丁 磊，鐘文杰

（廣東工業(yè)大學(xué) 計算機學(xué)院，廣東 廣州 510006）

隨著互聯(lián)網(wǎng)的發(fā)展和移動終端的普及[1]，移動廣告的出現(xiàn)是必不可少的，移動廣告具有移動性、高效性和互動性的特點. 移動廣告有諸多優(yōu)點，但隨著移動廣告類型的豐富，連接到廣告平臺的移動終端數(shù)量漸漸增多，廣告平臺對移動終端的移動廣告的管理就逐漸成為一個難題. 為了達到廣告平臺能有效管理數(shù)量龐大的移動終端的移動廣告的目的，本文設(shè)計一種利用OMA DM協(xié)議開發(fā)的移動廣告投放平臺. 該平臺的創(chuàng)新點在于:設(shè)計一種移動廣告投放平臺使用OMA DM協(xié)議，提高管理大量的移動終端中移動廣告的能力. OMA旨在尋求一種與系統(tǒng)無關(guān)的、開放的，使各種應(yīng)用和業(yè)務(wù)能夠在各種終端上實現(xiàn)互聯(lián)互通的標(biāo)準(zhǔn)[2]. 在移動廣告領(lǐng)域，楊芮等[3]的廣告系統(tǒng)利用Struts2框架作為控制層，但其廣告系統(tǒng)的廣告展示方式較為單一. 菅朋朋等[4]的RTB廣告系統(tǒng)使用實時傳輸協(xié)議縮短廣告系統(tǒng)對數(shù)據(jù)的響應(yīng)時間，但其廣告系統(tǒng)的穩(wěn)定性和可靠性不足. 廖安舟等[5]提出分層次、模塊化的廣告系統(tǒng)，但其廣告系統(tǒng)的安全性及用戶的隱私性保護不足. 王博等[6]提出基于云平臺的廣告投放系統(tǒng)，但其廣告投放系統(tǒng)對平臺依賴性較大，移植性較差. 陳志圣等[7]提出基于位置的移動商務(wù)廣告模型，但其模型中藍牙的偵測范圍較小，且當(dāng)用戶運動速度較快時，該模型無法與用戶建立穩(wěn)定的連接.

對于上述存在的廣告系統(tǒng)的不足及結(jié)合OMA DM協(xié)議，本文提出基于OMA的移動廣告投放平臺，利用OMA DM協(xié)議中的管理對象和管理命令對移動終端進行有效管理，在此基礎(chǔ)上實現(xiàn)OMA移動廣告投放平臺對數(shù)量龐大的移動終端中的移動廣告管理功能.

1 基于OMA的移動廣告投放平臺設(shè)計

1.1 OMA的DM協(xié)議

OMA DM協(xié)議是OMA組織開發(fā)的一種通過遠程服務(wù)器對網(wǎng)絡(luò)內(nèi)移動終端進行管理的協(xié)議. 它定義一套服務(wù)器和移動終端之間信息交互的標(biāo)準(zhǔn)[8]，DM協(xié)議由DM服務(wù)器和客戶端APP組成，DM服務(wù)器是控制方，客戶端APP是被控制方. 若要實現(xiàn)對移動終端的統(tǒng)一管理，移動終端就要有統(tǒng)一的數(shù)據(jù)格式.為此，DM協(xié)議定義了一些管理對象MO(Management Object)[9]，管理對象內(nèi)置在移動終端的客戶端APP，以樹的形式組織起來，稱為DM管理樹[10]. 管理對象在DM管理樹的位置用統(tǒng)一資源標(biāo)識符URI(Unified Resource Identifier)表示，使用管理命令和管理對象達到管理移動終端的目的. 命令一般有Add、Get、Replace、Exec等，管理命令采用XML編碼，符合SyncML同步規(guī)范語言[11]，客戶端APP通過解析DM服務(wù)器發(fā)送的管理命令執(zhí)行相應(yīng)操作. OMA DM管理模型如圖1所示.

圖1 DM管理模型Fig.1 DM management model

首先，用戶通過瀏覽器登陸并發(fā)起管理操作，DM服務(wù)器下達管理命令，然后移動終端中的客戶端APP解析DM服務(wù)器的命令. 根據(jù)管理命令對管理對象操作，最后返回數(shù)據(jù)和狀態(tài)碼.

1.2 OMA廣告管理系統(tǒng)的設(shè)計

OMA移動廣告投放平臺由OMA廣告管理系統(tǒng)和客戶端APP組成，如圖2所示. OMA廣告管理系統(tǒng)的需求分析包括:(1) 互動性的需求，OMA廣告管理系統(tǒng)投放移動廣告到用戶的移動終端，用戶可以點擊廣告鏈接. (2) 廣告投放效果度量需求，OMA廣告管理系統(tǒng)記錄用戶對廣告的響應(yīng)，為廣告活動提供數(shù)據(jù)，如廣告點擊率[12]. (3) 通信安全需求，對通信的數(shù)據(jù)進行加密，使用SSL進行加密處理，使用Basic和MD5[13]兩種鑒權(quán)機制進行鑒權(quán)，驗證DM消息完整性時使用HMAC-MD5進行驗證. (4) 廣告管理需求，OMA廣告管理系統(tǒng)可以對數(shù)量龐大的移動終端的移動廣告進行管理. OMA廣告管理系統(tǒng)與移動終端之間的DM消息使用WBXML編碼后用HTTP協(xié)議進行承載，傳輸時將HTTP頭中的Content-Type和MIME類型寫為application/vnd.syncml.dm.wbxml.

OMA廣告管理系統(tǒng)模塊如圖3所示，具體內(nèi)容包括:

(1) 用戶注冊模塊和用戶登陸模塊:用戶注冊時調(diào)用注冊模板，填寫注冊角色類型、用戶基本信息、用戶名和密碼，密碼使用MD5算法加密. 用戶登陸時，登陸的用戶角色、用戶名、密碼與數(shù)據(jù)庫中的用戶數(shù)據(jù)一致方可登陸成功.

(2) 廣告添加模塊:用于廣告主將廣告資源上傳到服務(wù)器并存儲到數(shù)據(jù)庫，選擇廣告類型后，加載相應(yīng)的廣告模板，填寫廣告名稱、在某個時間段展示次數(shù)、展示的時間、選擇廣告素材，廣告信息確認(rèn)無誤后選擇提交廣告. 該模塊使用MutipartFiles類getInputStream()方法處理廣告素材得到輸入流，然后再使用Files類copy()方法將廣告素材以輸入流的形式上傳到服務(wù)器.

圖2 OMA移動廣告投放平臺架構(gòu)圖Fig.2 OMA mobile advertising platform architecture diagram

圖3 OMA廣告管理系統(tǒng)模塊圖Fig.3 OMA advertising management system

(3) 廣告計價模塊:使用CPM(Cost Per Milles)計價模型，即每千次展示費用，這種計價方式適用于展示廣告，其計算公式是:Revenue=N×cpm/1 000，N代表廣告展示的次數(shù)，cpm代表每千次展示廣告費用.

(4) 廣告審核模塊:用于審核廣告主上傳的廣告的合法性，審核有兩個步驟，一是自動審查，通過系統(tǒng)自動審查是否有非法字符，每100 s執(zhí)行一次，使用Java.util.TimerTask創(chuàng)建定時任務(wù)機制timerTask，使用Java.util.Timer創(chuàng)建定時任務(wù)timer，然后調(diào)用timer的schedule()方法實現(xiàn)定調(diào)度. 二是人工審查，人工審查是否有錯別字或非法的素材資源，如審核通過，廣告主則可以投放該廣告，否則，將審核不通過原因反饋給廣告主.

(5) 實時控制模塊:控制廣告投放狀態(tài)，有投放廣告需求時，OMA廣告管理系統(tǒng)的應(yīng)用層向廣告服務(wù)管理模塊發(fā)出請求，廣告服務(wù)管理模塊將請求發(fā)給DM服務(wù)器通信管理模塊，使用DM協(xié)議的Put命令對管理對象進行管理，將廣告投放到移動終端的客戶端APP，如需控制廣告停止，則使用Delete命令.

(6) 財務(wù)信息模塊:用于查詢廣告主賬戶余額和現(xiàn)金審核. 廣告主發(fā)出充值或提現(xiàn)請求后，財務(wù)管理人員根據(jù)資金是否到賬，廣告主賬戶余額來決定是否同意廣告主的申請.

(7) 廣告反饋及記錄模塊:收集廣告的反饋信息，如廣告名稱、廣告Id、廣告計費、終端用戶觀看或點擊廣告次數(shù)等信息，然后使用Cewolf開源報表工具進行信息統(tǒng)計.

(8) 系統(tǒng)管理員模塊:負(fù)責(zé)創(chuàng)建和管理用戶，對用戶分配角色、分配角色權(quán)限、管理角色權(quán)限.

(9) 廣告主管理模塊:用于廣告主查詢和修改廣告主個人信息，查詢移動廣告投放效果信息，并控制移動廣告的投放，由此功能模塊可以發(fā)起賬戶充值或提現(xiàn)請求.

