Overview

The APAM Machine is based on a component-service metamodel, called the APAM metamodel, that allows defining, executing and managing component-based and service-based applications.

Metamodel

The central notion of the APAM metamodel is the concept of component. Components can be of three types: specification, implementation and instance, which share most of their characteristics.

Specification

A specification is a first class object that defines a set of provided and required resources (in the Java sense). Complete compositions can be designed and developed only in terms of specifications.

Implementation

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 resources defined by its associated specification, and that requires at least the resources required by its associated specification. In practice, an implementation must define a class that implements (in the Java sense) the interfaces of its specification.

Instance

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 ressources; in APAM it is an object.

Composite Implementation

A composite implementation, also called composite type, is a special case of implementation; as such it implements a specification. Contrary to an atomic implementation, a composite type does not define a main class, but a main implementation that implements the same specification. A composite type contains implementations and defines the rules governing their composition and visibility.

Composite Instance

A composite instance, also called composite, is a special case of instance; indeed it is an instance of a composite type. A composite contains instances (atomic or composite), at least one instance of the main implementation of its composite type.

Component Groups

Components are related by a group-members relationship. A specification is a group whose members are implementations, and an implementation is a group whose members are instances. A group-members relationship establishes a de facto inheritance between the group and its members. More precisely, all the characteristics of a group (its properties, its provided and required resources) are automatically inherited by all its members, like in a class-instance relationship.

Component Life Cycle

During execution, in APAM, a component has a single state: it is either existing (and therefore available and active), or non-existing.

Description Model

At design and development time, a component description contains the (meta-)information needed for the compiler to produce the "right" executable component (bundle), and for the execution platform to enforce its "right" behavior.

State Model

The APAM machine represents the current state of the supported applications (called ASM for APAM State Model) as a model conforming to the APAM metamodel. The APAM machine provides an API for the navigation and management of the ASM, mechanisms for enforcing the declared component behavior of an application, and mechanisms for extending the core functionality through the addition of specialized managers.

In the ASM, the instances of the component concepts are represented as first class objects with a set of attributes (properties) and relationships. The APAM machine is causally connected to the underlying platforms, thus, actions performed on an APAM object are transformed into actions performed on the corresponding platform entities, and vice-versa.

The APAM machine automates the creation of "wires" between the components participating in an application. This automatic wire management (creation, destruction, substitution) is performed in a moving context in conformance with the application definition and requirements; leading to the automatic building of dynamic and adaptable architectures.

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 ensure 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, it delegates all change decisions to the available managers.

Managers

Three classes of managers are defined:

• dependency managers called when a dependency needs to be resolved,
• property managers called when a property of a component is modified, and
• dynamic managers called when a service appears or disappears.

APAM extensibility is based on managers provided by third parties. Two managers are closely related to the core and are then provided in the distribution: ApamMan and DynaMan.

ApamMan is the default dependency manager. ApamMan tries to resolve a dependency looking into the components currently running in the platform, taking into account the visibility expressed in the client composites. If an implementation is found but no instance is available, ApamMan creates an instance of the selected implementation.

Dynaman is the default dynamic manager. Dynaman interprets the strategies defined in the composites and dependencies when a resolution fails, and when a component appears or disappears.

With these two managers, all the information, properties and characteristics defined in the component definition are fully enforced. Another implementation of these two managers can significantly change the core semantics and is therefore discouraged.

Standard Managers

The standard distribution comes with the following basic managers:

• OBRMan is a dependency manager that extends APAM with dynamic deployment. During a resolution, OBRMan is called if ApamMan did not found a convenient service (the right service is not currently running in the platform, or is not visible). OBRMan looks in a number of bundle repositories to find out a service that satisfies the dependency requirements; if found the corresponding bundle is deployed. See Compilation and OBR repositories bellow for more details on how OBRMan works.
• DistriMan is a dependency manager that extends APAM with distribution. During a resolution, if ApamMan did not found a convenient service (the right service is not currently running in the platform, or is not visible), Distriman can be called (after or before or instead OBRMan). Distriman looks on the network to find out a visible APAM machine on which a convenient service is currently running. If found, a proxy is created from the current machine toward the distant service and the resolution returns the proxy address.

Specialized Managers

ConflictMan is a dynamic manager specialized in the resolution of access conflict between two or more applications that require an access to the same exclusive services. This manager is intended to solve the conflicts toward shared exclusive devices.

Third parties are encouraged to develop specialized managers as a solution to their needs.