RE: write-up of interaction patterns

> 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

Received on Wednesday, 15 January 2003 11:33:09 UTC