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

["neelkanth_mishra" <neelkanth_mishra@infosys.com>]

First, apologies for not being able to attend the conf call today. At 3am, well nigh impossible to reach office! Saw the new bridge number only after coming to office in the morning.

One possibility is where the sender deliberately breaks all its messages into smaller segments for better QoS. Say multiple 4MB files have to be transferred end of day, and the optimal message size is 100KB (this is a real case using Websphere MQ). In such a scenario, the sender needs to have groups of messages, with a sequence within the group. One can debate if WS should be used for file transfer. But at an abstract level, it should be a possibility where because of the intervening infrastructure, splitting at sender and combining at receiver are necessary.

Two ways to handle this:

1. Let WSRM not be aware of any splitting and let the application logic handle the split-rejoin. Here, instead of being in the message header, the sequence id comes to the message data. The protocols for failure/re-transmission are therefore also implemented at an application level.

2. Have the group-id/sequence-id feature in WSRM - applications can use it for splitting/re-joining.

Neelkanth.

-----Original Message-----
From: Paolo Romano [mailto:romanop@dis.uniroma1.it]
Sent: Wednesday, May 07, 2003 3:05 PM
To: wsrm
Subject: Re: [wsrm] Preliminary minutes of WSRM TC Conf call -050603



>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