流程驱动的 SOA 开发

作者：Matjaz B. Juric 和 Harish Gaur

遵循完整的 SOA 生命周期开发端到端业务流程支持。

本文是企业解决方案简明手册的一部分

2009 年 8 月发布

下载：
Oracle SOA Suite

业务流程管理和 SOA

SOA 的一个主要优势就是它能够使 IT 与业务流程一致。业务流程非常重要，因为它们定义了业务活动的执行方式。随着企业发展和改进其运营，业务流程进行相应的更改。为了使企业更具竞争力，也需要更改业务流程。

如今，IT 是业务运营的一个重要部分。如果没有 IT 支持，企业就无法开展业务。但这也使 IT 承担了更多的责任。这些责任中的一个重要部分就是 IT 需要能够快速高效地响应更改。理想情况下，IT 必须立即响应业务流程更改。

但大多数情况下，IT 不够灵活，无法使应用程序体系结构快速适应业务流程的更改。软件开发人员需要时间来修改应用程序行为。同时，企业仍然使用旧流程。在竞争激烈的市场中，这样的延迟是非常危险的，而在越来越复杂的 IT 体系结构中依靠传统的软件开发进行快速更改会加剧这种威胁。

传统软件开发方法的主要问题是在 IT 和流程模型之间存在巨大的语义鸿沟。SOA 通过引入使 IT 开发周期与业务流程生命周期一致的开发模型缩小了语义鸿沟。

为了更好地了解此内容，我们来看看 SOA 生命周期的四个阶段：

• 流程建模，在该阶段中，流程分析人员与流程所有者协作，分析业务流程并定义流程模型。他们定义活动流、信息流、角色以及业务文档。他们还定义业务策略、约束、业务规则以及绩效量度。通常，绩效量度称为关键绩效指标 (KPI)。KPI 的示例包括活动周期、活动成本等。通常，在此阶段使用 BPMN（业务流程建模标注）。
• 流程实施，在该阶段中，开发人员与流程分析人员协作，实施业务流程，旨在为流程提供端到端支持。在 SOA 方法中，流程实施阶段包括使用 BPEL（业务流程执行语言）实施流程并将流程分解为服务、实施或重用服务以及集成。
• 流程执行和控制是实际的执行阶段，流程参与者在该阶段执行各种流程活动。在对业务流程的端到端支持中，很重要的一点是 IT 驱动流程并指导流程参与者执行活动，而非由员工驱动实际流程。在 SOA 中，流程在流程服务器上执行。流程控制是这个阶段的重要部分，在该阶段中，流程主管或流程管理人员控制是否优化执行流程。如果出现延迟、发生异常、资源不可用或出现其他问题，流程主管或管理人员可以采取纠正措施。
• 流程监视和优化，流程所有者在该阶段使用 BAM（业务活动监视）监视流程的
• 主要绩效指标 (KPI)。流程分析人员、流程所有者、流程主管以及主要用户在考虑不断变化的业务状况的同时检查流程并分析 KPI。他们检查业务问题并对业务流程进行优化。

图 1 显示了流程进入此周期以及通过各个阶段的方式。

图 1

确定并选择优化之后，流程返回到建模阶段以应用优化。然后，重新实施该流程并重复整个生命周期。这称为增量迭代生命周期，因为会在每个阶段改进流程。

SOA 开发的组织方面

如前所述，SOA 开发与传统的开发有显著不同。SOA 开发以流程为中心，使建模人员和开发人员专注于业务流程以及对流程的端到端支持，从而有效地缩小了业务和 IT 之间的鸿沟。

SOA 开发周期的成功依赖于正确的流程建模。只有详细地建立流程模型，我们才能开发有效的端到端支持。此外，还必须考虑异常流程流。这可能是个非常困难的任务，它超出了 IT 部门的范围（尤其是从传统角度来看）。

为了使以流程为中心的 SOA 项目成功，需要对组织进行一些更改。必须激发透彻了解流程的业务用户主动参与流程建模。不要将他们的主动参与视作理所当然，以免他们发现其他工作“更有用”，尤其是当他们没有看到流程建模的附加值时更是如此。因此，简要说明流程建模的意义是颇具价值的时间投资。

好的战略是获得高层管理团队的支持。有必要向高层管理团队解释两个关键因素：首先，为什么以流程为中心的方法以及对流程的端到端支持非常重要，其次是为什么没有业务用户的参与，IT 部门就无法成功完成任务。通常，高层管理团队会快速了解情况并指导业务用户参与。

很明显，提议的以流程为中心的开发方法必须成为正在进行的活动。这将需要形成某些组织结构。否则，将需要针对每个项目进行审批。我们已经看到提议的方法舍弃了对 IT 部门的组织限制。很多企业建立了 BPM/SOA 评测中心，包括业务用户以及进行 SOA 开发所需的所有其他配置文件（包括流程分析人员、流程实施、服务开发、表示层组以及 SOA 治理）。

SOA 开发的最大职责可能就是编排前面所述的组，使其为共同的目标工作。这是项目经理的职责所在，项目经理必须与治理组紧密合作。只有通过这种方式才能在短期（为业务流程开发端到端应用程序）和长期（开发一个灵活且与业务需求一致的 IT 体系结构）成功进行 SOA 开发。

SOA 开发的技术方面

SOA 引入了支持 SOA 开发方法的技术和语言。尤为重要的是 BPMN（业务流程建模标注）和 BPEL（业务流程执行语言），BPMN 用于对业务流程进行建模，BPEL 用于执行业务流程。

BPMN 是流程建模的关键技术。流程分析人员组必须深入了解 BPMN 和流程建模概念。必须详细地对 SOA 流程进行建模。我们必须识别从执行角度来讲不可分割的各个活动。还必须针对异常情形建模。异常情形定义当出现错误时流程的处理方式，因为在实际情况中，业务流程可能会出错。我们必须建立能够响应异常情形并进行相应恢复的模型。

接下来，我们使流程自动执行。这需要将 BPMN 流程模型映射到 BPEL 中的可执行表示。这由流程实施小组负责。BPMN 几乎可以自动转换为 BPEL，反之亦然，这样可保证流程映射始终与可执行代码同步。但是，还必须将可执行的 BPEL 流程与业务服务连接。每个流程活动都与相应的业务服务连接。业务服务负责实现各个流程活动。

如果您拥有可重用的、低级的中间服务和技术服务的业务服务组合，则 SOA 开发的效率最高。可以从头开始或在现有系统的基础上开发业务服务，也可以将其外包。该任务由服务开发小组负责。从理论上讲，服务开发小组首先开发所有业务服务是很有意义的。然后，流程实施小组才开始将这些服务组合成流程。但实际上，情况并非如此。因此，这两个组必须并行工作，这是一个很大的挑战。这需要 SOA 治理小组和项目经理的严格、明确的监管；否则这两个组（流程实施小组和服务开发小组）的结果将无法兼容。

成功实施流程之后，便可以将其部署在流程服务器上。除了执行流程之外，流程服务器还提供其他有价值的信息，包括流程审计跟踪、成功完成的流程列表以及终止或失败的流程列表。这些信息在控制流程执行以及采取任何必要的纠正措施方面非常有帮助。服务和流程使用 ESB（企业服务总线）进行通信。在符合 UDDI 的 Service Registry 中注册服务和流程。此体系结构的另一个部分是规则引擎，它充当业务规则的中心位置。对于具有人员任务的流程，显然用户交互非常重要，并且连接到身份管理。

SOA 平台还提供 BAM（业务活动监视）。BAM 帮助度量流程的关键绩效指标并提供有价值的数据，可以使用这些数据优化流程。每个 BAM 用户的最终目标是优化流程执行，提高流程效率以及察觉并响应重要事件。

BAM 确保我们将在最有意义的位置开始优化流程。一般来讲，流程优化基于模拟结果，更糟糕的是通过猜测可能出现瓶颈的位置进行流程优化。另一方面，BAM 提供了更可靠、更精确的数据，从而使有关从何处开始进行优化的决策更加明智。

图 2 显示了 SOA 体系结构层。

图 2

案例研究

流程建模

到目前为止，我们已经探讨了该理论。现在，我们来看一个来自 Elektro Slovenija 的端到端采购流程的案例研究，Slovenia 是一家国有配电公司。这个采购过程是使用全套的 Oracle 工具实施的：使用 Oracle 业务流程分析 PA 套件进行建模，使用包含 JDeveloper 和 Service Registry 的 SOA 套件（BPEL 流程管理器、ESB、规则创建器、WS 管理器、应用服务器）进行实施，使用 Oracle BAM 监视业务活动，如图 3 所示。

图 3

作为国有公司，Elektro Slovenija 必须严格遵守有关采购的法规。该流程从一个订购申请表开始。首先，必须决定是否将该订单与其他类似订单收集起来进行联合采购（例如办公用品），还是作为单个订单。订单值也会影响该流程。低于 4.200 欧元的订单最简单，需要收集三个报价，然后发出一个采购订单。对于高达约 12.000 欧元的订单，需要执行一个谈判流程，然后发出一份合同。对于较大的订单，需要创建一个特殊的代理来执行订购流程，该流程因订单类型（产品、服务或房地产）而异。该流程中涉及几个角色，包括订单创建者、负责合同的人员、采购组领导以及大型订单的代理。

该项目中的第一个挑战就是流程建模。该公司已经建立了一个 SOA 评测中心，并且高层管理人员已经深入了解了 BPM 和 SOA。这使得情况更加简单，因为激发业务用户参与并不太困难。以我们的经验，流程建模小组应包括具有以下角色的人员：

• 流程所有者，将验证流程流并决定流程中可能的更改
• 一两个切实了解该流程的流程所有者助手。这些人将进行实际的建模工作。
• 协调员，将提出问题并主持会议，
• 流程建模人员，在详细的 SOA 建模方面经验丰富。

已在六个级别上对 BPA 套件中的流程建立了模型。它包括 24 个子流程，由 230 个活动组成，其中 100 多个活动都是人员任务。该流程涉及 25 个不同的角色，实施 40 多个业务规则并且定义 7 个关键绩效指标。图 4 为 BPA 套件应用程序的屏幕截图，其中显示了顶层流程图：

图 4

值得一提的是，BPA 套件可以很好地支持包含人员任务的流程（例如我们的示例流程）。此外，还可以使用 BPA Publisher 将流程定义与其他感兴趣的各方共享，以促进协作。

设计完流程之后，BPA 套件会检查模型的语义有效性，以识别可能未正确建模的流程部分，如图 5 所示。

图 5

流程实施

启动三个并行的开发活动，以便为端到端支持开发组合应用程序：

• BPEL 可执行流程开发。
• 业务服务开发。
• 表示层 — 用户界面开发。

在这个案例中，这个包含了两个开发人员的小组开发了 BPEL 可执行流程和业务服务。其中一个开发人员还是流程建模人员。这样就简化了组织结构并且减少了通信费用。

以下子部分简要介绍了 BPEL 可执行流程和业务服务的开发。由于用户界面不是特定于 SOA 的，因此不进行讨论。

BPEL 可执行流程开发

图 6

可以手动开发 BPEL 可执行流程，也可以从 BPMN 模型自动转换。我们使用的是第二种方法。为了支持无缝转换，BPMN 设计应该遵循几个原则（请参阅有关 BPMN 到 BPEL 映射的原则）。BPMN 到 BPEL 转换非常复杂，可以采用不同的方法将同一 BPMN 构造映射到 BPEL。

如果您遵循原则，那么从 BPMN 到 BPEL 的转换（从 BPA 套件到 JDeveloper 蓝图）就比较简单。尽管技术相对较新，但也适用于生产的复杂流程（例如该采购流程）。我们的转换体验大多数都很好。图 6 显示了来自 JDeveloper BPEL 蓝图角度的屏幕。

必须在 JDeveloper 中修改 BPEL 代码。此处最重要的任务是将 BPEL 流程与实际的业务服务连接。请注意，可以在 BPA 套件中使用业务服务的 WSDL 界面，这样可以简化 BPEL 开发，但需要流程建模人员掌握一些额外的技能。

除了将 BPEL 与服务连接以外，这个阶段的其他重要活动包括开发 ESB 调解、在 Service Registry 中注册服务、在规则创建器中输入业务规则、部署流程以及开发 BAM 信息板（随后我们将讨论这些内容）。

业务服务开发

在 BPMN 和 BPEL 之间来回转换

