It presents high level business information such as ... dynamic parameter based discovery broker suitable for service discovery in a grid. 2 Related Work.
Enhancing UDDI for Grid Service Discovery by Using Dynamic Parameters Brett Sinclair, Andrzej Goscinski and Robert Dew School of Information Technology Deakin University Geelong, Vic 3217, Australia {brettwil, ang, rad}@deakin.edu.au Abstract. A major problem for a grid user is the discovery of currently available services. With large number of services, it is beneficial for a user to be able to discover the services that most closely match their requirements. This report shows how to extend some concepts of UDDI such that they are suitable for dynamic parameter based discovery of grid services.
1
Introduction
Naming and discovery are critical components of grids. Without the ability to discover the names of services that are available on a grid these services cannot be invoked. A grid service can be named by not just a name that is globally unique, but also by the parameters it portrays [6]. Service's parameters can be dynamic or static and can be used to expose important details of a service, such as its state. By using dynamic parameter based discovery a user is able to refine their search for services. This reduces the number of results received and increases the number of relevant results. UDDI (Universal Description Discovery and Integration) [7] is a generic system for discovering Web services. It presents high level business information such as contact details and service lists in a format similar to a telephone directory. The indexing service of Globus, which is a toolkit for creating only one kind of grid, offers a registry for grid services that can be used for discovery. This report shows the outcome of an initial study into dynamic parameter based discovery in grids by extending UDDI and a proof-of-concept in the form of a dynamic parameter based discovery broker suitable for service discovery in a grid.
2
Related Work
Grids are an emerging technology; the number of discovery systems which are being employed on grids today is small: UDDI is the current standard for discovery of Web services; and the index service is part of the Globus Toolkit. UDDI [8] is a system to enable businesses to publish and locate Web services. Businesses can publish information about themselves and the Web services they provide. Interaction with a UDDI registry is done using a set of XML interfaces, protocols and programming APIs. Information about Web services is stored similar to that of a phone book. There are white pages which contain information about
2
Brett Sinclair, Andrzej Goscinski and Robert Dew
individual Web services, yellow pages which classify Web services, and the green pages which store information about individual businesses [2]. However, UDDI does not have the ability to aggregate information about the state of a grid service. Globus contains, as a base service, a component called the index service. The index service is designed to aid in the discovery of resources and assist in the management of service data. Service data are additional parameters related to a service. The index service provides three systems [5]: a registry; service data providers; and a data aggregator. The registry provides a list of services currently published to the index service. This can be used for the discovery of resources. A service data provider provides additional information about a service which has been generated by an external program. The data aggregator can collect all information generated about a service and provide a simple access point to it. Thus, a name of a service can be discovered from the index service; however to obtain the most consistent service data the service must be invoked.
3
Dynamic Parameter Based Discovery Broker – Logical Design
This section presents a logical design of a centralized resource discovery broker that allows a published grid service to be discovered based on dynamic parameter values. 3.1
UDDI Data Model and UDDI Deficiencies for Grid Service Discovery
A fundamental concept of the UDDI standard is to represent data and meta-data about Web services. This information is represented in a standard way, catalogued and classified to allow for Web service discovery [1]. UDDI can be used to discover grid services; a grid service is a special case of a Web service. The information about businesses and services are stored in four structures: • businessEntity, businessService and bindingTemplate are in a parent child relationship, a parent can contain many children; • businessEntity is the parent to businessService; • the businessService is the parent to bindingTemplate structures; and • the tModel structure is outside this parent child relationship. One extension to Web services that a grid service introduces is service data. Service data provide information about a service, which the interface alone cannot provide. Every grid service has a basic set of service data elements, which contain information about the service, its interface, and its location. UDDI's data model is adept at storing information about Web services, however lacking the ability to record the service data of a grid service. UDDI's inability to index service data increases the processing complexity of a client. A client wishing to discover a grid service and obtain it service data using UDDI is forced to complete two steps. First a client must query the UDDI registry for a set of grid services. Second the client must query the discovered grid services to obtain their current service data. The retrieved service data is then used to determine if the service meets the requirements of the client.
Enhancing UDDI for Grid Service Discovery by Using Dynamic Parameters
3.2
3
A Logical Design of a Centralised Discovery Broker by Enhancing UDDI
Using the concepts of notifications described by the OGSA [3] it is possible to create a discovery broker that has the ability to dynamically index and keep a consistent view of service data. The published service is effectively given a dynamic parameter name. This allows the discovery of a service to be based on static and dynamic information about the service. To store the additional information, the UDDI data model, is enhanced to incorporate the storage of service data. A new data type called serviceData, which is the child of a single bindingTemplate, can be used to store service data. The serviceData type stores the current service data of the grid service described in the parenting bindingTemplate. This is shown in Figure 1. Furthermore, this figure shows the relationship between the UDDI data structures, which provide information about Web service and the businesses that are responsible for them.
Figure 1 Proposed data model incorporating service data
Service data are dynamic and change with respect to the state changes of a grid service. The OGSA describes the concept of notifications to monitor the changes of service data. Notifications can be used by the discovery broker to keep the data that is stored by the broker, consistent with the service data of a service. When a service is published to a discovery broker, the broker subscribes to that service to be notified of service data changes. When a grid service state changes a notification of the change, as well as the changed service data is sent to the discovery broker. This enables a registry to contain up to date information about a grid service. In this manner a client has the ability to query a centralized discovery broker on the high level business data, as well as the current service data of a grid service. The proposed model for a centralized discovery broker is shown in Figure 2.
Figure 2 Dynamic parameter based grid service discovery using proposed broker
4
Brett Sinclair, Andrzej Goscinski and Robert Dew
A grid service is published to a discovery broker (message 1). In the publication process, data about the grid service and the service data are presented to the broker. The discovery broker then subscribes to the grid service, such that it is notified when the service data of the grid service changes (message 2). A grid service notifies the broker of any changes made to its service data (message 3). A client wishing to discover a service, based on its dynamic parameter name, only has to query the discovery broker (message 4). The proposed discovery broker is composed of four major components: the interface; the query manager; the notification manager; and the published service information database, as shown in Figure 3.
Figure 3 Proposed discovery broker
This new model reduces the complexity of a client wishing to discover a grid service by removing the need for interaction between the client and the grid service; and reducing the need for the aggregation and querying of service data from multiple grid services. The model also decreases the demands on the grid service: a grid service is not continually queried by clients for its service data; and when the service data of a grid service change, only the centralized registry needs to be notified.
4
Centralized Dynamic Parameter Based Discovery Broker
This section demonstrates the construction of a centralized dynamic parameter based discovery broker following the design presented in Section 3. The discovery broker has been implemented as a grid service using the tools provided by the Globus toolkit. A grid service has two desirable properties. Firstly, it preserves its state between invocations, allowing the discovery broker to maintain information about publicized services. Secondly, it interoperates with all other grid services. The discovery broker developed is centralized. A UML diagram of the discovery broker showing the four major components is illustrated in Figure 4. The DiscoveryBrokerImpl class implements all the functionality of the discovery broker; its interface is defined by the DiscoveryBroker interface. It inherits all functionality which the OGSA requires a grid service to implement from the GridServiceImpl class. The notification manager, the query manager, the database and the interface are all contained by the DiscoveryBrokerImpl class. The Discovery Broker Interface. This interface describes the operations that a client can invoke on the discovery broker. All operations which can be invoked on a grid service are specified by its portType. Section 3 identified three categories of operations that can be invoked on the discovery broker: publications, notifications and queries. The implementation of the discovery broker specifies the operations in each of these categories.
Enhancing UDDI for Grid Service Discovery by Using Dynamic Parameters
5
The operations for the publication of a service are: • publishService(), which is used to publish a service; and • unpublishService(), which is used to un-publish a service. Queries are used to discover services; a number of different operations can be invoked to discover services in different ways. The names of the operations were derived from data structures used to store service information. The operations are: • searchBusinessEntity(), search for a business based on a business’s name; • searchBusinessService(), search for a business by the type (category) of services it provides; • searchBindingTemplate(), search for a particular service by name; and • searchServiceData(), searches for a grid service that has a particular service data element with a specified value. Only one operation is in the notifications category, deliverNotification(). It accepts messages from published grid services when their service data changes. This operation is a common operation to all grid services and is described by the OGSI [9]. These operations are not the only operations that the discovery broker must implement – all grid services must implement the GridService interface described by the OGSI and since the discovery broker accepts notifications the NotificationSink interface must also be presented. Figure 5 shows a UML diagram of the discovery broker interface. The interface, DiscoveryBroker, inherits the operations from the GridService and NotificationSink interfaces, which are provided by Globus. a)
GridServiceImpl
NotificationManager
b)
QueryManager
«interface» DiscoveryBroker
DiscoveryBrokerImpl 1
1 DataBase
1
Figure 4 UML representations of a) the discovery broker and b) the discovery broker interface
Globus provides an implementation of all OGSI interfaces. It is therefore not necessary to define the messages for operations inherited from the GridService or NotificationSink interfaces. The only messages which must be specified are the messages unique to the DiscoveryBroker; they are presented in [8]. Query Manager. The query manager provides a simple means of querying the data stored about published services. Messages are received from either the discovery broker or the notification manager requesting that information is either retrieved from, modified in or stored in the database. A major functionality of the query manager is its ability to understand and query data stored in an XML document. Service data is encoded in XML; the messages received via notification come in this form. The query manager has the ability to parse this document and extract specific service data elements and their values for appropriate action.
6
Brett Sinclair, Andrzej Goscinski and Robert Dew
Notification Manager. The notification manager implements one function, deliverNotification(), which receives push notification messages from grid services whose service data has been modified. The message received is an XML document; the notification manager parses it, extracts service data, and then passes the service data to the database. Database. There is a need for a data model for storing the published information about a service. The data model is hierarchical: each BusinessEntity contains a list of BusinessServices, each BusinessService contains a list of BindingTemplates, and each BindingTemplate contains a list of ServiceData. This hierarchical structure makes it relatively easy for the query manager to traverse when searching for records that need to be accessed, modified, deleted, or inserted.
5
Testing
This section shows that the proposed enhancement to UDDI and the application of the concepts of naming, notification and service data of OGSA are sound using evaluation of the dynamic parameter based discovery broker within a simple grid. 5.1
Test Environment
The dynamic parameter based discovery broker was implemented and tested on a small grid, consisted of two Pentium based machines connected by a hub. On each machine the Globus toolkit was installed and a set of simple services were deployed. Two services were developed to test the discovery mechanism: a simple mathematics service, MathService; and a printing service, PrintService. Each service contained a single service data element that is dynamically updated when the service is invoked. This service data element is used to test discovery based on the dynamic parameters of a service. The mathematics service allows two operations, add and subtract, to be conducted on a single value stored in the service. This value is retained between invocations of the service. A service data element, MathData, is exposed by the service. The printing service allows three operations to be conducted; turn on printer, turn off printer, and print a page. This service contains one service data element, PrintData, that contains two variables; the value in one indicates if the printer is on or off, and the other variable holds the total number of pages printed. Two hypothetical businesses were created to own the services: business1 and business2. Each business owns two services, a MathsService and a PrintService, which are hosted on two separate machines. The machine Globus01 is running three services a MathService owned by business1, a PrintService owned by business2, and the discovery broker. The machine Globus02 is running two services: a MathService owned by business2, and a PrintService owned by business1. These machines and hypothetical businesses where used to complete a series of tests on the capabilities of the discovery broker. Clients interact with the discovery broker that is hosted on Globus01. Operations are invoked on the discovery broker by sending SOAP messages to the broker using HTTP. A response from the broker is returned to the client as SOAP message.
Enhancing UDDI for Grid Service Discovery by Using Dynamic Parameters
5.2
7
Test Scenarios
To test the discovery broker, two scenarios were designed. Each scenario is comprised of a logical sequence of steps. The output of each step was predicted and compared with the actual output. Scenario 1 tested the discovery of services using static information that emulates the discovery methods provided by UDDI. Scenario 2 tested discovery using the dynamic parameters of a service. Scenario 1. Scenario 1 is used to test publication, un-publication and discovery of services. The following steps were conducted: 1. Publish the MathService owned by business1, using the publishService operation. 2. Publish the MathService owned by business2, using unpublishService. 3. Test whether services are published correctly by using searchBindingTemplate to search for services that have names that match the name “MathService”. 4. Un-publish the MathService owned by business1, using unpublishService. 5. Test, using the searchBindingTemplate operation, whether the service has been unpublished by searching for services that have the name “MathService”. The results of publishService invoked in steps 1 and 2 are shown in Listing 1. These results have been gathered from the discovery broker and show the received information about the services which are being published. Listing 1 Publication of MathSerices Publish service: Business Name: business1 Service Category: Math Service Name: MathService Location: http://globus01:8080/Math Publish service: Business Name: business2 Service Category: Math Service Name: MathService Location: http://globus02:8080/Math
The results from searchBindingTemplate invoked in step 3 are shown in Listing 2. Listing 2 Search for MathService Search for service: MathService ========== business1 ========== Service Category: Math Service Name: MathService Location: http://globus01:8080/Math ========== business2 ========== Service Category: Math Service Name: MathService Location: http://globus02:8080/Math
These results were gathered from the client application and were produced by a search for all services called MathService. They show that both published MathServices were discovered (which was the expected results). Step 4 attempts to un-publish the MathService owned by business1 using the unpublishService operation. The output generated from this operation being applied to the discovery broker is shown in Listing 3.
8
Brett Sinclair, Andrzej Goscinski and Robert Dew Listing 3 Un-publication of MathService Unpublish Service: Business Name: business1 Service Category: Math Service Name: MathService Location: http://globus01:8080/Math
Step 5 searches (again) for the services named MathService, Listing 4. This time the results show that the only published service with the name MathService is the service owned by business2. Listing 4 Results of search Search for service: MathService ========== business2 ========== Service Category: Math Service Name: MathService Location: http://globus02:8080/Math
This step has shown the un-publication of a service succeeded, as expected. The testing from Scenario 1 has shown that the discovery broker allows for discovery based on a service’s name. Scenario 2. This scenario is designed to assess discovery based on dynamic parameters. This discovery is based on the current values of dynamic parameters of a service. The steps are: 1. All services are published to the discovery broker, using publishService. 2. Both printer services are turned off. 3. Using searchServiceData, a search is conducted for printer services which are on. 4. The printer service from business1 is turned on. 5. A search is conducted for printer services which are turned on. 6. The searchBusinessService operation is used to search for businesses which have services which provide mathematics (maths) services. Listing 5 shows the results returned by the discovery broker when the publishService operation is invoked in step 1. Listing 5 Publication of all services Publish service: Business Name: business1 Service Category: Math Service Name: MathService Location: http://globus01:8080/Math Publish service: Business Name: business2 Service Category: Math Service Name: MathService Location: http://globus02:8080/Math Publish service: Business Name: business1 Service Category: Printing Service Name: PrintService Location: http://globus02:8080/Print Publish service: Business Name: business2 Service Category: Printing Service Name: PrintService Location: http://globus01:8080/Print
Enhancing UDDI for Grid Service Discovery by Using Dynamic Parameters
9
Step 2 required both printers to be turned off. This was completed by calling the operation turnOff for each printing service; this operation modifies the service data element called PrintData. The invocation of the turnOff operation on a printing service generates notifications messages that are sent to the broker. The output generated by the discovery broker, when the notifications occur, show the source of the notification and the service data element which has changed. This can be seen in Listing 6. These results show that the notifications of service data are received. Listing 6 Turning printers off Notification received from: http://globus01:8080/Print sde: PrintData status: OFF pages: 0 Notification received from: http://globus02:8080/Print sde: PrintData status: OFF pages: 0
Step 3 searches for printers which have been turned on. As there were no printers turned on, no results were received. The output from the client is shown in Listing 7. Listing 7 Search for printers which are on Search for service: PrintService Service data name: PrintData Service data element name: status Value: ON null
Step 4 turns on the printer owned by business1. Listing 8 shows that the notification was received by the discovery broker. Listing 8 Turn Printer On Notification received from: http://globus02:8080/Print sde: PrintData status: ON pages: 0
Step 5 searches (again) for printers which were on. One printer was found and that was the printer which was turned on in step 4 (which is what was expected). Listing 9 shows the output generated by the discovery broker. Listing 9 Search for printers which are on Search for service: PrintService Service data name: PrintData Service data element name: status Value: ON ========== business1 ========== Service Category: Printing Service Name: PrintService Location: http://globus02:8080/Print
Step 6 searches for all businesses that provided maths services. The results of this operation are shown in Listing 10. It is shown that both businesses are returned, as the both host math services, which is what was expected. Listing 10 Search for Math services Search for service category: Math business1 business2
10
Brett Sinclair, Andrzej Goscinski and Robert Dew
These six steps demonstrate the ability to complete discovery based on the dynamic parameters of a service. The scenario of discovering a printing service emphasizes the benefits of dynamic parameter based discovery. A user is able to specify a more detailed query using dynamic parameter values which returns higher quality results.
6
Conclusions
The design and development of a dynamic parameter based discovery technique for service discovery in a grid environment has been presented in this paper. This technique has taken advantage of an extension to UDDI such that it is suitable for dynamic parameter based discovery of grid services, and the concepts of naming, notifications and service data which were introduced by the OGSA. The current implementation of the discovery broker is limited by the types of queries which can be conducted because currently only a small set of queries are defined. Future research could be conducted into the implementation of a flexible XML based query language to conduct queries, which is programming language and platform independent. To provide scalability research is currently being carried out where several brokers cooperate to produce a distributed dynamic parameter based discovery broker.
References 1. 2. 3.
4. 5. 6. 7. 8.
9.
T. Bellwood, L. Clément, and C. v. Riegen, UDDI Spec Technical Committee Specification, http://uddi.org/pubs/uddi_v3.htm, accessed September 2004 M. Deitel, P. Deitel, B. Waldt, and L. Trees, Web Services a Technical Introduction: Prentice Hall, 2003. I. Foster, C. Kesselman, J. Nick, and S. Tuecke, "The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration.," presented at Open Grid Service Infrastructure WG, 2002. A. Iamnitchi and I. Foster, "On Fully Decentralized Resource Discovery in Grid Environments," International Workshop on Grid Computing, Denvor, CO, 2001. J. Joseph and C. Fellenstein, Grid Computing: Prentice Hall, 2004. Y. Ni and A. Goscinski, "Evaluation of attributed names," Distributed Systems Engineering, vol. 2, pp. 87-101, 1995. OASIS, Introduction to UDDI: Important Features and Functional Concepts, UDDI Technical White Paper, www.uddi.org, October 2004. B. Sinclair, A. Goscinski, R. Dew, "An Attributed Naming Based Enhancement of UDDI to Offer Service Discovery in Globus 3", Technical Report TRC04/15, Deakin University, December 2004. S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman, T. Maquire, T. Sandholm, D. Snelling, and P. Vanderbilt, "Open Grid Services Infrastructure (OGSI) Version 1.0," 2003.
