Microsoft .NET与Sun J2EE是目前企业Web Services平台市场上两个最重要的应用框架(Application Framework)。它们都在针对分布式N-Tier应用的设计、集成、性能、安全性和可靠性等诸多方面，为用户提供了总体的指南和规范。基于这些指南和规范，技术提供商提供了相应的平台、工具和编程环境。在具体的应用框架中，包括了针对应用的表现层服务、服务器端进程、会话管理、商业逻辑框架、应用数据缓存、应用逻辑、持久化性、事务、安全和日志服务等内容。
技术提供商能够在应用框架的顶部构建应用程序的开发工具和应用服务器。应用框架的目标是提供一个统一的软件框架，以减少对企业软件产品的支持、维护和集成的代价。
Microsoft .NET是一个由Server、Client和Service组成的平台。.NET框架包括基本的运行库、用户接口库、CLR、C#、C++、VB.NET、Jscript.NET、ASP.NET，以及.NET框架API的各个方面。它由以下三个部分组成：
◆ .NET平台，包括构建.NET服务和.NET设备软件的工具和基础框架；
◆ .NET产品和服务，包括基于Microsoft .NET的企业服务器，如BizTalk Server 2002 和SQL Server 2000, 它们对.NET框架提供支持；
◆ 第三方软件开发商提供的.NET服务，构建在.NET平台上的第三方服务。
J2EE(Java企业版)是一组规范集，每一个规范规定了Java技术应当如何提供一种类型的功能。J2EE平台为基于多层分布式应用模型上的Java应用设计、开发、装配和部署提供了一个完整框架。J2EE规范为开发应用和企业系统集成定义了数目众多的应用编程接口(API)和多种应用编程模型。最新的J2EE规范包括EJB 2.0、J2EE Connector Architecture1.0、JDBC 2.0、JSP 1.2、Servlet 2.3、JTA 1.0.1、JMS 1.0.2、JNDI 1.2、Java RMI 1.0、RMI/IIOP 1.0、JAAS 1.0、JavaMail 1.1、JAXP 1.1等。
作为彼此竞争的应用平台，J2EE和.NET开发平台在目标和体系结构上极其相似，但在实现上又完全不同。平台的体系架构是支撑平台的基础，平台各方面的性能也会因平台架构实现的不同而有差异。对两个平台产生至关重要影响的三个方面是：系统平台基础构造、三层/多层体系结构和移植/性能/扩展。
类似的平台基础构造
一个平台往往会在语言编译、代码执行、编程支持等基础构造方面，对平台的可用性、生产性、移植性等因素产生重要的影响，这也是评判一个平台是否适合特定应用的重要依据。J2EE和.NET两个平台底层的执行引擎都源于虚拟机，但.NET的CLR(Common Language Runtime)在Java虚拟机(JVM)的基础上发展得更远。CLR在借鉴了JVM的自动垃圾收集、异常处理等机制的同时，又为.NET平台添加了多语言支持、组件自描述等新的特性。
在.NET和J2EE平台上，程序的编译都经过两个类似的过程。首先指定高级语言编译器将C#（或其它.NET语言）或Java源代码翻译成中间语言(IL)和字节代码(ByteCode)。.NET在中间语言设计时，通盘考虑了多个主流高级语言，在这一层面实现了.NET平台的跨语言承诺。J2EE的基石则是Java语言，它最典型的特征是一次编写，多平台运行。
其次，在执行时，中间语言被即时编译器(JIT)编译成特定平台的二进制代码，字节代码通过虚拟机解释执行，完成各自语言的指令功能。鉴于Microsoft在代码上的优化功底(专注于自己的平台)，.NET代码的执行速度较之Java有明显的优势是不争的事实。但在Unix/Linux平台上，由于.NET尚未能实现其跨平台的承诺，J2EE几乎成了惟一的选择，执行效率的比较也就没有多大意义。在代码执行的同时，CLR和JVM也都提出了异常捕捉、类型安全、内存分配、垃圾收集等自动化内存管理工作，大大减轻了内存泄漏问题和程序员繁重的负担。
相同的三层/多层体系
基于三层/多层分布式计算结构已毋庸置疑地成为当今企业应用的主流模式，也是两个平台较量的着力点。
在客户端，表示层负责用户与系统的交互。对于不同的处理要求，.NET和J2EE都提出了基于桌面的应用程序和基于浏览器的Web应用的开发组件：Java Application与Windows Form、Java Servlet/JSP与ASP.NET。它们双双形成犄角之势。Windows Form依赖Microsoft桌面系统的天然优势，不管在交互速度还是在界面的表现性能上，都较Java Application稍胜一筹。Servlet/JSP与ASP.NET是目前企业在“瘦客户端”应用的重点，两者都基于HTTP请求/响应模型，通过HTML浏览器页面完成用户交互。虽然ASP.NET声称，在底层通过编译执行获得了相当高的处理速度，以及服务器方控件的浏览器自适应能力，但目前并没有这方面的硬性数据，很难据此而论高下。在缓存、状态优化等方面两者可谓旗鼓相当。另一个和客户端应用相关的技术是ActiveX与Applet，但从目前的趋势来看，它们在两个平台上的地位逐渐边缘化，也不为大多数企业所接受。
在中间层，分布式业务组件负责企业应用的商业逻辑部署。由于这些业务组件经常负责处理数据库连接、网络资源、线程等高昂的资源，所以一直是三层/多层架构的关键和企业应用的核心。J2EE的EJB是一个成熟的、得到业界广泛支持的大型企业级组件框架，而.NET组件则是建立在新型的Remoting和COM+服务之上的，两者在组件与操作系统的交互、客户端资源共享等方面都有很好的支持。EJB的核心是容器，容器是一个为组件提供服务的运行环境，负责为组件提供诸如事务处理、持久性、安全性、组建状态自动化管理等服务。它分离了商业逻辑和系统底层逻辑，从而使得开发人员的工作大为简化。.NET通过元数据支持自描述性的组件开发、XCOPY部署以及多版本共存，而无需注册表和描述文件，对企业客户有一定的吸引力。
在后端数据层，两个平台都为数据库连接量身定做了一套数据存取模型：J2EE的JDBC和.NET的ADO.NET。它们在支持传统SQL数据源的同时，也都支持新型的XML数据源。这方面由于更多地涉及到具体的数据库产品，很难说清哪种数据模型更有优势。
不同的移植、性能和扩展
在移植性方面，.NET通过CLR消除编程语言的差别，而J2EE则通过JVM来消除平台差别。跨平台是J2EE的一大卖点，也是在选择企业应用开发平台时的一个重要参考因素，几乎所有的主流操作系统都提供了对J2EE的支持。实际上如果要搭建跨Unix、Windows等多个操作系统平台，J2EE平台几乎是惟一的选择。J2EE更关注跨平台而不是跨语言。Microsoft认为，如果企业的应用都能通过标准协议以Web Services的方式发布，那么平台都是中立的。跨平台甚至是Microsoft所不想的。为了吸引更多的开发者和鼓励广大企业厂商转到.NET平台，Microsoft提出了多语言支持，希望用跨语言的交互性平衡跨平台的互操作。
性能是J2EE和.NET喋喋不休的话题。二者之间著名的论战是一个关于宠物店的范例应用。宠物店是Sun一直以来作为J2EE典型应用的展示范例。.NET在自己的平台上同样实现了该宠物店应用，且声称代码行是J2EE的1/3，效率却是J2EE的30倍。而Sun认为，这个范例根本不适合用来做性能比较，该范例实现也没有做针对性能的优化，并指责Microsoft通过后端数据库优化(诸如使用Store Procedure)等方法虚抬了.NET平台的效率。 在平台的成熟度方面，两者也有一拼。J2EE在1999年形成了其成熟的架构，并且到今天已经有相当成熟的、经过检验的企业应用系统。而.NET究其渊源是源自微软以前开发企业应用程序的平台DNA（Distributed Network Architecture），其中包括了许多已经被证实的技术，并且这些技术已经在产品中得到实现，包括Microsoft的事务服务器、COM+、消息队列、SQL Server数据库等。对于扩展性，广为业界接受的事实是.NET平台的扩展思想是基于软件的横向扩展，而J2EE平台的扩展思想则是基于硬件的纵向扩展。这也符合Microsoft和Sun各自的产品利益。
J2EE另一个重要特征就是它的架构开放性。它本身是一系列规范，而不是产品，任何符合这一规范的产品都是与J2EE兼容的。这使得J2EE从制定之初就得到了广泛的支持。BEA、IBM、Oracle等都相继开发了符合J2EE的应用服务器，它们的产品相互之间甚至可以兼容。而.NET在设计之初就紧紧地把平台规范与产品胶合在一起。不过随着.NET架构中的C#、CLI 等逐渐标准化，.NET也正在向J2EE的模式靠拢。
Web Services支持的比较
从.NET和J2EE这两个平台的发展历程来看，.NET从一开始就深深打上了Web Services技术的烙印，它的市场推广活动中，无时无刻不凸现其作为Web Services的开发和部署平台的特征。可以说，.NET天生就是为Web Services准备的开发平台和部署平台，也就是Web Services平台。相对.NET而言，J2EE是一个比较“老”的东西，最初它是为了将Java平台拓展到企业级解决方案的应用领域而制定的一个平台框架规范。随着Web Services的兴起和发展，J2EE平台作为一个企业级应用的开发和部署平台，是无法回避业界的重大技术革命—Web Services的，随着Web Services技术的发展，J2EE正不断地将Web Services的支持引入进来。
通过表1可以看出它们之间的不同。
表1 比较J2EE与.NET
标准 J2EE框架 .NET框架
基本设计和对Web Services的支持 通过一组API包(JAXM、JAXP、JAXR、JAX-RPC)对Web Services提供支持。 Web Services直接构建在平台中，.NET框架提供完整的服务标准如SOAP、WSDL和UDDI。
实现 J2EE的Web Services一般是通过EJB来实现。然而也可以把提供Web Services实现的Java应用独立出来，这完全依赖于设计和构建应用程序的业务处理和数据逻辑层。 .NET框架中Web服务的实现一般通过.NET Managed Component(包括Managed Class以及COM/COM+组件)来完成。
价格 与Microsoft的.NET相比，花费较高，然而，如果一个公司已经具有基于J2EE的应用服务器平台，使用现有的基本构架和设备将会比较合适。 比基于J2EE的应用服务器便宜的多，然而目前J2EE仍然是企业服务器端应用的较好选择。
工具和服务器 有多家公司已经构建了基于J2EE的集成开发环境(IDE)和应用服务器。他们中的多数已经开始在产品中支持Web Services的创建、部署和运行，对Web Services标准的支持和复杂的程度因产品而异。 Microsoft进行Web Services开发的基础开发工具(集成开发环境IDE)是Visual Studio.NET，使用Visual Studio能够确保产品的强壮性和易用性。Microsoft同时提供了支持Web Services的服务器软件，包括BizTalk 2000以及SQL Server 2000等。
企业支持 多个独立的公司，包括IBM、BEA、Oracle、HP、Sun等，在它们的基于J2EE的开发工具和应用服务器中正在提供对Web Services的支持。当在这个技术领域中有多个竞争产品时，就意味着没有单个公司的垄断了。 所有的工具、服务器和技术都是由Microsoft公司控制。尽管Microsoft公司对Web Services技术做出的承诺和稳定性没有任何问题，但是没有竞争，技术的提供和推动也许就不是最好的。不过Microsoft刚刚在它的网站上提供了.NET的核心CLI for FreeBSD的原码下载，这也许是一个好的开端。
平台的成熟度 在过去的四年中，J2EE已经被证明是一个稳定的、可扩展的、成熟的平台。新增的、对Web Services的支持是这个平台的又一个特征。 尽管.NET从Windows DNA体系框架中继承了大量的特征，但是相对来说它仍然缺少成熟度，还需要被证明能够提供企业范围的应用框架。
下面将就两个平台对于Web Services的支持上做更详细的比较。
从使用者的角度来看，两者都是Web Services的开发和部署平台。在这里首先从以下四个方面比较两者对Web Services的支持力度：
1. 服务实现 (Service Implementation)；
2. 服务调用和执行 (Service Invocation and Execution)；
3. 服务描述 (Service Description)；
4. 服务发布、发现与绑定 (Service Publishing, Discovery and Binding)。
服务实现
目前来看，实现一个Web Services实际上意味着，首先要将服务调用所需要指定的操作以及操作所涉及的数据结构化，并且将其组织成符合SOAP规范的XML消息文档，然后由Web解释和处理这个XML文档。当一个Web Services被实现之后，这个Web Services的客户端就能够向其发送一个SOAP消息，该SOAP消息中包含了具体需要调用的操作及涉及的数据。这个Web Services接收该SOAP消息并完成处理后，发送客户端相应一个SOAP消息，此时该消息包含了操作的执行结果(返回值)。
在J2EE中，通过使用WSDP中的JAX-RPC(Java API for XML-based RPC)，已有的Java类或Java应用都能够被重新包装，并以Web Services的形式发布。JAX-RPC提供了将RPC参数(in/out)编码和解码的API，使开发人员可以方便地使用SOAP消息完成RPC调用。对于那些使用EJB的商业应用而言，同样可以使用JAX-RPC将EJB包装成Web Services，而这个Web Services的WSDL界面与原先的EJB方法是对应一致的。
JAX-RPC为用户包装了Web Services的部署和实现，对Web Services的开发人员而言，SOAP/WSDL变得透明了，这有利于加速Web Services的开发周期。当然如果开发人员认为这样的透明带来了不灵活性，那么也可以直接使用JAXP手工地处理XML消息。
.NET是一个在J2EE之后出现的平台，它大量地吸收了Java平台，甚至是J2EE平台的优点，其中最重要的一点就是.NET不再完全沿袭Microsoft先前的技术了。从.NET开始，它的应用不再以本地机器代码运行，而是编译成中间代码(Microsoft Intermediate Language)，由称为CLR的虚拟机来运行，这样.NET也具备了强大的跨平台的能力。.NET不但在底层跨平台，在开发语言上也能以较小的代价支持更多的开发语言。它支持的开发语言包括VB.NET、C#、C++、JScript等，这些语言都被编译成相同的中间代码，并且都使用相同的运行库执行。因此从平台特性而言，.NET平台是迄今为止最“通用”的应用开发和部署平台。
在.NET平台上，开发人员可以自由地使用各种语言开发Web Services，同时.NET平台也提供了优秀的快速开发工具，而且.NET的SOAP/WSDL等繁复的技术点对开发人员是透明的。当然，开发人员也可以使用MSXML直接处理XML消息。
服务调用和执行
SOAP为在一个松散的、分布的环境中使用XML，对等地交换结构化的和类型化的信息提供了一个简单且轻量级的机制。
SOAP规范主要由四部分组成：
◆ SOAP信封用于包装数据；
◆
可选的编码风格用于表示应用相关的数据类型以及数据；
◆ 请求/响应的消息交换模式；
◆ 可选的SOAP/HTTP绑定。
SOAP是Web Services的主要通信协议。一个Web Services一般而言是以一个SOAP
Listener的形式存在的。当收到SOAP消息，Web Servieces会将消息解码，并将其中的数据传给相应的商业处理模块进行处理，处理结果回送给SOAP服务器，SOAP服务器再将处理结果包装成响应消息返回调用者。
J2EE使用WSDP中的JAX-RPC完成使用SOAP方法调用远端服务的功能。JAX-RPC使得Java开发人员能够利用符合SOAP/1.1规范的、基于XML的RPC方法，完成Web
Services之间的交互。
当一个JAX-RPC服务被设计并实现之后，它就需要被部署到服务器端的JAX-RPC运行系统中。部署的步骤会视具体实现时使用的组件的不同而有所不同。例如，一个基于EJB的服务就需要被部署到EJB
Container中。
在JAX-RPC服务的部署过程中，可以使用部署配置工具为这个JAX-RPC服务配置一个或多个协议绑定。绑定的实质就是将抽象的服务定义与指定的、基于XML的传输协议相结合。
对于这个Web Services的客户端而言，它应当根据描述该Web
Services的、WSDL文档中所描述的绑定信息与这个Web Services进行远程调用。
对于.NET而言，实现Web Services的方法与J2EE中描述的方法是类似的，同样具有更好的集成性。.NET的开发人员目前实现Web
Services有三种典型的方式，分别是：
◆ 使用内置的.NET SOAP消息类；
◆ 手动地构建一个SOAP Listener，使用诸如MSXML、ASP或者ISAPI等技术；
◆ 使用Microsoft SOAP Toolkit v2构建一个Web Services，这个Web
Services链接了一个商业构件。一般来说，这个商业构件是使用COM技术的，这样有一些类似与J2EE里面的Java类或EJB的SOAP包装。
同样，.NET也是通过Microsoft SOAP Toolkit这样的工具，使得客户端能够根据WSDL文档与Web
Services进行远程交互的。
服务描述
为了使Web Services的应用能够不断增长，非常重要的一点是需要有一种结构化的、可理解的方法描述Web
Services，从而使得Web Services的描述信息能够被程序自动处理，这是Web
Services即时装配的基本保证。WSDL是一种类似IDL技术的服务描述语言，正是需要的方法。WSDL
定义了一套基于 XML的 语法，将Web Services描述为能够进行消息交换的服务访问点的集合，从而满足了这种需求。WSDL文档也将Web
Services定义为服务访问点或端口的集合。在 WSDL
中，由于服务访问点和消息的抽象定义已从具体的服务部署或数据格式绑定中分离出来，因此可以对抽象定义进行重用。
J2EE通过WSDP中的JAX-RPC提供了Web Services的RPC调用的支持，其中Web
Services的RPC调用界面使用的规范正是WSDL。它使用J2EE开发和部署的Web
Services，能够使用WSDL发布它的调用界面。Web Services之间的、所有的XML交互消息及其交互模式，都应当遵循对应的WSDL文档的描述，同时Web
Services的消费者也可以在各种Web Services的注册中心中查询并获取Web
Services的WSDL描述。
与J2EE Web Services相同，.NET Web Services同样支持WSDL 1.1规范，同时采用WSDL作为Web
Services界面的描述工具。此时，我们常常将一个XML命名空间与这个WSDL文档相关联，以便使用这个XML命名空间惟一标识对应WSDL文档所描述的Web
Services。
.NET提供了一个Client端的组件以使应用程序能够调用由WSDL文档描述的、Web
Services的RPC入口，同时在Server端提供了一个组件，以实现从WSDL文档到COM组件的映射。
服务发布、发现与绑定
当Web Services被实现之后，它应该以某种形式发布到某个可提供查询的在线服务站点中，这样可以使得潜在的Web
Services使用者发现这个Web Services。关于如何访问这个Web
Services的技术信息应当同时被发布，这样发现这个Web
Services的客户端就能够通过这些技术信息与Web Services进行交互。具体地说，这些信息称为绑定(Binding)信息。
注册服务是目前用于发布、发现和绑定Web Services的主要方法。注册服务中包含了用于描述Web
Services，以及Web Services提供者的数据结构和分类信息。注册服务既可以由企业自己提供，也可以使用第三方的中立服务。
在J2EE的WSDP中，JAXR （Java API for XML Registries )提供了与多种类型注册服务进行交互的API。JAXR运行与规范兼容的Web
Services，这里的Web Services即为注册服务。一般来说，注册服务总是以Web
Services的形式运行的。
JAXR支持三种注册服务类型，分别为：
◆ JAXR Pluggable Provider，实现了JAXR规范的特性，又独立于任一种指定的注册服务。
◆ Registry-specific JAXR Provider，实现了JAXR规范的特性，同时以指定的某一种注册服务的方式工作。
◆ JAXR Bridge Provider，并不指定一个特定的注册服务，而是作为与其它类型的注册服务交互的桥梁。其它类型的注册服务，可能包括UDDI注册服务或是ebXML注册服务。
对于Microsoft的.NET，最初Microsoft使用一种称为DISCO的文件来发现Web
Services，而随着以Microsoft、IBM、Ariba作为创始企业的UDDI.org发布UDDI规范之后，.NET将UDDI注册服务作为其内置的Web
Services的发布和发现机制。在VS.NET中，内置了一个私有的UDDI
Registry供开发使用，同时提供了一个基于UDDI注册服务的、非常友好的GUI。就目前来看，UDDI提供了最佳的、保证Web
Services互操作性的注册服务。Microsoft也是UDDI实现的领先者，在它的Office
XP中，也提供了使用UDDI集成Web Services的功能。
去年年底，IBM和Microsoft又一起发布了WS-Inspection规范，也称为WSIL（Web
Services Inspection Language）规范。WS-Inspecation将作为UDDI的补充，在兼容UDDI的基础上，为未注册入UDDI注册服务的Web
Services提供发现机制。
在前面的内容中，我们已经看到，在对Web Services的支持上，J2EE和.NET基本上是不相上下的，惟一的区别可能是.NET的开发工具更为方便一些、集成度更高一些。现在考察一下第三方厂商对两种架构的支持。
J2EE作为一种开放的规范，从一开始就得到了众多厂商的支持，如IBM、BEA、HP、Oracle等在J2EE的实施上都洒下了大笔的投资。目前市场上最好的J2EE
Application Server，并不是Sun与Netscape合资的iPlanet，而是Bea的WebLogic和IBM的WebShpere。由于J2EE是开放的规范框架，只要有实力，任意厂商都可以按照规范来开发实现，不同厂商的组件也可以在一起协同使用，当然最关键的还是这些参与J2EE开发的厂商要具有很强的实力。目前，除了Microsoft以外，基本上所有的计算机软件业巨擎都对J2EE情有独钟。
然而，J2EE虽然是开放的规范，但是它的使用却不是那么的开放，每家使用J2EE技术的公司都不得不为此向Sun支付一笔不小的费用。也正因为Sun对J2EE规范的独家控制，使得J2EE规范的开发进度有些缓慢。迄今为止，J2EE规范中并不包含对Web
Services的支持，WSDP只是一种插件形式的扩展支持。有消息表明，今年年底前，Sun和Java领域的其它支持商，如IBM、Bea、Silverstream等会就J2EE如何支持Web
Services达成一致，然而这一切均存在变数，其中的根结就在于Sun对Java技术的独家控制。
同时，由于J2EE对Web Services支持的步履维艰，各大厂商分别自行开发Java平台的Web
Services支持。IBM在这个领域的步伐是飞快的，它的WSAD(Webshpere
Studio Application Developer)集成了大量的自行开发(部分来自于Apache.org，不过这项项目的前身大多是IBM发起的，而后移交给Apache.org的)的Web
Services组件，已称为Java领域开发Web Services的最佳开发工具。同时，IBM的WebSphere也慢慢向Web
Service开发部署应用平台的角色转化。
对于Microsoft的.NET而言，虽然从一开始就以独占、垄断、不开放的形象出现在平台市场上，然而它的.NET却表现出了前所未有的开放姿态。
.NET的主力开发语言C#已经提交给ECMA进行标准化，ECMA是一个致力于推动行业范围内采用信息和通信技术的、非特定供应商的国际标准组织。C#的标准化使希望在任何平台上都可以实现C#编程工具的公司能够实现他们的愿望。Microsoft还向ECMA提交了Microsoft
.NET框架的一个子集，叫做公共语言架构(Common Language
Infrastructure，CLI)，这将使其它供应商能够在各种平台上实现CLI，也使得用.NET框架提供的基本体系结构模型所写的软件可以在各种平台上用各种工具来创建。具体的实施也已经展开：著名的Linux桌面环境GNOME的开发商，美国Ximian公司在2001年7月开始启动一个名叫Mono
Project的开放源码版“.NET”的开发项目，旨在使开发者能够编写同时在Windows和Linux上运行的.NET程序。Mono计划主要包括一个C#编译器、与Microsoft
公司CLI兼容的类库、Linux版CLR编译器。最近，Microsoft又在自己的网站上提供了CLI
for FreeBSD/Windows的原码下载，为推广CLI踏出了探索性的一大步。虽然这些只是起步，然而谁也不能说，它就不会像当初的Java那样，从Sun的小玩具变成了今天如此重要的开发平台。
由于Web Services的各种技术都是先以规范的形式制定，然后再交付各大开发商进行实施的，所以如果某个开发商从一开始就参与某一种Web Services规范的开发，那么它的平台就能够以最快的速度支持这一种Web Services规范。在这一点上，Microsoft给人以非常积极进取的印象。在Web Services领域，Microsoft与IBM共同主推了大量的Web Services规范，在一段时间内，它们两家公司的Web Services技术的市场推广活动都是联合举行的，不难看出这两家公司在这个领域背后的战略合作。从最初的Web Services核心技术SOAP、WSDL主要由这两家制定，到后来的UDDI由这两家为首的多家核心企业共同制订，以及后来的一些不是很核心的Web Services规范，如WS-Inspecation、WSFL、WS-Security、WS-Routing、WS-License、WS-Referral完全由这两家来制定。我们不难看出，Microsoft和IBM对于Web Services的贡献，以及他们对Web Services规范的控制。
Sun自从在XML规范的制定中发挥了重要的作用之后，在其后的Internet规范，尤其是Web Services规范的制定中，声音变得非常地微弱，而且目前似乎并没有改善的趋势。最近，Web Services领域中的一件大事是WS-I.org的成立。WS-I.org是致力于为保证Web Services所承诺的互操作性而成立的一个组织，其主要的工作就是开发保障Web Services互操作性的相关规范，并进行规范实施的测试。WS-I.org的核心成员包括Accenture、Bea、HP、Intel、IBM、Microsoft、Oracle、SAP等，Sun不在其中。这是Sun发展战略的问题，还是其它原因我们不得而知。不过我们可以知道的是，Sun再一次在Web Services领域中落后了，从它控制的J2EE规范的状况就可以看出。
从技术的发展来看，大型的用户或是有着成功实施经验的用户，并不会因为新技术的推出，而盲目地否定旧技术，他们总是在保护投资的前提下，在不推翻现有架构的前提下有选择地挑选适合的技术。
J2EE已经是一个成熟的、成功的企业级应用解决方案，拥有大量的客户。那些已经实施了J2EE的企业不太可能在Web Services的时代中全面否定J2EE而去接收.NET，因为.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 Services组件。
虽然在继承原有技术上，.NET做得不是非常优秀，不过它的整个平台、开发工具的高集成性和友好的开发环境将给开发人员留下深刻印象。在Java领域中，无论是Borland的JBuilder 6，还是Sun的Forte for Java，或是IBM的WebShpere Application Developer及Visualage for Java都无法达到.NET的生产效率。开发工具是.NET的一大优势，同时.NET平台对Web Services规范的支持力度也仅有IBM的Java平台能够与之比拟。
因此，在企业级应用场合，如果已经采用了J2EE架构的，在Web Services的时代会继续使用J2EE架构。而原先就是采用Microsoft架构的，从技术的延续性考虑，大多数会选用Microsoft的.NET。那些采用其它技术的企业级应用，则会视开发效率、安全性、可靠性、维护代价都不同指标对两种架构进行考察。应该说机会是均等的，因为J2EE强在有大量的应用实例，而.NET强在整合集成的优秀开发部署环境。
在中小级别的应用领域，J2EE的占有率优势不再那么明显，因为一贯以来Microsoft特长于这个领域。但是Java解决方案已经是深入人心，即使是中小企业也会考虑J2EE架构，所以在这个领域，两者依然平分秋色。
在桌面应用(Web Service客户端)领域，除了一些管理客户端会采用Java开发以外，绝大多数的应用会在.NET平台上开发和部署。
虽然，J2EE和.NET在吸引用户的方面是在对抗，然而Web Services技术的精髓就是集成整合，即将不同平台框架上的应用整合在一起，形成一个更大的应用服务。因此，J2EE和.NET完全可以利用彼此的优势，在一个统一的Web Services层次上，进行广泛地应用协作和整合。
下面使用一个应用实例演示J2EE平台与.NET平台的整合，图1是一个认证考试申请应用的例子(这个案例纯属虚构)，这里仅作为实例引用，也算是案例预览。
图1所示，Web Services认证机构WSTA开始向公众提供Web Services技术认证服务，一开始这个服务仅在机构内部工作，工作人员通过收取报名表格在桌面应用中为客户完成注册、上课和考试等申请，但这样整个机构的运行效率不高。随着学员的不断增多，WSTA不得不使用Web Services技术来改造应用。首先完成认证考试各项申请的逻辑被包装成EJB Web Service，然后部署在机构内部的Weblogic Application Server上。桌面应用也被升级以支持Web Services调用。为了使得这个认证申请Web Services能够被更多的人通过各种平台使用，这个Web Services被注册进了Public UDDI Registry，并发布了它的WSDL描述文档。同时，WSTA也积极与公共教育平台进行接触，并尝试合作可能。经过一番接触，国家教育信息门户(National Educastion Information Portal)同意与WSTA进行系统对接，以实现在NEIP平台上直接对WSTA提供的Web Services技术认证提供申请服务。NEIP采用的是Microsoft .NET的平台，因此在这里实施了J2EE和.NET平台的连接集成。由于将自身注册入了Public UDDI Registry，WSTA的认证考试申请服务有机会被更多的外部平台集成使用。图1中的Global IT Education Web Service就是一例。
下面，按照图1中序号标明的顺序，逐一讲解这个Web Services集成是如何实施和运作的：
1. 用户可以通过NEIP的界面申请Web Services技术认证的注册、课程和考试；
2. NEIP的Web站点把请求通过Internet发送给WSTA的认证管理Web Services；
3. WSTA的认证管理Web Services通过与机构数据的交互，完成申请事务，并响应NEIP的Web站点，并最终将响应返回终端用户；
4. WSTA认证服务的技术信息被注册入了Public UDDI Registry供公共查询；
5. Global IT Education的在线服务通过搜索Public UDDI Registry，寻找到了WSTA认证申请服务；
6. Global IT Education获得WSTA认证申请服务的技术信息，实现动态绑定；
7. Global IT Education建立与WSTA认证申请服务，此后，任何使用Global IT Education的应用(包括各种应用、Web站点、Web Services)都可以通过Global IT Education的Web Services使用WSTA认证申请服务；
8. WSTA内部的桌面应用同样是使用Web Services界面绑定技术来调用WSTA认证申请服务的。
最后一点，我们再来谈谈J2EE和.NET这两个Web Services平台的目前需要解决的问题。我们知道，要使Web Services真正获得成功，还会遇到许多技术挑战，其中有许多与它们赖以生存的开放不利的环境有关。以下是一些最显著的问题：
◆ 可靠性，某些Web Services主机可能比其它主机更可靠。那么如何测量和传递这个可靠性呢? 当Web Services主机暂时脱机时会发生什么情况? 是寻求和使用其它供应商拥有的替代服务，还是等待原来的那个重新可用呢? 怎么知道哪些供应商可以信赖?
◆ 安全性，某些Web Services将在公开情况下可用而没有保护措施，但大多数与商业相关的服务将使用带认证的加密通信。SSL上的HTTP往往能够提供基本的安全性，但有个别服务需要更高颗粒度级别。Web Services如何认证用户？服务需要在方法级别上提供安全性的能力吗？如果与在世界范围内提供服务的供应商签约，这些服务如何了解你的安全性特权呢？
◆ 事务，传统的事务处理系统使用两阶段提交方式，所有参与的资源都被集中起来，并在整个事务发生之前锁定，等到事务发生后，资源被最后释放。这种方式在事务生存时间很短的封闭环境中很有效，但在事务可能跨越几小时，甚至几天的开放环境中就不那么好用了。
◆ 可伸缩性，因为目前能够将现有的组件系统，例如EJB当作Web Services，所以应该有可能利用已有的负载均衡和其它可伸缩性机制。但在进行的过程中有没有未预见的障碍? 需不需要一种新的Web Services应用服务器?
◆ 可管理性，管理高度分布式的系统需要哪种机制? 因为系统的特性是其各个部分特性的函数，所以每种不同Web Services的管理器是否需要以一种特殊的方式协调？是否可能将一些Web Services的管理“外包”给其它Web Services?
◆ 可计费性，如何定义一个用户可以访问和执行Web Services多久? 如何收取Web Services使用的费用? 占主导地位的模式是基于订阅的还是现购现付的? 如果销售Web Services，如何表明所有权的变更? Web Services是在使用时完全消费，还是可以作为采购协议的一部分多次重用该服务?
对于这两个平台而言，谁先解决了这些问题，谁解决得更好，将在这场Web Services平台的龙虎之争中占得先机。
前面我们已经就技术、厂商支持、规范以及市场几个方面对.NET和J2EE两个平台架构进行了介绍和论述，同时也给出了整合应用的实例。现在使用一张表格来概括两者的比较（见表2）。
表2 评价J2EE与.NET
| J2EE | .NET | ||
| 对Web Services的支持 很好服务实现 服务发布、发现与绑定 服务调用和执行 |
好 好 好 好 |
很好 好 很好 很好 好 好 |
|
| 好第三方支持 平台提供商 很好 软件开发商 |
很好 很好 很好 |
有待考察 有待考察 好 |
|
| 对Web Services规范的控制 | 情况复杂 (注) | 很好 | |
| 市场前景 企业级大型应用 中小级别应用 桌面应用 |
好 差 |
很好 一般 好 很好 |
J2EE的控制者Sun对Web Services规范几乎没有什么控制能力，然而Sun在J2EE上的合作伙伴IBM等对Web
Services规范却具备强大的控制力，所以表格中显示“情况复杂”。
从表格中，我们不难看出两者应该说是旗鼓相当的。在将来的发展中，对抗是在两个平台的控制者之间，而在两个平台的使用者之间，合作整合将远胜过互相对抗。