WebService与SOA的实现

14.1 Web Services和面向服务的软件架构（Service Oriented Architecture，简称SOA）概述：

 

在最新Java开发世界里，咱们常常会遇到这样一个名词：Web Services（Web服务）。同时还会发现，与这个名词同时出现的可能是各大主流技术供应商，各大技术供应商无一不在关注这一领域的发展。从Microsoft的.NET架构，到SUN的SUN ONE，以及IBM的Web Services，都体现了这些重量级的技术提供者对Web Services的推崇与重视。

 

电子商务的发展促进了Web Services的发展。Web服务能够使公司下降进行电子商务的成本，更快地部署解决方案以及开拓更多的新机遇。Web服务使应用程序的集成比之前更快、更容易并且更便宜。它更注重服务语义而不那么注重网络协议语义的消息，从而实现了业务功能的松散耦合。这些特性对于在企业之间和企业内部经过web链接业务功能是很是理想的。它提供了一致化（Uniform）的编程模型，从而在企业内外均可以利用通用的基础设施并以一种通用的方法进行应用程序集成。

 

要理解Web Services, 首先须要认识面向服务的软件架构（Service Oriented Architecture，简称SOA），Web Services是SOA架构系统的一个实例。

14.1.1面向服务的软件架构（SOA）

 

1. 面向服务中的基本概念

在面向服务的架构中包含一些基本的概念，透过这些基本概念能够进一步了解面向服务的架构。

(1) 服务的概念

在SOA中的服务是指可以处理一些任务过程的动做的抽象概念，这些服务能够被描述，能够被发现，能够由服务代理负责向请求者提供服务并给出结果。代理是指请求或者提供服务的人所使用的软件工具，人经过代理进行交互操做。

(2) 消息的概念

服务代理之间须要经过消息的传递进行交互操做，消息的内容含有必定的语义和数据，消息传输须要与某个通讯协议相绑定才可以实现。

(3) 服务的描述和发现

众多的服务组成一个开放系统，除了须要提供信息交互方式之外，还须要提供相互了解的机制，这就须要提供描述和发现的方式。代理能够经过服务的描述来了解一个服务的内容，包括使用这个服务的技术信息、访问这个服务的地址信息等内容。当新的服务被投入到系统之中后，它须要被注册，而且要可以被发现，使它能够被利用起来。

 

2.为何须要面向服务的软件

因为软件需求的扩大，软件系统变得愈来愈复杂。面对复杂的系统资源，咱们须要一种更加合理的方式将不一样类型、不一样位置的子系统有力地结合起来，这种整合并非将它们之间绑定得更加紧密，而是利用更加松散的方式来创建这个系统。

SOA经过松散的方式将分布式的软件模块结合起来，与旧有系统集成相比有着明显的优点。对于服务的使用者来讲，能够简单地经过服务的描述来获取服务，系统各部分之间没必要为了某一部分的升级而改变，在服务的过程当中不一样的软件模块能够充当不一样的角色，从而构成整个系统的工做体系。

在SOA当中，一个服务表明的是一个由服务提供者向服务请求者发布的一些处理过程，这个过程在被调用以后，得到服务请求者所须要的一个结果。在这个过程当中，服务请求者能够向任何可以提供此项服务的服务提供者来请求服务，服务实现的过程对于服务请求者来讲是透明的。

随着系统分布式和多种结构复合程度的提升，SOA的巨大优点将进一步被挖掘。

(1) 创建松散耦合的系统

松散耦合系统的优势已经被业内充分地承认，SOA做为一种分布式的系统，它实现了一种服务和描述等概念相结合的架构。

SOA中的服务在SOA架构中被标准的描述语言所描述，并经过与某种传输协议的绑定来实现相互之间的交互。这种基于服务的架构使整个系统成为一个松散耦合的结构，利用与通讯协议的绑定将分布式系统中的全部部分链接起来，利用语义和服务的描述，在代理之间进行交互。

(2) 提升软件的重用性

面向服务的架构还提升了对软件的重用性。与组件方式相比，SOA系统中的单个服务的改变不会对其余部分形成严重的影响，同时利用服务的描述使同一服务能够充分地被其余系统所调用，各个系统之间造成了高度的重用性。

如今正在被普遍使用的一些服务，正在不断地被各个系统所重用，重用的条件十分简单，只要了解服务的描述，或者能够访问到服务的描述地址便可。与组件重用相比，服务的重用还具备与实现语言无关的特色，重用服务的客户端程序不须要使用与服务实现部分一样的开发语言，一切交互的过程都是利用与实现无关的方式进行的。

(3) 提供按需服务的代码

面向服务的架构也使得系统的实现虚拟化，在SOA架构中的请求和提供之间交互或相互代理的过程当中，可计算的代码资源分布在松散结构中的各个部分上，当请求发生时才被调用和服务，全部计算过程都是按照请求者的需求进行的。服务的对象分为有状态和无状态两种方式提供服务，按照需求提供服务，也能够利用缓冲机制优化系统的系统。

总之，SOA使代码的开发变得更有服务的目的性，使开发更加有效和合理。

 

14.1.2 SOA与 Web 2.0

另外，咱们补充一下SOA与目前一样热门的Web 2.0的关系。

实际上Web 2.0 和SOA的概念在很大程度上是相同的，只是被粉饰成为软件的不一样部分（若是的确存在不一样的话），也就是说SOA和Web 2.0有不少重叠的东西，例如都是基于调用（invoke）的服务，都能存在于网络的任何位置等等。

SOA和Web 2.0的共性远大于它们之间的区别，并且Web 2.0在推广SOA方面起到了必定做用。到如今为止，SOA和Web 2.0拥有不一样的支持者- SOA更多涉及企业结构和商务开拓，而Web 2.0更关注用户。这种差异随着更多企业接纳Web 2.0而在变化，可是这两项技术有着不一样的重心: Web 2.0告诉咱们数据是软件应用中最重要的部分，而SOA告诉咱们服务才是中心。SOA中传输数据的服务也很是重要，可是传统SOA更关注IT系统的接合处而不是那些能使接合处更具价值的东西。也就是说，SOA也许是通畅的管道，但并非系统中经过的水的价值。许多行业领导者说企业同时须要SOA类方法的结构和Web 2.0方法的创业能力。

SOA和Web 2.0之间有许多共有的要素：

l 软件重组

l 管理

l 软件就是服务

l 应用就是平台

l 无心识的使用

l 开放

l AJAX

l 互操做性

l 货币化

l 安全

l 网络导向架构

特别要说的是，最后一条网络导向架构或者Web Oriented Architecture（WOA）是关键的内容，最终有可能会将SOA和Web 2.0合为一体。

 

了解了SOA后， 咱们来介绍什么是Web Services。Web Services是SOA架构系统的一个实例。从技术角度来说，Web Services是一种新的技术架构、新的软件应用环境。它的系统架构和实现技术彻底继承已有的技术，能够认为Web Services是Internet的一种延伸，是现有的Internet面向更好的互操做能力的一个延伸。

14.2． Web Services的概念

Web Services，从字面上理解就是经过Web提供的服务。咱们能够理解Web Services是自包含的、模块化的应用程序，它能够在网络(一般为Web)中被描述、发布、查找以及调用；也能够理解Web Services是基于网络的、分布式的模块化组件，它执行特定的任务，遵照具体的技术规范，这些规范使得Web Sevices能与其余兼容的组件进行互操做；也能够这样理解，所谓Web服务，它是指由企业发布的完成其特别商务需求的在线应用服务，其余公司或应用软件可以经过Internet来访问并使用这项应用服务

对于Web Services，不少人会与Web Service混为一谈，认为两者指的是同一个事物。其实否则，前者指的是用于建构Web Service的技术框架，后者指的是使用Web Services技术而建立的应用实例。Web Services是描述了一些操做的接口，基于标准化的XML消息传输机制，咱们能够经过网络访问这些操做。Web Services使用规范的、基于XML的WSDL(Web Services Description Language)语言描述的，这称为Web Services的服务描述。这一描述囊括了与服务交互所须要的所有细节，包括消息格式（详细描述操做的输入输出消息格式）、传输协议和位置。该接口隐藏了服务实现的细节，容许经过独立与服务实现、独立于软硬件平台、独立于编写服务所用的编程语言的方式使用该服务。这使得基于Web Services的应用程序具备松散耦合、面向组件和跨技术实现的特色。Web Services都履行必定的特定业务或任务，能够实现同其余Web Services一块儿用于实现复杂的商业交易。

从外部使用者角度而言，Web Services是一种部署在Web上的对象和组件，具有如下特征：

.无缺的封装性：

Web服务既然是一种部署在web上的对象，天然具有对象的良好封装性，对于使用者而言，他能且仅能看到该对象提供的功能列表。

.松散耦合

这一特征也是源于对象／组件技术，当一个Web服务的实现发生变动的时候，调用者是不会感到这一点的，对于调用者来讲，只要Web服务的调用界面不变，Web服务实现的任何变动对他们来讲都是透明的，甚至是当Web服务的实现平台从J2EE迁移到了．NET或者是相反的迁移流程，用户均可以对此一无所知。对于松散耦合而言，尤为是在Internet环境下的Web服务而言，须要有一种适合Internet环境的消息交换协议，而XML／SOAP正是目前最为适合的消息交换协议。

.使用协议的规范性

