middleware
Middleware refers to an additional layer in a more complex software structure whose task is to simplify the access mechanisms to layers arranged below it and to hide the details of their infrastructure from the outside world. For this purpose, the middleware provides functions for distribution as well as services to support the application. In this respect the result of a middleware is the discharge of the application programs and in addition to optimize by a higher productivity the development process.
One differentiates two different categories of Middleware: communication-oriented as well as application-oriented Middleware. Communication-oriented middleware initially provides a logical infrastructure for communication. The application-oriented Middleware offers an extension of the run time environment, service components as well as a component model beyond the framework of communication. By the expenditure of an additional layer the introduction of a Middleware does not contribute positively to a higher performance of the total system. Well-known middleware products are the MQSeries 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, as there are no exact specifications in this respect. 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 over a distributed system. Here, the basic extension of the communication infrastructure by services and runtime aspects such as threads, techniques for data transformation (marshalling, formats) and mechanisms for error handling, among others, are part of the tasks.
The figure shows that communication-oriented middleware sits directly on top of the operating system as an independent layer 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. The connection of the communication model with a programming paradigm is established by a programming model. 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, base is Java, supports synchronous communication.
- Message Oriented Middleware (MOM), a message-oriented model, principle of queues, supports asynchronous communication.
Application-oriented middleware supplements the communication-oriented middleware by a run time functionality, specific services for the application layer as well as frequently also by a component model.
The illustration clarifies the principle of the application-oriented Middleware.
The run time environment offers in addition of the structures of a distributed operating system among other things the administration of connections, concepts for concurrency, availability scenarios with failure of a component as well as extended safety 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 differentiated regarding their concrete implementations into the following technologies:
- Object Request Broker (ORB), is based on the programming model for the remote call of methods, offers flexible services however without own run time environment, an example is CORBA.
- Application servers, support the logic of the application (Middle Tier), provide a communication infrastructure, flexible services as well as additionally a run time environment and a component model.
- Component-based middleware, supplement application servers to a closed distribution platform with associated component models, well-known environments are J2EE, the .NET platform with the component models COM and DCOM or CORBA with the component model CCM.
A typical example for the employment of communication-oriented Middleware shows the illustration in connection with distributed systems. Originally distributed systems - also called 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 level of effort in implementation and control. Here, the complexity from the application's point of view can be minimized by defining middleware as an additional software layer. Here, then, 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 IDL, Interface Definition Language), which is so-called for the application. The middleware also defines functionalities such as application concurrency and data management, security and management, and name and directory service management.
Middleware vendors' approaches vary widely. For example, while Microsoft's .NET relies entirely on the integration of middleware and operating system, other vendors such as IBM or Sun take the opposite approach of separating middleware and operating system to be able to ensure interoperability with different vendors. Also, the concepts supported depend on the particular market environment served, which speaks for a certain diversity of middleware. On the other hand, proprietary implementations from a particular vendor can lead to dependency on that vendor's product. Ultimately, middleware is a decisive feature of a specific software architecture. Finally, a brief summary 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).