作者 Ted Neward譯者 張立楠 發(fā)布于 2007年7月13日 上午2時19分

社區(qū)

.NET,

Java

主題

Java+.NET集成,

互操作,

故事和案例分析

大概五年前，微軟發(fā)布了.NET Framework，這是Java/J2EE和.NET平臺上最流行的幾個“專家級”產(chǎn)品之一。從那以來，我一直在講Java/.NET的協(xié)調(diào)性。無論我在哪里講，都有一個出現(xiàn)頻率極高的問題（來自我的朋友，參會人員，咨詢客戶等等）。

問：說實話，我不會傳出去的。你最喜歡哪一個？是Java還是.NET？

我并不偏好哪一個，兩個我都同樣喜歡。說實話這個答案不太容易令人信服。所以我通常用得最多的回答是下面這個。

答：看情況。

問題背景的變化

我們的業(yè)界已經(jīng)被深深地分成了兩邊，核心問題是：“你使用哪種平臺？你是Java開發(fā)者，還是.NET開發(fā)者？”從這個問題的相關討論來看，有人可能會認為這是目前最主要的話題，其中往往伴隨著激烈的爭吵和辯論。暫且不管傳統(tǒng)的“征用權”與“皇權侵略”的爭論，以及那些主流媒體認為與伊拉克和東北非的動蕩同樣重要的各種文章。如果計算其中情感的力量，世界上最重要的問題莫過于你編程時主要使用Eclipse還是Visual Studio。

諷刺而有趣的是這些爭論毫無重點。Java和.NET雖然有些方面存在沖突，實際上它們是兩種截然不同的平臺，存在各自的優(yōu)點和缺點。兩種平臺都是從各自所在的社區(qū)和文化中開發(fā)（或產(chǎn)生）出來的，因此它們通常針對不同的問題，使用不同的方法和實現(xiàn)手段。

而且近年來它們本身已經(jīng)開始出現(xiàn)分歧。以前的各種會議上，我可以說，人們選擇Java或者.NET更多是出于文化因素，“任何你通過其中一個可以做到的事，都可以通過另一個在同樣的工作量下實現(xiàn)”。現(xiàn)在不是這樣了。以前說.NET 1.0/1.1與Java相當是可以的，而現(xiàn)在它們已經(jīng)開始不同的發(fā)展方向，實現(xiàn)它們獨有的創(chuàng)新和用戶群的反饋。Java社區(qū)目前致力于各種語言與平臺之間的合作，比如說與微軟最新版本.NET 3.0，兩個截然不同的平臺間進行的標準統(tǒng)一。于是關于Java和.NET的問題開始有微妙的轉變，人們不再問“你喜歡哪個平臺？”，而開始問一個更有趣而且有力的問題：“我怎樣才能把兩個平臺結合使用？”

完全列出可用的將兩個豐富的平臺進行整合的方法超出了本文的范圍。我們可以來看幾個比較吸引人的方式，并且在理念和代碼上體會一下。

方案：從WPF到WCF，再到Java Web Service

關于Java/.NET的協(xié)調(diào)性，最常用的例子大概就是廣泛使用的Web Service，通常使用Windows表示層編程框架（WPF）或WinForms界面，結合Windows分布式編程框架（WCF）將數(shù)據(jù)實際傳送到另一端以某種Java容器形式保存的Java Web Service，可能是WebLogic，WebSphere，Spring，Tomcat，等等。搭建Web Service的酸甜苦辣有許多文章進行了描寫，所以在此不必多費筆墨。但如果將Web Service作為CORBA或.NET遠程控制（或者說分布式對象技術）的擴展，會大量消耗額外的工作和精力。使用恰當?shù)姆眨軌騽?chuàng)建比希望換掉的分布式對象工具更松散的耦合，尤其是能夠更輕松地突破我們所討論的技術壁壘。WCF和JAX-WS的核心觀念都是“傳輸消息，而非對象”，只有表面層的一些API使它們看上去比較像RMI或.NET遠程控制。因此在搭建Web Service時可以利用它們良好的協(xié)調(diào)性。本方案最明顯的優(yōu)點是每種技術都集中于它所專長的部分。前端界面使用平臺獨有的技術，因此可以發(fā)揮全部性能；而后端使用的開發(fā)平臺則因性能和可測量性著稱。

