Unit 4

Registering and discovering Web services

THE ROLE OF SERVICE REGISTRIES:

 To exploit the full potential of e-business, organizations must be able to discover each other, make
their needs and capabilities known, and compose Web services from diverse organizations into new
services and business processes.
 The solution is to enable businesses to discover and reach each other, to learn what kinds of
capabilities their potential trading partners have, and to continuously discover new potential trading
partners, understand what their capabilities are, and seamlessly conduct e-business with them.
 This solution requires the creation of a service registry architecture that enables enterprises to
introduce a global, platform-independent, open framework for businesses to
 discover each other,
 define how they interact over the Internet, and
 share information in a global registry that will more rapidly accelerate the global adoption of
e-business.

Service Registries:
 Service registries are all about visibility and control. At the simplest level, a service registry keeps
track of what services an organization has and characteristics of those services.
 In general, two types of e-business registries can be discerned: the document-based and the
metadata-based service registry.
 These registries differ from one another in the way that they handle descriptive service information.
Document-Based service registry:
 A document-based service registry enables its clients to publish information by storing XML-based
service documents, such as business profiles or technical specifications (including WSDL
descriptions of the service), in the registry.
 When these descriptive documents are submitted to the registry, service providers must also provide
descriptive information about each document in the form of service metadata.
 Metadata is one of the key elements of any integration solution because it is used to describe the
structure of information held in the disparate systems and processes.
 This may range from the structure of XML schemas, interface definitions, or endpoints in locations
across the network to the detailed description of an entire process (e.g., a process that sets up a new
customer account or processes a customer-initiated order). Metadata is stored in the service registry
and is used by the registry to provide meaningful attachments to its descriptive
 documents, which are made persistent in the storage facility of the service registry.
 The registry is completely oblivious to the content of the service documents themselves.
Metadata-based service registry
 In the metadata-based service registry a different approach is used to deal with service-related
information.
 Service providers simply submit documents that contain service information. However, these
documents are not stored as such. Instead, the registry reads the information contained in the service
documents and creates metadata, which captures the essence of the submitted document.
 The metadata is stored in the service registry in an internal format. In this case, the service registry is
not oblivious to the published information.
 It is possible that the metadata contains references to content, to which the registry is oblivious.
  However, the registry does not manage these documents in this situation. Rather, the registry
provides links to the documents.

Advantages:

Maximizes Web services reuse and encourages broad usage by all potential users in an SOA solution.
◆ Creates a management and governance structure to grow and sustain a successful SOA implementation.
◆ Contains all the metadata about Web services and their associated objects. It also contains information
about service providers, consumers, and their relationships.
◆ Provides general- and special-purpose interfaces that address the needs of providers, consumers,
administrators, and operators.
◆ Ensures that the evolving SOA can handle the growing number of services and service consumers and
quickly adapt to changing business requirements.

SERVICE DISCOVERY

 Service discovery is an important element of an SOA. Service discovery is the process of locating
Web service providers, and retrieving Web service descriptions that have been previously published.
 Web service discovery entails locating and interrogating Web service definitions, which is a
preliminary step for accessing a Web service.
 It is through this discovery process that Web services clients learn that a particular Web service
exists, what its capabilities are, and how to properly interact with it. Interrogating services involves
querying the service registry for Web services matching the needs of a service requestor.
 A query consists of search criteria such as the type of the desired service, preferred price, and
maximum number of returned results and is executed against service information published by the
service provider.
 After the discovery process is complete, the service developer or client application should know the
exact location of a Web service (a URI for the selected service), its capabilities, and how to interface
with it.
 Service selection involves deciding on what Web service to invoke from the set of Web services the
discovery process returned.

There are two basic types of service discovery: static and dynamic

Static Service Discovery:

 Static service discovery generally occurs at design time, whereas dynamic discovery
 occurs at run-time.
 With static discovery, the service implementation details such as the network location and network
protocol to use are bound at design time and service retrieval is performed on a service registry.
 A human designer usually examines the results of the retrieval operation and the service description
returned by the retrieval operation is incorporated into the application logic.

Dynamic Service Discovery:

 With dynamic discovery, the service implementation details such as the network location and
network protocol to use are left unbound at design time so that they can be determined at run-time.
 In this case, the Web service requestor has to specify preferences to enable the application to infer
which Web service(s) the requestor is most likely to want to invoke.
  The application issues a retrieval operation at run-time against the service registry to locate one or
more service implementation definitions that match the service interface definition used by the
application.
 Based on application logic, QoS considerations such as best price, performance, security certificates,
and so on, the application chooses the most appropriate service, binds to it, and invokes it.

UDDI: Universal Description, Discovery, and Integration

UDDI is a registry that contains relatively lightweight data. As a registry its prime purpose is to provide
network addresses to the resources it describes, e.g., schemas, interface definitions, or endpoints, in
locations across the network.
The core concept of the UDDI initiative is the UDDI business registration, an XML document used to
describe a business entity and its Web services.
Conceptually, the information provided in a UDDI business registration consists of three interrelated
components:
 White Pages, including address, contact, and other key points of contact;
 Yellow Pages , the classification of information according to industrial classifications based on
standard industry taxonomies; and
 Green Pages, the technical capabilities and information about services that are exposed by the
business including references to specifications for Web services and pointers to various file- and
URL-based discovery mechanisms.
Using a UDDI registry, enterprises can discover the existence of potential trading partners and basic
information about them (through white pages), find companies in specific industry classifications (through
yellow pages), and uncover the kind of Web services offered to interact with the enterprises (through green
pages).
The information that is stored in the UDDI registry allows applications and developers to determine who the
business entity represents, what they do, where the services they provide can be found, and how they can be
accessed.

Advantages:
 To address the challenges of service registration and discovery, the Universal Description,
Discovery, and Integration specification was created. UDDI is a cross-industry initiative o create a
registry standard for Web service description and discovery together with a registry facility that
supports the publishing and discovery processes.
 The UDDI specifications take advantage of World Wide Web Consortium (W3C) and Internet
Engineering Task Force (IETF) standards such as XML, HTTP, and Domain Name System (DNS)
protocols.
 UDDI is designed for use by developer tools and applications that use Web services standards such
as SOAP/XML and WSDL. UDDI provides a global, platform-independent, open framework making
it easier to publish an enterprise’s preferred means of conducting business, find trading partners, and
interoperate with these trading partners over the Internet.
 By automating the registration and interrogation processes, UDDI enables service providers to
describe their services and business processes in a global, open environment on the Internet, thus
extending their reach.
 It also enables service clients to discover information about enterprises offering Web services; find
descriptions of the Web services these enterprises provide; and, finally, find technical information
about Web service interfaces and definitions of how the enterprises may interact over the Internet.
UDDI Registries
 An implementation of the UDDI specification is termed as a UDDI registry.
 UDDI registry services are a set of software services that provide access to the UDDI registry.
Meanwhile, registry services can perform a plethora of other activities such as authenticating and
authorizing registry requests, logging registry requests, load-balancing requests, and so on.
 A UDDI registry in itself is a Web service. A Web service consumer queries the UDDI registry using
the SOAP API defined by UDDI specification.
 Also, the UDDI specification publishes a WSDL description of the UDDI registry service.
 The UDDI project community members operate a UBR. This registry is available to everyone for
free publishing/querying of businesses and services information.

Public and Private UDDI Registries

A UDDI registry can be operated in two modes: public mode and private mode.
Public:
 A public UDDI registry is available for everyone to publish/query the business and service
information on the Internet.
 Such public registries can be a logical single system built upon multiple UDDI registry nodes that
have their data synchronized through replication.
 Thus, all the UDDI registry node operators would each host a copy of the content and accessing any
node would provide the same information and quality of service as any other operator node.
 Such global grouping of UDDI registry nodes is known as a UDDI Business Registry, or UBR.
 Content can be added into a UBR from any node, however, content can be modified or deleted only
at a node at which it was inserted.

Private:
 A private UDDI registry is operated by a single organization or a group of collaborating
organizations to share the information that would be available only to the participating bodies.
 Private UDDI registries can impose additional security controls to protect the integrity of the registry
data and to prevent access by unauthorized users. Note that a private node also can participate in
information replication.

Uses of UDDI Registry

Businesses can use a UDDI registry at three levels:
 White pages level. Businesses that intend to register just the very basic information about their
company, such as company name, address, contact information, unique identifiers such as D-U-N-S
numbers or Tax IDs, or Web services use UDDI as white pages.
 Yellow pages level. Businesses that intend to classify their information based on categorizations
(also known as classification schemes or taxonomies) make use of the UDDI registry as yellow
pages.
 Green pages level. Businesses that publish the technical information describing the behavior and
supported functions on their Web services make use of the UDDI registry as green pages.

UDDI SPECIFICATIONS
The UDDI 2.0 specification set includes the following documents:

UDDI replication.
The document describes the data replication process of the UDDI registries. Also, it describes the
programmatic interfaces supported by UDDI for achieving replication between
UDDI registries operated by different operators.

UDDI operators.
This document provides information on the operational behaviour that should be followed by UDDI node
operators. For example, the document defines guidelines that node operators can
follow in order to manage the data of the UDDI registry node.

Such guidelines include the following:

