Distributed service framework

Distributed service framework I. Introduction:

The importance of distributed services in enterprise applications is no longer mentioned. This article describes the basic network communication principles, application-level remote communication protocols, and popular distributed service frameworks involved in the distributed service framework, so as to gain an overall understanding of the distributed service framework.

Ii. Basic principles of network communication:

In terms of meaning, network communication needs to transmit data from one machine to another to achieve the purpose of communication between multiple machines. The specific network transmission mode is based on the transmission protocol and network Io. Common transmission protocols include HTTP, TCP, and UDP. HTTP, TCP, and UDP are also extended transmission protocols based on the socket concept for certain application scenarios. There are three main network Io Methods: bio, NiO, and AIO. All distributed communication protocols should be implemented based on this principle.

3. Application-level Remote Communication Protocol:

In the basic principle of network communication transmission, the transmitted data needs to be converted into a stream and transmitted to another computer through a certain protocol. After the remote computer receives the stream, it needs to be reversed to the correct data, after data is processed, the caller's computer is responded in the same way.

The emergence of the distributed service framework is to encapsulate complicated Stream Conversion and replace it with a new standard transmission protocol that is easier to use and understand. However, when learning the distributed service framework, you also need to consider the following issues:

1. Standard Format of Data Transmission

2. Basic data transmission protocols

3. Conversion between data and stream

4. Accept and process the stream

The new standard protocols used by the distributed service framework are discussed as follows.

1. RMI

Java Remote Method invocation is an application programming interface used to implement Remote Procedure Calls. It allows programs running on the client to call objects on the remote server.

The following describes the RMI-based remote communication process and principles.

1.1 The client initiates a request and transfers the request to the stub class of the RMI client;

1.2 stub class serializes the requested interfaces, methods, parameters, and other information;

1.3 transmit serialized objects to the server based on socket;

1.4 The server converts the received serialized stream to the corresponding Skelton class;

1.5 The Skelton class deserializes request information and calls the actual processing class;

1.6 return the result to the Skelton class after processing the class;

1.7 Skelton serializes the result and uses Socket to distribute the result to the stub class of the client;

1.8 stub class returns the result deserialization object to the caller.

The following figure shows the process of JBoss-remoting.

Question:

1.1 Standard Data Transmission Format

Java objectstream, so the request parameters need to be serialized.

1.2 Basic data transmission protocol

Socket

1.3 conversion between data and stream

The Java-based serialization mechanism converts request and response objects into streams.

1.4 accept and process the stream

The Port Number of the response listened by the program. However, after a stream enters, the stream is deserialized Based on the Java serialization mechanism, and corresponding server processing objects are obtained based on the RMI protocol for calling and processing, after processing is complete, data is also returned to the client based on the Java serialization mechanism.

Disadvantages:

1.1 is not cross-language and only supports communication between Java programs.

1.2 RMI can communicate only through the RMI protocol and cannot be accessed through the HTTP protocol, and cannot penetrate the firewall.

1.3 Distributed Transaction JTA is not supported.

1.4 The RMI framework has limited support for security, transactions, and scalability.

2. XML-RPC

XML-RPC (XML Remote Procedure Call is XML remote method call) is a set of programs running in different operating systems, different environments, based on internet process call specification, this Remote Procedure Call uses HTTP as the transmission protocol and XML as the encoding format for transmitting information, which can be implemented across platforms and languages.

Next let's look at the remote communication process of the XML-RPC.

1.1 The client initiates a request to fill in the request information according to the XML-PRC protocol;

1.2 after filling, the XML is converted into a stream and transmitted over HTTP;

1.3 after receiving the stream, the server converts it to XML, obtains the request information according to the XML-RPC protocol, and calls the processing class for processing;

1.4 after the server completes processing, it writes the results into XML and returns the results according to the XML-RPC protocol.

Question:

1.1 Standard Data Transmission Format

Standard XML format.

1.2 Basic data transmission protocol

HTTP

1.3 conversion between data and stream

Converts XML into a stream.

1.4 accept and process the stream

Obtain the XML stream through the listening port, convert it to XML, and obtain processing and other information based on the protocol. Call the processing class and write the result into XML, and return the result in the same way.

Disadvantages:

1.1 The XML-RPC can send fewer data types, but the message size is huge.

1.2 XML-RPC lacks important security mechanisms and robust object models.

3. Binary-RPC

Binary transfer protocol. Look at the name to know and XML-RPC almost, the difference is only in the standard format of the transfer from XML to binary format.

Question:

1.1 Standard Data Transmission Format

Binary files in standard format.

1.2 Basic data transmission protocol

HTTP.

1.3 conversion between data and stream

Converts a binary file to a stream for transmission.

1.4 accept and process the stream

The server obtains the request stream through the listening port, converts it to a binary file, and obtains processing information based on the protocol. The server calls the processing class and writes the result to XML for return.

Disadvantages:

1.1 lack of security mechanisms and transmission is not encrypted.

1.2 difficult to locate Hessian exception information. The client sometimes throws an exception during transmission of the contact time type (timestamp, which indicates the full retention time of the database). It is difficult to locate the exception information according to Hessian prompts. It took a long time to find out: in hessian jar's javasesrializier class, there was no short-selling judgment on the time conversion, resulting in a null pointer exception. After packaging, the original exception information was lost.

Try {

Java. util. Date = (Java. util. Date) in. readobject ();

Value = newjava. util. timestamp (date. gettime ));

}

