摘   要： 本文研究如何利用交易中間件BEA TUXEDO構建一種交互式的電信自助服務平臺，重點介紹了業務邏輯層的設計和交互式功能的設計與實現，提出了一種基于服務時間和業務熟悉程度相結合的多隊列機制來實現坐席分配。
關鍵詞： TUXEDO  交互式  自助服務  電信

　　中國電信業作為國家的支柱產業，在近幾年得到了迅猛的發展，用戶數量尤其是移動用戶迅速增長。在日益激烈的市場競爭環境下，電信運營企業的服務內容、服務方式、服務對象、服務質量、服務意識等，都發生了歷史性的深刻變化。為了保持和增強企業的競爭力，必須提高客戶的滿意度，為客戶提供更多、更好、更方便的服務渠道，通過提高服務質量留住用戶和吸引用戶。
　　目前，國內電信行業自助服務系統正處于起步階段。系統規模小，通常采用Client/Server結構的二層或三層模式。自助服務終端通過系統前置機與電信運營商業務系統連接，有的甚至將自助服務終端直接與電信運營商業務系統進行通信。采用這種模式的自助服務系統的網絡通信需要開發人員自己編寫函數實現，從而產生系統開發難度大、可靠性低、通信瓶頸和客戶端肥大等問題；另一方面，其實現的功能比較簡單，只能夠辦理用戶詳單、話單的查詢和打印、話費繳納、銷售電話卡等基本業務。
　　交互式電信業務自助服務平臺的建設是電信運營企業為向客戶提供更優質的服務所采取的措施之一。它通過在原有的自助服務系統的基礎上增加網絡視頻會議的功能，使自助服務平臺增加了對綜合電信業務辦理的支持，真正體現了創造需求、引導消費的現代客戶服務理念。
1  平臺的設計
　　交互式自助服務平臺中系統間的通信借助TUXEDO的API函數來實現，客戶端與服務端的數據通過數據緩沖區實現。當客戶端與服務端進行通信時，只需調用相應的API函數即可完成通信，從而有效地解決現有的自助服務系統中存在的交易通信問題。同時借助TUXEDO提供的多機模式和負載均衡功能可以很好地解決通信瓶頸問題。
1.1 平臺的網絡拓撲結構
　　交互式自助服務平臺采用分布式三層體系結構：表示層、業務邏輯層和數據層。表示層包括交互式自助服務終端、客戶服務中心、管理終端以及Web服務器。表示層將用戶的功能請求轉化為業務邏輯層能夠識別的數據請求格式并提交給應用層，然后從應用層獲取返回數據并用某種方式展現給用戶，平臺的業務邏輯處理對于表示層而言是透明的；業務邏輯層是平臺的核心，主要完成服務的封裝，包括將從交易數據庫或電信運營商業務系統獲取用戶的業務數據封裝后返回給表現層以及與銀行結算中心的對賬業務操作，它由主服務器、備份服務器和服務器1～n組成。完成業務邏輯處理的各個服務分布在服務器1～n中。主服務器負責協調它們之間的運行，在這些服務器之間平衡負載和容錯處理，同時主服務器與外部接口相連，完成協議轉換服務器的功能。當主服務器出現異常而停止工作時，備份服務器將啟動充當主服務器；數據層由交易數據庫和外部接口組成，主要為平臺提供數據。平臺的網絡拓撲結構如圖1所示。

