Running IBM MQ classes for Java applications within Java EE

There are certain restrictions and design considerations that must be taken into account before using IBM MQ classes for Java in Java EE.

IBM MQ classes for Java has restrictions when used within a Java Platform, Enterprise Edition (Java EE) environment. There are also additional considerations that must be taken into account when designing, implementing, and managing an IBM MQ classes for Java application that runs inside a Java EE environment. These restrictions and considerations are outlined in the following sections.

JTA transactions restrictions

The only supported transaction manager for applications using IBM MQ classes for Java is IBM MQ itself. Although an application under JTA control can make use IBM MQ classes for Java, any work performed through these classes is not controlled by the JTA units of work. They instead form local units of work separate from those managed by the application server through the JTA interfaces. In particular, any rollback of the JTA transaction does not result in a rollback of any sent or received messages. This restriction applies to application or bean managed transactions and to container managed transactions, and all Java EE containers. To perform messaging work directly with IBM MQ inside application server-coordinated transactions, IBM MQ classes for JMS must be used instead.

Thread creation

IBM MQ classes for Java creates threads internally for various operations. For example, when running in BINDINGS mode to call directly on a local queue manager, the calls are made on a 'worker' thread created internally by IBM MQ classes for Java. Other threads can be created internally, for example to clear unused connections from a connection pool or to remove subscriptions for terminated publish/subscribe applications.

Some Java EE applications (for example those running in EJB and Web containers) must not create new threads. Instead, all work must be performed on the main application threads managed by the application server. When applications use IBM MQ classes for Java, the application server might not be able to distinguish between application code and the IBM MQ classes for Java code, so the threads previously described cause the application to be non-compliant with the container specification. IBM MQ classes for JMS does not break these Java EE specifications and so can be used instead.

Security restrictions

Security policies implemented by an application server might prevent certain operations that are undertaken by the IBM MQ classes for Java API, such as creating and operating new threads of control (as described in the preceding sections).

For example, application servers typically run with Java Security disabled by default, and allow it to be enabled through some application server-specific configuration (some application servers also allow more detailed configuration of the policies used within Java Security). When Java Security is enabled, IBM MQ classes for Java might break the Java Security policy threading rules defined for the application server, and the API might not be able to create all the threads that it needs in order to function. To prevent problems with thread management, the use of IBM MQ classes for Java is not supported in environments where Java Security is enabled.

Application isolation considerations

An intended benefit of running applications within a Java EE environment is application isolation. The design and implementation of IBM MQ classes for Java predate the Java EE environment. IBM MQ classes for Java can be used in a manner which does not support the concept of application isolation. Specific examples of considerations in this area include:

• The use of static (JVM process-wide) settings within the MQEnvironment class, such as:
  • the user ID and password to be used for connection identification and authentication
  • the host name, port, and channel used for client connections
  • TLS configuration for secured client connections

  Modifying any of the MQEnvironment properties for the benefit of one application also affect other applications using the same properties. When running in a multi-application environment such as Java EE, each application must use its own distinct configuration through the creation of MQQueueManager objects with a specific set of properties, rather than defaulting to the properties configured in the process-wide MQEnvironment class.

• The MQEnvironment class introduces a number of static methods which act globally on all applications using IBM MQ classes for Java within the same JVM process, and there is no way to override this behavior for particular applications. Examples include:
  • configuring TLS properties, such as the location of the keystore
  • configuring client channel exits
  • enabling or disabling diagnostic tracing
  • managing the default connection pool used to optimize the use of connections to queue managers

  Invoking such methods affects all applications running in the same Java EE environment.

• Connection pooling is enabled to optimize the process of making multiple connections to the same queue manager. The default connection pool manager is process-wide, and shared by multiple applications. Changes to connection pool configuration, such as replacing the default connection manager for one application using the MQEnvironment.setDefaultConnectionManager() method therefore affects other applications running in the same Java EE application server.
• TLS is configured for applications using IBM MQ classes for Java using the MQEnvironment class and MQQueueManager object properties. It is not integrated with the managed security configuration of the application server itself. We must ensure that you configure IBM MQ classes for Java appropriately to provide we required level of security, and not use the application server configuration.

Bindings mode restrictions

IBM MQ and WebSphere Application Server can be installed on the same machine such that the major versions of the queue manager and of the IBM MQ resource adapter (RA) shipped in WebSphere Application Server are different. For instance WebSphere Application Server Version 7.0, which ships an IBM MQ RA level of 7.0.1, can be installed on the same machine as a Version 6 queue manager.

If the queue manager and resource adapter major versions are different, bindings connections cannot be used. Any connections from WebSphere Application Server to the queue manager using the resource adapter must use client type connections. Bindings connections can be used if the versions are the same.

Parent topic: Use IBM MQ classes for Java