In the distributed service framework, one of the most basic issues is how remote services communicate. There are many technologies that can achieve remote communication in the Java field, such as: RMI, MINA, ESB, Burlap, Hessian, SOAP, EJB, JMS, etc., what is the relationship between these terms, and what principles are behind them? Understanding these is the basic knowledge for implementing a distributed service framework, and if there are high performance requirements, It is necessary to have a deep understanding of the mechanisms behind these technologies.
To realize communication between network machines, we must first look at the basic principles of computer system network communication. At the underlying level, what network communication needs to do is to convert the stream Transmitting from one computer to another is implemented based on transmission protocols and network IO. Among the more famous transmission protocols are tcp, udp, etc., tcp and udp are all based on the Socket concept and are extended for certain application scenarios. The transmission protocol and network IO mainly include bio, nio and aio. All distributed application communication is implemented based on this principle. Just for the ease of use of the application, various languages usually provide some that are closer to the application. Easy-to-use application layer protocol.
In the final analysis, an enterprise application system is the processing of data. For an enterprise application system with multiple subsystems, its basic support is undoubtedly the processing of messages. . Different from objects, a message is essentially a data structure (of course, an object can also be regarded as a special message). It contains data that can be identified by both the consumer and the service. These data need to be stored in different Passed between processes (machines) and may be consumed by multiple completely different clients. Messaging seems to be better than file passing and remote procedure call (RPC) because it has better platform independence and can support concurrent and asynchronous calls well.
For Web Service and RESTful, it can be regarded as a derivative or encapsulation of messaging technology.
The message mode we often use is the Message Channel mode, as shown in the figure.
The message channel is an indirect layer introduced between the client (Consumer) and the service (Producer), which can effectively dissolve the relationship between the two. of coupling. As long as the message format that both parties need to communicate as well as the mechanism and timing for processing the message are implemented, the consumer can be "ignorant" of the producer. In fact, this model can support multiple producers and consumers. For example, we can let multiple producers send messages to the message channel. Because the consumer is ignorant of the producer, it does not have to consider which producer sent the message.
Although the message channel decouples the producer and consumer, allowing us to expand the producer and consumer arbitrarily, it also introduces their respective dependencies on the message channel, because they The location of the channel resource must be known. To relieve this dependence on the channel, you can consider introducing the Lookup service to find the channel resource. For example, in JMS, you can obtain the message channel Queue through JNDI. To achieve full flexibility, channel-related information can be stored in the configuration file. The Lookup service first obtains the channel by reading the configuration file.
Message channels usually exist in the form of queues. This first-in-first-out data structure is undoubtedly the most suitable for this message processing scenario. Microsoft's MSMQ, IBM MQ, JBoss MQ and open source RabbitMQ and Apache ActiveMQ all implement the Message Channel mode through queues. Therefore, when choosing to use the Message Channel model, it is more necessary to conduct a comprehensive analysis and trade-off of various products that implement this model from the perspective of quality attributes. For example, the message channel's support for concurrency and performance; whether the message channel fully considers error handling; support for message security; and support for message persistence, disaster recovery (fail over), and clustering.
Because the messages transmitted by the channel are often important business data, once the channel becomes a failure point or a security breakthrough point, it will have a catastrophic impact on the system.
The jndi mechanism is also mentioned here. Since JNDI depends on the specific implementation, here we can only explain the jndi implementation of jboss:
In the next After the object instance is bound to the jboss jnp server, when the remote end uses context.lookup() to obtain the remote object instance and starts calling, the implementation method of jboss jndi is to obtain the object instance from the jnp server and serialize it back to the local. Then deserialize locally, and then make class calls locally.
Through this mechanism, you can know that the local must actually have a class bound to the object instance on jboss, otherwise it will definitely fail during deserialization, and remote communication needs to be done It is to perform an action remotely and obtain the corresponding results. It can be seen that remote communication cannot be achieved purely based on JNDI.
But JNDI is also a key technical point in implementing the distributed service framework, because it can be used to achieve transparent remote and local calls, just like ejb. In addition, it is also a good hiding actual deployment mechanism (just Solutions such as datasource).
Once a message channel needs to support multiple consumers, you may face the choice of two models: pull model and Push model. The pull model is initiated by the consumer of the message, and the initiative is in the hands of the consumer, who will initiate a call to the producer according to its own situation. As shown in the figure:
#Another embodiment of the pull model is for the producer to notify the consumer that its state has changed when the state changes. However, the notified consumer will use a callback to obtain more detailed information by calling the passed consumer object.
In a message-based distributed system, the consumer of the pull model usually listens to the channel status regularly in the form of a Batch Job according to a preset time interval. Once a message is found to be delivered, the message will be passed to the real processor (which can also be regarded as a consumer) to process the message and perform related services.
The initiative to push the model is often in the hands of the producer, and the consumer passively waits for notifications from the producer, which requires the producer to know the relevant information of the consumer. As shown in the figure:
#For the push model, the consumer does not need to know the producer. When a producer notifies a consumer, it is often the message (or event) that is delivered, not the producer itself. At the same time, producers can also register different consumers according to different situations, or notify different consumers according to different status changes in the encapsulated notification logic.
Both models have their own advantages. The advantage of the pull model is that it can further relieve consumers of their dependence on the channel and regularly access the message channel through background tasks. The disadvantage is that a separate service process needs to be introduced and executed in the form of Schedule. For the push model, the message channel will actually serve as the subject of consumer observation. Once a message is discovered, the consumer will be notified to process the message. Regardless of the push model or the pull model, for message objects, a mechanism similar to the Observer model may be used to implement consumer subscriptions to producers, so this mechanism is often called the Publisher-Subscriber model , as shown in the figure:
#Normally, publishers and subscribers will be registered on the infrastructure used to propagate changes (that is, the message channel). The publisher will actively understand the message channel so that it can send messages to the channel; once the message channel receives the message, it will actively call the subscribers registered in the channel to complete the consumption of the message content.
For subscribers, there are two ways to process messages. One way is the broadcast mechanism. At this time, when the messages in the message channel are dequeued, the message objects also need to be copied to deliver the messages to multiple subscribers. For example, there are multiple subsystems that need to obtain customer information from the CRM system and perform corresponding processing based on the passed customer information. The message channel at this time is also called the Propagation channel. The other method is a preemption mechanism, which follows a synchronous method, and only one subscriber can process the message at the same time. A message channel that implements the Publisher-Subscriber pattern will select the only currently idle subscriber, dequeue the message, and pass it to the subscriber's message processing method.
Currently, there are many message middlewares that can well support the Publisher-Subscriber mode, such as the MessagePublisher and MessageSubscriber interfaces provided for Topic objects in the JMS interface specification. RabbitMQ also provides its own implementation of this pattern. Although Microsoft's MSMQ has introduced an event mechanism, it can trigger events to notify subscribers when the queue receives a message. But it is not strictly an implementation of the Publisher-Subscriber pattern. NServiceBus, with Microsoft MVP Udi Dahan as the main contributor, further packages MSMQ and WCF and can implement this model well.
Whether it is the Message Channel mode or the Publisher-Subscriber mode, the queue plays a pivotal role in it. However, in enterprise application systems, when the system becomes more and more complex, the performance requirements will also become higher and higher. At this time, the system may need to support the simultaneous deployment of multiple queues and may require distribution. Deploy different queues. These queues can receive different messages according to definition, such as order processing messages, log information, query task messages, etc. At this time, it is not appropriate for message producers and consumers to assume the responsibility of determining the message delivery path. In fact, according to the S single responsibility principle, this kind of responsibility allocation is also unreasonable. It is not conducive to the reuse of business logic, and will also cause coupling between producers, consumers and message queues, thus affecting the expansion of the system.
Since these three objects (components) are not suitable for taking on such responsibilities, it is necessary to introduce a new object specifically responsible for the function of delivering path selection. This is the so-called Message Router pattern , as shown in the figure:
#Through message routing, we can configure routing rules to specify the path of message delivery, and specify the producer corresponding to the specific consumer consumption. For example, specify the routing keyword, and use it to bind a specific queue to the specified producer (or consumer). Routing support provides flexibility in message delivery and processing, and also helps improve the message processing capabilities of the entire system. At the same time, the routing object effectively encapsulates the logic of finding and matching message paths, just like a mediator (Meditator), responsible for coordinating the relationship between messages, queues and path addressing.
Remote service communication, the goal to be achieved is to initiate a request on one computer, and the other machine will process the request accordingly after receiving it and return the result to On the request side, there are request methods such as one way request, synchronous request, asynchronous request, etc. According to the principle of network communication, what needs to be done to achieve this is to convert the request into a stream and transmit it to the remote end through the transmission protocol. The end computer processes the requested stream after receiving it. After the processing is completed, the result is converted into a stream and returned to the calling end through the transmission protocol.
The principle is like this, but for the convenience of application, the industry has launched many application-level protocols based on this principle, so that everyone does not need to directly operate such low-level things, usually application-level remote communication The protocol will provide:
In order to avoid the trouble of doing stream operations directly, a standard transmission format that is easier to use or more suitable for the language will be provided;
The implementation of the network communication mechanism is to complete the conversion of the transmission format into a stream for you, and transmit it to the remote computer through a certain transmission protocol. After receiving the stream, the remote computer converts it into a transmission format and stores it or uses it in a certain way. method to notify the remote computer.
So when learning application-level remote communication protocols, we can study with these questions:
Standard format of transmission What is it?
How to convert the request into a transmitted stream?
How to receive and process streams?
What is the transmission protocol?
However, the application-level remote communication protocol will not make much improvement in the transmission protocol. It mainly focuses on stream operations, allowing the application layer to generate streams and process streams. It is more in line with the language or standard used. As for the transmission protocol, it is usually optional. The well-known ones in the Java field are: RMI, XML-RPC, Binary-RPC, SOAP, CORBA, JMS, HTTP, to be specific. Take a look at these application-level protocols for remote communication.
RMI is a typical remote communication protocol customized for java. We all know that in single vm, we can achieve it by directly calling java object instance Communication, then of course it would be best if this method can be used for remote communication. This remote communication mechanism is called RPC (Remote Procedure Call), and RMI was born towards this goal.
RMI uses stubs and skeletons to communicate with remote objects. The stub acts as the client proxy of the remote object and has the same remote interface as the remote object. The call to the remote object is actually completed by calling the client proxy object stub of the object. Through this mechanism, RMI works as if it is a local job, using TCP/IP protocol, the client directly calls some methods on the server. The advantage is that it is strongly typed and errors can be checked during compilation. The disadvantage is that it can only be based on JAVA language and the client and server are tightly coupled.
Let’s take a look at the principle of a complete remote communication process based on RMI:
The client initiates a request and the request is forwarded to the RMI client. stub class;
The stub class serializes the requested interface, method, parameter and other information;
Serializes the requested information based on socket Stream to server;
The server receives the stream and forwards it to the corresponding skelton class;
The skelton class deserializes the requested information and then calls the actual processing class;
After the processing class completes the processing, the result will be returned to the skelton class;
The Skelton class will serialize the result and send the stream to the client through the socket The stub on the end;
The stub deserializes after receiving the stream and returns the deserialized Java Object to the caller.
Based on the principles, let’s answer several questions that came with the previous study of application-level protocols:
Transmission standards What is the format? is Java ObjectStream.
How to convert the request into a transmitted stream? Convert the requested java object information into a stream based on the Java serialization mechanism.
How to receive and process streams? Start the corresponding listening port according to the adopted protocol. When a stream comes in, the stream is deserialized based on the Java serialization mechanism, and the corresponding processing object information is obtained according to the RMI protocol, called and processed, and the processing is completed. The final result is also returned based on the Java serialization mechanism.
What is the transmission protocol? Socket.
RPC uses C/S mode, adopts http protocol, sends requests to the server, and waits for the server to return the result. The request includes a parameter set and a text set, usually of the form "classname.methodname". The advantage is that it is cross-language and cross-platform, and the C-side and S-side have greater independence. The disadvantage is that it does not support objects and cannot check errors in the compiler, but can only check at runtime.
XML-RPC is also a remote calling protocol similar to RMI. The difference between it and RMI is that it uses standard xml format to define the requested information (requested objects, methods, parameters, etc.) , what are the benefits of this? It can also be used in cross-language communication.
Let’s take a look at a remote communication process of the XML-RPC protocol:
The client initiates a request and fills the request information according to the XML-RPC protocol;
After the filling is completed, the xml is converted into a stream and transmitted through the transmission protocol;
is received and converted into xml after receiving the stream. Obtain the requested information and process it according to the XML-RPC protocol;
After the processing is completed, the result is written into xml according to the XML-RPC protocol and returned.
Similarly answer the question:
What is the standard format for transmission? Standard format of XML.
How to convert the request into a transmitted stream? Convert XML to stream.
How to receive and process streams? Obtain the requested stream through the listening port, convert it into XML, obtain the requested information according to the protocol, process it, and write the result into XML and return it.
What is the transmission protocol? Http.
As you can see from the name, Binary-RPC is similar to XML-RPC. The only difference is that the standard format of transmission is converted from XML. For binary format.
Similarly answer the question:
#What is the standard format for transmission? Standard format binary file.
How to convert the request into a transmitted stream? Convert binary format files into streams.
How to receive and process streams? Obtain the requested stream through the listening port, convert it into a binary file, obtain the requested information according to the protocol, process it and write the result into XML and return it.
What is the transmission protocol? Http.
SOAP originally means Simple Object Access Protocol, which is a lightweight communication protocol for information exchange based on XML for distributed environments. , it can be considered that SOAP is an advanced version of XML RPC. The principles of the two are exactly the same, both are http+XML. The only difference is that the XML specifications defined by the two are different. SOAP is also the service invocation protocol standard adopted by Webservice, so here it is No more elaboration.
The services provided by Web Service are based on web containers. The bottom layer uses the http protocol. It is similar to a remote service provider, such as a weather forecast service. It provides weather forecasts to clients in various places and is a request response mechanism. , is cross-system and cross-platform. It is through a servlet to provide services.
First, the client obtains the WSDL of WebService from the server, and at the same time generates a proxy class (Proxy Class) on the client. This proxy class is responsible for Request and Response with the WebService server. When a data (in XML format) is encapsulated into a SOAP format data stream and sent to the server, a process object will be generated and the SOAP packet received by the Request will be parsed, and then the thing will be processed. After the processing is completed, The calculation result is wrapped in SOAP, and then the package is sent to the client's proxy class (Proxy Class) as a Response. Similarly, the proxy class also parses the SOAP package and performs subsequent operations. This is a running process of WebService.
Web Service is generally divided into 5 levels:
Http transmission channel;
XML data format;
SOAP encapsulation format;
How WSDL is described;
UDDI UDDI is a directory service that enterprises can use to register and search Webservices;
JMS is a means and method to achieve remote communication in the Java field. Remote communication based on JMS is different from RPC, although it can be done The effect of RPC, but because it is not defined from the protocol level, we do not think that JMS is an RPC protocol, but it is indeed a remote communication protocol. There are also things similar to JMS in other language systems, which can be unified The mechanism is called the message mechanism, and the message mechanism is usually a communication mechanism recommended in high-concurrency and distributed fields. The main issue here is fault tolerance.
JMS is a Java message service. JMS clients can transmit asynchronous messages through the JMS service. JMS supports two message models: Point-to-Point (P2P) and Publish/Subscribe (Pub/Sub), namely point-to-point and publish-subscribe model.
Let’s look at the process of a remote communication in JMS:
The client converts the request into a Message that complies with JMS regulations;
Put the Message into the JMS Queue or Topic through the JMS API;
If it is a JMS Queue, it will be sent to the corresponding target Queue. If it is a Topic, then Sent to the JMS Queue subscribed to this Topic.
The processing end obtains the message by polling the JMS Queue. After receiving the message, it parses the Message and processes it according to the JMS protocol.
Similarly answer the question:
What is the standard format for transmission? Message specified by JMS.
How to convert the request into a transmitted stream? Put the parameter information into Message.
How to receive and process streams? JMS Queue is trained in rotation to receive Message. After receiving it, it is processed. After processing, it is still put into the Queue in the form of Message for sending or Multicast.
What is the transmission protocol? No limit.
Based on JMS, it is also one of the commonly used methods to implement remote asynchronous calls.
RPC is cross-language, while RMI only supports Java.
RMI calls remote object methods, allowing methods to return Java objects and basic data types, while RPC does not support the concept of objects. The messages transmitted to the RPC service are represented by external data (External Data Representation , XDR) language representation that abstracts the differences between endian classes and data type structures. Only data types defined by XDR can be passed. It can be said that RMI is an object-oriented Java RPC.
In terms of method invocation, in RMI, the remote interface enables each remote method to have a method signature. If a method is executed on the server, but no matching signature is added to the remote interface, then the new method cannot be called by the RMI client. In RPC, when a request arrives at the RPC server, the request contains a parameter set and a text value, usually in the form of "classname.methodname". This indicates to the RPC server that the requested method is in the class named "methodname". The RPC server then searches for a matching class and method and uses it as input for that method parameter type. The parameter type here matches the type in the RPC request. Once the match is successful, this method is called and the result is encoded and returned to the client.
There is no specification for RPC itself, but the basic working mechanism is the same, namely: serialization/deserialization+stub+skeleton. Broadly speaking, as long as remote calls can be realized, it is RPC. Such as: rmi .net-remoting ws/soap/rest hessian xmlrpc thrift potocolbuffer.
Java provides a complete sockets communication interface, but sockets require the client and server to exchange data using application-level protocol encoding. Using sockets is very troublesome. A protocol that replaces Sockets is RPC (Remote Procedure Call), which abstracts the communication interface for procedure calls, making it as convenient for programmers to call a remote procedure as it is to call a local procedure. The RPC system uses XDR to encode the parameters and return values of remote calls. However, RPC does not support objects, so object-oriented remote invocation RMI (Remote Method Invocation) has become an inevitable choice. Using RMI, calling remote objects is as convenient as calling local objects. RMI uses the JRMP (Java Remote Method Protocol) communication protocol, which is a remote calling method built on the TCP/IP protocol.
Using JMS service, objects are physically moved asynchronously from one JVM on the network to another directly. On a JVM (it is a message notification mechanism), while the RMI object is bound to the local JVM, and only the function parameters and return values are transmitted through the network (it is a request response mechanism).
RMI is generally synchronous, that is to say, when the client calls a method of the Server, it needs to wait until the other party returns before it can continue to execute the client. This process of calling a local method feels like Likewise, this is also a feature of RMI. JMS generally just sends a Message to the Message Server from one point. After sending it, it generally does not care who uses the message. Therefore, generally RMI applications are tightly coupled, while JMS applications are relatively loosely coupled.
RMI transfers serializable java objects over the tcp protocol. It can only be used on java virtual machines, binding languages, and clients. Both the client and the server must be java. Webservice does not have this limitation. Webservice transmits xml text files over the http protocol, regardless of language and platform.
Webservice focuses on remote service invocation, and jms focuses on information exchange.
In most cases, Webservice is a direct interaction between two systems (Consumer Producer), while in most cases, jms is a three-party system interaction (Consumer Producer). Of course, JMS can also implement request-response mode communication, as long as either the Consumer or the Producer also serves as the broker.
JMS can achieve asynchronous calls that completely isolate the client and service provider, and can withstand traffic peaks; WebService services are usually called synchronously and require complex object conversion. Compared with SOAP, now JSON and REST are both It is a good http architecture solution;
JMS is the message specification on the java platform. Generally, a jms message is not an xml, but a java object. Obviously, jms does not consider heterogeneous systems. To put it bluntly, JMS does not consider non-java things. But fortunately, most jms providers (that is, various implementation products of JMS) have solved the heterogeneous problem. Compared with the cross-platform of WebService, each has its own merits.
Currently, the Java field can be used to implement frameworks or libraries for remote communication. The well-known ones are: JBoss-Remoting, Spring-Remoting, Hessian, Burlap, XFire (Axis) , ActiveMQ, Mina, Mule, EJB3, etc., let’s give a brief introduction and evaluation of each. In fact, to build a distributed service framework, you need to have a very deep understanding of these things, because the distributed service framework In fact, it includes solving problems in the distributed field and the application level field.
Of course, you can also implement your own communication framework or library based on the remote network communication principle (transport protocol+Net IO).
So when learning about these remote communication frameworks or libraries, what questions will you bring to the study?
What protocol is it implemented on?
How to initiate a request?
How to convert the request into a format that conforms to the protocol?
What transmission protocol is used for transmission?
What mechanism does the responder use to receive requests?
How to restore the stream to transport format?
How to respond after processing?
Spring-remoting is a remote communication framework provided by Spring in the java field. Based on this framework, ordinary spring beans can also be easily Published in a certain remote protocol, you can also configure the spring bean as a remotely called bean. What protocol is
based on? As a remote communication framework, Spring integrates multiple remote communication libraries to support multiple protocols, such as rmi, http+io, xml-rpc, binary-rpc, etc.
How to initiate a request? In Spring, because it uses proxy implementation for remote calling beans, the request is initiated entirely through the service interface call.
How to convert the request into a format that conforms to the protocol? Spring converts the requested object information into a stream according to the protocol. For example, Spring Http Invoker is implemented based on a protocol defined by Spring itself. The transmission protocol is http, and the request information is converted based on the java serialization mechanism. Transport for streams.
What transmission protocol is used for transmission? Supports multiple transmission protocols, such as rmi, http, etc.
What mechanism does the responder use to receive requests? The responder follows the protocol method to receive requests. For users, they only need to configure ordinary spring beans as the responder or server through the spring configuration method.
How to restore the stream to transport format? Restore according to the protocol.
How to respond after processing? Just return directly after processing, and spring-remoting will do the corresponding serialization according to the protocol method.
Hessian is a remote communication library based on binary-RPC provided by caucho. What protocol is
based on? Implemented based on Binary-RPC protocol.
How to initiate a request? Requests need to be initiated through the API provided by Hessian itself.
How to convert the request into a format that conforms to the protocol? Hessian serializes the request information through its custom serialization mechanism to generate a binary stream.
What transmission protocol is used for transmission? Hessian is transmitted based on the Http protocol.
What mechanism does the responder use to receive requests? The responder receives requests based on the API provided by Hessian.
How to restore the stream to transport format? Hessian deserializes the request information according to its private serialization mechanism, and when it is passed to the user, it is already the corresponding request information object.
How to respond after processing? Return directly after processing, and Hessian serializes the result object and transmits it to the calling end.
Burlap is also provided by caucho. The difference between it and hessian is that it is based on the XML-RPC protocol. What protocol is
based on? Implemented based on XML-RPC protocol.
How to initiate a request? Based on the API provided by Burlap.
How to convert the request into a format that conforms to the protocol? Convert the request information into an XML format that conforms to the protocol and convert it into a stream for transmission.
What transmission protocol is used for transmission? Http protocol.
What mechanism does the responder use to receive requests? Listen to HTTP requests.
How to restore the stream to transport format? Restore according to XML-RPC protocol.
How to respond after processing? The return result is written into XML and returned to the calling end by Burlap.
XFire and Axis are the implementation frameworks of Webservice. WebService can be regarded as a complete SOA architecture implementation standard, so using XFire and Axis is also It means using webservice method. What protocol is
based on? Based on SOAP protocol.
How to initiate a request? Call directly after obtaining the proxy of the remote service.
How to convert the request into a format that conforms to the protocol? Convert the request information into XML format that follows the SOAP protocol, and convert it into a stream for transmission by the framework.
What transmission protocol is used for transmission? Http protocol.
What mechanism does the responder use to receive requests? Listen to HTTP requests.
How to restore the stream to transport format? Restore according to SOAP protocol.
How to respond after processing? The return result is written in XML and returned to the calling end by the framework.
ActiveMQ is an implementation of JMS. It is a good choice to implement remote communication based on a message mechanism such as JMS. After all, the function of the message mechanism itself makes it possible to implement remote communication based on JMS. It can easily implement synchronous/asynchronous/one-way calls, etc., and the message mechanism is also a good choice from the perspective of fault tolerance. This is an important basis for Erlang to be able to achieve fault tolerance. What protocol is
based on? Based on JMS protocol.
How to initiate a request? Follow the JMS API to initiate a request.
How to convert the request into a format that conforms to the protocol? Not sure, I guess it should be a binary stream.
What transmission protocol is used for transmission? Supports multiple transmission protocols, such as socket, http, etc.
What mechanism does the responder use to receive requests? Listen to the port that conforms to the protocol.
How to restore the stream to transport format? Same as question 3.
How to respond after processing? Follow the JMS API to generate messages and write them into the JMS Queue.
Mina is a communication framework provided by Apache. Network IO has not been mentioned before. The frameworks or libraries mentioned before are basically based on BIO, while Mina uses NIO. When the concurrency increases, NIO will have a significant performance improvement compared to BIO, and the improvement of Java performance is closely related to the close integration of NIO and the OS. What protocol is
based on? Based on pure Socket+NIO.
How to initiate a request? Through the Client API provided by Mina.
How to convert the request into a format that conforms to the protocol? Mina follows the java serialization mechanism to serialize the request object.
What transmission protocol is used for transmission? Supports multiple transmission protocols, such as socket, http, etc.
What mechanism does the responder use to receive requests? Listen to the protocol port in NIO mode.
How to restore the stream to transport format? Follow the java serialization mechanism to deserialize the request object.
How to respond after processing? Follow Mina API for return.
MINA is NIO, so there is no doubt that it supports asynchronous calls.
RPC (Remote Procedure Call) is a remote calling protocol. Simply put, it enables applications to call remote methods just like calling local methods. The process or service can be applied in many scenarios such as distributed services, distributed computing, remote service invocation, etc. Speaking of RPC, everyone is familiar with it. There are many excellent open source RPC frameworks in the industry, such as Dubbo, Thrift, gRPC, Hprose, etc. Let's briefly introduce the characteristics of RPC and common remote calling methods, as well as some excellent open source RPC frameworks.
Compared with other remote calling methods, RPC, HTTP, RMI, and Web Service can all complete remote calls, but the implementation methods and focuses are different.
HTTP (HyperText Transfer Protocol) is an application layer communication protocol that uses standard semantics to access specified resources (pictures, interfaces, etc.). The transfer server in the network can Identify the content of the agreement. The HTTP protocol is a resource access protocol through which remote requests can be completed and request results returned.
The advantages of HTTP are simplicity, ease of use, strong understandability and language independence. It is widely used in remote service calls, including Weibo. The disadvantage of HTTP is that the protocol header is heavier, and the link between the general request and the specific server is long, which may include DNS resolution, Nginx proxy, etc.
RPC is a protocol specification. HTTP can be regarded as an implementation of RPC, or HTTP can be applied as the transmission protocol of RPC. The RPC service has a relatively high degree of automation, can realize powerful service management functions, is more friendly when combined with language, and has excellent performance. Compared with HTTP, the disadvantage of RPC is that it is relatively complex and the learning cost is slightly higher.
RMI (Remote Method Invocation) refers to remote method invocation in the Java language. Each method in RMI has a method signature. The RMI client and server pass Method signature for remote method invocation. RMI can only be used in the Java language. You can think of RMI as object-oriented Java RPC.
Web Service is an architectural method for publishing, querying, and invoking services based on the Web, focusing on the management and use of services. Web services generally describe services through WSDL and use SOAP to call services through HTTP.
RPC is a remote access protocol, while Web Service is an architecture. Web Service can also make service calls through RPC, so Web Service is more suitable for comparison with the same RPC framework. When the RPC framework provides service discovery and management and uses HTTP as the transmission protocol, it is actually a Web Service.
Compared with Web Service, the RPC framework can conduct more fine-grained governance of services, including flow control, SLA management, etc., and has greater advantages in microservices and distributed computing.
RPC can be based on HTTP or TCP protocol. Web Service is RPC based on HTTP protocol. It has good cross-platform performance, but its performance is not as good as RPC based on TCP protocol. There are two aspects that will directly affect the performance of RPC, one is the transmission method, and the other is serialization.
As we all know, TCP is a transport layer protocol, HTTP is an application layer protocol, and the transport layer is lower than the application layer. In terms of data transmission, the lower the layer, the faster. Therefore, in general, TCP must be faster than HTTP quick.
In the field of remote communication, there are still quite a lot of knowledge points involved, for example: Communication protocol (Socket/tcp/http/udp/rmi/xml -rpc etc.), message mechanism, network IO (BIO/NIO/AIO), MultiThread, local call and remote call transparent solution (involving Java Classloader, Dynamic Proxy, Unit Test etc.) , asynchronous and synchronous calls, network communication processing mechanisms (automatic reconnection, broadcast, exceptions, pool processing, etc.), Java Serialization (private serialization mechanisms of various protocols, etc.), implementation principles of various frameworks (transmission formats, how to Convert the transport format into a stream, how to convert the request information into a transport format, how to receive the stream, how to restore the stream to the transport format, etc.), which of them you need to be proficient in depends on actual needs. It has been decided. Only when you understand the principles can you make an easy choice. You can even make a private remote communication protocol according to your needs. For those who are engaged in distributed service platforms or develop larger distributed applications, I I feel that at least the knowledge points mentioned above need to be understood.
Related articles:
Java implementation of get, PUT, POST, delete request
Detailed introduction to Java programming common problems summary
Detailed explanation of Java multi-threading basics
The above is the detailed content of Graphical introduction to Java remote communication technology and principle analysis. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
