【正文】 臺(tái)發(fā)展的重點(diǎn)項(xiàng)目。 J2ME 在設(shè)計(jì)其規(guī)格的時(shí)候,遵循著 “對各種不同的裝置而造出一個(gè)單一的開發(fā)系 統(tǒng)是沒有意義的事”這個(gè)基本原則。 圖 1 Java 平臺(tái)的結(jié)構(gòu) 于是 J2ME 先將所有的嵌入式裝置大體上區(qū)分為兩種:一種是運(yùn)算功能有 限、電力供應(yīng)也有限的嵌入式裝置(比方說 PDA 、手機(jī))；另外一種則是運(yùn)算能 力相對較佳、 在電力供應(yīng)上相對比較充足的嵌入式裝置 (比方說冷氣機(jī)、 電冰箱、 電視機(jī)上盒 (settop box))。因?yàn)檫@兩種型態(tài)的嵌入式裝置，所以 Java 引入了一 個(gè)叫做 Configuration 的概念，把上述運(yùn)算功能有限、電力有限的嵌入式裝置定 義在 Connected Limited Device Configuration(CLDC)規(guī)格之中；而另外一種裝置 第 2 頁 共 26 頁 則規(guī)范為 Connected Device Configuration(CDC)規(guī)格。也就是說,J2ME 先把所有 的嵌入式裝置利用 Configuration 的概念區(qū)隔成兩種抽象的型態(tài)。J2ME 平臺(tái)被認(rèn) 為是最杰出的手機(jī)游戲平臺(tái),它為開發(fā)者、設(shè)備制造商、網(wǎng)絡(luò)通信公司和消費(fèi)者 廣泛接受。它有一些非常重要的特征對所有組織都有益。因?yàn)?J2ME 應(yīng)用在不同 設(shè)備上都是便攜式的,他們常?？稍诰W(wǎng)絡(luò)上下載和執(zhí)行。如果沒有正確的防范， 它則為用戶和無線通信公司冒著無數(shù)個(gè)安全的風(fēng)險(xiǎn)。幸運(yùn)的是，Java 被設(shè)計(jì)成一 種安全的語言。所有字節(jié)碼應(yīng)用在執(zhí)行之前都要校驗(yàn)；JVM 在執(zhí)行過程中監(jiān)督 應(yīng)用的安全性和存儲(chǔ)違反問題。MIDP v2 運(yùn)行時(shí)間包括一個(gè)完全特征化的、基 于域的安全管理員，它在應(yīng)用的數(shù)字簽名者鑒別的基礎(chǔ)上賦予應(yīng)用 API 級許可。 J2ME 體系結(jié)構(gòu) J2ME 體系結(jié)構(gòu)是基于設(shè)備的系列和類別的。一個(gè)類別定義了一個(gè)特定種類 的設(shè)備：移動(dòng)電話、簡單尋呼機(jī)和電腦記事本都是單獨(dú)的類別。對存儲(chǔ)器和處理 能力有相近需求的若干類別的設(shè)備構(gòu)成設(shè)備的一個(gè)系列。移動(dòng)電話、簡單尋呼機(jī) 和簡單個(gè)人電腦記事本一起就是占用資源很小的設(shè)備的一個(gè)系列。 圖 2 定義了在 J2ME 上下文環(huán)境中設(shè)備的系列和類別之間的關(guān)系。 圖 2 設(shè)備的系列（family）和類別（category） 為了支持資源受限設(shè)備系列所要求的那種靈活性和可定制部署,人們將 J2ME 體系結(jié)構(gòu)設(shè)計(jì)成模塊化的和可伸縮的。 J2ME 技術(shù)在一個(gè)完整的應(yīng)用程序運(yùn) 行時(shí)模型中定義了這種模塊性和可伸縮性,在該模型（圖 3 所示）中的四個(gè)軟件 層都構(gòu)建在設(shè)備的主機(jī)操作系統(tǒng)上。 Java 虛擬機(jī)層（Java Virtual Machine Layer）:這一層是 Java 虛擬機(jī)的 一個(gè)實(shí)現(xiàn),它是為特定設(shè)備的主機(jī)操作系統(tǒng)定制的,而且支持一個(gè)特定的 J2ME 配置（configuration） 。 配置層（Configuration Layer） 配置層定義了 Java 虛擬機(jī)功能的和特定 ： 第 3 頁 共 26 頁 類別設(shè)備上可用的 Java 類庫的最小集。 從某種程度上說， 一個(gè)配置定義了 Java 平臺(tái)功能部件和庫的共同性， 開發(fā)者可以假設(shè)這些功能部件和庫在屬于某一特定 類別的所有設(shè)備上都是可用的。用戶不太會(huì)見到這一層，但它對框架（profile） 實(shí)現(xiàn)者非常重要。 框架層（Profile Layer） ：框架層定義了特定系列設(shè)備上可用的應(yīng)用程序編 程接口（API）的最小集。框架在一個(gè)特定的配置上面實(shí)現(xiàn)。應(yīng)用程序是針對特 定的框架編寫的,因此可以移植到支持該框架的任何設(shè)備上。一個(gè)設(shè)備可以支持 多個(gè)框架。用戶和應(yīng)用程序供應(yīng)商看到最多的就是這一層。 MIDP 層：移動(dòng)信息設(shè)備框（Mobile Information Device Profile（MIDP） ） 是一個(gè) Java API 集合，它處理諸如用戶界面、持久存儲(chǔ)和聯(lián)網(wǎng)這樣的問題。 Java 虛擬機(jī)層（Java Virtual Machine Layer） 、配置層（Configuration Layer）和框架層（Profile Layer）一起構(gòu)成了連接限制設(shè)備配置（Connected Limited Device Configuration（CLDC）。MID 框架（MID Profile）和 CLDC 提 ） 供了一個(gè)標(biāo)準(zhǔn)的運(yùn)行時(shí)環(huán)境， 這個(gè)環(huán)境允許把新的應(yīng)用程序和服務(wù)動(dòng)態(tài)地部署在 終端用戶設(shè)備上。 圖 3 J2ME 體系結(jié)構(gòu) 用 MIDP API 進(jìn)行 J2ME 編程：構(gòu)件 CLDC 和 MIDP 組合起來為創(chuàng)建移動(dòng)電話 和簡單雙向?qū)ず魴C(jī)上的應(yīng)用程序提供了完整的環(huán)境。 MIDP 框架的核心是一個(gè) MIDlet 應(yīng)用程序。這個(gè)應(yīng)用程序繼承了 MIDlet 類，以允許應(yīng)用程序管理軟件對 MIDlet 進(jìn)行控制、從應(yīng)用程序描述符檢索屬性 以及對狀態(tài)變化進(jìn)行通知和請求。 所有 MIDlet 都繼承 MIDlet 類 — 運(yùn)行時(shí)環(huán)境（應(yīng)用程序管理器）MIDlet 應(yīng)用程序代碼之間的接口。MIDlet 類提供了用于調(diào)用、暫停、重新啟動(dòng)和終止 MIDlet 應(yīng)用程序的 API。 應(yīng)用程序管理軟件可以在運(yùn)行時(shí)環(huán)境內(nèi)管理多個(gè) MIDlet 的活動(dòng)。此外， 第 4 頁 共 26 頁 MIDlet 可以自己發(fā)起一些狀態(tài)變化，并把這些變化通知給應(yīng)用程序管理軟件。 MIDP API 類的完整集合可以分為兩個(gè)類別： 用于用戶界面的 MIDP API：設(shè)計(jì)這些 API 是為了能以一系列屏幕顯示 為基礎(chǔ)與用戶進(jìn)行交互操作，每一屏幕顯示把適量的數(shù)據(jù)顯示給用戶。命令以每 屏幕為基礎(chǔ)提供給用戶。這些 API 應(yīng)用程序決定下一屏顯示什么、執(zhí)行什么計(jì) 算和使用網(wǎng)絡(luò)服務(wù)的何種請求。 用于處理數(shù)據(jù)庫的 MIDP API：這些 API 負(fù)責(zé)組織和操作設(shè)備數(shù)據(jù)庫， 這個(gè)數(shù)據(jù)庫由在 MIDlet 的多個(gè)調(diào)用之間跨越時(shí)保持持久的信息組成。 底層的 CLDC API 用于處理字符串、對象和整數(shù)。還提供了 Java 2 API 的 一個(gè)子集，用于處理 I/O 和網(wǎng)絡(luò)通信。 圖 4 定義了 J2ME 的構(gòu)件。 圖 4 J2ME 的構(gòu)件 聯(lián)網(wǎng)機(jī)制 通用聯(lián)網(wǎng)框架(圖 5)在 J2ME 平臺(tái)中扮演著十分重要的角色，如果沒有它， 我們寫的應(yīng)用程序?qū)ν馊藖碚f只能說“神秘”， 而應(yīng)用了通用聯(lián)網(wǎng)框架進(jìn)行聯(lián)網(wǎng) 的程序就顯得“神奇”了。這里我將對通用聯(lián)網(wǎng)框架進(jìn)行整體的分析,由于移動(dòng) 信息設(shè)備的資源受限特性，所以 和 包不適合在這里使用。現(xiàn) 實(shí)世界中使用著各種各樣的網(wǎng)絡(luò)通信協(xié)議，這使得設(shè)計(jì)好這個(gè)框架非常不容易， 至少我是這么認(rèn)為的。 然而當(dāng)我們分析 GCF 的時(shí)候可以清楚地發(fā)現(xiàn)它有如下幾個(gè) 特性：基于接口設(shè)計(jì)，便于擴(kuò)展、提供創(chuàng)建連接的工廠方法、使用標(biāo)準(zhǔn) URL 簡化 了程序員的工作。 當(dāng)我們察看 的 API 的時(shí)候可以發(fā)現(xiàn)其中定義了 8 個(gè)接 口、一個(gè) Connector 類和 ConnectionNotFoundException 異常。在 中進(jìn) 第 5 頁 共 26 頁 行了擴(kuò)展，提供了 HttpConnection、HttpsConnection 接口，這樣使得 MIDlet 具 備 了 通 過 Http 或 者 Https 協(xié) 議 與 server 通 信 的 能 力 ， 提 供 了 SocketConnection、ServerSocketConnection、UDPDatagramConnection 接口， 使得 MIDlet 能夠在 TCP/IP 層通過 socket 進(jìn)行通信或者使用數(shù)據(jù)報(bào)進(jìn)行通信的 能力。 結(jié)合 GCF 的接口層次圖來了解通用聯(lián)網(wǎng)框架是最好的辦法， 下面我們看看它 的層次結(jié)構(gòu)。 最上層的接口是 Connection，其他的接口都從他那里繼承。在 Connection 中只定義了一個(gè)方法 close()。在我們的現(xiàn)實(shí)世界中通常使用的是分組數(shù)據(jù)交換 和電路交換，所以在網(wǎng)絡(luò)框架中有 DatagramConnection 和 StreamConnection。 由于在基于流傳輸中我們需要對輸入流和輸出流通是具有操作的能力。因此 StreamConnection 擴(kuò)展了 InputConnection 和 OutputConneciton， 我們經(jīng)常使用 的 (),()方法都是在這兩個(gè)重要 的接口中定義的。StreamConnectionNotifier 接口定義了連接監(jiān)聽器應(yīng)該具備 的能力，它的方法 acceptAndOpen()方法返回一個(gè) StreamConnection 類型的連 接，ServerSocketConnection 繼承了 StreamConnectionNotifier 接口，這樣如 果你做 socket server 的時(shí)候就可以通過使用這樣的 URL,socket://:port 在你 的設(shè)備上建立監(jiān)聽端口等待連接。SocketConnection 繼承 StreamConnection 正 好可以和 ServerSocketConnection 交相輝映。UDPDatagramConnection 則是為 了分組數(shù)據(jù)交換中使用而繼承了 DatagramConnection 接口。 ContentConnection 接 口 中 只 定 義 了 三 個(gè) 方 法 getEncoding(),getLength() 和 getType() ， HttpConnection 就是他的子類，在 HttpConnection 中定義了大量的操作。 圖 5 通用聯(lián)網(wǎng)框架 而 GCF 的是使用非常簡單,主要集中在 Connector 的 open()方法上。我們要 做的是提供一個(gè)標(biāo)準(zhǔn) URL 給 open 方法， 例如需要得到 HttpConnection 我們應(yīng)該 第 6 頁 共 26 頁 寫類似下面的代碼: String url = “://myip:myport/myservlet”。 HttpConnection Conn = (HttpConnection)(url)。 我在這里只列入它的基本格式：{scheme}:[{target}][{parms}],針對不同 的網(wǎng)絡(luò)通信方式，我要做的就是寫出不同的 URL，并通過強(qiáng)制轉(zhuǎn)換得到你需要的 連接類型。 數(shù)據(jù)交換技術(shù) 本章主要介紹在 J2ME 中客戶端和服務(wù)器端的數(shù)據(jù)交換技術(shù)，由于移動(dòng)設(shè)備 有限的處理器能力和內(nèi)存，不支持一些像 JavaRMI 或 JAXRPC 復(fù)雜的客戶端/服 務(wù)器通信機(jī)制， 而必須選擇一種較為輕量級通信機(jī)制。 一般通信方式有:基于 HTTP 的通信方式、基于 SOCKET 的通信方式和基于數(shù)據(jù)包的通信方式等。 但是基于 SOCKET 或數(shù)據(jù)包方式目前不是所有的 MIDP 設(shè)備都支持， 而且可能 無法穿越防火墻,而基于 HTTP 的通信方式卻不存在此類問題,大多數(shù)企業(yè)的防火 墻都對 80 端口上的向外 HTTP 請求沒有限制或做少量的限制,對大多數(shù)應(yīng)用,以 HTTP 作為通信協(xié)議基礎(chǔ)完全可以勝任。而且所有的 MIDP 設(shè)備都支持 HTTP 網(wǎng)絡(luò)， 因此使用 HTTP 網(wǎng)絡(luò)的應(yīng)用程序跨平臺(tái)性很好。另外,Java 網(wǎng)絡(luò) API 為 HTTP 通信 提供了編程接口。 HTTP 請求 移動(dòng)設(shè)備 客 戶端 HTTP 響應(yīng) Servlet 圖 6 基于 HTTP 的 MIDP 客戶端和服務(wù)器端 下面闡述基于 HTTP 的 MIDP 客戶端和 Servlet 之間的基本通信方案(如圖 6 所示)。 一、基于 HTTP 的 MIDP 客戶端和 Servlet 之間的通信步驟為: ，MIDP 客戶端將請求消息編碼并將其打包成一個(gè) HTTP 請求，設(shè)置 Content_type 頭 內(nèi) 容 ， 將 其 設(shè) 置 為 text/plain( 文 本 內(nèi) 容 請 求 ) 或 application/octetstream(二進(jìn)制請求)等等，以確保網(wǎng)關(guān)對該請求的正確處 理。 ，S