用户经过身份验证，并且知道了他们所属的 TenantID

步骤 3. 配置数据库连接

Corent 多租户服务器构建在面向服务的架构之上，使用了一个 MetaModel 数据库（如 步骤 1 所述）。该 MetaModel 被用作一个抽象层，建模应用程序的原始数据库，而应用程序的数据库通信被重定向到 MetaModel 抽象而不是实际的数据库实现。方法就是重新配置 jBilling 的 JDBC 连接以访问 MetaModel 数据库而不是实际的 MySQL 数据库。对于使用 Hibernate 的应用程序，配置 Hibernate 的 Corent 方言（dialect）。

在作出这些修改后，应用程序数据库调用现在被指向到 MetaModel 数据库。这些 SQL 事件被 Corent Agile Controller™ 截获并被传递给 Corent 的 ADBC™（敏捷数据库连接器，Agile DataBase Connector）。ADBC 获得应用程序提交给 MetaModel 数据库的 SQL 语句并进行解析，然后为在会话中提交了 SQL 的用户的 TenantID 添加过滤条件（例如，TenantID = <myTenantID>

由于对 SQL 语句的处理是在将它们提交给 MetaModel 数据库后完成的，并且用户所属的租户已知，Corent Agile Controller 将截获并执行更加复杂的操作，包括查找特定于租户的流程和配置。因此，可以针对每个租户执行一些具体的操作，甚至是替换不同的数据库连接，从而使某个租户可以使用 DB2 数据库，即使所有其他租户使用一个 MySQL 数据库。或者，某个租户可以进行额外的 SQL 操作，将它们可以检索的数据限制为最近 90 天以内输入的记录。所有这些基于每个租户作出的自定义都可以通过多租户服务器内置的 Agile Rules Engine™ 实现，不需要对原始的应用程序代码做任何修改。

完成 jBilling 应用程序的全部转换只需要对应用程序做一些细微的修改，增强身份验证的最主要问题是在会话信息中包括租户信息，以及修改数据库连接以指向多租户服务器。您可以看到对 jBilling 的修改总结为以下几条：

• 原始应用程序
  • 源文件数：897（Java 和 jsp）
  • 总的代码行数：76,621
• 转换后的应用程序
  • 增加的源文件的数量：2（标准模板）
  • 修改的代码的行数：少于 100
  • 应用程序业务逻辑修改：0

包括所有分析和准备工作（判断哪些位置需要修改代码）在内，对 jBilling 的转换只用了不到一周的时间。许多修改就是在用于 JDBC 访问的 Java 代码片段中重复修改某个行，如果使用的是 Hibernate 之类的数据库持久层，那么这些修改都是可以省去的。

步骤 4. 将新的多租户 SaaS 应用程序部署到云中

现在，可以使用 SaaS-Factory 将 SaaS 应用程序部署到一个指定的服务器中，包括云中的服务器。

为应用程序和数据库选择了一个服务器后，将生成目标数据库（例如，对于我们的 jBilling 应用程序，就是在 Windows® 服务器上使用 MySQL 数据库），并将进行充分配置的多租户服务器应用程序以一组 .WAR 文件的形式部署到所选的应用服务器。多租户服务器可以使用任何现代的 J2EE Servlet 容器，而且还针对 WebSphere 应用服务器进行了认证。

部署后的应用程序现在已经能够处理多个租户。然而，原始应用程序现在缺少一个治理或管理界面来管理租户或监视多租户应用程序。

SaaS-Factory 还可以生成并安装一个称为 SaaS-Cockpit™ 的配套应用程序，该应用程序提供了这些基础的多租户服务。它可以像主应用程序那样访问 MetaModel 数据库并具有一个管理屏幕，用于指配租户、分配 Tenant Administrator 帐户和为各种可用的基于每租户的应用程序配置设置基本参数。还提供了一些管理工具，用于监视租户及其用户并进行报告。由于 SaaS 应用程序的典型特征之一就是需要跟踪租户订阅和记账，因此将出现一些用于记账的工具或与外部记账系统的集成。

就 SaaS 应用程序部署而言，这种程度的部署是相当基础的。应用程序的特征在转换后仍然保持不变，标准的部署场景，包括使用云管理工具创建模板和传播应用程序实例，可以用于部署满足应用程序对可扩展性、灵活性、弹性和冗余性的要求的运行架构。

一个典型的 SaaS 应用程序可能会允许通过一个负载均衡器访问一组应用服务器并连接到数据库服务器。数据库服务器本身可以作为一个集群部署，同时使用多个数据库服务器提供冗余和可扩展性。

IBM DB2 提供了一些技术和配置，可用于实现弹性和有保障的恢复时间，以及允许对数据库上的负载进行分配：

• 通过使用备用模式（secondary mode）作为只读数据库，DB2 HADR（高可用性灾难恢复）配置可以同时提供具有弹性的可用性和一些负载均衡。
• IBM pureScale 技术和 Tivoli System Automation (TSA) 支持集群化的数据库环境，该环境中的多个节点共享处理负载，但是对硬件和操作系统配置的限制较多。

对于 SaaS 应用程序，数据库可用性和故障转移正变得越来越复杂，因为与传统的客户端软件（图 5）相比，任何一次宕机对客户/租户产生的影响的范围都会更大。