Update: This entry is a sketch for what I feel an agent platform should be. I recently (2005-07-05) started a small side project called SPRAC++ to work toward these goals. Contributions & suggestions are welcome.I wrote this some two months ago, and never pushed it out until now. It is still only a sketch. I have often wished there was an open source, C++, Software Agent platform. I'm beginning to develop the system I will (hopefully) base my thesis on. It is moving along slowly, but I have reached the point where I am starting to implement network communication components. This isn't an extremely difficult task, but remains tedious while the system design is still evolving - as it is in my case. While I'm hacking out the tedious network programming code, I keep reminding myself the system would be much easier to prototype in the software agent paradigm. An agent platform would abstract away the networking code, leaving me to focus on the more important aspects of the how the system should function.
Dr. Paprzycki and I have casually discussed the nonexistence of a C++ agent platform over email. His response was along the following lines:
Java is the language of choice as this is the one that is conceptually best suited for the agents. I mean, agents are conceptually an extension of object oriented programming and the agency is a Virtual Machine that is between agents and the computer. And this is matching best with Java.
I can accept the fact that Java was initially the language of choice for developing agent platforms. There are portability advantages to using Java, but there are times when performance is more of a priority than instantaneous portability.
I disagree that an Agent Platform
must be a Virtual Machine; there are obviously security advantages to hosting agent platforms on a VM, however conceptually any run-time environment should suffice.
Naturally, I also feel that because the agent paradigm is an extension of object oriented programming that
any object oriented programming language should be able to support an agent platform. Further, I would expect that agents written on a specific agent platform should be able to communicate seamlessly with any other agent, whether or not they are implemented in the same environment. This is not the case today, and this is a major shortcoming of the agent paradigm. Agent communication protocols should strive to reach the level of interoperability achieved by internet communications protocols, where varying implementations work together without major issues.
What elements are needed to implement an agent platform in C++? A mere mental exercise
Every system implementation utilizing an agent platform is conceptually different. This tells us that we should strive for flexibility above all else, however, we still want there to be a familiar and convenient encapsulation/abstraction of the underlying network programming. I.e., we want a template, or framework, that provides some basic atomic services, where these services can be easily modified or built on to. Toward this end, I will briefly list attributes that I would like to see incorporated into an agent platform.
Aspects of an Agent Platform Object Oriented Mobile Agent Support Message Passing as Basis for Communication Modules Agent Communication Language Support Ontology Support Action and State Driven. Easily Extendable Light-weight Agents Light-weight & Efficient Agent Platform User Level Program Support & Daemon Support Support for High Level Artificial Intelligence Constructs (such as Neural Networks) Adaptability Genetic Programming Support Avoiding (Programming) Language Specific Approaches
Most of these attributes boil down into one guiding principle: modularity. We want to support a host of different capabilities while not explicitly requiring their use in the most basic agent implementations.
Object Oriented
This goes with the territory. The base agent should be a class that we can inherit from and extend.
Action and State Driven
In my mind, Agents should primarily function as Finite State Transducers, either Moore Machines, or O'Mealy Machines, or something similar. They accept input messages, and respond according to the state that they are in, sometimes producing output messages in response. Thinking in terms of states and transitions is very natural for most programmers, I think having this as a base paradigm underlying the agent oriented paradigm would be beneficial, aiding rapid program prototyping.
Ontology Support
(common definition of actions and messages)
Genetic Programming Support
Supply modules which would allow for easy implementation of genetic algorithms with Agents as the entities evolving. I see this as a move toward merging the Complex Adaptive Systems paradigm with the Software Agent paradigm.
Avoiding (Programming) Language Specific Approaches or Why JADE doesn't fit the bill.
Given the goal of cross-platform interoperability, one important task of the system is to avoid any language specific approaches during the implementation. JADE is a good illustration as to why this is a problem. JADE can only interact with over agents written in Java. Why? The main reason JADE based agents can't interact with non-Java agents is JADE's dependancy on Java-RMI. While Java-RMI is a quick and convenient way to implement a distributed object model, it necessitates the use of Java exclusively as it can't be called from other languages easily. This diverts us from our goal of
total interoperation : interoperation between agent platforms, interoperation between varying programming languages, and interoperation between varying operating systems. Now your probably thinking that CORBA is the solution, and perhaps it is a step in a similar direction, but I don't believe it is simple enough to be put into wide spread use. I feel a better approach would be to design generic protocols for message passing, and then to implement modules (native APIs) for using the protocols in various languages.
