PWS Lecture 5. UDDI

Programming Web Services - Lec. 5 UDDI!
DarkSwitch 2010
UDDI (Universal Description Discovery and Integration) by W3School

http://www.w3schools.com/webservices/ws_platform.asp?output=print
UDDI is a directory for storing information about web services

UDDI is a directory of web service interfaces described by WSDL
UDDI communicates via SOAP
UDDI is build into the Microsoft .NET platform
UDDI uses World Wide Web Consortium (W3C) and Internet Engineering Task Force
(IETF) Internet standards such as XML, HTTP, and DNS protocols.
UDDI uses WSDL to describe interface to web service.
Problems that the UDDI specification can help to solve:

• Discover the right business from the millions.
• Definition of how to enable commerce once the preferred business is discovered
• Expanding offering and extending market reach
• Solving customer-driven need to allow for rapid participation in the global internet
economy
UDDI (Universal Description Discovery and Integration) by Wikipedia

http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration
Universal Description, Discovery and Integration is a

• platform-independent,
• XML-based registry
for business worldwide
to list themselves on the Internet.
A UDDI business registration consists of three components:
• White Pages: Address, contact, and known identifiers

• Yellow Pages: Industrial categorizations based on standard taxonomies.
• Green Pages: Technical information about services exposed by the business.
It is designed to be interrogated by Simple Object Access Protocol (SOAP) messages
It provide access to Web Service Description Language (WSDL) documents
The UDDI was integrated into the Web Services Interoperability (WS-I) standard as a
central pillar of services infrastructure.
The UDDI specifications supported a publicly accessible Universal Business Registry in

which a naming system was built around the UDDI-driven service broker.
Definition: UDDI nodes are servers which support the UDDI specification and belong to a
UDDI registry.
Definition: UDDI registry is collection of one or more nodes.
V1.1 Last modification: 29/05/2010! Page 1

Programming Web Services - Lec. 5 UDDI! DarkSwitch 2010
UDDI (Universal Description Discovery and Integration) by Matskin

lecture 5
http://www.ict.kth.se/courses/ID2208/2010/lectures/UDDI2010.pdf
And <<Building Web Services with Java>> Part 1 chapter 6
Note: The teacher hasnʼt followed the structure of the book. Iʼm going to try to follow the
Book first and adding some special chapter when itʼs necessary.
I havenʼt include resume about some information that itʼs in the book but not in the slides
like “Suport for Multi-Registry Environments” or “Publishing a Service Definition with
Multiple Binding”. This happens cause this resume is more focused to the course than the
book.
1. What is Service Discovery? (Slide page 4)

The service discovery process establishes the relationship between the service requestor
and the service provider.
1.1 Role of Service Discovery in a Service-Oriented Architecture
There are three main roles in a Service-oriented Architecture:

• Service provider
• Service registry
• Service requestor
They interact using publish, find and bind operations.
The service provider is the business that provides access to the Web service and
publishes the service description in a service registry.
1.2 Service Discovery Mechanisms (Slide page 5)
Registry mechanism:

There are 4 mechanisms in web services discovery:

• Discovery through email, ftp, CD etc.
• Discovery at the point of offering.
• WSDL repository.
• UDDI
In the first approach, the service provider sends the service description through
email, ftp or CD to the service requestor in accordance to a previously agreed
business partnership. This is a static and a very simple approach.
In the point of offering mechanism, the service description is downloaded from a

formerly known list of services. This is an effective approach in statically settled
business agreements. But it is neither dynamic nor does offer a wide range of
choices for the service requestor.
The WSDL repository is a distributed approach where the service requestor

searches in a wide range of distributed repository of service descriptions. This
approach is much more dynamic.
The UDDI approach provides the concept of point to a service definition. The
providers can define a taxonomical classification of their services, provide a
new technical model, reference an existing technical model which might later be
used by other service providers. The provider can change his service description
without changing the UDDI reference.
The web services use the UDDI approach.
Definition UDDI:

The UDDI allows

• definitions of business and services
• detailed binding information and
• constructs
to support
• referential categorization
• identification, and
• indication of adherence
to technical specifications.
1.3 Service Discovery at Design Time and Runtime
1.4 Scenario Updates
2. UDDI (Universal Description, Discovery and Integration) (Slide page 14 and [from]
page 8)
The purpose of UDDI is to facilitate service discovery both at design time and the
dynamically at runtime.
There are two primary types of UDDI registries:

• Public and
• Private.
The public registry is referred to as the UDDI Business Registry (UBR).

A public registry doesnʼt provide the level of trust that is required to use it.
A private registry can be hosted on the Internet or Intranet.
A private registry usually has a specific purpose.
UDDI defines data structures and APIs for publishing service description in the registry and
for querying the registry.
The UDDI isnʼt a repository.
The UDDI enables dynamic binding.
The UDDI registry Operators provide a web-based user interface.
To use UDDI there are three steps:

