当前，CORBA、DCOM、RMI等RPC中间件技术已广泛应用于各个领域。但是面对规模和复杂度都越来越高的分布式系统，这些技术也显示出其局限性：（1）同步通信：客户发出调用后，必须等待服务对象完成处理并返回结果后才能继续执行；（2）客户和服务对象的生命周期紧密耦合：客户进程和服务对象进程都必须正常运行；如果由于服务对象崩溃或者网络故障导致客户的请求不可达，客户会接收到异常；（3）点对点通信：客户的一次调用只发送给某个单独的目标对象。
   面向消息的中间件（Message Oriented Middleware，MOM）较好的解决了以上问题。发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中，在合适的时候再将消息转发给接收者。这种模式下，发送和接收是异步的，发送者无需等待；二者的生命周期未必相同：发送消息的时候接收者不一定运行，接收消息的时候发送者也不一定运行；一对多通信：对于一个消息可以有多个接收者。
   已有的MOM系统包括IBM的MQSeries、Microsoft的MSMQ和BEA的MessageQ等。由于没有一个通用的标准，这些系统很难实现互操作和无缝连接。Java Message Service（JMS）是SUN提出的旨在统一各种MOM系统接口的规范，它包含点对点（Point to Point，PTP）和发布/订阅（Publish/Subscribe，pub/sub）两种消息模型，提供可靠消息传输、事务和消息过滤等机制。

1.JMS
   JAVA 消息服务(JMS)定义了Java 中访问消息中间件的接口。JMS 只是接口，并没有给予实现，实现JMS 接口的消息中间件称为JMS Provider，iLink实现了JMS接口，用户可以通过使用JMS接口，在iLink中进行JMS编程。 iLink支持JMS1.0.2版本。

2.JMS接口描述
   JMS 支持两种消息类型PTP 和Pub/Sub，分别称作：PTP Domain 和Pub/Sub Domain，这两种接口都继承统一的JMS父接口，JMS 主要接口如下所示：

MS父接口 PTP Pub/Sub ConnectionFactory QueueConnectionFactory TopicConnectionFactory Connection QueueConnection TopicConnection Destination Queue Topic Session QueueSession TopicSession MessageProducer QueueSender TopicPublisher MessageConsumer QueueReceiver,QueueBrowse r TopicSubscriber

                  
   ConnectionFactory ：连接工厂，JMS 用它创建连接
   Connection ：JMS 客户端到JMS Provider 的连接
   Destination ：消息的目的地
   Session： 一个发送或接收消息的线程
   MessageProducer： 由Session 对象创建的用来发送消息的对象
   MessageConsumer： 由Session 对象创建的用来接收消息的对象

3.JMS消息模型
JMS 消息由以下几部分组成：消息头，属性，消息体。
  
3.1 消息头(Header) - 消息头包含消息的识别信息和路由信息，消息头包含一些标准的属性如：JMSDestination,JMSMessageID 等。

消息头  由谁设置 JMSDestination send 或 publish 方法 JMSDeliveryMode send 或 publish 方法 JMSExpiration send 或 publish 方法 JMSPriority send 或 publish 方法 JMSMessageID send 或 publish 方法 JMSTimestamp send 或 publish 方法 JMSCorrelationID 客户 JMSReplyTo 客户 JMSType 客户 JMSRedelivered JMS Provider

Some XA JDBC drivers do not support local transaction operations, which can cause an error similar to the following when optimistic concurrency is used with such a driver:

SQL operations are not allowed with no global transaction by default for XA drivers.

In other words, the error will occur when SupportsLocalTransactions="true" is specified for the JDBCConnectionPool.

This problem occurs because optimistic concurrency suspends a global transaction and does reads in a local transaction when the database is not Oracle. (When using Oracle, you can avoid this problem by explicitly setting <database-type>Oracle</database-type> in your CMP deployment descriptor.)

Workaround : Use the "RollbackLocalTxUponConnClose" on the JDBCConnection.

If you encountered “ Cannot call Connection.commit in distributed transaction ” error, should check the weblogic connection pool and the datasource

If the connection pool is XA,

you should make sure that when you create the datasource to make it XA by select the check from "Honor Global Transaction" from the weblogic console.(default is selected)

If the connection pool is non-XA

    <[ServletContext(id=18489944,name=EBLGWeb,context-path=/)]: Deployment descriptor "/WEB-INF/bhr-tags-pagination.tld" is malformed. Check against the DTD: Content is not allowed in prolog. (line 1, column 1).>
    <[ServletContext(id=18489944,name=EBLGWeb,context-path=/)]: Error while parsing the Tag Library Descriptor at "/WEB-INF/bhr-tags-pagination.tld".
