eGents: Agents over Email

1
Agility
Craig Thompson, Steve Ford, Tom Bannon, Paul
Pazandak, David Wells Object Services and
Consulting, Inc. (OBJS)

• Main Idea - agents for the masses - scaling and
  pervasiveness
• Approach - piggyback agent capabilities on
  already pervasive technologies
• eGents - agents send messages over email
• WebTrader/DeepSearch - trader discovers ads for
  resources via search engines
• AgentGram - menu-based natural language interface
  wrappers for resources
• Smart Data Channels - information supply chain
  grids on the web
• Grid - implications for the grid

This presentation http//www.objs.com/agility/
2
eGents Agents over Email
Steve Ford
Problem
Impact

• Anyone with email can create an agent service
  that anyone else can use.
• eGents leverages pervasive, robust email
  infrastructure, inherits support for disconnected
  operations, message queueing, mobile users,
  firewalls, filtering, logging, and security.
• eGents spec submitted to FIPA standards group.

• Dynamic military situations are often
  disconnected and asynchronous.
• Need a scalable way to deliver agent messages to
  1000s of platforms.
• Agent systems are often closed and require a lot
  of specialized agent technology.

Approach
eGents Inside

• Thesis Integration of agent technology with
  pervasive Web-ORB-Email backplanes is a route to
  making agent technology open, pervasive and
  robust.
• eGents are agents which communicate over email.
  eGents use FIPA or KQML Agent Communication
  Language (ACL) encoded in XML. No ACL parser
  needed.
• Status Prototype, NEO demo, gridified, on
  wireless Palm.
• In progress packaging and various extensions

Command Post
Neo Evacuees
Medevac
Liaison
Family Member
In one eGents application, each NEO evacuee has
a Personal Status Monitor, which measures
location, vital signs, etc. The PSM contains an
eGent which intermittently communicates to
subscribing entities using email protocols.
3
Problem. Most agent systems rely on unique and
extensive infrastructures that must be widely
available if the systems are to be widely used.
This is an obstacle to the widespread adoption of
agent technology. Objective. We wanted to
demonstrate that agent technology could scale to
global proportions by leveraging an existing
infrastructure, rather than propagating a new
one. Approach. eGents is, basically, agents
communicating over email. Email is pervasive and
robust and already provides many functions an
agent system needs - message queuing, encryption,
filtering, firewall traversal, support for mobile
users. The eGent platform is a multi-threaded
Java app with access to an email account on an
SMTP/POP3 server. Individual eGents are
identified by their name and the email address of
the platform, and are managed as threads in the
eGent platform's process. Messages are in a
subset of FIPA ACL (subscribe inform), encoded
in XML, and sent as the body of an email message.
Recent Progress (a) We ported eGents to a
wireless Palm using Sun's newly released Java for
devices, KVM, a troublesome port because of KVM's
bleeding-edge nature, lack of tools, and because
most Java code will not run under KVM, including
most of Sun's Java class libraries, and all of
the third party code on which eGents depended.
The result runs, but is slow. The main benefit
is that it should port easily to other devices
(set top boxes, smart phones). (b) We built the
eGentGridAgent proxy which extends the grid by
demonstrating interoperability of GridAgents with
agents that are less "connected". We could have
just made a proxy for the PSM demo, but spent a
little more time coming up with a generic proxy.
We didn't want the eGents platform or an
individual eGent to know anything about the Grid,
or vice versa. The only component of the system
that knows anything about both is the
eGentGridAgent, which is just an eGent to eGents
and just a GridAgent to the Grid. We wanted to
keep the protocol situation simple. We didn't
want an eGent to have to know LAN protocols, like
Jini or HTTP or RMI or anything that made the
eGent less mobile, disconnected, and
asynchronous. So, an eGent can be "on the Grid"
without knowing anything about the Grid. Another
alternative for integrating eGents and the grid
would be to extend the grid to provide multiple
native communication protocols. Demonstrations.
The initial eGents demonstration was a technical
report subscription service. For the Science
Fair, we developed an eGents demo for a NEO-like
scenario. We assume that NEO evacuees have
Personal Status Monitors (PSMs) that monitor
location, medical status, threats, etc. These
PSMs contain eGent platforms and periodically
exchange status updates with subscribers, e.g.,
command posts, medevac units, state department
monitors. Plans. (a) install Java version of
eGents on 7x24 Grid, (b) integrate eGents into
Grid as an alternate transport, esp. for
LAN-to-LAN bridging, and install on 7x24 Grid,
(c) insert eGents into MIATA and/or CoAX TIEs,
(d) prepare a public release of the Java version,
(e) speed up eGents on the Palm under KVM, if
possible, else port to C, (f) prepare a public
release of Palm version, (g) demonstrate
email-based eGent installation, (h) integrate
Java security and make eGents security policy
easier for the user to understand and trust, (i)
use eGents to study grid control
schemes. Technology Transition. We developed an
application demonstration involving NEO evacuee
status monitoring for the Science Fair, since
ported to the PalmOS. The encoding of FIPA ACL
in XML and the JavaMail/MAPI API are candidates
for standards, and so we submitted these to the
FIPA-99 Call for Proposals. System
Requirements. (a) eGents should run on any Java
platform, but has only been tested on Windows NT
4.0 SP3. It requires Sun's Java JDK 1.2.2, 5MB
of free disk space, and an email (SMTP/POP3)
account for each machine on which the eGents
platform will run. (b) eGents also runs on KVM
(J2ME CLDC 1.0 FCS) on the Palm Vx, the PalmOS
Emulator 3.0a5, or under Windows NT. Wireless
communications from the Palm is currently via the
Novatel Minstrel V wireless modem, Omnisky's
wireless Internet access, and ATT's CDPD digital
cellular network. (c) The eGentGridAgent has
been tested with CoABS Grid v1.5.0 beta.
4
eGents interoperating with each other and with an
eGent-grid proxy
Might be on machine 2 or anywhere on LAN
or on grid-connected LAN
PSM client grid agent
Machine 2 perhaps installed at command post
Machine 3 perhaps installed at medevac unit
Machine 1 installed on evacuee
subscribe
inform
eGent grid agent proxy
PSM server eGent
PSM client eGent
other eGents
other eGents
other eGents
Grid
eGents platform
eGents platform
eGents platform
inform
inform
subscribe
inform
subscribe
subscribe
Email Server
KVM-based Java-based
All eGents can share one Email server or they
can each have their own or anything in between
5
(No Transcript)
6

