程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> 為EAI選擇JCA、JMS或Web服務

為EAI選擇JCA、JMS或Web服務

編輯：關於JAVA

引言

　　組織在迅速地發展，他們試圖在控制成本的同時滿足變化的業務需求。這意味著企業需要以支持信息系統的簡易重組的方式來組織他們自己的應用程序。重要的組織變化(例如兼並或子公司的創建)也有可能把新的變數引入信息系統。

　　企業還可能需要到市場上購買應用程序或簽定他們的部分業務需求的轉包合同(例如分類帳或 back-Office 管理)。無法保證現有的技術框架支持這些服務。

　　隨著信息系統變得越來越復雜，開發必須被簡化。這使人們對企業應用程序集成(Enterprise Application Integration，EAI)產生了興趣。企業仍然必須用業務服務和訪問新的集成應用程序的靈活方式來補充 EAI。

　　目前，基於接口的體系結構考慮了這種對業務服務的靈活訪問和客戶機獨立性的不斷增長的需求。基於接口的體系結構包括 Web 服務、 J2C 連接器體系結構(J2C Connector Architecture，JCA;)和 Java 消息服務(Java Message Service，JMS)等技術。它們還包括分離客戶機代碼和業務服務的實現的命令模式的所有變種。這些調用框架與 EAI 中間件之間可以相互調用。

　　在本文中，我們先討論每個接口技術的主要特點，然後講述促使您選擇技術的要求。讀完本文後，您將理解如何定位各種技術以及如何為某個實現選擇其中的一種技術。

　　Web 服務、JCA 和 JMS 的特點

　　這一部分列出有關的接口技術並詳細介紹它們的一些特點。

　　Web 服務

　　Web 服務是面向服務的體系結構(Services OrIEnted Architecture，SOA)的實現。SOA 有松耦合的三方：提供者、代理和請求者。提供者提供的業務服務表示請求者無法直接看到的某個實現。請求者從代理那裡了解它必須從提供者那裡收發的信息結構以及訪問該服務所用的協議。請求者一點也不了解提供者實現業務服務的方式。

　　Web 服務被定義為請求者與提供者之間的必需的業務接口而不是所有業務請求的共同管道。有些變數反映了 Web 服務的特點，包括：

　　它們可以是緊耦合的，它們的部署可以基於調用框架的使用。

　　它們以同步的請求/應答方式或異步方式來執行。

　　它們可由 J2EE 或非 J2EE 的提供程序來公開。

　　它們可能提供事務和安全性的支持(也可能不提供這種支持)。

　　JCA

　　Java 連接器體系結構主要處理的是以緊耦合的方式訪問企業信息系統(Enterprise Information System，EIS)的業務邏輯的需求。連接器體系結構提供了資源適配的支持，資源適配把 J2EE 安全性、事務和通信共享映射到相應的 EIS 技術。

　　起初，人們的意圖是讓連接器以同步的請求/應答方式來訪問大型機上的舊的事務服務器，這也是當前多數連接器的工作方式。目前，標准的發展方向是更異步的雙向連接性。

　　連接器的某些用戶定義的變種更成熟，它們運行在邏輯連接方式下。同樣，它們可被用作調用框架，以類似於 Web 服務的方式來選擇適當的物理 EIS 目標和業務操作。

　　JMS

　　JMS 是異步的、基於消息的接口。您還可以使用 JMS 來訪問分布於不同種類的系統中的業務邏輯。基於消息的接口支持以下功能：

　　點到點和發布/預訂機制。基於消息的框架可把信息傳給其它應用程序而這些程序不必顯式地請求它。相同的信息可被並行地傳遞給許多訂戶。

　　節奏的獨立性。JMS 框架以異步方式運行，但也提供模擬同步的請求/響應方式的功能。這使源系統和目標系統能夠同時運行而不必等待對方。

　　有保證的信息傳遞。JMS 框架可在事務方式下管理消息並確保消息的傳遞(但不確保傳遞的及時性)。

　　不同種類的框架之間的互操作性。源應用程序和目標應用程序可在不同種類的環境中運行而不必處理有關它們相應的框架的通信和執行問題。

　　使交換更流暢。改用消息方式後，信息交換的細粒度變細。

　　選擇接口技術

　　您過去在系統中實現業務邏輯的方式將使您自然地面對這些技術中的一種技術。作出選擇的第一步是分析您現有的基礎結構。有現有的消息傳遞系統或舊系統(例如 CICS 或 IMS)嗎?

