BPEL的研究

转贴Mathew的文章，感觉是很好的学习资料
原文出处：http://blog.csdn.net/cissyring/category/278046.aspx

BPEL研究(1)：BPEL语言的基本特点

面向 Web 服务的业务流程执行语言(BPEL 或 BPEL4WS)是一种使用 Web 服务定义和执行业务流程的语言。BPEL 使您可以通过组合、编排和协调 Web 服务自上而下地实现面向服务的体系结构 (SOA)。BPEL 提供了一种相对简单易懂的方法，可将多个 Web 服务组合到一个新的复合服务（称作 业务流程 ）中。

（1）、 BPEL 规范

Web 服 务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL4WS）规范，其定位是成为整合方面的 Web 服务标准。您可以创建能够完成 Web 服务调用、抛出故障或终止一个流程等工作的不同活动，然后将它们连接起来，从而创建出复杂的流程。这些活动可以嵌套到结构化活动中，结构化活动定义了其中 的活动的运行方式，如串列或并行还是取决于某些条件。它从本质上来说是IBM的WSFL和Microsoft的XLANG的结合物，目前已经成为业界标 准。WSFL 支持图形化的流程，而XLANG在结构化构造方面有独到的方法，而BPEL4WS正是吸取了两者的优点，同时摒弃了一些复杂繁琐的部分，形成了一种较为自 然的描述商业活动的抽象高级语言。

（2）、BPEL语言特点

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语言的语法做较深入的研究，你就会发现它其实只是对原有编程语言思想的继承和发展。
(1)、关于继承，BPEL4WS语言拥有传统编程语言的一些基本特性，如：
赋值操作（由对〈assign〉的操作完成）；
循环操作（由〈while〉操作完成）；
选择操作（由〈switch〉和〈case〉操作完成）；
远程调用操作（由〈invoke〉操作完成）；
错误捕捉操作（由〈catchfault〉和〈catchall〉操作完成）；
错误抛出操作（由〈throw〉操作完成）
Java,C#语言中的try操作（由〈scope〉操作完成）
(2)、关于发展，BPEL4WS语言是一门结合了商业处理特点的语言；
由于BPEL4WS语言是专为商业流程的执行所服务的，因此它也就自然而然的具有一门商业处理语言的特点，这体现在以下几个方面：
² 提供了对于远程调用（〈invoke〉）的同步和异步处理；
这 主要是由商业处理的特点决定的，就拿民航订票来说吧，当你向民航订票系统的订票Web Service发出订票请求后，你不可能期望马上得到结果（同 步），因为民航系统必须要首先要进行复杂的身份识别以确定你的系统是否有预订机票的权限，接着还要查询航班情况以确定是否你定的航班还有空座，然后才会给 你答复，而你不可能一直等待得到答复，就算你愿意你的服务器恐怕也受不了这个负担。因此你必须选择异步方式，也就是发出请求后继续执行其他的操作，在这一 点上有一点类似于TCP/IP协议和UDP协议的关系。 
² 提供了并行的操作（由〈flow〉操作支持）； 
对 于普通的程序设计语言来说，并行的概念只是用于表面。打个比方，也许有人会说，利用windows系统（或者unix, linux系统）的多任务执行能 力，我可以让一个程序一边在后台执行计算而前台却进行复杂的人机交互工作，这不也是一种并行吗。的确，这也是一种并行，但它只是cpu级别的并行，而 BPEL4WS语言所体现的并行性是一种更广范围的并行，是基于INTERNET的并行，在某些方面，类似于传统的并行处理系统（利用机群进行大规模复杂 并行计算）。通过BPEL4WS，可以同时调用位于不同地方（不同城市甚至是国家）的Web Services进行处理（如计算，订货等）。 
² 提供了补偿的操作（由〈compensate〉操作支持）； 
任 何程序的执行都可能会出错，而后果也是不同的。有的操作出错并不会产生什么直接的后果，而有的操作出错的结果就必须被纠正，也就是必须执行一些补偿的操 作。比如拿民航订票来说吧，假如顾客A在系统中预订一张机票，当民航系统的Web Services完成所有订票操作后，提交给顾客A请求确认时，顾客A 由于其他原因取消了订票操作或者系统出现故障，那么就必须要执行补偿操作，取消所有已执行的操作，恢复数据库信息。从某个方面来说，这很类似于DBMS中 的ROLLBACK操作，只不过在数据库系统中是微观执行的，而在BPEL4WS中是宏观执行的。 

