eGents:  Agents communicating via Email

Project Summary

Venu Vasudevan, Steve Ford and Craig Thompson
Object Services and Consulting, Inc.

17 June 2002

Contents

Executive Summary

Objective

The objective of the eGents project is to develop a modular light weight agent system that uses email as a transport layer.  There are a number of advantages to using email:  it is pervasive and industrial strength, and it already supports disconnected operations, message queuing, message filtering, firewall permeability, logging, and security.  So an email-based agent system should not have to replicate this functionality.  Instead, anyone with email can create an agent service that anyone else can use.

Specific scientific and engineering subgoals were:

Technical Accomplishments

Motivation

Despite the spread of web and distributed object technology, enterprise applications remain hard to build. CORBA and other distributed-object based solutions require heavyweight investments of software on the desktop, and a fair amount of investment in the glue software. Web and e-mail are lightweight and pervasive, but currently used for document transport, not distributed computing.  The goal in eGents is to adapt these transports to support distributed computations (specifically distributed agent computations), thus providing an agent platform that is useful, lightweight and leverages currently deployed technologies. In particular, eGents borrows the notion of  agent communication languages as a messaging language from the agent world, and integrates it with email as a computational transport, XML as the enterprise EDI language, and Java as the computational engine at the desktops.  To test our ideas, we focused on applications which benefit from eGents leverage of the vast and pervasive email infrastructure, especially those needing support for asynchronous and disconnected operations, message queueing, firewall permeability, filtering, logging, and security.

Architecture

The eGents framework is comprised of two types of agents: platform agents and task agents. Task agents are distributed java components that are wrapped using an agent wrapper framework so as to send, receive and respond to ACL messages. As their name indicates, they perform a particular task on a specific machine. Platform agents manage task agents, and mediate access to them. Task agents on a single machine are controlled by a per-machine platform agent which launches and terminates task agents (the task agents being threads executing as part of the platform agent process). Agent applications consist of communicating task agents that are dispersed across different machines (perhaps different administrative domains) across the WAN.

eGent task agents dispersed across a WAN communicate via a bi-level ACL bus using (a) an email-based ACL bus between platform agents and (b) the JavaBeans protocol between a platform agent and a task agent or between two colocated task agents. ACL messages are addressed to a named task agent belonging to a specific platform agent, and each platform agent has a unique email address. The eGents framework converts the ACL performative into an XML document and emails it to the destination platform agent. The destination platform agent parses the XML-based ACL message into a Java object, and forwards it to a local task agent using JavaBeans as a messaging protocol. Javabeans supports the observer design pattern whereby objects can subscribe to change events on other objects. Task agents use this to subscribe to changes in an ACL-mailbox object into which the platform agent stuffs incoming ACL messages.

The eGents ACL bus reuses standard Java, XML and email technology to build an ACL bus that has previously required proprietary KQML/FIPA ACL parsers and proprietary TCP/IP based transports. The use of XML as the EDI transport makes use of widely available XML parsers to parse the content at the receiving end, avoiding the engineering problems reported in some ACL-based agent efforts.  JavaBeans provides similar benefits within a single machine.

The agent wrapper framework uses a simple microscripting language to map ACL messages into sequences of method invocations on the Java component that implements the agent. One microscript statement corresponds to one task agent and one kind of performative. Blocks of microscript statements collectively specify how a particular agent type would respond to all ACL performatives that it handles. A per-machine agentmap (file) maintains the microscripts for all task agent types that are supported by a platform agent.   For instance, the microscript statement below says that:

The microscripting language emphasizes simplicity and minimality over full function workflow capabilities. As we gain experience with component wrapping, we will add to the language or consider integrating with other workflow specification mechanisms.

Agent wrappers use Java's dynamic class loading and reflection capabilities to execute the performative implementation based on a microscript specification. The microscript interpreter parses the microscript, dynamically loads the associated java class object, and uses reflection to dynamically compose the method invocation string and to execute methods on this class object.  Script-based wrappers offer the potential advantage that agent implementations can be dynamically changed in a running agent computation.

Initial applications

Technical Report Dissemination

As researchers, we spend a lot of time finding and cataloging technical papers that are relevant to our research, and disseminating this information to colleagues in our informal network. The forwarding of emails is a manual process that is tedious and error-prone for that reason. An alternative would be to establish lightweight repositories on everybody's desktop (Unix directories indexed by Glimpse servers) and to support subscription based access to these repositories using personal agents. That is what our first eGent application demonstrates, Technical Report Dissemination.

In this application, a publication repository is modelled as a single UNIX directory on one OBJS machine. This directory is indexed by a Glimpse server, making the index information accessible to the eGents platform running on this machine. Other OBJS users can subscribe to this repository by commanding the local eGents platform to launch personal monitoring agents (PM agent for short) on their behalf. These PM agents continually monitor the publication repository for newly deposited publications of interest to the owner of the personal agent. When new publications are discovered, the remote user (owner of the PM agent) can launch packager agents on the repository machine, which package the new publications into a multipart email and dispatch it to the subscribed user.  See demo script.

This application was chosen as an initial eGents scenario because it is accepted as a useful application and has at least a couple of well known non-agent solutions, notable Dumais' latent semantic indexing based system and SIFT from Stanford. It was felt that this application could serve not only as a demonstration of eGents, but in the longer term as a benchmark for comparing and contrasting agent and non-agent solutions.

After completing the Technical Report Dissemination application, we ported eGent from Unix to NT.  In the eGent demo application, we replaced the Glimpse dependence with the DOS Find utility.

Personal Status Monitor

In July 1990, we packaged the eGent project (code, license, documentation) and sent the system to Ed Killian at Rome who installed it successfully and commented "everything worked."  Killian sent some hints for improving the install and test documentation and commented "It is cumbersome to type or cut/paste/modify the queries.  It would be nice to have some kind of better interface for this."  This led us to work on an improved demo for eGents (and some new kernel capabilities).  The new demo shows evacuees who have a Personal Status Monitor that has eGents inside that communicates periodically (ACL sent via email) to subscribers (command post, medevac unit, state department monitor, ...).   We demonstrated the PSM application at the CoABS Science Fair (October 1999).  A number of attendees stopped to see our three demos including Jane Alexander (Deputy Director of DARPA).  New ideas to follow up include:  beeper for eGents (Hendler), USMTF messaging for MBNLI (Alexander), and MBNLI interfaces to Intelink databases (Hendler).

Advantages and Lessons Learned

Some of the real (and potential) lessons learned from this prototype were:

Palm implementation of eGents

As mentioned, at the CoABS Science Fair (October 1999), Jim Hendler (DARPA CoABS Program Manager) suggested that we extend eGents to operate nomadically, perhaps using a pager.  We subsequently determined that pagers at that time were not an ideal platform for eGents because of the near lack of programmability and the limited size of pager messages.  It is not hard to get trivial eGents messages to the pager, its just that nothing interesting can execute there with then-current pager technology so it was at best a trivial use of eGents.  But the Palm Pilot PDA proved to be a good candidate so we chose this path.

The hardware platform we settled on consisted of Palm Vx, Novatel Minstel V Wireless Modem, Omnisky Wireless Internet Access, and AT&T Wireless Cellular Service.  The software was more the problem.  Normal Palm applications are developed in C++.  We also looked at Sun's K Virtual Machine (KVM), a then new Java runtime environment that was built from the ground up to make an extremely lean implementation of the Java virtual machine for use in devices that have a small memory footprint, like digital cellular phones, pagers, mainstream personal digital assistants, low-end analog set-top boxes, and small retail payment terminals.  We chose the latter as our purpose was to show that agent technology is not standalone and monolithic and therefore irrelevant to mainstream computing technology, but rather that it can be and is being integrated with mainstream technologies.

The biggest time sink was figuring out how to do email programmatically from a Java application on the Palm.  We could not locate SMTP/POP3 class libraries that run under KVM (JVM for the Palm) nor even equivalent C++ email libraries.  Palm Java (circa January 2000) was very immature, buggy, slow and a resource hog, but it worked.  Mostly, people were doing graphical things with it.  The most common area for problems was network access.  Our plan was to use Multimail.  Unfortunately, this idea wouldn't work, as KVM apps cannot access Palm apps, because KVM doesn't support JNI (Java Native Interface).  KVM is a very restricted Java for use on small devices.

