沉疴一年，病情有所好轉。應公司要求閑暇時刻維護一下公司的短信平臺。那是幾年前的作品了，重拾舊作，順便做一總結。
SP端的聯通短信網關其實說白了就是一個簡單的SGIP協議接口，不過SP公司需要在實現接口的基礎上做一些業務方面的考量和實現。為此整個系統的結構設計仍然需要認真設計，便于擴展。
整個系統基本上兩大模塊：就是協議轉換模塊和業務產品模塊。
協議轉換模塊的基本功能：
1，各種協議包的接收、識別和響應，這是最基本的功能啦，沒有這樣的功能，談不上是一個網關。
2，各類信息的迅速轉發。這是對一個接口功能上的考慮。如果一個協議接口不能迅速處理大量的協議包，會造成接口的堵塞。只要編程正確，Java1.5提供的API完全能夠勝任SP目前的大業務量，即時是堵塞式API也能勝任有余，當然concurrent包是應該采用的。
產品模塊相當來說非常簡單啦，當然必須是線程為基礎。線程的run（）方法本身完全就可以作為產品類的一個獨立的唯一接口。
既然有了這兩個模塊，其間的通訊當然也是非常重要的，很容易成為整個系統的瓶頸，畢竟短信MT大都來自的產品模塊。推薦采用并發長連接實現。
在整個平臺的結構設計中，因為有很多業務方面的需要，譬如業務合作（每個合作方的接口不一定一致），統計（不同來源的統計，各種這樣的功能統計）等各方面的需求，往往在各模塊的接口設計上加入各種字段，甚至要求向協議轉換模塊傳入業務模塊的一些信息，往往看上去方便了一些功能的實現，譬如是統計，但是卻破壞了模塊概念上的純潔性，而且不便于后期的維護，所以，最終還是放棄了一個將合作方信息字段加入到協議轉換模塊的想法。
性能、數據完整性方面的考慮：
1，及時入庫還是日志入庫，看需要。如果網關信息庫是獨立的，可以考慮及時入庫，只是要保證信息的完整性，入庫異常的要保存日志。
2，各個模塊接口前加入前端緩存，建議采用concurrent包。大量數據應該存儲轉發，尤其是類似下發話單這樣的場合。
3，產品模塊因為要保證業務信息的及時和準確，所以在實現上必須使用緩存。大量的用戶業務數據信息緩存處理和數據庫存儲是實際應用中必須衡量使用。
整個結構設計清楚了，實現應該沒有太大的問題。目前這個應用平臺已經運行了兩年，中間也經受了業務推廣鼎盛時期的考驗，及其穩定，尚算滿意。打個及格分，呵呵。做一總結在此，希望能給新手一個設計上的借鑒。
寫的詞不達意。望諒解。