- 1. Web Service技术交流2010.4.20
- 2. Web ServiceWeb服务(Web Service)提供了一个在不同的应用和平台之间的交互操作标准。 这个交互操作通过一系列基于XML的开放标准实现，包括WSDL、SOAP和UDDI等。这些标准提供了一系列通用方法来定义、发布和使用Web Service。
- 3. Web Service的基本层次结构基础连接: Internet统一数据格式: XML服务操作协议: SOAP服务描述协议: WSDLSimple, Open, Broad Industry Support 简单、开放、工业界广泛支持服务发布协议: UDDIUDDI : Universal Description Discovery and Integration WSDL: Web Service Description Language SOAP : Simple Object Access Protocol
- 4. 为什么需要WebService DBMSDBMSNameNo.ZipStateOKCancelData ServicesBusiness Logic ServicesPresentation ServicesDBMSDBMSData ServicesWeb ServicesPresentation & Process ServicesNameNo.ZipStateOKCancelbrowserbrowser之前之后Client APNameNo.ZipStateOKCancelMobile DeviceLegacy
- 5. SOAP & WSDL
- 6. SOAP是什么？SOAP 是一种轻量级协议，用于在分散型、分布式环境中交换结构化信息。 SOAP 利用 XML 技术定义一种可扩展的消息处理框架，它提供了一种可通过多种底层协议进行交换的消息结构。 这种框架的设计思想是要独立于任何一种特定的编程模型和其他特定实现的语义。 SOAP的概念最初来自于 Microsoft and Userland software，它已经演化了好几代; 当前最新的规范是SOAP 2.0。由W3C组织制定。
- 7. SOAPSOAP被广泛地认为是新一代跨平台和跨语言的分布式计算机应用的基础框架。 SOAP 1.1只支持HTTP POST方式向终端提交请求。 SOAP 1.2支持HTTP POST和GET两种方式。
- 8. 四个主要组成部分SOAP是一个基于XML的轻量级规范，由下面几个部分组成: SOAP封装结构定义了一个整体框架用来表示消息中包含什么内容，谁来处理这些内容以及这些内容是可选的或是必需的。 SOAP编码规则定义了用以交换应用程序定义的数据类型的实例的一系列机制。 SOAP RPC表示定义了一个用来表示远程过程调用和应答的协定。 虽然这三个部分都作为SOAP的一部分一起描述，但它们在功能上是相交的。特别的，封装和编码规则是在不同的名域中定义的。规范定义了SOAP封装、SOAP编码规则和SOAP-RPC协定之外，这个规范还定义了SOAP和其他协议的绑定，描述了在有或没有HTTP扩展框架的情况下，SOAP消息如何包含在消息中被传送。
- 9. SOAP消息结构
- 10. SOAP消息处理框架SOAP 规范的核心部分就是消息处理框架。 SOAP 消息处理框架定义了一整套 XML 元素，用以“封装”任意 XML 消息以便在系统之间传输。 该框架包括以下核心 XML 元素： Envelope、Header、Body 和 Fault，所有这些都来自 SOAP 1.1 中的 http://schemas.xmlsoap.org/soap/envelope/ 命名空间。
- 11. SOAP Envelope 的结构
- 12. 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/
- 13. SOAP encodingStyle属性EncodingStyle全局属性用来表示SOAP消息的序列化规则。这个属性可以在任何元素中出现，作用范围与域名声明的作用范围很相似，为这个元素的内容和它的所有没有重载此属性的子元素。SOAP消息没有定义缺省编码。属性值是一个或多个URI的顺序列表，每个URI确定了一种或多种序列化规则，用来不同程度反序列化SOAP消息，举例如下： http://schemas.xmlsoap.org/soap/encoding/ http://my.host/encoding/restricted http://my.host/encoding/
- 14. 封装版本模型 SOAP没有定义常规的基于主版本号和辅版本号的版本形式。SOAP消息必须有一个封装元 素与名域http://schemas.xmlsoap.org/soap/envelope/关联。如果SOAP应用程序接收到的SOAP消息中的SOAP封装元素与其他的名域关联，则视为版本错误，应用程序必须丢弃这个消息。如果消息是通过HTTP之类的请求/应答协议收到的，应用程序必须回答一个SOAP VersionMismatch 错误信息。
- 15. Envelope元素Envelope元素始终是 SOAP 消息的根元素。 这就便于应用程序识别“SOAP 消息” — 只要检查一下根元素的名称即可。 通过检查 Envelope 元素的命名空间，应用程序也可确定所使用的 SOAP 版本。 Envelope元素包含一个可选的 Header 元素,后跟一个必要的 Body 元素。 Body 元素代表了该消息的有效内容。 它是一种通用容器，因为它可包含来自任何命名空间的任意数量的元素。 这就是试图发送数据的最终目的地。
- 16. Fault元素该消息处理框架还定义了一个名为Fault 的元素，用于在发生错误时在 Body 元素中表示错误。 这是不可缺少的，因为如果没有一种标准的错误表示方法，每个应用程序将不得不自己创建，从而使得通用基础结构不可能区分成功和失败。 以下示例 SOAP 消息中包含了一个 Fault 元素，指明在处理该请求时发生了“Insufficient Funds（资金不足）”错误：fault.xml
- 17. Fault元素Fault 元素必须包含一个 faultcode，后跟一个 faultstring 元素。 faultcode 元素使用一种符合命名空间的名称对错误进行分类，而 faultstring 元素提供一种对错误可读的解释（类似于 HTTP 的工作方式）。 表 2 简要地说明了 SOAP 1.1 所定义的各种错误码（所有这些代码都包含在 http://schemas.xmlsoap.org/soap/envelope/ 命名空间中）。 Fault 元素也可能包含一个 detail 元素，以便提供该错误的细节，这样可以帮助客户端诊断问题，特别是在 Client 和 Server 错误码的情况下。
- 18. SOAP 1.1 错误码VersionMismatch 处理方发现 SOAP Envelope 元素的命名空间是无效的 MustUnderstand 处理方没有理解或服从 SOAP Header 元素的某个直接子元素，而该子元素包含一个值为 “1” 的 SOAP mustUnderstand 属性。 Client 表明消息的格式错误或者不包含适当的信息，因而不能成功。 这通常表明，如果不对该消息做出更改，就不应该重发该消息。 Server 表明该消息未能得到处理的原因与消息的内容并没有直接关系，而是跟该消息的处理有关。 例如，处理过程可能包括与某个上游处理器的通信，但该处理器没有响应。 如果在稍后重发，该消息可能会成功。
- 19. Soap Header大多数现有的协议都区分控制信息（例如，标头）和消息有效负载。 在这方面，SOAP 也不例外。 SOAP Header 和 Body 元素在易于处理的 XML 世界中也进行同样的区分。 除了易用性之外，可扩展 Envelope 的关键优势在于它可用于任何通讯协议。 在各种应用程序协议中（如 HTTP、SMTP 等）标头总是具有重要的意义，因为标头允许连网两端的应用程序就所支持命令的具体行为进行协商。 尽管 SOAP 规范本身并不定义任何内置的标头，标头将逐渐在 SOAP 中扮演同等重要的角色。 与 Body 元素类似，Header 元素是控制信息的通用容器。 其中可包含来自任何命名空间（除 SOAP 命名空间之外）的任意数量的元素。 放置在 Header 元素中的各个元素被称为标头块。 如同其他协议一样，标头块中包含的信息应该能够影响有效负载的处理。 因此，这里正适于放置诸如凭证一类的元素，以帮助控制对操作的访问：header.xml 2: 我们也可以利用一个名为 mustUnderstand 的全局 SOAP 属性对标头块进行标注，以指明接收方在处理该消息之前是否需要理解标头: mustunderstand.xml.
- 20. Soap BodySOAP体元素（Body）提供了一个简单的机制，使消息的最终接收者能交换必要的信息。使用体元素的典型情况包括配置RPC请求和错误报告。体元素编码为SOAP封装元素的直接子元素。 如果已经有一个头元素，那么体元素必须紧跟在头元素之后，否则它必须是SOAP封装元素的第一个直接子元素。体元素的所有直接子元素称作体条目，每个体条目在SOAP体元素中编码为一个独立的元素。条目的编码规则如下： 一个条目由它的元素全名（包括名域URI和局部名）确定。SOAP体元素的直接子元素可能是名域限制的。
- 21. 协议绑定SOAP可以和很多传输协议进行绑定: SOAP over HTTP/HTTPS GET/POST SOAP over JMS SOAP over SMTP SOAP over RPC 一种具体的协议绑定准确地定义了应该如何利用给定的协议来传输SOAP 消息。 换言之，它详细定义了 SOAP 如何适用于另一协议的范围，该协议很可能具有自己的消息处理框架以及多种标头。 协议绑定实际所定义的内容很大程度上取决于该协议的功能和选项。 例如，针对 HTTP 的协议绑定应很大程度不同于针对 JMS 或针对 SMTP 的协议绑定。
- 22. SOAP 类型如今有两种基本类型的SOAP消息处理： 文档和RPC。文档类型指出主体只是包含一个 XML 文档，而发送方和接收方都必须遵循该文档的格式。 另一方面，RPC 类型指出主体中包含某个方法调用的 XML 表示，正如刚才所述。 两种方法可用于确定如何将数据序列化到主体中： 使用Literal文字的 XML 架构定义和使用 SOAP 编码规则Encoding。 利用前一种方法，架构定义逐字确定了主体的 XML 格式，不具有二义性。 然而，利用后一种方法，SOAP 处理器必须在运行时遍历各种 SOAP 编码规则以确定主体正确的序列化。 很显然，这种方法更易于导致错误和互操作性方面的问题。 最常见的情形是在使用文档类型时也使用文字架构定义（称为文档/文字），以及在使用 SOAP 编码规则时使用 RPC 类型（称为 rpc/编码）。 文档/编码和 rpc/文字也是可能的，但并不常见，也没有太大意义。 大多数 Web 服务平台都集中于文档/文字类型，将其作为发展的主要用例，且是现今 Microsoft ASP.NET WebMethod 框架的默认设置。
- 23. HTTP 绑定 HTTP 协议绑定定义了在 HTTP 上使用 SOAP 的规则。 SOAP 请求/响应自然地映射到 HTTP 请求/协议模型。
- 24. SOAP RPC绑定 尽管 SOAP 规范已日渐远离对象，它仍然定义了一种约定，以便利用上述的消息处理框架来封装并交换 RPC 调用。 定义一种标准的方法将 RPC 调用映射到 SOAP 消息，这使得在运行时基础结构可以在方法调用和 SOAP 消息之间自动转换，而不用围绕 Web 服务平台重新设计代码。 要利用 SOAP 进行方法调用，基础结构需要以下信息： 终结点位置 (URI) 方法名称 参数名称/值 可选的方法签名 可选的标头数据
- 25. SOAP RPC绑定RPC调用：double add(ref double x, double y)
Request对象：
struct add {
double x;
double y;
}
33 44 77 - 26. SOAP RPCSOAP文档内容
5 - 27. 服务调用前置机SOAP消息HTTPHTTPWSDL2JAVASOAP消息Class OperationXML Message服务描述CONTEXTXML2JAVAXML Message
- 28. 实现SOAP的容器XFIRE 1.x Apache AXIS 1.x/2.x Apache CXF ……
- 29. WSDL描述web服务的三个基本属性：服务做些什么? 服务所提供的操作(方法)； 如何访问服务？ 数据格式以及访问服务操作的必要协议； 服务位于何处？ 由特定协议决定的网络地址，如URL。
- 30. WSDL是什么？服务主要通过六个元素进行定义 types,定义了交换信息的数据格式。 message, 传输消息的抽象定义。一个消息含有多个逻辑部分，每一部分和一些类型相关联。 portType, 一些抽象操作的集合。每个操作关联一个输入消息和一个输出消息。 binding, 针对操作和portType中使用的消息指定实际的协议和数据格式规范。 port, 指定一个绑定的地址，这样定义一个通信的终端。 service, 一些port构成的集合
- 31. WSDL定义WSDL是XML描述的网络服务，基于消息机制、包含面向文本或面向过程信息的操作集合。 操作及消息的抽象定义与它们具体的网络实现和数据格式绑定是分离的,这样就可以重用这些抽象定义。 消息是需要交换数据的抽象描述； 端点类型是操作的抽象集合。 针对一个特定端点类型的具体协议和数据格式规范构成一个可重用的绑定。 一个端点定义成网络地址和可重用的绑定的联接，端点的集合定义为服务。
- 32. 服务接口定义和服务实现定义服务接口组成了服务描述中的可重用部分， type元素、message和portType。 types元素中描述消息中复杂数据类型的使用。 message元素指定XML 数据类型组成消息的各个部分。message元素用于定义操作的输入和输出参数。 portType元素中定义了Web服务的操作。操作定义了输入和输出数据流中可以出现的XML消息。
- 33. 服务接口定义和服务实现定义服务实现定义是一个描述给定服务提供者如何实现特定服务接口的WSDL文档。 有binding和services。 binding 元素描述特定服务接口的协议、数据格式、安全性和其它属性。 service元素。服务元素包含一组port元素。端口将端点与来自服务接口定义的binding 元素关联起来。
- 34. WSDL是一种XML应用,它将Web Services描述定义为一组服务访问端点，客户端可以通过这些服务访问端点对包含面向文档信息或面向过程调用的服务进行访问。 WSDL首先对访问的操作和访问时使用的请求／响应消息进行抽象描述，然后将其绑定到具体的传输协议和消息格式上，以最终定义具体部署的服务访问端点。 在具体使用中，可以使用任意的消息格式和网络协议。 在WSDL规范中，定义了如何使用SOAP消息格式、HTTP GET／POST消息格式以及MIME格式来完成Web Services交互的规范。
- 35. WSDL文档框架
* - 36. types元素
- 37. message元素
* - 38. portType元素--抽象操作的集合
- 39. binding元素
- 40. service元素
- 41. 类型 types元素包含了交换消息的数据类型定义。为了实现最大的互操作性（interoperability）和平台中立性（neutrality），WSDL选用XML Schema DataTypes，简称XSD作为标准类型系统，并将它作为固有类型系统。
- 42. 类型—XSD编码抽象数据类型建议使用元素（element）形式，而不使用属性(attribute)形式； 不包括仅在特殊的协议和数据格式中使用的元素或者属性； 数组类型使用Soap:Array 类型，并使用ArrayOfXXX作为数组类型的名； 使用XSD编码表示xsd:anyType。
- 43.
- 44. 消息 消息由若干个逻辑部件（part）构成。每个部件使用一个消息类型属性与某个类型系统的类型相关联。
消息定义语法如下：
* * - 45. 消息示例
- 46. 端口类型定义 端口类型是一个由抽象操作和抽象消息构成的有名称的集合。
- 47. 操作 WSDL支持4种消息交换方式，来访问服务端点。 单向（One-way）：服务访问端点接收消息； 请求响应（Request-response）：服务访问端点接收请求消息，然后发送响应消息； 要求应答（Solicit-response）：服务访问端点发送要求消息，然后接收应答消息； 通知（Notification）：服务访问端点发送通知消息。 操作中引用到的消息通过message属性指定。
- 48. 单向操作 单向操作语法：
- 49. 请求响应操作 请求响应操作语法
- 50. 要求应答操作 要求应答操作语法
- 51. 通知操作 通知操作语法
- 52. 操作中的元素名称 如果单向操作和通知操作未指定name属性，则该属性名默认为是操作名。 如果请求响应或要求应答操作中未指定name属性，则该属性名默认为是 操作名+“Request”/“Responese”/“Solicit”。 针对于请求应答和要求应答操作可以通过parameterOrder指定一个参数名列表。该属性的值是一个用空格分开的消息构件名序列 。
- 53. 绑定 绑定语法如下：
- 54. 服务public class myServices { public void myMethod (int x){ return x; } }
- 55. rpc/encoded样式 WSDL文档内容
- 56. rpc/encoded样式SOAP文档内容
5 - 57. 2 rpc/literal样式WSDL文档内容
- 58. 2 rpc/literal样式SOAP文档内容
5 - 59. 3 document /encodedWSDL文档内容
- 60. 3 document /encodedSOAP文档内容
5 - 61. 4．document /literalWSDL文档内容
- 62. 4．document /literalSOAP文档内容
5 - 63. 实战Web ServiceApache CXF 2.2
- 64. 什么是Apache CXF?http://cxf.apache.org/
- 65. Apache CXF简介Apache CXF = Celtix + XFire，Apache CXF 的前身叫 Apache CeltiXfire，现在已经正式更名为 Apache CXF 了，以下简称为 CXF。CXF 继承了 Celtix 和 XFire 两大开源项目的精华，提供了对 JAX-WS 全面的支持，并且提供了多种 Binding 、DataBinding、Transport 以及各种 Format 的支持，并且可以根据实际项目的需要，采用代码优先（Code First）或者 WSDL 优先（WSDL First）来轻松地实现 Web Services 的发布和使用。目前它仍只是 Apache 的一个孵化项目。 Apache CXF 是一个开源的 Services 框架，CXF 帮助您利用 Frontend 编程 API 来构建和开发 Services ，像 JAX-WS 。这些 Services 可以支持多种协议，比如：SOAP、XML/HTTP、RESTful HTTP 或者 CORBA ，并且可以在多种传输协议上运行，比如：HTTP、JMS 或者 JBI，CXF 大大简化了 Services 的创建，同时它继承了 XFire 传统，一样可以天然地和 Spring 进行无缝集成。
- 66. 特性和目标支持主要的Web Service标准——SOAP, WSDL, WS-I Basic Profile, WS-Addressing, WS-Security, 等等. 高性能的SOAP栈 可插入式地绑定对 POJOs, XMLBeans, JAXB 1.1, JAXB 2.0, and Castor的支持。 可运行在 Java 5和1.4 平台 支持多种传输协议 - HTTP, JMS, XMPP, In-JVM, 等等. 简单易用的API 支持Spring, Pico, Plexus, and Loom 等框架. 支持JBI 支持客户端和服务器端接口自动生成 支持JAX-WS
- 67. 在Apache CXF下开发Web Service Step by step
- 68. 第一步：下载Apache CXFhttp://cxf.apache.org/download.html 下载apache-cxf-2.2.3.zip 压缩包解压
- 69. 第二步：建立工程新建web工程，命名为apache。 将apache-cxf-2.2.3\lib下面的拷贝到新建的web工程WEB-INF\lib下面。
- 70. 修改web.xml文件增加如下内容
CXFServlet CXF Servlet org.apache.cxf.transport.servlet.CXFServlet 2 CXFServlet /* - 71. 编写WebService服务器端代码在src下新建包org.apache.cxf.demo 编写Book.java 编写BookService.java 编写BookServiceImpl.java 编写MainServer.java
- 72. 编写客户端测试代码Client.java
- 73. 发布WebService右键点击MainServer选择MyEclipse->Run As -> Java Application，将apache发布。
- 74. 查看自动生成的WSDL打开ie，键入 http://localhost:8080/BookService?wsdl
- 75. 自动生成的WSDL
- 76. 运行客户端程序右键点击Client.java 选择Run As…->Java Application 由于首次运行需要初始化，所以运行较慢，会报几个延时错误后才会显示结果。
- 77. 客户端运行显示结果
- 78. 相关链接
- 79. Web Service相关链接http://www.w3.org/TR/soap/ http://www.w3.org/TR/wsdl/ http://www.w3.org/TR/UDDI/ http://xfire.codehaus.org/ http://ws.apache.org/axis2
- 80. 课后练习模仿BookService，开发一个自己的GoodsService，通过WebService方式提供商品信息的查询服务。
