为 OTN 撰稿 为 Oracle 技术网撰写技术文章，获得报酬的同时可提升技术技能。 了解更多信息

密切关注 OTN 架构师社区

SOA 蓝图：架构师的工具箱

作者：Jürgen Kress、Berthold Maier、Hajo Normann、Danilo Schmeidel、
Guido Schmutz、Bernd Trops、Clemens Utschig-Utschig、Torsten Winterberg

行业 SOA 文章系列的一部分

2013 年 4 月

本文介绍为实现功能性 SOA 流程而需要建立的基础。我们并不介绍特定工具，而是定义一个广泛适用的 SOA 蓝图，其中各模块之上可以加装商业产品或日益增多的可用开源产品。

企业蓝图

图 1 将自适应企业计算远景显示为企业整体元蓝图，分为三个不同级别：

• 基础架构级别 — 此级别由数据库、存储系统、应用服务器以及运行系统所需的所有其他 IT 资源构成。
• 应用系统级别 — 此级别容纳所有应用（各种应用程序和标准软件）以及与 SOA 有关的服务、工作流和 BPM 系统。
• 流程管理级别 — 在流程设计中列出各种功能要求，然后在较低级别实现。

一个高级的面向服务的架构是在应用系统级别实现功能需求的最有效的选择。现有业务服务与流程模型中功能步骤的对应越出色，业务与 IT 之间的差距越小。

各种反馈耦合回路表示此元蓝图的实际附加值，意味着可以根据服务和技术流程的使用是否一致来衡量 KPI。这又可以促进流程控制，最终实现流程优化。企业在实现 SOA 方面的进步越大，自适应企业计算获得的效果越显著、见效越快。

确定了远景之后，我们接下来考虑一个 SOA 级别的蓝图，以帮助具体选择可用的 SOA 组件。

图 1：自适应企业计算远景

参考架构

参考架构代表可实现的 IT 环境的理想形象，其完整的实现需要很多步骤，因为具体项目的外部影响往往会导致偏离计划。首席架构师的任务是通过适当的纠正措施确保这些偏差不会过分妨碍完整实现。如果没有持续不断的检查和方向性调整，架构将在众多不同方向上逐渐扩展，从而导致难以管理的架构，无法获得任何好处，如降低成本或敏捷性。

架构师不仅在定义参考架构方面起到核心作用，在整个项目周期也是如此，因为初始项目结束后仍需执行类似的任务。战略 SOA 计划的引入要求各项目遵循相同的一组框架条件，以便协同一致实现定义的参考架构。

OASIS 制定了 SOA 参考模型 TC 来帮助实现技术的概念化和标准化，因为服务具有的决定性属性（效果、可达性、可见性、交互等）需要得到普遍理解。本指南虽然仍不够明确，但在一定程度上提供了这些概念的详细信息，指明这些属性必须支持组件识别，才能得出 SOA 蓝图要求。因此，需要公布在运行时平台上运行的可能影响系统状态的服务，这样当服务使用者使用定义的访问选项调用服务时，这些服务能够符合策略的要求。

面向服务的架构的组件

在详细介绍 SOA 蓝图之前，我们首先查看架构师工具箱中可以找到的所有组件。针对每个用例，必须选择正确的工具并将其逻辑连接到目标架构。下面各节描述了适用组件，只不过是以可在项目范围而不是特定产品级别生效的“产品类”的形式：

运行时容器

作为 Java Enterprise 环境的主要方面，JEE 容器是基本设备的一部分，是基于 Java 的 SOA 的“生态系统”，为事务、池化和集群提供基本服务。尽管包含一些轻量级框架（如 Spring），但 JEE 容器是企业架构的一个基本组件。供应商的选择通常由非功能性要求、项目规范和个人喜好来决定。注意，SpringSource Application Platform 和基于 OSGi 的系统等方法正在发挥着越来越重要的作用。

面向消息的中间件 (MOM)

