[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]