From: http://tech.ccidnet.com/pub/Article/c322_a204629_p1.htmlauthor: Software Research Institute of Chinese Academy of Sciences Date: 2005.01.16 Keywords: middleware
First, why do the middleware computer technology develops rapidly. From hardware technology, the CPU speed is getting higher and higher, and the processing capacity is getting stronger; from software technology, the scale of application is expanding, especially the emergence of Internet and WWW, making the computer's application range more broad, many applications The program needs to run on the heterogeneous platform of the network environment. All of this has made new demand for new generation software development. In this distributed heterogeneous environment, there are usually a variety of hardware system platforms (such as PCs, workstations, small machines, etc.), and there are various system software (such as different operating systems, databases, etc.) on these hardware platforms. Language compiler, etc.), as well as user interfaces vary from different styles, which may also use different network protocols and network architectural connections. How to integrate these systems and develop new applications is a very realistic and difficult problem. II is that the middleware is to solve the distribution of heterogeneous issues, and people have proposed the concept of midware (Middleware). The middleware is a general service between the platform (hardware and operating system) and the application, as shown in Figure 1, these services have standard program interfaces and protocols. For different operating systems and hardware platforms, they can have a variety of implementations that meet the interfaces and protocol specifications.
Figure 1 Middleware
It may be difficult to give a strict definition of middleware, but the middleware should have the following characteristics: to meet a large number of applications to support distribution calculations in a variety of hardware and OS platforms, provide transparency across network, hardware and OS platforms. Interactive Support for Applications or Services Support Standards Support Standard Interfaces Because of the importance of the standard interfaces for interoperability, middleware has become a major part of many standardization work. For application software development, middleware is more important than operating system and network services, the program interface provided by the middleware defines a relatively stable high-level application environment, regardless of how the bottom-level computer hardware and system software are replaced, as long as the middleware Upgrade updates and keep the interface definitions of the intermediate pieces are unchanged, and the application has almost no modification, which protects the company's major investment in application software development and maintenance. Third, the scope of the classification middleware of the main middleware is widely wide, and there are many distinctive middleware products for different applications. However, there is no more precise definition in middleware so far, so in different angles or different levels, the classification of middleware will also be different. Since the middleware requires a shielding of heterogeneous operating systems and network protocols in the distribution environment, it must provide communication services in the distribution environment, and we call this communication service as a platform. Based on the purpose and implementation mechanism, we divide the platform into the following major categories: Remote Procedure Call, a Message-Oriented MiddleWare object request agent (Object Request Brokers) can provide different Form communication services, including synchronous, queuing, subscription release, broadcasting, etc., above these basic communication platforms, you can construct a variety of frameworks, providing applications with services within different fields, such as transactional monitoring, distribution data Access, Object Series OTM, etc. The platform is the difference in heterogeneous platforms for the upper layer application, and the framework has defined system structures, standard service components, etc. in the corresponding field, and users only tell the events of the framework, and then provide processing these events. Code. When the event occurs, the framework calls the user's code. The user code does not need to call the frame, and the user program does not have to care about the frame structure, the execution process, the call to the system-level API, etc., all of these is done by the framework. Therefore, applications based on middleware have good expansion, easy management, high availability, and portability. Below, a brief introduction to several major middleware is separately introduced. 1. Remote Procedure Call Remote Process Call is a widely used distributed application processing method. An application uses RPC to "Remote" to perform a process in different address spaces and is the same as in the effect and performing local calls. In fact, an RPC application is divided into two parts: Server and Client. Server provides one or more remote processes; Client issues remote calls to Server. Server and Client can be located on the same computer, or within different computers, even on different operating systems. They communicate through the network. The corresponding STUB and running support provide data conversion and communication services to shield different operating systems and network protocols. The RPC communication here is synchronized. Asynchronous calls can be used. In the RPC model, Client and Server have the corresponding RPC interface and have RPC operation support, and the corresponding interoperability can be completed without restrictions on a particular Server. Therefore, RPC provides powerful support for Client / Server distribution calculations. At the same time, the remote process calls the RPC provides a process-based service access, the Client is directly connected to the Server, and there is no intermediate mechanism to process the request, so there is also a certain limit.
For example, RPC usually requires some network details to locate the server; while requiring a request, the Server must be active. 2, the intermediate member MOM-oriented intermediate member is referring to the high-efficiency and reliable messaging mechanism for platform-independent data communication, and is based on data communication to integrate the distributed system. By providing a message delivery and message queuing model, it can extend communication between processes in the distribution environment and support multi-communication protocol, language, applications, hardware, and software platforms. At present, popular MOM middleware products have IBM's MQSeries, BEA's MessageQ, etc. Message transfer and queuing technology have the following three main features: The communication program can run at different times: the program is not talking directly to each other on the network, but is indirectly placed in a message queue because there is no direct connection between the program. So they don't have to run at the same time. When the 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 is handled immediately. There is no constraint for the structure of the application: in complex applications, the communication program can be one-to-one relationship, but also a pair of multi-pair one or more, even the combination of the above methods. The structure of a variety of communication methods does not increase the complexity of the application. The program is isolated from the network complexity: the program puts the message into the message queue or takes the message from the message queue to communicate, all activities associated with this, such as maintaining the relationship between the message queue, maintenance procedures, and queues, processing the network Restart and move messages in the network are MOM's tasks, and programs are not talking to other programs, and they do not involve the complexity of network communication. 3. Object requesting agent With the development of object technology and distributed computing technology, the two have formed a distribution object calculation and developed into the mainstream direction of today's software technology. At the end of 1990, the Object Management Group omg first launched an object management structure OMA (Object Management Architecture), the object request agent (Object Request Broker) is the core component of this model. Its role is to provide a communication framework that transparently transmits object requests in the heterogeneous distribution computing environment. The CORBA specification includes all standard interfaces of ORB. The CORBA 1.1 introduced in 1991 defines the interface description language omg id1 and the API that supports the Client / Server object on the specific ORB. The CORBA 2.0 specification describes interoperability between the ORBs provided by different vendors. Object Request Agent (ORB) is an object bus, which is in a core position in the CORBA specification, defining the basic mechanism of the object transparent in the heterogeneous environment, is the basic mechanism of the reception response, which is the middleware of the Client / Server relationship between the object. ORB allows objects that can be transparently issued to other objects to respond to other objects, which can be located locally or within the remote machine. ORB intercepts request call, and is responsible for finding objects that can implement the requested object, transmit parameters, call the corresponding method, return results, etc. The client object does not know the mechanism of the Server object communication, activation, or store the Server object, or you don't have to know where the Server object is, it is implemented, what operating system or other system ingredients that do not belong to the object interface. It is worth noting that the client and server role are only used to coordinate the interaction between objects. According to the corresponding occasions, the objects on the ORB can be a client, or a server, even both. When an object issues a request, it is in a client role; when it is receiving the request, it is in the Server role. Most of the objects are both playing a Client role and playing a Server role. In addition, since ORB is responsible for the transmission of object requests and Server management, the client and server are not directly connected, and the ORB can support more complex structures compared to the simple Client / Server structure supported by RPC.
4. Transaction Processing Monitors earliest appears on the mainframe to provide a reliable operating environment that supports large-scale transactions. With the development of distribution computing technology, distributed application systems have put forward demand for large-scale transactions, such as a large number of key transactions in business activities. Transaction Monitoring Between Client and Server, transaction management and coordination, load balancing, failure recovery, etc. to improve the overall performance of the system. It can be seen as an "operating system" of the transaction application. Overall, transaction monitoring has the following functions: process management, including launching the Server process, assigning tasks, monitoring its execution, and balancing the load. Transaction management, that is, atomic, consistency, independence, and persistence of transactions under its surveillance. Communication management, providing a variety of communication mechanisms between Client and Server, including request response, session, queuing, subscription release, and broadcasting, etc. Transaction monitoring can serve a large number of Client, such as aircraft ticketing system. If Server assigns the resources they need for each Client, the server will be overwhelmed (as shown in Figure 2). But in fact, all Client is not requested to serve at the same time, and once a client requests the service, it wants to get a quick response. Transaction Monitoring provides a set of services over the operating system, managing the Client request and assigns the corresponding service process, so that Server can efficiently provide services to large-scale customers under limited system resources. Figure 2 Transaction processing monitoring
IV, some of the problems in the middleware can shield the differences in the operating system and network protocols, provide a variety of communication mechanisms for the application; and provide the corresponding platform to meet the needs of different fields. Therefore, the middleware has a relatively stable high-level application environment for the application. However, middleware services are not "universal medicine." Some of the principles that the middleware should follow are very large from the actual situation. Most popular middleware services use proprietary APIs and proprietary protocols, making it difficult to interoperate from different manufacturers. Some middleware services only provide some platform implementation, limiting the transplantation between the heterogeneous systems. Application developers build their own applications on these middleware services to bear considerable risks. As technology develops, they often need to rewrite their systems. Although the middleware service increases the degree of abstraction of distribution calculations, application developers need to face many difficult design choices, for example, developers need to decide distribution applications in the CLIENT and Server party function assignment. It is usually placed in the client to facilitate the use of the display device to place the data service in Server to close to the database, but not always, how to allocate other application functions is also not easy to determine. (T113) Said Net Middleware Topics http://tech.ccidnet.com/pub/series/s64.html
