This is not nearly as difficult as it may seem. If you are doing this
commercially, Grand Central Communications has a product that does just
this. It provides an asynchronous message bus to any synchronous
service. However, I am not sure the pricing recently, but they have an
excellent model for this.
Also - app servers like BEA and .NET do this as well, and it is all
But of course - this is a PERL mailing list, so let me tell you how I
would do it:.
Server side correlation:
Just as you realize, the first call is the request. The server will/
generate a unique identifier for the job and stick it in the database.
The server will return to the user the unique job id to the user. The
user/client then starts polling the same server for the response using
the job id as a parameter to the request. When the request is ready, it
is returned in the response to the poll request.
If you are looking for a model for how to do this and need something to
code against, Grand Central's Message Protocol document is an excellent
resource and can tell you at a low level, all the things you would need
Client side correlation:
Assuming the client has the ability to accept a message via CGI or some
Let the client generate a unique job id. Then pass to the server in a
SOAP header, the job id, and the URL to which the response should be
posted when then job is done. The server then receives the request,
queues it up, processes it, and when the result is ready posts the
response to the URL provided by the client with the client id encoded
Those are the two major modes of asynchronous messaging. You should
consider which approach is best for you, then post back to the group and
perhaps someone can help put the pieces together for you. :)
> I have a similar service - where user submits a job, gets a job
> identifier in return and then
> polls for the status/result of the job using the id. Now, we have a
> queuing system at the
> backend and a good bit of storage, so while the server submits the job
> to the queue and
> forwards the jobid it receives, the job continues to run and the
> result/error are stored for
> when the user polls for it. I am not quite sure on how one would do
> this without a system
> setup to specifically handle this.
> sorry not of much help.
> --- In firstname.lastname@example.org, thom@d... wrote:
> > Folks,
> > Two years ago I built a web service using Perl & SOAP::Lite. The
> project has
> > been highly successful at my client location. Because of architecture
> > constraints, it was built using SOAP::Transport::HTTP. Calls are
> > and we use fork'ing to achieve a higher active session count.
> > Now comes the fun. I've been asked to convert the service to an
> > service. Thus, calls for service will be immediately replied to with
> a callback
> > number (like a request id) while the procedure operates on the input
> data. After
> > the client waits a certain amount of time, they will initiate a
> > method with the callback number as a parameter, and they can get
> their results
> > (if ready).
> > It is not intuitively obvious to me how to make the server respond
> and keep
> > working on the service request. Any ideas?
> > Thom Eden
> > ______________________________________
> > This E-Mail was sent with Fronthost Web/Mail.
> > Use www.fronthost.com for all your hosting and development needs.
> *Yahoo! Groups Links*
> * To visit your group on the web, go to:
> * To unsubscribe from this group, send an email to:
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/>.