A Grid-based Problem Solving Environment for GECEM - CiteSeerX

Download PDF
0 downloads 0 Views 136KB Size Report
Comment
Cardiff University. 5 The Parade, Roath. Cardiff CF24 3AA maria,david@cs.cf.ac.uk. Yu Chen and Jason W. Jones. Civil and Computational. Engineering Centre.
A Grid-based Problem Solving Environment for GECEM Maria Lin and David W. Walker School of Computer Science Cardiff University 5 The Parade, Roath Cardiff CF24 3AA maria,[email protected]

Abstract Grid-enabled portals are becoming increasingly popular as a means to create Grid-based problem-solving environments (PSEs) that allow scientists to access distributed resources, and to monitor and execute distributed Grid applications from a Web browser. Resource sharing using such computational Grid portals enables geographically distributed partners to analyse large-scale and collaborative computational electromagnetics (CEM) simulations. In this paper, we describe a web-based portal based on the GridSphere portal and portlets that deploys services at the back end for discovery and management of distributed resources, and for invoking services for mesh generation and CEM simulation. In addition, the migration of the CEM simulation code to remote platforms is also supported.

1. Introduction Grid-based computational science portals have become increasingly popular to allow scientists to perform collaborative research and share resources that are geographically dispersed. Scientific simulations are complex and a grid portal can provide an easy-to-use interface for users to access distributed resources and hide the complexities of the scientific simulation. Example of Grid portals can be found in [1]. An application such as computational electromagnetics (CEM) is a suitable candidate for use of the Grid. CEM is of increasing importance to the civil and defence sectors. It is central to important problems such as predicting the electromagnetic compatibility between complex electronic systems, and the response of systems to lightning strikes and electromagnetic pulses. These issues are of key concern in possible future platforms such as the More Electric Aircraft

0-7803-9074-1/05/$20.00 ©2005 IEEE

Yu Chen and Jason W. Jones Civil and Computational Engineering Centre School of Engineering University of Swansea Swansea SA2 8PP Y.Chen,[email protected]

(MEA) and the All Electric Ship (AES). Large-scale CEM simulations are computationally intensive, and can involve access to resources that are intrinsically distributed. For example, in the case of an ”extended enterprise” in which multiple partners from industry and academia are cooperating to design and build a complex system that requires CEM simulations, the geometry of a component may be created at one location, a mesh conforming to this geometry may be generated at a second location, and a CEM simulation based on the mesh may be performed at a third location. Finally, the output from the simulation may be analysed and visualised at one or more other locations. In this paper, we describe the Grid-Enabled Computational Electromagnetics (GECEM) portal, and in particular show how the solver code may be migrated on-the-fly to be executed at a remote location. This extends previous work presented at AHM2003 [17] and AHM2004 [12, 13]. This work supports collaborative simulation and access to distributed resources among the different project partners in the GECEM project. In particular, the GECEM portal has been designed to support the generation of a computational mesh using a meshing service at the University of Wales, Swansea, the solution of a CEM problem on this mesh on a supercomputer at the Singapore Institute of High Performance Computing, and the collaborative visualisation of the results by participants at Cardiff University and BAE SYSTEMS in Bristol [17]. The rest of this paper is organised as follows. Section 2 gives the background to the GECEM project and the work presented in this paper. Section 3 presents the components of the portal: the GridSphere Portal and the Grid Portlets web application [7]. Section 4 describes the core portlets of the GECEM portlet service model, while section 5 describes the service model of these grid services. Section 6 describes how these portlets and services work together. Section 7 points to related work, and section 8 concludes

and outlines further work.

