引言
====
两个月前，公司另外一个开发组准备基于 J2EE(BEA WebLogic) 平台来重新开发原有的系统，在选型会上，我就企业开发中可能需要处理的各种问题咨询了 BEA 公司的技术人员，因为我没有基于 J2EE 平台的开发经验，所以只能是针对自己在 .NET 中的开发经验和体会来询问在 J2EE 中是否有类似的基础构件的支持，当然，这毕竟是两个不同的开发平台，不可能有完全一一对应的东西，但是同样都是企业级的开发平台，其实我认为从架构的角度上看，其开发框架应该是大致一样的。以下是我参加那次选型咨询会后得出的一些体会，由于本人对 Java 平台的理解浅薄，多有疏漏和偏颇之处还请读者指正。
1、EJB 对 COM+
EJB 与 COM+ 有太多的相似之处，都是基于特定的二进制协议 RMI 和 DCOM，都是分布式组件技术。正因为他们需要完成同样的功能要求，决定了他们有太多的一样，需要容器管理、上下文状态、事务模型、序列化技术、对象实例管理、线程、远程调用、消息队列、安全与角色 等等，无论是会话Bean还是实体Bean，也不管是BMP或是CMP，都可以在 COM+ 中找到类似的概念。总之，他们就像一对亲兄弟。
EJB 是一种规范一种标准，而COM+，更多人则认为它是一个产品，也许这就是微软给人感觉罢，因为我们可以选择不同的EJB容器服务器产品，有BEA、IBM或者其他开源的，而 COM+ 则只此一家。但事实上 COM/DCOM/COM+ 也是一种规范或标准，就像 EJB 一样，你只要最低限度的实现了 COM+ 规范中的某些接口即可注册成为一个 COM+ 组件，在 Visual Basic 6 中编写一个 COM+ 组件是非常容易的。
2、JDBC 对 ADO
JDBC 和 ADO 有些类似，不过拿它与 ADO.net 来做对比似乎有些不公平，毕竟 ADO.net 是后来者。在数据对象中，我最关注的是它们对数据的处理和缓存方式，长久以来，一直都使用三层/多层的应用架构模式来搭建企业应用，因此对数据集/结果集的处理和远程传输一定是我们首先面临的问题。
在传统的基于 ADO.Recordset 记录集的三层应用中，人们通常通过 DCOM/CORBA 协议来传输这些可持久化的数据对象，数据层在接受到客户端修改后的数据对象后，再通过这些记录集中包含的元数据来映射成相关的SQL操作，在多层架构的企业应用中，这种远程传输、客户端缓存数据集以及断连接的数据操作模式的技术是至关重要的。JDBC 中的 ResultSet 是无法直接做到这点的，这或许也是各种数据处理、映射EJB组件以及类似 Hibernate 这样的技术在 Java 平台中蓬勃发展的缘由罢！
3、O/R Mapping
事实上我不是一个类型化数据对象或对象关系映射（O/R Mapping）技术的支持者，至少在现阶段如此。对于 ObjectSpace（据说在 ADO.net 2 中将发布该技术）或者 Java 中的 Hibernate 始终没什么兴趣，我认为 O/R Mapping 并不如它宣传中的那么美妙，我更愿意使用 ADO.net DataSet 这样的“表模块”【见《企业应用架构模式》 Martin Fowler 著】技术来传递和操作数据，在 O/R Mapping 中通常使用属性来映射字段，他们宣称这样的前期绑定技术可在编译期间就检查出对字段命名的错误和值类型的检测，并可能在 IDE 的开发环境中提供更方便编码的特性（如 列出类成员），但是这会加重开发任务和难度，还可能需要很多这样的映射类来映射和操作数据库中的表，而我更喜欢使用一个通用的数据存储类来提取和存储数据库中各个表，这一切都只需要通过统一的XML（如 ADO.net 的 DataSet）来包装所需的表数据（包括这些表之间的关联、约束等），这样可简化数据存储和映射并提供足够的灵活性。
究竟该选择怎样的数据模型，这并不容易，对这个问题《企业应用架构模式》一书中有专门的讲解（第二章）。“表模块”有较平缓的基于工作量和复杂度之间的平衡度，鉴于“是否应用‘表模块’很大程度上取决于环境对通用记录集结构的支持。如果开发环境拥有大量基于记录集的工具（如 .NET或Visual Studio），则‘表模块’就很有吸引力。”【见《企业应用架构模式》P22】和以往的经验，我在刚开始接触JDBC时则始终纠缠于对“表模块”与其他模式之间的迷惑中，因为我实在不能理解为什么 J2EE 中没有现成的关于“表模块”的标准。在疑惑了几十天之后，我看到了《面向表格编程的力量（Butler介绍）》一文，终于惊叹：原来 Java 阵营对“表模块”模式也是非常感兴趣的！相信这会对推动 Java 应用的开发有非常积极的作用。
4、Web Services/SOAP
微软无疑是 XML 和 Web Services 的鼓吹和大力推广者。有人认为微软对 Web Services 的推崇甚至打压了他们自己的 Remoting 技术的发展，但业界对 Web Services 的前景和支持都是前所未有的统一和力度。基于 XML 规范的 SOAP 协议使大家有了一个更加清晰明确的统一的前景，这无疑是令人振奋和鼓舞的。在对 Web Service 的支持上.NET 拥有无可置疑的优势，无论是对 Web Services 开发效率和扩展性方面都是如此，在微软发布了 WSE(Web Service Enhancement) 2.0 开发包后更加提升了 .NET 在这方面的优势。
在企业应用中对数据对象的远程传递和缓存是所有的基础，这样的数据对象如果是基于 XML 规范无疑是非常有价值的，但遗憾的是，在这个充满利益争夺的商业社会中，无论是 ADO.net 的 DataSet 还是 Java 中的 JDO、Hibernate 在目前都无法互通处理，尽管可能利用 XSLT 来转换，但是建立一个更加统一的沟通标准始终是我们的良好愿望。
5、用户界面与报表
用户界面技术似乎向来都是微软的强项，Java 阵营似乎主要推崇的是浏览器客户端技术，而 .NET 现在更流行和推崇的是胖客户端的 SmartClient 技术，这两种技术各有优缺，但是相对复杂的企业应用我更偏向使用胖客户端的界面技术。事实上，Java 中的 GUI 界面也是越来越好，譬如 OpenOffice 这样的项目就是不错的证明，而 .NET 中的 ASP.net 也是非常有创新的，尤其是 ASP.net 2.0 更是令人充满期待，就这些 .NET 技术的发展来说，微软的速度和力量都是令人尊敬的，而 Java 社区和开源的力量也使他们取得了令人赞叹的进步和成果。
在用户界面技术中，有个非常酷的功能就是“绑定”技术。在 .NET 中你可以轻易的将任何一个对象的某个属性绑定到某个GUI组件的某个属性上，并且您还可以对绑定的过程进行自行转换和表现处理，无需担心多级联绑的数据同步显示等繁琐的细节处理，因为你只需要监侦好数据源即可。在使用“表模块”的数据操作模式中，该绑定技术将大大降低界面处理的复杂度，更令人惊奇的是，我从此不再认为数据操作界面开发是件郁闷冗繁的事了。
在 J2EE 中似乎并没有报表方面的标准。在报表打印方面 Crystal Report 似乎一直都是这两个平台的首选，但是做过 Crystal Report 开发的朋友一定会对 Crystal Report 的产品缺陷和中文支持多有怨言，而微软也一度和 Crystal Report 达成产品捆绑，但事实上微软也一直未放弃自己单独开发报表引擎/服务的努力，但是他在这方面一直没有取得太好的成果，一直到 Microsoft Reporting Service 出现为止，我们大多时候是使用 Crystal Report 来开发制作报表的。Reporting Service 真正令我感到鼓舞的是它的 RDL(Report Definition Language)，希望有一天，我们能通过标准化的基于XML规范的报表定义语言来交换和表现各系统的报表数据！
6、其他
微软总是将设计和实现一手包办并做成产品，对于这些产品也很少公开成技术标准，并尽可能的将这些产品和技术限制在 Windows 平台，这妨碍了其他实现者的加入但却巩固了微软对技术平台的控制，这或许就是微软的战略决策罢。就像 .NET 的宣传口号“一个平台，多种语言”一样，Windows 操作系统始终是他们的核心，相对 Java 的“一种语言，多个平台”而言，很明显这是两种截然不同的战略思想。有人说，现在微软重推的智能客户端(SmartClient)技术是希望借此推广富客户端来达致加强应用对 Windows 操作系统的依赖，不过，对此我并不完全赞成。
谈到.NET，我总是忍不住要关注下 Mono 这个令人激动的开源项目。我越来越渴望能在不同的平台中运行我们的企业应用，而且这也是客户越来越普遍和强烈的要求（政府部门的客户尤甚，在版权控制越来越严格的中国，企业客户也势必要求多些平台选择以降低系统成本），虽然我可以选择 J2EE 这样的平台来开发企业应用以达到跨平台的目的，但是，我对于 .NET 的热爱和迷恋又令我难以抛弃它，就像 Miguel（Miguel de Icaza，是Gnome、Ximian和Mono的创始人之一）说的那样“当 Microsoft 推出.NET，我们对它一见钟情，就启动了Mono”，这种情愫无疑是矛盾和痛苦的，所以 Mono 的出现和正式发布对我们来说是非常令人振奋的！目前，我们首先打算利用 Mono 使我们的企业应用的 WebService 和数据访问层能成功移植到 Linux 上，并且可以支持 Oracle、PostgreSQL 这两种数据库，随着 Mono 的发展，当对 WinForms 的支持基本完成时，那就更棒了！！！而这一切是多么令人期待呵～
最后，我希望本文能尽量避免过多涉及这两个平台的设计开发细节方面的差异（事实上，我也做不到这点。^oo^），也不想看到双方阵营的拥护者就此产生的一些过激的对立情绪。
