OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: XML over HTTP: SOAP and ...?

[ Lists Home | Date Index | Thread Index ]
  • From: "Steven Livingstone" <s.livingstone@btinternet.com>
  • To: "Tom Scola" <Thomas.Scola@us.rbcds.com>, <xml-dev@XML.ORG>
  • Date: Wed, 8 Mar 2000 00:40:49 -0000

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/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS