Sunil Kunisetty wrote:
>Paolo Romano wrote:
>
>
>
>>Scott Werden <> 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:]
>>>>Sent: Friday, July 11, 2003 5:08 AM
>>>>To: Sunil Kunisetty;
>>>>Cc: Scott Werden;
>>>>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: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
