|
介紹
計算機(jī)電話系統(tǒng)
Dialogic® NetMerge™ CT應(yīng)用開發(fā)環(huán)境
應(yīng)用環(huán)境語言（ADL）
應(yīng)用開發(fā)ActiveX對象（ADX）
新的方向
■ 介紹
本文可以幫助用戶了解Dialogic® NetMerge™ CT應(yīng)用開發(fā)環(huán)境（CT ADE）對于項目開發(fā)的價值，可以為用戶提供以下有價值的幫助如果用戶：
- 通常是在C/C++中使用硬件API編寫電話應(yīng)用
- 使用過Dialogic早期產(chǎn)品：VOS和CallSuite
- 曾經(jīng)使用過其他應(yīng)用開發(fā)工具
- 剛剛開始進(jìn)行電話應(yīng)用開發(fā)
■ 計算機(jī)電話應(yīng)用
開始之前，我們應(yīng)該考慮一下，我們打算使用這種技術(shù)做什么，以何種方式應(yīng)用這種技術(shù)。
我們的應(yīng)用需要能夠：
- 檢測和應(yīng)答到達(dá)的呼叫
- 進(jìn)行呼出呼叫并且檢測結(jié)果（忙，無應(yīng)答，語音應(yīng)答，機(jī)器應(yīng)答等等）
- 與呼叫方交互（向呼叫方播放語音，來子呼叫者的信號音和語音）
- 與呼叫方交換數(shù)據(jù)（從數(shù)據(jù)庫中讀寫數(shù)據(jù)）
- 控制呼叫（會議，拆線，轉(zhuǎn)接，保持，重試）
這些基本的操作應(yīng)該能夠在下列環(huán)境中執(zhí)行：
- 多種協(xié)議的網(wǎng)絡(luò)中（環(huán)路啟動，T-1/E-1 CAS, ISDN, IP），網(wǎng)絡(luò)協(xié)議隨國家而改變
- 多種尺寸的設(shè)備中（一個機(jī)箱2個模擬端口，一個機(jī)箱500個端口，多個協(xié)作的機(jī)箱）
- 多種操作系統(tǒng)控制下（Windows, Linux, Unix）
- 與系統(tǒng)管理監(jiān)控器和管理器相連接
最后，所有的這些任務(wù)都要和商業(yè)邏輯協(xié)調(diào)工作，輸入分析，控制操作，和輸出。
創(chuàng)建這種應(yīng)用的可選項有：
- 軟件包－如果您的應(yīng)用執(zhí)行相當(dāng)普通的操作，您會發(fā)現(xiàn)完軟件包可以按照您的意愿完成90％的操作，最后可以通過配置和定制滿足最后10％。語音郵件和交互式語音應(yīng)答（IVR）系統(tǒng)是此類一種普遍的應(yīng)用。
- 結(jié)構(gòu)－能夠為您的商業(yè)邏輯提供電話容器的解決方案較少，呼叫控制，呼叫監(jiān)控，呼叫管理組件提供了一個靈活的結(jié)構(gòu)，可以將應(yīng)用工作加入其中。這種應(yīng)用范圍可以從腳本語言到拖拉函數(shù)組件。
- 對象庫－電話處理函數(shù)能夠以類對象的方式發(fā)布，可以應(yīng)用在C++, Delphi, Java等非電話處理語言中，開發(fā)者可以使用能夠調(diào)用庫函數(shù)的標(biāo)準(zhǔn)語言進(jìn)行設(shè)計商業(yè)邏輯和應(yīng)用，對象和結(jié)構(gòu)有時可以指中間件。
- 控制API－這是設(shè)備制造商提供的接口，用來控制硬件。它依賴于不同的操作系統(tǒng)，這樣應(yīng)用程序員不僅要處理商業(yè)邏輯和程序設(shè)計，而且還要處理句柄、事件、狀態(tài)、以及電話硬件設(shè)備的封裝接口。
- 話音API－除了硬件接口以外，也有一些控制API用于其他技術(shù)，如語音合成，語音識別，而且也可以直接控制，通常是在C/C++中，或者在高層語言、庫和程序包中抽象成服務(wù)函數(shù)。
那一種最好？答案不僅依賴于應(yīng)用和可用產(chǎn)品，還依賴于您的公司和部門的開支和任務(wù)。區(qū)分這些可選方法的問題包括：
- 軟件包－如果軟件包涵蓋了您所需要的所有功能，可以采用一個基本解決方案快速。如果不是這樣，定義和擴(kuò)展所要開發(fā)的系統(tǒng)將非常困難，這取決于系統(tǒng)設(shè)計是否容易改變。性能和可擴(kuò)展性是一個普遍的問題，購買之前必須予以考慮。
- 結(jié)構(gòu)－這些結(jié)構(gòu)將會有不同的形式，當(dāng)不是所有的結(jié)構(gòu)都符合您的應(yīng)用目標(biāo)時，這些形式具有或多或少的靈活性，然而這些對于大多數(shù)的電話應(yīng)用來說，可以簡化應(yīng)用程序的編程，一些產(chǎn)品不需要提供硬件的不常用操作的功能。像軟件包一樣，性能很重要，這依賴于解決方案的通用型和設(shè)計中的優(yōu)化程度。
- 對象庫－由于這些對象很少會針對某一應(yīng)用，這些組件比軟件包和結(jié)構(gòu)更加靈活。通過特定接口抽象成通用形式，易于在類似的技術(shù)中進(jìn)行移植（像針對自動語音識別（ASR），ISDN和CAS網(wǎng)絡(luò)協(xié)議，或者DM/IP板卡和IP連接主媒體處理等等的SpeechWorks,
Nuance）。
- 控制API－這些肯定是控制硬件或者語音引擎的最全面的工具，選擇是根據(jù)必須精確管理的詳細(xì)程度。需要考慮培訓(xùn)成本和該選擇的實現(xiàn)，這不僅是針對應(yīng)用的初級版本，而且還要針對底層技術(shù)的可改變性。
■ Dialogic® NetMerge™
CT應(yīng)用開發(fā)環(huán)境
Dialogic提供了三種上述可選的清單：
- 一個控制功能的C/C++ API（R4）
- 一個電話結(jié)構(gòu)
- 一個對象庫
后兩項打包成Dialogic® NetMerge™ CT應(yīng)用開發(fā)環(huán)境（CT ADE），(關(guān)于R4的一些更多的信息，請參見http://www.Dialogic.com/)。
本文后面的部分描述這兩個CT ADE編程平臺的概念和功能：
- 應(yīng)用開發(fā)語言（ADL）－一種過程語言，擁有可選的圖形接口，集成了多種電話應(yīng)用構(gòu)建模塊。
- 應(yīng)用開發(fā)ActiveX對象（ADX）－一個具有COM接口的方法庫，可以集成到Windows下的開發(fā)語言中，如C++,
Visual Basic, Delphi，以及.NET語言C#和VB.NET等。
這兩個平臺的核心是資源管理器，是執(zhí)行所有電話交互基本代碼的基本代碼。
資源管理器
資源管理器的核心組件是介于您的編程命令（如ADX中的Play，ADL中的MediaPlay）和底層設(shè)備API之間的中間層代碼。例如：如果您需要激活A(yù)DL函數(shù)TrunkAnswerCall，資源管理器可以決定：
- 使用哪一個中繼接口
- 進(jìn)行此呼叫是否合法（有呼叫信號嗎？）
- 使用哪一個API函數(shù)：dx_sethook(R4 analog), ccAnswer(R4 PRI),gc_Anser_AnswerCall(R4
Global Call)等等。
為了能得到設(shè)備抽象，我們需要定義設(shè)備和所有的設(shè)備特征。
資源
資源管理器是圍繞著資源的概念構(gòu)建的，技術(shù)上，一個資源可以產(chǎn)生或者處理一個語音流，資源可以分成以下幾類：
- 中繼接口
- 媒體（播放器/記錄器）
- 傳真（發(fā)送機(jī)/接收機(jī)）
- 文字到語音轉(zhuǎn)換（TTS）
- 語音識別
- 會議
- 一些可以幫助了解這些信息的示例
首先考慮一個具有4信道的Dialogic® Dialogic™ D4PCI話音處理板卡，從資源管理器中可以看到一個信道具有兩個資源：中繼資源和媒體資源。中繼資源對應(yīng)電話線連接器，媒體資源對應(yīng)可以播放和記錄聲音文件的VOX設(shè)備。
通道管理兩個語音流，呼叫方話音（同樣包括撥號音和其他音頻）按照下列路徑處理：
呼叫方→模擬電話線→中繼資源→媒體設(shè)備（VOX/Wave記錄器）
在另一個方向，音頻流在VOX/Wave記錄器產(chǎn)生，通過中繼接口發(fā)送給電話線路：
媒體資源（VOX/Wave記錄器）→中繼資源→模擬電話線→呼叫方
正如這個例子所示，語音流從一個資源輸出有時可以作為另一資源的輸入，對于D4PCI卡，媒體和中繼設(shè)備是硬件，可以實現(xiàn)從一個輸出而輸入到另外一個資源，反之一樣。對于高端設(shè)備，可以控制這種傳輸?shù)穆酚桑ɡ�，SC和CT總線上的設(shè)備）。
另外一個例子，考慮Dialogic® Dialogic™ D4JCTLS融合通信卡，該卡具有4個中繼接口（稱為LSI設(shè)備）和4個播放器/記錄器（VOX設(shè)備），資源管理器認(rèn)為LSI是一個中繼資源，一個VOX是一個媒體資源。從資源管理器的角度看，該卡和D4PCI相似，主要不同是可以通過CT總線改變路由資源。
一個T-1 PRI ISDN接口卡，如Dialogic® Dialogic™ DTI240SC卡，可以被資源管理器作為23個中繼資源，每一個都各作為話音（B）信道。換句話說，一個中繼資源對應(yīng)一個T-1時隙。在ISDN電路上的其他信令（數(shù)據(jù)、D）信道不作為資源管理器的資源（它不處理任何話音）。在大多數(shù)情況下，D信道的存在和管理對于資源管理器的用戶是隱藏的。例如：如果一個T-1緩存一個LOS狀態(tài)（信號丟失，D信道故障），則用于B信道傳輸?shù)?3個資源管理器中繼資源的每一個都轉(zhuǎn)為網(wǎng)絡(luò)故障狀態(tài)（后面會有更多的資源狀態(tài)介紹）。如果一個B信道需要發(fā)起呼叫，此呼叫需要向D信道發(fā)送數(shù)據(jù)包，資源管理器可以像普通模擬中繼中發(fā)起呼叫類似一樣，通過DTMF撥號發(fā)起呼叫。
資源狀態(tài)將底層的技術(shù)事件和命令結(jié)果集合到操作資源狀態(tài)中。大多數(shù)情況下，您在編寫應(yīng)用時不用分析這些狀態(tài)變化，然而，如果需要分析，這些邏輯呼叫處理可以給出一些意想不到的狀態(tài)。
資源狀態(tài)
對于每一個資源（中繼、媒體、傳真、TTS、語音識別、會議），資源管理器預(yù)定義了一些狀態(tài)，例如，一個中繼資源可以震鈴響應(yīng)或者斷開，一個媒體資源可以播放和記錄。
一個資源狀態(tài)可以在兩種方法下改變：主動請求（外部事件的結(jié)果），或者資源管理器函數(shù)調(diào)用的結(jié)果。
一個主動請求狀態(tài)改變的例子是一個中繼資源在有呼叫呼入時從空閑轉(zhuǎn)換到振鈴狀態(tài)。
一個函數(shù)調(diào)用的狀態(tài)改變的例子是通過函數(shù)調(diào)用，可以使空閑的媒體資源轉(zhuǎn)到播放狀態(tài)，來響應(yīng)一個播放命令。
能夠執(zhí)行改變資源管理器資源狀態(tài)的函數(shù)被稱為命令。例如，ADL函數(shù)MediaPlay以及ADX方法PlayWave都調(diào)用了資源管理器的命令。
資源管理器嚴(yán)格遵守了如下規(guī)則：
- 每條命令都有一套指定的狀態(tài)，這些狀態(tài)可以合法的執(zhí)行命令。通常情況下，資源都是處于空閑狀態(tài)，如此命令才能夠合法執(zhí)行。同時對于大多數(shù)命令來說，每條命令只能在一種狀態(tài)下執(zhí)行（there
is only one state in which the command can be issued.）。但對于Abort和Reset命令來說，卻是例外的。
- 如果命令執(zhí)行失敗，資源的狀態(tài)不會改變。
- 如果命令執(zhí)行成功，資源的狀態(tài)馬上就會改變。對每一個命令，該狀態(tài)都是確定的，因此一旦命令執(zhí)行成功，應(yīng)用程序便無需檢查資源是否進(jìn)入給定的那個狀態(tài)。例如，如果Play函數(shù)沒有報錯，資源肯定已經(jīng)進(jìn)入播放狀態(tài)。
每個資源都是以初始狀態(tài)開始的。ADL和ADX的這種狀態(tài)對于用戶來說通常是不可見的，因此用戶通常無法在這種環(huán)境下找到資源。當(dāng)設(shè)備初始化完畢時，它進(jìn)入空閑狀態(tài)然后開始準(zhǔn)備接收命令。
對于所有類型的資源管理器資源來說，這些狀態(tài)和命令都是通用的：
- 初始狀態(tài)
- 空閑狀態(tài)
- 復(fù)位命令
- 復(fù)位狀態(tài)
- 退出命令
- 退出狀態(tài)
需要注意的是，資源管理器所定義的空閑不同于底層API所定義的"空閑"狀態(tài)。例如，在R4 API中，當(dāng)LSI設(shè)備不再進(jìn)行處理工作或者摘機(jī)時，就會被認(rèn)為是空閑狀態(tài)。如果與之相連的VOX設(shè)備正在播放或者錄音，那么則會被認(rèn)為處于"繁忙"狀態(tài)。R4
API無法跟蹤呼叫的邏輯狀態(tài)（是連接狀態(tài)還是斷開狀態(tài)），除非通過間接的途徑比如檢測當(dāng)前掛鉤開關(guān)的狀態(tài)，以及檢測線路中是否有環(huán)路電流。這種方法并不十分可靠，因為即使呼叫沒有斷開，也有可能在線路中存在短時間的脈沖電流。相反，在資源管理器中，空閑狀態(tài)意味著肯定沒有呼叫處理。一個呼叫會將繼電器資源置于連接狀態(tài)。
簡表
資源管理器簡表是一個和Windows注冊表很類似的數(shù)據(jù)庫。簡表中存儲了如下的信息：
- 按照資源掃描器的掃描結(jié)果記錄了所安裝硬件設(shè)備的詳細(xì)信息。（如下有具體描述）
- 用戶自定義的硬件配置信息，該信息是資源掃描器所無法檢測出來的
- 用戶自定義的選項，諸如缺省的話音語言（英語、西班牙語等等）
正在運(yùn)行的應(yīng)用程序（ADL和ADX）只能讀取簡表，而且必須在這些應(yīng)用程序運(yùn)行之前初始化完畢。
簡表中不存儲動態(tài)改變的信息，比如當(dāng)前設(shè)備狀態(tài)等。
簡表中的表項都有名稱和數(shù)值。表項的名稱類似于文件系統(tǒng)的路徑名。所有的名稱都是從根開始，用反斜線（\）標(biāo)明。例如，資源管理器內(nèi)部所常用的一個簡表表項是：
\TechCount=4
TechCount的數(shù)值就是這臺PC上所安裝的不同的資源管理技術(shù)的數(shù)目（一項技術(shù)就是一個特定的硬件和API的組合，比如R4
VOX）。
簡表無法存儲數(shù)值的名稱。所有數(shù)值名稱實際上都是以整數(shù)形存儲的。用于數(shù)值名稱的整數(shù)數(shù)組是預(yù)先定義好的。為了方便用戶的閱讀，系統(tǒng)提供了可顯示字符串的窗口，資源管理的功能就是將內(nèi)部存儲的整數(shù)數(shù)值轉(zhuǎn)換成可以在窗口中顯示的字符串，或者反之。這樣作可以應(yīng)用更加高效的查詢算法，因此在資源管理器應(yīng)用程序運(yùn)行之后就可以更快的訪問簡表。用來代表數(shù)值名稱的整數(shù)值有時被稱為RegIDs（注冊標(biāo)識），這是因為內(nèi)部的資源管理代碼是將簡表看作是注冊表。
和Windows注冊表不同，用戶應(yīng)用程序代碼無法直接訪問簡表，并且無法建立新的表項名稱。簡表只是供資源管理器內(nèi)部使用的。
資源掃描器
檢測已經(jīng)安裝的硬件以及驅(qū)動器的配置信息通常是很重要又很復(fù)雜的任務(wù)。傳統(tǒng)的API具有獨(dú)特的不等的功能用來查詢已經(jīng)安裝的配置信息。通常，重要的信息是無法取得的。
在資源管理器簡表中建立硬件/驅(qū)動器配置數(shù)據(jù)庫需要兩個步驟：
-
首先運(yùn)行資源掃描器，它會從可用的設(shè)備API中提取所有可用的配置信息。硬件或者驅(qū)動器配置一旦改變，就需要重新運(yùn)行資源掃描器。
-
第二步是"人工的"升級簡表。這一步是增加無法自動加入的配置信息，因此必須由用戶進(jìn)行處理。例如，對于一個E-1/R2中繼器，用戶必須指定用于R2協(xié)議的參數(shù)，這個參數(shù)是根據(jù)國家不同而不同的。對于模擬中繼器，用戶必須判斷呼叫方ID是否可用。對于T-1
CAS中繼器，用戶必須指定需要使用哪種全程呼叫協(xié)議來為PBX或者CO交換提供接口。
在運(yùn)行時建立設(shè)備掃描步驟有些困難：
- 掃描需要花費(fèi)很多時間，這會減慢應(yīng)用程序啟動的速度。在需要的時候才啟動資源掃描器，可以使應(yīng)用程序啟動得更快。
- 新版本的硬件通常會和老的API不相兼容，或者會引入新的用于配置信息的API。通過將掃描代碼和運(yùn)行代碼進(jìn)行分離，我們便可以更加容易的建立可以適應(yīng)最新軟件版本的掃描器。
特定技術(shù)接入（Technology-Specific Access）
資源管理器建立了一種較高層次的抽象，這樣應(yīng)用程序的編程就可以做到對API的透明性（比如相同的一套功能可以工作在所有支持電話的API上，也可以工作在支持各種繼電器的API之上）。只有應(yīng)用一些特定的技術(shù)才可以使用一些不常用的API。對于這樣的情況，可以通過指令或者數(shù)據(jù)識別符（RegIDs）以及命令來執(zhí)行指令或者訪問數(shù)據(jù)（比如，GetInt[get
integer value]以及SetInt[set integer value]或者布爾形以及字符串形的副本（counterparts
for Boolean and string values）的方法來調(diào)用層次較低的API。
對于電話硬件編程來說，這些功能通常是不需要的，但是對于更多高級的操作卻是可用的。該功能按照如下的描述直接轉(zhuǎn)換成硬件API功能的執(zhí)行。
舉例：為傳真操作建立重試策略：
SetInt R4GrtFaxRetryStrategy
利用這個REGID來建立
m_gfqRecord.retry_strategy API 單元
舉例：在DCB會議設(shè)備上建立數(shù)字檢測功能：
SetInt R4DcbConfEnableDigitDetection
利用這個REGID來直接訪問
dcb_setdigitmsk(handle, Confld, Value, CBA_SETMSK)API函數(shù)來實現(xiàn)數(shù)字檢測功能。
舉例：利用Global Call為數(shù)字中繼器建立設(shè)備模板（ device mask）：
SetInt R4GcEnableMask
利用這個REGID可以直接訪問帶有GCACT_ADDMSK參數(shù)的gc_SetEvtMsk API函數(shù)。
對于電話設(shè)備有300多個這樣的指定技術(shù)接入函數(shù)，對于TTS、語音識別以及聲音媒體特性則有更多這樣的函數(shù)。任何沒有被抽象倒高層API的電話操作都可以通過直接調(diào)用函數(shù)得以實現(xiàn)。
除此以外，硬件參數(shù)可以在啟動的時候設(shè)定。這就可以執(zhí)行板卡級API呼叫。這些操作所得到的結(jié)果都會被記錄到實時的記錄文件中，來幫助解決配置過程中所遇到的困難。
■ 應(yīng)用程序開發(fā)語言（ADL）
除了控制電話設(shè)備之外，計算機(jī)電話（CT）程序面臨著更多的挑戰(zhàn)。
- 多路呼叫必須一次完成。需要多任務(wù)處理的結(jié)構(gòu)
- 每個呼叫可能需要不同的對話以及工作結(jié)果。需要呼叫時的程序選擇功能。
通常程序都會運(yùn)行幾天或者幾個星期。因此設(shè)計必須是健壯的（高效的錯誤恢復(fù)，以及高密度資源）
- 硬件和軟件的安裝通常都是在遠(yuǎn)程進(jìn)行的，因此手持操作并不是永久的解決方案。
- 電話呼叫過程是一種實時性的活動，因此就需要實時的錯誤處理工具。
- Dialogic已經(jīng)實現(xiàn)了這些需求，在其指定電話語言，ADL，中有更多的描述。接下來的這部分解釋了支持復(fù)雜編程環(huán)境的一些可用的功能。
任務(wù)管理器
ADL支持多任務(wù)環(huán)境，也就是說兩個或者更多的任務(wù)可以同時執(zhí)行。即使多個任務(wù)運(yùn)行同一個應(yīng)用程序，每個任務(wù)也都有其自己的變量和數(shù)組的拷貝，同時擁有獨(dú)立的執(zhí)行路徑。在多任務(wù)處理環(huán)境中，各個任務(wù)的執(zhí)行是彼此獨(dú)立的。然而有些時候需要這些任務(wù)之間進(jìn)行合作或者相互交換信息。這可以通過信號標(biāo)識、消息以及全局變量來實現(xiàn)。
任務(wù)/中繼的配置
中繼配置程序允許用戶指定程序的哪一個功能來使用系統(tǒng)的中繼線路。當(dāng)一個運(yùn)行ADL項目時，中繼配置決定了應(yīng)該啟動哪一個應(yīng)用程序。
用戶可以為項目中的任何一個應(yīng)用程序分配一個中繼資源或者多個中繼資源。也可以根據(jù)從那些呼叫線路受到的ANI或者DNIS信息來決定應(yīng)該為程序分配哪種資源。
靜態(tài)數(shù)據(jù)
ADL中的數(shù)據(jù)區(qū)在編譯的時候是固定的。每個變量的起始位置在程序的數(shù)據(jù)區(qū)中都是固定的。這樣可以在執(zhí)行指令的時候，使ADL更加高效的定位數(shù)據(jù)。缺省情況下，ADL不會動態(tài)分配內(nèi)存。這就不需要使用垃圾收集程序，同時也避免了資源的泄漏。
TCP/IP以及DCOM通訊
利用TCP/IP或者DCOM通訊程序，ADL可以和在本地或者廣域網(wǎng)上的其他應(yīng)用程序交換信息和數(shù)據(jù)。這些工具實現(xiàn)了對任務(wù)、網(wǎng)絡(luò)狀態(tài)以及程序進(jìn)程的遠(yuǎn)程監(jiān)控。
同時，ADL包含了Windows 服務(wù)的特性，這種特性方便了遠(yuǎn)程無人監(jiān)守系統(tǒng)的修復(fù)。
符號形式的實時調(diào)試
不同的問題需要不同的解決方法。對于定位設(shè)計差錯的問題，ADL提供了符號形式的調(diào)試器。這些差錯是指控制流并不是按照我們的設(shè)計進(jìn)行的。一個指令接著一個指令運(yùn)行、檢測變量內(nèi)容以及設(shè)定斷點(diǎn)－如今所有通用而又先進(jìn)的調(diào)試技術(shù)都集成到了該開發(fā)環(huán)境中。
例如需要檢測昨天造成呼叫方在3a.m.掛機(jī)時所發(fā)生的事情，ADL會記錄一份實時的日志，該日志包含了在執(zhí)行操作期間每一個動作詳細(xì)的步驟，也包含了總結(jié)性的信息。ADL、資源管理器以及R4的事件、狀態(tài)和運(yùn)行結(jié)果都可以在1/100秒內(nèi)被捕捉下來。
◎ 過程編程
ADL語言也有函數(shù)和變量，和C或Basic差不多。
圖5: ADL程序等待一個呼叫，應(yīng)答它，播放提示，從呼叫方得到DTMF切入，最后播放基于數(shù)字集合的說明文件。
◎ 圖形編程
ADL流程圖是ADL Studio的一個組成部分，它是一個繪圖工具，可以幫助你創(chuàng)建并編輯電話應(yīng)用。你無需編寫代碼，只用在圖中插入模塊，就可在流程圖中畫出應(yīng)用。
圖6: 流程圖中的功能塊定義了在什么條件下什么序列下應(yīng)該執(zhí)行什么樣的動作。
那些模塊是預(yù)先定義的ADL庫函數(shù)，使用參數(shù)（argument）作為模塊的屬性。
圖7: 特性對話框，用于為PlayPrimpt功能塊設(shè)置提示名稱和終端數(shù)字
◎ 性能和密度
為了要達(dá)到API透明性的目標(biāo)，CT ADE加入了一個資源管理層，這樣不可避免的會引入一些開銷。但是，通過最優(yōu)化程序設(shè)計，可以使所費(fèi)開銷最小化。但現(xiàn)在，最有意義的是，應(yīng)該關(guān)注的是應(yīng)用如何管理多條通道--而不是它處理單獨(dú)一條指令流的速度有多快。
在任何應(yīng)用中，根據(jù)程序設(shè)計，CPU的使用情況有所不同：
在多個可執(zhí)行程序(一個應(yīng)用一個通道)情況下--CPU的開銷最大，因為在請求或者為每個電話狀態(tài)變化服務(wù)時，窗口必須從一個進(jìn)程（程序）切換到另一個去。
在多線程（一個進(jìn)程中的每個線程各有一個通道）--這種設(shè)計下，CPU的性能會好些，但是仍然需要操作系統(tǒng)切換線程以管理通道，
單線程狀態(tài)機(jī)（一個線程使用所有通道）--狀態(tài)的變化會即時通知線程，直接進(jìn)行處理，無需詢問操作系統(tǒng)。當(dāng)前通道的數(shù)據(jù)會被保存下來，并獲取下一通道的狀態(tài)數(shù)據(jù)，繼續(xù)處理。
但是，CPU使用效率越高，設(shè)計和實現(xiàn)起來就越困難。要想創(chuàng)建一個完整、健壯、靈活的狀態(tài)機(jī)，需要多年的努力。這也就是Dialogic提供ADL的原因，它的狀態(tài)機(jī)執(zhí)行可以控制單線程的幾百條通道。
◎ Dialogic標(biāo)準(zhǔn)結(jié)果
表1列出了一些實驗室測試和現(xiàn)場測試的實際性能結(jié)果。
這個測試中，只使用了可用的CPU時鐘周期的15％，就處理了所有的API呼叫、操作事件以及狀態(tài)轉(zhuǎn)換的管理。CPU的其余空閑可以用來處理其它的應(yīng)用如業(yè)務(wù)邏輯或者語音合成或語音識別。
用戶ADL應(yīng)用
表2中的現(xiàn)實結(jié)果顯示了ADL應(yīng)用的能力，該應(yīng)用集成了重要的業(yè)務(wù)功能。還有，如果這些應(yīng)用比你計劃創(chuàng)建的應(yīng)用簡單的話，也并非是由于限制每塊主板的密度的電話提取工作的影響。
VOS移植
ADL是VOS（語音操作系統(tǒng)）從Parity軟件（Software）派生出來的。ADL將全新的一套資源管理功能引入到了VOS中。舊的功能（sc_
，DTI_, GC_…），可以當(dāng)作是VOS遺留的功能，仍繼續(xù)可以使用，這樣就提供了后向兼容性。然而，對于新的工程來說，我們將強(qiáng)力推薦使用資源管理API。
■ 應(yīng)用開發(fā)ActiveX對象（ADX）
組件對象模型（COM）的控制，也指ActiveX對象的控制，包括了一些很有用的服務(wù)，可以將多個組件合成一個大的應(yīng)用。將復(fù)雜系統(tǒng)功能分解到面向業(yè)務(wù)的應(yīng)用中去，這種方法現(xiàn)在很常見，尤其是那些喜歡使用VB或Delphi的圖形化編程環(huán)境的開發(fā)者，常用這種方法。
上文中提到的資源管理器提供的所有電話服務(wù)，都是被封裝在構(gòu)建模塊中的，這些模塊在開發(fā)時可以看到它們的功能性（方法、參數(shù)、變量），要在操作系統(tǒng)上注冊功能性，在執(zhí)行時還要創(chuàng)建必要的對象。
圖8: 使用SDX語音方法PlayDate的VB編程，該方法提示基于COM標(biāo)準(zhǔn)的變量。
整套控件叫做ADX，包括：
編程環(huán)境
所有支持COM控件的環(huán)境也都支持ADX對象。Dialogic用的測試語言包括了C＋＋、VB、Delphi、C#以及
VB.NET。現(xiàn)場測試的報告顯示，ADE控件也可成功的應(yīng)用于JavaScript*網(wǎng)頁、Visual FoxPro*以及PowerBuilder*。還有第三方產(chǎn)品可以利用其它語音如Java*使用COM控件。
性能和密度
早期的COM對象是用微軟基類（MFC，Microsoft Foundation Classes）來寫的。這些類是為可視化對象設(shè)計的，可以廣泛支持用戶界面對話框和文檔處理。用MFC來編寫COM程序，會使得代碼冗余，COM組件會有不必要的巨大開銷。Dialogic的ADE對象使用了活動模板庫（Active
Template Library）用以取代MFC。ATL是專為COM開發(fā)設(shè)計的，可以是開發(fā)出的COM構(gòu)件腳本小而效率高。
采用與使用ADL時一樣的基準(zhǔn)來設(shè)計和配置，一個使用ADX語音控制的C＋＋多線程程序，其CPU的利用率為ADL的2倍，但是仍有70％可以給數(shù)據(jù)和其它邏輯處理使用。如果使用一個雙處理器CPU的話，這些單板的性能還會提高。
CallSuile移植
ADX是從Parity軟件的CallSuite控件的派生：VoiceBocx*、FaxBocx*、SwitchBocx*、ChatterBocx*、
MatchBocx*以及 NetHub*。雖然在8.3版當(dāng)中，字面上名字有了些變化，但是控件的名字以及他們的接口特征都是不變的。
■ 新的方向
Dialogic還可以為廣大的CT開發(fā)者作些什么呢？以下是一些Dialogic正在考慮的問題：
- 語音XML/SALT--自動語音服務(wù)使用這些標(biāo)記語言，可以更好地加強(qiáng)電話和網(wǎng)絡(luò)服務(wù)間的關(guān)系。你怎樣創(chuàng)建可視的站點(diǎn)，你就可以用同樣的技術(shù)創(chuàng)建語音服務(wù)。從Dialogic的角度來看現(xiàn)在的VoiceXML平臺，現(xiàn)在對于Dialogic來說，仍是一片待開發(fā)的處女地�？梢缘�http://www.Dialogic.com/查閱Dialogic與Microsoft聯(lián)手執(zhí)行SALT的相關(guān)情況。或者到http://www.microsoft.com去查閱"Microsoft
.NET 語音技術(shù)"。
- 視窗庫（非COM）--雖然Dialogic開發(fā)出了最具效率的COM對象，但還是可能會有一些程序設(shè)計和主機(jī)語言用C＋＋電話類庫來支持效果更好。
- Linux*--資源管理器、電話類以及ADL框架的優(yōu)勢。
請讓我們了解您使用這些產(chǎn)品的感受，以及您未來的需求。請與您的Dialogic經(jīng)銷商（http://www.Dialogic.com/）或者Dialogic產(chǎn)品經(jīng)理CT
ADE, Lyle Cowen (Lyle.Cowen@Dialogic.com; (415)
332-5656, x1310)聯(lián)系。
[ 全文英文版
]
|