(10) 廣告服務(wù)管理模塊:它是OMA廣告管理系統(tǒng)的核心模塊，用于接收應(yīng)用層廣告模塊的請求，并把請求發(fā)送給DM服務(wù)器通信管理模塊，同時將DM服務(wù)器通信管理模塊的響應(yīng)發(fā)送給具體的廣告請求模塊.

(11) DM服務(wù)器通信管理模塊:會話池管理交互雙方會話的創(chuàng)建、存儲和回收，協(xié)議處理機編解碼XML報文，將XML報文轉(zhuǎn)化為WBXML格式進行傳輸，按照OMA DM協(xié)議標(biāo)準(zhǔn)對移動終端進行交互管理.

(12) 接口1:OMA廣告管理系統(tǒng)與移動終端交互的接口，使用OMA DM協(xié)議進行通信.

最后就是DM協(xié)議管理廣告流程:

DM服務(wù)器通信管理模塊收到廣告服務(wù)管理模塊的廣告投放請求時，使用OMA DM協(xié)議的管理命令Put，Put命令表示推送廣告，將移動廣告推送到移動終端的管理樹的對象節(jié)點下，移動終端收到移動廣告后，返回200狀態(tài)碼，表示推送成功，否則推送失敗. 更新廣告時，使用Replace命令，在DM消息中設(shè)置管理對象的URI，使用Replace命令對管理對象進行更新廣告信息. 若要獲取某個廣告的反饋信息時，使用Get命令，指定管理對象的URI，從DM管理樹下的管理對象節(jié)點返回該移動廣告的反饋信息. 當(dāng)廣告主想要刪除某個移動廣告時，使用Delete命令對移動終端管理樹中包含該移動廣告的管理對象節(jié)點進行操作，刪除該廣告，返回狀態(tài)碼，DM協(xié)議管理廣告流程圖如圖4所示.

圖4 DM協(xié)議管理廣告流程圖Fig.4 DM protocol management advertising flow chart

1.3 客戶端APP的設(shè)計

客戶端APP主要是向OMA廣告管理系統(tǒng)發(fā)送設(shè)備注冊請求，將信息注冊到DM服務(wù)器，解析從DM服務(wù)器發(fā)來的管理命令，執(zhí)行管理命令，展示OMA廣告管理系統(tǒng)投放的移動廣告. 客戶端APP組成模塊如圖5所示，客戶端APP主要由手機鑒權(quán)模塊、統(tǒng)計記錄模塊、客戶端注冊模塊、解析命令模塊、連接建立模塊、廣告展示模塊組成，下面介紹一些模塊的設(shè)計方案.

圖5 客戶端APP組成模塊Fig.5 Component module of the client APP

1.3.1 客戶端注冊模塊的設(shè)計

建立會話連接前，先要進行信息引導(dǎo)注冊，移動終端從一個空的、沒有配置DM服務(wù)器信息到能夠向DM服務(wù)器發(fā)起會話的過程，就是引導(dǎo)注冊過程[14]，基于OMA的移動廣告投放平臺引導(dǎo)注冊方式有:(1)客戶端發(fā)起的引導(dǎo)注冊，設(shè)備制造商提前將DM服務(wù)器的信息內(nèi)置在移動終端中. 但這種方式導(dǎo)致引導(dǎo)注冊信息是不可擴展的. (2) DM服務(wù)器發(fā)起的引導(dǎo)注冊，通過終端用戶插入SIM(Subcriber Identity Module)卡個性化移動終端設(shè)置，同時移動終端號碼通知到DM服務(wù)器，DM服務(wù)器知道移動終端地址，便向移動終端發(fā)送引導(dǎo)注冊信息. (3) 智能卡發(fā)起的引導(dǎo)注冊，智能卡中包含有DM服務(wù)器的信息，插入智能卡可使移動終端得到DM服務(wù)器信息并建立會話.本文采用客戶端發(fā)起的引導(dǎo)注冊，客戶端發(fā)起注冊時序圖如圖6所示.

圖6 客戶端發(fā)起注冊時序圖Fig.6 Client registers the DM server with a timing diagram

1.3.2 DM消息處理流程

