Re: [ws-rx] i021 Proposal

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

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.

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

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. 

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.