Web服務設計師，第3部分：Web服務是CORBA的翻版嗎？

申請免費試用、咨詢電話：400-8352-114

Web服務設計師，第3部分：Web服務是CORBA的翻版嗎？

Dan Gisolfi (gisolfi@us.ibm.com)

解決方案設計師，IBM jStart Emerging Technologies

2001 年 7 月

早在 Web 服務傳播的初期，客戶們就已經(jīng)開始詢問這一技術與 CORBA 有何區(qū)別。 它是不是分布式計算的另一種形式？在 Web 服務設計師的這一部分，Dan Gisolfi 簡要概述了 SOAP、DCOM 和 CORBA 之間的區(qū)別，并為分布式計算領域內(nèi)的 Web 服務提出了一個有價值的建議。
可通過點擊文章頂部或者底部的討論，加入這篇文章的討論論壇。

在以前的文章中，我曾論述過動態(tài)電子商務的構想以及能讓我們得以實現(xiàn)這一構想的可用技術，也就是 SOAP、WSDL 和 UDDI。對于好奇的讀者來說，動態(tài)電子商務的整個課題只是分布式計算的另一種形式。對于這一新的分布式計算模型所作的調(diào)整改進是跨平臺以及跨編程語言的互操作性。自從分布式計算成為主流概念以來，我們首次擁有了一個建立在真正支持互操作性的開放標準基礎上的解決方案。

在宣傳 Web 服務的整個行程中，我所面對的聽眾總會產(chǎn)生一種善意的疑問。拋開聽眾不談，對于 Web 服務的疑問通常是通過以下（及相關的）問題中的某一個表現(xiàn)出來：

Web 服務技術與 CORBA 有何區(qū)別？

為什么 Web 服務能在 CORBA 失敗的領域獲得成功？

有兩個原因使得我對這些問題持歡迎態(tài)度。首先，它們反映了人們對于分布式計算有一定的熟悉程度，這有助于交流的開展。分布式計算編程模型在 IT 產(chǎn)業(yè)內(nèi)成為主流已經(jīng)有些時日了。我估計這一情形至少在近二十年內(nèi)是如此。因此交流能著重于以前解決方案的缺點以及將來對于成功的解決方案的要求。

其次，由于我們討論的并非一個全新的概念，那么人們能否接受 Web 服務的有關風險就小了。這也反映了它的開放標準基礎以及這些標準在廠商解決方案中的普遍性。低風險還反映了在改進 Web 服務互操作性方面所做的實際努力（這與以前解決方案所作出的關于廠商互操作性的“圓滑”承諾形成了對比 — 我在后面還將詳細講述這一點）。

過去，對象管理組（Object Management Group，OMG）及其 700 多個成員公司曾試圖規(guī)定廠商們需如何設計對象請求代理程序（object request brokers，ORB）以實現(xiàn)互操作性。然而，現(xiàn)實情況是廠商們在 ORB 的實現(xiàn)上存在競爭，因此從商業(yè)的角度來說不存在實現(xiàn)互操作性的動機。事實上，真正的 ORB 廠商的商業(yè)目的是能在分布式計算應用程序的兩端同時出售其解決方案：請求者和 提供者節(jié)點。

SOAP 是一個出色的分布式計算解決方案，因為它通過規(guī)范級別和實現(xiàn)級別上的開放標準，實現(xiàn)了互操作性。我跳到后面的內(nèi)容上去了。讓我們回過頭來看一下 CORBA 和 DCOM，最后再來看 SOAP。我將提供一些關鍵區(qū)別，并舉例說明為什么基于 SOAP 技術的 Web 服務擁有更好的分布式計算解決方案。

通信協(xié)議模型的簡單歷史

