b. kettler, isx (1/99) 1 the coabs grid: an overview brian kettler, ph.d. isx corporation...

B. Kettler, ISX (1/99) 1

The CoABS Grid: An Overview

Brian Kettler, Ph.D.

ISX Corporation

[email protected]

11 January 1999

OMG Agent Working Group Meeting


Agenda

• Brief overview of CoABS program– Caveat 1: Views are mine, not DARPA's (etc.)– Caveat 2: Program is young (6 months) and still evolving…

(more will be known after late January workshop in Las Vegas)

– Caveat 3: Program just beginning to reach out to wider community (FIPA, OMG, etc.)

• Overview of “The Grid”– Caveat 4: Very much a “Work in Progress” (2-3 months old)– We need input!


The DARPA Control of Agent-based Systems (CoABS) Program

• Goal: research/develop agent technologies supporting:– semantic interoperability among heterogeneous agents

• efficient interagent communication at level of goals/tasks, problem/domain elements (shared context, intent, etc)

• dynamic (run-time) collaborator discovery and cooperative problem-solving behavior (dynamic teams, etc.)

• greater levels of autonomous action (taskability, adaptability, etc.)

• easier integration of software components (including agents, legacy)

– large scale multiagent systems• many agents of varying sophistication/complexity on large scale, real-world problems

in dynamic, uncertain environments

• exploitation of parallelism

• efficient use of resources

• avoidance of chaotic behavior


CoABS Program Organization

• Government– PM: Prof. James Hendler (DARPA Information Systems

Office)– Mr. Rick Metzger (USAF Research Lab/Rome)

• Potential Customers– AMC, Other DARPA programs (ALP, etc.), ??? (TBD)

• Integration Contractor– Global Infotek, Inc. (GITI)– ISX Corporation

• Research Groups (university and industry) (~20)


CoABS Researchers


CoABS Program Efforts

• Technology Integration Experiments (TIEs)– Operationally-focused TIEs

• 3 for late Spring 1999

• existing components/architectures (OAA, RETSINA, Prodigy, etc.)

• NEO (Noncombatant Evacuation Operation) scenario

– Scientific TIEs• experiments on control, scalability, etc.

• The Grid


The Grid: Broad Vision• A Scenario [by Paul Cohen & CoABS Steering Cmte]

– You are an infantry battalion commander who connects your PDA online...

– Your personal assistant agent connects to the Grid• tells Grid your physical location, current tasks/goals/plans, resources, capabilities,

needs, etc.

– Meanwhile, the Grid adjusts to you...• i.e., can take advantage of your extra resources (physical, computer, etc.) &

capabilities:– sends you the latest status reports relevant to your goals/interests– run a meteorological simulation on some of your battalion PCs– due to your expertise in Arabic, sends you documents to translate

• Grid resources, priorities, and goals adjusted dynamically

– When you (temporarily) disconnect from Grid...• it prepares for your return (generates reports, filters email, etc.)


The Grid• The Grid is an infrastructure supporting the

semantic interoperability of agent groups, each with potentially different agent architectures

•e.g., A group of OAA agents talking to a group of RETSINA agents

•Analogous to the Internet’s support for interoperability among networks with different protocols

GA = Grid-aware Agents


Grid Development Approach• GITI/ISX is coordinating this effort• Define Vision for Grid

– define operational scenarios for its use

• Define Requirements - top down approach– define basic set of use cases (later expand for different kinds of

applications - e.g., planning agents)– define minimal services Grid must have - produce service-level

description (message syntax/semantics)

• Define Requirements - bottom up approach– canvass community (initially CoABS but also wider)– look at existing agent services

• e.g., CMU’s RETSINA, Dartmouth’s D’Agents, SRI’s OAA


Grid Development Approach (cont’d)

• Design/Develop Prototypes– build something (and they will come…)

• a strawman versus waiting on the definitive specification• initially implement base subset of use cases• deploy and let community experiment with it

– multiple implementations of a service are desirable – enumerate design assumptions & issues

• many are open research problems!

• Enumerate additional requirements– from operational/functional TIEs, scientific TIEs– incrementally refine, replace, update service specifications and

implementations


Some Initial Simplifying Assumptions

• Focus on functionality, vs. performance– “Real” Grid must consider fault tolerance, failure

recovery, comm bandwidth, CPU cycles, etc.

– scalability will be paramount

• Keep it simple (at least for now)– define a minimal set of Grid services

