Calling All IBM i Platforms. . .
August 16, 2021 Daniel Magid
In a microservices world, all elements of what used to be monolithic application programs are now chunks of code linked to each other using any number of application programming interfaces, or APIs. Those APIs can be based on a remote procedure call, or RPC, architecture, which is a kind of generic distributed client/server approach, or the REST – short for representational state transfer – architecture favored by parts of the commercial Web software stack that has dramatically grown in popularity in the past two decades. Either way – and in fact, there are more than two ways – APIs are how program elements, different applications made up of program elements, and end user interfaces all talk to each other in a modern software environment.
IBM i shops have to live in two worlds, and that is a good thing, not a bad thing. Valuable core legacy applications and databases have their means of representing business logic (RPG, Java, COBOL, and SQL are the main languages) and organizing the data that feeds them (usually in the Db2 for i database integrated into the IBM i platforms). Newer applications, which may run on IBM i or on other platforms like Linux or Windows Server, can be based on snippets of code in a mix of modern applications, stitched together by APIs and accessing data using different methods.
Steve Will, chief IBM i architect at Big Blue, recently talked about these two different sides of the programming house at IBM i shops, which was covered here at The Four Hundred. According to Steve, the best strategy for IBM i application development is to blend these two approaches rather than coming down firmly and solely on one side.
This balanced approach, which we at Eradani wholeheartedly support, is key. Application development is much faster when you use the tools for what they were meant for, rather than to try to make the stuff on the left side of the chart do what the stuff on the right side of the chart is good at – or vice versa. For example, by exposing your existing IBM i functions via APIs, you get all the value of your proven code yet you can hire a developer who knows the latest technology to rapidly write new functions for you using existing open source modules and new languages, rather than attempting to write something from scratch in COBOL or RPG.
In essence, what is needed for modern applications and for the middleware layer linking into legacy applications is a kind of API firewall, which can provide IBM i shops not only with connectivity to legacy applications, but also a level of comfort that the security is being handled, that there is this layer protecting their IBM i applications and data. You can use the latest in encrypted JSON Web Tokens, and OAuth security – without having to maintain the code yourself. Consequently, you’re not relying on some proprietary way of doing security. You’re using the standard way of doing security in the open source world that is being used by the largest organizations around the globe. You don’t have to try create that yourself or buy a proprietary system from one vendor that has only a few developers working on it. We are using the same token-based, open source tools that the entire Web is built on.
Here is a little bit more finer grained detail in how you call into an IBM i system from the outside:
And here is how you reach from the IBM i to the outside world:
Eradani starts with the same open source Node.js that Amazon, Facebook, and all the other hyperscalers and cloud builders use, and it links into OpenSSL, which is what it uses for cipher suites, encryption, SSL, and other security features.
Importantly, the Node.js modules include the latest cipher suites. One of the issues in the IBM i world is that IBM i shops don’t tend to install new releases when they become available. They wait and wait. But if you need to stay on older IBM i releases and if you are going to communicate via Web services, there’s a handshake that goes on where the cipher suites have to match. And if you don’t have the latest ciphers, you may not be able to connect at all and if you can, you are introducing a security vulnerability by using an older version. With an API “firewall” like Eradani Connect, it doesn’t really matter if you’re behind a little on IBM i releases because you are still getting the latest version of the ciphers in that Web connection layer.
With Eradani Connect, if you install it on the IBM i platform itself, we need IBM i 7.2 or later because we need the open source libraries that IBM delivers. Alternatively, you can install Eradani Connect on a Windows Server or Linux machine that talks to the IBM i, and if you do that, then your IBM i platform can be back to the 7.1 release. Most of our customers run it natively and are at least on 7.2.
If you are going to use these open source modules, one of the great advantages is that they are being updated constantly, especially for security reasons. And so you want to make sure that you’ve allowed for downloading those patches to your system. And that’s what Yum and RPM and all of those modules that IBM is providing do for you –they are constantly going out there and pulling down the latest security patches. If you look at a lot of the hacks that are happening, it is because somebody has a known vulnerability and they didn’t patch their machine. With our approach, you keep that stuff up to date all the time. If you are relying on your operating system update, you could be months or years behind and have vulnerabilities that everybody in the world knows about on your system. This gets right back to the idea of using the right tool for the job.
One last thing on security. We support but do not recommend basic authentication. A lot of IBM i users are using it and it introduces some significant security vulnerabilities. With Basic Authentication, you send the user ID and credentials with every API call. These are generally actual IBM i credentials, the things that provide native access to the system, and then those credentials are stored in the browser so the user doesn’t have to keep resigning on. Every time you send the credentials across the wire, there is a danger they will be discovered. And if you are storing the credentials in the browser, they can be discovered there as well. Because of this, almost everyone is moving to encrypted token based security. In fact, almost all the major Web providers are deprecating support for basic authentication because it is such a security problem.
So, the best way to leverage all of your investment in your existing applications while taking advantage of the latest technology is to use the “blended” application development approach and use the best tool for the job!