Lotus Notes/Domino 7 中的 Rooms and Resources 设计

Lotus Domino 4.5 中引入了 Rooms and Resources (R&R) 功能，以及 Calendaring and Scheduling (C&S) 功能。R&R 系统旨在成为一种集成的方式，用于用户为会议、事件或任何种类的活动预订房间或资源。当设置一场会议时，您可以要求想要的会议室和/或资源，其他用户也跟您一样可以这样要求，不管是从 C&S 界面，还是从 R&R 数据库。与 C&S 是每个用户的邮件文件的一部分所不同的是，R&R 请求是通过使用一个共享数据库来处理的，每个房间或资源都保存在该数据库中。

Notes/Domino 7 为 R&R 系统带来了重大的增强。本文将解释这些增强。我们首先来稍加了解 Notes and Domino 中 R&R 的历史。然后再来看 Notes/Domino 7 中特定的新 R&R 特性，包括界面改进和“可集群性 (clusterability)”。本文假设您熟悉基本的 Notes and Domino 特性。

Rooms and Resources 简史

在 Notes/Domino 4.x 中，R&R 使用一组代理，并依赖于 Agent Manager 来处理预订请求、更新和取消（本文后面我们将把这些行为统称为“预订请求”）。尽管这提供了所需的 R&R 功能，但是还有性能改善的空间，因为处理预订请求过程中还涉及到一些固有的延迟。

对于 Domino 5.x 和 6.x，我们升级了 R&R 系统，以使用模板脚本和/或后端处理代码来处理预定请求。这里仍然涉及到一个代理，但是它的主要目的只是清理“过去的事件”，所以时间性并不那么重要。这个修订的系统相对于 R4.x 设计是一个改进，主要因为它执行得更快了。此外，它也共享用于在用户之间自动处理消息发送的 C&S 自动处理特性。该代码重用意味着用户期望更加一致的行为。

尽管新的 R&R 系统比原来的更加具有响应性，但是它仍然具有一些外部依赖，比如允许重复预订房间或资源。自动处理是由服务器端代码执行的，或者是在数据库中执行，但是两者都依赖于忙碌时间 (busytime) 数据的准确性，才能最佳地发挥作用。假定该忙碌时间信息由 Schedule Manager (SchedMgr) 以异步的方式更新，那么就会存在小窗口的机会，允许来自 C&S 或 R&R 数据库有冲突的预订请求或者预订单个房间。这个窗口很小（最多几秒钟），要遇到这个窗口，冲突的预订请求需要在该窗口中被创建并交付到 R&R 数据库。实际上，我们一般碰不到这种情况，除非在某些环境中，有大量的用户争用很少的会议室。200 个用户相对于数千个用户来说，潜在会议室调度冲突的数量就会少得多。

如果我们允许 R&R 数据库在多个服务器上具有副本 (replica)，那么遇到重复（或多次重复）预订窗口的机会实际上会大很多。这是因为，如果房间或资源没有在忙碌时间系统（busytime system）中显示为“busy”，那么任何在 R&R 数据库中直接创建的预订请求都被自动接受。因此，由于在将已接受的预订请求保存为另一个副本和将它复制回 R&R 数据库的主机服务器以便它被置于忙碌状态之间存在延迟，那么遇到重复预订窗口的机会也变得大了很多。这个增加的潜在风险是我们在 Domino 5.x 和 6.x 中决定不允许使用 R&R 数据库副本的关键。

图 1 是 Domino 5.x/6.x R&R 设计的高级图表；请求处理逻辑存在于 Notes 客户机和路由器中：

图 1. Domino 5.x/6.x 的 R&R 系统

回页首

Domino 7：Rooms and Resources 的一个新模型

对于 Domino 7，我们想要解决客户建议的关于 R&R 系统可用性和可靠性的问题。为此，我们重新设计了 R&R 系统，主要目的是关闭重复预订的窗口。这是主要的标准，所有设计决策都根据这个标准进行了评估。如果提议的特性或增强允许重复预订，那么它就不被接受。我们的次要标准是以这样一种方式重新设计系统，即我们应该允许 R&R 数据库在多个服务器上的副本。我们将这一标准更进了一步，并通过向预订请求处理过程增加了集群故障转移而实际支持“可集群性”。

