Abstract 1. Introduction

Transcription

1 Jaguar: A Distributed Computing Environment Based on Java Sheng-De Wang and Wei-Shen Wang Department of Electrical Engineering National Taiwan University Taipei, Taiwan Abstract As the development of network technology, distributed computing has become one of important programming practices. We are motivated to develop a distributed computing environment, called Jaguar, for application developers to rapidly and efficiently design their distributed programs. To achieve portability, Jaguar is based on the Java programming language. We also utilize related application programming interfaces of Java to implement this environment, including socket programming, object serialization, and reflection. In addition, each component within Jaguar is an object. The Jaguar environment consists of four kinds of objects: Administrator, Supervisor, Task, and Resource objects. Administrator and Supervisor objects, provided by the environment, are responsible for the management of the environment. Task objects, designed by programmers, perform computations. Resource objects are parameters required by the Task objects. Cooperation of these distributed objects results in successful executions of distributed computing programs. The object-oriented nature of the Jaguar environment provides a promising framework for distributed program development and in the same time facilitates future maintenance and extension of the environment itself. 1. Introduction Much research has been done about distributed computing based on Java. Since the Java programming language provides various mechanisms for designing networked applications, different research groups have their respective issues of building distributed applications. The Do! project [1] provides parallel and distributed frameworks to ease the task of developing distributed applications using Java. The framework is responsible for managing program graphs, computing tasks, and required parameters. It has two features: run-time remote creation of objects and remote methods invocations. During execution, the framework dynamically creates objects on machines, and provides a mechanism for objects to access other objects on remote machines. The Do! project utilizes Java RMI (Remote Method Invocation) [2] to achieve inter-machine method invocation. A characteristic of the Do! project is transparency of remote invocations. Though RMI provides remote invocations, invocations of remote methods are different from that of local methods: remote methods may throw special exceptions to indicate error occurs. Therefore, RMI is not transparent for users. To simplify the development of distributed applications, the Do! project hides details of remote method invocations. Programmers only need to make use of methods provided by the framework, regardless of the location objects reside in. Traditionally, distributed computing is based on high-level languages other than Java, such as C/C++, and Fortran. Due to the popularity of Java language, researchers have developed distributed or parallel computing systems similar to existing ones. For instance, the JPVM [3] library is a parallel computing system that supports similar interfaces to the Parallel Virtual Machine (PVM) [4]. Since JPVM is based on Java, it has advantages over PVM in portability and thread safety. The POPCORN [4] project intends to accomplish globally distributed computations over the Internet. Since millions of computers are connected to the Internet, utilization of idle computers should be capable of performing computations that require a huge amount of time. A POPCORN application is a main thread running on a processor, and it keeps spawning sub-computing units as Java applets. Browsers having Java virtual machines inside have capabilities to make Java applets executed. In this way, computers connected to the Internet download applets from POPCORN web sites, and collaboratively act as a virtual computer. After computations, sub-computing units transmit results to the original POPCORN application, and verification is done by the application. 1

2 Like the POPCORN project, JAM (Java Applet in Massively parallel computing) [6] is designed to making use of idle computer connected to the Internet. Sub-computing units are also distributed in the form of Java applets. These Java applets communicate with the JAM server through socket interfaces. After obtaining results of computations, Java applets return results to the JAM server, and the server combines those results to get solutions. Our framework adopts basic networking APIs such as socket programming for data communication. The main advantage of using socket programming lies in the transmission efficiency. Writing network programs with socket APIs is tedious; therefore, our framework hides the details of data transmission from users. 2. System Architecture The proposed distributed computing environment consists of several kinds of distributed objects, including Administrator object, Supervisor object, Task object and Resource object. The Administrator object is executed in a process called Java virtual machine [7] running in a computer. The Administrator object takes responsibility for monitoring the system. Supervisor objects assist Administrator object to make the system function well. Like Administrator object, Supervisor object is also executed in a Java virtual machine. The framework provides Administrator and Supervisor objects, and collaboration of these two kinds of objects makes execution of Task objects possible. Task objects are user-defined objects performing the computations, and Resource objects are parameters of Task objects. Objects within the system cooperate to complete the computations. Figure 1: System architecture In our distributed computing environment, computations are classified and mapped to separate Task objects of different orders. The purpose of the classification is to regulate the execution order of computations. Task objects in the same level have no dependency; hence, these 2

