MIT Project Oxygen Software Technologies

Software systems adapt—to users, to the environment, to change, to failure—with minimal user intervention and without interruption to the services they provide. Computations follow (or appear to follow) users as they move about freely. Perceptual interfaces and knowledge access systems adapt to their user's idiosyncrasies. Networks adapt to changing configurations of participating devices. Devices adapt communication protocols to those of nearby devices, to user and application requirements, and to environmental conditions. Software systems themselves adapt when things go wrong, diagnosing and responding to problems by taking an alternative approach, rolling back to a consistent state, or taking another corrective action.

Conversely, software systems are adaptable. They can be customized easily to meet individual user needs and to take advantage of newly published software. They accommodate requests for upgrades and repairs, whether user-supplied or system-generated, to

  • bring applications just-in-time to handheld devices,
  • automatically install and upgrade software on personal machines,
  • maintain databases (e.g., for computer-aided design systems) across software upgrades, or
  • update networks of distributed embedded devices that lack individual user interfaces.

Project Oxygen's software architecture provides mechanisms for

  • building applications using composable, distributed components,
  • customizing, adapting, and altering component behavior,
  • replacing components, at different degrees of granularity, in a consistent fashion,
  • person-centric, rather than device-centric, security, and
  • disconnected operation and nomadic code.
Oxygen's software architecture relies heavily on abstraction to support change through adaptation and customization, on specification to support components that use these abstractions, and on persistent object stores with transactional semantics to provide operational support for change.

Computations are modular, as is storage. Abstractions characterize components that carry out computations and objects used in computations. In Oxygen, abstractions support the use of adaptable components and objects by providing

  • application access to components traditionally hidden beneath intervening layers of software, so as to observe and influence their behavior,
  • intent-based interfaces, not just syntax or address-based interfaces, so as to facilitate component and object use, adjustment, replacement, and upgrade,
  • stream-oriented interfaces that treat speech, vision, and sensor data as first-class objects, so as to enable compilers to manage low-level pipelining concurrency and multithreaded programs to adjust their behavior correctly at runtime in response to changes in the number of streams or the interactions among them,
  • constraint and event abstractions, which separate computation from control, trigger what is processed when, and provide flexibility for modifying behavior at runtime without compromising system integrity,
  • cutpoints, so as to provide safe fallbacks and to enable "eternal computation".

Specifications make abstractions explicit, exposing features to other system components. In Oxygen, specifications support adaptation and change by providing information about

  • system configurations, to determine what modules and capabilities are available locally,
  • module repositories, to provide code over the network for installation on handheld and other devices,
  • module dependencies, to support complete and consistent installations or upgrades,
  • module capabilities, to support other components and applications in scripting their use, and
  • module behavior, to support their safe use through a combination of static and runtime checks.

Persistent object store with transactional semantics
Code, data objects, and specifications reside in a common object-oriented store, which supports all Oxygen technologies (i.e., user, perceptual, system, and device technologies). Object-orientation helps maintain the integrity of the store by restricting updates to those performed by methods in the store. The store has transactional semantics, which enables concurrent access, rollback and recovery, and consistent updates to modules and data. It also operates efficiently, using techniques such as optimistic concurrency, pre-fetching, and lazy updates and garbage collection, which defer the costs of modifying the store as long as possible or until there is time to spare.

Oxygen Today

Software infrastructures
Pebbles are platform-independent software components, capable of being assembled dynamically by the GOALS planning mechanism in response to evolving system requirements. Each Pebble's description contains a mix of formal interface specifications (method signatures, etc.), informal descriptions (of the sort found in user manuals), and arbitrary other potentially useful information, including code for test cases and demonstrations. (Chris Terman, Steve Ward, Computer Architecture Group)

MetaGlue provides computational glue for large groups of software agents, such as those used in the Intelligent Room. MetaGlue clearly separates software that acts on behalf of users from software controlling spaces, provides wide-scale communication and discovery services, enables users to interact (subject to access control) with software and data from any space, and arbitrates among applications competing for resources. MetaGlue is implemented in Java, replacing the remote method invocation (RMI) mechanism with one that allows dynamic reconnection so that agents can invisibly resume previously established, but broken connections. (Howard Shrobe, Project AIRE)

CORE is a communication-oriented routing environment for pervasive computing. It structures an application as a graph of interconnected components along with a set of event-based rules. CORE supports application debugging by making all actions reversible, thereby enabling developers to test new agents or devices until something goes wrong, and then to rewind the system so as to observe the events leading up to the failure. (Larry Rudolph, Oxygen Research Group)

Click routerClick is an architecture for constructing network routers using software running on standard PC hardware. Click routers can perform a wide variety of complex tasks efficiently, including network address translation, encryption, filtering, and traffic prioritization. Conventional routers built from special-purposed hardware are not easily adaptable to these tasks. Click improves on other software routers by making it easy to configure and control packet-forwarding paths. (M. Frans Kaashoek, Robert Morris, Parallel and Distributed Operating Systems)

Persistent storage and software updates
SUDS (Software Upgrades in Distributed Systems) is a mechanism for automatically upgrading code for objects in a distributed object-oriented database (OODB) to correct software errors, improve performance, or support new features without disrupting service. Upgrades run just-in-time as transactions serialized with respect to all other (application and upgrade) transactions. SUDS is implemented using Thor, a large-scale distributed OODB that provides reliable and highly available persistent storage. (Barbara Liskov, Programming Methodology Group)

Abstraction and specification
IOA is a language and set of tools for developing reliable distributed systems. The language enables system designers to express designs at different levels of abstraction, starting with a high-level specification of required global behavior and ending with a low-level version that can be translated easily into code. IOA tools allow designers to simulate and reason about properties of designs at all levels of abstraction and about relationships between different levels. A code-generation tool, currently under development, will connect verified low-level designs to runnable, distributed code, thereby avoiding errors that often occur when manually transcribing designs into code. (Stephen Garland, Nancy Lynch, Theory of Distributed Systems)