This part gives implementation details of the assembly factory. While the assembly factory is responsible for building SCA component instances, it is itself implemented using the Fractal component model. Thank to the Fractal component model, the assembly factory is entirely configurable. For instance, this allows to easily extend the instantiation process by adding support for new binding type, or activating / deactivating model validation according to application needs (performance vs correctness).
The assembly factory implementation can be decomposed in three different personalities : the core factory, the generate factory and the runtime factory.
First, the core factory is the main module which provides the ability to create SCA component instances. SCA components are generated at compile time. As a consequence, the core factory can only create component instances using SCA components previously generated and compiled with the Tinfi compiler. Second, the generate factory extends the core factory to allow to generate and compile SCA component implementation by using the Tinfi compiler. It does not perform component instantiation. Finally the runtime factory combine both the functionalities offered by the core and the generate factory to allow user to generate and immediately instantiate SCA components from a Java archive. Although most of the SCA users will prefer simplicity and use the FraSCAti runtime platform; Advanced FraSCAti users should appreciate the possibility to avoid component code generation at runtime (using the generate factory to compile the SCA application) which consumes more system resources.
In this part, we will briefly discuss on differences between assembly factory personalities. Then we will detail the runtime assembly factory, more precisely the internal components responsible for managing the assembly factory and creating SCA composite instances. Finally we deal with the possible extension of the assembly factory in order to allow processing of SCA composite file with new implementation or binding type.
a) Core, Generate and Runtime personalities
As already mention, the assembly factory is decoupled in three distinct personalities : the core factory, the generate factory and the runtime factory. The core assembly factory personality is the main module which allows to create component instance while the generate factory is responsible for generating SCA Java components implementation. Additionally the runtime factory combines generation and instantiation in order to ease assembly factory usage.
The main difference between those personalities is the implementation of the component responsible for invoking the kernel. When the assembly factory creates component instance (core factory), the runtime component invokes Tinfi runtime kernel; When the assembly factory generates component implementation (generate factory), the runtime component invokes the Tinfi compiler. At runtime, both Tinfi compiler and runtime kernel are invoked.
The Tinfi component compiler needs to be initialized with some parameters, For instance, source and target directories. Thus, the assembly factory for component generation provides an initialization interface in addition to the component build interface given by the core factory.
In practice, the three personalities of the assembly factory are described by three different (but similar) Fractal component definitions. The assembly factory provides a single entry point which allows to get an instance of a particular personality (choosing the appropriate architecture to instantiate).
In the following part, we give details on internal process and components of the assembly factory, given in the figure 40. We will focus on the runtime personality.
b) Manager Component
The manager component is a front-end for the assembly factory. It provides the assembly factory main entry point which allows to load SCA applications from SCA composite definition. The manager is also responsible for driving assembly factory internal components.
When the assembly factory is requested for loading an SCA composite (see figure 47), the manager component calls the composite file parser to create an SCA model instance (using the composite definition). Since part of the SCA component definition can be defined in components implementation, the resulting model may be incomplete. For instance, SCA components implemented in Java can use annotations to describe service interfaces, references, properties, etc. In such case, the parser component calls the component responsible for completing the model with data defined by the implementation. This completion component currently supports introspection of SCA components implemented in Java (using the reflection API).
Once the composite description has been parsed and the composite model instance completed, the manager can use the model instance to instantiate the SCA composite. The manager invokes the instantiation component responsible for interpreting the SCA model and using the Tinfi kernel for creating SCA components instances. We give details of the assembly factory sub components in the next sections.
c) Parser component
The parser component of the assembly factory is mainly responsible for loading the composite definition. This component is based on the SCA model provided by the STP SCA project from the Eclipse development platform. The parser component first uses the SCA xml parser provided by STP to create an instance of the composite definition. The resulting model instance allows us to navigate easily through composite definition, however as already discussed, part of the model description can be directly defined in components implementation. Thus, the parser component has a sub component dedicated for resolving data from component implementation. Actually the resolver component supports introspection for SCA components implemented with Java. The resolve method helps in retrieving the Java interfaces for component services and component references and link components according to the target and promote attributes. Once the composite model has been resolved it is validated using the method provided by the EMF framework, this ensures that the composite model given to the instantiation process conform to the SCA specification.
d) Instantiation Component
The instantiation component is responsible for interpreting SCA composite model instances into invocations of the Tinfi kernel and the binding factory. The instantiation component is composed by seven sub components responsible for processing different parts of the SCA composite model (see figure 48). The Assembly and Component components respectively process SCA composites and SCA components according to the SCA composite model instance. For each component defined in the model instance, the component builder set components interfaces, sets the component implementation, intents, properties and creates bindings on SCA services and references.
The instantiation component is implemented according to specification of the “SCA Component Instantiation” described in section 8.1.3