axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anne Thomas Manes" <>
Subject Re: Questions on WebServices Discovery
Date Fri, 25 Jul 2003 14:34:25 GMT
See inline...

----- Original Message -----
From: Denero Watz
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.

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.

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' ??

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.


Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

View raw message