Re: Action Item 2004-07-01 Solution to 168/R114

On Wed, Jul 14, 2004 at 12:12:51AM -0700, Martin Gudgin wrote:
> > On Tue, Jul 13, 2004 at 08:03:05AM -0700, Martin Gudgin wrote:
> > > > Nothing but interoperability problems can result from such an 
> > > > approach,
> > > > IMO.
> > > 
> > > I don't see any such problems. The WSDL tells you what messages the
> > > service accepts and what messages the service emits.
> > 
> > Exactly.  Information required to understand the semantics of the
> > message is in the WSDL, and not in the message; that's the definition
> > of non-self-descriptive.  
> 
> Err, WSDL doesn't describe the semantics of the messages, does it? Do we
> actually HAVE any langauges that can describe the semantics of messages?

Well, I don't mean some fancy-shmancy semantics description language
(whatever that might be).  I just mean a token which is meaningful to
humans, e.g. "getStockQuote".  I'm saying that if that token isn't in
the message, or unambiguously associated with some bit(s) in the
(perhaps extended) message, then it's not self-descriptive.

> > I'm sure I don't need to tell you how
> > interoperability is detrimentally affected by a lack of
> > self-description.
> 
> I don't understand. I, as a service, accept a given set of messages.
> When messages that are in that set arrive, I process them and maybe send
> other messages.

Yes.  But in doing that, you're doing more than you think you're doing
I believe.  You are meeting a contract.

Back to the canonical getStockQuote example ... if there is a shared
expectation on behalf of you - the service - and the client, that
submitting the string "MSFT" will result in a quote for that ticker
symbol being returned, then you have a contract with an operation.  My
claim, therefore, is that 'getStockQuote("MSFT")' is a more
self-descriptive message than "MSFT" because it includes a token which
declares the operation/contract the message is part of.

IMO, if you really want to do large scale computing with document
exchange, what you need is a contract that is common to all services.
Jim and Savas' implied "processMessage" is such a contract, and with
it you get to use "MSFT" as your message, *and* be self-descriptive
(albeit with the cost of stomping on some existing specs, which is the
part of their suggestion which I disagree with).

> > > I'm not pretending there is no operation.
> > 
> > Sorry, I didn't mean to address that comment to you specifically,
> > Gudge; I don't know what you believe in this respect.  But there are
> > others here who do believe that.
> 
> Actually, I'm with Jim Webber. I think that for some classes of service,
> operation is largely illusory, being just a WSDL level construct for
> grouping together messages in an exchange. I'm also happy that there are
> services for whom there is a strong relationship between the operation
> name and some XML element in the input message. I just want to be able
> to describe both kinds of services ( and others ) with WSDL.

I'm with Jim too, I just think he misspoke.  I don't believe, nor do I
think he believes, that the operation can ever be illusory, because
without it communication cannot occur.  It's just that sometimes it's
not in the message (keeping in mind, as above, that there are both
self-descriptive and non-self-descriptive ways to hide the operation
from the message).

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.

Received on Wednesday, 14 July 2004 12:28:06 UTC