1. The application publishes the services and the information relatives in UDDI
2. The client query UDDI for a service
3. The direct interaction will be established between Client and Application cause UDDI.
2.1 Registry requirements (Slide page 13. Not found in the book)
The basic part is componed by:

• A set of data structure specifications for the metadata to be stored in the registry.
• A set of operations for interact (storing, deleting, querying) with the data in registry.
For the description of the data we use metadata. It should have:

• Ownership and containment
• Categorization
• A logical referencing mechanism
And for all the operations them should be composed by:

• Authentication for operation that change information
• Open access for read and
• query operations.
2.2 UDDI Datatypes (Slide page 16)
There are 6 types of UDDI datatypes:

• PublisherAssertion
• BusinessEntity
• BusinessService
• BindingTemplate
• tModel
• Subscription (UDDI 3.0)
Example: Schema of relationship
publisherAssertion ---> businessEntity

" |" " " |
" |" " " |---> businessService
" |" " " |" " |
" |" " " |" " |----> bindingTemplate ---> tModel
" |" " " |
" |" " " |---> businessService
" |" " " " " |
" |" " " " " |---> bindingTemplate ---> tModel
" |" " " " " |
" |" " " " " |---> bindingTemplate ---> tModel
" |
" |-------------------> businessEntity
" " " " |
" " " " |---> businessService
" " " " " " |
" " " " " " |---> bindingTemplate ---> tModel
The publisherAssertion
The publisherAssertion is used to define a relationship between two or more
businessEntity.
The publisherAssertion provides a method to link together two or more business that are
related to each other.
The businessEntity
The businessEntity provides information about a business
The businessEntity can contains references to one or more businessService.
The businessService
The businessService describes the business description for a Web service.
The bindingTemplate

The bindingTemplate describes a technical information necessary to use a particular

WEB service.
Each bindingTemplate contains a reference to one or more tModels.
The tModel
A tModel is used to define the technical specification for a service.
The subscription
The subscription describes a standing request to keep track of changes to the entities
described by the subscription.
Example: businessEntity
The following example presents a businessEntity element that contains one
businessService element. That businessService element contains two bindingTemplate.
<businessEntity businessKey=”5443890-573E-11D8-B936-000629DC0A53”>
! <name>SkatesTown</name>
! <description>UDDI businessEntity for SkatesTown</description>
! <contacts>
! ! <contact useType=”Technical Information”>
! ! ! <description xml:lang=”en”>
! ! ! ! CTIO for technical information</description>
! ! ! <personName> ... </personName>
! ! </contact>
! ! <contact useType=”Sales Information” >

! ! ! <description xml:lang=”en”> VP Sales </description>
! ! ! <personName> ... </personName>
! ! </contact>! !
! </contacts>
! <businessServices>
! ! <businessService
! ! ! serviceKey=”4C379407-3E1E-DC97-B1C7-F68597DA4ADB”
! ! ! businessKey=”55BB30DB-565A-4EF9-BA2E-83118AED644D”>
! ! <name>Purchase Order submission </name>
! ! <description>SkatesTown purchase order submission service. </description>
! ! <bindingTemplates>
! ! ! <bindingTemplate bindingKey=”...someKey...”
! ! ! ! ! serviceKey=”...someKey...”>
! ! ! ! <description>
! ! ! ! ! We based (HTTP) purchase order submission service.
! ! ! ! </description>
! !
! ! ! ! <accessPoint
! ! ! ! ! ! URLType=”http://www.skatestown.com/
! ! ! ! ! ! ! ! Services/poSumbmission.html”>
! ! ! ! </accessPoint>
! ! ! ! <tModelInstanceDetails>
! ! ! ! ! <tModelInstanceInfo tModelKey=”...someKey ...”>
! ! ! ! ! ! <description> HTTP address </description>

! ! ! ! ! </tModelInstanceInfo>
! ! ! ! </tModelInstanceDetails>
! ! ! </bindingTemplate>
! ! ! <bindingTemplate bindingKey=”...someKey...”
! ! ! ! ! serviceKey=”...someKey...”>
! ! ! ! ! SOAP based purchase order submission service
! ! ! !
! ! ! ! <accessPoint
! ! ! ! ! ! URLType=”http://www.skatestown.com/
! ! ! ! ! ! ! ! Services/poSumbmission.html”>
! ! ! ! </accessPoint>
! ! ! ! <tModelInstanceDetails>
! ! ! ! ! <tModelInstanceInfo tModelKey=”...someKey ...”>
! ! ! ! ! ! <description>
! ! ! ! ! ! ! Reference to tModel Web service inter. def.
! ! ! ! ! ! </description>
! ! ! ! ! </tModelInstanceInfo>
! ! ! ! </tModelInstanceDetails>
! ! ! </bindingTemplate>
! ! </bindingTemplates>
! ! ! <categoryBag>
! ! ! ! <keyedReference
! ! ! ! ! keyName=”Sports equipment and accessories”
! ! ! ! ! keyVale=”49221500”
! ! ! ! ! tModelKey=”uuid: ...someKey...” />
! ! ! </categoryBag>
! ! </businessService>
! </businessServices>
! !
! <identifierBag>
! ! <keyedReference keyName=”DUNS” keyValue=”00-111-1111”
! ! ! tModelKey=”uuid: ...someKey...” />
! </identifierBag>
! <categoryBag>
! ! <keyedReference keyName=”sporting and Athletic goods Manufacturing”
! ! ! ! ! keyValue=”33992” tModelKey=”uuid: ...someKey...” />
! ! <keyedReference keyName=”New York”
! ! ! ! ! keyValue=”US-NY” tModelKey=”uuid: ...someKey...” />
! </categoryBag>
</businessEntity>
Example of publisherAssertion:
In this example, a publisherAssertion is used to model the relationship between WeMakeIt
Inc. and its subsidiaries in Asia and Europe.

