一種基于J2ME的移動(dòng)支付系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

摘要：移動(dòng)支付是移動(dòng)電子商務(wù)中的最重要的部分之一。安全性、私密性、易用性是移動(dòng)支付的最重要的幾個(gè)問(wèn)題。目前有許多不同種類(lèi)的技術(shù)能夠實(shí)現(xiàn)移動(dòng)支付，其中J2ME憑借其多種顯著的優(yōu)勢(shì)成為了佼佼者。移動(dòng)支付系統(tǒng)也有多種體系架構(gòu)，其中以第三方支付平臺(tái)為中心的架構(gòu)比較靈活、具有很強(qiáng)的可擴(kuò)展性。本文討論一個(gè)基于J2ME的以第三方支付平臺(tái)為中心的移動(dòng)支付系統(tǒng)的特點(diǎn)和優(yōu)越性，并給出這個(gè)系統(tǒng)詳細(xì)的設(shè)計(jì)與實(shí)現(xiàn)過(guò)程。
關(guān)鍵詞：移動(dòng)支付;J2ME;XML加密;XML簽名

1、 引言

當(dāng)前移動(dòng)付費(fèi)已經(jīng)相當(dāng)普及，并受到來(lái)自銀行、零售業(yè)等移動(dòng)行業(yè)以外企業(yè)的關(guān)注。移動(dòng)支付是指交易雙方為通過(guò)手機(jī)、PDA、移動(dòng)PC等移動(dòng)設(shè)備進(jìn)行商業(yè)交易。

移動(dòng)支付根據(jù)涉及的金額的不同，一般可以分為以下兩類(lèi)：

1）微支付（小額支付）：微支付是指交易額少于10美元，通常是指購(gòu)買(mǎi)移動(dòng)內(nèi)容業(yè)務(wù)。

2）宏支付：宏支付是指交易金額較大的支付行為。

對(duì)于宏支付方式來(lái)說(shuō)，通過(guò)可靠的金融機(jī)構(gòu)進(jìn)行交易鑒權(quán)是非常必要的；而對(duì)于微支付來(lái)說(shuō)，使用移動(dòng)網(wǎng)絡(luò)本身的SIM卡鑒權(quán)機(jī)制就能夠達(dá)到較高的安全性了。

與傳統(tǒng)支付方式的比較，移動(dòng)支付的最大特點(diǎn)是交易靈活，方便快捷。但由于安全性和易用性問(wèn)題未得到很好的解決，目前國(guó)內(nèi)的移動(dòng)支付主要是小額支付為主。目前能夠實(shí)現(xiàn)移動(dòng)支付的技術(shù)從理論上來(lái)說(shuō)有很多，如SMS、WAP、J2ME等增值服務(wù)技術(shù)均能夠滿(mǎn)足移動(dòng)支付業(yè)務(wù)的基本需要。其中J2ME憑借其可移植性、強(qiáng)大的JDK支持等等顯著的優(yōu)勢(shì)成為了未來(lái)移動(dòng)支付技術(shù)的首選。

2、 系統(tǒng)的分析與設(shè)計(jì)

2．1 移動(dòng)支付系統(tǒng)的基本組成部分

移動(dòng)支付系統(tǒng)一般可以分為以下基本組成部分：

1） 移動(dòng)運(yùn)營(yíng)商：移動(dòng)運(yùn)營(yíng)商的主要任務(wù)是為移動(dòng)支付提供通信渠道。

2） 金融機(jī)構(gòu)：一般是銀行，為用戶(hù)、商家之間的交易提供了不使用現(xiàn)金的渠道。

3） 移動(dòng)支付平臺(tái)提供商：第三方移動(dòng)支付平臺(tái)提供商是運(yùn)營(yíng)商和金融機(jī)構(gòu)之間的銜接環(huán)節(jié)。

4） 用戶(hù)商家。

2．2 以第三方移動(dòng)支付平臺(tái)為中心的設(shè)計(jì)模式

目前，移動(dòng)支付系統(tǒng)的設(shè)計(jì)模式主要有以下三種：

1） 以移動(dòng)運(yùn)營(yíng)商為中心的設(shè)計(jì)模式；

