Why set up an application node?

The purpose of an application node is to run applications outside the voice response node. Java's remote method invocation (RMI) is used for communication. All VoiceXML applications must be run in application nodes rather than the voice response node. CCXML applications can be run on nodes of either type. For Java applications, the performance of applications run on an application node is slower than that of applications run in the voice response node. Nevertheless, application nodes have several potential uses:

Testing applications

Use an application node to test applications in a “pseudo-production” environment, before letting them run on a voice response node. This enables you to check that you have created the correct AppName configuration entry for the application. If you are testing a Java application, use the NodeClassPath keyword on each NodeName configuration entry to specify the classpath of the application you are testing. This enables you to have the same application defined for both production and test nodes.

Note that you cannot run applications from Rational Application Developer on an application node. You run the application “in the application node”, using the services of a voice response node.

Updating applications dynamically

Use an application node to put a new version of an application into production, without having to stop the voice response node. You simply have to stop the application node. So, if you have an application node for each application, you can dynamically update one application without stopping any of the others.

Keeping applications separate

You can have application nodes on different hosts to keep applications physically separate from each other. Nevertheless, all the voice segments for these applications must be located on the voice response node. The only way to keep applications completely separate is to have more than one voice response node.

Improving performance in a high-density system

In a high-density system, excessive Java garbage collection can have an adverse performance impact on your VoiceXML and Java applications. You can avoid this by setting up multiple application nodes on the same host as the voice response node, or on a different host.

Note that when you do run multiple application nodes, by default Blueworx Voice Response creates only one VoiceXML cache directory for use by all the nodes. However, it is possible for each node to use its own directory, which can lead to performance improvements. Use the following procedure to achieve such a configuration:
  1. Login as dtuser.
  2. Stop the Java and VoiceXML environment from the command line by entering: 
    dtjstop
dtjshost -exit
  3. Enter the command cd $DTBE_HOME/native/aix
  4. Using a text editor, open the file default.cff.
  5. For each application node (or voice response node) that you want to use its own cache directory, add the following line to the application NodeName stanza: 
    JavaCommand=java -Dwvr.vxml2.cachedir=directory
    (where java is name of the Java executable (usr/java16/jre/bin/java), and directory is the absolute path of the cache directory you want to use. If you already have a JavaCommand line in default.cff then add -Dwvr.vxml2.cachedir=directory to the end of the JavaCommand line.
  6. Save the file.
  7. Verify that the changes are valid, then update config.cfd by entering the command dtjconf.
  8. Restart the Java and VoiceXML environment by entering the following commands: 
    dtjshost
dtjstart
    The new cache directory is created automatically if it does not already exist.
Parent topic: Setting up an application node