The origins of the term "middleware" can be traced back to late 1960s, when it was used to denote software technologies situated between an application and the underlying software platform, with the goals of masking platform dependence and providing specialized services. In the late 1980s and especially throughout 1990s, the use of the term shifted. Rather than denoting any software technology interposed between an application and the underlying software platform, the term is now used more strictly in the context of distributed applications, where the issues of platform dependence and specialized services stand out. Several more or less formal definitions of the term "middleware" illustrate the concept:
| Â | The term "middleware" is defined by one's point of view. Many interesting categorizations exist, all centered around sets of tools and data that help applications use networked resources and services. Some tools, such as authentication and directories, are in all definitions of middleware. Other services, such as coscheduling of networked resources, secure multicast, object brokering, and messaging, are the particular interests of certain communities, such as scientific researchers or business systems vendors. This breadth of meaning is reflected in the following working definition: Middleware is "the intersection of the stuff that network engineers don't want to do with the stuff that applications developers don't want to do." | Â |
| Â | --Klingenstein K. J.: Middleware: The Second Level of IT Infractructure. | |
| Â | Middleware is connectivity software that consists of a set of enabling services that allow multiple processes running on one or more machines to interact across a network. Middleware is essential to migrating mainframe applications to client-server applications and to providing for communication across heterogeneous platforms. This technology has evolved during the 1990s to provide for interoperability in support of the move to client-server architectures. The most widely-publicized middleware initiatives are the Open Software Foundation's Distributed Computing Environment (DCE), Object Management Group's Common Object Request Broker Architecture (CORBA), and Microsoft's COM/DCOM (COM, DCOM). | Â |
| Â | --Bray M.: Middleware. | |
| Â | The role of middleware is to ease the task of designing, programming and managing distributed applications by providing a simple, consistent and integrated distributed programming environment. Essentially, middleware is a distributed software layer, or platform, which abstracts over the complexity and heterogeneity of the underlying distributed environment with its multitude of network technologies, machine architectures, operating systems and programming languages. | Â |
| Â | --Coulson G.: Middleware. | |
Developing and maintaining distributed applications requires considerable effort. The evolution of middleware reflects more general trends to reduce this effort, especially through reducing diversity and reducing coupling. One example of the drive to reduce diversity is the introduction of architectural styles that impose reasonable constraints on distributed application design, standardized platforms then support those architectural styles to make development easier. One example of the drive to reduce coupling is the tendency to strictly separate interfaces from implementation, which limits change propagation, and, when interfaces are based on the problem domain rather than the application implementation, also has the potential to reduce change frequency.
Examples of simple architectural styles include a distributed application built around a central server that implements the entire application and clients that act as remote terminals, or a distributed application built around a central server that implements a network filesystem and clients that implement the entire application. Other architectural styles include tiered architectures, distributed object architectures, event based architectures, data centric architectures, service-oriented architectures, peer-to-peer architectures. Obviously, the styles are not necessarily exclusive.
References.Â
Bray M.: Middleware. Software Technology Review, Carnegie Mellon Software Engineering Institute, 1997, http://www.sei.cmu.edu/str/descriptions/middleware.html.
Coulson G.: Middleware. Distributed Systems Online, IEEE, 2000, http://computer.org/dsonline/middleware/index.htm.
Klingenstein K. J.: Middleware: The Second Level of IT Infrastructure. Cause And Effect Journal Vol. 22 No. 4, EduCause, 1999, http://www.educause.edu/ir/library/html/cem/cem99/cem9942.html.