Generic Access to Web and Grid-basedSymbolic Computing Services:

the SymGrid-Services FrameworkAlexandru Carstea, Marc Frıncu, Georgiana Macariu, Dana Petcu

Institute e-Austria Timisoara, RomaniaEmail:{science,dana}@ieat.ro

and Kevin HammondSchool of Computer Science

University of St. Andrews, ScotlandEmail:kh@cs.st-and.ac.uk

Abstract— Modern Grid and Web technologies providestraightforward access to applications and services running onremote resources. The user (which may be a software developeror even an application) should be able to discover such aservice and dynamically load an interface to interact with it.While some software systems support either fully or partiallyautomatic creation of client software to access Web services, fewersupport Grid services in the same way. This paper introducesa new system that automatically generates client software toallow access to both Grid and Web services. Although designedas a stand-alone tool for accessing any Web or Grid service,we demonstrate its usefulness in the context of the SymGridframework for Grid-based symbolic computations.

I. INTRODUCTION

Grid and Web services are generally designed not to interactwith humans, but rather with software components, namelyservice clients and other Grid or Web services. Each timea service is created, corresponding client software must beproduced. It is, however, impractical to produce a specialisedclient for each instance of a remote Grid or Web service.Rather, having discovered a service, the user should be ableto dynamically load an interface that allows interaction withthat service.

Although several recent tools are able to encapsulate andexecute complex applications as Grid services, few alsoprovide a way for an application developer to generate anapplication specific interface that can be provided to the enduser. One obvious solution is to exploit the fact that everyWeb service and all recent Grid services are described by aWSDL document [19] that provides an abstract description ofthe service interface (or port type).

A wide range of parameters must be considered whengenerating Web service clients automatically. These includethe port that the service will be wired to, the number andnames of the methods, the service address, or the way thatthe service descriptor is obtained. Several tools provide partialimplementations of Web service generators. For example,Eclipse [11] can generate a Java Bean proxy from a WSDLdocument, but only for Web services deployed on WebSphereservers. A .NET tool, Webservice Studio [18], can be usedto invoke Web service methods interactively. This tool ismeant for Web service implementers to test their serviceswithout having to write the client code or to access other

Web services whose WSDL endpoint is known: it fetchesthe WSDL, generates a proxy from the WSDL and displaysthe list of methods available. The user can then choose anymethod and provide the required input parameters. A specificencoded request can be sent to the server and the response isparsed to display the return value. Unfortunately, WebserviceStudio does not work well with complicated methods. SystinetDeveloper for Eclipse [17] also supports client generation, theentry point being the WSDL document describing the Webservice and automatically generates Java client code that callsthe Web service; the developer must create the real methodcalls on the prepared interfaces in the client code. Othersolutions to generate the Java classes needed to invoke a Webservice programmatically are Novell exteNd Workbench, JAX-RPC Stylus Studio, etc.

Other solutions have been prototyped by various researchprojects. For instance, the ASSIST [1] framework aids theapplication developer by providing them with a proxy librarywhose entries are the stub methods for the remote Webservice. These are generated from the service’s WSDL file.The programmer must instantiate the stubs with the codeneeded to invoke the service’s methods, and place calls tothe stub methods within the code provided by the frameworkmodules. A different approach is taken by Xydra-OntoBrew[4]. This provides on-the-fly WSDL to Web-form generationfor simple services and portlet clients: the Xydra servlet takesWSDL as input, generates an XHTML form that allows theuser to provide an input message, gathers the submitted inputvalues and converts name-value pairs into an XML messagethat is sent to the Web service. Finally, it displays any resultmessages. While Xydra is a sophisticated response to the clientcode creation problem, simpler solutions are needed especiallywhen workflow execution of combined services is desired.

Although Grid services have different goals from pure webservices (sharing computing power and resources such as diskstorage databases and software applications, rather than shar-ing information), a Grid service is basically a Web service witha few extensions: statefulness, service instantiation, namedservice instances, two-level naming scheme, a base set ofservice capabilities, and lifetime management [9]. It followsthat Web services tools must be extended if they are also tobe used for Grid services,

