Analysis of Java remote invocation technology for distributed service architecture

One of the most fundamental issues in a distributed service framework is how remote services communicate, and there are many technologies in the Java domain that enable remote communication, such as RMI, MINA, ESB, Burlap, Hessian, SOAP, EJB, and JMS, What is the relationship between these nouns? What exactly are they based on, knowing that these are the basics of implementing a distributed service framework, and if there is a high performance requirement, the mechanism behind these technologies is essential, and in this blog we will look into the future, We welcome you to provide more information about the technology and principle of remote communication.

Basic principle

To achieve communication between network machines, first of all, to look at the basic principles of computer network communication, at the bottom level to see, network communication needs to do is to transfer the flow from one computer to another computer, based on the transmission protocol and network IO to achieve, where the transport protocol is more famous for HTTP, TCP, UDP, and so on, HTTP, TCP, UDP are for a class of applications defined by the transport Protocol, network IO, mainly bio, NIO, Aio three ways, all the distributed application communication based on this principle, but for the application of ease of use, Languages often offer more user-friendly application layer protocols

Application-level protocols

Remote service communications, the goal to be achieved is to initiate a request on one computer, and the other to process and return the result to the requesting side after receiving the request, in which there are requests such as one way request, synchronous request, asynchronous request, etc., according to the principle of network communication, What needs to be done is to convert the request to a stream, transmit it to the far end through the transfer Protocol, and the remote computer will process it after receiving the requested stream, and after processing, the result is converted to a stream and returned to the caller via the transport protocol.

The principle is this, but for the convenience of application, the industry has introduced a lot of application-level protocols based on this principle, so that everyone can not go directly to the bottom of the things, usually the application-level remote communication protocol will provide:

1, in order to avoid the direct flow of such trouble, to provide a more user-friendly or fitting language standard transmission format;

2, the realization of network communication mechanism, is for you to complete the transfer format into a stream, through some kind of transmission protocol to the remote computer, the remote computer after receiving the stream into the transmission format, and to store or in some way notify the remote computer.

So when learning the application-level remote communication protocol, we can take these questions to learn:

1, the transmission of the standard format is what.

2, how to transform the request into a stream of transmission.

3, how to receive and process the flow.

4, transmission protocol is.

However, the application-level remote communication protocol does not make much of an improvement on the transport protocol, mainly in the flow operation aspect, lets the application layer generate the flow and the processing flow the process to be more fit to use the language or the standard, as far as the transport protocol is usually optional, in the Java domain well-known has: RMI, XML-RPC , Binary-rpc, SOAP, CORBA, and JMS to specifically look at the application-level protocols for these remote communications:

Rmi

RMI is a typical Java-Custom remote communication protocol, and we all know that in a single VM we can communicate by simply calling Java object instance, and if that's the best way to do it in a remote communication, This mechanism of remote communication becomes RPC (remote Procedure call), and RMI was born to this goal.

Take a look at the principle of a complete remote communication process based on RMI:

1, the client initiates the request, requests transmits to the RMI client's stub class;

2, the stub class will request the interface, the method, the parameter and so on the information carries on the serialization;

3, based on TCP/IP the serialized stream is transmitted to the server side;

4, the server side received the stream and forwarded to the corresponding Skelton class;

5. The Skelton class calls the actual processing class after deserializing the requested information;

6, processing class after the completion of the results returned to the Skelton class;

7, Skelton class will result serialization, through TCP/IP will be circulated to the client stub;

8. The stub is deserialized after receiving the stream, returning the deserialized Java object to the caller.

See jboss-remoting for a better illustration of this process:

According to the principle to answer the previous learning application-level protocol with a few questions:

1, the transmission of the standard format is what.

Is the Java Objectstream.

2, how to transform the request into a stream of transmission.

Based on the Java serialization mechanism, the requested Java object information is transformed into a stream.

3, how to receive and process the flow.

According to the protocol to start the corresponding listening port, when there is a stream into the Java serialization mechanism after the flow of deserialization, and according to the RMI protocol to obtain the corresponding processing object information, the call and processing, the results of the processing is also based on the Java serialization mechanism to return.

4, transmission protocol is.

Tcp / ip.

XML-RPC

