Server Components

JBossMQ is composed of several components working together to provide JMS API level services to client applications. All of the components will be reviewed in this section in order to obtain a deeper understanding of the JBossMQ server and how to optimize it.

Invocation Layer

The Invocation Layer (IL) is the component that is responsible for defining the communications protocol that allows clients to send messages to a destination, and similarly, for the destination to send messages to the clients. JBossMQ can support running different types of Invocation Layers concurrently. All Invocation Layers have a dual channel nature that allows clients to send messages as it concurrently receives messages from the server.

Each different type of Invocation Layer will bind a JMS ConnectionFactory (configured to use the IL) to a different location in the JNDI tree. Clients can pick the protocol they wish to use by looking up the correct JNDI location.

Security Manager

The JBossMQ Security Manager is the component that enforces an Access Control List to guard access to your destinations. This component works closely with the State Manager component, which will be discussed later.

Destination Manager

The Destination Manager can be thought of as being the central sever for JBossMQ. It keeps track of all the destinations that have been created on the server. It also keeps track of the other server components such as the Message Cache, State Manager, and Persistence Manager.

Message Cache

Messages created in the server are subsequently passed to the Message Cache for memory management. JVM memory usage increases as messages are added to a destination that does not have any receivers. These messages are held in the main memory until the receiver picks them up. If the Message Cache notices that the JVM memory usage starts passing the defined limits, the Message Cache starts moving those messages from memory to persistent storage on disk. The Message Cache uses a Least Recently Used algorithm to determine which messages should go to disk.

State Manager

The State Manager (SM) is in charge of keeping track of who is allowed to log into the server and what the durable subscriptions are for each one of them.

Persistence Manager

The Persistence Manager (PM) is used by a destination to store messages marked as being persistent. JBossMQ has several different implementations of the Persistent Manager, yet only one can be enabled per server instance.

Destinations

A Destination is the object on the JBossMQ server that clients use to send and receive messages. There are two types of destination objects, Queues and Topics. References to the destinations created by JBossMQ are stored in JNDI.

Queues

A Queue is a JMS destination that routes messages to a single receiver. They expect that messages sent to a Queue will be received by only one other client ?once and only once?. If multiple clients are receiving messages from a single queue, the messages will be load balanced across the receivers.

Queue objects, by default, will be stored under the JNDI queue/ sub context.

Topics

A Topic is a JMS destination that allows messages to be broadcast to multiple receivers. When a client publishes a message to a topic, he expects that a copy of the message will be delivered to each client that has subscribed to the topic. Topic messages are delivered in the same manner that a television show is delivered. Unless you have the TV on and are watching the show, you will miss the program. Similarly, if the client is not up, running and receiving messages from the topics, it will miss messages published to the topic. To get around this problem of missing messages, clients can start a durable subscription. This is like having a VCR record a show that you are missing, so that you can see what you missed when you turn your TV back on.

Topic objects, by default, will be stored under the JNDI topic/ sub context.