1 / 63

Services Computing Chapter 4: Web Services Publishing and Discovery

Services Computing Chapter 4: Web Services Publishing and Discovery. IEEE Body of Knowledge on Services Computing Sponsored by Technical Committee on Services Computing, IEEE Computer Society. Your Name:________________________________________. Web Services Publishing

chenault
Download Presentation

Services Computing Chapter 4: Web Services Publishing and Discovery

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Services ComputingChapter 4: Web Services Publishing and Discovery IEEE Body of Knowledge on Services Computing Sponsored by Technical Committee on Services Computing, IEEE Computer Society Your Name:________________________________________

  2. Web Services Publishing Public/Private UDDI Publishing WSIL Publishing Simple Web Services Discovery UDDI Search Markup Language (USML) Advanced UDDI Search Engine Architecture Federated Web Services Discovery Methodology WSIL-Oriented Advanced Services Discovery Federated Web Services Discovery Framework Comparison between federated search framework with Google Outline

  3. A Web service can be published in one of the two major ways: to a centralized services registry or to a distributed services registry. UDDI registry is one typical example of a services registry; Web services Inspection Language (WS-Inspection or WSIL) is one example of publishing a Web service as a distributed document. 4.1 Web Services Publishing

  4. The information of registered Web services is stored in the UDDI registry in UDDI internal format. 4.1.1Public/Private UDDI Publishing • UDDI provides a SOAP interface to enable SOAP message-based services publishing.

  5. A WSIL document can also link to another WSIL document, which in turn may link to another WSIL document. These linked WSIL documents may nest multi-level deep. 4.1.2 WSIL Publishing • Thus, they are referred to as WSIL chains or Web services representation chains.

  6. <?xml version="1.0" encoding="UTF-8" ?> <inspection xmlns="http://servicescomputing.org/wsdl/" xmlns:wsilwsdl="http://servicescomputing.org/wsdl/"> <service> <abstract>This supply service provides an online purchase order handling service.</abstract> <name xml:lang="en-US">SupplyService</name> <description location="supply.wsdl" referencedName-space="http://servicescomputing.org/wsdl/"/> <description location="shipping.wsil" referencedNamespace=" http://servicescomputing.org/wsdl/"> <unknown:service-description type="unknown" /> </description> </service> 4.1.2 WSIL PublishingAn Example WSIL Document <link location="payment.wsil" referencedName-space="http://servicescomputing.org/wsdl/"> <abstract>Link to the WSIL document for payment services</abstract> </link> <link location="shipping.wsil" referencedName-space="http://servicescomputing.org/wsdl/"> <abstract>Link to the WSIL document for shipping services</abstract> </link> </inspection>

  7. UDDI Publishing Traditional Yellow Pages Organizations can share and use UDDI registries to maintain a number of Web services under different categories. Considered as a core building block that enables organizations to quickly, easily, dynamically locate and transact with each other via their preferred applications. WSIL Publishing Asking around for information. Cheaper for organizations to share services. Carried by XML files, WSIL enables Web services discovery, deployment, invocation through regular Web servers without a comprehensive and complex services registry infrastructure 4.1.3 UDDI Publishing vs WSIL Publishing

  8. Use a dedicated package (e.g. UDDI4J) to access UDDI Search for Business Search for Service Search for Service Type Use a separate package (e.g. WSIL4J) to access WSIL Documents Drawbacks: No automated or programmable process to access multiple sources No aggregation No uniform access mechanism 4.2 Simple Web Services Discovery

  9. A simple UDDI search usually adopts a UDDI client to look up a Web service in a UDDI registry. Generally a UDDI search intends to follow one of three directions: search for business, search for service and search for service type. 4.2.1 Simple UDDI Search

  10. 4.2.1 Simple UDDI Search Search for Business Search for business allows one to find business entities (organizations) according to some criteria, which can be any combination of keywords, identifiers, locators, service types, and discovery URLs.

  11. 4.2.1 Simple UDDI Search Search by Business Name By using the BusinessName tag, this search criterion specifies the name of the targeting business. The business organizations with their names starting with the specified characters will be returned.

  12. 4.2.1 Simple UDDI Search Search by Identifier A UDDI registry allows each of its stored entities to be annotated with information that can uniquely identify itself. This information is called identifier. By using an Identifier tag, this search criterion specifies a (name, value) pair representing the type of a targeting identifier and its value.

  13. 4.2.1 Simple UDDI Search Search by Category In order to facilitate service searching, a UDDI registry typically classifies its entities with various categorization taxonomies such as North American Industry Classification System (NAICS), Universal Standard Products and Services Classification (UNSPSC), and Geographic (GEO). These classification taxonomies are called locators. By using the Category tag, this search criterion specifies (name, value) pair representing the type of a targeting locator and its value.

  14. 4.2.1 Simple UDDI Search Search by Discovery URL UDDI allows each of its store entities to be associated with the address that points to a URL – addressable discovery document containing the information about the business registered. This service is called discovery URL.

  15. 4.2.1 Simple UDDI Search Search for Service Search for service allows one to find published business services according to some criteria which can be any combination of service name and service category. Only business services that match all criteria are returned.

  16. 4.2.1 Simple UDDI Search Search by Service Name By suing the ServiceName tag this search criterion specifiies the name of the service to look for. The business services with their names starting with the specified characters will be returned.

  17. 4.2.1 Simple UDDI Search Search by Category By using the Category tag, this search criterion specifies the (name, value) pair representing the type of a service category to look for and its value.

  18. 4.2.1 Simple UDDI Search Search for Service Type Search for service type allows one to find published business service types according to some criteria, which can be any combination of service type name and service type category. Only service types that match all of the specified criteria will be returned. Such a query has to contain at least one search criterion.

  19. 4.2.1 Simple UDDI Search Search by Service Type Name By using the ServiceTypeName tag, this search criterion specifies the name of the service type to look for. The business service types with their names starting with the specified characters will be returned.

  20. 4.2.2 Simple WSIL Search 5 Steps of Simple WSIL Search Step 1. Identify the location of a starting WSIL document (e.g.,http://www.servicescomputing.org.start.wsil). Step 2. Perform the search for the specified WSIL document. Step 3. Perform the search for the specified

  21. Step 4. Select a link to launch the content of the selected WSIL document. If the launched document contains other links, chase down the links to retrieve further documents. Step 5. Repeat Steps 3 and 4 to iterate through all interested links until intended information is found. 4.2.2. Simple WSIL Search

  22. In general, with the UDDI approach, one can locate business services whose identities are well known: one can find out what services a business is offering and how to access services. 4.2.3 Issues of the Simple UDDI/WSIL Search

  23. 4.2.3 Issues of the Simple UDDI/WSIL Search • Issues of the Simple UDDI • A public UDDI registry typically contains thousands of distinct entities. Thus, it is unlikely that a simple search will yield a manageable size of result sets. • Simple UDDI searching mechanisms require that service requestors know which directories to search ahead of time (e.g., search by business or search by service).

  24. Developers must manually write comprehensive search code, because simple UDDI search APIs are insufficient. 4. Typical UDDI search engines for simple UDDI searching only support specific types of UDDI registries. A basic UDDI query only allows searching for one category. 4.2.3 Issues of the Simple UDDI/WSIL Search

  25. Example: A company’s UDDI search technology may only allow its users to search its own category (i.e. search for business, search for service, or search for service type) 4.2.3 Issues of Simple UDDI/WSIL Search

  26. 4.2.3 Issues of the Simple UDDI/WSIL Search • Issues of the WISL Search Approaches • They lack a capability to aggregate found services when traversing linked WSIL documents. • 2. There is no uniform discovery mechanism for • aggregating search results from multiple data • sources, such as UDDI registries and WSIL • documents.

  27. UDDI Search Markup Language (USML) is a comprehensive XML based description language, aiming to formalize UDDI search queries and enable complex UDDI search queries across UDDI registries. 4.3 UDDI Search Markup Language

  28. 4.3 UDDI Search Markup Language • Three CORE Data Types that can be Queried: • 1. Business • 2. Service • 3. Service Type (tModel)

  29. A USML-based search request typically incorporates multiple search queries, UDDI sources, and aggregation operators. Such a query navigates through single or multiple UDDI registries according to multiple search criteria, including keywords, identifiers, and categories. The search results are aggregated before responding to search requestors. UML Schema (USML Search Schema, and USML Response Schema) 4.3 UDDI Search Markup Language (USML)for supporting “Google” style services Search <?xml version="1.0"?> <UDDISearch xmlns="http://www.servicescomputing.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.servicescomputing.org/UDDISearch.xsd"> <Search> <Query> <Source>Private UDDI</Source> <Sour-ceURL>http://servicescomputing.org/services/uddi/inquiryAPI</SourceURL> <BusinessName>COMPUTER</BusinesName> <FindBy>Business</FindBy> </Query> <Query> <Source>Public UDDI</Source> <SourceURL>http://pubuddi/services/uddi/servlet/uddi</SourceURL> <BusinessName>ELEC</BusinesName> <FindBy>Business</FindBy> </Query> <AggOperator>OR</AggOperator> <RequestTypeName>Business</RequestTypeName> </Search>

  30. The USML file has a link to an XML Schema file “UDDISearch.xsd”. A USML script is an XML document that contains a set of search queries, each being associated with a predefined criteria. In order for these USML scripts to be parsed and handled automatically by services registries, it is imperative for them to be associated with schema files describing structure of each search query and criterion. 4.3.1 USML SCHEMA

  31. An associated XML Schema File describes how the USML script should be interpreted. It defines the elements that a USML search request can contain, such as their attributes, values and so on. A valid USML document must conform to its associated XML Schema document. It should be noted that any kind of metadata description language can be used for this purpose. Example: Document Type Definition (DTD). 4.3.1 USML SCHEMA

  32. 4.3.2 Composite Search Options A simple UDDI search intends to find one of the three categories of information: search for business, search for service, and search for service type. 32

  33. 4.3.2 An Example of USML Response Schema 33

  34. 4.3.3 Aggregation Operators The AggOperator defined in USML can take different values, which can be either a simple AND (or OR) as discussed in the previous section, or a comprehensive function that requires a script to perform an aggregation task (e.g., an XOR function). If a response contains redundant information, it can be filtered by the use of such operators. This feature is especially useful for business searching. For example, since every business organization is associated with a business key and every service has a service key, an aggregation operator can help in combining the results of different keys and eliminate the repetitive information with the same key. 34

  35. 4.3.2-4.3.3 35

  36. The OR operator aggregates search results regardless of their relationships. For example, if one intends to search in a UDDI registry for any businesses starting with Company A or any services starting with Web, he/she should make two requests accordingly, and the results will be aggregated. 4.4 USML-BASED Advanced UDDI Search Engine

  37. 4.4 USML-BASED Advanced UDDI Search Engine Using USML, a service requestor can write one compound USML request to search across multiple UDDI registries, in order to facilitate USML interpretation and handling, the Advanced UDDI Search Engine (AUSE) is established. 37

  38. 4.4 Advanced UDDI Search Engine Architecture

  39. The goal of an AUSE is to automatically interpret USML requests, dispatch and conduct search queries to corresponding registries, aggregate search results from different UDDI registries, and send back results to search requestors in the format of a USML response. 4.4 USML Based Advanced UDDI Search Engine (AUSE)

  40. Step 1: A service requestor forms a USML request and sends to an AUSE engine. The request is registered at the Notification Broker. Step 2: The Notification Broker sends an acknowledgement of receipt to the service requestor. Step 3: The Notification Broker forwards the search request to the USML Parser to interpret the request. Federated Web Services Discovery Methodology

  41. Federated Web Services Discovery Methodology • Step 4: • The USML Parser validates the search script in accordance with corresponding USML Schema, and forwards to the Search Command Constructor. • Step 5: • The Search Command Constructor generates one or more individual UDDI search queries and forwards to the UDDI Search Dispatcher.

  42. Federated Web Services Discovery Methodology • Step 6: • The UDDI Search Dispatcher first checks the Local UDDI Database. If in-formation is not found, it checks the availability of requested UDDI registries and their access information. Search queries are also stored to the database for later use by the Information Aggregator. 42

  43. Step 7: The UDDI Search Dispatcher dispatches the search queries to correspond-ing UDDI registries. Step 8: The Information Aggregator retrieves information from the Local UDDI Database, then listens and gathers search results from the corresponding UDDI registries, and aggregates search results into an XML-based USML response based upon the aggregation operators defined in the USML request. Step 9: The Information Aggregator sends a Result Available Notice (RAN) message to the Notification Broker, informing availability of the corresponding search results. Federated Web Services Discovery Methodology (Cont’d)

  44. Step 10: The Notification Broker in turn sends a notification message to the service requestor. Step 11: The service requestor tries to fetch the search results from the Information Aggregator. Step 12: The Information Aggregator sends back to the service requestor the search results in the format of an XML-based USML response. Federated Web Services Discovery Methodology (Cont’d)

  45. 4.5 WSIL-Oriented Advanced Services Discovery Dynamic Service Discovery Framework (DSDF) for WSIL chains

  46. 4.5 WSIL-Oriented Advanced Services Discovery (Cont’d) • A mechanism to automate searching Web services in WSIL chains, aggregate Web services found in each WSIL document, and return results to the requestor for real-time feedback. • A service requestor, either from a program or from a Web browser, makes a request to the DSDF. • The DSDF then searches the Internet for appropriate WSIL chains starting from a specified Web link to find available proper Web services.

  47. 4.5 WSIL-Oriented Advanced Services Discovery (Cont’d) • DSDF also provides an aggregation mechanism to group all Web services found in each WSIL document and return organized results to the service requestor all at once. • Thus, service requestors can be released from being forced to manually track down WSIL documents for candidate Web services.

  48. 4.5.1 Architecture of DSDF

  49. 4.5.1 Architecture of DSDF Services Container The Services Container stores cached information of each service description document chain and Web services contained in the chain. This information is retrieved and used by the Chain Change Detection Engine.

  50. One example implementation of DSDF Is IBM’s WSIL discovery took, WSIL Explorer. Being part of the IBM Emerging Technologies Toolkit (ETTK) 2.3. 4.5.2 DSDF Implementation

More Related