〈二〉 BPEL4WS并不"可执行"：
BPEL4WS 虽 然定义为一门商业执行语言，但实际上它并不执行商业流程中的任何细节，也就是说它一点也不涉及到商业数据的存储和处理。BPEL4WS语言从本质上来说应 该是一门描述性语言，它只是描述了什么时候？以什么顺序？到哪儿？去调用那些Web服务？怎样组织这些调用？罢了。因此，在BPEL4WS中并没有出现复 杂的数据结构和数据类型，也没有关于数据存储和持久化的操作，唯一涉及显式数据操作的地方就是〈Assign〉的使用了，但数据只是一些临时数据，一旦商 业处理的流程结束，这些数据也就消失了，这些数据就好像是传统程序语言中的变量一样，但又没有那么复杂的数据类型。说BPEL4WS语言是商业流程执行语 言是因为从宏观上看，所有的操作都由BPEL4WS来完成，而其背后的操作，如Web服务的调用等是不可见的，也就是说是不透明的。这就好比软件测试中的 黑盒测试一样，用户只看到了自己应该看到的用户接口，而不用去关心这些功能到底是怎样实现的。
〈三〉 BPEL4WS是真正的分布式系统：
随 着INTERNET的迅速发展，在分布式技术领域也不断涌现出新技术新思想。SOAP,XML以及基于它们的Web Services，这些新技术的出现 为新的分布式处理模型提供了坚实的基础，而BPEL4WS的诞生，才是分布式技术的真正升华。比起传统的分布式系统来说，利用BPEL4WS实现的分布式 系统具有更高的灵活性，这主要体现在以下几个方面：
1〉各个节点机可以为异构系统；
2〉可以在运行时动态选择节点机进行处理；
3〉可以采用各种通信协议进行通信，只要符合SOAP协议。

==============================================================

WS-BPEL 2.0规范参见http://www.oasis-open.org

 

BPEL研究(2): 目前主流和开源的BPEL引擎

前面简单介绍了一下BPEL的基本特性，年底了终于有些时间可以积淀一下了，针对前段时间对BPEL的研究，现在 主要交流一下目前的主流和开源的BPEL引擎。时至今日，几乎没有一个大的软件厂商不力顶SOA的，而Oracle也是其中一家，在SOA方面的投了大量 的资金。

1、Oracle BPEL工具套件是一套比较好的BPEL工具，包括引擎和定制工具以及管理控制台：

Oracle BPEL Process Manager 通过将一系列同步和异步的服务组合到一个端到端 BPEL 流程流中，简化了基于面向服务的体系结构 (SOA) 开发应用程序的流程。Oracle BPEL Process Manager 为设计、部署和管理 BPEL 业务流程提供了一个开发人员易于使用的可靠的解决方案。

Oracle BPEL Process Manager 包括三个主要组件：

JDeveloper BPEL Designer：

JDeveloper BPEL Designer 扩展了 Oracle JDeveloper 10g 的功能，并支持使用 BPEL 进行业务流程的建模、编辑和设计。它提供了一个图形化和用户友好的方式构建 BPEL 流程。JDeveloper 使用 BPEL 作为其原生格式，因此构建的流程是可移植的。

Oracle BPEL Process Manager Server：

