Web services: How to find them Universal Description, Discovery, and Integration (UDDI)

Web services:
How to find them
Universal Description, Discovery,
and Integration (UDDI)
and other approaches
Outline
Maurizio Marchese – Web Services a.a.2008-2009
 In this lecture we described
    the role of service registries and the service discovery
process for web services
we introduced UDDI as a standard registry within a
Service Oriented Architecture
we examined the UDDI data structures and described
how they are related to WSDL documents and described
the UDDI APIs and how they are used to publish and
enquire about web services
We discuss current trends in service discovery
2
SOA interactions between actors
Maurizio Marchese – Web Services a.a.2008-2009
Problem to solve:
  How to find the service
one actually wants among
a potentially large
collection of services and
servers.
The goal is that the client
does not necessarily need
to know a priori where the
server resides or which
server provides the
service.
3
Service Discovery
Maurizio Marchese – Web Services a.a.2008-2009
  Service discovery is the process of locating web service
providers, and retrieving web services descriptions that
have been previously published
Interrogating services involves querying one or more
service registrys for web services matching the needs
of a service requester.
   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 service provider.
Discovering web services is a process that is dependent on the
architecture of the service registry.
After the discovery process is complete, the service developer
or client application should know the exact location of a web
service (URI), its capabilities, and how to interface with it.
4
Types of service discovery: static
Maurizio Marchese – Web Services a.a.2008-2009
There are two basic : static and dynamic
Static (old: similar to OOP)
 The results of the retrieval operation are examined
by a human designer and the service description
returned by the retrieval operation is incorporated into
the application logic.
 For WS code, generating tools from WSDL can be
usefully used
 With static discovery, the service implementation
details are bound at design time and a service
retrieval is performed on a service registry.
5
Example of static service discovery
Maurizio Marchese – Web Services a.a.2008-2009
 Look for instance at:
XMETHODS:
http://www.xmethods.net/ve2/Directory.po
 WebserviceX.NET:
http://www.webservicex.net/WS/
wscatlist.aspx
 WebServiceList
http://www.webservicelist.com
(with reccomandation info)
 (march 2009)
6
Maurizio Marchese – Web Services a.a.2008-2009
XMETHODS
7
Maurizio Marchese – Web Services a.a.2008-2009
WebServiceX.NET
8
Maurizio Marchese – Web Services a.a.2008-2009
WebServiceList
9
Types of service discovery: dynamic
Maurizio Marchese – Web Services a.a.2008-2009
Dynamic (new: towards adaptive SOA)
    With dynamic discovery, the service implementation details
are left unbound at design time so that they can be
determined at run-time.
The web service requester has to specify preferences to enable
the application to infer/reason which web service(s) the
requester 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 quality of service considerations such
as best price, performance, security certificates, and so on, the
application chooses the most appropriate service, binds to
it, and invokes it.
10
What is UDDI?
Maurizio Marchese – Web Services a.a.2008-2009
  The sponsoring organization, UDDI.org, is comprised of more than 200
major software developers and e-business leaders who hope to
catalyze the development of UDDI and related technologies.
The UDDI specification is probably the one that has undergone most
changes. The latest version is version 3 (July 2002):
    Originally, UDDI was conceived as a “Universal Business Registry”
similar to search engines (e.g., Google) which will be used as the
main mechanism to find electronic services provided by companies
worldwide.
  version 1 (September/2000) defined the basis for a business service registry
version 2 (June/2001) adapted the working of the registry to SOAP and WSDL
version 3 (July/2002) redefines the role and purpose of UDDI registries,
emphasizes the role of private implementations, and deals with the problem of
interaction across private and public UDDI registries
This triggered a significant amount of activity around very advanced and complex
scenarios (Semantic Web, dynamic binding to partners, runtime/automatic partner
selection, etc.)
Nowadays UDDI is far more pragmatic and recognizes the realities of B2B
interactions: it presents itself as the “infrastructure for Web services”,
meaning the same role as a name and directory service (i.e., binder in
RPC) but applied to Web Services and mostly used in constrained
11
Hype and reality
Maurizio Marchese – Web Services a.a.2008-2009
    There are a few universal
UDDI registries in operation
(maintained by IBM, Microsoft,
SAP, NTT, etc)
These registries are visible and
often the first thing one sees of
Web Services
Unfortunately, these registries
are still very small and
unreliable (most of the entries
in them do not work or do not
correspond to any real service)
This has been a source of
criticism to Web services in
general.
 The criticism has not been entirely
