2005 IEEE International Symposium on Cluster Computing and the Grid

A Dynamic Grid Services Deployment Mechanismfor On-Demand Resource Provisioning

Eun-Kyu Byunt Jae-Wan Jangt Wook Jungt Jin-Soo Kimt

Division ofComputer Science, Department ofEECS,Korea Advanced Institute ofScience and Technology (KAIST)

t{ekbyun, jwjang, wjung}(@camars.ka

Abstract

Recently Grid computing has started to leverage Webservices technology by proposing OGSI-standard. OGSIstandard defines the Grid service which presents unified in-terfaces to every participant of Grid. In current GlubusToolkit3(GT3),which is an implementation of OGSI, Gridservice factories should be deployed manually into re-sources to provide grid services. However, it is necessaryto dynamically allocate proper amount of resource, sincethe demandfor resource of service provider changes overtime.

In this paper, we propose a architecture to enable on-demand resource provisioning. We develop Universal Fac-tory Service (UFS) that provides a dynamic Grid servicedeployment mechanism and a resource broker called Doorservice. Through the experiments, we show that Grid ser-vices can adaptively exploit resources according to the re-quest rates.

1. Introduction

Grid computing [1] is a new approach to exploit dis-tributed, heterogeneous, and geographically scattered re-sources in order to solve complex problems in scientificand commercial areas. The ultimate goal ofGrid computingis to create virtual organizations (VOs) through secure, co-ordinated resource sharing among Grid participants and toprovide mechanisms for users to use Grid resources withoutknowing the detailed characteristics of them.

Recently Grid community has proposed OGSA (OpenGrid Service Architecture) [2], in which Grid resourcesare wrapped as Grid services with standard Web services[5] interfaces to provide unified access methods to users.Standard interfaces described in OGSA are based on OGSI

iJinsoo@cs.kaist.ac.kr

(Open Grid Service Infrastructure) [3]. OGSI providesmechanisms for 1) creating, naming, and discovering Gridservice instances, 2) managing Grid service lifetime, and3) subscribing and notifying specific service data. Hostingenvironment defined in OGSI and existing well-developedWeb services tools make the development of Grid serviceseasier than ever.

Globus Toolkit 3.0 (GT3) [4] is one of the referenceimplementations of OGSI specification. GT3 consists ofGT3 core and several packages including security, datamanagement, resource management, and information ser-vices. Using these packages, Grid service providers or userscan exploit Grid resources successfully, and Grid resourceproviders can supply their resources with uniform inter-faces. Service providers can release their services by de-ploying those on the Grid resources. Users of Grid then useremote Grid resources by using Grid service. In the currentimplementation of GT3, service factory of a service has tobe deployed in the resources in order to process service re-quests. However, the deployment of service factory requiresrestart of service container by resource administrator. Thismeans that other grid services executed on the resource haveto undergo unexpected interruption. That is to say, serviceproviders can not dynamically exploit Grid resources withcurrent GT3.

In this paper, we design and implement a dynamic Gridservice deployment mechanism named Universal FactoryService (UFS) and a resource broker named Door service.With these two service, we suggest a dynamic resource pro-visioning architecture for service providers. We evaluateUFS and Door service on a prototype Grid testbed. As a re-sult, we show that grid service can be deployed and provideswithout break of resource availability. We also show thatgrid service can exploit proper amount of Grid resourcesadaptively according to the request rates.

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

(a) Tradional Grid services arditecture

(b) Proposed Grid servics archibectre

Figure 1. A comparison of traditional and pro-posed Grid services architecture

2. Motivations

We assume that the following three entities are involvedin Grid computing.

* Service providers are who develop Grid services andwant to deploy the developed Grid services into re-sources.

* Resource providers are who provide resources such ascluster, desktop PCs, workstations, storages and so on.

* Service users are who want to use the services devel-oped by service providers.

