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

密切关注 OTN 架构师社区

SOA 和用户界面

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

克服在面向服务的架构中开发用户界面所面临的挑战

行业 SOA 文章系列的一部分

2013 年 10 月

摘要：在面向服务的架构中，用户界面与服务之间的交互是一个经常被忽略的主题。本文主要讲述在需要调用整个流程链并与之交互的情况下，创建用户界面时需要克服的特殊挑战。在简要介绍架构的一些常规事项之后，作者描述了 Thomas Erl UI 调解器模式的实际应用，并分享了他们自己的技术经验。

简介

在最简单的场景中，用户与业务流程的交互包括启动流程和等待结果。但是，流程很少能够完全自动运行，这意味着在流程周期内，人工干预必不可少。WS-HumanTask 规范可以满足 SOA 环境中的这一要求。为工作流服务定义的标准化 API 可用于向邮箱填充任务。如果使用流程自动化语言 BPEL，BPEL4People 规范定义了如何通过 WS-HumanTask 在流程周期内直接使用这一邮箱功能。当然，BPMN 也可以做到。

例如，如果需要在流程周期内需要执行手动审批或额外输入数据，那么该流程可以确定正确的操作员，并通过任务服务向其邮箱添加任务。HumanTask 服务为此功能提供了一个 Web 服务 API。用户在其邮箱中接收条目，并按顺序处理待完成的任务，与此同时，流程在后台继续工作。

人机交互与邮箱

从技术的角度来看，这是完美的解决方案概念，但许多用户都不熟悉它的处理。对于缺乏角色变更的简短流程，工作流甚至可以认为是一种颠覆性创新，因为传统的数据驱动型应用程序系统可以提供即时响应，而不需要迂回到邮箱。流程控制嵌入在界面控制中。

使用此类传统的应用程序时，用户是其流程的主人，而在邮箱驱动的解决方案中，用户会受规定流程的约束。设计过需要邮箱交互的经典 BPMN 或 BPEL 流程的人都知道，用户将面对邮箱中长长的任务列表，这通常需要用户进行机械、重复的交互操作。如今，许多技术部门都意识到了这个问题，并向日常流程需要记录流程要求的用户提供帮助。

SOA 和松散耦合的出现进一步实现了工作流程自动化，并将流程控制逐渐转移到后端。为了实现灵活性，时常需要对流程做一些适应性改变，所以应避免流程和界面的耦合过分紧密的情况。通过邮箱解耦通常是最有效的解决方案。

异步性实现稳定的界面

图 1 显示了用户界面与流程之间最基本的交互示例。通过一系列网页来收集数据，并将其作为输入参数传递到流程中。类似于服务调用的流程调用专为同步响应行为设计，用于评估结果，然后直接返回到等待页面。这种模式在实践中经常遇到，但不是 SOA 选用的方法。这一架构变种的问题是什么？

如果您思考为什么 SOA 被选作流程实现的架构准则，答案似乎很简单。SOA 提供了绝佳的灵活性，并且流程能够快速实现变更请求。在灵活性至关重要且流程需要更改的情况下，怎么才能确保延迟一段时间才（而不是立即）返回结果？

例如，作为新的要求，正在添加包含通过邮箱进行用户交互的时间密集型活动。实现将“中断”用户界面，因为系统本来一直在同步工作，而延迟的响应现在导致阻塞（或 Web 应用程序超时）。

在实践中，与服务进行同步交互的需求违背了松散耦合的原则。“快速异步性”也许能够满足这些要求，并成功取代同步性。我们注意到，同步与快速异步服务调用在响应时间上相差无几，因为瓶颈通常由网络延迟引起。

图 1：收集所有数据、触发流程并等待结果的标准基本方法。

邮箱方法

因为异步消息交换模式可在调用流程时发挥重要作用，所以我们来考虑其中涉及流程向用户提问的反向场景。由于流程运行在服务器上，因此服务器无法与用户直接通信。始终需要从用户的计算机发起通信。

图 2 显示了邮箱方法，这种方法在所有流程和工作流周期环境中的实现方式是一样的。流程确定操作员（人或角色），并将任务添加到其任务列表中。然后，流程等待操作员从邮箱删除该任务，并将该任务作为已处理的任务返回。可传输任何类型的复杂数据，某些环境允许嵌入整个屏幕区域，以供用户输入需要显示的数据。

在许多情况下，使用邮箱方法有一个明显的好处。可以从个别员工和硬连接的应用程序提取流程知识，并以流程的形式显化。可以使用更高级的流程控制，将多个复杂应用程序的操作广泛标准化。同时还创造了监视个别流程实例的机会，从而显著提高公司的透明度。

图 2：显示了长期流程的工作列表应用程序（邮箱）。

Erl 的模式与 SHIL

Thomas Erl 在《SOA Design Patterns》（2009 年，Prentice Hall）一书中提到了我们针对此问题设计的解决方案，名为“UI 调解器模式”。该模式高度抽象地描述了问题和解决方案背后的原理。从实际的角度，我们将描述已在之前的项目中成功实现的 UI 调解器模式的实现变体，称为“服务人机交互层”。

同步（人）和异步（流程）的均等化要求

除了 BPEL 或 BPMN，还需要一种可以满足这些要求，以将 UI 调解器模式应用于 SOA 环境的解决方案：

• 无需在前端重复实现业务流程逻辑和业务规则
• 所需的屏幕流以同步方式链接

第二个要求位于服务人机交互层 (SHIL) 的核心。SHIL 向用户模拟同步性（图 3），虽然在技术上是以异步方式工作。用户不再需要随时关注邮箱中出现的新任务，因为 SHIL 会以透明的方式执行此功能。这可最大限度减少邮箱条目的数量，使用户能够在当前待完成任务的框架内（而不是在复杂的任务列表内）按自己的节奏工作。

