An Eclipse-based Environment for Programming and Using Service-Oriented Grid

Transcription

1 An Eclipse-based Environment for Programming and Using Service-Oriented Grid Tianchao Li and Michael Gerndt Institut fuer Informatik, Technische Universitaet Muenchen, Germany Abstract The convergence of Grid computing with Web service leads to the emergence of serviceoriented Grid. Despite the fact that more and more applications are being developed in the form of standard and custom Grid services, the development of Grid services and client applications lacks tooling support. We address this issue with an Eclipse-based environment for developing, using and managing Grid services and client applications for service-oriented Grid. This paper provides a general introduction of this environment and outlines the functionality and designs of the tools that constitute this environment. 1. Introduction Grid computing aims at coordinated sharing of distributed resources. With the evolution of Grid technology, it has been moving onto the Service Oriented Architecture (SOA). The convergence of Grid computing with Web service leads to the concept of service-oriented Grid, where Grid resources are represented by standardized or custom services that hide unnecessary details of the resource sharing from clients. Based on WSRF and other related standards, the research community has defined and implemented a set of standard services, including Resource Allocation Management (GRAM) and Reliable File Transfer (RFT) as part of the Globus Toolkit v4 [1], Data Access and Integration (DAI) and Data Query Processing (DQP) from OGSA-DAI [2]. Even more custom services are implemented that serve the need for specific purposes. 1 The development of Grid services and client applications in a service-oriented Grid has not been fully investigated. Grid services are programmed following predefined patterns which involve the development of numerous classes, interfaces and scripts. Development using the basic command-line tools provided by the Grid toolkit is tedious and error-prone, due to the complexity and highly coupling among pieces of code, interface definitions and scripts. Grid clients help Grid users to utilize the rich functionalities provided by the services on the Grid. Although command line clients can be used for simple Grid services, many Grid services provide comprehensive functionalities and demand graphical user interface. However, due to the dynamic nature of Grid systems, new applications are constantly deployed in the form of custom services. In order to support those custom services, the client must be extensible and customizable. This paper presents a comprehensive tooling environment for programming Grid services, developing custom client applications and managing Grid services in the infrastructure. The environment is based on Eclipse, and leverages its rich functionalities for Java and Web service development, as well as its support for component-based application development. Our focus here is to introduce the functionalities and design of the tools in the environment and give a rational explanation of our design decision for choosing Eclipse as the basic platform. The remaining part of this paper is organized as follows: Section 2 provides an analysis of the user roles and functional requirements of the different tools, which is followed by a dis-

2 cussion on using Eclipse as the underlying platform for our implementation in Section 3. Section 4 to Section 6 introduces three different tools each for the development of Grid services, accessing Grid services and managing Grid services in the Grid infrastructure. Related works are discussed in Section 7, and Section 8 concludes with a brief summary. 2. User Roles and Requirements The tools and environments are designed to meet the functional requirements of different user roles. This include service development tools that help service developers to develop Grid applications, execution clients that are used by Grid users to control the execution of jobs, and management environments that are used by Grid managers to administrate the Grid system. The above mentioned user roles are neither distinct nor mutually exclusive. There are chances that a specific person has multiple roles and needs tools for all those roles. For the user's convenience, the tools should be ideally able to be freely composed. Another noticeable fact is the overlapping of functions in different user environments. For example, both service client and management environment need to be able to explore existing services; both service development environment and the programming environment and management requires the functionality of service deployment. Components of different environments should be reusable. Grid client applications share some basic functionality that is needed for general purpose, which include the support for the most basic types of infrastructure services. For custom services that are domain specific, the client needs additional component to be adapted to a different scenario. Actually, due to the dynamic nature of the Grid, the actual types of services deployed in the service-oriented Grid system are always changing. Therefore, the extension for new service support should ideally be performed online. Due to the above mentioned reasons, the tools and environments need to be developed in a component-based approach that enables the reuse of components between different applications, free composition of application components, and online downloading of application components and dynamic extension capability. From a practical point of view, due to the rich functionalities that are demanded, the development of the tools and environments requires a lot work. Therefore, in order to derive a feasible development plan, it would be desirable to reuse existing tools. Besides, many users would like to use tools that they are accustomed to and it would be desirable that such tools can be integrated into the environment as well. Therefore, we need a platform that supports component-based application development with rich functionalities and third-party contributions. 3. Eclipse as Component Platform As is discussed in Section 2, we need a platform that supports component-based application development with dynamic update functionality and possesses a rich set of existing components that can be leveraged. The best platform that meets such criteria so far is Eclipse [3], which supports component-based application development with plug-ins that can be freely composed and dynamically updated. The ten different projects that are hosted on eclipse.org provide the Eclipse platform and much functionality that can be leveraged in our environment, including JDT for Java development and debugging, WTP for Web services development, EMF and JET for service modeling and code generation, and a lot more. It also has up to now about one thousand third-party plug-ins as is seen from the Eclipse Plugin Central [4]. Besides, Eclipse also has a lot more advantages that can be beneficial to our environments, including its support for native OS look and feel, role-based UI layout into perspectives, and its support for headless (command line) application, rich client applications and IDEs. 2

