Background

Multiple TOSCA Parsers have been used in ONAP across different projects.

List some projects as an example::

Project	Implementation language	Parser used
SO	Java	SDC Tosca Parser
VF-C	Python	NFV Tosca Parser
UUI	Java	SDC Tosca Parser
VNFSDK	Java/Python	NFV Tosca Parser SDC Tosca Parser
Policy	Java	Internal Tosca Parser (Policy Type, Data Type, Policy only)
A&AI	Java	SDC Tosca Parser
SDNC	Java	SDC Tocsa Parser
VID	Java	SDC Tosca Parser
SDC	Java	SDC Tosca Parser
CLAMP	Java	SDC Tosca Parser
APPC	Java	SDC Tosca Parser
CDS	Kotlin	CDS/Custom Tosca Parser
...	...	...

Here only list part of the projects, not all the parser consumer project.

Now, all projects consume the parser interfaces through the lib library and project chose to use different parser based on the implementation code language

In summary, currently , the same parser function has different implementations, but parser as a common service should be unified and provided as a service not the lib library.

Advantages of Parser as a Microservice

Microservice can be decoupled from applications
Effect: The application does not need to know the implementation details of the Passer, only need to pay attention to the results of the analysis.
Current status: As a Library, an application can use parser only after understanding the internal implementation of Parser.
Multi-language support
Effect: Parser provides services through restful, language-independent, and can support any language such as python and java.
Current Status: There are different Parser tools for different languages, and cross-language support is difficult.
Easy to upgrade
Effect: Parser upgrades independently, only keep the external restful interface unchanged.
Current Status: The current Parser as Library, the application sees the internal implementation details of Parser, if Lib upgrade, it will affect the application.
Easy to deploy, support horizontal expansion
Current Status: With the application deployment, it is not easy to support horizontal expansion, and there is basically no flexibility.
Effect: After Parser is as a service, it conforms to Cloud Native idea, can utilize platform advantages, flexible deployment, and horizontal expansion.

Disadvantages of Parser as a microservice

Performance: Compared with the Lib usage, when Parser provides services through restful, the performance will be reduced
Delay: Compared with the Lib usage, when Parser provides services through restful, the delay will increase

Note： Temporarily there is no data support for the above performance and delay

Implementation recommendations

For external interface
After the tosca parser microservice is implemented, the Lib usage will continue to be provided, and the application can select to use the microservice or the Library according to the specific requirements scenario

For Parser implementation

Requirement Analysis ( which is tracked in SDC Template Type Analysis): collecting requirements, unifying model input and output, simultaneously implementing model output conversion from object to Json (this is the key point)

API Incapsulation: Providing unified restful interface to parser client.

For parser API abstraction，there are two options considered

Option

Description

Advantage

Disadvantage

1

Parser only provides one simple API with the csar file as input and return complex Object which contains all content in model API may looks like: ModelObject parseCsar( csarfile)

The parser implementation is relatively simple， just focus on how to build the complex response

Client need to extract the information that they need from complex response locally，this will bring more complexity on client side

2

Parser provides the extension APIs which are more granular and return the specific content in model to client according to different API invocation

These APIs may look like:

Metadata getServiceMetadata(InputParameter)

Inputs getInputs(InputParameter)

......

Don’t need to maintain two library code and can solve cross-language issue.

Parser should keep the context information and increase the difficulty of parser implementation

Supplement

In order to analysis the tosca parser requirements, we do some analysis on the tosca types which currently included and used in SDC and the analysis can be found here: SDC Template Type Analysis

Known TOSCA Parsers

See the list on this TOSCA page

Discussion Minutes (20190102)

Agreement: SDC Type fix ABC for Dublin
Target: Parser as a service
Problem: Rest API definitions for Parser us
Next Steps:
- Parser API analysis for run time consumers;
- Brain Storming in Paris for Parser API design.

Browser not supported