Since various services have different characteristics,their resource demands vary dynamically. For example, aon-line shopping mall has a huge peak demand in Decem-ber where majority of its sales occurs. The service providerfor the shopping mall should be able to provide resourcesenough to handle such a peak demand. However, this willlead to significant squandering of resources during othernon-peak season. If the service provider can adjust theamount of resources according to the demand, he need nothold resources just to deal with peak periods.

Requirements for on-demand resource provisioning areas follows:

* Finding resources to meet service providers' demand.Many resource broker systems [6][7][8][9][10] canchoose resources which satisfy the demand of serviceproviders.

* Deploying services to the selected resources. In thecurrent GT3, resource providers have to deploy ser-vices by hand.

* Dispatching incoming requestsfrom service users. In-coming service requests need to be spread out on mul-tiple resources where the services are deployed al-ready.

* Removing the service when it is idlefor a long time. Ifthe service request rates decreases, deployed servicescan be removed in order to save disk space and to re-duce management costs.

GT3 requires that a certain service factory has to be de-ployed in the resources in order to serve service users. Forexample, as shown in 1(a), Service A is only be served onResource 1 and Service B is only served in Resource 2. Incurrent GT3, deploying any Grid services requires the mod-ification ofconfiguration files and restarting ofthe GT3 con-tainer itself. Thus, it is hard to use othe r free resources forthe overloaded services because manual arrangement is un-avoidable to deploy the service.

However, in our proposed architecture shown in Fig-ure l(b), UFS can deploy any kinds of Grid services with-out modifying the configuration manually and restarting theGT3 container. For example, although resource 2 does notcontain serviceX before, UFS in resource 2 can deploy ser-viceX without aforementioned tasks.

In addition, Door service in the proposed architecturedispatches incoming requests to the resources and deploysservices into new resources according to the deploying poli-cies. In the previous example, if Door service notices thatserviceX is too overloaded to be served only in the resource1, Door service deploys serviceX into resource 2 which isselected by deploying policies. Moreover, Door service canremove the idle service from unnecessary resources.

With the help ofUFS and Door service, service providerscan exploit on-demand resource provisioning for unex-pected service users' demand. The benefits of using UFSand Door service are summarized as follows:

* Little effort to deploy services for resource providers.Resource providers only need to deploy UFS as a Gridservice and service providers can deploy their serviceson-demand if they have appropriate access rights.

* Improved manageability. Management cost ofGrid re-sources is substantially high due to the huge scale of

864

Grid. Since UFS can deploy and remove Grid ser-vice dynamically, resource providers need not performthese tasks by hand.

* Implicit load balancing on multiple resources. Doorservice can adjust the amount of resources to guaran-tee a certain level of quality-of-service to service userswithout involvement of service providers. Thus, ser-vice providers can focus only on their services.

The remaining sections are organized as follows. Section3 overviews related work. In section 4 we describe the de-sign and implementation ofUFS and Door service. Section5 displays the evaluation results. We present conclusionsand future work in section 6.

3. Related work

Various dynamic service deployment mechanisms havebeen explored in the area of distributed systems.

Oceano [11] is a prototype system of a highly available,scalable, and manageable infrastructure for an e-businesscomputing utility. Oceano divides server farms into sev-eral separate domains, which are completely isolated eachother. Each domain provides a hosting environment for oneservice. When one of the hosted services is overloaded,Oceano increases the size of associated domain by deploy-ing the services to free resources dynamically. If anotherbusy service becomes idle, adversely, they decrease the sizeof that domain by removing the services dynamically. InOceano, preparing another hosting environment for over-loaded services takes relatively long time due to the restart-ing and the reconfiguration ofthe server in order to meet therequirements of the new services. Thus, adjusting the sizeof a service domain has to be made carefully.SODA [12] is another kind ofthe service platform which

supports dynamic service deployment. SODA introduceHUP (Hosting Utility Platform) which is similar to ourUFS. HUPs are installed in physical hosts and each hostruns one or more virtual service nodes. A service can beinstalled in one or more these virtual service nodes, whichare complete virtual machines on real hosts. With HUP,SODA can support mechanisms for adjusting the amount ofvirtual service nodes according to the service request rate.If the number of incoming service requests of a service in-creases, service providers ask SODA agent a new resource,and SODA agent and master allocate more resources to thatservice, if possible. However, since SODA is based on thevirtual machine to provide hosting environment for a ser-vice, the cost of changing the amount of resources is con-siderably high, and thus this decision has to be made cau-tiously like Oceano.

OGSI.NET [13] is an implementation of the OGSI spec-ification on Microsoft's .NET platform. It provides a con-

tainer framework on which OGSI-compliant Grid comput-ing is supported in the .NET/Windows world. In OGSI.NETarchitecture, dispatcher is similar to our Door service,which routes incoming requests to pertinent Grid ServiceWrapper (GSW). While dispatcher in OGSI.NET is a lo-cal agent routing the incoming service requests to one ofGSWs, Door service is a global agent to link incoming ser-vice requests to resources. One of other components, meta-factory in OGSI.NET, is comparable to our UFS. Meta-factory allows service providers to deploy Grid services intothe GSW without restarting or reconfiguring OGSI.NETcontainer. However, service codes deployable into GSWare called assembly, which is a different type of the serviceimplementation from GT3.

The GridWeaver project [ 17] presents an autonomous re-source configuration framework for clusters by combiningLCFG [19] and SmartFrog [20]. Since these technology aredesigned for cluster scales, GridWeaver need to be modifiedto deal with huge resource pools like Grid.

Distributed Ant(DistAnt) [18] provides a mechanism fordeploying user's application on remote resource. DistAntadopts similar deployment mechanism used in UFS. How-ever, DistAnt only focuses on deploying and instantiatingcustom applications, and does not consider the resourceprovisioning for Grid-service provider.

Our work primarily differs from previous researches inthat we focus on on-demand resource provisioning with thedynamic Grid service deployment mechanism for OGSI-compliant Grid services.

4. Design and implementation of UFS andDoor service

4.1. Architecture for on-demand resource provi-sioning

Figure 2 shows the overall architecture of UFS and Doorservice with relevant entities such as service users, serviceproviders, and resource providers. Since this architecturefollows the standard OGSI specification, in order to use aparticular service, service users must interact with a serviceinstance created by Grid service factory ofthat service. Therole of each service is as follows:

* Actual service. Actual service is a Grid service writtenin Java that service providers want to provide to serviceusers. Actual service can be deployed to any resourcesin which UFS is deployed.

* Universal Factory Service (UFS). UFS is deployed inevery resource. UFS allows service providers to de-ploy their Grid services dynamically and to create in-stances of that Grid service.

865

Service users

I*4 \4 reqtsu; :SA^vg^ f) S:^ * query

/f6ploy F0$0

IResource.-dResourceResource, providers _

