An Overview of the Oplet Runtime Environment

This page gives a quick high-level "executive" summary of the Oplet Runtime Environment (ORE) and some of its most important features. More details can be found elsewhere in this document.

The ORE is a software platform for deploying services on network elements (NE) such as routers, switches, and hosts. Some important design goals for the ORE are:

• Enable code to be dynamically downloaded to the NE;
• Portable to many different kinds of NE;
• Robust, reliable and secure;
• Manage resource allocation for competing services;
• Protect services from each other;
• Open;
• Low performance impact on the NE;
• Provide a framework to structure code.

The ORE is primarily implemented in Java, although there is a small amount of native code to provide access to low-level platform-specific features. All dynamically deployed code is written in Java.

The ORE itself consists of two parts: a kernel that manages the interactions between dynamically downloaded components; and a small set of standard components. Both these standard components and other user-provided components are called oplets, and they contain the network services that are to be executed on the NE. More information about oplets is given below.

In a typical scenario the NE will initialize and start the Java Virtual Machine (JVM). The ORE kernel is launched and begins its own booting process. This involves contacting another server on the network and downloading the oplets that are needed to begin normal operation. The oplets are located by referring to them with a URL, so the server will often be a standard HTTP server.

The standard oplets include:

• A boot oplet that determines which other oplets should be started up.
• A logger oplet that serves as a central controller of log messages for other oplets. This is similar to the Unix syslog facility.
• A simple command line shell. This provides a basic interim mechanism for telneting to the ORE running on the NE and directly administrating it. The shell itself has no built-in commands. These are provided in a companion oplet. The commands are extensible, so that user-defined oplets can provide their own commands.
• A basic HTTP server with support for servlets. Oplets can provide HTML pages and servlets that can be accessed through this server. This oplet is based on code from a freely available HTTP server written at Acme. Future releases might replace this oplet with another similar one.
• A variant logger oplet that provides an interface more convenient for the HTTP service. This functionality will probably be moved into the basic logger.
• An oplet containing a collection of servlets that provide information about the current state of the ORE via the HTTP service.

This list of standard oplets will be extended as the ORE matures.

The primary purpose of the ORE is to provide mechanisms that enable new services to be added to an NE. It is these services that add new functionality and value to the NE, not the ORE itself. The ORE makes few assumptions about what a service can do, and places very few requirements on the implementation of the service.

Services are packaged into deployment units called oplets. Each oplet can contain multiple services. When an oplet is started it will typically start some or all of the services that it is providing.

Services are encouraged to make use of fellow services that are running in the ORE. This decomposition of functionality into distinct services has the following benefits:

• Code reuse
• Independent development tracks for services
• More maintainable
• More robust

The ORE provides a registry so that services can locate one another. When a service is started it is added to a registry, and when it is stopped it is removed from the registry. When an oplet provides a service that uses another service, a dependency exists between the oplet and the other service. The ORE manages these dependencies and ensures that they are satisfied. If its dependencies cannot be satisfied, the oplet cannot be started. If a running oplet depends on a service that is stopped, the oplet must also be stopped. More information on dependencies can be found in the detailed oplet page.

Oplets are packaged as standard Java JAR files. The JAR manifest contains signature information that is used to authenticate the oplet and verify its integrity as part of the ORE's security mechanism. Additional ORE-specific information is placed in the JAR manifest to represent meta-data such as the dependencies the oplet has, and declarations for the services that it provides.