L
lql0459
Unregistered / Unconfirmed
GUEST, unregistred user!
/*转自ibm.com.cn
*作者：柴晓路
*/
// 下列已换行，在delphibbs发信息，最头疼的就是换行问题！
//有部分因上下文关系未换行，应不影响阅读！
一.J2EE与.NET概述
Microsoft .NET与SUN J2EE是目前的企业Web服务平台市场的两个最重要的应用框架
(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(Jave企业版)则是一组规范集，每一个规范规定了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等。
二.Web服务规范
由于Web服务的各种技术都是先以规范的形式制订，然后再交付各大开放商进行实施的。
如果从一开始就参与某一种Web服务规范的开发，那么它的平台就能够以最快的速度支持
这一种Web服务规范。在这一点上，Microsoft给人以非常积极进取的映象，在Web服务领
域，Microsoft与IBM共同主推了大量的Web服务规范，在一段时间内，它们两家公司的Web
服务技术的市场推广活动都是联合举行的，不难看出这两家公司在这个领域背后的战略合
作。从最初的Web服务核心技术SOAP、WSDL主要由这两家制订，到后来的UDDI，由这两家
为首的多家核心企业共同制订，以及后来的一些不是很核心的Web服务规范：WS-Inspecation、
WSFL、WS-Security、WS-Routing、WS-License、WS-Referral完全由这两家来制订，我们
不难看出，Microsoft和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下来，我们期待着Microsoft能够提供转换程序以实
现代码的升级。虽然在原代码级别上的升级变得不是那么容易，然而开发人员仍然可以
在.NET平台下，将原有的COM组件进行重新包装，形成.NET平台下的Web服务组件。
虽然在继承旧有技术上，.NET做得不是非常优秀。不过它的整个平台、开发工具的高
集成性和友好的开发环境将给开发人员留下深刻的印象。在Java领域中，无论是Borland的
JBuilder 6、还是SUN的Forte for Java，又或是IBM的WebShpere Application Developer
以及Visualage for Java都无法达到VS.NET的生产效率。开发工具是.NET的一大优势，同
时.NET平台对Web服务规范的支持力度也仅有IBM的Java平台能够与之比拟。
因此，我们认为在企业级应用场合，如果已经采用了J2EE架构的，应该会在Web服务的
时代继续使用J2EE架构。而原先就是采用Microsoft架构的，由于技术的延续性考虑，大多
数仍然会选用Microsoft的.NET。而那些采用其他技术的企业级应用则会视对开发效率，安
全性、可靠性、维护代价都不同指标对两种架构进行考察，应该说机会是均等的，J2EE强在
有大量的应用实例，而.NET强在整合集成的优秀开发部署环境。
在中小级别的应用领域，J2EE的占有率优势不再那么明显，一方面，一贯以来Microsoft
特长于这个领域，另一方面，Java解决方案已经是如此地深入人心，即使是中小企业也会考
虑J2EE架构，在这个领域，两者平分秋色。
而在桌面应用(Web Service客户端)领域，除了一些管理客户端会采用Java开发以外，
绝大多数的应用应当毫无疑问的会使用Microsoft的技术在Microsoft的平台上开发和部署。
四、J2EE vs .NET, 强强对抗
从.NET和J2EE这两个平台的发展历程来看，.NET从一开始就深深打上了Web服务技术的烙印，
它的市场推广活动中，无时无刻不凸现其作为Web服务的开发和部署平台的特征。可以说，
.NET天生就是为Web服务准备的开发平台和部署平台，.NET就是Web服务平台。相对.NET而言
，J2EE是一个比较"老"的东西，最初它是为了将Java平台拓展到企业级解决方案的应用领域
而制定的一个平台框架规范，随着Web服务的兴起和发展，J2EE平台作为一个企业级应用的
开发和部署平台，是无法回避业界的重大技术革命------Web服务的，随着Web服务技术的
发展，J2EE不断地将Web服务的支持引入进来。
有多家公司已经构建了基于J2EE的集成开发环境(IDE)和应用服务器。他们中的多数已经
开始在产品中支持Web服务的创建、部署和运行，对Web服务标准的支持和复杂的程度则随厂
商的不同产品而异。多个独立的公司，包括IBM、BEA、Oracle、HP、SUN等，在他们的基于
J2EE的开发工具和应用服务器的中正在提供对Web服务的支持。当在这个技术领域中有多个
竞争产品，这时就意味着没有单个公司的垄断。在过去的四年中，J2EE已经被证明是一个
稳定的、可扩展的、成熟的平台。新增的对Web服务的支持是这个平台的又一个特征。
Microsoft进行Web服务开发的基础开发工具(集成开发环境IDE)是Visual Studio.NET，
使用Visual Studio能够确保了产品的强壮性和易用性。Microsoft同时提供了支持Web服务
的服务器软件，包括BizTalk 2000以及SQL Server 2000等。然而，这所有的工具、服务
器和技术都是由一家公司控制：Microsoft。尽管Microsoft 公司对Web服务技术的做出的
承诺和稳定性没有任何问题，但是没有竞争，技术的提供和推动也许不是最好的。不过
Microsoft刚刚在它的网站上提供了.NET的核心CLI for FreeBSD的原码下载。这也许是一
个好的开端。尽管.NET从Windows DNA体系框架中继承了大量的特征，但是它仍然相对较新
，需要被证明能够提供企业范围的应用框架。
五、Web服务支持
整体上看，J2EE是通过一组API包(JAXM,JAXP,JAXR,JAX-RPC)对Web服务提供支持。J2EE的
Web服务实现一般是通过EJB来实现的。当然也可以把提供Web服务实现的Java应用独立出来
，这完全依赖于设计和构建应用程序的业务处理和数据逻辑层。
而在.NET中，Web服务直接构建在平台中，.NET框架提供完整的服务标准如SOAP、WSDL
和UDDI。.NET框架中Web服务的实现一般通过.NET Managed Component(包括Managed Class
以及COM/COM+组件)来实现。
从使用者的角度来看，两者都是Web服务的开发和部署平台，在这里，我们将首先来比
较一下两者对Web服务的支持力度，比较将从以下四个方面来进行：
服务实现 (Service Implenmentation)
服务调用和执行 (Service Invocation and Execution)
服务描述 (Service Description)
服务发布、发现与绑定 (Service Publishing, Discovery and Binding)
服务实现
目前来看，实现一个Web服务，实际上是意味着，首先要将服务调用所需要指定的操作以
及操作所涉及的数据结构化，并且将其组织成符合SOAP规范的XML消息文档，然后该Web实
现需要能解释和处理这个XML文档。当一个Web服务被实现之后，这个Web服务的客户端就
能够向其发送一个SOAP消息，该SOAP消息中包含了具体需要调用的操作以及涉及的数据，
这个Web服务接收该SOAP消息并完成处理后，向客户端相应一个SOAP消息，该消息包含了
操作的执行结果(返回值)。
在J2EE中，通过使用WSDP中的Java API for XML-based RPC(JAX-RPC)，已有的Java类
或Java应用都能够被重新包装，并以Web服务的形式发布。JAX-RPC提供了将RPC参数(in/out)
编码和解码的API，使开发人员可以方便地使用SOAP消息来完成RPC调用。同样，对于那些使
用EJB的商业应用而言，同样可以使用JAX-RPC来包装成Web服务，而这个Web服务的WSDL界面
是与原先的EJB的方法是对应一致的。
JAX-RPC为用户包装了Web服务的部署和实现，对Web服务的开发人员而言，SOAP/WSDL变
得透明，这有利于加速Web服务的开发周期。当然如果开发人员认为这样的透明带来了不灵
活性，那么也可以直接使用JAXP来手工地处理XML消息。
.NET是一个在J2EE之后出现的平台，所有的重量级技术产品无一例外地都会吸收先前
的成功者的优点，.NET大量地吸收了Java平台，甚至是J2EE平台的优点，其中，最重要的
一点就是.NET不再完全沿袭Microsoft先前的技术，从.NET开始，.NET应用不再以本地机器
代码运行，而是编译成中间代码(Microsoft Intermediate Language)，由称为CLR
(Common Language Runtime)的虚拟机来运行，这样，.NET也具备了强大的跨平台的可能。
.NET不但在底层跨平台，在开发语言上，则能以较小的代价支持更多的开发语言，它支持
的所有开发语言，包括VB.NET、C#、C++、JScript等都被编译成相同的中间代码，使用相
同的运行库执行。因此，从平台特性而言，.NET平台是迄今为止最"通用"的应用开发和部
署平台。
在.NET平台上，开发人员可以自由地使用各种语言来开发Web服务，.NET平台同样提供
了优秀的快速开发工具，将SOAP/WSDL等繁复的技术点对开发人员透明，当然，同样开发人
员也可以使用MSXML来直接处理XML消息。
七、服务调用和执行
SOAP(Simple Object Access Protocol)为在一个松散的、分布的环境中使用XML对等
地交换结构化的和类型化的信息提供了一个简单且轻量级的机制。
SOAP规范主要由四部分组成：
SOAP信封用于包装数据
可选的编码风格用于表示应用相关的数据类型以及数据
请求/响应的消息交换模式
可选的SOAP/HTTP绑定
SOAP是Web服务的主要通信协议。一个Web服务一般而言是以一个SOAP Listener的形式
存在，当它收到SOAP消息，会将消息解码，并将其中的数据传给相应的商业处理模块进行
处理，处理结果回送给SOAP服务器，SOAP服务器再将处理结果包装成响应消息返回调用者。
J2EE使用WSDP中的Java API for XML-based RPC (JAX-RPC)来完成使用SOAP方法来调
用远端服务的功能。JAX-RPC使得Java开发人员能够利用符合SOAP/1.1规范的基于XML的RPC
方法来完成Web服务之间的交互。
当一个JAX-RPC服务被设计并实现之后，它就需要被部署到服务器端的JAX-RPC运行
系统中。部署的步骤会视具体实现时使用的组件的不同而有所不同，例如，一个基于EJB
的服务就需要被部署到EJB Container中。
在JAX-RPC服务的部署过程中，可以使用部署配置工具来为这个JAX-RPC服务配置一
个或多个协议绑定。绑定的实质就是将抽象的服务定义与指定的基于XML的传输协议相结
合，一个绑定的例子就是在HTTP之上的SOAP 1.1。
而对于这个Web服务的客户端而言，它应当根据描述该Web服务的WSDL文档中所描述
的绑定信息与这个Web服务进行远程调用。
对于.NET而言，实现Web服务的方法与J2EE中描述的方法是类似的，同时具有更好
的集成性。.NET的开发人员目前实现Web服务有三种典型的方式：
使用内置的.NET SOAP消息类
手动地构建一个SOAP Listener，使用诸如MSXML、ASP或者ISAPI等技术
使用Microsoft SOAP Toolkit v2来构建一个Web服务，这个Web服务链接了一个商业构件，一般来说，这个商业构件是使用COM技术的，这个有一些类似与J2EE里面的Java类或EJB的SOAP包装。
同样，.NET也是通过Microsoft SOAP Toolkit这样的工具来使得客户端能够根据描述Web服
务的WSDL文档与Web服务进行远程交互。
八、服务描述
为了使Web服务的应用能够不断增长，非常重要的一点是，我们需要有一种结构化可理
解的方法来描述Web服务，使得Web服务的描述信息能够被程序自动处理，这是Web服务即
时装配的基本保证。而WSDL(Web Services Description Language)正是这样的一种工具，
它是一种类似IDL技术的服务描述语言。WSDL 定义了一套基于 XML的 语法，将Web服务
描述为能够进行消息交换的服务访问点的集合，从而满足了这种需求。WSDL 文档将Web
服务定义为服务访问点或端口的集合。在 WSDL 中，由于服务访问点和消息的抽象定义
已从具体的服务部署或数据格式绑定中分离出来，因此可以对抽象定义进行重用。
J2EE通过Java Web Services Developer Pack(在文章的后面部分，将简称为WSDP)中
的Java API for XML-based RPC(JAX-RPC)提供了Web服务的RPC调用的支持，其中Web服务
的RPC调用界面使用的规范正是WSDL。使用J2EE开发和部署的Web服务，能够使用WSDL来发
布它的调用界面，Web服务之间的所有的XML交互消息及其交互模式都应当遵循对应的WSDL
文档的描述，同时Web服务的消费者也可以在各种Web服务的注册中心中查询并获取Web服
务的WSDL描述。
与J2EE Web服务相同，.NET Web服务同样支持WSDL 1.1规范，同时采用WSDL作为
Web服务界面的描述工具。此时，我们常常将一个XML命名空间与这个WSDL文档相关联，
以使用这个XML命名空间来唯一标识这个WSDL文档所描述的Web服务。
.NET提供了一个Client端的组件以使应用程序能够调用由WSDL文档描述的Web服务
的RPC入口，而同时也在Server端提供了一个组件以实现从WSDL文档到COM组件的映射。
九、服务发布、发现与绑定
当Web服务被实现之后，它应该被以某种形式被发布到某个可提供查询的在线服务
站点中，以使得潜在的Web服务的使用者能够发现这个Web服务。关于如何访问这个Web服
务的技术信息应当同时被发布，以使得发现这个Web服务的客户端能够通过这些技术信息
与Web服务进行交互，具体地来说，这些信息称为绑定(Binding)信息。
注册服务是目前用于发布、发现和绑定Web服务的主要方法。注册服务中包含了用于
描述Web服务以及Web服务提供者的数据结构和分类信息。注册服务即可以由企业自己来提
供，也可以使用第三方的中立服务。
在J2EE的WSDP中，Java API for XML Registries (JAXR)提供了与多种类型注册服
务进行交互的API。JAXR运行客户端访问与JAXR规范向兼容的Web服务，这里的Web服务即
为注册服务，一般来说，注册服务总是以Web服务的形式运行的。
JAXR支持三种注册服务类型：
JAXR Pluggable Provider： 实现了JAXR规范的特性，而又独立于任一种指定的注册服务。
Registry-specific JAXR Provider：实现了JAXR规范的特性，同时以指定的某一种注册服务的方式工作。
JAXR Bridge Provider：并不指定一个特定的注册服务，而是作为与其他类型的注册服务交互的桥梁而存在。其他类型的注册服务可能包括UDDI注册服务或是ebXML注册服务。
而对于Microsoft的.NET，最初，Microsoft使用一种称为DISCO的文件来发现Web服务，而随
着以Microsoft、IBM、Ariba作为创始企业的UDDI.org发布UDDI规范之后，.NET将UDDI注册服
务作为其内置的Web服务的发布、发现机制。在VS.NET中，内置了一个私有的UDDI Registry
供开发使用，同时提供了一个基于UDDI注册服务的非常友好的Web服务发现的GUI。就目前来
看，UDDI提供了最佳的保证Web服务互操作性的注册服务。而Microsoft也是UDDI实现的领先者。
在它的Office XP中，也提供了使用UDDI集成Web服务的功能。
全年年底，IBM和Microsoft又一起发布了WS-Inspection规范(也称为WSIL规范，
Web Services Inspection Language)，WS-Inspecation将作为UDDI的补充，在兼容UDDI的
基础上，为未注册入UDDI注册服务的Web服务提供发现机制。
十、第三方厂商的支持
在前面的内容中，我们已经看到，在对Web服务的支持上，J2EE和.NET基本上是不相
上下的，唯一的区别可能是.NET的开发工具更为方便一些，集成度更高一些。在这里来考
察一下第三方厂商对两种架构的支持。
J2EE作为一种开放的规范，从一开始就得到了众多厂商的支持，IBM、BEA、HP、
Oracle等都洒下了大笔的投资在J2EE的实施上。目前市场上最好的J2EE Application
Server并不是SUN与Netscape合资的iPlanet，而是Bea的WebLogic和IBM的Webshpere。一
年一度的JavaONE都有成千的开发商参加。由于J2EE是开放的规范框架，任意厂商只要有
实力都可以按照规范来开发实现，不同厂商的组件也可以在一起协同使用，当然最关键的
是这些参与J2EE的厂商都具有很强的实力，基本上可以这么认为，除了Microsoft以外，
基本上所有的计算机软件业巨擎都对J2EE情有独钟。
然而，J2EE虽然是开放的规范，但是它的使用却不是那么的开放，每家使用J2EE技术
的公司都不得不为此向SUN支付一笔不小的费用。同时也正因为SUN对J2EE规范的独家控制，
使得J2EE规范的开发进度有些缓慢，迄今为止，J2EE规范中并不包含对Web服务的支持，
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 Service开发部署应用平台的角色转化。
而对于Microsoft的.NET而言，虽然从一开始，Microsoft就给人以独占、垄断、不开
放的形象出现在平台市场上。然而，它的.NET却表现出了前所未有的开放姿态。
.NET的主力开发语言C# 已经提交给 ECMA 进行标准化，ECMA是一个致力于推动行业范
围内采用信息和通信技术的非特定供应商的国际标准组织。C# 的标准化使希望在任何平台
上都可以实现 C# 编程工具的公司能够实现他们的愿望。Microsoft 还向 ECMA 提交了
Microsoft .NET 框架的一个子集，叫做公共语言架构(Common Language Infrastructure，
CLI)。这将使其他供应商能够在各种平台上实现 CLI，以便用 .NET 框架提供的基本体系
结构模型所写的软件可以在各种平台上用各种工具来创建。
大家应该能够发现，CLI是类似于Java VM的机制，是.NET跨平台的基本保障。同时具
体的实施也已经开展：著名的Linux桌面环境"GNOME"的开发商，美国Ximian公司在2001年
7月开始启动一个名叫Mono Project的开放源码版".NET"的开发项目，旨在使开发者能够编
写同时在Windows和Linux上运行的.NET程序，Mono计划主要包括一个C#编译器、与Microsoft
公司的Common Language Infrastructure(CLI)兼容的类库、Linux版Common Language
Runtime(CLR)编译器。最近，Microsoft又在它自己的网站上提供了CLI for FreeBSD/Windows
的原码下载，为推广CLI踏除了探索性的一大步。虽然这些只是起步，然后谁也不能说，它
就不会象当初的Java那样，从Sun的小玩具，变成了今天如此重要的开发平台。
十一、整合J2EE和.NET
虽然，J2EE和.NET在吸引用户的方面是在对抗，然而Web服务技术的精髓就是集成整合，
将不同平台框架上的应用整合在一起，形成一个更大的应用服务。因此J2EE和.NET完全可以
利用他们彼此的优势，在一个统一的Web服务的层次上，进行广泛地应用协作和整合。
下面我们使用一个应用实例来演示J2EE平台与.NET平台的整合，下面是一个认证考试申请
应用的例子。这个例子也是我将在Web Service Case Study系列的第二篇中针对的应用实例
，这里仅作为实例引用，也算是案例预览吧。
Figure 1. J2EE和.NET整合案例图示（因不支持图表，未贴、评论也省略）
十二、发展方向
我们再来谈谈J2EE和.NET这两个Web服务平台的发展方向。我们知道，要使Web服务真正
获得成功，还会遇到许多技术挑战，其中有许多与它们赖以生存的开放、不利的环境有关。
以下是一些最显著的问题：
可靠性。某些Web服务主机可能将比其它主机更可靠。那如何测量和传递这个可靠性呢? 当Web服务主机暂时脱机时会发生什么情况? 您是寻求和使用其它供应商拥有的替代服务，还是等待原来的那个重新可用呢? 您怎么知道哪些供应商可以信赖?
安全性。某些Web服务将在公开情况下可用而没有保护措施，但大多数与商业相关的服务将使用带认证的加密通信。SSL上的HTTP往往能够提供基本的安全性，但有个别服务需要更高颗粒度级别。Web服务如何认证用户？服务需要在方法级别上提供安全性的能力吗？如果您与在世界范围内提供服务的供应商签约，这些服务如何了解您的安全性特权呢？
事务。传统的事务处理系统使用两阶段提交方式，所有参与的资源都被集中起来，并在整个事务发生之前锁定，等到事务发生后，资源被最后释放。这种方式在事务生存时间很短的封闭环境中很有效，但在事务可能跨越几小时，甚至几天的开放环境中就不那么好用了。
可伸缩性。因为目前能够将现有的组件系统，例如Enterprise Java Bean(EJB)当作Web服务，所以应该有可能利用已有的负载均衡和其它可伸缩性机制。但在进行的过程中有没有未预见的障碍? 需不需要一种新的Web服务应用服务器?
可管理性。管理高度分布式的系统需要哪种机制? 因为系统的特性是其各个部分特性的函数，所以每种不同Web服务的管理器是否需要以一种特殊的方式协调? 是否可能将一些Web服务的管理"外包"给其它Web服务?
可计费性。如何定义一个用户可以访问和执行Web服务多久? 如何收取Web服务使用的费用? 占主导地位的模式是基于订阅的还是现购现付的? 如果您销售Web服务，如何表明所有权的变更? Web服务是在使用时完全消费，还是可以作为采购协议的一部分多次重用该服务?
对于这两个平台而言，谁先解决了这些问题，谁解决得更好，将在这场Web服务平台的龙虎之争中占得先机。
十三、小结
在前面，我们已经就技术、厂商支持、规范以及市场的几个方面对.NET和J2EE两个平台
架构进行了介绍和论述，同时我们也给出了整合应用的实例。下面我们使用一张表格来概括
两者的比较：
比较标准 J2EE框架 .NET框架
对Web服务的支持 好 很好
服务实现 好 很好
服务调用和执行 好 好
服务描述 好 好
服务发布、发现与绑定 好 很好
第三方支持 很好 有待考察
平台提供商 很好 有待考察
软件开发商 很好 好
对Web服务规范的控制 情况复杂（注） 很好
市场前景 好 好
企业级大型应用 很好 一般
中小级别应用 好 好
桌面应用 差 很好
注：J2EE的控制者Sun对Web服务规范几乎没有什么控制能力，然而Sun在J2EE上的合作
伙伴IBM等对Web服务规范却具备强大的控制力，所以表格中显示"情况复杂"。
从表格中，我们不难看出，两者应该说是旗鼓相当的两个对手，应该说在将来的发展中，
对抗是在两个平台的控制者之间，而在两个平台的使用者之间，合作整合将远胜过互相对抗。
*作者：柴晓路
*/
// 下列已换行，在delphibbs发信息，最头疼的就是换行问题！
//有部分因上下文关系未换行，应不影响阅读！
一.J2EE与.NET概述
Microsoft .NET与SUN J2EE是目前的企业Web服务平台市场的两个最重要的应用框架
(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(Jave企业版)则是一组规范集，每一个规范规定了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等。
二.Web服务规范
由于Web服务的各种技术都是先以规范的形式制订，然后再交付各大开放商进行实施的。
如果从一开始就参与某一种Web服务规范的开发，那么它的平台就能够以最快的速度支持
这一种Web服务规范。在这一点上，Microsoft给人以非常积极进取的映象，在Web服务领
域，Microsoft与IBM共同主推了大量的Web服务规范，在一段时间内，它们两家公司的Web
服务技术的市场推广活动都是联合举行的，不难看出这两家公司在这个领域背后的战略合
作。从最初的Web服务核心技术SOAP、WSDL主要由这两家制订，到后来的UDDI，由这两家
为首的多家核心企业共同制订，以及后来的一些不是很核心的Web服务规范：WS-Inspecation、
WSFL、WS-Security、WS-Routing、WS-License、WS-Referral完全由这两家来制订，我们
不难看出，Microsoft和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下来，我们期待着Microsoft能够提供转换程序以实
现代码的升级。虽然在原代码级别上的升级变得不是那么容易，然而开发人员仍然可以
在.NET平台下，将原有的COM组件进行重新包装，形成.NET平台下的Web服务组件。
虽然在继承旧有技术上，.NET做得不是非常优秀。不过它的整个平台、开发工具的高
集成性和友好的开发环境将给开发人员留下深刻的印象。在Java领域中，无论是Borland的
JBuilder 6、还是SUN的Forte for Java，又或是IBM的WebShpere Application Developer
以及Visualage for Java都无法达到VS.NET的生产效率。开发工具是.NET的一大优势，同
时.NET平台对Web服务规范的支持力度也仅有IBM的Java平台能够与之比拟。
因此，我们认为在企业级应用场合，如果已经采用了J2EE架构的，应该会在Web服务的
时代继续使用J2EE架构。而原先就是采用Microsoft架构的，由于技术的延续性考虑，大多
数仍然会选用Microsoft的.NET。而那些采用其他技术的企业级应用则会视对开发效率，安
全性、可靠性、维护代价都不同指标对两种架构进行考察，应该说机会是均等的，J2EE强在
有大量的应用实例，而.NET强在整合集成的优秀开发部署环境。
在中小级别的应用领域，J2EE的占有率优势不再那么明显，一方面，一贯以来Microsoft
特长于这个领域，另一方面，Java解决方案已经是如此地深入人心，即使是中小企业也会考
虑J2EE架构，在这个领域，两者平分秋色。
而在桌面应用(Web Service客户端)领域，除了一些管理客户端会采用Java开发以外，
绝大多数的应用应当毫无疑问的会使用Microsoft的技术在Microsoft的平台上开发和部署。
四、J2EE vs .NET, 强强对抗
从.NET和J2EE这两个平台的发展历程来看，.NET从一开始就深深打上了Web服务技术的烙印，
它的市场推广活动中，无时无刻不凸现其作为Web服务的开发和部署平台的特征。可以说，
.NET天生就是为Web服务准备的开发平台和部署平台，.NET就是Web服务平台。相对.NET而言
，J2EE是一个比较"老"的东西，最初它是为了将Java平台拓展到企业级解决方案的应用领域
而制定的一个平台框架规范，随着Web服务的兴起和发展，J2EE平台作为一个企业级应用的
开发和部署平台，是无法回避业界的重大技术革命------Web服务的，随着Web服务技术的
发展，J2EE不断地将Web服务的支持引入进来。
有多家公司已经构建了基于J2EE的集成开发环境(IDE)和应用服务器。他们中的多数已经
开始在产品中支持Web服务的创建、部署和运行，对Web服务标准的支持和复杂的程度则随厂
商的不同产品而异。多个独立的公司，包括IBM、BEA、Oracle、HP、SUN等，在他们的基于
J2EE的开发工具和应用服务器的中正在提供对Web服务的支持。当在这个技术领域中有多个
竞争产品，这时就意味着没有单个公司的垄断。在过去的四年中，J2EE已经被证明是一个
稳定的、可扩展的、成熟的平台。新增的对Web服务的支持是这个平台的又一个特征。
Microsoft进行Web服务开发的基础开发工具(集成开发环境IDE)是Visual Studio.NET，
使用Visual Studio能够确保了产品的强壮性和易用性。Microsoft同时提供了支持Web服务
的服务器软件，包括BizTalk 2000以及SQL Server 2000等。然而，这所有的工具、服务
器和技术都是由一家公司控制：Microsoft。尽管Microsoft 公司对Web服务技术的做出的
承诺和稳定性没有任何问题，但是没有竞争，技术的提供和推动也许不是最好的。不过
Microsoft刚刚在它的网站上提供了.NET的核心CLI for FreeBSD的原码下载。这也许是一
个好的开端。尽管.NET从Windows DNA体系框架中继承了大量的特征，但是它仍然相对较新
，需要被证明能够提供企业范围的应用框架。
五、Web服务支持
整体上看，J2EE是通过一组API包(JAXM,JAXP,JAXR,JAX-RPC)对Web服务提供支持。J2EE的
Web服务实现一般是通过EJB来实现的。当然也可以把提供Web服务实现的Java应用独立出来
，这完全依赖于设计和构建应用程序的业务处理和数据逻辑层。
而在.NET中，Web服务直接构建在平台中，.NET框架提供完整的服务标准如SOAP、WSDL
和UDDI。.NET框架中Web服务的实现一般通过.NET Managed Component(包括Managed Class
以及COM/COM+组件)来实现。
从使用者的角度来看，两者都是Web服务的开发和部署平台，在这里，我们将首先来比
较一下两者对Web服务的支持力度，比较将从以下四个方面来进行：
服务实现 (Service Implenmentation)
服务调用和执行 (Service Invocation and Execution)
服务描述 (Service Description)
服务发布、发现与绑定 (Service Publishing, Discovery and Binding)
服务实现
目前来看，实现一个Web服务，实际上是意味着，首先要将服务调用所需要指定的操作以
及操作所涉及的数据结构化，并且将其组织成符合SOAP规范的XML消息文档，然后该Web实
现需要能解释和处理这个XML文档。当一个Web服务被实现之后，这个Web服务的客户端就
能够向其发送一个SOAP消息，该SOAP消息中包含了具体需要调用的操作以及涉及的数据，
这个Web服务接收该SOAP消息并完成处理后，向客户端相应一个SOAP消息，该消息包含了
操作的执行结果(返回值)。
在J2EE中，通过使用WSDP中的Java API for XML-based RPC(JAX-RPC)，已有的Java类
或Java应用都能够被重新包装，并以Web服务的形式发布。JAX-RPC提供了将RPC参数(in/out)
编码和解码的API，使开发人员可以方便地使用SOAP消息来完成RPC调用。同样，对于那些使
用EJB的商业应用而言，同样可以使用JAX-RPC来包装成Web服务，而这个Web服务的WSDL界面
是与原先的EJB的方法是对应一致的。
JAX-RPC为用户包装了Web服务的部署和实现，对Web服务的开发人员而言，SOAP/WSDL变
得透明，这有利于加速Web服务的开发周期。当然如果开发人员认为这样的透明带来了不灵
活性，那么也可以直接使用JAXP来手工地处理XML消息。
.NET是一个在J2EE之后出现的平台，所有的重量级技术产品无一例外地都会吸收先前
的成功者的优点，.NET大量地吸收了Java平台，甚至是J2EE平台的优点，其中，最重要的
一点就是.NET不再完全沿袭Microsoft先前的技术，从.NET开始，.NET应用不再以本地机器
代码运行，而是编译成中间代码(Microsoft Intermediate Language)，由称为CLR
(Common Language Runtime)的虚拟机来运行，这样，.NET也具备了强大的跨平台的可能。
.NET不但在底层跨平台，在开发语言上，则能以较小的代价支持更多的开发语言，它支持
的所有开发语言，包括VB.NET、C#、C++、JScript等都被编译成相同的中间代码，使用相
同的运行库执行。因此，从平台特性而言，.NET平台是迄今为止最"通用"的应用开发和部
署平台。
在.NET平台上，开发人员可以自由地使用各种语言来开发Web服务，.NET平台同样提供
了优秀的快速开发工具，将SOAP/WSDL等繁复的技术点对开发人员透明，当然，同样开发人
员也可以使用MSXML来直接处理XML消息。
七、服务调用和执行
SOAP(Simple Object Access Protocol)为在一个松散的、分布的环境中使用XML对等
地交换结构化的和类型化的信息提供了一个简单且轻量级的机制。
SOAP规范主要由四部分组成：
SOAP信封用于包装数据
可选的编码风格用于表示应用相关的数据类型以及数据
请求/响应的消息交换模式
可选的SOAP/HTTP绑定
SOAP是Web服务的主要通信协议。一个Web服务一般而言是以一个SOAP Listener的形式
存在，当它收到SOAP消息，会将消息解码，并将其中的数据传给相应的商业处理模块进行
处理，处理结果回送给SOAP服务器，SOAP服务器再将处理结果包装成响应消息返回调用者。
J2EE使用WSDP中的Java API for XML-based RPC (JAX-RPC)来完成使用SOAP方法来调
用远端服务的功能。JAX-RPC使得Java开发人员能够利用符合SOAP/1.1规范的基于XML的RPC
方法来完成Web服务之间的交互。
当一个JAX-RPC服务被设计并实现之后，它就需要被部署到服务器端的JAX-RPC运行
系统中。部署的步骤会视具体实现时使用的组件的不同而有所不同，例如，一个基于EJB
的服务就需要被部署到EJB Container中。
在JAX-RPC服务的部署过程中，可以使用部署配置工具来为这个JAX-RPC服务配置一
个或多个协议绑定。绑定的实质就是将抽象的服务定义与指定的基于XML的传输协议相结
合，一个绑定的例子就是在HTTP之上的SOAP 1.1。
而对于这个Web服务的客户端而言，它应当根据描述该Web服务的WSDL文档中所描述
的绑定信息与这个Web服务进行远程调用。
对于.NET而言，实现Web服务的方法与J2EE中描述的方法是类似的，同时具有更好
的集成性。.NET的开发人员目前实现Web服务有三种典型的方式：
使用内置的.NET SOAP消息类
手动地构建一个SOAP Listener，使用诸如MSXML、ASP或者ISAPI等技术
使用Microsoft SOAP Toolkit v2来构建一个Web服务，这个Web服务链接了一个商业构件，一般来说，这个商业构件是使用COM技术的，这个有一些类似与J2EE里面的Java类或EJB的SOAP包装。
同样，.NET也是通过Microsoft SOAP Toolkit这样的工具来使得客户端能够根据描述Web服
务的WSDL文档与Web服务进行远程交互。
八、服务描述
为了使Web服务的应用能够不断增长，非常重要的一点是，我们需要有一种结构化可理
解的方法来描述Web服务，使得Web服务的描述信息能够被程序自动处理，这是Web服务即
时装配的基本保证。而WSDL(Web Services Description Language)正是这样的一种工具，
它是一种类似IDL技术的服务描述语言。WSDL 定义了一套基于 XML的 语法，将Web服务
描述为能够进行消息交换的服务访问点的集合，从而满足了这种需求。WSDL 文档将Web
服务定义为服务访问点或端口的集合。在 WSDL 中，由于服务访问点和消息的抽象定义
已从具体的服务部署或数据格式绑定中分离出来，因此可以对抽象定义进行重用。
J2EE通过Java Web Services Developer Pack(在文章的后面部分，将简称为WSDP)中
的Java API for XML-based RPC(JAX-RPC)提供了Web服务的RPC调用的支持，其中Web服务
的RPC调用界面使用的规范正是WSDL。使用J2EE开发和部署的Web服务，能够使用WSDL来发
布它的调用界面，Web服务之间的所有的XML交互消息及其交互模式都应当遵循对应的WSDL
文档的描述，同时Web服务的消费者也可以在各种Web服务的注册中心中查询并获取Web服
务的WSDL描述。
与J2EE Web服务相同，.NET Web服务同样支持WSDL 1.1规范，同时采用WSDL作为
Web服务界面的描述工具。此时，我们常常将一个XML命名空间与这个WSDL文档相关联，
以使用这个XML命名空间来唯一标识这个WSDL文档所描述的Web服务。
.NET提供了一个Client端的组件以使应用程序能够调用由WSDL文档描述的Web服务
的RPC入口，而同时也在Server端提供了一个组件以实现从WSDL文档到COM组件的映射。
九、服务发布、发现与绑定
当Web服务被实现之后，它应该被以某种形式被发布到某个可提供查询的在线服务
站点中，以使得潜在的Web服务的使用者能够发现这个Web服务。关于如何访问这个Web服
务的技术信息应当同时被发布，以使得发现这个Web服务的客户端能够通过这些技术信息
与Web服务进行交互，具体地来说，这些信息称为绑定(Binding)信息。
注册服务是目前用于发布、发现和绑定Web服务的主要方法。注册服务中包含了用于
描述Web服务以及Web服务提供者的数据结构和分类信息。注册服务即可以由企业自己来提
供，也可以使用第三方的中立服务。
在J2EE的WSDP中，Java API for XML Registries (JAXR)提供了与多种类型注册服
务进行交互的API。JAXR运行客户端访问与JAXR规范向兼容的Web服务，这里的Web服务即
为注册服务，一般来说，注册服务总是以Web服务的形式运行的。
JAXR支持三种注册服务类型：
JAXR Pluggable Provider： 实现了JAXR规范的特性，而又独立于任一种指定的注册服务。
Registry-specific JAXR Provider：实现了JAXR规范的特性，同时以指定的某一种注册服务的方式工作。
JAXR Bridge Provider：并不指定一个特定的注册服务，而是作为与其他类型的注册服务交互的桥梁而存在。其他类型的注册服务可能包括UDDI注册服务或是ebXML注册服务。
而对于Microsoft的.NET，最初，Microsoft使用一种称为DISCO的文件来发现Web服务，而随
着以Microsoft、IBM、Ariba作为创始企业的UDDI.org发布UDDI规范之后，.NET将UDDI注册服
务作为其内置的Web服务的发布、发现机制。在VS.NET中，内置了一个私有的UDDI Registry
供开发使用，同时提供了一个基于UDDI注册服务的非常友好的Web服务发现的GUI。就目前来
看，UDDI提供了最佳的保证Web服务互操作性的注册服务。而Microsoft也是UDDI实现的领先者。
在它的Office XP中，也提供了使用UDDI集成Web服务的功能。
全年年底，IBM和Microsoft又一起发布了WS-Inspection规范(也称为WSIL规范，
Web Services Inspection Language)，WS-Inspecation将作为UDDI的补充，在兼容UDDI的
基础上，为未注册入UDDI注册服务的Web服务提供发现机制。
十、第三方厂商的支持
在前面的内容中，我们已经看到，在对Web服务的支持上，J2EE和.NET基本上是不相
上下的，唯一的区别可能是.NET的开发工具更为方便一些，集成度更高一些。在这里来考
察一下第三方厂商对两种架构的支持。
J2EE作为一种开放的规范，从一开始就得到了众多厂商的支持，IBM、BEA、HP、
Oracle等都洒下了大笔的投资在J2EE的实施上。目前市场上最好的J2EE Application
Server并不是SUN与Netscape合资的iPlanet，而是Bea的WebLogic和IBM的Webshpere。一
年一度的JavaONE都有成千的开发商参加。由于J2EE是开放的规范框架，任意厂商只要有
实力都可以按照规范来开发实现，不同厂商的组件也可以在一起协同使用，当然最关键的
是这些参与J2EE的厂商都具有很强的实力，基本上可以这么认为，除了Microsoft以外，
基本上所有的计算机软件业巨擎都对J2EE情有独钟。
然而，J2EE虽然是开放的规范，但是它的使用却不是那么的开放，每家使用J2EE技术
的公司都不得不为此向SUN支付一笔不小的费用。同时也正因为SUN对J2EE规范的独家控制，
使得J2EE规范的开发进度有些缓慢，迄今为止，J2EE规范中并不包含对Web服务的支持，
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 Service开发部署应用平台的角色转化。
而对于Microsoft的.NET而言，虽然从一开始，Microsoft就给人以独占、垄断、不开
放的形象出现在平台市场上。然而，它的.NET却表现出了前所未有的开放姿态。
.NET的主力开发语言C# 已经提交给 ECMA 进行标准化，ECMA是一个致力于推动行业范
围内采用信息和通信技术的非特定供应商的国际标准组织。C# 的标准化使希望在任何平台
上都可以实现 C# 编程工具的公司能够实现他们的愿望。Microsoft 还向 ECMA 提交了
Microsoft .NET 框架的一个子集，叫做公共语言架构(Common Language Infrastructure，
CLI)。这将使其他供应商能够在各种平台上实现 CLI，以便用 .NET 框架提供的基本体系
结构模型所写的软件可以在各种平台上用各种工具来创建。
大家应该能够发现，CLI是类似于Java VM的机制，是.NET跨平台的基本保障。同时具
体的实施也已经开展：著名的Linux桌面环境"GNOME"的开发商，美国Ximian公司在2001年
7月开始启动一个名叫Mono Project的开放源码版".NET"的开发项目，旨在使开发者能够编
写同时在Windows和Linux上运行的.NET程序，Mono计划主要包括一个C#编译器、与Microsoft
公司的Common Language Infrastructure(CLI)兼容的类库、Linux版Common Language
Runtime(CLR)编译器。最近，Microsoft又在它自己的网站上提供了CLI for FreeBSD/Windows
的原码下载，为推广CLI踏除了探索性的一大步。虽然这些只是起步，然后谁也不能说，它
就不会象当初的Java那样，从Sun的小玩具，变成了今天如此重要的开发平台。
十一、整合J2EE和.NET
虽然，J2EE和.NET在吸引用户的方面是在对抗，然而Web服务技术的精髓就是集成整合，
将不同平台框架上的应用整合在一起，形成一个更大的应用服务。因此J2EE和.NET完全可以
利用他们彼此的优势，在一个统一的Web服务的层次上，进行广泛地应用协作和整合。
下面我们使用一个应用实例来演示J2EE平台与.NET平台的整合，下面是一个认证考试申请
应用的例子。这个例子也是我将在Web Service Case Study系列的第二篇中针对的应用实例
，这里仅作为实例引用，也算是案例预览吧。
Figure 1. J2EE和.NET整合案例图示（因不支持图表，未贴、评论也省略）
十二、发展方向
我们再来谈谈J2EE和.NET这两个Web服务平台的发展方向。我们知道，要使Web服务真正
获得成功，还会遇到许多技术挑战，其中有许多与它们赖以生存的开放、不利的环境有关。
以下是一些最显著的问题：
可靠性。某些Web服务主机可能将比其它主机更可靠。那如何测量和传递这个可靠性呢? 当Web服务主机暂时脱机时会发生什么情况? 您是寻求和使用其它供应商拥有的替代服务，还是等待原来的那个重新可用呢? 您怎么知道哪些供应商可以信赖?
安全性。某些Web服务将在公开情况下可用而没有保护措施，但大多数与商业相关的服务将使用带认证的加密通信。SSL上的HTTP往往能够提供基本的安全性，但有个别服务需要更高颗粒度级别。Web服务如何认证用户？服务需要在方法级别上提供安全性的能力吗？如果您与在世界范围内提供服务的供应商签约，这些服务如何了解您的安全性特权呢？
事务。传统的事务处理系统使用两阶段提交方式，所有参与的资源都被集中起来，并在整个事务发生之前锁定，等到事务发生后，资源被最后释放。这种方式在事务生存时间很短的封闭环境中很有效，但在事务可能跨越几小时，甚至几天的开放环境中就不那么好用了。
可伸缩性。因为目前能够将现有的组件系统，例如Enterprise Java Bean(EJB)当作Web服务，所以应该有可能利用已有的负载均衡和其它可伸缩性机制。但在进行的过程中有没有未预见的障碍? 需不需要一种新的Web服务应用服务器?
可管理性。管理高度分布式的系统需要哪种机制? 因为系统的特性是其各个部分特性的函数，所以每种不同Web服务的管理器是否需要以一种特殊的方式协调? 是否可能将一些Web服务的管理"外包"给其它Web服务?
可计费性。如何定义一个用户可以访问和执行Web服务多久? 如何收取Web服务使用的费用? 占主导地位的模式是基于订阅的还是现购现付的? 如果您销售Web服务，如何表明所有权的变更? Web服务是在使用时完全消费，还是可以作为采购协议的一部分多次重用该服务?
对于这两个平台而言，谁先解决了这些问题，谁解决得更好，将在这场Web服务平台的龙虎之争中占得先机。
十三、小结
在前面，我们已经就技术、厂商支持、规范以及市场的几个方面对.NET和J2EE两个平台
架构进行了介绍和论述，同时我们也给出了整合应用的实例。下面我们使用一张表格来概括
两者的比较：
比较标准 J2EE框架 .NET框架
对Web服务的支持 好 很好
服务实现 好 很好
服务调用和执行 好 好
服务描述 好 好
服务发布、发现与绑定 好 很好
第三方支持 很好 有待考察
平台提供商 很好 有待考察
软件开发商 很好 好
对Web服务规范的控制 情况复杂（注） 很好
市场前景 好 好
企业级大型应用 很好 一般
中小级别应用 好 好
桌面应用 差 很好
注：J2EE的控制者Sun对Web服务规范几乎没有什么控制能力，然而Sun在J2EE上的合作
伙伴IBM等对Web服务规范却具备强大的控制力，所以表格中显示"情况复杂"。
从表格中，我们不难看出，两者应该说是旗鼓相当的两个对手，应该说在将来的发展中，
对抗是在两个平台的控制者之间，而在两个平台的使用者之间，合作整合将远胜过互相对抗。