3 Task objects can be executed concurrently. In this framework, each Task object retrieves data as input parameters from other Task objects in the previous level, performs computations, and stores output data in the form of Resource objects. Our design concentrates on this sort of problems in distributed computing, and users who make use of the system need to convert their computations into the type that is applicable to the environment. Figure 1 shows an example of a distributed computing environment. Figure 2: Task and Resource objects Figure 2 presents a program that consists of three levels of computations. In our terminology, this program is divided into seven Task objects. Task T a, T b, and T c must be executed before Task T d,t e,andt f. Resource R i1,r i2,andr i3 are input parameters of Task T a and T b.fromfigure2,task T a,t b,andt c have no dependency; therefore, these Tasks can be placed in the same level and computed concurrently. Resource R a1,r b1,r b2,r c1,andr c2 are output data and also input parameters of Tasks in the next level, such as Task T d,t e,and T f. After repeated execution of Tasks in different levels, the result of the program is obtained. Before using this computing environment, users need to prepare a script file that describes the computations such that the program graph is applicable to the system. That is, users have to 3

4 implement Task and Resource objects or select proper Resource objects provided by our framework. Besides, a script file describing the execution order of Task objects and flow of Resource objects is also indispensable. A script compiler provided by our framework is responsible for checking the syntax of the script and reading related information about the environment. If no errors occur, the system starts execution, and the result of computations will be returned. Joshua Script Format Joshua script is the scripting language designed for the proposed distributed computing environment. The syntax of Joshua script is similar to that of Visual Basic with the advantage of readability. The format is illustrated in Figure 3. Keywords are in bold face, and comments begin with %. Every Joshua script file can be segmented into two sections: a declaration section and an execution section. The declaration section begins with the keyword var or interface, and contains the following information: Declarations of user-defined class types Users have to specify class types of Task objects and Resource objects that are not provided by the framework. % Declaration Section interface userdef user-defined-class-list const variable-identifier = constant-value as system-defined-class import framework-defined-class-list include header-file declare data user-defined-data-type as system-defined-class end var dim task-identifier as user-defined-class dim resource-identifier as system-defined-class dim resource-identifier as user-defined-data-type [ from class-file-name ] dim resource-identifier as framework -defined-data-type [ from < class-file-name > ] dim resource-identifier (size, ) as system-defined-class dim resource-identifier (size, ) as user-defined-data-type [ from class-file-name ] dim resource-identifier (size, ) as framework -defined-data-type [ from < class-file-name > ] end % Execution Section begin resource-identifier = constant-value task-identifier. src = task-identifier. resource-identifier task-identifier. src =(task-identifier. resource-identifier, ) task-identifier. load = constant-value resource-identifier. flow = constant-value parallel exec ( task-identifier ) exec ( task-identifier ) % Task objects within a parallel-end segment are of the same order. end exec ( task-identifier-list ) % Task objects appear in a exec-statement are of the same order. return task-identifier. resource-identifier end Figure 3: Joshua script format 4

