引言

在为 IBM WebSphere® 开发者技术期刊撰写专栏之前，我花费了大量的时间与架构师、开发人员谈论了他们在基于 Web 服务和 SOA 设计以及构建解决方案时所面临的问题。有一些问题和主题一再成为讨论的焦点，因此，我把我个人认为是与 Web 服务相关的 10 大问题列出来与大家分享。 

注意，我没有把它们称为最佳实践，是因为其中有许多问题并不太容易回答。相反，别人对这些问题已经回答过许多次，对于这些内容，我只是想指导您了解一下我比较喜欢的资源，这些资源对该主题进行了较为详细的说明（当然这些资源大多数是一些 developerWorks 文章）。我认为这些主题涉及的领域非常广泛，对于我的某些观点，您可以完全赞同也可以完全不赞同；您也可以添加其他主题。这里为您敞开了一扇大门，欢迎您对我的看法提出意见。

1. 文档/文本 Web 服务到底是什么？

这无疑是我听到的首要问题。事实上，我们在数年前就听到这一问题，令人感到有些惊奇的是，到目前为止仍有人时常提出这一问题，而且对这一问题仍存在一些误解。您可能知道，您可以在 WSDL 定义中定义 Web 服务的调用样式和编码样式。尽管这对构建网络 SOAP 消息的确切方式存在影响，但对整体解决方案、交互样式或编程模型几乎毫无效果。因此我的建议始终是：

不要将使用某个特定的样式作为整个企业范围的规则。使用不同的样式有各种各样的原因，而且您很可能会碰到所有这些样式。 
将该主题看作是一种实现细节，不要让该主题推动或影响您的系统设计。 
请阅读 Russ Butek 撰写的优秀文章 我应该采用哪一种 WSDL 样式？，我认为这篇文章对这些不同之处做出了最好的解释。 

众所周知，使用 Web 服务在性能上会受到一定程度的影响。这几乎不会令人感到惊奇，因为使用 Web 服务时通常会涉及到把使用某种本机格式设置的数据构建为 XML 文档，并在网络中发送此文档。尽管交叉处理（甚至是跨网络处理）始终比本地调用要慢得多，但是如果听到已经对 Web 服务的性能进行了一些改进，您可能会感到惊奇。

有许多技术可以实现这一点；例如，智能 XML 解析器技术（为处理 SOAP 和 XML 构件而进行了高级优化）或 XML 应用程序的出现（如 IBM DataPower®，该应用程序支持硬件级别的 XML 处理）。还有 WebSphere Application Server 中的 Web 服务缓存支持功能，该功能也有助于大大提高性能。事实上，在某些情况下，在最新 WebSphere Application Server 运行时上的 SOAP over HTTP 调用比使用 RMI over IIOP 调用相同的功能要快。

因此，我的建议是应继续对分布式计算应用基本的最佳实践（例如，减少网络通信量等），但开始考虑使用 Web 服务，甚至是用在对性能要求关键的情况中。 

3. 我的 XML 模式不适用于您的产品

在经过了开发 Hello World 样式的测试应用程序之后，您可能会注意到，在您的工具中，XML 模式规范中的某些更高级别的元素或者不受支持或者不能很好地 支持。例如，在 WebSphere 工具中，不存在对 <xsd:choice> 元素的映射，该元素在模式中非常通用。对于 <xsd:group> 也是这种情况。在这些情况下，您可以选择更改模式，也可以选择开发自己的代码来处理基于此模式的 XML。请注意，可能需要手动干预才能将您的模式映射到 Web 服务实现。我建议的两篇文章是：

Web 服务技巧: 将多态性作为 xsd:choice 的备选方法  
如何为 Web 服务选择一种自定义映射技术 
总之，这里没有一次性解决所有问题的万能方法。不过，我们有理由期望这些标准和产品的未来版本也能够提供对高级模式不断增强的支持。

4. UDDI 是什么情况？还有人在使用它吗？

在 Web 服务首次开始流行之后，人们始终指出在任何 SOA 环境中都存在以下三种主要角色： 

服务请求程序 
服务提供程序 
服务代理程序 
代理程序角色一般由遵循 UDDI 标准的注册中心表示。提供公共注册中心可让您创建自己的项和重复使用其他项。WebSphere Application Server 还附带了一个专用 UDDI 注册中心。 

不过，在实际情形中我仍没有看到 UDDI 有多大用处（如果有）。大多数 IT 组织或者构建自己的方式来获取服务定义和连接端点（例如使用 LDAP），或者弃用 UDDI，等待注册中心的新标准。其他还有将专有扩展添加到 UDDI。公共 UDDI 注册中心由 IBM 支持，其他组织已经放弃。

我的预测是，在这一领域，随着时间的推移 UDDI 将由未来的新技术代替。

5. Web 服务的同步

另一个经常讨论的主题是，服务是同步的还是异步的，与编程模型相比，使用的通信协议充当什么角色。例如，假设使用 SOAP over JMS 绑定提供了 Web 服务。使用 JMS（支持异步交互）好像意味着这是一个异步 Web 服务。不过，如果在 WebSphere Application Server 中使用 JAX-RPC 支持，则服务使用者将在返回控制之前等待返回响应。这一原因是，无论是否使用了该协议，JAX-RPC 1.1 都在请求程序和提供程序之间强制执行了一个同步交互。换句话说，用来调用 Web 服务的编程模型通常确定调用的同步性，而不是网络协议。

要构建真正的异步交互，您有两个主要选项。第一个选项是构建一系列交换信息的单向服务，例如使用 WebSphere Application Server V6.1 中的 WS-Addressing 支持。我推荐的一篇 developerWorks 上的文章对此内容进行了详细说明：Web 服务寻址（WS-Addressing）对 SOAP 的隐式影响。

另一个选项是对异步调用使用服务组件体系结构 (SCA) 支持。SCA 提供了一个客户端 API，后者可以将发送的请求与接收的响应分离开。将来，新的 JAX-WS 2.0 标准将提供类似的支持。

6. ESB 或非 ESB

有许多问题都与企业服务总线 (ESB) 这一主题相关：

ESB 究竟是什么？它是一种产品还是一种模式，或者二者兼具？ 
每个 SOA 实现是否都需要 ESB？ 
假设 ESB 集线器，它是否有可能存在瓶颈问题？ 
ESB 中 是什么，ESB 上 是什么？ 
在尝试回答这些问题之前，先为您提供一项关键资源，该资源很好地解释了 IBM 对 SOA 编程模型上下文中的 ESB 的看法：IBM 企业服务总线介绍。 

回答上述问题涉及到整个系列文章，因此我在这里仅提供一些主要解答要点，让您有个初步了解；它们分别是：

企业服务总线是一种体系结构模式。产品可以方便创建该模式的特定实例。 
ESB 的关键特性是分离关注点。像通信协议差异、路由和审核交互、安全性之类的内容可以在实际的服务请求程序和提供程序之外处理。如果不使用此分离方法就能够开始您的解决方案，则不需要立即使用 ESB。不过，在大多数项目中都不会出现这种情况。 
ESB 是一种概念上的集线器，在几乎所有实例中都以分布式方式物理地部署。 
尽管这有时很难说清楚（而且通常由您使用的产品驱动），但谈论的一个较好切入点是考虑基础结构 逻辑和业务 逻辑。与基础结构相关的内容在总线中发生，而与业务相关的内容则不是。 
而且，我不主张这些简单的解答就是对该主题的正当解释，但它们也许为您的理解提供一些帮助。

7. 标头和其他上下文数据

Web 服务设计的一个关键部分是定义进出服务的消息。可以保险地说消息始终有两个关键部分：与业务功能相关的实际负载和上下文数据（如消息 ID、事务或会话 ID、安全信息等）。每个消息协议都为此上下文信息（SOAP 标头、JMS 标头、WebSphere“工作区”等）提供一个位置。问题是没有一个一致的方法或 API 来处理这些不同的机制，而且在大多数实际的 SOA 环境中，您会遇到多个消息传递协议。

最适于您处理这种不同、而且实际上可让您将一个标头结构映射到另一个结构的位置是 ESB（这是使用 ESB 的又一好处；下文至少还会提供一个这样的示例）。此映射很可能需要一些手工工作。 

无论您是如何处理的，关键是要为其尽早规划和设计一个策略，并尽量在您的所有项目中保持一致。

8. 最终需要使用多少 (Web) 服务？

我对该问题的第一反应始终是建议采用一种方法，以便在确定服务的过程中作为指导。其中一个这样的示例是由 IBM 全球业务服务部提倡的面向服务的建模和体系结构 (SOMA) 方法。与 IBM Rational&reg; Unified Process (RUP) 联合在一起通常可促使您使用 SOA 的方法。

第二，不要因为能够包装而将每项 IT 功能都包装在 Web 服务中。有时会使您对此采用整个“自下而上”的方法并使用富工具支持。在大多数（甚至是所有）情况下，采用此方法会导致服务太多，分得太细，没有重用而且与业务不相关。

而且，对此也没有很好的方法！业务分析师和 IT 架构师以适当的细分级别定义和创建适当的服务相当不容易。

9. 作为 Web 服务使用者的遗留应用程序

我们对通过 Web 服务支持现有功能给予了较多的关注。我所了解到的谈论得比较少（即使也同等重要）的是现有应用程序利用新服务的能力。例如，假设公司在对 SOA 采用发展的方法，随着时间的推移创建新服务，并将它们集成到现有环境中。其中一个现有应用程序是使用 RPG 编写的，并运行于 IBM iSeries 系统。现在需要将此应用程序更改为调用其中一个新服务。但负责此系统的开发人员对 SOAP 或 XML 不太熟悉，而且没有基于 RPG 的 Web 服务包。

对此问题的最通用的解决方法是将 SOAP 和 XML 处理委托给 ESB。例如，使用 COBOL 或 RPG 编写的应用程序可以容易地与 WebSphere MQ 队列交换记录格式的消息。已经建立了对这种方法的很好支持，而且已经并且经常使用。像 WebSphere ESB 或 WebSphere Message Broker 之类 ESB 产品可以从 MQ 接收数据，将其转换为 XML，然后处理新 Web 服务的调用。

换句话说，通常较为可取的方法是，将新服务对现有应用程序的影响保持在最低限度，并将协议和消息格式的细节委托给 ESB。

10. “困难在于具体实施”

最近，我访问了法国的 IBM 工业解决方案中心。该中心展示了针对不同行业（如零售业、卫生保健业或银行业）的基于 IBM 的解决方案。展示人员并没有提及任何特定的 IT 产品，而且重点说明了解决方案的实际（业务）功能。但是他不经意地指出一点：“当然，您在这里看到的一切都基于 SOA”。尽管我认为他不是太关注如何针对异步交互在多个协议之间维护 WS-Addressing 标头。

不过，构建、设计和实现 Web 服务和 SOA 会带来许多详细的 IT 技术问题。我们在使用新标准、新编程模型，而且经常使用新产品。创建支持诸如异类平台之间交互的应用程序、企业范围重用 IT 服务并按业务线需求不断更改系统的功能要求，通常会导致不可预见的问题。

因此，下次您的经理进入您的办公室说：“我希望构建一个每个人都说非常容易做到的这种 SOA 解决方案”时，您可以按照我的同事 Greg Flurry 这时爱讲的一句话说：“困难在于具体实施！”

参考资料 

您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
我应该采用哪一种 WSDL 样式？
Web 服务技巧: 将多态性作为 xsd:choice 的备选方法
Web 服务自定义数据绑定——第 1 部分: 如何为 Web 服务选择一种自定义映射技术
Web 服务寻址（WS-Addressing）对 SOAP 的隐式影响
用于实现 Web 服务的 SOA 编程模型，第 4 部分: IBM 企业服务总线介绍

关于作者

  Andre Tost 是 Software Group 的 Enterprise Integration Solutions 组织的一名高级技术人员，他在这个部门帮助 IBM 的客户建立面向服务的体系结构。他专长于 Web 服务技术。在开始从事目前的工作之前，他有十年的时间在 IBM 软件开发工作中担任各种合作伙伴启动、开发和构架的角色，目前他在 WebSphere Business Development 小组工作。他出生于德国，目前在美国明尼苏达州的罗彻斯特居住和工作。在业余时间，他喜欢和家人在一起，并且有空就去踢球或看球赛。

点击查看原文地址：http://www-128.ibm.com/developerworks/cn/websphere/techjournal/0608_col_tost/0608_col_tost.html?ca=drs-

1 、安装和配置 ActiveBPEL 引擎体验版

要使用ActiveBPEL引擎首先要求安装配置servlet容器。ActiveBPEL引擎可以运行在任何标准的servlet容器下。但它主要在Tomcat和Mysql下进行开发，我们也用Tomcat和Mysql作为蓝本进行说明。体验版没有考虑Mysql。

1.1 下载 Tomcat5.x

安装Tomcat (http://jakarta.apache.org/tomcat),并设置环境变量CATALINA_HOME(这个变量在代码和配置中有很多次的应用)。（经过测试的版本为Tomcat 5.0.25）。

1.2 下载 ActiveBPEl

网址为http://www.activebpel.org/download。文件的名字为activebpel-version-type.tar.gz 或activebpel-version-type.zip。版本号是：2.0.0。类型为"src" (source), "bin" (binaries), or "all" (source and binaries)。解压缩下载的文件包，会创建一个名字为activebpel-2.0的目录。可以重新命名，或者移动到任何地方。以下的文档中，简称这个目录为"activebpel"。

1.3 运行脚本 install.bat

执行命令行如下：（Windows）

    C:\> cd \activebpel

    C:\activebpel> install.bat

脚本将把lib下的内容拷贝到$CATALINA_HOME/shared/lib目录下，并且创建$CATALINA_HOME/bpr目录，这就是存放流程的配置文件.bpr的目录。

1.4 更改引擎的配置参数

在aeEngineConfig.xml文件里可以配置一些服务的参数，这个文件在$CATALINA_HOME/bpr。配置的改变是通过BpelAdmin配置页改变的，可以访问http://localhost:8080/BpelAdmin/config.jsp页，并保存配置。

1.5 启动 ActiveBPEL 引擎

要启动ActiveBPEL引擎,只需要启动Tomcat就可以了。

1.6 查看引擎的状态信息

当tomcat启动后，有两个WEB页可以显示服务器的信息

Axis WEB 服务列表http://localhost:8080/active-bpel/services    

ActiveBPEL 引擎管理http://localhost:8080/BpelAdmin/ 

在此页面可以修改引擎的配置参数，可查看帮助页来进行学习。

2 、 ActiveBPEL2.0 引擎的 Mysql 版安装

要使得ActiveBPEL引擎作为一个可持久化的引擎，需要做以下事情：

2.1 装数据库和驱动

安装数据库Mysql和相关的JDBC驱动，并且保证有权限做数据库操作。并且要把文件拷贝到${CATALINA_HOME}/common/lib下。

2.2 建库建表

启动安装好的数据库，执行\activebpel\dist\sql\activebpel\ddl目录下的ActiveBPEL_MySQL.sql语句，在数据库中创建名为ActiveBPEL的数据库，同时创建基本表。

2.3 设置数据源

打开${CATALINA_HOME}\conf目录下的omcat-users.xml文件，增加一个“admin”的角色，<role rolename="admin"/>，然后增加一个角色为admin的新用户。 增加数据源的操作如下：

2.3.1 重启Tomcat,并访问它的管理页http://localhost:8080/admin/ 

2.3.2 输入用户名和密码

2.3.3 按照以下顺序点击左侧的Frame

Server\Service\Host\Context(/active-bpel)\Resources\Data Sources

2.3.4 从 the list of Data Source Actions中选择 "Create New Data Source"           2.3.5按如下数值配置 Data Source信息。（注：在此之前要确保相关的JDBC驱动已经拷贝到tomcat\common\lib下）              

JNDI = jdbc/ActiveBPELDB

Data Source URL = jdbc:mysql://127.0.0.1:3306/ ActiveBPEL

JDBC Driver Class = org.gjt.mm.mysql.Driver

User Name =root

Password =

2.3.6 按保存按钮，并一定注意要提交（上方有一个Commit按钮）。

2.4 修改 aeEngineconfig.xml 文件

   将activebpel/dist/conf下的aeEngineConfig-Persistent.xml文件拷贝到%CATILINA_HOME%\bpr目录下，并且重命名为 aeEngineconfig.xml，原来的aeEngineconfig.xml文件则被覆盖掉。

2.5 ActiveBPEL 的内存管理模式

如果要使ActiveBPEL引擎 转换到应用内存管理的模式，可以把/activebpel/dist/conf下的  aeEngineConfig-InMemory.xml文件拷贝到 %CATILINA_HOME%\bpr目录下。

 2.6 启动

重启tomcat，启动数据库，打开http://localhost:8080/BpelAdmin/页，在Home页可以看到一个“Start Engine”的按钮，启动引擎，当表中的status为running,则表示启动成功。此时，即为以一个可持续的方式启动了ActiveBPEL引擎。

3 、配置发布自己的流程

ActiveBPEL 的流程需要创建一个配置文档(.jar和.bpr文件),并且把他们拷贝到servelet容器中。为了创建这些文件,需要组织一个特殊结构的目录,并创建一两个相应的配置文件,然后才能通过这些目录来创建文档。

3.1 建立目录

创建一个目录,我们假设这个例子叫mybpel,然后按照下边的列表创建它的子目录:

    * bpel

    * META-INF

    * wsdl

    * partners (optional)

    其中wsdl目录中包含了所有定义过的WSDL文件,在META-INFM目录中包含了wsdlCatalog.xml文件, partner definition目录定义了 .pdef文件.以.pdd为后缀的文件是流程的配置描述。

3.2 编写文件

作为一个例子,在各个的目录中放入对应的文件,假设有两个WSDL的服务,BPEL的流程名字为  my_process.bpl,各目录结构如下所示:

    mybpel

        META-INF

            wsdlCatalog.xml

        bpel

            my_process.bpl

        my_process.pdd

        wsdl

            service1.wsdl

            service2.wsdl

除非有.pdef文件,否则不需要partners目录。

3.3 发布应用

     打包并拷贝到servelet容器中。面的命令说明了如何配置BPEL流程到TOMCAT(如果没有partners目录,则把partners从jar的命令行中去掉):

Windows:

    C:\> cd mybpel

    C:\mybpel> jar cf mybpel.bpr *.pdd META-INF bpel partners wsdl

    C:\> cp mybpel.bpr $CATALINA_HOME/bpr

在配置文档中有多个.bpel或.pdd文件是允许的。另外,WSDL文件可以放在任意位置,即使是另一台机器,只要把他们打包,在.pdd文件中说明,让BPEL引擎知道它们在哪就可以。

HongSoft, 工学硕士，AgileFlow开源工作流引擎负责人，多年工作流产品和技术相关经验，曾任CSDN工作流专题主编，BEA广州UserGroup邀请讲座嘉宾，在《程序员》《微型机与应用》等杂志发表技术文章多篇。

1.    调用初始化target,以作为其他target的依赖;

2.    创建classes文件夹;

3.    创建dist文件夹;

4.    编译src下的java文件,把类文件放到classes目录下;

5.    把classes下的文件打包放到dist下, 以.jar为后缀命名;

6.    把配置文件 bpel_example_config.xml拷贝到 CATALINA_HOME/temp下,并允许覆盖.

7.    创建流程bpr文件,把bpel_process目录下的文件打包,除了CVS的文件,以.bpr为后缀命名( bpel.archive ),并放在dist目录下;

8.    拷贝dist目录下的.bpr文件到CATALINA_HOME/bpr下;

9.    创建web services文档.把 web_services下的文件包括META-INF/service.wsdd和class下的除了client下的class文件打包并命名为 * .wsr(ws.archive)放到dist下.

10. 配置web services,拷贝dist目录下的 ws.archive到 CATALINA_HOME/bpr下.

11. 创建jsp包.将jsp下的文件和class目录下的相关的.class文件打包,命名为*.war( jsp.archive )放到dist下.

12. 配置jsp文档,将dist下的*.war文件拷贝到CATALINA_HOME/ webapps下.

13. 执行deploy,配置流程,web service和jsp页.

14. 安装配置文件,并运行单独的没有bpel的web service的客户端测试程序. s执行 ws-test-client,也就是运行org.activebpel.demo.client下的WebServicesTestClient.

15. 安装配置文件,并运行客户端.执行client.运行org.activebpel.demo.client.BPELTestClient文件.

16. 卸载所有的文档.执行undeploy,删除 CATALINA_HOME/bpr下相应的 bpel.archive, ws.archive,删除 CATALINA_HOME/ webapps下的jsp.archive.

17. 删除classes目录和temp目录(注意临时目录的删除问题.);

18. 删除dist目录.

本,分析ActiveBpel启动的装载步骤:

1)进入org.activebpel.rt.tomcat.AeProcessEngineServlet的init方法
2004-9-13 15:08:20 org.activebpel.rt.tomcat.AeProcessEngineServlet init
信息: Active BPEL startup

2)读取配置文件,开始启动bpel引擎
2004-9-13 15:08:20 org.activebpel.rt.tomcat.AeProcessEngineServlet

startOrUpdateBpelEngine
信息: Loading engine config from D:\tomcat5.0/bpr/aeEngineConfig.xml

3)启动一个扫描器,默认每10秒扫描一次指定目录,如果有新的流程定义,则自动将它发

布;启动扫描器的同时,发布WEB应用
2004-9-13 15:08:31 org.apache.catalina.core.StandardHostDeployer install
信息: Installing web application at context path /bpel_example_client_page

from URL file:D:/tomcat5.0/webapps/bpel_example_client_page
2004-9-13 15:08:31 org.apache.catalina.core.StandardHostDeployer install
信息: Installing web application at context path /jsp-examples from URL

file:D:\tomcat5.0\webapps\jsp-examples
2004-9-13 15:08:31 org.apache.catalina.core.StandardHostDeployer install
信息: Installing web application at context path  from URL

file:D:\tomcat5.0\webapps\ROOT
2004-9-13 15:08:31 org.apache.catalina.core.StandardHostDeployer install
信息: Installing web application at context path /servlets-examples from

URL file:D:\tomcat5.0\webapps\servlets-examples
2004-9-13 15:08:32 org.apache.catalina.core.StandardHostDeployer install
信息: Installing web application at context path /tomcat-docs from URL

file:D:\tomcat5.0\webapps\tomcat-docs

4)大约隔了10秒,发布AeEngineAdmin.bpr流程
2004-9-13 15:08:32 org.activebpel.rt.tomcat.AeProcessEngineServlet

createBprDeployment
信息: Deploying new ActiveBPEL deployment

file:/D:/tomcat5.0/bpr/AeEngineAdmin.bpr

5)发布bpel_example.bpr流程
2004-9-13 15:08:33 org.activebpel.rt.tomcat.AeProcessEngineServlet

createBprDeployment
信息: Deploying new ActiveBPEL deployment

file:/D:/tomcat5.0/bpr/bpel_example.bpr

6)发布bpel_example_web_services.bpr流程
2004-9-13 15:08:34 org.activebpel.rt.tomcat.AeProcessEngineServlet

createBprDeployment
信息: Deploying new ActiveBPEL deployment

file:/D:/tomcat5.0/bpr/bpel_example_web_services.bpr

7)BPEL引擎启动完成.

     文档用非正式的 XML 语法描述了下面的 XML 文件 . 它和 BPEL 规范里的规则很相似 , 有一些小的改动 .URIs 命名空间的一般形式 ”some-URI” 代表了一些应用程序或是内容上依赖在 RFC2396 中定义的 URI.

l        在语法上大致符合于 XML 的要求 , 但是它的值表示了数据类型而不是值 .

l        字符被添加到元素中 , 并且属性值像 ”?”(0 或 1 个 ), “*”(0 或多个 ),”+”(1 或多个 ). 字符 ”[” 和 ”]” 用来表示包含了一组与 ”?”,”*”, 或 ”+” 有关的字符 .

l        元素和属性用 ”|” 分隔 , ”(” 和 ”)” 表示语法上的转换 .

l        Schemas 和例子都省略了 <?xml…..?> 预处理的指示 .

1.        *.bpr

*.bpr 是一个 BPEL 流程文档 , 它包含了 BPEL 文件 , 流程配置描述 (.pdd),WSDL, 和 partner 文件等配置流程所必须的文件 .

2.         *.pdd

.pdd 是描述流程配置的文件 , 它告诉 ActiveBPEL 引擎关于 BPEL 流程的相关信息 . 每一个 BPEL 流程都需要创建一个流程配置描述文件 *.pdd. 每一个流程文件 (*.bpel) 都包含它自己的 .pdd 文件 . 它的元素包含了 partner links 和 WSDL 的描述 .

3.        wsdlCatalog.xml

   WSDL 目录提供了让 ActiveBPEL 引擎发现在 .bpr 配置文档中描述的 WSDL 文件 . wsdlCatalog.xml 位于 META-INF 目录中 , 它是对 WSDL 文件位置的描述 .

   位置属性与 WSDL 文件匹配有两种方式 :

l        位置属性在 .pdd 文件的一个 <wsdl> 元素的 wsdlReferences 部分 .

l        位置属性在 WSDL 文件的 <import> 元素中 .

当在配置时加载了一个 WSDL 文件 , ActiveBPEL引擎从.pdd文件中读取WSDL的参数,并且用<wsdl>元素作为WSDL目录的关键字.如果WSDL目录包含了一个匹配的位置,引擎从相应的classpath中加载WSDL文件.如果不存在匹配的目录,引擎认为它的位置是一个绝对的URL,并且尝试从那个位置加载WSDL文件.

Classpath属性表示了WSDL文件在.bpr文件中的位置, 相对的.bpr文件内容的根路径.

4.      .pdef

Partner links 描述了各个 partner 之间的关系 . 关于 partner 定义的文件并不是所有的 BPEL 流程都需要 . 那些应用了主要基于端点参数映射的流程需要 .pdef 文件 . 当需要认证时 , 这个文件用来提供认证信息 .

ActiveBpel有很多的目录和文件配置,它对配置的处理也非常巧妙,我们分析如下:

1)CATALINA_HOME配置
有些朋友对TOMCAT的CATALINA_HOME配置感觉奇怪,其实看看TOMCAT的代码我们就能够

明白;在ActiveBpel中也有同样的配置,它是怎么实现的呢?我们看看

org.activebpel.rt.tomcat.AeProcessEngineServlet的代码就知道了.
org.activebpel.rt.tomcat.AeProcessEngineServlet用来启动bpel服务器和axis服务

器,它是随着tomcat的发布自动装载的,它启动后能够启动线程,该线程能够监听业务流

程的发布.
org.activebpel.rt.tomcat.AeProcessEngineServlet有代码如下:

        public static final String CATALINA_HOME = System.getProperties    

   ().getProperty("catalina.home");
我想您已经知道怎么回事了.

2)ServletConfig配置
我们看看web.xml文件:
<init-param>
         <param-name>bprDirectory</param-name>
         <param-value>bpr</param-value>
</init-param>
   <!-- Specify the engine configuration location, relative to bpr

directory -->
<init-param>
         <param-name>aeEngineConfigFile</param-name>
         <param-value>aeEngineConfig.xml</param-value>
</init-param>
我们再看看代码:
         mBprDirectory = CATALINA_HOME + "/" + aConfig.getInitParameter

("bprDirectory");
         String engineConfigFilename = aConfig.getInitParameter

("aeEngineConfigFile");
上面的aConfig就是在init(ServletConfig aConfig)中声明的,也就是,ActiveBpel启

动时直接从web.xml中读取目录和文件的配置

3)getResourceAsStream的使用
我们看看loadConfiguration方法的代码:
         File file = new File(aConfigFilename);
         ClassLoader cl = Thread.currentThread().getContextClassLoader();
         if(file.exists())
         {
            // load the configuration xml
            in = new FileInputStream(file);
         }
         else
         {
            log.info("File " + aConfigFilename + " doesn't exist loading

from default classpath " + DEFAULT_BPEL_ENGINE_CONFIG);
            // load the default configuration file if not in bpr directory
            in = cl.getResourceAsStream(DEFAULT_BPEL_ENGINE_CONFIG);
         }
如果您对ClassLoader比较熟悉,应该不难看懂上面的代码.如果/bpr/下面有配置文件,

则从该目录下读;否则,该文件可以被打包放到包里面了,那么从包中读取配置文件.

2003 年 8 月 01 日

商业流程执行语言BPEL4WS(Business Process Execution Language For Web Services)是专为整合Web Services而制定的一项规范标准。它从本质上来说是IBM的WSFL和Microsoft的XLANG的结合物，目前已经成为业界标准。WSFL 支持图形化的流程，而XLANG在结构化构造方面有独到的方法，而BPEL4WS正是吸取了两者的优点，同时摒弃了一些复杂繁琐的部分，形成了一种较为自然的描述商业活动的抽象高级语言。
引言

在本文的前三篇文章中(商业流程开发新纪元--BPEL4WS语言介绍，第1部分：特点介绍及使用技巧提示，第2部分：如何有针对性的利用RUP来规范BPEL4WS系统开发流程，BPEL4WS语言介绍，第3部分：利用UML对BEPL4WS系统进行建模)，已经向读者介绍了BPEL4WS语言的主要特点，BPEL4WS主要元素使用技巧以及利用外部Web服务的一些技巧；在软件过程方面着重介绍了在利用BPEL4WS语言进行系统开发时如何合理利用现有成熟软件过程RUP(Rational Unified Process)进行有针对性的系统开发；在BPEL4WS系统建模方面简要介绍了在开发过程中为什么要利用UML(Unified Modeling Language)对BPEL4WS系统进行建模以及如何用UML来构架BPEL4WS系统的体系结构。在本中将向读者介绍如何有针对性的利用UML核心架构对BPEL4WS系统进行建模。希望本文的内容会对您对UML核心架构的理解有所帮助。 

（注：对于BPEL4WS的基本语法介绍以及UML的详细语言规范由于篇幅原因并没有包括在本文中，读者可以参阅附录中的相关资料介绍； 
在文中出现的"BPEL4WS系统"与"用BPEL4WS语言开发的商业系统"同义） 

正文

根据不同系统的不同性质，一些模型可能比另一些模型要重要。例如，对于数据密集型系统，表达静态设计视图的模型将占主导地位。对于图形用户接口密集型系统，静态和动态用况视图就显得相当重要。在实时系统中，动态进程视图尤为重要。而在多层分布式系统中，尤其是在BPEL4WS系统中，实现模型和实施模型相对于其它系统来说就变得更加的重要。 

在利用BPEL4WS语言进行系统开发的过程中利用UML进行建模的方法和对普通的软件系统进行建模的方法大体上是相同的，但由于BPEL4WS系统本身的特点决定了只有针对性地进行建模活动才能取得更有价值的成果，再加上利用UML建模的过程实际上就是在遵循UML Specification的基础上，利用UML提供的一些核心要素对要开发的系统进行可视化、详述、构造和文档化的过程，所以我们可以针对UML的三个基本核心要素(基本构造块、规则、公共机制)来结合BPEL4WS语言的特点来有针对性地进行建模活动。而如何有针对性的利用UML核心架构对BPEL4WS系统进行建模成为了一个重要的问题，在下面的内容中将会较细致的介绍UML中主要元素的特点和如何在建模活动中有倾向性地向BPEL4WS系统靠拢。 

<一>基本构造块

在UML中的基本构造块可以划分为主要的三大类，每一类又可以细分为上图所示的许多小类。对于一个小型的项目来说，也许我们只会用到这些元素的一部分，但对于一个规模较大、较复杂的项目，特别是像BPEL4WS系统这样的多层分布式系统来说，在我们建模的过程中，基本上会用到上面的每一种构造块，只是侧重点要根据项目的特点的不同而定了。在UML的构造块中，我们利用"事物"可以对BPEL4WS模型中最具代表性的成分进行抽象；利用"关系"把BPEL4WS系统中的各种相关事物结合在一起；利用"图"来聚集整个BPEL4WS系统中的相关的事物。接下来让我们来分析每一类基本构造块的特点，以及如何有针对性地利用它们对BPEL4WS系统进行建模。 

<1.1>基本构造块中的4种事物：

<1.1.1>结构事物（Structural thing）：是整个UML模型中的名词。它们通常是模型的静态部分，在BPEL4WS系统中，我们可以利用结构事物来描述一些重要的概念或者物理元素，我们必须能够捕捉到整个BPEL4WS系统中存在的所有的相关的结构事物，只有在完整的系统语义的基础上，我们才可能进一步地发现和得到系统的动态特性。在利用UML建模时，我们一共可以用到7种结构事物，它们分别是： 

类(Class):是对一组具有相同属性、相同操作、相同关系和相同语义的对象的描述。我们利用一个类可以实现一个或多个接口。在BPEL4WS系统中，类是最基础的系统构造部分，值得我们多加注意的是我们应该把外部服务抽象成类的概念来进行建模活动，这在后面的类图介绍中会进行解释。 

接口(Interface):是描述了一个类或构件的一个服务的操作集合。因此，接口描述元素的外部可见行为。一个接口可以描述一个类或构件的全部行为或部分行为。值得我们注意的是，我们只是利用接口定义了一组操作的描述（即特征标记），而不是操作的实现，所有具体的实现都由类或者构件来完成。在BPEL4WS系统中，如果外部的Web服务提供给我们的服务是"暗盒操作"，也就是我们不知道操作的具体内部流程，我们就可以把这些操作抽象到某个接口中，而这些接口由那些抽象成类的Web服务来实现。 

协作(Collaboration):定义了一个交互，它是由一组共同工作以提供某协作行为的角色和其他一些相关元素构成的一个群体，这些协作行为从范围上来说要大于所有元素的各自行为的总和。因此，协作是有结构、行为和维度的。要注意的一点是，一个给定的类可以参与几个协作，而这些协作表现了系统构成模式的实现。我们在对BPEL4WS系统建模的时候，在抽象出系统相应的用况之后，就要用协作来实现这些用况，用况就好比是一篇论文的前言，告诉了我们这篇论文是讲什么的，而协作就是具体的内容。 

用况(Use case):是对一组动作序列的描述，系统执行这些动作序列将产生一个对某个特定的参与者有特定价值的结果。我们利用用况来对BPEL4WS模型中的行为事物结构化，我们通常通过协作来实现某一个用况。如果想建立一个完善的BPEL4WS系统模型，用况可以说是至关重要的部分，因为所有的用户需求我们都要在用况中体现出来，可以说用况是开发人员与用户进行交互的窗户，在系统的测试阶段，测试用例的创建也要以用况为基础，不论是BPEL4WS系统还是其他系统，用户满意度才是判断这个系统是否成功的最重要的因素。 

主动类(Active class):是这样的一种特殊的类，其对象至少拥有一个进程或线程，并且它能够启动控制活动。主动类的对象所描述的元素的行为与其他元素的行为并发，除了这一点之外，它和类是一样的。由于BPEL4WS流程本身就具有主动类的特征（每一个流程拥有自己的进程，并能自动启动控制活动），所以我们可以把流程本身抽象成主动类。 

构件(Component):是整个系统中物理的、可替代的部件，它遵循且提供一组接口的实现。在一个系统中，你将遇到不同类型的部署构件，如 C O M +构件和Java Beans，以及在开发过程中所产生的制品构件，如源代码文件。通常构件是一个描述了一些逻辑元素（如类、接口和协作）的物理包。对于构件在BPEL4WS系统中的使用，我们可以把每一个为我们提供Web服务的服务站点抽象成是一个特殊的"构件"，具体介绍在构件图的介绍中说明。 

节点(Node):是在运行时存在的物理元素，它表示了一种可计算的资源，它通常至少有一些记忆能力和处理能力。一个构件集可以驻留在一个节点内，也可以从一个节点迁移到另一个节点。在一般的系统建模时，如在C/S模式的时候，节点往往就是客户机和服务器；而在N-Tier模式时，也就是多层架构时，除了客户机和服务器外，还要将应用服务器，也就是中间层建模为相应的节点。在BPEL4WS系统中，比较特殊的一点是我们应该将一个服务提供商抽象成是一个节点，在这个特殊的节点中提供了一系列的Web服务，更详细的内容在实施图的说明中介绍。 

<1.1.2>行为事物（Behavioral thing）：是UML模型的动态部分。我们可以把它们看作是模型中的动词，它们描述了系统中存在的行为动作。在利用UML对BPEL4WS系统进行建模时，共有两类主要的行为事物可以供我们使用： 

交互(Interaction):是这样一种行为，它由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列（由一个消息所引起行为）和链（对象间的连接）。 

状态机(state machine):是这样一种行为，它描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及到一些其他元素，包括状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。 

在这里，由于篇幅关系，只介绍了行为事务的基本概念，在我们对BPEL4WS系统建模的时候，对于行为事务的建模是体现在相应的系统图模型中，这在下面的图模型说明中会有介绍。 

<1.1.3>分组事物（Group thing）：是UML模型的组织部分。它们一般是由整体系统分解下来的小的功能集合。在所有的分组事物中，最主要的分组事物是包，而在对BPEL4WS系统建模时我们利用最多的也是包。 

包(Package):是把元素组织成组的机制，这种机制具有多种用途。结构事物、行为事物甚至其他的分组事物都可以放进包内。包不像构件（仅在运行时存在），它纯粹是概念上的（即它仅在开发时存在）。在BPEL4WS系统中，包的使用比较自由，我们可以根据自己的需要划分系统中的各个部分，例如可以按外部Web服务的功能来划分这些Web服务。 

(注：包是用来组织UML模型的基本分组事物。它也有变体，如框架、模型和子系统等（它们是包的不同种类）。在JAVA中已经直接支持了包的概念，而在C#中虽然没有明确提出包的概念，但是C#中的命名空间概念实际上与包的概念是一致的) 

<1.1.4>注释事物（Annotation thing）：是UML模型的解释部分。我们可以用注释事物来描述、说明和标注整个UML模型中的任何元素。有一种最主要的注释事物，我们称为注解。 

注解(Note)：是一个依附于一个元素或一组元素之上，对它进行约束或解释的简单符号。注解可能是大家最容易忽视的部分，当我们编码的时候，程序注释的重要性我想大家都知道，而当我们对BPEL4WS系统或其他系统建模的时候，确容易忘掉为我们建立的系统模型元素加上详细的注释，对一个中小型系统来说，也许并不会有太大的危害，而对于一个复杂的系统模型来说，也许一时的偷懒会造成以后致命的潜伏的错误，所以宁可在建模时放慢进度也要争取建立一个完备的系统模型，为以后的review和测试阶段打下良好的基础。 

<1.2>基本构造块中的4种关系：

依赖（Dependency）： 
是两个事物之间的一种语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。在BPEL4WS系统中，我们要善于挖掘系统中存在的依赖关系，如在BPEL4WS系统中，外部Web服务之间就可能存在着依赖关系。 

关联（Association）： 
是一种结构关系，我们用它来描述一组链，链是对象之间的连接。不论是对BPEL4WS系统还是其他系统来说，关联关系恐怕是我们在建模时用到的最多的一种关系，系统元素之间的关系如果不能明显的由其他三类关系来表示，都可以抽象为关联关系。 

(注：聚合是一种特殊类型的关联，它描述了整体和部分间的结构关系) 

泛化（Generalization）： 
是一种特殊/一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象，也就是我们在面向对象学中常常提起的继承。用这种方法，子元素共享了父元素的结构和行为。在BPEL4WS系统中，泛化关系的使用并没有什么特殊的地方，只要注意能清楚明了地刻画出系统相关元素之间所存在的继承关系就行了。 

实现（Realization）： 
是UML元素之间的语义关系，其中的一个元素制定了由另一个元素保证执行的契约。在图形上，我们可以把实现看作是泛化和依赖关系两种图形的结合体。 

在BPEL4WS系统中，一般来说，我们会在两个地方需要使用实现关系，一是用在接口和实现它们的类或构件之间，另一种是用在用况和实现它们的协作之间，这些地方都是具有BPEL4WS系统特性的地方，大家在建模的时候要多加注意。 

<1.3>基本构造块中的9种图：

类图（Class diagram）：展现了一组对象、接口、协作和它们之间的关系。 
在对面向对象系统的建模中所建立的最常见的图就是类图。我们可以用类图来给出系统的静态设计视图，我们可以通过主动类的类图给出整个系统的静态进程视图。类图恐怕是大家最熟悉使用的一种图形了，因为自从有了面向对象的理论以后，类和类图就成为最基础的面向对象理论。在对BPEL4WS系统建模的时候，开始时最困难的部分可能就是识别系统中到底有哪些相关对象，也就是抽象出有哪些类，对于识别对象并抽象出类的方法，由于篇幅关系在这里就不详细说了，大家可以参看清华大学出版的一本很有名的书《面向对象的分析》（邵维忠，杨芙清），很实用的教材。在这里要提醒大家注意的是，在BPEL4WS系统中，应该把所有的外部Web服务抽象成类（用版类Stereotype扩展过的），而对于流程本身，也应该抽象成类的概念，这样所有BPEL4WS系统的元素都被抽象成类这种有固定形态特点的事物，这样就为以后的系统动态分析打好了基础。 

对象图（Object diagram）：展现了一组对象以及它们之间的关系。 
对象图描述了在类图中所建立的事物的实例的静态快照。虽然对象图也给出了系统的静态设计视图或者静态进程视图，但它们都是从真实的或原型案例的角度建立起来的。对于BPEL4WS系统的建模来说，对象图并不是重点，因为过细致的对象图会降低系统模型的抽象程度，这是不利于我们从更高的层次理解整个系统的架构和运作，但有的时候对象图也是必不可少的，特别是当我们要表示出位于某个确定状态的类对象之间的关系时。 

用况图（Use case diagram）：展现了一组用况、参与者（一种特殊的类，可以为用户或者是别的系统）及其它们之间的关系。 
我们通常利用用况图给出整个系统的静态用况视图。这些图对于系统的行为进行组织和建模是非常重要的。值得注意的是，在用况图中，我们应该很好地利用用况之间的泛化关系，也就是继承关系，这样可以更清晰地把一个较复杂的商业用况划分为几个较简单的用况（父用况和子用况），这对于我们在BPEL4WS系统中理解一些复杂的商业行为很有好处。 

顺序图（Sequence diagram）： 
在系统中，顺序图是一种强调消息的时间顺序的交互图。对于BPEL4WS系统的建模来说，顺序图应该说是最重要的一种图，虽然顺序图和协作图是同构的，也就是说是可互相转化的，但由于顺序图强调了时间上的概念，这与一个实际商业流程的运作是完全一致的，再加上BPEL4WS系统中所调用的各种外部Web服务在顺序图中可以很好的、形象的表现出来，所以当我们要对具体的商业流程建模的时候，顺序图是我们最好的选择。 

协作图（Collaboration diagram）： 
协作图也是一种交互图，不过它主要强调了收发消息的对象的结构组织的交互图。对于一般的系统建模（如MIS系统）来说，协作图与顺序图是一样重要的，而对于BPEL4WS系统来说，由于我们所关心的商业流程是有时间顺序的，所以我们应该先考虑创建完备的顺序图，对于一些用顺序图表示不太适合的交互（如涉及到复杂的消息传递），我们可以用协作图将其表示出来。 

(注：在这里，我要对交互图作一些补充说明，首先，顺序图和协作图都是交互图，而且顺序图和协作图是同构的，这也就意味着它们是可以相互转换的。另外一点需要注意的事，我们在系统建模的时候应该使交互图专注于整个系统的动态视图，这是因为UML中的交互图本质上展现了一种交互，而这种交互是由一组对象和它们之间的关系组成的，包括了在它们之间可能发送的消息) 

状态图（Statement diagram）：展现了一个状态机，它由状态、转换、事件和活动组成。 
状态图也主要专注于整个系统的动态视图，系统的状态图对于接口，类或协作的行为建模尤为重要，而且它还强调了对象行为的时间顺序，这一点是非常有助于对反应式系统建模的，也就是说对BPEL4WS系统建模来说是非常重要的（因为BPEL4WS系统实际上也带有一部分反应式系统的特点）。在为BPEL4WS系统所建立的模型中，状态图最重要的用处就是为流程本身的状态以及外部Web服务的状态建模。随着流程的运行，系统各个部分的状态可能都会发生变化，我们一定要能捕捉到这些变化，并把这些变化体现在相应的状态图中。 

活动图（Activity diagram）：是一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的流程。 
活动图在专注于系统的动态视图的同时，强调了对象间的控制流程，这对系统的功能建模特别的重要。在利用活动图对BPEL4WS系统建模的时候我们要注意，最好能把商业流程中发生的一系列商业事件（如客户身份认证，信用卡号认证等）以一一对应的关系对应到流程的活动图中的每一个活动；如果有必要的话，再对每一个活动进行更深层次的分析，构建出每一个活动本身的交互图和活动图。 

构件图（Component diagram）：展现了一组构件之间的组织和依赖。 
对于构件图，我们首先要知道的是构件图不能反映出系统的动态特性，构件图专注于描述系统的静态实现视图。在我们对任何一个系统建模时（当然包括BPEL4WS系统），构件图不可避免的要与类图相关联，因此我们通常把构件映射成一个或多个类、接口或协作。对于一般的系统来说，大部分的构件都存放在本地系统上，我们可以从大体上把这些构件分为两类，一类是"内部构件"，也就是自己开发的构件；另一类是"外部导入构件"，也就是通常所说的第三方构件，而对于BPEL4WS系统来说，由于它本身的特殊性（对外部Web服务的依赖性）决定了我们在建模时一定要用构件图完整地体现出整个流程所涉及到的所有的外部Web服务以及本地提供的Web服务，我们可以把每一个为我们提供Web服务的服务站点抽象成是一个"构件"，而在这个特殊的"构件"中为我们提供了一系列的Web服务功能。 

实施图（Deployment diagram）：展现了对运行时处理节点以及其中的构件的配置。 
通过构造系统的实施图，我们就可以构造出整个系统体系结构的静态实施视图。在我们对BPEL4WS系统建模的时候，实施图往往都要与构件图相关，通常在系统的每个节点中都包含一个或多个构件。我们可以扩展实施图中节点的概念，在扩展出的新的节点的概念中，一个节点不一定就是一个处理节点，我们可以将一个服务提供商抽象成是一个节点，而一个服务提供商可能会为我们提供几种不同的Web服务（即几个不同的服务站点），那这些服务站点就可以被抽象为"构件"，这样就可以很好的与构件图结合起来对BPEL4WS系统建模。 

(注： 在对BPEL4WS系统建模时，并不限定仅使用这9种图，但这9种图在实际应用中是最常用也是最方便使用的) 

<二>规则

在对BPEL4WS系统建模的时候，我们不能简单地把UML构造块按随机的方式放在一起。像任何语言一样，UML有它自身的一套规则，这些规则描述了一个结构良好的模型看起来应该像什么。对于为BPEL4WS系统所构建的模型，我们要求这个模型应该在语义上是前后一致的，并且与所有的相关模型协调一致。在建模的时候，UML有用于描述如下事物的语义规则： 

命　　名：为事物、关系和图起名。 

范　　围：给一个名称以特定含义的语境。 

可见性：怎样让其他人使用或看见名称。 

完整性：事物如何正确、一致地相互联系。 

执　　行：运行或模拟动态模型的含义是什么。 

值得注意的一点是，当我们对BPEL4WS系统进行建模时除了要建造一些结构良好的模型以外，我们在系统的开发期间所建造的模型往往需要发展变化，并可以由许多人员（所有的项目涉及人即Stakeholders）以不同的方式、在不同的时间进行观察。由于这个原因，下述的情况是常见的，即我们不仅要建造一些结构良好的模型，也要建造一些这样的临时模型： 

省　　　略：隐藏某些元素以简化视图。 

不完全性：可以遗漏某些的元素。 

不一致性：不保证模型的完整性。 

在BPEL4WS系统开发的整个生命期内，随着系统细节的展开和变动，不可避免地要出现这些不太规范的模型。但我们应该时刻牢记，我们的任务是专注于BPEL4WS系统中最重要的分析、设计和实现，而为了解决这些重要问题，将促使我们不断地修改我们所建立的模型、完善我们所建立的模型，这样随着时间的推移和系统设计的深入，我们为BPEL4WS系统所建立的模型将具有更好的结构。 

 <三>公共机制

在UML中有4种贯穿整个语言且一致应用的公共机制，因此使得UML变得较为简单；而特别值得我们注意的是，对于BPEL4WS系统的建模来说，这些机制显得尤为的重要，如果没有这些公共机制，我们是不可能构建出语义上完备的BPEL4WS系统的。这4种公共机制分别是： 

<3.17>详述：在建模的过程中，我们利用UML的图形表示发来对BPEL4WS系统进行可视化，利用UML的详述来描述BPEL4WS系统的细节问题。在文章前面提到的注释的问题实际上就是详述机制的问题，一个完备的BPEL4WS系统不仅要包括完整的系统模型元素，还要有详细的详述才能称得上是一个健壮的系统。 

<3.2>修饰：UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节加到这个符号上以扩展其含义。在BPEL4WS系统中，我们可以较自由的对系统中的各个元素进行修饰以扩充其含义，但要注意要保证这种扩充是在受控制的范围中。 

<3.3>通用划分：在对BPEL4WS系统建模时，我们可以采用两种通用划分的手段，一种是对类和对象的划分（类是一个抽象，而对象是这种抽象的一个具体形式）；第二种是对接口和实现的分离（接口声明了一个契约，而实现则表示了对该契约的具体实施，它负责如实地实现接口的完整语义）。 

<3.4>扩展机制：扩展机制是对已有的UML语义按不同系统的特点合理地进行扩展。 

UML扩展机制包括： 

<3.4.1>构造型（Stereo type）： 
我们在对BPEL4WS系统建模的时候，会发现现有的UML构造块不能完整无歧义地表示出BPEL4WS系统中的每一元素，因此我们可以利用构造型来扩展UML的词汇，我们可以利用它来创造新的构造块，这个新创造的构造块既可以从现有的构造块派生，又专门针对我们要解决的问题。 

<3.4.2>标记值（Tagged value）： 
利用标记值，我们可以扩展UML构造块的特性，我们可以根据我们的需要来创建详述元素的新元素。 

<3.4.3>约束（Constraint）： 
如果我们需要对UML构造块的语义进行扩展，我们就可以使用约束机制，这种机制使我们可以增加新的规则和修改现有的规则。 

(注：由于BPEL4WS系统本身所固有的特点，决定了在我们对其进行建模时不得不对UML中的一些部分进行扩展，但有一点我们必须要注意，那就是我们一定要让我们对UML所作出的扩展保持在我们的控制范围内，简单的说就是我们只可以以受控的方式来进行扩展，而不能任意地、无限制地进行扩展，我们必须保证我们利用UML扩展机制对BPEL4WS系统所作的建模活动是可理解、可控制的，如果任意地扩展，就会使我们在对系统进行建模的过程中偏离利用UML建模的真正目的--信息交流) 

给开发者的建议

"不积跬步无以至千里"，学习掌握UML的过程是一个漫长的过程，有时还会觉得有些乏味，但当你真真掌握了它并灵活的运用它在你的工作中的时候，你就会发现你不曾想到的乐趣。现在UML2.0已经问世了，而BPEL4WS语言也有了新的版本，它们都添加了很多的新的东西，也去掉了一些旧的东西，但我相信本文的内容对于新的Specification来说也是同样适用的，对于新技术新知识我觉得我们应该抱着一种积极的态度去学习和掌握它们，而不应该处于一种被动的状态，越早行动起来就能越早的收到回报，千万不要犹豫不决，就像《谁偷了我的奶酪》中说的那样，让我们都作一只敢于迎接变化的小老鼠吧！ 

结束语

在本文中向读者简要介绍了有关如何有针对性的利用UML核心架构对BPEL4WS系统进行建模的问题。在下一篇文章中，我将会在简要的介绍一些有关商业系统和商业流程的特点之后，为大家举一个实际的例子(贯穿分析，设计和实现)来阐明有关利用BPEL4WS进行系统开发和商业流程架构时应注意的细节问题，例子可能不长，但会涵盖UML中最重要的部分。 

参考资料 

BPEL4WS语言规范 v.1.1 
http://www.ibm.com/developerworks/library/ws-bpel/ 

UML(Unified Modeling Language)语言规范 v.1.5 
http://www.omg.org/technology/documents/formal/uml.htm 

RUP(Rational Unified Process)语言规范 
http://www.rational.com/products/rup/index.jsp 

2003 年 8 月 01 日

商业流程执行语言BPEL4WS(Business Process Execution Language For Web Services)是专为整合Web Services而制定的一项规范标准。它从本质上来说是IBM的WSFL和Microsoft的XLANG的结合物，目前已经成为业界标准。WSFL 支持图形化的流程，而XLANG在结构化构造方面有独到的方法，而BPEL4WS正是吸取了两者的优点，同时摒弃了一些复杂繁琐的部分，形成了一种较为自然的描述商业活动的抽象高级语言。
在本文的前两篇文章中(商业流程开发新纪元——BPEL4WS语言介绍， 第1部分：特点介绍及使用技巧提示 第2部分：如何有针对性的利用RUP来规范BPEL4WS系统开发流程)，已经向读者介绍了BPEL4WS语言的主要特点，BPEL4WS主要元素使用技巧以及利用外部Web服务的一些技巧，在软件过程方面着重介绍了在利用BPEL4WS语言进行系统开发时如何合理利用现有成熟软件过程RUP(Rational Unified Process)进行有针对性的系统开发。在本文中将继续向读者介绍在我们的实际开发过程中如何合理利用UML(Unified Modeling Language)对BPEL4WS系统进行建模活动，由于篇幅限制，我将有关利用UML对BPEL4WS系统建模的介绍分为了三部分，本文是第一部分，在接下来的两篇文章中会介绍UML核心架构的使用问题并会给出一个简化的建模实例。 由于水平有限，在文章中不免会有错误和不足的地方，欢迎大家批评指正，在此仅希望大家在阅读完本文的内容后会对如何利用UML对BPEL4WS系统建模有一个概念上的理解，也希望能对您的工作有所帮助。 

引言

本文主要介绍的有2个方面的内容； 

为什么要利用UML对BPEL4WS系统进行建模。 
用UML来构架BPEL4WS系统的体系结构。 

（注：对于BPEL4WS的基本语法介绍以及UML的详细语言规范由于篇幅原因并没有包括在本文中，读者可以参阅附录中的相关资料介绍；在文中出现的"BPEL4WS系统"与"用BPEL4WS语言开发的商业系统"同义）

 回页首 
 

正文

<一>为什么要利用UML对BPEL4WS系统进行建模 

一切事情都是有因有果的，为了更好的学习如何对BPEL4WS系统建模，还是在一开始先让我们来看看我们之所以要利用UML对BPEL4WS系统进行建模的原因是什么，也就是看看用UML对BPEL4WS系统建模的重要性在哪里。

为什么要对BPEL4WS系统建模 

建模是开发优秀软件的所有活动中的核心部分，其目的是把所要设计的结构和系统的行为沟通起来，并对系统的体系结构进行可视化和控制。我们对一个正在构建的BPEL4WS系统建模是为了能更好地理解它，而且对BPEL4WS系统建模还有可能为我们提供简化系统和复用组件的机会，同时我们为BPEL4WS系统建模可以更好的管理系统中潜在的风险。不成功的软件项目失败的原因各不相同，而所有成功的项目的成功原因在很多方面都是相似的。任何一个成功的软件组织有很多成功的因素，其中共同的一点就是对建模的采用。BPEL4WS系统模型是对现实商业流程的简化，BPEL4WS系统模型为我们提供了整个系统运作的蓝图。在BPEL4WS系统模型中既应该包括详细的计划，也应该包括从很高的抽象层次考虑系统的总体计划。通常来说，一个好的模型应包括那些与系统有紧密关系的主要元素，而忽略那些教松散的次要元素。每个BPEL4WS系统都可以从不同的方面用不同的模型来描述，而且每个模型都是一个在语义上闭合的系统抽象。我们所建立的模型应该既可以体现出BPEL4WS系统的结构性，强调整个系统的组织特性；同时也应该可以体现出BPEL4WS系统的行为性，即强调系统的动态方面。

也许有的开发者会问，BPEL4WS使用起来并不复杂，而且也没有复杂的数据结构和数据处理，那么我们为什么还要对BPEL4WS系统建模呢？BPEL4WS本身确实不是很复杂，但复杂的是千变万化的商业流程和商业行为，复杂的是分布在Internet上的大量的Web服务以及它们所提供的接口，我们对BPEL4WS系统建模是为了能够更好地理解我们正在开发的系统。我们通过对BPEL4WS系统建模，至少要达到以下四个目的： 

建造的模型可以帮助我们按照实际情况或按照我们所需要的细化程度对系统进行可视化。 
建造的模型可以详细的说明整个BPEL4WS系统的静态结构和动态行为。 
建造的模型可以给出一个能指导我们构造BPEL4WS系统的模板。 
建造的模型要能对我们在开发过程中做出的决策进行文档化。 

可以明确地讲，由于现在的商业系统变得越来越大、流程也越来越复杂，建模的重要性也相应的就越变越大，因为我们不能仅凭想象来完整地理解一个十分复杂的商业流程系统，所以我们要通过对它建模来使我们更好的了解它。

为什么选用UML作为BPEL4WS系统的建模语言 

UML(Unified Modeling Language)即统一建模语言，是一种绘制软件蓝图的标准语言，它可以贯穿于软件开发的每一个阶段。虽然UML和RUP都是Rational公司的产品，但实际上UML是独立于具体的过程的，也就是说我们也可以采用其他的软件过程，但由于UML和RUP在某些概念方面是相同的（关于结合RUP的一些内容，在上一篇文章中有所介绍），所以结合RUP使用UML对系统建模可以达到事半功倍的效果。正像UML的一位创始人说的那样："在未来的5年内，UML与RUP将变成每一个软件开发人员都应了解和掌握的技术"，所以我认为不论你使不使用它们，你都应该了解他们，因为它们是无数前辈的经验总结，站在巨人的肩膀上成长进步又何乐而不为呢。对于我们来说最重要的是当我们利用UML对BPEL4WS系统建模时，我们可以很好的描述出BPEL4WS系统的静态特性和动态特性，而且还可以体现出BPEL4WS系统本身所具有的一些特点，这正是我们所需要的。

对于软件系统，有几种建模的方法。最普通的两种方法是从算法的角度建模和从面向对象的角度建模。传统的软件开发往往是从算法的角度进行建模，所有的软件都用过程或函数作为其主要构造块。这种观点导致开发人员把精力集中在控制流程和对大的算法进行分解上。除了用这种方法建立的模型是脆弱的之外，采用这种方法没有其他本质上的害处。但当需求发生变化以及系统增长时，用这种方法建造的系统就会变得难以维护。现代的软件开发采用面向对象的角度进行建模，所有软件系统都用对象或类作为其主要构造块，而且当前的大多数程序语言、操作系统和工具在一定的方式上都是面向对象的。所以我们可以肯定地说，面向对象方法是软件开发方法的主流部分，其原因很简单，因为事实已经证明，它适合于在各种问题域中建造各种规模程度和复杂度的系统，这也就是说我们也可以采用面向对象方法来对BPEL4WS系统进行设计和开发。其实这是显而易见的，因为整个BPEL4WS系统从本质上来说完全是基于面向对象技术和组件技术的。目前业界中最好最完备的面向对象建模语言就是UML(Unified Modeling Language)了，我们利用UML可以对要构建的系统进行可视化、详述、构造和文档化，而这几个方面也正是对BPEL4WS系统建模的主要目的。所以自然而然的，UML就成为了我们最佳的选择。

学习用UML建模要注意什么 

整个UML语言规范是相当复杂的，所以我们学习时一定不能贪多贪快，要一边学习一边理解，要结合着UML的特点和构成结构来学习。

首先我们要知道，虽然我们在系统开发的过程中要使用UML，但是UML是独立于过程的，我们最好把它用于以用况为驱动，以体系结构为中心，迭代及增量的过程中，这样才能最大程度的发挥出它的特长。我们在整个系统的开发过程中，UML可以完成的工作包括：可视化；详述；构造；文档化，而这些工作正是任何一个系统开发过程中（当然包括BPEL4WS系统）最重要的工作，所以我们可以把UML用于复杂的软件密集型系统。

其次，我们在学习时要牢记构成整个UML的三个要素： 

UML的基本构造块。 
支配这些构造块如何放置在一起的规则。 
运用于整个语言的一些公共机制。 

只有完全掌握了每个UML元素的用法和特点，才能在对BPEL4WS系统建模的过程中做到心中有数，临阵不慌。

<二>用UML来构架BPEL4WS系统的体系结构。 

系统体系结构或许是最重要的制品，它可以驾驭我们不同的观点，并且在整个项目的生命周期内控制对系统的迭代和增量式开发。随着软件过程的不断发展，体系结构这个名词已经变得越来越流行起来，那么到底什么是体系结构呢？总的来说，我们可以把体系结构描述成是一组有关下述内容的重要决策： 

整个软件系统的组织； 
对组成系统的结构元素及其所提供的接口的选择； 
由各个系统元素间协作所描述的行为； 
将系统结构和各个系统元素组合到各个子系统中； 
指导整个组织的体系结构风格，静态和动态系统元素及其它们之间的接口、协作和组成。 

(注：软件体系结构不仅关心结构和行为，而且还关心用法、功能、性能、弹性、复用、可理解性、经济技术约束及其折衷，甚至还要涉及到审美的考虑)

在我们对一个复杂的系统建模时，最好用5个互连的视图来描述这个系统的体系结构。每一个视图是在一个特定的方面对系统的组织和结构进行的投影，针对不同的系统，每个视图的重要性是不同的。比如说对于一般的MIS系统来说，用况视图和设计视图是最重要的部分，相比之下，其它视图如实现视图和实施视图就显得不是至关重要的了；而对于BPEL4WS系统来说，除了用况视图和设计视图很重要外，实现视图和实施视图对于整个BPEL4WS系统建模来说是十分十分重要的，这是由于BPEL4WS系统对存在于Internet上的Web服务的依赖性所造成的，只有构建好完整详细的实现视图和实施视图，我们才能在最大的程度上保证整个BPEL4WS系统建模的完整性和可靠性，才能最大程度的减少潜在的风险。

下面简要介绍一下这5种视图的特点：

用况视图（Use case view）：--〉包含用况 

用况视图实际上并没有描述软件系统的组织，而是描述了形成系统体系结构的动力。对BPEL4WS系统建模时，整个用况视图的静态方面由用况图表现；动态方面由交互图、状态图和活动图表现。对于BPEL4WS系统来说，一个完备的用况视图可以在最大程度上体现出商业用户的需求，而且可以为系统开发后期的review和测试活动提供很好的参考，也是测试用例编写的基础。

设计视图（Design view）：--〉包含类、接口、协作 

这种视图主要支持系统的功能需求，即系统提供给最终用户的服务。对BPEL4WS系统建模时，整个设计视图的静态方面由类图和对象图表现；动态方面由交互图、状态图和活动图表现。对于任何系统的建模活动来说，评价建模水平的标准归根结底还是主要由设计视图体现的，这是因为开发人员正是利用这个视图来完成所有的用户功能需求，而用户所关心的恰恰就是所建立的系统是否能满足用户的所有功能需求。

进程视图（Process view）：--〉包含形成系统并发与同步机制的线程和进程。 

进程视图主要是针对系统的性能、可伸缩性和系统的吞吐量。对BPEL4WS系统建模时，整个进程视图的静态和动态方面的表现与设计视图基本相同，但进程视图注重于描述线程和进程的主动类，而在BPEL4WS系统中最重要的主动类就是流程本身了（整个流程本身被抽象成主动类），所以对于流程本身的描述，包括流程进程的并发和同步机制等内容，都要在进程视图中很好的体现出来。

实现视图（Implementation）：--〉包含用于装配与发布物理系统的构件和文件。 

在BPEL4WS系统中，整个实现视图的静态方面由构件图表现；动态方面由交互图、状态图和活动图表现。在构建实施视图时要多注意构件图的构建，要利用构建图来体现出BPEL4WS系统所独有的特点。(具体对构件图建模的介绍在下一篇文章中)

实施视图（Deployment view）：--〉包含了形成系统拓扑结构的节点。 

在BPEL4WS系统中，我们利用实施视图来描述对组成整个物理系统的部件的分布、交付和安装。整个实施视图的静态方面由实施图表现；动态方面由交互图、状态图和活动图表现。任何一个系统最终都是要交付用户使用的，而实施视图正是系统交付使用的基础，而且BPEL4WS系统在系统发布上的特点正是由实施图来体现的。（具体对实施图建模的介绍在下一篇文章中）

以上这5种视图每一种都可以单独使用，也可以互相作用，互相交互。在BPEL4WS系统中，我们一定要把体系结构作为一个重要的建模制品，并且要使UML注重于对整个BPEL4WS系统体系结构的不同视图进行建模。

 回页首 
 

给开发者的建议

UML不仅是一种建模语言，它还包含了面向对象技术、组件技术等许多先进的软件开发技术和思想。在国外的软件公司UML基本成为了软件工程师必备的知识，也许你的工作暂时用不到UML，但了解和掌握UML对于提高一个软件开发人员的技术水平来说是颇有裨益的。国内许多公司由于公司规模以及其他一些现实的情况，不能很好的推广UML技术，往往只使用UML中的一小部分功能。很多公司在项目初期设计的时候还可以利用UML来进行设计，但往往到了项目结尾阶段就完全抛开了UML，又恢复到了以前较无序的开发状态，特别是测试用例的编写变得很不完善，直接后果就是降低了用户满意度，这是我们最不愿意看到的结果。国内软件业确实有自身的难处，但我们应该看到中国的软件行业正处于高速的发展过程中，作为一名软件开发人员，越早掌握一些新技术、新思想，不仅提高了自身的竞争力，同时对于整个国内的软件发展也贡献了自己的力量。在未来的5到10年内，中国极有可能会成为世界上最大的软件外包市场，日本、美国、欧洲的软件外包工程都会大量的发到国内，到那个时候，决定一个国内公司是否可以竞标到项目的标准除了规模以外，就只有管理和技术了，恐怕现在还很盛行的“关系”机制到时就吃不开了。总而言之，作为一名软件开发人员，一定要为自己树立较高的目标并对自己严格要求，要不断提高自身的价值，只有这样我们才能在越来越激烈的竞争中处于不败之地。

 回页首 
 

结束语

在本文中向读者简要介绍了有关利用BPEL4WS语言进行系统开发时如何利用UML(Unified Modeling Language)进行系统建模的概要介绍。在下一篇文章中，我将会介绍如何有针对性的利用UML核心架构对BPEL4WS系统进行建模的问题，UML的基础就是它的核心架构，掌握和熟练应用核心架构是重要且必要的，希望下一篇文章会对大家学习和掌握UML建模起到一定的帮助作用。

在本篇文章中，如有任何错误或者不够完善的地方请您与我联系，我的邮箱地址是：

国内邮箱： wq7961@263.net公司邮箱： wang.qiang@fujixerox.co.jp(如果用中文的话，最好发到国内信箱，谢谢) 

十分期望收到您的反馈意见。

另外，由于我目前正在从事BPEL4WS语言的集成开发环境的设计和开发，如果您对这方面有什么好的建议也可以直接来信和我联系，谢谢。

 回页首 
 

参考资料 

BPEL4WS语言规范 v.1.1 
http://www.ibm.com/developerworks/library/ws-bpel/ 

UML(Unified Modeling Language)语言规范 v.1.5 
http://www.omg.org/technology/documents/formal/uml.htm 

RUP(Rational Unified Process)语言规范 
http://www.rational.com/products/rup/index.jsp 

级别: 初级    王强, 软件工程师

2003 年 3 月 01 日

商业流程执行语言BPEL4WS(Business Process Execution Language For Web Services)是专为整合Web Services而制定的一项规范标准。它从本质上来说是IBM的WSFL和Microsoft的XLANG的结合物，目前已经成为业界标准。WSFL 支持图形化的流程，而XLANG在结构化构造方面有独到的方法，而BPEL4WS正是吸取了两者的优点，同时摒弃了一些复杂繁琐的部分，形成了一种较为自然的描述商业活动的抽象高级语言。
在本文的上一篇文章中( 商业流程开发新纪元——BPEL4WS语言介绍，第1部分：特点介绍及使用技巧提示)，已经向读者介绍了BPEL4WS语言的主要特点，BPEL4WS主要元素使用技巧以及利用外部Web服务的一些技巧。在本文中将继续向读者介绍有关利用BPEL4WS语言进行系统开发时如何有针对性的利用现有成熟软件过程RUP(Rational Unified Process)。 

引言

本文主要介绍的有2个方面的内容； 

1，分析利用BPEL4WS进行系统开发与普通的软件开发过程相比有哪些应该特别加以注意的问题。 
2，针对BPEL4WS语言的特点，介绍如何有针对性的利用成熟软件过程RUP进行系统开发。 

（注：对于BPEL4WS的基本语法介绍以及RUP的详细内容由于篇幅原因并没有包括在本文中，读者可以参阅附录中的相关资料介绍；在文中出现的"BPEL4WS系统"与"用BPEL4WS语言开发的商业系统"同义。） 

 回页首 
 

利用BPEL4WS语言进行系统开发时所应注意的一些问题

BPEL4WS语言是一门专为创建商业处理流程而诞生的基于XML语言规范的高级抽象语言，它不仅在语言的Specification方面不同于传统的计算机语言，而且当利用BPEL4WS语言进行系统开发(即创建具体的商业流程)时也与传统的系统开发过程有一些不同之处。大家主要应该注意以下几个方面：

〈一〉并行操作； 

BPEL4WS语言中的并行操作是由〈flow〉完成的。这种并行是通过同时调用Internet上位于不同地方（不同城市甚至是国家）的Web Services进行各种商业处理来完成的。就如图1所示，当处理流程开始后，进入〈flow〉结构，在〈flow〉中同时开始执行两个并行的〈sequence〉操作，〈flow〉操作也只有等到这两个〈sequence〉操作都完成后才可以结束。正是由于BPEL4WS具有这种并行特性，所以在建模的时候就要着重参照并发模型的建模方法。

图1：并行操作〈flow〉示例

〈二〉弱数据处理能力； 

由于BPEL4WS语言在实际操作中不涉及到商业数据的存储和处理，也就是说所有有关于数据库的操作都隐式的由其调用的外部Web服务来完成，这些数据库操作不论对于开发人员和用户来说都是透明的。正因如此，在BPEL4WS中并没有出现复杂的数据结构和数据类型，也没有关于数据存储和持久化的操作，涉及到显式数据操作的地方就是〈container〉结构的使用了，而在〈container〉中的数据没有那么复杂的数据类型，因此我们可以说BPEL4WS语言是弱数据处理能力的。正是由于它的弱数据处理能力，决定了针对BPEL4WS语言的建模方法不太适合采用面向数据流的分析设计方法和针对算法的建模，因此面向对象的分析设计方法以及面向对象的建模自然而然就成为了最好的选择。

〈三〉分布式系统架构；

BPEL4WS的诞生，完全是由于分布式技术的飞速发展，SOAP,XML以及Web Services的出现为BPEL4WS语言的出现奠定了坚实的基础。在BPEL4WS中一个最重要的概念恐怕就是"伙伴"〈partner〉结构了，BPEL4WS中的主要操作都要指定相应的〈partner〉，〈portType〉和〈operation〉。〈partner〉实际上就指明调用了哪一个Web服务，〈portType〉指明了调用这个Web服务上的哪一个端口类型，〈operation〉指明了调用的具体操作（可类似看作调用一个函数）是〈portType〉中的哪一个。由于指定的"伙伴" 所位于的各个节点机可以为异构系统，且与这些"伙伴"之间进行的通信可以基于各种通信协议(只要符合SOAP协议)，所以决定了对于系统构件模型(component model)和系统实施模型(deploy model)的建模就变得相当的重要。只有在系统的分析和设计中清晰地体现出所有与系统相关的外部Web服务的有关信息，才能算是对系统的整体架构有一个完整的描述。

 回页首 
 

针对BPEL4WS语言的特点，合理结合成熟软件过程RUP进行系统开发

RUP(Rational Unified Process)即Rational统一过程，定义了一系列的过程元素，如角色，活动和产物，通过适当的组合，能够帮助软件开发组织有效地管理软件过程。RUP的特点体现在它是以用况驱动(use case driven)的，以体系结构为中心(architecture-centric)，迭代和增量(iterative process)的。在系统的整个开发生命周期内共有4个阶段：初始(inception)、细化(elaboration)、构造(construction)和移交(transition)，随着时间的推移，每个阶段所注重的焦点也不断发生变化，同时这四个阶段也是不断迭代完成的，每一次迭代都有增量的任务完成。

由于BPEL4WS语言自身所具有的特点，决定了在结合RUP使用的时候不能完全生硬的照搬RUP的整个过程，在一些方面要做一些适当的修改，这主要体现在以下几点：

〈一〉项目阶段重点的适度转移 

从管理的观点来说，Rational Unified Process 的软件生命周期随着时间分为四个依次进行的阶段（初始、细化、构造和移交），每个阶段的结束都有一个主要里程碑，这些里程碑实际上就是每一阶段工作成果的输出。针对普通的项目开发来说，每一阶段的工作量大致可划分为：

　 先启 精化 构建 产品化 
工作量 5 % 20 % 65 % 10% 

在这里要做出一些改变的地方是精化和构建阶段。构建阶段的主要工作结果输出中有一项是实施模型，实施模型对在精化阶段创建的模型进行了扩展，在实施模型中要确定所有要用到的构件，并且必须决定如何将设计模型中的类和包映射到实施模型中的构件和子系统中。对于普通的项目来说，系统中所要用到的构件要么由自己开发，要么使用第三方提供的构件。但对于BPEL4WS系统来说，由于并不存在本地构件的使用，系统中所用到的所有业务处理功能全部都是通过调用外部的WEB服务来实现的，虽然我们也可以把调用这些外部的WEB服务看成是调用散布在Internet上的控件，就好像调用CORBA,DCOM一样，虽然结果是相同的，但由于这些外部的WEB服务都是由其他的商业团体提供的，再加上最重要的一点是同样功能的WEB服务可能有很多，而且分别由不同的团体提供（这也体现了UDDI的好处），这些WEB服务虽然功能上是相同的，但在接口细节及其他一些方面（如性能等）有很大的差别，所以作出合理的选择将是一件费时费力的工作，一旦没有作出较好的选择就有可能影响到实施阶段的工作，还有可能导致返工。因此，应将构建阶段中的实施模型中的一部分工作提前到精化阶段中完成，尤其是系统外部"伙伴"的确定是至关重要的。但在精化阶段由于用例（use case）的分析还不够深入，所以在精化阶段不可能全部完成实施模型的创建工作，也就是说在利用BPEL4WS语言进行系统开发时，实施模型的构建活动应该在精化阶段就开始，一直持续到构建阶段结束，因此工作量方面也要作出适当的调整，大体上向精化阶段增加5％－10％的工作量，具体根据情况而定，大致划分如下。

　 先启 精化 构建 产品化 
工作量 5 % 25－30 % 55－60 % 10% 

〈二〉部分核心工作流程的调整 

在RUP中，项目开发可以包含几个主要的核心工作流程，包括业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理和环境。在这里要特别注意的除了实施（上面已经介绍过）以外，测试和配置与变更管理对于BPEL4WS系统来说是非常重要的。

测试： 

测试的目的在于核实对象之间的交互、核实软件的所有构件是否正确集成、核实所有需求是否已经正确实施、确定缺陷并确保在部署软件之前将缺陷解决。在很多组织中，软件测试占软件开发费用的 30% 到 50%。但大多数人仍然认为软件在交付之前没有进行充分的测试。这个矛盾主要来自两个方面的原因，第一个，测试软件十分困难。给定程序具有无数的不同行为方式。第二个，测试通常是在没有明确的方法，不采用必须的自动化手段和工具支持的情况下进行的。由于软件的复杂性，无法实现完全测试，但采用周密的方法和最新技术水平的工具可以明显提高软件测试的生产率和有效性。

由于BPEL4WS系统的特点决定了我们应该在整个软件生命周期的早期就启动执行良好的测试，这将明显降低完成和维护软件的开支，关键是它还可以大大降低与部署质量低劣的软件相关的责任或风险。由于外部WEB服务具有一些不确定性（接口的可变性等），我们应该将初期测试的重点放在对于那些与外部WEB服务接口相关联的模块的测试上，要尽早建立合理的测试用例进行测试，而且一定要将测试用例和测试结果进行文档化，这样可以在最后进行整合测试时作为十分有价值的参考。

维护阶段的测试显得更加的重要，对于BPEL4WS系统来说，其系统维护成本通常要占到总成本的40%左右，而且维护成本会受到用户数目的严重影响，这是因为用户越多，所发现的错误也越多。在这里要专门提到的是有关于在发生在系统维护阶段的程序缺陷修复活动，有时看上去很轻微的错误，比如调用WSDL中提供的<operation>时，从<container>中取出的数据的数据类型与<operation>中的<message>的数据类型不符，本来应该是长整数，结果错用成整数，这类错误虽然很难发现，但一旦在维护阶段的实际使用中暴露出来后，修复工作还是较简单的（只限于这个子系统）。由于维护人员常常不是编写代码的开发人员，而是一些初级程序员或者新手，结果更大范围的修复工作常常会被忽视，尤其是涉及到其他子系统时。所以在BPEL4WS系统的维护阶段，测试变得更加的重要。每次发现错误修复后，必须重新运行先前的所有测试用例，这样才可以确保系统不会以更隐蔽的方式被破坏。

配置与变更管理： 

在配置与变更管理中，最重要的是一个组织的配置与变更请求管理系统（CM 系统），因为在CM系统中存放了有关该组织的产品开发、部署和维护流程等的重要信息，并且保留了执行这些流程时产生的阶段成果。CM 系统是整个开发流程中的核心部分，它必不可少。对于BPEL4WS系统，我们已经注意到与我们息息相关的外部WEB服务具有无法避免的易变性（这是由于商业系统本身就是一个易变的系统，各种商业活动的规范和流程都可能随时改变，因此导致所提供服务的改变，正像《人月传说》中说的那样"不变只是愿望，变化才是永恒"），因此对于这些易变性的捕捉就变得十分的重要，这可能在开发阶段体现的还不是很明显，但在系统维护阶段就变得显而易见了，没人能保证自己系统用到的外部WEB服务的接口不会变，也没有人可以预测什么时候变，所以对于我们来说只能以不变应万变，做好配置与变更管理，而且要把重点放在系统中所调用的外部WEB服务的接口规则上，一定要保持同时更新，保证所涉及的每一个子系统能同步得到最新的变更通知。

〈三〉新的人员角色的增加 

在RUP中，所有的人员按角色划分可分为分析员、开发人员、测试人员、经理、其他角色。由于在BPEL4WS系统中外部WEB服务对我们来说是最重要的问题，我们的一切操作都要依靠它们，所以我们必须针对它们提供专门的人员角色来负一些重要的活动。

对于分析员角色，我们应该设置专职人员负责外部WEB服务的调查工作（如接口规则以及性能特点的调查），他还要在测试阶段和测试人员合作一起负责相关测试用例的生成，这类人员的工作可以为系统的设计和测试提供充足的参考。我们可以把这类人员角色称为"外部服务审核员"。

对于其他角色，如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整个系统所涉及的所有外部WEB服务的相关文档的收集和整理，我们可以把这类角色称为"外部服务文档管理员"，"外部服务文档管理员"的工作应该和"外部服务审核员"的工作紧密联系，并且这两种人员角色的工作与测试、配置与变更管理这两个系统核心流程紧密相关，如图2所示（这并不是说与其他的核心流程就没有关系了，这只是说与这两个核心流程的关系更加紧密罢了，这也是由BPEL4WS系统的特点所决定的）。

以上两种人员角色的工作十分的重要，他们的工作降低了复杂的外部Web服务可能对系统开发带来的干扰性程度，因此我们在作系统开发时要尽量分配专职人员负责这些工作。

图2：新增人员角色

 回页首 
 

给开发者的建议

BPEL4WS系统比起普通的分布式系统，它体现了一种更高级的分布式系统抽象模型，它体现了最新的分布式概念，它所依靠的一系列的新技术无一不体现了分布式和面向对象技术的飞速发展,而其中的WebServices技术正是基于组件的系统开发模式在多层分布式系统中的最好体现。新技术的出现自然要求整体软件开发过程也要随之进步、发展。现在越来越多的国内软件组织已经认识到了规范软件过程的重要性，作为软件从业人员，应该在提高自身技术水平的同时注意对自己在软件过程规范性方面的培养，有条件的软件组织最好对开发人员进行有关PSP（Personal Software Process）方面的培训并结合一个成熟的软件过程（如RUP）来规范组织的开发流程，争取使整个开发组织达到CMM2（可重复层）的水平，然后在此基础上逐渐过渡到TSP（Team Soft Process），当PSP/TSP在软件组织中确实开展起来，并且所有的软件人员都认识到了过程规范的重要性，那么无论是CMM3，CMM4甚至是CMM5，我想也就会变得不是那么可望而不可及了。但所有的过程都不是万能的，必须要结合自己组织的特点以及要开发系统的特点做出适当的调整才可以达到事半功倍的作用，一味的死搬硬套有时不仅不能起到积极的作用，还有可能挫伤软件人员的工作积极性，我们一定根据自己软件组织的特点，在实践中不断摸索经验和总结自身的特点，不断的持之以恒的改进自己的过程，我相信只有这样才能取得最令我们满意的效果。

 回页首 
 

结束语

在本文中向读者介绍了有关利用BPEL4WS语言进行系统开发时如何有针对性的利用现有成熟软件过程RUP(Rational Unified Process)。由于篇幅的限制，将有关如何合理利用UML(Unified Modeling Language)进行系统建模的介绍放在了下一篇文章中，并且在下一篇文章中还会举一个实际的例子(贯穿分析，设计和实现)来阐明有关利用BPEL4WS进行系统开发和商业流程架构时应注意的细节问题，希望能对大家的具体工作起到一些帮助作用。

在本篇文章中，如有任何错误或者不够完善的地方请您与我联系，我的邮箱地址是： qwang@mb1.ksp.fujixerox.co.jp，十分感谢您的反馈意见。 

另外，由于我目前正在从事BPEL4WS语言的集成开发环境的设计和开发，如果您对这方面有什么好的建议也可以直接来信和我联系，谢谢。

 回页首 
 

参考资料 

1．商业流程开发新纪元－BPEL4WS语言介绍，第1部分：特点介绍及使用技巧提示 http://www.ibm.com/developerworks/cn/webservices/ws-bpel/part1/index.shtml 
2．BPEL4WS语言规范： 
英文版： http://www.ibm.comhttp://www.ibm.com/developerworks/library/ws-bpel/ 
3．RUP(Rational Unified Process) http://www.rational.com/products/rup/index.jsp 
4．CMM（Capability Maturity Model ）,PSP（Personal Software Process）,TSP（Team Software Process） http://www.sei.cmu.edu/ 
 

转自 http://www-128.ibm.com/developerworks/cn/webservices/ws-bpel/part1/index.html

级别: 初级    2003 年 3 月 01 日 王 强, 软件工程师, 日本富士施乐（FujiXerox）

商业流程执行语言BPEL4WS(Business Process Execution Language For Web Services)是专为整合Web Services而制定的一项规范标准。它从本质上来说是IBM的WSFL和Microsoft的XLANG的结合物，目前已经成为业界标准。WSFL 支持图形化的流程，而XLANG在结构化构造方面有独到的方法，而BPEL4WS正是吸取了两者的优点，同时摒弃了一些复杂繁琐的部分，形成了一种较为自然的描述商业活动的抽象高级语言。
引言
本文主要介绍的有3个方面的内容
&#8226; BPEL4WS语言的特点。 
&#8226; BPEL4WS语言主要元素使用技巧提示。 
&#8226; BPEL4WS语言利用外部Web服务的技巧提示。 
（注：对于BPEL4WS的基本语法介绍由于篇幅原因并没有包括在本文中，读者可以参阅附录中的相关资料介绍。）

1．BPEL4WS语言的特点
BPEL4WS语言从诞生到现在还不到一年的时间，我们可以说它是一门新的语言，但是它又不完全独立于现在已经存在的各种编程语言，从各方明进行总结，可以得出以下三个突出的特点：
〈一〉 BPEL4WS并不"新"：
为什么说它并不新呢？这主要是因为光就BPEL4WS语言本身的语法结构以及编程的思想来说，它是被广大程序员所熟悉的（当然，你得熟悉XML语言和基本的程序设计思想，还有就是得有分布式系统的概念，如DCOM,CORBA等）。
BPEL4WS的文法是完全基于XML规范的，如果不考虑它的程序语言特性，大家完全可以把它理解为普通的XML文档规范，也就是说可以把BPEL4WS中的所有节点对应到一个虚拟的DTD文件中。如果不考虑它的程序特性，大家在编写BPEL文件的时候就只是按照这个DTD所定义的规范在编写普通的XML文件罢了。BPEL4WS主要基于以下几个XML规范的，WSDL 1.1、XML Schema 1.0 和XPath1.0。WSDL消息和XML Schema类型定义提供了BPEL4WS流程所需要的所有数据模型，所有需要的外部资源和伙伴都被描述为WSDL服务。
如果对BPEL4WS语言的语法做较深入的研究，你就会发现它其实只是对原有编程语言思想的继承和发展。
● 关于继承，BPEL4WS语言拥有传统编程语言的一些基本特性，如：
赋值操作（由对〈container〉的操作完成）；
循环操作（由〈while〉操作完成）；
选择操作（由〈switch〉和〈case〉操作完成）；
远程调用操作（由〈invoke〉操作完成）；
错误捕捉操作（由〈catchfault〉和〈catchall〉操作完成）；
错误抛出操作（由〈throw〉操作完成）
Java,C#语言中的try操作（由〈scope〉操作完成）
● 关于发展，BPEL4WS语言是一门结合了商业处理特点的语言；
由于BPEL4WS语言是专为商业流程的执行所服务的，因此它也就自然而然的具有一门商业处理语言的特点，这体现在以下几个方面：
1>提供了对于远程调用（〈invoke〉）的同步和异步处理；
这主要是由商业处理的特点决定的，就拿民航订票来说吧，当你向民航订票系统的订票Web Service发出订票请求后，你不可能期望马上得到结果（同步），因为民航系统必须要首先要进行复杂的身份识别以确定你的系统是否有预订机票的权限，接着还要查询航班情况以确定是否你定的航班还有空座，然后才会给你答复，而你不可能一直等待得到答复，就算你愿意你的服务器恐怕也受不了这个负担。因此你必须选择异步方式，也就是发出请求后继续执行其他的操作，在这一点上有一点类似于TCP/IP协议和UDP协议的关系。 
2〉提供了并行的操作（由〈flow〉操作支持）； 
对于普通的程序设计语言来说，并行的概念只是用于表面。打个比方，也许有人会说，利用windows系统（或者unix, linux系统）的多任务执行能力，我可以让一个程序一边在后台执行计算而前台却进行复杂的人机交互工作，这不也是一种并行吗。的确，这也是一种并行，但它只是cpu级别的并行，而BPEL4WS语言所体现的并行性是一种更广范围的并行，是基于INTERNET的并行，在某些方面，类似于传统的并行处理系统（利用机群进行大规模复杂并行计算）。通过BPEL4WS，可以同时调用位于不同地方（不同城市甚至是国家）的Web Services进行处理（如计算，订货等）。 
3〉提供了补偿的操作（由〈compensate〉操作支持）； 
任何程序的执行都可能会出错，而后果也是不同的。有的操作出错并不会产生什么直接的后果，而有的操作出错的结果就必须被纠正，也就是必须执行一些补偿的操作。比如拿民航订票来说吧，假如顾客A在系统中预订一张机票，当民航系统的Web Services完成所有订票操作后，提交给顾客A请求确认时，顾客A由于其他原因取消了订票操作或者系统出现故障，那么就必须要执行补偿操作，取消所有已执行的操作，恢复数据库信息。从某个方面来说，这很类似于DBMS中的ROLLBACK操作，只不过在数据库系统中是微观执行的，而在BPEL4WS中是宏观执行的。 
〈二〉 BPEL4WS并不"可执行"：
BPEL4WS虽然定义为一门商业执行语言，但实际上它并不执行商业流程中的任何细节，也就是说它一点也不涉及到商业数据的存储和处理。BPEL4WS语言从本质上来说应该是一门描述性语言，它只是描述了什么时候？以什么顺序？到哪儿？去调用那些Web服务？怎样组织这些调用？罢了。因此，在BPEL4WS中并没有出现复杂的数据结构和数据类型，也没有关于数据存储和持久化的操作，唯一涉及显式数据操作的地方就是〈container〉的使用了，但容器中的数据只是一些临时数据，一旦商业处理的流程结束，这些数据也就消失了，这些数据就好像是传统程序语言中的变量一样，但又没有那么复杂的数据类型。说BPEL4WS语言是商业流程执行语言是因为从宏观上看，所有的操作都由BPEL4WS来完成，而其背后的操作，如Web服务的调用等是不可见的，也就是说是不透明的。这就好比软件测试中的黑盒测试一样，用户只看到了自己应该看到的用户接口，而不用去关心这些功能到底是怎样实现的。
〈三〉 BPEL4WS是真正的分布式系统：
随着INTERNET的迅速发展，在分布式技术领域也不断涌现出新技术新思想。SOAP,XML以及基于它们的Web Services，这些新技术的出现为新的分布式处理模型提供了坚实的基础，而BPEL4WS的诞生，才是分布式技术的真正升华。比起传统的分布式系统来说，利用BPEL4WS实现的分布式系统具有更高的灵活性，这主要体现在以下几个方面：
1〉各个节点机可以为异构系统：
2〉可以在运行时动态选择节点机进行处理：
3〉可以采用各种通信协议进行通信，只要符合SOAP协议。
2.BPEL4WS语言主要元素使用提示。
BPEL4WS语言中的各个元素就好像是传统编程语言中的关键字一样，正是由这些基本的元素组合到一起，构成了BPEL4WS的语言结构。从总体上划分，BPEL4WS语言可以被划分为最重要的四个部分（并不是所有BPEL4WS元素都包含在其中，这只是按主要功能进行划分的）
1〉数据处理
2〉基本活动
3〉结构化活动
4〉作用域
由于篇幅的关系，在这里就不进行详细的介绍了，相关的内容可以查阅BPEL4WS语言规范。
（英文版： http://www.ibm.comhttp://www.ibm.com/developerworks/library/ws-bpel/） 
在实际的开发中，对于初学者来说，最容易迷惑的恐怕是BPEL4WS语言中关于各个元素之间相互包容关系的理解，这一点也是BPEL4WS语言比传统编程语言较为难的一点。用传统的编程开发语言进行开发，往往各个元素之间是可以互相嵌套的，而在BPEL4WS语言中各个元素之间的包含关系有着严格的规定，但遗憾的是这在它的Specification中并没有明确的指示出来（即没有显式的总结出来），也许对于一个资深BPEL4WS开发人员来说，一切都是那么自然而然，但对初学者来说，我觉得首先掌握BPEL4WS中各个元素之间的相互包含依赖关系是十分重要的。
下面是我为大家总结的BPEL4WS语言中的最重要的各个元素之间的包含依赖关系对照表。纵坐标代表母元素，也就是父节点；横坐标代表子元素，也就是子节点。有黑点标识的表示子节点（横坐标）可以包含于父节点（纵坐标）中，反之则不然。
 

3.BPEL4WS语言利用外部Web服务的技巧提示。
既然BPEL4WS语言本身并不执行任何业务操作，那么这些操作就必须由相应的Web服务来执行，这一点一定要体现在BPEL4WS的程序中。而如何调用这些外部的Web服务呢？这就要用到Web服务描述语言（WSDL）了。在WSDL文件中详细的描述了相关Web服务的细节内容，包括接口定义，消息定义，操作定义，连接定义等。
目前可以得到外部Web服务详细信息的途径主要有3条途径：
1〉通过本地的WSDL文件获得相关的Web服务信息。
优点：使用方便
缺点：不够灵活；不能保持与最新Web服务信息的同步
2〉通过TCP/IP协议获得分布于INTERNET上的Web服务的详细信息。
优点：可保持信息的同步
缺点：不能对同种类Web服务进行灵活选择。
3〉通过UDDI注册中心获得已注册的Web服务的详细信息。
优点：非常灵活，可以对登记在UDDI注册中心的所有同种类Web服务进行灵活的选择。
缺点：实现起来难度较大。
在得到需要的WSDL文件之后，我们就可以开始利用其中的信息进行系统的构架了。但是对于外部WSDL文件的使用上，有一点比较容易使初学者感到迷惑，那就是外部WSDL文件中的哪些信息对我们来说是有用的而哪些信息对我们来说是没用的。对于这一点，虽然在BPEL4WS的Specification中间接的介绍了，但遗憾的是没有详细的罗列出来。因此在此有必要做出较为详细的说明。
对于BPEL4WS语言中的各个元素来说，它们使用外部WSDL中的有用信息是通过它们的属性值来体现的。举个例子，在使用〈invoke〉时，我们必须指定相应的参数才可以完成调用，否则系统有哪能知道要调用什么操作呢？〈invoke〉操作如下所示：
<invoke name="getResults"
              partner="getResultsService"
              portType="getResultsPT"
              operation="getResults"
              inputContainer="getResultsData">
 </invoke>
在上面的代码中，红色的属性说明这些属性值应来自外部的WSDL文件中；蓝色的属性说明这些属性值应来自这个BPEL4WS文件本身。这就说明在利用BPEL4WS文件构造系统的时候，不仅要注意那些来自外部WSDL文件中的有用信息，还要注意利用你所设计的BPEL4WS文件本身中已定义的一些信息。对于这一点在BPEL4WS的Specification中没有显式的提出来，希望在这里可以得到大家的注意。
（注：在IBM公司Eclipse开发环境中嵌入的BPEL4WS开发环境可以实现BPEL文件本身相关信息的动态处理，如显示在下拉框中；但遗憾的是对于来自外部WSDL中的信息没有动态处理和显示的功能。）
在下面的部分中，总结了BPEL4WS语言中各个元素的属性值的数据来源，希望对大家有所帮助。
BPEL4WS主要元素参数分析
〈一〉 来源于BPEL文件自身的参数：
（1） Container/Input Container/Output Container/Fault Container:
<数据来源> 
来源于BPEL文件中的〈containers〉节点中的〈container〉节点的"name"属性。 
   <containers>
     <container name="request" 
                messageType="lns:requestMessage"/>
     <container name="reply" 
                messageType="lns:replyMessage"/>
   </containers>   
（2） Partner:
<数据来源> 
来源于BPEL文件中的〈partners〉节点中的〈partner〉节点的"name"属性。 
<partners>
      <partner name="customer" 
               serviceLinkType="lns:buyServiceLinkType"
               partnerRole="customer"/>
      <partner name="seller" 
               serviceLinkType="lns:sellServiceLinkType"
               partnerRole="seller"/>
   </partners>   
（3） Scope:
<数据来源> 
来源于BPEL文件中的〈scope〉节点的"name"属性的值。 
<scope name="buyScope" >
    <compensationHandler>
        <invoke partner="Seller" portType="SP:buy" 
                operation="CancelBuy" 
                inputContainer="getResponse"
                outputContainer="getConfirmation">
           <correlations>
              <correlation set="buyOrder" pattern="out"/>
           </correlations>
        </invoke>
    </compensationHandler>
</scope>    
（4） Set:
<数据来源> 
来源于BPEL文件中的〈correlation〉节点的"set"属性的值。 
<correlations>
       <correlation set="shipOrder" pattern="out"/>
</correlations>
（5） Pattern:
<数据来源> 
来源于BPEL文件中的〈correlation〉节点的"name"属性。 
<correlations>
       <correlation set="buyOrder" pattern="out"/>
</correlations>
〈二〉 来源于外部WSDL文件中的参数：
（1） Operation:
<数据来源> 
来源于外部WSDL文件中的〈portType〉节点中的〈operation〉节点的"name"属性。 
<portType name="buyServicePT">
 <operation name="buyRequest">
  <input message="buyRequestMsg"/>
 </operation>
</portType>
（2） PortType:
<数据来源> 
来源于外部WSDL文件中的〈portType〉节点的"name"属性。 
<portType name="buyServicePT">
 <operation name="buyRequest">
  <input message="buyRequestMsg"/>
 </operation>
</portType>
（3） FaultName:
<数据来源> 
来源于外部WSDL文件中的〈portType〉节点中的〈fault〉节点的"name"属性。 
<portType name="buyServicePT">
 <operation name="buyRequest">
  <input message="buyRequestMsg"/>
 </operation>
     <fault name="buyFault">
 </fault>
</portType>
（4） MessageType:
<数据来源> 
来源于外部WSDL文件中的〈message〉节点的"name"属性。 
<message name="buyRequestMsg">
 <part name="buyOrder" type="buy:buyOrder"/>
</message>
<message name="buyNoticeMsg">
 <part name="buyNotice" type="buy:buyNotice"/>
</message>
（5） MyRole/PartnerRole:
<数据来源> 
来源于外部WSDL文件中的〈serviceLinkType〉节点中的〈role〉节点的"name"属性。
<slnk:serviceLinkType name="buyLT"
   xmlns:slnk="http://schemas.xmlsoap.org/ws/2002/07/service-link/">
 <slnk:role name="buyService">
  <slnk:portType name="buyServicePT"/>
 </slnk:role>
 <slnk:role name="buyServiceCustomer">
  <slnk:portType name="buyServiceCustomerPT"/>
 </slnk:role>
</slnk:serviceLinkType> 
（6） ServiceLinkType:
<数据来源> 
来源于外部WSDL文件中的〈serviceLinkType〉节点的"name"属性。 
<slnk:serviceLinkType name="buyLT"
   xmlns:slnk="http://schemas.xmlsoap.org/ws/2002/07/service-link/">
 <slnk:role name="buyService">
  <slnk:portType name="buyServicePT"/>
 </slnk:role>
</slnk:serviceLinkType>

结束语
在本文中简要的介绍了BPEL4WS语言的主要特点，BPEL4WS主要元素使用技巧以及利用外部Web服务的一些技巧。在以后的文章中，打算仔细的探讨有关利用BPEL4WS进行系统开发和商业流程架构的细节问题和技巧，希望能对大家有所帮助。
参考资料 
1.BPEL4WS语言规范： 
英文版： http://www.ibm.com/developerworks/library/ws-bpel/ 
2.Business processes: Understanding BPEL4WS, Part1-Part4: 
http://www.ibm.comhttp://www.ibm.com/developerworks/library/ws-bpelcol/ 
3.W3C Note "Web Services Definition Language (WSDL) 1.1" 4.W3C Recommendation "The XML Specification" 

    [摘要]本Web服务架构入门阐述了Web服务架构的基础设计原则和Web服务的基础技术。此外还对其功能进行了介绍，并提供了对其进行正式定义的规范链接。本文也是该架构所有规范的参考指南。

XML和Infoset
    对于所有的消息传递系统来说，选择信息传输单位是非常重要的——简单地说，对消息的构成有个一般的认识是必不可少的。在Web服务中，一条消息就是一个XML文档信息项，它由XML信息集（XML Information Set，即Infoset）定义。Infoset是一个抽象的数据模型，它兼容基于文本的XML 1.0，也是所有最新XML规范（XML Schema、XML Query和XSLT 2.0）的基础。由于Web服务架构是以XML Infoset，而不是某一特定的表现形式为基础，使得该架构及其核心协议组件可与其他编码技术兼容。

    Infoset根据一组‘信息项（Information Items）’对XML文档进行建模。这组可能的信息项一般会映射到XML文档的不同功能部件上，如元素、属性、命名空间和注解。每一信息项都有一个关联属性集，用于提供该项的更完整描述。附录B描述了XML文档中的11类信息项。每一个结构严谨的XML文档都会包含一个文档信息项和至少一个元素信息项。

    除了基于纯文本的Infoset编码技术以外，Web服务架构还支持另外一种Infoset编码技术——即允许不透明的二进制数据与传统的基于文本的标记交织在一起。W3C XML-binary Optimized Packaging（即XOP）格式使用多部分MIME将原始二进制数据引入到XML 1.0文档中，而不采用base64编码。其配套规范——SOAP 消息 Transmission Optimization Method，即MTOM，则指定如何将该格式绑定到SOAP。XOP和MTOM是将原始二进制数据与基于文本的XML混合在一起的首选方法，它们取代了目前普遍遭到反对的SOAP with Attachments（SwA）和WS-Attachments/DIME。

SOAP
    SOAP为在分散的分布式环境中使用XML在同等体之间交换结构化分类信息提供了一种简单的轻量级机制。SOAP旨在最大限度地降低对基于不同平台构建的应用程序进行集成的设计成本，并认为最低成本技术最有可能赢得普遍接受。SOAP消息是包含三个元素的XML文档信息项，这三个元素是：<Envelope>、<Header>和<Body>。

    Envelope是SOAP消息的根元素，它包含一个可选的Header元素和一个必需的Body元素。Header元素是以分散方式增加SOAP消息功能的一种通用手法。Header的每个子元素都被称为一个Header块（Header Block），SOAP定义了几个知名的属性来指示应该由谁来处理Header块（role）以及这种处理是可选的还是必需的（mustUnderstand），下文中对这两个属性进行了介绍。目前，Header元素总是Envelope的第一个子元素；Body元素总是Envelope的最后一个子元素，也是供最终消息接收者使用的“有效负载”的容器。SOAP本身没有定义内置的Header块，且只定义了一个有效负载，那就是用于报告错误的Fault元素。

    所有的Web服务消息都是SOAP消息，它们充分利用了XML Infoset。消息有效负载和协议头都使用同一个模型，可以确保基础架构头Header和应用程序体的完整性。应用程序发送消息时可能会同时考虑Header的内容和消息中的数据。为XML数据模型开发的工具可以用于检查和构建完整的消息。过去，这些益处在某些架构中是没有的，如DCOM、CORBA和RMI，它们之中的协议头是一些对应用程序不透明的基础架构细节。

    SOAP消息是从发送者向接收者单向传送的。多个单向消息的组合可以形成较为复杂的模式。例如，比较常见的模式是同步请求/响应消息对。发送或接收消息的任何一个软件代理都被称为一个SOAP节点（SOAP Node）。启动消息传输的节点称为原始发送节点。使用和处理消息的最后一个节点称为最终接收节点。在原始发送节点和最终接收节点之间处理消息的任一节点都叫做中介（Intermediary）。中介用于模拟单个消息的分布式处理。消息经过的所有中介节点和最终接收节点统称为消息路径（Message Path.）。

    为了能够识别消息路径的各个部分，每个节点都担任一个或多个角色。SOAP角色是一种分类模式，它将一个基于URI的名称与某些抽象功能（如缓存、验证、授权）关联在一起。基础SOAP规范定义了2个内置角色：Next和UltimateReceiver。Next是一个通用角色，因为除了发送节点之外的每一个SOAP节点都属于Next角色。UltimateReceiver是消息路径中终端节点所扮演的角色。它通常就是应用程序，或在某些情况下是代表该应用程序执行任务的基础架构。

    SOAP envelope的Body总是针对最终接收节点。而SOAP header则可以针对中介，也可以针对最终接收节点。为了提供一个安全且版本可控的消息处理模型，SOAP定义了3个属性，用于控制中介和最终接收节点处理某一指定Header块的方式——role、relay和mustUnderstand。角色属性用于确定Header块所针对的节点。mustUnderstand属性用于指示在Header块未被认出的情况下该节点是否可以忽略该Header块。带有mustUnderstand="true"标记的Header块叫做强制Header块（Mandatory Header Block）。标记为mustUnderstand="false"或没有mustUnderstand属性的Header块叫做可选Header块。relay属性指示该节点是发送还是放弃未被认出的可选header。

    每一个SOAP节点都必须使用这3个属性来实现SOAP处理模型。以下步骤详细说明了该模型：

使用角色属性（缺省该属性表示Header块针对最终接收节点）确定将用于当前SOAP节点的SOAP消息的所有Header块。 
验证当前SOAP节点是否能够使用SOAPmustUnderstand属性来处理步骤1中所确定的所有强制Header块。如果有强制Header块不能被当前SOAP节点处理，则必须丢弃该消息，并生成一条醒目的错误消息。 
处理消息。可以忽略可选消息元素。 
如果SOAP节点不是消息的最终接收节点，则步骤1中所确定的所有无法分程传送的Header块都会被删除，然后消息被传送到消息路径中的下一个SOAP节点。下一个SOAP节点可以自由地将新的Header块插入到分程传送的消息中。其中的某些Header块可能是步骤1中所确定的Header块的副本。 
    SOAP处理模型旨在实现可扩展性和版本控制。mustUnderstand属性对新Header块的引入是中断变化还是非中断变化进行控制。添加可选header块（如标记为mustUnderstand="false"的header）是一种非中断变化，因为任何SOAP节点都可自由忽略它。添加强制header块（如标记为mustUnderstand="true"的header）是一种中断变化，因为只有知晓Header块语法和语义的SOAP节点才能够处理SOAP消息。Role、relay以及mustUnderstand属性沿着消息路径传递这种处理模型。

消息交换模式
    SOAP所提供的消息传递灵活性使Web服务能够以多种消息交换模式进行通信，从而满足分布式应用的需求。我们在该架构的核心构件中充分利用了其中一些模式，有几种模式已经被证明在分布式系统中特别有用，比如使用远程过程调用就使同步请求/响应消息交换模式得到了普及。当消息传送潜伏时间失控时，就需要采用异步消息传递。当使用同步请求/响应模式时，显式消息相关性则成为必需。

    广播传输（Broadcast Transport）使一对多消息传输得到了普及。原始发送者将其消息强行发送给接收者的模式称为推模式（Push Model）。尽管这种模式在局域网里很有效，但在广域网中则不太适用，接收者也无法调控消息流。另一个有用的模式是以应用程序表达对某些特定消息类别的兴趣的能力为基础的，它使发布/订阅模式大行其道。通过显式订阅消息源（或主题），应用程序可以更好地控制相关信息流。接收者从消息源显式请求消息时使用拉模式（Pull Model）。在这种模式下，消息流是由接收者驱动的。拉模式也可以与发布/订阅模式结合使用。这非常适合于接收者可能要与消息源间歇地断开连接的情况。

传输的独立性
    根据SOAP的定义，它与所使用的底层消息传递机制无关。它支持很多可用的消息交换传输机制，也支持同步和异步消息传送与处理。既需要多种传输又需要异步消息传递的系统的一个例子是在基于陆地高速网络干线的Web服务与由移动电话托管的间歇连接的Web服务之间进行通信的系统。这样的系统要求一条消息经哪种传输系统传输要以该消息在哪个网段内移动为依据。这样的系统还有一个典型特点，即消息传送潜伏时间无法精确确定。Web服务开发人员不应力图确定或界定消息传送潜伏时间，而应在假定异步消息传递已达到最大效能的前提下构建系统。与使用远程过程调用时的情况不同，异步消息传递允许发送者在每一消息传输之后继续进行处理，而不必被迫阻塞并等待响应。当然，同步请求--响应模式也可以构建在异步消息传递的基础之上。

    既然Web服务协议完全独立于底层传输之外，适当机制的选择可能就要延迟到运行时。这就为Web服务应用程序提供了在发送消息时确定相应传输机制的灵活性。此外，底层传输机制可能会随着消息在节点之间的发送而变化，相应地，针对每一网段而选择的传输机制也会随需发生变化。

    尽管存在着这种一般的传输的独立性，大多数第一代Web服务都使用HTTP来进行通信，因为这是SOAP规范内所包含的一种主要绑定协议。HTTP以TCP作为其底层传输协议。但是，TCP在设计时引入了不必要的处理开销。有些应用协议模式与用户数据报协议（即UDP， User Datagram Protocol）的语义学比较匹配，这些模式对于受设备及其他资源约束的系统特别有用。UDP不像TCP那样具有传输保证；它提供最大限度的数据报消息传递。与TCP相比，它需要的实施资源较少。此外，UDP还提供了多路广播功能（Multi-cast Capabilitiy），使一个发送者可以将消息同时发送给多个接收者。

寻址
    对于要在这种多传输情况下发送和寻址的消息来说，要让关键的消息传递属性为多个传输所携带，就需要一种共用机制。为此，WS-Addressing规范定义了3组SOAP Header块：

Action Header块用于说明消息的预期处理。该Header块包含一个URI，最终接收者通常用它来分派要进行处理的消息。 
MessageID和RelatesTo Header块用于识别和关联消息。MessageID和RelatesTo header使用简单的URI来唯一地识别消息——这些URI通常都是瞬态的UUID。 
To/ReplyTo/FaultTo Header块用于识别要处理消息及其回复的代理。这些Header依赖于WS-Addressing所定义的称为“端点引用（Endpoint Reference）”的结构，它将与对SOAP消息进行正确寻址所需的信息捆绑在一起。 
    端点引用是WS-Addressing的最重要的方面，因为与仅使用URI相比，它们可为更细粒度的寻址提供支持。它们广泛用于整个Web服务架构。端点引用包含3条关键的信息：基地址、可选的引用属性集和引用参数。基地址是一个URI，用于识别端点，出现在指向该端点的每一SOAP消息中的To Header块中。引用属性和引用参数是用于为该消息提供附加发送或处理信息以补充基地址的任意XML元素的集合，它们以文字Header元素来表示。当使用端点引用来构建端点消息时，发送者负责提供作为Header块的所有引用属性和引用参数。

    引用属性和引用参数之间的区别在于它们如何关联服务元数据。Web服务策略和契约仅基于其基地址和引用属性。通常，基地址和引用属性用于识别某一给定的已部署服务，引用参数用于识别该服务所管理的特定资源。

    引用属性和参数是那些预期只被最终接收者处理的简单的不透明XML元素。它们有助于确保可用于分派、发送、索引或其他发送端处理活动的信息被包含在给定的消息中。尽管中介预期不会对该信息进行处理，但某些中介（如防火墙或网关服务程序）却有可能使用某些引用属性或参数来进行消息发送、消息处理。引用属性有很多用途。服务类（Classes of Service）和专用实体标识符（Private Entity Identifier）就是两个例子。在服务等级例子中，引用属性可以用于区分针对标准客户的Web服务和针对“黄金”客户的Web服务，后者提供了更高的服务质量和增强功能——可能是通过附加的操作或附加的绑定——在逻辑上形成两个不同的端点。这些属性只在一个会话中设置一次，然后便在交互的其余所有部分重复使用。引用属性另一个用途的例子是以一种对系统不公开发送消息的方式来识别客户的机制。这两种引用属性的组合可以高效地将消息发送给一组适当的服务器，并高效地确定与某一特定用户有关的应用状态。这些例子还展示了引用服务实例的数据和引用用户实例的数据如何用引用属性来表示。

    需要特别指出的是，引用属性还有助于对共享一个共同的URL和作用域的WSDL实体集合进行寻址。WSDL是将Web服务描述为操作消息的一组端点的XML格式，它首先抽象地指定其实体，然后将其具体地绑定到特定实例。具体而言，消息和操作经抽象定义之后，被绑定到带有网络传输和消息格式信息的一个端点。因此，从WSDL的角度来看，当针对不同的具体实体（如输入或输出消息、portType绑定、端口或Web服务中使用一个共同URL的服务）时，对应端点引用的引用属性应该不同。

    使用引用参数的两个例子是基础架构和应用水平。引用参数的基础架构例子可以是发送给某一事务处理监视器的事务/征募ID（Enlistment ID）。在一个购书的场景中，书的ISBN号可能就是一个引用参数应用水平例子。

元数据（Metadata）
    所有的Web服务交互都是通过交换SOAP消息来进行的。为了提供一个健壮的开发和操作环境，服务是用机器可读的元数据来描述的——元数据支持互操作性。Web服务元数据可以服务于若干个意图。它用于描述Web服务支持的消息互换格式和某一服务有效的消息交换模式。元数据还用于描述服务的功能和需求。元数据的最后一种形式叫做“服务策略（Policy of Services.）”。消息互换格式和消息交换模式用WSDL来表示，策略使用WS-Policy来表示，契约（Contract）用上述三种元数据来表示。契约是将应用程序与它们所依赖的服务的内部实现细节隔离开来的抽象。

    Web服务描述语言，即WSDL——Web Service Description Language，它是被广泛用于描述Web服务基本特征的第一种手段。用WSDL描述的消息被归并为定义基本消息模式的若干操作。这些操作被归并为称作端口的若干个接口，它们详细说明了抽象的服务契约。端口和绑定则用于将portTypes与具体传输和physical 部署信息关联在一起。WSDL描述是自动识别目标服务的所有特征和启用软件开发工具的第一步。WSDL指定请求消息必须包含什么以及响应消息在使用无歧义符号时的显示会是怎样。WSDL文件用于描述消息格式的符号是基于XML模式的。这意味着它既是编程语言中立的又是基于标准的，这使得它很适合于描述可通过多种平台和编程语言来访问的服务接口。除了描述消息内容以外，WSDL还可以定义服务在何处是可用的，以及哪些通信协议被用于与该服务交谈。这意味着WSDL文件可以指定用于编写与某一Web服务进行交互的程序的基本元素。有几种工具可用于读取WSDL文件，以及为编制句法正确的Web服务消息生成所需代码。

    尽管WSDL是一个不错的起点，但它并不足以描述Web服务的方方面面，WSDL只能表示较少的一组属性。Web服务所必需的更详细信息包括：

操作特征：支持SOAP 1.2。 
使用特征：仅在早9点和下午5点之间可用。 
安全特征：要访问该服务必需使用Kerberos票。 
    第一代Web服务必须使用专有协议来交换带外（Out of Band）的元数据，这一问题可以使用WS-Policy来解决。WS-Policy提供了一种通用模型和语法来描述和传达Web服务策略。它指定了一个概念基集，它可以被其他Web服务规范使用和扩展，以描述更为广泛的服务需求和功能。WS-Policy引入了一个简单的可扩展语法来表示策略断言（Policy Assertion），以及一个处理模型来解释它们。断言可以合并到逻辑选项中。

    策略断言使编程人员要么在开发时、要么在运行时向服务信息中添加适当的元数据。开发时策略的例子包括消息大小的最大允许值或所支持规范的确切版本，运行时策略的例子包括宕机时的必备服务或某一给定的管理过程（定期的硬件维护）期间Web服务的不可用性。可以对单个的策略断言进行分组，以形成策略选项（Policy Alternative）。策略是策略选项的集合。为了便于进行互操作，策略是根据其XML Infoset表示形式来定义的。为了在保持互操作性的同时减小策略文档的大小，又定义了策略的紧凑形式。

    策略用于传达两个Web服务端点之间的交互条件。满足策略中的断言通常会引发反映这些条件的行为。因此，策略断言评估是识别兼容行为的中心。当且仅当请求者满足要求，即提供了这一功能、与该断言相符时，请求者才支持策略断言——策略的构造块。一般而言，这种决定要使用特定领域的知识来做出。请求者支持策略选项的条件是当且仅当请求者支持选项中的所有断言时，这种决定是使用策略断言的结果机械性地做出的。同样，当且仅当请求者至少支持策略中的一个选项时，请求者才支持策略。一旦策略选项经过评估，该决定也是机械性地做出的。请注意，虽然策略选项是互斥的，但一般来说要确定多个选项是否可以同时得到支持也是不太可能的。

    为了以互操作的形式传达策略，策略表达式（Policy Expression）采用策略的某种XML Infoset表示形式。普通形式的策略表达式是最简单的Infoset；同样，可选的Infoset允许通过大量构造来简洁地表达策略。策略表达式是策略的基础构造块。有两个运算符用于表达断言：All和ExactlyOne。All运算符表示策略选项集中的所有断言都必须适用于要满足的策略断言。ExactlyOne运算符表示策略选项集中只有一条断言必须适用于要满足的策略断言。

    策略层位于WSDL描述之上，并对它进行了扩充。策略与Web服务元数据（如WSDL定义或UDDI实体）的关联是通过使用WS-PolicyAttachment来实现的。策略可以作为其定义所固有的一部分或独立地与资源关联在一起。机制就是针对这些不同目的而定义的。需要特别指出的是，策略也可以与单个的SOAP消息一起使用。如果为某一实体制作了多个策略附件，它们会共同确定该实体的有效策略（Effective Policy）。在WSDL层次结构的不同层次上选用策略时一定要小心，因为层次结构每一层次的最终结果就是一个有效策略。作为自我描述和人所能理解的明确性的一般规则，在策略断言所适用的层次结构的每一层次上详细地重复该策略断言，比简单地依赖于计算有效策略的机制更可取。在一个WSDL文档中，与部署端点的消息交换可以同时包含所有4类主题的有效策略。WS-Policy和WS-PolicyAttachment相结合可以提高应用程序来发现和推出其他服务所支持的策略的能力。添加策略的灵活性是对描述消息交互的WSDL信息的一个重要补充。

    WSDL和WS-Policy都定义了元数据格式，但都没指定某一给定服务获得或访问元数据的机制。一般来说，服务元数据可以通过使用许多方法来获取。为了支持服务的自我描述，Web服务架构在WS-MetadataExchange中定义了基于SOAP的元数据访问协议。GetMetadata操作用于检索在请求的端点引用中找到的元数据。Get操作类似，但用于检索不同的元数据：在元数据部分引用，并要在存储它的端点引用中检索的元数据。

    使用WS-MEX来交换的元数据可以描述为资源。资源即可由某一端点引用寻址的任何实体，并且在该端点引用中，该实体可以提供一种其自身的XML表示形式。资源构成了构建Web服务中的状态管理所需的基础。

什么是互操作性概要（Interoperability Profile）
    概要（Profile）是一组指导原则，主要针对于核心协议以及Web服务规范的使用。这些指导原则对于规范的通用设计来说是必需的。在某些情况下，开发人员需要额外的帮助来确定使用哪些Web服务特性来满足某一特定需求。互操作性概要还用于解决Web服务规范不够明确的领域中的含糊性问题，以确保所有实施都以相同的方式来处理SOAP消息。

WS-I基本概要
第一个Web服务概要是由Web服务-互操作性组织（WS-I，Web Services-Interoperability Organization）发布的。WS-I已经完成了其第一个概要，并简单地称为基本概要1.0。该概要主要基于SOAP1.1和WSDL 1.0的互操作使用来提供指导原则。

安全性
    本节介绍Web服务架构中用于提供某一系统内部的消息完整性、身份验证和机密性、安全性令牌交换、消息会话安全性、安全策略表示和服务联盟安全性的规范。提供这些特性的规范是WS-Security、WS-Trust、WS-SecureConversation、WS-SecurityPolicy和WS-Federation。

    安全性是计算机系统的一个基本方面，尤其是那些由Web服务组成的系统。安全性必须是健壮而有效的。因为系统只对消息格式和合法的消息交换作出硬件假设，因此安全性必须基于一致通过的明确机制和假设。安全基础架构还应该具有足够的灵活性，以支持不同组织所需的不同安全策略。

    当安全传输可用于通信Web服务，如安全套接层（SSL）和传输层安全性（TLS）之间时，构建安全性解决方案就得到了简化。有了安全传输，这些服务就不需要参与单个消息的完整性和机密性的维护；它们可以依赖于底层传输。不过，现有的传输级安全性是一个仅限于点对点消息传递的解决方案。如果在使用安全传输时存在中介，则最初发送者和最终接收者需要相信这些中介能够帮助提供端到端的安全性，因为每个网段都是安全的。除了要明确地信任所有中介外，还必须考虑到其他风险，如消息的本地存储和中介受到损害的可能性。

    为了最大限度地扩大Web服务的作用范围，当通信端点不相信中介时，必须提供端到端的安全性，那就需要更高级别的安全协议。作为另一种选择，端到端消息安全性比点对点传输级安全性具有更丰富的内涵，因为它支持Web服务所需的基于SOAP的松耦合、联合、多传输和可扩展环境。这种功能强大而又灵活的基础架构可以通过现有技术和Web服务协议的组合来开发，同时还可以缓解与点对点消息传递相关联的许多安全风险。

    尽管Web服务的安全需求很复杂，但人们还没有发明新的安全机制来满足基于SOAP的消息传递的需要。现有的分布式系统安全性方法，如Kerberos票、公钥加密技术、X.509证书等已经够用了。只有应用现有的SOAP安全方法时，新机制才是必需的。这些新安全协议的设计充分考虑了可扩展性，以便将来能够加入新的方法。一个主要的设计目标是要提供自我描述安全性属性（为包括SOAP在内的Web服务架构而设计）机制。

    Web服务安全性的基础是输入消息要证实一组关于发送者、服务或其他资源的断言这一需求。我们称之为断言或安全性断言。典型的安全性断言包括身份、属性、关键财产、权限或功能。这些断言是用包裹在XML中的二进制安全性令牌编码的。在传统的安全性术语中，这些安全性令牌表示功能和访问控制的混合。很多方法都被用于创建安全性令牌。Web服务可以从本地信息构建定制的安全性令牌。反过来，安全性令牌也可以从X.509认证机构或Kerberos域控制器等专业服务检索。为了实现服务之间的通信自动化，需要一个表达安全需求的方法。

    服务可以使用WS-SecurityPolicy中所指定的策略断言来表达其安全需求。通过检索这些策略断言，应用程序可以构建符合目标服务需求的消息。断言、安全性令牌和策略所提供的这组特性以及从Web服务检索它们的能力非常强大。这种普通的Web服务安全模式支持一些更具体的安全模式，如基于身份的授权、访问控制列表和基于功能的授权。它允许使用现有技术，如X.509 公钥证书、基于XML的令牌、Kerberos共享的秘密票和密码摘要。这种普通模型对于构建使用更复杂的方法来进行更高级别的密钥交换、身份验证、基于策略的访问控制、审核和处理复杂的信任关系的系统已经足够。也可以使用代理和中继服务。例如，可以构建中继服务来加强位于信任边界的安全策略；出界的消息被加密，而界内的消息不加密。以前的解决方案没有提供这种灵活性和完善程度。附录C中所描述的常见安全攻击包含了系统威胁的基本分类，而这些系统威胁是在选择Web服务安全特性时应认真加以考虑的。

    本节的余下部分将探讨Web服务安全模式的应用。两个重要主题是安全通信和安全应用。没有假定安全的消息传输，这也不是安全的Web服务所必需的。

消息完整性和机密性
    消息级安全性是端到端安全性的关键构造块。使用消息级安全性时，无需传输级安全性。对消息级安全性的要求是消息完整性、消息身份验证和机密性。消息完整性确保消息不能在不知不觉中被更改。使用XMLSignature可确保消息的修改能够被察觉。消息身份验证可识别发送消息的主体。如果使用了公钥加密，就可以确定主体的唯一身份。将公钥加密与经受信任源认证的密钥一起使用可以实现这种身份验证。不过，如果使用了对称密钥加密，情况就不一样了——只有知道共享密钥的主体才能被识别。消息机密性可确保在传输期间未经授权的第三方不能阅读消息。SOAP消息是通过使用XMLEncryption [XMLENC]和安全性令牌来保证机密性的。

    完整性、身份验证和机密性机制将初始消息（或该消息的某些部分）作为输入，将生成的数据（如校验和）作为输出。例如，在某种简单情况下，XML元素的签名可能会作为XML元素所有字符的散列的非对称加密来实现。然后该加密散列可以存储在该消息中，并在该消息中传送。可以将XML文档看作字符串。就像XML签名一样，逐字符地比较也是非常重要的安全性操作。一字之差会导致不同的结果。串行化是用于表示“在线”对象的方法。例如，串行化可用于创建SOAP消息的XML表示。不同串行化软件所导致的任何无关紧要的排字差异都会被消息处理软件忽略，但会对安全性软件产生很大影响。XML消息的Infoset表示形式改进了这一问题。要使XML签名生效，消息必须转换成一个对所有方都是一致的XML表单。规范化是一个术语，来描述用于生成一致的换行符、制表间隔、属性排序和结束标签样式等非关键信息视图的方法。签名包含了用于使消息接收者能够完全像发送者那样处理安全信息的规范化方法。某一服务所使用的特定的规范化方法是要放置在一个WSDL portType绑定或WSDL端口的有用的策略断言。

    WS-Security指定了消息完整性和机密性机制以及单一的消息身份验证。对于消息完整性，该规范详细描述了加密签名是如何表示并与SOAP消息的特定部分关联的。该方法允许任意格式良好的消息片段拥有单独的签名。与之类似，机密性是通过结构良好的消息片段的加密来实现。身份验证是使用数字签名来实现的。WS-Security规范描述了当前常用的安全机制，也没有排除将来添加新机制的可能性。因为SOAP处理模型使用Header元素来作出处理决定，所以是决定SOAP消息中的哪些元素需要加密时一定要多加小心。

    在决定要对哪些元素进行加密以及要使用哪些加密算法时，Web服务设计人员一定要清楚消息是如何处理的。当某些特定的Header元素需要由第三方或中介来处理时，这些决定就更为重要了。如果这些参与者对适当的解密数据或对在加密XML元素时所使用的约定毫无所知，它们将无法实现正确操作。此外，每个处理节点对消息中包含的安全信息都必须有个一般的了解。加密某一Header中XML元素的一个自然选择就是对它进行完全加密，用初始元素替代加密数据类型的元素。这种简单的方法有些缺点。例如，中介不太好确定必须处理哪些元素（带有mustUnderstand="1"属性的元素）。另外，当元素类型发生变化时，确定其初始类型比较困难。另一种方法是对元素进行转换，使得进行正确的SOAP处理所需的所有关键属性都保持不变，且对初始元素进行了加密，并放在一个特殊的子元素中。这种方法的优点是即使不知道如何解密元素的中介也能实现正确的处理。这种方法的一个缺点是它要求所有参与者都了解用于表示初始元素的约定。尽管WS-Security目前没有对这种方法提供指导，但我们预期将来会提供的。相比之下这种方法更好一些，因为它可实现所有SOAP Header元素的正确处理。

    WS-Security的概要规范中描述了几种安全性令牌。针对表示用户名的令牌、X.509证书和基于XML的安全性令牌的概要都已经开发出来。基于XML的安全性令牌包括安全性断言标记语言（SAML，Security Assertion Markup Language）和可扩展权限标记语言/权限表达语言（REL，Rights Expression Language）。Kerberos票的使用规范还未成型。

WS-I基本安全概要
    WS-I将要发布的最新的互操作性概要之一是基本安全概要（BSP，Basic Security Profile）。该概要提供了WS-Security和各种安全性令牌，如Username和X.509证书令牌的实现指导。该概要用于补充和完善WS-I基本概要。

基于安全令牌的信任
    安全性令牌是提供端到端安全解决方案所必需的。这些安全性令牌必须在消息处理的参与者之间实现直接或间接共享。各参与者还必须确定断言的凭证是否可信。这些信任关系以安全性令牌的交换和代理为基础，并存在于已经确定的支持信任策略中。例如，某一代理的令牌有多少可信，是由系统管理员和他们确定的信任关系决定的。提供安全性令牌的服务五花八门。这是各种底层安全技术首先为Web服务所使用的领域。为了提供一种与安全技术无关的统一标准的解决方案，新协议是为信任域之间的安全性令牌交换而设计的。

    WS-Trust以用于请求、发出和代理安全性令牌的协议对WS-Security进行了补充。需要特别指出的是，其中定义了用于获取、发行、更新和验证安全性令牌的操作。该规范的另一个新特性是建立新信任关系的机制。IPsec或TLS/SSL之类的网络和传输保护机制可以与WS-Trust结合，以适应不同的安全性需求和情况。

    安全性令牌可以直接从某一适当的发行者处申请获得，或者通过委托某一受信任的第三方来获取。令牌还可以出乎意料地获得。例如，令牌可以从某一安全权威机构发送到一个并未明确申请该令牌的某一方。为此，系统管理员要确定初始信任关系，如将某一给定服务指定为信任的根服务。这种方法类似于目前Web上用于自展安全性的方法。从该服务获得的所有令牌受信任的程度与受信任的根服务本身相同。例如，如果某根服务只有断言A和B得到信任，且某一消息包含断言A、B和C，则该消息中只有断言A和B得到信任。配置灵活性是通过信任关系授权提供的。为了处理在退回或发出安全性令牌之前需要各方之间的一个交换集的情况，定义了用于验证、协商和交换的方法。一种称为“challenge”的特殊形式的交换为某一方证明它拥有与某一令牌关联的密钥提供了一种方法。交换的其他类型包括传统的协议隧道。WS-Trust详细说明了如何扩展该规范，以支持更多的令牌交换协议，而不仅仅是所给出的这两个例子。

    表示安全性断言的安全性令牌是由一个受信任根或一个通过一个授权链的根发行的。这些安全性断言用于验证消息符合正在施行的安全策略。它们还验证断言者的属性是通过签名来校验的。在代理的信任模式中，即由受信任的中介分配安全性令牌的模式中，签名可能不验证断言者的身份，而验证中介的身份。该中介可能只断言者的身份。

安全会话
    用于消息身份验证和机密性的某些机制可能会耗用大量的资源。需要特别指出的是，许多加密技术都会显著消耗处理能力。当消息的安全性是逐一得到保证时，这些代价通常是无法避免的。不过，当两个Web服务进行许多消息的交换时，可以使用比WS-Security中定义的方法更为高效和健壮的消息机密性方法。这些方法是基于对称加密的，在保证消息会话的安全时应使用它们。

    WS-SecureConversation在基于共享密钥（如对称加密）的两个通信方之间定义了一个安全上下文。在整个会话期内，安全上下文在各通信方之间始终是共享的。会话密钥由共享密钥派生而来，用于解密在会话中发送的单个消息。安全上下文在线表示为一个新的安全性令牌类型（即SCT ，Security Context Token）。

    规范为建立安全会话各方之间的安全上下文定义了3种不同方法。第一种，由安全性令牌服务创建，且必须由会话发起方提取并传送。第二种，通信一方创建安全上下文并通过消息传递给另一方。第三种，通过协商和交换创建安全上下文。Web服务会选择最能满足其需要的方法。必要时可以对安全上下文进行修正。更新安全上下文的一个典型例子是延长安全上下文的截止时间。安全上下文令牌隐含或包含了一个共享密钥。该密钥用于签名、加密消息。当使用共享密钥时，通信各方可以选用不同的密钥派生模式。例如，可以派生出4个密钥，这样双方便可以使用单独的密钥来签名和加密消息。为了保证密钥未曾用过和保持高度的安全性，应使用后续的派生密钥。使用这种方法来保证会话的安全性是一种更好的选择。WS-SecureConversation规范定义了一种方法来指示给定消息正在使用哪些派生密钥。所有派生算法都是通过URI来识别的。

安全策略
    WS-SecurityPolicy通过用一种符合WS-Policy的语言指定安全策略断言来完善WS-Security，其6种断言涉及安全性令牌、消息完整性、消息机密性、消息对SOAP中介的可见性、对安全Header的约束和消息寿命。例如，某一策略断言可能要求所有消息都使用某一权威机构提供的公钥来签名，或该身份验证要基于Kerberos票。

系统联盟
    除了我们已经介绍的方法以外，应用程序安全性还需要更多的方法。例如，在某一信任域中有效的身份在其他信任域中很可能没有意义。要让不同信任域中的服务能够验证身份的有效性，就需要适当的机制。WS-Federation定义了一些机制，以支持身份、帐户、属性、身份验证和身份验证信息跨信任域的共享。利用这些机制，多个安全域可以通过在由多方参与的Web服务之间支持和代理身份、属性和身份验证的信任而结成联盟。该规范扩展了WS-Trust模型，使属性和笔名可以被整合到令牌发行机制中，从而形成一种多域身份映射机制。这些机制都支持单点登录、退出和笔名，并描述了专业服务对于属性和笔名的作用。

    通过身份联盟，很多要求都可以得到满足。就拿将一名员工与其雇主关联起来的例子来说，公司A的Jane从OfficeSupplyStore.com进行采购，公司A和OfficeSupplyStore.com之间有一个采购合同。因为Jane的身份是与公司A关联的，所以可以让她来依据该合同来进行采购。第二个例子是将一个人映射到多个笔名。大家可能只知道Joe使用joe@companya.com工作。他还可能有其他身份，如joe_bloggs@hotmail.com和josephb@cornell.edu。通过身份联盟，系统可以确定这些身份都是同一个Joe。

    Web服务联合安全架构中定义了两个一般的请求者（消息发送者）类：被动和智能（活动）。被动请求者是只使用HTTP且从来不发出安全性令牌的服务。智能请求者是能够发出包含诸如WS-Security和WS-Trust中所描述的那些安全性令牌的消息的服务。传统的基于HTTP的Web浏览器就是被动请求者的一个例子。定义这两种请求者的行为的概要规范现已开发出来。对于智能请求者，active请求者概要详细说明了单点登录、退出和笔名是如何通过使用SOAP消息而整合到Web服务安全模型中的。实际上，该概要描述了在智能请求者上下文中实现WS-联盟中所描述的模式的方法。它详细说明了各种安全性令牌的要求。作为这些安全性令牌要求中之一的一个例子，当不使用安全通道时，X.509证书的整个令牌必须包含权威机构的名称和签名。该概要还要求X.509令牌包含主题标识符，以唯一地识别授之以该令牌的主题。

发现（Discovery）
    本节介绍Web服务架构中用于定位网络上Web服务和确定该服务可用性的功能组件：UDDI和WS-Discovery。Web服务发现是在没有人工干预的情况下实现服务连接自动化的关键。Web服务发现方法反映了计算机系统中查找信息的两个最常见方法：查看一个众所周知的目录，或将一个请求广播给所有可用的监听器。UDDI注册表就相当于该目录，发现协议用于广播请求。

目录（Directory）
    通用描述发现和集成协议，即UDDI——Universal Description Discovery and Integration Protocol，指定了一个用于查询和更新Web服务信息通用目录协议。该目录包含关于服务提供商、它们所托管的服务以及这些服务所实施的协议的信息。该目录还提供了用于向任何注册信息添加元数据的方法。如果Web服务信息存储在众所周知的位置时，则可以使用UDDI目录方法。一旦找到目录，就可以发送一系列查询请求以获取想要的信息。UDDI目录位置通常是通过系统配置数据从带外（Out of Band）获得的。

    对于如何部署UDDI注册表，Web服务提供商有很多不同的选择。部署方案不外乎3个类别：公共、企业外和企业内。为了支持公共部署，以Microsoft、IBM和SAP为首的一组供应商主持推出了UDDI企业注册表[UBR，UDDI Business Registry]。UBR是一个可跨多个主持企业复制的公共UDDI注册表，它既是基于Internet的Web服务资源，又是Web服务开发者的一个试验台。尽管目前公共UDDI实施已经受到了最大关注，但UDDI的早期采用者仍更倾向于使用企业外和企业内方法。在这两种部署情况下，企业要部署一个专用注册表，而且更严密地控制注册信息类型也是可能的。这些专用注册表可能只供一个企业使用，也可能供若干组业务合作伙伴使用。UDDI还为注册表间的复制和跨部署的信任联盟定义了协议。使用这些协议进一步增加了可用于实施者的部署方案数量。对于所有的部署方案，UDDI目录都包含了Web服务及其托管地的详细信息。UDDI目录项有3个主要部分——服务提供商、所提供的Web服务和实施绑定。其中的每一部分都逐渐提供有关Web服务的更详细信息。

    大部分的一般信息都描述服务提供商。该信息不针对Web服务软件，而是针对直接负责该服务的开发者或实施者。服务提供商信息包括名称、地址、联系人及其他管理细节。所有的UDDI项都有多个元素来支持多语言描述。可用的Web服务列表存储在服务提供商项中。这些服务可能是根据它们的预定用途来组织的：它们可能被分成不同的应用领域、地区或任何其他适用的模式。存储在UDDI注册表中的服务信息只包含服务描述和一个指向它所包含的Web服务实施的指针。由其他提供商托管的服务链接称为‘服务映射（Service Projection）’，也可能被注册。

    UDDI服务提供商实体的最后部分是实施绑定。该绑定将Web服务项与确切的URI关联起来，以确定在何处部署服务，它还指定了访问协议，并包含所实施的确切协议的参考资料。这些细节对于开发人员编写调用Web服务的应用程序已经足够。详细的协议定义的是通过一个称为“类型模型（即tModel，Type Model）”的UDDI 实体提供的。在许多情况下，tModel都会引用一个描述SOAP Web服务接口的WSDL文件描述，但tModel的灵活性也几乎可以描述任何种类的资源。对于在UDDI中注册的每一个提供商或服务来说，来自标准分类学（如NAICS和较古老的美国标准行业代码）或其他身份识别方案（如Edgar Central Index Key）的元数据都可用于分类信息和提高搜索准确性。可用的分类学和标识符方案集作为任何实施的一部分，是可轻松扩展的，因此可以对其进行定制以支持任何特定的地域、行业或企业需求。

动态发现（Dynamic Discovery）
    动态Web服务发现是以不同方式提供的。作为在已知注册表中存储信息的另一种方案，动态发现的Web服务会明确地声明它们的到达、离开网络。WS-Discovery为通过多路广播消息来声明和发现Web服务定义了协议。当Web服务连接到网络时，它通过发送一条Hello消息来声明它的到达。在最简单的情况下，这些声明的跨网发送使用多路广播协议——我们称之为自组织网络。该方法还最大限度地减少了网络上的轮询需要。为了限制网络信息流通量和优化发现过程，系统可能会包含一个发现代理。发现代理用一个众所周知的服务位置取代了发送多路广播消息的需要，从而将自组织网络转变成托管网络。利用配置信息，代理服务集合可以连接在一起，从而将发现服务扩展到多组服务器，从一台机器扩展到多台机器。

    因为发现代理自身也是Web服务，它们可能会用自己专用的Hello消息来声明它们的到场。接收该消息的Web服务然后可以利用该代理的服务，而无需再使用干扰较多的一对多发现协议。当服务离开网络时，WS-Discovery会指定一个Bye消息以发送给网络或发现代理。该消息通知网络上的其他服务离开的Web服务不再可用。

    为了完善这种服务声明和离开的基本方法的不足，WS-Discovery定义了两个操作——Probe和Resolve，以定位网络上的Web服务。对于自组织网络，Probe消息被发送给多路广播组，并且与该请求匹配的目标服务会将响应直接反馈给请求者。对于利用发现代理的托管网络，Probe消息则以单路广播方式发送给发现代理。如果按名称定位Web服务，则使用Resolve消息。Resolve消息只以多路广播模式发送。Resolve 类似于地址解析协议，即ARP，它将IP地址转换成其对应的物理网络地址。WS-Discovery规范还支持这样的系统配置：将Probe消息发送给一个已经通过其他管理方法建立起来的发现代理，如通过使用众所周知的DHCP记录。

    动态发现服务的能力实现了Web服务管理的自举。与WS-Eventing及其他协议相结合，更复杂的管理服务也可以通过使用这种动态发现基础架构来构建。动态发现还将Web服务架构扩展到设备，如那些目前可能实施通用即插即用（UPnP）协议的系统——这是使该架构真正实现通用的重要一步。例如，借助WS-Discovery和WS-Eventing，打印机或存储介质等设备可以作为Web服务纳入到系统中，而且无需专门的工具或协议。

Web服务设备概要规范
    Web服务设备概要规范对在资源受限的设备上应该实施Web服务架构规范家族的哪个子集提供了指导。该概要力图在由于资源限制而作出折衷时，在可用的丰富功能和最重要的功能之间找到平衡。

一致性协议——可靠的消息传递和事务
    本节介绍可以提供可靠的消息传送、事务行为和能够在一组Web服务之间进行显式协调的Web服务架构组件。定义这些功能的规范是WS-ReliableMessaging、WS-Coordination、WS-AtomicTransaction和WS-BusinessActivity。

    当多个Web服务必须完成工作的某一共同单元或依照某种共同的行为进行操作时，对于使用哪个协议必须达成共识。Web服务之间这种最低限度的协调是不可避免的。协调协议还必须能够确定并同意已达成一个共同目标。Web服务之间的每一个交互都可以看作一种协调。一致性协议为该架构提供了一个改进的机会，即参与者服务在它们准备共同完成的任务方面将获得成功。在传输丢失了消息和服务失常时，Web服务架构仍然能够正常工作。

    任何多方协调都可以通过接连地随需加入更多参与者从两方协调逐步发展而成。两方协调可能是自发的，也可能需要一个指定的协调者。广泛使用的自发协调协议的一个例子是同步请求—响应消息传递模式。这是一致性协调的最简单形式之一；对于每个工作请求，接收方Web服务必须完成所有预期工作之后才能向请求者返回数据。双方都遵循这种严格的模式，无需显式协调服务。

可靠的消息传递
    很多情形都可能中断两个服务之间的消息交换。当使用不可靠的传输协议（如HTTP 1.0和SMTP）来进行传输或当消息交换跨多个传输层连接时，这更会成为一个问题。消息可能会丢失、被复制或重新排序，Web服务可能会失败并失去易变状态。WS-ReliableMessaging是一个基于特定的传送保证特征实现可靠消息传送的协议。该规范定义了3个可结合使用的不同断言：

At-Least-Once Delivery（至少一次传送）：每条消息至少传送一次。 
At-Most-Once Delivery（至多一次传送）：不传送重复的消息。 
In-Order Delivery（依次传送）：按消息的发送顺序传送消息。 
    至少一次和至多一次保证相结合的结果是恰好进行一次传送。由于Web服务架构的设计与传输无关，因此所有传送都与所用的通信传输工具或其组合无关。由于开发人员必须预测的潜在传送失败模式数量减少，故使用WS-ReliableMessaging可以简化系统开发。

    可靠的消息传送不需要显式协调者。当使用WS-ReliableMessaging时，参与者必须根据SOAP消息Header中所发送的信息识别协议。作为一个组传输的消息集合称为消息序列（Message Sequence）。消息序列可以由发起者/发送者或Web服务创建，当建立一种双向关联时通常由它们共同创建。序列是使用CreateSequence和CreateSequenceResponse消息显式创建的。当想要的最终结果是用两个单向序列来充当一个双向序列时，发起者将提供Web服务所要使用的序列。该序列的ID由发起者包含在CreateSequence消息中。

    WS-ReliableMessaging中定义了几个策略断言。这些策略断言用WS-Policy中定义的方法来表示。

    可靠的消息传递协议简化了开发人员为在传输不断变化的情况下传输消息而必须编写的代码。也就是说，底层基础架构可以对消息在端点之间的正常传输进行验证，必要时还会转发消息并检测重复。应用程序不需要任何附加逻辑来处理提供传送可能需要的消息转发、重复消息的消除、消息重新排序或消息确认。WS-ReliableMessaging的实施是跨发起者和服务分布的。那些非‘在线’可见的特征，如消息传送顺序，是通过实施WS-ReliableMessaging规范来提供的。虽然由传输损失导致的消息重发等特征是通过不为应用程序所知的消息传递层来处理的，其他端到端特征（如依次传送）都要求消息传递基础架构和接收应用程序相互协作。当发送者希望按发送顺序提供消息排序时，在接收者一方却按接收顺序提供消息排序的情况是依次传送的一种不正确实施——注意到这一点是很有趣的。当发送者希望按接收顺序提供消息顺序时，在接收者一方按发送顺序提供消息顺序的情况，是依次传送的一种正确实施。

指定的协调者
    N路协调协议的某些族需要一个指定的协调者来引导一个工作单元通过一系列合作服务，一个例子是活动必须在不希望被同时连接的服务之间协调。只要每个参与者和协调者在某一时刻通信，协调就可能发生，结果就可能达成一致。Web服务架构为指定的协调者定义了某些简单操作。

    WS-Coordination规范定义了一个可扩展的协调框架来支持需要显式协调者的情况。该协议引入了一个称为协调上下文（Coordination Context）的SOAP头块，用以唯一地识别联合工作中将要着手进行的部分。为了启动工作的接合部分，Web服务会向一个或多个目标服务发送协调上下文。收到协调上下文后，接收方服务会得到提示，说有联合协作请求提出。协调上下文中包含了足够的信息，请求接收者可以利用这些信息来确定是否参与该工作。协调上下文中包含的确切信息根据被请求工作的种类的不同而变化。

    协调类型集是可扩充的。只要参与该联合工作的每个服务对所需行为都有个一般的了解，新类型就可以通过实施来定义。例如，原子事务是Web服务架构中已经定义了的几个初始基础协调类型之一。如果被请求的协调类型被理解并被接受，Web服务就会使用WS-Coordination注册协议来通知协调者并参与该联合工作。协调上下文中包含了协调者的一个端点引用和可能行为的可选标识符。注册操作指定该多方参与的Web服务所支持的行为。一旦注册消息发送到协调者，Web服务就会依照它们所预订的协议参与该工作。注册是协调框架中的关键操作，它允许意欲协同配合以完成工作的共同单元的不同Web服务相互连接在一起。

    WS-AtomicTransaction为Web服务指定了传统的ACID事务，并为原子事务协调类型定义了3个协议：完成协议（Completion Protocol）和两阶段提交协议（Two-Phase Commit Protocol）的两个变体。完成协议用于启动提交处理。为完成而注册的Web服务能够通知指定的协调者何时开始提交处理。该协议还详细说明了用于通知启动者事务最终结果的消息。不过，该协议不要求协调者确保启动者对结果进行处理。相反，WS-AtomicTransaction中的其他行为则要求协调者确保参与者对协调消息进行处理。

    两阶段提交（2PC）协议为所有已注册的参与者提供了一个公共的提交或中止决定，确保了所有参与者都能得到最终结果通知。顾名思义，它使用两轮通知来完成该事务。该协议的两个变体是：易失2PC（Volatile 2PC）和持久2PC（Durable 2PC）。这两个协议在线上使用相同的消息（对应于Prepare、Commit和Abort操作），但易失2PC没有持久性要求。易失2PC协议供管理易失资源的参与者使用，如缓存管理器或窗口管理器。这些参与者在第一轮通知中不与协调者发生联系，且不需要第二轮的通知。持久2PC协议供管理数据库和文件等持久资源的参与者使用。当某一提交处理已经启动时，在所有易失2PC参与者被联系过之后这些参与者会第一次被联系。这使缓存能够被刷新。持久2PC参与者需要完整的两轮通知来实现协调者所要求的全有或全无行为以及完成该事务。这些行为最适合于可以在整个事务期内持有资源，且该事务通常为非常短暂的事务的情况。该协议保证在正常处理的情况下，协调者提供第一阶段结果的同时将联系所有参与者。对于完成时间预计将比较长的事务，或当资源（如锁）无法持有时，其他协调协议就会定义替换行为。

    WS-AtomicTransaction中定义了若干策略断言，这些策略断言使用WS-Policy中定义的方法来表示。

排队系统（Queued System）
    构建分布式系统时被证明非常有用的一种模式是使用事务持久队列来提供存储转发异步消息传送。在这种模式下，原子事务被用于每一个传输端点。在发送端，发送应用程序以原子事务方式将消息发送给一个持久队列，此时应用程序和队列管理器都使用WS-AtomicTransaction来进行协调。只有在处理消息时不发生错误，消息才被认为成功发送至该队列。接下来，发送队列和接收队列之间消息的传送由队列子系统来接管。该传输步骤可以在消息置入发送队列之后的某一时刻完成。此外，发送队列的位置无需与发出消息的应用程序的位置一致。与此类似，从接收队列检索消息的应用程序也使用原子事务来执行类似操作。也就是说，只有不出现处理错误时消息才能从队列中移除。

持续时间长的活动（Long Duration Activities）
    WS-BusinessActivity为运行时间长的事务指定了两个协议。WS-BusinessActivity规范在事务提交之前并不锁定资源，而是基于补偿操作。底层事务模型是所谓的开放嵌套事务。这些协议系统化地说明了松耦合服务如何对已经完成某一联合任务达成一致意见。在其中的一个协议中，协调者显式地通知参与者没有更多的工作正在以联合任务的名义被请求。在另一个协议中，该参与者就是通知协调者以联合任务名义出现的工作已经完成的参与者。使用补偿操作可以在不锁定这些操作的情况下完成试验性操作。不管出于何故，只要系统想要撤消已完成的试验性操作结果，就要启动补偿操作。WS-AtomicTransaction和WS-BusinessActivity都利用WS-Coordination来管理Web服务之间的协作。

三方握手
    三方握手连接的建立和解除协议是不需要指定协调者服务的协调协议的一个例子。为了建立连接，发送者要向接收者发送一个请求。该请求建立一个会话。如果该请求被接受，接收者就会发出一条确认消息，对该请求作出积极响应。发送者然后再发送一条消息，作为对该确认消息的确认，从而证明双方都知道对方已经建立了一个会话。

    解除协议类似。一方向另一方发送一个会话解除请求。接收者以对解除消息的确认消息作为响应。接收到该确认消息之后，发出解除消息的一方通过再对该确认消息发送一条确认消息结束消息交换。

枚举、传输和事件
    本节介绍提供Web服务架构中的服务资源枚举、其状态管理和事件通知的规范。这些规范基于WS-Enumeration、WS-Transfer和WS-Eventing。

枚举（Enumeration）
    很多情况所要求的数据交换都使用不只一对的请求/响应消息。需要这些更长时间数据交换的应用类型包括数据库查询、数据流、命名空间等信息的遍历和枚举列表。特别是枚举，它是通过建立数据源和请求者之间的会话来实现的。会话中接连不断的消息用于传送正在被检索的元素的集合。对于该服务用于组织将要生成的项的方法不作假设。在正常处理的情况下，枚举应在会话结束前生成所有底层数据。

    WS-Enumeration指定了用于建立枚举会话和检索数据序列的协议。枚举协议允许数据源向正在使用的服务提供一个叫做枚举上下文的会话抽象。该上下文通过一个数据项序列来表示逻辑光标。然后，请求者将该枚举上下文用于一个或多个SOAP消息的某一区间以请求数据。枚举数据表示为XML Infoset。该规范还允许数据源提供一种自定义机制来开始新的枚举。既然枚举会话可能需要若干个消息交换，那么会话状态必须保持稳定。

    关于迭代进度的状态信息可以由数据源或正在使用的服务在请求间维护。WS-Enumeration允许数据源一个请求一个请求地决定哪一方将负责维护下一个请求的状态。这种灵活性实现了若干种优化。例如，使服务器能够避免对调用之间的任何光标状态进行保存。由于消息潜伏时间对于支持若干个同时枚举的服务来说可能会很长，不保存状态可能会使必须维护的信息总量大大减少。资源受限设备（如移动电话）上的服务实现可能根本无法维护任何状态信息。

传输（Transfer）
    WS-Transfer详细说明了对通过Web服务进行访问的数据实体进行管理所需的基本操作。要了解WS-Transfer需要介绍两个新术语：工厂（Factory）和资源（Resource）。工厂是能够从其XML表示形式创建资源的Web服务。WS-Transfer引入了用于创建、更新、检索和删除资源的操作。应当注意，对于资源状态维护，宿主服务器最多也只能做到尽力而为。当客户端获知服务器接受了创建或更新某一资源的请求时，它可以适当地预期资源目前在的确定位置，并具有确定了的表示形式，但这并不是一个保证——即使是在没有任何第三方的情况下。服务器可能会更改某一资源的表示形式，可能会彻底删除某一资源，也可能会恢复已经删除的某一资源。这种保证的缺乏与Web提供的松耦合模型一致。如果需要，服务可以提供非Web服务架构所必需的附加保证。

    WS-Transfer的创建、更新和删除操作扩展了WS-MetadataExchange中的只读操作功能。检索操作与WS-MetadataExchange中的Get操作完全相同。Create请求发送给工厂。然后，工厂创建被请求的资源并确定其初始表示形式。工厂被假定与所创建的资源不同。新资源被分配给一个在响应消息中返回的，由服务决定的端点引用。Put操作通过提供一种替换表示形式来更新资源。资源表示形式的一次性快照与WS-MetadataExchange中的Get操作一样，也可以通过WS-Transfer中的Get操作来检索。Delete操作成功后，资源将无法再通过端点引用来使用。这4个元数据管理操作构成了Web服务中状态管理的构建基础。

事件（Eventing）
    在由需要相互通信的服务构成的系统中，可能会使用异步消息传递。在很多情况下，由一个服务生成的信息也是其他服务所需要的。由于伸缩性差，轮询往往不是获得这种信息的有效方法；通过网络发送的不必要的消息太多了。相反，该架构需要一种当事件发生时发出显式通知的机制。更重要的要求是源服务和用户服务的绑定必须在运行时动态完成。为此，Web服务架构提供了一个轻量级事件协议。

    WS-Eventing详细说明了实现下面4个实体交互的机制：订户、订阅管理器、事件源和事件接收。这使某一Web服务在作为一个订户时能够登记它对另一个Web服务（事件源）所提供的特定事件的兴趣。这种注册叫做订阅。WS-Eventing定义了某一服务可以提供的支持订阅创建和管理的操作。当事件源判定有事件发生时，它就会将此信息提供给订阅管理器。订阅管理器然后可以将该事件传送给所有匹配的订阅，这类似于传统的发布/订阅事件通知系统中的发布主题。Web服务架构提供了主题定义、组织和发现方式的全面灵活性；它为在很多不同的应用场合中可能会用到的订阅提供了一个通用的管理基础架构。也可以订阅出租的资源，但最终都必须收回。用于收回资源的主要机制是各个订阅的到期时间。查询订阅状态同样也有一种机制，帮助订户管理其若干订阅事项（包括续订、通知和取消订阅的请求）的附加操作规范中也有详细说明。当然，任何服务都可以随时自由地终止订阅，这与所有Web服务的自主原则一致。订阅终止消息可供事件源通知订户订阅终止过早。

    虽然基于事件的异步消息的一般模式很常见，但不同的应用通常都要求使用不同的事件传送机制。例如，在某些情况下简单异步消息可能是最佳选择，但如果事件接收能够通过轮询控制消息流和消息到达时间，则其他情况可能会更适用。当接收无法从源头到达目的地时，如接收有防火墙阻拦的情况下，轮询也是必要的。WS-Eventing中所引入的传送模式概念就是用来支持这些要求的。传送模式被用作一个扩展点，以便为订户、事件接收和事件源建立定制的传送机制提供一种手段。下述管理规范利用了这种机制。

    事件代理可用于聚合或重新分配来自不同来源的通知，代理还可以用作独立的订阅管理器。这两个方法都得到了WS-Eventing的支持。代理在系统中可以扮演若干个重要角色。主题可以按特定的应用类来组织使用。代理可以充当通知聚集器，用于整合来自多个来源的事件信息。它们也可以充当过滤器，这比用于其自己通知的过滤器所接收的消息要多。这种灵活性是部署健壮而可伸缩的通知系统所必需的。

管理（Management）
    管理功能是要讨论的Web服务架构的最后一个方面。这些功能在WS-Management规范中有详细的说明。WS-Management构建于该架构的若干组件之上，提供了所有系统管理解决方案都必需的一个公共操作集。其中包括发现管理资源存在及其相互导航的能力。个别管理资源（如设置和动态值）可以被检索、设置、创建和删除。容器和集合的内容，如大表和日志，可以被枚举。规范最后定义了事件订阅和特定的管理操作。在这些方面，WS-Management只详细说明了最低的实现要求。规范还使符合WS-Management的实现可以部署到小型设备。同时，它还支持向大型数据中心和分布式安装的扩展。此外，各种机制的定义都不依赖于任何暗示的数据模型或系统健康模型。这种独立性使它可以应用到各种各样的Web服务。

    WS-Management要求托管资源的引用使用带有特定附加信息的端点引用。该信息包含了对该资源提供访问的代理的URL、该资源所属资源类型的唯一标识符URI以及识别该资源的零个或更多个密钥。这些密钥被假设为名称/值对。该信息是这样映射到WS-Addressing端点引用的：资源的URL映射到地址属性，资源类型标识符映射到一个名为ResourceURI（在适当的XML命名空间中）的特定引用属性，各密钥分别映射到一个名为Key、属性为Name的引用参数。为了满足管理服务的消息传递需要，规范为操作定义了3个限定符。这些限定符的SOAP表示位于header元素中。operation timeout指定了一个截止时间，之后操作将不需要接受服务；locale元素在需要或期望转换底层信息时使用；freshness限定符用于请求最新的值并避免返回陈旧数据。对于使用WS-Transfer操作的数据访问，WS-Management指定了另外3个限定符。Get操作可用于SummaryPermitted header和NoCache header。如果可用，SummaryPermitted限定符允许传输简略表示形式。NoCache限定符要求传输最新数据，禁止信息缓存。对于Put和Create操作，ReturnResource限定符要求服务返回资源的新表示形式。ReturnResource使资源受限的Web服务能够在更新资源时不保留状态。

    WS-Management为事件通知定义了3个自定义的传送模式：批、拉和捕获。这些模式都由URI来识别，这些URI在建立订阅时使用。批传送模式使订户能够接收捆绑在一个SOAP消息中的多个事件消息。订户可能还会要求捆绑某一最大数目的事件、服务收集事件可耗用的最长时间，以及应返回数据的最大量。拉传送模式使生成服务的数据能够维护事件的逻辑队列，以便订户能够按需轮询通知。该轮询是通过使用WS-Enumeration和返回时附带订阅响应消息的枚举上下文来完成的。最后，如果UDP多路广播是一种合适的消息传递方式，捕获传送模式便允许事件源使用它。在捕获模式下，事件源可以将其通知发送给某一预定义的UDP多路广播地址。

结束语
    本文介绍了Web服务架构的功能构造块及其底层原理。每个构造块都是依据协议规范来阐述的。我们希望本文所述的功能范围和指导原则保持不变。不过我们也希望架构能够得到扩展，以支持更多情况。能够支持创新是该架构的基本特征。

    已经进行的大量细致入微的工作可以确保各种Web服务协议能够不加变动地相互组合；尽管是一起设计的，它们仍可以以非常多的组合方式来使用。和功能构造块一样，它们的使用方式与传统开发框架类似。必要时，如对于SOAP附件，我们已经开发了新的解决方案，而且不加变动它们就可以很好地用于该架构内。关注组合不是对丰富功能的威慑。

    该架构的SOAP消息传递基础保证了 foundation assures wide reach。SOAP消息传递以一种传输独立的方式支持异步和同步模式。具有更高灵活性的基础架构不存在。为了加快Web服务架构的广泛采用，很多技术合作伙伴都参与了这些规范的制定。与这些重要技术提供程序的合作加快了设备和支持这些在线协议的编程环境的部署。实现广泛覆盖、广泛采用和与规模无关的构造是我们的3个核心目标。我们力争确保该架构能够在任何平台上用任何编程语言来实现。该架构基于消息的和基于协议的特性为此提供了便利。必要时，如只使用WS-Security来支持消息完整性、机密性和身份验证，以及只使用WS-Policy来表示元数据时，我们已经限定了用于提高互操作水平的技术方法的使用领域。理论上讲，只要实现切实遵守该架构的协议规范，它们就能与其他任何Web服务通信。

附录A：术语表
    活动请求者（Active Requestor）——活动请求者是能够发出如WS-Security和WS-Trust中所述的Web服务消息的应用程序（可能是Web浏览器）。

    身份验证（Authentication）——验证安全凭证的过程。

    授权（Authorization）——根据提供的安全凭证授权访问安全资源的过程。

    规范化（Canonicalization）——将XML文档转换成符合每一方要求的格式的过程。在签名文档和解译签名时使用。

    断言（Claim）——断言是对发送者、服务或其他资源（如名称、身份、密钥、组、特权、功能等）所作的陈述。

    协调上下文（Coordination Context）——一组协调服务要完成的一组工作的唯一标识符。

    反序列化（Deserialization）——从一个八位字节流构建XML Infoset的过程。它是用于从消息的有线格式创建消息的Infoset 表示形式的方法。

    摘要（Digest）——摘要是八位字节流的加密校验和。

    域（Domain）——安全域代表安全管理或信任的一个单元。

    持久的两阶段提交（Durable Two Phase Commit）——用于文件或数据库等持久资源事务的协议。

    有效策略（Effective Policy）——有效策略，针对某一给定的策略主题，是附加在包含该策略主题的策略范围上的策略组合。

    交换模式（Exchange Pattern）——用于服务之间消息交换的模式。

    工厂（Factory）——工厂是可以从XML表示形式创建资源的Web服务。

    联盟（Federation）——联盟是已经建立相互信任的信任域的集合。信任级别可能变化，但通常都包括身份验证，并可能包括授权。

    身份映射（Identity Mapping）——身份映射是创建身份属性之间关系的一种方法。某些身份提供程序可能会利用身份映射。

    身份提供程序（IP，Identity Provider）——身份提供程序是为最终请求者提供身份验证服务的实体。身份提供程序还为服务提供程序提供数据源验证服务（这通常是安全性令牌服务的一种扩展）。

    消息（Message）——消息是可由服务发送或接收的完整数据单元。它是信息交换的独立单元。无论何时消息都会包含SOAP信封，并有可能包含附加MTOM中指定的MIME部件、传输协议header。

    消息路径（Message Path）——遍布在初始源和最终接收者之间的SOAP节点集。

    被动请求者（Passive Requestor）——被动请求者是一个使用得到普遍支持的HTTP（如HTTP/1.1）的HTTP浏览器。

    策略（Policy）——策略就是策略选项集。

    策略选项（Policy Alternative）——策略选项就是策略断言集。

    策略断言（Policy Assertion）——策略断言表示特定于域的单个要求、功能、其他属性或行为。

    策略表达式（Policy Expression）——策略表达式是策略的XML Infoset表示形式，可以是正规形式，也可以是等同的压缩形式。

    主体（Principal）——可以被授予安全权限或可以给出安全性或身份断言的任何系统实体。

    协议组合（Protocol Composition）——协议组合是在保持技术连贯性的同时组合协议并避免任何非指定功能副作用的能力。

    资源（Resource）——资源是可由端点引用寻址的任何实体，在该端点引用中，该实体可以提供其自身的XML表示形式。

    安全上下文（Security Context）——安全上下文是一个抽象概念，指的是已建立的身份验证状态和可能具有与安全有关的附加属性的协商密钥。

    安全上下文令牌（Security Context Token）——安全上下文令牌（SCT）是安全上下文抽象概念的有线表示形式，它使上下文能够被URI命名并和一起使用。

    安全性令牌（Security Token）——安全性令牌用于表示一组断言的集合。

    安全性令牌服务（Security Token Service）——安全性令牌服务（STS）发行安全性令牌的Web服务。更确切地说，它根据它所信任的证据来作出断言，并发送给信任它的任何一方（或特定接收者）。为了表明信任，服务需要证据（如签名），以证实安全性令牌或安全性令牌集提供的信息。服务本身可以生成令牌，也可以通过它自己的信任陈述依靠某一独立的STS发行安全性令牌（注意，对于某些安全性令牌格式，这只能是重新发行或联合签名）。这构成了信任代理的基础。

    序列化（Serialization）——将XML Infoset表示为八位字节流的过程。它是用于创建消息的有线格式的方法。

    服务（Service）——通过消息来与其他实体进行交互的软件实体。注意，服务不需要连接到网络。

    签名（Signature）——签名是通过加密算法计算出来，并绑定到数据的一个值。而且经过绑定，数据的指定接收者可以使用该签名来验证数据没有改变并发自消息的签名者，从而提供了消息完整性和身份验证。签名的计算和验证可以通过对称或非对称密钥算法来进行。

    退出（Sign-Out）——退出是这样一个过程：某主体表明它们将不再使用其令牌且该域中的服务可能会破坏该主体令牌缓存。

    单点登录（SSO，Single Sign On）——单点登录是对身份验证序列的一种优化，旨在消除在请求者身上进行的反复操作负担。为了便于进行SSO，称为身份提供程序（Identity Provider）的元素能够以请求者的名义充当代理，将身份验证事件的证据提供给请求该请求者信息的第三方。这些身份提供程序（IP）是受信任的第三方，既需要得到请求者的信任（以维护请求者的身份信息，因为该信息的丢失可能会泄露请求者身份），又需要得到Web服务的信任，Web服务可能会根据该IP提供的身份信息的完整性提供对重要资源和信息的访问权。

    SOAP中介（SOAP Intermediary）——SOAP中介是一个SOAP处理节点，它既不是原始消息发送者，也不是最终接收者。

    对称密钥算法（Symmetric Key Algorithm）——一种加密算法，其中的消息加密和解密都使用相同的密钥。

    系统（System）——实现某一特定功能的服务的集合。与分布式应用程序意思相同。

    信任（Trust）——信任表示一个实体愿意依靠另一个实体来执行一组操作，对一组主题、范围作出一组断言。

    信任域（Trust Domain）——信任域是一个得到有效管理的安全空间，在其中，请求的来源和目标可以确定来自某一来源的特定凭证集是否符合该目标的相关安全策略，并对此达成一致。目标可以将信任决定延期至第三方的加入（如果这已被确立为一致意见的一部分），从而将受信任的第三方包括在信任域中。

    易失的两阶段提交（Volatile Two Phase Commit）——用于缓存或窗口管理器等易失资源事务的协议。

    Web服务（Web Service）——Web服务是一种可重复使用的软件组件，它依据XML、SOAP和其他业界公认的标准通过网络实现交互式的消息交换。

附录B：XML Infoset信息项
    XML文档可以包含11类信息项。下面，我们列出并详细说明了SOAP所支持的信息项，并简要介绍了其他的信息项。SOAP支持6类信息项：

文档（Document）：每个信息集里都有一个文档信息项。它用于引用所有的其他信息项。 
元素（Element:）：文档中每个XML元素的信息集中都包含一个元素信息项。对所有元素的访问是通过对Child属性的递归跟踪提供的。 
属性(Attribute)：文档中每个属性的信息集中都包含一个属性信息项。附加属性信息项用于命名空间。 
命名空间(Namespace)：每个在其父元素范围内的名称空间信息集中都包含一个名称空间信息项。 
字符(Character)：文档中每个数据字符的信息集中都包含一个字符信息项。 
注释(Comment)：除了出现在DTD中的以外，文档中每个注释的信息集中都包含一个注释信息项。 
    SOAP不支持但出现在XML Infoset初始定义中的5类信息项是：处理指令(Processing Instruction)、文档类型声明(Document Type Declaration)、未扩展的实体引用(Unexpanded Entity Reference)、未解析实体(Unparsed Entity)和表示法(Notation)。

附录C：常见的安全攻击
    对分布式系统的攻击可以分为若干个方面。它们可以指向系统中的一个或多个主机，或指向它们之间的通信网路。攻击的目的可能是中断操作、获得机密信息或在系统内部执行未授权的操作。它们可能会攻击系统中所使用的加密技术或以安全性为中心的其他技术，也可能企图通过攻击下面的系统和网络层或上面的应用层来旁路它们。以下是一个简短的不全面的安全性攻击类及针对每类攻击的标准对策的列表，它们是按上述的几个方面组织编排的：

对主机的攻击
拒绝服务（DoS，Denial-of-Service）攻击通过击垮主机的响应能力来中断其操作 
    当指向加密层时，DoS通常会尽力迫使主机反复执行特定身份验证或密钥交换协议所需的计算代价高昂的公钥操作。对抗这类攻击的典型防御措施是延迟公钥操作，直到对话者的合法性能够通过花费较少的方法（如对称加密或“谜语”）来验证时为止。DoS对底层网络层或顶层应用层的攻击很难预防，特别是在攻击者控制着大量资源且通信量处于正常通信量难以觉察的情况下。要实现网络基础架构的部署，通常必须通过漏斗方式将通信量降至一个可管理水平。

主机机密性或授权攻击企图泄露隐私或身份 
    这些攻击可能会利用主机软件中的薄弱点来获得对主机的控制。适当的安全性管理，如安装补丁、配置防火墙以及削减暴露应用程序的特权，是比较常用的对策。另一类攻击利用系统或应用程序中的弱点，如设置不正确的策略或应用程序逻辑错误，除了一般的主机泄密以外，它们还会考虑机密性或授权泄密。恰当的安全性策略管理和周密的应用程序设计是对付这类攻击的唯一防御措施。在“电子欺骗”攻击中，攻击者企图通过冒用某一经过授权的其他方的身份并做出相应的行为来获得对各种操作的授权。只要主机和经授权方切实保护好身份验证密码，并正确使用安全的身份验证协议，就可以预防电子欺骗。

对通信网路的攻击
DoS对网络的攻击试图中断与服务的通信 
    和对主机网络层的攻击一样，这些攻击确实也只能使用网络基础架构方法来应对。

对网络通信机密性的攻击企图在线泄露隐私 
    明文通信的直接监听可以通过加密来阻止。通过足够强大的加密算法和足够长的密钥，密码分析攻击也可以被扼制。

对网络通信授权的攻击企图泄露身份 
    攻击者企图将消息插入会话的“消息伪造攻击”和攻击者修改会话中发送的消息的消息，变更攻击都可以通过包含消息身份验证的消息安全性协议来阻止。攻击者将以前发送的（因而通过了正确的身份验证）消息插入会话的消息重放，攻击可以通过序号或时间戳和消息缓存的组合来检测和阻止。
 

2 Dynamic Proxy
根据远程wsdl，利用javax.xml.rpc.Service的getPort函数，可以得到远程ws的一个 D
ynamic Proxy
编写代理接口

public interface HelloClientInterface
extends Java.rmi.Remote
{
    public String getName(String name)
        throws Java.rmi.RemoteException;
}
 

客户端程序TestHelloClient.Java 

import Javax.xml.rpc.Service;
import Javax.xml.rpc.ServiceFactory;
import Java.net.URL;
import Javax.xml.namespace.QName;

public class TestHelloClient 
{
    public static void main(String[] args)
        {
        try
        {
   String wsdlUrl = "http://localhost:8080/axis/HelloClient.jws?wsdl";
   String nameSpaceUri = "http://localhost:8080/axis/HelloClient.jws";
String serviceName = "HelloClientService";
String portName = "HelloClient";
ServiceFactory serviceFactory = ServiceFactory.newInstance();
Service afService = serviceFactory.createService(new URL(wsdlUrl),
           new QName(nameSpaceUri, serviceName));
 HelloClientInterface proxy = (HelloClientInterface)afService.getPort(new QName(
              nameSpaceUri, portName), HelloClientInterface.class);
 System.out.println("return value is "+proxy.getName("john") ) ;
        }catch(Exception ex)
        {
            ex.printStackTrace() ;
        }
    }
}
 

3 DII
Dynamic Invocation Interface 这个最好理解，比如你动态获得了一个类，只知道类的
名字，你要调用他的一个方法，只好使用reflection得到你要调用的类，相应的参数信
息，然后调用
使用DII调用WS的时候，你知道的只是一个WSDL的地址，通过解析wsdl，你可以得到相应
的ws endpoint的信息，然后通过javax.xml.rpc.Call的setOperationName， addParam
eter等函数来指定要调用的函数，指定参数，然后调用
提供DII调用的原因是，我们有可能使用程序自动的去动态调用网络上的WS，而这个WS的
一切信息都是来自其WSDL
,只有通过DII，我们才有可能动态的去调用这个ws
例子：
服务器端程序

public class HelloClient
{
    public String getName(String name)
    {
        return "hello "+name;
    }
}
把源码拷贝到AXIS_HOME下，并改名为 HelloClient.jws

客户端程序
import org.apache.Axis.client.Call;
import org.apache.Axis.client.Service;
import Javax.xml.namespace.QName;
import Javax.xml.rpc.ServiceException;
import Java.net.MalformedURLException;
import Java.rmi.RemoteException;

public class SayHelloClient2
{
    public static void main(String[] args)
        {
        try
                {
  String endpoint =  "http://localhost:8080/axis/HelloClient.jws";

    Service service = new Service();
            Call call = null;

            call = (Call) service.createCall();

            call.setOperationName
   (new QName("http://localhost:8080/axis/HelloClient.jws", "getName"));
            call.setTargetEndpointAddress(new Java.net.URL(endpoint));

 String ret = 
 (String) call.invoke(new Object[] 
     {"zhangsan"});
  System.out.println
  ("return value is " + ret);
        } 
                catch (Exception ex)
                {
       ex.printStackTrace();
        }
    }
}