UDDI Registry

a CENTRAL PLACE is needed where the Service Provider can advertise the
services it offers and the Service Consumers can find the service they require.

Such a central place is called a SERVICE REGISTRY.

A common analogy for a Service Registry is the Library Card Catalog. This
catalog is used to enter information about new books as they arrive in the
library and to look up the location of a book when it is needed.

Another analogy is the Telephone Directory, where service providers

advertise their services in Yellow and White Pages and the consumers use the
directory to find the services they need.

The Universal Description, Discovery, and Integration (UDDI) specification

defines a standard way for registering, unregistering, and looking up Web
Services.
 UDDI Registry
 Figure 7.8 shows how UDDI enables the Dynamic Description,
Discovery, and Integration of services.

 A Service Provider first registers a service with the UDDI registry.

A Service Consumer looks up the required service in the UDDI registry.

When it finds the required service, the Consumer Directly Binds with
the Provider to use the service.
Three categories of information are stored in the UDDI registry.
General business and organization information
This includes Name, Description, Address, and so forth. Similar to the White
Pages

Descriptions of businesses according to standard taxonomies

This could be according to the types of services they offer or geographical
location. Similar to the Yellow Pages

Lists of services, binding, and service-specific technical information

This category could be compared to the Green Pages of the telephone book.
UDDI also defines an XML schema for SOAP messages and two APIs for
applications needing to use the registry.

Inquiry API Used to look up and browse the service registry

Publishers API Used to register services with the registry

 Overview and Basic Data Model
The role of the UDDI registry in Web Services is Similar to the role played
by a Search Engine on the Internet.

a fine-grained search for a Web Service is possible only if Service is

Classified Properly (the search engine uses the Keywords defined for a
page)

The Classification and Identification Taxonomies present in the UDDI

registry provide a starting point for describing Web Services.

Equally important is to classify the businesses or organizations that offer

Web Services

tModel - a structure that describes

a service's technical interface
a taxonomy (or namespace) that specifies the categorization or identification
scheme.
UDDI Data Model
 UDDI Data Model
consists of a hierarchy of five basic data types, defined through XML schemas.
businessEntity This data type contains information on a business or
organization, such as the name, address, and a contact phone number of the
business/organization. This data type is at the top of the data model hierarchy.

businessService This data type represents the aggregation of services

belonging to a specific category offered by a service provider (businessEntity may
offer several types or collections of Web Services ).
The businessService data type provides overall Web Service—level information, such
as the name of a service aggregate, a description, or a service categorization.
businessEntity serves as the container of business Services

bindingTemplate This data type exposes the service end point address
required for accessing a distinct Web Service. It may also be used to describe
technical characteristics of a service implementation or to refer to remotely
hosted services
businessService is a container of many bindingTemplates
 UDDI Data Model

tModel technical model.

This data type is used to expose Web Services interface information.
Indicate that a Web Service complies with a certain specification.
Provides a technical specification for a fingerprint that helps the
client determine whether the technical capabilities of the service
meets its requirement.
Represents a value system to identify and categorize information
entities

publisherAssertion
complements the information contained in the businessEntity data
type
useful for very large organizations that have many subsidiaries and
may not be adequately represented by the businessEntity data type.
Describes the relationships between business entities
 tModel
The tModel fulfills two important goals of the UDDI
registry.
Technical fingerprint of a service
The first goal is to provide a facility to describe Web Services
well enough that a consumer of a service can interact with
the service in a well-defined manner

Define a namespace or taxonomy

provide a means to describe Web Services well enough that
the description is useful during searches.
 Technical Fingerprint Role
The specification of how a consumer interacts with
a Service is stored in the tModel (wire protocol and
interchange formats, such as SOAP over HTTP).

A common use of the technical fingerprint involves

referring to a Web Service WSDL

The tModel only Stores Metadata (where WSDL

file is) and not the actual data.
Once tModel added to the UDDI, others can refer to it using the
tModelKey
Structure of a tModel
Structure of a tModel
Categorization and Identification Schemes
UDDI registry is used for finding
 business
service information.

Clients can find out who is offering a service as well as provides them important criteria
for deciding whether or not to use the service.

The identifierBag is a containment structure that UDDI provides for the introduction of
identification systems and related identifications

Identification systems
Thomas Register (supplies unique provider identification digits)
 Data universal Numbering System (DUNS)
nine-digit identification sequences providing unique identifiers for single business entities.
 Global Location Numbers (GLNs).
are unique 13-digit identification sequences identifying physical, legal, or functional locations within a business,

These numbers are maintained by the EAN International Association.

(European Article Number)
Structure of an identifierBag
 The identifierBag can be optional in a businessEntity and in a
tModel.

 Identifies a business, helps to search a UDDI directory according to

