User Guide

UDDI

 

---

Overview of BEA AquaLogic Service Bus and UDDI

Universal Description, Discovery and Integration (UDDI) registries are used in an enterprise to share Web services. Using UDDI services helps companies organize and catalog these Web services for sharing and reuse in the enterprise or with trusted external partners.

A UDDI registry service for Web services is defined by the UDDI specification available at:

http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3

This specification is a standard on which UDDI registries are based and provides the details on how to publish and locate information about Web services using UDDI. The specification does not define run-time aspects of the services (it is only a directory of the services). UDDI provides a framework in which to classify your business, its services, and the technical details about the services you want to expose.

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

Figure 8-1 AquaLogic Service Bus integration with UDDI

 

AquaLogic Service Bus' Web-based interface to AquaLogic Service Registry makes the registry accessible and easy to use. In working with UDDI, AquaLogic Service Bus promotes the reuse of standards based Web services. In this way, AquaLogic Service Bus registry entries can be searched for and discovered and used by a wider audience. 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.

Basic Concepts of the UDDI Specification

UDDI is based upon several established industry standards, including HTTP, XML, XML Schema (XSD), SOAP, and WSDL. The latest version of the UDDI specification is available at:

http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3

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

Benefits of Using a UDDI Registry with AquaLogic Service Bus

A UDDI registry stores data and metadata about business services. It is a standards-based library of catalogued and managed information about Web services for discovery and reuse by other applications. UDDI offers several benefits to IT managers at both design time and run time, including increasing code reuse. It also provides benefits to developers, including the following:

• Improves infrastructure management by publishing information about proxy services to the registry and categorizes the services for discovery. Thus growing a portfolio of services making it easier to understand and manage relationships among services, component versioning, and dependencies.
• Services can be imported from a registry to configure the parameters required to invoke the Web service and the necessary transport and security protocols.
• 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 decreasing the development lifecycle and improves productivity. It also increases the prospect of interoperability between business applications by sharing standards-based resources.
• Provides a user friendly interface for searching and discovering Web services. You can search on user specified criteria.

Introduction to UDDI Entities

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

Figure 8-2 UDDI Entities Representing Organizations and Services

 

A high-level overview of the UDDI entities is provided.

Table 8-1 High-Level Description of UDDI Entities

Business Entity	An organization or group of people that own and provide the services.It can be described by a set of names, descriptions, contact details for the service provider, a set of categories that represent the business entity's features, unique identifiers, discovery URLs.
Business Service	A business service represents functionality or resources provided by business entities. It is described by a name, a description, and a set of categories that represent the function of the service. It is not necessarily a Web service.
Binding Template	A binding template represents the technical details of how to invoke a business service. A business service can contain one or more binding templates. It is described by an Access Point representing the service endpoint (the endpoint URI and protocol specification), tModel instance information, and categories to reference specific features of the binding template
tModel	This is the technical model describing how services must be represented in the UDDI registry.It is described by name, description, an overview document (a reference to a document specifying the purpose of the tModel), categories, and identifiers (to uniquely identify the tModel).

 

For more information on the UDDI data model and entities used in UDDI, see Introduction to BEA AquaLogic Service Registry in BEA AquaLogic Service Registry 2.0 User's Guide.

Prerequisites

Before using AquaLogic Service Bus with a UDDI registry you must perform the following tasks:

• AquaLogic Service Registry must be installed and running. For information on how to install BEA AquaLogic Service registry 2.0, see Installation, in BEA AquaLogic Service Registry 2.0 Installation Guide.
• AquaLogic Service Bus must be installed and running. For information on how to install BEA AquaLogic Service Bus 2.1, see Preparing for your installation, in BEA AquaLogic Installation Guide.

Certification

AquaLogic Service Bus works with any UDDI registry that is fully compliant with the version 3 implementation of UDDI (Universal Description, Discovery and Integration).

AquaLogic Service Registry 2.0 is a version 3 UDDI-compliant registry and is certified to work with AquaLogic Service Bus.

Features

The AquaLogic Service Bus Console provides you with access to any version 3 compliant UDDI registry once it has been set up to work with AquaLogic Service Bus. The following features are available:

• Configure AquaLogic Service Bus to work with one or more version 3 UDDI compliant registries.
• The import feature allows you to search for specific services in a registry or list all services available. You can search on business entity, service name pattern, or both, and then make your selection from the results list.
• Import selected business services from a registry.
• Publish selected AquaLogic Service Bus proxy services to the registry.

For more information on how to configure and search the registry, import business services to AquaLogic Service Bus, and how to publish proxy services to a UDDI registry, see the following topics in System Administration in Using the AquaLogic Service Bus Console:

• Configuring a UDDI Registry
• Importing a Business Service from UDDI Registry
• Publishing a Proxy Service to a UDDI Registry

What is the BEA AquaLogic Service Registry?

BEA AquaLogic Service Registry is a fully version 3 compliant implementation of UDDI and is a key component of a Service Oriented Architecture (SOA).

Note: AquaLogic Service Registry is not provided with AquaLogic Service Bus.It is licensed independently from Systinet and BEA.

A UDDI registry provides a standards-based foundation infrastructure for locating services, invoking services, and managing metadata about services (security, transport or quality of service). Using the Registry Console you can browse and publish registry content. The Registry Console is the primary console for administrators to perform registry management. You can launch the ALSR console in a Web browser by opening the following URL: http://hostname:port/uddi/web, where Host name and port are defined when AquaLogic Service Registry is installed. The default port is 8080. For more information on the management of AquaLogic Service Registry, particularly configuring the registry and managing permissions, approval, and replication, see the BEA AquaLogic Service Registry Administrator's Guide.

Sample Business Scenario for AquaLogic Service Bus and UDDI

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

Basic Proxy Service Communication with a UDDI Registry

This scenario describes how you can use AquaLogic Service Bus to import services form a registry and then publish the services back to a registry as part of an AquaLogic Service Bus proxy service.

AquaLogic Service Bus imports business services from a UDDI registry. Proxy services are configured to communicate with the business services in the Message Flow. The proxy services themselves can be published back to the registry and made available for use by others.

Figure 8-3 Proxy Service Communication with a UDDI Registry

 

Cross-Domain Deployment in AquaLogic Service Bus

This scenario describes cross-domain deployment using AquaLogic Service Bus. An AquaLogic Service Bus application in one domain wants to invoke another AquaLogic Service Bus service in another domain at run time.

An instance of AquaLogic Service Bus is deployed in each of two domains. The AquaLogic Service Bus Proxy service (P1) is configured in domain (D1). The AquaLogic Service Bus Proxy service (P2) in domain (D2) wants to access proxy service (P1). As the domains can not communicate directly with each other, P2 in D2 can not discover P1 in D1. The AquaLogic Service Bus import/export feature does not support run-time discovery of services in different domains, but publishing the service to a publicly available UDDI registry allows for the discovery of the service in any domain. Once P1 is made available in the UDDI registry it can be invoked at run time (for example, get a stock quote) and imported as a business services in another AquaLogic Service Bus proxy service.

When importing and exporting from different domains you must have network connectivity. A proxy service might reference schemas located in the repository of a different domain, in which case it needs HTTP access to the domain to import using the URL. In the absence of connectivity an error message will be returned.

Figure 8-4 Sample Business Case of Cross Domain Deployment

 

 

---

Using AquaLogic Service Bus and UDDI

You can use the AquaLogic Service Bus Console to

• Publish information about any proxy service to a registry, including the following service types: WSDL, messaging, any SOAP, and any XML.
• Search a registry for information about a service and discover the service.
• Configure a registry to allow users to publish services and import services.
• Import Web services and integrate them with your application.

Typical Workflow

Figure 8-5 shows the typical workflow for using UDDI with AquaLogic Service Bus.

Figure 8-5 Typical Workflow

 

 

---

Configuring a Registry

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

The following table describes the configuration properties for a UDDI registry. Every registry has a set of properties that must be configured. When configuring a UDDI registry, the Inquiry URL is required. The Service account is also required to permit access to the registry when publishing a service.When specifying the configuration settings, the following cases are worth noting:

• To do an anonymous read only of the registry, you need to specify only an Inquiry URL and nothing else.
• To publish with authentication, you must specify the Inquiry URL, the Publish URL, Security URL, and the Service Account.
• To do an Inquiry and get a specific view of the contents of the registry, you must specify the Inquiry URL, the Security URL, and a service account.

Table 8-2 UDDI Registry Configuration Settings

