Run-time support

Once the software system has been deployed and started, the main objective of Timed-CAA- DRIP is to give run-time support to allow the CAAs composing the software system behave as expected. This section describes the internal executions performed by the implementation framework to achieve this expected behaviour. It is worth noting that the way the executions are performed depend not only on whether the CAA has time constraints or not, but also if an exception takes place in one of its roles during the execution. Hence, the description of the Timed-CAA-DRIP internal executions are divided among those required to execute a (normal or non-timed) CAA, a timed CAA and those that take place when dealing with an exception.

4.4.2.1 CAA execution

The activation of a CAA is considered as the process that begins when at least one participant enters into the CAA to play one of its roles. This process (i.e. the activation of the CAA) is

148 4. The Timed-CaaFWrk conceptual framework

completed once all the required participants have entered into the CAA, and the latter is ready to play their respective roles.

There exist two ways of requesting the activation of a CAA: the composite and nested ways. When calling a CAA in a composite manner, a single participant is required to achieve both the activation and execution of this CAA, since the implementation framework will, according to the allocation policy specified, locate the necessary participants. This activation is achieved by calling the method executeAll of the particular CAA that wants to be executed.

Conversely, when calling a CAA in a nested manner, such an allocation does not take place, since the participant to be used is the same that requests the activation of the CAA. Notice that in the case of nesting, a participant requests the activation of the CAA that wants to be executed by calling the method execute(r,caa), where r is the role to be played by the calling participant into the CAA of name caa. To succeed in the activation of this CAA, there must be as many participants requesting the activation of the CAA caa as roles it has.

Hereafter, the explanation is only focused on the activation and execution of a composite CAA. The Sequence Diagram shown in Figure 4.42 is used as a vehicle to support (and ease) the explanation of the internal operation performed by the implementation framework.

A participant, which is considered the client of the CAA being called, executes the method executeAll to request the activation of the CAA. Once the participant has executed this method, the control of the execution is passed to the Timed-CAA-DRIP framework (server side), which takes charge of the complete execution of the requested CAA. Notice that the CAA to be executed (according to the Sequence Diagram named caa) is assumed as properly defined by the client. Details about how to define a CAA are given in the following section.

Once the CAA has taken control of the execution it starts the activation process by executing the internal method runCAA. The first step within the activation process is to gather the needed participants to play each of its roles. The method assign participants looks for the specified participants and then allocates them to each of the roles. Once the allocation has completed, a thread is created for each participant such that they can play their respective roles. This is achieved by the method executeAll of the class Role. This method, after having created the thread, passes control (by the method controller ) to the manager of the role, which is the entity that leads its execution. A manager, then starts the execution of the role by calling the method run. Once this method has completed, the execution of the CAA life cycle starts. Notice that there exists a manager (named mgri in the Sequence Diagram) for each role (named rolei) to be

played.

The CAA life cycle is coded in the Manager class as a sequence of operations that it executes after its activation. The first activity a manager executes is to synchronise itself with all other managers that are taking place within the CAA. This is done by calling the syncBegin method. This method gets blocked until all the managers have synchronised. Once the syncBegin method returns, the manager checks if the pre-condition of the role is valid by calling the method preCondition. If the pre-condition of the role is not satisfied, then an internal exception called PreConditionException is raised, leading the CAA to its recovery phase, which is described at the end of this section.

Once all the managers have checked that the roles’ pre-conditions are met, the activation process of the CAA is considered as complete. Its status is changed to “start” by calling the method of the same name. Starting the CAA leads each manager to execute the role that is under its control by calling the bodyExecute method of the Role object. This method calls the method body, which has been overridden by the programmer with the instructions the role is expected

4.4. The Timed-CAA-DRIP implementation framework 149

allocator : Allocator role_i : Role mg_i : Manager

Thread B_i caa : CAA Thread A Client Creates Thread B_i run 6: start 9: bodyExecute 10: syncBegin 7: preCondition() 8: syncEnd 14: finish 12: postCondition() 13: controller(caa) 5: body() 11: runCAA 2: assign_participants() 3: executeAll() 4: free_participants() 15: executeAll() 1:

Fig. 4.42: Internal executions for starting a (non-timed) CAA.

to perform.

After all the roles have finished executing, the CAA status is changed to “finish”. It only remains to check whether each role passes its post-condition or acceptance test. If the post-conditions are satisfied, then the manager, once again, synchronises with all the other managers to finish the CAA execution synchronously. Otherwise the internal exception PostConditionException is raised, making the CAA recovery phase start.

Managers, after having synchronised upon exit, return control to the CAA (caa in the Sequence Diagram). Notice that every time a manager returns control to the CAA, the thread that is used to carry out the role execution is stopped17_{. The last step is concerned with the release of}

the allocated participants. This is achieved by calling the method fre participants.

17

150 4. The Timed-CaaFWrk conceptual framework

4.4.2.2 Timed-CAA execution

The run-time support provided by the implementation framework for launching a timed-CAA differs not only (1) in the sequence of method calls taking place, but also (2) in the overhead introduced due to the monitoring of the time constraints that can be set over the CAA. Details about these differences are given in the following order: first, the sequence of method calls re- quired to make a timed-CAA runnable are detailed, and then information regarding the overhead introduced by the implementation framework is given.

The Sequence Diagram shown in Figure 4.43 describes the complete sequence of method calls taking place during the execution of a Timed-CAA. This Sequence Diagram shows that the mayor difference between launching a (non-timed) CAA and a timed-CAA is in the use of the Java native interface ScheduledExecutorService, which is aimed at scheduling (Java) instructions not only to run after a given delay, or to execute periodically, but also to check whether their execution is completed within the expected deadlines.

After executing the method schedule, the sequence of method calls remains the same as for a non- timed CAA. However, the behaviour between a non-timed and a timed-CAA is differentiated by the number of threads involved in their execution. The method schedule is in charge of creating new threads both to activate the requested timed-CAA, and to monitor the timing constraints this CAA has to meet. Beside the thread used to activate and then execute the CAA, there may exist threads to monitor (1) the maximum allowed delay in effectively starting of the CAA (i.e. t1 in the Figure ?? shown in Section 4.3.1.1), (2) the minimum and maximum finish time or

deadlines (i.e. t2 and t3), (3) the minimum and maximum elapse time (i.e. E1 and E2), and (4)

the deadline imposed by its periodicity (i.e. Te), in case the requested timed-CAA is periodic.

For each kind of timing constraint, a new thread is created. This represents an extra overhead, in terms of memory and processing power, with respect to a non-timed CAA. A performance analysis similar to the one provided in [CGP+09] is planned to be carried out to quantitatively assess the overhead introduced by monitoring the time-constraints. However, it is worth noting that such an overhead is limited, since in the worst case, there will exist four extra threads running in parallel with those threads required to execute each of the CAA’s roles.

Each of these threads is aimed at monitoring a particular time constraint. Each thread will raise an internal time-related exception as soon as the watched time constraint is missed. The raising of this time-related exception leads the timed-CAA to its recovery phase. Notice that the recovery phase of a CAA is the same regardless of whether it is timed or not.

4.4.2.3 Recovery phase

The recovery phase of a CAA starts when an exception is raised during the execution of (at least) one of its roles. This points out that the CAA has already started, since a role is able to execute once all of the CAA’s roles have met their respective pre-condition. It is worth recalling that an exception may be raised either by the role itself, or any of the underlying layers it relies on to perform its execution. The Sequence Diagram shown in Figure 4.44 depicts the raising of exception ex within the role rolei as a self-message taking place in such a role.

As was explained in Section 4.2.2, a role may include a local handler for dealing with some exceptions. Hence, depending on whether there exists a local handler (first alternative), the raised exception can be handled by the role itself in a single manner. Otherwise, the exception must be handled in a cooperative manner by all the participants engaged in the execution of the CAA (second alternative). In this situation (i.e. second alternative), the role where the

4.4. The Timed-CAA-DRIP implementation framework 151

scheduler : ScheduledExecutorService allocator : Allocator mgr_i : Manager

caa : TimedCAA role_i : Role

