Page History

Update September 2019: A PoC for demonstrating the capabilities of API Fabric is being developed.  This will be demonstrated by mid-September. Please refer to the child page for details. 

Update October 2019: API Fabric proposal is put on hold and to be revisited after the Frankfurt release cycle. 

------------------------------------------------------------------------------------------------

Supported Operators: Vodafone, Swisscom (In discussion with other Operators) 

Project Name

• Proposed name for the project: API Fabric
• Proposed name for the repository: apifabric

Project Goal

Component for managing high-level APIs exposing the business logic of ONAP. Handles API management including the API Lifecycle, API Monitoring, API Security and Policy Control, API Transaction Logging, API Abstraction, and Transformation. Currently, there is a module in the MSB project with name Internal/External API Gateway. There is also an External API project. with the responsibility to integrate ONAP with OSS/BSS Solutions through TMF APIs.  The proposed functionality should not be confused with what MSB or Ext-API is providing as of today and suggested to check the comparison below with Ext-API and MSB. 

Background

ONAP today has many components/projects and many APIs exposing functional capability of components. There are dedicated components which manage API transformation between internal and external systems - such as Ext-API, Multi-Cloud, SDNC/App-C etc. There are also projects which compose functionality and expose low-level APIs (which are focused on exposing component specific management/functional interfaces). Most of the times, such low-level APIs are very complex to manage and consumer (such as other components in ONAP, external applications, use case specific applications etc. ) needs to be aware of very minute details (version, certificate, authentication, the right entity to be operated on, etc) of the provider to use the APIs in the right sequence and with the right information. This often leads to the tight dependency between components and additional overhead for project teams. There is no logical layer which consolidates these APIs and exposes a façade that is consumer friendly and hides many complexities associated with component level functional APIs. The need for such a facade layer has been discussed many times in the past in relation to the Modularity and also to make ONAP production ready/standard compliant etc.  The API GW Project is proposed to address the following problem statements

• Different API Management approaches: In ONAP each component exposes own APIs corresponding to the functionality supported. In addition to this, each project follows different approaches for API security, API documentation, and moreover API style itself (entity based, action based etc). This creates a lot of burden for the API consumer, especially use case developer who is focused on the high-level functionality to be leveraged than component level API intricacies (version, security, style, etc.). There should be consistency across components in defining APIs or there should be a logical layer (Facade)  which hides these inconsistencies/complexities so that the API consumer need not build different set of adaptors or require different expertise to consume the component level APIs.
• Standard Alignment is a priority in ONAP: In recent releases, standard interface and model alignment became a hot topic of discussion. Currently, standard API alignment is addressed by individual projects independently depending on specific use cases. There is also the redundant implementation of adaptors – for example, SOL005 API adaptor proposed for SO/Ext-API , SOL003 API Adaptor in SO for S-VNFM connectivity, SOL003 adaptor development in VFC, SOL005 adaptor development in VFC NFVO, SOL003 adaptor in SDNC and SOL002 adapter in SO, etc. There should be a consistent adaptation layer that can be consumed by internal and external API consumers so that maintenance and compliance of the APIs can be managed well.
• Production deployments require interoperability with legacy and 3rd Party components: In typical production deployment of ONAP, it will require integration with legacy and 3^rd Party applications in the operator premise. Currently, the expectation is that System Integrator responsible for the deployment build appropriate integration layer and enable interoperability with such external applications. But this is not a healthy and consistent solution as ONAP component level interfaces evolve over releases and for applications, this becomes unmanageable as these ONAP interface APIs have some times release specific dependency and non-backward compatible. There should be a logically centralized function in ONAP which can abstract component level API evolution and expose a higher level API as well hides the dynamics at the individual component APIs. Additionally, integration with 3rd party applications in productions environment might require different types of policy enforcement, different types of adaptations. In production deployments, ONAP components may not be compatible with operators IT systems -  for example, the operator might already have an Identity Provider and Auth Provider which are not compatible with AAF. Such scenarios might require additional capability in ONAP where these incompatibilities can be accommodated rather than instrumenting each ONAP project. Another requirement is related to Modularity - Not all components in ONAP might be required in the Operator production environment, depending on the evolutionary stage of transformation. They might have already procured redundant functions as in ONAP that fulfill the use case requirements. This leads to a requirement where different  ONAP components (not in full but selectively) need to be composed at different levels of abstractions and integrated with existing solutions.  One such scenario is Legacy NFVO integration with ONAP as discussed in the Orchestration Scenarios task force-  Similar requirement would require special integration which if handled at individual ONAP project may soon become unmanageable.  
• Evolution of platform functional capability vs use case based functional enhancements : This is a typical problem in most of the open source projects - the area the project should focus – i.e. to focus on developing functional capability and make it more generic for any use case to adapt or to enhance functional capability based on specific use cases. In ONAP the functional capability of projects is primarily driven by use cases. The requirements for each use case might be different or might require a different level of capability enhancements at the project level. For project teams, this creates lot of pressure to balance requirements across use cases and also to focus on progressing the functional capability for long term requirements. There should be a logical boundary where both such requirements - from use case or from project functional enhancement – should balance. The boundary should be an API layer which cushions the impact and hides the project level evolutions at the same time supports current and future use cases. 

