解读 WebService

以下部分内容引自：《Web Service学习》（该文还讲述了如何利用.NET实现WebService）

脑图链接

WebService是要做什么？

Web Service的主要目标是跨平台的可互操作性。为了实现这一目标，Web Service 完全基于XML（可扩展标记语言）、XSD（XML Schema）等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。

WebService从表面看，是一个能够通过Web调用的API，可以理解为统一使用80端口提供的RPC服务集；从深层看，WebService是构建分布式系统、实现可互操作的新的技术架构，是一个平台，是一套标准。

WebService 的架构设计到以下几个层面：通讯层、数据层、应用层。

WebService 组件

SOAP

简单对象访问协议（Simple Object Access Protocol）是交换数据的一种协议规范，是一种轻量的、简单的、基于XML的协议，它被设计成在WEB上交换结构化的和固化的信息。

以下内容部分引自：《菜鸟教程》

为什么使用 SOAP？

对于应用程序开发来说，使程序之间进行因特网通信是很重要的。通信方式可以归结为两类：

  • 基于socket（TCP or UDP）的数据结构实现通信，例如 RPC、ZeroMQ、ORB 以及其他各类网络中间件，都可以看成是对socket的封装，提供了更易于使用的接口；
  • 基于现有通信框架实现数据的传递，例如HTTP是一套完善的网络数据传输方式，故而可以将数据内容以HTTP协议发送到网络中。

目前的应用程序通过使用远程过程调用（RPC）在诸如 DCOM 与 CORBA 等对象之间进行通信。但 RPC 会产生兼容性以及安全问题；防火墙和代理服务器通常会阻止此类流量……通过 HTTP 在应用程序间通信是更好的方法，因为 HTTP 得到了所有的因特网浏览器及服务器的支持。

那么 WebService 通过HTTP协议发送请求和接收结果时，必须要有一定的格式，并不是说通过HTTP随便发送一个请求就可以的。SOAP 定义了这个标准格式。

SOAP 定义了 WebService 消息 的格式，SOAP协议是基于HTTP协议的，SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。于是乎，运行在不同的操作系统并使用不同的技术和编程语言的应用程序可以互相通信。

SOAP 构建模块

一条 SOAP 消息就是一个普通的 XML 文档，包含下列元素：

  1. 必需的 Envelope 元素，可把此 XML 文档标识为一条 SOAP 消息
  2. 可选的 Header 元素，包含头部信息
  3. 必需的 Body 元素，包含所有的调用和响应信息
  4. 可选的 Fault 元素，提供有关在处理此消息所发生错误的信息

所有以上的元素均被声明于针对 SOAP 封装的默认命名空间中：http://www.w3.org/2001/12/soap-envelope
以及针对 SOAP 编码和数据类型的默认命名空间：http://www.w3.org/2001/12/soap-encoding

语法规则

这里是一些重要的语法规则：

  • SOAP 消息必须用 XML 来编码
  • SOAP 消息必须使用 SOAP Envelope 命名空间
  • SOAP 消息必须使用 SOAP Encoding 命名空间
  • SOAP 消息不能包含 DTD 引用
  • SOAP 消息不能包含 XML 处理指令

组成部分

  • SOAP封装（envelop）：它定义了一个框架，描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们；
  • SOAP编码规则（encoding rules）：它定义了一种序列化机制，用于表示应用程序需要使用的数据类型的实例；
  • SOAP RPC表示（RPC representation）：它定了一个协定，用于表示远程过程调用和应答；
  • SOAP绑定（binding）：它定义了SOAP使用哪种协议交换信息。使用HTTP/TCP/UDP协议都可以。

把 SOAP 绑定到 HTTP 提供了同时利用SOAP的样式和分散的灵活性的特点以及HTTP的丰富的特征库的优点。在HTTP上传送SOAP并不是说SOAP会覆盖现有的HTTP语义，而是HTTP上的SOAP语义会自然的映射到HTTP语义。在使用HTTP作为协议绑定的场合中，RPC请求映射到HTTP请求上，而RPC应答映射到HTTP应答。然而，在 RPC 上使用SOAP并不仅限于HTTP协议绑定，SOAP也可以绑定到TCP和UDP协议上。

SOAP消息结构

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>
...
</soap:Header>

<soap:Body>
...
  <soap:Fault>
  ...
  </soap:Fault>
</soap:Body>

</soap:Envelope>

SOAP 不等于 HTTP + XML

SOAP消息能够与不同的底层传输协议进行绑定——包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用协议（RPC）等大量的应用程序。

当然，最多的情况还是绑定在HTTP协议上面传输。这就导致大多数人认为SOAP就是HTTP + XML，或者认为SOAP是HTTP post请求的一个专用版本，遵循一种特殊的XML消息格式——虽然，我们看到的大多情况确实如此，但这并不是SOAP本质与全部。

