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
- PubOA - public object agents , one for each machine in the
- 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)
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
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
OA destination. After a method has been executed, possible results are
to the associated ResultHandler via RMI.
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.
Figure: Consumer/producer interaction in JavaSymphony