Changes coming with the API Mediation Layer V3
{Core} The API Mediation Layer, along with the broader Open Mainframe Project’s Zowe server side, is garnering greater interest and adoption. As Version 3 approaches, it is important to be aware of the upcoming changes and prepare accordingly. This article aims to provide insights into what to expect in the future and highlight the key value propositions introduced in Version 2.
Out with the old
The project originally consisted of three sub-projects with multiple components in the case of the API Mediation Layer.
- API Mediation Layer
- Datasets APIs
- Jobs APIs
API Mediation Layer Components
- API Gateway Service
- Discovery Service
- API Catalog Service
- Caching Service
- Metrics Service (Technical Preview)
Two projects, the Datasets API and Jobs API, will be leaving the Zowe projects and becoming archived. These APIs were deprecated during the V2 Zowe, as the functionality they provided has been superseded by the z/OSMF itself. In the V2, these components are already disabled by default, and in the V3, they will be fully archived. Maintenance support will only continue for the V2 version.
Two years ago, we introduced the Metrics service as a Technical Preview component, which displayed the current traffic flowing through the API Gateway. However, this component did not gain traction and was not widely adopted. As a result, we have decided to archive it and explore a different approach, which I will explain further in the “In with the new” section.
Netflix Zuul-based API Gateway is part of Version 2. However, the support for Zuul and Ribbon technologies, which were used for implementing the API Gateway functionality, has ended. Even the Spring ecosystem has moved away from them. As a result, we have made the decision to leave them behind and introduce a new API Gateway built on top of the Spring Cloud Gateway technology.
The Zowe as of now supports lots of versions of z/OSMF including some of the versions not supported by IBM anymore. As such with V3 we intend to limit the support for the following z/OSMF versions
- V2R4 with PH12143 APAR applied
- V2R5
- V3R1 once it’s out and we are able to validate
The support for Java 8 and Java 11 will end with the release of Zowe V3. We understand the importance of staying on supported technologies, which is why we are upgrading the Zowe API Mediation Layer to run and build on Java 17. As part of this upgrade, we will also be updating Spring Boot to version 3 and Spring to version 6. We will soon be publishing the preview of the Zowe server side, along with the Spring Enabler that is built upon these updated versions. We are aware that this means that the prerequisite for Zowe V3 is to have z/OS 2.5 installed.
What about Version 2 and the End of Support for the Spring 5.x, Spring Boot 2.x? Spring Boot 2.x and Spring 5.x Community Support ends at the end of the year 2023, full two and half year before the Zowe Version 2 is removed from maintenance. In case there is a new vulnerability found within the Spring dependencies, we will evaluate the vulnerability and see whether it’s exploitable. In case it is we will either be able to mitigate the risk by changing the code on our side or in worst case scenario will need to prepare updated Spring version used within the Zowe with the fix to the specific vulnerability.
In with the new
The main change that is coming directly with Version 3 release is the addition of the new API Gateway built on top of Spring Cloud Gateway instead of Netflix Zuul. One of the nice functionality that wasn’t available before but is available now is the possibility to configure the rate limiting for the specific APIs onboarded to the API Gateway.
We would like our users, extenders, and contributors to jump in the driver’s seat, or at least a little backseat driving and join in on the discussions.
- What capabilities would you like us to add?
- What processes could be better when using Zowe API Mediation Layer?
- What would make extending Zowe API Mediation Layer easier?
Feel free to join the Slack channel discussion or initiate your own discussion in our Github repository. We highly value your input on the proposed changes. We eagerly await your thoughts and ideas, as we believe that the collective collaboration of great minds will lead to something truly exciting for the community.
Roadmap items for Version 3
- Open Telemetry Support: The API Mediation Layer will generate Open Telemetry compliant information regarding the usage of the APIs, as well as its own internal processes. This simplifies the observation of the entire z/OS ecosystem.
- Improved Debugging Experience: We aim to enhance logging by focusing on messages that are specifically relevant to the z/OS System Programmer. These messages will be actionable and provide additional information for debugging purposes in the event of any issues with the API Mediation Layer.
- Standalone API Catalog showcasing the Extender APIs: The Version 2 release stream includes the API Catalog, which offers a standalone mode that we would like to use to showcase the APIs of the API ML extenders.
- Zowe Server Side SDK Update: The Zowe server-side SDK has been neglected for some time and is currently not in a usable state. However, we are committed to making it an effective part of the ecosystem for building new API ML Conformant services. Additionally, we aim to utilize it for the API Mediation Layer components to simplify maintenance.
What was delivered within the Version 2
As the version 3 is nearing it’s also time to look back and point out what was delivered during the Version 2 release stream of Zowe API Mediation Layer. Most of the work was done around supporting further methods of authentication on the northbound side.
- Client certificates — It’s possible to use client certificate to call any endpoint onboarded to API Mediation Layer instead of having to exchange the certificate first for the JWT token.
- Personal Access Tokens — The new type of the tokens. Longer lived but scoped to specific subset of services. Learn more in Personal Access Tokens for the Zowe API Mediation Layer | by Boris Petkov | Zowe | Medium
- OIDC — Zowe API Mediation Layer can act as resource server within the OIDC scheme and as such it can validate the OIDC token provided and exchange it for different method of authentication for the southbound services.
In addition to that, we have made significant investments in developer-focused improvements for the API Catalog. These enhancements include visual upgrades in version 2. 0 and ongoing efforts to provide a more comprehensive developer portal experience with the catalog running in standalone mode. One crucial aspect of this effort was the addition of code snippets, which can be directly used to enhance functionality. To learn more about the code snippets and how they enhance the API consumer experience, you can read the article “Zowe Enhances the API Consumer Experience with Code Snippets” by Andrea Tabone on Medium.
Last but not least, we delivered the multi-tenancy support feature, which enables users to set up a central gateway for clusters of sysplexes. Each sysplex represents a different customer, allowing for proper routing and authentication on a per sysplex basis. This feature also provides a centralized access point for the entire ecosystem.
Learn More
If you enjoyed this blog, check out more Zowe blogs here. Or, ask a question and join the conversation on the Open Mainframe Project Slack Channel #zowe-api, as well as #zowe-help, #zowe-feedback, #zowe-explorer, #zowe-cli, or #zowe-onboarding.
If this is your first time using the Open Mainframe Slack Channel register here.
