引言
Web服务(Web Service)，当今IT技术的热点，今后数年中的一个非常重要的技术方向，正
受到万众的瞩目。全球权威IT行业研究评论机构Gartner Group对未来5年的Web服务的发展
状况做了预测：
2001年，Web服务的架构平台、开发工具将基本被各大开放商开发完毕。开发人员能够购买
到这些面向服务的开发工具。同时他们将会开始构建实际使用的Web服务。
2002年，商业Web服务将大量出现，大量的面向消费者的B2C Web服务将被投入使用。
2003年，UDDI注册中心应Web服务的发展，变得越来越重要，其中的商业数据也越来越丰富
。私有的UDDI注册中心将被投入使用以支持内部的服务信息的交换。而政府的Web服务(e-
Government)应用也将会不断出现。
2004年，各类企业将会普遍接受基于Web服务的商务应用模式，而服务集中的计算模式将会
进入青年期。私有的UDDI注册中心仍然在各类应用中处与优势地位。新的收入模式和商业
渠道将到处可见。40％的金融财务服务事务将使用Web服务模式。而35%的在线政府服务将
以Web服务的形式提供。
2005年，公共的UDDI注册中心作为公共商务信息的交换机制而获得大量的使用。动态服务
同样将大量投入使用。
目前，已经是2002年初，Gartner Group的预测似乎被技术提供商稍稍延误了，在上个月，
Microsoft的.NET Framework及其开发工具VS.NET刚刚正式发布。而作为Web服务世界中的
另一个重量级的角色SUN，也在这个月里为它的J2EE Framework增添了开发Web服务的强有
力的工具包Java™ Web Services Developer Pack。这两个开发工具的发布，意味着
Web服务领域的技术对抗真正拉开了阵势。从2002起到2005年，Gartner Group所预测的Bu
siness-To-Consumer、e-Government以及Business-To-Business领域的Web服务的发展将会
大量依赖这两个平台及其上的开发工具。
.NET与J2EE对Web服务的支持
从.NET和J2EE这两个平台的发展历程来看，.NET从一开始就深深打上了Web服务技术的烙印
，它的市场推广活动中，无时无刻不凸现其作为Web服务的开发和部署平台的特征。可以说
，.NET天生就是为Web服务准备的开发平台和部署平台，.NET就是Web服务平台。相对.NET
而言，J2EE是一个比较”老”的东西，最初它是为了将Java平台拓展到企业级解决方案的
应用领域而制定的一个平台框架规范，随着Web服务的兴起和发展，J2EE平台作为一个企业
级应用的开发和部署平台，是无法回避业界的重大技术革命------Web服务的，随着Web服
务技术的发展，J2EE不断地将Web服务的支持引入进来。
从使用者的角度来看，两者都是Web服务的开发和部署平台，在这里，我们将首先来比较一
下两者对Web服务的支持力度，比较将从以下四个方面来进行：
1. 服务描述 (Service Description)
2. 服务实现 (Service Implenmentation)
3. 服务发布、发现与绑定 (Service Publishing, Discovery and Binding)
4. 服务调用和执行 (Service Invocation and Execution)
服务描述 (Service Description)
为了使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交互消息及其交互模式都应当遵循对应的WS
DL文档的描述，同时Web服务的消费者也可以在各种Web服务的注册中心中查询并获取Web服
务的WSDL描述。
与J2EE Web服务相同，.NET Web服务同样支持WSDL 1.1规范，同时采用WSDL作为Web服务界
面的描述工具。此时，我们常常将一个XML命名空间与这个WSDL文档相关联，以使用这个X
ML命名空间来唯一标识这个WSDL文档所描述的Web服务。
.NET提供了一个Client端的组件以使应用程序能够调用由WSDL文档描述的Web服务的RPC入
口，而同时也在Server端提供了一个组件以实现从WSDL文档到COM组件的映射。
服务实现 (Service Implenmentation)
目前来看，实现一个Web服务，实际上是意味着，首先要将服务调用所需要指定的操作以及
操作所涉及的数据结构化，并且将其组织成符合SOAP规范的XML消息文档，然后该Web实现
需要能解释和处理这个XML文档。当一个Web服务被实现之后，这个Web服务的客户端就能够
向其发送一个SOAP消息，该SOAP消息中包含了具体需要调用的操作以及涉及的数据，这个
Web服务接收该SOAP消息并完成处理后，向客户端相应一个SOAP消息，该消息包含了操作的
执行结果(返回值)。
在J2EE中，通过使用WSDP中的Java API for XML-based RPC(JAX-RPC)，已有的Java类或J
ava应用都能够被重新包装，并以Web服务的形式发布。JAX-RPC提供了将RPC参数(in/out)
编码和解码的API，使开发人员可以方便地使用SOAP消息来完成RPC调用。同样，对于那些
使用EJB(Enterprise JavaBeans)的商业应用而言，同样可以使用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 La
nguage Runtime)的虚拟机来运行，这样，.NET也具备了强大的跨平台的可能。.NET不但在
底层跨平台，在开发语言上，则能以较小的代价支持更多的开发语言，它支持的所有开发
语言，包括VB.NET、C#、C++、JScript等都被编译成相同的中间代码，使用相同的运行库
执行。因此，从平台特性而言，.NET平台是迄今为止最”通用”的应用开发和部署平台。
在.NET平台上，开发人员可以自由地使用各种语言来开发Web服务，.NET平台同样提供了优
秀的快速开发工具，将SOAP/WSDL等繁复的技术点对开发人员透明，当然，同样开发人员也
可以使用MSXML来直接处理XML消息。
服务发布、发现与绑定 (Service Publishing, Discovery and Binding)
当Web服务被实现之后，它应该被以某种形式被发布到某个可提供查询的在线服务站点中，
以使得潜在的Web服务的使用者能够发现这个Web服务。关于如何访问这个Web服务的技术信
息应当同时被发布，以使得发现这个Web服务的客户端能够通过这些技术信息与Web服务进
行交互，具体地来说，这些信息称为绑定(Binding)信息。
注册服务是目前用于发布、发现和绑定Web服务的主要方法。注册服务中包含了用于描述W
eb服务以及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 Re
gistry供开发使用，同时提供了一个基于UDDI注册服务的非常友好的Web服务发现的GUI。
就目前来看，UDDI提供了最佳的保证Web服务互操作性的注册服务。而Microsoft也是UDDI
实现的领先者。在它的Office XP中，也提供了使用UDDI集成Web服务的功能。
全年年底，IBM和Microsoft又一起发布了WS-Inspection规范(也称为WSIL规范，Web Serv
ices Inspection Language)，WS-Inspecation将作为UDDI的补充，在兼容UDDI的基础上，
为未注册入UDDI注册服务的Web服务提供发现机制。
服务调用和执行 (Service Invocation and Execution)
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服务的支持上，J2EE和.NET基本上是不相上下的，唯
一的区别可能是.NET的开发工具更为方便一些，集成度更高一些。在这里来考察一下第三
方厂商对两种架构的支持。
J2EE作为一种开放的规范，从一开始就得到了众多厂商的支持，IBM、BEA、HP、Oracle等
都洒下了大笔的投资在J2EE的实施上。目前市场上最好的J2EE Application Server并不是
SUN与Netscape合资的iPlanet，而是Bea的WebLogic和IBM的Webshpere。一年一度的JavaO
NE都有成千的开发商参加。由于J2EE是开放的规范框架，任意厂商只要有实力都可以按照
规范来开发实现，不同厂商的组件也可以在一起协同使用，当然最关键的是这些参与J2EE
的厂商都具有很强的实力，基本上可以这么认为，除了Microsoft以外，基本上所有的计算
机软件业巨擎都对J2EE情有独钟。
然而，J2EE虽然是开放的规范，但是它的使用却不是那么的开放，每家使用J2EE技术的公
司都不得不为此向SUN支付一笔不小的费用。同时也正因为SUN对J2EE规范的独家控制，使
得J2EE规范的开发进度有些缓慢，迄今为止，J2EE规范中并不包含对Web服务的支持，WSD
P只是一种插件形式的扩展支持。有消息表明，在今年年底前，SUN和Java领域的其他支持
商，包括IBM、Bea、Silverstream等会就J2EE如何支持Web服务达成一致，然而这一切均存
在变数，其中的根结就在于Sun对Java技术的独家控制。
同时，由于J2EE对Web服务支持的步履维艰，各大厂商分别自行开发Java平台的Web服务支
持，IBM在这个领域的步伐是飞快的，它的WSAD(Webshpere Studio Application Develop
er)集成了大量的自行开发(部分来自于Apache.org，不过这项项目的前身大多是IBM发起的
，而后移交给Apache.org的)Web服务组件，业已称为Java领域的开发Web服务的最佳开发工
具，同时IBM的Websphere也慢慢向Web Service开发部署应用平台的角色转化。
而对于Microsoft的.NET而言，虽然从一开始，Microsoft就给人以独占、垄断、不开放的
形象出现在平台市场上。然而，它的.NET却表现出了前所未有的开放姿态。
.NET的主力开发语言C# 已经提交给 ECMA 进行标准化，ECMA是一个致力于推动行业范围内
采用信息和通信技术的非特定供应商的国际标准组织。C# 的标准化使希望在任何平台上都
可以实现 C# 编程工具的公司能够实现他们的愿望。Microsoft 还向 ECMA 提交了 Micro
soft .NET 框架的一个子集，叫做公共语言架构(Common Language Infrastructure，CLI
)。这将使其他供应商能够在各种平台上实现 CLI，以便用 .NET 框架提供的基本体系结构
模型所写的软件可以在各种平台上用各种工具来创建。
大家应该能够发现，CLI是类似于Java VM的机制，是.NET跨平台的基本保障。同时具体的
实施也已经开展：著名的Linux桌面环境“GNOME”的开发商，美国Ximian公司在2001年7月
开始启动一个名叫Mono Project的开放源码版“.NET”的开发项目，旨在使开发者能够编
写同时在Windows和Linux上运行的.NET程序，Mono计划主要包括一个C#编译器、与微软公
司的Common Language Infrastructure(CLI)兼容的类库、Linux版Common Language Runt
ime(CLR)编译器。虽然这只是起步，然后谁也不能说，它就不会象当初的Java那样，从Su
n的小玩具，变成了今天如此重要的开发平台。
潜在的市场
从技术的发展来看，大型的用户、或是有着成功实施经验的用户，并不会因为新技术的推
出，而盲目地否定旧技术，他们总是在保护投资的前提下，在不推翻现有架构的前提下，
有选择地挑选适合他们的技术。
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的JBu
ilder 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的平台上开发和部署。
--
FROM 159.226.40.3