　　在許多情況下，訪問大型機 EIS(例如 CICS 或 IMS)的最自然的方式是通過 Java 連接器體系結構。另一方面，如果您需要訪問 .Net 應用程序，那麼您很可能傾向於 Web 服務接口。在其它情況下，您可能使用 JMS 接口，該接口允許消息的交換而且對實現語言的約束很小。

　　請使用以下的決定要點的摘要：

　　您有現有的 Java 應用程序或在規劃新的 Java 應用程序：使用 JMS 或 JCA。

　　您需要與伙伴交互：把 Web 服務用於傳輸和連接。

　　您需要跨越語言之間的障礙：使用 JMS 或 Web 服務。

　　在作出決定時，另一個要考慮的因素是網絡的范圍：是因特網、內部網或外部網中的哪個?該范圍決定了您在選擇傳輸協議時的靈活性。因特網上的部署很可能需要通過 HTTP 的松耦合的 Web 服務。這將與現有的防火牆和非軍事區(demilitarized zone，DMZ)基礎結構相配套，您可以最大限度地降低成本。JMS 和 JCA 更適合作為內部網或外部網協議。JMS 適合用於異步方式或模擬的同步方式，JCA 適合用於更緊的耦合。

　　選擇的共同點

　　Web 服務不是通過 SOAP 提供的服務的同義詞。您可以把任何帶有它的功能的 Web 服務描述語言(Web services Description Language，WSDL)描述的代碼和訪問協議看作 Web 服務。您可以通過多個傳輸和協議來提供任何這種服務。

　　因此，您可以采用以 WSDL 為中心的方式，這一方式由 Web 服務調用框架(Web services Invocation Framework，WSIF)來描述和實現。無論網絡的范圍(內部網、外部網或因特網)，這把您為集成作出的選擇聯系在一起。

　　您很可能試圖把更多的選擇留到未來的擴展規劃中，包括現有企業系統的擴展或連接到業務伙伴。為了簡化這種做法，您可以在一個 WSDL 文檔中描述相同的業務組件，您可以：

　　通過入站綁定(inbound binding)概念，在不同的協議(例如 SOAP 和 RMI-IIOP)中提供。RMI 是 Java 遠程消息調用。因特網 ORB 間協議(Internet Inter-ORB protocol，IIOP)是 CORBA 有線協議。

　　通過出站綁定(outbound binding)概念，用不同類型的組件(例如 JCA 或基於 JMS 的組件)來實現。

　　如果使用這種方式，那麼 JMS 和 JCA 只是服務器提供程序可能用來實現業務組件的幾個協議。因此，不同網絡和接口技術只影響非功能性的部分，例如安全性、性能、響應時間和可用性。當內部網和因特網上的相同組件可被使用時，兩個網絡的區別是所需的安全性、預期的性能和要求的可用性。

　　Web 服務的以 WSDL 為中心的方式使您能夠把抽象的接口從確切的協議棧中分離出來。您可以用兩種方法來實現這種方式(兩種方法都利用 WSIF)：

　　通過使用 IBM Web Services Gateway(WSGW)，現有的 WSDL 描述被部署並在 SOAP 通道中使用 WSDL 描述。入站綁定是 SOAP，出站綁定是現有的 WSDL 實現描述。

　　通過使用 IBM WebSphere Studio Application Developer Integration Edition(WSAD-IE)，現有的 WSDL 描述被消耗並通過 SOAP 或 RMI-IIOP 代理來使用 WSDL 描述。

　　交互模式

　　在設計應用程序時，您需要定義交互的模式。一般來說，這些模式揭示了您對技術集成的偏愛。

　　事件驅動的推模型

　　等待事件的偵聽器提供了標准的事件推模型，該模型對於 EAI 特別重要。業務流程的自動化常常需要捕獲應用程序事件以便傳播到其它的集成應用程序。

　　標准的業務服務的偵聽器常常使用 JMS 或 HTTP 服務器。EJB 中的消息驅動 Bean 使用 JMS，而 Web 服務使用 HTTP。

　　在這個推模型中，被推的事件觸發流程。Web 服務社區已為正式定義這種流程交互的先後順序做了大量的工作。具體地說， Web 服務流程語言(Web services Flow Language，WSFL)和 Web 服務的業務流程執行語言(Business Process Execution Language for Web services，BPEL4WS)標准可處理這種事件排序。

　　在 WSFL 中，作為對進入消息的響應，流程引擎可以執行新的流程實例(以 spawn生命周期操作為標志)。它對單向交互的支持提供了對通知的支持。

