xml-dev - RE: XML over HTTP: SOAP and ...?

["Steven Livingstone" <s.livingstone@btinternet.com>]

If this is the case, then why are there so many problems with integraing
disparate systems? All of what you have mentioned has been available for a
long time, yet is not a popular technique.

I think what your RPC and SOAP protocols offer is a simple (non C/C++
orientated) way of integrating distributed systems. Everything goes over
HTTP - that's it. The more transparent it is, the quicker it will take off.
Hell, could we not have used SGML rather than XML now? Or SGML before HTML?

I think these lessons illustrate why such protocols are successful.

cheers
steven

-----Original Message-----
From: owner-xml-dev@xml.org [mailto:owner-xml-dev@xml.org]On Behalf Of
Tom Scola
Sent: 07 March 2000 18:25
To: xml-dev@xml.org
Subject: Re: XML over HTTP: SOAP and ...?


Mark Birbeck wrote:

> The main difference here is that you could write a SOAP implementation
> in a weekend - you couldn't do the same for WebDAV!

There's a big difference between SOAP and WebDAV.  DAV is an actual
protocol that does work -- once you've developed DAV, you're done.  SOAP
is just a framework -- once you've developed SOAP, you still have to
develop your application on top of it.

Pardon my naïveté, but I'm having a problem understanding the need for
so-called "lightweight" protocols such as XML-RPC and SOAP in the first
place.  If I wanted to write a distributed XML application I can:

1. Open a socket to a remote system
2. Authenticate the connection
3. Send and receive XML-encoded data over the socket

Step 1 requires about 10-20 lines of C code, or about 2-3 lines of perl
or python.  Step 2 is complicated, but thankfully there are already
libraries for that sort of thing such as openssl or cyrus-sasl.  Step 3
is where most of the work takes place, and requires exactly the same
amount of development time whether you're writing over a SOAP API, or
using sockets directly.

Don't try to tell me that the SOAP API makes writing programs easier.
What could be easier than "send" and "recv"?  Every RPC API I've ever
used has made network programming *more* difficult in the long run,
since they obscure network connection and timeout problems.  These
problems will probably outweigh the 2 man-days of development time you
thought you saved by using SOAP.

Don't try to tell me that SOAP makes it easier to traverse firewalls.
It does, but is that really a benefit?  Remember, SOAP is not a real
protocol, it's just a framework.  Every time you write an application on
top of SOAP, you're implementing a new protocol.  Every protocol that
traverses your firewall should be subject to an audit; writing socket
code makes that explicit.  Writing SOAP code is merely a means of
bypassing your company's security policy.

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************