1． 引言
近年來，隨著短信增值業(yè)務的繁榮，以短信為基礎的產業(yè)鏈逐漸形成。在這條產業(yè)鏈中，網絡提供商（例如：中國移動、中國聯通）作為網絡平臺的提供者，向SP服務商（Service Provider，簡稱SP）提供有償的數據和網絡平臺，而SP服務商利用此網絡平臺，向廣大短信用戶提供各種具體的應用服務。為了繼續(xù)活躍短信市場，網絡提供商降低了SP服務商的門檻，使得更多的中小型SP服務商融入到此產業(yè)鏈中。
本文從介紹Java短信平臺所依托的網絡結構和原理的大背景出發(fā)，利用Java語言面向對象特性和在Web服務、XML方面的優(yōu)勢，提出了適合于中小型SP服務商短信平臺的軟件模型，并著重論述了此軟件模型的總體框架、業(yè)務動態(tài)分配、狀態(tài)控制三部分。最后述說了實現此軟件模型所需要的幾個關鍵Java技術。
2． 背景介紹
2．1常用縮略語
首先對本文中出現的、在SP短信平臺中經常使用的縮略語做簡要說明[1]。
表 1 縮略語說明
2．2網絡平臺的結構和原理
中國移動、中國聯通作為網絡提供商，其本身并不經營具體的短信業(yè)務，而是由SP服務商提供短信業(yè)務。例如當手機終端用戶在使用蘇州地區(qū)氣象短信服務時，手機終端首先向氣象SP服務商的特服號01218發(fā)送內容為TQYB的短信。當SP服務商的短信平臺接收到TQYB后，做適當的業(yè)務處理后，將當前的天氣情況再發(fā)送到手機終端上。而此時，手機終端則表現為接收到一條由01218回復的短信，其內容是當前天氣情況。在一發(fā)一收過程中， SP服務商做了什么？網絡提供商又做了什么呢？
SP短信平臺與手機終端用戶之間通過網絡提供商的中介實體SMC 與ISMG相連。網絡的邏輯結構如示意圖1。
圖-1互聯短信邏輯網絡結構示意圖
（1） 手機終端發(fā)出的短信首先通過GSM協議被SMC接收；SMC再將短信路由給ISMG；
（2） ISMG隨后將短信通過CMPP協議傳送給SP服務商；
（3） SP服務商根據接收到的短信和自身的業(yè)務邏輯產生業(yè)務輸出；
（4） SP服務商將需要發(fā)送給用戶的短信按CMPP協議發(fā)送到ISMG；
（5） ISMG再將短信路由給SMC，最后由SMC負責將短信按GSM協議發(fā)給手機終端。
本文中的SP短信平臺是指SP服務商所擁有的、能夠完成上述短信流程中第（2）（3）（4）步的、用于滿足自身短信業(yè)務需求的軟件平臺。
3． SP短信平臺的軟件模型
3.1 模型的目標
SP短信平臺軟件模型的第一個目標是要能夠按照多種通信協議通信。這是因為在實際業(yè)務中，雖然大部分短信業(yè)務流程的發(fā)起者是手機終端用戶。但是，為了豐富短信業(yè)務的使用渠道和方便用戶，短信流程的發(fā)起者呈多樣化。以下是常用的4種短信業(yè)務流程發(fā)起者。
（1） 由用戶手機終端發(fā)起
這是最常見的一種發(fā)起方式。由手機終端對特服號發(fā)出某短信業(yè)務代碼，經過短信網關按照CMPP協議傳至SP短信平臺。經業(yè)務處理后，回復手機終端用戶。例如：實時股票指數查詢、氣象實時查詢。
（2） 由網站發(fā)起
用戶在網站上完成短信業(yè)務注冊包月，或者下載短信。此方式是通過Http協議由web服務器激發(fā)web容器中短信服務模塊，從而完成相應的短信業(yè)務流程。例如：通過網站下載短信笑話、在氣象網站上完成氣象服務的包月注冊。
（3） 由短信平臺自身發(fā)起
對于一些包月業(yè)務或者其他第三方軟件系統中提示功能的短信業(yè)務，通常是在某些特定條件下由短信平臺激發(fā)短信業(yè)務模塊。例如：商務平臺中內嵌日歷短信提示功能。
（4） 由SOAP協議發(fā)起
用戶有時通過客服電話或者移動公司的商業(yè)網點來訂閱短信服務。這時的訂閱請求經由MISC以SOAP協議方式發(fā)送到SP短信平臺上。所以這種類型的短信業(yè)務是由SOAP協議激發(fā)的。
由此使得SP短信平臺中通信部分所使用的通信協議和通信方式各不相同。
SP短信平軟件模型的第二個目標是一個短信平臺同時掛接多個短信子業(yè)務。這第二個目標也是是由中小型SP服務商的業(yè)務特點所決定的。其特點有：
（1） 充分利用企業(yè)特性，開發(fā)的短信業(yè)務種類豐富，甚至業(yè)務邏輯經常發(fā)生變化；
（2） 每種短信業(yè)務的邏輯并不復雜；
（3） 業(yè)務與業(yè)務之間互不干擾。
3.2 SP短信平臺軟件模型的總體框架
根據以上兩個目標的分析，軟件平臺總體思路是將業(yè)務模塊和通信模塊分離。按照各模塊的功能可以劃分為四部分，短信接收模塊、任務分配器、業(yè)務邏輯模塊、短信發(fā)送模塊。短信接收模塊將接收到短信都存入緩沖池中，然后任務分配器將不同的短信分配給相應的業(yè)務模塊。最后將產生的短信回復通過發(fā)送模塊發(fā)送。示意關系如圖2。
圖 2 模塊之間的示意關系
3. 3 業(yè)務模塊和通信模塊分離
3.3.1 收、發(fā)送通信模塊
通信模塊主要解決短信業(yè)務流程不同發(fā)起者的問題。對于由網站發(fā)起和由短信平臺自身發(fā)起部分的實現比較容易。而處理另外兩種發(fā)起者時，就要求通信模塊同時具有按CMPP協議和按SOAP協議通信的功能。所以可以將接收模塊進一步分層，分為上下兩層：底層模塊按兩種不同的通信協議（按CMPP通信協議方式接收或者按SOAP協議方式接收）接收來自短信發(fā)起源的短信，并以統一的格式傳給上層模塊；上層模塊則在接收到底層模塊的短信數據后，將其送入緩沖池，并產生原始記錄。
3.3.2 緩沖池
作為一個實時通信系統，并發(fā)是一個不可避免的問題，而且隨著業(yè)務量的增大，并發(fā)度也會相應提高。雖然在CMPP協議中提供了解決在傳輸時并發(fā)的手段，如通過滑動窗口來控制流量、針對不同的應用可以使用長連接或短連接。但在短信收發(fā)模塊和業(yè)務邏輯模塊之間仍存在并發(fā)問題和處理速度不一致問題，所以在短信收發(fā)模塊和業(yè)務邏輯模塊之間增加了緩沖池――接收緩沖池和發(fā)送緩沖池。緩沖池的另外一個作用是登記每一條收到和發(fā)送的短信，這是計費和進一步分析統計的依據。
3.3.3 業(yè)務模塊
SP服務商短信業(yè)務的執(zhí)行邏輯，隨著市場需求的變化經常會發(fā)生調整和變動。將通信模塊從業(yè)務模塊分離后，單個業(yè)務模塊的設計相對簡單，而且各個業(yè)務模塊之間是互相獨立的。那么，SP短信平臺又是如何根據不同的短信內容，啟動相應的業(yè)務模塊呢？于是任務分配器就應運而生，它是通信模塊和業(yè)務模塊之間的橋梁。
3.4 任務動態(tài)分配
任務分配器在于動態(tài)的根據收到短信業(yè)務類型的特征信息，“喚醒”不同的業(yè)務模塊。這就像struts中的控制器ActionServlet，能根據接收到不同的URL，去對應不同的Action類。
任務分配器首先需要一個業(yè)務描述文件，描述短信業(yè)務類型的特征與所需調用的業(yè)務模塊之間的關系，可以采用XML文件來描述。短信業(yè)務類型特征包括短信特服號和短信業(yè)務的類別碼；業(yè)務模塊用其相應java類的類名來表示。描述文件基本格式如下：
< business -config>
< business -mappings>
serviceID = "特服號"
businessID = "業(yè)務類別碼"
type = "業(yè)務類名" />
。。。
在分配機制中由于在代碼階段無法預知每個業(yè)務模塊的，類名稱是在程序運行時從XML描述文件中取得，所以普通的類實例化方法（如：ClassName clsinstant=new ClassName()）無法實現，而必須通過java的運行時鏈編技術才能有效的得以實現。具體實現的關鍵語句如下：
Do_Business instance = null;
Class clazz = Class.forName(className);
instance = (Do_Business) clazz.newInstance();
instance.process(MsgPacket);
其中，Do_Business是被所有業(yè)務模塊繼承的一個基類。process（）是它的一個接口，所有業(yè)務模塊都必須通過這個接口實現不同業(yè)務邏輯。第二、三行以沒某個具體業(yè)務的java類名作為輸入參數，并實例化此對象。第四行調用了此實例的process方法。java可以根據不同子類而調用各自不同的process方法。
通過這樣的一個任務分派器實現了將緩沖區(qū)中取來的短信交由相應的業(yè)務模塊處理。
4． 實現模型的關鍵技術
4.1 CMPP協議的消息包解析
按CMPP協議與短信網關通信是接收短信的最主要方式。CMPP協議是建立在TCP/IP上的應用層通信協議。SP短信平臺和ISMG之間使用套接字端口7890和7900通信。CMPP協議的消息包格式如圖3所示。消息包分為兩部分――消息頭和消息體，消息頭的長度12個字節(jié)，消息體的長度為消息頭中Total_Length與消息頭長度之差。消息體的內容和格式根據消息頭中命令字段Command_Id的不同而不同。各類命令的消息體格式見參考文獻1。
圖 3 CMPP協議的消息包格式
在實現對CMPP協議消息包格式的解析和封裝時，采用面向對象思想。把原本按字節(jié)順序組織的消息包，封裝成按類組織的消息對象。為今后使用消息包中的數據提供了方便。再加上Java語言利用其對面向對象思想的強大支持，如繼承、多態(tài)等，有效的提高了編碼的方便性和代碼的重用性。
4.2 SOAP方式接收短信請求
SOAP方式接收短信請求在短信注冊包月業(yè)務中使用的最為廣泛。SOAP協議是以Http協議為基礎。其命令請求和響應的內容都放在Http請求Entity Body中，并采用XML格式，內容類型（Content-Type）為：” text/plain”。 SOAP協議可以使用Apache提供的jar軟件包來解析。中國移動所使用SOAP協議的消息格式，請見參考文獻1。
5 結束語
按此模型開發(fā)短信平臺在蘇州某SP服務商，運行良好，而且很好的解決了我國兩大網絡提供商――中國移動和中國聯通的短信協議在并不完全相同的問題。
另外，彩信作為中國移動推出的短信升級版增值服務，其發(fā)展速度已經遠遠超過了移動的預計。SP服務商短信、彩信綜合平臺將有很好的應用前景。
參考文獻
[1] 中國移動通信互聯網短信網關接口協議V2.0 (China Mobile Peer to Peer, CMPP)，V2.0，中國移動通信集團公司，2002年
[2] DSMP規(guī)范中的SSO平臺接入規(guī)范，中國移動通信集團公司，2003年
[3] 《Java SOAP編程指南》，(美) Henry Bequet著，2002年
[4] 《Java線程》，Scott Oaks, Henry Wong著，2003年
[5] 《SMPP Protocol Specification v3.4》，SMPP Developers Forum，http://www.smsforum.net/
[6] 基于狀態(tài)和變化的統一時空數據模型，鄭扣根等，軟件學報Vol.12,No.9
----------------------------------------------------------------------------
給你幾個建議：
1 找SP合作，讓他們提供發(fā)送通道，例如，讓他們提供一個http的網址，你調用并傳遞參數實現發(fā)送，這個，就像樓上有人說的，如果沒有流量，沒人陪你玩；
2 找企業(yè)短信通道，這個移動在做，不過你的流量中國移動可能看不上，你可以找SP聯系這個通道，不過資費比1高一些，別的不知道，我倒是知道sohu的，你可以參考一下：http://61.135.132.56:8080/smsn/welcome.do
3 用短信貓或者干脆用手機，你搜索一下串口發(fā)送短信，這個解決方案你可以考慮。發(fā)送的sim卡你可以考慮開通幾張動感地帶，開通1000條的套餐，價格還算可以。
你先研究研究，如果你老大肯花錢，發(fā)彩信、短信、push都不是問題。多花錢享受服務也好，一分價錢一分貨。
