<!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>