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) 提供了一个在不同的应用和平台之间的交互操作标准。

这个交互操作通过一系列基于 XML 的开放标准实现，包括 WSDL 、 SOAP 和 UDDI等。这些标准提供了一系列通用方法来定义、发布和使用 Web Service 。

Web Service 的基本层次结构

基础连接基础连接 : : InternetInternet

统一数据格式统一数据格式 :: XMLXML

服务操作协议服务操作协议 :: SOAPSOAP

服务描述协议服务描述协议 :: WSDLWSDL

Simple, Open, Broad Industry SupportSimple, Open, Broad Industry Support简单、开放、工业界广泛支持简单、开放、工业界广泛支持

服务发布协议服务发布协议 :: UDDIUDDI

UDDI : Universal Description Discovery and Integration

WSDL: Web Service Description Language

SOAP : Simple Object Access Protocol

为什么需要 WebService

DBMSDBMS

DBMSDBMSName

No.

Zip

State

OK Cancel

DataServices

DataServices

BusinessLogic

Services

BusinessLogic

Services

PresentationServices

PresentationServices

DBMSDBMS

DBMSDBMS

DataServices

DataServices

WebServices

WebServicesPresentation &

ProcessServices

Presentation &ProcessServices

NameNo.ZipStateOK Cancel

browserbrowser

browserbrowser之前之前

之后之后

Client APClient AP

NameNo.ZipStateOKCancel

Mobile DeviceMobile Device

LegacyLegacy

SOAP & WSDL

SOAP 是什么？ SOAP 是一种轻量级协议，用于在分散型、分布式环境

中交换结构化信息。 SOAP 利用 XML 技术定义一种可扩展的消息处理框架，它提供了一种可通过多种底层协议进行交换的消息结构。 这种框架的设计思想是要独立于任何一种特定的编程模型和其他特定实现的语义。

SOAP 的概念最初来自于 Microsoft and Userland software ，它已经演化了好几代 ; 当前最新的规范是SOAP 2.0 。由 W3C 组织制定。

SOAP

SOAP 被广泛地认为是新一代跨平台和跨语言的分布式计算机应用的基础框架。

SOAP 1.1 只支持 HTTP POST 方式向终端提交请求。

SOAP 1.2 支持 HTTP POST 和 GET 两种方式。

四个主要组成部分 SOAP 是一个基于 XML 的轻量级规范，其主要使用在分

布式系统中，由下面几个部分组成 : SOAP 封装结构定义了一个整体框架用来表示消息中包含什么

内容，谁来处理这些内容以及这些内容是可选的或是必需的。 SOAP 编码规则定义了用以交换应用程序定义的数据类型的实

例的一系列机制。 SOAP RPC 表示定义了一个用来表示远程过程调用和应答的协

定。 虽然这三个部分都作为 SOAP 的一部分一起描述，但它们在功

能上是相交的。特别的，封装和编码规则是在不同的名域中定义的。规范定义了 SOAP 封装、 SOAP 编码规则和 SOAP-RPC 协定之外，这个规范还定义了 SOAP 和其他协议的绑定，描述了在有或没有 HTTP 扩展框架的情况下， 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

SOAP Envelope 的结构 <soap:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header> <!-- optional --> <!-- header blocks go here... --></soap:Header><soap:Body> <!-- payload or Fault element goes here... --> </soap:Body></soap: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 encodingStyle 属性 EncodingStyle 全局属性用来表示 SOAP 消息的序列化规

则。这个属性可以在任何元素中出现，作用范围与域名声明的作用范围很相似，为这个元素的内容和它的所有没有重载此属性的子元素。 SOAP 消息没有定义缺省编码。属性值是一个或多个 URI 的顺序列表，每个 URI 确定了一种或多种序列化规则，用来不同程度反序列化 SOAP 消息，举例如下：

"http://schemas.xmlsoap.org/soap/encoding/""http://my.host/encoding/restricted http://my.host/encoding/"""

封装版本模型SOAP 没有定义常规的基于主版本号和辅版本号的版本形式。 SOAP 消息必须有一个封装元

