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).
>>
>>
> >
|