Oracle BPEL Process Manager 提供了 BPEL 服务器的一个可伸缩的强健实现。Oracle BPEL Process Manager 执行标准的 BPEL 流程并提供“脱水”功能，因此长期运行流的状态在数据库中能够得以自动维护，从而实现了用于故障切换和可伸缩性的集群。BPEL Server 利用的是基础 J2EE 应用服务器。

Oracle BPEL Console：

Oracle BPEL Console 为管理和调试部署到 BPEL 服务器上的流程提供了一个基于 Web 的成熟界面。审计跟踪和流程历史/报告信息可通过 BPEL Console 和 Java API 自动维护和提供。

 

2、 IBM的WBI Server Foundation

WBI Server Foundation由运行环境和开发环境组成，它的开发环境是WSAD-IE，在WSAD-IE中完成流程开发后，将流程的EAR应用部署到运行环境中。

WBI Server Foundation 的运行环境提供一个高效的J2EE工作流引擎，它由流程导航(Navigator)、人员交互相关的工作项管理(WorkItem Management)、工厂(Factory)、内部和外部接口、客户端(Client)等部分组成。如下图：

导航器：导航器组件是流程引擎的核心，它管理所有流程实例的状态过渡以及这些流程实例中所有活动的状态过渡。

工作项管理：Work Item Manager 组件负责在流程引擎的数据库中创建和删除工作项，根据该数据库分析来自流程参与者的工作项查询等。

工厂：工厂组件负责管理流程引擎处理的"物理"状态信息，流程相关的数据能够以下列形式之一被存储：

• 瞬时存储在内存中，不可中断的流程要获得高效率的执行需要这种形式
• 持久存储在数据库中，可中断的流程要获得持久性需要这种形式

它支持的数据库包括 DB2、Oracle、Sybase 和 Cloudscape。

外部接口：流程引擎对外提供EJB和JMS两种接口，由Fa?ade-Session EJB 和 Fa?ade MDB 负责外部接口的同步生成和异步生成。

客户端：Server Foundation提供了Web客户端支持，同时用户可以利用其API接口开发自己的客户端。

其他组件：流程引擎包含一个负责产生诊断信息的跟踪和记录组件。

3、BEA Integration

4、开源的主要有

ActiveBPEL引擎的最新版本3.0，完全支持WS-BPEL2.0规范。其包含引擎和定制工具以及控制台。引擎是开源，但是定制工具并非开源。经过对比，此引擎也是目前开源BPEL引擎中不错的一个。

JbossBPEL 是jBPM的一个子部分，JBoss要进军SOA，故JbossESB和JbossBPEL为其不可或缺的一部分。JbossBPEL 基于开源的工作流jBPM开发的，把传统的工作流元素作了一个mapping

还有bexee、fivesight-pxe、twister等等，没有过多的接触所以不是很了解。

累了，今天就写到这。

对了简单的对比一下：

BPEL研究(3)：BPEL和WFMC

BPEL是使用 Web 服务定义和执行业务流程的语言，通过其能够很好的编排web服务，因此在SOA大兴其道的今天，BPEL成为流程编排方面的标准。在其之前的两年时间，我主要涉及的是传统意义上的人工工作流，即WFMC的一套标准。

其实怎么说呢，感觉这两个标准产生的背景和应用的场景还是有很多差异的。下面简单的和大家探讨一下，有不妥之处，请大家批评指正：）。

1、WFMC， 接触了两年多的时间，做的就是基于WFMC标准的工作流管理系统。其出现的背景就是办公以及公文流转吧。国外的一些传统EAI厂商(Tibco、 webmethod等)在这方面作的还是很不错的。而国内主要应用在OA及其他办公场景，不否认这其中也有很多中国特色的东西，比如流程规则比较特殊等等 (银狐兄在blog中有很多分析)。其实从WFMC本身来讲，其范围还是很大的。在实现的角度讲不但在人工工作流即交互层面并且可以调度Web服务。而其 目前大多这类系统仅应用在人工工作流方面。

