Common registry requirements for the metadata are:

• Ownership and containment: I usually own the data I publish and all the subdata contained
• Categorization: Data can be classified in one or more categories, mainly to facilitate searching and organization
• Logical referencing mechanism: I can use references as pointers to other parts of the registry

• Authentication for the operations that change information and for public registries
• Open access for read and query operations

UDDI Data Structures
UDDI allows entities such as businesses and organizations to register public information about themselves and details of the services they offer. It also allows entities, such as businesses, standards bodies, and industry groups, to register information about the types of services that they've defined, about standards and abstractions, and to refer to them by their assigned identifiers.

Business entity information is conceptually divided into what's commonly known as White, Yellow, and Green Pages. White Pages contain general contact information about the entity. An entry would contain a business name, address, and contact information such as phone, fax, and e-mail. Yellow Pages contain classification information about the types and location of the services the entity offers. A fictitious SkatesTown company could be classified as a sports equipment manufacturer and retailer, and as a skateboard manufacturer and retailer. Green Pages contain information about how to invoke the offered services. If SkatesTown were to offer their catalog online, their Green Pages entry would have a reference to their catalog URL. It's important to note that this is a conceptual model only, and that UDDI doesn't specify any particular storage model for implementing relationships. Conceptually, however, an entity's White Pages entry will contain classification information that points to its place in the various Yellow Pages, and an entity's business service entries will contain implementation information that points to entries in the Green Pages.

This is reflected in the details of the UDDI data structures (see Figure 2). The root structure - businessEntity - is used to represent information about an entity or a business. It's also used as a container for business services and, indirectly, for the corresponding implementation and binding details of all the services that an entity provides. The businessService structure describes a logical business service, such as a stock quote service or a securities buying service.

Different implementation details and bindings for the same logical service, if offered, are grouped under the same businessService element as a collection of binding templates. In a certain sense, the bindingTemplate structure is the end goal of UDDI. Other structures allow us to get information about businesses, their descriptions, contact information, categorization and taxonomy information, and what kind of services they offer.

After a decision is made about using a particular service from a particular provider, however, the bindingTemplate subtree holds the necessary technical information for the service to be invoked. The same logical service can have more than one binding (e.g., SOAP-based, HTTP browser-based, and e-mail SMTP). Each of these bindings is described in its own bindingTemplate structure. This is generally a combination of access-point information and references to predefined technical models. Entries in the Green Pages, where invocation details are described, are actually business-specific binding details for service types and other abstractions defined elsewhere. These reusable abstractions are referred to as technical models and their corresponding UDDI data structure is the tModel. This structure allows industry groups, standards bodies, and individual businesses to specify reusable abstract definitions of service types that others can use and combine, creating in effect a signature for a service.

Let's look at the structure of these in a little more detail.

Business Entity

• Operator: The certified name of the Operator that owns the UDDI node to which the entity is registered.
• Authorized name: The name of the business entity provided by the Operator.
• Discovery URLs: Optional URLs that provide alternate means for discovering the services; for example, businesses may provide a Web site to their services or use a convention such as the eCo Framework (www.oasis-open.org/cover/ecoFramework.html) service description convention.
• Contacts: Optional contact information for the entity; contact information can specify categories such as technical support and marketing.

• Name: Name of the service, as provided by the business

• Access point: The network address of the service to be invoked; the type of address is specified through a URL type. The allowed URL types are mailto, http, https, ftp, fax, phone, and other.
• Hosting redirector: Typically used instead of an access point in cases where an entity is exposing a service hosted by another entity, such as an ASP. In addition to the information described above, UDDI data structures have a number of common properties:
• Descriptions: Human-readable, multilanguage descriptions of the structure.
• Keys: Unique identifiers assigned by UDDI upon initial registration of a new piece of data; in addition, according to the UDDI containment scheme, each instance of a contained structure (businessService and bindingTemplate) holds a key reference to its containing entity (in this case, businessEntity and businessService, respectively) in a strict parent-child relationship. These identifiers are Universal Unique Identifiers (UUIDs) that follow the OSF Distributed Computing Environment (DCE) conventions. They follow the familiar 8-4-4-4-12 pattern (e.g., F775A3A6-FF3E-4B85-B1DE-F0F99D0E2C6D). In addition, tModel references are given the "uuid:" URN qualifier to their keys.
• Classification and categorization information: Collections of pointers that organize the UDDI data structures into a semantic network for convenient search and traversal; these are stored in the identifierBag and categoryBag parts of the UDDI data structure and they all point to tModels (see Figure 2). More on this later.

UDDI APIs
In addition to defining the data structures to be stored in the registry, the UDDI specification provides two main types of API operations, Publication and Inquiry. In version 1.0 these APIs defined a set of 20 SOAP messages over HTTP or HTTPS that has to be understood by any UDDI conformant registry. (Version 2.0 APIs will be discussed in a later column.) The SOAP body of the API messages and responses are XML structures defined in the UDDI specification.

