In the Endpoint Design and Architecture objective of the certification, I was going through some time sequence diagrams on how service handles the request Asynchronously using some sort of queuing. Whether the Service is handling the request synchronously or asynchronously, we know that client has an opportunity to poll for the result based on the response (some kind of token) returned by the service for later lookup.
Now assume that there are two clients clientA and clientB sending the request to interaction layer asynchronously and the interaction layer returns each of them with a unique token for them to poll later and things move on. Later when each of the client tries to poll the service, how would service know which response corresponds to which client. Does the service maintain any client specific information? I believe, it should be stateless. Then how does it achieve this.
In the event of client making Asynchronous call and service handling the request Synchronously, client will have the response immediately, but has an opportunity to look for the response at a later time without blocking, by checking isDone() method of Future interface. This is possible, because the response is actually available.
But In the event of client making Asynchronous call and service handling the request Asynchronously, response is not available right away and service can generate the response at a later point. What would happen under the hood, when the polling is done by client? Would there be another call the WS?
The service that is polled for a result some time after the original request has been made may store the result in a database or a hashmap, using the unique client id as key.
There would be a special operation in the service to do this. The information in the database or hashmap is, of course, client-specific.
I guess that, in a sense, this could be considered as client state and it may have a negative impact on the scalability of the service.
Hope this answers your question.