[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] [REL-14] WSDL for WSRM ??
Scott Werden <firstname.lastname@example.org> 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 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; 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 > > > > > -- Paolo Romano