I have an API implemented with Jersey. An external service is making HTTP requests to my endpoint and expects a result into the response. Currently, I am using the Asynchronous Server API, in order to make all my business logic and then respond when ready. It’s working fine, but now I want to improve scalability and H/A.
My plan is to have multiple instances of my API behind an Nginx load balancer and all the requests accepted by any of my API instances will be forwarded to another microservice with RabbitMQ. Finally, I want to collect the results from the microservice and attach them into the response.
My question is if I can dynamically generate the response to the original HTTP request from any of my API instances. I want any of them, not only the one that originally got the webhook, to be able to send an HTTP response back to the caller. Somehow maybe to store/serialize the AsyncResponse object. In other words, this means that even if the instance that originally got the webhook request is stuck or down, another one can fill in and send the response.
Maybe this is not possible but still I would like to hear any other suggestions that can help.
Thanks.
Related
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'd like to synchronize the state to all the clients interested in particular entity changes. So I'd like to achieve something like:
exposing CRUD API on entity (via HTTP/REST and websockets)
and routing the response (of the modifying calls) to websockets topic
So technically, I'd be interested in ideas to mix spring-data-rest with spring websockets implementation to achieve something like spring-data-websocket.
There are a two solutions coming to my mind, and in fact both would be:
spring-data-rest to expose my entities via REST/HTTP API
websocket controllers (used for the modification calls on entities)
The websocket controllers would look like this:
#Controller
public class EntityAWebSocketController {
#MessageMapping("/EntityA/update")
#SendTo("/topic/EntityA/update")
public EntityA update(EntityA entityA) throws Exception {
// persist,....
return entityA;
}
}
Scenario 1: Websocket API called from REST/HTTP API
Rules:
client request is always REST/HTTP API
response is REST/HTTP API for all the operations
moreover for modifying operations the websocket message comes as well
Technically, could be achieved, by:
calling the websocket controllers from the spring-rest-data events (namely in the AfterCreateEvent, AfterSaveEvent, AfterLinkSaveEvent, AfterDeleteEvent)
Still the solution seems quite sick to me, as I'd need to go for:
client A --HTTP request--> Server (spring-data-rest controller)
Server (AfterXXXEvent in the spring-data-rest controller) --websocket message--> Spring websocket controller
Spring websocket controller --websocket message via topic--> all Clients interested in the topic
Server (spring-data-rest controller) --HTTP response--> client A
Scenario 2: Websocket API independent from REST API
Rules:
client request is REST/HTTP API for non-modifying operations only
response is REST/HTTP API for non-modifying operations only
client sends websocket message for all the modifying operations
websocket message is sent to client for all the modifying operations only
Well, if no other ideas come up, I'd go for the later one, but still, it would be great if I could have somehow generated C(R)UD methods exposed via websockets as well, something like spring-data-websockets and handle only the routes in my implementation.
As I feel like I'd have to manually expose (via *WebSocketControllers) all the CUD methods for all my entities. And I might be too lazy for that.
Ideas?
Scenario 2 talks about, in the last step, a single client.But I thought your requirement was for a topic since you wanted multiple clients.
If I wanted to complete 2 for your stated requirement, then you might want to maintain a list of clients and implement your own queue or use a ForkJoinPool to message all your clients listening in on your WebSockets. Having said that, A topic is definitely more elegant here but overall looks too complicated with different interfaces
For all messages from client to server, just go with a simple wire protocol and use a collection to parameterize, it could be
RParam1.......
At the server, you need a controller to map these to different requests(and operations). Somehow does not look like too much work.
Hope this helps.
The same architecture has bugged my mind for a while now and it will be a long story if I want to mention all the drawbacks and advantages of it so let me jump into the implementation.
The second scenario is valid, but as you mentioned its better to perform the crud actions on same websocket session. This shall remove the need for HTTP handshakes on every request, and reduces the body size of messages, therefore you will have better latency. Meanwhile, you already have a persisting connection to a server, so why not make good use out of it?
I searched around for a while and after 6 years from your question, I still couldn't find any websocket protocols that can make this happen, so I decided to work on that by myself cause I needed it for another dummy project.
Another advantage of such protocol could be that it doesn't require much changes to your already written controllers. So it should be able to support Spring Framework (for example) annotations and make websocket endpoints out of it.
The hard part about implementing such protocol in another framework like spring is that as its not nice to create ServletRequest and ServletResponse and convert them to your own websocket protocol, you loose some advantages. For example, any http filter you have written in your application till that moment, will be meaningless because its not really easy to pass your websocket messages through those filters.
About the protocol itself: I decided everything to be passed through json format, alongside a unique id for each request so we can map callbacks on client side to the request id. And of course there is a filter chain to add your filters to it.
Another hard to deal thing here is Spring Security as that too works like http filters in some cases. In my own lib I could finally handle annotations like #PreAuthorize but if you are using antMatchers in your HTTP Security Config, it would be a problem.
Therefore, creating websocket adapter to call http controllers will have many drawbacks.
You can check out the project here: Rest Over Websocket. Its written for Spring Boot.
I've got a news server in Java and want to make it possible for clients to receive news as soon as they appear in database, without reloading client's page. For this purpose I decided to make HTTP request from client that returns response only after news become available. But if there are a lot of clients, server won't be able to accept new requests. So, is there any java technology that deals with it?
P.S. news server is just a similar model, but not an exactly problem, so, please, think about it more abstractedly=)
The term you're looking for is push communication. You could have a look at Comet, or the Java API for WebSockets.
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).
could you please give me a sample code on how an Http Server(Java) receives the request of a client(android)? I mean the client sends the request via Httppost, how the server takes the content of these requests in order to see the context and reply? I am trying to built a chat application.
Thank you in advance!
The server-side of HTTP is usually implemented using the protocol stack provided by a web container. You would then implement your application's server-side as servlets. There are numerous tutorials on this.
If that's the way you want to proceed, look at one of the standard web containers; e.g. Tomcat, Jetty, Glassfish, etc. The source code for all of these is available for you to browse, though I should warn you that they are all complicated under the hood.
Assuming that your HTTP service is going to be delivering JSON or XML (rather than HTML) to clients, you may want to look into using a RESTful framework.
Have a look at ServerSocket. Keep in mind that accept() blocks and, as you will probably run it in a service, you will want to time it out and check for the completion of the service. That should probably run in its own thread as should the responders to requests.
From there, you can open input and output streams to receive the request and write the response. There are any number of packages that can help you with the interaction, or you can roll your own, but it doesn't seem like you've done a lot of homework. Perhaps some searching, reading, and more specific questions would more you along more quickly.