universal description discovery and integration · the uddi model • a uddi information model is...

Universal Description Discovery and Integration

Service Registries

Thursday, March 22, 12

• Universal Description Discovery and Integration

– Industry-wide initiative supporting web services

– Developed on industry standards (XML, HTTP, TCP/IP, SOAP)

– Applies equally to XML and non-XML web services

• Originally, UDDI was conceived as an “Universal Business Registry” similar to search engines (e.g., Google)

• Triggered significant activity around advanced and complex scenarios(Semantic Web, dynamic binding to partners, automatic partner selection at runtime, etc.)

• Now more pragmatic

• name and directory service for Web services and mostly used in constrained environments (internally within a company or among a predefined set of business partners)

What is UDDI?


Provide a standards-based profile for all electronic services that are

provided. Includes web sites, other electronic resources

An organization needs to create 400 electronic relationships with

partners, each with its own standards and protocols

BroaderB2B

A small business wants to be “plugged in” to every marketplace

in the world, but doesn’t know how

SmarterSearch

A B2B marketplace cannot get catalog data for relevant suppliers

in its industry, along with connections to shippers, insurers,

etc.

Easier Aggregation

Describe Services

Discover Services

IntegrateThem

Together

Web ServiceVisibility

Publish for Accessibility

What problems does UDDI solve?


• Find Web services implementations that are based on a common abstract interface definition.

• Find Web services providers that are classified according to a known classification scheme or identifier system.

• Determine the security and transport protocols supported by a given Web service

• Issue a search for services based on a general keyword

• Cache the technical information about a Web service and then update that information at run-time.

Ways to use UDDI


• A node is a UDDI server that supports at least the minimum set of functionality defined in the specification• At least one API• It is a member of exactly one UDDI registry

• A registry is composed of one or more nodes and performs the complete set of functionality as defined in the specification

• Affiliated Registries are individual UDDI registries that implement policy-based sharing of information among them• They share a common namespace for UDDI keys that uniquely identify data

records

Main architectural components


• Main features– Publishing information about a service to a registry (UDDI Publication)– Searching a UDDI registry for information about a service (UDDI Inquiry)

• Groups of registry– Replicating and transferring custody of data about a service (UDDI Custody

Transfer)– Registration key generation and management (UDDI Replication)– Registration subscription (UDDI Subscription)– Security and authorization (UDDI Security)

Essential interfaces


• Service providers register precise information about themselves

• basic information

• categorization

• technical data

Three kinds of information


White Pages

• White pages

• Basic information about the Company and its business.

• Basic contact information including business name, address, contact phone number etc.

• Unique identifiers for the company tax IDs. This information allows others to discover your web service based upon your business identification.


Yellow Pages

• Yellow pages

• This has more details about the company, and includes descriptions of the kind of electronic capabilities the company can offer to anyone who wants to do business with it.

• It uses commonly accepted industrial categorization schemes, industry codes, product codes, business identification codes and the like to make it easier for companies to search through the listings and find exactly what they want.


Green Pages

• Green pages

• The various interfaces

• The URL locations

• Discovery information and similar data required to find and run the Web service.


UDDI data structure

• Four core entity types:

– businessEntity

– businessService

– bindingTemplate

– tModel

<businessEntity>name, contact, identificationdescription, category

<businessService> (1..n) name description

<bindingTemplate>

<tModel>NameDescriptionURL pointer to specification

<businessEntity>name, contact, identificationdescription, category

<businessService> (1..n) name description

<bindingTemplate>

reference

reusable entity outside the hierarchyThursday, March 22, 12

The UDDI model

• A UDDI information model is composed of instances of the following core entity types:

• businessEntity: Describes a business or other organization that typically provides Web services.

• businessService: Describes a collection of related Web services offered by an organization described by a businessEntity.

• bindingTemplate: Describes the technical information necessary to use a particular Web service.

• tModel: Describes a "technical model" representing a reusable concept, such as a Web service type, a protocol used by Web services, or a category system.

• Non-core entity types

• publisherAssertion: Describes, in the view of one businessEntity, the relationship that the businessEntity has with another businessEntity.

• subscription: Describes a standing request to keep track of changes to the entities described by the subscription.


• Provides information, including identifiers (in an identifier bag), contact information etc… (white-pages)

• Includes one or more businessService (service entity) elements that represent the services it provides

• Specifies a categoryBag to categorize the business (yellow-pages)

• A unique key identifies each businessEntity

businessEntity


businessEntity example

<businessEntity businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"

operator="http://www.ibm.com" authorizedName="John Doe"> <name>Acme Company</name> <description> We create cool Web services </description> <contacts> <contact useType="general info"> <description>General Information </description> <personName>John Doe</personName> <phone>(123) 123-1234</phone> <email>[email protected]</email> </contact> </contacts>

<businessServices> ... </businessServices> <identifierBag> <keyedReference tModelKey="UUID:8609C81E-EE1F-4D5A-B202-3EB13AD01823" name="D-U-N-S" value="123456789" /> </identifierBag> <categoryBag> <keyedReferencetModelKey="UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2" name="NAICS" value="111336" /> </categoryBag></businessEntity>


• Includes information such as name, description (white-pages)

• Uniquely identified by a service key

• Specifies a categoryBag to categorize the service (yellow-pages)

• Contains a list of bindingTemplates which in turn contains tModelInstanceDetails encoding the technical service information (green-pages)

• Includes reference to its host with a businessKey

businessService


businessService example

<businessService serviceKey="uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A" businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"> <name>Hello World Web Service</name> <description>A friendly Web service</description> <bindingTemplates> ... </bindingTemplates> <categoryBag /></businessService


bindingTemplate

• Binding templates are the technical descriptions of the web services represented by the business service structure.

• A single business service may have multiple binding templates. The binding template represents the actual implementation of the web service.


bindingTemplate Example<bindingTemplate serviceKey=”uuid:D6F1B765- BDB3-4837-828D-8284301E5A2A”

bindingKey=”uuid: C0E6D5A8-C446-4f01-99DA-70E212685A40"> <description>Hello World SOAP Binding</description> <accessPoint URLType="http"> http://localhost:8080/helloworld </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey="uuid:EB1B645F-CF2F-491f-811A-4868705F5904"> <instanceDetails> <overviewDoc> <description> references the description of the WSDL service definition </description> <overviewURL> http://localhost/helloworld?wsdl </overviewURL> </overviewDoc> </instanceDetails> </tModelInstanceInfo> </tModelInstanceDetails></bindingTemplate>


http://localhost/helloworld?wsdl

http://localhost/helloworld?wsdl

tModel

• A tModel is a way of describing the various business, service, and template structures stored within the UDDI registry.

• Any abstract concept can be registered as a tModel.

• For instance, if you define a new WSDL port type, you can define a tModel that represents that port type within UDDI.

• Then, you can specify that a given business service implements that port type by associating the tModel with one of that business service's binding templates.


tModel Example

<tModel tModelKey=”uudi:xyz987...” operator=”htpp://www.ibm.com” authorizedName=”John Doe”> <name>HelloWorldInterface Port Type</name> <description> An interface for a friendly Web service </description> <overviewDoc> <overviewURL> http://localhost/helloworld?wsdl </overviewURL> </overviewDoc> </tModel>


UDDI and WSDL relationship


universal description discovery and integration · the uddi model • a uddi information model is...

Documents