SOAP frustrations

Christopher Browne cbbrowne at acm.org
Thu Oct 17 13:01:10 EDT 2002


The world rejoiced as paul at boddie.net (Paul Boddie) wrote:
> Christopher Browne <cbbrowne at acm.org> wrote in message news:<aojsqj$ms9tp$1 at ID-125932.news.dfncis.de>...
>> Perl's SOAP::Lite takes, to my mind, the /right/ approach to this; it
>> creates what the implementors call a "SOM" object which is essentially
>> a 'parse tree' of the XML message.
>> 
>>    $foo = some_soap_call(arguments);
>>    print $foo->result(), "\n";   # Prints the result
>>    print $foo, "\n";             # $foo is an object containing the
>>                                  # parse tree...
>
> Well, unless "SOM" is interoperable with the DOM, I don't think it's
> entirely the right approach. I've been using various Java APIs to do
> SOAP stuff, and someone at Sun clearly decided that instead of
> exposing a normal DOM interface to SOAP messages, they would invent
> another API which is very similar but incompatible. If it weren't
> for Jaxen (the XPath package for Java) stepping in to save the day,
> I'd be at an even higher point of irritation with JAXM than I
> already am.

I'm not sure if "SOM" is interoperable with anything at all, and I
frankly don't care.  It's easy enough to work with, if we consider the
evils of doing recursive tree walks in Perl to be a "stipulated
given."

The point is that it involves keeping the XML parse tree, which is the
Right Thing, as opposed to parsing it and throwing the XML data away,
which is the Wrong Thing that naive SOAP implementations do.

>> The problem with many of the SOAP implementations (including those for
>> Python) is that the call to the result() method is implicit, and you
>> /never/ get a chance to intercept the XML so as to be able to do more
>> sophisticated things with it, such as looking for encrypted portions
>> and decrypting them...

> My unfashionable opinion is that if you want to do RPC, especially if
> other languages are involved, then CORBA is a mature enough technology
> that probably won't be as frustrating as SOAP to use or to deploy.

There's one problem with CORBA: It's nastier to get it through
firewalls, because there are lots of reasonably interoperable HTTP
proxies, but IIOP proxies are much rarer.

Of course, SOAP has /no/ "call-back" approach, so its functionality
"bottoms out" rather quickly...

Note that I've books in print that demonstrate the use of both CORBA
and SOAP using Python; while "future royalties" commend the idea of my
commending interest in SOAP, I certainly prefer CORBA...
-- 
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://cbbrowne.com/info/publications.html
"The nice  thing about standards  is that you  have so many  to choose
from.  Furthermore, if you do not  like any of them, you can just wait
for next year's model."  -- Tanenbaum, "Computer Networks"



More information about the Python-list mailing list