BEA WebLogic Server (WLS) is the most extensive J2EE application server, which has always been the most attractive platform for most corporate cases.
As part of J2EE 1.3, Java Message Services (JMS) is embedded within WLS. Its implementation takes advantage of many WLS embedded characteristics, which is more intuitive and easy to understand. For mainstream products such as WLS, it is really valuable to realize medium-size JMS.
Although the newly built JMS, WLS still retains diversity, scalability has applied, that is, in addition to providing local functions, the third party solves complex messages. For example, when there are a variety of application servers, C clients or non-Java legacy applications, the solution will be required to cover more platforms; if there is a special requirement to store clients or support large-capacity messages, specialized Solutions may be better. If the utility requirements are very high, the enterprise system designer must seek solutions to specialized message service providers.
Applying third-party JMS highly extended, the system for key tasks has many advantages, especially when there is Enterprise JavaBean (EJB) and XA Container-Managed Transaction (CMT) to participate in the configuration from the message queue. Comparison, it can make more complex processing. This issue is based primarily on two aspects: 1. Implementation of Java Transaction API (JTA) and Java Transaction Service (JTS) in WLS 6.x; two. JMS and J2EE application servers are mutually engaged in operational phases and development phases Associated issues. For the first point, cooperation with JMS suppliers is a must-have solution (unless JMS will open its internal transaction API public-Read: Open Source). For the second point, a complete solution attracts a variety of design patterns to supplement the tools provided by JMS vendors.
This paper discusses the integration of third-party JMS services and WLS, and proposes a method of implementing SonicMQ WLSADAPTER via Sonic Software to resolve the two problems described above. We will review the approach of the SonicMQ JMS implementation XA transaction and the way to establish mapping between non-standard WLS JTA, and further demonstrate all relevant issues around client connections, load JNDI, abnormal processing, and complex EJB interactions. .
WLS XA Trading and Third Party JMS Support Global Transaction (XA) or CMT, usually means special, complex issues. When WLS EJB sends or receives messages with other JMS products, and both parties have tried to participate in the transaction in a normal manner, they will often end. This is because WLS 6.x's JTA and JTS are implemented in non-standard. According to the JMS specification, the JMS provider must comply with the JTA specification, create and practical XA resources, that is, XaconnectionFactory, Xaconnection, and Xasesion objects should comply with the standard standards. Similarly, JMS must also comply with JTA standards (for details, please refer to JMS1.0.2.B) Chapter 8 http://java.sun.com/products/jms/docs. HTML). Assuming that all third-party JMS products are in line with these standards, they also expect that the application server as a JMS client fully complies with the JMS specification, ensuring that the XA-compatible operation can be successfully completed. WLS has four aspects of processing XA transactions. 1. No XaconnectionFactory, Xaconnection, or XASESSION When the J2EE application server sets XA transactions, it expects XaqueueConnectionFactory provided by external JMS or to create Xaconnection and XAsession objects. WLS only creates JMS connection and session objects, so the steps specified by the XA exchange and the specifications raised in Chapter 8 are not implemented. 2. The implementation of the XARESOURCEXA transaction must be started to start with XARESOURCE. Since WLS does not use the XaconnectionFactory object provided by third parties, there is no XARESOURCE object. Thus, in the case of a message driver bean, an external XARESOURCE object that is automatically generated under the control of the application server will never actually enter the CMT. Similarly, session beans can also call XAResource directly, XARESOURCE cannot be created here. 3. The proprietary session interface WLS requires the external JMS session object to implement a specified special interface -Weblogic.jms.Extensions.mdbtransaction. This interface contains a method AssociateTransAction (), WLS will enter this method in the CMT to enter the JMS Trading Manager. Since this interface is non-standard, the third party's JMS vendor must contain an adapter to implement it. WLS checks whether the session object is internally supported, if not, the container will throw an exception. 4. The XA transaction branch is not serialized according to the JTA specification, and all the branches of all XA transactions must be carried out in a serial manner. However, WLS is managed in another way, which allows for the second transaction branch provided by the external transaction manager to the container until other transaction branches are not completed. This happens due to the start branch and end branch of the transaction belong to different threads in WLS. The action of the "start" thread has been completed, allowing the next transaction branch to start, and the "end" action of the first transaction branch is not completed. Compatible with JMS1.0.2's product expectations XA transaction branch to follow JTA's specifications, executed in serial order, will believe that any overlapping transaction branch violates the JTA protocol. Therefore, when overlapping trading occurs, the exception will be thrown in accordance with the implementation of JMS, unless the JMS supplier provides non-standard implementation as a variation. Enter WebLogic Server Adapter (WLSADAPTER)
Despite these problems, third-party JMS suppliers who want to join the WebLogic market have a clear goal for providing integrated programs. Most vendors make up the difference between the rules of JMS Chapter 8 by including the adapter. The difference between the "ISWS" feature of the WLS existing version. The implementation of the adapter is very eye-catching, not only they guarantee the stability of the XA function, but also how they provide first-class, scalable solutions. SonicMQ is an advanced enterprise message platform that solves the integrated problem between WLS and SonicMQ from Sonic Software to WLSADAPTER. The implementation of this program also involves other important integrated puzzles, including: 1. Client automatic connection and JNDI load. 2. When testing the abnormal processing logic during the development phase, the incorrect occurrence is promoted. 3. Provide a stable design template for complex JMS structures. XA transaction integration
The application server provides XA trading function and supports cooperation with third-party JMS, must have the ability to have the following capabilities: 1. Create and manage JMS connection and sessions. 2. Create and manage Xaconnection and XASESSION. 3. Enable XARESOURCE. WLS can create and manage JMS connection and sessions, but cannot create XA transactions and enable XAResource. To solve this problem, WLSADAPTER creates and manages all XaconnectionFactories, Xaconnection, XAsession, and XARESOURCE. When Wlsadapter creates XASSSION, it will create a separate XAResource object (called Singleton) in the JVM, contacting the WLS's transaction manager when each XA transaction is performed. The actual XAResource provided in the JMS Trading Manager is created by WLSADAPTER and registered with Singleton, which in turn calls all the WLS trading manager all the WLS Trading Manager to call the appropriate SonicMQ XARESOURCE. The adapter manages all SonicMQ XA branches internally. In the case of a message-driven bean (MDB), WLSADAPTER will automatically enable XareSource for each transaction, and the session bean will pass the WLS TXHELPER, Javax.Transaction.Transaction Txn = WebLogic.TransAction.txhelper.getTransAction (), Explicitly enable XARESOURCE (Enabled by direct calls: txn.enListResource (MyXARESource). The effect is equivalent to the JMS adapter provides a small transaction manager for the WLS trading manager as a separate resource participation transaction. Due to the XARESOURCE for the WLS trading manager Can be obtained, therefore solves the first two problems. WLSADAPTER Solve the third problem is the method of implementing the BEA proprietary interface-MdbTransAction, in its session object, using the associateTransaction () method to trigger automatic enabling mode when MDB transaction. Since the method is implemented in the session object of the adapter, WLS no longer throws an exception. Finally, WLSADAPTER solves the fourth problem to manage the XA transaction branch to ensure their serial order. When WLS allows transaction branch overlap When it first stores the exception of SonicMQ in the cache and controls the overlapping trading branch without execution until the previous transaction is completed, let the next transaction branch started. Exception is blocked, branch overlap is avoided, XA transaction and The JTA specification has been consistent. Using SonicMQ's WLSADAPTER, all WLS and XA compatible issues have been solved, providing a complete solution for enterprise JMS, which complies with JTA global transaction protocol.
Other challenges in integration
Considering the operating phase and the development phase introduce the adapter to enhance the stability of the enterprise solution, and join the value-added characteristics to provide an opportunity. The main consideration includes automatic re-establishment of the agent or connection failure; for the test application level exception control providing tool (especially the recovery logic on the connection and the transaction level). Client Auto Rebuilding Rebuild Connections and Error Recovery is very important to any large distributed applications. Both WebLogic and SonicMQ provide clustering and reconnection features. Figure 1 is a typical weblogic cluster configuration diagram, which has two servers. Figure 1. Any WLS in a typical cluster configuration cluster can access Topic A and Topic B. However, the subject matter must be created in advance, the subject information is connected to a local dedicated server. In the event instance A, the information is introduced to other servers in the cluster, and Topic A will no longer be accessed. Figure 2 demonstrates the situation of working together with the SonicMQ cluster, and therefore has the function of rebuilding the connection due to the use of WLSADAPTER. In this example, no matter which WLS instance fails, through SonicMQ, all the topics remain valid. In addition, if any SonicMQ proxy fails, all information will be automatically restored to backup servers or servers, and the subject information will not be lost. If you use WLSADAPTER in SonicMQ, the topic can be dynamically created, and the information can also be shared within the JMS cluster. In the first example (no WLSADAPTER), if you want to re-establish the connection, when the agent fails, the message generator in EJB or synchronous message users must capture abnormalities, explicitly in the application logic. Re-establish the connection, rebuild all session objects. WLS is indeed re-established in MDB, but the listener cannot be rebuilt, so there is a possibility to lose the message. The solutions provided by WLSADAPTER are as follows: 1. For users, the connection failed to be completely masked. 2. Connection reconstruction depends on the list of URLs. 3. Make sure that the session object and the generator and the user of the message are recreated. Since the connection failure and connection rebuild are completely transparent to user and business logic, the developer is fully free of writing code and managing connection reconstruction. Fault insertion point
WLSADAPTER can insert a fault point for program tracking and analysis. The purpose of this is mainly focused on solving the tricky problem - integrated testing of the development phase, that is, introduced to control, but is actual fault to test an exception capture path. WLSADAPTER provides two types of fault insert: connection failure and method call failure. Connection failure faultless fault failure makes the application pause within the specified method. Using this method, developers can take an action outside the application to work in the designated place during application execution. For example, if you want to test the connection failure or the response of the agent, you can randomly unplug the cable or turn off the proxy server. Although the test example can be generated, they cannot be reliably reproduced. With SonicMQ WLSADAPTER, it is possible to execute the onMessage () method in a particular method, such as the onMessage () method in MDB, and the fault failure occurs, so that the fault point is isolated. When the method is called, the adapter will suspend the application. At this point you can force the agent connection to disconnect and simulate the fault. After the fault point is released, the subsequent execution of the application will reveal the abnormal logic to cope with the fault. Methods to perform faulty methods perform faults in design ideas, but it only enforces a specific method to throw an exception without requiring intervention of developers (such as killing proxy servers or unplug the cable, etc.). When the method's fault point is set, the program is suspended when executing the specified method; the choice will appear: Is it allowing the method to throw an exception or continue normal execution. There are 10 ways to set up a connection failure and method failure. The five of them are used in the JMS method, other for XA transactions. Applications only need to set a fault point in WLSADAPTER, perform problematic programs and methods, and do not need to embed temporary test logical statements in application code. Table 1 lists methods that may set a fault point in JMS and XA. Inserting the WEBLOGIC is very simple, just put the WLSADAPTER package into the classpath launched in the WebLogic domain, and add the following to the startup flag of the application server: -dsonicsw.wlsadapter.test.dofail = true-dsonicsw. Wlsadapter.test.failType =% 1-dsonicsw.wlsadapter.test.failpoint =% 2 Parameters% 1 is "ConnectionDrop" or "MethodFail"; parameter% 2 represents a method in Table 1. Table three enterprise design model Advanced transaction design implementation template can be included in the adapter package as the value-added characteristics. Enterprise EJB using JMS usually requires several BEANs to interact in transactions. These complex situations make it necessary to ensure that smart construction and conversation pools designed for scalability for stability. For example, a general environment may require MDB as a user to listen to the PUB / SUB subject for RFP. When the RFP message arrives, it may need to store documents to a local database via entity beans; session beans will generate response information and send it to the requester via a point-to-point queue. In an environment where the throughput is a large environment, the queue sent outward may put session beans into the buffer pool for extended considerations. In this case, both MDB, entity beans, and session beans are components of a single transaction, two two two two-way transactions with JMS trading manager. WLSADAPTER completely solves these problems around the enterprise. It contains prefabricated code design templates inside, which support multiple beans to interact. Solutions show a stable, light, environmental-free environment for the producers and users of the message.
Future Prospects Sonic WLSADAPTER contains 5 main JMS trading design modes (see Figure 3), they are: 1. Message driver bean2. Message Drive BEAN router 3. Message generate bean4. Message uses bean5. Message In the second part of this article, we will describe the implementation of partial design patterns that use SonicMQ and WLSADAPTER as the JMS solution. The specific implementation will involve: 1. Message Driver BEAN (with queue listener) 2. Message driver bean (reconstructed with the subject listener and connection) 3. Message uses bean4. Message generates bean (with JMS crossover domain and connection reconstruction )
We will use RFI / RFP to use RFI / RFP to make a combination design pattern with RFI / RFP between multiple beans.
Note: So many problems may be, some may ask: How to embed JMS in it and run? How is WebLogic? How is it how through Sun's J2EE 1.3 CTS? The answer comes from two aspects: First, Sun CTS only confirms its compliance norms from the API level, and does not specify the implementation, which means that many internal functions are flexible. This also leads to the second answer: embedded JMS and other parts of the WLS container share the transaction manager. Since only one trading manager processes the transaction, WLS can integrate all XA integration in its own environment, while in line with the CTS API level.