此外，我们提供了一组新的与 R&R 相关的特性，任何 Notes 客户机都可以使用这些特性。为了充分利用新 R&R 系统的优势，您所要做的就是将服务器和 R&R 数据库升级到 Domino 7。您的用户愿意的话还可以使用其当前版本的 Notes 客户机，并且仍然可以利用新设计的所有优势。新 R&R 系统被设计为独立于 Notes 客户机版本，尽管对于其他客户机活动，但最好还是保留 Domino 服务器版本的两个 Notes 版本。

R&R 的新设计涉及到集中所有的预订请求处理，以及它要正确工作所依赖的任何事物。为此，我们创建了一个新的 Domino 任务，即 Rooms and Resource Manager (RnRMgr)。图 2 是 Domino 7 R&R 设计的高级图表：

图 2. Domino 7 的 R&R 系统

除了将所有的请求处理逻辑/权限集中到 RnRMgr 中之外，我们还更新了 SchedMgr 和 Router 任务。SchedMgr 不再试图更新房间或资源的忙碌时间；它现在独自为用户更新忙碌时间。Router 也一样，只有对 C&S 用户的请求还是积极自动处理的；它使用的自动处理例程不再处理任何去往 R&R 的请求。

RnRMgr 任务的工作是关注 R&R 数据库中的预订请求，并以它们到达或创建的顺序处理它们。作为这一处理过程的一部分，RnRMgr 将查询并更新忙碌时间到尽可能接近当前的时间，以便即使交付了冲突请求也不会导致重复预订。因为关于接受或者拒绝一个预订请求的决定是在单个地方（而不是多个地方）做出的，所以不可能接受冲突请求并导致重复预订房间或资源。

为了集中所有的请求处理逻辑，我们调整了 R&R 模板，并删除了所有会接受请求的逻辑。我们仍然保留了最初的一些逻辑，以便 R&R 数据库可以执行已分类的检查，比如可能会被 RnRMgr 拒绝的所有者权限检查和被禁止的请求。它仍然进行忙碌时间检查，不允许用户为已经预订的日期和时间保存一个请求。（如果只是因为数据库允许您请求，就不断地为一个已经预订的房间保存新的预订请求，那没有比这更令人沮丧的了！）

回页首

R&R 数据库特性增强

在 Notes/Domino 7 中，R&R 数据库仍然执行它在以前版本中所做的大部分工作，但是有了一些微小的变化。在以前版本中，您应该假设，如果您可以保存预订请求，那么预订就被接受，房间就是您的了。由于关于预订请求的最后决策现在是由 RnRMgr 来处理，所以现在您的期望应该是这样的，即如果您可以保存预订请求，那么您的请求就有可能被接受。但是，有可能有人在您前面预订了，因此您的请求可能被拒绝。行为上的这一小小变化是必要的，可以确保系统的完整性，从而增加用户满意度。

Notes/Domino 7 中 R&R 用户界面的最大变化是，增加了新的预订请求状态指示器图标。这些图标的目的是可视化地指示任何预订请求的状态。这些新的指示器是：

• 一个沙漏，指示一个未处理的预订请求。
• 一个绿色的校验标记，指示一个已接受的预订请求。
• 一个红色的 X，指示一个被拒绝的预订请求。

视图中显示的每个预订上面都会有这三个状态指示器之一，如图 3 所示：

图 3. 预订状态指示器

一般来说，除非 RnRMgr 不在运行，否则您很少会看到沙漏图标（即使看到，也最多只会出现几秒钟）。在图 3 显示的 By Resource 视图中，您可以看到，用户具有两个已接受的预订、一个已拒绝的预订（因为它与另一个冲突）和一个未决的预订请求。R&R 数据库不允许您创建它知道会被拒绝（因为另一个预订已被接受了）的预订请求，所以您应该不会看到很多红色 X 图标。您确实会看到一些红色 X 图标，那通常是同步创建或交付冲突请求的结果。

