Web services: How to find them. Universal Description, Discovery, and Integration (UDDI) and other approaches

Transcription

1 Web services: How to find them Universal Description, Discovery, and Integration (UDDI) and other approaches

2 Outline In this lecture we described the role of service registries and the service discovery process for web services we introduced UDDI as a standard registry within a Service Oriented Architecture we examined the UDDI data structures and described how they are related to WSDL documents and described the UDDI APIs and how they are used to publish and enquire about web services We discuss current trends in service discovery 2

3 SOA interactions between actors Problem to solve: 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 a priori where the server resides or which server provides the service. 3

4 Service Discovery Service discovery is the process of locating web service providers, and retrieving web services descriptions that have been previously published Interrogating services involves querying one or more service registrys for web services matching the needs of a service requester. A query consists of search criteria such as the type of the desired service, preferred price and maximum number of returned results and is executed against service information published by service provider. Discovering web services is a process that is dependent on the architecture of the service registry. After the discovery process is complete, the service developer or client application should know the exact location of a web service (URI), its capabilities, and how to interface with it. 4

5 Types of service discovery: static There are two basic : static and dynamic Static (old: similar to OOP) The results of the retrieval operation are examined by a human designer and the service description returned by the retrieval operation is incorporated into the application logic. For WS code, generating tools from WSDL can be usefully used With static discovery, the service implementation details are bound at design time and a service retrieval is performed on a service registry. 5

6 Example of static service discovery Look for instance at: XMETHODS: WebserviceX.NET: wscatlist.aspx WebServiceList (with reccomandation info) (march 2009) 6

7 XMETHODS 7

8 WebServiceX.NET 8

9 WebServiceList 9

10 Types of service discovery: dynamic Dynamic (new: towards adaptive SOA) With dynamic discovery, the service implementation details are left unbound at design time so that they can be determined at run-time. The web service requester has to specify preferences to enable the application to infer/reason which web service(s) the requester is most likely to want to invoke. The application issues a retrieval operation at run-time against the service registry to locate one or more service implementation definitions that match the service interface definition used by the application. Based on application logic quality of service considerations such as best price, performance, security certificates, and so on, the application chooses the most appropriate service, binds to it, and invokes it. 10

11 What is UDDI? The sponsoring organization, UDDI.org, is comprised of more than 200 major software developers and e-business leaders who hope to catalyze the development of UDDI and related technologies. The UDDI specification is probably the one that has undergone most changes. The latest version is version 3 (July 2002): version 1 (September/2000) defined the basis for a business service registry version 2 (June/2001) adapted the working of the registry to SOAP and WSDL version 3 (July/2002) 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 11

12 Hype and reality There are a few universal UDDI registries in operation (maintained by IBM, Microsoft, SAP, NTT, etc) These registries are visible and often the first thing one sees of Web Services Unfortunately, these registries are still very small and unreliable (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 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 Web Services and supply the information missing in WSDL descriptions 12

13 UDDI main characteristics UDDI provides a mechanism to categorize businesses and services using taxonomies / classifications with or without an Ontology For example, service providers can use a taxonomy to indicate that a service implements a specific domain standard, or that it provides services to a specific geographic area UDDI uses standard taxonomies so that information can be discovered on the basis of categorisation. Core concept: UDDI business registration is an XML document used to describe a business entity and its web services. UDDI is not bound to any technology. In other words, an entry in the UDDI registry can contain any type of resource, independently of whether the resource is XML-based or not. For instance, the UDDI registry could contain information about an enterprise s Electronic Document Interchange (EDI) system, DCOM or CORBA interface, or even a service that uses the fax machine as its primary communication channel. The point is that while UDDI itself uses XML to represent the data it stores, it allows for other kinds of technology to be registered. 13

14 Overview of UDDI data structures 14

15 Overview of UDDI data structures 15

16 UDDI Data Structures Although UDDI is often thought simply as a directory mechanism, it also defines a data structure standard for representing company and service description information. The data model used by the UDDI registries is defined in an XML schema The UDDI XML schema defines four core types of information.these are 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: what type of services are offered and a list of the different services offered 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) 16

17 <businessentity> data structure expressed in UML 17

18 Business entity Description Info Taxonomy info 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, etc 18

19 Business service The services provided by a business entity are described in business terms using businessservice elements. A businessentity can have several businessservices but a businessservice belongs to one businessentity 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 19

20 <bindingtemplate> and <tmodel> data structures expressed in UML 20

21 Binding template: green pages A binding template contains the technical information associated to 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 field is a string: e.g., an address or even a phone) tmodels: a list of entries corresponding to tmodels associated with this particular binding. The list includes references to the tmodels, documents describing these tmodles, short descriptions, etc. categorybag: additional information about the service and its binding (e.g., whether it is a test binding, it is on production, etc) A businessservice can have several bindingtemplates but a binding Template has only one businessservice The binding template can be best seen as a folder where all the technical information of a service is put together 21

