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/
eGents: Agents over Email
Steve Ford
Problem
• Dynamic military situations are often disconnected
and asynchronous.
• Need a scalable way to deliver agent messages to
1000’s of platforms.
• Agent systems are often closed and require a lot of
specialized agent technology.
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.
Approach
• 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
eGents
Inside
Neo
Evacuees
Command Post
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.
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 AT&T's CDPD digital cellular network. (c) The eGentGridAgent has been tested with CoABS Grid v1.5.0 beta.
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 1
installed on evacuee
PSM
server
eGent
other
eGents
eGents
platform*
* KVM-based
** Java-based
Grid
Machine 2
perhaps installed at
command post
eGent
grid
agent
proxy
other
eGents
Machine 3
perhaps installed at
medevac unit
PSM
client
eGent
eGents
platform**
Email
Server
All eGents can share one Email server or
they can each have their own or anything in between
other
eGents
eGents
platform
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)
• the messages thread their way back through the system to eventually be displayed on the client.
• If you modify a value on the server, you can watch the update propagated back to the client
• You can view the eGent message log with Netscape Messenger.
WebTrader: Agent Discovery
Tom Bannon
Problem
• 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).
Impact
• 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.
Services / Datasources
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.
Agent World
White
Pages
GeoCoder
7
Ariadne
(ISI)
2
Open
Agent
Architecture
(SRI)
6
1
page
WebTrader
Agent
Agent
Grid
Web World
3
5
page
page
AD
AD
AD
page
page
page
4
AD
AD
Search
Engine
page
AD
page
page
page
WebTrader was used in the NEO TIE to
locate evacuees and to find a geocoder.
AD
page
AD
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).
WebTrader Architecture
4
Query (Client
Advertisement)
Response
14
5
WebTrader
6
13
WebTrader
matches and returns
candidate advertisements
Web Trader Engine
12
10
Matching
11
7
9
8 Web
Search Engine(s)
Indexed by
1
3
Web Page
Trader
Advertisement
2
Locates and returns candidate pages
Trading advertisements may
be distributed across some
part of the Web
WebTrader Demo:
Discovery, Rebinding, Federation
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 WebTrader’s 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.
WebTrader Application:
DeepSearch
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.
Natural Language I/F for Agents
Paul Pazandak
Problem
• 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.
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.
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 won’t 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 1001000 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.
MBNLI Grid Agent Demo Design
Parser
StateMgr
Store
client state
Agents retrieve
state
GridLog
EnviroConf DB
MBNLI
GridAgent
MBNLI
GridAgent
GridLog
DB
MBNLI
Parser System
Enviro
Conf DB
UserParser
Interaction
CoABS Grid
MBNLI
Agent Tester
User
spawns
MBNLI
Web Interface
Netscape
1.
2.
3.
4.
Register/deregister MBNLIGridAgentTester on the grid.
Lookup available MBNLIGridAgents - two are found (interfaces to NEO DAVCO dbms and to grid log).
Select one and get a session ID/URL.
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.
Smart Data Channels
David Wells
Problem
• 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)
Approach
• 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.
Filter
Security
Map
Map
… + Limitations
• Insufficient tools to represent, filter, aggregate, & index
• Can’t tell when information change is significant
• No user or location-specific parameterization
• Platform & bandwidth limitations not handled
• QoS not handled
M
e
r
g
e
PSM
PSM
PSM
C
h
o
o
s
e
L
a
y
e
r
L
a
y
e
r
M
e
r
g
e
Rescue
Impact
• Channels automatically deliver information to the
point of need.
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.
Example SDC Channel Mesh
Raw
sources
PSM.DTD
PSM5
Make
Channel
Project
Channels
P5
X/Y
SDC_PSM.DTD
PSM.DTD
PSM15
PSM.DTD
PSM31
PSM.DTD
PSM85
Make
Channel
Make
Channel
Make
Channel
SDC_PSM.DTD
P15
Merge
Channels
P31
Merge
SDC_PSM.DTD
SDC_PSM.DTD
P85
{provides overlay layers,
two layers/PSM}
MapServer
Map
Server
MapServer.DTD
Make
Channel
SDC_MapServer.DTD
{provides overlay base}
Merge
Channels
Rescue
SDC Channel Management Interface
Merged PSM Channel
Rescue Channel
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
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
References
• Agility Project Homepage - http://www.objs.com/agility/index.html
• Agility Overview
http://www.objs.com/agility/tech-reports/0008-CoABS-Agility-Boston.ppt
http://www.objs.com/agility/tech-reports/9910-ScienceFairPoster-Agility.ppt
• Prototypes
• eGent: Agents over E-mail
http://www.objs.com/agility/tech-reports/9911-eGents.html
• WebTrader: Discovery and Programmed Access to Web-Based Services
http://www.objs.com/agility/tech-reports/9904-WebTraderWWW8Poster.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-characterizing-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-agent-ref-arch-draft3.ppt
• OMG Agent WG Homepage - http://www.objs.com/isig/agents.html
includes OMG Agent Technology Green Paper, RFI responses, liaison w FIPA, and minutes