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


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]