2、BPEL主 要定位在整合Web服务的标准。本质上来说他是IBM的WSFL和Microsoft的XLANG的结合物。WSFL 支持图形化的流程，而XLANG在结构化构造方面有独到的方法，而BPEL4WS正是吸取了两者的优点，同时摒弃了一些复杂繁琐的部分，形成了一种较为自 然的描述商业活动的抽象高级语言。而其整合Web服务的特点整合迎合了SOA的趋势，在加上各大厂商的大力推广，已成为事实上的标准，目前ws- bpel2.0标准正在由Oasis维护。其主要特点是整合web服务，在人工流程方面基本是弱的。但是各大厂商像Oracle、IBM、BEA在其产品 中都加入了人工活动的节点。以适应更广泛的场景。由于BPEL只有统一的调用接口即WebService.因此为了调用其他像EJB、Java、JMS等 服务，必须先将其包装成web服务然后再调用，这样大大影响了执行效率。像Oracle等都采用了web服务调用框架(WSIF)来调用 webservice、ejb、java等。目前IBM和BEA还共同提出了一个BPELJ的私有标准，目的也是解决上述的问题。

总而言之，在应用中采用哪种标准的流程编排工具，需要结合具体的应用场景。不过在SOA的大势下，web服务的标准和基础环境的逐渐成熟，感觉BPEL会成为一种事实上的标准。

BPEL研究(4): ActiveBPEL 3.0

ActiveBPEL 引擎体系结构

ActiveBPEL 引擎执行业务流程执行语言 , 它接受 BPEL 流程的定义 , 创建流程实例 , 并执行它们 . ActiveBPEL 引擎在结构上有三个主要的方面 : 引擎 , 流程和活动 . 引擎执行相匹配的一个或多个 BPEL 流程 , 流程由活动组成 , 并按照活动的顺序或包含 LINK 执行 . ActiveBPEL 引擎根据 BPEL 流程的定义 (XML 文件 ) 创建流程实例 , 并执行这个流程。

Table of Contents

ActiveBPEL 引擎

The Engine

Figure 1. Engine Architecture

上图右边的数据库元素代表一般的持久性存储 . ActiveBPEL 引擎采用了插入式的结构 , 不同的管理器可以执行不同的存储机制 . ActiveBPEL 引擎伴有一个持续的管理者在内存中记录每件事。

Engine Startup

利用一个引擎工厂管理一个 ActiveBPEL 引擎的创建 . 应用处理服务的对象例如队列管理 , 警报和计时服务 , 流程配置使得引擎的各项职责互相分离 . 下面的代码描述了引擎工厂的创建和支撑服务。

engine = new Engine(getEngineConfigurationInfo(), createQueueManager(), createProcessStateManager()); engine.setPlanManager(createProcessDeploymentProvider()); createProcessDeploymentManager(); createWorkManager(); createAlarmAndTimerService();

引擎配置的处理是通过一个对象提供的缺省值并读取 aeEngineConfig.xml 文件 . 引擎连接一个队列管理器和一个流程状态管理器 , 对象负责执行履行那些服务给引擎 . 引擎是高度可配置的 , aeEngineConfig.xml 文件不仅描述了像缓存的大小和日志状态 , 也决定了各种管理器和处理器应用的类。

一个流程配置提供者处理读取流程配置描述 (.pdd)文件, 并且一个流程配置处理器处理流程的创建.一个工作管理器在时间上是异步操作。

Process Creation

一 个新的 BPEL 流程当它的起始活动被触发时创建 , 当接收到一个消息或是一个 PICK 活动的警报时活动被触发。当传入的消息包含相关的数据 , 引擎发现已经存在的流程替换匹配的数据。当引擎读取一个 BPEL 流程定义 , 它就创建对象并调用流程模型的活动定义。

Figure 2. Runtime Engine Object Creation

