Re: 2004-02-12 Action Item: Clarification to the OperationName feature

On Mon, 23 Feb 2004 13:59:37 -0500
Glen Daniels <gdaniels@sonicsoftware.com> wrote:
> OK, before I go on here I'm going to put forth my opinion at this
> point. I think WSDL is precisely about tying messages (data) together
> into operations.  That's why we have it at all, and don't just use
> schema/relax.  It *is* a choreography/flow language, and to tell you
> the truth I wish there were more direct commonality between it and
> beasties like BPEL.  It accounts for tying messages together into
> related groups, which have some INTENT behind them.  Now if you say,
> abstractly:
> 
> [ Message A goes in and Message B comes out ]
> 
> and also
> 
> [ Message A goes in and Message C comes out ]
> 
> ...whether you think of it as an "operation" an "interaction" or even
> a"message exchange", I believe you still want to know WHICH ONE you
> are actually using.  Otherwise, why bother?  Imagine Message A is a
> purchase order.  If the first exchange/operation is "validate PO",
> then Message B might be simply "OK, valid".  On the other hand, the
> second exchange/operation might be "submit PO", in which case Message
> C might be a completed invoice.  Sure would be nice to differentiate.

Sure.  *If* a WSDL author writes a description in which the message
body's qname is ambiguous, then there *ought* to be a way for that
author to provide some additional information to permit disambiguation.

Sounds like an *optional* feature to me.  Certainly not a required
feature, and double-plus certainly not a required feature with the
required semantic that the operation name appears in a particular
location.  As an optional means of disambiguation, I'm all for it.  As a
required feature, it's a burden on the folks who don't care (who have
OOB information to disambiguate, for instance), and twice a burden by
proposing a single algorithm for disambiguation.  A particular WSDL
might make it a required feature; other WSDLs may ignore it entirely.

> > WSDL 1.1 didn't have such a beast available, so it defined 
> > simple operations, some of which represent Very Well Known 
> > idioms (client/server request/response on a single 
> > connection, in particular). 
> > Now, given that I've been the champion of several MEPs that 
> > are less universally ubiquitous than that one, and an editor 
> > of part two, you might expect me to defend the things 
> > ferociously, but ... they're just icing.  Useful for simple 
> > definitions, and most definitions are simple.
> 
> They are definitely not "just icing", because the fact is people are
> actually using them right now for things which matter.

*shrug*  Given a sufficiently mature flow language, it would be
perfectly feasible to define a WSDL with all operations as input-only or
output-only.  I agree that they're necessary in the current state of the
art, but not that they're particularly critical to WSDL on the whole.

> Of course WSDL doesn't say *what* happens (a method gets called, a
> message gets pulled out of a database, whatever) behind the scenes of
> a particular exchange.  By calling out that an operation/exchange
> exists in WSDL, we indicate that said exchange exists as an entity in
> our minds as humans.  I don't care that a particular thing happens in
> any implementation, I care that we have an abstract concept (a
> particular operation) which HAS MEANING.

The meaning is that this format of request gets this format of response
(since it's almost always request/response that we're talking about
here).

> Again, there is a reason we have operations to tie together message
> exchanges (even one-way message exchanges) into named packages.  If
> there wasn't, we wouldn't do it at all and would just have a big bag
> o' schema.

Not sure that I agree.  Certainly, we could simplify WSDL by providing a
decorator attribute wsdl:message="true" on a schema, then supply binding
information and endpoints.  But there's always more than just a bag,
even if there isn't a hyperfocus on request/response exchanges construed
as method calls on objects or remote procedure calls.

Or, in sum: I think it's fine to have an optional feature that can
disambiguate operations that have the same qname.  I don't accept a need
for a required feature (that is, required for all WSDL instances, as
opposed to making the feature required in a particular WSDL).  I
particularly don't accept that the algorithm based on operation name is
the only way to do it.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Monday, 23 February 2004 16:17:51 UTC