Installation Lifecycle

During this phase all requirements specified by the composite are matched to resources within the fabric. Specifically this means:

• walking through the list of SCA includes specified in the composite and applying them to the current composite (this may be recursive)

• walking through the list of OSGi bundles that are specified via bundle imports and exports with a preference to bundles already installed in the current Newton instance

• adding any implied OSGi bundle dependencies (e.g. spring libraries for <implementation.spring>)

Note any one of these phases may fail due to lack of resources at runtime, however if this stage completes successfully installation passes onto the download phase.

This phase significantly eases the work of system administrators when trying to figure out the list of bundles that are needed to support a given application as Newton handles this automatically without operator intervention.

Having resolved the list of bundles that need installation any that are not currently downloaded are pulled from CDS.

Once all resources have been downloaded Newton uses a pluggable set of RuntimeActivationGuards to decide whether or not a composite should be activated. Guards can delay activation till external criteria are met.

Once all resources have been resolved, downloaded and the composite has been validated, Newton starts to construct the composite. This happens in the following order:

1. Implementation objects are instantiated via their implicit construction mechanism

2. Reference bindings are built and wired into the implementation

3. Service bindings are built, wired to their respective implementations.

4. Lifecycle callbacks are made to the component implementations.

During this phase Newton monitors the references required by the composite and informs it of changes to services supplying those references. If all references requirements are met then Newton publishes the Service interface such that it can be consumed by other references.

Periodically Newton will recheck the set of RuntimeActivationGuards installed in the Newton process and may deactivate the composite if a guard specifies that the composite should no longer be running.

The composite is removed from the Newton runtime, services are shutdown, references released and implementations destroyed. In this state the OSGi bundles downloaded to support a given composite install are still available on the local machine. OSGi bundles are only removed when all referencing composites have been uninstalled. This process is managed via a garbage collection scheme.

It is possible for more than one composite to make use of code from a given bundle, therefore though it is valid to install a bundle when a composite is installed it may not be valid to uninstall it when the same composite is uninstalled, due to it being in use by another composite.

Newton uses a reachability graph scheme similar to that found in the Java virtual machine to decide when a bundle may be safely finally removed frpm the runtime environment. This happens seamlessly and without the need for administrator intervention.