RE: [ws-rx] i021 Proposal

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

Umit,

Effectively, yes. I think that there
will be opportunity in the future to handle things
in the manner I have described, with
two assertions, building off of the one
we currently have defined with EPS.

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

"Yalcinalp, Umit" <umit.yalcinalp@sap.com>
wrote on 02/22/2006 06:17:08 PM:

> Are you effectively saying "close with no action" ?
>  
> --umit
>  
> 
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Wednesday, Feb 22, 2006 3: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. 
> 
> 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.