SOA 开发的一个重要部分（尤其是在实际项目中）是可以在 BPA 套件中的 BPMN 模型和 JDeveloper 蓝图表示中的 BPEL 之间来回更改。来回转换有两个重要方面：

• 如何将 BPMN 模型中的更改传播到 BPEL，而不会丢失已经在 BPEL 中进行的实施更改
• 如何将在 BPEL 中进行的更改传播回 BPMN 模型，以使它们保持同步。

Oracle 工具的成熟度给我们带来惊喜。这两种情况下，来回转换的体验一直很好：

• 更新 BPA 流程模型时，我们已经能够将更改传播到 JDeveloper 蓝图，而不会丢失以前对 BPEL 进行的实施更改。
• 更新 JDeveloper 中的 BPEL 时，我们已经能够将更改传播回 BPA 模型，业务人员可以选择接受或拒绝更改。下图显示了一个示例，其中在 BPEL（在 JDeveloper 中）中已经添加了一个 Save Order Request 活动，并且已经将更改传播回 BPA 套件中的 BPMN 模型。
•  

图 7

图 8

来回转换对于实际开发非常重要，因为它是迭代 SOA 开发的关键，可以确保缩短开发周期并且轻松更改现有组合应用程序。来回转换还可使模型 (BPMN) 和可执行代码 (BPEL) 保持同步。从我们使用 Oracle 工具的经验来看，只显露了非常小的问题，如处理程序故障导致无法实现 BPA 和 JDeveloper 之间的正确同步。在我们看来，Oracle 所采用的方法（即将建模和实施工具分离）好于两者使用相同工具的方法。

BPMN 到 BPEL 映射的原则

让我们再看一下 BPMN 到 BPEL 的映射。我们已经了解到 BPA 套件中并非所有 BPMN 构造都会同样正确地映射到 BPEL，因此流程建模人员必须了解与 BPMN 到 BPEL 映射有关的具体情况，以便获得最有效的模型。

映射的基本原则

• 所有 BPMN 活动都映射到 BPEL 范围。
• 根据触发器的类型，将启动事件映射到接收或选取活动。
• 根据类型，将结束事件映射到回复、调用、抛出或其他活动。
• 将网关转换为不同的 BPEL 活动，如选取、切换或流。
• 将业务数据映射到变量。
• 将子流程映射到调用活动。
• 每个 BPMN 子流程成为一个单独的 BPEL 流程。

当涉及循环时必须特别注意。BPMN 支持任意循环，但 BPEL 不支持。因此我们必须将所有循环转换为 while 循环（结构化循环）。但是，这可能会大大改变流程模型，至少从视觉角度是这样（如果执行适当的转换，那么流程行为不会改变）。因此，业务人员可能难以理解转换后的模型。如果流程包含很多交替的人员任务，则缺少对任意循环的支持也可能成为一个问题。

为了避免在比较简单的方案中采用结构化的循环，我们可以使用多个输出对决策进行一些重构。应该将此类决策分解成多个决策。例如，以下情形未正确映射到 BPEL：

图 9

因此，我们应该将此决策分解为两个决策：

图 10

循环中重复的活动会在生成的 BPEL 中重复。这可以通过以下方式来避免：组合重复的活动并将它们作为子流程建立模型。然后，在生成的 BPEL 中将只重复用于调用子流程的调用活动。

处理结束事件时也要非常小心，因为这些事件实际上可能并不能像您预期的那样结束 BPEL 流程。在 BPMN 决策中，我们可以影响将生成所生成 BPEL 切换的方式。如果我们没有为某个情况定义默认流，则会在 BPEL 切换活动中生成其他流。这对于人员任务尤为有用，因为 BPEL 流程应检查各种可能的人员任务结果。

流程执行

开发成功后，将组合应用程序部署到流程服务器。Oracle SOA 套件和 BPEL 流程管理器特别提供完备的工具来控制和管理流程执行。尤其是，10.1.3.4 中添加的故障策略对于生产非常有用，因为在流程中出现故障时，它们允许系统管理员进行干预。采购流程是一个长时间运行的流程，它包括很多人员任务。因此，如果出现故障，也不得终止流程。故障策略支持这一点，并且允许将系统故障处理与流程实施分离。WS 管理器在流程执行阶段是一个非常有用的工具。它简化了流程和服务的监管并且允许监视使用情况，甚至控制 SLA 合规性。