2. Background The motivation for the GECEM project comes from the fact that the relevant resources of the project partners are intrinsically distributed. In such a situation, the partners in the extended enterprise may be prepared to share data (the geometry, the mesh, the simulation output), but often not the proprietary software systems and the hardware that generate the data (the mesh generator and CEM solver code). Thus, it is not feasible to place all the data, computer, and human resources in one geographical location. The Grid, therefore, is an excellent candidate for providing the infrastructure needed to support extended enterprises. It should be noted that “extended enterprise” has essentially the same meaning as “virtual organisation” [5]. The first version of the GECEM grid was originally implemented using GT2 [17] using a shell script to access the resources remotely, transfer the files, and run the mesher and the solver codes remotely. However, this first version of the GECEM grid has created some difficulties. For example, there is no means of applying for access to all resources. Instead, the user must apply to each site for access. In addition, it is difficult for the user to run the script as there is no user interface, apart from a command-line script. In previous work [12] we used GridSphere as a computational science portal and the Grid portlets web application for credential management and job submission. Particularly, we used a Java-based API script to invoke the Job Submission Service provided by GridPortlets to submit jobs to GRAM to run the mesher and solver services. However, this method is not scalable and users have no flexibility to discover and choose the source of the data files and the mesher and solver services. To make it easier for users to access the Grid resources, we have enhanced the grid-enabled portal to have a better user interface and have implemented the mesh generator and CEM solver as independent OGSA-compliant grid services. These grid services are run locally on the server side. To allow for solver migration, the location of input and output files are passed to services as URIs, and a Migrate App Grid Service has been designed to migrate the executable solver to a specified remote site. The underlying idea is to use a service-oriented architecture based on emerging standards such as the Open Grid Services Architecture (OGSA). The advantage of using OGSA is that it allows us to provide users with access to GECEM-specific services without creating individual accounts as required by GT2. Thus, the difficulty with the inflexibility of creating individual user accounts in GT2 is reduced [17]. To provide a better portal interface we have extended the

work in [12] with the following changes. For work related to the Grid Portlets web application, we no longer use the Job Submission Services provided by Grid Portlets. Instead, we have implemented meshers and solvers as grid services that wrap legacy codes. To support solver migration, we have added a Migrate App Grid Service and portlets to invoke it. In addition, the most recent version of Grid Portlets uses GridFTP for file transfer instead of the Reliable File Transfer (RTF) Service, so we accordingly use GridFTP. For the part of the work related to the GECEM portal we have incorporated the following features: • File transfer using GridFTP. • A better user interface that specifies input and output files for mesher and solver services as URIs. • Service publication and querying using a UDDI registry. • Meshing and solver implemented as grid services. • Job migration implemented as a grid service.

2.1. Implementation The GECEM Portal is implemented using GridSphere 2.0 and Tomcat 4.0.30, and Globus Toolkit GT3.2. GT3.2 is a Java reference implementation of OGSI, and provides mandatory Grid service features, such as service invocation, lifetime management, a service data interface, and security interfaces that rely upon underlying Public Key Infrastructure (PKI).

3. The GECEM Portal The GECEM portal is a problem-solving environment (PSE) [18] composed of a collection of portlets and services. The PSE provides the main interface through which services are accessed. The PSE will support the composition of applications from service-based components, the execution and monitoring of such applications on remote resources, and collaborative visualisation, exploration, and analysis of the application results. In addition, the PSE also provides an interface to meshing services, solver services and supports the collaborative visualisation of meshes. The GECEM portal is made up of the GridSphere Portal [14, 8], the Grid Portlets web application, and GECEM Portlets. The GridSphere portal server and GridPortlets were both developed by the GridLab team. The advantage of coupling GridSphere and GridPortlets is that they fully support OGSI Globus Toolkit 3.X. In addition, GridSphere and OGSA can be hosted under the same container to allow a portal to host grid services.

The GECEM portal is implemented using a multi-tiered system architecture: the client web browser, the portal, and the grid services at the back-end. Figure 1 presents the portal in which users logon to GridSphere and configure their MyProxy credentials using GridPortlets. The GECEM portlets are then used to select the resources and files needed to execute a job and then submit it.

Logon

request a certificate and stores a proxy certificate in a secure MyProxy Server with a temporary password. When the user logs onto the GECEM portal, the user enters the password and the portal server contacts the proxy server and loads the proxy. The portal server will hold the proxy for the user for a short period of time specified in the user’s session state. By using the MyProxy package, users can use the portal to gain access to remote resources from anywhere without requiring their certificate and private key to be located on the same machine/device running the web browser.

Portlet

Myproxy Service

GRIDPORTLETS

Credential Retrieval Portlet

3.2.2. Credential Retrieval Portlet

GRIDSPHERE

Resource Browser Portlet File Browser Portlet (GridFTP)

GECEMPORTLETS Meshing

Migrate Solver

Portlet

Portlet

With the credential retrieval portlet, a user can view their local credential, renew a credential, revoke certificates, generate a certificate request, and store credentials on a MyProxy server. These portlets are useful for securely authenticating users to remote resources, and for users to delegate their certificates to a MyProxy server for later retrieval and login. By configuring GridSphere with GridPortlets, users can logon using their MyProxy password.

Figure 1. GECEM Portal overview 3.2.3. Resource Browser Portlet

