summaryrefslogtreecommitdiffstats
path: root/docs/clamp/acm/design-impl/participants/participant-intermediary.rst
blob: 95c1a7acbd03cb462f944698a7b510d8b93c6c34 (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-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
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)
- 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 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_UPDATE: a message received from clamp-acm runtime server for a clamp-acm update with clamp-acm instances
- PARTICIPANT_UPDATE: 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
- AUTOMATIONCOMPOSITION_STATECHANGE_ACK: is an acknowledgement sent by a participant as a response to AutomationCompositionStateChange
- AUTOMATIONCOMPOSITION_UPDATE_ACK: is an acknowledgement sent by a participant as a response to AutomationCompositionUpdate
- 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 an Automation Composition 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 an Automation Composition 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 Automation Composition 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 an Automation Composition
--------------------------------------
- AUTOMATION_COMPOSITION_UPDATE message with instantiation details and UNINITIALISED state is sent to participants
- Participant-intermediary validates the current state change
- Participant-intermediary will recieve AUTOMATION_COMPOSITION_UPDATE 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 an Automation Composition
--------------------------------------
- AUTOMATION_COMPOSITION_STATE_CHANGE message with UNINITIALISED state is sent to participants
- Participant-intermediary validates the current state change
- Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of AutomationCompositionElements to participants
- Each participant performs its designated job of undeployment by interacting with respective frameworks

Design of "issues automation composition commands to automation compositions" - case UNINITIALISED to PASSIVE
-----------------------------------------------------------------------------------------
- AUTOMATION_COMPOSITION_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 AUTOMATION_COMPOSITION_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 PASSIVE to UNINITIALISED
-----------------------------------------------------------------------------------------
- AUTOMATION_COMPOSITION_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 AUTOMATION_COMPOSITION_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 PASSIVE to RUNNING
-----------------------------------------------------------------------------------
- AUTOMATION_COMPOSITION_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 AUTOMATION_COMPOSITION_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 RUNNING to PASSIVE
-----------------------------------------------------------------------------------
- AUTOMATION_COMPOSITION_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 AUTOMATION_COMPOSITION_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 AUTOMATIONCOMPOSITION_UPDATE_ACK message
------------------------------------------
- A participant sends AUTOMATIONCOMPOSITION_UPDATE_ACK message in response to a AUTOMATIONCOMPOSITION_UPDATE message.
- For each CL-elements moved to the ordered state as indicated by the AUTOMATIONCOMPOSITION_UPDATE
- AutomationCompositionUpdateAckListener in CL-runtime collects the messages from DMaap
- It checks the status of all automation composition elements and checks if the automation composition is primed
- It updates the clamp-acm in DB accordingly

Design of a AUTOMATIONCOMPOSITION_STATECHANGE_ACK is similar to the design for AUTOMATIONCOMPOSITION_UPDATE_ACK