开发SOA组合应用程序来支持业务服务(1)

引言

组合应用程序提供了集成现有面向服务的体系结构（Service-Oriented-Architecture，SOA）服务和/或创建能够以不同方式进行组合的新服务的能力。组合应用程序的关键是使用 SCA 将可重用软件资产作为 SOA 服务实现创建。我们使用 WebSphere Process Server、WebSphere Portal、WebSphere Service Registry and Repository、WebSphere Enterprise Bus、WebSphere Portlet Factory 和 WebSphere Application Server 及其相应的开发工具开发了一个金融领域的示例组合应用程序。所选择的场景提供了一些示例，这些示例说明了开发高效组合应用程序所需的不同特性的实现。我们将首先通过这些示例场景来说明组合应用程序的好处和挑战。最后，我们将分析 IBM 产品中的技术特性以及可以如何将其用于开发组合应用程序。

在本文中，我们首先定义了组合应用程序、变化点、角色、用例、运行时环境，并给出了一个业务意图列表，为了创建支持业务服务的组合应用程序，需要实现这些业务意图。

本系列的后续文章将更为详细地对几个相关问题进行分析，包括多重租赁 (Multi-tenancy) 设计模式、应用选择器和业务规则来实现动态性、发布服务、自助模式和资产、使用动态配置文件的可配置用户界面、自动构建和部署、使用 CEI 开发可度量应用程序以及其他类似的主题。

什么是组合应用程序？

SOA 组合应用程序定义为“一组解决特定业务问题或任务的动态服务组件。组合应用程序经常提供一组服务，而这些服务又可能属于其他组合应用程序。”业务服务是业务单位选择在其边界公开的服务，通过接口与其客户、合作伙伴或其他业务单位连接。业务服务实现有意义的业务流程或任务。组合应用程序由一个或多个组件或组件聚合组成，而其中每个组件或组件聚合会公开一个服务接口。组合应用程序为业务服务提供支持。

图 1. 用于进行零售银行贷款发放的组合应用程序

正如图 1 中所示，组合应用程序对一系列可配置服务进行编排。例如，在此示例中矩形与公开业务服务的业务组件对应，如 Validate。红线指示组合应用程序的特定用例所遵循的调用序列。沿着红线，将依次接受贷款申请，生成信用记录，然后验证、分析和提供贷款。批准贷款后，必须对其进行初始化、配置、结算并记录。最后，将发起对话，以与客户进行沟通。

在此上下文中，服务组件体系结构（Service Component Architecture，SCA）是面向服务的组件模型。它提供涵盖无状态会话 EJB、Web 服务、传统 Java 对象（Plain Old Java Object，POJO）、Web 服务业务流程执行语言（WS-Business Process Execution Language，WS-BPEL）流程、数据库访问、企业信息系统（Enterprise Information System，EIS）访问和其他服务实现的抽象，如下面的图 2 中所示。SCA 将业务逻辑与基础设施逻辑分离开来，因此程序员能够集中精力处理业务问题。

图 2. SCA 实现类型

变化点

变化点是确定可能发生更改而应该外部化的位置。具有内置变化点的服务组件允许用户通过对这些服务进行配置来满足不同的需求。可以将可扩展性机制加入到 UI、服务组件接口、服务组件本身以及数据模型中，从而实现可配置应用程序。

非常有必要对可配置性和自定义进行一下对比。可配置性为我们提供在不更改代码库（编写代码）的情况下使组件适应不同需求的能力。可配置性构建到服务（Switch、Dial 和 Lever）中，可以由应用程序的用户进行调用。相反，自定义要求开发额外的代码（使用编程语言）来扩展和更改软件组件，以支持特定的“自定义”行为。

我们可以将这些变化点归为三大类：用户界面、业务逻辑和持久性。

用户界面 (UI)

用户界面中的变化点允许用户通过配置更改 UI 的外观以及其语义内容（数据字段）。用户界面中的配置变化点的示例有：

1. 使用客户特定的徽标和标识重塑网站的品牌。例如，假定有两家银行 Bank A 和 Bank B。这两家都具有自己的徽标或品牌，并希望网站能够反映这一点。
2. 更改在用户界面显示的标签和文本，以使其对使用它的员工和客户恰当，且为他们所熟悉。例如，一家银行可以使用术语 Preferred Aclearcase/" target="_blank" >ccount作为输入字段的标签，而另一家银行则可以使用术语 Advantage Account。
3. 更改向用户公开的输入字段。一家银行可以允许用户输入备用手机号码，而另一家银行则可以不允许提供此信息。
4. 更改用户调用的 SOA 服务的端点。可能会根据在国内的地域不同而使用不同的信用检查服务，因此可通过外部化端点来允许对其进行配置。

业务流程

由于多个组合应用程序解决方案可以使用同一个业务流程，因此每个应用程序实现可能会希望使用相同业务流程的略有不同的变体。因此，业务流程务必提供变化点，以允许组合应用程序的用户根据自己特定的需求配置业务流程。例如，假定一家银行决定向特定期间内开立新帐户的每个人提供礼品选项（如烤箱）。该银行将要求开户业务流程具有向所有新帐户所有者派发礼品的活动。不过，对于其他银行，应该禁用此活动。

为了实现此要求，组合应用程序实现需要能够禁用业务流程中的可选活动。WebSphere Process Server 提供了外部化变化点的机制，以允许用户在不必进行自定义的情况下配置业务流程。在 BPEL 业务流程中进行此工作的一个简单方法是执行活动前检索业务规则，此业务规则返回一个 Boolean 值，指示此活动是已启用还是已禁用。在上一段给出的示例中，我们将使用一个礼品规则，管理员可对其进行开启或关闭，从而最终启用或禁用业务流程中对应的“send gift”活动。

数据层

数据层中也一定存在变化点。由于组合应用程序可能具有不同的数据视图，因此需要能够在数据库模式层提供数据可变性。例如，一家银行可以捕获其客户的国籍，而另一家银行则不会进行此操作。由于我们对两家银行使用了相同的组件实现，因此我们访问的是相同的基础数据库模式。因此，我们需要在数据层中提供可变性，以便能够为一家银行存储客户国籍，但另一家银行却不需要如此。

提供此功能的一个可能的方法是将数据属性存储在驻留于数据库中的 XML 文件中。将数据属性保存在 XML 中可以允许采用非常灵活的模式，能在不用更改逻辑数据库模式的情况下添加或删除属性。由于数据库将此 XML 文档存储在一个数据库属性中（DB2® V9 的一个特性），因此将不会更改数据库模式，故而能实现此操作。

下面的部分将说明 Jivaro 银行组合应用程序的一些主要角色以及一些主要用例。

角色

让我们简要定义一下与我们的示例银行应用程序相关的一些角色。

银行业务提供者

这是向多个银行提供承载非现场银行业务的组织，通常为商业公司。此提供者的人员组成包括管理人员，即银行业务提供者管理员 (Banking Provider Administrators)，可以进一步划分为操作管理员 (Operations Administrator)和服务管理员 (Service Administrator)角色。前者处理日常操作，而后者配置每个银行所使用的服务。主管理员可以执行所有任务。图 3 以 UML 关系图的形式说明了所有这些关系。

图 3. 银行业务提供者管理员角色

银行业务管理员

银行业务管理员是使用提供者承载的服务的各个银行（如 Bank A）的员工。他们的任务是为 Bank A 管理系统的实例。可以按照与提供者管理员角色相同的方式对此角色进行进一步划分。