This paper describes the design and implementation of the Mobile Objects and Agents (MOA) project at the Open Group Research Institute. MOA was designed to support migration, communication and control of agents. It was implemented on top of the Java Virtual Machine, without any modifications to it. The initial project goals were to support communication across agent migration, as a means for collaborative work; and to provide extensive resource control, as a basic support for countering denial of service attacks. In the course of the project we added two further goals: compliance with the Java Beans component model which provides for additional configurability and customization of agent system and agent applications; and interoperability which allows cooperation with other agent systems. This paper analyzes the architecture of MOA, in particular the support for mobility, naming and locating, communication, and resource management. Object and component models of MOA are discussed and some implementation details described. We summarize the lessons learned while developing and implementing MOA and compare it to related work. Mobility has always attracted researchers in computer science. This interest spans from general observations, such as "if it weren't for mobility, we would still be trees" [10] , and the analogies with the real world "migrating birds and nomadic tribes moving due to the lack of resources", to purely technical reasons, such as improving locality of reference and difference between local and remote semantics. One of the first incarnations of software mobile entities. is worms [30] , which could spread across nodes and arbitrarily clone. Unrestricted implementations of worms and viruses have received negative connotations, due to security breaches and denial of service attacks [13] . The next generation of mobile entities, known as process migration, were implemented at the operating sysThis work was supported in part by the Advanced Research Projects Agency and the Rome Laboratory of the Air Force Materiel Command. tem (OS) level. There were many implementations of process and object migration [3, 12, 19, 31] , but none has achieved wide acceptance. Due to inherent complexity, it was hard to introduce process migration without impacting the stability and robustness of the underlying OS. Mobile objects and agents have attracted significant attention recently. In addition to mobile code (such as applets), agents consist of data and non-transient system state that can travel between the nodes in a distributed system (intranet or Internet). Compared to mobile objects, mobile agents also represent someone; they can perform autonomous actions on behalf of a user or another agent. This paper describes the Mobile Objects and Agents (MOA) project at the Open Group Research Institute. The obvious question is why yet another mobile agent system? There were a few reasons. None of the existing systems at the time of starting the project were mature enough to be used as a starting point for our work. We found it easier to develop another system that would suit our needs from the beginning. Additionally, some areas of our interest, such as communication and resource control, are deeply involved in the design decisions of any system, making it very hard to add them as an afterthought. Finally, we were interested in interoperability between the systems, and therefore supporting another implementation was a good idea. At the beginning of the project we were interested in the first two of the four features listed below, and during the course of development we added the last two: Collaboration. Frequently, agents need to collaborate during their execution either with other agents or their user. For agent collaboration, it is required to support naming, locating and communication among agents. Denial of service attacks. Agents, as well as hosts, are vulnerable to mutual attacks, either over a network or locally. In order to prevent denial of service attacks, it is required to maintain resource control of agents and agent systems, and to impose security and resource policies. It is increasingly difficult to configure and customize software. In the case of mobile agents, this applies both to agent applications, as well as to agent systems. Being compliant with a component model, such as Java Beans, allows for a standardized way to access and change component properties. Interoperability. Agents, as well as agent systems, need to interoperate. In the case of agent systems, interoperability leads to a larger base that agents can visit. We were active in the OMG Mobile Agent Facility proposal which addresses mobile agents systems interoperability [26] . More details on how these goals have been achieved is described in Sections 4.3, 4.6, 4.2 and 4.10 respectively. The rest of this paper is organized as follows. In Section 2 we provide a background on mobile agents and component-based computing. Section 3 describes Java's suitability for mobile agents and for component-based computing. Section 4 presents the MOA design and implementation. Section 5 discusses MOA current status. Section 6 describes some MOA applications. In Section 7 we present lessons learned while designing and implementing MOA. MOA is compared to related work in Section 8. Finally conclusions and future work are presented in Section 9. In this section, we provide background on mobile agents and component-based computing. Among the benefits of mobile agents we would like to underline the following. Improving locality of reference is achieved by moving the action towards the source of data or other end point of communication, resulting in substantial performance improvement. Survivability: similar to nomadic tribes or migratory birds, agents can survive if moved closer to resources, or away from partially failed nodes. Analogy to the real world helps some programmers to better understand programming paradigms expressed in terms of mobile agents. Examples are travelling salesman, shoppers and workflow management systems. Customization of software can be achieved using mobile agents, for example, by adjusting the search according to a user-specific criteria, or by performing an action specific to a remote site. Autonomicity represents agent's independence from its owner. A user can start an agent to act on his behalf and disconnect. When the user reconnects, the agent returns or otherwise provides results. Agents have various areas of deployment. One is slow and unreliable links, such as radio communication, where locality of reference improves performance, and avoids potential loss while transferring large amounts of data. Software distribution becomes increasingly hard. Mobile code has provided a revolutionary breakthrough, by allowing downloading code for heterogeneous environment. Mobile agents makes this effort even easier, by associating actions and state with each distributed version and copy of a particular software. Network management: agents migrate both code and data, making them useful for automating control and configuration in large scale environments, such as networks [15] . Electronic commerce deploys mobile agents by modeling travelling salesmen or shoppers visiting stores in an electronic mall. Data mining is a convenient application for mobile agents due to locality of reference: agents optimize a search by wandering from site to site with large volumes of information. (See [7] for additional benefits.) Nevertheless, mobile agents still haven't achieved wide acceptance. Some of the reasons include the following. Lack of applications: mobile agents have achieved a reputation of "the solution searching for the problem". Many systems have been developed but few applications exist. Security: the problems caused by mobile code are frequently reported. Mobile agents push the security problems even further. Lack of infrastructure adapted for mobile agents, such as name servers, messaging systems, and management, is still not widely deployed. Survivability is both a benefit and a challenge for mobile agents. Mobile agents are inherently survivable, but this does not come free; they need to be designed and implemented for survivability. In particular, they should minimize residual dependencies on previously visited nodes, or servers. Component-based programming, including OpenDoc, VBX, and ActiveX, has been quite successful in speeding the development of GUI applications. Java Beans (components written in Java), are promising for non-GUI component programming. The runtime behavior of a Java Bean is defined by an ordinary Java class. The difference between a bean and other objects is the metadata used for configuration. It is provided by an associated BeanInfo class, or it is derived from the runtime class. Component-based programming enhances object oriented benefits, such as flexibility, and code reuse with two new characteristics: independence and configuration. Independence. The source code defining a component does not directly reference any other component; instead, relationships between components are created at runtime. The relationships may be established by the container holding the components, or even by the component itself. This has several benefits: • a "building block" approach: programs are constructed from existing components by defining relationships • each component can be individually tested • components are more easily reused; there is a minimum of interdependency between components • a program can be restructured for new requirements without impacting the logic of individual components • updating a program with the latest version of 3rd party components is simplified  We have chosen Java because it seemed to be the mainstream programming language, but also because of the features that make it suitable for mobile agents and components. Java offers advantages for mobile agents, as well as some disadvantages. Advantages consist of the support for mobile code, heterogeneity, language safety, object serialization [28] , reflection, dynamic class loading, and multithreading. Disadvantages consist of inadequate support for resource management (e.g. memory and disk limits), no support for preserving the thread execution context, limited support for versioning, no ownership of objects and fine grained protection at the object granularity [21] . Components written in Java are lightweight and little code is required for conformance to the component model. Java supports a number of key features of component programming: • A component may have several interfaces. Java provides for the implementation of multiple interfaces, unrestricted casting, and an instanceof operator to determine if a component supports an interface. • Several components may be aggregated into a single component. The JDK 1.1 methods Beans.isInstanceOf and Beans.getInstanceOf can be used in place of the instanceof operator and casting, allowing for the future use of aggregation in JDK 1.2. • The life of a component may span more than one program. JDK's provision for serializing components allows converting an object into a form which can be written to a disk file or passed across a network. • A component is configured by modifying its properties identified by examining the method signatures of the component, e.g. the class is recognized as having the property slices, if the methods getSlices and setSlices exist. • The component's properties are accessed using the class Introspector. The MOA architecture is presented in Figure 1 . There are three types of nodes that run MOA system: front-end node allows users to control and monitor agents; home node is used as a repository for agent's data; and remote node is where agents typically run throughout their life time. name server tracks the location of agents and other objects, whereas a monitor serves for controlling and monitoring objects. These and other objects in the MOA architecture are described in more detail in this section. The MOA objects on remote nodes can be classified as agent-or system-related (see Figure 2) . Agent-related objects are circled; they have migratory state. Agent and place belong to the user trust domain (see Section 4.7 on more details related to security), whereas other components belong to the MOA trust domain. An agent and place are application extended classes. Agent is the first class MOA object. It is a template class extended by agent applications. Agents are named (see Section 4.4), and they can communicate (see Section 4.3). An agent can move to an agent environment (or a place within it), it can request to meet other agents at a certain place or agent environment, openChannel to another agent, or sendMessages to it. An agent always executes within a place (see below). There is a one-toone mapping between an agent and a place within an agent system. However, an agent can leave places behind when it moves. Therefore there is one-to-many mapping between an agent and places on different agent systems. Place is the second class MOA object. The main difference from agent is that place is a stationary object, and therefore it can not move or meet. However, places can communicate with other places and agents; they can be active, i.e. they can have threads running. Place also serves the container-proxy role. They are proxies because they can remain after an agent leaves and represent it there (be proxy). They serve the container role for security and resources of an agent. Agent Control, Agent Properties, Family, LogService and Bucket are agent-related classes that belong to the MOA trust domain. Agent control is an internal class that represents an interface between agent system and agent/place. It manages agent system resources (communication channels, agent properties, etc.). These objects can be accessed by an agent/place, but they cannot be changed. AgentProperties contains the properties that characterize agents and are transferred across the nodes. Examples are owner, home Agent Environment, and locatingStrategy. Family is used for monitoring agent activities. Each agent has its own Family object which it carries across migrations. LogService manages local logs. Bucket holds the contents of a JAR file (JAva aRchive). Each bucket implements a classloader for the dynamic loading of the jar file. A hashtable contained within a bucket enables the client of a bucket to efficiently index into the contents of a jar file. During migration, components circled in Figure 2 (except for Place and Agent Control) are serialized, put into the bucket and sent to destination node. Policy and Negotiator objects maintain and manage information about resources. Policy is a placeholder for properties describing the policy of an agent arriving at a node (agentPolicy), and a host receiving the agent (hostPolicy), such as agent's maximum lifetime, maximum number of channels and maximum threads. Negotiator performs negotiation between the agent and the receiving agent environment prior to agent's visit. Agent movement is subject to resource requirements and security arrangements between the two entities. Sandbox and Agent Environment provide basic infrastructure. Sandbox class separates the agent application from the agent system state. It switches from the agent system thread to application thread when there is a different protection domain; it also serves to switch from synchronous to asynchronous communication when going across the network. Resource usage and limits are tracked on a per sandbox basis. AgentEnvironment (AE) is the container for agents and their related objects at an agent system. There is one agent environment per Java Virtual Machine (JVM), but there can be many per a node. Each agent has its home AE and alternate home AE in case the home is not accessible. The Messenger layer uses the services of Net to support one-and two-way messages between components. Components are addressed using destination agent system and the component name. Name server tracks agent locations. The name server clients can (un)register and lookup an agent location. Name server clients are user (monitor) and agents that lookup locations of other agents in order to communicate. Information about the agent location (or how to find it) is cached at agent systems that the agent visited or communicated with. Name server also plays the Locator role. Mover, Monitor and Logger provide MOA services. Mover supports agent movement. It negotiates migration, captures the agent state, and transfers it. Monitor provides a user interface to control and monitor applications (e.g. agent's movement, communication and resource usage). Logger logs events in an Agent System to persistent media. MoaApplet, BatchDriver and User classes support the interface to the MOA system and its applications. MoaApplet is an applet-based interface enabling users to interactively monitor and debug agents, to launch them, to snapshot the agent's state, and to query the logged data. BatchDriver is a script-based user interface to provide the services of MoaApplet; typically it is used for testing purposes. User class serves as an interface between the user applet and the agent. It launches the preconfigured agents, tracks the agents, and maintains information of interest to a user. MOA components are configured using the MOAbatch tool (see Section 5). The components configuration defines the system object tree. The MOA system is loaded by first loading the root component. Each component then successively loads the component below it in the tree. Components are locally organized into a labeled tree (see Figure 3) used to dynamically establish relationship between the components, in contrast to static binding, typical of OO programming. After the components have been loaded, they can locate other components of the agent system by name in order to establish dynamic binding. Non-leaf elements of the object tree subclass the environmentChild class (see Figure 4 ) which provides methods for locating a tree element given a relative or full pathname. For example, any component in Figure 4 can access the Mover object by calling the method: getEnvironment().getInstanceOf("/Mover",Mover.class) Coupling of components to a certain extent negates the benefits of component programming, and as such it has been kept to a minimum. For example, the net component is made known to other components, such as those that subclass NetUser: AC, Messenger and arbitrary applications using Net. We have successfully used components for preconfiguring agent applications, as well as the agent system. For agent applications, we can easily preconfigure an agent's itinerary, policy, types of logging, debugging, etc. Agent system configuration specifies which components will be integrated into the tree. For example, homeService is not present on all agent systems, and agent environment is not needed on the front-end and on the home node. Debugging can be specified as a part of the agent system configuration at class granularity. Message timeouts can be configured on a component basis. For the Net component we specify its port number; for each agent, we specify the number of service threads for each agent; Killer component's property includes time when it will take the system down; for each user, we specify the password, login id and login time; for each system, we specify the host policy for negotiating with agents. Components can also be organized using subcomponents. For example, AC is an aggregate which includes AcChannelMgr and AcMsgUser. Only AC is configured into the whole system. This way configuration is simplified using a hierarchical structure. The MOA components of a remote system and their properties are presented in Figure 5 . The MOA communication is built on top of JVM sockets. It provides a higher level of abstraction, such as the channels and messaging between MOA objects (agents, places and servers). The communication channels support object streams. Messaging provides for passing objects of arbitrary type specific to the application. The Net package supports opening of channels with automated retry. The destination system can optionally reject a request for the channel subject to resource limitations. This can happen at the agent system, as well as at the application level. When opening a channel to an agent, only the agent name needs to be specified. The agent system resolves the actual agent location with the help of Locator object in a distributed manner. The Message package is able to pass application specific objects by delaying deserialization until the name space of destination is identified. Messages can be synchronous (RPC-like), or asynchronous (one-way messages). Messaging is built on top of the Net package, using a common pool of channels dedicated to message passing. The destination of messages can either be a specific location (destination name, host and port), or a logical name (e.g. agent name) in the case where the destination is a migrateable object. This is reflected in the implementation, where a layered approach is applied by building the Locator on top of the Message layer which builds on top of the Net (see Figure 6 ). The Locator handles transparent routing of messages when a location is not specified. It enables the agents to transparently communicate and collaborate with each other by using the name of the agent. The Locator relies on the locating strategies described in Section 4.4 to find new agent location. In the case of two way messages, responses are routed back to the originating thread, which is suspended pending either a response or a time out. A response can arrive from the node other than the original destination, if the destination agent moved. While moving from one node to another, the agent does not notice that its channels have been closed and reopened on the remote node. When the transfer is initiated, the channel migration process is performed first. During this process, the agent informs its collaborating partners of its intent. From this point onwards, the data received on the channels is not passed to the application, but is stored in a Vector of unread Objects. Upon learning about the move, the agent channel manager on the other end of the channel replies back an acknowledgment and closes the channel socket without informing the application. For the migrating agent, when the acknowledgment is received on a channel, the Reader thread for the channel is stopped, and the socket is closed. The agent transports itself to a new location, only when the migration process is completed for all open channels. During channel migration, though the socket is closed, the information regarding the other communicating agents/places is still maintained. When the agent moves, it carries along the information about the channels, and uses it to reopen channels at the new location. Prior to reopening channels it first sends all the unread objects to Debug (List of components being debugged) AE (agent application components)
For instance, Mobile Objects and Agents (MOA) REF supports four schemes for locating agents; these are used as required to deliver location-independent messages.
Mobile Objects and Agents (MOA)
IN PROC. OF THE FOURTH USENIX CONFERENCE ON OBJECT-ORIENTED TECHNOLOGIES AND SYSTEMS (COOTS ’98
Computer Science