Strawman Agent Architecture - Object Services and Consulting, Inc.

Object Services and Consulting, Inc.
Strawman
Agent Reference Architecture
(DARPA ISO coABS Program - Draft 8-31-98)
Craig Thompson
Object Services and Consulting, Inc. (OBJS)
[email protected], http://www.objs.com
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
DARPA coABS Objectives
Object Services and Consulting, Inc.
DoD Problem
•
•
•
Joint Vision 2010
ABIS Study
DARPA ISO next generation architecture
The Vision
•
•
•
networked society where every software artifact, information source, and device is
connected and running in parallel
intelligent automation-- application connectivity where networks of agents selforganize at run-time
scaleable, evolvable, reliable, secure, survivable, ...
The Challenges
•
•
•
what is an agent - an object with an attitude
control and complexity - agent, ensemble and system behavior that is predicable
and bounded
scalability and pervasiveness - agents for the masses
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Passing the Agent Test
Object Services and Consulting, Inc.
What is an Agent?
deconstructionist view:
agents augment objects with additional capabilities
Object
•
•
•
•
state
behavior
encapsulation
inheritance
Craig Thompson 972-379-3320 August 31, 1998

Component
•
•
•
•
reflection
packaging
serialization
repository

Agent
•
•
•
•
•
•
•
•
•
•
•

ACL
process inside
agent framework
planning
mobility
rules
…
goal/task-oriented
autonomous
ontologies
collaborative/teams
?
• TBD
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
What is an agent?
Object Services and Consulting, Inc.
• software that acts as a human’s agent to provide some service or
function in an intelligent manner
• modular software that exhibits some of these properties:
autonomy, mobility, intelligence
• objects with an attitude -- component software constructed
according to certain principles and/or mechanisms, e.g., objects
that use an ACL to communicate, objects that make use of a
planner, …
• more definitions at:
http://www.geocities.com/ResearchTriangle/Thinktank/4633/Agents_definition.html
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
The presentation consists of a list of views
of the Agent Reference Architecture
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
Operational Payoff View
what the end-user sees
Task
Agent
“Make it so!”
User
Agent
Info
Agent
Warfighter
INTERNET
Process
Agent
Agent systems offer the potential for rapid comprehensive response and adaptation to the dynamic battlefield.
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
Requirements View
Target operational requirements:
• Humans and agents connect to the agent grid anytime from anywhere and get the information
and capability they need. Enable teams led by humans and staffed by agents.
• Intelligent automation -- easier application connectivity where networks of agents selforganized at run-time. Reduce the 60% of time in command and control systems spent
manipulating stovepipes; incrementally replace stovepipes.
• Connect the $40B worth of DoD equipment that currently only interoperates with one or two
other components, permitting better knowledge sharing. Another example is a process
improvement in factory 1 is broadcast immediately to factories 2..N.
• Agent-enable object and web applications to reconfigure as new data and function is added
to the system. Add capability modularly. Stable, scaleable, evolvable, reliable, secure,
survivable, ...
• Scale to millions of agents so agents are pervasive and information and computation is
not restricted to machine or organization boundaries.
• Survivable so if one agent goes down, another takes its place;
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Characteristics of Agents
Object Services and Consulting, Inc.
Agents dynamically adapt
to and learn about
their environment
Agents coordinate
and negotiate to achieve
common goals
social
personality
Adaptive
Cooperative
to uncertainty and change
self-organizing
delegation
Autonomous
Mobile
Interoperate
Agents move
to where they
are needed
Agents interoperate
with humans, other,
legacy systems, and
information sources
proactive
Agents are goal directed
and act on their
own performing
tasks on your behalf
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
Agent Grid - System Concept View
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
Component
Data
Library
Service
A
A
A
Server
A
A
A
Data
Service
A
A
A
Server
A
A
A
A
Server
Data
Component
Library
Service
Server
A
A
Data
Service
A
Agents + the Global Grid
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Agent Ontology View
(aka Functional/Compositional View)
Object Services and Consulting, Inc.
ALP, HLA, IA
federates
heterogeneous*
• computing environ.
• agent systems
• ACLs
• content languages
• ontologies
• policies
• services
• open world
assumption
systemic
grid features
autonomous
decentralized*
scalability*
licensing & cost
mobility**
secure*, trust
IA
survivability
EDCS
evolvability
reliabile*
Quorum
More common services
instrumenting, logging
caching
queuing
routing, rerouting
pedigree, drill down
translation*
...
QoS*
• accuracy
• priorities
time-constrained*
Craig Thompson 972-379-3320 August 31, 1998
GRID
policy*, management
• resource dial
common services
distribution
messaging svcs*
agent life cycle* - start, stop,
checkpoint,
OMG
name service**
JTF
event monitoring
leasing, compensation Jini
catalog services*,
registry/repository*
register*,
offer/accept/decline
publish*, subscribe*
trading*, matchmaking,
advertising*, negotiating*,
brokering*, yellow pages*
security**
authenticate*
encrypt
access control lists*
firewall*
CIA model agent suspects
transactions
persistence*
query, profile (of metadata)*
data fusion
replication*
groups
multicast
(scarce) resource mgmt*,
allocate*, deallocate*,
monitor*,
local, global optimization,
load balancing*, negotiation
for resources*
scheduling
time, geo-location DDB
rules, constraints
planning*
property list
versioning, config
Architecture Principle: separation of concerns
deconstructionist view - what can you take away
and still have an agent system
AGENT SYSTEM
• single vs. multi-agent
agent properties & kinds
• communication
capability
• computation capability
• by role in system
• information agent I*3
• data sources BADD
• interface agent AICE
• NL
• fisheye view
• task agent
• web agent
• middleware agent
• mobile agent, itinerary
• social, personality,
motivation, forgetting
• intelligent agent
speech acts*: ACL* KQML, FIPA ACL, OAA
ICL
planning*
• reactive*
• goal interactions*
• discrete vs continuous*
• constraints
• iterative, revision
• workflow
learning
• by example
• ...
content languages
• KIF, FOL, IDL,
RDF
ensembles
• # of agents*
• teams, peers,
contracting,
• org. responsibility
• roles, capabilities,
• mutual beliefs
• hierarchy*
• conversational
policies*
societies
• closed vs. open,
communities of interest
control*, coordination*,
multi-agent synchronization
• cooperation, competition
adaptation, evolution*
via market model, ...
ONTOLOGY**
• ontolingua, OKBC
• metadata representations
• interests, locations,
availability, capability,
price/cost
• XML and web object models
infrastructure
primitives
• reflection
• serialization
• threads
• interceptors
• proxies
• filters
• multicast
• wrappers
• legacy sys
• data sources
missing
• views
• MOP
* = Architecture WG in Pittsburg
* = Control WG in Pittsburg
* = Interoperability WG in Pittsburg
red = Sun Jini
green = other DARPA programs
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
Information Access Framework
• heterogeneous data sources and domain object models
• properties:
• LAN or WAN at known location or dynamically available
• relational
• Oracle, Sybase, Informix, ODBC, JDBC
• OODB
• information retrieval
• simulators
• geographical informaiton systems
• semi structured sources
• html, xml , other formatted sources, image
• information integration services
• data source wrappers
• ifilter, subscribe, notify, monitor, push, pull
• persistence
• replication
• caching
• query decomposition
• multi tier queries - get info from one source to complete query
• source discovery
• trader, brokering, yellow pages, matchmaking
• source selection
• transformation, translation services, semantic integration and transformation, includes
• unit conversion
• domain and ontology services
• term translation , correlation services, name/place
• query translation (e.g., from OQL to SQL )
• fusing
• stream
• reflection
• control
• properties
• binding time ...
• indexing
• working in parallel
• iterative query reformulaiton
• change propagation
• if data sources change (alternate source)
• if query changes
• context of query
• statically
• dynamically - specified in plan, case-based reasoning, workflow
• metrics
• operation effectiveness - info quality, timliness and cost of retrieval
• breadth of coverage - completeness, data source complexity
• maintenance or evolution over time
• cost in labor hours
Craig Thompson 972-379-3320 August 31, 1998
• metadata properties
• operations covered
• query only vs update too
• data access systemic properties
• scaleable
• plug and play, open, component-based
• transparency of data location, access langauge, and protocol
• user queries
• static set vs dyanamic and frequently changing based on user task and need
• distributed
• all local to user machine, distributed on LAN, on WAN
• how homogeneous is content
• uniform across all sources
• unique per source
• overlapping sources
• partially redundant w inconsistencies
• incomplete
• homogeneity of information sources
• all in same query language
• syntatic differences
• multiple kinds
• source size - # of entity types
• 10, 50, >50
• semantic impedence w user
• no vs all query term translation
• source responsiveness
• quick (<10 sec; medium - up to 60 sec; slow - <3 min; very slow - <3 min; batch
• overnite; unreliable
• cost
• availability, permission, quality, quantity, capabilities, type,
• synchrony
• synchronous query and response
• asynchronous
• interuptable
• desired response control
• all answers at once
• client controls
• server controls
• top N answers
• requence of data source changes
• never, seldom (<1/yr); often >1/mo; continuous - real-time feed
• frequency of user query changes
• never, seldom (<1/yr); often >1/mo
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Relevant Theories View
Object Services and Consulting, Inc.
• speech acts, conversations/dialogs
• ontologies
• game theory
• economic markets
• patterns and protocols
• planning & case-based reasoning
• learns
• KBMS
• OO middleware service architectures (OMA/ORB)
• Web architectures
• distributed AI
• workflow
• dynamic DBMS
• simulation
• architecture description languages
• network management
• QoS
• ...
* = Architecture WG in Pittsburg
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Grid Federation View
Object Services and Consulting, Inc.
• enter and leave
• proxies
• services
• policies
Craig Thompson 972-379-3320 August 31, 1998
coABS grid
Borg collective
ALP cluster
HLA federation
DDB geolocation
IA enclave
swarm
domain
control regime
smart space
Jini
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Related Technology/Community View
Object Services and Consulting, Inc.
Some relevant technologies and communities
OMG
ODP
FIPA
HLA
WfMC
ALP
DCOM
I*3/BADD/AICE
Jini
HTTP-NG
DDB
digital libraries
HPKB
Quorum
W3C/Web
… we don’t want to invent yet another architecture
so the architecture views must not just concatenate to each other.
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
•
•
•
•
•
•
•
•
•
•
Agent Architecture Issues
What are agents? - code and data packets that are autonomous, adaptive, cooperative, mobile, interoperable … We
want all these properties in future agent-based systems. We need experience building systems with these properties.
Pervasiveness - How do we insure that the architecture stays lite-weight for wide-spread adoption.
Embracing heterogeneity - We must piggyback agent systems on already pervasive infrastructure like ORBs, the Web,
email, and DBMS systems. We must identify the specific kinds of heterogeneity we want agent system architectures to
support.
Separation of concerns
• agent-agent separation - can agents access each other’s state directly
• agent-service separation - do agents implement the long list of services that the grid provides or is that done via
underlying component-based middleware?
• grid-agent separation - agents are autonomous but they cooperate and compete for resources within the software
grid. The grid provides some global systemic properties and some basic shared services. Is there an explicit grid
or is it implicit in the way agents interact with each other? Are some “services” (like planning) optionally distributed
into agents or are they available from the grid’s planing service? Can new services be autoloaded into a grid that
does not have them?
Semantic interoperability, ontology - do ontologies scale? How do they extend class libraries?
Licensing - Agents, data sources, and component software need an economic model so broad communities can get
value from them. A model of licensing might be critical to success in the large.
Agent communication language (ACL) - Is the ACL compositional and extensible so one can define new speech acts
from existing ones? How many speech acts is enough? 20 or 5000?
Control points - where are the control points where different control algorithms might be substituted into the architecture
Grid federation issues - How are software grids federated - flat versus hierarchical models? If different grids contain
different policy choices or different services, how does that affect agents communicating across grid boundaries? Can
we add new services and -ilities to a grid once it is deployed? how transparent is addition or subtraction of services and
ilities
Coordination - Insure Agent Reference Architecture augments DARPA ISO ATAIS architecture. Provide template for
next generation unified OMG, FIPA, and W3C agent standards. Insure that reference implementations (toolkits) exist
and are widely available.
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
BACKUP
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
Towards an Agent Reference Architecture
Purpose of this presentation
•
to provide a number of views of a generic Agent Reference Architecture
What is a Reference Architecture
•
its a meta-architectural blueprint for a family of concrete architectures that may appear in implemented
systems, providing a collection of the component parts of the architecture, how they can fit together, and
any constraints on how they fit. A litmus test for a good reference architecture is that it covers actual
systems and provides a way to reason about missing pieces, subarchitectures that make sense,
interdependencies of parts, and how the architecture relates to other nearby architectures.
What should an Agent Reference Architecture do?
•
•
•
•
•
•
•
•
•
help people understand the scope and value-added of agent systems so they can realize their potential more
quickly (agents for the masses)
explain the principle components of Agent Systems and their interactions
explain how agent architecures solve DoD problems
explain how agent systems complement OMA, HLA, Web, DBMS, and other important system architectures,
also including AITS/NGII/NGA
identify missing components
identify what parts of the architecture already exist in COTS and GOTS, what parts are already prototyped,
and what parts are still needed. Map the coABS investment and what industry will do.
identify research issues (e.g., agent control, agent interoperability)
explain how to scale agent systems; also how to insure systemic properties of agent systems
identify candidate standards and a roadmap for adoption working with industry relevant consensus bodies
Status
•
this is a first draft and only covers some of the areas above. Textual notes augment this .ppt presentation.
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
DARPA coABS Working Groups
Object Services and Consulting, Inc.
Challenge Problem
DoD Domain: NEO Non-combatant evacuation order
quick insertion of temporary force
lots of uncertainty
most prevalent op
Control
Interoperability
smooth grid policy mgmt
how agent groups coordinate
planning, teams
allow many kinds of agent
systems to interoperate
naming, ACL, KIF, ontology
conversation policies, federation
Architecture
codify design of agent architecture,
esp. grid properties and services
what it means to be agent-ready
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
By Level in System *
Object Services and Consulting, Inc.
level 3: participant level
• user interface technologies
• domain entities like humans and simulated tanks
level 2: common apps level 1: control services level 0: network and connectivity -
* = used in 8/20 coABS chairs telecon
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Other Architecture Views
Object Services and Consulting, Inc.
(from Alan Piszcz, MITRE)
CONCEPT ORGANIZATIONAL
AGENT
ONTOLOGY AND STANDARDS
INFRADISTRIBUTED APPLICATION
MODELS AND
COMMUNICATION
KNOWLEDGE
ACTIVITIES STRUCTURE PROCESSING
AREAS
PATTERNS
LANGUAGE
REPRESENTATION
SYSTEMS
Autonomous
Broker
ARCOL
CYC
Agent Interop
Auditing
ATP
Critics
Benevolence
Active Object
FIPA97 ACL
GFP / OKBC
FIPA
Authorization
CORBA
Commerce
MAF
Design Eng
Collaborative
Adapter
KQML
GKB
Broker
DCOM
Coordination
Contract-Net
KQML97
JOE
Collaboration
HTTP
Discovery
Learning
Economy
KQML-LITE
KADS I+II
Configuration
Mngmt
Debugging
IIOP
Eager Assistant
Mobile
Federation
KIF
Pro-active
Mediator
K-ONTOLOGIES
Rationality
Negotiator
LOOM
Reactivity
Reasoner
ONTOLINGUA
Social
Societies
ONTOSAURUS
Veracity
PIF
Location
{Geo/Logical}
Naming/Direct
ory
Ontology
PSL
Persistence
SHADE
Place
SHELLEY
Resource Mng
RDF
Figure 1. Software Agent Systems Framework
Craig Thompson 972-379-3320 August 31, 1998
Human Agent
Interaction
Life Cycle
Routing
JAVA/RMI
Filters
KTP
Guides
OTP
Information
Mediator
Knowledge
Mining
Knowledge
Mngmt
Memory Aids
RPC
Network
Management
Resource
Translation
Situation
Monitoring
Workflow
Security
Time
Transaction
Payment
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Other Architecture Views
Object Services and Consulting, Inc.
(from Alan Piszcz, MITRE)
Application/
Mission
Software
Mapping
Protocol
(HTTP,ORB)
Agent
Wrapper
(AW)
Agent
Agent
Agent
Communication
Language
(ACL)
Agent
Communication
Language
(ACL)
RDBMS
WWW
Server
Agent Communication Channel (ACC)
Agent Based Dynamic
Virtual Private Network
Provisioning
Service
Provider
Agent
(SPA)
Personal
Communication
Agent
(PCA)
Directory
Facilitator
(DF)
Network
Provider
Agent
(NPA)
Agent
Management
System
(AMS)
Agent
Resource
Broker
(ARB)
Agent
Trigger
Services
(ATS)
Agent
Persistence
Service
(APS)
Agent
Ontology
Service
(AOS)
FIPA Specification
Application Specific Software
Non-FIPA service
Craig Thompson 972-379-3320 August 31, 1998
Figure 2. Agent Platform Reference Architecture
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
Other Architectural Views
Views Missing from this presentation
• review and refine all mapping
• identify additional requirements and map these to the Agent Reference Architecture
• identify additional issues and resolve issues
• recurse on sub-reference models for services and capabilities -or- point to existing
specifications from FIPA, OMG, or the agent community
• identify mappings from the Agent Reference Architecture to OMG OMA, HLA, etc. to
see the value added
• a mapping to implementations available as COTS or GOTS
• a mapping of coABS projects and components to other agent reference architecture views
• a priority view of components needed first, second, … by potential providers
• a roadmap for standards to complement FIPA’s and OMG’s (work through these groups)
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
•
•
•
•
•
Architecture Issues
requirements - from the point of view of DoD applications, what do we expect from agent technology. There are
many answers:
• replace stovepipe systems with more reliable, scalable, survivable, evolvable, adaptable systems. Make it
much easier to snap together future systems to meet flexible needs in uncertain environments
• reduce complexity - simplify agent technology so it is useful to the masses
• solve data blizzard, information starvation problems
We need to write these down and then provide mappings to agent architecture capabilities that make these
domain capabilities possible.
avoid yet-another-architecture - the agent reference architecture cannot be a wholly different architecture than
near-by relatives. It should overlay or augment architectures like ORBs, Web, HLA, Jini, ODP, Quorum, AICE,
ALP. Or it may be that it provides local agent architectures that can interoperate.
what are agents? - thin, thick, smart, dump, mobile, stationary, chatty, objects that use ACLs to communicate, …
We must tease these (possibly orthogonal) properties apart and understand what our technology is adding to the
picture. Especially if we want a large body of industry and DoD to adopt this next generation technology. Related:
criterial characteristics, minimal, maximal, lite or heavy weight - Are there criterial properties of agent based
systems? is there any minimal or maximal set of properties that we can agree on for something to be an agentbased system. Is it based on technical mechanisms (e.g., makes use of an ACL) or just any system with (some of)
these properties: autonomy, adaptive, cooperative, mobile, interoperable. How can we keep the architecture lite
weight and still accommodate all the services?
grid-agent separation - agents are autonomous but they cooperate and compete in some context which we are
terming the grid. The grid provides some global systemic properties and some basic shared services.
• are agents really autonomous (including being independent of the grid)?
• is there an explicit grid or is it implicit in the way agents interact with each other?
• are some “services” (like planning) optionally distributed into agents or are they available from the grid’s
planing service. Does this matter?
• is there a maximal or minimal (lite-weight) grid and what happens if agents interoperate that come from
differently configured grids?
• do agents ask other agents for their properties and grid capabilties
• can new services be autoloaded into a grid that does not have them?
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
•
•
•
•
•
•
•
•
Architecture Issues
agent-agent separation - can agents access each other’s state directly
agent-service separation - how are agents and services related? For instance, do agents implement the long list of
services that the grid provides or is that underlying component software? Does each agent contain a planner or is a
planning service global to a collection of services? It might be a wave-particle distinction.
embracing heterogeneity - it is clear we must do this if agents will live in internet settings. But we also cannot expect
systems to work with complete heterogeneity. The Web works partly because widespread agreement on HTTP, HTML,
XML, .. and DBMSs work because of SQL and related standards. So we must identify the specific kinds of
heterogeneity we want agent system architectures to support. It is not enough to say we are embracing heterogeneity.
semantic interoperability, ontology - how far beyond the standard OO class model or DBMS schema do ontologies
go; do they scale (most ontologies are pretty narrow), specifically which interoperability problems are solved
licensing - like many grid services, licensing’s degenerate form is no licensing. But agents and component software
cannot succeed without an economic model that makes broad communities get value from them. One way to do this is
via licensing space on your machine, capabilities and services, data sources, … A model of licensing might be critical
for coABS to succeed in the large.
Agent Communication Language (ACL)
• is the ACL compositional and extensible so one can define new speech acts from existing ones?
• How many speech acts is enough? 20 or 5000?
control points - where are the control points where different control algorithms might be substituted into the
architecture
grid federation issues
• how are grids federated - flat model, hierarchical
• if different grids contain different policy choices or different services, how does that affect agents communicating
across grid boundaries?
• can we add new services and -ilities to a grid once it is deployed? how transparent is addition or subtraction of
services and ilities
There are many other issues!
They are worth listing.
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.
Object Services and Consulting, Inc.
Challenges
Challenges for DARPA/ISO Next Generation Architecture
• What can coABS build on from other DARPA programs? Are reference architectures,
service specs, common schema, data sources, reference implementations readily
available in the NGA repository for plug-and-play? How about implementation guidance?
• What is our plan to transfer DARPA/ISO NGA architecture, specs, and implementations
inside DARPA and outside to industry via standards and products?
• How do we insure lite-weight meta architectures that are still evolvable?
Challenges for coABS
• Risks: silver bullet, overpromising, pin-down coABS unique contribution, do planning
techniques scale for Internet and programming language communities?
• Define agent functions, keep complexity manageable for the programmer in the street.
Insure the systems are implementable via prototyping; share toolkits where possible;
build on COTS and GOTS where possible.
• Coordinate with DDB, AICE, and Quorum on design of an open decentralized global grid.
Borrow and unify ideas of clusters, federates, enclaves from OMG, ALP, HLA, IA, Jini.
Unify agent architecture with HLA, Web, ORB, workflow, ...
• Insure coABS reference architecture provides template for next generation unified OMG,
FIPA, and W3C standards and that reference implementations (toolkits) exist and are
widely available.
• How do we foster an economy of componentized agent software?
• micro licensing component software and leasing resources across the network
• crossing organizational boundaries so the net is the DBMS, the net is the computer
• how to populate space with 100,000 advertisements?
Craig Thompson 972-379-3320 August 31, 1998
© Copyright 1998 Object Services and Consulting, Inc. All rights reserved.