分布式應用程序需要一個定義兩個并發(fā)進程間通信機制的協(xié)議。存在兩種建立這種應用程序的通信協(xié)議模型： 消息傳遞／排隊以及請求／響應。消息傳遞和請求／響應模型各有所長，可以相互代替執(zhí)行。例如，能用較低級別的請求／響應協(xié)議來建立消息傳遞系統(tǒng)。Microsoft 分布式計算環(huán)境（Distributed Computing Environment，DCE）就是這樣的。對于遠程過程調(diào)用（Remote Procedure Call，RPC）應用程序來說，同步請求／響應的設計風格通常是自然契合的。

在 20 世紀 80 年代，通信協(xié)議模型集中在網(wǎng)絡層上，如最初由 Sun Microsystems 開發(fā)的網(wǎng)絡文件系統(tǒng)（Network File System，NFS）— 大多數(shù)聯(lián)網(wǎng)的 Unix 系統(tǒng)都用它作為分布式文件系統(tǒng) — 以及 Microsoft 的運行在 Windows NT 上的 DCE RPC 應用程序。到了 90 年代，面向對象的編程團體迫切要求一個能將應用程序對象與網(wǎng)絡協(xié)議鏈接起來的對象 RPC（ORPC）協(xié)議。ORPC 和先于它們的 RPC 協(xié)議之間的主要區(qū)別是 ORPC 將通信端點的映射編碼至一個語言級別的對象中（請參閱參考資料中的 A Young Person's Guide to The Simple Object Access Protocol ）。

這一映射允許服務器端的中間件在服務器進程中定位并實例化一個目標對象。有一些技術（如將索引作為散列表鍵映射到一個數(shù)組或相關聯(lián)的符號名稱中）被用來實現(xiàn)端點到對象的映射。在 SOAP 和 Web 服務出現(xiàn)以前，在通用內(nèi)部 ORB 協(xié)議（GIOP）中，Microsoft DCOM 和 CORBA 的因特網(wǎng)內(nèi)部 ORB 協(xié)議（Internt Inter-ORB Protocol，IIOP）風格是業(yè)界的主流 ORPC 協(xié)議。

什么是 CORBA？

公共對象請求代理架構（Common Object Request Broker Architecture，CORBA）是對象管理組實現(xiàn)分布式計算節(jié)點間的互操作性的規(guī)范。他們的目標是定義一個架構，該架構能允許不同種類的環(huán)境進行對象級通信，而無需考慮是誰設計了分布式應用程序的兩個端點。

CORBA 1.1 由對象管理組（Object Management Group，OMG）于 1991 年提出。它定義了允許客戶機／服務器對象在對象請求代理（Object Request Broker，ORB）的特定實現(xiàn)中相互作用的接口定義語言（Interface Definition Language，IDL）和應用程序編程接口（Application Programming Interfaces，API）。ORB 是在分布式對象間建立請求者-提供者關系的中間件。

CORBA 2.0 于 1994 年 12 月被采用，它通過指定來自不同廠商的 ORB 如何相互操作解決了互操作性問題。（請參閱參考資料）。

ORB 將收到一條調(diào)用消息，來為注冊的對象調(diào)用一個特定的方法。ORB 截獲這條消息，并負責搜索一個能執(zhí)行該請求的對象，將參數(shù)傳遞給它，調(diào)用它的方法，然后返回結果。理論上，請求節(jié)點無需知道對象的位置、它的編程語言、它的操作系統(tǒng)或不屬于對象接口的一部分的任何其它系統(tǒng)方面的信息。

接口用一系列方法在外部把 CORBA 對象表現(xiàn)出來。一個對象引用可以識別對象的一個特殊實例。CORBA 對象的一個客戶程序獲取了其對象引用，并將它用作句柄進行方法調(diào)用，就好像對象是位于客戶程序的地址空間中一樣。ORB 負責搜索對象的實現(xiàn)所需要的所有機制，讓它做好接收請求的準備，隨后將請求傳達給它，并將回應（如果有的話）送回客戶程序。

什么是 DCOM？

