Janeva概述
在軟體界具有領袖地位的幾家大公司，每一家都有自己鮮明的技術特色。Microsoft 背靠作業系統，Oracle 以資料庫為中心，SUN 靠小型機稱雄，IBM 則以“四海一家的解決之道”為號召。至於Borland， 在一般人的印象中自然是開發工具的專業廠商。事實上，Borland 雖然以開發工具起家，但近年來已經逐漸轉變為一家提供企業級整體解決方案的廠商，其產品涉及開發工具、建模工具、資料庫、中間件、需求分析、變更管理等多個領域。在IT 業的大戰中，Borland 並不專屬於某一具體陣營，它的產品線跨越了Windows、Linux、Unix、Java、.NET 等主要平台。由於扮演了這種角色，Borland 公司在各個平台的協調工作和互相通訊的技術方面，占據了業界獨一無二的地位。經過一段時間的學習，作者慢慢熟悉了Janeva 的一些技術細節和市場定位，同時也了解了為什麼這些軟體公司對Janeva 如此感興趣。在和公司同事進行討論時， 大家也一致認為，Janeva 是一個很有技術特色、也很有市場前途的產品，可望在未來的企業級架構中扮演重要的角色。
產品特色
那么Janeva 到底是一個什麼樣的產品呢？根據Borland 公司的文檔，Janeva 的特徵是Platform Interoperability for the Enterprise， 注意兩個關鍵之處，一個是Platform Interoperability，一個是Enterprise。Janeva 提供了從.NET 平台到J2EE/Corba 平台的無縫互操作性，通過高度可擴展的、安全的Internet Inter-ORB Protocol(IIOP?)，使得基於客戶端或是伺服器的.NET 應用程式能夠訪問J2EE 和CORBA 伺服器上的組件。Janeva 以.NET 組件的形式提供，因此可以方便地嵌入到任何主流的.NET 開發環境中去，包括Microsoft Visual Studio .NET 和Borland C#Builder。Janeva 也可以被任何支持.NET 平台下的公共語言運行時（Common Language Runtime）的程式語言所使用。
在企業級市場，J2EE 正在如日中天，越來越多的大型套用都基於J2EE 的解決方案。除了以WebSphere、WebLogic 、BES 等J2EE 伺服器為基礎的核心套用以外，還衍生出了針對不同環境、不同行業的各種解決方案，可以說，J2EE 在服務端已經是根深蒂固，難以動搖。相對應地，Microsoft 則在客戶端占有絕對的優勢。特別是Microsoft 在發布.NET 架構以後，雄心勃勃地希望將.NET 架構打入企業級市場。根據分析家的預測，Java 或者.NET 一統天下的可能性都很小，在可預見的未來一段時間裡，將會出現Java 和.NET 共同瓜分套用軟體基礎平台的局面。
同類產品的比較
不可否認，Java 和.NET 都是非常優秀的Framework，而且對分散式組件技術都提供了良好的支持：Java 提供了RMI，.NET 提供了.NET Remoting 。在各自的領域內，這兩種解決方案都工作得很好。但是，如前所述，當面臨著Java 和.NET 長期共存的局面時，如何在這兩大平台之間進行互相通訊的問題就凸現出來了，因為無論是RMI 還是.NET Remoting，都不能夠連線到對方的平台。特別是大型的企業，不可避免地需要面對在異構平台之間進行集成的問題， 因此它們對這種通訊的解決方案特別關心，也就在情理之中了。異構平台通訊的解決方案
在Janeva 出現之前，出現過一些針對異構平台通訊的解決方案。其中比較著名的一種是Web Service。Web Service 可以用於訪問遠程機器上的對象，使用標準的XML 檔案作為數據封包的格式。由於它的規格簡單而且開放，並且獨立於任何平台和程式語言，因此大多數主流的平台和語言都對紛紛提供對Web Service 的支持，也包括Java 和.NET 在內。的確，通過Web Service，可以實現在Java 和.NET 之間的對象訪問。從理論上來說，通過Web Service，可以實現任何平台之間的對象訪問，只要它們提供了對Web Service 的支持。因此，有一段時間，Web Service 成為了一個非常流行的名詞。Web Service的缺陷
圖1：Janeva 解決方案示意圖但是在實踐中，人們很快就發現Web Service 並不是預想中的終極解決方案。原因是，Web Service 具有如下種種缺陷，而且這些缺陷幾乎是無法徹底克服的：
首先，Web Service 技術本身雖然比較簡單，但是為了通過Web Service 進行通訊，服務端和客戶端都必須進行額外的架構，將原有的對象進行封裝和暴露。這將需要投入額外的資源來進行編程和維護，更重要的是，涉及到對服務端的改動。而在一些關鍵性的套用中，由於對可靠性的要求極高，因此對於已經經過實際驗證能夠穩定運行的系統，進行改動帶來的風險是很大的。
其次，Web Service 技術的簡單性，一方面為開發和維護帶來了方便，但是另一方面，也帶來了對於分散式組件技術的某些高級特性支持不夠的缺陷。Web Service 對於事務處理、安全特性以及服務質量等特性的支持，一向是老大難問題，而且由於Web Service 本身的性質，在未來也難以出現理想的解決方案。很容易理解，在企業級套用的領域，對上述特性不支持或支持得不夠完善的技術，是很難有什麼前途的。
第三，Web Service 使用了標準的XML 作為數據封包的格式，雖然獲得了最好的兼容性，和簡化了開發，但是也導致了在性能上的損失。XML 的字元流和傳統的二進制流，處理的信息量可以相差一個數量級以上，再加上編碼/解碼的過程，差距就更大了。因此，在一些對性能要求苛刻的實時系統中，Web Service 基本上不被考慮。
橋接器技術
另外一種解決方案是所謂的“Bridge”，即橋接器技術。這種技術使用專門的橋接器，作為服務端和客戶端的中轉站。當客戶端向服務端傳送請求時，橋接器將請求轉換為服務端能夠理解的格式，再轉發給服務端。當服務端傳送回應時，同樣也通過橋接器中轉。很顯然，這種橋接器解決方案同樣也存在著性能上和兼容性上的問題。Janeva 的優勢
相比之下，Janeva 採用了一個獨特的技術角度切入，這使我們不得不佩服Janeva 的設計者的天才構思。Janeva 以.NET 組件的形式提供，本身是一組符合.NET 規範的assembly， 因此可以非常方便地在.NET 開發中使用，只需要導入相應的包名，就可以訪問Janeva 中的對象和方法。在Janeva 的底層，Borland 的工程師們實現了完整的IIOP 協定，通過IIOP 協定和J2EE/Corba 伺服器上的遠程對象進行互動。Janeva 的這種架構具有如下優勢：採用Janeva 的解決方案，無需對服務端進行任何改動，對客戶端的影響也降低到了最小程度。由於直接採用IIOP 通訊，服務端會認為它正在與一個J2EE/Corba 客戶端進行通訊，因此不需要額外的架構。而在客戶端，J2EE/Corba 對象會被自動映射成.NET 的本地對象的形式，只需要針對該對象編程即可。這樣，有效地保護了已有的投資和技術，避免了因為架構變動帶來的風險。圖二：在導入EJB 包以後，C#Builder 通過映射機制自動生成的cs 檔案
由於Janeva 的解決方案建立在對IIOP 的完全兼容性的基礎之上，因此它對分散式組件技術的高級特性有著良好的支持。Janeva 能夠支持雙向提交的事務處理，加密、驗證、授權等的安全特性， 以及各種複雜數據類型（自動進行Corba 和J2EE 的映射）。因此，Janeva 完全可以適應複雜的企業級套用環境。
在採用Janeva 的解決方案中，數據流是二進制流而不是XML 那樣的字元流，同時也省去了編碼/解碼的開銷，並且不需要任何橋接器進行中轉。因此，Janeva 在性能上有足夠的保證，有相關的測試數據表明，Janeva 和Web Service 的解決方案，在效率上有2~40 倍的性能差距。在對性能要求苛刻的系統中，Janeva 是當之無愧的選擇。
