[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Web Service: SOAP or {HTML + Servlets}?
Great question and very thought provoking answers so far. Here is my perspective as someone who has been strongly recommending SOAP to my clients for a year. Firstly, it does, as was said, have remarkably good framework support both in .NET and in the IBM Web Services Toolkit. This is a big help for my clients. Secondly, and more importantly, I always stress that I am not recommending Section 5 of the SOAP specification and that I am not recommending using it for RPC. As was also pointed out, that is just one way of using SOAP. Thirdly, I recommend binding SOAP to transactional messaging, not to HTTP (until something like HTTPR comes along). So what do I recommend it for? The use case is passing a complete transaction from one application to another. This is key to achieving integration without tightly coupling applications. It also ties the use of the protocol into the key application concept of an ACID transaction. When the application commits, part of what it does (or the middleware should do for it) is serialize the state of the transaction (the context, the references and the event name) into an XML document, wrap it in SOAP (do you wrap or wash messages with SOAP?) and put it on the queue. Note that the interpretation of the transaction is up to the receiver - another example of XML providing beautiful support for loose coupling. John Schlesinger SysCore Solutions -----Original Message----- From: Roger L. Costello [mailto:costello@m...] Sent: Tuesday, October 09, 2001 5:17 PM To: xml-dev@l... Subject: Web Service: SOAP or {HTML + Servlets}? Hi Folks, I have been looking at SOAP recently. Although its great fun to play with new technologies, I am struggling to see why I should recommend to my clients that they use SOAP rather than, say, HTML plus Java Servlets (or CGI, JSP, ASP, etc) to implement Web Services. Here are a couple of thoughts: 1. SOAP -> API-based architecture HTML + Servlets -> Document-based architecture SOAP is about enabling one application to invoke a method in another application by passing arguments. It's basically about enabling a (remote) subroutine call. Hidden behind the scenes is the construction of a SOAP XML document, and the passing of that XML document. From a document-based architecture point of view, the fact that the transport is an XML document is immaterial. Contrast this with the HTML + Servlet technology where an application creates an HTML document, which is sent to an application (servlet) for processing. This is a document-based architecture. I am dismayed that SOAP has gone the API-based architecture approach. I would have thought that the progression would be from HTML + Servlets (or CGI, JSP, ASP, etc) to XML + Servlets (or CGI, JSP, ASP, etc) A long time ago I saw the enormous benefits of document-based architectures. I switched from using API-based architectures to document-based architectures. I am extremely reluctant to regress back to an API-based framework. 2. SOAP provides a (very) loose framework for sending data/requests to a server. Basically, it leaves a bunch of "empty space" in the framework where you can put stuff: <Envelope> <Header> - put anything here </Header> <Body> - put anything here </Body> </Envelope> That's about the extent of the semantics of SOAP. Presumably, each vendor must define what elements can go in the Header element, and the semantics of those elements. Not a very attractive prospect from a cross-vendor point of view. On the other hand, if I were to implement Web Services using HTML + Servlets then the semantics of all the HTML elements are concretely defined. There is rich (standard, non-vendor-specific) support for things such as HTTP sessions, authentication, security, etc. None of this exists with SOAP. My vision of next generation Web Services is an XML-document-based architecture, with a well-defined set of elements. I envision the XML documents conforming to an XML Schema. I envision schema validation of the documents. I don't see any of this in SOAP. I'd like to use SOAP for implementing Web Services. It seems to be a fun technology to play with. But, in good conscience, I am real hard pressed to see any advantage to it over HTML plus Servlets (or XML plus Servlets). I am eager to be convinced otherwise, however. What are your thoughts on this? /Roger ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.xml.org/ob/adm.pl>
|
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
|