The term agent is heard frequently today. Why can agent technology absorb so many interests on them? Because it is claimed that agent will free people from annoying and regular daily work. It will act on behalf of you. It can remember what you are doing now and tell you what to do in the future or give you hint what you should do first. You may be disappointed when using a search engine to look for some topic on Internet. Often, a lot of garbage information will be sent to you. Now, agent can help you. It can find what you need through using its super power. It will have intelligence as well as emotions. It will only exist in the cyberspace, not in the physical world. It is a "soft" robot. This is a general image of agent to most people.

So what is an agent? Alan Kay gave the roots of software agents[Bra97]: "The idea of an agent originated with John McCarthy in the mid-1950’s, and the term was coined by Oliver G. Selfridge a few years later, when they were both at the Massachusetts Institute of Technology. They had in view a system that, when given a goal, could carry out the details of the appropriate computer operations and could ask for and receive advice, offered in human terms, when it was stuck. An agent would be a ‘soft robot’ living and doing its business within the computer’s world."

However, there are various definitions of the term agent. Here is another definition by Graesser: An autonomous agent is a system situated within and part of an environment that senses that environment and acts on it, over time, in pursuit of its own agenda and so as to effect what it senses in the future. So instead of trying to give a more general definition of agent, we only want to describe agent’s properties. A software agent may have several or all of the following properties[Bra97]:

• Autonomous: carrying out activities without requiring constant human guidance.
• Mobile: being able to migrate in a self-directed way from one host to another.

• Reactive: the ability to selectively sense and act on some events.
• Collaborative: working with other agents to achieve a common goal.
• Adaptive: being able to learn and improve with experience.
• Other properties.

Then what are the advantages of agent technology compared to other techniques? Here we focus on the mobile agent technology. In the technical view, mobile agent technology brings many benefits including:

• Flexible, dynamic customization of the behavior of clients and servers. The traditional client/server model is fixed whenever the system has been built. So if situation has a big changes, the system may have a poor performance.
• Need less network bandwidth compared to client/server model if a large number of data have to be processed and output is little. It is more efficient to transfer code to the data source than to send data directly.
• Robust remote interaction over unreliable networks.

Why can agent technology bring people so many benefits? Because it integrates many different research areas, such as distributed object computing, artificial intelligence, network, knowledge presentation, security, psychology, and so on. Then are there any special issues related with agent technology? To answer this question is the motivation of the paper.

In the paper, we review about twenty-six papers. In these papers, nine are journal papers, eleven are conference papers, six are other online papers. In section 2, we briefly address some related research work on agent technologies. Then we give a summary of some technique points of agent technologies. In section 4 and 5, we will introduce two known agent architectures: Aglets and Concordia, and applications of agent technologies. We will describe our project in section 6. In the last section, we will give some conclusions. The source code of our project is in appendix.

