You can migrate applications written using Speech Server 2004 to run on Speech Server using the following scenarios:
Scenario 1: Run Speech Server 2004 Web Server with Speech Server
In this scenario, you leave the application running on the Speech Server 2004 Web server. The computer running Speech Server points to the Speech Server 2004 Web server and the application functions unchanged. This scenario requires no changes to the application, such as code changes, recompilation, or redeployment.
While this scenario poses the least risk to the application, there are drawbacks. For example, Visual Studio .NET 2003 solutions must be converted to open in Visual Studio 2005. When converted, the solution is no longer compatible with Visual Studio .NET 2003. If you continue using Visual Studio .NET 2003 to develop existing applications and develop new applications in Speech Server, you must run both Visual Studio .NET 2003 and Visual Studio 2005. In addition to managing two versions of Visual Studio, developers cannot use new Speech Server tools such as Conversational Grammar Builder, streamlined grammar libraries, and the Session Initiation Protocol (SIP) phone simulator.
Speech Server introduces two new languages: English (United Kingdom) en-UK and German (Germany) de-DE. However, these new languages are unavailable to applications that are migrated to Speech Server using this scenario.
Scenario 2: Port an Application to Speech Server
In this scenario, you port the application written using Speech Server 2004 to Speech Server as a Web application. This approach does not use the new managed code paradigm, but unlike scenario 1, the new application is a complete Speech Server solution. As such, it takes advantage of most of the new features of Visual Studio 2005 and Speech Server (all non-designer tools), as well as the new Speech Server languages.
.gif) Note: |
|---|
|
If your application has an associated Setup program, you should not migrate the Setup program. Instead, rebuild it using Speech Server after migrating the application.
|
To port an application to Speech Server
-
Convert the Visual Studio .NET 2003 solution into a Visual Studio 2005 solution.
-
Update references to the Speech Controls version number.
-
Make any necessary ASP.NET 2.0 changes.
For information, see Upgrade from ASP.NET 1.x.
-
Recompile the application.
-
Redeploy the application.
Converting Visual Studio .NET 2003 solutions into Visual Studio 2005 is mostly automatic. Opening the solution in Visual Studio 2005 starts the Conversion Wizard, which makes most of the necessary changes. However, the wizard does not automatically update the Speech Controls version number. You must manually change all references to version 1.0.3200.0 of the Microsoft.Speech.Web assembly to version 2.0.3200.0 by using the Replace All option on all project files.
Also, the Conversion Wizard does not automatically handle all the changes in ASP.NET 2.0. For example:
-
Modify Web.Config file to remove the assembly name from the configSection element. In Visual Studio 2005, ASP.NET no longer precompiles the Web site into an assembly.
-
ASP.NET 2.0 disallows circular references, such as <% Register TagPrefix=”Contacts” TagName=”CommonSpeechElements” Src=”CommonSpeechElements.ascs” %>.
Also, in Visual Studio 2005, the HTML validation Show error option is selected by default. This default setting can generate compiler errors because the Speech Server 2004 Speech Controls render output that triggers numerous HTML validation errors. Fortunately, most of these errors do not interfere with the building and running of the applications and can therefore be ignored. Because these errors are misleading, you should disable the Show error option for HTML validation.
To disable the Show Error option
-
In Visual Studio 2005, click Options on the Tools menu, and then expand Text Editor.
-
Under Text Editor, expand HTML, and then select Validation.
-
Under the Target list, clear Show errors.
Scenario 3: Wrap an Application in Managed Code
Speech Server provides a SaltInterpreter object that lets you point a Speech Server managed code application to a Speech Server 2004 application. Using SaltInterpreter, you can move to the managed code programming model without rewriting the Speech Server 2004 application. You can extend existing Speech Application Language Tags (SALT) applications in Speech Server using the new managed programming paradigm, making minor modifications to the SALT application.
Minor modifications to the application might be necessary at the periphery. For example, slight modifications might be necessary on the first page to consume data passed into SaltInterpreter by the managed application and the opposite on the last page.
| Note: |
|---|
|
The SaltInterpreter object works with Speech Server Speech Controls.
|
This scenario requires you to run Visual Studio .NET 2003 and SASDK 1.1 to edit the SALT portion of the application. You also need Visual Studio 2005 and Speech Server to develop the managed wrapper portion of the application.
If you choose this scenario, you do not get the benefits of Visual Studio 2005, Speech Server tools, or Speech Server languages for your existing SALT application. However, new extensions to the application, written in managed code, are able to fully benefit from these features.
You cannot call into managed code from a SALT application. However, if you first wrap the SALT application in managed code, you can call into and out of the SALT application from the managed code.
Scenario 4: Rewrite an Application in Managed Code
In this scenario, you rewrite the application in managed code. This is the only option where you take full advantage of Visual Studio 2005, Speech Server languages, and all the Speech Server tools including Workflow Designer. The prompts and grammars do not need to be rewritten.
The obvious disadvantage of this scenario is that you must essentially recreate the application call flow. Also, while you can host SALT applications on a separate Web server, managed code voice response applications must run on the computer running Speech Server.
However, this does not prevent you from creating multi-tiered managed code applications. You can continue to design multi-tiered managed code applications that call into other applications (such as a business logic application) in other tiers.
Scenario 5: Port an Application to Speech Server and Wrap it in Managed Code
This scenario is a combination of scenarios 2 and 3, where you port the application and wrap it in managed code. This approach provides flexibility and benefits at a low cost. The existing application does not need to be rewritten, and new extensions to the application can be written using Workflow Designer and managed code. This approach eliminates the need to maintain Visual Studio .NET 2003 and SASDK 1.1 and delivers the full benefits of the additional features of Visual Studio 2005 and Speech Server.