JBossMQ Overview

JBossMQ is composed of several services that work together to provide JMS API-level services to client applications. The services that make up the JBossMQ JMS implementation are introduced in the following sections.

The Invocation Layer Services

The invocation layer (IL) services are responsible for handling the communication protocols that clients use to send and receive messages. JBossMQ can support running different types of ILs concurrently. All ILs support bidirectional communication, which allows clients to send and receive messages concurrently. ILs only handle the transport details of messaging. They delegate messages to the JMS server JMX gateway service known as the invoker. This is similar to how the detached invokers expose the EJB container via different transports.

Each IL service binds a JMS connection factory to a specific location in the JNDI tree. Clients choose the protocol they wish to use by the JNDI location used to obtain the JMS connection factory. JBossMQ currently has several different ILs:

• UIL2 IL The Unified IL, version 2 (UIL2) is the preferred IL for remote messaging. A multiplexing layer is used to provide bidirectional communication. The multiplexing layer creates two virtual sockets over one physical socket. This allows communication with clients that cannot have a connection created from the server back to the client due to firewall or other restrictions. Unlike the older UIL invocation layer, which uses a blocking round-trip message at the socket level, the UIL2 protocol uses true asynchronous send and receive messaging at the transport level, providing for improved throughput and utilization.

• JVM IL The Java Virtual Machine (JVM) IL was developed to cut out the TCP/IP overhead when the JMS client is running in the same JVM as the server. This IL uses direct method calls for the server to service the client requests. This increases efficiency because no sockets are created and there is no need for the associated worker threads. This is the IL that should be used by MDBs or any other component that runs in the same VM as the server, such as servlets, MBeans, or EJBs.

• HTTP IL The HTTP IL allows for accessing the JBossMQ service over the HTTP or HTTPS protocols. This IL relies on the servlet deployed in the deploy/jms/jbossmq-httpil.sar to handle the HTTP traffic. This IL is useful for access to JMS through a firewall when the only port allowed requires HTTP.

The SecurityManager Service

The JBossMQ SecurityManager service enforces an access control list to guard access to your destinations. This subsystem works closely with the StateManager service.

The DestinationManager Service

You can think of the DestinationManager service as being the central service in JBossMQ. It keeps track of all the destinations that have been created on the server. It also keeps track of the other key services, such as MessageCache, StateManager, and PersistenceManager.

The MessageCache Service

Messages created in the server are passed to the MessageCache service for memory management. JVM memory usage goes up 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 MessageCache service notices that the JVM memory usage starts passing the defined limits, MessageCache starts moving those messages from memory to persistent storage on disk. The MessageCache uses a least recently used (LRU) algorithm to determine which messages should go to disk.

The StateManager Service

The StateManager (SM) service is in charge of keeping track of who is allowed to log in to the server and what their durable subscriptions are.

The PersistenceManager Service

A destination uses the PersistenceManager service to store messages marked as being persistent. JBossMQ has several different implementations of the persistence manager (PM), but only one can be enabled per server instance. You should enable the PM that best matches your requirements:

• The JDBC2 PM The JDBC2 PM allows you to store persistent messages to a relational database by using JDBC. The performance of this PM is directly related to the performance that can be obtained from the database. This PM has a very low memory overhead compared to the other PMs. Furthermore, it is highly integrated with the MessageCache to provide efficient persistence on a system that has a very active MessageCache.

• The null PM This wrapper PM can delegate to a real PM.

Configurations on the destinations decide whether persistence and caching are actually performed. You can find an example of a configuration in docs/examples/jms. To use the null PM backed by a real PM, you need to change the ObjectName of the real PM and link the new name to the null PM.

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

Clients that are in the P2P paradigm typically use queues. They expect that messages sent to a queue will be received by only one other client, 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, are stored under the JNDI queue/ subcontext.

Topics

Topics are used in the pub-sub paradigm. When a client publishes a message to a topic, he or she expects that a copy of the message will be delivered to each client that has subscribed to the topic. Topic messages are delivered in a manner similar to how a television show is delivered: Unless you have the TV on and are watching the show, you will miss it. 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 or DVR record a show you cannot watch at its scheduled time so that you can see what you missed when you turn your TV back on.