Web Services - Concepts, Architecture and ApplicationsPart 7: Service Discovery (UDDI)Gustavo Alonso and Cesare PautassoComputer Science DepartmentETH Zü[email protected]://www.inf.ethz.ch/~alonso©ETH Zürich Part 7: UDDI 2Basic problems to solve How to make the service invocation part of the language in a more or less transparent manner.Ä Don’t forget this important aspect: whatever you design, others will have to program and use it How to exchange data between machines that might use different representations for different data types. This involves two aspects:Ä data type formats (e.g., byte orders in different architectures)Ä data structures (need to be flattened and the reconstructed) How to find the service one actually wants among a potentially large collection of services and servers.Ä The goal is that the client does not necessarily need to know where the server resides or even which server provides the service. How to deal with errors in the service invocation in a more or less elegant manner:Ä server is down,Ä communication is down,Ä server busy,Ä duplicated requests ...©ETH Zürich Part 7: UDDI 3What is UDDI? UDDI stands for Universal Description Discovery and Integration. The objective is to define a standard for enterprises to dynamically discover and invoke Web services The UDDI specification is probably the one that has undergone most changes. The latest version is version 3 (February 2005):Ä version 1 defined the basis for a business service registryÄ version 2 adapted the working of the registry to SOAP and WSDLÄ version 3 redefines the role and purpose of UDDI registries, emphasizes the role of private implementations, and deals with the problem of interaction across private and public UDDI registries Originally, UDDI was conceived as a “Universal Business Registry” similar to search engines (e.g., Google) which will be used as the main mechanism to find electronic services provided by companies worldwide. This triggered a significant amount of activity around very advanced and complex scenarios (Semantic Web, dynamic binding to partners, runtime/automatic partner selection, etc.) Nowadays UDDI is far more pragmatic and recognizes the realities of B2B interactions: it presents itself as the “infrastructure for Web services”, meaning the same role as a name and directory service (i.e., binder in RPC) but applied to Web services and mostly used in constrained environments (internally within a company or among a predefined set of business partners)©ETH Zürich Part 7: UDDI 4Role of UDDI Services offered through the Internet to other companies require much more information that a typical middleware service In many middleware and EAI efforts, the same people develop the service and the application using the service This is obviously no longer the case and, therefore, using a service requires much more information that is typically available for internal company services This documentation has three aspects:Ä basic information Ä categorizationÄ technical data©ETH Zürich Part 7: UDDI 5UDDI data model An entry in an UDDI registry is an XML document composed of different elements (labelled as such in XML), the most important ones being:Ä businessEntity: is a description of the organization that provides the service.Ä businessService: a list of all the Web services offered by the business entity.Ä bindingTemplate: describes the technical aspects of the service being offered.Ä tModel: (“technical model”) is a generic element that can be used to store additional information about the service, typically additional technical information on how to use the service, conditions for use, guarantees, etc. Together, these elements are used to provide:Ä white pages information: data about the service provider (name, address, contact person, etc.)Ä yellow pages information: classification of services based on existing (non-electronic) standards like the UNSPSC (Universal Standard Products and Services Classification) or ISO 3166 Country CodesÄ green pages information: technical information on how to use each one of the services offered, including pointers to WSDL descriptions of the services (which do not reside in the UDDI registry)©ETH Zürich Part 7: UDDI 6Business entity The generic white and yellow pages information about a service provider is stored in the businessEntity, which contains the following data:Ä each businessEntity has a businessKeyÄ discoveryURLs: a list of URLs that point to alternate, file based service discovery mechanisms.Ä Name: (textual information)Ä Business description: (textual information)Ä Contacts: (textual information)Ä businessServices: a list of services provided by the businessEntityÄ identifierBag: a list of external identifiersÄ categoryBag: a list of business categories (e.g., industry, product category, geographic region) The businessEntity does not need to be the company. It is meant to represent any entity that provides services: it can be a department, a group of people, a server, a set of servers, and so on.©ETH Zürich Part 7: UDDI 7Business service The services provided by a business entity are described in business terms using businessService elements. A businessService element can describe a single Web service or a group of related Web services (all of them offered by the same businessEntity) A businessEntity can have several businessServices but a businessServicebelongs to one businessEntity The businessService can actually be provided by a different businessEntity than the one where the element is found. This is called projection and allows to include services provided by other organizations as part of the own services It contains:Ä a serviceKey that uniquely identifies the service and the businessEntity (not necessarily the same as where the businessService is found)Ä name: as beforeÄ description: as beforeÄ categoryBag: as beforeÄ bindingTemplates: a list to all the bindingTemplates for the service with the technical information on how to access and use the service©ETH Zürich Part 7: UDDI 8Binding template A binding template contains the technical information associated with a particular service. It contains the following information:Ä bindingKeyÄ serviceKeyÄ descriptionÄ accessPoint: the network address of the service being provided (typically an URL but it can be anything as this