5 Declarations of constant variables The constant variable must be one of system-defined class types, such as Integer, Long, Double and Float types in package java.lang. Declarations of framework-defined class types Our framework provides commonly used data types including matrix, vector, and so on. It is necessary to specify class types of Resource objects used in computations. Inclusion of header files For convenience, Joshua script supports the syntax of including header file that contains declarations of constants and class types. Identifiers and class types of Task and Resource objects Joshua script also supports the syntax of multi-dimensional arrays. The execution section describes the flow of the execution. This section begins with the keyword begin and ends with the keyword end. The following information is included in the section: Identifiers of Resource objects as parameters of a certain Task object The construction of Task objects requires Resource objects. Programmers have to enumerate parameters of a Task object. Execution order Most statements in the execution section describe the execution order of Task objects within the environment. Lack of information about execution order results in failure to dispatch Task objects successfully. Load levels of Task objects To make good use of computers in the environment, Task objects should not be assigned to machines at random. Take efficiency into consideration, Task objects that require much CPU cycles to compute should be assigned to machines of high performance. In Jaguar, the load of a Task object is divided into nine levels that represent relative degrees. Programmer doesn t have to list precise ratios of loads; instead, estimated values are acceptable. Programmers ought to point out estimated loads of Task objects in the script, and the Administrator object will assign Task objects to machines to efficiently take advantage of processors in the environment, and achieve optimal performance. After execution, the Administrator object will collect accounting information of the system, including execution times of Task objects, and transmission times of Resource objects. If the program is executed again, the Administrator object will dispatch Task objects according to accounting information in order to improve the performance. The levels of loads are listed in Table 1. The values are sorted in descending order. These constant values are defined in a header file provided by the framework. Level JHS_CRITICAL JHS_HIGHEST JHS_HIGH JHS_ABOVE_NORMAL JHS_NORMAL JHS_BELOW_NORMAL JHS_LOW JHS_LOWEST JHS_IDLE Table 1: Load and flow level Flow levels of Resource objects Transmission times of Resource objects are influenced by the sizes of bytecode files and serialized data files. The delay it incurs cannot be ignored. For this reason, programmers are bound to roughly indicate the flow levels of Resource objects. The constant values for defining load and flow levels are listed in Table 1. Administrator Object In Jaguar, the Administrator object takes control over the whole system and monitors the operation of Supervisor objects and Task objects. Unlike other distributed objects in the system, there is only one Administrator object in the environment. Before the execution of the system, the Administrator object has to read a binary file generated by the Joshua script compiler. The compiler reads the script file written by programmers, compiles the script, and generates a binary file representing the program graph, whose extension file name is INF. The aim of compilation is to check the syntax of the script file, and make necessary data files. If no errors and warnings are found in the script, the 5

6 intermediate binary file is generated. The size of the binary file is in general less than that of the original script, and redundant information is removed. The Administrator object will command other objects according to this INF file. Figure 4 shows the internal structure of an Administrator object. Figure 4: Internal structure of an Administrator object In essence, the Administrator object is a Java application. The basic components are listed below. AdministratorThread The AdministratorThread object is a threaded object, and it s the main thread of the Administrator object. The AdministratorThread object also controls other threaded or non-threaded objects inside the application. MessageReceiver The MessageReceiver object is also derived from Thread class in Java. This thread is in responsible of receiving messages. It binds a well-known port and waits for incoming messages. The MessageReceiver object temporarily stores the messages in a list, and informs the AdministratorThread object of the arrival of new messages. By doing so, AdministratorThread objects can retrieve messages. Using a separate thread in charge of receiving messages has the advantages of concurrent executions. In this way, other threads in the Administrator object have capabilities to execute even when new messages arrive. Besides, it is beneficial to use threads instead of usingprocessesinconsiderationoftheoverhead of forking a new process. Objects in this distributed environment utilize thread mechanism for efficiency. FileServer The FileServer object is a threaded object providing file service. Before the computations start on Supervisor side, Supervisor objects requests Resource objects and Task objects from the Administrator object or other Supervisor objects. For this reason, the Administrator object 6

7 has to provide file service to Supervisor objects. Besides, the FileServer object also has capability of dealing with multiple clients simultaneously. MemoryBlock The FileServer object reads files in local disks. In addition, the FileServer object provides a special mechanism for data storage. When a Task object is terminated, it can store output data in memory, not in disks. The FileServer object keeps a table that contains the mapping of virtual file names to blocks of memory. When a Supervisor s request arrives, the FileServer object first looks up the file identifier in the table. If the identifier exists, the FileServer object converts the specified block of memory to a stream of data immediately, and sends the data to the client. If the file name doesn t exist, the request is re-directed to local disks. Since access to memory is faster than access to files, this mechanism results in fast data transmission. Figure 5: Monitor The INF file saves information in the script. The Monitor object records the information after reading the INF file. Scheduler The Scheduler object, a threaded object, is another important component of the Administrator object. The Scheduler object has to decide the machine to which a Task object should be assigned. When the system starts, Administrator object reads the INF file, saves information in the Monitor object, and invokes the Scheduler object. In addition, Administrator object also reads a configuration file that gives a description of machines in the system. The Memory files dispatch of Task objects depends on several significant factors, such as loads of Task objects, flows of Resource objects, states of Task objects, and the relative computing capabilities of computers. TaskController TaskController objects assist the Scheduler object to control remote Task objects. When a Task object is dispatched to a remote machine, the Scheduler object constructs a new TaskController object to manage the construction of the corresponding Task object. Then the TaskController object monitors the Task object until the Task object is terminated. The TaskController object needs to send 7