素与名域 "http://schemas.xmlsoap.org/soap/envelope/"关联。如果 SOAP 应用程序接收到的SOAP 消息中的 SOAP 封装元素与其他的名域关联，则视为版本错误，应用程序必须丢弃这个消息。如果消息是通过 HTTP 之类的请求 / 应答协议收到的，应用程序必须回答一个 SOAP VersionMismatch 错误信息。

Envelope 元素Envelope 元素始终是 SOAP 消息的根元素。 这就

便于应用程序识别“ SOAP 消息” — 只要检查一下根元素的名称即可。 通过检查 Envelope 元素的命名空间，应用程序也可确定所使用的 SOAP 版本。

Envelope 元素包含一个可选的 Header 元素 ,后跟一个必要的 Body 元素。 Body 元素代表了该消息的有效内容。 它是一种通用容器，因为它可包含来自任何命名空间的任意数量的元素。 这就是试图发送数据的最终目的地。

例子 :

在银行帐户之间转帐的请求信息 : request.xml

相应的响应信息 : response.xml

Fault 元素

该消息处理框架还定义了一个名为 Fault 的元素，用于在发生错误时在 Body 元素中表示错误。 这是不可缺少的，因为如果没有一种标准的错误表示方法，每个应用程序将不得不自己创建，从而使得通用基础结构不可能区分成功和失败。 以下示例 SOAP 消息中包含了一个 Fault 元素，指明在处理该请求时发生了“ Insufficient Funds（资金不足）”错误： fault.xml

Fault 元素 Fault 元素必须包含一个 faultcode ，后跟一个

faultstring 元素。 faultcode 元素使用一种符合命名空间的名称对错误进行分类，而 faultstring 元素提供一种对错误可读的解释（类似于 HTTP 的工作方式）。 表 2 简要地说明了 SOAP 1.1 所定义的各种错误码（所有这些代码都包含在 http://schemas.xmlsoap.org/soap/envelope/ 命名空间中）。

Fault 元素也可能包含一个 detail 元素，以便提供该错误的细节，这样可以帮助客户端诊断问题，特别是在 Client 和 Server 错误码的情况下。

SOAP 1.1 错误码 VersionMismatch

处理方发现 SOAP Envelope 元素的命名空间是无效的 MustUnderstand

处理方没有理解或服从 SOAP Header 元素的某个直接子元素，而该子元素包含一个值为 “ 1” 的 SOAP mustUnderstand 属性。

Client表明消息的格式错误或者不包含适当的信息，因而不能成功。 这通常表明，如果不对该消息做出更改，就不应该重发该消息。

Server表明该消息未能得到处理的原因与消息的内容并没有直接关系，而是跟该消息的处理有关。 例如，处理过程可能包括与某个上游处理器的通信，但该处理器没有响应。 如果在稍后重发，该消息可能会成功。

Soap Header

大多数现有的协议都区分控制信息（例如，标头）和消息有效负载。 在这方面， SOAP 也不例外。 SOAP Header 和 Body 元素在易于处理的 XML 世界中也进行同样的区分。 除了易用性之外，可扩展 Envelope 的关键优势在于它可用于任何通讯协议。

在各种应用程序协议中（如 HTTP 、 SMTP 等）标头总是具有重要的意义，因为标头允许连网两端的应用程序就所支持命令的具体行为进行协商。 尽管 SOAP 规范本身并不定义任何内置的标头，标头将逐渐在 SOAP 中扮演同等重要的角色。

与 Body 元素类似， Header 元素是控制信息的通用容器。 其中可包含来自任何命名空间（除 SOAP 命名空间之外）的任意数量的元素。 放置在 Header 元素中的各个元素被称为标头块。 如同其他协议一样，标头块中包含的信息应该能够影响有效负载的处理。 因此，这里正适于放置诸如凭证一类的元素，以帮助控制对操作的访问： header.xml

2: 我们也可以利用一个名为 mustUnderstand 的全局 SOAP 属性对标头块进行标注，以指明接收方在处理该消息之前是否需要理解标头 : mustunderstand.xml.

Soap Body

SOAP 体元素（ Body）提供了一个简单的机制，使消息的最终接收者能交换必要的信息。使用体元素的典型情况包括配置 RPC 请求和错误报告。体元素编码为 SOAP 封装元素的直接子元素。

如果已经有一个头元素，那么体元素必须紧跟在头元素之后，否则它必须是 SOAP 封装元素的第一个直接子元素。体元素的所有直接子元素称作体条目，每个体条目在SOAP 体元素中编码为一个独立的元素。条目的编码规则如下：

一个条目由它的元素全名（包括名域 URI 和局部名）确定。SOAP 体元素的直接子元素可能是名域限制的。

协议绑定 SOAP 可以和很多传输协议进行绑定 :

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 。 利用前一种方法，架构定义逐字确定了主体的 XML 格式，不具有二义性。 然而，利用后一种方法， SOAP 处理器必须在运行时遍历各种 SOAP 编码规则以确定主体正确的序列化。 很显然，这种方法更易于导致错误和互操作性方面的问题。

最常见的情形是在使用文档类型时也使用文字架构定义（称为文档 / 文字），以及在使用 SOAP 编码规则时使用 RPC 类型（称为 rpc/ 编码）。 文档 /编码和 rpc/ 文字也是可能的，但并不常见，也没有太大意义。 大多数 Web 服务平台都集中于文档 / 文字类型，将其作为发展的主要用例，且是现今 Microsoft ASP.NET WebMethod 框架的默认设置。

HTTP 绑定 HTTP 协议绑定定义了在 HTTP 上使用 SOAP 的规则。

SOAP 请求 /响应自然地映射到 HTTP 请求 / 协议模型。

SOAP RPC 绑定 尽管 SOAP 规范已日渐远离对象，它仍然定义了一种约定，以便利用上述的消息处理框架来封装并交换 RPC 调用。 定义一种标准的方法将 RPC 调用映射到 SOAP 消息，这使得在运行时基础结构可以在方法调用和 SOAP 消息之间自动转换，而不用围绕 Web 服务平台重新设计代码。

要利用 SOAP 进行方法调用，基础结构需要以下信息：1. 终结点位置 (URI)2. 方法名称3. 参数名称 /值4. 可选的方法签名5. 可选的标头数据

SOAP RPC 绑定RPC 调用： double add(ref double x, double y)Request 对象：struct add { double x; double y;}<add> <x >33</x> <y>44</y></add>Response 对象：struct addResponse { double result;}<addResponse> <result>77</result></addResponse>

SOAP RPC

SOAP 文档内容<soap:envelope> <soap:body> <myMethod> <x>5</x> </myMethod> </soap:body></soap:envelope>

服务调用

前置机前置机 SOAP 消息

SOAP 消息

HTTPHTTP HTTPHTTP

WSDL2JAVAWSDL2JAVA

SOAP 消息

SOAP 消息

Class OperationClass Operation

XML MessageXML Message

服务描述CONTEXT

服务描述CONTEXT

XML2JAVAXML2JAVA

XML MessageXML Message

实现 SOAP 的容器 XFIRE 1.x Apache AXIS 1.x/2.x SOAPLite

……

WSDL 描述 web 服务的三个基本属性： 服务做些什么 ?

服务所提供的操作 ( 方法 )； 如何访问服务？

数据格式以及访问服务操作的必要协议； 服务位于何处？

由特定协议决定的网络地址，如 URL 。

WSDL 是什么？ 服务主要通过六个元素进行定义

types, 定义了交换信息的数据格式。 message, 传输消息的抽象定义。一个消息含有多个逻辑部分，每一部分和一些类型相关联。

portType, 一些抽象操作的集合。每个操作关联一个输入消息和一个输出消息。

binding, 针对操作和 portType 中使用的消息指定实际的协议和数据格式规范。

port, 指定一个绑定的地址，这样定义一个通信的终端。 service, 一些 port 构成的集合

WSDL 定义 WSDL 是 XML 描述的网络服务，基于消息机制、包含面

向文本或面向过程信息的操作集合。 操作及消息的抽象定义与它们具体的网络实现和数据格式

绑定是分离的 , 这样就可以重用这些抽象定义。 消息是需要交换数据的抽象描述； 端点类型是操作的抽象集合。 针对一个特定端点类型的具体协议和数据格式规范构成一

个可重用的绑定。 一个端点定义成网络地址和可重用的绑定的联接，端点的集合定义为服务。

服务接口定义和服务实现定义 服务接口组成了服务描述中的可重用部分，

type 元素、 message 和 portType 。 types 元素中描述消息中复杂数据类型的使用。message 元素指定 XML 数据类型组成消息的各个部分。 message 元素用于定义操作的输入和输出参数。

portType 元素中定义了 Web 服务的操作。操作定义了输入和输出数据流中可以出现的 XML 消息。

服务接口定义和服务实现定义

服务实现定义是一个描述给定服务提供者如何实现特定服务接口的 WSDL 文档。有 binding 和 services 。binding 元素描述特定服务接口的协议、数据格式、安全性和其它属性。

service 元素。服务元素包含一组 port 元素。端口将端点与来自服务接口定义的 binding 元素关联起来。

WSDL 是一种 XML 应用 , 它将Web Services描述定义为一组服务访问端点，客户端可以通过这些服务访问端点对包含面向文档信息或面向过程调用的服务进行访问。

WSDL首先对访问的操作和访问时使用的请求／响应消息进行抽象描述，然后将其绑定到具体的传输协议和消息格式上，以最终定义具体部署的服务访问端点。

在具体使用中，可以使用任意的消息格式和网络协议。

在 WSDL 规范中，定义了如何使用 SOAP 消息格式、 HTTP GET ／ POST 消息格式以及MIME格式来完成 Web Services 交互的规范。

WSDL 文档框架<wsdl:definitions name="nmtoken" targetNamespace="uri"> <import namespace="uri" location="uri"/>* <wsdl:types> ……</wsdl:types> <wsdl:message name=“nmtoken”>* ……</wsdl:message> <wsdl:portType name="nmtoken">* ……</wsdl:portType> <wsdl:binding name="nmtoken" type="qname">* ……</wsdl:binding> <wsdl:service name="nmtoken">*……</wsdl:service></wsdl:definitions>

types 元素

<wsdl:types>

<wsdl:documentation .... />

<xsd:schema .... />*

<-- extensibility element --> *

</wsdl:types>

message 元素

<wsdl:message name="nmtoken"> * <wsdl:documentation .... /> <part name="nmtoken" element="qname" type="qname"/> * </wsdl:message>

portType 元素 --抽象操作的集合 <wsdl:portType name="nmtoken">* <wsdl:documentation .... /> <wsdl:operation name="nmtoken">* <wsdl:documentation .... /> <wsdl:input name="nmtoken" message="qname"> <wsdl:documentation .... /> </wsdl:input> <wsdl:output name="nmtoken" message="qname"> <wsdl:documentation .... /> </wsdl:output> <wsdl:fault name="nmtoken" message="qname"> * <wsdl:documentation .... /> </wsdl:fault> </wsdl:operation> </wsdl:portType>

binding 元素 <wsdl:binding name="nmtoken" type="qname">* <wsdl:documentation .... />? <-- extensibility element --> * <wsdl:operation name="nmtoken">* <wsdl:documentation .... /> ? <-- extensibility element --> * <wsdl:input> ? <wsdl:documentation .... /> ? <-- extensibility element --> </wsdl:input> <wsdl:output> ? <wsdl:documentation .... /> ? <-- extensibility element --> * </wsdl:output> <wsdl:fault name="nmtoken"> * <wsdl:documentation .... /> ? <-- extensibility element --> * </wsdl:fault> </wsdl:operation> </wsdl:binding>

service 元素 <wsdl:service name="nmtoken"> * <wsdl:documentation .... />? <wsdl:port name="nmtoken"

binding="qname">* <wsdl:documentation .... /> ? <-- extensibility element --> </wsdl:port> <-- extensibility element --> </wsdl:service>

类型 types 元素包含了交换消息的数据类型定义。为了实现最大的互操作性（ interoperability）和平台中立性（ neutrality）， WSDL 选用 XML Schema DataTypes ，简称 XSD 作为标准类型系统，并将它作为固有类型系统。

<definitions .... > <types> <xsd:schema .... />* </types> </definitions>

类型— XSD 编码抽象数据类型建议

使用元素（ element）形式，而不使用属性 (attribute) 形式；

不包括仅在特殊的协议和数据格式中使用的元素或者属性；

数组类型使用 Soap:Array 类型，并使用ArrayOfXXX 作为数组类型的名；

使用 XSD 编码表示 xsd:anyType 。

<types> <schema…> <element name="PO" type="tns:POType"/> <complexType name="POType"> <element name="id" type="string/> <element name="name" type="string"/> <element name="items"> <complexType> <element name="item" type="tns:Item" minOccurs="0“ maxOccurs="unbounded"/> </complexType> </element> </complexType> <complexType name="Item"> <element name="quantity" type="int"/> <element name="product" type="string"/> </complexType> <element name="Customer" type="tns:CustomerType"/> <complexType name="CustomerType"> <element name="name" type="string"/> </complexType> </schema> </types>

消息 消息由若干个逻辑部件（ part）构成。每个部件使用一个消息类型属

性与某个类型系统的类型相关联。 消息定义语法如下： <definitions .... > <message name="nmtoken"> * <part name="nmtoken" element="qname"? type="qname"?/> * </message> </definitions> 消息 (message)name 属性指定了消息的名称。 如果消息具有多个逻辑单位，则需要使用多个 part 元素。

消息示例 <message name="PO"> <part name="po" element="tns:PO"/> <part name="customer" element="tns:Customer"/> </message>

<message name="P1"> <part name=“address" type=“XSD:string"/> </message>

<message name="P2"> <part name="composite" type="tns:Composite"/> </message>

端口类型定义 端口类型是一个由抽象操作和抽象消息构成的有名称的集合。 <wsdl:definitions .... > <wsdl:portType name="nmtoken"> * <wsdl:operation name="nmtoken"> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation> </wsdl:portType > </wsdl:definitions> 端口类型定义的 name 属性表示端口类型名称，操作定义的 name

属性表示操作名称。

操作 WSDL 支持 4 种消息交换方式，来访问服务端点。

单向（ One-way）：服务访问端点接收消息； 请求响应（ Request-response）：服务访问端点接

收请求消息，然后发送响应消息； 要求应答（ Solicit-response）：服务访问端点发送

要求消息，然后接收应答消息； 通知（ Notification）：服务访问端点发送通知消息。

操作中引用到的消息通过 message 属性指定。

单向操作 单向操作语法： <wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken"> <wsdl:input name="nmtoken"?

message="qname"/> </wsdl:operation> </wsdl:portType > </wsdl:definitions> input 元素指定用于单向操作的抽象消息格式。

请求响应操作 请求响应操作语法 <wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken" parameterOrder="nmtokens"> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:output name="nmtoken"?

message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation> </wsdl:portType > </wsdl:definitions>

要求应答操作 要求应答操作语法 <wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken" parameterOrder="nmtokens"> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation> </wsdl:portType > </wsdl:definitions>

通知操作 通知操作语法 <wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken"> <wsdl:output name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:portType > </wsdl:definitions>

操作中的元素名称 如果单向操作和通知操作未指定 name 属性，则

该属性名默认为是操作名。 如果请求响应或要求应答操作中未指定 name 属

性，则该属性名默认为是 操作名 +“Request”/“Responese”/“Solicit” 。

针对于请求应答和要求应答操作可以通过parameterOrder指定一个参数名列表。该属性的值是一个用空格分开的消息构件名序列 。

绑定 绑定语法如下： <wsdl:definitions .... > <wsdl:binding name="nmtoken" type="qname"> * <-- extensibility element (1) --> * <wsdl:operation name="nmtoken"> * <-- extensibility element (2) --> * <wsdl:input name="nmtoken"? > ? <-- extensibility element (3) --> </wsdl:input> <wsdl:output name="nmtoken"? > ? <-- extensibility element (4) --> * </wsdl:output> <wsdl:fault name="nmtoken"> * <-- extensibility element (5) --> * </wsdl:fault> </wsdl:operation> </wsdl:binding> </wsdl:definitions>

服务

public class myServices { public void myMethod (int x){ return } }

rpc/encoded 样式

WSDL 文档内容<message name="myMethodRequest"> <part name="x" type="xsd:int"/></message><message name="empty"/><portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation></portType>

rpc/encoded 样式

SOAP 文档内容<soap:envelope> <soap:body> <myMethod> <x xsi:type="xsd:int">5</x> </myMethod> </soap:body></soap:envelope>

2 rpc/literal 样式 WSDL 文档内容

<message name="myMethodRequest"> <part name="x" type="xsd:int"/></message><message name="empty"/><portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation></portType>

2 rpc/literal 样式

SOAP 文档内容<soap:envelope> <soap:body> <myMethod> <x>5</x> </myMethod> </soap:body></soap:envelope>

3 document /encoded

WSDL 文档内容 <types> <schema> <element name="xElement" type="xsd:int"/> </schema> </types> <message name="myMethodRequest"> <part name="x" element="xElement"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType>

3 document /encoded

SOAP 文档内容 <soap:envelope> <soap:body> <xElement xsi:type="xsd:int ">5</xElement> </soap:body> </soap:envelope>

4 ． document /literal

WSDL 文档内容 <type> <schema> <element name="xElement" type="xsd:int"/> </schema> </types> <message name="myMethodRequest"> <part name="x" element="xElement"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType>

4 ． document /literal

SOAP 文档内容 <soap:envelope> <soap:body> <xElement>5</xElement> </soap:body> </soap:envelope>

Sample WSDL

sample.wsdl

开发 Web Service

XFire1.2.1

什么是 XFire?

http://xfire.codehaus.org

XFire简介 XFire 是下一代的 java SOAP 框架。 XFire

通过一些简单的 API 和对规范的支持使得面向服务的开发成为可能。

XFire 性能非常好，它是建立在低内存的StAX 模型的基础上的。

特性和目标 支持主要的 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

在 XFire 下开发 Web Service

Step by step

第一步：下载 XFire

http://xfire.codehaus.org/Download 下载 xfire-distribution-1.2.1.zip压缩包解压

第二步：建立工程 新建 web工程，命名为 xfire 。 将 xfire-1.2.1\lib 下面的包和 xfire-1.2.1\

xfire-all-1.2.1.jar 一起拷贝到新建的 web工程 WEB-INF\lib 下面。

修改 web.xml 文件 增加如下内容 <servlet> <servlet-name>XFireServlet</servlet-name> <display-name>XFire Servlet</display-name> <servlet-class> org.codehaus.xfire.transport.http.XFireConfigurableServlet </servlet-class> </servlet>

