程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> 談JMS和JSF的使用

談JMS和JSF的使用

編輯：關於JAVA

引言

IBM® WebSphere® Application Server 是基於 Java 的 Web 應用服務器，它創建於開放標准之上，使您能部署和管理從簡單 Web 站點到強大的電子商務解決方案的各種應用程序。IBM WebSphere Studio Application Developer（下文中簡稱為 WebSphere Studio）是一個集成開發環境，可以用來構建、測試、部署 J2EE 和 Web Services 應用程序。更進一步的信息，請參閱 developerWorks WebSphere Application Server 專區和 developerWorks WebSphere Studio 專區。

JavaServer Faces 曾經是 J2EE Web 開發中最被看好的技術之一。在 WebSphere Studio 中，JavaServer Faces 已經可以使用了。JavaServer Faces (JSF) 提供了可視化開發 J2EE Web 應用程序新的途徑。

問：這是一個很基本的問題。您能比較一下 JSF 和 Struts 之間各自的優缺點嗎。如何了解現在和將來的技術趨勢，JSF 如何以及是否將會發展成為相對於 Struts 更出色的技術。另外，WSAD 如果可以使兩者不同的話，將在兩者的比較中將會充當什麼樣的角色。

答：這是近期很熱門的一個問題。一般來說，JSF 仍然是相當新的技術，需要時間來完全地成熟。然而，我看到 JSF 已經可以完成 Struts 可以做的任何事，而且做的更多。 Struts 並不是來自於強制性的需求。它是開發人員厭煩了一次次的編寫相同的邏輯而創造的。JSF 的出現，既是必然的需要也是競爭的結果。

Struts 有以下優點：

Struts 是一個成熟的、被證實了的框架。它已經使用了幾年，且被成功部署到許多項目中。WebSphere Application Server 管理控制台就是一個 Struts 應用程序。

Struts 使用 Front Controller 和 Command 模式，可以處理復雜的控制器邏輯。

除了核心的控制器功能以外，它還有很多其他的優點，比如使用 Tiles 布局、說明性（declarative）異常處理以及國際化。

以下是其缺點：

Struts 是非常以 JSP 為中心的，必須使用其他框架來適應其他視圖技術。

盡管 Struts 有豐富的標記庫，但是它只能幫助進行控制器方面的開發，當您處理關於頁面的組件時，它沒有任何意義。因此，從視圖的角度來看，它沒有提供好的工具。

Struts 需要關於 Java™ 的知識。其目的是幫助 Java 開發人員，而不是隱藏 Java。它在對 Web 開發人員隱藏 Java 語言的細節這一方面做的並不好。

ActionForms 被程式化的與 Struts 框架鏈接。因此，為了降低模型的耦合度，您需要編寫傳送代碼或者在輸入時使用工具將數據從 Action Forms 移動到 Model。

JSF 從包括 Struts 的少數框架發展而來。Struts 的創建者，Craig McClanahan，即是 JSF 規范的領導人之一。因此，能看到 Struts 和 JSF 之間的一些相似之處，這並不是偶然的。JSF 的主要目的之一就是使得 J2EE Web 應用程序在 RAD 工具下易於開發。同樣地，它也引入了豐富的組件模型。JSF 有如下優點：

JSF 是一個來自 Sun® 的規范，將會被包括在 J2EE 規范的未來版本之中。各主要供應商都保證對 JSF 提供強力支持。

JSF 使用 Page Controller Pattern，因此會對頁面密集型應用程序有幫助。相應組件會對來自頁面上組件的事件作出響應。

JSF 有一個明確定義的請求生命周期，保證了在不同級別上的可插入性（plugability）。

可插入性的一個有力的例子是構建您自己的 render 工具包。將框架中的呈現（rendering）部分和控制器部分分離的能力實現了良好的可擴展性。組件供應商可以編寫他們自己的工具包以處理不同的標記語言，如 XML 或 WML。另外，render 工具包也不依賴於 JSP。

因為 JSF 有一個豐富的組件模型，所以它支持 RAD 類型的開發。現在我可以使用拖放技術來構建我的 Web 頁面。此外，JSF 提供在不打破層次布局的條件下，將可視組件同後台模型組件連接起來的途徑。

JSF 有以下缺點：

JSF 仍是相當新的並處於發展過程中。要看到成功的部署和廣泛的應用還需要一段時間。另外，組件供應商可能並不能做您想讓他們完成的所有事情。