这一特征从对象而来，但相比通常对象，它更加规范化和易于理解。首先，做为Web服务，对象界面所提供的功能应当使用标准的描述语言来描述(好比WSDL)；其次，由标准描述语言描述的服务界面应当是可以被发现的，所以这一描述文档须要被存储在私有的或公共的注册库里面。同时，使用标准描述语言描述的使用协约将不只仅是服务界面，它将被延伸到Web服务的聚合、跨Web服务的事务、工做流等，而这些又都须要服务质量(QoS)的保障。其次，咱们知道安全机制对于松散耦合的对象环境的重要性，所以咱们须要对诸如受权认证、数据完整性(好比签名机制)、消息源认证以及事务的不能否认性等运用规范的方法来描述、传输和交换。最后，在全部层次的处理都应当是可管理的，所以须要对管理协约运用一样的机制。

.高度可集成能力

因为Web服务采起简单的、易理解的标准，Web协议做为组件界面描述和协同描述规范，彻底屏蔽了不一样软件平台的差别，不管是CORBA、DCOM仍是EJB，均可以经过这一种标准的协议进行互操做，实现了在当前环境下最高的可集成性。

 

14.2.1 Web Services的核心技术

 

Web Services 是一种基于组件的软件平台,是面向服务的Internet 应用。Web Services 是应用于Internet 的,而不是限于局域网或试验环境，这就要求Web Services 框架必须适用于现有的Internet 软件和硬件环境,即服务的提供者所提供的服务必须具备跨平台、跨语言的特性。其次,Web Services 所提供的服务不可是面向人,并且需服务于其它应用系统。现有的Web网站也能够认为是面向服务的,但这种服务仅仅能够提供给人使用(只有人类才能够读懂浏览器下载的页面) 。而新一代的Web Services 所提供的服务应能被机器所读懂,例如其它应用程序及移动设备中的软件系统。这样,咱们能够看出,Web Services 的发展方向其实是构造一个基于现有Internet 技术之上的分布计算系统。

Web Services 框架的核心技术包括SOAP(Simple Object Access Protocol,简单对象访问协议) ,WSDL(Web Services Description Lanuage,Web服务描述语言) 和UDDI（Universal Description，Discovery and Integration，通用描述，发现，集成) ,它们都是以标准的XML 文档的形式表述的。

XML是Web Services技术体系中最基础的标准，Web Services的一切都创建在XML技术的基础之上，包括Web Services的消息、描述和服务实现的各个环节。利用XML，Web Services的服务提供者和请求者能够利用不一样的开发语言来协做完成服务调用的过程。XML是Web Services技术体系中的不少标准得以创建的基础，在Web Services系统中无处不在。

 

SOAP 是Web services 的通讯协议。SOAP是一种简单的、轻量级的基于XML 的机制，用于在网络应用程序之间进行结构化数据交换。SOAP包括三部分:一个定义描述消息内容的框架的信封，一组表示应用程序定义的数据类型实例的编码规则，以及表示远程过程调用和响应的约定。

WSDL表示WEB服务说明语言。WSDL文件是一个XML 文档，用于说明一组SOAP消息以及如何交换这些消息，经过WSDL能够描述一个服务的信息。这些信息使不了解这个服务的开发者能够创建调用这个服务的客户端代码，或者经过WSDL帮助生成实现它的基本代码结构。WSDL在Web Services的实际开发过程当中起着重要的做用。

 

　　Web Services是基于互联网的应用程序模块，用于在互联网上运行，它采用开放的UDDI（Universal Description，Discovery and Integration，通用描述，发现，集成）标准。UDDI标准先由IBM、微软、Ariba制订，到目前为止得到了130多家公司的支持。UDDI 提供一种发布和查找服务描述的方法。UDDI 数据实体提供对定义业务和服务信息的支持。WSDL 中定义的服务描述信息是UDDI注册中心信息的补充。UDDI提供了一个开放，平台独立的技术框架，来使企业之间能在互联网上找到对方的服务，定义它们在互联网上的交互活动，以及这些信息的共享方式。

 

Web 服务体系结构基于三种角色（服务提供者、服务注册中心和服务请求者）之间的交互。

服务提供者。从企业的角度看，这是服务的全部者。从体系结构的角度看，这是托管访问服务的平台。 
服务请求者（用户）。从企业的角度看，这是要求知足特定功能的企业。从体系结构的角度看，这是寻找并调用服务，或启动与服务的交互的应用程序。服务请求者角色能够由浏览器来担当，由人或无用户界面的程序（例如，另一个 Web 服务）来控制它。 
服务注册中心。这是可搜索的服务描述注册中心，服务提供者在此发布他们的服务描述。在静态绑定开发或动态绑定执行期间，服务请求者查找服务并得到服务的绑定信息（在服务描述中）。对于静态绑定的服务请求者，服务注册中心是体系结构中的可选角色，由于服务提供者能够把描述直接发送给服务请求者。一样，服务请求者能够从服务注册中心之外的其它来源获得服务描述，例如本地文件、FTP 站点、Web 站点、广告和服务发现（Advertisement and Discovery of Services，ADS）或发现 Web 服务（Discovery of Web Services，DISCO）。 

　　Web Services 的体系架构如图1 所示

Web Services 服务提供方经过WSDL(Web Services Description Language) 描述所提供的服务,并将这一描述告知Web Services 注册服务器。注册服务器依据WSDL 的描述,依照UDDI (Universal Description Discovery and Integration) 的协定更新服务目录并在Internet 上发布。用户在使用Web Services 前先向注册服务器发出请求,得到Web Services 提供者的地址和服务接口信息,以后使用SOAP 协议(Simple Object Access Protocol) 与Web Services 提供者创建链接,进行通讯。Web Services 的技术主要创建在XML 的规范之上,这保证了这一体系结构的平台无关性、语言无关性和人机交互性能。

 

14.2.2 Web 服务开发生命周期

Web 服务开发生命周期包括了设计和部署以及在运行时对服务注册中心、服务提供者和服务请求者每个角色的要求。每一个角色对开发生命周期的每一元素都有特定要求。

Web 服务开发生命周期有如下四个阶段：

1. 构建 
生命周期的构建阶段包括开发和测试 Web 服务实现、定义服务接口描述和定义服务实现描述。咱们能够经过建立新的 Web 服务、把现有的应用程序变成 Web 服务和由其它 Web 服务和应用程序组成新的 Web 服务来提供 Web 服务的实现。

2. 部署 
部署阶段包括向服务请求者或服务注册中心发布服务接口和服务实现的定义，以及把 Web 服务的可执行文件部署到执行环境（典型状况下，Web 应用程序服务器）中。

3. 运行 
在运行阶段，能够调用 Web 服务。在此，Web 服务完成部署，成为可操做的服务。服务请求者能够进行查找和绑定操做。

4. 管理 
管理阶段包括持续的管理和经营 Web 服务应用程序。安全性、可用性、性能、服务质量和业务流程问题都必须被解决。

 

接下来咱们具体展开Web Services原理。

 

14.3．Web Services原理

 

首先，咱们将看看 Web 服务的一个概念性协议栈以及这个协议栈的细节。而后咱们将讨论选择网络协议的标准。咱们还将回顾一下基本的基于 XML 的消息传递分布式计算。咱们将用服务描述扩展基本的 XML 消息传递，而服务描述是根据它的协议栈来解释的。接下来，咱们将讨论服务描述在 Web 服务体系结构中的角色，说明支持静态和动态 Web 服务应用程序的服务发布技术的范围。咱们还将围绕服务发布讨论服务发现的角色。最后，咱们将描述基本 Web 服务体系结构的扩展，电子商务须要这些扩展才能使用 Web 服务。

 

14.3.1 Web 服务协议栈

要以一种可交互操做的方式执行发布、发现和绑定这三个操做，必须有一个包含每一层标准的 Web 服务协议栈。图 2 展现了一个概念性 Web 服务协议栈。上面的几层创建在下面几层提供的功能之上。垂直的条表示在协议栈中每一层必须知足的需求。

图2. Web 服务概念性协议栈

Web 服务协议栈的基础是网络层。Web 服务要被服务请求者调用，就必须是能够经过网络访问的。互联网上能够公用的 Web 服务使用广泛适用的网络协议。HTTP 凭借其广泛性，成为了互联网可用的 Web 服务真正的标准网络协议。Web 服务还能够支持其它互联网协议，包括 SMTP 和 FTP。内部网域能够使用可靠消息传递和调用基础结构，如 MQSeries 和 CORBA 等等。

 

下一层是基于 XML 的消息传递，它表示使用 XML 做为消息传递协议的基础。选择 SOAP 做为 XML 消息传递协议有不少缘由：

它是使用 XML 传送以文档为中心的消息以及远程过程调用的标准化封装机制。 
SOAP 很简单；它基本上是一个用 XML 信封做为有效负载的 HTTP POST。 
SOAP 比对 XML 简单的 HTTP POST 更受青睐，由于它定义了一个标准机制，这个机制将正交扩展（orthogonal extension）合并为使用 SOAP 报头和对操做或函数进行标准编码的消息。 
SOAP 消息支持 Web 服务体系结构中的发布、查找和绑定操做。 
服务描述层其实是描述文档的一个协议栈。首先，WSDL 是基于 XML 的服务描述的真正标准。这是支持可交互操做的 Web 服务所需的最小标准服务描述。WSDL 定义了服务交互的接口和结构。要指定业务环境、服务质量和服务之间的关系，咱们还须要另外的描述。WSDL 文档能够由其它服务描述文档来补充，从而描述 Web 服务的这些更高级的方面。例如，描述业务环境除了使用 WSDL 文档，还要使用 UDDI 数据结构。Web 服务流程语言（Web Services Flow Language，WSFL）文档中则描述了服务组成和流程。

