Sam Couter wrote:

David Ripton wrote:

...

If you like the basic idea of SOAP (client/server RPC via XML over http), I think XML-RPC (which is basically an early draft of SOAP) is fine. Then feeping creaturism set in, and SOAP (plus the ring of associated cruft like WSDL) is no longer simple.

WSDL is one of the very few redeeming features of SOAP - it's the equivalent of CORBA's IDL, ...

... only it's in XML -- ooo, isn't that lovely! Not. 8^P IDL was more elegant.

... and allows you to define an interface and what types it expects. For languages less dynamic than python, the WSDL can be used to generate stub and skeleton code in an automated fashion.

Without WSDL, that code has to be written by hand. That's a menial, error prone and BORING task. Other RPC systems worked out not to do that decades ago.

For languages as dynamic as python, it allows code to dynamically interrogate an interface to find what functions it provides.

IMNSHO, these capabilities are okay, but very overrated. Stub and skeleton code is usually pretty trivial, and could be auto-generated using much simpler, more natural, and better-supported approaches than WSDL. Seen any WSDL tools lately? Me neither.

...

If pure request-response with just basic types is all you need, then either will work fine. (So will SOAP, or CORBA for that matter if firewalls don't preclude it -- there'll just be more docs to read.)

Both SOAP and CORBA allow you to define complex objects to be marshalled over the wire. Neither are limited to simple types. CORBA is not limited to simple request-response.

With CORBA the remote end can get a stub (object reference) that they can call remote methods on (callbacks). Object references can be passed back and forth all over the place, and the stub knows where to send the callback requests to find the original implementation of that object.

SOAP is value-object (structured data, no methods) only.

As far as I can tell, PB is a python-only equivalent to CORBA.

Not exactly, but I'll let the more PB-savvy types respond to this. Maybe Brian? ;) A very important distinction is that PB is, by design, not "transparent", as CORBA tries to be. One reason for this is that quite often it's important for your application to know what's remote and what's local. But hey, RTFM -- the PB howtos are pretty good, methinks! ;) - Steve

Stephen Waterbury writes:

Not exactly, but I'll let the more PB-savvy types respond to this. Maybe Brian? ;) A very important distinction is that PB is, by design, not "transparent", as CORBA tries to be. One reason for this is that quite often it's important for your application to know what's remote and what's local.

If your objects themselves already use a deferrable interface (otherwise you couldn't hide the object's use of callRemote which is asynchronous), it's also possible to wrap such references so they can be used more transparently. We were able to come up with a mix-in remote class that handled this transparently for our objects, with occasional custom handling of individual methods on the remote side (mostly those that needed to wrap their own results). To me, another really important distinction between PB and CORBA is that object references do not survive the lifetime of the network connection on which they were created, even if the objects themselves continue to exist on the machine where they were instantiated. It's been a while for me, but with CORBA I believe an IOR can always be used to connect and execute calls against an object even across multiple connections to the machine where the object is instantiated. While actual object IDs retrieved from binding are transient, brokers can implement automatic rebinding (since the original name remains valid) across network outages. That PB invalidates such references does make some sense in that otherwise the side of the PB connection that handed out the reference might be the only reason keeping the object alive within that Python runtime, but it does introduce complexity in dealing with network outages. In our case, it's been a driving force towards defining which objects are returned as references (only those for which there are natural "lookup" points in the application on which a network failure/retry mechanism can be hung) and which are returned as copies, and how we perform updates to such copies (sending back the new object as another copy rather than using a reference to it). I'd love to see a graceful persistent object reference scheme added to PB, but there are a number of issues to think about for any such system. Note also that this does not mean that PB isn't extremely good at what it does do, since it is, and we're definitely using it. To me, much of the strength of PB compared to other remoting approaches is its simplicity and straight-forward nature due to choices of what to support and not support (like not trying to be transparent or persistent). -- David

Glyph Lefkowitz writes:

On Wed, 2004-07-07 at 11:30, David Bolen wrote:

...

I'd love to see a graceful persistent object reference scheme added to PB,

In the next version of PB, URLs are a part of the connection structure, and so persistent object references can be accomplished by publishing a URL.

Sounds promising... Next version as in CVS somewhere or just plans at this point? Might it also come with a broker that would automatically re-establish an object's connection if a dead remote reference were used (presumably it would require remote references to also keep track of their original URL used)? -- David