- From: Anne Thomas Manes <anne@manes.net>
- Date: Mon, 27 Oct 2003 09:19:39 -0500
- To: Mark Baker <distobj@acm.org>
- Cc: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>, "paul.downey@bt.com" <paul.downey@bt.com>, www-ws-desc@w3.org, Jim Webber <jimwebber@hotmail.com>, distobj@acm.org
Mark Baker asked: > Would that still work if the operation were "SubmitDocument" rather than > "SubmitOrder"? Absolutely, because you aren't specifying the operation name on the wire. The service SOAP node determines how to process the message based on the message signature, which in Case 1 is an <OrderForm1> element. Somewhere -- as part of the configuration of the service (and usually defined in the wsdd file) -- the service SOAP node is told what to do when it receives an <OrderForm1> document. (Typically, it dispatches an agent application that knows how to process orders that conform to the OrderForm1 message structure.) Hence the message signature implies its associated operation. Tooling works much more easily if you have unique wire signatures for each operation (we've been discussing this topic in a different thread). At the moment, WS-Desc does not require unique message signature -- and in that case it's up to the service agent to figure out what operation has been requested. (I suspect that if WS-Desc doesn't require unique signatures, then WS-I will.) There's another thread that's asking whether we should change the element name "operation" to something like"messageExchange". Personally, I don't think it really matters what we call it (although I do have a preference for shorter names over longer names). The purpose of the element currently known as "operation" is to define the input, output, and/or fault messages that get exchanged in the course of a specific node-to-node interaction. (So maybe "interaction" would placate the opponents of "operation"? -- Whatever!). But back to the question that you asked in the subject line: WSDL describes a Web service. It describes - what the service does (its abstract interface) - how to communicate with it (the concrete protocols that it supports) - where to find it (its endpoint URLs) A Web service is a Web resource that performs one or more functions for other systems. The abstract interface therefore must define what functions it performs and what messages must be exchanged for each function. Note that the service provider (or perhaps the tooling that the service provider uses) determines the service's WSDL model. Anne At 07:45 PM 10/25/2003, Mark Baker wrote: >On Sat, Oct 25, 2003 at 02:34:28PM -0400, Anne Thomas Manes wrote: > > Savas, > > > > Thanks for providing an example to help us gel our thoughts. > > > > Case 1: If the dealer uses one form for both motorcycles and cars, one > > would assume that from a Web services perspective, the dealer offers one > > interface with one operation (SubmitOrder) which accepts as an input > > message (OrderForm1). As you say, the dealer's service understands the > > semantics of OrderForm1 and can determine based on the contents of an > > attribute or an element whether the order is for a motorcycle or a car. > > There's no need to specify the operation name on the wire because the > > receiving SOAP node knows what to do when it receives an OrderForm1. > >Would that still work if the operation were "SubmitDocument" rather than >"SubmitOrder"? > >Mark.
Received on Monday, 27 October 2003 09:20:17 UTC