Re: write-up of interaction patterns

Following up to myself is probably terribly tactless, but so it goes.

I've been trying to think of a scenario in which the "event" pattern works, probably with assumptions, but without additional description.

It seems to me that if one uses a connection-oriented protocol, in which the service/server responds to certain messages by leaving the connection open, sending messages from time to time, while the service partner/client also leaves the connection open and processes messages as they are received, then the pattern given would work.  Either side would be able to "unsubscribe" by closing the TCP connection; both sides would be aware of the status of the connection.  Any number of messages; no termination syntax needed; termination conditions expressed through the assumption that we're using persistent TCP connection; status by checking the connection.

Moreover, this is probably a model that would be chosen to implement event notification over HTTP, although there may be some issues with it (need socket options to prevent idle disconnect, which may not be possible after the connection has been established and the subscription message parsed, or as a workaround NOOP messages for keepalive; scales desperately poorly without specialized help).

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.

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 10:36:23 UTC