Architecture

Diagram 1 summarises the design of actim. The server contains multiple threads which all cooperate in a master-workers queue manner. Some threads are generated dynamically where there is an actim event. The actim server initially creates two threads; event task handler and result handler.

To summarise, the event task handler becomes active when there is a request from the client. If the request is a server command, the event task handler will create a thread to execute the command and close the thread. If it is an event, then it will send the event in email and create a thread to poll for actim result email. Any result that is generated from the local server or has arrived from remote server is first forwarded to the raw result queue. The result handler listens on the raw result queue and either puts the result back to the client or into the hold result queue. This hold result queue acts as an asynchronous feature for the client so that the user may decide to disconnect after launching the request. Then the result is fetched later on.

The picture shows the following steps starting from how a request is being formed to results returned from a client:

1. (Local) First the client creates a request event object from the arguments and configuration setup.
2. (Local) Connection is established and the request object is sent to the server.
3. (Local) The server recieves an incoming object and forwards this to the incoming queue.
4. (Local) The event task handler first checks whether the request is event or command type.
   1. (Local) If this is command type (Point A in the diagram), the event handler creates a new thread, Command executor, to execute the command and returns the result object into the raw result queue.
   2. (Local) Otherwise, it checks whether the event is generated locally. If so, then it finds out if there is any result inside the event object. If there is no result, this means the event is just submitted from the client. If then, serialises, encrypts and sends the event to the destinaton (Point B in the diagram). Meanwhile it starts a new thread to poll for any return email.
   3. (Local) If the event has result, this means the event has been executed from the remote site and returns the result back. Forward it to the raw result queue. (Point C in the diagram)

5. (Remote) On the destiny side, actim is also running. The poll media thread picks the email up because of the same subject. Then it unpacks the email content, decrypts and unserialises into an object and forwards to the incoming queue.
6. (Remote) The event task handler thread fetches this object from the incoming queue. This object can originate from two different status. It can be a request generated remotely or it is generated locally and returns from a remote site with a result. In the former case, go to the next step. Otherwise go to the last step.
7. (Remote) A new thread is created, event executor, which invokes the method request by the event (Point D in the diagram) and sends the result back to the sender. Back to step 4.
8. (Local) The result object is then forwarded to the client and the client reports the result.

Figure 1: Design of Actim