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

現在當SP向移動運營商申請接入後，移動運營商除了提供他們所採用的短信網關協議文檔外，還會提供由短信網關廠家提供的，短信網關通信的開發包，也就是我們所說的API了。對於是否使用這些API就見仁見智了，因此對於單說實現短信網關協議從開發上有兩種做法，一種就是完全基於別人提供的API來實現網關協議；另外一種就是自己根據網關協議文檔，自行寫代碼實現。對於第一種方法，就是開發速度快，底層通信以及短信協議的實現都不用自己考慮，缺點就是經常會有一些小問題：比如，廠家提供的API有內存泄漏，又或者這些API提供的時候就缺少一些庫文件，又或者在長時間運作後莫名其妙死掉等問題，而且處理這些問題自己都沒有辦法解決，只有等待廠家提供新版本的API。對於第二種方法就是優點就是自己對協議理解，實現都比較清楚，出了問題好找，對於要求性能高，穩定性好的SP建議採用該辦法，而缺點就是開發的時間相對來說會比較長，而且在對於不同廠家提供的網關會有一些小的改動。比如中國移動的CMPP網關，對於由亞信提供的短信網關，則在協議實現的時候，MO和MT要分別建立連接，而對於華爲提供的短信網關，則在同一個連接處理MO和MT。
  
  協議開發部分說完了，下面說說如何實現一個短信業務系統/平臺。從簡單的業務實現到複雜的運營商級的短信業務系統，實現上大致可以分爲三類。
  
  第一類，簡單業務型短信系統/平臺，由於業務類型的簡單或者單一，比如只是做羣發，或者只提供某些簡單的交互信息服務，實現的辦法就是在實現短信協議的同時，把業務邏輯都編寫到程序裏面去。這樣對於只是提供比較單一服務的SP就可以很方便實現自己的短信系統，當然啦，這樣的系統對於擴展性來說是很不利的，所以極少採用這種方法進行開發；那麼如果能夠業務邏輯和短信協議的實現分開就可以更好地實現短信系統了，對於第二類短信系統就是基本解決了這樣的問題。
  
  第二類，業務開發型的短信系統/平臺，能夠把業務邏輯和短信協議部分分開實現，採用一個短信服務號碼，根據用戶發送不同的短信代碼來實現不同的業務，這樣的系統是現有大部分SP都在使用的。其實現的辦法是，對於短信的上行和下行有專門的協議實現程序，而收到以及要發送的信息通過數據庫來做接口。對於業務邏輯的實現，就是通過專門編寫業務實現模塊的程序，或者直接利用數據庫的存儲過程來實現，業務模塊通過查詢數據庫得到用戶發送上來的MO信息，對該信息進行處理後，產生新的MT信息，並且寫回數據庫中，而短信協議模塊則讀取MT信息，把信息發送給用戶。
  
  第三類，運營商級的短信綜合業務二次開發平臺，對於這一類的短信平臺，它把短信協議的實現，數據庫的訪問，以及各種字符，數字，邏輯等運算都封裝起來，用戶在設計和實現新的業務流程的時候，只需要把要實現的流程圖畫好，就可以利用平臺提供的二次開發環境，不需要複雜的編程就可以實現新業務，有些二次開發環境還是圖形界面非常簡單方便，開發者完全可以不需要任何寫代碼的基礎。這一類的平臺，還可以同時加載上千個流程，並且可以實時加載和卸載流程而不影響其他流程正常的服務。實現的方法是，整個系統分成三個部分，第一部分是短信協議實現部分，這部分和以上兩類沒有太大區別只是和業務模塊是通過網絡通信的方式實現；第二部分是業務邏輯解析模塊，所有編寫好的業務邏輯都在這個模塊上加載，運行。這個模塊實現的就是封裝各種各樣的資源操作，並根據業務邏輯來執行。這裏一般對於業務邏輯的實現都是通過狀態機的狀態跳轉方式實現；第三部分就是業務開發模塊，也就是我們平常所說的短信流程，把業務邏輯解析的各種資源動作通過一個開發窗口提供給用戶使用，並且進行編譯，校驗用戶編寫的流程是否正確。
  
  以上三類系統/平臺的開發，對於第一類就不多說了，我們比較一下第二類和第三類的區別。第三類比第二類的好處在於，業務流程開發方便快捷，不需要專業的開發工程師就可以實現；在實現時候對於Session的控制簡單；業務管理方便。而缺點則是前期的投入比較大，對於平臺開發搭建的難度比較高。
  
  以上是我自己在短信技術開發思路上的一些總結，或者大家可能有其他不同的實現思路以及方法，歡迎大家一起探討，謝謝！