Programs that serve as intermediaries and translators between two different computing platforms, perhaps between client workstations requesting data or programs, and servers that provide them. Middleware is used in cross-platform situations where the clients and servers run on different operating systems (OSs) or where different database file structures are used. See also client, database, OS, server, and software.
An application connecting two separate applications.
Middleware systems provide functionality such as
distribution of components, deployment, and transaction services that
developers can integrate into their own applications without having to worry
about implementation details.
In 2006, Microsoft’s .NET architecture and various
implementations of Sun Microsystems’ J2EE Standard were popular forms of
Software that functions as a conversion or translation layer. It is also a consolidator and integrator. Custom-programmed middleware solutions have been developed for decades to enable one application to communicate with another that either runs on a different platform or comes from a different vendor or both. Today, there is a diverse group of products that offer packaged middleware solutions as outlined in the following examples. See application integration.
The TP monitor (transaction processing monitor) was perhaps the first product to be called middleware. Sitting between the requesting client program and the databases, it ensures that all databases are updated properly (see TP monitor).
Messaging middleware provides a common interface and transport between applications. If the target machine is down or overloaded, it stores the data in a message queue until it becomes available. The messaging system may contain business logic that routes messages to the appropriate destinations and reformats the data as well. Messaging middleware is similar to an e-mail messaging system, except that it is used to send data between applications. (see messaging middleware).
Distributed object systems such as CORBA, DCOM and EJB enable processes to be run anywhere in the network. They differ from messaging middleware in that they cause processes (components/objects) to be executed in real time rather than sending data.
Middleware provides a common interface between a query and multiple, distributed databases. Using either a hub and spoke architecture (top) or a distributed architecture (bottom), it enables data to be consolidated from a variety of disparate data sources (see EDA and DQbroker).
Common programming interfaces between applications are considered middleware. For example, Open Database Connectivity (ODBC) enables applications to make a standard call to all the databases that support the ODBC interface.
Application Server Middleware
A Web-based application server that provides interfaces to a wide variety of applications is used as middleware between the browser and legacy systems. The browser can be used at desktops or on laptops when traveling. A wide range of server-side processing has been supported by appservers (see Java EE).
Middleware for networks includes a common approach for identifying users and network resources, authorizing and authenticating users and setting up standardized directory schemas. Using middleware in this fashion avoids the problems that occur when applications are responsible for these tasks and incompatible versions arise. The Internet2 project is expected to make advancements in this area. For more information, visit http://middleware.internet2.edu.
ActiveWorks software was designed solely as an integration solution. Brokering messages between a wide range of enterprise applications, it added processing where required. ActiveWorks was later acquired by webMethods and folded into its BPM suite. (Image courtesy of Active Software, Inc.)