[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] [REL-14] WSDL for WSRM ??
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. 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; email@example.com > 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 > >