版权声明:本文转自oracle technology network原文地址:http://www.oracle.com/technology/global/cn/pub/articles/bpel_cookbook/chandran.html
将 BPEL 添加到企业集成混合环境
作者:Praveen Chandran 和 Arun Poduval
利用 Oracle BPEL 流程管理器的编排功能实现对传统 EAI 中间件起到补充作用的基于标准的业务流程集成。
大多数企业都拥有一个迥然不同的应用程序基础架构,其中包含由多个供应商提供的、在不同平台上运行以及使用完全不同的技术创建的各种应用程序。为了解决这些集成难题,TIBCO、webMethods、Vitria 以及 SeeBeyonda 等公司在过去的十年里相继推出了传统的企业应用程序集成 (EAI) 产品。在过去的几年里,许多企业在这些 EAI 解决方案上进行了大量的投资。因此,EAI 领域中的业务集成通常锁定到单个供应商,并且集成组件被紧密耦合在一起。
这些专用集成链接的维护成本为企业带来了沉重的负担。而专门技能的必不可少加重了成本和稳定性方面的问题。此外,对于保护 EAI 中的大量投资的企业而言,破坏并替换现有的 EAI 解决方案并不是一个可取的方法。
BPEL 提供了一个基于标准、与平台无关的解决方案,从而解决了所有这些问题。松散耦合的 BPEL 流程消除了供应商锁定、降低了集成成本并提供了互操作性;此外,它还增加了一个完善的安全性、异常管理和日志记录层。最重要的是,公司可以利用他们的现有基础架构,使其充分发挥效用,并使用 BPEL 对其进行编排。
在“BPEL 指南”的这个部分中,将介绍一个体系结构蓝图,其内容有关利用 Oracle BPEL 流程管理器开发新集成解决方案以及与现有集成解决方案进行连接。其中包含一个案例分析,在该案例分析中,必须将编排好的 Web 服务与基于 TIBCO BusinessWorks 和 webMethods 的现有异构 EAI 解决方案集成在一起。
此外,由于任何完整的业务流程实施都离不开精心设计的错误管理、安全性和记录框架,因此我将介绍 BPEL 作用域和补偿处理程序如何增强此流程的强健性和容错性,以及如何保护 BPEL 流程和相关的服务。
案例研究背景知识
EAI 是使现有应用程序充分发挥效用的强大推动力;可以将现有的中间件流程公开为 Web 服务,然后通过 BPEL 对该 Web 服务进行编排。
下图演示了一个使用 Oracle BPEL 流程管理器编排现有 EAI 接口以及集成新应用程序的通用方法。该方法假设中间件可以将业务流程公开为 Web 服务,并假设应用服务器本身具备 Web 服务接口。
![图 1](http://www.oracle.com/technology/pub/images/chandran_bpelcookbook_f1.jpg)
图 1 EAI 中的 Oracle BPEL 流程管理器(完整示意图)
对涉及两个传统 EAI 中间件产品的特定案例研究进行的分析演示了 BPEL 如何在集成两个产品方面起到重要作用。
在许多企业中,在一个客户“记录系统”中进行的更改不会填充到维护客户数据的其他系统。来看这样一个情形:由于各种业务原因,某个企业最终使用两个来自不同供应商的中间件产品,如与 TIBCO BusinessWorks 集成的 Siebel CRM 以及与 webMethods 集成的 SAP R/3(请参见图 2)。
![图 2](http://www.oracle.com/technology/pub/images/chandran_bpelcookbook_f2.jpg)
图 2 客户详细信息管理模块和中间件接口
在该模型中,SAP 与 Siebel 系统之间不一致的客户数据可能对客户服务级别产生负面影响,并降低部门和企业收入。而通过通用的客户详细信息管理模块(该模块与 TIBCO 和 webMethods 集成之间建立了多个接口点)可以维护一致性。例如,当 Siebel 收到客户数据时,它将检查该客户是新客户还是现有客户,然后将新数据添加到 SAP 或更新两个应用程序中的现有客户数据。
可以使用现有的中间件工具(TIBCO 和 webMethods)实现此集成,但这样做只会增加专用集成的规模以及出现供应商锁定。这种情况为使应用程序充分发挥效用从而实现一个基于标准、与供应商无关的解决方案提供了良机。
要在 EAI 中实现基于标准的接口,首先是将流程公开为 Web 服务。大多数中间件平台可以通过 Web 服务进行相互通信,但当必须将一组接口服务与相应的业务逻辑粘合在一起时,情况将变得复杂。
可以使用其他中间件流程甚至复杂的 Java 代码来编排 Web 服务。但该流程必须提供以下功能:
- 并行的 Web 服务调用
- 异步的 Web 服务调用
- 服务之间的松散耦合和可移植性
- 使用基于标准的接口公开整个编排
- 编排监控
如图 3 所示,基于标准的预制编排解决方案(基于 BPEL)可以解决这些问题。
![图 3](http://www.oracle.com/technology/pub/images/chandran_bpelcookbook_f3.jpg)
图 3 具有 Web 服务接口的客户详细信息管理模块
将 BPEL 引入到此情形中具有以下潜在的好处:
- BPEL 支持松散耦合的 Web 服务编排。
- 可以通过简单的 XML 标记表示业务逻辑(甚至并行流!)。
- 可以使用简单的 assign (copy 规则)和 invoke 语句在服务之间轻松地传送数据。
- 可以从其他编排、中间件工具或 Web 应用程序中以独立 Web 服务组件的形式调用客户详细信息管理模块。
- 可以通过简单的 GUI(如 Oracle BPEL 流程管理器提供的 GUI)管理流程。
大多数中间件工具可以将它们的业务流程公开为 Web 服务,这使得将现有集成与 BPEL 编排连接在一起变得更容易。实际上,您可以对相关的所有中间件服务接口使用通用消息格式。
现在,我们来看一下如何使用 Oracle BPEL 流程管理器在 SAP 和 Siebel 之间实现此客户数据同步。
实施客户详细信息管理模块
BPEL 在 SAP 与 Siebel 之间的客户数据同步流程自动化方面起到了帮助作用。实施此 BPEL 流程所涉及的步骤包括:
- 将 TIBCO 和 webMethods 流程公开为 Web 服务。
- 使用 BPEL 流程编排 Web 服务。
- 将异常管理功能添加到 BPEL 流程。
- 保护 Oracle BPEL 流程管理器、应用程序适配器和 EAI 工具之间的通信。
- 集中记录和通知流程。
第 1 步:将 TIBCO 和 webMethods 流程公开为 Web 服务。客户信息以规范格式表示并包含 SAP 和 Siebel 所需的字段。如果在 TIBCO 和 webMethods 之间传递此一般格式,则这些平台将把规范格式相应地转换为 Siebel 和 SAP 客户记录。
以下是将 BusinessWorks 流程公开为 Web 服务所采取的步骤:
- 分析由 BusinessWorks 流程提供的功能,以确定它能否作为集成情形中的独立组件。
- 确定流程输入和输出。
- 如果 input 和 output 比较复杂,请使用 W3C XML 模式 (XSD) 定义它们。还可以使用 XSD 定义自定义故障模式。
- 使用 WSDL 模板创建 WSDL,并定义 input 和 output 消息格式(如果需要,将它们与预定义的 XSD 关联)。还可以导入现有的 WSDL。
- 配置 HTTP Connection 资源。
- 将 SOAP Event Source 用作第一个活动,随后是业务逻辑,然后使用 SOAP Send Reply 将流程公开为服务。
- 将 HTTP Connection 资源与 Event Source 关联。
- 将 WSDL 和 Send Reply 与 Event Source 关联。
- 处理可能的异常,并使用 SOAP Send Fault 将异常发送至服务客户端。
- 如果计算机名为 mymachine,则用于 HTTP Connection 资源的端口为 8000;如果流程名为 SOAPService ,则可以使用 URL http://mymachine:8000/SOAPService 访问服务。
- 从 Event Source 活动的 WSDL 选项卡中获取服务的最终 WSDL。
以下是如何使用 webMethods 执行同一操作:
- 确定 webMethods 流服务能否成为集成情形中的独立组件。
- 如果要在未经任何验证的情况下从 webMethods 环境的外部调用此 Web 服务,请在 Permissions 选项卡中指定“Execute ACL to Anonymous”。
- 在 webMethods Developer 中选择 Flow Service,然后从 Tools 菜单中单击 Generate WSDL。
- 生成 WSDL 文档时,请指定协议 (SOAP-RPC/SOAP-MSG/HTTP-GET/HTTP-POST) 和传输机制 (HTTP/HTTPS)。
- 定义 WSDL 文档的目标命名空间。
- 在 Host 域中输入托管 webMethods 集成服务器的计算机的 IP 地址或名称。
- 在 Port 域中,输入端口号以连接到当前的集成服务器。
- 将 WSDL 文档保存到本地文件系统。可以在生成的 WSDL 文档中找到服务端点。
注意:webMethods 集成服务器根据特定的错误条件发送预定义的 SOAP 故障。如果必须发送自定义 SOAP 故障,则应使用自定义 SOAP 处理器。还应使用包装程序服务或自定义 SOAP 处理器将服务公开为文档/文字 Web 服务。
现在,假设您拥有以下三个 TIBCO Web 服务(使用 TIBCO BusinessWorks 流程和 TIBCO Adapter for Siebel 实现)。
- Siebel Add
- Siebel Update
- Siebel Query
同样,您使用 webMethods 集成服务器和 webMethods SAP R/3 Adapter 部署了以下 webMethods Web 服务。
- SAP Add
- SAP Update
该解决方案体系结构可以归纳如下:
![图 4](http://www.oracle.com/technology/pub/images/chandran_bpelcookbook_f4.jpg)
图 4 解决方案体系结构
如上所示,BPEL 流程通过 EAI 工具中转前端调用中心与后端 SAP 和 Siebel CRM 应用程序之间的转换。
以下是一些将中间件流程公开为 Web 服务的最佳实践:
- 尽可能遵守 WS-I 标准。
- 尝试在具有文字编码的“文档”样式中公开服务。如果该方法不可用,请使用具有文字编码的“rpc”样式。尽管两者均为 WS-I 推荐的方法,但您将发现文档样式更为简单(至少在您为 BPEL assign 活动创建 copy 规则时是这样)— 使用 rpc 样式,所有模式元素全部作为单独的消息部分出现,而使用文档样式,整个消息在一个部分中传送。可以使用单个 copy 规则复制整个模式,从而降低开发工作量,并在最终的 WSDL 文档中验证样式和编码。
- 避免使用 SOAP 编码;WSDL 的 SOAP Action 属性是一个空字符串。
- 确保中间件使用 WSDL 1.1 描述 Web 服务的接口。
- 使用 SOAP 的 HTTP 绑定。
- 确保所有用于描述此模式的 XSD 都符合 W3C 建议的 XML 模式规范。例如,全局元素声明不应使用对其他全局元素的引用;即,使用 type 属性而不是 ref 属性。
第 2 步:编排 Web 服务。将中间件流程公开为 Web 服务后,可以使用 Oracle BPEL 流程管理器(具有强大的、基于 GUI 的 BPEL 创作接口)对它们进行编排。
我们曾在前面提到过,客户详细信息管理模块的一个重要方面是它同步 SAP 与 Siebel 之间的客户数据。该流程是在 BPEL 设计器中以可视化方式创建的,如下所示。
![图 5](http://www.oracle.com/technology/pub/images/chandran_bpelcookbook_f5.jpg)
图 5 使用 Oracle BPEL 流程管理器编排客户详细信息模块
以下是此流程概要:
- receive 活动接受客户详细信息(企业模式)。
- 通过 assign 和 invoke(Siebel Query 服务)活动将详细信息传递给 Siebel。
- 通过 pick 活动,使用 Siebel Query 结果确定客户是现有客户还是新客户。
- 如果客户是新客户,则调用并行执行,并通过 flow 活动在 Siebel 和 SAP 中添加该客户;否则,另一个并行流将在这两个应用程序中更新客户详细信息。
- 如果 SAP 中不存在客户详细信息,则 Siebel Query 将从 Siebel 中获取这些字段。该 SAP 字段以及其他要更新的字段可能通过一组 assign copy 规则传递给 SAP Update。
- 通过使用显式 reply 活动返回 Customer Update/Addition 的最终状态。
如您所见,业务流程的两侧是用于添加和更新 Siebel 和 SAP 数据的 Web 服务。这些在第 1 步中设计的 Web 服务从内部调用 EAI 流程。
此 BPEL 流程满足了客户管理的业务需要,但它仍无法处理异常。例如,如果在 Siebel 中成功添加了客户,但在 SAP 中添加失败,情况将会怎样?为解决此问题,您需要在业务流程中启用异常管理。
第 3 步:添加异常管理功能。通过异常管理,BPEL 流程可以处理错误消息或由外部 Web 服务返回的其他异常,并可以生成错误消息以响应业务或运行时故障。
下表包含了为使客户管理 BPEL 流程更牢靠而需要处理的异常。
编号 | 情形 | 解决方案 |
1 | Siebel Query 失败 | 终止流程,然后重试 |
2 | Siebel Add 失败;SAP Add 成功 | 进行补偿以删除 SAP 记录,然后重试 |
3 | Siebel Add 成功;SAP Add 失败 | 正常流;重试 |
4 | Siebel Add 失败;SAP Add 失败 | 正常流;重试 |
5 | Siebel Update 成功;SAP Update 失败 | 正常流;重试 |
6 | Siebel Update 失败;SAP Update 成功 | 进行补偿以回滚 SAP 记录,然后重试 |
7 | Siebel Update 失败;SAP Update 失败 | 正常流;重试 |
除了情形 1、2 和 6(如下所示)以外,无需对其他情形进行显式处理即可保持数据一致。
必须跟踪 Web 服务的状态以捕获异常并采取相应的操作。在介绍如何处理情形 1、2 和 6 之前,我们先了解一下如何跟踪特定 Web 服务的状态。
整个 BPEL 流程具有以下回复模式属性:
- Siebel_Add_Status
- Siebel_Update_Status
- SAP_Add_Status
- SAP_Update_Status
所有这些属性均可以包含值 Failed、Success 或 NA,BPEL 流程可以在各个位置设置这些值。要设置 Failed 状态,流程可以捕获由目标 Web 服务引发的 SOAP 故障(对每个 invoke 活动使用捕获处理程序)。当发生任何故障时,调用客户详细信息管理模块的客户端可以重新发送详细信息。
下面,我们将了解一下异常的管理方法:
情形 1
如果 Siebel 查询本身失败,应终止流程,且调用客户端可以重试。
情形 2
当客户详细信息插入在 Siebel 中失败,但在 SAP 中成功时(它们是同时发生的),数据将无法保持一致性。此外,在进行重试时,可能会出现以下问题:
- 如果尝试调用 BPEL 流程以将客户详细信息插入到 Siebel 中,则客户详细信息可能在 SAP 中重复。
- 如果尝试调用 BPEL 流程以更新客户详细信息,则 Siebel 中的更新将失败,这是因为 Siebel 中没有相应的记录。
要处理以上情况,必须在尝试之前使用另一个具有 BPEL 补偿处理程序和作用域的 webMethods Web 服务删除 SAP 客户记录。
作用域和补偿活动是重要的 BPEL 开发工具。作用域是其他活动的容器和上下文;作用域活动类似于编程语言中的 {}block。作用域通过对功能结构进行分组简化了 BPEL 流,并提供了故障、事件和补偿处理程序以及数据变量和关联集。
Oracle BPEL 流程管理器提供了两个补偿处理结构:
- 补偿处理程序 — 该处理程序是实现回滚的业务逻辑。可以为流程和作用域定义处理程序。
- 补偿活动 — 该活动对已经成功完成的内部作用域活动调用补偿处理程序,并且只能从故障处理程序或另一个补偿处理程序的内部调用它。
异常是通过捕获处理程序在作用域级捕获的。捕获处理程序反过来使用补偿活动调用内部作用域的补偿处理程序。补偿处理程序将执行所需的回滚。
返回到本文的示例,假设 BPEL 流程有两个作用域:一个内部作用域和一个外部作用域。SAP Add 和 Siebel Add 服务的调用活动源自外部作用域,但只有 SAP Add 源自内部作用域。补偿处理程序可以与内部作用域关联,且补偿处理程序调用 SAP Delete 服务的活动。
必须将捕获块与外部作用域关联,以便可以捕获由 BusinessWorks Web 服务发送的 SiebelAddfault。每当发生 SiebelAddfault 时,补偿活动将补偿内部作用域并删除 SAP 客户记录。请注意,仅当内部作用域中的所有活动全部成功时,补偿才会成功。
图 6 显示了经过修改的、具备作用域和补偿处理程序的 BPEL 流程。
![图 6](http://www.oracle.com/technology/pub/images/chandran_bpelcookbook_f6.jpg)
图 6 用于删除 SAP 客户记录的补偿逻辑
情形 6
如果 Siebel 更新失败而 SAP 更新成功,则事务也会失败。这将导致数据不一致;因此,必须使用补偿逻辑回滚 SAP 中发生的事务。补偿处理程序与 SAP Update 服务关联,并将调用 SAP Rollback 服务。对 BPEL 流程的修改将遵守上面给出的指南。
显式调用补偿活动这一功能是 BPEL 的错误处理框架的基础。与传统的 EAI 补偿机制不同,BPEL 提供了一个标准化的回滚处理方法。
创建了 BPEL 流程以编排 TIBCO 和 webMethods Web 服务后,让我们来了解一下如何使 BPEL、适配器与 EAI 工具之间的通信更安全。
第 4 步:安全的业务通信。可以在两个层次实现安全性:出站(调用安全的 TIBCO 和 webMethods 服务)和入站(保护 BPEL 流程)。
出站安全性
需要保护 TIBCO 和 webMethods 服务以防止未授权的访问。Oracle BPEL 流程管理器支持用于调用外部服务的 HTTP 基本身份验证和 WS-Security 身份验证。本示例着重演示如何使用 HTTP 身份验证保护 TIBCO 和 webMethods 服务与机制,以从 BPEL 流程中调用它们。
在 TIBCO BusinessWorks 和 webMethods 集成服务器中部署的 Web 服务支持 HTTP 基本身份验证。设计 TIBCO Web 服务时,请选中 SOAP 事件源活动的 Transport Details 选项卡上的 Use Basic Authentication 复选框。使用 TIBCO Administrator 部署 Web 服务时,可以设置不同用户/角色的服务访问级别。使用 webMethods Developer 设计 Web 服务时,可以设置不同操作的 ACL(访问控制列表)。
如果在部署 TIBCO 和 webMethods 服务时使用基本身份验证,服务将在每次调用时进行此验证,并且应由 BPEL 流程传递证书。可以通过设置两个合作伙伴链接属性完成该任务:httpUsername 和 httpPassword。可以按如下所示静态设置这两个属性。
![图 7](http://www.oracle.com/technology/pub/images/chandran_bpelcookbook_f7.jpg)
图 7 设置 httpUsername 和 httpPassword
要动态传递证书,请使用 copy 规则。
<copy> <from variable="varUsername" <to partnerLink="p1" bpelx:property="httpUsername" </copy>
此外,还可以使用 WS-Security 保护 TIBCO 和 webMethods 服务。BPEL 流程可以将 WS-Security 身份验证标头传递给 WS-Security 保护的 Web 服务。您需要在服务的 WSDL 文档中定义该服务支持的 WS-Security 标头。然后,可以将这些标头字段作为 BPEL 流程中的变量(就像消息主体数据元素一样)进行处理。可以在 HotelShopFlow 示例(可以从 OTN 下载)中找到有关 WS-Security 身份验证的更多详细信息。
入站安全性
可以使用 HTTP 身份验证防止未授权用户调用 BPEL 流程;还可以为不同的 BPEL 流程设置不同的证书。
要实现此安全性,必须在应用服务器级别启用 HTTP 基本身份验证。随后,可以在 BPEL 流程中提取证书并以合作伙伴链接属性的形式传递给 TIBCO 和 webMethods Web 服务。
有关 BPEL 安全性的更多详细信息,请收听 OTN 上的“保护 BPEL 流程与服务”网络研讨会。
第 5 步:集中记录和错误处理。尽管业务流程现在比较安全和强健,但在其中构建记录和通知功能同样重要。构建一个集中的记录和错误处理框架将使应用程序更强健,增强可重用性并降低开发成本。可以从 BPEL 流程和中间件中使用 Web 服务构建这样的框架。通过 Oracle BPEL 流程管理器,您可以使用文件适配器将记录添加到该服务中,并要求在出现错误时发送电子邮件通知。
可以将以下示例模式用于此框架:
模式元素 | 说明 |
ROLE | ERROR、DEBUG、WARNING 以及 INFO 等角色 |
CODE | 错误代码 |
DESCRIPTION | 错误描述 |
SOURCE | 错误源 |
必须将通知发送到的电子邮件 ID |
可以将该 BPEL 流程公开为异步单向 Web 服务,这将使该服务的客户端继续运行,而不会出现任何延迟。下面显示了集中的记录和通知流程 LogNotify。
![图 8](http://www.oracle.com/technology/pub/images/chandran_bpelcookbook_f8.jpg)
图 8 使用 Oracle BPEL 流程管理器的记录和错误处理框架
如图 8 所示,LogNotify 流程执行以下操作:
- 接收要记录的来自外部流程的信息
- 调用 Log Service ,以将该数据写入日志文件。为此,Log Service 将利用文件适配器。
- 如果记录成功,该流程将完成。此外,如果 ROLE 字段包含 ERROR,则该服务将通过电子邮件通知相关用户。从收到的原始消息中检索电子邮件信息(参见示例模式)。
- 如果通知失败,将通知错误记录到文件后,该流程将结束。
主 BPEL 流程中的每个调用活动可以具有单独的 try-catch 块。中间件流程发送的 SOAP 故障(甚至可能包含最终应用程序引发的异常)在 catch 块中处理,并发送到通用记录和错误处理框架。
图 9 显示了如何在 Siebel Add 失败时调用 LogNotify 流程。
![图 9](http://www.oracle.com/technology/pub/images/chandran_bpelcookbook_f9.jpg)
图 9 从客户详细信息管理模块中调用记录和错误处理框架
结论
集成市场充斥着强大的 EAI 产品,许多集成都是通过这些产品完成的。BPEL 是使这些现有的 EAI 解决方案充分发挥效用的唯一选择。通过将现有中间件流程公开为 Web 服务并使用 Oracle BPEL 流程管理器对其进行编排,企业可以开始着手制定 SOA 方面的决策。