Integrated Agent Controller Design
The current communication between the Agent Controller (AC) and Eclipse workbench is through TCP/IP sockets for both local and remote case. In fact, socket communication is not required in the local case if we could bundle the Agent Controller into the Eclipse workbench. As long as the interface between the Agent Controller and the agents are the same, any existing agent will continue to work without having the need to migrate to a new API. Agent Controller in this form is called an Integrated Agent Controller (IAC).
· Should work with existing agents which communicate through native named pipes and shared memory. Agents should not be able to distinguish between a normal AC from an IAC.
· Should work with existing Eclipse client code without the need of changing any existing code. There might be changes in the “org.eclipse.hyades.execution” plugin. Any client code which uses this plugin should not be affected by the internal changes applied. Client code should not be able to distinguish between a normal AC from an IAC as well.
· The IAC should be run in-process with the Eclipse workbench and communication with client code will be short-circuited using direct method invocations. The IAC will be managed through the Profiling Perspective.
The IAC will consist of the following:
· Native Transport modules (named pipe, shared memory)
· Direct Connection module – used for communication between IAC and clients
· Traffic Controller – used for receiving bytes from all transports when dispatch to the appropriate processing component based on the connection information
· Processing modules – used to process incoming bytes or objects generated from the transport and direct connection modules. This module pluggable to the system and thus can support both the old and new API
The IAC is implemented in Java. Shared memory and named pipe transport currently used by the agents are implemented in C/C++. Java does not support these two types of connections. Therefore, in order to provide backward compatibility to existing agents, the IAC has to implement these two types of native transports through the use of the Java Native Interface (JNI).
Each of the Native Transport modules has to provide an interface for reading and writing bytes to the underlying transport mechanism. These transport modules will be created and added to the Traffic Controller which job is to handle all bytes streams in and out of the IAC. Each Native Transport which acts as a byte reader will be hosted inside a thread created by the Traffic Controller for continuously reading the bytes. The Traffic Controller will also forward any outgoing bytes from the IAC to the appropriate Native Transport module which acts as a byte writer.
There will be no separate communication channel between the Eclipse workbench and the IAC since they are hosted in the same process. The Direct Connection module is the facility used for sending and receiving messages between different components. Instead of reading and writing bytes as in the Native Transport module, the Direct Connection module will read and write Java objects (the java.lang.Object class). It is up to the receiver of the object to determine how to handle the object. Using the Object class will allow the maximum flexibility and extensibility.
The Traffic Controller is the centralized component for managing all incoming and outgoing data, whether it is a byte stream or a Java object. It keeps track of all connection by identifying the associated connection info. All transmitted will have a connection info attached to allow the receiving end to determine the origin of the data. This information is useful for operations such as sending a reply message back to the sender.
The Traffic Controller also holds a list of Processing modules which are responsible for processing all incoming data. The outputs from the Processing modules will be sent by the Traffic Controller to their appropriate destinations.
The Processing Modules are responsible for handling the incoming bytes or Java object and determine how to interpret them. Basically they act as the Agent Controller – handling agent registration, client requests, etc. Processing modules can be added or removed from the IAC to provide forward and backward compatibility. New Processing Modules can be added to the IAC as long as they implement the ProcessingModule interface.
The IAC will come with a Processing Module at the TPTP 3.3 API level to start with.
The TPTP 3.3 Processing Module will consist of the following:
· Byte Processor
· Data Processor
· Message Processor
· Configuration Processor
The Byte Processor receives bytes from the Processing Module. Its task is to look at the bytes and try to determine the type - whether it is a message or a data stream. If the data is a message, it will create a Message object from the bytes and send it to the Message Processor. Otherwise, if it is a binary data stream, it will forward the bytes to the Data Processor. The Byte Processor is also responsible for sending messages by reading a Message object and converts it into bytes. The bytes are then being sent to the Traffic Controller in order to reach its destination.
The Data Processor is used for handling incoming binary data (such as profiling data) and send it to the appropriate client side data processor through the Direct Connection mechanism.
The Message Processor is responsible for handing incoming Acknowledgement or Control messages. It has a handle to the local Node (which is retrieved from the NodeFactory) and will populate the Node with processes and agents when they registers through the use of the Control messages. This same Node is also being accessible by the client on the Eclipse workbench.
The IAC will have a configuration file similar to the AC. The Configuration Processor is used for parsing this file and configure the IAC accordingly. The mostly used aspect of the configuration file is to set agent attributes as well as allowed application to be launched through the IAC.