devices based on JADE. We show the main issues in downsizing it to PDAs / mobile phones and applying agent technology in the area of virtual team support. 1.
A Scalable Agent Infrastructure Michael Berger, Bernhard Bauer, Michael Watzke Intelligent Autonomous Systems Group Siemens AG, Corporate Technology D–81739 Munich, Otto-Hahn-Ring 6, Germany [Michael.Berger | Bernhard.Bauer | Michael.Watzke]@mchp.siemens.de Abstract Agent technology has the potential to play a key role in building and supporting virtual enterprises. To host and enable agents as well as agent functions an open infrastructure is needed. Beside standards, such an infrastructure has to be generic and deployment independent to deal with the heterogeneity of the computing and information technology world, e.g. supporting devices ranging from mobile phones, PDAs, Laptops up to personal computers and workstations as well as different kinds of mobile and fixed networks. In this paper we give an overview over the agent platform LEAP developed for small end user devices based on JADE. We show the main issues in downsizing it to PDAs / mobile phones and applying agent technology in the area of virtual team support.
1
Introduction
Since the early nineties the world is becoming more and more connected. The Internet usage is growing exponentially. Mobile data services are reaching users world-wide at anytime and businesses are moving to the web to connect with the customers, suppliers and partners to respect the globalisation of markets. Based on this communication and data exchange facilities, distributed virtual organisations and their intelligent support are becoming more important. Agent technology has the potential to play a key role in this “revolution” by automating daily processes, enriching higher level communication and enabling more intelligence service provision, e.g. by personalisation and service integration to value added services, to deal with the enlarging amount of information and functions. To realise this big potential, agents need to communicate to discover
their peers, to negotiate and to co-operate in open environments where everybody can add their contribution when and how it is deemed appropriate. For this, standards are required which allow the interoperability between agents of different vendors and domains. To host and enable agents as well as agent functions an open infrastructure is needed. Beside standards, such an infrastructure has to be generic and deployment independent to deal with the heterogeneity of the computing and information technology world. For example, it should support devices ranging from mobile phones, PDAs, Laptops up to personal computers and workstations as well as different kinds of mobile and fixed networks. This is one of the key factors for success of agent technology. Furthermore, such an infrastructure should be easily accessible and extensible by users and programmers from different domains. Open source software, such as Linux [Linux] and Apache [Apache], helps in the way to a worldwide distribution and let the community grow very fast. As also stated in [Raymond99]: “Internet-enabled collaboration and free information sharing, not monopolistic control, is the key to innovation and product quality.”, the way of thinking on open source becomes more importance since the mid nineties. Another and not even less important requirement for the acceptance of agent technology as a major key role for an infrastructure, are generic services for virtual organisations and virtual mobile teams. Such services are designed for multiple reuse and cover areas where higher level of intelligence are needed and agents seem more relevant than ever. Examples are personal assistance, knowledge and travel management, and distributed work co-ordination. Section 2 gives a short introduction on agents and FIPA (The Foundation for Intelligent Physical Agents) [FIPA], the world-wide standard body for agent technology. Section 3 describes the development of LEAP [LEAP] (Lightweight
Extensible Agent Platform), the world first FIPA compliant scalable agent platform running on PDAs and mobile phones based on the open source implementation JADE [JADE]. Section 4 includes the description of generic services and applications for virtual teams being under development. This also comprises a short overview over the field trials which will evaluate the concepts 1. Section 5 concludes and outlines ongoing work and future activities.
2
Agent technology background 2.1
Agent basics
Software agents are an innovative technology for the efficient realization of complex, distributed, and highly interactive heterogeneous systems and applications, such as virtual organizations and virtual mobile teams. Software agents are software components characterized by autonomy (to act on their own), re-activity (to process external events), pro-activity (to reach goals), cooperation (to efficiently and effectively solve tasks), adaptation (to learn by experience) and mobility (migration to new places). Agents can be specialized for the individual demands of their users and be used with minimal effort, as well as they communicate with other agents and external components in order to use or modify global relationships, see e.g. [Maes94; Müller97; O’Hare96, Odell00]. Agents are living on a so-called agent platform (AP) - a middleware which provides them with basic services inside of an AP and between APs: white and yellow pages. Often, agents are subdivided into three functional sections with different functionality: • The agent body wraps a software component and controls it through its software API. Such a software component may be a database, a calendar or an external service. Connected to an external software, the agent acts as an application agent transforming the application API into agent communication language (see below) and vice versa.
• The agent head is the intelligent unit of the agent. It is connected to the body on one side and to the communicator on the other side. The agent head contains databases storing knowledge of certain types like facts, beliefs, goals or intentions, preferences, motivations, and desires concerning the agent itself or associated ones. The world model contains an abstraction of relevant states of the real world. It is updated by information from other agents or through real world interfaces such as a sensors. The agent head is able to evaluate incoming messages with respect to its goals, plans, tasks, preferences and to the internal world model. • The agent communicator converts logical agent addresses into physical addresses and delivers messages on behalf of the agent head through appropriate channels to the receivers. Furthermore, the communicator runs an event loop listening for incoming messages which are forwarded to the agent head. The agent behavior should be benevolent which means that they at least understand the interaction protocols and react accordingly. Messages are highly structured and must satisfy standardized communicative (speech) acts which define the type and the content of the messages (agent communication language (ACL) [FIPA]). The order of exchanging messages of a certain type is fixed in protocols according to the relation of agents or the intention of the communication. Multi-agent systems require an appropriate adaptation to changing environments and to dynamic demands of customers. Learning techniques are well suited for the adaptation of single agents and whole multi-agent systems. Especially, user profiles and preferences can be learned by an agent, see e.g. [Mitchell97]. User agents are specialized agents, representing uniquely a user within an agent system.
2.2
FIPA – A world-wide agent standard Zeus (Mozilla) Jade (LGPL) Jade
Jade (LGPL)
LEAP (LGPL)
LEAP Zeus (Mozilla) 1
The platform, the services, the applications, and the field trials are part of the project LEAP founded by the European Commission through the grant IST1999-10211. The authors would like to thank the other partners of the project: ADAC, Broadcom, BT, TILabs, Motorola, and University of Parma.
Fig. 1. LEAP development process
The Foundation for Intelligent Physical Agents (FIPA) was formed in 1996 as a non-profit organisation with the remit of producing software standards for heterogeneous and
interacting agents and agent-based systems across multiple vendors' platforms [FIPA]. The emphasis is on the practical commercial and industrial uses of agent systems. The aim is to bring together the latest advances in agent research with industry best practice in software, networks and business systems. Beside the FIPA Abstract Architecture specification, identifying architectural abstractions, FIPA’s specifications include the following areas: • FIPA Agent Message Transport: deals with the delivery and representation of messages across different network transport protocols. • FIPA Agent Management: provides the framework within which FIPA agents exist and operate. It establishes the logical reference model for the creation, registration, location, communication, migration and retirement of agents. • FIPA Agent Communication: specifies the ACL (Agent Communication Language), along with libraries of predefined communicative act types, interaction protocols and content languages. • FIPA Applications: contains service and ontology descriptions and case scenarios for four agentbased applications. Current activities include the further specification of: application and management of policies and constraints; the support for agent platforms to manage and maintain large constellations of agent platforms and agents; the enhancement of agents to work in the nomadic application environments; ontologies; agent security; and agent mobility aspects.
3
LEAP - The Lightweight Extensible Agent Platform environment 3.1
LEAP platform development process
The Lightweight Extensible Agent Platform is the precursor of the second generation of FIPA-compliant platforms. It represents a major technical challenge - it aims to become the first integrated agent development environment capable of generating agent applications and executing them on run-time environments implemented over a large family of devices (computers, PDAs, mobile phones, etc.) and communication mechanisms (TCP/IP, WAP, etc.).
LEAP emerged as an independent development branch of JADE (see [JADE] and Section 3.2) under the LGPL licence [LGPL] and will be merged with the JADE mainstream, at which point LEAP will replace JADE’s kernel (see Figure 1). As such, LEAP concentrates on Lightweight and Extensible aspects, whereas JADE continues independently its evolution towards environmental functions such as monitoring facilities, visualisation packages, ontologies and policies. The JADE APIs remain unchanged. Therefore all existing applications will continue to run as before. In addition, developers can use JADE/LEAP to migrate existing applications to, or develop a new generation of applications for small wireless devices. The LEAP applications on virtual mobile team management (see Section 4) are a good illustration of these new capabilities. In parallel to the JADE-based development, project LEAP leads the evolution of the agent application development tool ZEUS [ZEUS] under the Mozilla licence. ZEUS simplifies the design and development of complete agent applications, providing sophisticated visualisation and simulation facilities, and finally compilation into LEAP agents.
3.2
Jade agent platform
One of the six available FIPA compliant open source systems is JADE [JADE]. In the following, we will give a short introduction to the actual version (v2.01) of JADE. A JADE agent platform consists of so-called containers, being either an agent container or a main container. All components and agents of a container are loaded into the Java Virtual Machine (JVM) [Java]. An agent container is a container for agents, which can either be empty or containing one or more agents. The amount of agents running in a container can change during execution. Each agent container may consist, beyond the agents, of a message dispatcher responsible for the delivering of agents' messages to other containers, and an Agent Communication Channel (ACC) responsible for the message passing between different agent platforms. A main container is a special case of an agent container. For each JADE platform exists exactly one main container, containing an Agent Management Service (AMS) and Directory Facilitator (DF) agent and a RMI registry [RMI], since in JADE the intra platform communication is done using RMI. Therefore a main container builds up a complete FIPA compliant agent platform. Arbitrary agent containers can register at the main container and thus the agent platform can be distributed over several computers. Figure 2 shows the examplary construction of the JADE agent platform. The main container and the two agent container are running on different machines in the network. The other FIPA compliant agent platform is somewhere in the internet. It can
be either another JADE platform or an arbitrary FIPA compliant agent platform. Agent 1 up to Agent 5 are agents e.g. of a distributed application. On a semantical level the agents are sending messages based on the FIPA-ACL standard. The delivering of the messages is done by the container, i.e. the agents are communication not directly with each other but via their containers. The communication between the containers depends on the location of an agent. If both agents are in the same container usual method
AM S
• Transport layer independent and in particular supporting transport protocols suitable for both the wireline and wireless environment, thus providing an homogeneous layer to agent application developers. • Compliant to the last FIPA specifications. • Extensible such that, when deployed on a powerful machine, it can provide a number of optional functionality such as agent mobility, user-defined ontologies, and platform management GUIs. o th e r F IP A c o m p lia n t p la tfo rm
IIO P , e tc .
ACC
DF
IIO P, e tc . Agent 1
Agent Agent 2
ACC
RMI
A g e n tC o n ta in e r RMI
M a in C o n ta in e r
b asis c o m p o n en t
Agent 4
M essage D is p a tc h er
M essage D is p a tc h e r
RMI
3
ACC
Agent 5
RMI M essage D is p a tc h e r A g e n tC o n ta in e r
b asis a ge n t
an o th e r ag e n t
F ig . 2 . E x a m p le o f a J A D E a g e n t p latfo rm
invocation is performed. Within the platform two agents are communicating using RMI [RMI] and IIOP [OMG] is used for inter platform communication. The internal physical communication is completely transparent to the user.
3.3
Platform changes to openess and scalability
The LEAP activity focuses on restructuring the JADE core, compliant to Java 2 Standard Edition (J2SE) [Java], in order to match the LEAP requirements. That means the new core is re-integrated into JADE to obtain a single platform that is: • Lightweight enough to be deployed on small devices, such as mobile phones, supporting only a KVM [Java] with Java 2 Micro Edition / Connected, Limited Device Configuration (J2ME/CLDC) [Java], instead of a standard JVM [Java].
3.3.1 J2ME / CLDC compatibility solutions The analysis of the JADE classes (J2SE-compliant) have shown that there were incompatibilities with the J2ME/CLDC API. To solve these incompatibilities the first step was to set up a CLDC-compliant version of LEAP. The detected incompatibilities can be divided into two kinds of classes, namely some J2SE classes which are not supported at all by CLDC and some J2SE classes which are only partially supported, hence some methods are missing. The following solutions solved those problems without loosing functionality or performance under J2SE. The proposed solutions were used simultaneously: • The JADE code was slightly modified to avoid using unsupported methods or classes. • Some Java classes, which do not exist in J2ME, were rewritten to be identically available in J2SE and J2ME. • Any other cases were identified and put in a special
module with different implementation depending on the Java platform. • If it is not possible to provide an implementation for J2ME, this piece of functionality is not available in J2ME environments. The following guidelines were used for the design of the rewritten classes: • It shall be possible to use these classes in the kernel of the LEAP platform (they shall implement the same interface, which shall be put into the kernel); • The performance impact for J2SE shall be minimised; • To keep the classes as lightweight as possible, only the features that are needed for LEAP are implemented. In order to achieve this, two decisions were taken. The first decision was, that the same class hierarchy is used for J2ME and J2SE so that these classes may be used from the kernel. The second decision was to implement some classes as a direct equivalent of a standard J2SE class. In that case, the new J2ME version of the class encapsulates an instance of the original J2SE class and behave as a wrapper, by redirecting all the calls to the encapsulated (original) class. Beyond changing the implementation according to the underlying Java platform, additional work has been done on the JADE platform to minimize the foodprint of the platform.
3.3.2 Transport layer independance A container is basically a Java object maintaining a table of local agents. It is responsible for: • Serving the requests, issued by its local agents, for operations that must be handled at the platform level such as: sending a message to another agent, or performing a life cycle transition (e.g. suspension and termination) including transfer/cloning to a remote container. • Dispatching incoming ACL messages to local agents. • Forcing its local agents to perform life cycle transitions when the AMS (that represent the authority of the platform) commands that.
• Handling other platform management operations such as the notification to the main container about its “birth” (starting) and “death” (terminating) or the creation of logs. The above leads to the general requirement to exchange information with the outside world (inter-platform exchange of FIPA messages) over one or more Message Transport Protocol (MTP). The information exchange with other containers in the platform (intra-platform exchange), e.g. to dispatch an ACL message to an agent on another container, has to be carried out through platform management commands that the containers send and receive and occurs over one or more Internal Transport Protocol (ITP). Therefore, within LEAP the following changes were made to support the independence of the transport: • The RMI intra-platform calls were changed such that from the platform side remote method invocations are performed. However, the RMI invocations implementing intra-platform exchanges of information were replaced by commands, with the same semantics, that are sent over the network from one container to another. A command carries a command type identifier and several command parameters. • The command dispatcher responsible for the dispatching of commands from one agent container to another one, selects an appropriate transport protocol to deliver the command and does the serialization of the involved objects. • However due to the fact that the CLDC configuration of the Java 2 Micro Edition (J2ME) platform does not support any built-in “serialization” to transport objects, there was the need to develop a surrogate serialisation mechanism to enable object transportation over the network. This serialization is done similar to the standard Java serialization for the objects being sent via the command structures.
3.3.3 Optional functionality The LEAP extensibility is a fundamental characteristic of a platform intended to cope with different devices and run-time environments. As platform developers, we categorized the components of the platform as part of the LEAP core or as LEAP optional functionality. The components belonging to the LEAP core are needed by all profiles and they are meant to implement the basic functionality of the platform. The components implementing the LEAP optional functionality are not required by all profiles and they are intended to work only on devices with sufficient memory and processing power.
At the moment, two pieces of functionality belong to the LEAP optional components/utilities: agent mobility and event listening. In particular, event listening allows agents to register as listeners for events that might occur in a platform. A listener agent registers for events with the AMS of the platform it want to monitor. If the AMS grants this registration, it is informed of all events that occur in the platform by ACL messages. An agent may observe the message delivery and reception, the transitions of agent life cycle, and the transitions of container life cycle. More pieces of functionality will be added to this list providing general-purpose tools for application developers. The LEAP platform was also designed to allow deploying the extension mechanism in different configurations (called profiles). Each profile supports the core functionality and a well-defined set of optional functionality suitable for a given type of device and a given type of application. With that, the LEAP platform is open and third-party developers can use its extension mechanisms to implement application-specific functionality that can be categorized as: • Platform extensions: Platform extensions are intended to provide new general-purpose functionality to cope with application-specific needs, like new transport protocols. • Platform integrations: Platform integrations are intended to provide application-specific code needed by agents, like new ontologies. Therefore LEAP integrates a generic ontology support. Such functionality is not part of the optional functionality and is not bundled with the LEAP distribution package.
4
LEAP applications and field trials
In order to demonstrate and evaluate some of the many benefits that LEAP will bring to users, companies and their customers, and society at large, two field trials will be conducted. One will take place with ADAC (a German company providing road side assistance) in Germany, the other with BT (British Telecom) in the UK. Both will be based on a LEAP application that is designed to meet the needs of mobile workers operating within virtual teams, and
that makes use of agent-based services.
4.1
Generic agent-based services for virtual team support
Initially, three agent-based services will be built within the project (but more can be added later): • Knowledge Management (KM) - services enable mobile workers to collaboratively establish, maintain and utilise a body of expertise relevant to their working lives. The KM services are anticipating a mobile worker’s knowledge requirements by accessing and customising knowledge (based on the mobile worker’s skill, location, current job and type of display) and providing access to collective knowledge assets in the team (e.g. by putting novices in touch with experts, as and when required). Generic KM service components like find-relevant-information, updateknowledge-base, and find-expert have been identified. • Teamwork co-ordination (TC) – services enable mobile workers to co-ordinate their activities in order to act as a distributed team, while taking into account each mobile worker’s preferences, local management constraints and so on. Much emphasis is placed on enabling mobile workers to flexibly manage the time they are at work. This includes allowing them to swap elements of their current working schedule activities (e.g. by trading jobs and negotiating for work), registering for and swapping overtime allocations, or swapping leave allocations, all within an agreed policy framework. We can also enable management to issue requests for mobile workers to register for overtime, to cancel leave at short notice, rearrange their shift patterns etc. The TC services are facilitating ‘buddying’ between mobile workers where team members can exchange tacit knowledge, for example between experienced and trainee workers. Generic TC service components like generatework-schedule, trade-work-request, coordinate-socialactivity, swap-shift, trade-overtime, and communicatewith-mentor have been identified. • Travel management (TM) - services support mobile workers in travelling during their working day, providing up-to-date information and guidance on travel planning, ensuring travel time is minimised, thus saving resource and reducing traffic congestion. Anticipating a mobile worker's travel needs, the services will provide guidance and time estimation so as to synchronise the movements of virtual teams working over vast geographic areas. Three generic TM service components have been identified to date: plan-route replan-route and estimate-route-cost. Where practical, the MESSAGE [Message] methodology for
designing agent-based systems will be used during the design of the agent services. This provides a useful way of organising the outputs of the design process and, as it prescribes an iterative process, allows developers to identify decision points in the design and provides the opportunity to incorporate comments and suggestions into the next cycle of the design process.
4.2
The Field Trial Scenarios
4.1Road side assistance A member of ADAC has a breakdown/accident with their vehicle, and calls the ADAC Breakdown Assistance Center (BAC). A “yellow angel” is dispatched from the BAC to help the member. The LEAP application’s task is to assist the “yellow angel” as follows: by providing guidance on the best route, based on current traffic information; by finding information about common problems for the customer’s model of car, by suggesting possible ways to fix those problems, and by downloading the relevant information to the wireless LEAP device, whilst the “yellow angel” is in transit. Once the vehicle is repaired, the “yellow angel” can provide the member with up to the minute traffic information, to help them plan their onward journey. If it is not possible to carry out a roadside repair, the “yellow angel” can still help the member by using the LEAP application to find information about alternative transport, sightseeing or accommodation.
4.2 Telecommunication network maintenance
mobile phone to the Internet and Siemens-MIDP-Emulator for mobile phones. To our knowledge LEAP is the first FIPA platform and agents running on lightweight PDAs and mobile phone emulators under J2ME/CLDC and MIDP. LEAP Version 2.0 (which will physically run on mobile phones) will be ready in September 2001. LEAP Version 2.0 will be released under an open source licence agreement. The LEAP Applications will be implemented in October 2001 and the Field Trials will be conducted in May 2002.
References [Apache] http://www.apache.org/ [CSELT] http://www.cselt.it/ [FIPA] http://www.fipa.org/ [JADE] http://sharon.cselt.it/projects/jade/ [Java] http://java.sun.com/aboutJava/ [LEAP] “Lightweight Extensible Agent Platform”, Project Number IST-1999-10211, http://www.cordis.lu/ist/projects/ 99-10211.htm, and http://leap.crm-paris.com/ [LGPL] http://www.gnu.org/copyleft/lgpl.html [Linux] http://www.linux.org/ [Maes94] Maes, P.: Modeling Adaptive Autonomous Agents, in: Langton, C. (ed.): Artificial Life Journal, Vol. 1, No. 182, MIT Press, pp. 135-162, 1994. [Message] MESSAGE Deliverable, 21 July http://www.eurescom.de/~pub-deliverables/P900series/P907/D1/p907d1.pdf
2000.
[Mitchell97] Mitchell, T.M.: Machine Learning, McGraw Hill, 1997.
Installation and repair engineers from BT will be able to use the LEAP application in the field via mobile devices i.e. PDAs and mobile ’phones. The emphasis will be on helping engineers to receive work requests, synchronise tasks, retrieve documentation, reach other virtual team members to get help and information, exchange tasks on the fly, and arrange convenient meeting places, based on their personal preferences and current locations.
[Müller97] J. P. Müller. The Design of Autonomous Agents : A Layered Approach, volume 1177 of Lecture Notes in Artificial Intelligence. Springer-Verlag, Heidelberg, 1997.
5
[OMG] http://omg.com/library/iiop4.html
Evaluation and Conclusion
The project LEAP reached its first milestone (LEAP Version 1.0) by running FIPA compliant agents on PDAs in December 2000. At the moment the LEAP platform supports the following emulators and end user devices: Palm Vx and Palm emulator, Quartz emulator, Psion 5MX coupled through IrDA and a
[Odell00] J. Odell. ed., Agent Technology, OMG, green paper produced by the OMG Agent Working Group, 2000. [O’Hare96] O’Hare, G.; Jennings, N. (eds.): Foundations of Distributed Artificial Intelligence, John Wiley & Sons, Inc. New York, 1996. [Raymond99] E.S. Raymond: “The Cathedral and the Bazaar – Musings on Linux and Open Source by an accidental Revolutionary”; O’Reilly & Associates, Inc., Sebastopol, CA, 1999. [RMI] http://java.sun.com/products/jdk/rmi/ [ZEUS] http://www.labs.bt.com/projects/agents.htm
