[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: slightly new i021 proposal
Firstly, before anyone (or Umit) ticks me off, this is not MY proposal. It is in effect an amalgam of previous proposals. Secondly, the intent of this proposal is to effectively take the previous proposal from Sanjay, amended by Chris, and make one key change. The change is for us to define our own model of what "optional" means. The reason is that I think that if we have the wsp:Optional marker on output messages it has an unintended consequence that it implies the Service Client can and should support RM. I see this policy being used in the following ways. 1) simply mark a whole endpoint optional. RM can be used on either path or not without problems 2) mark a whole endpoint non-optional. RM must be used on all interactions. 3) mark the endpoint optional and certain messages with optional markers. This is a way expressing a preference that these messages are delivered reliably. For example, mark all input messages optionally reliable. 4) mark the endpoint optional and certain messages non-optional. This expresses that these specific messages MUST be delivered reliably. One valid approach to this is to deliver all messages reliably. Paul Based on WSRMP WD06/CD3 In section 2.2 change: Replace Line 101 with : <wsrmp:RMAssertion [optional="true"]? ... > Replace lines 108-111 with /wsrmp:RMAssertion/@wsrmp:optional="true" The behavior indicated by the assertion is optional - that WS-ReliableMessaging MAY or MAY NOT be used. The attachment of an assertion marked optional does not imply that either the service client or service provider implements either or both an RMD or an RMS, and if no sequence is available, the interaction SHOULD continue unreliably. Replace the entire content of section 2.3 (Assertion Attachment) in the WS-RM Policy specification with the following: The RM policy assertion is allowed to have the following Policy Subjects [WS-PolicyAttachment]: Endpoint Policy Subject Message Policy Subject WS-PolicyAttachment defines a set of WSDL/1.1 [WSDL 1.1] policy attachment points for each of the above Policy Subjects. Since an RM policy assertion specifies a concrete behavior, it MUST NOT be attached to the abstract WSDL policy attachment points. The following is the list of WSDL/1.1 elements whose scope contains the Policy Subjects allowed for an RM policy assertion but which MUST NOT have RM policy assertions attached: wsdl:message wsdl:portType/wsdl:operation/wsdl:input wsdl:portType/wsdl:operation/wsdl:output wsdl:portType/wsdl:operation/wsdl:fault wsdl:portType The following is the list of WSDL/1.1 elements whose scope contains the Policy Subjects allowed for an RM policy assertion and which MAY have RM policy assertions attached: wsdl:port wsdl:binding wsdl:binding/wsdl:operation/wsdl:input wsdl:binding/wsdl:operation/wsdl:output wsdl:binding/wsdl:operation/wsdl:fault If an RM policy assertion is attached to any of: * wsdl:binding/wsdl:operation/wsdl:input * wsdl:binding/wsdl:operation/wsdl:output * wsdl:binding/wsdl:operation/wsdl:fault then an RM policy assertion, specifying optional=true MUST be attached to the corresponding wsdl:binding or wsdl:port, indicating that the endpoint supports WS-RM. Any messages, regardless of whether they have an attached Message Policy Subject RM policy assertion, MAY be sent to that endpoint using WS-RM. Additionally, the receiving endpoint MUST NOT reject any message belonging to a Sequence, simply because there was no Message Policy Subject RM policy assertion attached to that message. If the RM policy assertion appears in a policy expression attached to a wsdl:binding as well as to the individual wsdl:binding level message definitions(wsdl:binding/wsdl:operation/wsdl:input, wsdl:binding/wsdl:operation/wsdl:output, wsdl:binding/wsdl:operation/wsdl:fault), any parameters or extensibility elements in the former MUST be used and the latter ignored. If the RM policy assertion appears in a policy expression attached to a wsdl:port as well as to the other allowed WSDL/1.1 elements, any parameters or extensibility elements in the former MUST be used and the latter ignored. -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://feeds.feedburner.com/bloglines/pzf paul@wso2.com "Oxygenating the Web Service Platform", www.wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]