[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML over HTTP: SOAP and ...?
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@x... [mailto:owner-xml-dev@x...]On Behalf Of Tom Scola Sent: 07 March 2000 18:25 To: xml-dev@x... 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@x...&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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|