XML-RPC is also a remote invocation protocol similar to RMI, which differs from RMI in that it defines the requested information (the requested object, method, parameter, etc.) in a standard XML format, which is useful when communicating across languages.

Look at a remote communication process for the XML-RPC protocol:

1, the client initiates the request, according to the XML-RPC protocol will fill the request information;

2, after filling the XML into a stream, through the transmission protocol for transmission;

3, receive the stream after receiving the conversion to XML, according to XML-RPC protocol to obtain the requested information and processing;

4. After processing, the results are written in XML and returned in accordance with the RPC protocol.

Diagram the above procedure:

To answer the same question:

1, the standard format of transmission is.

XML in standard format.

2, how to transform the request into a stream of transmission.

Converts XML into a stream.

3, how to receive and process the flow.

Gets the requested stream through the listening port, converts it to XML, obtains the requested information based on the protocol, processes it, and returns the result to the XML.

4, transmission protocol is.

Http.

Binary-rpc

BINARY-RPC's name is known to be similar to XML-RPC, except that the standard format for transport is transformed from XML into binary format.

To answer the same question:

1, the standard format of transmission is.

A binary file in a standard format.

2, how to transform the request into a stream of transmission.

Converts a binary format file to a stream.

3, how to receive and process the flow.

Gets the requested stream through the listening port, converts it to a binary file, obtains the requested information based on the protocol, processes it, and returns the result to the XML.

4, transmission protocol is.

Http.

Soap

SOAP is intended for simple Object Access Protocol, a lightweight, xml-based communication protocol for information exchange in a distributed environment, and the idea that soap is an advanced version of XML RPC is identical in principle to Http+xml, Unlike the different XML specifications defined by the two, soap is also the standard for service invocation protocols that WebService uses, so it is not explained here.

Corba

Common Object Request Broker Architecture (Common Object Solicitation Agent [dispatch] program architecture) is a set of criteria for defining "distributed object Systems" by the OMG (Object Menagement Group) As a initiating and standard-setting unit. The purpose of CORBA is to define a set of protocols that allow objects to interact with each other, regardless of the language in which they are written, regardless of the machine or operating system in which they are run.

CORBA, in my view, is an SOA-like architecture that covers optional remote communication protocols, but it cannot be included in the communication protocol itself here, and CORBA Basic elimination, coupled with a little understanding of CORBA, this will not be elaborated.

Jms

What about JMS, is a way to implement remote communication in the Java domain, based on JMS to achieve remote communication and RPC is different, although the effect can be achieved, but because it is not defined from the protocol level, so we do not think that JMS is an RPC protocol, but it is a remote communication protocol, In other language systems, there are also things like JMS, which can be unified as the message mechanism, and the message mechanism, usually a high concurrency, distributed domain recommendation of a communication mechanism, where the main problem is fault tolerance (see Erlang paper).

To see the process of a remote communication in JMS:

1. The client converts the request into a message in accordance with the JMS regulations;

2. Put the message into JMS queue or topic through the JMS API;

3, if a JMS queue, the corresponding target Queue in the send, such as topic, is sent to the JMS queue subscribed to this topic.

4, the processing end through the rotation JMS Queue, to obtain messages, received messages in accordance with the JMS protocol to resolve the message and processing.

Answer the question:

1, the standard format of transmission is.

The message that the JMS prescribes.

2, how to transform the request into a stream of transmission.

Put the parameter information in the message.

3, how to receive and process the flow.

Rotation JMS queue to receive message, receive after processing, after processing is still in the way of messages into the queue sent or multicast.

4, transmission protocol is.

Unlimited.

JMS is also one of the common ways to implement remote asynchronous calls.

Optional implementation Technology

Of course, the above principle does not introduce all of the optional remote communication protocols in the Java domain, such as the ormi of the EJB, the simple HTTP invoker defined by spring, and so on.

After reading the principle, we will take a look at the current Java domain can be used to implement remote communication framework or library, well-known are: Jboss-remoting, spring-remoting, Hessian, Burlap, XFire (Axis), ActiveMQ, Mina, Mule, EJB3 and so on, to do a simple introduction and evaluation of each, in fact, to do a distributed service framework, these things are to have a very deep understanding, because the distributed service framework is actually involved in solving the distributed domain and application level of two aspects of the problem.

