MAINFRAME > Tips & Techniques > Application Development

Middleware’s Roots Are in Enterprise Computing

Editor’s note: This is the first of three articles on middleware. The term was first used in the late 1980s to describe some networking software and in the ’90s to label software used to help distributed systems work together.

Today, IT software is like a vast body of water. IT middleware is now one of the swiftly moving currents in this sea of software. It was created out of need, decades ago, and is still growing at a strong rate. According to Gartner, the worldwide application infrastructure and middleware software market totaled $19.3 billion in revenue in 2011, a 9.9 percent increase from 2010.

You might ask, “What, exactly, is middleware?” Some provides a functional layer between an OS and application. In IT architecture, the middleware model is a foundational construct—a way to divide and conquer the chores of software development. Not all software that embraces the “in the middle” model is labeled middleware. This variability is just the way things are in IT. Figure 1 illustrates the role of middleware in this model.

Today, many commercial products fall into this middle ground. Examples include enterprise transaction processing environments and databases, such as CICS, IMS, WebSphere Application Server and DB2. This definition of middleware or some of the specific examples given might not be recognized by everyone. For example, there are differences of opinion about whether CICS is middleware because of its role as a transaction server. However, significant portions of the CICS certainly fit the middleware model of being a functional layer “in the middle.”

The Business Case

Middleware is a cost-benefit tradeoff that enables application programmers to work in a given environment, at a higher level, by shielding them from many complexities of the underlying hardware and OS software. For example, without the ability to share data between different systems using messaging middleware, an application programmer would need to spend time and resources building their own software scheme for achieving this goal. Multiply one programmer’s efforts by the number of application programmers who need this function and you rapidly see the business case for messaging middleware.

Typically, application programmers have business IT challenges as their focus. However, their applications run in a computing environment managed by an OS. Their main focus on the business problem and the complexity of most operating environments creates an opportunity for a go-between that can simplify application development.

Middleware doesn’t eliminate complexity entirely but, on the whole, it reduces the difficulty of many of the development chores faced by programmers. This is shown in Figure 2.

The First Middleware

The roots of middleware are in centralized enterprise systems. This is where many of the middleware models were first realized. Some middleware has the Job Entry Subsystem (JES) and Job Control Language (JCL) as its solution. Each offers examples of how to improve the productivity of programmers and make good use of computing resources. Already well established 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 in different ways. This simply wasn’t a productive solution.

JES2, a specific JES implementation, handled inputs to the OS, called the Base Control Program (BCP), and outputs to files or print. Figure 3 shows the relationship between JES and other system components. JES2 is clearly in the middle handling chores for the BCP, helping it to be productive and not inhibited by I/O concerns.

JES2 is the engine and JCL is the interface to nearly every programmer who needs to get work performed by the computer. Like middleware of today, it 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.

Real-Time Roots

As JES and JCL are the middleware model for batch processing, CICS and IMS provide the real-time or interactive middleware models. By real time, I mean the kind of transactions that take place at your bank or credit union. Large centralized computers running a transaction processing (TP) monitor handle most bank transactions. Just as JES was specialized for batch work, TP monitors like CICS and IMS, are specialized for on-line transactions. They offered programmer-productivity models that evolved quickly in the industry, providing an environment for software and service partners to build upon.

CICS and IMS have built-in capabilities that are building blocks of functions provided by middleware that came later to support client-server systems. For example, CICS has support for program link and transfer as well as the ability to pass data between programs that utilize common storage constructs. The ability to link and transfer between programs is important as applications are designed and built in units that are often implemented by different programmers in the same team. IMS has similar program-to-program support and mechanisms, like a special scratch pad area segment in the input/output message to keep context information so the dialog with the person at a terminal can be simulated. The notion of a conversation or pseudo-conversation is important in CICS and IMS real-time programming as they focus on the careful use of computer resources in high-transaction environments.

Support for program modularity is just the beginning of what they provide for the application programmer. Both CICS and IMS have different implementations of database and file support so programmers can store data efficiently, using the latest access methods as well as relational and hierarchical databases. Both have useful ways to access and interact with display devices for transaction input and output. They also have support for programmatic queues that can be used for intra-program communication or for getting data to remote systems.

What Happened Next?

Client-server computing was developed in the 1980s when new hardware was created that made distributed systems possible. Operating software to support the new hardware developed quickly. Middleware to drive the new computing models was created by many companies to address challenges of the new client-server system. As this software was developed, enterprise systems evolved to interact with these new client-server systems and applications. This will be the subject of the next article in this series.

Joseph Gulla is the general manager and IT leader of Alazar Press, a publisher of award-winning children’s books. Joe is a frequent contributor to IBM Destination z (the community where all things mainframe converge) and writes weekly for the IT Trendz blog where he explores a wide range of topics that interconnect with IBM Z.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

A Beginner's Guide to the REXX Programming Language on z/OS

Reading and Writing Files in the REXX programming language on z/OS.


Application Management is Important to the Entire Process


Application Testing: Giving Users What They Need

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters