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

　　当然，目前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？尽管可能不需要这样做。

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

　　* * * 
Office客户端，J2EE服务器 

* 

　　* 

　　* 

　　* 

　　Office同样为那些使用了纲领性元素的组件和文档提供了一些部署的支持，因此在很多情况下，在这些组件内进行功能的升级就像到一个共享下载服务器发布一些东西一样简单。显然，一个主要的考虑是使用Office将出现许可费带来的成本，但幸运的是，大多数商业环境应该都已经部署了Office环境，减少了显着增加的费用。

　　Spring和J2EE容器中的Windwos工作流 

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

　　WPF客户端到Java服务 

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

　　* * * 
* 
* 
* 
*