[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [WS-RM & WSDL] Task Force Discussions
Sunil, Thanks for comments. I have now read through all the posted messages related to WSDL. I've come to these conclusions as far as the implementation of WSRM that I'm working on for my book: (1) Use the "minimal impact" approach described in Scott Werden's latest post. This is (I think) consistent with your philosphy - leave WSRM MEP information out of the WSDL. I.e., do not use <soap:header ...> within the WSDL bindings. (2) Implement WSRM sender and receiver layers as SOAP Handlers. Since my implementation is in Java, I'm going to try doing this using the JAX-RPC framework. Any suggestions are more than welcome! I'll let you know how it works out. I like your concept for the annotation of the WSDL using <wsdl:documentation>. I think maybe we should limit the annotation to those parameters that define the boundaries of the service's WSRM support. For example, it is useful to have an annotation for </ack-pattern> to tell the user what acknowledgement MEPs are supported by the service. However, I don't see why we would want to annotate things like <wsrm:retry-count> that do not describe properties (or limitations) of the WSRM support provided by the service. An RM processor is agnostic regarding the retry-count. It is totally up to the user of the service to decide how many retries to use isn't it? I guess that annotations like <wsrm:retry-count> could be used as "hints" for code generation tools, but I think we are better off avoiding "hints" for parameters where the service is agnostic. -- Mark -----Original Message----- From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com] Sent: Monday, June 30, 2003 4:00 PM To: Mark D. Hansen Cc: tom@coastin.com; Peter H. Petersen; jturpin@cyclonecommerce.com; scottw@wrq.com; venkat.danda@iona.com; Paolo.Romano@dis.uniroma1.it; Szabolcs.Payrits@nokia.com Subject: Re: [WS-RM & WSDL] Task Force Discussions Mark, Comments below. Btw, I've added Paolo and Szabolcs to this list and corrected Venkat's email. "Mark D. Hansen" wrote: > Sunil, > > Thanks for your email clarifying the WSDL issues. Here are some > thoughts that I have. Forgive me if some of my comments reveal a > certain ignorance about WSDL - I'm still getting up to speed!! > > I agree with your comments about issue #1. Certainly, we should deal > with #1 before attempting #2. > > However, while I agree with you that #2 is tricky, I wonder if we don't > need to address some of the issues raised by #2. Given that WSDL is the > "linga franca" of Web Services, don't we need to be able to describe a > WS-RM endpoint's behaviour using WSDL? If we dong describe the MEPs in Not necessarily. RM is a QoS feature and it is not imperative that it has to be defined as a MEP in WSDL. It will be good if we do it, but there are so many issues with it and also is time consuming. Paolo & Szabolcs are also discussing the same on the MAIN list. I haven't yet read Szabolcs's lengthy ( :-) ) mail yet, but there are indeed many complexities in mapping Application's MEP to WS-RM MEP. > > WSDL, how else will a client know how to interact with a WS-RM endpoint? > Do we just assume that the MEP is documented in the WS-RM Spec and that > it is understood between the client and endpoint outside of the context > of WSDL? I believe so. That would be case (1) in Szabolcs's first mail. Infact, none of the QoS WS Specs. such as WS-Security, WS-Policy defined WSDL mappings as they are complex, non-standard, time consuming etc.... > > > Here are some questions related to your <wsdl:documentation> example: > (a) Why would the endpoint specify retry-count / retry-interval? > Shouldn't the > endpoint be able to handle any retry-count / retry interval > combination? Sure. The endpoint should be able to handle any retry-count/retry-interval and infact should be agnostic about them. However, the intention of these being mentioned in WSDL is not for endpoint (or platform), but for the client (sender). WSDL is used by Clients/Tools to generate client proxy (or DII) code and it is for them to have this in their generate coded. This information may have to be provided to the client (Sender) either statically using some proprietary DDs or dynamically using some properties or APIs. The latter is definitely out-of-scope of this Spec. and instead of having proprietary DDs for WS-RM, an alternative would be able to supply the same in WSDL so that they can be used to generate code or used by tools to do WS-RM operations. > > (b) Regarding ack-pattern, couldn't the MEP used for acknowledgement > depend on the > contents of the message? And shouldn't the client sending a > message to an > endpoint be prepared for any type of ack MEP and have to deal with > that "on > the fly" ?? > Yes. The Ack. pattern is definitely decided by message contents. However, RM processor needs to know some hints from the User/Application to how he should like to receive the Ack. Generally this will be provided in some DD. Instead I'm using WSDL annotation as an User provided hint to the client side RM processor to handle these properties. As an example, in the initial WS-Reliability spec. we had the synchronous attribute on RM:AckRequested that indicated how the Client likes to receive the Ack. Though not explicitly mentioned in the Spec., it is implied that User will provided (if not, defaulted to one or other) this information and Client-side RM processor will then accordingly marshall the message. So instead of providing these in proprietary way, we could use WSDL to annotate so that User can provide this hints FOR client/tools in a much more standard way. I hope I clarified. Lemme know if I'm still vague so that I can elaborate. -Sunil > > -- Mark > > Mark Hansen > bus: (888) 360-7285 > fax: (914) 723-8671 > email: khookguy@yahoo.com > > -----Original Message----- > From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com] > Sent: Thursday, June 26, 2003 9:28 PM > To: jturpin@cyclonecommerce.com; Mark D. Hansen; scottw@wrq.com; > venkatd@iona.com > Cc: tom@coastin.com; Peter H. Petersen > Subject: [WS-RM & WSDL] Task Force Discussions > > There are 2 main focus areas wrt to WSDL that should interest us. > 1) Annotating (or Marking) <wsdl:operations> with WS-RM properties > 2) Creating WS-RM MEP Bindings. This would involve mainly declaring > WS-RM Headers and Async. Patterns. > > I'd hesitate to venture into focus area 2 as there are many unknowns: > - Usage of Headers is non-standard. Some applications use only > Dynamic Headers, Some map Headers to Parts, Some declare Headers > separately (to be processed by Handlers etc.) > - If we support multiple transports, then we have to create a bindings > for each of them. > - Whether WS-RM Async.patterns should be treated as MEPs and be > declared in WSDL is an arguable call. > > What I volunteered at F2F was the focus area 1, reason being: > - It is simple > - It only touches the wsdl "abstract" part. > - WSDL is the Service's window/interface for the client. > - If we don't do it, vendors could create their own DDs. > - Stub/Proxy generators could automatically generate WS-RM > specific code in the Stubs when they see these tags. > > My intention here is to make it non normative only. (In Appendix > or Best Practices Guide). > > If we decide to annotate <wsdl:operations>, then we have 2 choices: > 1) Use the <wsdl:documentation> element to define the elements. > 2) Add extensibility elements. > (ps: We can't use schema annotation as it should be only in the <types> > section) > > Option 2 is not viable in WSDL 1.1 as wsdl scould choke in some tools. > It should > be the option when we move to WSDL 1.2) Option 1 is the most commonly > used > one for "marking". WS-I BP Conformance Claim tags also use this > option. > > I believe we should do this. I'm not sure whether everyone concurs on > this or not. > > Here is an example of such a declaration would like: > > <portType name="fooPortType"> > <operation name="fooBar"> > > <wsdl:documentation> > <wsrm:WSRM xmlns:wsrm="spme URI"> > <!-- Spec. version> > <wsrm:version>1.0</wsrm:version> > > <!-- Indicates the RM:MessageHeader:To field contents !> > <wsrm:To>http://someuri</wsrm:To> > > <!-- Indicates the RM:MessageHeader:Service field contents !> > <wsrm:Service>StockQuoteService</wsrm:Service> > > <!-- No. of retries to send for non ack. messages and return > interval !> > <wsrm:retry> > <wsrm:retry-count>5</wsrm:retry-count> > <wsrm:retry-interval>10</wsrm:retry-interval> <!-- 10 secs --> > </wsrm:retry> > > <wsrm:gd> > <!-- ack-pattern sub-selement indicates the ack. receiving mode > Possible values are Response-Ack, Callback-Ack, Polling-Ack > !> > <ack-patten>Callback-Ack</ack-pattern> > </wsrm:gd> > > <wsrm:de>true</wsrm:de> > > </wsrm:WSRM> > </wsdl:documentation> > <input message="fooMessageIn" /> > <input message="fooMessageOut> > </operation> > ... > > </portType> > > If we all agree that such a thing is useful, then we could enhance this > (the above example > is far from complete) and define the schema. > > Thoughs??? > > Thanks, > -Sunil
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]