构建 SOA 组合业务服务，第 7 部分: 为组合业务服务提供多分租支持

本系列之前的文章介绍了组合业务服务 (CBS) 的概念，并讨论了其需要的部署环境的一些核心元素。本文将介绍多分租（即从共享的公共承载环境中为多个组织（客户）提供服务的能力）。另外还将介绍软件作为服务（Software-as-a-Service，SaaS）的网络交付方法及可能会利用 SaaS 多分租的不同用户类型。我们将介绍在 SaaS 承载环境中支持多分租的原则和技术实现。本文提供了使用 WebSphere® Process Server 和 WebSphere Portal、虚拟门户和 Portlet 的克隆与配置实现模式的多承租者平台实现。通过示例，我们还能了解如何对 Portlet 实现进行更改，以支持门户角色的扩展配置文件信息。本文将重点讨论为了支持订阅者和最终用户而对软件服务和基于 Portlet 的用户界面的设计更改。

多分租

在软件作为服务 (SaaS) 模型（也称为随需应变软件）中，服务的交付（如使用 WSDL 描述的服务）以对服务提供者的软件产品基于网络的访问为基础。此方法与通过安装机制的传统压缩打包软件交付形成对比。典型的服务提供者在大型的数据中心承载其软件，并使用 Internet 交付业务服务。尽管本文中的示例的重点是服务提供者为独立企业的具体案例，但服务提供者也可以为大型企业中的一个部门。

图 1 描述了一个 SaaS 示例。其中，Bank Account Opening 服务提供者承载 Account Opening 服务的实现，而服务的每个订阅者（承租者）都是银行，如 First Bank 和 Second Canadian Bank。而每个银行反过来将向其客户交付银行特定的 Account Opening 服务配置。

图 1. SaaS 示例

构建 SOA 组合业务服务，第 1 部分: 开发 SOA 组合应用程序来支持业务服务中给出了银行 SaaS 应用程序中角色的详细示例。第 1 部分将从服务提供者的公共共享承载环境支持多个业务服务订阅者（承租者）的能力称为多分租。

多分租支持是整个运行时堆栈中进行了全面考虑的设计理念。它要求对运行时环境拓扑、服务实现和用户界面的所有层次加以谨慎考虑。多承租者平台实现的选项涵盖诸多方面：从基于硬件的方面到虚拟化技术方面。在极端情况下，每个订阅者可能均由一组专用硬件和软件承载。此拓扑通过选择在承载环境中使用的实际硬件提供的多种选项为订阅者提供了最大的灵活性。例如，可以通过选择 CPU 来选择具体的性能。还可以基于服务器硬件选择可靠性级别。不过，此拓扑可能开销最大，因为这将迫使提供者为订阅者管理一系列专用服务器。提供者可以通过为很多客户共享硬件来实现成本节约。例如，提供者可以通过在数据库上安装多个数据库（每个客户一个数据库）减少成本。提供者还可以共享应用服务器的实例，以承载业务服务的多个实例。

从概念上来说，多承租者平台的选项范围可以大致归类为以下类别之一：

完全不共享
共享物理服务器
共享应用程序

务必认识到，即使在完全不共享的环境中，也能从定义良好的拓扑、公共硬件/软件产品定义和供参考的路线图获益。共享服务器类别相当广泛，包括以下选项：

仅共享支持基础设施（由 Tivoli® Provisioning Manager 之类的产品提供）
共享使用 Tivoli Access Manager 和 WebSeal 等产品实现的安全性功能
共享使用 DB2 等产品的数据库服务
共享中间件，如应用程序、流程和门户服务器

本文将讨论最后的共享应用程序：在此环境中，整个堆栈（包括硬件和软件）在整个用户群中实现重用；可以为各个订阅者配置软件（同时保留自定义选项）。

在本文下面的内容中，我们将了解如何实现对多分租的支持。接下来将重点讨论组合应用程序所需的三种核心服务类型，如图 2 中所示。

图 2. 组合应用程序服务

企业服务

本文的多承租者平台示例使用了以下产品来构建 CBS 基础设施：