• eGent DEMO
• Purpose
• eGentGridAgent proxy is used to connect
  (wireless) eGents in the field to grid-accessible
  agents on a LAN
• Demo scenario
• PSMs on troops updated with latest status
  information (geographic, health, threat, )
• other parties (PSM clients like command post or
  medevac) subscribe and receive inform messages in
  response to changes
• Displays
• PSM Server is displayed in one Java window
• DOS windows show activity of the eGentGridAgent
  proxy and Grid's log agent
• PSM Grid Client is displayed in another Java
  window
• Netscape Messenger shows the log of eGent
  messages
• Demo step-through shows
• registering the PSM Server eGent with the
  eGentGridAgent proxy which then registers it with
  the Grid
• switching to the PSM Client agent, which
  subscribes to the PSM Server by sending a lookup
  message to the Grid Registry, which finds the
  proxy, which the client thinks is the PSM Server,
  and then sends a subscribe grid message to the
  proxy, which passes it along to the PSM Server
• then PSM Server sends back an inform message
  containing the subscribed values (and sends
  updates later if any values change)

7
WebTrader Agent Discovery
Tom Bannon
Problem
Impact

• If grid applications are to be assembled when
  needed, the parts must be found somewhere and
  probably not all will come from the local
  environment.
• How can we find building block resources (e.g.,
  agents, services, channels, components, data
  sources) when we need them?
• Today, traders (matchmakers) are used for this
  purpose but these traders generally know only
  about closed worlds of resources of limited types
  (e.g., IDL).

• Anyone on the Web can advertise a resource (e.g.,
  agent, service, data source) that anyone else can
  discover.
• Advertised resources can be located at runtime to
  dynamically extend the knowledge and/or
  capabilities of the client, as well as enable
  intelligent on-the-fly assembly and
  reconfiguration of distributed systems.

Approach

• WebTrader is a matchmaking service that locates
  XML-based advertisements for resources embedded
  in web pages indexed by industrial-strength
  search engines.
• WebTrader supports type-specific matcher
  algorithms, trader federation, and can access
  multiple search engines.

8

• Problem. Most agent systems contain some sort of
  trader (matchmaker or yellow pages) that they use
  to locate agents by description. This provides
  late binding of agents to some service provider
  but does not scale outside of the closed agent
  system. Also, the trader itself is usually an
  integral part of agent system implementations and
  not available separately.
