41 UDDI

This section contains the following topics:

41.1 UDDI, UDDI Registries, and Web Services

UDDI stands for Universal Description, Discovery, and Integration. The UDDI Project is an industry initiative which aims to enable businesses to quickly, easily, and dynamically find and carry out transactions with one another.

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.

UDDI registries are used in an enterprise 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 run-time aspects of the services (it is only a directory of the services). UDDI provides a framework in which to classify your business, its services, and the technical details about the services you want to expose.

Publishing a service to a registry requires knowledge of the service type and the data structure representing that service in the registry. A registry entry has certain properties associated with it and these property types are defined when the registry is created. You can publish your service to a registry and make it available for other organizations to discover and use. Proxy services developed in Oracle Service Bus can be published to a UDDI registry. Oracle Service Bus can interact with any version 3.0-compliant UDDI registry. Oracle provides the Oracle Service Registry.

Figure 41-1 illustrates the integration of Oracle Service Bus with a UDDI registry.

Figure 41-1 Oracle Service Bus integration with UDDI

Description of Figure 41-1 follows
Description of "Figure 41-1 Oracle Service Bus integration with UDDI"

The Oracle Service Bus Web-based interface to Oracle Service Registry makes the registry accessible and easy to use. In working with UDDI, Oracle Service Bus promotes the reuse of standards-based Web services. In this way, Oracle 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.

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

  • 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

41.1.2 Benefits of Using a UDDI Registry with Oracle 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 run time, 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.

41.1.3 Introduction to UDDI Entities

UDDI uses a specific data model to represent entities that define organizations and services. Figure 41-2 shows the relationships between different UDDI entities.

Figure 41-2 UDDI Entities Representing Organizations and Services

Description of Figure 41-2 follows
Description of "Figure 41-2 UDDI Entities Representing Organizations and Services"

Table 41-1 provides a high-level overview of UDDI entities.

Table 41-1 High-Level Description of UDDI Entities

UDDI Entity Description

Business Entity

An organization or group of people who own and provide 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

Represents 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

Represents 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

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


For more information on the UDDI data model and entities used in UDDI, see "Publishing and Finding Web Services Using UDDI" in Oracle Fusion Middleware Programming Advanced Features of JAX-RPC Web Services for Oracle WebLogic Server.

41.2 Sample Business Scenarios for Oracle Service Bus and UDDI

The following are two sample business scenarios that highlight the benefit of using UDDI.

41.2.1 Basic Proxy Service Communication with a UDDI Registry

This scenario shows how you can use Oracle Service Bus to import services from a registry and then publish Oracle Service Bus proxy services back to the registry. See Figure 41-3.

Figure 41-3 Proxy Service Communication with a UDDI Registry

Description of Figure 41-3 follows
Description of "Figure 41-3 Proxy Service Communication with a UDDI Registry"

Oracle Service Bus imports business services from a UDDI registry. Proxy services are configured to communicate with the business services in the proxy service message flow. The proxy services can then be published back to the registry and made available for use by other domains.

41.2.2 Cross-Domain Deployment in Oracle Service Bus

This scenario shows cross-domain deployment using Oracle Service Bus. In this scenario, an Oracle Service Bus application in one domain requires access to an Oracle Service Bus service in another domain at run time. See Figure 41-4.

Figure 41-4 Sample Business Case of Cross-Domain Deployment

Description of Figure 41-4 follows
Description of "Figure 41-4 Sample Business Case of Cross-Domain Deployment"

An instance of Oracle Service Bus is deployed in each of two domains. The Oracle Service Bus proxy service (P1) is configured in domain (D1). The Oracle 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 Oracle Service Bus import and export feature does not support run-time 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 run time (for example, get a stock quote) and imported as a business service in another Oracle 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.

41.3 Using Oracle Service Bus and UDDI

Oracle Service Bus works with any UDDI registry that is compliant with the version 3.0 implementation of UDDI. Oracle Service Registry is a V3.0-compliant UDDI registry and is certified to work with Oracle Service Bus.

Using the Oracle Service Bus Administration Console or Eclipse, you can:

  • Configure Oracle 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, including the following service types: WSDL, messaging, any SOAP, and any XML.

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

