W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2003

RE: What does WSDL describe?

From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
Date: Fri, 24 Oct 2003 10:49:16 +0100
Message-ID: <BC28A9E979C56C44BCBC2DED313A4470021C38B5@bond.ncl.ac.uk>
To: <paul.downey@bt.com>, <www-ws-desc@w3.org>
Cc: "Jim Webber" <jimwebber@hotmail.com>, <distobj@acm.org>

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 Friday, 24 October 2003 05:49:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:27 GMT