Five Common Remote Call protocols in j2ee

This article compares the transmission performance of five communication protocols, including RMI, Hessian, Burlap, Httpinvoker, and web service, in different data structures and data volumes. RMI is a remote communication protocol provided by the java language. It is stable and efficient and is the basis of EJB. However, it can only be used for communication between JAVA programs. Hessian and Burlap are open source protocols provided by caucho. Based on HTTP transmission, the server does not need to open firewall ports. The protocol specification is public and can be used in any language. Httpinvoker is a remote communication protocol provided by SpringFramework. It can only be used for communication between JAVA programs, and SpringFramework must be used by the server and client. Web service is the preferred protocol for connecting heterogeneous systems or languages. It uses SOAP for communication and can be used in any language. Many development tools currently support it well. --- SOAP
SOAP is the Simple Object Access Protocol. It is a lightweight Protocol used to exchange XML encoding information. It has three main aspects: XML-envelope defines a framework for describing information content and how to handle content, encodes program objects into XML object rules, and executes Remote Procedure Calls (RPC). SOAP can run on any other transmission protocol. The Web Service allows different systems to call each other in the form of "software-software conversation", breaking the incompatibility between software applications, websites, and various devices, achieve the goal of "seamless Web-based integration.
--- WSDL
Web Service Description Language (WSDL) is a formal description document provided by machines that can be read. It is an XML-based language used to describe Web services and their functions, parameters, and returned values. Because it is based on XML, WSDL is machine readable and human readable.
The test results show that the communication efficiency of several protocols is as follows:RMI is the preferred Remote Call Protocol for JAVA, which is very efficient and stable. Especially when the data volume is large, the gap between RMI and other communication protocols is particularly obvious. HttpInvoker uses java serialization technology to transmit objects, which is essentially the same as RMI. In terms of efficiency, the two are almost the same, and the transmission time of HttpInvoker and RMI is basically the same. Hessian is faster and more efficient than RMI when transmitting a small number of objects, but it is about 20% slower than RMI when transmitting objects with complicated data structures or a large number of data objects. Burlap can only transmit one piece of data at a high speed. Generally, it consumes three times as much time as RMI. The low efficiency of Web Services is well known. On average, the communication time of Web Services is 10 times that of RMI.

Like the assumption, RMI is, of course, the fastest. In almost all cases, RMI is the least. Especially when the data structure is complex and the data volume is large, the gap with other protocols is particularly obvious. In order to give full play to the performance of RMI, the test class is also used. Without Spring, the original RMI form (inheriting UnicastRemoteObject object) is used to provide services and remote calls, compare the efficiency of RMI encapsulated by POJO with Spring. The results show that the two are basically the same, and the services provided by Spring are a little faster. Initially, this is because Spring's proxy and cache mechanisms are relatively powerful, saving time for re-obtaining objects.Caucho's resin server claims to be the fastest server and has a certain popularity in the java field. Hessian is an integral part of resin, and its design is also very simple and efficient. The actual running situation also proves this point. On average, Hessian is about 20% slower than RMI, but it can only be reflected when the data volume is very large and the data structure is very complex, hessian is not slower than RMI. The advantage of Hessian is that it is simple and efficient, can be used across languages, and protocol specifications are made public. We can develop the implementation of the Protocol for any language. Currently, the following languages are available: java, c ++,. net, python, and ruby. There is no delphi implementation yet. In addition, Hessian works very well with WEB servers. With the mature functions of WEB servers, Hessian has a great advantage in processing a large number of concurrent user accesses. In terms of resource allocation and thread queuing, exception Handling can be ensured by mature WEB servers. RMI does not provide multi-threaded servers. In addition, RMI needs to enable the firewall port, not Hessian.Both Burlap and Hessian are open-source products of caucho, except that Hessian uses binary, while Burlap uses xml format. The test results show that Burlap is still acceptable when the data structure is not complex and the data volume is medium. However, if the data volume is large, the efficiency will decrease sharply. In average calculation, the calling time of Burlap is three times that of RMI. I think there are two reasons for its low efficiency: one is that XML data has too many descriptions and the same data structure requires a large amount of transmission; the other is well known, parsing xml is more cost-effective, especially when there is a large amount of data.HttpInvoker is a JAVA Remote Call method provided by SpringFramework. It uses the java serialization mechanism to process object transmission. From the test results, the efficiency is still acceptable, which is basically the same as that of RMI. However, it can only be used for communication between the JAVA language, and requires both the client and the server to use the spring framework. In addition, HttpInvoker has not been tested in practice, and no project has been found to apply the Protocol.In this test, the apache AXIS component is used as the web service implementation, and AXIS is relatively mature and established in the web service field. To test the data transmission, encoding, and decoding time only, the client and the server use the cache, and the object only needs to be instantiated once. However, the test results show that the efficiency of web Services is 10 times slower than that of other communication protocols. If multiple references point to the same object for transmission, the web service will lag behind more. Because RMI, Hessian, and other protocols can transmit references, and how many references a web service has, how many object entities will be copied. Excessive redundant information transmitted by the Web service is one of the reasons for its slow speed. monitoring shows that the same access request describes the same data, and the data volume returned by the web service is 6.5 times that of the hessian protocol. In addition, the processing of WEB Services is also very time-consuming. Currently, the efficiency of xml parser is generally not high, and processing of xml <----> bean is very resource-consuming. From the test results, remote calls are faster than local calls, and it is also explained from the aspect that they are mainly used for encoding and decoding xml files. This is more serious than redundant information. redundant information only occupies network bandwidth, and the resource consumption of each call directly affects the server load capacity. (MS engineers once said that WEB Services cannot load more than 100 concurrent users .) During the test, we also found that the web service encoding is not very convenient. For non-basic types, We need to register serialization and deserialization classes one by one. This is very troublesome, and it is more tiring to generate stub, it is not as smooth and concise as spring + RMI/hessian processing. In addition, the web service does not support the collection type and can only use arrays, which is inconvenient.
References: http://otom31.iteye.com/blog/141043
Http://www.blogjava.net/ducklyl/archive/2008/10/09/154757.html