Copyright © 2002 IEEEThis position paper considers how existing Grid infrastructure can be use to support Java computation on the Grid. We are interested in a class of Java applications characterize by distributed, mobile code. We identify and address these problems by building upon existing Grid services, resulting in a propose infrastructure called Coglets that supports homogenous, secure access to Java-enabled Grid resources.Darren Webb and Andrew L. Wendelbor

Webb, D.

Wendelborn, A.

Adelaide Research &amp; Scholarship

                      Copyright © 2002 IEEE. Reprinted from      IEEE/ACM International Symposium on Cluster Computing and the Grid (2nd : 2002 : Berlin, Germany)  This material is posted here with permission of the IEEE. Such permission of the IEEE does not in any way imply IEEE endorsement of any of the University of Adelaide's products or services.  Internal or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by writing to pubs-permissions@ieee.org.  By choosing to view this document, you agree to all provisions of the copyright laws protecting it.   Java CogletsDarren Webb and Andrew L. WendelbornDepartment of Computer ScienceUniversity of AdelaideSouth Australia 5005, AustraliaAbstractThis position paper considers how existing Grid in-frastructure can be used to support Java computationon the Grid. We are interested in a class of Java appli-cations characterized by distributed, mobile code. Weidentify and address these problems by building uponexisting Grid services, resulting in a proposed infras-tructure called Coglets that supports homogenous, se-cure access to Java-enabled Grid resources.1 IntroductionThe Grid is a geographically-dispersed, large-scaleexecution environment used to solve large, complexproblems. The Grid integrates heterogeneous resourceswith dynamic availability and capability connected byan unreliable network. The Globus toolkit[1] is an en-abling technology that provides us with a uniform viewof this execution environment. The toolkit enablesus to ﬁnd resources, obtain performance data, stageprogram inputs, remotely execute programs, and stageprogram results.Many projects have extended their software to takeadvantage of Grid-enabled resources. Generally, theseprojects access basic Grid services through the JavaCommodity Grid toolkit (CoG)[4]. The toolkit enablestheir software to transfer Java code to a resource andfork a virtual machine to execute the code. An alterna-tive is the “100% Java GRAM”[4] which treats a JARﬁle as an executable. The Java GRAM ﬁrst stages theJAR ﬁle then forks a virtual machine to execute itscode. The CoG does not address issues of locatingJava-enabled Grid resources, heterogeneous Java in-stallations, or security. The Java GRAM handles someof these issues, but necessitates replacing some existingGlobus services with those of the Java GRAM.Here we propose a new infrastructure to standard-ize Java computation on the Grid. This infrastructureexploits existing Globus services and protocols for se-curely staging and executing Java code in a mannerthat is natural to Java programmers. Central to thisinfrastructure is the Coglet, a simple mechanism forspecifying Java execution on the Grid. Coglets aimto exploit the platform independence of Java, and thearchitecture-neutral protocols of Globus, in a consis-tent, secure manner.2 CogletsA Coglet is a simple speciﬁcation for running Javaon the Grid. A Coglet is similar to an applet, specify-ing a reference to Java code to be downloaded and thename of an executable class. However, Coglet execu-tion occurs on a Grid resource. Like an applet, a Cogletis speciﬁed by a Coglet tag. This tag is an applicationof the Resource Speciﬁcation Language (RSL), used inGlobus for resource queries and job requests.Suppose we want to issue a request to execute a Javaprogram named Main whose class is stored in a JARﬁle named classes.jar, parameter name=value andprogram argument arg1. To execute the Java program,we start a virtual machine program with argumentsincluding the location of classes, parameters, the nameof the class containing a main() method, and programarguments. Speciﬁed directly in RSL it is:&(executable=java)(arguments=-classpath classes.jar-Dname=value Main arg1)There are several problems with this request. First,the executable attribute speciﬁes the Java virtual ma-chine program and the arguments attribute is litteredwith low-level details. The executable should be theMain class and its codebase in classes.jar. Thishas ramiﬁcations for executable staging. Globus sup-ports staging of the executable, stdout and stderrattributes. This means the Java programmer is respon-sible for staging the codebase. Second, the request as-Proceedings of the 2nd IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGRID02) 0-7695-1582-7/02 $17.00 © 2002 IEEE sumes that Java is installed, in the path, invoked bythe command java, and is correctly conﬁgured. Thisis not always the case.We propose the request be:&(executable=Main)(codebases=https://codebase:666/classes.jar)(params=-Dname=value) (arguments=arg1)We have introduced two new attributes and modi-ﬁed the interpretation of another two. The executableattribute now speciﬁes a class containing a main()method, denoting the name of a Java program. Op-tionally, this attribute could specify a JAR ﬁle witha manifest entry denoting a class containing a main()method. The codebases attribute speciﬁes the class-path as a comma-delimited list of URLs denoting thesearch path for classes. Each URL speciﬁes a direc-tory or JAR ﬁle. The params attribute enables theprogrammer to specify additional virtual machine pa-rameters, including system properties and virtual ma-chine conﬁguration. Finally, the arguments attributespeciﬁes input arguments for the program.We feel the new request is more intuitive to Javadevelopers, and better ﬁts the deﬁnition of the requestattributes. However, addition and redeﬁnition of therequest will require a specialized jobmanager capableof correctly interpreting the attributes.We propose a jobmanager-java for Java programs,that interprets these request arguments and forks amachine with the correct arguments. A dedicated job-manager for Java programs oﬀers a number of beneﬁts.The jobmanager-java implicitly identiﬁes a Java byte-code processor independent of its implementation (vir-tual machine or direct execution processor) and low-level execution details. The jobmanager-java identiﬁesa Java-enabled resource that can be published to thegrid information services. This identiﬁes Java-enabledGrid resources to users without the guess work. Butimportantly, the virtual machine program can be con-ﬁgured to apply security policy to code mobility. Wenow discuss this issue in more detail.3 Grid SandboxJava introduces a number of interesting problems tothe Grid. A Java class loader can download code acrossa network. Code downloaded across the network is nottrustworthy, so there is a need to apply some control.For this purpose, Java provides the security manageror access controller to establish security policy.One reason for the success of applets is the appletsandbox. Applets are untrusted programs downloadedover the network and run locally. The sandbox is asecurity manager that imposes strict controls on whatuntrusted code can and cannot do. For example, anapplet can not access the local ﬁlesystem, execute pro-grams or native code of the local system, or initiatesocket communication to hosts other than the webserver. These controls are too low-level and too re-strictive for Grid computation[3].We propose a Grid Sandbox that is intended to se-cure code mobility and still facilitates data mobilitywith other participants. We envisage the sandbox,built upon the Grid Security Infrastructure (GSI)[2],will establish a “ring of trust”, ultimately comprisinga set of mutually authenticated resources and partici-pants within which less restrictive interchange can takeplace.The sandbox enforces a policy whereby code can bedownloaded only from trusted services or participantsinside the sandbox. GSI provides communication in-tegrity, hence an eavesdropper can read downloadedcode but not modify it. Consequently, we do not feelit necessary to enforce strong policies that restrict ﬁleaccess, initiation of socket connections or invocation ofexternal code.4 SummaryThe Coglet infrastructure we propose enables secure,peer-to-peer computation using Java on the Grid. TheCoglet tag ﬁts neatly within the RSL framework tostandardize the submission of Java-based job requests.The jobmanager-java interprets the Coglet tag and ini-tiates a Java virtual machine, with a ﬂexible but re-strictive Grid sandbox security model. The infrastruc-ture is simple, ﬂexible and general. Further, we believethe Coglet infrastructure can be easily applied to othercommodity toolkits, such as the toolkit for Python.References[1] I. Foster and C. Kesselman. Globus: A metacomput-ing infrastructure toolkit. The International Journalof Supercomputer Applications and High PerformanceComputing, 11(2):115–128, Summer 1997.[2] I. Foster, C. Kesselman, G. Tsudik, and S. Tuecke.A Security Architecture for Computational Grids. InProc. 5th ACM Conference on Computer and Commu-nications Security Conference, pages 83–92, 1998.[3] H. Takagi, S. Matsuoka, H. Nakada, S. Sekiguchi,M. Satoh, and U. Nagashima. Ninflet: a migratableparallel objects framework using Java. Concurrency:Practice and Experience, 10(11–13):1063–1078, 1998.[4] G. von Laszewski, I. Foster, J. Gawor, and P. Lane. AJava Commodity Grid Kit. Concurrency and Computa-tion: Practice and Experience, 13(8–9):643–662, 2001.Proceedings of the 2nd IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGRID02) 0-7695-1582-7/02 $17.00 © 2002 IEEE 

Java coglets

https://digital.library.adelaide.edu.au/dspace/bitstream/2440/29501/1/hdl_29501.pdf

Java coglets

Abstract

Similar works

Full text

Available Versions

Adelaide Research & Scholarship

Java coglets

Abstract

Similar works

Full text

Available Versions

Adelaide Research &amp; Scholarship

Adelaide Research & Scholarship