UFS Grid serviceups ~~~~~~containercreateUFSlnstance(

UFS instance UFS instance

Factory of service A Factory of service B

m31iccreateServkceL( cateServke(

IK.tal osEvif A

IA

Figure 3. Internal architecture of UFSFigure 2. The relationship among ser-vice providers, service users and resourceproviders

* Resource Selection Service (RSS). RSS is a kind of In-dex service which monitors and serves the informationof Grid resources. Based on this information, Doorservice obtains the list of proper resources which sat-isfies the condition for executing actual service.

* Door service. Door service relays service requests toproper resources in which actual service is deployed.Door service also deploys the actual service to the re-source with the help ofRSS and UFS in order to adjustthe amount of resources occupied by the service.

Service users should know the address ofGSH(Grid Ser-vice Handle) of the service factory in order to create anduse the service instances. In our on-demand resource pro-visioning architecture, the location of the resources wherethe Grid service is deployed is dynamically changed. Thus,some mechanism to connect the service user to the re-sources is necessary. Door service takes a part ofthis mech-anism in our architecture.

Note that service providers should have their own Doorservices to provide their Grid services to service users.We implemented a general Door service so that serviceproviders can use that after simple configuration. Serviceusers then can use the Grid service simply by contacting itsown Door service.

Next two subsections explain UFS and Door service indetail. At the end of this section, we show an example sce-nario how a Grid service is called by a service user.

4.2. Universal Factory Service (UFS)

Figure 3 depicts how UFS creates service instances. UFSis a persistent Grid service which is permanently accessibleas long as the GT3 container is alive. If Door service asksUFS to deploy a new Grid service, UFS creates an UFSinstance, which is an empty service at that time. UFS in-stances can work as a service factory ofany Grid service af-ter Door service transfers service code and configures nec-essary parameters. Since Grid services are implemented asJava classes, no complicated installation procedures are re-quired. Java classes are transferred over http protocol andstored in preassigned local storage. Then just after link-ing the location of that Java classes to the UFS instance,service users can create service instances using createSer-viceO method of the UFS instance in the same way theyaccess common Grid service factory.

Since UFS instances support the notification of its re-source status, Door service subscribes that resource status.Currently, a UFS instance notifies Door Service ofthe CPUload average and the number of active service instances.A UFS instance can be terminated by the destroyO

method. The destroyO method deletes the service code anddestroys the UFS instance as other Grid service instancesare destroyed.

4.3. Door service

Door service provides service users with the same inter-face as common Grid service factory does. Service userscan get GSH of a service instance from Door service viacreateServiceO method. To handle the request from serviceusers, Door service asks the proper resource to create a ser-vice instance. Door service can deploy the actual serviceinto new resources using UFS, if necessary.

The service providers need to specify the policies includ-ing where new service instance should be crested, when the

866

Service users

617Door service ><

L Deplyed 31resource tableb

(a)

Resource- provider

UFS instanceV (Factory of

service A)

4Instance ofservice A

Resource

(b)

Figure 4. Service request flows

service should be deployed into a new resource, and whenthe resource should be released. In the current version ofDoor service, service providers can determine the policy ac-

cording to the CPU load average and the number of activeinstances in the resource. Door service maintains a list ofGSHs ofUFS instances where the actual service is deployedand the status of the resources. The status of resource is up-dated by notification from UFS instances.

Since UFS instances are not persistent Grid services, dy-namically deployed services are no more available if GT3container is restarted or failed. Nonetheless, since Door ser-

vice always monitors the status of resource, Door servicecan detect the resource failure and allocate new resource ifthe number of remaining resources are insufficient to dealwith next requests.Now we show the example scenario of using Door ser-

vice and UFS. Assume that s service user want to invokea Grid service A. Figure 4(a) depicts the operation flowswhen Door service does not need to deploy the service tonew resource. In this case, the following steps are required:

1) A service user asks Door service to create an instanceof the service A.

2) Door service selects a resource from the resource poolwhere the service A is already deployed.

3) Door service sends a request to the UFS instance oftheselected resource to create an instance of service A.

4),5) The UFS instance creates a new instance ofthe serviceA and retums its GSH to Door service.

6) Door service retums that GSH to the service user.

7) The service user contacts the instance of the service Ausing the returned GSH.

Figure 4(b) displays the request flow when Door serviceneeds to deploy service A into a new resource. In this case,the following steps should be done between step 2) and 3)of Figure 4(a):

1) Door service gets the list of available resources for theservice A from RSS.

2) Door service asks UFS to create a UFS instance.

3),4) UFS creates an UFS instance which is an empty fac-tory and returns GSH of the created UFS instance.

5) Door service transfers the service code of the serviceA and configures the UFS instance. Then the UFS in-stance is ready to act as a factory of the service A.

5. Evalution

5.1. Experimental setup

