WS Technologies I UDDI

1
WS Technologies IUDDI
Models and Languages for Coordination and
Orchestration IMT- Institutions Markets
Technologies - Alti Studi Lucca
Roberto Bruni Dipartimento di Informatica
Università di Pisa
2
Contents

• Web Services, informally
• SOAP a protocol for WS
• UDDI registries

3
Universal Description Discovery an Integration
Protocol (UDDI)

• UDDI
• a directory service for web service (phone book
  analogy)
• a platform-independent, Internet-based way of
• describing services,
• discovering business,
• and integrating business services
• UDDI registry
• indexed collection of service interfaces
  (described in WSDL format with some additional
  information)
• similar to DNS
• unique catalogue, distributed but not necessarily
  hierarchical
• SOAP based interaction/communication

4
Why UDDI? I

• Imagine a city that hosts around 100,000 business
• assume that city has no such thing as a business
  directory
• no yellow pages
• nor any commercial listings in white pages
• (OK, maybe that would be nice... )
• Business in such a city would have great
  difficulty finding each other
• each business would build it's own directory
  containing contacts for customers and suppliers
• suppose each business maintained 1000 contacts
• there would be 100 Million contacts being
  maintained
• imagine the cost of unnecessary duplicated effort
  
• imagine the potential for errors as contacts
  change

5
Why UDDI? II

• As if all this were not bad enough
• imagine how it would be if each business spoke a
  different language
• when you finally get through, you can't
  communicate!
• B2B communities face a very similar problem
• each community member typically maintains a set
  of data about each partner
• (access points, security credentials, interface
  definitions, etc)
• furthermore each member will often impose
  different business technical requirements on
  their partners

6
Service Discovery

• The purpose of UDDI compliant registries is to
  provide a service discovery platform on the World
  Wide Web
• Service discovery is related to being able to
  advertise and locate information about different
  technical interfaces exposed by different parties
• Services are interesting when you can discover
  them, determine their purpose, and then have
  software that is equipped for using a particular
  type of Web service, complete a connection and
  derive some benefit
• A UDDI compliant registry provides an information
  framework for describing services exposed by any
  entity or business
• to promote cross platform service description
  that is suitable to a black-box Web
  environment, this description is rendered in
  cross-platform XML

7
UDDI Profiles I

• (just a conceptual separation, not necessarily
  effective)
• White pages
• basic contact data (like business name,
  identifiers, some technical information, address
  contact details for negotiations and technical
  support)
• Yellow pages
• standard classification data (like geography,
  industry code) that are used to classify business
  and services
• Green pages
• technical interface and access point details for
  services (like WSDL description)
• point to "tModels" which, in turn, provide the
  service technical details

8
UDDI Profiles II

• All the UDDI components are meta-data entries
• Web Services are described by XML objects such as
  WSDL (Web Service Description Language) files
• Rather like the card index in a library, UDDI
• describes and points to these objects
• but does not store the objects, which are located
  anywhere on the internet

9
UDDI Architecture

• UDDI is situated one level up w.r.t. SOAP
• two kinds of user
• publishers
• "readers"
• UDDI servers authenticate publishers
• keep track of the publisher of any service
  description
• only the publisher will be able to remove or
  modify the entry

UDDI
SOAP
XML
Transport protocols (HTTP, HTTPS, )
10
UDDI v3 History
Version Year Goal
1.0 2000 public registry foundation
2.0 2003 Web Services alignment and extensible taxonomies
3.0 2004 Flexible and secure registry interaction models
11
Key Functional Concepts

• UDDI data model
• businessEntity
• businessService
• bindingTemplate
• tModels (metadata)
• publisherAssertion
• Hierarchy of registry instances
• Nodes, registries, affiliated registries
• Key programmatic interfaces
• Publish, search, replicate, subscribe, key
  management, authentication
• Multiple, flexible service taxonomies

12
A Closer Look at theUDDI Data Model
publisherAssertion Information about a
relationship between two parties, assessed by one
or both
publisherAssertion Information about a
relationship between two parties, assessed by one
or both
13
White pages

• Tailored to human beings (instead of
  applications)
• useful reference in the initial phase of
  commercial partnerships
• Main data structure uddibusinessEntity
• contains contacts (description, addresses,...),
  and other information related to a business
  entity
• since not all kinds of information can be
  foreseen, a special element uddiidentifierBag
  can be used to list generic name-value pairs
