He also noted that military needs for agent technology can be translated into these issues, e.g.:
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:
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:
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.
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.)]
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.
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.]
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.
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 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.