Article ID:	148
Last updated:	January 12, 2007

Would you like to...

Print this page

Post a comment

User Opinions

No users have voted.

---

How would you rate this answer?

Helpful

Not helpful

Thank you for rating this answer.

The Audium Elements are a collection of pre-built, fully tested building blocks to speed application development.

• Browser compatibility – Audium’s library of Voice Elements produce VoiceXML supporting the industry’s leading voice browsers. They output dynamically generated VoiceXML 2.0 compliant code that has been thoroughly tested with each browser.
• Reusable functionality – Audium Elements encapsulate commonly found parts of a voice application, from capturing and validating a credit card to interfacing with a database. Audium Elements greatly reduce the complexity of voice applications by managing low-level details.
• Configurable content – Audium Elements can be significantly configured by the developer to tailor their output specifically to address the needs of the voice application. Pre-built configurations utilizing proven dialog design techniques are provided to further speed the development of professional grade voice applications.

In Audium, there are five different building block types, or elements, that are used to construct any voice application: voice elements, VoiceXML insert elements, decision elements, action elements, and flag elements. Call Services combines these elements with three additional concepts: hotlinks, hotevents, and application transfers, to represent a voice application.

The building blocks that make up an application are referred to as elements. In Audium, elements are defined as:

Element

A distinct component of a voice application call flow whose actions affect the experience of the caller.

Many elements in Audium share several characteristics such as the maintenance of element data and session data, the concept of an exit state, and customizability.

Element and Session Data

Much like variables in programming, elements in a voice application share data with each other. Some elements capture data and require storage for this data. Other elements act upon the data or modify it. These variables are the mechanism for elements to communicate with each other. The data comes in two forms: element data and session data.

• Element data are variables that exist only within the element itself, can be accessed by other elements, but can only be changed by the element that created them.
• Session data are variables that can be created and changed by any element as well as some other non-element components.

Exit States

Each element in an application's call flow can be considered a "black box" that accepts an input and performs an action. There may be multiple results to the actions taken by the element. In order to retain the modularity of the system, the consequences of these results are external to the element. Like a flowchart, each action result is linked to another element by the application designer. The results are called exit states. Each element must have at least one exit state and frequently has many. The use of multiple exit states creates a "branched" call flow.

Customizability

Most elements require some manner of customization to perform specific tasks in a complex voice application. Customization is accomplished through three different mechanisms supported by Audium: a fixed configuration for the element, a Java API to dynamically configure pre-built elements or to define new ones, and an API accessed via XML-data delivered over http to do the same.

• The fixed configuration approach provides a static file containing the element configuration so that each time the element is visited in the call flow it acts the same. Even in dynamic voice applications, not every component need be dynamic; many parts actually do not need to change.
• The Java API approach is used for dynamic customization and is a high performance solution because all actions are run by compiled Java code. The one drawback to this approach is that it requires developers to have at least some Java knowledge, though the Java required for interfacing with the API is basic.
• The XML-over-HTTP (or XML API for short) approach affords developers the ability to utilize any programming language for the customization of elements. The only requirement is the use of a system that can return XML based on an HTTP request made by Audium Call Services. The advantages of this approach include: a larger array of programming language choices, the ability to physically isolate business logic and data from the voice presentation layer and the use of XML, which is commonly used and easy to learn. The main disadvantage of this approach is the potential for HTTP connection problems, such as slow or lost connections. Additionally, the performance of this approach does not typically perform as well as compiled Java because XML must be parsed at runtime in both Call Services and the external system.