深度解析J2EE vs NET开发平台.docx

深度解析J2EE vs NET开发平台.docx

《深度解析J2EE vs NET开发平台.docx》由会员分享，可在线阅读，更多相关《深度解析J2EE vs NET开发平台.docx（20页珍藏版）》请在冰豆网上搜索。

深度解析J2EEvsNET开发平台

深度解析：

J2EEvs.NET开发平台

看到这个标题，也许会有人表示疑惑，J2EE和.NET并不在一个层次上，怎么能将它们放在一起呢？

需要指出的是，通常所说的.NET包含了一个相当广泛的产品家族，包括开发平台、操作系统、服务器、终端设备等，此外还包括服务平台。

开发平台只是整个.NET战略中的一部分，所以确切地说，放在这里的.NET应该算是.NET开发平台。

随着三层/多层企业信息系统结构的深度发展和下一代分布式计算模型Web服务的出现，企业应用中关于平台、框架、语言的竞争也愈演愈烈。

J2EE平台在过去几年里一直引领着企业应用的潮流，但最近微软强力推出的.NET平台也开始吸引着众多IT企业和开发人员的注意力，向J2EE平台提出了强有力的挑战。

企业应用领域的技术对抗也因此拉开了架势。

需要强调的是，.NET是战略产品，而J2EE是描述产品的标准，现在有很多符合J2EE标准的产品。

在可以预见的未来，它们都将是构建企业信息系统应用的基础性平台，尤其是开发和部署Web服务的重要平台。

尽管可以同时使用几种系统平台和语言，但对于企业来说，还需要选择一个战略性的平台来实现数据的无缝集成，加速企业应用的部署。

而要做出正确的选择，首先需要充分了解两个平台的特点和优势。

本期专题将为您细说J2EE和.NET。

一、群力所至的J2EE

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

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

四、J2EEvs.NET：

Web服务谁主沉浮？

一、群力所至的J2EE

企业应用系统的开发一直面临着重大挑战：

一方面，企业应用系统面对的是一个异构的分布式环境，它必须支持与已有系统的集成性和与其他系统的互操作性；另一方面，作为为客户、合作伙伴和企业内部提供信息服务的平台，企业系统还必须具有高可用性、安全性、可靠性和可伸缩性。

这些要求再加上复杂多变的用户需求和不断伸缩的交付时间，使得企业系统的开发越来越困难。

开发商和广大程序员一直在努力推动和殷切期待一个成熟、标准的企业平台来简化和规范企业系统的开发和部署。

Java技术的出现，尤其是J2EE（Java2PlatformEnterpriseEdition）平台的推出正是这种努力的结果，也使得企业系统的开发由此变得更加快速和方便。

需要指出的是，J2EE本身是一个标准，它为不同厂商创建平台产品提供了标准，使不同J2EE平台产品之间的交互成为可能。

1、J2EE旅程

Java于1996年由Sun公司推出，当时它的主要用途是制作产生动态网页的Applet。

后来，人们发现Java的“一次开发，多次运行”、纯面向对象的特性、垃圾回收机制和内置的安全特别适合于开发企业应用系统。

于是，企业应用开发商纷纷在Java标准版的基础上各自扩展出许多企业应用API，其结果导致基于Java的企业应用呈爆炸式增长。

但是各企业系统API之间又不能相互兼容，破坏了Java的平台独立性。

鉴于此，Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商于1998年共同制订了一个基于Java组件技术的企业应用系统开发规范，该规范定义了一个多层企业信息系统的标准平台，旨在简化和规范企业应用系统的开发和部署。

这一规范和其定义的平台就构成了J2EE。

目前J2EE的最新版本是J2EE1.3。

需要注意的是，J2EE本身是一个标准，而不是一个现成的产品（虽然现在有很多符合J2EE标准的产品），它由以下几个部分组成：

J2EE规范。

该规范定义了J2EE平台的体系结构、平台角色及J2EE中每种服务和核心API的实现要求。

它是J2EE应用服务器开发商的大纲。

J2EE兼容性测试站点。

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

J2EE参考实现。

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

J2EE实施指南。

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

2、组件-容器搭建体系架构

J2EE规范定义了一个基于组件的多层企业应用系统开发平台，其逻辑结构如图1所示。