3.1. GridSphere The GridSphere portal provides a portlet container, and a set of core portlets and portlet services that provide the basic framework for user management, session management and group management, as well as layout customization and portlet subscription. It also provides built-in support for role-based access control (RBAC), separating users into guests, users, administrators, and superusers. The availability of a high-level portlet model allows developers to build complex portlets using visual beans and the GridSphere User Interface (UI) tag library. The GridSphere framework is based on the widely-used “portlet model”. A portal web page is composed of portlets that provide “mini-applications” each represented as a visual window similar to applications in any other desktop environment that can be minimized or maximized.

3.2. GridPortlets A GridPortlets web application, composed of a collection of portlets and services, allows end-users to make use of Grid technologies. Specifically, it offers portlets for certificate and credential management, which are used to authenticate the user through MyProxy. 3.2.1. Security with MyProxy To use the grid resources, the user needs to contact the portal server with a valid “proxy certificate”. First, the user has to

The resource browser portlet allows a user to select a machine in the GECEM grid. A list of machines is hand-edited beforehand in an XML Resource Registry file, which is accessible by the GridPortlets web application. This file defines the available services and the machine names responsible for these services. For example, the machines for MyProxy and for GridFTP. 3.2.4. File Browser Portlet GridPortlets provides a File Browser Portlet to allow users to transfer files from one machine to another. The list of machines is loaded from a list defined in the XML resource registry file. User can select files from these machines. File transfer in GridPortlets is supported through GridFTP. File operations such as copying, moving, deleting, renaming and creating directories are also available.

4. GECEM portlets Portlets are a special type of servlet which are easily pluggable. They are implemented using the Portlet API provided by GridSphere. GECEM portlets provide functions to select data files and resources, search UDDI registries for grid services, and invoke grid services from remote machines for mesh generation and CEM simulation. According to the functional needs of the GECEM project, we have developed two main functional portlets: the Meshing Portlet and the Migrate Solver Portlet. We will describe these portlets in Section 4.3.

Here we first describe the components of a functional portlet.

4.1. Abstract Functional Portlet The design for a GECEM functional portlet has a number of components as described in Fig. 2. File Selection Portlet File Parameter Portlet

GecemService

Service Portlet

UDDI Portlet

Figure 2. GECEM Functional Portlet

File Selection Portlet During initialisation, the File Selection Portlet will load the list of machines specified in the Resource Browser Portlet. To run a scenario, the user first selects the machines from the list of machines loaded, then selects the necessary input files for the services. The hostname and the location of the selected file are appended together to form the URI of the file. A URI is used to identify the input and output files for a service, and the machines they reside on. It is used in GridFTP where the data files described by URIs are archived to the service provider described by a Uniform Resource Locator. The URI of the output file allows the output to be located and retrieved later. The file information is saved using the GECEM Service as described in Section 4.2.

Web services according to some user-specified criteria. The UDDI portlet is set by default to search the WeSC UDDI registry. The UDDI portlet returns the Grid Service Handles (GSHs) of the grid services located at the University of Wales, Swansea.

Service Portlet The Service Portlet allows a user to invoke the web services described in Section 5 for meshing and CEM simulation and to monitor and analyse the results of the execution. In the Service Portlet, the input file parameters are retrieved using the GecemService as described in Section 4.2. In addition to the file parameters, each service can have a number of parameters and the service portlet provides a button to invoke the service. Each service has a basic version and an advanced version for specifying the input parameters. In the basic version, the parameters are set by default and in the advanced version, the user can change the parameters. The portlets then commit the resources and the files selected to access the meshing service and the solver service.

4.2. GecemService To pass the selection of values from one portlet to another portlet, the GecemService provides a bean to store the values of the input files and the value of the GSH to be invoked for the service. Currently the GecemService stores the following values: • URI of Mesh input files • URI of Solver input files • GSH service URL

File Parameter Portlet 4.3. Instance of a Functional Portlet As soon as the user has selected the file from the File Selection Portlet, the URI of the selected file is displayed in the File Parameter Portlet under the corresponding heading so that the user can make sure that the correct files are selected.

There are two instances of the Functional Portlets developed for GECEM: the Meshing Portlet and the Migrate Solver Portlet, which are designed to invoke the Meshing grid service and the Migrate App grid service respectively.

UDDI Portlet

4.4. Meshing Portlet

The grid services used by GECEM are published to the UDDI registry located at the Welsh e-Science Centre (WeSC). The UDDI Portlet allows the user to search the UDDI registry for information on the location of the available mesher and solver services, thereby allowing them to be discovered dynamically. A user can publish services and query services through the UDDI registry, and select