DCOM 是 Microsoft 的 COM（組件對象模型，Component Object Model）的分布式擴展（請參閱參考資料中的 COM95），它在 DCE RPC （請參閱參考資料中的 DCE95）的頂端建立了一個對象遠程過程調(diào)用（ORPC）的層來支持遠程對象。COM 服務器能創(chuàng)建多對象類的對象實例。一個 COM 對象可以支持多個接口，每個接口代表對象的一種不同的視圖或行為。一個接口由一套功能相關的方法組成。COM 的客戶程序通過獲取指向一個對象接口的一個指針，并通過該指針來調(diào)用方法以實現(xiàn)與 COM 對象之間的互相作用，就好像對象駐留在客戶程序的地址空間中一樣。COM 指定任何接口都必須遵循一個標準的內(nèi)存規(guī)劃，這與 C++ 的虛擬函數(shù)表（請參閱參考資料中的 Rogerson96）相同。由于該規(guī)范是二進制級別的，因此它允許集成可能用不同編程語言如 C++、Java 和 Visual Basic（請參閱參考資料）等編寫的二進制組件。

基礎 RPC 架構

在 DCOM 和 CORBA 中，客戶進程與對象服務器之間的互相作用是作為面向對象的 RPC 式通信來實現(xiàn)的。圖 1 展示了一個典型的 RPC 結構。為調(diào)用一個遠程函數(shù)，客戶程序要調(diào)用客戶機存根。然后存根將調(diào)用參數(shù)打包成一個請求消息并調(diào)用傳輸協(xié)議將該消息傳送到服務器。在服務器端，傳輸協(xié)議將消息傳送給服務器存根，隨后服務器存根解包請求消息并調(diào)用對象中真正的函數(shù)。在 DCOM 中，客戶機存根被稱為代理（Proxy），而服務器存根被稱為存根（Stub）。相反，CORBA 中的客戶機存根稱為存根（Stub），而服務器存根稱為框架（Skeleton）。有時， 代理這個名稱還被用來指 CORBA 中正在運行的存根實例。至于在 SOAP 和 Web 服務中，我們稱客戶機存根為服務代理（Service Proxy），稱服務器存根為服務實現(xiàn)模板（Service Implementation Template）。表 1 說明了這些概念的不同名稱

表 1：不同 RPC 架構中的客戶機與服務器組件

RPC 架構 客戶機存根 服務器存根 CORBA 存根 框架 DCOM 代理 存根 Web 服務 服務代理 服務實現(xiàn)模板

圖 1：基本 RPC 架構

細微的差別影響互操作性

DCOM 和 CORBA IIOP 有許多相似之處。這兩個協(xié)議都使用端點標識符來識別服務器端中間件中的目標對象，且它們都使用方法標識符來確定待調(diào)用方法的簽名。

表 2：CORBA 和 DCOM 中實現(xiàn)屬性名稱比較

實現(xiàn)屬性 DCOM CORBA 端點命名 OBJREF IOR 接口／對象 多個 單個 有效負載參數(shù)值格式 DR CDR

然而，與這些相似之處同時存在的還有一些影響互操作性的差別。 如表 2 所示，存在三個主要的差別：

通信端點的命名：在 ORPC 協(xié)議中，需要 ORPC 端點的一些消息表示法以便通過網(wǎng)絡傳達對象引用。在 CORBA/IIOP 中，這種表示法被稱為可互操作的對象引用（Interoperable Object Reference，IOR）。IOR 包含可移植格式的尋址信息，任何基于 CORBA 的產(chǎn)品都能把這些信息解析到對象端點上去。在 DCOM 中，這種表示法被稱為 OBJREF，它能將分布式引用計數(shù)與端點／對象識別結合起來。遺憾的是，IOR 不能與 OBJREF 相互關聯(lián)，這就導致了 CORBA 和 DCOM 應用程序之間的互操作性問題。

支持一對象多接口：在 CORBA 中，接口標識符是固有的，因為它只支持一種對象接口。然而 DCOM 能支持一對象多接口。

