UDR :UDDI Done Right

1
UDR UDDI Done Right

• Waqar Mohsin
• The Logic Group, CS Department
• 25 February, 2003

2
Highlights of the Talk

• Introduction to UDDI
• Whats wrong with UDDI
• Suggestions

3
What is UDDI ?

• Technical specification for building a
  distributed directory of businesses and web
  services
• Enables companies to publish and find web
  services
• Announced by Ariba, IBM and Microsoft in
  September 2000
• July 2002 Version 3 released

4
UDDI Architecture

• UDDI data model
• An XML schema for describing businesses and web
  services
• UDDI API
• A SOAP based API for searching and publishing
  businesses and web services
• UDDI Business Registry
• An operator site that implements the UDDI data
  model and API

5
How UDDI works
UDDI Business Registry
Services Type Registrations
BusinessRegistrations
UDDI assigns a universally unique identifier
(UUID) to each registry record
6
Registry Data
Business Name Description Contact
Info Identifiers (external taxonomy)
WhitePages
businessEntity
YellowPages
businessService
A list of web services offered
GreenPages
bindingTemplate
- Address for invoking the service - How to
invoke (eg. SOAP)
Service Type Registrations
tModel (technical model)
Pointer to an external specification of the web
service (eg. WSDL)
7
UDDI Data Model
8
UDDI API

• Inquiry API

• Publishing API

• find_business
• find_service
• find_binding
• find_tmodel

• save_business
• save_service
• save_binding
• save_tmodel

• delete_business
• delete_service
• delete_binding
• delete_tmodel

• get_businessDetail
• get_serviceDetail
• get_bindingDetail
• get_tmodelDetail

• get_authtoken
• discard_authtoken

9
Registry Nodes Operation

• Peer operator nodes
• A business can register with any node
• Registrations replicated on a daily basis
• Operates like DNS logically centralized,
  physically distributed

10
Whats wrong with UDDI ?

• Thoughts and suggestions

11
1. Too much indirection

• Name - businessKey - serviceKey - bindingKey
  - tModelKey- WSDL link
• serviceKey and bindingKey of not much use
• get_xxx calls only accept UUID keys
• Extra level of indirection to map business name
  to businessKey
• Redundancy
• bindingTemplate already contained in WSDL !
• Complex design
• No convincing argument for multiple tModels for a
  specific binding

12
2. Use of a taxonomy optional

• If a business or web service does not identify
  itself with a taxonomy/ontology, you need to know
  its UUIDs to find out more about it !!!
• find_xxx API almost useless
• find_business does the real search
• find_tmodel alone doesnt provide the complete
  picture
• Essentially need to drill down from the top
• Yahoo minus the pictures
• No clear argument for avoiding the use of
  semantic web technologies to solve a problem that
  is clearly within their domain

13
3. Use of UUIDs

• Most keys are internal names burdened with being
  persistently unique in space and time across the
  universe
• How big should the UUID be ?
• Size vs efficiency
• Extra level of indirection
• Name - UUID - Number
• Need a single assigning authority
• Introduce impurities ?
• Same problems as with IP addresses
• When a service is changed, at what point is it a
  different service new UUID ?

14
Suggestions

• Use URIs instead of UUIDs
• Simplify the UDDI data model
• Use a distributed registry model

15
1. Use URIs vs UUIDs

• Use URIs to identify entries in the registry
• Leverage off the DNS
• No need to reinvent the wheel !
• Service providers can organize their URIs using
  any scheme they like
• Flat, vertical, hierarchical
• Much better scaling and performance
• UUID assignment and management complex

16
Example
bf-002035229c64
businessKey"ba744ed0-3aaf-11d5-80dc-002035229c64"
XMethods Delayed Stock Quotes
20-minute delayed stock
quotes
bf-002035229c64
bindingKey"d594a970-3e16-11d5-98bf-002035229c64"
SOAP binding for delayed
stock quotes service
http//services.xmeth
ods.net80/soap

11d5-98bf-002035229c64" /


ockQuote.xml businessKeyxmetho
ds.net" XMethods Delayed Stock
Quotes 20-minute delayed
stock quotes
StockQuote.xml
bindingKeyxmethods.net/SimpleStockQuote/SoapBind
ing.xml" SOAP binding for
delayed stock quotes service
http//services.xmeth
ods.net80/soap

xmethods.net/SimpleStockQuote/tModel2.xml" /


17
2. Simplify the UDDI data model

• Specify WSDL instead of bindingTemplate
• Standard for describing a web service
• Be practical email, fax, telephone based
  services dont have much of a chance !
• Pre/post conditions go in WSDL
• Extend findQualifiers to include these
• One registry documet per business
• Merge white/yellow pages
• WSDL is the green page !
• Use tModels only for identifierBag and categoryBag

18
Example

XMethods Web
services resource site
...
. . . . . .

XMethods Barnes and Noble
Quote Returns book
price from BN given ISBN
key"xmethods.net/PacBellSMS.wsdl"
XMethods Pacific Bell SMS Service
Sends a text message to PacBell
SMS network
uote.wsdl" XMethods Delayed Stock
Quotes 20-minute
delayed stock quotes
. . .
sEntity
19
3. Use a distributed registry model

• The registry nodes should only cache information
  that actually lives in a URI-addressable registry
  document on the web site of the relevant
  organization
• Amazon should own Amazons registry document and
  should update it on their website when they feel
  like it
• Update a UDDI registry node by publishing the URI
  only
• Registry node then updates its cache by pulling
  the data from the URI (pull vs push)
• Use HTTP for publishing (both ways)
• HTTP provides proven authentication and access
  control
• UDDI Publishing API no longer needed
• Solves UDDI SOAP based security concerns

20
What do we gain at the end ?

• Easy inspection just point browser at URI
• Ease of maintenance
• One local XML document can use any editor
• Update as frequently as you like
• Simplified registry node design
• Simple data model
• Much less data to replicate across nodes
• Much better performance and scalability
• Metadata could be associated with a registry
  entry using RDF
• Fits nicely with the RDF Everything has a URI
  model