No Subject

I would thus expect WSRM to be able to:

- support a pub/sub paradigm. I believe the plumbing in the current spec is
there for this: a topic is roughly equivalent to a GID. The app supplies the
GID that it is publishing to, and the WSRM implementation provides the SID
to ensure proper sequencing at the receiving end. But this SID is only
scoped to within the domain of a single SOAP node, so messages from two
different SOAP nodes cannot be ordered relative to each other. But I do not
believe that they must be anyway (they aren't in JMS). But still the
receiving end will require two levels of grouping to properly order the
messages: (1) grouping by the "topic" that is being published to (which will
be the GID), and (2) grouping by the sending node's ID so that it can order
all messages arriving from that node. Thus to support the pub/sub feature,
we need a "from" field also, and this must be distinct from the GID. 

- support for point-to-point messaging. The plumbing is essentially the same
as above - the differences lie in functionality that lies outside of the
WSRM-SOAP stack (like whether a message is delivered to one or more than one
application). In this case a GID is equivalent to an instance of a message
queue.

I believe a MID may have semantic importance to an application and thus it
needs control over how it is created (or at least we need to offer that
option). But following the above description for how I propose that GID/SID
are interpreted, the SID is generated opaquely by the WSRM provider and thus
it should be kept distinct from the MID.

Comments?

Scott Werden
WRQ

> 
> I would appreciate more information about business situations 
> in which 
> we believe multiple un-acknowledged messages may be 
> outstanding.  If I'm 
> thinking clearly, those cases in which message ordering may become 
> important are a subset of the un-acknowledged request cases.  Those 
> cases in which two parties may have parallel sequences in 
> progress are a 
> further subset of this second class.  We need to ensure the protocol 
> must go that far before we do (validate) all of the work.
>