[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"
In Ian's last email, MustUnderstand is the way of getting MUST NOT semantics: if the service doesn't understand the context, it faults. OK, maybe there's scope for debate over this approach, but that's secondary. What remains (via WS-P) should be MUST and MAY as far as I can see. No need for anything else.
Mark.
-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Wed 5/17/2006 11:43 AM
To: Mark Little
Cc: Ian Robinson; ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"
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).
> >>
> >>
> > >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]