由于 Web 服务被定义为能够经过 SOAP 从网络进行访问，并由服务描述表示，因此该协议栈中的前三层须要提供或使用 Web 服务。最简单的协议栈将包括网络层的 HTTP、XML 消息传递层的 SOAP 协议以及服务描述层的 WSDL。全部企业间或公用 Web 服务都应该支持这种可交互操做的基础协议栈。Web 服务，特别是企业内部或专用 Web 服务，可以支持其它的网络协议和分布式计算技术。该协议栈提供了互操做性，它使 Web 服务可以利用现有的互联网基础结构。这将使进入广泛存在的环境的成本很是低。另外，灵活性并不会由于互操做性需求而有所下降，由于咱们能够为选择性和增值的技术提供另外的支持。例如，咱们必须支持 HTTP 上的 SOAP，但也能够同时支持 MQ 上的 SOAP。

协议栈的最下面三层确立了保证一致性和互操做性的技术，而它们上面的两层，即服务发布和服务发现，能够用多种解决方案来实现。

任何可以让服务请求者使用 WSDL 文档的操做，无论它处于服务请求者生命周期的哪一个阶段，都符合服务发布的标准。该层中最简单、最静态的实例就是服务提供者直接向服务请求者发送 WSDL 文档。这被称为直接发布。电子邮件是直接发布的载体之一。直接发布对静态绑定的应用程序来讲颇有用。另外，服务提供者还能够将描述服务的文档发布到主机本地 WSDL 注册中心、专用 UDDI 注册中心或 UDDI 运营商节点。

Web 服务若是没有被发布就不能被发现，因此说服务发现依赖于服务发布。该层的各类发现机制和一组发布机制互相平行。任何容许服务请求者得到对服务描述的访问权，并在运行时使应用程序可以使用该服务描述的机制都必须符合服务发现的标准。最简单、最静态的发现的实例是静态发现，其中服务请求者从本地文件获取 WSDL 文档。这一般都是经过直接发布获取的 WSDL 文档，或者前面查找操做的结果。另外，也能够经过使用本地 WSDL 注册中心、专用 UDDI 注册中心或 UDDI 运营商节点在设计时或运行时发现服务。由于 Web 服务实现是一种软件模块，因此经过组建 Web 服务来产生 Web 服务是很天然的。Web 服务的组合能够扮演不少角色之一。企业内部的 Web 服务可能会相互合做，从而对外显示出一个单独的 Web 服务接口，或者，来自不一样企业的 Web 服务能够相互合做，从而执行机器到机器、企业到企业的事务。另外，工做流程管理者还能够在参与业务流程的时侯调用每一个 Web 服务。最上面一层，即服务流程，描述了如何执行服务到服务的通信、合做以及流程。WSFL 用于描述这些交互。要使 Web 服务应用程序知足当今电子商务的迫切需求，就必须提供企业级基础结构，包括安全性、管理和服务质量。这几个垂直条在协议栈的每一层都必须获得解决。每一层的解决方案能够彼此独立。随着 Web 服务范例的采用和发展，将会出现更多此类垂直条。

该协议栈的最下面几层表示基础 Web 服务协议栈，它们相对于协议栈中上面几层来讲更成熟，也更标准。Web 服务的成熟和采用将会带动协议栈中上面几层和垂直条的开发和标准化。

网络层

Web 服务协议栈的最底层是网络层。该层可表示任意多个网络协议：HTTP、FTP、SMTP、消息排队（Message Queuing）、互联网 ORB 间协议（Internet Inter ORB Protocol，IIOP）上的远程方法调用（Remote Method Invocation，RMI）、电子邮件等等。在任何给定的状况下使用的网络协议都依赖于应用程序需求。

对于能够从互联网访问的 Web 服务，人们选择网络技术的时侯一般会倾向于选择广泛部署的协议，如 HTTP。对于内部网中提供和使用的 Web 服务，使用另外的网络技术也会被认同。咱们能够根据其它需求选择网络技术，包括安全性、可用性、性能以及可靠性。这使得 Web 服务能够利用已有的功能更高级的联网基础结构和面向消息的中间件，如 MQSeries。在有多种网络基础结构的企业中，HTTP 能够用来在这些基础结构之间搭建桥梁。

Web 服务的好处之一在于，它为专用内部网和公用互联网服务的开发和使用提供了统一的编程模型。因此，网络技术的选择对服务开发者来讲是透明的。

基于 XML 消息传递的分布式计算

Web 服务体系结构最基础的支柱是 XML 消息传递。当前 XML 消息传递的行业标准是 SOAP。IBM、Microsoft 以及其它企业都向 W3C 建议 SOAP 做为 XML 协议工做组（XML Protocol Working Group）的基础。XML 协议将代替 SOAP 做为行业标准 XML 消息传递协议的位置。当 W3C 发布 XML 协议的草案标准时，Web 服务体系结构就会从 SOAP 迁移到 XML 协议。

SOAP 是一种简单的、轻量级的基于 XML 的机制，用于在网络应用程序之间进行结构化数据交换。SOAP 包括三部分：一个定义描述消息内容的框架的信封、一组表示应用程序定义的数据类型实例的编码规则，以及表示远程过程调用（remote procedure calls，RPC）和响应的约定。SOAP 能够和各类网络协议（如 HTTP、SMTP、FTP 和 IIOP 或 MQ 上的 RMI）相结合使用，或者用这些协议从新封装后使用。

虽然理解这个基础很重要，但多数 Web 服务开发者没必要直接处理这个基础结构。大多数 Web 服务都会使用从 WSDL 生成的通过优化的特定于编程语言的绑定。当服务提供者和服务请求者都在相似的环境中执行时，这种优化可能尤其重要。

图 4 展现了 XML 消息传递（即 SOAP）和网络协议如何组成Web 服务体系结构的基础。

 

图 4. 使用 SOAP 的 XML 消息传递

网络节点在基于 XML 消息传递的分布式计算中扮演提供者和请求者角色的基本要求是构建、解析 SOAP 消息的能力（或二者兼而有之），以及在网络上通讯的能力（接收、发送消息，或二者）。

一般，在 Web 应用程序服务器中运行的 SOAP 服务器将执行这些功能。另外，咱们也能够使用在 API 中封装这些功能的特定于编程语言的运行库。应用程序与 SOAP 的集成能够经过使用四个基本步骤来实现：

在图 4 中，服务提供者的应用程序在（1）建立一条 SOAP 消息。这条 SOAP 消息是调用由服务提供者提供的 Web 服务操做的请求。消息主体中的 XML 文档能够是一个 SOAP RPC 请求，也能够是一个服务描述中所描述的以文档为中心的消息。服务请求者将此信息和服务提供者的网址一块儿提供给 SOAP 基础结构（例如一个 SOAP 客户机运行时）。SOAP 客户机运行时与一个底层网络协议（例如 HTTP）交互，而后在网络上将 SOAP 消息发送出去。 
网络基础结构在（2）将消息传送到服务提供者的 SOAP 运行时（例如一个 SOAP 服务器）。SOAP 服务器将请求消息路由到服务提供者的 Web 服务。若是应用程序须要，SOAP 运行时负责将 XML 消息转换为特定于编程语言的对象。这个转换由消息中能够找到的编码模式所控制。 
Web 服务负责处理请求信息并生成一个响应。该响应也是一条 SOAP 消息。响应的 SOAP 消息在（3）被提供给 SOAP 运行时，其目的地是服务请求者。在 HTTP 上的同步请求／响应的状况中，联网协议的底层请求／响应本质用于实现消息传递的请求／响应本质。SOAP 运行时将 SOAP 消息响应发送到网络上的服务请求者。 
响应消息在（4）由服务请求者节点上的联网基础结构接收。消息会通过整个 SOAP 基础结构；可能会将 XML 消息转换为目标编程语言中的对象。而后，响应消息被提供给应用程序。 
本示例使用了请求／响应传送基本原理，这种原理在大多数分布式计算环境中都很常见。请求／响应交换能够是同步的，也能够是异步的。其它传送基本原理，如单向消息传递（无响应），通知（推进式响应）以及发布／订阅，也可能用到 SOAP。

那么，服务请求者如何知道请求消息应该使用什么格式呢？这个问题在下面会获得回答。

 

服务描述：从 XML 消息传递到 Web 服务

服务提供者是经过服务描述将全部用于调用 Web 服务的规范传送给服务请求者的。要实现 Web 服务体系结构的松散耦合，并减小服务提供者和服务请求者之间所需的共识的程度和定制编程与集成的程度，服务描述就是关键。例如，无论是请求者仍是提供者，都没必要了解对方的底层平台、编程语言或分布式对象模型（若是有的话）。服务描述与底层 SOAP 基础结构相结合，足以封装服务请求者的应用程序和服务提供者的 Web 服务之间的这个细节。

基本服务描述

Web 服务体系结构使用 WSDL 做为基本服务描述。WSDL 已经被提交到 W3C 做为标准。WSDL 是一种 XML 文档，它将 Web 服务描述为一组端点，这些端点会处理包含面向文档或面向过程的（RPC）消息的消息。操做和消息都是被抽象描述的，而后它们会被绑定到一个具体的网络协议和消息格式，用来定义端点。相关的具体端点被合并到抽象的端点或服务中。WSDL 能够扩展为容许端点和其消息的描述，无论使用哪一种消息格式或网络协议进行通信均可以。然而，目前通过描述的绑定只能用于 SOAP 1.一、HTTP POST 以及多用途互联网邮件扩展（Multipurpose Internet Mail Extensions，MIME）。

