十二年之前，Sun公司默默宣布了一種可以使網頁更動感和更富有活力的編程語言及其環境。當然，目前Java語言已經成為了一種普遍使用的工具，不僅僅用于為網頁添加更多的動態效果，還包括創建和生成這些網頁（透過servlets和JSP技術），提供一個用于事務性過程和商業邏輯的平臺（透過EJB技術，即Enterprise Java Beans）,訪問消息系統（透過JMS技術，即Java Message Service），訪問關系型數據庫（透過JDBC技術），甚至于訪問不同的主機（透過Java Connector API技術）。但這個故事還遠遠沒有終結，每天，以Java為中心的社區通過開源的努力和大量的項目變得越來越強大，甚至于官方的Java平臺也不斷地通過Java Community Process這樣一個開放性的國際組織來進行構建、成長和對自身進行增強。

六年之前，微軟大張旗鼓地宣布了一系列嶄新的編程語言和應用于各種開發場景下的環境。在此之后，.NET已經出現了兩個發行版本。每一個主要的發行版本都會對運行時和三款主流的語言（C#，C++和Visual Basic）產生巨大的改變，同時也會為客戶層和服務層帶來許多新特性，如事務的支持(System.Transactions)，泛型的支持（同時支持C#和Visual Basic），目錄服務支持，管理（WMI）等等。這個故事也遠遠沒有終結，微軟甚至計劃將一系列新技術應用到其下一個發行版本中（NetFX 3.0, 隨Vista發行）。一個急速增長的社區也依然在不斷擴大，并用開源和商業的新項目以及新構想增強了.NET環境。

在這幾年中，在Java和.NET環境之間產生了大量的討論，大多數的討論都強烈地傾向于兩者中的一方，這幾乎沒有產生任何作用。畢竟，諸如“我的編程語言比你的編程語言要好”或者“我的平臺比你的平臺運行得要快”，乃至于“你們很遜”這類的話題或許在雞尾酒會和小組會議上是一個你來我往的頗為有趣的話題，但是這些話題對于引導一個有意義的軟件開發是沒有任何成效可言的。在經歷了立場和姿態上的對立以及互相攻擊以后，當嘗試使.NET和Java共同工作和對此進行有意義的討論時，這些對話卻又轉向了一些諸如“Web服務”、“企業服務總線”或“面向服務的體系架構”等繁雜的詞匯中，而沒有任何實在的展示。當越過這些高層的討論去關注底層的細節時，對話中經常出現的又是SOAP、WSDL和WS協議，或者通過消息交換數據，或者在CLR中實現JVM，或者在JVM中實現CLR等。

換句話說，來解釋這些流行的用語即“你大步邁進并討論這如何去解決這個問題，但是卻從來沒有真正得討論為什么你要這樣做” 從歷史的角度看，關于Java/.NET互操作性的討論降低到了體系結構的次要位置，僅次于“按需”主題——也就是說這種互操作的發生僅僅應該在一個企業同時使用.NET和Java系統，并且需要在它們之間進行對話時。盡管如此，在這個討論中關于動機問題的討論被忽視了——為什么開發人員想要同時使用Java和.NET？盡管可能不需要這樣做。

從表面上看來，這是一個危險的主題。因為不是由于對某個平臺“不能”做什么的暗示而招致完全的義憤，就是任何關于某個平臺可能在某方面“優于”另一個平臺的說法都會導致偏愛或無知的譴責。（這甚至忽略了一個基本的問題，即指出這里的“優于”的定義是什么）。與其無視或躲避這個話題，不如直接面對它。這樣的譴責和批評是不應該被忽略的，事實上我們應該歡迎它們，并將其作為一個大討論的一部分，這個大討論將解答何時、何地以及如何做出這些決策。盡管這樣，我們認為開放式的討論，時刻檢查思想，允許讀者形成自己的、批判的觀點依然非常重要。

本文作為關于Java/.NET互操作性主題系列文章中的一篇，也正是基于此觀點進行的。

* * *

當在大腦中思索什么是Java和.NET都做的好的方面時，有好幾個場景會浮現于我們的腦海并值得我們向前探索。

Office客戶端，J2EE服務器

微軟的Office產品，無論好壞，即使在有電腦的歷史以來不是最流行（這里所說的流行是指安裝在更多的電腦主機上）的軟件平臺，也必然是最流行的軟件平臺之一。目前，Office產品已經迎來了第二個十年，作為一個強大的平臺，用戶可以輸入，維護和查看廣泛的、不同來源的數據。對于那些目前依賴于J2EE后臺服務器的用戶來說，既然有相當數量的數據，那么將這些數據轉入Office平臺來實現更加簡單的管理和考察將是一個很好的考量。更讓人感興趣的是來考察Office平臺利用過程無關的通信工具、實現利用Spring或其他輕型Java容器中業已實現的商業邏輯的方式。

