As every good schoolboy knows: cold showers after cross country running lessons put hairs on your chest; the acceleration of a body is parallel and directly proportional to the net force acting on that body; and when Juliet cried ‘wherefore art thou Romeo’, she meant WHY not WHERE as she vexed over her lover’s family allegiances.

So when we ask wherefore art thou middleware? What we really want to know is why do we need middleware? What pressure points upon our software application lifecycle cycle does it address? ... and, perhaps most crucially of all, are the full cadre of ‘stakeholders' sitting under the CIO's purview all fully cognizant of its function, importance and role in day-to-day operations?

What is middleware?
As much of many of us now understand the term, HP hosts a seminal paper by Philip A. Bernstein written in 1993 that serves as an arguably quite pivotal
definition for middleware that we can go back to again and again.

"To help solve heterogeneity and distributed computing problems, vendors are offering distributed system services that have standard programming interfaces and protocols. Standard programming interfaces make it easier to port applications to a variety of platforms, giving the customer some vendor-independence. Standard protocols enable programs to interoperate. These distributed system services are called middleware, because they sit ‘‘in the middle,'' layering above the operating system and networking software and below industry-specific applications," wrote Bernstein. So middleware performs functions including:

1. Accessing databases and handling input/output requests at various levels
2. Connecting software to an array of different hardware components
3. Forming the relationship required between application code and the run-time infrastructure in computer simulation systems
4. Scaling an application and/or integrating its various component parts

"The reason we have middleware is that some of this stuff is really hard to do," argues Red Hat UK head of middleware Steve Gaines. "Experienced developers create ‘engines' in the form of pieces of middleware code that can perform these tasks."

Of course Red Hat has its JBoss Enterprise Application Platform, Oracle has Fusion, IBM has WebSphere and "open" data integration tools now proliferate from the likes of Talend and others. Interestingly, HP also appears to champion "open first, proprietary second" here, as evidenced by its Open Source Middleware Stacks (OSMS) offering, which is designed to help reduce Linux roll-out complexity and and expedite integration within heterogeneous multi-OS environments.

Red Hat's Gaines provides some insight into how his firm's most recent product releases have been architected for the cloud computing market. Specific efficiencies have been engineered into JBoss so that a system will only start up the resources and run the segments of code it needs to execute a specified function.

What is our objective here?
"What we're looking at here is the march towards what we like to call the ‘Intelligent Integrated Enterprise'," said Gains. "Looking back five years or so ago we might have been handling a Red Hat Enterprise Linux job and saying - look, here's some JBoss as well. Today, we're talking directly to the VP of application development as they work with their CIO to bring intelligent middleware power to bear upon their software stack."

At the heart of any middleware stack we find Business Rules Engines (BRE) in use to allow non-programmers to define business logic outside of a code-centric programming environment. A ‘Business Rule' is part of a business policy that can be directed to perform an operation (or a sequence of operations) on data taken from databases or applications or from multiple sources simultaneously in a Complex Event Processing (CEP) scenario.

"Application infrastructure and middleware projects increasingly span on-premises, cloud and external business partners," said Fabrizio Biscotti, research director at Gartner. "The impacts of using multiple delivery models, increased reliance on governance technologies, and convergence of application and data integration requirements are driving organisations to sustain significant investment in AIM (application integration middleware) technologies and skills." So as an increasing amount of intelligent automation now becomes available across the programming environment, do we risk a backlash from developers
themselves who want to be able to work with more tangible and malleable technology that they themselves can impact?

The answer is yes, but it should not be a problem if we continue to align to open standards, open platforms and open source in this space. Middleware is, after all, all about integration -- and integration should be all about interoperability.

Buddha taught the middle way; maybe he had a point.

•   •   •

This post was first published on the Enterprise CIO Forum.