anchor.diff:  
   [NOTE]
   ====
  -The "/app" prefix is arbitrary. You can pick any prefix. It's simply meant to differentiate
  -messages to be routed to message-handling methods to do application work vs messages
  -to be routed to the broker to broadcast to subscribed clients.
  -
  -The "/topic" and "/queue" prefixes depend on the broker in use. In the case of the simple,
  -in-memory broker the prefixes do not have any special meaning; it's merely a convention
  -that indicates how the destination is used (pub-sub targetting many subscribers or
  -point-to-point messages typically targeting an individual recipient).
  -In the case of using a dedicated broker, most brokers use "/topic" as
  -a prefix for destinations with pub-sub semantics and "/queue" for destinations
  -with point-to-point semantics. Check the STOMP page of the broker to see the destination
  -semantics it supports.
  +For the built-in, simple broker the "/topic" and "/queue" prefixes do not have any special
  +meaning. They're merely a convention to differentiate between pub-sub vs point-to-point
  +messaging (i.e. many subscribers vs one consumer). When using an external broker, please
  +check the STOMP page of the broker to understand what kind of STOMP destinations and
  +prefixes it supports.
   ====
   
   
  
positive.code: == STOMP
  
  The WebSocket protocol defines two types of messages, text and binary, but their
  content is undefined. It's expected that the client and server may agree on using
  a sub-protocol (i.e. a higher-level protocol) to define message semantics.
  While the use of a sub-protocol with WebSocket is completely optional either way
  client and server will need to agree on some kind of protocol to help interpret
  messages.
  
  
  
  [[websocket-stomp-overview]]
  === Overview
  
  http://stomp.github.io/stomp-specification-1.2.html#Abstract[STOMP] is a simple
  text-oriented messaging protocol that was originally created for scripting languages
  such as Ruby, Python, and Perl to connect to enterprise message brokers. It is
  designed to address a subset of commonly used messaging patterns. STOMP can be
  used over any reliable 2-way streaming network protocol such as TCP and WebSocket.
  Although STOMP is a text-oriented protocol, the payload of messages can be
  either text or binary.
  
  STOMP is a frame based protocol whose frames are modeled on HTTP. The structure
  
negative.code: [[websocket-stomp-message-flow]]
  === Flow of Messages
  
  Once a STOMP endpoint is exposed, the Spring application becomes a STOMP broker for
  connected clients. This section describes the flow of messages on the server side.
  
  The `spring-messaging` module contains foundational support for messaging applications
  that originated in https://spring.io/spring-integration[Spring Integration] and was
  later extracted and incorporated into the Spring Framework for broader use across many
  https://spring.io/projects[Spring projects] and application scenarios.
  Below is a list of a few of the available messaging abstractions:
  
  * {api-spring-framework}/messaging/Message.html[Message] --
  simple representation for a message including headers and payload.
  * {api-spring-framework}/messaging/MessageHandler.html[MessageHandler] --
  contract for handling a message.
  * {api-spring-framework}/messaging/MessageChannel.html[MessageChannel] --
  contract for sending a message that enables loose coupling between producers and consumers.
  * {api-spring-framework}/messaging/SubscribableChannel.html[SubscribableChannel] --
  `MessageChannel` with `MessageHandler` subscribers.
  * {api-spring-framework}/messaging/support/ExecutorSubscribableChannel.html[ExecutorSubscribableChannel] --
  `SubscribableChannel` that uses an `Executor` for delivering messages.
  
  Both the Java config (i.e. `@EnableWebSocketMessageBroker`) and the XML namespace config
  (i.e. `<websocket:message-broker>`) use the above components to assemble a message
  workflow. The diagram below shows the components used when the simple, built-in message
  broker is enabled:
  
  image::images/message-flow-simple-broker.png[]
  
  There are 3 message channels in the above diagram:
  
  * `"clientInboundChannel"` -- for passing messages received from WebSocket clients.
  * `"clientOutboundChannel"` -- for sending server messages to WebSocket clients.
  * `"brokerChannel"` -- for sending messages to the message broker from within
  server-side, application code.
  
  The next diagram shows the components used when an external broker (e.g. RabbitMQ)
  is configured for managing subscriptions and broadcasting messages:
  
  image::images/message-flow-broker-relay.png[]
  
  The main difference in the above diagram is the use of the "broker relay" for passing
  messages up to the external STOMP broker over TCP, and for passing messages down from the
  broker to subscribed clients.
  
  When messages are received from a WebSocket connectin, they're decoded to STOMP frames,
  then turned into a Spring `Message` representation, and sent to the
  `"clientInboundChannel"` for further processing. For example STOMP messages whose
  destination header starts with `"/app"` may be routed to `@MessageMapping` methods in
  annotated controllers, while `"/topic"` and `"/queue"` messages may be routed directly
  to the message broker.
  
  An annotated `@Controller` handling a STOMP message from a client may send a message to
  the message broker through the `"brokerChannel"`, and the broker will broadcast the
  message to matching subscribers through the `"clientOutboundChannel"`. The same
  controller can also do the same in response to HTTP requests, so a client may perform an
  HTTP POST and then an `@PostMapping` method can send a message to the message broker
  to broadcast to subscribed clients.
  
  Let's trace the flow through a simple example. Given the following server setup:
  
  [source,java,indent=0]
  [subs="verbatim,quotes"]
  