In order to describe our policy-based mobility model we sketch an MA application in the context of an Emergency Rescue Management (ERM) scenario. This application can provide emergency healthcare staff with the possibility to access, elaborate and insert patient information during patient care. Figure 2 shows the architecture and the interacting components of the ERM application. The 911 service accepts emergency calls and forwards them to the nearest healthcare team. The emergency server running on the ambulance computing equipment receives from the 911 preliminary information on the type of accident and possibly on the patient. Healthcare staff can interact with the emergency server and with 911 by means of client stubs that allow them to acquire on demand additional needed information on patient clinical history. In an ERM application scenario it is essential to simplify information searching/filtering tasks and to allow the healthcare staff to operate from various devices and even when changing physical location. The client stubs exploit the MA technology to address these requirements. The introduction of MAs acting on behalf of healthcare staff can reduce the effort to conduct information searching and filtering and permits to transfer the client-side application execution from the ambulance computing equipment to Personal Digital Assistants (PDA) to follow healthcare staff movements.

Figure 2. The components of the ERM application.

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.

Ponder Policies for SOMA Agents

Let us introduce some simple examples to illustrate the use of Ponder obligation policies for the management of the UserInterfaceAgent and ExplorerAgent mobility behaviour in the previous ERM application (see Figure 3). When the physician involved in the patient care has to physically leave the ambulance to assist the patient, for instance at his home, the execution of the UserInterfaceAgent is transferred from the ambulance computing equipment to the PDA that the physician uses to continue to interact with the 911 service. The MobPol1 policy commands the migration of the UserInterfaceAgent when the physician logs into the PDA (the Login() event). The go() method is used in SOMA to support agent movement. Its input parameters are the new destination device and the name of the method to execute at destination. MobPol2 is an example of policy that forces agent migration when its survivability is compromised. The UserAgentInterface migrates to the PC node whenever the battery level of the PDA decreases under a specified threshold. MobPol3 is used to initiate the migration of the ExplorerAgent when the UserInterfaceAgent needs information related to patient allergy (the StartSearchRequest("Allergy") event).

Figure 3. Ponder obligation policies for mobility.