Working with UDDI Registries

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 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 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 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:

Expand the System project, right-click UDDI, and then select Open.

The Folder Definition Editor appears with a list of existing UDDI registry resources.
To locate specific UDDI registry resources, do the following:
- If the query fields are not visible above the UDDI table, click Query by Example in the table toolbar.
- Enter the name of the UDDI registry resource you want to find above the Name column, and press Enter.
  
  You can enter wildcard characters (? for a single character; * for multiple characters) to perform a more general search.
- To view all UDDI registry resources again, clear the query fields and press Enter.
To view the configuration for a UDDI registry, click the resource name in the UDDI table.
To delete a UDDI registry resource, select the name of the resource in the table and click Delete. See How to Delete a UDDI Registry Resource.

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:
1. If you are using JDeveloper, click Test Connection.
2. 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:

In the toolbar, click Window and then select Resources to display the Resources window.
Expand IDE Connections and UDDI Registry.
Right-click a UDDI connection, point to Service Bus, and select Create Service Bus UDDI Registry Resource.

The Create UDDI Service dialog appears.
Enter a name for the resource, or accept the default, and click Finish.

The UDDI Registry Definition Editor appears with the inquiry URL already populated, based on the URL specified for the UDDI registry connection.
Complete the remaining fields, as described in How to Create UDDI Registry Resources.

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:
1. If you are using JDeveloper, click Test Connection.
2. 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:

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 resource, and select UDDI Settings.

The UDDI Settings dialog appears.
In the Default UDDI Registry list, select the name of the registry you want to set as the default registry.

Note:

The list displays all UDDI registries you have created, but you can only select one that has already been activated.
In the Default Business Entity list, select the name of the business entity you want to set as the default entity. This is optional.
Click OK.
When you are done making changes, click Save.
If you are using the Oracle Service Bus Console, click Activate to end the session and deploy the configuration to the runtime.

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:

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 resource, and select Delete.
If you are using JDeveloper, a confirmation dialog displays the number of references for the resource. Click Show Usages to view information about the references, and then click Yes to confirm that you want to delete the resource.
If you are using the Oracle Service Bus Console, click Activate to end the session and deploy the configuration to the runtime.

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:

If it does not already exist, create the UDDI registry resource, as described in How to Create UDDI Registry Resources.
In the Application Resources panel, expand Service Bus System Resources.
Right-click the UDDI registry resource for which you want to create a connection, point to Service Bus, and click Create UDDI Connection.

The new connection is created based on the configuration of the UDDI registry resource.
To display the Resources window and access the connection, click Window in the toolbar and then select Resources. Expand IDE Connections and UDDI Registry.
To modify the connection properties and test the connection, right-click the connection and select Properties.

The Edit UDDI Registry Connection wizard appears, where you can modify the inquiry endpoint URL and the view, and you can test the connection.

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:

If the Resources window is not visible, click Window and then select Resources.
In the Resources panel, expand IDE Connections and UDDI Registry.
Locate the UDDI registry containing the web service you want to access, and browse through the nodes until you find the service.

Tip:

Alternatively, you can perform a search in the Resources window for the service to use.
Under the service name, expand Binding Templates, until you see the binding you want to use.
Right-click the binding, point to Service Bus, and then select Generate Business Service.

The Consume Service wizard appears. The service WSDL file and endpoint are automatically configured based on the service you selected.
By the Service Artifacts Folder field, click Browse to navigate through the current application and select a project or folder in which to create the business service.

For more information at any time, press F1 or click Help from within the Create Business Services wizard.
Click Next.
On the Create Service page, enter a name for the business service in the Service Name field.
Optionally add a description and update the location on the file system (this location must be somewhere within the application folder). The WSDL information is automatically configured.
Click Next.
On the Transport page, specify the transport to use for the business service. The available options vary depending on the type of service selected.
Update the endpoint URI if necessary.
Click Finish.

The business service is created, and the Business Service Definition Editor appears so you can finish configuring the service. For more information, see Creating and Configuring Business Services.

46.6.3 How to Download a Service From a UDDI Registry