3 4. Grid Service Development Environment 4.2. Components and Dependencies The Grid Service Development Environment (GSDE) is the tooling environment for programming Grid services. We intend to make GSDE such a tool that supports the development of Grid services in a natural way that is familiar to most Java developers. It does impose additional requirements on the development process, and it should not restrict the developed Grid services to follow specific patterns. Two major design decisions contribute to the achievement of this goal: first, the separation of service modeling and code generation process from service development. Second, the design and development of incremental project builders that automatically handles the stub generation from WSDLs Functionality Major functions of GSDE are divided into three groups that can be used separately or collaboratively: Service modeling and code generation: GSDE supports the modeling of Grid services with user-friendly editors. Various properties and complex relationships between services and resources can be modeled, together with configuration aspects like service registration and security. The service model and templates are weaved together by the code generator to generate the code and scripts, which serve as the initial skeletons of Grid service code and can be modified at will. Service development: This include project creation, configuration and building support, deployment, execution and debugging of the developed service. Custom builders have been implemented that translates WSDLs to stubs, which is managed by the platform and cooperates with Java builder to automatically build the project in an incremental way. Service deployment: It allows exporting the project into GARs or deploying into different runtime servers, currently including Globus and Tomcat. Figure 1 is a screenshot of GSDE, which shows user interface for service modeling. 3 GSDE is a set of plug-ins that can be organized into three functional groups ( features in terms of Eclipse), each for modeling and code generation, project configuration and building, and deployment. Figure 2 shows the dependencies among the GSDE plug-ins, third-party plug-ins and Eclipse platform. The dashed lines denote optional dependencies. GSDE plug-ins has been designed and implemented to be composable so that different runtime configurations are possible. The availability of EMF and Tomcat Launcher plug-ins will decide whether a specific feature is available to GSDE. If EMF is not installed on the platform, the modeling and code generation feature will not be activated; and if Tomcat Launcher plug-in does not present, the feature for deploying the project into tomcat is deactivated. However, the basic core function for project creation, configuration and build will be working on most platforms as it does not depend on plug-ins not existing in the standard Eclipse platform. 5. Grid Service Execution Client The Grid Service Execution Client (GSEC) provides the basic functionalities and UI support for accessing the power of a serviceoriented Grid. It is intended to be used as the basis of custom client applications that can be customized or extended with plug-ins that contribute libraries and UI elements for additional custom services Functionality Figure 3 is a screenshot of GSEC that shows its basic layout. The basic functionalities of GSEC include: Generic Web service support: It maintains a directory of services, which can be managed by manual add/remote/modify, or can be selectively imported from an index service. It can be used to examine the WSDL of individual services, and monitoring SOAP messages.

4 WSRF and WSN support: Besides accessing the basic operations supported by WSRF and WSN services, it can also start local notification listeners that observe changes to resource properties. Index Service support: It allows the user to manage index services, and browse the content of index services. Agreement Service support: It integrates API library and provide UI components for accessing the WS-Agreement services. Some UI components can be integrated with those of custom services Components and Dependencies GSEC plug-ins can be schematically organized into several groups that are layered on top of each other. The first layer is a set of plug-ins that constitute the Core Service Client, including plug-ins that wrap the Globus libraries, plug-ins that provide fundamental functionalities and UI support for WSRF/WSN port types. The second layer is plug-ins that provide functional and UI for different services, including those for basic services like index service, broker service and agreement services that form the Basic Service Client, and those for custom services that form a Custom Service Client. Beneath the Core Service Client is the Eclipse IDE or RCP platform, and above them are plug-ins that provide advanced features based-on underlying layers. Figure 4 shows the dependencies among the plug-ins and their grouping into Core Service Client, Basic Service Client, and Custom Service Client. From a different view point, the architecture of the system can also be divided into UI layer and non-ui layer. The functional and UI contributions are separated into UI plug-ins and non-ui plug-ins, and it should be noted that non-ui plug-ins are not dependent on any UIplug-ins. This makes it possible to further develop a non-gui client based on the same architecture, based on the support of Eclipse for headless applications. 6. Grid Service Management Environment Grid system managers need support environment for administrative activities. Such activities include installation of Grid middleware, deployment of Grid services, monitoring Grid systems etc. It may also need to incorporate major functionalities of GSEC, because the Grid managers need to verify the deployed services. The Grid Service Management Environment (GSME) is developed as such a support environment for Grid managers Functionality Figure 5 is a screenshot of the basic layout of GSME. The basic functionalities of GSME include: System management: It allows accessing remote file systems and executing commands in remote shells. It is a reuse of the Remote Systems explorer and Remote Shell from Eclipse DSDP/TM project. System monitoring: Currently it reused plug-ins of GSEC to check the status of systems from information in the Index Services. Further work on integrating more advanced Grid monitoring systems has been planned. Grid service deployment: It can be used to deploy Grid service GARs on remote Grid servers. It reuses plug-ins that implements this functionality in GSDE. Service clients: It allows to do test run of the deployed services. It is based on the same functionality in GSEC Components and Dependencies GSME is developed by reusing existing plug-ins from GSDE, GSEC and Eclipse DSDP/TM. Figure 6 provides a simplified picture that depicts the composition of GSME. This serves as a good example of developing new tools by weaving existing components from applications on the same platform. 7. Related Work 7.1. Grid Service Development Tools 4

