1．??? 引言?

近年來，隨著短信增值業(yè)務的繁榮，以短信為基礎的產(chǎn)業(yè)鏈逐漸形成。在這條產(chǎn)業(yè)鏈中，網(wǎng)絡提供商（例如：中國移動、中國聯(lián)通）作為網(wǎng)絡平臺的提供者，向SP服務商（Service Provider，簡稱SP）提供有償?shù)臄?shù)據(jù)和網(wǎng)絡平臺，而SP服務商利用此網(wǎng)絡平臺，向廣大短信用戶提供各種具體的應用服務。為了繼續(xù)活躍短信市場，網(wǎng)絡提供商降低了SP服務商的門檻，使得更多的中小型SP服務商融入到此產(chǎn)業(yè)鏈中。?

本文從介紹Java短信平臺所依托的網(wǎng)絡結(jié)構和原理的大背景出發(fā)，利用Java語言面向?qū)ο筇匦院驮赪eb服務、XML方面的優(yōu)勢，提出了適合于中小型SP服務商短信平臺的軟件模型，并著重論述了此軟件模型的總體框架、業(yè)務動態(tài)分配、狀態(tài)控制三部分。最后述說了實現(xiàn)此軟件模型所需要的幾個關鍵Java技術。?

2．??? 背景介紹?

2．1常用縮略語?

首先對本文中出現(xiàn)的、在SP短信平臺中經(jīng)常使用的縮略語做簡要說明^[1]。?

表 1 縮略語說明?

2．2網(wǎng)絡平臺的結(jié)構和原理?

中國移動、中國聯(lián)通作為網(wǎng)絡提供商，其本身并不經(jīng)營具體的短信業(yè)務，而是由SP服務商提供短信業(yè)務。例如當手機終端用戶在使用蘇州地區(qū)氣象短信服務時，手機終端首先向氣象SP服務商的特服號01218發(fā)送內(nèi)容為TQYB的短信。當SP服務商的短信平臺接收到TQYB后，做適當?shù)臉I(yè)務處理后，將當前的天氣情況再發(fā)送到手機終端上。而此時，手機終端則表現(xiàn)為接收到一條由01218回復的短信，其內(nèi)容是當前天氣情況。在一發(fā)一收過程中， SP服務商做了什么？網(wǎng)絡提供商又做了什么呢？?

SP短信平臺與手機終端用戶之間通過網(wǎng)絡提供商的中介實體SMC 與ISMG相連。網(wǎng)絡的邏輯結(jié)構如示意圖1。?

圖-1互聯(lián)短信邏輯網(wǎng)絡結(jié)構示意圖

（1）?????? 手機終端發(fā)出的短信首先通過GSM協(xié)議被SMC接收；SMC再將短信路由給ISMG；?

（2）?????? ISMG隨后將短信通過CMPP協(xié)議傳送給SP服務商；?

（3）?????? SP服務商根據(jù)接收到的短信和自身的業(yè)務邏輯產(chǎn)生業(yè)務輸出；?

（4）?????? SP服務商將需要發(fā)送給用戶的短信按CMPP協(xié)議發(fā)送到ISMG；?

（5）?????? ISMG再將短信路由給SMC，最后由SMC負責將短信按GSM協(xié)議發(fā)給手機終端。?

本文中的SP短信平臺是指SP服務商所擁有的、能夠完成上述短信流程中第（2）（3）（4）步的、用于滿足自身短信業(yè)務需求的軟件平臺。?

3．??? SP短信平臺的軟件模型?

3.1?? ?模型的目標

SP短信平臺軟件模型的第一個目標是要能夠按照多種通信協(xié)議通信。這是因為在實際業(yè)務中，雖然大部分短信業(yè)務流程的發(fā)起者是手機終端用戶。但是，為了豐富短信業(yè)務的使用渠道和方便用戶，短信流程的發(fā)起者呈多樣化。以下是常用的4種短信業(yè)務流程發(fā)起者。?

（1）?????? 由用戶手機終端發(fā)起

這是最常見的一種發(fā)起方式。由手機終端對特服號發(fā)出某短信業(yè)務代碼，經(jīng)過短信網(wǎng)關按照CMPP協(xié)議傳至SP短信平臺。經(jīng)業(yè)務處理后，回復手機終端用戶。例如：實時股票指數(shù)查詢、氣象實時查詢。?

（2）?????? 由網(wǎng)站發(fā)起

