[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"
Although WS-Policy does not define the semantics of missing assertions, it is not unreasonable to assume that if a particular policy assertion does not appear, it means "don't do that". For example, if an endpoint does not have a Reliable Messaging assertion in its policy it's fair to assume that it does not want a reliable protocol used. And if there is no encryption assertion, this seems to imply that messages shd not be encrypted. But there are some tricky areas. For example, if there is no encoding assertion does this mean that no encoding shd be used? It seems to depend on whether the absent assertion is among the set of 'known assertions'. In any case, I think WS-TX is free to adopt the absence-means-don't-do-it semantic but it would be good if this was spelt out clearly in the spec. All the best, Ashok > -----Original Message----- > From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] > Sent: Monday, May 15, 2006 3:36 PM > To: Monica J. Martin > Cc: Monica.Martin@Sun.COM; Ram Jeyaraman; ws-tx@lists.oasis-open.org > Subject: Re: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional" > > > > > > Monica, > The 3 semantics that WS-AT is trying to represent are: > a policy alternative that indicates that a tx context MUST be > sent by a requester a policy alternative that indicates that > a tx context SHOULD NOT be sent to a requester a policy > alternative that indicates that a tx context MAY be sent to a > requester. > > It is the TX domain that is defining presence of the policy > assertion as "MUST send TX context". I don't understand why > it is a misuse of Policy for the TX domain to define absence > of this assertion as "SHOULD NOT send TX context". If this is > a misuse of Policy, then how could the above 3 alternatives > be more properly expressed? > > Regards, > Ian Robinson > > > > > > "Monica J. > > Martin" > > <Monica.Martin@Su > To > n.COM> Ram Jeyaraman > > Sent by: > <Ram.Jeyaraman@microsoft.com> > Monica.Martin@Sun > cc > .COM > ws-tx@lists.oasis-open.org > > Subject > Re: [ws-tx] Issue 045 > - WS-AT: > 08/05/2006 21:01 Meaning of > "wsp:Optional" > > > > > > > > > > > > > > > > > > >> jeyaraman: It is possible for a client to infer MAY > behavior based on > >> the normalized policy alternatives (MUST and SHOULD NOT). > >> > >> For example, an operation may advertise a compact form of the AT > >> policy assertion, such as: > >> > >> 1 <wsdl:operation name="TransferFunds" > > >> 2 <wsp:Policy> > >> 3 <wsat:ATAssertion wsp:optional="true" /> > >> 4 </wsp:Policy> > >> 5 </wsdl:operation> > >> > >> A consumer may normalize the above policy expression (in compact > >> form) into two policy alternatives: one with AT assertion > (MUST) and > >> another without it (SHOULD NOT). These two alternatives > indicate that > >> the AT behavior MAY be engaged. > >> > >> Hence, there is no need for a new attribute. > > > mm1: Ram, let's separate Issue 45 [reference 1] concerns here: > > (1) Composition with WS-Policy and the use of the compact form > (shortcut for expressing multiple alternatives) > (2) WS-AT intended use of this optional attribute > > Clearly, choices made where wsat:ATAssertion > wsp:Optional="true" is used or not, and if the policy is > normalized, have impacts to implementation and interoperability. > > (1) In Section 3.2 of WS-Policy [reference 2]: > > "An assertion whose type is part of the policy's vocabulary > but is not included in an alternative is explicitly > prohibited by the alternative." > > Interpretation of the above WS-Policy text indicates that the > WS-AT description of the compact shortcut, > wsp:Optional="true", has to be the policy alternatives "MUST" > and "MUST NOT" rather than the current specified alternatives > of "MUST" and "SHOULD NOT". Otherwise, WS-AT is misusing WS-Policy. > > (2) WS-Policy does not prohibit postponing the selection of a > final policy alternative, and this could be done with > normalized forms, at the expense of a complex client > interface. But, your simple example contains only a single > assertion. In actual applications, a policy alternative can > and likely will contain multiple types of policy assertions > [reference 3]. > According to WS-Policy, a wsdl:binding/wsdl:operation can > have a set of policy alternatives, one of which MUST be > chosen. The final selection of one alternative could be > delayed so long as they are acceptable to both client and service. > However, it is unlikely that all types of assertions can > support postponing the selection of a final policy alternative. > > In Section 5.2, WS-AT: > > "The absence of the assertion is interpreted to mean that a > transaction SHOULD NOT be flowed inside a requester's message." > > There are two points of view to the above stated behavior. If > a requestor's message does flow a transaction that SHOULD NOT > have been flowed, the current WS-AT specification leaves > undefined how the service would handle such an unexpected transaction. > > The WS-AT specification does not state what happens when a > policy assertion is not met. We should define that a service > interpretation of the policy assertion takes precedence when > the requestor flows a transaction context it should not have > flowed. The service can either silently ignore the > non-requested transaction context or it can fault on the > mismatch between client and service interpretation of the > wsat policy assertion. > > Thanks. > > > ========== > [1] Issue 45: > http://lists.oasis-open.org/archives/ws-tx/200603/msg00168.htm > l (on public site) > > [2] Reference: http://www.w3.org/Submission/WS-Policy/, see > some of the sections important to this discussion: > [start] > p. 6, 3.1 Policy Assertion > "A policy assertion identifies a behavior that is a requirement (or > capability) of a policy subject." > > p. 6, 3.2 Policy Alternative > "A policy alternative is a logical construct which represents > a potentially empty collection of policy assertions. An > alternative with zero assertions indicates no behaviors. An > alternative with one or more assertions indicates behaviors > implied by those, and only those assertions."... > > "An assertion whose type is part of the policy's vocabulary > but is not included in an alternative is explicitly > prohibited by the alternative." > > p. 7, 3.4 Web services > "A requester may choose any alternative since each is a valid > configuration for interaction with a service, but a requester > MUST choose only a single alternative for an interaction with > a service since each represents an alternative configuration." > > "A policy assertion is supported by a requester if and only > if the requester satisfies the requirement (or accommodates > the capability) corresponding to the assertion." > > p. 10, 4.3.1 Optional Policy Assertions > "To indicate that a policy assertion is optional, this > specification defines an attribute that is a syntactic > shortcut for expressing policy alternatives with and without > the assertion." [schema for Optional follows] > "/Assertion/@wsp:Optional If true, the expression of the > assertion is semantically equivalent to the following: > <wsp:ExactlyOne> > <wsp:All><Assertion ...> ... </Assertion> </wsp:All> <wsp:All > /> </wsp:ExactlyOne> > > If false, the expression of the assertion is semantically > equivalent to the following: > <wsp:ExactlyOne> > <wsp:All><Assertion ...> ...</Assertion></wsp:All> > > Omitting this attribute is semantically equivalent to > including it with a value of false." [an example follows with > an actual assertion] [end] > > [3] According to WS-Policy, an alternative is a set of > options (assertions). > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]