Re: [wsrm] Preliminary minutes of WSRM TC Conf call -050603

["iwasa" <kiwasa@jp.fujitsu.com>]

Paolo, Doug, and all,

Sorry for a long e-mail. There are two contents
in this e-mail as follows:
  1.Use case for multiple groups
  2. About ID for message (MsgID vs. GroupID+Sequence#)
And the second one contains proposed resolution.

--
1.Use case for multiple groups

I think the use case I have is similar to Sunil's
use case. This use case made me believe it is
required to support multiple groups for ordering.
The use case is:

A sender has two application software, one is
procurement/purchase ordering application software,
and the other is catalogue filling application software.
And the two applications are sharing a single messaging
software which has one endpoint.

And a receiver also has two application software
to respond those two kind of requests above.
And the two application are also sharing one messaging
software which has one endpoint.

In this case, two independent application
are using one messaging software at both end.
And two kind of transaction should be done concurrently.
And even if one of the application or message
delivery has problem, the other application should not be
affected with the problem.

For instance, in case a request message from
catalogue filing application was lost and
waiting for resend, the receiver should be able
to give the next message from procurement software
to the application without waiting a resent
message from a catalogue filing software.

If we can use only a single group for sequencing, it
could cause some bad affect to independent software
sharing the messaging software.


2. About ID for message

I do not have objection to have a single identification
for message, if there is good way to do so.

Currently a global unique message ID is the identification
for a message, and group ID + Sequence number is added
only for ordering, but not for a purpose of a message
identification. But it ended up with becoming other identification
for a message.

I have considered Doug's approach to solve this issue,
but found some issues with the resolution, which are:
1. It is impossible to find out how many messages are
    lost at receiver side when two or more consecutive
    messages are lost. And it makes difficult people to
    solve those problems manually, once it happened.
2. It is impossible for receiver to identify the message's
    group for ordering if the previous message was lost.
    So it potentially makes implementation complex and
    non-efficient, since the message has to be saved in
    a non-group identified storage rather than saving
    the message in a storage for the group.
3. Since people usually do ordering with sequence number,
    but merely doing so with link to the former one,
    it is simple to use sequence number.
    And simple approach can avoid any confusion.

With above reasons, I tend to find other option
to solve the issue, and the following is the one
I propose:

Making GroupID mandatory for all messages,
SequenceNumber mandatory only for ordering,
and MessageId optional or remove it completely.
The GroupID must be globally unique.

With this resolution, GroupId is equivalent with
Globally unique message ID, if you do not do
ordering. And ordering can be done within a group
with SequenceNumber.

We can change the element name also if we want.
  Eg. GroupID to MessageGroupID

I believe this resolution solves all issues we have.

Thanks,

Iwasa


>
> >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