diff options
| author | dims <dims@13f79535-47bb-0310-9956-ffa450edef68> | 2008-06-17 00:23:01 +0000 |
|---|---|---|
| committer | dims <dims@13f79535-47bb-0310-9956-ffa450edef68> | 2008-06-17 00:23:01 +0000 |
| commit | bdd0a41aed7edf21ec2a65cfa17a86af2ef8c48a (patch) | |
| tree | 38a92061c0793434c4be189f1d70c3458b6bc41d /sandbox/jim/docs/runtime_overview.html | |
Move Tuscany from Incubator to top level.
git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@668359 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'sandbox/jim/docs/runtime_overview.html')
| -rw-r--r-- | sandbox/jim/docs/runtime_overview.html | 86 |
1 files changed, 86 insertions, 0 deletions
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 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<title>Tuscany Java Runtime Overview</title>
</head>
<body>
<h1>Tuscany Java Runtime Overview</h1>
<h2>Introduction</h2>
<p>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 <i>o.a.t.core.context.Context</i>. which, at a minimium, + control their lifecycle state . The most prevalent type of context is + <i>o.a.t.core.InstanceContext</i>, which manages instances of a runtime artifact. + There are several types of instance context: </p> + <ul> + <li><i>SimpleComponentContext:</i> Manages implementation instances of a leaf + appplication component such as an SCA component, i.e. a component that has no + children. There is generally a 1:1 relationship between a simple context and a + component implementation instance.</li> + <li><i>AggregateContext:</i> Manages a context which contains child contexts such as an
SCA module component. Aggregates may contain SimpleComponentContexts,
EntryPointContexts and ExternalServiceContexts.</li>
<li><i>EntryPointContext:</i> Manages the public access point of a service offered by a + component or external service in a an aggregate context over a transport binding.</li> + <li><i>ExternalServiceContext:</i> Manages a local representation of a service external + to an aggregate context.</li> + <li><i>ScopeContext:</i> Manages a scope which defines the lifecycle and visibility of + component instances. SimpleComponentContexts, EntryPointContexts, External Services, + and AggregateComponentContexts are associated with a scope context. Further, + aggregate contexts contain scope contexts to manage the visibility of their + children.</li> + <li> + <i>RuntimeContext:</i>Manages a runtime instance. A runtime context is an aggregate + context that contains a root aggregate context and a system aggregate context.</li> + </ul> + <p>The relationship between contexts is described in the following diagram:</p> + <img alt="context.uml" src="overview/Slide1.png"/> + <h2>Configuration</h2> + <p>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.</p> + <h2>The Runtime Bootstrap</h2> + <p>Contexts are assembled in hierarchical fashion, starting with the RuntimeContext:</p> + <img alt="context.uml" src="overview/Slide2.png"/> + <p>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:</p> + <ol> + <li>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.</li> + <li>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.</li> + <li>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.</li> + <li>Bring the runtime online.</li> + </ol> + <p>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.</p> + <h2>Registering and Building Configuration</h2>
<p>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).</p> + <h3>Runtime Configuration</h3> + <p>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. </p> + </body> +</html> |