[Gen94] discussed several problems of software agents. First, agent-based software engineering needs a common agent communication language. There are two approaches to design a common agent communication language: the procedural approach and the declarative approach. Especially, ACL from ARPA Knowledge Sharing Effort, which belongs to the second approach, is described in detail. Secondly, how to combine agent with existing program such as legacy software? Three approaches are compared: using a transducer that mediates between an existing program and other agents, using a wrapper outside the existing program, or rewriting the program. The paper also proposed a federated architecture for multiagent system. [Yam99] proposed a middleware mechanism, which is built on IBM Aglets, for controlling the use of memory and the CPU by thousands of agents. It also gave the results of a performance evaluation. This middleware consists of an agent interaction protocol, a MessageMonitor, an AgentScheduler. It doesn’t address system overload now. The Agent Scheduler provides memory control and thread control. Its scheduling policy is maximum throughput. Unlike the time quanta used by Unix, this mechanism uses units of processing messages. According to the result of experiments, this architecture is scalable. [Kar97] presented the security model for IBM Aglets. It discussed security issues of mobile agent applications and possible attacks on aglets. The purpose of Aglets’ security model is to protect the host and aglets against malicious aglets’ attacks. This model supports a variety of security policies. Several key items of the model were described: principals, aglets, contexts, domains, handling aglet migration, and access control to local resources. The paper briefly introduced two components of the aglets security architecture: the policy database and owner-specified security preferences. [He98] proposed the concept of security agent, which implements the authority of authentication verification service systems. One remarkable characteristic of security agent is its flexibility and scalability, which means dynamic hierarchical certificate relationship can be easily established. The security agent structure consists of the following components: communicator, task planner, task scheduler, execution module, human-agent interface, protocol database, certificate database. To support security agent, KQML is extended to provide public key management and secure communications. [Bre98] discusses a Market-based system to control resources consumed by Mobile Agents. It presents the result got on D’Agents [Previously named Agent TCL]. The system consists of a currency model, a banking system, and a set of currency-aware resource managers. Resources are designated with fixed price or dynamic price. Agents carry some electronic currency with them and pay for the resources they will use to the resource owners. Four primary approaches to dynamic pricing are classified. At present, the system uses the sealed-bid second-price auction strategy to drive dynamic pricing. [Has98] used a resource-centric model to address security issues and some existing solutions, which were related with protecting a host from external programs. First, resources were divided into system recourses, such as memory and CPU, and conceptual resources, which can be accessed through some interfaces. Controlling resource access and consumption were two basic means of current security solutions. A security policy can be implemented during three phases: program-development, migration, and execution. The paper classified existing security solutions according to the different resources and controlling means they focused on, and when they were applied. [Bel99] proposed a secure and open mobile agent programming environment(SOMA). In SOMA, place is the ExecutionContainer of agent. Any node has at least a place. Several places are grouped into a domain, in which a default place takes in charge of interaction with other domains. So SOMA has good scalability. SOMA consists of four components: Agent Manager, Local Resource Manager, Distributed Info Service, and CORBA Bridge. Agent Manager offers the basic functionality such as agent naming, mobility, and message passing. Local Resource Manager is the interface for node resources that agents can access to and controls the authorization of agents and enforces the place security policy. Distributed Info Service offers the functionality like remote monitoring, and remote search. SOMA provides protection for both the hosts and the agents, and ensures integrity and secrecy for agent migration and communication. The protection of hosts from malicious agents is solved by authentication and access control mechanisms, through wellknown certification protocols(DSA algorithm and X.509 certificates). From the agent perspective, integrity and secrecy for message exchange and agent transfer is achieved by standard cryptographic mechanisms: when configuring the SOMA system for untrusted environment, it is possible to choose between the DES channel encryption, or the SSL protocol solution. [Jas97] designed a model for intelligent resource agents. Intelligent Resource Agents serve as mediators between users and Internet resources. They interact cooperatively in a distributed environment to perform tasks ranging from remote database access, to dynamic composition of HTML pages for the display of appropriate resources, to customization of both the form and contents of those pages to an individual user’s preferred styles. However, how to realize cooperation among agents? How to search information from such a large amount of unstructured information on Internet? This paper aimed at solving these two issues. First, Lockheed Martin’s implementation of KQML is selected to realize Inter-Agent communication. It consists of two layers: router and KRIL. Router takes in charge of providing communication path. KRIL is responsible for encoding exchanged information into messages and extracting information from messages. Secondly, the resource catalog is used to maintain meta-information about the data sources. And a special resource discovery agent will continually provide information for the resource catalog. Users can also give comments or suggestions to the resource catalog. So it will evolve with time. Specific tools facilitate users to produce both structured and unstructured annotations. [Sos97] described a general flexible security architecture, the Saga Security System, especially Saga Authorization model and its security mechanism, which consists of access tokens, access control vector, and the security monitor. Access tokens are implemented by using public-key technology. Each Saga agent has an access control list(ACL) and is associated with a security monitor, which protects the agent during its moving in a distributed system. [Abd98] gave the experimental results of comparing three ORB architectures under different workload conditions. Particularly, the paper discussed the impact of inter-node communication delays, message size, and request service time on these architectures. [Lej96] described a framework using a bottom-up construction for the development of multi-agent architectures. This framework consists of three layers: protocols for inter-agent communication, distributed model, and agent coordination protocols. The first two layers are the basis of the third layer. An important contribution of this paper is to address performance issues in some possible multi-agent architectures. Particularly, it discussed performance difference of the framework under the influence of several factors: number of agents in the system, arrangement of those agents, and transmitted message size. [Woo99] summarized some misunderstandings and unsuitable approaches on agent technologies from several aspects. First, agent is not a universal solution. Agent is still a piece of code. To develop agent-based system from scratch is not realistic and is also unnecessary. Secondly, agent technology is not another term of AI technology. So people should not just pursue agents with high intelligence. Furthermore, too many researchers are doing repeated work on agent technology. They all want to develop their own agent architectures. But they might forget agents, what they are studying, will be cooperated with each other. Therefore why couldn’t they cooperate with each other? Besides, agent-based system will be concurrent and multi-threaded in general. So researchers should address issues like deadlock, synchronization, and so on. [Ism99] made a performance comparison among RMI, IBM Aglets, and a minimal self-developed mobile agent model. Since many well-known agent architectures are based on Java, these architectures’ performance will be greatly influenced by Java’s. However, the mechanisms of serialization and de-serialization as well as dynamic class loading in Java are not very effective. Therefore, RMI is much faster than agent migration no matter on a local network or Internet. Only when many RMI calls are needed between a client and a server, moving an agent to the server may bring benefits if the cost of agent migration is less than the cost of multiple RMI calls. According to their experiments, IBM Aglets has higher agent migration costs than their agent model. This is because the Agent Transfer Protocol used by Aglets is more complex. [Won99] presented a generic mobile agent architecture, which consists of six components: an agent manager, an inter-agent communications manager, a security manager, a reliability manager, an application gateway, and a directory manager. In the model, the security manager plays an important role. It will authenticate and authorize mobile agents, encrypt agents before transmission or being saved to persistent storage, and manage a certificate of the agent server such that agent servers can authenticate each other. It also introduced evolution of distributed computing paradigms: from early remote procedure call and process migration, to remote evaluation and mobile object, then to current mobile agent technology. [Kin97] compared three leading mobile agent systems: Odyssey, IBM Aglets, and Voyager. Odyssey provides multiple agent transport mechanisms based on Java RMI, CORBA’s IIOP and Microsoft’s DCOM. Odyssey also has a unique audit trail mechanism that is very convenient for debugging agents in a distributed environment. IBM Aglets is easy to install and use. Voyager has many innovative features. First, it doesn’t require an agent server to run on each node. In Voyager, an agent is called a virtual object. A virtual object can have its own threads of control. It can also be passive objects that be moved and accessed remotely by other virtual object in an RPC-like fashion. Secondly, Voyager provides a transparent access to remote virtual objects. This paper also discussed suitable applications of agents as well as unsolved issues, in which knowledge representation and security are two main problem around agent technology. [Lab99] presented the research status on agent communication language. Common features and limitations of current two main agent communication languages, KQML and FIPA ACL, were discussed. They are very successful. But their applications are limited. This is because they lack some basic agent service ontology, such as naming, authentication, registration, capability definition, and facilitation. Future research directions will be to provide these basic services and integrate with existing and emerging Web technologies like XML and RDF(Resource Definition Format). [Vog97] presented a secure and reliable architecture for mobile agent systems. A two-phase-commit protocol(2pc) is used to ensure the agent transfer with the exactly-once-semantic. Each participant has a public key. For protecting agent migration in an unreliable network, agent is encrypted by using a one-time session key before transmission. This model will ensure security for both hosts and agents. It is based on the prerequisite of trust between each other. A third party, trust service, will maintain the trust relationship among participants. Hosts and users all register on the trust service. All activities in the distributed environment will be logged on the trust service. In case of a trust violation, the logged data can be used to find the violator and call him to account. But in this model, the trust service is a single point of failure. They gave a realization of the model based on OMG Object Transaction Service. They also discussed the scalability of their model. Large distributed systems can be divided into domains. Each domain will be based on their model. But the effective organization and cooperation of all domain trust services is another issue of scalability. [San98] proposed an innovative encryption scheme approach to protect mobile agents from malicious hosts. Its key idea is that through using some encryption schemes, mobile agents can be transformed into encrypted, thus secure, but still executable codes. For example, if we could find a secrete key encryption scheme E on ({0, 1}^*, +, · ) such that encrypted bits can be added and multiplied without being revealed, then we can send agent in the encrypted form to remote nodes and calculated results are sent back in the encrypted form naturally. Here we suppose agents only do addition or multiplication. The theory of this approach is very like FFT, which transforms from the time domain to the frequency domain. The difference is that without the secrete key, it is hard to inverse the encrypted form. [Mus98] focused on unreliability inherent in mobile code. Mobile code like mobile agents will have a much wider range of applications in the future. So the software reliability engineering was proposed to address issues related with mobile code. [Hoh98] discussed some security problems of mobile code and agents as well as relations and difference between security and reliability. [Str99] addressed issues in human-agent instructional situations and proposed a hybrid architecture, which integrates natural language, perception and action in order to make collaborative communications between human and agent in a common environment. The architecture consists of two components: a behavior-oriented base system and a higher-level deliberative system. The behavior-oriented base system integrates language, perception, and action on a lower level. The deliberative system has more complex cognitive competence and can plan complex goals into simple basic actions and schedule their execution. [Gre98] discussed security issues related with the use of mobile agents, and security techniques available to protect mobile agents and hosts. Some attacks to hosts and mobile agents were introduced, including: damage, denial of service, breach of privacy, harassment, manipulation by using misinformation, coercion or other means, event-triggered attack, compound attack. Most of current mobile agent systems use a reference monitor to control mobile agents’ access to information, services, and resources on a computer based on a security policy. The security policy can be predefined and some mobile agent systems also support dynamically changing security policy. In addition, security domains are used sometimes. In this case, each domain has a domain security policy. So different levels of access control are possible. Current security techniques protecting hosts include: authenticating credentials, access-level monitoring and control, code verification, time limits, range limits, duplication limits, and audit logging. The possible techniques protecting mobile agents include: replication and voting, persistence, redirection around crashed hosts or networks, sliding encryption, trail obscuring, code obfuscation through execution context migration, encrypted data manipulation, state appraisal functions. However, these techniques may be in conflict some time when used together. To realize an exclusive secure mobile agent system is very difficult in the near future. So adequate protection to hosts and mobile agents is a more realistic goal through combining these techniques coordinately. [Meh98] proposed an integrated architecture, the Agent Development Environment(ADE), for building, debugging and testing distributed multi-agent applications. In ADE, agents and agent activities can be designed using a graphical programming language based on the Grafcet standard. Each agent has a unique global name and some properties. So agents can be located by their names and specific properties. A Learning Context is provided for agents to develop their behavior through a learning process. Besides, two automatic control applications developed by using ADE were also introduced. [Tah99] proposed a three-layer multi-agent development architecture, which consists of macro-architecture and micro-architecture and the object level. Each has specific agent patterns, which represent typical and recurring structures and behavior of agent. The patterns in the upper layer can be easily reused. The upper layer ensures platform independence. It represents the outline of the system configuration and the agent behaviors and has such generality that the layer is not dependent on any specific agent platforms. The micro-architecture represents the detail of the system configuration and the agent behaviors specialized in each agent platform. The object level represent the program codes implemented according to the design of the above two layers. Several Mobility Patterns and Cooperation Protocol Patterns are suitable for the first layer. Micro-architecture Patterns make good use of the advantage of the platforms. [Ari98] presented some common things, agent design patterns, in the agent-based application design. These patterns can be divided into three classes: traveling, task, and interaction. Three traveling patterns are related with agent migration. Two task patterns are delegation of a task to another agent and coordination of multiple tasks. There are five interaction patterns: meeting, locker, messenger, facilitator, and organized group. Meeing provides a way for two or more agents to initiate local interaction at a given host. One advantage is communication cost is reduced because of only local interaction. Another advantage is local interaction is more reliable since no danger of offline. But the problem is how to measure the cost of transmitting agents and how to do if the meeting host is down. Locker defines a private storage space for data left by an agent while it is temporarily dispatched(sent) to another destination. Its basic idea is data may be large so that binding data with agent in its travel may not be suitable. Messenger defines a surrogate agent to carry a remote message from one agent to another. Facilitator defines an agent that provides services for naming and locating agents with specific capabilities. Organized Group composes agents into groups in which all members of a group can travel together. [Hay99] proposed some patterns for interaction among agents. Four basic architectural styles were introduced: hierarchical, federated, peer-to-peer, and agent-pair patterns. Peer-to-peer is most flexible and hierarchical patterns have the least freedom. As an example, the Broker pattern was described. This is one kind of federated pattern. The broker is located between Client and Server. It requires a request handler, a registration mechanism for service-providers, a matching facility to find providers to satisfy a request, and a mechanism to map results back to requesters.

