Java Remote Communication Optional technology and principle

Java remote Communication Optional technology and principle--turn

In the framework of distributed services, one of the most fundamental problems is how remote services communicate, and in the Java domain there are many technologies that can be used for remote communication.

For example: RMI, MINA, ESB, Burlap, Hessian, SOAP, EJB, and JMS, and so on, what is the relationship between these nouns, and what is the rationale behind them?

Understanding these is the basic knowledge of implementing a distributed service framework, and if there is a high performance requirement, it is necessary to understand the mechanics behind these technologies.

In this blog we will explore the future, we welcome you to provide more remote communication technology and principles of introduction.

Basic principle

To realize the communication between network machines, we should first look at the basic principle of network communication in computer system.

At the bottom level, what the network communication needs to do is to transfer the stream from one computer to another, based on the transport protocol and network IO,

The transport protocol is known to have HTTP, TCP, UDP and so on, HTTP, TCP, UDP are defined for a certain type of scenario, the transport protocol,

Network IO, mainly bio, NIO, Aio three ways, all distributed application communications are based on this principle, only for the ease of use of the application, various languages will often provide some more application-friendly application layer protocol.

Application-level protocols

For remote service communication, the goal is to initiate a request on one computer, and another machine to process the request and return the result to the requesting side.

There will be requests such as one way request, synchronous request, asynchronous request and so on, according to the principle of network communication, the need to do is to convert the request into a stream,

Transmitted through the transport Protocol to the far end, the remote computer receives the requested stream after processing, after processing the results into a stream, and through the transport Protocol to return to the caller.

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 people can not go directly to operate such a low level of things, usually application-grade remote communication protocol will provide:

1, in order to avoid direct flow operation so troublesome, provide a more easy-to-use or fit the language of the 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 a transmission format, and to store or in some way notify the remote computer.

So when learning about application-level remote communication protocols, we can learn with these questions:

1. What is the standard format for transmission?

2. How do I convert a request to a streamed stream?

3, how to receive and process the flow?

4. What is the transmission protocol?

However, the application-level remote communication protocol does not make much improvement on the transport protocol, mainly in terms of flow operations,

the process of having the application layer generate flows and process the flow is more closely aligned with the language or standard used , and the transport protocol is usually optional.

Well-known in the Java field are: RMI, Xml-rpc, Binary-rpc, SOAP, CORBA, JMS, to see the application-level protocols for these remote communications:

Rmi

RMI is a typical remote communication protocol for Java customization, and we all know that in a single VM, we can communicate by invoking the Java object instance directly.

In the case of remote communication, if this is the best way to do this, the mechanism of remote communication becomes RPC (remote Procedure call), and RMI is born to this goal.

Consider the principle of a complete remote communication process based on RMI:

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

2, the stub class will request the interface, methods, parameters and other information to serialize;

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 invokes the actual processing class after deserializing the requested information;

6. After processing, the result is returned to the Skelton class;

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

8. The stub is deserialized after it receives the stream and returns the deserialized Java object to the caller.

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

Follow the principles to answer a few questions before learning the application-level protocol:

1. What is the standard format for transmission?

Is the Java Objectstream.

2. How do I convert a request to a streamed stream?

Converts the requested Java object information into a stream based on the Java serialization mechanism.

3, how to receive and process the flow?

According to the protocol used to start the corresponding listening port, when there is a stream into the Java serialization based on the mechanism of the flow to deserialize, and according to the RMI protocol to obtain the corresponding processing object information,

are called and processed, and the results are also returned based on the Java serialization mechanism.

4. What is the transmission protocol?

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 (requested object, method, parameter, etc.) in a standard XML format.

What is the benefit of this is that it can also be used when communicating across languages.

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

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

2. After filling, the XML is transformed into a stream and transmitted through the transmission protocol.

3, received in the received stream after the conversion to XML, according to the 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 XML-RPC protocol.

The above process is illustrated:

To answer the question:

1. What is the standard format for transmission?

XML in standard format.

2. How do I convert a request to a streamed stream?

Converts XML into a stream.

3, how to receive and process the flow?

Gets the requested stream through the listening port, translates to XML, and obtains the requested information according to the protocol, processes it and returns the result to the XML.

4. What is the transmission protocol?

Http.

Binary-rpc

Binary-rpc look at the name to know and Xml-rpc is similar, the difference is only in the transmission of the standard format from XML to binary format.

To answer the question:

1. What is the standard format for transmission?

A binary file in standard format.

2. How do I convert a request to a streamed stream?

Converts binary format files to streams.

3, how to receive and process the flow?

Gets the requested stream through the listening port, translates into a binary file, obtains the requested information according to the protocol, processes it, and returns the result to the XML.

4. What is the transmission protocol?

Http.

Soap

Soap was originally simple Object Access Protocol, a lightweight, XML-based communication protocol for information exchange in a distributed environment.

It can be considered that soap is an advanced version of XML RPC, and that the principles are identical, both http+xml, except that the XML specifications defined by the two are different.

Soap is also a service invocation protocol standard adopted by WebService, so it is not elaborated here.

Corba

Common Object Request Broker Architecture (Common object request Broker [Scheduler] program architecture) is a set of criteria for defining a "distributed Object System",

By the OMG (Object menagement Group) as the initiator and standard-setting unit. The purpose of CORBA is to define a set of protocols in which objects that conform to this protocol can interact with each other.

No matter what language they are written in, no matter what kind of machine or operating system they run on.

CORBA seems to me to be a SOA-like architecture that covers the optional remote communication protocol, but cannot itself be included in the communication protocol here, and CORBA basically obsolete,

In addition to CORBA also do not understand, here will not be elaborated.

Jms

JMS, is the realization of the Java domain remote communication means and methods, based on the JMS implementation of remote communication and RPC is different, although the effect of RPC can be achieved,

But because it's not defined from the protocol level, we don't think of JMS as an RPC protocol, but it's really a remote communication protocol, and there's something like JMS in other language systems,

This kind of mechanism can be called a unified message mechanism, and the message mechanism, usually high concurrency, distributed domain recommended a communication mechanism, the main problem here is fault tolerance (see the Erlang thesis in detail).

Consider the process of a remote communication in JMS:

1. The client translates the request into a message that complies with the JMS provisions;

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

3. If it is 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 side through the rotation JMS Queue, to obtain the message, after receiving the message according to the JMS protocol to parse the message and processing.

Answer the question:

1. What is the standard format for transmission?

The message specified by JMS.

2. How do I convert a request to a streamed stream?

Put the parameter information in the message.

3, how to receive and process the flow?

Rotation a JMS queue to receive a message, receive it for processing, and still send or multicast in the queue as a message after processing is complete.

4. What is the transmission protocol?

Unlimited.

JMS is also one of the common methods of implementing remote asynchronous calls.

Optional implementation Technology

Of course, the above principle does not introduce all the optional remote communication protocols for the Java domain, such as the Ormi that EJB uses, a simple HTTP invoker that spring defines itself, 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: Jboss-remoting, spring-remoting, Hessian, Burlap, XFire (Axis), ActiveMQ, Mina, Mule, EJB3, etc.

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 actually contains the solution of the distributed domain and the 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 what's the problem with learning about the framework or library of these remote communications?

1, is based on what protocol to achieve?

2, how to initiate the request?

3, how to convert the request into a protocol-compliant format?

4. What transport protocol is used for transmission?

5. What mechanism is the response end based on to receive requests?

6. How to restore a stream to a transfer format?

7. How to respond after the processing is finished?

Jboss-remoting

Jboss-remoting is a Java-domain remote communication framework written by JBoss, which makes it easy to implement RPC for Java objects based on a variety of transport protocols.

To answer the question directly:

1, is based on what protocol to achieve?

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

2, how to initiate the request?

In jboss-remoting, you simply pass in the request parameter object that you want to initiate into the Jboss-remoting Invocationrequest object.

You can also package Invocationrequest objects that meet your requirements based on the protocol invocationrequest.

3, how to convert the request into a protocol-compliant format?

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

4. What transport protocol is used for transmission?

Supports multiple transport protocols, such as TCP/IP, HTTP, and so on.

5. What mechanism is the response end based on to receive requests?

The response side simply registers its processing object with the connector object in the server side of the jboss-remoting provided.

6. How to restore a stream to a transfer format?

The jboss-remoting is based on the Java serialization mechanism or JBoss's own serialization implementation to restore the request information to a Java object.

7. How to respond after the processing is finished?

After processing, the result object is returned directly, and Jboss-remoting will serialize the object in accordance with the Protocol and return to the caller.

In addition, jboss-remoting supports a variety of communication methods, such as synchronous/asynchronous/unidirectional communication.

Spring-remoting

Spring-remoting is spring provides the Java domain of the remote communication framework, based on this framework, it can also be very simple to the ordinary spring beans in some kind of remote protocol to the way to publish,

It is also possible to configure a bean that the spring bean is called remotely.

1, is based on what protocol to achieve?

Like Jboss-remoting, as a framework for remote communication, Spring provides support for multiple protocols by integrating multiple remote communication libraries.

such as RMI, Http+io, Xml-rpc, Binary-rpc, and so on.

2, how to initiate the request?

In spring, because of its proxy implementation for a remote invocation of the bean, the originating request is made entirely through the service interface invocation.

3, how to convert the request into a protocol-compliant format?

Spring converts the requested object information into a stream by protocol, for example, Spring HTTP Invoker is based on a protocol that spring itself defines, and HTTP is used on the transport protocol.

The request information is transformed into a stream based on the Java serialization mechanism.

4. What transport protocol is used for transmission?

Supports a variety of transport protocols, such as RMI, HTTP, and so on.

5. What mechanism is the response end based on to receive requests?

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

6. How to restore a stream to a transfer format?

Follow the protocol to restore.

7. How to respond after the processing is finished?

After processing is completed, the spring-remoting will be serialized according to the Protocol method.

Hessian

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

1, is based on what protocol to achieve?

Implementation based on the BINARY-RPC protocol.

2, how to initiate the request?

The request needs to be initiated through the API provided by Hessian itself.

3, how to convert the request into a protocol-compliant format?

The Hessian uses its own serialization mechanism to serialize the request information, resulting in a binary stream.

4. What transport protocol is used for transmission?

The Hessian is transmitted based on the HTTP protocol.

5. What mechanism is the response end based on to receive requests?

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

6. How to restore a stream to a transfer format?

Hessian the request information according to its private serialization mechanism, which is the corresponding request information object when passed to the consumer.

7. How to respond after the processing is finished?

After processing, the Hessian returns the resulting object, which is then serialized and transmitted to the calling end.

Burlap

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

1, is based on what protocol to achieve?

Implementation based on the XML-RPC protocol.

2, how to initiate the request?

Based on the API provided by burlap.

3, how to convert the request into a protocol-compliant format?

Converts the request information into a protocol-compliant XML format and translates it into a stream for transmission.

4. What transport protocol is used for transmission?

HTTP protocol.

5. What mechanism is the response end based on to receive requests?

Listens for HTTP requests.

6. How to restore a stream to a transfer format?

Restore according to the XML-RPC protocol.

7. How to respond after the processing is finished?

The returned results are written to the XML and returned by burlap to the caller.

XFire, Axis

XFire, Axis is the WebService implementation framework, WebService can be considered as a complete SOA architecture implementation standard, so the use of XFire, axis These also means the use of WebService way.

1, is based on what protocol to achieve?

Based on the SOAP protocol.

2, how to initiate the request?

Called directly after obtaining a proxy to the remote service.

3, how to convert the request into a protocol-compliant format?

The request information is converted into an XML format that follows the SOAP protocol, and the framework is transformed into a stream for transmission.

4. What transport protocol is used for transmission?

HTTP protocol.

5. What mechanism is the response end based on to receive requests?

Listens for HTTP requests.

6. How to restore a stream to a transfer format?

Restore based on the SOAP protocol.

7. How to respond after the processing is finished?

The returned results are written to the XML and returned by the framework to the calling side.

ActiveMQ

ACTIVEMQ is the implementation of JMS, based on JMS such a message mechanism to achieve remote communication is a good choice, after all, the function of the message mechanism itself makes it easy to implement synchronous/asynchronous/One-way invocation, etc.

And the message mechanism is a good choice in terms of fault tolerance, which is an important basis for Erlang to do fault tolerance.

1, is based on what protocol to achieve?

Based on the JMS protocol.

2, how to initiate the request?

Follow the JMS API to initiate the request.

3, how to convert the request into a protocol-compliant format?

It is not clear that the conjecture should be a binary stream.

4. What transport protocol is used for transmission?

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

5. What mechanism is the response end based on to receive requests?

Listen for ports that are compliant with the protocol.

6. How to restore a stream to a transfer format?

With question 3.

7. How to respond after the processing is finished?

Follow the JMS API to generate the message and write it to the JMS queue.

Examples of remote communication based on JMS such mechanisms are spring-intergration, Mule, lingo, and so on.

Mina

Mina is the communication framework provided by Apache, which has not previously mentioned the network IO, the framework or library mentioned above is basically bio-based, and Mina is using NIO,

NIO has a significant performance boost compared to bio when concurrency increases, and the improvement in Java performance has little to do with the close integration of NIO and the OS.

1, is based on what protocol to achieve?

Optional transport protocol +nio.

2, how to initiate the request?

The client API provided through Mina.

3, how to convert the request into a protocol-compliant format?

The Mina follows the Java serialization mechanism to serialize the request object.

4. What transport protocol is used for transmission?

Supports multiple transport protocols, such as TCP/IP, HTTP, and so on.

5. What mechanism is the response end based on to receive requests?

The protocol port is monitored in NIO mode.

6. How to restore a stream to a transfer format?

The request object is deserialized by following the Java serialization mechanism.

7. How to respond after the processing is finished?

Follow the Mina API to return.

Mina is the NIO approach, so it is no surprise to support asynchronous invocation.

Ejb

EJB is the most prominent in its distributed, EJB uses the Ormi protocol, and RMI protocol is similar, but EJB in distributed communication security control, transport pool, smart Proxy and so on, so that it is in the distributed field is not negligible force.

1, is based on what protocol to achieve?

Based on the Ormi protocol.

2, how to initiate the request?

EJB call.

3, how to convert the request into a protocol-compliant format?

The request object is serialized by following the Java serialization mechanism.

4. What transport protocol is used for transmission?

Tcp / ip.

5. What mechanism is the response end based on to receive requests?

Listen for protocol ports.

6. How to restore a stream to a transfer format?

The request object is deserialized by following the Java serialization mechanism.

7. How to respond after the processing is finished?

You can return directly to the processing object.

In the previous Distributed Services Framework series of articles on Jndi is misleading suspicion, in this blog also incidentally mention Jndi mechanism, because jndi depends on the specific implementation, here can only be explained under the implementation of JBoss Jndi.

When the object instance is bound to JBoss JNP server, when the remote end obtains the remote object instance in Context.lookup () mode and begins the call, the implementation of JBoss Jndi is to get the object instance from JNP server.

Serialize it back to local, then deserialize locally, and then make the class call locally.

Through this mechanism, we can know that the local actually must have bound to the JBoss object instance class, otherwise deserialization must fail, and the remote communication needs to do is to do a remote operation,

and obtains the corresponding result, can be seen purely based on Jndi is unable to realize the remote communication.

But Jndi is also a key technical point for implementing a distributed service framework, because it allows for transparent remote and local calls, like EJBs,

It is also a good way to hide the actual deployment mechanism (like DataSource).

Summarize

From a series of analysis, we know that in the field of tele-communication, the knowledge points involved are quite many,

For example: Communication protocol or Remote invocation Protocol (TCP/HTTP/UDP/RMI/XML-RPC etc), message mechanism, network IO (Bio/nio/aio), multithread,

A transparent scheme for local invocation and remote invocation (involving Java classloader, Dynamic Proxy, Unit Test etc), asynchronous and synchronous calls,

network communication processing mechanism (automatic re-connect, broadcast, exception, pool processing, etc.), Java serialization (private serialization mechanism of various protocols, etc.),

The implementation principles of various frameworks (transmission format, how to convert the transfer format into a stream, how to convert request information into a transport format, how to receive a stream, how to restore a stream to a transport format, and so on),

To master which of these things, according to the actual needs of the decision, only in the understanding of the principle of the situation can be very easy to make a choice, even according to the requirements of the Private remote communication protocol,

for those of you working on a distributed service platform or developing a larger distributed application, I feel that at least the knowledge points mentioned above need to be better understood .

Java Remote Communication Optional technology and principle