[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] [REL-14] WSDL for WSRM ??
Sunil Kunisetty wrote: >Paolo Romano wrote: > > > >>Scott Werden <scottw@wrq.com> ha detto: >> >> >> >>>The need to advertize that a Web service provider supports WS-RM I think is >>>important. The question is whether WSDL is the best mechanism by which to do >>>that. I suggest we research what is going on with the other WS-XXX specs (in >>>particular WS-Security since it is the only "open" one at this point) since >>>this problem is not at all unique to WS-RM. >>> >>> >>> >>These are links about WS-Security and WSDL: >>http://lists.w3.org/Archives/Public/www-ws-arch/2002Nov/0070.html >>http://www-106.ibm.com/developerworks/webservices/library/ws-security.html#IDAJWYTC >> >> >> > > None of the above links provide any concrete information at all. Infact, I just checked with > the Oracle rep. for WS-Security and he mentioned that they are not looking into WSDL > binding stuff. > > -Sunil > We should write and send a liaison to w3c wsdl group about this one. This is much wider than just for wsrm, and maybe they have some ideas on it. would anyone like to craft a liaison contribution to send to them with our questions and concerns about wsdl and soap extensions, in general? Tom Rutt > > > > >>Paolo >> >> >> >>>One suggestion: the WSDL could import the WS-RM schema and namespace without >>>actually creating message parts or bindings. The semantic here is that the >>>service is saying that it fully understands WS-RM but that it is optional. >>>Of course this would not work if the service wants to claim only partial >>>support of WS-RM. >>> >>>Scott >>> >>> >>> >>>>-----Original Message----- >>>>From: Paolo Romano [mailto:Paolo.Romano@dis.uniroma1.it] >>>>Sent: Friday, July 11, 2003 5:08 AM >>>>To: Sunil Kunisetty; Paolo.Romano@dis.uniroma1.it >>>>Cc: Scott Werden; wsrm@lists.oasis-open.org >>>>Subject: Re: [wsrm] [REL-14] WSDL for WSRM ?? >>>> >>>> >>>> >>>> >>>> >>>>> WS-RM is not offering a new service (by itself), but >>>>> >>>>> >>>>rather a QoS to an >>>> >>>> >>>>> existing service. >>>>> >>>>> So I don't see a good reason that WS-RM MEPs be defined in the WSDL >>>>> which was meant to be the application client's view point >>>>> >>>>> >>>>of the service >>>> >>>> >>>>> being offered. Marking the service with RM >>>>> >>>>> >>>>features/properties is different >>>> >>>> >>>>> and some what useful thing, and which is what we are >>>>> >>>>> >>>>achieving with the >>>> >>>> >>>>> annotations (REL-49). >>>>> >>>>> I don't believe in infrastructure's (whether it is WS-RM >>>>> >>>>> >>>>or some other >>>> >>>> >>>>> QoS provider) properties being defined in the WSDL. Just because >>>>> we use tcp (soap/http/tcp), do we have defined tcp linger >>>>> >>>>> >>>>or tcp_nodelay >>>> >>>> >>>>> properties in the WSDL? No. I see the same analogy with WS-RM MEPs. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>The main reason to incluse a WSDL description of a ws-rm >>>>header is to allow the >>>>service provider to advertize the fact it is able to use such >>>>protocol in a >>>>standard way. I agree with you, ws-rm does not actually >>>>define a new service, >>>>but for sure it modifies the application level service >>>>itself, because it >>>>enhances it with reliabilty features. But this is philosophy... >>>>With WSDL you make available to clients the information >>>>concerning the transport >>>>protocol you use, SOAP over HTTP, SOAP over SMTP. Including a >>>>WS-RM description >>>>in WSDL a service provider may state that it is using WS-RM >>>>over SOAP over >>>>HTTP/SMTP/etc. >>>> >>>> >>>> >>>>> Yes, the WS-RM client infrastructure has to 'imply' a MEP based on >>>>> the original MEP + Ack. Pattern Selected + Some other dependent >>>>> and should enforce that MEP. However, I don't see a requirement >>>>> that it be defined in the Service's WSDL. >>>>> >>>>> >>>>> >>>>Are you saying that the spec should not make mandatory ONLY >>>>the defition of >>>>additional operations just to take into account the WS-RM >>>>additional MEPs for >>>>ACKs/FAULTs, or also the fact that a WS-RM header should be >>>>included in the >>>>requesting message to exploit WS-RM functionalities? I may >>>>agree with the first >>>>resolution, but not on the second. Please see below. >>>> >>>> >>>> >>>>>>2- A service which relies on WS-RM headers for >>>>>> >>>>>> >>>>reliability should be able to >>>> >>>> >>>>>>advertize it in a standard way, i.e. WSDL. I do not like >>>>>> >>>>>> >>>>the idea of setting up >>>> >>>> >>>>>>an out-of-band agreement for discovering wheter a given >>>>>> >>>>>> >>>>web-service supports or >>>> >>>> >>>>>>not ws-rm... UDDI and WSDL are standardized solutions for >>>>>> >>>>>> >>>>doing that. >>>> >>>> >>>>> I'm totally against the Spec. mandating that these >>>>> >>>>> >>>>Headers be defined in the wsdl >>>> >>>> >>>>> binding section (using soap:Headers). >>>>> >>>>> - By defining the soap:Headers in the binding section, >>>>> >>>>> >>>>there won't be any >>>> >>>> >>>>> dynamic way of toggling whether we need to send RM Headers per >>>>> message or not. This is because all the M Headers will >>>>> >>>>> >>>>have mU=1, and >>>> >>>> >>>>> any Header defined in wsdl with mU=1 should always be sent. >>>>> Because of this: >>>>> -- Client (or Sender) will never have a say and the >>>>> >>>>> >>>>Service provider >>>> >>>> >>>>> (Receiver) will always have the control - which is >>>>> >>>>> >>>>a very inflexible. >>>> >>>> >>>>> -- Say you define the MessageOrder Header in the >>>>> >>>>> >>>>wsdl:binding, and the >>>> >>>> >>>>> client application wants to send only One message >>>>> >>>>> >>>>in some transaction. >>>> >>>> >>>>> Client infrastructure may want to do some >>>>> >>>>> >>>>optimization such as sending >>>> >>>> >>>>> it as a stand alone message rather than as a group. >>>>> >>>>> >>>>However, it cannot do >>>> >>>> >>>>> so as it has to always send the MessageOrder header. >>>>> -- If the client for some reason wants to send an >>>>> >>>>> >>>>un-reliable message to the >>>> >>>> >>>>> same operation, it cannot as it is forced to send >>>>> >>>>> >>>>reliable headers ALL the >>>> >>>> >>>>> time. >>>>> -- Service providers should generally list the >>>>> >>>>> >>>>options/features it supports >>>>and the >>>> >>>> >>>>> consumers are the ones who should pick the option it >>>>> >>>>> >>>>applies to them. Not >>>> >>>> >>>>> the other way around. >>>>> >>>>> >>>> >>>>I understand these comments. These are related to a >>>>well-known WSDL 1.1 limit: >>>>not being able to define optional headers. Anyway (please >>>>correct me if I am >>>>wrong) a feasible solution (while we wait for WSDL 1.2) for >>>>all of these issues >>>>could be defining two WSDLs, one for the reliable and one for >>>>the unreliable >>>>service. This way the client may pick up its favorite one. >>>> >>>> >>>> >>>> >>>>> - Also, defining Headers in the wsdl:binding as parts is >>>>> >>>>> >>>>some what questionable IF >>>> >>>> >>>>> the Headers are processed by some sort of Handlers. It >>>>> >>>>> >>>>makes sense to define >>>> >>>> >>>>> them in wsdl:binding mapping to parts if they are >>>>> >>>>> >>>>processed by the Service >>>>itself. >>>> >>>> >>>>> Since WS-RM Headers will be processed by a WS-RM >>>>> >>>>> >>>>Processor and not by >>>> >>>> >>>>> the service, I don't a see big advantage. The only adv. >>>>> >>>>> >>>>of defining the Headers >>>> >>>> >>>>> in the binding section and mapping them to parts would >>>>> >>>>> >>>>be when the Service >>>> >>>> >>>>> provider wants to FORCE WS-RM Headers (with mU = 1) all >>>>> >>>>> >>>>the time. The >>>> >>>> >>>>> disadvantage is that we loose the flexibility. >>>>> >>>>> >>>>> >>>>I guess we could still have flexibility with the above solution. >>>> >>>> >>>> >>>>> - Having said the above, if some service provider wants to >>>>> >>>>> >>>>use Headers, they >>>> >>>> >>>>> should be able to do so even today by importing the >>>>> >>>>> >>>>WS-RM schema in their >>>> >>>> >>>>> wsdl and defining them in the binding section. There is >>>>> >>>>> >>>>nothing in the spec. >>>> >>>> >>>>> prohibits this. Since the spec. doesn't say it shouldn't >>>>> >>>>> >>>>be, anyone can add it >>>> >>>> >>>>> by their mercy. >>>>> >>>>> >>>>> So for all the above reasons, I believe that the Spec. >>>>> >>>>> >>>>shouldn't mandate that >>>> >>>> >>>>> the headers be explicitly defined in the wsdl. >>>>> >>>>> >>>>I see that WSDL currently lacks several features (optionality >>>>of header >>>>elements, complex MEPs) so I can understand your reasons. I >>>>think we could >>>>manage a way to reasonably use the current version of WSDL >>>>with our spec. We >>>>have to choose whether to provide a non normative way of >>>>using WSDL with WSDL or >>>>just leave any implementor free to do it its own way. >>>>Personally I prefer the >>>>first choice, but I also think that a reasonable solution >>>>could be stating that >>>>currently WSDL 1.1 is too limited to efficiently describe the ws-rm >>>>functionalities and that a standard way to use WSDL will be >>>>provided as soon as >>>>WSDL 1.2 becomes a standard. >>>> >>>> >>>> >>>>> Btw, I did mention some of these points in the last con. >>>>> >>>>> >>>>call and hence we >>>> >>>> >>>>> closed REL-14 and created REL-49. I'm not sure whether you >>>>> >>>>> >>>>were there >>>> >>>> >>>>> or not. >>>>> >>>>> >>>>Unfortunately I could be present only for a short while at the last >>>>teleconference, and I have missed this discussion. >>>> >>>> >>>> >>>>> I'm noticing that many closed resolutions have been deliberately or >>>>> >>>>> >>>>un-deliberately >>>> >>>> >>>>> being reopen. I hope this doesn't become the trend. >>>>> >>>>> -Sunil >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>-- >>>>Paolo Romano >>>> >>>> >>>> >>>> >>-- >>Paolo Romano >> >>You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php >> >> > > >You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php > > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.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]