RE: What does WSDL describe?

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.

Case 2: If the dealer uses two separate forms for motorcycle versus car 
orders, then the dealer has a few choices on how to model its Web services:
a) It could offer one interface with one operation (SubmitOrder) which 
accepts an Order message that contains a choice of OrderForm1 or OrderForm2:
   <element name="Order">
      <complexType>
          <choice>
             <element name="OrderForm1" type="OrderForm1"/>
             <element name="OrderForm2" type="OrderForm2"/>
           </choice>
       </complexType>
    </element>
b) It could offer one interface with two operations (SubmitMCOrder and 
SubmitCarOrder), with each accepting an input message of OrderForm1 and 
OrderForm2 respectively.
c) It could offer two interfaces each with one operation (SubmitOrder) 
which accepts OrderForm1 and OrderForm2 respectively.

But regardless of what interface model it chooses, the SOAP node receiving 
the message needs to know what to do with the input message. As long as the 
message signature is unique, a SOAP processor should be able to determine 
how to route the message. If the message signature isn't unique, then I 
suppose the SOAP processor will dispatch it to a catch-all service which 
will determine how to route the message based on the flag within the 
message. Either way the service provder makes a decision as to what level 
of message signature uniqueness is required.

Anne



At 05:49 AM 10/24/2003, Savas Parastatidis wrote:

>Paul,
>
>(apologies for the long message that follows... a real-world example is
>included)
>
> > > I don't think that a WSDL document says anything about the semantics
>of
> > the message exchanges or the semantics of the message contents.
> >
> > OK WSDL doesn't /formally/ specify semantics, but well thought out
>names
> > such as 'ISBN', ZipCode', 'getAccountDetailsByCustomerId' can be used
>to
> > impart a lot of meaning to a human operator.
> >
> > Telling people they're not to take any meaning from names used in WSDL
> > would seem a bit restrictive to me.
>
>I see Web Services technologies as the "glue" between platforms. They
>provide the means for integration between organisations. Unlike a closed
>system where we have control over the type system (e.g., sharing of
>object types and their semantics), in cross-organisation interactions we
>don't have such control. A well-thought-out name may give us an
>indication of what may happen but it's not a guarantee. In a closed
>system, we do have that assurance because we are in control. In WSA, we
>are not.
>
>Hence, the only thing we can be certain of is the validation of messages
>and the message exchange patterns involved.
>
>I see from many messages in this and other discussion lists that many
>people make the association between a WSDL "operation" and a method on
>an object at the other end. Again, that's because the current tooling
>out there has forced us to think of web services as objects with
>methods, so we tend to think of the messages being exchanged as a
>representation of methods, hence the use of terms like "argument",
>"operation", etc in discussions. In fact, we just exchange documents
>that the service knows how to interpret and how to process.
>
>Please note that I am not suggesting that nothing happens at the service
>end upon arrival of a message. I am merely saying that it doesn't have
>to be a computer running an object-based program with methods being
>invoked; or procedures; we just don't know and I believe we shouldn't
>care. There may be a fast typist that types XML and sends it back. The
>XML returned to us may not make any sense semantically but _it_is_ valid
>since adheres to the only thing that we, as consumers, have agreed with
>the service (the structure of the message exchanged). And in these cases
>we don't have control of what goes on.
>
>I believe that SOA is all about document exchange through messages and
>the services are responsible for processing those documents. Please
>allow me to use an example from the real world to illustrate what I
>mean.
>
>Let's take a car/motorcycle dealer. The dealer offers either...
>
>1. A single order-form that can be used to order either a car or a
>motorcycle (OrderForm1).
>
>2. Two different forms for each (OrderForm2 and OrderForm3).
>
>Let me start from case 2...
>
>In order to find out which form we have to use, we have to use some
>out-of-band mechanism (e.g., phone call, the web, word of mouth, etc.).
>Someone will tell us... We may not depend on the name of the form to
>make a choice. Also, when you fill in the appropriate form, you don't
>call an "operation" on the dealer. You just send the form (e.g., fax it,
>post it, deliver it in person, etc.). The dealer knows what to do with
>the form. If an OrderForm2 is received, it means the order is for a car.
>If an OrderForm3 is received...
>
>If a third party sees the order form while in transit from the customer
>to the dealer, there may be no way of telling whether it's for a car or
>a motorcycle. Perhaps the form is descriptive enough for them to get an
>idea, but there is no guarantee. The customer and the dealer, however,
>have agreed, through the out-of-band mechanism, about what is going to
>happen.
>
>Relation to WSDL: OrderForm2 is the document being exchanged. The
>structure of the document is defined by the dealer. The response will be
>an invoice or an out-of-stock-for-that-colour document.
>
>Now, let me go to case 1...
>
>This is relevant to the discussion about the uniqueness of the message
>on the wire. I am not going to argue about what the WSDL group should do
>and its relation to WS-I. However, this example attempts to demonstrate
>how it could be possible for a service to determine what to do upon a
>receipt of the same document in two different situations.
>
>There is only one form (OrderForm1). The structure of the document is
>the same whether you buy a car or a motorcycle. However, there are two
>"tick" boxes that allow you to specify whether you want one or the
>other. Although the form is the same, the dealer knows how to process it
>accordingly because it can interpret the contents of the document and
>make the appropriate business decision.
>
>We didn't send a document called "Buy a car" or "Buy a motorcycle". We
>just sent a document called "OrderForm1". It's the business logic at the
>service end that decides what needs to be done, although to an observer
>the format of the document in transit was not different in either of the
>cases.
>
>Relation to WSDL: the same document structure could be allowed in two
>different message exchanges, if the service is prepared to make the
>distinction. It's the business logic that's going to determine what's
>going to happen.
>
>
>Again, apologies for the long message. I am interested in reading
>people's views.
>
>
>Regards,
>.savas.

Received on Saturday, 25 October 2003 14:34:35 UTC