Dynamic Agent Platform Discovery for Real-Time ...

Dynamic Agent Platform Discovery for Real-Time Resource Selection Z. Balogh, E. Gatial and L. Hluchý Institute of Informatics, Slovak Academy of Sciences/Department of Parallel and Distributed Computing, Bratislava, Slovakia {Zoltan.Balogh, Emil.Gatial, Ladislav.Hluchy}@savba.sk Abstract— In this paper we present a dynamic agent platform discovery system which is used for real-time resource selection during crisis situations. We present a motivating use case and we describe the implementation and design details of the proposed system. Comparison of invocation mechanisms of agents as a direct result of AP discovery is discussed. We also present a scenario on which the discovery mechanism was evaluated.

I. INTRODUCTION Crisis management often happens under adverse conditions, where constant, high bandwidth communication might not be available. Mobile agents systems are a scalable distributed computing paradigm that emphasizes autonomy of software components. Mobile agents localize problem solving, and are therefore well suited to operate in environments where intermittent network failures are to be expected. For instance, assume an incident where a large number of people are injured, such as a traffic accident involving a chemical transport in an urban area. First responders could then rely on the support system to handle patient care. Mobile agents may be distributed across the data centers of different local and even international hospitals to gather information on available services and resources. According to their individual condition, patients can then be individually and automatically assigned to the clinic which has the best in specialist competences, available treatment facilities and free beds. II. STATE OF THE ART In [1] authors describe a system called CI6 which provides a middleware based on software agent using a semantic layer that supports data gathering and aggregation coming from various sources to produce value added information. Authors have evaluated the system by simulating two scenarios: a sea emergency scenario and the management of evacuation of a city area because of flood. The CI6 system integrates the JADE agent platform with the SESAME semantic repository to locate resources. They have stated that the possibility to have a semantic layer (semantic net) and a layer able to elaborate simple data to produce complex information (middleware based on agent), has revealed as an appropriate instrument to manage the complexity and the variety of the analyzed domain. In [2] the possible implementation strategies for e-health service application using the client server and mobile agent paradigms are discussed. The parameters used for analysis are communication time, number of servers, timings and data size. They conclude that in emergency situation like mass casualty, using mobile agents gives better results than client server approach.

Use of the MANET network is used for retrieval of Virtual Electronic Patient Medical Records (VEPMR) upon request from the emergency scene in [3]. Any member of the triage or medical personnel, anywhere in the emergency zone, can create a mobile agent with a VEPMR request when any personal document identification of the victim is found. Use of agents to provide decision support in a dynamic, context sensitive environment was demonstrated in [4]. Authors have implemented an agent which hops between individual places (hospitals or medical archives) from which information are collected. In this proposed approach agents exhibit the property of being autonomous and interactive. Agents also encompass mobility feature which is characterized as the ability to migrate autonomously from one agent platform to another together with collected information. In contrast to the type of mobility implemented in [4] we decided to use agents in a more centralized way. We have developed an agent system called the Secure Agent Infrastructure (SAI) [5] to support the management of crises situations. Since security is a serious obstacle to wider adoption of agents in real-world usage [6] we believe mobility of agents must be addressed in parallel with security challenges. The security issues faced by both mobile agents and mobile agent hosts were addressed for example in [8]. Our SAI uses predefined processes to automate information collection by mobile agents. In order to enable security control of agent execution we restrict the mobility of agents – we allow direct secure deployment of agents to selected authorized agent platforms only. The agents cannot migrate between platforms autonomously instead agents are responsible to deliver information to their sending entity. Agents though might delegate other agents to deliver partial information and deliver results of their execution to multiple (backup) delivery points. Such automated information processing is intended for large scale information collection and processing. In this article we particularly describe the implementation of the SAI agent platform (AP) discovery. We begin with a motivation use case description in section 3. The SAI system was implemented as an extension to Apache River [9] (former JINI) service platform. Individual agent platforms are implemented as JINI services. The AP discovery is described in section 4 and querying and matching AP descriptions in section 5. Comparison of invocation mechanisms of agents as a direct result of AP discovery is discussed in section 6. We verify the application of the proposed AP discovery in section 7 on a real-world scenario for which we have implemented the proposed approach.

III. MOTIVATION USE CASE There are situations in which services with certain changeable properties are demanded instantly during crisis management operations. On the offer side there are providers whose service properties are changing in time, i.e. the availability or level of potentially provided service depends upon for example the supplier capacity. Let’s take for instance the already mentioned healthcare domain where a hospital is able to provide medical services only in a case it has sufficient resources available, i.e. medical staff, equipment or beds. The challenge is therefore to provide a framework which will enable a) dynamic discovery of suitable service providers and b) description, propagation, evaluation and selection of demanded services in real-time. In order to enable such system we need to: 1. enable description of providers and attributes of supplied services and 2.