MOM 构成 SOA 的传输基础架构，提供可达性特性，同时注重提高服务质量 (QoS)。在最简单的场景中，如果服务提供者和服务使用者都位于 Java 环境中，则 Java 消息服务 (JMS) 就可以帮助完成消息交换。合适的候选者包括具有 JMS 接口的原生产品和传统队列提供者，如 Apache ActiveMQ、Oracle AQ 和 IBM WebSphere MQ。

企业服务总线 (ESB)

严格来说，ESB 提供集成模式并负责一系列基本任务。这些任务包括通过路由实现可达性、进行消息转换和协议转换以支持交互、支持系统标准的接口耦合的适应性以及企业 SOA 环境可管理性。ESB 位于服务提供者和服务使用者之间，用于分离和服务虚拟化。

ESB 的常见功能包括：

• 路由 — 使用 ESB 的好处是服务使用者不必了解所需调用的服务提供者的确切端点。服务使用者只需向 ESB 发送消息，然后 ESB 根据消息的内容或标头信息转发消息（基于内容的路由/基于标头的路由）。使用此虚拟化层，可以用 ESB 配置轻松替代服务，而不必警告服务使用者或适应松散耦合。也可以使用延迟绑定通过注册表访问虚拟化概念，本文稍后将对此进行讨论。
• 消息转换 — 很多时候，服务使用者和服务提供者使用的并不是同一种语言，因为它们通常基于一般不兼容的“信息模型”或接口。ESB 可以提供一种“转换”服务来解决此难题。后续文章将讨论如何使用转换和锥形数据模型。

ESB 还能提供安全性和事务控制等功能，同时支持其未来的服务组件架构 (SCA) 标准也渐成趋势。

业务流程和工作流引擎

如果业务流程自动运行，则 SOA 中需要业务流程引擎。该引擎管理用标准化语言建模的流程，这种语言通常是业务流程执行语言 (BPEL)，但在实践中也可能是基于 XPDL 或 jPDL 的 BPM。如今经常在流程自动化中使用业务流程模型和标注 (BPMN) 2.0。引擎自动调用 BPEL 中运行的流程中的现有服务并将它们链接在一起，这称为服务编排。BPM 引擎可以独立工作，也可以嵌入 ESB 中（例如，通过 JBI 作为服务引擎）。

典型产品包括 ActiveBPEL、Apache ODE、Oracle SOA Suite 和 Oracle BPM Suite。这些产品的区别主要体现在高容量操作以及它们提供扩展功能和满足产品无缝集成要求的方式上。过渡到工作流引擎的过程异常顺利，尤其是在人机交互和通过 XPDL 的实现方面。BPEL 最初仅用于可自动运行的流程。现在，人机交互特性已经通过 WS-HumanTask 和 WS-BPEL4People 规范针对异步交互进行了升级，使得实际应用中这两者之间的差异不那么明显。

可执行流程不仅用于功能业务流程模型的技术映射，还用于更复杂的 EAI 集成流程的服务实现级别。后续文章将详细讨论这些语言和标注的交互和分界。

规则引擎

由于频繁更改或需要在运行时修改而通常不硬编码到程序代码中的功能规则，应移至规则引擎。在可通过各种接口（如 Java、RMI 或 Web 服务）进行检索之前，可以根据具体系统或使用相对自然的语言以图形方式定义功能规则。一个典型示例是将 BPEL 流程中的一个功能决策变成规则引擎中的一条规则。这种转变避开了复杂的 XPath 逻辑，并且由于无需需部署修改后的流程，还提高了可维护性和灵活性。

典型产品包括 JBoss Rules（以前的 Drools）、WebSphere ILOG JRules、Visual Rules Modeler 和 Oracle Business Rules。

SOA 治理计划

SOA 治理计划主要与组织问题有关，用于控制 SOA 的开发、监视和管理。典型核心领域包括服务组合管理，SLA 监视、操作和部署，服务域和域管理器，建模和开发准则，SOA 项目中的角色以及这些角色与任务之间的转换。

此外，如果制定治理计划的阶段过迟，会增加所构建 SOA 环境不可控的风险，偏离参考架构中确立的商业目标和技术目标。您可能会发现自己所面对的环境具有与当前应用相同的问题，如 Point2Point 连接、交叉关联、缺少标准化格式或并行操作等。