If you want to use a specific service in a Service Bus project, you can download the service and any related files to the project.

To download a service from a UDDI registry:

If the Resources window is not visible, click Window and then select Resources.
In the Resources panel, expand IDE Connections and UDDI Registry.
Locate the UDDI registry containing the web service you want to access, and browse through the nodes until you find the service.

Tip:

Alternatively, you can perform a search in the Resources window for the service to use.
Under the service name, expand Binding Templates, until you see the binding to use.
Right-click the binding, point to Service Bus, and then select Download.

The Import Service Bus Resources wizard appears. The resource type and source URL are automatically configured based on the service you selected.
In the Resource Name field, enter a new name for the service, or accept the existing name.

For more information at any time, press F1 or click Help from within the Import Service Bus Resources wizard.
By the Import Location field, click Browse to navigate through the current application and select a project or folder in which to download the service.
Click Next.
Verify the resources to be downloaded and then click Finish.

The service is added to the project or folder you specified, and the WSDL Editor appears.

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:

Specify a default UDDI registry to which proxy services will publish.

For instructions, see How to Specify a Default UDDI Registry Resource.
In the Oracle Service Bus Console's Project Navigator, expand the project and folders containing the proxy service to configure.
Right-click the proxy service name, and select Open.
Under UDDI on the General page, select Auto Publish to Registry.

Note:

if there is no UDDI section, there is no default UDDI registry specified. For more information, see How to Specify a Default UDDI Registry Resource.
Click Save.

For more information about editing proxy services, see Configuring Proxy Services.
Click Activate to end the session and deploy the configuration to the runtime.
To verify that the proxy service was published, click the Admin tab and click Auto-Publish Status.

The proxy service should appear in the list of published services.

46.7.1.2 How to Manually Publish a Proxy Service to a UDDI Registry

You can only publish services to a UDDI registry when you are not in a session. Exit your session to enable UDDI publishing and access the registries list.

To manually publish a proxy service to a UDDI registry:

Right-click a folder or project, point to Export, and then select Publish to UDDI.

The Publish to UDDI dialog appears.
In the Registry Name field, select the UDDI registry to which the services will be published.
In the Business Entity field, select the business entity in the UDDI registry under which the services will be classified.
In the Proxy Services table, specify which proxy services to export to the registry.

By default, all proxy services in the session are selected. Clear the check boxes for any services you do not want to export.
Click Publish.

The Publish Summary page appears, and indicates whether the services were published successfully. It also lists any messages generated during the publishing process.
To publish another set of proxy services, click Publish Another. Otherwise, click Close.

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:

Do one of the following:
- Right-click the folder or project where you want to import the resource, point to Import, and then select From UDDI.
- Right-click All Projects, point to Import, and then select From UDDI. On the Destination page of the Import from UDDI dialog, select the project or folder where you want to import the service and then click Next.
The Import from UDDI dialog appears with the Service page displayed.
In the Registry Name field, select the UDDI registry from which the services will be imported.
In the Business Entity field, select the business entity in the UDDI registry under which the services are located. Select All to search all business entities in the registry.
In the Service Name field, enter the name of a service to import.

Searches accept wildcard characters ("*" for multiple characters and "%" for a single character).
Click Search.

A list of matching business services appears in the Business Services table. If you are unable to find a specific service, it may be because you do not have the security permissions to view its records.
In the Business Services table, select the business services to import from the registry.
Click Next.
If a selected business service has multiple binding templates, the Binding Template page appears. For each listed service, select one binding template to use to create the business service.

Note:

If a selected service has multiple binding templates, each binding template results in a business service. The Binding Template page lets you further narrow your selection among the binding templates you want to import.
Click Next.

The Review page appears, displaying a summary of the resources to be imported. A warning message is displayed for any resource that cannot be imported.
Verify the list of resources selected to be imported, and then click Import.

The selected resources appear in the Project Navigator. The Import from UDDI wizard displays a summary of the import along with any errors in the imported resources.
To import another set of business services, click Import Another. Otherwise, click Close.

