Cisco Cisco Unified Customer Voice Portal 10.5(1) Developer's Guide

C

HAPTER 

2:

 

C

ISCO 

CVP

 

V

OICE

XML

 API Introduction

   

C

ISCO 

CVP V

OICE

XML 3.1

 

 

• 

An application is loaded into memory when the Server first starts up or the application is 
updated. During this process, a single instance of each element (both standard and 
configurable) is created and cached for the application to use. Whenever a call to that 
application encounters an element, the Server will call the execution method of that single 
instance. This means that a single element instance will handle requests made across all calls 
to the application. This applies to multiple uses of an element type in the call flow (e.g. if the 
call flow contains two Digits elements, the Server will actually use the same instance for both 
across all calls). This is very important because in this design, the element class acts as if it is 
static. The consequence of this is that all member variables defined in the element class act as 
static variables, meaning that once changed, every caller experiencing that element type is 
exposed to the same value. It is highly recommended to use only static final member 
variables, store any persistent data in the session (which the API provides access to), and 
keep all other variables local to the execution method. Everything an element needs is 
provided by the API so while this is important to be aware of, this design restriction should 
not prevent the developer from implementing any desired functionality within the element.  

• 

The Server runs in a multi-threaded environment. If the guidelines above are followed, such 
as avoiding member variables and non-final static variables this does not pose a problem. 
The developer does not need to worry about architecting their code with synchronization in 
mind when dealing with local or session variables. They would, however, when performing 
tasks such as accessing external resources such as files. 

Once a component is constructed in Java, the process for compiling and deploying these classes 
is very simple. The Server 

lib

 directory includes JAR files containing everything a developer 

requires to compile custom components. The main JAR file of interest is 

framework.jar

, which 

defines the entire CVP VoiceXML Java API (including the VFCs). To create custom 
components, all that is needed is to ensure that this JAR file appears in the compiler’s 

CLASSPATH

 or referred to in a Java IDE project file. Some Java IDEs, such as Eclipse, require 

additional JAR files, 

servlet.jar

 and 

xalan.jar

, to appear in the 

CLASSPATH

 since the classes 

within 

framework.jar

 refer to classes defined in those JAR files and these IDEs cannot compile 

without definitions for these additional classes. The command-line Java compiler does not 
require 

servlet.jar

 or 

xalan.jar

 to appear in the 

CLASSPATH

. The developer is then 

responsible for adding to the 

CLASSPATH

 any  additional JAR files their custom code requires. 

Once compiled, component class files are deployed separately for CVP VoiceXML Studio and 
CVP VoiceXML Server. Within these deployments, a developer can choose to associate 
component classes with a specific application or with the system as a whole so that the 
components can be shared across all applications. The deployment process for Studio and the 
Server are described in the following sections. A third section provides details on the specific 
deployment directories developers should use.  

 

 

Copyright 2001 - 2005 Audium Corporation.  All Rights Reserved. 10/05

 

12