引言

在为 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中的基本构造块可以划分为主要的三大类，每一类又可以细分为上图所示的许多小类。对于一个小型的项目来说，也许我们只会用到这些元素的一部分，但对于一个规模较大、较复杂的项目，特别是像BPEL4