JMS stands for Java Message Service and can be categorized under Message-Oriented Middleware (MOM).
The message-oriented middleware became widely used when providers created architectures that could operate in a standard way on a variety of platforms and enable asynchronous communication between applications. These providers gained popularity in enabling integration of mainframes and personal computers.
Even though there is much variety in MOM products, they fall into one of the following categories:
An enterprise messaging system enables applications to asynchronously communicate with one another through messages. A message is a request, report, or event that contains information needed to coordinate communication between different applications.
JMS supports the point-to-point (PTP) and publish/subscribe messaging models. The models are very similar, except the following:
- The PTP messaging model enables delivery of a message to exactly one recipient.
When using a PTP queue, multiple message producers can put messages onto a single queue. The queue serializes the messages in a linear order. Multiple receivers can pull messages off the queue in FIFO order. The oldest message on the queue is the first one to be taken off.
A message can be delivered only to one receiver. Receivers are also referred to as consumers.
A request-reply messaging model is more suited to a synchronous messaging environment where the requester and replier are in conversational mode the requester waits for a response from the replier before continuing work.
- In publish/subscribe, you have multiple consumers that subscribe to certain messages (named topics). When the producer publishes its message to the topic, all consumers/subscribers receive the message.
By decoupling a subscriber from the publisher, the subscriber does not have to determine whether its publisher is active. If the message-oriented middleware server is executing, the needs of both the publishers and the subscribers are met.
Oracle WebLogic Server JMS uses its built-in support for JDBC and JDBC connection pools to persist JMS messages in a database, but the default is file-based persistency.
Oracle WebLogic supports transactional message delivery. Transactional message delivery gives the developer the ability to put a JMS session into a transaction context. In Oracle WebLogic JMS, the message is not visible or available for consumption until the transaction is committed. A session can optionally roll back the transaction, which has the transaction "drop" the messages it had previously buffered.
The following diagram shows a typical WebLogic JMS architecture:
The main components of the WebLogic JMS Server architecture include:
- JMS servers that can host a defined set of modules and any associated persistent storage that resides on a WebLogic Server instance. JMS server configuration is stored in the domain
config.xmlfile. - Client JMS applications that either produce messages to destinations or consume messages from destinations.
- Java Naming and Directory Interface (JNDI), which provides a resource lookup facility. JMS resources such as connection factories and destinations are configured with a JNDI name. The runtime implementations of these resources are then bound to JNDI using the given names.
- WebLogic persistent storage (file store or JDBC-accessible) for storing persistent message data.
You can create and configure a JMS server by using the Administration Console. To create a JMS server, perform the following steps:
- In the Services node in Domain Structure in the left panel, click JMS Servers.
- Click New at the JMS Servers table.
- Enter values for the following configuration parameters:
- Name: The name of the JMS server.
- Persistent Store: The backing store used by destinations. A value of none means that the JMS server will use the default persistent store that is configured on each targeted WLS instance. It can be file-based or database. Database is usually a bit slower, but has some other advantages. There is less message loss on server outs. Applications can take advantage of any high-availability or failover solutions offered by the database. On file-based, this could be more difficult to guarantee as you are using shared disks only.
- Then target a JMS server.
- When you specify that you want to create a new store in step 3, the Select store type page appears. You can select File Store or JDBC Store.
- If you specify File Store, the File Store Properties page appears. When creating a File Store for the JMS Persistent store, the path name to the directory must exist on your system, so be sure to create it before completing this page.
- If you selected JDBC Store, in the Create New JDBC Store page, select a configured JDBC data source or configure a new JDBC data source for the store. You cannot configure a JDBC data source that is configured to support global transactions, because WebLogic JMS supports global transactions for both file and JDBC store.
- You can monitor the runtime statistics for an active JMS server. From the Monitoring tab, you can also access runtime information for a JMS server's destinations, transactions, connections, and server session pools.
- Go to Expand Services | Messaging and click JMS Servers. Select a JMS server.
- Click the Monitoring tab. By default, a Monitoring subtab is displayed, which provides general statistics for all destinations on every JMS server in the domain. These statistics include the number and size of messages processed by the JMS server.
- The Active Destinations tab displays the statistics for each active JMS destination for the domain.
- The Active Transactions tab displays all active JMS transactions for the domain. For troubleshooting, you can force commits or rollbacks on selected transactions. Simply select a transaction, and then click either the Force Commit or Force Rollback button.
- The Active Connections tab displays all active client JMS connections for the domain. For troubleshooting, you can destroy the selected connections. Simply select a connection, and then click the Destroy button above the table.
The available columns include:
- Messages Current: The current number of messages in the destination. This does not include the pending messages
- Messages Pending: The number of pending messages in the destination
- Messages High: The peak number in the destination since the last reset
- Messages Received: Number of messages received in this destination since the last reset
- Messages Threshold: Amount of time in the threshold condition since the last reset
- Consumers Current: The current number of consumers accessing this destination
Configuration of JMS resources such as queues, topics, and connection factories are within JMS modules. An administrator can create and manage JMS modules as:
JMS configuration resources, such as destinations and connection factories, are stored outside of the WebLogic domain configuration file as module descriptor files of an application. JMS modules do not include the JMS server definitions.
The JMS system modules must be targeted to one or more Oracle WebLogic Server instances. The targetable resources that are defined in a system module must also be targeted to a JMS server or the Oracle WebLogic Server instances within the scope of a parent module's targets.
In the following screenshot you can see how to specifiy a new JMS Module:
The configuration of JMS resources, such as destinations and connection factories, are stored outside of the WebLogic domain configuration file as module descriptor files, such as the weblogic-jms.xsd schema.
The JMS system modules must be targeted to one or more Oracle WebLogic Server instances or to a cluster. The resources that are defined in a system module must also be targeted to a JMS server or WebLogic Server instances.
You can package JMS modules using integrated development environment (IDE) or a development tool that supports the editing of an XML descriptor file. You then deploy and manage modules using the JSR 88-based tools, such as the weblogic.Deployer utility or the WebLogic Administration Console.
The deployment of packaged JMS modules follows the same model as all the other components of an application: individual modules can be deployed to a single server, a cluster, or individual members of a cluster.
Besides the modules, there is also a component called Subdeployment. A subdeployment for JMS destinations is a mechanism by which queues and topics, and connection factories are grouped and targeted to a single JMS server. Queues and topics depend on the JMS servers they are targeted to the management of persistent messages, durable subscribers, and message paging.
For example, if you want to re-locate a group of queues with a connection factory that is targeted to a specific JMS server, you can associate the queues with the subdeployment the connection factory belongs to, provided that the connection factory is not already targeted to multiple JMS servers.
JMS modules are application-related definitions that are independent of the domain environment. You create and manage JMS resources either as system modules or application modules.
JMS application modules are a WebLogic-specific extension of Java EE modules and can be deployed either with a Java EE application (as a packaged resource) or as standalone modules that can be made globally available. Application modules are owned and modified by WebLogic developers, who package JMS resource modules with the application's EAR file.
During the process of deploying a JMS application, you link the application components to the environment-specific JMS resource definitions, such as the Managed Server instances, and the location to use for persisting JMS messages.
With modular deployment of JMS resources, you can promote your application and the required JMS configuration from environment to environment, such as from a testing environment to a production environment, without opening an enterprise application file (such as an EAR file) or a standalone JMS module, and without extensive manual JMS reconfiguration.
Within each JMS module, the connection factory resource names must be unique. All the connection factory JNDI names in any JMS module must be unique across an entire WebLogic domain.
When you create a JMS Module, you can go on and create additional destinations.
A JMS destination identifies a queue (point-to-point) or topic (publish/subscribe) resource within a JMS module. Each queue and topic resource is targeted to a specific JMS server. A JMS server's primary responsibility for its targeted destinations is to maintain information about the persistent store that is used for any persistent messages that arrive on the destinations and to maintain the states of the durable subscribers created on the destinations.
Connection factories are resources that enable JMS clients to create JMS connections. WebLogic JMS provides preconfigured default connections. You can also configure one or more connection factories to create connections with predefined options that better suit your application.
When connection factory options are modified at runtime, only the incoming messages are affected; stored messages are not affected.
To create a new Connection Factory, click on the JMS Module, and then add a JMS Destination. The Connection Factory will be the first one in the list
You can give it the name and JNDI:
After this, you can target it to a Managed Server instance or Subdeployment.
The queues (point-to-point) or topics (publish/subscribe) are also grouped as JMS destinations. After configuring a JMS server, configure one or more queue or topic destinations for each JMS server. You configure destinations explicitly or by configuring a destination template that can be used to define multiple destinations with similar attribute settings.
A JMS destination identifies a queue (point-to-point) or topic (publish/subscribe) resource within a JMS module.
The main difference between a Topic and a Queue is that a Topic is synchronous and a Queue asynchronous.
In the same screen to create a new Connection Factory, you also can create these resources.