Through reading all these papers, I think researchers and developers of agent technologies need to solve the following main issues:

There will be thousands of agents running on one host. How to arrange their execution as well as allocate CPU and Memory for them? The agent running environment should avoid the crash danger induced by too many agents. Agents may move to other machines. How to manage them?

We tried two times to create aglets as many as possible to see when the aglet server would go down on the Window NT machine Dalmation. The first time about 930 aglets were created. An invalid aglet exception was thrown and the tahiti server could not exit normally. The second time about 950 aglets were created. But the result was more severe. The Window NT was crashed and rebooted itself. From this, we can know how important to manage resources effectively for the agent running environment. Execution of agents needs memory and CPU. They will read and write files some time. Agents may have special requirements on execution time, network bandwidth, and so on. How to satisfy their requirements? How to control them? Today’s personal computers only run several applications at the same time. They work well. But to server thousands of agents is fully different.

To schedule the execution of thousands of agents is not an easy task. Similar problem also exists in the development of OSs, transaction processing monitors, and so on. Mobile agent systems need an effective mechanism to manage resources. Though IBM Aglets1.0.3 doesn’t scale well, another project based on Aglets, TabiCan, has a much better scalability. To limit the consumption of memory, a swap-in and swap-out mechanism for agents is used in TabiCan[Yam99]. Its basic idea is that not all agents will be active at a moment. Some agents can be moved out from memory when they are waiting for messages. In this case, the swap-out module will store them in secondary storage. Later when a message is targeted to an agent currently in secondary storage, the swap-in module will read it from storage and reactivate it. After the agent finishes processing the message, it can be swapped out again. Using such a mechanism, agent server can hold a large number of agents without using up memory. Different agents are set to different priority values. Real-time agents can be set to a higher priority value so that they will never be swapped out.

When agents are moving from one host to the other host, it is possible that one host or the communication path goes down. How to guarantee that agent successfully reaches the destination, no more no less, exactly one copy?

At present, agents as well as messages are transmitted from one host to another using lower-level protocols like TCP/IP, HTTP, SMTP or IIOP. These protocols don’t ensure that agent is transmitted exactly once, especially in an unreliable network. They won’t recover the transmission after the network disconnection. So mobile agent systems should provide such a reliable transmission mechanism themselves.

If agents in a system have different identifiers, we can use an at-leas-once mechanism to provide agents with a reliable transmission channel. If agents in a system may have same identifiers, we should use the exactly-once mechanism to transmit agents. In this case, we can use the two-phase commit protocol(2PC), which has been used in DBMS and Transaction Processing. A drawback of 2PC is that it is actually a kind of synchronization protocols and several packets have to be transferred for one transaction. So transmission of agents will need a long time.

Without cooperation, agent is just another kind of RPC. We need to define a suitable agent communication language. ACL makes a group of agents cooperatively finish a work that couldn’t be done by individual agent. An ACL provides agents with the ability to exchange information and knowledge in meaningful semantics such that agents can do complex tasks together. This is not like CORBA, which provides a mechanism to transmit simple objects between clients and servers without semantics[Lab99]. Using ACL, agents can exchange plans and goals as well as adjust their plans and goals in a large-scale dynamic distributed environment. Agents not only exchange a single message but also make conversations. They can discuss, negotiate or just chat.

To design an ACL, people often borrow theories from human speech. Like human beings, agents will have beliefs, desires, and intentions(BDI). Emotions are also considered sometimes. As a result, BDI theories are proposed to describe the agent’s knowledge, goals, and commitments[Lab99]. Agents communicate their BDI states with each other.

Since many applications may use different interaction languages, we have to translate a language to another language if we want to integrate them. We need to guarantee that token’s semantic contents are preserved among applications. In other words, the same concept, object, or entity must be preserved across applications even if different applications use different names to refer to it. This is in fact a problem of preserving meaning during translation. However, when discussing communication among agents, people generally consider a higher-level. This is what ACL wants to solve. ACL provides a mechanism for agents to question other agents, inform them, request their services for a task, find other agents who can assist them, monitor values and objects, and so on.

At present, there are two kinds of ACLs: KQML, and FIPA ACL. KQML is a high-level, message-oriented communication language and protocol for information exchange independent of content syntax and applicable ontology. A KQML message consists of three parts: message type, content, communication parameters. The message type identifies the network protocol with which to deliver the message and supply a speech act or performative that the sender attaches to the content. The speech act indicates whether the message is an assertion, a query, a command, or any other of a set of known performatives. The message type also contains information about the ontology used, the content topic and so on. The content can be any information. Communication parameters provide information for transmitting the message to the destination, such as the sender and the receiver.

In KQML, facilitator is a very important concept. A facilitator is an agent(using agent here is confusing. It will be clear to use "component" instead of agent from its functions)that performs many useful communication services, such as maintaining a list of service names, determining information providers based on clients’ needs, forwarding messages to corresponding services, routing messages according to contents, and so on[Lab99].

FIPA’s ACL is also based on speech act theory [Lab99]. In fact, FIPA’s ACL’s syntax and structure are very similar to KQML’s, only using different names.

Now some applications and systems have implemented ACL, such as Jackal(developed at UMBC), JALite(developed at Stanford), JAFMAS from Univ. of Cincinnati. They are all based on Java. And a common feature of these products is that they not only provide single message communication support, but also support conversations among agents. However, they are not interoperable because ACL doesn’t have a standard and they designed ACL according to their needs. Another issue is that several well-known agent architectures don’t support ACL yet. A possible improvement is to plug an ACL component into these mobile agent architectures.

Mobile agent brings the risk of security breach. How to prevent malicious agents or hosts? Security is a fundamental concern for a mobile agent system. Some people said security is the primary obstacle for adopting mobile agent systems[Far96].

Though manay security techniques have been proposed and used to address security issues in traditional standalone applications and static distributed systems, they may not be directly applied in mobile agents systems without any modifications. The security schemes used in those traditional systems are almost all based on the role-based access control model. In this model, files, devices, processes, services are resources; Entities that request resources are principals. Principals are classified as different roles. A reference monitor accepts requests from principals and decides whether or not to grant each request based on the role of the principal making the request and the access rules for the resources. A principal can act as multiple roles. But at one time, a principal can only act as one role. This is to prevent abusement. However, this model is not very efficient to manage mobile agents because mobile agents may change their status during their migration. Besides, those computers and network channels where mobile agents travel are often heterogeneous and have different security levels and are not equally trusted. So it is very difficult to authenticate mobile agents and control their access to resources[Far96].

One feature of existing mobile agent architectures is that they all need to install an agent execution environment on each host where agents may traverse. We use the agent server to denote the agent execution environment. Ideally, a mobile agent system should be secure and reliable. It means that the agent servers should allocate appropriate resources to agents but prevent harmful behavior. Agents should be able to execute as what they are supposed to do. They can communicate with each other in a secrete way and block unauthorized access to sensitive code or data that they carry. When they migrate from one node to another node, they should move to correct destinations. In case of system failure, they can be recovered. But in practice, agents and the agent servers can both become threats to security of a mobile agent system. Various attacks from malicious agents and hosts, both inadvertent and deliberate, are possible. On one hand, malicious agents can terminate or modify the behavior of agent servers. They can mislead other legitimate agents to performe malicious tasks. They can also spy on sensitive data stored within agents as well as within agent servers. Several malicious agents may coordinate to make more severe attacks on other agents and hosts. On the other hand, malicious hosts can also steal sensitive information from agents. They can tamper agents’ code or data. They may randomly terminate execution of agent or send agents to wrong destinations.

How to prevent all these attacks? According to these two kinds of attacks, security goals for a mobile agent system can be discussed in two aspects. On one hand, we should protect an agent from malicious agents as well as agent servers. On the other hand, we should prevent malicious agents from doing harmful behavior on agent server. Currently, the following approaches have been used to address the issue of mobile agent security[Kar97]:

• Running agents in a sandbox or a separated execution environment.
• Transmitting agents and messages in the encrypted format.
• Adding digital signatures on agents and messages for authentication as well as to prevent tampering.
• Using role-based access control to partly protect agents and resources from attacks.

However, it can not be said that these approaches have solved security issues of mobile agents. There are still several difficulties to be solved. First, It is really hard to authenticate agent server. Of cause, we can use a third party to do the authentication. Suppose we can let the party add a digital signature to the agent server. Later we can check whether the agent server has been tampered. It seems we solve the problem easily. In fact not. How to ensure the agent server is correct at the beginning? Someone will say to test it thoroughly. But testing is a tough staff itself. We all know bugs. Some intelligent guys have been able to do some bad things because of security bugs existed in Netscape and IE. Also we have no reliable ways to ensure that the agent server will execute agents faithfully. An agent server can freely stop execution of an agent or transmit the agent to unplanned destinations. Secondly, it is useless to encrypt agent’s code since every agent server will need a plain code format. Of cause, if several agent servers believe each other, they can encrypt agents before transmitting them. If some of agent’s data is not needed during its following migration, it can be encrypted using the sender’s public key. After the agent returns back to the home, the owner can read the data[Far96]. A new approach is to compute with encrypted data[San98]. If this is true, we don’t need to use plain data in agents any more.

Several factors may become the bottlenecks in a large-scale mobile agent environment.

• Network bandwidth. How to minimize the communication resources consumed by agent transfer? Migrating agents and transmitting messages among agents both consume network bandwidth. If a system is characterized by frequently agent movements but small message sizes, we should try to reduce migration times as well as the transmitted code length. Java serialization mechanism provides a basis for many agent architectures to implement agent migration. But this mechanism is not very efficient at present and can be improved in some way. The serialization result is very large and sometime this is not necessary. Some researchers proposed some methods to reduce network traffic, such as using effective format, caching agent class code, compressing the result before transmission. But there is a tradeoff to be made by people. A large amount data will need more network resources but shorter marshalling and unmarshalling time. An effective and sometime compressed format may need less network bandwidth but a much longer marshalling and unmarshalling time.
• Agent Server. If there are thousands of agents in a server, its process power may be saturated. It will be busy at receiving and sending messages, scheduling execution of agents. As a result, it couldn’t accept extra agents any more and cooperate with other agent servers timely. The whole system will become very slow. Just like current Internet at some time. There is also problems related with the organization of agent servers. How to let agent servers know each other? Many agent architectures use some naming and directory services to address this problem. But this is not enough. We should organize agent servers in an efficient way, such as using a hierarchical structure. Besides, the management of meta-data is very important. People should study suitable algorithms for retrieving them in a distributed system. Agent Server will be limited by the available hardware resources in the end. So the real bottleneck is here.

