SMS短信開發(fā)技術總結--協(xié)議篇　

現在提供短信服務的SP都需要接入到各個移動運營商，雖然作為短信來說是同過SMPP協(xié)議和移動的交換中心進行通信。但是為了提供信息服務，對各種業(yè)務進行業(yè)務管理，以及計費，因此每個移動運營商都開發(fā)了相應的網關協(xié)議，給SP做開發(fā)接口。因此這些網關協(xié)議就是做一次轉換，把SP發(fā)過來的信息轉換成 SMPP協(xié)議發(fā)送給交換中心，并且實現了計費以及業(yè)務的管理功能。

從現有的四個移動運營商來說，分別有四個不同的短信網關協(xié)議。中國移動（CMPP），中國聯(lián)通（SGIP），中國電信（SMGP），中國網通（CNGP）。前兩個運營商主要針對現在手機的用戶，后兩個運營商是針對小靈通的用戶。對于這些不同的協(xié)議，由于不同地方的移動運營公司采用不同廠家的產品，因此，在實現的時候都會有一些小差異，這點要比較注意，否則比如中國移動的CMPP網關在華為網關能夠跑的系統(tǒng)，不一定可以在亞信網關上直接用的。
下面就對現在的每個網關協(xié)議進行介紹。

首先，要說得是也是大家用得最多的中國移動的網關協(xié)議--CMPP，CMPP協(xié)議還在用得是有兩個版本，一個是CMPP2.0，另外一個是 CMPP3.0。從SP接入到CMPP3.0開始，就是接入了卓望的MISC系統(tǒng)。單從協(xié)議上講CMPP2.0和3.0之間的最大區(qū)別是3.0增加了 LinkID。然后在Fee_terminal_type，Dest_terminal_type以及Src_terminal_type增加對用戶號碼的定義，當這些用戶號碼類型為0：表示真實號碼；為1：表示偽碼。從增加的這些信息可以看到，第一，LinkID其實是一個臨時的定購關系標識，也就是說對于點播類業(yè)務，SP的短信系統(tǒng)收到這個LinkID后，才能建立正常的定購關系，而發(fā)送的信息必須攜帶LinkID才可以成功收費，否則就會監(jiān)權失敗，信息發(fā)送不出去。這樣就從技術上阻止了SP亂發(fā)收費信息；第二，用戶號碼類型，現在傳給SP還是普通的手機號碼，那么有了這個標識就是以后有可能發(fā)送上來的不是用戶的手機號碼了，而是一個普通的偽碼，那么以后SP就不能獲得最終用戶的手機號碼了。CMPP3.0除了協(xié)議方面的改進外，還把定購關系從SP方面剝離。以前CMPP2.0的時代，用戶的定購關系由SP自行把握，因此很容易出現SP私自捆綁用戶收費的現象，現在中國移動上了MISC1.6后，就把所有定購關系都放在運營商，而通過Provision的方式來和SP進行定購用戶的同步，并且訂購關系以運營商里面的數據為準，這也是從技術上杜絕了SP 自己管理的定購關系所出現的問題。

然后，介紹一下在手機方面的另外一個網關協(xié)議，中國聯(lián)通的SGIP，SGIP和移動的CMPP一樣都有兩個版本，SGIP1.2, SGIP1.3。新舊版本之間的主要區(qū)別也是增加了LinkID項。并且對于各種不同的業(yè)務類型，如手機點播，網上點播等都參數都做了重新的調整。中國聯(lián)通也上了一個類似移動MISC的管理平臺，SP的各種業(yè)務監(jiān)權也通過該管理平臺審核。

最后，要介紹一下的就是小靈通方面的兩個協(xié)議，一個就是中國電信的SMGP1.3協(xié)議，另外就是中國網通的CNGP1.0協(xié)議，這兩個協(xié)議在最近的升級里面都采用了聯(lián)通的辦法，使用MMSP這樣一套系統(tǒng)進行監(jiān)權管理，對于點播業(yè)務來說，只有和服務代碼相對應的字冠才可以正常收發(fā)信息。

以上是對現在運營商提供的短信協(xié)議進行簡單的介紹，詳細協(xié)議的內容，請到SP論壇關于SMS技術那里都可以找到。

SMS短信開發(fā)技術總結--開發(fā)篇　

在上一篇協(xié)議篇里面，相信大家都對現有的移動運營商提供的短信網關協(xié)議有一定的了解。OK，那么我繼續(xù)總結下去，開始和大家探討一下如何基于這些網關協(xié)議開發(fā)短信系統(tǒng)，我在這里只是總結開發(fā)的思路，并不提供代碼，因為具體到代碼的實現就是各自的開發(fā)功力問題，不在技術總結的范圍。不過，歡迎大家到SP論壇或者天堂鳥論壇來一起交流代碼的實現。

