A user-friendly platform for developing and accessing grid services

Transcription

1 Inf Syst Front (2006) 8: DOI /s A user-friendly platform for developing and accessing grid services Hiroyuki Morohoshi Runhe Huang Jianhua Ma Published online: 27 October 2006 # Springer Science + Business Media, LLC 2006 Abstract This article presents an enhanced platform that provides a friendly environment of developing grid services and accessing grid services over Globus Toolkit 3 (GT3). This platform includes a class of functions for processing parameters input from a developer via GUI, a class of functions for generating files required for defining a grid service specified, and a class of functions for creating client program and facilitating accesses of the deployed services. As a result, the development and access of grid services requires less special expert knowledge of a developer at the server side and users at the client side, the efficiency of developing and accessing grid services can be improved. This paper describes our design ideas, necessary functions, and implementations. The comparisons with other related toolkits are given and the extended version of the platform on top of the web service environment rather than GT3. Keywords User-friendly interface. Grid service. Globus toolkit. Grid development platform. Automation of file generation 1 Motivations With rapid advances in network technology and distributed computing, grid computing is revealing its potential, and a global effort is being devoted to the development of an H. Morohoshi (*) : R. Huang : J. Ma Computer and Information Sciences, Hosei University, Tokyo, Japan i05t0009@k.hosei.ac.jp R. Huang rhuang@k.hosei.ac.jp J. Ma jianhua@k.hosei.ac.jp environment in, which individual users can access computer resources and facilities simply and transparently over networks (Foster, Kesselman, Tuecke, 2001). Globus Toolkit is one of the developing platforms for grid computing applications. Globus Toolkit 3 provides diverse fundamental functions of grid and has been widely used in not only the science field but also the business field. It emphasizes the concept of offering grid service instead of grid computing. An open grid services architecture defines standard mechanisms for creating, naming, and discovering transient grid service instances (Foster, Kesselman, Nick, Tuecke, 2002). Although Globus Toolkit 3 (GT3) becomes a standard toolkit with, which many grid applications and systems are developed on top of it. There are some drawbacks that prevent it being a popular development environment. It is rather difficult for a general user to install GT3 and set up configuration, environment, and security. It requires special expert knowledge on computer systems and programming skills on web service, grid service, and Java. It is not easy for a general user to write client side program for accessing deployed grid services. To solve the last two problems, this research is focused on developing a user-friendly platform on top of GT3 so as to facilitate easier development of defining grid services and accessing deployed services. The enhanced platform provides two classes of functions for defining grid services and writing a client program. A class of functions takes and processes inputted parameters or values and a class of functions automatically trigs execution commands, generates required files, and places them into appropriate locations. Relevant parameters and values for defining grid services and accessing deployed services are input from the user-friendly platform where users are provided sufficient

2 256 Inf Syst Front (2006) 8: information like hints, samples, templates, and given a wizard window when it is necessary. The developers can create grid services easily by using the platform even if they have less special expert knowledge of grid. 2 Related work The core infrastructure of GT3 is based on the open grid services infrastructure (OGSI) primitives and protocols. It specifies grid service for creating, managing, and exchanging information among entities (Tuecke et al., 2003). The main design goal has been to make the OGSI technology easy to use, reuse, and extend when developing new grid applications (Sandhold Gawor, 2003). It provides API and the tools for developing grid services. The following steps are involved in writing a grid service over GT3 (Globus Allience, 2004): Step 1, generate grid service code. Step 2, optionally add service data to the service. Step 3, create a grid service archive (GAR). Step 4, deploy the service. There are mainly two ways to generate grid service code (Sotomayor, 2004a,b). One is writing the interface in Java and then generating the WSDL interface. Another is writing the interface directly in a GWSDL port type definition. Figure 1 shows the process of writing a grid service over GT3. No matter,which approach is taken, it strongly requires developers having expert knowledge of either Java implementation or web service and grid service, for example, writing GWSDL file, WSDD file, and Mapping file. Writing WSDL interface directly is not easy and is verbose work. Although it is relatively easier for one who has Java programming skill to write service code in Java, the problem is that some complicated operations and requirements are not able to be expressed in Java. To develop grid services easily over GT3, Globus Toolkit plug-in for eclipse (Sotomayor, 2004a,b) developed by the Globus Alliance provides an environment that integrates all the steps from code to deployment. The advantage is that eclipse is a Java environment and plug-in for eclipse makes implementations of a grid services more effective in eclipse environment. Moreover, it provides the function to convert the implementation file to GWSDL automatically. However, the disadvantages are three fold: It provides only functions that mainly facilitate server side capabilities. It offers a limited number of functions such that developers are restricted to few grid services. It provides template files for developers to write services from Java interface, which limits developers free development. In order to access deployed grid services, it is necessary to write grid service client program. A grid service client can be written directly on top of the JAX RPC client APIs (Sandhold Gawor, 2003). Figure 2 shows the process of accessing a grid service. It mainly consists of the following five steps: Receiving the GWSDL file of a specified service from the server, Fig. 1 Writing a grid service over GT3

3 Inf Syst Front (2006) 8: CoG Kit itself is a quiet complicated commodity framework and it will take lot of time to get familiar with the framework and utilize its functions. 3 The enhanced platform Fig. 2 Accessing a grid service over GT3 Generating stub files from the received GWSDL file, Writing a client program by using a part of generated stubs, Acquiring grid service handle (GSH) from the server, and Accessing the service using the client program with acquired GSH (URI of the service). For facilitating the client access process, GT3 provides a number of utility classes. Even so, writing a client program is rather difficult for a general user since the user has to understand the JAX-RPC client APIs or GT3 utility classes APIs with knowledge of RPC (remote procedure call). The Java CoG Kit (Laszewski, Foster, Gawor, Lane, 2004) offers components for mainly client and limited server side capabilities (Laszewski, Foster, Gawor, Smith, Tuecke, 2000). The advantage is that it hides the complex infrastructure and provides convenient access to grid functionality through pure Java client-side classes and components. The disadvantages are three fold: It provides mainly client side functions and components. A user has to have Java programming skill and has to familiar with CoG Kit classes and components. Developing a grid service and writing a client program for accessing a grid service over GT3 are not easy to both grid service developers and the client side users. In the process of developing a grid service, a developer must define a number of files and execute commands manually, which requires specific expert knowledge and techniques. As for users who would like to access the deployed grid service, they have to have knowledge of using APIs provided by GT3 and making client program. For most of users, it is rather difficult. To enhance GT3 practical usability and the development of grid applications, this research is aimed at providing functions for both writing grid services and accessing the deployed service from the client side. In particular, the platform is emphasized on providing an easy environment that requires developers and users less expert knowledge. Concretely speaking, it automates some processes like defining configuration files, writing programs, generating stubs, deploying services, writing client program, starting the grid service container, and so on. It uses wizards to guide inputting the necessary the minimal required parameters and data. Though many functions are added in the platform, they are easy to understand and use since it provides a user-friendly interface. A user-friendly interface is designed with hints, samples, templates, and wizards to input the necessary minimal parameters and values. The rest of file generation, command execution, and service deployment are automatically conducted by the system itself. The platform has extendibility because of its open source. It is possible to add new functions to the platform by modifying some source programs according to the specifications. The position and role of the platform is shown in Fig. 3. It is in the intermediary layer between GT3 and OGSA. It is Fig. 3 The role of the enhanced platform Fig. 4 The client function menu