undeserved but it is often misguided:
what was there to criticize was not
UDDI itself but the use that has been
made of it and the hype around
dynamic Web services
   UDDI is rather useful if seen as
supporting infrastructure for Web
Services in well defined and
constrained environments
Most of the UDDI registries in
place today are private
registries operating inside
companies (recall that the
widest use of Web Services today
is for conventional EAI) or
maintained by a set of companies
in a private manner
UDDI has now become the
accepted way to document
Web Services and supply the
information missing in WSDL
descriptions
12
UDDI main characteristics
Maurizio Marchese – Web Services a.a.2008-2009
 UDDI provides a mechanism to categorize businesses and services
using taxonomies / classifications with or without an
Ontology
    For example, service providers can use a taxonomy to indicate that a
service implements a specific domain standard, or that it provides
services to a specific geographic area
UDDI uses standard taxonomies so that information can be
discovered on the basis of categorisation.
Core concept: UDDI business registration is an XML
document used to describe a business entity and its web
services.
UDDI is not bound to any technology. In other words, an entry in
the UDDI registry can contain any type of resource, independently
of whether the resource is XML-based or not.
  For instance, the UDDI registry could contain information about an
enterprise’s Electronic Document Interchange (EDI) system, DCOM
or CORBA interface, or even a service that uses the fax machine as
its primary communication channel.
The point is that while UDDI itself uses XML to represent the data it
13
stores, it allows for other kinds of technology to be registered.
Maurizio Marchese – Web Services a.a.2008-2009
Overview of UDDI data structures
14
Maurizio Marchese – Web Services a.a.2008-2009
Overview of UDDI data structures
15
UDDI Data Structures
Maurizio Marchese – Web Services a.a.2008-2009
  Although UDDI is often thought simply as a directory mechanism, it also
defines a data structure standard for representing company and service
description information. The data model used by the UDDI registries is
defined in an XML schema
The UDDI XML schema defines four core types of information.These are
     businessEntity : is a description of the organization that provides the
service.
businessService: a list of all the Web Services offered by the business entity.
bindingTemplate: describes the technical aspects of the service being
offered.
tModel: (“technical model”)is a generic element that can be used to store
additional information about the service, typically additional technical
information on how to use the service, conditions for use, guarantees, etc.
Together, these elements are used to provide:
   white pages information: data about the service provider (name, address,
contact person, etc.)
yellow pages information: what type of services are offered and a list of
the different services offered
green pages information: technical information on how to use each one of
the services offered, including pointers to WSDL descriptions of the services
(which do not reside in the UDDI registry)
16
Maurizio Marchese – Web Services a.a.2008-2009
<businessEntity>
data structure expressed in UML
17
Business entity
The generic white and yellow pages information about a service
provider is stored in the businessEntity, which contains the
following data:
Description
Info
      Taxonomy
info
Maurizio Marchese – Web Services a.a.2008-2009
    each businessEntity has a businessKey
discoveryURLs: a list of URLs that point to alternate, file based
service discovery mechanisms.
Name: (textual information)
Business description: (textual information)
Contacts: (textual information)
businessServices: a list of services provided by the businessEntity
identifierBag: a list of external identifiers
categoryBag: a list of business categories (e.g., industry, product
category, geographic region)
The businessEntity does not need to be the company. It is
meant to represent any entity that provides services: it can be a
department, a group of people, a server, a set of servers, etc
18
Business service
Maurizio Marchese – Web Services a.a.2008-2009
   The services provided by a
business entity are described in
business terms using
businessService elements.
A businessEntity can have several
businessServices but a
businessService belongs to one
businessEntity
It contains:
     a serviceKey that uniquely
identifies the service and the
businessEntity (not necessarily
the same as where the
businessService is found)
name: as before
description: as before
categoryBag: as before
bindingTemplates: a list to all
the bindingTemplates for the
service with the technical
information on how to access
and use the service
19
Maurizio Marchese – Web Services a.a.2008-2009
<bindingTemplate> and <tModel>
data structures expressed in UML
20
Binding template: “green pages”
Maurizio Marchese – Web Services a.a.2008-2009
 A binding template contains the technical information associated
to a particular service. It contains the following information:
        bindingKey
