RE: [soaplite] Asynchronous messaging
- To wit, there's no way to tell if a perl subroutine 'intends' to return
something, because even without an explicit 'return' statement, a perl
subroutine still returns the value of the last statement executed, in
effect, a perl subroutine always returns *something* it's just a question if
the author of the subroutine put something usefull there, and if the user of
the subroutine wants it. Neither of which can be examined from the method
WSDL or some kind of method-defining language of some sort would be required
for that kind of logic to be even possible.
There are several usefull combinations using fork, in addition to the
server-side one (Guessing at how to clean up after a spawned process from
the middle of a soap service is messy at best, admittedly)
If you as the client-writer, know you don't need whatever value the server
returns you could simply do:
in your client, resulting in a notification call to your server, and your
main program not even having to acknowledge that it sent it, this is
probably the fastest fork-based implementation of what you particularly want
I've also written a couple of fork-based catch-throw implementations,
similar to what the fellow from Grand Central was talking about, where your
'client' forks a 'listening' agent (Actually a soap server in it's own
right) and calls a service via soap, and ignores the return value as per
above, and the 'server' forks off a new soap object which calls the soap
service in your 'client' effectively turning both sides into client-servers,
then your client simply needs a way to collect the messages from the
'listening' agent to do something with them (IPC pipes work reasonably well,
although I haven't found anything that works truely satisfactorly on Win32)
both sides can implement a 'message session' to assossiate a given call with
a given return, in the event the calls need to be associated (The particular
implementation I wrote was a chat-client, so the client didn't need to know
where the message from the server came from, but with soap, it's just as
easy to send a lively little hash with message-id, authentication(which you
need in your client too, if your client is a client-server), and anything
else you want to stick in it :)
All that being said, yes fork has some overhead issues (particularly if you
try to do a bunch, a single fork that simply listens and passes message back
to your main program isn't too bad, overhead-wise. Still, it's a good Idea
to fork early to have less process state to duplicate) A more efficient
implementation would use Perl's multi-threaded model, however it only exists
in perl 5.8 and isn't entirely stable from what I've seen, and I have no
Idea if SOAP is thread-safe :)
Perhaps an alternative to forking on every SOAP call you want to disregard
the return value of, would be to fork once at the beginning and use some
kind of IPC messaging system between your main client process and your child
and have the child simply perform the soap call, and be blocked until it
returns but not have to worry about being blocked in the main program.
From: Ryan Gammon [mailto:rggammon@...]
Sent: Wednesday, October 23, 2002 11:39 PM
Subject: Re: [soaplite] Asynchronous messaging
Paul Kulchenko wrote:
>Hi Ryan,The best answer I can think of here is to allow a soap::lite server to
>--- Ryan Gammon <rggammon@...> wrote:
>>But wouldn't it be nice if soap::lite servers could see that the
>>being dispatched to isn't going to return anything, and allow the
>>client to return immediately?
>How would you know it? There is no such information in method
optionally parse the same wsdl file used for the client, and use that to
determine return types.
>>Or alternatively, give a dispatched function theThe transports could be modified with a function that causes them to
>>ability to close the transport, and continue processing? Would the
>>soap::lite powers that be like to see such a beast?
>Don't see an easy way to do it without forking a process.
close on demand. I could call this function inside the method that has
been dispatched to. On returning from the dispatched method, the handler
of the transport in question would have to check to see if the transport
had already been closed for it.
>SOAP::LitePretty slick. That's the first time I've seen wantarray.
>does some optimization on server side (if dispatched call is done in
>void context response message will not be generated/serialized; used
>for POP3 server). Which means that you can overload HTTP transport
>and make a call in empty context, but still it will block before
>processing is complete.
>>This is one of the big questions I have -- is it proper SOAPThat is indeed what I found with my TCP server with the redefined handler.
>>not return a xml response? (as opposed to a response by the
>>mechanism, like a 2xx message in http -- that is definitely
>I would say yes. In fact, it was discussed several times and it seems
>like spec doesn't require response message to be present and it's ok
>to send empty response (for example only 200OK). SOAP::Lite supports
>this mode: you'll get undef instead of SOAP::SOM object in this case
>(unless fault was returned, but SOAP response is also optional in
>Hope it helps. I would like to discuss proper API for async calls,To unsubscribe from this group, send an email to:
>because I want it to be implemented consistently for different
>Best wishes, Paul.
>Do you Yahoo!?
>Y! Web Hosting - Let the expert host your web site
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/