分布式计算、云计算与大数据第七章

Web Services概述

Web Services背景和概念

  WEB应用与传统的桌面应用之间存在连接上的鸿沟，平台的互操作性差和异构性等问题严重影响了WEB应用的发展。Web Services的出现正是为了解决跨应用系统、跨平台、跨架构的互操作问题。
  WebService是一种跨编程语言和跨操作系统平台的远程调用技术。通过Web Services可以使运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件，就可以相互交换数据或进行集成。因此，无论应用之间采用什么语言、平台或内部协议，都可以方便地进行数据的交换。
  Web Services是基于一些常规的产业标准和已有的成熟技术，如XML和HTTP等开放式Web规范技术，因此，它具有很好的开放性和互操作性。此外，Web Services的协议、接口和注册以松耦合方式协同工作，减少了应用程序接口的花费，为整个企业间业务流程集成提供了一个通用机制。

Web Services特点

良好的封装性
  Web Services是一种部署在Web上的对象，因此具有对象的特点，即良好的封装性。这样服务使用者只能看到对象提供的通用接口和功能列表，而不用关心服务的实现细节。
松耦合
  只要Web Services的调用接口不变，其内部变更对调用者来说是透明的。使用标准协议规范Web服务是基于XML的消息交换机制，其所有公共的协约都采用Internet开放标准协议进行描述、传输和交换。相比一般对象而言，其调用更加规范化，便于机器理解。
高度可集成性
  由于Web Services采取简单的、易于理解的标准协议作为组件描述，因此完全屏蔽了不同软件、平台的差异，使它们之间可以通过Web Services来实现互操作。
易于构建
  要构建Web Services，开发人员可以使用任何常用的编写语言（如Java、C#、C/C++或Perl等）及其现有的应用程序组件。

Web Services应用场合

跨防火墙的通信
  把应用程序的中间层换成Web Services，可以从客户端直接调用服务，而不需要建立额外的ASP页面。同时作为中间层的Web Services完全可以在应用程序集成场合下重用。这样不仅减少了开发周期和代码复杂度，还能够增强应用程序的重用性和可维护性。
应用程序集成
  通过Web Services把应用之间需要“暴露”给对方的功能和数据，以服务接口的形式提供给调用者，而不用去在意各应用程序之间异构性，因为Web Services是采用开放的、标准的、跨平台的协约来执行的。
B2B的集成
  Web Services是实现B2B应用程序高效集成的重要技术之一，电子商务公司可以根据业务需求将应用的接口“暴露”给指定的客户或供应商，以方便客户和供应商高效地完成电子业务。
软件和数据重用
  组件提供商可以把组件变成Web Services，并把相应的服务接口提供给服务使用者。这样，服务使用者无需将服务组件下载到本地并安装，而是直接在应用中调用服务，获取所需的数据。

Web Services技术架构

三种主流的Web服务实现方案：
REST
  表述性状态转移（Representational State Transfer）
采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将所有 Web 系统的服务抽象为资源，REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表述（representation）。REST是一种软件架构风格而非协议也非规范，是一种针对网络应用的开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
SOAP
  简单对象访问协议（Simple Object Access Protocol）
一种标准化的通讯规范，主要用于Web服务（web service）中。
用一个简单的例子来说明 SOAP 使用过程，一个 SOAP 消息可以发送到一个具有 Web Service 功能的 Web 站点，例如，一个含有房价信息的数据库，消息的参数中标明这是一个查询消息，此站点将返回一个 XML 格式的信息，其中包含了查询结果（价格，位置，特点，或者其他信息）。由于数据是用一种标准化的可分析的结构来传递的，所以可以直接被第三方站点所利用。
XML-RPC
  远程过程调用（Remote Procedure Call，RPC)
通过XML将调用函数封装，并使用HTTP协议作为传送机制。后来在新的功能不断被引入下，这个标准慢慢演变成为今日的SOAP协定。XML-RPC协定是已登记的专利项目。XML-RPC透过向装置了这个协定的服务器发出HTTP请求。发出请求的用户端一般都是需要向远端系统要求呼叫的软件。

Web Services的开发

Web Services的开发周期包括服务的构建、部署、运行和管理。
在Web服务的实践开发中，有以下四种模式：
零起点开发模式
  开发者不仅要创建Web服务，还要创建与Web 服务相集成的应用程序（服务功能代码），然后才能部署和发布整套Web服务。通常，我们先创建服务功能代码，然后使用Axis创建WSDL服务描述和部署描述，这样便可以部署和发布整个Web服务了。

自底向上开发模式
  不需要创建与Web服务相集成的应用程序，而是使用现有的、或遗留的应用程序代码作为服务功能代码。然后使用工具从这些服务功能代码导出相应的WSDL服务描述，再部署和发布即可。

自顶向下开发模式
  相当于Web服务的WSDL服务描述已经存在了，此时WSDL相当于一种规范，我们只要按着这种规范创建相应的服务功能代码（如Java类），然后将服务功能代码和WSDL相关联，并部署和发布即可。

中间相遇开发模式
  是自底向上和自顶向下两种开发方案的组合，此时不仅存在Web服务的接口，也存在服务功能性代码，但它们可能并不满足既定需求，而需要做适当的修整。因此，只要对二者进行修整，再结合起来，部署并发布服务即可。

XML

XML概述

  XML是Extended Markup Language的缩写，即可扩展标记语言。它是一种广泛应用于互联网分布式计算中的、简单的、跨平台的结构化数据或数据结构标记语言。同时，XML是一种元语言，即用户可以根据实际需求设计自定义的标记来描述数据，XML中使用文档类型定义（DTD）或者模式（Schema）来描述数据。
  XML具有其跨平台、与软硬件无关的优点，以XML为基石不断催生着各种新技术的到来，如SOAP、WSDL和XSL等，它们为Web技术的发展提供了不竭动力。XML具有以下特点：
可扩展性
自描述性
简洁性
数据的描述与显示相分离
易于数据的交换和共享
易于充分利用数据
可用于创造新的语言

XML Schema

  XML Shema，即XML模式。在XML中模式用来描述文档类型，即把特定的XML文档当做一种规范来描述，XML Schema定义了一类XML文档。
  XML是Web Services的基石，以SOAP为例，SOAP消息就是以XML文档形式存在的，而消息中包含有待交互的数据，通过网络传输即可与服务进行交互。但服务接收者会接收到各种各样的SOAP消息，要识别出哪些SOAP消息格式是满足要求的，必须通过一定的机制，那就是XML Schema。通过XML Schema可以检测一个SOAP消息是否满足预定义模式要求，再决定是否接受消息。

SOAP Web Services