The following two agent architectures are both based on Java. They only support weak agent mobility because when an agent migrates from one machine to another, it can not take all states of it. Suppose an agent calls the move method during execution. When it arrives at the destination, it will not continue execution from the code site after the move method, instead it will execute from the entry point again or its onArrival method will be called. This feature arises out of the architecture of the JVM, which doesn't allow a program to directly access and manipulate execution stacks. This is part of the JVM's built-in security model. So only code and data can be serialized and execution state will be lost. Unless there is a change to the JVM, Java-based agents will be unable to carry the state of their execution stacks with them as they migrate[Ven97].

Aglets was developed by IBM Tokyo Research Laboratory. An aglet is a composite Java object that includes mobility and persistence and its own thread of execution and can communicate with other aglets. Aglets uses a call-back model based on the Java event delegation model. During its life cycle, an aglet receives various events in response to its actions; for example, if it is deactivated to the persistent storage, a persistency event occurs just before the deactivation, and corresponding call-back method, onDeactivating, is invoked. Later, when it is activated from the persistent storage, another persistency event occurs just after the activation, and the call-back method onActivation will be invoked. In this way, an aglet can determine what to do when a specific event happens[Woo99].

An aglet interacts with its environment (its aglet host) through an AgletContext object. Aglets are always executed in AgletContexts. To interact with each other, aglets go through AgletProxy objects. An AgletProxy object acts as an interface of an aglet and provides a common way of accessing the aglet behind it. In this way, an AgletProxy object becomes the shield that protects an agent from malicious agents[Woo99].

The lifecycle of an aglet[Ven97]:

• Created: a brand new aglet is born -- its state is initialized, its main thread starts executing.
• Cloned: a twin aglet is born -- the current state of the original is duplicated in the clone. But the aglet ID is different.
• Dispatched: an aglet moves to a new host -- the code and data go with it.
• Retracted: an aglet, previously dispatched, is brought back from a remote host -- its code and data come back with it. This is used to pull back aglets through a firewall since aglets can’t return themselves.
• Deactivated: an aglet is put to sleep -- its code and data are stored on a disk.
• Activated: a deactivated aglet is brought back to life -- its code and data are restored from disk.
• Disposed: an aglet dies.

The following graph describes the Aglets architecture, which consists of two layers: the Aglets Runtime Layer and the Communication Layer, and two APIs that define interfaces for accessing their functions: Aglet API and Communicaiton API[Osh98].

Aglets model is very simple. To do aglet programming is easy. Messages can have different priorities so that high priority messages will be handled first. It is a desirable feature because some applications like real-time system require messages to be processed as soon as possible. Besides, Aglets has the potential to interoperate with other agent systems because its communication API is derived from the OMG standard, MASIF(Mobile Agent System Interoperability Facility). So if another agent system also conforms to MASIF, it can interoperate with Aglets in theory. Here, we say in theory because MASIF is intended for CORBA, but Aglets doesn’t support CORBA yet. Since Java2 has embedded CORBA support, it is easy for Aglets to support CORBA in its future version.

It was claimed that the AgletProxy interface would provide the aglet with location transparency. But it is not true in Aglets1.0.3. Whenever an aglet moves, a new AgletProxy object will be returned. Using the previous AgletProxy object will not work.

Aglets assumes the communication channel is reliable. So it won’t work in a mobile and often disconnected network. Also Aglets has little security support in the version 1.0.3 and only has a simple security support in the version 1.1. In Aglets1.1, an aglet is authorized based on its codebase and owner.

Aglets has only a limited scalability. From the experiment, we can see an aglet server can hardly hold one thousand agents in it. Though a ResourceManager object will charge the resources used by an aglet, the server lacks of a main resource manager to control the whole system’s resource consumption under a limit.

In Aglets, cooperation between agents is also difficult to be implemented since Aglets has no effective and standard agent interaction protocol.

Luckily, according to the documents from IBM, they developed an electronic marketplace framework, called e-Marketplace, on top of Aglets, to provide a meeting place for agents and define a high-level interaction protocol for interagent communication. The framework also provides a swap-in and swap-out scheduling mechanism to accommodate thousands of consumer agents at the same site. This is a good news. But it is much better if Aglets has such a mechanism itself.

Concordia is a full-featured framework based on Java for the development and management of distributed multi-agent applications. Before an application can be run, the Concordia server should be started on each machine where agents may move there. Concordia consists of eight components[MEIHSL]:

• Agent Manager: It uses TCP/IP to implement the communication infrastructure that allows for agents to travel.
• Security Manager: It protects resources and ensures the security and integrity of mobile agents and their data.
• Queue Manager: It is responsible for the scheduling and guarantied delivery of mobile agents between Concordia servers. It provides for reliable transmission in an unreliable network.
• Directory Manager: It provides a name service for applications and agents such that agents can find services in the network.
• Inter-Agent Communication Manager: This component handles the registration, posting and notification of events to and from mobile agents. It also provides an infrastructure which allows agents to collaborate(i.e. synchronize and share data with each other).
• Persistence Manager: It can save the data and state of agents and other objects in transit around the network. It will periodically checkpoint agents. So it can be used to recover agents and other objects when abnormal events happen such as server crash.
• Agent Tool Library: This library includes all Concordia APIs and agent classes needed to develop agents.
• Administration Manager: This module is a remote administration tool that supports central management of multiple servers.

It pays much attention on security and reliability. Role-based access control is realized to protect resources and mobile agents. So unauthorized mobile agents can not access resources and unauthorized users can not inspect agents’ contents. Concordia also utilize symmetric and public key cryptography to protect agents during their transmission as well as when being stored on disk. Concordia server can authenticate each other by exchanging digital certificates. It uses two-phase commit protocol to transmit agents from one node to another. In case of server or network failures, agents can be recovered through using persistence manager. Concordia also has an agent debugger which helps tracking the progress of an agent throughout the network[Woo99].

• First, agent can be used as a personal assistant. It will help people and alleviate their work. It will learn itself and gradually understand people’s interests, intentions, goals. It will navigate through large amounts of distributed information and organize them in order. In a word, agent should have some intelligence. Some researchers are developing techniques and algorithms in agent decision-making, planning, learning, and collaboration. But it is an issue that has been addressed several decades by AI community without good results.
• The most interesting usage of agent is in E-Commerce. However, without a multiagent negotiation protocols, agent technology can not be successful in such an application field. Most current agent architectures lack a strong communication language. It is hard to codify and convey knowledge about the "business rules" of agent and service interaction.
• Chris Rygaard holds that mobile agent technology is powerful in the embedded world because those are memory-constrained environments. Mobility lets you dynamically swap apps.
• Agent techniques can also be used in automatically industrial control. In the future, when agent need to be upgraded, it is convenient to send a new agent to replace the original one.
• Mobile agent can play a role in the automation of configuration and management of a plug-and-play network[Kin97].
• Agent technologies are suitable for team development, workflow.
• Using agent technology, people can also elongate the life of legacy software. We can use a static agent to serve as the bridge between a legacy program and other agents.

