What is middleware?

I. Why middleware?

Computer technology is developing rapidly. From the perspective of hardware technology, the CPU speed is getting higher and higher, and the processing capability is getting stronger. From the perspective of software technology, the scale of applications is constantly expanding, especially the emergence of Internet and WWW, this gives computers a wider range of applications. Many applications need to run on heterogeneous platforms in the network environment. All of this poses new requirements for the next generation of software development. In such a distributed heterogeneous environment, there are usually a variety of hardware system platforms (such as PCs, workstations, minicomputers, etc ), there are a variety of system software (such as different operating systems, databases, language compilers, etc.) on these hardware platforms, as well as a variety of user interfaces with different styles, these hardware system platforms may also use different network protocols and network architecture connections. It is very realistic and difficult to integrate these systems and develop new applications.

2. What is middleware?

In order to solve the problem of distribution heterogeneity, people put forward the concept of middleware (middleware. Middleware is a common service between the Platform (hardware and operating system) and applications, as shown in Figure 1. These services have standard program interfaces and protocols. For different operating systems and hardware platforms, they can have multiple implementations that comply with the interface and protocol specifications.

Figure 1 Middleware

It may be difficult to define the middleware strictly, but the middleware should have the following features:

Meet the needs of a large number of applications
Running on multiple hardware and OS platforms
Supports distributed computing and transparent interaction of applications or services across networks, hardware, and OS platforms
Standard protocols supported
Supports standard interfaces

Due to the importance of standard interfaces for portability and standard protocols for interoperability, middleware has become a major part of many standardization work. For application software development, middleware is far more important than operating systems and network services. The program interfaces provided by middleware define a relatively stable high-level application environment, no matter how the underlying computer hardware and system software are upgraded, as long as the middleware is upgraded and the interface definition of the middleware is kept unchanged, the application software does not need to be modified, this protects significant investments in application software development and maintenance.

Iii. Classification of main Middleware

Middleware has a wide range of features, and a variety of distinctive middleware Products have emerged for different application requirements. So far, no precise definition of middleware is provided. Therefore, the classification of middleware varies from different angles or layers. Because middleware needs to shield heterogeneous operating systems and network protocols in the distributed environment, it must be able to provide communication services in the distributed environment. We call this communication service a platform. Based on different purposes and implementation mechanisms, we divide the platform into the following main categories:

Remote Procedure Call)
Message-Oriented Middleware (Message-Oriented Middleware)
Object Request Broker)

They can provide different forms of communication services, including synchronization, queuing, subscription and publishing, and broadcasting. On these basic communication platforms, they can build various frameworks, provides services in different fields for applications, such as transaction processing monitor, distributed data access, and Object Transaction Manager OTM. The Platform shields the differences between heterogeneous platforms for upper-layer applications, and its framework defines the system structure and standard service components of applications in the corresponding fields, you only need to tell the framework about the events and then provide the code to handle these events. When an event occurs, the Framework calls your code. User code does not need to call the framework, and user programs do not need to care about the framework structure, execution process, and system-level API calls. All these are done by the framework. Therefore, applications developed based on middleware have good scalability, manageability, high availability, and portability.

The following describes the main types of middleware.

1. Remote process call

Remote Process calling is a widely used distributed application processing method. An application uses RPC to remotely execute a process in a different address space, and the effect is the same as that of local calls. In fact, an RPC application is divided into two parts: server and client. Server provides one or more remote processes. The client sends a remote call to the server. The server and client can be on the same computer, different computers, or even running on different operating systems. They communicate through the network. The corresponding stub and running support provides data conversion and communication services to shield different operating systems and network protocols. RPC communication is synchronized here. Asynchronous calls can be performed using threads.

In the RPC model, as long as the client and server have the corresponding RPC interfaces and support for RPC operation, the corresponding interoperability can be completed without limiting specific servers. Therefore, RPC provides powerful support for client/server distributed computing. At the same time, Remote Procedure Call RPC provides process-based service access. The client directly connects to the server without an intermediate mechanism to process requests. Therefore, Remote Procedure Call RPC also has some limitations. For example, RPC usually requires some network details to locate the server. When the client sends a request, the server must be active.

2. Message-Oriented Middleware

MOM refers to the use of an efficient and reliable message transmission mechanism for platform-independent data exchange and integration of Distributed Systems Based on Data Communication. By providing message transmission and Message Queuing Models, it can expand inter-process communication in a distributed environment and support multi-communication protocols, languages, applications, hardware, and software platforms. Currently, popular MOM middleware Products include IBM MQSeries and BEA MessageQ. The following three technologies are available for message transmission and queuing:

Main features:

Communication Programs can directly talk to each other at different times, but indirectly put messages into the message queue because there is no direct connection between programs. So they do not have to run at the same time. When a message is placed in an appropriate queue, the target program does not even need to be running. Even if the target program is running, it does not mean that the message must be processed immediately.

