Bookmark and Share
RSS

Recent Posts

I Never Want a World Without Middleware

December 3, 2018

For the last three weeks, I have been exploring the dimensions of IBM z14 hardware. As much as I could, I centered everything in those posts on some aspect of the hardware—speed of circuits, cache sizes, number of transistors, miles of wire—you get the idea. If you missed it, here are the two most important paragraphs in all three posts.
  1. With IBM z14, you have a central processor chip with L3 cache and a system control chip with L4 cache. This features 14nm SOI technology and 5.2GHz cycle speed in a water-cooled enterprise server. The central processor chip has 6.1B transistors with 14 miles of wire. The system control chip has 9.7B transistors with 13.5 miles of wire.
  2. There are up to 240 physical cores in a four-drawer shared-memory symmetric multiprocessing. There are 170 configurable customer CPUs, plus IO assist and firmware CPUs. The z14 also has micro-architectural and architectural enhancements for wide variety of workloads such as binary encodings of decimal numbers (BCD) for COBOL, garbage collection for Java and compression for databases, to name a few examples.
Those two paragraphs read like a description of a great symphony. It’s more like Beethoven’s Ninth Symphony than his “Eroica.” z14, like the Ninth, is a work reflecting the maturity of a lifetime and is still growing and driving technology change. The technology reflected in z14 didn’t just happen, IBM made it happen—they designed and implemented the platform that’s running critical workloads in enterprises today.

This week, I start again with a topic I find revitalizing: Middleware. I found this definition using Google: “software that acts as a bridge between an OS or database and applications, especially on a network.” This is correct to a point, but it’s not fully reflective of the breadth and depth of middleware today.

Middleware Is of Huge Importance in IT
Like the Milky Way Middleware is a subject of great importance. You may not know that because your job (and curiosity) has you busy supporting applications or installing products or something else in IT that doesn’t smash right into middleware. I worked with principal middleware like CICS and IMS and didn’t know them as middleware. It was only when I worked on a team that developed professional services for middleware products that I got a rounder picture of this category of software.

Roots of Middleware
When you research middleware, many sources inform you that middleware was developed in response to the needs of client/server (CS) applications. Initially, CS middleware was developed as a means to connect a large network of distributed computers by providing file transfer, remote printing, terminal flexibility and remote file access. With networking becoming a greater focus and providing increasing flexibility and functionality, the stage was set for other services that would support executing useful interactions between distributed and networked computers.

The Real History of Middleware
This explanation about the CS roots of middleware is factual, however. The historical roots of middleware are in centralized enterprise systems. This is where many of the middleware models were first realized. Consider the job entry subsystem (JES) and job control language (JCL) as middleware. Both JES and JCL are examples of how to improve the productivity of programmers and make good use of computing resources. Already well established over 40 years ago, JES and JCL are still in wide use today.

Centralized computers running a commercial OS started with support for batch workloads. “Batch” means to collect a bunch of work and put it through the system as a group. “Batching work” made for a more productive use of expensive computer resources. When JES was created, it became a standardized productivity interface to the OS and the resources it controlled. Prior to JES, many programmers were solving the same problem, how to get work into the system and handle job outputs, in different ways. This simply wasn’t a productive approach.

JES2, a specific JES implementation, handled inputs to the OS, called the base control program (BCP), and outputs to files or print. JES2 handled chores for the BCP, helping it to be productive and not inhibited by I/O concerns. JES2 was the engine and JCL the interface to nearly every programmer who needed to get work performed on a mainframe computer. Like other middleware today, JES and JCL provided a layer of abstraction to reduce complexity, and improved programmer productivity by providing a simple but powerful interface involving JOB, EXEC and DD statements.

Today, for every job that you submit, you need to tell z/OS where to find the appropriate input, how to process that input and what to do with the resulting output. You use JCL to convey this information to z/OS through a set of statements known as job control statements. JES and JCL have lasted for decades because they have been updated and enhanced frequently, as is the way that IBM keeps its technology vital while protecting the significant investments of thousands of its clients.

Next in the Series
Next week, I’ll continue with this exploration of the many dimensions of middleware. I’ll continue the discussion with the size of the market and the categories or taxonomy of middleware software.
    

Posted December 3, 2018| Permalink

comments powered by Disqus