服务计算（一）

第零章、XML

可扩展标记语言，标准通用标记语言的子集，简称XML。是一种用于标记电子文件使其具有结构性的标记语言。
在电子计算机中，标记指计算机所能理解的信息符号，通过此种标记，计算机之间可以处理包含各种的信息比如文章等。它可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。 它非常适合万维网传输，提供统一的方法来描述和交换独立于应用程序或供应商的结构化数据。是Internet环境中跨平台的、依赖于内容的技术，也是当今处理分布式结构信息的有效工具。早在1998年，W3C就发布了XML1.0规范，使用它来简化Internet的文档信息传输。

第一章、介绍

1.0 为什么要学服务计算

今天，万维网的主要用途是交互访问文档和应用程序。在几乎所有情况下，这种访问都是由人类用户进行的，通常是通过Web浏览器、音频播放器或其他交互式前端系统进行的。如果将Web扩展到支持应用程序之间（从一个程序到另一个程序）的通信，那么它的威力和范围将显著增长。

-来自W3CXML协议工作组章程

欢迎来到web服务的世界。本章将介绍web服务术语和体系结构的基础知识。它通过回答最常见的问题来做到这一点，包括：

•什么是web服务？•什么是web服务协议栈？•什么是XML消息传递？服务描述？服务发现？•XML-RPC、SOAP、WSDL和UDDI是什么？这些技术如何相互补充，共同工作？•web服务特有的安全问题是什么？•目前有哪些标准？

1.1 Web服务简介

web服务是通过Internet提供的任何服务，使用标准化的XML消息传递系统，并且不与任何一种操作系统或编程语言绑定。
下图是一个基本的web服务

XML消息传递有几种替代方案。例如，可以使用XML远程过程调用（XML-RPC）或SOAP，这两种调用都将在本章后面介绍。或者，您可以只使用HTTP GET/POST并传递任意XML文档。

尽管它们不是必需的，但是web服务还可以有两个额外的（和期望的）属性：

•web服务应该是自描述的。如果发布新的web服务，则还应向该服务发布公共接口。至少，您的服务应该包含人类可读的文档，以便其他开发人员可以更轻松地集成您的服务。如果您已经创建了一个SOAP服务，那么理想情况下还应该包括一个用通用XML语法编写的公共接口。XML语法可用于标识所有公共方法、方法参数和返回值。
•web服务应该是可发现的。如果您创建一个web服务，应该有一个相对简单的机制来发布这个事实。同样，应该有一些简单的机制，让相关方可以找到服务并定位其公共接口。确切的机制可以是通过一个完全分散的系统或一个更加逻辑集中的登记系统。

总而言之，一个完整的web服务就是：

•可在Internet或专用（intranet）网络上使用•使用标准化的XML消息传递系统•不与任何一种操作系统或编程语言绑定•可通过通用XML语法进行自我描述•可通过简单的查找机制发现

1.1.1 今天的网络：以人为中心的网络

要使web服务更加具体，请考虑基本的电子商务功能。例如，Widgets，Inc.通过其网站销售部件，使客户能够提交采购订单并检查订单状态。

为了检查订单状态，客户通过web浏览器登录到公司网站，并以HTML页面的形式接收结果。这个基本模型说明了一个以人为中心的Web，其中人类是发起大多数Web请求的主要参与者。它也代表了当今大多数网络运行的主要模式。

1.1.2 Web服务：以应用程序为中心的Web

使用web服务，我们从以人为中心的web转变为以应用程序为中心的web。这并不意味着人类完全不在画面之外！它只是意味着可以在应用程序之间直接进行对话，就像在web浏览器和服务器之间一样容易。

例如，我们可以将order status应用程序转换为web服务。然后，应用程序和代理可以连接到服务并直接利用其功能。例如，库存应用程序可以查询Widgets，Inc.所有订单的状态。然后，库存系统可以对数据进行处理、操作，并将其集成到整个供应链管理软件中。
在许多领域中，以应用程序为中心的Web可以证明是非常有用的。例如信用卡验证、包裹跟踪、投资组合跟踪、购物机器人、货币转换和语言翻译。其他选项包括个人信息的集中存储库，如微软提议的.NET MyServices项目。NET MyServices旨在集中日历、电子邮件和信用卡信息，并提供用于共享这些数据的web服务。

Web服务与语义Web
蒂姆•伯纳斯•李是Web的最初发明者，他最近提出了“语义Web”的观点，语义Web是以应用程序为中心的，与Web服务有许多相同的想法。事实上，在W3C的第一次web服务会议上，Berners Lee指出web服务是语义web远景的实现。有关语义Web的概述，请参阅Berners Lee在Scientific American中的文章：http://www.sciam.com/2001/0501issue/0501berners-Lee.html。

1.1.3 Web服务愿景：自动化Web

以应用程序为中心的Web并不是一个新概念。多年来，开发人员已经创建了CGI程序和javaservlet，它们主要是为其他应用程序设计的。例如，公司开发了信用卡服务、搜索系统和新闻检索系统。

关键的区别在于，这些系统中的大多数都是由特定的解决方案组成的。有了web服务，我们有望实现一些标准化，这将有望降低应用程序集成的障碍。

web服务体系结构提供了一个有趣的替代方案，可以将表示与内容彻底分离。例如，一个站点只能由容器页面组成，容器页面通过SOAP或XML-RPC将参数传递给真正的逻辑。这使得更改演示文稿变得很容易，而且还允许人和计算机“共享”单个web服务。

从长远来看，web服务也提供了自动化web的前景。如果服务很容易被发现、自我描述并遵循通用标准，那么就有可能实现应用程序集成的自动化。一些业内人士称之为“just intime”应用程序集成。

例如，以MegaElectric（ME）为例。我想从Widgets，Inc.购买零件，还想无缝地将订单状态集成到一个统一的库存系统中。在未来的某个时候，我将能够购买自动化整个过程的软件。下面是它的工作原理：

一、库存应用程序唤醒并连接到web服务的集中目录：“Widgets，Inc.是否提供订单状态服务？”目录返回Widgets，Inc.服务的信息，并包含指向服务描述的指针。二、inventory应用程序连接到Widgets，Inc.并检索服务描述。
三、服务描述文件包含有关如何连接到指定服务的完整详细信息。因此，inventory应用程序可以自动调用order status服务。

是否可以使用现有的web服务技术自动化此过程？不完全正确：目前只有部分流程可以自动化。例如，我们将在第9章中看到，可以创建查询服务注册中心的Java程序。然而，了解结果并选择实际使用的服务仍然需要一些人工干预。也可以根据服务描述自动调用服务。例如，正如我们将在第6章中看到的，许多自动调用工具已经存在并且工作得非常好。

即使所有这些步骤都可以自动化，但目前还没有实现业务关系自动化的机制。例如，当前的服务描述不包括对定价、交付时间表的保证，或者如果没有交付，则不包括法律后果。给定一个服务描述，您也不能假定该服务没有bug，或者该服务在100%的时间内都是可用的。

这些类型的问题不容易解决，也不容易自动化。因此，完全自动化的web服务和“即时”应用程序集成可能永远无法实现。尽管如此，当前的web服务技术确实使我们更进一步，并使我们能够自动化流程的某些部分。

1.1.4行业格局

目前有许多相互竞争的web服务框架和建议。三大竞争者是微软的.NET、IBM Web服务和Sun开放网络环境（ONE）。虽然这些框架中的每一个都有自己独特的利基和旋转，但它们都共享这里提出的基本web服务定义和远景。此外，所有框架都共享一组公共技术，主要是SOAP、WSDL和UDDI。

本文不是集中在一个特定的实现或框架上，而是集中在共同的定义和技术上。希望，这将更好地装备你通过市场宣传，了解和评估目前的竞争者。

1.2 Web服务架构

对待web服务体系结构有两种方法。第一个是检查每个web服务参与者的各个角色；第二个是检查正在出现的web服务协议栈。

1.2.1 Web服务角色

web服务体系结构中有三个主要角色：

服务提供商

这是web服务的提供者。服务提供者实现服务并使其在Internet上可用。

服务请求者

这是web服务的任何使用者。请求者通过打开网络连接并发送XML请求来利用现有的web服务。

服务注册中心

这是一个逻辑上集中的服务目录。注册表提供了一个中心位置，开发人员可以在这里发布新服务或查找现有服务。因此，它是公司及其服务的集中票据交换所。

