專利名稱：一種業(yè)務(wù)平臺和門戶分離的實(shí)現(xiàn)方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及電信增值業(yè)務(wù)領(lǐng)域，特別涉及一種業(yè)務(wù)平臺和門戶(Portal)分離的實(shí)現(xiàn)方法和系統(tǒng)。
背景技術(shù)：
隨著電信技術(shù)的進(jìn)步，電信行業(yè)在原有話音業(yè)務(wù)的基礎(chǔ)上，出現(xiàn)了多種類型的增值業(yè)務(wù)，包括短信業(yè)務(wù)(Short Message Service，SMS)、個性化回鈴音業(yè)務(wù)、通話背景音業(yè)務(wù)、終端振鈴下載業(yè)務(wù)、音樂下載業(yè)務(wù)、多媒體視音頻業(yè)務(wù)等。這些業(yè)務(wù)的功能特點(diǎn)是利用現(xiàn)有電信網(wǎng)絡(luò)向終端用戶提供服務(wù)，通過網(wǎng)絡(luò)設(shè)備對業(yè)務(wù)進(jìn)行管理，并向終端用戶提供業(yè)務(wù)自助服務(wù)功能；對于涉及到內(nèi)容/服務(wù)提供商(Content Provider/Service Provider，CP/SP)的業(yè)務(wù)，同時還要向CP/SP提供管理功能。提供增值業(yè)務(wù)的系統(tǒng)可劃分為業(yè)務(wù)平臺和門戶兩大部分，業(yè)務(wù)平臺多數(shù)采用瀏覽器/服務(wù)器(Browser/Server，B/S)結(jié)構(gòu)，用于實(shí)現(xiàn)具體的業(yè)務(wù)邏輯；而門戶包括業(yè)務(wù)門戶和管理門戶，管理門戶通過瀏覽器以WEB方式向運(yùn)營商、內(nèi)容提供商或服務(wù)提供商提供管理功能；業(yè)務(wù)門戶對于終端用戶提供基于無線應(yīng)用協(xié)議(WirelessApplication Protocol，WAP)、SMS、交互式語音應(yīng)答(Interactive VoiceResponse，IVR)、非結(jié)構(gòu)化對稱補(bǔ)充業(yè)務(wù)(Unstructured Supplementary ServiceData，USSD)或WEB的自助服務(wù)功能，這些業(yè)務(wù)門戶的自助服務(wù)功能基本彼此相同，只不過是提供的途徑不同，用以滿足用戶不同的使用習(xí)慣。
門戶面向最終用戶或業(yè)務(wù)管理者，客戶化要求程度高，因此對門戶的要求是業(yè)務(wù)門戶能夠讓終端用戶方便快捷地使用增值業(yè)務(wù)，并根據(jù)終端用戶的需要靈活定制業(yè)務(wù)門戶，管理門戶向業(yè)務(wù)管理者提供簡明統(tǒng)一的管理界面；業(yè)務(wù)平臺是業(yè)務(wù)邏輯的實(shí)現(xiàn)部分，要求能夠快節(jié)奏地更新業(yè)務(wù)內(nèi)容，或者對業(yè)務(wù)內(nèi)容進(jìn)行擴(kuò)展。
但現(xiàn)在的增值業(yè)務(wù)系統(tǒng)的業(yè)務(wù)平臺和門戶等通常都是由同一廠商提供，各模塊緊耦合在一起，無論是對業(yè)務(wù)平臺還是對業(yè)務(wù)門戶的改動都會涉及各個模塊的修改，因此對增值業(yè)務(wù)系統(tǒng)的更新改進(jìn)十分困難，而且成本很高；并且，各個廠家的增值業(yè)務(wù)系統(tǒng)的業(yè)務(wù)平臺和業(yè)務(wù)門戶彼此各不相同，操作方式也存在很大差異，對于終端用戶、運(yùn)營商，內(nèi)容提供商或服務(wù)提供商來說，使用起來都十分不便。
目前，運(yùn)營商還采用所謂統(tǒng)一門戶技術(shù)把多個業(yè)務(wù)的門戶集中到同一個業(yè)務(wù)門戶中。該技術(shù)主要采用超文本傳遞協(xié)議(Hypertext Transfer Protocol，HTTP)的超級連接重定向技術(shù)，對用戶提供統(tǒng)一的門戶，用戶選擇某業(yè)務(wù)后，再重定向到該業(yè)務(wù)平臺。但該技術(shù)僅僅是把不同的業(yè)務(wù)鏈接集中到同一個門戶頁面而已，并沒有從實(shí)質(zhì)上解決上述問題。
目前一些業(yè)務(wù)平臺開放部分應(yīng)用編程接口(Application ProgrammingInterface，API)供運(yùn)營商及SP/CP的系統(tǒng)調(diào)用，集成。但目前業(yè)務(wù)平臺的API開放，都是基于私有協(xié)議，沒有形成規(guī)范，不同業(yè)務(wù)平臺的API協(xié)議不同，集成工作量大。各業(yè)務(wù)平臺本身并不是基于開放技術(shù)的，僅根據(jù)廠家之間的協(xié)議對部分功能開發(fā)部分API，不能滿足業(yè)務(wù)的靈活定制需要。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的目的在于，提出一種業(yè)務(wù)平臺和門戶分離的實(shí)現(xiàn)方法，可以使業(yè)務(wù)平臺和門戶各自獨(dú)立。業(yè)務(wù)平臺對外提供應(yīng)用編程接口API，該方法包括如下步驟門戶通過調(diào)用業(yè)務(wù)平臺的API向業(yè)務(wù)平臺發(fā)送請求；業(yè)務(wù)平臺收到來自門戶的請求，將請求轉(zhuǎn)換為請求事件，并執(zhí)行與所述請求事件相應(yīng)的業(yè)務(wù)邏輯；業(yè)務(wù)平臺向門戶返回響應(yīng)信息。
所述向業(yè)務(wù)平臺發(fā)送的請求為底層傳輸協(xié)議封裝的簡單對象訪問協(xié)議SOAP消息。
所述底層傳輸協(xié)議為傳輸控制協(xié)議TCP、超文本傳輸協(xié)議HTTP或文件傳輸協(xié)議FTP。
所述向業(yè)務(wù)平臺發(fā)送的請求中包含用戶認(rèn)證信息；所述將請求轉(zhuǎn)換為請求事件之后，進(jìn)一步包括業(yè)務(wù)平臺對所述用戶認(rèn)證信息進(jìn)行認(rèn)證，認(rèn)證通過則執(zhí)行后續(xù)步驟，否則結(jié)束本流程。
所述執(zhí)行與所述請求事件相應(yīng)的業(yè)務(wù)邏輯包括業(yè)務(wù)平臺根據(jù)預(yù)先設(shè)置的請求事件與業(yè)務(wù)處理單元的映射關(guān)系，將所述請求事件發(fā)送至相應(yīng)的業(yè)務(wù)處理單元，業(yè)務(wù)處理單元根據(jù)所收到的請求事件執(zhí)行業(yè)務(wù)邏輯。
本發(fā)明的目的還在于，提出一種業(yè)務(wù)平臺和門戶分離的系統(tǒng)，可以使業(yè)務(wù)平臺和門戶各自獨(dú)立。本系統(tǒng)包括業(yè)務(wù)平臺和門戶，業(yè)務(wù)平臺用于實(shí)現(xiàn)至少一種業(yè)務(wù)功能，并對于每一個業(yè)務(wù)功能，對外提供唯一的API；門戶用于通過調(diào)用API向業(yè)務(wù)平臺發(fā)送請求，并接收來自業(yè)務(wù)平臺的響應(yīng)。
所述門戶為管理門戶或業(yè)務(wù)門戶。
所述業(yè)務(wù)門戶的具體實(shí)現(xiàn)方式為至少如下任意一種WEB門戶、交互式語音應(yīng)答IVR門戶、短信業(yè)務(wù)SMS門戶、非結(jié)構(gòu)化對稱補(bǔ)充業(yè)務(wù)USSD門戶或無線應(yīng)用協(xié)議WAP門戶。
所述管理門戶為如下任意一種業(yè)務(wù)管理點(diǎn)SMP門戶、客服門戶、業(yè)務(wù)管理接入點(diǎn)SMAP門戶或BOSS門戶。
所述業(yè)務(wù)平臺包括底層傳輸協(xié)議消息處理層，用于接收來自門戶通過底層傳輸協(xié)議發(fā)送來的SOAP消息，并將所收到的SOAP消息發(fā)送至上一層的SOAP消息處理層；還用于接收SOAP消息處理層封裝后的SOAP消息，并將該消息通過底層傳輸協(xié)議發(fā)送至門戶；SOAP消息處理層，用于將底層傳輸協(xié)議消息處理層上報的SOAP消息進(jìn)行解析，轉(zhuǎn)換為業(yè)務(wù)請求事件，并將所得業(yè)務(wù)請求事件發(fā)送至事件處理層；還用于把事件處理層返回的事件響應(yīng)消息封裝為SOAP消息，并將該消息返回至底層傳輸協(xié)議消息處理層；事件處理層，用于維護(hù)事件類型與業(yè)務(wù)處理層中的業(yè)務(wù)處理單元的映射關(guān)系；接收來自SOAP消息處理層的業(yè)務(wù)請求事件，并根據(jù)事件類型與業(yè)務(wù)處理模塊業(yè)務(wù)處理單元的映射關(guān)系，將所接收的業(yè)務(wù)請求事件轉(zhuǎn)發(fā)給業(yè)務(wù)處理層中對應(yīng)的業(yè)務(wù)處理單元；還用于接收業(yè)務(wù)處理層返回的請求響應(yīng)事件，并將請求響應(yīng)事件返回給SOAP消息處理層；業(yè)務(wù)處理層，該層由至少一個業(yè)務(wù)處理單元組成，每個業(yè)務(wù)處理單元負(fù)責(zé)完成一個具體的業(yè)務(wù)邏輯；每個業(yè)務(wù)處理單元接收對應(yīng)的業(yè)務(wù)請求事件，完成相關(guān)的業(yè)務(wù)邏輯并生成業(yè)務(wù)響應(yīng)事件，然后把業(yè)務(wù)響應(yīng)事件返回給事件處理層。
所述底層傳輸協(xié)議消息處理層為HTTP消息處理層、TCP消息處理層或FTP消息處理層。
所述業(yè)務(wù)處理層中的每一個業(yè)務(wù)處理單元包括各個業(yè)務(wù)處理單元共有的開放接口層和接口訪問控制模塊，以及自身獨(dú)有的用于實(shí)現(xiàn)業(yè)務(wù)邏輯的業(yè)務(wù)功能模塊，其中，開放接口層用于向門戶提供API；接口訪問控制模塊用于在門戶調(diào)用API時對用戶進(jìn)行認(rèn)證，認(rèn)證通過則將來自開放接口層被調(diào)用的API的相關(guān)信息透傳給業(yè)務(wù)功能模塊，并將業(yè)務(wù)功能模塊執(zhí)行相應(yīng)業(yè)務(wù)邏輯后返回的信息透傳給開放接口層。
從以上技術(shù)方案可以看出，業(yè)務(wù)平臺向外提供功能接口供門戶調(diào)用，而業(yè)務(wù)門戶和管理門戶通過調(diào)用相應(yīng)的功能接口，可以方便地集成、開發(fā)定制個性化的用戶界面，對用戶界面的修改開發(fā)工作將不需要業(yè)務(wù)平臺的更改，從而使用戶界面的開發(fā)工作輕量化；同時業(yè)務(wù)門戶部分可以通過調(diào)用不同的業(yè)務(wù)接口，增加新的服務(wù)，快速響應(yīng)市場。通過應(yīng)用本發(fā)明方案，可以實(shí)現(xiàn)業(yè)務(wù)平臺和門戶各自獨(dú)立，對業(yè)務(wù)平臺或門戶的升級不會影響系統(tǒng)其他模塊，易于實(shí)現(xiàn)系統(tǒng)升級，并且極大方便用戶的使用以及運(yùn)營商、內(nèi)容/服務(wù)提供商對系統(tǒng)的管理。


