Sequencing use cases [was: Re: [wsrm] Preliminary minutes of WSRM TCConf call -050603]

[Doug Bunting <Doug.Bunting@Sun.COM>]

An interesting use case thread to say the least.

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.

While I can, for example, imagine a messaging system splitting a large 
transfer into an ordered set of messages sent in a "batch", I'm not sure 
why the system would act in this fashion (versus performing one large 
transfer).  I suspect a justification exists and didn't object to making 
parallel sequences a requirement for our protocol but would like to hear 
it clearly described.

Somewhat separately, I'm assuming above that we're talking about a 
relatively short duration sequence of messages (having short pauses 
between the sent messages).  "Conversations" (if you will) with gaps 
between messages longer than the time-to-live for those messages seem to 
be more about shared context than ordering since the messages must be 
acknowledged individually.  Please let me and the group know if you're 
considering long duration sequences (those with long gaps between 
messages) an important requirement for our protocol.  Otherwise, the 
"multiple un-acknowledged messages" mentioned above exist in a window of 
about the same size as the message time to live.

thanx,
	doug

On 07-05-2003 09:30, Dock Allen wrote:
> I don't think we should preclude a use case where an application initiates
> multi-segment messages at the same time.  Threaded  applications would do this
> because the threads operate independently most of the time.  The question is,
> how is that supported?  Does it require that the messages use different
> end-points, or are they just different messages overloaded onto the same pair
> of end points?  We don't place any such restrictions on single-segment
> messaging.
> 
> Dock
> 
> Paolo Romano wrote:
> 
> 
>>>4.4      REL-11 MESSAGE ID AND GROUPID/SEQUENCENO
>>
>>...
>>
>>>Paulo stated that having two identifiers (such as groupID, sequenceNO) is
>>>needed for several groups of messages with dependencies. Messages ordered
>>>by groups is a use case we have often. He also would prefer one id
>>>mechanism, but it could be a struct with groupID
>>
>>I guess I must have missed a "not" in the yesterday phone call...
>>Actually, I can't imagine many common use cases where between two end
>>points it is necessary to have simoultaneously multiple groups of messages
>>which have to be ordered independently. This is why I consider redundant
>>having two different identifiers (Group_id + Sequence_id), and I would
>>prefer to use only one identifier for both duplicate elimination and
>>sequence ordering. The advantages of such an approach would be:
>>implementation simplification and reduced "verbosity" => overhead.
>>
>>May be somebody can show us some use cases where the feature of having
>>multiple groups of messages ordered is worthy the cost of using distinct
>>identifiers for ordering and filtering out duplicates.
>>
>>Paolo