As I understand it, the options currently supported are:
required/optional/will be ignored/
maps to the policy assertions as follows:
MUST/MAY/SHOULD_NOT/ -> wsat:ATAssertion/wsat:AT Assertion optional=true/no-policy
as Ian mentions an error (rejects) is indicated by returning a must_Understand fault.
Regards
Tom
Alastair Green <alastair.green@choreology.com>
05/17/2006 11:43 AM |
|
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:
- Unfortunately required/optional/will be ignored isn't what Ian has outlined. It sounds more like required/optional/error
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).
>>
>>
> >
