PAST:
The true roots of middleware can in fact be traced all the way to the formulation of the client–server model in the 1960s and 1970s, when computer scientists at Xerox and Xerox PARC came up with the concept of server-host (or serving host) and user-host. The fundamentals of this were pretty simple and still hold true:
Servers are a dedicated single or group of systems/machines that are meant to perform certain commonly used generic functions.
Clients are a group of distributed consumers (again systems/machines) that need to avail the services offered by servers. Clients are supposed to make requests and the server is supposed to serve it.
The Client-Server model was a big leap in the history of computing; now the clients are no longer just a dump display terminal to translate and display the byte of data stream from centralized systems (like mainframes and AS/400) into a human readable language. Clients started to take the shape of powerful computing local devices that now would rely on servers for specific needs only. If we look closely, clients have evolved from dump terminals à desktops à laptops à handheld devices (table / mobile) à wearable gadgets.
This model introduced the need for communication channels through which these machines could talk to each other. The history of the term middleware, going all the way back to the 1980s, primarily focused on fulfilling the network connection management software needs of the client-server model. It was not until the 1990s when middleware started achieving sufficient penetration and visibility with the advancement of network technology. The past of Middleware is very well addressed in an article from David E. Bakken, Washington State University. A few of the lines are quoted below:
By 1990s middleware had evolved into a much richer set of paradigms and services offered to help make it easier and more manageable to build distributed applications. The term was associated mainly with relational databases for many practitioners in the business world through the early 1990s, but by the mid-1990s this was no longer the case [1,2]. Concepts similar to today’s middleware previously went under the names of network operating systems, distributed operating systems and distributed computing environments. [For further reference, entire article link can be found at: http://www.eecs.wsu.edu/~bakken/middleware.pdf ]
In a nutshell, the following diagram to a large extent reflects the past of middleware.
PRESENT:
Middleware today implies integration servers like EAI, SOA, ESB, Web Services, RESTful APIs, JSON and various others. What really constitutes the boundary of middleware is debatable in today’s world, and the only common settling ground is: a “glue” technology required to integrate diversified systems, components and applications.
Up until today, various vendors have focused on addressing three main areas under the umbrella of middleware: Communication, Processing & Store. So there is no need to be surprised when you come across terms like Middleware for data, BPM, distributed database, and Enterprise Service Bus (ESB), APIs, SOA, ETL, EAI, etc. as a middleware offering. Also, there always has been debate around how one is better than the other and as the IT landscape changes or evolves, how one will survive and grow at the expense of the other. Different vendors with different focuses have their own story to tell. At the end of the day, all these are good enough to confuse everyone about this mystic term called “Middleware”.
Today, Oracle is the only organization with the most holistic and all compromising approach towards Middleware. Middleware is a platform and not just diverse sets of framework, technology or integration offerings; it is the software layer that lies between the operating system and the applications on each side of a distributed computer network (quoted from Oracle Middleware Concepts Guide). The following image from the same guide on Fusion Middleware reflects this holistic approach very well.
http://docs.oracle.com/cd/E21764_01/core.1111/e10103/img/productoverview.gif
The Platform is indeed the present of Middleware and there is no doubt every vendor in the near future is going to follow the same suite.
FUTURE:
What does middleware have to offer in the future? Is Middleware as a platform the end of the Middleware evolution?
Indeed the answer is NO.
EVOLUTION is the special gift that has been bestowed on all living creatures and then extended through their innovations. We have not stopped evolving and we never will; so it will be with middleware. Now the question comes, what’s next?
The 21st century has witnessed ongoing increasing dependency of business on technology. At the same time, it won’t be incorrect to say that technology has seen tremendous unimagined growth and adoption because of growing business needs. So, the answer lies in the very basic question, how can Middleware be a business accelerator of tomorrow?
Will it be in the technological improvement of HUB-SPOKE over POINT-TO-POINT, SOA over ESB, RESTful over SOA? Middleware is the behind-the-scenes mechanism that enables distributed, diversified technology to stick together, but that will not be sufficient enough for future solutions to cater to the growing needs of a business. One thing is for sure, that no one technological approach is going to triumph over the other in order to fulfill the needs of an entire enterprise. The future of middleware has to be based on a hybrid technological model that will need to be business centric.
In short, Middleware has to follow the evolutionary path of human communication skill. Middleware as a platform is still very primitive when we talk about efficiency and effectiveness of communication, compared with what humans have mastered so far. Middleware communication needs to develop receptive language skills.
For the Middleware of the Future, the technology glue has to be Simple and Smart, with flexible advanced skills to speak and comprehend any business language.
Manvendra Blogs 