org.xml.sax.SAXException: [HTTP:101248][ServletContext(id=18489944,name=EBLGWeb,context-path=/)]: Deployment descriptor "/WEB-INF/bhr-tags-pagination.tld" is malformed. Check against the DTD: Content is not allowed in prolog. (line 1, column 1).
        at weblogic.apache.xerces.parsers.DOMParser.parse(DOMParser.java:285)
        at weblogic.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:201)
        at weblogic.servlet.jsp.dd.JSPEntityResolver.load(JSPEntityResolver.java:81)
        at weblogic.servlet.jsp.dd.JSPEntityResolver.load(JSPEntityResolver.java:96)
        at weblogic.servlet.internal.WebAppHelper.registerTagLibListeners(WebAppHelper.java:293)
        at weblogic.servlet.internal.WebAppServletContext.activateFromDescriptors(WebAppServletContext.java:2530)
        at weblogic.servlet.internal.WebAppServletContext.activate(WebAppServletContext.java:6163)
        at weblogic.servlet.internal.WebAppServletContext.setActive(WebAppServletContext.java:6141)
        at weblogic.servlet.internal.WebAppModule.activate(WebAppModule.java:836)
        at weblogic.j2ee.J2EEApplicationContainer.activateModule(J2EEApplicationContainer.java:3322)
        at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2201)
        at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2174)
        at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2122)
        at weblogic.management.deploy.slave.SlaveDeployer$Application.setActivation(SlaveDeployer.java:3099)
        at weblogic.management.deploy.slave.SlaveDeployer.setActivationStateForAllApplications(SlaveDeployer.java:1768)
        at weblogic.management.deploy.slave.SlaveDeployer.resume(SlaveDeployer.java:351)
        at weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.resume(DeploymentManagerServerLifeCycleImpl.java:229)
        at weblogic.t3.srvr.SubsystemManager.resume(SubsystemManager.java:136)
        at weblogic.t3.srvr.T3Srvr.resume(T3Srvr.java:965)
        at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:360)
        at weblogic.Server.main(Server.java:32)
>

是由于某些文本编辑器（UltraEdit）存文本的时候产生的问题。可以使用text pad, word pad编辑XML格式的文件。

通过HTTP提交EDI请求,当EDI处理时间超过了20分钟后,就会看到在另一个weblogic server也接收到了这个EDI请求,重新处理这个报文.
如果报文处理时间更长,比如超过了50分钟,就会发现这个报文被处理了3遍或5遍.

When the Apache HTTP Server Plug-In attempts to connect to WebLogic Server, the plug-in uses several configuration 
parameters to determine how long to wait for connections to the WebLogic Server host and, after a connection is
established, how long the plug-in waits for a response. If the plug-in cannot connect or does not receive a response, 
the plug-in attempts to connect and send the request to other WebLogic Server instances in the cluster. If the 
connection fails or there is no response from any WebLogic Server in the cluster, an error message is sent.


响应等待时间参数WLIOTimeoutSecs (http://e-docs.bea.com/wls/docs81/plugins/plugin_params.html#1149781.
按照BEA 推荐的，这个值应该设得大一些, 这个参数的缺省值为300s. 见下面：
<Location /EDIHandler>
         SetHandler weblogic-handler
         WebLogicCluster apc_app1wls1:7011,apc_app1wls2:7011
         KeepAliveEnabled ON
         WLIOTimeoutSecs 7200
</Location>

有时候使用的mq jar文件的版本不对给出现一些末名奇妙的问题,本文则是能接收消息但不能发送消息的一个问题.碰到这样的问题一定要记得double-check你使用的mq jar文件的版本

MQJMS200713 Oct 2006 16:47:15,484 ERROR MessagingUtilServlet [ExecuteThread: '14' for queue: 'weblogic.kernel.Default'][]: **********EXCEPTION TRACE START*************
13 Oct 2006 16:47:15,484 ERROR MessagingUtilServlet [ExecuteThread: '14' for queue: 'weblogic.kernel.Default'][]: produce error
com.bhr.infra.messaging.exception.PMException: JMSException
        at com.bhr.infra.messaging.PMHandler.send(PMHandler.java:419)
        at com.bhr.epc.infra.messaging.util.MessagingUtilServlet.produce(MessagingUtilServlet.java:312)
        at com.bhr.epc.infra.messaging.util.MessagingUtilServlet.service(MessagingUtilServlet.java:74)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6981)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
        at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892)
        at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
Caused by: javax.jms.JMSException: MQJMS2007: failed to send message to MQ queue
        at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:553)
        at com.ibm.mq.jms.MQMessageProducer.sendInternal(MQMessageProducer.java:1589)
        at com.ibm.mq.jms.MQMessageProducer.send(MQMessageProducer.java:1012)
        at com.ibm.mq.jms.MQMessageProducer.send(MQMessageProducer.java:1046)
        at com.bhr.infra.messaging.PMQueueSender.send(PMQueueSender.java:57)
        at com.bhr.infra.messaging.PMHandler.send(PMHandler.java:410)
        ... 13 more
13 Oct 2006 16:47:15,486 ERROR MessagingUtilServlet [ExecuteThread: '14' for queue: 'weblogic.kernel.Default'][]: **********EXCEPTION TRACE END**************

It may be caused by use of old version MQ jar. It can receive message, but cannot send message.

如果你碰到"Cannot Forward a Response that is Already Committed"这样的错误信息,一定是应用对一次http请求做了多次页面跳转或对response对象做过close后,又去写响应.

这个问题的根本原因由于响应本次请求的Response对象的状态是已提交状态造成的, 它不允许响应提交多次。

什么时候Response对象的状态变成已提交状态：当你的应用已经实现了页面跳转逻辑。

通常原因：

1． 如果你使用了community的话， community的安全认证和授权如果没有通过，community内部会进行页面跳转。但你的应用(对于workshop应用的话，指的是action)又试图进行页面跳转，就会出现这样的问题。


    /**

     * @jpf:action

     * @jpf:forward name="page" path="page.jsp"

     */

    protected Forward actionMethod()

{

    //如果已经提交了响应，你仍然试图再次进行页面跳转，即再次提交响应，可能出现问题

    //通常可以加一个判断

 

       if (!getResponse().isCommitted()) {

            return new Forward("success");

        } else {

            return null;

        }

    }

 

    protected void beforeAction() {

       SecurityManager.checkAuthorization(getRequest(), getResponse(), config.getString(

                CDConstants.CREATE_TERM_ACTION_NAME, ""));

      //这个调用可能实现了页面跳转，即提交响应

}

 

注意JSP中实现页面跳转后，加return 语句防止继续提交响应:

 

<%

       SecurityManager.checkAuthorization(getRequest(), getResponse(), config.getString(

                CDConstants.CREATE_TERM_ACTION_NAME, ""));

{

     //可能有实现页面跳转逻辑

    ……………forward();

        return;//记得加retrun.

    }

%>

 

2. .如果没有使用community的话，下面情景也会出现这个问题

 

    /**

     * @jpf:action

     * @jpf:forward name="page" path="page.jsp"

     */

    protected Forward actionMethod()

 

//直接操作Response对象写响应

     getResponse().getPrintWriter().println();

    …

/

   // 又执行的页面跳转，也可能出现问题

        return new Forward("index");

    }

一个页面流在第一次使用时,内部属性currentpage并没有指定页面,所以避免在begin方法里使用return-to: current page用法.同时在用的时候注意页面流的工作方式

Error message like below in Web Page is displayed:

Page Flow:
 /com/xxxx/xxx/xxx.jpf
Action:
 update
 
Page Flow Error - No Relevant Page
You have tried to return to a recent page in the current page flow through return-to="currentPage", 
but there is no appropriate page. 


Exception's stack trace:

Exception: No previous page for return-to="currentPage" on action create in page flow
 /com/gems/mt/web/CreateReleaseCntr/CreateReleaseCntrController.jpf.
com.bea.wlw.netui.pageflow.NoPreviousPageException: No relevant page for return-to="currentPage" 
on action create in page flow /com/gems/mt/web/CreateReleaseCntr/CreateReleaseCntrController.jpf.
at com.bea.wlw.netui.pageflow.FlowController.doReturnToPage(FlowController.java:1328)
at com.bea.wlw.netui.pageflow.FlowController.forwardTo(FlowController.java:1023)
at com.bea.wlw.netui.pageflow.PageFlowController.forwardTo(PageFlowController.java:606)
at com.bea.wlw.netui.pageflow.FlowController.internalExecute(FlowController.java:765)

...

When a new page flow is created and its current page is null (it mean you visit at the fist time),
 so such an exception like NoPreviousPageException occur if you use return-to="currentPage".

if a new page flow finish a successful forward, it will treat last page as current page

so that we can use current page to display error message conveniently.

Solution:

ensure page flow finish a successful forward and use current page again.

You can also use path="specificPage.jsp" instead of return-to="currentPage" 
if your original return-to is just one specific page.

We have known, the ListCellRenderer interface has only one method public Component getListCellRendererComponent(), and it returns a Component. When a JList needs to compute its dimension or paint its cell item, this method will be called. So it will be called frequently, and we have a best practice, try to reuse object, avoid time-consumed computation and unnecessary operation in this method.

Recently found, there is a memory leak bug for list cell renderer in both JDK 1.4.x and JDK 5 (don’t know whether has the same bug in earlier JDK). The component returned from getListCellRendererComponent() method could not be GC, and all its referenced objects also could not be GC. Unfortunately, this bug is only fixed in JDK 6.

So currently, if a JList use the ListCellRenderer, but only holds a little resource (eg: the JList only has little items, and the component is returned from ListCellRenderer is a simple JLable), you may not care about the memory leak.

But if a JList use the ListCellRenderer, and holds a large resource, you should remember to use the following way to avoid memory leak.

Work Around: Subclass JList and invoke removeAll after painting is done:

       public class xxxList extends JList {

            private CellRendererPane renderer;

            private CellRendererPane getRenderer() {

                if (renderer == null) {

                    for (int i=0; i<getComponents().length; i++) {

                                          Component c  = getComponents()[i];

                        if (c instanceof CellRendererPane) {

                            renderer = (CellRendererPane)c;

                            break;

                        }

                    }

                }

                return renderer;

            }

            protected void paintComponent(Graphics g) {

                super.paintComponent(g);

                CellRendererPane renderer = getRenderer();

                if (renderer != null) {

                    renderer.removeAll();

                }

            }

Please note that in the state classes, if a method is supported by stateA and not supported by stateB. 
Then, in stateB, the method body will throw an exception (IllegalArgumentException) to indicate that coder call the wrong method in the wrong state.

Example, in VesselPlanView.java, public boolean addStowage(...).  This method is only meaningful to stowageView.

public boolean addStowage(IlvManager manager, List transformList, IlvGraphic stowage, String stadBayN,
                              boolean isSelect) {
        throw new IllegalArgumentException(
                "GrVessel::addStowage-->be sure the vessel at stowage view!");
    }


Hence, in PlanView, the method body will throw exception.

Just to share with you a better way to code.

使用 IlvToolTipManager 创建一个多行的 tooltip ：  

1) 首先需要注册 view (IlvManagerView)I
lvToolTipManager.registerView(view);  

2) 创建需要显示的信息的数组，即每行的信息为数组中的一个元素：
new String[] tooltipArray ;  

3) 创建 tooltip, 第一个参数是上面创建的数组，第二个参数是显示位置，必须是 SwingConstants.LEFT , RIGHT , or CENTER String tooltip = IlvToolTipManager.createMultiLineToolTipText(tooltipArray, SwingConstants.LEFT);  

4) 设置 tooltip ：
IlvGraphic.setToolTipText(tooltip);



