Re: MEP proposal

On Mon, 24 Feb 2003 11:45:40 -0800
"Assaf Arkin" <arkin@intalio.com> wrote:
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> > Behalf Of Amelia A. Lewis
> > Sent: Monday, February 24, 2003 8:34 AM
> > To: Jacek Kopecky
> > Cc: arkin@intalio.com; www-ws-desc@w3.org
> > Subject: Re: MEP proposal
> > 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.
> 
> In that case there are multiple services that all share the same end-point,
> essentially, a common channel, but still one service role. The only
> difference is that the input will be processed multiple times and you may
> receive multiple responses (assuming some communication idiom that supports
> that).

Umm, why request/response?

> So you look at such communication idiom as involving a group with:
> 
> - Indefinite number of clients (but one role) but any communication
> originates from one client
> - Indefinite number of servers (but one role) but any communication involves
> one channel (end-point) shared by all servers
> - Description is given from the point of view of the service where service
> denotes the listener on that channel, but is not strictly one server

Possibly not the listener at all.  A publication service is defined primarily in terms of the place that it publishes.  It may not be listening.

> - Communication idiom identified as multicast implying multiple responses vs
> unicast implying single response

Umm, no, not necessarily.  Again, we seem to slip into service=server, where the server is always *listening*.  It ain't necessarily so.

> note 2: I have suggested looking at group communication before as the model
> for WSA for that same reason. Even if we don't consider this advance topic
> as interesting at this point in time, at least we can talk in more abstract
> terms to allow its introduction in the future. End-point as a channel for
> communication is more interesting than end-point as a URL for accessing a
> server.

Umm, this is actually part of the reason that I've been avoiding the topic.  It's good for *lots* of discussion ....

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

Received on Monday, 24 February 2003 15:34:53 UTC