Skip to main content

IBMers Robert Jones and Andrew Smithson Explain Technical Aspects of API Enablement on IBM Z

Joseph Gulla discusses API enablement with IBMers Robert Jones and Andrew Smithson in this two-part series.

"IT Trendz" in white against a purple banner, white chat bubble in righthand corner, with dots connected by white lines against a blue background.

This is the second of a two-part series of articles on API enablement on IBM Z®. Last week, I discussed API enablement with Anthony Papageorgiou, an IBM senior inventor and offering manager for API Enablement on IBM Z. This week, I’m writing about my question and answer session with two individuals with an intimate knowledge of API enablement for IBM Z. Andrew Smithson is a software engineer and development technical lead at IBM Southampton in the United Kingdom. Robert Jones is a senior technical staff member focused on API enablement for IBM Z. Jones is the chief architect for IBM z/OS® Connect Enterprise Edition at IBM Hursley, Hampshire, United Kingdom.

Technical Discussion on APIs

In this section on the technical aspects of APIs, I asked Smithson and Jones how they would explain specific aspects of APIs:
Joseph Gulla (JG): The literature on API programming reads “quick and easy.” How is that possible? Is it because code is generated for you automatically? Or, is it that the development tools are so effective?
Andrew Smithson (AS): The tooling that we provide to build APIs for z/OS Connect Enterprise Edition is a big part of making API development “quick and easy.” From the start, the developer is guided through the steps required to build the structure of the API and then can wire together the composite parts in a visual way without having to learn a new language or write complex instructions. The ability to then install and test the API direct from the tooling facilitates rapid iterative testing ensuring that the developer can regularly check their progress without having to try and complete the entire API. 
JG: How is it achievable to use APIs without any changes to the underlying technology like CICS® or Db2®? Does this mean that the only element that’s created is the API program itself?
AS: The systems of record that we API enable already have good links for calling programs and getting data remotely, so that’s the first step to avoiding changes. The second is the technology we have in z/OS Connect Enterprise Edition for transforming between JSON and the binary structures expected by the target program. The combination of these two things provides the ability to change what would traditionally be a request/response application into something RESTful that looks like other RESTful APIs.
JG: REST and SOAP were created for the web environment. How is it that they apply to getting information from mainframe applications and databases?
Rob Jones (RJ): The internet boom drove rapid growth of B2B, accelerating the development and subsequent adoption of open standards. Patterns of best practice built upon open standards have proven equally attractive for integration with traditional mainframe applications and data. Further, they bring with them ever improving security characteristics and a natural approach that’s intuitive for today’s applications teams, rather than requiring highly specialist skills. The trick to getting this right is in empowering the mainframe asset experts to applying their expertise on a particular application or database, in order to create a consumable modern interface for new and future consumers.
JG: Since security on the mainframe is handled one way and security on the web is handled another, how does z/OS Connect Enterprise Edition bridge that divide?
RJ: z/OS Connect Enterprise Edition enables the use of various types of security credentials that are natural to the web and OpenAPI world, including TLS client certificates and JSON Web Tokens. Typically, there needs to be a relationship defined between those identities these credentials represent outside of z/OS and an identity that can be used in the mainframe security realm. Security administrators are able to define these relationships through standard security registries (such as SAF or LDAP), and z/OS Connect Enterprise Edition applies them for identification and authorization in every API invocation. 
JG: However you define hybrid environments, they’re common today. Private and public environments, cloud or otherwise, are used and increasingly used in conjunction with one another. How does that work with IBM’s API solutions? Do the API programs run outside the private CICS or IMS™ environment?
RJ: Using z/OS Connect Enterprise Edition for API solutions with mainframe applications allows API consumers to leverage mainframe applications or data. These consuming applications could be running on any platform within network range and equally could be other z/OS-based applications. The value proposition of an OpenAPI catalog is equally applicable to new intra-application calls within a z/OS system, as for integration with external platforms and applications. 
In many cases, applications that consume REST APIs don’t connect directly to a z/OS Connect Enterprise Edition server. An intermediate software component, such as an API gateway (e.g., IBM API Connect) is used where API management facilities such as rate limiting, chargeback and an enterprise-wide API catalog combine with multiple API providers. A network appliance (e.g., IBM DataPower Gateway) is used where common IP security characteristics and policies may be defined and enforced, as well as taking up load associated with communications processing such as routing and cryptography.

Next Post

Next week, I’ll share the first part of my coverage of the 2020 Enterprise Computing Community Conference. The virtual conference took place from June 7-9.
IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →