简介： 面向服务架构和 SOA 编程模型是实现真正的敏捷性和使 IT 和业务协调一致的希望所在。但开发真正的面向服务架构软件真正需要的是什么呢？本文将探索一个小型架构师和开发人员团队的经验，该团队基于在 WebSphere Business Modeler 中建模的一个业务流程模型，从无到有构建了一个 SOA 应用程序。本文描述了他们的设计和开发流程，包括面向服务设计和数据建模的一些注意事项。我们将深入研究该项目实现的一个业务流程，并探讨使用 WebSphere Integration Developer 在 BPEL 中开发流程和在 SCA 中开发服务组件的技术。

概述

一般而言，案例处理是一个复杂的业务流程，特别是在涉及社会计划和保险理赔业务的复杂企业中。这种流程中有许多异常路径，即使其中所谓的 “快乐路径” 也既漫长又复杂。案例处理业务流程中充满了大量机遇，可以利用它们实现自动化和面向服务设计和开发。处理这个项目的团队调整了在 WebSphere Business Modeler 中创建的业务流程模型，以便演示：与传统的编程方法相比，SOA 如何在实现业务流程方面提供增值。

在面对这个挑战之前，这个开发团队在 SOA 架构风格和 SOA 编程模型方面都没有经验。架构师安排了使用的工具（WID、WPS、WESB）的培训，并花时间来对开发人员培训 SOA 风格和编程模型。最后，开发团队理解了 SOA 概念，并且能够独立进行设计和开发。

这个挑战的结果将在下面介绍。团队在 Service Component Architecture (SCA) 中创建了一组可重用服务，在 Business Process Execution Language (BPEL) 中创建了 3 个业务流程，还创建了一个底层数据结构和一个富 web 界面来呈现用户体验并展示技术概念。本文将描述应用程序设计的关键元素，流程和服务的开发，以及应用程序的部署和测试。

概念

在这个项目中，我们首先制定并演示了各种关键面向服务概念。这些概念与典型业务流程中所需的东西 — SOA 的目标 — 直接相关，以便提供一个遵循业务流程的 IT 解决方案。

下面的列表描述了这些基本概念。

• Service Orientation（面向服务）：将服务定位为 IT 资产，这些资产有望随时间变化提供重复价值，从而超过初始开发成本。
• Automated Process Flow（自动流程流）：协调人员和服务组件的动作，确保所有案例经过一系列相同的处理步骤。自动化流程响应事件，并确定何时继续执行下一个处理步骤。
• Service-Based Activities（基于服务的活动）：自动化流程流包含服务组件执行的活动。流程流调用服务操作，传递流程中某一点提供的信息。服务操作可以执行动作或返回信息，流程在自动化流中向前传播该信息。
• Human-Directed Activities（人工指挥的活动）：自动化流程流包含需要人员注意和操作的步骤。人员通过在系统用户界面中维护的一个工作负载指示板获悉即将执行的动作。人员至少需要通过系统用户界面指出动作的结果，从而允许流程流继续执行。
• Time-Driven Activities（时间驱动的活动）：在自动化流程流中，有些活动必须在特定的时点发生。流程流可以在一个指定时点启动，或者在一个指定的时段内挂起。时间驱动的活动可以执行一次，也可以根据一个时间表反复执行。
• Informational Alerts（信息警报）：自动化流程流可以探测对系统用户重要的条件。在那些时点上，流程流可以生成信息警报，转发给一个或多个系统用户。这些警报在用户指示板上显示。
• Externalized Business Rules（外化业务规则）：流程流通过在决策点应用业务规则受到指挥。那些规则可以通过一个专用管理界面、在系统运行过程中得到更新。

设计应用程序

本节详细讨论应用程序设计过程中的许多注意事项。

用例设计模式

定义系统用途是设计和开发流程的首要步骤。这适用任何架构或编程风格，尤其是 SOA 设计和开发。在概念证明（proof of concept，PoC）中，设计流程首先定义一组用例，用于代表 PoC 将实现的目标。更精确的说法是，那些用例被选择来支持通过概念证明展示的 SOA 概念。

为促进应用程序组件、服务和流程的开发并制作用例文档，我们构造了一个模板，以便描述每个用例。这些文档作为 Word 文档创建，拥有以下主要部分。

图 1. 用例

用例文档有几个重要特征。用例文档描述一个特定系统用例中涉及哪些人员（或执行者），他们在那个用例场景中执行了哪些操作。这个用例在用例的主流程流中采集，也在替代流程流（没有显示）中采集。在某些条件满足或某些错误发生时，可能会出现替代流程流。一个用例全面描述系统的一个用途，用例集合全面描述系统的所有用途。拥有这些文档后，设计人员和开发人员就可以在技术层面上完整描述系统的数据、行为和特征了。

本文 “下载” 部分提供了用例文档的一个完整模板。

下表描述了为 PoC 定义的用例。

服务组件设计

