X-Git-Url: https://gerrit.onap.org/r/gitweb?a=blobdiff_plain;f=docs%2Farchitecture.rst;h=fa6d503ae943cba52511a6e5a018bb7ae0843d21;hb=HEAD;hp=cae6bca0b44916c655314dae2c90cce893625197;hpb=3d3b9def088b171329dc47fd7a1c471d25aafc06;p=dmaap%2Fdatarouter.git diff --git a/docs/architecture.rst b/docs/architecture.rst index cae6bca0..fa6d503a 100644 --- a/docs/architecture.rst +++ b/docs/architecture.rst @@ -10,13 +10,6 @@ Capabilities The DMaaP Data Router (DR) provisioning API is an HTTPS-based, REST-like API for creating and managing DR feeds and subscriptions, which provides a pub/sub architectural model for the transfer of data. -The DR API also supports `AAF CADI authorization `_. - -To use this feature, the API client must provide a valid AAF AppID / MechID with each request. -To enable this feature, see the :ref:`configuration` section. - -.. note:: In future releases, AAF CADI auth will be enabled by default. - Usage Scenarios --------------- Typically, DR pub clients request the provisioning of a new DR feed. @@ -24,22 +17,42 @@ Once created, DR sub clients can then subscribe to the feed to receive all data .. image:: images/dr_pub_flow.png +Previously, prospective publishers and subscribers would use the DMaaP Bus Controller API, which would call +the DR provisioning API to manage feeds and subscriptions. -The DR provisioning API is not meant to be used directly by DR end users (publishers and subscribers) -for feed / subscription CRUD (create, read, update, delete) operations. +However, with the deprecation of Message Router, the DMaaP Bus Controller API has also been deprecated and +DR provisioning has been brought into DR itself. This will be performed through the +Data Router (DR) provisioning client. -Instead, prospective publishers and subscribers should use the DMaaP Bus Controller API, which will call -the DR provisioning API to manage feeds and subscriptions. +The Data Router (DR) provisioning client runs as a Kubernetes initContainer for ONAP DCAE applications +that use DR feeds to transfer data between applications. The logic for the client is contained in a script +that makes requests to the DR provisioning node using the DR provisioning API. +(See the `API documentation `_ for details.) + +The DR provisioning client (drprov-client) replaces the DMaaP Bus Controller client (dbc-client). +The dbc-client used the DMaaP Bus Controller to provision data router feeds and subscribers and +DMaaP Message Router topics and clients. The Message Router provisioning functionality is no longer needed, +and Bus Controller will be deprecated and removed from the ONAP tree. - .. image:: images/dr_bc_prov.png +The provisioning logic is in a script called drprov-client.sh. This script is set as the +entrypoint for the initContainer. +The drprov-client performs two high-level tasks: -See DMaaP Bus Controller API docs for more information: +- Makes requests to the DR provisioning API to create feeds and subscriptions and captures the API's responses. +- Uses the API's response to update a component's configuration file by replacing placeholders in the file + (in the form of environment variable names) with values from the API responses. -`Bus Controller Feeds API `_ +The drprov-client script queries the DR provisioning API to determine if a feed already exists (based on the feed +name and feed version) and does not attempt to create the feed again. Instead, it retrieves the feed information +for the existing feed and supplies that information to a component. -`Bus Controller Subs API `_ +Similarly, the drprov-client script queries the DR provisioning API to determine if a subscription already exists +(based on the username, password, and delivery URL for the subscription). If one exists, the script does not create +a new subscription. +Refer to `README file `_ +in drprov-client in the datarouter repo for full details. High level Architecture -----------------------