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] REL-21 & REL39 proposal


Hi Marc and all,


Regarding definition of elements usable beyond the reliable messaging I see two ways, we may follow:
1. Keep the specification inside the reliability layer, i.e. no elements are defined for general purpose and unnecessarily.
2. Specify the absolutely needed elements for "general" purpose, which may be replaced later on by a standard.

In our input specification, the "MessageHeader" is in question. Functionally it is for message identification and SOAP addressing/routing.

Message identification: this is needed, because the Acknowledge should refer to the message acknowledged ->I see two solutions
1. The messageID is in the ReliableMessage header, used only for reliable messaging
2. Definition of a general purpose message identification header, which contains the messageID and likely a timestamp optionally. This header may also carry an optional reference to the SOAP request messageID, for which the SOAP response message  arrived in case of req/resp MEP. The RMResponse should refer to the identifier of the message acknowledged. 

Routing: the "From" and "To" elements can not be used for real routing (just not enough), for that purpose are unneccessary. 

Addressing: there is no SOAP-addressing, SOAP just re-use the (underlying transport) HTTP addressing schema. As HTTP carries these addresses in end-to-end scenario, there is no need to include them in the SOAP message, unless the Acknowledge/Fault  for the message is required to another endpoint. This is solved in the ReliableMessage header by ReplyTo element, which should be OPTIONAL in my understanding. Based on this, I think, the "From" and "To", just as the "Service" elements are unnecessary.


Here is the schema snippet:

<xsd:element name="MessageHeader">
	<xsd:complexType>
		<xsd:sequence>
			<xsd:element ref="ns1:MessageId"/>
			<xsd:element ref="ns1:CorrMessageId" minOccurs="0"/>
			<xsd:element ref="ns1:Timestamp" minOccurs="0"/>
		</xsd:sequence>
		<xsd:attribute ref="soap:mustUnderstand" use="optional"/>
		<xsd:attribute name="id" type="xs:ID" use="optional"/>
                <xs:attribute ref="soap:actor" use="optional"/>
	</xsd:complexType>
</xsd:element>

<xsd:element name="MessageId" type="ns1:RFC2822MessageIdType"/>
<xsd:element name="CorrMessageId" type="ns1:RFC2822MessageIdType"/>
<xsd:element name="Timestamp" type="xsd:dateTime"/>



<xsd:element name="ReliableMessage">
	<xsd:complexType>
		<xsd:sequence>
			</xsd:element>
			<xsd:element ref="ns1:ReplyTo" minOccurs="0"/>
			<xsd:element ref="ns1:TimeToLive"/>
			<xsd:element ref="ns1:AckRequested" minOccurs="0"/>
			<xsd:element ref="ns1:DuplicateElimination" minOccurs="0"/>
		</xsd:sequence>
		<xsd:attribute ref="soap:mustUnderstand" use="required"/>
                <xsd:attribute name="id" type="xs:ID" use="optional"/>
	</xsd:complexType>
</xsd:element>

<xsd:element name="ReplyTo" type="xsd:anyURI"/>
<xsd:element name="TimeToLive" type="xsd:dateTime"/>
<xsd:element name="AckRequested">
	<xsd:complexType>
		<xsd:attribute name="synchronous" type="xsd:boolean" use="optional" default="false"/>
	</xsd:complexType>
</xsd:element>

<xsd:element name="DuplicateElimination">
	<xsd:complexType/>
</xsd:element>

<xsd:element name="RMResponse">
	<xsd:complexType>
		<xsd:sequence>
			<xsd:element name="MessageType">
				<xsd:simpleType>
					<xsd:restriction base="xsd:string">
						<xsd:enumeration value="Acknowledgment" />
						<xsd:enumeration value="Fault" />
					</xsd:restriction>
				</xsd:simpleType>
			</xsd:element>
			<xsd:element ref="ns1:RefToMessageId"/>
		< /xsd:sequence>
		<xsd:attribute ref="soap:mustUnderstand" use="required"/>
                <xsd:attribute name="id" type="xs:ID" use="optional"/>
	</xsd:complexType>
</xsd:element>

<xsd:simpleType name="RFC2822MessageIdType">
	<xsd:restriction base="xsd:string" />
</xsd:simpleType>

<xsd:element name="RefToMessageId" type="ns1:RFC2822MessageIdType"/>

What do you think ?

br,
Magdolna

-----Original Message-----
From: ext Goodner, Marc Andrue [mailto:marc.andrue.goodner@sap.com]
Sent: June 18,2003 16:53
To: wsrm@lists.oasis-open.org
Subject: [wsrm] REL-21 & REL39 proposal


REL-21 Proposal: 
3.1.1. <From> Element
The REQUIRED <From> element is used to specify the original sender node of the message. This is used by the WS-RM layer to unambiguously identify the original sender as there may be higher level addressing or routing schemes in place that have delivered the message to the current receiver node making the true origin of the message ambiguous to the current receiver node. The <From> element identifies the initial sender's endpoint to send the Acknowledgment or Fault Message to when the <ReplyTo> element in the ReliableMessage header is not present.
The value of this element MUST be a URI as defined in [RFC 2396].

3.1.2. <To> Element
The <REQUIRED> element is used to specify the ultimate receiver node of the message known to the sender.
The value of this element MUST be a URI as defined in [RFC 2396].

[MG] I don't think, the "From" and "To" elements should be included in the "MessageHeader" at all, just as the "Service" element. The upcoming first version of WS-RM 

REL-39 Proposal:
3.2.2. <ReplyTo> Element
This OPTIONAL element is used to specify a different endpoint than the initial sender to reply to with an Acknowledgment or Fault Message. Higher level addressing or routing schemes MAY supercede the value of the From element when <ReplyTo> is not used to indicate the endpoint to receive an Acknowledgment or Fault Message. Higher level addressing or routing schemes MUST NOT supercede the value of the ReplyTo element when it is used.
The value of this element MUST be a URI as defined in [RFC 2396].

You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php



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