RE: MEP proposal

> -----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 12:34 PM
> To: Assaf Arkin
> Cc: jacek@systinet.com; www-ws-desc@w3.org
> Subject: 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?

Because it's more complicated than just request ;-)


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

Sorry, different usage than what you are talking about. I was thinking about
solicit-response operation not notification.

A notification service would be a case where:

- Indefinite number of clients (but one role) and idefinite number of
servers (but one role)
- Any communication involves one channel (end-point) share by all servers
and clients
- Description is given from the point of view of the publication service
which publishes that information
- There could be many servers that publish information through that service,
multiple clients that pull that information from the service

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

On the other hand, it's all too tempting to describe the architecture in
terms of unicast idioms, which would require extension of the architecture
to deal with multicast. For example, one could say that the end-point
denotes the node that processes the message, which is clearly not true for
notification. If we use more abstract terms, and end-point denotes the
channel by which you communicate with the service, then we can have both
forms of communication.

arkin

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

Received on Monday, 24 February 2003 16:03:15 UTC