RE: write-up of interaction patterns

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

There are actually three event notification models in Java.

One is based on constant polling. For example, retrieving data from a socket
using the receive method. In HTTP you could implement that by having a
persistent connection but you'll need to maintain the connection and keep
sending messages, so it's not a suitable solution for Internet deployment.
This is done in lieu of an asynchronous I/O package.

The other is based on registering a listener. This is basically the example
you have been given. This model simplifies the development of components
that are tightly integrated with each other and execute in the same process.
It is not suitable for distributed applications and is how inter-process
communication is implemented.

The third is based on broadcasting notifications and having a "message bus".
This is how JMS, JMX, IP multicast and other publish/subscribe mechanisms
are implemented. Since it is used for publish/subscribe messaging, this is
the model we should pursue for WSDL.

In JMS/JMX/IPM there is no subscription operation provided by the publisher.
The publisher only defines an output operation which it uses to send
messages. The protocl deals with the propagation of these messages to
listener. Sometimes you require subscription to the actual source (IP
multicast), sometimes you always subscribed but need to filter messages you
are interested in (some implementations of JMS and JMX protocols).

The subscription is done in the client library by expressing interest.

For IP multicast you would actually join a group which would send an ICMP
message. ICMP messages are control messages, they are not something the
publisher deals with directly. The publisher sends UDP messages and the
subscriber receives UDP messages. ICMP messages are handled by the routers.

For JMS you would open a listener to a topic. How messages are delivered
depends on the implementation. The implementation may use control messages,
pool for messages and filter them, retrieve them from a queue, etc. For JMX
you would register an interest in broadcast messages, and again the model is
similar to JMS and actual registration (if at all) is protocol dependent.

The application may register a listener with the client library, e.g. for
JMS and JMX. The application may also poll for messages, e.g for JMS and for
IP multicast. Whichever approach you do is an implementation detail of the
client implementation and not representative of the operations the services
are performing.

I would recommend looking at JMS and applying the JMS model. In other words,
looking at the operations that a JMS publisher does (sending message X) and
the operations that a JMS subscriber does (sending message X) but ignoring
how the application internally uses the client library (register, poll,
peek, iterators, etc).

arkin

>
> Agreed.
>
> > 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.
>
> My intent was to have the Java/JavaScript style >= 0 deliveries pattern.
> If and when this becomes accepted, we'll make sure that the spec clarifies
> this clearly.
>
> > 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.
>
> Oops, I'll add that .. forgot ;-).
>
> > 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.
>
> Again, we'll write this down if and we put this in. My preference is to
> follow the Java style rules and pick as simple as possible semantics
> for the distributed issues you bring up (all good ones!). If we get
> this far I'll be happy to propose a set of answers to these and related
> questions.
>
> > 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.
>
> My proposal would be to not support any status investigation capability in
> this simple event pattern syntax. If such complexity is desired, the
> general interaction pattern approach can be used to give clear and
> precise semantics and also as the basis to provide custom syntax.
>
> Sanjiva.
>

Received on Wednesday, 15 January 2003 20:30:44 UTC