通过Web Service混合.NET和Java技术往往很容易，但Web Service并非是.NET和Java互操作的万灵丹。WebService在集成独立的跨网络通信的组件时非常有用，在简单的调用/返回情景中，涉及的数据类型数量非常有限，且WebService是基于标准的，混合.NET和Java技术通常显得很简单，因此有人认为WebService是实现.NET和Java互操作的万能答案，但事实却并非如此。

　　在搜索引擎中搜索一下“Java .NET互操作”将会返回很多搜索结果，但听过今年6月JavaOne会议上微软主题演讲的人应该还有印象（51CTO编者注：互操作性在近年来成为了微软的关注重点之一，不仅仅是Java，还有php互操作性等等），微软说放弃Web Service可能是最好的办法。这是很不幸的消息，因为对于很多任务，WebService并不是Java和.NET互操作的理想解决方案，而且对于部分任务，根本不可能使用WebService。在这篇文章中，我会列举三个Java和.NET互操作情景，如果使用Web Service实现会被认为是愚蠢的行为。

　　首先，我先说一下我认为的Java和.NET互操作的含义，真正的Java和.NET互操作机制应允许你在任何地方使用.NET语言编写的代码代替用Java语言编写的代码，换句话说，它应该允许你从.NET代码中访问任何基于Java的实体（如对象，类或方法），反之亦如此。

　　情景1 在Java应用程序中嵌入.NET UI控件

　　假设你要在基于AWT的Java应用程序中使用一个Windows窗体控件，标准的做法是获得与AWT容器对等的句柄，然后使用该句柄设置Windows窗体控件的父对象为AWT容器，你可以使用一个Web Service实现这类互操作。

　　WebService是松散耦合的，服务和客户端运行在独立的进程中，因为是独立的进程，你就不能交换窗口句柄，句柄只在同一个进程中才有效，有意义，换句话说，这是一个必须紧密结合才能互通的情况，这种情况WebService不能适应，想在基于Java的GUI应用程序中嵌入基于.NET的控件，开发人员必须想另外的办法，反之亦如此。

　　情景2 从Java应用程序中调用.NET程序库

　　如果你想在Java程序中调用.NET程序库，那你可能正处于以下环境：

　　1）已经在.NET开发中使用过这个库，你想在Java环境中继续使用；

　　2）已经花钱购买过.NET程序库，不想再花钱购买Java程序库；

　　3）不考虑平台差异的话，这个程序库可能是最好使用的了。

　　在这种情况下，你可以使用Web Service从Java访问.NET代码，但这种用法似乎有点小题大做，WebService更适合两个更大的独立组件之间的通信，而不是将一个库集成到一个更大的系统中去。如果程序库就在同一台机器上，非要创建一个WebService来访问这个库显得有点过分，在这种情况下，在Java程序进程内运行基于.NET的程序库意义更大，但采用WebService是做不到的。

　　情景3 使用Java API注册.NET监听器

　　假设你使用了JMS（Java消息服务），想创建一个.NET组件来向它发送消息，以及从它那里接收消息。向JMS发送消息一般使用JMS API中的各种发送函数，通过在JMS基础架构上注册监听器来接收消息。

　　你也可以使用Web Service来实现，但它并不擅长处理异步通信，如果你真要使用Web Service实现异步通信，你有两个选择：

　　1）实现一个轮询机制，客户端反复轮询服务获得结果，当得到结果后，服务将其放在一个预定的地方，轮询操作就会发现它。

　　2）实现一个回调机制，客户端留下回复地址，当获得结果后，服务将结果发往该地址。

　　不幸的是，这两个机制都需要实现重大的基础架构，使用轮询机制时，需要实现轮询机制，还需要为服务提供一个机制放置结果，以便轮询机制可以找到它，使用回调时，必须在客户端嵌入一个全新的“反向”Web Service，以便原始服务可以联系到它，并返回异步结果。

　　这两个方法都不完美，如果你想一个应用程序简单地调用一个程序库，Web Service需要实现超乎任务需要的机制，必须要有更好的方式来做到这一点。

　　Java和.NET互操作需要的附件工具

　　对于复杂的Java和.NET互操作需求（如在Java程序中调用.NET库，或使用Java API注册一个.NET监听器），WebService强迫你另起炉灶，你必须建立复杂的基础架构——通过套接字交换XML——完成本应该很简单的任务，可以说这么做显得很愚蠢，对于其它任务，如在Java程序中嵌入.NET UI控件，使用Web Service根本是不可能的。

　　开发人员和架构师工具箱应该拥有很多Java和.NET互操作解决方案，对有些情况可能有用，但对于许多互操作任务，你需要不同的工具，当WebService满足不了要求时，Java和.NET桥接器可能会有用，甚至在那些可以使用WebService的情景中，使用Java和.NET桥接器可能效率更好，并且更易于使用。

　　如果你理解了Web Service在互操作性方面的限制，并熟悉其它解决方案，你就可以在你的应用程序中同时充分利用Java和.NET技术。

NET技术：Java和.NET互操作：我们应该放弃Web Service吗？，转载需保留来源！

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。