Cross-platform network communication middleware: Ice and ACE

Since the middle of 1990s, the industry has been using object-oriented middleware platforms such as DCOM and CORBA. In distributed applications, the middleware platform hosts most network transactions, such as data encoding and decoding for transmission, and maps logical object addresses to physical transmission endpoints, change the data representation based on the machine architecture of the customer and server, and automatically start the server as needed. Because of its shortcomings, DCOM and CORBA have not successfully occupied most of the distributed computing market. DCOM is Microsoft's exclusive solution. In a heterogeneous network, various machines run a variety of operating systems and cannot use DCOM all. At the same time, DCOM does not support creating a large number of objects (hundreds of thousands or millions), which is largely due to the overhead of its distributed garbage collection machine.

Although a number of vendors provide CORBA products, none of them can implement all the operating system environments in the heterogeneous network environment. Despite a large amount of standardization work, the lack of interoperability between different CORBA implementations has continuously caused various problems. In addition, suppliers often define extensions by themselves, the lack of multi-threaded environment specifications for CORBA has never been fully implemented for languages like C or C ++.
In a heterogeneous network environment, it is not easy to make DCOM and CORBA coexist. In 2002, Microsoft launched the. NET platform to replace DCOM .. NET provides more powerful distributed computing support than DCOM, but it is still Microsoft's exclusive solution. On the other hand, the technology of CORBA has stagnated, and many vendors have left the market. Many defects in the CORBA specification have not been solved in a timely manner. Along with the decline of DCOM and CORBA, developers in the distributed computing field have a strong interest in SOAP and Web Services.

SOAP and WebServices technology once caused a huge public effect, and many papers have been published in the industry. However, no matter in terms of network bandwidth or CPU overhead, SOAP will leave a serious impact on the application.
Performance bottleneck. Applications can splice various SOAP messages together, but this is extremely tedious and error-prone.
The standardization process of WebServices is very slow and has been on the technical implementation for many years. Many experts worry about the architecture security of SOAP and WebServices. In this context, the middleware ICE and ACE of network communication were born.

ICE is a high-performance middleware that supports distributed deployment management, message middleware, and grid computing.
ICE has the following advantages: Object-oriented semantics. All operation calls are later bound.

Supports synchronous and asynchronous message transmission, synchronous and asynchronous operation call and dispatch, and publish-subscribe message transmission. It has nothing to do with the hardware architecture. clients and servers are shielded from the underlying hardware architecture. For application code, problems such as byte order and padding are hidden. It has nothing to do with the upper-layer programming language. The client and server can be deployed in different languages, C ++ and Java languages, and PHP languages are supported on the client. It has nothing to do with the operating system used. ICE is completely portable. The same source code can be compiled and run on Windows, Linux, MacOS, and UNIX. It is completely threaded, and its API is thread-safe.

Using TCP/IP, IP, and UDP as the transmission protocol, client and server code do not need to understand the underlying transmission mechanism. The server location is transparent to users. ICE routines are responsible for locating objects and managing underlying transmission mechanisms, such as opening and closing connections. The interaction between the customer and the server seems like no connection. The server can be migrated to different physical addresses without invalidating the proxy held by the customer. The customer has no idea how the object implementation is distributed across multiple server processes. SSL-based strong encryption enables secure communication between customers and servers. Use the built-in persistence mechanism to create persistent objects. It also provides built-in support for high-performance database BerkeleyDB.

ICE provides a rich set of reusable WrapperFacade and framework components to complete common communication software tasks across multiple platforms, including: multi-channel event separation and event processor allocation, signal processing, service initialization, inter-process communication, shared memory management, message routing, distributed service dynamic (heavy) configuration, concurrent execution and synchronization, etc. ACE simplifies the development of object-oriented network applications and services using inter-process communication, event Multi-Channel Separation, explicit dynamic links, and concurrency. ACE benefits include enhanced Portability: with the help of ACE components, it is easy to write concurrent network applications on an OS platform, and then quickly port them to a variety of other OS platforms. Better Software Quality: ACE uses many key design patterns that can improve software quality, and provides communication software flexibility, scalability, reusability, and modularity.
Higher efficiency and predictability: Ace supports a wide range of application Quality of Service (QoS) requirements, including low response waiting time for latency-sensitive applications, high performance of high-bandwidth applications, and real-time application predictability.
It is easier to switch to standard advanced middleware: Tao uses reusable components and models provided by Ace, implements them according to the standard of CORBA, and optimizes high-performance and real-time systems. Ace contains an advanced network programming framework that integrates and enhances a lower-level C ++ packaging look. This framework supports dynamic configuration of concurrent distributed services into applications. The ACE framework includes the following components:
Event multiplexing components: Ace Reactor (Reactor) and proactor (front camera) are scalable object-oriented multiplexing splitters that distribute proprietary processors to applications, to respond to various types of I/O, timer, signal, and synchronization events.
Service initialization component: the ace acceptor and connector (connector) components decouple active and passive initialization tasks with application proprietary tasks executed by the communication service once Initialization is complete.
Service Configuration component: Ace
Service configurator supports application configurations. Services of these applications can be dynamically assembled during installation or running.
Layered stream component: the ace stream component simplifies the development of communication software applications composed of layered services such as user-level protocol stacks.
Orb adapter component: Through orb adapter, Ace can be seamlessly integrated with single-line and multi-thread CORBA implementations.
The same as network communication middleware, the difference between ice and Ace is that the former encapsulates communication objects,
For example, the client's ice core is different from the server's ice core, while the latter is an encapsulation of the communication itself, such as socket encapsulation and synchronous asynchronous communication. The latter is more underlying and abstract than the former. Ace can be considered as a general network programming framework software, while ice is a cross-platform RPC software.