- Tech know how online


Middleware is an additional layer in a more complex software structure whose task is to simplify the access mechanisms to layers below it and to hide the details of their infrastructure from the outside. To this end, the middleware provides functions for distribution and services to support the application. In this respect, the result of middleware is to reduce the load on the application programs and also to optimize the development process by increasing productivity.

There are two different categories of middleware: communication-oriented and application-oriented middleware. Communication-oriented middleware first provides a logical infrastructure for communication. The application-oriented middleware provides an extension of the runtime environment, service components as well as a component model beyond the scope of communication. Due to the effort of an additional layer, the introduction of a middleware does not positively contribute to a higher performance of the overall system. Well-known middleware products are the MQ series from IBM, the Websphere Application Server or the SAP Exchange Infrastructure from SAP.

The concrete design and complexity of a middleware essentially depend on the services it provides to the application. The implemented middleware technologies therefore also vary, since there are no exact specifications in this regard. The Software Engineering Institute (SEI), for example, explicitly distinguishes between TP monitors, message-oriented middleware (MOM), remote procedure calls (RPC) and object request brokers (ORB) when categorizing middleware. This also shows that a whole series of standardizations has become established in the middleware environment. The present explanations are based on a division into the following categories: communication-oriented middleware and application-oriented middleware.

Communication-oriented middleware defines the infrastructure for the communication of distributed applications via a distributed system. Here, the basic extension of the communication infrastructure by services and runtime aspects such as threads, data transformation techniques (marshalling, formats) and error handling mechanisms, among others, are part of the tasks.

Application Middleware

Application Middleware

The figure shows that communication-oriented middleware is built directly as an independent layer on top of the operating system and flexibly supplements its functionality. An essential element is the handling of different data formats so that all components involved can interpret the data to be processed in the same way. The preparation of data into a format for transmission is called marshalling, while the recovery of data is called unmarshalling. An example in this context is the Common Data Representation (CDR) of CORBA.

The middleware can support both synchronous and asynchronous communication models, and is completely independent of the application for which these services are provided. Synchronous middleware is often used in environments with high interaction between applications. A programming model is used to connect the communication model to a programming paradigm. The programming paradigms used are mainly the procedural paradigm as well as the object-oriented paradigm, so the middleware uses the following programming models:

  • Remote Procedure Calls (RPC), procedural, remote invocation of a procedure, supports synchronous communication.
  • Remote Method Invocation (RMI), object-oriented, based on Java, supports synchronous communication.
  • Message Oriented Middleware (MOM), a message-oriented model, principle of queues, supports asynchronous communication.
Application-oriented middleware supplements communication-oriented middleware with runtime functionality, specific services for the application layer, and often a component model.

Application-Oriented Middleware

Application-Oriented Middleware

The figure illustrates the principle of application-oriented middleware.

In addition to the structures of a distributed operating system, the runtime environment provides, among other things, the management of connections, concepts for concurrency, availability scenarios in the event of a component failure, and extended security functions.

An application-oriented middleware implicitly provides so-called services via the runtime environment, which can be accessed by means of special programming interfaces (API). Possible services can be: Naming services, e.g.: Interoperable Naming Service (INS), session management, persistence services or transaction management.

Component models define application objects as components and expose them to a component runtime environment. Well-known component models are J2EE or .NET.

Application-oriented middleware can be divided into the following technologies in terms of their concrete implementations:

  • Object Request Broker (ORB), is based on the programming model for remote invocation of methods, provides flexible services but without its own runtime environment, an example is CORBA.

  • Application servers, support the logic of the application (middle tier), provide a communication infrastructure, flexible services and additionally a runtime environment and a component model.

  • Component-based middleware, complement application servers to a closed distribution platform with associated component models, Known environments are J2EE, the .NET platform with the component models COM and DCOM or CORBA with the component model CCM.
Communication-oriented middleware

Communication-oriented middleware

A typical example of the use of communication-oriented middleware is shown in the figure in connection with distributed systems. Originally, distributed systems - also known as computer networks - offer only basic communication services as well as simple measures for security and error handling. If an application is based directly on the protocol stack of the distributed system, this is certainly advantageous for high performance, but at the same time means a high effort in implementation and control. Here, the complexity from the application's point of view can be minimized by defining a middleware - as an additional software layer. So here the middleware defines the logical pattern of interaction between the partners in distributed systems, so that the original infrastructure of the application itself remains hidden. Both asynchronous and synchronous forms of communication are supported by the middleware. The example also shows the Intelligent Calling Interface (also known as IDL, Interface Definition Language) for the application. Middleware also defines functionalities such as application concurrency and data management, security and management, and name and directory service management.

The approaches of middleware vendors are quite different. For example, while Microsoft's .NET relies entirely on the integration of middleware and the operating system, other vendors such as IBM or Sun take the opposite approach of separating middleware and the operating system to ensure interoperability with different vendors. Also, the concepts supported depend on the particular market environment served, which argues for a certain diversity of middleware. On the other hand, proprietary implementations of a particular vendor can lead to dependency on that vendor's product. In the end, middleware is a crucial feature of a specific software architecture. Finally, here's a brief roundup of popular middleware products: SAP Exchange Infrastructure, IBM MQSeries, WebSphere Application Server (IBM), CORBA (Object Management Group, OMG), Enterprise Service Bus (Oracle), and Tibco (TIBCO).

Informationen zum Artikel
Englisch: middleware
Updated at: 15.08.2012
#Words: 1849