I'm looking for an example showing how can I configure my CXF project, so that I can call a service method asynchronously; meaning my invocation in the client side doesn't block for the response and when the response is ready the logic will be done. I'm very thankful if somebody can help me
Best
The simplest way is to use #Oneway annotation on the server side. CXF will handle the request on the server side in a separate thread, so the client won't be blocked and will return immediately after receiving 200 response code and empty response body.
Of course in this case you cannot receive any response (by definition of request-only SOAP operation), which is not an option for you. Unfortunately you're need to implement this by hand using thread pool and future tasks. Fortunately this is very simple since Java 5, start by studying ExecutorService API.
Related
I want to standup an endpoint /foo which is a synchronous endpoint for clients but the response is dependent on a callback /foo_callback being called on the app as a result of the request to the synchronous endpoint.
to elaborate the workflow:
Flow diagram
I havent decided on a technology to use so ideally would look for a recommendation.
High level what I am thinking of is starting an async thread in the request handler and check for an update on a singleton map to see if the server has responded but I am wondering if there is a better way
I dont have control over the client and cannot really use websocket or long polling.
For the last week I've been researching a lot on the microservice architecture pattern and its requirements and constraints.
The majority of ressources suggest to use event buses/message brokers (asynchronous communication) to communicate between microservices rather than using REST API endpoints.
Synchronous calling would result in a higher response time and may cause cascading failure in case of a particular microservice failing in the chain.
Question:
Let's say the user requests a particular functionality or page on a website/mobile app which then needs to fetch data from multiple microservices and use theire respective functionalities to provide the desired outcome. But to achieve the desired outcome (response to client) ALL the services need to do their work before the backend sends the response back to the client (website/mobile app).
But if we use asynchronous service requests - which means the calling service doesnt wait for a response and would send its own response back to the client without getting the data from the asynchronously called service - the outcome might not be complete if an asychronously called service doesnt respond in time (service is unavailable or network issues). This would mean that the backend will send an incomplete response back to the client which is not acceptable.
How can I deal with this issue or did I get the concept wrong?
I'm thankful for every answer
If it's absolutely essential that a request gets a full response (i.e. that the request is synchronous), that's a strong argument in favor of the service stitching together synchronous requests and responses (and potentially needing to handle rollback in cases of partial success etc.).
Many requests don't fall into that pattern, though. For instance, a response might well be interpretable as "we've received your request and the operation will be performed. You can track the progress of your operation by using this request ID"; such an approach fits well with asynchronous messaging.
I need to send a asynchronous message to client from my CXF (JAX WS) webservice layer...
How client would be capable of receiving it?What steps need to be taken care to achieve this?Is there a sample tutorial available?
You have two options to achieve asynchronous calls from client with CXF.
You can poll the service for response
You can define a callback which will be executed when the server's job is done
Each solution has pros and cons, so choose according to your needs.
The polling gives you a Response object and you can test if the call is complete on it by response.isDone(). (if not, wait some time, then send another request)
The callback gives you a Future object which wraps the call, you can define an AsyncHandler for instance when you call the service to define what will be run when the process is finished.
From the server side, you should take a look at WS-Addressing (to define a replyTo endpoint for callback if needed) and WS-POLICY: http://cxf.apache.org/docs/ws-addressing.html
Note that if you need to use callbacks (it seems so), you will have to define a CXF client on the client side to enable WS-addressing (on the cxf bus).
This is the issue I encounter, which is design and implementation related :
I have a REST web service that accepts POST requests. Nothing special about it. It currently responds synchronously.
However, this web service is going to initiate a background process that may take some long time.
I do not want this service to respond 30 minutes later.
Instead, it should immediately return an ack response to the client, and nothing more (even after 30 minutes, there will be no more information to send).
How do I implement such behavior with Jersey ?
I read the page https://jersey.java.net/nonav/documentation/2.0/async.html#d0e6914.
Though it was an interesting reading, I did not find the way to only send an ACK typed response (something like an HTTP 200 code).
Maybe i am confused with asynchronous and the behavior I want to implement.
I just understood that I could create a new Thread within my #POST method to handle the background process, and just returns immediately the ACK response.
But does this newly thread live after the response has been sent back to the client ?
How would you implement this WS ?
I hope you will help me clarifying this point.
I think the Jersey 2 Asynchronous Server API you linked would still hold the client connection until the processing completes. The asynchronous processing is really internal to Jersey and does not affect the client experience.
If you want to return an ACK, you can use a regular Jersey method, delegate the work to another thread and then return immediately. I'd recommend HTTP 202 for this use case.
You may create a Thread to do so just like in the Jersey 2 example and it would survive the execution of the Jersey resource method invocation:
#POST
public Response asyncPost(String data) {
new Thread(...).start();
return Response.status(Response.Status.ACCEPTED).build();
}
This being said, creating threads is generally not recommended within app servers.
If you're using EE7, I'd recommend you look at JSR-236 http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/package-summary.html
If you're using EE6, you can consider sending a message to a queue to be processed by a Message-Driven Beans (MDB) in the background.
BOSH (Bidirectional-streams Over Synchronous HTTP) is a sneaky way of implementing 2-way client-server communication in situations where true server-push is not allowed, most obviously to let a server push data to a browser client without having to use client polling.
It works by the client sending a request to the server, and the server doesn't respond immediately... rather it remembers the request but only responds when it has some data to send. When this happens the client immediately sends another request so there is virtually always a 'stored request' sitting on the server ready to push data to the client.
At least, that's how I think it works!
Update:
My question is how you can do this using a Java EE stack i.e standard servlets. Is this possible using say Servlet 2.x (I'm a bit rusty so I don't know if you can decline to send a response or something) or only using extensions through a wrapper like Atmosphere?
Not an equivalent but Servlet 3.0 introduces an Asynchronous API. With or without Servlet 3.0, there is also Atmosphere.
See also
Servlet 3.0 Asynchronous API or Atmosphere? Easy decision!
Asynchronous HTTP and Comet architectures
Jean François Arcand blog (the author of Atmosphere)
I think this is what you might be looking for: http://blog.jwchat.org/jhb/
Maybe you are looking for something like comet, a kind of reverse AJAX in which the client initiates the connection, allowing the server to push data when it wants.
EDIT: I realize you are looking for solutions in Java and when we think of AJAX we immediately think of JavaScript, but the term has been tainted lately and it represents a concept more than a JavaScript solution. Comet is very much a concept like AJAX and can also be implemented in the programming language of your choice.