We decided to implement POP3 and SMTP for the Palm in KVM Java.  We found a simple implementation of POP3 and started to port it to KVM -- not easy.  So much of Java is missing that there's hardly a line of code you'd normally write that can go unchanged plus the codebase is not very stable and the debugging tools are poor.  We ported the eGent code (sans email support) to KJava (Java for handhelds), stripping out all unnecessary classes, added others, integrated a KVM-compliant parser into the code (replacing the IBM parser), ported the demo Personal Status Monitor (PSM) and PSM client codebase and interfaces to KVM.  We completed implementing POP3 for PalmOS in Java (KVM) and a test app, integrated it with the port of eGents, and ported it again to J2ME CLDC 1.0 Beta (the new version of KVM), and then ported a sufficient subset of JavaMail to KVM to support eGents' SMTP needs.  Fortunately and unfortunately, PalmOS version 3.5 and CLDC 1.0 Beta came out in the middle of this.  It was fortunate because the size of the Java heap increased by 4x, and without that, it might have proven impossible to run egents.  Unfortunately, because it introduced some new different bugs, changed the network API, and temporarily invalidated our wireless access to the Internet.  In 2Q00, we integrated all components into the eGents platform under J2ME CLDC 1.0 Beta (PalmOS) including the Personal Status Monitor (PSM) demo, and tested and debugged .  We got it working on kvm.exe, and with more work on the POSE (Palm emulator) and the Palm itself but it was too slow.

Performance analysis pointed to POP3 message reception as the biggest problem, about 4X slower than SMTP message transmission.   Focusing on that, we were able to speed message reception up to the level of transmission.  It is now fast emough for the kind of applications we are targetting but slow for demo purposes.  To run the demo we ran at the Science Fair takes about three minutes from the point that one clicks "subscribe" on the client until the client's fields are updated on its display.  That involves one message send from the client and received by the server, and then one response sent by the server and received by the client.  The messages were sent via the mail server on internal.objs.com.  Most of the time is spent sending and receiving the messages, although xml parsing seems unnecessarily slow too, and some time is wasted in our primitive thread management.  This all can be sped up quite a bit using standard techniques.

At this point, we turned our attention to gridifying eGents.

Gridifying eGents

CoABS Grid.  The CoABS grid is a JINI-based implementation of an agent interoperability platform developed by GITI, the DARPA CoABS program integration contractor.  It is an important, on-going experiment in agent system interoperability.  As described elsewhere, we contributed architectural ideas to the grid.  But in addition, we developed three standalone agent components (eGents, WebTrader, and AgentGram) that can play a role as grid components or services.  As part of the Agility eGents project, we worked on two approaches to connecting eGents to the CoABS Grid described below.  At the same time, we note:  eGents taken alone but piggybacked pervasively on Email is arguably a very different but also very powerful basis for an agent grid.

eGent-Grid Proxy, 7x24 grid and eGents launch page.   In July 2000 we gridified eGents and the Personal Status Monitor (PSM) demo using an eGent-grid proxy approach - see the two figures below.  We can send messages from normal client GridAgents to GridAgent/eGent proxies (a Grid Agent that is also an eGent), which then translates the incoming message, which is in KQML, into an eGent message in FIPA ACL (pretty close alignment of fields, actually), and then forwards it to an eGent.  To do so, we implemented the eGentGridAgent class, which is a generic proxy for registering eGents on the CoABS Grid, and relaying messages between Grid Agents and eGents. We modified the Java and KVM PSM Server eGents to (optionally) register with the Grid via an eGentGridAgent.  We built a Java PSM Client Grid Agent for end-users to use to subscribe to PSM Servers, either eGents or Grid Agents.  We demonstrated this new capability at the CoABS Workshop in Boston (August 2000).  Thereafter we prepared eGents and the PSM demo for permanent installation on the 7x24 Grid, and maintained it for most of a year (see Personal_Status_Monitor in the grid archives).  This required some changes to bring the demo up dependably and usably on the 7x24 Grid and also to enable multiple clients' subscriptions to a single server.  The latter involved making eGents handle connects and disconnects from multiple simultaneous clients reliably and intuitively.   The public demo worked for multiple servers and clients, both Grid clients and eGents clients, operating simultaneously.  We also provided a launch page with documentation for using and downloading the PSM demo.

