From bdd0a41aed7edf21ec2a65cfa17a86af2ef8c48a Mon Sep 17 00:00:00 2001 From: dims Date: Tue, 17 Jun 2008 00:23:01 +0000 Subject: Move Tuscany from Incubator to top level. git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@668359 13f79535-47bb-0310-9956-ffa450edef68 --- sandbox/jim/docs/runtime_overview.html | 86 ++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 sandbox/jim/docs/runtime_overview.html (limited to 'sandbox/jim/docs/runtime_overview.html') diff --git a/sandbox/jim/docs/runtime_overview.html b/sandbox/jim/docs/runtime_overview.html new file mode 100644 index 0000000000..5d9af90eb1 --- /dev/null +++ b/sandbox/jim/docs/runtime_overview.html @@ -0,0 +1,86 @@ + Tuscany Java Runtime Overview

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. +
  3. 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.
  4. +
  5. 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.
  6. +
  7. Bring the runtime online.
  8. +
+

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.

+ + -- cgit v1.2.3