! <publisherAssertion>
! ! <fromKey>
! ! ! ...WeMakeItKey...
! ! </fromKey>
! ! <toKey>
! ! ! ...WeMakeItAsianKey...
! ! </toKey>
! ! <keyedReference keyName=”subsidiary” keyValue=”parent-child”

! ! ! tModelKey=”...tModelKey of the parent-child relationship system” />
! </publisherAssertion>
The fromKey contains a reference to WeMakeIt. The toKey element references the
businessEntity for WeMakeIt Asia Inc. And the keyedReference indicates the type of
relationship between the two entities.
In this example, we refers that WeMakeIt as the parent of WeMakeItAsian
Then, for those service requestors that user the services provided by WeMakeIt, this
publisher assertion could be used to find another service provider that may provide the
same type of services.
2.2.1 What is a tModel (Slide page 33)
There are two primary uses for UDDI tModels:

1. To define the technical fingerprint for a Web service.
a. The technical fingerprint refers of how to conduct business
2. To define a namespace.
a. The namespace is used to identify business entities or classify business entities,
business services, and tModels.
b. these namespace are used in the identifierBag and categoryBag
Before you can invoke (or bind to ) a Web service, you need to know the serviceʼs
technical details, including information such as the message formats and transport
protocols.
The serviceʼs technical details are supplied in the description of the service.
The serviceʼs technical details can be reused if we separate:

• the abstract reusable service specification from
• the implementation information
To reuse it, there are few steps:

1. Some entity publish the service interface definition as a consortium standard. This
would enable any company in the consortium to reference the service interface
definition.
2. Other entity publish the service implementation details.
3. The service requestor search the UDDI registry to find implementation of the standard
service interface definition.
The service interface definition is the perfect example of tModel.
The tModel is primary used to provide pointers to external technical specifications.

The tModel allows various entities (such as industry groups, standard bodies, and
businesses) to publish abstract service specification that can then be used by other
entities that implement services.
For example, an entity called e-Torus would register its http://www.e-Torus.org/services/

poSubmissiion.wsdl specification as tModel. This tModel would be referenced by all
businesses in the consortium (Such as SkatesTown) that implemented the service
interface. In this way, any service requestor that wanted to find services that conform to
the e-Torus service specification could query the UDDI registry for services that reference
that tModel.
Example: tModel publish by e-Torus
! <tModel tModelKey = “uuid:5492ACB9-8812-6673-EF45-23C421C4A5C1”>

! ! <name>e-Tour purchase order submission service</name>
! ! <description xml:lang=”en”>
! ! ! This is the standard service interface definition for purchase order
! ! ! submission service
! ! </description>
! ! <overviewDoc>
! ! ! <description xml:lang=”en”>
Reference to the WSDL document that contains the e-Tours
standard service interface definition for the purchase order
submission service.
! ! ! </description>
! ! ! <overviewURL>
! ! ! ! http://ww.e-Torus.com/services/poSubmission.wsdl
! ! ! </overviewURL>
! ! </overviewDoc>
! ! <identifierBag>
! ! ! <keyedReference keyName=”DUNS keyValue=”00-222-2222”
! ! ! ! tModelKey=”...tModelKey...”>
! ! </identifierBag>
! ! <categoryBag>
! ! ! <keyedReference keyName=”uddi-org:types” keyValue=”soapSpec”
! ! ! ! ! ! ! ! ! tModelKey=”...tModelKey...” />
! ! ! <keyedReference keyName=”uddi-org:types keyValue=”wsdlSpec”
! ! ! ! ! ! ! ! ! tModelKey=”...tModelKey...”/>
! ! ! <keyedReference keyName=”Sports equipment and accessories”
! ! ! ! ! ! keyValue=”49221500” tModelKey=”...tModelKey”/>
! ! </categoryBag>
! <tModel>
The only change SkatesTown would make is in the bindingTemplate for the SOAP-based
WEb-service binding. The tModelInstanceInfo element must be updated to reference the
e-Torus tModel listed previously:
Example:
" <bindingTemplate bindingKey=”...someBindingKey...”

