Update dmaap references in policy documentation files

Issue-ID: POLICY-4942
Change-Id: I08d9ab8e5028eab0a20999ce174d3a2fbad67967
Signed-off-by: FrancescoFioraEst <francesco.fiora@est.tech>

8 files changed, 14 insertions, 14 deletions

diff --git a/docs/clamp/acm/design-impl/clamp-gui-acm.rst b/docs/clamp/acm/design-impl/clamp-gui-acm.rst
index b0a2782f..600c721d 100644
--- a/docs/clamp/acm/design-impl/clamp-gui-acm.rst
+++ b/docs/clamp/acm/design-impl/clamp-gui-acm.rst
@@ -51,7 +51,7 @@ Class-based react components are used to render the different pages related to f
 2.1.2 Automation Composition GUI
 ================================
 
-The current automation composition GUI is an extension of the previously created GUI for the Clamp project. The Clamp project used the CLAMP GUI to connect to various onap services, including policy api, policy pap, dcae, sdc and cds. Although the current automation composition project builds upon this GUI, it does not rely on these connected services. Instead, the Automation Composition GUI connects to the Automation Composition Runtime only. The Automation Composition Runtime then communicates with the database and all the Automation Composition participants (indirectly) over DMAAP.
+The current automation composition GUI is an extension of the previously created GUI for the Clamp project. The Clamp project used the CLAMP GUI to connect to various onap services, including policy api, policy pap, dcae, sdc and cds. Although the current automation composition project builds upon this GUI, it does not rely on these connected services. Instead, the Automation Composition GUI connects to the Automation Composition Runtime only. The Automation Composition Runtime then communicates with the database and all the Automation Composition participants (indirectly) over Kafka.
 
 The CLAMP GUI was originally housed in the clamp repository but for the Istanbul release, it has been moved to the policy/gui repo. There are 3 different GUIs within this repository - clamp-gui (and Automation Composition gui) code is housed under the "gui-clamp" directory and the majority of development takes place within the "gui-clamp/ui-react" directory.
 
@@ -106,15 +106,15 @@ This is where all of the endpoints for operations on Automation Compositions are
 
 The rest endpoints are split over two main classes; CommissioningController.java and InstantiationController.java. There are also some rest endpoints defined in the MonitoringQueryController. These classes have minimal business logic defined in them and delegate these operations to other classes within the controlloop.runtime package. The Automation Composition Runtime write all data received on its' endpoints regarding commissioning and instantiation to its; database, where it can be easily accessed later by the UI.
 
-The Runtime also communicates with the participants over DMAAP. Commissioning a automation composition definition writes it to the database but also triggers priming of the definitions over DMAAP. The participants then receive those definitions and hold them in memory. Similarly, upon decommissioning, a message is sent over DMAAP to the participants to trigger de-priming.
+The Runtime also communicates with the participants over Kafka. Commissioning a automation composition definition writes it to the database but also triggers priming of the definitions over Kafka. The participants then receive those definitions and hold them in memory. Similarly, upon decommissioning, a message is sent over Kafka to the participants to trigger de-priming.
 
-Using DMAAP, the Runtime can send; updates to the automation composition definitions, change the state of automation compositions, receive information about participants, receive state information about automation compositions and effectively supervise the automation compositions. This data is then made available via Rest APIs that can be queried by the frontend. This is how the GUI can perform monitoring operations.
+Using Kafka, the Runtime can send; updates to the automation composition definitions, change the state of automation compositions, receive information about participants, receive state information about automation compositions and effectively supervise the automation compositions. This data is then made available via Rest APIs that can be queried by the frontend. This is how the GUI can perform monitoring operations.
 
 More detail on the design of the Runtime Automation Composition can be found in :ref:`clamp-runtime-acm`.
 
-2.4 DMAAP
+2.4 Kafka
 ---------
-DMAAP is component that provides data movement services that transports and processes data from any source to any target.  It provides the capability to:
+Kafka is component that provides data movement services that transports and processes data from any source to any target.  It provides the capability to:
 - Support the transfer of messages between ONAP components, as well as to other components
 - Support the transfer of data between ONAP components as well as to other components.
 - Data Filtering capabilities
@@ -131,10 +131,10 @@ The purpose of the Automation Composition participants is to communicate with di
 
     .. image:: ../images/gui/ParticipantsDirectory.png
 
-The participants communicate with the Runtime over DMAAP. Tosca service template specifications, Automation Composition updates and state changes are shared with the participants via messages from runtime Automation Composition through the topic "POLICY-CLRUNTIME-PARTICIPANT".
+The participants communicate with the Runtime over Kafka. Tosca service template specifications, Automation Composition updates and state changes are shared with the participants via messages from runtime Automation Composition through the topic "POLICY-CLRUNTIME-PARTICIPANT".
 
 3. GUI Sample Flows
 ###################
-The primary flows from the GUI to the backend, through DMAAP and the participants are shown in the diagram below. This diagram just serves as an illustration of the scenarios that the user will experience in the GUI. You can see factually complete dialogues in :ref:`system-level-label`.
+The primary flows from the GUI to the backend, through Kafka and the participants are shown in the diagram below. This diagram just serves as an illustration of the scenarios that the user will experience in the GUI. You can see factually complete dialogues in :ref:`system-level-label`.
 
     .. image:: ../images/gui/GUI-Flow.png