　　在 BPEL4WS 中，作為對進入消息的響應， receive或 pick活動可隱式地啟動業務流程; pick活動可根據一組事件中的一件來選擇運行的流程。

　　同步的請求/應答方式

　　在企業中，性能要求可能促使您選擇 JCA 實現，特別是在目前多數業務邏輯在某個現有的 EIS 中的時候，更是這樣。然而，並沒有訪問所有系統的連接器，在有些情況下，用 JMS 來添加消息層是唯一的解決方案。

　　消息傳遞不是請求/響應類型交互的主要選擇。由於消息傳遞所帶來的隔離，用消息傳遞中間件實現的請求/響應阻礙了調用者與被調者之間的事務協調。另外，調用者的編程邏輯(而不是提供的連接器實現)必須管理響應超時。

　　異步模型

　　所有三個接口技術(Web 服務、JMS 甚至 JCA)都可在異步方式下工作。請求或事件被發送至目標而所期待的回答只不過是“消息被正確地傳遞”。它是“發送並忘記(fire-and-forget)”式的交互。

　　在體系結構中支持這個模型不是主要問題，您所用的技術與其它模型中的技術類似。您常常把異步模型與事件推支持或輪詢機制配對，這些細節很可能促使您為實現選擇某種技術。

　　在 Web 服務的情況下，雖然一般來說工具不適合異步交互，但是這種形式被支持。基於 SOAP 的 Web 服務不僅支持同步 RPC 交互方式，還支持異步消息交互方式。它的基礎是面向文檔模型，在這個模型中，請求者和供應者必須處理 SOAP 信封格式化和分析。

　　面向文檔模型是實現真正的單向通信的方法。

技術選擇的要求和含義

　　下一部分討論在選擇業務邏輯的訪問技術中作為決定因素的非功能性要求。

　　松耦合或緊耦合

　　緊耦合意味著存在不易改變的、被迫准確表達的、預先確定的客戶機-服務器或消費者-發布者關系。在這種情況下，對於給定的客戶機，您一般只有一個特定的服務器，該服務器有故障敏感(這意味著客戶機必須處理有關協議的錯誤)的技術交互。您可以在接口定義級別或協議棧級別上查看這種緊耦合。為了訪問該服務，您可能依賴於服務的特定的抽象定義或特定的協議棧。

　　松耦合系統常被設計成解決跨越數據流邊界的問題，工作程序只解決更大的問題的一個部分，而且不一定知道這個問題的上下文。您常常可以通過添加更多的工作程序來自然地擴展這些系統。

　　您可以按以下方式來松耦合：

　　通過提供描述消費者/客戶機與生產者/服務器之間的關系的公共合同，您可以放心地構建和集成您的應用程序而不必讓別人了解您的應用程序的技術細節(以及隨著時間的流逝而發生的變化)。通過相同的標記，您可以使用別的開發者的公共合同來使用他們的應用程序而不必了解細節。

　　通過提供處理與匿名服務器無連接交互的協議棧，您可以放心地通過故障彈性機制與組件交互。

　　通過提供與負載無關的通信通道，特別是通過基於代理的消息傳遞系統。

　　現在，我們把所討論的三種技術映射到松耦合或緊耦合。

　　JCA 是緊耦合技術。

　　JCA 是使用容器來連接請求和連接的企業信息系統的 J2EE 標准。容器是一個耦合器，為安全性、事務作用域、連接管理傳播以及與目標系統的交互提供受管方式支持。

　　JCA 耦合接口由公共客戶機接口來嚴格定義。

　　應用程序組件看不到系統合同和容器-組件合同，但這些合同確實有力地鏈接了調用者和被調者。

　　JCA 尚未處理類似計費和審計的業務問題。實現這些要求仍是應用程序業務體系結構的問題。

　　JMS 是松耦合技術。例如，它(只給消息中間件)不給目標系統提供安全性或事務綁定。一般來說，消息傳遞實現松耦合的原因有：

　　消息制造者和消費者在點到點或發布/預訂模型中通過消息傳遞傳輸(例如消息代理)來交互。

　　提供的技術頭常常獨立於業務負載。

　　JMS 很適合於：

　　集成參與業務事件的系統/組件。

　　集成遲緩的響應者。

　　集成現有的系統。

　　Web 服務的目標是業務服務而不是技術連接性。它們主要用松技術耦合但接口定義級別上的緊耦合來實現。

　　在 Web 服務中，耦合基於接口定義和協議綁定。

　　合同用 WSDL 來發布，WSDL 定義了接口，接口定義了可用的操作。

　　用於訪問 Web 服務的協議多種多樣。這個協議被稱為入站綁定，它定義了如何獲取實現助診文件。

