OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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