用戶在網(wǎng)站上完成短信業(yè)務注冊包月，或者下載短信。此方式是通過Http協(xié)議由web服務器激發(fā)web容器中短信服務模塊，從而完成相應的短信業(yè)務流程。例如：通過網(wǎng)站下載短信笑話、在氣象網(wǎng)站上完成氣象服務的包月注冊。?

（3）?????? 由短信平臺自身發(fā)起

對于一些包月業(yè)務或者其他第三方軟件系統(tǒng)中提示功能的短信業(yè)務，通常是在某些特定條件下由短信平臺激發(fā)短信業(yè)務模塊。例如：商務平臺中內(nèi)嵌日歷短信提示功能。?

（4）?????? 由SOAP協(xié)議發(fā)起

用戶有時通過客服電話或者移動公司的商業(yè)網(wǎng)點來訂閱短信服務。這時的訂閱請求經(jīng)由MISC以SOAP協(xié)議方式發(fā)送到SP短信平臺上。所以這種類型的短信業(yè)務是由SOAP協(xié)議激發(fā)的。?

由此使得SP短信平臺中通信部分所使用的通信協(xié)議和通信方式各不相同。?

SP短信平軟件模型的第二個目標是一個短信平臺同時掛接多個短信子業(yè)務。這第二個目標也是是由中小型SP服務商的業(yè)務特點所決定的。其特點有：?

（1）?????? 充分利用企業(yè)特性，開發(fā)的短信業(yè)務種類豐富，甚至業(yè)務邏輯經(jīng)常發(fā)生變化；

（2）?????? 每種短信業(yè)務的邏輯并不復雜；

（3）?????? 業(yè)務與業(yè)務之間互不干擾。

3.2?? SP短信平臺軟件模型的總體框架

根據(jù)以上兩個目標的分析，軟件平臺總體思路是將業(yè)務模塊和通信模塊分離。按照各模塊的功能可以劃分為四部分，短信接收模塊、任務分配器、業(yè)務邏輯模塊、短信發(fā)送模塊。短信接收模塊將接收到短信都存入緩沖池中，然后任務分配器將不同的短信分配給相應的業(yè)務模塊。最后將產(chǎn)生的短信回復通過發(fā)送模塊發(fā)送。示意關系如圖2。

圖 2 模塊之間的示意關系

3.?3? 業(yè)務模塊和通信模塊分離

3.3.1? 收、發(fā)送通信模塊

通信模塊主要解決短信業(yè)務流程不同發(fā)起者的問題。對于由網(wǎng)站發(fā)起和由短信平臺自身發(fā)起部分的實現(xiàn)比較容易。而處理另外兩種發(fā)起者時，就要求通信模塊同時具有按CMPP協(xié)議和按SOAP協(xié)議通信的功能。所以可以將接收模塊進一步分層，分為上下兩層：底層模塊按兩種不同的通信協(xié)議（按CMPP通信協(xié)議方式接收或者按SOAP協(xié)議方式接收）接收來自短信發(fā)起源的短信，并以統(tǒng)一的格式傳給上層模塊；上層模塊則在接收到底層模塊的短信數(shù)據(jù)后，將其送入緩沖池，并產(chǎn)生原始記錄。?

3.3.2? 緩沖池

作為一個實時通信系統(tǒng)，并發(fā)是一個不可避免的問題，而且隨著業(yè)務量的增大，并發(fā)度也會相應提高。雖然在CMPP協(xié)議中提供了解決在傳輸時并發(fā)的手段，如通過滑動窗口來控制流量、針對不同的應用可以使用長連接或短連接。但在短信收發(fā)模塊和業(yè)務邏輯模塊之間仍存在并發(fā)問題和處理速度不一致問題，所以在短信收發(fā)模塊和業(yè)務邏輯模塊之間增加了緩沖池――接收緩沖池和發(fā)送緩沖池。緩沖池的另外一個作用是登記每一條收到和發(fā)送的短信，這是計費和進一步分析統(tǒng)計的依據(jù)。?

3.3.3??業(yè)務模塊

SP服務商短信業(yè)務的執(zhí)行邏輯，隨著市場需求的變化經(jīng)常會發(fā)生調(diào)整和變動。將通信模塊從業(yè)務模塊分離后，單個業(yè)務模塊的設計相對簡單，而且各個業(yè)務模塊之間是互相獨立的。那么，SP短信平臺又是如何根據(jù)不同的短信內(nèi)容，啟動相應的業(yè)務模塊呢？于是任務分配器就應運而生，它是通信模塊和業(yè)務模塊之間的橋梁。?

