46 Working with UDDI Registries
This chapter describes how to use Service Bus with Universal Description, Discovery, and Integration (UDDI) registries.
This chapter contains the following sections:
46.1 UDDI, UDDI Registries, and Web Services
UDDI provides a framework in which to classify your business, its services, and the technical details about the services you want to expose.
The UDDI Project is an industry initiative that aims to enable businesses to find and carry out transactions with one another quickly, easily, and dynamically. A populated UDDI registry contains cataloged information about businesses, the services that they offer, and communication standards and interfaces they use to conduct transactions. 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). The UDDI registry can store and provide these metadata using arbitrary categorizations. These categorizations are called taxonomies.
An organization uses UDDI registries to share web services. Using UDDI registries helps companies organize and catalog web services for sharing and reuse in an enterprise or with trusted external partners. The UDDI version 3.0 specification is 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 runtime 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. Certain properties are associated with each registry entry 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 Service Bus can be published to a UDDI registry. Service Bus can interact with any UDDI registry that is compliant with version 3.0.
Figure 46-1 illustrates the integration of Service Bus with a UDDI registry.
Figure 46-1 Oracle Service Bus integration with UDDI
![Description of Figure 46-1 follows Description of Figure 46-1 follows](img/uddisbinteg.gif)
Description of "Figure 46-1 Oracle Service Bus integration with UDDI"
The Service Bus web-based interface makes the registry accessible and easy to use. In working with UDDI, Service Bus promotes the reuse of standards-based web services. In this way, Service Bus registry entries can be searched for, discovered, and used by 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.
46.1.1 Basic Concepts of the UDDI Specification
UDDI is based upon several established industry standards, including HTTP, XML, XML Schema Definition (XSD), SOAP, and WSDL. The 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 the following:
-
Businesses, organizations, and other web services providers
-
The web services they make available
-
The technical interfaces that can be used to access and manage those services
46.1.2 Benefits of Using a UDDI Registry with Service Bus
A UDDI registry stores data and metadata about business services. A UDDI registry offers a standards-based mechanism to classify, catalog, and manage web services so that they can be discovered and consumed by other applications. UDDI offers several benefits to IT managers and developers at both design time and runtime, including the following:
-
UDDI improves infrastructure management by publishing information about services to the registry and categorizing the services for discovery. This ability of UDDI to categorize a growing portfolio of services makes it easier to manage them and helps you to understand relationships among components, supports versioning, and manages dependencies.
-
You can import UDDI services from a registry to configure the parameters required to invoke the web service and the necessary transport and security protocols.
-
UDDI promotes the use of standards-based web services and business services development in business applications and provides a link to a library of resources for web services developers. This decreases development time and improves productivity. It also increases the prospect of interoperability between business applications by sharing standards-based resources.
-
UDDI provides a user-friendly interface for searching and discovering web services.
46.1.3 Introduction to UDDI Entities
UDDI uses a specific data model to represent entities that define organizations and services.Figure 46-2 shows the relationships between different UDDI entities.
Figure 46-2 UDDI Entities Representing Organizations and Services
![Description of Figure 46-2 follows Description of Figure 46-2 follows](img/uddientities.gif)
Description of "Figure 46-2 UDDI Entities Representing Organizations and Services"
Table 46-1 provides a high-level overview of UDDI entities.
Table 46-1 High-Level Description of UDDI Entities
UDDI Entity | Description |
---|---|
Business Entity |
An organization or group that owns and provides the services. A business entity can be described by a set of names, descriptions, contact details for the service provider, a set of categories that represent the business entity features, unique identifiers, and discovery URLs. |
Business Service |
A description of the functionality or resources provided by a business entity. A business service is described by a name, a description, and a set of categories that represent the function of the service. A business service in a UDDI registry does not necessarily represent a web service. The UDDI registry can register arbitrary services, for example EJB, CORBA, and such. |
Binding Template |
The technical details of how to invoke a business service. A business service can contain one or more binding templates. Binding templates are described by access points representing service endpoints (the endpoint URI and protocol specification), tModel instance information, and categories to reference specific features of the binding template. |
tModel |
A technical specification; typically a specifications pointer, or metadata about a specification document, describing how services must be represented in the UDDI registry. The description of a service includes a name, a description, an overview document (a reference to a document specifying the purpose of the tModel), a category, and an identifier (to uniquely identify the tModel). |
46.2 Service Bus and UDDI
Service Bus works with any UDDI registry that is compliant with the version 3.0 implementation of UDDI.
Using Service Bus with a UDDI registry, you can do the following:
-
Configure Service Bus to work with one or more V3.0-compliant UDDI registries.
-
Configure a registry to allow users to publish services and import services.
-
Publish information about any proxy service to a registry.
-
Search for specific services in a registry or list all services available. You can search on business entity, service name pattern, or both.
-
Import business services from a registry.
46.2.1 UDDI Registry URLs
When you configure a UDDI registry in Service Bus, you specify several API endpoint URLs for different types of UDDI registry access. These URLs include the following:
-
Inquiry URL: The URL of the Inquiry API endpoint used for locating and importing services.
-
Publish URL: The URL of the Publish API endpoint used for publishing services.
-
Security URL: The URL of the Security API endpoint used for getting an authentication token so you can publish to the registry
-
Subscription URL: The URL of the Subscription API endpoint used for subscribing to registry changes, creating a registry subscription, and listening for changes to imported services.
46.2.2 UDDI Registry Security Configuration
You can make your UDDI registries available in Service Bus by creating a UDDI registry resource, which defines the connection information for the UDDI registry. You can then publish Service Bus proxy services to the registry or import business services from the registry to be used in a proxy service. You specify the UDDI URLs in the resource, and optionally specify security information. When publishing services to most registries, the proxy service configuration must include a valid user name and password for authentication to gain access to the registry.
You can set up registries with multiple user names and passwords allowing different users to have different permissions based on the associated service accounts. In Service Bus, user permissions govern access to the registries, their content, and available functionality.
46.2.3 Authentication Configuration and UDDI Registries
When a proxy service is published to a UDDI registry, the service is converted into a WS business service with the WSDL document. If present, the authentication configuration is also exported to UDDI. When a WSDL-based business service with WSRM policy is imported from an UDDI registry to Service Bus, the service is imported as a WS business service that is automatically configured to use the WS transport.
Transport-level custom authentication tokens are published to the UDDI. The client-auth
property is present in the instanceParms
of the HTTP or HTTPS transport attributes whenever authentication is configured. As described in Transport Attributes., the possible values of 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
.
Note:
Service Bus business service definitions do not support custom token authentication. If you import a service from UDDI that has client-auth
equal to CUSTOM-TOKEN
, the service is imported as if it does not have any authentication configuration.
46.2.4 About Publishing Proxy Services to a UDDI Registry
Use the Oracle Service Bus Console or JDeveloper to publish proxy services to a UDDI registry and make it available for other organizations to discover and use. All proxy services developed in Service Bus can be published to a UDDI registry. You can select the business entity under which you want to publish your service and you can publish a number of services at a time.
To do this you must have a user account set up in the UDDI registry. You can publish any proxy service to a UDDI registry and 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 first time you publish to a registry you must load the tModels to that registry. You do this when you configure the publishing details in the console or JDeveloper. For more information on how to publish to a UDDI registry, see Publishing Proxy Services to a UDDI Registry.
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 a 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).
Before you publish services to a UDDI registry from a clustered domain, be sure that none of the servers in the cluster use localhost in the server addresses. Instead, use either the machine name or the IP address.
You can publish local proxy services to a UDDI registry in order to associate them with Service Bus generic proxy services. For example, you might have an any SOAP or any XML generic proxy service that dynamically routes to multiple local transport proxy services with concrete WSDL files. Alternatively, you might have a generic proxy service in Service Bus 1 that dynamically routes to a generic proxy service in Service Bus 2 where the business service is attached. From the UDDI registry, you can get the WSDL file of the local proxy service and the URL of the any SOAP or any XML generic proxy service. Combining the WSDL file and URL creates an effective WSDL file for sending messages to the local proxy service through the generic proxy service.
46.2.5 About Importing Services from a UDDI Registry
You can import services from a UDDI registry as Service Bus business services. When importing a WSDL-based service, if multiple UDDI binding templates are encountered, Service Bus creates a different business service for each binding template.
For information about the security roles required to establish access to UDDI registries in Service Bus, see "Role-Based Access in Oracle Service Bus" in Administering Oracle Service Bus. When importing, you select from the list of available registries. In the Oracle Service Bus Console, you can view the complete list of registries on the UDDI Folder Definition Editor. When you import from a registry, you discover services by querying that registry. In JDeveloper, you can view the available registries in the Resources window and browse through the list to discover a service. Entries in registries are unique.
You can import the following business services types from a UDDI registry into Service Bus:
-
WSDL over HTTP binding. When multiple UDDI binding templates are present, a business service is created for each binding template.
-
SOAP or XML binding over HTTP.
-
Services that are categorized as Service Bus services. These are proxy services that are published to a UDDI registry. This feature is primarily used in multi-domain Service Bus deployments where proxy services from one domain need to discover and route to proxy services in another domain.
Services have documents associated with them, and those 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 Service Bus.
46.2.5.1 About Business Entities and Patterns
Business entity and pattern are the criteria used to search for a service in a registry. Services published by Service Bus have specific tModel keys identifying the services that you use when searching for the service in 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 system administrator.
46.3 Keeping Services Synchronized
You can keep the service definitions in 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 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 Oracle Service Bus Console or JDeveloper to prompt you for approval for synchronization when a service changes in the UDDI registry.
46.3.1 Automatic Publishing for Proxy Services
When you configure a proxy service in the Oracle Service Bus Console, you can configure it to be published automatically to a default UDDI registry. This feature is not available in JDeveloper. You must first set up a default registry and configure the proxy service to automatically publish to the default registry. When you activate these changes, the proxy service is published to the default registry. If the UDDI registry is unavailable, the publish action is retried. Any further changes to the proxy service resets the retry attempts. When a proxy service is republished to a UDDI registry, all taxonomies and categorizations, which are defined in UDDI for the proxy service, are preserved.
For instructions, see How to Specify a Default UDDI Registry Resource and How to Automatically Publish Proxy Services to a UDDI Registry.
46.3.1.1 Changes to the Default Registry
When you change the default registry, all the proxy services that have auto-publish enabled are published to the new default registry. Synchronization then takes place with the current default registry. When a proxy service is not synchronized, the Oracle Service Bus Console displays an unsynchronized icon.
Note:
When you have a default registry and you import a configuration JAR file that 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. This might result in errors on the Auto Publish Status page if there are any auto-published proxy services. You can correct this situation by selecting the default registry again.
46.3.1.2 Auto-Publish Synchronization Process
When auto-publish is enabled for a proxy service, you can use the Auto Publish Status page on the Oracle Service Bus Console to view and manage the service synchronization process. This page displays a list of published proxy services along with their status. If any errors prevent a service from automatically publishing the registry, you can retry publishing them from this page.
If a proxy service changes after being published, you can synchronize the changes using the Admin features in the Oracle Service Bus Console. If auto-publish is enabled, Service Bus automatically publishes any changes to the service in the registry. In addition, the Auto Publish Status dialog shows this service and provides options for publishing the service to the registry.
46.3.2 Automatic Importing of UDDI Services
You can use the auto-import feature to synchronize the business services that were imported from a UDDI registry with the corresponding services in the registry. For instructions, see How to Automatically Synchronize Imported Services.
Note:
Auto-import is available only in the Oracle Service Bus Console, and not in JDeveloper.
When a service is updated, you must re-import the service from the registry to get the most recent version unless auto-import is enabled in the UDDI registry resource. When the Enable Auto-Import option is selected, any service that is imported is automatically kept synchronized with the UDDI registry. Any failure that occurs during auto-synchronization is reported on the Auto-Import Status page where you can synchronize it manually.
When auto-import is enabled, you can use the Auto Import Status page to view and manage the service synchronization process. You can either synchronize a service with the registry or unlink the service to avoid synchronization on this page.
46.3.2.1 Synchronization of Imported Services
If the services you have imported from a UDDI registry are changed in the registry change, you can synchronize the services with those in the registry using the Admin features in the Oracle Service Bus Console. If auto-import is enabled and a business service is not unlinked from the registry, Service Bus automatically subscribes to any changes to the service in the registry. The Auto Import Status dialog shows this service and provides options for synchronizing the service or unlinking it from the registry. Under certain circumstances, synchronizing the service might result in semantic validation errors, which could prevent session activation. In that case, unlinking might be a better choice.
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. This includes policy configurations.
Consider a scenario where you publish services from Domain1 to a registry. You then import these services from the registry into a domain, Domain2 (see Figure 46-3). Then you make changes to the services in Domain1 and update them in the registry. You can update the services in Domain2 by synchronizing them with the registry using the auto-import feature.
Figure 46-3 Sample Business Case of Cross-Domain Deployment
![Description of Figure 46-3 follows Description of Figure 46-3 follows](img/uddicrossdomaindeploy.gif)
Description of "Figure 46-3 Sample Business Case of Cross-Domain Deployment"
46.3.2.2 Unlinking Imported Services
There may be times when you do not want the service in the Oracle Service Bus Console to be synchronized with the corresponding service in the registry. You can avoid synchronization by unlinking the service from the registry. See How to Unlink an Imported Service From the UDDI Registry.
46.4 Related References
This section provides links to documents which provide additional UDDI information.
-
Technical Notes can be found at
http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm
. The note on Using WSDL in a UDDI Registry is important. -
UDDI product and development tool information is available at the OASIS UDDI Solutions page at
http://uddi.org/solutions.html
. -
The UDDI specifications
http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm
The specification defines the following:
-
SOAP APIs that applications use to query and to publish information to a UDDI registry
-
XML schema of the registry data model and the SOAP message formats
-
WSDL definitions of the SOAP APIs
-
UDDI registry definitions (tModels) of various identifier and category systems that may be used to identify and categorize UDDI registrations
-
46.5 Working with UDDI Registry Resources
In order to access a UDDI registry in Service Bus, you need to create and configure a UDDI registry resource, which describes the registry.
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 Service Bus can be published to a UDDI registry.
46.5.1 How to View UDDI Registry Resources in the Oracle Service Bus Console
The Folders Definition Editor for UDDI registries lists all the UDDI registry resources you have created in the current session. Use this page to quickly find and access the UDDI registry resources you have defined.
To view UDDI registries in the console:
46.5.2 How to Create UDDI Registry Resources
When you create a UDDI registry resource, you specify connection information for the remote server, including URLs, security credentials, and whether to automatically synchronize services. After you create a registry, you can then publish Service Bus proxy services to them or import business services from them to be used in a proxy service.
To create a UDDI registry resource:
-
Do one of the following:
-
If you are using JDeveloper, expand the Application Resources panel, right-click Service Bus System Resources, point to New, and then select UDDI Registry.
Note:
To create UDDI registry resources directly in a project, making it a project-level resource, right-click the project, point to New, and then select UDDI Registry.
-
If you are using Oracle Service Bus Console, expand the System project, right-click UDDI, point to Create, and then select Create UDDI Registry.
The Create UDDI Registry dialog appears.
-
-
Enter a name and optional description for the resource, and then click Finish or Create.
The UDDI Registry Definition Editor appears and the new UDDI registry resource appears in the Systems folder of the Oracle Service Bus Console or in the Service Bus System Resources folder in the Application Resources panel of JDeveloper.
-
Enter the inquiry, publish, subscription, and security URLs for the UDDI registry.
For more information, see UDDI Registry URLs.
-
To publish the Service Bus tModels to the registry, select Load T-Models into Registry.
This field is only required when publishing proxy services to this registry.
-
To automatically synchronize services with the UDDI registry, select Enable Auto-Import.
Any service that is imported with this option selected will be kept in synchrony with the UDDI registry.
Note:
Auto-synchronization is a background process; you cannot reverse it using the session Undo function. Undoing an auto-synchronization change is not permanent as the service will be re-synchronized in the next synchronization cycle. If you want an imported service to stay out of synchrony with the UDDI registry, you have to detach the service to avoid further updates from the registry. See How to Unlink an Imported Service From the UDDI Registry.
-
If access to the UDDI registry console requires a user name and password, enter a user name in the User Name field, and the associated password in the Password and Confirm New Password fields.
-
Click Save.
-
Test the UDDI URLs by doing one of the following:
-
If you are using JDeveloper, click Test Connection.
-
If you are using the Oracle Service Bus Console, click Test and Validate UDDI Registry.
-
-
If you are using the Oracle Service Bus Console, click Activate to end the session and deploy the configuration to the runtime.
46.5.3 How to Create a UDDI Registry Resource from a JDeveloper UDDI Connection
In JDeveloper, you can create a UDDI registry resource from an existing UDDI registry connection. Conversely, you can also create a UDDI registration connection from a UDDI registry resource.
To create a UDDI registry resource from a UDDI connection:
46.5.4 How to Edit a UDDI Registry Resource
Once you create a UDDI registry resource, you can modify its description and most of the UDDI properties.
To edit a UDDI registry resource:
-
Expand the project and folders containing the resource to edit. This can be any of the following locations:
-
In JDeveloper, the Service Bus System Resources folder in the Application Resources panel.
-
In JDeveloper, the Service Bus project or folder in which the UDDI registry resource is located in the Application Navigator.
-
In Oracle Service Bus Console, the UDDI folder in the System project.
-
-
Right-click the UDDI registry name, and select Open.
The UDDI Registry Definition Editor appears.
-
Modify any of the fields described in How to Create UDDI Registry Resources. The online help describes these fields in greater detail.
-
When you are done making changes, click Save.
-
Test the UDDI URLs by doing one of the following:
-
If you are using JDeveloper, click Test Connection.
-
If you are using the Oracle Service Bus Console, click Test and Validate UDDI Registry.
-
-
If you are using the Oracle Service Bus Console, click Activate to end the session and deploy the configuration to the runtime.
46.5.5 How to Specify a Default UDDI Registry Resource
You can designate one of the UDDI registries that has already been configured and activated as the default registry for the domain. To use the auto-publish functionality, you must first set a default registry. For more information, see Automatic Publishing for Proxy Services.
To specify a default UDDI registry resource:
46.5.6 How to Delete a UDDI Registry Resource
When you delete a UDDI registry resource, any references to the resource from other Service Bus resources are broken. Before deleting the resource, check for dependencies. In the Oracle Service Bus Console, open the UDDI registry resource in the UDDI Registry Definition Editor and click the Tools icon in the upper right, and then select References. In JDeveloper, right-click the UDDI registry and select Explore Dependencies.
To delete a UDDI registry resource:
46.6 Sharing UDDI Registry Services in JDeveloper
In JDeveloper, you can create business services from services located in a UDDI registry, or you can simply download a service to a Service Bus project.
When working with UDDI registries in JDeveloper, you need to create a JDeveloper UDDI registry connection and a Service Bus UDDI registry resource. The registry connection lets you access and browse the registry in the Resources window and in the various selector dialogs that let you browse to and select artifacts for your projects. The registry resource specifies the API endpoint URLs and security information for the registry.
46.6.1 How to Create a UDDI Registry Connection in JDeveloper
You can create a UDDI registry connection using JDeveloper's New Gallery, or you can create the connection from an existing UDDI registry resource in the Application Resources panel. The following instructions describe how to create the connection from the resource.
Before You Begin:
Before you can work with a registry in JDeveloper, you must have an account with that registry. Service Bus supports interoperability with UDDI registries that are compliant with the version 3.0 specification.
To create a UDDI connection in JDeveloper:
46.6.2 How to Create a Business Service from a UDDI Registry Service
In JDeveloper, you can create business services from services stored in a UDDI registry. You cannot publish services to the UDDI registry from JDeveloper. When you perform these steps, the business service is created in the location you specify in the current application.
To create a business service from a UDDI registry service:
46.7 Sharing UDDI Registry Services in the Oracle Service Bus Console
The Oracle Service Bus Console provides several options for publishing and importing from UDDI registries, including manual procedures and automatic processing.
Before you can publish to or import from a registry, you must have an account with that registry. Service Bus supports interoperability with UDDI registries that are compliant with the version 3.0 specification.
Note:
If you need to unpublish a service from a registry, this is done from the UDDI registry.
46.7.1 Publishing Proxy Services to a UDDI Registry
You can publish any Service Bus proxy service to a UDDI registry so it is available for other organizations to discover and use. When you publish a service, you can optionally select the business entity under which the service is published and you can publish a number of services at one time. You can only publish from the Oracle Service Bus Console, and not JDeveloper.
Note:
If the service is not successfully published it can be re-published. To re-publish a service, select the service on the Auto-Publish Status page and click Publish.
If the Publish to Registry option is enabled, the proxy services are published as soon as they are created or edited and the session is activated. You can use the Publish to Registry option with all proxy services, except those using the Local Transport.
46.7.1.1 How to Automatically Publish Proxy Services to a UDDI Registry
You can automatically publish proxy services to the default UDDI registry that you configure for a session. In order to enable automatic publishing, you need to enable auto-publishing on the service and you need to define the default UDDI registry so Service Bus knows which UDDI registry to publish services to.
To automatically publish a proxy service to a UDDI registry:
46.7.2 How to Import Resources from a UDDI Registry
You can import the following business service types from a UDDI registry into the Oracle Service Bus Console:
-
WSDL services over HTTP transport.
-
Service Bus proxy services that are published to a UDDI registry. This feature is primarily used in multi-domain Service Bus deployments where proxy services from one domain need to discover and route to proxy services in another domain.
You can import multiple resources from a UDDI registry at one time.
Before you begin:
In order to access the UDDI registry to import resources from, you must create a UDDI resource in Service Bus. For more information, see How to Create UDDI Registry Resources.
To import resources from a UDDI registry in the console:
46.7.3 How to Automatically Synchronize Imported Services
The Auto-Import Status page lets you synchronize changes to a service with those present in the registry. Any service imported while automatic import is enabled is kept synchronized with the UDDI registry. Upon any changes to a service in the registry, Service Bus provides notification of the change on the Auto-Import Status page, which lists all out-of-sync services.
To enable automatic import for a UDDI registry:
46.7.4 How to Manually Synchronize an Imported Service
When automatic import is enabled and there are any failures during auto-synchronization, the errors are reported on the Auto-Import Status page. After fixing the errors, you can synchronize the services manually.
To synchronize a service with the UDDI registry:
46.7.5 How to Unlink an Imported Service From the UDDI Registry
When you do not want the service in the Oracle Service Bus Console synchronized with the corresponding service in the registry, you can avoid synchronization by detaching it from the registry.
Unlinking a business service from the UDDI registry cannot be undone. You have to re-import the service manually to link them back up.
To unlink an imported service from the UDDI registry:
46.8 Sample Business Scenarios for Service Bus and UDDI
These sections contain two sample business scenarios that highlight the benefit of using UDDI.
46.8.1 Basic Proxy Service Communication with a UDDI Registry
This scenario illustrated using Service Bus to import services from a registry and then publish Service Bus proxy services back to the registry. See Figure 46-4.
Figure 46-4 Proxy Service Communication with a UDDI Registry
![Description of Figure 46-4 follows Description of Figure 46-4 follows](img/uddiproxyservicecomm.gif)
Description of "Figure 46-4 Proxy Service Communication with a UDDI Registry"
Service Bus imports business services from a UDDI registry. Proxy services are configured to communicate with the business services in the pipeline. The proxy services can then be published back to the registry and made available for use by other domains.
46.8.2 Cross-Domain Deployment in Service Bus
This scenario shows cross-domain deployment using Service Bus. In this scenario, a Service Bus application in one domain requires access to a Service Bus service in another domain at runtime. See Figure 46-5.
Figure 46-5 Sample Business Case of Cross-Domain Deployment
![Description of Figure 46-5 follows Description of Figure 46-5 follows](img/uddicrossdomaindeploy.gif)
Description of "Figure 46-5 Sample Business Case of Cross-Domain Deployment"
An instance of Service Bus is deployed in each of two domains. The Service Bus proxy service (P1) is configured in domain (D1). The Service Bus proxy service (P2) in domain (D2) requires access to proxy service (P1). As the domains cannot communicate directly with each other, P2 in D2 cannot use P1 in D1. The Service Bus import and export feature does not support runtime discovery of services in different domains, but publishing the service to a UDDI registry allows the discovery and use of a service in any domain. Once P1 is made available in the UDDI registry it can be invoked at runtime (for example, get a stock quote) and imported as a business service in another 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 you need HTTP access to the domain to import it using the URL. In the absence of connectivity an error message is returned.
46.9 Mapping Service Bus Proxy Services to UDDI Entities
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.
Table 46-2 shows the service types, message types, and transports relevant to the UDDI registry mapping for a proxy service.
Table 46-2 Proxy Service Attributes and Service Types
Service Type | Message Content Type | Transports |
---|---|---|
WSDL |
SOAP or XML (with attachment) |
HTTP, JMS, Local, SB, WS |
Transport Typed |
SOAP or XML |
JEJB |
Any SOAP |
Untyped SOAP (with attachment) |
HTTP, JMS, Local, SB |
Any XML |
Untyped XML (with attachment) |
Email, File, FTP, HTTP, JMS, Local, MQ, SB, SFTP, Tuxedo |
Messaging |
Binary, Text, MFL, XML (schema) |
Email, File, FTP, HTTP, JMS, Local, MQ, SFTP, Tuxedo |
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). Email, File, SFTP, 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 include the following:
-
businessService
: Represents the service as a whole and contains high-level general information about the service. -
bindingTemplate
: Contains information for accessing the service. -
tModels
: Supplies the individual attributes for categorizing and defining the service.
Figure 46-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 Service Bus proxy services as entities in the UDDI registry, you must provide additional canonical tModels to support some of the constructs specific to Service Bus. Not all attributes of a 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 Service Bus maps to UDDI is shown in Figure 46-7.
46.9.1 UDDI Mapping Details for a Service Bus Proxy Service
Service Bus high-level proxy service information maps to the business service as follows:
-
The Name and Description map to
businessService elements
. -
There is a special
keyedReferenceGroup
for Service Bus properties. An example of a key isuddi:bea.com:attributes:oracleservicebus
. -
Service Bus type (WSDL, SOAP, XML, and Mixed) and instance are mapped to
keyedReferences
in the service category. An example of a key isuddi:bea.com:servicetype
. -
A Service Bus instance maps to a
keyedReference
in the Service BuskeyedReferenceGroup
(Name = "OracleServiceBus
", Values = URL of the Service Bus instance).This instance serves two purposes:
-
To indicate that this service is in fact hosted by a Service Bus server.
-
To contain the URL of the Service Bus instance.
-
The following example shows a mapping of high-level proxy service information to a business service.
Example - Sample Proxy Service to Business Service Mapping
<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 Service Bus domain name, the path of the proxy service, and the proxy service name. It takes the following form:
uddi:bea.com:servicebus:<domainname>:<path>:<servicename>
For example, AnonESBan, a Service Bus domain, 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:
uddi:bea.com:servicebus:AnonESB:Proxies:Accounting:PayoutProxy
Service Bus detailed proxy service information maps into the binding template as follows:
-
The Endpoint URI maps to the access point.
-
The Marker tModel for each transport maps to
tModelInstanceDetails
.-
Transport tModels for HTTP, JMS, File, FTP, Email. New tModels are packaged with Service Bus to support JMS and File transports.
-
Detailed Service Bus configuration information maps to
instanceParms
.
-
-
The Marker tModel for each service type maps to the
tModelInstanceDetails
. This includes the following:-
Protocol tModels for WSDL, any SOAP, any XML, and Messaging. New tModels are packaged with Service Bus to support anySOAP, anyXML, and Messaging.
-
WSDL maps using WSDL to UDDI technology note.
-
Messaging has detailed configuration information that maps to
InstanceParms
.
-
The following example shows a detailed information mapping to the binding template.
Example - Sample Detailed 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://example.com:7001 /sbresource?SCHEMA%2FDJS%2FOAGProcessPO"/> <property name="RequestSchemaElement" value="PROCESS_PO"/> <property name="responseType" value="None"/></ALSBInstanceParms> </InstanceParms> </InstanceDetails> </tModelInstanceInfo> </tModelInstanceDetails> </bindingTemplate>
46.9.2 Transport Attributes
Each of the transport types in the uddi:uddi.org:transport: *
group has a different set of detailed metadata. See Table 46-2. This metadata provides the 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 configuration details, including the required client authorization and the request and response character encoding. The following example provides an example of what must appear in the bindingTemplate tModelInstanceDetails
.
Example - Example of 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 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 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 46-3 is organized by transport type and lists the tModelKey
and instanceParms
used by each of the transports.
Table 46-3 Transport Attributes
Transport | tModelKey | InstanceParms |
---|---|---|
EmailFoot 1 |
uddi:uddi.org:transport:smtp |
|
File |
uddi:uddi.org:transport:file |
|
FTP |
uddi:uddi.org:transport:ftp |
|
HTTP |
uddi:uddi.org:transport:http |
|
JEJB |
uddi:uddi.org:transport:jejb |
|
JMS |
uddi:uddi.org:transport:jms |
|
Local |
uddi:uddi.org:transport:local |
None |
MQ |
uddi:bea.org:transport:mq |
|
SB |
uddi:bea.org:transport:sb The URI scheme is |
None |
SFTP |
uddi:bea.org:transport:sftp |
|
Tuxedo |
uddi:bea.org:transport:tuxedo |
|
WS |
uddi:uddi.org:transport:http WS uses the HTTP tModelKey |
None |
Footnote 1
The accessPoint in the Binding Template for an Email transport uses the standard mailto URL format: mailto:name@example.com
. This is different from the one configured for the proxy service in Service Bus, which is a URL oriented toward reading email. It is not be possible to derive this mailto URL from the proxy service definition as the server name is not known. For example, if the proxy service is defined to read from a POP3 server, it might be defined with a URL such as mailfrom:pop3.bea.com. When publishing such a proxy service, a dummy server is added. In the above example, the published URL will take the form mailto:some_name@example.com.
46.9.3 Service Type Attributes
Table 46-4 provides a high-level description of each of the service types.
Table 46-4 Service Type Attributes
Service | Description |
---|---|
WSDL |
WSDL-based proxies map to UDDI based on the Using WSDL in a UDDI Registry, version 2.0.2 technical note at URL: |
Any SOAP |
A simple marker protocol in the tModel in the |
Any XML |
A simple marker protocol tModel within the |
Messaging Services |
A simple marker protocol tModel in the bindingTemplate
|
46.9.4 Canonical tModels Supporting Service Bus Services
The Service Bus to UDDI mapping provides a number of canonical tModels that are used to represent Service Bus metadata and relationships. These tModels must be registered in the UDDI registry to support this mapping. You can create the tModels in the UDDI registry under the administrator ID.
Table 46-5 through Table 46-8 provide a summary of the tModels.
Table 46-5 CategorizationGroup tModel Types
Name | Description |
---|---|
bea-com:servicebus:properties |
Describes very specific attributes of a Service Bus service. In the data model it is used in the business service |
Table 46-6 Categorization tModel Types
Name | Value | Description |
---|---|---|
bea-com:servicebus:serviceType |
WSDL, SOAP, XML, Messaging Service |
Describes the service type of the Service Bus service. |
bea-com:servicebus:instance |
URL of Service Bus Administration Console |
Describes the service instance in Service Bus responsible for publishing the service to UDDI. |
Table 46-7 Transport tModel Types
Name | Description |
---|---|
uddi-org:jms |
Describes the type of transport used by the service. A reference to it is found in the accessPoint attribute of the business service binding template. |
uddi-org:file |
Describes the type of transport used to invoke the service. A reference to it is found in the accessPoint attribute of the business service binding template. |
Table 46-8 Protocol tModel Types
Name | Description |
---|---|
bea-com:servicebus:anySoap |
Describes the type of protocol used to access the service. It designates services that have a SOAP message but not defined by a WSDL file or schema. The message body content is determined dynamically by the application. |
bea-com:servicebus:anyXML |
Describes the type of protocol used to access the service. It designates services having an XML message but not defined by a WSDL file or schema. The message body content is determined dynamically by the application. |
bea-com:servicebus:messagingService |
Describes the type of protocol used to access the service. It designates services where the request message can be any XML (with or without schema), text, binary, or MFL and whose response message can be any of the above or none. The message body content is determined dynamically by the application. |
46.9.5 Mapping Example
The following example is a sample 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.
Example - Sample Messaging Service Mapping
<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://example.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://example.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://example.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>