| MOM is a concept that has been around for two decades. Over the years, new ideas have been introduced, new vendors have moved into the MOM space, and new standards continue to evolve that are related to messaging and MOM concepts. While the messaging category of technology continually gets better, there is also a set of core concepts that will remain similar across many MOM implementations. 5.2.1 Abstract Decoupling Messaging applications use a messaging client API to communicate with one another through a messaging system. When an application is communicating in this fashion, it is acting as either a producer or a consumer. Senders (producers) produce messages and receivers (consumers) consume messages. An application may be both a producer and a consumer at the same time. Producers and consumers are loosely coupled in that they are not directly tied to each other; instead, they are abstractly connected to each other through virtual channels called publish-and-subscribe channels or point-to-point channels. These two distinct channel types are often referred to as topics and queues, respectively (Figure 5-5). Figure 5-6. Producers and consumers are abstractly decoupled from each other using virtual channels known as publish-and-subscribe topics and point-to-point queues 
The producer does not need to know which applications are receiving a message, or in some cases even how many are receiving it. Likewise, the consumer does not need to know which applications are sending the data; it only knows that it receives a message and acts upon it. If a response is required, that fact is encoded in the message via the presence of a "ReplyTo" destination to identify the channel on which to send a response. Depending on the implementation, these virtual channel definitions are either coded into the application, or are described and configured administratively using a tool, with the details of the configuration stored in a directory service. Even if the details of channel configuration are stored in a directory service, the creation of the message channels needs to be coded into the application when using a basic MOM, rather than a higher-level ESB that is built on a MOM. With an ESB, the details of creating and managing the messaging channels are encapsulated in a container-managed environment that is configured instead of being written into application code. 5.2.2 Messaging Models: Publish-and-Subscribe and Point-to-Point As shown in Figure 5-6, the publish-and-subscribe (pub/sub) domain is intended for a one-to-many broadcast of information, while the point-to-point domain is intended for a one-to-one communication between two specific applications. Figure 5-7. Common messaging models include publish-and-subscribe and point-to-point 
In the pub/sub model, multiple consumers may register an interest with, or subscribe to, a topic. A producer sends a message on that channel by publishing on that topic. Each subscriber receives a copy of that message. In the point-to-point model, only one consumer may receive a message that is sent to a queue. As shown in Figure 5-6, a point-to-point queue may have multiple consumers listening for the purposes of load-balancing or "hot backup"; however, only one receiver may consume each individual message. There may also be no receivers listening, in which case the message stays in the queue until a receiver attaches itself to the queue to retrieve messages. In the publish-and-subscribe model, messages not flagged as reliable can be discarded if no subscribers are registered to receive them at the time they are published. The choice of which model to use can largely depend on how many consumers need to see duplicate copies of the same message. For example, in a supply chain, a supplier might want to broadcast special price reductions to its buyers in a one-to-many fashion using the pub/sub messaging model, with all buyers receiving the same information. However, if a particular buyer wants to react to that lower price by purchasing the goods being advertised, that will require a point-to-point conversation that involves only the two parties: the buyer and the seller. 5.2.3 Topic Hierarchies Many MOM implementations allow publish-and-subscribe topics to be managed in a hierarchical tree structure, as illustrated in Figure 5-7. Figure 5-8. Publish-and-subscribe topic hierarchies allow wildcard-based subscriptions at any level 
Using topic hierarchies, a message consumer may subscribe to any level of any branch within a topic tree. Wildcard substitution can be used to represent an entire subnode within a tree. For example, using the topic hierarchy represented by Figure 5-7, a subscriber who subscribes to the Travel.#.Deluxe topic will receive all messages addressed to the Travel.Hotels.Domestic.Deluxe, Travel.Hotels.International.Deluxe, and Travel.Cars.Deluxe topics. In this representative syntax, the # character matches any number of node levels in the topic tree that begin with Travel. Another example of topic hierarchies, this time in the financial services industry, is the segregation of market data (Figure 5-8). Figure 5-9. Segregation of data in a financial services topic hierarchy 
These examples both use the popular "." (dot) syntax to separate topic names. Industry efforts are underway to standardize hierarchical topic trees using XML syntax in the WS-Notification family of specifications. WS-Notification uses a subset of XPath for expression matching on individual branches and leaves in a tree, in addition to allowing for various proprietary dialects. 5.2.4 Access Control Lists (ACLs) A companion security feature may also be implemented to take advantage of hierarchical topic trees. Access Control List (ACL) mechanisms can allow administrators to grant access to different levels of the hierarchy using a similar wildcard approach to specify routes to a particular branch or leaf of a topic tree. Security realms can be implemented such that individuals or groups can be granted permissions, either positively or negatively, to individual branches or leaves within a tree-based namespace of messaging destinations. For example, you can administratively specify to "Grant this group of users all access to the graph of topics that match the expression Travel.#.Domestic.#, excluding these three users." If the point-to-point queue namespace has a similar form, the same pattern matching can occur. In an ESB, this capability helps to enable the federated autonomy between departments and business units. Each ESB segment can reside in an individual business unit and have its own local control over ACLs. 5.2.5 What's in a Message? A message is typically composed of three basic parts: the headers, the properties, and the message payload or body (Figure 5-9). The headers are used by both the messaging system and the application developer to provide information about things such as the destination, the reply-to destination, the message type, and the message expiration time. Figure 5-10. MOM messages consists of headers, properties, and the message body 
The properties section may contain a set of application-defined name/value pairs. These properties are essentially parts of the message payload or body that get promoted to a special section of the message so that filtering can be applied to the message by consumers or specialized routers.  | Note that not all MOM implementations support the notion of a property section. Instead, they merge the concept of headers and properties into a single space. |
|
The format of the message payload can vary across messaging implementations. Most common formats are plain text, a raw stream of bytes for holding any type of binary data, or a special XML message type that allow the message payload to be accessed using any number of common XML parsing technologies. | 