Code migration is not an innovative concept. In fact, people proposed some code migration techniques long long ago. At the beginning, people had to copy their programs to remote machines(remote machines should be large-scale and very fast. They can use ftp or other tools to transmit their programs.). Then they could start their programs on remote machines. In the end, they collected results generated by their programs. All these had to be done manually. Very inconvenient! So people began to look for automatic code migration means. Remote procedure calling(RPC) is the first successful method for distributed computing. RPC is not very efficient because if an application uses multiple RPC calls to do a task, a large number of network bandwidth will be consumed. So three other code migration techniques--process migration, remote evaluation, and mobile objects—were developed later. They have much better performance than RPC. Process migration is to move an entire address space from one computer to another. Remote evaluation programming is to allow one computer to send another computer a request in the form of a program. The remote computer receiving such a request executes the program referenced in the request within its own local address space and returns the results to the sending computer. Mobile objects were based on object-oriented techniques. They could bring data, state information and other embedded objects when they migrated from node to node. These methods all have limits. Process migration did not allow an easy way to return data back to the source node without the entire process returning as well. Remote evaluation could not transmit state information, which is needed for application some time. Mobile objects are very like mobile agents. Only they are not autonomous and the itinerary information is predefined and static[Woo99].

Compared to these earlier code migration techniques, mobile agents are more powerful and more flexible. Mobile agents are proactive and can notice changes in the distributed environment such that they can decide where to go next.

We design the following mobile agent runtime model, which consists of Agent Manager, System Manager, Conversation Manager, Security Manager, Information Directory, Resource Manager, Persistence Manager and Reliable Communication Manager. Their functionality can be describe as the following:

• Agent Manager provides the execution environment for agents. When an agent or its clone is created, Agent Manager will allocate a new thread for it. Each agent will have a unique identifier. The identifier will be generated through combining the magic number of the agent server, a static counter number, and the local address. Agent Manager also set a limit on maximal number of active agents in the system. When the limit is reached, it will let persistence Manager to swap out those waiting or idle agents. To prevent agents from living forever, a time stamp can be used. When an agent will move to another host, Agent Manager will serialize the agent and send the serialized form after encryption to the Reliable Communication Manager. When it receives a serialized form from the Reliable Communication Manager, it will de-serialize the agent and resume its execution.
• System Manager will serve as an interface to the outside world. Other applications can use public methods of System Manager to create, dispatch, and manipulate agents. Besides, System Manager will coordinate with System Managers in other Agent Servers. Several agent servers can form a group. Groups can be embedded into another groups. So they will have a hierarchical structure. Group members may be defined beforehand or created dynamically. Each group will have a leader. When an agent migrates from one node to another, its information will be put in the Information Directory of the group leader.
• Conversation Manager will realize complex interaction among agents. Agent can send a single message to another agent or agents in the same group. Several agents can also talk to each other. KQML will server as the agent communication language.
• Security Manager will protect hosts and agents in an acceptable way. Each agent server as well as application will have a public key. When an agent server wants to interact with another agent server or an application first enters into an agent server, they will authenticate each other. Then their roles will be determined. Resource Manager can ask for the role information about the role of the owner of an agent.

• Information Directory will include several sub directories. One sub directory is for agents to register their meta-information. Agents can advertise their functions, their requirements, and acceptable messages, on the directory. Another sub directory is for managing meta-information of agent servers in the same group. A special flag will denote a group leader.
• Resource Manager will control resource consumption through using role-based access control list. When an agent wants to access a resource, it sends the request to Agent Manager. Agent Manager will first consult Security Manager to get the corresponding role of the agent. Then Resource Manager will be asked to check whether the role can access the resource. If the role has been authorized, the agent can access the resource now. If not, the agent will be denied and deactivated to the persistent storage temporarily. At the same time, System Manager will be notified such a violation event. It can trace where the agent comes and take further measures after getting more information. In addition, it will inform Agent Manager to lower the limit of active agents if resources consumed too much.
• Persistence Manager will cooperate with Agent Manager to control the number of active agents at one time to be lower than a customized value. When an agent is waiting for an event or a message, it will be saved into a persistent storage if the number of active agents has been close to the upper limits. It will be reactivated again when the waited event or message has come. Persistence Manager also checkpoint those agents that has been active for a long time in a fix time interval. In case of host crash, agents can be recovered to the last check point by calling Persistence Manager.
• Reliable Communication Manager will use at-least-once policy to transmit agents. Since each agent has a unique id, when a remote machine receives a second copy, it just ignores it. At the same time, we use the two-phase commit protocol to ensure exactly-once transmission of messages.

When an agent A moves from one machine to another, how to ensure messages delivered to this agent can reach it no matter where it is? One approach is to maintain an agent directory on each machine. Even when agent A leaves the machine, its information is still there. Of cause, the destination address is recorded. Similarly, when the agent A moves again and again, its information is left on each machine it has passed. Next time, if another agent B wants to send a message to the moved agent A, it just uses the address in the agent directory. When the message arrives at the host, its agent server looks for the agent A in its directory and finds it has moved. So it transfers the message to the new address. In the end, the message will reach the agent A since the message travels exactly along the route the agent A has passed. Here, some optimizations can be made. The agent server where A is located currently can send a notification to the original server. So that the original server can modify its agent directory to reflect A’s real site. Or if we divide agent servers into a hierarchy, we can let the group server to manage an agent’s information if it leaves the original server. One problem of such processing is how to notify the original agent sending the message if it requests an acknowledgement. To tell it that A has moved and let it wait for a while? Then how to set a suitable timeout value? Another approach is to just inform the original agent that A is not here and A may be on some place. So if the original agent still wants to communicate with A, it can send another message to the new address. This procedure may repeat some times according to how many hosts A has migrated. Some agents will only have limited lifetime. So we can use a timestamp to delete their information if their lifetime has been over. If an agent is killed instead, its information is not needed any more. The agent server can either multicast a message to other agent servers or just notify an agent server till the killed agent is visited by it. Some malicious agents may set their lifetime very long. In such a way, they will consume large amount of memory and CPU time.

A flat structure to organize a large number of agent servers is not effective because each agent server has to store all other agent servers’ information. Internet has accumulated ample experience on how to manage so many computers. Using a hierarchical structure is its solution. To define domain according to areas, fields so that the whole network is scalable.