To invoke the Meshing grid service, a user has to 1. select the input files, 2. search the UDDI registry for the service, 3. submit the service.

Figure 3. Meshing Portlet - Advanced Option Using the UDDI Portlet, the user searches the UDDI registry for the ”PPML” service. As a result, the GSH of the grid service for meshing is returned. Fig. 3 shows the advanced option of the service portlet. The parameters of the file and the GSH are passed to the Meshing Portlet. The user needs to input a number of mesh-related numerical parameters to generate a mesh file from the input files. After the mesh generation, the user can view the URI of the output of the generated mesh file which will be used as one of the input files for the Migrate Solver Portlet.

4.5. Migrate Solver Portlet The meshes generated by the Meshing Portlet will be used in the Migrate Solver Portlet. The Migrate Solver Portlet is similar to the Meshing Portlet. In the Migrate Solver Portlet, three input files are selected: the meshes generated from the Meshing Portlet, the boundary control file, and the control file. Using the UDDI Portlet, the user searches the UDDI registry for the “Migrate” service. As a result, the GSH of the grid service for migrating the solver is returned. The advanced option is shown in Fig. 4. Using the Migrate Solver Portlet, in addition to the input file parameters, other parameters including the destination host name, the migration host name, the local host name, and the file path of the executable need to be specified.

5. Grid-Enabled Applications Developing Grid services is an important aspect of the GECEM project. One motivation is to move legacy applications into the GECEM Grid architecture to achieve collaborative mesh generation and numerical simulation across a geographically dispersed Extended Enterprise. These

legacy applications not only typically represent large-scale investments that cannot be discarded, but also are highquality software. To migrate legacy applications to grid service technology, minimal modifications are required to these codes. The Java Native Interface is used to enable the integration of grid service code written in Java with legacy code written in other languages, and to allow Java code to operate with existing applications and libraries. Once the library and the wrapper codes have been created the native methods can be invoked from Java. We have successfully implemented many Grid services and have integrated them into the GECEM framework to solve complex engineering problems. For example, the Meshing Grid Service is a mesh generation service to mesh the flow domain. The CEM Grid service can perform a sophisticated simulation on an incident electromagnetic wave and a general scatterer. These services can be easily invoked remotely without legacy code migration. We also deploy a Migrate App Grid Service to migrate applications to specified resources. This service provides the functionality to securely and remotely execute applications on the various computing resources available in the Grid infrastructure so as to achieve maximum resource utilization.

5.1. Wrapping Strategy To adapt legacy codes to the Grid environment, a wrapping strategy is adopted to leverage investment made in previous application development, and to achieve better performance than would be achieved if the application were rewritten in a new language. We do not want to rewrite these legacy codes because they are not only functional, fast, and optimized, but are also often very complex, and make use of many other legacy code libraries. Such a wrapping strategy is useful when we make the legacy applications available as Web or Grid services. In the GECEM context, legacy applications were previously written in FORTRAN, C, and C++,

Figure 4. Migrate Solver Portlet - Advanced Option while Grid services often are implemented in Java. We create a wrapper that invokes the native implementation. Java Native Interface (JNI) is used to serve as glue between the Java side and native side of legacy applications. Through the JNI approach, we implement the Grid services in Java and still use highly optimized native code where necessary. The legacy implementations are modified only slightly, and compiled into a C wrapped dynamic link library, which the operating system loads and links into the Grid services processes that run the JVM. Details on the adaptation of applications to the Grid environment can be found in [13].

5.2. Implementation of Grid Services The Grid is an emerging infrastructure based on the exchange of information and the sharing of distributed resources by applications. The Open Grid Services Architecture (OGSA), which defines mechanisms for creating, managing, and exchanging information among entities called Grid services [16], has become widely used in Grid computing. When deploying a Grid service, Web Services Description Language (WSDL) [15] is used to describe the methods the Grid service provides. We use WSDL instead of a Java interface to define the service not only because WSDL is more expressive than interface definition languages, but also because WSDL allows reuse of designs in a language independent way.

6. Scenario To demonstrate the portlet service model used by GECEM, in this section we present a particular scenario.

6.1. Initial Setup Before using the portal, the user has to store their credential using the MyProxy server specified by the portal. 1. The user logs onto GridSphere using an account provided by the administrator. 2. The user selects the tab labelled ’Grid’ to select the GridPortlets application. 3. The user configures the GridPortlet to use the credential and supplies the MyProxy details to the credential retrieval portlet. 4. The user can use the File Browser Portlet to transfer files.

