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 (updated)



Fair enough. Let us hit the call now.
- Sanjay 

> -----Original Message-----
> From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> Sent: Thursday, Feb 16, 2006 12:53 PM
> To: Patil, Sanjay; Paul Fremantle
> Cc: wsrx
> Subject: RE: [ws-rx] i021 proposal (updated)
> 
> The revised proposal below was culled from Paul's by you only last
> night. 
> 
> I don't think we as a TC have finished discussing this, just 
> see all of
> the comments Anish just made about this. Let's even look at 
> one of your
> own comments: "define rules for handling the case where RM policy
> assertions are attached to multiple subjects in the same WSDL".
> Shouldn't that be included in a proposal to resolve this 
> then? What does
> it mean if this assertion is attached to an endpoint, the 
> input message,
> but not the output message?
> 
> Also I have a question about this line in the proposal:
> "WS-Addressing allows for policy assertions to be included"
> The 2004/08 version uses [policy] abstract property. The CR version of
> WS-A doesn't say anything about this. We haven't determined which
> version of WS-A the final RM spec is going to refer to, we even have a
> deferred issue on this topic. So how is this impacted by that? Granted
> this might be the right thing. The right thing, as you 
> suggest, might be
> cutting this section from the proposal and staying silent. 
> I'm just not
> sure. I'd prefer to have confidence we were making the right 
> decision on
> this.
> 
> I'm sorry that I need time to digest this but I do. As the issue has
> been open for 8 months as you note I don't see what closing 
> it this week
> versus next accomplishes other than potentially not getting 
> it right the
> first time and having to open more issues.
> 
> Marc Goodner
> Technical Diplomat
> Microsoft Corporation
> Tel: (425) 703-1903
> Blog: http://spaces.msn.com/mrgoodner/ 
> 
> 
> -----Original Message-----
> From: Patil, Sanjay [mailto:sanjay.patil@sap.com] 
> Sent: Thursday, February 16, 2006 12:19 PM
> To: Marc Goodner; Paul Fremantle
> Cc: wsrx
> Subject: RE: [ws-rx] i021 proposal (updated)
> 
> 
> The proposal has been out for review for about a week now (Paul posted
> it on Feb 9th). The issue itself has been open for about 8 
> months now :)
> 
> My proposed changes are something that I believe we can discuss on the
> call without requiring a line-numbered proposal.
> 
> I really suggest that we utilize today's call to discuss and resolve
> this issue.  Marc, we can walk through the proposal again if that may
> help you in understanding it better.
> 
> -- Sanjay
> 
> > -----Original Message-----
> > From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> > Sent: Thursday, Feb 16, 2006 11:52 AM
> > To: Patil, Sanjay; Paul Fremantle
> > Cc: wsrx
> > Subject: RE: [ws-rx] i021 proposal (updated)
> > 
> > I'm sorry, I might be able to agree to this proposal but I need more
> > time to review this, particularly as you seem to suggest 
> yourself that
> > there are changes you want to apply to this proposal. There 
> > was a lot of
> > discussion on this issue this week and I expect there will 
> be more on
> > today's call. 
> > 
> > I simply can't digest that much information to make a call 
> one way or
> > the other yet. I think this is an important issue and would 
> > prefer that
> > we take the proper amount of time to close it properly. If 
> forced I'm
> > afraid I would have to vote against adopting anything on this today
> > rather than making the wrong call or accepting something that is
> > incomplete.
> > 
> > All of that said; I'm not opposed to what I'm seeing here. 
> I just need
> > more time to review it.
> > 
> > Marc Goodner
> > Technical Diplomat
> > Microsoft Corporation
> > Tel: (425) 703-1903
> > Blog: http://spaces.msn.com/mrgoodner/ 
> > 
> > 
> > -----Original Message-----
> > From: Patil, Sanjay [mailto:sanjay.patil@sap.com] 
> > Sent: Wednesday, February 15, 2006 7:01 PM
> > To: Marc Goodner; Paul Fremantle
> > Cc: wsrx
> > Subject: RE: [ws-rx] i021 proposal (updated)
> > 
> > 
> > I am fine with Paul's suggested way of addressing my 
> concerns. I think
> > this proposal should be on the table as a candidate for 
> resolving i021
> > on tomorrow's call. I am taking the liberty (due to time zone 
> > difference
> > with PaulF) to update the proposal as per his response just to
> > facilitate easier deliberation by the TC members ...
> > 
> > I would also propose to -- a> define rules for handling the 
> case where
> > RM policy assertions are attached to multiple subjects in the 
> > same WSDL,
> > and b> clarify (or even remove) the last paragraph related 
> to how EPR
> > contained RM assertions interact with WSDL attached RM assertions. I
> > wouldn't ask for another round of proposal for resolving 
> > these aspects,
> > and would rather let our able team of editors apply the necessary
> > changes (assuming the TC blesses the proposal and agrees on the
> > updates!) ...
> > 
> > -- Sanjay
> > 
> > --------------------------------------------------------------------
> > 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.
> > 
> > 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).
> > 
> > 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.
> > -------------------------------------------------------------------
> > 
> > > -----Original Message-----
> > > From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> > > Sent: Wednesday, Feb 15, 2006 17:16 PM
> > > To: Paul Fremantle; Patil, Sanjay
> > > Cc: wsrx
> > > Subject: RE: [ws-rx] i021 proposal
> > > 
> > > So where are we with this proposal now? Is the below text in, 
> > > out? Does
> > > it need to be revised in light of discussion to date? What is the
> > > expectation for this issue on the call tomorrow? Discussion 
> > to figure
> > > out the correct direction to refine this proposal seems 
> > about right to
> > > me.
> > > 
> > > Marc Goodner
> > > Technical Diplomat
> > > Microsoft Corporation
> > > Tel: (425) 703-1903
> > > Blog: http://spaces.msn.com/mrgoodner/ 
> > > 
> > > 
> > > -----Original Message-----
> > > From: Paul Fremantle [mailto:paul@wso2.com] 
> > > Sent: Thursday, February 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.
> > > 
> > > 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).
> > > 
> > > Thanks for your comments,
> > > 
> > > Paul
> > > 
> > > 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]