讓JAVA 和 .NET架構共存

.net架構 原創作者：Ashish Banerjee

翻譯整理：51DOTNET CLUB（WWW.51DOTNET.COM）SLASH

目的：對JAVA與.NET架構共存的可能性做一個評估

目標受眾：JAVA程式員和系統工程師

  

提要：

       首先是對JAVA 和 .NET平台的構成做一個分析，然後是我個人對JAVA如何形成的一個認識，接著是分析微軟和SUN之間的合作與分歧，最後是JAVA與.NET合作的前景。

     
我個人強烈認為JAVA與.NET將在不久的未來逐步的統一起來。已經有很多關於整合JAVA和.NET的專案計劃被提交到源碼開放組織。在微軟的MSDN，SUN 的JAVA網站，以及來自於ECMA 和 W3C.org的標準文檔都可以看到有關內容。

  

簡介

     JAVA與.NET繼續發展下去，可能的兩種結果：其中的一種退出競爭或是兩種共存，而共存的可能性更大。JAVA得以生存的原因在於它的時間優勢：它已經發展了六年；它在大多數的作業系統上可以運行；它得到了業界領導者如ORACLE、IBM的支援；並且使用JAVA進行開發的專案計劃幾乎覆蓋所有的應用程式領域。


     而.NET的優勢在於微軟擁有90%的案頭作業系統市場，同時微軟也開始採用SUN的市場戰略，即將其特有的技術標準化。如：在遠程通訊上它向IETF（InternetEngineering Task Force）和W3C（World Wide Web Consortium）提交了SOAP（SIMPLE OBJECT ACCESS PROTOCLE）（類似於RFC-REQUEST FORCOMMENT）；向ECMA (European Computer Manufacturer's Association)提交了C#語言和通用運行時（COMMON RUNTIME）基礎結構的標準。

  

JAVA平台的構架

      JAVA平台包括JAVA語言，以及一套虛擬機器——如JVM、KVM、CVM等——通過它們實現在PC機，手提電腦或是嵌入式系統上運行JAVA的位元組碼。同時，JAVA平台還定義了一整套覆蓋面很廣的API，它們被用來與微軟的API協調或是相互競爭。如JDBC對ODBC，JTAPI對TAPI，JDO對ADO等等。因此，簡要來說，JAVA平台包括語言，虛擬機器，以及API庫。


      由於使用虛擬機器機制，所以JAVA語言在所有的平台上只有唯一的版本，因此它使用RMI（遠程方法調用Remote Method Invocation）協議進行遠程通訊；微軟則在.NET架構中使用DCOM——正在逐步演變為SOAP（簡易物件存取通訊協定 (SOAP)）。


      SUN最初對JAVA的宣傳是“一次性代碼編寫，所有環境下運行”，但在推出了“J2EE” (Java 2 Enterprise Edition)和“J2ME” (Java 2 Micro Edition)後不得不收回了它最初的宣傳，因為“一種尺碼的鞋適合所有的腳”的解決方案並不能很好的工作。

   

.NET平台的構架

  

     .NET架構套件括C++, VB.NET (VB 7.x) 和 C# 等一系列語言；與JAVA虛擬機器類似的一套運行時環境；以及一套傾向與WINDOWS體系的API介面。其中的運行時環境可能存在於一個瀏覽器、或是一個WEB SERVER、或是在作業系統中。將來也許在SQL SERVER中也可能存在這樣的運行時環境。另外需要提及的是微軟的SOAP協議，它在繼承了DCOM的一些特性的基礎上發展起來，基於XML格式通過HTTP進行傳輸。SOAP的JAVA版本，可以在http://xml.apache.org上看到它的有關文檔。

  

發展曆程

  

JAVA最初來源於SUN的一套為機頂盒設計的語言，當時的名字是OAK，SUN將之更名，並將它放在INTERNET上作為開放源碼共用。隨著專門為網頁設計的JAVA APPLET的出現，JAVA語言迅速在INTERNET上流行起來。當時的瀏覽器主要是NETSCAPE。當微軟發現明天市場的主宰可能是瀏覽器而不是案頭系統時，開始著手對NETSCAPE進行收購，在收購計劃失敗後微軟發展了自己的瀏覽器IE。



當時的INTERNET需要一種語言，而JAVA適時的出現了，由於它與C++的許多相似的文法，使得很多程式員轉向了JAVA。而它確實具有很多優勢，以至於在98年秋，它的反對者微軟在MSDN中都宣稱，JAVA是編寫COM組件的最佳語言。


隨著JAVA一起出現的還有LINUX作業系統和APACHE伺服器。這三者的聯合在伺服器端的應用表現出強大的威力，以至WINDOWS NT在企業級伺服器市場受到了很大的衝擊。


98年出現的DHTML和JAVASCRIPT導致了JAVA APPLET在網頁設計領域的淡出，在這裡有兩方面因素：一、大部分APPLET效果現在都可以由DHTML完成；二、而DHTML對頻寬的要求更低。但是JAVA因為在伺服器端的應用仍有市場，而得以繼續發展。這是開發源碼的支援者為JAVA添加了活力，首先是APACHE提出的SERVERLET 和 稍後出現的JSP，這些在.com網站的程式開發中佔據了一席之地。


JAVA平台首先以SERVERLET，然後是JSP，最後是EJB(Enterprise Java Beans)，逐步向企業級應用拓展。EJB是一個物件導向的事務進程系統，有些類似於微軟的MTS（Microsoft Transaction Server）。事實上MTS和EJB都不是很成功，因為它們都無法達到INTERNET應用的規模。


     就我的觀點來看，JAVA最失敗的時刻是，SUN通過法律手段向微軟索賠$2000萬，並獲得成功的時候。微軟從那時開始制訂自己的.NET計劃，同時也宣布了JAVA作為獨一無二的INTERNET 平台的地位的結束。

  

展望


現在，我們能看到到還只是一個很混亂的局面。而在未來，我們將看到.NET的成熟，以及它和JAVA的融合。


JAVA將繼續保持它的特點：跨平台的伺服器端應用，如WAP伺服器，或者是電信領域的如JAIN(Java API for Intelligent Networks，同時它在嵌入式系統中將繼續保持它的優勢，象智慧卡、行動電話、PDA等。而我們還將看到.NET的成熟，當然這種成熟需要時間，可能是相當長的一段時間，就好象當年JAVA成長那樣。


ORACLE 8i 及其更老一些的版本，充當著一個JAVA 運行時的載體的角色，這使得JAVA 得以與ORACLE 資料庫引擎緊密結合；同樣，.NET體系也會與新版本的SQL SERVER，緊密的結合，這將包括一個VES （虛擬執行系統）執行引擎。這將使程式開發人員可以在SQL 陳述式和預存程序中嵌入C#和VB.NET 的成分。目前，你可以通過調用DLL函數來使用擴充預存程序，但資料庫本身並沒有一個物件導向的運行時引擎與之相匹配。

  

未來的標誌.NET 成熟的裡程碑

   

非微軟產品，包括伺服器，案頭或是攜帶型裝置的作業系統如Solaris, Linux和Palm OS的.NET介面。與JAVA核心的整合。比如說，針對CLI（Common Language Infrastructure）的JAVA編譯器，針對JAVA虛擬機器的C#編譯器。SQL SERVER 或是 ORACLE 等資料庫產品中整合的VES 引擎。由中立的第三方開發的開放源碼的，完善的.NET平台。


可以預見到，微軟將會贊助一些開放源碼的項目，以使.NET 向UNIX 平台擴充，而這將有助於一些開放源碼組織減少它們對JAVA的偏愛。

  

JAVA的命運

  

     JAVA的一個主要目標是通訊裝置供應商，如NOKIA就在它的WAP SERVER 應用了JAVA。類似於70年代和80年代初，PC銷售時硬體供應商將最終的應用程式綁定在作業系統中一起銷售，JAVA現在也被綁定於通訊裝置中被銷售。

     
它的另一個主要方向是JAIN（Java API for Advanced Intelligent Network），它主要是定義一套與協議（如CDMA，GSM，IMT2000）無關的API，以便於基於開放市場的組件開發。這使得ISV（獨立軟體廠商）可以以外掛程式的形式提供通訊服務，如可自動轉接至最近的可撥通的國際話務中心的800免付費電話。當然，JAIN也遇到了對手，想微軟和不列顛通訊提出的Parlay計劃——它也被業界所支援。

    
另外，JAVA在嵌入式裝置中也保持著領先的地位，如smart 3G 和 GPRS，在這裡的行動電話系統採用的是J2ME（Java 2 Micro Edition），但是如果它不能很好的解決一些固有的問題，如載入時的延遲等，也許，很快，它就將被C#代替，如果.NET 能提供快速的運行環境，和廣泛的業界支援。

  

.NET和JAVA的整合

   

無論從商業角度，還是開發人員角度，甚至是源碼開放組織的角度，.NET和JAVA的整合都顯得很有必要，下面就二者的整合做出一個提前的估計（所有的相關項目被分為A、B、C三個組，以便於看清它們之間的關係，當然這些項目也完全可以被獨立的操作）：

JVM to CIL compiler (Group A)

Java API bridge for .NET API and lib. (Group A)

Java compiler for CLI (Group A)

CLI ports for Palm OS, Linux and Solaris (Group B)

.NET API and lib. bridge for Palm OS API (Group B)

.NET API and lib. bridge for POSIX (Group B)

CIL compiler to JVM (Group C)

.NET API and lib. bridge for Java API (Group C)

C# compiler for JVM (Group C)

    

A組的項目


    該組項目的主要目的是使現有的JAVA二進位代碼能夠在.NET平台上被執行。這意味著JAVA的二進位碼（尾碼為class 的檔案）不用再從原始碼進行重編譯就能運行於.NET 平台了。當然這些class 檔案在安裝或執行時會被編譯，就好象微軟的運行時和JIT對微軟中繼語言所做的那樣。

JVM to CIL compiler

     一個編譯器，輸入JAVA位元組碼，輸出MSIL代碼——它將被編譯為可執行檔（如EXE，DLL，MSI等）

  

Java API bridge for .NET API and lib

     
在這裡，JAVA API 與每一個相應 .NET API之間將建立一個映射，比如Java API中的java.io.File將被映射到 .NET的System.IO.File 類。相對於比較簡單的IO類的映射，還有一些映射比較複雜，比如java.net包到.NET 的SYSTEM.NET的映射。這裡存在的一個問題是：該項工作如果在C#中進行開發會比較方便。而假如在JAVA中實現，則需要有一個直接指向CLI（Common Language Interface）的編譯器，它能產生符合CLS（Common Language Specification）標準的CIL（Common Intermediate Language）代碼。

    
可以通過編寫一個嚮導式的工具來避免一些煩瑣的工作，例如，可以利用C# 或JAVA來編寫一個基於XML格式的對象描述，用它產生一個架構代碼，然後根據需要向其中手寫添加其他代碼。如果你確實打算進行這樣的操作，在http://xml.apache.org網站你可以找到很多有用的資料。微軟的過時的JAVA SDK中也有類似的工具可供參考——一個用來產生Jdirect（JDirect was the Microsoft's hack for implementing native interfaces）代碼的工具，利用它可以實現訪問本地WIN32 API。SDK中有該工具的原始碼。順便提一句，由於這裡涉及到微軟的一套獨特的JAVA擴充標記，因此SUN和微軟一直就此問題打著官司。

  

Java compiler for CLI

     它將JAVA原始碼（使用.NET 架構API）編譯為可執行檔的格式，如EXE，DLL等，這個工作是在最高的層面上對JAVA和.NET架構進行整合。這將為今後直接利用JAVA在.NET架構下建立應用打好基礎。

     
對現有JAVA編譯器的代碼產生部分重寫，將是此項工作一個比較便捷的解決方案。就我個人的意見，SUN會根據開放原始碼的標準，開發這樣的一套編譯器。當然，這樣的一些改造計劃需要對一些JAVA類進行調整。

  

B組的項目

該組的項目將主要致力於為其他的平台如PALM OS、SOLARIS以及LINUX平台開發.NET 架構的連接埠。這些連接埠應該用C 來編寫以適應速度和控制上的需要，另外採用       C 來開發還可以保留進行作業系統相關的系統級編程。


CLI ports for Palm OS, Linux and Solaris.

這部分內容事實上分為兩個獨立的部分：一、針對PALM OS；二、針對UNIX 系統。


對於PALM OS 來說，解決方案比較簡單，開發可以在PC 環境下進行，然後利用資料線或是藍芽傳輸到PALM 裝置上。與之相關的.NET 架構針對PALM OS 設計的 API 將在下個部分詳述。

    UNIX部分將利用JAVA開發，最後將PE（Portable Executeable）檔案編譯為COFF（Common Object File Format）格式，一種UNIX 可執行檔的格式。編譯將在安裝或是載入時進行。

  

.NET API and lib. bridge for Palm OS API.

這個.NET API bridge 應該以一種最佳化的方式被映射到PALM OS API上。連接器和裝載裝置的映射表駐留在PC 的網關上。通過資料線或藍芽傳輸PALM OS 的可執行代碼。它的實現將依賴於PALM OS 的駐留虛擬機器 KVM（the Java 2 Micro edition）運行時，同時它還應該避免KVM設計中JAVA運行程式載入過慢的缺陷。另外這一套API 與 為WINDWOS CE 的 設計的不同，它不應捨棄那些資源佔用較大的API 象System.Xml。.NET依賴於SOAP進行遠端方法調用。SOAP 基於 XML格式，因此它需要System.Xml的支援。如果沒有，基於SOAP的分布式應用將無法工作。通過調用System.Xml API 的方法可以實現對PDA諸如WINDOWS CE 和 PALM OS上的應用程式或是一些伺服器端的應用的遠程操作。甚至可以在SOAP的基礎上利用為WAP (Wireless Access Protocol)設計的WBXML (Wap Binary XML)標準與WAP 閘道器進行通訊。

  

.NET API and lib. bridge for POSIX.

     這部分將對.NET API 和UNIX API進行映射，大量的 C 的編程工作將是一個困難，但更大的困難將來自於GUI 元素的處理上。這些UNIX平台會有很多GUI架構，比較安全的做法是給它們提供一個WIN32 API 的連接埠作為媒介。如果能以前文所述的MICROSOFT JAVA SDK的方法來進行映射的操作，那麼將節省大量的編程工作。

  

C組的項目

  

該部分的內容致力於將.NET 架構應用於JAVA上。這將是一項艱苦的工作。當然，假如微軟向ECMA提交一份標準規範，這項工作將變的比較實際一些。

  

CIL compiler to JVM

該項目將把.NET執行程式（PE）轉換為.class格式的檔案。但如果執行程式中有一些非受管代碼，JVM將不接受它們。該項目的實現依賴於下面將要描述的.NET API bridge for Java 的實現。

  

.NET API and lib. bridge for Java API.

  

一個完全相容的.NET API bridge幾乎是不可能的，它需要依賴於微軟向ECMA提交的標準中的一些參數。這項工作將由JAVA來實現，但與前文提到的Java API to .NET bridge一樣，將有很多煩瑣的工作。

  

C# compiler for JVM

   這項工作可以用JAVA或是C# 的任意一種來完成。比較容易實現的是利用JAVA，因為有SUN的JAVA編譯器的許多代碼可以被再利用。但我建議用C# 來實現該項工作，在.NET 架構中有許多基礎的編譯器可被利用。此項目依賴於.NET API bridge for Java的實現。

  

總結

    最後我要說的是將.net 與JAVA 整合不僅僅是微軟與SUN的工作。所有的程式員也許都應對它進行關注。