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

["Patil, Sanjaykumar" <sanjay.patil@iona.com>]

I may be coming full circle to where this discussion started, but I must now say that the previous two-identifier solution sounds better than what we are now getting into.

It were certainly desirable to have a simple design of having a single identifier, but its price seems to be excessive, since  - 
a> We will be making the spec less modular: The MessageId is now NOT guaranteed to be unique, as its uniqueness is now subject to whether the message was ordered or not. The MessageData (parent of MessageId) which provided certain modularity by being generic and reusable for other features now loses its strength. Even the WS-RM spec itself will have to pay certain  penalty for breaking this modularity. For example, the RMResponse.RefToMessageId which is supposed to  uniquely identify the message to which a response (Ack, Fault) is to be sent now requires a change (in the form of a composite value or additional constructs, etc) to guarantee uniqueness of its value. Of course we can fix this problem as well, but isn't that extra price!
b> From a runtime perspective, the single-identifier design seems to be less efficient: The receiver is now forced to understand the ordering related constructs irrespective of whether the receiver node supports the ordering feature or not. In addition, this overhead will be in the code path of each and every message, as finding the unique message identifier is fundamental to processing of any message!

On the other hand, if I were to compare the above drawbacks with those of the two-identifier solution, which are: - 
a> The two-id design requires handling (persistence, etc) of two sets of identifiers and 
b> The two-id design may cause confusion (and therefore creating error-prone situations) by the virtue of providing a choice. 
I think that the second problem (of confusion) can be addressed by tightening the spec and mandating only one value to be used as unique identifier, etc. Regarding the first issue, perhaps it is justifiable that the additional "ordering" feature comes with its own extra cost and we aim for ensuring that the solution for simple use cases remains simple. Perhaps this was not a clearly stated goal, but isn't it a generally accepted good practice.

In summary, the singe-identifier design may "look" crisper, but it sounds less supportive of extensibility, runtime efficiency, etc. Thoughts??

Sanjay Patil
Distinguished Engineer
sanjay.patil@iona.com
-------------------------------------------------------
IONA Technologies
2350 Mission College Blvd. Suite 650
Santa Clara, CA 95054
Tel: (408) 350 9619
Fax: (408) 350 9501
-------------------------------------------------------
Making Software Work Together TM


-----Original Message-----
From: Sunil Kunisetty [mailto:sunil.kunisetty@oracle.com]
Sent: Thursday, May 08, 2003 8:04 AM
To: iwasa
Cc: Paolo Romano; wsrm; Doug Bunting
Subject: Re: [wsrm] Preliminary minutes of WSRM TC Conf call -050603





 <iwasa>

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

 </iwasa>

 +1.  More crispy that what I mentioned before.

 A more concrete refinement would be:
 - Remove the <rm:GroupId> element from <rm:MessageOrder>
 - Add 'status' attribute to <rm:SequenceNumber>
 - Use of <rm:MessageOrder> Header differentiates ordered
   to non -ordered
 - MessageId is GUID for non-ordered.
 - Sequence no. is unique within a group (for the same MessageId)

 Thanks,
 -Sunil

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