■■ Node operators’ responsibility for durable recording and backup of all data. Checking the validity of
information provided by businesses during registration, such as email addresses.
■■ Checking the integrity of data in the UDDI registry after it has been modified. For example, if a business
has been deleted from the registry, then the operator should ensure that the services
corresponding to this business also are deleted.

UDDI programmer’s API. This document describes the programming interfaces supported by a UDDI
registry in terms of SOAP messages. This document is targeted towards programmers who want to write
software that would interact with a UDDI registry operated at a public or private level, using SOAP.

UDDI data structures. This document outlines the details of the XML structures that are associated with
the SOAP messages used to communicate with the UDDI registries. These SOAP messages are well
defined by the UDDI programmer’s API specification and are used to perform the inquiry and publishing
functions on the UDDI registry.

UDDI Programming API

The UDDI specification defines two XML-based programming APIs for communicating with the UDDI
registry node: inquiry API and publishing API. The following sections describe each of these.

Inquiry API
 The inquiry API consists of XML messages defined using a UDDI Schema, which can be used to
locate information about a business, such as the services a business offers and the technical
specification of those services (such as a link to a WSDL document describing the interface of the
service, the binding of the service and the URL where the service is running, and so on).
 AUDDI programmer would use these inquiry APIs to retrieve information stored in the registry.
 To retrieve information, a registry user does not need to be authenticated.
The following is a list of inquiry API functions that can be used for finding information in a UDDI registry:
■■ <find_business>
■■ <find_relatedBusinesses>
■■ <find_service>
■■ <find_binding>
■■ <find_tModel>
To get further detailed information from the UDDI registry, the following
inquiry API functions are available:
■■ <get_businessDetail>
■■ <get_businessDetailExt>
■■ <get_serviceDetail>
■■ <get_bindingDetail>
■■ <get_tModelDetail>

Publishing API
 The publishing API consists of functions represented by a UDDI Schema, which defines XML
messages that can be used to create, update, and delete the information present in a UDDI registry.
 Note that in order to publish to a UDDI registry, the registry user needs to be authenticated.
 The following is a list of publishing API functions that can be used for adding/modifying
information to a UDDI registry:
■■ <save_business>
■■ <set_publisherAssertions>
■■ <add_publisherAssertions>
■■ <save_service>
■■ <save_binding>
■■ <save_tModel>
The following is a list of publishing API functions that can be used for deleting information from a UDDI
registry:
■■ <delete_business>
■■ <delete_publisherAssertions>
■■ <delete_service>
■■ <delete_binding>
■■ <delete_tModel>
Apart from the functions just mentioned, the publishing API also defines functions that deal with the
authentication of the registry users, which is required in order to successfully execute the rest of the
functions of this API:
■■ <get_authToken>
■■ <discard_authToken>

UDDI Data Structures

 The information managed by a UDDI registry is represented as XML data structures also known as
UDDI data structures.
 The UDDI data structures specification document defines the meaning of these data structures and
the relationship between them.
 Ultimately, it is these data structures with which a UDDI client needs to work.
 A UDDI client makes use of these, in conjunction with the XML messages of programming APIs, to
manipulate a specific type of information in a registry.
 Similarly, response to a search operation received from the UDDI registry also would consist of
these data structures.
 Hence, the UDDI data structures are more or less input and output parameters for the UDDI
programming API.
The following are the five primary UDDI data structures defined in the specification:
■■ <businessEntity>
■■ <publisherAssertion>
■■ <businessService>
■■ <bindingTemplate>
■■ <tModel>

<businessEntity>
 The <businessEntity> data structure represents the primary information about a business, such as
contact information, categorization of the business according to a specific taxonomy or classification
scheme, identifiers, relationships to other business entities, and descriptions about that particular
business.
 The categorizations are discussed in a later section titled Support for Categorization in UDDI
Registries.

<publisherAssertion>
 A business registered in a UDDI registry can have active business relationships with other
businesses.
 This relationship can be of any form, for example, a relationship of business partners or a business-to
customer relationship. Such relationships are represented by a <publisherAssertion> data structure in
a UDDI Registry.
 The <publisherAssertion> structure is used to establish a relationship between two <businessEntity>
structures.

<businessService>
 The <businessService> data structure represents the service of a business.
 These services can be Web services or any other type of service. For example, the <businessService>
data structure may represent a service hat is offered over the telephone, such as a telephone banking
service.
 The <businessService> data structure is merely a logical representation of services that a business
has to offer.
 A <businessEntity> structure contains one or more <businessService> structures. The same
<businessService> structure also can be used by multiple <businessEntity> structures. For example,
if a business has two departments—say, manufacturing and sales— that are each published to a
UDDI registry as a <businessEntity> structure, then both of them can use the same
<businessService> structure representing another business service—say, legal counseling.

