Hi Manoj, I think industry is converging on service mesh technologies to solve this problem. For example, ISTIO with envoy and gloo/ambassador/ingress is being used for both E-W and N-S APIs. It does take of many of the requirements you cited.
- API Routing - API Management such as users, roles (RBAC) - API transformation - Etc.. With the integration of APIGEE as ISTIO Mixer adapter, one can even have comprehensive API management too. Only thing that is not satisfied is : Breaking big API into smaller APIs. I argue whether it belongs in service mesh as it requires application understanding. I feel that functionality should be implemented as additional application micro-service. My suggestion is to put efforts in using industry best practices ☺, see what is missing in applying those to ONAP and fix those gaps. Thanks Srini From: [email protected] [mailto:[email protected]] On Behalf Of Manoj K Nair Sent: Wednesday, May 22, 2019 1:33 AM To: Stephen Terrill <[email protected]>; 赵化冰 <[email protected]> Cc: [email protected] Subject: [Onap-arc] API GW Proposal Hi Stephen, Huabing, I just noted the following comments in the ArchComm MoM yesterday · ArchCom views that the APIGW functionally in MSB with the following notes: o .. o There was a discussino about ExtGW in MSB vs External APIs. External APIs exposes functional capabilities. ExtGW in MSB is communication connection. We have concern with the last comment. Our proposal for API GW is not limited to enable “communication connection”. I guess using API GW for just routing the request is not very efficient. We are proposing API GW functionality to be leveraged for the following use cases · Compose low level/object level API of the ONAP components behind API GW through a Façade and enable more manageable integration with external solutions. This in a way is expected to address the modularity requirements driven by Architecture team. · Host Business/High-Level/Standard APIs/Adaptation and transformation logic for Use Cases, App Developers with tools to hook business logic or policies if required. · Consistent Security/Policy enforcement for ONAP exposed/consumed APIs. Additionally ensure consistency of ONAP exposed APIs in terms of style, version, documentation. · RBAC enforcement for ONAP exposed/Consumed APIs · Support Tenancy management · ‘ONAP as a Service’ Enabler . · As a gateway for enabling transactions with cross domain solutions- with partner solutions, legacy solutions, with edge management solutions and enforce appropriate business policies We don’t think the above use cases are being addressed today. We are focusing on the above use cases to be enabled than focusing on enabling external (or NBI) communication channel for ONAP components. In our view Ext-API, Various adaptors (SOL005/SOL003/Multi-Cloud Adaptors) are doing some level of adaptation and bit more (level of composition with additional business logic). These redundant modules can offload majority of the transactional logic and chaining to well-known API GW solutions as there are already built in toolsets for incorporating that. The new proposal is not intended for or require any refactoring of existing projects, it just require adding a service in either common service or MSB for hiding the complexity of ONAP capability consumption. While we discuss the capabilities and technology choices with MSB team, we would also like to get clarity on the following open items which will help us to arrive at an appropriate technology choice. · Views from project teams and use case team on whether the use cases stated above are valid and enhancement of API GW is fine to address those ? · Is API GW, with additional seed code in future releases, expect to handle only the NBI calls via Ext-API or all the external calls – inbound/outbound (e.g. calls from OSS/BSS directed to Ext-API or all types/formats of APIs – SOL005/SOL003/Cloud specific, REST/non-REST etc or NBI + East/WEST API Calls) . Is the need currently to support only the NBI to Ext-API and selectively ignore API calls to ONAP components as required (for example SOL005 directly to SO instead of passing through API GW or Ext-API) ? · How project teams expect to develop the adaptors or Façade (API Composition logic – simplified or single API call exposed for multiple internal low level APIs) for various use cases/end user applications ? Within project boundary as separate microservice using project specific toolsets or as part of API GW or using common API GW microservice in different components? · Is there any need for additional toolsets and plugins to be developed in API GW for developing standard adaptors (e.g. SOL005/SOL003 etc) or Façade APIs or Security/Policy enablers? Does it required to be developed by the API GW functional owner or respective teams that require such API plugins/enablers? Are we open to put additional effort required for developing the feature debt jointly irrespective of the technology of choice or programming language of choice? Regards Manoj ________________________________ The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17192): https://lists.onap.org/g/onap-discuss/message/17192 Mute This Topic: https://lists.onap.org/mt/31720416/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