1.2 業務邏輯層的設計
1.2.1 服務的劃分
　　在TUXEDO應用系統服務端中把業務邏輯劃分成一個個獨立的服務(Serviece)，把多個服務按一定的規則綁定到一個Server中，客戶端調用這些服務來實現相應的操作，所以服務端的主要任務就是編寫一個個的服務。交互式自助服務平臺業務邏輯層主要的業務邏輯處理有：管理終端對交易數據操作的請求；交互式自助服務終端辦理常規業務的請求；交互式功能實現時所涉及到的坐席申請、分配、狀態更新的請求。Web服務器請求的服務為第二種請求的子集。對于第一種請求，主要是對交易數據庫進行查詢、更新、刪除、插入等操作，因此，可以劃分兩個Service：DataQuery(數據查詢)和DataControl(數據操縱)，并綁定到進程(Server)Sys_Server中；第二種請求是平臺業務處理中最為頻繁的，主要包括用戶身份驗證、話費繳納、賬單查詢、話費詳單查詢、業務受理等。出于系統安全性和靈活性以及上述服務劃分、綁定原則的考慮，這里采用二個進程Term_Imprest和Term_Server來實現第二種請求。Term_Imprest有一個服務Multi_Imprest，實現用戶繳費的業務處理；Term_Server劃分為二個服務：Multi_Service和Multi_Request。Multi_Request實現業務邏輯層與電信運營商業務系統前置機之間的數據通信，Multi_Service實現自助服務終端用戶業務請求邏輯，不同的業務通過交易編碼(系統自定義參數)來區分。之所以將繳費繳納單獨采用一個進程處理，是因為在具體運行中經常需要關閉繳費功能但同時保證其他業務能正常辦理。針對這種情況，管理維護人員只需將業務邏輯層中的Term_Imprest進程關閉即可，其他業務仍然可以照常辦理；第三種請求主要是輔助交互式功能的實現。對于這種請求，業務邏輯層相當于一個坐席中轉服務程序，它劃分為三個服務：Query_Seat(坐席狀態查詢)，Update_Seat(坐席狀態更新)，Apply_Seat(申請坐席)，并綁定到進程(Server)Seat_Server中。
1.2.2 坐席的分配
　　在交互式自助服務平臺中，交互式業務類型有多種，每種類型需要的服務時間各不相同。因此，本文采用基于服務時間和業務熟悉程度相結合的多隊列機制來實現坐席分配。
　　每一種交互式業務對應一個坐席隊列，業務邏輯層從自助服務終端業務請求隊列中按照FCFS的原則取出一個請求，然后從對應的坐席隊列中取出服務時間和業務熟悉程度加權和最大的坐席分配給請求自助服務終端。加權計算方法為：服務時間×服務因子＋業務熟悉程度×業務因子。服務因子與服務時間成反比，服務時間越長，服務因子越小；業務因子與業務熟悉程度成正比，業務越熟悉，業務因子就越大。坐席在辦完一次業務后，服務時間增加，業務熟悉程度增加，同時也將導致服務因子減小和業務因子的增大。通過這種方式，能有效地均衡坐席的服務強度。采用多隊列的方式相比，單個隊列方式能有效地提高效率和系統吞吐量。因為多隊列方式中，每個坐席只需負責一種服務，其熟練程度要大于一個坐席負責多種服務，才能降低出錯的可能，而且采用多隊列機制也不會因為一種服務受阻而影響其他服務的辦理。坐席分配示意如圖2所示。

　　圖2中S表示服務時間，F表示業務熟悉程度，Factor_S表示服務因子，Factor_F表示業務因子。
1.2.3 數據通信的設計
　　交互式自助服務平臺的數據通信是平臺運行的關鍵，它是將平臺各個部分銜接起來的橋梁和紐帶，而業務邏輯層是平臺通信的樞紐。業務邏輯層的通信主要有二種模式：(1)表示層為獲取數據而與業務邏輯層之間的通信。(2)業務邏輯層為獲取用戶所需的業務數據而與數據層的電信運營商業務系統前置機之間的通信。
　　第一種通信模式是平臺的主要通信方式，它借助于BEA TUXEDO中間件來實現。本文采用會話方式來實現表示層與業務邏輯層之間用戶詳單文件的傳輸。表示層調用tpconnect( )函數主動與業務邏輯層建立連接，之后業務邏輯層作為發送者調用tpsend( )函數向請求的表示層發送數據，表示層作為接收者調用tprec( )函數接收邏輯層發送的詳單數據。當數據傳送完畢，由表示層關閉連接。從連接建立到連接關閉，表示層與業務邏輯層之間連接一直保留，可以多次實現數據傳輸。采用Q/方式來實現交互式功能中的坐席分配。Q/方式有二種模式：基本模式和轉發模式。基本模式適用于客戶機對客戶機，而轉發模式適用于客戶機對服務器。前者主要用于兩者之間交換數據，在坐席分配實現中采用轉發模式。表示層將坐席請求發送到消息隊列中，業務邏輯層收到消息后轉發給相應的處理進程進行處理，處理完畢之后，由表示層從消息隊列中取出處理結果。采用同步請求/回答方式來處理第一種通信方式中剩余的表示層與業務邏輯層之間的通信，這種通信方式比較簡單。表示層在調用相應的服務后處于阻塞狀態，等待業務邏輯層的處理結果或者超時退出之后才繼續往下執行。
　　第二種通信模式中，業務邏輯層主要實現協議轉換的功能。這種方式中，邏輯層充當了電信運營商業務系統前置機的客戶端，它向電信運營商業務系統業務提出業務請求，并接收電信運營商業務系統業務的響應。這種通信方式的實現要視電信運營商業務系統提供的接口而定。
1.3 表示層的功能設計
　　表示層主要是為系統使用者提供多樣化的界面邏輯，將從業務邏輯層獲取的數據展現給用戶，因此表示層側重于功能的設計。表示層由自助服務終端、客戶服務中心、管理終端、Web服務器組成。交互式自助服務終端是平臺中直接與用戶交互的部分，它將用戶的業務請求提交給業務邏輯層，并將業務邏輯層返回的數據直觀地展現給用戶，同時提供用戶與客戶服務中心坐席交互的功能。由于自助服務要求用戶能在無人指導的情況下在自助設備上完成業務操作，因此，交互式自助服務終端要充分考慮各種階層的使用者，要有人性化的操作界面。如用生動的圖形動畫、文字說明及豐富的聲音來提示、引導客戶進行自助操作；操作流程要簡單、明了、無二義性，使客戶能簡單、直觀地完成操作；容錯性能好，能處理各種正常或異常情況，使客戶放心操作。
　　終端管理系統主要實現實時監控自助服務終端運行狀況、交易狀況、系統故障和對交易數據進行管理，使管理人員能隨時準確地了解平臺的運行狀況，從而能根據終端運行情況采取相應的措施，保證平臺能24小時穩定、正常地運行。終端管理系統由系統管理、終端管理、終端查詢、坐席管理、報表管理、門禁系統管理6個子系統組成。
Web服務器主要用來實現平臺的Web功能，擴大平臺的應用范圍，實現平臺的電子商務功能，從而實現原有的自助服務系統與電子商務平臺的有機結合。Web服務器采用Bea公司的另一旗艦產品Weblogic Server實現，通過Bea公司的Jolt產品或者Wtc產品可以實現TUXEDO與Weblogic之間的互連。Web服務器實現的功能和自助服務終端相同，只是數據展現方式不同。
　　客戶服務中心通過與自助服務終端進行音、視頻的交互，與用戶一起完成綜合電信業務的辦理。
1.4 交互式功能的設計與實現
　　平臺的交互式功能通過網絡視頻會議系統實現。在實現過程中需要進行視頻、音頻、文件、數據傳輸。在交互式平臺中采用實時流傳輸技術實現視頻、音頻信號的傳輸，文件和數據的傳輸則通過基于TCP/IP協議的套接字通信實現。由于視頻流和音頻流數據量大，因此在平臺實現中協議的選擇是實現實時多媒體流傳輸的關鍵。圖3給出了交互式平臺中實現視頻會議功能時所采用的協議體系結構。

