eGents: Agents communicating via Email
Venu Vasudevan, Steve
Ford and Craig Thompson
Object Services and Consulting, Inc.
17 June 2002
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:
develop a lightweight agent system that uses email-based
support (as subset of) FIPA agent communication language
(ACL) represented in XML
demonstrate eGents running on PDAs (e.g., Palms,
any device running KVM)
demonstrate eGents in DoD scenarios
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.
The eGents framework is comprised of two types of 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
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
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
the Glimpser agent maps to the com.objs.tao.Glimpser component
the FIPA subscribe performative is implemented by calling the setWatchWord
and setDistance methods (in that order)
maps parameters in the subscribe performative to method arguments
Glimpser com.objs.tao.Glimpser subscribe #setWatchWord 1
#setDistance 2 #changes
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.
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
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:
ACLs make a nice messaging language. The fact that
they are human readable makes the system easier to debug. Having said that,
there are no miracles to ACLs beyond being a next-generation messaging
language with some higher-level primitives (e.g multi-party negotiation).
The fact that messages are human readable, human
generatable and sent over e-mail makes it possible to substitute humans
for agents and vice-versa. Agent A sending an ACL-over-XML-over-email to
agent B does not know (or care) whether B is a program or a person. This
allows applications to be prototyped with the human-in-the-loop coordinating
task agents, and then subsequently replace the human with an agent.
Building a logger is easy, just bcc: all ACL messages
to a logger email address.
Easy reconfiguration of the human/agent mesh that
makes up the application requires a mediation architecture. One where agent-agent
communication is actually agent-mediator-agent. Changing the application
logic is then reprogramming the mediator.
The benefits of agents so far is that of using ACLs.
Any speculative advantages in terms of component discovery, automated assembly
of the application, ability of personal agents to tune the information
feed based on user feedback are all possible but not demonstrated. The
idea is that this would be a lightweight and totally pervasive (and scalable)
platform to try out such experiments.
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
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
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.
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.
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.
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.
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
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).
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:
develop a demo scenario for Small Unit Operations - The demo begins when
the Y-JBI system sends the commander an email describing a mole report
of rebels shadowing US platoons in Bosnia. The commander zooms in
via a map, and four platoons appear. The commander subscribes to them (Y-JBI
communicates the subscription to eGents at the remote platoons).
eGents periodically send Y-JBI platoon level personal status monitor (PSM)
updates on individual troop health status. During the course of the
demo, two platoons are attacked, one with conventional weapons and the
other via a chemical attack. Y-JBI fuselets interpret the raw PSM
reports to make this determination of an attack in progress and report
to the commander the ongoing status.
agree on a common ACL messaging format - This required some additions to
eGents: support for additional ACL including time-constrained and
periodic subscriptions as well as additional suspend, resume,
and cancel performatives.
extend eGents with a simple simulation capability
test eGents and Y-JBI communication between Plano TX and Rome NY, make
an .avi movie, and demonstrate the result at the the CoABS Workshop in
Nashua (July 2001). See
TIE avi (.exe includes TechSmith TSCC Codec and viewer - 2.9MB - 2:14
Interactions and Related Work
In September 2000, Gail Kaiser (Columbia) requested
a copy of the Palm version of eGents for possible use in DARPA Dasada.
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.
Work has begun on eGents under CoABS has led to two
the DARPA UltraLog MsgLog contract
(February 2001) - the idea is to provide the ALP-Cougaar agent-based system
with multiple communication transports (email and NNTP in addition to RMI)
and then use policy management to select among them to insure survivable,
robust message delivery in chaotic environments. David Wells described
our Msg*Log project, including its origins in the CoABS Agility project,
in Msg*Log: Email-based Agent Messaging to Improve
Robustness in a Distributed Logistics Planner, a paper for the Software
Technology Conference (STC 2001), Salt Lake City, Apr 29-May 4, 2001.
an SBIR II with ScenPro as prime (October 2001) -
the idea is to extend eGents in several ways to support small unit operations
Agent projects that are related to eGents are JATLite, SodaBot, BeeGent
JATLite implements a subset of eGents functionality (the ACL bus) using
applet communication protocols as the transport. As applets are limited
to communicating only with the host they were downloaded from, much of
the JATLite infrastructure is geared towards building a peer-to-peer messaging
bus out of this star communication topology (i.e., all applets talk back
to a single node from which they are downloaded). This infrastructure
includes components that perform performative queueing and routing function.
eGents avoids this limitation by using e-mail, which is peer-to-peer by
definition. eGents reuses the email store-and-forward capability (that
mailboxes inherently provide) to implement performative queueing and routing.
The centralized nature of JATLite raises some scalability concerns in serving
large communities of agents. eGents has no single locus of control, and
relies on the scalability of email. The JATLite feature that agents have
to be applets can be restrictive and unnecessary. eGents can support
batch agent applications that do not require the interactivity that applets
provide, and conversely need greater access to the host platform than applets
provide. The security restrictions of applets makes them hard to operate
over corporate firewalls. eGents e-mail based ACL bus imposes fewer requirements
on agents that use it, and firewalls do not pose a problem for an e-mail
based ACL bus. While applets limit JATLites range of applications, they
also make JATlite easy to deploy and distribute. JATLite uses web browsers
as the agent platform and applet downloads as the software distribution
mechanism. We would like for eGents software distribution to be as easy
as downloading an applet, without the downside's of restricting agents
to be applets.
SodaBot provides a toolkit for building personal online assistants (electronic
secretaries) and application agents (coordinate tasks or information transfer
amongst people). It uses an e-mail based agent communication infrastructure,
with a Perl-based ACL (and content language). SodaBot has a built-in software
distribution mechanism to disperse code blocks from a static agent specification
to the locations they need to execute at. SodaBot has similarities
to eGents, but does not use widely supported implement platforms such as
Java and XML.
AT&T's VisitorBot is more an application than a platform, but relevant
in that it also uses e-mail as a computational infrastructure to automate
meeting scheduling amongst multiple lab members. Their application uses
a limited communication language between desk top agents (one which is
transported over e-mail), and a star architecture where all desktop agents
communication to a central meeting scheduler agent. VisitorBot does have
the intelligence to find the user (if not at his workstation, page him,
or fax him.....), something which is worth incorporating into eGents.
Toshiba Labs seems similar in goals to eGents. Like eGents, BeeGent has
an ACL-over-XML bus, but over HTTP instead of email. They apparently have
a mobility solution over http as well. It is unclear why (or whether)
they do not use Koala and XML-based mobility. They also focus on agents
that are java components, and have a component wrapper language. Their
focus seems to be more on enterprise-wide access to repositories and less
on office automation. This might influence our respective architectures
All the real computing is going on on the web server. You go to their
site and choose from a library of zaplets, say a poll zaplet, you fill
out the zaplet form (a form letter), and their server sends it to the recipients
you specify. The recipients get a message containing a link to the
client version of the poll on their web server. They fill out their
part and their web server updates the server version of the poll, on the
web server. Optionally, it might send you a message saying it has
received a response. You go back to their server to check the results.
It looks like the poll is being updated in your local mail archive
if you keep the original message that's sent out, but its not really, its
just that the message doesn't really have the script or data in it, it
has a link to it on the Zaplet server. In contrast, eGents uses a
thin agent platform on the client side to connect (Java) applications on
the local machine to communicate (using email as the transport) to similar
applications using similar eGent clients on other machines.
There is no central server. So, the mechanism is totally different,
but both mechanisms could implement the applications they are targetting.
A disadvantage to their design is that it is dependent on the Web, and
connectivity to their server, so would not work with the same level of
disconnectedness that eGents can. The advantage is that its fairly
independent of any software on the client, especially all the security
issues involved with running Java applications on clients. Both technologies
can be used to create back office or interactive apps connected into email.
The eGents approach is more decentralized, usually means more scalable,
and also works disconnected.
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
handle dangling subscriptions (subscriptions from dead clients)
integrate eGents into the Grid as an alternate transport
integrate Java security and make eGents' security policy easier for the
user to understand and trust
add XML-based mobility solution (e.g Koala from Inria)
make eGents as easy to install on the desktop as a plug-in or applet (without
the limitations of either).
tackle some tedious but tractable engineering challenges allowing eGents
to share a user's mailbox without him/her noticing the email pollution.
eGents + WebTrader + ... = e-mail-based Jini
explore adaptive application architectures that make use of agent mobility.
Right now, mobility is used at the individual agent level, without any
collective intelligence driving it.
XML'ize the AgentMap file format. This will save us from building custom
parsers, if the microscripting language becomes more complicated.
improve the performance of the Palm version of eGents, and merge in changes
from the Java version.
prepare a general public release of the Java and Palm versions of eGents
Sodabot Home Page
BeeGent Home Page
Borenstein, N., Email
with a Mind of its Own: The Safe-Tcl Language for Enabled Email and
Mail as Network Infrastructure for Computer-Supported Cooperative
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
© 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
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.