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).
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 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...
So, I have this old legacy JAX-WS service, that does a lot of IO per request, so each request takes quite a bit of time, but doesn't consume much CPU/RAM.
With amount of clients increasing lately, there's a huge problem of thread starvation.
At first, I thought about implementing JAX-WS builtin async support, but it requires clients to be aware of it, and thats a no in my situation. I cannot possibly force them all to update their code.
My current idea is to create special async servlet and manually parse SOAP request and encode the response, but I can't seem to find some good way to do that.
Is there any way to utilize Servlet 3.1 async support when handling JAX-WS requests?
I should clarify, that I cannot use some kind of queue, or otherwise "just return early", because request processing can fail, and client must get that failure.
I've found the solution that works perfectly for me, CXF Continuations API.
http://cxf.apache.org/docs/continuations.html
https://github.com/search?l=java&q=ContinuationProvider&type=Code&utf8=%E2%9C%93
I had to enable async for CXF Servlet, and add jboss module dependency to bundled CXF.
While the whole things feels somewhat like a hack, it allowed me to do proper asynchronous processing without changing service external API at all.
As a bonus, I can even decide whether to suspend request, or process it normally, which helps a lot in certain cases.
You could make use of workflow here where say you have webserver's workers accept the request, you handle it and places it in a queue which is shared by thread which will process this event asynchronously.
This would just mean that you have low wait time on client side and you process the client request asynchronously. In that way, you build your system scalable and can increase number of worker threads on either of the side i.e. webserver so you could accept multiple requests from client concurrently and at the same time multiple threads may be concurrently processing the events from client.
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.
Hi I am working with java and thrift. I see that there are 2 parts to the thrift Async system one is the Service.AsyncIface and another is Service.AsyncClient. From the thrift implementations for AsyncClient, I see that the non blocking interface is wired up and ready to go on the library side. I just made a simple client using TNonBlockingSocket and it works
1) Do we care if the existing thrift server for the Service is blocking or non blocking? Why?
2) If we want to wrap a nonblocking client framework in things like retry logic, host discovery, policy management etc what would be the ideal framework?
From client's point of view there's no difference in communication with sync or async server given that protocols and transports are compatible. That's because the client should receive the same serialized response from both sync/async servers. For example, if you do JSON over HTTP request, you don't really care if the server is sync or async.
Finagle is a good choice if you're interested only in JVM languages (and it's the only framework I'm aware of that has required feature set).