Purpose and Scope

The Functional Archive component or FAR represents an object graph of an application that is loaded in memory. FAR therefore is a memory mapping technique. There are some similarities between a map consisting of components with bundles that have been registered in the bundle registry. In fact, FAR could be thought of as a "super bundle" that runs within a specific container instance. The main difference is that the object graph is lazily loaded, meaning only class objects that are needed on demand are put in memory while some may only have existing references (concept of emerging behavior which is one of the aspects of the Techne container). So the super bundle has quite a lot of activities going on simultaneously. Also, the objects in the object graph do not have a start/stop lifecycle. Instead, they have a loaded/unloaded lifecycle similar to classes. Furthermore, these objects depend on programs that are triggered by policies. In addition, this component has the following features:

  • When the object graph is in memory, the "application" that is being hosted by the container instance has full access to these objects by means of delegation or proxy.
  • A FAR is a "self-hosting assembly." It can look up or search for any matching container instance and load itself to that instance within the network.
  • The FAR's object graph is validated by an inspector which can be called on demand.
  • A FAR can be integrated with another FAR.
  • The component manages its own history. It has the capability to go back to previous configurations.
  • Each container instance can only load one FAR at a time.
  • The FAR is actually a product of the Builder.
  • FAR's two basic resources:
    • First, you can use existing assemblies like bundles, plugins (bundles with eclipse extensions), war-files, simple jar files, directories (bunch of resources).
    • Second, you can disassemble anything down to bytecode entities (java-class files) and use this as a starting resource.
      The second approach is interesting, because it could help building Techne itself. So we just point the Builder to the eclipse workspace (where all bytecode files are produced by Eclipse) and let it assemble components. Necessary meta data comes from Eclipse config files, bnd files and possibly from other formats (SCA components maybe).
  • The actual FAR is composed at runtime but it can be archived as a concrete and discreet FAR for quickstart or backup and restore.

Seven Characteristics of a FAR Component

  • It is a bunch of bytecode.
  • It has lots of metadata.
  • It makes up a profile in Felix terminology (and in PeterUserstory).
  • It is always self-contained.
  • It is a self-hosting assembly.
  • Everything it needs except the TRE components are inside.
  • No "multiple FARs" can exist because the TRE will merge each contribution (FAR) into a single FAR.