Spring WebSocket Detailed

Spring WebSocket Detailed
The spring framework supports WebSocket starting with version 4.0, and I'll detail the Spring WebSocket library. The content includes how the spring framework supports WebSocket messaging in Web applications, and how to leverage the STOMP protocol as a sub-protocol to the application layer's protocol--websocket.

1, websocket protocol introduction

The WebSocket protocol is an important feature of the web domain defined by the RFC-6455 specification: Full duplex, which is two-way communication between the client and the server. It's an exciting feature that the industry has been exploring for a long time, using technologies such as Java applets, XMLHttpRequest, Adobe Flash, ActiveXObject, various comet technologies, server-side send events, and more.
It is important to understand that before using the WebSocket protocol, you need to first use the HTTP protocol to build the initial handshake. This relies on a mechanism-building HTTP, requesting protocol upgrades (or protocol conversions). When the server agrees, it responds with an HTTP status code of 101, which indicates consent to switch protocol. Assuming a successful handshake through the TCP socket, the HTTP protocol escalation request passes, and both the client and server side can send messages to each other.

Spring Framework 4.0 and above introduces a new module, the Spring-websocket module. It provides support for WebSocket communications. It is compatible with the Java WebSocket API specification JSR-356, while providing additional functionality

2, websocket the downgrade option

Browser support for the websocket is not fast, ie browser is the 10th edition only started to support. In addition, some proxy tools also restrict websocket communication. Therefore, even if you are developing a websocket application now, the downgrade option is essential to use the simulated WebSocket API to work in an unsupported scenario. The spring framework provides this transparent downgrade scenario-using the SOCKJS protocol. This scenario can be configured to automatically switch without modifying the application's code.

3. Message Communication Architecture

Using WebSocket In addition to the development challenges, there is a difficulty in design considerations.
The rest architecture is now a widely accepted, easy-to-understand architecture for building modern Web applications. The rest architecture relies on many URLs, and several HTTP methods, using the principles of linking, keeping stateless, and so on.
In contrast, the WebSocket app may use only one URL for the initial HTTP handshake. All subsequent messages share this TCP connection, and the message flows in both directions on this connection. This can be seen as completely different from the rest architecture, which is an asynchronous, event-driven, message-passing architecture. The WebSocket architecture is similar to a traditional message transfer scenario, such as JMS, AMQP.

Spring Framework 4.0 introduces a new module,--spring-messaging module, which contains a number of conceptual abstractions from the spring integration project, such as: Message messages, message channels Messagechannel, Message handle MessageHandler and so on. This module also includes a set of annotations that can map messages to methods similar to the spring MVC annotation-based programming model.

4, WebSocket support sub-protocol

WebSocket is simply a messaging architecture that does not specify any specific messaging protocols. It is an ultra-thin layer on the TCP protocol that converts byte streams into message flows (text-to-cargo binary). The message is then interpreted by the application.
Unlike the HTTP protocol, the WebSocket protocol is an application-level protocol that is very simple, does not understand incoming messages, and does not route or process messages. So the WebSocket protocol is the bottom of the application-level protocol, which requires a framework to understand and process messages.
For this reason, the WebSocket RFC defines the use of the sub-protocol. During a handshake, the client and server side can use the Sec-websocket-protocol of the header section to negotiate the sub-protocol used-that is, the more advanced application-level protocol. The use of the sub-Protocol is not required, but even if the sub-protocol is not used, the application still needs to select a message format-a format that allows the client and server to understand each other. This format can be customized, or framework-specific, or use standard messaging protocols.

The spring Framework provides support for using the Stomp Sub-protocol.
stomp,streaming text orientated message Protocol, flow-oriented messaging protocol. Stomp is a simple messaging protocol, a simple text protocol designed for MOM (message oriented middleware, messaging-oriented middleware).
STOMP provides an interoperable connection format that allows the stomp client to interact with any stomp message broker (broker), similar to the Openwire protocol (a binary protocol).

5, what scenario should use WebSocket

In a Web application, WebSocket is appropriate when the client and server side need to exchange events at higher frequencies and with lower latencies. WebSocket is therefore suitable for applications such as finance, gaming, and collaboration.
It may not be appropriate for other scenarios. For example, a news subscription needs to show breaking news, and a long poll with intervals of several minutes is also possible, where the delay is acceptable.
Even in scenarios where low latency is required, if the number of messages transmitted is low (for example, a scenario that monitors network failures), you should consider using long polling techniques.

And only in low-latency and high-frequency message communication scenarios, the choice of WebSocket protocol is very suitable. Even with this scenario, there is still a choice of websocket communication? Or is it choosing rest http communication?
The answer is based on the needs of the application. However, it is also possible to use both techniques to put the data that needs to be exchanged frequently into websocket and to implement the rest API as a procedural business implementation. In addition, when the rest API calls for a message to be broadcast to multiple clients, it can also be implemented through a websocket connection.

The Spring Framework provides @controller comments and @restcontroller annotations, both of which can be used for processing HTTP requests and for handling WebSocket messages. In addition, the request processing method of Spring MVC, or the request handling method of other applications, makes it easy to use the WebSocket protocol to broadcast messages to all interested clients or to specified users.