• DUNS code (Dun Bradstreet number)
• partita IVA
• All the entities in UDDI registries are assigned
  a universal unique identifier (uuid) acting as
  primary key
• 128 bits xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  (where x in 0-F)

14
Sketch ofbusinessEntity Schema
ltelement name"businessEntity"gt ltcomplexTypegt
ltsequencegt ltelement
ref"discoveryURLs" minOccurs"0" /gt
ltelement ref"name" maxOccurs"unbounded" /gt
ltelement ref"description" minOccurs"0"
maxOccurs"unbounde
d" /gt ltelement ref"contacts"
minOccurs"0" /gt ltelement
ref"businessServices" minOccurs"0" /gt
ltelement ref"identifierBag" minOccurs"0" /gt
ltelement ref"categoryBag" minOccurs"0" /gt
lt/sequencegt ltattribute
ref"businessKey" use"required" /gt
ltattribute ref"operator" /gt ltattribute
ref"authorizedName" /gt lt/complexTypegt lt/elemen
tgt
15
Yellow pages

• Most interesting face of UDDI registries
• Allows business entities to search services
• category searches, by name, by service typology
• and many more (ex. similar entities)
• The element uddicategoryBag of
  uddibusinessEntity is particularly relevant
• it contains general categories referred to
  business and services
• UDDI supports a whole set of different taxonomies
  
• NAICS (North American Industry Classification
  System) for numeric industry code
• UNSPSC (United Nations Standard Product and
  Services Classification)
• ISO 3166 (International Standard for geographical
  regions)
• Each taxonomy is described by a suitable tModel

16
Sketch ofbusinessService Schema
ltelement name"businessService"gt
ltcomplexTypegt ltsequencegt ltelement
ref"name" maxOccurs"unbounded" /gt
ltelement ref"description" minOccurs"0"
maxOccurs"unbounded"
/gt ltelement ref"bindingTemplates" /gt
ltelement ref"categoryBag" minOccurs"0"
/gt lt/sequencegt ltattribute
ref"serviceKey" use"required" /gt
ltattribute ref"businessKey" /gt
lt/complexTypegt lt/elementgt
17
Green pages

• Technical information for service/software
  developers
• Two main structures
• uddibindingTemplate
• access point (it is fundamental at runtime)
• technical schema including a set of tModel keys,
  implemented methods, and required parameters
• udditModel
• t as type (also technical)
• Model as model ?
• used to assign "labels" to taxonomies

18
Sketch ofbindingTemplate Schema
ltelement name"bindingTemplate"gt
ltcomplexTypegt ltsequencegt ltelement
ref"description" minOccurs"0"
maxOccurs"unbounded" /gt
ltchoicegt ltelement ref"accessPoint"
minOccurs"0" /gt ltelement
ref"hostingRedirector" minOccurs"0" /gt
lt/choicegt ltelement ref"tModelInstanceDet
ails" /gt lt/sequencegt ltattribute
ref"bindingKey" use"required" /gt
ltattribute ref"serviceKey" /gt
lt/complexTypegt lt/elementgt
19
Service Type Definition(also known as tModel) I

• For two pieces of software to be compatible with
  each other
• (i.e. compatible enough to exchange data for the
  purpose of achieving a desirable result)
• they must share some common design goals and
  specifications
• The UDDI registry information model is based on
  this sharing
• in the past, two companies only had to agree to
  use the same specification (and then test their
  software)
• within a UDDI registry, business need to publish
  information about the specifications and versions
  of specifications used to design their advertised
  services
• to distinctly identify public specifications (or
  even private specifications shared only with
  select partners), information about the
  specifications themselves needs to be
  discoverable ( a classic metadata construct)
• this information about specifications is called a
  tModel within UDDI

20
Service Type Definition(also known as tModel) II

• A tModel is a UDDI entry that
• is independent of a particular business entity
• and is designed to describe standard interface
  definitions that are re-used by many business
• ex. many business might provide a sales order
  service but all comply with the same EAN.UCC
  standard that is described by a tModel
• provides the ability to describe compliance with
  a specification, a concept, or a shared design
• can have various uses in the UDDI registry
• mainly used to represent technical specifications
  like wire protocols, interchange formats and
  sequencing rules
• When a particular specification is registered
  with the UDDI repository as a tModel, it is
  assigned a unique key, which is then used in the
  description of service instances to indicate
  compliance with the specification

21
tModel Example

• A business bought a software package that can
  automatically accept electronic orders via
  Internet connection
• the availability of this capability can be
  advertised on a public UDDI