The import process can result in dependency issues. To view and resolve any resulting conflicts, click the Conflicts tab at the bottom of 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:

In the Oracle Service Bus Console's Project Navigator, expand the System project and UDDI folder.
Right-click the UDDI registry resource name, and select Open.
Select Enable Auto-Import.
Click Save.

Any services imported from a UDDI registry are kept synchronized with those in the UDDI registry. You can view the status of synchronized services on the Auto-Import Status page.

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:

In the Oracle Service Bus Console, click the Admin tab and then click Auto-Import Status.

The Auto-Import Status dialog appears.
In the list of services, select the check box next to the service you want to synchronize to the UDDI registry.
Click the Synchronize icon above the table.

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:

In the Oracle Service Bus Console, click the Admin tab and then click Auto-Import Status.

The Auto-Import Status dialog appears. Services are shown on this page only when there is a change in the original service in the registry. Not every service is available on this page.
In the list of services, select the check box next to the service you no longer want to be linked to the UDDI registry.
Click the Unlink icon above the table.
On the Warning dialog that appears, click OK to unlink the service, or click Cancel if you no longer want to unlink the service.
Click Close on the Auto-Import Status dialog.

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 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 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.

Figure 46-6 WSDL Service to UDDI Mapping

Description of "Figure 46-6 WSDL Service to UDDI Mapping"

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.

Figure 46-7 Service Bus to UDDI Mapping

Description of "Figure 46-7 Service Bus to UDDI Mapping"

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 is uddi: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 is uddi:bea.com:servicetype.
A Service Bus instance maps to a keyedReference in the Service Bus keyedReferenceGroup (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
Email^Foot 1	uddi:uddi.org:transport:smtp	Attachment Supported [Boolean] Request Encoding
File	uddi:uddi.org:transport:file	File Mask Sort by Arrival [Boolean] Request Encoding
FTP	uddi:uddi.org:transport:ftp	File Mask Sort by Arrival [Boolean] Transfer Mode [Text, Binary] Request Encoding
HTTP	uddi:uddi.org:transport:http	Client Authentication [None, Basic, Client Certificate (HTTP only), and Custom Token] Request Encoding Response Encoding
JEJB	uddi:uddi.org:transport:jejb	URI EJB Spec Version Client JAR Home Interface (not published for EJB 3.0) Remote Interface (business interface for EJB 3.0) Method Names
JMS	uddi:uddi.org:transport:jms	Destination Type [Queue, Topic] Response Required, Response URI Response Message Type [Bytes, Text] Request Encoding Response Encoding
Local	uddi:uddi.org:transport:local	None
MQ	uddi:bea.org:transport:mq	Response Required Response URI Response Correlation Pattern
SB	uddi:bea.org:transport:sb The URI scheme is `sb` when `use ssl` is false; `sbs` when `use ssl` is true.	None
SFTP	uddi:bea.org:transport:sftp	File Mask Sort by Arrival [Boolean] Request Encoding Authentication Mode
Tuxedo	uddi:bea.org:transport:tuxedo	Response Required Access Point ID Buffer Type Buffer Subtype Classes Jar Field Table Classes View Classes
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: `http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm`.
Any SOAP	A simple marker protocol in the tModel in the `bindingTemplate` `tModelInstanceDetails`, as well as in the `categoryBag`, defines the Any Soap attributes.
Any XML	A simple marker protocol tModel within the `bindingTemplate` `tModelInstanceDetails`, as well as in the `categoryBag` defines the Any XML attributes.
Messaging Services	A simple marker protocol tModel in the bindingTemplate `tModelInstanceDetails`, defines the messaging services attributes. Unlike the other service types, messaging services have additional configuration information associated with them, which provides detail 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`: Input message format (XML, Text, Binary, MFL) URL of input message schema in Service Bus (optional, if input message is XML) URL of input message MFL in Service Bus (if input message is MFL) Output message format (none, XML, Text, Binary, MFL) URL of output message schema in Service Bus (optional, if output message is XML) URL of output message MFL in Service Bus (if output message is MFL)

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 `categoryBag`.

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>