The Apam system is made of the Apam machine, and a number of managers that, collectively, are designed for the run-time support of dynamic applications. The Apam system supports a component-service model whose behavior ranges from "classic" components platforms (like in EJB, Fractal, ...), to "pure" service platforms (like OSGi, SCA, webService , ...). The following is a short introduction to the Apam System.
The APAM machine
The Apam machine (APplication Abstract Machine) is based a component-service metamodel which goal is the run-time support and control of component or service based applications. The Apam machine manages the current state of the supported applications (called ASM for Application State Model) as a model conforming to the component-service metamodel. The Apam machine provides an API for the management of this ASM, mechanisms for enforcing the declared component behavior, and mechanisms for extending the system through the addition of specialized “managers”.
The Apam metamodel emphasizes the concepts of specification, implementation and instances. In the following, the words “component” or “service” are used informally to mean specification, implementation or instances. In the Apam ASM, instances of these concepts are represented as first class objects with a set of attributes (properties) and relationships. Before run-time, these concepts are represented by artifacts that can be described, developed, built, and deployed (as OSGi bundles). Once deployed (in the OSGi platform), they become an object of the ASM. The Apam machine is causally connected to the underlying platform (OSGi) : everything performed on an Apam object is transformed into actions performed on the corresponding platform entities, and vice-versa.
A specification is a first class object that defines a set of provided “interfaces” (in the java sense) and a set of required specifications. Note that this is not symmetric, since specification dependencies are not toward interfaces but toward other specifications. Complete compositions can be designed and developed only in term of specifications.
An implementation is related by an “implements” relationship with one and only one specification. An implementation is an executable entity (in Java) that implements all the interfaces defined by its associated specification, and that requires at least the specifications required by its associated specification. In practice, an implementation must define a main class that implements (in the java sense) the interfaces of its specification (see Implementation description for how to describe an implementation). Before the run-time an implementation can be a part of a bundle, in the underlying platform it is a set of classes, in Apam it is an object.
An instance is related by an “instanceOf” relationship with one and only one implementation. An instance is a run-time entity, represented in the run-time platform (OSGi) as a set of Java objects, one of which is an instance (in the Java sense) of its associated main class implementation. In the underlying service platform, an instance can be seen as a set of services, one for each of the associated specification interface; in Apam it is an object. A “client” instance can be related to a “server” instance by a “wire” relationship. A “wire” represents the fact that, in the OSGi platform, an object of the client instance has a field toward a service provided by the server instance. Wires are automatically created during execution when these fields are used for the first time. Relationships “use” between the corresponding implementations, and “require” between the corresponding specifications are derived from the creation of wires.
Since dependencies are in term of specification (or interface), creating a wire needs to select an implementation that implements that specification (or interface), and then to select or create an instance of that implementation. This process is called resolution. It is not the Apam platform but the managers that are in charge to perform resolutions. Each manager resolves with respect to a different “repository”; for example, APMAN resolve in the ASM, SAMMAN in the service platform, OBRMAN in OBR repositories, and so on.
Composite Type concept
Composites types are a special case of implementation; as such they “implement” a specification. Contrary to atomic implementations, they do not define a main class, but a main implementation that implement the same specification (see Composite description for how to describe composites). A composite type contains implementations and defines the rules governing the visibility of the implementations it contains. A composite type C contains its main implementation, and all the implementations that will be “deployed” to create a wire which origin is an instance of an implementation contained in C. An implementation is “deployed” if it is brought into Apam ASM from “outside”, outside meaning either the service platform or any repository. A composite type C has to deploy an implementation either because there is no valid implementation currently in the ASM (APMAN fails to resolve), or because the valid implementations present in the ASM are not visible from C. Therefore the same implementation can be deployed (logically) more than once, and be contained in more than one composite type.
A composite is a special case of instance; indeed it is an instance of a composite type. Being an instance, wires can start from, or lead to, composites. A composite contains instances (atomic or composite), at least one instance of its composite-type main implementation. An instance pertains to a composite if the resolution of a wire which origin is an instance pertaining to the composite, leads to brought to the ASM a new instance, either found elsewhere (e.g. in the service platform), or created (e.g. by instantiation). An instance pertains to a single composite, leading to a hierarchy of composites, since some instances can be (sub) composites. The ASM therefore contains a forest of composite hierarchies, each tree being called, abusively, an “application”.
Users can explicitly create relationships “depend” between composites, and “import” between composite types. These relations define the scope and visibility; see Sharing and scope specification.
The APAM System
The behavior of the Apam system is the result of the collaboration between the Apam machine, and a number of managers. Roughly, the duty of the Apam machine is to hold the Application State Machine (ASM), to enforce the causality between the ASM and the underlying platform, and to enforce the properties associated with the ASM objects. But the Apam machine, by itself, never changes the ASM, but delegates all change decisions to the available managers. The Apam system is extensible, if comes with a set of standard managers (shortly described here), and new managers can be created or alternative one substituted.
Apam delegates to the managers different classes of reactions.
- resolution. When an instance asks for the creation of a new wire, managers are asked to select, instanciate, deploy … the needed components, and to create the needed wire (see Apam machine , Dynamic deployement ).
- component apparition. When an instance or implementation appears on the underlying platform, the Apam machine sends an event (to managers that subscribed). These managers can change the ASM accordingly (see Dynamic components ).
- component disappearance. The fact an instance disappears is notified to the interested managers. It may result in deploying, instantiating or selecting new components, and in changing wires (see Dynamic components ).
- faults and failures. Each class of error and fault detected by Apam are notified to the interested managers, which can react and try to fix the problems.
- creation/destruction of ASM components. Each creation / destruction of object in the ASM, and most notably the composites, are notified to all managers.
Managers can be driven by a specific model. Each time a composite type is created in the ASM, Apam calls each registered manager with the associated model. It means that the management strategy is relative to each composite type. For example, each composite type can (and should) indicate the repositories from which are to be deployed its components (OBRMAN), which is the dynamic strategy (DYNAMAN), how the composite should be managed (COMPOMAN), what is the distribution strategy (DISTRIMAN) and so on.