1. Read Chapter 10 – Market Place Application
This chapter develops the idea of multiple, autonomous agents that can interact with each other and do useful work. The focus is on an application that works in a marketplace environment where there are buyer and seller agents. The buyer and seller agents cooperate and compete to process sales transactions for their owners. A facilitator agent is also presented who functions as a manager for the market place. Both rule-based inferencing and hard-coded logic are used in the negotiation strategies.
2. After implementing the Market Agents of Chapter 10 in assignment 4, do either of the following:
* Augment the Market Agents with improved or additional functionality; or
* Design your own agent system based on the Market ideas.
As noted in the last assignment I found an open-source implementation of a distributed multi-agent system that was built to support a Defense Dept. logistics system. COUGAAR is an acronym for “Cognitive Agent Architecture.” I decided to dive a little deeper into the Cougaar environment and see what kind of additional functionality could be added to the Pizza Party application.
If you recall, the Pizza Party Application entails eight Cougaar agents split across two processes (“Nodes”), planning a pizza party. This simple application shows Cougaar agents acting as social planners for 4 friends: Alice, Bob, Mark, and Tony. Alice is planning a pizza party. Her Cougaar Agent takes care of inviting all her friends on her buddy list. The Agents for Bob, Mark, and Tony take care of answering for them. Because it is a pizza party, they must tell Alice whether they like “Meat” or “Veggie” pizza.
Once Alice knows how much of what kinds of pizza to order, she must find a Pizza Provider. Pizza Providers sell “Meat” and/or “Veggie” pizzas — and Alice wants to order all her pizza from one provider. Alice knows how to do “Service Discovery”. She does look-ups in the Yellow Pages, where pizza parlors advertise their services. This is how she finds Joes originally, and this is how she can find a new provider, if Joes isn’t good enough.
One of the nice things about the Market Place application was being able to see what the Facilitator was doing. The facilitator, buyer, and seller agent essentially comprised a small society an we could see the interactions between them fairly easily. However, in an realistic implementation the size of the society would be significantly larger. The largest possible society would be the Internet, but we don’t really want to think about the complexities involved in that one. A more realistic scenario would be a large organization that had offices around the world where the agents supported different branches of the same organization. This reduces the threat analysis considerably.
In a scenario like I just described it would be much more challenging to keep track of what all the agents were doing and how they were configured. A very good addition to the agent architecture would be a configuration management utility that would discover and provide status information for the various entities within the society. This should be a dynamic process where the agents register themselves and periodically send configuration status information to the configuration manager. This will allow the configuration manager to monitor the heath of the society since if a registered agent stops updating its status then it can be flagged as inoperative and eventually removed from the society.
In the Cougaar Architecture there are a number of Plugins that can be implemented to provide this functionality.
Configuration Manager Plugin
Overview – The Configuration Manager Plugin (CM) is a plugin that manages the configuration on any agent in its configuration community. This plugin receives and composes agent configurations from agents residing on various nodes and sends the composed set of node configurations to parent configuration manager(s). If the plugin has other configuration managers that report to it then the plugin will integrate the configuration and status information from the child managers into its local society representation.
Responsibilities – The Configuration Manager Plugin is responsible for subscribing to and processing all configuration directives from agents in the same configuration community. If the CM has parent managers it needs to send the collected information it has composed to those parents. If the CM has child managers, then it needs to handle incoming node configurations and compile them into the complete society representation. The CM is responsible for gathering agent status information and responding to node status request messages.
The CM is certainly a responsible agent!
All of the efforts by the CM would be much more useful if we could view it graphically. To this end a viewer has been implemented so that you can see how everything is connected in the society. Because the number of agents can get large very quickly the viewer provides two methods to narrow down the display; filters and a search mechanism.
I downloaded the Cougaar Configuration Manager project files and installed them into my base Cougaar installation. http://cougaar.org/projects/ccm/
The original Pizza Party Node Configuration files have been replaced with new ones including the CM functionality. Each agent has the following additional agent definition in the XML file:
To test the CM I started up the Pizza Party nodes again.
This triggered the CM Viewer Application to launch. The viewer is divided into three main sections: The upper left provides a dynamic tree view of the society showing the Nodes, Communities, and Computers that are hosting the activity.
You can expand the elements in the tree to drill down into the society hierarchy as shown in the following diagram. Note the Health Status indicator and how you can see the individual components making up the Mark Agent.
The upper right of the viewer display is used to show the dynamic interconnect structure of the element selected in the tree. In the following image you will see the Mark Agent and the components and communities that Mark has or belongs to.
To show the real interconnectedness and power of the viewer I selected a community; Friends of Mark, and you can see in the display how the viewer dynamically arranges the nodes.
While this is really cool it would obviously get overwhelming if you had a hundred or more agents and lots of communities. Below is an image showing all the elements running on just my computer.
Very busy! To deal with that the bottom section of the viewer provides a method of filtering and searching.
The view also provide CPU and Memory utilization statistics to judge the impact of running the agent architecture on the hardware platform.
The Configuration Manager is a powerful tool for keeping status information on a large society. It would be extremely helpful in troubleshooting errors in the system. Because the agents report to the CM it would be easy to add functionality to the agents to manipulate them on them fly; modifying parameters or tasking them to accomplish something.
This exercise expanded my understanding of the inherent difficulties in managing large groups of agents in a complex society. The value of registering agents through a yellow pages service and providing the ability for your agents to practice service discovery is immediately apparent.