2） 以銀行為中心的設(shè)計(jì)模式；

3） 以第三方移動(dòng)支付平臺(tái)提供商為中心的設(shè)計(jì)模式。

其中，以第三方移動(dòng)支付平臺(tái)提供商為中心的設(shè)計(jì)模式如圖1所示，它具有簡(jiǎn)單、便捷、跨領(lǐng)域操作等另外兩種設(shè)計(jì)模式所不具備優(yōu)點(diǎn)。

2．3 移動(dòng)支付系統(tǒng)運(yùn)作流程

以第三方移動(dòng)支付平臺(tái)提供商為中心的移動(dòng)支付系統(tǒng)的運(yùn)作流程如下：

1） 用戶(hù)發(fā)交易短信到移動(dòng)支付平臺(tái)提供商的服務(wù)號(hào)；

2） 支付平臺(tái)收到短信后進(jìn)行服務(wù)識(shí)別，并向用戶(hù)回復(fù)確認(rèn)消息；

3） 用戶(hù)收到確認(rèn)短信后回復(fù)，確認(rèn)此次交易；

4） 支付平臺(tái)收到確認(rèn)短信后，根據(jù)商品編號(hào)、價(jià)格以及相關(guān)注冊(cè)信息等查詢(xún)到用戶(hù)的銀行卡號(hào)碼；

5） 支付平臺(tái)嘗試向銀行發(fā)出扣費(fèi)請(qǐng)求，如果扣費(fèi)成功則轉(zhuǎn)入6），否則下發(fā)短信給用戶(hù)提示交易失敗；

6） 扣費(fèi)成功，向用戶(hù)發(fā)送確認(rèn)短信，同時(shí)告知相關(guān)移動(dòng)支付系統(tǒng)交易成功，交易結(jié)束。

2．4 系統(tǒng)實(shí)現(xiàn)的重點(diǎn)

1） 安全性問(wèn)題

由于無(wú)線(xiàn)網(wǎng)絡(luò)本身幾乎不提供安全保護(hù)措施，因此移動(dòng)支付過(guò)程中可能受到多種的攻擊行為。要實(shí)現(xiàn)安全的無(wú)線(xiàn)交易，必須要解決以下幾個(gè)問(wèn)題：

鑒權(quán)（Authentication）：通信雙方必須標(biāo)識(shí)其本身，沒(méi)有經(jīng)過(guò)鑒權(quán)的通信方將不能夠進(jìn)行下一步操作。

數(shù)據(jù)完整性（Integrity）：確保交易他方或非法入侵者不能對(duì)交易的內(nèi)容進(jìn)行修改，從而保證通信中的接收方收到的是原文。

數(shù)據(jù)機(jī)密性（Confidentiality）：防止合法或隱私數(shù)據(jù)為非法用戶(hù)所獲得，從而確保在交易過(guò)程中只有交易的雙方才能唯一知道交易的內(nèi)容。

不可否認(rèn)性（Non－repudiation）：確保交易行為正確性，交易雙方均不能否認(rèn)交易行為產(chǎn)生的事實(shí)。

2） 開(kāi)發(fā)移動(dòng)終端設(shè)備的應(yīng)用程序的限制

開(kāi)發(fā)移動(dòng)終端設(shè)備的應(yīng)用程序要受到多種條件的限制如：芯片處理能力弱，存儲(chǔ)空間小，堆內(nèi)存小，屏幕尺寸有限，按鍵少，網(wǎng)絡(luò)帶寬不足等。

2．5 安全性問(wèn)題解決方法

要保護(hù)通信安全，實(shí)現(xiàn)安全的無(wú)線(xiàn)交易，必須要解決通信過(guò)程中的鑒權(quán)，數(shù)據(jù)完整性，數(shù)據(jù)機(jī)密性和不可否認(rèn)性這幾個(gè)問(wèn)題。而數(shù)據(jù)加密和數(shù)字簽名兩種安全措施的利器正好可以達(dá)到這個(gè)目的。

