RE: write-up of interaction patterns

When I connect to systems using asynchronous messagings I tend to use JMS.
Sometimes in combination with EJB (message driven beans). I could use MSMQ
or CORBA notification service, but it's basically the same thing only a
different API.

It would be helpful if I can capture the interaction between the services in
the same way.

I am not discounting JavaBeans. I love JavaBeans. But I am speculating that
if JavaBeans were designed to do asynchronous messaging there would be no
reason to use JMS or similar APIs. At the moment I do not see a requirement
to capture the way JavaBeans exchange events in the same process using WSDL.
I am thinking more along the lines of inter-process communication.

So I am trying to asses if this proposal is intended to indeed capture the
way in which distributed systems communicate with each other asynchronously.

arkin

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Thursday, January 16, 2003 11:07 PM
> To: Assaf Arkin; Amelia A. Lewis
> Cc: www-ws-desc@w3.org
> Subject: 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 15:22:15 UTC