Re: write-up of interaction patterns

The model I wrote up is based on the JavaBeans event model; which is
your 2nd case.

IMHO that's the case that should have special syntax in WSDL; YMMV.

Bye,

Sanjiva.

----- Original Message -----
From: "Assaf Arkin" <arkin@intalio.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>; "Amelia A. Lewis"
<alewis@tibco.com>
Cc: <www-ws-desc@w3.org>
Sent: Wednesday, January 15, 2003 8:25 PM
Subject: 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 Friday, 17 January 2003 05:05:34 UTC