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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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