Layers of i

It's come to my attention recently that many people within the IBM i community (and outside it as well) would benefit from a bit of an explanation of the structure of the operating system we all know and love. Now, I won't write a book on the subject, and I know most people don't need to know the architectural details, but I think there are some key points to be made about the purpose and value of the architecture.

For the purposes of this blog entry, I'll describe the layers of IBM i as these:

• Integrated Middleware
• "The" Operating System
• Technology Independent Machine Interface
• Licensed Internal Code
• Hypervisor

Integrated Middleware

One of the key values you get from IBM i is that the operating system "contains" software that you'd need to buy and/or install separately on other platforms. The type of software we integrate is typically "middleware" - that is, software that enables specific kinds of applications above and beyond what the base operating system can. A few examples of middleware that are integrated into IBM i are the Apache Web server, the Tivoli Directory Server, and the Java (JVM) environments critical to many newer applications. Not only are these included with IBM i, but they are integrated - they're designed, built and tested to work together and work within the security and work management models of the operating system. A key piece of middleware that's typically added on to other operating systems (at an additional price) is the database, so I must mention it here. However, DB2 is so integral to IBM i that I will also discuss it in the layers that follow. We also work to integrate optional middleware products like WebSphere Application Server Express, Domino and Zend PHP to make it easy to support applications based on these technologies.

"The" Operating System

I'm in a bit of a difficult position here. In order to fully describe this layer, you need to know a bit about the next couple of layers, as well. Let me start the description this way: Every operating system has a set of common characteristics, and this layer of IBM i provides those. What are these characteristics? Perhaps most clearly, the operating system must provide interfaces that allow other software to be developed and used. IBM i has a large library of application programming interfaces (APIs) that represent "the operating system" or more generally "the machine" from the point of view of the applications that sit on it. IBM i also has ways to install, start and stop these applications, and so on. And, of course, the IBM i diagnostic tools and performance tools also have their home here, along with more capabilities than I have space to mention.

As new programming capabilities emerge, an operating system must be updated to include those. Over time, of course, IBM i and its predecessors have added interfaces to support TCP/IP, standard file systems, Java, Web programming and much more. Once upon a time, this layer was known as "XPF" and while some people still refer to it that way, it now contains so much more than the original XPF that it deserves a better, bigger name. Maybe I'll get Craig to come up with one. (OK, OK, we know. No more renaming.)

DB2 for i has its primary interfaces at this level. The DB2 APIs don't sit above the other operating system APIs, as is true with other operating systems, but right alongside them. And, like the rest of the APIs, they rely on the next two layers for their complete implementation.

Technology Independent Machine Interface (TIMI)

This is easy and hard to describe at the same time. The easy description of TIMI is that it's a contract with the programs above it. TIMI provides interfaces that provide specific functions, no matter what sort of hardware or firmware changes occur below them. How this happens is somewhat harder, and probably deserves its own blog entry sometime in the future. Suffice it to say that programs written to supported TIMI interfaces and compiled (properly) 20 years ago on OS/400 (and even S/38) can still run on IBM i because we have the TIMI architecture. This provides a level of stability and compatibility that's highly unusual, if not unique, in the industry. It protects investments made in software that runs businesses for decades, not months, and allows technology changes without disruption.

Again, DB2 for i must be mentioned here, because part of the TIMI architecture are database operations that remain constant in their interfaces, but can have significant changes in the lower-level implementation - to take advantage of new hardware or to implement improved relational database algorithms - without causing changes to the applications which use the database. (Well, they likely perform better, but there are no functional changes.)

Licensed Internal Code (LIC)

Let's be clear here: IBM i isn't IBM i without the LIC. And only IBM i uses the LIC. What does it do? It completes many of the functions exposed in the APIs of "The Operating System," while also accommodating and exploiting new hardware and firmware capabilities. Here's where the storage management occurs that I wrote about in my previous blog entry. Here, in LIC, is the incorruptible basis of the security and integrity model for IBM i. Here, we implement timers, queues, storage used for system and user programs, cryptographic algorithms, networking protocols and, yes, the relational database in which your business data is stored. 

Hypervisor

Back in 1999, just before AS/400 became iSeries, we introduced the concept of "partitioning" to our customer set. To make it happen, we created the Hypervisor, which essentially allows each operating system stack to operate as if it had control of an entire system, unaware that other operating system stacks are also active on the same underlying hardware. These days, the same Power Hypervisor is shared across all of Power Systems, with many of the original architects and developers still working on that evolving version. The base Power Hypervisor is provided with the Power System hardware and supports IBM i, as well as AIX and Linux. It supports whole core partitions. PowerVM adds advanced virtualization capabilities to the base Power Hypervisor including micro-partitioning (partitions using less than one core), automatic processor and memory resource movement between partitions, and I/O virtualization through VIOS.

In summary, the robust IBM i operating system is flexible and long-lived largely due to this layered architecture. When we talk about IBM i, we're talking about all of these layers in combination. I hope this brief introduction helps you understand the value that comes to you when you run IBM i, and why the IBM i development team continues to work hard to bring you this great integrated operating system.