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)
...
- Proposed name for the project: API GatewayFabric
- Proposed name for the repository: apigwapifabric
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.
...
- 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.
- 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.
...
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 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.
...