[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
I think we are in agreement about the complexity the split identifier brings in. So what are the choices we have? Can I say there are three alternatives in front of us:- 1> Status quo Keep Ordering functionality independent of others. If Ordering is enabled, specific headers appear in the message that are both syntactically and semantically independent of the headers related to other functionalities such as guaranteed delivery and duplicate detection. 2> Single identifier but split in two fields MessageId serves as unique identifier, except when ordering is enabled (in which case MessageId combined with SequenceNumber forms the unique identifier). In terms of syntax, there were two proposal for achieving this effect. 2a> Keep MessageHeader unchanged. Trim the MessageOrder element to include SequenceNumber only. 2b> Remove MeessageId from MessageHeader. Utilize MessageOrder/GroupId is the primary identifier. 3> MessageId as primary identifier, referenced additionally for Ordering. Introduce syntax, conventions for carrying Ordering information that depends upon MessageId element for uniquely identifying the previous message in the order, etc. I am personally in favor of the option 1 for the reasons mentioned in my previous email. About option 3, I have seen some issues raised, but I guess we haven't explored this possibility in full. Am I right? 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: Doug Bunting [mailto:Doug.Bunting@Sun.COM] Sent: Monday, May 12, 2003 11:37 AM To: wsrm Subject: Re: [wsrm] Preliminary minutes of WSRM TC Conf call -050603 Sanjay, Before I start, a couple of terms. I use "unique identifier" and (sometimes) "identifier" when speaking of the primary key, that which identifies a single message among all messages in the either. This identifier may or may not be split between multiple "fields" (element or attribute values) in the messages. On 2003-05-08 21:06, Patil, Sanjaykumar 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! I do not understand where you are seeing these issues. Are you reacting to the recent suggestion to make use of GroupId as if it were a MessageId *except* when message order is in use? If so, then I agree the proposed solution complicates our picture. If not, I have yet to see a proposal using MessageId as anything other than a single unique identifier for a particular message. > 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! I am not sure how to have this discussion without slipping into particular solutions. A single identifier split between two fields is a bit more complicated and might be less efficient in some cases. A single field providing a unique identifier does not have those problems. > 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. I agree that simple cases should remain simple and see many use cases for a single unique identifier beyond WS-RM (business links between messages, for example). This leads me to believe we should focus on the simple MessageId solution for the bulk of our work. The question comes down to whether or not the baggage of an additional unique identifier for a message is necessary for the few ordering use cases before the group. If we can satisfy our requirements using the existing identifier and a new type of reference, that seems the simple option. I recommend not complicating the basic story with a number of "except when" clauses to support the more complex case (ordering in this instance). > In summary, the singe-identifier design may "look" crisper, but it > sounds less supportive of extensibility, runtime efficiency, etc. > Thoughts?? As described above, it depends upon which single identifier you choose. > Sanjay Patil Distinguished Engineer sanjay.patil@iona.com ... thanx, doug
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]