See inline... ----- Original Message ----- From: Denero Watz To: [EMAIL PROTECTED] Sent: Friday, July 25, 2003 8:00 AM Subject: Questions on WebServices Discovery
I have some general questions: 1) I have seen a soap server is protected using some authentications e.g. by Basic Authentication on the web server. But will there be a situation where a UDDI or WSIL url will be protected? My understanding is that since they are registries that is exposed to users to look up services there will not be any usecase to protect that url itself. Correct me if I am wrong. <atm> There are plenty of use cases that require authentication and also authorization for access to a Web services registry. The most obvious one is as follows: You want to make sure that only authorized people are permitted to register services or change previously registered services. But here's another one: You want to set up a single UDDI registry that you can use for both internal and external service registrations. You prefer to have only one registry because some of your services support both internal and external users, and you don't want to maintain multiple registrations for the same service in different registries. Also you offer different external services/interfaces to different partners -- your gold partners get extra features/capabilities/discounts/etc. Therefore you need to authenticate each user and return only the information that that user is permitted to see. I believe that all UDDI registry implementations require authentication. Keep in mind that a UDDI registry is a Web service, not just a URL. The authentication mechanism is not prescribed by the specification, though, so each registry implementation can implement its own authentication mechanisms. UDDI does provide a default application-level authentication mechanism (get_authToken and discard_authToken), although it is used only with the publish API, which supports primitive access control features: only those that registered a service can modify the registration. The current UDDI specifications (V2 and V3) don't define a standard access control mechanism for the inquiry API, therefore most UDDI registry implementations don't support inquiry access control. There are two exceptions: Systinet WASP UDDI and Novell Nsure UDDI Server both support fine-grained role-based access control on each element in the registry. WSIL is not a Web service. It is simply a set of linked files containing WSIL XML documents. You can protect these files just as you would protect any other file. </atm> 2) Is there a way we can identify a UDDI or WSIL url by looking into the url itself programatically? I think a UDDI url can be any http url so cannot identify. But a WSIL url always ends with the text 'wsil' ?? <atm> A WSIL file SHOULD end with .wsil -- but it's just a file, so you can name it anything you want. If you want people to recognize it as a WSIL file, though, you should name it properly. UDDI is a Web service, and if it is registered in some type of Web service registry (WSIL or another UDDI registry), then your application can programmatically find and use the UDDI accesspoint. If it hasn't been registered anywhere, there's no way to programmatically determine that the URL is a UDDI accesspoint. </atm> Thanks dw Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
