Java SCA Architecture Guide

Overview"> Overview

The SCA Java runtime is composed of core and extensions. The core is essentially a multi-VM wiring engine that connects components together using the principles of Dependency Injection, or Inversion of Control.

Core

The Core is designed to be simple and limited in its capabilities. It wires functional units together and provides SPIs that extensions can interact with. Capabilities such as service discovery, reliability, support for transport protocols, etc. are provided through extensions.

Extension

Extensions enhance SCA runtime functionality. Extension types are not fixed and core is designed to be as flexible as possible by providing an open-ended extension model. However, there are a number of known extension types defined including:

• Component implementation types, e.g. Spring, Groovy, and JavaScript
• Binding types, e.g. Axis, CXF, AMQP, ActiveMQ, JXTA
• DataBinding types, e.g. JAXB, SDO, XmlBeans
• Interface Binding types, e.g. WSDL, Java

Details of how to implement an extension can be can be found in the [Extensions Guide].

Runtime

The core is designed to be embedded in, or provisioned to, a number of different host environments. For example, the core may be provisioned to an OSGi container, a standalone runtime, a servlet engine, or J2EE application server. Runtime capabilities may vary based on the host environment.

High level overview of Java SCA runtime

The diagram shown below is a high level view of the SCA runtime which consists of the following key modules/packages:

1. SCA Spec API: The APIs defined by the SCA Java Client and Implementation Spec
2. API: Tuscany APIs which extend the SCA spec APIs
3. Core: The runtime implementation and the SPIs to extend it
4. Extensions:
   1. Container implementation - For extending language support, for example BPEL, Python, C++, Ruby,..
   2. Binding - for extending protocol support, for example Axis2, CXF,..
   3. Interface Binding - for service definition, for example WSDL, Java, ...
   4. Databinding - for extending data support, for example SDO, JAXB, ...
5. Host Platforms: The environments that host the Tuscany runtime.

Internals High Level View">Internals High Level View

[Note: Do we want to link to Kernel-Structure]?

Bootsrap">Bootsrap

Bootstrap process is controlled by Host environment. The default process is implemented in DefaultBootstrapper.
The runtime processes service assemblies serialized using SCA Assmebly XML which can take other forms.

• The load phase processes SCDL and creates an in-memory model and produces corresponding runtime artifacts (e.g. components, services, references)
• The connect/wire phase wires references to services

Metadata">Metadata

Contribution">Contribution

Binding Extension">Binding Extension

Component Implementation Extension">Component Implementation Extension

Data Binding Extension">Data Binding Extension

Wiring">Wiring

[This section needs to be updated]
To understand how wiring works, we need to detail how Components function in the system. Let's start with Atomic Components and then discuss Composite Components.

Atomic Component

AtomicComponent is the most basic component form. It corresponds to the spec concept which offers services, has references and properties

• Implementation types e.g. Java, XSLT, etc.
• Are wired
• Have properties

Atomic Components have implementation instances. Instances are associated with a scope: e.g. request, conversation, composite. A SCDL entry is used to define a Component.

Atomic components use a ScopeContainer to manage implementation instances:

• Composite, HTTP Session, Request, Stateless
• ScopeContainers track implementation instances by scope id and the AtomicComponent instance identity
• Instances are stored in an InstanceWrapper which is specific to the component implementation type (e.g. PojoInstanceWrapper.java)

Component Wiring

Component references are connected to services through wires

• Two sides
  • InboundWire - handles the source side of a wire, including policy
  • OutboundWire - handles the target side of a wire, including policy
• The runtime connects inbound and outbound wires, performing optimizations if possible
  • Inbound and outbound wires may be associated with different service contracts
  • Different implementation types
  • "Standard" wires contain invocation chains that have Interceptors that perform some form of mediation (e.g. policy)
  • Other wire types exist that, for example, do not perform mediations

Invocation Chains

A wire has an InvocationChain per service operation. An InvocationChain may have interceptors - "around-style" mediation. Component implementation instances access a wire through a WireInvocationHandler associated with a reference.

• WireInvocationHandlers may (or may not depending on the component type) be fronted by a proxy
• WireInvocationHandlers dispatch an invocation to the correct chain
  A wire has a TargetInvoker that is created from the target side AtomicComponent or Reference and is stored on the source wire invocation handler. The TargetInvoker is resposnible for dispatching the request to the target instance when the message hits the end of the target invocation chain.

Invocation Overview

• An invocation is dispatched to the WireInvocationHandler
• The WireInvocationHandler looks up the correct InvocationChain
• It then creates a message, sets the payload, sets the TargetInvoker, and passes the message down the chain
• When the message reaches the end of the chain, the TargetInvoker is called, which in turn is responsible for dispatching to the target
• Having the TargetInvoker stored on the outbound side allows it to cache the target instance when the wire source has a scope of equal or lesser value than the target (e.g. request-->composite

The runtime provides components with InboundWires and OutboundWires. InvocationChains are held in component wires and are therefore stateless which allows for dynamic behavior such as introduction of new interceptors or re-wiring.

Loading SCA assemblies">Loading SCA assemblies

Artifact Processor

[add info about what this is: Luciano\?]

Loading Java SCA

SCA service assemblies are deployed to the SCA domain in the format of SCDL files. Tuscany runtime artifact processor loads the SCDLs into model objects which are a set of java beans to hold the metadata.

There are two types of loaders:

• StAXElementLoader: Load the XML element from the StAX events
• ComponentTypeLoader: Load the Component Type for an implementation either by introspection or paring a side file

Loading Component Type

Loads the component type definition for a specific implementation

• How it does this is implementation-specific
• May load XML sidefile (location set by implementation)
• May introspect an implementation artifact (e.g. Java annotations)
• ... or anything else

Loading Composite ComponentType Loader

• Load SCDL from supplied URL
• Extract and load SCDL from composite package

POJO ComponentType Loader

• Introspect Java annotations
• Uses a pluggable "annotation processing" framework to introspect Java classes

Class diagram for the runtime artifacts

Spring Integration">Spring Integration