[FoRK] [Twisted-Python] Re: Spread or SOAP (fwd from
eugen at leitl.org
Wed Jul 7 08:49:57 PDT 2004
----- Forwarded message from David Bolen <db3l at fitlinxx.com> -----
From: David Bolen <db3l at fitlinxx.com>
Date: 07 Jul 2004 11:30:33 -0400
To: twisted-python at twistedmatrix.com
Subject: [Twisted-Python] Re: Spread or SOAP
Organization: Fitlinxx, Inc. - Stamford, CT
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Reply-To: Twisted discussion stuff <twisted-python at twistedmatrix.com>
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).
Twisted-Python mailing list
Twisted-Python at twistedmatrix.com
----- End forwarded message -----
Eugen* Leitl <a href="http://leitl.org">leitl</a>
ICBM: 48.07078, 11.61144 http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
Url : http://lair.xent.com/pipermail/fork/attachments/20040707/2f6ae00f/attachment.pgp
More information about the FoRK