JavaSymphony Runtime System architecture

This page presents the design of the JavaSymphony Runtime System.
The JavaSymphony Runtime System (JRS) is implemented as an agent based system (see the figure below) that consists of several components:

JSShell - The JavaSymphony administration shell ,
NAS - The network agent system. It comprises network agents (NA), which run on every machine (PC/workstation, SMP node, supercomputer, multicore machine ), on which a JavaSymphony application may run.
OAS - The object agent system. It comprises two types of object agents:

PubOA - public object agents , one for each machine in the JS environment
AppOA - application object agents , one created for each JSApp when registered with the JRS.

EvAS - The event agent system. It comprises event agents (EvA), one for each machine to be used by the JSApps.

Figure: JavaSymphony Runtime System Architecture
Each machine to be used by JavaSymphony has a NA, a PubOA and an EvA running in the same JVM, while each JSApp runs in its own JVM instance, together with its associated AppOA.

JSShell - The JavaSymphony Administration Shell

    All physical computing resources (nodes) such as workstations, PCs, clusters or supercomputers, and multicore machines must have a JVM installed and must be configured under the JS-Shell (see the figure below), before they can be used by any JSApp. The JSShell then starts a NA on every configured node. The JSShell controls the NAs via the Java/RMI mechanism.

    The computing resources are monitored using the JSShell GUI. The runtime behaviour of the JSApps can be observed in the information window of a node. The remote objects of an application distributed on several nodes are listed in the same window and can be migrated to a remote node using this interface.

    For more details see the JavaSymphony User Guide and the paper "On the Implementation of JavaSymphony" in the paper section.

Figure: JSShell, an interface to control physical resources for JSApps

NAS - The Network Agent System

A NA is started by the JSShell or independently by a user on every computing node to be used by JSApps. A NA starts an associated PubOA and an associated EvA within the same JVM. Its main objective is to monitor the resources of the corresponding machine (e.g. dynamic parameters as system load, free memory or static parameters as operating system, machine name, Java version). In the same time, the NA monitors the constraints used for creation of VAs, or for creation or migration of JS objects, and chooses the machines that will be part of the VAs built in a JSApp. The set of all NAs defines the Network Agent System (NAS).

At the level of the NAS, the computing nodes are organized in a level-i (i >= 2) tree structure, similar to a JavaSymphony VA, which we call physical architecture (PA). A level-3 PA represents a cluster and consists of a set of nodes (level-2 PA). A level-4 PA represents a cluster of clusters, etc. A PA manager, which is a node as well, controls the nodes in a PA. In addition to the management tasks, a PA manager can also be used as a computing node for JSApps. See the left side of JSShell figure, which shows a complex PA.

The VAs are used by JS application to map their nodes (level-2 VAs) onto the nodes in a PA. Higher-level VAs do not correspond to the nodes in a PA.

OAS - Object Agent System

    The OAS directly interacts with JS application by managing both remote ans shared meory objects which include: creation, mapping, migration, load balancing, and deletion of objects. Furthermore, the OAS is responsible for remote method invocations (parameter transfer, remote execution,and returning results to the calling site).

    Any NA creates a public object agent (PubOA) within the same JVM. For every JS application, a unique application object agent (AppOA) is generated once the JS application registers with the JRS. A JS application uses the same JVM as its associated AppOA. PubOAs and NAs on the one hand, and AppOAs and JSApps on the other hand interact by local (direct) method invocation.
The RMI mechanism are used for communication between AppOA and PubOA on the same node or on different nodes. The AppOA manages a list of all objects generated by its corresponding JSApp.

    When a JS application requests a VA from the JRS, the associated AppOA forwards this request to the PubOA. The VAManager, as part of the PubOA, manages (creates, modifies, and releases) all VAs that have been asked by any JS application on the node where the PubOA resides.

    A job processing mechanism (see the figure below) is used to implement any type of remote and local interaction between OAs. A job may create a JS or SJS object, invoke a method, download a codebase, migrate objects, lock/unlock objects or VAs, etc.

    Each PubOA and AppOA creates a set of threads called JobHandlers, which process every job submitted remotely using RMI, or locally through direct method invocation. The number of JobHandler threads is controlled via the JSShell. For single-threaded JS objects, a new and dedicated JobHandler thread is created, whereas for multi-threaded objects (default case), several threads can be employed to simultaneously process jobs.

    The shared memory jobs are processed by a local OA, while the remote memory jobs are distributed and processed by remote OAs. An OA has a multi-threaded job queue which contains all jobs related to the multi-threaded JS or SJS objects. A multi-threaded job queue is associated with n job processing threads called Job Handlers. Each single-threaded JS or SJS object has a single-threaded job queue and an associated job handler. The results returned by the shared and remote memory jobs are accessed using ResultHandle objects, which can be either local object references in case of SJS objects, or remote object references in case of distributed JS objects.

    The job mechanism is exemplified for the method invocation in the figure below. For every method invocation in a JS application which implies local or remote OA processing, a MethodInvocator (part of OA) creates a job. If this job implies receiving of results, a ResultHandle is created and attached to the job. The OAs and ResultHandleare the remote objects for the Java RMI mechanism, whereas jobs are serializable objects to be passed as parameters of remote method invocations of OAs. These result handlers represent local object refrences in case of shared memory application (SJSObjects). Depending on whether jobs cause method invocations of multi-threaded or single-threaded objects, they are placed in corresponding queues at the OA destination. After a method has been executed, possible results are transmitted to the associated ResultHandler via RMI.

OAS

Figure: Job processing mechanism in JavaSymphony

EvAS - Event Agent System

The Event Agent System (EvAS) consists of the event agents (EvA) which run on each machine used by JS applications. On each of these machines, the NA starts an associated EvA. An EvA directly interacts with the local PubOA to register user-defined events, middleware events, and system events consumers or to produce user-defined events (see Events in the language section). The EvA also interacts directly with the local NA to produce system events. The middleware events are configured/selected using the JSShell and are automatically produced by JS classes .

The interaction between consumers and producers is realized via the EvAS (see figure below).

To register for an event, a consumer (any object in JSApp) contacts the local EvA and provides information about the event it wants to receive (e.g. event type, filter for producers, constrains for system events, method to handle the event, etc.). The EvA analyses the filter associated with the event consumer, determines the list of possible producers and distributes (remotely) the request to the corresponding EvAs. Each of them manages a list of registered consumers.
To produce an event, a producer (any object in JSApp for user events, JS classes for middleware events or a NA for system events) contacts the local EvA and provides information for the event (e.g. event type, a filter for the destinations, etc.). The EvA analyses the filter and the type associated with the event to find the list of possible consumers and (remotely) notifies the corresponding EvAs about the occurrence of the event. The EvA at the consumer's location contacts the consumer by (locally) invoking its event handling method.

There is no direct connection between the producer(s) and consumer(s). Local interaction among EvAs and consumers, respectively producers, is done via local method calls. The RMI mechanism is used for remote interactions.

Producer/Consumer interaction in JavaSymphony

Producer/Consumer interaction in JavaSymphony

Figure: Consumer/producer interaction in JavaSymphony