[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Preliminary minutes of WSRM TC Conf call -050603
Sanjay, I see your point. So you prefer the current spec as is, rather than loosing modularity. I do not have objection with that. But how about the following solution? [Other option] Both GroupID and SequenceNumber are Mandatory as header information. The combination of those two elements is globally unique per message and equivalent with the current MessageId. And GroupId itself is globally unique as well. MessageId is optional or take it away completely. This is just replacement of MessageID and not mixing a function of MessageOrdering. SequenceNumber could be always zero, if you do not use ordering. Or actually you do not have to check it if you are not doing ordering. MessageOrder element remains as optional, and will be used for any information relating to ordering function. If you use ordering, you have to have the MessageOrder element, which is same with the current spec. Otherwise the element will not be used. With this solution, one major difference to the current spec is the messageID, but not for modularity. And the implementation that doesn't support ordering don't have to implement unnecessary ordering function. Someone might say this messageID is optimized for ordering, but actually it is not so much big deal and not so much complex to implement this. How was this solution? Iwasa -- [Sanjay wrote] 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]