活动定义包含了一个 BPEL 活动执行对象的例示所需要的所有信息 . 当执行的对象类似于类的实例化对象 , 活动定义就与类相似。

引擎和它的事件监听都访问这些定义。这些事件包含一个 Xpath 值它表示了流程中的哪个活动正在触发事件 。 这些 Xpath 的值来自活动的定义。

引 擎采用访问者的模式访问活动定义对象模型来创建它的执行对象 , 并且从这个模型来创建执行对象。ActiveBPEL 引擎密封了任何关于流程构造的逻辑实现。举例来说 , 一个固有作用域的调用活动将产生一个带有外部作用域的单独的调用子活动。设计者或其他监听都不知道关于这些实现 , 因为他们只关注定义和它们的 XPATH 信息。

Input and Output

Activebpel 引擎本身并不处理输入和输出。 然而 , 协议规范处理器像 AeBpelRPCHandler 和 AeBpelDocumentHandler 把数据从一种特殊的协议转换为一种消息 ,反之亦然。

Data Handling

所有变量的实现通过 IAeVariable 接口。这个接口能够得到变量的定义和它的有效负载 , 如果变量被声明成一种相对的元素或消息 , 将会有所不同 。消息的负载需要一个和部件对象交互的接口 。

Expression Evaluation

所 有活动和链接允许使用对象各种属性的表达式。 这些表达式需要一个相容的方法来执行 并描述执行的相互关系。 IaeBpelObject对象本身可以包含这些实现并能够提供继承于对象的抽象基本类.BPEL对象是它自己的作用域并且可以被用来正确的找回表达式内 容的变量.赋值允许所有的XPATH扩展( for example, bpws:getVariableData )。

Debugging and Logging

在流程执行期间 ,ActiveBPEL 引擎激活流程的事件 。当日志启动 , 一个 AEEngineLogger 实例监听引擎的事件并写出每个流程的日志文件。一旦流程完成 , 文件关闭。