圖1為本發(fā)明系統(tǒng)的結(jié)構(gòu)示意圖；圖2為業(yè)務(wù)平臺在消息處理層面的結(jié)構(gòu)示意圖；圖3為本發(fā)明實(shí)施例門戶與業(yè)務(wù)平臺分離的架構(gòu)實(shí)現(xiàn)業(yè)務(wù)的流程圖；圖4為本發(fā)明實(shí)施例門戶與業(yè)務(wù)平臺分離的架構(gòu)實(shí)現(xiàn)管理功能的流程圖。
具體實(shí)施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚，下面結(jié)合附圖對本發(fā)明作進(jìn)一步的詳細(xì)闡述。
本發(fā)明的核心思想是將增值業(yè)務(wù)系統(tǒng)的業(yè)務(wù)平臺與門戶相互獨(dú)立，業(yè)務(wù)平臺專注于業(yè)務(wù)功能的實(shí)現(xiàn)，而業(yè)務(wù)門戶專注于業(yè)務(wù)的靈活展示，管理門戶則向增值業(yè)務(wù)系統(tǒng)的管理者展示管理功能。其中，業(yè)務(wù)平臺向外提供功能接口供門戶調(diào)用，而業(yè)務(wù)門戶和管理門戶通過調(diào)用相應(yīng)的功能接口，可以方便地集成、開發(fā)定制個性化的用戶界面，對用戶界面的修改開發(fā)工作將不需要業(yè)務(wù)平臺的更改，從而使用戶界面的開發(fā)工作輕量化；同時業(yè)務(wù)門戶部分可以通過調(diào)用不同的業(yè)務(wù)接口，增加新的服務(wù)，快速響應(yīng)市場。
按以上方式，增值業(yè)務(wù)系統(tǒng)將被劃分為各種門戶設(shè)備和業(yè)務(wù)平臺設(shè)備。各種門戶設(shè)備主要負(fù)責(zé)把業(yè)務(wù)展示給終端用戶或者向運(yùn)營商、CP/SP提供管理功能，同時運(yùn)營商、CP/SP都可以開發(fā)自己的門戶，其門戶不需要關(guān)心業(yè)務(wù)邏輯。業(yè)務(wù)平臺設(shè)備負(fù)責(zé)實(shí)現(xiàn)業(yè)務(wù)邏輯，包括門戶請求的處理，業(yè)務(wù)數(shù)據(jù)的存儲，以及業(yè)務(wù)所需網(wǎng)絡(luò)設(shè)備的交互等。
由于門戶實(shí)現(xiàn)方式的多樣性，本發(fā)明方案不提供具體的業(yè)務(wù)門戶實(shí)現(xiàn)方法，業(yè)務(wù)門戶僅需要按照增值業(yè)務(wù)平臺提供的API協(xié)議要求，正確地向業(yè)務(wù)平臺發(fā)送請求，正確地接收響應(yīng)即可。對于業(yè)務(wù)的展示，業(yè)務(wù)門戶可以根據(jù)門戶自身特點(diǎn)采用合適的實(shí)現(xiàn)方法。而且由于業(yè)務(wù)的多樣性，本發(fā)明也不提供具體業(yè)務(wù)的實(shí)現(xiàn)方法。本發(fā)明所提出的是一種門戶與業(yè)務(wù)平臺分離的架構(gòu)，以及通過這種架構(gòu)如何實(shí)現(xiàn)業(yè)務(wù)的通用流程。
圖1為本發(fā)明系統(tǒng)的結(jié)構(gòu)示意圖。業(yè)務(wù)門戶110包括至少一個運(yùn)營商業(yè)務(wù)門戶或CP/SP業(yè)務(wù)門戶，分別用于向運(yùn)營商的用戶或者CP/SP的用戶提供業(yè)務(wù)功能。管理門戶120也可包括運(yùn)營商管理門戶和CP/SP管理門戶，分別用于向運(yùn)營商或CP/SP提供管理功能。業(yè)務(wù)門戶110具體形式可以是基于WEB、IVR、SMS、USSD或WAP的門戶；管理門戶120通常是基于WEB方式，可以是業(yè)務(wù)管理點(diǎn)(Service Management Point，SMP)門戶、客服門戶、業(yè)務(wù)管理接入點(diǎn)(Service Management Access Point，SMAP)門戶或業(yè)務(wù)運(yùn)營支撐系統(tǒng)(Business & Operation Support System，BOSS)門戶。
業(yè)務(wù)門戶110或管理門戶120調(diào)用業(yè)務(wù)平臺130的開放接口層131的API來實(shí)現(xiàn)相應(yīng)的業(yè)務(wù)功能或管理，無論門戶的具體形式如何，對于相同的業(yè)務(wù)功能或管理功能僅有一個API。API以功能為單位對外提供，業(yè)務(wù)門戶110或管理門戶120僅需要調(diào)用一個API即可完成一個完整的業(yè)務(wù)功能或管理功能，而無需關(guān)心該功能的實(shí)現(xiàn)邏輯。
各種功能API都基于Web Service協(xié)議族，具體包括簡單對象訪問協(xié)議(Simple Object Access Protocol，SOAP)、Web服務(wù)描述語言(Web ServiceDescription Language，WSDL)、服務(wù)統(tǒng)一描述、發(fā)現(xiàn)、集成(UniversalDescription，Discovery and Integration，UDDI)協(xié)議。其中SOAP為API消息承載協(xié)議，WSDL為API描述協(xié)議、UDDI為服務(wù)發(fā)布協(xié)議。該協(xié)議族為開放的協(xié)議，基于HTTP和擴(kuò)展標(biāo)識語言(Extensible Markup Language，XML)技術(shù)，有專門的技術(shù)組織維護(hù)，具有廣泛的支持，開發(fā)簡單，部署迅速。該協(xié)議族是與編程語言、運(yùn)行平臺無關(guān)的。
業(yè)務(wù)平臺130用于提供至少一種業(yè)務(wù)功能，對于每個業(yè)務(wù)功能，開放接口層131中有唯一的一個API與之相對應(yīng)。為便于對業(yè)務(wù)進(jìn)行管理，業(yè)務(wù)平臺130提供至少一種管理功能，對于每一個管理功能，開放接口層131也有唯一的一個API與之相對應(yīng)。
業(yè)務(wù)平臺130包括開放接口層131、接口訪問控制模塊132以及業(yè)務(wù)功能模塊133。其中，開放接口層131用于向業(yè)務(wù)門戶110或管理門戶120提供API；接口訪問控制模塊132用于提供對API的訪問控制機(jī)制。具體地說，通過權(quán)限、角色、用戶實(shí)現(xiàn)對API的訪問控制。系統(tǒng)通過創(chuàng)建角色定義用戶類別，屬于同一個角色的用戶具有相同的訪問權(quán)限。定義角色后，通過為該角色分配接口定義該角色的權(quán)限，把某API分配給一個角色意味著增加了該角色用戶訪問該API的權(quán)限。在業(yè)務(wù)門戶110或管理門戶120調(diào)用API時需要提供用戶認(rèn)證信息；接口訪問控制模塊132根據(jù)所述用戶認(rèn)證信息判斷用戶是否合法，如果用戶合法則認(rèn)證該用戶所屬角色是否具有該API的訪問權(quán)限，若是則將來自開放接口層131被調(diào)用的API的各種信息透傳給業(yè)務(wù)功能模塊133，并將業(yè)務(wù)功能模塊133執(zhí)行相應(yīng)業(yè)務(wù)邏輯后返回的信息透傳給開放接口層131；否則拒絕該API的調(diào)用。
業(yè)務(wù)功能模塊133用于根據(jù)接口訪問控制模塊132透傳過來的來自被調(diào)用的API的信息實(shí)現(xiàn)相應(yīng)的業(yè)務(wù)邏輯。進(jìn)一步地，根據(jù)實(shí)際業(yè)務(wù)的需要，業(yè)務(wù)功能模塊133調(diào)用一個或一個以上的服務(wù)設(shè)備140來實(shí)現(xiàn)業(yè)務(wù)功能，所述服務(wù)設(shè)備140可以是獨(dú)立的設(shè)備也可以是業(yè)務(wù)功能模塊133的組成單元，若是獨(dú)立設(shè)備，則需要通過業(yè)務(wù)設(shè)備接口與之相連；服務(wù)設(shè)備140的具體形式根據(jù)業(yè)務(wù)功能而定，例如可以是數(shù)據(jù)庫或存儲器。
業(yè)務(wù)平臺130的升級保持API的向前兼容，由于門戶系統(tǒng)僅需要集成不同的功能向最終用戶提供服務(wù)，門戶系統(tǒng)僅通過SOAP消息與增值業(yè)務(wù)平臺交互，不需關(guān)心業(yè)務(wù)功能或管理功能的具體實(shí)現(xiàn)方式，因此業(yè)務(wù)平臺130升級對業(yè)務(wù)門戶110或管理門戶120無影響。
API的調(diào)用是通過IP網(wǎng)絡(luò)進(jìn)行的，門戶通過IP網(wǎng)絡(luò)請求業(yè)務(wù)平臺進(jìn)行某種操作，并向門戶作出響應(yīng)。這個過程中門戶與業(yè)務(wù)平臺進(jìn)行了消息的交互。這就需要對門戶與業(yè)務(wù)平臺之間傳送的消息格式進(jìn)行定義，同時需要能夠通過某種網(wǎng)絡(luò)協(xié)議傳送消息。SOAP協(xié)議提供了這種消息格式的定義，其格式是基于XML文本的SOAP封裝。SOAP協(xié)議建議了集中傳送SOAP消息的網(wǎng)絡(luò)協(xié)議，包括傳輸控制協(xié)議(Transmission Control Protocol，TCP)、HTTP、文件傳輸協(xié)議(File Transfer Protocol，F(xiàn)TP)等，同時SOAP是網(wǎng)絡(luò)協(xié)議無關(guān)的，即SOAP本身并不關(guān)心底層傳輸協(xié)議是什么。
本發(fā)明方案采用HTTP協(xié)議進(jìn)行SOAP消息的傳送。作為客戶端的門戶向作為服務(wù)端的業(yè)務(wù)平臺通過HTTP發(fā)送SOAP請求消息。業(yè)務(wù)平臺收到門戶的請求消息后，進(jìn)行業(yè)務(wù)處理，然后向門戶返回SOAP響應(yīng)消息，該消息同樣通過HTTP傳送給門戶。
業(yè)務(wù)平臺對收到的SOAP消息采用事件響應(yīng)模式進(jìn)行處理業(yè)務(wù)平臺首先將收到的SOAP請求消息，即一段SOAP請求XML文本進(jìn)行解析，解析后封裝為對應(yīng)的請求事件，然后對該事件進(jìn)行相應(yīng)的業(yè)務(wù)處理，處理后生成事件響應(yīng)，再把事件響應(yīng)封裝為SOAP響應(yīng)消息，即一段SOAP響應(yīng)消息XML文本，并通過HTTP協(xié)議把該響應(yīng)消息發(fā)送給門戶。
圖2所示為業(yè)務(wù)平臺在消息處理層面的結(jié)構(gòu)圖，業(yè)務(wù)平臺220自下而上分為四個層次，分別為HTTP消息處理層221，該層的軟件模塊為HTTP服務(wù)器，用于接收來自門戶210通過HTTP協(xié)議發(fā)送來的SOAP消息，并將所收到的SOAP消息發(fā)送至上一層的SOAP消息處理層222；還用于接收SOAP消息處理層222封裝后的SOAP消息，并將該消息通過HTTP協(xié)議發(fā)送至門戶210；SOAP消息處理層222，用于將HTTP消息處理層221上報的SOAP消息進(jìn)行解析，轉(zhuǎn)換為業(yè)務(wù)請求事件，并將所得業(yè)務(wù)請求事件發(fā)送至事件處理層223；還用于把事件處理層返回的事件響應(yīng)消息封裝為SOAP消息，并將該消息返回至HTTP處理層221；事件處理層223，用于維護(hù)事件類型與業(yè)務(wù)處理層224中的業(yè)務(wù)處理單元的映射關(guān)系；接收來自SOAP消息處理層222的業(yè)務(wù)請求事件，并根據(jù)事件類型與業(yè)務(wù)處理模塊業(yè)務(wù)處理單元的映射關(guān)系，將所接收的業(yè)務(wù)請求事件轉(zhuǎn)發(fā)給業(yè)務(wù)處理層224中對應(yīng)的業(yè)務(wù)處理單元；還用于接收業(yè)務(wù)處理層224返回的請求響應(yīng)事件，并將請求響應(yīng)事件返回給SOAP消息處理層；業(yè)務(wù)處理層224，該層由至少一個業(yè)務(wù)處理單元組成，每個業(yè)務(wù)處理單元負(fù)責(zé)一個具體的業(yè)務(wù)邏輯；每個業(yè)務(wù)處理單元接收對應(yīng)的業(yè)務(wù)請求事件，完成相關(guān)的業(yè)務(wù)邏輯并生成業(yè)務(wù)響應(yīng)事件，然后把業(yè)務(wù)響應(yīng)事件返回給事件處理層223。
從以上描述可以看出，圖2所示為業(yè)務(wù)平臺的垂直分層結(jié)構(gòu)，而圖1所示的業(yè)務(wù)平臺是圖2所示的分層結(jié)構(gòu)中最上面一層，即業(yè)務(wù)處理層224的平面結(jié)構(gòu)；所述業(yè)務(wù)功能單元包括各個業(yè)務(wù)處理單元共有的開放接口層和接口訪問控制模塊，以及自身獨(dú)有的用于實(shí)現(xiàn)業(yè)務(wù)邏輯的業(yè)務(wù)功能模塊。
以下以業(yè)務(wù)平臺實(shí)現(xiàn)個性化回鈴音定制業(yè)務(wù)為例，對本發(fā)明方案業(yè)務(wù)平臺與業(yè)務(wù)門戶分離時，如何實(shí)現(xiàn)業(yè)務(wù)進(jìn)行詳細(xì)闡述。業(yè)務(wù)平臺把回鈴音定制業(yè)務(wù)封裝為一個回鈴音下載API，業(yè)務(wù)門戶通過調(diào)用該API即可實(shí)現(xiàn)回鈴音定制?；剽徱粝螺dAPI包含的成員、成員含義及其設(shè)置方法如表1所示。對象定義清參考SOAP1.2協(xié)議。表1所示各項(xiàng)內(nèi)容僅為本發(fā)明應(yīng)用情況的一個具體示例，并不用以限制本發(fā)明。
業(yè)務(wù)平臺僅對外開放該API，不提供業(yè)務(wù)的任何展示。IVR/WEB/WAP等門戶向用戶展示回鈴音定制界面，當(dāng)用戶選擇定制后，業(yè)務(wù)門戶調(diào)用該API。業(yè)務(wù)門戶只需給出表1中回鈴音下載API各個成員的具體值，并將包含這些值的回鈴音下載請求發(fā)送至業(yè)務(wù)平臺。根據(jù)圖2所示的業(yè)務(wù)平臺消息處理的結(jié)構(gòu)，所述回鈴音下載請求是HTTP封裝的SOAP消息。業(yè)務(wù)平臺將所收到的SOAP消息解析后，所得各個成員組合起來即為回鈴音下載事件。業(yè)務(wù)平臺再根據(jù)回鈴音下載事件與業(yè)務(wù)處理單元的映射關(guān)系，將所得回鈴音下載事件發(fā)送給對應(yīng)的回鈴音業(yè)務(wù)單元。表1中第2和第3項(xiàng)的角色和角色代碼即為用戶認(rèn)證信息，根據(jù)角色和角色代碼的值，回鈴音業(yè)務(wù)單元判斷是否允許角色代碼對應(yīng)的用戶進(jìn)行回鈴音定制，若是則執(zhí)行回鈴音定制的業(yè)務(wù)邏輯并向業(yè)務(wù)門戶返回操作結(jié)果，所述業(yè)務(wù)邏輯包括將資源標(biāo)識或資源代碼對應(yīng)的回鈴音加入用戶個人鈴音庫，同時完成該回鈴音的計(jì)費(fèi)操作。業(yè)務(wù)平臺上述處理的各個環(huán)節(jié)若出現(xiàn)異常也向業(yè)務(wù)門戶返回結(jié)果并中斷操作。從表1中還可以看出，門戶同樣可以通過調(diào)用API的方式實(shí)現(xiàn)對業(yè)務(wù)平臺的管理功能，具體過程與實(shí)現(xiàn)業(yè)務(wù)的過程類似，故不再贅述。