Of course, you can also implement your own communication framework or library based on the principle of Remote network communication (transport Protocol+net IO).

So when you understand the framework or library of these remote communications, what problems will you learn?

1, is based on what protocol to achieve.

2, how to initiate the request.

3, how to convert the request to conform to the format of the agreement.

4, use what transmission protocol transmission.

5, the response end based on what mechanism to receive requests.

6, how to restore the stream to the transmission format.

7, how to respond after the completion of processing.

Jboss-remoting

Jboss-remoting is a Java domain Remote communication framework written by JBoss, based on which the RPC of Java objects based on multiple transport protocols can be implemented very simply.

To answer the question directly:

1, is based on what protocol to achieve.

Jboss-remoting is a communication framework, so it supports communication in a variety of protocol modes, such as Tcp/ip+io mode, RMI mode, Http+io mode, etc.

2, how to initiate the request.

In jboss-remoting, you simply pass the request parameter object that you want to launch into the Jboss-remoting Invocationrequest object, It is also based on the protocol that Invocationrequest packages meet the requirements of Invocationrequest objects.

3, how to convert the request to conform to the format of the agreement.

Jboss-remoting the request into an object byte stream based on the Java serialization mechanism or JBoss's own serialization implementation.

4, use what transmission protocol transmission.

Supports a variety of transport protocols, such as TCP/IP, HTTP, and so on.

5, the response end based on what mechanism to receive requests.

The response side simply registers its processing object with the connector object on the server side provided by Jboss-remoting.

6, how to restore the stream to the transmission format.

Jboss-remoting restores request information to Java objects based on the Java serialization mechanism or JBoss's own serialization implementation.

7, how to respond after the completion of processing.

After processing, the result object is returned directly, and Jboss-remoting will serialize the object by protocol and return to the caller.

In addition, jboss-remoting supports multiple modes of communication, such as synchronous/asynchronous/one-way communications.

Spring-remoting

Spring-remoting is the remote communication framework that spring provides for the Java domain, and it is also possible to simply publish the normal spring Bean as a remote protocol, as well as configure the bean that the spring bean is called remotely.

1, is based on what protocol to achieve.

Like Jboss-remoting, as a framework for remote communications, spring enables the support of multiple protocols, such as RMI, Http+io, XML-RPC, BINARY-RPC, and so on, by integrating a variety of remote communications library.

2, how to initiate the request.

In spring, because it uses a proxy implementation for a remote-invoked bean, the originating request is simply the way it is invoked through the service interface.

3, how to convert the request to conform to the format of the agreement.

Spring translates the requested object information into a stream by protocol, for example, Spring HTTP Invoker is based on a protocol defined by spring itself, which is Http based on the Transfer Protocol, and the request information is transformed into a stream for transmission using the Java serialization mechanism.

4, use what transmission protocol transmission.

Supports multiple transport protocols, such as RMI, HTTP, and so on.

5, the response end based on what mechanism to receive requests.

The response side follows the protocol to receive the request, and for the consumer, simply configure the normal spring bean as the response side or the service side through spring configuration.

6, how to restore the stream to the transmission format.

Restore in accordance with the Protocol.

7, how to respond after the completion of processing.

After processing the direct return can be, spring-remoting will be based on the protocol to do the corresponding serialization.

Hessian

Hessian is a remote communication library based on the BINARY-RPC implementation provided by Caucho.

1, is based on what protocol to achieve.

Implemented based on BINARY-RPC protocol.

2, how to initiate the request.

Requests are initiated through the APIs provided by Hessian itself.

3, how to convert the request to conform to the format of the agreement.

Hessian uses its custom serialization mechanism to serialize request information and produce binary streams.

4, use what transmission protocol transmission.

Hessian is transmitted based on the HTTP protocol.

5, the response end based on what mechanism to receive requests.

The response side receives the request based on the API provided by Hessian.

6, how to restore the stream to the transmission format.

Hessian to deserialize the request information according to its proprietary serialization mechanism and is already the corresponding request information object when passed to the consumer.

7, how to respond after the completion of processing.

Returns directly after processing, hessian the result object to the caller.

Burlap

Burlap is also provided by Caucho, which differs from Hessian in that it is based on an XML-RPC protocol.

1, is based on what protocol to achieve.

Implementation based on XML-RPC protocol.