J2EE与.NET技术架构的比较

文章不错，就转载了

一、J2EE简介

J2EE体系结构图：

　　　　　　　　　　　　　　　　　　

　　　　　　

1．组件-容器模型

J2EE是一个基于组件-容器模型的系统平台，其核心概念是容器。容器是指为特定组件提供服务的一个标准化的运行时环境，Java虚拟机就是一个典型的容器。组件是一个可以部署的程序单元，它以某种方式运行在容器中，容器封装了J2EE底层的API，为组件提供事务处理、数据访问、安全性、持久性等服务。在J2EE中组件和组件之间并不直接访问，而是通过容器提供的协议和方法来相互调用。组件和容器间的关系通过“协议”来定义。容器的底层是J2EE服务器，它为容器提供J2EE中定义的各种服务和API。一个J2EE服务器（也叫J2EE应用服务器）可以支持一种或多种容器。

2．J2EE的核心——EJB

J2EE定义了四种组件：Applet组件、Application客户组件、Web组件及EJB（Enterprise JavaBeans）组件。其中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接口和Enterprise Beans类。

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

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

（３）EnterpriseBeans类 Enterprise Beans类是商业逻辑的具体实现类。它可供用户调用的方法在Remote接口中定义。根据功能不同，EJB 2.0规范中定义了三种EnterpriseBeans:会话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组件时，还需要两个文件：部署描述文件，容器根据该文件来部署EnterpriseBeans，提供所要求的服务；EJB jar文件，它是提交给EJB容器的一个部署单元，容器（应用服务器）在部署时解开它，装入EnterpriseBeans。

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

3．平台标准服务

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

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

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

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

(4) 消息服务JMS（Java Message Service） 它是一组用于和面向消息的中间件相互通信的API,它既支持点对点的消息通信，也支持发布/订阅式的消息通信。 电子邮件JavaMail API允许在应用程序中以独立于平台、独立于协议的方式收发电子邮件。JAF（JavaBeans Activation Framework）负责处理MIME编码，JavaMail利用JAF来处理MIME编码的邮件附件。

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

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

4．对WEB服务的支持

Sun提供了一套API及其实现WSDP作为对J2EE的扩展。在WSDP中，JAXP用来解析XML文档;JAXR向UDDI服务器注册Web Services；JTX/RPC用基于XML的协议（如SOAP）来发送和接收XML文档；JWSDL处理WSDL文档。

J2EE 1.4的设计目标就是Web服务，其中新加入了像JAX-RPC／SAAJ和JAXR等API，另外EJB2.1里也增加了许多针对Web服务设计的特性。

5 多层应用模型

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

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的绝大部分是微软Windows DNA(Distributed Network Architecture)的重写，DNA是微软以前开发企业应用程序的平台。Windows DNA中包括了许多已经被证实的技术，新的.NET框架取代了这些技术，并包含了Web服务层和改良的语言支持。图是.NET开发平台的体系结构。

1．﹒NET框架内核

.NET框架实现了语言开发、代码编译、组件配置、程序运行和对象交互等各个层面的功能，为Web服务及普通应用程序提供了一个托管、安全和高效的执行环境。所有在.NET平台上创建的应用程序运行都需要两个核心模块:Common LanguageRuntime（CLR，通用语言运行时）和.NET Framework类库。

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

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

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

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

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

2．ADO.NET组件

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

3．XML数据组件

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

4．WINDOWS表单组件

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

5．ASP.NET应用服务

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

ASP.NET Web表单把VB表单高效率的优点带到了Web应用程序的开发中。它支持传统的将HTML内容与脚本代码混合的ASP语法，但是它提出了一种将应用程序代码和用户接口内容分离的、更加结构化的方法。它提供一套映射传统HTML用户接口部件（包括列表框、文本框和按钮）的ASP.NET Web表单控件和一套更加复杂的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（InternetInterORB Protocol），而.NET则使用SOAP。

（2）相同的三层/多层体系 基于三层/多层分布式计算结构已毋庸置疑地成为当今企业应用的主流模式，也是两个平台较量的着力点。

在客户端，表示层负责用户与系统的交互。对于不同的处理要求，.NET和J2EE都提出了基于桌面的应用程序和基于浏览器的Web应用的开发组件：JavaApplication与Windows表单、Java Servlet/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数据源。这方面由于更多地涉及到具体的数据库产品，很难说那种数据模型更有优势。

两种架构的简单对照如表所示。



J2EE与.NET架构比较

架构 比较项	J2EE	.NET
通信协议	Remote Method Invocation over Internet InterOrb Protocol (RMI/IIOP)	XML
编程语言	Java	C#，VB.NET，COBOL等
运行时环境	Java Virtual Machine (JVM)	Common Language Runtime (CLR)
胖客户端	Java Swing	Windows Forms
目录服务	Java Naming and Directory Interface (JNDI)	Active Directory Services Interface (ADSI)
数据访问	Java Database Connection (JDBC)	Java Connectors ADO.NET
异步消息处理	Java Message Service (JMS)	Microsoft Message Queue
表示层技术	Servlets， Java Server Page(JSP)	ASP.NET
中间层组件模型	EJB，JavaBean	COM+，COM
安全访问	JAAS	COM+ Security Call Context
事物处理	Java Transaction Server (JTS)	Microsoft Distributed Transaction Coordinator (MS-DTC)
开发工具	Borland JBuilder，IBM VisualAge 等	Visual Studio.NET

2 移植性比较

在移植性方面，.NET支持跨语言，J2EE支持跨平台。

微软通过.NET 通用语言运行时来消除编程语言的差别，“选择.NET平台就意味着选择Windows”，这句话至少在可预见的一段时间里仍然是一个基本事实。J2EE则通过Java虚拟机来消除平台差别，跨平台是它的一大卖点，也是在选择企业应用开发平台时的一个重要参考因素，几乎所有的主流操作系统都提供了对J2EE的支持；实际上如果要搭建跨Unix、Windows等多个操作系统平台，J2EE平台几乎是惟一的选择，J2EE更关注跨平台而不是跨语言。但微软认为，如果企业的应用都能通过标准协议以Web服务的方式发布，那么平台都是中立的。为了吸引更多的开发者和鼓励广大企业厂商转到.NET平台，微软提出了多语言支持，希望用跨语言的交互性来平衡跨平台的互操作。

3. 性能比较

性能是J2EE和.NET喋喋不休的话题。二者之间著名的论战是一个关于宠物店的范例应用。宠物店是Sun一度以来作为J2EE典型应用的展示范例，而.NET“自告奋勇”地在自己的平台上实现了该宠物店应用，且声称代码行是J2EE的1/3，效率却是J2EE的30倍。但Sun的理由是这个范例根本不适合用来做性能比较，该范例实现也没有做针对性能的优化，而且指责微软通过后端数据库优化和缓存虚抬了.NET平台的效率。这样的争吵当然不能作为判断的依据，目前也没有见到更客观的第三方评测报告。在“Wintel平台”上也许没有理由怀疑.NET的性能；至于非Windows平台，.NET和J2EE也不再具有可比性。

4．安全性、稳定性比较

WINDOWS本身的安全漏洞，使得.NET的安全性不如J2EE。同时，在应用服务器的选择上，.NET只能用IIS，安全性、稳定性难以保证；而J2EE有更多的选择，可以在诸多遵循标准的厂商所提供的应用程序服务器中，选择最符合需要、成本最低、而且又被认为是最佳的平台。

5．可扩展性比较

.NET平台的扩展思想是基于软件的横向扩展，而J2EE平台的扩展思想则是基于硬件的纵向扩展。

Windows系统一般只能扩展到不超过8个处理器，而Sun的系统却可以扩展到100个甚至更多处理器。

基于J2EE平台的应用程序可被部署到各种操作系统上，例如可被部署到高端UNIX与大型机系统，这种系统单机可支持64至256个处理器，这是NT服务器所望尘莫及的。J2EE领域的供应商提供了更为广泛的负载平衡策略，能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。

6．成熟度比较

在平台的成熟度方面，两者也有一比。J2EE在1999年形成了成熟的架构，发展至今已经具有相当成熟的、经过检验的企业应用系统。而.NET究其渊源是源自微软以前开发企业应用程序的平台DNA（DistributedNetwork Architecture），其中包括了许多已经被证实的技术，并且这些技术已经在产品中得到实现，包括微软的事务服务器、COM+、消息队列和SQL Server数据库等。

7．第三方厂商的支持

J2EE作为一种开放的规范，从一开始就得到了众多厂商的支持，IBM、BEA、HP、Oracle等在J2EE的实施上都有较大的投入。目前市场上最好的J2EE应用服务器并不是Sun与Netscape合资的iPlanet，而是BEA的WebLogic和IBM的Webshpere。开发工具有Borland的JBuilder、Sun的Forte for Java、BEA的WebLogicWorkshop、Oracle的JDeveloper、IBM的VisualAge
forJava等。