serviceKey
description
accessPoint: the network address of the service being provided
(typically an URL but it can be anything as this field is a string: e.g.,
an e-mail address or even a phone)
tModels: a list of entries corresponding to tModels associated with
this particular binding. The list includes references to the tModels,
documents describing these tModles, short descriptions, etc.
categoryBag: additional information about the service and its
binding (e.g., whether it is a test binding, it is on production, etc)
A businessService can have several bindingTemplates but a
binding Template has only one businessService
The binding template can be best seen as a folder where all the
technical information of a service is put together
21
tModel
 A tModel is a generic container of information where designers can write
any technical information associated to the use of a Web service:
Maurizio Marchese – Web Services a.a.2008-2009
   A tModel is a document with a short description of the technical
information and a pointer to the actual information. It contains:
        the actual interface and protocol used, including a pointer to the WSDL
description
description of the business protocol and conversations supported by the
service
tModelKey
name
description
overviewDoc: (with an overviewURL and useType that indicate where to find
the information and its format, e.g., “text” or “wsdl description”)
InstanceDetails: descriptions and URI of WSDL interfaces
identifierBag
categoryBag
A tModel can point to other tModels and eventually different forms of
tModels will be standardized
 tModel for WSDL services, tModels for EDI based services, RosettaNet Partner
22
Interface Processes (PIPs) …
Maurizio Marchese – Web Services a.a.2008-2009
Example of <tModel> entry
<tModel tModelKey="…" >
<name> RosettaNet-Org </name>
<description xml:lang=”en”>
Supports a process for trading partners to request and provide quotes
</description >
URL pointing to a zipped file where a
description of the PIP 3A1 "Request
Quote" can be found
<overviewDoc>
<description xml:lang=”en”>
This compressed file contains the specification in a word
document, the html guidelines document, and the XML schemas.
</ description>
<overviewURL>
http://www.rosettanet.org/rosettanet/Doc/0/
K96RPDQA97A1311M0304UQ4J39/3A1_RequestQuote.zip
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference keyName=" Trading quote request and provision"
keyValue=" 80101704" tModelKey=" ….."/>
</categoryBag>
</tModel>
list of name-value pairs that are used to
record specific taxonomy information, e.g.,
industry, product or geographic codes, for
23
this <tModel>
Interaction with an UDDI registry
Maurizio Marchese – Web Services a.a.2008-2009
 The UDDI specification provides a number of Application Program
Interfaces (APIs) that provide access to an UDDI system:
       UDDI Inquiry: to locate and find details about entries in an UDDI
registry. Support a number of patterns (browsing, drill-down)
UDDI Publication: to publish and modify information in an UDDI
registry. All operations in this API are atomic in the transactional
sense
UDDI Security: for access control to the UDDI registry (token
based)
UDDI Subscription: allows clients to subscribe to changes of
information in the UDDI registry (the changes can be scoped in the
subscription request)
UDDI Replication: how to perform replication of information across
nodes in an UDDI registry
UDDI Custody and Ownership transfer: to change the owner
(publisher) of information and ship custody from one node to another
within an UDDI registry
UDDI also provides a set of APIs for clients of an UDDI system:
  UDDI Subscription Listener: the client side of the subscription API
UDDI Value Set: used to validate the information provided to an 24
UDDI registry
UDDI inquiry API
Maurizio Marchese – Web Services a.a.2008-2009
      Search and lookup entries in a
registry.
This API is freely available, no
client authentication is required.
Errors are reported as SOAP
Faults
Browse functions search the
registry based on keywords and
return summary lists with
overview information (key, name
and description) about matching
businesses or services.
Find qualifiers are used to sort
the results and to control the
keyword matching: toggle
between AND/OR, case sensitive/
insensitive, use of wildcards and
categories.
To minimize the number of
requests, find queries can be
nested
 Drill-down functions are used to
fetch the specific UDDI data
structures about particular
entries given their key, returned
by the Browse functions
Browse functions
find_business
find_relatedBusinesses
find_service
find_binding
find_tModel
Drill down functions
get_businessDetail
get_operationalInfo
get_serviceDetail
get_bindingDetail
get_tModelDetail
UDDI Version 3.0 Specification, 19 July 2002
25
UDDI publishing and security API
Maurizio Marchese – Web Services a.a.2008-2009
     Publish, update and delete
 information contained in a UDDI