! ! ! ! ! ! ! ! serviceKey=”...someServiceKey...”>
! ! <description>SOAP based purchase order submission service.</description>
! ! <accessPoint URLType=”http”>
! ! ! http://www.skatestown.com/services/poSubmission
! ! </accessPoint>
! ! <tModelInstanceDetails>
! ! ! <tModelInstanceInfo
! ! ! tModelKey=” uuid:5492ACB9-8812-6673-EF45-23C421C4A5C1”>
! ! ! ! <description>Reference to tModel Web Service instance
! ! ! ! ! definition
! ! ! </tModelInstanceInfo>
! ! </tModelInstanceDetails>
! </bindingTemplate>
!
2.2.1.1 tModel components
• tModelKey: (compulsory) identification of the tModel. This key is assigned by the

custodian upon registration.
• name: (required) contains a descriptive identifier for the tModel. Service consumer can
use name to perform a search for a given tModel
• operator: (opcional). Contains the name of the custodian
• authorizedName: (optional) The name of the entity who published the information
• description: (optional) description of the tModel
• overviewDoc: (optional) used to include additional references. It has description and
overviewURL
• identifierBag: (optional) contains a list of unique identifier associated with the business.
It has keyedReference element.
• categoryBag: (optional) contains a list of industry, product or geographic classifications.
2.2.2 Categorization and Identification of Information (Slide page 40)
UDDI provides a method to perform intelligent searches through taxonomic categorization

and classification.
Each of these taxonomies is identified and referenced using a predefined tModel Key.
Definition: categorization is the process of creating categories.
Definition: classification is the process of assigning objects to these predefined

categories.
2.2.2.1 Using predefined categories.
UDDI defines a set of built-in classification schemes (or taxonomies):
• The North American Industry Classification System (NAICS) for classifying businesses
by industry
• The Universal Standard Product and Services Classification (UNSPSC) for product and
service classifications
• The ISO 3166 standard for geographic location classification.
In order to take advantage of these classification schemes, businesses need to provide

the relevant classification information as they publish their entries. This is done using the
categoryBag. This element contains a set of keyedReference elements, each of which has
three attributes: tModelKey, keyName and keyValue.
The tModelKey attribute is a simple but powerful extension mechanism that acts as a
namespace qualifier for the values specified in the other two attributes.
Example:
" <categoryBag>
" " <keyedReference keyName=”Sporting and Athletic Goods Manufacturing”
" " " keyValue=”33992”
! ! ! tModelKey=”...NAICStModelKey...” />
" " <keyedReference keyName=”New York”
" " " keyValue=”US-NY”
! ! ! tModelKey=”...ISO3166tModelKey...”>
" </categoryBag>
In this example, the business definition for SkatesTown is categorized as a Sporting and
Athletic Goods Manufacturing business with a key value of 33992 using the NAICS
taxonomy.
The business location is defined as New York with a Key value of US-NY using the ISO
3166 geographical categorization scheme.
2.2.2.2 Adding published categories
Other categorization schemes can be added to a UDDI registry.
Example:
" <tModel tModelKey=”...YahootModelKey...”>

" " <name>Yahoo! Business Taxonomy</name>
" " <description xml:lang=”en”>Yahoo! Business Taxonomy</description>
" " <categoryBag>
" " " <keyedReference keyName=”Yahoo! category”
" " " " keyValue=”categorization”
" " " " tModelKey=”...sometModeKey...”>
" " </categoryBag>
" </tModel>
After this tModel is published, another keyedReference element could be added to

the categoryBag within the SkatesTown businessEntry to indicate the Yahoo!
category associated with this business definition.
! <categoryBag>
! ! <keyedReference keyName=”Sporting and Athletic Goods Manufacturing”
! ! ! keyValue=”33992”
! ! ! tModelKey=”...NAICStModelKey...” />
! ! <keyedReference keyName=”New York”
! ! ! keyValue=”US-NY”
! ! ! tModelKey=”...ISO3166tModelKey...”>
! ! <keyedReference keyName=”Yahoo Business Taxonomy”
! ! ! keyValue=”Business_and_Economy/Shopping_and_Services/Sports/
! ! ! ! ! ! ! skateboarding/Deck_andTruck_Makers/”
! ! ! tModelKey=”...YahootModelKey”>
! </categoryBag>
2.2.2.3 Using identifierBag
In addition to specifying categorization information, identification information may also

be provided through the identifierBag. This type of information allows businesses or
tModels to be associated with a declared identification scheme, such as a tax ID or an
industry group ID.
Example:
The D-U-N-S number (www.dnb.com) is defined as a taxonomy tModel.

