3G視線 -- 專注手機軟件開發(fā)
MIDPV2。0規(guī)范！
一 簡介：
MIDP v2.0是由JCP(Java Community
Process)制訂的，該規(guī)范的制訂是由大約50個公司共同參與設(shè)計參見附錄一。MIDP
v2.0規(guī)范設(shè)計的目的是定義一體系架構(gòu)，相應(yīng)的APIs，從而為第三方的移動信息設(shè)備（MIDs〕應(yīng)用的開發(fā)提供一開放的標準環(huán)境。
MIDP v2.0規(guī)范是在MIDP v1.0規(guī)范的基礎(chǔ)上設(shè)計的，它保證了同MIDP v1.0的兼容性。即在MIDP v1.0上編寫的MIDlets能在MIDP v2.0上執(zhí)行。
根據(jù)J2ME定義的體系架構(gòu)，MIDP被設(shè)計在CLDC的基礎(chǔ)上運行。關(guān)于CLDC的資料可以參見:
http://jcp.org/jsr/detail/30.jsp.雖然MIDP
v2.0規(guī)范是在CLDC1.0所提供的功能的基礎(chǔ)上制訂的，但它仍能運行在CLDC1.1的基礎(chǔ)上，以及以后的更新版本。但我們希望MIDP
v2.0的實現(xiàn)最好在CLDC1.1的基礎(chǔ)上。
二 J2ME 架構(gòu)：
Java自1995年發(fā)明以來以發(fā)生了很大的變化，從最早的為基于溜覽器中運行的Applet的編程，到
Servlet/EJB的Server編程，再到現(xiàn)在的MIDlet為無線信息設(shè)備的編程。它已發(fā)展成為為開發(fā)者提供一端到端編程開發(fā)的平臺，即我們常說
的
J2SE/J2EE/J2ME,Java的三個平臺(fig1)。由于無線編程有其完全不同于傳統(tǒng)編程的特殊性，比如：運行設(shè)備的多樣性，設(shè)備處理能力不
如服務(wù)器和微機，用戶界面的差異性等。另外在加上無線技術(shù)的飛速發(fā)展，使得J2ME的體系架構(gòu)有者完全不同于J2SE/J2EE的特點。
圖1: Java 的三個平臺
J2ME的架構(gòu)是把我們傳統(tǒng)的Java架構(gòu)：硬件/OS/JVM/APIs/應(yīng)用加一變化，變成了：硬件/OS/Configuration/Progile/應(yīng)用。之所以采用這樣的架構(gòu)是由我們上面所談到的J2ME的特殊性有關(guān)。
圖2: J2ME的架構(gòu)
J2ME/CLDC/MIDP作為J2ME的一個版本，它是專為無線移動通訊設(shè)備說設(shè)計的，在下面我們簡單介紹它的體系架構(gòu)。從下圖中我們可以看到：
圖3: CLDC/MIDP架構(gòu)
1.在CLDC之上有兩類API:
－MIDP APIs: 這些APIs正是MIDP v.0規(guī)范所要定義的APIs.
- OEM-specific APIs: MIDP規(guī)范所涉及的無線通訊設(shè)備多種多樣，因此它不可能 涉及所有設(shè)備 的需求。因此這一類的APIs是由OEM廠商提供以便訪問特定設(shè)備的特定功能。但基于這些APIs的應(yīng)用可能不能在其它的MIDs設(shè)備上運行。
2.MID應(yīng)用的種類：
－MIDP: 一個MIDP應(yīng)用或稱為MIDet，它必需只使用MIDP和CLDC規(guī)范中所定義的APIs。該類應(yīng)用能在應(yīng)是在MID設(shè)備上最常見的應(yīng)用。
－OEM-specific: 一個OEM-specific的應(yīng)用會使用一些不在MIDP中定義的PIs(OEM-specific classes) 。這些應(yīng)用不能在不同的MIDs設(shè)備上運行。
－Native: 一個本地應(yīng)用使指用非Java語言編寫的直接運行于設(shè)備操作系統(tǒng)之上的應(yīng)用。在MIDP規(guī)范中不涉及OEM-specific和Native的應(yīng)用。
三 MID v2.0規(guī)范所涉及的范圍：
我們都知道無線信息設(shè)備（MIDs〕的功能多種多樣。但MIDP規(guī)范并不是要對這些設(shè)備的所有功能都要加以
定義，并提供APIs編程。相反MIDP v1.0和MIDP
v2.0的專家組同意只針對有通用并且成功實施的功能的需求制訂相應(yīng)的APIs。在MIDP v1.0中這些功能包括：
－ 應(yīng)用的下載
－ 應(yīng)用的生命周期
－ 端到端的傳輸(http)
－ 網(wǎng)絡(luò)聯(lián)結(jié)
－ 數(shù)據(jù)庫存儲
－ 計時器
－ 用戶界面
通過用戶對MIDP v1.0的使用經(jīng)驗和反饋，MIDP v2.0的專家組在MIDP v1.0 APIs的基礎(chǔ)上又新加了下面的 APIs:
－ 應(yīng)用的下載和計費
－ 端到端的安全傳輸(https)
－ 應(yīng)用的數(shù)字簽名和域的安全模式
－ MIDlet的push注冊(server push model)
－ 聲音
基于上面所講的同樣的原因，一些功能是不會在MIDP的定義范圍內(nèi)，這些功能包括：
－ 系統(tǒng)層的APIs: MIDP APIs的重點是針對應(yīng)用的開發(fā)者，而不是系統(tǒng)開發(fā)。因此一些底層的涉及系統(tǒng)接口的APIs，比如無線信息設(shè)備的電源管理，語音的編碼模塊就屬于系統(tǒng)層的APIs而不在MIDP所討論的范圍內(nèi)。
－ 底層的安全：MIDP規(guī)范不涉及底層的安全的功能，它只使用CLDC所提供的底層的安全機制。
關(guān)于MIDP v2.0的新APIs在本文中我們不加以介紹。
四 MIDP v2.0的安全機制：
我們知道Java語言作為以種網(wǎng)絡(luò)編程語言，它具有很多特點來滿足網(wǎng)絡(luò)編程的需求，其中最為人們所津津樂道
的是它的遍寫一次到處運行，以及它的安全性。特別是它的安全性，從它的發(fā)明道現(xiàn)在的7年的時間已經(jīng)為無數(shù)的事實所證明。Java語言的安全性，安全機制也
有它發(fā)展的過程，下面我們簡單介紹以下Java的安全機制。
1.Java1.0的沙箱機制：
fig3: Java1.0安全的沙箱機制
上圖所描述的是Java1.0的沙箱機制，它最早是為在溜覽器中運行的Applet所設(shè)計。因
Applet的運行代碼是通過網(wǎng)絡(luò)傳輸?shù)接脩舻臋C器中，為了防止惡意代碼，該機制把用戶應(yīng)用簡單分為本地應(yīng)用和網(wǎng)絡(luò)應(yīng)用(applet)。對網(wǎng)絡(luò)應(yīng)用它只
能放問一些安全的 APIs從而保證安全性。但該機制過于簡單，無法很好滿足開發(fā)者的需求。
2.Java1.1的可信任代碼的安全機制：
fig4: 可信任代碼的安全機制
該安全機制只是在Java1.0沙箱安全機制的基礎(chǔ)上，引入一種新的網(wǎng)絡(luò)應(yīng)用，及可信任的網(wǎng)絡(luò)應(yīng)用，但并未對所訪問的資源進行很好的劃分。大家從圖中可看出，應(yīng)用要嗎受沙箱的約束，只能訪問有限資源，要么就能訪問所有資源。
3.Java1.2/2的域安全機制：
Java1.2/2的域安全機制
該安全機制通過配置文件對Java的應(yīng)用以及訪問的資源進行配置，從而實現(xiàn)了一種非常細化的安全機制。
4.MIDP安全機制及其發(fā)展：
MIDP1.0規(guī)范在制訂時由于當時的無線網(wǎng)絡(luò)尚處于發(fā)展階段，因此在考慮MIDP
v1.0的安全機制時沒有太多考慮應(yīng)用在網(wǎng)絡(luò)傳輸過程中安全性的設(shè)置，而是把重點放在無線應(yīng)用在設(shè)備上的運行過程中的安全性上。因此MIDP1.0規(guī)范通
過沙箱的安全機制來提供MIDlet
suite運行時的安全性，該機制保證MIDlet所能調(diào)用的APIs不能訪問設(shè)備的敏感信息和功能。在MIDP2.0安全機制的制訂過程中，專家組采納
了用戶對MIDP v1.0安全機制所提出的意見：即1.0版本的安全性太“強”使得很多的無線設(shè)備的功能
不能通過MIDP的編程來加以使用。比
如說手機中地址本的訪問等。如果要把這些敏感功能的APIs開放讓用戶的應(yīng)用訪問，就必須引入一種新的安全機制。該機制就是我們前面所描述的
Java1.2/2的域的安全機制。在MIDP v2.0中對不被信任的MIDlet則只能運行于該沙箱安全機制中。任何一種MIDP
v2.0的實現(xiàn)，必需支持非信任的MIDlet的在MIDs設(shè)備上的運行。
MIDP2.0引入了信任的MIDlet的新概念，對于信任的MIDlet它能使用一些敏感的和被限制使用
的APIs.當無線信息設(shè)備檢測到一MIDlet
sute是可信任時，則它對APIs的訪問由相應(yīng)的安全域的策略定義。我們將在下面的章節(jié)中詳悉介紹。當驗證一MIDlet
suite是否能信任時發(fā)生錯誤，則該MIDlet suite必需被拒絕
執(zhí)行。
5.MIDP2.0的域的安全機制：
非信任的MIDlet Suites
一非信任的MIDlet suite是指MIDlet
suite的下載源和JAR文件的完整性不能被下載的設(shè)備所信任。對于非信任的MIDlet
suite必需只能運行于非信任的安全域中，在該域中對受保護的APIs或功能不能訪問或由設(shè)備使用者確定可以訪問或不可以訪問。任何一MIDP1.0兼
容的MIDlet suite能在MIDP v2.0的實現(xiàn)上用非信任的模式運行。對于非信任的MIDlet suites它能訪問它的JAR
manifest和application desctiptor文件以及下面的APIs:
－ javax.microedition.rms
－ javax.microedition.midlet
－ javax.microedition.lcdui
－ javax.microedition.lcdui.game
－ javax.microedition.media
－ javax.microedition.media.control
非信任安全域?qū)σ韵翧PIs或功能的訪問必須由用戶確定可以或不可以：
－ javax.microedition.io.HttpConnection
－ javax.microedition.io.HttpsConnection
可信任的 MIDlet Suite 的安全：
可信任的 MIDlet Suite 的安全是建立在保護域的機制上。每一保護域定義了該域中的
MIDlet suite 的訪問權(quán)限。該保護域的定義者可以定義設(shè)備怎樣確認和驗證它能信任的 MIDlet suite
并把該域所允許和授權(quán)使用的受保護的APIs和功能綁定給該MIDlet suite。設(shè)備所使用的驗證和信任MIDlet
suite的機制的定義是分開的，這樣有利于人們根據(jù)設(shè)備，網(wǎng)絡(luò)，和商業(yè)模式的不同來進行選擇。可信任的 MIDlet Suites使用X.509
PKI的簽名和驗證機制來確定一MIDlet suites的可信任性。
在MIDP2.0的域的安全機制中，大家主要回涉及以下概念：
保護域： 是MIDlet suite所允許的權(quán)限訪問的集合
權(quán)限訪問： 是指必須通過授權(quán)才能使用的 APIs 或功能
信任MIDlet Suite： 指該MIDlet suite能通過驗證并其JAR文件的完整性能被保證，并能被該設(shè)備上的某一保護域所信任。
配置文件： 一配置文件中包含許多域或別名的定義。每一域由包含所賦于的權(quán)限和用戶操作所構(gòu)成。
配置文件的例子：
domain: O= MIDlet Underwriters, Inc. , C=US
allow: javax.microedition.io.HttpConnection
oneshot(oneshot): javax.microedition.io.CommConnection
alias: client_connections javax.microedition.io.SocketConnection, javax.microedition.io.SecureConnection,
javax.microedition.io.HttpConnection,
javax.microedition.io.HttpsConnection
domain: O=Acme Wireless, OU=Software Assurance
allow: client_connections
allow: javax.microedition.io.ServerSocketConnection, javax.microedition.io.UDPDatagramConnection
oneshot(oneshot): javax.microedition.io.CommConnection
domain: allnet
blanket(session): client_connections
oneshot: javax.microedition.io.CommConnection
五. 總結(jié)：
MIDP v2.0是為廣大的開發(fā)者在無線移動通訊設(shè)備上提供的一個開放的Java平臺，它具有開放性，通用性，以及比MIDP v1.0更強的安全功能。它是由全球約五十多家廠商所共同制定的，因此基于MIDP v2.0的應(yīng)用在將來回有很廣泛的應(yīng)用前景。
附錄一：MIDP v2.0 的專家組:
公司：
4thpass Inc, AGEA Corporation, Alcatel, Aplix
Corporation, AromaSoft Corp, Baltimore Technologies CELLon France,
Distributed Systems Technology Centre, Elata PLC, Esmertec, Espial
Group Inc, France Telecom / Orange, Fujitsu Limited, German Aerospace
Center (DLR), Institute of Communications and Navigation, Hitachi
Ltd./Digital Media Group, In Fusio, J-PhoneEast Co. Ltd, Logica Mobile
Networks, Mitsubishi Electric Corp, Mobile Scope AG, Mobilitec,
Motorola, NEC Corporation, Nextel Communications Inc, Nokia, NTT
DoCoMo, Inc, Omnitel Pronto Italia S.p.A, One 2 One, Openwave Systems
,
Inc, Orange (UK), Palm, Philips Consumer Communications, Philips
Semiconductors, Research In Motion (RIM), Samsung Electronics Co., Ltd,
Sharp Labs, Siemens AG, Siemens ICM, Smart Fusion, Sony Ericsson Mobile
Communications, Sun Microsystems, Inc, Symbian Ltd, Telef'nica M'viles
Espa'a, Vaultus, Inc, Veloxsoft, Inc, Vodafone Global Platform &
Internet Services, Vodafone Group Services Limited, Vodafone
Multimedia, Zucotto Wireless,
個人：
Fabio Ciucci, Glen Cordrey, Jon Eaves, David Hook, Myank Jain, Neil Katin, Steve Ma, Ravi Reddy Wai Kit Tony Fung