OAA's agent library, which provides the necessary infrastructure for constructing an agent-based system, is available in several programming languages, including PROLOG, C, C++, JAVA, LISP, VISUAL BASIC, and DELPHI. As mentioned earlier, two goals of the library's design have been to minimize the effort required to construct a new system, and to maximize the ease with which legacy systems can be agentified.
The library's several families of procedures, provide all the functionalities mentioned in this paper, as well as many that are omitted, for lack of space. For example, declarations of an agent's solvables, and their registration with a facilitator, are managed using procedures such as oaa_Declare, oaa_Undeclare, and oaa_Redeclare. Updates to data solvables can be accomplished with a family of procedures including oaa_AddData, oaa_RemoveData, and oaa_ReplaceData. Similarly, triggers are maintained using procedures such as oaa_AddTrigger, oaa_RemoveTrigger, and oaa_ReplaceTrigger.
The essential elements of protocol (that is, the details of the messages that encapsulate a service request and its response) are provided by the library, and made transparent in so far as possible, so that application code can be simpler. This enables the developer to focus on the desired functionality, rather than on the details of message construction and communication. For example, to request a service of another agent, an agent calls the library procedure oaa_Solve. This call results in a message to a facilitator, which will exchange messages with one or more service providers, and then send a message containing the desired results to the requesting agent. These results are returned via one of the arguments of oaa_Solve. None of the messages involved in this scenario is explicitly constructed by the agent developer. (Note that this is a description of the synchronous use of oaa_Solve.)
The agent library provides both intraagent and interagent infrastructure; that is, mechanisms supporting the internal structure of individual agents, on the one hand, and mechanisms of cooperative interoperation between agents, on the other. It is worth noting that most of the infrastructure cuts across this boundary; that is, many of the same mechanisms support both agent internals and agent interactions in an integrated fashion. For example, services provided by an agent can be accessed by that agent through the same procedure (oaa_Solve) that it would employ to request a service of another agent (the only difference being in the address parameter accompanying the request). This, in turn, helps the developer to reuse code and avoid redundant entry points into the same functionality.
Both of the characteristics described above (transparent construction of messages and integration of intraagent with interagent mechanisms) apply to most other library functionality as well, including data management and temporal control mechanisms.