registry
The publishing API requires user
authentication using a session token
and typically uses SOAP over HTTPS  The registry performs access control
for all publishing functions:
information about the entries can only
be edited by the owner
Category information and keyed
references associated to the entries
are validated before accepting new
information into the registry
Deletion functions are used to remove
entries identified by their key from
the registry. Removing a business will
remove all services associated with it.
The same publishing functions are
used both to add new information or
replace existing information,
depending on whether a valid key is
passed or not.
When adding new entries, keys are
usually automatically generated by
the registry
Security Session Management functions
get_authToken, discard_authToken
Publishing functions
save_business
save_service
save_binding
save_tModel
Deletion functions
delete_business
delete_service
delete_binding
delete_tModel
26
WSDL to UDDI Mapping Model
Maurizio Marchese – Web Services a.a.2008-2009
 The service information defined in WSDL
documents is complementary to the
information found in UDDI business and
service entries.
   Since UDDI strives to accommodate many types of
service descriptions it has no direct support for
WSDL.
However, since UDDI and WSDL distinguish clearly
between interface and implementation, these two
constructs work together quite naturally.
In the following we will show how to map WSDL
service description into a UDDI registry, which is
required by existing web service tools and
runtime environments.
27
Maurizio Marchese – Web Services a.a.2008-2009
Mapping WSDL to UDDI schemas
28
Maurizio Marchese – Web Services a.a.2008-2009
UDDI and WSDL
29
Business information provider roles
Maurizio Marchese – Web Services a.a.2008-2009
 Registry operators: these refer to the organisations (referred to
earlier as operator nodes) that host and operate the UDDI
Business Register (UBR).
   The operator nodes manage and maintain the directory information,
cater for replication of business information and other directory
related functions.
The registry works on a ”register once, published everywhere”
principle. This means that a client searching for a business or service
can do so at any of the registry operators – they should get the same
information. This happens since the operator nodes registries
replicate their data with each other on a regular basis.
Standard bodies and industry consortia: these publish
descriptions in the form of service type definitions (<tModel> s).
 These <tModel> s do not contain the actual service definitions,
instead they have a URL that points to the location where the service
descriptions are stored (definitions can be in any form, however
UDDI, recommends using WSDL).
30
continued
Maurizio Marchese – Web Services a.a.2008-2009
 Service providers: commonly implement web services
conforming to service type definitions supported by UDDI.
   They publish information about their business and services in the
UDDI.
The published data also contains the end point of the web services
offered by these enterprises.
Private UDDI nodes: the term UDDI is often used to mean both
the protocol with its data structures and Application Program
Interface (API), that is publish and find operations, as well as the
global UDDI Business Registry described in the previous.
  This is not, however, the only way that UDDI registry can be
deployed, there are other deployment possibilities
The structure of the UDDI allows the possibility of private UDDI
nodes. A private (non-operator) UDDI node can implement all the
UDDI functionality, but it does not participate in the replication
scheme defined by the UDDI operator’s agreement.
31
UDDI deployment possibilities
Maurizio Marchese – Web Services a.a.2008-2009
 The e-marketplace UDDI: an e-marketplace, a standards body,
or a consortium of organisations that participate and compete in
the industry can host this private UDDI node.
    The e-marketplace could run a local version of a UDDI registry with
its data shielded from the global UDDI registry.
The entries in this private UDDI relate to a particular industry or
narrow range of related industries.
The e-marketplace node can then provide value added services such
as quality of service monitoring, validation of content published by
companies, ensure that participants in the UDDI registry have been
vetted by a rigorous selection procedure, and also ensure that all
entries pertain to the market segment of interest.
Such a deployment might be not free of charge like the global
registry and may charge a fee, either from the service providers or
from the clients for providing such value added services
32
continued
Maurizio Marchese – Web Services a.a.2008-2009
 The business partner UDDI registry: this variant of the above
scheme is a private UDDI node hosted behind one of the business
partner’s firewall and only trusted or vetted partners can access
the registry.
  It also contains web service description meta-data published by
trusted business parties (that is, those organisations with which the
hosting organisation has formal agreements/relationships).
The portal UDDI: this type of deployment is on an enterprise’s
firewall and is a private UDDI node that contains only meta-data
related to the enterprise’s web services.
  External users of the portal would be allowed to invoke find
operations on the registry, however, a publish operation would be
restricted to services internal to the portal.
The portal UDDI gives a company ultimate control over how the
meta-data describing its web services is used.
33
continued
Maurizio Marchese – Web Services a.a.2008-2009
 The internal UDDI: this allows applications in different
departments of the organisation to publish and find services, and
is useful for large organisations.
   The major distinction of this UDDI variant is the potential for a
