J2EE VS .NET

看到这个标题，也许会有人表示疑惑，J2EE和.NET并不在一个层次上，怎么能将它们放在一起呢?需要指出的是，通常所说的.NET包含了一个相当广泛的产品家族，包括开发平台、操作系统、服务器、终端设备等，此外还包括服务平台。开发平台只是整个.NET战略中的一部分，所以确切地说，放在这里的.NET应该算是.NET开发平台。

　　随着三层/多层企业信息系统结构的深度发展和下一代分布式计算模型Web 服务的出现，企业应用中关于平台、框架、语言的竞争也愈演愈烈。J2EE平台在过去几年里一直引领着企业应用的潮流，但最近微软强力推出的.NET平台也开始吸引着众多IT企业和开发人员的注意力，向J2EE平台提出了强有力的挑战。企业应用领域的技术对抗也因此拉开了架势。

　　需要强调的是，.NET是战略产品，而J2EE是描述产品的标准，现在有很多符合J2EE标准的产品。在可以预见的未来，它们都将是构建企业信息系统应用的基础性平台，尤其是开发和部署Web服务的重要平台。

　　尽管可以同时使用几种系统平台和语言，但对于企业来说，还需要选择一个战略性的平台来实现数据的无缝集成，加速企业应用的部署。而要做出正确的选择，首先需要充分了解两个平台的特点和优势。本期专题将为您细说J2EE和.NET。

　　一、群力所至的J2EE

　　二、.NET开发平台留住Windows开发者

　　三、 J2EE与.NET平台体系架构的异同

　　四、 J2EE vs .NET：Web服务谁主沉浮?

　　一、群力所至的J2EE

　　中南大学 罗新星 毕文杰

　　企业应用系统的开发一直面临着重大挑战：一方面，企业应用系统面对的是一个异构的分布式环境，它必须支持与已有系统的集成性和与其他系统的互操作性;另一方面，作为为客户、合作伙伴和企业内部提供信息服务的平台，企业系统还必须具有高可用性、安全性、可靠性和可伸缩性。这些要求再加上复杂多变的用户需求和不断伸缩的交付时间，使得企业系统的开发越来越困难。开发商和广大程序员一直在努力推动和殷切期待一个成熟、标准的企业平台来简化和规范企业系统的开发和部署。Java技术的出现，尤其是J2EE(Java 2 Platform Enterprise Edition)平台的推出正是这种努力的结果，也使得企业系统的开发由此变得更加快速和方便。需要指出的是，J2EE本身是一个标准，它为不同厂商创建平台产品提供了标准，使不同J2EE平台产品之间的交互成为可能。

　　J2EE旅程

　　Java于1996年由Sun公司推出，当时它的主要用途是制作产生动态网页的Applet。后来，人们发现Java的“一次开发，多次运行”、纯面向对象的特性、垃圾回收机制和内置的安全特别适合于开发企业应用系统。于是，企业应用开发商纷纷在Java标准版的基础上各自扩展出许多企业应用API，其结果导致基于Java的企业应用呈爆炸式增长。但是各企业系统API之间又不能相互兼容，破坏了Java的平台独立性。鉴于此，Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商于1998年共同制订了一个基于Java组件技术的企业应用系统开发规范，该规范定义了一个多层企业信息系统的标准平台，旨在简化和规范企业应用系统的开发和部署。这一规范和其定义的平台就构成了J2EE。目前J2EE的最新版本是J2EE 1.3。需要注意的是，J2EE本身是一个标准，而不是一个现成的产品(虽然现在有很多符合J2EE标准的产品)，它由以下几个部分组成：

　　J2EE规范。该规范定义了J2EE平台的体系结构、平台角色及J2EE中每种服务和核心API的实现要求。它是J2EE应用服务器开发商的大纲。

　　J2EE兼容性测试站点。Sun公司提供的一个测试J2EE应用服务器是否符合J2EE规范的站点，对通过该站点测试的产品，Sun公司将发放兼容性证书。

　　J2EE参考实现。即J2EE SDK，它既是Sun公司自己对J2EE规范的一个非商业性实现，又是为开发基于J2EE企业级应用系统原型提供的一个免费的底层开发环境。

　　J2EE实施指南。即BluePrints文档，该文档通过实例来指导开发人员如何去开发一个基于J2EE的多层企业应用系统。

　　组件-容器 搭建体系架构

　　J2EE规范定义了一个基于组件的多层企业应用系统开发平台，其逻辑结构如图1所示。图中的椭圆形表示组件，大矩形表示容器，包含向下文字的小矩形表示API，箭头表示访问，箭头线上的文字表示相应的协议。

　　J2EE是一个基于组件-容器模型的系统平台，其核心概念是容器。容器是指为特定组件提供服务的一个标准化的运行时环境，Java虚拟机就是一个典型的容器。组件是一个可以部署的程序单元，它以某种方式运行在容器中，容器封装了J2EE底层的API，为组件提供事务处理、数据访问、安全性、持久性等服务。在J2EE中组件和组件之间并不直接访问，而是通过容器提供的协议和方法来相互调用。组件和容器间的关系通过“协议”来定义。容器的底层是J2EE服务器，它为容器提供J2EE中定义的各种服务和API。一个J2EE服务器(也叫J2EE应用服务器)可以支持一种或多种容器。在图1中，你可能已经注意到每个容器的服务包括两部分：J2SE(Java 2 Platform Standard Edition)和一组扩展的服务。这是因为J2EE是以Java标准版为基础的，各容器在J2SE之上再根据需要提供一些扩展的服务，如目录服务、事务管理、数据访问、消息机制、安全性等。

　　J2ee的核心——EJB

　　J2EE定义了四种组件：Applet组件、Application客户组件、Web组件及EJB(Enterprise JavaBeans)组件。其中Applet和Application客户组件在客户端运行，J2EE通过Java插件为Applet提供运行环境，Application客户的容器就是本地Java虚拟机。Web及EJB组件在服务端运行。J2EE中包含两种Web组件：JSP和Servlet。它们是Web服务器的功能扩展，都能生成动态Web页面。不同的是JSP是将Java代码嵌入到HTML中，服务器负责解释执行，生成结果返回用户(与ASP技术相似)。而Servlet是单独的Java类，它动态生成HTML文件返回给客户。Web组件的容器比较典型的就是基于Java的Web服务器。

　　EJB是J2EE平台的核心，也是J2EE得到业界广泛关注和支持的主要原因。我们知道，J2EE的一个主要目的就是简化企业应用系统的开发，使程序员将主要精力放在商业逻辑的开发上。EJB正是基于这种思想的服务器端技术，它本身也是一种规范，该规范定义了一个可重用的组件框架来实现分布式的、面向对象的商业逻辑。EJB的核心思想是将商业逻辑与底层的系统逻辑分开，使开发者只需关心商业逻辑，而由EJB容器实现目录服务、事务处理、持久性、安全性等底层系统逻辑。

　　一个可部署的EJB组件包含3个部分：

　　Remote 接口 Remote接口定义EJB组件中提供的可供用户调用的方法，也就是通常所说的实现商业逻辑的函数或过程(如计算商品价格的函数)，以供远程客户端调用。在EJB组件部署到容器的时候，容器会自动生成Remote接口相应的实例，即EJB对象，它负责代理用户的调用请求。

　　Home接口 Home接口定义一组方法来创建新的EJB对象，查找、定位和清除已有的EJB对象。在EJB组件部署时容器也会自动生成相应的Home对象，该对象负责查找和创建EJB对象，返回EJB对象的引用给客户;用户利用该引用调用EJB组件的方法，得到结果;最后Home对象清除EJB对象。我们可以形象地称Home接口为EJB对象的工厂。

　　Enterprise Beans类 Enterprise Beans类是商业逻辑的具体实现类。其可供用户调用的方法在Remote接口中定义。根据功能不同，EJB 2.0规范中定义了三种Enterprise Beans:会话Beans(Session Beans)、实体Beans(Entity Beans)和消息驱动Beans(Message-driven Beans)。

　　会话Beans分无状态和有状态两种。一般无状态的会话Beans模拟商业逻辑，比如计算价格等。有状态的会话Beans通常模拟一个客户会话，它会临时保存客户信息，根据客户要求调用其他Beans来存取数据。两种会话Beans都不保存状态信息或数据，当客户断开连接或服务器关闭时，会话Beans也随之消失。一个会话Beans的典型例子是网站上的购物车。

　　实体Beans模拟商业数据，它表示一个数据存储，可以是状态信息或数据库中的一条纪录。实体Beans在客户断开连接或服务器关闭后，仍有服务保证其数据得以保存。一个实体Beans的典型例子就是客户账号信息。

　　消息驱动Beans在行为上很像会话Beans。不同的是仅在需要向这些Beans发送消息时才调用消息驱动Beans,比如在需要的时候发送用户确认信息等。

　　另外，在提交和部署EJB组件时，还需要两个文件：部署描述文件，容器根据该文件来部署Enterprise Beans，提供所要求的服务;EJB jar文件，它是提交给EJB容器的一个部署单元，容器(应用服务器)在部署时解开它，装入Enterprise Beans。