The first Grid service standard to appear, OGSI, was notfully compliant with the SOAP standard. Lessons learnedfrom this were applied to create the WSRF standard [20].Working with WSRF allows Grid services and Web servicesto be treated uniformly. Remote operations can be invoked bysupplying the location of the server, the name of the operationand the list of parameters to be passed.

Application experts are often unwilling to deal with thelow-level code development that is mandated by approachessuch as those described above, but require straightforwardways to access remote services from within domain-specificapplications or environments. The classical solution is to pro-vide application-specific libraries that allow access to specificservices. However, if the underlying Web or Grid technologieschange in any significant way, then all of these library routinesmust be rewritten. A more flexible solution is to build a singlegeneric package to access Web and Grid services and to thenprovide simple application-specific adapters to this package.This is the approach that we are taking in the SymGridsystem, a new standard platform for Grid-based symboliccomputations (see Section II).

As noted above, some tools already exist that will au-tomatically generate Web services clients. However, thesetools do not include Grid service capabilities, and, as faras we are aware, there is no previous automatic generatorthat supports WSRF-compliant services. In this paper, wedescribe a generator that treats both Grid services and Webservices in a uniform manner. By using this tool, ComputerAlgebra Systems (CAS) can access external Grid and Webservices via an external component: CAGS (the ComputerAlgebra to Grid Services component), which interfaces theCAS to the Grid. CAGS supports URL-based access usingboth http and https transport protocols. It also supports theSSL security certificates management required by the GlobusToolkit GSI [8].

The remainder of this paper is structured as follows. Sec-tion II briefly describes our objectives in constructing theSymGrid system; Sections III and IV describe the design andimplementation of the generic CAGS tool; Sections V and VIdescribe examples. Finally, Section VII concludes.

II. SYMGRID AIMS AND OBJECTIVES

Symbolic computation software systems are vital tools inseveral areas of modern academic and commercial research.The aim of the EU Framework VI SCIEnce project (Sym-bolic Computation Infrastructure in Europe, http://www.symbolic-computations.org) is to improve integra-tion between CAS developers and application experts. Theproject includes developers from four major CASs: GAP,Maple, MuPAD and Kant; plus application experts organisedthrough the international Research Institute for SymbolicComputation, RISC-LINZ. Its main objectives are to:

1) develop versions of the CASs that can inter-communicate via a common standard Web servicesinterface, based on domain-specific results produced by

the OpenMath [14] and MONET [12] projects as wellas generic standards such as WSRF;

2) develop common standards/middleware to allow the pro-duction of Grid-enabled symbolic computation systems;

3) promote and ensure uptake of recent developments inprogramming languages, including automatic memorymanagement, into symbolic computation systems.

Since our research is primarily concerned with parallel andGrid computations, we are mainly concerned with achievingthe second objective: that of providing Grid-enabled symboliccomputations using a novel framework, SymGrid. Our goalsin developing this framework are to:

1) produce a portable framework that will both allow sym-bolic computations to access Grid services, and allowsymbolic components to be exploited as part of largerGrid service applications on a computational Grid;

2) develop resource brokers that will support the irregularworkload and computation structures that are frequentlyfound in symbolic computations; and

3) implement a series of applications that will demonstratethe capabilities and limitations of Grid computing forsymbolic computations.

These objectives cannot be achieved without introducing newhigher-level middleware systems than are currently available.By providing a new domain-specific framework for symbolicGrid computations we aim to supply a sophisticated interac-tive computational steering interface integrating seamlesslyinto the interactive front-ends provided by each CAS, andproviding simple, transparent and high-level access to Gridservices. By defining common data and task interfaces, we willallow complex computations to be constructed by orchestratingheterogeneous distributed components into a single symbolicapplication. By providing generic interfaces where possible,we also anticipate that it will in fact, in time, be possible toexploit our framework for other application domains.

