Cisco Cisco Customer Voice Portal Downloads リリースノート
A
PPENDIX
A:
T
HE
V
OICE
F
OUNDATION
C
LASSES
P
ROGRAMMING
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
R
ELEASE
7.0(1)
95
Appendix A: The Voice Foundation Classes
The Unified CVP Voice Foundation Classes are a Java API for generating VoiceXML. Any
custom component wishing to produce VoiceXML must use the VFCs because their main
purpose is to act as an abstraction layer between VoiceXML and the component. The VFCs
handle the vagaries of VoiceXML and especially the differences in the VoiceXML interpreted by
various voice browsers. This allows the developer to simply focus on the functionality desired
without worrying about the details of writing VoiceXML or the quirks of their chosen voice
browser. The VFCs are primarily used to construct voice elements, though hotevents and on call
end classes use the VFCs as well.
custom component wishing to produce VoiceXML must use the VFCs because their main
purpose is to act as an abstraction layer between VoiceXML and the component. The VFCs
handle the vagaries of VoiceXML and especially the differences in the VoiceXML interpreted by
various voice browsers. This allows the developer to simply focus on the functionality desired
without worrying about the details of writing VoiceXML or the quirks of their chosen voice
browser. The VFCs are primarily used to construct voice elements, though hotevents and on call
end classes use the VFCs as well.
VFC Design
The high level design of the VFCs is to simulate standard VoiceXML in Java. The behavior of
these classes directly match the VoiceXML specifications (both versions 1 and 2). This,
however, acts only as a basis from which supporting a particular voice browser begins, since no
two browsers have exactly the same compliance. The software provides voice browser
compatibility by extending these base VFCs to create a layer that produces the VoiceXML
compatible with a particular voice browser. Most of the functionality is still defined in the base
VFC classes and only the browser-specific functionality needs to be included in the subclasses.
The classes for a particular voice browser are encapsulated in a separate plugin or driver, called a
Gateway Adapter. Installing a new Gateway Adapter will add support for a new voice browser
and a Unified CVP application can be deployed on a new browser by simply selecting the
Gateway Adapter to use.
these classes directly match the VoiceXML specifications (both versions 1 and 2). This,
however, acts only as a basis from which supporting a particular voice browser begins, since no
two browsers have exactly the same compliance. The software provides voice browser
compatibility by extending these base VFCs to create a layer that produces the VoiceXML
compatible with a particular voice browser. Most of the functionality is still defined in the base
VFC classes and only the browser-specific functionality needs to be included in the subclasses.
The classes for a particular voice browser are encapsulated in a separate plugin or driver, called a
Gateway Adapter. Installing a new Gateway Adapter will add support for a new voice browser
and a Unified CVP application can be deployed on a new browser by simply selecting the
Gateway Adapter to use.
The design of the base VFCs follows roughly the design of VoiceXML, utilizing similar
concepts and naming, so prior knowledge of VoiceXML is beneficial for understanding the VFC
design. The VFCs allow full compatibility with VoiceXML in that anything you can do in
VoiceXML you can do in the VFCs, including using proprietary tags and/or attributes introduced
by supported browsers. Many times, a single VoiceXML tag maps to a single VFC that is
similarly named. The class
concepts and naming, so prior knowledge of VoiceXML is beneficial for understanding the VFC
design. The VFCs allow full compatibility with VoiceXML in that anything you can do in
VoiceXML you can do in the VFCs, including using proprietary tags and/or attributes introduced
by supported browsers. Many times, a single VoiceXML tag maps to a single VFC that is
similarly named. The class
VForm
, for example, deals with VoiceXML
<form>
tags and the class
VField
with
<field>
tags. Some tags, however, have been combined into a single VFC for ease
of use. For example, the
VAction
class encapsulates tags such as
<var>
and
<assign>
to
<break>
and
<submit>
. As a result, there are fewer VFCs than VoiceXML tags. The VFCs also
help the developer by producing some VoiceXML automatically. The developer will quickly
find that using the VFCs is very much like coding in VoiceXML, except in Java.
find that using the VFCs is very much like coding in VoiceXML, except in Java.
There are a few concepts that need to be described before delving into the individual VFCs. First,
each VFC class extends a common base class,
each VFC class extends a common base class,
VRoot
. The purpose for this is similar to having all
Java classes extend
Object
, it is a way to help define common functionality of the VFCs as well
as being able to identify if a Java class is a VFC.
The second concept involves the hierarchy of the VFCs. There are, in fact, several layers of
abstraction in the VFCs that separate not only differences between various voice browsers but
abstraction in the VFCs that separate not only differences between various voice browsers but