企业架构管理工具和 SOA 信息库是重要辅助工具，不仅支持治理流程，通常还提供最初的管理指南。

常见的治理产品包括 Centrasite Software AG 和 Oracle Enterprise Repository 等。

目录服务

认为可以找到合适服务的服务使用者还需要了解如何根据可见性属性找到该服务。这可以使用一个遵循通用描述、发现和集成 (UDDI) 标准的目录服务来实现。后来服务信息库出现了，它们除了具有与 UDDI 相同的注册表功能外，还需要解决治理问题。虽然根据所提议的 SOA 配置级别的不同，使用信息库可能至关重要，但开始时使用常规建模工具甚至 MS Excel 即可满足需要。

业务活动监视 (BAM)

使用业务活动监视的产品通常在典型管理控制界面中以吸引人的图形方式显示功能显示运行时信息。根据 KPI 监视情况，在使用传感器的 BAM 信息板中以图形方式显示运行的流程实例的值尤为直观。BAM 产品通常还有对应的适配器/传感器，这样还可以使用 Java、PL/SQL 和其他常用语言访问数据。这样，可以监视采购流程内偏离车辆预留下限的情况，并采取适当的手动和自动对策。

知名的 BAM 产品包括 Oracle BAM、vFabric Hyperic、Systar 和 SeeWhy。

复杂活动处理 (CEP)

复杂事件处理 (CEP) 是一个相对较新的领域，其技术尚在发展的早期阶段。CEP 的目的是允许根据时间、空间或内容上不相关的特定模式浏览事件流。一个典型用例是信用卡诈骗未遂检测，此时发生的事件顺序表明同一张卡在几小时内在完全不同的位置被使用。目前的应用领域还包括高容量场景中的金融交易。连续查询语言 (CQL) 提供了一种 SQL 式查询语言，用于添加查询元素并将数据流处理成 SQL 语言结构。典型产品包括 Oracle Event Processing 和 Esper。

SOA 蓝图实际应用

先前描述的所有组件假定都是重要的子函数，可以整合成一个统一的 SOA 基础架构 — SOA 蓝图（图 2）。不是每个项目都需要立即配备各式各样的产品，因为这一过程是渐进式的。在 SOA 项目的初始阶段，随着需求的增加和技术专长的提升，将在 ESB 和/或 BPM 引擎等基础组件上逐渐加入其他组件以逐步实现业务目标。

一旦选定了合适的产品类型，必须将蓝图付诸实施。至于选择的是来自商业厂家的套件解决方案、开源套件还是同类最佳方法，从架构的角度来说是个次要问题。典型产品体系包括 JBoss Enterprise SOA 平台、Glassfish SOA 体系、Geronimo GASwerk SOA 体系、SOPERA ASF 和 Oracle SOA Suite。将 Apache ServiceMix、Apache Camel 和 Apache ODE 等独立产品捆绑成一个专用套件也是可行的。但架构师必须意识到一致性、可管理性和稳定性是重要特征，缺少它们通常会导致完全不同的解决方案。

实际应用中必须考虑的另一项权衡方案是开源中间件产品，因为可以根据需要修改源代码，所以它们支持更好的控制、更多的干预选项。但这种替代方案首先要求理解非常复杂的主题，如开源引擎的 TX 行为。这类更改在商业套件中要么不可能，要么通常非常耗时，因为需要使用产品补丁。注意，现在也可以为特定的开源体系购买商业支持。

另外还需考虑集成产品的一致性和集成，因为正常情况下会使用能干净地与环境集成的集成产品。SOA 非常复杂，如果由于开发人员的低效导致其无法即时与 IDE 交互，其优势也会快速消失。集成监视控制台对于运行时也很重要，因为跟踪通过流程引擎、ESB、规则引擎和其他组件的消息流的能力也是完美集成的产品体系的一项重要特性。