而.NET在设计之初就紧紧地把平台规范与产品胶合在一起。虽然，NET架构的一小部分具有开放性（如C#语言、通用语言基础构造CLI 和Web服务标准），但至少目前很难想象会有一个非微软的.NET实现。Visual Stdio.NET是其唯一的开发工具。

8．开源支持比较

J2EE开源产品众多，免费框架居多，相应的最佳实践设计模式层出不穷。而.NET无开源社区支持，是以框架开发者为主导的设计。

9．学习成本比较

J2EE门槛较高，由于多且杂，需要开发人员花费很长时间才能熟悉整个体系。而.NET门槛较低，使用方便，学习成本较低。但是，对于开发人员来说，.NET在系统整体架构的设计方面不如J2EE易于把握。

10．对WEB服务支持的比较

从.NET和J2EE这两个平台的发展历程来看，.NET从一开始就深深打上了Web服务技术的烙印，在它的市场推广活动中，无时无刻不凸显其作为Web服务的开发和部署平台的特征，可以说，.NET天生就是为Web服务准备的开发和部署平台。相对.NET而言，J2EE是一个比较“老”的东西，最初它是为了将Java平台拓展到企业级应用领域而制订的一个平台框架规范，随着Web服务技术的兴起和发展，J2EE平台作为一个企业级应用的开发和部署平台，无法回避业界的重大技术革命——Web服务，J2EE也不断地引入了对Web服务的支持。

从服务描述、服务实现和服务的发布、发现与绑定，以及服务的调用和执行这些不同的角度看，J2EE和.NET的支持基本不相上下，惟一的区别可能是.NET的开发工具更为方便一些、集成度更高一些。

在Web服务规范的控制方面，微软与IBM共同主推了大量的Web服务规范，在一段时间内，两家公司Web服务技术的市场推广活动都是联合举行的，不难看出这两家公司在这个领域背后的战略合作关系。最初的Web服务核心技术SOAP、WSDL主要由这两家公司制订，后来的UDDI是由这两家为首的多家核心企业共同制订，再后来的一些不是核心的Web服务规范，如WS-Inspection、WSFL、WS-Security、WS-Routing、WS-License和WS-Referral等，则完全是由这两家来制订的。不难看出：IBM和微软对于Web服务的贡献以及它们对Web服务规范的控制。

尽管由于某种原因，Sun公司曾经在很长的一段时间里被排除在WS-I（由IBM，微软和BEA发起成立的促进WEB服务互操作的一个组织）的门外，但这并没有影响Sun公司继续在WEB服务方面坚持开放的战略。Sun公司是Java语言的发明者，而作为一个开放的跨平台的技术体系，Java在WEB服务的开发方面也起着非常重要的作用。双方妥协后，Sun最终被接纳为WS-I的董事成员。

Sun公司积极地参与了制订Web服务规范的过程，像XML和ebXML。并已经在Java中支持WEB服务中最重要的规范，例如SOAP（JAX-RPC、JAXM、SAAJ和JMS）、WSDL（Java API forWSDL）、UDDI/ebXML（JAXR）和XML（JAXP，JAXB）等等。Sun公司除了积极地参与Web服务领域里的标准化工作，更是努力地为客户提供全面的软件产品，为用户开发和部署Web服务提供平台。Sun公司的Sun
ONE Web服务平台开发版，是业界第一个用于基于Java技术的Web服务和Web应用开发的全方位的集成平台。该平台集成了多种SunONE服务器软件、Java开发工具，支持业界的WEB服务标准，而且是面向开发人员设计，安装和使用都非常简单。

四、结束语

关于J2EE和.NET之间的讨论已经持续很多年了，孰优孰劣仍然很难下结论。事实上，.NET和J2EE都各有特长，两者都是十分优秀的开发平台，短时间内谁也不可替代对方。选择哪种开发平台，除了要看软件开发人员对语言的掌握能力及个人喜好，也要根据开发内容和企业具体情况、具体需求而定。

J2EE最大的优势是跨平台，.NET最大的优势是入门容易和性能较高（鉴于微软在“Wintel平台”上的代码优化功底，.NET代码的执行速度较之于J***A有明显的优势）。对于没有.NET和J2EE平台基础的开发团队来说，如果开发的应用软件没有跨平台的要求，只需要运行于微软平台之上，则选择.NET平台较好；如果要求跨平台，则只能使用J2EE。如果开发团队具有.NET或J2EE平台基础，在进行新的应用软件开发时，如果没有跨平台要求，则没有必要更换开发平台，因为，更换平台会带来不小的培训成本。