[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i021 proposal
Well said Gil. +1 Marc Goodner Technical Diplomat Microsoft Corporation Tel: (425) 703-1903 Blog: http://spaces.msn.com/mrgoodner/ -----Original Message----- From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] Sent: Wednesday, February 15, 2006 3:46 PM To: Patil, Sanjay; Ashok Malhotra; Yalcinalp, Umit; Paul Fremantle Cc: wsrx Subject: RE: [ws-rx] i021 proposal 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 > > > > > > > > > > > > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]