B. Kettler, ISX (1/99) 1 The CoABS Grid: An Overview Brian Kettler, Ph.D. ISX Corporation 11 January 1999 OMG Agent Working Group Meeting

B. Kettler, ISX (1/99) 2 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!

B. Kettler, ISX (1/99) 3 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

B. Kettler, ISX (1/99) 4 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)

B. Kettler, ISX (1/99) 5 CoABS Researchers

B. Kettler, ISX (1/99) 6 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

B. Kettler, ISX (1/99) 7 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 , etc.)

B. Kettler, ISX (1/99) 8 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 Internets support for interoperability among networks with different protocols GA = Grid-aware Agents

B. Kettler, ISX (1/99) 9 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., CMUs RETSINA, Dartmouths DAgents, SRIs OAA

B. Kettler, ISX (1/99) 10 Grid Development Approach (contd) 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

B. Kettler, ISX (1/99) 11 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

B. Kettler, ISX (1/99) 12 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)

B. Kettler, ISX (1/99) 13 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 –???

B. Kettler, ISX (1/99) 14 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

B. Kettler, ISX (1/99) 15 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)?

B. Kettler, ISX (1/99) 16 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

B. Kettler, ISX (1/99) 17 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.

B. Kettler, ISX (1/99) 18 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.

B. Kettler, ISX (1/99) 19 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.

B. Kettler, ISX (1/99) 20 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.)

B. Kettler, ISX (1/99) 21 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.)

B. Kettler, ISX (1/99) 22 Additional Information CoABS – The Grid –Use Case document