• partners and customers can find out that
  electronic orders are accepted
• the business chose this sw package because its
  widespread popularity
• the salesperson highlighted a feature that gives
  the new sw its broad appeal
• the use and support of a widely used electronic
  commerce interface that accommodates automatic
  business data interchange
• As the new software is installed and configured,
  it automatically consulted a public UDDI and
  identified compatible business partners
• It located those business that had already
  advertised support for (compatible) electronic
  commerce services
• The sw took advantage of the fact that a tModel
  has been registered and a corresponding tModel
  key gets assigned at the time of registration
• This tModel represents the interface or
  specification for the electronic commerce
  capability

22
tModel Benefit

• tModel keys are some sort of fingerprint
• to trace the compatibility of a given service
• many such services will be constructed or
  pre-programmed to be compatible with a given,
  well-known interface
• For software companies and programmers
• tModels provide a common point of reference
• they allow a technical interface to be
  registered, and compatible implementations of
  those interfaces to be easily identified
• For business that use software
• greatly reduced work in determining which
  bindings exposed by a business partner are
  compatible with the software used in-house
• For standards organizations
• the ability to register information about a
  specification and find web services
  implementations that are compatible with a
  standard helps customers realize the benefits of
  a widely used design

23
Sketch oftModel Schema
ltelement name"tModel"gt ltcomplexTypegt
ltsequencegt ltelement ref"name" /gt
ltelement ref"description" minOccurs"0"
maxOccurs"unbounded
" /gt ltelement ref"overviewDoc"
minOccurs"0" /gt ltelement
ref"identifierBag" minOccurs"0" /gt
ltelement ref"categoryBag" minOccurs"0" /gt
lt/sequencegt ltattribute name"tModelKey"
use"required" /gt ltattribute
name"operator" use"optional" /gt
ltattribute name"authorizedName" use"optional"
/gt lt/complexTypegt lt/elementgt
24
tModel Examples

• UDDI Home Page Specification
• tModel structure
• Usage example
• UDDI HTTP Transport
• tModel structure
• Usage example
• UDDI SMTP Transport
• tModel structure
• Usage example
• UDDI Fax Protocol
• tModel structure
• Usage example

25
UDDI Data Model
26
publisherAssertion

• Many business (like large enterprises,
  marketplaces) are not effectively represented by
  a single businessEntity
• their description and discovery are likely to be
  diverse
• Several businessEntity structures can be
  published, representing individual subsidiaries
  of a large enterprise or individual participants
  of a marketplace
• representing a more or less coupled community
  their relationships can be made visible in their
  UDDI registrations through uddipublisherAssertion
  
• before making visible the relationship, both
  publishers have to agree that it is valid by
  publishing their own publisherAssertion
• to avoid the possibility that one publisher
  claims a relationship between both business that
  is in fact not reciprocally recognized
• if a publisher is responsible for both business,
  the relationship automatically becomes visible
  after publishing just one assertion

27
UDDI Standard

• UDDI specifies protocols for
• Publishing and searching services registry
• Controlling access to registry
• Distributing and delegating to other registries
• Typical Registry Applications
• Publishing or finding web services (within an
  organization or across organizational boundaries)
  that meet arbitrary criteria
• Determining the security and transport protocols
  supported by a given web service
• Insulating applications (and providing fail-over)
  from failures or changes in invoked services
• Managed by OASIS standards body

28
UDDI API

• UDDI Inquiry API
• to find and retrieve data about business,
  services, contact information
• rather rich selection of searches generic,
  specific and based on binding and relationship
• find
• detail
• analogous to google (list of candidate items)
• UDDI publishing API
• to publish, modify, remove entries from UDDI
  registries
• UDDI Replication API
• at the server-to-server level in the UDDI network
• not considered here

