請教各位：CTI IVR領域該應用那些設計模式？

westant發表於2007-02-26
VR設計模式
一個呼叫中心的IVR系統，該用什麼模式呢？ ivr系統應該是一個狀態機模型，裡面充斥著各種線路控制的狀態和事件（空閒，震鈴，掛機，放音，錄音，加入會議，離開會議，兩通道連線。。。。。）不過總的來說，線路部分的狀態和事件不會很多，並且是不會經常變化的，可以看成是固定的就那幾個。 然後，做應用的時候，業務邏輯引入的自定義狀態就不可預料了。如何進行解耦？如何保證底層線路控制部分的純潔不被業務邏輯所破壞？IVR系統是一個實時性要求很高的系統，同時也是一個併發量很高的系統（絕對不能用一個通道一個執行緒的方法，只能用狀態機輪詢）。IVR系統的底層可以是各個廠家的語音卡，可以是各個廠家的交換機，可以是來自IP的呼叫，甚至是簡訊，郵件等各種資源。這些應該要和業務邏輯完全分離。 我設想的是用分散式的程式來解耦。外圍的線路資源（如語音板卡）做成獨立的一個程式，不參與業務邏輯，做成一個只會做事，而不知道為什麼做的“傻瓜”。 業務邏輯單獨也是一個程式，和資料庫打交道的也單獨做成一個程式。。。。這樣，處理業務邏輯的程式就是一個依照業務邏輯發號命令，但是不知道如何具體實現這些命令的人（COMAND模式？），其他的各類資源閘道器都和這個業務程式打交道，各資源閘道器彼此之間不打交道（中介模式？）。 如此思路下，那麼一個業務流程的執行就大概如下了： 業務程式執行流程，發現需要對使用者放音，就發個包（SOCKET通訊）給板卡程式，發現需要執行一個儲存過程，就發個包給資料庫程式，發現需要發條簡訊，就發個包給簡訊程式，發現需要做****,就發個包給&&&&. 這樣，板卡程式就只管聽命令，對指定的通道放音，錄音，加入會議之類。然後把底層線路的變化事件發包給業務程式，資料庫程式也是，只管按要求執行儲存過程，然後把結果發包給業務程式，簡訊。。。。等等。這樣，整個系統就很容易擴充了，並且外圍的程式也很容易編寫，用三匯卡，就作個三匯卡函式封裝的板卡程式，用AVAYA交換機，就做個對應的交換機程式。要IP應用，就做個IP閘道器程式等等。 然後，問題就是，這個最核心的業務程式怎麼設計啊？該用那些模式來例項化業務流程？如何維護每個例項的狀態？等等，期待大家的討論，謝謝

相關文章