[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i021 proposal (updated)
> -----Original Message----- > From: Patil, Sanjay [mailto:sanjay.patil@sap.com] > Sent: Thursday, Feb 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. +1. > > 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]