Tuscany Java Runtime Overview

Introduction

This document is intended to provide a high level view of the Tuscany Java Runtime. At the most general level, the Tuscany Java Runtime is organized into a series of artifacts which can be loosely defined as units of management. Runtime artifacts can vary from the bootrap container, component containers to application components. Runtime artifacts are managed by implementations of o.a.t.core.context.Context. which, at a minimium, control their lifecycle state . The most prevalent type of context is o.a.t.core.InstanceContext, which manages instances of a runtime artifact. There are several types of instance context:

The relationship between contexts is described in the following diagram:

context.uml

Configuration

Runtime artifacts are defined by configuration artifact. The set of configuration artifacts and their inter-relations are described by a Logical Configuration Model (LCM) located in o.a.t.model.assembly. The LCM is an in-memory representation of configuration information derviced from some external source (e.g. XML, programmatically, etc.). The runtime uses an LCM to generate the appropriate context objects. For example, a SimpleComponentContext is generated from a Component, an AggregateContext from a ModuleComponent, etc. This is done through a multistep configuration process described further on.

The Runtime Bootstrap

Contexts are assembled in hierarchical fashion, starting with the RuntimeContext:

context.uml

A host environment is responsible for bootstrapping the runtime, providing "core" capabilities such as classloader semantics, and loading configuration artifacts. For example, a host runtime will typically boostrap the runtime according to the following steps:

  1. Instantiate a runtime context (the default implementation is o.a.t.core.system.context.RuntimeContextImpl) with a collection of boostrap runtime configuration builders (.cf the description of configuration processing), and an implementation of o.a.t.common.monitor.MonitorFactory for logging. This context serves as the runtime bootstrap.
  2. Load system module components and register them with the runtime context. System module components contain system components that provide core runtime functionality such as support for the SCA Java Client and Implementation model, transport bindings, configuration builders, and data binding.
  3. Recursively load susbsystems, module components and other artifacts, registering them with the runtime context as parts of an LCM. The runtime context will modify or complete the LCM during this registration phase. Note that additional components and other artifacts may be registered dynamically after the runtime has been brought online.
  4. Bring the runtime online.

This design allows the Tuscany runtime to be hosted on a variety of technology platforms such as J2SE, a Servlet engine, a J2EE container, or an OSGi container.

Registering and Building Configuration

A configuration is registered with its parent context which is always an AggregateContext. For example, a SimpleComponent is registered with its parrent AggregateContext. Similarly, an AggregateContext is registered with its parent context which will be another AggregateContext. All registered aggregates form a hierarchy descending either from the root or system aggregate contexts (whose parent is the runtime context). When a component configuration is registered with its parent context, the configuration is passed up the hierarchy for completion. At this point, a second pass termed the build phase is made over the configuration and it is decorated with factories that create Context instances (the specifics of this process are detailed in a separate document; in brief, however, a pass is made over the configuration by implementations of o.a.t.core.builder.RuntimeConfigurationBuilder, which are configured system components).

Runtime Configuration

The core Tuscany runtime is also built in the same manner as described above. In this case, the host environment registers system components with the system context (or one of its children). These system component configurations are processed and decorated by a series of bootstrap builders (c.f. o.a.t.core.system.builder). The system context is then started and appropriate child contexts are created from the decorated model. These contexts manage implementation instances which provide core runtime functionality. System entry points may be wired to external services in other modules, thereby providing a way to access system capabilities from other components.