Re: write-up of interaction patterns

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

Received on Tuesday, 14 January 2003 10:41:52 UTC