4 258 Inf Syst Front (2006) 8: Fig. 5 The wizard for the function, Run developed on top of GT3 and facilitates a part of OGSA services by providing various functions. GT3 accesses resources through the protocol layers, such as SOAP and GWSDL. The application in the highest layer uses OGSA services. 3.1 Available functions The platform provides three classes of functions for developing grid services, for accessing the deployed services, and for processing input parameters and values from the user interface, respectively The server side functions The server side functions for developing grid services are enabled from the menu in the user interface as shown in Fig. 7. Generate_Service generates a service package including files and folders required for writing a grid service. The minimal required information for writing a grid service such as service name, base package, is input from a wizard window and stored in the.service_info file, which is to be accessed by other functions. Delete_Service deletes a service from a group of the generated services. Concretely, it deletes some files and the list of service information in.service_info. Generate_GWSDL_from_Interface generates a GWSDL file from the Java interface. First, the Java interface is converted to WSDL by using tool, and then it is parsed and converted to GWSDL,which describes various information of a grid service. Set_Service_Data is an optional function and only executed when a developer wants to add the service data to a grid service by defining service data elements and their properties from a wizard window. Service data is a structured collection of information that is associated to a grid service. Generate_Stub_Files generates the stub files by using ant tools. The build folder is generated and put in the service package, and then the stubs folder including the stub files is generated and put in the build folder. The stubs are used for communications between the server and the client, and they are imported into the Java implementation file. Generate_Implementation_from_GWSDL generates a Java implementation file from GWSDL. The elements in GWSDL are converted to the methods in the Java implementation file. Moreover, the developers can add Java code using provided template and selecting the items that they want to implement. The comments to the methods, the types of parameters and the method names can be saved to the file in the XML form named Method_Details_Of_<Service Name>.xml via the interface. The information about methods of a grid service is very useful for the client side user to better understand details of the service provided by the server. Build_Files generates the GAR file from all files including the service stubs, WSDD file, the code added by the developer, and so on. The generated GAR file as a developed grid service is to be deployed into the grid service container. DeployService unpacks the GAR file and copies the files (WSDL, compiled stubs, compiled implementation, WSDD) into the specified locations in the GT3 directory tree by using ant tools. Once the Globus container starts, the deployed service will be available. UndeployService removes services and deletes the files from GT3. Globus_Container includes two functions, start and stop. If start is selected, the container is started, and if stop is selected, the container is stopped. Normally, the Fig. 6 The wizard for generate a new service

5 Inf Syst Front (2006) 8: Fig. 7 The user-friendly interface list of the services GSH in the Globus container will be displayed on the console. Export_GWSDL exports the folder or the zip file containing GWSDL and XML for the client side. It helps to generate client side stubs and write the implementation files by importing and using them The client side functions The functions available for accessing and running grid services are enabled from the menu of the user interface as shown below in Fig. 4. They are briefly described below. Generate_Client_Stubs_from_GWSDL imports GWSDL file from the server and generates stubs. The path for storing GWSDL and XML, and the directory for putting stub files should be specified by the client side users. Delete_Client_Stubs deletes the stubs in the client side but not GWSDL, the XML file or the zip file that are imported. Those files remain. Generate_Client_Files generates a client package for accessing a deployed grid service. The client folder is created and it includes Service_Name under,which there is the Java_Client file. The Java client file is generated according to service information stored in the.service_info file. After selecting a deployed service, the list of methods provided by the deployed service, the types of parameters, and some descriptions are displayed. The implementation code can be added to any method if it is necessary by selecting a method from the template. Create_Service_Instance creates a service instance and returns the instance s reference (the instance location). The Java client file runs the service with the created service instance. Destroy_Service_Instance destroys the service instance when it is no more in need. Run runs and accesses the service with some arguments from the client site as shown in Fig. 5. Fig. 8 The wizard for selecting a service