WebSphere Portal
WebSphere Process Server
WebSphere Service Registry and Repository
DB2
Tivoli 产品，包括 Directory Server

图 3. 组合业务服务体系结构

尽管图 3 中所示的运行时环境支持进行表示和业务服务所需的功能，仍然需要服务提供者管理员进行一些工作来为订阅者实际公开和配置这些功能。具体来说，要将新订阅者（承租者）引入平台中，服务提供者管理员必须进行以下工作：

必须在 LDAP 目录服务器 (Tivoli Directory Server) 上创建专用领域。必须使用 WebSphere Portal 所预期的预定义结构目录对此领域进行配置。
必须向订阅者分配订阅者帐户 ID。此 ID 用于 WebSphere Portal 的虚拟门户功能，将成为提供订阅者的 Web 通道目的地的唯一 URL 的一部分。
必须为每个银行创建主题和皮肤，以定义订阅者的虚拟门户及各个 Portlet 的总体布局和外观。必须在运行多承租者平台的 WebSphere Portal 上安装这些主题和皮肤。

表示服务

多承租者承载平台的表示服务应该允许订阅者向其用户提供采用唯一品牌的专用身份验证入口点。平台必须确保订阅者和最终用户的安全性，而且同时要保证所有平台用户的信息安全。就这些注意事项而言，必须在多承租者的表示服务中提供以下功能：

通道目的地向订阅者的最终用户提供平台入口点。例如，对于 Web 通道，可以使用队列 URL 作为通道目的地；但对于 IVR 通道，则可以使用免费编号。
订阅者隔离确保各个订阅者的用户群无法访问平台的其他订阅者的业务服务和信息。例如，假定某个单一银行服务提供者 SaasBank 有两个银行服务订阅者：First Bank NA 和 Second Canadian Bank。在此示例中，当 First Bank NA 的客户通过网站登录时，必须针对 First Bank NA（而不是 Second Canadian Bank 或 SaasBank）的客户群进行身份验证。
品牌确保在最终用户访问通道目的地或通过通道的身份验证时，向最终用户提供特定于其订阅者的外观。例如，First Bank NA 客户登录后，用户界面必须特定于该银行，最终用户修改的外观配置（如布局或用户特定的皮肤）必须属于 First Bank NA。

到目前位置，本文的此部分的重点都是基础设施功能，忽略了多承租者设计对多承租者应用程序面向用户的部分的影响。在基于门户环境（如 WebSphere Portal）的上下文中，为多承租者应用程序创建的 Portlet 的设计和开发必须考虑下面所描述的这些注意事项。

由于订阅提供者跨各个订阅者提供共享 Portlet，因此每个 Portlet 必须对每个订阅者均是可配置的。为了实现高可重用性，Portlet 中的可配置性程度必须支持订阅者特定的设置，这包括从名称-值对配置（如订阅者 ID 或订阅者的服务端点）到订阅者特定的外观，并要提供指示哪些表单字段或操作按钮应该呈现给最终用户的设置。除了在订阅者级别支持可配置性外，各个订阅者还必须能够在没有服务提供者的支持的情况下进行配置。

为了处理上面所述的配置注意事项外，还可以采用克隆与配置 方法来处理多承租者应用程序的 Portlet 的实现与部署。WebSphere Portal 允许将各个 Portlet 部署到要克隆的服务器上。对于包含 Portlet 代码的每个 WAR 文件，可以创建具有不同配置选项的 Portlet 克隆或副本。为了支持不同订阅者的不同配置设置，服务提供者管理员将负责为每个订阅者克隆 Porlt 并分配 Portal 授权设置，从而使得每个订阅者只能访问自己的 Portlet 克隆。另外，服务提供者管理员还将向订阅者管理员分配额外的权限，以授权订阅者管理员配置相应的克隆 Portlet。

例如，在银行多承租者应用程序上下文中，假定某个 Portlet 处理 Funds Transfer 服务面向用户方面的内容。如果某个假想的 SaasBank 服务提供者希望向 Second Canadian Bank 公开 Funds Transfer Portlet，部署该 Portlet 的克隆与配置方法将涉及到以下步骤：