Thread B Thread A Thread C Client Creates Thread C Creates Thread B run 7: syncBegin 8: preCondition() 9: start 10: bodyExecute() 11: syncEnd 15: finish 13: postCondition() 14: runCAA 2: schedule() 3: assign_Participants() 4: executeAll() 5: free_participants() 16: controller() 6: body() 12: executeAll() 1:

Fig. 4.43: Internal executions for starting a timed-CAA.

exception was raised, notifies its manager (named mgri in the Sequence Diagram). This is

achieved by propagating the exception using the Java native instruction throw.

Once the manager is notified about an exception, it starts the resolution mechanism by executing the method exceptionResolution. This method includes a call to the method notifyException over the leader18manager. The aim of the notifyException method is: (1) to interrupt the execution of all the other roles enclosed within the same CAA, and (2) to determine the resolving exception to be handled. The second goal is achieved by calling the method getResultException. Once all the managers have been informed as to which exception is to be handled, the recovery mechanism is initiated.

18

Among all the existing managers used to lead the execution of each the CAA’s role, the first one created is designated as the leader. The “leader” manager is the centralised point for performing commons tasks within the CAA, such as interrupting the roles, or determining the common exception to be handled in the case where concurrent exceptions are raised

152 4. The Timed-CaaFWrk conceptual framework

cmp_i : Compensator

mgr_i : Manager hnd_k : Handler mgr_j : Manager role_i : Role

Thread A Thread B

[exists local handler]

notifies the occurence of the exception ex to all the others roles enclosed within the same CAA

[else]

[else BER] [exists FER for resolvedEx]

alt alt

"Leader" manager among those being used to play the roles exception ex is raised notifyException(ex) 6: exceptionResolution 5: handlerExecution 9: syncBegin 10: bodyExecute() 11: postCondition() 12: syncEnd 13: compensatorExecution() 14: abort 15: bodyExecute() 1: resolvedEx=getResultException 7: return resolvedEx 8: catch Exception ex 3: throw ex 4: ex 2:

Fig. 4.44: Internal execution for recovering from an exception.

The recovery mechanism executed by Timed-CAA-DRIP is either FER or BER, depending on whether there exists a cooperative handler for the exception. It is worth recalling that a cooperative handler is defined as a set of handlers. Within Timed-CAA-DRIP, handlers used to define a cooperative handler are instances of the class Handler.

In the case that a cooperative handler does exist (and then the CAA has as many instances of class Handler as roles) for dealing with the exception ex , the handlerExecution method is called to act over each handler instance. For the sake of simplicity, only one handler (named hndk) is

shown in the Sequence Diagram. The aim of the handlerExecution is to collaboratively execute with the other handlers, those instructions that allow the CAA to recover from the exception. This is achieved by, first synchronising the handlerExecution’s initiation with the other peer handlers (by calling the method syncBegin), and then calling the method bodyExecute. This method is overridden by the programmer to include Java native instructions that allow certain instructions to be handled.

4.4. The Timed-CAA-DRIP implementation framework 153

It must be noted, that the same manager used to lead the execution of the role, is also used to lead the execution of the handler. Hence, once the handler completes the execution of bodyExecute, the manager calls the post-condition method of the same handler to check whether it passes or fails its acceptance test. In case all the handlers have passed their respective tests, the execution follows the same sequence of method calls as in the case when no exceptions have been raised. Otherwise, the BER is started in order to abort the CAA.

The BER occurs when a cooperative handler for the raised exception does not exist or when an exception takes place during the FER. The BER performs the necessary steps to undo all the effects of having executed the CAA thus far. This is achieved by (1) compensating the execution of each role, and (2) calling the process abort. The compensation of the tasks done by role rolei are performed by calling the method compensatorExecution. This method encodes the

instructions such that each manually-recoverable external object can be restored to a consistent state, presumably a state similar to that that object had before initiating the CAA.

On the other hand, the method abort (belonging to the manager) interfaces with each auto- recoverable external object by calling its implementation of the method abort. The abort method implemented by each external object is part of the Transaction interface to be implemented. (Details of this interface and its aim are given in the next section).