• agent communities also will have their own services

– define a minimal set of messages an agent on the Grid must support


Use Cases• Actors

– Users• Application End User

• Grid/System Administrator

– Agents• Grid-Aware Agents - can join the Grid

– Application Agents (problem solvers, resource mgrs., interface agents)

– Grid Service Agents (Registration Agent, Security Agent, etc.)

• Non Grid-Aware Agents

• System– The Grid

• Grid Services (Agents)


Use Cases for Any Grid-aware Agent (GA)

• Most basic:– GA connects to Grid– GA disconnects from Grid– GA posts request/need to Grid– GA posts capability/service advertisement to Grid– GA asks/requests another GA (i.e., direct agent-agent comm)

• Additional use cases:– GA makes log/checkpoint entry– GA sets/clears timer– GA gets a security “check”– ???


Grid Registration Agents (GRAs)• Map Grid ID of GAs to their address

– I.e., naming/white pages service

• Store addresses of some (local?) GAs– DNS-style address scheme?

• Assign new Grid IDs to new GAs– globally unique, persistent IDs

• Communicate with other GRAs• Check GAs credentials, permissions, etc. with Grid

Security Agent


Grid Matchmaker Agents (GMMAs)

• Map capabilities/services to IDs of GAs– i.e., yellow pages service

• Store capability descriptions (i.e, ads)– need some language for these (vocabulary -> ontology)

• Have query capability (e.g., nearest neighbor matching, etc.)

• Communicate with other GMMAs– organized hierarchically? by topic (or location)?


Grid Management Agents (GMAs)• Support management of Grid by agents and users• Provide Grid status (to other agents)

– Grid comm infrastructure (i.e., network sensing)– Can obtain status info from other GAs– status info can be sent to Grid Visualization Services (i.e., interface

agents on the Grid)

• Detect problems– deadlock, livelock, etc.

• Can exert control over GAs– request they start/stop/suspend, etc.

• Can startup/shutdown other GSAs


Other Grid Service Agents (GSAs)• Grid Event Management Agents

– support setting/clearing timers– may support other kinds of events (and possibly

triggers/sentinels)– keep GMT (Grid Mean Time)

• Grid Logging Agents– store activity/state info for GAs– support querying of this info for debugging, visualization, etc.

• Grid Security Agent– provide authentication, access control, etc.


Other Potential Grid Services

• Mobility– support transport of running agents– interface with control services for load balancing, etc.

• Exception Handling– handling of common exceptions– reduce burden on agent programmer

• Programming Tools– facilitate construction of Grid-aware agents– e.g., wrapping legacy agents and non-agent components,

debugging, etc.


Some General Design Issues• Services provided by Grid (versus elsewhere)

– also customizability via policies, tuning, etc.

• Grid Comm (messaging infrastructure, ACLs, etc.)– e.g., sockets or some higher level messaging mechanism (RMI, CORBA,

etc.)– e.g., one or several mechanisms/ACLs supported

• GA-to-GA, GSA-to-GSA, etc.

• translation services provided?

– consider platforms, footprint, COTS software required, etc.– lightweight vs. heavyweight ACLs (vocabulary vs. ontology)

• Built-in (vs. add-on) support for mobility, security, fault tolerance/recovery, etc.


What We Need (1)• Additional use cases

– higher-level/more specific?• e.g., planner requests sentinel agent to monitor for threats to

plan

• Refinements on service-level descriptions of Grid• Components to leverage for services

– other CoABS and non-CoABS agent services

– other services? (CORBA trader, event, etc.)


What We Need (2)

• Agent communication mechanisms– low-level messaging mechanisms (e.g., sockets, CORBA, etc.)– wrapper language (e.g., KQML-Lite, etc.)– content language (e.g., KIF, etc.)– ontology, service description language

• HPKB upper level ontology, etc.

• Agent Visualization techniques/tools– for debugging, demonstration, etc.– low-level activity (comm level, CPU, etc.)– comm content, patterns, etc.– higher-level activity (teams, subproblems, etc.)


Additional Information

• CoABS– http://dtsn.darpa.mil/iso/

• The Grid– Use Case document

• email [email protected]

b. kettler, isx (1/99) 1 the coabs grid: an overview brian kettler, ph.d. isx corporation...

Documents

grid slide

grid grid services agents

coabs grid

grid resources

grid caveat

minimal services grid

gridaware agents system

performance real grid