Spring WebSocket Detailed
The spring framework supports WebSocket starting with version 4.0, and I'll detail the Spring WebSocket library. The content includes how the spring framework supports WebSocket messaging in Web applications, and how to leverage the STOMP protocol as a sub-protocol to the application layer's protocol--websocket.

1, websocket protocol introduction

The WebSocket protocol is an important feature of the web domain defined by the RFC-6455 specification: Full duplex, which is two-way communication between the client and the server. It's an exciting feature that the industry has been exploring for a long time, using technologies such as Java applets, XMLHttpRequest, Adobe Flash, ActiveXObject, various comet technologies, server-side send events, and more.
It is important to understand that before using the WebSocket protocol, you need to first use the HTTP protocol to build the initial handshake. This relies on a mechanism-building HTTP, requesting protocol upgrades (or protocol conversions). When the server agrees, it responds with an HTTP status code of 101, which indicates consent to switch protocol. Assuming a successful handshake through the TCP socket, the HTTP protocol escalation request passes, and both the client and server side can send messages to each other.

Spring Framework 4.0 and above introduces a new module, the Spring-websocket module. It provides support for WebSocket communications. It is compatible with the Java WebSocket API specification JSR-356, while providing additional functionality

2, websocket the downgrade option

Browser support for the websocket is not fast, ie browser is the 10th edition only started to support. In addition, some proxy tools also restrict websocket communication. Therefore, even if you are developing a websocket application now, the downgrade option is essential to use the simulated WebSocket API to work in an unsupported scenario. The spring framework provides this transparent downgrade scenario-using the SOCKJS protocol. This scenario can be configured to automatically switch without modifying the application's code.

3. Message Communication Architecture

Using WebSocket In addition to the development challenges, there is a difficulty in design considerations.
The rest architecture is now a widely accepted, easy-to-understand architecture for building modern Web applications. The rest architecture relies on many URLs, and several HTTP methods, using the principles of linking, keeping stateless, and so on.
In contrast, the WebSocket app may use only one URL for the initial HTTP handshake. All subsequent messages share this TCP connection, and the message flows in both directions on this connection. This can be seen as completely different from the rest architecture, which is an asynchronous, event-driven, message-passing architecture. The WebSocket architecture is similar to a traditional message transfer scenario, such as JMS, AMQP.

Spring Framework 4.0 introduces a new module,--spring-messaging module, which contains a number of conceptual abstractions from the spring integration project, such as: Message messages, message channels Messagechannel, Message handle MessageHandler and so on. This module also includes a set of annotations that can map messages to methods similar to the spring MVC annotation-based programming model.

4, WebSocket support sub-protocol

WebSocket is simply a messaging architecture that does not specify any specific messaging protocols. It is an ultra-thin layer on the TCP protocol that converts byte streams into message flows (text-to-cargo binary). The message is then interpreted by the application.
Unlike the HTTP protocol, the WebSocket protocol is an application-level protocol that is very simple, does not understand incoming messages, and does not route or process messages. So the WebSocket protocol is the bottom of the application-level protocol, which requires a framework to understand and process messages.
For this reason, the WebSocket RFC defines the use of the sub-protocol. During a handshake, the client and server side can use the Sec-websocket-protocol of the header section to negotiate the sub-protocol used-that is, the more advanced application-level protocol. The use of the sub-Protocol is not required, but even if the sub-protocol is not used, the application still needs to select a message format-a format that allows the client and server to understand each other. This format can be customized, or framework-specific, or use standard messaging protocols.

The spring Framework provides support for using the Stomp Sub-protocol.
stomp,streaming text orientated message Protocol, flow-oriented messaging protocol. Stomp is a simple messaging protocol, a simple text protocol designed for MOM (message oriented middleware, messaging-oriented middleware).
STOMP provides an interoperable connection format that allows the stomp client to interact with any stomp message broker (broker), similar to the Openwire protocol (a binary protocol).

5, what scenario should use WebSocket

In a Web application, WebSocket is appropriate when the client and server side need to exchange events at higher frequencies and with lower latencies. WebSocket is therefore suitable for applications such as finance, gaming, and collaboration.
It may not be appropriate for other scenarios. For example, a news subscription needs to show breaking news, and a long poll with intervals of several minutes is also possible, where the delay is acceptable.
Even in scenarios where low latency is required, if the number of messages transmitted is low (for example, a scenario that monitors network failures), you should consider using long polling techniques.

And only in low-latency and high-frequency message communication scenarios, the choice of WebSocket protocol is very suitable. Even with this scenario, there is still a choice of websocket communication? Or is it choosing rest http communication?
The answer is based on the needs of the application. However, it is also possible to use both techniques to put the data that needs to be exchanged frequently into websocket and to implement the rest API as a procedural business implementation. In addition, when the rest API calls for a message to be broadcast to multiple clients, it can also be implemented through a websocket connection.

The Spring Framework provides @controller comments and @restcontroller annotations, both of which can be used for processing HTTP requests and for handling WebSocket messages. In addition, the request processing method of Spring MVC, or the request handling method of other applications, makes it easy to use the WebSocket protocol to broadcast messages to all interested clients or to specified users.

Spring WebSocket Detailed