The Publication API is an authenticated set of operations that allows organizations to publish information, whether business, service, implementation, or service-type specification, to the UDDI registry. Aside from requiring an authentication token and the use of the HTTPS protocol in the authenticated operations, UDDI does not specify an authentication method. Each Operator must provide a mechanism. The Inquiry API is a nonauthenticated public set of operations that allows users to extract information out of the UDDI registry. Inquiries can follow two different patterns: a browsing pattern to find general information (the find operations) usually followed by a drilldown pattern to find specific detail information (the get_Detail operations).

Corresponding to the four structure types (businessEntity, businessService, bindingTemplate, and tModel), UDDI provides four save operations (save_business, save_service, save_binding, and save_tModel), four delete operations (delete_business, delete_service, delete_binding, and delete_tModel), four find operations (find_business, find_service, find_binding, and find_tModel) and four get_Detail operations (get_businessDetail, get_serviceDetail, get_bindingDetail, and get_tModelDetail) as shown in Table 1.

The save operations can be used to create a new entry or to update an existing one. To create a new entry, the entry identification key parameter is not supplied in the call, but is assigned by the Operator and returned in the Operator's response. To update an existing entry this Operator-assigned key is supplied in the call. The delete operations take the Operator-assigned keys as parameters and remove the corresponding entries from the registry.

The find operations are passed a set of search criteria and generally return a (possibly empty) list structure containing information about entries that match the search criteria. The get_detail operations are passed a list of identifiers and return detailed information about the entries referred to by the supplied keys. The API provides one additional get_detail operation, get_businessDetailExt, to allow the retrieval of extended business information from non-Operator nodes that implement these extensions. In addition, since the Publication API is a set of authenticated operations, where authentication is token-based, the API provides two authentication operations, get_authToken and discard_authToken. Finally, the getRegisteredInfo is an authenticated operation that returns all the businessEntity and tModel keys registered by an accredited user.

Note that it's possible to perform most of the Publication and Inquiry API functions (some find and get_Details operations) through the individual Operator's Web sites. In addition to being more complete and powerful than what's available through browsers, the API is intended to allow businesses to perform all the operations programmatically to facilitate dynamic (runtime) service discovery.

Authentication
As we've seen, all Publication API operations need to be authenticated. Privacy, security, and authentication are crucial for the UDDI Operators to build a trusted relationship with UDDI users. However, since there is not one clearly universal and widely accepted standard for authentication, various Operators have different authentication policies. Because of this, the UDDI authentication mechanism involves getting an opaque authentication token by means specified by the UDDI Operator, using it in the authInfo attribute, then, optionally, discarding it. In addition, all Publication API messages are SSL encrypted. UDDI Operator nodes can list their own specific mechanism for getting a token. In case no Operator-specific mechanism is provided, Operators are required to implement the get_authToken API. Authentication in this case is performed by first getting an opaque authentication token from the UDDI registry through the get_authToken call, supplying that token in the authInfo element in the subsequent calls, and finally discarding the token through the discard_authToken call.

Before being allowed to publish information to an Operator node, a prospective user will need to establish some credentials through an initial preregistration step, which is Operator-dependent. As a result of this initial step, each registering entity is either issued an authentication token (e.g., a certificate) or a user ID and password.

To establish appropriate security context to access a registry, a preregistered user has to issue the following message over SOAP to a UDDI Operator:

<get_authToken generic="1.0" xmlns="urn:uddi-org:api"
userID="{userID assigned by Operator}"
cred="{password chosen at registration}"/>

The result of the get_authToken operation is an authToken structure identifying the Operator and providing a token, usually in the form of a UUID, for example,

<authToken generic="1.0"
xmlns="urn:uddi-org:api"
operator="UDDIOperator">
<authInfo>5BA16322-B5ED-4300-8F2F-420DA3A212D2</authInfo>
</authToken>

All authenticated operations must include the authInfo element as part of their message over SOAP. For example, a save_business operation for the SkatesTown company might look something like Listing 1.

Finally, the discard_authToken operation is used to inform the token issuer that the token is no longer valid and can be discarded. Subsequent Publishing API calls using the same token should be rejected. The token received in the get_authToken operation is passed as a parameter.

<discard_authToken generic="1.0"
xmlns="urn:uddi-org:api">
<authInfo>5BA16322-B5ED-4300-8F2F-420DA3A212D2</authInfo>
</discard_authToken>

This has been a whirlwind introduction to the core data structures and APIs of UDDI. The next XML in Transit will look in detail at the magic of tModels and the mechanisms for classification and categorization in UDDI. This is where the true power of service registries lies.