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.
This is the context in which Eradani Connect lives. Our clients asked us to create a middleware layer around the IBM i that would make it much easier for their developers to call into existing RPG/COBOL/CL functions from open source, Node.js, .NET or other technologies and to call out from RPG/COBOL/CL to other types of software. They wanted to continue enhancing their IBM i applications in RPG and COBOL (after all, those languages are really good for that), but use new open source technology for API enablement, new user interfaces and other innovations so prevalent around IT. Building and accessing web services is best done in JavaScript because that what is was built for and it is the most popular language in the world for that purpose. Even more than Java, JavaScript is being adopted for both server-side and client-side application development. Its functions have gone way beyond the capabilities first dreamed of by Brendan Eich, Marc Andreesen and their colleagues at Netscape when they initially started designing the technology.
There are a lot of things that JavaScript offers for IBM i users that give them good reasons to want to start leveraging the right side of Steve Will’s chart above to enhance the left side. Enhanced API security is a great example. If you are building your connections in RPG, you are going to do yourself something that literally hundreds of thousands of open source programmers are already working on. The OAuth, JWT, TLS and Open API code is being vetted by the best security people in the world and is being used by millions or tens of millions or even billions of people around the world. With these technologies, IBM i users no longer need to rely on “security through obscurity” and the hope that nobody is actually going to try to find them. With the Open Source enhancements the IBM lab has made, you can now take advantage of the latest security innovations. If you’re building services, if you’re exposing things via APIs, there are billions of bots that all day and night look for connections and try to see if they can get in. In that world, the last thing you want to do is try to write the security code yourself. You really want to make sure that you have the best security, and that means open source with millions of eyes on it. “Security through transparency,” we suppose.
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.
Instead, we built in support for JSON Web tokens for the latest in encrypted secure token communications between the IBM i and the outside world. So you’re always getting the latest security. And because we’re open source and we support JavaScript, you can plug in any of the nearly five hundred different authentication methodologies (like OAuth2) into Eradani Connect to secure access to IBM i applications and data. If you have a central or third party authentication server, it is the only thing that receives a user name and password. It then passes an encrypted token to the requesting user and to the IBM i. From then on, all authentication is done using the tokens, not the actual user name and password. And tokens can be set to expire after a little bit of time. This approach also means that you don’t have to give any native IBM i access to the Web applications, ever.
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!
RELATED STORIES
In The API World, Nobody Knows You Are An IBM i
In Search Of Next Gen IBM i Apps
Modernization Trumps Migration for IBM i and Mainframe, IDC Says
