Design of an Agent Cluster as Integrative Environment of Personal Agents Torsten Illmann Distributed Systems Department University of Ulm, Germany
[email protected]
Frank Kargl Distributed Systems Department University of Ulm, Germany
[email protected]
Michael Weber Distributed Systems Department University of Ulm, Germany
[email protected]
Abstract Since searching, sorting and filtering of information nowadays becomes more and more important, the demand for supportive autonomous, mobile and intelligent software agents is steadily increasing. For fast and efficient implementation of agents there needs to be a powerful infrastructure supporting collaboration and coordination between agents. While developing such a powerful distributed infrastructure for personal agents in Java, we combine all personal agents of one user within a so called Agent Cluster which may be seen as an integrative environment. Agents can easily enter or leave the cluster or run within a common security environment separated from the outside. Within the cluster, they use common private services such as access to private data, serialization or efficient communication services. The design of such a cluster composed of a software bus called Agent Bus and agents is described in this paper. For agents, we introduce a flexible design of an agent model by identifying different inter-agent functionality with specific Agent Roles.
1 Introduction As human knowledge is doubling every few decades, it seems to be obvious that people spent more and more time with browsing, searching, sorting and filtering of information - especially within the Internet. One hope is that intelligent and personalized software agents help to solve these problems and make daily work more efficient. Agents are proactive, personalized, adaptive and autonomous software entities that work at request of their user, take the initiative and submit intelligent proposals for problem solving [7]. Hence, the need of developing agents will further intensify
and since we want to avoid the reinvention of commonly used functionality, we are developing a communication infrastructure for personal agents in Java called CIA [4]. The system design of CIA is mainly based on modularity and flexibility. CIA provides all the necessary fundamental functionality for agent programming like distribution, different communication models, mobility, persistence, security issues and robustness. These mostly technical issues can be seen as a component-based repository of low-level functions useful for agent programming. When building a new agent, the developer does not care about technical issues but simply uses the ones from the repository according to his needs and concentrates on developing the essential, application-specific functionality. To achieve this, the CIA system is designed in three layers as shown in Figure 1: the agent layer, the directory-, broker- and trading layer and the service layer. All personal agents are located in the agent layer. All personal agents of one user are combined in an Agent Cluster. The directory layer provides distributed white- and yellow-page services. Using these services, agents within a cluster (layer 1) or application services (layer 3) are able to locate other Agent Clusters or services. All application services not bound to a specific user are part of the service layer. A exemplary room reservation scenario is illustrated in Figure 1. In this paper we concentrate on the design of an Agent Cluster. We propose a modular structure and describe its components. To illustrate the design an exemplary diary agent negotiating appointments with diary agents of other users is described with code fragments. At the end of the paper we mention related work and discuss the design.
Figure 2. The Agent Cluster
Figure 1. The CIA 3-Layer Model
2 Agent Cluster All software agents belonging to one user are combined in an Agent Cluster as shown in Figure 2. For that reason, it can be seen as privacy domain for distributed personal agents. Each user builds his own private cluster tailored to his specific needs. Agents can dynamically enter or leave the cluster, driven by user request or by one of separate control agents present in each cluster. Within a cluster agents can communicate via a software bus which we call Agent Bus. Because of that, agents can easily be spread over several physical places which makes sense especially in local area networks (LAN) to do load balancing or use special system resources on specific computers. To design a general agent cluster as private part of a communication infrastructure for agents, we post the following requirements: 1. Autonomy of agents. Agents should be loosely coupled via the agent bus. 2. Maximum of modularity. Each encapsulated functionality is realized as separate agent. 3. Asynchronous communication. Communication should be robust, dead locks should be avoided. 4. Easy plugin of agents. Basic agents are provided and new agents can be easily integrated. According to these requirements, we structure an Agent Cluster in separate parts: Agent Bus, Agent Places, Agents and Agent Roles. These components illustrated in Figure 3 using UML notation are described in the following sections.
2.1 Agent Bus The CIA Agent Bus is the central (and only) communication mechanism in our agent infrastructure. We have identified various requirements for agent communication that our Agent Bus must meet: 1. Location Transparency. The composition of agents at one place may vary frequently. Mobile agents may come or go and certain agents may be started or shutdown by their user. Thus a mediating middleware is preferable above direct addressing. 2. Topic addressing. An agent can not know which other agents are interested in the information the agent wants to make public or which other agents can respond to its request. Thus an addressing style based on topically named communication channels and not on single agents is preferable. 3. Message filtering. Furthermore not all agents want to interprete all messages. So some kind of filtering mechanism should be realized directly within the messaging system. 4. Persistent messages. Mobile agents or agents hosted on mobile systems like notebooks or PDAs may not always have a direct connection to the messaging system. Thus some kind of disconnected operation mode is needed where important messages are stored in a persistent manner within the messaging system and are delivered to the agents whenever they reconnect. 5. Quality-of-Service. Not all messages have the same importance and such different qualities of service need to be implemented. Some messages e.g. may need high throughput but only few reliability whereas others have to be delivered with an exactly-once semantic. 6. Timing Constraints. Often an information has a certain lifetime. It is valid only after some initial date and not
Asynchronous ChannelEvents that are directed to a channel and are seen by all consumers on this channel. Events differ from ordinary communication in that they are not addressed to special recipients but to a communication medium where all participants can read this event. In contrast asynchronous ChannelMessages are addressed to a specific agent on a channel and are delivered to this agent only. Synchronous multicast ChannelRequests are sent to a channel where a number of repliers may process them. Each replier may return a result. All results are delivered to the requestor as an array of ChannelReplies. Alternatively, the receiver may specify to only receive the first incoming request in order to realize failure tolerance or be more efficient.
Figure 3. Components of an Agent Cluster
longer than its expiration date. Such and similar timing constraints should be respected by the messaging system. 7. Secure communication. Agents often deal with sensitive information about their user (like credit card numbers etc.). Secure and confidential communication should be implemented directly within the agent communication infrastructure. 8. Distributed architecture. For reasons of scalability and resilience, the messaging system should work without any central components, like message dispatcher or naming service or at least these components should work redundantly. 9. Portability. As we want to use different platforms for our system, ranging from PDAs to PCs and workstations, the messaging system must be platform independent or easily portable. The Agent Bus is divided into subchannels, called Agent Channels, that provide a topic based information exchange between clients. Agents, channels and the whole Agent Bus are named using a URL-like notation. An example may be: cia:://frank.kargl@de:123/dates/diary-agent
You can specify optional QoS parameters, your name, country and the optional personal id to identify your personal Agent Cluster. /dates denotes the name of a channel for exchanging date information. Finally diaryagent is the name of a specific agent communicating via this channel. The primary design principal was to keep usage of the Agent Bus by agent programmers as easy as possible. Therefore an agent simply passes the data it wants to an Agent Channel. Reception of events works via event handlers. There are four kinds of communication entities that an Agent Channel can handle:
Synchronous ChannelRequestMessages are similar to ChannelRequests, but are directed to a specific agent. Any of these mechanisms may be used in parallel within the same channel. The following code example illustrates how easy channels are created/joined and events are sent: // create new AgentBusFactory using ibus AgentBusFactory myABF = new AgentBusFactory("ibus"); // create new AgentURL AgentURL myAURL = new AgentURL( "cia://frank.kargl@de/dates/diary-agent"); // create new Channel AgentChannel myAC = myABF.newChannel(myAURL); // create new Event ChannelEvent myCE = new ChannelEvent("Test Message"); // send event myAC.sendEvent(myCE);
ChannelMessages and ChannelRequests/Replies may be used in a similar manner. The reception of events works via event handlers and may look like this: public class SimpleEventReceiver implements ChannelEventListener { public static void main() { // create AgentChannel (see above) ... // register ChannelEventListener SimpleEventReceiver mySER = new SimpleEventReceiver(); myAC.addChannelEventListener(mySER); ... }
public void handleChannelEvent (ChannelEvent event) { // parse ChannelEvent ... } ... }
The Agent Bus also provides for event persistence. The Message Log Agent records all events in a channel for a specified lifetime and may retransmit them to any agents that join this channel at a later point in time. Other Quality of Service parameters like encryption, reliability etc. may be encoded in the qos specification of the AgentURL. After comparing different messaging systems [5] we decided to use Softwireds iBus [10] as a first platform for implementing the Agent Bus. iBus is a very portable (100% Java) concept with good built-in capabilities. As iBus uses a configurable stack of different stack modules to define its functionality and as application programmers can add custom stack modules, we are also able to integrate own features like security mechanisms or new communication patterns, e.g. implementing an encryption module. As we do not want to depend on a single messaging system the Agent Bus totally wraps all specific aspects of iBus. There is a factory for creating new Agent Channel instances that can work with any other implementation. We plan to implement at least two other alternatives for comparison: one based on the CORBA Notification Channel [2] and a completely independent implementation of a messaging system based on an ATM network that allows advanced QoS applications like video conferencing.
2.2 Agent Place An Agent Place is defined as runtime environment for agents. With running several Agent Places on several physical locations, agents of one cluster can be spread or move over certain physical locations e.g. PCs in the office, at home or even PDAs. This idea extends the usual understanding that the electronic privacy domain of one user is located on one physical machine or at least LAN. The functionality of an Agent Place is quite small. It has to support other agents to enter the agent cluster on its local machine. On behalf of the Agent Cluster, it starts agents locally and provides them with the necessary information for them being able to connect to the Agent Bus (the agent cluster URL and used agent bus implementation). The agents will be loaded by a special class loader either from the local file system and in case of absence over the agent bus. A second functionality of an Agent Place is to inform the cluster about the local system load so that automatic load balancing can be realized. The Agent Place runs in a separate process and subscribes to a well-known channel of the agent bus. Initially,
the Agent Place is started by the user. After every crash of the local system, the Agent Place automatically restarts and informs its cluster which is then able to re-establish the execution of agents on this Agent Place. There are two possibilities to start new agents. The agents can run in separate threads, which we call shared agent activation policy, or separate processes, called unshared agent activation policy. An Agent Place may be configured by the user with one of the two policies. The difference of the two approaches is a different mass of efficiency, security and robustness. The shared policy uses less memory, the unshared one is more robust for agent failures and more secure against hostile agents.
2.3 Agents and Agent Roles The CIA infrastructure already provides a set of basic agents [4] which support application agents in their tasks, i.e. they offer support for management, logging, security or persistent object storage. Each Agent Cluster needs at least these five basic agents (see Figure 2): 1. The Cluster Control Agent (CCA) manages the agent bus. It controls the initialization of the whole system, starting of new agents, moving of agents or stopping of unneeded ones. After a system failure, it re-establishes the agents that were killed. For low-level functionality it communicates with the appropriate Agent Places. Only the CCA is authorized to to start new agents. The Agent Place only acts on behalf of it. 2. Agents can store themselves or the data they produce using the Persistent Object Space (POS), which is an agent responsible for storing and retrieving serialized objects. We use a tuple space (similar to JavaSpaces) for this task. 3. There is a Message Log Agent (MLA) responsible for collecting and logging all messages on the Agent Bus. The MLA can replay selected messages which is important in respect to delayed agent startup or system failures. 4. All the communication between the user and his agent cluster takes place by way of the User Communication Agent (UCA). This agent provides a convenient interface that other agents can use to interact with their user. In our prototype we use a special Java applet for implementing the UCA. Hence, a user is able to control or monitor his agents remotely by executing the applet from outside via a web server. The web server must be located on the computer the UCA is running on. The applet uses RMI calls to communicate with a cluster-intern proxy which delegates the communication to the agents. Agents can register capabilities
Figure 4. Agents and Agent Roles
or methods with the UCA, the UCA uses callbacks for asynchronous notification [6]. 5. The Cluster Proxy Agent (CPA) represents the gateway of the cluster. All communication into or out of the cluster passes through this agent. Consequently, the internal structure of an Agent Cluster can be hidden to other clusters. The above list of five basic agents represents the smallest and fundamental environment for agents within an Agent Cluster. To build more sophisticated applications we provide further supportive agents providing security facilities (Cluster Security Agent, CSA) or allowing foreign mobile agents (Cluster Docking Agent, CDA) to enter the cluster with certain rights. When designing the agent model, we set focus on the autonomy and simple integration of agents in the cluster. Autonomy is guaranteed by running agents within an Agent Place as described in 2.2. Easy integration requires easy communication capabilities to interact with other (especially basic) agents. Agents often communicate with similar agents using the same channels and messages via the Agent Bus. Many communication scenarios are the same for different agents. To avoid implementing similar scenarios for every new agent, we introduce the concept of Agent Roles (see Figure 4). Possible roles are: The ControlRole automatically subscribes to the admin channel of the cluster and waits for a possible termination request of the CCA. Furthermore, it answers for is-alive events. An agent can use it to access cluster internal enviroment variables. Every personal agent in an Agent Cluster uses this role. Using the MobilityRole indicates that an agent is potentially mobile. It provides the functionality to pack an agent and send it to another Agent Place where it is unpacked. The CCA may do automatic load balancing of agents using
this role. Nevertheless there are agents which may not be mobile, for example when they use local system resources. The SecurityRole provides a possibility to use security functions such as authentication of agents or encryption of data. Agents need these capabilities to exchange private data or add digital signatures. To build user interfaces (UI), agents use the UserInterfaceRole which has an easy-to-use API to create dynamic remote interfaces and receive UI events. This role communicates with the UCA. Since agents are not persistent per default, they have to implement persistent behavior on their own. Using the PersistencyRole they may use simple methods to store and retrieve data through the POS. Dynamically adding or removing roles show the flexibility of this approach. For example we define a role called DynamicRole which does nothing else than waiting on a specific channel for roles to add, remove or replace. When the UCA is moving (i.e. from PC to PDA), the cluster control agent can induce all agents displaying UIs to replace their UserInterfaceRole to a PDA-capable one. Since the framework is open to integrate any other Agent Roles, new agents may and should offer specific Agent Roles for other agents easily communicating with them.
3 Example Agent The following example shows a simple stationary diary agent that is autonomously negotiating appointments with agents of others users. They communicate using a diary channel. Since we have already described how to create and use channels for communication in section 2.1 we here focus on using Agent Roles. The first code fragment shows the initialization of the diary agent: public class DiaryAgent extends PersonalAgent implements ActionListener, ChannelRequestListener { // create agent roles private AgentRole uiRole = new UserInterfaceRole(); private AgentRole dbRole = new PersistencyRole(); private AgentChannel diaryChannel; public void init() { // add roles addRole(uiRole); addRole(dbRole); // create and subscribe to "diary channel" diaryChannel = ... diaryChannel.addChannelRequestListener(this); // create UI uiRole.create("DiaryBean", "cia.agent.diary.DiaryBean");
Appointment app = (Appointment) r.getData(); // load persistent appointements Object[] apps = dbRole.retrieve(new Appointment());
// check for possible appointment if (checkAppointment(app)) { dbRole.store(app); uiRole.call("DiaryBean", "addAppointment", app); return new ChannelReply(...); } else { ... // reply failure }
// init UI uiRole.call("DiaryBean", "init", apps); // subscribe to AWT events uiRole.addActionListener("DiaryBean", this); } ... }
}
The agent uses two roles, the PersistencyRole, to access and store the appointments and the UserInterfaceRole to manage the remote GUI. When initializing, the agent adds the roles and creates and subscribes to the diaryChannel. It then creates its remote GUI using the uiRole. The whole GUI is encapsulated in a Java bean which is transferred and created remotely at the UCAs web interface. All existing appointments are loaded (retrieve) and added to the GUI by calling the remote init method of the bean (call). Moreover, the agent is subscribed to action events of the bean (addActionListener). The following method shows the event handler of the agent when an GUI event occurs. Here, the event means that a new appointment is requested by the user:
When receiving a request from another diary agent, the appointment delivered as request parameter has to be checked using the checkAppointment method. If it fits into the users calender, the appointment is stored, added to its GUI and a positive acknowledge replied to the sender. In the case of conflict a failure reply is returned.
public void actionPerformed(ActionEvent event) { Appointment app = (Appointment) uiRole.call("DiaryBean", "getAppointment");
Telescript is the first implementation of a mobile agent system with commercial use. Its intention was to built agents for searching electronic marketplaces. The language is a self-developed interpreted object-oriented script language being executed by the Telescript engine. Places in Telescript are, in our terminology, services that allow mobile agents to dock and locally communicate with them. Security aspects are included in Telescript (Authorities and Permits). For example, an agent may get the permission to change data at a place or does not get the permission to travel to certain places. Communication between agents is made by events. Since events are delivered only locally, Telescript does not support stationary agents. There is no URL-like general naming concept. Telescript supports transactions to combine a set of depending operations.
// build request from appointment ChannelRequest request = ... ChannelReply reply = diaryChannel.sendRequest(request); // if ok, store date if (reply.getType() == ...) { dbRole.store(app); uiRole.call("DiaryBean", "addAppointment", app); } else { // try sth else, e.g. new date ... ... }
4 Related Work As related projects we want to mention the mobile agent systems Telescript [12] and IBM Aglets [3]. Since a detailed description of them are beyond the scope of this paper, we emphasize on the differences to our system.
}
Using the uiRole, the GUI is asked for the desired appointment. A ChannelRequest is built from it and sent to the appropriate user. When everything works fine the new appointment is made persistent and displayed at the remote GUI. Finally, the diary agent of the other user has to answer to this request implementing the following event handler: public ChannelReply handleChannelRequest(ChannelRequest r) {
Aglets is a mobile agent system developed by IBM Japan and based on the Java programming language. Its focus is to built network-centric solutions that use agents to search, access and manage corporate data and other information. The agent model supports a globally unique URL-like naming scheme for agents and special agent design patterns to support several communication models or traveling behaviors. They developed a general Agent Transfer Protocol (ATP) to transfer objects over the network. Agents are running in ATP daemons which may be compared to our Agent
Places. While CIA supports the remote management of distributed agents of one user (UCA), the visual agent manager of Aglets allows to control all agents of one computer. To ensure secure agents, an extensible layered security model with a sandbox-like environment for agents is introduced. On the highest security layer the user may give special permissions to special agents. Aglets may also be integrated in the World Wide Web on the client or server side. Further agent systems are Voyager [8], Agent Tcl [1], ARA [9] and Mole [11]. They all concentrate on mobile agents.
5 Conclusions In this paper we present the design of an Agent Cluster as integrative and distributed environment of personal agents. We describe how agents in a cluster can be built, how they communicate and work. The total framework is developed modular and flexible by introducing an implementationindependent Agent Bus as cluster communication infrastructure and a pluggable agent model with Agent Roles and supportive basic agents. Like most agent systems we do not emphasize on mobile agents. Since we do not except the network bandwidth being a limiting factor for many applications in future and since there are still a lot of unsolved problems concerning the security of mobile agents, we assume stationary agents to expand more than mobile agents. In our opinion, mobile agents only fit for specific application scenarios. Nevertheless, our framework is designed to combine these two ideas in order to offer a high-level application-independent agent system where the agent programmer may concentrate on the application-specific behavior. Actually, we are working on the integration of mobile agents and mobile places and a flexible security model for stationary and mobile agents. We further think of extending the design of the Agent Cluster, so that it may be split into several subclusters in which a more efficient communication is possible. This especially makes sense when the number of agents and Agent Places raises enormously. The subclusters are possibly located on different networks without being permanently connected (e.g. LAN and PDA).
References [1] R. Gray. Agent tcl: A flexible and secure mobile-agent system. Proceedings of the Fourth Annual Tcl/Tk Workshop, 1996. [2] T. Hewlett-Packard. Joint submission to notification service rpc., 1998. [3] IBM. Aglets software development kit home, available at http://www.trl.ibm.co.jp/aglets/, 1999.
[4] F. Kargl, T. Illmann, and M. Weber. Cia - a collaboration and coordination infrastructure for personal agents. DAIS 99, Helsinki, Finland, June-July 1999. [5] F. Kargl, T. Illmann, and M. Weber. Evaluation of java messaging middleware as a platform for software agent communication. JIT 99, Duesseldorf, Germany, September 1999. [6] F. Kargl, T. Illmann, M. Weber, and S. Ribhegge. Dynamic interfaces of java. Webnet 99, Hawai, US, October 1999. [7] P. Maes. Humanizing the global computer. IEEE Internet Computing, July-August 1997. [8] Objectspace. White papers, available at http://www.objectspace.com/products/vgrwhitepapers.htm, 1999. [9] H. Peine. The ara project. Distributed Systems Group, Department of Computer Science, University of Kaiserslautern 1996. [10] Softwired. ibus specification 2.0.1, available at http://www.softwired-inc.com, 1999. [11] M. Strasser, J. Baumann, and F. Hohl. Mole - a java based mobile agent system. M. Muehlhaeuser: (ed.), Special Issues in Object Oriented Programming, dpunkt, pages 301– 308, 1997. [12] J. White. Telescript technology: The foundation for the electronic marketplace. General Magic White Paper, General Magic, Inc. 1994.