图 3：UI 调解器向用户模拟同步性。

“同步”意味着用户可以在特定的用户界面上工作，能够立即（同步）从被触发的服务器接收对请求的响应，无需等待“异步”响应。人们喜欢与系统同步工作，但自动运行的业务流程只将用户视为“异步服务”。当流程无法立即获得所需信息时，流程会以异步方式发出请求，等待有人提供响应。SHIL 解决了首选通信机制之间的这一冲突（图 4）。

图 4：服务人机交互层 (SHIL) 显示为 UI 调解器模式的实现。

SHIL 解决方案设计

要设计 SOA 环境中通过 SHIL 进行的 UI 通信，需要两种类型的流控制器：

• 微流控制器
• 宏流控制器

微流控制器通常是一个类似于在 Struts、JSF Spring Web Flow 中使用的 UI 控制器，它在前端实现与用例有关的所有屏幕流和 GUI 与人的交互。可以使用已定义的流 ID（例如，可从外部触发的“自由飞行”网站）启动单个屏幕流（宏视图）。

宏流控制器位于 GUI 与业务流程层之间，控制 GUI 与流程之间的通信。请注意，在这些情况下，不应实现 GUI 的屏幕流控制。BPEL 或 BPMN 等宏流语言因为不够灵活，所以并不合适。实际页面流仍在应用程序中（微流）。

如果流程层中需要涉及 UI 交互的用例，宏流控制器将按事件逐个进行干预，并就在哪个用例或前端执行通知微流控制器。通知时包含功能屏幕流的逻辑名称通常就足够了。这种透明的中间层被称为 SHIL。

SHIL 是一个典型的横截面方面，可以使用面向方面编程 (AOP) 轻松插入 GUI 中。透明性意味着调解层不能包含任何应用程序逻辑。有效负载的消息头中包括用于关联的数据，如用户的会话 ID。可以使用 GUI 选择并启动下一个微流的永久流 ID 由 BPEL 或 BPMN 层验证并传递到 SHIL。下一步要执行的微流（用例）仅由 UI 端的微流控制器确定。

任何时候取消事务，都必须必须保持流程的一致性。如果用户暂停处理、关闭浏览器或中断连接，处理必须能够在其他时间恢复。因此，在此解决方案的情形中，使用邮箱具有至关重要的意义。SHIL 与邮箱交互，系统通过流程的推送，只向其通知新收到的邮件和相应的流 ID。

因此，SHIL 的特点归纳如下：

• SHIL 是一个纯调解层，通过使用 AOP 等技术并调用 HumanTask 服务，管理 UI 与 BPEL 或 BPMN 流程之间的消息流。
• SHIL 无法存储任何应用程序逻辑。
• SHIL 是一个横截面方面，可以使用 AOP 方法透明地集成到 GUI 控制。
• 下一步要执行的微流仅在 UI 中，根据 BPEL 或 BPMN 业务流程传递的信息来确定。
• 所有流程消息都需要一个额外的消息头来通过流程向 SHIL 传输流 ID 和关联 ID。
• 邮箱（工作流服务）用作故障处理和预防的缓冲区，如延缓由最终用户执行的终止操作。
• SHIL 在 GUI 端实现简短异步流程（少于 10 秒）中同步行为的模拟，并伴有具有阻塞作用的“等待”消息。
• SHIL 在 UI 端为长期流程管理取消和通知。

使用 SHIL

用户应该能够尽可能久地与服务器进行同步通信，而不是被邮箱控制。以下场景描述了在 SHIL 环境中用户实际上如何与流程交互：

1. 在 UI 中完全处理完第一个用例之后，启动流程。
2. SHIL 进行干预并创建所有必要的相关信息，如用户会话和流程实例 ID。
3. 根据所需的处理时间，可能发生三种不同的情形：
   • 如果流程只需不到一秒的时间即可完成，SHIL 会将响应直接转发给显示下一个页面的用户界面。
   • 如果处理时间需要一到十秒，SHIL 将向用户显示可跳转到结果页面的“等待”对话框。
   • 如果超过十秒并发生超时，SHIL 会拒绝“等待”对话框，同时向用户显示道歉信息，并解释伪同步无法提供所需的便利。
4. 流程下次报告时，将以异步的方式向用户的邮箱添加一个新任务。

总结

使用工作列表的经典工作流方法自然适用于用户界面与流程的整合。现有接口可通过“邮箱”轻松扩展，邮箱使用任务分配的方式为用户提供参与流程周期的途径。当跨角色的操作可行或可取时，这种方法也适用，从技术上讲，该方法使用专有的工作流系统或基于 BPEL/BPMN 的解决方案。如今，所有 BPM 软件都有相应的功能。

但是，如果所使用的流程频繁、反复地向同一邮箱添加任务，并且不涉及角色变更，那么应用 UI 调解器模式可以为操作员带来更多便利。系统会向操作员模拟准同步操作行为，即使系统内部是异步机制。所获得的便利以增加实现成本为代价的。

对于定制构建项目，需要注意两个问题。首先，应用程序必须经过特殊设计，以便与所运行的流程进行交互。其次，技术部门对即时、同步响应调用的需求通常可以使用快速响应异步架构模式更好地实现，以实现所需的灵活性。

要点

• 业务流程的自动化通常需要人参与到流程周期中去。
• 大多数情况下，使用邮箱方法整合用户的经典工作流解决方案（如包含工作流服务的 BPEL/BPMN）已经足够了。
• 应用 UI 调解器模式通过模拟准同步操作行为为用户提供了更多便利。
• 对即时、同步响应调用的技术需求通常可以通过快速响应异步架构模式更好地实现。