Re: [soaplite] Re: soap call - fire and forget
- Ok, so the million dollar question is:
"Is SOAP::Lite capable of performing asynchronous messaging by itself?"
The answer is yes, but not natively. There are two forms of asynchronous
messaging that I have seen:
1) A sends message to B. A transmits to B a port/socket (that A opens) for
the response to be sent to. When B is done processing the message, they
post their response to the port A designated. This port is the means of
correlating the response with the initial request. (BEA does something
similar to this I believe, but they also use a Conversation ID for
correlation as well, and if I am not mistaken, .NET does something like
this as well.)
This is known as a callback style of asynchronous messaging.
2) A sends message to B. B returns to A a Correlation ID. B polls A for
response using Correlation ID. (Of course this is the scenario that Grand
Central implements through its network because it's implementation it
doesn't depend upon the endpoint to actually comprehend ANY asynchronous
This is known as poll-based style of asynchronous messaging.
Here is the problem with 1) both asynch implementations that I know of are
proprietary protocols. It therefore requires that the server and client
both understand how to exchange messages, and correlate in this manner.
If I wanted to implement something like this in SOAP::Lite, I would
suggest implementing a CGI that could process returned responses. The
client would have to be able to generate a unique ID and trasmit it along
with the URL the CGI listens on to the service being called. The service
would then have to persist and return the correlation id provided by the
client, and post the response to the CGI/port designated by A.
I have actually implemented something like this, but again - it is highly
proprietary and therefore not very portable.
Asynchronous messaging is a highly desired feature enhancement for
SOAP::Lite, but I am not sure which standard to turn to for a COMPLETE
answer to the problem. WS-Correlation is only part of the problem - what
is the HTTP protocol?
> Is SOAP::Lite capable of perform asynchronous messages by itself. I^byrne :/
> assume the default is synchronous? And is this because of the way LWP
> One thing I notice in a system we have recently developed is that when
> using is over a LAN it works great, except for the synchronous
> interaction. But when I run the system over a corporate VPN the
> interaction is "choppy" - slower and not as consistent, but any
> transaction always seems to finish OK. Could this be a result of
> SOAP::Lite or do you think it is the VPN? I have used other commercial
> client/sever type programs on this same VPN and some work fine (same as
> being on the LAN) and others are "choppy" and some are downright
> unreliable and fail. Could this be a result of some of these systems
> are synchronous/asynchronous?
> Byrne Reese wrote:
>> I apologize to spam the group with something vaguely commercial, but I
>> feel this thread warrants it.
>> Grand Central is a Web Services network (technically, we call ourselves
>> "Business Services Network" - but I am not going to mince words) - in
>> event, Grand Central offers the ability to turn any SOAP call into an
>> asynchronous non-blocking one.
>> Most SOAP calls are synchronous in nature: socket opens, request is
>> message is processes, response returned, socket closes. However, as this
>> threads suggests, not all SOAP calls follow this pattern. Sometimes you
>> just want to fire off a notification. Sometimes, the SOAP call is likely
>> to take a long time and hanging up a thread, or socket for that long is
>> impractical, sometimes you just want to fire and forget... Grand
>> asynchronous messaging protocol can be used with any service deployed on
>> the network.
>> In a very small way you can think of GC as a proxy. In an asynchronous
>> scenario a message is posted to a service. The network accepts the
>> messages, and immediately returns a tracking number (used for the
>> correlation later) to the sender. Mean while the message traverses the
>> system and is delivered to the utlimate destination (in some cases the
>> message is sent to multiple services when the service you are sending a
>> message to invokes a business process - we all heard of SOAP
>> intermediaries, Grand Central actually uses them!). When the response is
>> returned, it is held by Grand Central, and the user then polls for it,
>> much like you poll a POP3 mail server for email.
>> Grand Central is free as long as your bandwidth is less than 25MB per
>> month. And you have me as an excellent support resource. I have made
>> there are lots of Perl/SOAP::Lite examples on the GC developer site. :)
>>>I have been trying to do something similar - in my case I want the end
>>>user (thru a GUI) to be able to cancel the SOAP call - or at least
>>>ignore what the call returns... I think the issue is that since
>>>SOAP::Lite is using LWP to perform the HTTP communication, the process
>>>waits until a return or timeout. Perhaps there is a way to configure
>>>this??? I am experiementing with Perl 5.8.2 and using a separate
>>>thread to make the SOAP call. I have also seen ways to spawn another
>>>process to make the call so the main process is not stuck waiting
>>>around - for Win32 there is a good example in the O'reilly Programming
>>>Perl/Tk Book that goes out and gets comics and displays them back in
>>>the TK UI - this does not use SOAP, but does use LWP and the concepts
>>>work the same...
>>>Yahoo! Groups Links
>>>To visit your group on the web, go
>>>To unsubscribe from this group, send an email
>>>Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>> ^byrne :/