Project Name:

Proposed name for the project: ONAP Parser Common Service
Proposed name for the repository: ParserService

Project description:

Preface:

A clear separation of “Design Time” and “Run Time” execution platforms with in ONAP gives an opportunity to truly model drive the run time execution platforms from the design time modelling platform.
On the Design Front : Various developments in R1 of ONAP’s SDC and SO (MSO) modules have provided a ground for defining a logically centralized reference platform for designs & models using multitude of design patterns & grammar, it in-effect proposes a placeholder for future evolution of ONAP to truly model drive ONAP
On the Run Time Front : R1 proposes a Run Time Catalogue embedded within each Execution Platform with certain common set of functionalities that can be centralized (in model driven architecture spirit) and eventually externalized for triggering business cases for much better interop between non-ONAP and ONAP based B/OSS stacks in various service providers
This proposal is an evolutionary idea to further the model driven concept and it also suggests an even greater inter-op construct with non-ONAP Service Provider B/OSS stacks for a global ONAP and truly model driven stack adoption & evolution
At a high level, this proposal is achieved in 2 stages (a) Centralization and (b) Externalization of Parser Binaries

Idea:

As part of R2, we are proposing an improvisation of parser implementation function under the “Centralization of Parser” part of the proposal
current Understanding of Parser Implementation (as part of Design / Run time catalogue) are as below –

A model creation UI (model designer) as part of “Design Time Catalogue”

Below picture depicts the segregation / dissection of parsing function spread across design and run time environments
Highlighted / Encircled Portion in Red shows functional blocks that Design Time Catalogue covers

“Design Grammar” for creation (En-Coding) of models being proposed using some of the (Apache Foundation / Cloudify Proposed / ONAP Custom / technology focussed) popular and prevalent parser(s)

Commissioned Report Results on Parser Usage and Preference By (some) Participants of a Survey Earlier in December 2017

A snapshot of result from the survey as below -

Irrespective of Parser Function that is chosen for implementation in R2 Beijing, idea is to propose “Centralization of Parser” concept as a rather “Centralization of Grammer” function and treat ONAP as a Platform rather than a finished product for use right out of the box (argument in favour is that service providers may want some custom features specific to their preferences, akin to Openstack or Linux or any other Open source porject)
Another part of proposal is to do with “Design time catalogue” function i.e. once the model are built, they are en-coded via one of the parser binary / library / definition, Refer : Picture below
While the ONAP platform may default the Parser Implementation with a certain flavour of Parsing Function Grammer, this “Centralization of Parser” proposal endeavours to provide a choice to service proviers to select any of the parser functions that were proposed in the survey (above) or beyond (in future). Even if there is ONE parser to be used in ONAP, this proposal provides the centralization as opposed to a federated implementation of parser en-coding / de-coding at multiple places.

“Design Grammar” for extrication (de-coding) of models which is proposed has to be the same as the one we used for en-coding in SDC

Parser binaries which will be used for de-coding are being built into the “Runtime Catalogue” of Service Orchestration platform
Run Time Catalogue will have two functions (i) Model De-Coding and (ii) Object Translation / Formation
Current R2 proposal is for Run Time Catalogue to be replicated for each execution platform, starting with Service Orchestration (MSO)
Our Proposal is to pluck the “Model De-Coding” aspects of the Run-time Catalogue and build that as part of the Common Services Platform as part of the “Centralization of the Parser” theme

“Common Services Platform” Implementation – Consolidated logic, as mentioned in steps 2 and 3 in above diagrams should be implemented in common service layer

Parser Definition / Binaries will sit in central common service block as a collection of micro-services in a self-contained block
By the very definition of this block, common services are applicable for all design and run time components within ONAP and hence this step will de-duplicate multiple en-code / de-code functions and make them central to ONAP blocks
By adopting this approach, we would have created a placeholder for TOSCA / Parser function binaries and reference definitions
While this provides central definition / orchestration and control of TOSCA parsers, this implementation also provides a hook into the nest steps of our proposal

