原文地址：http://www.devx.com/enterprise/Article/43086/0/page/1
利用Web Services 將 .NET 和 Java 技術融合很容易，但對於許多任務來說，Web Services 並不是Java / .NET互操作性的解決方案。
Web services 對於集成網絡通信的獨立組件很有用。當使用直接的調用/返回方式時，涉及的數據類型的數量非常有限，建立並讓它們工作很簡單。因爲，web services 是標準的，所以，用它將 .NET 和 Java 融合也很容易，這讓一些人相信，web services 是 Java/.NET 互操作性的靈丹妙藥，但通常不是。
簡單在搜索引擎搜索一下“Java/.NET互操作性”，會得到很多檢索結果，參加2009年6月 “Microsoft keynote at JavaOne 2009”會議的人都相信 Web services 是最好的方式。很不幸，對於很多任務來說，Web services 並不是Java/.NET互操作性的理想解決方案。很多任務使用 Web services 幾乎是不可能的。下面，我會列舉三個用 Web services 實現 Java/.NET 互操作的情景，從中可以看出，用Web services並不是一個明智的選擇，甚至愚蠢。
首先，先準確定義一下，什麼是 Java和.NET互操作性。誠然，這不太容易，但一個真正的 Java/.NET 互操作機制應該允許你在任何地方替換用 Java 編寫的代碼，你一般會用 .NET 語言編寫的代碼來替換。換句話說，允許你從 .NET 代碼中訪問任何基於Java的實體（如對象，類或是方法），反之亦如此。對於很多開發者和架構師不會使用 web services 的情景來說，定義Java/.NET互操作性是很有益的。
情景1. 將 .NET UI 控件嵌入到 Java 應用程序
考慮一個情況：你想要在基於AWT的Java應用程序中使用一個Windows窗體控件。
標準的做法是獲得與AWT容器對等的句柄（底層 Windows 對象，the underlying Windows object），然後使用該句柄設置Windows窗體控件的父對象爲AWT容器（也就這些，這就是嵌入工作的主要要求）。你不能使用 Web Service 實現這類互操作性。
Web Service是鬆散耦合（loosely coupled）。服務和客戶端運行在獨立的進程中。在獨立的進程中，你不能交換窗口句柄。而句柄只有在同一個進程中才是有效的、有意義的。換句話說，這是一個必須緊密耦合（tightly coupled）的互操作性情景。Web Service 就不能適應這種情況。想在基於Java的GUI應用程序中嵌入基於.NET的控件，開發人員必須想另外的辦法，反之亦如此。若想將基於 .NET 的控件嵌入到基於 Java GUI的應用程序（或反之亦然），開發人員就不得不使用其他方法。
情景2. 從 Java 應用程序調用 .NET 程序集
假設你有一個基於 .NET 程序集，想在其他基於 Java 的應用程序中使用。很多因素能導致這種情況，例如：
1) 已在 .NET 開發中使用了這個庫，你想繼續使用這個庫（庫都是有特殊、專門的用途的）；
2) 已購買 .NET 庫，不想再購買Java庫；
3) 不考慮平臺的話，這個庫可能是最好使用的。
在某些情況下，你可以使用 Web Service 在 Java 中訪問 .NET 代碼，但是，這種似乎有點小題大做。通過簡單訪問一個庫，建立一個服務，顯然沒意義。Web Service更適合兩個大的獨立組件之間的通信，而不是將一個庫集成到一個大的系統中。如果庫都在同一個機器上，那麼創建一個Web service，讓一個應用程序訪問一個庫，顯然有點過了。在這種情況下，在Java 應用程序進程內運行基於 .NET 庫，更有意義。但是用 Web Service 不能做到這點。
情景3. 用一個 Java API 註冊一個 .NET 監聽（.NET Listener）
假設你有一個 JMS 消息服務（Java Message Service）架構（JMS infrastructure），你想創建一個 .NET 組件，向它發送消息，並從它那裏接收消息。
一般地，你通過調用 JMS API 中的發送方法，向 JMS 發送消息，用 JMS 設施註冊監聽來接受消息。當消息到達時，監聽就會執行。
你也可以使用 Web Service來完成，但它並不適於處理異步通信。如果你真要使用 Web Service 實現異步通信，你有兩個選擇：
1) 實現一個輪詢機制，客戶端反覆輪詢服務以便獲得結果。當得到結果後，服務將其放在一個預定的位置，輪詢操作就會發現它。
2) 實現一個回調機制，客戶端留下一個回覆地址（return address）。當獲得結果後，服務調用這個回覆地址。不幸的是，這兩個機制都需要實現一個很大的基礎架構。
在輪詢機制情況下，你需要實現輪詢機制，以及爲服務放置結果的機制，以便輪詢機制能看到它。
在回調機制情況下，你必須在客戶端嵌入一個全新的“反向”Web Service，以便原始服務可以與它通信，並返回異步結果。這兩個方法都缺少相稱性。如果你只是想簡單地讓一個應用程序調用一個庫，Web Service 需要實現與目前任務完全不相稱的機制。當某一個動作發生時，註冊一個監聽器，是最好的例子。必須要有更好的方式來完成。
需要額外的工具爲 Java /.NET 互操作性
對於複雜的、但仍然比較簡單的 Java/.NET 互操作需求（如在 Java 應用程序中調用 .NET 庫，或使用Java API註冊一個 .NET 監聽器），Web Service使你浪費時間，去做別人已做好的事（reinvent the wheel）。你必須建立複雜的基礎架構——通過 sock 交換 XML——來完成本應該很簡單的任務。這是愚蠢的。而且對於其它任務，如在 Java 應用程序中嵌入 .NET UI 控件，Web Service根本是不可能的。
開發人員和架構師工具箱有很多 Java/.NET 互操作性的解決方案，除了 web services 外。對某些情況，它們很有用。但是對於許多互操作任務，你需要不同的工具。當 Web Service 不合適或是無法工作時，Java/.NET 橋接器（bridge）會很好地工作，甚至在那些可以用 Web Service 的情況中，效率更高、更容易使用。
如果你理解了 Web Service 在互操作性方面的侷限性，並熟悉其它解決方案，你就可以在你的應用程序中充分利用Java和.NET技術。