public static String createMultiLineToolTipText(String as[], int i)
    {
        String s;
        switch(i)
        {
        case 2: // '\002'
            s = "left";
            break;

        case 4: // '\004'
            s = "right";
            break;

        case 0: // '\0'
            s = "center";
            break;

        case 1: // '\001'
        case 3: // '\003'
        default:
            throw new IllegalArgumentException("Alignment must be LEFT, RIGHT, or CENTER");
        }
        Font font = UIManager.getFont("ToolTip.font");
        StringBuffer stringbuffer = new StringBuffer("<p align=\"");
        stringbuffer.append(s);
        stringbuffer.append("\" style=\"font-family:");
        stringbuffer.append(font.getName());
        stringbuffer.append(";font-size:");
        stringbuffer.append(font.getSize());
        stringbuffer.append("pt\">");
        String s1 = stringbuffer.toString();
        StringBuffer stringbuffer1 = new StringBuffer("<html>");
        for(int j = 0; j < as.length; j++)
        {
            stringbuffer1.append(s1);
            stringbuffer1.append(as[j]);
            stringbuffer1.append("</p>");
        }

        stringbuffer1.append("</html>");
        return stringbuffer1.toString();
    }

时间：2006-06-27 作者：孟和 浏览次数： 1229 本文关键字：WebLogic, MQ, JMS, MQSeries, JMS Bridge

文章工具  推荐给朋友  打印文章

　　最近参与一个系统的原型开发,原型要求演示WebLogic Server9.1与其他第三方产品的通信支持,包括与IBM MQSeries的双向交互、与Tuxedo的双向交互、支持与.NET的通过Web Service交互等。我负责完成与IBM MQSeries的双向交互这部分，在网上找了不少文章，发现其中基本都是基于WebLogic Server 8.1实现的。因为WebLogic Server 9.1在JMS上有很大的增强，所以我参考以前的文章，自己实现了WebLogic Server 9.1与IBM MQSeries 5.3的双向交互并且进行了测试。想必很多同行会遇到跟我一样的问题，特此撰文一片跟大家分享。本文配置在window xp上测试成功。

概述

　　目标是实现WebLogic Server 9.1和IBM MQSeries5.3之间的的双向交互，包括：

• WebLogic Server 9.1消息转发给IBM MQSeries5.3
• IBM MQSeries 5.3消息转发给WebLogic Server 9.1

　　具体地，将WebLogic Server9.1队列WLSSendQueue的消息转发到IBM MQSeries 5.3队列MQReceiveQueue，同时将IBM MQSeries 5.3队列MQSendQueue的消息转发到WebLogic Server 9.1队列WLSSendQueue。

　　WebLogic Server包含一个完整的、有丰富特性的消息服务器。第三方的消息服务器(如IBM MQSeries)，只要其提供了JMS API的实现，也可以在其中运行。Messaging Bridge是一种由WebLogic Server提供的J2EE设备，用于转发两个消息提供者的消息。你可以使用Messaging Bridge将消息从一个消息提供者的目的地（队列或者主题）移至另外一个消息提供者的目的地。因此，当WebLogic应用程序需要与第三方消息提供者 （比如IBM MQSeries）进行交互时，Messaging Bridge就可以承担这个中间角色。我们需要做如下配置：

• 通过WebLogic控制台建立两个WebLogic队列：发送队列WLSSendQueue和接收队列WLSReceiveQueue。
• 类似地，通过MQ资源管理器建立两个MQ本地队列：发送队列MQSendQueue和接收队列MQReceiveQueue。
• 为 了实现消息转发需要建立两个Messaging Bridge：WLS2MQBridge 和MQ2WLSBridge 。WLS2MQBridge：将WebLogic发送队列WLSSendQueue的消息转发到MQ接收队列MQReceiveQueue； MQ2WLSBridge：将MQ发送队列MQSendQueue的消息转发到WebLogic接收队列WLSReceiveQueue。
• 为 了实现事务性消息转发， WebLogic需要使用XAQueueConnectionFactory，而MQ需要使用MQXAQueueConnectionFactory。这 就确定了WebLogic需要使用支持XA的连接工厂，MQ必须采用绑定的模式，并且WebLogic和MQ必须安装在同一台机器上。

WLS配置

　　WebLogic Server 9.1在WebLogic JMS的配置、部署和动态管理方面引入了重要的改进。它对JMS 1.1规范提供官方支持。此外，在系统中添加了人们期待已久的消息排序高级特性。XML API的XML消息处理功能得到了增强。在WebLogic 9.1平台上使用JMS非常轻松有趣、可靠且迅速。下面是现有新特性中的一些亮点。

• 自动化的 JMS 故障恢复

  　　自动化的JMS故障恢复是业内期待已久的特性。JMS利用“Automatic WebLogic Server Migration”特性来提供自动化的JMS故障恢复。在整个WebLogic Server实例进行故障恢复时，JMS也将自动从故障中恢复过来。尽管其他的一些JMS服务器提供商已经利用一些复杂装置提供了这样的功能，但 WebLogic 9.1的实现是最直观而清晰的。

• 排序单元

  　　消息排序是大多数消息处理应用程序的一项基本要求。WebLogic Server JMS即使在集群环境中也能确保消息的顺序处理。它甚至可以定义多个组来将消息分组，这样每个组都拥有自己的处理顺序（如图1所示）。

  

• 存储转发 (SAF)

  　　WebLogic存储转发(store and forward, SAF)服务使WebLogic Server能在通过WebLogic Server实例部署的应用程序间可靠地交付信息。SAF的强大功能使得我们可以很容易地将多个消息服务链接在一起（如图2所示）。

  