Subsequent extensions is the proposed “Externalization of Parser” concept. Acquisition of Parser Binaries / Definition from a central repository which is hosted and maintained by a standard body like Apache Foundation or OASIS or Linux Foundation – We understand that this proposal would require (one or more) SDO engagements and will need a governance around Parser Definition / Distribution & on-going management. However if we ever had a chance to make ONAP and rest of the B/OSS Service Provier stack model driven, perhaps this is it. If we can (a) Centealize Parser (b) Externalize the Reference (c) Build Business Case for Existing B/OSS Stack of CSPs to upgrade and reference same global parser function (d) Work Out the interop, by use of MEF / TMF APIs – that would take us to a truly model driven economy for a service provider across ONAP and non-ONAP stacks

Architecture Improvisation

Points to Note :

Common theme across design and run time is the use of common TOSCA binaries for en-coding and de-coding
The object formation function of run time catalogue is specific to the execution platform, since the data model of the application is not common
Implementation of the run time catalogue can be central or distributed, however the key function of RT catalogue i.e. object formation is tightly coupled with data models of the respective execution platform applications
Only common thread is the use of binaries / definitions - if an Apache TOSCA parser is to be used, the same has to used at both ends of the modelling spectrum i.e. design and run time
Hence a common parser grammer placeholder as well as model ↔ parser (function & binary repository) ↔ model conversion is the core part of functionality that can be centralized and this is what parser common service proposal is all about

Sequence Diagrams

Centralisation

Externalization

Overall Scope: High Level Requirements

De-Coupling of Library Requirements of En-Coding Function from SDC / Design Time Catalogue

De-Coupling of Library Requirements of De-Coding Function from MSO / Run Time Catalogue
Creation of TOSCA Parser Binary Placeholder in Common Services Layer
Creation of Consumption / Reference (for the Parser Binaries) Flows from Common Services Layer
Common Services Layer Logic Implementation Using Micro-Service(s) - For orchestrating TOSCA parser binaries
(Subsequently) Implementation of Binary Acquisition / Updation from External Repository (Dependency on SDO engagement)
Governance around Parser / Models Function Maintenance

High Level Story: Centralization

High Level Stories: Externalization

Detailed Deliverables:

Activity / Capability	Description	Comments / Notes / Dependency
Centralization User Story / PAR1 · Creation / Ring-Fencing the Parser En-Coding & De-Coding Function	· The actual En-Coding and De-Coding Logic remains part of the Design time and Run time catalogue · Binary / Definition, which are referenced by these blocks will reside in Common Services Layer, this story will focus on isolating the logic for referencing of parser binaries	· Binary Acquisition Service / API exposed by Common Service Layer needs to be sorted · TOSCA Binary Refresh / Push / Pull Mechanism to be Sorted (on to consumer platforms)
Centralization User Story / PAR2 · De-Coupling of Ring-Fenced logic from SDC into Common Services Layer	· Once the binary definition placeholder is segregated within catalogues, the same needs to be ported to Common Services Layer	· Implementation of binary hold within Common Service Layer should be via micro-service(s)
Centralization User Story / PAR3 · Create API / Interface for acquiring Parser Binaries from Common Services Layer	· Common Services Layer needs to expose the binary acquisition via services / APIs in a standard way to (any consumer) platform	· The mechanism is very similar to how catalogue function downloads models on to execution platforms, TMF / MEF needs to be referenced for any suitable API / Generic mechanism to transfer the definitions binary
Externalization User Story / PAR4 · Modify Parser Container in Common Services Layer to start referencing external SDO via API exposure layer	· Binary / Definition itself will reside external to ONAP, within a globally available repository managed and operated by a SDO · ONAP team has to work with SDO to agree common way of Parser/Repository Governance, Maintenance and Exposure	· Dependency on SDO engagement and governance

Supplimentry Information

Managed Objects:

Parser Definition / Binaries
Worflows, Versioning
Service Templates and Parsed Template Outputs

Functions:

TOSCA Parser Binary Management, including synchronization, upload, acquire / distrubute functions
Integration with OOM or its own UI for Parser Binary Management
Provide API to fetch / distrubute the binaies to design / run time catalogues, including the external non-ONAP system (via API Gateway), and inner run time ONAP components

Role	Name	Gerrit ID	Company	Email	TimeZone
Primary Contact	Atul Purohit		Vodafone Group	Atul.Purohit1@Vodafone.com	Newbury, UK, GMT / UTC
Committers (Yet to confirm)	Cloudify
	Amdocs
	NetCracker
	Huawei
	Infosys
	E///

Browser not supported