Re: [Twisted-Python] Spread or SOAP
Mr. Ripton, Thank you for your very kind and helpful response. I will most definitely give PB a spin since my project is in-house and thus I can run Python on both sides of the conversation. I didn't realize that SOAP is Microsoft FUD, as I thought SOAP is a W3C standard. Is W3C the committee that Microsoft is trying to manipulate? Thanks again for your hepful feedback. Python really rocks the world and I think will continue to do so for a long time to come. Sergio
From: David Ripton <dripton@ripton.net> Reply-To: Twisted discussion stuff <twisted-python@twistedmatrix.com> To: Twisted discussion stuff <twisted-python@twistedmatrix.com> Subject: Re: [Twisted-Python] Spread or SOAP Date: Mon, 5 Jul 2004 16:10:55 -0700
Hi, I'm new to Twisted and just discovered it today. It looks to be amazing and versatile. I want to use the Twisted Web server to receive an HTTP POST and when the POST comes in, I want to relay a message to another object that happens to be running on the same physical machine (although in the future it may not be running on the same machine). The message that will be sent will contain some basic data. To do this, should I use Spread with
On 2004.07.04 09:40:32 +0000, Sergio Trejo wrote: the
Perspective Broker for interobject communication (can I even do this from, say, a cgi application in Twisted Web server), or should I do something a bit more fancier such as using SOAP?
PB is excellent, within its range of applicability. If you control both sides, can choose Python, and prefer async operation, I highly recommend it. Yeah, it should be easy to integrate with other Twisted bits.
XML-RPC is reasonable, if you need cross-language support or more buzzword compliance.
SOAP is XML-RPC attacked by Microsoft and a committee. It's hard to read the specs without laughing, and harder to try to interoperate with someone using Microsoft's broken^Wenhanced implementation of it without crying.
But what did you expect to hear on a Twisted list?
-- David Ripton dripton@ripton.net
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
On 2004.07.05 21:19:13 +0000, Sergio Trejo wrote:
I didn't realize that SOAP is Microsoft FUD, as I thought SOAP is a W3C standard. Is W3C the committee that Microsoft is trying to manipulate?
I didn't say anything about FUD or manipulation. Microsoft and W3C committees are perfectly capable of producing absolute garbage even when aiming for something good. (Sturgeon's Law most definitely applies to software.) 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. I think PB is easier to use than XML-RPC, and (other than the Python requirement) more flexible. It allows passing general Python objects rather than just simple types, and supports asynchronous server-to-client callbacks over the original socket. 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.) -- David Ripton dripton@ripton.net
David Ripton <dripton@ripton.net> 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, 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.
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. -- Sam "Eddie" Couter | mailto:sam@couter.dropbear.id.au Debian Developer | mailto:eddie@debian.org | jabber:sam@teknohaus.dyndns.org OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C
Sam Couter wrote:
David Ripton <dripton@ripton.net> 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 <golux@comcast.net> wrote:
... only it's in XML -- ooo, isn't that lovely! Not. 8^P IDL was more elegant.
Definately. I'm not saying WSDL is better than IDL, I'm saying that WSDL is better than no interface specification at all.
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.
I use them in my day job (WebSphere). Microsoft's SOAP stuff has tools for WSDL also. But I believe IBM and Microsoft have various patents on WSDL processing, and as you say, WSDL isn't exactly nice. I haven't seen any Free tools for parsing WSDL. Apache's Axis libraries can generate it from Java classes and some extra type mapping information. Anyway, this has drifted off-topic, since it's not about PB anymore. No more from me. -- Sam "Eddie" Couter | mailto:sam@couter.dropbear.id.au Debian Developer | mailto:eddie@debian.org | jabber:sam@teknohaus.dyndns.org OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C
Stephen Waterbury <golux@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
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.
Glyph Lefkowitz <glyph@divmod.com> 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
participants (6)
-
David Bolen -
David Ripton -
Glyph Lefkowitz -
Sam Couter -
Sergio Trejo -
Stephen Waterbury