In this paper, we focus on the Grid service provision require-ment, that is on the component we term SymGrid-Services.The complementary component that allows symbolic computa-tions to be executed as high-performance parallel computationson a computational Grid is described elsewhere [2]. Whilethere are several parallel computer algebra systems suitable foreither shared-memory or distributed memory parallel systems,work on Grid-based symbolic systems is still nascent. A re-view of current Grid-based systems for symbolic computationcan be found in [15]. None of these systems conforms to allthree of our basic requirements, however, which are to:

(a) deploy symbolic Grid services;(b) access available Grid services from within the sym-

bolic computing system; and(c) couple different Grid symbolic services into a coher-

ent whole.In addition to dealing with these key issues, a number

of major new obstacles remain to be overcome if effectivesymbolic Grid applications are to be developed. Amongstthe most important requirements are mechanisms for adapting

Fig. 1. CAGS structure

to dynamic changes in either computations or systems. Thisis especially important for symbolic computations, whichmay be highly irregular in terms of data structures andgeneral computational demands, and which therefore presentan interesting challenge to current and projected technologiesfor computational Grids in terms of their requirements forautonomic control. The intention of SymGrid is to go beyondcurrent systems by developing a generic framework supportingheterogeneous Grid components derived from a critical set ofcomplementary symbolic computing systems, by incorporatingnew and vital tools such as dynamic resource brokers andschedulers that can work both at a task and system level, andby creating a number of large new demonstrator applications.

III. THE CAGS ARCHITECTURE

CAGS allows Computer Algebra Systems to leverage the com-puting capabilities offered by external Grid or Web services.A CAS user must be able to i) discover services; ii) connectto remote services; iii) call remote operations; and iv) run jobsand transfer files in a seamless fashion. In order to meet theserequirements we have created a component that provides thisfunctionality to the CAS. The component interface consistsof three Java classes: SGServices; SGProxyCert; andSGUtils.

1) SGServices: this provides three kinds of operations –retrieval of the list of services registered to a certain UDDIregistry or Globus container; retrieval of signatures for theexposed operations of a service; and calling remote operations.The corresponding methods are (Figure 1):

getGridServiceListreturns the list of services deployed inthe specified Globus container. The list ofservices is obtained by querying the GlobusContainerRegistryService using XPathqueries [21];

getWebServiceListreturns the list of services registered to a UDDIregistry;

getOperationsListreturns the list of operations exposed by a Grid/Webservice;

isGridServiceindicates whether a service is a WS-Resource (usu-ally for Grid services);

getWSResourceEPRused to call a factory service and to retrieve the EPRof the newly created WS-Resource (usually for Gridservices); and

callOperationcalls an operation exposed by a service.

2) SGProxyCert: this handles issues arising from the needto support ’single sign-on’ for users of the Grid and delegationof credentials: namely the creation and destruction of proxycertificates. The class can also be used to retrieve informationabout the owner of a X509 certificate and about the lifetimeof a proxy certificate. Since a user may have more than oneX509 certificate, but with only one being used at a certainmoment, when creating a proxy certificate, the location of the

certificate is automatically stored in a session file. When aproxy certificate is needed, this default certificate is loadedand used. The SGProxyCert class provides the followingmethods:createProxyFile

creates a new proxy – the location of the proxycan either be supplied by the user or automaticallygenerated;

proxyDestroyused to destroy an existing proxy;

getCertInforeturns information about the owner of the certificate;and

isProxyValidindicates whether the proxy is valid.

3) SGUtils: this provides additional functionality for ex-plicit file transfer, file deletion and remote job exection. TheSGUtils class provides the following methods:copyFile

copies files using the Globus Toolkit RFT service;deleteFile

deletes files using the RFT service;runJob

allows Globus jobs to be submitted in a synchronousmanner;

submitJoboffers the possibility to allows Globus jobs to besubmitted in an asynchronous manner and returns aunique identifier for further reference;

getJobStatuschecks the status of an asynchronous job;

