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 21 Next »


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

SDC Tosca Parser

A&AIJavaSDC Tosca Parser
SDNCJavaSDC Tocsa Parser
VIDJavaSDC Tosca Parser
SDCJavaSDC Tosca Parser
CLAMPJavaSDC Tosca Parser
APPCJavaSDC 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

  1. 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.

  2.  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.


  3. 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.

  4.  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

  1.  Performance: Compared with the Lib usage, when Parser provides services through restful, the performance will be reduced 


  2. 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

  1.  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


  2.  For Parser implementation


    1. 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)

    2. API Incapsulation: Providing unified restful interface to parser client.

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

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.






  • No labels