webServices与Web服务

本篇的内容在MSND中标注已经是一项旧技术，而取而代之的是WCF，

那么我也放弃吧！可是这个属于Web服务的范畴，而WCF本质上也是一个Web服务来的，因此对于基础的东西仍是不变的。那么此次就着重看看这个Web服务的基础知识。

首先仍是形式上的列举一下webServices配置节的内容，尽管它如今没用了，在WCF当中配置用的是system.serviceModel。

   

webservice的三要素：

SOAP（Simple Object Access Protocol）、WSDL(WebServicesDescriptionLanguage)、UDDI(UniversalDescriptionDiscovery andIntegration)之一， soap用来描述传递信息的格式， WSDL 用来描述如何访问具体的接口， uddi用来管理，分发，查询webService 。具体实现能够搜索 Web Services简单实例 ; SOAP 能够和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。SOAP使用基于XML的数据结构和超文本传输协议(HTTP)的组合定义了一个标准的方法来使用Internet上各类不一样操做环境中的分布式对象。

   

   

XML Web services 是一个能提供特定功能元素（例如应用程序逻辑）的可编程实体，可供使用通用 Internet 标准（例如 XML 和 HTTP）的任意数目的潜在独立系统访问。XML Web services 主要依赖普遍接受 XML 及其余 Internet 标准来建立支持应用程序互操做性的基础结构，其支持级别解决了之前妨碍这类尝试的不少问题。

XML Web services 能够由单个应用程序在内部使用，也能够经过 Internet 在外部公开以供任意数目的应用程序使用。因为 XML Web services 可经过标准接口进行访问，所以 XML Web services 容许多个异构系统做为单个计算网络协同工做。

XML Web services 并不追求代码可移植性的通常功能，而是提供了一种实现数据和系统互操做性的可行解决方案。XML Web services 使用基于 XML 的消息做为数据通讯的基本方式，以帮助减小组件模型、操做系统和编程语言不一致的系统之间的差异。开发人员能够在建立应用程序时糅合来自各类来源的 XML Web services，其方式与他们之前在建立分布式应用程序时使用组件的方式大同小异。

XML Web services 的核心特色之一是，服务的实现和使用之间存在高度的抽象。经过将基于 XML 的消息用做服务的建立和访问机制，XML Web services 客户端和 XML Web services 提供程序只要相互知道输入、输出和位置，就不用再了解任何其余信息了。

XML Web services 为分布式应用程序开发开创了一个新时代。这里再也不有对象模型冲突，也无需比较编程语言的美观程度。在使用专有基础结构紧密耦合系统时，是以牺牲应用程序的互操做性来实现的。XML Web services 在全新的层次上提供互操做性，令这些妨碍效率的对手黯然失色。做为 Internet 的下一个革命性成果，XML Web services 将成为连接起全部计算设备的基础结构。

若想在复杂的网络中顺利执行，XML Web services 必须不受所选用的操做系统、对象模型和编程语言的影响。另外，若想让 XML Web services 像其余基于 Web 的技术那样受到普遍采用，就必须知足下列条件：

• 松耦合：若是对两个系统所施加的惟一要求是了解上述基于文本的自述消息，则这两个系统将被视为松耦合。相反，紧密耦合的系统在进行通讯时会消耗大量的自定义开销，并须要两个系统之间加强了解。
• 无所不在的通讯：目前或不久的未来，人们所构建的操做系统通常都可以链接到 Internet，从而提供一个无处不在的通讯渠道。所以，若是具有这种几乎可以将任何系统或设备链接到 Internet 的能力，便可确保这类系统和设备可普遍地供任何链接到 Internet 的其余系统或设备使用。
• 通用的数据格式：经过对专用的闭环通讯方法采用现有的开放标准，任何支持相同开放标准的系统都可以了解 XML Web services。经过利用 XML Web services 及其客户端无需知道每一个基础系统的构成便可共享的自述性文本消息，能够在独立系统与其余系统之间进行通讯。XML Web services 即是使用 XML 来实现此功能。

   

XML Web services 使用的基础结构提供下列内容：用于查找 XML Web services 的发现机制、用于定义服务用法的服务说明以及通讯所使用的标准连网格式。下面的插图显示了这种基础结构的一个示例。

XML Web services 目录

   

与 Internet 上的任何其余资源同样，要在不使用一些搜索方式的状况下找到某个特定的 XML Web services 几乎是不可能的。XML Web services 目录提供了多个中心位置，XML Web servicers 提供方能够在那里发布有关他们所提供的 XML Web services 的信息。这类目录甚至能够是 XML Web services 自己，能够经过编程方式来访问，它们经过响应来自潜在的 XML Web services 客户端的查询来提供搜索结果。可能有必要使用 XML Web services 目录找到为了某种特定目的而提供 XML Web services 的组织或者肯定某个特定组织所提供的 XML Web services。UDDI（通用描述、发现和集成）规范定义了一种发布和发现 XML Web services 相关信息的标准方式。与 UDDI 关联的 XML 架构定义了四种类型的信息，经过这些信息开发人员可使用已发布的 XML Web services。它们是：业务信息、服务信息、绑定信息和有关服务规范的信息。