图中的椭圆形表示组件，大矩形表示容器，包含向下文字的小矩形表示API，箭头表示访问，箭头线上的文字表示相应的协议。

J2EE是一个基于组件-容器模型的系统平台，其核心概念是容器。

容器是指为特定组件提供服务的一个标准化的运行时环境，Java虚拟机就是一个典型的容器。

组件是一个可以部署的程序单元，它以某种方式运行在容器中，容器封装了J2EE底层的API，为组件提供事务处理、数据访问、安全性、持久性等服务。

在J2EE中组件和组件之间并不直接访问，而是通过容器提供的协议和方法来相互调用。

组件和容器间的关系通过“协议”来定义。

容器的底层是J2EE服务器，它为容器提供J2EE中定义的各种服务和API。

一个J2EE服务器（也叫J2EE应用服务器）可以支持一种或多种容器。

在图1中，你可能已经注意到每个容器的服务包括两部分：

J2SE（Java2PlatformStandardEdition）和一组扩展的服务。

这是因为J2EE是以Java标准版为基础的，各容器在J2SE之上再根据需要提供一些扩展的服务，如目录服务、事务管理、数据访问、消息机制、安全性等。

3、J2ee的核心——EJB

J2EE定义了四种组件：

Applet组件、Application客户组件、Web组件及EJB（EnterpriseJavaBeans）组件。

其中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容器实现目录服务、事务处理、持久性、安全性等底层系统逻辑。

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

Remote接口Remote接口定义EJB组件中提供的可供用户调用的方法，也就是通常所说的实现商业逻辑的函数或过程（如计算商品价格的函数），以供远程客户端调用。

在EJB组件部署到容器的时候，容器会自动生成Remote接口相应的实例，即EJB对象，它负责代理用户的调用请求。

Home接口Home接口定义一组方法来创建新的EJB对象，查找、定位和清除已有的EJB对象。

在EJB组件部署时容器也会自动生成相应的Home对象，该对象负责查找和创建EJB对象，返回EJB对象的引用给客户；用户利用该引用调用EJB组件的方法，得到结果；最后Home对象清除EJB对象。

我们可以形象地称Home接口为EJB对象的工厂。

EnterpriseBeans类EnterpriseBeans类是商业逻辑的具体实现类。

其可供用户调用的方法在Remote接口中定义。

根据功能不同，EJB2.0规范中定义了三种EnterpriseBeans:

会话Beans（SessionBeans）、实体Beans（EntityBeans）和消息驱动Beans（Message-drivenBeans）。

会话Beans分无状态和有状态两种。

一般无状态的会话Beans模拟商业逻辑，比如计算价格等。

有状态的会话Beans通常模拟一个客户会话，它会临时保存客户信息，根据客户要求调用其他Beans来存取数据。

两种会话Beans都不保存状态信息或数据，当客户断开连接或服务器关闭时，会话Beans也随之消失。

一个会话Beans的典型例子是网站上的购物车。

实体Beans模拟商业数据，它表示一个数据存储，可以是状态信息或数据库中的一条纪录。

实体Beans在客户断开连接或服务器关闭后，仍有服务保证其数据得以保存。

一个实体Beans的典型例子就是客户账号信息。

消息驱动Beans在行为上很像会话Beans。

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

另外，在提交和部署EJB组件时，还需要两个文件：

部署描述文件，容器根据该文件来部署EnterpriseBeans，提供所要求的服务；EJBjar文件，它是提交给EJB容器的一个部署单元，容器（应用服务器）在部署时解开它，装入EnterpriseBeans。

EJB容器非常复杂，一般由专业的J2EE应用服务器开发商提供，比较流行的EJB容器由IBM的WebShpere、BEA公司的WebLogicServer、Sun公司的iPlant等应用服务器提供。

EJB容器除了为EJB提供事务处理、目录服务、持久性管理和安全性服务外，还负责EJB的部署、发布和生命周期管理。

5、平台标准服务

服务是组件和容器之间，以及容器和J2EE服务器之间的接口，在实现层面上它就是一系列API和协议。

J2EE平台定义了一组标准的服务，其中有些服务是由J2SE提供的，有些则是J2EE对Java的扩展。

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

