Java、.NET，为什么不合二为一？

十二年之前，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 互操作性主题系列文章中的一篇，也正是基于此观点进行的。

* * *

当在大脑中思索什么是 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 之间进行可能的互操作的所有场景的。事实上, 为了让这篇文章处于一个可控的长度，在这儿我们忽略了下面几种可能性：

• 采用 Eclipse 的富客户端平台作为客户端，要么部署一个通过由 DCOM 向.NET/COM+ 通信的服务组件，要么部署一个 WCF 服务。
• 在一台部署了 Excel 计算引擎的 Windows Server 2003 机器中采用 Swing 客户端和 / 或 Java Web Start 创造一种便携式、可下载、零部署客户端应用解决方案。
• 在一个 SWT 应用程序中利用 DirectX 提供本地的 3D 效果 (包括音效)。
• 使用微软的语音服务器，以提供交互式语音识别 (IVR)，而“前台”使用一个 Swing 或 J2EE 应用。

等等, 等等, 等等。

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

查看英文原文： Java, .NET, But Why Together? - - - - - -

译者简介：张立，博士研究生，喜欢新技术，新思想。经历了一些企业级软件开发后，逐渐将兴趣转向 C#和 JAVA 的企业级应用。同时对动态语言的发展非常关注，喜欢用 Python 进行一些计算，对 Ruby 也倾注了一定的精力。大部分时间在学校从事一些理论研究，工作之余关注开源软件的进展。