getJobFilesenables the user to retrieve the files resulted byexecuting the job.

A. RunManager

To access the functionality provided by these three classesit is necessary to create new class instances. Generally,however, CASs do not offer such functionality by defaultand we therefore run the supplied Java classes in a childprocess created by the CAS and which communicateswith the CAS uses standard input/output streams to passparameter and return values (Figure 2). The processis invoked by a script that executes the commandjava RunManager arg0 arg1 arg2 ... argN,where arg0 represents the Java class to load, arg1 is thename of the method to invoke, and remaining arguments arepassed to the method. RunManager is a completely genericcommand that exploits Java reflection capabilities to allowthe execution of any class.

IV. THE CAGS IMPLEMENTATION

A. WSRF Specifications and Implementation

A Grid service is a Web service that conforms to a setof conventions (interfaces and behaviors) that permits the

Fig. 2. Interactions between CAS and CAGS

creation of stateful Web services [20]. Statefulness is achievedby separating the service from the state information andby providing mechanisms to identify and manage this stateinformation. A stateful WS-Resource is uniquely identifiedby an Endpoint Reference (EPR). The WSRF standard forGrid services includes specifications for: WS-Resource,WS-ResourceProperties, WS-ResourceLifetime,WS-ServiceGroup, and WS-BaseFaults. Related stan-dards include WS-Addressing and WS-Notification.The de-facto standard middleware for creating computationalgrids that implementing these specifications is Globus Toolkit4 [8]. Using an EPR is more complex than simply using thelist of methods exposed by a registered service, and a specialmethod was therefore included in CAGS to deal with this case.The service that is pointed to by its URL is not the serviceitself, but a registered factory that generates a service instancefor the particular service requestor.

B. Tools and Libraries

Globus-based Grid services are currently developed using oneof three WSRF implementations: Java WS Core, C WS Core orthe Python WS Core. The most comprehensive implementationis the Java WS Core component, which uses Java 1.5. Amongstother features, it implements a set of predefined port typesthat simplify access to and manipulation of WS-Resources.Since Globus Toolkit 4 exposes any builtin capability as a Gridservice, the Globus container also exposes by default severalservices used to support resource management, file transferand job submit and control. These services are grouped asdata management services, information services, and execu-tion management services. From these existing services, theCAGS tool uses the Reliable File Transfer (RFT) servicefor data management and transfer, DefaultIndexServiceand ContainerRegistryService to obtain the list ofservices deployed in a virtual organization, and WS-GRAM torun jobs. We have therefore used the Java 1.5 SDK as thebasis the CAGS implementation, extending the Apache Axisimplementation of the standard SOAP protocol that is used bythe Globus Toolkit to also provide https support. We usethe UDDI4J package to query UDDI-compliant Web servicesregistries.

On the client side, before generating the service client, thestubs and Java Beans that are needed by the call mut firstbe generated. CAGS uses the Apache Axis subcomponents

offered by the WSDL2Java tool to achieve this. Since thesetools were originally intended only to be used in conjunctionwith the http protocol, we have needed to extend them toalso cover the https protocol.

C. Security Considerations

Grid environments allow remote execution of operations thatcould potentially expose security holes, through access tofile systems, access to licensed software tools etc. Sensitiveinformation must be protected and the Grid environment mustprevent unauthorized access. The Globus Toolkit GSI offersthe required security features: secure communication; singlesign-on; delegation of credentials; and the ability to managesecurity issues in a decentralized manner. GSI exploits X509security certificates to provide these security. These basecertificates allow the user to generate a proxy certificate witha limited lifetime. This ensures a good level of security atreasonable effort. The CAGS tool permits access to bothsecure and non-secure services. In particular SymGrid pro-vides secure access based on Grid certificates to commercialmathematical software and also provides public access to opensource mathematical software.

D. Service Discovery Issues