下图显示了主要的web服务角色以及它们之间的交互方式。

1.2.2 Web服务协议栈

查看web服务体系结构的第二个选项是检查正在出现的web服务协议栈。堆栈仍在发展中，但目前有四个主要层。下面是对每一层的简要描述。

服务运输

此层负责在应用程序之间传输消息。目前，这一层包括超文本传输协议（HTTP）、简单邮件传输协议（SMTP）、文件传输协议（FTP）和较新的协议，如块可扩展交换协议（BEEP）XML消息传递

此层负责以通用XML格式对消息进行编码，以便可以在两端理解消息。目前，这个层包括XML-RPC和SOAP。

服务说明

该层负责描述特定web服务的公共接口。目前，服务描述是通过Web服务描述语言（WSDL）处理的。

服务发现

该层负责将服务集中到一个公共注册表中，并提供简单的发布/查找功能。目前，服务发现是通过通用描述、发现和集成（UDDI）来处理的。

随着web服务的发展，可以添加额外的层，并且可以向每个层添加额外的技术。下图总结了当前的web服务协议栈。
1.2.3体系结构快照：IBM Web服务浏览器

要深入了解协议栈的实际工作方式，请尝试使用IBM Web服务浏览器。浏览器允许您搜索现有服务，查看其服务描述，并自动调用这些服务。这样，您就可以看到协议栈中的每一层，而无需实际编写任何代码。

要开始，请打开浏览器并转到http://demo.alphaworks.ibm.com/browser/。您应该看到图1-8所示的屏幕。

在右侧窗格中，您可以搜索现有web服务的集中注册表。（注册中心实际上使用了UDDI，但还没有完全了解细节。）在搜索框中，键入“IBM Web服务”，然后单击搜索。IBM将为您搜索集中式目录，并在左窗格中显示所有匹配的结果。选择最后一个名为IBM Web服务TestArea的文件夹，您将看到可用Web服务的列表。（见图1-9。）

单击GetWeatherService，右窗格将显示有关该服务的特定详细信息。（参见图1-10。）数据包括绑定点（指示实际连接到服务的URL）和解释如何与服务接口的服务描述文件。（这些是WSDL文件，但同样，不要太过关注细节。）

单击左窗格中的“查看页面”链接。右窗格现在将显示天气服务的简单用户界面。选择一个城市和州，IBM将自动调用该服务并显示当前的天气状况。（见图1-11。）

IBM浏览器很好地演示了web服务的实际工作，并突出显示了协议栈中的主要层。它还很好地说明了“即时”应用程序集成的潜力。每个服务基本上都充当一个独立的构建块，您可以继续将越来越多的服务堆叠到同一页。最棒的是，你不需要写一行代码就可以做到！

1.3 XML消息

近年来，XML在计算领域迅速发展。它得到了迅速的接受，因为它使不同的计算机系统更容易共享数据，而不管是操作系统还是编程语言。有几十种XML工具，包括解析器和编辑器，这些工具几乎可以用于每一个操作系统和每种编程语言，包括java、perl、python、C++、c、C++和Ruby。当开发人员决定构建web服务消息传递系统时，XML是一个自然的选择。XML消息传递有两个主要竞争者：XML-RPC和SOAP。以下各节介绍了这两种协议。

1.3.1 XML-RPC

XML-RPC是一个简单的协议，它使用XML消息来执行RPC。请求用XML编码并通过HTTP POST发送。XML响应嵌入在HTTP响应的主体中。因为XML-RPC是独立于平台的，所以它允许不同的应用程序进行通信。例如，Java客户机可以向Perl服务器讲XML-RPC。

要获得对XML-RPC的高级理解，请考虑一个简单的天气服务。服务需要一个邮政编码并返回该区域的当前温度。下面是对天气服务的XML-RPC请求示例（省略了HTTP头）：
请求由一个简单的methodCall元素组成，该元素指定方法名和任何方法参数。

以下是来自天气服务的XML-RPC响应示例：
响应由一个指定返回值的methodResponse元素组成。在这种情况下，返回值被指定为整数。XML-RPC是开始使用web服务的最简单方法。在许多方面，它比SOAP更简单，也更易于采用。然而，与SOAP不同，XML-RPC没有相应的服务描述语法。这就防止了XML-RPC服务的自动调用——这是实现实时应用程序集成的关键因素。XMLRPC的更多细节将在第2章中介绍

