anchor.diff:  
   		@Override
   		public void registerStompEndpoints(StompEndpointRegistry registry) {
  -			registry.addEndpoint("/portfolio").withSockJS();
  +			registry.addEndpoint("/portfolio").withSockJS();  // <1>
   		}
   
   		@Override
   		public void configureMessageBroker(MessageBrokerRegistry config) {
  -			config.setApplicationDestinationPrefixes("/app");
  -			config.enableSimpleBroker("/topic", "/queue");
  -		}
  -	}
  -----
  -
  -and in XML:
  +			config.setApplicationDestinationPrefixes("/app"); // <2>
  +			config.enableSimpleBroker("/topic", "/queue"); // <3>
  +		}
  +	}
  +----
  +
  +<1> `"/portfolio"` is the HTTP URL for the endpoint to which a WebSocket (or SockJS)
  +client will need to connect to for the WebSocket handshake.
  +<2> STOMP messages whose destination header begins with `"/app"` are routed to
  +`@MessageMapping` methods in `@Controller` classes.
  +<3> Use the built-in, message broker for subscriptions and broadcasting;
  +Route messages whose destination header begins with "/topic" or "/queue" to the broker.
  +
  +The same configuration in XML:
   
   [source,xml,indent=0]
   [subs="verbatim,quotes,attributes"]
  
positive.code: [[websocket-stomp-message-flow]]
  === Flow of Messages
  
  When a STOMP endpoint is configured, the Spring application acts as the STOMP broker
  to connected clients. This section provides a big picture overview of how messages flow
  within the application.
  
  The `spring-messaging` module provides the foundation for asynchronous message processing.
  It contains a number of abstractions that originated in the
  https://spring.io/spring-integration[Spring Integration] project and are intended
  for use as building blocks in messaging applications:
  
  * {api-spring-framework}/messaging/Message.html[Message] --
  a message with headers and a payload.
  * {api-spring-framework}/messaging/MessageHandler.html[MessageHandler] --
  a contract for handling a message.
  * {api-spring-framework}/messaging/MessageChannel.html[MessageChannel] --
  a contract for sending a message enabling loose coupling between senders and receivers.
  * {api-spring-framework}/messaging/SubscribableChannel.html[SubscribableChannel] --
  extends `MessageChannel` and sends messages to registered `MessageHandler` subscribers.
  * {api-spring-framework}/messaging/support/ExecutorSubscribableChannel.html[ExecutorSubscribableChannel] --
  a concrete implementation of `SubscribableChannel` that can deliver messages
  asynchronously via a thread pool.
  
  The `@EnableWebSocketMessageBroker` Java config and the `<websocket:message-broker>` XML config
  both assemble a concrete message flow. Below is a diagram of the part of the setup when using
  the simple, in-memory broker:
  
  image::images/message-flow-simple-broker.png[]
  
  The above setup that includes 3 message channels:
  
  * `"clientInboundChannel"` for messages from WebSocket clients.
  * `"clientOutboundChannel"` for messages to WebSocket clients.
  * `"brokerChannel"` for messages to the broker from within the application.
  
  The same three channels are also used with a dedicated broker except here a
  "broker relay" takes the place of the simple broker:
  
  image::images/message-flow-broker-relay.png[]
  
  Messages on the `"clientInboundChannel"` can flow to annotated
  methods for application handling (e.g. a stock trade execution request) or can
  be forwarded to the broker (e.g. client subscribing for stock quotes).
  The STOMP destination is used for simple prefix-based routing. For example
  the "/app" prefix could route messages to annotated methods while the "/topic"
  and "/queue" prefixes could route messages to the broker.
  
  When a message-handling annotated method has a return type, its return
  value is sent as the payload of a Spring `Message` to the `"brokerChannel"`.
  The broker in turn broadcasts the message to clients. Sending a message
  to a destination can also be done from anywhere in the application with
  the help of a messaging template. For example, an HTTP POST handling method
  can broadcast a message to connected clients, or a service component may
  periodically broadcast stock quotes.
  
  Below is a simple example to illustrate the flow of messages:
  
  [source,java,indent=0]
  [subs="verbatim,quotes"]
  
negative.code: == STOMP
  
  The WebSocket protocol defines two types of messages, text and binary, but their
  content is undefined. The defines a mechanism for client and server to negotiate a
  sub-protocol -- i.e. a higher level messaging protocol, to use on top of WebSocket to
  define what kind of messages each can send, what is the format and content for each
  message, and so on. The use of a sub-protocol is optional but either way client and
  server will need to agree on some protocol that defines message content.
  
  
  
  [[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 minimal 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, message payloads can be
  either text or binary.
  
  STOMP is a frame based protocol whose frames are modeled on HTTP. The structure
  