6 260 Inf Syst Front (2006) 8: A client user specifies the path of the Java file directory or selects it from the list. If the user wants to add the arguments, he/her inputs them from the text area. 3.2 The user-friendly interface The user interface is designed friendly for easily to developing grid services and accessing the deployed services. In designing a friendly interface, it is important to have a class of functions grouped together, to have operations consistent, and to have searching function and assistant wizard available (Ambler, 2000). It is necessary to have help page to make users understand the functions (Welie et al., 2001). Figure 6 shows a wizard window for generating a new service. Where, the region A presents a list of items, the region B gives the text input fields associated with the region A. The region C is a text area for displaying explanations or suggestions. If the cursor points to an item in the region A, the explanation referring to the item is given in the region C, and if the cursor points to an input text field in the region B, hints, suggestions, or default example data/value for the user are displayed in the region C. There are some other similar wizards for assisting adding service data to a service, developing a client program, and so on. As it can be seen that it is a user friendly wizard window, in particular, it is convenient and easy for those who are lack of specific expert knowledge of generating services. The main user-friendly interface is presented in Fig. 7. Each menu is given an intelligible name and groups a class of functions together. There are three basic groups of functionalities: developing grid service, accessing the deployed services, and processing inputs. By dragging the mouse to the menu, Server_oper(S), a list of functions in the region D is displayed. The order of the functions in the list is supposed to give a hint or reminder of the service development order. If some parameters or data are required, an input wizard window will be popped up. When what to input is not sure, one can open a sample file and refer to the default inputs. The menu, Help, provides explanations and hints. Once some operations are conducted, the files and folders are simultaneously displayed in the regions E and F It is possible to revise the files directly from the regions E and F if it is necessary and the revised source code in the text area can be saved by pressing the Save button. The status progress of the processing can be viewed by pressing the progress bar in the region G. The processing status is displayed in the Console marked as H. The region H for display can be switched between the Globus container and the Console. If the function, Generate GWSDL from Interface, is selected, the wizard window shown in Fig. 8 is popped up. When a new service is created, it is classified into a Fig. 9 The working flow of the functions

7 Inf Syst Front (2006) 8: category. For example, math service and arithmetic are in the same category, calculation. The service categories are displayed in the tree structure. A target service can be searched from the category tree, and selected for execution. The classified services are easy to manage and operate. 4 Implementations The platform is implemented in Java. The implementation mainly consists of the graphics user-friendly interface (GUFI) and all functions behind the GUFI. Some functions are grouped together. Some functions require information or data as input parameters. GUFI provides interfaces and wizard windows to facilitate it. Figure 9 gives an overview of the platform function groups and their working flow. Of course, the necessary information or data for creating a service are input from the user interface in each step and the input information is stored in the Service Information Manager stored. Information/data is to be used by the functions in the Service Package, the Other Server Operations, thegenerate Client, the Other Client Operations, and the Client Package. When executing some functions in the Other Server Operations or the Other Client Operations, some functions require information/data input from GUFI and/or stored in the Server Information Manager to generate some files to be put into the Service Package or the Client Package. Finally, a defined service package (grid service archive, GAR) is deployed to the Globus Container (Fig. 10). 4.1 Implementation of the server side functions The server side functions include the Generate Service and the Other Server Operations. All functions provided by the platform are listed in the Server_Oper(S) Generating a service When the menu, Generate Service of Server_Oper(S) is clicked, the dialogue window appears. Data/information is Fig. 10 The class, ServiceInformation

8 262 Inf Syst Front (2006) 8: Package are either written directly by a developer or generated and updated by performing other server operations Generating GWSDL from a Java interface Although all files are generated and included in the service package, some of them are necessary to be filled in with the concrete content related to a specified service and Java interface. A Java interface is defined from the user interface by following the wizard provided by the system. The file, GWSDL can be generated automatically from the Java interface or can be written directly. Figure 12 gives an example, the method add( ), to show what contents are generated in the files, WSDL and GWSDL, corresponding to a defined Java interface. The tools, Java2WSDL and Jaxp, are applied to convert a Java interface to WSDL and GWSDL files. When the operation, Generate_ GWSDL_ from_interface is selected from the menu, the event trigs the tool, Java2WSDL. Java2WSDL takes the defined Java interface as an argument and converts the methods into a WSDL file. It puts the method name before the keywords, Request and Fig. 11 The hierarchy of the generated files to be input or default data/information is to be used for generating a grid service. The input or default data/information is taken and stored in the Service Information Manager by a set of set( ) methods and Vector objects in the class, ServiceInformation. The stored data/information can be retrieved when any operation in the Other Service Operations is performed. If the operation is related to the Service object, the information about the service object is retrieved using the service name by the method, getservices( ) in the class, ServiceUtilities. If a target value is required in any operation, the target value is retrieved by the method, get( ) in the class, ServiceInformation. When the Generate Service operation is performed, a service package is generated by a sequence of action methods in the class, CreateServiceFolder. The hierarchy tree of holding the generated files and folders in the service package is presented in Fig. 11. The file names with the underline except for the files, GWSDL, XSD, and WSDL are the names given by a developer via the user interface. The file or folder that is linked by a thick line is the file or directory later created by calling other functions. The files, Java Interface, WSDL, GWSDL, XSD, and Java Implementation in the Service Fig. 12 The WSDL and GWSDL generation

