Slide 37 of 78
The OAA is currently a research prototype exploring techniques for enabling more flexible interactions among distributed components. As pointed out in this slide, there are certain limitations with respect to the scalability of the simple agent-client, facilitator-server pictures shown previously. Here are two possible strategies for retaining OAA’s flexibility while sidestepping some of the scalability issues:
1. First, an OAA Facilitator is an agent like another, so other network topologies of agent configurations can be constructed. One example (but not the only possibility) is a hierarchical construction, where a top level Facilitator manages collections of both client agents and other Facilitators. Facilitator agents could be installed for individual users, for a group of users, or as appropriate for the task.
2. A second approach is a bit more difficult to explain, but seems very promising. In the current version of OAA, a Facilitator agent, upon receiving a complex request, will break the request into pieces, discover which agents can participate in the resolution process, and then constructs an execution plan describing who, how and in what order the agents will interact to accomplish the overall goal. Once the plan is constructed, the Facilitator begins executing the plan, sending requests to agents in parallel, collecting and routing answers to other agents, etc. By separating these two phases (planning & execution), the planner and registry component can easily be replicated across many machines, and the execution state of a complex request, instead of the Facilitator storing this for all agent requests (e.g., single point of failure), can be distributed among many agents.
In addition, it is clear that techniques such as load-balancing, resource management, and dynamic configuration of agent locations and numbers could be naturally incorporated into the Facilitator, using any of the OAA topologies discussed.