![](bg4.png)
time in order to favour the construction of adaptable
software architectures.
For instance, the Activator class in OSGi, the
BeanContext, and the components membrane in Frac-
tal 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
features of individual components and also important
semantic aspects, such as the correct way those fea-
tures are to be used. With OSGi, developers can as-
sociate lists of name/value attributes to each service,
and use the LDAP filter syntax for searching the ser-
vices that match given search criteria. Furthermore,
Declarative Services (Humberto Cervantes, 2003) for
OSGi offers a declarative model for managing multi-
ple components within each bundle and also for au-
tomatically publishing, finding and binding their re-
quired/provided services. This minimizes the amount
of code a programmer has to write; it also allows ser-
vice components to be loaded only when they are
needed (Delayed Activation). Declarative Services
indicates if a required service is mandatory or op-
tional. The binding makes the life cycle of the com-
ponent dependent on the presence of that linkage, re-
spectively having its state as active or passive depend-
ing on the presence or absence of the component’s de-
pendencies.
These mechanisms are not limited to components
and services running on a single platform. Remote
service bindings are usually achieved through port
and proxy mechanisms. 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 cor-
rect Java object when a port is requested by a compo-
nent. It either calls the appropriate methods of the lo-
cally available service implementation object or trans-
lates the Java method calls to messages, sends them to
a remote container (e.g., availing of Java RMI, SOAP,
or JXTA), waits for remote execution 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 sys-
tems. 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 partic-
ular service, OSCAR automatically tries to locate the
highest-ranked implementation.
A-OSGi (J. Ferreira and Rodrigues, 2009) 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 all the threads in a bundle be-
long to the same thread group, and by (ii) provid-
ing each service client with a proxy that executes the
service methods within the same thread group. Sec-
ondly, a planning component interprets Event Condi-
tion Action (ECA) rules specifying adaptation actions
to be executed in response to specific events and given
conditions. Finally, an execution component applies
these actions to their target components. Specifically,
A-OSGi considers three main action types, namely:
1) specify rules for service bindings, in such a way
that a specific bundle is prohibited, or obliged, to use
some specific service implementation; 2) change ser-
vice properties, for instance change a parameter asso-
ciated with a service implementation; and 3) control
the life cycle of a bundle, by either starting or stop-
ping bundles.
4 RELATED WORK
A number of works have looked at leveraging both
component and agent approaches for the development
of adaptive software systems.
A component-based approach in the construction
of multi agent systems has been supported by numer-
ous researchers in the past. This typically considers
the components to be simply the building blocks from
which agents are constructed (M. Amor and Troya,
2003). An advantage of this approach is the abil-
ity to take domain-specific issues into account at the
component level. The decisions made on these issues
can therefore be separated from the task of construct-
ing the multi agent system as a whole, thus simpli-
fying the process. The resulting agent applications
inherit some of the (functional/non-functional) prop-
erties from the underlying component framework.
However, this form of technical integration does not
contribute much to a conceptual combination of both
paradigms as, once they are built, agents remain the
only primary entity form.
A different integration approach is advocated in
SoSAA (M. Dragone and O’Hare, 2009b), in which
an high-level agent framework supervises a low-level
component-based framework. The latter provides a
computational environment to the first, which then
COMPONENT & SERVICE-BASED AGENT SYSTEMS: SELF-OSGI
203