遵守定义明确的内部架构的服务实现更容易设计、构建、维护并随它们的服务生命期扩展。PoC 团队花费了大量时间考虑应用程序和服务构造期间使用的模式。由于团队比较小，因此可能在项目期间生成的所有软件中使用的惯例形成共识。这对我们的项目来说是一个优势。我们的所有服务都使用相似的结构和惯例。但是，这样的一致性对于 SOA 生效并不是绝对必要的。不同的开发组织可以根据他们开发的惯例确定他们的工作的风格。只要服务接口定义明确并有效地实现，企业就能使用各种技术来构建软件。

项目设计阶段，团队每天都会面，处理业务流程和用例，以确定需要的服务。下面的图表描述一个典型用例中的服务及其关系，并通过 UML 图表使用。 下表列示了被识别的服务以及每个服务的基本功能，充当服务的详细规范的一个出发点。本文后面将展示一个服务规范模板样例，服务规范模板用于在项目中详细描述服务，以便开发人员据此构建服务。鉴于团队的规模较小，规定服务的人员还负责构建服务。但是，该团队非常注意采用制作服务规范文档方面的最佳实践，这是各种规模的团队都应该采用的实践。

图 2. 服务模型

服务

服务

SOA 中的每个服务都必须拥有一个规范。在这个项目中，团队通过一个服务规范文档来描述服务功能。下图展示了一个服务规范文档的节选。

图 3. 服务规范 (1)

图 4. 服务规范 (2)

下面描述服务规范的重要元素。

• Service Operation（服务操作）。全面描述服务将通过其 WSDL 公开为服务操作的功能。一个操作有一些输入参数、返回值，还有一些可能发生的故障，它们可以通过服务处理并传递给使用者。
• Data Types（数据类型）。服务公开数据上的操作。服务规范中的数据类型说明定义入站和返回数据的预期类型和组织。这对于服务使用者确保正确调用服务操作并正确理解服务操作并返回的数据很关键。

数据设计

进行数据建模时不考虑服务边界通常会促成这样一个模型：只针对单个应用程序优化，但缺乏支持松散耦合的可重用服务的灵活性。PoC 团队发现，一个更好的方法是使用应用程序需求来创建一个服务模型，该模型包含对灵活的命名空间、补充对象属性和其他定制特性的支持。这样就可以为支持应用程序所需的每个服务创建更小、更简单的数据模型。

图 5. 数据服务

服务对象的动态注册为了在广泛的应用程序中使用，一个服务不能因为要支持一个新用途而需要进行开发或配置。这个项目中指定的服务就遵守这个原则。团队考虑如何引入耐用的、服务管理的对象类型的变体来支持案例系统和潜在的其他应用程序使用的不同案例。构建一个可扩展的服务的一种方法可能是通过 XML 或类似方法、使用对象类型的属性、以静态方式配置服务。团队否决了这种方法，因为它与一个成功的面向服务架构不兼容。新应用程序需要开发人员在服务中定义新对象类型，以便支持每个新应用程序。相反，为此项目开发的所有服务允许使用服务界面中的操作针对服务动态注册新的对象类型。这种方法允许新应用程序自己提供服务支持的已定制对象类型。 这种提供可以通过为服务构建的一个管理用户界面实现，或者直接在客户机应用程序代码中实现。这个 PoC 项目同时使用这两种方法。

软件架构

下面是此项目中构造的软件配置的一个表示。软件组件以一种特殊的方式安排并互联，以便提供问题隔离和一种模块式设计模式，这种模式与现代 MVC 模式和 SOA 架构风格是一致的。

图 6. 软件架构

构建应用程序

从应用程序设计开始，团队分解出一些构造任务，这些任务是应用程序的模块式设计的逻辑产物。SOA 支持使用下面的图表显示的关联开发任务、沿服务组件边界划分工作。本文不讨论数据库实现和 UI 实现，本文的重点是服务组件和 BPEL 实现。您只要明白还需要大量工作来实现表示层和相关控制逻辑、以及一个定义明确的数据访问层就可以了。在这个项目中，我们在用户界面层使用 Struts 框架和 Ajax ，在数据访问层使用 Hibernate。要了解更多细节，请联系这些框架的作者，并参考本文 “参考资料” 部分。

下面几个小节将描述这个 SOA 应用程序开发中的一些重要元素，我们将使用 Service Component Architecture、BPEL 和 WebSphere Integration Developer software。

序列图

这个序列图描述流程中的操作顺序，以及哪个组件处理操作请求。序列图是编排业务流程的一个非常有用的设计工具。

图 7. 证据请求流程的序列图

服务接口（WSDL）

这个应用程序中的每个服务都通过它的 Web Services Definition Language (WSDL) 文件定义。在我们的示例中，WSDL（即 XML 文件）在 WebSphere Integration Developer WSDL 编辑器中显示和修改。服务操作和输入/输出类型通过 WSDL 描述，以便使用者准确了解服务向操作提供的内容、服务对参数的预期以及返回的结果。下图显示应用程序中的一个服务的 WSDL。

图 8. 证据流程的 WSDL

BPEL 流程

Evidence Solicitation 业务流程很好地展示了项目执行的工作。项目构建了一个负责获取电子证据文档的 BPEL 组件。