• Objective. Build a scalable robust trader
  component architected for the global grid.
• Approach. WebTrader is a scalable trader that
  locates advertisements (represented in XML)
  stored on web pages that have been indexed by
  search engines. Query results allow clients to
  connect to the most suitable service.
  Advertisement types include agents, components,
  data sources, search engines, MBNLI grammars,
  other traders, channels, and other types.
• WebTrader leverages industrial strength Web
  search engines so it is scalable, lightweight,
  portable, and robust. WebTrader is extensible --
  recent changes to WebTrader support adding
  specialized matchers for ads of specific types.
  DeepSearch is an application of WebTrader that
  recursively searches other search engines and
  traders (using a federation design pattern).
  This makes specialized Web pages (not indexed by
  many search engines) accessible to DeepSearch.
  Also keeps a search history.
• Demonstrations. WebTrader is used in the Science
  Fair NEO application to locate data sources for
  the location of evacuees and to find a geocoder
  component. In the demo, ISI Ariadne uses SRI OAA
  to request WebTraderAgent to find these
  resources. WebTraderAgent consults the Grid to
  find a WebTrader service and then uses it to
  discover candidate resources which are returned
  to Ariadne via OAA. Other demonstrations show
  trader federation, service rebinding, and
  WebTrader used to locate agents that use natural
  language wrappers. The DeepSearch demonstration
  shows WebTrader locating ads for search engines
  on the web and recursively searching them,
  opening up parts of the web that are usually
  beyond the reach of general purpose crawlers.
  WebTraderQueryTool is a recent hybrid of
  WebTrader and DeepSearch that does add matching
  and better supports application composition.
• Plans. We are currently hardening WebTrader and
  making the design more open. We need to grow
  WebTrader ad populations. To do this, we will
  make it easier to create WebTrader ads manually
  using a GUI. Also, we want to try to harvest ads
  from the web to automate the process of ad
  synthesis. This is a web-size ontology question.
  We are also making matching ad type open so
  specialized search and ranking algorithms can be
  plugged in.
• Technology Transition. We are hardening
  WebTrader and DeepSearch getting ready for a
  public experiment. We led effort of OMG Agent WG
  to review an Agent Resource Description and
  Discovery Service. We reviewed Agent UML.
• System Requirements WebTrader Agent WebTrader
  Grid Service require MS Win NT 4.0 (pure Java
  programs), Apache (latest) web server, Webinator
  2.5 search engine (from www.thunderstone.com) ,
  Sun JDK 1.2.2, Sun XML TR-2 XML parser, GNU Make
  3.75, tcsh. DeepSearch requires all of the above
  plus Netscape or IE, ActiveState Perl 5. Need
  connection to Internet (licensing quirk of local
  search engine used).

9
WebTrader Architecture
Query (Client Advertisement)
14
4
5
WebTrader
13
Web Trader Engine
WebTrader matches and returns candidate
advertisements
6
12
10
Matching
11
9
7
Web Search Engine(s)
Locates and returns candidate pages
8
Indexed by
3
Trading advertisements may be distributed across
some part of the Web
10
(No Transcript)
11
(No Transcript)
12
WebTrader Demo Discovery, Rebinding, Federation
13

• WebTrader Demonstration
• This demonstration of the WebTrader illustrates
• service binding and rebinding
• trader federation
• In the demo, trading ads exist for a variety of
  components (e.g., service agents, clients, and
  WebTraders). Metadata including color and cost is
  included in the ads. A Blue client, for example,
  asks the USA WebTrader to locate a Blue agent
  implementing a particular interface and with zero
  cost, if possible. One is found and bound, and
  the client makes use of the agent. When the
  agent unexpectedly dies, the WebTrader is
  consulted again by the client, in case the state
  of the world has changed. It gets back a new
  list of agents, sorts them by cost, and goes down
  the list trying each agent until it finds one
  that works. If the WebTrader fails to respond,
  the client can fall back on its cached list of
  previously found agents. When the Yellow client
  asks the USA WebTrader for Yellow agents, the
  WebTraders initial search turns up none, as it
  only consults a domain that indexes ads of Red,
  White, or Blue agents. However, it does find an
  ad for a WebTrader that knows about Yellow
  agents, and so passes on the original client
  query to the Euro WebTrader, which finds a Yellow
  agent, passes it back to the USA WebTrader, which
  passes it back to the client, which then uses it
  to connect to the agent.
