简介： 在本系列文章（共分为 3 部分）的第 1 部分中，我们将讨论 Web 服务的术语和概念以及 Web 服务可以带给 IT 专业人士的益处。本文没有解决任何特定于 Lotus Domino 的问题，只给出了 Web 服务的介绍，以便您快速入门。
平均分 (9个评分)
您可能听说过 Web 服务这一术语，在技术文章的上下文、软件产品的描述或者在与同事的交谈中都会提到它。Web 服务固然重要，但若将 Web 服务解释成 “用来定义能够交换消息的通信端点集合的 XML 语法” 多少会让人感觉整个概念太过复杂且难以理解。
幸运的是，只要不过于追究底层的操作细节，Web 服务可以用一种人人都能理解的方式加以定义。您应尽力理解 Web 服务，因为它们（及其相关术语 Service-Oriented Architecture 或 SOA）是 IT 界相当普遍的概念。
可以将 Web 服务看作是汽车：当您购买汽车、驾驶汽车或与朋友谈论汽车（除非他们是地道的修理工）时，您不需要在深奥的技术层面上了解所有活塞、凸轮轴和燃料喷射器的工作方式。Web 服务也是如此，您只需了解什么是 Web 服务和 Web 服务的工作方式以及 Web 服务为何对于您和您的生活（作为 IT 专业人士）如此重要就已经足够了。
实际上，现在使用 Web 服务很容易，无需处理大量的底层技术，因为在过去的几年中软件供应商及开放源码社区通过努力已经从低级别的任务中提取出 Web 服务的具体细节。这样一来，您就可以将大量时间花在集成组件上，而不是阅读冗长详细的规范文档以解决如何正确格式化 XML 消息的问题。
此系列文章适合于协助 Domino 开发人员理解并使用 IBM Lotus Domino V7.0 中的 Web 服务。本文是介绍性文章，适用面广泛，对于想知道什么是 Web 服务的任何人都是很有用的。Lotus Domino V7.0 合并了多种技术，使得开发人员可以很容易且方便地创建并公开 Web 服务，稍后我们将对此进行更加详细的讨论。
现在我们来讨论一下究竟什么是 Web 服务。
简单地说，Web 服务允许计算机应用程序间以一种标准的方式进行通信。
Web 服务是一个抽象的概念 —— 这种抽象多少有点像人与人之间的谈话。谈话一般会涉及进行交谈的两个或更多人，这些人使用他们都能理解的某种语言进行交谈。而这种语言定义了所使用的词语以及如何将这些词语组成句子。通常谈话将包括一些答复和响应，其中一个人给出陈述或提出问题，然后其他人根据第一个人所说的内容进行响应。人们可以面对面坐着交谈、通过电话交谈、或在当今时代，来回发送电子邮件或使用在线聊天服务进行交流。
在任何情况下，谈话本身有多个组成部分，根据所涉及的人数、正在使用的语言以及谈话人所使用的技术（如果有的话），谈话发生的方式也略有不同。
Web 服务允许应用程序间的通信，其中所涉及的内容很多，本文通篇将对这些内容进行讨论。但基本的概念仍类似于上述人与人之间的谈话的概念，只不过这里是应用程序使用共同的语言进行通信，且通常会跨越某种网络。应用程序可以位于同一台计算机，也可以位于不同的计算机，而不同的计算机彼此之间可能相隔甚远并仅通过 Internet 线路及之间的一些路由器和服务器来连接。最妙的是应用程序和计算机不必相似。在单个的 Windows 笔记本电脑上可以有两个 Microsoft .NET 程序互相通信，加拿大的一台 iSeries 服务器上的 Java 程序也可以与中国的 Linux 台式机上的 C++ 程序进行通信，所有这些都使用 Web 服务。
下面是在基本 Web 服务通信中通常会使用的标准技术：
- XML：Web 服务组件所使用的语言（数据格式）
- 简单对象访问协议（Simple Object Access Protocol，SOAP）：应用程序之间发送的 XML 消息
- Web 服务描述库（Web Services Description Library，WSDL）：XML 文件，定义了必须以怎样的方式来构造并发送 SOAP 消息
还有另外一个标准技术可用于基本 Web 服务通信，即通用描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）。我们将在文章末尾对它进行讨论；但 UDDI 的使用是可选的，在很多 Web 服务实现中没有使用它。
在进一步解释术语之前，先回顾一下与公开和使用 Web 服务相关的一些定义。
当我们谈到公开 Web 服务时，我们指的是这样一个应用程序，该应用程序发布 WSDL 文件并允许其他应用程序使用其提供的 Web 服务。公开 Web 服务的应用程序也被称为提供程序。
当我们谈到使用 Web 服务时，我们指的是调用另一台机器上的 Web 服务的应用程序。Web 服务的使用者也被称为客户机。
XML 是用于 Web 服务组件之间的通信的语言。应用程序之间进行交换的消息采用 XML 格式，而且用来定义所使用的 Web 服务的文件也采用 XML 格式。图 1 描述了简单的 XML 文件的结构。
图 1. 基本 XML 结构
从图中可以看到，文件中单独的信息（姓、名等等）被带尖括号的标记包围起来。例如名字 John 表示为 <firstname>John</firstname>。还可以具有包含在其他元素中的元素，例如 <person> 元素，它包含了 <firstname>、<lastname> 和 <birthday> 元素。
使用 XML 来编写 Web 服务有极大的优势，即：
- 在所有现代编程语言中，XML 解析器是很常见的，因此为 Web 服务编写的应用程序不必直接解析原始 XML 文件。
- XML 文件是可读懂的文本文件（换句话说，只要熟悉 XML 语言，就可以在任何文本编辑器中打开 XML 文件，并读懂文件内容）。这对调试过程很有帮助。
- XML 提供了在消息中使用任何标准字符集的方法，因此可以像用英语编写消息一样，很容易地用德语或日语编写消息。
- XML 允许使用名称空间，允许对文件中特定的元素的期望结构进行预定义。例如，可以定义始终是浮点数的 Price 元素或具有字符串子元素 FirstName 和 LastName 的 PersonName 元素。
如有必要，名称空间还允许相同名称的不同的元素具有不同的定义。例如一个名称空间中的 StockPrice 元素可能有股票代码和价格，而另一个名称空间中的 StockPrice 元素可能有股票代码、价格、每日高低点和一年最高点。
使用 XML 的缺点（如果您将其称为缺点的话）是：
- XML 是一种十分严格的语言，因此 XML 消息中的任何格式问题都将引起整个消息解析失败（即使这些问题可以很容易地解决或忽略）。但是，只要在程序中使用标准 XML 库来生成 XML 文件（这应是带有 Web 服务实现的情况），那么标准 XML 库就会确保以正确的格式表示消息。
- 消息的 XML 表示是纯文本文件，因此它通常比其他格式（如分隔符、二进制或定制格式）的等价表示要大得多。
但是，这些都是小问题，XML 的优势远远超过了上述不便。
知道 Web 服务应用程序之间的通信是以 XML 格式编写只解决了一半的问题。应用程序可以解析消息，但它们怎样知道如何解释解析结果呢？
关于如何格式化 Web 服务 XML 消息的规范是 SOAP。SOAP 定义了消息的结构，因此应用程序知道如何发送和解释数据。SOAP 消息的基本结构如图 2 所示。
图 2. 基本的 SOAP 消息结构
作为 XML，上述结构可以解释为如下内容：
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<ns1:GetStockInfo xmlns:ns1="urn:thisNamespace">
<symbol>FOO</symbol>
</ns1:GetStockInfo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
在其最基本的格式中，有一个包含 SOAP Body 的 SOAP Envelope，且 Body 包含了所传递的实际数据。有时，有一个包含额外信息的 SOAP Header（在 Envelope 中的 Body 之前），不过 SOAP Header 是可选的。
同时，出现问题的情况下，SOAP Body 将以 SOAP Fault 格式来包含错误信息。Fault 是另一个 XML 结构，它包含了错误的描述，例如：
<SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Server Error</faultstring> <detail>Database not available</detail> </SOAP-ENV:Fault> |
尽管 SOAP 消息是标准 XML 格式的文本文件，但手动创建或解释 SOAP 消息通常很难，因为所有名称空间和元素属性要严格按照某些特定方式来定义。幸运的是，现在有大量可用的工具和编程库能够用来创建并解释 SOAP 消息，因此利用这些技术可以大大减少复杂性。这些工具可以为我们完成复杂工作。
每个提供 Web 服务的应用程序都使用 WSDL 文件来描述哪些服务是可用的以及这些服务该如何调用。WSDL 是另一种基于 XML 的格式，它具有明确定义的结构，允许应用程序对其进行解析。通常将缩写词 WSDL 念做 “Whiz-dull”。
在 WSDL 文件的中心，Web 服务的提供程序定义了可由其他应用程序使用的方法。例如，Web 服务有一个名为 GetTemperature 的方法，该方法将返回给定城市的温度。WSDL 文件将该方法和如下信息一起列出：
- 特定的名称，用于向方法提出请求（在本例中，为 GetTemperature）
- 请求中必须使用的参数，如果有参数的话（参数的特定名称和特定的数据类型）
- 成功处理请求时值或返回值的格式（值的特定名称和数据类型）
- 为了进行方法调用应使用的 URL 和协议
文件中还有其它信息用来说明应如何格式化 SOAP 消息，例如要使用的名称空间、参数的顺序和结构、以及 SOAP Header 元素或 HTTP header 中所需的额外信息。
如果您以前从未看过 WSDL 文件，现在打开一个文件进行阅读可能很难提取出全部信息，因为文件的实际结构有些复杂。有关方法的全部信息（名称、参数、协议等）将分布在文件的各个部分，并且必须在可以构造 SOAP 消息之前由客户机应用程序将其拼凑起来。对 WSDL 文件的各个组成部分及它们如何一起工作的说明超出了本文的讨论范围。
还好，我们还可以求助于相关技术的帮助。大多数情况下，开发人员不必读取、解析并了解 WSDL 文件的内部细节。利用一些软件工具完全可以获取这些信息，因此您所需要关心的事情就是为 Web 服务提供数据并且使用作为响应返回的数据。您不但可以使用工具和库来实现这种功能，而且应该 始终这样做。Web 服务所涉及的组件存在很多异常、变数和复杂性，所以需要更加关心使用 Web 服务而不是逐一分解并理解全部组件。
到目前为止，我们尚未涉及的一个细节是这些 SOAP 消息是如何来回传递的？
答案是它们通常通过 HTTP 协议在网络（和/或 Internet）中传送，就像 Web 页面从 Web 服务器传送到工作站的浏览器上一样。这些消息不一定非要使用 HTTP（SMTP 是 HTTP 协议的主要竞争者，尽管它落后很多）协议来传送。WSDL 文件中明确定义了 Web 服务所使用的协议。
WSDL 文件中所指定的 SOAP 消息协议通常是 HTTP 协议。SOAP 客户机根据所使用协议的规范来发送消息。
到目前为止，我们所讨论的内容已包括了最常用的术语，但是在讨论 Web 服务时，还可能会听到其他一些术语。
使用 Web 服务的应用程序通常是松耦合的，这就是说能够让程序运转起来的 Web 服务没有直接与应用程序捆绑在一起，同样该应用程序也没有直接捆绑在 Web 服务上。程序可以方便地利用幕后的不同服务集来提供功能，服务本身也可以等待一个应用程序 —— 任何应用程序 —— 来调用它们并等待响应。
在现实世界中，可以将和朋友一起进餐的活动看作是一种松耦合的情况。几个朋友先是以各种方式（面对面、电话、电子邮件等）互相联系。然后大家采用对自己方便的交通方式到达饭店，就餐后，采用某种方式结帐。这其中的细节并不重要，而且就餐这件事还可能以其他方式进行，但是最终的结果都是一样的 —— 和朋友们共进晚餐。
而驾驶汽车的活动可以说是紧耦合的一个例子。您需要以特定的方式使用一整套固定的工具以便执行预定义的任务。如果您想从车道上倒车出来，则必须挂入倒档，然后踩油门。如果想左转，则必须向左转动方向盘。因为系统整体上很精确并且各个组件之间也是紧密依赖的，所以对于如何使它运转起来，您不会有很多选择。
UDDI 是一个标准，用来提供 Web 服务的目录，该 Web 服务可用于任何数量的不同应用程序。它就像是一个 Web 服务提供程序的“电话簿”。客户机可以在 UDDI 注册表中查找服务信息，由注册表返回连接到该服务所需的详细信息。
虽然在最早的 Web 服务定义中，UDDI 是一个重要的标准，但由于它是 Web 服务的可选组件，并且一些人选择不使用它（这是常有的事），因此 UDDI 的重要性有所减弱。
在很多更具组织性的企业环境还存在有 UDDI 注册表，这些企业环境拥有大量内部的 Web 服务提供程序。实际上，当发布可在公司内使用的 Web 服务时，设置企业 UDDI 站点是一个很好的主意。除了集合可用 Web 服务外，UDDI 使更改幕后的 Web 服务提供程序变得很容易。只要所有的客户机使用 UDDI 来定位 Web 服务而不是直接转到提供服务器，SOAP 调用都将自动指向新的提供程序。
总之，它是一个可选的架构组件，并不是 Web 服务实现所严格要求的。
在阅读 SOAP 和 WSDL 描述时，您一定很关心安全性问题。当调用这些服务时，如果提供程序使用了非公共的信息，那么该如何实现验证呢？当然，并不是所有的 Web 服务都是向公众全部开放的，不是吗？
这是一个非常好的问题，遗憾地是，没有一个标准的答案。在很多不同的场景下，必须根据实际情况进行处理，例如：
- SOAP 消息是使用纯文本格式进行传递还是需要加密？
- 您是需要简单的用户名/密码验证还是需要持久性的、基于令牌的验证？
- 如果有令牌，是否需要通过签署验证来对它们进行签名？又如何将其正确地包括在 SOAP 消息中？
- 如果客户机没有将 SOAP 消息直接发送到提供程序，而是通过中间节点（例如消息队列或其他 Web 服务）来发送消息，该怎么办？
另外，无法保证 HTTP 始终是信息交流所使用的协议，因此不能仅在现有的 HTTP 安全性方法上使用 Web 服务安全性。
还有一些规范可以解决这些及其他 Web 服务的安全性问题，它们是 WS-Security、WS-Policy、WS-Trust 和 WS-Privacy。一些软件供应商和委员会已经对此讨论多年。当然，并非所有 Web 服务实现都能兼顾所有的安全性规范，因而所形成的安全性标准提供了一些被普遍接受的方式用于解决大多数安全性问题。
还有更大的一套支持安全性标准的 Web 服务标准，通常这些标准（在一个相当大的集合中）混在一起，被称为 WS-* 规范。它们共同解决了很多重要的架构问题，当您开始在企业环境中放置大量 Web 服务时会出现这些问题。WS-* 中的标准涉及如下主题：
- 安全性
- 可靠性
- 消息传递
- 事务
- 服务质量
之所以需要这么多标准是因为在企业应用程序中 Web 服务客户机和服务器交互间的消息传递要求比简单的请求/响应要复杂得多。例如，应该如何确保消息实际到达了提供程序并返回到客户机？如果 SOAP 请求实际上是一个多方事务请求，该怎么办？怎样管理那些涉及调用了其他 Web 服务的 Web 服务的过程？如果应用程序发送了一系列具有定时要求的请求，该怎么办？
对于较大的软件供应商，解决上述问题并应用这些规范将带来机遇和挑战。一些供应商为市场提供了 Web 服务中间件产品软件包 —— 通常被称为企业服务总线（Enterprise Service Bus）或 ESB —— 这些软件包提供了一些或全部管理功能以便解决此类问题。通常这些 ESB 产品还有附加功能，比如它们可以将跨机构的很多 Web 服务捆绑在一起并提供诸如登录和消息排队这样的功能。
接下来要探讨的是面向服务的架构 (Service-Oriented Architecture)。在很多方面，SOA 只是我们已描述的各方面内容的组合：来自多个提供程序的松散耦合的 Web 服务在公共标准集（可能是 ESB）下互操作，并通过多个应用程序集中在一起，这些应用程序从服务中提取数据，然后以多种方式表示出来。
因为它实际上是一个软件架构，所以构建 SOA 时会涉及大量的计划和协调。它不是多个 Web 服务胡乱的堆砌和混合；而是对服务如何被收集并公开、使用哪种管理工具和中间件、如何整体上监视并维护服务和系统这些问题的有序组织。
从更高的层次上来讲，SOA 也是一种理念体系。它不需要您考虑独立操作的大型应用程序，而是要求您关注有关使用或提供可在企业中公开或使用的功能模块集的所有事情。也就是说它要求不要从泛泛的应用程序方面进行考虑，而是应该着眼于具体的明确定义的服务，即 Web 服务。
现在您对 Web 服务如何工作有了一些了解 —— 客户机读取提供程序的 WSDL 文件，根据该文件中的定义来格式化并发送 SOAP 消息，然后接收响应中的 SOAP 消息。那么这些为何如此重要？原因何在呢？
重要性的部分原因在于应用程序现在能够以一种标准方式进行通信，而不管它是采用哪一种语言编写的或运行在哪一种平台上。在过去，应用程序（可能进行了也可能没进行过很好的建档）需要定制的数据格式，而且必须要处理 API 级功能，这些功能可以也可能不可以被用其他语言编写的其他程序访问。所有的 Web 服务标准都采用 XML 格式就意味着所有的服务都是可访问的且明确定义的。
实际上，它还解放了不相关的应用程序，这些应用程序现在可以使用公共语言方便地进行通信。在使用多个供应商提供的不同技术时，所面临的困难之一是始终要确保程序之间能够互相对话并交换数据。现在，只要应用程序可以提供和/或使用 Web 服务，不同技术之间的互操作性就会大大简化。
另一个优势在于可以很容易地将 Web 服务客户机和提供程序放置在完全不同的机器上（可能运行于完全不同的硬件和操作系统），同时通信仍能进行。过去，应用程序只能由相同机器上的其他应用程序或由其他机器上使用了定制数据传送格式的应用程序访问。Web 服务应用程序所需要只是网络连接和 XML 解析器。
将所有这些因素放在一起就是真正的原因所在了。由于现在可以采取一种标准方式用于不同应用程序在网络上的通信，因此您就可以设计自己不同的应用程序。现在还能够编写更加模块化的程序，而不必多此一举地编写提供全部功能的单一应用程序。
例如，现在您不必编写大型报告型应用程序来收集关于几个不同进程的数据，然后将数据转化为图表，再将其展示给用户，您完全可以采用指示板，它是可以提供此功能的一些 Web 服务的前端。经过编译的数据可以通过对一个或多个 Web 服务的调用进行检索，而且通过发送数据到接收该数据并返回饼状图或类似图表的绘图 Web 服务可以生成图表本身。
指示板已由一个大型的独立程序演变成了一个简单的接口。如果需要添加新组件，只需调用附加服务。如果需要其他图表类型，则可以调用不同的绘图服务。如果指示板需要与向下钻取功能或定制排序有更多的交互，则指示板可以在用户和适当的 Web 服务之间来回传递请求。甚至可以在不影响用户的情况下彻底更改后台中调用的服务，并且（只要 WSDL 文件没有更改）无需更改指示板应用程序。
作为 IT 专业人士，您可能会负责计划或开发这类接口和/或这类服务。了解如何结合使用本文所介绍的这些组成块（或至少知道这些组成块的存在）是推动此类项目前进的重要基础。
幸运的是，有很多工具可用来协助您提供并使用 Web 服务，而且无论您使用何种技术，它们都将为您减轻大量开发负担。在本系列文章的后续部分中，我们将讨论如何使用 IBM Lotus Domino V7.0 轻松地为客户机或系统提供 Web 服务。
学习
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
- 查看完整的 “IBM Lotus Domino 7 中的实用 Web 服务” 系列文章。
- developerWorks Lotus 文章 “Lotus Notes/Domino 7 Web Services”
- developerWorks Lotus 文章 “通过 Lotus Domino Java 代理消费 Web 服务”
- developerWorks 教程 “快速创建 Domino Web 服务，利用 Domino 7 中新的 Web 服务功能加快开发速度”
- developerWorks SOA and Web services 专区的标准和规范页面
- developerWorks 文章 “我应该采用哪一种 WSDL 样式？”
- developerWorks SOA and Web Services 专区
- developerWorks 文章 “观点与展望，第 1 部分: 选择 SOA 的原因和时机”
- developerWorks 文章 “面向服务的体系结构（SOA）：对 IBM Workplace 和 Lotus 开发人员的采访”
获得产品和技术
- 从 developerWorks 可下载 Lotus Domino 试用版。
- 从 developerWorks 可下载 Lotus Notes 试用版。
讨论
- 参与论坛讨论。
- 通过参与 developerWorks blogs 加入 developerWorks 社区。
扫一扫
641
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
