|
|
通過Web Service混合.NET和Java技術(shù)往往很容易，但Web Service并非是.NET和Java互操作的萬靈丹。WebService在集成獨立的跨網(wǎng)絡(luò)通信的組件時非常有用，在簡單的調(diào)用/返回情景中，涉及的數(shù)據(jù)類型數(shù)量非常有限，且WebService是基于標(biāo)準(zhǔn)的，混合.NET和Java技術(shù)通常顯得很簡單，因此有人認(rèn)為WebService是實現(xiàn).NET和Java互操作的萬能答案，但事實卻并非如此。
在搜索引擎中搜索一下“Java .NET互操作”將會返回很多搜索結(jié)果，但聽過今年6月JavaOne會議上微軟主題演講的人應(yīng)該還有印象（51CTO編者注：互操作性在近年來成為了微軟的關(guān)注重點之一，不僅僅是Java，還有php互操作性等等），微軟說放棄Web Service可能是最好的辦法。這是很不幸的消息，因為對于很多任務(wù)，WebService并不是Java和.NET互操作的理想解決方案，而且對于部分任務(wù)，根本不可能使用WebService。在這篇文章中，我會列舉三個Java和.NET互操作情景，如果使用Web Service實現(xiàn)會被認(rèn)為是愚蠢的行為。
首先，我先說一下我認(rèn)為的Java和.NET互操作的含義，真正的Java和.NET互操作機制應(yīng)允許你在任何地方使用.NET語言編寫的代碼代替用Java語言編寫的代碼，換句話說，它應(yīng)該允許你從.NET代碼中訪問任何基于Java的實體（如對象，類或方法），反之亦如此。
情景1 在Java應(yīng)用程序中嵌入.NET UI控件
假設(shè)你要在基于AWT的Java應(yīng)用程序中使用一個Windows窗體控件，標(biāo)準(zhǔn)的做法是獲得與AWT容器對等的句柄，然后使用該句柄設(shè)置Windows窗體控件的父對象為AWT容器，你可以使用一個Web Service實現(xiàn)這類互操作。
WebService是松散耦合的，服務(wù)和客戶端運行在獨立的進(jìn)程中，因為是獨立的進(jìn)程，你就不能交換窗口句柄，句柄只在同一個進(jìn)程中才有效，有意義，換句話說，這是一個必須緊密結(jié)合才能互通的情況，這種情況WebService不能適應(yīng)，想在基于Java的GUI應(yīng)用程序中嵌入基于.NET的控件，開發(fā)人員必須想另外的辦法，反之亦如此。
情景2 從Java應(yīng)用程序中調(diào)用.NET程序庫
如果你想在Java程序中調(diào)用.NET程序庫，那你可能正處于以下環(huán)境：
1）已經(jīng)在.NET開發(fā)中使用過這個庫，你想在Java環(huán)境中繼續(xù)使用；
2）已經(jīng)花錢購買過.NET程序庫，不想再花錢購買Java程序庫；
3）不考慮平臺差異的話，這個程序庫可能是最好使用的了。
在這種情況下，你可以使用Web Service從Java訪問.NET代碼，但這種用法似乎有點小題大做，WebService更適合兩個更大的獨立組件之間的通信，而不是將一個庫集成到一個更大的系統(tǒng)中去。如果程序庫就在同一臺機器上，非要創(chuàng)建一個WebService來訪問這個庫顯得有點過分，在這種情況下，在Java程序進(jìn)程內(nèi)運行基于.NET的程序庫意義更大，但采用WebService是做不到的。
假設(shè)你使用了JMS（Java消息服務(wù)），想創(chuàng)建一個.NET組件來向它發(fā)送消息，以及從它那里接收消息。向JMS發(fā)送消息一般使用JMS API中的各種發(fā)送函數(shù)，通過在JMS基礎(chǔ)架構(gòu)上注冊監(jiān)聽器來接收消息。
你也可以使用Web Service來實現(xiàn)，但它并不擅長處理異步通信，如果你真要使用Web Service實現(xiàn)異步通信，你有兩個選擇：
1）實現(xiàn)一個輪詢機制，客戶端反復(fù)輪詢服務(wù)獲得結(jié)果，當(dāng)?shù)玫浇Y(jié)果后，服務(wù)將其放在一個預(yù)定的地方，輪詢操作就會發(fā)現(xiàn)它。
2）實現(xiàn)一個回調(diào)機制，客戶端留下回復(fù)地址，當(dāng)獲得結(jié)果后，服務(wù)將結(jié)果發(fā)往該地址。
不幸的是，這兩個機制都需要實現(xiàn)重大的基礎(chǔ)架構(gòu)，使用輪詢機制時，需要實現(xiàn)輪詢機制，還需要為服務(wù)提供一個機制放置結(jié)果，以便輪詢機制可以找到它，使用回調(diào)時，必須在客戶端嵌入一個全新的“反向”Web Service，以便原始服務(wù)可以聯(lián)系到它，并返回異步結(jié)果。
這兩個方法都不完美，如果你想一個應(yīng)用程序簡單地調(diào)用一個程序庫，Web Service需要實現(xiàn)超乎任務(wù)需要的機制，必須要有更好的方式來做到這一點。
對于復(fù)雜的Java和.NET互操作需求（如在Java程序中調(diào)用.NET庫，或使用Java API注冊一個.NET監(jiān)聽器），WebService強迫你另起爐灶，你必須建立復(fù)雜的基礎(chǔ)架構(gòu)——通過套接字交換XML——完成本應(yīng)該很簡單的任務(wù)，可以說這么做顯得很愚蠢，對于其它任務(wù)，如在Java程序中嵌入.NET UI控件，使用Web Service根本是不可能的。
開發(fā)人員和架構(gòu)師工具箱應(yīng)該擁有很多Java和.NET互操作解決方案，對有些情況可能有用，但對于許多互操作任務(wù)，你需要不同的工具，當(dāng)WebService滿足不了要求時，Java和.NET橋接器可能會有用，甚至在那些可以使用WebService的情景中，使用Java和.NET橋接器可能效率更好，并且更易于使用。
如果你理解了Web Service在互操作性方面的限制，并熟悉其它解決方案，你就可以在你的應(yīng)用程序中同時充分利用Java和.NET技術(shù)。
NET技術(shù)：Java和.NET互操作：我們應(yīng)該放棄Web Service嗎？，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
