- From: Doug Bunting <db134722@iPlanet.com>
- Date: Thu, 14 Mar 2002 22:32:29 -0800
- To: <www-ws-arch@w3.org>
Mark, It seems you're raising a basic architectural point against SOAP while also invalidating most of the web services work (since before it got that name). SOAP and everything developed on top of it is providing a generic service (mostly packaging and transport infrastructure for SOAP itself) to higher layers in the application stack. At the SOAP layer, it doesn't know whether the payload contained will create a purchase order, update one or delete one. Higher layers don't know the transport SOAP will use and wouldn't know when to describe the appropriate HTTP action. These software design efficiency arguments are somewhat specious and could be closed by saying "why not?" if they didn't remove dependencies between the application layers. Onward... Yes, HTTP POST is a wonderful transport for carrying XML and other payloads to and from your application. POST has almost always been more appropriate for dynamic parameters from the client than GET. Security, privacy (visibility of sent information) and usability play a big part when systems start getting used. While this may not have been the original intent when HTTP 1.0 (or 0.9) was written, it's how the web is used today. Even without that rant, what I fail to understand is why POST is inappropriate for outbound XML documents. Most of the SOAP messages sent on the outbound HTTP hop (when using that binding) actually do cause changes at the receiving end, far beyond notations in the web server log. They almost never create new addressable resources at the receiver. This seems to be the essence of POST. While a few trivial cases could be handled through GET and a few parameters in the URL, trivial web services don't help the Business Infrastructure needs where ebXML Messaging and D-AG0017 sit. thanx, doug ----- Original Message ----- From: "Mark Baker" <distobj@acm.org> To: "Krishna Sankar" <ksankar@cisco.com> Cc: <www-ws-arch@w3.org> Sent: Thursday, March 14, 2002 9:05 PM Subject: Web architecture Hi Krishna, > Mark, > > I fail to understand your issue with ebXML and BTP for that > matter. They follow SOAP over HTTP. The points you are raising are basic > to SOAP over HTTP rather than to BTP or ebXML. That's true. There are BTP and ebXML specific points, but I think it's important that the one overriding Web-services/Web architectural mismatch be addressed before talking about them. > Also your term "web services protocol" is a little vague. Isn't > it SOAP/HTTP ? There is no "web services protocol" per se. Basically anything that isn't a data format. i.e. not WSDL, etc.. > Third, what exactly is wrong ? They use HTTP POST as a transport > mechanism, which looks Ok to me. It's not ok if you want to conform to Web architecture. POST is a *method*, in the same way that getStockQuote() is a method. Would you consider it ok if I did this? getStockQuote( 'getWeatherReport( "OTTAWA" )' ) If not, then consider that when you do; POST ( "getStockQuote()" ) that you are doing *exactly* the same thing. > I will lok into the issue of BTP introdicung new application > semantics. My first impression is "why not". But it is a WAG, I will dig > into it and think more, in the mean time would appreciate any thoughts. Introducing new application semantics isn't a bad thing. But introducing them in a Web architecture friendly way is difficult because you're working with *existing* application semantics; those of the Web, in this case. These protocols I've seen all assume that they're working with a clean slate, because they see HTTP as a transport protocol, which it is not. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Friday, 15 March 2002 01:32:31 UTC