Information Technology Reference
In-Depth Information
3.2
Component & Service Adaptation
Many of the infrastructural services associated with component contexts act as late-
binding mechanisms that can be used to defer inter-component associations by locating
suitable collaboration partners. Through these brokering mechanisms, components do
not need to be statically bound at design/compilation time but can be bound either at
composition-time or at run-time in order to favour the construction of adaptable soft-
ware architectures.
For instance, the
Activator
class in OSGi, the
BeanContext
, and the components
membrane in Fractal enable components to look up services in the frameworks service
registry, register services, access other components, and install additional components
within the local platform.
The separation between component's services and their actual implementation is the
key to the creation of self-managing and adaptable architecture. In striving toward these
solutions, a formal base is usually required to describe the provided and required fea-
tures of individual components and also important semantic aspects, such as the cor-
rect way those features are to be used. With OSGi, developers can associate lists of
name/value attributes to each service, and use the LDAP filter syntax for searching the
services that match given search criteria. Furthermore, Declarative Services (DS) [6] for
OSGi offers a declarative model for managing multiple components within each bun-
dle and also for automatically publishing, finding and binding their required/provided
services. This minimizes the amount of code a programmer has to write; it also al-
lows service components to be loaded only when they are needed (Delayed Activation).
Declarative Services indicates if a required service is mandatory or optional. The bind-
ing makes the life cycle of the component dependent on the presence of that linkage,
respectively having its state as active or passive depending on the presence or absence
of the component's dependencies.
These mechanisms are not limited to components and services running on a single
platform. Remote service bindings are usually achieved through port and proxy mech-
anisms. For example, in both R-OSGi and D-OSGi, remote bindings can be viewed
as connection points on the surface of the component where the framework can attach
(connect) references to provides-ports provided by other components. The framework
is then responsible for returning the correct Java object when a port is requested by a
component. It either calls the appropriate methods of the locally available service im-
plementation object or translates the Java method calls to messages, sends them to a
remote container (e.g., availing of Java RMI, SOAP, or JXTA), waits for remote execu-
tion and then returns the value contained in the received message.
In the OSGi implementation OSCAR, the same mechanism is also used to support
intelligent hot swapping of services to implement fault-tolerant systems. Specifically,
as every service in OSGi may be given a certain rank which can be used to describe its
quality and importance, when queried about a particular service, OSCAR automatically
tries to locate the highest-ranked implementation.
A-OSGi [7] goes a step further by providing a number of mechanisms that can be
used to create self-adaptive architectures. Firstly, a monitor component measures the
CPU and memory used by each bundle by: (i) altering the OSGi life cycle layer so that
