By hooking up a username with a WebSocket ID, let's see how all this runs. Restart everything, and visit the site.

First, we login as shown in this screenshot:

As seen in the last screenshot, the user logs in as greg. After that, the chat box will display itself at the bottom of the page. If we assume that oliver and phil have also logged in, we can see an exchange of messages as follows:

Greg asks how everyone likes the cover:

This preceding message is seen by everyone. Again, no reason to display all three users' views, since it is identical at this stage.

Oliver gives his $0.02:

So far, the conversation is wide open, as depicted by the (all) tag on each message. By the way, isn't this user-based interaction easier to follow the conversation than the earlier version where we used session IDs?

Phil writes a direct question to Greg:

After Phil clicks on Send, the following appears in Greg's browser:

Notice how this message does NOT have (all)? We know this message is direct, which is further verified by looking at Oliver's browser:

No sign of a followup question about t-shirt availability.

And if we look at Greg's JavaScript console, we can see all of this:

This preceding interchange shows the following:

• One message is sent from Greg's session to the server
• Two broadcast messages are received via the broker from Greg and Oliver
• One direct message is received from Phil

In conclusion, it's nice to see that by chaining together streams of messages across the system with Spring Cloud Stream, we were able to pipe exactly the messages we wanted to whom we wanted to receive them. We were able to leverage a sturdy transport broker, RabbitMQ, without getting caught up in messy details.

We took advantage of things like headers to mark up our messages, and filtered things as needed to implement business requirements. And we didn't spend all our time configuring brokers, servlet containers, or anything else. Instead, we logically defined channels and what was posted/consumed from those channels.