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

Re: Which operation?

From: Mark Baker <distobj@acm.org>
Date: Wed, 16 Jun 2004 07:00:25 -0400
To: Jim Webber <Jim.Webber@newcastle.ac.uk>
Cc: www-ws-desc@w3.org
Message-ID: <20040616110025.GL20032@markbaker.ca>

Hi Jim,

On Wed, Jun 16, 2004 at 11:41:35AM +0100, Jim Webber wrote:
> > 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 discovering.
> Why do messages need to be ambiguous?

Whoa, miscommunication alert!  They don't.  I was just saying that the
messaging model(s) that WSDL 2.0 seems to be supporting are ambiguous,
and needn't be.

> I can see how you can engineer a
> way of making a message ambiguous but in a real deployment messages
> would (or at least should) all be different from one another. A
> cancelOrder message will look different from a placeOrder message - no
> ambiguity.
> You may choose to assume that the receipt of two slightly differently
> populated placeOrder messages would imply an update to an order - or
> whatever semantics your service decides upon. But I still can't see
> anything ambiguous in this.

No, that doesn't sound ambiguous, as long as whatever is "slightly
different" about the messages can be tracked to the semantic difference
via the specification(s) associated with the processing of the message.
Aka, the message is self-descriptive.  As soon as a message isn't
entirely self-descriptive, ambiguity exists.

> Having just an orderMessage and the POST and DELETE verbs achieves much
> the same thing but couples you to that Web stuff.

Not sure what you mean there.

> > There is a better way!
> Yes you're right - the "processThis" model [1] rocks :-)

Exactly!  I prefer the extended processThis model; GET, PUT, processThis,
DELETE, but I'll take just processThis over the current model any day of
the week.

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Wednesday, 16 June 2004 07:00:39 UTC

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