[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i021 proposal
In case it was not clear, I am in agreement with the summary that Sanjay has sent out. This is supporting mail to indicate to Paul why we need a restricted semantics (as in complying with point A in Sanjay's email) for message level attachment by examples. Thanks. --umit > -----Original Message----- > From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com] > Sent: Monday, Feb 13, 2006 9:35 AM > To: Patil, Sanjay; Paul Fremantle > Cc: wsrx > Subject: RE: [ws-rx] i021 proposal > > Sanjay, > > Perhaps I did not express my discomfort on (B) well and why I prefer a > restricted semantics to apply to "in" messages only. I do not > think that > the general use case is really thought out well hence my hesistation. > > I am in favor of applying the assertion at message subject but I > hesitate its use with outbound messages when there are > multiple messages > in an MEP (inbound and outbound) and we allow attachment to individual > messages due to complexity. > > Lets consider the specific cases: > > (a) There is an operation which has only output message(s) in > it. This > use case can easily be handled with endpoint message policy > subject and > does not require message policy subject. No problem there. > > (b) There is an operation which is input/output, your typical request > response. Lets assume that we allow that the assertion applies to > outbound message in a request response. Here are the > questions that come > to my mind. > > -- How would this use case interact with CS/CSR since RM > kicks in on the > outbound message? > -- what would be the requirement on the sender of the message wrt to > specific the respective WS-Addressing headers? > > Take your typical use of WS-Addressing most folks would assume that > request/response would map to sync request-response where > replyTo would > be anonymous (HTTP response). (Am I hearing i061 but it is > out of scope > for inbound messages or not? :-)) > > I fear that the assertion would not really work well with RM > if RM only > applies to the outbound message only which applies to the > HTTP response > in this case. > > (c) There is a complicated MEP with multiple in/out messages where we > allow some of the messages to have RM assertions and some > others do not. > This is a rather complicated use case. > > Endpoint policy subject is simple since it governs both input > and output > messages. If there is granularity needed to cover at the > message level, > we should allow them at the input message level only where the RMD can > assert its requirements for the incoming messages and RMS can initiate > the protocol. If we leave the assertion at the inbound > message only, it > is implied that a clearly demarcated interaction with this > party (hence > RMD) would require RM engagement and the sender of the message accepts > this fact. > > Otherwise, I fear that we need to clarify the roles and responsibility > of client and/or RMS for case (b) and (c) well in order to proceed. > > "Redesign your abstract layer in order to suit RM > requirements" so that > cases (b) and (c) never occur may be a recommendation we can > make, but I > do not see that part of the proposals. This option implies WSDL-last > kind of design as well. If this is what we would be > promoting, we should > be clear about it. > > Hope this clarifies where I am coming from, > > > --umit > > > > -----Original Message----- > > From: Patil, Sanjay > > Sent: Monday, Feb 13, 2006 6:22 AM > > To: Yalcinalp, Umit; 'Paul Fremantle' > > Cc: 'wsrx' > > Subject: RE: [ws-rx] i021 proposal > > > > > > Just to kick the i021 discussion further (this issue has an > > amazing characteristic of moving very fast in multiple > > direction, typically away from the center of gravity and > > always needs some impetus :) ... > > > > How about saying that -- > > A> RM Policy assertion applies one-way (inbound messages only) > > B> RM Policy assertion can be applied at various > > granularities - service/port/binding/operation/message. > > Attachment at higher granularity overrides attachment at > lower level. > > C> EPR based techniques may also be used to assert the RM > > behavior of outbound messages of a Service. Specifying the > > precise syntax of how RM Policy assertion can appear in an > > EPR and how the policies in an EPR interact with the static > > policies of the endpoints (both ends) is outside the scope > of this TC. > > > > If there is consensus on the above semantic, I believe that > > Paul's last proposal can be easily tweaked to reflect the same. > > > > Please comment and let us continue hashing out this issue > > further on the mailing list (data point: this issue is close > > to 8 months old now!). > > > > -- Sanjay > > > > > -----Original Message----- > > > From: Yalcinalp, Umit > > > Sent: Thursday, Feb 09, 2006 18:43 PM > > > To: Paul Fremantle; Patil, Sanjay > > > Cc: wsrx > > > 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/archi > > > ves/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]