Trip Report

CoABS Meetings

March 11-12, 1999
Arlington, VA

Frank Manola
Object Services and Consulting

CoABS New PI Meeting, March 11

I attended a CoABS meeting held at Schafer Corporation, in Arlington, Virginia.  The purpose of the meeting was to brief new CoABS PIs and program other participants as to the overall goals of the program and its major activities, and to enable them to start to determine how their particular activities fit into the program.

Program Overview

Jim Hendler gave an overview of the CoABS program.  He indicated that there was still a need to get a precise idea of what "agents" were in the context of CoABS.  He also indicated that his goal was to be ahead of standards activities, like FIPA, and not following them (he also noted that much relevant activity in FIPA was by people  funded by CoABS).  He said that as far as the program was concerned, the important agent technologies included: i.e., infrastructure/architectural types of issues.

He also noted that military needs for agent technology can be translated into these issues, e.g.:

[NB:  Information management in general, e.g., generalization of federated DBMS concepts to object and agent architectures, is also a big issue in the large-scale operational architectures into which agents would be integrated.]

Jim gave an example of "low-hanging fruit" that CoABS should be looking for, describing a situation where people at a military facility were copying numbers from one Excel spreadsheet and manually entering them in another, due to the lack of interoperability mechanisms.  Here, straightforward wrapper technology would have been extremely helpful in this situation, and there may be other problems which might be overlooked (as being thought too simple) that CoABS-related technology might help with (and might not necessarily involve agents, per se, at all.)   [This reminds me of my first visit to CINCLANTFLT shortly after starting work at NRL.  I was working on database technology, and was asked whether database technology would allow them to access a file in more than one order without having to re-sort the data.]

He noted that the military's emphasis is now beyond a simply "network centric" view (in the sense of thinking that simply getting everything connected on the network is the goal).  One reason is that while in that model all the information is available, users still have to figure out what they want and try to find it.  What they are looking for instead is "precision-guided information", where the system maintains a real-time dynamic picture of the situation, and presents users with customized information, tailored to their requirements, on a schedule that meets there needs (and is updated when user-relevant changes occur).  [A lot of this, again, is essentially layered on HDDBMS technology and concepts, when agents (processes), active data, and mobility mixed in.]  The picture is that of an adaptive community of disconnected and dynamically-changing heterogeneous resources.

Prior agent work often focused on performatives, ACL semantics, etc., leaving such things as content, advertising metadata, etc. to be dealt with in an ad hoc way.  CoABS is intended to address some of these other issues that have to be addressed in building large-scale agent-based systems.  He also noted that CoABS was intended to be genuine science, with demos emphasizing the scientific/technical issues being addressed (and that DARPA wanted to see more science).

Jim described three scaling axes:

A possible fourth axis was the information complexity involved in the agent system.  [Jim mentioned ALP in this connection as an example of a system with lots of agents, and in which the agents were pretty complex (although in a regularly-structured way).]  There is a need to look carefully at existing systems, to determine whether their architectural assumptions scale during movement along these axes.

CoABS is to pull distinct areas of agent work together in building real systems.  He described the Grid as a system for testing agents.  The goal is to pull together work on:

People working in these areas typically ignore each other, and one of the goals of the Grid is to force these people to come together and build complete systems.

The next workshop is scheduled for June.  At that time, there should be demos of the NEO TIEs, and talks about the Scaling TIEs.  Slides of the talk will be placed on the Web site.

Grid Overview

Brian Kettler (ISX) reviewed work on the Grid.  Brian described the Grid as a matrix facility for connecting the four types of agents Jim mentioned above.  He used as an analogy the way the Internet originally functioned as a way of providing interoperability between separately-developed networks which used different technologies, following which Internet-native applications proliferated.  He sees the Grid as needing to connect and deal with legacy systems and data, not just agents.  He described related Grid Vision and Grid Engineering efforts.  The intial Vision draft is scheduled for the end of March.  In terms of Grid services, they have wrapped the RETSINA Matchmaker to use as an initial broker service, and are also thinking in terms of "high-level" services such as MIT's exception-handling, translation, ontology, control, etc. as well as "lower-level" services along the lines of CORBAServices.