Web 服务体系结构中对 WSDL 的使用按照常规将基本的服务描述分红了两部分：服务接口和服务实现。这使每一个部分均可以被分开独立定义，并能够由另外一部分从新使用。

服务接口定义是一种抽象或可重用的服务定义，它能够被多个服务实现定义实例化和引用。咱们能够将服务接口定义想象成接口定义语言（Interface Definition Language，IDL）、Java 接口或 Web 服务类型。这使常见的行业标准服务类型能够被多个服务实现者定义和实现。这相似于在编程语言中定义抽象接口而后获得多个具体实现。服务接口能够由行业标准组织定义。

服务接口包含 WSDL 元素，它们组成了服务描述中的可重用部分，这些元素有：WSDL: binding、WSDL: portType、WSDL: message 和 WSDL: type 元素，如图 5 中所描述。WSDL: portType 元素中定义了 Web 服务的操做。操做定义了输入和输出数据流中能够出现的 XML 消息。您能够将操做想象成编程语言中的方法说明。WSDL: message 元素指定哪些 XML 数据类型组成消息的各个部分。WSDL: message 元素用于定义操做的输入和输出参数。WSDL: types 元素中描述消息中复杂数据类型的使用。WSDL: binding 元素描述特定服务接口（WSDL: portType）的协议、数据格式、安全性和其它属性。

服务实现定义是一个描述给定服务提供者如何实现特定服务接口的 WSDL 文档。Web 服务被建模成 WSDL: service 元素。服务元素包含一组（一般是一个）WSDL: port 元素。端口将端点（例如网址位置或 URL）与来自服务接口定义的 WSDL: binding 元素关联起来。

为了说明职责的安排，开放应用程序组（Open Applications Group，OAG）为开放应用程序组集成规范（Open Applications Group Integration Specification，OAGIS）购买标准定义了一个服务接口定义。这个服务接口定义会定义 WSDL: type、WSDL: message、WSDL: portType 和 WSDL: binding。

服务提供者能够选择开发实现 OAGIS 购买订单服务接口的 Web 服务。服务提供者会开发一个服务实现定义文档，描述 WSDL 设备、端口和地址位置元素，这些元素描述提供者的 Web 服务的网址及其它特定于实现的细节。

服务接口定义和服务实现定义结合在一块儿，组成了服务完整的 WSDL 定义。这两个定义包含为服务请求者描述如何调用以及与 Web 服务交互的足够信息。服务请求者能够要求得到其它关于服务提供者端口的信息。此信息由服务完整的 Web 服务描述提供。

 

完整的 Web 服务描述

完整的 Web 服务描述创建在服务基本的 WSDL 定义之上。完整的 Web 服务描述能够解决这样的问题：什么企业在托管这个服务？它是何种类型的企业？与服务相关联的产品有哪些？各类公司和产品类别中与该企业或其 Web 服务相关联的分类有哪些？有没有服务的其它方面（如服务质量）会影响到请求者是否选择调用服务？为了使查找该服务更容易，能够提供哪些关键字？

图 6 中描述了一个完整的 Web 服务描述。

图 6. 完整的 Web 服务描述协议栈

UDDI 提供了一个保存 Web 服务描述的机制。虽然 UDDI 一般会被认为是一种目录机制，可是它也定义了一个用 XML 表示服务描述信息的数据结构标准。UDDI 条目中有四种基本数据结构，如图 7 中所示。

图 7. 基本 UDDI 数据结构

UDDI 条目由 businessEntity 开始。businessEntity 元素对关于企业的信息进行建模，包括基本的企业信息（例如企业名称和联系方式信息是什么？）、分类信息（例如这是何种类型的企业？）以及标识信息（即 Dunn and Bradstreet 编号是什么？）。businessEntity 包含一组 businessService 元素，每一个元素对应于企业但愿发布的每一个 Web 服务。每一个 businessService 元素都包含和 businessEntity 元素的 Web 服务有关的技术性和描述性信息。businessService 包含一组 bindingTemplate 元素。bindingTemplate 描述访问信息（例如端点地址），还描述 businessService 如何使用各类不一样的技术规范。技术规范在这里的模型是 tModel。tModel 能够为不少不一样概念建模，如：一种服务、一个诸如 HTTPS 之类的平台技术或一个类别。与 businessService 相关联的那一组 bindingTemplate 元素表明了 businessService 所使用的技术的印记。

在Web 服务体系结构中，完整的 Web 服务描述包括用于端点描述的一层，这个端点描述使用 UDDI 条目向服务描述添加企业和实现环境。

端点描述遵循结合 WSDL 使用 UDDI 的约定。端点描述使用 UDDI 提供企业信息和类别的标准表示。这个 UDDI-WSDL 约定规定了如何从和 Web 服务相关联的 UDDI 条目中得出服务接口定义和服务实现定义的 WSDL 描述。这个约定对于在Web 服务体系结构中使用 UDDI 做为基于 WSDL 的服务的服务注册中心来讲相当重要。

端点描述向应用到服务的特定实现的服务描述添加了另外的语义。安全属性能够定义对 Web 服务的访问进行控制的策略。服务质量属性指定面向性能的能力，例如服务在必定时间内做出响应的能力，或所支持的可靠消息传递的级别。服务开销属性描述服务的资源需求。还能够定义支持哪些对话语义。

服务描述协议栈中的最后一层是协议描述。协议描述反映两个企业伙伴之间为了完成一个多步企业交互而进行的 Web 服务调用的一个简单的编排。例如，“协议定义”定义了购买协议中诸如购买者和出售者之类的角色。协议定义规定了每一个角色必须达到的要求。例如，出售者必须有接受报价请求（request for quote，RFQ）消息、购买订单（purchase order，PO）消息和付款消息的 Web 服务。购买者的角色必须有接受报价（RFQ 响应信息）、发票消息和账户摘要信息的 Web 服务。这个简单的 Web 服务到企业角色的编排对于在企业伙伴之间创建多步的、面向服务的交互来讲相当重要。在不少不一样的企业协议标准下，一个给定的服务请求者或服务提供者也许可以扮演购买者或出售者的角色。经过显式地创建企业协议和每一个节点在企业协议中扮演各类角色的能力，请求者能够选择在面对各类提供者企业伙伴时加入哪一种企业协议。

这个领域充满了创新。对于企业协议定义来讲，目前尚未一个单独的标准。ebXML 协做-协议概要和协定规范（ebXML Collaboration-Protocol Profile and Agreement Specification）描述了这些概念，但不是根据做为该体系结构的一部分描述的 Web 服务技术而描述的。Web 服务流程描述和 Web 服务端点描述这两层正处于开发中，它们能够提供这个级别的服务描述。

 

服务描述的发布和发现

服务发布

Web 服务的发布包括服务描述的生成和以后的发布。发布能够使用各类不一样机制。

生成服务描述 
咱们能够生成、手工编码服务描述，也能够根据已有的服务接口定义组成服务描述。开发者能够手工编码整个服务描述，包括 UDDI 条目。有些工具能够从编程模型和可执行 Web 服务的部署生成 WSDL，还有可能生成来自元数据构件的部分 UDDI 条目。部分服务描述可能已经存在（例如，Web 服务能够基于一个行业标准服务接口定义），这样就只须进一步生成一小部分就能够了。

发布服务描述 
服务描述能够使用各类不一样机制来发布。根据应用程序将使用服务的动态程度，这些不一样的机制提供不一样的能力。服务描述能够使用多种不一样机制发布到多个服务注册中心。

最简单的状况是直接发布。直接发布意味着服务提供者直接将服务发布给服务请求者。这能够经过使用电子邮件附件、FTP 站点甚至光盘分发来实现。直接发布能够在企业伙伴双方就在 Web 上使用电子商务的条款达成一致后进行，或在请求访问服务的服务请求者支付了费用以后进行。在这种状况下，服务请求者能够保留服务描述的一份本地副本。

稍微更动态一点的发布使用 DISCO 或 ADS。DISCO 和 ADS 二者都定义了一个从给定 URL 获取 Web 服务描述的简单的 HTTP GET 机制。加强的服务描述资源库会提供服务描述的一个本地高速缓存，不过还提供了附加的搜索能力。对于在企业内部跨越主机的服务描述资源库来讲，服务提供者会向专用的 UDDI 节点发布。咱们能够根据发布到节点的 Web 服务的域的范围，使用几种专用的 UDDI 节点。

内部企业应用程序 UDDI 节点（Internal Enterprise Application UDDI node）节点：公司内部为了进行内部企业应用程序集成而使用的 Web 服务应该被发布到这一类 UDDI 节点。此类 UDDI 节点的范围能够是部门的或公司的单独的应用程序。这些 UDDI 位于防火墙以后，容许服务发布者对他们的服务注册中心和它的访问权、可用性以及发布要求有更多的控制。 
门户网站 UDDI 节点（Portal UDDI node）节点：由公司发布以供外部伙伴查找和使用的 Web 服务能够使用门户网站 UDDI 节点。门户网站节点运行在服务提供者的防火墙以外或之间。这种专用 UDDI 节点只包含公司但愿向来自外部伙伴的请求者提供的那些服务描述。这容许公司保留对他们服务描述的控制、UDDI 节点的访问以及 UDDI 节点的服务质量。此外，经过使用门户网站中固有的基于角色的可见性，企业将服务描述的可见性局限在容许看到它们存在的伙伴中。 
伙伴目录 UDDI 节点（Partner Catalog UDDI node）节点：由特定公司使用的 Web 服务能够被发布到伙伴目录 UDDI 节点。伙伴目录 UDDI 节点位于防火墙以后。此类专用 UDDI 节点只包含来自合法企业伙伴的通过容许的、测试过的、有效的 Web 服务。此类 Web 服务的业务环境和元数据能够被定位到特定的请求者。 
电子市场 UDDI 节点（E-Marketplace UDDI node）节点：对于服务提供者打算用来与其它 Web 服务竞争请求者的业务的 Web 服务来讲，服务描述应该被发布到电子市场 UDDI 节点或 UDDI 运营商节点。电子市场 UDDI 节点由一个行业标准组织或社团托管，包含特定行业中的企业的服务描述。咱们能够要求这些服务支持特定的标准、可搜索元数据、接口或数据类型。电子市场 UDDI 节点通常会过滤掉某些非法的条目，并提供有保证的服务质量。 
UDDI 运营商节点：若是您但愿 Web 服务能够被潜在的新的企业伙伴或服务用户发现，还能够将其发布到 UDDI 运营商节点。IBM、Microsoft 和 Ariba 都支持、复制和托管 UDDI 运营商节点。在发布 UDDI 运营商节点的时侯，若是要让潜在的服务请求者发现服务的话，完整的业务环境和通过深思熟虑的分类法是很必要的。

图 8. 服务发现连续体

图 8 展现了从发布和发现中最静态、最简单的技术到最动态、更复杂的技术的连续体。Web 服务的用户或实现者没必要严格遵循这个发展顺序。

服务发现

Web 服务的发现包括获取服务描述和使用描述。获取过程能够使用各类不一样机制。

获取服务描述

和发布 Web 服务描述同样，根据服务描述如何被发布以及 Web 服务应用程序可能达到的动态程度，获取 Web 服务描述也会有所不一样。服务请求者将在应用程序生命周期的两个不一样阶段，即设计时和运行时查找 Web 服务。在设计时，服务请求者按照他们支持的接口类型搜索 Web 服务描述。在运行时，服务请求者根据他们通信的方式或公告的服务质量搜索 Web 服务。

使用直接发布方法时，服务请求者在设计时对服务描述进行高速缓存，以在运行时使用它。服务描述能够被静态地用程序逻辑表示，并存储在文件或简单的本地服务描述资源库中。

服务请求者能够在设计时或运行时在服务描述资源库（简单的服务注册中心或 UDDI 节点）中检索一条服务描述。查找机制须要支持一种查询机制，它提供按接口类型（基于 WSDL 模板）、绑定信息（即协议）、属性（如 QoS 参数）、所需的中介类型、服务分类法、企业信息等等的查找。

不一样类型的 UDDI 节点会显示能够选择的运行时绑定 Web 服务的数目、多选一的策略，或者调用服务以前必须由请求者做出预选的量。

内部企业应用程序 UDDI 节点和伙伴目录 UDDI 节点将不须要预选来创建对服务的信任。服务选择能够创建在绑定支持、历史性能、服务质量分类、类似性或负载平衡的基础之上。

电子市场 UDDI 节点将有更多的运行时服务能够选择。必须执行某种预选以保证 Web 服务提供者是有价值的伙伴。咱们能够根据价格承诺、开销、通过容许的伙伴列表的出席状况，一样还有绑定支持、历史性能、服务质量分类和类似性来选择服务。

若是服务请求者从 UDDI 运营商节点查询 Web 服务提供者，他们在预选可能的服务提供者时就必须尽量谨慎和认真。应该有一个有效和准确的机制就位，过滤掉无用的服务描述和没有价值的服务提供者。

使用服务描述 
在获取了服务描述以后，服务请求者须要处理它以调用服务。服务请求者使用服务描述生成对 Web 服务的 SOAP 请求或特定于编程语言的代理。该生成能够在设计时或运行时进行，从而对 Web 服务的调用进行格式化。咱们在设计时和运行时能够使用各类工具从 WSDL 文档生成编程语言绑定。这些绑定表示应用程序的 API，并封装了来自应用程序的 XML 消息传递的细节。

在下一部分，咱们将描述基本 Web 服务体系结构的扩展，电子商务须要这些扩展才能使用 Web 服务。

 

在下一部分，咱们将描述基本 Web 服务体系结构的扩展，电子商务须要这些扩展才能使用 Web 服务。

 

14.3.2 真正的电子商务的 Web 服务

虽然对于可互操做的 XML 消息传递来讲 SOAP 和 HTTP 就足够了，并且 WSDL 也足能够传达服务请求者和服务提供者之间须要什么样的消息，可是要覆盖电子商务的所有需求还须要更多的技术。为了彻底支持电子商务，安全性、可靠的消息传递、服务质量、Web 服务协议栈的每一层的管理都须要扩展。

 

安全性

真的须要 Web 服务安全层吗？对于基于消息的体系结构，业界已经有一套现成的并且普遍接受的传输层安全机制，好比，安全套接字层（Secure Sockets Layer，SSL）和网际协议安全（Internet Protocol Security，IPSec），为何还要再加别的呢？为了回答这个问题，咱们不只要研究要求，还将探讨一些只依靠现有的几类传输层安全机制并不能在 Web 服务模型内提供足够的安全性的状况。

一般，Web 服务安全层必须提供如下四个基本的安全性要求：

机密性（Confidentiality）是指信息对没有通过受权的我的、实体或进程的不可用性或不公开性，并保证消息内容不对没有通过受权的我的公开。 
受权（Authorization）是指权限的授予，包括根据访问权限授予访问权和保证发送方被受权发送消息。 
数据完整性（Data integrity）是指数据没有以未经受权的方式或被未经受权的用户不可察觉的改变或者破坏的性质，从而确保消息在传送的过程当中不会被偶然或故意修改。 
原始性证实（Proof of origin）是对消息或数据的发送者进行标识的证据。断言消息由正确标识的发送者传送，而且不会从新发送之前传送过的消息。这一要求隐含了数据完整性的要求。 
因为须要在基于 XML 消息和工做流的动态 Web 服务世界中管理不一样风格的资源访问，因此必须从新评估策略、信任和风险评估这三者相互之间的关系。现有的基于我的身份的访问控制模型正在发展成为基于角色的信任域关系，在该种关系中，可信任的权威机构将执行某项任务的权限授予我的，其行为受该权限限制。Web 服务体系结构定义了须要信息的代理（服务请求者）、提供信息的代理（服务提供者），有时还有提供关于信息的信息的代理（服务中介者、元信息提供者或服务注册中心）。服务中介者常常会收到大量信息请求，这样就须要它可以决定谁想要哪些信息以及请求者是否是已经被授予访问权。基础设施和关系变化迅速，所以有关的策略须要能灵活的容许或拒绝访问。

此外，尽管 XML 发誓要为这样的服务提供通用接口，但 XML 不会提供实现这一梦想所须要的整个基础设施。并且，XML 可能不适合构建整个 Web 服务安全层。目标是要肯定在哪些场合用 XML 格式提供信息以顾及通用数据交换较为重要，以及在哪些场合利用目前已存在于平台之上的现有安全性机制较为重要。

SOAP 信封是用 XML 定义的，从而使您能够向消息添加种类众多的元信息，好比事务 ID、消息路由信息和消息安全性。SOAP 信封由两个部分组成：头和主体。头是把功能添加到 SOAP 消息中的通用机制。SOAP 头元素下一级的全部子元素都叫作头条目。主体是为最终的消息接收方想要的应用数据（如 RPC）准备的容器。所以，能够把 SOAP 看做是在传输层（例如 HTTP）和应用层（例如，业务数据）之间引入的另一层，在此能够方便的传送消息元信息。SOAP 头提供可扩展机制以扩展 SOAP 消息使其能够适用于多种用途。虽然 SOAP 头是向消息添加安全性功能最合理的地方，可是 SOAP 规范自己并无指定这样的头元素。

让咱们仔细的分析一下在 Web 服务模型中现有的各类各样的传输层安全机制为何不够，又为何会须要 Web 服务安全层，以及这个安全层最初是怎样的。

端对端的消息传递。安全传输协议，如 SSL 和 IPSec，能够在传输过程当中提供消息完整性和机密性，但只有在点对点的状况下，它们才会这样作。可是，由于 SOAP 消息是由中介体接收并处理的，因此即使两两之间的通讯链路（communication link）是可信任的，只要在全部的中介体间没有信任关联（trust association），那么安全的端对端通讯就是不可能的。若是有一条通讯链路不安全，那么端对端安全性也会被削弱。就 Web 服务拓扑来看，安全的传输对于 SOAP 消息的端对端安全性是不够的。

中间件的独立性。最终，惟一能提供端对端安全性的方式就在于应用层或中间件层。若是消息在通讯方之间的某点是纯文本，那么就有可能在这点受到攻击。可是，既要在新的或现有的应用中集成加密功能，又不能引入额外的安全性弱点或增长风险，这是一项不容易又不受欢迎的任务。所以，在大多数状况下，人们但愿安全性功能尽量靠近应用，但不在应用自己中构建。

传输的独立性。SOAP 中介体的原意是用来把信息转发到不一样的网络上去，一般使用的传输协议也会有所不一样。虽然全部的通讯链路都是安全的，中介体也是值得信赖的，可是，安全信息（如消息发送者的身份验证）须要被转移到消息路径上的下一个传输协议安全性域，这个过程冗长并且复杂，还可能会致使完整性方面的缺陷。