　　EJB容器非常复杂，一般由专业的J2EE应用服务器开发商提供，比较流行的EJB容器由IBM的WebShpere、BEA公司的WebLogic Server、Sun公司的iPlant等应用服务器提供。EJB容器除了为EJB提供事务处理、目录服务、持久性管理和安全性服务外，还负责EJB的部署、发布和生命周期管理。

　　平台标准服务

　　服务是组件和容器之间，以及容器和J2EE服务器之间的接口，在实现层面上它就是一系列API和协议。J2EE平台定义了一组标准的服务，其中有些服务是由J2SE提供的，有些则是J2EE对Java的扩展。

　　目录服务　JNDI(Java Name and Directory) API为应用程序提供了一个统一的接口来完成标准的目录操作，由于JNDI是独立于目录协议的，应用程序可以用它访问各种目录服务，如LDAP、NDS、DNS等。

　　数据访问 JDBC(Java Database Connectivity) API为访问不同类型的数据库提供了统一的途径，屏蔽了不同数据库的细节，具有平台无关性。J2EE平台除了要求核心的JDBC API(包含在J2SE中)外，还要求扩展的JDBC API 2.0，它支持行集、连接池和分布式的事务处理。

　　事务处理 JTA(Java Transaction Architecture)定义了一组标准的接口，为应用系统提供可靠的事务处理支持。JTS(Java Transaction Service)是CORBA OTS事务监控的Java实现。JTS规定了事务管理器的实现方式，该事务管理器在高层支持JTA标准，在底层实现了OMG OTS规范的Java映射。

　　消息服务　JMS(Java Message Service)是一组用于和面向消息的中间件相互通信的API。

　　它既支持点对点的消息通信，也支持发布/订阅式的消息通信。 电子邮件 JavaMail API允许在应用程序中以独立于平台、独立于协议的方式收发电子邮件。JAF(JavaBeans Activation Framework)负责处理MIME编码，JavaMail利用JAF来处理MIME编码的邮件附件。

　　CORBA兼容接口　RMI(远程方法调用)是在分布式对象间通信的Java本地方法，它使应用程序调用远程方法像调用本地方法一样，不需要考虑所调用对象的位置。RMI-IIOP是RMI的扩展，是符合CORBA标准的对象通信协议，也是J2EE默认的组件通信协议。Java IDL允许J2EE应用组件通过IIOP协议访问外部的CORBA对象。

　　安全服务　JAAS(Java Authentication and Authorization Service)用两个步骤实现安全性：认证，即由用户提供认证信息(如用户名和密码)来获得系统认证，这一过程又称之为登录;授权，在被确认为合法用户后，系统根据用户的角色授予其相应的权限。J2EE的授权是基于安全角色的概念，一个安全角色是一个拥有相同权限的逻辑组。J2EE的安全角色由应用组件提供商来定义。

　　Web服务支持 目前J2EE还不提供对Web服务的支持。Sun提供了一套API及其实现WSDP作为对J2EE的扩展，但目前还不是J2EE规范的内容。在WSDP中，JAXP用来解析XML文档;JAXR向UDDI服务器注册Web Services;JTX/RPC用基于XML的协议(如SOAP)来发送和接收XML文档;JWSDL处理WSDL文档。虽然J2EE不是为Web服务而生，但它现在正在努力追赶Web服务的脚步。

　　多层应用模型

　　从应用的角度来看，J2EE为企业应用系统的开发提供了一种多层分布式企业应用模型。在J2EE中，应用逻辑按功能不同可以划分为不同类型的组件，各组件根据它们所在的层分布在不同的机器上，共同组成一个基于组件的分布式系统。

　　如图2所示，J2EE定义了一个典型的四层结构，分别是客户层、Web层、商业逻辑层和企业信息系统层。

　　在应用开发时，J2EE定义的四层模型可根据实际情况灵活运用。由于除了Applet外其他的组件都可以访问数据库、EJB组件和企业信息系统，所以通过不同层的取舍及组合，可以衍生出许多应用软件开发模型，如基于Web的四层模型、基于桌面应用的三层模型(不包括Web层)、B2B模型(不包括客户层)等。如果应用系统比较简单，一般不用EJB作为逻辑层，而直接用Web组件来实现商业逻辑和数据访问，毕竟EJB的开发和部署费用还相当高。

　　二、.NET开发平台留住Windows开发者

　　南京邮电学院 李建忠