包括人员任务的流程还需要一个身份管理系统，其中所有角色和用户都参与流程。在本例中，我们使用了 Active Directory，它可以与 SOA 套件集成。还可以使用 Oracle 身份管理。

使用 BAM 和优化进行流程监视

过去的立法发生了变化，因此有必要对采购流程进行一些修改。此外，该公司努力提高效率，这使得他们更加重视系统化识别流程瓶颈的能力，从而进一步增加了对流程修改的需求。

为了支持该功能，我们实现了 BAM 支持。这包括定义用于监视流程执行的传感器以及开发 BAM 信息板。下图显示了为流程开发的一个示例信息板：

已经证明 BAM 对于流程所有者来说特别重要，它使流程所有者能够实时监视流程执行。以我们的经验，开发 BAM 信息板非常简单，至少对于只监视简单 KPI 的信息板来说是这样。

最后的挑战是将 BAM 数据导回 BPA 建模工具中。这可以使用自定义 JavaScript 来完成，但却非常费时。未来版本的 BPA 套件将对此进行改进，使这些操作更加简单。

BAM 是进行流程优化的有用起点。到目前为止，采购流程仅位于其第一次迭代中，尚未进行优化。但是，已经使用 BAM 数据来识别可能的优化点。即使在其第一次迭代中，采购流程也显露出了多项优势：由于一些流程活动已经自动执行并且大大改善了流程的可见性，因此员工的工作量减少了 25% 到 35%。可以跟踪流程实例的执行并且了解在所选流程实例中进行了哪些活动。这减少了间隔时间，从而加快了执行速度。在接下来的迭代中，将使更多的流程步骤自动执行，从而产生更多的收益。

吸取的经验和教训

作为实际示例，该案例研究已经证实以流程为中心的 SOA 方法的最重要优势：业务和 IT 之间更高的一致性、更快的开发周期、更少的错误，并且最重要的是更快的开发周期，从而确保了大大减少实现业务需求所需的时间。

围绕着业务和 IT 之间更高的一致性，还显现了下列以流程为中心的开发的重要优势：

• 更好地了解业务需求。
• 端到端业务流程支持。
• 流程监视和执行控制提供了有用的业务性能指标。

没有 SOA 方法，实现这些优势是非常困难的。

我们还了解到以流程为中心的 SOA 开发方法既是一个技术挑战，也是一个组织挑战。它要求为流程建模、流程实施、服务开发合开发用户界面建立胜任的团队。还要求通过 SOA 管理和项目管理建立必要的监管。对于比较小的项目，同一小型开发团队可以担当多个角色。最后，需要新技能以成功开发 SOA。

完整 SOA 流程生命周期（生成模型、实施、执行、监视和优化）的优势很多，因此非常值得在所需的知识和产品方面进行必要投资。我们认为整个流程生命周期都显示了 SOA 的实际价值，当对流程进行更改、修改以及优化时，将更加显著地体现这些价值。

此案例研究的主旨是可以为复杂的实际流程开发完整的端到端流程。具有完整生命周期支持的以流程为中心的 SOA 开发方法为公司带来大量商机，不仅仅可以改进和优化其 IT 支持，而且还可以通过流程自动化提高运营效率。

参考资料

1. Matjaz Juric、Kapil Pant， Business Process Driven SOA using BPMN and BPEL，Packt Publishing，2008 年 8 月
2. Matjaz Juric、Poornachandra Sarang 和 Benny Mathew， Business Process Execution Language for Web Services 2nd Edition，Packt Publishing，2006 年 1 月

感谢 Harish Gaur 对本文的贡献。

	Matjaz B. Juric 拥有计算机与信息科学的博士学位。他编著或者合著了多本 SOA 图书，包括《Business Process Driven SOA using BPMN and BPEL》、《Business Process Execution Language for Web Services》（英语版和法语版）、BPEL Cookbook 以及 SOA Approach to Integration。他还担任过多个大型 SOA 项目的顾问。
	Harish Gaur 是 Oracle 的融合中间件产品管理总监。在这一职位上，他与战略客户密切合作，使用 Oracle SOA 技术实现了面向服务的架构。Harish 与人合著了《The BPEL Cookbook》（由 Packt Press 出版）。