异步多阶消息传递。传输层安全性保证数据在通讯链路上传输时的安全。它与存储在任何中介体上的数据都无关。在一次传输被接收并解密后，传输层安全性对保护数据免受没有通过受权的访问和可能的改变就不是颇有帮助了。在先存储消息而后转发的状况下（持久的消息队列），消息层保护是有必要的。

由于咱们已经看到安全的传输机制不足以知足 Web 服务开发方法和使用场景的要求，因此咱们的任务就是要建立一个概念性 Web 安全层，包括下列几个组件：

对于网络安全性： 
支持如 SSL 和 HTTPS 等提供机密性和完整性的安全传输机制。 
对于 XML 消息： 
若是通讯没有中间节点，那么发送方能够依靠 SSL 或 HTTPS 来保证用户标识和密码的机密性。 
W3C 正在标准化 XML 数字签名工做的支持。它定义了生成消息摘要与利用发送方的私钥来签发消息的标准 SOAP 头和算法。所以，接收方就能够证实消息发送方的身份。 
对网络内部的、可信任的第三方验证服务（例如 Kerberos）的支持。 
概念性 XML 消息传递模型还必须支持端对端保护消息及其子元素。为了全面的支持，过程和流能力须要被扩展到包括消息交换的安全性特征。应该有一种方式能够定义多段消息和用预期接收方的公钥来保护消息段。须要探讨的一些论题有：

端点负责实现验证及受权。应该支持在企业之间交换信息的合同的任何描述中都要定义哪些雇员能够使用哪些服务。中介体负责审计和服务原始性证实。中介体还可能须要执行验证、受权和数字签名验证以及有效性检查。 
在服务端点的服务描述层中须要定义支持上文论述的安全性问题的面向安全性元数据。这些安全性描述将根据主体或角色定义 Web 服务层访问控制。服务描述将会描述是否支持数字签名、加密、验证和受权以及如何支持它们。 
请求者将使用服务描述的安全性元素来查找服务端点，该端点应符合政策要求及其安全性方法。 
标准组正在调查以下主题和技术。随着这些标准固定下来，它们将会被并入 Web 服务安全性体系结构。

W3C 有一个 XML 加密工做组，帮助提供数据元素的机密性，这样验证交换成为可能。 
W3C 已发布了一个 XML 密钥管理服务（XML Key Management Services，XKMS）的备忘录，来帮助分发及管理在端点之间进行安全的通讯所需的密钥。 
OASIS 已经成立了一个技术委员会来定义受权和验证断言（Authorization and Authentication assertions，SAML）。这将帮助端点接受和决断访问控制权。 
OASIS 已经成立了一个技术委员会来标准化访问控制权的表达（XACML）。这将帮助端点可以以一致的方式解析 SAML 断言。 
随着咱们不断的研究 Web 服务模型中遇到的全部威胁和对策，Web 服务安全性体系结构也在不断发展着。

 

服务质量（QoS）和可靠的消息传递

服务质量垂直塔提供与 Web 服务概念栈每一层有关的信息的规范。对于网络层，这将会暗示能使用各类级别的服务质量的网络。

因为须要经过网络进行可靠的消息传递，因此得根据在这一领域内发送高质量服务的能力来选择网络技术。可靠的消息传递指基础设施把消息一次发送（只发送一次）到预约目标或提供肯定的事件（若是发送没能完成，也许会从新发送到源）的能力。结合网络层与 XML 消息传递将须要支持四个等级的消息传递服务质量：

1. 最佳努力：服务请求者发送消息，服务请求者和基础设施不尝试重发。

2. 至少一次：服务请求者提出请求，并一直重试直到它接收到确认为止。服务提供者重复消息处理不是问题，例如简单的查询处理。实现这可能意味着每一个消息包含惟一的标识。服务请求者以本身肯定的时间间隔重发没有获得确认的消息。服务提供者发出确认消息，为 RPC 响应消息，若是不能处理的话，就发送不能处理的消息异常。

3. 至多一次：这创建在最少一次状况的基础之上。服务请求者试着请求直到它获得回应。象现有的全局惟一标识符（universal unique identifier，UUID）这样的机制容许服务提供者抑制重复屡次的请求，以确保请求不会被屡次执行。例如，请求根据库存目录中的一个号码拿一件东西。

4. 恰好一次：服务请求者提出请求，请求已经执行的回应使其获得保证。恰好一次交换模式排除了重传请求的须要而且适应失效的状况。

可靠的消息传递一般是经过标准设计模式传送的，在该模式中，一件基础设施，有时叫作端点管理器，将会被用来在通讯的每一端协调消息发送。在这种模式中，发送方经过同步请求把消息发给端点管理器。一旦发送到，发送方就能够获得保证，必定会把消息发送出去或引起肯定的事件（例如超时）。端点管理器与其它资源管理器参与本地事务，在一次事务中不只能够由端点管理器对消息进行排队，还有可能在数据库中记录业务过程步骤。应用程序应该指派端点管理器来负责发送消息或者检测发送失败的缘由，它在网络传输层或 XML 消息传递层均可以起做用。

可靠的一次性消息发送的技术和目的都不会引发争议。可是，围绕如何在 SOAP 和 XML 的上下文中支持这项技术已经提出了重要的质疑。关键问题是：应不该该在 XML 消息层上定义必要的协议和消息格式，从而容许可靠的消息发送成为两端应用程序的责任，或者能不能在较低的层（如传输层上）定义协议和消息格式？

在没有支持可靠的消息传递的传输方式的状况下（即互联网），XML 消息传递层将须要在不可靠的基础设施之上支持这些服务质量。端点管理器将须要修改消息，而不是修改消息的传输信封，这样才能成功扮演其角色。应用程序和业务过程的定义将必须考虑全部可能的结果，如拒收消息或在可接受的时间长度内发送不出去。可是，这些定义还须要考虑在发送过程当中发生的中间状态。向业务过程公开这些状态可能会大大增长其定义的复杂程度，但对于定义过程的业务分析师而言并没有太大意义。在一些状况下，使用 XML 消息传递来发送可靠的消息传递格式可能会致使使用现有的这些传输毫无效率。最好能开发一种在互联网上使用的可靠的 HTTP 标准。

在有支持可靠的消息传递的传输方式的状况下（即在企业内部），它能够用于发送可靠的消息，而不是 XML 消息传递层（可能缺省为空实现）。端点管理器将会只修改传输信封，而不会修改 XML 消息。使用可靠的传输使应用程序和业务过程定义不须要知道或处理消息发送的中间状态。

须要在未来进行的几点补充：

互联网的 HTTP 须要加以改进才能提供能够在企业间使用的简单可靠的消息传递。这会带来额外的好处：不止 SOAP，许多种消息类型均可以采用可靠的消息传递。须要 XML 消息传递层处理可靠的消息传递的状况就会随之减小，促进不依赖于网络选择的应用程序开发。 
HTTP 上的 XML 消息传递层也须要处理发布和订阅、消息排序、发送时间限制、优先级和多点传送等等问题。 
服务提供者对可靠的消息传递的质量和实现的支持状况将会在服务描述的绑定信息中定义。

服务实现层（例如，经过事务的或安全的 SOAP 绑定）的服务描述以及接口层（例如，从请求者开始等待来自提供者的响应以后最长通过多久）的其它服务描述中都会关系到服务质量（Quality of Service）信息。人们期待着开发出 WSDL 扩展或新的服务描述层来容许指定其它服务质量和功能的规范。

Web 服务层上的服务质量能够在服务合成和服务流中使用。在为流选择服务或提示流管理器该开始恢复或其它的流时，预期的执行时间、超时值、历史平均执行时间值均可以做为输入。服务描述栈的端点描述层和工做流描述层必须提供这一信息。

Web 服务的服务质量问题和解决方案仍然很紧迫。

 

系统和应用程序管理(Management)

随着 Web 服务成为商业运做的重要因素，就须要对其进行管理。在这种状况下，所谓管理是指专为应用程序定制的或从厂商那里买来的管理应用程序能够发现 Web 服务的基础设施、Web 服务、服务注册中心和 Web 服务应用程序存在性、可用性以及健康度。最使人满意的结果是管理系统还应当可以控制和配置基础设施及组件。

管理概念性 Web 服务栈各层的 Web 服务和 Web 服务模型组件一定是有可能的。对管理的需求能够分红两个集中的领域。第一个领域是用于实现 Web 服务的基础设施的可管理性。主要的考虑应当是确保可用性和提供服务描述、消息传递和网络的关键元素的性能。Web 服务基础设施提供者应当提供这一层上的系统管理。

企业对其本身的基础设施及管理拥有彻底的自主权。可是，当企业在对等基础上相互做用时，就应当提供对网络层、XML 消息传递层、服务注册中心和 Web 服务实现的基本报告和恢复办法。此外，企业向其合伙人提供的管理接口应当是在服务层上操做的，而不是在相对低级的基础设施层上。合伙人应该可以访问到报告操做和请求处理的状态和健康度的接口，但不必定要理解企业如何管理其请求的细节。

对于网络层，现有的网络管理产品几乎支持目前全部的网络基础设施。这些产品应当用于管理企业内部的 Web 服务的网络基础设施。当企业相互做用时，就应该向其合伙人提供有关 Web 服务基础设施可用性的基本报告。影响 Web 服务基础设施可用性的网络可用性应做为因素之一写入报告。

