By Kam Lung Leung

Introduction

Traditionally, enterprise voice application were found primarily within the financial industry. However, in recent years, we saw a number of large eCommerce companies become early adopters of VoiceXML based voice applications. As demand for more sophisticated voice applications increases, the inherent complexity of the applications also increases. In the remainder of this article we take a look at how one can deal with this complexity by incorporating extensibility, stability, and vendor independence into application and system design.

Extensibility

Extensibility refers to the ability to upgrade or add new modules to a voice application without replacing the whole voice application or rebooting the system. Many enterprise systems can take up to an hour or more to run system self diagnose and self-discovery. The ability of performing module upgrades in an enterprise system is a must. A voice application consisting of multiple self-running modules is the best way to ensure extensibility of the product. We may think of it like the concept of Peer-to-Peer in computer networking, where each individual computer is interconnected to computer network and shares information, communicating to each other via TCP/IP transport.  For example, the secondary inbound/outbound self-governing module, Storage Server, within PAAM can be upgraded independently without rebooting the whole system.  In essence, a module is upgraded on the standby and later becomes an active server through automatically, or manual switching by a system administrator. With this scheme upgrading a module will not disrupt traffic to the system during the switch.  PAAM can be deployed in multiple-servers configuration for use in enterprise level system, but it can also be housed in a single server system. Of course, this leads to a commonly asked question among many system designers: is a system assembled by many self-governing module (server) be more stable than a large monolithic server system? This leads us to the attribute of stability of the system.

Stability

Stability means the robustness of the system, not just the voice application. Any enterprise level system requires at less 99 percent uptime. There are a variety of ways to design a stable system. One way is to use a server constructed with the most expensive, reliable, and high performance hardware components to host voice applications, and hoping that the hardware will not fail. On the other hand, the same stability can be achieved by using less expensive hardware components and building a network of active and standby servers.  In fact a total of 1:N or p:N protections for all self-governing modules can be archived where N is a finite arbitrary number of active servers and p is a finite arbitrary number of standby servers. For the 1:N case, one standby server protects all active servers in the system. The later case involves multiple standby servers protecting any arbitrary number of active servers.  With this architecture, the voice application running on the active server must be able to switch to the standby server in case of a failure that may or may not be hardware related. Downtime of the system is minimized through this approach.  In particular, stability is achievable by combining hardware modularization, the software distribution capability of J2EE and deployment of voice applications on a Linux enterprise cluster configuration.

Vendor Independence

Advance capabilities such as volume control on demand, playback speed control on demand, environmental noise detection and filtering on demand, and 64-bits bit-wise operation in scripting language are needed to meet the demands of sophisticated services for today voice application. However, in most cases these capabilities are not yet included in the current VoiceXML specification. Thus, voice server platform vendors may choose to implement the missing capabilities in proprietary ways. In general however, it is not a good idea to totally rely on one particular voice server platform vendor for the company’s entire line of products. This leads to the need of VoiceXML compliant certification and vendor independent capability from software components.  In an enterprise level configuration, ideally the voice application will dynamically generate VoiceXML page that all voice servers from different vendors in the system can process. Thus, a voice server that is from vendor AA can be replaced by a voice server that is from vendor BB in a voice application system without software changes. This is feasible as long as those voice servers are compliant with the VoiceXML specification. Having said that, what should we do if there is a need to use a vendor specific functionality? In PAAM, software component for vendor specific is dynamically loaded into the system in real time. This capability allows PAAM to use vendor specific functionalities without depend on it entirely.

Conclusion

We have looked at three important design attributes of enterprise-level voice applications.  The first attribute is extensibility achievable by employing combination of hardware and software modulations. The second attribute is stability achievable by employing the concept of active, standby and combination of hardware and software distributing capability. The third attribute is vendor independence achievable by using VoiceXML certified voice server platform vendor and deterministic capability from software components to ensure interoperability among voice server platform from different vendors. We can see the benefits of building a voice application around the three attributes discussed in this article which will fulfill the demand of sophisticated services for today and tomorrow’s enterprise voice application.