將 EJB 組件作為商務服務提供

2019-11-18 12:34:43

字體：大中小

來源：轉載

供稿：網友

　　設計模式對于面向服務的體系結構具有深遠的影響（人們對此尚熟悉不足），因此請明智地選擇您的設計模式
　　
　　當機構使用 Web 服務技術構建、部署和組織業務服務時，顯然必須進行仔細、全面設計 java 2 平臺企業版 (J2EE) 應用程序。在這方面，最有效的幫助是嚴格應用旨在實現面向服務的體系結構 (SOA) 的體系結構模式。當公開 EnterPRise JavaBean (EJB) 時，此類模式尤其有用。
　　
　　人們通常把模式僅僅看作是為非凡設計問題提供指導的參考工具；而事實上，應將模式看作是體系結構要求的組成部分。它們是影響業務服務（封裝了業務規則驗證、計算、數據訪問以及其他驅動 J2EE 應用程序的核心功能的邏輯）組織決策的起點。除其他適用于 J2EE 的模式和思考方式以外，一些學術界人士、供給商和用戶還從 SOA 的角度對聞名的Design Patterns一書（由 Addison-Wesley 出版社于 1994 年出版，作者是 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides —— 通常稱之為“四人幫”或“GoF”）中的許多模式進行了再計算和研究。
　　
　　本文將從體系結構的角度介紹最重要的模式及其應用，假設您熟悉以下 Web 服務基礎知識：簡單對象訪問協議 (SOAP)、HTTP、xml、J2EE、EJB、Java 消息服務 (JMS) 等。
　　
　　走進 Web 服務世界
　　從 J2EE 的角度而言，Web 服務基本上是 J2EE 編程模型的擴展（參見圖 1），具體體現在：
　　
　　Web 服務繼續了符合 J2EE 的應用服務器的容器功能。
　　遠程過程調用 (RPC) 樣式的 Web 服務通過非會話狀態 EJB 公開。
　　消息樣式的 Web 服務通過 JMS（JMS 監聽程序）和消息驅動的 bean 公開。
　　非會話狀態 EJB 或 JMS 被定義為 Web 服務定義語言 (WSDL) 的應用程序入口點，并被部署為 Web 服務。
　　Web 服務客戶機使用 WSDL 生成服務請求程序基于 SOAP 的代碼。
　　　將 EJB 組件作為商務服務提供（圖一）

　　圖 1：J2EE/Web 服務模型
　　首先，我們將簡要概述將 EJB 應用程序公開為業務服務的過程。盡管本文使用 Oracle application Server Containers for J2EE (OC4J) 環境，但對于任何其他符合 J2EE 的應用服務器也同樣適用。
　　
　　下面，我將介紹一個企業對客戶 (B2C) 商務領域中的示例。（參見圖 2 和圖 3；圖 2 描繪了角色交互，圖 3 描繪了系統分解。）在該示例中，客戶登錄到“電子商店”網站，點擊感愛好的商品，選擇某些要購買的商品，查看訂單信息，提供支付信息，最后注銷。為簡單起見，我省略了大量具體信息—例如，所有表示（Web 層）組件、安全支持等。
　　　將 EJB 組件作為商務服務提供（圖二）

　　圖 2：“電子商店”示例—協作圖表
　　　將 EJB 組件作為商務服務提供（圖三）

