变化点

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

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

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

    用户界面 (UI)

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

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

    业务流程

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

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

    数据层

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

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

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

    角色

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

    银行业务提供者

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

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