方案：SQL Server服務代理與JSP

自從SQL Server 2005發(fā)布以來，一種新的消息處理方式誕生了，這就是SQL Server服務代理，用于搭建基于消息的通訊程序。這種方式基于SQL Server的數(shù)據(jù)引擎實現(xiàn)（服務代理中的隊列均為高效數(shù)據(jù)表，頂層以簡單的外殼包裝），并且具有足夠的強壯性，能夠用于事務型和有序傳輸保證。服務代理為開發(fā)人員提供強制消息平臺，尤其是在那些已經(jīng)有數(shù)據(jù)庫的數(shù)據(jù)中心里。然而使用Java訪問SQL Server服務代理和訪問其它JDBC數(shù)據(jù)庫同樣簡單。Java應用程序，——無論是客戶端程序，還是服務器處理引擎，——都可以通過微軟SQL Server 2005 JDBC驅動（可以在MSDN上免費下載）訪問服務代理，或者向服務代理程序發(fā)送信息，以及必要的時候接收來自服務代理的信息。

在本示例中，一個虛擬的公寓大樓需要在網(wǎng)上生成維護人員的工作順序，以便住戶不必打電話要求辦公室來安排傳票（從而花費辦公室人員三倍的寶貴時間來填寫紙質(zhì)表格；事實上辦公室人員很討厭對住戶的要求視而不見）。

因此，解決方案提供者構建了一個簡單而輕便的網(wǎng)絡系統(tǒng)，其中只有兩個JSP頁面：一個供住戶將傳票放入服務中，另一個供維護人員收集傳票并瀏覽。系統(tǒng)的目的很簡單，第一個頁面收集傳票信息，包括問題描述，公寓本身，住戶姓名和電話等，然后將信息排入ServiceBroker的隊列中，等待維護部門訪問第二個JSP頁面來獲取待處理的任務列表。

至于實現(xiàn)方式，從Java的角度來說，使用ServiceBroker和使用其它以JDBC為驅動的數(shù)據(jù)庫并沒有很大區(qū)別。要把消息送入隊列中，只需要一個對SQL Server實例的JDBC調(diào)用，就像傳統(tǒng)方式寫一個INSERT或者UPDATE語句一樣:

獲取消息的方式更為直接，使用SQL Server的RECEIVE關鍵字:

或許會有許多人提出疑問，這里為何使用SQL Server服務代理，而不使用對Java更加友好的JMS實現(xiàn)方式，比如開源的ActiveMQ或商業(yè)的SonicMQ。要回答這個問題，可能會回到以往Java/.NET兼容性問題中常用的答案上：“我們這樣做是迫不得已。”更有說服力的答案是：為了“會話”。ServiceBroker提供了JMS標準中前所未有的會話功能。與事務型消息傳遞相類似，會話表現(xiàn)為往返傳遞的一系列信息，每個會話都有唯一的標識符。本質(zhì)上而言，這是連續(xù)RPC調(diào)用和獨立的單獨路徑信息的結合。它提供了消息通訊系統(tǒng)中通常難以具備的可靠性和健壯性。在我們上面的虛擬示例中，會話的使用有些隨意，它在長時間運行的商業(yè)流程中也同樣可以非常強大。上面代碼中的標識符conversationId在每個ServiceBroker實例中是唯一的，標識本次用戶交互中消息的集合（本例中只有一個）。