从管理控制台打开 WebSphere Portal Portlet Management 组。
使用 Manage Portlets 功能查找 Funds Transfer Portlet 并创建克隆副本。
从管理控制台使用 Resource Permissions 查找 Funds Transfer Portlet 的克隆。
将 Second Canadian Bank 的订阅者管理员添加为克隆 Funds Transfer Portlet 的管理员。

从 Second Canadian Bank 的订阅者管理员的角度而言，向银行提供了 Funds Transfer Portlet 后（已创建克隆 Portlet 并分配了相应的权限），订阅者管理员将执行以下步骤：

使用管理控制台 > Portlet Management > Manage Portlets 查找 Funds Transfer Portlet。
打开 Funds Transfer Portlet 的配置，并为 Second Canadian Bank 指定订阅者帐户 ID。
复查 Funds Transfer Portlet 的其他设置并根据需要进行修改，如服务端点等。

业务服务

如图 2 中所示，多承租者应用程序的业务服务必须设计为通过表示层接收和处理来自不同订阅者的请求。而且，业务服务的设计和实现必须允许服务进行重用，并能针对每个订阅者和用户进行自定义。

正如前面讨论的，多承租者平台的每个订阅者都使用唯一的平台级订阅者 ID 进行标识。在用户界面层，订阅者特定的 Portlet 配置负责维护该 ID 和保存与订阅者的最终用户关联的 ID。最终用户在表示层生成的服务请求在业务逻辑层进行处理，在其中会将 ID 作为业务服务的配置参数进行处理。

将订阅者 ID 从表示层传递到业务层，将从两个方面影响业务服务实现。首先，WSDL 接口的设计（特别是进入服务的数据的消息模式的设计）必须将订阅者 ID 作为参数之一。例如，在下面的代码片段中，订阅者 ID 实现为名为 bankID 的变量，属于示例贷款处理业务流程所用的 processLoan 消息。

清单 1. 最大宽度的示例代码列表

<!--

<wsdl:types>

<schemaelementFormDefault="qualified"

targetNamespace="http://process91958946.www.example.com"

xmlns="http://www.w3.org/2001/XMLSchema"

xmlns:impl="http://process91958946.www.example.com"

xmlns:intf="http://process91958946.www.example.com"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<elementname="processLoan">

<elementname="bankId"nillable="false"type="xsd:string"/>

<elementname="loanAmount"nillable="true"type="xsd:decimal"/>

<elementname="customerId"nillable="true"type="xsd:string"/>

<elementname="ssn"nillable="true"type="xsd:string"/>

</sequence>

</complexType>

</element>

<elementname="processLoanResponse">

</complexType>

</element>

</schema>

</wsdl:types>

其次，业务层的服务实现必须使用订阅者 ID 来向服务订阅者和各个最终用户提供可变性。使用 WebSphere Process Server (WPS) 构建的多承租者平台可提供一系列选项来向服务实现提供可变性。例如，使用 WebSphere Business Modeler 创建的业务流程可以通过参数指示可变点，这些参数可转换为适合在 WPS 上执行的业务流程执行语言（Business Process Execution Language，BPEL）业务规则。或者，还可以使用 WebSphere Integration Developer 直接在 BPEL 工作流中指定业务规则，而不用使用 WebSphere Business Modeler。例如，不同订阅者的贷款审批流程的同一个规则可以为贷款申请的预审批使用不同的信用记录，如 First Bank NA 的贷款申请的自动批准的信用记录要求高于 720，而 Second Canadian Bank 的自动批准要求高于 750。

结束语

本文说明了 CBS 支持多承租者的平台的主要体系结构概念。文中使用了银行应用程序示例对多承租者平台中的角色进行了解释，说明了多承租者应用程序的服务提供者、服务订阅者和最终用户间的关系。应用程序体系结构分解为几种主要服务类型：基础设施类型、表示类型和业务类型。本文讨论了基础设施服务的基础运行时体系结构、有关表示服务的问题、克隆与配置模式以及多承租者应用程序设计对业务服务实现的影响。

参考资料

学习