About Unified Messaging - Unity as a Pure UM Product (Page 2 of 11 )
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
 This chapter is from Cisco Unity Deployment and Solutions Guide by Todd Stone (Addison-Wesley, 2004, ISBN: 1587051184). Check it out at your favorite bookstore today. Buy this book now.
|
Next: Comparison of Unified and Integrated Messaging >>
More Administration Articles
More By Addison-Wesley Prentice Hall PTR
/ 3 