數(shù)據(jù)加密的方式多種多樣，如使用已經(jīng)很成熟的SSL/TLS和HTTPS對(duì)網(wǎng)絡(luò)連接進(jìn)行加密，從而保護(hù)數(shù)據(jù)。此外其加密算法也同樣有很多的選擇，常用的有Triple DES、RSA等等算法。系統(tǒng)采用Triple DES來(lái)加密傳輸?shù)臋C(jī)密數(shù)據(jù)，RSA算法來(lái)加密Triple DES的密匙。

數(shù)字簽名解決以下問(wèn)題：

鑒權(quán)：由于私匙與公匙是一一對(duì)應(yīng)的，并且私匙只有用戶(hù)才能夠持有，因此實(shí)際上私匙成為了用戶(hù)的身份的唯一標(biāo)志，就像一般的用戶(hù)名/密碼一樣可以在鑒權(quán)過(guò)程中識(shí)別用戶(hù)身份。

數(shù)據(jù)完整性：數(shù)據(jù)完整性主要是保證內(nèi)容不被篡改。在數(shù)字簽名的流程中，接收方在收到簽名及其原始消息后，會(huì)按照消息原文再生成一次摘要，然后與用公匙解密的摘要進(jìn)行對(duì)比驗(yàn)證。因此即使入侵者修改了原文，也會(huì)因?yàn)闊o(wú)法通過(guò)對(duì)比驗(yàn)證而達(dá)不到破壞的目的。

不可否認(rèn)性：因?yàn)樘囟ǖ暮灻畔⒅荒苡赡硞€(gè)用戶(hù)通過(guò)私匙進(jìn)行簽名，而不能由任何其他人實(shí)現(xiàn)，因此用戶(hù)無(wú)法否認(rèn)經(jīng)過(guò)自己簽名的信息。

這里選擇XML作為客戶(hù)端與服務(wù)器通信的數(shù)據(jù)載體。使用XML不但可以以清晰的邏輯表示復(fù)雜的嵌套的數(shù)據(jù)結(jié)構(gòu)，而且因?yàn)閄ML是當(dāng)今互聯(lián)網(wǎng)的主流的通信接口的標(biāo)準(zhǔn)，有很好的兼容性與擴(kuò)展性。所以我們將使用XML加密與XML簽名解決本系統(tǒng)的安全性問(wèn)題。

3、 J2ME客戶(hù)端的實(shí)現(xiàn)

整個(gè)J2ME客戶(hù)端的邏輯架構(gòu)是由若干個(gè)功能模塊組成的，這些功能模塊覆蓋了網(wǎng)絡(luò)通信、用戶(hù)界面、安全等各個(gè)方面的職能，并通過(guò)模塊間的通信共同實(shí)現(xiàn)了移動(dòng)支付系統(tǒng)客戶(hù)端的功能。

邏輯結(jié)構(gòu)如圖2所示，其中A～F的意義如下：

A：用戶(hù)請(qǐng)求交易 / 交易操作結(jié)果

B：用戶(hù)輸入的交易請(qǐng)求信息 / 服務(wù)器端返回的交易結(jié)果

D：經(jīng)過(guò)XML簽名的已加密請(qǐng)求信息 / 解析過(guò)的XML返回結(jié)果

E：組裝好的經(jīng)過(guò)XML簽名的已加密請(qǐng)求信息的XML數(shù)據(jù)包 / 網(wǎng)絡(luò)通信模塊接收到的XML數(shù)據(jù)包

F：發(fā)向服務(wù)器的XML數(shù)據(jù)包 / 接收到的來(lái)自服務(wù)器的XML數(shù)據(jù)包

黑色雙箭頭所表示的是J2ME特有的RMS數(shù)據(jù)庫(kù)的數(shù)據(jù)。數(shù)據(jù)庫(kù)訪問(wèn)模塊負(fù)責(zé)調(diào)用J2ME的RMS數(shù)據(jù)庫(kù)的功能接口，對(duì)用戶(hù)界面模塊用的個(gè)性化設(shè)置，XML加密和簽名用的私匙和公匙對(duì)，網(wǎng)絡(luò)通信模塊用的HTTP訪問(wèn)地址和設(shè)置等等數(shù)據(jù)進(jìn)行存取，而其它模塊則通過(guò)訪問(wèn)數(shù)據(jù)庫(kù)模塊存取所需數(shù)據(jù)。

