Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 WS Technologies I UDDI Roberto Bruni Dipartimento di Informatica Università di Pisa Models and Languages for Coordination and Orchestration IMT- Institutions.

Similar presentations


Presentation on theme: "1 WS Technologies I UDDI Roberto Bruni Dipartimento di Informatica Università di Pisa Models and Languages for Coordination and Orchestration IMT- Institutions."— Presentation transcript:

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

2 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 2 Models and Languages for Coordination and Orchestration Contents Web Services, informally SOAP: a protocol for WS UDDI registries

3 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 3 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 4 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 5 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 6 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 7 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 8 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 9 Models and Languages for Coordination and Orchestration 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 Transport protocols (HTTP, HTTPS, …) XML SOAP UDDI

10 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 10 Models and Languages for Coordination and Orchestration UDDI v3 History VersionYearGoal 1.02000 public registry foundation 2.02003 Web Services alignment and extensible taxonomies 3.02004 Flexible and secure registry interaction models

11 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 11 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 12 Models and Languages for Coordination and Orchestration A Closer Look at the UDDI 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 13 Models and Languages for Coordination and Orchestration White pages Tailored to human beings (instead of applications) useful reference in the initial phase of commercial partnerships Main data structure uddi:businessEntity contains contacts (description, addresses,...), and other information related to a business entity since not all kinds of information can be foreseen, a special element uddi:identifierBag can be used to list generic name-value pairs DUNS code (Dun & Bradstreet number)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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 14 Models and Languages for Coordination and Orchestration human readable (non-blank) offered services uuid Sketch of businessEntity Schema <element ref="description" minOccurs="0" maxOccurs="unbounded" />

15 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 15 Models and Languages for Coordination and Orchestration 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 uddi:categoryBag of uddi:businessEntity 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 16 Models and Languages for Coordination and Orchestration human readable (non-blank) technical data associated business uuid Sketch of businessService Schema <element ref="description" minOccurs="0" maxOccurs="unbounded" />

17 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 17 Models and Languages for Coordination and Orchestration Green pages Technical information for service/software developers Two main structures uddi:bindingTemplate access point (it is fundamental at runtime) technical schema including a set of tModel keys, implemented methods, and required parameters uddi:tModel “t” as “type” (also “technical”) “Model” as “model” used to assign "labels" to taxonomies

18 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 18 Models and Languages for Coordination and Orchestration technical specification associated service uuid Sketch of bindingTemplate Schema <element ref="description" minOccurs="0" maxOccurs="unbounded" />

19 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 19 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 20 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 21 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 22 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 23 Models and Languages for Coordination and Orchestration technical specification (including.wsdl URL) uuid Sketch of tModel Schema <element ref="description" minOccurs="0" maxOccurs="unbounded" />

24 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 24 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 25 Models and Languages for Coordination and Orchestration UDDI Data Model

26 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 26 Models and Languages for Coordination and Orchestration 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 uddi:publisherAssertion 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 publisherAssertion

27 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 27 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 28 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 29 Models and Languages for Coordination and Orchestration find_business <find_business [maxRows="nn"] generic="2.0" xmlns="…"> [ ] [ [ ] … ] [ ] … … … … ex. search for "microsoft"search for "microsoft" on IBM's UDDI on IBM's UDDI (response)response

30 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 30 Models and Languages for Coordination and Orchestration find_relatedBusiness <find_relatedBusiness generic="2.0" xmlns="…"> [ ] [ ] By having at hand the uuid (businessKey) of a business, we can the find other related business

31 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 31 Models and Languages for Coordination and Orchestration find_service <find_service businessKey=“…” [maxRows=“nn”] generic=“2.0” xmlns=“…”> [ ] <serviceInfo serviceKey=“…” businessKey=“…”> … … <serviceInfo serviceKey=“…” businessKey=“…”> … ex. search for microsoft servicessearch for microsoft services on IBM's UDDI on IBM's UDDI (response)response

32 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 32 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 33 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 34 Models and Languages for Coordination and Orchestration 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 <get_authToken generic="2.0" xmlns="…" userId="myLogin" cred="myCredential"/> 897324875245 <discard_authToken generic="2.0" xmlns="…"> 897324875245

35 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 35 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 36 Models and Languages for Coordination and Orchestration save_business and delete_business <save_business generic="2.0" xmlns="…"> [ … ] <delete_business generic="2.0" xmlns="…"> [ … ]

37 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 37 Models and Languages for Coordination and Orchestration save_service and delete_service <save_service generic="2.0" xmlns="…"> [ … ] <delete_service generic="2.0" xmlns="…"> [ … ]

38 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 38 Models and Languages for Coordination and Orchestration 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 Roberto Bruni @ IMT Lucca 15 March 2005 Institutions Markets Technologies IMT 39 Models and Languages for Coordination and Orchestration 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


Download ppt "1 WS Technologies I UDDI Roberto Bruni Dipartimento di Informatica Università di Pisa Models and Languages for Coordination and Orchestration IMT- Institutions."

Similar presentations


Ads by Google