[转] J2EE vs .NET (下)
三. 异中有同同中有异
——J2EE与.NET平台体系架构的异同
南京邮电学院 李建忠
中南大学 毕文杰
作为彼此竞争的应用平台，J2EE和.NET开发平台在目标和体系结构上极其相似，但在实现上又完全不同。平台的体系架构是支撑平台的基础，平台各方面的性能也会因平台架构实现的不同而有差异。对两个平台产生至关重要影响的三个方面是：系统平台基础构造、三层/多层体系结构和移植/性能/扩展。J2EE是一个平台规范而非产品，对等而论，在这里述及的.NET也专注于该平台的架构规范，而较少地涉及到具体产品，尽管对.NET而言有时候这方面并不能被区分得很清楚。
类似的平台基础构造
一个平台在语言编译、代码执行、编程支持等基础构造方面往往会对平台的可用性、生产性、移植性等产生重要的影响，也是我们评判一个平台是否适合特定应用的重要依据。J2EE和.NET两个平台在底层的执行引擎都源于托管的虚拟机概念，但.NET的CLR沿着Java虚拟机(JVM)走得更远。CLR在借鉴了JVM的自动垃圾收集、异常处理等机制的同时，又为.NET平台添加了多语言支持、组件自描述等新的特性。
在.NET和 J2EE平台上，程序的编译都经过两个类似的过程。首先特定高级语言编译器将C#（及其他.NET语言）和Java源代码分别翻译成中间语言(IL)和字节代码(ByteCode)。.NET在中间语言设计时通盘考虑了多个主流高级语言，在这一层面实现了.NET平台的跨语言承诺。J2EE的基石是Java语言，它最典型的特征是：一次编写，多次运行。跨平台是J2EE一直引以为豪的关键，这是通过JVM来实现的。
其次，在执行时，中间语言被即时编译器(JIT)编译成特定平台的二进制代码，字节代码则通过JVM解释执行，完成各自语言的指令功能。鉴于微软在“Wintel平台”上的代码优化功底，.NET代码的执行速度较之于Java有明显的优势是不争的事实。但在Unix/Linux平台上，由于.NET迟迟未能实现其跨平台的承诺，J2EE几乎成了惟一的选择，执行效率的比较也就无所谓。在代码执行的同时，通用语言运行时和Java虚拟机也都提出了异常捕捉、类型安全、内存分配、垃圾收集等自动化内存管理工作，大大减轻了现代软件的内存泄漏问题和程序员繁重的负担。
面向对象程序设计在J2EE和.NET平台中都获得了直接的支持，单根继承加多接口实现是它们共有的特征。但在面向对象之外，.NET对现代组件编程提供了直接支持。当然，当下的很多企业中间件都是基于J2EE平台的,只是.NET从设计、编码、配置到运行给予了组件编程更多、更直接的支持。
一个能够为编程提供广泛服务的、可从玫腁PI类库对于现代软件平台非常重要。从基础的集合、字符串操作到企业级的API接口，如JMS、JDBC、JAX、JNDI等，可以看到J2EE在这方面有着非常坚实的结构。微软.NET框架类库也不示弱，提供了从图画、网络、线程到ADO.NET、ADSI、Windows表单、ASP.NET等一系列的API。在这些基础的和企业级的服务上两个平台很难一决高下，而且对功能集合的支持很多时候是一个时间问题，往往是一个平台推出了某一子功能集，另一个平台马上推出类似的功能集。
除去API类库的无缝的功能复用外，对本地平台的调用操作也是值得关注的一点。CLR和Java虚拟机都支持本地方法的调用。在异构平台方面，J2EE更钟情于IIOP（Internet InterORB Protocol），而.NET则使用SOAP。
相同的三层/多层体系
基于三层/多层分布式计算结构已毋庸置疑地成为当今企业应用的主流模式，也是两个平台较量的着力点。
在客户端，表示层负责用户与系统的交互。对于不同的处理要求，.NET和J2EE都提出了基于桌面的应用程序和基于浏览器的Web应用的开发组件：Java Application与Windows表单、Java Servlet/JSP与ASP.NET双双形成犄角之势。但Windows表单依赖微软桌面系统的天然优势，不管在交互速度还是在界面的表现性能上都较Java Application稍胜一筹。Servlet/JSP与ASP.NET是目前企业在“瘦客户端”应用的重点，两者都基于HTTP请求/响应模型，通过HTML浏览器页面完成用户交互。虽然ASP.NET声称在底层通过编译执行获得了相当高的处理速度，以及服务器方控件的浏览器自适应能力，但目前并没有这方面的硬性数据，很难据此而论高下。在缓存、状态优化等方面两者可谓旗鼓相当。另一个和客户端应用相关的技术是ActiveX与Applet，但从目前的趋势来看，它们在两个平台上的地位逐渐边缘化，也不为大多数企业所接受。
在中间层，分布式业务组件负责企业应用的商业逻辑部署。由于这些业务组件经常负责处理数据库连接、网络资源、线程等高昂的资源，所以一直是三层/多层架构的关键和企业应用的核心。J2EE的EJB是一个成熟的、得到业界广泛支持的大型企业级组件框架，而.NET组件则是建立在新型的COM+服务之上，两者在组件与操作系统的交互、客户端资源共享等方面都有很好的支持。EJB的核心是容器，容器是一个为组件提供服务的运行时环境，负责为组件提供诸如事务处理、持久性、安全性、组建状态自动化管理等服务，它分离了商业逻辑和系统底层逻辑，使开发人员的工作大为简化。.NET则通过元数据支持自描述性的组件开发、XCOPY部署以及多版本共存，而无需注册表和描述文件，对企业客户有一定的吸引力。
在后端数据层，两个平台都为数据库连接量身定做了一套数据存取模型：J2EE的JDBC和.NET的ADO.NET。它们在支持传统SQL数据源的同时，也都支持新型的XML数据源。这方面由于更多地涉及到具体的数据库产品，很难说那种数据模型更有优势。
值得指出的是，在打造三层/多层体系结构的同时，Web服务作为新一代企业计算模型也得到了J2EE和.NET平台相当的关注，在后面的文章会有这方面的详细评述。
不同的移植、性能和扩展
在移植性方面，微软通过.NET 通用语言运行时来消除编程语言的差别，而J2EE则通过Java虚拟机来消除平台差别。“选择.NET平台就意味着选择Windows”，这句话至少在可预见的一段时间里仍然是一个基本事实。跨平台是J2EE的一大卖点，也是在选择企业应用开发平台时的一个重要参考因素，几乎所有的主流操作系统都提供了对J2EE的支持。实际上如果要搭建跨Unix、Windows等多个操作系统平台，J2EE平台几乎是惟一的选择。J2EE更关注跨平台而不是跨语言。但微软认为，如果企业的应用都能通过标准协议以Web服务的方式发布，那么平台都是中立的。跨平台甚至是微软所不想的。为了吸引更多的开发者和鼓励广大企业厂商转到.NET平台，微软提出了多语言支持，希望用跨语言的交互性来平衡跨平台的互操作。
性能是J2EE和.NET喋喋不休的话题。二者之间著名的论战是一个关于宠物店的范例应用。宠物店是Sun一度以来作为J2EE典型应用的展示范例，但.NET“自告奋勇”地在自己的平台上实现了该宠物店应用，且声称代码行是J2EE的1/3，效率却是J2EE的30倍。但Sun的理由是这个范例根本不适合用来做性能比较，该范例实现也没有做针对性能的优化，而且指责微软通过后端数据库优化和缓存虚抬了.NET平台的效率。这样的争吵当然不能作为我们判断的依据，目前也没有见到更客观的第三方评测报告。在“Wintel平台”上我们也许没有理由怀疑.NET的性能，而至于非Windows平台，.NET和J2EE也不再具有可比性。
在平台的成熟度方面，两者也有一拼。J2EE在1999年形成了其成熟的架构，并且到今天已经有相当成熟的经过检验的企业应用系统。而.NET究其渊源是源自微软以前开发企业应用程序的平台DNA（Distributed Network Architecture），其中包括了许多已经被证实的技术，并且这些技术已经在产品中得到实现，包括微软的事务服务器、COM+、消息队列、SQL Server数据库等。而对于扩展性，广为业界接受的事实是.NET平台的扩展思想是基于软件的横向扩展，而J2EE平台的扩展思想则是基于硬件的纵向扩展。这也符合微软和Sun各自的产品利益。
J2EE另一个重要特征就是它的架构开放性，它本身是一系列规范，而不是产品，任何符合这一规范的产品都是J2EE兼容的。这使得J2EE从制订之初就得到了广泛的支持。BEA、IBM、Oracle等都相继开发了符合J2EE的应用服务器，它们的产品相互之间甚至可以兼容。而.NET在设计之初就紧紧地把平台规范与产品胶合在一起，虽然.NET架构的一小部分具有开放性（如C#语言、通用语言基础构造CLI 和Web服务标准），但至少目前很难想像会有一个非微软的.NET实现。
四。Web服务谁主沉浮？
■ 柴晓路
现在已经是2002年第二季度，Gartner Group对Web服务发展的预测似乎被产品提供商稍稍延误了，最近微软的.NET Framework及其开发工具VS .NET刚刚正式发布。而作为Web服务世界中另一个重量级角色Sun，也为它的J2EE Framework增添了开发Web服务的强有力的工具包Java Web Services Developer Pack(WSDP)。从2002年起到2005年，Gartner Group所预测的B2C、B2B以及e-Government领域Web服务的开发和部署将会大量依赖J2EE和.NET这两个平台及其上的开发工具。
.NET与J2EE 对Web服务的支持
从.NET和J2EE这两个平台的发展历程来看， .NET从一开始就深深打上了Web服务技术的烙印，在它的市场推广活动中，无时无刻不凸显其作为Web服务的开发和部署平台的特征。可以说，.NET天生就是为Web服务准备的开发和部署平台。相对.NET而言，J2EE是一个比较“老”的东西，最初它是为了将Java平台拓展到企业级应用领域而制订的一个平台框架规范。随着Web服务的兴起和发展，J2EE平台作为一个企业级应用的开发和部署平台，无法回避业界的重大技术革命——Web服务。随着Web服务技术的发展，J2EE也不断地引入了对Web服务的支持。
从服务描述、服务实现和服务的发布、发现与绑定，以及服务的调用和执行这些不同的角度看，J2EE和.NET的支持基本不相上下，惟一的区别可能是.NET的开发工具更为方便一些，集成度更高一些。.NET是一个在J2EE之后出现的平台，所有的重量级技术产品无一例外地都会吸收先前成功者的优点，.NET就大量地吸收了J2EE平台的优点。其中，最重要的一点就是.NET不再完全沿袭微软先前的技术，从.NET开始，其应用不再以本地机器代码运行，而是编译成中间代码，由称为CLR的虚拟机来运行，这样，.NET也具备了跨平台的可能。不过.NET的跨平台特性主要体现在支持多种开发语言上，VB.NET、C#、C++、JScript等都可以被编译成相同的中间代码，使用相同的运行库执行。
第三方厂商的支持
J2EE作为一种开放的规范，从一开始就得到了众多厂商的支持，IBM、BEA、HP、Oracle等在J2EE的实施上都有较大的投入。目前市场上最好的J2EE应用服务器并不是Sun与Netscape合资的iPlanet，而是BEA的WebLogic和IBM的Webshpere。一年一度的JavaONE就有成千上万的开发商参加。由于J2EE是开放的规范框架，任意厂商只要有实力都可以按照规范来开发实现，不同厂商的组件也可以在一起协同使用，当然最关键的是这些参与J2EE的厂商都具有很强的实力。除了微软以外，基本上所有的软件业巨擎都钟情于J2EE。
然而，J2EE虽然是开放的规范，但是它的使用却不是那么开放，每家使用J2EE技术的公司都不得不为此向Sun支付一笔不小的费用。同时也正因为Sun对J2EE规范的独家控制，使得J2EE规范的开发进度缓慢，迄今为止，J2EE规范中并不包含对Web服务的支持，Sun推出的WSDP只是一种插件形式的扩展支持。有消息表明，在今年年底前，Sun和Java领域的其他支持商，包括IBM、Bea、Silverstream等会就J2EE如何支持Web服务达成一致，然而这一切均存在变数，其中的根结就在于Sun对Java技术的独家控制。
同时，由于J2EE对Web服务支持的步履维艰，各大厂商分别自行开发Java平台的Web服务支持，IBM在这个领域的步伐是飞快的，它的WSAD（Webshpere Studio Application Developer）集成了大量自行开发（部分来自于Apache.org，不过这个项目的前身是IBM发起，而后移交给Apache.org）的Web服务组件，业已成为Java领域开发Web服务的最佳开发工具，同时IBM的Websphere也慢慢向Web服务开发部署应用平台的角色转化。
而对于微软的.NET而言，虽然从一开始，微软就以独占、垄断、不开放的形象出现在平台市场上。然而，它的.NET却表现出了前所未有的开放姿态。
.NET的主力开发语言C# 已经提交给 ECMA，开始标准化，ECMA是一个致力于推动行业范围内采用信息和通信技术的非特定供应商的国际标准组织。C#的标准化使希望在任何平台上都可以实现 C# 编程工具的公司能够实现其愿望。微软 还向 ECMA 提交了微软.NET框架的一个子集，叫做CLR（公共语言架构，Common Language Infrastructure）。这将使其他供应商能够在各种平台上实现 CLI，以便用.NET框架提供的基本体系结构模型编写的软件可以在各种平台上用各种工具来创建。美国Ximian公司已于2001年7月启动了一个名为Mono 的开放源码版.NET开发项目，计划内容包括一个C#编译器、与微软的CLI兼容的类库和Linux版CLR编译器。虽然这只是起步，然而谁也不能肯定，它不会像当初的Java那样，从Sun的小玩具，变成了今天如此重要的开发平台。
Web服务规范的控制
由于Web服务的各种技术都是先以规范的形式制订，然后再交付各大开发商进行实施。所以，某个开发商如果从一开始就参与某种Web服务规范的开发，那么它的平台就能够以最快的速度支持这一Web服务规范。在这一点上，微软给人以非常积极进取的印象。在Web服务领域，微软与IBM共同主推了大量的Web服务规范，在一段时间内，两家公司Web服务技术的市场推广活动都是联合举行的，不难看出这两家公司在这个领域背后的战略合作关系。最初的Web服务核心技术SOAP、WSDL主要由这两家公司制订;后来的UDDI是由这两家为首的多家核心企业共同制订;再后来的一些不是核心的Web服务规范，如WS-Inspection、WSFL、WS-Security、WS-Routing、WS-License、WS-Referral等，则完全由这两家来制订，不难看出IBM和微软对于Web服务的贡献以及它们对Web服务规范的控制。
而Sun自从在XML规范的制订中发挥了重要的作用之后，在其后的Internet规范，尤其是Web服务规范的制订中，声音变得非常微弱，而且似乎并没有改善的趋势。最近在Web服务领域中的一件大事是WS-I.org的成立。WS-I.org是为保证Web服务所承诺的互操作性而成立的一个组织，主要工作就是开发保障Web服务互操作性的相关规范，并进行规范实施的测试。WS-I.org的核心成员包括Accenture、BEA、HP、Intel、IBM、Microsoft、Oracle、SAP等，Sun不在其中，甚至都不在非核心成员的列表中。是Sun的发展战略的问题，还是受盈利问题的困扰，我们不得而知，不过我们可以知道的是，Sun再一次在Web服务领域中落后了，由它控制的J2EE规范的状况也就可想而知。
潜在的市场
从技术的发展来看，大型的企业用户或有着成功实施经验的企业用户，并不会因为新技术的推出而盲目地否定旧技术，它们总是在保护投资的前提下，在不推翻现有架构的前提下，有选择地挑选适合的技术。
J2EE已经是一个成熟的、成功的企业级应用解决方案，拥有大量的客户，已经实施了J2EE的企业不太可能在Web服务的时代全面否定J2EE而去接受.NET。.NET是一个全新的架构，虽然它的开发语言中已经包含了诸如VB、C++等传统开发语言，刚刚接触.NET的开发人员会以为能将以前使用VB开发的代码平滑地转移到.NET平台上来。其实不然，VB.NET的语法与VB 6.0已经有了根本性的差别，与其说VB.NET是VB 6.0的升级，不如说VB.NET是C#的Basic版。由于采用了CLI的结构，VB.NET将很难兼容以前的VB 6.0的代码，大量的VB代码无法顺利地转移到.NET上，我们期待着微软能够提供转换程序以实现代码的升级。虽然在源代码级别上的升级变得不是那么容易，不过开发人员仍然可以在.NET平台下，将原有的COM组件进行重新包装，形成 .NET平台下的Web服务组件，而且.NET的整个平台、开发工具的高集成性和友好的开发环境还是会给开发人员留下深刻印象。在Java领域中，无论是Borland的JBuilder 6，还是Sun的Forte for Java，或是IBM的WebShpere Studio Application Developer、VisualAge for Java都无法达到VS .NET的生产效率。开发工具是.NET的一大优势，同时.NET平台对Web服务规范的支持力度也仅有IBM的J2EE平台能够与之相媲美。
因此，笔者认为在大型企业级应用场合，如果已经采用了J2EE架构，应该会在Web服务的时代继续使用J2EE架构。而原先就是采用微软架构的，出于技术延续性的考虑，大多数仍然会选用微软的.NET。那些采用其他技术的企业级应用则会在开发效率、安全性、可靠性、维护代价等不同指标上对两种架构进行考察，应该说机会是均等的，J2EE强在有大量的应用实例，而.NET强在整合集成的优秀开发部署环境。
在中小级别的应用领域，J2EE的占有率优势不再那么明显，一方面，长期以来微软专长于这个领域;另一方面，Java解决方案已经是如此地深入人心，即使是中小企业也会考虑J2EE架构，在这个领域，两者平分秋色。
而在桌面应用（Web服务客户端）领域，除了一些管理客户端会采用Java开发以外，绝大多数的应用毫无疑问地会在微软平台上开发和部署。
谁主沉浮
下面这张表格概括了对两者的比较：
比较项目? J2EE? .NET?
对Web服务的支持?
服务描述? 好? 好?
服务实现? 好? 很好?
服务发布、发现与绑定? 好? 很好?
服务调用和执行? 好? 好?
第三方支持?
平台提供商? 很好? 有待考察?
软件开发商? 很好? 好?
对Web服务规范的控制? 情况复杂(注）? 很好?
市场前景?
企业级大型应用? 很好? 一般?
中小级别应用? 好? 好?
桌面应用? 差? 很好?
注：J2EE的控制者Sun对Web服务规范几乎没有什么控制能力，然而Sun在J2EE上的合作伙伴IBM等对Web服务规范却具备强大的控制力，所以表格中显示“情况复杂”。
从表格中，不难看出两者是旗鼓相当的对手，现在就断言谁主沉浮还为时过早。应该说，J2EE目前需要做的是尽快真正将Web服务规范融入到J2EE规范中去，从规范出发统一对Web服务的支持。而.NET迫切需要进行的则是加大平台的开放力度，争取改善微软在用户心目中独断、单方控制、不开放的形象。
在未来相当长时期内，J2EE和.NET都将是企业构建应用系统的重要选择，两个平台将相互共存，两者本身也在不断地相互借鉴和完善，并且有望通过Web服务实现互操作。真正的市场，正是需要强大的竞争者之间的较量，这样用户才能得到最好的技术和解决方案。
小资料·
Gartner Group对未来Web服务发展状况的预测：
2001年，Web服务的架构平台、开发工具将基本被各大开发商开发完毕。开发人员能够购买到这些面向服务的开发工具，同时将开始构建实际使用的Web服务。
2002年，商业Web服务将大量出现，大量的面向消费者的B2C Web服务将投入使用。
2003年，UDDI注册中心随着Web服务的发展，将变得越来越重要，其中的商业数据也越来越丰富。私有的UDDI注册中心将被投入使用，以支持内部服务信息的交换。而政府的Web服务应用也将不断出现。
2004年，各类企业将会普遍接受基于Web服务的商务应用模式，而服务集中的计算模式将进入青年期。私有的UDDI注册中心仍然在各类应用中处于优势地位，新的赢利模式和商业渠道将到处可见。40％的金融财务服务事务将使用Web服务模式，而35%的在线政府服务将以Web服务的形式提供。
2005年，公共的UDDI注册中心作为公共商务信息的交换机制将大量应用。动态服务同样将大量投入使用。
——J2EE与.NET平台体系架构的异同
南京邮电学院 李建忠
中南大学 毕文杰
作为彼此竞争的应用平台，J2EE和.NET开发平台在目标和体系结构上极其相似，但在实现上又完全不同。平台的体系架构是支撑平台的基础，平台各方面的性能也会因平台架构实现的不同而有差异。对两个平台产生至关重要影响的三个方面是：系统平台基础构造、三层/多层体系结构和移植/性能/扩展。J2EE是一个平台规范而非产品，对等而论，在这里述及的.NET也专注于该平台的架构规范，而较少地涉及到具体产品，尽管对.NET而言有时候这方面并不能被区分得很清楚。
类似的平台基础构造
一个平台在语言编译、代码执行、编程支持等基础构造方面往往会对平台的可用性、生产性、移植性等产生重要的影响，也是我们评判一个平台是否适合特定应用的重要依据。J2EE和.NET两个平台在底层的执行引擎都源于托管的虚拟机概念，但.NET的CLR沿着Java虚拟机(JVM)走得更远。CLR在借鉴了JVM的自动垃圾收集、异常处理等机制的同时，又为.NET平台添加了多语言支持、组件自描述等新的特性。
在.NET和 J2EE平台上，程序的编译都经过两个类似的过程。首先特定高级语言编译器将C#（及其他.NET语言）和Java源代码分别翻译成中间语言(IL)和字节代码(ByteCode)。.NET在中间语言设计时通盘考虑了多个主流高级语言，在这一层面实现了.NET平台的跨语言承诺。J2EE的基石是Java语言，它最典型的特征是：一次编写，多次运行。跨平台是J2EE一直引以为豪的关键，这是通过JVM来实现的。
其次，在执行时，中间语言被即时编译器(JIT)编译成特定平台的二进制代码，字节代码则通过JVM解释执行，完成各自语言的指令功能。鉴于微软在“Wintel平台”上的代码优化功底，.NET代码的执行速度较之于Java有明显的优势是不争的事实。但在Unix/Linux平台上，由于.NET迟迟未能实现其跨平台的承诺，J2EE几乎成了惟一的选择，执行效率的比较也就无所谓。在代码执行的同时，通用语言运行时和Java虚拟机也都提出了异常捕捉、类型安全、内存分配、垃圾收集等自动化内存管理工作，大大减轻了现代软件的内存泄漏问题和程序员繁重的负担。
面向对象程序设计在J2EE和.NET平台中都获得了直接的支持，单根继承加多接口实现是它们共有的特征。但在面向对象之外，.NET对现代组件编程提供了直接支持。当然，当下的很多企业中间件都是基于J2EE平台的,只是.NET从设计、编码、配置到运行给予了组件编程更多、更直接的支持。
一个能够为编程提供广泛服务的、可从玫腁PI类库对于现代软件平台非常重要。从基础的集合、字符串操作到企业级的API接口，如JMS、JDBC、JAX、JNDI等，可以看到J2EE在这方面有着非常坚实的结构。微软.NET框架类库也不示弱，提供了从图画、网络、线程到ADO.NET、ADSI、Windows表单、ASP.NET等一系列的API。在这些基础的和企业级的服务上两个平台很难一决高下，而且对功能集合的支持很多时候是一个时间问题，往往是一个平台推出了某一子功能集，另一个平台马上推出类似的功能集。
除去API类库的无缝的功能复用外，对本地平台的调用操作也是值得关注的一点。CLR和Java虚拟机都支持本地方法的调用。在异构平台方面，J2EE更钟情于IIOP（Internet InterORB Protocol），而.NET则使用SOAP。
相同的三层/多层体系
基于三层/多层分布式计算结构已毋庸置疑地成为当今企业应用的主流模式，也是两个平台较量的着力点。
在客户端，表示层负责用户与系统的交互。对于不同的处理要求，.NET和J2EE都提出了基于桌面的应用程序和基于浏览器的Web应用的开发组件：Java Application与Windows表单、Java Servlet/JSP与ASP.NET双双形成犄角之势。但Windows表单依赖微软桌面系统的天然优势，不管在交互速度还是在界面的表现性能上都较Java Application稍胜一筹。Servlet/JSP与ASP.NET是目前企业在“瘦客户端”应用的重点，两者都基于HTTP请求/响应模型，通过HTML浏览器页面完成用户交互。虽然ASP.NET声称在底层通过编译执行获得了相当高的处理速度，以及服务器方控件的浏览器自适应能力，但目前并没有这方面的硬性数据，很难据此而论高下。在缓存、状态优化等方面两者可谓旗鼓相当。另一个和客户端应用相关的技术是ActiveX与Applet，但从目前的趋势来看，它们在两个平台上的地位逐渐边缘化，也不为大多数企业所接受。
在中间层，分布式业务组件负责企业应用的商业逻辑部署。由于这些业务组件经常负责处理数据库连接、网络资源、线程等高昂的资源，所以一直是三层/多层架构的关键和企业应用的核心。J2EE的EJB是一个成熟的、得到业界广泛支持的大型企业级组件框架，而.NET组件则是建立在新型的COM+服务之上，两者在组件与操作系统的交互、客户端资源共享等方面都有很好的支持。EJB的核心是容器，容器是一个为组件提供服务的运行时环境，负责为组件提供诸如事务处理、持久性、安全性、组建状态自动化管理等服务，它分离了商业逻辑和系统底层逻辑，使开发人员的工作大为简化。.NET则通过元数据支持自描述性的组件开发、XCOPY部署以及多版本共存，而无需注册表和描述文件，对企业客户有一定的吸引力。
在后端数据层，两个平台都为数据库连接量身定做了一套数据存取模型：J2EE的JDBC和.NET的ADO.NET。它们在支持传统SQL数据源的同时，也都支持新型的XML数据源。这方面由于更多地涉及到具体的数据库产品，很难说那种数据模型更有优势。
值得指出的是，在打造三层/多层体系结构的同时，Web服务作为新一代企业计算模型也得到了J2EE和.NET平台相当的关注，在后面的文章会有这方面的详细评述。
不同的移植、性能和扩展
在移植性方面，微软通过.NET 通用语言运行时来消除编程语言的差别，而J2EE则通过Java虚拟机来消除平台差别。“选择.NET平台就意味着选择Windows”，这句话至少在可预见的一段时间里仍然是一个基本事实。跨平台是J2EE的一大卖点，也是在选择企业应用开发平台时的一个重要参考因素，几乎所有的主流操作系统都提供了对J2EE的支持。实际上如果要搭建跨Unix、Windows等多个操作系统平台，J2EE平台几乎是惟一的选择。J2EE更关注跨平台而不是跨语言。但微软认为，如果企业的应用都能通过标准协议以Web服务的方式发布，那么平台都是中立的。跨平台甚至是微软所不想的。为了吸引更多的开发者和鼓励广大企业厂商转到.NET平台，微软提出了多语言支持，希望用跨语言的交互性来平衡跨平台的互操作。
性能是J2EE和.NET喋喋不休的话题。二者之间著名的论战是一个关于宠物店的范例应用。宠物店是Sun一度以来作为J2EE典型应用的展示范例，但.NET“自告奋勇”地在自己的平台上实现了该宠物店应用，且声称代码行是J2EE的1/3，效率却是J2EE的30倍。但Sun的理由是这个范例根本不适合用来做性能比较，该范例实现也没有做针对性能的优化，而且指责微软通过后端数据库优化和缓存虚抬了.NET平台的效率。这样的争吵当然不能作为我们判断的依据，目前也没有见到更客观的第三方评测报告。在“Wintel平台”上我们也许没有理由怀疑.NET的性能，而至于非Windows平台，.NET和J2EE也不再具有可比性。
在平台的成熟度方面，两者也有一拼。J2EE在1999年形成了其成熟的架构，并且到今天已经有相当成熟的经过检验的企业应用系统。而.NET究其渊源是源自微软以前开发企业应用程序的平台DNA（Distributed Network Architecture），其中包括了许多已经被证实的技术，并且这些技术已经在产品中得到实现，包括微软的事务服务器、COM+、消息队列、SQL Server数据库等。而对于扩展性，广为业界接受的事实是.NET平台的扩展思想是基于软件的横向扩展，而J2EE平台的扩展思想则是基于硬件的纵向扩展。这也符合微软和Sun各自的产品利益。
J2EE另一个重要特征就是它的架构开放性，它本身是一系列规范，而不是产品，任何符合这一规范的产品都是J2EE兼容的。这使得J2EE从制订之初就得到了广泛的支持。BEA、IBM、Oracle等都相继开发了符合J2EE的应用服务器，它们的产品相互之间甚至可以兼容。而.NET在设计之初就紧紧地把平台规范与产品胶合在一起，虽然.NET架构的一小部分具有开放性（如C#语言、通用语言基础构造CLI 和Web服务标准），但至少目前很难想像会有一个非微软的.NET实现。
四。Web服务谁主沉浮？
■ 柴晓路
现在已经是2002年第二季度，Gartner Group对Web服务发展的预测似乎被产品提供商稍稍延误了，最近微软的.NET Framework及其开发工具VS .NET刚刚正式发布。而作为Web服务世界中另一个重量级角色Sun，也为它的J2EE Framework增添了开发Web服务的强有力的工具包Java Web Services Developer Pack(WSDP)。从2002年起到2005年，Gartner Group所预测的B2C、B2B以及e-Government领域Web服务的开发和部署将会大量依赖J2EE和.NET这两个平台及其上的开发工具。
.NET与J2EE 对Web服务的支持
从.NET和J2EE这两个平台的发展历程来看， .NET从一开始就深深打上了Web服务技术的烙印，在它的市场推广活动中，无时无刻不凸显其作为Web服务的开发和部署平台的特征。可以说，.NET天生就是为Web服务准备的开发和部署平台。相对.NET而言，J2EE是一个比较“老”的东西，最初它是为了将Java平台拓展到企业级应用领域而制订的一个平台框架规范。随着Web服务的兴起和发展，J2EE平台作为一个企业级应用的开发和部署平台，无法回避业界的重大技术革命——Web服务。随着Web服务技术的发展，J2EE也不断地引入了对Web服务的支持。
从服务描述、服务实现和服务的发布、发现与绑定，以及服务的调用和执行这些不同的角度看，J2EE和.NET的支持基本不相上下，惟一的区别可能是.NET的开发工具更为方便一些，集成度更高一些。.NET是一个在J2EE之后出现的平台，所有的重量级技术产品无一例外地都会吸收先前成功者的优点，.NET就大量地吸收了J2EE平台的优点。其中，最重要的一点就是.NET不再完全沿袭微软先前的技术，从.NET开始，其应用不再以本地机器代码运行，而是编译成中间代码，由称为CLR的虚拟机来运行，这样，.NET也具备了跨平台的可能。不过.NET的跨平台特性主要体现在支持多种开发语言上，VB.NET、C#、C++、JScript等都可以被编译成相同的中间代码，使用相同的运行库执行。
第三方厂商的支持
J2EE作为一种开放的规范，从一开始就得到了众多厂商的支持，IBM、BEA、HP、Oracle等在J2EE的实施上都有较大的投入。目前市场上最好的J2EE应用服务器并不是Sun与Netscape合资的iPlanet，而是BEA的WebLogic和IBM的Webshpere。一年一度的JavaONE就有成千上万的开发商参加。由于J2EE是开放的规范框架，任意厂商只要有实力都可以按照规范来开发实现，不同厂商的组件也可以在一起协同使用，当然最关键的是这些参与J2EE的厂商都具有很强的实力。除了微软以外，基本上所有的软件业巨擎都钟情于J2EE。
然而，J2EE虽然是开放的规范，但是它的使用却不是那么开放，每家使用J2EE技术的公司都不得不为此向Sun支付一笔不小的费用。同时也正因为Sun对J2EE规范的独家控制，使得J2EE规范的开发进度缓慢，迄今为止，J2EE规范中并不包含对Web服务的支持，Sun推出的WSDP只是一种插件形式的扩展支持。有消息表明，在今年年底前，Sun和Java领域的其他支持商，包括IBM、Bea、Silverstream等会就J2EE如何支持Web服务达成一致，然而这一切均存在变数，其中的根结就在于Sun对Java技术的独家控制。
同时，由于J2EE对Web服务支持的步履维艰，各大厂商分别自行开发Java平台的Web服务支持，IBM在这个领域的步伐是飞快的，它的WSAD（Webshpere Studio Application Developer）集成了大量自行开发（部分来自于Apache.org，不过这个项目的前身是IBM发起，而后移交给Apache.org）的Web服务组件，业已成为Java领域开发Web服务的最佳开发工具，同时IBM的Websphere也慢慢向Web服务开发部署应用平台的角色转化。
而对于微软的.NET而言，虽然从一开始，微软就以独占、垄断、不开放的形象出现在平台市场上。然而，它的.NET却表现出了前所未有的开放姿态。
.NET的主力开发语言C# 已经提交给 ECMA，开始标准化，ECMA是一个致力于推动行业范围内采用信息和通信技术的非特定供应商的国际标准组织。C#的标准化使希望在任何平台上都可以实现 C# 编程工具的公司能够实现其愿望。微软 还向 ECMA 提交了微软.NET框架的一个子集，叫做CLR（公共语言架构，Common Language Infrastructure）。这将使其他供应商能够在各种平台上实现 CLI，以便用.NET框架提供的基本体系结构模型编写的软件可以在各种平台上用各种工具来创建。美国Ximian公司已于2001年7月启动了一个名为Mono 的开放源码版.NET开发项目，计划内容包括一个C#编译器、与微软的CLI兼容的类库和Linux版CLR编译器。虽然这只是起步，然而谁也不能肯定，它不会像当初的Java那样，从Sun的小玩具，变成了今天如此重要的开发平台。
Web服务规范的控制
由于Web服务的各种技术都是先以规范的形式制订，然后再交付各大开发商进行实施。所以，某个开发商如果从一开始就参与某种Web服务规范的开发，那么它的平台就能够以最快的速度支持这一Web服务规范。在这一点上，微软给人以非常积极进取的印象。在Web服务领域，微软与IBM共同主推了大量的Web服务规范，在一段时间内，两家公司Web服务技术的市场推广活动都是联合举行的，不难看出这两家公司在这个领域背后的战略合作关系。最初的Web服务核心技术SOAP、WSDL主要由这两家公司制订;后来的UDDI是由这两家为首的多家核心企业共同制订;再后来的一些不是核心的Web服务规范，如WS-Inspection、WSFL、WS-Security、WS-Routing、WS-License、WS-Referral等，则完全由这两家来制订，不难看出IBM和微软对于Web服务的贡献以及它们对Web服务规范的控制。
而Sun自从在XML规范的制订中发挥了重要的作用之后，在其后的Internet规范，尤其是Web服务规范的制订中，声音变得非常微弱，而且似乎并没有改善的趋势。最近在Web服务领域中的一件大事是WS-I.org的成立。WS-I.org是为保证Web服务所承诺的互操作性而成立的一个组织，主要工作就是开发保障Web服务互操作性的相关规范，并进行规范实施的测试。WS-I.org的核心成员包括Accenture、BEA、HP、Intel、IBM、Microsoft、Oracle、SAP等，Sun不在其中，甚至都不在非核心成员的列表中。是Sun的发展战略的问题，还是受盈利问题的困扰，我们不得而知，不过我们可以知道的是，Sun再一次在Web服务领域中落后了，由它控制的J2EE规范的状况也就可想而知。
潜在的市场
从技术的发展来看，大型的企业用户或有着成功实施经验的企业用户，并不会因为新技术的推出而盲目地否定旧技术，它们总是在保护投资的前提下，在不推翻现有架构的前提下，有选择地挑选适合的技术。
J2EE已经是一个成熟的、成功的企业级应用解决方案，拥有大量的客户，已经实施了J2EE的企业不太可能在Web服务的时代全面否定J2EE而去接受.NET。.NET是一个全新的架构，虽然它的开发语言中已经包含了诸如VB、C++等传统开发语言，刚刚接触.NET的开发人员会以为能将以前使用VB开发的代码平滑地转移到.NET平台上来。其实不然，VB.NET的语法与VB 6.0已经有了根本性的差别，与其说VB.NET是VB 6.0的升级，不如说VB.NET是C#的Basic版。由于采用了CLI的结构，VB.NET将很难兼容以前的VB 6.0的代码，大量的VB代码无法顺利地转移到.NET上，我们期待着微软能够提供转换程序以实现代码的升级。虽然在源代码级别上的升级变得不是那么容易，不过开发人员仍然可以在.NET平台下，将原有的COM组件进行重新包装，形成 .NET平台下的Web服务组件，而且.NET的整个平台、开发工具的高集成性和友好的开发环境还是会给开发人员留下深刻印象。在Java领域中，无论是Borland的JBuilder 6，还是Sun的Forte for Java，或是IBM的WebShpere Studio Application Developer、VisualAge for Java都无法达到VS .NET的生产效率。开发工具是.NET的一大优势，同时.NET平台对Web服务规范的支持力度也仅有IBM的J2EE平台能够与之相媲美。
因此，笔者认为在大型企业级应用场合，如果已经采用了J2EE架构，应该会在Web服务的时代继续使用J2EE架构。而原先就是采用微软架构的，出于技术延续性的考虑，大多数仍然会选用微软的.NET。那些采用其他技术的企业级应用则会在开发效率、安全性、可靠性、维护代价等不同指标上对两种架构进行考察，应该说机会是均等的，J2EE强在有大量的应用实例，而.NET强在整合集成的优秀开发部署环境。
在中小级别的应用领域，J2EE的占有率优势不再那么明显，一方面，长期以来微软专长于这个领域;另一方面，Java解决方案已经是如此地深入人心，即使是中小企业也会考虑J2EE架构，在这个领域，两者平分秋色。
而在桌面应用（Web服务客户端）领域，除了一些管理客户端会采用Java开发以外，绝大多数的应用毫无疑问地会在微软平台上开发和部署。
谁主沉浮
下面这张表格概括了对两者的比较：
比较项目? J2EE? .NET?
对Web服务的支持?
服务描述? 好? 好?
服务实现? 好? 很好?
服务发布、发现与绑定? 好? 很好?
服务调用和执行? 好? 好?
第三方支持?
平台提供商? 很好? 有待考察?
软件开发商? 很好? 好?
对Web服务规范的控制? 情况复杂(注）? 很好?
市场前景?
企业级大型应用? 很好? 一般?
中小级别应用? 好? 好?
桌面应用? 差? 很好?
注：J2EE的控制者Sun对Web服务规范几乎没有什么控制能力，然而Sun在J2EE上的合作伙伴IBM等对Web服务规范却具备强大的控制力，所以表格中显示“情况复杂”。
从表格中，不难看出两者是旗鼓相当的对手，现在就断言谁主沉浮还为时过早。应该说，J2EE目前需要做的是尽快真正将Web服务规范融入到J2EE规范中去，从规范出发统一对Web服务的支持。而.NET迫切需要进行的则是加大平台的开放力度，争取改善微软在用户心目中独断、单方控制、不开放的形象。
在未来相当长时期内，J2EE和.NET都将是企业构建应用系统的重要选择，两个平台将相互共存，两者本身也在不断地相互借鉴和完善，并且有望通过Web服务实现互操作。真正的市场，正是需要强大的竞争者之间的较量，这样用户才能得到最好的技术和解决方案。
小资料·
Gartner Group对未来Web服务发展状况的预测：
2001年，Web服务的架构平台、开发工具将基本被各大开发商开发完毕。开发人员能够购买到这些面向服务的开发工具，同时将开始构建实际使用的Web服务。
2002年，商业Web服务将大量出现，大量的面向消费者的B2C Web服务将投入使用。
2003年，UDDI注册中心随着Web服务的发展，将变得越来越重要，其中的商业数据也越来越丰富。私有的UDDI注册中心将被投入使用，以支持内部服务信息的交换。而政府的Web服务应用也将不断出现。
2004年，各类企业将会普遍接受基于Web服务的商务应用模式，而服务集中的计算模式将进入青年期。私有的UDDI注册中心仍然在各类应用中处于优势地位，新的赢利模式和商业渠道将到处可见。40％的金融财务服务事务将使用Web服务模式，而35%的在线政府服务将以Web服务的形式提供。
2005年，公共的UDDI注册中心作为公共商务信息的交换机制将大量应用。动态服务同样将大量投入使用。
Author: orangelizq
email: [email protected]
|
|
|