For the experiments, we use eight two-way SMP nodeswith Intel Pentium Xeon 2.8 GHz and 1GB memory, andfour two-way SMP nodes with Intel Pentium III 850MHzand 1.5GB memory. They are connected by 10OMbps Eth-ernet. Globus toolkit version 3.2.1 is installed in every node.Door service and RSS are deployed on a Xeon node, whileanother Xeon node is dedicated to periodical generation ofservice requests. The remaining ten nodes are used as re-sources ofthe resource provider and UFS is installed in eachresource.We convert three real applications, Raja[14], JIU[15],

and Jspeex[1 6], into Grid services. During the experiments,we have varied the rate of service requests to these services.

5.2. Overhead of using Door service

While UFS and Door service provide a convenient wayto use resources for service providers, service users mayexperience an additional delay compared to the case theyuse the resource directly, since every request should passthrough Door service. This delay can be longer when Doorservice has to deploy the service to a new resource. Inour experiments, deploying a service of 4.5Mbytes codethrough UFS takes 3.98 seconds on average. Notice thattransferring the service code over the network consumes97% out of 3.98 seconds. Since service deployment doesnot happen frequently, the delay due to the presence ofDoorservice is not critical.

867

Table 1. The elapsed time for getting a service instance from a resource

Without stub code loadingDirect to factory via Door servicer 98.47 ms l 108.79 ms

We measured the average round trip time of createSer-viceO method of Door service. Service users ask Door ser-vice to create an instance of Raja Grid service. The result ispresented in Table 1. When service users request the Gridservice for the first time, service users may wait additionaltime to get results since they have to load stub codes. Thisoverhead does not appear once stub codes are loaded.

In Table 1, the time without stub code loading shows thedelayed time due to Door service. The service users waitabout 10 more milliseconds to get results when they requestthrough Door service than when they directly request to fac-tory. This is ignorable compared to the whole executiontime of the service.

When we measure the round trip time with stub codeloading, via Door service takes smaller time than Direct tofactory. This is caused by the difference in stub code sizebetween two approaches. In the current GT3, service usershave to load several classes to access common Grid servicefactory, while service users should load only Door servicerelated classes in order to access Door service.

53. Behavior of UFS and Door service with singleGrid service

In order to show our framework provides resources dy-namically when the number of requests from service userschanges, we vary the arrival rate ofrequests and observe thenumber of servicing nodes. Service users periodically makea request to run'Raja Grid service which takes a few tens ofseconds.We vary the arrival rate of requests of service users by

0.1 req/s every ten minutes. First, we increase the arrivalrate from 0.1 req/s to 1.0 req/s and, after that, decrease from1.0 req/s to 0.1 req/s. We repeat this experiment for twodifferent policies of deploying/scheduling. The first policyis that Door service does not allow the number of activeinstances of every deployed resource to exceed the numberof processors of the node. On the other hand, in the secondpolicy, Door service does not allow the CPU load average ofevery deployed resource to exceed the number ofprocessorsofthe node. In both case, Door service releases the resourcewhen it has no active instance.

Figure 5 presents the number of servicing nodes alongwith request failure rates. The results of the first policy isdenoted as instances, and that of the second policy as loa-

With stub code loadingDirect to factory via Door service

3482.65 ms l 2573.05 ms

D

E9

10

9

8

7 D

6 °c'S u

4 w

2

1

0ol .1, .11 .1 11,111I.1_ ! Ini -! X1 rl oq o~ Cb Q@ ml " tC a 0 a a a a a a _0 0 0 a a 0 0 6 6 6

request amval rate (reags)

Failure rate (Instances) Failure rate (Loadavg). # servicing nodes (Instances) _ # servicing nodes (Laadavg)

Figure 5. Changes on the number of servicingnodes and request failure rates when servicerequests vary

davg. Figure 5 shows that Door service utilizes resourcesproportional to the arrival rates. Services are completelyprovided to service user until there is no more resource.When the arrival rate is more than 0.8 req/s, some requestsare not served because all resources are busy and the policydoes not allow to create a new service instance on existingresources.