enable easy and robust propagation and discovery of published providers and selection of services.

We have developed a platform discovery system which tries to fulfill the above stated objectives. This system is part of the already mentioned SAI. In this paper we aim to demonstrate how dynamic agent platform discovery works and how it is implemented. Our use case employs mobile agents to retrieve and report the capacities of hospitals in the vicinity of a disaster site to a mobile command center (Figure 1).

of a crisis situation the hospitals must provide appropriate treatment facilities for the injured persons in a required capacity and must be as close as possible to the incidence site. Each involved hospital has to have a deployed and configured AP that is registered in the registry of APs. The registry allows discovering hospitals based on their attributes, i.e. geographic location, name, address, available medical services or other defined attributes. The mobile command center uses the process management system to initiate a search for hospitals. The process management system queries the registry for suitable hospitals. Then specific mobile agents are sent to the APs of respective hospitals. The agents retrieve the requested information and provide the gathered information to the mobile command center. The retrieval of information might not be instant, but might occur later when required information becomes available – this justifies the use of agents instead of pure services. An agent at a hospital AP can continue execution even when no internet connecting is available and deliver information when the connection is restored. Also agents can deliver already aggregated data which can save transmitted data in cases when bandwidth is limited. The retrieved data is consequently summarized by the process management system and presented to the mobile command center operators. Other advantages of mobile agents in this use case include the abilities to constantly monitor the legacy systems for changes, to immediately notify the sending system of changes, to retrieve information from different legacy systems in different formats, autonomously act or encapsulate advanced intelligence. The Registry of APs as well as the registration, discovery and selection of APs were implemented in Java utilizing and extending an existing discovery mechanism to discover available pre-annotated services, i.e. agent platforms. In the following section we provide further implementation and design details of the AP discovery. IV.

Figure 1. Use of agents to collect information from disparate information sources.

In this scenario mobile agents collect information from disparate hospital information systems such as from legacy databases or from medical staff in charge. In case

AGENT PLATFORM DISCOVERY

As already mentioned the Registry of APs is build above the existing JINI lookup mechanism which enables both description of services and their lookup. This enables us to dynamically discover suitable APs in terms of security (agent authorization and access rights), functionality (the AP contains necessary libraries for agent execution) and business logic (the AP provides the necessary services to agents). JINI system provides a basic interface called Entry – which enables to pass additional information about services that clients can use to query and select required services. There are three Entry classes which we propose to be used by any AP service to describe itself: Geographic Location, Java Libraries and Generic Organization Description. We describe in more details the aim and use of each Entry object bellow.

A. GenericObject GenericObject represents the top abstract Entry object in our hierarchy. It has a single attribute called name, which can be used to name the described entity.

Figure 2. The Library Entry.

D. Organization The AP service is deployed on behalf of an entity which is taxonomically categorized by the Organization entry (Figure 5). Taxonomies can be created for each

Figure 3. The GenericObject Entry.

B. GeoLocation Geographical location can be specified by extending the GeoObject class (Figure 3) which is inherited from the GenericObject class. The information stored in the latitude and longitude attributes should represent the current (but dynamically changeable) geographic location of the organizational entity - not of the AP deployment location. For example an AP service for a hospital should

Figure 5. The Organization Entry.

problem domain. For example for crisis management the taxonomy would encompass hospitals, police, warehouses, fire brigades and other crisis mitigationrelated organizations. Creation of these taxonomies should be part of the system customization process. V.

Figure 4. The GeoObject Entry.

describe the geographic location of the hospital, not the physical location of the server where the AP service runs. C. Library In order to evaluate the compatibility of an agent with the AP’s Java Runtime Environment libraries, all Java libraries should be advertised for each AP service. We have defines a class called Library, which should hold the full class name and version in the respective attributes. Hence during discovery of APs the Process Management Subsystem (PMS) can identify compatibility of the environment with the agent’s requirements.

QUERYING AND MATCHING AGENT PLATFORM DESCRIPTIONS

When the AP service provider registers a service it can optionally register sets of attributes along with the service object. The AP service should use the GenericObject class to describe itself. Entries are advertised to all lookup services, which can be found through multicast mechanism, or to a set of explicitly predefined lookup services - step 1 in the Figure 6. … 1. Entries

2. Query 3. DSAP Entries

Figure 6. Registration of an Agent Platform (AP service) and PMS querying a single register.

On the other hand PMS can query one of the available lookup services which is depicted as step 2 in the Figure 6. The query is formulated in order to retrieve the given type of organization, i.e. matching the Organization entry of the AP service with the querydefined template entry. Refining the selection based on other attributes is executed locally - this is due to the inability of the JINI lookup mechanism to use logical operations in the query. The original lookup service was able to do either exact matches or wildcard matches of Entry object instances. Therefore we had to extend the lookup mechanism to further filter attributes to retrieve relevant AP service descriptions – step 3 in the Figure 6. A. Custom Entry Taxonomy As already mentioned, the Entry taxonomy is domaindependent.

The above example represents an array of entries which describe a Hospital with Emergency facility and with a PlasticSurgery clinic. We used an Entry called Emergency (Figure 8) with a given name and geographic location. B. Agent Platform Registration After the entries are created, the AP service might register itself with one or multiple lookup services:   ...    ServiceItem item = new ServiceItem(       null, dsapService, entries    );     ...    reg = registrar.register(      item, 60 * 60 * 1000);     ... 

The above code excerpt shows how an AP service (denoted as DSAP) registers itself for one hor with a LookupService reference by a registrar object which must be created in advance. This mechanism is in line with a generic way of registering a JINI service. C. Lookup for Agent Platforms based on Entries In order to find a relevant AP service one must again define the template for matching registered services:

Figure 7. Simple Entry domain-specific taxonomy representing clinics in a hospital.

In the Figure 7 we depict a simple evaluation taxonomy, which was created to model a hierarchy of clinics in a hospital. This taxonomy of Entry objects can be used to describe and search available hospitals based on Clinic types. Such taxonomy could be integrated from various data sources in an ontological form as proposed in [9].

Figure 8. Hospital and Emergency Entries definition.

In order to register an AP with descriptions, the AP service code must define an array of entries upon execution. Entry[] entries = new Entry[] {    new Emergency("Hospital BA", 48.17217,         17.07372),    new PlasticSurgery(),    new Hospital()  }; 

Entry[] template = new Entry[] {  new Hospital(),  new Surgery(),    new Library("jini‐core.jar", "2.1")  }; 

In the code above we defined a template, which would match any AP services described by Hospital or Surgery entries. The disadvantage of the current Jini lookup mechanism is that there is no way to specify logical operators for lookup. Therefore a bigger subgroup must be identified and retrieved and later filtered according to more strict constraints. Therefore we have developed a class called FindService, which provides methods to search for AP services either by distance or by entry. FindServices fs = new FindServices();  ServiceMatches matches;    matches = fs.findServiceByEntry(template);    matches = fs.findServiceByDistance(    48.3507, 19.3167, template); 

The code above retrieves all the AP services which match the template entry set (findServiceByEntry) and also services which are closest to the defined longitude and latitude and the template entry set (findServiceByDistance). We use the Reggie standard service as a lookup service. Depending on the size of the infrastructure there might be one or multiple instances of the lookup service deployed in order to implement faultresilience.

VI.

COMPARISION OF AGENT DEPLOYMENT TYPES

Following the AP discovery agents are sent to collect required information. The traditional deployment mechanism (such as described in [4]) of autonomous mobile agents is depicted in the following figure:

Figure 10. SOA-based approach. A client retrieves information from several services using request-response mechanism.

Figure 9. Autonomous migration of an agent through platforms.

Agents are hopping through individual APs retrieving and carrying retrieved information from one AP to another. AP0 is the originating and also the final AP where all the integrated results (r1, r2 and r3) are delivered. We have denoted tex as execution time needed to extract requested information on the APx and tmx,y as the migration time between APx and APy. The total time ttotal needed to traverse all APs and retrieve required information in this setting can be computed as follows:

,

te

tm ,

where n is the total number of APs from which we want to gather information. The total retrieval time of information from multiple sources is the sum of execution times at AP1, AP2 and AP3 plus the sum of all migration times between individual APs. This setting poses several concerns to real-time retrieval of information from APs. The first concern is that the individual hops are processed in sequence so any delay in a processing time at any of the APs (either execution or migration time) will have effect on the total time required to collect information. The second concern is that the migration times might gradually increase (depending on the agent implementation) due to raising size of carried information in each hop (results r1, r2 and r3) which might be a problem in case of low bandwidth communication. The last concern is a security related one – the agent instance traversing all three APs will need authorization and will need to be deployed on each of the APs, which raises either an agent or platform-related security risks. Another way of collecting information is to use Service Oriented Architectures (SOA). In this setting separate services are deployed on individual sites.

As depicted in the Figure 10 we have services (S1, S2, S3) deployed on three different sites. The client C sends requests (treqx) to each of these services. The services process the requests in times tex and return responses (trx) to the client. If the requests are processed in parallel the total retrieval time is computed as: max

,

,

Although services are most commonly used way to retrieve information in the internet today crisis management poses many specific challenges for which service-based approach is not the best suited one. Let’s take for example a sudden and repeatedly occurring network abruption. If any of the request execution times tex takes longer any network failure may interrupt the request. In a case of repeating network abruptions a new request must be submitted each time by the client thus prolonging either treqx or the response time trx. In order to enable a successful processing of all requests we need a working network connection for max(treqx + tex + trx) time to be working continuously where 1