Up to this point the discussion has focused exclusively on the development phase of speech applications using the SASDK. Ultimately, the SASDK is a faithful simulated representation of a Speech Server, coupled with additional development and debugging tools. The benefit is that when it comes time to deploy speech applications they exist as a set of ASP.NET Web pages and artifacts as shown in Table 3. Deployment is simply the process of packaging and deploying these files using the same methodology as any ASP.NET application.
Table 3: The typical components of a speech application.
A file containing the visual elements of a Web Forms page.
A file that persists a user control as a text file.
A file that handles application-level events.
An ASP.NET Web Handler file used to manage raw HTTP requests.
A grammar file.
A binary file created by the SASDK command-line grammar compiler.
A compiled prompt database that is created when a .promptdb file is compiled with the Speech Prompt Editor.
However, there are some inherent architecture differences to remember between the SASDK and the Speech Server environment. For example, the Telephone Application Simulator (TASIM) provided by the SASDK is used in the development of voice-only applications. It simulates the functions of both the TAS and SES components of a Speech Server. Once the application is deployed you wouldn't be able to access voice-only applications from Internet Explorer. In a production environment, the TAS component and the SES component are completely separate. The TAS is responsible for handling the processing of incoming calls and SES handles speech input. In the development environment both of these functions are handled by the TASIM. Additionally, in the development of a multimodal application, debugging is provided by the Speech add-in for Internet Explorer, which has been enhanced to include extensions and integration with the Speech Debugger. However, these enhancements aren't available as part of the standard client installation.
Finally, when developing applications using the SASDK it is possible to build applications where the paths to grammar files are specified by physical paths. However, within the production Speech Server environment, all paths to external resources such as a grammar file must be specified using a URL not a physical path. Prior to creating your deployment package it is always a good idea to switch into HTML view and verify that all grammar file paths use a relative or absolute URL.
There are many different ways to deploy the components of Speech Server based on your usage and workload requirements. Each component is designed to work independently. This enables the deployment of single or multi-box configurations. The simplest deployment is to place the TAS, SES, IIS, hardware telephony board, and TIM software together on a single machine. Without a doubt the Web server is the essential component of any Speech Server deployment as it is the place where applications are deployed and the SALT-enabled Web content is generated. Even if you decide to deploy Speech Server components on separate Web Servers, each server running SES must have IIS enabled.
In this article you've looked at how to use the SASDK and Microsoft Speech Server 2004 to develop speech-enabled ASP.NET applications. The SASDK provides the development environment that includes a simulator and debugging tools integrated into Visual Studio 2003. This combination provides developers the ability to build and test voice and multimodal applications on their local machine. Once the application is complete, Microsoft Speech Server provides the production-level support and scalability needed to run these types of applications. Personally, I don't expect to be talking to HAL anytime soon. However, the possibilities are starting to get better.