多分租（multi-tenancy）是指从共享的公共承载环境中为多个组织（客户）提供服务的能力。本文将说明多分租的概念，并将介绍软件作为服务的网络交付方法。

　　引言

　　本系列之前的文章介绍了组合业务服务(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>
　　    <schema elementFormDefault=”qualified”
　　   targetNamespace=”http://process91958946.www.example.com”
  
  
  
  
   >
　　   <element name=”processLoan”>
　　    <complexType>
　　     <sequence>
　　      <element name=”bankId” nillable=”false” type=”xsd:string”/>
　　      <element name=”loanAmount” nillable=”true” type=”xsd:decimal”/>
　　      <element name=”customerId” nillable=”true” type=”xsd:string”/>
　　      <element name=”ssn” nillable=”true” type=”xsd:string”/>
　　     </sequence>
　　    </complexType>
　　   </element>
　　   <element name=”processLoanResponse”>
　　    <complexType>
　　     <sequence/>
　　    </complexType>
　　   </element>
　　  </schema>
　　 </wsdl:types>

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

　　结束语

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

　　作者简介

　　Amber Roy-Chowdhury是IBM的一位高级软件工程师，在北卡罗莱纳的Research Triangle Park工作。他致力于WebSphere Portal体系结构与开发方面的工作。他目前担任WebSphere Portal的代理通信框架（称为Property Broker）的架构师兼技术负责人。此前Amber曾担任过WebSphere Application Server和Encina Transaction Processing Monitor产品的首席开发人员。Amber拥有伊利诺伊大学香槟分校的博士学位。
 
　　German Goldszmidt博士是IBM软件部的一位杰出工程师，其研究重点是用于交付、自定义和部署SOA组合应用程序来支持业务服务的集成平台的体系结构。之前他曾在IBM T.J. Watson Research Center担任研究人员，并曾带领团队进行多种技术的设计和实现工作，包括Océano（自主计算eUtility的第一个原型）和Network Dispatcher（WebSphere产品的负载平衡组件）。
 
　　Carl Osipov是IBM Software Group的On Demand Incubation and Development Organization的软件工程师。他所擅长的领域是分布式计算和面向服务的体系结构，以及语音应用程序开发和计算自然语言理解。他在本行业以及大众媒体上发表了一些SOA和沟通对话管理主题方面的文章，并举行过这方面的讲座。您可以通过osipov@us.ibm.com与Carl联系。