　　訪問實現的方法也多種多樣。這個協議被稱為出站綁定，它定義了實現公共合同的助診文件。示例包括 JavaBeans、EJB 和 JCA。

　　Web 服務中的耦合方式提供了靈活性，有兩種綁定：靜態和動態。

　　靜態綁定意味著緊耦合：請求者使用在設計時獲取的服務實現;不必使用私有的或共享的注冊中心。

　　動態綁定意味著松耦合：請求者在運行時發現用於被調用的服務的實現;它甚至可能在運行時確定應該被調用的接口。

　　在現實中，目前多數 Web 服務把 SOAP 用作入站協議。SOAP 是松耦合協議，直至服務等級被支持。服務等級將處理安全性、可靠性和可用性。

　　由於 SOAP 無處不在、防火牆友好和其它優點，SOAP 仍是缺省協議。另外，SOAP 是目前開發 Web 服務安全性規范的地方;所以在實踐中，定義標准的安全性方式意味著使用 SOAP。

　　現在，在 Web 服務中，一些其它輔助業務功能(例如計費和審計)已經可用。

　　可移植性和互操作性

　　Web 服務不在調用者與被調者之間強加編程語言或操作系統限制。在不久的將來，很有可能處理 SOAP 的某些互操作性問題，例如 apache 實現與其它實現之間的差異。在解決它之後，所有支持 Web 服務的平台將可以互操作(包括 .NET 和 J2EE 平台)。但是即使到那時，Web 服務客戶機或服務器實現代碼也不能在供應商之間移植。為 .Net 編寫的實現代碼肯定不能運行於 J2EE。

　　JMS 和 JCA 只處理 Java 世界。有了 JCA，就可以在 Java 客戶機代碼端上實現可移植性，而且互操作性限於特定的目標。為了在技術級別上互操作，JMS 要求在兩端都有 Java 環境，但是消息負載是無關的，通過使用 JAXM Web 服務，可在 JMS 上攜帶 SOAP 負載。

　　事務支持

　　JCA 並不總是支持 EIS 的端到端事務支持。前面已提到，連接器提供程序實現了把事務上下文傳播到目標系統的容器。這是通過事務管理系統合同來完成的，在合同中，容器被用作控制作為資源管理器的 EIS 的事務管理器。這是基於 XA標准。

　　Web 服務目前不支持事務。標准委員會正在研究用 WS-Coordination 和 WS-transaction 標准來提供松耦合模型中的事務支持的方法。今後將出現使用補償的松耦合模型和使用類似 XA 事務模型的緊耦合模型。

　　在消息傳遞模型中，消息被傳遞到隊列後，客戶機無法控制它的傳播。所以 JMS 只支持隊列入口點的事務，不支持目標應用程序的事務。

　　可靠性

　　目前，唯一有保證的傳遞是通過 JMS(盡管沒有消息延遲的保證)。為了今後的需要，IBM、Microsoft、BEA 和 TIBCO 已聯合提出了在 Web 服務環境中交換安全的、可靠的消息的標准機制。您可在 Web 服務組織站點獲取這些標准。JCA 連接的可靠性總是特定於連接器，JCA 本身並不意味著可靠性。

　　安全性

　　安全性是標准化程度最低的領域。在 JMS 中，規范明確規定安全性由 JMS 提供程序實現(該實現與其它的 J2EE 安全性兼容)來決定。幸運的是，IBM 也堅持這一標准。在 JCA 中，安全性的支持取決於連接器容器的功能和目標企業信息系統的實現。

　　HTTPS 支持在傳輸層上提供某種 Web 服務安全性。但是，在 Web 服務器譯碼和認證請求後，它是易受攻擊的，只有使用 SOAP 安全性擴展(SOAP Security Extensions，SOAP-SEC)的某些 Web 服務實現支持目前可用的安全性(請參閱參考資料以了解更多有關 SOAP-SEC 的信息)。有關 WS-Security 標准的標准化工作正在進行，WS-Security 將在未來實現完全互操作的端到端安全性模型。

　　結束語

　　您可以看到，需要根據多個標准來為集成選擇 Web 服務、JMS 和 JCA 實現中的一個實現。通過映射到某些解決方案的要求並對這些要求劃分優先級，設計者可為他們特殊的情況選擇正確的實現。

　　下面的表總結了我們已討論過的內容並列出了決定的標准：

Web 服務

JMS

JCA

注釋

接口耦合（抽象服務定義）

是

支持動態接口發現和請求構造

否

負載無關