级别： 初级 Reiner Kraft (rekraft@almaden.ibm.com), 高级软件工程师, IBM Almaden Research Center
2002 年 4 月 01 日 本文对两个开发环境和工具 IBM WebSphere Studio ApplicationDeveloper 和 Microsoft Visual Studio .NET 作了一个高级别的概览。文章着重论述它们如何支持 Web 服务的开发并向您讲述两者概念上的差异。
© 2002 International Business Machines Corporation. All rights reserved.
介绍
最近，IBM 发行了 WebSphere® Studio Application Developer 产品，这是一个允许您创建可用于跨异类系统部署的开放、与平台无关的 Web 服务的开发环境。本质上，Application Developer 合并了 VisualAge® for Java™ 和早期的 WebSphere Studio 产品中的功能。不过，它也添加了包括 XML 工具和 Web 服务支持在内的许多新功能。
Microsoft® 最近也向 MSDN 订购者发行了 Visual Studio® .NET（发行候选版），它允许开发者编写、构建和测试 .NET 应用程序；ASP .NET、通用语言运行库（Common Language Runtime）、文档、样本、工具以及命令行编译器都是其中的一部分。最终版本可望于 2002 年 2 月推出。
虽然这两个解决方案都基于开放标准（例如：XML、
SOAP、WSDL、UDDI（基本规范）），但它们之间还是有很多差异（例如：框架、编程语言、运行时、服务发现、术语等等）。本文（即本系列的第 1 部分）对这两个开发环境和工具作了一个高级别的概览，着重论述它们如何支持 Web 服务的开发。本文的目标是向您讲述两者在概念上的差异。
去年，我撰写了两篇比较 IBM 的 WSTK/WSDE 和 Microsoft 的 Visual Studio .NET 的文章：
自那以后，发生了很多变化。包括 WSDE 预发行版在内，IBM 的 WSTK 技术概念已被采用并集成到新的 Application Developer 中。那些熟悉 WSTK 的人将在 Application Developer 中看到相似的功能。当然，微妙的差异是存在的。但将所有重要的开发工具和技术（例如：Java、XML、Web 站点开发以及 Web 服务）集成到一个 IDE 中的结果对开发者而言是一个极好的变动。IBM 的 Application Developer 支持将 Java 作为主要的语言选择。今天，Application Developer 的 GUI 使开发方便了很多，也轻松了很多。而且，Application Developer 的 Web 服务工具支持在开放源代码、多平台的 Apache Tomcat 上的托管。这对那些不是在基于 Windows® 的环境中工作的用户而言将是一个重要的功能。Application Developer 也将很快可以在 Linux 上使用，所以它并不是只依靠于一种环境。
与早期的 Beta 测试版相比，Visual Studio .NET 的当前发行候选版中有几个变化与 Web 服务相关。其中大多数变化都是预料中的，例如使用 Web 服务描述语言作为替代技术和对 UDDI 的支持。在 Beta 测试版版本 2 及更早版本中，用 SDL 和 SCL 描述 Web 服务。鉴于 W3C 在
WSDL上所做的标准化努力，Microsoft 现在选择使用 WSDL 作为描述 Web 服务接口和实现的语言。至于所使用的语言，Microsoft 的 .NET 及其通用语言运行库（CLR）主要使用 C#、VB .NET 和 C++（或者最近添加的替代 Java 的 Visual J#，因为不支持 Java）。还添加了对 UDDI 作为服务目录和发现机制的支持。
能看到 IBM 的和 Microsoft 的解决方案支持相同的 Web 服务技术开放标准（基本规范）是件好事。
本文将概述这两个环境和工具，以帮助您判断哪一个环境更适合您当前的 Web 服务开发需要。第 1 部分将只考察与 Web 服务有关的功能，因此并不对 IDE 的其它重要部分（例如 XML 工具）作比较。请注意，Visual Studio .NET 的最终版尚未发行。由于可用版本间的差异，要做一个“完全的”比较就更加困难了。本文简要描述一下现状，确定进行比较的关键的方面，并着重具体论述这些方面。本文不强调 beta 测试发行版中通常存在的小问题。同时，对现状进行考察是值得的。
本文分为以下部分：
-
概念方面的概览-- 对 IBM WebSphere Studio Application Developer 和 Microsoft Visual Studio .NET 所支持的概念作一个高级别的概览。
-
工具和开发环境概览-- 考察这两个开发环境并介绍所提供的便于 Web 服务的开发的重要工具。这一部分也简要讨论值得一提的系统要求、设置和安装问题。
本文着重论述 IBM 的 Application Developer 和 Microsoft 的 .NET 如何遵循提议的 Web 服务标准。本文特别讨论了对当前 Web 服务协议栈（SOAP、WSDL 和 UDDI）的支持。在每一部分的末尾，我对重要差异作了一个总结。
总之，本文叙述我从使用这两个产品中获得的经验。本文是对我以前所写的与 Visual Studio .NET 有关的文章的技术更新，而且添加了取代 WSTK/WSDE 的新的 Application Developer 主题。本文的目标是帮助那些刚刚开始开发 Web 服务的开发者理解这两种环境。对于使用过其中一种开发环境的开发者，本文将使他了解另一种环境并指出两者间的差异和兼容性问题。
先决条件
本文假设您对 Web 服务和 Web 服务协议栈有一定程度的熟悉：
您可以在
IBM developerWorks找到很多关于 Web 服务的基础知识的好文章。
下载Application Developer 的一个 60 天免费试用版。要测试该环境，您也应安装 .NET 框架，它随 Visual Studio .NET 发行版一起提供，订购者可以从
MSDN Web 站点获得 Visual Studio .NET 发行版。您也可以从
MSDN 下载站点下载 .NET 框架。如果您对 Visual Studio 先前的版本，如版本 6.0 有点熟悉，则您可以从本文学到更多东西，但这不是必需的。MSDN 订购者可以获得 Visual Studio .NET 的发行候选版。
理想的情况是，本文的目标开发者已经使用 IBM WebSphere Studio Application Developer 或 Microsoft Visual Studio .NET 设计过 Web 服务，而且想知道它们如何能够使用其它技术完成相同的任务（或更多任务）。
IBM 的 Web 服务倡议
WebSphere Studio Application Developer 的最新发行版体现了集成的成就。Application Developer 中的 Web 服务功能源自 Web services toolkit（WSTK），并且结合了 IBM 在公开发行 WSTK 那段时间获得的所有经验和开发者反馈。IBM 最近在
IBM alphaWorks上发行了其工具箱的最新版本 WSTK 2.4.2，它包含有各种工具以支持开发者开始实现和部署 Web 服务。这个最新的发行版提供 Web 服务协议栈、WS-Inspection、WebSphere 4.0 支持、HTTPR 演示、XKMS 原型、Web Services for Browser 以及运行时和工具的增强功能。此外，IBM 的
alphaWorks 站点还为开发者提供非常有用的工具：例如 Web Services Invocation Framework、Lotus Web Service Enablement Kit、Web Services Process Management Toolkit 和一个用于 Web 服务的 Business Explorer。XML 和 Web 服务开发环境（Web Service development environment（WSDE））不再作为单独的下载包提供，因为它已被集成进 Application Developer。此外，
IBM developerWorks提供更多关于 Web 技术和 Web 服务的资源。WebSphere Studio Workbench（IBM 的新的、开放的、可移植的通用工具平台和集成技术的品牌名）为开发 Web 服务提供一种使用 GUI 的简单方法。
IBM 一直在为开发者社区和各种与 Web 服务相关的新技术出力。例如：
- 用于 Web 服务的 Business Explorer（UDDI 浏览引擎）
- Web 服务体验语言（Web services experiences language（WSXL）），它描述 Web 服务的可视的交互式界面
- Web 服务调用框架（Web service invocation framework（WSIF）），它提供用于调用 Web 服务的标准 API
- UDDI 注册中心
- HTTPR 规范（一种用于在 HTTP 1.1 协议上进行消息的
可靠传输的新协议）草案
有了
全局 XML Web 服务体系结构（Global XML Web Services Architecture）方面的共同工作，我们可以期望会在这个领域看到更多新的、有趣的技术。IBM 和 Microsoft 最近结成的联盟 -- “Web Service Interoperability Organization”-- 表示为了提高 Web 服务的跨多平台、跨应用、跨编程语言的互操作性所作的开放业界努力又迈进了一步。
Microsoft 的 Web 服务倡议
Microsoft 的 .NET 平台是大约两年前在 Microsoft 的开发者大会（PDC）上随其 Visual Studio .NET 预览版一起介绍的。目前，MSDN 订购者可以下载这个发行候选版，最终版预计于 2002 年 2 月推出。.NET 平台支持 XML Web 服务体系结构，并且还合并进了更多的功能和先进技术（例如 ASP+、新的编程语言 C#、.NET 框架和 CLR 等等）。请注意 Web 服务前的术语“XML”。这是最近添加上去的，可能是用来着重强调作为底层通用语言的 XML。Microsoft 现在也以下载的方式提供 SOAP Toolkit，版本 2.0（黄金版）（
MSDN）。本文不详细概述 .NET 平台，也不提供 Visual Studio .NET 的教程。这些信息已在 .NET 框架工具随带的联机文档中提供，而且在 MSDN 和其它讨论这个主题的 Web 上有大量的教程、文章和其它参考资料。
ECMA此时已经完成了 .NET 框架和 C# 编程语言的公共语言基础架构的标准化。而且，
Microsoft Visual J#™ .NET（一种用于 .NET 平台与 Java 兼容的语言）的 beta 测试版，也已经可以下载和测试。在操作系统方面，Microsoft 正在 .NET 服务器（目前是 beta 测试版 3）方面努力，.NET 服务器集成了对 Web 服务协议栈（包括 UDDI）的本地支持。
Microsoft 把为应用集成和聚合提供基础的一组
基本规范（XML、SOAP、WSDL 和 UDDI）和
全局 XML Web 服务体系结构（一组构建在基本规范上的规范）区别开来。IBM 和 Microsoft 于 2001 年 4 月在 W3C 有关 Web 服务的专题研讨会（W3C Workshop on Web Services）上共同提出了这个
框架。一组技术预览和提议已经可用：
- WS-Inspection（它可以用来协助检查一个站点的可用服务）。
- WS-License（它描述如何对 X.509 证书、Kerberos 凭单和任意的二进制凭证进行编码）。
- WS-Referral（它提供一种机制来动态配置消息路径中的 SOAP 节点，以定义这些结点应如何处理 SOAP 消息）。
- WS-Routing（它使基于 SOAP 的协议能够在各种传输协议（如 TCP、UDP 和 HTTP）上以异步方式路由 SOAP 消息）。
- WS-Security（它描述对 SOAP 消息传递的增强，提供三个功能：凭证交换、消息完整性和消息机密性）。
- XLANG（业务组织语言（business orchestration language））。
除这些规范之外，Microsoft 正计划在
全局 XML Web 服务体系结构继续发布更多规范。
IBM 的 Application Developer 所支持的 Web 服务概念
在 IBM 的 Application Developer 术语中，Web 服务本身就被直接称为
服务，服务就代表应用。Application Developer 的 Web 服务角色模型仍然基于这个随 WSTK 一起被引入的设计。
服务提供者是一个实体，它托管服务。然后有
服务注册中心。服务注册中心充当 Web 服务的服务中介者。服务提供者可以发布它们提供的服务。相似地，
服务接口提供者可以发布服务的接口（例如，一个标准组织）。
服务请求者（客户）接着可以查询服务注册中心，找到想要的服务的实现（它实现一个特定接口），然后绑定到服务实现。虽然术语不同，但我们仍然可以映射到 .NET（下一部分将提供对 .NET 的进一步描述）：
- （.NET）XML Web 服务客户 =>（IBM）服务请求者
- （.NET）XML Web 服务 =>（IBM）服务、服务提供者、服务接口提供者
- （.NET）目录服务 =>（IBM）服务注册中心
图 1. IBM 的 Web 服务角色及交互作用
其中有两个主要的、互补的使用方案和操作：
-
查找（Find）和绑定（Bind）-- 在设计期间，软件开发者使用 UDDI Explorer 浏览或搜索服务注册中心。搜索结果是一个服务接口的描述（WSDL），开发者可以用它来构建客户应用程序。然后开发者可以创建一个 Java 客户代理来与这个 Web 服务通信。另一种方案是开发者可以选择实现 Web 服务，它遵循他们在 UDDI 注册中心发现的 WSDL 定义。在这种情况下，开发者将使用 Application Developer 的 Web 服务工具来创建 Web 服务的 Java 骨架程序实现，然后填充业务逻辑。此外，开发者可以选择直接访问 uddi4j API 进行动态调用：在运行时期间，客户应用程序将查询 UDDI 注册中心，以找出实现特定服务接口的哪些服务是可用的。一旦选择了服务提供者的一个特定服务，客户就将直接绑定到该服务。这意味着客户应用程序将动态地调用服务以完成任务。
-
发布 -- 服务提供者或服务接口提供者需要发布服务描述文件。正如前面所讨论的，服务接口提供者将只需要发布服务接口，而服务提供者将需要发布该服务的实现，服务的实现指向（或导入）一个特定的服务接口。服务提供者使用 API 函数将服务接口发布到服务注册中心。服务接口将被作为 tModel（UDDI 术语）存储，并且通过
<overviewURL> 标记包含一个对 WSDL 文件的引用（另请参阅
Understanding WSDL in a UDDI registry了解更多细节）。
最后一步是，服务提供者将代码部署到服务容器（应用服务器、SOAP 服务器）中，这样就可以首选使用 HTTP 上的 SOAP 访问代码。
在这种模型中，服务接口提供者和服务实现有很大不同。由于 WSDL 允许这种分离，所以把这种模型建到 .NET 中也是可能的。WebSphere Studio Application Developer，版本 4.0.2 使生成能消费 .NET 样式的 SOAP 消息的代理类成为可能。这里的差异是 Application Developer 期望有两个 WSDL 文件（一个用于服务接口，一个用于服务实现），而 .NET 则将两者合并为一个 WSDL 文件。Application Developer 最近的这一扩展为开发者提供了这两个不同平台间更好的互操作性。
目前还没有对额外发现机制（如 .NET 的基于文件的发现方法（DISCO））的支持。不过，提议的 DISCO 方法会如何将自己制定成一个开放标准，还是会被 Web 服务探查语言（Web Services Inspection Language（WSIL））取代还有待观察。WSIL 是由 IBM 和 Microsoft 提议的，用来在广告 Web 服务方面补充 UDDI，WSIL 与使用 DISCO 的基于文件的发现方法相似。由于 IBM 和 Microsoft 已经宣布将把 WSIL 规范提交给标准组织，WSIL 可能将取代 DISCO。
Microsoft 的 .NET 所支持的 Web 服务概念
让我们来看看 Microsoft 的 XML Web 服务基础架构（请参阅下面的图 2 请注意，图 2 取自 .NET 文档）。四个基础架构块之间存在差异：
-
XML Web 服务目录（Directory） -- UDDI 作为目录的一种选择，为了定位由其它组织提供的 Web 服务而提供中心位置。客户使用预定义的 UDDI API 将查询发送到 UDDI。其结果是返回一个指向一个发现或 Web 服务描述文档的 URL。如果客户已经知道目标 Web 服务的描述和位置，则这一步是可选的。请注意，UDDI 支持已被添加到 Visual Studio .NET 的发行候选版中，它补充了基于文件的 DISCO。IBM 和 Microsoft 各自维护公共 UDDI 库。
-
XML Web 服务发现（Discovery） -- 它处理定位或发现一个或多个有关文档的过程，这些文档使用 Web 服务描述语言（WSDL）描述特定的 XML Web 服务。基于文件的 DISCO 机制允许编程式的发现（例如，使用 crawling 技术），并且被用于定位服务描述。本质上，这些 DISCO 文件被放置在 Web 服务器的虚拟目录。它们提供到这个服务器所托管的可用 Web 服务的链接。同样，如果客户已经知道一个特定 Web 服务的描述和位置，则这一步是可选的。基于文件的发现补充了基于 UDDI 的发现。
-
XML Web 服务描述（Description） -- 在客户能够消费或使用一个特定的 Web 服务之前，客户需要知道如何与 Web 服务进行交互（消息交换格式等）。WSDL 用于描述 Web 服务。请注意，Visual Studio .NET 先前版本中的 SDL/SDL 已被 WSDL 替代。
-
XML Web 服务有线格式（Wire Format） -- SOAP（HTTP 之上的 XML）被用作通信的有线格式。SOAP 被看作是在非集中式、分布式环境中进行信息交换的轻量级协议。
图 2. .NET 中的 XML Web 服务基础架构
在 .Net 的 Web 服务领域的概念中，有三个实体或角色：
XML Web 服务客户（XML Web service client）、
XML Web 服务（XML Web service）本身和
目录服务（Directory Service）。首先，
Web 服务客户可以为特定服务需要查询 UDDI 目录服务。例如，客户对信用卡验证服务有兴趣。UDDI 通过标准化的 API 提供服务目录（黄页、白页和绿页）和搜索功能。如果客户已经知道使用哪一个服务，则不需要这一步骤。因此，在这个基础架构中，可以用一种不同类型的目录服务代替 UDDI。
接着，客户请求一个发现文档（DISCO 文件），按照约定，发现文档通常驻留在 Web 服务器的根目录（如果主机已知）。发现文档包含指向服务描述和位置的指针。我们可以看到，这种基于文件的发现对 UDDI 是一个补充，而且可以被客户以类似 crawler 的方式使用。同样，如果客户已经知道 Web 服务的 URL，则这一步可以省略。
Web 服务客户接着用 HTTP 从已知的 URL 请求该服务描述，服务描述以 WSDL 文档的形式提供。返回的 WSDL 文档包含调用 Web 服务所需的所有必要的技术信息（参数列表、数据类型等）。对已经拥有 Web 服务描述的客户来说，这一步也是可选的。
最后，客户通过使用 SOAP 向 XML Web 服务发出一个请求以传递一条消息，这条消息包含有要调用的方法名、参数等。接着，XML Web 服务处理该请求并返回一个包含计算结果的 SOAP 信封。
IBM 的 Application Developer 中的 Web 服务工具概览
Application Developer 是一种可视化开发环境，用于构建 Java 应用程序、Web 站点、DTD、XML 模式、XML、XSLT 以及在 XML 和不同的后端存储之间进行映射。我们仍旧把重点放在那些与 Web 服务开发有关的方面。Application Developer 补充了 WebSphere Application Server 4.0，后者用于部署 Web 服务。安装也很简单。当您安装 Application Developer 时，将安装 WebSphere Application Server 的一个测试版，这样您就可以开始进行开发和测试，而不用担心应用服务器设置。另一件好事是，这个测试设置中的两个环境可以在同一台机器上并存而不会有什么问题。Application Developer 用端口 8080 进行测试，而 Microsoft 的 Internet Information Server（IIS）则在端口 80 上运行。
Application Developer 引入“Web 服务向导（Web Services Wizards）”以帮助方便 Web 服务的开发（Application Developer附带很多详细讲述这些各种各样的向导的教程）：
-
Web Services Creation Wizard -- 用这个向导创建 Web 服务 Java 类，或者创建消费 Web 服务的 Java 代理客户和 JSP 文件。这个向导要求您输入 Java 类、企业 bean、接收和返回数据的 URL 以及 DB2® XML Extender 调用。通过文档访问定义扩展（Document Access Definition eXtension（DADX）），DB2 存储过程（Stored Procedures）和 SQL 查询得到支持。
-
Web Services Client Wizard -- 用这个向导来从 JavaBeans™、DADX、URL 或无状态会话 EJB 创建能访问和测试现有已部署的 Web 服务的 Java 客户。调用 Web 服务的模型建立在使用 WSDL 创建远程 Java 代理的基础上，远程 Java 代理接着使用用于调用机制的 SOAP、HTTP GET 或 HTTP POST（取决于可用且被选中的绑定）。
注：DADX 文档使用一套操作来指定 Web 服务，这套操作由 IBM 的 XML Extender DAD 文档或 SQL 语句定义。DADX 文件中指定的 Web 服务被称为 DADX Web 服务。
-
Web Services DADX Group Configuration wizard -- 用这个向导处理访问 DB2 和存储在 DB2 中的 XML 数据的 Web 服务。
-
IBM UDDI Explorer -- 使用这个 JSP 应用程序浏览 UDDI 业务注册中心以定位现有的用于集成的 Web 服务。提供 UDDI4J 作为类库支持与 UDDI 注册中心进行交互。
我们可以从所支持的工具中看出，这个开发环境把 Java 作为开发 Web 服务的主要选择，这是 Visual Studio .NET 和 Application Developer 之间的主要不同之处。
Application Developer 的 Web 服务工具也支持在开放源代码、多平台的 Apache Tomcat 上进行托管，对那些不在基于 Windows 的环境中工作的用户来说，这是一个重要的功能，因为 .NET 目前仅支持在 Windows 上使用。
目前，在 Microsoft 的 .NET 中没有与 UDDI Explorer 等同的东西。不过，UDDI .NET SDK 1.75 Beta 测试版添加了对 UDDI 的支持，并且随带了一个 UDDI 浏览器以演示这项功能，可以从
MSDN站点下载 UDDI .NET SDK 1.75 Beta 测试版。这使得在 .NET 中从软件或脚本代码与 UDDI 节点进行交互成为可能。该测试版有一个可用于编写 UDDI 客户的类库。UDDI .NET SDK 1.75 Beta 测试版一旦下载就可以集成到 Visual Studio .NET 中。您可以用所提供的样本代码来熟悉 SDK。
Microsoft 的 .NET 中的 Web 服务工具概览
安装过程很简单。然而，由于多种原因（例如，因为它不是最终代码，所以当要升级到更新版本时，删除它可能会导致某些问题），我建议您把它安装在测试机器上。所需要的一个重要东西是 Microsoft 的 IIS。我的测试机器在 Windows XP Professional 上运行，装有最新版本的 IIS。一旦安装好了，Visual Studio .NET 就会提供一套全面的、集成的工具来方便 Web 服务的开发。这些工具的大多数功能都可通过所提供的 GUI 进行使用。此外，随 .NET 框架提供有这些工具的一些命令行版本（在
FrameworkSDK/bin 文件夹中）。
还有很多工具帮助编写 XML 文档和 XML 模式以处理安全和数字证书等。不过，我将仅突出讲述处理 Web 服务开发的组件。（第一个预览版和最近的发行候选版在术语上有一些变化。例如，ASP+ 运行时也称为 ASP .NET，SDL 和 SCL 被 WSDL 取代，文档把 NWGS 类库也看作 .NET 类。.NET 中的文档使用两种术语指同一个东西。）
-
ASP+ 运行库（ASP .NET）
- 代表一个编程抽象，这个编程抽象允许开发者构建 Web 服务而无须处理底层管道。
-
.NET 类库
- 提供一组有用的类来构建和操作 Web 服务。
-
Web 服务描述语言工具（
wsdl.exe ）
- 从 Web 服务描述语言（Web Services Description Language（WSDL））约定文件、XML 模式定义（XML Schema Definition（XSD））模式文件和 .
disco 发现文档为 XML Web 服务和 XML Web 服务客户生成代码。这个工具取代 Visual Studio .NET 的早期版本中所用的
webserviceutil.exe 来生成代理类。
-
Web 服务发现工具（
Disco.exe ）
- 发现位于 Web 服务器上的 XML Web 服务的 URL，把与各个 XML Web 服务相关的文档保存到本地磁盘。
-
Web 引用
- 合并进了
wsdl.exe 工具的功能的 GUI。请注意，有了 Visual Studio .NET 的这个版本，就不必再使用命令行工具为 Web 服务客户构建代理类。在解决方案中添加进 Web 引用将自动生成所要求的代理代码，代理代码在本地范围代表 XML Web 服务的已公开功能并处理所有必要的管道。
-
服务器和解决方案浏览器工具
- 用于通过网络服务器浏览 Web 服务、管理 Web 服务项目并将它们自动地部署到 Web 服务器的一个 GUI。
-
联机文档
- 自前发行版以来，与 XML Web 服务相关的文档已经成熟。
Microsoft 正致力于使其新的编程语言，即 C#，成为开发 XML Web 服务的语言选择，而 IBM 的 Application Developer 则支持把 Java 作为主要的语言选择。C# 看起来与 Java 类似，但有一些 Java 所没有的功能（例如：索引生成器（indexer）、事件（event）和代理（delegate））。Web（例如
The C# Corner和
ProgrammingTutorials.com）上有很多讲授 C# 的速成教程，这些教程也可作为语言参考。此外，在 MSDN 上有更多 C# 入门参考资料。本文不包含讲授 C# 的教程，但我在示例中所用到的语言功能对 Java 或 C/C++ 开发者而言应该比较简单。此外，Microsoft 还引入了 Visual J# 作为面向通用语言运行库的与 Java 兼容的语言。
CLR 是 .NET 中的新东西之一。CLR 不依赖于语言，这意味着您可以选择用于编码的语言，只要 .NET 的 CLR 支持该语言。目前，CLR 提供 22 种以上的语言（例如：C#、VB.NET、Jscript、C++、Perl、Python 和 COBOL）。性能应该是可以接受的，因为代码将被编译成中间语言（intermediate language（IL））代码，然后在运行时用 JIT 编译器将 IL 转换成本机代码。CLR 不支持 Java。（这个问题通过引入 J# 解决。）CLR 方法的缺点是由于它要成为真正独立于平台的解决方案，所以它必须支持所有主流平台（Linux、Mac 等）。目前，只有 Windows 2000 和 Windows 的未来版本得到了支持。这在目前把 .NET 和 CLR 的多功能性局限为只支持 Windows。把 .NET 平台移植到不同的平台不是一项容易的任务，但有人在努力将这个开发平台移植到 Linux。
结束语
总的来说，这两个解决方案都有自己的好处和优点。IBM 的 Application Developer 和 Microsoft 的 .NET 都遵循最近提议的 Web 服务标准和基本规范。两者都提供非常多用于开发和操作 Web 服务协议栈（UDDI、WSDL 和 SOAP）的每一层的工具和 API。Microsoft 的 Visual Studio .NET 已及时将它们以前的 SDL/SCL 语言替换为 WSDL（作为描述 Web 服务的语言）并提供了对 UDDI 的支持。Visual Studio .NET 保持用基于文件的发现（DISCO）来与 UDDI 互补。标准在两者中的实现和使用还存在着微妙的差别。这些互操作性问题已经超出本文的范围，不过请注意，随着时间的推移，这些互操作性已有很大改善。
一个明显的（并且是主要的）差异是 IBM 的 Application Developer 支持把 Java 作为主要的语言选择，而 Microsoft 的 .NET 及其 CLR 主要使用 C#、VB .NET 和 C++（或最近添加的替代 Java 的 Visual J#）。
在我以前的比较中，我提到过把 Web 服务集成到 .NET 所用的方法使得开发者可以非常容易地快速建立和运行 Web 服务。今天，IBM 的 Application Developer GUI 使开发方便了很多，也轻松了很多。而且，Application Developer 的 Web 服务工具支持在开放源代码、多平台的 Apache Tomcat 上进行托管。这对那些不是在基于 Windows 的环境中工作的用户而言将是一个重要的功能。而且，Application Developer 将很快能在 Linux 上使用，这使得它对在 Linux 平台上工作的开发者很有吸引力，而 Visual Studio .NET 仅在 Windows 平台上可用。
总之，所提供的工具在开发过程中将发挥重要作用。不过，应用拓扑结构（J2EE 或 .NET）和有可扩展性和安全性要求的服务器基础架构（WebSphere Application Server 或 Microsoft 的 IIS）也是选择合适工具的重要标准。
在未来几个月中跟踪这两个环境的发展将是很有趣的，特别是如果有了 Visual Studio .NET 的最终发行版。可以预见，有了 IBM 的和 Microsoft 的
全局 XML Web 体系结构，在当前的 Web 服务协议栈之上的更有趣的应用将逐渐出现。这将有助于促进“可编程的”Web 的发展前景。
我的下一篇文章，即第 2 部分，将更深入地讲述这里所出现的工具。该篇文章将建立在本文的技术背景上，并且展示在这两个环境中开发、实现和发布 Web 服务的详细代码样本。别走开 ...
参考资料
关于作者  | 
| |
Reiner Kraft是 IBM Almaden Research Center 的高级软件工程师。他是 IBM jCentral Java 资源搜索引擎的一个关键开发人员，该引擎现已集成到 IBM developerWorks 中。他还设计并实现了 xCentral，一个特定于 XML 的搜索引擎。他的研究兴趣是智能搜索引擎（因特网搜索技术）、超文本、安全性和因特网信息系统。可以通过
rekraft@almaden.ibm.com与 Reiner 联系。
|
对本文的评价
| 
