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

Hi Amy!

> [why is this being cc'd to the distributed objects mailing 
> list at acm? 
> do they want to see it?]

"They" in this case is Mark - that's his email addy. :)

> > > It establishes sequence and content of messages that are related.
> > 
> > OK, sounds good.  So why do we care about that?
> 
> Historical reasons.  There's no particular justification for 
> it, if you've got a higher-level choreography/flow language 
> that associates messages in a more sophisticated fashion.  
> All you'd really need then is to model each message inside an 
> "input-only" or "output-only" operation, and leave 
> correlation to the higher-level language.

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.

Continuing on...

> 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.

> There is, as Jim sapiently noted, *no* *expectation* that a 
> particular method, procedure, function, process, algorithm, 
> or fast tango will be performed when a particular message 
> arrives.  Note that the whole notion of strongly mapping to 
> methods/functions/whatever (but not latin dances) is strongly 
> tied to the use of the request/response style, which more or 
> less (a great deal less, imo&e) parallels the processing that 
> happens in a stack-based computer language.  For other 
> networking styles (particularly output-first operations), it 
> is much less easy to make a mapping at all.

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.

> Message comes in, message goes out, what happens in between 
> deponent sayeth not.  Message goes out, message comes in, 
> what happens in between deponent sayeth not.  Message goes 
> out.  Period.  Nothing to say, is there?  Message comes in.  
> Period.  There may be something to say, or there may not, but 
> the WSDL spec *ain't sayin' it*.

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.

> "message exchange pattern" is a much better term than 
> "operation", but we *don't* want to end up in another 
> argument about naming, please the gods of small forest pools 
> and sandy ocean beaches.

Whatever - as mentioned above I'm much less concerned about what you
call it than about what it is and why you bring it into being in the
first place.

--Glen

Received on Monday, 23 February 2004 14:15:04 UTC