8 information about Resource objects to the Supervisor object, and periodically asks the Supervisor object to report the status of Task objects. Before construction of a new Task object, TaskController object has to ensure all input parameters are available. TaskController object is also a thread within the application. TaskInfo table The TaskInfo table maintains information about Task objects, including status, location, and execution time. TaskController objects have to lookup states about Task objectsinthistable. ResourceInfo table The ResourceInfo table keeps information about Resource objects. ResourceInfo table is more complicated than TaskInfo table because several Task objects may simultaneously access a Resource objects. Therefore, a Resource object has different states in different machines. TaskController objects have to look up states of Resource objects in this table. Supervisor Objects A Supervisor object executes in a Java virtual machine on different hosts and it is responsible for constructing Task objects and transmitting Resource objects. In Jaguar, any computer permits the co-existence of Supervisor objects, and each Supervisor object, which is a process in essence, binds a specific port for communication. However, take efficiency into consideration, it is proposed that only one Supervisor object exist in a computer. The reason is that Supervisor objects compete CPU utilizations with all Task objects; therefore, fewer Supervisor objects waste fewer CPU cycles, and Task objects are able to fully utilize the processor. During the execution, the Administrator object sends messages to command Supervisor objects to perform actions, such as reporting states of Task objects, constructing a Task object, getting Resource objects from other machines, and so forth. Before Task objects execute, Supervisor objects must fetch the bytecode files of Task objects and Resource objects. Owing to the distributed computing environment, maybe the bytecode files are not in the same machine as Supervisor objects. In this situation, Supervisor objects cannot directly access the bytecode files and data files from the local storage equipment. Thus, Supervisor objects have to download these required files from the Administrator object or other Supervisor objects. Before the Supervisor object downloads files, Administrator object sends information about Task and Resource objects. Then the Supervisor object downloads files, and construct Task and Resource objects. Object construction involves using application programming interfaces and mechanisms provided by Java, such as reflection and object serialization. After the construction of Task and Resource objects, Supervisor objects reports the current status to the Administrator object. The Administrator object will send a message to ask Supervisor objects to start the execution of Task objects. Within a Supervisor object, several Task objects may be executed concurrently. In Jaguar, Task objects are executed as threads in the same process as the Supervisor object in consideration of the overhead. Adopting multi-threaded architecture avoids the overhead of spawning a new process, which is mentioned before. During the execution of Task objects, the Supervisor object in the same machine monitors the execution. When Task object terminates, the Supervisor object collects output resources and temporarily store resources in memory. When Administrator object or other Supervisor objects request these resources, a thread within this Supervisor object reads the resources previously stored in memory, and binds a port for data transmission. The Supervisor object also records the execution time of Task objects and elapsed time for downloading Resource objects. Then the Supervisor object reports to the Administrator object, and the Administrator object maintains the information. 8

9 Figure 6: Internal structure of a Supervisor object We introduce basic components of a Supervisor object in brief: SupervisorThread A SupervisorThread object is a threaded object, and it s the main thread in a Supervisor object, which is a Java application. The SupervisorThread object controls other objects within the Supervisor object. ReflectionThread A ReflectionThread object is a threaded object. When a Supervisor object gets a message that commands the Supervisor object to create a new Task object, it constructs a new ReflectionThread object. For this reason, the number of ReflectionThread objects is equal to that of Task objects within a Supervisor object. The ReflectionThread object downloads necessary files for the construction of a Task object and constructs the Task object. After the Task object is terminated, the ReflectionThread object reads and passes output data to a FileServer object. NetworkClassLoader A NetworkClassLoader object downloads bytecode files located in remote machines if necessary. The ReflectionThread object utilizes the NetworkClassLoader object for task construction. MessageReceiver The MessageReceiver object will be described below in detail. FileServer The FileServer object is introduced before. Task Objects Unlike Administrator and Supervisor objects, Task objects are designed and implemented by users who take advantage of Jaguar. Task objects read input parameters, perform computations, and write output data. Programmers have to follow some rules in order to make Task objects executed normally in the system. A qualified Task object for Jaguar must be derived from a base class, dcs.util.basetask, which is provided by the Jaguar framework. The BaseTask class defines basic methods and properties and stipulates that programmers have to override these methods in their own Task objects. Figure 8 is the sample code of a Task object. Programmers have to override the run method and the getoutput method of Task objects. 9