• Messaging Bridge具有如下优点：
  • 不需要编码，纯配置，加速你的开发；
  • 灵活的体系结构，容易配置多个Messaging Bridges，并且而且可以动态的启动和停止单个Messaging Bridge；
  • 采用即取即用的MQ 适配器，实现全面的MQ JMS 支持，能够设定MQ 主题查询；
  • 充分利用WebLogic容器进行服务管理，并且集中所有的Bridges资源在一个线程池；
  • 全面的事务处理能力，两阶段事务处理；
  • 全面的JCA 支持；
  • 确保服务质量和连接管理，实实在在的一次性服务；
  • 控制台监视能力；
  • 集成BEA WebLogic应用与外部消息提供商，以便将新的应用与现有的投资连接起来。

创建Server域

　　创建Server Domain, domain名称jms_domain

修改启动文件

　　修改WebLogic的启动文件startWebLogic.cmd。将IBM MQSeries和IBM MQSeries Java的安装目录加到WebLogic path下，同时将MQ JMS Java类包加入到WebLogic classpath下：

@rem added the following to configure messaging bridge with local MQSeries installation
set MQ_INSTALL_PATH=D:\installed\MQ
set MQ_JAVA_INSTALL_PATH=D:\installed\MQ\Java
set MQ_JAVA_LIB=%MQ_JAVA_INSTALL_PATH%\lib
set MQ_CLASSPATH=%MQ_JAVA_LIB%\com.ibm.mq.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\com.ibm.mqbind.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\com.ibm.mqjms.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\fscontext.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\jms.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\jndi.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\jta.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\ldap.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\providerutil.jar

set MQ_PATH=%MQ_INSTALL_PATH%\in;%MQ_JAVA_INSTALL_PATH%\in;
       %MQ_JAVA_INSTALL_PATH%\lib
set PATH=%MQ_PATH%;%PATH%
set CLASSPATH=%MQ_CLASSPATH%;%WEBLOGIC_CLASSPATH%;
       %POINTBASE_CLASSPATH%;%JAVA_HOME%\jre\lib\rt.jar;
      %WL_HOME%\server\lib\webservices.jar;%CLASSPATH%

配置JMS

　　注意WLS91的连接工厂和队列要到JMS Modules下面设置：

• 创建文件后备存储BridgeFileStore
• 创建JMS服务器BridgeJMSServer，和Paging Store设为" BridgeFileStore" ，Target为adminServer
• 创建支持XA的连接工厂WLSCFXA，JNDI Name为bridge.wlsCFXA
• 创建JMS发送队列WLSSendQueue，JNDI名称为bridge.wlsSendQueue，Target为BridgeJMSServer
• 创建JMS接收队列WLSReceiveQueue，JNDI名称为bridge.wlsReceiveQueue，Target为BridgeJMSServer

  

配置Messaging Bridge Destination

• JMS Bridge Destination名称为MQReceiveBridgeDestination
  • Adapter JNDI Name: eis.jms.WLSConnectionFactoryJNDIXA
  • Connection URL为file:/D:/installed/MQ/Queues，
  • Initial Context Factory为com.sun.jndi.fscontext.RefFSContextFactory，
  • Connection Factory JNDI Name为bridge.mqQCFXA,
  • Destination JNDI Name为bridge.mqReceiveQueue
  • Destination Type: Queue
• JMS Bridge Destination名称为MQSendBridgeDestination
  • Adapter JNDI Name: eis.jms.WLSConnectionFactoryJNDIXA
  • Connection URL为file:/D:/installed/MQ/Queues，
  • Initial Context Factory为com.sun.jndi.fscontext.RefFSContextFactory，
  • Connection Factory JNDI Name为bridge.mqQCFXA,
  • Destination JNDI Name为bridge.mqSendQueue
  • Destination Type: Queue
• JMS Bridge Destination名称为WLSReceiveBridgeDestination
  • Adapter JNDI Name: eis.jms.WLSConnectionFactoryJNDIXA
  • Connection URL为t3://localhost:7001，
  • Initial Context Factory为weblogic.jndi.WLInitialContextFactory，
  • Connection Factory JNDI Name为bridge.wlsCFXA,
  • Destination JNDI Name为bridge.wlsReceiveQueue
  • Destination Type: Queue
  • User Name: weblogic（域配置时指定的）
  • User Password: weblogic（域配置时指定的）
• JMS Bridge Destination名称为WLSSendBridgeDestination
  • Adapter JNDI Name: eis.jms.WLSConnectionFactoryJNDIXA
  • Connection URL为t3://localhost:7001，
  • Initial Context Factory为weblogic.jndi.WLInitialContextFactory，
  • Connection Factory JNDI Name为bridge.wlsCFXA,
  • Destination JNDI Name为bridge.wlsSendQueue，
  • Destination Type: Queue
  • User Name: weblogic（域配置时指定的）
  • User Password: weblogic（域配置时指定的）

配置Messaging Bridge

• JMS Bridge名称为MQ2WLSBridge
  • Source Bridge Destination:　　MQSendBridgeDestination
  • Target Bridge Destination:　　WLSReceiveBridgeDestination
  • Quality Of Service:　　　　　　Exactly-Once
  • Started:　　　　　　　　　　　　Yes
