一般而言，案例处理是一个复杂的业务流程，特别是在涉及社会计划和保险理赔业务的复杂企业中。这种流程中有许多异常路径，即使其中所谓的 “快乐路径” 也既漫长又复杂。案例处理业务流程中充满了大量机遇，可以利用它们实现自动化和面向服务设计和开发。处理这个项目的团队调整了在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定义的用例。

用例名称	说明
Display Examiners Dashboard	缺陷（disability）审查员指示板是一个显示器，向审查员显示他们的总体工作负载的状态，他们需要执行的动作，以及与他们正在处理的案例相关的事件。这个指示板是审查员访问他们正在处理的案例、执行并完成指定动作、以及查看关于事件的扩展信息的出发点。这个用例描述审查员如何显示指示板，以及指示板显示的信息。
Display Case Information Case Information Display	向审查员提供关于一个特定案例的详细信息，允许他们在整个确定流程中访问检查、分析、更新和管理与该案例相关的活动所需的所有功能。
Assign Case to Primary Examiner	系统中的每个案例都被分配给一个缺陷审查员，该审查员负责开发案例并在整个确定流程中管理事件。这个用例描述一个审查员如何成为一个缺陷案例的主审查员。
Submit Case to System	这个用例描述一个缺陷案例如何进入系统。主执行者是一个外部系统，该系统收集了关于一个案例的足够信息，以便将该案例提交到系统来完成确定流程。
Solicit Electronic Evidence Document	缺陷审查员开始这个流程来获取一些电子证据文档，这些文档支持来自此案例中确定的源的案例指控。系统向选中的提供者发送通知。如果某个提供者没有在指定的天数内作出回应，系统将提醒缺陷审查员执行后续动作。
Submit Electronic Evidence Document	收到对一个电子案例证据文档（UC005）的请求后，证据提供者通过一个中介暂存系统（intermediate staging system）提供一个文档。暂存系统向案例系统通知这个提交，并将该提交添加到一个案例的证据集合。主审查员收到警报。
Transfer Examiner”s Workload	系统意识到该工作已由一些人员执行，那些人员属于一些按层级安排的组织。一个组织可以被关联到一个工作场所，工作场所定义组织的地理位置。这个用例描述一个审查员的工作任务如何转移到同一个组织内的另一个审查员。
Transfer Organization”s Workload	这个用例描述系统内的工作职责如何从一个组织转移到另一个组织。例如，如果一个自然或人为紧急情况阻止某个组织执行工作，就需要这个功能。从一个组织转移工作负载移除了那个组织内的人员的工作任务，并将那些工作任务分配给其他组织内的人员。
Request Assistance Document	在案例分析过程中，审查员请求协助分析案例。系统基于一组业务规则选择将提供协助的用户。
Provide Assistance Document	收到一个协助请求文档后，协助提供者通过一个注释提交页面提供一个注释。系统通知主审查员谁发出了协助请求，注释被添加到案例的注释集合。

　　服务组件设计

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

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

图 2. 服务模型

　　服务

服务名称	说明
Alert Service	警报是业务事件的通知。警报包含事件相关信息和上下文信息，这些信息可用于基于警报的接收启动特定动作。
Business Event Audit Service	注册、记录和检索重要业务事件，实现了审计线索的概念。事件类型通过一个名称识别，服务没有指定名称的格式，但建议遵守特定域名的规则。
Document Service	负责执行针对一个文档管理存储库存储和检索电子文档的操作。Case Documentation Service使用这个常规服务来存储与案例相关的特殊文档。
Organization Service	管理反映企业组织关系和人员与组织单位之间的成员关系的模型。每个人员都属于一个组织，每个组织都属于一个父组织。组织可以关联到工作场所，工作场所定义组织的物理位置。
Text Communication Service Text Communication Service	负责维护一个消息模板库，生成并传输来自那些模板的消息，在已命名的插入点添加定制信息。这个服务处理 Email 和 SMS Text 通信。
Work Assignment Service	实现工作任务概念；在工作任务概念中，任务类型可以动态定义，并随同任务类型的相关上下文信息实例化。任务可以绑定到任意已命名实体，包括但不限于系统用户。支持任务转移并维护任务历史。
Vendor Service	供应商（vendor）是一个普通词汇，适用于充当案例文档源的任意外部组织。 这个服务维护一个案例文档供应商注册表，包括它们的组织名称、联系信息以及交互偏好。
Case Information Service	维护系统中的案例的基本信息。这个服务管理与案例相关的索赔、索赔人以及联系信息，使用一个惟一键来检索所有案例相关信息。
Case Processing Service	合成服务负责执行一些操作，那些操作根据业务规则维护案例和业务领域的其他部分之间的关系。这样的操作比如选择一个人员，基于案例、组织和人员特点进行案例分配。其他操作还包括转移案例、汇总组织的案例工作负载等。
Evidence Service	维护案例及其支持文档之间的关系。
Case Assistance Service	这个服务专门用于协调受命执行与一个案例相关的任务的多个人员的操作。

　　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架构风格的一个重要优势。