BPEL

 服务正在成为应用系统开发的基本元素。
业务流程执行语言（BPEL）已经成为编排这些服务和管理业务流程的无缺陷执行的事实标准。
大多数业务流程都包含多个决策点。在这些决策点处，将对某个条件进行评估。业务流程根据这些标准或者业务规则更改他们的行为。这些业务规则对业务流程起到了推动作用。这些规则通常嵌入到业务流程本身或自定义 Java 代码的内部，这将导致在将来的某个时候出现若干问题：
1 业务规则比业务本身更改得更频繁，而更改和管理嵌入的业务规则是一个复杂问题，并超出了大多数分析员的能力范围。因此，随着业务规则的更改，程序员通常要消耗大量时间来执行该任务。
2 大多数组织都缺少中央规则信息库。因此，策略中任何涉及到组织范围的更改都无法运用到所有业务流程中。
3 业务流程无法重用规则。因此，IT 人员最终要为每个流程设计规则，这通常导致不一致性或冗余。
避免这些问题的最佳方法是使用规则引擎将业务流程与业务规则分离。在该方法中，规则公开为服务，而 BPEL 流程在到达决策点时通过查询该引擎来利用这些服务。该方法更为灵活 - 可以通过图形方式操作规则，而不是在编程语言中或在流程内部对规则进行编码。业务用户可以使用工具自行编写规则，并且无需 IT 人员的协助即可进行部署后的规则更改。由于大多数更新和功能增强是由业务用户执行的，因此可以显著减少维护成本。

规则引擎和 BPEL 是两种互补技术。Oracle BPEL 流程管理器提供了高级工具来显示、设计和管理 BPEL 流程，而第三方规则引擎使复杂的业务逻辑可以用类似英语的语法表示，并由非程序员领域专家对其进行编辑。

分离规则与流程
 将规则引擎集成到流程管理框架中要求事先进行一定量的投资。在尝试进行此集成之前，将规则与流程分开是很重要的。因此，系统体系结构方面的一个主要决策是如何实现业务策略、业务流程和支持业务逻辑。实际上，架构师必须交流或设计最佳实践，以便设计人员在设计系统功能时知道应在何处应用每个相关技术 - BPEL、业务规则、Java/Web 服务。
1.业务流程层(business process layer)
      该层负责管理业务流程的总体执行。这些使用BPEL实现的的业务流程可以是长期执行的业务流程,事务业务流程以及持久业务流程。流程逻辑支持分布到 Web 服务/EJB 调用中的高级事务（“sagas”）以及嵌套的子流程事务。BPEL 引擎支持对工作流进行审计和检测，因此比较适合于
 将不易变化的工作流步骤与易变的业务规则分开
 实现行业流程
 实现需要补偿的流程
 支持流程的大型实例化
 设计需要审计的流程
 协调异构技术，如连接器、Web 服务和支持 Web 服务调用框架 (WSIF) 的逻辑

2.web服务层 (web service layer)
 Web 服务层将现有的应用程序层功能公开为服务。这样，多个业务流程便可以重用这些服务，从而实现面向服务体系结构 (SOA) 的承诺。
Web 服务实现功能逻辑和域逻辑。功能方法通常是无状态和中等粒度的。例如，Web 服务可能包含系统数据的实用程序方法、实体操作和查询方法。可以使用多种技术实现 Web 服务并隐藏实现平台之间的差别。因此，该层比较适合于：
 为特定实体/域领域实现中等粒度的方法
 集成原有的代码/第三方工具
 封装应用程序层中的逻辑、自定义代码和实现
 
3.规则层  (rules layer)
 规则引擎通常是复杂逻辑（涉及实体之间的一些相互依赖性以及与顺序相关的逻辑计算）的发源地。从业务流程中以单独实体的形式提取业务规则可更好地对系统进行分离，从而提高可维护性。
 规则引擎可以对规则集进行并行和按顺序的评估。此外，规则能够对输入数据和中间数据的值进行评估并确定是否应引发规则。与传统的 Java 过程代码相比，该模块设计提供了一个更简单、可维护性更高的解决方案。
 此外，正如我在前面指出的，规则具备声明特性，并使业务分析员能够进行高级 GUI 编辑。现代规则引擎的执行速度非常快，并提供了内置的审计记录。规则层的典型特性包括
 包含耦合和复杂的逻辑
 支持使用并行执行进行高效的业务逻辑评估
 包含基于多个业务规则评估构建的复杂返回结构
 允许将域逻辑转换为简单规则
 实现高度易变的业务策略
 由于规则在 Web 服务层中公开为服务，因此可以在所有企业间应用程序中重用，从而简化了新应用程序和集成的开发。

包含文件:
.project eclipse格式工程文件
bpel.xml 工程配置描述符.定义(工作流中服务配置)wsdl文件的位置.以及其他工程参数.
build.xml 编译和部署工程文件.
*.bpel 工程的bpel资源文件.
*.wsdl 程序的wsdl接口.