An overview of how UDDI registries can be referenced by service integration bus (SIBus)-enabled Web services.
UDDI
The Universal Description, Discovery and Integration
(UDDI) specification defines a way to publish and discover information about
Web services.
In this specification:
- Each Web service is owned by one business, and each business (and the
Web services it owns) is maintained by one Authorized Name.
- One Authorized Name can own many businesses, and one business can own
many Web services.
The UDDI specification also associates Web services with Technical
models. Using these models, or generic categories, a UDDI registry user can
search for a type of service, rather than needing to know the access details
for a specific service.
For more general information about UDDI, see
the UDDI community at uddi.org.
UDDI registries
UDDI registries use the UDDI specification
to publish directory listings of Web services. There are Universal Business
Registries (sometimes referred to as
public UDDI registries)
hosted worldwide, including one hosted by IBM. Enterprises can also host their
own internal registries behind their firewalls (sometimes referred to as
private
UDDI registries) to better manage their internal implementation of
Web services. The
IBM WebSphere UDDI Registry is an example
of a private UDDI registry.
How the service integration technologies interact with UDDI
registries
The service integration technologies interact with UDDI
registries in two ways:
To enable your service integration bus-deployed Web services to
interact with a UDDI registry, you create one or more pointers to the registry.
These pointers are known as
UDDI references, and you create them
as described in
Creating a new UDDI
reference. Each UDDI reference includes the following parameters:
- The access points for the UDDI registry (the Inquiry URL and the Publish
URL).
- The Authorized Name (the User ID and Password) for the owner
of one or more businesses in the UDDI registry.
You get the Authorized Name from the target UDDI registry. For more information,
see
Publishing a Web service to a
UDDI registry.
A given UDDI reference can only access the Web
services that are owned by the businesses that are owned by a single Authorized
Name. Therefore if you need to access two Web services in the same registry,
and each service is owned by a different "Authorized Name", then you
must create two UDDI references.
When you create an inbound service,
and you specify that the template WSDL file is located through a UDDI registry,
you enter the following two parameters:
- The UDDI reference that can access this service.
- The service-specific part of the full service key that the UDDI registry
has assigned to this service.
Note: When a service is published to UDDI, the registry assigns
a service key to the service.
After the service has been published you can get the service
key from the target UDDI registry.
Here is an example of a full UDDI service key:
uddi:blade108node01cell:blade108node01:server1:default:6e3d106e-5394-44e3-be17-aca728ac1791
The service-specific part of this key is the final part:
6e3d106e-5394-44e3-be17-aca728ac1791.
When you tell SIBus Web services to create entries for a Web service in one or more UDDI registries, you enter
the following two parameters:
- The UDDI references (one for each registry) that can access the UDDI business
category under which you want to publish this service.
- The business key that identifies the UDDI business category.
To get a list of valid business keys, look up
businesses in
the UDDI registry. Here is an example of a UDDI business key:
08A536DC-3482-4E18-BFEC-2E2A23630526.
Because
SIBus Web services only interacts with UDDI registries at the level of specific Web
services, SIBus Web services does not use UDDI Technical models.
For more information
see Publishing a Web service to a
UDDI registry.