Their current prototype uses a FIPA system written in Java acquired from SPAWAR as a base, which they are modifying and adding to.  The system will support non-Java agents as well.  They intend to support six basic services:  naming, directory, translation, logging, visualation, and brokering.  They also intend to include some of the Jini discovery (join, lookup, events) mechanism.  Since their prototype broker is the RETSINA Matchmaker, LARKS is the current resource description language, but this can change.  The translation service is intended to support translation of FIPA ACL to KQML and ICL (the OAA ACL).  They have defined an Agent Activity Markup Language (AAML) in XML as a content language.  They also write agent logs in XML.  The visualization facility is Web-based, and involves agents having URLs with agent homepages, and dynamic information (using XML) being generated for display about agent status, etc.

[Brian mentioned that one of the issues involved in the Grid is how much control the Grid has over individual agents.  I commented later this this might be application-dependent, rather than being inherent in the notion of a Grid.  In other words, someone has to explicitly decide what the architecture's (that is, the Grid together with all the agents) capabilities are intended to be, and this will help determine how much control the Grid needs to have over individual agents (or conversely, how much control agents that participate in the Grid must be willing to give up.)]

NEO TIEs

Onn Shehory (CMU) reviewed work on the NEO TIEs (standing in for Katia Sycara).  He noted that there was a concurrent TIE meeting taking place at GITI.  He noted that the original CoABS goals involved mission planning and execution monitoring [therefore clear potential ties to ALP], and that the NEO TIE involves both planning and execution monitoring (and also replanning, since there's a scenario where an airport explosion prevents the originally-planned airport from being used, and hence replanning must take place.  [During his presentation, it occurred to me to wonder how the legacy system wrappers being used dealt with the situation where the legacy systems were being updated not just by the wrapper, but by external connections (e.g., would the wrapper continually poll for new information, or try to install notification?)].

Scalability TIEs

George Cybenko (Dartmouth) reviewed work on the Scalability (formerly the Scientific, now apparently called the Robustness) TIEs.  George mentioned ALP as providing potential scenarios and issues to this TIE, and also noted that a hierarchical command structure was a realistic basis for estimating potential deployment scaling needs, since the command structure helps pre-determine the number of agents, and the number of agents each other agent might have to talk to (another aspect of ALP that is relevant to the CoABS program). Someone asked where they were going to get several thousand agents for performing real scalability experiments.  George said they were going to do a certain amount of cloning, but this gave me the opportunity to mention ALP's potential role as a vehicle for such scaling experiments.  George also mentioned the need to investigate the performance of mobility for different types of agents, and also the performance of other mechanisms as the types of agents change.  For example, for large numbers of simpler agents, economic decision mechanisms work, but for more complex agents, and different problems, different decision-making mechanisms (e.g., for matchmaking) might be more appropriate.

George also described the work on robustness and "QoS", e.g., the MIT work.  I noted that they ought to be working with the Quorum program on that, since an end-to-end solution involved complete consideration of those issues below the "agent level", and that Quorum was already working those lower levels.  What would be nice would be if CoABS could somehow characterize any distinct "Agent QoS" issues, and merge them into the work that Quorum is already doing.

General Discussion

General discussion followed.  It was noted that the NEO TIEs were concentrating on teamwork and team creation issues, and generally ignoring scaling, leaving that to the other TIEs, and that it was important for each set of TIEs to carefully identify what its (scientific) goals were, and how what the TIEs accomplished illustrated progress on those goals.  We then went around the room and described what we were doing (no signup sheet circulated, and I didn't get everyone's name and affiliation, as the introductions were very hasty).  Joe Pasquale (UCSD) indicated that he was primarily a network and OS guy, and was looking at network and OS-related mechanisms to support mobile code, and mobile code systems with QoS.  I mentioned the connection that Jeff Bradshaw had established with Sun to work, among other things, on JVM extensions to provide low-level support for mobility, resource management, and other stuff, which Joe found interesting.

Jim mentioned the rather limited visualization facilities available in ALP, and said Todd Carrico had told him that CoABS agent visualization technology would be a good technology transfer area (since practially every agent project had developed some interfaces for users to give agents instructions, and visualize what the agents were doing).  An example of potential transfer would be the XML-based dynamic Web page generation facilities that Brian had mentioned in his Grid presentation.  Doyle Weisher said that the official ALP "party line" on how visualization would be handled was something called "CPOF" (?).

George Cybenko seemed very interested in ALP interaction.  This makes a lot of sense,  since ALP would provide a good test of the scaling capabilities of CoABS technology.  He said that Steve Milligan was coming up to Dartmouth to talk to them (I told him Steve Kotz had invited me up too).  I suspect Katia Sycara would also be amenable to ALP interactions.  [These TIE presentations cause me to think that the next level CoABS folks it would be reasonable to talk to about ALP interaction would probably be the TIE coordinators/organizers, e.g., George and Katia.  In this connection, I also need to talk to Marshall Brinn regarding ALP availability issues for CoABS experiments, e.g., is the code available?  what kind of access can CoABS folks get to ALP (and information about it, e.g., to their Web site)?  which pieces?  etc.]

Other

Following the meeting, I spoke with Doyle Weisher (GITI).  Both he and I recalled meeting before, but couldn't remember where.  He is the former ALP PM.

Jim said he had an article coming out in Nature (the British science magazine), and that he was being interviewed on NPR today.  Nature's homepage is www.nature.com.

I need to find out from Jim and Todd how open I can be about material produced under the CoABS-ALP effort;  e.g., can I distribute the design document around to the other CoABS projects?  what procedure to go through before release?  etc.
 

Meeting with Brian Kettler, March 12

I met for about two hours with Brian Kettler at ISX, discussing the relationship of the CoABS grid and ALP.

Brian described a number of general connections between earlier work on agent-based planning and issues arising in ALP.  For example, he mentioned a predecessor program to CoABS, the DARPA-Rome Labs Planning Initiative ("Arpee"), also referred to in DARPA as the "Planning Decision Aids" program.  SRI developed the MultiAgent Planning Architecture (MPA) under this program which sounded fairly ALP-ish.  Brian also described an ALP-like monitoring scenario where a plan agent produces a plan, hands it to a sentinel agent, and tells it to "monitor the plan for threats".  Supporting this involves the need for a common understanding of the plan representation, what the particular plan agent would think of as a threat, etc.

Brian had a general picture of what ALP was about.  I described some additional details (the various internal components of a cluster, what their jobs were, how that agent structure related to more conventional ones, what plugins did, how clusters communicated, etc.)

We discussed a number of potential areas where CoABS technology could contribute to ALP, and vice-versa.  For example, ALP provides a good test case for CoABS technology (e.g., in terms of scale).  We agreed that major areas of interaction between the Grid and ALP would be things like heterogeneous interoperability and discovery (matchmaking, etc.).  Brian suggested two models (others may exist) for connecting ALP to the Grid:

We also noted that there was an issue as to how dynamic the agent organization would really be in an operational system, since in most large organizations, as in ALP (military logistics application domain), there are business processes that govern most of the work most of the time, and these processes largely determine who you interact with to do what.  While there is obviously a need for openness and dynamic discovery, there is also a need for the predefined cases to be handled using more direct mechanisms.  Non-agent interactions also need their own direct mechanisms.  Thus, it may be that Grid services other than discovery might prove the more valuable for ALP's immediate applications.

We agreed that, since the Grid capabilities currently being defined were pretty basic, it didn't seem likely there would be any major issues raised by integrating ALP that would affect Grid interface definitions.

I gave him two copies of the design document.  He promised to look at it, and forward a copy to Doyle Weisher.  He also said there were folks at ISX involved with an ALP plug-in, and he'd try to get feedback from them too.  I said I would try to bounce ideas for CoABS (especially grid) and ALP interactions off him, and hoped he'd bounce any ideas he had off me.  He said the Fall would be a good time to target for these TIES, and we agreed that scenarios involving such things as dynamic configuration, coalition operations, and access to local suppliers might be the basis of these TIEs.

We also discussed the CoABS grid work itself. Brian reiterated the point he'd made in his Grid presentation at the CoABS meeting, that the Grid needed to support legacy systems and data, not just agents (which accurately reflects our view as well).  An important issue in this regard will be scaling.  Much of the hard-core agent community looks at relatively small numbers of fairly complex agents, whereas the Grid needs to provide support for large numbers of agents, many of which will be "dumb" (objects or even data).

Brian said that the Grid vision was still not clear, and evolving (which, I think, reflects everyone's situation).  I suggested he look at the Grid concepts in, e.g., ABIS, as background, since I felt that seemed to be the general flavor of the Grid as described in the look-ahead document, as opposed to purely computational grids;  I noted that I was updating my Grid white paper to include the ABIS and Network-Centric Computing concepts for that reason.  He said he thought our work on characterizing Grids was valuable in helping clarify what the Grid should be doing, and was interested in continuing interaction on that subject, e.g., via the Grid Vision paper he is working on.

Brian also mentioned the forthcoming Grid meeting in Philadelphia, and I told him what I knew of the background behind Sun's involvement in that meeting, based on the February meeting at Sun I'd attended.

Overall I think we established a good basis for future cooperation as the result of this meeting.