API Fabric Project
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 3rd 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.