Starting with version 4.1 Spring Integration has introduced WebSocket support. It is based on architecture, infrastructure and API from the Spring Framework’s web-socket module. Therefore, many of Spring WebSocket’s components (e.g. SubProtocolHandler or WebSocketClient) and configuration options (e.g. @EnableWebSocketMessageBroker) can be reused within Spring Integration. For more information, please, refer to the Spring Framework WebSocket Support chapter in the Spring Framework reference manual.

@MessagingGateway
@Controller
public interface WebSocketGateway {

    @MessageMapping("/greeting")
    @SendToUser("/queue/answer")
    @Gateway(requestChannel = "greetingChannel")
    String greeting(String payload);

}

Since the WebSocket protocol is streaming by definition and we can send and receive messages to/from a WebSocket at the same time, we can simply deal with an appropriate WebSocketSession, regardless of being on the client or server side. To encapsulate the connection management and WebSocketSession registry, the IntegrationWebSocketContainer is provided with ClientWebSocketContainer and ServerWebSocketContainer implementations. Thanks to the WebSocket API and its implementation in the Spring Framework, with many extensions, the same classes are used on the server side as well as the client side (from a Java perspective, of course). Hence most connection and WebSocketSession registry options are the same on both sides. That allows us to reuse many configuration items and infrastructure hooks to build WebSocket applications on the server side as well as on the client side:

//Client side
@Bean
public WebSocketClient webSocketClient() {
    return new SockJsClient(Collections.singletonList(new WebSocketTransport(new JettyWebSocketClient())));
}

@Bean
public IntegrationWebSocketContainer clientWebSocketContainer() {
    return new ClientWebSocketContainer(webSocketClient(), "ws://my.server.com/endpoint");
}

//Server side
@Bean
public IntegrationWebSocketContainer serverWebSocketContainer() {
    return new ServerWebSocketContainer("/endpoint").withSockJs();
}

The IntegrationWebSocketContainer is designed to achieve bidirectional messaging and can be shared between Inbound and Outbound Channel Adapters (see below), can be referenced only from one of them (when using one-way - sending or receiving - WebSocket messaging). It can be used without any Channel Adapter, but in this case, IntegrationWebSocketContainer only plays a role as the WebSocketSession registry.

The WebSocketInboundChannelAdapter implements the receiving part of WebSocketSession interaction. It must be supplied with a IntegrationWebSocketContainer, and the adapter registers itself as a WebSocketListener to handle incoming messages and WebSocketSession events.

For WebSocket _sub-protocol_s, the WebSocketInboundChannelAdapter can be configured with SubProtocolHandlerRegistry as the second constructor argument. The adapter delegates to the SubProtocolHandlerRegistry to determine the appropriate SubProtocolHandler for the accepted WebSocketSession and to convert WebSocketMessage to a Message according to the sub-protocol implementation.

The WebSocketInboundChannelAdapter accepts and sends to the underlying integration flow only Message s with SimpMessageType.MESSAGE or an empty simpMessageType header. All other Message types are handled through the ApplicationEvent s emitted from a SubProtocolHandler implementation (e.g. StompSubProtocolHandler).

On the server side WebSocketInboundChannelAdapter can be configured with the useBroker = true option, if the @EnableWebSocketMessageBroker configuration is present. In this case all non-MESSAGE Message types are delegated to the provided AbstractBrokerMessageHandler. In addition, if the Broker Relay is configured with destination prefixes, those Messages, which match to the Broker destinations, are routed to the AbstractBrokerMessageHandler, instead of to the outputChannel of the WebSocketInboundChannelAdapter.

If useBroker = false and received message is of SimpMessageType.CONNECT type, the WebSocketInboundChannelAdapter sends SimpMessageType.CONNECT_ACK message to the WebSocketSession immediately without sending it to the channel.

For more configuration options see Section 35.5, “WebSockets Namespace Support”.