<bindingTemplate>
 The <bindingTemplate> structure consists of pointers to technical descriptions and access URLs of
the service.
 Each <businessService> structure can contain one or more <bindingTemplate> structures. So, for
example, if the <businessService> structure represents a Web service, then its <bindingTemplate>
would refer to a PDF document providing the technical description of this Web service and the URL
at which the Web service can be accessed. Also, the <bindingTemplate> structure can provide an
optional description of the Web service.

tModel>
 The <tModel> structure provides a description of a particular specification or behavior of the service.
 The <tModel> structure does not contain the service specification directly; instead, it contains a link
to the service specification, which is managed elsewhere.
 The <tModel> thus defines the interaction pattern in order to use the service. For example, a business
  may provide a Web service whose WSDL interface may be referenced through a link from within the
<tModel> structure.
 Thus, <tModel> defines the lowest-level and most concrete piece of information about the services
offered by a business.
 A UDDI client typically gets hold of the service specification pointed out by the <tModel> structure
in order to use a publicly available Web service registered by a particular business.

The linking between these five core data structures of UDDI is depicted.

Apart from these five primary data structures, two other structures exist that represent the category and
identification information of the primary data structures: <identifierBag> and <categoryBag>.

<identifierBag>
 The <identifierBag> structure enables <businessEntity> or <tModel> structures to include
information about the common forms of identification such as D-U-N-S numbers and tax IDs.
 This data can be used to signify the identity of <businessEntity>, or it can be used to signify the
identity of the publishing party.
 Including such identification information is optional.
 However, when a published <businessEntity> or <tModel> carries such common forms of
identification, it greatly enhances the search behaviors exposed via inquiry API functions.

<categoryBag>
  The <categoryBag> structure enables <businessEntity>, <businessService>, and <tModel> structures
to be categorized according to any categorization system, such as an industry categorization system
or a geography categorization system.
 Categorizing the data structures mentioned previously is optional.
 However, when these data structures are published along with their categorization information, it
greatly enhances the search behaviors exposed via inquiry API functions.
 The categorization support in a UDDI registry is discussed in the following section.

Implementations of UDDI
The UDDI specification enjoys tremendous amounts of vendor support.
There are a lot of offerings in the UDDI space. Vendors provide UDDI
support in two ways:

UDDI client.
Almost all of the vendors participating in the UDDI space provide UDDI client support.
A UDDI client basically provide APIs required for working with the UDDI registry.
These APIs can be in a variety of languages such as Java, C++, Python, and so on.
Note that most of the vendors, as of this writing, provide proprietary implementations of Java APIs for UDDI. JSR-
093 JAXR is an effort to provide a standard Java API for communicating with UDDI registries.
Because the JAXR specification has just recently been finalized, vendors should now be able to start providing
support for JAXR in their API implementations.
The JAXR specification is covered in more detail in Chapter 11, “Java API for XML Registries.”
The examples covered in this chapter do not make use of JAXR APIs.

UDDI registry server implementation.

Many implementations of the UDDI registry server are available now.
Apart from the public registries hosted by Microsoft, HP, IBM, and Systinet, several vendors also provide
implementations of private UDDI registries.

Limitations of UDDI
UDDI is an evolving standard.
Currently, the most deployed version of UDDI (2.0) is limiting in terms of the information model that it supports,
especially when compared to other registry specifications such as ebXML Registry/Repository. UDDI provides
support for storing only the basic data structures, such as businesses, users, services, and service technical
descriptions.
However, storing information about business Web services requires more than just the basic support. For example,
potential users of business Web services should be able to publish/query extensive business oriented information,
such as the business process models that a particular business Web service relies upon.
This is possible only if the target registry provides a data structure representing the business process model.
Thus, an information model is an important feature for any registry.

Addressing and notification

Web Services Notification
Event-driven processing and notification introduces a pattern known as the notification
pattern for SOA implementations. In the notification pattern (sometimes also referred to
as the event pattern), an information-providing service sends one-way messages to one or
more interested receivers. It is possible that more than one consuming service is registered
to consume the same information. In addition, the information-providing (distributing)
service may send any number of messages to each registered consuming service as the
application may require. In this pattern the message frequently carries information about
an event that has occurred rather than a request that some specific action should occur.
Another requirement is that message receivers are registered prior to receiving the
notifications. Service registration may be initiated either by the consuming services
themselves, or by a third party. Registration may be preconfigured or may happen
dynamically.
The WS-Notification family of standards provides support for both brokered as well as
peer-to-peer publish/subscribe notification and proposes three normative specifications:
WS-BaseNotification, WS-Topics, and WS-BrokeredNotification.
Peer-to-peer notification