• JMS Bridge名称为WLS2MQBridge
  • Source Bridge Destination:　　WLSSendBridgeDestination
  • Target Bridge Destination:　　MQReceiveBridgeDestination
  • Quality Of Service:　　　　　　Exactly-Once
  • Started:　　　　　　　　　　　　Yes

  

MQ 配置

　　IBM MQSeries是IBM的商业通讯中间件(Commercial Messaging Middleware)。IBM MQSeries提供一个具有工业标准，安全，可靠的信息传输系统。它的功能是控制和管理一个集成的商业应用，使得组成这个商业应用的多个分支程序(模块)之间通过传递信息完成整个工作流程。IBM MQSeries具有特殊的技术防止信息重复传送，确保信息一次且仅一次(once-and-only-once)传递，保证传输的可靠性。本文使用的 MQ版本为IBM MQSeries 5.3。

　　IBM MQSeries基本由一个消息传输系统和一个应用程序接口组成，其资源是消息和队列(Messaging and Queuing)。

　　队列管理器（Queue Manager）：管理队列的系统，实现网络通信，保证消息安全可靠地传输到目的地。用于确保队列之间的信息提供，包括网络中不同系统上的的远程队列之间的信息提供。并保证网络故障或关闭后的恢复。

　　队列：一个安全的信息存储区。因为信息存放在队列中，所以应用程序可以相互独立的运行，以不同的速度，在不同的时间，在不同的地点。

　　本地队列：对程序而言，本地队列属于该程序所连接的队列管理器。

　　远程队列：该队列不属于该程序所连接的队列管理器，而只是远端队列管理器的队列在本地的定义。

　　传输队列：它是一个本地队列，保存了指定要发送到远端的消息。

　　死信队列：它是一个本地队列，用于存放无法传递的消息。

　　通道：在两个队列管理器之间建立起来的数据传输链路。

　　应用程序接口：应用程序和信息系统之间通过MQSeries API实现的接口。

Install MQ

• 安装过程中选择自定义安装模式，并确保安装JMS所需的Java　jar包支持如下图:

　　(缺省安装未包含)

确认MQ服务已启动。

　　可通过MicroSoft windows控制面板中管理工具下的服务控制台确认。如下图：

从程序菜单启动MQ 资源管理器

　　如果程序提示试用版过期,可以通过修改系统时间搞定.我就是修改到了2004年。

通过MQ资源管理器创建一个通道

　　建立名为BRIDGE.CHANNEL的通道，其他参数缺省设置。

通过MQ资源管理器创建两个本地队列

　　建立两个本地队名为MQReceiveQueue, MQSendQueue，其他参数缺省设置。

更新MQ安装目录下与ＪＭＳ配置相关的文件

　　JMSAdmin.config文件位于%MQ_INSTALLL_HOME_PATH%\Java\bin，主要定义JNDI服务的提供商，即JMS Server Factory和URL。%MQ_INSTALLL_HOME_PATH%\Java\bin目录下新建目录bridgeconfig，将JMSAdmin.config文件拷贝到bridgeconfig。

　　使用Sun的文件JNDI服务Factory,故定义

INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
PROVIDER_URL=file:/D:/installed/MQ/Queues
SECURITY_AUTHENTICATION=none
（例子中，MQ安装目录%MQ_INSTALLL_HOME_PATH%为：D:/installed/MQ/）
JMSAdmin.bat文件也位于%MQ_INSTALLL_HOME_PATH%\Java\bin，此文件用于启动ＭＱ的JMS命令行管理界面，要设置启动JMS命令行管理界面所需环境变量。在JMSAdmin.bat中添加如下环境变量：
set MQ_JAVA_INSTALL_PATH=D:\installed\MQ\Java
set MQ_JAVA_LIB=%MQ_JAVA_INSTALL_PATH%lib
set MQ_CLASSPATH=%MQ_JAVA_LIB%com.ibm.mq.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%com.ibm.mqbind.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%com.ibm.mqjms.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%fscontext.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%jms.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%jta.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%ldap.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%providerutil.jar

进入MQ的JMS命令行管理界面绑定MQ的JMS Factory以及JMS本地队列

• 开启MicroSoft Windows的Dos窗口(cmd.exe)
• 进入MQ安装目录下的java目录下的bin目录
• 运行JMSAdmin.bat并通过-cfg参数指定JMSAdmin.config文件位置

  　　本次例子中输入：D:\ installed\MQ\Java\bin>jmsadmin -cfg  .\bridgeconfig\jmsadmin.config

  

• 如上图所示界面，生成一个MQXAQueueConnectionFactory对象，Messaging Bridge将使用这个工厂对象建立MQ的XA连接，使用命令DEFINE XAQCF，起名：bridge.mqQCFXA。
• 生成JMSQueue对象来绑定MQ队列MQReceiveQueue。
• 生成JMSQueue对象来绑定MQ队列MQSendQueue。
• 使用dis ctx命令，查看目前已有的对象和绑定，可以看到XA连接工厂和队列都已绑定。

测试

MQ发送，WLS接收

1. MQ发送队列放入测试消息

   

2. 在WLS控制台监测消息到达

   

WLS发送，MQ接收

