Lotus Domino 4.5 saw the introduction of Rooms and Resources (R&R) functionality, along with Calendaring and Scheduling (C&S). The R&R system is intended to be an integrated way for users to reserve rooms or resources for meetings, events, or any sort of activity. When setting up a meeting, you can invite a desired meeting room and/or resource, as you would other users, either from within the C&S interface or from an R&R database. Unlike C&S, which is part of each user's mail file, R&R requests were handled by using a shared database in which each room or resource resides.
Notes/Domino 7 brings significant enhancements to the R&R system. This article explains these enhancements. We begin with a quick look at the history of R&R in Notes and Domino. We then look at specific new R&R features in Notes/Domino 7, including interface improvements and "clusterability." This article assumes you're familiar with basic Notes and Domino features.
A brief history of Rooms and Resources
In Notes/Domino 4.x, R&R used a set of agents and relied on the Agent Manager to handle reservation requests, updates, and cancellations (which we will collectively refer to as "reservation requests" for the remainder of this article). Although this provided the required R&R functionality, it left some room for performance improvements, due to inherent delays involved in processing reservation requests.
For Domino 5.x and 6.x, we upgraded the R&R system to use template scripts and/or backend processing code to handle the processing of reservation requests. There was still one agent involved, but its sole purpose was to just do "past event" purging, so timeliness was not that important. This revised system was an improvement over the R4.x design, primarily because it performed faster. In addition, it also shared the C&S autoprocessing feature used to autoprocess messages sent between users. This code reuse meant that users could expect more consistent behavior.
While the newer R&R system was more responsive than the original one, it still had some external dependencies that in some instances could allow rooms or resources to be double-booked. Autoprocessing was performed by server-side code or in the database, but both relied on the accuracy of busytime data to function optimally. Given that busytime information is updated in an asynchronous manner by the Schedule Manager (SchedMgr), there were small windows of opportunities that could allow a single room to be reserved by conflicting reservation requests from either C&S or via the R&R database. This window was tiny (a few seconds at most), and for it to be encountered, conflicting reservation requests needed to be created or delivered to the R&R database within that window. In practice, we did not find this occurring with any real frequency except in environments that had a large number of users contending for a very small pool of conference rooms. The number of potential conference room scheduling conflicts is much smaller with a pool of 200 users than it is with a population of thousands of users.
This window for double (or more) booking would actually be much larger if we permitted R&R databases to have replicas on multiple servers. The reason for this is that any reservation requests created directly in the R&R database was automatically accepted if the room or resource did not already appear as "busy" in the busytime system. As a result, the window for double booking becomes much larger due to the latency between saving the accepted reservation into a second replica and having it replicate back to the R&R database's home server so it can be put into busytime. This increased potential risk was key to our decision to disallow replicas of R&R databases in Domino 5.x and 6.x.
Figure 1 is a high-level diagram of the Domino 5.x/6.x R&R design; request processing logic existed in the Notes client and router:
Figure 1. R&R system for Domino 5.x/6.x
Domino 7: A new model for Rooms and Resources
For Domino 7, we wanted to address customer comments regarding the usability and reliability of the R&R system. To this end, we redesigned the R&R system with a primary goal of closing the window for double bookings. This was the principal criterion by which all design decisions were evaluated. If a proposed feature or enhancement permitted double bookings, it was disallowed. Our secondary criterion was to redesign the system in such a way that we could allow for replicas of an R&R database on multiple servers. We took this criterion a step farther and actively embraced "clusterablity" by adding cluster failover to the processing of reservation requests.
In addition, we provided a set of new R&R-related features that any Notes client can use. To enjoy the benefits of the new R&R system, all you have to do is upgrade your server and R&R database to Domino 7. Your users can still use their current version of the Notes client they want, and still get all the benefits of the new design. The new R&R system is designed to be independent of the Notes client version, although for other client activity, it is good practice to stay within two Notes releases of the Domino server release.
The new design for R&R involves centralizing all the reservation request processing and anything it actively depends on for proper function. To this end, we created a new Domino task, the Rooms and Resource Manager (RnRMgr). Figure 2 is a high-level diagram of the Domino 7 R&R design:
Figure 2. R&R system for Domino 7
In addition to centralizing all request processing logic/authority into RnRMgr, we updated the SchedMgr and Router tasks. SchedMgr no longer tries to update busytime for a room or resource; it now updates busytime solely for users. As for the Router, only requests to C&S users are still actively autoprocessed; the autoprocessing routines it uses no longer process any R&R-destined requests.
The job of the RnRMgr task is to watch for reservation requests in an R&R database and to process them in the order in which they arrive or were created. As part of this processing, RnRMgr will both query and update busytime to be as current as possible, so that even the delivery of back-to-back conflicting requests will not cause a double booking to occur. Since the decision to accept or decline a reservation request is performed in a single place (rather than in multiple places), there is no possibility of conflicting requests being accepted and thus double booking a room or resource.
To centralize all the request processing logic, we trimmed the R&R template and removed all logic that would accept a request. We still preserved some of the original logic so that the R&R database can perform assorted checks, such as owner restrictions checking and disallowing requests that would be rejected by RnRMgr. It also still does busytime checks, so that a user is not allowed to save a request for an already-reserved date and time. (Nothing would be more frustrating than to have to repeatedly save new reservation requests for an already-reserved room just because the database lets you request it anyway!)
R&R database feature enhancements
In Notes/Domino 7, the R&R database performs much of what it did in previous releases, but with a subtle change. In earlier releases, you could assume that if you could save your reservation request, the reservation was accepted and the room was yours. Because the final decision on a reservation request is now handled by RnRMgr, your expectations should now be that if you can save the reservation request, you are likely to get your request accepted. However, there could be someone "in line" ahead of you, and then you might not get the request. This minor change to the behavior is necessary to ensure the integrity of the system and to increase user confidence.
The most noticeable change to the R&R user interface in Notes/Domino 7 is the addition of new reservation request status indicator icons. The purpose of these icons is to visibly indicate the status of any reservation request. These new indicators are:
- An hourglass to indicate an unprocessed reservation request.
- A green checkmark to indicate an accepted reservation request.
- A red X to indicate a declined reservation request.
Each reservation displayed in the views will have one of these three status indicators on it, as shown in figure 3:
Figure 3. Reservation status indicators
Typically, unless RnRMgr is not running, you will rarely see the hourglass icon (and if you do, it only appears for a few seconds at most). In the By Resource view shown in figure 3, you can see that the user has two accepted reservations, one declined reservation (because it conflicted with another), and one pending reservation request. The R&R database will not let you create a reservation request that it knows will be declined because another reservation was already accepted, so you should not see many red X icons either. Those that you do see typically are the result of conflicting requests being created or delivered simultaneously.
There are also several new features added to the R&R template in Notes/Domino 7 to make R&R more productive and useful for Notes users.These include:
- "quick" reservations
- limiting how far in the future reservations can be created
- transferring a reservation to another user
- sending autoreminders to reservation owners on a regular basis
We plan to discuss these and all other new Notes/Domino 7 R&R features in more detail in an upcoming article.
So far we have looked at the new design and how it prevents double bookings of R&R -- our primary goal for Notes/Domino 7. We also mentioned a secondary goal: to increase availability of the R&R system. Although Domino server uptime is excellent, there can be extended server down time (scheduled and unexpected) that can cause user frustration or annoyance. To address this, we designed RnRMgr to be able to take advantage of Domino clusters. So instead of being restricted to single replica R&R, it is now possible to have multiple replicas of an R&R database, as seen in figure 4:
Figure 4. Multiple replicas of an R&R database
In addition to allowing replica copies of the R&R database, we've designed RnRMgr to actively use Domino clusters to perform application failover of R&R request processing. This means that if one server where RnRMgr is running becomes unavailable for a period of time, RnRMgr on its cluster mates will attempt to take control and process pending R&R reservation requests for all R&R databases that are shared between those servers.
For Notes/Domino 7, we have added the concept of a "primary" server for an R&R database. The primary server is where request processing normally happens. It is the same as the home server for the room in the Domino Directory, and it is where C&S requests are normally routed to and delivered. All other servers that have a replica are "secondary" servers. While there is an RnRMgr running on the secondary server, it does not process any requests in the R&R database. Instead, it simply keeps an eye on the primary server. When the primary becomes unresponsive long enough to be considered "offline," the secondary server will begin to process any unprocessed reservation requests for any R&R databases that were on the primary server. This means the secondary server has become an "acting primary" server. When the primary server restarts, it will check the failover status of its R&R databases before it tries to begin work. If there is an acting primary server, then the primary server will do nothing with that database. If there is no acting primary server for that database, then the primary server will begin processing reservation requests as it normally does.
With this new clusterable design, it is now OK for users to create reservation requests in replicas on a secondary server; it will be processed with the same confidence as if it were created on the primary server or via C&S. The request normally would cluster-replicate to the primary server where the RnRMgr there would process it, and the results would cluster-replicate back to the secondary server. With application failover, any unprocessed requests (from any source) will be processed on the acting primary server. For that case, the request created by the user would simply be processed locally, and the results seen just a little sooner than before.
This application failover can occur again if the acting primary fails. When failover happens, a secondary server will be chosen as the new acting primary, and request processing continues as before. For Notes/Domino 7, we have given the primary server priority in a clustered environment, so when the primary server restarts after failover has occurred once, the acting primary server (the secondary server) will continue to process reservation requests, until the acting primary server becomes unresponsive. When it does, control will fail back to the primary server instead of to another secondary server.
Rooms and Resources in Notes/Domino has gone from being a single replica, multi-party decision-making design to a highly focused, centralized decision-making design with cluster failover abilities to ensure high availability. With no change to the C&S system, and minimal changes to the overall user experience, we have redesigned the R&R system to provide greater user confidence in R&R and to embrace the potential of Domino clusters rather than fear them. In addition to the redesign, the new features in the R&R database should bring a big smile to every user's face.
- For more information about all the features in Lotus Notes 7.0, see the developerWorks: Lotus article, "New features in Lotus Notes and Domino Designer 7.0."
- And for more information about new features in Lotus Domino 7.0, see the article, "New features in Lotus Domino 7.0."
- See the Lotus Notes/Domino product page for more information about the Lotus Notes and Domino products.
- Get involved in the developerWorks community by participating in
developerWorks blogs.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
