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

See A&AI Context Builder

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

Key APIs

• POMBA Initiating Audit
• POMBA Context Builder Swagger

Design Issues

DevOps

Links