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

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

Amber Roy-Chowdhury, 高级软件工程师, IBM Pittsburgh Lab

Amber Roy-Chowdhury 是 IBM 的一位高级软件工程师,在北卡罗莱纳的 Research Triangle Park 工作。他致力于 WebSphere Portal 体系结构与开发方面的工作。他目前担任 WebSphere Portal 的代理通信框架(称为 Property Broker)的架构师兼技术负责人。此前 Amber 曾担任过 WebSphere Application Server 和 Encina Transaction Processing Monitor 产品的首席开发人员。Amber 拥有伊利诺伊大学香槟分校的博士学位。



Germán Goldszmidt (gsg@us.ibm.com), 杰出工程师, EMC

author photoGerman Goldszmidt 博士是 IBM 软件部的一位杰出工程师,其研究重点是用于交付、自定义和部署 SOA 组合应用程序来支持业务服务的集成平台的体系结构。之前他曾在 IBM T.J. Watson Research Center 担任研究人员,并曾带领团队进行多种技术的设计和实现工作,包括 Océano(自主计算 eUtility 的第一个原型)和 Network Dispatcher(WebSphere 产品的负载平衡组件)。



Carl Osipov (osipov@us.ibm.com), 软件工程师, EMC

Carl Osipov 是 IBM Software Group 的 On Demand Incubation and Development Organization 的软件工程师。他所擅长的领域是分布式计算和面向服务的体系结构,以及语音应用程序开发和计算自然语言理解。他在本行业以及大众媒体上发表了一些 SOA 和沟通对话管理主题方面的文章,并举行过这方面的讲座。您可以通过 osipov@us.ibm.com 与 Carl 联系。



2007 年 9 月 06 日

引言

本系列之前的文章介绍了组合业务服务 (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 示例
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 的克隆与配置方法将涉及到以下步骤:

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

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

  1. 使用管理控制台 > Portlet Management > Manage Portlets 查找 Funds Transfer Portlet。
  2. 打开 Funds Transfer Portlet 的配置,并为 Second Canadian Bank 指定订阅者帐户 ID。
  3. 复查 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" 
	  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">
   <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 Execution Language,BPEL)业务规则。或者,还可以使用 WebSphere Integration Developer 直接在 BPEL 工作流中指定业务规则,而不用使用 WebSphere Business Modeler。例如,不同订阅者的贷款审批流程的同一个规则可以为贷款申请的预审批使用不同的信用记录,如 First Bank NA 的贷款申请的自动批准的信用记录要求高于 720,而 Second Canadian Bank 的自动批准要求高于 750。

结束语

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

参考资料

学习

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=253451
ArticleTitle=构建 SOA 组合业务服务,第 7 部分: 为组合业务服务提供多分租支持
publish-date=09062007