有效負載參數(shù)值的格式：在 DCOM 中，有效負載是以一種稱為網(wǎng)絡數(shù)據(jù)表示法（Network Data Representation，DR）的格式編寫的。在 IIOP/GIOP 中，有效負載是用通用數(shù)據(jù)表示法（Common Data Representation，CDR）編寫的。DR 和 CDR 都處理各種平臺上使用的不同數(shù)據(jù)表示法。需要注意的是，這兩種格式之間存在著一些細微的差別，使得它們彼此無法兼容。

為什么 CORBA 和 DCOM 的成功是有限的

盡管 CORBA 和 DCOM 已經(jīng)在各種平臺上得到了實現(xiàn)，然而實際情況是建立在這些協(xié)議之上的任何解決方案都依賴于單一廠商的實現(xiàn)。因此，如果要開發(fā)一個 DCOM 應用程序，分布式應用程序中所有參與的節(jié)點都必須以 Windows 風格運行。如果要開發(fā) CORBA 應用程序，應用程序環(huán)境中的每個節(jié)點都要運行相同的 ORB 產(chǎn)品?，F(xiàn)在也有來自不同廠商的 CORBA ORB 能夠相互操作。但是那種互操作性并不能擴展到像安全與事務管理那樣的更高級別的服務中去。不僅如此，所有特定于廠商的優(yōu)化在這種情況下將丟失殆盡。

這兩種協(xié)議都依賴于嚴格管理的環(huán)境。要找到能成功地在外部調(diào)用 DCOM 或 IIOP 的任意兩臺計算機的幾率比較?。ㄕ垍㈤唴⒖假Y料）。此外，程序員們必須處理數(shù)據(jù)排列和數(shù)據(jù)類型所需的協(xié)議唯一的消息格式規(guī)則。DCOM 和 CORBA 都是服務器對服務器通信的合適的協(xié)議。然而，它們在客戶機對服務器通信方面都存在嚴重的缺陷，特別是當客戶機遍布因特網(wǎng)時。

改進的 RPC 解決方案需要些什么

盡管 CORBA 和 DCOM 存在著局限性，但由于我們迫切需要一個分布式計算模型，因此它們還是得到了廣泛的應用。事實上，隨著因特網(wǎng)的出現(xiàn)，企業(yè)越來越強烈地希望在公司外部與分布式應用程序結合。那么一個成功的分布式計算模型需要有一些什么樣的特征呢？首先，解決方案一定是廠商、平臺以及語言都不確定的。此外，它所提供的必須不只是互操作性的承諾；它必須使互操作性有很大的提高。另外，它必須能方便程序員們使用協(xié)議及部署應用程序。這就要求能方便地訪問協(xié)議的客戶機和服務器端的實現(xiàn)。簡單地說，我們需要一個建立在開放因特網(wǎng)標準基礎上的新的分布式計算模型。

依賴開放因特網(wǎng)標準

Web 服務技術組件是一套開放的規(guī)范，它們要么是現(xiàn)有的因特網(wǎng)標準，要么是被廣泛接受并正在通過正常步驟成為標準的規(guī)范。組件的基本部分包含 HTTP、XML、SOAP、WSDL、UDDI 以及 WSFL。

這部分的基礎是 HTTP，它是一個被廣泛運用的、類似 RPC 的簡單協(xié)議，并且是防火墻友好的。接下來，是 XML 中的通用數(shù)據(jù)表示法語言，它同樣被廣泛使用。SOAP 是一個基于 XML 的消息傳遞協(xié)議，它不確定平臺及語言。它同時支持消息傳遞和請求／響應通信模型。與 CORBA 和 DCOM 一樣，它需要一個 IDL。它所使用的 WSDL 是一個基于 XML 的服務 IDL，定義了服務接口和其實現(xiàn)特征。

