Resource Access

The new design of the TAgents platform tries to fulfill all the requirements of a highly extendable system. In the concept of Mobile Agents are stationary Agents used for providing special functionality to the other Agents. By extending this concept one can use so called System Agents to extend the System with all kind of resources as there are at this moment communication, a region registry and administration tools. These resources have to be public available (with security checks) to the System and to the Agents residing in it. The administration and distributing of the resources is done by the platform where all resources have to be registered.

The first design for this work used interfaces with the definition of access to the provided resources to be published in the System. These interfaces where implemented by the System Agents and then registered in the platform. The platform hold a string describing the interface as the key to the resource. This string was just the name (with package prefix) of the interface registered in the platform. Unfortunately it was now possible for an Agent to do a recast of the interface reference to the real System Agent. The platform was managing the resources in a hashtable with the name of the interface as key and a reference to the interface implementation of the System Agent. To give an example the (value:key) entry in the hashtable was something like

interfacename : reference_to_interfaceimplementation

``tagents.mafffinder.MAFFinderIFace'' : (MAFFinderIFace) maffinderservice 
With the interface implemented by the System Agent. An Agent could now do a recast to the System Agent:

• [SysAgent]sysagent = (SysAgent) reference_to_interfaceimplementation;

Now the Agent had access to all the standard methods of a System Agent like e.g. suspendAgent or terminateAgent to mention the worst. So it could do something like:

sysagent.terminateAgent();

Which would terminate the MAFFinder of this System. Since the recast is not restricted to the basic System Agent class but to all other interfaces and methods implemented by this special System Agent it would have been a too big overhead to check the security at every call to a method of a System Agent. So the design of the resource access had to be changed to provide the Agent only with an object containing no more than the methods defined in the interface.

This object which implements only the methods of the interface registered in the platform works as a wrapper or proxy between the user (Agent) and the provider (System Agent). It will be referred as proxy. The System Agent still implements all the methods needed for accessing the provided resources but creates then a proxy to register the proxy instead of itself to the platform. The proxy implements the same interface as the System Agent and contains internally a reference to the service providing System Agent (also called service). All calls to methods of the proxy are wrapped to the calls of the System Agent. Some methods now need to know which Agent has called them, making it necessary to personalize the proxy given to the Agent. First the platform had just one reference to the proxy and provided this reference to all Agents which where allowed to use one or more methods of this interface. The Agent had now access to all methods of the interface without giving the service the possibility to check if the Agent is allowed to call this method. For example it was possible for an Agent to call the unregisterAgentSystem method of the MAFFinder which is used to remove the entry for the given Agent System out off the MAFFinder.

So it was clear that the proxy must know which Agent is using it. This implies that every Agent using a proxy must have its own personalized clone of the proxy. Every proxy now has to extend the ProxyIFace which provides a method to clone the proxy with providing the ID of the Agent. This clone is then provided by the platform to the Agent requesting the resource. To do not let the Agent create its own clone of the proxy with another ID the proxy can only be cloned once from the proxy provided by the System Agent. See image on page for a process diagram.

Figure: Proxy Registration and Use

3#3

For an overview of the relations between the proxies, the System Agent, the Platform and the Agent see Figure on page .

Figure: Proxy Design

4#4

As one can see go all the calls to the System Agent through the proxy and not through the platform. The platform does not know which kind of resources are accessed by the Agent which makes the platform fully independent of the resource and service providing System Agents. The platform does not have to be changed when adding a new service (System Agent) like a new communication protocol or other resource access providers.