Re: [ws-rx] i021 Proposal

[Christopher B Ferris <chrisfer@us.ibm.com>]

Anish,

Please see below.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

Anish Karmarkar <Anish.Karmarkar@oracle.com>
wrote on 02/23/2006 02:36:21 PM:

> Christopher B Ferris wrote:
> > 
> > Thinking about this proposal, I am concerned that what is not
clear is 
> > what is the expected behavior
> > should the policy be expressed as Message Policy Subject (MPS)
for 
> > selected input and/or output|fault messages
> > and then either side goes a step further and sends messages that
have 
> > NOT been designated as reliable.
> > 
> 
> An absence of an RM assertion does not tell you anything -- RM may
be 
> supported or not.
> I don't think this has anything to do with whether an RM assertion
is 
> expressed as MPS. What would happen if there wasn't any RM assertion
on 
> the port/binding/message and a RM message is received? The same thing
> would happen in this case.
> 
> > Specifically, I am concerned that there might be two flavors
of RM 
> > implementation: one that only supports
> > EPS and one that supports MPS granularity. It would be a problem
IMO if 
> > these two flavors of RM implementation
> > did not interoperate.
> > 
> 
> I don't quite see the issue. Implementations have to support the spec,
> you can't pick and chose to support one part of the spec and not the
other.

Just because a spec says you MAY do X, does not imply
that an implementation
MUST support such capability unless the spec says
that an implementation
MUST be capable of doing X.

Nothing in Sanjay's proposal said anything about whether
an endpoint
(RMD or RMS) MUST support use of MPS. I would certainly
not be in favor
of any such language, as I am not certain that we
like the idea
due to the fact that it requires that the RMS (at
least) have access
to the WSDL and policy and we are concerned about
the potential 
performance implications of having to parse the message
to determine
whether to apply RM or not.

> 
> In any case, if the implementation does not support MPS then it would
> not understand assertions attached to the messages and would not know
> apriori wither RM is required/supported.

Which is exactly my point, they might not interoperate.

> 
> > I am thinking that what may be needed is two assertions: one
for the 
> > endpoint (EPS) that effectively proclaims
> > that "this endpoint supports WS-RM", period. A second
assertion with MPS 
> > could then be used to decorate
> > the WSDL to indicate which messages SHOULD be sent reliably,
but would 
> > NOT preclude that other messages
> > be sent reliably.
> > 
> 
> I'm not sure why we can't say the same thing while using a single
QName. 
>   When processing a policy assertion it is important to take
into 
> account where the assertion is attached -- isn't that essentially
what 
> WS-policy model is?

I think that the two assertions have different semantics.

