在本文中，您將學習如何利用 Java 2 Platform, Enterprise Edition (J2EE) 設計和開發 面向服務的體系結構 （SOA）框架。通過采用 SOA 框架，企業可以最大程度地減少系統間的耦合，從而提高可重用性。本文從一個較高的層面概述了在 SOA 框架上進行的幾次迭代過程，這個框架將滿足一家虛構企業的需求。這里開發的示例框架可以很容易地進行修改以適合您的商業需求。
SOA 是一種分布式的軟件模型。SOA 的主要組件包括 服務、動態發現 和 消息 。
- 服務 是能夠通過網絡訪問的可調用例程。服務公開了一個接口契約，它定義了服務的行為以及接受和返回的消息。術語 服務 常與術語 提供者 互換使用，后者專門用于表示提供服務的實體。
- 接口通常在公共注冊中心或者目錄中發布，并在那里按照所提供的不同服務進行分類，就像電話簿黃頁中列出的企業和電話號碼一樣�？蛻簦ǚ⻊障M者）能夠根據不同的分類特征通過動態查詢服務來查找特定的服務。這個過程被稱為服務的 動態發現 。
- 服務消費者或者客戶通過 消息 來消費服務。因為接口契約是獨立于平臺和語言的，消息通常用符合 XML 模式的 XML 文檔來構造。
下面的 圖 1 說明了 SOA 中的不同角色。
Web 服務建立在開放標準和獨立于平臺的協議的基礎之上。Web 服務通過 HTTP 使用 SOAP（一種基于 XML 的協議），以便在服務提供者和消費者之間進行通信。服務通過 WSDL（Web Service Definition Language）定義的接口來公開，WSDL 的語義用 XML 定義。UDDI 是一種語言無關的協議，用于和注冊中心進行交互以及查找服務。所有這些特性都使得 Web 服務成為開發 SOA 應用程序的優秀選擇。
1.4 版的 J2EE 平臺通過新的 JAX-RPC 1.1 API 提供了完整的 Web 服務支持，這種 API 支持基于 servlet 和企業 bean 的服務端點。JAX-RPC 1.1 基于 WSDL 和 SOAP 協議提供了與 Web 服務的互操作性。J2EE 1.4 平臺也支持 Web Services for J2EE 規范(JSR 921)，后者定義了 Web 服務的部署需求并利用了 JAX-RPC 編程模型。除了幾種 Web 服務 API 之外，J2EE 1.4 平臺還聲稱支持 WS-I Basic Profile 1.0。WS-I Basic Profile 標準讓 Web 服務克服了不同編程語言、操作系統和供應商平臺之間的障礙，從而使多種應用程序之間能夠交互.這意味著除了平臺獨立性和完整的 Web 服務支持之外，J2EE 1.4 還提供了跨平臺的 Web 服務互操作性。
在 J2EE 1.4 下，Web 服務客戶可以通過兩種方式訪問 J2EE 應用程序�？蛻艨梢栽L問用 JAX-RPC API 創建的 Web 服務；在幕后 JAX-RPC 使用 servlet 來實現 Web 服務。Web 服務客戶也可以通過 bean 的服務端點接口訪問無狀態會話 bean。Web 服務客戶不能訪問其他類型的企業 beans。第二種選擇——公開無狀態 EJB 組件作為 Web 服務——有很多優勢：
- 利用現有的業務邏輯和流程： 在許多企業中，現有的業務邏輯可能已經使用 EJB 組件編寫，通過 Web 服務公開它可能是實現從外界訪問這些服務的最佳選擇。EJB 端點是一種很好的選擇，因為它使業務邏輯和端點位于同一層上。
- 并發支持： 作為無狀態會話 bean 實現的 EJB 服務端點不必擔心多線程訪問，因為 EJB 容器必須串行化對無狀態會話 bean 任何特定實例的請求。
- 對服務的安全訪問： 企業 beans 允許在部署描述符中聲明不同方法級別的安全特性。方法級別角色被映射到實際的主體域（principal domain）。使用 EJB 組件作為 Web 服務端點，把這種方法級別的安全性也帶給了 Web 服務客戶。
- 事務問題： EJB 服務端點在部署描述符規定的事務上下文中運行。容器處理事務，因此 bean 開發人員不需要編寫事務處理代碼。
- 可伸縮性： 幾乎所有 EJB 容器都提供了對無狀態會話 bean 群集的支持。因此當負載增加時，可以向群集中增加機器，Web 服務請求可以定向到這些不同的服務器。通過把 Web 服務模型化為 EJB 端點，可以使服務具有可伸縮性，并增強了可靠性。
- 池與資源管理： EJB 容器提供了無狀態會話 bean 池。這改進了資源利用和內存管理。通過把 Web 服務模型化為 EJB 端點，這種特性很容易擴展，使 Web 服務能夠有效地響應多個客戶請求。
記住所有這些優點，下一節將展示如何在體系結構中將無狀態 EJB 組件公開為 Web 服務。
比方說有一家公司，它的各種系統（比如支付、財務和發票系統）需要彼此交互。此外，其中一些應用程序還需要對外界公開，以便不同的業務合作伙伴與它們進行交互。您還需要為各種應用程序（如輸入發票的各種數據輸入操作或者查看支付的狀態）設計基于 Web 的解決方案。最佳選擇就是設計一種松散耦合的基于服務的系統。這些服務應該得到開放標準的支持，這樣任何業務合作伙伴都可以調用它們。
這些方面的考慮將使您轉向 Web 服務 /SOA 框架，通過無狀態 EJB 組件把各種服務和業務流程公開為 Web 服務。下面的 圖 2 說明了企業內部應用的 SOA 框架。
下面列出了 SOA 框架中進行交互的各種組件。這是一種典型的 MVC 2 框架。
- 客戶（Client）： 用戶通過 Web 瀏覽器與不同的應用程序交互，瀏覽器作為應用程序的客戶。比如，出納部門的用戶可能要輸入帳單細節并把信息提交給應用程序�？梢允褂� JSP 頁面和 XHTML 來呈現客戶頁面。
- 應用程序控制器（Application controller）： 應用程序控制器是您的主控制器 servlet。它負責初始化、委派請求和響應請求處理程序。
- 請求處理程序（Request processor）： 這是一個 Java 類，通過調用相應的請求執行程序完成要求的處理，對請求進行預處理。這種調用采用命令模式。
- 請求執行程序（Request handlers）： 請求執行程序完成具體請求的活動，比如與服務交互，向不同的企業信息系統（enterprise information systems，EIS）增加或檢索信息。請求執行程序依靠業務定位程序發現相應的服務，然后通過這些服務訪問需要的 EIS 信息。
- 業務定位程序（Business locators）： 這些程序負責隱藏查找服務的復雜性，并提供緩存邏輯。業務定位程序可以采用多種形式，比如 Web 服務定位程序、EJB 組件定位程序或者 JMS 定位程序。
- 會話 Facades（Session Facades）： 通過聚合來自多個系統或服務的方法，簡化復雜對象的視圖。會話 facades 是 EJB Web 服務方法的包裝器。
- EJB Web 服務（EJB Web services）： 根據 EJB 1.4 規范，Web 服務端點可以模型化為無狀態的會話 bean。如前所述，這種技術有許多優勢。
- 數據訪問接口（Data access interfaces）： 使用不同的技術（比如 EJB-CMP、JDO、DAO） 和不同的持久性技術訪問 EIS，所使用的訪問技術取決于接口需求以及獲取、插入或更新的數據量。這一層負責與 EIS 進行交互，并以相應的 EJB Web 服務方法所期望的格式把數據返回給這些方法。
- MQSeries/JCA/CCF： 現有的基于主機的服務可以公開為 Web 服務，從而向外界展示它們。Web 服務客戶使用基于 HTTP 的 SOAP 協議與 EJB Web 服務交互。EJB 方法通過 JMS 協議向 MQSeries 隊列發送請求。（使用 MQSeries 是與基于主機的應用程序交互的一種方式。）主機端的 MQSeries 服務器觸發相應的基于 COBOL 的程序，后者為與后臺系統（比如 IMS DC）進行交互提供必要的邏輯。然后這些程序把響應返回到隊列中，應用程序邏輯檢索這些響應并返回給 EJB 方法。SOAP 消息可以通過不同協議進行傳輸，比如 HTTP、HTTPS 和 JMS，但為了統一起見，本例子只使用 HTTP 和 HTTPS。
這些組件提供了企業內部應用程序面向服務體系結構的基礎。接下來討論把服務向外界公開。
如果準備向外部用戶公開服務，您需要某種安全約束來保證只有授權的用戶才能訪問服務。一種方法是提供另外的 Web 服務層，過濾掉禁用的 Web 服務請求，并提供登錄和安全約束。這種過濾方式還應提供一種工具，向每一客戶只公開授權給該用戶的服務子集。
圖 3 說明了企業外部應用的面向服務體系結構。它向外界公開了細粒度的服務。
以下是這種體系結構的基本功能單元：
- 外部客戶（External clients）： 可以包括基于 Web 的客戶、移動客戶或者使用 .NET 環境、Perl 或其他編程語言編寫的客戶。所有這些客戶都為不同的服務發送請求。只要遵循 WS-I Profiles 就不會出現互操作性的問題。
- 企業防火墻（Corporate firewall）： 根據其安全策略，這家公司在 intranet 和 Internet 之間架起了防火墻，對收到的分組信息進行限制。
- Web 服務網關（Web Services Gateway）： 本例中，我選擇使用 WebSphere Application Server 5.0 中的 Web Services Gateway 產品作為公開外部服務的網關。 Web Services Gateway 是一種中間件產品，在調用 Web 服務時提供了 Internet 和 intranet 之間的中間框架。使用 Web Services Gateway，開發人員和 IT 經理可以安全地對外公開 Web 服務，防火墻之外的客戶也能調用這些服務。它包括一個服務管理模型（部署、取消部署，等等）和過濾器（對流經網關的請求和響應起作用的自定義代碼）。它只處理收到的 SOAP/HTTP 請求，通過網關的請求可能發送給 Java 類、EJB 組件或者 SOAP 服務器（該服務器甚至還可能是另一個網關）。它可以為單個的 Web 服務方法提供保護（基本授權），也可以保護整個網關。使用 Web Services Gateway，來自客戶的請求可以被轉換成服務所要求的任何消息協議。例如，客戶的請求可能是 HTTP 上的 SOAP，但在內部可以使用 JMS 協議上的 SOAP，Web Service Gateway 能夠提供從一個協議到另一個協議的轉換。
- EJB 服務（EJB services）： EJB 服務沒有任何變化。過程的其他部分和 圖 2 所示體系結構提供的基于 intranet 的服務類似。
迄今所見到的過程都是向客戶公開細粒度的 Web 服務。只要每個業務服務作為單個業務過程執行，這種設置就能很好地工作。但是假設客戶要進行在線資金轉移，這種情況下提供單一的、粗粒度的接口顯然更加合理，讓用戶提供所有必要的信息，包括傳輸的金額、發出和接收的銀行信息，等等。此外，這類情形中驗證必須在執行任何業務邏輯之前完成。在設計 Web 服務方法時必須考慮到這些問題，還要記住除了網絡調用之外還有解析與規劃 XML 請求和響應的開銷。
考慮到這些因素，可以把 Session Facades 模型化為 EJB Web 服務端點。Session Facades 可以在把請求委派給相應的 Web 服務方法之前首先驗證請求。這樣，您就可以向 Web 服務客戶提供粗粒度的服務。
下面的 圖 4 說明了企業外部應用的面向服務體系結構的下一次迭代過程。這個版本的體系結構向外界公開粗粒度的服務。
這里，主要的實現仍然和 圖 3 中所示的相同。唯一的區別在于已經公開了 Session Facades 作為 Web 服務端點。EJB Web 服務可以模型化為本地接口而不是遠程接口。使用會話 facades 和方法級安全性，可以限制要執行的服務。使用 Web Service Gateway 也能為 Web 服務客戶施加安全措施。根據需要，可以實現粗粒度服務和細粒度服務的某種結合，通過調整 Web 服務網關中間件來向外部客戶公開兩種服務
采用 WSDL 文件形式的 Web 服務接口可以發布到商業注冊中心，從而使客戶能夠動態查找這些接口。如果交易伙伴已經知道這些服務，也不一定要進入商業注冊中心，但是全球服務需要公共注冊中心，以便客戶能夠查找可用的服務。例如，各個航空公司可以把它們的機票價格服務放在注冊中心，普通客戶可以發現所有這類服務，并查找航空公司所提供的最低票價。
我希望本文能夠有助于您開始使用 Web 服務和新的 J2EE 1.4 規范所提供的特性構建面向服務的體系結構。您可以修改和調整本文所述的 SOA Web 服務框架以適應您的業務需要。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
