Eagentpluginarchitecture

IEEE Integration of Knowledge Intensive Multi-Agent Systems (KIMAS-05), Waltham, MA, April 18-21, 2005E2 Agent Plugin ArchitectureMinh Vu and Craig ThompsonComputer Science and Computer Engineering DepartmentUniversity of Arkansas, Fayetteville, AR 72701, USAmvu, cwtuark.eduAbstract E2 is a plugin-based, service-oriented middleware architecture. E2 extends the popular Eclipse platforms idea of building a software system entirely and dynamically from XML-interfaced plugins, adds the feature to remove and replace plugins on the fly, administers the plugin connection process, and provides a message transport plugin for distributed inter-E2 system communication. E2 introduces a generic user interface plugin that separates user interfaces and application functionality. With these extensions, E2 extends the plugin concept, with its success on the desktop, to the broader areas of distributed middleware and multi-agent systems. E2 retains compatibility with Eclipse so that it can reuse Eclipse plugins but also, via an extensible interpreter capability, adds compatibility with Web Services and WSDL. This paper describes the E2 platform, implemented in Java, being used to develop the Everything is Alive agent system.1. Motivation and BackgroundFor some years, we have been developing a vision of pervasive computing that will rely on agents. Everything is Alive (EiA) is a vision of the coming Internet of Things where computing is pervasive and everything is alive that is, a world where common objects, including inanimate and abstract ones, can have individual identities, memory, processing capabilities, and the ability to communicate, sense, monitor, and control their own behaviors 1.Our earlier work on agent system architectures resulted in the Egents system 2, developed as part of the DARPA Control of Agent-based Systems Program, and the Small Unit Operations (SUO) agent system 3, 4 developed for Rome Labs. Egents demonstrated XML-based message formats and a scalable message transport based on email. SUO added agent ontologies, agent simulations, and the ability to send a role assignment to generic agents to specialize them to become rangers, sensors, robots, etc. Externally, Egents and SUO agents were modular but it was still a “small matter of programming” to build new agents or add capabilities to agents that is, there was a need for an internal architecture for agents.To realize the EiA vision requires the ability to scale agent systems in several ways. First, there will be many (at least thousands, maybe millions) of kinds of agents; second, it must be possible to assemble agents quickly from component capabilities; third, agents so assembled must be able to interoperate with each other and with other widely available middleware; and finally, agents need to be able to evolve over time. In the Egents system, agent role was hard-coded. In the SUO system, a Command Post agent sent individual generic agents a message that turned on or off capabilities already programmed into the agent. All agents were similarly capable but differentiated by their role assignment. Neither scheme was scalable. What we required was a modular scheme that could represent an agent as a collection of capabilities that can be dynamically discovered and downloaded to an agent (plugins) or accessed remotely (services). Capabilities could be added, removed, or replaced. In looking for other systems with these properties, we reviewed service-oriented architectures (CORBA, Java, and web services) as well as plugins in Mozilla and Netscape browsers, Adobe Photoshop, Macromedia Dreamweaver, and also the DARPA Cougaar agent system. One framework was especially appealing the open source Eclipse Platform (eclipse.org 5), which has developed a plugin development environments (PDE) for the purpose of developing integrated development environments. Eclipse was appealing because it provided a library of plugins and used XML interfaces to define modularity boundaries, providing a scheme for dynamic loading and also the advantage of late binding among interfaces.Eclipse met our requirement for modular plugins and dynamic loading but did not meet all our requirements. It was not possible to unplug plugins, a capability we needed so we could evolve (add, remove, or update) plugins in running agents. Also, Eclipse downloads plugins to a single JVM. We wanted a distributed collection of agents (potentially many agents per JVM and many JVMs) and also we wanted to be able to send messages in XML between agents. Finally, we wanted to take advantage of Eclipses increasingly broad acceptance and its plugin libraries as well as to be able to seamlessly access remote XML resources written in other protocols, especially web services using WSDL, SOAP, and UDDI to take advantage of the even faster growing collection pool of remote services that agents could also use. Of course, we also wanted high performance, understandability, and maintainability.To meet these requirements, we developed the E2 Platform (derivative of Eclipse), remaining upwards compatible with Eclipse but also adding the additional features to add, remove, or update plugins dynamically; support multiple agents running in one or multiple JVMs; and access remote services via messages, interoperable with web services and other protocols. Where Eclipse is designed for building integrated development environments, E2 generalizes Eclipse to be useful as a general service-oriented architecture platform that can be used in a variety of middleware applications. In this paper, we focus on using E2 to develop an agent integration environment where agents, composed from a set of plugins, can live, die, communicate with each other or users, share resources and carry out tasks together. In E2, XML is not only used as an interface for specifying plugins and how to combine them together but also for agents to communicate with each other. Also, an E2 plugin can have multiple interfaces and each interface can be used by multiple interpreters, which makes this architecture additionally flexible. One of the direct results is Web services with their WSDL interfaces can be treated as plugins, albeit their implementations remain remote.3. E2 ArchitectureFigure 1 shows the architecture of E2. The E2 Platform is implemented in three layers: a class loader layer, an extension layer, and plugins themselves, including generic user interface plugins and message transport plugins. The loader layer manages plugins: a plugin and plugin resource is loaded when any agent needs one, and released when no longer needed. The loader layer uses XML metadata associated with plugins to determine which plugin to load. Building on the loader layer is an extension layer where plugins are connected to form an agent. Each agent maintains of XML registry of its plugins. The extension layer relies on the loader layer to load plugins and resources that it need. The generic user interface relies on the extension layer to connect UI plugins and functionality plugins. The message transport plugin facilitates sending and receiving messages between agents. Loader Layer(Classloader Tree, XML metadata interpreter)Extension Layer(Extensions, Extension Points, XML interface interpreter)Generic UI PluginMessage Transport PluginPluginsXML interface+XML metadataAgents(XML registry)Figure 1. E2 PlatformE2 Loader LayerUsually, when running a Java program, Java classes are loaded by the Java System Class Loader (system loader) into the Java Virtual Machine (JVM). Classes then cannot be unloaded from the System Loader unless the JVM is terminated. Java provides the ability to define a custom loader to replace the system loader in order to load classes from many sources, impose security on class loading, and unload classes by disposing of the loader that loads them. Custom class loaders are useful for long-running servers or browsers which load and run many classes but may need to unload or update some of them later. This capability is useful for multi-agent systems too, because many times, long-running agents must be able to evolve. The ability to unload classes also saves resources. In E2, a tree of loaders, similar to that of some Java servlet servers, is used to manage plugins: update, load and unload them on demand (Figure 2). The main function of the tree is to load plugins via separate E2 Plugin Loaders.The loader tree is built by skim reading plugins XML interfaces and dedicates a plugin loader for each library declared. Library declaration consists of a package and relative path to its binaries. As a result, each plugin loader only loads certain packages. No classes are loaded into two different plugin loaders. Also, because the loader tree knows exactly which plugin loader loads which packages, it can quickly chose the right class loader and the right binary to load instead of reading the manifest of all the .jar files in the class path. This reduces the time to find a classs binary significantly, especially when plugins are distributed over the net.The loader layer is provided with several administrative tools. Screenshot 1 shows a Java program which connects to the loader layer and tells the loader tree about an available plugin. The command add with a parameter that specifies the location of a new plugin tells the loader to read the metadata for that plugin (if it exists) and make it available for all agents to use. The remove and update commands will unload or reload plugins in the loader tree. The loader layer also provides a number of debug commands so that the user can tell the loader tree to print (or not print) debug information including warnings errors, logs, classes loaded. Other commands can be added to the loader layer as plugins. The command shell is also used for extension layer administration. For example, the invoke command with parameters that are names of plugins will build and run a system from those plugins. This administrative environment enables controlling and monitoring the platform and testing new features such as multiple interfaces and multiple interpreters.The E2 loader layer is mostly transparent to the E2 extension layer because the loader will automatically load classes which are needed at runtime and unload classes when no longer needed. Users and/or agents can interact with the loader layer for debugging purposes or to manually command the loader tree to look for more available plugins or update existing one. E2 Loader Manager(Plugin Registry)E2 Plugin LoaderE2 Plugin LoaderE2 Plugin LoaderJava System LoaderFigure 2. Loader TreeScreenshot 1. E2s Custom Class Loader Command Line InterfaceThe loader layer also provides the ability to integrate plugins of different languages. The loader layer can also be implemented for C or .NET for a C or .NET platform. At present, the Java version of the loader layer is robust and stable enough to sustain plugin development by others sub-projects in the Everything is Alive project.E2 Extension LayerThe E2 Extension layer reads XML interfaces of plugins and combines them into agents. E2 use XML Schema and concepts from Eclipse XML interfaces in which plugins are connected to each other through extensions and extension-points. For example, plugins H0, H1 (host plugins) declare an extension-point and other plugins P0, P1, P2 declare extension to that extension point and provide extended functionality which H0, H1 can load and use on demand at run time. This mechanism is similar to plugins in Mozilla or Photoshop but is more flexible: there may be many host plugins instead of one and plugins can plug into many host plugins. The extension mechanism is also more dynamic: any plugins can provide extensions for others and itself. The architectural representation of the collection of Eclipse and E2 plugins is a graph which can have edges connecting any pair of nodes instead of a tree representation of classic plugin architectures. The extension layer provides an Agent Launcher, a GUI shown in Screenshot B, where the left column shows available plugins and the right column lists selected plugins. When a plugin A is selected from the available list, all the plugins that provide extension to any extension-point declared by A are made available also. When Launch Agent is pressed, the selected plugins are connected together according to their extension and extension-point declaration and an agent is launched.Screenshot 2. Extension Layer Agent LauncherBuilt-in E2 PluginsGeneric User Interface (GUI) Plugin The GUI plugin is not only useful in systems, to separate application functionalities and interfaces, but also is used to represent the architectural behavior of the platform itself. In general, the GUI plugin makes systems developed with E2 more understandable, maintainable, and faster to develop because of concurrent development of user interfaces and functionalities. E2s GUI implements a model-view-controller design pattern. In Screenshot 3 (below), we see a generic event open file. When an open file event is triggered, no matter through which of the UI representations, the same procedure is called to determine how to open a file and return its contents. As a result, that procedure is only implemented once and is independent of the UI. The same GUI can also be implemented to interface to many methods without knowing what they do, providing them with a generic user interface (such as a hierarchical menu interface), specified dynamically. One similar example is the Linux environment where a function can have both terminal and X Window interfaces; the action is the same no matter what interface triggered it. And the terminal is a kind of generic user interface where an unlimited number of functions can share that interface.In E2s generic user interface, a generic event is similar to a Linux command in which a result of the previous command can be piped to the next one. The difference is that, in E2, the result piped is an object, rather than text so that functions can be naturally connected together to perform any given task. For example, the open file event is a series of three generic events: chose file, open file name and return file content. Each command is simple and results in the input for successive commands: for instance, the chose file command returns a file name to the open file name command, resulting in a handle used by the return file content command to deliver file content. The association of generic UI commands to specific plugin event functionality is done dynamically in the extension layer. E2 implements many generic UI classes that can be associated with many events. Consequently, when an agent is deployed to the platform, it does not have to implement its Screenshot 3. Generic User Interface Plugin - Open File Eventown UI but can instead associate its functions with certain events and then be displayed by the UI associated with those events. Also, because of separation of UI with plugin functionality, capabilities of different agents can more easily be connected because they do not have to connect their UI, which sometime requires tedious recoding. As a result, an agent with a large number of capabilities can be composed more quickly, and different generic UI can be connected to expose different capabilities.E2 also provides an opportunity to create various user interfaces for an agent. An agent can have win32, Java Swing, Eclipse SWT and/or Web user interfaces, on the same or other platforms, which maximizes accessibility.Generic UI is built on the E2 plugin architecture and is a basic part of E2 Platform. As a plugin, it can itself have plugins so it is easy to extend. Message Transport Plugin The message transport plugin facilitates agent communication. After registering a name with the message transporter, agents can send messages to each other. E2 borrows a thread-safe way of sending message between agents by making use of a similar constraint to the apartment thread of the Eclipse GUI which states that the GUI can only be created in the main thread (GUI thread). 4. Project Directions and ConclusionThe Everything is Alive agent system project at the University of Arkansas is continuing to re-architect the Small Unit Operations (SUO) agent system 2,3 in a modular way from the ground up using E2. General-purpose plugins for GUIs, natural language interfaces 6, digital licensing 7, digital rights 8, micropayments, and electronic receipts are in progress as well as domain- specific plugins, for example, a robot plugin 6. Our approach involves a two-dimensional development of E2 make the architecture more dynamic and open but also apply it for a specific useful application, the EiA agent system that drives the architecture. 11Evolved from the Eclipse architecture, E2 is not only useful for developing agent architectures; rather, it is a middleware architecture that can just as readily be used to develop other kinds of software. A companion project at the University of Arkansas is developing data grids. These grids consist of collections of thousands of commodity PCs that support distributed indexing, database query, workflow, and custom applications. It appears E2 might be useful in this environment as well to provide node level controllers. The best of both worlds will be if we can see ways to reuse agent and grid technology to build smart grids 9, 10. Another direction is continued compliance with the evolving web services and .NET framework. Another direction is to extend E2 to support aspect-oriented meta-plugins that load before or after existing plugins. This would be useful for dynamically adding or removing security, logging, caching, and other non-functional behaviors.The artificial intelligence and agent communities have not yet evolved a widely useful platform for sharing and integrating results. The notion of plugins, with its heritage of separation of concerns and its language-neutral XML interfaces, is driven heavily by middleware notions but can be useful to these communities as well as the grid and Eclipse community as a way of sharing and building on each others results.References1 C. Thompson, “Everything is Alive,” Architectural Perspectives Column, IEEE Internet Computing, Jan/Feb 2004. 2 C. Thompson, T. Bannon, S. Ford, P. Pazandak, and V. Vasudevan, Final Report: Agility: Agent -Ility Architecture, DARPA Contract F30602-98-C-0159, Object Services and Consulting, June 2002. agility/final/CoABS-OBJS-Agility-Final-Report.html3 C. Thompson, B. Brown, P. Morris, Final Report: SUO Communicator: Agent-based Support for Small Unit Operations., AFRL Contract F30602-01-C-0189, ScenPro, Inc., September 2003. http:/csce.uark.edu/cwt/ DOCS/2003-09-FINAL-REPORT-ASIV-SBIR.doc4B. Brown, P. Morris, C. Thompson, “SUO Communicator: Agent-based Support for Small Unit Operations,” IEEE Integration of Knowledge Intensive Multi-Agent Systems (KIMAS-03), Cambridge, MA, October 1-3, 2003. 5“Eclipse Platform Technical Overview,” Object Technology International, Inc. February 2003. 6J. Allen, Q. Duong, C. Thompson, Natural Language Service for Controlling Robots and Other Agents,” IEEE Integration of Knowledge Intensive Multi-Agent 7R. Jena, C. Thompson, “Digital Licensing Service for Agents and Web Services,” IEEE Integration of Knowledge Intensive Multi-Agent Systems (KIMAS-05), Waltham, MA, April 18-21, 2005.8C. Caloianu, C. Thompson, “Digital Rights for Agents,” IEEE Integration of Knowledge Intensive Multi-Agent Systems (KIMAS-05), Waltham, MA, April 18-21, 2005.9 C. Thompson, Ag