3.4?? 任務動態(tài)分配

任務分配器在于動態(tài)的根據(jù)收到短信業(yè)務類型的特征信息，“喚醒”不同的業(yè)務模塊。這就像struts中的控制器ActionServlet，能根據(jù)接收到不同的URL，去對應不同的Action類。?

任務分配器首先需要一個業(yè)務描述文件，描述短信業(yè)務類型的特征與所需調(diào)用的業(yè)務模塊之間的關系，可以采用XML文件來描述。短信業(yè)務類型特征包括短信特服號和短信業(yè)務的類別碼；業(yè)務模塊用其相應java類的類名來表示。描述文件基本格式如下：?

< business -config>

? < business -mappings>

???

serviceID = "特服號" ?

businessID = "業(yè)務類別碼"

type = "業(yè)務類名"? />

。。。

??

在分配機制中由于在代碼階段無法預知每個業(yè)務模塊的，類名稱是在程序運行時從XML描述文件中取得，所以普通的類實例化方法（如：ClassName clsinstant=new ClassName()）無法實現(xiàn)，而必須通過java的運行時鏈編技術才能有效的得以實現(xiàn)。具體實現(xiàn)的關鍵語句如下：?

?????? ??? Do_Business instance = null;

?????? ??? Class clazz = Class.forName(className);

?????? ??? instance = (Do_Business) clazz.newInstance();

????????????? instance.process(MsgPacket);

其中，Do_Business是被所有業(yè)務模塊繼承的一個基類。process（）是它的一個接口，所有業(yè)務模塊都必須通過這個接口實現(xiàn)不同業(yè)務邏輯。第二、三行以沒某個具體業(yè)務的java類名作為輸入?yún)?shù)，并實例化此對象。第四行調(diào)用了此實例的process方法。java可以根據(jù)不同子類而調(diào)用各自不同的process方法。?

通過這樣的一個任務分派器實現(xiàn)了將緩沖區(qū)中取來的短信交由相應的業(yè)務模塊處理。?

4．?實現(xiàn)模型的關鍵技術?

4.1?CMPP協(xié)議的消息包解析

按CMPP協(xié)議與短信網(wǎng)關通信是接收短信的最主要方式。CMPP協(xié)議是建立在TCP/IP上的應用層通信協(xié)議。SP短信平臺和ISMG之間使用套接字端口7890和7900通信。CMPP協(xié)議的消息包格式如圖3所示。消息包分為兩部分――消息頭和消息體，消息頭的長度12個字節(jié)，消息體的長度為消息頭中Total_Length與消息頭長度之差。消息體的內(nèi)容和格式根據(jù)消息頭中命令字段Command_Id的不同而不同。各類命令的消息體格式見參考文獻1。?

圖 3 CMPP協(xié)議的消息包格式

在實現(xiàn)對CMPP協(xié)議消息包格式的解析和封裝時，采用面向?qū)ο笏枷搿０言景醋止?jié)順序組織的消息包，封裝成按類組織的消息對象。為今后使用消息包中的數(shù)據(jù)提供了方便。再加上Java語言利用其對面向?qū)ο笏枷氲膹姶笾С?，如繼承、多態(tài)等，有效的提高了編碼的方便性和代碼的重用性。?

4.2? SOAP方式接收短信請求

SOAP方式接收短信請求在短信注冊包月業(yè)務中使用的最為廣泛。SOAP協(xié)議是以Http協(xié)議為基礎。其命令請求和響應的內(nèi)容都放在Http請求Entity Body中，并采用XML格式，內(nèi)容類型（Content-Type）為：” text/plain”。 SOAP協(xié)議可以使用Apache提供的jar軟件包來解析。中國移動所使用SOAP協(xié)議的消息格式，請見參考文獻1。?

5??結(jié)束語?

按此模型開發(fā)短信平臺在蘇州某SP服務商，運行良好，而且很好的解決了我國兩大網(wǎng)絡提供商――中國移動和中國聯(lián)通的短信協(xié)議在并不完全相同的問題。?

另外，彩信作為中國移動推出的短信升級版增值服務，其發(fā)展速度已經(jīng)遠遠超過了移動的預計。SP服務商短信、彩信綜合平臺將有很好的應用前景。?

參考文獻?

[1]? 中國移動通信互聯(lián)網(wǎng)短信網(wǎng)關接口協(xié)議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)和變化的統(tǒng)一時空數(shù)據(jù)模型，鄭扣根等，軟件學報Vol.12,No.9