We use IBM Aglets to implement a distributed book management system. The databases are located on three machines. When a user wants to retrieve book information, agents will be sent to the machines having the databases to do the retrieval operation and the results will be fetched back by the agents.

The basic functions of the book management system are: Add information, Update information, and Retrieve information. We define three kinds of databases. One for books(BookTab), another for journals(JournalTab), and the third for proceedings(ProcTab). Each database will be on different machines. We store BookTab on the machine Dalmation(137.99.10.203), JournalTab on Labrador(137.99.10.204), and ProcTab on Shepard(137.99.10.202). We use Microsoft Access to design the databases and manage them. We also distinguish different users. Only administrators can append records, delete records and modify records. Other users can only retrieve records from the databases. Originally, we want to use different structures for these tables. Now, for simplicity, the structures of these tables are same. Each has seven fields: id(call ID number), name(of a book or journal or conference), author, pubdate, publisher, category, source(where to get it). Though we fix the database addresses, we permit user to change them at runtime. So we design several interfaces for functions discussed above. Now we will describe them one by one.

This dialog will be popped up when the user starts the Book Management System. We use Microsoft Access to manage user account. Only when the user has a valid account, can he/she use the system. After inputting name and password, press OK to continue. If the input information is not correct or the user press CANCEL, the system will exit.

If the user input correct information, the following dialog will be displayed. Here, append and update functions are enabled because the user is an administrator. If the user is a common user, these two functions will be disabled.

At the beginning, the configure interface will be displayed. The user can toggle to other interfaces through pressing Append, Update, or Retrieve.

Through the configure interface, use can set the location of each database. Remember to add "atp://" before the IP address or hostname. After setting, please press Save to make the new values effective.

When the user is an administrator, he or she can enter the append interface by pressing Append. First, the user can select the database to which records are appended. Each time the user can add one record. Notice: the ID field is the primary key. So two records can’t have the same ID.

The append operation is not very efficient because a new aglet will be sent out to do insertion at the data source whenever the user pushes the Add button to append a new record. Another approach is to buffer these new records and then to dispatch an aglet to the data source to do multiple appending. Of cause, to use RMI to insert records to a remote database will be faster than using an agent. Since the goal is to understand the mechanism of IBM Aglets, we don’t care performance very much.

We use JDBC to access the databases. So two options need to be checked in Tahiti server. Choosing Options->Security Preferences, a dialog will be displayed. Please check the "Enable JDBC" for both trusted and untrusted aglets.

We define a SuperAglet(see SuperAglet.java) to do the insertion operation at the data source. In fact, this aglet can also perform deletion or modification at the data source.

When the user is an administrator, he or she can enter the update interface by pressing Update. First, the user can select the database to be updated. The user can browse records of a database one by one. The next/previous record can be displayed by pushing Next or Previous. Currently we don’t support random record browsing. User can delete or modify current record displayed in the window.

The performance is not very efficient because during update operation, to display one record needs to send an aglet to the database server. At the beginning, I thought JDk1.1.8 would have a strong database access support. It’s not a fact. In JDK1.2, the class ResourceSet has the similar functionality like the Cursor in many database systems. User can use it easily to retrieve previous or next record, modify a record, or delete one. But in JDK1.1.8, user can use the ResourceSet to retrieve next records only. It can’t be used to do anything else. An alternative approach is to fetch many records to the local and either save them in a local temporary database or in memory. Then browsing, deletion and modification can be done locally. Only when a record not in local is requested, an aglet with current buffered records is delivered to the data source again. This aglet will come back with another block of records. This method can improve performance somewhat. Of cause, many large-scale DBMSs such as Oracle and SQL Server have been based on the Client/Server model. So when a client wants to access a remote database record by record, he/she won’t feel the difference compared to local access, just using the cursor handle returned by the server.

First, user can select the database to be searched. User can search information in one database or in all databases. At present, user can designate two search conditions. These two conditions can be an AND or OR relation. Each condition will be related to one field. The search results will be displayed in another window(ListWin.java).

When user wants to search all databases, the execution needs more time since the databases are on different machines. But an agent is suitable to do the search operation, especially when the initial data set is very large and the result set is relatively small and the initial data set is located in different places. In the project, we define another aglet "SearchAglet" to do the search operation at the data source.

The results are displayed in another window as the following:

In the Appendix, the source code of the project is given. Please refer to there for more details.

In this paper, we review current research work on agent technologies and discuss some issues related with agent technologies. Currently, there have been a number of agent architectures. On one hand, their functionality is still rudimentary. So their potential benefits must be weighed against the risks they pose. If these issues are not solved, their usage will be limited. On the other side, they are not interoperable. Even though we don’t want them to accept agents created by other systems, we still hope them to understand messages send by other systems. To realize the goal of running agents everywhere, agent software vendors need to standardize the agent architecture. This is very difficult at present. Some people are trying a new approach that provides a mobile agent mechanism in the operating system level. But at least, we can design an interoperable and extensible agent communication protocol.

In this project, we implemented a book management system using IBM Aglets1.0.3. Aglets is very simple and easy to use. However, its functionality is very basic. Aglets1.0.3 almost has no security control. Aglets1.0.3 doesn’t scale well. Fortunately, IBM has noticed these issues and made some improvements on Aglets1.1 as well as another project, Tabican. Through using Aglets1.0.3, we feel testing and debugging agents are not easy. So how to test and debug agents during the development phase? If agent architecture can include a simulation environment, then it is easier to develop agent-based systems. In the system, we insisted on using agents to access databases since we want to use Aglets. However, agent technology should not exclude other mature distributed techniques. A practical agent architecture should support existing distributed computing techniques. Sometimes using an RMI call is more efficient than sending an agent.

In the future, agent technology will play a key role in economy. We researchers should do our best to solve those issues that block the broad applications of agent technology.

[Abd98] Abdul-Fatah, I., Majumdar, S.: Performance Comparison of Architectures for Client-Server Interactions in CORBA, in the 18^th International Conference on Distributed Computing Systems(1998), Amsterdam, The Netherlands, 1998, pp. 2-11 (Conference Paper).

[Ari98] Aridor, Y., Lange, D.B.: Agent Design Patterns: Elements of Agent Application Design, in the Second International Conference on Autonomous Agents(Agents’98), Minneapolis, MN, 1998, pp. 108-115 (Conference Paper).

[Bel99] Bellavista, P., Corradi, A., Stefanelli, C.: A Secure and Open Mobile Agent Programming Environment, in the Fourth International Symposium on Autonomous Decentralized Systems, Tokyo, Japan, Mar. 1999, pp. 238-245 http://www-lia.deis.unibo.it/Software/MA (Web Site).

[Bra97] Bradshaw, J.M: An Introduction to Software Agents(Web Site), in J.M. Bradshaw (Ed.) Software Agents, AAAI/MIT Press, 19997, pp. 3-46.