在 XML 消息传递层，协议应该在企业内部由现有的基础设施管理工具来管理。在企业相互做用的状况下，每一个站点都有必要提供协议的基本报告和恢复办法。例如，若是站点 A 支持会话，就该向站点 B 提供可用于查询活跃的 IBM Software Group Architecture Overview Web Services Conceptual Architecture 28 会话以及强行回滚的接口。协议层须要正常的频道与协议和相似对等的控制接口。

管理的第二个方面是 Web 服务自己的可管理性。一些主要的考虑是性能、可用性、事件和使用量度，由于它们将为服务提供者市场收取所提供的服务使用费提供必要信息。

服务描述能够用于宣传可管理性特征和管理需求。这方面的约定正在开发之中。

服务注册中心的任何实现，无论是用于私人消费仍是公共消费，都要求基础设施是可用的、发送承诺的服务质量并可以报告使用状况。这些系统管理元素对于成功采用 UDDI 是十分重要的。

对于 Web 服务应用程序组件来讲，支持管理环境可能会大大增长应用程序的复杂性。因为 Web 服务必须易于开发，因此必须尽量向开发者隐藏这样的复杂性。Web 服务的管理方式要使基础设施能自动提供量度、审计日志、启动和中止处理过程、事件通知和做为 Web 服务运行时的一部分（也就是说，起码是 SOAP 服务器）的其它管理功能。由于基础设施经过观察它所托管的组件的行为不可能收集到全部的信息，因此 Web 服务实现也许会须要向托管它的服务器提供基本的健康度和监督信息。

Web 服务基础设施应该为服务提供一种简单的方式以参与管理和利用管理基础设施。可管理的服务的 WSDL 文档的定义应当是 Web 服务能实现提供经过管理系统访问 Web 服务的管理信息的功能。这一接口可能包括的能力是得到配置和量度数据、更新配置及接收来自可管理的 Web 服务的事件。

Web 服务体系结构的平台独立性使它不适合套用任何一条 Web 服务管理标准。所以，须要有一种基于 Web 服务并且容许 Web 服务与管理系统通讯的方法。为了达到这一目的，还应当定义由 WSDL 文档描述的、可接收来自可管理 Web 服务的事件以及量度更新的管理服务，并使其可用。管理服务的实现技术与 Web 服务无关。可是，对于基于 Java 技术的环境，Java 管理扩展（Java Management Extension，JMX）应该是合乎逻辑的并且厂商不可知的选择。经过使用 JMX 这样的开放标准，对现有的系统管理提供者来讲，要把其目前所提供的产品扩展为包括 Web 服务关键元素的管理应该是很容易的。Web 服务的管理体系结构仍在向前发展。

 

14.4 Web Services 项目实战

14．4．1 Web Services实现

 

本书是重点讲解EJB 3.0的。在理解了Web Services原理以后， 接下来咱们讲解如何使用J2EE和EJB3.0来实现Web Services

 

Web 服务遵循 Java 2 平台，企业版（Java 2 Platform，Enterprise Edition，J2EE）、通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA）以及其它针对与耦合较紧的分布式或非分布式应用程序集成的标准。Web 服务是部署并提供经过 Web 访问业务功能的技术；J2EE、CORBA 和其它标准是实现 Web 服务的技术。

 

J2EE 1.4为使用常规Java类或企业级Java Beans来建立和部署web services提供了一个全面的平台。如下表格给出了J2EE 1.4中包括的web service APIs的细节。 

定义在Java Community Process的JSR 101之下的JAX-RPC，提供了建立和访问web services的Java API,所以它是使用J2EE平台建立和部署web services的“心脏和灵魂”。经过向应用程序开发者隐藏XML类型和Java类型映射的复杂性，以及处理XML和SOAP消息的底层细节，它提供了一个简单的，健壮的建立web services应用的平台。为了引入一个方法调用范式，它提供了两种编程模式:服务器端模式，使用Java类或无状态EJB开发web service 端点，和客户端模式，建立做为本地对象访问web services的Java客户端。JAX-RPC 1.1要求使用SOAP 1.1，而且实现与使用其余技术建立的web services之间的互操做性，好比微软的.NET。实现了J2EE1.4规范的应用服务器，好比OC4J 10.1.3和SUN的Java System Application Sever,提供了对于JAX-RPC的支持。

JAX-RPC的叫法有点用词不当，由于它既支持RPC类型的web services，也支持文档类型的web services。

Web Services部署模型

在J2EE 1.4以前，全部J2EE商家都使用他们私有的部署模型支持web services。J2EE 1.4为Java Web Services定义了部署模型。它为J2EE平台上的web services制定了开发，部署以及服务发布和使用的标准。

有了J2EE 1.4对web services的支持，让咱们学习使用J2EE平台来建造web service的方法。

使用J2EE建立一个Web Service

把web service建立成一个轻便的和可互操做的分布式组件不是一项琐碎的任务。如以前讨论的，你既能够把常规Java类，也能够把无状态EJB部署成web services。常规Java类被打包在一个web模块中，而EJB web services被打包在标准的ejb-jar模块中。

在这两种部署选择中，你会使用哪个呢?

Java 类对无状态EJB:永无止境的争论

你会选择常规Java类仍是EJB做为你建立web service的技术多是一个长期的争论。Java类比EJB更容易开发，它是纯的Java对象，而且它不具备EJB带来的“额外辎重”。可是，EJB提供了几个很好的特色，好比被声明的事务和安全性，所以它使开发者将精力集中于创建商业逻辑，而不须要担忧基础服务架构。EJB 3.0大大简化了设计模型，在它的规范中，EJB看起来就像常规Java类。

使用J2EE 5.0简化SOA的开发

　　使用J2EE建立面向服务的应用程序确实很困难，所以经过使用由JSR 181定义的Web Services 元数据注解，J2EE 5.0将使开发更简单。EJB 3.0和Web Services元数据具备类似的目标，就是向开发者提供亲和力。

　　为了在J2EE 1.4中开发一个简单的Java web service，你须要几个web service定义文件:WSDL，映射文件和几个冗长的标准以及私有的web services部署描述符。Web Services元数据规范使用一种相似于EJB 3.0的缺省配置方法来使开发更简便。Web Services元数据注解处理器(或web services 装配工具)会为你生成这些文件，所以你只须要关心类的实现。

　　当你使用Web Services元数据开发时，这是一个看起来如此简单的Java web service:

package com.ascenttech.ejb30.ws.demo; 
import javax.jws.WebMethod; 
import javax.jws.WebService; 
@WebService(name = "HelloWorldService", 
targetNamespace = "http://hello/targetNamespace" ) 
public class HelloWorldService { 
@WebMethod public String sayhello(String name ) { 
return "Hello” +name+ “ from jws";
} 
}

　　正如我以前提到的，EJB 3.0使用常规Java类简化了EJB的开发。经过利用EJB 3.0和Web Services元数据，开发基于EJB的web services将会变得愈来愈简单。当使用EJB 3.0和web services元数据时，这是一个看起来如此简单的HelloWorld EJB web service。你没必要担忧建立WSDL，部署描述符等等，应用服务器会在部署过程当中生成这些定义文件。

package com.ascenttech.ejb30.ws;
import javax.ejb.Remote;
import javax.jws.WebService;
@WebService 
public interface HelloServiceInf extends java.rmi.Remote{
@WebMethod java.lang.String sayHello(java.lang.String name) 
throws java.rmi.RemoteException;
}

　　以下是EJB 3.0中 HelloWorld EJB的实现类:

package com.ascenttech.ejb30.ws;
import java.rmi.RemoteException;
import javax.ejb.Stateless;
@Stateless(name="HelloServiceEJB")
public class HelloServiceBean implements HelloServiceInf {
public String sayHello(String name) {
return("Hello "+name +" from first EJB3.0 Web Service");
}
}

　　以上例子清楚的代表了经过使用web services元数据和EJB 3.0，服务开发正在变得愈来愈简单。如今，你能够在实现了J2EE规范的应用服务中，好比JBoss Application Server等，开始建立和部署你的web services了。

14.4．2 Web Services 项目实战

14.4.2.1 Web Services的实现
本节使用EJB 3.0 实现一个web Services登陆的例子。下面咱们建立一个工程叫：EmployeeManager。加入用到的EJB 3.0的jar包。

咱们先建立服务器端的实体Bean，这和建立普通的Ejb3.0实体bean是同样的：

package com.ascent.ejb.po;

import java.io.Serializable;

 

import javax.ejb.Remote;

import javax.ejb.Stateless;

import javax.persistence.Column;

import javax.persistence.Entity;

import javax.persistence.GeneratedValue;

import javax.persistence.Id;

import javax.persistence.Table;

@SuppressWarnings("serial")

@Entity

@Table(name = "usr")

 

public class User implements Serializable

{

private Integer id;

private String name;

private String password;

private String description;

@Id

@GeneratedValue

public Integer getId()

{

return id;

}

public void setId(Integer id)

{

this.id = id;

}

@Column(name = "name", nullable = false)

public String getName()

{

return name;

}

public void setName(String name)

{

this.name = name;

}

@Column(name = "password", nullable = false)

public String getPassword()

{

return password;

}

public void setPassword(String password)

{

this.password = password;

}

@Column(name = "description", nullable = true, length = 100)

public String getDescription()

{

return description;

}

public void setDescription(String description)

{

this.description = description;

}

}

接着建立远程接口：

package com.ascent.webservice.bean;

 

import java.rmi.Remote;

import javax.jws.WebMethod;

import javax.jws.WebService;

import javax.jws.soap.SOAPBinding;

import javax.jws.soap.SOAPBinding.Style;

@WebService

@SOAPBinding(style=Style.RPC)