Towards an Email-based Grid Transport.  In January 2001, we began a short-lived experimented with another way to connect eGents to the grid, this time using eGents (actually just email) as a grid com layer.  This time, we wanted to consider how we could modify the grid to use an Email-based transport.  We made good initial progress towards this goal.  The initial approach was at the Java level (that is, below the grid and JINI).  We looked at the RMI source and discovered that RMI allows one to substitute its socket-based transport layer with sockets of your own design, such as sockets that support SSL (encryption) or eGent-based sockets, so that is the path we took.  We created an Email Sockets library and successfully used it as the RMI socket factory in a test RMI program such that all the RMI traffic including RMI registry lookups and distributed garbage collection (DGC) activity was routed over email instead of the usual sockets.  We chose Unix-style sockets as one API for this email-based messaging capability because sockets are the predominant interprocess (IP) communications mechanism in many OSes including Windows and Unix and thus make a good direct or indirect building block, and because you can slip in custom sockets to handle all RMI traffic in Java with one line of code!  We identified five integration points that Email Sockets could be used in or with a Java program in order to modify the program to use email for IP communication.  We got an RMI test progam (a client-server pair) running in time for Miami.  We wrote a second RMI program ("CoABS Chat") to be more demo-friendly.  We also created a pared-down version of the CoABS Grid demo program "June Demo" to use as the starting point to inject Email Sockets into the Grid.  We got the program to run successfully on the machine standalone, as well as using the 7x24 GITI Grid machine.  We began to investigate the relationship of Jini to RMI (Jini uses RMI) and to determine how Email Sockets will play in the Jini-based Grid.  In February, we decided we had to discontinue this effort in FY01 due to the funding shortfall and higher priority TIEs.  In April we were able to transfer some of our technical effort on this subproject to our Msg*Log contract, which is part of the DARPA Ultra*Log program.  There, we are focusing on adding eMail and NNTP as transports to ALP/Cougaar agents and eventually will focus on creating an adaptive, survivable message transport capability.  So our early results, conceived and begun under Agility, will bear fruit in another grid-like distributed architecture, fulfilling this subproject's research objective.


 

Technology Transition

In December 1998, we responded to the 5th FIPA Call for Proposals on agent technologies suitable for standardization with a proposal for FIPA E-Gents: Agents over Computational E-mail which described certain aspects of eGents.  In that paper, we identified two potential component standards:  one for encoding FIPA ACL in XML so there is no need for a separate ACL parser; and the other for an API which allows email agents to send and receive ACL messages.  FIPA has since accepted both proposals.

We described and/or demonstrated eGents at CoABS Workshops at Northhampton (June 1999), Science Fair in Arlington (October 1999), Atlanta (February 2000), Boston (Augut 2000), Miami (January 2001) and Nashua (July 2001).

In addition to standalone demos, eGents was used in three DoD-oriented technology integration experiments (TIEs) described below.

MIATA TIE

In the disaster recovery domain (MIATA TIE), Palm-based eGents was used as a Situation Reporter in the simulated aftermath of Hurricane Mitch (see figure below).  The scenario is that human observers scattered around the Honduras theatre are equipped with wireless Palms, and they submit "Situation Reports" (essentially filling out eGents-based forms) to J2 (INTEL) when they come across situations of interest.  There are several different kinds of reports supported (i.e. city, bridge, road, weather, other).  The demo focussed on "other reports", of which several types are supported (flood, mudslide, epidemic, fire, evacuation).  The situation actually reported in the demo was an evacuation report saying that the President of Honduras was stranded away from the capital.  The J2 passed it to the JTF Commander, who gave the order to assign two helicopters to pick him up.  This actually happened during Hurricane Mitch.  For the demo, we worked with Mark Burstein (BBN, MIATA coordinator) and David Diller (BBN, MIATA scenario using eGents).  In the demo, Palm-based eGents sends situation data to a Maple Sim GridAgent.  The Palm itself was tethered via a serial cable (as unassisted wireless solutions did not work dependably in a conference room setting) to the laptop, where the mail server, Grid, and Proxy to Maple Sim reside.  We used kAWT this time, which raises the level of Palm graphics programming a notch.   Much of the work was in fitting the demo into memory and speeding it up.  We had to toss out significant parts of eGents to make the demo fit.  This was demoed at the CoABS Workshop in Miami (January 2002).  Following the demo, at David Diller's (BBN) request, we packaged and delivered the MIATA Field Agent demo to BBN for incorporation in a permanent and/or traveling version of the MIATA demo.  In the process, we installed a public domain mail server (Apache James) and got eGents to work with it.

