Web Service Module for Access to g-Lite Radoslava Goranova Faculty of Mathematics and Informatics, University of Sofia “St. Kliment Ohridski”, 5 James Bourchier blvd., 1164 Sofia, Bulgaria
Goran Goranov Faculty of Electrical Engineering and Electronics, Technical University of Gabrovo, 4 Hadji Dimitar str., 5300 Gabrovo, Bulgaria
[email protected],
[email protected] Abstract. G-Lite is a lightweight grid middleware for grid computing installed on all clusters of the European Grid Infrastructure (EGI). The middleware is partially service-oriented and does not provide well-defined Web services for job management. The existing Web services in the environment cannot be directly used by grid users for building service compositions in the EGI. In this article we present a module of well-defined Web services for job management in the EGI. We describe the architecture of the module and the design of the developed Web services. The presented Web services are composable and can participate in service compositions (workflows). An example of usage of the module with tools for service compositions in g-Lite is shown. Keywords: SOA, Grid, BPM, Web Service, Composition PACS: 01.50.hv, 07.05.-t, 07.05.Bx
INTRODUCTION G-Lite [1] is a lightweight grid middleware for grid computing installed on all clusters of the European Grid Infrastructure (EGI) [2]. The vision for the grid middleware (g-Lite) is presented in [3]. According the authors, gLite grid services follow a service-oriented architecture. Indeed the development of the grid middleware follows the direction of service-orientation. However, some of the current grid services in g-Lite are not service-oriented. This makes g-Lite partially service-oriented environment. The service-oriented architecture [4] is an architectural style for building systems and applications. The basic unit in the architecture is the service. The service is defined through description document, which describes the protocols for service access and the type of the data that service can exchange. In the service-oriented architecture the services follow a set of principles. They are: Contract – the document that describe the service logic and access to it; Loose coupling - the service logic can be change without impact on the other services within the same system; Abstraction – the service logic is capsulated; Autonomy – the service has isolated logic from the other services within the same system; Reusability – the service can be reused more than once; Composability – the service can participate into composition; Statelessness – the service does not save the state of activity; Interoperability – the service is platform and implementation independent;
Discoverability – the service is discoverable, there is a standard mechanism, which allows the service to be discovered. The Web Service Architecture (WSA) is an implementation of the service-oriented architecture. It specifies the standards and protocols for Web service description, Web service invocation and message exchange. The main standards are: SOAP – protocol for exchange of XML massages; WSDL – XML based language for Web service description. It describes the interfaces of the service, the endpoint references and the format of the exchanged message; UDDI – registry for Web services. It provides mechanisms for Web service publishing and discovery; WS-BPEL – XML based language for description and execution of service compositions. The advantage of the service-oriented approach is the ability of building compositions from existing services. Systems, environment and applications developed according to WSA specification provide support of WSDL, UDDI and WS-BPEL. Even more, the service-oriented grid systems and applications have to provide mechanisms for orchestration and service mediation. In [5] the author presents these important aspects for service-orientated grid and the lack of widely accepted mechanisms for orchestration and mediation in it. G-Lite is not an exception. The middleware does not provide mechanisms for orchestration. In the table below (Table 1) are shown the basic services from g-Lite environment with respect to their service-orientation. TABLE (1) Basic g-Lite services with respect to their service-orientation
g-Lite service lcg-CE CREAM-CE SRM FTS WMS MyProxy BDII VOMS
Example endpoint references (EPR) ldap://hostname:2170/mds-vo-name=BG05-SUGrid,o=grid https://hostname:8443/ce-cream/services httpg://hostname:8446/srm/managerv2 https://hostname:8443/glite-data-transfer-fts/services/FileTransfer https://hostname:7443/glite_wms_wmproxy_server hostname:7512 ldap://hostname:2170/mds-vo-name=local,o=grid https://hostname:8443/vomses/
WSDL N/A Yes Yes Yes Yes N/A N/A Yes
WSDL in BDII N/A Yes N/A Yes Yes N/A N/A N/A
We can see that some of the g-Lite services have WSDL descriptions. These services are WMS and CREAMCE. They are implemented as Web services and they follow the principles of service-orientation. However, for the other g-Lite services the WSDL description is not available (N/A). There is no centralized registry in g-Lite grid environment where all the available WSDL descriptions can be found. The information system of g-Lite (BDII) allows discovery of available grid services, however that information is not sufficient for service invocation. Moreover, the existence of the WSDL document is necessary, but not sufficient condition for service composition. The ability of building compositions from existing services depends also from the service loose coupling, abstraction, autonomy, reusability, composability and discoverability. G-Lite does not provide welldefined Web services for job management. The existing Web services in the environment cannot be directly used by grid users for building service compositions in the EGI. Moreover, the EGI grid environment does not provide mechanism for execution of service compositions. In [6] we present some of the tools, which are available for g-Lite and can be used for building and executing service compositions in the EGI. However, all of the presented tools use their one mechanism for service composition, independently from g-Lite. All of these lead us to the conclusion that g-Lite is partially service-oriented environment. If we generalize, the indicators for that are: No service registry or service registry support; No discovery service; No service composition; No well-defined Web service description; The partial service-orientation of the g-Lite environment is a barrier for the development and the support of service-oriented grid applications. There is obviously a need of well-defined Web services for the g-Lite grid environment that can be directly used by grid users in the EGI. In this article we present an example architectural solution of Web service module for access to g-Lite and implementation of well-defined Web services for job management in the EGI.
WEB SERVICE MODULE According [7], a Web service is “a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service using SOAP messages”.
Module Architecture Following the requirement of the definition above, a Web service module for access to g-Lite was developed. On (Figure 1) the architecture of the module is shown.
FIGURE 1. Web Service Module Architecture
The module is implemented on Tomcat 7 application server with Axis 2 SOAP engine and MySQL database for storing user credentials. It provides two types of Web services: Web services that expose some of the main functionality for access to g-Lite Web services that expose some of the main functionality of ROOT framework
FIGURE 2. Web Service Module Architecture with respect to EGI
ROOT [8] is an object-oriented framework that provides packages for analysis of large amounts of data. Usually grid users use it after analyses of the data in grid for graphical data representation. Web services for ROOT allow functionalities of the system to be used in more complex sequences of tasks in dynamic and flexible manner. The developed module is used as an adapter in more complex five-layered architecture of a framework for service composition in g-Lite presented in [9]. Part of this framework is shown on (Figure 2). The EGI provide some legacy services as g-Lite grid services: MyProxy, lcg-CE, BDII etc. These services cannot be changed. The only solution to make them service-oriented is to develop new Web services which to expose the functionality that they provide. Besides EGI legacy services, there can be and other applications like the ROOT framework, which is used by the grid user for additional data processing. The service registry is a repository for all developed Web services. This makes the developed Web services discoverable and reusable by other grid applications. The presented module is extensible. If some other application is added an additional Web services can be developed. The advantage of the module is that the developed Web services can be used by other service composition tools for g-Lite like Triana, Tavern, Kepler or any other tools that support BPEL. Examples of usage are shown further in this paper.
Module Implementation The developed ROOT Web services are presented as class diagram on (Figure 3). The developed Web services exposed very small part of the rich functionalities, which ROOT provides. We design ROOT Web services to expose: RootHistogram1D – functionality for drawing one-dimensional histograms; RootFunction1D – functionality for drawing one-dimensional functions; RootDownloads – implements additional functionality for downloading the histograms and function as ROOT file or C++ file. This allows user to do further changes to the ROOT object. The detailed implementation of the services is published in [10]. From user point of view, there are no specific requirements for access and invocation of the ROOT Web services. For g-Lite Web services this is not the case.
FIGURE 3. ROOT Web Services class diagram
An important aspect of accessing the grid is the security. In g-Lite the security is realized through Grid Security Infrastructure (GSI) [11], which covers user identification, rights delegation, single sign-on and secure communications. The GSI uses X.509 public key infrastructure. In order to identify himself into the EGI, the user have to possess grid certificate (X.509 certificate) issued by Certification Authority (CA) recognized by EGI. Besides the grid certificate, in order to access the EGI, the user has to be a member of a virtual organization (VO). The VO is a set of separate people, institutions and organizations, which share data or work on the same field. Once the user has a certificate and membership into a VO, he can use the grid infrastructure. The basic steps, with respect to the job submission, which the users usually do, are: The user logins on the gLite user interface – computer where all client commands for access to the EGI are installed; The user creates proxy certificate – temporary certificate file with a limit lifetime validity; The user creates job description and submit the job into the grid infrastructure; The WMS finds appropriate match and executes the job; The user verifies if the job is done; The user fetches the job output (if the job is done and the user proxy is not expired), The user processes the output of the job by using additional application, for example ROOT.
Considering this, we developed g-Lite Web services (Figure 4). In order to be invoked, they require user identification. The identification is based on user credentials: username and password, which are stored into the module database. The database stores only users’ proxy certificates. If the user is not registered in the Web service module, preliminary registration is needed. The conclusion is that only grid users that have registration for the developed Web service module can actually invoke and access the g-Lite Web services.
FIGURE 4. g-Lite Web Services class diagram
The developed g-Lite Web services expose the following: ProxyService – functionality for proxy creation and its storage into the database; WebFTP – functionality for uploading files on the application server; UserService – provide functionality for user account management: registration, user DN; JobManager – functionality for job submission into EGI; JobStatus – functionality for job status verification and notification; In (Table 2) are shown basics operations of the ProxyService TABLE (2) Proxy Service operations
Operation proxyCreate proxyCreateUpload proxyView proxyValidate
Description Creates user proxy. As input takes name of the virtual organization, username and password Creates user proxy and stores it into the database. The input is the same as in proxyCreate Selects the user proxy from the database. The input is the same as in proxyCreate Validates the proxy certificate lifetime. If the proxy is expired returns 0.
Module Application In order to test the developed Web service module, some existing tools for service composition in g-Lite was investigated. We analyzed five tools: g-Eclipse [12], P-GRADE [13], Triana [14], Taverna [15] and Kepler [16] Tools for Service Composition in the EGI The analyzed tools were compared according the three major criterions: Web service support – if the tool provides support of Web services; BPEL support – if the tool provides support of BPEL; Registry support – if the tool provides support of service registry
In (Table 3) the results from this investigation are shown. On the base of these results we decided to use the tools Triana, Taverna and Kepler in order to do the module tests. The goal of the test is to verify that tools, which support Web services, can be used for building workflows by composing the developed Web services from the presented module into compositions. TABLE (3). Tools for service composition in the EGI with respect to their service-orientation g-Eclipse P-GRADE Triana Taverna Kepler Criterions No No Yes Yes Yes Web services support No No Yes No No BPEL support No No Yes Yes No Registry support
Described as a part of a workflow, the basics actions which the user does in order to use the grid infrastructure are: Step 1 : Creates proxy certificate; Step 2: Submits job; Step 3: Verifies if the job is done; Step 4: If the proxy is not expired and job is done fetches the job output. Example workflows On (Figure 5) is shown example workflow that represents Step 1 from the actions above.
FIGURE 5. Example workflow with g-Lite Proxy Create Service
With this workflow the user creates proxy certificate by providing username, password and name of the virtual organization he belongs to. The username and password are verified by the Web service module. If the user exists and is identified successfully, then the operation proxyCreateUpload is executed and the proxy certificate is created and stored into the module database. As a result of service invocation a proxy certificate is returned. On the next step, the returned proxy certificate is validated by operation proxyValidate. If the proxy is valid a number representing proxy time left is returned. If the proxy is expired or some exception occurs 0 is returned. As a result from the workflow execution user proxy is created and stored into the module database and proxy time left number is returned. On (Figure 6) is shown example workflow realization in Taverna Workbench 2.3.0 tool.
FIGURE 6. Example workflow with g-Lite Proxy Create Service in Taverna Workbench 2.3.0
Taverna provides very user-friendly workbench for workflow creation. It was easy to discover and import the WSDL of the developed Web services and therefore easy to create the described above example workflow. We have
to mention that Taverna provides and time statistic for workflow execution. Average time for workflow completion is available. Thus, if some errors occur it can be further investigated. On (Figure 7) is shown example workflow realization in Kepler 2.3 tool.
FIGURE 7. Example workflow with g-Lite Proxy Create Service in Kepler 2.3
Again, it was easy to discover and import the WSDL of the developed Web services and therefore easy to create the described example workflow. We try to do the same experiment with Triana. According to [14] Triana tool provides Web services support. However, the latest available version of the software (Triana 4) does not provide such utilities. Unfortunately, that prevents us from further investigation in this direction. Results TABLE (4). Tools for service composition in the EGI with respect to service-orientation Triana Taverna N/A Yes N/A Yes
Criterions Successful execution of workflow with web services from the module Average time for completion
Kepler Yes N/A
As conclusion the following results were achieved (Table 4). The developed Web services are well-defined and can be directly used by grid users in the EGI. Interesting question occurs during workflow execution. For unknown reasons workflow couldn’t be executed due to timeout limit. The timeout can be configured and increased, but nevertheless, it is an interesting question to investigate.
CONCLUSIONS AND FUTURE WORK We introduce a module of well-defined Web services for job management in the EGI. The presented Web services are composable and can participate in service compositions (workflows). An example of usage of the module with tools for service compositions Triana, Taverna and Kepler was shown.
REFERENCES 1. 2. 3.
4. 5. 6.
g-Lite grid midlleware, http://glite.cern.ch/ European Grid Infrastructure, http://www.egi.eu/ Laure, E., Fisher, S., M., Frohner, A., Grandi, C., Kunszt, P., Krenek, A., Mulmo, O., Pacini, F., Prelz, F., White, J., Barroso, M., Buncic, M., Hemmer F., Di Meglio, A., Edlund, A. "Programming the Grid with gLite", Computational Methods in Science and Technology 12(1), 2006, pp. 33-45 Erl, T. "Service-Oriented Architecture: Concepts, Technology, and Design", Prentice Hall Publishers, 2005 Dimitrov, V. T., Development of applications with service-oriented architecture for grid, ACM New York, 2008, Proceedings of the 9th International Conference on Computer Systems and Technologies (CompSysTech '08), Article No.14 Goranova R. D., Service composition tools in g-Lite, Conference Proceedings of the Fifth International Conference ISGT, 2011, pp. 228-235
7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Booth, D., Haas, H., et al. "Web Service Architecture", 2004 ROOT User Guide, http://root.cern.ch/download/doc/Users_Guide_5_26.pdf Goranova, R. D., Framework for service composition in g-Lite, American Institute of Physics, Conference Proceedings Volume 1404, 2011, pp. 218-224 Goranova, R. D., Development of ROOT Services for Grid, American Institute of Physics, Conference Proceedings Volume 1301, 2010, pp. 661-668 Grid Security Infrastructure (GSI), http://www-unix.globus.org/toolkit/docs/3.2/gsi/key/index.html g-Eclipse, http://www.geclipse.eu/index.php?id=86 P-GRADE Portal User Guide, Version 2.10, 2010, http://portal.p-grade.hu/manual/user/v210/UsersManualRelease2_10.html Triana 4 User Manual, http://www.trianacode.org/docs/userguide/UserGuide.pdf Taverna 2 Architecture, http://www.taverna.org.uk/developers/taverna-2-x/architecture/ Getting Started with Kepler, https://code.kepler-project.org/code/keplerdocs/trunk/outreach/documentation/shipping/2.3/getting-started-guide.pdf