Project Description

The proposed project – API GW, acts as an API broker between external/internal components in ONAP and provides logically centralized API management and control capability.

Image Added

API GW closely works with three components in ONAP – Ext-API , MSB and DMaaP. API GW can provide a proxy interface to Ext-API project and enable secure connection, Federation, Policy enforcement, load balancing, and overall API Management capability. API GW can enhance the capability of MSB with built-in plugins that enhance MSB to have capabilities such as API LCM, Marketplace, API Catalog management, Analytics, RBAC, Security Management, API Aggregation and Composition, Script insertion, Expression language support, etc. API-GW can act like a DMaaP client and expose notifications to external applications through a subscribed hub resource.

This proposal does not intend to replace any of the existing components/functionality in ONAP. Some of the redundant functionality that exists between API GW and ONAP Components such as Ext-API and MSB can be managed through collaboration and mutual agreement. API GW can also potentially be a subproject of either Ext-API or MSB to augment the missing capabilities in respective projects. Another potential option is to merge functionality in Ext-API, MSB, and API-GW to create a single API Management/Adaptation component.

Please note the comparison of API GW and existing ONAP projects like Ext-API and MSB below. The comparison also covers what additional capability API GW bring in to augment the existing functionality. As for this proposal, the directions provided by Architecture committee and TSC will be followed once the need for such functionality is agreed with all stakeholders. 

How API GW Solution solves the problems stated? 

• Different API Management Approaches: Logically Centralized API GW component enables consistent approach for managing APIs without the need to develop  redundant API Adaptor, hiding a variety of approaches followed by different ONAP components
• Standard Alignment: API GW support rich transformation capability with inbuilt plugins and support for expression language that can be configured on demand rather than developing from scratch ( and subsequently waiting for a long release cycle.)
• Production deployments might require interoperability with legacy and 3rd Party components:  This is an inherent capability of API GW.  API GW allows flexible integration with external and internal systems with toolsets for HTTP Method conversion, HTTP Payload Conversion, REST/SOAP transformation, JSON/XML transformation, JSON to JSON transformation, Different types of security mechanisms, etc.  API GW can expose Façade APIs which compose the internal functionality of ONAP at desired levels of complexity. 
• Evolution of Platform functional capability vs. Use Case capability: Helps in creating abstraction layer or Façade as needed for different use cases, allowing the projects to evolve independently

Project Name

• Proposed name for the project: API Gateway
• Proposed name for the repository: apigw

Project Goal

Component for managing high-level APIs exposing the business logic of ONAP. Handles API management including the API Lifecycle, API Monitoring, API Security and Policy Control, API Transaction Logging, API Abstraction, and Transformation. Currently, there is a module in the MSB project with name Internal/External API Gateway. There is also an External API project. with the responsibility to integrate ONAP with OSS/BSS Solutions through TMF APIs.  The proposed functionality should not be confused with what MSB or Ext-API is providing as of today and suggested to check the comparison below with Ext-API and MSB. 

Background

ONAP today has many components/projects and many APIs exposing functional capability of components. There are dedicated components which manage API transformation between internal and external systems - such as Ext-API, Multi-Cloud, SDNC/App-C etc. There are also projects which compose functionality and expose low-level APIs (which are focused on exposing component specific management/functional interfaces). Most of the times, such low-level APIs are very complex to manage and consumer (such as other components in ONAP, external applications, use case specific applications etc. ) needs to be aware of very minute details (version, certificate, authentication, the right entity to be operated on, etc) of the provider to use the APIs in the right sequence and with the right information. This often leads to the tight dependency between components and additional overhead for project teams. There is no logical layer which consolidates these APIs and exposes a façade that is consumer friendly and hides many complexities associated with component level functional APIs. The need for such a facade layer has been discussed many times in the past in relation to the Modularity and also to make ONAP production ready/standard compliant etc.  The API GW Project is proposed to address the following problem statements