“A D&B D-U-N-S number is a unique nine-digit sequence recognized as the universal
standard for identifying and keeping track of over 100millions business worldwide”
SkatesTown can identify itself with a D-U-N-S number by using the following
identifierBag.
<identifierBag>
" <keyedReference keyName=”DUNS”
" " keyValue=”00-11-1111”
" " tModelKey=”...D-U-N-StModelKey...” />
</identifierBag>
2.2.2.4. Difference between CategoryBag and IdentifierBag
They are almost the same. The unique difference is where to search or discover them.
When some pre-defined or custom created categories are in categoryBag, then the other
can search (discover) your business under some specified categories.
When some pre-defined or custom created keyedReference are in identifierBag, then the
other can search(discover) your business with a specific identifier like D-U-N-S number.
2.2.2.5 Using self-defined registry
With identifierBag we can reference some additional scheme including keyedReference in

the identifierBag.
Example:
Businesses in the e-Torus marketplace can identify themselves using the e-Torus
identification tModel as a namespace.

<tModel tModelKey=”...eTorustModelKey..”>
! <name>e-Torus Registry</name>
! <description xml:lang=”en”>e-Torus Registry Number </description>
! <categoryBag>
! ! <keyedReference
! ! ! keyName=”Unique identifiers for member companies”
! ! ! keyValue=”identifier”
! ! ! tModelKey=”...someKey...”>
! ! <categoryBag>
! </tModel>
Then, to reference this identification scheme, the identifierBag must be updated to

include an additional keyedReference.
<identifierBag>
" <keyedReference keyName=”DUNS”
" " keyValue=”00-11-1111”
" " tModelKey=”...D-U-N-StModelKey...” />
" <keyedReference keyName=”eTorus Registry” keyValue=”12345”
" " tModelKey=”...eTorustModelKey...”>
</identifierBag>
2.2.3 Business Entity (Slide page 25 and page 15)
The businessEntity is used to represent information about an entity or a business.
The businessEntity is a container for the businessService.
Business entity information is conceptually divided into three categories.

• White Page: Contains general contact information about the entity.
" The SkateTown entry would contains its name, address, and contact information
such as phone, fax, and email.
• Yellow Page: Contains classification information aout the types and location of the
service that the business entity offers.
" The SkateTown could be its classification as a sports equipment manufacturer and
retailer, and more specifically as a skateboard manufacture and retailer.
• Green Page: Contains information about the details of how to invoke the offered
services.
" For example, if SkatesTown were to offer its catalog online, its green pages entry
would have a reference to its catalog URL.
The example was showed in the UDDI Datatype.
2.2.4 Business Service (Slide page 28)
The businessService is the root element for describing a logical business service.
On our example, the logical business service could be the services provided by
SkatesTown.

the businessService entry must contain a direct reference to the businessEntry entry that
itʼs associated with. This is done using the businessKey attribute on the businessService
element.
The components of businessService are:

• serviceKey: (compulsory) contains a unique, hexadecimal identifier for a service.
• businessKey: (compulsory) references the businessKey of the businessEntity that itʼs
associated.
• name: (compulsory) contains the name(s) of a service
• description: (optional) brief description of the servie
• bindingTemplate (compulsory) contains technical information about a service
• categoryBag (optional) contains a list of industry, product or geographic classification.
Be careful cause itʼs not the categoryBag of the businessEntity.
2.2.5 Binding Template (Slide page 30)
The bindingTemplate contains the technical information necessary to invoke a specific

Web service.
The same logical service may have more than one type of binding. (SOAP-based HTTP
binding, HTTP browser binding, email SMTP binding...)
Each of these bindings is described in a separate bindingTemplate.
This binding template generally has a combination of

• access point information and
• tModel reference.
There are many examples in this document.
The components of the bindingTemplate are:
• bindingKey: (compulsory) contains a unique identifier. This unique identifier is assigned

by the operator node upon registration.
• serviceKey: (compulsory) references the serviceKey of the service which contains the
bindingTemplate
• description: (optional) contains brief descriptions of Web service
• accessPoint: (compulsory or optional) Specify where to access Web services.
" If hostingRedirector is not specified, this attribute will be compulsory.
• hostingRedirector: (compulsory or optional) contains a link to another bindingTemplate
structure. The other bindingTemplate structure has to contains the description of a
particular service.
" If accessPoint is not specified, this attribute will be compulsory
• tModelInstanceDetails: A list of one or more tModelInstanceInfo. The “technical
fingerprint” of a Web service is formed with the collection of tModelKey attributes found
here. The “technical fingerprint” can be used to identify compatible services.
2.2.6 Publisher Assertion (Slide page 23)
The publisherAssertion is used to associate a pair of existing business (businessEntity)
The structure are simple:

• fromKey: key of the first element

• toKey: key of the second element
• keyedReference: type of the relationship
• keyName: name of the key
• keyValue: The type of the relationship.
• tModelKey: reference to relation type system
There are three types of relationship:

• parent-child: the first element is the parent of the second element
• peer-peer: the first element is the peer of the second element
• identity: The first element is the same organization as the second element.
An assertion isnʼt complete until the publishers of both businessEntity entries have made
the sam assertion.
Example of parent-child relationship:
! <publisherAssertion>
! ! <fromKey>
! ! ! ...WeMakeItKey...
! ! </fromKey>
! ! <toKey>
! ! ! ...WeMakeItAsianKey...
! ! </toKey>
! ! <keyedReference keyName=”subsidiary” keyValue=”parent-child”

! ! ! ! tModelKey=”...tModelKey of parent-child relationship system” />
! </publisherAssertion>
For process publisher assertions, five APIs are used:

• add_publisherAssertions: Add one or MORE publisherAssertions
• delete_publisherAssertions: delete one or MORE publisherAssertions
• get_publisherAssertions: Get the full list of publisherAssertions
• get_assertionStatusReport: Determinate the status of current and outstanding
assertions
• set_publisherAssertions: Add new assertions or updates existing assertions. The call
operates on the ENTIRE set of assertions for a publisher.
2.3 Using a UDDI Registry (Slide page 45)
A UDDI registry is itself an instance of a Web service.
Entries in the registry can be published and queried using a SOAP-based interface.
With the SOAP-based interface, the SOAP-based message is used for all publish and
inquiry operations.
There are three main types of users:

• Service providers
• Service requesters
• Other registries

2.3.1 Publishing Service Description (Slide page 46)
Most UDDI registries requiere you to register before you can publish any UDDI entries.
The registration process provides you with a publisher account.
With the publisher account, you can create entries in the registry.
Entries in the registry are owned by the publisher who created them, and only the owner
can update or delete a registry entry.
The UDDI publication APIs provide support for

• creating
• updating and
• deleting
the elements of UDDI. They are:
• businessEntity
• businessService
• bidingTemplate
• tModel and
• publisherAssertion
To use a publication API call you must first obtain an authentication token using the
get_authToken API call.
The authentication token represent an active session with the registry.
Example of get_authToke:
! <get_authToken generic=”2.0” xmlns=”urn:uddi-org:api_v2”

! ! userId=”userid”
! ! cred=”password” />
When an authentication token is no loger needed, you can use the discard_authToken
messae to inform that registry that it can be discard.
UDDI provides 2 basic types of API operations applied to basic components:

• UDDI Inquiry API
• Find registry entries (find_*)
• Provide details (get_*)
• UDDI Publisher API
• Add and modify entries (save_*)
• delete entries (delete_*)
Table of main API that must be understood:
Business Service Binding tModel
Save/ save_business save_service save_binding save_tModel

Update
Delete delete_business delete_service delete_binding delete_tModel

Business Service Binding tModel
Find find_business find_service find_binding find_tModel
GetDetail get_businessDetail get_serviceDetail get_bindingDetail get_tModelDetail
For the find operations, we can set some criteria like name, identifierBag, categoryBag or
tModelBag.
Other general purpose operations in the UDDI API are:

• UDDI Custody and Ownership Transfer API:
• transfer_entities: Transfer the custody of information among themselves
• transfer_custody: Transfer ownership of these structures form one to another
• UDDI Subscription API: Used to monitoring the changes in the registry
• save_subscriptions
• get_subscriptions
• get_subscriptionResults
• delete_subscription
• UDDI Replication API: supports replication of information between registries that
different registres can be kept synchronized
The most complete call is get_registerInfo. This message is used to obtain a COMPLETE
LIST of businessEntity and tModel entries.
Example of save (publish) message of an entity:
<save_business generic=”2.0” xmlns=”urn_uddi-org_api_v2”>

" <authInfo> [authInfo value] </authInfo>
! <businessEntity businessKey=”5443890-573E-11D8-B936-000629DC0A53”>
! ! <name>SkatesTown</name>
! ! <description>UDDI businessEntity for SkatesTown</description>
! ! <contacts>
! ! ! ....
! ! </contacts>
! ! <businessServices>
! ! ! <businessService
! ! ! ! serviceKey=”4C379407-3E1E-DC97-B1C7-F68597DA4ADB”
! ! ! ! businessKey=”55BB30DB-565A-4EF9-BA2E-83118AED644D”>
! ! ! ! <name>Purchase Order submission </name>
! ! ! ! ! SkatesTown purchase order submission service.
! ! ! ! <bindingTemplate>
! ! ! ! ! ....
! ! ! ! </bindingTemplate>
! ! ! ! <categoryBag>
! ! ! ! ! <keyedReference
! ! ! ! ! ! keyName=”Sports equipment and accessories”
! ! ! ! ! ! keyVale=”49221500”
! ! ! ! ! ! tModelKey=”uuid: ...someKey...” />
! ! ! ! </categoryBag>
! ! ! </businessService>
! ! </businessServices>
! !
! ! <identifierBag>
! ! ! <keyedReference keyName=”DUNS” keyValue=”00-111-1111”
! ! ! ! ! ! ! ! tModelKey=”uuid: ...someKey...” />
! ! </identifierBag>
! ! <categoryBag>
! ! ! <keyedReference
! ! ! ! ! keyName=”sporting and Athletic goods Manufacturing”
! ! ! ! ! keyValue=”33992” tModelKey=”uuid: ...someKey...” />
! ! ! <keyedReference keyName=”New York”
! ! ! ! ! keyValue=”US-NY” tModelKey=”uuid: ...someKey...” />
! ! </categoryBag>
! </businessEntity>
</save_business>
Example of find_business by name
" <find_business generic=”2.0” maxRows=”2” xmlns=”urn:uddi-org:api_v2”>