1.3.2 SOAP

SOAP是一种基于XML的计算机间信息交换协议。尽管SOAP可以用于各种消息传递系统，并且可以通过各种传输协议来传递，但是SOAP的主要关注点是通过HTTP传输的rpc。与XML-RPC一样，SOAP是独立于平台的，因此允许不同的应用程序进行通信。

为了对SOAP有一个更高层次的理解，让我们重新访问我们的简单天气服务。下面是一个示例SOAP请求（省略HTTP头）：
如您所见，SOAP请求比XML-RPC请求稍微复杂一些。它同时使用XML名称空间和XML模式。但是，与XML-RPC一样，SOAP请求的主体同时指定方法名和参数列表。

以下是来自天气服务的SOAP响应示例：

1.4服务描述：WSDL

WSDL当前表示web服务协议栈中的服务描述层。简而言之，WSDL是一种XML语法，用于指定web服务的公共接口。此公共接口可以包括所有公共可用函数的信息、所有XML消息的数据类型信息、有关要使用的特定传输协议的绑定信息以及用于定位指定服务的地址信息。WSDL不一定绑定到特定的XML消息传递系统，但它确实包含用于描述SOAP服务的内置扩展。

使用WSDL，客户机可以定位web服务并调用任何公共可用的函数。使用WSDL感知工具，这个过程可以完全自动化，使应用程序能够轻松地集成新的服务，只需很少或根本不需要手动代码。例如，IBM最近发布了IBMWeb服务调用框架（WSIF）。使用WSIF，您可以指定WeatherService.wsdl文件并自动调用所描述的服务。

1.5服务发现：UDDI

UDDI当前表示web服务协议栈中的发现层。UDDI最初是由Microsoft、IBM和Ariba创建的，代表了发布和查找业务和web服务的技术规范。

UDDI的核心由两部分组成。
首先，UDDI是一种技术规范，用于构建业务和web服务的分布式目录。数据以特定的XML格式存储。UDDI规范包括用于搜索现有数据和发布新数据的API详细信息。
其次，UDDI业务注册中心是UDDI规范的一个完全可操作的实现。UDDI注册中心由微软和IBM于2001年5月推出，现在任何人都可以搜索现有的UDDI数据。它还使任何公司能够注册自己及其服务。

UDDI中的数据分为三大类：

白页

此类别包括有关特定公司的一般信息；例如，公司名称、业务说明和地址。

黄页

此类别包括公司或所提供服务的一般分类数据。例如，这些数据可能包括基于标准分类法的行业、产品或地理代码。

绿皮书

此类别包括有关web服务的技术信息（指向外部规范的指针和用于调用web服务的地址）。

下图显示了microsoftudi站点的一个示例屏幕截图。从这个站点，您可以轻松地发布自己的服务或搜索现有的服务。

1.6服务运输

web服务协议栈的底部是服务传输。此层负责在两台计算机之间实际传输XML消息。

1.6.1 HTTP协议

目前，HTTP是最流行的服务传输选项。HTTP是简单、稳定和广泛部署的。此外，大多数防火墙允许HTTP通信。这允许XMLRPC或SOAP消息伪装成HTTP消息。如果您希望轻松集成远程应用程序，这是很好的，但它确实会引起一些安全问题。（见本章后面的1.7节）虽然HTTP确实完成了这项工作，但一些批评者认为HTTP并不适合web服务。特别是，HTTP最初是为远程文档检索而设计的，现在正在重新设计以支持rpc。与文档检索相比，RPCs对效率和可靠性的要求更高。

有些开发人员认为HTTP是消息传递的基础，而HTTP之上的层与解决方案同样是一个问题。有关这种视角的一些内容，称为表示状态转移（Representational State Transfer，简称REST），请参见http://internet.conveyor.com/RESTwiki/moin.cgi。

1.6.2BEEP

块可扩展交换协议（BEEP）是HTTP的一个很有前途的替代方案。BEEP是一个新的IETF框架，它包含了构建新协议的最佳实践。尤其是，BEEP直接在TCP上分层，并包含许多内置功能，包括初始握手协议、身份验证、安全性和错误处理。使用BEEP，可以为各种应用程序创建新的协议，包括即时消息、文件传输、内容联合和网络管理。