表1業(yè)務(wù)平臺所返回的結(jié)果代碼如表2所示。表2所示各項(xiàng)內(nèi)容僅為本發(fā)明應(yīng)用情況的一個具體示例，并不用以限制本發(fā)明。

表2從以上所述回鈴音定制的具體實(shí)施例，可以總結(jié)出本發(fā)明提出的這種業(yè)務(wù)平臺與門戶分離的架構(gòu)下實(shí)現(xiàn)業(yè)務(wù)的流程，具體如圖3所示，包括如下步驟步驟301用戶在業(yè)務(wù)平臺提供的用戶界面上選擇業(yè)務(wù)，業(yè)務(wù)門戶向業(yè)務(wù)平臺發(fā)送業(yè)務(wù)請求。如前所述，業(yè)務(wù)門戶可以是基于WEB、IVR、SMS、USSD或WAP的門戶；業(yè)務(wù)請求的形式為TCP、HTTP或FTP等傳輸協(xié)議封裝的SOAP消息，業(yè)務(wù)請求的內(nèi)容為API的各個對象的具體值。
步驟302業(yè)務(wù)平臺收到業(yè)務(wù)請求，將業(yè)務(wù)請求轉(zhuǎn)換為業(yè)務(wù)請求事件，并根據(jù)業(yè)務(wù)請求事件與業(yè)務(wù)處理單元的映射關(guān)系，將所述業(yè)務(wù)請求事件發(fā)送至相應(yīng)的業(yè)務(wù)處理單元。
步驟303業(yè)務(wù)處理單元首先對業(yè)務(wù)請求事件中包含的用戶認(rèn)證信息進(jìn)行認(rèn)證，通過后執(zhí)行相應(yīng)的業(yè)務(wù)邏輯。
步驟304業(yè)務(wù)平臺向業(yè)務(wù)門戶返回業(yè)務(wù)響應(yīng)信息。
類似地，根據(jù)這種門戶與業(yè)務(wù)平臺分離的架構(gòu)實(shí)現(xiàn)管理功能的流程如圖4所示，包括如下步驟步驟401管理者在管理平臺提供的用戶界面上選擇管理功能，管理門戶向業(yè)務(wù)平臺發(fā)送管理請求。如前所述，管理門戶可以是SMP門戶、客服門戶、SMAP門戶或BOSS門戶。管理請求的形式為TCP、HTTP或FTP等傳輸協(xié)議封裝的SOAP消息，管理請求的內(nèi)容為API的各個對象的具體值。
步驟402業(yè)務(wù)平臺收到管理請求，將管理請求轉(zhuǎn)換為管理請求事件，并根據(jù)管理請求事件與業(yè)務(wù)處理單元的映射關(guān)系，將所述管理請求事件發(fā)送至相應(yīng)的業(yè)務(wù)處理單元。
步驟403業(yè)務(wù)處理單元首先對業(yè)務(wù)請求事件中包含的用戶認(rèn)證信息進(jìn)行認(rèn)證，通過后執(zhí)行相應(yīng)的業(yè)務(wù)邏輯。
步驟404業(yè)務(wù)平臺向管理門戶返回管理響應(yīng)信息。
圖3和圖4可以看出，這兩個流程基本上是一致的。
以上所述僅為本發(fā)明的較佳實(shí)施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)所作的任何修改、等同替換和改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種業(yè)務(wù)平臺和門戶分離的實(shí)現(xiàn)方法，其特征在于，業(yè)務(wù)平臺對外提供應(yīng)用編程接口API，該方法包括如下步驟門戶通過調(diào)用業(yè)務(wù)平臺的API向業(yè)務(wù)平臺發(fā)送請求；業(yè)務(wù)平臺收到來自門戶的請求，將請求轉(zhuǎn)換為請求事件，并執(zhí)行與所述請求事件相應(yīng)的業(yè)務(wù)邏輯；業(yè)務(wù)平臺向門戶返回響應(yīng)信息。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述向業(yè)務(wù)平臺發(fā)送的請求為底層傳輸協(xié)議封裝的簡單對象訪問協(xié)議SOAP消息。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述底層傳輸協(xié)議為傳輸控制協(xié)議TCP、超文本傳輸協(xié)議HTTP或文件傳輸協(xié)議FTP。
4.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述向業(yè)務(wù)平臺發(fā)送的請求中包含用戶認(rèn)證信息；所述將請求轉(zhuǎn)換為請求事件之后，進(jìn)一步包括業(yè)務(wù)平臺對所述用戶認(rèn)證信息進(jìn)行認(rèn)證，認(rèn)證通過則執(zhí)行后續(xù)步驟，否則結(jié)束本流程。
5.根據(jù)權(quán)利要求1至4任一項(xiàng)所述的方法，其特征在于，所述執(zhí)行與所述請求事件相應(yīng)的業(yè)務(wù)邏輯包括業(yè)務(wù)平臺根據(jù)預(yù)先設(shè)置的請求事件與業(yè)務(wù)處理單元的映射關(guān)系，將所述請求事件發(fā)送至相應(yīng)的業(yè)務(wù)處理單元，業(yè)務(wù)處理單元根據(jù)所收到的請求事件執(zhí)行業(yè)務(wù)邏輯。
6.一種業(yè)務(wù)平臺和門戶分離的系統(tǒng)，包括業(yè)務(wù)平臺和門戶，其特征在于，業(yè)務(wù)平臺用于實(shí)現(xiàn)至少一種業(yè)務(wù)功能，并對于每一個業(yè)務(wù)功能，對外提供唯一的API；門戶用于通過調(diào)用API向業(yè)務(wù)平臺發(fā)送請求，并接收來自業(yè)務(wù)平臺的響應(yīng)。
7.根據(jù)權(quán)利要求6所述的系統(tǒng)，其特征在于，所述門戶為管理門戶或業(yè)務(wù)門戶。
8.根據(jù)權(quán)利要求7所述的系統(tǒng)，其特征在于，所述業(yè)務(wù)門戶的具體實(shí)現(xiàn)方式為至少如下任意一種WEB門戶、交互式語音應(yīng)答IVR門戶、短信業(yè)務(wù)SMS門戶、非結(jié)構(gòu)化對稱補(bǔ)充業(yè)務(wù)USSD門戶或無線應(yīng)用協(xié)議WAP門戶。
9.根據(jù)權(quán)利要求7所述的系統(tǒng)，其特征在于，所述管理門戶為如下任意一種業(yè)務(wù)管理點(diǎn)SMP門戶、客服門戶、業(yè)務(wù)管理接入點(diǎn)SMAP門戶或BOSS門戶。
10.根據(jù)權(quán)利要求6所述的系統(tǒng)，其特征在于，所述業(yè)務(wù)平臺包括底層傳輸協(xié)議消息處理層，用于接收來自門戶通過底層傳輸協(xié)議發(fā)送來的SOAP消息，并將所收到的SOAP消息發(fā)送至上一層的SOAP消息處理層；還用于接收SOAP消息處理層封裝后的SOAP消息，并將該消息通過底層傳輸協(xié)議發(fā)送至門戶；SOAP消息處理層，用于將底層傳輸協(xié)議消息處理層上報的SOAP消息進(jìn)行解析，轉(zhuǎn)換為業(yè)務(wù)請求事件，并將所得業(yè)務(wù)請求事件發(fā)送至事件處理層；還用于把事件處理層返回的事件響應(yīng)消息封裝為SOAP消息，并將該消息返回至底層傳輸協(xié)議消息處理層；事件處理層，用于維護(hù)事件類型與業(yè)務(wù)處理層中的業(yè)務(wù)處理單元的映射關(guān)系；接收來自SOAP消息處理層的業(yè)務(wù)請求事件，并根據(jù)事件類型與業(yè)務(wù)處理模塊業(yè)務(wù)處理單元的映射關(guān)系，將所接收的業(yè)務(wù)請求事件轉(zhuǎn)發(fā)給業(yè)務(wù)處理層中對應(yīng)的業(yè)務(wù)處理單元；還用于接收業(yè)務(wù)處理層返回的請求響應(yīng)事件，并將請求響應(yīng)事件返回給SOAP消息處理層；業(yè)務(wù)處理層，該層由至少一個業(yè)務(wù)處理單元組成，每個業(yè)務(wù)處理單元負(fù)責(zé)完成一個具體的業(yè)務(wù)邏輯；每個業(yè)務(wù)處理單元接收對應(yīng)的業(yè)務(wù)請求事件，完成相關(guān)的業(yè)務(wù)邏輯并生成業(yè)務(wù)響應(yīng)事件，然后把業(yè)務(wù)響應(yīng)事件返回給事件處理層。
11.根據(jù)權(quán)利要求10所述的系統(tǒng)，其特征在于，所述底層傳輸協(xié)議消息處理層為HTTP消息處理層、TCP消息處理層或FTP消息處理層。
12.根據(jù)權(quán)利要求10所述的系統(tǒng)，其特征在于，所述業(yè)務(wù)處理層中的每一個業(yè)務(wù)處理單元包括各個業(yè)務(wù)處理單元共有的開放接口層和接口訪問控制模塊，以及自身獨(dú)有的用于實(shí)現(xiàn)業(yè)務(wù)邏輯的業(yè)務(wù)功能模塊，其中，開放接口層用于向門戶提供API；接口訪問控制模塊用于在門戶調(diào)用API時對用戶進(jìn)行認(rèn)證，認(rèn)證通過則將來自開放接口層被調(diào)用的API的相關(guān)信息透傳給業(yè)務(wù)功能模塊，并將業(yè)務(wù)功能模塊執(zhí)行相應(yīng)業(yè)務(wù)邏輯后返回的信息透傳給開放接口層。
全文摘要
本發(fā)明公開了一種業(yè)務(wù)平臺和門戶分離的實(shí)現(xiàn)方法，業(yè)務(wù)平臺對外提供應(yīng)用編程接口API，該方法包括如下步驟門戶通過調(diào)用業(yè)務(wù)平臺的API向業(yè)務(wù)平臺發(fā)送請求；業(yè)務(wù)平臺收到來自門戶的請求，將請求轉(zhuǎn)換為請求事件，并執(zhí)行與所述請求事件相應(yīng)的業(yè)務(wù)邏輯；業(yè)務(wù)平臺向門戶返回響應(yīng)信息。本發(fā)明還提出了一種業(yè)務(wù)平臺和門戶分離的系統(tǒng)。通過應(yīng)用本發(fā)明方案，可以實(shí)現(xiàn)業(yè)務(wù)平臺和門戶各自獨(dú)立，對業(yè)務(wù)平臺或門戶的升級不會影響系統(tǒng)其他模塊，易于實(shí)現(xiàn)系統(tǒng)升級，并且極大方便用戶的使用以及運(yùn)營商、內(nèi)容/服務(wù)提供商對系統(tǒng)的管理。
文檔編號H04W88/18GK1909685SQ20061010332
公開日2007年2月7日 申請日期2006年7月18日 優(yōu)先權(quán)日2006年7月18日
發(fā)明者胡小清, 黃崇輝 申請人:華為技術(shù)有限公司