• Different API Management approaches: In ONAP each component exposes own APIs corresponding to the functionality supported. In addition to this, each project follows different approaches for API security, API documentation, and moreover API style itself (entity based, action based etc). This creates a lot of burden for the API consumer, especially use case developer who is focused on the high-level functionality to be leveraged than component level API intricacies (version, security, style, etc.). There should be consistency across components in defining APIs or there should be a logical layer (Facade)  which hides these inconsistencies/complexities so that the API consumer need not build different set of adaptors or require different expertise to consume the component level APIs.
• Standard Alignment is a priority in ONAP: In recent releases, standard interface and model alignment became a hot topic of discussion. Currently, standard API alignment is addressed by individual projects independently depending on specific use cases. There is also the redundant implementation of adaptors – for example, SOL005 API adaptor proposed for SO/Ext-API , SOL003 API Adaptor in SO for S-VNFM connectivity, SOL003 adaptor development in VFC, SOL005 adaptor development in VFC NFVO, SOL003 adaptor in SDNC etc. There should be a consistent adaptation layer that can be consumed by internal and external API consumers so that maintenance and compliance of the APIs can be managed well.
• Production deployments require interoperability with legacy and 3rd Party components: In typical production deployment of ONAP, it will require integration with legacy and 3^rd Party applications in the operator premise. Currently, the expectation is that System Integrator responsible for the deployment build appropriate integration layer and enable interoperability with such external applications. But this is not a healthy and consistent solution as ONAP component level interfaces evolve over releases and for applications, this becomes unmanageable as these ONAP interface APIs have some times release specific dependency and non-backward compatible. There should be a logically centralized function in ONAP which can abstract component level API evolution and expose a higher level API as well hides the dynamics at the individual component APIs. Additionally, integration with 3rd party applications in productions environment might require different types of policy enforcement, different types of adaptations. In production deployments, ONAP components may not be compatible with operators IT systems -  for example, the operator might already have an Identity Provider and Auth Provider which are not compatible with AAF. Such scenarios might require additional capability in ONAP where these incompatibilities can be accommodated rather than instrumenting each ONAP project. Another requirement is related to Modularity - Not all components in ONAP might be required in the Operator production environment, depending on the evolutionary stage of transformation. They might have already procured redundant functions as in ONAP that fulfill the use case requirements. This leads to a requirement where different  ONAP components (not in full but selectively) need to be composed at different levels of abstractions and integrated with existing solutions.  One such scenario is Legacy NFVO integration with ONAP as discussed in the Orchestration Scenarios task force-  Similar requirement would require special integration which if handled at individual ONAP project may soon become unmanageable.  
• Evolution of platform functional capability vs use case based functional enhancements : This is a typical problem in most of the open source projects - the area the project should focus – i.e. to focus on developing functional capability and make it more generic for any use case to adapt or to enhance functional capability based on specific use cases. In ONAP the functional capability of projects is primarily driven by use cases. The requirements for each use case might be different or might require a different level of capability enhancements at the project level. For project teams, this creates lot of pressure to balance requirements across use cases and also to focus on progressing the functional capability for long term requirements. There should be a logical boundary where both such requirements - from use case or from project functional enhancement – should balance. The boundary should be an API layer which cushions the impact and hides the project level evolutions at the same time supports current and future use cases. 

Project Description

The proposed project – API GW, acts as an API broker between external/internal components in ONAP and provides logically centralized API management and control capability.

Image Removed

API GW closely works with three components in ONAP – Ext-API , MSB and DMaaP. API GW can provide a proxy interface to Ext-API project and enable secure connection, Federation, Policy enforcement, load balancing, and overall API Management capability. API GW can enhance the capability of MSB with built-in plugins that enhance MSB to have capabilities such as API LCM, Marketplace, API Catalog management, Analytics, RBAC, Security Management, API Aggregation and Composition, Script insertion, Expression language support, etc. API-GW can act like a DMaaP client and expose notifications to external applications through a subscribed hub resource.

