Web Services - Concepts, Architecture and Applications Part 7: Service Discovery (UDDI)Basic problems to solveRPC-Binding DCE architectureBeyond RPC: Dynamic invocationUniversal Description, Discovery and Integration (UDDI)What is UDDI?Hype and realityRole of UDDIMore detailed (ebXML architecture)Information in an UDDI registryUDDI data modelBusiness entityBusiness serviceBinding templatetModel (technical model)Summary of the UDDI data modelInteraction with an UDDI registryUDDI, SOAP and WSDLUDDI interfacesUDDI inquiry APIUDDI publishing and security APISummary UDDIReferencesWeb 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 3RPC-Binding  A service is provided by a server located at a particular IP address and listening to a given port Binding is the process of mapping a service name to an address and port that can be used for communication purposes Binding can be done:Ä locally: the client must know the name (address) of the host of the serverÄ distributed: there is a separate service (service location, name and directory services, etc.) in charge of mapping names and addresses. These services must be reachable by all participants With a distributed binder, several general operations are possible:Ä REGISTER (Exporting an interface): A server can register service names and the corresponding portÄ WITHDRAW: A server can withdraw a serviceÄ LOOKUP (Importing an interface): A client can ask the binder for the address and port of a given service There must also be a way to locate the binder (predefined location, environment variables, broadcasting to all nodes looking for the binder)©ETH Zürich Part 7: UDDI 4DCE architecture©ETH Zürich Part 7: UDDI 5Beyond RPC: Dynamic invocation CORBA, as a reference architecture, tries to provide maximum flexibility RPC is based on a static model whereby the client is tied to a server (maybe not to an instance of the server but certainly to an interface of the server). To make a call, the client needs to know the interface of the service being invoked CORBA defines a dynamic invocation mechanism where the client can call a service without knowing the interface in advance (i.e., without having been linked to the client stub or using a proxy) The trick is to do at run time the same operations written in the client stub by the IDL compiler CORBA provides an interface repository that can be queried by the client through the dynamic invocation API. The interface repository contains the signatures of all services that can be invoked through the ORB For dynamic invocation:Ä find the matching service interface (method signature)Ä create the request by passing the name of the method to call and the necessary arguments CORBA_Object_create_requestÄ invoke the request just created: CORBA_request_invoke Note: these are exactly the same operations performed by the Client stub©ETH Zürich Part 7: UDDI 6Universal Description, Discovery and Integration (UDDI)©ETH Zürich Part 7: UDDI 7What is UDDI? The UDDI specification is probably the one that has undergone most changes. The latest version is version 3 (July 2002):Ä 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 8Hype and reality There are a few universal UDDI registries in operation (maintained by IBM, Microsoft, SAP, NTT, etc) These registries are very visible and often the first thing one sees of Web services Unfortunately, these registries are still very small and most of the entries in them do not work or do not correspond to any real service This has been a source of criticism to Web services in general. The criticism has not been entirely undeserved but it is often misguided: what was there to criticize was not UDDI itself but the use that has been made of it and the hype around dynamic Web services UDDI is rather useful if seen as supporting infrastructure for Web services in well defined and constrained environments (i.e., without public access and where there is a context that provides the missing information) Most of the UDDI registries in place today are private registries operating inside companies (recall that the widest use of Web services today is for conventional EAI) or maintained by a set of companies in a private manner UDDI has now become the accepted way to document