The IBM i is still the best business-logic server, but middleware makes it accessible to everyone.

Welcome back to my new article series, “Practical Middleware.” The inaugural article was a bit abbreviated, but we’re going to do a much deeper dive here.

My Infrastructure

As I noted last time, I think we can agree that the IBM i is the best business-rules processing platform available, and I want to use these articles help you build an ecosystem around your business rules. I’ve found that anything you need to do can be done by using some combination of Linux, Tomcat, IBM i (RPG and DB2), and Node.js. That’s my version of the ubiquitous LAMP stack: Linux, Apache, MySQL, and PHP (or Python or Perl). So what does my infrastructure look like?

Figure 1: Tomcat and Node.js can connect your IBM i server to anything.

My environment isn’t a traditional stack with a specific role for each layer. That’s because while the LAMP stack was geared specifically for web applications, my stack is designed to be multi-purpose, meeting any connectivity needs. Yes, it still supports user access via browser. For example, Tomcat can act as a fully functioning web server without any additional front end. You can use any of a number of frameworks, such as Spring, to build traditional web applications. Or you can use something like Pug (formerly known as Jade) and Express to quickly create powerful applications.

You may have noted that I don’t include Apache in my architecture. While Apache provided a number of benefits in the early days of Tomcat, in my opinion the primary reason to use Apache today is to provide load balancing. And even there, NGINX may be simpler and provide better performance. Apache really is the Cadillac of web serving, but NGINX may be more of a Maserati. Click here for a quick overview of the two.

Anyway, as I mentioned, my stack is more a full-function business-logic server than a dedicated web-application server. As noted, Tomcat can be used to deploy traditional web applications. The potential drawback is that you have to know Java to develop your applications, but I consider Java to be an essential part of a programmer’s toolkit. I believe that skills learned developing statically typed Java applications provide a fundamental understanding of object-oriented architectures. The discipline gained helps you write much more efficient and maintainable code in the dynamically typed world of JavaScript, which is the underlying language of the other side of my stack, Node.js (or simply Node).

Node and its surrounding ecosystem provide a very powerful server-side programming environment. It’s incredibly easy to create a web server: I built a proxy server for my Tomcat instance using 10 lines of code. Why would I want to do that? Well, this allows me to build and test my Tomcat applications using the standard Tomcat port without worrying about things like HTTPS certificates and the like. Then when I want to deploy, I can put a secure front end on it with a simple Node proxy. These are some of the things we’ll be exploring as we move forward.

So, if you look again at Figure 1, there are any number of potential paths. The traditional path of IBM i to Tomcat to web user is certainly available, shown as option A. Another possibility is IBM i to Node to EDI cloud services, shown as option B. Or as option C depicts, you could use a vanilla Tomcat instance to talk to a Node server, which in turn talks to a REST service. In this last case, it’s very easy to use Node as a front end to parse out REST requests over a secure HTTP connection and route them to one or more different Tomcat servers, which in turn access data on the IBM i through program calls.

So Where Does All This Wonderful Middleware Run?

That’s a really important question. I know people running both Tomcat and Node on the IBM i, so theoretically you can do everything there. I have nothing against that approach, and for many years I championed running everything on the midrange platform. You can also run the middleware on Windows; both Tomcat and Node run quite well under Windows. However, as time has gone on, I’ve found that Linux is an excellent middleware platform. It’s easy to install (and just as importantly, uninstall) software, with lots of preconfigured packages available. I find the online Linux tutorials to be more complete and plentiful, and I rely on those a lot. But there’s a catch: I don’t run Linux on my workstation; I run Windows. I’m not going to spin up a completely separate piece of hardware just to run Linux, and until recently that has precluded me from using Linux in my development stack. Yes, you can run a virtual machine. Oracle’s VirtualBox is free and works quite well, but it’s an extra installation process and one more hoop that can make things too difficult. Instead, I found something much better, at least for development (we’ll discuss deployment another day). That magic piece of software is the Windows Subsystem for Linux, or WSL. WSL, and particularly WSL2, provides a very seamless and smooth interface with Windows. In fact, with WSL2 you can run graphical Linux applications right on your Windows desktop.

What About Windows?

My stack can run on Windows. In fact, when I do Node development I like to do it on Windows using either the free Microsoft Visual Studio Code or the slightly pricey but very robust WebStorm IDE from JetBrains. If your organization already has Windows servers as part of its infrastructure, you can deploy everything we’ll be building to those servers. My biggest problem with Windows is that I find it difficult to upgrade components such as Tomcat smoothly. I can never seem to cleanly remove an old version of something, and I end up with registry remnants that cause problems for the next version. With WSL, I can have multiple Linux configurations on my development machine and the performance is solid.

Next Steps

It’s not all rainbows and lollipops. As this series progresses, I’ll take you through each of the components and list the pros and cons and also the fine design points you’ll need to consider as you plan your architecture both for development and deployment. But for now, if you’re at all interested in using Linux, I suggest that you install WSL and start to play with it. Try to install Linux from the Microsoft store. I recommend Ubuntu 22.04; it’s the latest LTS (Long Term Support) release of the very popular and stable Ubuntu platform. Start to read up on Node and Express and Pug. Install Visual Studio Code if you haven’t already done so. All of these are free steps. Unfortunately, WebStorm is not free, and in fact it’s a subscription model. At some point I’ll compare Code to WebStorm so you can see if it’s worth ponying up the yearly fee.

In the next installment, I’ll walk you through one of the simplest of the deployments: a Pug screen that allows you to maintain a file on the IBM i.