An Agent-based Platform for Federated Information Systems: Some Design Issues• C. CIOFFI, M. PANTI, L. PENSERINI, L. SPALAZZI, E. TONUCCI AND S. VALENTI Computer Science Department – University of Ancona 60131 Ancona – Italy
[email protected]
Introduction The information flow through different actors is as desirable as difficult in a Public Administration scenario. It is desirable, since it allows coordination and cooperation among different activities, producing more timely and effective results. It is actually difficult, due to the rigid structure of a bureaucratic environment, which often produces very different structural views of the same objects or resources, depending on the aim an activity is carried on, its context, and the constrains involved. Thus it seems of particular relevance the study of methodologies of information integration and the development of technologies to support interoperability of autonomous information systems. In this paper we concern with this topic in the context of a particular case study: the information system supporting the Territorial Framing Plan (TFP) of an Italian district. The TFP is an open and cooperative system, outlining a reference model that allows describing social, economical and cultural phenomena coming into the plan and their actual manifestations. On the other hand, the TFP allows representing the evolutions of both such phenomena and the model itself. The problem of an information system for monitoring "political instances" as TFP are, must be stated in terms of pre-existing, evolving information systems which are managed by the actors of the plan, rather than in terms of available technologies (e.g. communication networks, servers, computers, etc.). The term actor addressing any individual or collective private or public subject having a relevant role in the plan definition, and characterizing both information needs and products. Such information systems are often cited in acts, regulations and directives in an imprecise, informal way, without detailed specifications of their characteristics nor of the procedures to set for their effective running. Therefore, even if an attention to information and its circulation can be guessed from official documents, on the other side, they lack to grasp the fundamental fact that usefulness of such systems strongly depends on the presence of cultural, normative, organizational and technological tools to "put at work" information not only for operational tasks, but also for decision-making. The realization of a TFP as a result of interaction among various private and public subjects can be seen as the concrete ground to define a general project involving the development of such tools. As a matter of fact, TFP is seen by districts, as the knowledge needed to produce a reference scenario within which to measure and coordinate political strategies devoted to the development of: • cohesion and coexistence of economic, social, administrative, and cultural demands; • infrastructures (means of communication, assistance, services or other); • the location of district plants or centers; • the utilisation of historical and cultural areas to a greater advantage. Furthermore, the TFP has a purposive aspect in terms of suggestions/directions of actions on the territory which can be taken as a sort of benchmark of the action model the TFP itself represents. In this framework the need of an information system which allows monitoring the realization of the TFP and provides the information needed to log its temporal evolution becomes relevant. Since the goal is to produce and circulate information, the first fundamental step is the characterization of relevant information, and the management of its circulation by means of suitable tools which allows to realize a true communication, where sender and receiver understand each other. Furthermore, since a TFP is a dynamic entity, whose contents can change and evolve in many respects, it turns to be necessary the continuous actor intervention thus raising the need of a representation supporting
•
This work is part of the INTERDATA research project funded by MURST (Italian Ministry of University and of Scientific and Technological Research) and it is accepted In Proc. of the International Conference: on Software Engineering Applied to Networking and Parallel/Distributed Computing (SNPD' 00), Reims, France, May 18-21, 2000 1
the external communication towards the actor community, besides a coherent internal representation of information. Therefore, an important preliminary work is the deep analysis of the state of the information owned by the actors, their needs (related to the plan) and their ways of communication. Moreover, the monitoring of possible interactions and overlaps of parts of the TFP pertaining to different actors is of great importance, as well as actor's awareness of interactions and overlaps, which can be achieved only by communication. Thus the communication methods cannot be conceived just as networks of interconnected computers: they must include some mechanism of proactive information exchange and revision. TFP is both a planning activity, producing real projects of intervention on road, health, industrial infrastructures etc., and a set of norms and methodologies by which to plan and control the consequences of the planning. Therefore the TFP has to adjust itself by adjusting its plans on the basis of the original norms and methodologies it born with, and also by adjusting such norms and methodologies. This result may be obtained imposing a steady although flexible set of relations among actors and their information systems, that is a flexible model of communication allowing mutual understanding between involved actors while saving autonomy. As a main consequence, the system supporting the TFP is mainly characterized by the capability of integration of heterogeneous solutions adopted by single actors. The dynamical properties of a TFP adds another level of complexity on the support system, which has to handle modifications due to: • •
internal actions causing revision/adaptation processes; external events, independent of its area of influence, like decisions assumed by neighbour districts or unforeseeable natural phenomena.
Therefore an open information system, easily reconfigurable to allow both the entrance of new actors and the exit of old ones, is required. Features such as plurality, heterogeneity, dynamicity, reconfigurability make traditional information system paradigms quite inadequate, as the organization models they are based on (typically hierarchic or functional) are too rigid in terms of reconfigurability and too centralized both in terms of the definition of languages, protocols and information organization/conceptualization and in terms of control mechanisms. Since the autonomy of each actor cannot be decreased to reduce the heterogeneity of the whole system in the adopted test-bed, it is necessary to study solutions that do not affect autonomy while maintaining a "reasonable" level of information interchange (communication of everything to everybody is utopian in the context of TFPs, which involve a wide variety of very different actors). In the light of current research insights and available technology, an adequate model appears to be that of "federated information systems": that is a set of autonomous information systems which decide to share (part of) their data and processes in a cooperative perspective. In this paper we will discuss the implementation of a platform based on software agents for federated information systems. The platform has been developed trying to fulfil the Fipa97-98 specifications with special emphasis on: • • • •
portability use of standard protocols both for intra and extra platform communication autonomy and dinamicity support of cooperation among agents.
2. - Reference Model In this section we will give an overview of the most common models both of Federated Information Systems and of Agent-based Systems. Such models will be then compared with the requirements of the application domains in order to present our approach to Federated Information Systems for Local Public Administration. Models for Federated Information Systems (FIS) Information integration is defined as the task of providing a uniform access to autonomous and heterogeneous information sources. Furthermore, information sources may be classified as structured, as for 2
instance relational databases, semi-structured, i.e. spatial data represented through quad-trees, or destructured (text or images). The basic components of a FIS are (She90): • • •
a common data model – that should be flexible enough a) to represent different kinds of information from different sources and b) to cope with missing or wrong information; a common language – that could be used to submit queries to the integrated system. Also in this case, flexibility along with high expressiveness levels is required to cope with different functional levels of distinct information sources; some tools for translation (to cope with syntactic relations), integration and mapping (to handle semantic relations)
In the last few years, mediators-based systems have become the reference architecture to integrate both structured semi-structured data (Wie92, Sub98, Ham97 and Are93). Such systems are characterized by the presence of wrappers that are responsible of the translation of the data representation from the local model of the information source to the common one and of the queries from the common language to the information source language (fig. 1).
Fig. 1 – A network of Mediators, Wrappers and Information Sources (Gai97) Mediators have been introduced to improve the management of the integrated system through the amalgamation of data coming from different sources and the handling of inconsistency. Furthermore mediators are used to handle user-formulated queries through reformulation plans and query optimization towards different information sources. Two main approaches have been reported in the literature to the design of mediator-based systems that can be discriminated as query vs. data centered. The former put the emphasis on the ability of the mediator to answer queries: in this case it does not exist an explicit integrated schema of the common data model, and the semantic relations are defined as views. Different mediators are needed to answer different queries or to build distinct relations among data. Existing systems in this class provide the programmer who has designed the mediator, tools to integrate domains, information and to handle conflicts. (Gar97, Lev96 and Sub98) In the latter approach to the of design mediator-based systems, query formulation is an activity that stems out from the definition of an integrated schema requiring a partial or total unification of the local data models (Are93, Har97 and She88). In spite of the greatest number of prototypes based on a query-centered mediators that have been reported in literature, we believe that the applicability of such approach is reduced by the number of involved information sources, since semantic heterogeneity must be explicitly reduced by the programmer. Furthermore query centered mediators may rise the classical problems of information processing: reduced usability due to the fact that a limited amount of semantic relations and queries is implemented only, and dependence of data from applications rising problems of alignment and inconsistency. 3
Therefore we consider the development of models for automatic integration of common data schemata a strategic issue. Holding in mind the previous considerations, a possible configuration of the developed architecture showing agents, platforms and domains is depicted in figure 2 (Dia98, Val99). Platform District Y
Wrapper
Domain: MAPS DB
Wrapper
DBMS
DB DBMS Platform Region Z
Mediator
GV Mediator
Domain: Register Office Mediator
DF
GV
GV
AMS ACC
Maps
AMS Wrapper ACC
DB
Mediator
Platform Municipality Y
DBMS
GV
DF Register-office AMS ACC
Fig 2 - Platforms and domains for a TFP For each platform an Agent Management System, an Agent Communication Channel and a Directory Facilitator (DF) at least should be defined. Furthermore application dependent Mediators and Wrapper agents should be included. 3. A FIPA compliant Agent Platform Among different endeavors to define agent platforms specifications FIPA (FIPA 97-98) looks like more suitable for our goals: indeed, it defines the specifications that must be satisfied both from protocol and communication language and platform architecture. Three mandatory agents constitute the FIPA's reference model for agent platform (AP) architecture (fig. 3): Agent Communication Channel (ACC), Agent Management System (AMS) and Directory Facilitator (DF).
!
"
#
!
"
#
!
(
$
#
"
%
#
)
*
"
-
+
&
'
#
&
* )
,
)
%
%
.
# )
*
)
#
%
-
/
#
#
,
Internal Platform Message Transport
Fig. 3 - Agent Management Reference Model
4
The ACC manages the transaction message both between intra and inter-platforms agents. All agents have access to at least one ACC that behaves as the router of the AP. Each AP contains only one AMS who is in charge of controlling and managing the AP itself and agent activity. More in detail, the AMS manages the creation, registration and deregistration of an agent into its platform. The white-pages represent one of the most important services provided by AMSs. The white pages contain the list of all agents registered on the AP identified through their GUID. Moreover, an AMS must register on the default DF of an AP at least. Although being ACC and AMS functionally distinct they do not need to be physically separate. Therefore these two agents have been implemented in our prototype as a single entity, thus representing a single process having distinct functionalities. This design choice stems from the high level of message interaction among the two agents and is aimed to avoid the useless overburden of the communication channel and to decrease the elapsed time among queries and answers. The ACC is the router of the platform and delivers messages between agents inside the platform and among agents belonging to other platforms. Therefore, the ACC must be fast and efficient. In particular each message to be routed in a platform by the ACC must be previously authenticated on the white-pages of the AMS to verify the registration on the platform both of the sender and of the receiver. Thus, if the two agents are implemented as distinct entities exchanging messages, the high interaction could become a bottleneck for the platform performance. The ACC, AMS and DF agents adopt the FIPA-request protocol to communicate. This protocol defines the relationship between message types supported by agents. In particular, to explain the meaning of each message and the actions supported by agents we take example from AMS. An AMS agent is a mandatory component of any FIPA compliant AP, and is responsible for managing the operation of the AP itself. This agent maintains a list of all the agents currently registered on its platform. Each item in the list must contain the ams-agent-description information recording the GUID, ap-state and address of the agent. These last informations are needed to uniquely locate the agent and to know in advance the possibility to communicate with it. The list of agents introduced above is named white-pages service from FIPA. The white pages are used by AMS to manage the agents in order to perform the tasks: register-agent, deregister-agent, modifyagent, query-platform-profile, authenticate and search-agent. The Directory Facilitator (DF) provides a yellow-pages like directory service to agents. The DF is a mandatory, normative agent, which is the trusted benign custodian of an agent directory. It is trusted in the sense that it must strive to maintain an accurate, complete list of agents. It is benign in the sense that it must provide the most current information about agents in its directory on a non-discriminatory basis to all authorized agents. Agents may register their services with the DF or query the DF to find out what services are offered by other agents. According to FIPA, at least one DF must be resident on each AP (the default DF). However an AP may support any number of DFs. The importance of the DF derives from the definition of Agent Domain i.e. the logical grouping of agents defined by membership to a directory maintained by the DF (fig. 4). Moreover, an agent must register itself at least on one domain even if it can register itself on more domains, thus an AP can support more than one domain.
5
3
@
;
4
5
=
6
9
7
A
6
2
8
9
7
B
:
;
3
@
3
;
= 9
A
6
5
6
7 2
8
7 9
C
J
@
4
:
@
;
G
;