在客戶(hù)端系統(tǒng)的實(shí)現(xiàn)中，使用了一些第三方API庫(kù)：kXML和Bouncy Castle API。其中kXML是XML組裝/解析的工具，而B(niǎo)ouncy Castle API是J2ME應(yīng)用程序?qū)Ｓ玫腦ML加密/解密和簽名/驗(yàn)證的工具。

客戶(hù)端部分的主要模塊實(shí)現(xiàn)如下：

1） 數(shù)據(jù)庫(kù)訪問(wèn)模塊

數(shù)據(jù)庫(kù)訪問(wèn)模塊是所有其它模塊需要用到的模塊，這是因?yàn)樗颜麄€(gè)J2ME客戶(hù)端需要用到的程序配置和用戶(hù)設(shè)置存取到J2ME的數(shù)據(jù)庫(kù)中。在J2ME MIDP中定義了一個(gè)簡(jiǎn)單的基于記錄的數(shù)據(jù)庫(kù)管理系統(tǒng)（Record Management System，RMS），在RMS中Record Store等同于一般數(shù)據(jù)庫(kù)系統(tǒng)中的表（Table），它是記錄了一系列記錄的文件。

數(shù)據(jù)庫(kù)訪問(wèn)模塊對(duì)RMS進(jìn)行操作，并對(duì)外部模塊提供了兩個(gè)存取數(shù)據(jù)的接口：

按名稱(chēng)保存數(shù)據(jù)到RMS的接口：public void setDataToRecordStore(String name, String data)

按名稱(chēng)從RMS獲取數(shù)據(jù)的接口：public String getDataFromRecordStore(String name)

2） 用戶(hù)界面模塊

用戶(hù)界面模塊實(shí)現(xiàn)人機(jī)交互工能，接收用戶(hù)輸入，并把操作結(jié)果以友善的形式進(jìn)行輸出。除了使用J2ME提供的Display、Screen、Label、Command、Alert、Form、TextField等高級(jí)用戶(hù)界面控件外，還需要使用J2ME提供的Canvas、Image等等低級(jí)用戶(hù)界面API，來(lái)實(shí)現(xiàn)動(dòng)畫(huà)等特效。

3） XML加密/解密模塊

這兩個(gè)模塊負(fù)責(zé)對(duì)服務(wù)器端傳來(lái)的用RSA算法公匙加密的共享密匙進(jìn)行解密，然后用共享密匙對(duì)機(jī)密信息使用Triple DES算法進(jìn)行加密。

通過(guò)使用Bouncy Castle API密碼術(shù)包，我們可以輕松地對(duì)所需要傳輸?shù)慕灰渍?qǐng)求里面的機(jī)密信息進(jìn)行XML加密和解密。它所提供的org.bouncycastle.crypto包有加密/解密中需要用到的絕大部分的類(lèi)，另外org.bouncycastle.util包提供了包括Base64編碼轉(zhuǎn)換、Hex編碼轉(zhuǎn)換等有用的工具類(lèi)。在Bouncy Castle API中，公匙、私匙和共享密匙都是對(duì)象，在試圖使用它們之前，必須要通過(guò)它們的主要參數(shù)重構(gòu)出這些密匙對(duì)象。RSA的公匙有Modulus和Exponent兩個(gè)主要參數(shù)，RSA私匙除了這兩個(gè)參數(shù)外，還有privExp、dp、dq、p、q、qInv等幾個(gè)參數(shù)，而Triple DES共享密匙只有單一的key參數(shù)。在傳遞這些密匙參數(shù)或加密的相關(guān)信息時(shí)，由于XML加密的很多元素指定使用Base64編碼，因此還需要用到Base64這個(gè)工具類(lèi)。我們定義了一個(gè)Encryptor類(lèi)來(lái)處理所有加密/解密的相關(guān)的問(wèn)題。定義的接口如下：

TripleDES加密接口：public byte[] encryptTripleDES (byte[] data) throws CryptoException

RSA解密接口：public synchronized byte[] decryptRSA(byte[] data) throws CryptoException

4） XML簽名/驗(yàn)證模塊

