SMS短信開發技術總結--協議篇　

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

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

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

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

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

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

SMS短信開發技術總結--開發篇　

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

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

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

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

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

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

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