22 tmodel A tmodel is a generic container of information where designers can write any technical information associated to the use of a Web service: the actual interface and protocol used, including a pointer to the WSDL description description of the business protocol and conversations supported by the service A tmodel is a document with a short description of the technical information and a pointer to the actual information. It contains: tmodelkey name description overviewdoc: (with an overviewurl and usetype that indicate where to find the information and its format, e.g., text or wsdl description ) InstanceDetails: descriptions and URI of WSDL interfaces identifierbag categorybag A tmodel can point to other tmodels and eventually different forms of tmodels will be standardized tmodel for WSDL services, tmodels for EDI based services, RosettaNet Partner Interface Processes (PIPs) 22

23 Example of <tmodel> entry <tmodel tmodelkey=" " > <name> RosettaNet-Org </name> <description xml:lang= en > Supports a process for trading partners to request and provide quotes </description > <overviewdoc> <description xml:lang= en > This compressed file contains the specification in a word document, the html guidelines document, and the XML schemas. </ description> <overviewurl> K96RPDQA97A1311M0304UQ4J39/3A1_RequestQuote.zip </overviewurl> </overviewdoc> <categorybag> <keyedreference keyname=" Trading quote request and provision" keyvalue=" " tmodelkey=".."/> </categorybag> </tmodel> URL pointing to a zipped file where a description of the PIP 3A1 "Request Quote" can be found list of name-value pairs that are used to record specific taxonomy information, e.g., industry, product or geographic codes, for this <tmodel> 23

24 Interaction with an UDDI registry The UDDI specification provides a number of Application Program Interfaces (APIs) that provide access to an UDDI system: UDDI Inquiry: to locate and find details about entries in an UDDI registry. Support a number of patterns (browsing, drill-down) UDDI Publication: to publish and modify information in an UDDI registry. All operations in this API are atomic in the transactional sense UDDI Security: for access control to the UDDI registry (token based) UDDI Subscription: allows clients to subscribe to changes of information in the UDDI registry (the changes can be scoped in the subscription request) UDDI Replication: how to perform replication of information across nodes in an UDDI registry UDDI Custody and Ownership transfer: to change the owner (publisher) of information and ship custody from one node to another within an UDDI registry UDDI also provides a set of APIs for clients of an UDDI system: UDDI Subscription Listener: the client side of the subscription API UDDI Value Set: used to validate the information provided to an 24 UDDI registry

25 UDDI inquiry API Search and lookup entries in a registry. This API is freely available, no client authentication is required. Errors are reported as SOAP Faults Browse functions search the registry based on keywords and return summary lists with overview information (key, name and description) about matching businesses or services. Find qualifiers are used to sort the results and to control the keyword matching: toggle between AND/OR, case sensitive/ insensitive, use of wildcards and categories. To minimize the number of requests, find queries can be nested Drill-down functions are used to fetch the specific UDDI data structures about particular entries given their key, returned by the Browse functions Browse functions find_business find_relatedbusinesses find_service find_binding find_tmodel Drill down functions get_businessdetail get_operationalinfo get_servicedetail get_bindingdetail get_tmodeldetail UDDI Version 3.0 Specification, 19 July

26 UDDI publishing and security API Publish, update and delete information contained in a UDDI registry The publishing API requires user authentication using a session token and typically uses SOAP over HTTPS The registry performs access control for all publishing functions: information about the entries can only be edited by the owner Category information and keyed references associated to the entries are validated before accepting new information into the registry Deletion functions are used to remove entries identified by their key from the registry. Removing a business will remove all services associated with it. The same publishing functions are used both to add new information or replace existing information, depending on whether a valid key is passed or not. When adding new entries, keys are usually automatically generated by the registry Security Session Management functions get_authtoken, discard_authtoken Publishing functions Deletion functions save_business save_service save_binding save_tmodel delete_business delete_service delete_binding delete_tmodel 26

27 WSDL to UDDI Mapping Model The service information defined in WSDL documents is complementary to the information found in UDDI business and service entries. Since UDDI strives to accommodate many types of service descriptions it has no direct support for WSDL. However, since UDDI and WSDL distinguish clearly between interface and implementation, these two constructs work together quite naturally. In the following we will show how to map WSDL service description into a UDDI registry, which is required by existing web service tools and runtime environments. 27

28 Mapping WSDL to UDDI schemas 28

29 UDDI and WSDL 29

30 Business information provider roles Registry operators: these refer to the organisations (referred to earlier as operator nodes) that host and operate the UDDI Business Register (UBR). The operator nodes manage and maintain the directory information, cater for replication of business information and other directory related functions. The registry works on a register once, published everywhere principle. This means that a client searching for a business or service can do so at any of the registry operators they should get the same information. This happens since the operator nodes registries replicate their data with each other on a regular basis. Standard bodies and industry consortia: these publish descriptions in the form of service type definitions (<tmodel> s). These <tmodel> s do not contain the actual service definitions, instead they have a URL that points to the location where the service descriptions are stored (definitions can be in any form, however UDDI, recommends using WSDL). 30