数据访问JDBC（JavaDatabaseConnectivity）API为访问不同类型的数据库提供了统一的途径，屏蔽了不同数据库的细节，具有平台无关性。

J2EE平台除了要求核心的JDBCAPI（包含在J2SE中）外，还要求扩展的JDBCAPI2.0，它支持行集、连接池和分布式的事务处理。

事务处理JTA（JavaTransactionArchitecture）定义了一组标准的接口，为应用系统提供可靠的事务处理支持。

JTS（JavaTransactionService）是CORBAOTS事务监控的Java实现。

JTS规定了事务管理器的实现方式，该事务管理器在高层支持JTA标准，在底层实现了OMGOTS规范的Java映射。

消息服务　JMS（JavaMessageService）是一组用于和面向消息的中间件相互通信的API。

它既支持点对点的消息通信，也支持发布/订阅式的消息通信。

电子邮件JavaMailAPI允许在应用程序中以独立于平台、独立于协议的方式收发电子邮件。

JAF（JavaBeansActivationFramework）负责处理MIME编码，JavaMail利用JAF来处理MIME编码的邮件附件。

CORBA兼容接口　RMI（远程方法调用）是在分布式对象间通信的Java本地方法，它使应用程序调用远程方法像调用本地方法一样，不需要考虑所调用对象的位置。

RMI-IIOP是RMI的扩展，是符合CORBA标准的对象通信协议，也是J2EE默认的组件通信协议。

JavaIDL允许J2EE应用组件通过IIOP协议访问外部的CORBA对象。

安全服务　JAAS（JavaAuthenticationandAuthorizationService）用两个步骤实现安全性：

认证，即由用户提供认证信息（如用户名和密码）来获得系统认证，这一过程又称之为登录；授权，在被确认为合法用户后，系统根据用户的角色授予其相应的权限。

J2EE的授权是基于安全角色的概念，一个安全角色是一个拥有相同权限的逻辑组。

J2EE的安全角色由应用组件提供商来定义。

Web服务支持目前J2EE还不提供对Web服务的支持。

Sun提供了一套API及其实现WSDP作为对J2EE的扩展，但目前还不是J2EE规范的内容。

在WSDP中，JAXP用来解析XML文档;JAXR向UDDI服务器注册WebServices；JTX/RPC用基于XML的协议（如SOAP）来发送和接收XML文档；JWSDL处理WSDL文档。

虽然J2EE不是为Web服务而生，但它现在正在努力追赶Web服务的脚步。

6、多层应用模型

从应用的角度来看，J2EE为企业应用系统的开发提供了一种多层分布式企业应用模型。

在J2EE中，应用逻辑按功能不同可以划分为不同类型的组件，各组件根据它们所在的层分布在不同的机器上，共同组成一个基于组件的分布式系统。

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

在应用开发时，J2EE定义的四层模型可根据实际情况灵活运用。

由于除了Applet外其他的组件都可以访问数据库、EJB组件和企业信息系统，所以通过不同层的取舍及组合，可以衍生出许多应用软件开发模型，如基于Web的四层模型、基于桌面应用的三层模型（不包括Web层）、B2B模型（不包括客户层）等。

如果应用系统比较简单，一般不用EJB作为逻辑层，而直接用Web组件来实现商业逻辑和数据访问，毕竟EJB的开发和部署费用还相当高。

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

.NET开发平台一推出，就开始了与J2EE平台的竞争。

它的绝大部分是微软WindowsDNA（DistributedNetworkArchitecture）的重写，DNA是微软以前开发企业应用程序的平台。

WindowsDNA中包括了许多已经被证实的技术，新的.NET框架取代了这些技术，并包含了Web服务层和改良的语言支持。

从战略角度看，.NET开发平台担负着整合.NET战略的重任，但它最直接的目标则是努力为微软保留住庞大的Windows用户基础。

微软的Windows开发用户群是微软通过Windows操作系统获得的最大财富。

对于为什么要推出.NET开发平台，微软表示，主要原因之一就是由于Java向开发者承诺的硬件和操作系统无关性，可能会导致这些用户转向其他平台。

虽然开发平台本身不会给微软带来很多收益，但Windows程序员是企业内部对微软产品的主要支持力量，商用软件的开发者形成了向客户销售微软产品的重要渠道。

如果微软可以让开发者在.NET开发平台上编写应用程序，那么就会有更多的公司购买微软的其他产品。

1、认识.NET

认识.NET最好的方法是看它做什么。

.NET战略将互联网本身作为构建新一代操作系统的基础，并对互联网和操作系统的设计思想进行合理延伸，使开发人员能够创建出与设备无关的应用程序，以便轻松实现互联网连接。

.NET包括一个相当广泛的产品家族，它们构建于XML和互联网产业标准之上，为用户提供Web服务的开发、管理、应用和体验。

图1是对.NET战略的总体描述。

组成.NET战略的五个方面包括：

.NET开发平台这是一组用于建立Web服务应用程序和Windows桌面应用程序的软件组件，包括.NETFramework（框架）、.NET开发者工具和ASP.NET。

于今年3月发布的VisualStudio.NET将是RAD开发工具中一个重要的产品。

.NET服务器能够提供广泛聚合和集成Web服务的服务器是搭建.NET平台的后端基础。

.NET基础服务密码认证、日历、文件存储、用户信息等基础服务是必不可少的。

微软正在着力建设的.NETMyServices等基础性服务平台是这方面可以借鉴的例子。

.NET终端设备广泛的连接互联网并体验Web服务的终端设备是实现.NET的前端基础。

PC、PDA以及各种嵌入式设备将在这个广阔的天地里发挥作用。

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

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

2、.NET框架内核

.NET框架实现了语言开发、代码编译、组件配置、程序运行、对象交互等各个层面的功能，为Web服务及普通应用程序提供了一个托管、安全、高效的执行环境。

所有在.NET平台上创建的应用程序运行都需要两个核心模块:

CommonLanguageRuntime（CLR，通用语言运行时）和.NETFramework类库。

CLR是一个软件引擎，用来加载应用程序，确认它们可以没有错误地运行，并进行相应的安全许可验证，执行应用程序，然后将被清除。

.NETFramework类库则向程序员提供软件组件，来编写在CLR的控制下运行的代码，它们按照单一有序的分级组织提供了一个庞大的功能集，包括从文件系统到对XML功能的网访问的每一样功能。

该类库为开发提供了三种基本编程模板：

基于ASP.NET的Web表单应用、基于ASP.NET的Web服务应用和基于传统GUI交互的Windows应用。

3、CLR——.NET的虚拟机

CLR为.NET应用程序提供了一个托管的代码执行环境。

托管意味着将原来由程序员或操作系统做的工作剥离出来交由CLR来完成，从而使程序运行获得更高的安全性和稳定性。

这些工作包括内存管理、即时编译、组件自描述、安全管理和代码验证，以及其他一些系统服务。

CLR提供一个技术规范，无论程序使用什么语言编写，只要能编译成中间语言，就可以在它的支持下运行，这样.NET应用程序就可以独立于语言。

CLR还在应用程序运行环境中为基于组件的编程提供了直接支持，比如它支持属性、事件、对象、继承性、多态性、接口等组件编程特性。

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

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

中间语言是在.NET平台下编译器输出PE文件（Windows可执行文件）的语言，它为.NET平台提供了多语言支持，允许开发者使用20多种不同的编程语言。

而元数据是一个内嵌于PE文件的表的集合，描述了代码中数据类型等在代码执行时CLR需要知道的信息。

元数据使得.NET应用程序代码具备自描述特性，提供了类型安全保障，而这在以前需要额外的类型库或接口定义语言（IDL）。

CLR根据托管组件的来源（如互联网、企业局域网、本地机器）等因素确定各组件的信任度，并根据信任度来限定它们执行诸如读取文件、修改注册表等敏感操作的权限。

此外，CLR借助通用类型系统对代码类型进行严格的安全检查，可以避免不同组件之间可能存在的类型不匹配问题。

通过代码访问安全机制，开发人员可以为应用程序指定完成工作所必需的权限。

CLR不仅规定了代码访问安全，还规定了基于角色的安全。

基于角色的认证为互联网上分布式组件的执行提供了安全保证。

值得指出的是，CLR通常寄宿在其他高性能服务器的应用程序中，比如互联网信息服务器（IIS）、SQLServer数据库服务器等。