• At the right in the figure is shown a service
  advertisement in XML.

14
WebTrader Application DeepSearch
15
WebTrader Application DeepSearch DeepSearch is
an application of the WebTrader. In this case,
the advertisements of interest are service ads
for search engines. Many web search engines only
index top-level pages leaving the other half of
the web unindexed except by these local search
engines. So DeepSearch recursively (via
federation) locates these local search engines
and spawns deeper searches of these. You start
out with the main search page (shown on the
right). You select your favorite initial search
engines (any or all - e.g., this part just shows
metasearching in parallel) and enter a search
term like you do for any search engine and hit
return. Then the side window pops up with the
search results, and as you click on the links,
the corresponding pages come up in the main
browser window. Local search engines found
during searching show up among the links - you
can expand them to get the results of their
searches, just like you can expand a directory in
the Windows File Explorer.
16
Natural Language I/F for Agents
Paul Pazandak
Problem
Impact

• Humans can task and query agents using complex
  but understandable commands in constrained
  natural language.
• This technology can mix pervasively into all
  applications, both on the desktop and the Web.

• Dynamic military situations will require people
  to task and query agents using complex commands.
• Unconstrained natural language is still not
  tractable in many situations.

Approach

• Thesis Natural language-enhanced user-to-agent
  communication will simplify basic human-agent
  interactions while making it possible for humans
  to formulate complex agent requests.
• Approach Agents communicate with people and
  other agents using restricted languages for
  stating complex queries and commands
• How AgentGram extends agents with natural
  language middleware wrappers, dynamically loads
  grammars, and uses menu-based natural language to
  query and task agents. Works over the web with
  many users, can auto-generate NLI interfaces to
  DBMS, works with speech, and is on the CoABS grid.