Catch (exception e ){....}

4. Soap

Simple Object Access Protocol (SOAP) is a lightweight communication protocol for information exchange based on XML in a distributed environment. A soap message is an XML document that contains a required soap encapsulation package, an optional SOAP message header, and a required SOAP message body. HTTP is used at the underlying layer of soap to allow cross-platform and cross-language communication.

5. CORBA

The Common Object Request Broker Architecture (the Common Object Request proxy reminder structure) is a set of standards used to define the "Distributed Object System. A set of protocols is defined in the CORBA. objects that comply with the Protocol can interact with each other and have language independence.

CORBA model:

Object services: Object services are used by distributed objects. The server publishes an available service and provides the application domains accessible to the client. The domain objects in the method 2 are provided by the Naming Service and the trading service. The naming service is used by the client to access the service through the domain name. The trading services client accesses the service based on its own properties.

Common Facilities: a series of services that can be shared by multiple applications.

Domain interfaces (domain Interface): domain interfaces are similar to object services and public components and are mainly designed for specific application domains.

Application interfaces (application interface ):

Architecture diagram of corba orb:

Disadvantages:

1.1 CORBA cannot penetrate the firewall. The configuration of the listener port on the client is complex if you want to penetrate the firewall.

1.2 CORBA is too complicated.

6. JMS

Message mode of Java Message Service

1.1 Point to Point messaging)

This model only transmits information to one receiver. The PTP message passing application uses the named queue to send messages. The queue sends messages to a specific queue. The queue receiver obtains messages from a specific queue. A queue can have multiple senders and receivers, but only one message is delivered to one queue receiver. If multiple queue recipients listen to messages in the queue, different implementations use different algorithms to determine which receiver gets the message. For example, WebLogic JMS uses the "first-to-First" algorithm. If no queue receiver listens to the queue, the message is retained in the message queue until the queue receiver obtains the queue.

Queue: A Message Queue named by the message provider. The message receiver uses this name to obtain the message.

Queue connection Factory (queueconnectionfactory): the receiver uses this queue to connect the factory to create a connection queue (connectionqueue). The connection queue is used to obtain the connection with the JSM point-to-point message sender.

Connectionqueue: the active connection queue exists between the message provider and the message receiver, and the receiver uses it to create one or more JMS Message Queue SESSION (queuesession ).

Queuesession: used to create the sender and receiver of a message queue ).

Message sender (queuesender or messageproducer): sends a message to a declared queue.

Message Receiver (queuereceiver or messageconsumer): receives messages that have been sent to the specified queue.

 

1.2 publish and subscribe Mode)

This model supports passing a message to multiple subscribers. This model runs multiple topic subscribers to receive the same message. JMS keeps the message until all topic subscribers receive the message.

Topic: a topic object named by the message sender. The Subscriber obtains the topic object based on the topic name.

Topic connection Factory (topicconnectionfactory): The Subscriber creates a connection topic (connectiontopic) based on the topic link factory to obtain the link with the JMS message pub/sub publisher.

Connectiontopic: the link topic of an activity exists between the publisher and the subscriber.

Topic Session: used to create the topic message publisher (topicpublisher) and subscriber (topicsubscriber ).

Messageproducer: sends a message to a declared topic.

Messagecustomer: receives messages that have been sent to a specified topic.

Disadvantages:

Security, transaction processing, and scalability problems may occur. For a simple JMS client, you can only outsource security and transaction processing to a vendor, that is, these problems will be handled in a vendor-specific manner. If your simple JMS client needs to process incoming messages and send messages, it will encounter scalability problems. JMS does not have a built-in mechanism to process more than one incoming request at a time. To support concurrent requests, you need to expand the JMS client to generate multiple threads or start multiple JVM instances so that these threads or instances can run applications separately. In addition, you also need to configure the JMS provider to have multiple subscribers on some appropriate destinations. At this time, you will question whether the simple JMS client solution is actually simple.

 

Iv. distributed service framework: 1. RMI

The above has been introduced. For specific code implementation, see distributed service framework RMI.

2. CORBA

The above has been introduced. For more information about code implementation, see distributed service framework-CORBA.

3. Hessian

Hessian converts a network transmission object to a binary file that passes through the HTTP protocol and uses the binary-PRC protocol. Can penetrate the firewall. Hessian is a lightweight remoting on HTTP tool. It is easy to use and can be combined with spring for perfection.

Disadvantages:

Hessian uses its own serialization mechanism to implement grouping aller and ungrouping aller. Therefore, the supported data types are limited and complex types are not supported.

For Hessian code implementation, see Hessian in distributed service framework.

4. httpinvoker

Httpinvoker is a remote communication protocol provided by spring. The Java serialization mechanism is used to process object transmission.

Disadvantages:

1.1 can only be used for communications between Java programs.

1.2 springframework must be used for the server and client.

For code implementation of spring httpinvoker, see httpinvoker in distributed service framework.

5. Axis

Apache axis is an open-source, soap-based WebService architecture.

For specific code implementation, see Axis of distributed service framework.

6. Active MQ

Apache activemq is implemented based on JMS.

For specific code implementation, see activemq in distributed service framework.

V. end:

1. In the distributed service framework, the server often needs to verify the validity of the request parameters sent by the client. Can the server abstract Interface Verification common methods. For example, you can perform required parameter verification, numeric type verification, time type verification, dependency verification, and valid value set verification through Java generic.

2. Introduction to common distributed service framework code implementation is being summarized. Please wait.