[Bre98] Breduin, J., Kotz, D., and Rus, D.: Market-based Resource Control for Mobile Agents, in the Second International Conference on Autonomous Agents(Agents’98), Minneapolis, MN, 1998, pp.197-204 (Conference Paper).

[Far96] Farmer, W.M., Guttman, J.D., Swarup, V.: Security for Mobile Agents: Issues and Requirements, in the 19^th National Information Systems Security Conference(1996), Baltimore, MA, 1996, pp. 591-597 http://csrc.nist.gov/nissc/1996/papers/NISSC96/paper033/SWARUP96.PDF (Web Site).

[Gen94] Genesereth, M.R.: Software Agents, Communications of the ACM, Vol. 37, No. 7, Jul. 1994, pp. 48-53(Journal Paper).

[Gre98] Greenberg, M.S., Byington, J.C., Harper, D.G.: Mobile Agents and Security, IEEE Communications Magazine, vol.36, no.7, July 1998, pp. 76-85(Journal Paper).

[Has98] Hashii, B., Lal, M., Samorodin, S., and Pandey, R.: Securing Systems Against External Programs, IEEE Internet Computing, Vol. 2, No. 6, Nov./Dec. 1998, pp. 35-45 (Journal Paper).

[Hay99] Hayden, S.C., Carrick, C., Yang, Q.: A Catalog of Agent Coordination Patterns, in the Third International Conference on Autonomous Agents(Agents’99), Seattle, WA, 1999, pp. 412-413 (Conference Paper).

[He98] He, Q., Sycara, K.P., and Finin, T.W.: Personal Security Agent: KQML-Based PKI, in the Second International Conference on Autonomous Agents(Agents’98), Minneapolis, MN, 1998, pp.377-384 (Conference Paper).

[Hoh98] Hohl F.: Mobile Agent Security and Reliability, in the Ninth International Symposium on Software Reliability Engineering, Nov. 1998, Paderborn, Germany, http://dlib.computer.org/conferen/issre/8991/pdf/89910181.pdf (Web Site).

[Ism99] Ismail, L., Hagimont, D.: A Performance Evaluation of the Mobile Agent Paradigm, in OOPSLA’99, Denver, CO, 1999, pp. 306-313 (Conference Paper).

[Jas97] Pastor, J.A., Taylor, S.L., McKay, D.P., McEntire, R.: An Architecture for Intelligent Resource Agents, in the Proc. Of the 2^nd IFCIS International Conference on Cooperative Information Systems(CoopIS’97), Kiawah Island, SC, 1997, pp. 151-159 (Conference Paper).

[Kar97] Karjoth, G., Lange, D.B., and Oshima, M.: A Security Model for Aglets, IEEE Internet Computing, Jul/Aug. 1997, pp. 68-77(Journal Paper).

[Kin97] Kiniry, J., Zimmerman, D.: A Hands-On Look At Java Mobile Agents, IEEE Internet Computing, Jul/Aug. 1997, pp. 21-30(Journal Paper).

[Lab99] Labrou, Y., Finin, T., and Peng, Y.: Agent Communication Languages: The Current Landscape, IEEE Intelligent Systems, Mar./Apr. 1999, pp. 45-52 (Journal Paper).

[Lej96] Lejter, M., and Dean, T.: A Framework for the Development of Multiagent Architectures, IEEE Expert, Dec. 1996, pp. 47-59(Journal Paper).

[Meh98] Mehra, A., Chiodini, V.: An Integrated Development Environment for Distributed Multi-Agent Applications, in the Third International Conference on Multi Agent Systems ’98, Paris, France, 1998, http://computer.org/proceedings/icmas/8500/8500toc.htm#85000451, (Conference Paper).

[MEIHSL] Technology at a glance: Concordia—Java Mobile Agent Technology, Mitsubishi Electric ITA Horizon Systems Laboratory, http://www.meitca.com/HSL/Projects/Concordia/Concordia-at-a-glance.html (Web Site).

[Mus98] Musa, J.D.: Software Reliability Engineering for Mobile Code, in the Ninth International Symposium on Software Reliability Engineering, Paderborn, Germany, Nov. 1998, http://dlib.computer.org/conferen/issre/8991/pdf/89910182.pdf (Web Site).

[Osh98] Oshima, M., Karjoth, G., Ono, K.: Aglets Specification 1.1 Draft, http://www.trl.ibm.co.jp/aglets/spec11.html (Web Site).

[San98] Sander, T.: Protecting Mobile Code, in the Ninth International Symposium on Software Reliability Engineering, Paderborn, Germany, Nov. 1998, http://dlib.computer.org/conferen/issre/8991/pdf/89910183.pdf (Web Site).

[Sos97] Soshi, M., Maekawa, M.: The Saga Security System: A Security Architecture for Open Distributed Systems, in the 6th IEEE Workshop on Future Trends of Distributed Computing Systems (FTDCS '97), Tunis, Tunisia, 1997, http://www.computer.org/proceedings/ftdcs/8153/8153toc.htm (Web Site).

[Str99] Strippgen, S., Peters, K.: "The other way round!"—Collaborative Communication with Agents, in the Third International Conference on Autonomous Agents(Agents’99), Seattle, WA, 1999, pp. 108-115 (Conference Paper).

[Tah99] Tahara, Y., Ohsuga, A., Honiden, S.: Agent System Development Method Based on Agent Patterns, in Proceedings of the 1999 International Conference on Software Engineering(ICSE'99), Los Angeles, CA, 1999, pp. 356-367 (Conference Paper).

[Ven97] Venners, B.: Under the Hood: The architecture of aglets, Javaworld, Apr. 1997, http://www.javaworld.com/javaworld/jw-04-1997/jw-04-hood.html (Web Site).

[Vog97] Vogler, H., Kunkemann, T., Moschgath, M.-L.: An Approach for Mobile Agent Security and Fault Tolerance using Distributed Transactions, in 1997 International Conference on Parallel and Distributed Systems (ICPADS '97), Seoul, KOREA, 1997, pp. 268-274 (Conference Paper).

[Won99] Wong, D., Paciorek, N., and Moore, D.: Java-based Mobile Agents, Communications of the ACM, Vol. 42, No.3, Mar. 1999, pp. 92-102 (Journal Paper).

[Woo99] Wooldridge, M.J., Jennings, N.R.: Software Engineering with Agents: Pitfalls and Pratfalls, IEEE Internet Computing, Vol. 3, No. 3, May/June 1999, pp. 20-27 (Journal Paper).

[Yam99] Yamamoto, G., Nakamura, Y.: Architecture and Performance Evaluation of a Massive Multi-Agent System, in the Third International Conference on Autonomous Agents(Agents’99), Seattle WA, 1999, pp. 319-325 (Conference Paper).

Appendix: Source Code of the Book Management System: prjsrc.htm