什么是 Web 服务？架构、类型、示例

什么是 Web Service？

Web service 是客户端应用程序和 WWW (World Wide Web) 上的服务器应用程序之间通信的标准媒介。Web service 是一个旨在执行一组特定任务的软件模块。

云计算中的 Web Service 可以在网络上进行搜索，也可以按需调用。
调用时，Web Service 将能够向调用它的客户端提供功能。

Web Services 如何工作？

上图展示了 Web Service 的实际工作原理的简化视图。客户端会通过向托管实际 Web Service 的服务器发出请求来调用一系列 Web Service 调用。

这些请求是通过所谓的远程过程调用（Remote Procedure Calls）进行的。远程过程调用 (RPC) 是对由相应 Web Service 托管的方法进行的调用。

例如，亚马逊提供了一个 Web Service，通过 amazon.com 提供在线销售产品的价格。前端或表示层可以是 .Net 或 Java，但任何一种编程语言都可以与 Web Service 进行通信。

Web Service 设计的主要组件是客户端和服务器之间传输的数据，那就是 XML。 XML (可扩展标记语言) 是 HTML 的对应物，并且是许多编程语言易于理解的中间语言。

因此，当应用程序相互通信时，它们实际上是用 XML 进行通信的。这为使用各种编程语言开发的应用程序提供了通用的通信平台。

Web Services 使用称为 SOAP (Simple Object Access Protocol) 的东西在应用程序之间发送 XML 数据。数据通过普通的 HTTP 传输。从 Web Service 发送到应用程序的数据称为 SOAP 消息。SOAP 消息就是 XML 文档。由于文档是用 XML 编写的，因此调用 Web Service 的客户端应用程序可以用任何编程语言编写。

为什么需要 Web Service？

现代商业应用程序使用各种编程平台来开发基于 Web 的应用程序。有些应用程序可能用 Java 开发，有些用 .Net，还有些用 Angular JS、Node.js 等。

这些异构应用程序通常需要某种形式的通信。由于它们是使用不同的开发语言构建的，因此很难确保应用程序之间的准确通信。

这就是 Web Services 发挥作用的地方。Web Services 提供了一个通用平台，允许使用各种编程语言构建的多个应用程序相互通信。

Web Service 类型

Web Service 主要有两种类型。

SOAP Web Services。
RESTful Web Services.

为了使 Web Service 完全可用，需要具备某些组件。无论用于编程 Web Service 的开发语言是什么，这些组件都需要存在。

让我们更详细地看看这些组件。

SOAP (Simple Object Access Protocol)

SOAP 被称为一种与传输无关的消息协议。SOAP 基于将 XML 数据作为 SOAP 消息传输。每条消息都有一个称为 XML 文档的部分。只有 XML 文档的结构遵循特定的模式，而内容则不。Web Services 和 SOAP 的最佳之处在于它们都通过 HTTP 发送，而 HTTP 是标准的 Web 协议。

SOAP 消息包含以下内容：

每个 SOAP 文档都需要有一个根元素，称为 <Envelope> 元素。根元素是 XML 文档中的第一个元素。
“envelope”又分为两部分：第一部分是 header（头部），第二部分是 body（主体）。
Header 包含路由数据，基本上是告诉 XML 文档需要发送给哪个客户端的信息。
Body 将包含实际消息。

下图展示了通过 SOAP 进行通信的简单示例。

我们将在本教程中详细讨论 SOAP。

WSDL (Web services description language)

找不到 Web Service 就无法使用它。调用 Web Service 的客户端应该知道 Web Service 实际位于何处。

其次，客户端应用程序需要知道 Web Service 实际做什么，以便它能够调用正确的 Web Service。这通过 WSDL（Web services description language）来实现。WSDL 文件也是一个基于 XML 的文件，它基本上告诉客户端应用程序 Web Service 的功能。通过使用 WSDL 文档，客户端应用程序将能够了解 Web Service 的位置以及如何利用它。

Web Service 示例

下面提供了一个 WSDL 文件的 Web Service 示例。

<definitions>	
   <message name="TutorialRequest">
      <part name="TutorialID" type="xsd:string"/>
   </message>
     
   <message name="TutorialResponse">
      <part name="TutorialName" type="xsd:string"/>
   </message>

   <portType name="Tutorial_PortType">
      <operation name="Tutorial">
         <input message="tns:TutorialRequest"/>
         <output message="tns:TutorialResponse"/>
      </operation>
   </portType>

   <binding name="Tutorial_Binding" type="tns:Tutorial_PortType">
      <soap:binding style="rpc"
         transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="Tutorial">
         <soap:operation soapAction="Tutorial"/>
         <input>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </input>
         
		 <output>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </output>
      </operation>
   </binding>
</definitions>

关于上述 Web Services 的 WSDL 声明示例，需要注意的重要方面如下：