common administrative domain that can dictate standards (for
example a fixed set of tModels can be used).
This allows the UDDI node to operate with different publish
restrictions than those suggested for the business partner UDDI. For
example, the node could restrict the publication of new tModels and
thereby restrict publishing of <businessService>s and
<bindingTemplate> to accept only entries associated with a fixed set
of tModels .
These kinds of UDDI deployments are called EAI UDDI, as they allow
corporations to deploy and advertise Intranet web services.
34
Summary UDDI
Maurizio Marchese – Web Services a.a.2008-2009
     The UDDI specification is fairly complete and encompasses many
aspects of an UDDI registry from its use to its distribution across several
nodes and the consistency of the data in a distributed registry
Most UDDI registries are private and typically serve as the source of
documentation for integration efforts based on Web services
UDDI registries are not necessarily intended as the final repository of the
information pertaining Web services. Even in the “universal” version of
the repository, the idea is to standardize basic functions and then build
proprietary tools that exploit the basic repository. That way it is possible
to both tailor the design and maintain the necessary compatibility across
repositories
While being the most visible part of the efforts around Web services,
UDDI is perhaps the most critical due to the complexities of
realistic and dynamic B2B interactions (establishing trust, contracts,
legal constrains and procedures, etc.)
The ultimate goal is, of course, full automation, but until that
happens a long list of problems needs to be resolved and much more
standardization and semantic information is necessary.
35
Some References
Maurizio Marchese – Web Services a.a.2008-2009
 Specifications:
http://www.uddi.org
http://uddi.org/pubs/uddi-v3.00-published-20020719.pdf
 UDDI
Business Registry (UBR) nodes:
IBM
Homepage: http://uddi.ibm.com/
Inquiry API:
http://uddi.ibm.com/ubr/inquiryapi
Publish API:
https://uddi.ibm.com/ubr/publishapi
Microsoft
Homepage: http://uddi.microsoft.com/
Inquiry API:
http://uddi.microsoft.com/inquire
Publish API :
https://uddi.microsoft.com/publish
SAP
Homepage: http://uddi.sap.com/
Inquiry API : http://uddi.sap.com/uddi/api/
inquiry
Publish API : https://uddi.sap.com/uddi/api/
publish
NTT
Homepage: http://www.ntt.com/uddi/
Inquiry API : http://www.uddi.ne.jp/ubr/
inquiryapi
Publish API : https://www.uddi.ne.jp/ubr/
publishapi
36
Beyond UDDI
Maurizio Marchese – Web Services a.a.2008-2009
 Initial vision of UDDI
  Replication of centralized UBRs
Businesses will be businesses
Need privacy, security, trust
 Rise of private and semi-private registries
  New UDDI versions (4+) will provide
support for distributed registries
37
Registry Federation
Registry Federation is defined as a
“group of co-operating registries” that
provide transparent access to all member
registries
 Examples of federations
Maurizio Marchese – Web Services a.a.2008-2009
 Two companies X and Y share their registries
 Federation of all registries in Auto parts
domains
 38
An Example: METEOR-S
Maurizio Marchese – Web Services a.a.2008-2009
Web Service Discovery Infrastructure (MWSDI)
http://lsdis.cs.uga.edu/Projects/METEOR-S
39
Extended Registries Ontologies
(XTRO)
Maurizio Marchese – Web Services a.a.2008-2009
 Provides a multifaceted view of all
registries in MWSDI
   Federations
Domains
Registries
Registry
Federation
belongsTo
Federation
belongsTo
Registry
supports
Domain
subDomainOf
Ontology
consistsOf
40
Types of Queries Supported
Maurizio Marchese – Web Services a.a.2008-2009
       What is the access URL, available data model or type
of the registry R?
Does the registry R support the ontology O?
Which are the registries available under the business
domain B?
Is the registry X a member of the registry federation Y?
Which registries pertain to the domains that support
the ontologies O1 and O2?
Get all the registry federations that belong to the
domain D?
Find all the registries that are categorized under the
node N in the taxonomy (or ontology) C?
41
Next-Generation Web Services
Discovery Mechanism
Maurizio Marchese – Web Services a.a.2008-2009
  A script-based search agent will likely play an
important role in Web services discovery for
Web browser-based Web services, discovery
clients, and e-business applications.
The mechanism should:
    Use a standard interface
Simplify the developer's work
Hide the complexity of UDDI and WSIL (search
clients Web Service Inspection Language)
Perform result aggregation from one or multiple
federated sources
42
Maurizio Marchese – Web Services a.a.2008-2009
Agent-Based Web Service Search
43