XML Web services 发现

XML Web services 发现是指查找（即发现）一个或多个用 Web 服务描述语言 (WSDL) 描述特定 XML Web services 的相关文档的过程。正是经过发现过程，XML Web services 客户端才了解到存在 XML Web services 以及在何处查找 XML Web services 的说明文档。

已发布的 .disco 文件是一个 XML 文档，其中包含描述 XML Web services 的其余资源的连接，于是可以实现以编程方式发现 XML Web services。下面演示发现文档的结构示例：

由上面的发现文档内容看出有三个URL，其中有两个是同样的http://www.contoso.com/Counter.asmx，剩下一个是http://www.contoso.com/Counter.asmx?wsdl，看它的属性感受是前者是文档的地址，后者才是服务的地址，可是根据在我以往使用的配置中发现不带wsdl的才是服务地址，并且WSDL正是web service三要素中的web服务描述语言的缩写，感受后者才是文档的地址。

例以下面就是某个WCF服务的WSDL

那么它不带WSDL的就是发现地址，感受就是UDDI

   

注意：发现文档是一个元素容器，其中的元素一般包含一些指向资源的连接 (URL)，这些资源提供 XML Web services 的发现信息。若是 URL 是相对的，则认为它们相对于发现文档的位置。

可是，实现 XML Web services 的网站并不须要支持发现。另外一个网站能够负责描述该服务，例如 XML Web services 目录。另外，可能不存在查找该服务的公共方式。例如在建立供专门使用的服务时，就会出现这种状况。

XML Web services 说明

XML Web services 基础结构所依据的通讯方式是基于 XML 且符合已发布的服务说明的消息。服务说明是用称为 WSDL（Web 服务描述语言）的 XML 语法编写的 XML 文档，用于定义 XML Web services 可以识别的消息格式。服务说明的做用就至关于协议，它定义 XML Web services 的行为，并指示潜在客户端如何与该服务交互。XML Web services 的行为由该服务定义和支持的消息模式决定。这些模式从概念上指示，在将格式正确的消息提交给 XML Web services 时，服务使用方能够指望出现哪些行为。

例如，与远程过程调用 (RPC) 样式服务关联的请求/响应模式会定义将使用何种 SOAP 消息架构来调用特定的方法。此模式还会定义随后的响应 SOAP 消息应遵循哪一种格式。

又如，还有一种消息模式表示单向交互。在进行单向通讯时，就会使用这种模式。在这种状况下，发送方将不会接收到来自 XML Web services 的任何消息，包括错误消息。须要注意的是，若是创建单向通讯时使用的协议采用传统的请求/响应模式，则可能会返回错误消息。

定义 SOAP 消息格式的架构能够在实际服务说明的内部定义，也能够在外部定义好后再导入到服务说明中。

除了消息格式定义和消息模式外，服务说明还能够包含与每一个 XML Web services 入口点关联的地址。此地址的格式应当与用于访问服务的协议相对应，例如 HTTP 的 URL 或 SMTP 的电子邮件地址。