6.2. Using GECEM Portlets The user then selects the tab labelled ’GECEM’. The user should see there are two functionally designed portlets: one for meshing and one for solver migration. The user selects the tab for meshing.

1. The user first selects the File Selection Portlet to select the files. 2. After the files are selected, the user searches the UDDI registry for meshers. 3. The user then proceeds to the meshing service interface. The user could use the supplied default parameters to invoke the mesher grid service. The user needs to wait until the service has completed. The user next selects the tab for solver migration. 1. The user first selects the File Selection Portlet to select the generated meshes and other input files. 2. After the files are selected, the user searches the UDDI registry for solver migration services. 3. The user then proceeds to the solver migration service interface. The user can use the supplied default parameters to invoke the solver migration service.

6.3. Application of the GECEM Portal In this subsection, we present an application to demonstrate the use of the GECEM Portal to generate meshes and to migrate solver codes from University of Wales, Swansea to Cardiff University. In this application, we will use the following requirements at different locations. • A user is situated at BAE and has input files at BAE. • Both software for mesh generation and solver are located at Swansea. • In addition, two grid services are also located at Swansea: one for mesh generation and one for migration of solvers. • The solver needs to be migrated from Swansea to Cardiff for execution. • The user needs to view the result of the solver at BAE. The user at BAE would like to use their input files at BAE and have the results of the solver returned to BAE as well. To accommodate this, the user first logs on to the GECEM Portal, which can be accessed anywhere. The user selects the input files at BAE using the File Selection Portlet, searches the UDDI registry to get the GSH of the grid services for mesh generation, then invokes the grid services located at Swansea using the Meshing Portlet. After the meshes have been generated, the user selects the input files for solver migration using the File Selection Portlet, searches the UDDI registry to get the GSH of the grid services for solver migration and invokes the grid services for solver migration using the Migrate Solver Portlet.

To migrate the solver from Swansea to Cardiff, the following parameters are setup: • The migrating host is set to Swansea. • The destination host is set to Cardiff. • The local host is set to BAE. During the execution, the solver will be migrated from Swansea to Cardiff for execution. At the end of the execution, the user can view the results on BAE machines.

7. Related Work A grid-based problem solving environment is useful for collaborative simulation. As pointed out in the context of the Geodise toolkit [4], a problem solving environment to assist scientists doing computational electromagnetics has several advantages. Although both GECEM and the Geodise toolkit [4]provide similar functionality for mesh generation and code analysis, the Geodise toolkit has implemented this functionality through Matlab commands, rather than through some other user interface. In Geodise, meshing is performed through a mesh generation tool, while analysis is done through an analysis tool, rather than through grid services. The rationale of using a web portal as an interface is that the web has been an interface for many years. By using a web-based portal, a user can access the portal anywhere and can have an easy-to-use user interface to access these resources without the need to aware that the resources are distributed. A number of scientific portals have been developed using GridSphere as the portal container. For example, The Virtual Observatory Portal (VO-Portal) [2] and the P-GRADE Portal [9]. The VO-Portal provides an interface for job submission and job monitoring, so that scientists can execute an application through a web browser. However, the portal does not integrate any grid application services. Our approach is more customised to the user requirements of our industrial partner. However, it should be straightforward to migrate the same approach to other applications. The P-GRADE portal supports workflow and job migration. In addition, it provides a high-level graphical environment to generate PVM, MPI or GAT code according to the actual execution platform. It also supports interactive execution of parallel programs. It would be interesting to investigate if P-GRADE and GECEM can be integrated together. The GEMLCA project [3] addresses the issue of exposing legacy codes as Grid services, and provides a way of exposing and executing legacy applications through an OGSI

Grid Service. As pointed out in [11], a wrapping approach has the disadvantage of requiring access to source code and may require modification of the original legacy source code. In addition, the wrapping process is not entirely automatic, so considerable user effort may be required if the process needs to be applied to many legacy codes. In [10, 11], GEMLCA has taken a further step to create a general solution to deploy existing legacy code applications as Grid services without modifying the source code by creating a frontend Grid service layer. To access a legacy code program, the user executes the GEMLCA Grid service client that creates a legacy code instance with the help of the legacy code factory. The GEMLCA software has been integrated with a P-GRADE portal, which allows the user to construct and execute workflows from legacy codes deployed as OGSA Grid services.

[4]

[5]

[6] [7]

[8] [9]

8. Conclusions and Future Work

[10]