XML簽名過(guò)程中，首先生成原始數(shù)據(jù)的摘要，再對(duì)摘要進(jìn)行簽名。生成摘要的算法一般使用SHA1算法。Bouncy Castle API包同樣提供了生成簽名用的摘要的SHA1Digest類(lèi)，以及用于數(shù)字簽名的RSAEngine、PSSSigner等類(lèi)。我們定義Signature類(lèi)封裝所有的處理簽名的功能代碼。定義的接口如下：

生成摘要：private byte[] getDigest(String mesg) throws Exception

使用RSA私匙簽名：public byte[] RSASign(byte[] toSign) throws Exception

5） XML組裝/解析模塊

為了簡(jiǎn)化問(wèn)題，XML組裝可以使用簡(jiǎn)單的字符串拼接來(lái)實(shí)現(xiàn)，而對(duì)于XML解析工作，我們使用kXML來(lái)處理。它是一個(gè)只占很小存儲(chǔ)空間的XML語(yǔ)法分析程序，對(duì)于J2ME應(yīng)用程序非常適合。

kXML有一個(gè)非常獨(dú)特的DOM操作方法和被稱(chēng)為Pull的語(yǔ)法分析方法。DOM是一個(gè)與XML相互作用的簡(jiǎn)單方法，通常這個(gè)XML是一棵完整的XML樹(shù)，被解析成一個(gè)存放在存儲(chǔ)器中的節(jié)點(diǎn)結(jié)構(gòu)，可以通過(guò)遍歷這棵樹(shù)獲取所有節(jié)點(diǎn)信息。它非常簡(jiǎn)單易用，但是因?yàn)檎脴?shù)存在于存儲(chǔ)器中造成存儲(chǔ)器的負(fù)擔(dān)。與DOM不同，Pull語(yǔ)法分析讓程序員從語(yǔ)法分析程序中"拉"出下一個(gè)事件，Pull語(yǔ)法分析使處理狀態(tài)改變更加容易，因?yàn)槟憧梢园l(fā)送分析器到不同的函數(shù)，維護(hù)它們自己的狀態(tài)變量。此外，Pull特別適用于J2ME環(huán)境中的需要保持盡可能地少的內(nèi)存占用的情況，因此我們采用Pull方法進(jìn)行XML的解析。定義接口如下：

根據(jù)XML節(jié)點(diǎn)名稱(chēng)獲取對(duì)應(yīng)值：private String getXMLNodeValue(String nodeName)

6） 網(wǎng)絡(luò)通信模塊

在J2ME的MIDP 1.0 API中，網(wǎng)絡(luò)通信協(xié)議支持UDP、HTTP、Socket等等。雖然從理論上說(shuō)可以使用Socket或UDP協(xié)議與外界進(jìn)行通信，但是一些廠商的MIDP設(shè)備可能不支持這些協(xié)議，使用這些協(xié)議進(jìn)行通信可能造成程序移植上的問(wèn)題。而HTTP由于是當(dāng)今互聯(lián)網(wǎng)最主要的通信協(xié)議，因此基本上所有廠商的移動(dòng)終端設(shè)備都支持HTTP協(xié)議。因此我們采用HTTP協(xié)議進(jìn)行通信。下面給出發(fā)送和接收數(shù)據(jù)的代碼：public String sendAndReceiveByHttp(String url, String strToSend) throws Exception

{

HttpConnection hc = (HttpConnection)Connector.open(url, Connector.READ_WRITE);

hc.setRequestMethod(HttpConnection.POST);

hc.setRequestProperty(“Connection”, “Keep-Alive”);

DataOutputStream dos = hc.openDataOutputStream();

dos.writeUTF(strToSend);//向目的URL發(fā)送數(shù)據(jù)

dos.flush();

dos.close();

DataInputStream dis = hc.openInputStream();

String strReceived = dis.readUTF();//接收目的URL的響應(yīng)數(shù)據(jù)

dis.close();

return strReceived;

}

4、 J2EE服務(wù)器端的實(shí)現(xiàn)

服務(wù)器端包含一些重要的模塊，如多個(gè)對(duì)外接口，后臺(tái)管理子系統(tǒng)，商家自服務(wù)子系統(tǒng)，OTA下載等等。這里我們對(duì)那些與J2ME客戶(hù)端重復(fù)的功能模塊如XML解析、加密、簽名等等略去不提，而把重點(diǎn)放在服務(wù)器端的獨(dú)有的實(shí)現(xiàn)細(xì)節(jié)上。服務(wù)器端邏輯結(jié)構(gòu)圖3所示。

