We strongly recommend using Hessian/burlap as a remote service solution within the J2EE distributed system.

In a J2EE distributed system, we need to select a remote service protocol for interaction between distributed processes. Optional protocols such as EJB and soap-based Web services are also primitive such as RMI and socket. However, I recently learned about the Hessian/burlap solution of Caucho. I think this solution is the most suitable, Because it does not have the disadvantages of the other solutions described above And, if we use Hessian/burlap in combination with spring, the designers will feel extremely convenient.

Next we will talk about these "bad" Solutions one by one, and then introduce Hessian/burlap solutions.

A.EJB. Needless to say, the EJB is extremely heavy, the configuration will be exhausted, and the performance will be poor.

B.Soap-based Web Service. Has the same disadvantages as EJB. It is very troublesome to declare a service, and it will waste a lot of bandwidth to transmit data using the SOAP protocol. Because soap is based on XML, most of the data in XML is not necessarily business data, but only metadata.

C.RMI. If used in combination with spring, configuration is not troublesome. However, its service interfaces are restricted (the java. RMI. remote interface must be inherited), and the RMI service can only use port 1109.

D. socket . This should be the most reassuring protocol for Program Members, because programmers can do whatever they want. But there are two costs:
I. There are many underlying and fundamental things to do. For example, programmers have to hand over the annoying socket client and server Code , and directly deal with underlying classes such as socket, inputstream, and outputstream; to manually implement security, concurrency, transcoding, logging, and other functions, the socket server should also be started through an independent main program, rather than being put into the J2EE server product operation, that is to say, the monitoring function of the J2EE server cannot be used.
II. design the Message Specification for intercommunication When socket interaction is used. This is a very tiring job. Packets must be grouped and reported in a unified manner, and the packets must not cause ambiguity. When the remote service interface is changed, the message may be greatly changed. For example, if a field is inserted in the original message, the positions of the fields after the field must be moved back. In this way, the Group report and return code may all be changed.

E.Hessian/burlap. Its advantage is to solve the shortcomings of the above solutions.
I.Ease of use. It is very convenient. services do not need to inherit any strange interfaces, and there is not much configuration. You only need to package them into a Servet. When combined with the spring injection mechanism, the client and server will be very comfortable.
II.Good performance. Burlap also uses XML to transmit data, but it is much simpler than soap. Hessian is a binary protocol, which saves more bandwidth.
III. It is alsoBased on HTTPIt can penetrate the firewall. In fact, it is also a web service protocol,
Iv. As a programmerRemoves the need for underlying and basic work.. Because it is a servlet, underlying work, such as input and output streams, concurrency, logs, and other tasks can be handed over to ready-made servers such as Tomcat; with the application server, you can also obtain other functions, such as monitoring and cluster. You can also configure the user name and password, and the security work is also done.

V.No design Packet. Because the service on the server side is exposed to the client in the Java method. The Java method is easy to implement without ambiguity, and changing the signature is also very simple (for example, eclipse has such a refactoring function), which is much better than the socket packet.

To sum up, there is no reason not to select the Hessian/burlap solution.