Anish,
What the resolution to i021 said was
that for the ***extensibility elements*** of the RMAssertion that those
present at the port trumped the extensions
at the binding, ad nauseum. It said nothing about the
meaning of wsp:Optional which is consistent
IMO with WS-Policy in that it is shorthand for a policy
statement that contains an ExactlyOne
containing two Alls, one with, and one without the RMAssertion.
e.g.
<wsp:Policy>
<wsrm:RMAssertion wsp:Optional="true"/>
</wsp:Policy>
is equivalent to:
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsrm:RMAssertion/>
</wsp:All>
<wsp:All>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
When you attach policy to a port, it
applies to that port. It means that RM is optional for all messages
sent to that port. When you assert a
policy statement at the message level, it asserts for that message
level. You can't undo it at the port
level.
IMO, there is no issue here. I propose
we close with no action.
Cheers,
Christopher Ferris
STSM, Software Group Standards Strategy
email:
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
Anish Karmarkar <>
wrote on 04/20/2006 03:13:25 PM:
> Marc Goodner wrote:
> > Anish, the text you quote as being in the spec is from the resolution
to
> > issue 21 [1, 2], it is not however in CD3 which is what most
of us have
> > to look at right now.
>
> Yes, it is not in CD3, but is part of issue 21 resolution and editors'
> draft.
>
> > Your proposed resolution says to make it clear how
> > wsp:Optional is handled when the assertion is attached at more
than one
> > WSDL construct. We discussed this extensively in resolving issue
21 and
> > I thought it was reflected in the resolution the TC accepted.
>
> I didn't see anything in the resolution that talked about wsp:Optional.
> But yea we did discuss wsp:Optional in the context of issue 21, but
IIRC
> it was in the context of what wsp:Optional means wrt to input v. output
> messages. We didn't really say anything about how this is factored
into
> merging policies when they are attached at various wsdl artifacts.
>
> > I agree it
> > is implied but not clarified by the text you quote, but isn't
it
> > clarified by the text describing the requirements when attaching
the
> > assertion to the input/output/fault?
> >
>
> This requirement (to attach RM assertion at the binding- or port-level
> with wsp:Optional='true' whenever there is a message-level RM assertion)
> is what got me thinking. If you assume that
> RM-policy-assertion(port) trumps RM-policy-assertion(binding) which
in
> turn trumps RM-policy-assertion(message)
> AND
> having a message-level assertion requires that there must be a binding-
> or port-level assertion, then
> the message-level assertion is completely pointless (as it will always
> be overridden by binding- or port-level assertion which must be present).
>
> What I find message level assertion useful for is:
> saying that RM is *required* for a particular message while saying
at
> the same time that the port/binding will *support* RM for all other
> messages in that binding/port.
>
> But if binding- or port-level assertion always wins then I can never
say
> the above, defeating the whole idea behind the resolution of issue
21.
>
> {I hope the WSP experts will educate me if this is already resolved
by
> WSP and friends}
>
> -Anish
> --
>
> > 1 Issue 21
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i021
> >
> > 2 Issue 21 resolution (+ additional line notes in issue list)
> > http://lists.oasis-open.org/archives/ws-rx/200603/msg00188.html
> >
> > Marc Goodner
> > Technical Diplomat
> > Microsoft Corporation
> > Tel: (425) 703-1903
> > Blog: http://spaces.msn.com/mrgoodner/
> >
> >
> > -----Original Message-----
> > From: Anish Karmarkar [mailto:]
> > Sent: Wednesday, April 19, 2006 11:20 PM
> > To: wsrx
> > Subject: [ws-rx] NEW ISSUE: What is the effective policy when
RM policy
> > assertion is present at multiple places?
> >
> > Title: What is the effective policy when RM policy assertion
is present
> > at multiple places?
> >
> > Description:
> >
> > WSRMP spec currently contains the following text:
> >
> > "If the RM policy assertion appears in a policy expression
attached to a
> >
> > wsdl:binding as well as to the individual wsdl:binding level
message
> > definitions(wsdl:binding/wsdl:operation/wsdl:input,
> > wsdl:binding/wsdl:operation/wsdl:output,
> > wsdl:binding/wsdl:operation/wsdl:fault), the parameters in the
former
> > MUST be used and the latter ignored.
> > If the RM policy assertion appears in a policy expression attached
to a
> > wsdl:port as well as to the other allowed WSDL/1.1 elements,
the
> > parameters in the former MUST be used and the latter ignored."
> >
> > Firstly, we do not define any RM policy assertion parameters,
so I'm not
> >
> > sure what the above means. But it does give the impression that:
> > RM-policy-assertion(port) trumps RM-policy-assertion(binding)
which in
> > turn trumps RM-policy-assertion(message).
> >
> > Given that we do not define any parameters the above statement
doesn't
> > mean anything expect in the context of wsp:Optional. Unless WS-Policy
> > and friends define how wsp:Optional is dealt with in such cases,
I
> > believe we should define how things work in the realm of WSRM.
> > Specifically:
> >
> > If wsdl:binding/wsdl:operation/wsdl:input (or wsdl:output or
wsdl:fault)
> >
> > has <wsrmp:RMAssertion wsp:Optional='false'/> and wsdl:binding
has
> > <wsrmp:RMAssertion wsp:Optional='true'/> then the message-level
> > assertion should trump the binding-level assertion (i.e. RM is
mandatory
> >
> > for that message). The message-level assertion is more specific
and that
> >
> > is the one that should be used (for that message) than the binding-level
> >
> > assertion.
> >
> > Similarly,
> >
> > If wsdl:binding has <wsrmp:RMAssertion wsp:Optional='false'/>
and
> > wsdl:service/wsdl:port has <wsrmp:RMAssertion wsp:Optional='true'/>
then
> >
> > the binding-level assertion should trump the port-level assertion
(i.e.
> > RM is still mandatory for that binding). The binding-level assertion
is
> > a contract that must be adhered to by any port that uses it (one
could
> > argue that the assertion at the port is in violation of the binding
> > contract).
> >
> >
> > Justification:
> >
> > See above.
> >
> > Target: wsrm policy
> >
> > Proposal:
> >
> > Include language in the spec that makes it clear how wsp:Optional
is
> > handled when RM assertion is present at more than one WSDL constructs.
> >