SOAP概述

  SOAP(Simple Object Access Protocol，简单对象访问协议）是一种基于XML的、轻量级的、跨平台的数据交换协议。SOAP不仅描述了数据类型的消息格式及一整套串行化规则，包括结构化类型和数组，还描述了如何使用HTTP来传输消息。SOAP提供了应用程序之间的交互能力。
SOAP主要包括以下四个部分：
SOAP Envelope——用于定义一个描述消息中的内容、发送者、接收者、处理者及如何处理的整体表示框架。
SOAP编码规则——定义了一套编码机制用于交换应用程序定义的数据类型的实例。
SOAP RPC——表示远程过程调用和应答的协定。
SOAP绑定 ——定义了一种使用底层传输协议来完成节点间交换SOAP消息的约定。

SOAP消息交换模型

  SOAP是基于XML的消息式数据交换协议，为了准确地实现应用与服务间数据的互操作，SOAP消息的提供者与请求者都必须访问相同的XML模式。
  SOAP消息交换是从发送方到接收方的一种传输方法。从本质上说，SOAP是一种无状态的协议，它提供符合的单向消息交换框架，以便在称为SOAP节点的SOAP应用程序之间传输XML文档。
  SOAP节点既可以是SOAP消息的发送者，也可以是SOAP消息的接收者，或者是SOAP消息的发送者和接收者放入中介。由于SOAP并不提供路由机制，因此SOAP需要识别发送者发送的SOAP消息应当通过哪些SOAP中介才能到达接收者处。此外，接收到SOAP消息的节点必须能够实时处理被产生必要的SOAP错误和SOAP响应，如果合适，还应当根据SOAP规范的后续描述生成额外的SOAP消息。
  SOAP Header中actor属性可以用来标识SOAP的角色，SOAP角色是SOAP节点在处理SOAP消息时的身份。actor属性的值是一个URI，例如：http://www.w3.org/2003/05/soap-envelope/actor/next。当SOAP节点在处理一个SOAP消息时，其SOAP角色在整个处理过程中是不变的，因为SOAP是无状态的。含actor属性的SOAP Header匹配了一个SOAP节点，或者此SOAP Header没有actor属性，而采用匿名角色，则我们称SOAP Header指向了一个SOAP节点。

SOAP应用模式

按照SOAP应用环境的不同，将SOAP分为五类：
请求/响应模式
  请求/响应方式的SOAP服务，即服务请求者将请求发送给服务接收者，服务接收者接收到发送者的请求后，再获取并处理其中的数据，最后将处理结果信息以SOAP消息方式回送给服务请求者。如果请求消息没有被接收到，或没有被期望的业务应用所处理，那么保障通信的传输层会产生相应的状态信息，并报告给SOAP发送者。

fire-and-forget模式
  fire-and-forget一词源于军事中，比喻当某种武器当被发射出后，便不用人们再去控制，而可以自行寻找攻击目标。把它用在SOAP中时，表示SOAP消息一经发出，便不用发送者关心，SOAP消息自己会寻找相应的接收者。
  按照SOAP消息接收者的多少，可以将fire-and-forget分为两类，一种是面向单个接收者的，另一种是面向多个接收者的。面向单个接收者指发送者要求该SOAP消息只被一个接收者接受，且不要求予以回复发送报告，比如是否发送完成、是否已被接收等报告。面向多个接收者指的是发送者要求该SOAP消息被发送给一组接收者，也不要求回复发送报告。

高级消息模式
  会话消息模式——基于会话的消息模式，双方会长时间维持一个会话进程，其中包含了双方多次的消息交互。
  异步消息模式——此种模式下，发送者发送SOAP消息后，并不期望接收者接收并处理后立即予以响应，而允许接收者在一定的时间段内给予回复。异步方式更加适合于实际应用。
  事件通知模式——此种模式类似于“订阅”。应用程序向一个事件源订阅了一些特定的事件通知，当事件发生时，事件源便按照订阅者的要求将通知发送给原订阅者，或其他指定的用户。

增量解析和处理模式
  当SOAP消息过于庞大，给传输带来困难时，往往想到的是分组来发送，类似于计算机网络中IP数据报的分组。
  按照一定机制将冗长的SOAP消息分割后，由多个SOAP消息来发送，待接收者收到这些分片的消息后，再对分片进行重组和处理。
  这种模式缩短了消息传输延时，降低了通信阻塞，使SOAP服务效率得以提高。但此模式要求发送者和接收者都具备增量解析和处理消息的能力。

缓存模式
  在SOAP消息中，为了缩短响应时延、占用更小的带宽，可以将一些常用的消息存储在缓存中，供相关应用或SOAP节点使用。

WSDL

  WSDL（Web Services Description Language，Web服务描述语言）是一种基于XML的、专门用于描述Web Services的语言。通过WSDL可以对服务的功能信息、功能参数的消息类型、协议绑定信息和特定服务的地址信息进行描述。
  WSDL文档将服务访问点、消息的抽象定义与具体服务部署、数据格式的绑定分离开来，因此可以对抽象定义进行重用。在WSDL中，消息指对数据的抽象描述，端口类型指的是操作的抽象几何，端口类型使用的具体协议和数据格式规范构成了一个绑定，将Web访问地址与可再次使用的绑定相关联来以定义一个端口，而端口的集合则称为服务。

UDDI

  UDDI（Universal Description、Discovery and Integeration，统一描述、发现和集成）一套基于Web的分布式的Web Services信息注册中心的实现标准规范，也包含一组访问协议的实现标准，使得企业能将自身的Web Services注册上去，并让其他企业能够发现并使用这些服务，使服务更容易被获取。
UDDI中所提供的信息可以分为以下三类：
  白页——表示企业的基本信息，如企业的名称、地址、联系方式、经营范围、企业标识、税号等。
  黄页——用来依据标准分类法区分不同的行业类别，使企业能够在更大的范围（如地域范围）内查找已经在注册中心注册的企业或Web服务。
  绿页——包括了关于该企业所提供的Web服务的技术信息，其形式可能是一些指向文件或是URL的指针，而这些文件或URL是服务发现机制的必要组成部分。