We've coded our CommentService to implement Spring's WebSocketHandler interface, meaning, it's ready to transmit traffic over a WebSocket. The next step is to hook this service into the machinery.

We can start by creating a Spring configuration class:

    @Configuration 
    public class WebSocketConfig { 
      ... 
    } 

This Spring configuration class is devoted to configuring WebSocket support, and is marked up with the @Configuration annotation, indicating it's a source of Spring bean definitions.

With that in place, we now come to the core piece of registering WebSocket functionality:

    @Bean 
    HandlerMapping webSocketMapping(CommentService commentService) { 
      Map<String, WebSocketHandler> urlMap = new HashMap<>(); 
      urlMap.put("/topic/comments.new", commentService); 
 
      Map<String, CorsConfiguration> corsConfigurationMap = 
        new HashMap<>(); 
      CorsConfiguration corsConfiguration = new CorsConfiguration(); 
      corsConfiguration.addAllowedOrigin("http://localhost:8080"); 
      corsConfigurationMap.put( 
        "/topic/comments.new", corsConfiguration); 
 
      SimpleUrlHandlerMapping mapping = new SimpleUrlHandlerMapping(); 
      mapping.setOrder(10); 
      mapping.setUrlMap(urlMap); 
      mapping.setCorsConfigurations(corsConfigurationMap); 
 
      return mapping; 
    } 

This preceding little chunk of code can be taken apart as follows:

• @Bean indicates this entire method is used to construct a Spring bean.
• It's a HandlerMapping bean, Spring's interface for linking routes with handler methods.
• The name of the method, webSocketMapping, indicates this method is about wiring routes for WebSocket message handling.
• It asks for a copy of the CommentService bean we defined earlier. Since Spring Boot activates component scanning, an instance of that service will be created automatically, thanks to the @Service annotation we put on it earlier.
• We create a Java Map, designed for mapping string-based routes onto WebSocketHandler objects, and dub it a urlMap.
• We load the map with /topic/comments.new, and link it with our CommentService, a class that implements the WebSocketHandler interface.
• There's the sticky issue of microservices, whereby, our chat service runs on a different port from the frontend image service. Any modern web browser will deny a web page calling a different port from the original port it was served. To satisfy security restrictions (for now), we must implement a custom Cross-origin Resource Sharing or CORS policy. In this case, we add an Allowed Origin of http://localhost:8080, the address where the frontend image service resides.
• With both the urlMap and the corsConfiguration policy, we construct SimpleUrlHandlerMapping. It also needs an order level of 10 to get viewed ahead of certain other route handlers provided automatically by Spring Boot.

Essentially, this bean is responsible for mapping WebSocket routes to handlers, whether that is to target client-to-server, or server-to-client messaging. The message route we've designed so far is a WebSocket message that originates on the server when a new comment is created, and is pushed out to all clients so they can be alerted to the new comment.

In Spring Framework 4, there is an annotation-based mechanism that lets us configure these routes directly on the handlers themselves. But for Spring Framework 5 (WebFlux), we must configure things by hand. CORS is also critical to handle given the way we split things up across multiple microservices.

Another critical component in the same configuration class is listed next:

    @Bean 
    WebSocketHandlerAdapter handlerAdapter() { 
      return new WebSocketHandlerAdapter(); 
    } 

This preceding, somewhat boring looking, Spring bean is critical to the infrastructure of WebSocket messaging. It connects Spring's DispatcherHandler to a WebSocketHandler, allowing URIs to be mapped onto handler methods.