Async use cases

I believe the first two of these are at least mostly covered by the 
existing known cases, particularly callback, but they may look different 
from a technical point of view (particularly to WSDL).  The last is a 
pure WSDL issue.  Caveat: I'm nothing like a WSDL guru, so please excuse 
an mangled usage of terms or apparent non-sequiters.

    * Discovery.  I want to discover instances of some resource.  I
      /broadacst/ a message to a set of possible hosts of this
      resource.  The broadcast contains an EPR through which they may
      respond.  I listen for responses, and eventually either find what
      I want or get bored.  In other words, there is no particular
      endpoint to the exchange (though a more refined protocol might
      support a "cancel" message.
    * Notification streams:  This is WSN.  The issue is that a
      subscription implies /zero or more/ messages sent to the consumer
      destination.  Strictly speaking, as I incompletely understand it,
      the consumer would advertise a one-way in-only message.  But this
      loses the information that the consumer is receiving zero or more
      messages, as the in-only MEP specifies exactly one message.  In
      effect, a subscription produces zero or more one-way operations. 
      This doesn't seem greatly harmful, but it arguably mis-describes
      the cardinality.
    * WSN as a binding.  Suppose a WSDL advertises an out-only message. 
      That is, it says "I can produce messages" (and again we'll skirt
      the issue of cardinality).  As far as I know, it's up to the
      binding to say how to initiate this.  One way might be some other
      in-only message to the service.  One way might be to use some
      legacy MOM.  Two more ways might be to make a WSN or WSE
      subscription to some NotificationProducer/EventSource.   How might
      we say this?

Received on Wednesday, 9 February 2005 21:05:46 UTC