第7章 Web Services
Web Services概述
Web Services背景和概念
1.WEB应用与传统的桌面应用之间存在连接上的鸿沟，平台的互操作性差和异构性等问题严重影响了WEB应用的发展。Web Services的出现正是为了解决跨应用系统、跨平台、跨架构的互操作问题。
2.WebService是一种跨编程语言和跨操作系统平台的远程调用技术。通过Web Services可以使运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件，就可以相互交换数据或进行集成。因此，无论应用之间采用什么语言、平台或内部协议，都可以方便地进行数据的交换。
3.Web Services是基于一些常规的产业标准和已有的成熟技术，如XML和HTTP等开放式Web规范技术，因此，它具有很好的开放性和互操作性。此外，Web Services的协议、接口和注册以松耦合方式协同工作，减少了应用程序接口的花费，为整个企业间业务流程集成提供了一个通用机制。
Web Services 特点
1.良好的封装性
—Web Services是一种部署在Web上的对象，因此具有对象的特点，即良好的封装性。这样服务使用者只能看到对象提供的通用接口和功能列表，而不用关心服务的实现细节。
2.松耦合
—只要Web Services的调用接口不变，其内部变更对调用者来说是透明的。使用标准协议规范Web服务是基于XML的消息交换机制，其所有公共的协约都采用Internet开放标准协议进行描述、传输和交换。相比一般对象而言，其调用更加规范化，便于机器理解。
3.高度可集成性
—由于Web Services采取简单的、易于理解的标准协议作为组件描述，因此完全屏蔽了不同软件、平台的差异，使它们之间可以通过Web Services来实现互操作。
4.易于构建
—要构建Web Services，开发人员可以使用任何常用的编写语言（如Java、C#、C/C++或Perl等）及其现有的应用程序组件。
Web Services应用场合
1.跨防火墙的通信
–把应用程序的中间层换成Web Services，可以从客户端直接调用服务，而不需要建立额外的ASP页面。同时作为中间层的Web Services完全可以在应用程序集成场合下重用。这样不仅减少了开发周期和代码复杂度，还能够增强应用程序的重用性和可维护性。
2.应用程序集成
–通过Web Services把应用之间需要“暴露”给对方的功能和数据，以服务接口的形式提供给调用者，而不用去在意各应用程序之间异构性，因为Web Services是采用开放的、标准的、跨平台的协约来执行的。
3.B2B的集成
–Web Services是实现B2B应用程序高效集成的重要技术之一，电子商务公司可以根据业务需求将应用的接口“暴露”给指定的客户或供应商，以方便客户和供应商高效地完成电子业务。
4.软件和数据重用
–组件提供商可以把组件变成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请求。发出请求的用户端一般都是需要向远端系统要求呼叫的软件。
三种方案的比较
1.XML-RPC已慢慢的被SOAP所取代，现在很少采用了，但它还是有版权的；SOAP在成熟度上优于REST；在效率和易用性上，REST更胜一筹；在安全性上，SOAP安全性高于REST，因为REST更关注的是效率和性能问题。
2.SOAP是Web Services的核心技术，且现在大多数Web Services都是基于SOAP的，其应用开发也相对成熟。REST是一项新技术，它不是协议、不是架构，严格来说也不属于Web Services；它只是一种抽象的软件设计观念，要求从资源的角度来考虑问题。因此，Web Services的核心架构其实就是SOAP技术，而REST是理念。
Web Services工作原理
1.一般Web Services角色包括服务提供者、服务注册中心和服务使用者：
(1)服务提供者注册和发布自己的服务在服务注册中心中，并对服务请求进行响应；
(2)服务注册中心担任中介的作用，一边接收服务提供者发来的服务，一边供服务提供者在其统一目录中查找合适的服务；
(3)服务使用者是根据具体的应用需求调用服务的。
2.在典型情况下，服务提供者托管可通过网络访问特定的软件模块，定义Web Services的服务描述并将服务发布到服务注册中心统一目录中；服务请求者使用查找操作从注册中心中检索特定的服务，然后使用服务描述与服务提供者进行绑定并调用相应的服务。
Web Services的开发
1.Web Services的开发周期包括服务的构建、部署、运行和管理。
2.在Web服务的实践开发中，有以下四种模式：
(1)零起点开发模式
开发者不仅要创建Web服务，还要创建与Web 服务相集成的应用程序（服务功能代码），然后才能部署和发布整套Web服务。通常，我们先创建服务功能代码，然后使用Axis创建WSDL服务描述和部署描述，这样便可以部署和发布整个Web服务了。
(2)自底向上开发模式
不需要创建与Web服务相集成的应用程序，而是使用现有的、或遗留的应用程序代码作为服务功能代码。然后使用工具从这些服务功能代码导出相应的WSDL服务描述，再部署和发布即可。
(3)自顶向下开发模式
相当于Web服务的WSDL服务描述已经存在了，此时WSDL相当于一种规范，我们只要按着这种规范创建相应的服务功能代码（如Java类），然后将服务功能代码和WSDL相关联，并部署和发布即可。
(4)中间相遇开发模式
是自底向上和自顶向下两种开发方案的组合，此时不仅存在Web服务的接口，也存在服务功能性代码，但它们可能并不满足既定需求，而需要做适当的修整。因此，只要对二者进行修整，再结合起来，部署并发布服务即可。
XML
XML概述
1.XML是Extended Markup Language的缩写，即可扩展标记语言。它是一种广泛应用于互联网分布式计算中的、简单的、跨平台的结构化数据或数据结构标记语言。同时，XML是一种元语言，即用户可以根据实际需求设计自定义的标记来描述数据，XML中使用文档类型定义（DTD）或者模式（Schema）来描述数据。
2.XML具有其跨平台、与软硬件无关的优点，以XML为基石不断催生着各种新技术的到来，如SOAP、WSDL和XSL等，它们为Web技术的发展提供了不竭动力。XML具有以下特点：
----可扩展性
----自描述性
----简洁性
----数据的描述与显示相分离
----易于数据的交换和共享
----易于充分利用数据
----可用于创造新的语言
XML语法和文档
1.所有的数据都是在文档中进行描述的。而XML文档具有不同的类型，XML的组成部分和结构形式地定义了文档的类型。
2.XML文档由命名容器和命名容器的相关参数值组成，这些命名容器包括声明、元素和属性。其中声明确定了当前XML文档所使用的XML标准规范的版本；元素就是XML文档中的一对标记及标记之间的内容，它是文档最基本的组成单元，XML正是通过这些命名的标签对来描述结构化数据的；
3.属性用于对元素的特性进行描述，以便XML文档处理器能按照特定的属性来处理文档。
命名空间
1.用于指定变量、函数、数据对象等标示符所处的有效范围。通过命名空间可以避免名称冲突，使系统更加模块化。例如，在C++语言中，使用关键字namespace来声明命名空间，并使用“{ }”来界定命名空间的作用域。
2.例如，声明命名空间MyNamespace，并在其中定义两个int型变量。
3.XML命名空间的声明方法为：xmlns:prefix-name=”URI”。其中，xmlns是XML中专门用于声明命名空间的关键字。prefix-name是命名空间的名称，一般以字母或下划线（_）开头，不包含空白字符和冒号（:），且不能使用XML保留字（如：xml、xsl等）做命名空间名称。
4.命名空间的值是一个URI（Uniform Resource Identifier，统一资源标示符）。因为，在Web中汇集了各种各样的资源，为了唯一地标识这些资源，W3C提出了URI的概念。一个URI中包含了能够唯一标识一个资源的字符串，通过URI可以方便地实现对资源的表示、描述、访问和共享。
5.任何命名空间只能够在其作用域内进行使用，且同一个命名空间中所有元素名和属性名必须是唯一的。如图清单为含有命名空间的XML文档。
6.以上清单描述了一家名为GZSoftware的软件公司的基本信息，其中元素company、company-info、name、fdate都是定义在命名空间ns中的，ns的URI为http://www.myns.com，因此这些元素的名称前缀都是ns（如ns:company）。而元素division、name（为division的name）、employee是定义在命名空间nsd中的，nsd的URI为http://www.myns.com/division，其元素名前缀都是nsd。可见，这样避免了name重名冲突问题，因为它们在不同的命名空间。
8.在XML中，命名空间可以划分为三类，即目标命名空间、标准命名空间和源命名空间。如下清单是一个XML Schema文档，展示了这三种命名空间的用法。
7.目标命名空间（targetNamespace）为“http://www.OnlineShop.com/info”，文档中定义的元素名称（Schema、import、element）、类型名称（string、float）、属性名称（name、type）和属性组名称的作用范围就是此目标命名空间。
8.标准命名空间（XMLns），即文档中的“http://www.w3.org/2000/08/XMLSchema”，其中定义了XML Schema语法标准中规定的一些名字（Schema、import、element等）。注意，“XMLns:INFO”是对命名空间的一种简化处理，这样“XMLns:INFO”就代表了命名空间“http://www.OnlineShop.com/info”。
9.源命名空间表示使用外部名称所在的命名空间，如上述清单中“import namespace”导入的外部命名空间“http://www.Address.org/produceAera”，并用“XML:proAera”简化。
XML Schema
1.XML Shema，即XML模式。在XML中模式用来描述文档类型，即把特定的XML文档当做一种规范来描述，XML Schema定义了一类XML文档。
2.XML是Web Services的基石，以SOAP为例，SOAP消息就是以XML文档形式存在的，而消息中包含有待交互的数据，通过网络传输即可与服务进行交互。但服务接收者会接收到各种各样的SOAP消息，要识别出哪些SOAP消息格式是满足要求的，必须通过一定的机制，那就是XML Schema。通过XML Schema可以检测一个SOAP消息是否满足预定义模式要求，再决定是否接受消息。
----清单8.7为一个描述智能手机基本信息的XML文档，而清单8.8为此文档的Schema。
SOAP Web Services
SOAP概述
1.SOAP(Simple Object Access Protocol，简单对象访问协议）是一种基于XML的、轻量级的、跨平台的数据交换协议。SOAP不仅描述了数据类型的消息格式及一整套串行化规则，包括结构化类型和数组，还描述了如何使用HTTP来传输消息。SOAP提供了应用程序之间的交互能力。
2.SOAP主要包括以下四个部分：
----SOAP Envelope——用于定义一个描述消息中的内容、发送者、接收者、处理者及如何处理的整体表示框架。
----SOAP编码规则——定义了一套编码机制用于交换应用程序定义的数据类型的实例。
----SOAP RPC——表示远程过程调用和应答的协定。
----SOAP绑定 ——定义了一种使用底层传输协议来完成节点间交换SOAP消息的约定。
SOAP消息结构
SOAP是基于XML的消息式数据交换协议，为了准确地实现应用与服务间数据的互操作，SOAP消息的提供者与请求者都必须访问相同的XML模式。
SOAP Envelope
1.SOAP Envelope，即SOAP信封，是每一个SOAP消息唯一的根，是必须要有的。SOAP信封中所有的元素都是使用W3C XML Schema规范进行定义的。命名空间是XML Schema中关键的技术，它不仅避免了元素重名的困扰，还使得模式文档更具可扩展性。因此，通过引用不同的命名空间，SOAP消息可以扩展其语义范围。
2.在SOAP中同样适用xmlns来声明命名空间，例如上面清单上中命名空间soap的值为http://www.w3.org/2003/05/soap-envelope。在此命名空间中，不仅定义了元素，还定义了
3.SOAP规范允许在信封标签中定义任意数量的附加的、自定义的属性，但每一个自定义的属性都必须有合适的命名空间。
SOAP Header
1.Header元素是SOAP Envelope中的第一个直接子元素，Header并不是Envelope中必须要含有的，且一个SOAP Envelope中只能有一个Header元素。
2.Header提供了一种对扩展功能进行封装的机制，且扩展功能无须与有效载荷发生关联，也不需要修改SOAP基本结构，因此可以在不违反规范的前提下不断为SOAP消息添加新的特性或功能，例如安全性、对象引用、计费、数字签名、QoS等。
3.Header中的所有直接子元素都称为Header条目，每个Header条目都由一个命名空间和局部名组成的完整修饰元素来标识，不允许出现没有命名空间修饰的Header条目。
SOAP Body
1.Body元素是Envelope中必须要有的，它提供了一种SOAP消息与中消息接收者交换信息的机制，例如RPC调用和错误报告。Body应该作为Envelpoe元素的一个直接子元素，若Envelope中包含Header元素，则Body元素必须紧跟在Header后，作为Header元素的直接的下一个兄弟。
2.在Body元素中所有的直接子元素都称为Body条目，每一个条目必须是一个独立的元素，且每一个完整的条目由一个命名空间URI和名称组成。Body条目自身可以包含下级子元素，但这些元素也不是Body的条目，而是Body条目的内容。此外，在Body中可以使用Fault元素来指示调用错误的信息。
SOAP Fault
SOAP Fault元素用于在SOAP消息中传输错误及状态信息。Fault元并不是必须的，若出现了Fault，则它必须位于Body元素中，作为Body的一个条目，且在Body元素中至多出现一次。如下表格给出了SOAP Fault的子元素。
Fault子元素faultcode的值有下面四种：
SOAP消息交换模型
1.SOAP消息交换是从发送方到接收方的一种传输方法。从本质上说，SOAP是一种无状态的协议，它提供符合的单向消息交换框架，以便在称为SOAP节点的SOAP应用程序之间传输XML文档。
2.SOAP节点既可以是SOAP消息的发送者，也可以是SOAP消息的接收者，或者是SOAP消息的发送者和接收者放入中介。由于SOAP并不提供路由机制，因此SOAP需要识别发送者发送的SOAP消息应当通过哪些SOAP中介才能到达接收者处。此外，接收到SOAP消息的节点必须能够实时处理被产生必要的SOAP错误和SOAP响应，如果合适，还应当根据SOAP规范的后续描述生成额外的SOAP消息。
3.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分为五类：
1.请求/响应模式
请求/响应方式的SOAP服务，即服务请求者将请求发送给服务接收者，服务接收者接收到发送者的请求后，再获取并处理其中的数据，最后将处理结果信息以SOAP消息方式回送给服务请求者。如果请求消息没有被接收到，或没有被期望的业务应用所处理，那么保障通信的传输层会产生相应的状态信息，并报告给SOAP发送者。
2.fire-and-forget模式
1.fire-and-forget一词源于军事中，比喻当某种武器当被发射出后，便不用人们再去控制，而可以自行寻找攻击目标。把它用在SOAP中时，表示SOAP消息一经发出，便不用发送者关心，SOAP消息自己会寻找相应的接收者。
2.按照SOAP消息接收者的多少，可以将fire-and-forget分为两类，一种是面向单个接收者的，另一种是面向多个接收者的。面向单个接收者指发送者要求该SOAP消息只被一个接收者接受，且不要求予以回复发送报告，比如是否发送完成、是否已被接收等报告。面向多个接收者指的是发送者要求该SOAP消息被发送给一组接收者，也不要求回复发送报告。
3.高级消息模式
1.会话消息模式——基于会话的消息模式，双方会长时间维持一个会话进程，其中包含了双方多次的消息交互。
2.异步消息模式——此种模式下，发送者发送SOAP消息后，并不期望接收者接收并处理后立即予以响应，而允许接收者在一定的时间段内给予回复。异步方式更加适合于实际应用。
3.事件通知模式——此种模式类似于“订阅”。应用程序向一个事件源订阅了一些特定的事件通知，当事件发生时，事件源便按照订阅者的要求将通知发送给原订阅者，或其他指定的用户。
4.增量解析和处理模式
1.当SOAP消息过于庞大，给传输带来困难时，往往想到的是分组来发送，类似于计算机网络中IP数据报的分组。
2.按照一定机制将冗长的SOAP消息分割后，由多个SOAP消息来发送，待接收者收到这些分片的消息后，再对分片进行重组和处理。
3.这种模式缩短了消息传输延时，降低了通信阻塞，使SOAP服务效率得以提高。但此模式要求发送者和接收者都具备增量解析和处理消息的能力。
5.缓存模式
在SOAP消息中，为了缩短响应时延、占用更小的带宽，可以将一些常用的消息存储在缓存中，供相关应用或SOAP节点使用。
WSDL
1.WSDL（Web Services Description Language，Web服务描述语言）是一种基于XML的、专门用于描述Web Services的语言。通过WSDL可以对服务的功能信息、功能参数的消息类型、协议绑定信息和特定服务的地址信息进行描述。
2.WSDL文档将服务访问点、消息的抽象定义与具体服务部署、数据格式的绑定分离开来，因此可以对抽象定义进行重用。在WSDL中，消息指对数据的抽象描述，端口类型指的是操作的抽象几何，端口类型使用的具体协议和数据格式规范构成了一个绑定，将Web访问地址与可再次使用的绑定相关联来以定义一个端口，而端口的集合则称为服务。
在WSDL文档中常常用到以下8种元素来描述SOAP Web Services：
1.definitions——该元素用于定义WSDL文档的名称，引入必要的命名空间。
2.types——数据类型定义容器，提供了用于描述交换信息的数据类型定义，它使用某种类型系统（如XML Schema中的类型，即XSD）。
3.message——消息结构的抽象类型化定义，消息包括多个逻辑部分，每一部分与某种类型系统中的一个定义相关。消息使用types所定义的类型来定义整个消息的数据结构。
4.operation——描述了一个访问入口的请求/响应消息对，是对服务中所支持的操作的抽象描述。
WSDL的文档结构模型：
----在实际的应用中很少直接去硬编码WSDL，而是采用一些软件工具自动化生成WSDL文档，几种自动化生成WSDL文档的工具：
(1)IBM WSTK——即IBM Web Services工具包，它包含ApacheSOAP、WSSDL生成器和通用描述、发现和集成客户顿等，可以方便地实现WSDL的自动生成
(2)IBM WSDL工具包——用来从WSDL生成客户端和服务器存根。，该工具的代码被封装为wasl.jar，并使用了WSTK的bsf.jar（Bean框架脚本）和xalan.jar（XML样式单处理器）文件。
(3)Genuitec MyEclipse—— 用于开发J2EE产品的IDE，使用它可以方便地创建Web Services，其中也集成了WSDL文档自动化生成的功能，十分方便开发者的使用。
(4)Microsoft Visual Studio—— 与MyEclipse类似，Visual Studio也是一个可以用于开发Web Services的强大IDE，一般我们使用C#语言在此工具上开发Web服务，当然它也集成了WSDL文档自动化生成的功能。
UDDI
1.UDDI（Universal Description、Discovery and Integeration，统一描述、发现和集成）
----一套基于Web的分布式的Web Services信息注册中心的实现标准规范，也包含一组访问协议的实现标准，使得企业能将自身的Web Services注册上去，并让其他企业能够发现并使用这些服务，使服务更容易被获取。
2.UDDI中所提供的信息可以分为以下三类：
----白页——表示企业的基本信息，如企业的名称、地址、联系方式、经营范围、企业标识、税号等。
----黄页——用来依据标准分类法区分不同的行业类别，使企业能够在更大的范围（如地域范围）内查找已经在注册中心注册的企业或Web服务。
----绿页——包括了关于该企业所提供的Web服务的技术信息，其形式可能是一些指向文件或是URL的指针，而3.这些文件或URL是服务发现机制的必要组成部分。
3.在UDDI消息传输机中，首先客户端发出SOAP请求，并通过HTTP传输到注册中心节点中，注册中心的SOAP服务器在接收到UDDI SOAP消息后，在注册数据中找到相应的SOAP服务，并处理请求，同时把处理结果返回给客户端。如图展示了UDDI消息在客户和注册中心间的传输示意图。
UDDI工作原理
4.UDDI的数据类型包括以下五种元素：
5.WSDL和UDDI都可以用来描述接口和实现，因此它们二者之间是可以相互补充、相互协作的。UDDI提供了一个发布和发现WSDL的方法，而WSDL中定义的服务信息是对UDDI业务和服务条目信息的补充。
6.WSDL接口（含types、message、oportType和binding）部分将映射到UDDI的技术模型tModel部分。WSDL服务实现中的service元素部分将映射到UDDI的businessEntity部分。而WSDL中port元素部分将映射到UDDI的bindingTemplate元素。
来源：CSDN
作者：?? Martian? ? ?
链接：https://blog.csdn.net/weixin_45929685/article/details/103396692