I am working on a project which have many legacy heterogeneous systems. We are planing to connect them using JMS/MOM/ESB but need Synchronous web service calls from client.
i.e Request/Response architecture using web service is a requirement.
Client will make calls and wait for response.
My question is how can we implement Request/ response system which internally work on JMS/MOM to connect desperate systems?
Second question : Do any existing JMS/MOM or ESB implementations support such synchronous architecture?
first about second question: All of them support such architecture.
second about first:-)
just a brief idea:
when you send a message to target JMS Queue you have to have a unique message ID (in headers as example) then target system must answer (response) to "replyTo" queue. Then you have to have listener on that replyTo queue with filter by that unique ID and your flow must wait for response from that listener.
Something like that...
Related
I use Angular with Spring for internal API communication. Now I need to call external api to get some data. That external API provides callback feature, so I trigger call from Angular, call Spring rest method which, at the end, calls external API.
On the other hand I get data on my callback methods (Spring rest also), but I dont know how to transfer those data back to Angular.
Is websocket the only option?
If internal API calls are longer than the allowable client timeout, then you will need to find a WebSocket or WebSocket-like alternative. The alternative to WebSockets is to use long-polling (good example with source code here), which is essentially having the client repeatedly make requests until the original task is completed and the data can be sent. Either way, you'll need to use a pub/sub mechanism of some sort to handle multiple users, which is where things can get complicated.
Pub/sub can be complicated and I don't have an example on-hand, but essentially you must (1) have the client subscribe to a channel using a unique identifier (you can do this with CometD via a service channel), (2) evaluate the response, (3) publish the response to the client's subscribed channel, and finally (4) close the channel when it's no longer in use.
I've had some luck with CometD as a library to simplify pub/sub channel management, and it provides a good abstraction for asynchronous communication, although I haven't tried it with Spring and it might be heavy for what you want to do.
Another option that I'm less familiar with is to use Spring with STOMP. This seems to come recommended by others. Spring does provide ways to send messages to single users using STOMP: Sending message to specific user on Spring Websocket
I'd recommend following the above STOMP example.
Additional STOMP resources:
Getting Started with WebSockets (Spring)
Enable STOMP Over WebSocket
Angular2 with Stomp.js
As a side note, throttling may be necessary here, too, as with any time that you can spawn long-running threads from clients.
If you choose not to use STOMP or CometD, then a lighter solution could be to roll your own pub/sub for this single case using Spring's DeferredResult (as in Roger Hughes example), tying the subscription request to the long-poll request via a UUID token, which might also be the session ID if you choose to disallow concurrent requests per user. On subscription, the system can associate the request with a UUID and return this UUID to the client. The client can then make long-poll requests (again, as in Roger Hughes example) but with the UUID attached. The server can wait until the request for the given UUID has completed and then return the result to the client via the client's active long-poll request.
Channel management (i.e., request/UUID-tracking) can be done by clearing the channel on DeferredResult result retrieval and removing orphan channels with a separate thread acting as a GC -- or, perhaps better yet, automatically clearing orphan channels by removing them on DeferredResult completion/timeout if no active listeners exist. If you opt for the latter option, you will want to make sure that the client won't have any delay between its long-poll requests so that the DeferredResult doesn't unintentionally complete with no listeners.
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 was going thru Soap vs Rest on net and found most of them says Soap supports asynchronous call while Rest does not but did not get any concrete example of that. Can anybody help me here?
Here is one of the resources i was referring to
http://web.archive.org/web/20120421084456/http://www.prescod.net/rest/rest_vs_soap_overview/
http://searchsoa.techtarget.com/tip/REST-vs-SOAP-How-to-choose-the-best-Web-service
http://seanmehan.globat.com/blog/2011/06/17/soap-vs-rest/
As per my understanding both should be synchronous. In both cases client makes a call to web service either thru soap or rest, client waits till response comes back from service. So how come soap supports asynchronous behaviour while rest does not?
REST is purely an HTTP transport based call and you will receive a response say 200 OK
on the other side,
SOAP uses two varieties,
Synchronous Messaging over HTTP
Asynchronous Messaging over HTTP
With synchronous messaging, the Requestor makes a request and the transport layer code blocks waiting for a response from the Provider. The Requestor receives the response on the same HTTP connection that the Requestor initially established to send the request. Synchronous exchange is usually easier to implement and requires that the Provider be able to generate a response in a short time, specifically in a time less than the HTTP timeout value(generally 120sec).
[A single HTTP Connection is used that itself behaves Synchronously]
With asynchronous messaging, the Requestor is able to release transport specific resources once the request is acknowledged by the responder, knowing that a response will eventually be received. When the Provider completes the processing of the message it sends a response back to the Requestor over a new HTTP connection.
[Here we utilize two HTTP Connections to implement an asynchronous messaging
first HTTP Connection is used that for sending the Request and receiving an acknowledgement HTTP Response 200/OK
second HTTP Connection is used for receiving the callback and responding HTTP Response 200/OK]
Rijoy
https://soascribbles.wordpress.com/
SOAP defines a reply approach that allows for asynchronous computing, like a callback mechanism. You can achieve the same with REST but there is no specification for it, so you would have to build it yourself.
Here is an example using JAX-WS 2.0 demonstrating the feature.
I found useful information in Wikipedia WS-Addressing, which has a link for this W3C Specification.
In the past I also developed in SAP ESB designer which allowed for asynchronous service interface methods. Although I never used that feature, that tool was fully compliant with SOAP specification and I am pretty sure it would work just like the Java example above, since the WSDL was used to generate JAX-WS server based. If I have time next week I will use that option to so see what happens and post it here.
You should also check this answer which address pertinent aspects of this approach.
I have created a REST service which actually calls an async method to interact with DB layer and made our service asynchronous. I feel it is possible to implement asynchronous service in REST API. But in that case you need to have a call back service which will check whether the process has been completed in regular interval.
I have successfully implemented both polling and callback client side asynchronous examples, but now I am interested in implementing a web service with server side asynchrony. The infrastructure is Java EE using JBoss AS 6.x.
The pattern (as I understand it) that I am trying to implement would involve two web service operations, one to initiate a request and a second to check to see if a request is done and retrieve the results.
Client invokes web service endpoint operation 1 with search parameters via SOAP over HTTP.
Web service endpoint sends the request over JMS queue 1 to a message driven bean.
Message driven bean (MDB) picks up the request from queue 1.
MDB acknowledges service request by sending a message containing a correlator ID over JMS queue 2 to the web service endpoint.
(I am assuming this correlator ID will be the JMS message id generated.)
MDB acknowledges the original message to remove it from queue 1.
MDB begins long running database query, presumably building results to a temp table using the correlator ID as the
retrieval key.
Web service endpoint sends back reply containing correlator ID to the Client via SOAP over HTTP.
I am guessing that, since picking up the results doesn't involve a long query, I don't need JMS, I can simply query the database to see if results are ready. So, the second operation would be:
Client invokes web service endpoint operation 2 with correlator ID via SOAP over HTTP.
Web service queries database using correlator ID. Result code would be: no results found, operation still in progress, or
results found.
Web service responds to Client with some sort of complex structure that would combine the result code along with any results.
So, I have many questions. I have seen some references to server side support for asynchrony, but they all seem to be server specific in some way. For example, I have seen a diagram describing this first operation exactly, but it seems to be OC4J specific. If anyone can direct me to an generic example or tutorial implementing something like this, please do. Other subleties might be, should I use the JMS message ID as the correlator to return to the client? I am assuming I should use CLIENT-ACKNOWLEDGE as the JMS session mode so that the MDB can send a reply to the web service and then remove the message from the queue. Or, should I even bother? Should the web service endpoint just generate a JMS message, pop it in the queue and return the message ID directly to the service client without going through all the rigamarole of having the MDB send back a correlator via JMS queue 2? [edit: Actually, the more I consider it, it seems wrong that the web service would send a message and then, what, block on waiting for a reply on queue 2? ]
Correlation id can be generated at step 2 and immediately returned to the client. That reduces additional hops before responding to the client. Generating a persistent message into the queue should suffice. I also dont see the need for two queues. I prefer an application generated correlation id.
I'm looking for a way of implementing a simple API to receive log messages (for various events across various systems).
We've concluded an HTTP get request is the most open (lowest barrier to entry) for the different code bases and systems that would need to post to this server.
The server itself needs to provide an HTTP GET api where I would send a message e.g. logging.internal/?system=email&message=An email failed
However we'd like this to be non blocking so any application can throw information to this server and never have to wait (not slowing any production systems).
Does anyone know of any framework to implement this in Java, or an appropriate approach?
In java, for the server, you can use any implementation of JAX-RS for the Restful part, and when processing the message, just call an asynchronous EJB method ( http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html ), which will do the longer processing.
This will allow the RESTful request to return as fast as possible.
In this case, the only blocking part will be the http request/response.
If you want to make it less blocking, issue the RESTful request from the client in an Async method as well (or a Message Driven Bean if using Java EE 5).