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 6 Current »

API Fabric Analogy 

The concept of API Fabric is quite similar to what is followed in Textile industry where the raw fiber is converted to yarn, fabric, which is then used for making different clothing products and finally packaged for consumption by end-user. Similarly here raw APIs exposed by ONAP components are assembled to create façade (quite similar to fabric) and then used for creating productized APIs (quite similar to clothing) that can be subscribed. API Fabric as a solution provides the capability to manage raw APIs and enable operational end-users to develop custom APIs required for operational use cases, combining business logic and enriched data from multiple backend APIs  (quite similar to how different type of clothing is made). API fabric facilitate custom use case and application development by easier composition of APIs of ONAP management and orchestration capabilities (quite similar to how different clothing types can be made). 

Proof of Concept Context 

As per the discussions in previous ONAP F2F meeting, there were multiple views of using API Fabric

  • As a toolset for API management
  • As a Façade layer for hiding complexity of ONAP APIs
  • As an enabler for hosting standard API adaptors
  • As an Operational flow enabler
  • As a gateway to enable secure access to ONAP APIs

The current PoC touch upon above aspects and primarily drives a general theme as to how ONAP can be consumed more efficiently by operational team, how operational automation can be carried out seamlessly without getting impacted by ONAP releases or variability in ONAP component capabilities.

Demo Goals 

  • To showcase how API Fabric will be useful for ONAP projects and use cases
  • To provide a mechanism for an end-user (operations user) to manage their own APIs without relying on the ONAP project teams
  • To showcase how ONAP can expose standard interfaces in a manageable and model-driven way
  • To showcase how the security of existing ONAP services can be enhanced with additional OAuth2.0 based token authentication and API Keys 
  • To showcase how a façade API can be exposed from ONAP to end-users without sharing much of the intricacies of the internal implementations

Demo Scenarios 

  • An operational user wants to integrate existing third party solution with ONAP through a secure API channel, security to be enforced through an enterprise auth provider deployed in the CSP premise
    • Mapped demo case – ONAP Ext-API access through an OAuth2.0, https enabled interface
    • Potential use case – Integration of ONAP with BSS Solutions and Enterprise Apps, Integration of ONAP with SaaS Cloud or Digital Marketplace
  • An operational user wants to leverage one of the components in ONAP as a modular entity and selectively integrate with an existing business application through a façade interface (complexity-reduced interface)
    • Mapped demo case – ONAP SOL003 adaptor hosting
    • Potential use case – ONAP as a service,  AAI or DCAE integration with existing Business Apps. Lawful intercept/Security monitoring solution integration with Policy 
  • An operational user wants to host a standard API Adapter - to interface with ONAP components or interface from ONAP components to an external component based on popular standard reference architecture.
    • Mapped demo case – ONAP SOL003 adaptor hosting , building reusable adaptor capabilities
    • Note: We have selected SOL003 as this was one of the scenarios which were available as reference, the scenarios above hold good for SOL005, SOL002 as well.
    • Potential use case – ONAP integration to legacy NFVO or S-VNFM or EMS through standard API
  • An operational user wants to manage APIs in a consistent manner – on board the APIs, manage security tokens, manage the subscriptions, manage the plans, manage the quota, manage the logs/traces/consumption, etc.
    • Mapped demo scenario – API Fabric API Management capability
    • Potential use case – Centralized operations management, Devops and NetOps . Operational automation.

Two scenarios are developed for the demo - Secure access of Ext-API TMF APIs from Business Apps or Partner Orchestrator 2) , Hosting a standard API Adapter to work with ONAP components 

Proof Of Concept Functional View 

For the PoC API Fabric is deployed as an independent microservice, but the original plan is to host API Fabric as a subcomponent of Ext-API. Note that this does not limit ONAP internal components in using API Fabric for own use cases (primarily for façade/secure/standard APIs).


Proof of Concept Implementation View 


Demo Scenarios

1) Ext-API Secure access

2) Adapter Hosting 

3) API Management Outline 

3.a) API Onboarding 

3.b) Plugin instrumentation (if required) for alignment with ONAP

3.c) API Security Configuration 

3.d) API Activation 

3.e) API Subscription 

3.f) API Consumption 


Proof of Concept Deployment Details 

  • API Fabric Micorservices :
    • API Management : 4 (gateway, api, ui, mongodb) , can be independently scaled. (All from Gravitee open-source solution) 
    • Authentication Provider : Currently using an open source variant from Gravitee (gravitee.io) 
    • VNFM Proxy : From ONAP SOL003 Adapter 
  • ONAP Release alignment : Dublin
  • Plugins developed : 4 (AAI Data Fetcher, SDC Data Fetcher, VNF Operation Manager, VNF Operation Validator) – Code size ~ 800 LOC Java code (For all plugins) 
  • Policies reused – Cache, OAuth 2.0, Dynamic Routing

How the proposed proof of concept can be used? 

  • As a wrapper around ONAP to expose simplified, secure and modular capabilities 
  • To build standard adapters in ONAP 
  • As an API management and stitching layer for use cases 
  • As a basic building block of ONAP components to expose a less complex interface 
  • For much broader integration use cases 
  • As a means of operational automation 
  • No labels