If I am invoking a webservice, I have to write client for it. If I have a website that lists several restaurants and gives menu for the selected restaurant by invoking webservice of selected restaurant, do I have to have webservice client for each restaurant? I would think that the answer is YES. Now, what if I want to add a restaurant in my list (write new client!!), or remove one, or one of the restaurants in the list, changes the way I call its webservice... All this makes thigs tightly coupled which is bad. Any thoughts, comments? [ June 02, 2002: Message edited by: Chintan Rajyaguru ]
Yes, this is why there should be a call for standardization. All restaurants should agree on a common WSDL binding document that describes the way in which they would provide their menus. Then you would need only one client... Kyle
Thanks Kyle, Evenif there is a common WSDL document, all restaurents still have their own web service and own WSDL document that confirms to a standard (say an XML schema for WSDL docs). How can I live with one client to call one of many web services? It seems I need a mechanism to make decision at run time to invoke a web service.
If all the web services conform to a single WSDL binding document then the only paramter that would change at run time is the URL. Most SOAP clients (including the ones generated by IBM's tools) allow you to substitute the URL of the web service at run time. So, that would solve your problem if all restaurants had the same binding document -- BTW, you could look up all the runtime URL's from a repository like UDDI... Kyle
"same binding document " is the key to the solution. I kept thinking of seperate WSDL documents. UDDI registry will also help restaurents register on UDDI server and use the listing service without having to change any code. I think now I am getting grasp of it. Thanks Kyle Chintan