在2006年8月發行的MSDN雜志發表了數篇關于Office開發的文章（并為此強烈建議任何對于Office編程能力不熟悉的人將此作為背景材料），在以“使用Office作為一個開發平臺的須知”為題的一篇文章中，用一個圖表展示了Office平臺的全部能力。這里我們沒有卷帙浩繁地列出完全名單，而是用一塊區域簡單列出Office可以與Java平臺進行良好互動的幾點特性：

• 外部自動化。由于COM自動化技術的強大，COM自動化的后繼者，Visual Studio Tools for Office (VSTO)，這個主要的Office，包括Word、Excel、 Outlook 和其他應用程序等，組件可以被外部的應用程序接口所驅動，因此，各種Office文檔就可以通過一些通用語言從外部創建。拿Excel的強大的圖表和計算功能或者Word的強大的編輯和拼寫檢查功能來說，考慮在Java應用程序如何結合這些功能來實現何種新功能將十分有趣，在服務器上（如一個Web應用程序可以驅動Word來創建一個顧客郵件或者打印由J2EE服務器傳入的包含特定數據元素的報告文本，就像使用Velocity引擎填充模板生成HTML的方式一樣），或者是在客戶端，利用Eclipse富客戶端平臺，一個已經實現可以作為COM自動化組件的宿主（事實上，Eclipse可以在一個安裝有Office的Windows操作系統里創建Word文檔）。當用戶僅僅需要查看Word文檔而不是創作Word文檔時，這就顯得尤其重要。微軟提供了一個免費的Word查看程序，如果Java的Web應用程序負責創建Word文檔，然后通過HTTP協議在網絡上傳送，這樣就可以提供一個比HTML更加豐富的格式。

• 插件。Office也可以提供插件功能，一些軟件組件作為插件在Office的內部運行，通常的情形是將它們自身作為一個主菜單項或者一個上下文菜單。一個.NET組件可以將其自身注冊為一個Excel電子表格應用程序插件，使用一些形式的Java互聯技術（Web服務，遠程調用工具包或其他過程內宿主）來連接Java的商業組件用于驗證、數據獲取或存儲。比如，很多公司使用Excel作為一個發票和/或會計解決方案，而且他們可能使用了一些Java組件作為一個簡單的進出公司會計系統的方式。這個會計系統一般是龐大的、基于Java技術的一個應用程序包，運行在一個企業級的服務器上，通過EJB中的會話Bean提供的Java連接器進行訪問。

• Excel用戶自定義函數。Excel在其計算引擎中已經提供調用用戶自定義函數功能有非常久的時間了，從歷史來看，這些函數必然是使用非托管的（原始C++）代碼編寫而成，這些代碼為應用程序帶來了危險的不穩定性。創建一個Excel中的用戶自定義函數為應用程序服務器中業已存在的商業邏輯進行一個簡單的包裝——比如一個存貨支票調用Excel表格模板來生成一個訂購單——可以提供給對大多數Excel用戶來說Excel不曾給過的強大的在線體驗。

• 智能標記。智能標記是微軟為文檔中的一些小方框所起的新名稱，這寫文檔中的小方框包含一個箭頭，一般位于感興趣的內容旁邊。在文檔中，智能標記經常會被配置和自定義特殊的元素，比如說在Word的自動糾錯中，如果Word認為出現了一個打印錯誤，那么在被糾正的單詞上方懸停鼠標就會出現一個智能標記，在沒有出現真正的錯誤的情況下，允許用戶選擇取消這個糾正。智能標記就是插件的一種形式，因此其他幫助用戶彌補客戶端和企業服務之間裂痕的可視化輔助組件也可以使用此種形式。

Office同樣為那些使用了綱領性元素的組件和文檔提供了一些部署的支持，因此在很多情況下，在這些組件內進行功能的升級就像到一個共享下載服務器發布一些東西一樣簡單。顯然，一個主要的考慮是使用Office將出現許可費帶來的成本，但幸運的是，大多數商業環境應該都已經部署了Office環境，減少了顯著增加的費用。

Spring和J2EE容器中的Windwos工作流

