[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] i021 proposal
+1 Tom Rutt Gilbert Pilz wrote: >I can take a swipe at the "fundamental question". First the answer is >"yes". The reason for this is that WS-RM Policy is basically about >annotating WSDL. WSDL is about describing the contract between a service >consumer and a service provider. Part of describing that contract deals >with describing the output of an operation. WSDL routinely asserts all >sorts of requirements on the service consumer; I don't see why asserting >that the output of an operation should have WS-RM semantics applied >should be a special case. > >If you are looking for a greater degree of consumer/provider >independence than I think the best thing would be to have your consumer >specify the callback interface in its own WSDL. It is then free to apply >WS-RM Policy (or not) as it sees fit. The service making the async >callback would, of course, be expected to understand and comply with any >policies attached to the callback interface. > >- gp > > > >>-----Original Message----- >>From: Patil, Sanjay [mailto:sanjay.patil@sap.com] >>Sent: Wednesday, February 15, 2006 7:10 AM >>To: Ashok Malhotra; Yalcinalp, Umit; Paul Fremantle >>Cc: wsrx >>Subject: RE: [ws-rx] i021 proposal >> >> >>Ashok and others who care about this issue [please chime in] >> >>I would like to understand a bit more the rationale behind >>your thinking. So please allow me to ask a set of questions ... >> >>The fundamental question asked by i021 is - does the RM >>policy apply both ways? So let us try to answer the >>controversial part of this question, that is -- should the >>Destination be allowed to assert a requirement that the >>Source must be prepared to handle the response messages >>reliably. If yes, can you please provide a brief use case >>(bait: I may be convinced!) >> >>If the answer to the above question is NO (that is, the >>Destination can only talk about reliable messaging behavior >>of inbound messages only), then the nature of i021 becomes -- >>how to specify this semantic? Does the policy framework >>provide us enough support to capture our needs, or do we have >>to invent new syntax/mechanisms? >> >>If the answer to the question is YES (that is, the >>Destination should be in a position to assert reliable >>messaging in both directions), then there are broadly two options >>- YES always, which means the Destination asserts the >>reliable messaging behavior at a port/binding level and the >>assertion is applied to all the inbound and outbound >>messages. This may be close to the status quo. >>- YES but not always, which means the Destination would like >>to have a finer level of control in asserting reliable >>messaging behavior. This option is close to PaulF's proposal. >> >>Let us try to hash out this issue by answering the above (and possibly >>additional) set of questions. >> >>-- Sanjay >> >> >> >>>-----Original Message----- >>>From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com] >>>Sent: Monday, Feb 13, 2006 7:22 AM >>>To: Patil, Sanjay; Yalcinalp, Umit; Paul Fremantle >>>Cc: wsrx >>>Subject: RE: [ws-rx] i021 proposal >>> >>>Sanjay: >>>In reading the mail on i021 there seems to be agreement that the >>>assertion should apply to various granularities including message. >>> >>>If the assertion is applied to a WSDL definition that encompasses >>>inbound, outbound and, possibly fault messages, I'm not >>> >>> >>sure there is >> >> >>>agreement. >>> >>>It can be argued that in this case the RM assertion applies to all >>>messages covered by that definition with the following semantic: >>>- Inbound: please send these messages to me using a >>> >>> >>reliable protocol >> >> >>>- Outbound: I will send these messages using a reliable protocol. >>> >>>Paul's proposal, which I am happy with, argues the above. >>> >>>All the best, Ashok >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Patil, Sanjay [mailto:sanjay.patil@sap.com] >>>>Sent: Monday, February 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >>> > > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]