TAgents Future Plans

Warning: This document is highly technical! It is intented for development use only.

Core Platform

GroupService

API:

: createGroup; deleteGroup; listGroups; getGroup(Agent)

Class Group:

: join(Agent); leave(Agent); listAgents

Perhaps this will done by Ben (write me how you think about it, and I can give you more info).
Basic part of a MAS. Especially needed for mulicast messages.

Security

Internal Security (SecurityManager...)
Andres wrote me to tell me that one of his students is probably making the security part.
Would be a great thing!

Communication

First, I would like to get rid of RMI. In my opinion its obsolete (plain socket is more powerful and basic).
The benefits of RMI like the registry (replaced by MAFFinder) and easy for remote API calls (replaced by messaging) are all not working in the TAgents system. So I propose to remove it.
Second I want to discuss an old question: Is it good to provide API calls over the net for some special services (MAFFinder)?
We could make this easier by switching all to messages and therefor make the messages more powerfull (see above).
A first step would be the encapsulating of the network/protocol-specific parts in the according packages (e.g. pls).
These services would then provide a simple interface with just the sendMessage/receiveMessage calls (details above).
Registering APIs like the MAFFinderSserviceProxy could be done in the general CommunicationService. I call this concept "SuperService" like a SuperClass is the general parent of a class, so it is the SuperService to its "SubServices".
API for CommSubService::

: sendMessage; sendMessage (with timeout); and probably security related methods

When it receives a message it passes it through to the super-service...
All other components access only the "super-service" as CommService.
This CommService maintains all its SubServices and can use therefor the new created module for ResourceHandling.
Benefits are the easier integration of new protocols and more robust ones.
Before there was the problem where to decide which protocol to use when contacting another MAS. The code is still in the BasicAgent. Now we could put this code where it belongs, in the CommService.
Disadvantages are the bigger overhead and therefore the slower communication. Also Agents are not able to choose their desired communication protocol (Well, that could be done, too). But I think they should not bother with these things.
API for CommService (the super-service)::

: move; sendMessage; sendAsyncMessage; sendFutureMessage; sendMulticastMessage

the same as it is now (AgentCommIFace.java).

Messaging

We now send/execute message in a "may-be" (no second try if something happens) fashion.
For some situations it could be good to have different messaging schemas available:
at-least-once: The operation will be executed at least one time (automatic retry when somethink happens)
at-most-once: The reaction on error depends if the operation was already executed or not. The op will not be executed more then once.
exactly-once: Call exactly once when failure or message lost.
I am sorry for the bad explanations (I have them here in german and not very clear described :-((() but the idea should be clear. Any ideas ????
Things to be implementedfor communication in general:
* Transfer of needed classes (when an Agent travels with some unknown classes). For a good explanation please have a look at the OMG MASIF document (I can send it to you if you want. When I have time, I'll place a link on the homepage).
* Message Multicast (can only be done once Groups are available).

Testing

Since everyone who writes a part of the system will (or should) test it, how about writing an "TestAgent" which does automated testing? We could then build a test suite for atomatically testing all parts of the system. Especially important for testing the system under different jdks and platforms. I now this is gonna be a little more work, but I think it is worth it.
I am also playing with argoUML, a java based opensource UML modelling tool. Very promising but still not so easy use as I would like it. But you can try it out yourself (argouml.tripod.org).

MAFFinder (the region registry)

It needs improvements of several kinds. Some older idea is to make it a hierarchical registry (sub-maffinders register themselfs at the main maffinder...). Aanother is the currently lack of some information (like te services on an specific AS). The first implementation was compoatible (in forms of methods/parameters) to the MASIF standard of the omg (www.omg.org). It was intendet to make it fully compatible by adding CORBA support someday. Well Andres and I are thinking more and more about skipping these issues and making it better suited for the project. It seems not for much use to implement corba here... A taks could be to look at other standards (e.g. fipa, or general region registries) and perhaps switch to another standard (or defining our own ;-).

Java VM

I would love to see someoe testing the platform on other java vms, like the palm pilot's. Some evaluation/testing of the compotibility to the PeronalJava specification would be of great help, too.

Agent Loader

The agent loader need some more functionality. soe is to be able to load classes by getting the bytes from another AS (AgentSystem) or through http/ftp. The next thing is to bind the AgentLoader better to the Agent, like if the Agent loads some class it will also be automatically be fetched from the Agents location (if not already in the AS). This would require a central class cache in an AS and surely some really deep digging in Java ;-).

Examples

I say this very often, we need more examples. Some kind of Example-Agent-Set that do funny tasks together... Implement your own ideas here!

GUI

Setup

We would really need a user friendly GUI for configurin the System. For example when started the first time (without a configuration file) it should show an easy dialog to set the basic settings (maffinder location/system name ...). This should be able to be done later when running the system, too.
Another abroach could be to let every component (service) define their own configuration panel. So would the maffinder have a panel with fields to specify the adress of the main maffinder (if its a wrapper). The main setup gui just would need to compile all these panel into a complete setup gui (wit some basic setups, too). I think this is the most flexible solution.
Another (even more advanced) way could be through xml data exported by the service which describe the kind of settings and the setup system would create a gui to set these settings. This is fairly complicated and could be done more in future.

GUI for Agents

How can we control the window resources of Agents? A possible solution could be to let the Agent only export a panel and there would be then a general gui which creates a complete gui of these panels (like in the setup).

Please write your comments to the tagents-devel mailinglist. I will maintain this document and add any good ideas.