[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] i021 proposal
Few comments/views on this thread: 1) WSDL and RM look at things in a very different way, which may result in a mismatch. A WSDL description specifies things from the point of view of a service. It says what it supports/requires (for various artifacts) and it says what the client/service-invoker must/may do. RM on the other hand talks about a unidirectional Sequence of messages that may or may not span multiple services/endpoints/operations/bindings/etc and may or may not span multiple client/service-invokers. 2) There is nothing wrong in having a service advertise that it requires RM for both inbound and outbound message OR just inbound OR just outbound message. As Gil stated in one of his emails a service can require a client to do something (such as support RM on outbound) -- it is a precondition to talk to the service. There are usecases for all of the following: 1) only inbound is reliable -- it is a PO submission with an app-level ack coming back. The ack is not reliable. 2) both in-out are reliable -- the most common case perhaps, where the input is reliable and the output of the invocation is also reliable. 3) only the out message is reliable -- Dug pointed out the polling usecase where the in message is trying to pull a result and therefore the in message is not reliable but the out message is. 3) We should not assume that the Sequence that is used in a request-response is always freshly created. The communicating parties may have created Sequence in both directions and these Sequences are being used for various req-res message exchanges. 4) WRT RM policy in EPRs that are exchanged (such as in the ReplyTo), we don't need to say anything (about what is overridden) other than the fact that EPRs may have embedded policies. There is no processing model for metadata that is embedded in an EPR -- so I'm not sure we can say anything here. But more importantly I don't think an EPR can override an RM assertion in WSDL. Here's why: We are talking about a request-response operation here (for in-only and out-out, an EPR that is in ReplyTo or such other constructs are not relevant from the WSDL RM assertion POV. I'll ignore complex MEPs that WSDL 2.0 allows for now). The request-response operation is specified by the WSDL and supported by the service. A client/invoker *cannot* override the service's WSDL in a replyTo EPR. For example, if RM is enabled for both in-out messages in the WSDL, since there is no such assertion called "RM-Not-Supported", the client cannot override it. If RM is only enabled for in-message in the WSDL, the replyTO epr may have assertion that says RM-required, but there is no guarantee that the service is going to respect that. It may. If it does, it does not override anything that the WSDL says (since the WSDL doesn't say anything about RM for out-bound). So I don't think it is relevant. In any case, an invoker cannot/should not override what the service requires. 5) Wrt to replyTo being 'anon' for in-out operations in WSDL which says RM is required for both in and out operations -- yes this is a problem iff you don't already have a Sequence created in the other direction that can be used (see 3 above). In which case, the service can just fault. WS-Addressing already provides one with a WSDL tag that says anon-replyTos are not allowed. The service can use that to signal that 'anon' replyTos are not allowed (that is if knows that it won't have a Sequence in the opposite direction that is already created that it can use). 6) Wrt to other policy assertion specs and looking at them for inspiration -- I think that is a bad idea. They are under defined and I'm not sure if they have considered some of the scenarios that we have considering here. There are some unique requirements for WSRM cause a Sequence can spans multiple endpoints/clients. Regardless, since those specs are going through change and standardization process they are likely to change as well. 7) I like Paul's proposal (with the addendum that he sent in reply to Sanjay's email last week). I agree with Marc that extending the policy scope beyond endpoint to messages makes sense. I.e., allows RM policy to have endpoint *and* message scope. This allows all the usecases (RM for in-only, RM for out-only and RM for in-out). -Anish -- Marc Goodner wrote: > To me this issue was always about whether or not the assertion should be > expanded to allow additional granularity, not restrict existing usage. > > So expanding the assertion definition to allow a message level > attachment point certainly allows a service to express that RM is > required on the inbound message and not the outbound among other > potential MEPs (this seems to be the one driving the need for this > change though). Using the assertion at the endpoint level per Paul's > proposal continues to allow a service to express RM is required for > inbound and outbound messages. > > One of the principle scenarios for RM is to bring reliability to Web > services on unreliable transports. Req-resp is a very common web service > interaction pattern, so what is controversial about wanting to allow a > service to express that RM is required for that pattern? Are you asking > for a use case for reliable req-resp? I would actually like to know why > a service designer should be prevented from expressing that the resp > flow must be sent reliably. > > 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: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]