　　.NET开发平台一推出，就开始了与J2EE平台的竞争。它的绝大部分是微软Windows DNA(Distributed Network Architecture)的重写，DNA是微软以前开发企业应用程序的平台。Windows DNA中包括了许多已经被证实的技术，新的.NET框架取代了这些技术，并包含了Web服务层和改良的语言支持。从战略角度看，.NET开发平台担负着整合.NET战略的重任，但它最直接的目标则是努力为微软保留住庞大的Windows用户基础。

　　微软的Windows开发用户群是微软通过Windows操作系统获得的最大财富。对于为什么要推出.NET开发平台，微软表示，主要原因之一就是由于Java向开发者承诺的硬件和操作系统无关性，可能会导致这些用户转向其他平台。虽然开发平台本身不会给微软带来很多收益，但Windows程序员是企业内部对微软产品的主要支持力量，商用软件的开发者形成了向客户销售微软产品的重要渠道。如果微软可以让开发者在.NET开发平台上编写应用程序，那么就会有更多的公司购买微软的其他产品。

　　认识.NET

　　认识.NET最好的方法是看它做什么。.NET战略将互联网本身作为构建新一代操作系统的基础，并对互联网和操作系统的设计思想进行合理延伸，使开发人员能够创建出与设备无关的应用程序，以便轻松实现互联网连接。.NET包括一个相当广泛的产品家族，它们构建于XML和互联网产业标准之上，为用户提供Web服务的开发、管理、应用和体验。图1是对.NET战略的总体描述。组成.NET战略的五个方面包括：

　　.NET开发平台 这是一组用于建立Web服务应用程序和Windows桌面应用程序的软件组件，包括 .NET Framework(框架)、.NET开发者工具和ASP.NET。于今年3月发布的Visual Studio .NET将是RAD开发工具中一个重要的产品。

　　.NET服务器 能够提供广泛聚合和集成Web服务的服务器是搭建.NET平台的后端基础。 .NET基础服务 密码认证、日历、文件存储、用户信息等基础服务是必不可少的。微软正在着力建设的.NET My Services等基础性服务平台是这方面可以借鉴的例子。

　　.NET终端设备 广泛的连接互联网并体验Web服务的终端设备是实现.NET的前端基础。PC、PDA以及各种嵌入式设备将在这个广阔的天地里发挥作用。

　　.NET用户体验 能够满足人们各种各样需求的用户体验是.NET的最终目标，也是.NET的价值实现。

　　在这五个组成部分当中，.NET开发平台中的 .net框架是.NET软件构造中最具挑战性的部分，其他四个部分则紧紧围绕.NET框架来进行组织整合。

　　.NET 框架内核

　　.NET框架实现了语言开发、代码编译、组件配置、程序运行、对象交互等各个层面的功能，为Web服务及普通应用程序提供了一个托管、安全、高效的执行环境。所有在.NET平台上创建的应用程序运行都需要两个核心模块:Common Language Runtime(CLR，通用语言运行时)和.NET Framework类库。CLR是一个软件引擎，用来加载应用程序，确认它们可以没有错误地运行，并进行相应的安全许可验证，执行应用程序，然后将被清除。

　　.NET Framework类库则向程序员提供软件组件，来编写在CLR的控制下运行的代码，它们按照单一有序的分级组织提供了一个庞大的功能集，包括从文件系统到对XML功能的网访问的每一样功能。该类库为开发提供了三种基本编程模板：基于ASP.NET的Web表单应用、基于ASP.NET的Web服务应用和基于传统GUI交互的Windows应用。图2描述了 .NET开发平台的组成。

　　CLR——.NET的虚拟机

　　CLR为.NET应用程序提供了一个托管的代码执行环境。托管意味着将原来由程序员或操作系统做的工作剥离出来交由CLR来完成，从而使程序运行获得更高的安全性和稳定性。这些工作包括内存管理、即时编译、组件自描述、安全管理和代码验证，以及其他一些系统服务。CLR提供一个技术规范，无论程序使用什么语言编写，只要能编译成中间语言，就可以在它的支持下运行，这样.NET应用程序就可以独立于语言。CLR还在应用程序运行环境中为基于组件的编程提供了直接支持，比如它支持属性、事件、对象、继承性、多态性、接口等组件编程特性。

　　CLR中的自动垃圾收集器负责.NET应用程序运行时的内存分配、对象布局、内存释放等内存管理问题，彻底解决了多年来困扰程序员的内存泄漏问题，大大增强了应用程序的健壮性。

　　即时编译器在运行时将中间语言以调用的对象方法为单位动态编译成本地二进制代码。

　　中间语言是在.NET平台下编译器输出PE文件(Windows可执行文件)的语言，它为.NET平台提供了多语言支持，允许开发者使用20多种不同的编程语言。而元数据是一个内嵌于PE文件的表的集合，描述了代码中数据类型等在代码执行时CLR需要知道的信息。元数据使得.NET应用程序代码具备自描述特性，提供了类型安全保障，而这在以前需要额外的类型库或接口定义语言(IDL)。

