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] WS-ReliableMessaging: Where Are Message ID's

I don't think WS-Addressing is so much related here. As you described, the  MessageID and RelatesTo constructs in WS-Addressing are mostly intended for capturing application defined relationships between messages (rather than the simple ackTo kind of correlation needed by reliable messaging). 

I think we all seem to notice that the WS-ReliableMessaging did not require an explicit MessageId, since their Identifier|MessageNumber combination serves the purpose for both the use cases, that is, with or without ordering. The problem as we see is that this solution is more optimized for ordering, as it requires a composite identifier in all cases, irrespective of whether the message belongs to an ordered group or not. 

Another consequence of the above design in WS-ReliableMessaging is that its ack message also has to be in terms of a composite identifier for the ack'ed message. However there is one clear benefit of this design - you now get support for "batch acknowledgement" almost free!

It would be great to know what the group's thinking is in this regard. In its current form, the WS-Reliability spec seems more modular, as the constructs for reliability and ordering are independent of each other. For an implementation perspective this is perhaps more cleaner, as there is no inheritance/overloading of constructs (you basically have fewer "if-else" in the code now). Are there other good reasons for maintaining the two unique identifiers?

Sanjay Patil
Distinguished Engineer
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: Wednesday, April 16, 2003 4:08 PM
To: iwasa
Cc: Chiusano Joseph; wsrm@lists.oasis-open.org
Subject: Re: [wsrm] WS-ReliableMessaging: Where Are Message ID's

Put another way, Joe was missing the WS-Addressing specification. 
WS-Reliability is somewhat comparable to the composition of 
WS-ReliableMessaging and WS-Addressing.

Within WS-Reliability, two unique identifiers (one optional and one 
required) exist for every message.  The optional unique identifier is 
the GroupId|SequenceNumber combination that becomes required when 
message ordering is used.  The required one is the MessageId value.  The 
MessageId provides for lower levels of reliable delivery (duplicate 
elimination, correlation of messages and acknowledgements when combined 
with RefToMessageId, ...) as well as allowing (though not directly 
supporting) additional references to the message.  The message ordering 
constructs are used only to add that feature on top of a reliable delivery.

In the combination not submitted to this TC, you can also point to two 
unique identifiers for every message though neither is truly required 
since you may nor may not use either specification.  The 
Identifier|MessageNumber combination in WS-ReliableMessaging provides 
the data necessary for all levels of reliable delivery in that 
specification, including simple correlation of acknowledgements.  The 
MessageID in WS-Addressing supports more complex correlations (directly 
since the RelatesTo element includes a RelationshipType attribute) and 
other message reference features.  The WS-Addressing correlation feature 
seems intended primarily for application layers above the delivery 
subsystem (as opposed to the WS-Reliability and WS-ReliableMessaging 
correlation which are primarily for the delivery subsystem itself).

This leads to an interesting problem, discussed long ago on the W3C Web 
Services Architecture WG public mailing list.  Two unique identifiers 
for a single message is a redundancy, especially when both must be 
maintained for later use.  (There's probably additional architectural 
issues with this that I'm forgetting.)

I can't find the URI for the archived email at the moment but believe it 
was Assaf Arkin who mentioned the possibility of using the MessageId 
unique identifier directly to implement ordering.  He proposed something 
like a "depends on" relationship, meaning the referenced message must be 
delivered to the application first.  This obviously cascades to form an 
ordered list though it could also be used to provide more complex 
dependency graphs.

Another approach, more foreign to the input before this TC so far, would 
be defining something like RelatesTo in terms of a prior 
Identifier|MessageNumber combination and do away with MessageID.  I must 
admit not liking this approach because it optimises toward ordered 
delivery (a use case previously identified as an optional layer above 
reliable delivery), splits the unique identity between two values and 
doesn't support complex dependency graphs.

For an example of complex dependency graphs, please look at any business 
process :)  Ship notices may assume delivery of multiple confirmations. 
  Each of those confirmations may have updated a previous confirmation. 
  Et cetera.  These types of situations aren't specific to B2B of course.


On 2003-04-15 19:24, iwasa wrote:
> Joe,
> Yes, I believe your observations is correct.
> They do not use a globally unique messageId to identify 
> the specific message, but use group identifier - "Sequence/Identifier" 
> and sequence number - "MessageNumber".
> If the Sequence/Identifier's uniqueness is guaranteed,
> I think it should be OK to identify the specific message 
> with a combination of "Sequence/Identifier" and "MessageNumber",
> even if they do not have globally unique message id.
> And their "Sequence/Identifier" is similar to our GroupId.
> But they mandate it for every message, but we use it
> only for message ordering.
> Thanks,
> Iwasa
>> It's been a long day, and I might be missing something. I just glanced
>> at the GXA WS-ReliableMessaging spec [1] and noted that in the
>> definition of message sequence, there is a message number but no message
>> ID. From p.10 of spec:
>> Sequence definition:
>> <wsrm:Sequence ...>
>>    <wsu:Identifier> [URI] </wsu:Identifier>
>>    <wsrm:MessageNumber> [unsignedLong] </wsrm:MessageNumber>
>>    <wsrm:LastMessage/>?
>>    <wsu:Expires> [dateTime] </wsu:Expires>?
>>    ...
>> </wsrm:Sequence>
>> Example:
>> <wsrm:Sequence>
>>    <wsu:Identifier>http://fabrikam123.com/abc</wsu:Identifier>
>>    <wsrm:MessageNumber>10</wsrm:MessageNumber>
>>    <wsrm:LastMessage/>
>> </wsrm:Sequence>
>> Yet, in WS-Reliability, we specify a GroupID in the MessageOrder
>> element:
>> <rm:MessageOrder xmlns:rm:="http://schemas.fujitsu.com/rm"
>>       SOAP:mustUnderstand="1">
>>       <rm:GroupId status="Continue">020907-45261-0450@a.com</rm:GroupId>
>>       <rm:SequenceNumber>12</rm:SequenceNumber>
>> </rm:MessageOrder>
>> Where GroupID is "used to specify the group of messages for which
>> message ordering is guaranteed."
>> Can anyone please confirm my observations? It seems very odd that
>> message ID's do not appear in message sequences in the
>> WS-ReliableMessaging spec.
>> Kind Regards,
>> Joe Chiusano
>> Booz | Allen | Hamilton
>> [1] http://msdn.microsoft.com/ws/2003/03/ws-reliablemessaging

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]