W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2003

Re: MEP proposal

From: Jacek Kopecky <jacek@systinet.com>
Date: 24 Feb 2003 17:08:24 +0100
To: "Amelia A. Lewis" <alewis@tibco.com>, arkin@intalio.com
Cc: WS Description WG <www-ws-desc@w3.org>
Message-Id: <1046102904.23499.129.camel@krava.in.idoox.com>

Amy, Arkin, others?,

I agree every complex interaction can be thought of as a set of two-role
simple interactions with higher-level rules to govern the set
(choreography), just as every complex interaction (e.g.
request/response) can be thought of as a set of messages, with
higher-level rules to govern them.

There is a big step from two messages to request/response, at least
conceptually. I'm not sure if there is such a step from two-role
interactions to more complex ones.

Anyway, what I was saying is that there are these two possible
interpretations of the phrase "from the point of view of the service".
It seems we agree that there are operations at the largest level (I'll
call them high-level operations) that include multiple messages between
multiple roles.

(some formalism starts here, if you don't want to read this or it's
confusing, there is a mark after it so you can skip it)

Let me define a high-level operation as 

     1. a set R of distinct roles
     2. a set M of messages (defined as triples {source role, target
        role, message format})
     3. a set F of flow rules that govern the sequencing of messages as
        they flow from instance(s) of their source roles to instance(s)
        of their target roles.

Let's say we're modeling WSDL MEPs as the high-level operations as seen
by the service. So we select a given role S (as service) from the set R,
and now what?

One way, we select those messages from M in which either the source role
or the target role is the role S. Then we select the rules from F that
involve the selected messages.

Second way, we start by selecting *two* roles C (as client) and S (as
server) from R, select only those messages from M that go between these
roles (either way) and then select the appropriate rules from F.

(formalism ends here)

In other words, the phrase "from the point of view of the service"
doesn't necessarily contain the client-server relationship that Amy
seems to see there.

We must choose if we're defining strictly client/server interactions and
view anything more complex as choreography and black-box encapsulation
(that would be the second way above), or we're concerned with the
interactions of a single node (that's actor, not a role) with the world,
which may contain multiple roles (that would be the first way above).

Again, I can go both ways, but we must choose one way and make sure
everyone understands it. Just saying "from the point of view of the
service" was insufficient for at least one person in the group, and that
would be me. 8-)

BTW, the stricter client/server scenarios are a subset of the more
general interactions.

Anyway, if I still sound like a misguided lunatic ( 8-) ), we can try to
talk at the f2f next week.

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/







On Fri, 2003-02-21 at 20:09, Amelia A. Lewis wrote:
> On 21 Feb 2003 19:33:57 +0100
> Jacek Kopecky <jacek@systinet.com> wrote:
> > Amy, please see below. 8-)
> > 
> > On Fri, 2003-02-21 at 18:44, Amelia A. Lewis wrote:
> > > On 21 Feb 2003 18:20:05 +0100
> > > Jacek Kopecky <jacek@systinet.com> wrote:
> > > > 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.
> > 
> > AFAICS, the definition of SOAP MEPs doesn't say anything about the
> > number of nodes: http://www.w3.org/TR/soap12-part1/#soapmep
> 
> SOAP 1.2 part 1, section 3.1, in the discussion of features, restricts
> everything to between two adjacent soap nodes (a problem that I
> thought I had pointed out to the working group; the word "two" is
> unnecessarily limiting; "adjacent nodes" is adequate).  Perhaps, since
> it bugs me so much, I'm reading too much into it.
> 
> > The two MEPs provided by SOAP spec do have precisely two nodes, but that
> > is not a general constraint on SOAP MEPs.
> 
> Okay.
> 
> > > > 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?
> > 
> 
> <snip>
> 
> I really apologize, but a description of the picture doesn't really
> help me at all.  And yes, I realize it's odd to encounter someone so
> particularly non-visual, when pictures are a common aid in these
> matters, but it's a picture of an abstract thing that looks rather
> venn diagrammish only not really.
> 
> Let me see if I can describe the three "levels" of MEPs in words (and
> without reference to the picture, if you don't mind; I have a little
> trouble with pink MEPs versus green MEPs, and still really meaning no
> offence, okay?).
> 
> At the smallest level, a MEP may represent the interaction between two
> conceptual processes (although there may be more actual processes
> involved; there are only two roles), which will do all the processing
> internally, on one machine, or in a fashion that is otherwise
> completely opaque to the mechanism of WSDL for description.
> 
> At the largest level, a MEP may represent the interaction of multiple
> processes, which may expose service interfaces that are in turn
> dependent upon other service interfaces, and are susceptible to
> description in WSDL.  For instance, the mep8 earlier mentioned might
> be an example of this level.
> 
> I don't understand where the middle level fits, either.  Sorry.
> 
> The two that I outline above are, in my opinion, a WSDL MEP/operation
> (the small level) and a choreography "process".  That's how I think
> things ought to be targeted, at least.
> 
> > I've heard in this WG before statements that seemed to say: why break up
> > the middle MEP into two small MEPs if it's really just one MEP logically
> > and since it's still from the point of view of the service?
> 
> As you can see, I don't quite understand how the middle one is
> described.  I can't find its boundaries, in verbal description.
> 
> > I think my picture contains no more control flow than request/response
> > contains. Is there anything else choreographish you'd ascribe to any of
> > the "WSDL? MEP"s?
> 
> I apologize, but I don't know what the picture represents.
> 
> Of the MEPs defined, I think number one is the simplest, with the
> content model:
> 
> IN
> 
> mep7 is probably the most complex, and can be characterized with the
> content model:
> 
> OUT, ( (IN, oFault?) | iFault )*
> 
> Perhaps you could provide a content model description for the MEP in
> the picture?
> 
> > I think visible intermediaries should be describable with WSDL. A
> 
> I disagree.
> 
> > visible intermediary is a service, too, so you can't dismiss this again
> > saying we decided WSDL is from the point of view of the service. 8-)
> 
> Not about to.  I think it should be described as a service.  The
> client is going to contact the intermediary, though, not the ultimate
> service; it doesn't really know it's talking to that other service.
> 
> > But a visible intermediary does have the other side that logically
> > belongs in the same operation but contains a third role.
> 
> I disagree; I think it simply plays the client role to the ultimate server.
> 
> > Again, I'm not saying WSDL must contain an intermediary MEP, but we must
> > allow it.
> 
> I think we do already.
> 
> Amy!
Received on Monday, 24 February 2003 11:08:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:22 GMT