A SOMA agent is logically composed of three parts: state, code, and mobility policy. The state part includes private data and information about the status of the execution; the code part contains the description of the computation to carry out (migration directives are not embedded in the code part); the mobility policy part comprises Ponder obligation policies that have the agent as policy subject (see Figure 4).

Figure 4. A policy controlled SOMA agent.

Each client stub is composed of two MAs in a master-slave relationship. The master MA (UserInterfaceAgent) acts as an user interface agent that allows healthcare staff to collect, insert and visualise patient information. The slave MA (ExplorerAgent) is responsible for searching useful information related to the patient from hospital information sources. We exploit the SOMA mobile agent framework to support the design and deployment of MA applications. Agent migration strategies are abstracted away from SOMA agent code and modeled as policies.

From an implementation point of view, when one agent is first instantiated, it is associated with two concurrently executing threads (the Agent Worker and the Policy Worker), with a Policy Engine and with a mailbox (see Figure 5).

Figure 5. SOMA Policy-controlled Agent Architecture.

The Agent Worker thread is in charge of executing the agent code part, whereas the Policy Worker thread is responsible for coordinating the activation of agent migration at event occurrence accordingly to the policy specifications contained in the agent mobility policy part. The Policy Engine provides the functionality to load/unload policies into the agent mobility policy part and to activate policy retrieval and execution at event notification. Finally, the agent mailbox permits the agent to receive event notification. Let us now describe how mobility policies can be interpreted and consistently enforced. The Policy Worker waits for event notification, that is delivered to the agent via mailbox. At event notification the Policy Worker delegates policy management operations to the Policy Enforcement Service. When the execution of a policy starts, any additional event notification is stored sequentially in the agent mailbox in a FIFO stack and it is extracted as soon as the management of the previously triggered policy terminates. Note that the concurrent execution of both Agent Worker and Policy Worker threads may lead to inconsistencies, such as when the Policy Worker activates agent migration while the Agent Worker is executing a critical section, i.e., a portion of agent code whose execution cannot be interrupted. Inconsistencies arise because the Java technology, used to implement SOMA agents, does not preserve the agent execution state upon migration. Examples of critical sections are when the agent is currently engaged in a transaction that has to be completed locally, or when it is using local resources to which it cannot re-bind once migrated. To avoid potential inconsistencies, agent migration should be delayed until the end of the critical section. Toward this goal we synchronise thread execution by providing agent programmers with the capability to mark an instruction in the agent code part as a critical section (the criticalSection("savePersonalData") method of Figure 4). The agent system supports the mutual exclusive execution of the critical section. For example, if the Policy Worker tries to activate policy enforcement while the Agent Worker is executing a critical section, the Policy Worker computation is automatically suspended and resumed as soon as the execution of the critical section terminates.