RE: MEP proposal

I prefer 'from the point of view of the service' for two reasons.


First, for each operation we identify a service whose end-points must be
known in order to perform the service, and an infinite set of clients about
which nothing must be known in advance. It is only the service that needs to
be described, hence, the definition can be given from the point of view of
the service.

Even if we wrote the definition as:

operation involving messages M1..Mn
roles S and C
direction for messages as D(M1) being either C->S or S->C

It would make little difference. To perform the operation you still need to
know the end-point by which you reach S and known nothing about C until the
operation is performed. The more verbose form adds nothing and is equivalent
to how we currently describe operations in WSDL.

(This is different from say ebXML, where you need to know the end-points of
both S and C, hence you treat them as X and Y - both are services. It is
only later on that you determine one is initiator and one is respondent)


Second, for any given operation one acts as a 'client' and one acts as a
'server' (I much prefer the term requester and provider). However, this is
not a client-server model.

The term client-server is used to denote an architecture where one machine
is always the client and one machine is always the server and a network
topology is built on that. A client for one server may act as a server for
another client, but may never switch roles, i.e. if X is server of Y, Y is
never server of X. The term peer-to-peer is used when machines may switch
roles, X may be server of Y or client of Y at any given point in time.

Client-server and peer-to-peer are two different architectures that can be
achieved with Web services, but Web services does not force you to elect
just one of these architectures. For that reason I would prefer to avoid
client-server and talk about service requester and service provider for any
given operation.

arkin

> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com]
> Sent: Monday, February 24, 2003 8:08 AM
> To: Amelia A. Lewis; arkin@intalio.com
> Cc: WS Description WG
> Subject: Re: MEP proposal
>
>
> 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 13:11:46 UTC