.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-controlloop-participant-intermediary:
+.. _clamp-acm-participant-intermediary:
Participant Intermediary
########################
The CLAMP Participant Intermediary is a common library in ONAP, which does common message and
state handling for participant implementations. It provides a Java API, which participant
implementations implement to receive and send messages to the CLAMP runtime and to handle
-Control Loop Element state.
+Automation Composition Element state.
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)
+- Broadcast message: a message for all participants (participantId=null)
+- Message to a participant: a message only for a participant (participantId properly filled)
- MessageSender: a class that takes care of sending messages from participant-intermediary
- GUI: graphical user interface, Postman or a Front-End Application
+- Message Broker: supported message Broker are DMaap and Strimzi-Kafka
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
+- PARTICIPANT_REGISTER_ACK: received as a response from clamp-acm runtime server as an acknowledgement to ParticipantRegister message sent from a participant
+- PARTICIPANT_DEREGISTER_ACK: received as a response from clamp-acm runtime server as an acknowledgement to ParticipantDeregister message sent from a participant
+- AUTOMATION_COMPOSITION_STATE_CHANGE: a message received from clamp-acm runtime server for a state change of clamp-acm
+- AUTOMATION_COMPOSITION_DEPLOY: a message received from clamp-acm runtime server for a clamp-acm deploy with clamp-acm instances
+- PARTICIPANT_PRIME: a message received from clamp-acm runtime server for a participant update with tosca definitions of clamp-acm
+- PARTICIPANT_STATUS_REQ: A status request received from clamp-acm 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
+- AUTOMATIONCOMPOSITION_STATECHANGE_ACK: is an acknowledgement sent by a participant as a response to AutomationCompositionStateChange
+- AUTOMATION_COMPOSITION_DEPLOY_ACK: is an acknowledgement sent by a participant as a response to AutomationCompositionDeploy
+- PARTICIPANT_PRIME_ACK: is an acknowledgement sent by a participant as a response to ParticipantPrime
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)
+- A participant starts and send a PARTICIPANT_REGISTER message with participantId and Supported Element Definition Types
+- in AC-runtime ParticipantRegisterListener collects the message from Message Broker
+- if participant is not present in DB, it saves participant reference with status ON_LINE to DB
- 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
+- A participant is going to close and undeploys all AC-elements and send a PARTICIPANT_DEREGISTER message
+- in AC-runtime, ParticipantDeregisterListener collects the message from Message Broker
+- if participant has AC-elements instance, it updates with UNDEPLOYED deployStatus
+- It triggers the execution to send a PARTICIPANT_DEREGISTER_ACK message to the participant deregistered
- 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
+Prime of an Automation Composition Definition Type
+--------------------------------------------------
+- AC-runtime assigns the AC Definition to the participants based of Supported Element Definition Type by participant
+- it triggers the execution to send a broadcast PARTICIPANT_PRIME message
+- the message is built by ParticipantPrimePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition)
+- Participant-intermediary will receive a PARTICIPANT_PRIME message and stores the Tosca Service Template data on ParticipantHandler
+
+DePrime of an Automation Composition Definition Type
+----------------------------------------------------
+- AC-runtime triggers the execution to send a broadcast PARTICIPANT_PRIME message
+- the message is built by ParticipantPrimePublisher with an empty list of ParticipantDefinition
+- Participant-intermediary will receive a PARTICIPANT_PRIME message and deletes the Tosca Service Template data on ParticipantHandler
+
+Design of "issues automation composition commands to automation compositions" - case UNDEPLOY to DEPLOY
+-------------------------------------------------------------------------------------------------------
+- AUTOMATION_COMPOSITION_DEPLOY message with instantiation details and DEPLOY order state is sent to participants
+- Participant-intermediary validates the current deployState change
+- Participant-intermediary will receive AUTOMATION_COMPOSITION_DEPLOY message and sends the details of AutomationCompositionElements 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
+Design of "issues automation composition commands to automation compositions" - case DEPLOY to UNDEPLOY
+-------------------------------------------------------------------------------------------------------
+- AUTOMATION_COMPOSITION_STATE_CHANGE message with instantiation details and UNDEPLOY order state is sent to participants
+- Participant-intermediary validates the current deployState change
+- Participant-intermediary will receive AUTOMATION_COMPOSITION_STATE_CHANGE message and sends AC-element details 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 "issues automation composition commands to automation compositions" - case LOCK to UNLOCK
+---------------------------------------------------------------------------------------------------
+- AUTOMATION_COMPOSITION_STATE_CHANGE message with instantiation details and UNLOCK order state is sent to participants
+- Participant-intermediary validates the current lockState change
+- Participant-intermediary will receive AUTOMATION_COMPOSITION_STATE_CHANGE message
+
+Design of "issues automation composition commands to automation compositions" - case UNLOCK to LOCK
+---------------------------------------------------------------------------------------------------
+- AUTOMATION_COMPOSITION_STATE_CHANGE message with instantiation details and LOCK order state is sent to participants
+- Participant-intermediary validates the current lockState change
+
+Design of a PARTICIPANT_STATUS_REQ message
+------------------------------------------
+- AC-runtime triggers the execution to send a broadcast PARTICIPANT_STATUS_REQ message or to send it to a specific participant
+- the message is built by ParticipantStatusReqPublisher
+- Participant-intermediary will receive a PARTICIPANT_STATUS_REQ message
Design of a PARTICIPANT_STATUS message
--------------------------------------
-- A participant sends a scheduled PARTICIPANT_STATUS message
+- A participant sends a scheduled PARTICIPANT_STATUS message or in response to a PARTICIPANT_STATUS_REQ 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
+Design of a AUTOMATION_COMPOSITION_DEPLOY_ACK message
+-----------------------------------------------------
+- A participant sends AUTOMATION_COMPOSITION_DEPLOY_ACK message in response to a AUTOMATION_COMPOSITION_DEPLOY message.
+- For each AC-elements moved to the ordered state as indicated by the AUTOMATION_COMPOSITION_DEPLOY
+- AutomationCompositionUpdateAckListener in AC-runtime collects the messages from Message Broker
+- It checks the deployStatus of all automation composition elements
+- It updates the AC-instance in DB accordingly
+
+Design of a AUTOMATIONCOMPOSITION_STATECHANGE_ACK message
+---------------------------------------------------------
+- A participant sends AUTOMATIONCOMPOSITION_STATECHANGE_ACK message in response to a AUTOMATIONCOMPOSITION_STATECHANGE message.
+- For each AC-elements moved to the ordered state as indicated by the AUTOMATIONCOMPOSITION_STATECHANGE
+- AutomationCompositionStateChangeAckListener in AC-runtime collects the messages from Message Broker
+- It checks the deployStatus/lockStatus of all automation composition elements
+- It updates the AC-instance in DB accordingly
Code Review / policy / parent.git / blobdiff