I'm building a custom message queue, where I have to maintain a queue to hold the requests and retry them using a queue structure(FIFO). I have started out using servlets, which actually maintains the queue during the server life time and when server goes down, it will tranfers all these requests to the DB table.
In this case, I can I send a request to destination using a web service call? Can anyone please show me elaborately on how to use a web service call to post a request object in the servlet. ?
Thanks in advance.
Related
I have rest client API accessing data through /read endpoint from my server. However, I have an internal batch service that calls my server's /write endpoint which updates the data. So from time to time the data from the server gets updated. How will I tell the client that the data is updated and ask it to call the /read endpoint again to get the latest data?
Below is a highlevel diagram on the scenario.
Try learning webhooks? Basically, the client will "subscribe" to your webhook, or to make it easier, the client will provide an endpoint to the server. Whenever there's an update, your server just sends a request to the client. The client should simply call a service that, whenever it receives a request from the webhook, fetches read.
It basically goes like this
Client subscribes to server
The client gives the server an endpoint /updateAvailable
When there's an update, the server sends a request to client's endpoint /updateAvailable
'/updateAvailable' invokes a service that calls on '/read'
The '/updateAvailable' endpoint could invoke a service that updates content. Let's say the request sent has a parameter
{
"updateFound":true
}
So whenever the client's '/updateAvailable' is called and receives a request, you do something like this (pseudo code)
if (updateBody.updateFound.message=true)
then call read()
Edit
By creating an endpoint for client, you can also do automatic updates. So client has an /updateAvailable endpoint. The server sends the update to the /updateAvailable endpoint, which from the client side invokes whatever service is used for /read
There are two solutions for your question:
Using timer on restful client to request to restful server in every N seconds/minutes... However, it's really bad idea because it has to request to server many times even though there's no updated data.
Using third party publish-subscribe-based messaging protocol solutions to implement push notification feature whenever there is new data updated. These solutions are: Google FCM,MQTT,AMQP
I have a RESTful web Service that provide function of returning some data whenever a client send GET requests to ask for it:
#GET
#Path("/{deviceId}")
#Produces(MediaType.TEXT_PLAIN)
public String getDataResource(#PathParam("deviceId") long id){
return dataService.getData(id);
}
And the flow for this case would be the client sends request -> the web service returns value. But I want to ask that is it possible that the web service will automatically send response to the client when ever it has new data change inside of it? That means it not need to wait for the client to send request to ask for it. Because I would like to establish a communication between a client and some services running on an Application Server so that the client can always receives the newest data from the Application Server, so I think RESTful web Service can be a solution for it. And in oder to be ensure that the newest data will be transfered to the client side, so the server has to send to the client, not wait for the client to ask for it. Is RESTful web service provides any function like this?
Thank you all!
Is RESTful web service provides any function like this?
No. Not in the context you're asking for.
As answered before, the client could periodically poll for updates on the server. This is usually common option.
Another option - the original server posting updated on the "client". The client then becomes server itself. Viable, if you can expose services on the "client" side.
Maybe what are you looking for are web sockets. It is a long-lasting connection from client, where the server could keep returning data as they come.
There are some books around but you could search the net for more resources depending on the framework you use
You can implement notification system(observer pattern), so that client will poll the server in certain interval and any state change, it can get the result.
You may use the Schedulers to push the data to the client in a certain intervals.
I am trying to implement a web socket session manager and I have just encountered a road block that I hope someone can assist me with.
Basically a client will initiate a web socket session with my websocket server endpoint and I will take the HTTP request parameters, parse it and subscribe to web service producer endpoint. The Web service will return a response containing a subscription identifier of which will use as a key mapping (along with the HTTP session ID) to add to a java map cache with the session object. The proceed to send data to my published webservice consumer endpoint. My application will then take the data received from the producer, use the subscription id that comes with each packet and find the right session in the map caches to send the data back to.
Here is my problem..
I noticed that if the client opens another tab in the browser and sends a second subscription request, it would still be sent with the same HTTP Session ID yet tomcat will still be able to stream the data to the correct tab. This implies that the tomcat websocket implementation has a built in multiplex handling mechanism.
To exclude some unnecessary details unless asked, I want to to also be able identify all the channels that were multiplexed under the same session id. But I can't find any way in the API to identify it. As I need to be able to look up my map caches and remove sessions for tabs that have been closed (which triggers a close method in my web socket endpoint), but I'm not going to be able to do that as there could be many sockets/channels associated with the same HTTP Session ID.
The websocket framework does not provide any such implementation. Every tab opens a new socket. You can maintain a session info through adding a key in the request while initiating the websocket and on message check for that key(eg JSESSION id value) in the server and serve the request accordingly.
I'd like to use JMeter to test an asynchronous web service. Namely, JMeter is used to send Soap requests to a webservice (invoking some WSDL defined routines) and the webservice will queue these operations for later execution. It will respond with a notification for each operation that is executed.
I would like to be able to track the latency between request and response for each request sent.
Since the request and response happen asynchronously, I would need a way of mapping each request that I send to the response which may come back later.
Can someone point me to the simplest way of doing this in JMeter?
Thanks in advance.
the simplest way I see is to setup a thread simulating each user.
After sending the request, the thread polls for the response, which is the way a browser would work.
Obviously, this cannot be done when the time between request and response is long, and/or volumes become very large. In this case, you probably would need to log each event and to calculate time duration offline.
For a web service application, I would like for the server to be able to notify the clients about some events. When a client is launched, he calls one of the WS methods to get some information it needs. Then the server, that stores this information, listens continuously for changes on these information and if there is a change, it notifies the concerned client.
I don't know if a web service is a good solution to my problem? I don't know how it may work concerning the TCP connections, since the server may notify a client after a very long time.
What would be the best architecture to solve this kind of issue?
Thanks
EDIT: I've looked at some discussions that propose to use Comet, but if you think there are simpler and more convenient solution, please let me know. Since I'm starting this project from scratch, I have no limitations.
I can also use a polling model where the clients periodically poll the server for the information they need, but then I need to take into account the load that this model may create on the server. I don't know if web services can support such a load when there are a lot of clients.
I've also looked at the asynchronous functionality provided by Servlet 3.0 but I don't know how it may solve my problem.
Without polling: sockets
With polling and webservices: u should use etag (html).
When a client polls he sends a request with an etag. webservice responds either with 200(ok) and data or 304(not modified). 304 has no body => less trafic
Instead of client polling the server, you could implement a callback method on the client so that when ever server want to publish some changes to the client, the server can use the callback method provided by the client.
I can think of one the two approaches below using web services solution:
Callback: When client invokes the server it leaves its call back url and a id, say correlation id. When the server wants to respond back to the client it will just use the call back url to notify. The Server can use a variety of approaches to process the request asynchronously. Your client need not be a webservice for this, but it should be capable of accepting requests (callback). It can be a servlet etc.
Polling: When client makes a request to the server it receives back a id, say requestid. After specified interval client polls the server with this request id to fetch a response. A reasonable timeout and polling interval based on the processing time would be required.