Windows工作流是微軟在“NetFX 3.0”發行版本中的發行的一個新框架，它將隨著Windows Vista操作系統被同時安裝。工作流的目的是提供一個方法，這個方法使得商業過程功能——或許是一個小規模的應用，比如網站中網頁的交互，或許是一個大規模的應用，比如簽署一個保險協議的主要過程——可以被非開發人員創建、查看、跟蹤和編輯等。工作流的開發人員（或者是傳統的.NET開發人員，或者是領域專家）使用一個類似流圖表工具的環境設計工作流，這些工作流由一些活動組成，這些活動表示過程當中的一個個邏輯步驟。這個環境將會隨Visual Studio一起被普遍提供，但是也可以在一些其他自定義的應用程序中存在，同樣也允許公司將工作流的設計者完全剝離出傳統的程序員工具之外。工作流設計的結果就是一個格式化的XML文檔或代碼，然后使用工作流編譯器將其編譯成一個.NET類，這個類將由工作流運行時處理，運行于各種環境之中，包括ASP.NET，控制臺應用程序或者是一個擁有圖形用戶接口的應用程序等。工作流可以是串行的或是由外界狀態改變驅動的，甚至可以跨越很長的時間間隔。

從事實上看，工作流運行時是被設計為易用于各種應用環境和上下文之中，一個最直接的想法就是使用一些連接技術將工作流應用于Spring（或其他J2EE容器）中，比如可能是工作流運行時支撐Spring容器創建自定義的活動，以用于調用Spring中的Bean類執行商業功能，也可能是在Spring的Bean中支撐工作流運行時，來執行對Spring接受的遠程調用進行響應的功能。特別是在第二種情況下，終端用戶可以設計業務過程并將其執行于傳統的企業服務器中。同樣，工作流的狂熱愛好者已經描述了工作流可以如何被應用，以來結構化ASP.NET應用程序中網頁的導航，這樣一種方式不同于Structs的action映射文件。在servlet容器中支撐工作流來完成同樣的目標是另一種可行的辦法，同樣也在servlet和JSP網頁之間提供了一種可見的“流”，而非目前占據此位置的晦澀的XML語法。

WPF客戶端到Java服務

本節將會描述最后一個,但肯定不是最不重要的場景,而且它有可能成為將.NET和Java在一起使用時最富有挑戰的場景：在Java強大和可擴展的服務提供的數據模型之上（可能是Spring，EJB，或一些組合），使用新的WPF技術來提供一個豐富而強大的用戶界面。WPF所宣稱的基于xaml的編程模型，標志著相較于近一個時期以來典型的UI編程模型的重大改變，而且在許多方面都讓人很容易地產生復雜的用戶界面，這種技術超出了Swing或SWT目前所能夠實現的。另外,由于xaml是一種基于文本的格式，因此可以動態生成XAML并將其下載到客戶端執行，就像現在的HTML一樣。

WPF前臺與Java后臺之間通過WCF進行對話將可能稱為一個典型的場景。WCF是微軟的新的通信管道，使所有的分布式通信編程模式成為一個單一的架構。除了支持許多最新的WS-*規范，WCF還通過多種途徑提供了用于通信的豐富的可擴展性模型，包括通過REST格式（有時稱作普通XML，或POX），甚至可能使用其他的通信媒介，比如UDP。Sun通過其Tango項目使得這個辦法更加可行，作為一種特定的設計目標，Tango項目可以與WCF無縫集成。

* * *

不言而喻，以上這份列表是很難列出Java和.NET之間進行可能的互操作的所有場景的。事實上,為了讓這篇文章處于一個可控的長度，在這兒我們忽略了下面幾種可能性：

• 采用Eclipse的富客戶端平臺作為客戶端，要么部署一個通過由DCOM向.NET/COM+通信的服務組件，要么部署一個WCF服務。

• 在一臺部署了Excel計算引擎的Windows Server 2003機器中采用Swing客戶端和/或Java Web Start創造一種便攜式、可下載、零部署客戶端應用解決方案。

• 在一個SWT應用程序中利用DirectX提供本地的3D效果(包括音效)。

• 使用微軟的語音服務器，以提供交互式語音識別(IVR)，而“前臺”使用一個Swing或J2EE應用。

等等,等等,等等。

聽起來好像這一切都是牽強和不合理的煽情，就像在腦海里浮現出那幫擁有大量時間但卻沒有常識的營銷人員所作的事。當Java擁有公式引擎時何必使用Excel?當我們擁有JAX-WS時何必使用WCF？當我們擁有Java3D時何必使用WPF？讓我們坦然的面對如下事實：.NET能做的任何事，Java都可以做到，反之亦然。免得我們因為偏愛某項技術被指責。但我們也尤其須要坦白承認的一個事實是：兩種平臺各有特殊的興趣領域，并且它們在各自的領域做得都很好。開發人員愿意拋開立場偏見，進行開明的討論，并發揮各自平臺的優勢以導致一些更大的利益。或是寬泛地引用卡爾?馬克斯的一句名言,“對每一個項目而言，應該根據自己的需要充分發揮其所需平臺的能力。”（ From each platform, according to its abilities, to each project, according to its needs.）