The main purpose of CAGS is to permit remote Grid/Webservices calls. If a Web service is intended to be public, theWeb service can be advertised by registering the service toa public UDDI registry. Such a registry is designed to beinterrogated using SOAP requests and provides access to WSDLdocuments describing the Web services that are registered init. Obtaining a list of the Grid services deployed in a containeris similar to normal Web service discovery.

The list of available Grid/Web services provides little or noinformation about the suitability of those services to the user’sneeds. Research into how best to discover the most appropriateservice is currently being undertaken by the GENSS project[6]. CAGS therefore currently provides only a simple selectionmechanism that involves matching against the service name.

E. The FlattenXML format

Both Grid and Web services allow operations to be exposedthat accept complex user-defined types in either input parame-ters or return values, where the type is described using an XSDdefinition. To obtain an in-memory representation, the type canbe mapped to a Java Bean, which can in turn be generated bythe Apache Axis WSDL2Java tool. The challenge in CAGSis in representing such types so that they can be easily used inthe CAS. Since the CASs and the Java environment commu-nicate using a string-based representation; it is not possibleto share in-memory objects. The flattenXML format thatwe propose here is one solution to this problem. Rather thanproviding a full definition of flatttenML, we give a simpleillustrative example here. For a complex type represented bythe hierarchy:<person>

<name><firstname>

John</firstname><lastname>

Smith</lastname>

</name><age>

23</age>

</person>

the corresponding flattenXML string is:

"person:name:first name:string:John;person:name:lastname:string:Smith;person:age:int:23;"

where the path separator and parameter separator used here,for simplicity, are ”:” and ”;”, but would normally be lesscommonly used separators such as ”#” and ”###”.

Since SymGrid services will communicate using the Open-Math format (an extension of XML), all SymGrid methodswill receive an OpenMath object as their input and should re-turn an OpenMath object. Such objects will be communicatedbetween the CAS and CAGS using flattenXML.

F. Calling Operations

In order to call an operation, the user must supply the serviceproviding the operation, the name of the operation, and thelist of required parameters. CAGS first uses the informationsupplied in the WSDL file that describes the operation togenerate the corresponding Java Beans and communicationstubs. It then dynamically generates a new client that willinvoke the required operation. In order to provide the servicestubs, CAGS uses a helper tool that has been implemented aspart of the GSBT project [10].

One special category of services is the standard set providedby the Globus Toolkit. The RFT service and WS-GRAM-relatedservices are treated specially since it is possible to create staticclients for these services and require a valid proxy certificateto be supplied.

V. USAGE SCENARIOS

A. Typical scenarios

The primary functionality of CAGS lies in obtaining a listof Grid/Web services registered at a certain URL; obtainingthe signatures of those operations that are exposed by a certainGrid/Web service; calling an operation and retrieving the resultof an operation call. Secondary functionality includes filetransfer and job submission, and managing utilities for proxycertificates.

A typical scenario begins with the discovery of a serviceby consulting a service registry URL (either a UDDI registryor a Globus Container):

start scenario(registry_URL)if (is_Web_service_registry(registry_URL))service_list:= get_Web_service_list(registry_URL,

toMatch,options)elseservice_list:= get_Grid_service_list(

registry_URL,toMatch)endif

service:= select_service(service_list)operation_list:= get_operation_list(service,toMatch)operation:=select_operation(operation_list)[create_proxy_certificate();]result:= call_operation(service,operation,

parameters)end scenario

Here, Registry URL parameter is a valid URL of a UDDIregistry or a Globus container. The toMatch parameter is aselection string that must be a substring of the service name inthe get Web service list/get Grid service listcombined with a substring of the operation name inthe get operation list. The selection functionsselect service/select operation are user-defined functions that can be used to select the desiredservice/operation.

Note that this scenario assumes that the user only knowsthe registry URL. If the user already knows, for instance,the service URL and the signature of the operation, then theunnecessary steps can be omitted.

B. Accessing CAGS from the GAP System

