1，為什麼要進行互操作？ 

u公司的產品是基於.NET或者Java 開發的，但是客戶沒有對應的平臺環境？

u公司的數個產品線分別使用.NET和Java技術開發，有很多重複的功能模組和業務元件，但因為技術平臺不統一而無法複用，沒法降低開發成本？

u開發人員只會.NET,現在來了Java專案，怎麼辦？要培訓成為一個熟練的Java開發人員需要一定的時間成本並帶來一定的技術風險。

    以往，我們在面對這樣的問題的時候最直接的考慮就是“我們賣的是.NET/Java 做的產品，我們需要尋找能夠提供Windows/Linux執行環境的客戶”,現在.NET和Java各自佔據了企業級使用者市場的半壁江山，選擇一種技術平臺就意味著丟棄了一半市場；所以，大的企業就選擇了“雙管其下”，為同一個產品做兩個不同的版本，執行在不同的平臺上，而小公司就要求開發人員都是全能人才，級精通Java

    如果有一種技術，能夠讓.NET的產品跑在Linux上，或者讓Java的產品元件能夠被.NET呼叫，那麼我們就不用為目標平臺的選擇，開發人員的技能培訓，產品的技術風險等問題苦惱了，同時也有效的降低了公司的專案產品開發成本。

2.互操作的型別

    Java和.NET是兩種不同的技術，但他們的實現原理卻很類似，都是基於中間程式碼解釋/編譯執行的，所以理論上它們是可以互操作的。互操作可以分為“原始碼”互操作和“平臺互操作”兩類，前者是將對方的原始碼拿到自己的平臺編譯執行，後者是提供一系列的元件，類庫，通訊介面，在平臺介面層次進行互操作。

    我們分別對這兩種互操作方式進行了研究，總結了一下可行方案：

原始碼互操作分為2類，

lJava 複用.NET程式碼：代表方案是 Mainsoft to Java EE ;

l.NET 複用Java程式碼：代表方案是Visual J# 和開源專案 IKVM.Net;

平臺互操作也分為2類，

nWeb服務（傳統的基於XML格式的Web服務和新的流行的基於JSON格式的Web服務）；

nSocket通訊，在Java平臺和.NET平臺採用Socket技術分別實現客戶端和服務端；

 3.原始碼互操作

3.1 執行環境的選擇不再依賴於具體的開發技術

--Mainsoft for Java EE

Mainsoft for Java EE能讓.NET開發人員開發出執行在Linux及其它能執行Java的作業系統之上的Web和伺服器端應用程式，而無需重寫程式碼或者學習新的開發技能。

Mainsoft的總裁和CEO，Yaacov Cohen解釋說：

“Mainsoft的跨平臺的軟體讓JVM（Java Virtual Machine）能夠完全地支援C# 2.0和Visual Basic。我們投入了1200萬美元用於把Java EE轉換到多語言平臺。因此，現在我們的企業客戶和軟體開發商，能夠把他們產品執行環境的技術選型同軟體開發的技術選型分開考慮，即可以使用高生產率的 Visual Studio IDE來進行快速應用程式開發，也能把產品部署到安全性更高擴充套件性更強的Java EE伺服器，或者門戶伺服器上。”

Mainsoft for Java EE是Mainsoft和Mono專案進行了4年合作的成果。Mono計劃主要是Linux陣營中的精英發起的開源版的.NET專案，旨在使開發者能夠編寫同時在Windows和Linux上執行的.NET程式。

注：Mono專案是Novell發起的一個開源專案，它能夠讓.NET程式執行在非Windows平臺上，包括Linux等多個非MS的作業系統平臺，Mono相當於實現了一個跨平臺的.NET執行框架。與Mono不同的是，Mainsoft在JVM上面實現了一個.NET執行庫，本質上是把.NET程式編譯成Java位元組碼在JVM上面執行的。

Mainsoft 提供了一個可以免費下載的Visual Studio 2005外掛。利用這個外掛，無需重寫你的C#或者VB.NET程式碼，你就可以使你用.NET語言開發的Web應用程式和Web服務執行在Linux平臺的Tomcat和各種Java支援的平臺下面。Mainsoft for Java EE 2.0版本目前支援Visual Studio2005的IDE，支援.NET FrameWork 2.0、Asp.NET 2.0的控制元件、角色安全、C#等。

使用Mainsoft for Java EE，企業可以在保留現有的.NET程式碼和技術的基礎之上把.NET的產品遷移到Java平臺支援的環境中（比如Linux）,最大限度的節省了你的開發成本和時間！

Mainsoft for Java EE把.NET開發者在Visual Studio中開發的應用編譯成Java的二進位制程式碼產品，這種產品完全通過了Sun的Java企業版本的簽定。Mainsoft for Java EE支援IBM WebSphere® Application Server、Tomcat各種應用和各種標準的如BEA WebLogic、JBoss等服務。

軟體開發商可以把他們的.NET原始碼應用到Java EE來擴充套件他們的市場。開發者可以通過一些簡單的程式碼來實現他們產品同時具有一套.NET的版本和一套Java的版本。