diff --git a/docs/clamp/acm/design-impl/clamp-runtime-acm.rst b/docs/clamp/acm/design-impl/clamp-runtime-acm.rst
index 5b88edba..c21cc171 100755..100644
--- a/docs/clamp/acm/design-impl/clamp-runtime-acm.rst
+++ b/docs/clamp/acm/design-impl/clamp-runtime-acm.rst
@@ -19,7 +19,7 @@ Terminology
 - Spring Scheduling: into SupervisionAspect class, the @Scheduled annotation invokes "schedule()" method every "runtime.participantParameters.heartBeatMs" milliseconds with a fixed delay
 - MessageIntercept: "@MessageIntercept" annotation is used into SupervisionHandler class to intercept "handleParticipantMessage" method calls using spring aspect oriented programming
 - GUI: swagger-ui, Postman or policy-gui
-- Message Broker: supported message Broker are DMaap and Strimzi-Kafka
+- Message Broker: It supports the message Broker Kafka
 
 Design of Rest Api
 ******************
diff --git a/docs/clamp/acm/design-impl/participants/a1pms-participant.rst b/docs/clamp/acm/design-impl/participants/a1pms-participant.rst
index 23e70b9b..5afbf912 100644
--- a/docs/clamp/acm/design-impl/participants/a1pms-participant.rst
+++ b/docs/clamp/acm/design-impl/participants/a1pms-participant.rst
@@ -7,7 +7,7 @@ A1PMS Participant
 
 The A1PMS participant receives A1 policy service information from the CLAMP runtime and creates the A1 policy service in A1PMS. The participant acts as a wrapper around the A1PMS and creates the policy service.
 
-Supported message Broker are DMaap and Strimzi-Kafka.
+It supports the message Broker Kafka.
 
 .. image:: ../../images/participants/a1pms-participant.png
 
diff --git a/docs/clamp/acm/design-impl/participants/http-participant.rst b/docs/clamp/acm/design-impl/participants/http-participant.rst
index 3125e173..03605377 100644
--- a/docs/clamp/acm/design-impl/participants/http-participant.rst
+++ b/docs/clamp/acm/design-impl/participants/http-participant.rst
@@ -13,7 +13,7 @@ the microservice that runs a REST server. Once the microservice is up, the HTTP
 participant can be used to configure the microservice over its REST interface.Of course,
 the HTTP participant works towards any REST service, it is not restricted to REST
 services started by participants.
-Supported message Broker are DMaap and Strimzi-Kafka.
+It supports the message Broker Kafka.
 
 .. image:: ../../images/participants/http-participant.png
 
diff --git a/docs/clamp/acm/design-impl/participants/k8s-participant.rst b/docs/clamp/acm/design-impl/participants/k8s-participant.rst
index dae5df5d..82935bda 100644
--- a/docs/clamp/acm/design-impl/participants/k8s-participant.rst
+++ b/docs/clamp/acm/design-impl/participants/k8s-participant.rst
@@ -10,7 +10,7 @@ k8s cluster on the specified namespace. It can fetch the helm chart from remote
 that are configured on the helm client. The participant acts as a wrapper around the helm client and creates the required
 resources in the k8s cluster.
 
-Supported message Broker are DMaap and Strimzi-Kafka.
+It supports the message Broker Kafka.
 
 The kubernetes participant also exposes REST endpoints for onboarding, installing and uninstalling of helm charts from the
 local chart database which facilitates the user to also use this component as a standalone application for helm operations.
diff --git a/docs/clamp/acm/design-impl/participants/kserve-participant.rst b/docs/clamp/acm/design-impl/participants/kserve-participant.rst
index 618b7ebd..24314a3d 100644
--- a/docs/clamp/acm/design-impl/participants/kserve-participant.rst
+++ b/docs/clamp/acm/design-impl/participants/kserve-participant.rst
@@ -7,7 +7,7 @@ Kserve Participant
 
 The Kserve participant receives inference service information from CLAMP runtime and creates the inference services in the Kubernetes cluster. The participant acts as a wrapper around Kserve and creates the inference service.
 
-Supported message Broker are DMaap and Strimzi-Kafka.
+It supports the message Broker Kafka.
 
 .. image:: ../../images/participants/kserve-participant.png
 
diff --git a/docs/clamp/acm/design-impl/participants/participant-intermediary.rst b/docs/clamp/acm/design-impl/participants/participant-intermediary.rst
index 891f5771..0fbaf897 100755..100644
--- a/docs/clamp/acm/design-impl/participants/participant-intermediary.rst
+++ b/docs/clamp/acm/design-impl/participants/participant-intermediary.rst
@@ -16,7 +16,7 @@ Terminology
 - 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
+- Message Broker: It supports the message Broker Kafka
 
 Inbound messages to participants
 --------------------------------
diff --git a/docs/clamp/acm/design-impl/participants/participants.rst b/docs/clamp/acm/design-impl/participants/participants.rst
index 4dab3434..6b12b7c4 100644
--- a/docs/clamp/acm/design-impl/participants/participants.rst
+++ b/docs/clamp/acm/design-impl/participants/participants.rst
@@ -7,7 +7,7 @@ Automation Composition Participants
 
 A Participant is a component that acts as a bridge between the CLAMP Automation Composition Management runtime and components such as
 the Policy Framework, DCAE, or a Kubernetes cluster that are taking part in automation composition management. It listens
-to DMaaP to receive messages from the CLAMP runtime and performs operations towards components that
+to Kafka to receive messages from the CLAMP runtime and performs operations towards components that
 are taking part in acms. A participant has an Automation Composition Management Element for each automation composition in
 which it is taking part.