另一個可能出現(xiàn)的問題是為何使用JSP來編寫網(wǎng)頁界面，而不使用ASP.NET; 對于非Windows平臺而言，這仍然是個“迫不得已”的選擇。但JSP有其獨到之處，就是用于生成美觀界面的豐富的工具和預編譯組件。如果我們討論所有的Java/Web space工具，比如Struts, Seam, WebWork, JSF, Google Web Toolkit等等，都使Web開發(fā)體驗與傳統(tǒng)ASP.NET的拖放方式截然不同。（對不熟練的Web開發(fā)人員，拖放方式或許很適用，但熟練者都有自己喜歡的方式，并且覺得ASP.NET的設計與他們的方式相沖突。）關于SQL Server服務代理更詳細的討論，請見勃切明與蘇利文的《SQL Server 2005開發(fā)人員指南》。關于Servlet和JSP更詳細的討論，請見杰森?弗克納和凱文?瓊斯的《Java Servlet與JSP》。關于JDBC更詳細的討論，請見費舍爾、艾利斯和布魯斯的《JDBC教程與API參考，第三版》。

方案：Office與Spring

狂熱的開源分子聽到這一方案可能有些難以接受。毫無疑問，在過去10年中，微軟的Office提供了世界上最流行的辦公室生產(chǎn)效率軟件系列。世界上被安裝次數(shù)最多的軟件可能就是Office，其次是Windows本身。

近年來，Java社區(qū)在討論富客戶端程序，拋棄以往的點擊、等待、閱讀的網(wǎng)絡模式，尋求更具有交互性的用戶體驗。AJAX實現(xiàn)了其中的部分功能，代價是需要編寫大量額外的腳本代碼以應對不同的瀏覽器或瀏覽器版本（而有些瀏覽器禁止使用AJAX）。Java社區(qū)中有人將Eclipse富客戶端平臺視為解決法寶，有人推崇JavaWebStart, 或者Adobe Flex等等。

最好的富客戶端應該基于終端用戶機器上已經(jīng)安裝的軟件。因為Office是安裝范圍最廣的，尤其是在企業(yè)范圍內(nèi)的機器，何不利用Office的優(yōu)秀擴展接口，將Office用作富客戶端，在后端使用Java？

為了出版Office對象模型和使用方法相關的書籍，文章，教程和參考文檔，我們不知道已經(jīng)砍伐了多少森林。算上.NET和未使用的COM，Office接口非常復雜，在此列舉也沒有意義。本文將集中于Office擴展模型之一，智能標簽，以及使用XML定義文件來識別Office文檔中詞匯（通常是在Excel和Word中使用，不過PowerPoint和Access也可以使用）并提供下拉菜單供用戶跳轉到某個網(wǎng)站的智能標簽列表。

在這種情況下，虛擬環(huán)境很簡單：一家在線電子經(jīng)銷商發(fā)現(xiàn)他們的在線寵物商店非常火爆（他們終于解決了通過與世界各地的寵物商店談判后水路郵遞寵物的問題），而他們使用Spring JPetStore范例編寫的首頁現(xiàn)在需要處理各種復雜的計算，遵守公司內(nèi)財務人員和市場人員提出的商業(yè)規(guī)則。簡單的訂單都留給首頁處理，但復雜一些的訂單將由銷售人員通過面談或電話完成。

復雜的計算法則需要復雜的處理語言來實現(xiàn)，而這正是Excel的用武之地——財務人員和市場人員都可以在Excel中使用公式語言來自己編寫法則，——我們要做的下一步是將Excel中的數(shù)據(jù)表格顯示為Spring前端首頁。此時第一步只需要從Excel文檔中識別出訂單和產(chǎn)品號，然后顯示出智能標簽將銷售人員指向Spring編寫的網(wǎng)站中準確的頁面。（進一步的改進可以在保存數(shù)據(jù)表格時自動下訂單，或者在試圖銷售沒有庫存的寵物時彈出警告信息等。）

