當前，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）存文本的時候產生的問題?？梢允褂胻ext 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規范之外的這些內容，很多也是非常重要的?？偟膩碚f，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對通信功能的要求很少，所以對二者對通信支持能力還是有很大的差別的?？偟膩碚f，歷史更悠久的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服務器的實例讀消息了。

對于大型的WEB APP多數需要在集群環境下運行,那么在開發WEB APP時就需要注意幾點,以便可以支持FAILOVER.

1. SESSION中的數據做了修改后一定要手動的SET到SESSION 中
??? 如果當前的MANAGED SERVER DOWN掉,ADMIN SERVER會自動failover到其他的MANAGED SERVER,?并復制SESSION數據.當你對SESSION中的數據做了修改后,必須SET回SESSION,否則修改后的數據不會被復制到另一個SERVER,數據丟失.

2. SESSION中的數據必須是可序列化的.
??? 很容易理解, 只有可以被序列化的數據才能被復制

3. 靜態數據必須是只讀的
????同上, 當FAILOVER時,靜態數據是不會被復制的,如果靜態數據被修改了,白改!
????例如經常會用靜態屬性去做記數器,這樣就需要考慮用其他方法了

其實就算WEB APP目前沒有準備使用集群,也應該注意這幾點,以便以后可以方便的移植到集群.

歡迎大家指正和補充!