Information Technology Reference
In-Depth Information
all the threads in a bundle belong to the same thread group, and by (ii) providing each
service client with a proxy that executes the service methods within the same thread
group. Secondly, a planning component interprets ECA rules specifying adaptation ac-
tions (used to start, stop and configure bundles) to be executed in response to specific
events and given conditions. Finally, an execution component applies these actions to
their target components.
4
Component & Service Agent Model
The characteristic new approach advocated in this work is to address the lack of com-
mon adaptation mechanisms in component & service frameworks by leveraging their
previously unexploited similarities with the BDI agent model.
The previous two sections allows us to draw many similarities between agent and
component & service-based frameworks: while the first favours the construction of ap-
plications in terms of loosely coupled, autonomous entities (the agents), each agent
is still a managed entity within an agent platform - just as components are managed
within their container. Furthermore, similarly to the separation between goals and plans
in agent systems, the decoupling between component's services and their actual imple-
mentation is the key to the creation of adaptive software systems.
In order to inform the design of a new generation of frameworks for adaptive soft-
ware systems, and before dwelling on the details of its OSGi-based implementation
(
Self
-OSGi), this section translates the BDI model into general component & service
concepts.
4.1
Modular Belief Model
Rather than storing all the agent's beliefs into a single, centralized belief set, a compo-
nent & service-based organization can be used to access and distribute the processing of
information across the system. Specifically, an agent may use a number of sensor com-
ponents to interface with its environment. Each of these components produces data that
can be exported with any of the collaboration styles afforded by mainstream component
& service-enabling technologies (procedural calls, messaging, events). This informa-
tion can be fed to other perception components, for instance, to infer situations or test
conditions involving multiple beliefs, thus enabling a variety of perception architectures
to fit with the sensors available to the agent and also with the run-time requirements
posed by its specific perceptual processes.
4.2
Service Goal Model
A
Service Goal
is informally defined as
the interface of a service that may be used to
achieve one of the agent's goals
.
Service goals may represent either: (i) sub-goals defining the desired conditions to
bring about in the world and/or in the system's state (for instance, the service
(void)
