Increased Functionality = Increased Complexity?
Sophisticated VoiceXML applications, like their visual counterparts rely heavily on information stored in back-end databases. Such applications may be executed in an application environment where the code that is consumed by the VoiceXML interpreter is generated at run time. It is quite feasible, and sometime very desirable, to engineer VoiceXML applications in this way using programming languages like PHP, ASP and JSP (among others). For example, a VoiceXML application that provides information updates might be designed to query a database at run time to alert the caller to any new updates. The trade off for this level of sophistication is greater complexity and additional points of failure for an application.
To understand these issues better, it helps to have an understanding of the different parts of a dynamic VoiceXML application.
Clearly, an application designed like this will require components that a more streamlined VoiceXML application would not. In addition to the standard web sever, a run time environment, where application code is executed must be established, as must a database server to process SQL queries. And while all of these components can reside on the same physical server, production performance requirements typically result in these components being placed on separate servers.
As a result, a problem with any one server can negatively impact the application. Other problems, like an error in executing the application code or a problem with the network connecting the different servers can also cause major problems. Unfortunately, if your VoiceXML application is heavily reliant on data stored in a back-end database, there aren’t a lot of really
Working on the client
Distilled to its essence, the real power of VoiceXML is that it extends the traditional web development paradigm to the telephone. This underlying development paradigm includes a host of features that help boost the performance of web applications.For example, storing web content and files in a local cache can speed up the delivery of information to end users. Most users are never even aware of this process, but it is a fundamental feature of visual browsers and traditional web pages/applications.
In order to demonstrate the power of multidimensional arrays in voice applications, we need to identify a suitable example whose functions we will emulate. For this example, I have chosen an application created by the State of Delaware – the Internet Access Locater (http://www.state.de.us/dti/vxml.shtml). This application follows the traditional multi-tier architecture found in most web applications with a separation of presentation, application and database layers.
To be clear, this application works well, and the architectural model used is sound. However, the data that is used by this application changes infrequently. Since, the application utilizes and external VoiceXML interpreter, there is always the potential for a degradation in performances caused by problems with the connection between the VoiceXML interpreter and the underlying application layer. This potential degradation can be avoided by storing the data used by the application on the client side (e.g., the VoiceXML interpreter), instead of in a back end database.
Caching Data on the Client Side
In a VoiceXML application, the “client” is actually the VoiceXML interpreter which acts as sort of proxy client for a caller’s telephone. (In the VoiceXML application architecture, it isn’t really feasible to store information on an end users phone.) In order to cache files on a VoiceXML interpreter, the appropriate HTTP headers need to be sent when the document is fetched. There is an excellent article on the benefits of caching data to improve the performance of VoiceXML applications available at http://www.voicexmlreview.org/Dec2002/features/vxml_app_performance.html
which provides more detail on this point.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.