SOAP frustrations

[Christopher Browne]

After takin a swig o' grog, grahamd at dscpl.com.au (Graham Dumpleton) belched out...:
> Derek Thomson <derek at wedgetail.com> wrote in message news:<tS7r9.452$i84.53205 at news.optus.net.au>...
>> Andrew Dalke wrote:
>> > 
>> > It's such that the more CS-y people at my client's site believe that
>> > web services in Python are still very immature and want to switch the
>> > project over to Java and WebLogic(!).  (I did point out that developing
>> > the library I did was still less time than setting that up, but there
>> > are other factors in the mix as well.)
>> 
>> I think most CS-y people believe that web-services themselves are very 
>> immature, and are likely to remain so for a while yet.
>
> As far as the Internet goes I would probably agree on that point. After all,
> there aren't exactly many (any?) web services of any great significance which
> are generally available over the Internet through only a SOAP or XML-RPC
> interface. Where such SOAP or XML-RPC interfaces exist, they in general
> merely add something on top of what is an existing browser based service.

The /eventual/ intent is for SOAP to do something much more ambitious
than XML-RPC, namely to have a single interface that provides /two/
forms of functionality:
  a) An RPC scheme (not unlike XML-RPC or CORBA), and
  b) A way of transferring substantial XML documents around in a
     'verifiable' way.

The latter is pointed to by the hordes of 'layered standards' that
take over where WSDL leaves off, where you can do things like
attaching digital signatures and encrypting portions of documents.

> The problem in the Internet arena is that you are asking too much in
> putting up a web service on the Internet, publishing your WSDL and
> expecting people to write their own clients. Yes it may work for
> very simple stuff like Google searching or stock quote services, but
> not for anything too much more complicated than that.

Indeed.  There's a lot that people don't "get" about it...

> Where web services make more sense at this point is on company
> Intranets where the application developers can also build and deploy
> the clients which might make use of such systems in a meaningful
> way. Even in this setting I still don't see services relying purely
> on XML-RPC or SOAP type protocols for communications. What is a
> better mix is to use more traditional frameworks for interprocess
> communications and/or messaging and have these web based protocols
> more as a convenience for accessing a restricted set of interfaces
> of a system as a whole.

The place where it's liable to "come into its own" is when BizTalk
interfaces start popping up; they'll be transferring around big XML
documents to describe accounting transactions, and you might as well
use SOAP to transfer around something that is a big XML document.  The
only alternative with any merit would be a message queueing system
like MQSeries (or M$FT's clone, called MSMQ)...

The interesting thing is that at /that/ point, you would no longer
want to treat SOAP as an RPC scheme, where the use of XML is being
hidden under the table.  You want to have the contents of the message
provided as an XML message; perhaps as a 'raw' stream of bytes, or as
a parsed XML document object that you can "walk" through.

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.

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

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...
-- 
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/sap.html
Rules of the  Evil Overlord #126. "Rather than  having only one secret
escape  pod,  which  the  hero   can  easily  spot  and  follow,  I'll
simultaneously launch a few dozen decoys to throw him off track."
<http://www.eviloverlord.com/>