9 Inf Syst Front (2006) 8: Response in message nodes and the arguments of the method in part nodes of the WSDL file. Then the tool, Jaxp is trigged and it converts the generated WSDL file into GWSDL file. It in fact parses the WSDL file according to the XML parser of Jaxp and rearranges the contents in a DOM tree. The name attributes of a message node in WSDL are mapped with the name attributes of the element nodes in GWSDL. Of course, there are other mappings and additions as shown in Fig Setting service data When it is necessary it is able to add some service data to the grid service by clicking the function, Set_Service_Data from the menu, Server_Oper(S) in the user interface, a wizard window is popped up and the necessary data/ information for the service data is input from the window. The input data referring to the properties of the service data is set to the attributes of the servicedata node in GWSDL. The attribute defines various properties of service data element (SDE), for example, the minimum and the maximum number of values that the SDE can have. The input data referring to the name and type of internal value of SDE is set to the ComplexType node in XSD as shown in Fig Generating Java implementation file Once having GWSDL file, the Java implementation file can be generated from GWSDL. Similarly, the tool, Jaxp is applied to such process as shown in Fig. 14. GWSDL in the form of a DOM tree has element nodes that are the child elements of the scheme. Those elements are added to the Java implementation file. Concretely speaking, the name attribute of an element node is the method name in Java implementation file. If the name attribute has a keyword, Response attached, it means the method has a return value with defined type. The platform parses GWSDL and displays the types of the arguments and the return value to the wizard. One can directly add the code to the Java implementation file by selecting the item that he wants to implement from the provided template. Comments on methods defined in the Java implementation files can be also freely added via the wizard to make them more readable and intelligible for the client side users. Then the contents added from the wizard are converted into the XML as shown in Fig Export GWSDL To access the developed services, the client should generate the stub files. It is necessary to acquire GWSDL that the server provides to generate the client side stubs. This function exports GWSDL and XML in the folder or zip file. It makes accessing service possible by importing it from the client side as shown in Fig Implementation of the client side functions After the completion of generating a grid service, the grid service archive (GAR) is deployed to GT3 container, which is ready for accessing from the client users. The platform provides a client program that enables the client side users to access the deployed grid services. There are mainly the following steps of accessing the deployed grid services. Step 1, generates stubs from the imported GWSDL or WSDL. Step 2, writes the client program by using a part of generated stubs. Step 3, runs the program and accesses the grid services, the grid resources and methods provided by the server. To be able to conduct these three steps, the client side users must have the special knowledge of generating stubs Fig. 13 Adding service data into GWSDL and XSD

10 264 Inf Syst Front (2006) 8: Fig. 14 From GWSDL to Java implementation and writing client program. It is also time-consuming to write the client program from the scratch. Moreover, the users should understand well about the functions and the methods of the deployed services provided by the server before they are able to write a client program such as the names of methods, the type and meaning of the arguments and the return values of the methods, and so on Generating stubs from GWSDL As it was described above, the generated GWSDL and XML (comments on methods) are exported at the server side. It is ready for the client side function to import the GWSDL and XML files. Using the imported GWSDL file, the client side stubs can be automatically generated. The partial generated stubs are used in the process of generating the client program together with the XML file and information/data as shown in Fig Generating a client package The client program is generated by selecting the function, Generate_Client_Files from the menu, Client_Oper(C). Of course, this process consists of three steps: selecting the methods from the popped up wizard window where all detailed descriptions and comments on each method are available, inputting necessary information/data for generating client program such as path for the client package and other parameters from popped up dialogue window according to the wizard guidance or using the default setting and parameters, and using the partial of the client side stubs previously generated according to the methods selected. Apart from specifying a deployed service and selecting the methods of the specified service to access, other processes can proceed according to the wizard guidance or completely automate using the default setting and parameters. It does not require users much expert knowledge to generate the client program. Fig. 15 Adding codes and comments Fig. 16 Exporting and importing GWSDL and XML files