用簡單的XML文件實現(xiàn)這些，要比使用Java和.NET代碼更加實用。幸好URL天性靈活，智能列表標簽不必介意URL所指向的網(wǎng)站其實是用Spring編寫的。如下所示的智能標簽會每天刷新，隨時顯示出新的商品ID。（“看啊，孩子們，我們現(xiàn)在有雪貂的庫存！”）

簡單來說，我們需要建立兩個智能標簽。一個用來識別產(chǎn)品ID(FL-DSH-01等等),另一個用來識別項目ID(EST-16, EST-17等等). 我們只需要在URL中使用ID值來替換{TEXT}占位符并訪問網(wǎng)站。這里的ID編碼很復雜，但標簽中列出的是一個.jsp頁面——其中的代碼會向底層數(shù)據(jù)庫查詢所有的產(chǎn)品與項目ID，并在獲得新版本列表時刷新顯示（Office會自動覆蓋舊版本列表，位置在C:\Program Files\Common Files\Microsoft Shared\Smart Tag\Lists directory)。Office會每5分鐘刷新一次智能標簽列表，因為智能標簽列表將自己定義為可更新的(因為其中有上述的 和標簽), 因此它會每5分鐘進行一次更換查詢(間隔可以在標簽中定義). 也就是說，每當新的產(chǎn)品和項目被加入數(shù)據(jù)庫時，智能標簽都會自動更新，而無需人工操作。

智能標簽的能力遠遠超出這個簡單的例子所展現(xiàn)的。Visual Studio Tools for Office API可以讓.NET開發(fā)人員在所需要的智能標簽后面編寫任意形式的代碼，所以在激活智能標簽時向JPetStore引擎進行遠程調(diào)用（使用Web Service調(diào)用或其它商業(yè)工具，例如JNBridge或者ZeroC’s ICE）來獲取當前庫存量等操作也完全可以實現(xiàn)。

智能標簽并不是Office整合能力的極限。文檔表格可以通過自定義為任何Java系統(tǒng)充當用戶界面，Excel的公式語言可以通過自定義公式進行擴展（當然可以通過本地JVM使用Java API或者遠程調(diào)用Java系統(tǒng)），等等。而且方式不止一種——必要的時候，Word和Excel都可以裝入Eclipse RCP，或者說，任何一個COM自動對象都可以這樣使用，而Word和Excel本身的功能仍然完整保留。

其他方案

當然，以上并非全部可用方案，只是最近幾次討論和客戶會談中想到的一些。其它方案還有：

• 使用連接Java的Cmdlets的PowerShell：PowerShell將在不久的未來成為Windows上最重要的管理工具，而圍繞它搭建一系列通過JMX與Java服務器溝通的Cmdlets簡直輕而易舉。這樣一來，我們可以非常輕松地建立檢查IIS或其它Java服務器的狀態(tài)與性能的腳本，并將結果顯示為美觀的圖表（就像PowerGadgets中cmdlets所顯示的一樣），或者通過方法調(diào)用打開、關閉系統(tǒng)的部分功能。
• 使用Speech Server的Java：Vista中加入了一些新的語音合成功能，而微軟的Speech Server提供了Java平臺中從未有過的強大的語音識別功能。隨著我們對殘障人士用戶的日益關注，語音和通過語音與用戶交互（通過電話或者電腦話筒）將帶來越來越高的吸引力。
• 調(diào)用Java的Workflow操作：Windows Workflow具有一個預編譯操作，用于調(diào)用Web Service，但如之前所說，Web Service在特定環(huán)境下有用，卻未必能滿足所有交互要求。自定義操作可以利用其它Java/.NET交互方式與Java組件溝通。
• 內(nèi)置Workflow的Java：Workflow引擎最強大的特性，在于它可以嵌入多種環(huán)境之中，如ASP.NET。當然，它也完全可以嵌入Java系統(tǒng)，比如Tomcat或Jetty, 從而開啟Workflow的“信息工人”訪問性，與Java和.NET網(wǎng)絡應用程序連接。
• 與Java交互的Windows Mobile設備：隨著移動設備世界越來越火熱，微軟的Windows Mobile平臺成為使手寫軟件能夠在Smartphone等移動設備上運行的可選方案之一。現(xiàn)在移動設備越來越普及，IT企業(yè)都希望把它們與自己的各種環(huán)境相整合，其中自然包括Java。有時這種通訊通過Web Service完成，但有時需要更加有針對性的通訊手段，比如使用商業(yè)工具JNBridge Pro等ZeroC’s ICE。