For detailed procedural information, see:

41.3.1 A UDDI Workflow

The typical workflow for using a UDDI registry with Oracle Service Bus is as follows:

  • Install Oracle Enterprise Repository

  • Install Oracle Service Registry or any V3.0-compliant UDDI registry.

    Note:

    Oracle Enterprise Repository and Oracle Service Registry are not provided with Oracle Service Bus. In order to use those products, you have to buy a separate licence from Oracle.

    For more information on Oracle Enterprise Repository, see the Oracle Fusion Middleware documentation for Oracle Enterprise Repository.

  • In the Oracle Service Bus IDE, generate business services from service assets in Oracle Enterprise Repository, as described in Section 19.1.2, "Generating a Business Service from Oracle Enterprise Repository."

  • If you do not create a new UDDI Registry resource as part of generating a business service from Oracle Enterprise Repository, configure the service registry in the Oracle Service Bus Administration Console or in Eclipse. See:

  • Set a default registry in the Oracle Service Bus Administration Console. See Section 30.3, "Setting Up a Default UDDI Configuration."

41.4 Configuring a Registry

You can configure a UDDI registry, make it available in Oracle Service Bus, and then publish Oracle Service Bus proxy services to it or import business services from the registry to be used in a proxy service. You must be in an active session in the Oracle Service Bus Administration Console to configure the registry. For detailed information, see:

When publishing services to Oracle Service Registry, you need a valid user name and password for authentication to gain access to the registry. The user name and password combination is implemented as a service account resource in Oracle Service Bus. You must define service accounts before configuring proxy services. See Section 17.1, "Specifying Service Accounts."

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 Oracle Service Registry, administrators manage user privileges and create views into the registry, specific to the needs of different users. In Oracle Service Bus, user permissions govern access to the registries, their content, and available functionality.

41.5 Publishing a Proxy Service to a UDDI Registry

You can use the Oracle Service Bus Administration Console or IDE to publish proxy services to the Oracle Service Registry. To do this you must have a user account set up in Oracle Service Registry. You can publish any proxy service to a UDDI registry. The permitted service types and transports are listed in Table 41-2.

Table 41-2 Service Types and Transports for Proxy Services

Service Type Transports

WSDL

HTTP, JMS, Local, SB, WS

Transport Typed

JEJB

Any SOAP

HTTP, JMS, Local, SB

Any XML

E-mail, File, FTP, HTTP, JMS, Local, MQ, SB, SFTP, Tuxedo

Messaging

E-mail, File, FTP, HTTP, JMS, Local, MQ, SFTP, Tuxedo

Note: Messaging services can have different content for requests and responses, or can have no response at all (one-way messages). E-mail, File, SFTP, and FTP should be one-way.


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 (for example, the Business Service Console of Oracle Service Registry). 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 Oracle Service Bus Administration Console or Oracle Service Bus plug-ins for Eclipse. For more information on how to publish to a UDDI registry, see Section 30.7, "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 an Oracle 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).

Ensure that before you publish services to a UDDI registry from a clustered domain, none of the servers in the cluster use localhost in the server addresses. Instead, use either the machine name or the IP address.

41.5.1 Publishing Local Proxy Services to UDDI

You can publish local proxy services to UDDI so you can associate them with Oracle 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 WSDLs. Alternatively, you might have a generic proxy service in Enterprise Service Bus (ESB) 1 that dynamically routes to a generic proxy service in ESB 2 where the business service is attached. From the UDDI registry, you can get the WSDL of the local proxy service and the URL of the any SOAP or any XML generic proxy service. Combining the WSDL and URL creates an effective WSDL for sending messages to the local proxy service through the generic proxy service.

41.6 Using Auto-Publish

When you create a proxy service you can configure it to be published automatically to a default UDDI registry. You must first set up a default registry. See Section 30.3, "Setting Up a Default UDDI Configuration."

To enable the auto-publish feature for individual proxy services, you select the Publish To Registry check box on the Create a Proxy Service-General Configuration page. When you enable the Publish To Registry option, the proxy service is published to the default registry upon session activation. 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.

When you change the default registry, all the proxy services that have auto-publish enabled will be 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 Administration Console displays an unsynchronized icon.

Note:

When you have a default registry and you import a sbconfig.jar, which has a default registry set with the same logical name during the import, it is possible that the default registry will have an incorrect value for the business entity. You might now see 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.

41.7 Importing a Service from a Registry

You can import services from a UDDI registry as Oracle Service Bus business services. When importing a WSDL-based service, if multiple UDDI binding templates are encountered, Oracle Service Bus creates a different business service for each binding template.

To establish access to UDDI registries in Oracle Service Bus you must have Oracle Service Bus IntegrationAdmin or IntegrationDeployer privileges. See "Role-Based Access in the Oracle Service Bus Administration Console" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus. The registry entries are located on the System Administration, Import from UDDI page in the Oracle Service Bus Administration Console. When importing, you select from the list of available registries. To discover a service in a registry you must query a specific registry. Entries in registries are unique. The query is performed when you specify what registry you want to use for importing a service.

As a governance best-practice alternative to direct import from a UDDI registry, you can also generate business services from service assets stored in Oracle Enterprise Repository, which are in turn associated with services in Oracle Service Registry.

You can import the following business services types from a UDDI registry into Oracle 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 Oracle Service Bus services. These are Oracle Service Bus proxy services that are published to a UDDI registry. This feature is primarily used in multi-domain Oracle Service Bus deployments where proxy services from one domain need to discover and route to proxy services in another domain.

For information on importing services from a UDDI registry, see:

When a service is updated, you must re-import the service from the registry to get the most recent version, unless you have selected the Enable Auto Import option to auto-synchronize imported services with the UDDI registry. Any service that is imported with this option selected will be kept in synchrony with the UDDI registry. See Section 41.9, "Auto-Synchronization of Services With UDDI." If there is any failure during auto-synchronization, it will be reported on the Auto-Import Status page where you can update it manually.

Services have documents associated with them and these documents can include a number of other documents (schemas, policies, and so on). On import, the UDDI registry points to the document location based on the inquiry URL of the service. When a document that includes or references other resources is located, all of the referenced information and each included item is added as a separate resource in Oracle Service Bus.

Business Entity and pattern are the criteria used to search for a service in a registry. For example, you can enter foo%, when searching for a service. Services published by Oracle 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.

41.7.1 Related References

See the following related content:

41.8 Using Auto-Import

You can use the auto-import feature to synchronize the business services, which are imported from the Oracle Service Registry, with the corresponding services in the registry. See Section 30.5, "Using Auto-Import Status."

Note:

Auto-import is available only in the Oracle Service Bus Administration Console, not in the Oracle Service Bus plug-ins for Eclipse.

You can use the Auto Import Status page to do the following:

41.8.1 Synchronize

You can synchronize the services you have imported from the registry. If the services in the registry change, you can synchronize services in the Oracle Service Bus Administration Console with those in the registry. The following use case illustrates the process of synchronization. If the business service is not detached from the registry, Oracle Service Bus automatically subscribes to any changes to the service in the registry. If the service changes, an unsynchronized icon appears in the Resource Browser and Project Explorer indicating that the service needs to be synchronized. In addition, the Auto Import Status page shows this service and provides options for synchronizing the service or detaching it from the registry. Under certain circumstances, synchronizing the service might result in semantic validation errors that show up on the View Conflicts page. You will have to fix these errors before activating the session.

When a service is synchronized, the service is updated only with fields that are obtained from UDDI. Other fields in the service definition will preserve their values if modified since last import.

Consider a scenario where you publish services from Domain1 to a registry (see Figure 41-5). You then import these services from the registry into a domain, Domain2. 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 41-5 Sample Business Case of Cross-Domain Deployment

Description of Figure 41-5 follows
Description of "Figure 41-5 Sample Business Case of Cross-Domain Deployment"

41.8.2 Detach

Sometimes you do not want the service in the Oracle Service Bus Administration Console to be synchronized with the corresponding service in the registry. You can avoid synchronization by detaching the service from the registry. See Section 30.6, "Detaching Services."

41.9 Auto-Synchronization of Services With UDDI

You can keep the service definitions in Oracle 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 Oracle 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 Administration Console or the Oracle Service Bus plug-ins for Eclipse to prompt you for approval for synchronization when a service changes in the UDDI registry.

