I examined the flow of TCP communication with Spring Integration (client edition)

In order to organize the flow of TCP communication with Spring Integration, I drew a sequence diagram on the client side, although it is complicated.

Pre-stage

It is assumed that ʻautoStartUp is enabled, that is, ʻOutbound Gateway and ConnectionFactory are started when the application is started. That made the starting point strange: confounded :.

1. ʻOutbound Gateway calls the method that sets ConnectionFactory`.
2. ConnectionFactory registers ʻOutboundGateway in Sender/Listener as a sender / receiver (ʻOutboundGateway implements TcpSender / TcpListener). TcpSender is the interface for establishing a connection from the connection factory to send a message, and TcpListener is the interface for receiving the received message from the connection.
3. Set the life cycle of ConnectionFactory to start.

TCP connection (send to host)

1. The Client performs business processing and passes the object to Message Gateway.
2. Convert the object to Message with MessagingTemplate and pass it to ʻOutbound Gateway via ʻAdvisedRequestHandler.
3. ʻOutbound Gateway calls ConnectionFactory` to establish a connection.
4. ConnectionFactory callsbuildNewConnection ()of TcpConnection to establish a new connection. When sharing a connection (single-use = false), check first if there is already a usable connection. Publish an event when a new connection is established.
5. ʻOutbound Gateway holds TcpConnection` in a variable.
6. Create a ʻAsyncRepry` object. This is for checking on the client side whether the received message is associated with the sent message, or for waiting for the sending process until asynchronous reception.
7. Call send of TcpConnection and serialize the message with Serializer and send it to the host.

Called between 6 and 7 if ʻInterceptor` is defined.

TCP connection (received from host)

1. TcpConnection causes MessageMapper to map the received object to the message object.
2. MessageMapper edits the header and returns a message to TcpConnection.
3. TcpConnection passes a message to ʻOutbound Gateway`.
4. ʻOutbound Gateway checks if the received message is tied to what was sent and passes it to ʻAsync Repry.
5. ʻAsyncRepry` receives the message and counts down the latch.
6. Wait until the ʻAsyncRepry latch counts down or times out and returns a message to the ʻOutbound Gateway. Receive processes 1 to 5 are executed asynchronously.
7. If you do not share the connection (single-use = true), close the connection. In this case, an event is issued.
8. ʻOutbound Gateway returns the result in Message Gateway`.
9. Message Gateway returns the result to Client.

If ʻInterceptor is defined, it will be called at 3 before passing the message to ʻOutbound Gateway.

Remarks: Although omitted in the figure, there are Channel and various endpoints between Message Gateway and ʻOutbound Gateway`.

Background to the posting

TCP communication will be performed using Spring Integration in the case, and the purpose of organizing the investigated results is I posted. There are few documents in Japanese, so I hope it helps those who are worried about it: sweat :. (By the way, the Server side does not plan to use Spring Integration in this project, so I will probably post it).

The service used to create the diagram

The figure above was created using a service called WebSequenceDiagrams. You can easily draw a sequence diagram with a script while looking at the sample. You can change the design and output it as an image. If you register your e-mail address, you can also save the data on the site. However, since the output image is low quality and the logo is included in the lower right (it seems that it can be solved by charging), it seems that it can not be used for commercial purposes, but it seems that it can be used to organize ideas.