public interface LoginDao extends Remote {

@WebMethod

public boolean isLogin(String name, String password);

}

在LoginDao类中要注意的是Remote接口是要实现的，@SOAPBinding(style=Style.RPC)，Soap的绑定方式也是须要的，否则在客户端是找不到LoginDao 。

下面建立会话bean：

package com.ascent.webservice.bean;

import java.util.List;

import javax.ejb.Stateful;

import javax.ejb.Stateless;

import javax.jws.WebService;

import javax.persistence.EntityManager;

import javax.persistence.PersistenceContext;

import javax.persistence.Query;

@Stateless

@WebService(endpointInterface = "com.ascent.webservice.bean.LoginDao")

public class LoginDaoBean

{

@PersistenceContext

protected EntityManager em;// the manager of entity

public boolean isLogin(String name, String password)

{

// define query sentence

StringBuffer hql = new StringBuffer();

hql.append("from User u where u.name='" + name + "'");

hql.append(" and u.password='" + password + "'");

// create the query

Query query = em.createQuery(hql.toString());

List queryList = query.getResultList();

// if the result is null

if (queryList.size() == 0)

{

return false;

}

// if the user's length greater 1

if (queryList.size() > 1)

{

return false;

}

// return single user

return true;

}

}

至此服务器端的类是建好了，这里又两个问题，须要说明一下

A． 两个类的方法中都没有抛出异常，可不能够抛出呢? 能够。但到实现SOA的时候会有一些问题，就是异常在经axis 经过WSDL2Java 生成后，在程序运行时有可能会出现找不到的情形。因此本文为了让你们在仿照这个例子时都能成功，因此也就抛弃了异常的抛出。

B． 两个类的方法的返回值是基本类型，而不是自定义类型，为何会这样呢，自定义类型能够不能够呢，能够。

如今咱们的webservice的服务器端就已经建立好了，咱们把服务器端的三个类和persistence.xml文件一块儿打包部署到jboss服务器里。包名是：empdEjb。

下面咱们来建立客户端：

package com.ascent.webservice.client;

import java.net.URL;

import javax.xml.namespace.QName;

import javax.xml.rpc.Service;

import javax.xml.rpc.ServiceFactory;

import com.ascent.webservice.bean.LoginDao;

public class LoginClient

{

public static void main(String[] args) throws Exception

{

String userName ="lxl";

String password = "lxl";

URL url = new URL("http://localhost:8080/empdEjb/LoginDaoBean?wsdl");

QName qname =

new QName("http://bean.webservice.ascent.com/jaws","LoginDaoService");

ServiceFactory factory = ServiceFactory.newInstance();

Service service = factory.createService(url, qname);

LoginDao loginDao = (LoginDao) service.getPort(LoginDao.class);

boolean isExists = loginDao.isLogin(userName, password);

if(isExists)

{

System.out.println("hello " + userName);

}

else

{

System.out.println("sorry " + userName + ", you are not user in the system!");

}

}

}

把服务器端发布出去之后，服务器端会自动发布一个webService，而且生成并发布一个WSDL文件，经过访问http://localhost:8080/empdEjb/LoginDaoBean?wsdl这个网址是能够找到的。http://bean.webservice.ascent.com/jaws 和 LoginDaoService 字符串，在客户端程序当中出现了上面两个字符串，它们在你生成的wsdl 文件中有详细的描述。在地址栏里输入http://localhost:8080/empdEjb/LoginDaoBean?wsdl，就能够看到wsdl文件了。这里你所须要作的是按照你本身的状况编写你本身的客户端程序。启动服务器后，在机子上运行客户端程序就能够了。固然你也能够去编写本身的jsp客户端去调用它。wsdl文件的内容以下：

<definitions name="LoginDaoService"

targetNamespace="http://bean.webservice.ascent.com/jaws">

<types/>

<message name="LoginDao_isLogin">

<part name="String_1" type="xsd:string"/>

<part name="String_2" type="xsd:string"/>

</message>

-

<message name="LoginDao_isLoginResponse">

<part name="result" type="xsd:boolean"/>

</message>

-

<portType name="LoginDao">

-

<operation name="isLogin" parameterOrder="String_1 String_2">

<input message="tns:LoginDao_isLogin"/>

<output message="tns:LoginDao_isLoginResponse"/>

</operation>

</portType>

-

<binding name="LoginDaoBinding" type="tns:LoginDao">

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>

-

<operation name="isLogin">

<soap:operation soapAction=""/>

-

<input>

<soap:body namespace="http://bean.webservice.ascent.com/jaws" use="literal"/>

</input>

-

<output>

<soap:body namespace="http://bean.webservice.ascent.com/jaws" use="literal"/>

</output>

</operation>

</binding>

-

<service name="LoginDaoService">

-

<port binding="tns:LoginDaoBinding" name="LoginDaoPort">

<soap:address location="http://lixinli:8080/empdEjb/LoginDaoBean"/>

</port>

</service>

</definitions>

这样一个WebService+Ejb 3.0的例子就实现了。

14.4.2.2 SOA的实现
本例仍是基于前两个例子的基础上的，要保证上面的例子是能正常运行的。

1.WSDL2Java
从名字上能够看出，是把wsdl 转化为java的.在上面的例子中咱们在服务器端生成了一个wsdl文件，如今要作的就是你把那个wsdl文件给别人或者别的公司，让他们根据wsdl中所描述的你所提供的服务，去开发一个应用，来访问你所提供的接口。拿到这个WSDL文件后要作什么呢，to java。咱们来看看怎么to java。

这里，在原来的EmployeeManager工程下面建一个wsdl文件夹，将它放在下面，而后所要作的准备工做是，把包括axis在内的几个jar包找到，设置在你的classpath里面。而后在命令行下运行WSDL2Java。

哪几个jar包？

C:\axis-1_4\lib\axis.jar;C:\axis-1_4\lib\axis-ant.jar;C:\axis-1_4\lib\commons-discovery-0.2.jar;C:\axis-1_4\lib\commons-logging-1.0.4.jar;C:\axis-1_4\lib\jaxrpc.jar;C:\axis-1_4\lib\log4j-1.2.8.jar;C:\axis-1_4\lib\saaj.jar;C:\axis-1_4\lib\wsdl4j-1.5.1.jar;E:\jboss-4.0.5\server\default\lib\activation.jar;E:\jboss-4.0.5\server\default\lib\mail.jar

这是我classpath 里面所设置的几个jar包，后面两个能够不须要，第二个也能够不须要，后俩个只是保证运行的时候没有警告。

1． 将LoginDaoBean.wsdl 放在wsdl文件夹下面。E:\workspace\EmployeeManager\wsdl

2． 在命令行下进入E:\workspace\EmployeeManager\wsdl

3． 执行 java org.apache.axis.wsdl.WSDL2Java LoginDaoBean.wsdl

这个时候，你会发如今wsdl文件夹下面生成了一个目录，它里面包含了几个java类。

LoginDao.java，LoginDaoBindingStub.java，LoginDaoService.java，LoginDaoServiceLocator.java

2 SOA的实现
本节是一个以SOA+struts实现登陆的例子。新建一个web工程，EmployeeWebService，而后将上面生成的几个类放入你的src目录下面，是放整个目录，别只放几个类进去. 构建struts资源。建立struts的过程就不在这里细说了。建立的action内容以下：

package com.ascent.webservice.struts.action;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import javax.servlet.http.HttpSession;

import org.apache.commons.logging.Log;

import org.apache.commons.logging.LogFactory;

import org.apache.struts.action.Action;

import org.apache.struts.action.ActionForm;

import org.apache.struts.action.ActionForward;

import org.apache.struts.action.ActionMapping;

import org.apache.struts.action.ActionMessage;

import org.apache.struts.action.ActionMessages;

import com.ascent.webservice.struts.form.LoginForm;

import com.ascent.webservice.bean.jaws.LoginDao;

import com.ascent.webservice.bean.jaws.LoginDaoServiceLocator;

public class LoginAction extends Action

{

public ActionForward execute(ActionMapping mapping, ActionForm form,

HttpServletRequest request, HttpServletResponse response)

throws Exception {

LoginForm loginForm = (LoginForm) form;

String userName = loginForm.getLoginName();

String password = loginForm.getPassword();

LoginDaoServiceLocator loginDaoServiceLocator = new LoginDaoServiceLocator();

LoginDao loginDao=

loginDaoServiceLocator.getLoginDaoPort();

boolean isExists = loginDao.isLogin(userName, password);

if(isExists)

{

System.out.println("hello " + userName);

HttpSession session = request.getSession();

session.setAttribute("loginName", loginForm.getLoginName());

return mapping.findForward("success");

}

else

{

System.out.println("sorry " + userName + ", you are not user in the system!");

ActionMessages messages = new ActionMessages();

messages.add("login",new ActionMessage("error.login.jsp.loginName.exists"));

this.saveErrors(request, messages);

return mapping.getInputForward();

}

}

}

这里用到的LoginDaoServiceLocator类和getLoginDaoPort()方法就是使用WSDL2Java命令把wsdl文件生成的类。如今就能够打包成叫employee的war文件，运行它。至此，你即可以在浏览器中输入http://localhost:8080/employee/login.jsp，运行你这个SOA的应用了。若是是把服务器端部署到别的机器上，只要把localhost改成相应的ip就能够了。

小结本章首先介绍了目前一个前沿技术：Web Services和面向服务的软件架构（Service Oriented Architecture，简称SOA）。在理解了Web Services原理以后， 接下来咱们讲解了如何使用J2EE和EJB3.0来实现Web Services。