5 GT4IDE [5] was the first attempt to implement a development tool for GT4 based Grid services. It was built on top of Eclipse platform and JDT. It provides simple code generation functionality based on information provided in a wizard, and simple project configuration that creates the project structure and configures the class path. It relies on custom Ant scripts for project build which is not integrated with Eclipse build system. Due to its limited functionality and buggy implementation, GT4IDE is not applied in actual development work. It has, however, inspired our development of GSDE and similar works that have been progressed in parallel. The Grid Development Tools (GDT) [6] provides a programming environment similar to our service development tool. It requires the user to follow specific programming pattern by annotate Java interfaces with custom tags as means of service modeling. It is unable to model arbitrary relationships between Grid services and resources, and also restricts the user from programming complex services on top of the generated code. The Introduce Grid Service Authoring Toolkit [7] is a self-contained GUI that provides service modeling, code generation and service deployment support. As a stand-alone application implemented with Java Swing, it is not able to benefit from the rich functionalities of a real IDE like Java coding support, automatic build, interactive debugging and does not allow the integration of third-party tools Grid Service Development Tools The g-eclipse [8] project aims to build an integrated workbench framework on top of Eclipse to access the power of existing Grid infrastructures. The framework targets three user roles - Grid application developers, Grid application users, and Grid operators, and provides tools for application development, deployment and debugging, job management and monitoring, data management, as well as VO management, infrastructure configuration, monitoring and benchmarking. The current implementation 5 of g-eclipse is limited to glite. g-eclipse is designed to support standard Grid services only. Intel Grid Programming Environment (GPE) [9] provides an environment for using the standard services from Globus and Unicore. It provides several client applications for Grid users with different expertise and support environment for administrators. In addition to the standard Grid services, GPE allows to define higher-level custom services that take advantage of the standard ones. Service-specific user interfaces are defined with GridBeans, which are published in GridBean services and are dynamically integrated in different clients. Although the GridBeans allows GPE clients to display custom UI components for custom services, more advanced customizations that involves custom interactions of multiple services is not possible. Examples of simpler Grid client environments include those of P-GRADE [10], ASKA- LON [11] and GEMLCA [12]. All of them only work with standard or predefined services and does not support application-specific extensions or customizations. 8. Conclusion A comprehensive environment for the development, usage and management of applications in service-oriented Grid systems has been developed. The environment includes GSDE for Grid service development, GSEC as basic client platform for using application services on the Grid, and GSME for managing Grid services on the Grid infrastructure. All the tools are seamlessly integrated with the Eclipse platform, and can be freely composed according to the needs of the user as Grid service developer, Grid service user, or Grid system manager. They are also extensible and customizable for the usage in a special scenario. The environment and tools have been practically applied in our daily work. This includes the development of SLA management services and custom application services. Custom client applications based on GSEC has also been developed in our demonstrations.

6 Bibliography 1. Globus Toolkit homepage, 2. OGSA DAI homepage Eclipse homepage, 4. Eclipse Plugin Central (EPIC), 5. GT4IDE homepage, 6. g-eclipse homepage, 7. Thomas Friese, Matthew Smith, Bernd Freisleben, GDT: A Toolkit for Grid Service Development, Proc. of the 3rd International Conference on Grid Service Engineering and Management, pp , Shannon Hastings et.al., Introduce: An Open Source Toolkit for Rapid Development of Strong Typed Grid Services, Journal of Grid Computing, White paper: Intel s Grid Programming Environment, online available at Whitepaper.pdf 10. Péter Kacsuk et. al., P-GRADE: A Grid Programming Environment, Journal of Grid Computing, 1(2), pp , Thomas Fahringer et. al., ASKALON: a tool set for cluster and Grid computing, Concurrency - Practice and Experience, Vol. 17, Number 2-4, pp , Thierry Delaitre et. al., GEMLCA: Running Legacy Code Applications as Grid Services Journal of Grid Computing, Vol. 3, Number 1-2, pp ,

7 Figures Figure 1. Globus Service Development Environment (this screenshot demonstrates service modeling) Figure 2. GSDE architecture and dependencies of plug-ins. 7

8 Figure 3. Grid Service Execution Client serves as a base client platform. Figure 4. GSEC architecture and dependencies of plug-ins. 8

9 Figure 5. Grid Service Management Environment supports Grid service management. Figure 6. GSME is composed of plug-ins from GSDE, GSEC and DSDP/TM. 9