Legion: A Worldwide Virtual Computer
Home General Documentation Software Testbeds Et Cetera Map/Search
  Legion Architecture
Legion's object-based system gives classes and metaclasses system-level responsiblity


Legion users will require a wide range of services in many different dimensions, including security, performance, and functionality. No single policy or static set of policies will satisfy every user, so, whenever possible, users must be able to decide what trade-offs are necessary and desirable. Several characteristics of the Legion architecture reflect and support this philosophy.

  • Everything is an object: The Legion system will consist of a variety of hardware and software resources, each of which will be represented by a Legion object, which is an active process that responds to member function invocations from other objects in the system. Legion defines the message format and high-level protocol for object interaction, but not the programming language or the communications protocol.

  • Classes manage their instances: Every Legion object is defined and managed by its class object, which is itself an active Legion object. Class objects are given system-level responsibility; classes create new instances, schedule them for execution, activate and deactivate them, and provide information about their current location to client objects that wish to communicate with them. In this sense, classes are managers and policy makers, not just definers of instances. Classes whose instances are themselves classes are called metaclasses.

  • Users can provide their own classes: Legion allows users to define and build their own class objects; therefore, Legion programmers can determine and even change the system-level mechanisms that support their objects. Legion 1.4 (and future Legion systems) contains default implementations of several useful types of classes and metaclasses. Users will not be forced to use these implementations, however, particularly if they do not meet the users' performance, security, or functionality requirements.

  • Core objects implement common services: Legion defines the interface and basic functionality of a set of core object types that support basic system services, such as naming and binding, and object creation, activation, deactivation, and deletion. Core Legion objects provide the mechanisms that classes use to implement policies appropriate for their instances. Examples of core objects include hosts, vaults, contexts, binding agents, and implementations.

The Model

Legion objects are independent, logically address-space-disjoint active objects that communicate with one another via non-blocking method calls that may be accepted in any order by the called object. Each method has a signature that describes the parameters and return value, if any, of the method. The complete set of method signatures for an object fully describes that object's interface, which is determined by its class. Legion class interfaces can be described in an interface description language (IDL), several of which will be supported by Legion.

Legion implements a three-level naming system. At the highest level, users refer to objects using human-readable strings, called context names. Context objects map context names to LOIDs (Legion object identifiers), which are location-independent identifiers that include an RSA public key. Since they are location independent, LOIDs by themselves are insufficient for communication; therefore, a LOID is mapped to an LOA (Legion object address) for communication. An LOA is a physical address (or set of addresses in the case of a replicated object) that contains sufficient information to allow other objects to communicate with the object (e.g., an <IP address, port number> pair).

Legion will contain too many objects to simultaneously represent all of them as active processes. Therefore, Legion requires a strategy for maintaining and managing the representations of these objects on persistent storage. A Legion object can be in one of two different states, active or inert. An inert object is represented by an OPR (object persistent representation), which is a set of associated bytes that exists in stable storage somewhere in the Legion system. The OPR contains state information that enables the object to move to an active state. An active object runs as a process that is ready to accept member function invocations; an active object's state is typically maintained in the address space of the process (although this is not strictly necessary).

Core objects

Several core object types implement the basic system-level mechanisms required by all Legion objects. Like classes and metaclasses, core objects are replaceable system components; users (and in some cases resource controllers) can select or implement appropriate core objects.

  • Host objects: Host objects represent processors in Legion. One or more host objects run on each computing resource that is included in Legion. Host objects create and manage processes for active Legion objects. Classes invoke the member functions on host objects in order to activate instances on the computing resources that the hosts represent. Representing computing resources with Legion objects abstracts the heterogeneity that results from different operating systems having different mechanisms for creating processes. Further, it provides resource owners with the ability to manage and control their resources as they see fit.

  • Vault objects: 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. Context objects: Context objects map context names to LOIDs, allowing users to name objects with arbitrary high-level string names, and enabling 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.

  • Binding agents: Binding agents are Legion objects that map LOIDs to LOAs. A <LOID, LOA> pair is called a binding. Binding agents can cache bindings and organize themselves in hierarchies and software combining trees, in order to implement the binding mechanism in a scalable and efficient manner.

  • Implementation objects: 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.


Legion specifies functionality and interfaces, not implementations. Legion 1.4 provides useful default implementations of class objects and of all the core system objects, but users are never required to use our implementations. In particular, users can select (or build their own) class objects, which are empowered by the object model to select or implement system-level services. This feature of the system enables object services (e.g. creation, scheduling, security) to be appropriate for the object types on which they operate, and eliminates Legion's dependence on a single implementation for its success.

Link Description
Overview A general look at Legion
Objectives and constraints Legion's design objectives and restrictions
Applications Adapting and running Legion applications
Architecture Legion system architecture
High-performance computing Using Legion to get high-performance computing
Scheduling Scheduling and resource management
Security Legion's security philosophy and model


[Home] [General] [Documentation] [Software]
[Testbeds] [Et Cetera] [Map/Search]

This work partially supported by DOE grant DE-FG02-96ER25290, Logicon (for the DoD HPCMOD/PET program) DAHC 94-96-C-0008, DOE D459000-16-3C, DARPA (GA) SC H607305A, NSF-NGS EIA-9974968, NSF-NPACI ASC-96-10920, and a grant from NASA-IPG.