WSDL

WSDL 文档仅仅是一个简单的 XML 文档（人为定义的格式化文本）。它包含一系列描述某个 web service 的定义，包括两个层面的信息：

  • 网络服务的定位（地址）
  • 网络服务的接口描述

WebService服务提供商可以通过两种方式来暴露它的WSDL文件地址：

  • 注册到UDDI服务器，以便被人查找；
  • 直接告诉给客户端调用者。

以下内容引自：《菜鸟教程》

文档结构

WSDL 文档是利用这些主要的元素来描述某个 web service 的：

元素定义
<portType> web service 执行的操作
<message> web service 使用的消息
<types> web service 使用的数据类型
<binding> web service 使用的通信协议

示例

<message name="getTermRequest">
  <part name="term" type="xs:string"/>
</message>

<message name="getTermResponse">
  <part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
  <operation name="getTerm">
    <input message="getTermRequest"/>
    <output message="getTermResponse"/>
  </operation>
</portType>

在这个例子中，<portType> 元素把 "glossaryTerms" 定义为某个端口的名称，把 "getTerm" 定义为某个操作的名称。
操作 "getTerm" 拥有一个名为 "getTermRequest" 的输入消息，以及一个名为 "getTermResponse" 的输出消息。
<message> 元素可定义每个消息的部件，以及相关联的数据类型。
对比传统的编程，glossaryTerms 是一个函数库，而 "getTerm" 是带有输入参数 "getTermRequest" 和返回参数 getTermResponse 的一个函数。

UDDI

UDDI 是一个独立于平台的框架（在线企业和服务注册的一个规范），用于通过使用 Internet 来描述服务，发现企业，并对企业服务进行集成。

  • UDDI 是一种用于存储有关 web services 的信息的目录。
  • UDDI 是一种由 WSDL 描述的 web services 界面的目录。

注意：UDDI 经由 SOAP 进行通信。

技术规范 

UDDI数据模型：一个用于描述商业组织和Web Service的XML Schema；

UDDI API：一组用于查找或发布UDDI数据的方法，基于SOAP；

UDDI注册服务（应用）：Web Service中的一种基础设施。

XSD

WebService采用HTTP协议传输数据，采用XML格式封装数据——XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，64位？这些细节对实现互操作性很重要。XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。

WebService平台用XSD来作为其数据类型系统的。当你用某种语言（如.NET或Java,C语言）来构造一个Web service时，为了符合WebService标准，所有你使用的数据类型都必须被转换为XSD类型。不用太担心，你用的工具可能已经自动帮你完成了这个转换。

WebService架构层级

通讯层

HTTP无疑是WebService通讯的主要形式和载体。

除了标准的HTTP之外，WebService也支持FTP协议和SMTP协议。而对于Intranet上，WebService也支持采用中间件来作为传输交互的基础架构，例如IBM的 MQ Series 和 CORBA。

实际上，通讯层的可替换性很强——你可以通过任何一种socket传输协议，实现消息的网络传递。而这个过程对服务提供者来说，基本是透明的。

数据层

数据表现层的XML为WebService上层协议提供了信息、数据描述手段。XML是目前全球范围内描述数据和交换数据的一种标准方式。

在WebService的时代，全部的规范、技术都是以XML为底层核心和构架基础的。对WebService而言，不管是WebService消息的传递（SOAP）、WebService服务接口的描述（WSDL)，或是WebService的查询发现（UDDI）都是将XML作为信息描述和交换的标准方式。

描述数据结构的数据模型（也就是元数据），它本身也是一种数据。因此，描述数据结构的方式也基于XML实现——XML Schema。

消息层

消息是数据的封装形式，

WebService使用的是基于XML的消息交换协议SOAP。SOAP是构建于更低的传输层之上，这意味这SOAP可以单独使用，也可以与任何传输层协议进联合使用。所有的SOAP消息都提供前面说过的WebService架构中的发布（Publish)、绑定(Bind)、和查找(Find)功能。

接口描述层

WSDL文档只是服务的基本描述手段，它可以通过其他服务描述文档来补充，以描述WebServices例如业务环境，服务质量等更高级的信息。 

应用层

应用层包含三个角色——服务终端、请求者（客户端）和服务注册中心。

服务提供者能够直接向服务客户端发送WSDL文档，例如通过Email的形式。
当然，更常见的形式是服务提供者将WSDL发布到本地的UDDI库中，或者是公共/私有的UDDI服务注册中心，服务客户端可以通过注册库发现WSDL文档。

服务客户端可以选择在设计阶段或运行时阶段通过本地WSDL服务注册中心或者公有/私有的UDDI注册中心发现WSDL文档。

服务项

引自：《解道：SOA面向服务架构》

服务两个重要特点：自治和管制。

自治代表服务不能被外部势力牵制，比如在一个服务内部处理中需要调用外部资源或等待外部流程结束，这种等待不能影响服务本身的调用。如果一个服务分为显式对外和隐式内部两个部分，那么自治是针对隐式内部，意味着我们不能在具体一个服务中直接使用同步代码实现复杂功能。如：

public class AServiceImpl :AService{
　　public void productSale(...){
　　　　Product product = productService.getProduct();
　　　　int inventory = InventoryService.getInventory(product);
　　　　int price = priceService.getPrice(product);
　　}
}

在AServiceImpl的productSale方法中，我们获得商品的库存和定价，都是通过同步的RPC实现调用的，这样造成productSale方法依赖于InventoryService和priceService，无法实现自身自治。

服务工作流层

WebService工作流语言（WSFL）是协议栈顶层的服务工作流层的标准语言。与协议栈中其他的标准不同，WSFL针对的是商务流程建模和工作流。WSFL用于描述WebService在工作流中如何交互，以及服务跟服务之间的通信和协同，这意味这WebService可以是工作流的一部分，也可以动态地被编入工作流。特别的，这个工作流有可能发生在买方，卖方和承运方之间。

例如WSFL允许工作流管理器从一个复合WebService中，按工作流来定义依据商业流程赋予的不同功能的，作为其成分的每个个体WebService。这样的商业流程包括财务报表、预测和5年IT计划等。

SOA 与 Web Service 的联系

因为现在几乎所有的SOA应用场合都是和Web Service绑定的，所以不免有时候这两个概念混用。不可否认Web Service是现在最适合实现SOA的技术，SOA的走红在很大程度上归功于Web Service标准的成熟和应用普及。因为现在大家基本上认同Web Service技术在几方面体现了SOA的需要：

  • 首先，是基于标准访问的独立功能实体满足了松耦合要求：在Web Service中所有的访问都通过SOAP访问进行，用WSDL定义的接口封装，通过UDDI进行目录查找，可以动态改变一个服务的提供方而无需影响客户端的配置，外界客户端是根本不关心访问服务器端的实现。
  • 其次，适合大数据量低频率访问符合服务大颗粒度功能：基于性能和效率平衡的要求，SOA的服务提供的是大颗粒度的应用功能，而且跨系统边界的访问频率也不会象程序间函数调用那么频繁。通过使用WSDL和基于文本(Literal)的SOAP请求，可以实现能一次性接收处理大量数据。
  • 最后，基于标准的文本消息传递为异构系统提供通讯机制：Web Service所有的通讯是通过SOAP进行的，而SOAP是基于XML的，XML是结构化的文本消息。从最早的EDI开始，文本消息也许是异构系统间通讯最好的消息格式，适用于SOA强调的服务对异构后天宿主系统的透明性。

综合上述观点，Web Service不愧为当前SOA的最好选择。然而，就SOA思想本身而言，并不一定要局限于Web Service方式的实现。更应该看到的是SOA本身强调的是实现业务逻辑的敏捷性要求，是从业务应用角度对信息系统实现和应用的抽象。随着人们认识的提高，还会有新技术不断的发明出来，更好的来满足这个要求。

非适用场景

单机应用程序

目前，企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下，最好就不要用Web Service，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在同一台服务器上的服务器软件也是这样。当然Web Service 也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。

局域网的一些应用程序

在许多应用中，所有的程序都是在Windows平台下使用COM，都运行在同一个局域网上。在这些程序里，使用DCOM会比SOAP/HTTP有效得多。与此相类似，如果一个.net程序要连接到局域网上的另一个.net程序，应该使用.net Remoting。其实在.net Remoting中，也可以指定使用SOAP/HTTP来进行Web Service 调用。不过最好还是直接通过TCP进行RPC调用，那样会有效得多。

思考

  1. 关于SOAP，作为协议为何需要与XML的具体的描述语言耦合（所谓基于XML）？
    答：任何协议，设计到数据时，总是需要描述数据结构和数据定义——而XML与XSD作为语言无关的数据描述方案，成为了SOAP/WSDL等协议的描述形式——故而称，SOAP是基于XML的协议。这不是耦合，而是不得不用，而选择语言无关的数据定义，已经是最小化的依赖方案了。
  2. 跨平台是HTTP实现的，而不是SOAP！
    答：或者说，SOAP之所以基于HTTP，就是为了继承HTTP这一套平台无关的通讯实现。当然，SOAP也可以采用其他传输模式，如SMTP/MIME，甚至于局域网内的RPC/ORB的消息——所以更底层的说，跨平台是socket（TCP or UDP）实现的，而不是SOAP！
【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/brt3/p/9814294.html