This chapter is from the book
This chapter is from the book
This chapter is from the book
Unity as a Pure UM Product
In its original form, Unity was too pure of a UM product. Its original implementation was with Exchange 5.5. It used the Exchange 5.5 directory to store all its data and save a few pieces, and it used the Exchange 5.5 information store to store all messages. It did not store any data other than messages in the Exchange 5.5 store. The data that it stored on the local server consisted of the system prompts and default greetings, the call routing, rules, and the system schedule. Unity was installed with Exchange 5.5 on-box and was installed either as a self-contained system (which meant that it also had to be a domain controller) or as a member server in an existing Windows NT domain.
Some fundamental problems arose with this approach. The whole notion of using the Exchange 5.5 directory to store the UM-specific data required for the system to operate and for e-mail–enabled end users to act as Unity subscribers was not effective: The LDAP-enabled Exchange 5.5 directory was not fast enough to provide the real-time searching capabilities that Unity needed, and it often became unresponsive (the DAPI access was not any better). It was also very problematic for administrators, who had to worry about the impact of adding a large amount of data into the directory, challenging its directory size. Finally, the Exchange 5.5 directory forced replication for the entire object each time an attribute belonging to that object was modified. This meant that Unity caused directory replication to increase anywhere from marginal levels to very high levels, depending upon the actual subscriber traffic on the system.
Unity's use of the Exchange 5.5 information store represented a complete dependency on the capability of Exchange 5.5 to maintain a stable and operational store for e-mail clients and Unity alike. This dependency caused problems because it subjected Unity to frequent interruptions as the information store became impaired or unavailable.
To make things worse, Unity used the directory poorly, without regard for the response time from the directory and the way it depended upon message retrieval delays from the message store by playing back what it experienced into the subscriber's or outside caller's ear. As a result, the subscriber or caller heard all delays that Unity was experiencing—sometimes the delays were so bad that the system simply was not serviceable.
The challenge was to find ways to eliminate the response time issues. The directory was tackled first, so a proprietary cache was created in Unity that would cache the directory data. This made Unity capable of accessing the cache quicker than it could access the directory, making it faster and less susceptible to the inherent delays in accessing the directory directly. The information store came next: Continuous modifications and improvements were made in Unity's use of MAPI to compensate for the constant timeouts and loss of access resulting from the frequently unavailable or impaired information store.
As Unity matured as a product, and as Microsoft released Exchange 2000, more work was done to enable Unity to maintain sustainable operations. Thus, its pure UM implementation evolved to make it more reliable and to relieve its dependencies on the message store if it became unresponsive. The Unity cache, internally called the Dohcache (see Chapter 3, "Components and Subsystems: Object Model") was eliminated and replaced by MS SQL Server 2000. Using SQL was fully justified when it was determined that Exchange 2000's directory, Active Directory, was no faster than the Exchange 5.5 directory for the type of real-time directory access that Unity required. Thus, the SQL server implementation within Unity made the product more stable and more readily capable of providing a consistent end-user experience.
A part of this SQL server effort also included the notion of taking the information store off the Unity server, thus eliminating Unity's dependency on an on-box message store that could get bogged down by its connectivity to the other servers it communicated with. Thus, the standard implementation of Unity came with an off-box message store. This was perfect and desirable for unified messaging.
As a replacement product for a legacy voice-messaging system, Unity comes with a separation of account/directory functionality and message store functionality. Figure 1-1 shows the difference between a legacy voice-messaging system and Unity. In the figure, the main difference is that a legacy voice-messaging system contains its own mail store and some type of address book or directory. With Unity, those components are found in the customer's environment. Unity uses either MS Exchange or Lotus Domino. For specific versions, see Part II, "Deployment."
)
Figure
1-1 A Legacy Voice-Messaging System Compared to a Unified Messaging
Solution
Unity Messaging Repository
The Unity Messaging Repository (UMR) was put in place because of the prevailing risk of losing access to the information store. The premise was that with the repository, voice messages would go into a holding place prior being delivered to the off-box Exchange server and stored there if the Exchange server or servers were offline. When a user's Exchange server is unavailable, the messages in the UMR are available to the user through the TUI, but not through the GUI interfaces. As soon as the messaging store comes back online, the messages are delivered and sent to the subscriber's mailbox. For more information, see Chapter 5, "Components and Subsystems: Messaging/Unity Message Repository."
Figure 1-2 shows Unity with the UMR in place. If it loses access to the messaging system that it services, it will continue to take messages from outside callers.
)
Figure
1-2 The Unity Messaging Repository
Comparison of Unified and Integrated Messaging
So, why stick with unified messaging if all these problems occur with the directory and the information store? Two very important reasons exist. First, you have just as many—although different—problems with integrated messaging.
With integrated messaging, you have the following:
Separate directories
Separate message stores
Client connection to both e-mail and voice mail (VM) systems
Required VM address book when composing VM for an e-mail client
No shared distribution lists
With unified messaging, you have the following:
Same directory
Same message store
Client connected to the e-mail system only, but it can connect to Unity to use the Telephone Record and Playback (TRaP) feature for recording and playing back messages
E-mail address book available when composing a voice messages for an e-mail client
Shared distribution lists
Figure 1-3 shows the difference between unified messaging and integrated messaging. With unified messaging, the unified messaging server provides services to subscribers by becoming a part of the messaging environment where the subscribers reside. With integrated messaging, the integrated messaging servers become a second messaging infrastructure on top of the existing messaging infrastructure. The client then must connect to both messaging infrastructures to experience "unified" messaging.
)
Figure
1-3 Unified Messaging Versus Integrated Messaging
With integrated messaging, the focus moves off the messaging store onto the client, to unify the different types of messages. As a result, integrated messaging systems typically have a challenge in providing reliable notification services, such as lighting message waiting indicators, on a timely basis.