[Twisted-Python] Re: Spread or SOAP

[David Bolen]

Stephen Waterbury <golux at comcast.net> 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