《web services-100ppt》由会员分享，可在线阅读，更多相关《web services-100ppt（103页珍藏版）》请在金锄头文库上搜索。
1、Web Service,TOC,Web Service的概念 SOAP WSDL REST vs XML-RPC vs SOAP vs DATA BINDING WS-security WS-Notification WS-Transaction 开发一个WebService XFire 1.x Axis 1.x/2.x 开发一个Web Service实例 WebService相关技术 AJAX JMS BPEL Grid SOA,需要知道的知识,XML HTTP/HTTPS SCHEMA/DTD,Web Service的概念,Web Service,Web服务(Web Service)提供了
2、一个在不同的应用和平台之间的交互操作标准。 这个交互操作通过一系列基于XML的开放标准实现，包括WSDL、SOAP和UDDI等。这些标准提供了一系列通用方法来定义、发布和使用Web Service。,Web Service的基本层次结构,基础连接: Internet,统一数据格式: XML,服务操作协议: SOAP,服务描述协议: WSDL,Simple, Open, Broad Industry Support 简单、开放、工业界广泛支持,服务发布协议: UDDI,UDDI : Universal Description Discovery and Integration WSDL: Web
3、 Service Description Language SOAP : Simple Object Access Protocol,为什么需要WebService,Data Services,Business Logic Services,Presentation Services,Data Services,Web Services,Presentation & Process Services,browser,browser,之前,之后,Client AP,Mobile Device,Legacy,SOAP & WSDL,SOAP是什么？,SOAP 是一种轻量级协议，用于在分散型、分布式
4、环境中交换结构化信息。 SOAP 利用 XML 技术定义一种可扩展的消息处理框架，它提供了一种可通过多种底层协议进行交换的消息结构。 这种框架的设计思想是要独立于任何一种特定的编程模型和其他特定实现的语义。 SOAP的概念最初来自于 Microsoft and Userland software，它已经演化了好几代; 当前最新的规范是SOAP 2.0。由W3C组织制定。,SOAP,SOAP被广泛地认为是新一代跨平台和跨语言的分布式计算机应用的基础框架。 SOAP 1.1只支持HTTP POST方式向终端提交请求。 SOAP 1.2支持HTTP POST和GET两种方式。,四个主要组成部分,SO
5、AP是一个基于XML的轻量级规范，其主要使用在分布式系统中，由下面几个部分组成: SOAP封装结构定义了一个整体框架用来表示消息中包含什么内容，谁来处理这些内容以及这些内容是可选的或是必需的。 SOAP编码规则定义了用以交换应用程序定义的数据类型的实例的一系列机制。 SOAP RPC表示定义了一个用来表示远程过程调用和应答的协定。 虽然这三个部分都作为SOAP的一部分一起描述，但它们在功能上是相交的。特别的，封装和编码规则是在不同的名域中定义的。规范定义了SOAP封装、SOAP编码规则和SOAP-RPC协定之外，这个规范还定义了SOAP和其他协议的绑定，描述了在有或没有HTTP扩展框架的情况下
6、，SOAP消息如何包含在消息中被传送。,SOAP消息结构,SOAP消息处理框架,SOAP 规范的核心部分就是消息处理框架。 SOAP 消息处理框架定义了一整套 XML 元素，用以“封装”任意 XML 消息以便在系统之间传输。 该框架包括以下核心 XML 元素： Envelope、Header、Body 和 Fault，所有这些都来自 SOAP 1.1 中的 http:/schemas.xmlsoap.org/soap/envelope/ 命名空间。 以下代码中提供了 SOAP 1.1 的完整 XML 架构定义，以供在阅读下文时参考。 SOAP 1.1 XML 架构定义: SOAP.xml,SO
7、AP Envelope 的结构,SOAP Envelope 的结构,所有的SOAP消息都使用XML形式编码,一个SOAP应用程序产生的消息中，所有由SOAP定义的元素和属性中必须包括正确的域名。SOAP应用程序必须能够处理它接收到的消息中的SOAP域名，并且它可以处理没有SOAP域名的SOAP消息，就象它们有正确的名域一样。SOAP定义了两个名域: SOAP封装的名域标志符是“http:/schemas.xmlsoap.org/soap/envelope/“ SOAP的编码规则的名域标志符是“http:/schemas.xmlsoap.org/soap/encoding/“,SOAP enco
8、dingStyle属性,EncodingStyle全局属性用来表示SOAP消息的序列化规则。这个属性可以在任何元素中出现，作用范围与域名声明的作用范围很相似，为这个元素的内容和它的所有没有重载此属性的子元素。SOAP消息没有定义缺省编码。属性值是一个或多个URI的顺序列表，每个URI确定了一种或多种序列化规则，用来不同程度反序列化SOAP消息，举例如下： “http:/schemas.xmlsoap.org/soap/encoding/“ “http:/my.host/encoding/restricted http:/my.host/encoding/“ “,封装版本模型,SOAP没有定义常
9、规的基于主版本号和辅版本号的版本形式。SOAP消息必须有一个封装元 素与名域“http:/schemas.xmlsoap.org/soap/envelope/“关联。如果SOAP应用程序接收到的SOAP消息中的SOAP封装元素与其他的名域关联，则视为版本错误，应用程序必须丢弃这个消息。如果消息是通过HTTP之类的请求/应答协议收到的，应用程序必须回答一个SOAP VersionMismatch 错误信息。,Envelope元素,Envelope元素始终是 SOAP 消息的根元素。 这就便于应用程序识别“SOAP 消息” 只要检查一下根元素的名称即可。 通过检查 Envelope 元素的命名空间
10、，应用程序也可确定所使用的 SOAP 版本。 Envelope元素包含一个可选的 Header 元素,后跟一个必要的 Body 元素。 Body 元素代表了该消息的有效内容。 它是一种通用容器，因为它可包含来自任何命名空间的任意数量的元素。 这就是试图发送数据的最终目的地。,例子:,在银行帐户之间转帐的请求信息: request.xml 相应的响应信息: response.xml,Fault元素,该消息处理框架还定义了一个名为Fault 的元素，用于在发生错误时在 Body 元素中表示错误。 这是不可缺少的，因为如果没有一种标准的错误表示方法，每个应用程序将不得不自己创建，从而使得通用基础结构
11、不可能区分成功和失败。 以下示例 SOAP 消息中包含了一个 Fault 元素，指明在处理该请求时发生了“Insufficient Funds（资金不足）”错误：fault.xml,Fault元素,Fault 元素必须包含一个 faultcode，后跟一个 faultstring 元素。 faultcode 元素使用一种符合命名空间的名称对错误进行分类，而 faultstring 元素提供一种对错误可读的解释（类似于 HTTP 的工作方式）。 表 2 简要地说明了 SOAP 1.1 所定义的各种错误码（所有这些代码都包含在 http:/schemas.xmlsoap.org/soap/enve
12、lope/ 命名空间中）。 Fault 元素也可能包含一个 detail 元素，以便提供该错误的细节，这样可以帮助客户端诊断问题，特别是在 Client 和 Server 错误码的情况下。,SOAP 1.1 错误码,VersionMismatch 处理方发现 SOAP Envelope 元素的命名空间是无效的 MustUnderstand 处理方没有理解或服从 SOAP Header 元素的某个直接子元素，而该子元素包含一个值为 “1” 的 SOAP mustUnderstand 属性。 Client 表明消息的格式错误或者不包含适当的信息，因而不能成功。 这通常表明，如果不对该消息做出更改，
13、就不应该重发该消息。 Server 表明该消息未能得到处理的原因与消息的内容并没有直接关系，而是跟该消息的处理有关。 例如，处理过程可能包括与某个上游处理器的通信，但该处理器没有响应。 如果在稍后重发，该消息可能会成功。,Soap Header,大多数现有的协议都区分控制信息（例如，标头）和消息有效负载。 在这方面，SOAP 也不例外。 SOAP Header 和 Body 元素在易于处理的 XML 世界中也进行同样的区分。 除了易用性之外，可扩展 Envelope 的关键优势在于它可用于任何通讯协议。 在各种应用程序协议中（如 HTTP、SMTP 等）标头总是具有重要的意义，因为标头允许连网
14、两端的应用程序就所支持命令的具体行为进行协商。 尽管 SOAP 规范本身并不定义任何内置的标头，标头将逐渐在 SOAP 中扮演同等重要的角色。 与 Body 元素类似，Header 元素是控制信息的通用容器。 其中可包含来自任何命名空间（除 SOAP 命名空间之外）的任意数量的元素。 放置在 Header 元素中的各个元素被称为标头块。 如同其他协议一样，标头块中包含的信息应该能够影响有效负载的处理。 因此，这里正适于放置诸如凭证一类的元素，以帮助控制对操作的访问：header.xml 2: 我们也可以利用一个名为 mustUnderstand 的全局 SOAP 属性对标头块进行标注，以指明接
15、收方在处理该消息之前是否需要理解标头: mustunderstand.xml.,Soap Body,SOAP体元素（Body）提供了一个简单的机制，使消息的最终接收者能交换必要的信息。使用体元素的典型情况包括配置RPC请求和错误报告。体元素编码为SOAP封装元素的直接子元素。 如果已经有一个头元素，那么体元素必须紧跟在头元素之后，否则它必须是SOAP封装元素的第一个直接子元素。体元素的所有直接子元素称作体条目，每个体条目在SOAP体元素中编码为一个独立的元素。条目的编码规则如下： 一个条目由它的元素全名（包括名域URI和局部名）确定。SOAP体元素的直接子元素可能是名域限制的。,协议绑定,SO
16、AP可以和很多传输协议进行绑定: SOAP over HTTP/HTTPS GET/POST SOAP over JMS SOAP over SMTP SOAP over RPC 一种具体的协议绑定准确地定义了应该如何利用给定的协议来传输SOAP 消息。 换言之，它详细定义了 SOAP 如何适用于另一协议的范围，该协议很可能具有自己的消息处理框架以及多种标头。 协议绑定实际所定义的内容很大程度上取决于该协议的功能和选项。 例如，针对 HTTP 的协议绑定应很大程度不同于针对 JMS 或针对 SMTP 的协议绑定。,SOAP 类型,如今有两种基本类型的SOAP消息处理： 文档和RPC。文档类型指出主体只是包含一个 XML 文档，而发送方和接收方都必须遵循该文档的格式。 另一方面，RPC 类型指出主体中包含某个方法调用的 XML 表示，正如刚才所述。 两种方法可用于确定如何将数据序列化到主体中： 使用Literal文字的 XML 架构定义和使用 SOAP 编码规则Encoding。 利用前一种方法，架构定义逐字确定了主体的