One of the initial SymGrid targets is the GAP [5] com-putational algebra system. We have therefore constructed alibrary of GAP functions that allows a GAP user to access theCAGS functionality without needing to know the details ofthe implementation. There is one function in the GAP libraryfor each method in the CAGS interface. The general patternused to wrap the CAGS functionality is:directoryName := DirectoryCurrent();fileName:=Filename(directoryName,"script.sh");ListMethods := function(arg2...argN)local j_main, response;j_main := InputOutputLocalProcess(

DirectoryCurrent(), fileName, []);#send handler method: class, method, no. of#arguments, args (one per line), end signalWriteLine(j_main, "java_class_to_call");WriteLine(j_main, "method_name");WriteLine(j_main, "nr_of_parameters");WriteLine(j_main, arg2);...WriteLine(j_main, argN);WriteLine(j_main, "quit");#retrieve response from the processrepeatresponse := ReadLine(j_main);if (response <> fail) Print(response); fi;

until (response = fail);end;

Since Java cannot be invoked directly from a GAP program,the solution is to instead invoke a shell script that startsa Java program using the InputOutputLocalProcessGAP function. In the above example we pass the neededparameters to the script.sh script. The j main variableis the handle to the running process. It can be used as anargument to the WriteLine function to pass the arguments.

VI. EXAMPLES

In this section, we show how CAGS can be used directly byexploiting the RunManager utility program. Three categories

of services have been used for our initial tests:1) general Web services such as those deployed at http:

//uddi.sap.com/uddi/api/inquiry;2) domain-specific symblic Web services such as those

provided by MONET [13] and GENSS [7];3) simple test Grid services, that we have deployed on

a single cluster. These symbolic computation serviceswrap publicly available CASs: CoCoA, Fermat, GAP,Kant, Macaulay, MuPAD, PARI, Singular and Yacas.The test services are deployed in a Globus container athttp://194.102.62.44:8082 (this is due to bereplaced with an official SymGrid address in Summer2007).

A. Listing Services

A UDDI Registry can be interrogated to obtain the list ofservices registered to that registry. For example, the command:

java science.run.RunManagerscience.clients.wrappers.SGServicesgetWebServiceList"http://uddi.sap.com/uddi/api/inquiry""A" "caseSensitiveMatch "

produces the result:

http://192.168.6.98/HelloWorld/Service1.asmxhttp://www50.brinkster.com/vbfacileinpt/np.asmxhttp://www.webservicex.com/AustralianPostCode.asmx...

This is a list of Web service URLs representing all servicesin the UDDI registry whose names include the substring A.

B. Listing Operation Signatures

Once the address of a service is known, CAGS can supplythe signatures of the operations exposed by the service. Basedon the list of the methods exposed, the user can then discoverall details that are needed to call a remote operation. In thecase of the Fermat service that is deployed on the SymGridtestbed, as the result of the command:

java science.run.RunManagerscience.clients.wrappers.SGServicesgetOperationsList"http://194.102.62.44:8082/wsrf/services/science/FermatService" ""

the following list of operations can be obtained:

string Bin (string)string Prime (string)string Rand (string)string Sigma (string)string Prod (string)string Modulus ( string)...

Note that since SymGrid services take and return OpenMathobjects, the arguments and results to each operation are stringsrather than the integers that might be expected.

C. Calling an Operation

Remote operation invocation is one of the main reasons forusing CAGS. To call the FermatService operation that

calculates the greatest common divisor of 96 and 80, we mightuse the following call:java science.run.RunManagerscience.clients.wrappers.SGServicescallOperationhttp://194.102.62.44:8082/wsrf/services/science/FermatServiceGCD "96,80"

obtaining as result the string string:16. Note that the finalversion of FermatService (to be produced by September2007) will accept only two OpenMath objects instead of thetwo integer values currently allowed by this service.

D. Creating a Proxy

The creation of a proxy certificate assuming that the useralready has a X509 certificate can be done with the command:java science.run.RunManager

science.clients.wrappers.SGProxyCertcreateProxyFile/tmp/testproxy1 "" "" "PASSWORD"

This returns the local location of the newly created proxycertificate, here /tmp/testproxy1.

