十二年之前，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)产生巨大的改变，同时也会为客户层和服务层带来许多新特性，如事务的支持(System.Transactions)，泛型的支持(同时支持C#和Visual Basic)，目录服务支持，管理(WMI)等等。这个故事也远远没有终结，微软甚至计划将一系列新技术应用到其下一个发行版本中(NetFX 3.0，随Vista发行)。一个急速增长的社区也依然在不断扩大，并用开源和商业的新项目以及新构想增强了.NET环境。

在这几年中，在Java和.NET环境之间产生了大量的讨论，大多数的讨论都强烈地倾向于两者中的一方，这几乎没有产生任何作用。毕竟，诸如“我的编程语言比你的编程语言要好”或者“我的平台比你的平台运行得要快”，乃至于“你们很逊”这类的话题或许在鸡尾酒会和小组会议上是一个你来我往的颇为有趣的话题，但是这些话题对于引导一个有意义的软件开发是没有任何成效可言的。在经历了立场和姿态上的对立以及互相攻击以后，当尝试使.NET和Java共同工作和对此进行有意义的讨论时，这些对话却又转向了一些诸如“Web服务”、“企业服务总线”或“面向服务的体系架构”等繁杂的词汇中，而没有任何实在的展示。当越过这些高层的讨论去关注底层的细节时，对话中经常出现的又是SOAP、WSDL和WS协议，或者通过消息交换数据，或者在CLR中实现JVM，或者在JVM中实现CLR等。

换句话说，来解释这些流行的用语即“你大步迈进并讨论着如何去解决这个问题，但是却从来没有真正得讨论为什么你要这样做”。从历史的角度看，关于Java/.NET互操作性的讨论降低到了体系结构的次要位置，仅次于“按需”主题——也就是说这种互操作的发生仅仅应该在一个企业同时使用.NET和Java系统，并且需要在它们之间进行对话时。尽管如此，在这个讨论中关于动机问题的讨论被忽视了——为什么开发人员想要同时使用Java和.NET?尽管可能不需要这样做。

从表面上看来，这是一个危险的主题。因为不是由于对某个平台“不能”做什么的暗示而招致完全的义愤，就是任何关于某个平台可能在某方面“优于”另一个平台的说法都会导致偏爱或无知的谴责。(这甚至忽略了一个基本的问题，即指出这里的“优于”的定义是什么)。与其无视或躲避这个话题，不如直接面对它。这样的谴责和批评是不应该被忽略的，事实上我们应该欢迎它们，并将其作为一个大讨论的一部分，这个大讨论将解答何时、何地以及如何做出这些决策。尽管这样，我们认为开放式的讨论，时刻检查思想，允许读者形成自己的、批判的观点依然非常重要。

当在大脑中思索什么是Java和.NET都做的好的方面时，有好几个场景会浮现于我们的脑海并值得我们向前探索。

Office客户端，J2EE服务器

微软的Office产品，无论好坏，即使在有电脑的历史以来不是最流行(这里所说的流行是指安装在更多的电脑主机上)的软件平台，也必然是最流行的软件平台之一。目前，Office产品已经迎来了第二个十年，作为一个强大的平台，用户可以输入，维护和查看广泛的、不同来源的数据。对于那些目前依赖于J2EE后台服务器的用户来说，既然有相当数量的数据，那么将这些数据转入Office平台来实现更加简单的管理和考察将是一个很好的考量。更让人感兴趣的是来考察Office平台利用过程无关的通信工具、实现利用Spring或其他轻型Java容器中业已实现的商业逻辑的方式。

在2006年8月发行的MSDN杂志发表了数篇关于Office开发的文章(并为此强烈建议任何对于Office编程能力不熟悉的人将此作为背景材料)，在以“使用Office作为一个开发平台的须知”为题的一篇文章中，用一个图表展示了Office平台的全部能力。这里我们没有卷帙浩繁地列出完全名单，而是用一块区域简单列出Office可以与Java平台进行良好互动的几点特性：

外部自动化

由于COM自动化技术的强大，COM自动化的后继者，Visual Studio Tools for Office (VSTO)，这个主要的Office，包括Word、Excel、Outlook和其他应用程序等，组件可以被外部的应用程序接口所驱动，因此，各种Office文档就可以通过一些通用语言从外部创建。拿Excel的强大的图表和计算功能或者Word的强大的编辑和拼写检查功能来说，考虑在Java应用程序如何结合这些功能来实现何种新功能将十分有趣，在服务器上(如一个Web应用程序可以驱动Word来创建一个顾客邮件或者打印由J2EE服务器传入的包含特定数据元素的报告文本，就像使用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和J2EE容器中的Windwos工作流

Windows工作流是微软在“NetFX 3.0”发行版本中的发行的一个新框架，它将随着Windows Vista操作系统被同时安装。工作流的目的是提供一个方法，这个方法使得商业过程功能——或许是一个小规模的应用，比如网站中网页的交互，或许是一个大规模的应用，比如签署一个保险协议的主要过程——可以被非开发人员创建、查看、跟踪和编辑等。工作流的开发人员(或者是传统的.NET开发人员，或者是领域专家)使用一个类似流图表工具的环境设计工作流，这些工作流由一些活动组成，这些活动表示过程当中的一个个逻辑步骤。这个环境将会随Visual Studio一起被普遍提供，但是也可以在一些其他自定义的应用程序中存在，同样也允许公司将工作流的设计者完全剥离出传统的程序员工具之外。工作流设计的结果就是一个格式化的XML文档或代码，然后使用工作流编译器将其编译成一个.NET类，这个类将由工作流运行时处理，运行于各种环境之中，包括ASP.NET，控制台应用程序或者是一个拥有图形用户接口的应用程序等。工作流可以是串行的或是由外界状态改变驱动的，甚至可以跨越很长的时间间隔。

从事实上看，工作流运行时是被设计为易用于各种应用环境和上下文之中，一个最直接的想法就是使用一些连接技术将工作流应用于Spring(或其他J2EE容器)中，比如可能是工作流运行时支撑Spring容器创建自定义的活动，以用于调用Spring中的Bean类执行商业功能，也可能是在Spring的Bean中支撑工作流运行时，来执行对Spring接受的远程调用进行响应的功能。特别是在第二种情况下，终端用户可以设计业务过程并将其执行于传统的企业服务器中。同样，工作流的狂热爱好者已经描述了工作流可以如何被应用，以来结构化ASP.NET应用程序中网页的导航，这样一种方式不同于Structs的action映射文件。在servlet容器中支撑工作流来完成同样的目标是另一种可行的办法，同样也在servlet和JSP网页之间提供了一种可见的“流”，而非目前占据此位置的晦涩的XML语法。

WPF客户端到Java服务

本节将会描述最后一个,但肯定不是最不重要的场景,而且它有可能成为将.NET和Java在一起使用时最富有挑战的场景：在Java强大和可扩展的服务提供的数据模型之上(可能是Spring，EJB，或一些组合)，使用新的WPF技术来提供一个丰富而强大的用户界面。WPF所宣称的基于xaml的编程模型，标志着相较于近一个时期以来典型的UI编程模型的重大改变，而且在许多方面都让人很容易地产生复杂的用户界面，这种技术超出了Swing或SWT目前所能够实现的。另外,由于xaml是一种基于文本的格式，因此可以动态生成XAML并将其下载到客户端执行，就像现在的HTML一样。

WPF前台与Java后台之间通过WCF进行对话将可能称为一个典型的场景。WCF是微软的新的通信管道，使所有的分布式通信编程模式成为一个单一的架构。除了支持许多最新的WS-*规范，WCF还通过多种途径提供了用于通信的丰富的可扩展性模型，包括通过REST格式(有时称作普通XML，或POX)，甚至可能使用其他的通信媒介，比如UDP。Sun通过其Tango项目使得这个办法更加可行，作为一种特定的设计目标，Tango项目可以与WCF无缝集成。

不言而喻，以上这份列表是很难列出Java和.NET之间进行可能的互操作的所有场景的。事实上，为了让这篇文章处于一个可控的长度，在这儿我们忽略了下面几种可能性：

听起来好像这一切都是牵强和不合理的煽情，就像在脑海里浮现出那帮拥有大量时间但却没有常识的营销人员所作的事。当Java拥有公式引擎时何必使用Excel?当我们拥有JAX-WS时何必使用WCF?当我们拥有Java3D时何必使用WPF?让我们坦然的面对如下事实：.NET能做的任何事，Java都可以做到，反之亦然。免得我们因为偏爱某项技术被指责。但我们也尤其须要坦白承认的一个事实是：两种平台各有特殊的兴趣领域，并且它们在各自的领域做得都很好。开发人员愿意抛开立场偏见，进行开明的讨论，并发挥各自平台的优势以导致一些更大的利益。或是宽泛地引用卡尔·马克思的一句名言，“对每一个项目而言，应该根据自己的需要充分发挥其所需平台的能力。”( From each platform, according to its abilities, to each project, according to its needs.)