17
Problem. Agent-based command and control systems
offer real promise in flexibility and
adaptability but it is not yet clear how they can
be understood and controlled. It would be
desirable if we could just talk to systems of
agents - but how? About Menu-based Natural
Language Interfaces (MBNLI). Try typing or
speaking to a system that has a conventional
type-in or speech natural language interface
(NLI). Most of your questions and commands will
not be understood because they overshoot the
capabilities of the NLI system or the underlying
application it interfaces to. In addition, you
wont really know about some things you could ask
(map or statistical queries?) so your questions
and commands will also undershoot the
capabilities of the NLI system. Menu-based
Natural Language Interface (MBNLI) technology
uses standard NLI technology but in a
menu-directed completion-based way to restrict
the language and guide the user to just the
capabilities of the NLI and underlying system.
The technology fills a large unfilled niche in
user interface design enabling unskilled users to
make complex queries and commands. Objective.
The AgentGram project addresses human-to-agent
communication via agents that understand
constrained MBNLI languages. Humans can task and
query one or more agents using complex but
understandable commands. This technology can
mix pervasively into all applications, both on
the desktop and the Web, providing NLI
capabilities to not just agents but also
information sources, services, and generally any
accessible resource. Approach. Like other NL
technology, MBNLI technology uses attribute
grammars and a predictive parser. The difference
is in using the grammars to predict legal
sentence completions and displaying these using
menus. MBNLI, using a client-server parser farm
architecture, supports (a) web-based access, (b)
multiple users, (c) multiple simultaenous
grammars, (d) speech control via Java Speech
Markup Language, (e) the ability to generate
MBNLI interfaces to DBMS system given the DBMS
schema, (f) a partitioning of MBNLI into client
and stateless server so a very thin client can be
downloaded (with no installation) only requiring
Javascript, (g) LL descriptors on the web,
discoverable by traders, and (h) techniques for
composing MBNLI grammars and interfaces. The
AgentGram prototype explores the idea of
attaching NL wrappers to agents to make it
possible for people to query or task them.
Sub-grammars of individual agents can be
traversed on-the-fly to construct commands or
queries which span several agents. The web
prototype shows how to make MBNLI technology
pervasive on the web. Demonstrations. In the NEO
TIE, the MBNLI component is agentized as an SRI
OAA user interface agent (part of the SRI
Multi-Modal Map) that translates natural language
queries to SQL to be executed by an information
access agent (ISI Ariadne). In OBJS demos shown
at the Science Fair, MBNLI was used to query the
DBMS of Enviro Conference attendees and also to
visualize the XML-based grid log. The AgentGram
demo finds MBNLI-enabled agents using WebTrader
and shows how the sub-grammars of one or more
agents can be traversed to produce commands and
queries. Our CoABSGrid demo illustrates one
example of how our MBNLIGridAgent can be used to
integrate MBNLI technology into the grid. In the
demo the user is able to interact with the MBNLI
web browser interface while the MBNLIGridAgent is
able to provide current status regarding the
interaction. Plans. In the near term, we need
to (a) port to IE, (b) re-engineer client-server
MBNLI so one parser server can service (now
10-20, in the future 100-1000 simultaneous) MBNLI
clients, (c) build grammar translations to
FIPA-based Agent Communication Language, (d)
interface AgentGram to eGents and Smart Data
Channels. Longer term, (e) we want to interface
AgentGram to agents and data sources in-the-wild
(on the open Web and in DoD) and (f) add support
for roles, dialog and context models. Technology
Transition. A MBNLI agent was used in the
Science Fair NEO application coupled to SRI OAA
and ISI Ariadne. We are starting to look for
early adopter DoD and commercialization partners
for this technology USMTF and Intelink
databases appear to be good DoD targets. System
Requirements. MBNLI web client requires Netscape
browser server requires WinNT, MySQL, ODBC, a
cgi/php-capable web server.
18
MBNLI Grid Agent Demo Design
Parser StateMgr
Agents retrieve state
GridLog
EnviroConf DB
Store client state
MBNLI GridAgent
MBNLI GridAgent
GridLog DB
MBNLI Parser System
CoABS Grid
Enviro Conf DB
MBNLI Agent Tester
User- Parser Interaction
User
spawns
MBNLI Web Interface
Netscape
19
1. Register/deregister MBNLIGridAgentTester on
the grid. 2. Lookup available MBNLIGridAgents -
two are found (interfaces to NEO DAVCO dbms and
to grid log). 3. Select one and get a session
ID/URL. 4. Launch a (netscape) browser to
interact with remote MBNLI (LLWeb) parser farm.
At this point, you can get the current state of
the LLWeb interaction, whatever it is (state,
translation of the state, or the url for the
results if you evaluate the url (in a browser)
you will execute the query the results will be
returned.
20
(No Transcript)
21
Smart Data Channels
David Wells
Approach
Problem

• Smart Data Channels Standards-based dynamic
  optimizable Web-based information supply chain
  where portals are declaratively personalized by
  type, content, format, data quality, cost, user
  needs, data source capabilities, and timing specs.

• Getting the right information, at the right time,
  in the right format.

WWW Opportunity ...

• Vast sea of information
• Many formats supported
• Distributed and decentralized ? failure tolerant
• Independence of source format rendering
• Active and passive data (e.g., CGI scripts)

Limitations

• Insufficient tools to represent, filter,
  aggregate, index
• Cant tell when information change is significant
• No user or location-specific parameterization
• Platform bandwidth limitations not handled
• QoS not handled

Impact

• Channels automatically deliver information to the
  point of need.

22
Problem. The World Wide Web has greatly increased
the amount of information available on-line, but
obtaining the right information at the right time
in the right format is still beyond the state of
the art, since there is no higher-level Web-wide
information model and existing Web tools do not
adequately address the problems of filtering,
aggregating and disseminating this information.
Information must either be accepted "as is" or
converted and delivered by manual means or a
complex programming process requiring specialized
skills. Portal or channel technology is
intended to provide customized information
delivery, but current technology has limited
modeling and manipulation power, its centralized
architecture does not make best use of network
computing capabilities, the resultant channels
are not resilient to denial of service attacks or
component or network failure, and since channel
composition is not exposed, collections of
channels cannot be optimized to reduce processing
and bandwidth costs. Objective. Develop smart
data channels (SDC) technology to allow the
flexible and efficient creation of information
channels through which information flows through
the Web from data sources to information
consumers. Approach. SDC uses and augments
existing Web technology and standards to reach
the largest market at the least development cost
and risk. In particular, SDC is based on XML and
XSLT, with the current implementation being in
the Java programming language. Details. In SDC,
desired channel content is specified
declaratively rather than procedurally. This
allows the type of information flowing over the
channel to be externally visible, which in turn
makes it possible to define new channels in terms
of existing channels, to use type matching to
determine potential information sources for
channels, to switch to alternate sources when
primary sources become unavailable, and
(ultimately) to optimize collections of channels
to reduce processing and/or bandwidth costs. SDC
operators move information and allow channels to
be combined and tailored to individual needs.
Flow control on a channel allows specification of
update policies for the delivered pages (i.e.,
the conditions under which changed page content
is delivered). Profiles allow customization of
output and delivery based on the type of the
display hardware. Channels can be automatically
parameterized based on user characteristics such
as location (e.g., deliver maps for where I am
right now). Demonstrations. SDC was initially
demonstrated to the Space and Missile Defense
Command under a Ballistic Missile Defense Command
SBIR Phase I. A substantially improved XML-Java
version was demonstrated to the DARPA CoAbs
Program as part of the OBJS Agility
project. Grid. Developed mostly under SBIR, SDC
is not currently tied to the CoABS grid. At
present, it represents a different sort of
grid/infrastructure implementation, also capable
of interoperability with agents, the CoABS grid,
or DAML. Plans. (a) Improvements performance
and reliability, design and implement better
interfaces for channel creation and subscription.
(b) Define a more robust SDC algebra for
specifying channels. (c) Integrate SDC with
Traders to allow channels to be located and
matched more effectively. (d) Develop
optimization strategies to conserve system
resources. (e) Upgrade from XML to
DAML. Technology Transition. SDC will be used as
a test application for the DARPA DASADA program,
possibly also as an architecture description
configuration representation. NIMA has shown
interest for routing map products through
processing stations to DoD customers. We are
also seeking commercial support for further
development. System Requirements. SDC makes use
of Web standards such as browsers, Traders, Java
and JavaScript, XML, XSL, and OBJS XML-to-Java
parser, CGI scripts, servlets, and browser
plug-ins.
23
Example SDC Channel Mesh
Rawsources
X/Y
ProjectChannels
P5
MakeChannel
PSM.DTD
PSM5
SDC_PSM.DTD
P15
SDC_PSM.DTD
MakeChannel
PSM.DTD
PSM15
MergeChannels
Merge
P31
PSM.DTD
PSM31
MakeChannel
SDC_PSM.DTD
SDC_PSM.DTD
P85
PSM.DTD
PSM85
MakeChannel
provides overlay layers, two layers/PSM
MapServer
Rescue
MapServer.DTD
MergeChannels
MakeChannel
SDC_MapServer.DTD
MapServer
provides overlay base
24
SDC Channel Management Interface
25
Merged PSM Channel
26
Rescue Channel
27
Implications for the Grid

• What we demonstrated - grid was useful in various
  ways
• registration/discovery - WebTrader and AgentGram
  grid agents
• interoperability - eGents-grid proxy
• Grid extensions
• each component can be viewed as a generic
  scalable grid extension
• egents adds wireless disconnected agents
• WebTrader adds web-wide agent/resource discovery
• AgentGram adds general way to MBNLI-enable grid
  agents using a lightweight interface that
  operates across the web.
• Smart Data Channels adds information flow
  formalism
• at the same time, each is standalone and useful
  separately
• Grid implications
• several ways to conceptualize the grid - see our
  earlier paper at www.objs.com to appear in
  Bradshaw, Handbook of Agent Technology
• there might be no minimal agent grid - different
  subsets of the agent grid are separately useful

28
OMG Agent Working Group

• http//www.objs.com/isig/agents.html
• Meeting 11 - Burlingame, CA, September 11-12,
  2000
• Meeting 12 - Orlando, FL, December 11-15, 2000
• CoABS/DAML SPEAKERS NEEDED

29
References

• Agility Project Homepage - http//www.objs.com/agi
  lity/index.html
• Agility Overview
• http//www.objs.com/agility/tech-reports/0008-CoAB
  S-Agility-Boston.ppt
• http//www.objs.com/agility/tech-reports/9910-Scie
  nceFairPoster-Agility.ppt
• Prototypes
• eGent Agents over E-mail
• http//www.objs.com/agility/tech-reports/9911-eGen
  ts.html
• WebTrader Discovery and Programmed Access to
  Web-Based Services
• http//www.objs.com/agility/tech-reports/9904-WebT
  raderWWW8Poster.html
• MBNLI sample screens
• http//www.objs.com/agility/tech-reports/9812-NLI/
  MBNLI-Screens.html
• Architecture
• Characterizing the Agent Grid
• http//www.objs.com/agility/tech-reports/000304-ch
  aracterizing-the-agent-grid.doc
• System-wide Grid Properties
• http//www.objs.com/aits/9901-iquos.html
• Strawman Agent Architecture
• http//www.objs.com/agility/tech-reports/9808-agen
  t-ref-arch-draft3.ppt