　　CLR根据托管组件的来源(如互联网、企业局域网、本地机器)等因素确定各组件的信任度，并根据信任度来限定它们执行诸如读取文件、修改注册表等敏感操作的权限。此外，CLR借助通用类型系统对代码类型进行严格的安全检查，可以避免不同组件之间可能存在的类型不匹配问题。通过代码访问安全机制，开发人员可以为应用程序指定完成工作所必需的权限。CLR不仅规定了代码访问安全，还规定了基于角色的安全。基于角色的认证为互联网上分布式组件的执行提供了安全保证。

　　值得指出的是，CLR通常寄宿在其他高性能服务器的应用程序中，比如互联网信息服务器(IIS)、SQL Server数据库服务器等。这样，开发者可以充分利用CLR诸多安全、高效的优点来部署自己的商业逻辑。

　　类库——组件和服务的家园

　　.NET Framework类库由一组广泛的、面向对象的、可被开发者用于任何编程语言的可重用类集合组成。它提供了几乎所有应用程序都需要的公共代码;在此之上是许多应用程序模板，这些模板为开发网络站点和网络服务提供特定的高级组件和服务，不管是传统的命令行程序还是Windows图形界面程序，亦或是面向下一代互联网分布式计算平台的ASP.NET或Web服务应用。与在Windows和它的SDK中发送的代码库一样，.NET框架类库将程序员从繁重的编程细节中解放出来，而专注于程序的商业逻辑。它将核心Win32 API最常用的功能和外挂SDK的功能封装到了一个统一的包中，并采用清晰而有条理的方式对类库进行分组和描述，这样开发者就能够更方便地找到其应用程序所需要的大多数功能。下面是它所提供的一些核心服务：

　　系统框架服务

　　服务框架包括一套开发人员希望在标准语言库中存在的基类库，如集合、输入/输出、字符串、数据等基类。基类库还提供访问操作系统服务的类，如图画、网络、线程、加密等类型。此外，服务框架也包括数据访问类库以及开发工具。

　　ADO.NET组件

　　ADO.NET为基于网络的、可扩展的应用程序和服务提供数据访问服务。它不仅支持传统的基于链接指针风格的数据访问，而且对于更适合于把数据返回到客户端应用程序的无链接数据模板，它也提供高性能的访问支持。

　　XML数据组件

　　通过它开发人员可以对任何数据进行XML转换、传输和确认，所有数据都可以被看做是XML格式的。同时，系统也支持ADO.NET数据与XML数据之间的通用转换。

　　Windows表单组件

　　Windows表单组件为开发人员提供了强大的Windows应用程序模型和丰富的Windows用户口，包括传统的ActiveX控件和Windows XP的新界面，如透明的、分层的浮动窗口。对CLR的强大支持也是Windows表单组件令人兴奋的地方之一。

　　ASP.NET应用服务

　　ASP.NET的核心是其用于处理基于低级结构HTTP请求的高性能的运行语言，其编译运行的方式大大提高了它的性能。ASP.NET使用基于构件的.NET框架配制模板，因此它获得了诸如XCOPY配制、构件并行配制、基于XML配制之类的优点。它还支持应用程序的实时更新，同时提供高速缓冲服务，以改善性能。

　　ASP.NET Web表单

　　ASP.NET Web表单把VB表单高效率的优点带到了Web应用程序的开发中。ASP.NET Web单支持传统的将HTML内容与脚本代码混合的ASP语法，但是它提出了一种将应用程序代码和用户接口内容分离的、更加结构化的方法。它提供一套映射传统HTML用户接口部件(包括列表框、文本框和按钮)的ASP.NET Web表单控件和一套更加复杂的Web应用控件(如日历和广告转板)。

　　对Web服务的支持

　　ASP.NET应用服务体系架构为用ASP.NET建立Web服务提供了一个高级的可编程模板。虽然建立Web服务并不限定使用特定的服务平台，但是ASP.NET的许多优点将简化其开发过程。使用这个编程模型，开发人员甚至无需理解HTTP、SOAP或其他任何网络服务规范。ASP.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从设计、编码、配置到运行给予了组件编程更多、更直接的支持。

　　一个能够为编程提供广泛服务的、可复用的API类库对于现代软件平台非常重要。从基础的集合、字符串操作到企业级的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注册中心作为公共商务信息的交换机制将大量应用。动态服务同样将大量投入使用。

本文转自：http://www.testage.net/html/50/n-141650-2.html