Hi!
Jack Delerousse wrote:
But, if I configure the service to be asynchronous, then it will create a separate thread to do the processing - including writing to the queue. This would lessen the chances of a timeout, correct?
With reservations for not having completely understood the entire question, here are my thoughts:
The separate thread that processes the request to the web service only inserts the data received, that is the batch data, into a queue. The first step of processing the request is then done and the web service can now return a correlation identifier or such to the client.
Some time later, another thread, constantly running in the background, retrieves data from the queue and processes it.
Finally the processed data, with some association to the correlation identifier, is made available to the (other) web service operation which the client uses to poll for result data.
Reference:
http://java.sun.com/blueprints/guidelines/designing_webservices/html/architecture5.html#1147022
Does this make sense? In other words, I need to make this service asynchronous to lessen the risk of a timeout, right?
Yes, to me, this makes sense.
An alternative that I come to think of is to do
SOAP over email. The client mails the request, with the batch data, to some mail address. The email is then processed by the service and, using for instance the reply-to email address, sent back to the client.
If using SOAP is not written in stone, another alternative is a RESTful web service that, as a result of POSTing the batch data, returns an URL at which the client can poll for the result.
Update: Just discovered that
JBoss RESTeasy already has built-in support for this kind of asynchronous operations.
Best wishes!