10 package dcs.util; public abstract class BaseTask extends Thread { abstract public Object[] getoutput(); // Write output data Figure 7: BaseTask import dcs.util.*; public class MyTask extends BaseTask { public MyTask(Resource1 res1, Resource2 res2) { // constructor public void run() { // code segment for computations public Object[] getoutput() { // code segment for returning output data Figure 8: Sample code of a Task object In essence, Task object is a thread executing in a process called Java virtual machine. The steps of initialization of Task object are described as below. First, Supervisor object within the same process has to download data and bytecode files of Resource objects that the Task object needs. Second, after the construction of Resource objects, Supervisor object invokes the constructor of the Task object, and these Resource objects are input parameters. Finally, the Task objected is created, and the initialization is done. After initialization, Supervisor object needs to inform Administrator objects that the Task object is ready to run. Administrator object records the information and immediately notifies Supervisor object to start the Task object. The run method of the Task object in Figure 8 is invoked to perform computations. Upon termination of the Task object, Supervisor object will invoke a method defined in Task object to write output Resource objects. Programmers are bound to override this method, or data transmission may fail. Resource Objects Resource objects in our system act as input parameters of Task objects or the result of computations. While Task objects execute, Resource objects are transmitted between Task objects. It s the programmer s duty to write their Resource objects, or use objects provided by Java. Jaguar also provides a few data types commonly used in numerical analysis, including vector, matrix, and so on. Besides, classes of Resource objects must implement the interface java.io.serializable to enable serializability. Without serializability, the Supervisor object cannot automatically restore the state of a Resource object. Object-oriented programming languages provide a mechanism for initializing an object immediately when the object is allocated. In Java, the method of an object with the purpose of initialization is called a constructor. This framework stipulates that users are liable to 10

11 write constructors for their Task objects, and the parameters of the constructor are Resource objects. In addition, users have to specify the Resource objects that a Task objects needed in the script file. In this way, the distributed environment is competent to send Resource objects to corresponding Task objects, and retrieve Resource objects from Task objects after execution. public class MyResource implements java.io.serializable { public MyResource() { // default constructor Figure 9: Sample code of a Resource Object Data transmission of a Resource object contains two kinds of data: one is the bytecode file of the Resource object; the other is a serialized data file recording the content of the Resource object. In our design, a Resource object is also a class, but the state of the object cannot be recorded in the bytecode file. Therefore, an additional file is needed for maintaining the content. After acquiring required files, Supervisor objects restore the state of Resource objects using the mechanism of object serialization. 3. Conclusion We have proposed a distributed computing framework, Jaguar, which is based on the Java technology. The Jaguar framework utilizes basic concepts of object-oriented programming for future maintenance and extension. The implementation of Jaguar takes advantages of Java standard APIs and mechanisms, such as socket programming, object serialization, threading, and reflection. In this way, Jaguar is portable across different OS platforms. Jaguar provides an Administrator object and Supervisor objects as built-in auxiliary components to assist the executions and coordination of Task objects designed by programmers. We have successfully implemented Administrator and Supervisor classes that effectively help Task objects to perform computations. Also, we have implemented useful Resource objects for programmers to shorten the duration of developing their own classes of computing parameters. In consideration of efficiency, the thread mechanism is broadly utilized to reduce the overhead incurred by spawning new processes. In addition, using threads achieves concurrent executions of distributed objects. References [1] P. Launay and J. Pazat. Generation of Distributed Parallel Java Programs. INRIA, [2] Sun Microsystems. Java Remote Method Invocation Specification, Revision 1.50, JDK 1.2. Sun Microsystems, [3] A. J. Ferrari. JPVM: Network Parallel Computing in Java. Technical Report. Department of Computer Science, University of Virginia, [4] A. Geist, A Beguelin, etc. PVM: Parallel Virtual Machine A Users Guide and Tutorial for Networked Parallel Computing. MIT Press, [5] N. Nisan, S. London, O. Regev, and N. Camiel. Globally Distributed Computations over the Internet The POPCORN Project. In Proceedings of the 18 th International Conference on Distributed Computing Systems, pages , [6] L. Yan and C. Chen. JAM: High Performance Internet Computing with Massive Java Applets. In Proceedings of the 19 th IEEE International Conference on Distributed Computing Systems Workshops on Electronic Commerce and Web-based Applications/Middleware, pages 3-8, [7] J. Meyer and T. Downing. Java Virtual Machine. O Reilly,