这样，开发者可以充分利用CLR诸多安全、高效的优点来部署自己的商业逻辑。

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

.NETFramework类库由一组广泛的、面向对象的、可被开发者用于任何编程语言的可重用类集合组成。

它提供了几乎所有应用程序都需要的公共代码;在此之上是许多应用程序模板，这些模板为开发网络站点和网络服务提供特定的高级组件和服务，不管是传统的命令行程序还是Windows图形界面程序，亦或是面向下一代互联网分布式计算平台的ASP.NET或Web服务应用。

与在Windows和它的SDK中发送的代码库一样，.NET框架类库将程序员从繁重的编程细节中解放出来，而专注于程序的商业逻辑。

它将核心Win32API最常用的功能和外挂SDK的功能封装到了一个统一的包中，并采用清晰而有条理的方式对类库进行分组和描述，这样开发者就能够更方便地找到其应用程序所需要的大多数功能。

下面是它所提供的一些核心服务：

5、系统框架服务

服务框架包括一套开发人员希望在标准语言库中存在的基类库，如集合、输入/输出、字符串、数据等基类。

基类库还提供访问操作系统服务的类，如图画、网络、线程、加密等类型。

此外，服务框架也包括数据访问类库以及开发工具。

6、ADO.NET组件

ADO.NET为基于网络的、可扩展的应用程序和服务提供数据访问服务。

它不仅支持传统的基于链接指针风格的数据访问，而且对于更适合于把数据返回到客户端应用程序的无链接数据模板，它也提供高性能的访问支持。

7、XML数据组件

通过它开发人员可以对任何数据进行XML转换、传输和确认，所有数据都可以被看做是XML格式的。

同时，系统也支持ADO.NET数据与XML数据之间的通用转换。

8、Windows表单组件

Windows表单组件为开发人员提供了强大的Windows应用程序模型和丰富的Windows用户口，包括传统的ActiveX控件和WindowsXP的新界面，如透明的、分层的浮动窗口。

对CLR的强大支持也是Windows表单组件令人兴奋的地方之一。

9、ASP.NET应用服务

ASP.NET的核心是其用于处理基于低级结构HTTP请求的高性能的运行语言，其编译运行的方式大大提高了它的性能。

ASP.NET使用基于构件的.NET框架配制模板，因此它获得了诸如XCOPY配制、构件并行配制、基于XML配制之类的优点。

它还支持应用程序的实时更新，同时提供高速缓冲服务，以改善性能。

10、ASP.NETWeb表单

ASP.NETWeb表单把VB表单高效率的优点带到了Web应用程序的开发中。

ASP.NETWeb单支持传统的将HTML内容与脚本代码混合的ASP语法，但是它提出了一种将应用程序代码和用户接口内容分离的、更加结构化的方法。

它提供一套映射传统HTML用户接口部件（包括列表框、文本框和按钮）的ASP.NETWeb表单控件和一套更加复杂的Web应用控件（如日历和广告转板）。

11、对Web服务的支持

ASP.NET应用服务体系架构为用ASP.NET建立Web服务提供了一个高级的可编程模板。

虽然建立Web服务并不限定使用特定的服务平台，但是ASP.NET的许多优点将简化其开发过程。

使用这个编程模型，开发人员甚至无需理解HTTP、SOAP或其他任何网络服务规范。

ASP.NET可以利用现存的体系架构和应用程序，为在互联网上绑定应用程序提供了一个简单的、灵活的、基于产业标准的模型。

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

作为彼此竞争的应用平台，J2EE和.NET开发平台在目标和体系结构上极其相似，但在实现上又完全不同。

平台的体系架构是支撑平台的基础，平台各方面的性能也会因平台架构实现的不同而有差异。

对两个平台产生至关重要影响的三个方面是：

系统平台基础构造、三层/多层体系结构和移植/性能/扩展。

J2EE是一个平台规范而非产品，对等而论，在这里述及的.NET也专注于该平台的架构规范，而较少地涉及到具体产品，尽管对.NET而言有时候这方面并不能被区分得很清楚。

1、类似的平台基础构造

一个平台在语言编译、代码执行、编程支持等基础