2. What’s New!

  1. Service Mesh capabilities & how DM APIM works with Service Meshes

DMAPIM 3.X is built with micro gateway capabilities along with the ability to support custom gateway behavior. Each micro gateway has a subset of APIs to be managed by it. Despite the distribution, all external traffic will have only a single entry point. This is managed by the HTTP listener nodes, which maintains a service registry internally. The registry helps to route traffic to the right gateway instance.

Due to this distributed architecture, the DMAPIM 3.X gateway can be deployed on a set of containers, and managed using Kubernetes. Further more, Istio or similar service meshes can be used to control the flow of traffic. While this is not mandatory, the HTTP listener node can be replaced with a service mesh in cases where extreme scalability is needed. Note that this requires configuration & deployment architecture changes for the gateway.

  1. Modularization - Dev Portal usage with other providers

DMAPIM is built as a set of independent modules. While the design is to allow them to work with each other, they can easily be made to work with other components as all components communicate via APIs. As long as the other applications can use DMAPIM’s data model, they can integrate via the APIs. The data model itself is defined in a very generic manner. As a result, adapting this is fairly easy.

For any kind of data transformation needed to interact with DMAPIM, Coupler (another component) can be used to define the transformations or compose APIs and publish backend specific end points.

The core components of DMAPIM are:

  1. Publisher Portal - The Publisher Portal manages the API configurations, and allows users to package APIs as Packs and associate price plans with the APIs. The portal also allows management of users and groups. All functionalities are exposed as APIs. This allows other applications to easily integrate and use the capability. As part of one of out implementations, the Publisher and Developer portal were used in a headless mode to integrate with an existing UI, which leveraged the capabilities. During this integration the Publisher & Developer portal UIs were initially integrated with an existing backend to pull certain pieces of information like API documentation till the actual UI was built. This was then seamlessly switched to the new UI after 3 months of operation.

  2. Developer Portal – This is the API consumer facing part and is also called the store front. Again, as all functionality is available as APIs, the Developer portal can easily integrate with other applications. We have successfully trialed this with other competing applications like APIGEE by modelling the consumer paradigms on our existing models, and mapping the data from these products to our model. The data is then imported into DMAPIM and traffic is routed to the actual gateway running on the other product instances.

  3. Gateway – This is the core gateway which manages the traffic. If all configuration can be provided in the format that the gateway expects, it can run independent of the portals used.

  4. OAuth Server – This is by default a standalone OAuth server. Our gateway and portals consume this application’s APIs. It can easily be replaced with any other OAuth server.

  5. Coupler – This is a separate component meant for service composition. It can run independent of all other components and can be used as a service orchestration layer.

  6. Analytics Module - The analytics module reads data from the other components and gives users the ability to create charts/reports based on the input data. Any data can be fed to it and reported on. There is no dependency on the data source as these are configurable.


    DMAPIM 3.X

    Fig. 2.1 DMAPIM 3.X

Note

The features described in the Whats New! section are only available for versions 3.0 and above.