Documentation

Technical papers

Downloads

Latest Stable Release

Resources

An Introducton to The GNU Adaptable Multiplatform Object Routing Architecture

1 Introduction

1. Thread-of-execution based security

2. Remote administration and application visualization

3. Transparent distributed-application support

4. Thread management

5. Multi-application support

6. Convenient module abstraction 

Gamora is dual licensed under both the MPL and the GPL. The MPL license included in Gamora has been modified to allow GPL compatibility.

2 Philosophy

2.1 Buses and BusObjects

Gamora tries to provide an abstraction paradigm that is at once easy to conceptualize, easy to develop in, and readily adaptable to as many modular programing tasks as possible.

Gamora divides functionality into any number of buses. A bus is, like its hardware counterpart, a component that hosts other components (called BusObjects), and provides a meaningful way for the components to communicate to each other via message passing. Because buses themselves are BusObjects, they can be attached to other Buses to create a hierarchical structure.

This division of functionality provides a clear demarcation between components in an application. In servers, for example, each client connection is a BusObject, the connection daemon is another, while the server logic is its own BusObject (a BusController in fact, more later). In this manner, the daemon accepts and creates new client BusObjects, the server BusObject is informed of new clients, and each client, being its own thread, communicates with the server BusObject to perform a useful task.

2.2 BusControllers

Gamora's default implementation of Bus (you can create your own to suit you) provides a second classification of objects called BusControllers. BusControllers are BusObjects that are registered with a Bus to receive anonymous messages. Anonymous messages are those sent over a Bus with no intended destination. In such cases, the messages are given to all registered BusControllers. 

In the server example, the logic module would likely be a BusController, receiving the anonymous broadcasts of clients. Because the server BusObject receives not only the message but the originator of the message, it can use the receipt of a client message as the trigger of processing that message. The server-object need not care about how the client is communicating, nor keep track of all connected clients. That is done by Gamora's communications package (Waterworks) and the buses themselves.

2.3 Nodes

Simply separating the connections into BusObjects would not be enough to relieve the server of the duty of keeping track of them. Also, state must be associated with each connection. All Gamora state objects (connection objects, called Sinks, included), are called Nodes. A Node is simply a BusObject with methods allowing other BusObjects to set and retrieve state. When a server-object receives a message and the origin BusObject, it can retrieve state from the origin BusObject to differentiate it from other connections. At this point, truely all tedious server behavior is offloaded to Gamora.

3 Waterworks

1. The ability to chain stream-processing modules, much like Java's   streams, but with the advantages of hot-swapping and forking.

2. The ability to switch data sources and destinations at will without   disrupting the resources (switch from TCP/IP to diskfile and back   without closing either, for example).

3. The ability to provide sophisticated filter and logic modules, even   unrelated to the streams themselves (IdleDisconnect, for example,   disconnects a client after inactivity, while PasswordDBAuth provides   password authentication transparent to the application)

4. These modules, called Pipes, can disconnect themselves when finished,   or spawn new pipes, all without disrupting the flow of data.

Waterworks is composed of four major components, Sinks, Pipes, and Factories, and SinkBuilders. A Pipe is a communication element, either a filter or datasource. A Sink is the BusObject that holds and controls a set of input and output pipes (called the Waterworks). A Factory builds Sinks from a description of the wateworks, and a SinkBuilder repeatedly calls a Factory to build a Sink. 

Though complex by appearance, using Waterworks is frighteningly simple. One simply creates a SinkBuilder, specifying which Factory (SocketFactory, for example, constructs Sinks communicating via TCP/IP), and the layout of the pipes he or she wishes his Sinks to contain. Then he or she activates the SinkBuilder (as he/she would any other BusObject). One can create fantastically complex I/O systems in one or two lines of code.

As an example, one can create a SinkBuilder that will accept clients that speak to the server via serialized Java Objects, to which the server replies with NNTP responses (a nonsensical example, but bear with me) with this code fragment:

SocketFactory sf=new SocketFactory(coreController, 30500);

SinkBuilder builder=new SinkBuilder(coreController, sf, 

new Class[] {ObjectIn.class},  new Class[] {NNTPOut.class, TextOut.class});

4 Administration

5 Security

One can easily protect a resource from unauthorized use in two or three lines of code.

6 Thread management

Gamora can protect against 'greedy threads' that through either malicious intent or accidental crash would otherwise lock the entire JVM thread pool. By detecting such threads and beginning a process called 'thread-stirring', Gamora remains responsive for all affected BusObjects.

In addition, one can retrieve information on which threads are running, and which BusObjects created these threads, and if necessary, they can be killed.