Mature Unified Messaging Will Use Open Standards.
This article is the last in a three-part series. The second part ran in the June issue of CTR.
There is more than one way to build a unified-messaging system. Each service provider's most advantageous approach will depend in part on its starting point. The major issue is whether you have existing servers you're using to provide single-medium messaging. If so, you probably need to continue using them for at least a time to recoup your investment. That simply means that you'll migrate from your current services into unified messaging, distributing the processing load among interconnected servers. A new service provider entering the messaging market for the first time might go straight to a single centralized server to support collection of all media and delivery to the recipient customers. The ideal architecture of either kind is flexible; so that either specialized or centralized servers become modules on which to build.
The argument has been made that a central server may be less reliable than multiple servers, bringing the whole service down with a single failure and providing less flexibility for handling peak usage volumes. This is really a concern only if the centralized server is one form of messaging and is now being a called on to surpass its limits for processing or number of ports. There's nothing to keep unified messaging from being deployed on fault-tolerant, high-availability, even redundant servers. If one means of access goes down such as a LAN, for example, other means such as the telephone interface will remain available.
A unified server certainly simplifies other processes, including the directory- which yields ongoing benefits in more accurate data and in easier and less-costly maintenance. The directory also facilitates effective integration with existing operations systems or those that support other services, such as service management, billing, and network management. That kind of integration is vital to realizing economies of scale and other administrative cost efficiencies. Billing integration can be especially important if you want to bill for unified messaging on the basis of usage. Once you have such a system, recording transactions and tracking user navigation, you can also use it to fine-tune the unified-messaging application and even for targeted marketing of certain features.
The greatest flexibility, no, matter how many servers you use, comes with an architecture based on network objects. Bellcore's own Unified Messaging Services Platform, for instance, has each call (or user interaction) "terminate" in as software Telecom Object. This call controller manages the signaling interface to the network and the variety of media that may need to be recognized to handle the callet's choice of aces mechanism, including DTMF (Touch Tone) signals, speech recognition, and fax modems. The Telecom Object finishes its object by binding the call with an "application object" that gathers the customer's preferences from a profile and invokes the appropriate applications to provide the specific service features that customer has ordered. It also monitors the applications for proper functioning.
The vital difference that makes unified messaging possible is of course the a matter of digitalization. It's what makes voice and email and fax all look the same, at least to the system. It's that homogeneity that lets you put them together in a single "message store." This is another point of flexibility and migration, however. If you already have some message-storage resources in place, there's no reason to discontinue their use as long as you supplement them with storage capacity for the media you haven't served before and as long as you have connecting software to integrate the various message types.
There is a trade-off between cost and efficiency in implementing your unified-messaging system. A unified messaging system. A unified message store will make for simpler and better-integrated operators process. As a platform, the unified store is more flexibility extensible to support multimedia feature enhancements such as compound messaging and video messaging.
The converging industries that are making unified messaging a reality have been acting to remove some of the biggest uncertainties about implementation. Vendors are developing technical standards on which multiple service providers and equipment manufacturers can base the key components of a rational flexible, interoperable system. Consortiums such as the Enterprise Computer Telephony Forum (BCTF), the intelligent Network Forum (INF), the Electronic Messaging Association (EMA), and the Object Management Group (OMG) are all working on interoperability standards and process, which help top open the unified messaging market.
Standards are especially important at the messaging interfaces-between one server and another, between the customer's "client" device and the server-and for system directory. Several widely accepted standards are already in place to facilitate the exchange of messages among network-service computers. For transferring email over networks that use TP, the SMTP and MIME have emerged as complementary standards, and MIME for "rich" message content such as formatted text, voice, and binary files. For voice and fax interchange over the Internet, there is the Voice Profile for Internet Mail (VPIM), created by the cross-industry EMA, which is rapidly gaining acceptance. VPIM uses SMTP messages with MIME attachments, which would allow a unified-messaging system's server to send and receive email, voice messages, and faxes, all using same components.
Meanwhile, industry consensus is forming around complete client standards and, today, most unified-messaging solutions support POP3, for simple downloading, and IMAP4, for true interaction between the client and server systems. For the directory system, DAP has emerged as the to standard for establishing centralized directories in support of unified messaging.
Especially when they're all together, the availability of widely accepted standards is what makes unified messaging possible. They give each service provider a choice of both hardware and software products from which they can select to create the system that will best meet their own and their customers' needs, including the ability to integrate their existing servers and other elements into their system design, and to incrementally add capacity and enhancements as their needs and other factors change.
Reaping the full benefits of open systems depends on the system architecture. In addition to the basic network-object design approach, effective unified-messaging solutions should be grounded on a "services platform," software that both originates the objects an assembles them into services. The services platform contains generic functionalities that can serve as the bases for various kinds of software objects, which it then directs. By combining and recombining objects, the services platform can support a wide range of applications, including, but far from limited to, unified messaging-hence, it is "extensible." Once the services platform is in place for one service, developing others is much more economical, especially with a powerful, GUI-based service-creation environment.
The services platform comprises a layer between the system hardware and operating system on one hand, and the application on the other, so it's also commonly known as "middleware." This intermediary position enables the services platform to yield the additional benefit of acting as a buffer. Ordinarily, any changes in computer hardware or an operating system-including updates or enhancements- would affect every application running on the system. The services platform protects applications from the effects of such changes, allowing them to continue uninterrupted.
As one of the early products of the marriage of telephones and computers, unified messaging has the potential to lead the way for many future service applications that cross the telecommunications net works. The more it is based on open systems, the more a unified-messaging system can become a departure point for additional services such as audio voicemail, speech-to-text conversion, video messaging, and advanced call-management features. And the more extensible its services platform, the more nimbly a service provider can respond to a marketplace in which service-development life cycles are measured, not in years, but in weeks and months.
The service providers in the strongest position to enlist tomorrow's millions of unified-messaging customers will be those that build most effectively on the strengths of the public switched telephone network and the Internet; take maximum advantage of standard products and technologies; and design systems capable of both high performance and high flexibility.
The surest route to attaining these qualities, whether as an established provider or as a newcomer to the telecommunications marketplace, is to use a services platform and architecture built on the most widely accepted open standards. Consultants should be able to integrate a select, proven services platform into a service provider's existing telecommunications and messaging environments, also uniting it with network management, provisioning, billing, and other operations-support systems. The resulting unified-messaging system will be compatible with all major protocols, will take full advantage of commodity pricing of components, and will be both extensible and scalable.
The exact color and texture of unified messaging remains to be determined, but the basic shape of the service is clear today. The form of unified messaging that will dominate, if not define, the marketplace will take advantage of the open industry standards that best foster interconnectivity, which is precisely the point of the service. Mature unified messaging will give customers all of the advantages of their present network services, a new level of convenience and reliability, and more. Add this to the advantages for service providers and it's clear that unified messaging will soon be as indispensable as voicemail, email, and fax.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||Technology Information|
|Author:||Tarabour, Richard M.|
|Publication:||Computer Technology Review|
|Date:||Jul 1, 1999|
|Previous Article:||Franklin REX PRO Proves Less Is More.|
|Next Article:||Linux Delivers The Goods For VPNs.|