Name*	This is the name of the registry. The name was assigned to it when it was first published.Select the registry name to edit the details for the registry. You can edit the Inquiry URL, Publish URL, Security URL, and the Service Account, but not the name of the registry.
Inquiry URL*	This is the URL used to locate and import a service. The Inquiry URL is required. To read from a registry, you only need to specify a name and Inquire URL.
Publish URL*	This is the URL used to publish a service. When publishing a service you must also specify a security URL and specify the service account associated with the registry.
Security URL	This URL is used to get an authentication token so that you can publish to the registry. You must specify a publish URL and a security URL if you have a service account defined.
Service Account	A service account is required for publishing services to a registry. This account grants access to the registry using a username and password. A registry can have a single service account associated with it.When using a service account, you must also specify a security URL.
Options	Delete is the only option defined for the registry.


 

When publishing services to AquaLogic Service Registry, to gain access to the registry, you must be authenticated and have a valid username and password. The username and password is implemented in AquaLogic Service Bus as a service account resource (using credentials). Service accounts must be defined before configuring proxy services so that the authentication criteria is set up to work with a service during the configuration of the proxy service. To create a service account in AquaLogic Service Bus, see "Adding a Service Account" in Service Accounts in Using the AquaLogic Service Bus Console.

You can set up registries with multiple username and passwords allowing different users to have different permissions based on the service account. Permissions in AquaLogic Service Registry were developed so that administrators can manage users' rights in BEA AquaLogic Service Registry and create views into the registry, specific to the needs of the different user types. User permissions set in AquaLogic Service Bus govern access to the registries, their content, and the functionality available to you.

 

---

Publishing a Proxy Service to a UDDI Registry

You can use the AquaLogic Service Bus Console to publish proxy services to AquaLogic Service Registry You must have an account set up in AquaLogic Service Registry to do this. You can publish any proxy service to a UDDI registry. The service types and transports are listed in Table 8-3.

Table 8-3 Service Types and Transports for a Proxy Service

Service Type	Transports
WSDL	HTTP(S), JMS
Any SOAP	HTTP(S), JMS
Any XML	HTTP(S), JMS, Email, File, FTP
Messaging	HTTP(S), JMS, Email, File, FTP
Note: Messaging services can have different content for requests and responses, or can have no response at all (one-way messages). Email, File, and FTP must 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 (the Business Service Console in the case of AquaLogic Service Registry). The first time you publish to a registry you must load the tModels to that registry. This is done at the same time you configure the publishing details in the AquaLogic Service Bus Console. For more information on how to publish to a UDDI registry, see "Publishing a Proxy Service to a UDDI Registry" in System Administration in Using the AquaLogic Service Bus Console.

AquaLogic Service Bus works with any UDDI version 3 registry. Generally in a large organization the systems administrator is responsible for creating and setting up the registries. The service account must be set up before a service (proxy service in AquaLogic Service Bus) can be published as a business entity to the registry.

 

---

Importing a Service from a Registry

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

Access to registries in AquaLogic Service Bus is established by someone who has AquaLogic Service Bus system administration privileges for the UDDI registries. The registry entries automatically appear in the Import page of the AquaLogic Service Bus Console. When importing, you make a selection from the list of available registries. To discover a service in a registry you must query a specific registry. Entries in registries are unique. This query is performed when you specify what registry you want to use for importing a service.

You can import the following business services types from a UDDI registry into AquaLogic Service Bus:

• WSDL over HTTP binding.When multiple UDDI binding templates are encountered, a business service is create for each binding template.
• SOAP or XML binding over HTTP, or XML.
• Services that are categorized as AquaLogic Service Bus services. These are AquaLogic Service Bus proxy services that are published to a UDDI registry. This feature is primarily used in multi-domain AquaLogic Service Bus deployments where proxy services from one domain need to discover and route to proxy services in another domain.

For information on how to use the AquaLogic Service Bus Console to import services from a UDDI registry, see "Importing a Business Service from a UDDI Registry" in System Administration in Using the AquaLogic Service Bus Console.

When a service is updated, you must re-import the service from the registry to get the most up to date version.

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

Business Entity and pattern are the criteria used to search for a service in a registry. For example, you can enter foo%, when searching for a service. Services published by AquaLogic Service Bus have specific tmodel keys identifying the service that are used when searching for the service in the registry.

Import automatically tries to connect to a registry as you are attempting to get the list of business entities from the registry. The Business Entity is the highest level of organization in the registry, though you can use other search criteria, such as business, application type, and so on. If you require authentication, then you need a username and password which you must get from your systems Administrator.

Related References

• Technical Notes can be found at http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm. One of the most important Technical Notes is Using WSDL in a UDDI Registry.
• UDDI product and development tool information is available at the OASIS UDDI Solutions page at http://uddi.org/solutions.html.
• The UDDI specifications can be found at 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 schemata 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

 

---

Mapping AquaLogic Service Bus Proxy Services to UDDI Entities

AquaLogic Service Bus proxy service attributes must be mapped to the data model supported by the UDDI registry to allow a proxy service to be published as a UDDI business entity. The following table shows the service types, message types, and transports relevant to the UDDI registry mapping for an AquaLogic Service Bus proxy service.

Table 8-4 Proxy Service Attributes and Service Types

Service Type	Message Content Type	Transports
WSDL	SOAP or XML (with attachment)	HTTP(S), JMS
Any SOAP	Untyped SOAP (with attachment)	HTTP(S), JMS
Any XML	Untyped XML (with attachment)	HTTP(S), JMS, Email, File, FTP
Messaging	Binary, Text, MFL, XML (schema)	HTTP(S), JMS, Email, File, FTP
Note: Optional parts are listed in parenthesis. Messaging services can have different content for requests and responses, or can have no response at all (one-way messages). Email, File, and FTP must 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—this represents the service as a whole and contains high-level general information about the service.
• bindingTemplate—this contains information for accessing the service.
• tModels—tModels are used to supply the individual attributes for categorizing and defining the service.

Figure 8-6 shows how WSDL-based services are mapped to UDDI business entities.

Figure 8-6 WSDL Service to UDDI Mapping

 

The technical note Using WSDL in a UDDI registry, version 2.0.2, at http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm, is used as the basis for publishing WSDL-based proxy services to the UDDI registry. This document is also used as a reference point for publishing non WSDL-based services. The document and the base UDDI specification describe the canonical technical models (tModels) used to describe UDDI entities. To publish AquaLogic Service Bus proxy services as entities in the UDDI registry, you must add additional canonical tModels to support some of the AquaLogic Service Bus specific constructs. Not all attributes of an AquaLogic Service Bus proxy service are useful when searching for a service, such as service type and transport details. These attributes do not categorize the service, they are useful things to know about a service and 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 category bag of the binding template.

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

Figure 8-7 AquaLogic Service Bus to UDDI Mapping

 

UDDI Mapping Details for an AquaLogic Service Bus Proxy Service

AquaLogic Service Bus high-level proxy service information maps into the Business Service as follows:

• Name and Description map to businessService elements.
• There is a Special keyed Reference Group for AquaLogic Service Bus properties. An example of a key is uddi:bea.com:attributes:aqualogicservicebus.
• AquaLogic Service Bus type (WSDL, SOAP, XML, and Mixed) and Instance are mapped to keyedReferences in the service category bag. An example of a key is uddi:bea.com:servicetype.
• An AquaLogic Service Bus Instance maps to a keyedReference in the AquaLogic Service Bus keyedReferenceGroup (Name = "AquaLogicServiceBus", Values = URL of the AquaLogic Service Bus instance). This instance serves two purposes:
• As a maker to indicate that this service is in fact hosted by an AquaLogic Service Bus server.
• To contain the URL of the AquaLogic Service Bus instance.

Listing 8-1 shows a mapping of high-level proxy service information to a business service.

Listing 8-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 AquaLogic 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, an AquaLogic Service Bus domain, AnonESB, contains a project Proxies, 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.

AquaLogic 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 AquaLogic Service Bus to support JMS and file transports.
• Detailed AquaLogic Service Bus configuration information maps to instanceParms.
• The Market tModel for each service type maps to the tModelInstanceDetails.This includes the following:
• Protocol tModels for WSDL, any SOAP, any XML, Messaging. New tModels are packaged with AquaLogic 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.

Listing 8-2 shows a detailed information mapping to the binding template.

Listing 8-2 Sample Detailed Mapping to the Binding Template

