[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] [REL-14] WSDL for WSRM ??
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 > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]