When configuring a registry, select the Enable Auto Import option to auto-synchronize imported services with the UDDI registry. Any service that is imported with this option enabled will be kept in synchrony with the UDDI registry automatically. If there is any failure during auto-synchronization, it is reported on the Auto-Import Status page where you can update it manually. See Section 30.2, "Configuring UDDI Registries."

41.10 Mapping Oracle Service Bus Proxy Services to UDDI Entities

Oracle 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 41-3 shows the service types, message types, and transports relevant to the UDDI registry mapping for an Oracle Service Bus proxy service.

Table 41-3 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)

E-mail, File, FTP, HTTP, JMS, Local, MQ, SB, SFTP, Tuxedo

Messaging

Binary, Text, MFL, XML (schema)

E-mail, 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). E-mail, 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 are:

  • 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 41-6 shows how WSDL-based services are mapped to UDDI business entities.

Figure 41-6 WSDL Service to UDDI Mapping

Description of Figure 41-6 follows
Description of "Figure 41-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 Oracle Service Bus proxy services as entities in the UDDI registry, you must provide additional canonical tModels to support some of the constructs specific to Oracle Service Bus. Not all attributes of an Oracle Service Bus proxy service are useful when searching for a service, for example, service type and transport details. These attributes do not categorize the service. tmodels are configuration details of the service once it has been discovered. These configuration details are mapped to the business service binding template tmodelinstanceDetails section. Other attributes specifically identify a service and can be used as the search criteria for the service. These attributes are mapped using keyed references to tModels with values in the categoryBag of the binding template.

An example of how Oracle Service Bus maps to UDDI is shown in Figure 41-7.

Figure 41-7 Oracle Service Bus to UDDI Mapping

Description of Figure 41-7 follows
Description of "Figure 41-7 Oracle Service Bus to UDDI Mapping"

41.10.1 UDDI Mapping Details for an Oracle Service Bus Proxy Service

Oracle Service Bus high-level proxy service information maps to the business service as follows:

  • Name and Description map to businessService elements.

  • There is a special keyedReferenceGroup for Oracle Service Bus properties. An example of a key is uddi:bea.com:attributes:oracleservicebus.

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

  • An Oracle Service Bus instance maps to a keyedReference in the Oracle Service Bus keyedReferenceGroup (Name = "OracleServiceBus", Values = URL of the Oracle Service Bus instance).

    This instance serves two purposes:

    • To indicate that this service is in fact hosted by an Oracle Service Bus server.

    • To contain the URL of the Oracle Service Bus instance.

Example 41-1 shows a mapping of high-level proxy service information to a business service.

Example 41-1 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 Oracle 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, which is a domain in Oracle Service Bus, contains a project named Proxy, which contains a folder named Accounting, which in turn contains a proxy service called PayoutProxy. When PayoutProxy is published to UDDI, its businessService is created with the following key:

uddi:bea.com:servicebus:AnonESB:Proxies:Accounting:PayoutProxy

Oracle 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, E-mail. New tModels are packaged with Oracle Service Bus to support JMS and File transports.

    • Detailed Oracle 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 Oracle Service Bus to support anySOAP, anyXML, and Messaging.

    • WSDL maps via WSDL to UDDI technology note.

    • Messaging has detailed configuration information that maps to InstanceParms.

Example 41-2 shows a detailed information mapping to the binding template.

Example 41-2 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://domain.com:7001
          /sbresource?SCHEMA%2FDJS%2FOAGProcessPO"/>
        <property name="RequestSchemaElement"
              value="PROCESS_PO"/>
        <property name="responseType" value="None"/></ALSBInstanceParms>
    </InstanceParms>
    </InstanceDetails>
  </tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>

41.10.2 Transport Attributes

Each of the transport types in the uddi:uddi.org:transport: * group has a different set of detailed metadata. See Table 41-3. 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. Example 41-3 provides an example of what must appear in the bindingTemplate tModelInstanceDetails.

Example 41-3 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 Oracle 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 41-4 is organized by transport type and lists the tModelKey and instanceParms used by each of the transports.

Table 41-4 Transport Attributes

Transport tModelKey InstanceParms

E-mailFoot 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 Cert (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 E-mail transport uses the standard mailto URL format: mailto:name@some_server.com. This is different from the one configured for the proxy service in Oracle Service Bus, which is a URL oriented toward reading e-mail. 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@some_server.com.

41.10.3 Service Type Attributes

Table 41-5 provides a high-level description of each of the service types.

Table 41-5 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 Oracle Service Bus (optional, if input message is XML)

  • URL of input message MFL in Oracle Service Bus (if input message is MFL)

  • Output message format (none, XML, Text, Binary, MFL)

  • URL of output message schema in Oracle Service Bus (optional, if output message is XML)

  • URL of output message MFL in Oracle Service Bus (if output message is MFL)


41.11 Canonical tModels Supporting Oracle Service Bus Services

The Oracle Service Bus-UDDI mapping provides a number of canonical tModels that are used to represent Oracle Service Bus metadata and relationships. These tModels must be registered in the UDDI registry to support this mapping. You can create these tModels in Oracle Service Registry under the administrator ID.

Table 41-6 through Table 41-9 provide a summary of the tModels.

Table 41-6 CategorizationGroup tModel Types

Name Description

bea-com:servicebus:properties

Describes very specific attributes of an Oracle Service Bus service. In the data model it is used in the business service categoryBag.


Table 41-7 Categorization tModel Types

Name Value Description

bea-com:servicebus:serviceType

WSDL, SOAP, XML, Messaging Service

Describes the service type of the Oracle Service Bus service.

bea-com:servicebus:instance

URL of Oracle Service Bus Administration Console

Describes the service instance in Oracle Service Bus responsible for publishing the service to UDDI.


Table 41-8 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 41-9 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 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 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.


41.12 Example

Example 41-4 is an example of the mapping for a Messaging Service, configured with JMS transport, the request being XML with a schema and the response being a text message.

Example 41-4 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://server.com:7001/weblogic.jms.XAConnectionFactory/
              ReqQueue
      </accessPoint> 
      <tModelInstanceDetails>
        <tModelInstanceInfo tModelKey="uddi:uddi.org:transport:jms">
          <instanceDetails>
            <instanceParms>
              <ALSBInstanceParms
                xmlns="http://www.bea.com/wli/sb/uddi">
                <property name="is-queue" value="true"/> 
                <property name="request-encoding" 
                  value="iso-8859-1"/> 
                <property name="response-encoding" 
                  value="utf-8"/> 
                <property name="response-required" 
                  value="true"/> 
                <property name="response-URI" 
                  value="jms://server.com:7001/
                  .jms.XAConnectionFactory/
                    RespQueue"/> 
                <property name="response-message-type" 
                  value="Text"/> 
                <property name="Scheme" value="jms"/> 
              </ALSBInstanceParms>
            </instanceParms> 
          </instanceDetails>
        </tModelInstanceInfo>
        <tModelInstanceInfo 
          tModelKey="uddi:bea.com:servicebus:
              protocol:messagingservice">
          <instanceDetails>
            <instanceParms>
              <ALSBInstanceParms xmlns=
                "http://www.bea.com/wli/sb/uddi">
                  <property name="requestType" value="XML"/> 
                  <property name="RequestSchema" 
                    value="http://server.com:7001/
                    sbresource?SCHEMA%2FDJS%2FOAGProcessPO"/> 
                <property name="RequestSchemaElement" 
                  value="PROCESS_PO_007"/> 
                <property name="responseType" value="Text"/> 
                </ALSBInstanceParms>
              </instanceParms> 
            </instanceDetails>
          </tModelInstanceInfo>
        </tModelInstanceDetails>
      </bindingTemplate>
    </bindingTemplates>
  <categoryBag>
  <keyedReferenceGroup tModelKey="uddi:bea.com:servicebus:properties">
    <keyedReference tModelKey="uddi:bea.com:servicebus:servicetype" 
          keyName="Service Type" 
          keyValue="Mixed" /> 
    <keyedReference tModelKey="uddi:bea.com:servicebus:instance" 
          keyName="Service Bus Instance" 
          keyValue="http://cyberfish.bea.com:7001" /> 
    </keyedReferenceGroup>
  </categoryBag>
</businessService>