| Regis Coqueret (regis.coqueret@fr.ibm.com), 客戶(hù)經(jīng)理／解決方案 設計師, jStart Emerging Technologies，IBM Software Group 2003 年 3 月 01 日 本文討論了在 J2C 連接器體系結構（J2C Connector Architecture，JCA）、Java 消息服務(wù)（Java Message Service，JMS）和 Web 服務(wù)實(shí)現之間作出選擇的標準（選擇的依據是現有的環(huán)境、您想實(shí)現的模式和松耦合或緊耦合的預置要求）。
組織在迅速地發(fā)展，他們試圖在控制成本的同時(shí)滿(mǎn)足變化的業(yè)務(wù)需求。這意味著(zhù)企業(yè)需要以支持信息系統的簡(jiǎn)易重組的方式來(lái)組織他們自己的應用程序。重要的組織變化（例如兼并或子公司的創(chuàng )建）也有可能把新的變數引入信息系統。 企業(yè)還可能需要到市場(chǎng)上購買(mǎi)應用程序或簽定他們的部分業(yè)務(wù)需求的轉包合同（例如分類(lèi)帳或 back-office 管理）。無(wú)法保證現有的技術(shù)框架支持這些服務(wù)。 隨著(zhù)信息系統變得越來(lái)越復雜，開(kāi)發(fā)必須被簡(jiǎn)化。這使人們對 企業(yè)應用程序集成（Enterprise Application Integration，EAI）產(chǎn)生了興趣。企業(yè)仍然必須用業(yè)務(wù)服務(wù)和訪(fǎng)問(wèn)新的集成應用程序的靈活方式來(lái)補充 EAI。 目前，基于接口的體系結構考慮了這種對業(yè)務(wù)服務(wù)的靈活訪(fǎng)問(wèn)和客戶(hù)機獨立性的不斷增長(cháng)的需求?；诮涌诘捏w系結構包括 Web 服務(wù)、 J2C 連接器體系結構（J2C Connector Architecture，JCA；請參閱 參考資料以了解更多信息）和 Java 消息服務(wù)（Java Message Service，JMS）等技術(shù)。它們還包括分離客戶(hù)機代碼和業(yè)務(wù)服務(wù)的實(shí)現的命令模式的所有變種。這些調用框架與 EAI 中間件之間可以相互調用。 在本文中，我們先討論每個(gè)接口技術(shù)的主要特點(diǎn)，然后講述促使您選擇技術(shù)的要求。讀完本文后，您將理解如何定位各種技術(shù)以及如何為某個(gè)實(shí)現選擇其中的一種技術(shù)。
Web 服務(wù)、JCA 和 JMS 的特點(diǎn)
這一部分列出有關(guān)的接口技術(shù)并詳細介紹它們的一些特點(diǎn)。
Web 服務(wù)被定義為請求者與提供者之間的必需的業(yè)務(wù)接口而不是所有業(yè)務(wù)請求的共同管道。有些變數反映了 Web 服務(wù)的特點(diǎn)，包括：
起初，人們的意圖是讓連接器以同步的請求／應答方式來(lái)訪(fǎng)問(wèn)大型機上的舊的事務(wù)服務(wù)器，這也是當前多數連接器的工作方式。目前，標準的發(fā)展方向是更異步的雙向連接性。 連接器的某些用戶(hù)定義的變種更成熟，它們運行在邏輯連接方式下。同樣，它們可被用作調用框架，以類(lèi)似于 Web 服務(wù)的方式來(lái)選擇適當的物理 EIS 目標和業(yè)務(wù)操作。
點(diǎn)到點(diǎn)和發(fā)布／預訂機制?；谙⒌目蚣芸砂研畔鹘o其它應用程序而這些程序不必顯式地請求它。相同的信息可被并行地傳遞給許多訂戶(hù)。 節奏的獨立性。JMS 框架以異步方式運行，但也提供模擬同步的請求／響應方式的功能。這使源系統和目標系統能夠同時(shí)運行而不必等待對方。 有保證的信息傳遞。JMS 框架可在事務(wù)方式下管理消息并確保消息的傳遞（但不確保傳遞的及時(shí)性）。 不同種類(lèi)的框架之間的互操作性。源應用程序和目標應用程序可在不同種類(lèi)的環(huán)境中運行而不必處理有關(guān)它們相應的框架的通信和執行問(wèn)題。 使交換更流暢。改用消息方式后，信息交換的細粒度變細。
您過(guò)去在系統中實(shí)現業(yè)務(wù)邏輯的方式將使您自然地面對這些技術(shù)中的一種技術(shù)。作出選擇的第一步是分析您現有的基礎結構。有現有的消息傳遞系統或舊系統（例如 CICS 或 IMS）嗎？ 在許多情況下，訪(fǎng)問(wèn)大型機 EIS（例如 CICS 或 IMS）的最自然的方式是通過(guò) Java 連接器體系結構。另一方面，如果您需要訪(fǎng)問(wèn) .NET 應用程序，那么您很可能傾向于 Web 服務(wù)接口。在其它情況下，您可能使用 JMS 接口，該接口允許消息的交換而且對實(shí)現語(yǔ)言的約束很小。 請使用以下的決定要點(diǎn)的摘要： 您有現有的 Java 應用程序或在規劃新的 Java 應用程序：使用 JMS 或 JCA。 您需要與伙伴交互：把 Web 服務(wù)用于傳輸和連接。 您需要跨越語(yǔ)言之間的障礙：使用 JMS 或 Web 服務(wù)。 在作出決定時(shí)，另一個(gè)要考慮的因素是網(wǎng)絡(luò )的范圍：是因特網(wǎng)、內部網(wǎng)或外部網(wǎng)中的哪個(gè)？該范圍決定了您在選擇傳輸協(xié)議時(shí)的靈活性。因特網(wǎng)上的部署很可能需要通過(guò) HTTP 的松耦合的 Web 服務(wù)。這將與現有的防火墻和 非軍事區（demilitarized zone，DMZ）基礎結構相配套，您可以最大限度地降低成本。JMS 和 JCA 更適合作為內部網(wǎng)或外部網(wǎng)協(xié)議。JMS 適合用于異步方式或模擬的同步方式，JCA 適合用于更緊的耦合。
Web 服務(wù)不是通過(guò) SOAP 提供的服務(wù)的同義詞。您可以把任何帶有它的功能的 Web 服務(wù)描述語(yǔ)言（Web services Description Language，WSDL）描述的代碼和訪(fǎng)問(wèn)協(xié)議看作 Web 服務(wù)。您可以通過(guò)多個(gè)傳輸和協(xié)議來(lái)提供任何這種服務(wù)。 因此，您可以采用以 WSDL 為中心的方式，這一方式由 Web 服務(wù)調用框架（Web services Invocation Framework，WSIF）來(lái)描述和實(shí)現。無(wú)論網(wǎng)絡(luò )的范圍（內部網(wǎng)、外部網(wǎng)或因特網(wǎng)），這把您為集成作出的選擇聯(lián)系在一起。 您很可能試圖把更多的選擇留到未來(lái)的擴展規劃中，包括現有企業(yè)系統的擴展或連接到業(yè)務(wù)伙伴。為了簡(jiǎn)化這種做法，您可以在一個(gè) WSDL 文檔中描述相同的業(yè)務(wù)組件，您可以：
如果使用這種方式，那么 JMS 和 JCA 只是服務(wù)器提供程序可能用來(lái)實(shí)現業(yè)務(wù)組件的幾個(gè)協(xié)議。因此，不同網(wǎng)絡(luò )和接口技術(shù)只影響非功能性的部分，例如安全性、性能、響應時(shí)間和可用性。當內部網(wǎng)和因特網(wǎng)上的相同組件可被使用時(shí)，兩個(gè)網(wǎng)絡(luò )的區別是所需的安全性、預期的性能和要求的可用性。 Web 服務(wù)的以 WSDL 為中心的方式使您能夠把抽象的接口從確切的協(xié)議棧中分離出來(lái)。您可以用兩種方法來(lái)實(shí)現這種方式（兩種方法都利用 WSIF）：
在設計應用程序時(shí)，您需要定義交互的模式。一般來(lái)說(shuō)，這些模式揭示了您對技術(shù)集成的偏愛(ài)。
標準的業(yè)務(wù)服務(wù)的偵聽(tīng)器常常使用 JMS 或 HTTP 服務(wù)器。EJB 中的消息驅動(dòng) Bean 使用 JMS，而 Web 服務(wù)使用 HTTP。 在這個(gè)推模型中，被推的事件觸發(fā)流程。Web 服務(wù)社區已為正式定義這種流程交互的先后順序做了大量的工作。具體地說(shuō)， Web 服務(wù)流程語(yǔ)言（Web services Flow Language，WSFL）和 Web 服務(wù)的業(yè)務(wù)流程執行語(yǔ)言（Business Process Execution Language for Web services，BPEL4WS）標準可處理這種事件排序。
消息傳遞不是請求／響應類(lèi)型交互的主要選擇。由于消息傳遞所帶來(lái)的隔離，用消息傳遞中間件實(shí)現的請求／響應阻礙了調用者與被調者之間的事務(wù)協(xié)調。另外，調用者的編程邏輯（而不是提供的連接器實(shí)現）必須管理響應超時(shí)。
在體系結構中支持這個(gè)模型不是主要問(wèn)題，您所用的技術(shù)與其它模型中的技術(shù)類(lèi)似。您常常把異步模型與事件推支持或輪詢(xún)機制配對，這些細節很可能促使您為實(shí)現選擇某種技術(shù)。 在 Web 服務(wù)的情況下，雖然一般來(lái)說(shuō)工具不適合異步交互，但是這種形式被支持?；?SOAP 的 Web 服務(wù)不僅支持同步 RPC 交互方式，還支持異步消息交互方式。它的基礎是面向文檔模型，在這個(gè)模型中，請求者和供應者必須處理 SOAP 信封格式化和分析。 面向文檔模型是實(shí)現真正的單向通信的方法。
下一部分討論在選擇業(yè)務(wù)邏輯的訪(fǎng)問(wèn)技術(shù)中作為決定因素的非功能性要求。
松耦合系統常被設計成解決跨越數據流邊界的問(wèn)題，工作程序只解決更大的問(wèn)題的一個(gè)部分，而且不一定知道這個(gè)問(wèn)題的上下文。您常?？梢酝ㄟ^(guò)添加更多的工作程序來(lái)自然地擴展這些系統。 您可以按以下方式來(lái)松耦合：
現在，我們把所討論的三種技術(shù)映射到松耦合或緊耦合。 JCA 是緊耦合技術(shù)。
JMS 是松耦合技術(shù)。例如，它（只給消息中間件）不給目標系統提供安全性或事務(wù)綁定。一般來(lái)說(shuō)，消息傳遞實(shí)現松耦合的原因有：
JMS 很適合于：
Web 服務(wù)的目標是業(yè)務(wù)服務(wù)而不是技術(shù)連接性。它們主要用松技術(shù)耦合但接口定義級別上的緊耦合來(lái)實(shí)現。 在 Web 服務(wù)中，耦合基于接口定義和協(xié)議綁定。
Web 服務(wù)中的耦合方式提供了靈活性，有兩種綁定：靜態(tài)和動(dòng)態(tài)。
在現實(shí)中，目前多數 Web 服務(wù)把 SOAP 用作入站協(xié)議。SOAP 是松耦合協(xié)議，直至 服務(wù)等級被支持。服務(wù)等級將處理安全性、可靠性和可用性。 由于 SOAP 無(wú)處不在、防火墻友好和其它優(yōu)點(diǎn)，SOAP 仍是缺省協(xié)議。另外，SOAP 是目前開(kāi)發(fā) Web 服務(wù)安全性規范的地方；所以在實(shí)踐中，定義標準的安全性方式意味著(zhù)使用 SOAP。 現在，在 Web 服務(wù)中，一些其它輔助業(yè)務(wù)功能（例如計費和審計）已經(jīng)可用。
JMS 和 JCA 只處理 Java 世界。有了 JCA，就可以在 Java 客戶(hù)機代碼端上實(shí)現可移植性，而且互操作性限于特定的目標。為了在技術(shù)級別上互操作，JMS 要求在兩端都有 Java 環(huán)境，但是消息負載是無(wú)關(guān)的，通過(guò)使用 JAXM Web 服務(wù)，可在 JMS 上攜帶 SOAP 負載。
Web 服務(wù)目前不支持事務(wù)。標準委員會(huì )正在研究用 WS-Coordination 和 WS-transaction 標準來(lái)提供松耦合模型中的事務(wù)支持的方法。今后將出現使用補償的松耦合模型和使用類(lèi)似 XA 事務(wù)模型的緊耦合模型。 在消息傳遞模型中，消息被傳遞到隊列后，客戶(hù)機無(wú)法控制它的傳播。所以 JMS 只支持隊列入口點(diǎn)的事務(wù)，不支持目標應用程序的事務(wù)。
HTTPS 支持在傳輸層上提供某種 Web 服務(wù)安全性。但是，在 Web 服務(wù)器譯碼和認證請求后，它是易受攻擊的，只有使用 SOAP 安全性擴展（SOAP Security Extensions，SOAP-SEC）的某些 Web 服務(wù)實(shí)現支持目前可用的安全性（請參閱 參考資料以了解更多有關(guān) SOAP-SEC 的信息）。有關(guān) WS-Security 標準的標準化工作正在進(jìn)行，WS-Security 將在未來(lái)實(shí)現完全互操作的端到端安全性模型。
您可以看到，需要根據多個(gè)標準來(lái)為集成選擇 Web 服務(wù)、JMS 和 JCA 實(shí)現中的一個(gè)實(shí)現。通過(guò)映射到某些解決方案的要求并對這些要求劃分優(yōu)先級，設計者可為他們特殊的情況選擇正確的實(shí)現。 下面的表總結了我們已討論過(guò)的內容并列出了決定的標準：
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
聯(lián)系客服
