十二年之前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）產生巨大的改變同時也會為客戶層和服務層帶來許多新特性如事務的支持（SystemTransactions）泛型的支持（同時支持 C#和Visual Basic）目錄服務支持管理（WMI）等等這個故事也遠遠沒有終結微軟甚至計劃將一系列新技術應用到其下一個發行版本中（NetFX 隨Vista發行）一個急速增長的社區也依然在不斷擴大並用開源和商業的新項目以及新構想增強了NET環境
在這幾年中在Java和NET環境之間產生了大量的討論大多數的討論都強烈地傾向於兩者中的一方這幾乎沒有產生任何作用畢竟諸如我的編程語言比你的編程語言要好或者我的平台比你的平台運行得要快乃至於你們很遜這類的話題或許在雞尾酒會和小組會議上是一個你來我往的頗為有趣的話題但是這些話題對於引導一個有意義的軟件開發是沒有任何成效可言的在經歷了立場和姿態上的對立以及互相攻擊以後當嘗試使NET和Java共同工作和對此進行有意義的討論時這些對話卻又轉向了一些諸如Web服務企業服務總線或面向服務的體系架構等繁雜的詞匯中而沒有任何實在的展示當越過這些高層的討論去關注底層的細節時對話中經常出現的又是SOAPWSDL和WS協議或者通過消息交換數據或者在CLR中實現JVM或者在JVM中實現CLR等
換句話說來解釋這些流行的用語即你大步邁進並討論這如何去解決這個問題但是卻從來沒有真正得討論為什麼你要這樣做 從歷史的角度看關於Java/NET互操作性的討論降低到了體系結構的次要位置僅次於按需主題——也就是說這種互操作的發生僅僅應該在一個企業同時使用NET和Java系統並且需要在它們之間進行對話時盡管如此在這個討論中關於動機問題的討論被忽視了——為什麼開發人員想要同時使用 Java和NET？盡管可能不需要這樣做
從表面上看來這是一個危險的主題因為不是由於對某個平台不能做什麼的暗示而招致完全的義憤就是任何關於某個平台可能在某方面優於另一個平台的說法都會導致偏愛或無知的譴責（這甚至忽略了一個基本的問題即指出這裡的優於的定義是什麼）與其無視或躲避這個話題不如直接面對它這樣的譴責和批評是不應該被忽略的事實上我們應該歡迎它們並將其作為一個大討論的一部分這個大討論將解答何時何地以及如何做出這些決策盡管這樣我們認為開放式的討論時刻檢查思想允許讀者形成自己的批判的觀點依然非常重要
本文作為關於Java/NET互操作性主題系列文章中的一篇也正是基於此觀點進行的
* * *
當在大腦中思索什麼是Java和NET都做的好的方面時有好幾個場景會浮現於我們的腦海並值得我們向前探索
Office客戶端JEE服務器
微軟的Office產品無論好壞即使在有電腦的歷史以來不是最流行（這裡所說的流行是指安裝在更多的電腦主機上）的軟件平台也必然是最流行的軟件平台之一目前Office產品已經迎來了第二個十年作為一個強大的平台用戶可以輸入維護和查看廣泛的不同來源的數據對於那些目前依賴於 JEE後台服務器的用戶來說既然有相當數量的數據那麼將這些數據轉入Office平台來實現更加簡單的管理和考察將是一個很好的考量更讓人感興趣的是來考察Office平台利用過程無關的通信工具實現利用Spring或其他輕型Java容器中業已實現的商業邏輯的方式
在年月發行的MSDN雜志發表了數篇關於Office開發的文章（並為此強烈建議任何對於Office編程能力不熟悉的人將此作為背景材料）在以使用Office作為一個開發平台的須知為題的一篇文章中用一個圖表展示了Office平台的全部能力這裡我們沒有卷帙浩繁地列出完全名單而是用一塊區域簡單列出Office可以與Java平台進行良好互動的幾點特性
*
外部自動化由於COM自動化技術的強大COM自動化的後繼者 Visual Studio Tools for Office （VSTO）這個主要的Office包括WordExcel Outlook 和其他應用程序等組件可以被外部的應用程序接口所驅動因此各種Office文檔就可以通過一些通用語言從外部創建拿Excel的強大的圖表和計算功能或者Word的強大的編輯和拼寫檢查功能來說考慮在Java應用程序如何結合這些功能來實現何種新功能將十分有趣在服務器上（如一個Web應用程序可以驅動Word來創建一個顧客郵件或者打印由JEE服務器傳入的包含特定數據元素的報告文本就像使用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和JEE容器中的Windwos工作流
Windows工作流是微軟在NetFX 發行版本中的發行的一個新框架它將隨著Windows Vista操作系統被同時安裝工作流的目的是提供一個方法這個方法使得商業過程功能——或許是一個小規模的應用比如網站中網頁的交互或許是一個大規模的應用比如簽署一個保險協議的主要過程——可以被非開發人員創建查看跟蹤和編輯等工作流的開發人員（或者是傳統的NET開發人員或者是領域專家）使用一個類似流圖表工具的環境設計工作流這些工作流由一些活動組成這些活動表示過程當中的一個個邏輯步驟這個環境將會隨Visual Studio一起被普遍提供但是也可以在一些其他自定義的應用程序中存在同樣也允許公司將工作流的設計者完全剝離出傳統的程序員工具之外工作流設計的結果就是一個格式化的XML文檔或代碼然後使用工作流編譯器將其編譯成一個NET類這個類將由工作流運行時處理運行於各種環境之中包括 ASPNET控制台應用程序或者是一個擁有圖形用戶接口的應用程序等工作流可以是串行的或是由外界狀態改變驅動的甚至可以跨越很長的時間間隔
從事實上看工作流運行時是被設計為易用於各種應用環境和上下文之中一個最直接的想法就是使用一些連接技術將工作流應用於Spring（或其他 JEE容器）中比如可能是工作流運行時支撐Spring容器創建自定義的活動以用於調用Spring中的Bean類執行商業功能也可能是在 Spring的Bean中支撐工作流運行時來執行對Spring接受的遠程調用進行響應的功能特別是在第二種情況下終端用戶可以設計業務過程並將其執行於傳統的企業服務器中同樣工作流的狂熱愛好者已經描述了工作流可以如何被應用以來結構化ASPNET應用程序中網頁的導航這樣一種方式不同於Structs的action映射文件在servlet容器中支撐工作流來完成同樣的目標是另一種可行的辦法同樣也在servlet和JSP網頁之間提供了一種可見的流而非目前占據此位置的晦澀的XML語法
WPF客戶端到Java服務
本節將會描述最後一個但肯定不是最不重要的場景而且它有可能成為將NET和Java在一起使用時最富有挑戰的場景在Java強大和可擴展的服務提供的數據模型之上（可能是SpringEJB或一些組合）使用新的WPF技術來提供一個豐富而強大的用戶界面WPF所宣稱的基於xaml的編程模型標志著相較於近一個時期以來典型的UI編程模型的重大改變而且在許多方面都讓人很容易地產生復雜的用戶界面這種技術超出了Swing或 SWT目前所能夠實現的另外由於xaml是一種基於文本的格式因此可以動態生成XAML並將其下載到客戶端執行就像現在的HTML一樣
WPF前台與Java後台之間通過WCF進行對話將可能稱為一個典型的場景WCF是微軟的新的通信管道使所有的分布式通信編程模式成為一個單一的架構除了支持許多最新的WS*規范WCF還通過多種途徑提供了用於通信的豐富的可擴展性模型包括通過REST格式（有時稱作普通XML或 POX）甚至可能使用其他的通信媒介比如UDPSun通過其Tango項目使得這個辦法更加可行作為一種特定的設計目標Tango項目可以與 WCF無縫集成
* * *
不言而喻以上這份列表是很難列出Java和NET之間進行可能的互操作的所有場景的事實上為了讓這篇文章處於一個可控的長度在這兒我們忽略了下面幾種可能性
*
采用Eclipse的富客戶端平台作為客戶端要麼部署一個通過由DCOM向NET/COM+通信的服務組件要麼部署一個WCF服務
*
在一台部署了Excel計算引擎的Windows Server 機器中采用Swing客戶端和/或Java Web Start創造一種便攜式可下載零部署客戶端應用解決方案
*
在一個SWT應用程序中利用DirectX提供本地的D效果（包括音效）
*
使用微軟的語音服務器以提供交互式語音識別（IVR）而前台使用一個Swing或JEE應用
等等等等等等
聽起來好像這一切都是牽強和不合理的煽情就像在腦海裡浮現出那幫擁有大量時間但卻沒有常識的營銷人員所作的事當Java擁有公式引擎時何必使用 Excel？當我們擁有JAXWS時何必使用WCF？當我們擁有JavaD時何必使用WPF？讓我們坦然的面對如下事實NET能做的任何事 Java都可以做到反之亦然免得我們因為偏愛某項技術被指責但我們也尤其須要坦白承認的一個事實是兩種平台各有特殊的興趣領域並且它們在各自的領域做得都很好開發人員願意拋開立場偏見進行開明的討論並發揮各自平台的優勢以導致一些更大的利益或是寬泛地引用卡爾？馬克斯的一句名言對每一個項目而言應該根據自己的需要充分發揮其所需平台的能力（ From each platform according to its abilities to each project according to its needs）
From:http://tw.wingwit.com/Article/program/net/201311/13442.html
