[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] slightly new i021 proposal
Corrections or clarifications:
>> /wsrmp:RMAssertion/@wsrmp:optional="true"
>>
>> The behavior indicated by the assertion is optional - that
>> WS-ReliableMessaging MAY or MAY NOT be used.
Remove "or MAY NOT" - redundant, and actually misleading (MAY NOT is not an RFC2119 keyword, and would mean "cannot" here..)
>> and if no sequence is available, the
>> interaction SHOULD continue unreliably
That seems to authorize the following scenario: server is actually using RM for "out" messages (was optional policy) based on a prior agreement with client. But for some reason, Client RMD is unable to allocate sequences for "out" messages. The server then bypasses its own RMS and continues unreliably, ignoring the decision to use RM with client. That would be at odd with Ashok interpretation:
> But at the end of it the server and the client will agree on whether
> the message shd be transmitted reliably or not.
Shouldn't we say something like:
>> /wsrmp:RMAssertion/@wsrmp:optional="true"
>>
>> "The behavior indicated by the assertion is optional: the use of RMS by server (for out messages) or RMD (for in messages) is conditioned by an assumed prior agreement between client and server, meaning both parties SHOULD be aware whether or not RM is expected for every exchange that concerns the optional policy subject. The behavior on either side in case of unfulfilled expectation is itself subject to an agreement that is out of scope."
Because this is different than saying "the server is free to randomly send back messages (in case policy subjects are out messages) reliably or not without warning - client beware...", or than saying "the server may attempt to send back reliably, and if it can't due to client-side problem, will automatically switch to non-reliable". Either one of these two behaviors may actually be desired, but that would precisely be part of the above agreement.
Jacques
-----Original Message-----
From: Paul Fremantle [mailto:paul@wso2.com]
Sent: Wednesday, March 08, 2006 12:22 AM
To: Ashok Malhotra
Cc: wsrx
Subject: Re: [ws-rx] slightly new i021 proposal
Ashok
Suppose we had a client policy. Maybe the client has published an exact
mirror of the WSDL with an Out-In, and attached policy to it. Suppose
the policy has an RM wsp:Optional marker on the response (client-in)
message.
[ I am assuming this is the same semantic as there being an RM
wsp:Optional on the server-out message]
If the server looks at this, it sees this optional as meaning both RM
and not RM. Given this, the Server can choose which of these policy
options it likes.
Now it decides it wants RM, and therefore it chooses RM. From the
server's perspective, the client has said it supports RM.
Let me give you another exemplar. If I publish RM wsp:Optional on my
server, and then you try and create a reliable connection and you never
can, then you will phone me up (possibly waxing irate) saying that my
policy is incorrect. When you publish a space of assertions, the idea is
that you as the publisher, support ALL of them, and the consumer needs
to support ONE of them.
The only unclarity is how this applies to responses/out messages. If my
assumption is that it is equivalent to mirroring the WSDL then the
wsp:Optional is not appropriate for us.
Paul
Ashok Malhotra wrote:
> Paul:
> Thank you for trying to ferret out the confusion.
>
> My understanding of wsp:optional is a bit different and I
> don't think we need to define our own optional semantics.
>
> If you attach wsp:optional = 'true' to an output message
> you are saying that that message may or may not be transmitted
> reliably. In WS-Policy terms this means that there will
> be a policy option created that will transmit that message reliably
> and an option created that will not transmit the message reliably.
> Both policy options are equally valid and which option is chosen
> depends on what the client and server agree on.
>
> If a server attaches <RM optional = 'true'> to an output message
> it says that the message may or may not be transmitted reliably.
> The client may or may not be prepared to accept the message reliably.
> There needs to be communication between the client and server to
> determine whether the message is transmitted reliably or not.
> This may take the form of policy intersection or negotiation.
> But at the end of it the server and the client will agree on whether
> the message shd be transmitted reliably or not.
>
>
> All the best, Ashok
>
>
>
>> -----Original Message-----
>> From: Paul Fremantle [mailto:paul@wso2.com]
>> Sent: Tuesday, March 07, 2006 9:36 AM
>> To: wsrx
>> Subject: [ws-rx] 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
>>
>>
>>
>>
>
>
--
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]