1. WLS发送队列放入测试消息

   　　执行下面的代码，给WLS发送队列放入测试消息

   　　 

   package com.bea;
   import javax.naming.InitialContext;
   import javax.naming.Context;
   import javax.naming.NamingException;
   import javax.jms.*;
   import java.util.Hashtable;
   /**
    * Created by IntelliJ IDEA.
    * User: pmeng
    * Date: 2006-6-3
    * Time: 14:54:08
    */
   public class SendMessageTest {
       public static void main(String[] args) {       
           try {
               Hashtable env = new Hashtable();
               env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
               env.put(Context.PROVIDER_URL, "t3://localhost:7001");
               InitialContext ctx = new InitialContext(env);              
               QueueConnectionFactory factory = (QueueConnectionFactory) ctx.lookup("bridge.wlsCFXA");
               QueueConnection connection = factory.createQueueConnection();
               QueueSession session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
               Queue queue = (Queue) ctx.lookup("bridge.wlsSendQueue");
               connection.start();
               QueueSender queueSender = session.createSender(queue);
               TextMessage msg = session.createTextMessage();
               msg.setText("Menghe.");
               queueSender.send(msg);
           }
           catch (NamingException e) {
               System.out.println("NamingException:" + e.getMessage());
               e.printStackTrace();
           }
           catch (JMSException e) {
               System.out.println("JMSException:" + e.getMessage());
               e.printStackTrace();
           }
       }
   }
   

2. MQ资源管理器查看接收到的消息

   

参考资料

1. BEA WebLogic Server 8.1 JMS与 IBM MQSeries 集成方案，周海根，
   http://dev2dev.bea.com.cn/techdoc/20040411784.html
2. BEA WebLogic 8.1 JMS 与IBM MQ v5.3 通过JMS Message Bridge通信配置，陈仁祥
   http://e-docs.bea.com/wls/docs91/messaging.html

转自http://www.lrsolution.com/docs/MQvsWLJMS.html


比较IBM MQSeries和BEA WebLogic JMS Server

刘睿
2005年7月

在面向消息的中间件(MOM)这个领域，IBM MQSeries (又称WebSphere MQ)一直是当仁不让的超级大哥，其它还有一些小兄弟，比如SwiftMQ、SonicMQ之类。但近年来随着J2EE中的JMS规范的建立，完备地支持JMS的服务器如雨后春笋般地出现，比如BEA WebLogic Server的JMS Server就是其中一个佼佼者。

仅仅就JMS规范来说，MQSeries与WebLogic JMS没有什么不同之处。但JMS规范仅仅定义了消息服务器的一个开发接口，而且还忽略了许多细节，所以不同之处就在JMS规范之外的这些内容，很多也是非常重要的。总的来说，MQSeries的功能和性能方面明显占优，而WebLogic JMS的某些JMS配置更加简单易行。

在本文中，我尽量试图从客观的角度分析两种产品的差异，如有不妥之处，请读者不吝赐教。

1. 产品体系架构不同造成的差异

WebLogic JMS是一个纯Java实现的支持C-S架构的实现JMS规范的服务器产品；而MQSeries是使用本地语言(比如在UNIX和Windows上的C语言)编写的既支持C-S架构，又支持对等访问的实现完备MOM(包括JMS规范)的产品。于是就产生出以下的不同点：

1.1 MQSeries支持真正的异步数据传输；而WebLogic JMS不支持。

异步发送数据到远端的消息服务器，是MQSeries等完备的MOM的特色。JMS规范规定了一个C-S架构，定义了JMS客户机与JMS服务器的开发接口，并没有定义JMS服务器与JMS服务器的规范，而客户机方面没有任何队列，所以只能说是规范了消息的存取，而没有规范消息数据的传输。因为JMS客户机并不拥有存放数据的队列，所以所有发送的操作都要由应用程序来控制，JMS服务器本身并不代理传输，也不保证数据在远程队列间传输的可靠性。WebLogic JMS就是这样的体系。

这种体系结构有时候是不能直接满足应用的要求的。首先，为了充分利用资源和提高效率，许多应用需要采用异步消息的机制。其次，许多需要快速返回的应用也必须使用异步传输。比如电话自动语音应答(IVR)的程序，某个操作需要把数据传输到远程的服务器上，但是必须立即返回，接受客户的下一个按键。

MQSeries通过通道与传输队列和远程队列来完成这一任务。能充分利用网络的带宽，甚至支持断网续传，保证数据传输的可靠性。当然，虽然应用程序不必作任何工作，但配置方面确实还要多学一些概念。

1.2 MQSeries支持多种语言的开发；而WebLogic JMS基本上只支持JAVA

MQSeries支持的语言包括C, C++, COBOL, JAVA, PL/1, REXX, RPG, Visual Basic (使用COM/ActiveX)等。老板本的MQSeries支持JAVA是通过一个叫MA88的SupportPac来实现，虽然经过广泛的使用和验证，但给人的感觉是不太方便。好在从5.3版起(目前最新的是6.0版)，JAVA支持已经内置在MQSeries中。

WebLogic JMS一般只支持JAVA开发。但BEA也在dev2dev.bea.com网站上提供了一套免费的C的支持，称作“JMS C API”。参见http://dev2dev.bea.com/utilitiestools/environment.html?highlight=utilitiestools。但这个工具与老的MA88也是不能相提并论的，因为BEA并不真正支持它，因此也基本没有什么用户。参见BEA网站上关于“JMS C API”的警告：

1.3 纯JAVA实现的利与弊

MQSeries是用本地语言实现的，因此带来的好处是高性能和高并发的支持能力。MQSeries相对WebLogic JMS等产品的性能优势是非常明显的，所以MQSeries非常适于企业级的大数据量和高并发的数据传输业务。谁也无法想象一个企业级的数据应用会采用一个纯Java实现的数据库，因为其性能无法满足要求，对较大的数据传输应用也是一样的，纯Java实现的JMS服务器例如WebLogic JMS无法满足其性能的要求。

