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

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

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

首先，要說得是也是大家用得最多的中國移動的網(wǎng)關(guān)協(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其實是一個臨時的定購關(guān)系標識，也就是說對于點播類業(yè)務(wù)，SP的短信系統(tǒng)收到這個LinkID后，才能建立正常的定購關(guān)系，而發(fā)送的信息必須攜帶LinkID才可以成功收費，否則就會監(jiān)權(quán)失敗，信息發(fā)送不出去。這樣就從技術(shù)上阻止了SP亂發(fā)收費信息；第二，用戶號碼類型，現(xiàn)在傳給SP還是普通的手機號碼，那么有了這個標識就是以后有可能發(fā)送上來的不是用戶的手機號碼了，而是一個普通的偽碼，那么以后SP就不能獲得最終用戶的手機號碼了。CMPP3.0除了協(xié)議方面的改進外，還把定購關(guān)系從SP方面剝離。以前CMPP2.0的時代，用戶的定購關(guān)系由SP自行把握，因此很容易出現(xiàn)SP私自捆綁用戶收費的現(xiàn)象，現(xiàn)在中國移動上了MISC1.6后，就把所有定購關(guān)系都放在運營商，而通過Provision的方式來和SP進行定購用戶的同步，并且訂購關(guān)系以運營商里面的數(shù)據(jù)為準，這也是從技術(shù)上杜絕了SP 自己管理的定購關(guān)系所出現(xiàn)的問題。

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

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

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

SMS短信開發(fā)技術(shù)總結(jié)--開發(fā)篇　

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

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

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

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

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

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

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