Notes/Domino 7 中 R&R 模板也新增了几个特性，使得 R&R 对 Notes 用户来说更加高效和有用。这些新特性包括：

• “快速”预订。
• 限制未来多久才能创建预订。
• 将预订转移给另一个用户。
• 在常规基础上向预订所有者发送自动提醒。

我们计划在下一篇文章中更加详细地讨论这些特性，以及所有其他新的 Notes/Domino 7 R&R 特性。

回页首

可集群性

到目前为止，我们了解了新的设计，以及它如何防止 R&R 的重复预订 —— Notes/Domino 7 的主要目标。我们还提到了一个次要目标：增加 R&R 系统的可用性。尽管 Domino 服务器的正常运行时间很优秀，但是还存在扩展的服务器停机时间（计划内的和计划外的），这会导致用户受挫或烦恼。要解决这个问题，我们将 RnRMgr 设计成能够利用 Domino 集群的优势。因此，不再是限制为单个 R&R 副本，现在有可能具有 R&R 数据库的多个副本，如图 4 所示：

图 4. R&R 数据库的多个副本

除了允许 R&R 数据库的重复副本之外，我们还将 RnRMgr 设计成积极地使用 Domino 集群来执行 R&R 请求处理的应用程序故障转移。这意味着，如果一个运行 RnRMgr 的服务器在一段时间内变得不可用，那么其集群中的 RnRMgr 将试图接管控制，并为在这些服务器之间共享的所有 R&R 数据库处理未决的 R&R 预订请求。

对于 Notes/Domino 7，我们为 R&R 数据库增加了“主”服务器的概念。主服务器是请求处理通常发生的地方。它与 Domino Directory 空间中的 home 服务器相同，并且它也是 C&S 请求通常被路由和交付到的地方。所有其他具有副本的服务器都是“次”服务器。尽管次服务器上也运行有 RnRMgr，但是它并不处理 R&R 数据库中的任何请求。相反，它只是关注主服务器。当主服务器变得无响应的时间长到足以被认为是“脱机”时，次服务器将为主服务器上的任何 R&R 数据库处理任何未处理的预订请求。这意味着次服务器成了“代理主”服务器。主服务器重新启动时，它会在试图开始工作之前检查它的 R&R 数据库的故障转移状态。如果有一个代理主服务器，那么主服务器将不会对数据库做任何事情。如果该数据库没有代理主服务器，那么主服务器将会开始像往常一样处理预订请求。

有了这种新的可集群设计，现在用户可以在次服务器上创建重复的预订请求；该请求将以相同的信任被处理，就像它是在主服务器上创建的或者是由 C&S 创建的一样。请求通常会被集群复制 (cluster-replicate) 到主服务器，RnRMgr 会在这里处理该请求，然后结果会被集群复制回次服务器。有了应用程序故障转移，任何未处理的请求（来自任何来源）将在代理主服务器上被处理。因此，用户创建的请求只在本地处理，并且只比以前稍早一点看到结果。

如果代理主服务器发生故障，会再次出现这种应用程序故障转移。当故障转移发生时，一个次服务器将被选择作为新的代理主服务器，请求处理像前面一样继续进行。对于 Notes/Domino 7，我们在集群环境中给予主服务器优先权，所以当故障转移后主服务器重启时，代理主服务器（次服务器）将继续处理预订请求，直到代理主服务器变为无响应。当代理主服务器变为无响应时，控制将返回给主服务器，而不是另一个次服务器。

回页首

结束语

Notes/Domino 中的 Rooms and Resources 有了集群故障转移能力以确保高可用性，因而从单个副本、多方决策设计转变成了高度专注、集中的决策设计。在没有改变 C&S 系统、只很小地改变了整体用户体验的情况下，我们重新设计了 R&R 系统，以在 R&R 方面提供更好的用户满意度，并利用 Domino 集群的潜在能力而不是畏惧它们。除了重新设计之外，R&R 数据库中的新特性也会为每个用户带来满意。