【文章內容簡介】 CMPP_DELIVER_RESP 消息回應。 2. SP 與 ISMG 之間的連接方式 現(xiàn)階段，要求 ISMG 之間必須采用長連接的通信方式， 長連接方式如下： 通信雙方以客戶 服務器方式建立 TCP 連接，用于雙方信息的相互提交。當信道上沒有數(shù)據(jù)傳輸時，通信雙方應每隔時間 C發(fā)送鏈路檢測包以維持此連接，當鏈路檢測包發(fā) 出超過時間 T后未收到響應，應立即再發(fā)送鏈路檢測包，再連續(xù)發(fā)送 N1 次后仍未得到響應則斷開此連接。 參數(shù) C、 T、 N原則上應可配置，現(xiàn)階段建議取值為： C=3分鐘， T=60 秒， N=3。 網(wǎng)關與 SP 之間、網(wǎng)關之間的消息發(fā)送后等待 T 秒后未收到響應，應立即重發(fā)，再連續(xù)發(fā)送 N1 次后仍未得到響應則停發(fā)?，F(xiàn)階段建議取值為： T=60 秒，N=3。 消息采用并發(fā)方式發(fā)送，加以滑動窗口流量控制，窗口大小參數(shù) W可配置，現(xiàn)階段建議為 16，即接收方在應答前一次收到的消息最多不超過 16條。 長連接的操作流程舉例如圖 7所示： 圖 7 長連接操作流程圖 與 DSMP 由于全時通業(yè)務是 SP 與移動合作的收費業(yè)務，收費是由移動帶收，所以必 . . . . . . 建立 TC P 連接 滑 動窗口不大于 W W CMPP 消息 1 客戶端 服務器端 CMPP 消息 2 對 CMPP 消息 1 的響應 對 CMPP 消息 2 的響應 鏈路檢測包 鏈路檢測包響應 建立 TCP 連接 鏈路檢測包 鏈路檢測包響應 拆除 TCP 連接 . . . . . . 建立 TC P 連接 須使得 SP 與 DSMP（ ）之間定購關系同步（該功能通過 Provision 接口規(guī)范 來完成 ）。 4 Provision 接口規(guī)范定購技術介紹 機主短信留言功能的實現(xiàn)必須通過用戶使用短信的方式自己定制與退定，而短信的定購就必須通過 Provision 接口規(guī)范的定購，才能與 DSMP 平臺聯(lián)系起來。因此， Provision 接口規(guī)范的定購是用戶通過短信定制機主短信留 言功能所必須的一項技術。 Provision 接口規(guī)范 Provision 接口 規(guī)范 是用來實現(xiàn) DSMP（ 是數(shù)據(jù)業(yè)務的管理核心平臺 ,完成數(shù)據(jù)業(yè)務的業(yè)務管理和控制功能 ） 和 SP 之間定購關系同步， DSMP 通過該接口進行定購關系同步和在用戶自助服務時設置定購服務相關的屬性，比如暫停、取消業(yè)務等，它是基于 HTTP/XML 格式的消息交互模式 。 SP在實現(xiàn)接口改造時必須對 DSMP通過該接口傳過去的所有用戶狀態(tài)改變信息都要做對應的處理，比如 BOSS 暫停、 BOSS 開機、用戶取消、暫停等等，否則會引起 MISC 和 SP 雙方定購關系不同步 ，引起不必要的費用糾紛 。 另外，目前 MISC 平臺可以對所有 SP 實現(xiàn)反向取消業(yè)務的功能，但是必須要求 SP 先實現(xiàn)反向 Provision 定購關系同步接口功能 。 正反向定購 Provision 接口規(guī)范 正向定購 Provision 接口規(guī)范 流程說明 ： SP 特服號 MO(Mobile Originate)消息向 MISC 發(fā)起 MO 鑒全批價 收到 MO 鑒全批價請求后進行定購、點播指令匹配 ，則 MISC 會向 SP 發(fā)送訂購關系同步請求SyncOrderRelationReq 收到同步請求后，對這個定購請求做相應的定購關系處理，并返回訂購關系同步應答 SyncOrderRelationResp 收到響應后在系統(tǒng)里面生成正式的定購關系，并且由系統(tǒng)自動產(chǎn)生一條定購成功的提醒消息發(fā)給用戶 反向定購 Provision 接口規(guī)范 SP MISCSubscribeServiceReq接入鑒權用戶鑒權業(yè)務鑒權SyncOrderRelationReqSyncOrderRelationResp出包月話單、生成訂購關系SubscribeServiceResp 圖 8 反向定制圖 流程說明 ： 收到用戶的定購請求后，向 MISC 發(fā)起訂購請求 SubscribeServiceReq，并等待 MISC 處理 響應消息 對消息中的業(yè)務鑒權接入鑒權，判斷該業(yè)務是否允許進行反向訂購 ，判斷用戶狀態(tài)是否正確以及是否是重復定購等 向 SP 發(fā)送訂購關系同步請求 SyncOrderRelationReq 收到同步請求后，對這個定購請求做相應的定購關系處理，并返回訂購關系步應答 SyncOrderRelationResp 收到響應后在 MISC 里面生成正式的定購關系，并返回 SP 反向定購處理響應 SubscribeServiceResp ，如果響應正確則轉到 8 MISC 的錯誤響應，則說明定購失敗， SP 必須對這個失敗消息做相應處理，比如把生成的定購關系清除 MISC 的正確響應，則 SP 可以不做任何處理 簡介 作為唯一一個完全符合中國移動集團公司 DSMP 數(shù)據(jù)業(yè)務管理規(guī)范 的產(chǎn)品，它能夠支撐多種數(shù)據(jù)業(yè)務模式，包括 wap、 sms、 pda、 kjava、 mPic 等，完成代理訪問、用戶及定購關系鑒全批價、 SP 定購關系同步、 SSO 網(wǎng)站登錄等功能，同時還支持各種業(yè)務管理、客戶投訴處理、數(shù)據(jù)報表等功能 。 5 機主留言功能的設計與實現(xiàn) 核心數(shù)據(jù) 庫表 表 1 被叫用戶表（即具有機主留言功能的機主表 lh_ps_userinfo）： Name Null？ Type ID NOT NULL NUMBER(12) PSMOBILE VARCHAR2(20) PAUSESERVICE NUMBER(2) MSG VARCHAR2(200) DURATION NUMBER SEDTIME DATE 表 2 臨時接口表（ lh_interface）： Name Null？ Type ID NOT NULL NUMBER(12) TYPE VARCHAR2(20) TYPEVALUE VARCHAR2(200) “全時通”系統(tǒng)接口的實現(xiàn) 全時通系統(tǒng)獲得用戶的短消息都是通過移動的固定接口（ Provision 接口 ），因此全時通系統(tǒng)也有相應的接口（該接口命名為 SPprovision 接口）與移動接口對應。 用戶的定制、取消、暫停等行為都要求全時通系統(tǒng)與移動同步，因此必須保證相關的接口與數(shù)據(jù)庫和內存同步。那么 SPprovision 接口是怎么實現(xiàn)的呢？ 為了實現(xiàn)同步關系，用戶的定制、取消短信都是通過 Provision 接口 傳送到SPprovision 接口 上，然后全時通系統(tǒng)再對短信信息進行處理，步驟如下： SMMO（ Short Message Mobile Originate） 正向定購 SP的業(yè)務時，MISC收到定購請求后通過正向同步 Provision接口向 SP發(fā)起定購關系同步請求 收到同步請求后經(jīng)過處理返回正確的響應，如果由于 SP 的網(wǎng)絡原因未給 MISC 響應，那么 MISC 會在一定時間重發(fā)三次，一般是 30 秒一次 收到 SP 的 Provision 響應后開始處理定購，如果響應錯誤則返回定購失敗，否則返回處理成功 同時 針對特殊業(yè)務需要 通過反向定購時， SPprovision 接口 首先響應， SP發(fā)起 Provision 反向定購請求， MISC 收到后按照正向流程向 SP發(fā)起正向同步請求，完成定購同步 。 數(shù)據(jù)庫連接技術 由于機主留言功能是在已有的“全時通”系統(tǒng)上開發(fā)設計，所以，其數(shù)據(jù)庫也是建立在“全時通”系統(tǒng)的數(shù)據(jù)庫中。正是由于數(shù)據(jù)庫建在已有系統(tǒng)的數(shù)據(jù)庫中，這樣才能更好的與已有系統(tǒng)融合在一起，達到最小影響原有系統(tǒng)的效果。 “全時通”系統(tǒng)與數(shù)據(jù)庫服務器并不是在同一臺服務器上，他們處于同一局域網(wǎng)內，而機主留言功能的數(shù)據(jù)庫的表也建在已有系統(tǒng)上，所以該設計的數(shù) 據(jù)庫訪問與原有系統(tǒng)的數(shù)據(jù)庫訪問是一致的， JDBC 代碼如下： try{ (“”)。// 建立 JDBC橋接器 } catch(ClassNotFoundException ex) {} Connection conn = null。 try{ conn=(“jdbc:oracle:thin:@:1521:ora9”,”oraclename”,”p assword”)。// 連接數(shù)據(jù)庫 } catch(SQLException ex){ ()。 //將此 throwable 及其追蹤輸出至標準錯誤流 } 定制功能 SP 接收到用戶的定制短信時，“全時通系統(tǒng)”會對該用戶進行判斷他是否是全時通用戶。如果不是會發(fā)送相關的提醒短信返回給用戶；如果是則會繼續(xù)分析該用戶的定制語句。一旦判斷到該用戶的語句是“ m +數(shù)字（ 19 小時，該短信滯留全時通平臺時間即短信的有效時間） +“不方便接聽原由””時（數(shù)字可有可無 ,沒有數(shù)字則表示該機主 留言短信長期有效，方便了用戶擔心短信留言的有效時間過短而設置的），則認為該用戶是在定制機主留言短信功能，立即存入到內存中，同時更新存放數(shù)據(jù)庫內的機主留言功能的表（ lh_ps_userinfo）并且向用戶發(fā)送機主留言功能定制成功的短信 ,相關的判斷算法程序如下： if (() 1 amp。amp。 (M)!=1 ) { String message = null。 int duration。 //duration 短信留言的有效期 StringBuffer buffer = new StringBuffer()。 int i = 1。 for(i = 1。 i () 。 i++){ char c = (i)。//查找 i位置的字母 if((c))//如果 c是數(shù)字字符，則返回 true (c)。 else break。 } if(().trim().equals()) duration = 0。 else duration = (())。 message = (i,())。 if(!(mobile)) (mobile,)。 //發(fā)送用戶不是全時通用戶的提醒 else{ PsUser psuser = new PsUser()。 = message。 = duration。 =new SimpleDateFormat(yyyyMMdd HH:mm:ss).format(new Date(()))。 (mobile + : 被 叫 請 求 ,msg: + message + ,duration:+ duration+,sendtime+)。 if((mobile)){ //如果該用戶是被叫用戶，則更新數(shù)據(jù)庫 (mobile,psuser)。 (message,duration,mobile)。 }else{ //如果表中無該用戶，則把該用戶填加進表中 (mobile,psuser)。 (mobile,message,duration)。 } (mobile,)。 //發(fā)送用戶定制短信留言功能成功消息 } } 留言短信發(fā)送 內存模塊與數(shù)據(jù)庫的關系 系統(tǒng)直接對數(shù)據(jù)庫的操作會影響整個系統(tǒng)的性能，鑒于這個原因，“全時通”系統(tǒng)則使用的是系統(tǒng)直接對內存操作，內存與數(shù)據(jù)庫同步的方式把內存作為一個緩沖以增加系統(tǒng)的性能。因此，必須保證內存模塊與數(shù)據(jù)庫之間同步。 當“全時通”系統(tǒng)重 新啟動后，就必須立即實現(xiàn)內存與數(shù)據(jù)庫之間的同步。 實現(xiàn)的方法如下： user = (pos,max)。 while(user != null amp。amp。 0){ for(int i=0。i。i++){ InitPsUserLogic(user[i][0],user[i][1],user[i][2],user[i][3],user[i][4])。 pos = (user[i][0])。 } user = (pos,max)。 } user =null。 (InitPsUserThread:總共導入被叫 +()+個 )。 (\n)。 ()。 free()。 private void InitPsUserLogic(String id,String mobile,String message,String duration,String sendtime){ if(mobile!=null){ PsUser user = new PsUser()。 = mobile。 = message。 = (duration)。 = sendt