- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Tue, 26 Mar 2002 19:26:36 -0500
- To: xml-dist-app@w3.org
- Cc: www-ws-arch@w3.org
> -----Original Message----- > From: Jacek Kopecky [mailto:jacek@systinet.com] > Sent: Tuesday, March 26, 2002 6:07 PM > To: xml-dist-app@w3.org > Cc: Mark Baker; Stuart Williams; Noah Mendelsohn; David Fallside; > www-ws-arch@w3.org > Subject: What is SOAP? > > > it is now obvious now that serious disagreement comes from the > lack of the basic definition of what SOAP actually is - > > 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 of SOAP 1.2 as c), although SOAP 1.0 was b) and 1.1 is somewhere between b) and c). Ideally, 1.2 should be general enough to be useful for both use cases a) and b). I'm not sure that SOAP is *necessary* for use case a) -- URIs to identify services, and some specific XML format to return results would suffice -- but for practical reasons it may find use there. For example, applications and tools might want to support a relatively seamless transition between RPC and REST for the environments that they are most appropriate: a tool such as VS.NET or WebLogic Workshop might use a common UI to generate web services and let the user choose among synchronous, callback, and REST options to generate the actual message exchange pattern. Does this make sense, or am I pretending that the world is cleaner than it really is?
Received on Tuesday, 26 March 2002 19:26:37 UTC