SOAPpy and callback

[Paul McGuire]

"Diez B. Roggisch" <deets at nospam.web.de> wrote in message 
news:4parepFho4q7U1 at uni-berlin.de...
> Maybe we have a misunderstanding here. I'm not a native speaker, so bear 
> with me.
>
That's okay, I'll type very, very slowly.  :)

> In CORBA or RMI, there is a notion of an object/interface reference passed 
> around, which allows for callbacks in a natural way. Which is AFAIK not 
> the case in SOAP. Hell, they don't even know objects and stateful 
> connections...
>
Are you confusing SOAP with REST?  The standard I refer to defines a set of 
WSDL files that can be crunched to build implementation bindings for C#, 
Boo, Java, etc. (Unfortunately, not Python - there is some issue with SOAPpy 
that will not handle the input WSDL.)  These bindings do model the remote 
interface bindings as objects, and stateful connections and sessions are 
very much part of the standard.  If you like, you can download the WSDL 
files at http://dom.semi.org/web/wstandards.nsf/supmaterials.

It is true, the implementation of the callback in SOAP is quite crude, as it 
exposes the callback as an endpoint wrapped around a URL string.  Not very 
object-y at all - but then think back to CORBA again, and many systems did 
something similar by passing around names bound to objects in a nameserver, 
or just cut to the chase and shipped IOR's around directly.

> That you obviously can define a system that needs several SOAP servers to 
> interact with each other - well, you could also perform inter process 
> communication using printed documents, some horses and either OCR or data 
> typists. But this isn't exactly inter process communication in my book, 
> albeit there certainly _are_ processes, _and_ communication :)
>
About 10 years ago, the standards body for semiconductor process integration 
*was* using IDL to define process interfaces, and defining CORBA 
implementation bindings.  Unfortunately, the CORBA learning curve was too 
much, and the implementations were too expensive (at the time; today ACE and 
omniOrb are reasonable platforms).  The group today went with SOAP, defining 
a set of WSDL files to serve as the standard interface definition, in place 
of the CORBA IDL of yore.

And what you describe might still be a step up from the RS-232-based system 
in place today (instituted in the 70's, upgraded to ethernet in the late 
80's, but still limited to encoded ASCII and point-to-point connections).

I would definitely agree that working with callbacks in SOAP sometimes feels 
like an unnatural act.  But it is clearly an interprocess communication, and 
it does have an object model to its language bindings. Any Rube Goldberg 
aspects to SOAP are neatly buried in the code generated from the WSDL.

-- Paul