A：由2.3描述的移動(dòng)支付交易流程的各個(gè)步驟。

B：用戶(hù)通過(guò)在網(wǎng)站或通過(guò)發(fā)送短信點(diǎn)播WapPush鏈接的方式，由OTA服務(wù)器提供MIDlet的下載。其中每個(gè)MIDlet都已經(jīng)內(nèi)嵌了RSA的私匙－公匙對(duì)，而這些密匙對(duì)是由RSA密匙對(duì)管理模塊維護(hù)的。

C：商家登錄自服務(wù)子系統(tǒng)進(jìn)行注冊(cè)帳號(hào)，發(fā)布、修改或刪除商品的信息。

服務(wù)器端的主要模塊的實(shí)現(xiàn)如下：

1） 交易接口及交易流程管理模塊：交易接口是指移動(dòng)支付流程中負(fù)責(zé)處理服務(wù)器端與外界交互的業(yè)務(wù)邏輯的模塊，包括了用戶(hù)交易接口、銀行交易接口和商家交易接口。用戶(hù)交易接口負(fù)責(zé)處理與J2ME客戶(hù)端的交互，銀行交易接口負(fù)責(zé)處理使用用戶(hù)指定的銀行卡扣費(fèi)的業(yè)務(wù)邏輯，商家交易接口負(fù)責(zé)處理通知商家交易結(jié)果的業(yè)務(wù)邏輯。而這三個(gè)接口由交易流程管理模塊進(jìn)行整體上的協(xié)調(diào)管理。我們?cè)O(shè)計(jì)了一個(gè)交易記錄表TradeHistory來(lái)記錄必要的交易信息。

2） Triple DES密匙管理模塊：J2ME客戶(hù)端用于加密的Triple DES共享密匙是由服務(wù)器端接收到交易請(qǐng)求后，由系統(tǒng)隨機(jī)產(chǎn)生的，并同時(shí)產(chǎn)生與之對(duì)應(yīng)的密匙名稱(chēng)，并由CarriedKeyName元素把名稱(chēng)帶回給J2ME客戶(hù)端。之后，系統(tǒng)把密匙名稱(chēng)和密匙都存放到數(shù)據(jù)庫(kù)，在下一次有用該密匙加密的數(shù)據(jù)需要解密時(shí)，才從數(shù)據(jù)庫(kù)中根據(jù)密匙名稱(chēng)查找出密匙進(jìn)行解密。系統(tǒng)通過(guò)表DESede_Keys來(lái)存放TripleDES密匙。

3） OTA下載模塊：用戶(hù)通過(guò)Wap Push進(jìn)入到OTA服務(wù)器提供的MIDlet的下載鏈接，從而獲取到MIDlet應(yīng)用。OTA下載模塊主要是需要對(duì)Resin服務(wù)器做一些相應(yīng)的設(shè)置，以及獲取RSA密匙對(duì)嵌入MIDlet中。

4） RSA密匙對(duì)管理模塊：RSA私匙－公匙組成的密匙對(duì)可用Bouncy Castle密碼術(shù)包生成。生成了密匙對(duì)后，需要把密匙對(duì)的主要參數(shù)存儲(chǔ)到數(shù)據(jù)庫(kù)中，供OTA下載模塊獲取并分配給每個(gè)不同的MIDlet應(yīng)用實(shí)例。系統(tǒng)通過(guò)表RSA_Key_Params來(lái)存儲(chǔ)RSA密匙對(duì)的主要參數(shù)。

5） 商家自服務(wù)子系統(tǒng)：商家自服務(wù)系統(tǒng)是提供給商家注冊(cè)基本資料和發(fā)布、編輯商品的一個(gè)Browser/Server架構(gòu)的子系統(tǒng)。該子系統(tǒng)通過(guò)以下兩個(gè)表來(lái)存儲(chǔ)相關(guān)信息：商家基本信息表Sale_Info和商品資料表Product_Info。

