1．??? 引言?

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

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

2．??? 背景介紹?

2．1常用縮略語?

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

表 1 縮略語說明?

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

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

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

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

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

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

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

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

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

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

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

3.1?? ?模型的目標(biāo)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖 2 模塊之間的示意關(guān)系

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

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

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

3.3.2? 緩沖池

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

3.3.3??業(yè)務(wù)模塊

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

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

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

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

< business -config>

? < business -mappings>

???

serviceID = "特服號" ?

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

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

。。。

??

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

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

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

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

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

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

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

4．?實(shí)現(xiàn)模型的關(guān)鍵技術(shù)?

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

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

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

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

4.2? SOAP方式接收短信請求

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

5??結(jié)束語?

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

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

參考文獻(xiàn)?

[1]? 中國移動通信互聯(lián)網(wǎng)短信網(wǎng)關(guān)接口協(xié)議V2.0 (China Mobile Peer to Peer, CMPP)，V2.0，中國移動通信集團(tuán)公司，2002年

[2]? DSMP規(guī)范中的SSO平臺接入規(guī)范，中國移動通信集團(tuán)公司，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ù)模型，鄭扣根等，軟件學(xué)報(bào)Vol.12,No.9