> 
> > Alternately, there would likely need to be some statement made
to the 
> > effect that if ONLY MPS is specified, then
> > there is an implicit claim that the assertion ALSO applies to
EPS to 
> > indicate "RM supported". However, I am not clear as
to whether
> > Policy effectively supports this notion of transitive policy
subject UP 
> > the food-chain.
> > 
> > I think that unless we have such a notion of two-levels of policy
> > subject as applied to RM
> > assertions, that there will be potential interoperability issues.
For 
> > instance, what if a message that was
> > NOT designated as being reliable were sent reliably? If the RMD
> > implementation were to reject this message, then the
> > Sequence is effectively broken because the MessageNumber has
been used 
> > but will never be acknowledged.
> > 
> 
> Isn't that true for a lot of cases, where it is not know apriori that
RM 
> is supported. I would imagine that if RM is supported at an endpoint
> then the WSDL port would be annotated.
> For example, I can see a scenario where RM assertion is specified
at the 
> messages with required=true and the same assertion is specified at
the 
> port with required=false (or whatever is the right term in WS-Policy).
> This would communicate to the clients that for a particular message
RM 
> must be used, for other message you may.
> 
> > I'm not suggesting that this is the behavior that one would expect,
just 
> > that given what it states in the proposal
> > below, it isn't clear what responsibility the RMS and RMD have.
> > 
> > Thus, I am thinking that we really need two assertions, one with
EPS and 
> > the other with MPS to get this
> > right, and to ensure interoperability.
> > 
> > The semantic of the one with EPS is "WS-RM Supported|Required"
and MAY 
> > be attached to either
> > a wsdl:binding or wsdl:port and MUST NOT be attached to any other
WSDL 
> > component.
> > 
> > The semantic of the one with MPS is "SHOULD be sent reliably".
It MAY be 
> > attached to any of:
> > 
> >     * wsdl:binding/wsdl:operation/wsdl:input
> >     * wsdl:binding/wsdl:operation/wsdl:output
> >     * wsdl:binding/wsdl:operation/wsdl:fault
> > 
> > It MUST NOT be attached to any other WSDL component. When used
in the 
> > context of an
> > endpoint that proclaims "WS-RM Required" (e.g. <wsrmp:RMAssertion
> > wsp:Optional="false"/>) then
> > the designated message(s) MUST be sent as part of an RM Sequence,
> > otherwise, the receiving
> > endpoint SHOULD generate a fault (TBD with semantics of "RM
REQUIRED"). 
> > When used
> > in the context of an endpoint that proclaims "WS-RM Supported"
(e.g. 
> > <wsrmp:RMAssertion wsp:Optional="true"/>)
> > then the sending endpoint MAY send the designated messages as
part of an 
> > RM Sequence.
> > The receiving endpoint MUST NOT generate a "RM REQUIRED"
fault. The 
> > receiving endpoint
> > SHOULD (MUST?) permit messages that have not been designated
"SHOULD be 
> > sent reliably" to be
> > included in an RM Sequence.
> > 
> > Finally, there is the issue of the scope of the EPS assertion.
Does it 
> > apply only to messages sent to
> > the service provider endpoint, or does it apply to messages sent
in 
> > either direction?
> > 
> > One use case that needs to be covered is that for pub/sub, where
the 
> > subscriber endpoint is the one
> > that would want to assert that the messages be delivered reliably
(or 
> > not as the case may be),
> > but where the service provider (the publisher) could go either
way (RM 
> > supported).
> > 
> > Doug had a proposal that provided for the wsa:ReplyTo EPR to
carry in 
> > its metadata, a policy
> > assertion that indicated whether RM was supported/required, much
as the 
> > service provider can
> > do by decorating its WSDL description.
> > 
> > The question then becomes, how does one express this if it is
to deal 
> > with MPS as opposed to
> > simply EPS? WS-PolicyAttachments has defined a domain expression
for EPR 
> > which we could
> > use, but that would only give us EPS.
> > 
> > We could invent some domain expression for WSDL and use that
for an 
> > external policy attachment
> > using PolicyAttachment. I am not comfortable having the WS-RX
TC do a 
> > domain expression for
> > WSDL though, and we'd have to do more than one flavor anyway
(sigh).
> > 
> > Quite frankly, I am not at all confident that the proposal below
really 
> > addresses all of the issues.
> > I personally think that we would be best off for NOW going with
JUST EPS 
> > scope for the
> > assertion and having the RM assertion mean:
> > 
> > <wsrmp:RMAssertion wsp:Optional="true"/> == WS-RM
supported. The sending 
> > endpoint MAY choose to use
> > a Sequence to send any (or all) of the messages sent to the endpoint
as 
> > described in the WSDL.
> > 
> > <wsrmp:RMAssertion wsp:Optional="false"/> ==
WS-RM required. The sending 
> > endpoint MUST use a
> > Sequence for all messages sent to that endpoint as described
in the WSDL.
> > 
> > When the policy assertion is attached to a WSDL port/endpoint
or 
> > binding, it applies to messages
> > sent from the service consumer to the service provider.
> > 
> > When attached to an EPR, it means any (or all) messages sent
to the 
> > referenced endpoint be sent
> > using RM.
> > 
> > Cheers,
> > 
> > Christopher Ferris
> > STSM, Emerging e-business Industry Architecture
> > email: chrisfer@us.ibm.com
> > blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> > phone: +1 508 377 9295
> > 
> > "Patil, Sanjay" <sanjay.patil@sap.com> wrote
on 02/22/2006 03:33:06 PM:
> > 
> >  > Here is an updated proposal for resolving the long
pending issue
> >  > i021. The key difference in comparison to what exists
in the WS-RM
> >  > Policy specification today is that -- the proposal
allows Message
> >  > Policy Subject (in addition to the Endpoint Policy
Subject) for the
> >  > RM Policy assertion.
> >  > I would also like to bring to your notice that this
proposal:
> >  > -- Avoids text that would repeat the semantics already
addressed in
> >  > WS-PolicyAttachment, for example, an Endpoint Policy
Subject applies
> >  > to behaviors associated with all the message exchanges
of the
> >  > endpoint, and applies to aspects of both communicating
with as well
> >  > as instantiating the endpoint. So the proposal would
seem a bit
> >  > short and dry to some people!
> >  > -- Does not include any recommendations for which
wsdl elements
> >  > (among those that are allowed by the proposal - wsdl:port
Vs. wsdl:
> >  > binding Vs.binding level messages) are more appropriate
for policy
> >  > attachment, since this may simply be a matter of best
practices and
> >  > there are no strong technical reasons for the specification
to
> >  > promote one approach over another, IMO.
> >  > -- Does not include any text related to whether and
how EPR
> >  > contained policies may interact with the WSDL attached
policies,
> >  > since I couldn't arrive at any precise and useful
(normative) text
> >  > in this regard.
> >  > Please try to send in your comments before the conf-call
tomorrow 
> > (2/23)!
> >  > -- Sanjay
> >  > 
> > 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > 
> >  > Replace the entire content of section 2.3 (Assertion
Attachment) in
> >  > the WS-RM Policy specification with the following:
> >  > The RM policy assertion is allowed to have the following
Policy
> >  > Subjects [WS-PolicyAttachment]:
> >  > Endpoint Policy Subject
> >  > Message Policy Subject
> >  >
> >  > WS-PolicyAttachment defines a set of WSDL/1.1 [WSDL
1.1] policy
> >  > attachment points for each of the above Policy Subjects.
Since an RM
> >  > policy assertion specifies a concrete behavior, it
MUST NOT be
> >  > attached to the abstract WSDL policy attachment points.
> >  > The following is the list of WSDL/1.1 elements whose
scope contains
> >  > the Policy Subjects allowed for an RM policy assertion
but which
> >  > MUST NOT have RM policy assertions attached: 
> >  > wsdl:message
> >  > wsdl:portType/wsdl:operation/wsdl:input
> >  > wsdl:portType/wsdl:operation/wsdl:output
> >  > wsdl:portType/wsdl:operation/wsdl:fault
> >  > wsdl:portType
> >  >
> >  > The following is the list of WSDL/1.1 elements whose
scope contains
> >  > the Policy Subjects allowed for an RM policy assertion
and which MAY
> >  > have RM policy assertions attached:
> >  > wsdl:port
> >  > wsdl:binding
> >  > wsdl:binding/wsdl:operation/wsdl:input
> >  > wsdl:binding/wsdl:operation/wsdl:output
> >  > wsdl:binding/wsdl:operation/wsdl:fault
> >  >
> >  > 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.