OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] i021 proposal


 

> -----Original Message-----
> From: Paul Fremantle [mailto:paul@wso2.com] 
> Sent: Thursday, Feb 09, 2006 3:04 AM
> To: Patil, Sanjay
> Cc: wsrx
> Subject: Re: [ws-rx] i021 proposal
> 
> Sanjay
> 
> You are right. The proposal isn't yet fully clear on the meaning of 
> attaching WS-RM to a message or operation.
> 

That is not the real issue, see below. 

> How about if the following text was added, before the EPR text.
> 
> Attaching the RM assertion to a specific wsdl:input, wsdl:output, or 
> wsdl:fault construct indicates that the RM protocol MUST be used when 
> sending that message (or MAY if the assertion is marked optional).
> Attaching the RM assertion to a specific wsdl:operation construct 
> indicates that the RM protocol MUST be used for all messages (whether 
> input, output or fault) related to the operation(or MAY if 
> the assertion 
> is marked optional).
> Attaching the RM assertion to a specific wsdl:binding  construct 
> indicates that the RM protocol MUST be used for all messages (whether 
> input, output or fault) related to the binding (or MAY if the 
> assertion 
> is marked optional).
> Attaching the RM assertion to a specific wsdl:port construct 
> indicates 
> that the RM protocol MUST be used for all messages (whether input, 
> output or fault) related to the port (or MAY if the assertion 
> is marked 
> optional).
> Attaching the RM assertion to a specific wsdl:service construct 
> indicates that the RM protocol MUST be used for all messages (whether 
> input, output or fault) related to the service (or MAY if the 
> assertion 
> is marked optional).
> 
> You are also right about the EPR. I would recommend making the EPR 
> policy override the WSDL policy, but once again I think this 
> is an issue 
> with the overall WS-Policy Framework (i.e. a general Policy 
> issue not a 
> specific RX issue).
> 

I must agree that there is an issue which is beyond WS-RX here, but not
really about WS-Policy per se but metadata that is contained within an
EPR in general. EPR may have metadata that mimics WSDL constructs in
addition to policy assertions. 

EPR policy and WSDL policy may conflict and EPR may be stale. We punted
on this in the WS-Addressing wg. We left the question to be answered
using an unspecified lifecycle definition of the EPR or retrieval
mechanisms, such as WS-MEX that will help in resolving this issue.
Therefore, I am not sure it is a good idea recommend making the EPR
policy override the WSDL policy. Let me ask this. Can we guarantee that
the EPR will never be stale within an WS-RM context? 

Further, is the EPR policy about the EPR itself or the endpoint that it
represents? 
I have heard different answers to this last question depending on whom I
talked to. Can the EPR metadata contain both type of policy? By design,
it is possible. It is a bucket...

I think we should punt on overriding just like WS-A. 


> Thanks for your comments,

Thanks for the proposal. This is pretty much what I was suggesting as
well in my email [1] for using message level subject but it appears that
you want to allow outbound or fault messages as well. I need to think
about the consequence of this a bit further, so I do not think that
Sanjay's question is really answered by the text you added wrt to
applying the RM assertion to outbound messages. 

It seems to me if it would be cleaner to leave the one-way policy
assertion at the input message only, so that for the "outbound messages"
the receiving end's policy assertion would apply. I am thinking in terms
reconciling the policies of RMS and RMD at both ends (including
extensibility). I think binding/operation/input message should be
sufficient and is simpler. 

> 
> Paul

--umit

[1]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602
/msg00027.html
> 
> Patil, Sanjay wrote:
> > Comments inline ... 
> >
> >   
> >> -----Original Message-----
> >> From: Paul Fremantle [mailto:paul@wso2.com] 
> >> Sent: Thursday, Feb 09, 2006 1:43 AM
> >> To: wsrx
> >> Subject: [ws-rx] i021 proposal
> >>
> >> Proposal regarding issue 021. I'm not quite sure this is 
> >> right yet, so I 
> >> would appreciate feedback from the Policy experts.
> >>
> >> Based on CDII
> >>
> >> Delete 142-154 section 2.3 and replace with.
> >>
> >> 2.3 Assertion Attachment
> >>
> >> The RM assertion can have Service, Endpoint, Operation or Message 
> >> Endpoint Policy Subjects [WS-PolicyAttachment].
> >>
> >> WS-PolicyAttachment [WS-PolicyAttachment] defines both 
> abstract and 
> >> concrete attachment points in WSDL [WSDL1.1]. Because the 
> RM policy 
> >> assertion specifies a concrete behaviour, it MUST NOT be 
> attached to 
> >> abstract constructs:
> >>
> >>     * wsdl:portType
> >>     * wsdl:portType/wsdl:operation
> >>     * wsdl:portType/wsdl:operation/wsdl:input
> >>       * wsdl:portType/wsdl:operation/wsdl:output
> >>       * wsdl:portType/wsdl:operation/wsdl:fault
> >>     * wsdl:message
> >>
> >> The RM policy assertion MAY be attached to the following constructs
> >> * wsdl:service
> >> * wsdl:port
> >> * wsdl:binding.
> >> * wsdl:binding/wsdl:operation
> >> * wsdl:binding/wsdl:operation/wsdl:input
> >> * wsdl:binding/wsdl:operation/wsdl:output
> >> * wsdl:binding/wsdl:operation/wsdl:fault
> >>
> >> If the RM assertion is attached to the wsdl:service 
> >> construct, it MUST 
> >> be considered to apply to all the wsdl:port's referenced in 
> >> the binding.
> >> If the RM assertion is attached to the wsdl:port construct, 
> >> it MUST be 
> >> considered to apply to all the wsdl:binding's referenced 
> in the port.
> >> If the RM assertion is attached to the wsdl:binding 
> >> construct, it MUST 
> >> be considered to apply to all the wsdl:operation's 
> referenced in the 
> >> binding.
> >> If the RM assertion is attached to the wsdl:operation 
> >> construct, it MUST 
> >> be considered to apply to all the wsdl:input's, wsdl:output's and 
> >> wsdl:fault's referenced in the operation.
> >>     
> > It seems like your proposal allows for attachment of RM 
> assertion at the
> > message level. In that case, wouldn't you also want to specify the
> > behavior when the RM assertion is directly attached to the 
> wsdl:input,
> > wsdl:output or wsdl:fault constructs? Or is that semantic somehow
> > derived from the above? I think the main question of the 
> issue i021 is
> > whether and how does RM assertion apply to the outbound (I hate this
> > term) messages of an endpoint, and I don't see a clear 
> answer to that
> > question in this proposal.
> >
> > There should also be statements for handling the case where RM
> > assertions are attached to multiple subjects within the same scope.
> >
> >   
> >> WS-Addressing allows for policy assertions to be included within an
> >> EndpointReference. Per section 2.2 above, the presence of this
> >> policy assertion in an EPR specifies the level of support for
> >> WS-ReliableMessaging offered by that endpoint.
> >>     
> > Since the previous text regarding the WSDL attachment of RM 
> assertion
> > covers the behavior of outbound messages also, there may possibly be
> > conflicts when both the techniques of associating policies (WSDL
> > attachment and EPR inclusion) are used.
> >
> > -- Sanjay
> >
> >   
> >> Paul
> >>
> >> -- 
> >>
> >> Paul Fremantle
> >> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >>
> >> http://bloglines.com/blog/paulfremantle
> >> paul@wso2.com
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> >>
> >>
> >>     
> 
> -- 
> 
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> 
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
> 
> "Oxygenating the Web Service Platform", www.wso2.com
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]