当一个案例提交到系统时，它包含一列潜在文档及其提供者（当前持有文档的供应商）。文档提供者在案例信息显示中对审查员可见。当审查员决定需要一个文档来补充基本案例信息时，该审查员将启动请求流程。

请求流程接收一个证据项目，该项目包含案例标识符、需要的证据的类型、以及从其获取证据的供应商。请求流程向该供应商发送一个通信，供应商可以使用该通信包含的信息来定位想要的文档，以及一个已编码的 URL，该 URL 可用于将一个文档副本上传到一个安全的文档存储库，文档副本在文档存储库中成为案例信息的一部分。但是，对于项目目标，电子邮件通信提供了最直接的通信通道来实现。

发送初始通信之后，流程监控请求进度。如果在预定的天数后请求的文档没有出现在存储库中，流程将发送一个后续警报给审查员。这个警报包含关于请求的已定制上下文信息，显示应用程序使用这个信息来显示请求的当前状态的相关信息。那时，审查员可以决定后续动作。流程接受 3 条事件消息：取消请求、继续（继续等待）、以及继续通信（发送另一个通信到提供者并继续等待）。

当供应商将文档提交到存储库时，流程更新案例来表明文档可用，并发送一个已提交证据的警报给审查员。此时，流程结束。审查员现在可以查看已提交的证据文档。

图 9. BPEL 中的证据请求流程

上述 BPEL 流程是一个更大、更可靠的 BPEL 流程定义的一部分。要查看完整的 BPEL 流程，请参见 “下载” 部分中的 BPEL 流程映像下载链接。

组装图

此项目将这个流程实现为其 SCA 模块中的一个 BPEL 组件。第一步是定义流程的 WSDL 接口，该接口描述流程支持的操作或事件。startRequest 操作启动流程。cancelRequest、continueRequest 和 continueRequestWithCommunication 操作定义允许审查员控制流程执行的事件消息。submitEvidenceDocument 操作表明请求的文档已被提交。最后，captureCurrentState 操作允许客户机显示进度信息。

图 10. 证据请求流程的 WID 组装图

组装图显示流程依赖大量为项目构建的服务。这些服务作为导入显示在组装图右侧。

部署应用程序

下面是部署后的 PoC 的架构。这是一个概念证明演示，因此这个部署架构并不旨在高度可伸缩或容错。我们选择跨一个异构硬件和操作系统架构部署这些服务，以便演示 SOA 中的虚拟化，并在某种程度上便于演示。生产级架构看起来会非常不同，读者应该意识到，这个项目的有限范围决定了其部署架构。

图 11. 部署架构

这个部署架构有几个特性，它们对于演示概念证明中的概念很重要。

存在内联网和互联网。证据提供者位于防火墙外，显示为互联网上使用 gmail 的一个用户。其目的是展示流程中的参与者的异构性是可能的。

服务虚拟化。SOA 的一个关键特性是能够从多个端点引用和调用服务。端点的配置允许必要的服务虚拟化。在这个演示中，团队可以随心所欲地从一个位于中央的电子邮件服务切换到一个远程服务端点。

数据联合。来自多个异构源的数据被联合起来并通过数据服务公开到应用程序层。数据服务处理数据上的所有 CRUD 操作。

水平伸缩和容错。软件栈部署在一个拥有双向 WAS 集群的集群环境中，这个集群可以扩展为多向集群。

组装

有几种方法可以打包一个应用程序以便在 WebSphere Application Server 和 WebSphere Process Server 中运行。一种方法是创建一个包含所有服务及其关联代码的单一、大型部署单元。这种方法的不足之处是缺乏模块性，好处是易于部署。

在这个项目中，我们选择为每个服务组件创建一些部署单元（EAR 文件），为 web 接口创建一个 EAR 文件。这允许我们根据需要部署（或重新部署）服务，而不必部署整个应用程序。事实证明，这种方法对于开发有好处，因为我们经常需要只更改一个服务组件并重新部署那个组件。将每个服务打包到它们自己的部署包中使得流程更快，开发和测试更高效。

下图展示了所有服务组件都已安装且作为独立企业应用程序运行的 WebSphere Application Server。

图 12. 部署单元

结束语

对于不熟悉 SOA 概念的新手而言，使用 BPEL 和 SCA 在 SOA 中实现一个业务流程是一个挑战。这个项目团队通过实践了解了如何用 BPEL 实现一个业务流程，如何在 SCA 架构中调用服务。通过这次实践，团队形成了一些最佳实践，并了解了一些需要避免的误区。

本文总结了一个项目的设计和开发过程，这个项目使用业务流程执行和服务组件架构，并利用了 WebSphere 工具系列。我们了解到，SOA 架构风格和编程模型在软件中实现业务流程方面具有巨大的优势。Business Process Execution Language 和 SOA 工具的开发和运行时支持能够提供一个可靠的环境，可以在这个环境中实现长时运行的业务流程并在较长的时间段内维护业务流程内的状态。这次实践显示，Service Component Architecture 能够在服务实现细节之上提供必要的抽象，提高开发团队的生产力并支持服务重用和合成 — 这是 SOA 架构风格的一个重要优势。