HTML and CSS Reference
In-Depth Information
The more you use WebSocket, the more you may realize that the requirements for
building WebSocket-powered applications resemble classic messaging concepts. For
example, perhaps you want to extend the reach of your enterprise messaging protocols
to the Web by distributing large quantities of messages to a large number of clients. Or,
suppose you're building a collaborative application that requires your WebSocket clients
to send and receive data to and from other WebSocket clients. These two examples
illustrate messaging applications and WebSocket applications alike. As you will see in this
chapter, the two technologies work well together and layering messaging over WebSocket
enables you to build powerful messaging applications.
Messaging systems differ in how they integrate with clients. Some, like brokers that
support STOMP, offer protocol-level interoperability. Anyone implementing a compatible
protocol client can connect to those systems from any platform and language. Others
offer APIs that are provided for some select platforms chosen by the system vendor.
The simplest open, widely used protocol for messaging is STOMP: Simple
(or Streaming) Text Oriented Messaging Protocol. The most widely used messaging
API in the enterprise is JMS: Java Message Service. Unlike STOMP, which promotes
interoperability by defining a wire protocol, JMS is just an API. STOMP has been
implemented for many different languages; because of its nature as an API, JMS is almost
exclusively reigning in the Java world.
A newly standardized open messaging protocol is AMQP: Advanced Message
Queuing Protocol. AMQP 1.0 became an OASIS standard in October 2012. Although
AMQP was created with wide industry support, whether it can live up to the popularity
and success of STOMP and JMS remains to be seen. To learn more about AMQP,
In this chapter we walk through using STOMP over WebSocket (STOMP/WS). But if
your interest is JMS or AMQP over WebSocket, there are vendors and projects that can offer
you these capabilities. In addition, there are several proprietary pub/sub implementations
over WebSocket: some are simple, some more sophisticated. See Appendix B for a list of
current WebSocket servers that may have the support you need. The steps in this chapter
will hopefully also help give you a general understanding of how pub/sub over WebSocket
implementations work.
Introduction to STOMP
STOMP is an open protocol for messaging that was originally developed for use with
Apache ActiveMQ and has spread widely to other systems. STOMP does not have topics
or queues. STOMP messages are sent and received from destinations; the STOMP
server decides how these destinations behave. This behavior is similar to HTTP, in that
servers just have URLs, and it is up to the server to decide how to serve those URLs.
In the example we build in this chapter, we use STOMP with ActiveMQ. ActiveMQ uses
destination names to expose messaging features including topics and queues, temporary
destinations, and hierarchical subscriptions.
There is a running joke about standards whose names include the word “simple”:
they are almost universally overcomplicated. Examples include SNMP (Simple Network
Management Protocol), SOAP (Simple Object Access Protocol), and SMTP (Simple
Mail Transfer Protocol). STOMP is a genuinely
simple
protocol: it is text oriented and
resembles HTTP in its appearance. Each frame consists of a command, headers,