　　應用層中的視頻、音頻、文件、數據被傳送至傳輸層，傳輸層通過UDP的無連接方式或TCP有連接方式再傳送到IP層。
　　視頻流的網絡傳輸一般分為采集、壓縮、傳輸三個步驟。圖像和視頻的采集是視頻技術應用的關鍵前提。本文采用“攝像頭＋采集卡”的方法實現圖像序列的采集。用這種方式實現視頻信號的采集和傳輸具有圖像質量高、丟幀率低、畫面抖動小的優點。視頻的壓縮和傳輸利用采集卡廠商提供的SDK函數實現。在局域網內實現交互式自助服務平臺時，對視頻幀的傳輸進行測試。在建立連接后的25秒內采集的視頻幀數逐漸、平滑地上升，之后基本保持在24幀/秒。在視頻的傳輸過程中丟幀率僅為0.06%。
　　音頻信號的網絡傳輸相對于視頻信號而言要容易，可以采用Windows提供的音頻服務來實現音頻信號的采集、壓縮、傳輸。Windows通過高級音頻函數、媒體控制接口(MCI)設備驅動程序，低級音頻函數MIDI Maper、低級音頻設備驅動以及DirectX技術提供了音頻服務。由于采用DirectX技術容易實現音頻信號的網絡傳輸，因此這里采用DirectX技術來采集和傳輸音頻信號，并采用基于TCP協議的點對點通信方式。
　　數據和文件的傳輸最為簡單，兩者都采用基于TCP協議的套接字進行傳輸。在傳輸文件前先先將文件轉換為數據流，接收方接收到數據流后再將數據流轉換為文件。由于在通信過程中需要傳輸的文件和數據都很少，因此采用這種傳輸方式的優點是操作簡單、容易控制。
2  平臺的實現
　　交互式自助服務平臺借助TUXEDO中間件實現。業務邏輯層通過編寫若干個服務來完成；表示層通過調用業務邏輯層的服務來實現自身的功能。業務邏輯層的服務程序采用C語言編寫；表示層中的終端管理系統采用C++Builder實現；交互式自助服務終端和客戶服務中心坐席系統采用Visual Basic實現；交易數據庫采用Microsoft SQL SERVER 2000數據庫系統；表示層與業務邏輯層之間的通信緩沖區采用FML類型。
　　以下分別給出業務邏輯層和表示層實現的抽象描述。業務邏輯層實現Term_Serve進程，表示層調用Term_Serve進程中的Multi_Service服務實現業務辦理功能。
　　

3  總  結
　　本文針對現有自助服務系統在實際運行過程中存在的問題，采用TUXEDO中間件實現業務邏輯的處理和系統網絡通信，提高了系統的可靠性和可擴展性，并增加音、視頻交互功能，增加對綜合電信業務辦理的支持。在描述基于中間件的交互式自助服務平臺過程中，重點介紹了業務邏輯層的設計和交互式功能的設計與實現，提出了一種基于服務時間和業務熟悉程度相結合的多隊列機制來實現坐席分配。交互式自助服務平臺的實現對于增強競爭力具有很重要的意義。
參考文獻
1   羅會蘭，謝小兵.多層分布式體系技術在電信觸摸屏多媒體查詢系統中的應用.微型機與應用，2004；(1)
2   張海林，趙錦蓉，莊永宙.Multimedia Conferencing System and Multicasting.清華大學學報，1999；4(2)
3   于海燕，張霞.基TUXEDO中間件的郵政電子化支局生產作業系統的設計與實現.計算機系統應用，2003；(7)
4   郭亞，劉曉晴.基于Web技術的自助服務開發平臺.中國金融電腦，2003；(12)