aboutsummaryrefslogtreecommitdiffstats
path: root/docs/clamp/controlloop/design-impl/participants/participant-intermediary.rst
blob: a483dfc3eaf9bcde61dd3d1e4eb75d3657aad88b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
.. This work is licensed under a Creative Commons Attribution 4.0 International License.

.. _clamp-controlloop-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.

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