This section contains the information on the following topics:
Universal Description, Discovery and Integration (UDDI) registries are used in an enterprise to share Web services. Using UDDI services helps companies organize and catalog these Web services for sharing and reuse in the enterprise or with trusted external partners.
A UDDI registry service for Web services is defined by the UDDI specification available at:
http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3
UDDI registries are based on this specification, which provides details on how to publish and locate information about Web services using UDDI. The specification does not define run-time aspects of the services (it is only a directory of the services). UDDI provides a framework in which to classify your business, its services, and the technical details about the services you want to expose.
Publishing a service to a registry requires knowledge of the service type and the data structure representing that service in the registry. A registry entry has certain properties associated with it and these property types are defined when the registry is created. You can publish your service to a registry and make it available for other organizations to discover and use. Proxy services developed in BEA AquaLogic Service Bus can be published to a UDDI registry. AquaLogic Service Bus can interact with any UDDI 3.0 compliant registry. BEA provides the AquaLogic Service Registry.
AquaLogic Service Bus’ Web-based interface to AquaLogic Service Registry makes the registry accessible and easy to use. In working with UDDI, AquaLogic Service Bus promotes the reuse of standards based Web services. In this way, AquaLogic Service Bus registry entries can be searched for and discovered and used by a multiple domains. Web services and UDDI are built on a set of standards, so reuse promotes the use of acceptable, tested Web services and application development standards across the enterprise. The Web services and interfaces can be catalogued by type, function, or classification so that they can be discovered and managed more easily.
UDDI is based upon several established industry standards, including HTTP, XML, XML Schema Definition (XSD), SOAP, and WSDL. The latest version of the UDDI specification is available at:
An UDDI specification describes a registry of Web services and its programmatic interfaces. UDDI itself is a set of Web services. The UDDI specification defines services that support the description and discovery of:
A UDDI registry stores data and metadata about business services. It is a standards-based library of catalogued and managed information about Web services for discovery and reuse by other applications. UDDI offers several benefits to IT managers at both design time and run time, including increasing code reuse. UDDI also provides benefits to developers, including the following:
UDDI uses a specific data model to represent entities that define organizations and services. Figure 5-2 shows the relationship between different UDDI entities.
A high-level overview of the UDDI entities is provided.
For more information on the UDDI data model and entities used in UDDI, see Introduction to BEA AquaLogic Service Registry in BEA AquaLogic Service Registry 2.1 User’s Guide.
Before using AquaLogic Service Bus with a UDDI registry you must perform the following tasks:
AquaLogic Service Bus works with any UDDI registry that is fully compliant with the version 3 implementation of UDDI (Universal Description, Discovery and Integration).
AquaLogic Service Registry 2.1 is a version 3 UDDI-compliant registry and is certified to work with AquaLogic Service Bus.
The AquaLogic Service Bus Console provides you with access to any version 3 implementation of UDDI registry once it has been set up to work with AquaLogic Service Bus. The following features are available:
For more information on how to configure and search the registry, import business services to AquaLogic Service Bus, and how to publish proxy services to a UDDI registry, see the following topics in System Administration in Using the AquaLogic Service Bus Console:
BEA AquaLogic Service Registry is a compliant fully with version 3 implementation of UDDI and is a key component of a Service Oriented Architecture (SOA).
Note: | AquaLogic Service Registry is not provided with AquaLogic Service Bus. In order to use AquaLogic Service Registry you have to buy a separate licence from BEA. |
A UDDI registry provides a standards-based foundation infrastructure for locating services, invoking services, and managing metadata about services (security, transport or quality of service). Using the Registry Console you can browse and publish registry content. The Registry Console is the primary console for administrators to perform registry management. You can launch the AquaLogic Service Registry console in a Web browser by opening the following URL: http://
hostname:port/uddi/web
, where hostname and port are defined when AquaLogic Service Registry is installed. The default port is 8080. For more information on the management of AquaLogic Service Registry, particularly configuring the registry and managing permissions, approval, and replication, see
BEA AquaLogic Service Registry Administrator’s Guide.
The following are two sample business scenarios that highlight the benefit of using UDDI.
This scenario describes how you can use AquaLogic Service Bus to import services form a registry and then publish the services back to a registry as part of an AquaLogic Service Bus proxy service.
AquaLogic Service Bus imports business services from a UDDI registry. Proxy services are configured to communicate with the business services in the Message Flow. The proxy services themselves can be published back to the registry and made available for use by other domains.
This scenario describes cross-domain deployment using AquaLogic Service Bus. An AquaLogic Service Bus application in one domain requires access to an AquaLogic Service Bus service in another domain at run time.
An instance of AquaLogic Service Bus is deployed in each of two domains. The AquaLogic Service Bus Proxy service (P1) is configured in domain (D1). The AquaLogic Service Bus Proxy service (P2) in domain (D2) requires to access proxy service (P1). As the domains can not communicate directly with each other, P2 in D2 can not discover P1 in D1. The AquaLogic Service Bus import and export feature does not support run-time discovery of services in different domains, but publishing the service to a publicly available UDDI registry allows for the discovery of the service in any domain. Once P1 is made available in the UDDI registry it can be invoked at run time (for example, get a stock quote) and imported as a business services in another AquaLogic Service Bus proxy service.
When importing and exporting from different domains you should have network connectivity. A proxy service might reference schemas located in the repository of a different domain, in which case it needs HTTP access to the domain to import using the URL. In the absence of connectivity an error message will be returned.
You can use the AquaLogic Service Bus Console to:
The typical workflow for using UDDI with AquaLogic Service Bus is as follows:
You can configure a UDDI registry, make it available in AquaLogic Service Bus, and then publish AquaLogic Service Bus proxy services to it or import business services from the registry to be used in a proxy service. You must be in an active AquaLogic Service Bus session in the AquaLogic Service Bus Console to configure the registry.
The following table describes the fields for configuring a UDDI registry. An asterisk denotes a required field.
When publishing services to AquaLogic Service Registry, to gain access to the registry, you must be authenticated for which you should have a valid user name and password. The user name and password combination is implemented as a service account resource in AquaLogic Service Bus. Service accounts must be defined before configuring proxy services so that the authentication criterion is set up to work with a service during the configuration of the proxy service.
You can set up registries with multiple user name and passwords allowing different users to have different permissions based on the service account. Permissions in AquaLogic Service Registry are such that administrators can manage users’ privileges in BEA AquaLogic Service Registry and create views into the registry, specific to the needs of the different user types. User permissions set in AquaLogic Service Bus govern access to the registries, their content, and the functionality available to you.
You can use the AquaLogic Service Bus Console to publish proxy services to AquaLogic Service Registry. You must have an account set up in AquaLogic Service Registry to do this. You can publish any proxy service to a UDDI registry except proxy services using the local transport. The service types and transports are listed in Table 5-3.
You can select the Business Entity under which a service is to be published. Business Entity Administration (including creation, removal, update, and deletion of entities) is done using the management console provided by the registry vendor (the Business Service Console in the case of AquaLogic Service Registry). The first time you publish to a registry you must load the tModels
to that registry. This is done at the time you configure the publishing details in the AquaLogic Service Bus Console.
For more information on how to publish to a UDDI registry, see “Publishing a Proxy Service to a UDDI Registry” in System Administration in Using the AquaLogic Service Bus Console.
AquaLogic Service Bus works with any UDDI version 3 compliant registry but it has been certified to work with AquaLogic Service Registry only.
Note: | An error can occur when you attempt to import a service from a UDDI registry if that service was originally published to the registry from an AquaLogic Service Bus cluster in which any of the clustered servers uses the localhost address. Specifically, when the service being imported references a resource (WSDL or XSD) which references other resources (WSDL or XSD). |
Note: | Ensure that before you publish services to a UDDI registry from a clustered domain, none of the servers in the cluster use localhost in the server addresses. Instead, use either the machine name or the IP address. |
When you create a proxy service you can publish it to the default registry automatically. In order to do this you have to first set a default registry to which the proxy services are published when you create or modify them. You can select the check box beside Publish To Registry in the Create a Proxy Service-General Configuration page to enable or disable the Auto-Publish feature for individual proxy services. For more information on setting up a default registry, see Setting up a Default Registry in Using the AquaLogic Service Bus Console.
When you enable the Publish To Registry in the Create a Proxy Service-General Configuration page the proxy service is published to the default registry. The services are automatically published to the registry when you activate the session, only when the Publish to Registry check box is selected for the proxy service. If the Registry is unavailable, the publish is retried in the background. Any further changes to the proxy service resets the retry attempts. When a proxy service is republished to UDDI, all taxonomies and categorizations, which are defined in UDDI for the proxy service are preserved.
When you change the default registry all the proxy services that are enabled to auto-publish will be published to the new default registry. Synchronization will now take place with the current default registry. When a proxy service is not synchronized, the AquaLogic Service Bus Console console displays this icon beside the proxy service.
Note: | When you have a default registry and you import a sbconfig.jar , which has a default registry set with the same logical name during the import, it is possible that the default registry will have an incorrect value for the business entity. You may now see errors in the Auto Publish Status page, if there are any auto-published proxy services. You can correct this by selecting the default registry again. |
You can import services from a registry as AquaLogic Service Bus business services. When importing a WSDL-based service, if multiple UDDI binding templates are encountered, AquaLogic Service Bus creates a different business service for each binding template.
To establish access to UDDI registries in AquaLogic Service Bus you must have AquaLogic Service Bus system administration privileges. The registry entries appear on the System Administration > Import from UDDI page of the AquaLogic Service Bus Console. When importing, you make a selection from the list of available registries. To discover a service in a registry you must query a specific registry. Entries in registries are unique. This query is performed when you specify what registry you want to use for importing a service.
You can import the following business services types from a UDDI registry into AquaLogic Service Bus:
For information on how to use the AquaLogic Service Bus Console to import services from a UDDI registry, see “Importing a Business Service from a UDDI Registry” in System Administration in Using the AquaLogic Service Bus Console.
When a service is updated, you must re-import the service from the registry to get the most recent version, unless you have selected the Enable Auto Import option to auto-synchronize imported services with the UDDI Registry. Any service that is imported with this option selected will be kept in synchrony with the UDDI Registry. If there is any failure during auto-synchronization, it will be reported on the Auto-Import Status page where you can update it manually.
Services have documents associated with them and these documents can include a number of other documents (schemas, policies, and so on). On import, the UDDI registry points to the document location based on the inquiry URL of the service. When a document that includes or references other resources is located, all of the referenced information and each included item is added as a separate resource in AquaLogic Service Bus.
Business Entity and pattern are the criteria used to search for a service in a registry. For example, you can enter foo%
, when searching for a service. Services published by AquaLogic Service Bus have specific tmodel
keys identifying the services that are used when searching for the service in the registry.
Import automatically tries to connect to a registry when you attempt to get the list of business entities from the registry. The Business Entity is the highest level of organization in the registry, though you can use other search criteria, such as business, application type, and so on. If you require authentication, then you need a user name and password which you must get from your systems Administrator.
http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm
. The note on s Using WSDL in a UDDI Registry is important.
http://uddi.org/solutions.html
.
http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm
tModels
) of various identifier and category systems that may be used to identify and categorize UDDI registrations
You can use the Auto-Import feature to synchronize the business services, which are imported from the AquaLogic Service Registry, with the corresponding services in the registry. For more information on Using Auto-Import see, Auto-Import in Using the AquaLogic Service Bus Console. You can use Auto-Import to do the following:
You can synchronize the services you have imported from the registry. If the services in the registry change, you can synchronize services in the AquaLogic Service Bus Console with those in the registry. The following use case illustrates the process of synchronization. If the business service is not detached from the registry, AquaLogic Service Bus automatically subscribes to any changes to the service in the registry. If the service changes, the icon in the resource browser and project explorer indicates the service needs to be synchronized. In addition, the Auto Import Status page shows this service and provides the options to synchronize the service or detach it from the registry. Under certain circumstances, synchronizing the service might result in semantic validation errors that shows up in the view conflicts page. These will have to be fixed manually fixed before the session is activated.
When a service is synchronized, the service is updated only with fields that are obtained from UDDI. Other fields in the service definition will preserve their values if modified since last import.
Consider a scenario where you publish services from Domain1(see Figure 5-5) to a registry. You then import these services to another domain, Domain2. When you make changes to the corresponding service in Domain1 and update it in the registry. You can update the services in Domain2 by synchronizing it with the registry using Auto-Import.
When you do not want the service in the AquaLogic Service Bus Console synchronized with the corresponding service in the registry then, you can avoid synchronization by detaching it from the registry. For more information on using Detach, see “Detaching a Service” in System Administration in Using the AquaLogic Service Bus Console.
You can keep the service definitions in AquaLogic Service Bus automatically synchronized (both ways) with those in UDDI.
Services can be automatically published to a UDDI registry after they are created or changed within AquaLogic Service Bus and business service definitions can be imported from UDDI and automatically updated when the original service is changed in UDDI. Alternatively, you can configure the AquaLogic Service Bus Console to prompt you for approval for synchronization when a service changes in the UDDI registry.
When configuring a registry, select the Enable Auto Import option to auto-synchronize imported services with the UDDI Registry. Any service that is imported with this option selected will be kept in synchrony with the UDDI Registry automatically. If there is any failure during auto-synchronization, it will be reported on the Auto-Import Status page where you can update it manually. See “Configuring a UDDI Registry” in System Administration in the Using the AquaLogic Service Bus Console.
AquaLogic Service Bus proxy service attributes must be mapped to the data model supported by the UDDI registry to allow a proxy service to be published as a UDDI business entity. The following table shows the service types, message types, and transports relevant to the UDDI registry mapping for an AquaLogic Service Bus proxy service.
Note: | Optional parts are listed in parentheses. Messaging services can have different content for requests and responses, or can have no response at all (one-way messages). E-mail, File, and FTP should be one-way. |
Proxy services have attributes in common and also attributes that are specifically defined by the transport protocols used by the service and the type of service. Each proxy service can deliver messages of a certain type.
The primary relevant entities in UDDI are:
Figure 5-6 shows how WSDL-based services are mapped to UDDI business entities.
The technical note on Using WSDL in a UDDI registry, version 2.0.2, at
http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm
, is used as the basis for publishing WSDL-based proxy services to the UDDI registry. This document is also used as a reference point for publishing non-WSDL based services. The document and the base UDDI specification describe the canonical technical models (tModels
) used to describe UDDI entities. To publish AquaLogic Service Bus proxy services as entities in the UDDI registry, you must add additional canonical tModels to support some of the constructs specific AquaLogic Service Bus. Not all attributes of an AquaLogic Service Bus proxy service are useful when searching for a service, for example service type and transport details. These attributes do not categorize the service. tmodels
are configuration details of the service once it has been discovered. These configuration details are mapped to the business service binding template tmodelinstanceDetails
section. Other attributes specifically identify a service and can be used as the search criteria for the service. These attributes are mapped using keyed references to tModels
with values in the categoryBag
of the binding template.
An example of how AquaLogic Service Bus maps to UDDI is shown in Figure 5-7.
AquaLogic Service Bus high-level proxy service information maps into the Business Service as follows:
businessService elements
.uddi:bea.com:attributes:aqualogicservicebus
.keyedReferences
in the service category. An example of a key is uddi:bea.com:servicetype
.keyedReference
in the AquaLogic Service Bus keyedReferenceGroup
(Name = “AquaLogicServiceBus
”, Values = URL of the AquaLogic Service Bus instance). Listing 5-1 shows a mapping of high-level proxy service information to a business service.
<keyedReferenceGroup tModelKey="uddi:bea.com:servicebus:properties">
<keyedReference tModelKey="uddi:bea.com:servicebus:servicetype"
keyName="Service Type"
keyValue="SOAP"/>
<keyedReference tModelKey="uddi:bea.com:servicebus:instance"
keyName="Service Bus Instance"
keyValue="http://FOO02.amer.bea.com:7001"/>
</keyedReferenceGroup>
Note: | The key for the businessService created when a proxy service is published is a publisher assigned key name. It is derived from the AquaLogic Service Bus domain name, the path of the proxy service, and the proxy service name. It takes the following form: |
Note: | uddi:bea.com:servicebus:< domainname >:< path >:< servicename > . |
Note: | For example, AnonESBan, which is a domain in AquaLogic Service Bus, contains a project named Proxy, which contains a folder named Accounting, which in turn contains a proxy service called PayoutProxy. When PayoutProxy is published to UDDI, its businessService is created with the following key: |
Note: | uddi:bea.com:servicebus:AnonESB:Proxies:Accounting:PayoutProxy. |
AquaLogic Service Bus detailed proxy service information maps into the binding template as follows:
Listing 5-2 shows a detailed information mapping to the binding template.
<bindingTemplate bindingKey="uddi:" serviceKey="uddi:">
<accessPoint useType="endPoint">file:///c:/temp/in3</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:uddi.org:transport:file">
<InstanceDetails>
<InstanceParms><ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
<property name="fileMask" value="*.*"/>
<property name="sortByArrival" value="false"/> </ALSBInstanceParms>
</InstanceParms>
</InstanceDetails>
</tModelInstanceInfo>
<tModelInstanceInfo tModelKey="uddi:bea.com:servicebus:protocol:
messagingservice">
<InstanceDetails>
<InstanceParms><ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
<property name="requestType" value="XML"/>
<property name="RequestSchema" value="http://domain.com:7001
/sbresource?SCHEMA%2FDJS%2FOAGProcessPO"/>
<property name="RequestSchemaElement"
value="PROCESS_PO"/>
<property name="responseType" value="None"/></ALSBInstanceParms>
</InstanceParms>
</InstanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
Each of the transport types in the uddi:uddi.org:transport: *
group has a different set of detailed metadata. (See
Table 5-4, Proxy Service Attributes and Service Types, on page 5-16.) This metadata provides configuration details of the transport for the proxy service. It is neither useful for characterizing the service nor useful in querying the service. However, after the service has been discovered, this data is needed to access the service. The metadata is represented by an XML string and is located in the instanceParms
field in tModelInstanceInfo
.
If you are mapping a proxy service that uses the HTTP transport, and as part of the HTTP configuration you need to describe some detailed configuration details, including the required client authorization and the request and response character encoding, the following Listing 5-3 provides an example of what must appear in the bindingTemplate tModelInstanceDetails
.
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:uddi.org:transport:http">
<instanceDetails>
<instanceParms>
<ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
<property name="client-auth" value="basic"/>
<property name="request-encoding" value="iso-8859-1"/>
<property name="response-encoding" value="utf-8"/>
<property name="Scheme" value="http"/>
</ALSBInstanceParms>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
Note: | For each transport, the service endpoint is always stored in the bindingTemplate’s accessPoint field. |
The client-auth
property is present in the instanceParms
of the HTTP or HTTPS transport attributes whenever authentication is configured. The possible values for client-auth
are basic, client-cert, and custom-token. Whenever the value is custom-token, two additional properties are present: token-header
and token-type
.
Because AquaLogic Service Bus business service definitions do not support custom token authentication in this release, if you import a service from UDDI that has a value of custom-token for client-auth
, the service is imported as if it does not have any authentication configuration.
Table 5-5 is organized by transport type and lists the tModelKey
and instanceParms
used by each of the transports.
E-mail1
|
||
1The |
Table 5-6 provides a high-level description of each of the service types.
WSDL based proxies map to UDDI based on the Using WSDL in a UDDI Registry, version 2.0.2 technical note at URL:
|
|
A simple marker protocol tModel in the bindingTemplate’s
tModelInstanceDetails , defines the messaging services attributes. This is a new detailed tModel.Unlike the other service types, messaging services have additional configuration information associated with them, which provide details about the request and response messages. The configuration details are represented as XML data in the InstanceParms data for the following tModel reference in the tModelInstanceInfo :
|
The AquaLogic Service Bus-UDDI mapping introduces a number of new canonical tModels
that are used to represent AquaLogic Service Bus metadata and relationships. These tModels
must be registered in the UDDI registry to support this mapping. You can create these tModels
in AquaLogic Service Registry under the administrator ID.
The following table provides a summary of the new tModels
.
The following is an example of the mapping for a Messaging Service, configured with JMS transport, the request being XML with a Schema and the response being a text message.
<businessService
serviceKey="uddi:bea.com:servicebus:Domain:Project:JMSMessaging"
businessKey="uddi:9cb77770-57fe-11da-9fac-6cc880409fac"
xmlns="urn:uddi-org:api_v3">
<name>JMSMessagingProxy</name>
<bindingTemplates>
<bindingTemplate
bindingKey="uddi:4c401620-5ac0-11da-9faf-6cc880409fac"
serviceKey="uddi:bea.com:servicebus:
Domain:Project:JMSMessaging">
<accessPoint useType="endPoint">
jms://server.com:7001/weblogic.jms.XAConnectionFactory/
ReqQueue
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:uddi.org:transport:jms">
<instanceDetails>
<instanceParms>
<ALSBInstanceParms
xmlns="http://www.bea.com/wli/sb/uddi"><property name="is-queue" value="true"/>
<property name="request-encoding"
value="iso-8859-1"/>
<property name="response-encoding"
value="utf-8"/>
<property name="response-required"
value="true"/>
<property name="response-URI"
value="jms://server.com:7001/
.jms.XAConnectionFactory/
RespQueue"/>
<property name="response-message-type"
value="Text"/>
<property name="Scheme" value="jms"/>
</ALSBInstanceParms>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
<tModelInstanceInfo
tModelKey="uddi:bea.com:servicebus:
protocol:messagingservice">
<instanceDetails>
<instanceParms>
<ALSBInstanceParms xmlns=
"http://www.bea.com/wli/sb/uddi">
<property name="requestType" value="XML"/>
<property name="RequestSchema"
value="http://server.com:7001/
sbresource?SCHEMA%2FDJS%2FOAGProcessPO"/>
<property name="RequestSchemaElement"
value="PROCESS_PO_007"/>
<property name="responseType" value="Text"/>
</ALSBInstanceParms>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReferenceGroup tModelKey="uddi:bea.com:servicebus:properties">
<keyedReference tModelKey="uddi:bea.com:servicebus:servicetype"
keyName="Service Type"
keyValue="Mixed" />
<keyedReference tModelKey="uddi:bea.com:servicebus:instance"
keyName="Service Bus Instance"
keyValue="http://cyberfish.bea.com:7001" />
</keyedReferenceGroup>
</categoryBag>
</businessService>