讓我們回顧一下表 2，并注意 HTTP 和 XML 作為一個新的分布式計算模型帶給 Web 服務的價值。在 HTTP 中，請求和響應消息都能包含任意的有效負載信息。HTTP 報頭（HTTP header）只是純文本，這使得一般的因特網(wǎng)程序員便于使用。通常，這些報頭包含內(nèi)容長度和內(nèi)容類型。并且 HTTP 使用 TCP/IP 作為其請求／響應消息的網(wǎng)絡通信協(xié)議。HTTP 客戶機利用 TCP 連接到 HTTP 服務器。建立了 TCP 連接以后，客戶機可以向服務器發(fā)送 HTTP 請求消息。然后服務器對請求進行處理后將 HTTP 響應消息發(fā)送回客戶機。簡單地說，HTTP 是一種出色的不確定有效負載的傳輸方式，它提供了 CORBA 和 DCOM 中所能找到的大部分連接管理功能。它還使用 URL 進行對象引用，它們與分別在 CORBA 和 DCOM 中找到的 IOR 和 OBJREF 相一致。

由于 HTTP 是不確定有效負載的，它確實缺少一個在 RPC 消息中表示參數(shù)值的機制。這就需引入 XML 了。XML 是一種與平臺無關的標記數(shù)據(jù)表示語言。它允許數(shù)據(jù)串行化為一種消息格式，從而能輕易地在任何平臺上進行解碼。然而，與 DR 和 CDR 不同，XML 很容易使用，它提供了一種靈活的、易于擴展的數(shù)據(jù)格式，并且能獲得幾乎所有計算平臺的支持。不僅如此，它還是開放的，并且被廣泛采用。表 2 描述了 HTTP 和 XML 是如何解決困擾 CORBA 和 DCOM 的互操作性問題的。

Web 服務技術組件提供了 SOAP 作為映射應用程序對象到網(wǎng)絡協(xié)議的開放標準 ORPC（請參閱表 3）。盡管 SOAP 不受特定的傳輸協(xié)議的約束，HTTP 還是成為了早先在 SOAP 采納者中最受歡迎的協(xié)議。使用 HTTP 時，SOAP 信封使用 XML 作為請求和響應參數(shù)的編碼方案。SOAP 消息實質上是一個遵循 SOAP 編碼規(guī)則的 HTTP 請求和響應。SOAP 端點就是一個基于 HTTP 的、識別方法調(diào)用目標的 URL。與 CORBA 一樣，SOAP 并不要求一個特定對象被連接到給定的端點上。相反，需要由實現(xiàn)者來決定如何將對象端點標識符映射到服務器端的對象上。在 SOAP 中檢查方法名稱的名稱空間 URI 與在 DCOM 或 CORBA 中檢查方法名稱的接口 ID 在功能上是相同的。

表 3：Web 服務的互操作性特征

實現(xiàn)特征 Web 服務 端點命名 URL 接口／對象 多個 — WSDL 有效負載參數(shù)值格式 XML

通向成功之路

依靠開放的、被廣泛采用的標準只是解決方案的一部分。我們還需確保該解決方案能提供高度的互操作性并且協(xié)議的實現(xiàn)容易訪問。這也是我看好 Web 服務前景的原因。廠商們紛紛開始支持包含 Web 服務組件的標準。這也許是由于時間選擇和省錢的原因，或者也許是因為因特網(wǎng)對編程模型的影響。拋開原因不談，結果是十分令人滿意的。不同于由 DCOM 和 CORBA 解決方案所造成的單一廠商的實現(xiàn)要求，廠商們一致認為，定義一個能讓應用程序實現(xiàn)互操作性的分布式計算模型是每個人的最大利益所在。

最近，IBM 為一大群 SOAP 廠商主辦了一個互操作性專題研討會。Microsoft 和 WebMethods 等公司都自愿參與，以保證它們的 SOAP 解決方案能與其他廠商的解決方案實現(xiàn)互操作。這是 90 年代 ORB 之爭的 180 度文化轉彎。這個專題研討會只是個開始。另一個由其他廠商主辦的專題研討會已經(jīng)在計劃之中。