a distinct category.

 The search could be based on distinct categories, such as the

category, the industry it belongs to, the region in which a service
provider operates, or the technical requirements for invoking a
service.
 categoryBag
categoryBag is a container of information on categories. The structure of
categoryBag is similar to identifierBag

References to tModels identifying the actual classification system, along with

keyNames and keyValues.

The information in the categoryBag helps a consumer decide whether the

service or the service provider belongs to the right category.

A category can occur inside a businessEntity, businessService, or tModel.

UDDI explicitly mentioned the following categories:

North American Industry Classification System (NAICS)
Universal Standard Product and Services Classification (UNSPSC) system.
UDDI also has a number of built-in taxonomies, including a taxonomy named
keyName: uddi-org:types
keyValue are wsdlSpec, soapSpec, and xmlSpec.
 Binding Template
A binding template contains
information on the Service End Point
Through accessPoint or hostingRedirector (mutually exclusive)
A direct child of the bindingTemplate element
The accessPoint used to specify the service end point information
directly into the bindingTemplate itself.
Attribute URL type (e.g. http) and value content of the accessPoint
element represents the URL
hostingRedirector indicates that the binding template points to
another bindingTemplate, which ultimately provides the service end
point information
hostingRedirector is useful when more than one service description
can benefit from one bindingTemplate

Refers to the technical information about a Web Service.

Binding Template
 Binding Template
• The attribute bindingKey maintains the UUID value
of the target bindingTemplate.

• The top element in this hierarchy is

tModelinstanceDetails, which is a container
element.

• The most important information carried by this

substructure is information about the wire
protocol and data exchange formats and links to
the tModels associated with the binding template.
 Use of WSDL in the UDDI Registry
A WSDL document consists of a service interface part and a service
implementation part.

bindingTemplate and tModels also provide the same information.

it may be possible that the bindingTemplate and tModels can delegate this
information to a WSDL document.

this is possible when the WSDL document is partitioned in a particular way.

group the portType and binding elements in one file (say, WSDL interface and
binding file)

 The service element containing the port elements is grouped in another

file (say, the WSDL implementation file).

The implementation file imports the WSDL interface and binding file.
 The location attribute of the import element carries the physical location of the imported
 interface and binding file.
 The namespace prefix "imported" refers to the target namespace of the elements contained
 in the interface and the binding file named weatherServiceInterface.wsdl.
For tModel, refer to the WSDL interface and binding file

For the bindingTemplate, refer to the WSDL implementation file.

For tModel, a uddi-org:types taxonomy value of wsdlSpec classifies the tModel to refer
to the WSDL interface and binding document.

This value is specified in the categoryBag element of the tModel.

The overviewURL element (a subelement of the overviewDoc element ) refers to the URL
of the WSDL interface and binding document

Listing 14-4 shows how the reference to the WSDL interface and binding document is
made (see lines 7-9).

The tModelKey attribute in the keyedReference element is a UUID and points to a

tModel representing

the UDDI built-in uddi-org:types category system. The keyName and keyValue attributes
determine that this weather service tModel is a link to a WSDL document.
How the WSDL implementation document is referred to in a
bindingTemplate.

The accessPoint element of the bindingTemplate directly holds the

exact network address of the Web Services, as shown in Listing 14-
5.

No need to replicate this information elsewhere, Therefore, the

attachment of the WSDL implementation document is not required
to attach a WSDL implementation document to the binding template.
In this listing, we first direct the Web Services
client through the over-viewURL element to the
weatherServiceImpl.wsdl document (lines 5-7)
that contains the Web Services implementation
information.

The instanceParms element then directs the

client to the matching port entry within the
WSDL implementation document file.
 Summary of UDDI APIs
(Out of syllabus)

The users of the UDDI registry interact with the registry using synchronous calls.

SOAP is used as the message format

HTTP is used for the communication protocol.

UDDI call-and-response structures are embedded in the SOAP message body as

XML elements.

 A publication API

 An inquiry API
UDDI Registry API supports two kinds of operations:

A publication API A Web Services provider uses this API

to publish, update, or delete information about a Web
Service it offers.

The save_xxx call is used to create new information entities or

to update existing information entities. An example of such a
call is save_binding.

The delete_xxx call types are used to remove or unpublish

one or more information entities from the UDDI registry. This
type of call can take as input one or more key attributes
identifying the information entities to be removed.
A publication API-save bindings
A publication API-delete bindings
UDDI Registry API supports two kinds of operations:

An inquiry API A Web Services consumer uses this

API to search for information for a particular Web
Service and to find an appropriate service provider
who offers the required service

The find_ xxx calls are used to locate registered

information entities within the UDDI registry. Summary
list.

get_xxxDetail – to get specific details