越來越多的開發(fā)人員開始意識到結合使用.NET和Java的優(yōu)勢，因此越來越多的方案將得到實施。Java和.NET社區(qū)都在進行更多的創(chuàng)新，因此雙方都會更加開放而誠懇地考慮如何更好地解決客戶的問題。畢竟最后不論你喜歡哪種技術，我們的目的都是一個：為客戶提供解決方案。

關于作者

Ted Neward是Neward & Associate公司的主要負責人，該公司是致力于使用Java、.NET、XML及其它必要工具的企業(yè)系統(tǒng)的咨詢公司。他從1991年起開始使用C++，從1997年起開始使用Java，從2000年起開始使用.NET。他兼任PluralSight的.NET講師，獨立教授Java，在世界Java和.NET社區(qū)中的各種會議上發(fā)言，為MSDN、InfoQ和TheServerSide撰寫文章，并著有《果殼中的C#》，《SSCLI本質(zhì)》與《有效的企業(yè)級Java》等書籍。這些信息記錄于網(wǎng)站http://www.tedneward.com。

附錄：主要角色

需要注意，本文的讀者通常對兩種技術中的一個比較熟悉，而不是都熟悉。因此，下面將列出兩種平臺的主要構成。這里并不是要對每種組件進行介紹，或者進行詳細的列舉。讀者可以通過文末的參考文獻尋找更多信息。

Java：

• Java 5企業(yè)版：最近由上一個名字“Java2企業(yè)版”更改而來，通常被簡稱為J2EE。該標準是總合性標準，覆蓋了許多其它企業(yè)級標準。雖然不太準確，許多人將J2EE與EJB同等使用。
• Enterprise JavaBeans (3.0)：EJB是描述軟件組件尋求生命周期，布署連接與分布式事務管理的容器標準。可以將EJB視為事務處理框架系統(tǒng)的邏輯Java后續(xù)版本。
• JDBC (4.0)：標準Java調(diào)用層對關系數(shù)據(jù)庫API接口的實現(xiàn)。不同的廠商有不同的“提供者”（驅動）來實現(xiàn)JDBC API，使開發(fā)人員與實際的數(shù)據(jù)庫實現(xiàn)方式隔離（理論上屬于松散耦合）。
• Servlets (2.5)：Servlet標準描述了布署用于搭建動態(tài)HTTP頁面的軟件組件的標準。一個Servlet實質(zhì)上是一個Java類及擴展的特殊接口。
• Java Server Pages (2.2)：JSP頁面是針對輸出的創(chuàng)建Servlet的方式，與ASP或ColdFusion類似。JSP文件會被解釋為Java源文件(servlets)并進行編譯。
• 遠程方法調(diào)用：RMI是Java版本的對象遠程過程調(diào)用(ORPC)堆棧。RMI有兩種，一種使用本地Java傳輸格式，稱為“RMI/JRMP”；另一種使用OMG的CORBA傳輸格式，稱為“RMI/IIOP”。官方推薦的J2EE系統(tǒng)使用RMI/IIOP, 但實際使用更廣的是RMI/JRMP。
• Java信息服務(1.1)：JMS是對任意Java平臺消息服務（不是指電子郵件）的標準訪問API。
• JavaMail：JavaMail是對任意電子郵件服務(SMTP, POP3, IMAP, and so on)的標準訪問API。
• Java命名與目錄接口：對任意提供命名與/或目錄服務，比如LDAP的標準訪問API。
• Java WebStart：通過HTTP URL本地調(diào)用Java程序并存儲在客戶端機器上以備將來使用（必要時可以脫機使用）的布署技術。
• Java API for XML Binding(2.0)：JAXB是自動進行Java到XML或XML到Java翻譯的標準API。
• Java API for Web Services (2.0)：JAXWS是Java基于XML的服務的標準API。JAXWS最初名為“Java API for XML RPC (JAX-RPC)”, 在2.0版中這個名字遭到反對，因為JAXWS加入了更加面向消息的實現(xiàn)方式。
• Spring (2.0)：實際是提供輕量級Java組件服務的開源容器（又稱“POJOs”，“Plain Old Java Objects”的縮寫)。通常被視為J2EE的代替品。
• Swing：官方名稱為“Java基礎類”。Swing是跨平臺的構建富客戶端界面的工具包。因為其目的在于創(chuàng)建平臺兼容的外觀，許多繪圖和顯示邏輯都是自己編寫的。
• 標準窗口工具包（SWT）：開源的Eclipse編譯器的核心顯示技術。SWT與Swing不同的是使用本地系統(tǒng)級UI功能來完成繪圖與顯示邏輯。