! ! <findQualifiers>
! ! ! <findQualifier> SortByDateDesc </findQualifier>
! ! <findQualifiers>
! ! <name> S </name>
! <find_business>
The possible message returned could be:
" <businessList generic=”2.0” operator=”UDDIOperator” truncated=”false”

! ! ! ! ! ! ! ! ! xmlns=”urn:uddi-org:api_v2”>
! ! <businessInfos>
! ! ! <businessInfo businessKEy=”...someKey...”>
! ! ! ! <name>SEMC</name>
! ! ! ! ! sport Equipment Manufacturing Consortium
! ! ! ! <serviceInfos>
! ! ! ! ! ....
! ! ! ! </serviceInfos>
! ! ! </businessInfo>
! ! ! ...
! ! </businessInfos>
! </businessList>
Example of get_businessDetail:
! <?xml version=”1.0” encoding=”UTF-8”?>

! <get_businessDetail generic=”2.0” xmlns=”urn:uddi-org:api_v2”>
! ! <businessKey> ...someBusinessKey...
! ! </businessKey>
! </get_businessDetail>
2.3.2 Finding Service Description (Slide page 57 to 63, page 62)

Added to Publishing service Description.
2.4 Whatʼs new in UDDI Version 3.0
2.4.1 Policy
2.4.2 Security
2.4.3. Support for Multi-Registry Environments
2.4.4 Subscription (Slide page 66)
There are two types of subscriptions:

• Entity-based: It notifies the subscriber when one or more entities have changed.
• query-based: The subscriber is notified when the result set for the query changes
within a specified time period.
2.4.5 Publisher-Assigned Keys (Slide page 21)
The key is used to identify the entity.
There is method to move entities between UDDI registries without having to create new
keys.
The keys has the structure:

“schema:value”
where schema is always uddi
There are three types of keys:

• uuidKey: contains a UDDI key.
" " For example: udid:4CD7E4BC-426D-9936-443EAAC8AE23
• domainKey: contains a valid hostname. For example: uddi:www.SkatesTown.com
• derivedKey: contains UDDI key with a key-specific string appended to it.
" " For example: uddi:www.SkatesTown.com:PriceCheck,
" " uddi:www.SkatesTown.com:PurchaseOrderSubmission
2.4.5.1 Private UDDI keys
The conceptual space of uddiKeys is divided into non-overlapping, hierarchically arranged

partitions.
Each partition can be associated with a publisher.
Initially, the registry itself has authority for the root partition of the hierarchy.
Only the publisher associated with a particular partition is given the authority to assign
keys within the partition.
The publisher with authority for a given partition may designate any publisher it chooses
for any partition directly below the partition it manages, provided it has not already
designated a publisher to that partition.
The publisher with authority for a partition may transfer its authority to another publisher.
Each node of a registry is a generator of keys.
2.5 Using WSDL with UDDI (Just for your interes)
The service description information defined in WSDL is complementary to the information

found in a UDDI registry.
UDDI has no direct support for WSDL or any other service description mechanism.
2.5.1 How to Publish WSDL-Based Service Description (just for your interes)
Documents which describe how to publish WSDL-based service description in a UDDI
registry:
• Using WSDL in a UDDI Registry 1.08 - http://www.oasis-open.org/committees/uddi-spec/

doc/bp/uddi-spec-tc-bp-using-wsdl-v108-20021110.pdf
• Using WSDL in a UDDI Registry version 2.0 - http://www.oasis-open.org/committees/
uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm
2.5.2 Mapping from WSDL to UDDI (Slide page 68)

This figure show the major WSDL elements map in to UDDI elements.
Since the service interface represents a reusable definition of a service, a reference to it is

published in a UDDI registry as a tModel.
If the service interface definition contains more than one binding element, the
reference to the service interface may include a pointer to a specifica WSDL binding
element.
The service implementation describes a instance of a service, and each instance is

defined using a WSDL service element. Each service element in a service
implementation document corresponds to a UDDI businessService element.
In particular, the Web service location (address) listed in a WSDL port element must be
the same as the value in the UDDI accessPoint element.
2.5.3 How to Publish the Purchase Order Submission Service
2.5.4 Publishing a SErvice Definition with Multiple Binding
3. Other Service Discovery Methods
3.1 WS-Inspection (Slide page 73)
The Web Services Inspection Language (WS-Inspection) defines a method to discover

service descriptions at the service providerʼs point of offering.
The WS-Inspection defines how a client application can locate Web services descriptions
that reside on a particular Web server.
The WS-Inspection specification defines two primary functions:

• The XML format used to list references to existing Web services.
• The set of conventions for locating WS-Inspection documents on a Web site.
WS-Inspection requires you to know the location of a service provider so that you can
inspect its Web site.
If the developer knows the Web server on which a Web server resides, the developer can
use WS-Inspection to find WSDL document.
If the developer doesnʼt know the Web server, she/he would use UDDI to locate the
service.
3.2 WS-ServiceGroup (Slide page 74)
Definition: WS-Resources is a Web Service that is associated with a stateful resource.
Ws-ServiceGroup defines a method for grouping together Web services and WS-
Resources.
A Web service that belongs to a ServiceGroup is a Member.

Each member is associated with the Service Group through a ServiceGroupEntry.
Members of a ServiceGroup must conform to the membership rules and constraints for the
ServiceGroup.
Then the meaningful queries can be processed to locate entries in the ServiceGroup.
The concept of a ServiceGroup could be used to define an aggregation of Web services

that form a basic service registry
The queries that are processed against a ServiceGroup could be used to discover Web
services that are defined as Members of the ServiceGroup.

PWS Lecture 5. UDDI

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PWS Lecture 5. UDDI

Transféré par

Droits d'auteur :

Formats disponibles

Programming Web Services - Lec. 5 UDDI!

UDDI (Universal Description Discovery and Integration) by W3School

UDDI is a directory for storing information about web services

UDDI uses WSDL to describe interface to web service.

Problems that the UDDI specification can help to solve:

UDDI (Universal Description Discovery and Integration) by Wikipedia

Universal Description, Discovery and Integration is a

A UDDI business registration consists of three components:

• White Pages: Address, contact, and known identifiers

It is designed to be interrogated by Simple Object Access Protocol (SOAP) messages

It provide access to Web Service Description Language (WSDL) documents

The UDDI specifications supported a publicly accessible Universal Business Registry in

Definition: UDDI registry is collection of one or more nodes.

V1.1 Last modification: 29/05/2010! Page 1

UDDI (Universal Description Discovery and Integration) by Matskin

1. What is Service Discovery? (Slide page 4)

1.1 Role of Service Discovery in a Service-Oriented Architecture

There are three main roles in a Service-oriented Architecture:

They interact using publish, find and bind operations.

1.2 Service Discovery Mechanisms (Slide page 5)

V1.1 Last modification: 29/05/2010! Page 2

There are 4 mechanisms in web services discovery:

In the point of offering mechanism, the service description is downloaded from a

The WSDL repository is a distributed approach where the service requestor

The web services use the UDDI approach.

V1.1 Last modification: 29/05/2010! Page 3

The UDDI allows

1.3 Service Discovery at Design Time and Runtime

1.4 Scenario Updates

There are two primary types of UDDI registries:

The public registry is referred to as the UDDI Business Registry (UBR).

The UDDI isnʼt a repository.

The UDDI enables dynamic binding.

The UDDI registry Operators provide a web-based user interface.

To use UDDI there are three steps:

The basic part is componed by:

For the description of the data we use metadata. It should have:

• A logical referencing mechanism

And for all the operations them should be composed by:

2.2 UDDI Datatypes (Slide page 16)

There are 6 types of UDDI datatypes:

Example: Schema of relationship

publisherAssertion ---> businessEntity

V1.1 Last modification: 29/05/2010! Page 5

The bindingTemplate describes a technical information necessary to use a particular

! ! <contact useType=”Sales Information” >

! ! ! ! ! ! <description> HTTP address </description>

V1.1 Last modification: 29/05/2010! Page 7

! ! <keyedReference keyName=”subsidiary” keyValue=”parent-child”

2.2.1 What is a tModel (Slide page 33)

There are two primary uses for UDDI tModels:

The serviceʼs technical details can be reused if we separate:

To reuse it, there are few steps:

The service interface definition is the perfect example of tModel.

The tModel is primary used to provide pointers to external technical specifications.

For example, an entity called e-Torus would register its http://www.e-Torus.org/services/

Example: tModel publish by e-Torus

! <tModel tModelKey = “uuid:5492ACB9-8812-6673-EF45-23C421C4A5C1”>

" <bindingTemplate bindingKey=”...someBindingKey...”

• tModelKey: (compulsory) identification of the tModel. This key is assigned by the

2.2.2 Categorization and Identification of Information (Slide page 40)

UDDI provides a method to perform intelligent searches through taxonomic categorization

Definition: categorization is the process of creating categories.