11 Inf Syst Front (2006) 8: Fig. 19 The Java code necessary for obtaining service information Fig. 17 Generating the client program Other client operations Other client operation functions are Create_Service_Instance, Destroy_Service_Instance and Run. They are used for the client side users to easily access the deployed grid services. First, the client creates the service instance and gets the GSH by the function Create_Service_Instance. Then, the client accesses to the created instance from the received GSH. Finally the created service instance can be destroyed when it is not used anymore as shown in Fig Flexible for developers to add more functions to the platform The platform is written in Java and its source codes are completely open, which allows developers to flexibly customize their development environment on top of the platform. For example, adding more functions or methods by rewriting or revising the related program files according to the specification of the platform. The new created functions are added to Other Server Operations at the server side or to Other Client Operations at the client side. In the process of adding functions or methods, the service information such as service name, fold directory are necessary, which can be obtained from Service Information Manger. Figure 19 shows the partial source code of acquiring related service information. To update menu bar with newly added functions or methods, it is necessary to rewrite or revise two source programs, MenuBarComponent.java and MenuBarListener.java. The MenuBarComponent class is for generating the menu of GUI and the MenuBarListener class is for processing the event. 5 Comparisons with the related work The functions and features of the enhanced platform is evaluated and compared with other tools. The comparisons with the Globus Toolkit plug-in for Eclipse and Java CoG Kit are given in Table 1. The enhanced platform has two features that should be emphasized. One is that it is aimed at facilitating capabilities of both creating grid services and accessing the deployed services. While the Globus Toolkit plug-in for eclipse is mainly focused on providing easier environment only in eclipse environment for developing grid services with less consideration of client program that runs and accesses the deployed services. In reverse, the Java CoG Kit is mainly for providing client side functions and components with little consideration of writing grid services. Another feature of the enhanced platform is that the platform is designed for naïve developers who have less Table 1 The comparisons with other tools Globus Toolkit plug-in for eclipse over GT3 Implementing a grid service only in eclipse Server side functions only Java implementation > GWSDL Limited functions Only one way to write service codes The enhanced platform Implementing a grid service in any Java enable environment Both server and client side functions Java interface > GWSDL > Java implementation Relative more functions Two ways to write service codes Fig. 18 Accessing a service instance Java Cog Kit Mainly rich client side functions The enhanced platform Both server and client side functions

12 266 Inf Syst Front (2006) 8: Fig. 20 Developing a Web service special expert knowledge about Java programming, web service and grid service programming. Without knowing of the detail about infrastructure, writing Java code, and writing (grid) web service descriptions, developers can write grid services, run the deployed services and access the services with assistant of the user-friendly interface and wizard guidance. Besides, the enhanced platform enables two approaches in writing service codes. While the Globus Toolkit plug-in for eclipse facilitates only one approach of writing Java Interface, which limits developers free development, requires developers having Java programming skill, and causes a problem when some operations cannot be expressed in Java. Another inconvenient point of the Globus Toolkit plug-in for eclipse is that it does not provide service deployment function while our enhanced platform has the function. Of course, regarding implementations of designate functions, the Globus Toolkit plug-in for eclipse is more effective in eclipse but it is not applicable to other environments. Fig. 21 The comparisons