SOAP没有绑定到任何特定的传输协议。实际上，您可以通过HTTP、SMTP或FTP使用SOAP。因此，一个有前途的想法是在BEEP上使用SOAP。这样做比HTTP提供了一些性能优势。具体来说，BEEP确实需要一个初始握手，但是握手之后，协议对每条消息只需要30字节的开销，这使得它比HTTP更加高效。[1]此外，BEEP支持同一连接上的多个数据通道，通过HTTP提供了额外的效率。

[1] 每个HTTP消息的开销取决于许多因素，包括请求的URL、使用的客户端类型和HTTP响应中返回的服务器信息类型。因此，典型的浏览器和SOAP请求的开销可以从每条消息的大约100到300字节不等。

使用SOAP over BEEP的最新建议可在以下位置获得：

http://beepcore.org/beepcore/docs/beep-soap.jsp。

另一个有希望替代HTTP的方法是可靠HTTP（HTTP-R）。HTTP-R正由IBM开发，该公司计划将其提案提交给互联网工程特别工作组（IETF）。HTTP-R增强了HTTP以确保消息的可靠性。例如，HTTP-R确保消息只传递一次或报告为不可传递。这对于电子商务服务（如电子订货系统和库存管理）尤其重要。有关HTTP-R的入门文章可从IBM获得，网址为HTTP://ww106.IBM.com/developerworks/webservices/library/ws-phtt/。

1.7安全考虑

安全性对web服务至关重要。然而，XML-RPC和SOAP规范都没有明确的安全或身份验证要求。此外，web服务社区提出了许多安全框架和协议，但尚未就一个全面的安全包达成共识。

从广义上讲，有三个具体的安全问题：机密性、身份验证和网络安全。

1.7.1保密

如果客户机向服务器发送XML请求，我们能确保通信保持机密吗？

幸运的是，XML-RPC和SOAP都主要运行在HTTP之上，因此XML通信可以通过安全套接字层（SSL）加密。SSL是一种久经验证的技术，已被广泛部署，因此是加密消息的一个非常可行的选项。

然而，web服务的一个关键元素是单个web服务可以由一系列应用程序组成。例如，一个大型服务可能将其他三个应用程序的服务绑定在一起。在这种情况下，SSL是不够的；消息需要沿着服务路径在每个节点上加密，并且每个节点代表链中潜在的薄弱环节。目前，对于这个问题还没有达成一致的解决方案，但有一个很有希望的解决方案是W3C XML加密标准。该标准为加密和解密整个XML文档或XML文档的一部分提供了一个框架，并且很可能得到广泛的行业支持。有关XML加密标准的信息，请访问http://www.w3.org/Encryption/。

1.7.2认证

如果客户机连接到web服务，我们如何识别用户？用户是否被授权使用该服务？

一种解决方案是利用HTTP身份验证。HTTP包含对基本身份验证和摘要身份验证的内置支持，因此可以以与当前保护HTML文档相同的方式保护服务。然而，大多数安全专家都认为HTTP身份验证是一个相对薄弱的选择。

与加密一样，对于强身份验证方案没有明确的共识，但是有几个框架正在考虑之中。第一个是SOAP安全扩展：数字签名（SOAP-DSIG）。DSIG利用公钥加密技术对SOAP消息进行数字签名。这使客户端或服务器能够验证另一方的身份。DSIG已提交给W3C，可在http://www.w3.org/TR/SOAP DSIG/上获得。

其次，结构信息标准促进组织（OASIS）正在研究安全断言标记语言（SAML）。SAML旨在促进业务伙伴之间身份验证和授权信息的交换。有关信息，请访问http://www.oasipoen.org/committees/security/。

在一项相关的工作中，一些公司提出了XML密钥管理服务（XKMS）。XKMS定义了一系列用于分发和管理公钥和证书的服务。协议本身是基于SOAP和WSDL构建的，因此它是web服务的一个很好的例子。该规范可在线访问http://www.w3.org/TR/xkms/。

1.7.3网络安全

2000年6月，著名计算机专家Bruce Schneier直言“SOAP将为安全漏洞开辟一条全新的途径。”[2]Schneier的基本论点是HTTP是为文档检索而设计的。通过SOAP扩展HTTP使远程客户端能够调用命令和过程，这是防火墙明确设计用来防止的。

[2] 密码通讯，2000年6月15日（http://www.countrane.com/Crypto-Gram-0006.html）。

您可能会争辩说，CGI应用程序和servlet存在相同的安全漏洞。毕竟，这些程序还允许远程应用程序调用命令和过程。然而，随着SOAP的应用越来越广泛，Schneier的论点变得更加有说服力。目前，这个问题还没有一个简单的答案，它已经成为许多辩论的主题。现在，如果您真正想过滤掉SOAP或XML-RPC消息，一种可能是过滤掉所有将其内容类型设置为text/XML的HTTP POST请求（这两种规范都有要求）。另一种选择是筛选SOAPAction HTTP头属性（有关详细信息，请参阅第3章）。防火墙供应商目前也在开发明确设计用于过滤web服务流量的工具。

1.8一起

一旦理解了web服务协议栈中的每一层，下一个重要的步骤就是理解所有部分是如何组合在一起的。有两种方法可以解决这个问题，要么从服务请求者的角度，要么从服务提供者的角度。在本节中，我们将研究这两个方面，并为每个方面查看一个典型的开发计划。

1.8.1服务请求透视图

服务请求者是web服务的任何使用者。以下是服务请求者的典型开发计划：

一。首先，必须识别并发现与应用程序相关的服务。因此，第一步通常包括搜索UDDI业务目录中的合作伙伴和服务。2。一旦确定了所需的服务，下一步就是找到服务描述。如果这是一个SOAP服务，您可能会找到一个WSDL文档。如果这是一个XML-RPC服务，您可能会找到一些人类可读的集成指令。三。第三，必须创建客户机应用程序。例如，可以用您选择的语言创建XMLRPC或SOAP客户机。如果服务有WSDL文件，您还可以选择通过WSDL调用工具自动创建客户机代码。四。最后，运行客户机应用程序来实际调用web服务。

图1-14提供了服务请求者透视图的快照。

1.8.2服务提供商视角

服务提供者是一个或多个web服务的任何提供者。以下是服务提供商的典型开发计划：

一。首先，您必须开发服务的核心功能。这通常是最困难的部分，因为您的应用程序可能连接到数据库、企业JavaBeans™ （ejb）、COM对象或遗留应用程序。2。第二，必须开发核心功能的服务包装器。这可以是XML-RPC或SOAP服务包装器。这通常是一个相对简单的步骤，因为您只是将现有功能包装到一个更大的框架中。三。接下来，您应该提供一个服务描述。如果要创建SOAP应用程序，则应创建WSDL文件。如果要创建XML-RPC服务，则应考虑创建一些人类可读的指令。四。第四，您需要部署服务。根据您的需要，这可能意味着安装和运行独立服务器或与现有web服务器集成。5个。第五，你需要公布你的新服务的存在和规格。这通常意味着将数据发布到全局UDDI目录，或者可能是特定于您公司的私有UDDI目录。

1.9标准和一致性

Web服务仍处于初级阶段，但它们准备在分布式应用程序开发领域取得重大进展。然而，web服务长期成功的最关键因素将是这些标准的标准化和一致性。目前，本书中所描述的web服务技术都没有W3C或IETF的官方支持。SOAP和WSDL都已提交给W3C，但没有正式的推荐状态。XML-RPC尚未提交给任何标准机构。UDDI目前处于一个行业联盟的管辖范围内，在被移交给一个标准机构之前，它可能还要经过多次迭代。

2000年9月，W3C创建了一个XML协议组。这个小组代表了W3C首次正式进军web服务领域。它的第一个任务是为SOAP创建一个正式的推荐，该小组目前正在完成SOAP 1.2规范。2002年1月，W3C将XML协议组合并到一个更通用的Web服务活动中。新活动添加了Web服务架构和Web服务描述的工作组。

有关W3CWeb服务活动的信息，请访问http://www.w3.org/2002/ws/。

大多数刚接触web服务的人最初都被一长串拟议的标准和它们之间复杂的交互所淹没。标准化web服务协议栈中的每一层将是一个重大挑战。确保所有层都整合在一起，并且对开发人员来说是一个更大的挑战。