W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

Re: Which operation?

From: Mark Baker <distobj@acm.org>
Date: Tue, 15 Jun 2004 15:46:57 -0400
To: "Liu, Kevin" <kevin.liu@sap.com>
Cc: www-ws-desc@w3.org
Message-ID: <20040615194657.GF20032@markbaker.ca>

On Tue, Jun 15, 2004 at 08:12:57PM +0200, Liu, Kevin wrote:
> Hi Mark,

Hey Kevin,

> Can you elaborate why wsdl:operation is used to define the contract? To my understanding, the contract is the messages to be exchanged. Operation names provides some application semantics, but have no significance in the run time message. 

Well, as I see it, the contract is the thing that says "If you do this,
I'll do this for you".  For example, "if you send a company name to me,
I'll respond with a stock quote".  You can label that with an operation
such as "getStockQuote", or not, and include that operation in the
message, or not.  But in all those cases, the same contract exists.

> One might define some operation style (such as RPC style as defined in part 1)  to require that the top element of a message must be named same as the operation name, but the "contract" is still in the message schema. 

I don't believe that a schema transform can represent a contract.  An
example I like to use for this (any Godel Escher Bach fans? 8-), is a
service that an application exposes which returns the last fault raised
by the application.

Now consider if that service were to itself raise a fault; how does the
client distinguish that fault from the last fault raised by the app?
That's what a contract is supposed to define; there's a whole bunch of
metadata/signalling information out-of-band of the document payload that
has been methodically stripped away under the banner of Web services, in
the pursuit of a more loosely coupled architecture.  But none of that
changes the part of the architecture that affects the coupling, the
contract (the "connector" in software architectural parlance).  All it
really does is make for a very poorly self-descriptive messaging
infrastructure with an abundance of ambiguity, as we've recently been

There is a better way!

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Tuesday, 15 June 2004 15:48:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:41 UTC