We have a Java API that needs to be supplemented/fronted with a SOAP/REST Web service Layer.
What does it take to implement Async Calls across process/server boundaries using
a) SOAP Webservices
b) RESTful webservices
Some of the methods might need multiple calls to respond to the request.
We will be using Java/J2ee to implement the SOAP/restful service using a library like CXF or Axis or Jax-RS/WS.
Any examples ? Gotchas ?
Thank you,
The Async Http Client is an open source library that was specifically designed for this type of problem. It utilizes futures and wraps up a lot of the detail and hassle out of making async calls.
The author has a very good getting started guide and there is an active discussion group. The author is a very talented developer and the project is under continuous development.
From the documentation:
The library uses Java non blocking I/O
for supporting asynchronous
operations. The default asynchronous
provider is build on top of Netty
(http://www.jboss.org/netty), the Java
NIO Client Server Socket Framework
from JBoss, but the library exposes a
configurable provider SPI which allows
to easily plug in other frameworks.
Your question is not clear. I am interpreting your question as you want your serverside code to call a remote REST web services in an Async manner. If so then your best bet is to use the Futures feature of java.util.concurrent it will do exactly what you want. If my interpretation of the question is wrong then please update your question with exactly where the async operations need to happen.
Akka http://akka.io/
Great framework, great performance - Here are their claims:
"""
Simpler Concurrency
Write simpler correct concurrent applications using Actors, STM & Transactors.
Event-driven Architecture
The perfect platform for asynchronous event-driven architectures. Never block.
True Scalability
Scale out on multi-core or multiple nodes using asynchronous message passing.
Fault-tolerance
Embrace failure. Write applications that self-heal using Erlang-style Actor supervisor hierarchies.
Transparent Remoting
Remote Actors gives you a high-performance transparent distributed programming model.
Scala & Java API
Scala and Java API as well as Spring and Guice integration. Deploy in your application server or run stand-alone.
"""
#Vivek
GET is async and other HTTP methods
are not.
This isn't true. Please go ahead and read about AJAX :-)
For REST web services (apart from GET) everything else (POST/PUT..) is Async, it returns you the HTTP status code of the opeeration.
If you want to make GET also Async then you will have to use Threads, We did it once in Spring framework using #Async annotation (which internally spawns a thread).
From get return the callback URL as the response and use threads to process the request asynchronously.
Apart from that, For both SOAP / REST once you get the request you can publish it on a JMS queue to make the service Async.
One of the best ways to implement asynch ops is to use callbacks. For REST APIs, design of APIs and Rest client should support this. For instance , client class should pass itself or it's inner class as listner. Rest API on server side should maintain request id and call back listener in map . Once processing is done , it can call method on listener based on request id from map.
Real question: why do you want to call it Async? Having looked at solutions for parallel processing on the Java EE side, it's not recommended that you spawn child threads within a container on your own.
In your case, it looks like the following:
1. you're looking to create a wrapper contract in WSDL (REST or SOAP or both) and if you clients are not just browsers (AJAX)(i mean you'd have adopters from the server-side), then, for JAX-WS -> you could create a #CallBack end-ponint (http://docs.oracle.com/cd/E15051_01/wls/docs103/webserv_adv/callback.html)
or
if it's REST end-point that requires being called from an adopter (server-side), use jAX_RS 2.0 feature
Note: Above assumes it's point to point but in an Async way
Here are a few options:
if you're looking to call REST Or SOAP or some other function asynchronously, you can use workManager API (JSR )
or
use JMS and use a request-reply model if you need it (short running) and calling multiple end-points in parallel
use WS-BPEL (only WSDL end-points) - this is a OASIS standard as well
use SCA (any component with any technology) that can contain assemblies of WS-BPEL component (stateless or stateful) running in BPEL engine like Apache ODE or IBM process server and other components and collaborates. This is a standard
Related
I need to create an async web service using jax-ws and I need configure it in a Oracle Service Bus 12c.
will you have some tutorials that explain step by step how to achieve it?
What are the best practices?
If you need to use Oracle Service Bus as an intermediate layer for an asynchronous backend service, you need to create two synchronous proxy services:
First for sending the request to the service and providing the synchronous reponse back to consumer.
Second for sending the asynchronous response to the original consumer.
Service Bus does not support asynchronous (long-running) services. The drawback of this solution is that these two services are completely separate.
I would prefer using BPEL for this scenario (which is also part of SOA Suite), if possible. You can create an asynchronous BPEL process which will cover the whole asynchronous communication by a single SOA composite. You can match the request and asynchronous response and easily indicate which requests got their responses. You can also utilize WS-Addressing.
I have web service cloud system based on Java EE. I use jboss as application server, java version 1.7
My system is something like a bridge between client and merchant servers. Client sends data via soap protocol (amount USD, merchantID, paymenttype and so on.) and i make service implementation based on requested params and send back to client.
I have a question:
There are two ways to make core implementation,
1 is to run it in main thread, every web service runs in main thread
2 per service call should be in separate thread.
I don't want code examples or anything, just what is the correct way to determine my solution?
You can use the jboss request processing thread pool to control it. There does not seem to be a reason to attempt custom thread pool. Its a a complete different discussion if you are thinking about asynchronous communication.
I got the below from another SO post which is helpful
http://www.mastertheboss.com/jboss-server/jboss-performance/jboss-as-7-performance-tuning?start=3
In my case, I designed my system as multiple threads managed by main thread. This solution is very helpful and easy to maintain.
Scenario :
There is a java library that helps asynchronously listen to some
system events. I am planning to use the already implemented asynch
functionality from a vb.net project.
I have planned to address it in the following way :
Write a web service around the java library
Add reference of that service to the .net app.
The web service will run locally on a tomcat as the .net app. The problem i am faced with is how do i make the web service communicate to the .net app asynchronously ? Should the .net app block and wait on a web service and if so how ?
I believe that firstly you need a design pattern for asynchronous services communication t better address your system requirements.
1 - Asynchronous Response Handler
The application creates a separated thread to process server response leaving main thread free for other tasks. When response arrives main thread is notified to receive the response. There are two implementation strategies: pooling and callback. With pooling, the main thread checks for response in the second thread until the response is available. With callback, the second thread notifies the main thread using a callback method.
2 - Request/Acknowledge
This patterns is based on the server participation to achieve asynchronous communication. Instead of splitting the process into two client threads, the process divided into two different transactions between client and server. This patterns needs some kind of correlation identification to associate request and response transactions. A messaging subsystem is used to achieve more scalability and availability.
A simple solution could be implemented using Asynchronous Response Handler/Callback Strategy. To do that, the service provider (java) could be a simple jax-ws web service.The service consumer(.net) implementation could use the AsyncCallback Delegate. There is a example here.
References:
http://www.servicedesignpatterns.com/WebServiceInfrastructures/AsyncResponseHandler
http://www.servicedesignpatterns.com/ClientServiceInteractions/RequestAcknowledge
http://msdn.microsoft.com/pt-br/library/system.asynccallback(v=vs.110).aspx (AsyncCallback Delegate)
http://msdn.microsoft.com/en-us/library/wyd0d1e5(v=vs.100).aspx (service consumer)
http://java.dzone.com/articles/jax-ws-hello-world (service producer)
You are planning to build a long running process, consider using some workflow engine like JBPM or Activiti. Since your calls are going to be web services which are stateless & you intend to have callbacks better would be an option to create persistent long running workflows since they would take care of most of the design & architectural issues else you would end up handling it.
e.g of issues
-Corelation between request-response
-Loss of data on reboot of system
-Application getting overwhelmed with data synchronization.
Polling & calbacks are just mechanisms for inter process communication but you need to handle req-resp correlation as well as ensure reliablity in the communication.
I have to implement a webservice which will be used by different clients written using several languages (e.g. Java,C#) and frameworks.
Because of this i decided to use JAX-WS and the Apache CXF Framework to create an WSDL first webservice.
Now my problem is that the webservice has to notify all clients whenever the user performed certain actions on one of them (like adding an element to the database).
After some research I found that the technique of long-polling might help me to get this task done. However I'm not sure that this is the best solution and that this one will work on all target plattforms.
Is the technique of long-polling suited in a Webservice (WSDL) context or is there another method widely used and supported?
Long polling or Comet techniques are best used for this scenario, Web services are stateless and don't support pushing data to clients without heavy modification of the hosting service, i.e. IIS, Apache... etc.
I am writing a web service in Java which needs to handle a large number of requests / second. The general flow will be:
Web service receives a request from client
Returns a 'keep polling me' response to client
Calls another web service (or
services), and waits for them to
respond (with a timeout)
Client polls our web service, until
it receives a response (with a
timeout)
Researching on the Internet, I have found two general approaches to writing web services:
Spawn a thread for each request
Use the Reactor pattern (central dispatcher thread responds to IO events)
Do you have a recommendation for which approach is generally better, and what are the pros/cons of each approach? I would also appreciate pointers to examples.
Don't think multi-threading. Think asynchronously. I happened to have just coded an async handler that ran 2,000 RPS with <10 threads in IIS. Not sure how java works since I'm a .net guy but I gotta believe they have similar BeginXXX/EndXXX methods. If you ever spawn a thread then you're not considering all the places your code can block: data base IO, File I/O, web services, etc. These are the places your performance will cause your site to be slow.
Async, Async, Async.
Chant and repeat.
In addition to "No Refunds No Returns" response, I'd say yeah "Think Asynchronously" as you should be allowing your container to manage the multi-threading/scalability and high-availability issues of the web services it has deployed, this allows you to set-up things like clustering and so forth using your application container.
EDIT: So in conclusion, there isn't a pattern as such, maybe you should explore the scalability/availability features of your application container...
Asynchronism is indeed the right approach but don't manage this yourself, use something that supports asynchronous web service invocation like JAX-WS 2.0 (which uses the Future interface and/or the Executor framework from java.util.concurrent). See Asynchronous Web Service Invocation with JAX-WS 2.0.