現在當SP向移動運營商申請接入后，移動運營商除了提供他們所采用的短信網關協(xié)議文檔外，還會提供由短信網關廠家提供的，短信網關通信的開發(fā)包，也就是我們所說的API了。對于是否使用這些API就見仁見智了，因此對于單說實現短信網關協(xié)議從開發(fā)上有兩種做法，一種就是完全基于別人提供的API來實現網關協(xié)議；另外一種就是自己根據網關協(xié)議文檔，自行寫代碼實現。對于第一種方法，就是開發(fā)速度快，底層通信以及短信協(xié)議的實現都不用自己考慮，缺點就是經常會有一些小問題：比如，廠家提供的API有內存泄漏，又或者這些API提供的時候就缺少一些庫文件，又或者在長時間運作后莫名其妙死掉等問題，而且處理這些問題自己都沒有辦法解決，只有等待廠家提供新版本的API。對于第二種方法就是優(yōu)點就是自己對協(xié)議理解，實現都比較清楚，出了問題好找，對于要求性能高，穩(wěn)定性好的SP建議采用該辦法，而缺點就是開發(fā)的時間相對來說會比較長，而且在對于不同廠家提供的網關會有一些小的改動。比如中國移動的CMPP網關，對于由亞信提供的短信網關，則在協(xié)議實現的時候，MO和MT要分別建立連接，而對于華為提供的短信網關，則在同一個連接處理MO和MT。

協(xié)議開發(fā)部分說完了，下面說說如何實現一個短信業(yè)務系統(tǒng)/平臺。從簡單的業(yè)務實現到復雜的運營商級的短信業(yè)務系統(tǒng)，實現上大致可以分為三類。

第一類，簡單業(yè)務型短信系統(tǒng)/平臺，由于業(yè)務類型的簡單或者單一，比如只是做群發(fā)，或者只提供某些簡單的交互信息服務，實現的辦法就是在實現短信協(xié)議的同時，把業(yè)務邏輯都編寫到程序里面去。這樣對于只是提供比較單一服務的SP就可以很方便實現自己的短信系統(tǒng)，當然啦，這樣的系統(tǒng)對于擴展性來說是很不利的，所以極少采用這種方法進行開發(fā)；那么如果能夠業(yè)務邏輯和短信協(xié)議的實現分開就可以更好地實現短信系統(tǒng)了，對于第二類短信系統(tǒng)就是基本解決了這樣的問題。

第二類，業(yè)務開發(fā)型的短信系統(tǒng)/平臺，能夠把業(yè)務邏輯和短信協(xié)議部分分開實現，采用一個短信服務號碼，根據用戶發(fā)送不同的短信代碼來實現不同的業(yè)務，這樣的系統(tǒng)是現有大部分SP都在使用的。其實現的辦法是，對于短信的上行和下行有專門的協(xié)議實現程序，而收到以及要發(fā)送的信息通過數據庫來做接口。對于業(yè)務邏輯的實現，就是通過專門編寫業(yè)務實現模塊的程序，或者直接利用數據庫的存儲過程來實現，業(yè)務模塊通過查詢數據庫得到用戶發(fā)送上來的MO信息，對該信息進行處理后，產生新的MT信息，并且寫回數據庫中，而短信協(xié)議模塊則讀取MT信息，把信息發(fā)送給用戶。

第三類，運營商級的短信綜合業(yè)務二次開發(fā)平臺，對于這一類的短信平臺，它把短信協(xié)議的實現，數據庫的訪問，以及各種字符，數字，邏輯等運算都封裝起來，用戶在設計和實現新的業(yè)務流程的時候，只需要把要實現的流程圖畫好，就可以利用平臺提供的二次開發(fā)環(huán)境，不需要復雜的編程就可以實現新業(yè)務，有些二次開發(fā)環(huán)境還是圖形界面非常簡單方便，開發(fā)者完全可以不需要任何寫代碼的基礎。這一類的平臺，還可以同時加載上千個流程，并且可以實時加載和卸載流程而不影響其他流程正常的服務。實現的方法是，整個系統(tǒng)分成三個部分，第一部分是短信協(xié)議實現部分，這部分和以上兩類沒有太大區(qū)別只是和業(yè)務模塊是通過網絡通信的方式實現；第二部分是業(yè)務邏輯解析模塊，所有編寫好的業(yè)務邏輯都在這個模塊上加載，運行。這個模塊實現的就是封裝各種各樣的資源操作，并根據業(yè)務邏輯來執(zhí)行。這里一般對于業(yè)務邏輯的實現都是通過狀態(tài)機的狀態(tài)跳轉方式實現；第三部分就是業(yè)務開發(fā)模塊，也就是我們平常所說的短信流程，把業(yè)務邏輯解析的各種資源動作通過一個開發(fā)窗口提供給用戶使用，并且進行編譯，校驗用戶編寫的流程是否正確。

以上三類系統(tǒng)/平臺的開發(fā)，對于第一類就不多說了，我們比較一下第二類和第三類的區(qū)別。第三類比第二類的好處在于，業(yè)務流程開發(fā)方便快捷，不需要專業(yè)的開發(fā)工程師就可以實現；在實現時候對于Session的控制簡單；業(yè)務管理方便。而缺點則是前期的投入比較大，對于平臺開發(fā)搭建的難度比較高。