至于具体的产品选择，需要根据每个案例的具体要求对众多决定性因素进行裁决和价值效益分析。无论实际选择何种产品，遵循蓝图都是关键和必要的。如果以松散耦合的方式将所选模块连接起来，可在符合设计更改要求的前提下实现一定的灵活性。个别产品可以发生变动，但基础架构必须保持稳定。

示例：RYLC

图 3 显示了一个名为 RYLC 的租车公司的租用流程，其中展示了各产品类型在运行时如何彼此交互。这些交互实现为一个 BPEL 流程，并通过 ESB 提供以实现虚拟化。

公司租车流程的步骤如下所示：

第 1 步 — 前台应用调用 ESB 服务，此服务启动可执行流程的一个实例。

第 2 步 — 第一个服务调用（称为“readCustomerData”）使用一个通过 ESB 以虚拟化形式提供对应的 CRM 系统功能的服务查找 CRM1 中的所有客户数据。也可以直接使用 CRM 系统或服务的适配器，这种方法通过 ESB 来调用它，无需“迂回”实现。下面各节将讨论这种架构决策的效果。

第 3 步 — 需要确定是否基于客户的 CRM 数据为客户提供特殊服务。此决策通常转移到规则引擎，以保持在运行时更改规则的灵活性。从技术上讲，规则是通过“决策服务”调用的。

第 4 步 — 确定租车系统中符合查询时间段的所有可用车辆、选项和价格。和本过程第 2 步中一样，将租车系统中的对应功能作为服务来提取并通过 ESB 提供。

第 5 步 — 建立可能的车辆组合，以方便客户选择并启动绑定预留。注意，此过程还需要在运行时向用户提问，这从技术角度提出了一种有趣的挑战。在专门的用户界面设计模式一文中将详细讨论此主题。

第 6、7 步 — 恢复正常操作并通过 ESB 调用服务，将所需数据回写到 CRM 系统并安排进行计费。租车流程最后询问客户其租车查询是否成功完成。

图 2：带有可向其添加特定工具的“产品类型”的 SOA 蓝图

图 3：各 SOA 组件之间的动态交互

意外集成架构

以我们目前对静态蓝图和动态耦合选项的了解，不能假定只有逻辑架构是自动创建的（图 4）。尽管没有全面的总体规划或任何违反预定的参考架构的行为，但是使用了 SOA 蓝图的各组件。在本场景中，形成了典型的“意大利面”基础架构，它拥有众多彼此之间直接通信的组件。缺少理顺许多交叉连接的公共基础架构，防碍了安全性和 QoS 等的统一实现。

图 4：意外集成架构示例

有条理的工具箱

图 5 展示了一种大大改进的架构变式，其中 ESB 彻底封装了所有通信。尤其是，可通过为连接系统提供双向服务的连接层提供可重用适配器服务。映射数据结构所必需的方案则通过元数据信息库提供。这种架构的一个优点是可以通过总线集中处理安全性和服务质量 (QoS)，这是图 4 所示场景的一个重要缺点。

本示例清楚地说明，即使是最优秀的工具箱有时也不能独自提供所需的解决方案。架构师的任务是理顺工具箱，且必须确定每个工具的功能和使用范围。哪些工具最适合我们的蓝图，哪些组合会引入困难和/或冗余？是否违反参考架构？实际上，复杂项目的结果很大程度上依赖于主管架构师的经验和专业技能。

图 5：逻辑集成基础架构示例 — 图 4 所示架构的改进变式

常见问题

我们看看实际项目在建立 SOA 蓝图时可能面临的几个问题示例。

问题 1

应在哪些领域使用 BPEL 或 BPMN 2.0？

回答 1

实际上，BPEL 也经常用作 EAI 工具，且许多工具包括合适便利的适配器，它们使用向导快速对接私有服务。这些场景专注于通过各种系统的信息流以及必要的数据转换，而不是功能流程。

第三种应用领域是工作流场景。任务最初是用自动服务还是手动任务处理的并不重要，WS-BPEL4People 和 WS-HumanTask 等产品模糊了全自动服务调用的界限。虽然有些工具支持，但默认情况下应避免通过 BPEL 流程传输事务上下文。稳定操作的框架条件非常复杂，因此到达维护阶段时不可避免地会出现一些潜在问题。