手工方式的 JSF 並不比 Struts 簡單。它的目標更傾向於 RAD。那些喜歡手工開發的人（例如，那些不喜歡 IDE 的 vi 類型的人）可能會發現 Struts 更容易開發。

Struts 導航可能會更加靈活一些，但同時也導致控制器邏輯更加復雜。

JSF 和 Struts 將會繼續共存一段時間。Struts 社區已經了解了 JSF 並在作出一些改變以對 JSF 提供強大的支持。參見 What about JSTL and JavaServer faces?

在工具的角度，如果您留意了 WebSphere Studio 對 JSF 和 Struts 的工具支持，將會發現 Struts 工具集中於控制器方面。Web Diagram 編輯器幫助構建您的 Struts 配置，而向導/編輯器構建 Struts 構件。JSF 工具適合於構建頁面，而實質上向您隱藏了 JSF 框架。可以預計 WebSphere Studio 將暫時同時支持兩種框架。當 JSF 趨於成熟以後，預計將可以在 JSF 中看到一些控制器方面的可用工具。

問：將大型應用程序從 Struts 向 JSF 進行遷移的最佳途徑是什麼？是否有一些有幫助的支持工具？

答：這是一個決定於您的 Struts 應用程序的復雜任務。因為兩種框架有著不同的目標，這將存在一些挑戰。首先遷移您的響應頁面。保留 Struts 控制器，同時在前端使用 JSF 頁面。然後您可以配置 Struts 前端以檢查 Faces servlet。可以考慮參考 Apache 的 Struts-Faces 框架。參見 JSF in Action的框架一章。

問：是否有從 Struts 到 JSF 的遷移途徑？比起 Struts，JSF 的成熟性如何？

答：對於第一個問題，參見前一個問題的回答。對於第二個問題，參見問題 1 的回答。

問：我能否用 Message-Driven bean 來代替 Stateless session bean？

答：程式化地說，任何事都是可能的。但是這種類型的改變應該是需求驅動的。Message Driven Bean (MDB) 是一個用來接收 JMS 消息的異步監聽器。Stateless Session Bean 既通過本地接口進行監聽，也使用遠程接口通過 RMI/IIOP 進行監聽。應用程序邏輯應該根據向多個客戶端提供服務的方式進行分層。您可能考慮通過 MDB 來取代 Stateless Session Bean，以便增加其可被多個客戶端訪問的能力。圖 1 展示了相關概念。

圖 1. 概念

有關這個話題， Enterprise Java Programming with IBM WebSphere, Second Edition 是一個很好的資料。

問：我在使用 WSAD 5.1.1。與 Sun JSF 1.1 發布對應，WSAD 中支持 JSF1.1 的 RAD 組件何時才能用於產品應用？（由 Jay B. 提出)

答：IBM 近期還沒有轉向 JSF 1.1 的計劃，因為原來的實現（WebSphere Studio 5.1.2 中所附帶的）包括了對 JSF 1.1 中缺陷的更正。采用 JSF 1.1 對於 IBM 已經發布的代碼來說是多余的。應當提醒的是 IBM 是 JSF 工程主要的代碼提供者，並且 IBM 在 WebSphere Studio 5.1.2 中附帶的更正是算作 JSF 1.1 一部分的。當 JSF 經過一段時間的繼續發展以後，IBM 將會采用新的版本。

問：合適的 WSAD 和 Portal Toolkit 開發環境是什麼樣子的？我們的團隊必須在 Portal Server 4.2.1 上部署應用程序。我們也正在使用 Rational XDE。計劃在 2005 年 2 月將整個產品轉向 WAS 5.1。我們將使用 Struts 並將考慮使用 JSF。

我們是否能使用 WSAD 5.1.2 加上 Portal Toolkit 5.0.2.2？我希望能在開始向 Portal Server 4.2.1 部署時，使開發人員的生產率最大化。請問您推薦什麼樣的 WSAD 和 Portal Toolkit 開發環境呢？

答：要向 WebSphere Portal 4.2.1 部署，您可以使用 WebSphere Studio 5.1.2，並使用 WebSphere Portal 4 測試環境配置。WebSphere Studio 向後兼容 4 版本的 WebSphere Portal。然而，與對應於 WebSphere Portal 5 的版本 5 的 Unit Test Environment 不同，您需要單獨安裝 WebSphere Portal 4 UTE。像 JSF 等一些特性在版本 4 的 WebSphere Portal 中並不可用。此外，您也不能使用 J2EE 1.3 API 或者 JSR 168 Portlet 規范。一旦您移向 WebSphere Portal 5.0.2，就可以構建基於 JSF 的 portlet 了。

一旦您移向 5.1 版本的 WebSphere Application Server，就可以使用 JSF 特性了。然而，在您的環境下，使用 IBM Portlet API 的 Struts 應該是最佳的解決方案，因為它同時被版本 4 和 5 支持。然而，版本 4 的 Struts 支持是基於 1.0 的，而版本 5 是 Struts 1.1。您可能需要對 Struts 代碼進行少量的遷移以使用 Struts 1.1。

問：我正在從 WAS 4 向 WAS 5 遷移。雖然沒有任何編譯錯誤，但是當我測試應用程序時，在控制台上打印出如下錯誤：

[6/23/04 12:59:047 SGT] 493877ce WebGroup E SRVE0020E:

[Servelt Error]-[BF02SPINSLoginServlet]:

Failed to load servlet:

java.lang.NoClassDefFoundError:

com/ibm/ejs/models/base/config/applicationserver/WebModuleRef

at java.lang.Class.newInstance0(Native Method)

at java.lang.Class.newInstance(Class.java.262)

at java.lang.Class.Instantiate(Beans.java.233)

at java.lang.Class.Instantiate(Beans.java.77)

at com.ibm.ws.webcontainer.webapp.WebAppServletManager.loadServlet

(WebAppServletManager.java.188)

我試圖在 class path 中添加 ws-base-config，但還是出現問題。

答：遷移 J2EE 應用程序和服務器有時候是需要技巧的。沒有更多的信息，是很難診斷您的問題的。J2EE 1.2 應用程序應該可以不作任何修改在 WebSphere Application Server 上運行的。確保服務器包含的必要的配置資源。例如，對於 J2EE 1.2 應用程序，確保配置了一個 WebSphere Application Server 4 數據源。

如果您的的遷移包括了對 J2EE 應用程序從版本 1.2 到 1.3 的升級，可以參閱 Migrating to WebSphere V5.0, An End-to-End Migration Guide。

我建議在 WebSphere Application Server 5 上運行版本 1.2 的 J2EE 應用程序，以消除任何服務器配置的問題。然後您可以集中精力進行應用程序遷移。

問：在我編寫應用程序時，是否可以在 SWING 上使用 JSF（或者反過來）？是否有這樣的成功案例？

答：JSF 主要還是一個運行 J2EE Web 應用程序的 MVC 框架。JSF 組件模型的意圖是幫助開發人員使用 RAD 工具來開發 Web 應用程序，這些工具是胖客戶端應用程序開發人員所習慣使用的。盡管您可以創建自定義的 render 工具包來擴展 JSF，以處理來自服務器的胖客戶端控件，JSF 的目標或者基於 Web 的應用程序。您應該考慮回答這樣的問題：“我是要構建一個胖 GUI 的應用程序還是一個基於 Web 的系統？”

問：我現在正在設計一個應用程序，考慮使用 Struts 還是 JSF。我應該用什麼樣的標准在兩者之間選擇？

答：這是一個普遍的問題。問題 1 的答案可能是有幫助的。此外，考慮以下方面：

計劃中的部署日期是什麼時候？如果需要立即部署，那麼應該選擇 Struts。如果部署的時間比較遠，應該選擇 JSF。

您的開發人員技術水平如何？采用他們擅長的 RAD IDE 類型的方法，或者采用他們更喜歡的手工編程方式。您的視圖開發和控制器開發是否由不同的開發人員來完成？我一直認為應該考慮他們開發團隊適合的水平。

您的控制器邏輯復雜程度如何？您的頁面復雜程度如何？Struts 支持復雜的控制器邏輯（使用輸入的邏輯對導航有主要的影響）。JSF 更擅長於復雜的頁面邏輯（需要豐富的事件模型和模型同步的許多組件）。

您有什麼類型的模型（EJB、JavaBeans、JDBC 等等）？向您的 JSF 供應商核對被支持的數據組件。例如，WebSphere Studio 將其簡化為直接把 SDO 或 JavaBean 對象拖到頁面上合適的位置。

您是從零開始構建新的頁面/Web 應用程序，或者重用/遷移現有的應用程序？如果您有使用 Struts 實現的現有頁面或現有應用程序，那麼您必須考慮遷移的代價。

供應商支持的重要性如何？JSF 和 Struts 同時被 IBM 支持。

您的企業應用程序將有什麼類型的客戶機？（Web Based、HTML、XML、Mobile、GUI 等等）

問：我正在使用 WebSphere MQ 5.3 Publish/Subscribe 功能。我如何使用 WebSphere MQ 5.3 在服務器和客戶機計算機上配置代理拓撲（broker topology）？以及，我如何創建主題層次以便利用 WebSphere MQ 提供的這個特性？

答：當 WebSphere MQ 和 WebSphere Application Server 一起使用時，有許多拓撲選項設置。在 WebSphere MQ JMS 提供者那裡設置 Topic Connection Factories 和 Queue Connection Factories。

以下的書籍和文章包含您所需要的信息：

Enterprise Messaging using JMS and IBM WebSphere

IBM WebSphere: Deployment and Advanced Configuration

JMS Topologies and Configurations with WebSphere Application Server and WebSphere Studio Version 5

關於層次的話題，JMS 並沒有規定內容如何被組織成主題層次。這是一個和具體提供者相關的方面。在 MQ JMS 中，主題被安排成樹狀層次。您必須在 JNDI 命名空間中注冊 Topic ，您不能在 MQ 中執行創建任務。當某一特定主題的發布者或訂閱者被第一次創建時，代理例示主題。

問：我正在試圖解決我的 wsadmin jacl 腳本中的問題。當創建 Application Server 時，使用 wsadmin 腳本怎樣做以下工作：1）啟用 ORB Pass By Reference 選項。2）設置 Generic JVM Args。

在創建數據庫提供者時：1）即使在組件管理的持久別名被設置時，AuthData 別名還是沒有被設置（Admin Console 的下拉菜單）為容器管理的持久。

在部署時：1）Resources 的 Map Resource Reference 屬性 - JNDI 名稱沒有被正確設置。

我正在試圖尋找 wsadmin 腳本提供的參數名稱。例如，我使用 SOAP_CONNECTOR_ADDRESS 。它不起作用，但是 BOOTSTRAP_ADDRESS 起作用。如果在什麼地方能找到這些參數的名字，那將是非常有幫助的。（由 Nisha 提出）

答：在 WebSphere Application Server 5.1 Information Center 中有許多 wsadmin 的例子。我寫的書 IBM WebSphere: Deployment and Advanced Configuration，也有一個關於 wsadmin 的完整例子。

關於啟用 ORB Pass By Reference 選項，參見 Configuring an ORB service using wsadmin。關於設置一般的 JVM args，參見 Configuring the JVM using wsadmin。

關於創建數據庫提供者，有關信息可能不在 Information Center 中，所以，我附上我書中的一個程序片斷。關於創建容器管理的別名，您必須把 J2C 別名附在映射模塊上，而不是 DataSource 本身。

puts "\nCreating the datasource $dsName" set attrs2 [subst {{name "$dsName"} {description "$dsDescription"}}] set ds1 [$AdminConfig create DataSource $jdbcProviderID $attrs2] #Set the properties for the data source... set propSet1 [$AdminConfig create J2EEResourcePropertySet $ds1 {}] set attrs3 [subst {{name databaseName} {type java.lang.String} {value "$databaseName1"}}] puts "\nj2eeresourceproperty" $AdminConfig create J2EEResourceProperty $propSet1 $attrs3 set attrs4 [subst {{jndiName $jndiName} {statementCacheSize $statementCacheSize} {datasourceHelperClassname $datasourceHelperClassname} {authMechanismPreference "BASIC_PASSWORD"}}] $AdminConfig modify $ds1 $attrs4 #Create the connection pool object... $AdminConfig create ConnectionPool $ds1 {{connectionTimeout 1000} {maxConnections 30} {minConnections 1} {agedTimeout 1000} {reapTime 2000} {unusedTimeout 3000} } #Set the auth mapping properties set authDataAliasList [list authDataAlias $aliasName ] set mappingConfigAliasList [list mappingConfigAlias DefaultPrincipalMapping ] set mappingList [list $authDataAliasList $mappingConfigAliasList] $AdminConfig create MappingModule $ds1 $mappingList