As computing platforms are becoming more intrinsically distributed, the need for Web-based portals that can hide the low-level details is increasing. The significance of this work is that the scientist can concentrate his effort on science without worrying about the technical aspects of remote access to distributed resources, such as using heterogeneous platforms for job submission, security management, and resource management. We have presented a grid-based problem solving environment for the GECEM Portal to support the migration of simulation codes across the Grid. Specifically, we have described the portlets approach to providing a better interface for scientists, and OGSA-compliant grid services for mesh generation and CEM solver migration. We have demonstrated through a scenario how these portlets and services are integrated to support collaborative simulation. We have used a UDDI registry to publish and discover the mesher and solver services. In future developments, we aim to support collaborative visualisation, exploration, and analysis of the CEM simulation results. We also plan to adapt our infrastructure to use the Web Services Resource Framework (WSRF) [6].

[11]

References [1] R. Allan, C. Awre, M. Baker, and A. Fish. Portals and portlets 2003. http://www.grids.ac.uk/Papers/ Portals/portals.pdf, Accessed April 2004. [2] B. Beeson, S. Melnikoff, S. Venugopal, and D. G. Barnes. A portal for grid-enabled physics. http://www. gridbus.org/reports/ePhysics.pdf. [3] T. Delaitre, A. Goyeneche, P. Kacsuk, T. Kiss, G. Z. Terstyanszky, and S. C. Winter. GEMLCA: Grid execution management for legacy code architecture design. In 30th

[12]

[13]

[14]

[15] [16]

[17]

[18]

EUROMICRO Conference, pages 477–483, Rennes, France, Aug. 2004. M. H. Eres, G. E. Pound, Z. Jiao, J. L. Wason, F. Xu, A. J. Keane, and S. J. Cox. Implementation and utilisation of a grid-enabled problem solving environment in matlab. Future Generation Computer Systems (In press), 2004. I. Foster, C. Kesselman, J. M. Nick, and S. Tuecke. The physiology of the grid: An open grid services architecture for distributed systems integration, June 2002. Globus. The WS-Resource Framework. http://www. globus.org/wsrf/, Jan. 2004. GridLab. Gridlab and application portlets design. http://www.gridlab.org/WorkPackages/ wp-4/Documents/GridLabPortlets.pdf. GridLab. The gridsphere portal. http://www. gridsphere.org/gridsphere/gridsphere. P. Kacsuk, G. Dozsa, R. Lovas, N. Podhorszki, Z. Balaton, and G. Gombas. P-GRADE: A Grid Programming Environment). Journal of Grid Computing, 1:171–197, 2003. P. Kacsuk, T. Kiss, A. Goyeneche, T. Delaitre, Z. Farkas, and T. Boczko. A high-level grid application environment to grid-enabled legacy code. ERCIM News, 59, Oct. 2004. P. Kacsuk, T. Kiss, A. Goyeneche, T. Delaitre, Z. Farkas, and T. Boczko. High-level grid application environment to use legacy codes as OGSA grid services. In Conf. Proc. of the 5 th IEEE/ACM International Workshop on Grid Computing, Pittsburgh, USA, November 8 2004. M. Lin and D. W. Walker. A portlet service model for GECEM. In S. J. Cox, editor, Proc. UK e-Science All Hands Meeting 2004, Aug. 2004. M. Lin, D. W. Walker, Y. Chen, and J. W. Jones. A web service architecture for GECEM. In S. J. Cox, editor, Proc. UK e-Science All Hands Meeting 2004, Aug. 2004. J. Novotny, M. Russel, and O. Wehrens. GridSphere: An advanced portal framework. In EUROMICRO 2004, Aug. 2004. B. Stearns. Web services description language (WSDL). http://www.w3.org/TR/wsdl, Mar. 2001. S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman, T. Maquire, T. Sandholm, D. Snelling, and P. Vanderbilt. OGSI final specification v1.0. http://www-unix.globus.org/ toolkit/draft-ggf-ogsi-gridservice-33_ 2003-06-27.pdf. D. W. Walker, J. P. Giddy, N. P. Weatherill, J. W. Jones, A. Gould, D. Rowse, and M. Turner. GECEM: Grid-Enabled Computational Electromagnetics. In Proc. UK e-Science All Hands Meeting 2003, pages 436–443, Sept. 2003. D. W. Walker, M. Li., O. F. Rana, M. S. Shields, and Y. Huang. The software architecture of a distributed problem-solving environment. Concurrency: Pract. Exp., 12(15):1455–1480, 2000.