|< Day Day Up >|| |
In this section we discuss Quality of Service capabilities and considerations specific to JMS and WebSphere MQ.
This section briefly discusses some of the tools important for fault monitoring and isolation.
There are two Windows Service snap-ins that use WebSphere MQ instrumentation to present the user with a GUI event and monitoring tool:
WebSphere MQ Alert Monitor (Windows)
The WebSphere MQ Alert Monitor is an error detection tool that identifies and records problems with WebSphere MQ on a local machine. It displays information about the current status of the local installation of a WebSphere MQ server.
Performance Monitor (Windows)
The Performance Monitor is a standard component of Windows. It enables you to select and display a variety of data about the performance of the Windows environment as tabular reports or graphs. You can use it to monitor the depth of messages on WebSphere MQ queues, and the rates of message arrival and removal.
WebSphere MQ ensures that messages are not lost by maintaining records (logs) of the activities of the queue managers that handle the receipt, transmission, and delivery of messages. It uses these logs for three types of recovery:
Restart recovery, when you stop WebSphere MQ in a planned way
Crash recovery, when WebSphere MQ is stopped by an unexpected failure
Media recovery, to restore damaged objects
In all cases, the recovery restores the queue manager to the state it was in when the queue manager stopped, except that any in-flight transactions are rolled back, removing from the queues any messages that were not committed at the time the queue manager stopped. Recovery restores all persistent messages; non-persistent messages are lost during the process.
It is often helpful to examine application server log and trace files when your application experiences JMS errors or problems. It is always important for applications to record their activity to a logging facility. When you write a log to the standard output file or standard error file, the application server will record it to the corresponding log files.
The approaches discussed in "IBM WebSphere MQ clustering" on page 294 also provide the node redundancy and failover capabilities needed to eliminate single-point-of-failure for production messaging systems.
Some issues that play a role in JMS messaging performance are:
WebSphere MQ client versus bindings mode connection
Using a bindings mode connection to a queue manager situated on the same machine as the application server will speed up communication. In addition to the performance gain, it also makes it possible to join a global transaction.
Generic versus specific message structure
Making the message structure more generic requires more translation and interpretation time at the sender and receiver ends. Making a message too specific will reduce flexibility for even small changes in the message structure.
Using persistent messages in MQ requires writing the messages to disk, which takes time and reduces performance.
In a request/reply scenario, EJBs should only be used with appropriate request/reply timeouts and re-tries.
Minimize the time spent in a message-driven bean processing the message. Let the pool of message-driven beans depend on the number of messages that arrive at the queue.
Optimization with connection
Start the connection when appropriate, so consumers are ready to consume messages before the producers are started. Process messages concurrently using a server session pool and close the connection when you are finished.
WebSphere MQ offers the ability to create clusters. MQ clusters provide a number of benefits that are silently utilized by JMS applications. Clusters offer:
Simpler administration of logically related queue managers
Clustering allows communication between queue managers to promote information about the queues they offer. Once in a cluster, queues on remote queue managers are visible to all queue managers if the queues are defined as cluster queues. The number of explicit definitions within IBM WebSphere MQ administration is reduced with the use of clusters.
Workload and failover management
Adding queue managers to clusters allows access to WebSphere MQ workload and failover features.
As shown in Figure 13-8, QM3 is able to load balance across the queue named ReplyQ, since it is available on both QM1 and QM2. Similarly, if QM1 is disabled, all messages for ReplyQ are routed to QM2.
Figure 13-8: Cluster workload management
None of these features can be controlled through the JMS interfaces. However, MQ will automatically utilize the workload and failover under JMS.
These and other features of MQ offer significant benefits and demonstrate that IBM WebSphere MQ is a reliable, scalable, and mature JMS Provider.
The JMS specification does not specify any features for controlling message integrity or authentication. It is expected that a JMS provider will provide these services. Security is considered to be a JMS provider-specific feature that is configured by an administrator rather than controlled via the JMS API by clients.
Messages arriving at a message-driven bean listener port have no client credentials associated with them. The messages are anonymous. However, some security can be provided if the JMS listener assumes the application server processes credentials when invoking the message-driven bean.
WebSphere MQ provides security for its administrative functions and for access to WebSphere MQ objects. This security relies on authentication being performed by the security system of the underlying operating system. Authorization of the users or groups to MQ resources is performed through the use of an access control list (ACL) maintained through the WebSphere MQ Object Authority Manager (OAM) command interface.
For more information see the InfoCenter article, Asynchronous messaging - security considerations at:
The JMS enterprise messaging API has achieved wide cross-industry support. It allows Java applications to leverage existing, enterprise-proven messaging systems, such as WebSphere MQ. It provides application designers and developers with standard messaging concepts and conventions that apply across a wide range of enterprise messaging systems.
JMS providers may support transactions, but only between the client and the messaging system, not to the target application. Once the client has sent the message to the messaging system, the client no longer has control of its propagation.
The WebSphere MQ JMS provider includes the JMS XA interfaces. These interfaces allow MQ JMS to participate in two-phase commit transactions that are coordinated by a transaction manager that complies with the Java Transaction API (JTA).
|< Day Day Up >|| |