RE: [ws-rx] i021 Proposal

["Patil, Sanjay" <sanjay.patil@sap.com>]

> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Wednesday, Feb 22, 2006 15:08 PM
> To: Patil, Sanjay
> Cc: wsrx
> Subject: Re: [ws-rx] i021 Proposal
> 
> 
> 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.
I don't think we can normatively specify the behavior in this situation.
IMO, the larger question here is - are policies allowed to be in effect
when not explicitly attached?

OTOH, I believe that this problem exists even with the current spec
where only EPS is allowed. Note that we allow targeting the same
Sequence to multiple ports, and it is possible that some of the messages
in the Sequence may be destined to ports that do not have RM Assertion
attached.

> 
> 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. 
By defining rules for resolving RM assertion attachments to different
WSDL elements, we should be able to deterministically say whether EPS or
MPS is in effect. I don't think two separate flavors of RM assertion are
needed as such.

> 
> 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 thought that this was always true, that is, by attaching RM assertion
to a particular WSDL component, you are not necessarily precluding
anything for other WSDL components! If an RM assertion is attached to a
particular message, that assertion by itself is not saying anything
about other messages in the same context.
 
> 
> 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 don't see a need for this. Sure, all messages first hit the endpoint
but that does not mean that every Policy Subject needs to specify an
endpoint behavior.
 
> 
> 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.
Please see my first comment.
 
> 
> 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.
The use of wsp:Optional to specify whether RM is required and the
generation of faults in cases where the requirements are violated is
orthogonal to the issue of which Policy Subjects should be allowed, IMO.
 
> 
> 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? 
Policy framework may be a bit vague on this, but my interpretation is
that when EPS is used, all message exchanges and both directions are
affected. Here is a cut-paste from Sep 2004 Policy Attachment spec:
"An Endpoint Policy Subject applies to behaviors associated with an
entire endpoint of
the service, irrespective of any message exchange made. This includes -
but is not
limited to - aspects of communicating with or instantiating the
endpoint."

I am not sure if we want to override this framework level semantic in
our specs (without good reason of course)!

> 
> 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.
As I noted in my proposal, I avoided any treatment of EPR since the
rules of expression and interactions of EPR policies with WSDL attached
policies are not clear (at least to me). If you have any specific ideas
here, I suggest that you open a separate issue, since this issue may be
pertinent even with the current spec.

> 
> 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: 
I fail to relate the concerns you previously raised to your above
conclusion. I think that allowing MPS is a fundamental part of the
solution for i021.

> 
> <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.
This may be violating the policy framework level assumptions. Not sure
if this is a good idea.

Overall, I think the question to ask ourselves is - whether we want to
allow message level granularity for RM assertion attachment to solve the
problem raised by i021, which is - Does RM Policy (have to) apply
two-way? I believe the proposal I submitted builds upon the sentiment I
heard in the TC that message level granularity should be allowed! If you
disagree, we should talk more!
-- Sanjay 

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