.NET：

• Windows分布式編程框架（WCF）：以前的代碼名稱為“Indigo”。WCF展現(xiàn)出微軟的下一代任意程序之間通訊的API，從消息隊列到安全/可靠/事務型服務，以及WS-* web service。
• Windows表示層編程框架（WPF）：以前的代碼名稱為“Avalon”。WPF展現(xiàn)出微軟的下一代表示層，充分利用近年來業(yè)界在圖形顯示卡上的巨額投資所獲得的成就。WPF代碼有兩種利用方式，一種是在每個.NET開發(fā)實例中調(diào)用并編譯，或者使用名為“XML應用程序標記語言”（XAML）的XML進行定義，從而編譯在應用程序之中，或者通過HTTP請求傳送至IE7中進行動態(tài)顯示。WPF的子集WPF/E用于非IE的瀏覽器。
• Windows工作流編程框架（WWF）：正如其名，提供工作流編程支持。
• Windows表單：.NET對傳統(tǒng)Windows界面功能進行的包裝(User32.dll和GDI32.dll).
• 活動目錄（AD）：AD是用于企業(yè)級“帶名稱資源”部署的目錄服務，比如用戶和服務器。AD也有一個用于單個應用程序的較輕量級版本“ADAM”。
• ASP.NET：創(chuàng)建動態(tài)Web/HTTP功能的.NET實現(xiàn)方式。ASP.NET管道提供面向編程的ASHX和面向輸出的ASPX兩種表單，用于生成最終用戶可視內(nèi)容，同時還有面向編程的Web service(ASMX)。
• ADO.NET：對關系數(shù)據(jù)庫實現(xiàn)的調(diào)用級接口API。不同的廠商有不同的“提供者”（驅動）來實現(xiàn)ADO.NET API，使開發(fā)人員與實際的數(shù)據(jù)庫實現(xiàn)方式隔離（理論上屬于松散耦合）。
• .NET遠程調(diào)用：.NET版本的對象遠程過程調(diào)用(ORPC)技術。
• Microsoft消息隊列(4.0)：MSMQ是微軟的消息服務，對所有版本的Windows都可用(4.0與Vista一同提供).
• COM+/企業(yè)服務：COM+是為“管理下的應用程序”（這是原始的名稱）提供事務與生命周期服務的容器。.NET組件使用System.EnterpriseServices命名空間調(diào)用COM+。
• Microsoft Office：世界上安裝最多的辦公室生產(chǎn)效率軟件系列，主要包括Microsoft Word, Microsoft Excel, Microsoft PowerPoint and Microsoft Outlook。