I'm glad that my reply has posted some discussion while I was absent on vacation. Apart from anything else this has highlighted a lack of clarity in what I said regarding the ODA component approach (apologies for that), so let me try again.
Part of the ODA work is defining functional components (such as Product Catalog, Party Management, and many more), see the recently draft component list
here (it's in team approved status, I guess waiting for member approval). So what I meant to say was: it doesn't make sense in general (to me at any rate) that more than one functional ODA component definition should expose the same API. Violating this guide would mean that multiple different systems are somehow "owning" the same data item. It could be that we will discover specific deviations from this guideline that would need to be discussed and justified.
Vance, Rakshit, and others correctly pointed out that there can potentially be multiple instances of the
same ODA component in a deployment,
coming from different suppliers (vendors), e.g. multiple federated product catalogs all exposing operations from the same TMF620 API. And then we have the challenge of how to route consumer calls to the "correct" implementation.
Vance also makes a very good point about the API granularity - the API is "just" a document (swagger file, user guide). What is important for implementations is which
operations are exposed, and indeed the ODA component spec is going into that level of detail, see the first pilot guide published
here (for product catalog).
Hope this is now clearer.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: Jun 07, 2021 14:49
From: Greg Herringer
Subject: Impact of microservices in exposing Open APIs
I wonder if these topics require an ODA IG Guide - along with some work on evolving the API specs too. Perhaps a topic to be added to the IG Guide backlog.
------------------------------
Greg Herringer
IBM Corporation
Original Message:
Sent: Jun 07, 2021 05:22
From: Dave Milham
Subject: Impact of microservices in exposing Open APIs
This brings out several important points:
- Use of terms API and component need to be qualified by whether one is talking about the concept, a specification, an implementation or a deployed instance.
- Use of virtualisation makes instance coupling a run time issue decision than a design decision
- Arbitrary boundaries to current API specifications and the need for service based description of API functions
------------------------------
Dave Milham
TM Forum, Chief Architect
Original Message:
Sent: Jun 04, 2021 04:43
From: Vance Shipley
Subject: Impact of microservices in exposing Open APIs
On Jun 03, 2021 11:27 @Jonathan Goldberg wrote:
> In the ODA project, they are defining components (which may or may not be microservices), where to my best understanding (subject to correction by ODA experts) an API cannot be exposed by more than one component, so there is no ambiguity.
That statement leaves room for doubt.
Is it that a specific API (i.e. TMF620) may only be produced by a single ODA Component in an ODA System? No, I don't think that works. In both BOS Catalyst projects we demonstrated Product Catalog federation between ODA Components which produce TMF620. In BOS I we had a hierarchy and described various delegation patterns.
Is it that one instance of an API may be provided by at most one ODA Component? What is an instance? That might seem obvious if you consider that an IP Address:Port is bound to a socket with a listener process on a server. However the ODA Decoupling and Integration functional block accomplishes API exposure so that level of detail is obfuscated entirely. To apply an API exposure rule which demands that /productCatalogManagement/productSpecification/ MUST be routed to the same ODA Component as /productCatalogManagement/productOffering/ and /productCatalogManagement/catalog/ seems unnecessary, arbitrary and indeed harmful. How would this even be enforced? For what purpose?
This issue has triggered me because I've been highlighting of late just how arbitrary TMFXXX granularity is. TMF620, for example, should be decomposed into a list of services/capabilities it provides and those should exist in a registry, available for discovery, and that forms a much more appropriate level of granularity for this type of discussion.
------------------------------
Vance Shipley
SigScale
Original Message:
Sent: Jun 03, 2021 11:27
From: Jonathan Goldberg
Subject: Impact of microservices in exposing Open APIs
Hi Jay
From Open API perspective, there is no prescription for how an API is implemented. At least in principle you could have a huge monolith, written in COBOL, that could implement all (or many) of the Open APIs. The consumer of an API needs a REST endpoint that will be directed (presumably by an API gateway) to the actual implementation, and so should be completely unaware of which software is implementing the API. It is even possible that (e.g. in a canary deployment) some calls will go to one implementation while other calls will go to a different implementation.
Perhaps you can give a concrete business example of what is bothering you.
In the ODA project, they are defining components (which may or may not be microservices), where to my best understanding (subject to correction by ODA experts) an API cannot be exposed by more than one component, so there is no ambiguity.
Hope it helps.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Jun 03, 2021 00:16
From: Jay Dela Cruz
Subject: Impact of microservices in exposing Open APIs
Hello.
What is TM Forum's view on - when one application (i.e. Application X) consumes a TMF Open API exposed by another application (i.e. Application Y) that is microservices based, should the consuming application know which particular microservice is serving the call?
The assumption here is that Application Y has different microservices to serve one TMF Open API exposed.
Thanks.
------------------------------
Jay Dela Cruz
Globe Telecom Inc.
------------------------------