Java與CORBA技術結合的前景展望
阿新 • • 發佈：2019-01-18
隨著Internet、Intranet及Extranet在全球範圍內的普及和發展，下一代的Web必須能夠處理企業－企業（business-to- business）交易和客戶－企業（consumer-to-business）多步驟交易過程中的複雜需求。為了實現這一目的，Web必須發展成為一種能夠執行線上交易軟體的一種成熟的客戶機/伺服器結構。現在的HTTP/CGI結構存在一些不足，它不能滿足上述這些新的要求。而各種不同的CGI擴充套件規範，例如cookie、Microsoft Internet Services API（ISAPI）、Netscape Server API（NSAPI）以及Active Server page等，也都不能從根本上解決問題。為了能夠滿足不斷髮展的電子商務的要求，Web需要有分散式物件的功能。這就導致了人們所稱的下一波的 Internet革命──物件化的Web（Object Web）有產生。
建立Object Web的一種可行的方法，是使用COBRA（通用物件請求代理結構， Common Object Request Broker Architecture）和Java。如果沒有Object Web的話，對大多數對企業級的客戶機/伺服器市場有興趣的廠商，以及喜歡面向物件程式設計的人而言，CORBA及Java將只不過是一種容易使用的技術而已。因此業界都希望能將COBRA和Java各自的功能結合起來形成一種新的Object Web環境。軟體界中除了Microsoft以外幾乎所有其它的廠商所組成的聯盟都力促COBRA和Java的結合以建立一個通用的Object Web環境。而Microsoft目前也正要據它的ActiveX/DCOM技術建立自己的Object Web環境。本文首先將分別對CORBA和Java進行介紹，接下來將會詳述CORBA/Java以及Object Web的各種細節。
首先，那些Java的擁護者必須清楚，CORBA不止是一種物件請求代理（ORB），它同時也是一個非常完整的分散式物件操作平臺。CORBA能跨越網路、程式語言、元件界限以及作業系統，因此能夠大大擴充套件Java應用軟體的使用範圍。
對於那些CORBA的支持者，我們必須要指出的Java也不光只是一套能和CORBA結合的程式語言。Java不僅是一種面向物件的語言，同時也是具備物件功能的可移植性作業系統。Java允許CORBA物件在各種不同的機器上執行，無論是大型機、網路電腦（NC），甚至是蜂窩式電話等。Java簡化了大型CORBA系統的程式分發──Java利用位元組碼使得使用者開發的物件能到處執行，這同時也為CORBA行動式代理提供了一個切實可行的方案。現在人們都知道Java幾乎是開發客戶機/伺服器CORBA物件的最理想的語言。它內建的多執行緒（multithreading）、垃圾收集（garbage collection）及錯誤管理（error management）功能，使人們可以很容易開發出可靠的面向物件的應用。
這個方案成功的關鍵在於這兩種技術的基礎結構能夠彼此互補。Java彌補了CORBA的一些不足，而CORBA則可以為Java帶來可移植的面向物件的軟體環境。
Java和COBRA如何結合
對於如何將COBRA技術和Java技術結合起來，業界並目前沒有一個統一的標準。這主要是因為推動COBRA發展的物件管理集團（OMG，Object Management Group）及推動Java發展的JavaSoft之間無法很清楚地劃清界線。舉個例子來說，當JavaSoft為不同的Java客戶端之間，通過虛擬機器（VM）的方式建立遠端方法革新（Remote Method Invocation，RMI）時，它就已經在許多方面向OMG看齊了。以制定分散式物件標準為己任的OMG當然希望COBRA能成為Java的分散式物件模型，而JavaSoft則希望建立自己的分散式物件模型，但它又遲遲提不出自己的不同於COBRA的物件結構。
不過據稱這場分岐可能很快就要結束了。JavaSoft將採納CORBA做為分散式的物件模型這個模型在OMG的幫助之下，將能夠在CORBA/IIOP（Internet Interoperable ORB Protocol）上執行RMI API。今年六月所釋出的這個訊息，已經對消除CORBA及Java兩個陣營之間的分岐起到了明顯的效果。接下來我們介紹JavaSoft計劃如何將CORBA加入Java的核心中。
Java開發包（Java Development Kit；JDK）1.2版（97年第三季推出），包含一組純粹由Java所發展的CORBA ORB。這組ORB將是Joe的一小部分，全部以Java開發的ORB將會包含在Sun的NEO這項產品中。此外，JDK 1.2版將會支援Java IDL（Java介面定義語言，Java Interface Definition Language），Java IDL是一套能從IDL中產生出CORBA識別標籤及程式框架的開發環境。JDK 1.2版同時也將包含一組完全用Java所開發的CORBA命名服務（Naming Service）。Java RMI將執行在CORBA/IIOP結構上。這意味著JavaSoft將放棄目前所建立的專有ORB結構。
將來的JDK將會支援Enterprise JavaBeans功能。Enterprise Beans將利用CORBA/IIOP以及其它的一些協議來與客戶端的Beans進行通訊。最重要的是， Enterprise JavaBeans將會支援Java交易服務（Java Transaction Service；JTS）功能，這個功能將建立在CORBA的物件交易服務（Object Transaction Service；OTS）的基礎上。
先前宣佈的這些訊息，對於低端以及高階的CORBA/Java市場有著非常深遠的影響。在低端的市場方面，使用者不僅可以從JDK提供廠商（即使是Microsoft也有可能）獲得免費的CORBA/Java ORB，同時還可取得IDL開發環境。在高階的市場方面，使用者將能取得具備交易功能的JavaBeans。交易功能為Beans帶來ACID四種保護功能，
亦即不可分割性（Atomic）、一致性（Consistent）、隔離性（Isolated）以及永續性（Durable）。這個功能同時具有連線元件的功能，使用者可利用這個功能使各個廠商所開發的Beans達到同步化。因為上述的各種原因，OMG和JavaSoft才有可能求同存異，實現COBRA與Java的順利結合。
說了半天，讀者可能要問，CORBA/Java ORB到底是什麼呢？它實際上是為了具備可移植性而完全由Java所開發的CORBA/IIOP ORB。這個ORB必須要能夠從CORBA IDL產生出能和Java語言相連結的元件。除此之外，由這個IDL編譯器所產生的程式程式碼，必須完全由Java語言所組成，使用者只要下載這些程式碼後，就能在任何具備Java執行環境的機器上執行。
現在已經有三家公司推出了符合這些條件的ORB，它們分別是Sun的Joe、Iona的OrbixWeb以及Visigenic/Netscape的VisiBroker for Java。這三個ORB都得到了許多廠商的強力支援。Joe將會包含在JDK 1.2版中。OrbixWeb是ORB開發廠商的龍頭老大Iona所推出的產品。VisiBroker for Java這套產品目前不但隨著Netscape Communicator及Enterprise Server一起推出，而且也即將附加在Oracle的asp.cn/ class=wordstyle>網路計算結構（Network Computing Architecture，NCA）、Sybase的Jaguar，以及Novell的InternetWare等三項產品中。除了這些純粹由Java所發展的ORB之外，許多由C++所開發出來的ORB現在也提供了與Java的結合能力，例如Expersoft的PowerBroker、IBM的Component Broker及BEA即將推出的ObjectBroker等就是這樣的產品。
Web功能難以割捨
Web起初只是一個用來出版及廣播靜態電子檔案的一個媒體。w就基本功能而言，它只不過是一個以存放URL檔案為主的巨型檔案伺服器。到了1995年後期，隨著三層客戶機/伺服器CGI結構的推出，它才開始具備一些基本的互動操作功能。CGI目前已經應用在各種伺服器環境中。
CGI的HTTP結構使用起來不僅效率很低而且無法認證，同時它也不適用於開發目前流行的客戶機/伺服器應用程式。對具備面對對功能的Java客戶端程式來講， CGI並不是一種很合適的選擇。為了打破HTTP/CGI的這些限制，Web伺服器的開發廠商在這方面下了很大的功夫。廠商所研究出來的解決方案，通常是以他們專用的伺服器擴充套件功能及新的API的方式表現出來的，如NSAPI、ISAPI、Next的WebObject以及WinCGI等。
為了解決HTTP無法認證的問題，部分擴充套件規範要求客戶端瀏覽器通過cookie（存在客戶端的一些伺服器資訊）技術來實現認證的要求。其他的規範則更進一步的利用伺服器端交易物件的特性來擴充cookie的功能，並且使用交易物件來代表使用者。然而這些嘗試大部分都只符合特定的結構，而且還存在很嚴重的缺陷。
此外，CGI的執行速度很慢。每當接到一個新的客戶端請求時，CGI都會產生一個新的執行過程來滿意這個請求。為了解決這個不足，許多廠商提出的擴充套件規範都提供了常駐記憶體的工作模式，例如DLL方式的執行程式（In-process DLL）、伺服器plug-in、甚至是以ORB為基礎的物件等。一般而言，為了有效的處理客戶端的請求，伺服器端會不計一切代價的將這個服務程式保留在記憶體中。但這樣又會帶來擴充套件規範標準不統一（或要求特殊操作平臺）的問題。
上面這些建議最主要的問題在於他們需要通過HTTP及Web伺服器來調節客戶端及伺服器上所執行的物件。在客戶端上的物件不能直接使用伺服器上的物件。我們知道，使用HTTP表格只不過是客戶機/伺服器互動操作最基本的一個要求。但這種笨拙的操作模式並不適用於成熟的客戶機/伺服器應用軟體，因為這些軟體中的元件要求具有很強的互動操作性。此外，這種操作模式也沒有彈性。
到了1996年，Web終於開始具有了物件功能。Java applet是邁向開發客戶機/伺服器結構Object Web的第一步。在發展Object Web的過程上，雖然Java是必要可少的部分但但光有Java卻還是不夠的。Java需要具有分散式的基礎設施才能變得更完整，而CORBA則剛好能彌補Java的這個不足。
1997年６月，隨著CORBA/Java ORB與Netscape Communicator一起面世，但意味著Object Web真正的誕生了。在Web伺服器軟體方面，每一套Netscape Enterprise Server 3.0版都同時包含有CORBA/C++及CORBA/Java這兩種ORB一起出售。Java及CORBA互動操作的物件技術，是Object Web發展的第一個步驟。
Object Web中的互動操作
在Object Web結構中，以Web為基礎的客戶端及伺服器間的互動操作關係變得十分的簡單∶
１、Web瀏覽器下載用HTML編寫的網頁檔案。在這種要求下，這個檔案中將同時包含與Java applet的連結。
２、Web瀏覽器從HTTP伺服器中下載Java applet。HTTP伺服器取得這些applet，並以位元組碼的型式將applet傳送給瀏覽器。
３、Web瀏覽器載入applet。這些applet必須先通過Java的安全檢查，才會下載到本地硬碟上。
４、Applet對CORBA伺服器提出物件服務請求。Java applet中可以包含由IDL所產生的客戶端識別標籤，利用這個識別標籤，applet就可以對CORBA伺服器上的物件提出服務請求。Java applet以及CORBA物件之間的通訊連線可以持續存在，直到任何一方決定中斷連線。需注意的是要達到這項功能，使用者必須使用具備IIOP功能的防火牆（firewall）裝置。目前，由Iona所推出的WonderWall是唯一符合這一要求的產品。不久Netscape也很有可能將推出IIOP防火牆裝置。
５、伺服器上的物件能夠選擇性地為使用者產生下一頁的HTML檔案。當伺服器準備好下一頁檔案後，它會通知客戶端瀏覽器到特定的URL位址去下載這一頁檔案。
從Object Web結構來看，伺服器通常不需要具備動態產生網頁的功能。要在客戶端上執行的軟體會以單一HTML網頁、內含象applet（或是Object標籤中的JavaBeans）元件的方式封裝起來。與HTTP/CGI結構相比，CORBA讓使用者能快速地與伺服器實現並互操作的效果，使用者只需用滑鼠單擊HTML檔案的元件，而不需要再切換到不同的網頁就能獲得實現互動操作的目的。
CORBA/Java擴充套件Web結構
利用CORBA/Java來擴充套件Web基本結構可立即看到下面兩個好處∶
１、CORBA避開了CGI的瓶頸困境。CORBA允許客戶端程式直接呼叫伺服器上的物件方法。客戶端程式利用事先編譯過的識別標籤，直接將執行時所需要的引數傳送給伺服器，或是利用伺服器上的CORBA動態請求服務程式，立即產生所需的引數。無論是那一種方式，伺服器都會利用事先編譯好的框架程式，直接接收客戶端的服務請求。使用者可以呼叫伺服器上任何一組由IDL定義出來的物件程式，而不光只是HTTP定義的服務程式。此外，使用者還可以傳遞任何形式的引數類別，而不再只侷限於字串型的引數。這說明這種結構對客戶機/伺服器環境的負載會很小，尤其是和原來HTTP/CGI的結構相比效果更為明顯。
２、CORBA提供了一種伸縮性很強的伺服器與伺服器之間進行通訊的結構。每個伺服器上的通訊物件都可以利用CORBA ORB來相互通訊。這些物件可以同時在多個伺服器上執行，以便使來自客戶端的各種服務請求能達到負載平衡。ORB會將服務請求分配給第一個可用的物件，同時會隨著請求的增加而增加新的物件。通過對通訊進行限制和相關的CORBA服務程式，CORBA允許伺服器上的物件能以一致的行為來執行。而CGI應用程式會造成系統功能的瓶頸，因為它必須處理成千上萬的服務需求。CGI不能將這些負載分散到不同的處理程式或是不同的處理器上執行。
三層式CORBA/Java Object Web
Object Web上每個新的應用程式，都將設計或封裝成元件的型式。使用者可以在CORBA IDL中利用物件的介面來封裝現有的程式程式碼。幾乎每一種程式語言所編寫出來的程式程式碼都能重新封裝。舉例來說，利用CORBA，使用者可以像變魔術一樣的使一百多萬行COBOL程式看起來像是一個物件。任何由IDL所建立的物件，都能夠以初始類別（first class）的方式運用在Object Web中。這種方法之所以能成功，是因為CORBA同Java一樣，將物件的介面和物件的執行分得很清楚。
一些主要的asp.cn/ class=wordstyle>電腦公司，包括Sun、IBM/Lotus、Netscape、Oracle、Sybase、Novell以及BEA等，都非常看好Object Web這個重量級的應用軟體。這些公司同時選擇CORBA/IIOP及JavaBeans作為與公司其它產品之間立即可使用的高階軟體溝通方案。下面我們通過三層式結構（three-tier）的客戶機/伺服器結構來詳細介紹一下Object Web。
◆客戶端（client）
結構中的第一層是由傳統的Web瀏覽器及全新以Web為中心的桌面環境構成。相對於如今靜態的網頁而言，這些新物件將更能代表真實世界事物的樣子。舉例來說，使用者將可以看到物件容器中包含有人、物體以及其它的物件容器。這個動態的網頁內容，是由裝載著可移動式物件容器的行動式容器軟體內嵌的JavaBeans執行所產生的整體效果，像HTML網頁或Jars等都可以算是行動式的容器軟體。使用者可以利用拖拉的動作或直接操作表格的方法來與這些物件達到互動操作的效果。位於客戶端的Beans不僅可以和容器軟體中其它客戶端的Beans互動操作，同時也能和伺服器上的Beans互動操作。
此外，利用CORBA的事件或回叫（callback）模式，伺服器上的Beans將可以直接呼叫客戶端的物件程式。瀏覽器可以利用HTTP協議來下載Web網頁、Jars以及圖象檔案等，而使用CORBA作為Java客戶端到伺服器，以及伺服器到客戶端的傳輸協議。
◆中間層（middle tier）
結構中的中間層執行在每個伺服器上，其主要的功能是為HTTP及CORBA客戶端提供服務。幾乎每種操作平臺上的伺服器都支援CORBA/HTTP這兩種組合功能，如Unix、NT、OS/2、NetWare、MacOS、OS/400、MVS及Tandem NonStop Kernel等
CORBA物件將商業原則（business logic）封裝到物件中，並在這個結構中起著中間介面應用程式伺服器的作用，這些CORBA物件最後很有可能被封裝成Enterprise JavaBeans。這些物件利用CORBA/IIOP與客戶端的JavaBeans進行互動操作。一些可伸縮性差一些的軟體，也可以利用HTML伺服器網頁上的script功能來呼叫這些物件。舉例來說，Netscape的Web應用介面（Web Application Interface，WAI）就可以對應用軟體提供這種服務。
伺服器上的CORBA物件會利用CORBA ORB來與其他伺服器上的物件進行互動操作。這些物件也可以利用SQL/JDBC（Java資料庫互連）或其它中介軟體（Middleware）來與第三層結構中現有的伺服器應用軟體通訊。使用者甚至還可以使用CORBA/IIOP伺服器主幹來作為普通資料的傳送通道。這就是Oracle用來建立資料Plug-in的技術。
現在I-Kinetics及Visigenic這兩家公司，也推出了能將JDBC運用在IIOP上的資料傳輸軟體。
中間層的這個結構同時也必須提供伺服器端“元件協調者（component coordinator）”的功能，這項功能也稱為物件的TP糾察員（TP monitor）。這些元件協調者實際上是建立在ORB上的TP monitor。這些元件協調者不是用來管理遠端的程式，而是用來管理物件。元件協調者會預先改變物件的共同成員、平衡物件的負載、提供容錯的能力，並且協調多個元件之間的通訊行為。如果沒有元件協調者的話，根本無法管理伺服器中成千上萬的物件，而這項管理的功能卻又是Object Web所需具備的能力。
在以CORBA為基礎的元件協調者中，比較有名的是IBM的Component Broker及BEA的Tuxedo/Iceberg。伺服器端的元件是是一種包含一小部分元件服務功能CORBA伺服器物件。Oracle的 Cartridge可算是這種元件中最具代表性的例子。Cartridge是著名的CORBA物件，它同時具有通訊功能和保密功能，而且還能激發特定的事件。
使用者可以對伺服器端的元件進行視覺化裝配。這說明只要通過元件本身所提供的連結介面，使用者就能利用可覺化工具軟體將這些元件整合在一起。將來CORBA化的Enterprise JavaBeans中將提供伺服器端元件的視覺化裝配功能。CORBA/JavaBean的這項技術已經整合到由Symantec、Penumbra、ParcPlace、IBM/Taligent、Borland及Sybase等公司所推出的視覺化開發工具中。
在CORBA/Java Object Web結構中的第二層，還必須具備能夠儲存元件名稱、HTML網頁及行動式物件容器的能力。這些物件可以儲存在行動式的Java Jars中，並且通過面向物件的資料庫管理系統（ODBMS）或傳統的資料庫管理系統（DBMS）來進行管理，不過使用面向物件的資料庫管理系統要更合適一些。
◆後端伺服器（back end）
任何一種CORBA物件能夠訪問的資源，都可以算是此結構第三層的一部分。這包括程式性的TP monitor、中介軟體（middleware）、資料庫管理系統、面向物件的資料庫管理系統、Lotus Notes和電子郵件等。這樣一來，利用CORBA物件來取代中間層中的CGI程式才能收到良好的效果。最後使用者將可以取得封裝大部分三層功能的CORBA/Java元件，這樣就可以充分發揮CORBA的作用了。
結束語
CORBA和Java為Object Web上各種產品的整合起著沾合劑的作用。這是軟體工業界中第一個嘗試即插即用（plug-and-play）功能的軟體，而這個功能則是開放系統最終希望實現的。
在其他廠商發展Object Web的同時，軟體業的大腕Microsoft也不會甘於寂寞，它正努力的以自己的方式來詮釋並試圖主導Object Web的發展方向，而它所用的方法則是DCOM及ActiveX。Microsoft的Transaction Server（代號Viper）是一套DCOM元件協調軟體，它是Microsoft計劃用來統治Object Web的祕密武器。不過目前看來，Microsoft的Web環境還遠不夠成熟。相信隨著Microsoft的Web環境的進一步發展，未來Object Web領域的競爭將會日趨激烈。
建立Object Web的一種可行的方法，是使用COBRA（通用物件請求代理結構， Common Object Request Broker Architecture）和Java。如果沒有Object Web的話，對大多數對企業級的客戶機/伺服器市場有興趣的廠商，以及喜歡面向物件程式設計的人而言，CORBA及Java將只不過是一種容易使用的技術而已。因此業界都希望能將COBRA和Java各自的功能結合起來形成一種新的Object Web環境。軟體界中除了Microsoft以外幾乎所有其它的廠商所組成的聯盟都力促COBRA和Java的結合以建立一個通用的Object Web環境。而Microsoft目前也正要據它的ActiveX/DCOM技術建立自己的Object Web環境。本文首先將分別對CORBA和Java進行介紹，接下來將會詳述CORBA/Java以及Object Web的各種細節。
首先，那些Java的擁護者必須清楚，CORBA不止是一種物件請求代理（ORB），它同時也是一個非常完整的分散式物件操作平臺。CORBA能跨越網路、程式語言、元件界限以及作業系統，因此能夠大大擴充套件Java應用軟體的使用範圍。
對於那些CORBA的支持者，我們必須要指出的Java也不光只是一套能和CORBA結合的程式語言。Java不僅是一種面向物件的語言，同時也是具備物件功能的可移植性作業系統。Java允許CORBA物件在各種不同的機器上執行，無論是大型機、網路電腦（NC），甚至是蜂窩式電話等。Java簡化了大型CORBA系統的程式分發──Java利用位元組碼使得使用者開發的物件能到處執行，這同時也為CORBA行動式代理提供了一個切實可行的方案。現在人們都知道Java幾乎是開發客戶機/伺服器CORBA物件的最理想的語言。它內建的多執行緒（multithreading）、垃圾收集（garbage collection）及錯誤管理（error management）功能，使人們可以很容易開發出可靠的面向物件的應用。
這個方案成功的關鍵在於這兩種技術的基礎結構能夠彼此互補。Java彌補了CORBA的一些不足，而CORBA則可以為Java帶來可移植的面向物件的軟體環境。
Java和COBRA如何結合
對於如何將COBRA技術和Java技術結合起來，業界並目前沒有一個統一的標準。這主要是因為推動COBRA發展的物件管理集團（OMG，Object Management Group）及推動Java發展的JavaSoft之間無法很清楚地劃清界線。舉個例子來說，當JavaSoft為不同的Java客戶端之間，通過虛擬機器（VM）的方式建立遠端方法革新（Remote Method Invocation，RMI）時，它就已經在許多方面向OMG看齊了。以制定分散式物件標準為己任的OMG當然希望COBRA能成為Java的分散式物件模型，而JavaSoft則希望建立自己的分散式物件模型，但它又遲遲提不出自己的不同於COBRA的物件結構。
不過據稱這場分岐可能很快就要結束了。JavaSoft將採納CORBA做為分散式的物件模型這個模型在OMG的幫助之下，將能夠在CORBA/IIOP（Internet Interoperable ORB Protocol）上執行RMI API。今年六月所釋出的這個訊息，已經對消除CORBA及Java兩個陣營之間的分岐起到了明顯的效果。接下來我們介紹JavaSoft計劃如何將CORBA加入Java的核心中。
Java開發包（Java Development Kit；JDK）1.2版（97年第三季推出），包含一組純粹由Java所發展的CORBA ORB。這組ORB將是Joe的一小部分，全部以Java開發的ORB將會包含在Sun的NEO這項產品中。此外，JDK 1.2版將會支援Java IDL（Java介面定義語言，Java Interface Definition Language），Java IDL是一套能從IDL中產生出CORBA識別標籤及程式框架的開發環境。JDK 1.2版同時也將包含一組完全用Java所開發的CORBA命名服務（Naming Service）。Java RMI將執行在CORBA/IIOP結構上。這意味著JavaSoft將放棄目前所建立的專有ORB結構。
將來的JDK將會支援Enterprise JavaBeans功能。Enterprise Beans將利用CORBA/IIOP以及其它的一些協議來與客戶端的Beans進行通訊。最重要的是， Enterprise JavaBeans將會支援Java交易服務（Java Transaction Service；JTS）功能，這個功能將建立在CORBA的物件交易服務（Object Transaction Service；OTS）的基礎上。
先前宣佈的這些訊息，對於低端以及高階的CORBA/Java市場有著非常深遠的影響。在低端的市場方面，使用者不僅可以從JDK提供廠商（即使是Microsoft也有可能）獲得免費的CORBA/Java ORB，同時還可取得IDL開發環境。在高階的市場方面，使用者將能取得具備交易功能的JavaBeans。交易功能為Beans帶來ACID四種保護功能，
亦即不可分割性（Atomic）、一致性（Consistent）、隔離性（Isolated）以及永續性（Durable）。這個功能同時具有連線元件的功能，使用者可利用這個功能使各個廠商所開發的Beans達到同步化。因為上述的各種原因，OMG和JavaSoft才有可能求同存異，實現COBRA與Java的順利結合。
說了半天，讀者可能要問，CORBA/Java ORB到底是什麼呢？它實際上是為了具備可移植性而完全由Java所開發的CORBA/IIOP ORB。這個ORB必須要能夠從CORBA IDL產生出能和Java語言相連結的元件。除此之外，由這個IDL編譯器所產生的程式程式碼，必須完全由Java語言所組成，使用者只要下載這些程式碼後，就能在任何具備Java執行環境的機器上執行。
現在已經有三家公司推出了符合這些條件的ORB，它們分別是Sun的Joe、Iona的OrbixWeb以及Visigenic/Netscape的VisiBroker for Java。這三個ORB都得到了許多廠商的強力支援。Joe將會包含在JDK 1.2版中。OrbixWeb是ORB開發廠商的龍頭老大Iona所推出的產品。VisiBroker for Java這套產品目前不但隨著Netscape Communicator及Enterprise Server一起推出，而且也即將附加在Oracle的asp.cn/ class=wordstyle>網路計算結構（Network Computing Architecture，NCA）、Sybase的Jaguar，以及Novell的InternetWare等三項產品中。除了這些純粹由Java所發展的ORB之外，許多由C++所開發出來的ORB現在也提供了與Java的結合能力，例如Expersoft的PowerBroker、IBM的Component Broker及BEA即將推出的ObjectBroker等就是這樣的產品。
Web功能難以割捨
Web起初只是一個用來出版及廣播靜態電子檔案的一個媒體。w就基本功能而言，它只不過是一個以存放URL檔案為主的巨型檔案伺服器。到了1995年後期，隨著三層客戶機/伺服器CGI結構的推出，它才開始具備一些基本的互動操作功能。CGI目前已經應用在各種伺服器環境中。
CGI的HTTP結構使用起來不僅效率很低而且無法認證，同時它也不適用於開發目前流行的客戶機/伺服器應用程式。對具備面對對功能的Java客戶端程式來講， CGI並不是一種很合適的選擇。為了打破HTTP/CGI的這些限制，Web伺服器的開發廠商在這方面下了很大的功夫。廠商所研究出來的解決方案，通常是以他們專用的伺服器擴充套件功能及新的API的方式表現出來的，如NSAPI、ISAPI、Next的WebObject以及WinCGI等。
為了解決HTTP無法認證的問題，部分擴充套件規範要求客戶端瀏覽器通過cookie（存在客戶端的一些伺服器資訊）技術來實現認證的要求。其他的規範則更進一步的利用伺服器端交易物件的特性來擴充cookie的功能，並且使用交易物件來代表使用者。然而這些嘗試大部分都只符合特定的結構，而且還存在很嚴重的缺陷。
此外，CGI的執行速度很慢。每當接到一個新的客戶端請求時，CGI都會產生一個新的執行過程來滿意這個請求。為了解決這個不足，許多廠商提出的擴充套件規範都提供了常駐記憶體的工作模式，例如DLL方式的執行程式（In-process DLL）、伺服器plug-in、甚至是以ORB為基礎的物件等。一般而言，為了有效的處理客戶端的請求，伺服器端會不計一切代價的將這個服務程式保留在記憶體中。但這樣又會帶來擴充套件規範標準不統一（或要求特殊操作平臺）的問題。
上面這些建議最主要的問題在於他們需要通過HTTP及Web伺服器來調節客戶端及伺服器上所執行的物件。在客戶端上的物件不能直接使用伺服器上的物件。我們知道，使用HTTP表格只不過是客戶機/伺服器互動操作最基本的一個要求。但這種笨拙的操作模式並不適用於成熟的客戶機/伺服器應用軟體，因為這些軟體中的元件要求具有很強的互動操作性。此外，這種操作模式也沒有彈性。
到了1996年，Web終於開始具有了物件功能。Java applet是邁向開發客戶機/伺服器結構Object Web的第一步。在發展Object Web的過程上，雖然Java是必要可少的部分但但光有Java卻還是不夠的。Java需要具有分散式的基礎設施才能變得更完整，而CORBA則剛好能彌補Java的這個不足。
1997年６月，隨著CORBA/Java ORB與Netscape Communicator一起面世，但意味著Object Web真正的誕生了。在Web伺服器軟體方面，每一套Netscape Enterprise Server 3.0版都同時包含有CORBA/C++及CORBA/Java這兩種ORB一起出售。Java及CORBA互動操作的物件技術，是Object Web發展的第一個步驟。
Object Web中的互動操作
在Object Web結構中，以Web為基礎的客戶端及伺服器間的互動操作關係變得十分的簡單∶
１、Web瀏覽器下載用HTML編寫的網頁檔案。在這種要求下，這個檔案中將同時包含與Java applet的連結。
２、Web瀏覽器從HTTP伺服器中下載Java applet。HTTP伺服器取得這些applet，並以位元組碼的型式將applet傳送給瀏覽器。
３、Web瀏覽器載入applet。這些applet必須先通過Java的安全檢查，才會下載到本地硬碟上。
４、Applet對CORBA伺服器提出物件服務請求。Java applet中可以包含由IDL所產生的客戶端識別標籤，利用這個識別標籤，applet就可以對CORBA伺服器上的物件提出服務請求。Java applet以及CORBA物件之間的通訊連線可以持續存在，直到任何一方決定中斷連線。需注意的是要達到這項功能，使用者必須使用具備IIOP功能的防火牆（firewall）裝置。目前，由Iona所推出的WonderWall是唯一符合這一要求的產品。不久Netscape也很有可能將推出IIOP防火牆裝置。
５、伺服器上的物件能夠選擇性地為使用者產生下一頁的HTML檔案。當伺服器準備好下一頁檔案後，它會通知客戶端瀏覽器到特定的URL位址去下載這一頁檔案。
從Object Web結構來看，伺服器通常不需要具備動態產生網頁的功能。要在客戶端上執行的軟體會以單一HTML網頁、內含象applet（或是Object標籤中的JavaBeans）元件的方式封裝起來。與HTTP/CGI結構相比，CORBA讓使用者能快速地與伺服器實現並互操作的效果，使用者只需用滑鼠單擊HTML檔案的元件，而不需要再切換到不同的網頁就能獲得實現互動操作的目的。
CORBA/Java擴充套件Web結構
利用CORBA/Java來擴充套件Web基本結構可立即看到下面兩個好處∶
１、CORBA避開了CGI的瓶頸困境。CORBA允許客戶端程式直接呼叫伺服器上的物件方法。客戶端程式利用事先編譯過的識別標籤，直接將執行時所需要的引數傳送給伺服器，或是利用伺服器上的CORBA動態請求服務程式，立即產生所需的引數。無論是那一種方式，伺服器都會利用事先編譯好的框架程式，直接接收客戶端的服務請求。使用者可以呼叫伺服器上任何一組由IDL定義出來的物件程式，而不光只是HTTP定義的服務程式。此外，使用者還可以傳遞任何形式的引數類別，而不再只侷限於字串型的引數。這說明這種結構對客戶機/伺服器環境的負載會很小，尤其是和原來HTTP/CGI的結構相比效果更為明顯。
２、CORBA提供了一種伸縮性很強的伺服器與伺服器之間進行通訊的結構。每個伺服器上的通訊物件都可以利用CORBA ORB來相互通訊。這些物件可以同時在多個伺服器上執行，以便使來自客戶端的各種服務請求能達到負載平衡。ORB會將服務請求分配給第一個可用的物件，同時會隨著請求的增加而增加新的物件。通過對通訊進行限制和相關的CORBA服務程式，CORBA允許伺服器上的物件能以一致的行為來執行。而CGI應用程式會造成系統功能的瓶頸，因為它必須處理成千上萬的服務需求。CGI不能將這些負載分散到不同的處理程式或是不同的處理器上執行。
三層式CORBA/Java Object Web
Object Web上每個新的應用程式，都將設計或封裝成元件的型式。使用者可以在CORBA IDL中利用物件的介面來封裝現有的程式程式碼。幾乎每一種程式語言所編寫出來的程式程式碼都能重新封裝。舉例來說，利用CORBA，使用者可以像變魔術一樣的使一百多萬行COBOL程式看起來像是一個物件。任何由IDL所建立的物件，都能夠以初始類別（first class）的方式運用在Object Web中。這種方法之所以能成功，是因為CORBA同Java一樣，將物件的介面和物件的執行分得很清楚。
一些主要的asp.cn/ class=wordstyle>電腦公司，包括Sun、IBM/Lotus、Netscape、Oracle、Sybase、Novell以及BEA等，都非常看好Object Web這個重量級的應用軟體。這些公司同時選擇CORBA/IIOP及JavaBeans作為與公司其它產品之間立即可使用的高階軟體溝通方案。下面我們通過三層式結構（three-tier）的客戶機/伺服器結構來詳細介紹一下Object Web。
◆客戶端（client）
結構中的第一層是由傳統的Web瀏覽器及全新以Web為中心的桌面環境構成。相對於如今靜態的網頁而言，這些新物件將更能代表真實世界事物的樣子。舉例來說，使用者將可以看到物件容器中包含有人、物體以及其它的物件容器。這個動態的網頁內容，是由裝載著可移動式物件容器的行動式容器軟體內嵌的JavaBeans執行所產生的整體效果，像HTML網頁或Jars等都可以算是行動式的容器軟體。使用者可以利用拖拉的動作或直接操作表格的方法來與這些物件達到互動操作的效果。位於客戶端的Beans不僅可以和容器軟體中其它客戶端的Beans互動操作，同時也能和伺服器上的Beans互動操作。
此外，利用CORBA的事件或回叫（callback）模式，伺服器上的Beans將可以直接呼叫客戶端的物件程式。瀏覽器可以利用HTTP協議來下載Web網頁、Jars以及圖象檔案等，而使用CORBA作為Java客戶端到伺服器，以及伺服器到客戶端的傳輸協議。
◆中間層（middle tier）
結構中的中間層執行在每個伺服器上，其主要的功能是為HTTP及CORBA客戶端提供服務。幾乎每種操作平臺上的伺服器都支援CORBA/HTTP這兩種組合功能，如Unix、NT、OS/2、NetWare、MacOS、OS/400、MVS及Tandem NonStop Kernel等
CORBA物件將商業原則（business logic）封裝到物件中，並在這個結構中起著中間介面應用程式伺服器的作用，這些CORBA物件最後很有可能被封裝成Enterprise JavaBeans。這些物件利用CORBA/IIOP與客戶端的JavaBeans進行互動操作。一些可伸縮性差一些的軟體，也可以利用HTML伺服器網頁上的script功能來呼叫這些物件。舉例來說，Netscape的Web應用介面（Web Application Interface，WAI）就可以對應用軟體提供這種服務。
伺服器上的CORBA物件會利用CORBA ORB來與其他伺服器上的物件進行互動操作。這些物件也可以利用SQL/JDBC（Java資料庫互連）或其它中介軟體（Middleware）來與第三層結構中現有的伺服器應用軟體通訊。使用者甚至還可以使用CORBA/IIOP伺服器主幹來作為普通資料的傳送通道。這就是Oracle用來建立資料Plug-in的技術。
現在I-Kinetics及Visigenic這兩家公司，也推出了能將JDBC運用在IIOP上的資料傳輸軟體。
中間層的這個結構同時也必須提供伺服器端“元件協調者（component coordinator）”的功能，這項功能也稱為物件的TP糾察員（TP monitor）。這些元件協調者實際上是建立在ORB上的TP monitor。這些元件協調者不是用來管理遠端的程式，而是用來管理物件。元件協調者會預先改變物件的共同成員、平衡物件的負載、提供容錯的能力，並且協調多個元件之間的通訊行為。如果沒有元件協調者的話，根本無法管理伺服器中成千上萬的物件，而這項管理的功能卻又是Object Web所需具備的能力。
在以CORBA為基礎的元件協調者中，比較有名的是IBM的Component Broker及BEA的Tuxedo/Iceberg。伺服器端的元件是是一種包含一小部分元件服務功能CORBA伺服器物件。Oracle的 Cartridge可算是這種元件中最具代表性的例子。Cartridge是著名的CORBA物件，它同時具有通訊功能和保密功能，而且還能激發特定的事件。
使用者可以對伺服器端的元件進行視覺化裝配。這說明只要通過元件本身所提供的連結介面，使用者就能利用可覺化工具軟體將這些元件整合在一起。將來CORBA化的Enterprise JavaBeans中將提供伺服器端元件的視覺化裝配功能。CORBA/JavaBean的這項技術已經整合到由Symantec、Penumbra、ParcPlace、IBM/Taligent、Borland及Sybase等公司所推出的視覺化開發工具中。
在CORBA/Java Object Web結構中的第二層，還必須具備能夠儲存元件名稱、HTML網頁及行動式物件容器的能力。這些物件可以儲存在行動式的Java Jars中，並且通過面向物件的資料庫管理系統（ODBMS）或傳統的資料庫管理系統（DBMS）來進行管理，不過使用面向物件的資料庫管理系統要更合適一些。
◆後端伺服器（back end）
任何一種CORBA物件能夠訪問的資源，都可以算是此結構第三層的一部分。這包括程式性的TP monitor、中介軟體（middleware）、資料庫管理系統、面向物件的資料庫管理系統、Lotus Notes和電子郵件等。這樣一來，利用CORBA物件來取代中間層中的CGI程式才能收到良好的效果。最後使用者將可以取得封裝大部分三層功能的CORBA/Java元件，這樣就可以充分發揮CORBA的作用了。
結束語
CORBA和Java為Object Web上各種產品的整合起著沾合劑的作用。這是軟體工業界中第一個嘗試即插即用（plug-and-play）功能的軟體，而這個功能則是開放系統最終希望實現的。
在其他廠商發展Object Web的同時，軟體業的大腕Microsoft也不會甘於寂寞，它正努力的以自己的方式來詮釋並試圖主導Object Web的發展方向，而它所用的方法則是DCOM及ActiveX。Microsoft的Transaction Server（代號Viper）是一套DCOM元件協調軟體，它是Microsoft計劃用來統治Object Web的祕密武器。不過目前看來，Microsoft的Web環境還遠不夠成熟。相信隨著Microsoft的Web環境的進一步發展，未來Object Web領域的競爭將會日趨激烈。