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.

> > we publish.  That's because I think doing so shows that the MEP
> > represents a common "idiom" in networking, and not just a
> > for-the-sake-of-consistency inclusion.
> 
> All these MEPs are based on some constraints, but the constraints are not
> defined and not obvious from the term 'message exchange pattern'.

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

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

> The "idiom" also captures additional constraints which explains why the MEPs
> are one or two stage and don't involve if/else. But again, these have to be
> explained, otherwise all the questions raised so far are valid.

Umm, what?  I'm sorry, I don't quite follow.  What's a stage, in this context?

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.

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

Received on Friday, 21 February 2003 13:43:15 UTC