下面圖中，請大家注意其對ADO.NET的支援。

當然，Mainsoft for Java EE目前還是有一定的費用的，但是，個人覺得，對於一個企業來說，.NET的產品在Java領域的擴充套件所帶來的收益肯定要比這10000$多得多。

3.2 讓Java開發人員也能夠寫.NET程式

--Visual J# 介紹

Visual J#是Visual Studio 2005提供的一種託管語言，可供Java程式設計師構建在.NET Framework上執行的應用程式和服務。

Visual J# 面向公共語言執行庫，可以充分利用.NET Framework開發.NET應用程式，包括XML Web services和Web應用程式。

Visual J# 應用程式從下列功能中獲益：

　　●跨語言整合

　　●增強的安全性

　　●版本控制和部署支援

　　●除錯和分析服務

經實驗，Visual J#的解決方案可以直接將java程式碼檔案新增到專案中，不用更改副檔名就能使用其中的類和方法，若此java程式碼使用了第三方的jar包，首先要用IKVM.Net的命令將jar包轉成.Net的dll，然後在J#的專案中引用此dll即可。

執行：ikvmc -target:library xxx.jar

會將jar檔案自動轉換為 xxx.dll

Visual J# 自帶一個用.NET實現的 1.1.1.4 JDK，我們嘗試著使用IKVM.NET轉換引用了更高版本的JDK程式的Java元件，在使用中暫未發現問題。不過，既然是在.NET平臺下開發應用程式，使用C#等.NET原生的開發語言是首選，J#只是一個過渡，但它能夠把你現有的Java原始碼編譯成.NET應用程式或者類庫，供其它.NET程式使用，這是它的一大亮點。

4.平臺互操作

 4.1 越古老越通用 

前2個方案是基於原始碼互轉的方案，而Socket方案解決的是系統互聯的問題，即按照一定的格式將資料編碼成二進位制流，採用TCP或UDP協議進行傳輸。Socket是基於TCP和UDP協議的高層介面，定義了收發資料的格式。使用Socket通訊方式，首先需要在客戶端和服務端定義好通訊介面，包括埠號，協議，編碼格式等，由於Socket是底層的網路程式設計協議，所以採用該技術實現的應用有很高的通訊效率，幾乎是傳統異構平臺間高效通訊技術的首選。

4.2 Web服務資料交換格式的新貴

 --JSON，比XML更快更易於傳輸

JSON(JavaScript Object Notation) 是一種輕量級的資料交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。

JSON與XML的比較：

l可讀性

JSON和XML的可讀性可謂不相上下，一邊是簡易的語法，一邊是規範的標籤形式，很難分出勝負。

l可擴充套件性

　XML天生有很好的擴充套件性，JSON當然也有，沒有什麼是XML能擴充套件，JSON不能的。不過JSON可以直接轉換為Javascript物件，有著xml不可比擬的優勢。

l精簡度

相比之下JSON格式要比XML精簡一些，這對於網路間資料傳輸JSON存在一些優勢。

l序列化

現各平臺對JSON與XML的序列化支援都比較不錯，開發者們能輕而易舉的找到適合自己開發需要的序列化開發包。

我們使用.net平臺下WCF(Windows Communication Foundation)做為遠端資料服務,並以WEB HTTP和 WINDOWS FORM 客戶端(以JSON格式)方式對服務進行呼叫，測試取得良好效果。由於客戶端JavaScript程式可以直接呼叫和使用自服務端的方法或者資料，有很高的效率，所以現在JSON已經成了Web服務端和Web客戶端交換資料格式事實上的標準。

5   互操作方案總結

根據上面介紹的幾種互操作方案，和我們對這幾種方案進行的實際測試，得出了一個自己的比較結果：

     注：由於我們使用的是免費的Mainsoft for Java EE 開發人員版，所以在實際使用中有些限制，測試結果不是特別理想。對於原始碼互操作來說，它的開發工作量無疑是最小的。

在平臺互操作中，Socket這種古老的通訊方式無疑效率是最高的，但它的開發成本太高；JSON是一中資料交換格式，由於它相對於流行的XML來說要輕巧，所以在Web開發中它是資料互動格式的首選。

6如何取捨？

    在實際專案應用中，具體選擇何種互操作方式要根據情況而定，如果要追求最高的程式碼執行效率和複用程度，應該選擇原始碼互操作方案，如果不能修改或者擴充套件專案原有程式碼，或者應用分佈在不同的物理機器上，那麼應該採用平臺間互操作的方式。

儘管技術的進步已經使得Java & .NET 這兩種技術平臺可以在原始碼級別進行互操作，但仍然有相當多的應用開發商對此持審慎態度，甚至還有很多人認為根本不可能或者持懷疑態度，因而目前兩大平臺的互操走大都使用Web服務方式。技術是為市場服務的，如果有新技術能夠為我們的開發降低成本，擴大市場，我們應該拋棄“Java & .NET陣營”的思想壁壘，就像世界拋棄“東西方意識形態陣營”一樣，迎來一個多元的開放的新世紀！