9.0 Legion core objects
The Legion core object model specifies the composition and functionality of Legion's core objects. These objects create, locate, manage, and remove objects in the Legion system. Legion provides implementations of core objects but you are not obligated to use them.
Although the object model includes and relies on a few single logical Legion objects, access to these objects is limited because of heavy caching and hierarchical organization of lower level objects. Objects can be replicated to reduce any contention. Increasing the number of Legion computing resources will not increase competition for the few "centralized" Legion objects.
In this object model, each Legion object belongs to a class and each class is itself a Legion object. All Legion objects export a common set of object-mandatory member functions, such as save_state() and restore_state(). Class objects export an additional set of class-mandatory member functions, such as create(), derive(), and inherit_from(). The object model's power comes from the Legion classes. Much of what is usually considered system-level responsibility is delegated to user-level class objects. Legion classes are responsible for creating and locating their instances and subclasses, and for selecting appropriate security and object placement policies. Core Legion objects provide mechanisms for user-level classes to implement policies and algorithms that they choose. Assuming that we define the operations on core objects appropriately (i.e., that they are the right set of primitive operations to enable a wide enough range of policies to be implemented), this philosophy effectively eliminates the danger of imposing inappropriate policy decisions and opens up a much wider range of possibilities for the applications developer.
9.1 Core objects classes
There are six core objects
From these, the core class types--hosts, vaults, and binding agents--are derived. The core classes set the minimal interface that the core objects export. Every core object is an instance of a class that is itself eventually derived from one of the core object classes.
- LegionClass: The LegionClass object is the common unit of the Legion system. The core LegionClass provides the fundamental characteristics and object-mandatory functions of all Legion objects. There is only one LegionClass object in a system.
- LegionBindingAgent: Binding agents are Legion objects that map an object's LOID to its LOA (Legion Object Address). A <LOID, LOA> pair is called a binding. Binding agents cache bindings and organize themselves in hierarchies and software combining trees in order to implement the binding mechanism in a scalable and efficient manner.
- LegionContextObject: Context objects map context names to LOIDs, allowing users to assign arbitrary high-level string names to Legion objects. These objects also enable multiple disjoint name spaces to exist within Legion. All objects have a current context and a root context, which define parts of the name space in which context names are evaluated.
- LegionHostObject: Host objects represent processors. One or more host objects run on each computing resource which is included in Legion. Host objects create and manage processes for active Legion objects on their hosts. Classes invoke the member functions on host objects in order to activate instances (see section 12.5.3 in the Developer Manual). Representing computing resources with Legion objects abstracts the heterogeneity which results from different operating systems using different mechanisms for creating processes. Further, it provides resource owners with the ability to manage and control their resources as they see fit.
- LegionVaultObject: Just as a host object represents computing resources and maintains active Legion objects, a vault object represents persistent storage, but only for the purpose of maintaining the state, in OPRs, of the inert Legion objects that the vault object supports.
- LegionImplementationObject: Implementation objects allow other Legion objects to run as processes in the system. An implementation object typically contains machine code that is executed when a request to create or activate an object is made. More specifically, an implementation object is generally maintained as an executable file that a host object can execute when it receives a request to activate or create an object. An implementation object (or the name of an implementation object) is transferred from a class object to a host object to enable the host to create processes with the appropriate characteristics.
For more information on the Legion core objects, please see page 145 in the Developer Manual.