十二年之前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）产生巨大的改变同时也会为客户层和服务层带来许多新特性如事务的支持（SystemTransactions）泛型的支持（同时支持 C#和Visual Basic）目录服务支持管理（WMI）等等这个故事也远远没有终结微软甚至计划将一系列新技术应用到其下一个发行版本中（NetFX 随Vista发行）一个急速增长的社区也依然在不断扩大并用开源和商业的新项目以及新构想增强了NET环境
在这几年中在Java和NET环境之间产生了大量的讨论大多数的讨论都强烈地倾向于两者中的一方这几乎没有产生任何作用毕竟诸如我的编程语言比你的编程语言要好或者我的平台比你的平台运行得要快乃至于你们很逊这类的话题或许在鸡尾酒会和小组会议上是一个你来我往的颇为有趣的话题但是这些话题对于引导一个有意义的软件开发是没有任何成效可言的在经历了立场和姿态上的对立以及互相攻击以后当尝试使NET和Java共同工作和对此进行有意义的讨论时这些对话却又转向了一些诸如Web服务企业服务总线或面向服务的体系架构等繁杂的词汇中而没有任何实在的展示当越过这些高层的讨论去关注底层的细节时对话中经常出现的又是SOAPWSDL和WS协议或者通过消息交换数据或者在CLR中实现JVM或者在JVM中实现CLR等
换句话说来解释这些流行的用语即你大步迈进并讨论这如何去解决这个问题但是却从来没有真正得讨论为什么你要这样做 从历史的角度看关于Java/NET互操作性的讨论降低到了体系结构的次要位置仅次于按需主题——也就是说这种互操作的发生仅仅应该在一个企业同时使用NET和Java系统并且需要在它们之间进行对话时尽管如此在这个讨论中关于动机问题的讨论被忽视了——为什么开发人员想要同时使用 Java和NET？尽管可能不需要这样做
从表面上看来这是一个危险的主题因为不是由于对某个平台不能做什么的暗示而招致完全的义愤就是任何关于某个平台可能在某方面优于另一个平台的说法都会导致偏爱或无知的谴责（这甚至忽略了一个基本的问题即指出这里的优于的定义是什么）与其无视或躲避这个话题不如直接面对它这样的谴责和批评是不应该被忽略的事实上我们应该欢迎它们并将其作为一个大讨论的一部分这个大讨论将解答何时何地以及如何做出这些决策尽管这样我们认为开放式的讨论时刻检查思想允许读者形成自己的批判的观点依然非常重要
本文作为关于Java/NET互操作性主题系列文章中的一篇也正是基于此观点进行的
* * *
当在大脑中思索什么是Java和NET都做的好的方面时有好几个场景会浮现于我们的脑海并值得我们向前探索
Office客户端JEE服务器
微软的Office产品无论好坏即使在有电脑的历史以来不是最流行（这里所说的流行是指安装在更多的电脑主机上）的软件平台也必然是最流行的软件平台之一目前Office产品已经迎来了第二个十年作为一个强大的平台用户可以输入维护和查看广泛的不同来源的数据对于那些目前依赖于 JEE后台服务器的用户来说既然有相当数量的数据那么将这些数据转入Office平台来实现更加简单的管理和考察将是一个很好的考量更让人感兴趣的是来考察Office平台利用过程无关的通信工具实现利用Spring或其他轻型Java容器中业已实现的商业逻辑的方式
在年月发行的MSDN杂志发表了数篇关于Office开发的文章（并为此强烈建议任何对于Office编程能力不熟悉的人将此作为背景材料）在以使用Office作为一个开发平台的须知为题的一篇文章中用一个图表展示了Office平台的全部能力这里我们没有卷帙浩繁地列出完全名单而是用一块区域简单列出Office可以与Java平台进行良好互动的几点特性
*
外部自动化由于COM自动化技术的强大COM自动化的后继者 Visual Studio Tools for Office （VSTO）这个主要的Office包括WordExcel Outlook 和其他应用程序等组件可以被外部的应用程序接口所驱动因此各种Office文档就可以通过一些通用语言从外部创建拿Excel的强大的图表和计算功能或者Word的强大的编辑和拼写检查功能来说考虑在Java应用程序如何结合这些功能来实现何种新功能将十分有趣在服务器上（如一个Web应用程序可以驱动Word来创建一个顾客邮件或者打印由JEE服务器传入的包含特定数据元素的报告文本就像使用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和JEE容器中的Windwos工作流
Windows工作流是微软在NetFX 发行版本中的发行的一个新框架它将随着Windows Vista操作系统被同时安装工作流的目的是提供一个方法这个方法使得商业过程功能——或许是一个小规模的应用比如网站中网页的交互或许是一个大规模的应用比如签署一个保险协议的主要过程——可以被非开发人员创建查看跟蹤和编辑等工作流的开发人员（或者是传统的NET开发人员或者是领域专家）使用一个类似流图表工具的环境设计工作流这些工作流由一些活动组成这些活动表示过程当中的一个个逻辑步骤这个环境将会随Visual Studio一起被普遍提供但是也可以在一些其他自定义的应用程序中存在同样也允许公司将工作流的设计者完全剥离出传统的程序员工具之外工作流设计的结果就是一个格式化的XML文档或代码然后使用工作流编译器将其编译成一个NET类这个类将由工作流运行时处理运行于各种环境之中包括 ASPNET控制台应用程序或者是一个拥有图形用户接口的应用程序等工作流可以是串行的或是由外界状态改变驱动的甚至可以跨越很长的时间间隔
从事实上看工作流运行时是被设计为易用于各种应用环境和上下文之中一个最直接的想法就是使用一些连接技术将工作流应用于Spring（或其他 JEE容器）中比如可能是工作流运行时支撑Spring容器创建自定义的活动以用于调用Spring中的Bean类执行商业功能也可能是在 Spring的Bean中支撑工作流运行时来执行对Spring接受的远程调用进行响应的功能特别是在第二种情况下终端用户可以设计业务过程并将其执行于传统的企业服务器中同样工作流的狂热爱好者已经描述了工作流可以如何被应用以来结构化ASPNET应用程序中网页的导航这样一种方式不同于Structs的action映射文件在servlet容器中支撑工作流来完成同样的目标是另一种可行的办法同样也在servlet和JSP网页之间提供了一种可见的流而非目前占据此位置的晦涩的XML语法
WPF客户端到Java服务
本节将会描述最后一个但肯定不是最不重要的场景而且它有可能成为将NET和Java在一起使用时最富有挑战的场景在Java强大和可扩展的服务提供的数据模型之上（可能是SpringEJB或一些组合）使用新的WPF技术来提供一个丰富而强大的用户界面WPF所宣称的基于xaml的编程模型标志着相较于近一个时期以来典型的UI编程模型的重大改变而且在许多方面都让人很容易地产生复杂的用户界面这种技术超出了Swing或 SWT目前所能够实现的另外由于xaml是一种基于文本的格式因此可以动态生成XAML并将其下载到客户端执行就像现在的HTML一样
WPF前台与Java后台之间通过WCF进行对话将可能称为一个典型的场景WCF是微软的新的通信管道使所有的分布式通信编程模式成为一个单一的架构除了支持许多最新的WS*规范WCF还通过多种途径提供了用于通信的丰富的可扩展性模型包括通过REST格式（有时称作普通XML或 POX）甚至可能使用其他的通信媒介比如UDPSun通过其Tango项目使得这个办法更加可行作为一种特定的设计目标Tango项目可以与 WCF无缝集成
* * *
不言而喻以上这份列表是很难列出Java和NET之间进行可能的互操作的所有场景的事实上为了让这篇文章处于一个可控的长度在这儿我们忽略了下面几种可能性
*
采用Eclipse的富客户端平台作为客户端要么部署一个通过由DCOM向NET/COM+通信的服务组件要么部署一个WCF服务
*
在一台部署了Excel计算引擎的Windows Server 机器中采用Swing客户端和/或Java Web Start创造一种便携式可下载零部署客户端应用解决方案
*
在一个SWT应用程序中利用DirectX提供本地的D效果（包括音效）
*
使用微软的语音服务器以提供交互式语音识别（IVR）而前台使用一个Swing或JEE应用
等等等等等等
听起来好像这一切都是牵强和不合理的煽情就像在脑海里浮现出那帮拥有大量时间但却没有常识的营销人员所作的事当Java拥有公式引擎时何必使用 Excel？当我们拥有JAXWS时何必使用WCF？当我们拥有JavaD时何必使用WPF？让我们坦然的面对如下事实NET能做的任何事 Java都可以做到反之亦然免得我们因为偏爱某项技术被指责但我们也尤其须要坦白承认的一个事实是两种平台各有特殊的兴趣领域并且它们在各自的领域做得都很好开发人员愿意抛开立场偏见进行开明的讨论并发挥各自平台的优势以导致一些更大的利益或是宽泛地引用卡尔？马克斯的一句名言对每一个项目而言应该根据自己的需要充分发挥其所需平台的能力（ From each platform according to its abilities to each project according to its needs）