有关 WSDL 规范，请参见 W3C 网站 (http://www.w3.org/TR/wsdl)。

XML Web services 连网格式

DCOM 等二进制协议包括一个驻留在专有通讯协议之上的方法请求层。这类协议不适合建立通用的 XML Web services。然而，这不会阻止您在 XML Web services 方案中使用这类协议，但使用这类协议的缺点是它们依赖于其基础系统的特定体系结构，于是限制了潜在客户端的范围。

或者，您能够构造使用一个或更多开放式协议（如 HTTP 和 SOAP 协议的组合）的 XML Web services。支持不一样的协议所必需的基础结构各不相同。

XML Web services 不限于提供远程过程调用 (RPC) 访问。还能够生成 XML Web services，用来交换采购订单和发票等结构化信息，以及用于自动化和链接内部及外部业务流程。

HTTP-GET 和 HTTP-POST

HTTP-GET 和 HTTP-POST 是标准协议，它们使用 HTTP（超文本传输协议）谓词对参数进行编码并将参数做为名称/值对传递，还使用关联的请求语义。每一个协议都包括一系列 HTTP 请求标头，HTTP 请求标头及其余一些信息定义客户端向服务器请求哪些内容，哪一个服务器用一系列 HTTP 响应标头和所请求的数据进行响应（若是成功）。

HTTP-GET 使用 MIME 类型 application/x-www-form-urlencoded（将追加处处理请求的服务器的 URL 中）以 URL 编码文本的形式传递其参数。URL 编码是一种字符编码形式，可确保传递的参数中包含一致性文本，例如将空格编码为 %20。追加的参数也称为查询字符串。

与 HTTP-GET 相似，HTTP-POST 参数也是 URL 编码的。可是，名称/值对是在实际的 HTTP 请求消息内部传递的，而不是做为 URL 的一部分进行传递。

SOAP

SOAP 是一种简单的基于 XML 的轻量协议，用于在 Web 上交换结构化信息和类型信息。SOAP 的整体设计目标是使其尽可能简单，并提供最低限度的功能。该协议定义一个不包含应用程序或传输语义的消息传递框架。所以，该协议是模块化的且高度可扩展。

经过在标准传输协议之上传输，SOAP 可使用 Internet 的现有开放式体系结构，而且容易被可以支持最基本的 Internet 标准的任意系统所接受。能够将支持符合 SOAP 的 XML Web services 所必需的基础结构看做是一种很是简单且强大的基础结构，由于它向 Internet 的现有基础结构添加相对较少的内容，但仍然有助于对用 SOAP 生成的服务进行通用访问。

SOAP 协议规范包括四个主要部分。第一部分定义用于封装数据的必需的可扩展信封。SOAP 信封定义 SOAP 消息，是 SOAP 消息处理程序之间的基本交换单位。这是该规范中惟一的一个必需部分。

SOAP 协议规范的第二部分定义了可选的数据编码规则和一个统一模型，数据编码规则用来表示应用程序定义的数据和有向图，统一模型用来序列化非语法数据模型。

第三部分定义 RPC 样式（请求/响应）消息交换模式。每一个 SOAP 消息都是单向传输。虽然 SOAP 的根位于 RPC 中，但它并不局限于成为一种请求/响应机制。XML Web services 一般组合 SOAP 消息以实现这类模式，但对于 SOAP 而言消息交换模式并非必需的，而且这一部分规范也是可选的。

规范的第四部分定义 SOAP 与 HTTP 之间的绑定。可是，这部分也是可选的。能够将 SOAP 与任何能够传输 SOAP 信封的传输协议或机制结合使用，其中包括 SMTP、FTP，甚至还包括软盘。

   

有关 SOAP 规范，请参见 W3C 网站 (http://www.w3.org/TR/ soap)。

使用 SOAP 与 Web 服务方法进行通讯遵循标准格式。此格式的一部分是在 XML 文档中编码的数据。XML 文档包含一个 Envelope 根元素，该元素又由必需的 Body 元素和可选的 Header 元素构成。Body 元素由特定于消息的数据构成。可选的 Header 元素能够包含不与特定消息直接相关的其余信息。Header 元素的每一个子元素都被称为 SOAP 标头。

尽管 SOAP 标头能够包含与消息相关的数据，但因为 SOAP 规范并未严格定义 SOAP 标头的内容，所以其中一般包含 Web 服务器内由基础结构处理的信息。SOAP 标头的用法示例是在 SOAP 标头内为 SOAP 消息提供路由信息。

   

来自 <https://msdn.microsoft.com/zh-cn/library/77hkfhh8.aspx>

   

在以前提供的web服务中看到了某个方法的SOAP内容，以下

看这段就知道该web服务使用的是HTTP协议，请求的时候是用了POST方法，xml格式 utf-8字符编码，post内容就是那对xml，固然length,string都是一些占位符，这么说来或许我也能够试试本身拼一个HTTP POST请求过去，看可否获取到对应的内容。这些格式都是有前面的WSDL发现的。.NET Framework内部都把这些操做所有封装起来，若是要尝试的话大能够本身写个程序从发现WSDL走起（固然.disco文件我如今也没见到，不知如何获取并解析），拿到它的WSDL，而后解析成SOAP（或者直接请求得到SOAP？？？），创建起一些代理类，在代理类内部经过HTTP请求把调用代理方法的参数拼装到HTTP请求中，看可否获得对应的响应，若是有响应了按照SOAP把结果解析出来，造成代理方法的返回。可是响应及返回这块也涉及到以前WSDL中说到的消息交互的模式（如单向）。但目前我对WSDL的了解不足以实现这个。

   

这是本系列的最后一篇。

   

参考文章

webServices 元素（ASP.NET 设置架构）

来自 <https://msdn.microsoft.com/zh-cn/library/ms228319(VS.85).aspx>

   

<webServices> 元素

来自 <https://msdn.microsoft.com/zh-cn/library/cs8x2624.aspx>

   

   

XML Web services 基础结构

来自 <https://msdn.microsoft.com/zh-cn/library/sd5s0c6d(v=vs.100).aspx>

   

使用 SOAP 标头

来自 <https://msdn.microsoft.com/zh-cn/library/77hkfhh8.aspx>