正文
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>
