Designing Grid-based Problem Solving Environments and Portals Gregor von Laszewski, Ian Foster, Jarek Gawor, Peter Lane, Nell Rehn, Mike Russell Argonne National Laboratory, 9700 South Cass Avenue, Argonne, IL 60439, U.S.A. [email protected]Abstract Building Problem Solving environments in the emerging national-scale Computational Grid infrastructure is a chal- lenging task. Accessing advanced Grid services, such as authentication, remote access to computers, resource man- agement, and directory services, is usually not a simple matter for problem solving environment developers. The Commodity Grid project is working to overcome this dif- ficulty by creating what we call Commodity Grid Toolkits (CoG Kits) that define mappings and interfaces between the Grid and particular commodity frameworks familiar to problem solving environment developers. In this paper, we explain why CoG Kits are important for problem solving en- vironment developers, describe the design and implementa- tion of a Java CoG Kit, and use examples to illustrate how CoG Kits can enable new approaches to application devel- opment based on the integrated use of commodity and Grid technologies. 1. Introduction The development of next-generation problem solving environments (PSEs)[12] is influenced by rapid advances in the world of commodity computing and the emerging national-scale Computational Grid. The explosive growth of the Internet and of distributed computing in general has led to significant technology improvements in sev- eral domains that are important for the development of PSEs accessing large-scale computational resources. In the world of commodity computing, a broad spectrum of dis- tributed computing technologies (Web protocols, Java, JINI, CORBA, DCOM, etc.) has emerged, with revolutionary ef- fects on how we access and process information. Simulta- neously, the high-performance computing community has taken big steps toward the creation of so-called Grids, ad- vanced infrastructures designed to enable the coordinated use of distributed high-end resources for scientific problem solving. These two worlds of what we will call “commodity” and “Grid” computing have evolved in parallel, with different goals leading to different emphases and technology solu- tions. For example, commodity technologies tend to focus on issues of scalability, component composition, and desk- top presentation, while Grid developers emphasize end-to- end performance, advanced network services, and support for unique resources such as supercomputers. The results of this parallel evolution are multiple technology sets with some overlaps, much complementarity, and some obvious gaps. In this context, we have established the Commodity Grid (CoG) project, with the twin goals of (a) enabling devel- opers of PSEs to exploit commodity technologies wherever possible and (b) exporting Grid technologies to commodity computing for easy integration in PSEs. A first activity being undertaken within the CoG project is the design and development of a set of Commodity Grid Toolkits (CoG Kits), that define and implement a set of gen- eral components that map Grid functionality into a com- modity environment/framework. Hence, we can imagine a Web/CGI CoG Kit, a Java CoG Kit, a CORBA CoG Kit, a DCOM CoG Kit, and so on. In each case, the bene- fit of the CoG Kit is that it enables application developers to exploit advanced Grid services (resource management, security, resource discovery) while developing higher-level components in terms of the familiar and powerful applica- tion development frameworks provided by commodity tech- nologies. In each case, we also face the challenge of devel- oping appropriate interfaces between Grid and commodity concepts and technologies—and, if similar Grid and com- modity services are provided, reconciling competing ap- proaches. As part of these activities, we have successfully devel- oped a Java-based Commodity Grid Toolkit (Java CoG Kit) that defines and implements a set of general components mapping Grid functionality into the Java framework. The Java CoG Kit is of particular interest for PSE developers because it allows them to implement preinstalled heavy- weight applications to be started on user-accessible com- 1
Building ProblemSolvingenvironmentsin theemergingnational-scaleComputationalGrid infrastructure is a chal-lenging task. AccessingadvancedGrid services,such asauthentication,remoteaccessto computers, resourceman-agement,and directory services,is usually not a simplematter for problemsolving environmentdevelopers. TheCommodityGrid project is working to overcomethis dif-ficulty by creatingwhat we call CommodityGrid Toolkits(CoG Kits) that definemappingsand interfacesbetweentheGrid andparticular commodityframeworksfamiliar toproblemsolvingenvironmentdevelopers. In this paper, weexplainwhyCoGKits areimportantfor problemsolvingen-vironmentdevelopers,describethedesignandimplementa-tion of a JavaCoGKit, anduseexamplesto illustratehowCoGKits canenablenew approachesto applicationdevel-opmentbasedon theintegrateduseof commodityandGridtechnologies.
1. Intr oduction
The developmentof next-generationproblem solvingenvironments(PSEs)[12] is influencedby rapid advancesin the world of commoditycomputingand the emergingnational-scaleComputationalGrid. The explosive growthof the Internet and of distributed computing in generalhas led to significant technology improvementsin sev-eral domainsthat are important for the developmentofPSEsaccessinglarge-scalecomputationalresources.In theworld of commoditycomputing,a broadspectrumof dis-tributedcomputingtechnologies(Webprotocols,Java,JINI,CORBA, DCOM, etc.)hasemerged,with revolutionaryef-fectson how we accessandprocessinformation. Simulta-neously, the high-performancecomputingcommunityhastaken big stepstoward the creationof so-calledGrids, ad-vancedinfrastructuresdesignedto enablethe coordinateduseof distributedhigh-endresourcesfor scientificproblemsolving.
Thesetwo worldsof whatwewill call “commodity” and“Grid” computinghave evolved in parallel,with differentgoals leadingto different emphasesand technologysolu-tions. For example,commoditytechnologiestendto focuson issuesof scalability, componentcomposition,anddesk-top presentation,while Grid developersemphasizeend-to-endperformance,advancednetwork services,andsupportfor uniqueresourcessuchassupercomputers.The resultsof this parallelevolution aremultiple technologysetswithsomeoverlaps,muchcomplementarity, andsomeobviousgaps.
In thiscontext, wehaveestablishedtheCommodityGrid(CoG) project, with the twin goalsof (a) enablingdevel-opersof PSEsto exploit commoditytechnologieswhereverpossibleand(b) exportingGrid technologiesto commoditycomputingfor easyintegrationin PSEs.
A first activity beingundertakenwithin theCoGprojectis thedesignanddevelopmentof a setof CommodityGridToolkits(CoGKits), thatdefineandimplementasetof gen-eral componentsthat map Grid functionality into a com-modity environment/framework. Hence,we canimagineaWeb/CGI CoG Kit, a Java CoG Kit, a CORBA CoG Kit,a DCOM CoG Kit, and so on. In eachcase,the bene-fit of the CoG Kit is that it enablesapplicationdevelopersto exploit advancedGrid services(resourcemanagement,security, resourcediscovery)while developinghigher-levelcomponentsin termsof the familiar andpowerful applica-tion developmentframeworksprovidedby commoditytech-nologies.In eachcase,we alsofacethechallengeof devel-opingappropriateinterfacesbetweenGrid andcommodityconceptsandtechnologies—and,if similar Grid andcom-modity servicesare provided, reconciling competingap-proaches.
As part of theseactivities, we have successfullydevel-opedaJava-basedCommodityGrid Toolkit (JavaCoGKit)that definesand implementsa set of generalcomponentsmappingGrid functionality into the Java framework. TheJava CoG Kit is of particularinterestfor PSEdevelopersbecauseit allows them to implementpreinstalledheavy-weight applicationsto be startedon user-accessiblecom-
The primary goal of our researchis not to build a PSEthat will solve a specificproblemfor a particularapplica-tion area. Instead,our focus is on developinga softwareinfrastructureto make it easierto build and deploy pow-erful PSEs. We have basedour developmentof the JavaCoGkit onourexperienceswith applicationusersin variousproblemdomains.Thus,we areconfidentthatthetoolkit isgeneralenoughto beusefulfor a largenumberof PSEde-velopers.
While wehaveintroducedin [17] thegeneralconceptsoftheJavaCoGKit, wewill illustratein thispaperits practicalusein the developmentof problemsolving environments.Additionally, we introduceherenew componentsandmoresophisticatedsecurityconceptsthatareof particularinterestto developersof chemistryproblem-solvingenvironments.
2. Portals to Problem SolvingEnvir onments
For readersto understandthe scopeof this work, weexplain the termsproblemsolvingenvironmentandportal,sincemultiple definitionsareusedfor bothtermsin thelit-erature.
2.1. ProblemSolving Envir onment
Our understandingof a PSEfollows approximatelythedefinitiongivenin [7]: “A problemsolvingenvironmentisa computationalsystemthat providesa completeandcon-venientsetof high level tools for solvingproblemsfrom aspecificdomain.ThePSEallows usersto defineandmod-ify problems,choosesolutionstrategies, interactwith andmanageappropriatehardware and software resources,vi-sualizeandanalyzeresults,andrecordandcoordinateex-tendedproblemsolving tasks. A usercommunicateswitha PSEin the languageof the problem,not in the languageof aparticularoperatingsystem,programminglanguage,ornetwork protocol.”
For ourresearchfocusweassumethattheproblemsmustaccessremoteresources,potentially in a securefashion,andmayrequirea largeamountof computeand/ordatare-sources.The processof solving the problemis steeredbythescientist,andits progressmaybemonitoredthroughIn-ternetbrowsersor special-purposeapplication-monitoringprograms.
2.2. Requirementsfor PSEPortals
We identifieda list of characteristicsthat influencedourPSEtoolkit design[1]:
Problem-oriented. ThePSEshouldallow specialiststoconcentrateon their discipline,without having to become
Integrated. Many problemsand their solution strate-giesareextremelyheterogeneous:in models,codes,appli-cations,andmachines.A PSEmustbedesignedto managethis heterogeneityin an integratedway, so that the userispresentedwith a predictableandconsistentPSE.
Collaborati ve. Most scienceandengineeringprojectsare performedin collaborative modewith physically dis-tributed participants. A PSE must include the ability tofoster collaborative solution strategies. We assumethat ageneral-purposevideo conferencingtool can be providedwith commonoff-the-shelftoolsdevelopedby commercialcompanies.Nevertheless,it may be necessaryto developspecial-purposecollaborativetoolsthatarenot providedbythird parties.
Distrib uted. Besidestheneedto supportdistributedcol-laborationbetweenscientists,many problemswehavebeendealingwith (suchasGrandChallenges)canbesolvedonlywhile accessinglarge distributed resources(suchas stor-ageandcomputeresources)in conjunctionwith eachother.A PSEmustbe able to accessthesedistributed resourcesseamlesslyandin collaboration.
Persistent. Sincedevelopinga solution for a problemmayrequiresignificanttime,it is desirableto provideaper-sistentenvironmentthatallowstheresearcherto resumethesolutionprocessat a later time at a potentiallydifferentlo-cation. Thus, it is necessaryto be able to checkpointnotonly thestateof thecalculationbut alsothestateof thePSEuserinterface.Thepersistenceof a PSEcouldbeenhancedwith preferencesthat are eithersetby the useror are de-tectedautomaticallyby the PSE.Suchfunctionality couldbe achievedwith the integrationof what is calledan elec-tronicnotebook.
Open,flexible, adaptive. Problemstrategiesrequirebe-ing ableto integratenovel ideas.A sophisticatedPSEbuild-ing tool must be able to tailor or add new functionalitywithin its existentbase.
A “Web portal” is commonlydefinedasan entry pointor startingsite for theWorld Wide Web,combininga mix-tureof contentandservicesthatattemptsto provide a per-sonalized"homebase"for it’s audience.Featuresincludecustomizablestartpagesto guideuserseasily throughtheservicesprovidedby the portal. Suchservicesincludefil-terablee-mail, chat rooms and messageboards,person-
Problem Solving Environment Portal
Clients
Servers
XUL,XML
XML,HTTP,SOAP,(Globus)
Supercomputer WorkstationCluster
StorageServers
Figure 1. A computing por tal interfacesclients with Grid resour ces suc h as stor -age servers, super computer s, and worksta-tion cluster s.
In this spirit, we suggestthata convenientway of inter-facingwith aPSEis to designportalsfor ascientificdomainor a particularproblemstrategy. Besidesproviding collab-orative, interactive, and informationservices,suchportalsincludealsoservicesthatareuniquefor thedomainbut aretypically not providedby consumer-orientedportals.Theseservicesinclude interfacesbetweenusersof the PSEwiththe help of clients rangingfrom graphicsworkstationstopalmpilots to theresourcesavailableaspartof thecompu-tationalGrid (Figure1). Naturally, not all capabilitiesof aportalmaybeexposedby lesscapableaccessdevicessuchaspalmpilots. Nevertheless,theability to sendamessagetoa beeper, palmpilot, or cell phoneaddssignificantvaluetothePSEfunctionalityby notifying theuserof theexistenceof a collaborative sessionor the completionof a problemsolution. Hence,theability to accessa portalwith various(evenlesscapable)devicesis anintegralpartof ourdesign.
2.4. Usersand UsageModesof PSEPortals
Portaldevelopmentfor PSEsfirst requiresdeterminingwhich customergroupwill beusingthe portal. We distin-guishthreetargetgroups:
1. Novicescienceor problemsolvingenvironmentusers,that is, casualor novice usersusing readily availablesolutionsto problems. The problemstrategy is non-transparentto noviceusers.
2. Expertscienceor problemsolvingenvironmentusers,that is, usersin the domain for which the portal is
developed. Such usersare able to extend the por-tal while providing solutionstrategiesasusedby thenoviceusersor themselves.
In addition, we distinguishbetweeninteractive and batchmodein which jobs aresubmittedfrom the problemsolv-ing environmentto the backendsystemsby the users.Wehave to be able to supportthe useof computeresourcesthroughfine-grainedparallelprograms,typically providedthroughMPI message-passingparallelprograms,or coarse-grainparallelprogramsthroughjob dependenciesbetweenjobs submittedto the batchprocessingsystemsor a forkjobmanager. Thetoolkit we describein this papersupportstheseusagemodes.
3. Ar chitecture
Becauseof thediversifieduseof aPSEportal,thearchi-tectureof suchanenvironmentmustbeflexible. Thus,it isnot feasibleto developapointsolutionfor asingleproblem.Neededinsteadis a portal toolkit that includesa setof ser-vicesexposedvia APIs thatcanbeusedto assembleapointsolutionfor aproblem.Figure2 andTable1 outlinethevar-ious groupsof servicesthat we initially focuson andthatmustbeintegratedinto aportaltoolkit. Eachportalcompo-nentmayhaveseveralsubcomponentsthatsupportthetasksperformedaspartof thecomputingportalfor problemsolv-ing environments.The componentsin bold text of Figure2 aredevelopedaspartof theCoGKit. Othercomponentsareprovidedeitherby commoditysoftwareor theapplica-tion programmers.The flexible designmakes it possibleto integratenew componentsinto theframework or replaceexistingmodules.
3.1. Grid CoreServices
The scientific problem-solving infrastructure of thetwenty-firstcenturywill supportthecoordinateduseof nu-merousdistributed heterogeneouscomponents,includingadvancednetworks,computers,storagedevices,displayde-vices,andscientific instruments.The term “The Grid” isoften usedto refer to this emerging infrastructure[5][6].NASA’s InformationPower Grid andtheNCSA Alliance’sNational TechnologyGrid are two contemporaryprojectsprototypingGrid systems;both build on a rangeof tech-nologies,includingmany providedby theGlobusprojectinwhich we areinvolved. In designingPSEportals,we makeextensive useof thesetechnologies,including Globus ser-vices,suchas
PortalDisplay Components
ScienceComponents
CollaborationComponents
Compute ResourceComponents
DesignComponents
AdministrationComponents
MonitoringComponents
PSE/Computing
Portal
p-flow
p-installer
p-monitor
p-debug
p-brokerp-trader
c-ticker
a-snb
c-video
p-renderer
SecurityComponents
p-crypt
c-bean c-jsp
p-authenticate
Figure 2. A computing por tal is built withthe help of a variety of por tal componentsranging from specializ ed application- spe-cific por tal components to components forusing distrib uted compute resour ces or otherGrid infrastructure .
� an authenticationand authorization service (GSI),which providesmechanismsfor establishing,identify-ing, andcreatingdelegatablecredentials;and
� a uniform job submissionserviceacrossdistributedschedulingsystems(GRAM).
TheseGrid servicesareoften termed“middleware”: theytypically involve a distributedstateandcan be viewed asa naturalevolution of the servicesprovidedby today’s In-ternet. They build the basisfor developing a Grid-basedproblemsolving environmentbecausemany of the portalcomponentsusetheir services.
3.2. Job Submissionand Execution
Oneof the main servicesa PSEportal mustprovide isto job submissionto remoteresources.This mustbe donein seamlessfashionfrom thedesktopwith a singlesign-onauthentication.Computersmustbelocatedandthecompu-tationmustbestartedontheselectedsystems.It is essentialto monitor theprogressof thejob executionandobtaintheresultsof thecalculationthrough,for example,outputfilesthatmaybemanipulatedlocally ontheclientside(thecom-puterfrom which thejob wasinitiated).Weareableto sup-port suchuniform job submissionwhile using the Globusmetacomputingtoolkit to accessGrid resourcessecurely.
Authentication Thefirst stepof the job submissionis toauthenticatewith the system. Authenticationis the pro-cessto verify the identity of an entity. Although the cryp-tographic algorithms that form the basis of most secu-rity systems–suchaspublickey cryptography–arerelativelysimple, it is a challengingtask to usethesealgorithmstomeetdiversesecuritygoalsin complex, dynamicproblemsolving environments,with potentially large anddynamicsetsof usersandresourcesandfluid relationshipsbetweenusersandresources.Authenticationsolutionsfor problemsolvingenvironmentsin a ComputationalGridsmustsolvetwo problemsnotcommonlyaddressedby standardauthen-ticationtechnologies.
Thefirst problemis supportfor localheterogeneity. Theresourcesavailable in the Grid are operatedby a diverserangeof entities, eachdefining a different administrativedomain.
The secondproblem support for N-way security con-texts. In traditional client-server applications,authentica-tion involves just a single client and a single server. Incontrast,a Grid-basedPSEmay requireand dynamically
maintainedresources.Thus, it mustbe possibleto estab-lish a securityrelationshipbetweenany two processesinthecomputationusedto solve theproblemevenif they arein differentadministrative domains. To simplify our taskweusetheGrid securityinfrastructure(GSI) thatdealswiththe authentication. GSI policy allows a userto authenti-catejust onceper computation,at which time a credentialis generatedthat allows processescreatedon behalfof theuserto acquireresources,andsono,withoutadditionaluserintervention. Local heterogeneityis handledby mappinga user’s Grid identity into local useridentitiesat eachre-source.In summary, theGSIsecuritymodelprovidesPSEsthe following advantages:singlesign-onfor all resources,noneedfor userto keeptrackof accountsandpasswordsatmultiplesites,andno plaintext passwords.
Protocol-basedJob Submission Recently, Globus hasbeenenhancedto includean HTTP-basedprotocolfor jobsubmission.Thus, job submissioncanbe initiated from aclient on which no otherGlobuscomponentsareinstalled.Figure3 shows theGlobuscomponentsthatareinvolvedinsucha job submission.First, onehasto authenticatewiththe system,which is donewith the help of public key in-frastructureanda proxydelegationwhile generatinga tem-porarykey. Jobsaresubmittedfrom theclient sidethroughAPI calls known as gram-submitand gram-request. ThegatekeeperontheGlobus-enabledresourceverifieswhethertheuseris allowedto submita job to it andcheckstheavail-ability of theuser’spublickey in agrid mapfile local to theresource.Oncea job hasbeensuccessfullysubmittedto thesystem,it is startedwith the help of the job manager, andits stateis monitoredwith the help of the reporter. Dur-ing startupof a job ausercanregistercallbackhandlersthatprovidejob statusupdates.In ourJavaCoGKit wehaveim-plementedall componentsandservicesresponsiblefor theproxy initialization and the job submission. Furthermorewe have replacedtheC-basedcallbackservicewith a Java-basedeventservice.Thus,all componentsto submita jobareavailablein pureJava, allowing even Windows clientsto submitjobsto Globusservers.
3.3. Additional Security Issues
In the precedingsectionswe addressedsecurity issuesrelatedto authenticationandauthorizationwhile usingthesecuritypolicy suggestedby Globus. The authorizationtousea particularGrid resourcecanbecontrolledvia a grid-mapfile andappropriatelyspecifiedgrouppermissionscon-trolledby thelocal systemadministrators.
Nevertheless,we still have to addressissuessuchasthesecurecommunicationbetweenprograms. To guaranteeprivacy, weusethesecuritymechanismsprovidedby securesocketconnections,whichwecanobtainthroughGlobusIO.
gram-submit Gatekeeper
job-managercallback handler
grid-proxy-init
authentication
proxy-delegation
job-requestregister callback
status
client side server side
reporter
private key
temporary key
challengegrid-map
Figure 3. The components of the Glob us se-curity infrastructure used during job submis-sion. All client side components are availab lewithin the CoG Kit as pure Java components.
In theremainderof this paperwe focusour attentiononour Java CoGKit prototype,which enablesus to build thecomponentslistedin Table1 andusedaspartof aPSE.Be-causeof thelargenumberof packagesandclassesrequiredto exposethenecessaryfunctionalityof theGlobustoolkit,we focus in this paperon a subsetof the classesthat wedeemmostuseful for the developmentof PSE-basedGridapplications.Thedesignof theJava CoGKit is intendedtofacilitatethe developmentof future componentsasa com-munityproject.To supportaniterativeprocessof definition,development,andapplicationof a Java CoGKit in collab-oration with other teams,we classify componentsin fourlayers. This categorizationprovides the necessarysubdi-visions to coordinatesucha challengingopencommunitysoftwareengineeringtask.
Low-Level Grid Interface Components provide map-pingsto commonlyusedGrid services:for example,the Grid information service(the Globus Metacom-puting Directory Service, MDS), which providesLightweight Directory AccessProtocol (LDAP) [9]accessto informationaboutthe structureandstateofGrid resourcesand services; resource managementservices, which support the allocation and manage-ment of computationaland other resources(via theGlobus GRAM and DUROC services); and dataaccessservices, for example, via the Globus GASSservice[3].
Low-Level Utility Components are utility functions de-signedto bereusedby many users.Examplesarecom-
// Step0. Initialization
MDS mds=new MDS("www.globus.org","389","o=Grid");//Step1. Search for an availablemachine
Figure 4. This sample script demonstrateshow we access basic Grid services with thehelp of the Java CoG Kit. Here data for astructural biology code called SnB are lo-cated, an appr opriate machine is selected,and the calculation is executed on that ma-chine .
ponentsthatuseinformationservicefunctionsto findall computeresourcesthat a usercansubmit to, thatprepareand validatea job specificationwhile usingthe extendedmarkuplanguage(XML) or the Globusjob submissionlanguage(RSL), that locatethe geo-graphicalcoordinatesof a computeresourceandthattestwhetheramachineis alive.
Low-Level GUI Components provide a basic graphicalcomponentsthatcanbereusedby applicationdevelop-ers.ExamplesareLDAPattributeeditors,RSLeditors,LDAP browsers,andsearchcomponents.
Application-specificGUI Components simplify thebridge betweenapplicationsand the basic CoG Kitcomponents.Examplesare a stock market monitor,a graphical climate data display component,or aspecializedsearchenginefor climatedata.
Figure4 shows how a small setof servicesprovidedbythe Java CoG Kit may be usedin practice. This Java pro-gramskeletondemonstrateshow simpleit is to build portal-specificserviceswhenaccessingavarietyof basicGrid ser-vicesthroughtheJava CoGKit. In this example,anappro-priatemachineis selectedfor execution,datafor aninstanti-ationof aproblemspecificalgorithmis determined,andthejob is executedon thatmachine,resultingin thegenerationof anoutputfile.
4.1. Low-Level Grid Interface Components
We describeherea subsetof packagesthat provide theinterfaceto the low-level Grid servicesandapplicationin-terfaces.Thesepackagesareusedby many usersto developJava-basedprogramsin theGrid. Wedescribeonly thegen-eral functionalityof thesepackages.A completelist of theclassesandmethodsaccompaniesthedistribution [18].
RSL The packageorg.globus.rsl provides methodsforcreating,manipulating,andcheckingthevalidity of theRe-sourceSpecificationLanguage(RSL) expressionsusedinGlobus [8] to expressresourcerequirements.As shown inStep3 of Figure4, theargumentsto a new call includepa-rametersthatspecifybothcharacteristicsof therequiredre-sourcesandpropertiesof thecomputation.
GRAM The packageorg.globus.gram provides a map-ping to theGlobusResourceAllocation Manager(GRAM)services[8], which allow usersto scheduleandmanagere-mote computations.The classesand methodsdistributedallow usersto submitjobs,bind to alreadysubmittedjobs,andcanceljobsonremotecomputers.Othermethodsallowusersto determinewhetherthey cansubmit jobs to a spe-cific resource(throughaGlobusgatekeeper)andto monitorthejobstatus(pending, active, failed,done, andsuspended).
As shown in Step4 of Figure4 the classGramis usedto createa job with anRSL stringdescribingthe job andamachinecontactthatdetermineson which machinethejobis requestedfor execution. Our Java mappingdiffers fromthatprovidedin Globusfor C throughtheintroductionof aformal job object,aswell as the availability of a sophisti-catedeventmodelin Java. Our implementationutilizesthisevent modeland transfersthe C callbacksinto equivalentJava events. In Java onecannow usethreadsin order to“listen” to aparticulareventthatcantriggerfurtheractions.A Java interfaceGramJobListener that containsthemethodstateChanged(GramJob job) can be usedto definecustomizedjob listenersthatcanbeaddedwith theGramJobmethodaddListener(GramJobListenerlistener).
MDS The packageorg.globus.mdssimplifies accesstothe MetacomputingDirectory Service(MDS) [15], whichis an importantpartof the Globus informationservice. Itsfunctionsinclude(a) establishinga connectionto anMDSserver, (b) queryingMDS contents,(c) printing,and(d) dis-connectingfrom the MDS server. The packageprovidesanintermediateapplicationlayerthatcanbeeasilyadaptedto differentLDAP [9] client libraries,includingJNDI [10],NetscapeSDK [11], andMicrosoftSDK [13].
As shown in Step1 of Figure4, theparametersto initial-ize the MDS classare the DNS nameof the MDS server,the port numberfor the connection,andthe distinguishedname(DN) thatspecifiestheroot for a searchin thedirec-tory tree.A searchis performedin Step2a;thefirst param-eterspecifiesthetop level of thetreein which thesearchisperformed,thesecondparameterspecifiestheLDAP query,andthethird parameterspecifiesthescope,that is, for howmany levels in the treethe searchshouldcontinue(in ourcase,only thenext level). Searchresultscanalsobestoredin a NamingEnumerationprovidedby JNDI.
GASS TheGlobalAccessto SecondaryStorage(GASS)service[3] simplifies the porting and running of applica-tionsthatusefile I/O, eliminatingtheneedto manuallylogontositesandftp files or to install a distributedfile system.The packageorg.globus.gassprovides an essentialsubsetof GASSservicesto supportthe copying of files betweencomputerson which the Grid Servicesare installed. Themethodget(Stringfrom,Stringto) copiesa remotefile to alocal file, andthemethodput(Stringfrom,Stringto) copiesa local file to a remotelocation. The fetch methodusedinour example(Figure4) providesa convenientwrapperandusesinternallythepreviouslymentionedget method.
4.2. Low-Level Utilities
Thelow-levelutility classescurrentlydefinedin theCoGKit provideanabstractdatatyperepresentingacyclic graphsandbasicXML parsingroutines. The graphclassis used,for example,to accessdependenciesbetweenjobs,a majorrequirementfor PSEs. The XML classesareusedto pro-vide transformationsbetweendifferentdataformats.UsingXML hasthe advantagethat a DocumentType Definition(DTD) that is definedfor thesedataformatscanbeusedtoverify whetherarecordto betransmittedis well formedbe-fore it is sentto a server. Thusthe load on serverscanbedramaticallyreduced.Theavailability of a dependency be-tweenjobs is a significantextensionto theexisting Globuslow-levelapplicationinterface.In addition,wehavedefineda generalconceptof a machine and job broker interface.Thisenablesaprogrammerto defineacustomizedselectionof machinesandjobs dependenton his demand.We haveusedthis technologyas part of a high-throughputbroker
schedulingpolicy
machines jobs
broker
accesspolicy
Figure 5. A broker interface allo ws us tospecify an easy way to develop compatib lecomponents relying on this interface . Jobsand machines are selected based on a pre-defined access/security polic y as well as ascheduling polic y. The policies may be gen-erated dynamicall y based on other system in-formation.
that is implementedin Java but canalsoexposedthroughCORBA objects. The GECCOapplicationintroducedinSection4.4usestheJava-basedmachineandjob brokers.
The broker is a good exampleof a universally usefulcomponentfor PSEdevelopers,aswell asGrid users.Herea setof jobs andmachinesis storedin two tables.Depen-dent on a schedulingand accesspolicy, a machineis se-lectedanda job is scheduledfor theexecutionon this ma-chine (seeFigure 5). We have defineda simple interfaceoutlinedin Figure6. Thisinterfaceallowsustoaddjobsandmachinesto thesetssothatit is possibleto administerthemdynamically. With thehelpof thisinterfacewehavedefinedmultiple schedulingpoliciessuchasfirst-come-first-servedandloadbalancingbasedon resourcecharacteristics.Cur-rently we areinvestigatingthe useof economymodelsforschedulingjobsto machines.
4.3. Low-Level GUI Components
The Java CoG Kit low-level GUI componentsprovidebasicgraphicalcomponentsthatcanbeusedto build moreadvancedGUI-basedapplications. Thesecomponentsin-cludetext panelsthatformatRSLstrings,tablesthatdisplayresultsof MDS searchqueries[17], treesthatdisplaythedi-rectoryinformationtreeof the MDS, andtablesto displayHBM andnetwork performancedata.Eachcomponentcanbe customizedand is availableasJavaBean. In future re-leasesof theJavaCoGKit it will bepossibleto integratethebeanin aJava-basedGUI compositiontool suchasJBuilderor VisualCafe.
Figure 6. This code fragment sho ws the ele-mentar y methods of the broker. Jobs and ma-chines can be added. The job and machinereturned by the get methods are defined bythe policies and the algorithms defined by anobject instantiation of the interface .
4.4. PSEApplication Level Utilities and GUI Com-ponents
High-level graphicalapplicationscombinea variety ofCoGKit componentsto deliver a singleapplicationor ap-plet. Theseapplicationscanbe combinedto provide evengreaterfunctionality. The usershouldselectthe tools thatseemappropriatefor thetask. To demonstratetherangeofapplications,we have includeda setof screendumpsthathighlight the look andfeel of someapplicationsdevelopedto date.
GECCO The Graph Enabled Console COmponent(GECCO)is a graphicaltool for specifyingandmonitoringthe executionof setsof taskswith dependenciesbetweenthem[16][14]. Specificallyit allowsoneto
2. debugthespecificationin orderto find erroneousspec-ificationstringsbeforethejob is submitted;and
3. executeandmonitor the job graphicallyandwith thehelpof a log file.
As shown in Figure7, eachjob is representedasa nodeinthegraph.A job is executedassoonasits predecessorsarereportedto have successfullycompleted.Thestateof a jobis animatedwith colors.It is possibleto modify thespecifi-cationof thejob while clicking onthenode:A specificationwindow popsup allowing the userto edit the RSL, the la-bel, andotherparameters.Editing canalsobe performedduringruntime(job execution),henceproviding for simplecomputationalsteering.
Figure 7. The Grid Enabled Console COmpo-nent (GECCO) allo ws the user to specify de-pendencies between tasks that are to be exe-cuted in the Grid envir onment.
High-Thr oughput Broker We have developeda proto-type of a high-throughputbroker to testwhetherthe inter-facesand classesallow one to easily generatehigh-levelcomponentsthatsimplify job maintenancetasksfor certainproblem-solvingstrategies. Oneof the tasksthat hasbeenidentifiedandis commonto many solutionstrategiesis toperforma parameterstudy[2][4]. That is, an algorithmisrepeatedlyexecutedwith a varietyof parameters.Our sys-temis basedon theinterfaceof a brokerandthusallowsusto clearlyseparatetheGUI presentationfrom thefunction-ality (Figure8). Theprototypelooksfor computeresourcesavailablein a pool of machinesformedby a Grid informa-tion servicewith the help of the Globus MDS. From thispool we selectthoseresourcesthat are idle andareavail-ablefor calculation.If a resourceis not ableto fulfill a job(becauseof connectiontimeout or excessive time neededto completethejob), theresourceis automaticallyremovedfrom the setof viable candidates.The setof resourcesaswell as thoseremoved from the list can be manipulatedthroughan interactive shell. A similar interfaceexists forthe jobs. Specialattentionhasto be placedon the imple-mentationof suchabroker. Althoughit is possibleto spawnfor eachjob andmachinea threadthatmaintainstheappro-priateobject,we have chosento maintainthejobsandma-chinesin lists to avoid theoverheadassociatedwith threadsand the expectedresourcelimitations on the machineonwhich the systemis running. Thus,we areableto handlesubmissionsthatmaintain10,000or morejobs,a taskthatwouldotherwisebeimpossible.
5. Installation and Upgrading
An importantfunction that mustbe provided by a PSEis to install andupgradethesoftwarethataccessesthevar-iousservicesexposedaspartof its design.UsingJava willprovideuswith severaloptionsfor deployingourclientsoft-
Figure 8. A high thr oughput broker allo ws thesubmission of many jobs as par t of a prob-lem. After all jobs are completed a solution ofthe problem can be obtained. The progressof the calculation is monitored with a GUI.
ware.In additionto traditionalmethodsof deliveringclientsoftwareto be installedandconfiguredprior to its use,wecandevelopthin-clientsoftware,whichcanbedynamicallyinstalledor updatedaswell asloadedat timeof use.
Preinstallationof the software in the form of a standaloneapplicationor a library is convenientfor applicationsthatwould take too long to be installedvia a network con-nection(Figure 9). This strategy is today usedby manycommercialportalsaspartof their accesssoftwareenabledwith the help of so-calledbrowserplug-ins. Nevertheless,we recognizethe fact that it is sometimesnot possibletoinstallany softwareon theclientcomputerbecausetheuserdoesnot have sufficient accessto it. This requires,at thecostof additionaldownloadtime, downloadingthe appro-priate jar files from a well-definedURL. In both casesitwill be possibleto augmentthe jar files with authentica-tion measuresin the form of certificates.Thesewill allowclientsto identify thesourceof thecodeupondownloadingour softwareandto verify that it canbe trustedfor useontheir systems.
Figure 9. The installation of the CoG Kit ontoa client can be done prior to the star t of theapplication as a standalone application orthe installation of a librar y or during an on-demand execution.
vicesfor large-scale,widearea,multi-institutionalenviron-mentsandfor applicationsthat requirethecoordinateduseof multiple resources.In the CommodityGrid project,weseekto bridge thesetwo worlds so as to enableadvancedapplicationsthat can benefitfrom both Grid servicesandsophisticatedcommoditydevelopmentenvironments.
TheJava CommodityGrid Toolkit (CoGKit) describedin this paperrepresentsa first attemptat creatingof suchabridge. Building on experiencegainedover the pastthreeyearswith the useof Java in Grid environments,we havedefineda setof classesthat provide the Java programmerwith accessto basicGrid services,enhancedservicessuit-ablefor thedefinitionof desktopproblemsolvingenviron-ments,and a rangeof GUI elements. Initial experienceswith thesecomponentshave beenpositive. It hasprovenpossibleto recastmajorGrid servicesin Java termswithoutcompromisingonfunctionality. SomesubstantialJavaCoGKit applicationshave beendeveloped,and reactionsfromusershavebeenpositive.
Our futurework will involve theintegrationof moread-vancedservicesinto the Java CoG Kit andthe creationofotherCoG Kits, with CORBA, DCOM, andPythonbeingearly priorities. We alsohopeto gain a betterunderstand-ing of wherechangesto commodityor Grid technologiescanfacilitateinteroperabilityandof wherecommoditytech-nologiescanbeexploitedin Grid environments.
With the help of the CoG Kits we have prototypedaportalto a structuralbiology problemsolvingenvironment.Otherprojectsarecurrentlyinvestigatingtheuseof theCoGKit to simplify theaccessto Grid resources.SuchprojectsincludetheastrophysicsportalCactus,theNCSA Userpor-tal, and SDSCHotpage. The requirementsdemandedbysuchprojectshaveinfluencedourpresentdesign,andwearecollaboratingwith projectdevelopersto enhancethe com-ponentsweprovide in theCoGKit. Most recently, wehave
This work was supportedby the Mathematical,Infor-mation, and ComputationalScienceDivision subprogramof the Office of AdvancedScientificComputingResearch,U.S.Departmentof Energy, underContractW-31-109-Eng-38. Globus researchand developmentis supportedbyDARPA, DOE,andNSF. WethankGeoffrey C.Fox,DennisGannon,andJasonNovotny for valuablediscussionsduringthe courseof the CoG Kit development.This work wouldnothavebeenpossiblewithout thehelpof theGlobusteam.
For up-to-date release notes, and further in-formation readers should refer to the Web pagehttp://www.globus.org/cog[18].
References
[1] MarcAbrams,DonaldAllison, DennisKafura,CalvinRibbens,Mary Beth Rosson,Clifford Shaffer, andLayne Watson. PSEResearchat Virginia Tech: AnOverview. Departmentof ComputerScience,VirginiaTech,Blacksburg, VA 24061,1999.
[2] D. Abramson,R. Sosic,J. Giddy, andB. Hall. Nim-rod: A tool for performingparameterisedsimulationsusing distributed workstations. In Proc. 4th IEEESymp.on High PerformanceDistributedComputing.IEEE ComputerSocietyPress,1995.
[3] JosephBester, Ian Foster, Carl Kesselman,JeanTedesco,andSteven Tuecke. GASS: A datamove-mentandaccessservicefor wide areacomputingsys-tems.In Proc. IOPADS’99. ACM Press,1999.
[4] D. H. J. Epema,M. Livny, R. vanDantzig,X. Evers,andJ.Pruyne.A WorldwideFlock of Condors:LoadSharingamongWorkstationClusters.FutureGenera-tion ComputerSystems, 12,1996.
[5] I. Foster and C. Kesselman,editors. The Grid:Blueprint for a Future Computing Infrastructure.Morgan-Kaufmann,1999.
[6] Ian Foster. Building the Grid: An Inte-grated Services and Toolkit Architecture forNext Generation Networked Applications.http://www.gridforum.org/building_the_grid.htm,July 1999.
[7] E. Gallopoulos,E. Houstis,andJ.R.Rice. Problem-Solving Environments for ComputationalScience.
[9] Tim HowesandMark Smith. LDAP : ProgrammingDirectory-EnabledApplicationsWith LightweightDi-rectoryAccessProtocol. TechnologySeries.Macmil-lanTechnicalPublishing,1997.
[10] JAVA Naming and Directory Interface (JNDI).http://java.sun.com/products/jndi.Version1.2.
[11] NetscapeDirectory and LDAP Developer Central.http://developer.netscape.com/tech/directory/index.html.
[12] J. R. Rice and R. F. Boisvert. From scientific soft-warelibrariesto problem-solvingenvironments.IEEEComputationalScienceandEngineering, Fall:44–53,1996.
[14] GregorvonLaszewski. A LooselyCoupledMetacom-puter: CooperatingJobSubmissionsacrossMultipleSupercomputingSites. Concurency, Experience, andPractice, Mar. 2000.
[15] Gregor von Laszewski, S. Fitzgerald, I. Foster,C. Kesselman,W. Smith, and S. Tuecke. A Direc-tory Servicefor ConfiguringHigh-PerformanceDis-tributed Computations. In Proc. 6th IEEE Symp.on High-PerformanceDistributed Computing, pages365–375,1997.
[16] GregorvonLaszewski andIanFoster. Grid Infrastruc-tureto SupportSciencePortalsfor LargeScaleInstru-ments.In Proc.of theWorkshopDistributedComput-ing on the Web (DCW). University of Rostock,Ger-many, June1999.
[17] Gregor von Laszewski, Ian Foster, JarekGawor, War-renSmith,andSteveTuecke. CoGKits: A Bridgebe-tweenCommodityDistributedComputingandHigh-PerformanceGrids. In ACM 2000JavaGrandeCon-ference, San Francisco,California, June3-4, 2000.http://www.extreme.indiana.edu/java00.
[18] Gregor von Laszewski, JarekGawor, andPeterLane.Java CoG Distribution. http://www.globus.org/cog,January2000.Version0.8.6.