The structure of the application is not restricted in complex application scenarios. communication programs can be in a one-to-one relationship, but also in one-to-many and multiple-to-one modes, it is even a combination of the above methods. The construction of multiple communication modes does not increase the complexity of applications.

Programs are isolated from Network Complexity

The program puts messages into the message queue or retrieves messages from the message queue for communication. All activities associated with the message queue, for example, it is a MOM task to maintain message queues, maintain the relationship between programs and queues, process network restarts, and move messages in the network. programs do not directly communicate with other programs, and they do not involve the complexity of network communication.

3. Object Request proxy

With the development of object technology and distributed computing technology, the two have combined to form distributed object computing, and concurrency has become the mainstream direction of today's software technology. At the end of 1990, OMG launched the Object Management Architecture (OMA) for the first time. The Object Request Broker (OMG) is the core component of this model. It provides a communication framework that transparently transmits Object Requests in Heterogeneous Distributed computing environments. The CORBA Specification includes all the standard interfaces of ORB. Launched in 1991, CORBA 1.1 defines the Interface Description Language omg idl and APIs that support Client/Server object interoperability on specific ORB. The norm of CORBA 2.0 describes the interoperability between ORB provided by different vendors.

The Object Request proxy (ORB) is an object bus. It is at the core of the CORBA specification and defines the basic mechanism for objects to transparently send requests and receive responses in a heterogeneous environment, is the middleware that establishes the client/server relationship between objects. ORB allows objects to transparently send requests to other objects or receive responses from other objects. These objects can be stored locally or remotely. ORB intercepts request calls and is responsible for finding the objects that can implement the request, transmission parameters, calling corresponding methods, and returning results. The client object does not know the mechanism for communicating, activating, or storing the server object with the server object, you do not need to know where the server object is located, the language in which it is implemented, the operating system used, or other system components that are not part of the object interface.

It is worth noting that the client and server roles are only used to coordinate the interaction between objects. According to the corresponding situation, the objects on ORB can be clients, servers, or even both. When an object sends a request, it is in the client role; when it receives the request, it is in the server role. Most objects assume both the client role and the server role. In addition, because orb is responsible for transmitting Object Requests and managing the server, the client and server are not directly connected. Therefore, compared with the simple Client/Server structure supported by RPC, orb supports more complex structures.

4. Transaction Processing monitoring

Transaction Processing monitoring (Transaction Processing monitors) first appeared on the mainframe, providing it with a reliable runtime environment that supports large-scale transaction processing. With the development of distributed computing technology, distributed application systems demand large-scale transaction processing, such as a large number of key transactions in business activities. The transaction processing monitoring field is between the client and server. It manages and coordinates transactions, balances loads, and recovers failures to improve the overall system performance. It can be seen as the "Operating System" of the transaction processing application ". In general, transaction processing monitoring has the following functions:

Process management, including starting the server process, assigning tasks to it, monitoring its execution, and balancing the load.
Transaction Management ensures the atomicity, consistency, independence, and durability of transaction processing under its monitoring.
Communication Management provides multiple communication mechanisms between the client and the server, including Request Response, session, queuing, subscription, publishing, and broadcast.
Transaction Processing monitoring can provide services for a large number of clients, such as the aircraft ticketing system. If the server allocates the required resources to each client, the server will be overwhelmed (2 ). But in fact, not all clients need to request the service at the same time. Once a client requests the service, it wants to get a quick response. Transaction Processing monitoring provides a set of services on top of the operating system, manages client requests, and assigns them corresponding service processes, this enables the server to efficiently provide services to large-scale customers with limited system resources.

Figure 2 transaction processing monitoring

Iv. Problems

Middleware can shield the differences between operating systems and network protocols, provide multiple communication mechanisms for applications, and provide corresponding platforms to meet the needs of different fields. Therefore, middleware provides a relatively stable high-level application environment for applications. However, the middleware service is not a panacea ". Some principles that middleware should follow are still far from reality. Most popular middleware services use proprietary APIs and proprietary protocols, making applications built on products of a single manufacturer. It is difficult for different manufacturers to implement interoperability. Some middleware services only provide the implementation of some platforms, thus limiting the transplantation of applications between heterogeneous systems. Application developers have to bear considerable risks when building their own applications on top of these middleware services. As technology develops, they often need to rewrite their systems. Although middleware services increase the abstraction of distributed computing, application developers still need to face many difficult design choices. For example, developers also need to determine the function distribution of distributed applications on the client and server. Usually, services are placed on the client to facilitate the use of display devices. Data Services are placed on the server to access the database, but this is not always the case. In addition, it is difficult to determine how to allocate other application functions.