Re: [wsrm] Rel YY

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

Tom Rutt wrote:

Sunil Kunisetty wrote:

>Tom Rutt wrote:
>
>
>
>>Sunil Kunisetty wrote:
>>
>>
>>
>>> Jacques,
>>>
>>> Oracle will be supporting this proposal. However, I prefer that
>>>SequenceNumber
>>> be Optional rather than mandatory as you indicated in (P2). I
>>>understand that it will
>>> be difficult for schema validation, but I believe it will be much
>>>simpler and efficient
>>> for implementations.
>>>
>>> So essentially we should categorize all RM  into 3 different
>>>categories based on
>>> the elements used in RM Headers:
>>>
>>> 1) Grouped and Ordered Messages:          Group Id + Seq No.  +
>>>Message Order
>>>
>>>Same Group Id, Different Seq No.
>>>
>>> 2) Grouped and Un-Ordered Messages:    Group Id + Seq No.
>>>
>>>Same Group Id, Different Seq No.
>>>
>>> 3) Discrete & Independent RM Messages: Group Id
>>>
>>> We could then use the SequenceNumber sub-element has the toggle
>>>switch to
>>> distinguish Grouped Un-ordered with Discrete & Independent messages.
>>>
>>>
>>>
>>We could then use the presence of the SequenceNumber's status attribute
>>(an enum with first, more, and last) as the trigger for ordered delivery
>>of the sequenced group.
>>
>>
>
> You mean instead of the proposed MessageOrder element in Request ( I guess
> that's what you meant below by saying rm-orderRequested).
>
> I prefer MessageOrder (or what ever is the name) sub-element as the
> triggering mechanism rather than the value of some attribute or sub-element
> to distinguish the category.
>
> Infact, that's the reason I preferred SequenceNumber as optional  and non
> existence of SequenceNumber to distinguish as an independent message
> rather than having it and value be 0.
>
>
>
It simplifies processing if all things having to do with the use of
sequence number occur
together in the message.  That way you do not have to look at another
header to determine
if the ordered delivery is requred.

 I never bought into this argument. We have to look/read all RM Headers
 before we really do any significant processing. So it's okay
if it is spread
 over Headers. It is indeed a cosmetic issue, but then these Headers
are
 not  visible to the user, so not that big a deal.

 My main concern of categorizing based on the element or attribute
 value is that 1) it can easily be mis-represented and more error prone
 (what if SeqNo  value is zero and status attribute exists) 2) we have to
 send extra elements/attributes for some un-necessary cases (such as
 Seq No with value '0' for discrete & independent RM msg. case).

 Btw, MessageOrder was put back by Jacques revised proposal. I
 was just saying I'm okay with it. Anyway, this is not a big issue
 compared to having Seq No. for un-ordered cases which most
 people (now) seem to be agreeing. Other ones are minor and
 we can decide based on majority's opinion. I can go either way
 with a preference to be based on existence of elements rather
 than their values.

 

The point is our existing syntax covers the semantics well.  Why add
another element
to another header (messageOrder element).  We already moved the status
attrbute to sequenceNumber, why move it back?

Tom Rutt

>
>
>>Thus the sequence Number would be optional with an optional status
>>attribute.
>>
>>This does not change our existing syntax, only the semantics.
>>
>>
>
> Yes, it will change the syntax, but it won't be that complex. Infact, we used
> to have it (MessageOrder) before.
>
>
>
>>This way we would not need a separate rm-orderRequested header subelement.
>>
>>Tom Rutt
>>
>>
>>
>>>An
>>> implementation could then use 3 different Hash Tables to store the
>>>IDs, thus
>>> making DE much more efficient.
>>>
>>>
>>>
>>----------------------------------------------------
>>Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
>>Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>
>>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>>
>>
>
>
>

--
----------------------------------------------------
Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133