Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 61 Next »

POMBA Definition 

What is POMBA - Post Orchestration Model Based Audit

Architecture Intent

High level view of POMBA components

   


Design

Design Principles

  • Reusable Components

POMBA is developed based on microservices-based architecture to ensure pluggable capability into other Data Integrity sub-system

POMBA uses other microservices initially designed for A&AI component promoting them as a platform modules.

  •  Event-Driven

POMBA is event-driven application to ensure auditing without affecting existing systems.

  • Extensibility

POMBA is implemented based on Context Builders Framework to ensure that core audit process is decoupled from the target system integration specifics.

            

Sequence Diagrams



Process Flow

  1. Service Instantiation completion event is published
  2. Context Aggregator receives the event
  3. Context Aggregator initiates calls to various Context Builders to get normalized data from platform components.
  4. Context Aggregated payload is published into event bus
  5. Rule Processing engine receives that event and activates audit rules processing
  6. The result of audit rules processing is published into Event Bus
  7. Audit Result payload is consumed by synapse service
  8. The result is inserted into data storage / ES via search service
  9. Reporting tool such as Kibana displays  the data

Sub-Components

POMBA leverages context builders approach to provide pluggable framework of accessing various ONAP components to retrieve the data. 

It allows to encapsulate the complexity of reaching a component as well as implement the mapping and transformation component’s related data to common model consumed by audit process. 

SDC Context Builder 

See SDC Context Builder

A&AI Context Builder

The purpose of A&AI Context Builder is to encapsulate the complexity of interaction with A&AI component .

High level view of A&AI Context Builder mS:




SDN-C Context Builder

SDN-C Context Builder is aimed to encapsulate the functionality of accessing SDN-C via RESTful APIs and transform the data into common model structure used by audit process.



Context Aggregator

Context Aggregator is a microservice that orchestrates the calls to various context builders which are pluggable into POMBA upon receiving the Orchestration Completion Event from Message Router.

Context Aggregator is configured to subscribe to the Message Router topic.

Once new event is published – Context Aggregator executes series of RESTFull GET requests to various context builders to obtain a data (service model / service instance  / VNF instance)  stored in component data stores in a common model format, aggregates these payloads into one payload structures and publishes that payload into Message Router.


Validation Service + Rule Processing

Validation service is a core A&AI microservice which implements a rule processing engine.

POMBA configures and deploys its own instance of validation service that consumes and publishes to POMBA topics in DMaaP.

Audit rules are stored in groovy format file. The files are injected into a service and rules are processed by the engine.

Currently audit rules are hand crafted, but eventually will be sourced from well formed ASDC models and from Data Dictionary.  Existing rules are listed here.

POMBA will eventually support the mechanism of separating rules from validation service code, thereby allowing rule updates without a rebuild or restart of the validation service.

The text of the message displayed for each violation will be kept separately to allow text change without touching the code



Search Data Service

The Search Service microservice was created to be an abstraction layer above indexable storage engine (i.e Elasticsearch).

Using search data service allows to leverage any search & storage engine (currently it supports Elasticsearch).

All requests which result in Elasticsearch CRUD (Create, Read, Update, Delete) operations should be made to SDS using its API, at which point SDS will convert the requests to align with Elasticsearch's API and forward them on.


DMaaP

See POMBA DMaaP

Deployment Model

Containers

IDNameport pod dependenciesAttributes

ONAP referencing dependencies

Incoming API

ONAP ref dependencies

Outgoing API

Notes
1synapse service9502 dmaap, search-data-service
/data-router/v1/orchestration-event-service/orchestration-eventdmaap APIs, /services/search-data-service/v1/search/indexes 
 2search-data-service9509 elastic-search 
 /services/search-data-service/v1/search/indexeselasticSearch APIs
 3elastic-search 9200n/a 
 n/a n/a
aai-context-builder9530 aai-service 
/aaicontextbuilder/service/context  A&AI APIs
 5 sdn-c-context-builder9531  sdnc
/sdnccontextbuilder/service/context  SDN-GC APIs
 6 sdc-context-builder9532  sdc-be
/sdccontextbuilder/service/context  SDC BE APIs
 7 context-aggregator9529 aai-context-builder,sdc-context-builder, sdn-c-context-builder, dmaap
 dmaap APIsdmaap APIs 
 8 validation-service9501 dmaap
dmaap APIs dmaap APIs 
 9dcae-context-builder 9540 DCAE, Vertica DB ? 
 /<serviceContext>/service/context  

10  network-discovery-context-builder9550 

 /<serviceContext>/service/context  


Key APIs

Design Issues

DevOps

Links


  • No labels