在考虑批处理场景时需要格外小心。针对一天 n 次调用设计的流程并不能立即集成为批处理运行。考虑并行启动 50 万个流程实例，由一个批处理控制器启动。任何流程引擎要逻辑处理此峰值负载都需要采取预防措施。

问题 2

我的流程引擎工具已经具备 ESB 功能，为什么还需要 ESB 呢？不仅复杂度上升，还没有什么新收获。

回答 2

支持当今大多数流程引擎工具的优势促使许多使用者直接在工具中实现组件，而不是按照正确做法将功能转移到 ESB。例如，考虑流程需要的一个数据库表值。由于其简单、易用，在 BPEL/BPMN 中直接使用数据库适配器而不必定义或更改服务，这在原则上是正确的。可以将数据库适配器视作一个技术服务，其可见性为私有，因此不必经历服务生命周期。

但如果项目到达维护阶段，则适配会有风险。在最糟糕的情况下，数据库连接字符串分布于整个应用程序，这会影响灵活性。在流程实例运行时进行更改通常需要重新部署修改的流程模板。相反，如果从纯功能的角度来看，该流程更易于维护、更整洁、更灵活，且适配器/数据读取服务是通过 ESB 提供的，其配置允许在运行时进行干预。

这同样适用于使用直接在流程中配置端点的专用服务而不是使用适配器服务的情况。通过 ESB 虚拟化或通过运行时在 UDDI 中查询特定服务端点的延迟绑定将是提高灵活性的正确措施。

问题 3

我的 Web 应用的屏幕流已经隐式存储在流程流中。为什么不能将 BPEL 或 BPMN 2.0 用作页面流引擎？

回答 3

此问题与区分关注项的方式有关。有些应用仍然需要内部微页面流，对于这些流，有许多可靠的页面流控制器框架可供利用。用例通常完全编写在应用中。相反，专注 BPM 场景的流程包括许多功能序列，每个序列可以视为一个专用用例。因此流程将扮演用例控制器的角色，但对用例内的微页面流没有任何控制。后续文章将详细讨论此主题。

再谈 RYLC：选择组件

因此，上述注意事项对租车公司 RYLC 有何意义？他们已经决定继续采用 SOA 并已经定义要实现的流程，只剩下最后使用哪些蓝图组件的问题。

基本条件是快速成功地解决公司问题同时提供尽可能多的优势。因此，由于时间限制，从头引入完整 SOA 环境的传统方法并不可行。可以快速产生参考项目的 SOA“快速启动”法可能更适合，以便有效地过渡到创建 SOA 环境。

从 SOA 蓝图中为 RYLC 的第一个快速 SOA 项目选择了两个组件：

• BPM 引擎 — 实现新流程，不应再硬编码到应用中运行
• ESB — 解决待处理的集成场景，并为 BPM 引擎编排的服务提供虚拟化层

规则引擎计划用于下一阶段，根据需要对其运用进行分类，以便获得更大的灵活性以容纳频繁更改的规则。最初不包括注册表、BAM 或 CEP，因为并不期望取得短期利益。

上面已经建立 RYLC 将为其第一个 SOA 项目实现的基础架构。后续文章将详细介绍要实现的服务，并讨论相应的指导原则。

总结：要点

• 严格遵循概念，无论起点是开源解决方案还是服务提供商的商业体系。
• SOA 非常复杂，必须利用一切机会进行精简。在可能的情况下使用套件法，将集成的责任交给服务提供商。
• 可以通过使用更高效的商业产品替换喜爱的和/或开源组件来满足进一步的需求。
• 构建 SOA 时通常要一致遵循的最重要的原则是服务松散耦合。
• 如果 SOA 概念在工具级很成功，就可以实现灵活性，因为如果概念兼容，切换工具要轻松得多。
• 区分具体工具及其功能。可热插拔性可在同类最佳的上下文中实现。