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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

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


Subject: Re: [ws-tx] Issue 29 - wsa:MessageID should be explicitly requiredfor WS-AT non-terminal notification message


I'm not convinced 2005-08 CR removes this requirement if the message sent back to the original sender is considered to be a "reply", as Mark Little pointed out in an earlier post.

In my mind, this hinges on one central question: does the presence of wsa:ReplyTo define the message as a request, to which replies must be formulated in the manner described in WS-Addressing 3.3 "Formulating a reply message"?

If the answer is yes then we either do all of the following:

1) add message ids to all the messages

2) replies must cite the message ids as their RelatesTo value.

3) the replier MUST use the ReplyTo value to address the reply

Or, we stop using wsa:ReplyTo and use a WS-TX-defined element to convey the semantic intended.

Alastair


Ram Jeyaraman wrote:

 

This is identified as WS-TX issue 29.

 

Please ensure follow-ups have a subject line starting "Issue 29 -" (after any Re:, [ws-tx] etc.)

 

===================================

 

Issue name: wsa:MessageID should be explicitly required for WS-AT non-terminal notification message

 

Issue type: spec

 

Owner: Joseph Fialli (Joseph.Fialli@Sun.COM)

 

Reference documents:

 

WS-AT specification:

http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17044/wstx-wsat-1.1-spec-wd-03.pdf

 

PDF Line numbers: 475-477, 481-482

 

Description:

 

Summary:

Under Section 9 "Use of WS-Addressing Headers", non-terminal

notification messages MUST have

a wsa:ReplyTo but is silent on wsa:MessageID. 2004 WS-Addressing

specification requires wsa:MessageID when wsa:ReplyTo exists.

 

Resolution:

Add bullet "MUST include a wsa:ReplyTo header" to Non-terminal

notification messages. (line 481-482)

 

Details:

Request messages MUST have wsa:MessageID and wsa:ReplyTo (line 475-477).

Non-terminal notification message MUST have wsa:ReplyTo (line 481-482).

The absence of MUST have wsa:MessageID implies it is optional for

non-terminal notification message.

 

Supporting data that non-terminal message MUST have a wsa:MessageID

 

1. 2004 WS-Addressing

spec(http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/)

states that if wsa:ReplyTo exists then wsa:MessageID MUST exist.

 

Extracted from Section 3: Message Information Headers

> 

> *[reply endpoint]* : endpoint reference (0..1)

>     <deleted> If this property is present, the [message id] property

>     is REQUIRED

> 

Note that the W3C WS-Addressing spec no longer states the above constraint.

Proposed resolution could be reconsidered when updating to that

specification.

 

2.  The WS-Atomic Transaction interop document does reflect,

non-normatively, that the intent is element wsa:MessageID is mandatory

on non-terminal notification messages. (Conforming to 2004 WS-Addressing

specification)

 

Non-normative reference:

 

wsa:MessageID is specified Mandatory for following non-terminal

notification messages

in tables in Section 8" Message Snapshots" of WS-Atomic Transaction

Interop Scenarios,

ftp://www6.software.ibm.com/software/developer/library/ws-wsatscenario.doc

 

> WS-AtomicTransaction Messages, Completion Protocol

> Message Completion::Commit

> Message Completion::Rollback

> 

> WS-AtomicTransaction Messages, 2PC Protocols

> Messages for Volatile and Durable 2PC protocols are identical, this

> paragraph contains Durable2PC messages.

> Message Durable2PC::Prepare

> Message Durable2PC::Replay

> Message Durable2PC::Commit

> Message Durable2PC::Rollback

 



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