纯JAVA实现的JMS服务器也有其好处，就是与其它的J2EE服务完美地集成在一起。所以WebLogic的JMS配置显得更简洁。WebSphere+MQSeries也配合得很好，但总是能感觉到是这两个产品。WebLogic JMS的对象体系完全符合JMS的概念体系。而MQSeries要通过WebSphere Application Server或者一个叫JMSAdmin的工具，借助于目录服务来完成MQSeries概念体系到JMS概念体系的映射。应该是看到了这件事造成的麻烦，所以IBM在WebSphere v6也提供了一套纯JAVA实现的、与MQSeries可以互操作的JMS服务器。另外一点是WebLogic不需要WebSphere以及MQSeries那样的冗长的CLASSPATH等环境变量的设置，这点对开发人员有吸引力。

1.4 MQSeries的通信功能更加强大，WebLogic JMS也有自己的一些特色

JMS对通信功能的要求很少，所以对二者对通信支持能力还是有很大的差别的。总的来说，历史更悠久的MQSeries占优，但WebLogic JMS也有自己的特色。

• MQSeries支持支持真正的远程异步数据传输，甚至支持消息的路由，可以“多级跳”；WebLogic JMS不支持。
• MQSeries支持消息的分组和分段传输，对于大消息传输和不稳定的网络非常有意义。WebLogic JMS没有这方面的功能。
• 二者都支持SSL、持久性、优先级、超时等功能。除了完备的SSL实现之外，MQSeries的安全体系 遭到了一些批评，使用通道的安全出口程序显得很麻烦，而使用用户名称但无须口令保护的远程数据通信，如何能令人满意？但在这一点上WebLogic JMS也很难说就好一些，因为WebLogic JMS仅仅支持C-S的操作，系统本身并不支持远程的数据传输(需要应用实现)。
• WebLogic JMS支持IP多播会话，能显著地提高 局域网内广播通信的性能，但这种方式不保证数据接收的可靠性，只适于某些特定的应用。MQSeries本身不提供此功能，但在Event Broker和Message Broker等MQSeries的升级产品中提供IP多播的支持。

1.5 MQSeries的管理功能更加强大

JMS对管理功能的要求很少，在这方面MQSeries也有比较明显的优势。

• JMS对事务处理的支持包括的对XASession和XAConnection实现，这一点对MQSeries和WebLogic JMS是相同的。MQSeries本身还可以作为事务管理器，协调两阶段提交。
• MQSeries和WebLogic JMS都支持Message Driven Bean作为触发新的应用的一种方式。WebLogic JMS还支持一种称作Session Pool的类似的触发机制。但这类触发机制过于简化，也就是每个消息都触发一个新的线程的应用。MQSeries的触发机制更丰富，不但包括这种被称作Every的方式，还包括First和Depth等方式。另外MQSeries还可以触发各种执行程序或者MQSeries的通道。
• MQSeries拥有一套完备的日志系统，可以进行独立的系统备份和恢复，因此适于高规格的数据/消息传输的应用。WebLogic JMS没有这方面的支持。

2. 产品历史的不同造成的差异

MQSeries是个历史悠久的产品，而WebLogic JMS是个新兵，因此会有以下的差异：

2.1 MQSeries支持更多的系统平台

支持30多种系统平台。当然值得注意的是某些平台的MQSeries是由合作伙伴实现的。

WebLogic JMS是个新产品，支持的平台数与WebLogic Server一样，只有常用的几个。有人说所有支持JDK的平台都能跑WebLogic JMS的客户机，这是不正确的说法。因为JMS是J2EE规范的一种，J2SE的SDK并不包括JMS的支持，更不要说支持WebLogic的J2EE了。

2.2 MQSeries支持更多的 通信协议

MQSeries支持很多通信协议，但目前在实践中常用的是TCP/IP协议和SNA协议。

WebLogic JMS仅支持TCP/IP协议。

有些人对MQSeries的单向通道的概念提出了异议，认为增加了配置的复杂性，仅仅是SNA协议的需要，而不是TCP/IP协议的需要。我个人认为这点也不无一些道理。但是在有防火墙的TCP/IP网络上，不同的方向还是有差异的。

3. 群集实现的差异

MQSeries与WebLogic JMS在支持群集时，差异比较大，应该说各有各的特点。

• MQSeries的群集建立在配置库和群集通道基础之上，可以定义“共享队列”；WebLogic JMS的群集建立在WebLogic群集基础之上，可以定义“分布式队列”。
• MQSeries在写共享队列时，如果发现本地有，就只写本地的队列(这称作本地优先)；如果本地没有，就会轮流写到所有定义了此共享队列的队列管理器。MQSeries在读共享队列时，只能从本地取。WebLogic JMS在读写分布式队列时，不受本地影响，总是进行轮流或权重选择。听起来似乎WebLogic JMS的群集更灵活，其实也不尽然。当取得了JMS的对象QueueSender或QueueReceiver后，WebLogic实际上已经绑定了一个JMS服务器的实例。如果每次写或读一个消息，都重新生成QueueSender或QueueReceiver，虽然比较好地支持了负载均衡，但势必造成很大的性能损失。而MQSeries在轮流写共享队列时，没有这方面的问题。
• WebLogic JMS的分布式队列有一个叫做Forward Delay的有意思的属性，定义了一个时间的长度。系统一旦发现超过这个时间长度，还没有人读这个队列，就把它的消息转送给群集中有消费者的队列。有了这个属性，应用程序就可以只从一个JMS服务器的实例读消息了。