The result obviously exhibits that loadavg occupiesslightly more resources with higher failure rate than in-stances. This is caused by the freshness of informationDoor service uses. While the number of active instances isreported to Door service whenever changed, the CPU loadaverage is reported in every 10 seconds. Besides, the CPUload average denotes the average running processes duringlast one minute. Therefore, once Door service perceives theresource is busy, Door service may not use that resourceeven though the resource is available.

5.4. Behavior ofUFS and Door service with severalGrid services

We perform another experiment to show the behavior ofUFS and Door service when several services co-exist on theresources. We deployed three Door services of Raja, JIU,

868

z

Table 2. The amount of the service requestsnormalized to the phase I

I I Phase I

Raja 1.0 _JIU 1.0Jspeex 1.0 _

Figure 6. The dynamic change in the numberof servicing nodes for three different Grid ser-vices

and Jspeex Grid service. Similar to the former experiments,service users periodically make service requests.We divide the whole experiment time into four phases.

Each phase lasts for 20 minutes. In the first phase, ser-vice users make total 400 requests for Raja, 600 requestsfor JIU, and 800 requests for Jspeex. We change the ar-

rival rate ofrequests whenever the phase is changed. Table2 shows the relative arrival rates of each phase normalizedto those of phase 1. In this experiment, each service adoptsthe instances policy. Figure 6 shows the number of servic-ing nodes during the experiments. As expected, each ser-

vice occupies only the amount of resources that is requiredto handle the incoming requests.We also show that on-demand resource provisioning can

more efficiently utilize the limited amount of resourcesthan the case where services are statically partitioned to re-sources. For the static deployment system, we deploy Rajainto four nodes, JIU into three nodes, and Jspeex into threenodes prior to starting the experiment. As shown in figure7, the failure rate of the static deployment system is higherthan that of the dynamic deployment system. Dynamic de-ployment system can exploit any resources, whereas staticdeployment system use only the fixed number ofresources.

Figure 7. Failure rates experienced by serviceusers

6. Conclusions and future work

In this paper, we identify the requirements for the on-

demand resource provisioning for Grid services. Sincefunctionalities of the current GT3 are insufficient to sup-port dynamic Grid service deployment which is essential tosupport on-demand resource provisioning, we design andimplement UFS which is an OGSI-compliant Grid service.Once UFS is deployed into the resources, service providerscan deploy any kinds of Grid services without modifyingany configuration or restarting the GT3 container. We alsodesign and implement a simple resource broker called Doorservice. Door service works as a front end of a certain ser-vice and dispatches incoming requests ofthat service to theresources in which actual services are already deployed.

Through the various experiments, we show that ourdynamic deployment mechanism works correctly. Whenthe request rate of a service increases, we can observe thatthe corresponding service occupies more resources. On theother hand, when the request rate of a service decreases, thecorresponding service releases its resources and the amountofoccupying resources shrinks. We also show that dynamicdeployment can use resource more efficiently compared tostatic partitioning.

Service providers may apply several policies for deploy-ing and dispatching to Door service in order to preserve thereasonable performance of their services. These policiesshould be determined considering the performance charac-teristics of a service, the capability of a resource, and theQoS expectation of service provider. The current versionof Door service only allows service provider to limit thenumber of concurrent instances according to the numberof processors. However, since the characteristics of manyGrid services vary, our next version of Door service willsupport additional mechanisms for service providers to de-

869

Phase 22.00.50.5

Phase 3_1.0

_ 1.57

Phase 40.01.51.5

ee2!

LI

e

12ue4

scribe more detailed policies.If too many users want to use the same service, Door

service may be the performance bottleneck. Since Door ser-vice is quite lightweight as shown in section 5.2, the scala-bility of the service container dominates the throughput ofDoor service. Our Door service runs on GT3 container. Un-fortunately, GT3 container can not handle more than 20 ser-vices at the same time and we find that it shows the limitedthroughput even for very light Grid service. Therefore, it isnecessary to make GT3 container more scalable. We alsoplan to construct a hierarchy of Door services to enhancethe scalability ofDoor service.

