Re: MEP proposal

Jacek,

Thanks for these comments.  *laugh*  I do a lot better with formalisms than with pictures ....

On 24 Feb 2003 17:08:24 +0100
Jacek Kopecky <jacek@systinet.com> wrote:
> 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.

I'm not certain how I gave the impression that I think so; I don't.

> We must choose if we're defining strictly client/server interactions and
> view anything more complex as choreography and black-box encapsulation

I hope not.  There are a number of network paradigms, notably including publish/subscribe, in which there is a service and a [participant that interacts with the service].  It is convenient, on occasion, to speak of the latter as a "client", but it isn't accurate, since the model is different.

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

I am answering only this part because I believe that there is a false dichotomy here.

I think that it is perfectly possible for the WSDL to describe a single role, which is always the advertised service, and which is (typically; see note 1 below) a single node.  The fact that the WSDL tends to describe a single node which is taking on the role(s) specified by the service description does not, to my mind, mean that the service description MUST describe every interaction that this particular node has with all other nodes, whatever their roles.

Or, in other words, the service description describes the service role of the node that implements it.  It is silent on that node's interactions when it is not acting in the service role.  This leads to relatively good encapsulation; I don't have to care how service A is implementing operation O.  It can do all the processing itself.  It can delegate processing to other services, such as service B via operations P, Q, and R.  It can grow as complex as it needs to be, but *I*, the consumer of the service, don't care.  I don't *want* operations P, Q, and R of service B to be exposed as part of operation O of service A, because then, if service B implements operation Q in terms of service Z's operation X, all of the descriptions have to be rewritten (and then all the clients), even though only implementation has changed.

The big steps that I see with more than two roles in an exchange pattern are: 1) control flow (often implicit at the boundaries), and 2) defeat of modularization.

Given an exchange pattern with three or more roles, and well-motivated by example usage, I might think differently, but I can't come up with such an example.  I don't have anwhere near as much trouble coming up with multiple-message exchange patterns (there are a number of networking idioms that involve more than two messages, and work without control flow).  I'm being kind and not proposing those (yet) because it adds to the confusion.

note 1: another of the things that adds to the confusion for message exchange patterns is that a service could easily be defined, using a multicast target address, as a distributed sort of application.  That is, the service description could easily be describing a cooperating set of nodes, all playing the "service" role.  This is a lot easier than it sounds, but only if you're familiar with pub/sub and multicast.  Again, I haven't raised this as an issue because it's what the textbooks call "an advanced topic", and isn't, I think, necessary to think about deeply while resolving the issue of message exchange patterns.

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

Received on Monday, 24 February 2003 11:34:09 UTC