- From: Edwin Khodabakchian <edwink@collaxa.com>
- Date: Tue, 26 Mar 2002 18:53:36 -0800
- To: "'Mark Baker'" <distobj@acm.org>, "'Jacek Kopecky'" <jacek@systinet.com>
- Cc: <xml-dist-app@w3.org>, "'Stuart Williams'" <skw@hplb.hpl.hp.com>, "'Noah Mendelsohn'" <noah_mendelsohn@us.ibm.com>, "'David Fallside'" <fallside@us.ibm.com>, <www-ws-arch@w3.org>
Mark, If the "meaning" of the message is defined at the transport layer, what happens if I need to deliver the same "request/message" using SMTP or JMS as the transport? Thanks -----Original Message----- From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On Behalf Of Mark Baker Sent: Tuesday, March 26, 2002 6:20 PM To: Jacek Kopecky Cc: xml-dist-app@w3.org; Stuart Williams; Noah Mendelsohn; David Fallside; www-ws-arch@w3.org Subject: Re: What is SOAP? Hey Jacek, > a) an extension of the web (or HTTP), or > b) an RPC request/response protocol on top of *a transport > layer*, or > c) simply a messaging protocol with basically every message > being one-way (again, on top of a transport layer). > > I think the original Abstract Model [1] assumed (c), I think that > many of our audience still (unfortunately) assume (b), and I think > Mark Baker assumes (a) (at least I haven't noticed another strong > proponent of (a)). I believe that the majority expectation is also > (c). I believe SOAP is c), but that a) is a special case of c) where the meaning of the message transfer is inherited from HTTP (just to compare apples-to-apples with your a). [snip] > AFAIK, the history of SOAP is the transition from (b) to (c). > I don't think there is a possible transition from (c) to (a) > other than starting from scratch. And I don't think (a) and (c) > can be combined simply and nicely. IMO, there is definitely a transition. The chameleon view is about making this transition, but assigning meaning to the sending of a SOAP message, where that meaning comes from the method used in the underlying protocol. In fact, c) by itself is insufficient with which to get any work done, because no meaning has yet been assigned to the sending of the SOAP message. What most people currently do is put the meaning within the envelope, such as is done here (not to pick on Gudge, but this is a simple and illustrative example); http://www.xml.com/pub/a/2002/02/20/endpoints.html The example I had in mind is this one; <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"> <soap:Body> <pre:Add xmlns:pre="http://example.org/lists" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding" > <person> <name>Hayley</name> <age>30</age> </person> </pre:Add> </soap:Body> </soap:Envelope> Here, we see the meaning of the message "Add" in the message itself. A chameleon version of this with SOAP/HTTP would be; <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"> <soap:Body> <person> <name>Hayley</name> <age>30</age> </person> </soap:Body> </soap:Envelope> What happened to "Add" and the URI? Well, HTTP POST roughly means "Add", and the URI, "http://example.org/lists" is what you POST to. Any clearer? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Tuesday, 26 March 2002 22:02:29 UTC