Message Queue and Jakarta EE

Previous Next Contents

5 Message Queue and Jakarta EE

The Jakarta EE Platform is a specification for a standard server platform hosting multi-tier, distributed enterprise applications. One of the requirements of Jakarta EE is that distributed components be able to interact through reliable, asynchronous messaging. This interaction is enabled through the use of a JMS provider. Message Queue is Jakarta Messaging compatible implementation.

This chapter explores the ramifications of implementing JMS support in a Jakarta EE platform environment. The chapter covers the following topics:

For additional information about using Message Queue as a JMS provider for Jakarta EE compliant application servers, see "JMS Resource Adapter Property Reference" in Open Message Queue Administration Guide.

JMS/Jakarta EE Programming: Message-Driven Beans

In addition to the general JMS client programming model introduced in Client Programming Model, there is a more specialized adaptation of a JMS client used in the context of Jakarta EE platform applications. This specialized client is called a message-driven bean and is one of a family of Jakarta Enterprise Beans (EJB) components described in the Jakarta Enterprise Beans 3.2 (and later) Specification.

Message-driven beans provide asynchronous messaging; other EJB components (session beans and entity beans) can only be called synchronously, through standard EJB interfaces. However, enterprise applications often need asynchronous messaging, to allow server-side components to communicate without tying up server resources. Any application whose server-side components must respond to application events needs an EJB component that can receive and consume messages without being tightly coupled to the message producer. In enterprise applications, this capability must also scale under increasing load.

A message-driven bean (MDB) is an EJB component supported by a specialized EJB container, that provides distributed services for the components it supports.

An MDB implements the JMS MessageListener interface. The onMessage method (written by the MDB developer) is invoked when the MDB container receives a message. The onMessage() method consumes the message, just as the onMessage() method of a standard MessageListener object would. (You do not remotely invoke methods on MDBs as you do on other EJB components: therefore there are no home or remote interfaces associated with them.) Each MDB can consume messages from only a single destination. The messages can be produced by standalone JMS applications, JMS components, or EJB components, as shown in the following figure.

Figure 5-1 Messaging with MDBs

Diagram showing JMS message producers sending messages to consuming MDB instances in a Jakarta EE environment.

A specialized EJB container supports the MDB. This MDB container creates instances of the MDB and sets them up for asynchronous consumption of messages. The container sets up a connection with the broker (including authentication), creates a pool of sessions associated with a given destination, and manages the distribution of messages among the pooled sessions. Since the container controls the life cycle of MDB instances, it manages the pool of MDB instances to accommodate incoming message loads.

Associated with each MDB is a deployment descriptor that specifies the connection factory attributes and destination properties that the container uses in setting up message consumption. The deployment descriptor can also include other information needed by deployment tools to configure the container. Each such container supports all instances of a single MDB.

Jakarta EE Application Server Support

In Jakarta EE architecture, EJB containers are provided by Jakarta EE application servers. An application server supports these containers by providing resources they need, such as transaction managers, persistence managers, name services, and, in the case of messaging and MDBs, a JMS provider.

For information about Jakarta EE architecture, see the Jakarta EE Platform Specification located at https://jakarta.ee/specifications/platform/.

Jakarta EE also provides a standardized way of plugging in external resources needed by an application server. The standard, defined by the Jakarta Connectors 2.1 specification, allows an application server to interact with external systems by way of a resource adapter. External systems can include, among others, JMS messaging systems, as implemented by a JMS provider.

Plugging a JMS resource adapter into an application server allows Jakarta EE components deployed and running in the application server to exchange JMS messages. The JMS connection factory and destination administered objects needed by these components can be created and configured using Jakarta EE application server administration tools.

Other administrative operations, however, such as managing a broker and physical destinations, are not included in the Connectors specification and can be performed only through provider-specific tools.

Message Queue includes a JMS resource adapter that consists of a single file (imqjmsra.rar) located in a directory that depends on the operating system (see "JMS Resource Adapter Property Reference" in Open Message Queue Administration Guide). The imqjmsra.rar file contains the JAR files needed by the application server to support JMS messaging, as well as the resource adapter deployment descriptor (ra.xml) used to deploy the resource adapter in a Jakarta EE application server.

You can deploy the Message Queue resource adapter in Jakarta EE-11-compliant application servers by following the resource adapter deployment and configuration instructions provided by each application server.

In the case of the GlassFish Server, however, Message Queue is already integrated, by default, as the application server’s native JMS provider. Hence, no deployment of the Message Queue resource adapter is required.


Previous Next Contents
Copyright © 2019, Oracle and/or its affiliates. All rights reserved.
Eclipse Foundation Logo  Copyright © 2019, 2025 Contributors to the Eclipse Foundation