通过不同的方式组合现有 SOA 服务来进行 SOA 服务集成。我们将重点讨论如何在服务组件体系结构框架内完成此工作。

　　引言

　　组合应用程序提供了集成现有面向服务的体系结构(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 的外观以及其语义内容(数据字段)。用户界面中的配置变化点的示例有：

　　使用客户特定的徽标和标识重塑网站的品牌。例如，假定有两家银行 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. 银行业务提供者管理员角色

　　银行业务管理员

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

　　银行业务最终用户

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

　　图 4. 银行最终用户

　　用例

　　在此部分，我们将简单说明一下示例组合应用程序中的一些用例。这些用例根据发起用例的主要参与者归入了四个主要功能区域，如图 5 中所示。

　　图 5. 用例模型的功能区域

　　银行业务服务提供者管理

　　第一组用例由银行业务提供者发起。此参与者可以创建银行以及银行管理员。管理员能够配置所提供的服务、创建内部用户、建立安全机制等等。提供者管理员还可以查看测定数据或跟踪用户使用率的数据，从而对解决方案进行监视。这些用例如图 6 中所示。

　　图 6. 银行服务提供者管理用例

　　银行管理用例

　　银行管理员可以配置业务流程(如贷款流程)、添加其他管理员、添加用户(批量方式)和创建银行的各个品牌。具体如图 7 中所示。银行品牌为银行的网站提供独特的外观。

　　图 7. 银行管理用例

　　银行员工用例

　　这个组中的用例是由银行的实际员工执行的。存在不同类型的银行员工，包括平台销售和出纳。银行的员工可以管理客户及其对应的帐户。他们可以创建贷款抵押产品和用户类别，以用于后续 UI 配置。这些用例如图 8 中所示。

　　图 8. 银行员工用例

　　银行客户服务用例

　　此组中的用例是由银行的实际客户通过银行的网站发起的。当然，这些对提供者承载的网站都是透明的。如图 9 中所示，客户可以查看他们的帐户和交易、转帐、申请贷款以及查看自己的贷款申请状况。

　　图 9. 银行客户服务用例

　　拓扑关系图

　　描述了主要用例后，我们接下来要将注意力放到运行时环境上。在我们的示例银行业务场景中，我们将应用程序分布到三个节点上。所使用的节点数量(本例中为 3 个)取决于诸如可伸缩性等许多服务质量问题。下面的拓扑关系图显示了我们决定在何处运行中间件产品。

　　图 10. 拓扑关系图

　　表示服务

　　表示服务在负责用户界面的运行的表示服务节点执行。在这种情况下，WebSphere Portal 为 Web 应用程序提供了一个即时可用且功能丰富的运行时环境。图 11 表示了运行 WebSphere Portal 所需的中间件产品，而图 12 则是我们的示例银行业务应用程序中的一些 Portlet 的视图。

　　图 11. 表示服务

　　图 12. 用于示例银行业务应用程序的 WebSphere Portal 用户界面

　　业务服务

　　业务服务在业务服务节点上运行。我们的业务逻辑正是驻留在此处。由于我们的调用机制基于服务组件体系结构 (SCA)，因此使用 WebSphere Process Server，如图 13 中所示。

　　图 13. 业务服务包含应用程序的业务逻辑

　　企业服务

　　企业服务在企业服务节点上运行，此节点中包含提供数据、安全和其他基础设施服务(如服务注册中心)的产品。Tivoli Directory Server 提供了一个轻量级目录访问协议(Lightweight Directory Access Protocol，LDAP)基础设施，可作为标识管理的基础。WebSphere Service Registry and Repository 允许由提供者注册服务并供使用者选择。

　　图 14. 企业服务

　　支持业务服务的组合应用程序特性

　　支持业务服务的组合应用程序需要反映特定的理想业务意图。这些业务意图的实现允许方便地开发、部署和重用组合应用程序。以下给出了此类意图的简要总结，将作为后续文章的基础，以深入讨论支持实现这些意图的技术特性。

　　多分租：多分租指组合应用程序能够从共享的公共承载环境为多个客户机服务。

　　动态性：动态性可以定义为能够反映在执行期间(即运行时)发生的事件，而不仅是反映预先确定的时间或某个固定的时间的事件。例如，在 WebSphere Process Server 中，专门使用了选择器和业务规则来支持动态性。

　　已发布：组合应用程序可以为已经在目录中发布的服务的用户和提供者。例如，WebSphere Service Registry and Repository 可以帮助和管理此类服务的注册。

　　可自助服务：组合应用程序所支持的功能配置和控制(如业务规则、用户和角色、可配置选项)应该委托给服务的使用者。例如，管理员应该能够更改控制贷款发放的规则。

　　安全：应该仅允许经过身份验证的使用者调用服务和访问其得到授权的信息。信息必须根据客户的角色按照确立的策略进行加密和以保密方式进行维护。例如，在贷款发放场景中，有些贷款可以自动批准和拒绝，而其他则分配给贷款官员进行手动处理。在安全环境中，只有贷款官员有权手动批准或拒绝贷款。

　　可配置性：可以通过业务策略、业务规则、业务服务水平协议和配置参数等项目对行为进行定制，以满足客户特定的需求。例如，WebSphere Portlet Factory Dynamic Profiles 特性可以在用户界面中提供一定的动态可配置性。

　　自动化：自定义是使用具有脚本的“无人”计算机化流程来替换主要通过手工进行的任务。例如，自动部署机制可提供受控制的可重复部署流程。

　　可度量：组合业务服务必须对其业务价值进行量化。例如，业务服务可以使用公共事件基础设施(Common Event Infrastructure，CEI)来生成可以稍后进行分析的事件，以提供业务水平测定结果。

　　可重用：创建服务和组件时必须考虑在不同解决方案中进行重用的意图。SOA 设计技术提供了恰当设计解决方案和组件结构以便在不同上下文中进行重用的方法。

　　灵活性：组合业务服务必须能在基础业务和技术需求发展时适应各种变化。例如，通过使用 WebSphere Enterprise Service Bus，单个 SCA 应用程序可以在无需对应用程序代码进行任何更改的情况下支持通过 SOAP/HTTP 和 SOAP/JMS 协议进行同步和异步通信。