E. Running a Job

Standard Globus services offer, amongst other things, theability to run a Globus job on a remote machine. To achievethis, the user must supply the shell command or the programto run, the number of times the job must be run, the parametersand the names of the result files. Empty result files resultin default locations being used. The result of the commandindicates whether the job was successful on not. For example,to run a job that lists the contents of a directory we can issuethe commandjava -DGLOBUS_LOCATION=$GLOBUS_LOCATIONscience.run.RunManagerscience.clients.wrappers.SGUtilsrunJob"/bin/ls" "1" "-l::/tmp" "" "" ""

A successful invocation will result in the return value 1, withresults stored in a new file created in the /tmp directory.

F. The GAP Interface to CAGS

To show how GAP can use CAGS to interact with externalservices, we have built an example in which GAP calls anexternal service. The external service is a YACAS instance,that easily interacts with OpenMath objects. The first step inthe example is to list all the services from a Globus containerthat can be matched using the string ”YACAS”. From the listof services that are obtained, we choose the wrapping service,and ask for the list of operations supported by that servicethat relate to OpenMath (OM). The final step of the examplelaunches a call from GAP to the service. The result of the callis displayed by GAP on the console:gap> SG_CreateProxy("path_proxy", "", "", "pswd");gap> gridServList := SG_GridServiceList(

"http://194.102.62.44:8082/wsrf/services/","YACAS");

http://194.102.62.44:8082/wsrf/services/science/

YACASServicegap> operationList := SG_OperationList(

gridServiceList[1], "OM");string YACAS_OMDef (string)string YACAS_OMForm (string)string YACAS_OMRead (string)

gap> SG_CallOperation(gridServiceList[1],operationList[2], "25");

string:<OMOBJ> <OMI>25</OMI> </OMOBJ>

G. Web Portal Example

To demonstrate that CAGS can be integrated into a varietyof applications, we have created a Web portal, using Javaservlets deployed into a Tomcat Apache server. The generalstructure of servlet applications imposed some minor changesregarding the location of the libraries used by CAGS, butwas otherwise straightforward, and allows the full CAGSfunctionality to be accessed from HTML forms. Users areable to login into the system, query for a Web/Grid servicelist, call a remote Grid/Web service operation, or launch aGlobus job. If an anonymous connection is made to the portal,a Web user is restricted to non-secure Grid services. Loggingto the portal causes a proxy certificate to be created that canbe used when invoking secure services. Figure 3 gives somescreenshots showing how the portal can be used. The portal isavailable for test purposes at http://194.102.62.36:8080/portal.

VII. CONCLUSIONS AND FUTURE DEVELOPMENTS

In this paper, we have introduced a generic tool, CAGS, thathas been constructed to allow easy access to WSRF-basedWeb and Grid services from within symbolic computations.While this is only a small component of the planned SymGridmiddleware, it represents an important first step. We will nowtest its utility as part of the SymGrid design by trying alarger number of existing mathematical services, using a largerprivate test Grid that is being constructed to link Romania,Germany and Scotland, and also by testing special servicesthat are requiring high-performance computing.

In the next few months, we will construct a new componentto allow deployment of Web and Grid-based symbolic com-puting services. This new component must be also genericto easily expose new services. Initially this component will beused for the deployment of basic SymGrid services, wrappinginstances of the GAP, MuPAD, Kant and Maple kernels intoGrid services.

Another issue that we will address in the coming monthswill be service composition. Currently, only a few workflowtools such as GridNexus [3] can be used in conjunction withthe CAGS since it is necessary to generate the service stubswe require.

Finally we review some of the novel elements of the systemthat is described in this paper: a solution to uniform accessof Web and Grid services; application to a new domain thatwill strongly benefit from Web and Grid service integration;a generic scenario for interacting with Web and Grid servicesfrom within symbolic computing systems; and finally the

Fig. 3. Examples of using the Web portal: top, a Web service, middle a Gridservice wrapping YACAS [22], bottom client call simulation and the result