The WebSocketOutboundChannelAdapter accepts Spring Integration messages from its MessageChannel, determines the WebSocketSession id from the MessageHeaders, retrieves the WebSocketSession from the provided IntegrationWebSocketContainer and delegates the conversion and sending WebSocketMessage work to the appropriate SubProtocolHandler from the provided SubProtocolHandlerRegistry.

On the client side, the WebSocketSession id message header isn’t required, because ClientWebSocketContainer deals only with a single connection and its WebSocketSession respectively.

To use the STOMP sub-protocol, this adapter should be configured with a StompSubProtocolHandler. Then you can send any STOMP message type to this adapter, using StompHeaderAccessor.create(StompCommand...) and a MessageBuilder, or just using a HeaderEnricher (see Section 7.2.2, “Header Enricher”).

For more configuration options see below.

Spring Integration WebSocket namespace includes several components described below. To include it in your configuration, simply provide the following namespace declaration in your application context configuration file:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:int="http://www.springframework.org/schema/integration"
  xmlns:int-websocket="http://www.springframework.org/schema/integration/websocket"
  xsi:schemaLocation="
    http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/integration
    http://www.springframework.org/schema/integration/spring-integration.xsd
    http://www.springframework.org/schema/integration/websocket
    http://www.springframework.org/schema/integration/websocket/spring-integration-websocket.xsd">
    ...
</beans>

<int-websocket:client-container>

<int-websocket:client-container
                	id=""  
                	client=""  
                	uri=""  
                	uri-variables=""  
                	origin=""  
                	send-time-limit=""  
                	send-buffer-size-limit=""  
                	auto-startup=""  
                	phase="">  
                <int-websocket:http-headers>
                	<entry key="" value=""/>
                </int-websocket:http-headers>  
</int-websocket:client-container>

<int-websocket:server-container>

<int-websocket:server-container
					id=""  
					path=""  
					handshake-handler=""  
					handshake-interceptors=""  
					decorator-factories=""  
					send-time-limit=""  
					send-buffer-size-limit=""  
					allowed-origins="">  
				  <int-websocket:sockjs
						client-library-url=""   
						stream-bytes-limit=""   
						session-cookie-needed=""   
						heartbeat-time=""   
						disconnect-delay=""   
						message-cache-size=""   
						websocket-enabled=""   
						scheduler=""   (16)
						message-codec=""   (17)
						transport-handlers=""  (18)
						suppress-cors="true"="" />  (19)
</int-websocket:server-container>

<int-websocket:outbound-channel-adapter>

<int-websocket:outbound-channel-adapter
                          id=""  
                          channel=""  
                          container=""  
                          default-protocol-handler=""  
                          protocol-handlers=""  
                          message-converters=""  
                          merge-with-default-converters=""  
                          auto-startup=""  
                          phase=""/>  

<int-websocket:inbound-channel-adapter>

<int-websocket:inbound-channel-adapter
                            id=""  
                            channel=""  
                            error-channel=""  
                            container=""  
                            default-protocol-handler=""  
                            protocol-handlers=""  
                            message-converters=""  
                            merge-with-default-converters=""  
                            send-timeout=""  
                            payload-type=""  
                            use-broker=""  
                            auto-startup=""  
                            phase=""/>  

Starting with version 4.3.13, the ClientStompEncoder is provided as an extension of standard StompEncoder for using on client side of the WebSocket Channel Adapters. An instance of the ClientStompEncoder must be injected into the StompSubProtocolHandler for proper client side message preparation. One of the problem of the default StompSubProtocolHandler that it was designed for the server side, so it updates the SEND stompCommand header into MESSAGE as it must be by the STOMP protocol from server side. If client doesn’t send its messages in the proper SEND web socket frame, some STOMP brokers won’t accept them. The purpose of the ClientStompEncoder, in this case, is to override stompCommand header to the SEND value before encoding the message to the byte[].