将 BPEL 添加到企业集成混合环境

版权声明：本文转自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 EAI 中的 Oracle BPEL 流程管理器（完整示意图）

 

对涉及两个传统 EAI 中间件产品的特定案例研究进行的分析演示了 BPEL 如何在集成两个产品方面起到重要作用。

在许多企业中，在一个客户“记录系统”中进行的更改不会填充到维护客户数据的其他系统。来看这样一个情形：由于各种业务原因，某个企业最终使用两个来自不同供应商的中间件产品，如与 TIBCO BusinessWorks 集成的 Siebel CRM 以及与 webMethods 集成的 SAP R/3（请参见图 2）。

 

图 2 客户详细信息管理模块和中间件接口

 

在该模型中，SAP 与 Siebel 系统之间不一致的客户数据可能对客户服务级别产生负面影响，并降低部门和企业收入。而通过通用的客户详细信息管理模块（该模块与 TIBCO 和 webMethods 集成之间建立了多个接口点）可以维护一致性。例如，当 Siebel 收到客户数据时，它将检查该客户是新客户还是现有客户，然后将新数据添加到 SAP 或更新两个应用程序中的现有客户数据。

可以使用现有的中间件工具（TIBCO 和 webMethods）实现此集成，但这样做只会增加专用集成的规模以及出现供应商锁定。这种情况为使应用程序充分发挥效用从而实现一个基于标准、与供应商无关的解决方案提供了良机。

要在 EAI 中实现基于标准的接口，首先是将流程公开为 Web 服务。大多数中间件平台可以通过 Web 服务进行相互通信，但当必须将一组接口服务与相应的业务逻辑粘合在一起时，情况将变得复杂。

可以使用其他中间件流程甚至复杂的 Java 代码来编排 Web 服务。但该流程必须提供以下功能：

• 并行的 Web 服务调用
• 异步的 Web 服务调用
• 服务之间的松散耦合和可移植性
• 使用基于标准的接口公开整个编排
• 编排监控

如图 3 所示，基于标准的预制编排解决方案（基于 BPEL）可以解决这些问题。

 

图 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 流程所涉及的步骤包括：

1. 将 TIBCO 和 webMethods 流程公开为 Web 服务。
2. 使用 BPEL 流程编排 Web 服务。
3. 将异常管理功能添加到 BPEL 流程。
4. 保护 Oracle BPEL 流程管理器、应用程序适配器和 EAI 工具之间的通信。
5. 集中记录和通知流程。

第 1 步：将 TIBCO 和 webMethods 流程公开为 Web 服务。客户信息以规范格式表示并包含 SAP 和 Siebel 所需的字段。如果在 TIBCO 和 webMethods 之间传递此一般格式，则这些平台将把规范格式相应地转换为 Siebel 和 SAP 客户记录。

以下是将 BusinessWorks 流程公开为 Web 服务所采取的步骤：

1. 分析由 BusinessWorks 流程提供的功能，以确定它能否作为集成情形中的独立组件。
2. 确定流程输入和输出。
3. 如果 input 和 output 比较复杂，请使用 W3C XML 模式 (XSD) 定义它们。还可以使用 XSD 定义自定义故障模式。
4. 使用 WSDL 模板创建 WSDL，并定义 input 和 output 消息格式（如果需要，将它们与预定义的 XSD 关联）。还可以导入现有的 WSDL。
5. 配置 HTTP Connection 资源。
6. 将 SOAP Event Source 用作第一个活动，随后是业务逻辑，然后使用 SOAP Send Reply 将流程公开为服务。
7. 将 HTTP Connection 资源与 Event Source 关联。
8. 将 WSDL 和 Send Reply 与 Event Source 关联。
9. 处理可能的异常，并使用 SOAP Send Fault 将异常发送至服务客户端。
10. 如果计算机名为 mymachine，则用于 HTTP Connection 资源的端口为 8000；如果流程名为 SOAPService ，则可以使用 URL http://mymachine:8000/SOAPService 访问服务。
11. 从 Event Source 活动的 WSDL 选项卡中获取服务的最终 WSDL。

以下是如何使用 webMethods 执行同一操作：

1. 确定 webMethods 流服务能否成为集成情形中的独立组件。
2. 如果要在未经任何验证的情况下从 webMethods 环境的外部调用此 Web 服务，请在 Permissions 选项卡中指定“Execute ACL to Anonymous”。
3. 在 webMethods Developer 中选择 Flow Service，然后从 Tools 菜单中单击 Generate WSDL。
4. 生成 WSDL 文档时，请指定协议 (SOAP-RPC/SOAP-MSG/HTTP-GET/HTTP-POST) 和传输机制 (HTTP/HTTPS)。
5. 定义 WSDL 文档的目标命名空间。
6. 在 Host 域中输入托管 webMethods 集成服务器的计算机的 IP 地址或名称。
7. 在 Port 域中，输入端口号以连接到当前的集成服务器。
8. 将 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 解决方案体系结构

 

如上所示，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 使用 Oracle BPEL 流程管理器编排客户详细信息模块

 

以下是此流程概要：

1. receive 活动接受客户详细信息（企业模式）。
2. 通过 assign 和 invoke（Siebel Query 服务）活动将详细信息传递给 Siebel。
3. 通过 pick 活动，使用 Siebel Query 结果确定客户是现有客户还是新客户。
4. 如果客户是新客户，则调用并行执行，并通过 flow 活动在 Siebel 和 SAP 中添加该客户；否则，另一个并行流将在这两个应用程序中更新客户详细信息。
5. 如果 SAP 中不存在客户详细信息，则 Siebel Query 将从 Siebel 中获取这些字段。该 SAP 字段以及其他要更新的字段可能通过一组 assign copy 规则传递给 SAP Update。
6. 通过使用显式 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 用于删除 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 设置 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	错误源
EMAIL	必须将通知发送到的电子邮件 ID

可以将该 BPEL 流程公开为异步单向 Web 服务，这将使该服务的客户端继续运行，而不会出现任何延迟。下面显示了集中的记录和通知流程 LogNotify。

 

图 8 使用 Oracle BPEL 流程管理器的记录和错误处理框架

 

如图 8 所示，LogNotify 流程执行以下操作：

1. 接收要记录的来自外部流程的信息
2. 调用 Log Service ，以将该数据写入日志文件。为此，Log Service 将利用文件适配器。
3. 如果记录成功，该流程将完成。此外，如果 ROLE 字段包含 ERROR，则该服务将通过电子邮件通知相关用户。从收到的原始消息中检索电子邮件信息（参见示例模式）。
4. 如果通知失败，将通知错误记录到文件后，该流程将结束。

主 BPEL 流程中的每个调用活动可以具有单独的 try-catch 块。中间件流程发送的 SOAP 故障（甚至可能包含最终应用程序引发的异常）在 catch 块中处理，并发送到通用记录和错误处理框架。

图 9 显示了如何在 Siebel Add 失败时调用 LogNotify 流程。

 

图 9 从客户详细信息管理模块中调用记录和错误处理框架

 

结论

集成市场充斥着强大的 EAI 产品，许多集成都是通过这些产品完成的。BPEL 是使这些现有的 EAI 解决方案充分发挥效用的唯一选择。通过将现有中间件流程公开为 Web 服务并使用 Oracle BPEL 流程管理器对其进行编排，企业可以开始着手制定 SOA 方面的决策。