References

[1] I. Foster, C. Kesselman, and S. Tuecke, "The Anatomyofthe Grid: Enabling Scalable Virtual Organizations,"International Joumal of Supercomputer Applications,2001.

[2] I. Foster, C. Kesselman, J. Nick, and S. Tuecke, "ThePhysiology of the Grid: An Open Grid Services Ar-chitecture for Distributed Systems Integration" OpenGrid Service Infrastructure WG, Global Grid Forum,2002.

[3] S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Gra-ham, C. Kesselman, T. Maguire, T. Sandholm, P.Vanderbilt, and D. Snelling, "Open Grid Services In-frastructure (OGSI) Version 1.0," Global Grid ForumDraft Recommendation, 6/27/2003.

[4] The Globus Alliance, http://www.globus.org/.

[5] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N Mukhi,and S. Weerawarana, "Unraveling the Web ServicesWeb: An Introduction to SOAP, WSDL, and UDDI,"IEEE Internet Computing, 2002.

[6] C. Liu, L. Yang, I. Foster, and D. Angulo, "Designand Evaluation ofa Resource Selection Framework forGrid Applications," Proceedings of the IEEE Interna-tional Symposium on High-Performance DistributedComputing, 2002.

[7] W. Lee, S. McGough, S. Newhouse, and J. Dar-lington, "Load-balancing EU-DataGrid Resource Bro-kers," UK e-Science All Hands Meeting, 2003.

[8] D. Thain, T. Tannenbaum, and M. Livny, "Condor andthe Grid," Grid Computing: Making The Global In-frastructure a Reality, John Wiley, 2003.

Proceedings of the IEEE International Conference onHigh Performance Computing and Grid in Asia PacificRegion, 2000.

[10] Y.-S. Kim, J.-L. Yu, J.-G. Hahm, J.-S. Kim, and J.-W. Lee, "Design and Implementation of an OGSI-Compliant Grid Broker Service," Proceedings of theIEEE International Symposium on Cluster Computingand the Grid, 2004.

[11] K. Appleby, S. Fakhouri, L. Fong, G. Goldszmidt,M. Kalantar, S. Krishnakumar, D. P. Pazel, J. Persh-ing, and B. Rochwerger, "Oceano-SLA Based Man-agement of a Computing Utility," Proceedings ofthe IFIP/IEEE International Symposium on IntegratedNetwork Management, 2001.

[12] X. Jiang, D. Xu, "SODA: a Service-On-DemandArchitecture for Application Service Hosting Util-ity Platforms," Proceedings of the IEEE InternationalSymposium on High Performance Distributed Com-puting, 2003.

[13] G. Wasson, N. Beekwilder, M. Morgan, and M.Humphrey, "OGSI.NET: OGSI-compliance on the.NET Framework,' Proceedings of the IEEE Interna-tional Symposium on Cluster Computing and the Grid,2004.

[14] The Raja Project, http://raja.sourceforge.net/.

[15] JIU - The Java Imaging Utilities - An image process-ing library, http://jiu.sourceforge.net/.

[16] JSpeex - Java Implementationhttp://jspeex.sourceforge.net/.

of Speex,

[17] GridWeaver Project, http://www.gridweaver.org/.

[18] W. Goscinski and D. Abramson, "Distributed Ant:A System to Support Application Deployment in theGrid," IEEE/ACM International Workshop on GridComputing, 2004.

[19] P. Anderson and A. Scobie, "LCFG - the Next Gena-ration," UKUWG Winter Conference, 2002.

[20] P. Goldsack, "Smartfrog: Configuration, ig-nition and management of distributed appli-cation," Technical report, HP Resource Labs.http://www-uk.hpl.hp.com/smargfrog/.

[9] R. Buyya, D. Abramson, and J. Giddy, "Nimrod/G:An Architecture for a Resource Management andScheduling System in a Global Computational Grid,"

870