diff options
Diffstat (limited to 'docs/clamp/controlloop/design-impl/participants/participant-intermediary.rst')
| -rw-r--r-- | docs/clamp/controlloop/design-impl/participants/participant-intermediary.rst | 118 |
1 files changed, 117 insertions, 1 deletions
diff --git a/docs/clamp/controlloop/design-impl/participants/participant-intermediary.rst b/docs/clamp/controlloop/design-impl/participants/participant-intermediary.rst index 7f6cf499..a483dfc3 100644 --- a/docs/clamp/controlloop/design-impl/participants/participant-intermediary.rst +++ b/docs/clamp/controlloop/design-impl/participants/participant-intermediary.rst @@ -10,4 +10,120 @@ state handling for participant implementations. It provides a Java API, which pa implementations implement to receive and send messages to the CLAMP runtime and to handle Control Loop Element state. -.. warning:: To be completed +Terminology +----------- +- 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) +- MessageSender: a class that takes care of sending messages from participant-intermediary +- GUI: graphical user interface, Postman or a Front-End Application + +Inbound messages to participants +-------------------------------- +- PARTICIPANT_REGISTER_ACK: received as a response from controlloop runtime server as an acknowledgement to ParticipantRegister message sent from a participant +- PARTICIPANT_DEREGISTER_ACK: received as a response from controlloop runtime server as an acknowledgement to ParticipantDeregister message sent from a participant +- CONTROL_LOOP_STATE_CHANGE: a message received from controlloop runtime server for a state change of controlloop +- CONTROL_LOOP_UPDATE: a message received from controlloop runtime server for a controlloop update with controlloop instances +- PARTICIPANT_UPDATE: a message received from controlloop runtime server for a participant update with tosca definitions of controlloop +- PARTICIPANT_STATUS_REQ: A status request received from controlloop runtime server to send an immediate ParticipantStatus from all participants + +Outbound messages +----------------- +- PARTICIPANT_REGISTER: is sent by a participant during startup +- PARTICIPANT_DEREGISTER: is sent by a participant during shutdown +- PARTICIPANT_STATUS: is sent by a participant as heartbeat with the status and health of a participant +- CONTROLLOOP_STATECHANGE_ACK: is an acknowledgement sent by a participant as a response to ControlLoopStateChange +- CONTROLLOOP_UPDATE_ACK: is an acknowledgement sent by a participant as a response to ControlLoopUpdate +- PARTICIPANT_UPDATE_ACK: is an acknowledgement sent by a participant as a response to ParticipantUpdate + +Design of a PARTICIPANT_REGISTER message +---------------------------------------- +- A participant starts and send a PARTICIPANT_REGISTER message +- ParticipantRegisterListener collects the message from DMaap +- if participant is not present in DB, it saves participant reference with status UNKNOWN to DB +- if participant is present in DB, it triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of Priming) +- the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition) +- It triggers the execution to send a PARTICIPANT_REGISTER_ACK message to the participant registered +- MessageIntercept intercepts that event, if PARTICIPANT_UPDATE message has been sent, it will be add a task to handle PARTICIPANT_REGISTER in SupervisionScanner +- SupervisionScanner starts the monitoring for participantUpdate + +Design of a PARTICIPANT_DEREGISTER message +------------------------------------------ +- A participant starts and send a PARTICIPANT_DEREGISTER message +- ParticipantDeregisterListener collects the message from DMaap +- if participant is not present in DB, do nothing +- if participant is present in DB, it triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of DePriming) +- the message is built by ParticipantUpdatePublisher using Tosca Service Template data as null +- ParticipantHandler removes the tosca definitions stored +- It triggers the execution to send a PARTICIPANT_DEREGISTER_ACK message to the participant registered +- Participant is not monitored. + +Design of a creation of a Control Loop Type +------------------------------------------- +- If there are participants registered with CL-runtime, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message +- the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition) +- Participant-intermediary will receive a PARTICIPANT_UDPATE message and stores the Tosca Service Template data on ParticipantHandler + +Design of a deletion of a Control Loop Type +------------------------------------------- +- if there are participants registered, CL-runtime triggers the execution to send a broadcast PARTICIPANT_UPDATE message +- the message is built by ParticipantUpdatePublisher with an empty list of ParticipantDefinition +- It deletes the Control Loop Type from DB +- Participant-intermediary will receive a PARTICIPANT_UDPATE message and deletes the Tosca Service Template data on ParticipantHandler + +Design of a creation of a Control Loop +-------------------------------------- +- CONTROL_LOOP_UPDATE message with instantiation details and UNINITIALISED state is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_UPDATE message and sends the details of ControlLoopElements to participants +- Each participant performs its designated job of deployment by interacting with respective frameworks + +Design of a deletion of a Control Loop +-------------------------------------- +- CONTROL_LOOP_STATE_CHANGE message with UNINITIALISED state is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of ControlLoopElements to participants +- Each participant performs its designated job of undeployment by interacting with respective frameworks + +Design of "issues control loop commands to control loops" - case UNINITIALISED to PASSIVE +----------------------------------------------------------------------------------------- +- CONTROL_LOOP_STATE_CHANGE message with state changed from UNINITIALISED to PASSIVE is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Each participant performs its designated job of state change by interacting with respective frameworks + +Design of "issues control loop commands to control loops" - case PASSIVE to UNINITIALISED +----------------------------------------------------------------------------------------- +- CONTROL_LOOP_STATE_CHANGE message with state changed from PASSIVE to UNINITIALISED is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Each participant performs its designated job of state change by interacting with respective frameworks + +Design of "issues control loop commands to control loops" - case PASSIVE to RUNNING +----------------------------------------------------------------------------------- +- CONTROL_LOOP_STATE_CHANGE message with state changed from PASSIVE to RUNNING is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Each participant performs its designated job of state change by interacting with respective frameworks + +Design of "issues control loop commands to control loops" - case RUNNING to PASSIVE +----------------------------------------------------------------------------------- +- CONTROL_LOOP_STATE_CHANGE message with state changed from RUNNING to PASSIVE is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Each participant performs its designated job of state change by interacting with respective frameworks + +Design of a PARTICIPANT_STATUS message +-------------------------------------- +- A participant sends a scheduled PARTICIPANT_STATUS message +- This message will hold the state and healthStatus of all the participants running actively +- PARTICIPANT_STATUS message holds a special attribute to return Tosca definitions, this attribute is populated only in response to PARTICIPANT_STATUS_REQ + +Design of a CONTROLLOOP_UPDATE_ACK message +------------------------------------------ +- A participant sends CONTROLLOOP_UPDATE_ACK message in response to a CONTROLLOOP_UPDATE message. +- For each CL-elements moved to the ordered state as indicated by the CONTROLLOOP_UPDATE +- ControlLoopUpdateAckListener in CL-runtime collects the messages from DMaap +- It checks the status of all control loop elements and checks if the control loop is primed +- It updates the controlloop in DB accordingly + +Design of a CONTROLLOOP_STATECHANGE_ACK is similar to the design for CONTROLLOOP_UPDATE_ACK |