<bindingTemplate bindingKey="uddi:" serviceKey="uddi:">
  <accessPointuseType="endPoint">file:///c:/temp/in3</accessPoint>
  <tModleInstanceDetails>
    <tModleInstanceInfo 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>
    <tModleInstanceInfo 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>

Transport Attributes

Each of the transport types in the uddi:uddi.org:transport:* group has a different set of detailed metadata. (See Table 8-4.) This metadata provides configuration details of the transport for the proxy service. It is not 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.

For example, if you are mapping a proxy service that uses the HTTP transport, and as part of the HTTP configuration you need to describe some detailed configuration details, including the required client authorization and the request and response character encoding, the following listing provides an example of what must appear in the bindingTemplate tModelInstanceDetails.

Listing 8-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="basic-auth-required" value="true"/>
          <property name="request-encoding" value="iso-8859-1"/>
          <property name="response-encoding" value="utf-8"/>
          <property name="Scheme" value="http"/> 
        </ALSBInstanceParms>
      </instanceParms> 
    </instanceDetails>
  </tModelInstanceInfo>
</tModelInstanceDetails>

Note: For each transport, the service endpoint is always stored in the bindingTemplate's accessPoint field.

Table 8-5 is organized by transport type and lists the tModelKey and InstanceParms used by each of the transports.

Table 8-5 Transport Attributes

Transport	tModelKey	InstanceParms
HTTP	uddi:uddi.org:transport:http	Client Authentication [None, Basic, Client Cert (HTTPS only)] Request encoding Response encoding
JMS	uddi:uddi.org:transport:jms	Destination Type [Queue, Topic] Response required, Response URI Response Message Type [Bytes, Text] Request encoding Response 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
Email1	uddi:uddi.org:transport:smtp	Attachment supported [Boolean] Request Encoding

1. The accessPoint in the Binding Template for an Email Transport uses the standard mailto URL format: mailto:name@some_server.com This is different than the one configured for the proxy service in AquaLogic 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@some_server.com.

 

Service Type Attributes

Table 8-6 provides a high-level description of each of the service types.

Table 8-6 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, which is available at the following 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's tModelInstanceDetails, as well as in the categoryBag, defines the Any Soap attributes.
Any XML	A simple marker protocol tModel in the bindingTemplate's tModelInstanceDetails, as well as in the categoryBag defines the Any XML attributes. This is a new detailed tModel.
Messaging Services	A simple marker protocol tModel in the bindingTemplate's tModelInstanceDetails, defines the messaging services attributes. This is a new detailed tModel.Unlike the other service types, messaging services have additional configuration information associated with them, which provide details about the request and response messages. The configuration details are represented as XML data in the InstanceParms data for the following tModel reference in the tModelInstanceInfo: Input message format (XML, Text, Binary, MFL) URL of input message Schema in AquaLogic Service Bus (optional, if input message is XML) URL of input message MFL in AquaLogic Service Bus (if input message is MFL) Output message format (none, XML, Text, Binary, MFL) URL of output message Schema in AquaLogic Service Bus (optional, if output message is XML) URL of output message MFL in AquaLogic Service Bus (if output message is MFL)

 

 

---

Canonical tModels Supporting AquaLogic Service Bus Services

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

The following table provides a summary of the new tModels.

Table 8-7 AquaLogic Service Bus tModels

Name	Value	Description
CategorizationGroup tModel Types
bea-com:servicebus:properties		Used to describe very specific attributes of an AquaLogic Service Bus service. In the data model it is used in the business service category bag.
Categorization tModel Types
bea-com:servicebus:serviceType	WSDL, SOAP, XML, Messaging Service	Describes the service type of the AquaLogic Service Bus service.
bea-com:servicebus:instance	URL of AquaLogic Service Bus Console	Describes the service instance in AquaLogic Service Bus responsible for publishing the service to UDDI.
Transport tModel Types
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		Describe 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.
Protocol tModel Types
bea-com:servicebus:anySoap		Used to describe the type of protocol used to access the service. It designates services having 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		Used to describe 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		Used to describe 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 messge can be any of the above or none. The message body content is determined dynamically by the application.

 

 

---

Example

The following is an example of the mapping for a Messaging Service, running over JMS with the request being XML with a Schema and the response being a text message.

Listing 8-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" 
                  ="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>