關於 Resources 的 Map Resource Reference 屬性 - JNDI 名稱沒有被正確設置，參見 Wsadmin tool。

問：我的站點是一個中等規模的銀行（200,000 名顧客），在 Windows 2000 服務器上運行 WebSphere 4.05，使用 SQL2000 作為 WebSphere 存儲庫。首先我想知道的是“這是否是一個不正常的配置？”您是否也可以告訴我什麼樣的配置最能適合這樣規模的應用？我想問的另一個問題是關於腳本部署，當前我們使用手工部署，大多數網站是怎麼做的呢？（由 bendigobank.com.au 的 StephenP 提出）

答：關於您的第一個問題，有許多性能方面需要考慮的事情，比如 windows 服務器的數量、您的 SQL2000 服務器的冗余等等。不同的顧客使用不同的平台和環境。我曾經看到用戶在 AIX®、Solaris®、Linux、Windows® 和 z/OS 上成功地運行 WebSphere。這個問題很難給出這樣一個普遍的答案。可以考慮去看我的同事 Stacy Joines、Ruth Willenborg、Ken Hygh 所著的書 Performance Analysis for Java Websites。這本書裡有大量的關於衡量 Web 站點規模和性能測試應用程序的參考。

關於您的第二個問題，使用腳本可以使許多以前由開發人員、組裝人員、部署人員和管理員所做的單調乏味的手工工作自動化，這是一個高效的方法。如果您的應用程序封裝的比較簡單，手工部署對於小到中規模的應用程序還是可以成功的。然而，自動化可是幫你免除重復的勞動，為其他任務空出資源來。這是我所寫的書 IBM WebSphere: Deployment and Advanced Configuration 中主要的論題。在書中，我們分析了各種各樣的組裝和部署模型，並闡述了為什麼使用腳本的自動化是有益的。

問：我們開發了一個 J2EE 的銀行 Web 應用程序。在啟用以後，我們收到了儲戶強烈的抱怨：網站太慢了，不能浏覽，也無法連接。我們知道問題所在：在上午時間（9－11時）我們能收到 500 個並發連接。我們擔心 WebSphere 服務器不能同時連接超過 500 個用戶。是否有什麼優化應用程序性能的方法。請告訴我們大多數流行的網站所使用的性能優化技術。（由 Brijesh 提出）

答：關於性能的問題，沒有簡單的答案。這可能包括從應用程序到配置的各種問題。我曾經看到因為開發人員在他們的登錄框架裡沒有初始化 StringBuffers，導致應用程序在垃圾收集上運行極其緩慢。要解決您的性能問題，參閱 Performance Analysis for Java Websites。

一般情況下，性能測試應該是您的產品正式使用之前的部署過程中的一個主要部分。我需要關於您的問題的更多信息。當您說 500 個並發連接時，我理解為您是指 Web 容器。您是否聚集了您的應用程序？您是否有 Web 服務器？在下列資源中您可以看到各種各樣的布局：

IBM WebSphere: Deployment and Advanced Configuration

IBM WebSphere V5.1 Performance, Scalability, and High Availability WebSphere Handbook Series

問：是否有什麼方法能提供以前遺留的 I-Series 上的 RPGLE 程序到 VARPG 的接口。換句話說，程序的前端 GUI 屏幕已經設計並運行在 AS400 上了？

答：這種案例實際上我也沒有經歷過。不過，您想要看到的可能是以下這些產品：

WebSphere Host Access Transformation Service (HATS)

WebSphere Host On Demand

WebSphere Studio Enterprise Developer

iSeries Development Family

問：我在用不同於 Java 的其他語言（例如 Borland Delphi 和 C++）連接 MQ 5.3，以使用 WebSphere MQ - mqic32.dll 中的庫。但是，在發送前將消息轉換到 JMS-format 時，會出現問題。IBM 是否有相應的 dll 庫或別的構件來與 Java 以外的其他語言中的 JMS 操作一起工作？

答：您需要在 WebSphere MQ Queue 配置中將 Target Client Flag 設置成 MQ。

這在 JMS Topologies and Configurations with WebSphere Application Server and WebSphere Studio Version 5 中有講述。您可以在 WebSphere MQ Queue 的配置下設置目標客戶機。

圖 2. 新建 WebSphere MQ Queue