What’s new with WSO2 APIM 3.2.0 Part-1
WSO2 API Manager, a leading platform for creating, managing, consuming, and monitoring APIs. Recently named the leader THE FORRESTER WAVE™: API MANAGEMENT SOLUTIONS, Q3 2020.
With the ever-growing demand around API ecosystems. WSO2 APIM proven SOA best practices to solve a wide range of API management challenges such as API provisioning, API governance, API security, and API monitoring.
It combines some of the most powerful and mature components of the WSO2’s state-of-the-art Carbon platform to deliver a smooth and end-to-end API management experience while catering to both API publisher and API consumer requirements.
In this section, I’ll be focusing on one of the major but most important architecture revamp compare to its successor which is APIM 3.1.0. So, let's deep dive and analyze key architectural change.
▹ In-Memory subscription validation
The In-Memory subscription validation provides support to remove runtime dependencies between the Gateway and the Key Manager node and validates the request by accessing the metadata in the In-Memory data store. This is a major improvement for APIM 3.2.0. As a result, the WSO2 API Manager can serve the request even in a situation where the database is inaccessible.
How APIM 3.1.0 and before handled Key Manager interactions?
The challenges had with the previous releases was;
- Gateway scaling limitation; Yes, there were potential practice issues, there was the problem of tight coupling of the DB at Key Manager, there was a problem when GW communicates with the Kay manager direct and if DB fails, the whole operation would be in jeopardy (at least for a short period of time, but still this is significant for critical operations).
- Also, to reduce DB operations interactions, there were multiple caching layers built on top of Key manager components because of deployment expansions.
- Scalability becomes issues with Gateway expansion with the number of Key manager operations the Key manager layer had to deal with an ever-growing load (note: with DB bottleneck due to huge read writes)
- Gateway’s dependency with the key manager; Whenever the key manager component released, the underneath admin communication for a different type of Key manager activities were depended on the Key Manager component, again, this was another major factor faced with the Key Manager scalability
How APIM 3.2.0 revamp its architecture?
APIM 3.2.0 and beyond
- With the new implementation, the gateway is responsible for validating the token or validating the scope in memory.
- The in-memory maps keep the contexts of the subscriptions, applications, APIs, Scope, Policies. When requests come the validation happens using the in-memory maps. These maps are basically in-memory hash maps, with this way, it reduces the connection between the key manager
- The direct link between the gateways and the key manager eliminated with the hub and spoke model or we call it event-driven architecture. The EventHub. a.k.a TrafficManager plays the key role in establishing notification between other critical nodes loosely coupled manner
- Yes, this architecture has proven, how it would boost the overall platform performance, especially when comes to key validation, scope validation
How event-driven notification improved the key subscription architecture?
As depicted in the above diagram, the gateway has an in-memory, which keeping track of subscription, application, scope, policies, key mapping changes. The API developer or API Publisher pushes the changes to event notification such as the subscription, scope, policy changes. Once the traffic manager receives the relevant information, all the gateways that are being subscribed to the traffic manager would receive event notifications to update their in-memory cache to the context.
Scalability, with the event base notification architecture, I would say, this is the most important aspect. As depicted in the above diagram, APIM 3.2.0 beyond offers the deployment to be scalable, it's just a matter of starting new gateway nodes, where each Gateway node itself having a Restful API invocation to the traffic manager to subscribe to it self. This is happening whenever the Gateway node re-initialization with a durable subscription mode.
If anyone would like to see how this has improved implemented please refer
- APP/Subscription/API Creation Gateway Event listener: GatewayJMSMessageListener.java
Key points
- Overall, as depicted the APIM 3.2.0 and beyond offers a loose coupled event-driven architecture that will address most of the issues that developers noticed during APIM 3.1.0 or before and around Key Manager direct invocation via Gateway nodes
- You'll notice right now, APIM 3.2.0 and beyond the Traffic manager should communicate with the AM_DB, the reason as stated, whenever changes notified traffic manager will query (read-only mode) the AM DB and provides a relevant update.
If you would like to try WSO2 APIM please click here
Will share other improvements with the upcoming stories..
