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

RE: write-up of interaction patterns

From: Assaf Arkin <arkin@intalio.com>
Date: Wed, 15 Jan 2003 09:23:35 -0800
To: "Amelia A. Lewis" <alewis@tibco.com>
Cc: <sanjiva@watson.ibm.com>, <www-ws-desc@w3.org>
Message-ID: <IGEJLEPAJBPHKACOOKHNMELADAAA.arkin@intalio.com>

I understand.

We're in violant agreement here.

There's so much experience out there in building multicast systems, I don't
see why this has not trickled down to WSDL. It looks to me like defining
multicast for HTTP is as simple as borrowing the ICMP messages and defining
suitable operations, and the WSDL protocol bindings would be even simpler.
Actually port and interaction style.

Couldn't we just do a sketch of that and see how the existing output
operations maps to it?

arkin


> -----Original Message-----
> From: Amelia A. Lewis [mailto:alewis@tibco.com]
> Sent: Wednesday, January 15, 2003 9:00 AM
> To: Assaf Arkin
> Cc: sanjiva@watson.ibm.com; www-ws-desc@w3.org
> Subject: Re: write-up of interaction patterns
>
>
> This is all absolutely correct.  It wouldn't use the proposed
> event syntax at all.
>
> My original point was that the event syntax does not seem to
> describe any messaging system I know of.  If one wanted to
> provide an event mechanism with subscription, monitoring,
> administration, unsubscription, that runs over, for instance,
> email, one needs more than the proposed syntax, including
> termination rules.  If one wants an equally (or more) powerful
> event mechanism over multicast, JMS, or any other system designed
> to the purpose, then one wants *less* than the proposed event
> pattern.  My struggle was to understand under what circumstances
> the proposed event pattern would actually work, containing as it
> does explicit initiation, but no explicit termination syntax or semantics.
>
> On Wed, 15 Jan 2003 08:31:43 -0800
> "Assaf Arkin" <arkin@intalio.com> wrote:
>
> > > Is this what's intended by this "event" pattern?  In that case,
> > > were it to be labelled, and its assumptions described adequately,
> > > I've no real objection to it.  I *would* like to see an event
> > > pattern more suitable for those protocols that normally *do* such
> > > things ... and that would include some indication of termination
> > > syntax/conditions as well as status, something that could run
> > > without dedicating a socket to it for the duration of the
> subscription.
> >
> > Can you explain the termination syntax and what would that be used for?
> >
> > Let's say I am using IP multicast to distribute messages to all the
> > subscribers. The publisher decides on the IP/port to use and
> defines that in
> > its WSDL service definition. The operation is an output
> operation (publisher
> > sends message).
> >
> > Each subscriber retrieves messages by joining the group. It knows the
> > IP/port address to join from the service definition and it also
> knows which
> > message to expect. The decision when to subscribe and when to
> unsubscribe is
> > left up to the subscriber and does not involve the publisher.
> >
> > The way in which subscription occurs is described at the
> protocol binding
> > level, there's no need to define a WSDL operation for that.
> That's also the
> > case with other protocols I can think of, and all MOMs I have
> worked with.
> > So I can't see why a termination syntax would be required?
> >
> > If I had to do multicasting over HTTP at a layer below the choreography
> > (that is, WSDL), I would follow the exact same pattern that all other
> > pub/sub protocols use. The subscribe/unsubscribe operations
> would be defined
> > at the protocol level, exactly the same set of HTTP messages
> for each and
> > every service, with an address for subscription and an output operation.
> >
> > There are two reasons why I would not do a WSDL-level subscribe
> operation:
> >
> > 1. If there is anything that needs to be passed to the application level
> > then you're are doing pub/sub at the choreography level and
> that should be
> > addressed by a choreography language
> >
> > 2. An intermediary may intercept this call and do a local
> registration. You
> > can't do that with a WSDL-level operation, since the operation must be
> > passed to the end service.
> >
> > No. 2 is required in order to allow a multicast tree to be
> formed. If I have
> > a hundred applications in my Intranet that all subscribe to the
> same source
> > that publishes messages in some other network, I can have an
> intermediary
> > (broker) that does a single subscription on their behalf and
> then sends all
> > the notifications to them. IP multicast can't scale well
> without multicast
> > trees, HTTP won't scale at all without one.
> >
> > arkin
> >
> >
> >
> > >
> > > I can't say that I'd be *happy* with another implicitly
> > > synchronous, runs-best-over-HTTP pattern, if there are no
> > > patterns at all suitable for use with alternative protocols.
> > >
> > > Amy!
> > > On Tue, 14 Jan 2003 10:41:25 -0500
> > > "Amelia A. Lewis" <alewis@tibco.com> wrote:
> > >
> > > >
> > > > My first comment on this is that the interaction model seems a
> > > much better expression of message exchange patterns than our
> > > current <operation> syntax, and I support it strongly.
> > > >
> > > > My second comment is that the event pattern introduced here is
> > > underspecified.  Until and unless it can be made less ambiguous,
> > > more interoperable, I would resist including it.
> > > >
> > > > Specifically:
> > > >
> > > > 1. the number of notifications to be received for a
> > > subscription is underspecified
> > > > 2. there is no termination syntax
> > > > 3. termination conditions are unspecified
> > > > 4. status investigation is unspecified
> > > >
> > > > I believe that the model on which the 'event' pattern is based
> > > is event notifications in Java and similar languages.  It is
> > > worth noting that, in Java, an XyzzyEventSource exposes
> > > addXyzzyListener *and* removeXyzzyListener (and may supply more
> > > than one event, for that matter).  Status investigation is
> > > insignificant for this case; in Java, a listener thread isn't
> > > going to fail and later be restored, and when the JVM quits, all
> > > the loose ends are cleaned up.  Similar ease of implementation is
> > > simply not found in network communications.
> > > >
> > > > 1. the number of notifications to be received for a
> > > subscription is underspecified:
> > > >
> > > > It is possible that this pattern is intended to be "send me the
> > > next notification" and stop; basically a request/response with
> > > delay.  I don't believe that that is the case, since it's
> > > modelled on the event models in Java etc.  If it is intended to
> > > be single-shot, then the following criticisms don't apply.  But
> > > if it's intended to only deliver a single event notification, I
> > > don't think that it's very useful, either.
> > > >
> > > > 2. there is no termination syntax:
> > > >
> > > > addXyzzyListener() without removeXyzzyListener().
> > > <subscription> without <unsubscription>.  How do I *stop* getting
> > > messages from this service?  I do not think that this can be left
> > > unspecified.  Shutting down the JVM won't do it, because there
> > > isn't a JVM over the scope of the network.  I can, of course,
> > > just stop listening, but that raises the next issue.
> > > >
> > > > 3. termination conditions are unspecified
> > > >
> > > > When a service is sending notifications, and begins to receive
> > > errors (network unreachable, host unreachable, port unreachable,
> > > connection refused), is it allowed to terminate the subscription?
> > >  Is it allowed to do so the first time?  The thousandth time?  At
> > > a percentage?  When?  If my router dies, and the network folks
> > > work furiously for two hours to get us back up and reachable, am
> > > I subscribed or not?  Which leads to the next issue.
> > > >
> > > > 4. status investigation is unspecified:
> > > >
> > > > Am I subscribed or not?  As the event syntax is given, were I
> > > to build a client that expects to subscribe, I would have that
> > > client subscribe every [duration], where duration represents the
> > > average time between notifications.  I don't want to miss one.  I
> > > would also design the client to send the most brutal error
> > > message possible when I want to unsubscribe (a TCP RESET, for
> > > instance, when I receive a notification from a service that I
> > > can't unsubscribe from).  Probably, though, since this looks like
> > > a fire hose I can open, but never close, I just wouldn't use it.
> > > If I had to use it, since I can't find out if I'm not getting
> > > messages because there are no messages or because the network
> > > happens to be down, I'd use the subscription message as a
> > > keep-alive.  As a result, I'd probably be sending nearly as many
> > > subscription requests as I receive notifications.  Not good.
> > > >
> > > > I think that these things need to be addressed before such a
> > > pattern is included in the spec.
> > > >
> > > > Amy!
> > > > --
> > > > Amelia A. Lewis
> > > > Architect, TIBCO/Extensibility, Inc.
> > > > alewis@tibco.com
> > > >
> > >
> > >
> > > --
> > > Amelia A. Lewis
> > > Architect, TIBCO/Extensibility, Inc.
> > > alewis@tibco.com
> >
>
>
> --
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com
Received on Wednesday, 15 January 2003 12:24:58 GMT

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