Currently, there is no proposal to replace any of the existing components in ONAP. Some of the redundant functionality that exists between API GW and ONAP Components such as Ext-API and MSB can be managed through collaboration and mutual agreement. API GW can also potentially be a subproject of either Ext-API or MSB to augment the missing capabilities in respective projects. Another potential option is to merge functionality in Ext-API, MSB, and API-GW to create a single API Management/Adaptation component.

Please note the comparison of API GW and existing ONAP projects like Ext-API and MSB below. The comparison also covers what additional capability API GW bring in to augment the existing functionality. As for this proposal, the directions provided by Architecture committee and TSC will be followed once the need for such functionality is agreed with all stakeholders. 

Architecture

API GW consists of four main building blocks – Gateway, API GW Management Component, API GW Configuration store, API GW UI. Gateway function is a stateless reverse proxy which can be instantiated on demand, scaled and distributed. It hosts a set of plugins that enhance the API control logic. The plugins are developed using the gateway SDK and attached as a library during the initialization. Gateway and Plugins refers the API configuration (i.e information about the on boarded API) from Configuration and Analytics data store. The Configuration & Analytics DS persists the API configuration and API transactional metrics. API GW can work with an inbuilt Auth provider capable of centrally managing the Authentication, Authorization of the exposed APIs. The API GW UI hosts the Management, Design and Monitoring UIs. The GW function maintains statistics and log information of APIs and stores the information in the Configuration and Analytics store. It is also possible to integrate the Configuration and Analytics Store with external monitoring solutions like Prometheus or alert engines to notify external consumers about API statistics.

...

• Existing Capabilities in MSB
  • API Endpoint Registration and Discovery
  • Static API Endpoint Routing based on port and Service URL (No payload-based routing)
  • API Load balancing
  • Service Mesh Integration Prototype
  • Integration with AAF for security policy enforcement (?)
  • Integration with OOM for dynamic Service Registration
  • Management APIs for registration of Servicesof Services
• Capabilities Augmented by API GW Solution
  • Full API Lifecycle Management
  • Manual and Bulk API Import – Swagger or Management API
  • API Subscription/Plan management, API Discovery
  • API Catalog and Marketplace
  • Integration with multiple external IDP, Monitoring solution
  • Rate Limit, Quota Mgmt , Circuit Break
  • Tenant, Role Management
  • Whitelisting , Black Listing
  • Enhanced API Security Management – OAuth2, JWT,
    Open ID etc. – All inbuilt and centrally managed
  • Script insertion in the API execution flow
  • Configurable APIs, Transformation logic
  • API Aggregation and Composition
  • Management and Monitoring UI

Benefits for ONAP 

• Support a single source of truth for High level APIs, rather than each project maintaining own versions

• Augments MSB and Ext-API capabilities

• Facade layer: Enables development of a Facade layer which abstracts the complexities of internal API

• Request/Response Transformation: Enables ONAP components to align with SDO APIs more easily without changing the existing capabilities

• Low impact on existing projects: Enable Operators to plugin standard and legacy integration API adaptors without impacting the ONAP components

• Allows Projects/Components to focus on core functionality rather than worrying about API Transformation

• Enables Tenancy/RBAC Management: Centralized API management can help in the implementation of tenancy management through policies.

  Capabilities Augmented by API GW Solution
• Full API Lifecycle Management
• Manual and Bulk API Import – Swagger or Management API
• API Subscription/Plan management, API Discovery
• API Catalog and Marketplace
• Integration with multiple external IDP, Monitoring solution
• Rate Limit, Quota Mgmt , Circuit Break
• Tenant, Role Management
• Whitelisting , Black Listing
• Enhanced API Security Management – OAuth2, JWT,
  Open ID etc. – All inbuilt and centrally managed
• Script insertion in the API execution flow
• Configurable APIs, Transformation logic
• API Aggregation and Composition
Management and Monitoring UI

• How does this project fit into the rest of the ONAP Architecture?
  API Gateway provides an API and UI interface. API can be used by components in ONAP or by administrative users to manage the lifecycle of high-level APIs. UI is primarily intended for an administrator to provision and manage APIs. The UI is also suitable for the end user as the API GW provides a consumer view – API Marketplace which can be used to subscribe to specific APIs.
• What other ONAP projects does this project depend on?
  OOM for deployment, MSB or Specific ONAP components whose APIs need to be abstracted behind a façade API (standard API), AAF for Security – Authorization, Authentication and Certificate Management
• In Relation to Other ONAP Components

...

...