CoAX TIE

In the coalition domain (CoAX TIE), eGents played a role in a biosurveillance vignette of a larger demo.  It is the year 2012.  Elephant herds in mythical Laki Safari Park in Binni, Africa, are migrating through a planned UN firestorm area.  Both the UN and the press have just become aware of this, and care must be taken to locate the elephants and avoid harming them.  A biosurveillance program at Safari Park had commenced in 1009, and eGents is being used to monitor the movements of large mammals including the elephants.  The information is collected monthly and stored in a DBMS which can be accessed across the web (using OBJS MBNLI).  An MBNLI query discovers the elephant migration path, and eGents is pulsed for the current location of the elephants, which is displayed on the CoAX MBP map.  A last minute decision must be made about the placement of the firestorm to avoid harming the elephants.  The scenario shows off bio-surveillance, eGents publish-subscribe, and finding and accessing a new data source with natural language commands.  The CoAX eGents release used the free Apache James email server to permit demoing eGents in standalone CD based demos.  We also added a simulation data source (to simulate the Elephant Status Monitor receiving data).  We iterated with Austin Tate (U Edinburgh, overall coordination), Patrick Beautement (Qinetiq, demo scenario), David Allsopp (DERA, integration), and Craig Knoblock (ISI, an Ariadne information source wrapper), and others.  This work was demoed standalone at the CoABS Workshop in Miami (January 2001) and integrated with other CoAX components at the CoABS Workshop in Nashua (July 2001).  See CoAX TIE avi (.exe includes TechSmith TSCC Codec and viewer - 4.2MB).


JBI TIE

In the small unit operations domain (JBI TIE), commanders drilled down via a map to subscribe to and monitor troop and platoon status during an attack, and fuselets noticed patterns (e.g., chemical attack, soldier wounded).  This TIE was initiated in January 2001 at the suggestion of Jim Hendler (DARPA CoABS PM) and Dan Daskiewich (AFRL, in charge of CoABS), who were interested in understanding how eGents might interoperate with the Y-JBI project at Rome, being developed by Maj. Robert Marmelstein as part of the Joint Battlespace Infosphere project.  Steps were:



Other Interactions and Related Work

Other interactions

In September 2000, Gail Kaiser (Columbia) requested a copy of the Palm version of eGents for possible use in DARPA Dasada. In April 2001, we released eGents source to Joe Giampapa (CMU).  He wants to get Retsina to interoperate with the agents that other CoABS research groups have made available "on the Grid" and wanted other research groups to be able to use his agents "via the Grid".  The idea is that he'll get Retsina to access the PSM on the 7x24 Grid in the same way the PSM Grid Client does.

Related Work

Work has begun on eGents under CoABS has led to two additional contracts:

Appendix

Related Work

Agent projects that are related to eGents are JATLite, SodaBot, BeeGent and VisitorBot.

Futures

The following make sense as next steps for the eGents project - some are research tasks and some are engineering aimed at making the system more usable.

References

  • Sodabot Home Page
  • BeeGent Home Page
  • appmail zaplets
  • Borenstein, N., Email with a Mind of its Own: The Safe-Tcl Language for Enabled Email and Computational Mail as Network Infrastructure  for Computer-Supported Cooperative Work

    • This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Air Force Research Laboratory under contract F30602-98-C-0159. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency, U.S. Air Force Research Laboratory, or the United States Government.

    © Copyright 1998, 1999, 2000, 2001 Object Services and Consulting, Inc.  All rights reserved.  Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information in this survey.

    Last revised:  June 2002.  Send comments to Craig Thompson.

    Acknowledgements:  The initial design and implementation of eGents was by Venu Vasudevan (now at Motorola Labs).  Steve Ford (OBJS) further developed the eGent platform, removed Unix dependencies, ported to the wireless Palm, added CoABS Grid interoperability, and developed the PSM and MIATA demos.  Paul Pazandak (OBJS) worked with Ford on the Palm port.  Tom Bannon (OBJS) worked on the experiment to use eGents as a grid com layer.  Craig Thompson (OBJS) workd on the CoAX and JBI TIEs, modifying eGents to use additional ACL commands including time-constrained subscriptions.