The CLAMP Runtime Server

To be update....    

Broadcast message: a message for all participants (participantId=null and participantType=null).
Message to a participant: a message only for a participant (participantId and participantType properly filled).
    
Design of a creation of a Control Loop Type

• Call POST /commission with a Control Loop Type Definition (Tosca Service Template) as body
• Save to DB the Tosca Service Template using PolicyModelsProvider
• if there are participants registered, it triggers to ParticipantUpdatePublisher to send a broadcast PARTICIPANT_UPDATE message
• message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition).

Design of a deletion of a Control Loop Type

• Call DELETE /commission with a Control Loop Type Definition (Tosca Service Template)
• if there are participants registered, it triggers to ParticipantUpdatePublisher to send a broadcast PARTICIPANT_UPDATE message
• message is built by ParticipantUpdatePublisher with a empty list of ParticipantDefinition
• delete the Control Loop Type from DB

Design of a creation of a Control Loop

• Call POST /instantiation with a Control Loop as body
• Validation of the Control Loop
• Save the Control Loop to DB

Design of an update of a Control Loop

• Call PUT /instantiation with a Control Loop as body
• Validation of the Control Loop
• Save the Control Loop to DB

Design of a deletion of a Control Loop

• Call DELETE /instantiation
• check that Control Loop is in UNINITIALISED status
• delete the Control Loop from DB

Design of a issues control loop commands to control loops - case UNINITIALISED to PASSIVE

• CALL /instantiation/command with PASSIVE as orderedState
• check if participants registered are matching with the list of control Loop Element
• update control loop and control loop elements to DB (orderedState = PASSIVE)
• validate the status order issued
• trigger to ControlLoopUpdatePublisher to send a broadcast CONTROL_LOOP_UPDATE message
• message is built by ControlLoopUpdatePublisher using Tosca Service Template data and ControlLoop data. (with startPhase = 0)
• update control loop and control loop elements to DB (state = UNINITIALISED2PASSIVE)        

Design of a issues control loop commands to control loops - case PASSIVE to UNINITIALISED

• CALL /instantiation/command with UNINITIALISED as orderedState
• check if participants registered are matching with the list of control Loop Element
• update control loop and control loop elements to DB (orderedState = UNINITIALISED)
• validate the status order issued
• trigger to ControlLoopStateChangePublisher to send a broadcast CONTROL_LOOP_STATE_CHANGE message
• message is built by ControlLoopStateChangePublisher with controlLoopId
• update control loop and control loop elements to DB (state = PASSIVE2UNINITIALISED)

Design of a issues control loop commands to control loops - case PASSIVE to RUNNING
        - CALL /instantiation/command with RUNNING as orderedState
        - check if participants registered are matching with the list of control Loop Element.
        - update control loop and control loop elements to DB (orderedState = RUNNING)
        - validate the status order issued
        - trigger to ControlLoopStateChangePublisher to send a broadcast CONTROL_LOOP_STATE_CHANGE message
        - message is built by ControlLoopStateChangePublisher with controlLoopId
        - update control loop and control loop elements to DB (state = PASSIVE2RUNNING)

Design of a issues control loop commands to control loops - case RUNNING to PASSIVE
        - CALL /instantiation/command with UNINITIALISED as orderedState
        - check if participants registered are matching with the list of control Loop Element.
        - update control loop and control loop elements to db (orderedState = RUNNING)
        - validate the status order issued
        - trigger to ControlLoopStateChangePublisher to send a broadcast CONTROL_LOOP_STATE_CHANGE message
        - message is built by ControlLoopStateChangePublisher with controlLoopId
        - update control loop and control loop elements to db (state = RUNNING2PASSIVE)

SupervisionAspect
        - ThreadPoolExecutor: in this context is configured to execute task in ordered manner, one by one.
        - Scheduling: is used to schedule retry task.
        - MessageIntercept: is used to intercept messages from participants

HandleCounter
        - remove(id) -> used to remove from monitoring
        - clear(id)  -> used to clear/start monitoring

Design of a PARTICIPANT_REGISTER message
       - the message is collected by ParticipantRegisterListener
        - the participant is save to db if not present with status UNKNOWN
        - if is present a Control Loop Type, it triggers to ParticipantUpdatePublisher to send a PARTICIPANT_UPDATE message to the participant registered (message of Priming).
        - message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition).
        - trigger to ParticipantRegisterAckPublisher to send a PARTICIPANT_REGISTER_ACK message to the participant registered
        - from MessageIntercept the event is intercepted and if PARTICIPANT_UPDATE message has been sent, it will be add a task to handle PARTICIPANT_REGISTER in SupervisionScanner
        - in SupervisionScanner start the monitoring for participantUpdate
    
Design of a PARTICIPANT_UPDATE_ACK message
        - the message is collected by ParticipantUpdateAckListener
        - from MessageIntercept the event is intercepted and it add a task to handle PARTICIPANT_UPDATE_ACK in SupervisionScanner
        - in SupervisionScanner remove the monitoring for participantUpdate
        - update the status of the participant to db
    
Design of a PARTICIPANT_STATUS message
        - the message is collected by ParticipantStatusListener
        - from MessageIntercept the event is intercepted and it add a task to handle PARTICIPANT_STATUS in SupervisionScanner
        - in SupervisionScanner clear and start the monitoring for participantStatus
        
Design of a CONTROLLOOP_UPDATE_ACK message
        - the message is collected by ControlLoopUpdateAckListener
        - from the control loop into the message check the status of all control loop element and check if the control loop is primed
        - update the CL into the db if it is changed
        - from MessageIntercept the event is intercepted and it add a task to handle a monitoring execution in SupervisionScanner
        
Design of a CONTROLLOOP_STATECHANGE_ACK message is similar to CONTROLLOOP_UPDATE_ACK
       
Solution Design of retry, timeout, and reporting for all Participant message dialogues

Design of startPhase into monitoring execution in SupervisionScanner
        - phaseMap is map that contains (CL -> last startPhase sent)
        - during the monitoring is calculate the the minimum startPhase where the status of a Element is not equal to the orderstatus (minSpNotCompleted).
        - if the last startPhase sent is different to minSpNotCompleted and CL order status is UNINITIALISED2PASSIVE then send the CONTROLLOOP_UPDATE message with minSpNotCompleted as startPhase

Design of a monitoring execution in SupervisionScanner
        - for each CL
            - check if the status of the CL is equal to the order status; if they are equal, clear the monitoring counter for this CL and continue the loop.
            - for each CL Element check if the status of an Element are equal to the orderstatus
            - if all CL Element status are equal to the orderstatus, update the CL status, clear the monitoring counter for this control loop and continue the loop.
            - the message CONTROLLOOP_UPDATE/CONTROL_LOOP_STATE_CHANGE to participant will be sent if: