• 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 self-organized 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;
Architecture Principle: separation of concernsdeconstructionist view - what can you take away
and still have an agent system
secure*, trust
societies• closed vs.. open,
communities of interest
learning• by example• ...
mobility**
heterogeneous*• computing environ. • agent systems• ACLs• content languages• ontologies• policies• services• open world
assumption
autonomousdecentralized*
xxx = Agility addresses these* = Architecture WG in Pittsburg* = Control WG in Pittsburg* = Interoperability WG in Pittsburgred = Sun Jini green = other DARPA programs
• describes views of the Agent Grid as• a set of agent mechanisms
• a global registry/system management backplane environment for agents and agent systems that provides resource, services, and system wide properties
• a collection of interacting semantic grids representing various kinds of collections: organizations, teams, … ensembles (including ALP) all acting like mini-grids to control local resources
• all of the above
• lists grid architecture issues• Is the agent grid itself a kind of agent system?
• Is the agent grid logically centralized? hierarchical?
• How can we use existing object services? Must they be wrapped as agent services?
• Is there a minimal set of services?
• will be published in Bradshaw’s agent book forthcoming
• In Progress• AgBot - Use reflection to automatically extract Java agent capability description
(a la search bots)• WebScribe - record user surfing actions, use as an information agent• AgBot and WebScribe can advertise via WebTrader• Embed lightweight web servers within agents
• WebTrader is a scalable trader (matchmaker) that indexes XML-based client and service advertisements embedded in Web pages. Query results allow clients to connect to the most suitable service.
• Leverages Web search engines, which index the advertisements - scalable, liteweight, portable, robust.
• Demo shows service binding, rebinding, and trader federation (recursively searching other traders).
• The current focus is ad type spcialization and ad synthesis. Advertisement types include components, agents, data sources, search engines, MBNLI grammars, EC objects.
• Could be used as a scalable “blackboard” for advertising intermediate results.
• NEO TIE combines WebTrader with SRI OAA and ISI Ariadne
• Paper: Venu Vasudevan and Tom Bannon, WebTrader: Discovery and Programmed Access to Web-Based Services, poster at: The Eighth International World Wide Web Conference, Toronto, Canada, on May 11-14, 1999.
• OMG Agent WG Homepage - http://www.objs.com/isig/agents.htmlincludes OMG Agent Technology Green Paper, just released RFI, liaison w FIPA, and minutes
• 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.
Comments• the ALP architecture is not logistics-specific • the current ALP implementation is (nearly) 100% Java for portability. Interoperability interfaces to non-Java
environments (RDBMS, CORBA, C++, ...) are established by lower level interoperability mechanisms.
Similarities• an individual cluster is like an agent with plug-in components for expanding tasks, allocating resources, assessing
status, and information access • a society (federation) of clusters is like a multi-agent system (or possibly a grid?). Most "conventional” agent
architectures impose somewhat more organization on the participants (e.g., in their use of Matchmaking components and rich ACLs) than the cluster architecture does.
• cluster relationships tend to mirror organizational and other dependency relationships - decentralized control possible but tends to be top down mirroring DoD command structures
• agents are wrappers of existing legacy functionality. (More correctly, clusters are containers. It's the plugins that wrap legacy functionality (and most of the other functionality as well; the clusters provide generic organization capabilities for the plugins, which actually do the work).
Differences (at the present time) *• clusters/agents are not currently mobile • ALP clusters do not communicate via ACL. They communicate via directives and the log plan they are all contributing
too; extending the directive vocabulary is a known issue in ALP, and one to which some kind of ACL could contribute a solution (this is noted in the design document).
• ALP does not currently use Traders • ALP does not currently use agent frameworks (it uses Java, and Voyager now but is moving toward using Jini) • there is no "list of services" that are available as in the OMG services architecture (naming, transactions, perisistence,
query, ...) • there is no particular provision for insertion of systemic properties into the architecture (so called iQos/ilities like
security, survivability, scalability, evolvability, reliability, ...) but the architecture evidences several -ility related patterns (e.g., scalability via federation).
• no global grid optimization but cost functions and penalty functions provide some decentralized global control business rules are inside of plugins (when they exist at all) and not visible at the cluster level
* the ALP architecture does not preclude these. It just has not addressed them yet.
ALP as a Grid?Compare and contrast the ALP architecture and the CoABS grid