當我們介紹開放源代碼實現(xiàn)的概念時，情況變得更好了。Web 服務組件的核心，即 HTTP、XML 和 SOAP 的實現(xiàn)可自由地通過 Apache 開放源代碼社區(qū)得到。WSDL 的免費實現(xiàn)可從 Microsoft 和 IBM 處獲得。因此一般的程序員能公開獲取必需的工具以快速開發(fā)分布式應用程序，此外，他們很放心，為這些應用程序部署的支持可以被應用程序用戶簡單、劃算地解決。

翻版

Web 服務是 CORBA 的翻版嗎？不，至少我不把 Web 服務編程模型看作是 CORBA 的再現(xiàn)或再生。我把它看作是一個全新的開放的解決方案，它解決了 CORBA 所解決的相同的分布式計算問題，同時又有更進一步的目標，那就是改進 CORBA 的一些缺陷。

Web 服務技術提供了一個全新的編程模型來利用開放因特網(wǎng)標準建立分布式應用程序。這一全新的分布式計算解決方案采用特定因特網(wǎng)技術的開放性解決了許多 CORBA 和 DCOM 的互操作性問題。特別是，Web 服務

使用 HTTP 來實現(xiàn)防火墻友好和不確定有效負載；

將 XML 作為一個編碼模式使用，它能比 DR 和 CDR 更為廣泛地被采用；

提供關于 HTTP/SOAP 服務器環(huán)境的免費的經(jīng)濟價值建議，或提供關于 ORB 框架的收費的經(jīng)濟價值建議；

使用廣泛深入的 URL 因特網(wǎng)概念來解決對象識別問題；并且提供的不只是互操作性的承諾。廠商們正積極工作以證明它們的 SOAP 實現(xiàn)確有互操作性。

Web 服務是不是一個更好的 RPC？我想是的，但只有時間能夠證明一切。

參考資料

• 可通過點擊文章頂部或者底部的討論，加入這篇文章的討論論壇。
  
• 請閱讀我這一系列中的 第 1 篇和 第 2 篇專欄文章。
  
• 請閱讀 Web Services Conceptual Architecture 以獲得 Web 服務的概述。
  
• 請查閱關于動態(tài)電子商務的 realworld adoption scenarios。
  
• 請回顧簡單對象訪問協(xié)議。
  
• 請閱讀 Web 服務描述語言。
  
• 請訪問對象管理組的站點以了解更多關于 CORBA 的信息。
  
• 學習如何將 CORBA ORB 與 WebSphere Application Server 集成起來。
  
• WebSphere Application Server 支持 CORBA、Web 服務以及 J2EE。
  
• 請訪問主頁，了解更多有關通用描述、發(fā)現(xiàn)和集成方面的信息。
  
• 了解誰是 XML 協(xié)議工作組的成員。
  
• 更多 dW Web 服務參考資料。

關于作者

作為在 IBM 工作了 13 年的老員工，Dan Gisolfi 擁有 Polytechnic 大學的人工智能碩士學位和 Manhanttanville 大學計算機科學的學士學位。1999 年以前，他致力于從專家系統(tǒng)、OS/2 到網(wǎng)絡安全付費系統(tǒng)的軟件和產(chǎn)品開發(fā)。作為 jStart（jump-Start）新興技術組的一員，他既從事商業(yè)活動，又從事客戶約定的技術方面工作。從商業(yè)開發(fā)經(jīng)理和宣傳者到解決方案的設計師和合同的談判代表，他有很多頭銜。作為 jStart 的 Web 服務方面的領導，他幫助 IBM 通過真實的商業(yè)解決方案，加速采用這一新興技術?？赏ㄟ^ gisolfi@us.ibm.com 和他聯(lián)系。

瀏覽：Web服務設計師，第1部分

Web服務設計師，第2部分

Web服務設計師，第4部分

Web服務設計師，第5部分

Web服務設計師，第6部分