中 華 大 學
碩 士 論 文
題目：點對點行動網路上網路服務分享機制之研究
系 所 別：資訊工程學系碩士班 學號姓名：M09502007 陳晏晟 指導教授：張欽智 博士
中華民國 九十八 年 二 月
摘要
近年來，隨著行動網路技術的不斷發展和演進，以及行動終端裝置運算能力 的提昇，行動裝置應用上也日趨廣泛，其中點對點(Peer to Peer，P2P)及網路服 務(Web Services)應用在行動裝置上成為無可避免的趨勢。但是，受限於網路的 頻寬和行動裝置運算能力，行動 P2P 及網路服務的發展仍有侷限，本論文在探 討如何將 P2P 的技術和研究逐漸地延伸至行動網路上。並且在行動網路環境下，
針對網路服務的分享去做更深入的探討。
由於點對點行動網路環境的限制，如何有效的搜尋及分享服務，一直是一個 重要的研究主題。本篇論文建置一個系統，透過系統的註冊、搜尋和分享三樣功 能，以提昇服務的分享速度和快速得知提供者所提供的服務。並利用行動裝置上 的紀錄管理儲系統(RMS)來連接資料庫，資料可以透過閘道器互相存取，並使用 客製化的搜尋機制來配對服務，配對一組適合使用者的服務，最後建立不需透過 代理人的分享功能，使服務能在使用者的行動裝置間快速分享。
本文中的系統是建置在 JXME 上，JXME 是一種行動平台上的 JXTA 技術，
JXTA 是以服務導向架構為基礎的 P2P 技術，而 JXME 適合在點對點行動網路的 環境研究與開發。本文並透過單機及多機的模擬網路環境，去驗證本系統；以單 機模擬網路環境，去分析 JXME 和中繼同儕點性能，以多機模擬網路環境，去 探討系統分享功能的效能。
關鍵字： JXME、JXTA、P2P、網路服務(Web Services)、服務導向架構(SOA)
Abstract
In recent years with the development and advance of mobile network technologies and the enhancement of computing capability of mobile devices, the applications of mobile devices become more pervasive. Peer to Peer (P2P) networks and Web services are inevitable to be applied to mobile devices. But due to the network bandwidth and computing capability of mobile devices, the applications of mobile P2P and Web services are still limited. In this thesis, we are studying how to apply P2P technology to mobile Web services and investigate how to share Web services in mobile network environment.
Due to the limitation of P2P mobile networks, how to effectively discover and share services is always an important research topic. In this thesis a system is built to expedite service sharing and to fast recognize the services provided by service providers through three system functions: registry, discovering, and sharing. In this system, the record management store (RMS) is used to connect databases. Data can be accessed and exchanged through gateways. Customizing discovery can help match services that meet the requirements of users. Services can be fast shared among user’s mobile devices without agents.
The system is built on JXME which is a JXTA technology on mobile platforms.
JXTA is a P2P technology based on service-oriented computing and JXME is suitable for P2P mobile networks. The system is verified through the simulations of single and multiple machines. The functionalities of JXME and relay peer nodes are analyzed in the single machine environment. The performance of system sharing is discussed in the multiple machine environment.
Keywords: JXME, JXTA, P2P, Web services, service-oriented architecture (SOA)
致謝
首先誠摯的感謝指導教授張欽智博士，老師悉心的教導使我得以一窺 Web Services 領域的深奧，不時的討論並指點我正確的方向，使我在這些年中獲益淺。
老師對學問的嚴謹更是我輩學習的典範。本論文的完成另外亦得感謝蔡文偉大力 協助，及陳思君的支持。因為有你們的體諒及幫忙，使得本論文能夠更完整而嚴 謹。
兩年裡的日子，實驗室裡共同的生活點滴，學術上的討論、言不及義的閒扯、
讓人又愛又怕的宵夜、趕作業的革命情感、因為睡太晚而遮遮掩掩閃進實驗 室...，感謝眾位學長姐、同學、學弟妹的共同砥礪，你們的陪伴讓兩年的研究 生活變得絢麗多彩。
感謝創楷學長不厭其煩的指出我研究中的缺失，且總能在我迷惘時為我解 惑，也感謝吳志偉、郭竹晏同學的幫忙，恭喜我們順利走過這兩年。實驗室的黃 偉峰、許世宗、泫廷、新隆學弟們當然也不能忘記，你們的幫忙及搞笑我銘感在 心。皓呆在背後的默默支持更是我前進的動力，沒有阿達、小強和小公的體諒、
包容，相信這兩年的生活將是很不一樣的光景。
最後，謹以此文獻給我摯愛的雙親。
內容目錄
摘要 ……….….…… i
Abstract ……….… ii
致謝 ……….…iii
內容目錄 ……….……….. ……… iv
圖目錄……….……….. ………..vii
表目錄 ………..……….. ix
第一章 緒論………..………..1
1.1. 研究背景與動機………..1
1.2. 研究目的………..3
1.3. 論文架構………..4
第二章 相關文獻與技術探討………..5
2.1. P2P 簡介………..………...………..5
2.1.1. P2P 定義及優點………....5
2.1.2. P2P 歷史與演進………....6
2.1.3. P2P 未來與挑戰………....8
2.2. JXTA 簡介………...………...………8
2.2.1. JXTA……….………....8
2.2.2. JXTA 的軟體架構……….8
2.2.3. JXTA 的點群組研發架構和服務層延伸的服務……….9
2.2.4. JXTA 的模組層架構………...10
2.2.5. JXTA 的同儕及其功能………...…11
2.2.6. JXTA 的應用程式優點………...12
2.2.7. JXME………...………...………12
2.2.8. JXME 的 Proxy 和 ProxyLess 策略………...……….13
2.3. 網路服務以及其相關技術………...………...………..14
2.3.1. 網路服務………...………...14
2.3.2. XML…...………...………...15
2.3.3. WSDL…...……..………...………..…….15
2.3.4. SOAP...………...………...………...16
2.3.5. UDDI....………...……….17
2.3.6. 服務導向架構………...………...18
2.4. 服務的搜尋法………...………...…………..…19
第三章 系統設計架構與流程………..………20
3.1. 行動網路服務(MWS)………...………...…………..…20
3.2. JXME 架構………...………...………..23
3.3. RMS 連接資料庫………...………...………...………..24
3.4. 系統架構………...………...………..26
第四章 系統範例實作………..………29
4.1 系統開發環境………...………...………...29
4.2 範例系統設計………...……...……..………...30
4.2.1 服務註冊………...……….……...30
4.2.2 系統功能………...………..30
4.3 實驗執行與結果……….31
4.3.1 兩種連線和交換訊息..………...……….……...31
4.3.2 實作系統介面和功能………...……….……...34
第五章 系統實驗分析………..………40
5.1 實驗環境………...………..……...………...40
5.2 記憶體的分配和釋放………...……….………...41
5.3 單機模擬網路環境………...………..……...………...…42
5.4 zlib 資料壓縮法………...…………...……...………...44
5.5 多機模擬網路環境………...…………...………...46
第六章 結論與未來展望……..………48
參考文獻………..………49
圖目錄
圖 2.1 第一代的代表 Napster………...………..…6
圖 2.2 第二代的代表 Gnutella……….………..……….……7
圖 2.3 第三代的代表 JXTA………..………..………7
圖 2.4 JXTA 的軟體架構……….……….………..9
圖 2.5 點群組研發架構和服務層延伸的服務………10
圖 2.6 XML 文件的範例………..………….………15
圖 2.7 WSDL 文件的範例………..………..……….16
圖 2.8 SOAP 文件的範例………..…………17
圖 2.9 UDDI 的四種元素和對應關係………..………18
圖 2.10 服務導向架構………...………...………19
圖 3.1 系統建立階層示意圖………...………….…………20
圖 3.2 JXME 虛擬網路……….24
圖 3.3 RMS 連接 Java 平台資料庫……….……….………….26
圖 3.4 系統架構………..……….………….28
圖 4.1 JSP 閘道器回應的 XML 文件………..…….………….32
圖 4.2 管道建立的訊息……….………….………..…33
圖 4.3 管道傾聽的訊息…………..……….………….33
圖 4.4 管道傳送的圖片訊息………...……….…………33
圖 4.5 管道傳送的文字訊息………...……….…………34
圖 4.6 中繼點設定………35
圖 4.7 註冊功能………..….……….………35
圖 4.8 註冊的行程服務………..……….…….……35
圖 4.9 註冊的旅館服務………...……….………35
圖 4.10 註冊的飲食服務……….……….…36
圖 4.11 搜尋的功能……….……….………….36
圖 4.12 搜尋時輸入的使用者偏好……….…….…………36
圖 4.13 搜尋配對的行程服務……….………….36
圖 4.14 搜尋配對的旅館服務……….………….37
圖 4.15 搜尋配對的飲食服務……….………….37
圖 4.16 [1]系統上的規則基準法服務選擇畫面………..…………37
圖 4.17 分享的功能……….………….38
圖 4.18 行動裝置上提供的服務……….………….38
圖 4.19 使用者輪詢到的服務……….………….38
圖 4.20 圖片檔分享……….………….38
圖 4.21 文字檔分享……….……….…39
圖 5.1 中繼同儕點的阻塞………..……….………….43
圖 5.2 服務發佈的時間間距和服務的 Size 關係..………...………43
圖 5.3 服務的大小和回應時間的關係………..………..…………44
圖 5.4 文字服務大小和壓縮比的關係……….………...….…...45
圖 5.5 圖片服務大小和壓縮比的關係……….………...….………...45
圖 5.6 文字服務大小與壓縮和解壓縮時間的關係……….………...46
圖 5.7 圖片服務大小與壓縮和解壓縮時間的關係……….………...46
圖 5.8 多機模擬網路環境-服務大小和平均回應時間的關係………...47
圖 5.9 多機模擬網路環境-zlib 壓縮和未壓縮的平均回應時間比較………47
表目錄
表 2.1 JXTA 和 JXME 比較...………..………13 表 3.1 WS 和 MWS 特性比較...………..……….21 表 3.2 P2P、Agent-Based 和 P2P Agent-Based 的 MWS 應用架構比較…………...22 表 4.1 系統實作環境...………..……….…………29 表 4.2 系統範本的特徵與個數….…..………..……….30
第一章 緒論
網際網路的變革日新月異，傳統的客戶端-伺服端結構已經無法滿足人們的 需求，P2P 利用閒置網路上節點的資源，帶來更多的運算能力和儲存容量，使人 們日漸重視 P2P 的可行性，也讓 P2P 在各領域具有很高的實用性。JXTA 是一套 P2P 協定，改善且綜合以往的 P2P 架構，是行動平台上 P2P 技術 JXME 的基礎，
更有團隊持續開發，使得 JXTA 成為發展 P2P 應用程式重要的平台。網路服務的 快速發展，在於能達到資訊和應用程式的整合和跨平台。如何在點對點行動環境 裡面，提供給使用者適合且快速的服務，是現在許多研究所努力的一個目標。在 1.1 節說明本論文的研究背景與動機，1.2 節說明本論文的目的，1.3 則會介紹本 論文的章節架構。
1.1 研究背景與動機
科技的進步，網際網路的快速發展，傳統的客戶端-伺服端(Client-Server)結 構已經發展成熟，但是仍存在許多問題，直到 P2P 結構的出現，改善了傳統客 戶端-伺服端結構上的問題，且傳統的結構已經無法滿足使用者的需求，讓 P2P 結構成為熱門的研究議題。在傳統的客戶端-伺服端結構，各式各樣的資源，包 括文字、圖片和音樂等資源都存放在伺服端的硬碟上，客戶端通過網際網路連結 到伺服端搜尋、下載、或上傳資料，在這種結構下，客戶端和伺服端存在明顯的 主從關係。P2P 的結構，不同於傳統的客戶端-伺服端結構，是 P2P 網路上不存 在中心伺服器，每一個節點的功能都是對等的，除了能當服務的消費者也能當服 務的提供者，能善加利用 P2P 網路上閒置節點的資源，提昇 P2P 網路上的頻寬、
容量和計算等資源，同時也能降低伺服端的運算負載和節省 P2P 網路系統開發 成本。
1999 年夏天，Napster 的出現顛覆了人們對網際網路的傳統觀念，是第一個被廣 泛應用的 P2P 音樂共享服務；而後廣泛應用的是 Bittorrent 及 Gnutella，強調 P2P 檔案傳輸協定能力，大型檔案能快速且有效分享至整個 P2P 網路，讓 P2P 在電 腦科技的應用中更為流行。
JXTA 是一套 P2P 協定，用來解決 P2P 計算的開放性網際網路運算平台，適 用在各種相異的裝置和環境。在 P2P 領域中，JXTA 做了不同以往的改變，JXTA 定了一套自己的 P2P 協定，開發者可以使用這些 P2P 協定來建立幾乎所有的應 用，例如：檔案分享、資源分享、和即時通訊等，因為 JXTA 致力於提供一個基 本的 P2P 協定，基本的協定是建立在普遍 P2P 應用的必要元件，這樣能讓其他 的 P2P 應用也可以建立在基本協定之上。為了讓行動裝置也能使用 P2P 協定，
JXTA 團隊開發了 JXME(JXTA for J2me)，簡化 JXTA 的功能，並適用在 MIDP 和行動裝置的規格，讓行動裝置也能在複雜的 P2P 環境中運行。
資訊技術(Information Technology，IT)結構的演進，由主機架構(mainframe)，
緊接的是主從式架構(client server) ，到網路為中心(network centric)架構，直到現 今軟體極力發展的服務導向架構(Service-Oriented Architecture)。服務導向架構其 主要概念，是針對企業需求組合而成的一組軟體元件，能讓異質系統和資訊整 合，提昇企業應用程式的靈活度與可重複使用性。服務導向架構發展的過程中，
有許多知名的中介軟體，包括了 CORBA、COM+、RMI 等中介軟體，由於標準 不相容的問題，都未能達成資訊完全整合。隨著網路服務(Web Services)技術的 導入，服務導向架構才真正實現及流行。
過去，網際網路剛發展時，只有「文件網頁」(Document Web)能供瀏覽，隨 著網路的快速發展、頻寬的提昇和文件網頁的成熟，一般的文件網頁已經無法滿
足一般使用者和企業的需求，人們更近一步需要的是資訊和應用程式的整合，但 是各企業有各自的技術標準和平台，而無法達到資訊和應用程式的整合目標。為 了達到這個目標，因此有了網路服務的產生。網路服務以 UDDI、SOAP、WSDL 為基本技術標準規格，具備資訊整合和應用程式跨平台的功能，並有 IBM、微 軟、和 Oracle 大力推廣，變成一種流行的技術標準規格。過去互不相通的平台，
經過網路服務的包裝，服務可以共用，如 J2EE(Java 2 Platform Enterprise Edition) 與微軟的.NET 平台的網路服務可相互存取和溝通。
1.2 研究目的
由於行動裝置的移動性，如何有效的搜尋及分享服務，一直是一個重要的研 究主題。P2P 技術在固網上的應用隨處可見，更是熱門的研究主題，但是，P2P 在行動平台的應用與技術才剛起步，現今文獻上少有研究但非常重要的問題，也 是本論文研究的議題。本論文，建立一個系統，行動裝置在 MANET 環境下，利 用 P2P 的技術，能快速得知彼此服務和有效率分享服務。JXME 是一種行動平台 上的 JXTA 技術，JXTA 是以服務導向架構為基礎的 P2P 技術，本論文利用 JXME 為建置系統的 P2P 應用技術。
本篇論文主要的目的在提出一個系統，提昇服務的分享速度和快速得知提供 者所提供的服務，系統主要提供註冊、搜尋和分享三樣功能。利用行動裝置上的 紀錄管理儲系統(RMS)來連接資料庫，資料可以透過閘道器互相存取，達到註冊 功能，並使用客製化的搜尋機制來配對服務，配對一組適合使用者的服務，最後 建立不需透過代理人的分享功能，使服務能在行動裝置間快速分享。本文並透過 旅遊規劃的範例來驗證我們提出的搜尋方法和搜尋方法，在分享的功能提出單機 模擬網路環境，去分析 JXME 和中繼同儕點性能；並在多機模擬網路環境，去
探討系統分享功能的效能。
1.3 論文架構
本論文中一共分為六章。第一章為論文研究的緒論，說明我們的研究動機、
研究此論文的目標、與此論文的研究方法。第二章為論文相關技術與文獻探討，
我們會針對本篇論文中所提及的相關技術與研究，依序探討說明。第三章為系統 架構，此章節為本論文的核心，說明我們研究當中所提出的各式各樣軟體架構流 程與研究方法，並透過代理人整合各種軟體架構，成為本論文的系統架構，並細 部分析本論文的系統架構與各軟體架構的元件與流程。第四章為系統範例實作，
系統提供註冊、搜尋和分享三樣功能，並利用系統建構旅遊服務的應用。第五章 為系統評估，針對我們所提出的研究方法，細部討論，藉以比較與驗證我們所提 出的方法。第六章為結論與未來展望，針對本篇論文作總結，並討論未來的研究 方向。
第二章 相關文獻與技術探討
在本章中，將概述本篇相關的一些技術與知識，從 P2P 的知識探討開始，
再深入研究為何選擇 JXTA 為本篇的 P2P 協定，後續的探討包括了：網路服務、
服務導向架構、和服務的搜尋法等，藉此更進一步了解 P2P、JXTA 和網路服務 的背景知識。2.1 節中將簡介 P2P 的背景，包括了定義、優點、演進和未來挑戰。
在 2.2 節中深入探討 JXTA 相關知識，包括了定義、軟體架構、同儕群組研發架 構、模組層架構、同儕及其功能、應用程式優點、JXME、和 JXME 的 Proxy 與 ProxyLess 兩個策略。2.3 節中探討網路服務的知識與基本技術規格，包括：XML、
WSDL、SOAP、UDDI、和服務導向架構。在 2.4 節中討論目前的服務搜尋法，
提供使用者合適的服務。
2.1 P2P 簡介
2.1.1 P2P 定義及優點
P2P 是一種網路技術，依賴網路中參與者的計算能力和網路頻寬，而不是把 依賴都聚集在較少的伺服器上，Clay Shirky 則是說：P2P 是一種在儲存能力、生 命週期、檔案內容與其他人造產物等資源具有優勢的應用[15]。
P2P 非集中化的特點，帶來許多優點，是傳統的主從架構不能實現的，有四 個特性如下[15]：
z 可伸縮性(scalability)：接受大量資源與連結節點聚集數量可擴展性。
z 強健性(robustness)：避免單一個功能失敗，每一個節點都是獨立的。
z 可擴展性(Extensible)：P2P 網路不存在通信瓶頸，可以被無限擴展。
z 高性能低成本：利用網路中的大量空閒資源，可以用更低的成本提供更 高的計算和存儲能力。
2.1.2 P2P 歷史與演進
P2P 已有多年的演進過程，每一時期都具有代表作。第一代的 P2P，資源搜 尋都在中央的伺服器，Napster 是其代表作，如圖 2.1 表示，也是第一個被廣泛 應用的 P2P 的共享音樂服務；第二代的 P2P，是純粹分散式的，不存在任何中央 伺服器，Gnutella 是其代表，如圖 2.2 表示，但是在節點眾多的情況下，頻寬的 消耗會非常沈重；第三代的 P2P，其代表為 JXTA，如圖 2.3 表示，使用結構化 且階層化的節點架構，綜合了第一代和第二代的 P2P 協定的優點，並且新增運 算能力較強的超級節點，處理較複雜的資源搜尋，這種樹狀結構的 P2P 網路，
可以更有效的利用網路。
圖 2.1 第一代的代表 Napster
圖 2.2 第二代的代表 Gnutella
圖 2.3 第三代的代表 JXTA
2.1.3 P2P 未來與挑戰
P2P 的技術上，有許多尚待加強的問題，例如：訊息的傳遞和路由、服務發 現、服務的質量、安全性等。而且，P2P 的應用上，有很多的挑戰，例如：惡意 的傳播、防火牆和 NAT 的穿越、群組成員的溝通等。在 P2P 的應用程式，使用 不同的協定，提供適合的方法，例如：Bittorrent 協定適合檔案的快速分享。目 前常見的應用種類和應用程式，能提供不同的服務，例如：即時通訊(Jabber，
MSN)、檔案分享(Bittorrent，Gnutella)、分散式計算(SETI@Home)等，從眾多廠 商相繼投入不同領域的 P2P，更可以瞭解 P2P 的應用是廣泛的。
2.2 JXTA 簡介
2.2.1 JXTA
JXTA(Juxtapose)是一種 P2P 的協定，在 2001 年 4 月由 SUN MicroSystems 提出，提供一個 P2P 開發的共通平台，適用在不同的裝置、不同作業系統與網 路上都能執行。JXTA 是一套開放的協定，設立三個簡單的目標：作業系統獨立 性、語言獨立性和提供 P2P 應用程式可用的服務和基礎架構，因為 JXTA 是一種 基本架構位於軟體開發者的應用程式之上，無須擔心虛擬機器在底層的詳細運 作。JXTA 的相關文獻，可以參考[12-20]。
2.2.2 JXTA 的軟體架構
JXTA 的軟體架構分為三層，如圖 2.4 所示[2]：
z 核心層(Core Layer)：負責處理節點的建立、安全、通訊以及路由等功能。
z 服務層(Service Layer)：負責較高階的網路服務概念，像是搜尋、資源聚 集、協定轉換以及認證等功能。
z 應用層(Application Layer)：應用 JXTA 服務層所開發出來的完整 P2P 應 用程式，例如：myJXTA。
圖 2.4 JXTA 的軟體架構
2.2.3 JXTA 的同儕群組研發架構和服務層延伸的服務
JXTA 開發應用程式時，是以同儕群組(Peer Group)為單位，建構一個核心服 務，同儕群組並表示建造了安全、區域和監督的環境。軟體開發者研發應用程式 時，需要按照三個階層去研發，三層由低到高為：核心層、服務層和模組層，才 能達到 JXTA 的目標，讓各種裝置在相異的環境下都能執行，同儕群組研發架構 和服務層延伸的服務，如圖 2.5 所示。
圖 2.5 同儕群組研發架構和服務層延伸的服務
2.2.4 JXTA 的模組層架構
模組層提供一個模組 API，允許節點實現一個新的行為，這行為必須先透過 抽象化的過程，讓使用不同程式語言、版本和作業系統的點能夠相容，因此把模 組層抽象化為三個階層：
z 模組類別(Module Class)：一般的類別或是行為的類型。目的是去公告一 個行為的存在，並指定一個模組 ID。
z 模組規格(Module Specification)：以包含行為模式的跨平台定義來定義模 組。一個模組規格應用於一個模組類別所提供的功能，例如：在模組類 別的公告引用管道的公告，如此一來，用這個模組的使用者就不必另外 搜尋一個可用的管道公告了。
z 模組實作(Module Implementation)：某個平台上此模組的特有實例。模 組實作是模組規格的實現，是一個模組實作應用於一個模組規格所提供
的功能。定義公告的最後項目是 JXTA Shell 應用程式的話，會把這個 Shell 變成同儕群組的預設應用程式，JXTA Shell 就可以監控管理這個節 點。
2.2.5 JXTA 的同儕及其功能
JXTA 定義了兩種同儕：邊際同儕(Edge Peer)及超級同儕(Super Peer)，超級 同儕又分為集結(Rendezvous)同儕點及中繼(Relay)同儕點。當一個邊際同儕發佈 可用的資源，資源的索引會透過分享資源分散式索引(Shared Resource Distributed Index，SRDI)推向集結點，集結點再使用分散式雜湊表(Distributed Hash Table，
DHT)將索引推向其它同儕節點，以利服務的搜尋與分享。JXTA 網路的建立，要 透過集結點及中繼點(Relay)來繞送訊息和資料，更詳細的集結同儕點和中繼同儕 點功能如下所示：
集結同儕點的功能：
z 保持緩衝儲存區的公告。
z 依照之前的搜尋請求，幫助其他節點搜尋資源。
z 集結點保持其他已知的集結點名單和與他相連的節點。
z 同儕群組保持自己的集結點名單，當有需求時能增加集結點。
z 群組間的搜尋請求，需要透過集結點傳遞。
中繼同儕點的功能：
z 保持有關於到其他點的路由。
z 路由訊息給節點。
z 中繼點能傳送訊息給那些無法直接定址的點，能解決 NAT 的問題。
2.2.6 JXTA 的應用程式優點
依照 JXTA 協定所開發出來的 P2P 應用程式，可以具備以下幾個特點[15]：
z 能穿越防火牆，並動態的發現其他節點。
z 輕易的分享訊息和文件。
z 利於找尋內容。
z 以群組為單位提供服務。
z 遠端地監控節點的行為。
z 安全地與其他節點連結。
在這邊舉例一個常用的 JXTA 應用程式，名稱為 JXTA Shell，是由 JXTA 團 隊提供，定義了一個本機的執行環境，透過這個環境能執行應用程式，且能和 P2P 網路互動，並且可以把 JXTA 平台延伸到其他電腦上。因為 P2P 系統為分散 式的系統，比較難在完全控管的環境下實作和測量，JXTA Shell 提供了一個管 理介面，透過這個介面便能控制和執行 P2P 應用程式，甚至能和其他使用者聊 天。
2.2.7 JXME
JXTA 計畫研發了 JXTA for J2ME，稱為 JXME，JXME 如同 JXTA 包含有 Proxy 及無 Proxy 兩個策略，開發的目標是把 JXTA 的功能帶入 MIDP 裝置。但 是，有幾個在 JXTA 協定的要求，卻很難對 MIDP 實施，說明如下，並且在表 2.1 做 JXTA 和 JXME 的比較：
1. 由於 JXTA 訊息是用 XML 表示 ，節點必須外掛一個 XML 解析器，XML
解析器的擴展記憶體，可能會超過在記憶體限制的 MIDP 設備。
2. JXTA 使用快取記憶體(cache)，存取鄰近節點的公告和資源，會更縮緊 MIDP 設備上的記憶體負擔。
3. JXTA 的網路連接可以使用資料流(datagram)和 Socket，但是，MIDP 裝置 主要任務是支援最基本的 HTTP 連結，資料流和 Socket 是非必須的。
表 2.1 JXTA 和 JXME 比較
JXTA JXME
XML Parser 支援 不支援
Incoming Http Connection 支援 不支援
廣泛的安全性支援 高 低
廣播 支援 不支援
因為 JXME 節點不能擔任複雜工作，只能當作終端節點的角色，所以在 Proxy 策略中，把複雜的功能移至 JXTA 中繼點代理，另外在 ProxyLess 策略，會把複 雜的功能移至行動虛擬中繼點代理。
2.2.8 JXME 的 Proxy 和 ProxyLess 策略
Sun 制定了兩個標準，CLDC 和 CDC，針對不同裝置的特性制定不同的規 範 ， 包 含 了 虛 擬 機 的 規 範 和 基 本 的 API ， CLDC 和 CDC 說 明 如 下 ， CLDC(Connected Limited Device Configuration)是為運行在資源非常有限的設備 上 的 J2ME 應 用 程 序 的 架 構 ， 通 常 是 指 低 階 手 機 ， CDC(Connected Device Configuration，連接設備配置)通常指的是 PDA 或高階手機。JXTA 的 Proxy 和 ProxyLess 策略技術支援和策略的優缺點如下所示：
JXTA-Porxy - 支援 CLDC-MIDP 1.0 相容的裝置，由於 Proxy 是設在固網 上，有較高的穩定度，技術上也較成熟。但 JXTA-Porxy 缺乏 XML 解析器，並 缺乏支援可延伸的安全保護及有效的群播機制，而且需要 JXTA 的中繼點與 JXME 在同一網路上，目前改進的工作仍在進行中。
JXTA-ProxyLess -支援 CLDC-MIDP 2.0 和 CDC 相容的裝置，目前仍在原型 (Prototype)的階段，技術上較不成熟。JXTA-ProxyLess 不需要 JXTA 的中繼點基 礎架構，仍須啟動 JXTA 平台去連結其他節點，且行動裝置網路的建立需要透過 虛擬的行動裝置中繼點。在 CDC 版本中，須改良 ID 和 PeerNetwork 讓它們更符 合 JXTA 規範，與新增 XML 訊息轉換的功能。 改進的工作較 JXTA-Proxy 策略 慢，因為 MANET 的限制與版本的不穩定。
2.3 網路服務以及其相關技術
2.3.1 網路服務
網路服務是一種軟體元件，透過 Web 通訊協定及開放式標準(例如 HTTP、
SOAP、和 XML)來為其他應用程式提供服務。網路服務的價值有兩種，第一種 價值，作為提供服務的元件，可用來建構分散式架構系統，實現動態整合、平衡 負擔等優點，第二種價值，以 Web 為基礎及採取開放式標準，讓不同平台的應 用服務可以操作，解決資訊與應用程式整合時所遭遇到互通性的問題。簡單的 說，網路服務在網際網路上提供其他程式或系統呼叫使用的程式。網路服務的特 性包含有：重複使用性、獨立性、物件導向及內部處理等四大特色[3]。
網路服務主要包含了 XML、WSDL、SOAP、UDDI 等重要的開放式標準。
網路服務的運作是透過自動產生的 WSDL 服務描述介面與 SOAP 的訊息交換，
藉此達成電腦或程式之間的溝通。下面將詳細介紹這些開放式標準的技術規格。
2.3.2 XML
XML(eXtensible Markup Language，可擴展標記語言)，資料結構屬於樹狀結 構，主要是用來描述資料，而不是像 HTML 用來排版和顯示資料，並且利用能 讓電腦理解的標籤方式，定義各種標籤所對應的屬性，描述成一份 XML 文件。
要讓電腦去理解一份 XML 文件，必須利用程式透過解析器(Parser)的協助處理，
能解析出標籤和標籤對應的屬性。圖 2.6 是一個 XML 文件的範例。
圖 2.6 XML 文件的範例 2.3.3 WSDL
WSDL(Web Services Description Language，網路服務描述語言)，以 XML 為 基礎描述的文件檔，用來描述一個網路服務，和說明如何存取與使用網路服務。
WSDL 的介面規範出網路服務輸入與輸出的參數，使用者藉由 WSDL 文件的規 格，能了解服務相關資訊和如何使用服務。簡單的說，就是讓使用者明白這個服 務的描述與如何去使用服務。建立網路服務後，WSDL 文件也會自動產生，並不
<?xml version="1.0" encoding="Big5"?>
<!DOCTYPE Personal_Info SYSTEM http://www.ws.org.tw/xml/Personal_Info.dtd>
< Personal_Info >
<Number>9502007</Number>
<Name>陳小仔</Name>
<Major>資訊工程所</Major>
<Email>chen@chu.edu.tw</Email>
<Phone>03-530-5400</Phone>
</Personal_Info >
需要額外去描述。圖 2.7 是一個 WSDL 文件的範例。
圖 2.7 WSDL 文件的範例 2.3.4 SOAP
SOAP(Simple Object Access Protocol，簡單物件存取協定)，以 XML 為基礎，
是資訊交換的通訊協定，把網路服務的需求訊息編譯，再將編譯過的回應訊息，
透過網際網路通訊。SOAP 訊息可以運作在不同的系統與網路上面，能達到跨平 台的功能。SOAP 可搭配各種網路協定，例如：HTTP 協定作同步(synchronous) 傳輸、SMTP 作非同步(asynchronous)傳輸等，再經由 RPC(Remote Procedure Call，
遠端呼叫)呼叫且使用服務，RPC 展示需求端與服務端之間的訊息交談程序，如 果以 XML 當作為編碼法，則稱 XML-RPC。SOAP 簡單的說，通常是 HTTP 加 上 XML，是應用程式和用戶之間傳輸資料的一種機制。圖 2.8 是一個 SOAP 文 件的範例。
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="LoanRequest" targetNamespace="http://j2ee.netbeans.org/wsdl/LoanRequest"
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns="http://xml.netbeans.org/schema/LoanRequest"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://j2ee.netbeans.org/wsdl/LoanRequest">
<types>
<xsd:schema targetNamespace="http://j2ee.netbeans.org/wsdl/LoanRequest">
<xsd:import namespace="http://xml.netbeans.org/schema/LoanRequest"
schemaLocation="LoanRequest.xsd"/>
</xsd:schema>
</types>
<message name="LoanRequestOperationRequest"><part name="reqMessage"
element="ns:ReqElement"/></message>
<message name="LoanRequestOperationReply"><part name="respMessage"
element="ns:RespElement"/></message>
<portType name="LoanRequestPortType">
<operation name="LoanRequestOperation">
<input name="in" message="tns:LoanReqRequest"/><output name="out" message="tns:LoanRequReply"/>
</operation>
</portType>
<binding name="LoanRequestBinding" type="tns:LoanRequestPortType">//~~~~~~~~~~</binding>
<service name="LoanRequestService">
<port name="LoanRequestPort" binding="tns:LoanRequestBinding">
圖 2.8 SOAP 文件的範例
2.3.5 UDDI
UDDI(Universal Discovery Description and Integration)稱為統一現描述與整 合，是一種以 XML 為基礎的定義服務的發現、描述和整合，可以使全世界的企 業能在網際網路上發佈自己所提供的服務。簡單的說，UDDI 是一種有關於網路 服務的目錄註冊服務，網路服務提供者能把網路服務註冊至 UDDI，網路服務需 求者就能透過 UDDI 去搜尋可以利用的網路服務有哪些。UDDI 儲存的資料結 構，主要包含下面 4 個元素，元素之間的關係如圖 2.9 所示[3]：
z BusinessEntity：提供網路服務的商業公司相關資訊，可包含一個或多個 BusinessServices。
z BusinessServices：一個網路服務的邏輯上描述資訊，可包含一個或多個 BindingTemplate。
z BindingTemplate：服務的連結點和提供了實際技術，對應到一個 tModel。
z tModel：服務的實際技術介面規格，包括了實際技術資訊與描述的專有名詞。
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header/>
<S:Body>
<ns2:PorcessApplicOperation xmlns:ns2="http://LoacProcessor/">
<socialSecurityNumber>001006</socialSecurityNumber>
<applicantName>chen</applicantName>
<applicantAddress>Taiwan</applicantAddress>
<applicantEmailAddress>chen@cc.chu.edu.tw</applicantEmailAddress>
<applicantAge>26</applicantAge>
<applicantGender>male</applicantGender>
圖 2.9 UDDI 的四種元素和對應關係
2.3.6 服務導向架構
「服務導向架構」(Service-Oriented-Architecture，SOA)是一種計算架構，在 建立互通性的計算模式，在此模式下資源以清楚分割的跨平台服務來呈現。服務 導向架構能夠解決企業的異質應用程式之間的整合問題，達到資訊整合目的，增 加企業營收和提高服務品質。服務導向架構是針對企業需求組合而成的一組軟體 元件，組合的元素通常包括：軟體元件、服務及流程三個部份，元件指的是最底 層的基本執行程式，透過流程把元件串聯起來，組合成一個服務。例如，當企業 面對顧客訂單要求，提供的元件有信用查詢、 庫存查詢等，流程會依照訂單要 求的處理步驟，如果執行信用查詢完，再執行庫存查詢，顧客都符合條件以後，
最後完成顧客下訂單的作業。服務導向架構導入企業成功的案例，西門子公司在 新流程的部屬上少了 83%，並增進商業的生產力。在服務導向架構裡面，定義了 三個角色：提供者、使用者和仲介者，提供了四種行為：搜尋、 發佈、註冊和 存取。角色和行為的關係圖，如圖 2.10 所示。
BusinessEntity
BindingTemplate BusinessService
tModel BusinessServiceBusinessService
BindingTemplate
tModel
圖 2.10 服務導向架構 2.4 服務的搜尋法
服務的搜尋方法，目前常見的有三種：關鍵字(Keyword)搜尋、知識架構 (Ontology) /語義(Semantic)搜尋 、和行為(Behavior)搜尋[21]。關鍵字搜尋，使用 字串比對，很容易實作但是正確性低。知識架構搜尋，利用適當的知識架構搭配 人工智慧配對服務去進行搜尋，例如：利用 OWL-S(ontology built on top of Web Ontology Language)建立旅遊的知識架構，再透過人工智慧去訓練範本，讓旅遊 搜尋結果適合使用者的需求，可採用目前流行的人工智慧的方法有基因演算法、
模糊理論和類神經網路等。行為搜尋，網路服務之間可以透過工作流程(Workflow) 的組合，如「商業流程執行語言」(Business Process Execution Language，BPEL) 利用工作流程協調網路服務，連結在一起而產生新的解決方案。本篇採用關鍵字 搜尋配合排序機制，再透過規則基準法的相似度運算，讓使用者能配對一組適當 的組合服務，解決因為關鍵字搜尋配對成功率太低，而造成配對結果不適合使用 者的問題。
第三章 系統設計架構與流程
本論文最主要的目標，在建置於行動 P2P 網路上的服務導向架構平台，根 據不同的角色和任務，結合固網的 JXTA 網路平台和無線的 JXME 網路平台，並 根據使用的平台提供適合的註冊機制，達到服務的註冊、發佈、搜尋和分享。系 統建立的階層，以 SOAP 為基本的傳輸訊息，並使用 JXTA 提供的服務，透過固 網上的代理人處理複雜運算和系統軟體架構彼此的連接，最後顯示的介面以 J2ME 或網頁應用程式呈現，[5]也提供相關的系統。系統建立階層示意圖，如圖 3.1 所示。
本節介紹「行動網路服務」，分析採用 JXME-Proxy 的理由，說明 JXME-Proxy 的架構和運作，解釋 RMS 與資料庫連接，描述代理人的功能，最後描述系統架 構上各角色的任務及運作。
圖 3.1 系統建立階層示意圖 3.1 行動網路服務(MWS)
將 網 路 服 務 運 用 在 行 動 網 路 上 就 稱 做 「 行 動 網 路 服 務 」 (Mobile Web Services，MWS)[8]。MWS 和 WS 的特性比較，如表 3.1 所示。
表 3.1 WS 和 MWS 特性比較
WS MWS
可攜帶性 低 高
可靠度 高 低
運算能力 高 低
網路頻寬 高 低
記憶體空間 大 小
連線品質 高 低
資料傳送量 高 低
資料傳送頻率 高 低
時間和地點資訊依賴性 低 高
個性化 低 高
QOS 高 低
使用者介面設計 簡單 複雜
MWS 的應用架構，大致可以分為三種：直接存取架構、點對點架構、和 Agent-Based 架構[6]。直接存取架構，是典型的伺服端-客戶端使用方式，行動裝 置使用者直接存取網路服務提供者所提供的服務；點對點架構，是行動裝置同時 擔任網路服務的使用者及提供者兩種角色，又可以在分成 ad-hoc 和非 ad-hoc 兩 種架構，非 ad-hoc 架構是使用 P2P 的搜尋方法直接存取固往上的網路服務，而 ad-hoc 架構是直接存取行動網路上的網路服務[9]；Agent-Based 架構，是透過代 理人間接存取網路服務。
網路服務的快速發展和行動網路的普及化，這兩種技術的結合，提供一個機 會讓企業在行動的環境中，可使用 MWS 的技術，直接提供服務給客戶。人手一 機的時代中，MWS 能提供客戶個人化的服務在多樣化的行動裝置上，然而個人 化的特性卻是一般的 WS 所缺乏的，且 WS 和 MWS 的行動網路環境和行動裝置
的限制，會隨著時間慢慢縮小差距，所以選擇 MWS 當作是我們提供的服務。
本篇系統中，為了讓 MWS 快速的分享，MWS 的應用架構採取 P2P 的非 ad-hoc 架構結合 Agent-Based 架構，稱之為「P2P Agent-Based 架構」(P2P Agent-based)，因為 P2P 的架構需要大量運算能力和網路頻寬，且行動裝置和行 動網路環境的限制，利用固網上的代理人做訊息的壓縮存和運算的處理，減輕行 動裝置的運算負載量和降低網路頻寬的使用。
本篇系統採用 JXTA-Proxy 策略，因為如此可以把大多數的運算和儲存的工 作交給 JXTA 網路的中繼同儕點，並透過在固網上的代理人提供資源和功能。採 用 P2P Agent-Based 的運作架構，能改善網路頻寬較低和行動裝置計算及儲存能 力較差的問題。然而，沒有採用 JXTA-ProxyLess 策略，在於目前的版本還在原 型階段，開發上仍然不穩定，此策略卻能提供行動隨易網最佳化的策略，未來技 術一旦成熟，純粹的行動隨易網會比較適合採用此策略。
P2P、Agent-Based 和 P2P Agent-Based 的 MWS 應用架構比較，如表 3.2 所 示，因為代理人代理複雜的運算和壓縮網路傳輸的資料，讓行動裝置的所剩能 量、網路頻寬、運算能力和記憶體容量，都會介於 P2P 和 Agent-Based 之間，適 合大眾化的點對點行動網路上網路服務分享的應用平台開發。
表 3.2 P2P、Agent-Based 和 P2P Agent-Based 的 MWS 應用架構比較
P2P Agent-Based P2P Agent-Based
所剩能量 小 大 中
網路頻寬 大 小 中
運算能力 大 小 中
記憶體容量 大 小 中
代理人裝置 無 有 有
3.2 JXME架構
JXME-Proxy的版本提供了三個應用程式介面，可以參考[7]：
z Element： JXTA的訊息，由許多元素所組成。
z Message： 提供了存取JXTA訊息的方法。
z PeerNetwork:
createInstance()：是個工廠函式，會傳回並建立一個PeerNetwork實例。
connect()：連結至指定的HTTP URI的中繼同儕點，會傳回持久狀態資 訊的位元組陣列。
create()：透過中繼同儕點代理在JXTA網路上建立節點、同儕群組或管 道。
search()：搜尋節點，同儕群組或管道。
poll()：在中繼同儕上輪詢在中繼同儕點上的中繼訊息。
listen()and close()：傾聽能開啟存取JXTA訊息的管道，關閉則是關閉管 道。
send()：當管道傾聽狀態，就能發送訊息至管道中。
開發 JXME 應用程式時，程式的撰寫必須利用「行動資訊的裝置設定檔」
(MobileInformation Device Profile，MIDP)，這是為了行動裝置上的 JAVA 語言所 制定的規範。行動裝置連接至整個 JXTA 網路，必須透過 JXTA 網路上的中繼同 儕點，才能交換訊息，如圖 5 所示。JXME-Proxy 版本中，只有支援基本的功能，
缺乏複雜的功能，讓行動裝置不能當伺服端直接提供 MWS，因為行動裝置受限 的運算能力和記憶體，JXME 缺乏開啟連接埠(port)的能力，而且缺乏 XML 格式 的支援，以 XML 格式為基礎的網路服務標準的 SOAP 技術規格也同樣不支援。
在 JXME-Proxy 版本中，行動裝置如何透過 JXTA 網路上的中繼點，建立 JXME 虛擬網路和訊息的交換，如下面的步驟對應至圖 3.2 的流程所示：
圖3.2 JXME虛擬網路
1.建立 PeerNetwork 與中繼同儕點連接並送出 HTTP 的需求。
2.中繼點把 HTTP 訊息轉成 XML 訊息，到 JXTA 網路裡交換訊息。
3.中繼點收到從 JXTA 網路傳來的 XML 訊息，轉成 HTTP 訊息。等待行動終 端點來輪詢，再將 HTTP 訊息傳給行動終端點。
4. 行動裝置輪詢中繼點上的訊息，並回傳輪詢後的回應訊息給行動終端點。
3.3 RMS 連接資料庫
「JAVA 資料庫連接器」(JAVA Database Connectivity，JDBC)是一套應用程 式介面，在提供 Java 平台資料庫的連結，以利 SQL 指令存取資料庫。由於行動 裝置記憶體容量小和運算能力較低，J2ME 並不直接支援 JDBC 去連接資料庫，
一般是透過閘道器使用 JDBC 連接至 Java 平台資料庫。MIDP 提供一套小型的資 料庫系統「紀錄管理系統」(Record Management System，RMS)，以位元組陣列 的方式，在行動裝置上管理和儲存資料，開發應用程式時，提供細微、同步、順 序的存取。交換及傳輸的資料是 XML 文件，為了能讓電腦去理解 XML 文件，
須外掛如 KXML 的 XML 剖析器(Parser)以剖析 XML 文件，並提供使用者自訂的 有意義標籤，分析標籤對應的資料涵義，達到資料的跨平台。KXML 可以是物 件驅動以樹狀展開(tree-based)XML 文件或是事件驅動(event-based)連續處理
XML 文件，選擇物件驅動當作 KXML 分析器，因為樹狀驅動符合本篇的需求，
能簡單存取樹狀架構上強健的資料。JDOM 是標準的 JAVA API 以物件驅動為基 礎，但是本篇選擇 KXML 為 XML 分析器，因為 JDOM 過於複雜，不適合行動 裝置，且 KXML 支援 CLDC 提供的核心函式，符合行動裝置的 XML 文件分析。
網路連線方面，為了維護跨多重 HTTP 連結的概念，我們使用了一個多方通 訊的議程(session)的概念。session 由伺服器維護，並有專有的 ID，每當終端機送 出需求，伺服器會回傳給終端機 session ID，session ID 是終端機表明自己身份的 一個識別證。cookie 是為了辨識用戶身份而儲存在客戶端的資料，Servlet 通常使 用 cookie 來傳送 session ID。因為考慮到代理人同時會接受多個行動裝置的連 接，採用 session 維護連線，伺服端建立 session ID 並透過資料流(datagram)傳輸 cookie 給客戶端，一個 cookie 代表一個連線的維護和建立，如此能讓代理人同時 處理多個客戶端的請求。
行動裝置的 MIDP 並不支援 Java 平台資料庫，因為 MIDP 在硬體上的限制，
為了讓 MIDP 的 RMS 和固網的 Java 平台資料庫互通，還須建立一個 JSP 閘道器 當作資料互通的媒介，使得 RMS 和 Java 平台資料庫能相互存取。RMS 存取 Java 平台資料庫上的資料架構圖，如圖 3.3 所示，連接和存取的過程如下面 4 個步驟 所示：
圖 3.3 RMS 連接 Java 平台資料庫
1.行動裝置(客戶端)建立 Session 連接至 JSP 閘道器(伺服端)，並透過 cookie 護 連線。
2.RMS 上的資料透過 KXML 剖析成 XML 文件，XML 文件經由 session 建立 的連線傳送給 JSP 閘道器。
3.JSP 閘道器收到 XML 文件，再把 XML 文件交給 KXML 剖析。
4.JSP 閘道器透過 JDBC，使用 SQL 指令存取 Java 平台資料庫上的資料。
3.4 系統架構
系統架構如圖 7 所示，架構上有五個角色，有線點、行動點、終端點、中繼點和 代理人，分述如下：
z 有線點
是建立在 JXTA 網路上能提供服務的節點，連結至代理人，透過網路服務傳 輸協定(Web Services Transfer)，把能提供的服務傳送並註冊在代理人上，因為代 理人能替代有線點提供服務存取點，避免因距離太遠而傳輸過慢，或有線點的連 接斷了而導致服務的存取失敗。
z 行動點
建立在 JXME 虛擬網路上的行動裝置，當連結至代理人時會去更新代理人上 註冊的服務，當代理人沒有此服務，行動點把服務傳輸且註冊在代理人上，反之，
當代理人有此服務時，行動點和代理人不用執行任何動作。行動點的使用者也可 以透過搜尋介面，經由排名和排序機制藉由相似度的比較運算，配對適合的服務 給使用者。行動點在同 JXME 虛擬網路下彼此分享服務，不用透過代理人，可 加速服務的分享，這分享機制更適合在範圍小及具主題性服務群的環境，在此環 境下相同的服務會重複使用，因而快速散佈，舉個範例：在海洋博物館走到鯊魚 景點，如果鄰近使用者擁有此服務，就能直接分享他的服務，鯊魚的服務便能很 快速的散佈在博物館的每位使用者。
z 終端點
JXTA 網路上不提供服務的節點，是建立 JXTA 網路的主要節點，因為大部 分的節點都是不提供服務的。JXTA 2.0 新增集結點，終端點可以透過集結點管 理，有效的傳播至相鄰的終端點或集結點，是改善舊版的傳播方式且能減少網路 資源的浪費。
z 中繼點
JXME 虛擬網路建立在 JXTA 網路上的基礎架構節點，行動裝置連接至同 JXME 虛擬網路，要預先得知中繼點的 IP 和連接埠，才能中繼訊息至 JXTA 網 路，行動裝置就能經由中繼點交換彼此的訊息。行動裝置交換訊息的方法，是行
動裝置和中繼點建立管道，管道須先進入傾聽的狀態，再透過中繼點傳送訊息至 JXTA 網路，並等待行動裝置輪詢中繼點上的訊息。
z 代理人
具備多種需要複雜運算處理的功能，由六項功能組成：蒐集鄰近點提供的服 務、提供註冊中心、發佈服務、RMS 與資料庫的連接、和搜尋最佳化的配對，
讓使用者能快速得到最適合的服務。
圖3.4 系統架構
系統的運作，包含下列的運作，如圖 3.3 所示：
z 註冊：服務提供者，將服務註冊在代理人上。
z 更新：提供服務者更新在代理人上註冊的服務。
z 傳輸：當代理人沒有行動點所擁有的服務，行動點把服務傳輸給代理人。
z 發佈：代理人發佈註冊的服務。
z 搜尋：行動點透過搜尋介面，由代理人的配對機制，配對給使用者最合適的 服務。
z 分享：行動點不需透過代理人，而是透過中繼點，彼此分享服務。
第四章 系統範例實作
4.1 系統開發環境
在這個研究中所使用的開發環境為在 Windows Server 2003 作業系統下，使 用 NetBeans 當作開發平台，配合使用語言為 JAVA 與 JSP 來撰寫程式，其中 JAVA 版本為 jdk-6u2。利用 Glassfish v2 來架設我們的網頁伺服器，搭配的資料庫為 MySQL6.0，當作伺服端的後端系統。利用 JXTA 2.5 版本架設固網上的中繼同儕 點，行動裝置連接到 JXME 虛擬網路須使用 JXME 2.1.3 的版本。行動裝置和代 理人同時安裝 XML 剖析器的 KXML，KXML 的版本為 KXML2。jzlib 則是用來 傳輸的資料壓縮函式庫，安裝在使用者端的行動裝置，版本為 jzlib-1.0.7。並詳 細資訊如下表 4.1 所示：
表 4.1 系統實作環境 硬體 CPU Intel Xeon ,3.2GHz
主機板 Ausu NCCH-DL 記憶體 4GB DDR 網路卡 Intel(R) PRO/1000 CT
軟體 作業系統 Windows Server 2003, Enterprise Edition 開發平台 NetBeans IDE6.0
開發程式語言 JAVA 與 JSP JAVA 版本 jdk-6u2 網頁伺服器 Glassfish V2 資料庫 MySQL 6.0 JXTA JXTA 2.5 JXME JXME 2.1.3
KXML KXML2 zlib Jzlib-1.0.7
4.2 範例系統設計
4.2.1 服務註冊
本篇所設計的系統上，註冊和搜尋功能主要應用在旅遊行程的組合排程，透 過此系統，和行動裝置的介面，根據使用者的偏好，系統會客製化一套旅遊的行 程給使用者。系統的服務樣本，參考[3]所提供的範本，總共有 150 個網路服務，
分為旅遊、飲食、和行程三大類，三大類又再各自分類成幾個服務特徵，服務特 徵擁有自己的服務屬性，舉個例子：旅遊這分類，又在分為 5 個服務特徵：價格、
人數、和地點等，人數的服務特徵又可以分為 1 人、2 人和 4 人服務屬性，地點 的服務特徵又可以分為墾丁、花東和綠島等服務屬性。系統範本的特徵與個數，
如下面的表 4.2 所示。
表 4.2 系統範本的特徵與個數
服務個數 服務特徵
旅遊 53 5
飲食 40 4
行程 57 2
4.2.2 系統功能
本篇的系統功能，包括註冊(Register)、搜尋(Discovery)和分享(Share)這三樣 功能，介面使用 MIDP 的行動裝置畫面，並結合[3]所架設的系統當作我們的註 冊中心。註冊時，MIDP 透過 JSP 閘道器連結至系統上的註冊中心，得知目前註 冊的服務，並把服務資訊列印在 MIDP 的行動裝置介面上，或是連結到固網上 的網頁也能得知註冊的服務。搜尋時，利用修改過的規則基準法的網路服務，把
原本回傳值的格式去除掉且在代理人上建立 JSP 閘道器來提供連接和存取。在搜 尋時，使用者透過行動裝置輸入使用者偏好，連結至註冊中心，使用者偏好先經 由排序機制和排名機制，再透過規則基準法的相似度運算得到行程、飲食和旅遊 的一組合適的服務，並只有挑選三類的前三名資訊給使用者，也可以透過固網上 網址輸入使用者偏好，取得一組合適的服務。在分享時，提供服務的行動點在 JXME 虛擬網路上廣播提供的服務，而使用者則是對中繼點輪詢服務，並等待使 用者去選擇服務，再把服務的資訊輸出在 MIDP 的行動裝置畫面上，此分享功能 應用在行動點的彼此分享，能減輕代理人的負載。
4.3 實驗執行與結果
4.3.1 兩種連線和交換訊息
系統建立兩種連線：RMS 連接資料庫的閘道器連線，及 JXME 虛擬網路的 連線。RMS 連接資料庫連線建立後，透過 JSP 閘道器行動點可發出需求(Request) 的 XML 文件，當 JSP 閘道器接受到需求訊息後，把經過運算的回應(Response) 的 XML 文件回傳給行動點，JSP 閘道器的回應訊息如下圖 4.1 所示。實做無線 網路上的 RMS 連接至固網上的 Java 資料庫，透過閘道器連線的步驟，可參考 JAVAWORLD 提供的範例[7]。
1. JXME 虛擬網路的連線，行動點須透過中繼點，與中繼點建立管道，行動裝 置才能經由管道傳輸訊息，分享行動裝置提供的服務。行動裝置與中繼同儕 點交換的訊息主要有三種：管道建立的訊息、管道傾聽的訊息、和管道傳送 的訊息，而管道傳送的訊息在細分成圖片和文字兩種，在後半段會詳細敘述 這三種訊息。管道建立後，會建立交換的訊息，管道建立的交換訊息如圖 4.2 所示，管道 ID 是自行設定的，而不是自動取得，並且把管道設定成傳遞型
(Propagate)，因為單一型(Unicast)的只能傳遞訊息給本身，而不能把訊息傳 給其他裝置。
2. 管道建立後進入傾聽狀態，才能傳輸訊息至管道內，傾聽狀態的訊息如圖 4.3 所示。
3. 傾聽狀態後才能傳送自訂的訊息，這邊自訂了兩種格式的訊息，分別為圖片 訊息和文字訊息，透過副檔名區分格式的不同。圖片訊息自訂了圖片的長與 寬(JXTATalkImageWidth 和 JXTATalkImageHeight)，MIDP 的畫布(Canvas) 讀取圖片的長度與寬度，再繪圖至行動裝置的螢幕上，而圖片的資訊包含在 JXTATalkImageData 標籤中，以位元組為單位傳送，圖片太大時就需要把檔 案作分割傳送，此時會用 JxtaTalkImageSimplifyData 自訂切割圖片為幾等 份，且 JxtaTalkImageSimplifyDataNumber 是圖片切割過後被分配到的切割區 塊上的圖片資訊，管道傳送的圖片訊息如圖 4.4 所示。文字訊息自訂 JxtaTalkTxtData 標籤，讀取文字檔裡面的內容，再把讀取到的內容繪圖在畫 布上，管道傳送的文字訊息如圖 4.5 所示。
圖 4.1 JSP 閘道器回應的 XML 文件
圖 4.2 管道建立的訊息
圖 4.3 管道傾聽的訊息
圖 4.4 管道傳送的圖片訊息
0 JxtaTalkSenderName 1 JxtaSendRoleAction Share 2 JxtaTalkFileName kenting.png 3 JxtaTalkImageWidth 300 4 JxtaTalkImageHeight 384 5 JxtaTalkImageLength 115200 6 JxtaTalkImageSimplifyData 5 7 JxtaTalkImageSimplifyDataNumber 3 8 JxtaTalkImageData
9 response data 10 id
urn:jxta:uuid-59616261646162614E50472050325033D1D1D1D1D1D141D191D191D1D1D1D1D104 11 EndpointSourceAddress
jxta://uuid-59616261646162614E504720503250338A65EA80D26540E28D24E648410D1D5103 12 EndpointDestinationAddress http://0.0.0.0:0/EndpointService:jxta-NetGroup
0 response success 1 requestId 1
2 EndpointSourceAddress
jxta://uuid-59616261646162614E504720503250338A65EA80D26540E28D24E648410D1D5103 3 EndpointDestinationAddress http://0.0.0.0:0/EndpointService:jxta-NetGroup
0 response success 1 requestId 0 2 type PIPE
3 name JxtaTalkUserName.Hotel 4 id
urn:jxta:uuid-59616261646162614E50472050325033D1D1D1D1D1D141D191D191D1D1D1D1D104 5 arg JxtaPropagate
6 EndpointSourceAddress
jxta://uuid-59616261646162614E504720503250338A65EA80D26540E28D24E648410D1D5103
圖 4.5 管道傳送的文字訊息
4.3.2 實作系統介面和功能
因為使用者行動裝置的操作，不同於一般在網頁的操作，且 RMS 會因為 MIDP 的關閉而資料消失，當 JXME 虛擬網路必須連接到指定的中繼點上，須先 輸入中繼點的連結設定，並把設定值存在 RMS 上，如圖 4.6 所示。連結至中繼 點後，可以選擇三個功能：註冊、搜尋、和分享。註冊時，相鄰節點會把服務註 冊給代理人，代理人再連接 JXME 虛擬網路發佈目前註冊的服務，由旅館、飲 食和行程三類所組成，如圖 4.8、4.9 和 4.10 所示。搜尋時，使用者必須透過 MIDP 先輸入使用者偏好，如圖 4.12 所示，並連結至代理人做排序機制和排名機制，
再經由規則基準法的相似度運算，得到合適的一組服務，由旅館、飲食和行程各 取前三名組成，如圖 4.13、4.14 和 4.15 所示，使用者也可以在固網上利用網頁 應用程式，在 Web 系統上輸入使用者偏好，能得到同樣的服務，如圖 4.16 所示;
分享時，行動裝置透過中繼點分享彼此服務，行動裝置不必透過代理人分享服 務，先得知行動裝置提供的服務，如圖 4.18 所示，使用者再輪詢中繼點所提供 的服務，如圖 4.19 所示，選取的服務類別可以為圖片檔和文件檔，使用者選取 後的結果如圖 4.20 和 4.21 所示。
0 JxtaTalkSenderName 1 JxtaSendRoleAction Share 2 JxtaTalkFileName restaurant.txt
3 JxtaTalkTxtData Restaurant is a good place.
4 response data 5 id
urn:jxta:uuid-59616261646162614E50472050325033D1D1D1D1D1D141D191D191D1D1D1D1D104 6 EndpointSourceAddress
jxta://uuid-59616261646162614E504720503250338A65EA80D26540E28D24E648410D1D5103
7 EndpointDestinationAddress http://0.0.0.0:0/EndpointService:jxta-NetGroup
圖 4.6 中繼點設定 圖 4.7 註冊功能
圖 4.8 註冊的行程服務 圖 4.9 註冊的旅館服務
圖 4.10 註冊的飲食服務 圖 4.11 搜尋的功能
圖 4.12 搜尋時輸入的使用者偏好 圖 4.13 搜尋配對的行程服務
圖 4.14 搜尋配對的旅館服務 圖 4.15 搜尋配對的飲食服務
圖 4.16 系統上的規則基準法服務選擇畫面[1]
圖 4.17 分享的功能 圖 4.18 行動裝置上提供的服務
圖 4.19 使用者輪詢到的服務 圖 4.20 圖片檔分享
圖 4.21 文字檔分享
第五章 系統實驗分析
在本章裡，會得知 JXME 及其中繼同儕點的性能，和 zlib 壓縮方法之 memory 壓縮比和壓縮解壓縮時間長度，最後比較系統分享功能壓縮和未壓縮的回應時 間。在 5.1 中，會先提出兩個實驗環境，並解釋影響系統效能的參數。在 5.2 中，
分析系統上的記憶體分配，和介紹中繼點及 MIDP 的記憶體釋放。在 5.3 中，分 析單機模擬網路環境中，參數彼此之間的關係。在 5.4 中，介紹 zlib 並且分析 zlib 壓縮比和壓縮解壓縮時間。在 5.5 中，在多機模擬網路環境中，分析系統有壓縮 和未壓縮的優缺點。
5.1 實驗的模擬環境
實驗的模擬環境，可以分成「單機模擬網路環境」和「多機模擬網路環境」，
在 5.3 和 5.4 節都是用單機模擬網路環境，5.4 則是用多機模擬網路環境。單機模 擬環境比較單純，可以測試 JXME 及其中繼同儕點的性能極限，因為可以免除 一些外在的因素，例如：中繼點的連結數過多等；然而，多機模擬網路環境是最 適合分享的環境，因為服務的分享來自於多個使用者，是本篇架構上的分享環境。
單機模擬環境，是一個行動裝置使用者提供服務，並選擇他想要的服務，使 用者在最快的回應時間獲得自己想要的服務；多機模擬網路環境，是 4 個的行動 裝置使用者去分享彼此的服務，第四位行動裝置使用者，能在最快的時間獲得使 用者選擇的服務。
單機和多機模擬網路環境，有下列的參數會影響整個系統效能：
z 服務的大小：記憶容量大小，會藉由中繼同儕點中繼訊息。
z 服務發佈的時間間距：依據服務的 memory 大小，需多久的發佈時間，去制 定發佈的時間間距。
z 回應時間：使用者選擇的服務，最快能在多久的時間獲得回應，獲得 5 次取 平均值當作回應時間。
z 壓縮比：當服務壓縮時，服務 memory 縮減了多少比例，就是服務的壓縮比。
z 壓縮和解壓縮時間：壓縮所花的時間，和接收壓縮資料去解壓縮的時間。
5.2 記憶體的分配和釋放
開發 J2ME 的程式時，最容易遇見 Out Of Memory 的問題，所以在這先說明 J2ME 上的記憶體(memory)相關設定、再探討系統上記憶體的分配與記憶體的釋 放。MIDP 設備的記憶體分為三種，「程式記憶體」(Program Memory)、「堆疊 記憶體」(Heap Memory)、「持久儲存記憶體」(Persistent Storage Memory) 。Program Memory 是移動資訊設備分配給 MIDlet suite 的空間；Heap memory 用來儲存程 序和本地端變數的記憶體大小為 1945.4kb；而 Persistent Storage Memory 通常用 來保存設定檔，只有 32kb 的大小，實現了手機上持久儲存的能力，RMS 是其範 例。然而，MIDP 開啟圖片時，會產生的 MIDP 內存量為寬 * 高 * 畫素 (pixel) (bytes)，Pixels 值跟行動裝置型號有關係，所以要有效減少圖片的內存量，就是 降低圖片的寬 * 高。圖片常因為內存量大於 Heap Memory，而遇到 Out Of Memory 問題，可以去更改預定的記憶體容量，以符合行動裝置越來越高的性能。
本篇系統執行分享功能時，行動裝置端記憶體使用分配為：
1. MIDP_Code：MIDP 程式碼的長度。
2. RMS 的紀錄：紀錄在 RMS 上的紀錄，例如：中繼同儕點的設定等。
3. 發佈的服務：行動裝置上提供和分享的服務。
4. 選擇的服務：使用者選擇其他人所發佈的服務。
5. 服務的執行：服務的執行時所花費的 memory 容量。
本篇系統中，當分享的服務是佔用比較大量的記憶體時，預設的 Heap Memory 經常會不夠大，例如：圖片，服務在上面的選項 3、4 和 5 會重複佔用 大量的 Heap Memory，經由評估過後，服務的記憶體最大可以是 500kb 左右。
本篇系統中，記憶體的釋放分為行動裝置的 MIDP 記憶體釋放和中繼同儕點 的中繼訊息記憶體釋放。行動裝置的 MIDP 記憶體釋放，是當開啟檔案或是繪製 圖案(Canvas)時，會隨著執行的結束把暫時的記憶體釋放；中繼同儕點的中繼訊 息記憶體釋放，是當中繼同儕點上的訊息已滿時，會開始丟棄已經使用過的訊 息，或是中繼點忙著傳送訊息時，新進來的信差(Messenger)會被關閉，並把訊息 丟到一個輸出緩衝器(Output Buffer)，等到 Output Buffer 滿了或是一段時間後，
就會把訊息中繼至中繼同儕點。但是，中繼同儕點上的中繼訊息，如果來不及釋 放，Output Buffer 就會產生阻塞(Block)的現象，此管道新進的訊息就會一直被丟 棄，導致輪詢回應時間大於 10 分鐘，系統的效能會降低許多，如圖 5.1 所示。
5.3 單機模擬網路環境
阻塞的現象，如圖 5.1 所示，Small 的藍色折線是代表 58.2kb 的資料大小，
關係為發佈的次數和第一次輪詢到服務的回應時間，而 Large 的紅色折線是資料 較大的服務，資料大小為 320.6kb，從圖中得知 Small 折線一定能輪詢的到發佈 的服務，而 Large 的折線在次數 8 的時候，會產生阻塞的現象。
圖 5.1 中繼同儕點的阻塞
為了預防中繼同儕點上管道發生阻塞的現象，拉長服務發佈的時間間距，讓 Output Buffer 有足夠的空間釋放中繼訊息，使用者才能輪詢到分享的服務。經由 實驗分析後，得知發佈的服務記憶體大小每增加 100kb，服務發佈的時間間距就 要增加 1 秒左右，呈現正比的關係，如圖 5.2 所示。服務越大使用者輪詢得到的 時間也越長，經由實驗分析後，服務大小和回應時間成正比，且 600kb 的服務在 8 秒左右就能分享完成，又得知 JXME 分享的網路速度快，服務大小和回應時間 的關係圖，如圖 5.3 所示
圖 5.2 服務每 100kb 大小拉長 1s 發佈時間間距，就能解決 Block 問題
圖 5.3 JXME 分享的網路速度，600kb 服務大小，8 秒左右完成
5.4 zlib 資料壓縮法
zlib 是提供資料壓縮之用的函式庫，此函式庫為自由軟體，而且另外提供了 Java 版本的 Jzlib，zlib 使用 DEFLATE 演算法 ，DEFLATE 是同時使用了 LZ77 演算法與霍夫曼編碼(Huffman Coding)的一個無失真壓縮演算法。zlib 是 PNG source code 官方的程式庫，幾乎只要是 PNG 相關的都會使用到 zlib，又 PNG 圖 片幾乎是 J2ME 平台上圖片格式的標準，所以 zlib 適合本篇系統的資料壓縮法。
zlib 壓縮的性能好壞可以分為兩種，服務記憶體壓縮比和壓縮與解壓縮時間 長短，當記憶體壓縮比越高，或壓縮和解壓縮時間越短，都會提昇壓縮的品質。
系統上的分析，服務記憶體的壓縮比，可以分為記憶體容量較小的文字服務和容 量較大的圖片服務，經由分析後得知，zlib 在服務很小時，產生的壓縮比只有 20%，直到服務的大小超過 4kb，就會維持 80%的高壓縮比，適合在有限頻寬的 無線網路環境下使用，文字服務和圖片服務的壓縮比圖，如圖 5.4 和圖 5.5 所示。
圖 5.4 文字服務大小和壓縮比的關係
圖 5.5 圖片服務大小和壓縮比的關係
系統上的分析，壓縮和解壓縮時間，一樣分為記憶體容量較小的文字服務和 容量較大的圖片服務，經由分析後得知，文字服務只有在小於 1kb 時，才會出現 壓縮時間大於解壓縮時間，並且，文字服務的壓縮和解壓縮時間短，跟沒有使用 zlib 所花費的時間差不多，服務較大的時候，壓縮和解壓縮時間就會拉長，會影 響系統上服務發佈的時間和系統整個效能，文字服務和圖片服務的壓縮和解壓縮 時間比圖，如圖 5.6 和圖 5.7 所示。
