SOAP frustrations

[Paul Boddie]

Christopher Browne <cbbrowne at acm.org> wrote in message news:<aojsqj$ms9tp$1 at ID-125932.news.dfncis.de>...
> 
> Therein lies a /critical/ problem in the design of the existing Python
> SOAP implementations; they take the approach that SOAP is 'just RPC,'
> so that the XML is trash to be thrown away.  Nothing could be further
> from the truth, as in many cases, if you throw away /any/ of the data
> in the message, you may have just trashed the message.

I agree. One of the biggest issues is that people think, "SOAP? Ah,
that's just RPC over the Internet where it doesn't get more
complicated than fetching stock quotes." [*] And they don't give it
any further thought. Yet in the situations where SOAP is most
interesting to use, it's as an XML document that one wants to see the
information.

I'd go further than that and state that in many situations, "end to
end" XML is extremely interesting, and that I can't understand why
people have to invent their own object model for every application
they write, especially when the object model they've invented doesn't
provide any more features than the DOM does, doesn't expose itself to
querying in the way that various XML technologies permit when used in
conjunction with the DOM, and especially when they're only packaging
data up as objects for purely obsessive purposes: "I'm not using
thousands of objects in my application - something must be wrong!"

> 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.

> 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.

Paul

[*] If a technology's usefulness can only be justified with "stock
quote" applications, then such a technology clearly isn't useful
enough to be widely adopted.