13 Inf Syst Front (2006) 8: their differences in Fig. 21 are mainly in the following aspects (Armstrong et al., 2005): GT3 versus JWSDP GWSDL versus WSDL Stubs generated from GWSDL versus from WSDL Globus container versus web service container Fig. 22 The current version versus the extended version 6 Discussions on the extension of the platform So far this article has been focused on describing the enhanced platform developed on top of GT3 environment. However, one of the disadvantages for GT3 is that it is rather difficult for a general user to install GT3 and set up configuration and environment. The idea is that it would have more widely and practical use if the enhanced platform can be extended and run on top of a more general and easy environment like the Web service environment since the use of the Web service environment is much easier for a general users and a few automated installers are available. However, whether it is possible for the platform to run on the Web service environment with some extended functions and modifications is discussed in this section. 6.1 The difficulty encountered Figure 20 shows the process of developing a web service with Java API for XML-Based RPC (JAX RPC) and Java Web services developer pack (JWSDP). Compared with the process of developing a grid service with GT3 in Fig. 1, It seems if we place the necessary tools, such as GWSDL2WSDL, GWSDL2Java, etc., in the platform on top of the Web service environment, automation of the processes of generating required files for a grid service would not be a problem. However, the difficulty encountered is that we have not found any solution so far to use the web service container instead of Globus container. The difficulty is due to the differences between a grid service and a web service. A web service is stateless and nontransient service but a grid service is not and their differences are reflected in their difference containers, the grid service container and a Web service container (Sotomayor, 2004a,b). If there will be a solution to this problem, it will be possible to automatically developing grid services over our enhanced platform on top of Web service environment with some extended functions and modifications to our current version of the platform. We will continue this study as our future work. 6.2 The grid service access on top of JAX RPC The grid service system is developed to enhance the web service system such that they share many common design principles and file formats and even some tools. Although developing a grid service over the enhanced platform on top of Web service environment faces a difficulty, it is possible to access a deployed grid service over the enhanced platform on top of the Web service environment instead of GT3 with some extended functions added to the enhanced platform. As we know that a client side user can access a deployed grid service by having only GWSDL file. If at the client Fig. 23 The process of accessing to resources on top of GT4

14 268 Inf Syst Front (2006) 8: side, there are required the tools that can generate stubs from GWSDL, the remaining work for the client side user is to specify the methods of the grid service to access and input necessary parameters via the wizard window. The information about methods and input parameters together with the associated partial stubs are sent to the client program at the server side. The access of a specified grid service is conducted via the client program. To achieve this, it is necessary to import the necessary tools from GT3 to the enhanced platform. The tools are activated from the platform rather than from GT3 as shown in Fig. 22. Therefore, the client side users can access the deployed grid services over the platform without need of installing GT3, which greatly reduces the client side s workload. installation of GT3 environment, which greatly reduce the client side installation and configuration load. Although it proves its convenience and development efficiency, there are still lots of remaining work and further improvements for future. There are mainly as follows: providing more functions to further improve the interface; further study on the extended version of the enhanced platform, which requires a lighter environment, possibly Web service environment, rather than GT3 for both grid service development and access; corresponding to the latest Globus Toolkit (GT4); enabling client users to access the deployed service from a mobile environment and other ubiquitous devices. 6.3 Extension for Globus Toolkit 4 Globus Toolkit 4 (GT4) is the latest version of Globus Toolkit (Foster, 2005). The main difference between GT3 and GT4 is that GT4 includes a complete implementation of the Web services resource framework (WSRF) specification (Czajkowski et al., 2004) instead of OGSI. However WSRF and OGSI are conceptually the same (Sotomayor, 2005). WSRF is similar with OGSI but it takes into account all the comments from both the grid community and the Web services community. As a result, it is a more polished and stable standard. Consequently, it is reasonable for the model of the platform to remain same for GT4 but there are some revised steps for the client side users to access to the grid resources. Step 1, generate stubs from WSDL Step 2, implement and run the client access program Step 3, creates resource by factory service Step 4, performs operation on a specific resources by instance service The process of accessing the deployed grid service is shown in Fig. 23. The platform provides some functions to facilitate these processes. For example, automation of stubs and client program generations. The accessibility to the distributed resource will be improved. 7 Conclusions and future work This paper describes a user-friendly platform for developing grid applications on the top of GT3 with two emphases: providing functions for both server side and client side developments, and designing a user-friendly interface together with provided functions for naive developers and users. Compared with other related platforms, our enhanced platform has its features and advantages. In particular, the extended version of the enhanced platform enables the client users to access the deployed grid services without References Ambler, S. W. (2000). User interface design: Tips and techniques. Cambridge, UK: Cambridge University Press. Armstrong, E., Ball, J., Bodoff, S., Carson, D. B., Evans, I., Green, D., et al. (2005). The J2EE 1.4 Tutorial. Retrieved September 9, 2005, from the Sun Microsystems Web site: j2ee/1.4/docs/tutorial/doc/index.html. Czajkowski,K.,Ferguson,D.F.,Foster,I.,Frey,J.,Graham,S.,Sedukhin,I., et al.(2004).the WS-Resource Framework. Foster, I. (2005). Globus Toolkit version 4: Software for serviceoriented systems. In IFIP international conference on network and parallel computing, LNCS 3779 (pp. 2 13). Berlin Heidelberg New York: Springer. Foster, I., Kesselman, C., Nick, J., Tuecke, S., (2002). The physiology of the grid: An open grid services architecture for distributed systems integration. In: Open grid service infrastructure WG, global grid forum. Foster, I., Kesselman, C., Tuecke, S. (2001). The anatomy of the grid: Enabling scalable virtual organizations. International Journal Supercomputer Applications. Japan IBM System Engineering (2004). What is grid computing. Japan: SoftBank. Laszewski, G., Foster, I., Gawor, J., Lane, P. (2004). A Java commodity grid kit. Retrieved December 14, 2004, from Java CoG Kit web site; Laszewski, G., Foster, I., Gawor, J., Smith, W., Tuecke, S. (2000). CoG Kits: A bridge between commodity distributed computing and high-performance grids. ACM java grande 2000 conference. Sandhold, T., Gawor, J. (2003). Globus Toolkit 3 Core: A Grid Service Container Framework. Retrieved December 19, 2004, from the Globus Alliance Web site: toolkit/3.0/ogsa/docs/gt3_core.pdf. Sotomayor, B. (2004a). The Globus Toolkit 3 Programmer s Tutorial. Retrieved November 12, 2004, from the Globus Toolkit Web site: Sotomayor, B. (2004b). A Globus Toolkit Plug-in for Eclipse. Retrieved December 20, 2004, from SourceForge.net Web site: Sotomayor, B. (2005). The Globus Toolkit 4 Programmer s Tutorial, Retrieved November 26, 2005, from the Globus Toolkit Web site: The Globus Allience (2004). Grid Service Development Tools Guide. Retrieved December 14, 2004, from the Web site:

15 Inf Syst Front (2006) 8: Tuecke, S., Czajkowski, K., Foster, I., Frey, J., Graham, S., Kesselman, C., et al. (2003). Open grid services infrastructure (OGSI) version 1.0. Global Grid Forum Draft Recommendation. Welie, M., Vliet, J. C., Veer, G. C., Eliens, A., Paterno, F., Rauterberg, M., et al. (2001). Tasked-based user interface design. The Dutch Graduate School for Information and Knowledge Systems. University of the West of England, UK, in She worked at National Defense University of Technology as a lecturer during the period In 1988, she received a Sino-Britain Friendship Scholarship for her Ph.D. study in UK. She was working in the Computer Science and Engineering Lab of University of Aizu for 7 years. She is now working as a professor in Hosei University. Dr. Huang has been working in the field of Computer Science and Engineering for more than 20 years. Her research fields include Computer Supported Collaboration Working (CSCW), Artificial Intelligence Applications, Multimedia and Distributed Processing, Genetic Algorithms, Distributed Multi-agents, Ubiquitous Computing, and Mobile Computing. Hiroyuki Morohoshi is a graduate student in the Faculty of Computer and Information Sciences, Hosei University. His research fields include Multimedia and Distributed Processing, Ubiquitous Computing, and Mobile Computing. Runhe Huang received her B.Sc. in Electronics Technology from National Defense University of Technology, China, in 1982, and her Ph.D. in Computer Science and Mathematics from the Jianhua Ma is a professor at Digital Media Department in the Faculty of Computer and Information Sciences, Hosei University. Before joining Hosei University in 2000, he had worked for 7 years at National University of Defense Technology (NUDT), 3 years at Xidian University in China, and 5 years at the University of Aizu in Japan. He received his B.E. and M.E. in Communication Systems from NUDT, and PhD in Information Engineering from Xidian University in 1982, 1985, and 1990, respectively. His research interests include ubiquitous/ pervasive computing, mobile multimedia, P2P communications, collaborative systems, proactive and autonomic multi-agents, context aware applications, integrations of cyber and real worlds, etc. Contact him at jianhua@k.hosei.ac.jp.