RE: MEP proposal

> -----Original Message-----
> From: Amelia A. Lewis [mailto:alewis@tibco.com]
> Sent: Friday, February 21, 2003 10:43 AM
> To: Assaf Arkin
> Cc: jacek@systinet.com; mgudgin@microsoft.com;
> jeffsch@windows.microsoft.com; www-ws-desc@w3.org
> Subject: Re: MEP proposal
>
>
> On Fri, 21 Feb 2003 10:30:35 -0800
> "Assaf Arkin" <arkin@intalio.com> wrote:
> > If I was to explain these MEPs to someone in isolation, then the obvious
> > questions would be: why only two nodes? why can't we have more
> complex MEPs?
> > what about if/else, multiplicity, etc?
>
> Umm, I get really uncomfortable with the term "two nodes",
> because (as I keep pedantically reminding people) what we really
> said in Scottsdale was "two node roles."  There's a significant
> difference; one of the MEPs that we supplied in the document
> (mep7) is multicast solicit-response.

Absolutely right. Definitely the MEP should be defined in terms of
roles/actors/etc as opposed to actual nodes.


> Hmm.  Okay.  We ought to include some sense of atomicity, but I
> don't know how to do that.

I think by definining the minimal number of communication idioms that must
be supported.


> > The constraint is actually imposed by an operation defined as
> having exactly
> > two actors, so these are clearly two actor MEPs, and not as one
> may assume
> > MEPs that fail to describe more than two actors.
>
> Well, two roles.  One of the roles can be the chorus, so there
> can be lots of people singing.  They aren't two-actor MEPs,
> they're two-role MEPs.  But apart from that, yes, maybe.  If
> someone could come up with a MEP in which there are three roles,
> but no control flow, then I'd be more convinced that such a thing
> is possible.  I'm not convinced by the forwarding example because
> either a) the client doesn't know that the intermediary exists,
> so is looking at a mep2 published by the ultimate service, or 2)
> the client does know that the intermediary exists, but doesn't
> know it's an intermediary for the ultimate service, so is looking
> at a mep2 published by the intermediary (and doesn't care what
> the intermediary does to process the message).

This is simply another constraint. From the perspective of messages passing
between the two roles, there may be intermediaries and some MEP could
describe them. From the perspective of the WS operation there are no
intermediaries, they are either the ultimate service or invisible. We just
need to explain that particular perspective and it will be clear that
intermediaries are not covered by these specific MEPs.


> Probably we need to state, somewhere, that a MEP is something
> that doesn't have any control flow constructs (and this is why
> there are choreography languages; *they* have constructs, we just
> have sequences ... grumble, grumble, mother *always* loved
> choreography best ...).  In fact, it's very likely that we need a
> much better (more constraining?  more precise?) definition of MEP
> and of operation.  Likewise, choreo languages need this, because
> they use MEP/operation as atoms.  If the point of this para is
> that we have some rather underdefined concepts, I'll go along with that.

A choreography is also a message exchange pattern. And just saying 'no
control flow' is not enough. I can think of a case where two operations (one
from A to B, one from B to A) is better than a single request-response MEP
(no control flow). I can't yet articulate the difference, but since this is
also important for choreography I'll give it a try.

arkin

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

Received on Friday, 21 February 2003 13:53:22 UTC