开发 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 管理系统的实例。可以按照与提供者管理员角色相同的方式对此角色进行进一步划分。

　　银行业务最终用户

　　银行业务最终用户分为三大类：银行的员工、业务合作伙伴和实际零售客户。详见图 4 中所示。通过将业务合作伙伴包括进来，就可以得到更为复杂的环境，可以将此环境中的一些银行业务服务实际外包给其他服务提供者。在银行业务领域，可以将抵押处理外包给抵押业务提供者。因此，抵押业务提供者可以成为银行的业务合作伙伴，从而要求获得一个对应的参与者身份。

　　图 4. 银行最终用户