　　圖 3：“電子商店”示例—分解圖表
　　
　　如圖 3 所示，該解決方案包含四種 EJB 子系統（每個子系統包含多個 bean）：
　　
　　客戶驗證治理：負責登錄/注銷、站點注冊和客戶首選項
　　客戶體驗治理：負責客戶可以在“電子商店”站點執行的所有功能—查看目錄、購買商品、付款、查詢訂單狀態等
　　產品清單治理：負責提供商品可用性和更新存貨/脫銷數據庫以及觸發實現進程
　　財務治理：負責帳目治理和其他財務處理，如開發票。
　　
　　此處最簡單的服務可能是基于非會話狀態會話 bean SystemIdEJB 的 GetSystemIdService。該 bean 是稱作“驗證客戶”的一組對象類的一部分。假如客戶已經成功通過驗證，則該 bean 提供稍后用于獲取其他客戶信息（例如，與商品目錄的呈現方式相關的客戶首選項）的系統用戶 ID。假如客戶未成功通過驗證，則該 bean 發出例外。
　　
　　以下是發送至該服務的 SOAP 1.1 請求以及該服務發出的響應的示例：
　　
　　POST /SystemId HTTP/1.1
　　Host:eStore.com
　　Content-Type:text/xml; charset="utf-8"
　　Content-Lengthnnnn
　　SOAPAction:"http://eStore.com/getSystemId"
　　
　　<soapenv:Envelope
　　xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
　　<soapenv:Body>
　　<m:GetSystemIdRequest
　　xmlns:m="http://eStore.com/GetSystemId.wsdl/"
　　xmlns:xsd="http://eStore.com/GetSystemId.xsd/">
　　<xsd:logon>LogonID</xsd:logon>
　　</m:GetSystemIdRequest>
　　</soapenv:Body>
　　</soapenv:Envelope>
　　
　　..........
　　<soapenv:Envelope
　　xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
　　<soapenv:Body>
　　<m:GetSystemIdResponse
　　xmlns:m="http://eStore.com/GetSystemId.wsdl/"
　　xmlns:xsd="http://eStore.com/GetSystemId.xsd/">
　　<xsd:authenticatedId>SystemID</xsd:authenticatedId>
　　</m:GetSystemIdResponse>
　　</soapenv:Body>
　　</soapenv:Envelope>
　　
　　從以上示例可以清楚地看到：WSDL 和 XML 消息表示是啟用服務的主要元素。最重要的是，WSDL 描述了該服務的消息和端口、綁定以及服務定義： EJB 2.1 和 EJB 3.0
　　
　　J2EE 和 EJB 體系結構的改進速度很快；主要供給商正致力于實現與 J2EE 1.4 和 EJB 2.1 規范保持完全一致。
　　
　　增強對 Web 服務的支持是 EJB 2.1 規范背后的驅動力。例如，EJB 2.1 為將非會話狀態會話 bean 公開為 Web 服務提供了顯式支持（對于基于 Java 的客戶機通過 JAX-RPC API 提供支持，對于非 Java 客戶機通過 SOAP 1.1 提供支持）。具體地說，EJB 2.1 規范為非會話狀態會話 bean 定義一個新端點，從而顯式指示：“端點”實際上是一個通過 SOAP 訪問的非會話狀態會話 bean。建議的 EJB 3.0 規范通過從 bean 類生成接口進一步改進了該設計思想。
　　
　　盡管 EJB 2.1 使 Web 服務開發的效率得到了顯著提高，但對可重用性和靈敏性的要求仍是將 J2EE 組件公開為 Web 服務的主要因素，并且在大型 SOA 實現中仍需要進行仔細的設計。
　　
　　<message name="GetSystemIdInput">
　　<part name="body" element="xsd:logon"/>
　　</message>
　　
　　<message name="GetSystemIdOutput">
　　<part name="body" element="xsd:authenticatedId"/>
　　</message>
　　
　　<portType name="SystemIdPortType">
　　<operation name="GetSystemId">
　　<input
　　message="tns:GetSystemIdInput"/>
　　<output
　　message="tns:GetSystemIdOutput"/>
　　</operation>
　　</portType>
　　.....................
　　
　　<service name="GetSystemIdService">
　　<port name="SystemIdPort"
　　.....................
　　<port>
　　</service>
　　
　　但這些 WSDL 和 XML 消息表示究竟如何映射到 Java 對象，尤其是 EJB？首先，mapping.xml 文件指定 Java 到 WSDL 映射（例如，程序包名稱與 XML 名稱空間之間的映射，WSDL 類型與 Java 對象之間的映射等等）。對于 OC4J，該文件由 wsadmin 工具生成，如下所示：
　　
　　<package-mapping>
　　<package-type>AuthenticateCustomer</package-type>
　　<namespaceURI>urn:oracle-ws</namespaceURI>
　　</package-mapping>
　　
　　然后，創建一個名為 webservices.xml 的部署描述符，并將其置于 ejb-jar 文件的 META-INF 中。該描述符指定了由 J2EE 應用服務器控制的服務描述以及它們與容器功能的相關性：
　　
　　............
　　
　　<webservice-description>
　　<webservice-description-name>SystemIdEJB</webservice-description-name>
　　<wsdl-file>META-INF/GetSystemId.wsdl</wsdl-file>
　　...........
　　<port-component>
　　<port-component-name>SystemIdPort</port-component-name>
　　<wsdl-port>
　　<namespaceURI>urn:oracle-ws</namespaceURI>
　　<localpart>SystemIdPort</localpart>
　　</wsdl-port>
　　<service-endpoint-interface>AuthenticateCustomer.GetSystemIdService</service-
　　endpoint-interface>
　　<service-impl-bean>
　　<ejb-link>SystemIdEJB</ejb-link>
　　</service-impl-bean>
　　</port-component>
　　</webservice-description>
　　
　　以上示例表明：假如在開發環境中使用適當的工具（如 Oracle 　應用服務器和 Oracle JDeveloper），則公開 EJB 的過程將非常簡單。但情況并非絕對如此，而且實際的大型分布式應用程序需要模塊化、可重用性、可擴展性、可移植性、版本控制、一致性以及可伸縮性的可持續特性。
　　
　　有關如何利用標準 J2EE 組件（其中的模塊功能面向業務服務上下文）以及 Web 服務中不斷涌現的技術改進或增強軟件開發過程以高效構建高質量的大型應用程序的信息很少。即使我們能夠精確地標識“可以服務”的業務功能并擁有所有必要的應用程序和中間件工具，也無法回答下面這個問題：如何在分布式處理元素中安排應用程序功能或職責，以便在使用 Web 服務時最大限度地增強質量功能？
　　
　　通常情況下，研究 Web 服務的組織利用其現有 Java 對象并直接使用 Web 接口公開它們。最終的結

上一篇：如何調用部署在其他服務器上的EJB？

下一篇：圖解JDeveloper 10g快速開發會話EJB（上）