31 continued Service providers: commonly implement web services conforming to service type definitions supported by UDDI. They publish information about their business and services in the UDDI. The published data also contains the end point of the web services offered by these enterprises. Private UDDI nodes: the term UDDI is often used to mean both the protocol with its data structures and Application Program Interface (API), that is publish and find operations, as well as the global UDDI Business Registry described in the previous. This is not, however, the only way that UDDI registry can be deployed, there are other deployment possibilities The structure of the UDDI allows the possibility of private UDDI nodes. A private (non-operator) UDDI node can implement all the UDDI functionality, but it does not participate in the replication scheme defined by the UDDI operator s agreement. 31

32 UDDI deployment possibilities The e-marketplace UDDI: an e-marketplace, a standards body, or a consortium of organisations that participate and compete in the industry can host this private UDDI node. The e-marketplace could run a local version of a UDDI registry with its data shielded from the global UDDI registry. The entries in this private UDDI relate to a particular industry or narrow range of related industries. The e-marketplace node can then provide value added services such as quality of service monitoring, validation of content published by companies, ensure that participants in the UDDI registry have been vetted by a rigorous selection procedure, and also ensure that all entries pertain to the market segment of interest. Such a deployment might be not free of charge like the global registry and may charge a fee, either from the service providers or from the clients for providing such value added services 32

33 continued The business partner UDDI registry: this variant of the above scheme is a private UDDI node hosted behind one of the business partner s firewall and only trusted or vetted partners can access the registry. It also contains web service description meta-data published by trusted business parties (that is, those organisations with which the hosting organisation has formal agreements/relationships). The portal UDDI: this type of deployment is on an enterprise s firewall and is a private UDDI node that contains only meta-data related to the enterprise s web services. External users of the portal would be allowed to invoke find operations on the registry, however, a publish operation would be restricted to services internal to the portal. The portal UDDI gives a company ultimate control over how the meta-data describing its web services is used. 33

34 continued The internal UDDI: this allows applications in different departments of the organisation to publish and find services, and is useful for large organisations. The major distinction of this UDDI variant is the potential for a common administrative domain that can dictate standards (for example a fixed set of tmodels can be used). This allows the UDDI node to operate with different publish restrictions than those suggested for the business partner UDDI. For example, the node could restrict the publication of new tmodels and thereby restrict publishing of <businessservice>s and <bindingtemplate> to accept only entries associated with a fixed set of tmodels. These kinds of UDDI deployments are called EAI UDDI, as they allow corporations to deploy and advertise Intranet web services. 34

35 Summary UDDI The UDDI specification is fairly complete and encompasses many aspects of an UDDI registry from its use to its distribution across several nodes and the consistency of the data in a distributed registry Most UDDI registries are private and typically serve as the source of documentation for integration efforts based on Web services UDDI registries are not necessarily intended as the final repository of the information pertaining Web services. Even in the universal version of the repository, the idea is to standardize basic functions and then build proprietary tools that exploit the basic repository. That way it is possible to both tailor the design and maintain the necessary compatibility across repositories While being the most visible part of the efforts around Web services, UDDI is perhaps the most critical due to the complexities of realistic and dynamic B2B interactions (establishing trust, contracts, legal constrains and procedures, etc.) The ultimate goal is, of course, full automation, but until that happens a long list of problems needs to be resolved and much more standardization and semantic information is necessary. 35

36 Some References Specifications: UDDI Business Registry (UBR) nodes: IBM Homepage: Inquiry API: Publish API: Microsoft Homepage: Inquiry API: Publish API : SAP Homepage: Inquiry API : inquiry Publish API : publish NTT Homepage: Inquiry API : inquiryapi Publish API : publishapi 36

37 Beyond UDDI Initial vision of UDDI Replication of centralized UBRs Businesses will be businesses Need privacy, security, trust Rise of private and semi-private registries New UDDI versions (4+) will provide support for distributed registries 37

38 Registry Federation Registry Federation is defined as a group of co-operating registries that provide transparent access to all member registries Examples of federations Two companies X and Y share their registries Federation of all registries in Auto parts domains 38

39 An Example: METEOR-S Web Service Discovery Infrastructure (MWSDI) 39

40 Extended Registries Ontologies (XTRO) Provides a multifaceted view of all registries in MWSDI Federations Domains Registries Registry belongsto Federation Registry Federation Domain belongsto supports subdomainof Ontology consistsof 40

41 Types of Queries Supported What is the access URL, available data model or type of the registry R? Does the registry R support the ontology O? Which are the registries available under the business domain B? Is the registry X a member of the registry federation Y? Which registries pertain to the domains that support the ontologies O1 and O2? Get all the registry federations that belong to the domain D? Find all the registries that are categorized under the node N in the taxonomy (or ontology) C? 41

42 Next-Generation Web Services Discovery Mechanism A script-based search agent will likely play an important role in Web services discovery for Web browser-based Web services, discovery clients, and e-business applications. The mechanism should: Use a standard interface Simplify the developer's work Hide the complexity of UDDI and WSIL (search clients Web Service Inspection Language) Perform result aggregation from one or multiple federated sources 42

43 Agent-Based Web Service Search 43