construction of a publicly available test environment that linksseveral symbolic computing facilities into a single Web portal.

ACKNOWLEDGMENTS

This research is partially supported by European Union Frame-work 6 grant RII3-CT-2005-026133 SCIEnce: Symbolic Com-puting Infrastructure in Europe, and by a one-year SOEDsupport fellowship from the Royal Society of Edinburgh.

REFERENCES

[1] M. Aldinucci, M. Danelutto, A. Paternesi, R. Ravazzolo and M. Van-neschi, “Building Interoperable Grid-aware ASSIST Applications viaWeb-Services, Proc. PARCO 2005: Parallel Computing, 2005, availableat http://compass2.di.unipi.it/TR/Files/TR-05-24.pdf.gz.

[2] A. Al Zain, K. Hammond, P.W. Trinder, S.A. Linton, H.-W. Loidland M. Costanti, “SymGrid-Par: Designing a Framework for ExecutingComputational Algebra Systems on Computational Grids, Submitted tothe International Workshjop on Practical Aspects of High-level ParallelProgramming (PAPP 2007), Beijing, China, 2007.

[3] J. Brown, C. Ferner, T. Hudson, A. Stapleton, R. Vetter, T. Carland,A. Martin, J. Martin, A. Rawls, W. Shipman and M. Wood, “GridNexus:A Grid Services Scientific Workflow System, International Journal ofComputer Information Science (IJCIS) 6, No 2, June 2005, pp. 72–82.

[4] D. Gannon, J. Alameda, O. Chipara, M. Christie, V. Dukle, L. Fang,M. Farrellee, G. Kandaswamy, D. Kodeboyina, S. Krishnan, C. Moad,M. Pierce, B. Plale, A. Rossi, Y. Simmhan, A. Sarangi, A. Slominski,S. Shirasuna and T. Thomas, “Building Grid Portal Applications froma Web Service Component Architecture, Procs. of the IEEE Publica-tion 93, Issue 3, 2005, pp. 551– 563.

[5] GAP, http://www-gap.mcs.st-and.ac.uk/.[6] GENSS, http://genss.cs.bath.ac.uk/.[7] GENSS test service, http://agentcities.cs.bath.ac.uk:

8080/genss_axis/services/GENSSWS?wsdl[8] Globus Toolkit, http://www.globus.org/toolkit/.[9] A. Grimshaw, Grid Services extend Web services, SOAWebServices Jour-

nal 506, Jul. 24, 2003, http://webservices.sys-con.com/read/39829.htm.

[10] GSBT, http://gsbt.sourceforge.net/.[11] IBM Eclipse, Generating a Java Client Proxy and a Sample

Application from a WSDL Document using the Axis run-timeEnvironment, http://help.eclipse.org/help31/index.jsp?topic=org.eclipse.jst.ws.axis.ui.doc.user/tasks/tsampappa.html

[12] MONET, http://monet.nag.co.uk.[13] MONET Maple service, http://ptibonum.scl.csd.uwo.ca:

16661/MonetServiceClient/[14] OpenMath, http://www.openmath.org/.[15] D. Petcu, D. Tepeneu, M. Paprzycki and T. Ida, “Symbolic Computations

on Grids, In Engineering the Grid: status and perspective, eds. B. diMartino, J. Dongarra, A. Hoisie, L. Yang, and H. Zima, AmericanScientific Publishers, 2006, pp. 91-107

[16] D. Petcu, “Distributed Symbolic Computations, Invited talk, Procs. ofISPDC 2007, to appear.

[17] Systinet Developer for Eclipse, http://www.systinet.com/doc/sd-60/dg.ws.clients.creation.html

[18] WebServiceStudio 2.0, http://www.gotdotnet.com/team/tools/web_svc/default.aspx

[19] WSDL, http://www.w3.org/TR/wsdl.[20] WSRF, http://www.globus.org/wsrf/.[21] XPath, http://www.w3.org/TR/xpath.[22] YACAS, http://yacas.sourceforge.net/.