[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"
As I understand it, the options currently supported are:
That's not how I read it. He wants a server to accept the request, not have it fail, despite the fact that it has a superfluous context that SHOULD NOT be there. Or at least, that's how I read Ian's last sentence. I do feel that explicitness (in names and in definitions of meanings) would be very helpful. Alastair Mark Little wrote:
Mark. -----Original Message----- From: Alastair Green [mailto:alastair.green@choreology.com] Sent: Wed 5/17/2006 11:21 AM To: Ian Robinson Cc: Mark Little; ws-tx@lists.oasis-open.org Subject: Re: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional" Ian, I agree with your argument that presence of a context which is recognized but discarded by the provider is the desired behaviour. I think it comes back to your earlier question on how best to represent the three values: {required, optional, will be ignored}. Is there a strong argument against three explicit assertions? Wouldn't that be clearest? Alastair Ian Robinson wrote: > > > I think we need to exercise caution with any proposal to consider a MUST > NOT policy. > > We should remember that the purpose of the ATAssertion is to advertise to > the requester the transactional requirements of the provider service: > For a service that requires a trasaction context, a MUST semantic is > useful. > For a service which does not require a transaction context but whose > environment understands transaction contexts, a SHOULD NOT semantic is more > useful than a MUST NOT semantic. An example is a service deployed as an EJB > with TX NotSupported. > For a service that will run under a transaction context if one is provided, > then a MAY semantic is useful. > For a service that does not understand transaction contexts then any > transaction context will cause a MustUnderstand fault. > > For a service whose requester MUST NOT send a transaction context but whose > environment understands transaction contexts, we could consider a MUST NOT > policy alternative but I think this would be quite unusual and certainly > should not be the "default" semantic used in the absence of any policy > alternative. This is about as useful as an EJB deployed with TX Never, > which is something we rarely see in practise. There should be no reason to > cause a request a fail if an unnecessary (but understood) > CoordinationContext is flowed. > > Ian > > > > > "Mark Little" > <mark.little@jbos > s.com> To > <ws-tx@lists.oasis-open.org> > 17/05/2006 14:48 cc > > Subject > Re: [ws-tx] Issue 045 - WS-AT: > Meaning of "wsp:Optional" > > > > > > > > > > > Do we really need to differentiate between SHOULD NOT and MAY? Seems to me > that it would be more straightforward to go for either MUST, MUST NOT, and > MAY, or MUST and MAY (c.f., the old CosTransactions::TransactionalObject > approach). My preference would be for the former though. > > If we look at the actual definitions of the words: > > SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > and > > MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > > So although there are differences between SHOULD NOT and MAY in general, in > this case (how WS-TX uses them), I'd feel more comfortable not straying > into those vagueries where transaction propagation is concerned. > > Mark. > > > Ian Robinson wrote: > >> >> 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.html (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]