This chapter is from the book
This chapter is from the book
This chapter is from the book
Types of Messaging
There are two main ways to send messages: point-to-point and publish-subscribe. A point-to-point messaging application has a single producer (usually) and a single consumer. The producer produces messages while the consumer consumes them. Figure 19.2 illustrates a point-to-point messaging model.
){kind=link}
Figure 19.2. A point-to-point messaging system involves a single producer and a single consumer.
A point-to-point system can actually have multiple producers,but usually only a single con sumer. Think of a print server, for instance. Any machine on the network can send a print job to a particular print server. Of course, you can have multiple print servers, but that really just means you have multiple point-to-point message queues. Figure 19.3 illustrates a typical multi-producer point-to-point queue.
){kind=link}
Figure 19.3. A point-to-point system can have multiple producers.
The publish-subscribe messaging model (pub-sub) is more of a broadcast-oriented model. Publish-subscribe is based on the idea of topics and typically has many consumers-and potentially many producers as well. An Internet mailing list is similar to a typical publish-subscribe messaging system. The topic is the subject of the mailing list. For example, you might subscribe to Sun's JSP-INTEREST mailing list. In this case, JSP-INTEREST is the topic. Everyone who subscribes to the list receives messages. Anyone who sends a message to the list is a publisher. Of course, with a mailing list, the set of potential publishers is also the set of subscribers, but in a more general publish-subscribe system, the producers usually don't subscribe to the topics they publish on. Figure 19.4 illustrates a typical publish- subscribe setup.
){kind=link}
Figure 19.4. A typical publish- subscribe architecture is shown here.
Note
A point-to-point messaging system delivers only a single copy of the message to one consumer. A pub-sub messaging system delivers a copy of the message to every consumer.
There is something neat and elegant about a pub-sub model. It's far less coupled than even a message queue system. A component broadcasts the information, never caring about who listens to the data. You can add new components to process the data without the publisher even knowing about the components. Pub-sub is popular in applications that handle data on a real-time basis (or close to real-time, at least). For example, at an airline, you might pub lish flight information. At a bank, you might publish currency exchange information or stock quotes. At a sports network, you might publish updated scores. Although a producer using point-to-point messaging might never know about the consumer, there is only one consumer in a point-to-point messaging system. The advantage of pub-sub is that you can add new consumers without affecting existing consumers.
After you see how simple and powerful pub-sub can be, you might be tempted to use it for all your component-based communication. Keep in mind, however, there is a big potential drawback to using pub-sub everywhere. With most pub-sub systems, message ordering isn't guaranteed. The message ordering really comes into play when you have a system in which one pub-sub event triggers another. Figure 19.5 illustrates the message-ordering problem. Producer A sends a message that producer B receives. Producer B then publishes another message related to the one from producer A. Now consumer C happens to see the mes- sage from producer B and doesn't understand what's going on because the message from producer A hasn't arrived yet.
){kind=link}
Figure 19.5. When pub-sub messages can trigger other pub-sub messages, message order can be a problem.
It might be difficult to find a messaging system that can preserve message order-it's a fairly complex task. Remember, it's one thing to preserve the order on a single topic, but an entirely different (and harder) task to preserve the order across multiple different topics. Your best bet, unfortunately, is to avoid situations in which message order matters. This limits the number of places you can apply pub-sub, but you're still left with a rich set of possibilities.