Thanks Andrew. That is very much like the approach I have in mind with some minor differences. I don't have the need to persist the IDs in a database as my web services dequeue messages off of a dynamic queue and they just do it when the call is made by a client. Essentially, the client submits JMS messages by calling a web service and retrieves JMS messages (response messages) by calling a different web service. The client basically has a thread that wakes up every so often and makes the second web service call for the retrieval. However, the one downside here is that the second request is initiated by the client as well.
What would be clean and distributed in my mind is if the callback actually happens to be another web service call. That way, the client registers a web service call as the callback and when the response is ready, the server side implementation simply calls the callback web service and passes the response. Ofcourse, this would mean that the client has a web service implementation as well but that seems simpler and well-detached compared to this AsyncHandler approach. Right? -- View this message in context: http://www.nabble.com/Asynchronous-Web-Services-using-AsyncHandler-tp19520451p19535165.html Sent from the cxf-user mailing list archive at Nabble.com.
