The Service Structure
This is the description of the new structure for the service providing framework for TAgents.
Services can be all from components to SysAgents and Agents. They all provide a proxy for accessing their functionality.
The picture below shows a general overview of the structure:
In the first column in the middle you see the main Services class. Every object who has to be accessed in the System has
to register itself there. It is the main service maintainer. If an Agent wants to publish a service it has to register there.
Every Agent gets a attribut "services" when created and can access the service maintainer through this. The same for SysAgents,
too. Until now the Agents and SysAgents access to the platform through so called helpers. With useing the service providing
machanism for the platform (AgentSystem class) itself it will be possible to replace them. The big advantage of a standard
method to access the services is ease of use and more important to have a single point of access for security control.
Every access to a service will be checked back with the security manager and provides a "service-level" security control.
The next point is then in the methods of the proxies itself for more finegrained control.
The services are organized hierarchical:
There is a basic (root) service manager, initialized by the AgentSystem at
start. Then there are (or will be) sub-service-manager (sub-classes of
ServiceManager and SubManagerProxy). They register themselfes as
"<service_name>/manager" at their root service manager. An example is the
AdminManager and services:
There is a service called admin/output/console for printing methods
(print/-ln). The manager structure is now the following:
admin/manager: a ServiceManager with still no special functionality
admin/output: The service for all print methods (super service for the
console and gui output services)
admin/output/manager: The place were the console service registers its output
service. It is basically a ServiceManager class with no special functionality
admin/output/console: This is the real console output service.
When now a service registers itself, the manager checks if it is a root
service of its level (in other words if it has a "/" in its type). Then it
checks if there is a sub-manager to delegate the registering process to it
(e.g. it finds a admin/manager and delegates the registering to this one, with
type now "output/console"). and so on...
The admin/output/console service will be registered at the
admin/output/manager with type "console".
When now an agent writes output it writes it to the admin/output service.
This service checks the admin/output/manager for all registered output
services and delegates the printing to them (e.g. to admin/output/console).