<message> – WSDL 定义中的 message 参数用于定义 Web Service 执行的每个操作的不同数据元素。因此，在上面的 Web Services 示例中，我们有两个可以在 Web Service 和客户端应用程序之间交换的消息，一个是“TutorialRequest”，另一个是“TutorialResponse”操作。TutorialRequest 包含一个名为“TutorialID”的元素，其类型为 string。类似地，TutorialResponse 操作包含一个名为“TutorialName”的元素，其类型也为 string。
<portType> – 这实际上描述了 Web Service 可以执行的操作，在本例中称为 Tutorial。此操作可以接收两个消息：一个输入消息和一个输出消息。
<binding> – 此元素包含使用的协议。因此，在本例中，我们将其定义为使用 http (http://schemas.xmlsoap.org/soap/http)。我们还为操作主体指定了其他详细信息，例如命名空间以及消息是否应进行编码。

我们将在本教程中详细讨论“WDSL”。

UDDI (Universal Description, Discovery, and Integration)

UDDI 是一个用于描述、发布和发现特定服务提供商提供的 Web Services 的标准。它提供了一个有助于托管 Web Services 信息的规范。

现在，我们在上一主题中讨论了 WSDL 以及它如何包含 Web Service 实际功能的信息。但是，客户端应用程序如何找到 WSDL 文件来理解 Web Service 提供的各种操作呢？UDDI 就是解决这个问题的答案，它提供了一个可以托管 WSDL 文件的存储库。因此，客户端应用程序将能够完全访问 UDDI，UDDI 充当包含所有 WSDL 文件的数据库。

正如电话簿包含特定人的姓名、地址和电话号码一样，UDDI 注册中心也会包含 Web Service 的相关信息。这样，客户端应用程序就知道在哪里可以找到它。

Web Services 的优势

我们已经明白了 Web Services 最初出现的原因，即提供一个平台来允许不同应用程序相互通信。

但是，让我们看看 Web Services 的优势列表，了解使用 Web Services 的重要性。

在网络上公开业务功能 – Web Service 是一个托管代码单元，为客户端应用程序或最终用户提供某种功能。可以通过 HTTP 协议调用此功能，这意味着也可以通过 Internet 调用它。如今，所有应用程序都已联网，这使得 Web Services 的目的更加有用。这意味着 Web Service 可以位于 Internet 上的任何位置，并按需提供必要的功能。
应用程序之间的互操作性 – Web Services 允许各种应用程序相互通信，并在它们之间共享数据和服务。所有类型的应用程序都可以相互通信。因此，您无需编写只能被特定应用程序理解的特定代码，而是可以编写所有应用程序都能理解的一般代码。
人人都能理解的标准协议 – Web Services 使用行业标准协议进行通信。所有四个层（服务传输、XML 消息传递、服务描述和服务发现层）在 Web Services 协议栈中使用明确定义的协议。
降低通信成本 – Web Services 使用 SOAP over HTTP 协议，因此您可以使用现有的低成本 Internet 来实现 Web Services。

Web Services 架构

每个框架都需要某种架构来确保整个框架按预期工作，Web Services 也是如此。Web Services 架构由以下三个不同的角色组成：

提供者 (Provider) – 提供者创建 Web Service 并使其可供想要使用的客户端应用程序使用。
请求者 (Requestor) – 请求者不过是需要联系 Web Service 的客户端应用程序。客户端应用程序可以是 .Net、Java 或任何其他语言的应用程序，它们通过 Web Service 寻求某种功能。
代理 (Broker) – 代理不过是提供 UDDI 访问权限的应用程序。如前一主题所述，UDDI 使客户端应用程序能够定位 Web Service。

下图展示了服务提供商、服务请求者和服务注册中心如何相互交互。

Web Services Architecture — Web Services 架构

发布 (Publish) – 提供者通过使用代理的发布接口通知代理（服务注册中心）Web Service 的存在，使客户端可以访问该服务。
查找 (Find) – 请求者咨询代理以定位已发布的 Web Service。
绑定 (Bind) – 根据从代理（服务注册中心）获取的关于 Web Service 的信息，请求者能够绑定或调用 Web Service。

Web Service 的特点

Web Services 具有以下特殊的行为特征：

基于 XML – Web Services 在表示层和数据传输层使用 XML 来表示数据。使用 XML 消除了任何网络、操作系统或平台依赖性，因为 XML 是所有人都理解的通用语言。
松耦合 – 松耦合意味着客户端和 Web Service 之间没有绑定，这意味着即使 Web Service 随时间变化，也不应改变客户端调用 Web Service 的方式。采用松耦合架构有助于使软件系统更易于管理，并允许不同系统之间更简单的集成。
同步或异步功能 – 同步性是指客户端与服务的执行绑定。在同步操作中，客户端会等待 Web Service 完成操作。例如，可能是数据库读写操作。如果数据从一个数据库读取然后写入另一个数据库，则操作必须按顺序进行。异步操作允许客户端调用一项服务，然后并行执行其他功能。这是确保在执行特定操作时不会停止其他服务的常用且可能最受青睐的技术之一。
支持远程过程调用 (RPC) 的能力 – Web Services 使客户端能够使用基于 XML 的协议调用远程对象上的过程、函数和方法。远程过程公开了 Web Service 必须支持的输入和输出参数。
支持文档交换 – XML 的关键优势之一是其通用表示方式，不仅可以表示数据，还可以表示复杂文档。这些文档可以很简单，例如表示当前地址，也可以很复杂，例如表示一整本书。