<servlet-mapping> <servlet-name>XFireServlet</servlet-name> <url-pattern>/servlet/XFireServlet/*</url-pattern> </servlet-mapping>

<servlet-mapping> <servlet-name>XFireServlet</servlet-name> <url-pattern>/services/*</url-pattern> </servlet-mapping>

编写WebService 服务器端代码 在 src 下新建包 org.codehaus.xfire.demo 编写 Book.java 编写 BookService.java 编写 BookServiceImpl.java BookService.aegis.xml

编写 Handler

新建包 org.codehaus.xfire.demo.handlers 编写 CheckVersionHandler.java 编写 OutHeaderHandler.java

编写WebService配置文件 在 src 下新建 log4j.properties 文件。 在 src 下新建目录META-INF/xfire/ 在 META/xfire/ 下新建文件 services.xml

编写客户端测试代码 BookClient.java

发布 WebService

右键点击 xfire 选择MyEclipse->Add and Remove Project Deployment ，将 xfire 发布到 Tomcat 上去。

查看自动生成的 WSDL

打开 ie ，键入http://localhost：8080/xfire/services/BookService?wsdl

自动生成的 WSDL

运行客户端程序右键点击 BookClient.java 选择 Run As…->Java Application 由于首次运行需要初始化，所以运行较慢，会报几个延时错误后才会显示结果。

客户端运行显示结果

语义 Web & Web 服务 & SOA

Web

Web 可以获得如此巨大的发展，一个很重要的原因就是 HTML 的简单、易用；

Yahoo 的发展和出现得益于其网页目录 . Google 的出现可以处理海量的网页信息 .

语义 Web

从学术的角度，一个可以准确有效搜索、推理的Web 应该是一个语意的 Web ，即结构化的和有意义的 Web；

目前数十亿的页面不可能消失或者重建。 一个可行的方法 : 包装已有信息，给已有信息增加语意的说明，即元数据，例如标签（ Tag 或Annotation）。

从这个意义和角度， Google Toolbar 的书签服务， Yahoo 收购 del.icio.us 就可以理解，大家要做的是一样的事情，都是为了提供更好的搜索结果，而不是简单的提供书签服务。

从搜索角度看 自然语言提问 , 系统自动找到答案 系统有一个知识库 , 知识来源可以是网页 知识区分领域

语义 Web

学术界和业界提出了语意 Web （ Semantic Web）的概念，简单来说，就是扩展现有Web ，使 Web页不仅仅是供信息表达的手段，而且可以自描述，具有语意，而更好的搜索 http://del.icio.us和互操作。

SOA

为了更快更有效地响应变化莫测的市场机会，所有行业的公司都在想方设法进行这方面的努力。为获得更高的业务灵活性，许多公司都在实施面向服务的架构 (SOA) 。

SOA 的灵活性体现在它将业务流程和相关的 IT 基础设施中的元素看作安全的、标准化的组件（服务），通过对这些组件（服务）进行重用和组合，即可应对不断变化的业务目标和业务优先级。

当企业系统越来越多后 缺少业务流程标准 架构策略限制 独立的程序业务需

要 基础设施的构建没

有蓝图

从不同的组件中创建服务

DFK

Data Warehouse

GeneralLedger

AP

SalesCorrections

POReceiving

Return toVendor

WarehouseManagement

Credit App

EmployeeChange Notice

OTHER APPS - PC

ACCTS REC APPS - PCINVENTORY CONTROL APPS - PC INVENTORY CONTROL APPS - PC

Journal Entry Tool Kit

Scorecard

ResourceScheduling

P09 - P17Cyb.

Millennium

Millennuim 3.0

Banks - ACH and Pos toPay

Cobra

StockStatus

Polling

On-line NewHire Entry

CTS

Plan Administrators(401K, PCS, Life)

D01 Post LoadBilling

HomeDeliveries

-Transfers

Planning

PurchaseOrder

SolutionSoftware

Inventory Info

Interface

Sales Posting

Price ManagementSystem

Cycle PhysicalInventory

SKUInformation

Customer RepairTracking I35 Early Warning

System

MerchandiseAnalysis

I13- AutoReplenishment

CTO

Intercept Counts

EmployeePurchase

Tex A

ACH

Stock Options

Customer PerceivedIn-Stock

Tx

SS

CapitalProjects

FixedAssets

ReconFile

Repair

EDICoordinator

Mesa DataNEW Soundscan

Resumix

Op.

Store BudgetReporting

Tally Sheet

Cash Receipts/Credit

HouseCharges

Ad Expense

-PromoAnalysis

PriceMarketingSupport

BMP - Busperformance Mngt

StoreScorecard

PriceTesting

Media

Bonus/HR

Hand ScanApps

Shows

POS

SalesTax

A04 - CustRefund Chks

Equifax

Credit

CellularRollover

SatelliteSystem

Scanning

VAN

SKU Rep

Host to AS400Communication

Layaways

Bus Systems

V04-SignSystem

Count CorrectionsN.

P01-EmployeeMasterfile

CustomerOrder

ABCCo

Universal AccountReconcilliation

DepositoryBanks

CellPhones

- ISPTracking

AAS

PO

Cash Over/Short

Coop SKU SelectionTool

SKUPerformance

SupplierCompliance

1

DRKABBX

Misc Accounting/Finance Apps - PC/NT

AIMSMngr Approval

Batch ForcastingAd Measurement

AIMSReportingAd

Launcher

MktReactions

SpecSource

website

RebateTransfer

SignSystem

WriterWorkspace

PowerSuiteStore

Monitor

Calendar

Stores & Mrkts

Due Dates

Smart Plus

InsertionsOrders

BudgetAnalysis Tool

Print CostingInvoice App

Reports

BroadcastFilter

Smart PlusLauncher

GeneralMaintenance

Printer PO

PrinterMaintenance

VendorMaintenance

Vendor Setup

Connect 3

Connect 3Reports

Connect 3PDF Transfe

Spec SourceSKU Tracking

S20-SalesPolling

Prodigy

PSP

In-HomeRepair

WarrantyBillingSystem

Process Servers(Imaging)

找到服务的组件Step 2

Step 1

定义业务服务－ SOA 的基本组成者

重复上述过程Step 4

Step 3

定义接口

确定客户资格

获得信用报告

请求附加信息

Generate decline

等等…

Etc….

通过整合服务实现业务流程

现在，像实施服务一样实施应用…

Web 服务减少了应用间的接口…从这样 … … 变成这样 (web 服务 ).

应用程序

业务应用和接口是可重用的

减少业务应用中间的接口

减少接口的数目和复杂度

对应用接口有丰富的业务描述

但是分别独立的连接还是会导致接口之间的限制…

接 口

= interface

应用服务应用程序 应用程序 应用程序

应用程序 应用程序 应用程序 应用程序

接 口 接 口

接 口 接 口 接 口 接 口

应用服务应用服务应用服务

应用服务 应用服务 应用服务 应用服务

企业服务总线更好地减少了接口…

结果 快速的业务相应

允许动态的选择，置换和匹配

让你找到可以重用的应用和接口

减弱接口间点到点的连接

使应用之间的形成联结或解散联结更灵活

… 变成这样 (SOA)

企业服务总线 ESB

从这样 (web 服务 ) …

接 口 接 口 接 口

接 口 接 口 接 口 接 口

应用服务应用服务

应用服务 应用服务

应用服务应用服务

应用服务 应用服务

应用服务应用服务

应用服务 应用服务

应用服务应用服务

应用服务 应用服务

什么是企业服务总线？企业服务总线（ Enterprise Service Bus ） 是一个整合应用和

服务的灵活的连接基础组织。ESB 减少了你的 SOA 体系中的接口的数量，大小和复杂度。

形状 = 协议颜色 = 数据类型

ESB 在请求者和服务之间实现了：

• 转化请求者和服务之间的传输协议

• 处理分离资源间的业务事件

• 转换请求者和服务之间的消息格式

• 路由服务间的消息

旅行预定过程

有效班机服务

企业服务总线

新检查旅行服务

定酒店服务

有效酒店服务

定车服务

新的有效班机服务

旧的有效班机服务

定机票服务

检查信用服务

改变服务并且对已经存在的服务造成最小的影响

快速添加新的服务

ESB 使你关注于核心业务多过 IT

如果你的应用符合 Web 服务标准…

如果你的应用并不完全符合 Web 服务标准…

…这样你需要 ESB 就要关注在基于标准的服务整合。

…这样你需要高级 ESB关注在对已有的非服务形式的应用的整合。

企业服务总线

1 2

高级企业服务总线

旅行预定过程

有效班机服务

检查旅行服务

定酒店服务

有效酒店服务 定车服务

定机票服务

检查信用服务

旅行预定过程

有效班机服务

检查旅行服务

定酒店服务

有效酒店服务 定车服务

定机票服务

检查信用服务

ESB 的两个关键需求

一个企业服务总线的高级视图

ESB 的集中控制和分布处理星形集成：

相关链接

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

课后练习 模仿 BookService ，开发一个自己的

GoodsService ，通过 WebService 方式提供商品信息的查询服务。