29
find_business
ltfind_business maxRows"nn"
generic"2.0" xmlns""gt
ltfind-qualifiers /gt ltname /gt ltname /gt
ltdiscoveryURLs /gt ltidentifierBag /gt
ltcategoryBag /gt lttModelBag
/gt lt/find_businessgt
ltbusinessListgt ltbusinessInfosgt
ltbusinessInfo businessKey""gt ltnamegt
lt/namegt ltserviceInfosgt
ltserviceInfo serviceKey""gt
ltnamegt lt/namegt lt/serviceInfogt
lt/serviceInfosgt
lt/businessInfogt lt/businessInfosgt lt/busi
nessListgt
ex. search for "microsoft" on IBM's UDDI
(response)
30
find_relatedBusiness
By having at hand the uuid (businessKey) of a
business, we can the find other related business
ltfind_relatedBusiness generic"2.0"
xmlns""gt ltfind-qualifiers /gt
ltbusinessKey /gt ltkeyedReference
/gt lt/find_relatedBusinessgt
31
find_service
ltfind_service businessKey
maxRowsnn generic2.0
xmlnsgt ltfind-qualifiers /gt
ltname /gt ltcategoryBag /gt lttModelBag
/gt lt/find_servicegt
ltserviceListgt ltserviceInfosgt
ltserviceInfo serviceKey
businessKeygt ltnamegt lt/namegt
lt/serviceInfogt ltserviceInfo
serviceKey
businessKeygt ltnamegt lt/namegt
lt/serviceInfogt lt/serviceInfosgt lt/serviceListgt

ex. search for microsoft services on IBM's UDDI
(response)
32
Other Searches

• find_binding and find_tModel
• to get more details on business, services, etc.
• get_businessDetail
• details given the businessKey
• get_businessDetailExt
• as above, but extended (more info are retrieved)
• get_serviceDetail
• details given the serviceKey
• get_bindingDetail
• detail given the bindingKey
• get_tModelDetail
• detail given the tModelKey

33
Publication

• Inquiries are allowed to any user
• Only certain users are allowed to publish
  information on a UDDI registry
• hard for individuals
• (unless they have access to some private UDDI
  registry)
• an authorization is needed from a UDDI provider
• Constraint on UDDI API
• authentication methods are needed
• but SOAP has no such mechanism built-in
• UDDI servers must provide authentication
  mechanisms

34
Authentication

• Any publisher must obtain in advance an
  authentication token from the UDDI server
• To get the token she/he must provide
• a valid user identifier
• a password
• Then, an authInfo structure is returned
• it consists of just one string
• that string should be always used as a parameter
  in every request related to publishing
• When the interaction with the server is concluded
  the token can be thrown away
• next time, fresh token is needed

ltget_authToken generic"2.0" xmlns""
userId"myLogin"
cred"myCredential"/gt
ltauthInfogt897324875245lt/authInfogt
ltdiscard_authToken generic"2.0"
xmlns""gt ltauthInfogt897324875245lt/authInfogt
lt/discard_authTokengt
35
Saving and Deleting

• The most frequent publishing activities are
• data registration (save)
• data removal (delete)
• applicable for any of the main UDDI structures
• business (save_business and delete_business)
• services (save_service and delete_service)
• bindings (save_binding and delete_binding)
• taxonomies (save_tModel and delete_tModel)
• (other operations are also possible)
• ex. publisher assertions
• NOTE UDDI registries can generate uuid
  identifiers automatically when they are not
  specified by the publisher

36
save_business and delete_business
ltsave_business generic"2.0"
xmlns""gt ltauthInfo /gt ltbusinessEntity /gt
ltbusinessEntity /gt lt/save_businessgt
ltdelete_business generic"2.0"
xmlns""gt ltauthInfo /gt ltbusinessKey /gt
ltbusinessKey /gt lt/delete_businessgt
37
save_service and delete_service
ltsave_service generic"2.0"
xmlns""gt ltauthInfo /gt ltbusinessService
/gt ltbusinessService /gt lt/save_servicegt
ltdelete_service generic"2.0"
xmlns""gt ltauthInfo /gt ltserviceKey /gt
ltserviceKey /gt lt/delete_servicegt
38
UDDI Standardization

• Using XML standard in inter/intra business
  communication and data exchange has obvious
  advantages
• like sharing XML Schema
• In WS the problem is more complicated because of
  activities must be described (and not just data)
• WSDL is the actual standard
• Not only that, but activity workflows are to be
  taken into account in many occasions to avoid
  incompatibility problems (like deadlock)
• many proposals WSFL, XLANG, BPEL4WS, BTP, ...
• However, even when standard are not available,
  information can still be processed manually
• business, managers, programmers and individuals
  can exploit UDDI to search for a specific
  business partner or service

39
To Learn More

• http//www.uddi.org/
• Specification, Technical notes, Best practices,
  Case studies, Committee membership
• OASIS (Organization for the Advancement of
  Structured Information Standards)
• Member-led, international, non-profit standards
  consortium
• Focuses on structured information and e-business
  standards
• Members include users, vendors, academics, and
  governments
• The UDDI Business Registry (UBR)
• Public reference implementation of standard
• Directory of publicly available services