RE: MEP proposal

Amy,

I definitely agree with everything you said regarding the semantics of MEP
for the operation definition. My comments are specifically about the use of
the term MEP in isolation.

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?

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

The constraint is actually imposed by an operation defined as having exactly
two actors, so these are clearly two actor MEPs, and not at one may assume
MEPs that fail to describe more than two actors.

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.

arkin



> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Amelia A. Lewis
> Sent: Friday, February 21, 2003 9:44 AM
> To: Jacek Kopecky
> Cc: mgudgin@microsoft.com; jeffsch@windows.microsoft.com;
> www-ws-desc@w3.org
> Subject: Re: MEP proposal
>
>
>
> On 21 Feb 2003 18:20:05 +0100
> Jacek Kopecky <jacek@systinet.com> wrote:
>
> > Amy, I have two questions (with some discussion) below:
> >
> > 1) Are WSDL MEPs from the point of view of the service?
>
> Everything in WSDL is from the point of view of the service,
> according to Received Wisdom.  In my opinion, the only thing that
> requires this are MEP definitions.
>
> > SOAP MEPs (similar to what I would call abstract MEPs) are describing
> > the message flow among a given set of nodes (two or more, usually). They
>
> Precisely two, according to the SOAP spec.
>
> > informally distinguish between different messages, and they formally
> > distinguish between different nodes. SOAP MEPs have no notion of a
> > service.
> >
> > Now WSDL MEPs (the ones necessary for describing operations) have a
> > notion of a service (a special kind of node, I guess) and describe only
> > the part of the appropriate abstract MEP that actually concerns the
> > service.
>
> Okay.
>
> > The attached image shows two options of what WSDL MEPs are. The SOAP MEP
> > in the image (green/biggest box) has three nodes (to better demonstrate
>
> Not any SOAP MEP that I know of, and not legally by the SOAP
> spec, as far as I know.
>
> > my point), but the WSDL MEP can be understood to have the service and
> > "the world" (blue/middle box) or only two communicating nodes
> > (pink/small box). Now which ones were you doing? Which ones do we want
> > to do? Which ones do we want abstract?
>
> I'm sorry.  I realize that for most people, a picture is worth a
> thousand words.  To me, alas, a picture is just visual noise.  In
> other words, I can't make head or tails of a picture.  Can you
> explain it in words?
>
> > IMHO the smalles ones are interfaces, the middle ones are interactions,
>
> I dislike the term "interface", since it seems to imply RPC-ness,
> which is only one of a number of network models that WSDL can (in
> theory) describe.
>
> > the big ones are systems. If we do interfaces, we do the smallest ones.
>
> Why does the term "operation" not fit somewhere in here?  MEPs
> describe operations, in the terminology to which I'm accustomed.
>
> > Also, I believe abstract MEPs should be the big ones; probably providing
> > decomposition into both smaller types. WSDL MEPs would then reference
> > the component MEPs, not just the whole big MEPs.
>
> Umm, a part of what the picture describes appears to be what I
> would consider choreography.  If the larger "MEPs" happen to
> contain control flow, I think it falls irrevocably into the realm
> of choreography.
>
> > 2) Was the Scottsdale decision meant to forbid more-than-two-nodes WSDL
> > MEPs or was it just that this WG would not specify them?
>
> I don't know.  I'd like to see a justification of a MEP with more
> than two node roles, that doesn't include control flow (if/then).
>  I haven't seen one yet.
>
> I'll note that I consider several of the MEPs included in our
> document insufficiently motivated.  I'm in favor of attaching
> names, and preferably providing example uses, for each MEP that
> 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.
>
> > If such MEPs are forbidden, then surely we are doing the smallest MEPs.
> > What you have written below seems to suggest this approach.
> >
> > If more-than-two-nodes MEPs are just out of scope, we would be doing the
> > bigger (blue) MEPs. If so, cases with more than two nodes should still
> > be considered so that we don't end up with something that makes
> > describing/using such MEPs complex or impossible.
>
> *shrug*  I haven't seen motivation for MEPs with more than two node roles.
>
> > I hope we'll soon all be clear (and it may be just me who needs
> > clarification) on all this. 8-)
>
> Amy!
> --
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com

Received on Friday, 21 February 2003 13:31:59 UTC