j2ee与net技术架构比较.docx
《j2ee与net技术架构比较.docx》由会员分享，可在线阅读，更多相关《j2ee与net技术架构比较.docx（18页珍藏版）》请在冰豆网上搜索。
j2ee与net技术架构比较
随着三层/多层企业信息系统结构的深度发展和下一代分布式计算模型Web服务的出现，软件开发中关于平台、框架、语言的竞争也愈演愈烈。
自从微软推出.NET平台，业界关于J2EE平台与.NET平台的比较从未停止过。
本文在收集整理相关文章的基础上，试图对目前两种主要的应用软件开发技术架构J2EE与.NET进行一个客观、公正、全面的比较，以帮助软件开发商选择一个较为合适的开发平台进行应用软件的开发。
一、J2EE简介
Java于1995年由Sun公司推出，当时它的主要用途是制作产生动态网页的Applet。
后来，人们发现Java的“一次开发，多次运行”、纯面向对象的特性、垃圾回收机制和内置安全特别适合于开发企业应用系统。
于是，企业应用开发商纷纷在Java标准版的基础上各自扩展出许多企业应用API，其结果导致基于Java的企业应用呈爆炸式增长。
但是各企业系统API之间又不能相互兼容，破坏了Java的平台独立性。
鉴于此，Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商于1999年共同制订了一个基于Java组件技术的企业应用系统开发规范，该规范定义了一个多层企业信息系统的标准平台，旨在简化和规范企业应用系统的开发和部署。
这一规范和其定义的平台就构成了J2EE。
它定义了基于组件的方式设计、开发、组装和部署企业应用系统的各个组成部分。
同时，J2EE规范定义了分布式多层应用系统模型、组件重用策略、一体化的安全模型以及灵活的事务控制策略等，使得独立软件提供商（ISV）能够比以前更快的速度，向市场推出用户适应的解决方案。
J2EE是一套针对于企业级分布式应用的计算环境，其结构体系如图1所示。
它定义了动态Web页面功能（Servlet和Jsp）、商业组件（EJB）、异步消息传输机制（JMS）、名称和目录定位服务（JNDI）、数据库访问（JDBC）、与子系统的连接器（JCA）和安全服务等。
需要注意的是，J2EE本身是一个标准，而不是一个现成的产品（虽然现在有很多符合J2EE标准的产品），它由以下几个部分组成：
（1）J2EE规范该规范定义了J2EE平台的体系结构、平台角色及J2EE中每种服务和核心API的实现要求。
它是J2EE应用服务器开发商的大纲。
（2）J2EE兼容性测试站点Sun公司提供的一个测试J2EE应用服务器是否符合J2EE规范的站点，对通过该站点测试的产品，Sun公司将发放兼容性证书。
（3）J2EE参考实现即J2EESDK，它既是Sun公司自己对J2EE规范的一个非商业性实现，又是为开发基于J2EE企业级应用系统原型提供的一个免费的底层开发环境。
（4）J2EE实施指南即BluePrints文档，该文档通过实例来指导开发人员如何去开发一个基于J2EE的多层企业应用系统。
图1J2EE体系结构图
1．组件-容器模型
J2EE是一个基于组件-容器模型的系统平台，其核心概念是容器。
容器是指为特定组件提供服务的一个标准化的运行时环境，Java虚拟机就是一个典型的容器。
组件是一个可以部署的程序单元，它以某种方式运行在容器中，容器封装了J2EE底层的API，为组件提供事务处理、数据访问、安全性、持久性等服务。
在J2EE中组件和组件之间并不直接访问，而是通过容器提供的协议和方法来相互调用。
组件和容器间的关系通过“协议”来定义。
容器的底层是J2EE服务器，它为容器提供J2EE中定义的各种服务和API。
一个J2EE服务器（也叫J2EE应用服务器）可以支持一种或多种容器。
2．J2EE的核心——EJB
J2EE定义了四种组件：
Applet组件、Application客户组件、Web组件及EJB（EnterpriseJavaBeans）组件。
其中Applet和Application客户组件在客户端运行，J2EE通过Java插件为Applet提供运行环境，Application客户的容器就是本地Java虚拟机；Web及EJB组件在服务端运行。
J2EE中包含JSP和Servlet两种Web组件，它们是Web服务器的功能扩展，都能生成动态Web页面。
不同的是JSP是将Java代码嵌入到HTML中，服务器负责解释执行，生成结果返回用户（与ASP技术相似）；而Servlet是单独的Java类，它动态生成HTML文件返回给客户。
Web组件的容器比较典型的就是基于Java的Web服务器。
EJB是J2EE平台的核心，也是J2EE得到业界广泛关注和支持的主要原因。
众所周知J2EE的一个主要目的就是简化企业应用系统的开发，使程序员将主要精力放在商业逻辑的开发上。
EJB正是基于这种思想的服务器端技术，它本身也是一种规范，该规范定义了一个可重用的组件框架来实现分布式的、面向对象的商业逻辑；其核心思想是将商业逻辑与底层的系统逻辑分开，使开发者只需关心商业逻辑，而由EJB容器实现目录服务、事务处理、持久性、安全性等底层系统逻辑。
一个可部署的EJB组件包含3个部分：
Remote接口、Home接口和EnterpriseBeans类。
（１）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的部署、发布和生命周期管理。
3．平台标准服务
服务是组件和容器之间，以及容器和J2EE服务器之间的接口，在实现层面上它就是一系列API和协议。
J2EE平台定义了一组标准的服务，其中有些服务是由J2SE提供的，有些则是J2EE对Java的扩展。
（1）目录服务JNDI（JavaNameandDirectory）API为应用程序提供了一个统一的接口来完成标准的目录操作，由于JNDI是独立于目录协议的，应用程序可以用它访问各种目录服务，如LDAP、NDS、DNS等。
（2）数据访问JDBC（JavaDatabaseConnectivity）API为访问不同类型的数据库提供了统一的途径，屏蔽了不同数据库的细节，具有平台无关性。
J2EE平台除了要求核心的JDBCAPI（包含在J2SE中）外，还要求扩展的JDBCAPI2.0，它支持行集、连接池和分布式的事务处理。
（3）事务处理JTA（JavaTransactionArchitecture）它定义了一组标准的接口，为应用系统提供可靠的事务处理支持。
JTS（JavaTransactionService）是CORBAOTS事务监控的Java实现。
JTS规定了事务管理器的实现方式，该事务管理器在高层支持JTA标准，在底层实现了OMGOTS规范的Java映射。
（4）消息服务JMS（JavaMessageService）它是一组用于和面向消息的中间件相互通信的API,它既支持点对点的消息通信，也支持发布/订阅式的消息通信。
电子邮件JavaMailAPI允许在应用程序中以独立于平台、独立于协议的方式收发电子邮件。
JAF（JavaBeansActivationFramework）负责处理MIME编码，JavaMail利用JAF来处理MIME编码的邮件附件。
（5）CORBA兼容接口RMI（远程方法调用）是在分布式对象间通信的Java本地方法，它使应用程序调用远程方法像调用本地方法一样，不需要考虑所调用对象的位置。
RMI-IIOP是RMI的扩展，是符合CORBA标准的对象通信协议，也是J2EE默认的组件通信协议。
JavaIDL允许J2EE应用组件通过IIOP协议访问外部的CORBA对象。
（6）安全服务JAAS（JavaAuthenticationandAuthorizationService）它用两个步骤实现安全性：
认证，即由用户提供认证信息（如用户名和密码）来获得系统认证，这一过程又称之为登录；授权，在被确认为合法用户后，系统根据用户的角色授予其相应的权限。
J2EE的授权是基于安全角色的概念，一个安全角色是一个拥有相同权限的逻辑组。
J2EE的安全角色由应用组件提供商来定义。
4．对WEB服务的支持
Sun提供了一套API及其实现WSDP作为对J2EE的扩展。
在WSDP中，JAXP用来解析XML文档;JAXR向UDDI服务器注册WebServices；JTX/RPC用基于XML的协议（如SOAP）来发送和接收XML文档；JWSDL处理WSDL文档。
J2EE1.4的设计目标就是Web服务，其中新加入了像JAX-RPC／SAAJ和JAXR等API，另外EJB2.1里也增加了许多针对Web服务设计的特性。
5多层应用模型
从应用的角度来看，J2EE为企业应用系统的开发提供了一种多层分布式企业应用模型。
在J2EE中，应用逻辑按功能不同可以划分为不同类型的组件，各组件根据它们所在的层分布在不同的机器上，共同组成一个基于组件的分布式系统。
如图1所示，J2EE定义了一个典型的四层结构，分别是客户层、表示层（Web层）、业务逻辑层和企业信息系统层。
在应用开发时，J2EE定义的四层模型可根据实际情况灵活运用。
由于除Applet外，其他的组件都可以访问数据库、EJB组件和企业信息系统，因此通过不同层的取舍及组合，可以衍生出许多应用软件开发模型，如基于Web的四层模型、基于桌面应用的三层模型（不包括Web层）、B2B模型（不包括客户层）等。
如果应用系统比较简单，一般不用EJB作为逻辑层，而直接用Web组件来实现商业逻辑和数据访问，毕竟EJB的开发和部署费用还相当高。
二、.NET简介
.NET来自于微软，是一套全能的框架平台，支持C++、C#、J++、VB、ASP等语言，能够解决C/S、B/S和单机等结构的软件开发需求。
.NET平台将这些语言编译成CLR语言，使它们可以无差别的运行在.NETFramework上，是2000年以后微软最为重要的软件开发套件产品。
.NET的绝大部分是微软WindowsDNA（DistributedNetworkArchitecture）的重写，DNA是微软以前开发企业应用程序的平台。
WindowsDNA中包括了许多已经被证实的技术，新的.NET框架取代了这些技术，并包含了Web服务层和改良的语言支持。
图2是.NET开发平台的体系结构。
图2.NET体系结构图
1．﹒NET框架内核
.NET框架实现了语言开发、代码编译、组件配置、程序运行和对象交互等各个层面的功能，为Web服务及普通应用程序提供了一个托管、安全和高效的执行环境。
所有在.NET平台上创建的应用程序运行都需要两个核心模块:
CommonLanguageRuntime（CLR，通用语言运行时）和.NETFramework类库。
（１）CLR——.NET的虚拟机CLR是一个软件引擎，用来加载应用程序，确认它们可以没有错误地运行，并进行相应的安全许可验证，执行应用程序，然后将被清除。
它为.NET应用程序提供了一个托管的代码执行环境，托管意味着将原来由程序员或操作系统做的工作剥离出来交由CLR来完成，从而使程序运行获得更高的安全性和稳定性。
这些工作包括内存管理、即时编译、组件自描述、安全管理、代码验证以及其他一些系统服务。
CLR提供一个技术规范，无论程序使用什么语言编写，只要能编译成中间语言，就可以在它的支持下运行，这样.NET应用程序就可以独立于语言。
CLR还在应用程序运行环境中为基于组件的编程提供了直接支持，比如它支持属性、事件、对象、继承性、多态性和接口等组件编程特性。
CLR中的自动垃圾收集器负责.NET应用程序运行时的内存分配、对象布局、内存释放等内存管理问题，彻底解决了多年来困扰程序员的内存泄漏问题，大大增强了应用程序的健壮性。
即时编译器在运行时，将中间语言以调用对象的方法将单位动态编译成本地二进制代码。
（2）类库NETFramework类库向程序员提供软件组件，用来编写在CLR控制下运行的代码，它们按照单一有序的分级组织提供了一个庞大的功能集，包括从文件系统到对XML功能的网访问的每一样功能。
该类库为开发提供了三种基本编程模板：
基于ASP.NET的Web表单应用、基于ASP.NET的Web服务应用和基于传统GUI交互的Windows应用。
.NETFramework类库由一组广泛的、面向对象的、可被开发者用于任何编程语言的可重用类集合组成，它提供了几乎所有应用程序都需要的公共代码;在此之上是许多应用程序模板，这些模板为开发网络站点和网络服务提供特定的高级组件和服务，无论是传统的命令行程序，还是Windows图形界面程序，亦或是面向下一代互联网分布式计算平台的ASP.NET或Web服务应用，与在Windows和它的SDK中发送的代码库一样，.NET框架类库将程序员从繁重的编程细节中解放出来，而专注于程序的商业逻辑。
它将核心Win32API最常用的功能和外挂SDK的功能封装到了一个统一的包中，并采用清晰而有条理的方式对类库进行分组和描述，这样开发者就能够更方便地找到其应用程序所需要的大多数功能。
2．ADO.NET组件
ADO.NET为基于网络的、可扩展的应用程序和服务提供数据访问服务。
它不仅支持传统的基于链接指针风格的数据访问，而且对于更适合于把数据返回到客户端应用程序的无链接数据模板，也提供高性能的访问支持。
3．XML数据组件
通过它开发人员可以对任何数据进行XML转换、传输和确认，所有数据都可以被看作是XML格式的。
同时，系统也支持ADO.NET数据与XML数据之间的通用转换。
4．WINDOWS表单组件
Windows表单组件为开发人员提供了强大的Windows应用程序模型和丰富的Windows用户口，包括传统的ActiveX控件和WindowsXP的新界面，如透明的、分层的浮动窗口。
5．ASP.NET应用服务
ASP.NET的核心是其用于处理基于HTTP请求的高性能的运行语言，其编译运行的方式大大提高了它的性能。
ASP.NET使用基于构件的.NET框架配置模板，因此，它获得了诸如XCOPY配置、构件并行配置和基于XML配置之类的优点。
它还支持应用程序的实时更新，同时提供高速缓冲服务，以改善性能。
ASP.NETWeb表单把VB表单高效率的优点带到了Web应用程序的开发中。
它支持传统的将HTML内容与脚本代码混合的ASP语法，但是它提出了一种将应用程序代码和用户接口内容分离的、更加结构化的方法。
它提供一套映射传统HTML用户接口部件（包括列表框、文本框和按钮）的ASP.NETWeb表单控件和一套更加复杂的Web应用控件（如日历和广告转板）。
6．对Web服务的支持
ASP.NET应用服务体系架构为用ASP.NET建立Web服务提供了一个高级的可编程模板。
虽然建立Web服务并不限定使用特定的服务平台，但是ASP.NET的许多优点将简化其开发过程。
使用这个编程模型，开发人员甚至无需理解HTTP、SOAP或其他任何网络的服务规范。
ASP.NET可以利用现存的体系架构和应用程序，为在互联网上绑定应用程序提供了一个简单、灵活和基于产业标准的模型。
三、J2EE与.NET比较
1．体系架构的比较
作为彼此竞争的应用平台，J2EE和.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接口，如JMS、JDBC、JAX和JNDI等，J2EE在这方面有着非常坚实的结构。
微软.NET框架类库也不示弱，提供了从图画、网络、线程到ADO.NET、ADSI、Windows表单和ASP.NET等一系列的API。
除去API类库的无缝的功能复用外，对本地平台的调用操作也是值得关注的。
CLR和Java虚拟机都支持本地方法的调用。
在异构平台方面，J2EE更钟情于IIOP（InternetInterORBProtocol），而.NET则使用SOAP。
（2）相同的三层/多层体系基于三层/多层分布式计算结构已毋庸置疑地成为当今企业应用的主流模式，也是两个平台较量的着力点。
在客户端，表示层负责用户与系统的交互。
对于不同的处理要求，.NET和J2EE都提出了基于桌面的应用程序和基于浏览器的Web应用的开发组件：
JavaApplication与Windows表单、JavaServlet/JSP与ASP.NET双双形成犄角之势。
但Windows表单依赖微软桌面系统的天然优势，无论在交互速度还是在界面的表现性能上都较JavaApplication稍胜一筹。
Servlet/JSP与ASP.NET是目前企业在“瘦客户端”应用的重点，两者都基于HTTP请求/响应模型，通过HTML浏览器页面完成用户交互。
虽然ASP.NET声称在底层通过编译执行获得了相当高的处理速度和服务器方控件的浏览器自适应能力，但目前并没有这方面的硬性数据，很难据此而论高低。
在缓存、状态优化等方面两者可谓是旗鼓相当。
另一个与客户端应用相关的技术是ActiveX与Applet，从目前的趋势来看，它们在两个平台上的地位逐渐边缘化，也不为大多数企业所接受。
在中间层，分布式业务组件负责企业应用的商业逻辑部署。
由于这些业务组件经常负责处理数据库连接、网络资源和线程等高昂的资源，所以一直是三层/多层架构的关键和企业应用的核心。
J2EE的EJB是一个成熟的、得到业界广泛支持的大型企业级组件框架，而.NET组件则是建立在新型的COM+服务之上，两者在组件与操作系统的交互、客户端资源共享等方面都有很好的支持。
.NET则通过元数据支持自描述性的组件开发、XCOPY部署以及多版本共存，无需注册表和描述文件，对企业客户有一定的吸引力。
在后端数据层，两个平台都为数据库连接量身定做了一套数据存取模型：
J2EE的JDBC和.NET的ADO.NET，它们在支持传统SQL数据源的同时，也支持新型的XML数据源。
这方面由于更多地涉及到具体的数据库产品，很难说那种数据模型更有优势。
两种架构的简单对照如表1所示。
表1J2EE与.NET架构比较
架构
比较项
J2EE
.NET
通信协议
RemoteMethodInvocationoverInternetInterOrbProtocol（RMI/IIOP）
XML
编程语言
Java
C#，VB.NET，COBOL等
运行时环境
JavaVirtualMachine（JVM）
CommonLanguageRuntime（CLR）
胖客户端
JavaSwing
WindowsForms
目录服务
JavaNamingandDirectoryInterface（JNDI）
ActiveDirectoryServicesInterface（ADSI）
数据访问
JavaDatabaseConnection（JDBC）
JavaConnectorsADO.NET
异步消息处理
JavaMessageService（JMS）
MicrosoftMessageQueue
表示层技术
Servlets，JavaServerPage（JSP）
ASP.NET
中间层组件模型
EJB，JavaBean
COM+，COM
安全访问
JAAS
COM+SecurityCallContext
事物处理
JavaTransactionServer（JTS）
Mic
升级会员 