客戶端APP接收OMA廣告管理系統(tǒng)發(fā)送的DM消息后，首先檢查承載的HTTP報文中是否有xsyncml-hmac字段，若存在該字段則根據(jù)mac摘要值檢驗DM消息的完整性. 完整性驗證成功后，使用解析命令模塊將DM消息的WBXML格式轉(zhuǎn)換為XML格式，XML格式的消息包含SyncML節(jié)點、SyncHdr節(jié)點、SyncBody節(jié)點，SyncML是消息的根節(jié)點，SyncHdr節(jié)點包含消息的基本信息，如管理對象的URI，SyncBody節(jié)點包含消息的主體內(nèi)容. 然后使用SyncML Manager對SyncBody節(jié)點的子節(jié)點進行遍歷，SyncBody的子節(jié)點都是命令，根據(jù)這個命令名稱找到命令對象，然后初始化這個命令對象，根據(jù)SyncHdr節(jié)點中包含的URI對管理對象執(zhí)行命令，得到結(jié)果和狀態(tài).

1.4 數(shù)據(jù)庫設(shè)計

數(shù)據(jù)存儲使用Mysql數(shù)據(jù)庫，存儲廣告主基本信息、廣告及廣告效果、廣告計費、賬戶余額及金額充值記錄、廣告交易記錄和用戶信息. 設(shè)計的數(shù)據(jù)庫由loginUser_table、ad_table、finan_table、trade_table等表組成. 由于篇幅限制，下面主要給出廣告表ad_table的設(shè)計，如表1所示，用戶信息表loginUser_table表的設(shè)計，如表2所示.

表1 ad_table表設(shè)計Tab.1 Design of the ad_table

ad_table表主要用于存儲上傳的廣告信息，記錄廣告投放效果.

表2 loginUser_table表設(shè)計Tab.2 Design of the loginUser_table

loginUser_table表用于記錄登陸用戶信息，驗證用戶身份.

2 實驗與討論

為驗證基于OMA的移動廣告投放平臺的有效性，使用一臺阿里云主機作為服務(wù)器，使用手機用于接收廣告，使用webbench模擬數(shù)量龐大的移動終端，測試移動終端并發(fā)訪問OMA廣告管理系統(tǒng)時的性能.

系統(tǒng)工作流程如下:(1) 客戶端APP向DM服務(wù)器發(fā)送連接請求，廣告主登陸OMA廣告管理系統(tǒng)，在廣告添加模板中向服務(wù)器上傳廣告，然后由廣告管理員進行審核通過.

(2) OMA廣告管理系統(tǒng)進行廣告投放，客戶端APP進行廣告接收并展示，如圖7所示.

圖7 注冊信息與廣告展示Fig.7 Registration information and advertising display

(3) 使用webbench模擬數(shù)量龐大的移動終端，并發(fā)訪問OMA廣告管理系統(tǒng)，在實驗條件相同情況下，將其與文獻[15]的移動廣告平臺對比，文獻[15]的移動廣告平臺性能分析如表3所示，OMA廣告管理系統(tǒng)性能分析如表4所示.

表3 文獻[15]的移動廣告平臺性能分析表Tab.3 Performance analysis table of mobile advertising platform in [15]

實驗結(jié)果表明，數(shù)量龐大的移動終端并發(fā)訪問文獻[15]的移動廣告平臺時，CPU的占用率和內(nèi)存使用率增大較快，該平臺系統(tǒng)性能下降較快. OMA廣告管理系統(tǒng)被數(shù)量龐大的移動終端并發(fā)訪問時，該系統(tǒng)的的總體性能還比較好，能夠有效管理數(shù)量龐大的移動終端的移動廣告，提高系統(tǒng)的穩(wěn)定性和可靠性.

表4 OMA廣告管理系統(tǒng)性能分析表Tab.4 OMA advertising management system performance analysis table

3 總結(jié)

基于OMA的移動廣告投放平臺使用DM協(xié)議對數(shù)量龐大的移動終端的移動廣告進行管理，管理的內(nèi)容主要包括廣告投放、廣告刪除、廣告更新、獲取廣告反饋信息等. DM協(xié)議定義了一些標(biāo)準(zhǔn)的管理對象[16]，如SyncML DM、DevInfo、DevDetail管理對象.

管理對象內(nèi)置在客戶端APP中為DM服務(wù)器統(tǒng)一管理移動廣告提供統(tǒng)一的數(shù)據(jù)格式，為統(tǒng)一管理移動廣告提供保證. 移動終端訪問服務(wù)器時能接收到

OMA廣告管理系統(tǒng)投放的廣告，并且系統(tǒng)的整體性能比較好，實現(xiàn)了對數(shù)量龐大的移動終端移動廣告的管理和投放功能. 而OMA廣告管理系統(tǒng)還未能對用戶實現(xiàn)個性化移動廣告投放，如何實現(xiàn)對用戶個性化移動廣告投放是未來研究的重點.