日志文件放在 {user.home} /AeBpelEngine/process-logs , {user.home} 是java系统属性”user.home”的值.日志被命名为process-id .log , process-id 是一个由引擎给出流程的 ID号码,为了启动日志,应用 BpelAdmin配置页, ( http://localhost:8080/BpelAdmin/config.jsp ) 。

Processes

一个流程的组成 :

Partner links

描述两个 web services 之间接口关系。

Partners

参与 web service 交易的实体。

Variables

值的容器.

Correlation sets

确定业务流程唯一的一套数据 . 在流程的不同时期 , 流程可以定义不同的相关集 .

Fault handlers

描述发生问题时的处理方法 .

Compensation handlers

描述如何退回已经完成的业务流程

Event handlers

处理引入的消息和警报 .

A top-level activity

一个单独的 BPEL 活动 , 通常是一个其他活动的容器 .

Dispatching Requests

每 个 BPEL 流程必须至少有一个起始活动 . 一个新的 BPEL 流程当它的起始活动被触发时创建 , 也就是一个引入消息或一个 PICK 活动的警报的到来 . 引擎分派引入的消息给正确的流程实例 . 如果有相关的数据 , 引擎就会发现正确的实例并匹配相关的数据 . 如果没有相关的数据 , 请求匹配一个新的活动 , 一个新的流程实例被创建 .

Figure 3. Request Dispatch Flowchart

Queued Receives

接 收队列包含了所有流程实例的当前在执行的 RECEIVE 活动 . RECEIVE 活动包括了消息活动 , 它是 PICK 或一个事件处理的一部分 . 接收队列也包含了来自外部的绑定的消息 , 如果和队列中等待接收的活动不匹配 , 它们本身是不能创建新的流程实例 . 一个不匹配的接收数据像给出的异步的 WEB 服务 . 引擎将接收这些所提供不匹配的消息 , 它们包含了相关的数据 . 这些消息留在队列里 , 直到超时为止 . 这个时间由引擎的配置参数 UnmatchedReceiveTimeout 指定 .

如 果一个流程队列的一个活动比如说一个 RECEIVE活动,它会一直保存在队列里直到数据到达或流程终止.PICK 略有不同:第一个匹配的消息或警报的到来,PICK活动立即设置其它的消息或警报的状态为DEAD_PATH.这将把它们从队列中移走.一旦定义他们的作 用域完成,事件处理器会自动把它们从队列中移走.

Activities

BPEL 流程由活动的块组成 . 基本的活动从概念上是一个简单的行为如接收一个消息 , 调用一个 WEB 服务 , 赋值给变量 . 结构化的活动与带有条件或循环构造的程序语言相似 . 特殊的活动介绍了变量 , 作用域和处理正常的活动像流程终止和补偿活动 .

活 动加入了 LINKS,有外部的或固有的.活动的路径和LINKS由多种因素决定,包括变量的值和表达式的值.每个活动都存在一个作用域,包括相关的变量,错误处理 和补偿处理.作用域在概念上与程序语言的介绍变量的域和处理exception相似.一些活动像Scope和Invoke产生了新的作用域,外部的或是内 部的.

BPEL Activities

Basic activities

Activity	Notes
<receive>	Block and wait for a message from a partner
<reply>	Reply back to the partner that sent the message we received
<invoke>	Call some other Web service, either one-way or request-response
<assign>	Assign or copy values to variables
<throw>	Generate a fault
<wait>	Wait for a given time period (time-out) or until a particular time has passed (alarm)
<empty>	A no-op

Structured activities

Activity	Notes
<sequence>	Execute children in order
<switch>	Just like a "switch" or "case" statement
<while>	Repeat an activity while a condition is true
<pick>	Block and wait for a message, time-out, or alarm
<flow>	Children are executed concurrently; links can provide additional control structure

Special activities

Activity	Notes
<scope>	Define a new scope for variables, fault handlers, and compensation handlers
<compensate>	Invoke compensation on an inner scope that has already completed normally
<terminate>	Immediately terminate a business process instance

States

每个活动都有一个相关的状态 , 这些活动进入或是退出这些状态都基于 BPEL 标准 . 活动也会触发事件 , 使得监听能够发现其状态的改变 . 有一些机制来监听这些事件 .

表示状态的常量定义在 AeBpelState中,一个活动必须是下列的状态之一:

State	Notes
INACTIVE	当流程开始的时候 , 所有 BPEL 的活动都是没有非活动的状态 All BPEL activities are in the inactive state when the Process starts
READY_TO_EXECUTE	准备执行 . 这些活动在它们的父队列里 , 它们的连接条件的值为 true. Ready to execute. These activities have been queued by their parent and their join condition has evaluated to true
EXECUTING	正在执行 . Currently executing
FINISHED	执行完成 , 没有出错 . Finished executing without a fault
FAULTED	执行完成 , 出错 . Finished executing with a fault
DEAD_PATH	由于绝对路径的消除从执行路径中移出 , 当一个父活动的状态变为 :DEAD_PATH, 这个状态会传给它所以的子活动 . Removed from the execution path due to dead path elimination. When a parent activity's state becomes DEAD_PATH , that state is propagated to all of its children
QUEUED_BY_PARENT	父活动的执行队列 . Queued for execution by their parents
TERMINATED	终止 . Terminated
Unknown	活动的状态为空 . 如果一个父活动的状态变为 unkown, 它的子状态变为 INACTIVE. The activity's state is null . If a parent activity's state becomes unknown, then the childrens' states change to INACTIVE .

ActiveBPEL的安装和配置

一、安装和配置 ActiveBPEL 引擎

本文档描述了如何安装 ActiveBPEL 引擎

（一）、依赖关系

ActiveBPEL 引擎要求安装和正确的配置 servlet 容器。 ActiveBPEL 引擎的安装脚本是用作环境变量，也就是 Tomcat 的最上层目录。 ActiveBPEL 引擎应该运行在任何标准的 servlet 容器下。

1 、下载 TOMCAT 5.x (http://jakarta.apache.org/tomcat).

安装 TOMCAT, 并设置环境变量 CATALINA_HOME 。（经过测试的版本为 Tomcat 5.0.25. ）

2 、下载软件： (http://www.activebpel.org/download)

其中有两张格式 a.tar.gz 或者 a.zip. 两张格式包含的文件是相同的。文件的名字为 activebpel-version-type.tar.gz 或 activebpel-version-type.zip 。版本号是： 1.0.1

类型为 "src" (source), "bin" (binaries), or "all" (source and binaries) 。解压缩下载的文件包，会创建一个名字为 activebpel-1.0.1 的目录。可以重新命名，或者一动到任何地方。以下的文档中，简称这个目录为 "activebpel" 。

 

（二）、安装 ActiveBPEL 引擎

1 、运行脚本 install.bat 。它将拷贝 lib 下的内容到 $CATALINA_HOME/shared/lib 目录下，并且创建 $CATALINA_HOME/bpr 目录，也就是存放流程的配置文件 .bpr 的目录。

执行命令行如下：

Windows:

    C:/> cd /activebpel

    C:/activebpel> install.bat

2 、更改引擎的配置参数

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

3 、启动 ActiveBPEL 引擎

启动 TOMCAT,.

Windows:

C:> %CATALINA_HOME%/bin/startup.bat

4 、停止引擎

关闭 TOMCAT

Windows:

    C:/> %CATALINA_HOME%/bin/shutdown.bat

5 、引擎的状态信息

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

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

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

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

 

二、 ActiveBPEL(TM) 引擎的持续安装

 

（一）、要使得 ActiveBPEL 引擎作为一个可持续运行的引擎来，需要做以下步骤：

    1 、安装数据库 Sqlserver 2000 和相关的正确的 JDBC 驱动，并且保证有权限创建数据库的表。 Jdbc 的驱动程序一定要到 sourceforge 网站去下载。下载后解压缩文件包，把其中的 jtds-1.0.3.jar 文件拷贝到 CATALINA_HOME/common/lib 下。

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

3 、设置 Tomcat 的数据源。打开 %CATILINA_HOME%/conf 目录下的 omcat-users.xml 文件，增加一个 “admin” 的角色， <role rolename="admin"/> ，然后增加一个角色为 admin 的新用户。

  增加数据源的操作如下：

（ 1 ）、重启 Tomcat, 并访问它的管理页 http://localhost:8080/admin/

（ 2 ）、输入用户名和密码

（ 3 ）、按照以下顺序点击左侧的 Frame

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

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

        JNDI = jdbc/ActiveBPELDB

        Data Source URL = jdbc:jtds:sqlserver://localhost:1433/ActiveBPEL

        JDBC Driver Class = net.sourceforge.jtds.jdbc.Driver

        User Name = [db user name]

        Password = [db password]

  （ 6 ）、按保存按钮，并提交（上方有一个 Commit 按钮）。

4 、修改 aeEngineconfig.xml 文件

   将 activebpel/dist/conf 下的 aeEngineConfig-Persistent.xml 文件拷贝到 %CATILINA_HOME%/bpr 目录下，并且重命名为 aeEngineconfig.xml ，原来的 aeEngineconfig.xml 文件则被覆盖掉。然后打开这个文件，  更改其中的一行关于数据库的信息 <entry name="DatabaseType" value="mysql" /> ，把 value 值改为 sqlserver 。

 

5 、 ActiveBPEL 数据库的配置文件

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

< 注： > 任何已经设置的 ActiveBPEL 引擎的配置参数现在被重新设置成缺省值。

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

三、配置 BPEL 流程示例 ( 以 custom_invoke 流程为例 )

为了配置一个 BPEL 流程，必须创建和安装一个包含 BPEL 流程文件的配置文档。

1 、这里要用到 jar ，所以需要一个 Java SDK,  任何版本都应该可以，其中经过测试的版本是 1.4.1 SDK 。安装 Java SDK, 并且配置环境变量 JAVA_HOME 。

2 、需要 ant 来运行 build.xml 文件。 Ant 测试过的版本为 Ant Version 1.5.1 。安装 ant 后，设置环境变量 ANT_HOME ，并且要在环境变量 path 里增加％ ANT_HOME ％ /bin; ％ JAVA_HOME ％ /bin 。以下的步骤假设已经安装了 ant （ CATALINA_HOME 一定要定义）

，并做好相应的配置。

3 、如果你的 ActiveBPEL 引擎安装程序不能在 "localhost:8080" 在运行，需要改变下列文件中的相关字符串： build.xml

       bpel_process/wsdl/loanapprover.wsdl

       bpel_process/wsdl/loanassessor.wsdl

4 、配置示例中的流程

在命令行中执行以下命令：

<installdir>/activebpel-version/samples/custom_invoke/ant deploy

该命令调用了两个目标程序： deploy-bpel and deploy-cih.

deploy-bpel 创建和安装了一个包含 BPEL 流程信息的 .bpr 文件。 deploy-cih 创建和安装了一个包含 custom invoke handlers 的 .jar 文件。

每次一个新的 jar 拷贝到 $CATALINA_HOME/shared/lib 下，重启 TOMCAT 后可以看到它。不需要每次执行 “ant deploy” 命令时都重启 TOMCAT, 仅仅当每次 deploy-cih 拷贝 jar 文件到 $CATALINA_HOME/shared/lib/ 下需要重启 TOMCAT. 这不同于重新配置一个 BPR, he ActiveBPEL 引擎会发现并重新装载它。

5 、在客户端运行 BPEL 流程

运行 ant client 命令调用 BPEL 流程，可以看到运行结果。

或者访问： http://localhost:8080/bpel_example_client_page/index.jsp 也可以看到运行结果。

四、配置自己的流程

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

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

    * bpel

    * META-INF

    * wsdl

    * partners (optional)

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

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

    mybpel

        META-INF

            wsdlCatalog.xml

        bpel

            my_process.bpl

        my_process.pdd

        wsdl

            service1.wsdl

            service2.wsdl

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

  应用这个目录结构 , 创建文档并拷贝的到 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 引擎知道它们在哪就可以 .

 ===================================================================================

注：上面两部分内容均出自部分网友。

目前我们使用ActiveBPEL3.0部署到Weblgoic8.1上，并进行了简单的测试。性能还是能够满足基本的应用。

BPEL研究(5): 开源的流程定制工具

  Oracle有个BPEL的流程定制工具，感觉做的还是很不错的，有两个版本一个是Eclipse的插件、另一个是for Oracle JDeveloper的插件。能够很简单的上手使用建模，并且可以免费使用。

         ActiveBPEL Designer是Active公司开发的一个ＢＰＥＬ设计工具结合其开源的引擎。在ActiveBPEL的官方网站可以进行申请下载，但不用用于商业用途。

       下面讲讲开源的Eclipse BPEL Designer为一个Eclipse的一个开源项目，如今项目比较活跃。主要有IBM、Oracle、大学等开发人员参与。早期的版本有点像ＩＢＭ的 ＢＰＥＬ设计器，猜测可能就是IBM捐了一部分程序。现在功能在慢慢的完善。同其开发人员有些沟通和交流，感觉过不了多长时间应该有一个比较好的开发工具 诞生。不过目前还是有些问题，比如说支持的BPEL版本问题、一些界面的小BUG等等，但基本一个能够使用此工具建立简单的BPEL模型了。如果大家在使 用中发现有什么问题及时反映给他们，希望不久有一个好的开源定制工具诞生。