WebLogic with WebSphere MQ as an XA resource

Question

I have been using WebLogic MDBs with WebSphere MQ as an external JMS provider. We just bought MQ Extended Client that would let external transaction managers do XA management with MQ. I have looked at IBM's document @
          http://publibfp.boulder.ibm.com/epubs/pdf/csqzar00.pdf. This document indicates that Weblogic cannot be used to do XA with MQ; only three txn managers are mentioned - CICS, Encina, and Tuxedo.
          I don't believe that to be true because it says that it can be used with any XA compliant transaction manager. Is anyone aware of documents showing how to configure a WebLogic server (expecially MDBs) to use MQ extended client to do XA?

Answer 1

WL is an XA compliant TM, and many customers use it with MQ. For more information, you can start with this FAQ:
          http://e-docs.bea.com/wls/docs81/faq/interop.html#268632
          Also see the notes I've appended below.
          Finally, you can search this newsgroup - you will see that your question comes up quite a bit.
          Tom, BEA
          JMS Integration of Foreign Vendors with BEA WebLogic Server
          The following notes are derived mostly from "http://dev2dev.bea.com/technologies/jms/index.jsp".
          For additional questions, a good forum for WebLogic questions in general is "newsgroups.bea.com". These can be mined for information by using Google's newsgroup search function.
          JMS Integration Overview
          - For integration with "non-Java" and/or "non-JMS" platforms, see "Non-Java Integration Options" below.
          - For a foreign JMS vendor to participate in a WL transaction it must support XA. Specifically, it must support the javax.jms.XA* interfaces.
          - In WL versions 6.0 and up it is possible to make synchronous calls to foreign JMS vendors participate in a WL transaction as long as the foreign vendor supports XA.
          - WL 6.0 and 6.1 MDBs can be driven by foreign vendors non-transactionally. They can be driven transactionally by a select few foreign vendors (MQ is not part of the select few)
          - WL 7.0 and later, MDBs can be driven by foreign vendors transactionally and non-transationally.
          - WL 6.1 and later WL provides a messaging bridge feature. Messaging bridges forward messages between any two JMS destinations, including foreign destinations, and can transfer messages transactionally or non-transactionally.
          - WL 8.1 JMS provides additional features that simplify transactional and JNDI integration of foreign vendors. See http://edocs.bea.com/wls/docs81/jms/intro.html#jms_features
          Integration with 8.1 Details
          A good overview of 8.1 JMS interop capability is the presentation "Integrating Foreign JMS Providers with BEA WebLogic Server" here:
          http://www.bea.com/content/files/eworld/presentations/Wed_03_05_03/Application_Servers/1097-Foreign_JMS_Providers_WLS.pdf
          This document refers to helpful new 8.1 features, which simplify integration. These include:
          http://edocs.bea.com/wls/docs81/ConsoleHelp/jms_config.html#accessing_foreign_providers
          http://edocs.bea.com/wls/docs81/jms/j2ee_components.html#1033768
          And are also summarized here (under interoperability):
          http://edocs.bea.com/wls/docs81/jms/intro.html#jms_features
          Also read the MDB documentation, which extensively covers integrating foreign vendors:
          http://edocs.bea.com/wls/docs81/ejb/message_beans.html
          The 8.1 features are likely sufficient for most 8.1 integration needs, and you may not need to refer "Using Foreign JMS Providers With WLS" white-paper mentioned below.
          Integration with 6.1 and 7.0 Details
          Read the "Using Foreign JMS Providers With WLS" white-paper:
          http://dev2dev.bea.com/products/wlserver/whitepapers/jmsproviders.jsp
          Note that this white-paper does not take into account 8.1 features.
          For 7.0 read the extensive 8.1 MDB documentation, which largely also applies to 7.0:
          http://edocs.bea.com/wls/docs81/ejb/message_beans.html
          Non-Java Integration Options
          - WL JMS has a JNI based C client which is available for Windows and some UNIX platforms. This C client supports 7.0 and up, and will be officially packaged with WLS in 9.0 (virtually unchanged). The C API is currently only supported through the jms newsgroup. See "JMS C API", here:
          http://dev2dev.bea.com/technologies/jms/index.jsp
          - WL supports direct Windows COM access through its "JCOM" feature. This doesn't include the JMS API, but one can invoke EJBs which in turn invoke JMS. See
          http://e-docs.bea.com/wls/docs61/jcom.html
          http://e-docs.bea.com/wls/docs70/jcom/
          http://e-docs.bea.com/wls/docs81/jcom/
          - Similar to JCOM, but more advanced, WL supports IIOP standard based access on multiple platforms. You can use the BEA Tuxedo C client for this purpose (no license fee). This doesn't include the JMS API, but one can invoke EJBs which in turn invoke JMS. See
          http://e-docs.bea.com/wls/docs81/rmi_iiop/
          http://e-docs.bea.com/wls/docs70/rmi_iiop/
          http://e-docs.bea.com/wls/docs61/rmi_iiop/
          Unlike most other approaches, the IIOP client approach also allows the client to begin and commit user (JTA) transactions (not configured).
          - If you already have a BEA Tuxedo license, one option is communicate through BEA Tuxedo (which has various APIs on Windows) and configure a WebLogic Server to respond to these requests via the WTC bridge. Search for "WTC" in the BEA docs. Unlike most other approaches, the Tuxedo API approach also allows the client to begin and commit user (JTA) transactions.
          - Another approach is to interop via web-service standards. Or even to simply to invoke a servlet on the WL server using a basic HTTP call from Windows. These in turn can invoke the JMS API. There is a white-paper on "Interoperability Study of BEA WebLogic Workshop 8.1 and Microsoft .NET 1.1 Web Services", that demonstrates web-services here:
          http://ftpna2.bea.com/pub/downloads/WebLogic-DotNet-Interop.pdf
          - Yet another approach is to use a third party product that is designed to wrap any JMS vendor. There are even open source versions. In no particular order, here are some examples: Open3 WinJMS, CodeMesh, Active JMS, SpiritSoft
          - Finally, there are .NET/C/C++ integration libraries that not specific to JMS, some examples are JNBridge, Jace, and CodeMesh.
          Notes on MQ Remote Capable XA Clients
          Until recently, IBM MQ JMS clients could not work transactionally unless they were running on the same host as their MQ server. This is a limitation unique to MQ that was relaxed with the introduction of IBM's new "WebSphere MQ Extended Transactional Client". See:
          http://publibfp.boulder.ibm.com/epubs/pdf/csqzar00.pdf
          The product is new, and for some reason, configuration of this client seems to be tricky, even when WebLogic is not involved at all. Oddly, the main sticking point seems to be simply making sure that class paths refer to the required IBM jars:
          - Required on WLS where MQ objects are bound into JNDI:
          com.ibm.mq.jar, com.ibm.mqjms.jar
          - Required only if MQ objects are bound into JNDI on a different server:
          com.ibm.mq.jar
          If there are problems when using this client, first get it to work using a pure IBM client without any BEA classes involved. Once that is working, search the WL JMS newsgroup for answers and/or contact BEA customer support.
          Notes on Oracle AQ Integration
          If problems are encountered integrating Oracle's built-in queuing (Oracle AQ) JMS client, there is publicly available wrapper code that can aid integrating AQ directly into MDBs, JMS, or the messaging bridge. The solution is titled "Startup class to bind AQ/Referenceable objects to WLS JNDI", is not supported by BEA, and is posted to:
          http://dev2dev.bea.com/codelibrary/code/startupclass.jsp
          Caveats:
          The solution doesn't directly support concurrent consumers. Perhaps Oracle requires that concurrent consumers each have a unique JMS connection? As a work-around, parallel message processing can be achieved indirectly by forwarding AQ messages into a WL JMS destination - which do support concurrent processing.
          Up-to-date versions of Oracle may be required. For more information, google search the weblogic.developer.interest.jms newsgroup for "Oracle" and "AQ".
          The solution doesn't seem to support transactions, it may be possible to extend it to do so.
          MDB Thread Pool Notes
          WL7.0SP? and WL8.1 and later support the "dispatch-policy" field to specify which thread pool an MDB uses to run its instances. In most cases this field should be configured to help address potential performance issues and/or dead-locks:
          http://edocs.bea.com/wls/docs81/ejb/DDreference-ejb-jar.html#dispatch-policy
          (Note that "dispatch-policy" is ignored for non-transactional foreign vendors; in this case, the MDB "onMessage" callback runs in the foreign vendor's thread.)
          MDB Concurrency Notes
          Queue MDBs driven by foreign providers can run multiple instances concurrently. Topic MDBs driven by foreign providers are limited to one instance (not sure, but transactional foreign driven topic MDBs may not have this limitation). The size of the thread pool that the MDB runs in and the "max-beans-in-free-pool" descriptor limit how many instances run concurrently.
          Design Guide-Lines and Performance Tuning Notes
          The "WebLogic JMS Performance Guide" white-paper contains detailed design, performance, and tuning information for Clustering, Messaging Bridge, JMS, and MDBs.
          http://dev2dev.bea.com/products/wlserver/whitepapers/WL_JMS_Perform_GD.jsp