6） 后臺(tái)管理子系統(tǒng)：管理員可以使用后臺(tái)管理子系統(tǒng)進(jìn)行平臺(tái)的各方面的設(shè)置，如增刪帳號(hào)，審批商家的注冊(cè)申請(qǐng)，監(jiān)督商品的發(fā)布情況，以及監(jiān)控交易的情況等等。

7） 數(shù)據(jù)庫(kù)訪問(wèn)模塊：數(shù)據(jù)庫(kù)訪問(wèn)模塊：不同于J2ME客戶(hù)端的數(shù)據(jù)庫(kù)訪問(wèn)模塊，服務(wù)器的數(shù)據(jù)庫(kù)訪問(wèn)模塊可以做的更加強(qiáng)大。為應(yīng)付高強(qiáng)度的數(shù)據(jù)庫(kù)訪問(wèn)操作，可以針對(duì)查詢(xún)和更新操作在程序這個(gè)級(jí)別上進(jìn)行優(yōu)化。對(duì)查詢(xún)操作設(shè)立一個(gè)查詢(xún)結(jié)果的緩沖區(qū)，將最近查詢(xún)或查詢(xún)頻率較高的查詢(xún)結(jié)果保存在緩沖區(qū)內(nèi)，以便以后的查詢(xún)就可以直接訪問(wèn)緩沖區(qū)（內(nèi)存）而不必每次進(jìn)行數(shù)據(jù)庫(kù)操作；對(duì)于更新操作，采用緩寫(xiě)機(jī)制，接收到更新操作的請(qǐng)求后不馬上訪問(wèn)數(shù)據(jù)庫(kù)，而是放入緩沖區(qū)，等積累到一定數(shù)量的操作后進(jìn)行數(shù)據(jù)庫(kù)操作的批處理，或是定時(shí)把緩沖區(qū)中的更新操作執(zhí)行掉一部分。

5、 結(jié)束語(yǔ)

本論文創(chuàng)新點(diǎn)：論文分析了移動(dòng)支付系統(tǒng)的三種方案，提出了一種以第三方支付平臺(tái)為中心的移動(dòng)支付系統(tǒng)架構(gòu)，并討論在J2ME環(huán)境下原型系統(tǒng)的客戶(hù)端及服務(wù)端的技術(shù)方案設(shè)計(jì), 給出支付系統(tǒng)中的安全性解決方法。該系統(tǒng)經(jīng)實(shí)際測(cè)試，性能良好，可較好的解決安全性和易用性問(wèn)題，是一種較佳的移動(dòng)支付解決方案。

參考文獻(xiàn)
[1] Cay S.Horstmann，Gary Cornell，（譯）京京工作室，Java 2核心技術(shù)［M］，機(jī)械工業(yè)出版社，2001.6
[2] Paul Tremblett，（譯）王伯欣，J2ME無(wú)線(xiàn)Java應(yīng)用開(kāi)發(fā)［M］，人民郵電出版社，2002.9
[3] 盧軍，J2ME應(yīng)用程序開(kāi)發(fā)－手機(jī)、PDA程序開(kāi)發(fā)捷徑［M］，中國(guó)鐵道出版社，2002.9
[4] 聞怡洋，J2ME MIDP 1.0/2.0無(wú)線(xiàn)設(shè)備編程指南［M］，北京大學(xué)出版社，2004.7
[5] Kim Topley，（譯）張伶，林琪，J2ME技術(shù)手冊(cè)［M］，中國(guó)電力出版社，2004.2
[6] 崔巖， 劉永杰，周玉潔，一種適用于移動(dòng)電子商務(wù)的微支付方案[J]， 計(jì)算機(jī)工程與應(yīng)用， 2005年 第 41卷 第35期，P125-128
[7] 陳思，何煒，居悌;基于開(kāi)放服務(wù)架構(gòu)的移動(dòng)支付平臺(tái)[J]， 計(jì)算機(jī)工程, 2003年 第29卷 第20期，P165-168
[8] 何國(guó)輝, 甘俊英, 基于手機(jī)的移動(dòng)電子商務(wù)應(yīng)用研究[J], 微計(jì)算機(jī)信息， 2006年第22卷 第2-3期，P137-139