February 28, 2021
Hot Topics:

Review: Audium 3

  • By Hitesh Seth
  • Send Email »
  • More Articles »

Dynamic Module Configurations

In step 5 of the VoiceXML application design we created using the Audium Builder we introduced the notion of a configuration for a module. The configuration of a module describes the various properties, variables, prompts, etc. that a module provides. In simpler scenario, module configurations can be static, however, to support complex scenarios module configurations may be dynamic. Let's take an example approach by looking at the Audio module. By default, the audio module supports a set of prompts that can be configured to either play pre-recorded audio or play a text-to-speech message. If we would like to play a static line of text we can just have it be a part of the prompts that are played in the Audio module. However, if components of that prompt are dynamically retrieved from a backend application then we will need to set up the module to have a Dynamic Configuration.

Two mechanisms are supported by Audium to achieve dynamic configuration capability:

  1. Where you get the configuration from a Java class file: In this scenario we create a class which implements the com.audium.server.proxy ModuleInterface Java Interface. This class then should be placed in %AUDIUM_HOME%\applications\ApplicationName\java\application\classes directory.
  2. Where you get the configuration information from a web based HTTP/XML exchange: In this scenario, information about the current VoiceXML session is posted to the HTTP-based loosely-coupled interaction.

To understand dynamic Module Configurations let's look at an example. Let's say we would like to build an Employee Locator application. We would like to provide the information (phone numbers, email address) to a caller after recognizing the name of the employee and then transfer the user to a selected phone type (mobile/direct). The call flow for the application is shown below.

Implementing a module configuration is a relatively simple task--it just requires us to implement a single method, getConfig() which returns a ModuleConfig instance. Typically, you can just modify the existing default configuration and add the dynamic functionality.

package com.silverline;import java.util.*; import com.audium.server.proxy.*; import com.audium.server.module.*; import com.audium.server.session.*; import com.audium.server.*; import com.audium.server.xml.*; public class EmployeeModuleConfig implements ModuleInterface {  public ModuleConfig getConfig(String name,    EntityAPI input,    ModuleConfig defaults) throws AudiumException {    ModuleConfig.PromptGroup initial = defaults.getPromptGroup("initial_prompt", 1);   String employee_name = input.getPublicData("EmployeeForm", "selection");// Query the database using JDBC and get the employee // information into the string employee_info_string   initial.insertPrompt(1, defaults.new AudioPrompt(employee_info_string, null));      return defaults;      } }


Whereas Dynamic Configuration can be used to provide dynamic behavior in a number of scenarios, it is limited to the fact that it can only change the results of the module but can't change the call-flow itself. In some scenarios, however, we would like the call flow itself to be changed depending on the outcome of a business rule. Audium supports this capability by allowing VoiceXML application developers to implement a "Rule". Similar to a Dynamic Configuration, a rule can also be implemented as a Java class or a HTTP/XML interaction.

To understand how rules are built, let's say we want to build a customer service application. As a business rule we would like all platinum customers to be treated differently than regular customers. The figure below shows an illustrative call-flow for the same.

To implement a rule using Java, the developer is required to implement the com.audium.server.proxy.RuleInterface Java Interface, as illustrated below.

package com.silverline;import java.util.*; import com.audium.server.proxy.*; import com.audium.server.session.*; import com.audium.server.*; public class CustomerRule implements RuleInterface {  public String doRule(String name, EntityAPI input) throws AudiumException { String customerID = input.getPublicData("CustomerForm", "selection");  String customer_type = CustomerBusinessObject.getCustomerType(customerID);      return customer_type;        } }


So Rules are used to change call-flow sequences and Dynamic Configurations are used to change the VoiceXML markup that is generated by Audium. What if you would like to do some background processing without changing the call-flow or the VoiceXML markup? To implement such background processing, Audium provides the concept of Worklets. As always, a worklet can also be implemented as a Java class or a HTTP/XML interaction.

To understand how worklets are developed and used, let's say we want to build a worklet which audits some of the key interactions with the customer into an Audit Trail database. The figure below shows an illustrative call-flow for the same.

To implement a worklet using Java, the developer is required to implement the com.audium.server.proxy.WorkletInterface Java Interface, as illustrated below.

package com.silverline;import com.audium.server.proxy.*;import com.audium.server.session.*;import com.audium.server.*;import java.util.*public class CustomerAudit implements WorkletInterface { public void doWork(String name,   WorkletAPI input) throws AudiumException {    String customerID = input.getPublicData("CustomerForm", "selection");    Date today = new Date();    AuditTrailDatabase.log(customerID,today);}}

New Modules

In the previous article we had a chance to look at the various set of modules that are provided by Audium. The fact that there are bunch of modules which are available indicates that there must be a mechanism to create custom modules. For instance, if you would like to implement some functionality that your gateway provides but is not implemented as part of the Audium system, such asSpeech Verification. This scenario would require you to build a new module, which requires implementing the abstract Java class com.audium.server.module.ModuleBase. This class is used as the base class for all modules that are used with the Audium server. To create VoiceXML output from the module, Audium Voice Foundation Classes (VFC) should be utilized.

When to Use What?

Dynamic Module Configurations Change the embedded VoiceXML markup without changing the overall call-flow. For instance providing a dynamic prompt.
Rule Change the call-flow without effecting the markup.
Worklet Do some processing in the background; No change to the call-flow; No change to the VoiceXML markup.
Module Create a totally new functionality encapsulated as a reusable module.


It is pretty clear that the Audium product is different from all the other IDEs, development tools and hosted development environments that we have reviewed so far. It actually falls into a class of what I call "server-side dynamic VoiceXML platforms."

Overall, I believe that there are some good features that exist in the Audium product, especially in the soon-to-be-released 3.0 version, (such as the intuitive call-flow building capability). As with any pre-release product, I did come across some issues which I pointed out to the Audium product engineering team. The capabilities that I believe should be added to the product include: closer integration with external/internal grammar development and integration (specially W3C XML grammars), step-by-step debugging capabilities, distributed development/deployment support (through remote deployment capabilities) and a larger suite of reusable components.


About Hitesh Seth

Hitesh Seth is Chief Technology Evangelist for Silverline Technologies, a global eBusiness and mobile solutions consulting and integration services firm. He is a columnist on VoiceXML technology in XML Journal and regularly writes for other technology publications including Java Developers Journal and Web Services Journal on technology topics such as J2EE, Microsoft .NET, XML, Wireless Computing, Speech Applications, Web Services & Integration. Hitesh received his Bachelors Degree from the Indian Institute of Technology Kanpur (IITK), India. Feel free to email any comments or suggestions about the articles featured in this column at hks@hiteshseth.com.

Page 3 of 3

This article was originally published on September 3, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date