國
立
交
通
大
學
資訊學院 資訊學程
碩
碩
碩
碩
士
士
士
士
論
論
論
論
文
文
文
文
個人化儲存服務系統平台之設計與實作
Design and Implementation of a Unified Personal Storage
Framework and Service
研 究 生：吳 捷
指導教授：曾建超 教授
個人化儲存服務系統平台之設計與實作
Design and Implementation of a Unified Personal Storage
Framework and Service
研
究
生：吳
捷
Student：Chieh Wu
指導教授：曾建超
Advisor：Chien-Chao Tseng
國
立
交
通
大
學
資訊學院
資訊學程
碩
士
論
文
A ThesisSubmitted to College of Computer Science National Chiao Tung University in partial Fulfillment of the Requirements
for the Degree of Master of Science
in
Computer Science June 2010
Hsinchu, Taiwan, Republic of China
個人化儲存服務系統平台之設計與實作
學生：
吳
捷
指導教授
：曾建超
博士
國 立 交 通 大 學
資 訊 學 院
資 訊 學 程 碩 士 班
摘
要
本論文設計並實作一套整合性個人檔案平台以整合個人在網路儲存媒體所擁
有的儲存空間，使用者可透過此平台所提供之單一介面，存取不同儲存空間以及
本地端硬碟的資料，而且存取不同儲存空間時，使用者不會察覺到儲存媒體或使
用方式的不同，此外，也可藉由此平台與他人分享在不同儲存空間的檔案，分享
時也不會有認證或是存取上的困擾。此平台讓使用者更能充分運用與發揮網路儲
存空間所帶來的便利。
受惠於網路儲存媒體所提供免費且大量的儲存空間，使用者可擺脫時間與地
點的束縛，透過網路存取上述儲存空間。善用這些儲存空間亦可有效地幫助使用
者備份與分享檔案。然而不同網路儲存媒體間不僅存在有相容性問題，亦無法與
使用者原有的儲存設備整合，在分享檔案時也因相容性問題使得分享功能倍受限
制。因此在享受網路儲存服務所帶來的便利時，使用者也必須忍受使用上所產生
的問題。
本論文針對上述問題提出整合性個人檔案平台，使用者可透過本平台利用單
一操作方式存取各式儲存服務與儲存空間，除了延續使用者操作經驗，也達到管
理眾多不種儲存媒體的目的。此外本平台亦提供使用者利用互相信賴之分享機
制，透過較直覺的方式分享檔案給朋友而不需要額外的服務帳號或認證。最後本
平台延伸瀏覽器的環境至使用者桌面使檔案存取不再限制於瀏覽器中，而能持續
與使用者保持互動。
Design and Implementation of a Unified Personal Storage
Framework and Service
Student：Chieh Wu
Advisors：Dr. Chien-Chao Tseng
Degree Program of Computer Science
National Chiao Tung University
ABSTRACT
In this thesis, we present the design and implementation of a Unified Personal
Storage Platform that can integrate the storage spaces a user acquired from various
network storage services. Under this platform, users can access various network or
local storages via a single access interface and will not be aware of the differences of
underlying storage services. Furthermore, users can also share their resources in this
platform without suffering from authentication or sharing policy issues. In a word, the
“Unified File Platform” can help users to manage their own storage spaces across
Internet and share information with others very conveniently without detail.
Because of the free and huge spaces provides by many emerging network storage
service providers, users can access their photos, videos or other resources any time
and any where. Furthermore, users can also use these storage spaces to backup or
share files. However it is inconvenience for user to manage many storage spaces
across various network storage service systems with different authentication or access
mechanisms. Furthermore, different network storage service providers may adopt
different sharing policies.
In order to resolve above issues, the UPS platform provides a unified GUI for
users to manage and access different storage services across Internet. The unified GUI
inherits the concept of common file access interfaces and all storages appear as files in
UPS. Furthermore, UPS also provides a sharing mechanism with trusted relationship.
With this mechanism, user can share or access file without tedious account creation
and authentication procedures. Last but not least, UPS client can run on desktop so
that it can notify users the changes in file sharing.
誌
謝
本篇論文的完成首先要感謝指導教授
曾建超博士，感謝教授不
論在研究方向或是研究方法上給予我的指導，特別是教授在教學上嚴
謹的態度與完整的思考邏輯，更是讓我獲益不少，我也要感謝教授在
這段期間能容忍我因工作所帶來的不便，讓我能順利完成研究與論
文。
另外我也要感謝所有口試委員提供的寶貴建議，讓本篇論文更加
完善，還有特別感謝實驗室的史永建學長與林家樑學長，謝謝他們在
研究與報告上給予我的協助與建議，幫我解決不少問題與疑惑。
求學與研究的路是漫長且辛苦的，特別是還有工作的考量，感謝
公司的同仁對我的幫助與諒解，也感謝我的父母以及太太姿如的鼓勵
與支持，讓我在遭遇困難與挫折時，能夠打起精神繼續的走下去，感
謝每一位幫助我完成論文學位的人，有了你們的陪伴，才能有我今日
的榮耀。
目
錄
摘 要 ... i ABSTRACT... ii 誌 謝 ... iii 目 錄 ... iv 表目錄... vi 圖目錄... vii 一、緒論...1 1.1 研究動機...1 1.2 研究目的...2 1.3 論文架構...3 二、相關背景研究...4
2.1 Virtual File System與Apache VFS Library ...4
2.2 雲端儲存 (Cloud Storage) ...5
2.3 eXtensible Access Method (XAM) ...6
2.3.1 XAM之目的...6
2.3.2 XAM架構...6
2.4 Storage Resource Broker (SRB) ...8
2.4.1 SRB架構...8 2.4.2 SRB 處理流程...9 2.4.3 SRB Federation之檔案交換機制...11 三、系統功能與需求分析...12 四、系統設計...14 4.1系統架構...14 4.2 各元件設計...16
4.2.1 Integrated File Management System (IFMS) ...16
4.2.2 Service Adapter ...20 4.3 UFP檔案分享機制...24 4.3.1 認證問題...25 4.3.2 即時的檔案分享資訊...26 五、實作與成果展示...28 5.1 系統實作...28 5.1.1 Widget與IFMS 之介面...28 5.1.2 Actions ...29 5.1.3 Common Interface ...30 5.1.4 Service Adapter ...32
5.1.5 Configuration File設定檔...35 5.1.6 Widget Notify實作...36 5.1.7 Message flow...37 5.2 成果展示...40 六、系統比較...45 6.1 功能比較...45 6.2 效能比較...46 七、結論與探討...49 7.1 未來發展...49 參考文獻...51
表目錄
表 1 XML資料回傳內容 ...29
表 2 UFP中Action動作 ...30
表 3 FileSystem介面中的function...31
表 4 jFileObject介面中的function...32
表 5 Java mail 與common interface之對應關係 ...33
圖目錄
圖 1 使用者存取不同網路儲存服務 ...2
圖 2使用者透過Unified File Service存取各式儲存服務...3
圖 3 Virtual File System在OS中之架構 ...4
圖 4 雲端儲存服務之基本架構 ...5 圖 5 XAM 架構圖...7 圖 6 XSystem與XSet之關係 ...8 圖 7 SRB的基本架構 ...9 圖 8 SRB處理流程 ...9 圖 9 SRB Agent內架構圖 ...10 圖 10 透過Federation做資料交換之流程 ...11 圖 11 UFP基本系統架構圖 ...14 圖 12 UFP 架構元件圖 ...15 圖 13 UFP基本處理流程 ...15 圖 14 User Application介面...17 圖 15 IFMS之內部處理流程 ...17 圖 16 Action元件的內部邏輯...18 圖 17 UFP虛擬檔案與Metadata...19 圖 18 服務與Service Adapter對應關係...20
圖 19 透過Service Adapter轉換網路儲存服務的protocol...20
圖 20 Service Adapter與Common Interface...21
圖 21 第三類服務之Service Adapter...23 圖 22 第四類服務與IFMS Agent...24 圖 23 UFP的分享角色與機制 ...25 圖 24 分享檔案之存取流程 ...26 圖 25 主動分享訊息之發佈 ...27 圖 26 Common Interface中的階層架構 ...31 圖 27 Gmail Adapter之實作 ...33 圖 28 服務之檔案上傳流程 ...34 圖 29 從HTML中找出下載資源之URL...34 圖 30 檔案下載 ...34
圖 31 Mobile Agent in Applet...35
圖 32 UFP之設定檔 ...36
圖 33 UFP之PUSH流程...36
圖 34 檔案基本操作之流程 ...37
圖 36 分享檔案之流程 ...38 圖 37 瀏覽分享檔案之流程 ...39 圖 38 下載分享檔案之流程 ...39 圖 39 基本Widget畫面...40 圖 40 開啟服務內容之畫面 ...40 圖 41 設定分享檔案或開啟檔案 ...41 圖 42 分享之檔案被標記”P”...41
圖 43 建立遠端UFP之Trust Server...42
圖 44 新增朋友UFP後之資料夾 ...42 圖 45 UFP Server分享檔案 ...43 圖 46 UFP Client存取分享檔案...43 圖 47 分享事件通知 ...43 圖 48 透過IFMS Agent整合儲存服務 ...44 圖 49 檔案上載至Gmail服務...46 圖 50 檔案從Gmail服務下傳...47 圖 51檔案上載至FTP Server服務...47 圖 52檔案從FTP Server服務下傳...48
一、緒論
1.1
研究動機
隨著儲存的技術發展，儲存容量的成長速度越來越快，個人儲存裝置的容量 已經不再是問題，在Internet上也有越來越多的線上服務開始提供大容量且免費 的儲存服務, 使用者可以將自己的照片, 影片或是文件存放到這些空間中, 並且 開放與朋友分享，另一方面, 自從雲端運算的概念被提出後，相對應的雲端儲存 服務也如雨後春筍般的出現，使用者透過一些既有的介面存取雲端中的檔案，就 如同存取自己硬碟裡的檔案一般，透過網路，使用者存取服務內的文件與檔案時 可以不受時間與地點的限制，這些服務特別適用於檔案文件的備分[ 1]與分享， 傳統上使用者必須花心力於儲存裝置的擴充與維護，但利用網路儲存服務，使用 者只需專心於文件和檔案的管理即可，儲存硬體的整合與維護工作則是交給服務 廠商。 但是在享受這些服務的同時，我們也見到許多使用這些儲存服務上的問題 1.使用者必須面對不同的操作環境 雖然目前很多的線上服務都有直覺性的操作介面，但各服務之間所能提供的功能 與操作步驟都有一定程度的差別，有時使用者必須透過許多的網頁才能順利的存 取到需要的檔案，這些網頁中有包含有許多的廣告，無形之中增加了存取的時 間，再者使用者可能必須為了存取不同的服務而必須安裝不同的介面程式，在使 用上來說也是一件麻煩的事情。 2.管理多個服務不易 使用者有時為了要得到更多的免費空間或是存放不同類型的檔案，常常申請許多 相同或不同類型的儲存服務，當需要使用這些空間時，使用者必須記得這些散落 在各地的檔案，有些服務也許因為閒置太久沒有存取，可能連帳號都已遺失。 3. 難與個人儲存裝置整合 線上儲存服務很難與本地儲存設備或是其他儲存服務整合，雖然目前雲端儲存都 有提供標準的存取介面，但雲端服務大都擁有特別的使用端介面，與使用者既有 的檔案管理介面不同，在使用的方法上也有出入，當使用者要在這些服務與儲存 裝置之間移動檔案時，必須花費一番功夫才能達到目的。 4.會員制分享機制的限制 線上服務大多具有分享機制，使用者可以將檔案、圖片與朋友分享，但分享的對象僅限於該服務的會員，不同的服務之間也無法做檔案的分享，試想在Flickr上 分享照片給朋友時，朋友也必須有Flickr的帳號，若是沒有認證的分享機制，則 又有安全上的考量。 5.瀏覽器存取的限制 線上服務大多透過瀏覽器進行存取，所有存取動作也都是透過瀏覽器，一但關閉 瀏覽器，則使用者就無法取得服務的任何訊息，也無法得知及時的檔案狀態，再 者，不同的瀏覽器也存在著不相容的問題，某些特別的服務功能可能只適用某個 特定的瀏覽器，對使用的方便性來說，也是一大折扣。 圖 1 使用者存取不同網路儲存服務 基於以上的問題與需求，我們提出一個新的個人檔案管理平台，能夠解決這些問 題，並且符合使用者未來的需求。
1.2
研究目的
本研究的目的是在設計與發展一套個人化的檔案整合系統，透過本系統，使 用者可整合目前的儲存服務與裝置，並且充分享受線上儲存服務所帶來的便利 性，讓使用者不再有儲存空間上的限制，面對異質性的儲存媒體上也可以輕鬆的 管理或是移動檔案，可減少日常備份或是分享檔案時不必要的轉換，以及在不同 儲存服務之間難以管理的情況，系統必須要能提供以下三大功能:1.能夠提供整合性檔案存取平台，使用者透過本系統可利用同一種操作方式存取 各式各樣的儲存服務與儲存媒體，對使用者來說不但延續了使用操作的經驗，也 達到管理眾多不種服務的目的。 2.能夠提供使用者利用互相信賴之分享機制，透過直覺的方式將檔案分享給所需 要的朋友而不需要額外的服務帳號或認證。 3.延伸瀏覽器的環境到使用者的桌面，檔案的存取不再只限制在瀏覽器中，而是 能持續與使用者保持互動。
圖 2使用者透過Unified File Service存取各式儲存服務
1.3
論文架構
本論文內共分七章，依序如下，第一章為序論，說明為何要發展此個人化檔案系 統，其目的與目標為何? 第二章為相關背景研究，介紹目前有哪些標準或是類似 的檔案整合系統，第三章系統功能與需求分析，描述現存系統的問題與缺點以及 本系統如何解決這些問題，第四章為系統設計，詳述系統各內部元件之功能與機 制，為了達到所需要的功能或是解決現存問題系統內部應該如何設計，第五章實 作與成果展示，說明如何依據設計做出實際的系統以及系統細部實作，並且展示 系統運作之畫面，第六章系統比較，列出本系統與現存系統之功能比較，最後第 七章總結，說明本研究之結論與貢獻以及未來發展之可能方向。二、相關背景研究
本章將就目前現有之檔案整合平台與相關技術作介紹。
2.1 Virtual File System
與
Apache VFS Library
虛擬化檔案系統(Virtual File system)，是架構在真實檔案系統上的抽象層
(abstract layer)，不同的檔案系統透過抽象層將實體檔案系統隱藏起來，並且透
過一個統一的介面進行存取，使用者在存取檔案時，就如同存取本地端的硬碟
般，讓使用者不會查覺到所使用的檔案系統之不同，藉由Virtual File System的
隔絕，不同的檔案系統可被同時使用在同一個OS(Operation System)當中。
所謂的抽象層在Virtual File System中是指一個已經定義好的介面，最早實
作此抽象層的系統是在UNIX類的OS中，此介面是介於系統核心與檔案系統之
間的橋樑，系統核心存取檔案都須透過此一抽象層，近年來越來越多的系統都可
以實作出Virtual File System，它不但可以存在於系統核心層(Kernel Layer)也可
以存在於應用層(Application Layer)。
圖 3 Virtual File System在OS中之架構
Apache Common Virtual File System[ 2]便是一個使用Java所開發在應用
層的Virtual File System Library，透過它所提供的API，使用者可以開發存取不
同檔案系統的應用程式，其中包含Local Files、FTP、HTTP以及 ZIP和GZIP
等壓縮檔，透過VFS library使用者不會察覺到使用不同的檔案系統，在存取檔
案時所使用的方式都是一樣。
Linux的FUSE (Filesystem in Userspace)[ 15]則是一個存在於Linux Kernel
的Virtual File System模組，透過FUSE使用者可以開發整合不同的File System
kernel，目前已有多種檔案系統可透過FUSE掛載，以下舉幾個透過FUSE所完 成的FileSystem • SSHFS: 透過SSH協定存取遠端檔案 • Httpfs: 透過HTTP協定存取遠端檔案 • GmailFS: 透過檔案系統方式存取GMail
2.2
雲端儲存
(Cloud Storage)
雲端儲存是最近幾年從雲端計算(Cloud computing)所延伸出來的概念，雲 端儲存不是一種儲存技術，而是一種服務，雲端儲存透過網路軟體技術將大量不 同類型的儲存裝置整合起來，提供外界資料存放與管理之服務，使用者透過網路 即可存取到自己所存放的資料，而不需考慮複雜的儲存設備與硬體建構的問題， 在雲端儲存內部包含了許多複雜的技術，一般來說我們將雲端儲存的架構劃分為 五層架構[ 3]。 圖 4 雲端儲存服務之基本架構1. Network and storage infrastructure: 提供基本的網路與儲存的硬體架構，使
用者主要透過網路存取雲端裡的資料，所以在雲端儲存服務當中，最底層的 基本設施便是網路與儲存設備。
2. Storage management: 提供實體資料的儲存方式，其中定義了儲存方法與結
構，分散式儲存的管理與資料群組的劃分等。
3. Metadata management: 透過整合不同資料群組的metadata，讓處於不同群
組內的資料互相交流，進而讓不同群組協同工作。
4. Storage overlay: 提供單一的邏輯儲存單元，虛擬化技術與資料存取都在此
層實作，從使用者角度來看只會看到簡單的介面與單一的儲存裝置。
5. Service Interface: 提供一致性的介面給使用者進行資料存取，並且管制
Client端的存取方式與權限。
Amazon 的 S3 (Simple Storage Service) 是典型且相當有名的雲端儲存服
存物件的容量定為5 Gbyte，所有的儲存物件在系統中都被存放在Buckets中，
每個Bucket都有一個特有的名稱與使用者所設定的密碼，Bucket與儲存物件可
被建立或是透過HTTP與SOAP (Simple Object Access Protocol) 介面存取，
每個存取的請求都必須先經過使用者所設定在 Bucket 內的密碼或是物件中的
access list的驗證，Amazon聲稱直到2010年三月，儲存於S3服務的資料物
件已高達102百萬個。
2.3 eXtensible Access Method (XAM)
2.3.1 XAM之目的
XAM是指 (eXtensible Access Method) ，它是由Storage Networking
Industry Association (SINA) 所提出的新一代儲存裝置介面的標準，SINA有鑒
於在現存之儲存設備的管理與整合因為受到各家業者特定的儲存介面而無法互 相溝通，因此才提出了此一標準。
一般所謂的資料檔案(fixed content file)的生命週期相當長，這些檔案大部分
只做於參考使用，不會經常被更新，但是當我們在儲存這些檔案時，所使用的儲 存技術卻是不斷的更新，當管理者把資料從舊系統移植到新系統時，許多不相容
的問題也就浮現，XMA的概念即是把資料(data)看成是一個物件(Object)，其中
包含資料本身以及自我描述(self-describing)的資料，所謂自我描述的資料即記
錄資料本身特性和屬性的metadata，藉由這樣的方法，儲存系統不需要去識別
(recognize)這些資料，而是去讀取這些metadata進而了解資料的特性，XAM定
義了這些metadata的格式與查詢這些描述資料的介面，以及如何藉由這些介面 去取得所需要的資料，SINA期望透過XAM的制定能夠做到以下三點: 1. 應用程式可以跨不同儲存媒體使用。 2. 資料物件(Data Object)可以在不同的儲存裝置中移動。 3. 資料物件(Data Object)可以在不同的應用程式之間移動。 2.3.2 XAM架構
在XAM中，定義了兩個標準的Interface，分別是XAM API與VIM(Vendor
Interface Module)[ 14]
1. XAM API: 定義XAM架構與應用程式端的介面，應用程式透過此介面可存取
到Storage資料，應用程式必須連結此XAM library方可使用此API。
2. VIM API: 定義儲存系統與XAM架構之間的介面，讓XAM可透過此介面存
圖 5 XAM 架構圖
應用程式透過XAM API存取儲存裝置，而XAM library會選擇適當之VIM
與裝置溝通，應用程式同時也可透過Toolkit API使用XAM library，Toolkit是包
含XAMQuery，XUID等工具類的API，使用這類toolkit的API可更方便存取
XAM library。在XAM中包含兩個重要的元件，分別是XSet與XSystem。
• XSet: 在XAM中，XSet可以代表資料的邏輯單元，任何資料進入XAM都
被包裝成XSet，當應用程式將資料透過XAM送往儲存裝置時，XAM會建立
XSet並且將資料填入後送至儲存裝置，若過程順利成功，儲存裝置會回應一
個XUID給應用程式，應用程式透過此XUID便可搜尋到這筆資料，同時也
可以透過交換此XUID而達到與其他應用程式交換資料的目的。
• XSystem: 可以看成是裝滿XSet的容器，XSystem提供了存取與管理XSet
的能力，XSystem同時也提供了XSet的建立、搜尋、刪除與儲存的方法，
應用程式透過XSystem可以存取到XSet並且存取到所需要的資料，而
XSystem本身也具有基本的XSet管理能力，像是存取XSet的安全機制、虛
圖 6 XSystem與XSet之關係
外部的應用程式可使用XAM Library存取XSystem，XAM library目前提供
C與Java的程式binding介面讓應用程式透過XAM library存取XSystem，另
外XAM Library也定義了安全機制，它使用SASL (Simple Authentication and Security Layer) authentication機制確保與應用程式之間的安全。
2.4 Storage Resource Broker (SRB)
Storage Resource Broker是一種分散式資料系統，由聖地牙哥國家超級計
算中心 (SDSC）所開發， SRB 是一套結合資料庫系統與檔案系統觀念的分散 式檔案管理與資源儲存系統，它是一個Client/Server架構的middleware系統， 在Client端，它提供了使用者一個存取多種異質存儲系統的統一介面，涵蓋了異 質儲存系統的特性。它支援廣域網路環境下多種資料源的存取，並且提供了資料 複製、複本資料的存取、檔案的彙集、分散式檔案的邏輯集合等功能。 2.4.1 SRB架構
在SRB的架構中有三項重要的元件，SRB Client, SRB Server與MCAT
(Meta data Catalog)[ 4]，其功能分述如下:
1. SRB Client: 透過SRB所提供的API進行資料的存取，SRB有提供可整合
之API與user application 程式。
2. SRB Server: 負責接收Client端的請求，並將結果回傳，另一方面SRB
Server也必須負責與MCAT溝通以及與底層不同的儲存系統進行存取。
使用者資料以及各種不同儲存資源的metadata，這些metadata定義了存取 權限的控制、資料儲存的結構 (Collection) 等，透過MCAT所提供資料的 logical name或是屬性，使用者所存取的不再是資料檔案的實體位置，因此 可以將儲存系統與應用程式分離。 圖 7 SRB的基本架構 2.4.2 SRB 處理流程 在SRB處理Client端請求時，主要的兩個基本元件為SRB Master與SRB Server也稱為SRB Agent。 圖 8 SRB處理流程
SRB Master在SRB系統中扮演Server的角色，它持續接收Application所發送
的請求，一但Application與SRB Master連線並通過認證後，SRB Master會產
時SRB Master也可以接收其他Application的請求，而這個新產生的Server
Process在SRB中被稱為SRB Agent，Application透過網路利用一組定義好的
API與SRB Agent溝通，因此Application與SRB Agent或SRB Master可存在
於不同的主機當中。
在SRB Agent的架構當中，每個Client的請求都經過Dispatcher發送到位
於SRB Agent內的兩個Handler，分別是High level handler與Low level handler
• High level handler: 負責處理需要經過 MCAT的請求，若資料經由MACT
取得，則MCAT會自動對資料進行管理追蹤，直到資料從儲存系統中刪除，
當使用者進行資料的建立、檔案存取、搜尋或是檔案權限管控時，這些動作
都必須存取MCAT內的metadata，而這些動作也必須透過High Level
Handler進行。
• Low level handler: 處理不需經過MCAT的Application請求，有時這些請求
也來自於High Level handler，Low level handler負責處理與儲存系統溝通
的I/O能力，目前在SRB系統中Low level handler只有定義對檔案系統與
資料庫存取的能力。
圖 9 SRB Agent內架構圖
何時需要High level handler或Low level handler是取決於Application的請求，
例如: 使者想在系統中儲存一個檔案，當請求進入SRB Agent後，SRB Agent
先使用High level handler到MCAT中找尋使用者權限或是可使用之儲存資源，
動作，並且同時在MCAT中建立該檔案的metadata進行追蹤，而SRB Agent
會將該檔案的handler回傳給Application，Application便可利用此handler進行
後續的讀寫檔案，若此資料是存放於本地主機上的儲存系統，則SRB Agent會
直接將後續Application 讀寫請求交由Low level handler作I/O上的存取。
2.4.3 SRB Federation之檔案交換機制
SRB Server也可以組合起來成為一個Federation，一同處理Application的
請求，並且在這些Server中交換彼此檔案資源，以Application發出開啟資料之
請求為例，整過資料交換過程如下:
圖 10 透過Federation做資料交換之流程
1. Application在與Server A上的SRB Master完成認證與連線後，便發送開啟
資料的請求給所屬的SRB Agent。
2. SRB Agent會傳送User ID 與資料名稱給MCAT要求確認Application是否
有足夠的權限存取相關資料，經過確認後，MCAT會回傳該資料所在儲存裝置
上的實體位置。
3. 若Server A上的SRB Agent發現所要求的資料位於Server B上，Server A
上的Agent會發出開啟資料的請求給Server B上的SRB Agent。
4. Server B上的Agent會根據儲存系統的型態，發出存取檔案請求給Low level
handler以便取得File handle以及資料的相關資訊回傳給Server A。
5. Server A上的Agent將所得到的File handle以及相關資訊回傳給
三、系統功能與需求分析
本章介紹系統設計的概念與系統架構，在決定系統的功能之前，必須先暸解 現行檔案整合系統平台的問題與缺點，分別由以下三個部分來說明。 1.在使用者介面方面: 大多數的網路儲存服務的使用者介面都是以瀏覽器為主，雖然使用者端不需 額外安裝任何軟體只需用瀏覽器即可，但有許多功能也因此被限制在瀏覽器中， 脫離了瀏覽器便無法使用。 2.在整合網路儲存服務方面: FUSE與Apache VFS雖然有能力整合不同檔案系統，但本身不是一個完整 的檔案平台，兩者沒有檔案分享機制或是概念，這兩個虛擬檔案系統主要解決在 不同檔案系統之間的檔案存取問題，而非提供一個完整可用的個人化檔案管理平 台。 新興的雲端儲存服務大多只能存取服務供應商所提供的儲存空間，空間大小 的使用則是依照使用者付費的多寡而決定，對於現有其他免費的儲存服務則無法 相容，在這類服務當中雖然有提供檔案分享與權限管理的概念，不過分享的方式 為被動的告知，而非主動通知。 XAM是未來儲存媒體整合的一個標準，新標準的提出有助於對未來儲存服 務的整合，並且有越來越多的標準將線上存儲也納入管理整合的範疇，但這必須 要線上儲存服務與平台開發者相互的配合才能實踐，對現今線上儲存服務的使用 者來說，此構想並非立即可行，而新系統對舊儲存服務的相容性也是一大問題， 現存的服務必須透過開發相容的介面才能與標準溝通，無形之中也增加了新標準 推行的困難度。 SRB具有很好的異質性儲存系統的整合能力，不過整合的儲存對象是以檔 案系統或是資料庫為主，而不是線上的儲存服務，並且在使用SRB之前必須完 成相當龐大的網路元件的設置[ 5]，以個人的使用角度來看，其實並不適合。 3.在分享檔案方面: 不同的網路服務有不同的安全或是分享的機制，也因此造成使用者與朋友之 間分享檔案的困難，有些服務分享的對象也必須具有該服務帳號才可以存取檔 案，所以當使用者做檔案分享時，也只能分享給服務中的會員，無形之中限制了 分享的便利性，另一方面，多數的服務在分享檔案給非會員時大多是使用URL 連結的方式，將URL寄給朋友，朋友再利用此連結存取到使用者所分享的檔案， 此方法雖然可以解決會員機制的問題，但是URL連結的安全性也比較低，任何 人取得此連結都可以存取得到檔案，即使存取URL連結時可再增加一個密碼的安全認證，但對存取者來說，每次存取都必須要記得密碼，無形之中是增加了存 取分享檔案的困難度。 在分享的機制上來說，多數的服務對服務訊息都是被動的通知，例如: 使用 者分享了一張照片給朋友，朋友必須去瀏覽使用者的檔案或是使用者的訊息才知 道有新的照片被分享出來，如此被動的分享機制對社群訊息的即時性來說是大打 折扣。 基於以上所提到問題，我們以使用者個人的檔案服務平台最為目標，在安裝容易
與不耗用龐大資源為前提下提出檔案平台(Unified File Platform)的設計，UFP必
須要具備以下特性與功能: 1. 在使用者介面方面: 平台必須提供一個定義完整且容易整合的使用者程式介面，讓使用者製作 客製化的程式時，不受會侷限於到某個特定介面程式，如此也可提高使用 者程式端的彈性，使用者透過此介面可存取到後端各種不同的儲存服務， 而使用者也不會查覺到服務之間的差異。 2. 整合網路儲存服務方面: 系統要盡可能的將現行與未來服務整合到此平台，在整合服務時，必須考慮 以服務端變動最小的情形下進行整合，平台同時也必須提供基本檔案管理與 操作的功能，例如檔案的刪除，更改檔名，複製，但不包含對檔案即時編輯 之能力，對檔案的編輯應於使用者桌面環境中透過適當的程式進行，而不是 在UFP之中。 3. 在分享檔案方面: 透過平台新的分享機制達到一致性的分享功能，此分享機制必須要能不受 各種不同服務端的認證與分享方式的影響，使用者在分享檔案時也不需要 申請新的帳號或是輸入額外的密碼才可存取，另一方面此分享機制也必須 提供一個即時的分享訊息通知，讓分享訊息能達到即時通知的能力。
四、系統設計
4.1
系統架構
根據以上需求分析，我們計畫將透過以下方法來達到系統所需具備的功能與特 性。 • 使用file virtualization的機制將服務間不同的差異性隱藏起來，讓系統可 以與現存網路儲存服務做整合。 • 使用不同的service adapters與不同服務做溝通，讓儲存服務端在整合時 的變動降到做低，甚至不需服務端的改變便可以整合進UFP中。• 設計一個active sharing with transparent authentication的方法，在使用
者存取不同儲存服務時，不會受到各服務的認證機制所阻擋，同時能夠提 供一個主動式的分享通知功能，讓朋友可以即時接收到使用者所分享檔案 的訊息。 • 在使用者介面部分，可使用XML/HTTP為介面設計檔案相關操作的API， 前端的使用者程式只要能利用HTTP與處理XML，就可與UFP介接。 由上述所使用到的方法，我們設計出UFP系統的基本架構，如下圖 圖 11 UFP基本系統架構圖 Well-defined interface是面對使用者程式的介面，讓使用者透過此介面存取檔
案，File Virtualization Layer主要做file virtualization的部分，同時它也是進行
檔案分享與分享事件發出的主要部分，而Service Adapter則是主要網路服務的
溝通者，負責與不同的服務溝通。
User Application Service Adapter Service Adapter Service Adapter Service Adapter FTP server Local HD
Unified File Platform
Internet
OS File System Integrated FileManagement System (IFMS)
User Application Interface
圖 12 UFP 架構元件圖
系統是由兩大部分組成，分別是Service Adapter, Integrated File management
System (IFMS)，以下針對這兩個元件說明彼此扮演角色與溝通的流程。 Integrated File Management System User Application Service Adapter Service Adapter Gmail Adapter
Internet
Unified File Platform
Gmail FTP Disk C
View.gif Mu.mp3 Slide.ppt
Des.pdf Log.txt
圖 13 UFP基本處理流程
User Application負責與使用者溝通，提供使用者檔案操作的介面，它透過IFMS
Application中，所有的資源都是以檔案的概念呈現，一種服務使用一種資料夾 來表示，資料夾內都是該服務內的資源，當使用者選取該資料夾時，其訊息流程
如下:
1. User Application透過user application interface發送List File命令給
Integrated File Management System (IFMS)。
2. IFMS參考相關內部資料處理邏輯並且選擇一個適當的Service Adapter當成
是與服務端溝通的橋樑，IFMS透過一個定義好的common interface將命令
送給Service Adapter。
3. Service Adapter將List File命令轉換成服務端的指令後透過網路傳送給服務
端，讓服務端執行使用者所期望的List File操作。
當服務端處理完List File命令後便會將resource內容回傳，使用者在User
Application的介面上就會出現該資料夾內的檔案。
4.2
各元件設計
本章介紹UFP內兩個主要元件Integrated File System Management與
Service Adapter的細部設計。
4.2.1 Integrated File Management System (IFMS)
IFMS是UFP中主要處理file virtualization的元件，它對於前端有user
application interface與User Application做溝通，再根據內部邏輯與處理，透過
Service Adapter與儲存服務溝通。
為了要保留User Application介面的彈性，IFMS將使用XML over HTTP
為介面，所有的使用者操作命令都將透過HTTP GET參數格式傳送給IFMS，並
且由IFMS做出對應的檔案操作，最後使用XML格式的文件將結果回傳給前端
User Application，使用XML的好處是資料的分析與轉換相當容易[ 12]，在IFMS
中設計一個HTML的轉換元件，便可將XML轉換成HTML回應給User
Application，如此就可以使用瀏覽器進行檔案操作，更進一步，使用者若是需要
開發客製化User Application，也可透過此HTTP介面與IFMS傳送命令與結果。
使用HTTP作為傳送的傳輸協定主要是HTTP已經廣泛的被一般系統或是
開發環境所支援，對於必須要客製化前端的User Application而言，是較為容易
整合的傳輸協定，另一方面因為IFMS透過網路與前端溝通，User Application
Application不需要在同一台主機上，如此又增加User Application使用上的彈性。
圖 14 User Application介面
對IFMS來說，它必須負責處理所有User Application傳送來的請求，經過
處理後，再選取適當的Service Adapter傳送到服務端進行檔案操作。
Actions
Metadata Storage View.gif photos XML/HTTP Configuration FileIFMS
ServiceAdapter 1 Adapter2Service Adapter3Service User Application
圖 15 IFMS之內部處理流程
由於在IFMS中要處理許多User Application的檔案操作需求，所以必須要
有相對應的元件來處理這些請求，因此我們在IFMS中設計了Action元件來處
理不同的命令，每個Action負責處理單一的命令，從User Application傳送來的
請求必須指定所要操作的檔案命令，命令進入IFMS後交給合適的Action進行
Service Adapter，因此在Action中，我們利用Action Command來區分處理不
同檔案操作的Action元件。
圖 16 Action元件的內部邏輯
同一個Action Command所處理檔案操作的流程是相同的，但Action依照
內部邏輯處理過程當中必須存放Action Data以區分流程中不同的狀態，例如:
在切換目錄時，必須要先從Action Data中取得目前所在的目錄，如此才知道往
上一層目錄切換時必須傳送何種指令給服務，這些Action Data必須依照不同狀
態儲存在Action中，所以同一個Action可能有數個Action Data存在其中，另
一方面，Action在處理過程當中，必須要參考Metadata才能完成虛擬檔案的操
作，這時Action就必須與Metadata storage相互溝通，Metadata storage在IFMS
中負責存放metadata的資料中心。
在UFP中，所有的resource都以檔案呈現，但是在網路上，不是所有的資
源都是以檔案的形式呈現給使用者，很多的網路儲存服務的資源事實上是不能執 行檔案操作命令，因此將網路上的實體資源與系統中虛擬檔案做切割變得十分重
要[ 6]，而在UFP內部就是透過虛擬檔案(Virtual File)的方式將資源虛擬成UFP
中的檔案，Virtual File與真實資源的對應關係都儲存在Metadata當中，每一個
Metadata在UFP中就代表一個虛擬檔案，當使用者所操作的對象為虛擬檔案
時，Action會對儲存在Metadata storage中的Metadata進行操作，如果使用者
要對虛擬資料進行存取時，Action必須先從Metadata storage中取出該虛擬檔
案的真實資訊，再針對真實資源進行存取，因此不是所有的檔案都需要建立
Metadata，只有無法進行檔案操作的資源或分享檔案才需利用Metadata做成虛
擬檔案，所以Metadata storage事實上可以在UFP中提供logic view與physical
File Name Real location Metadata storage Car.gif URL we.gif URL
http://flickr.com/33ERyt
Car.gif Download File IFMS User Application Actions ServiceAdapter 1 Adapter2Service Adapter3Service
Flickr Yahoo
Access URL
圖 17 UFP虛擬檔案與Metadata
當Action要對實際服務資源操作時，必須透過Service Adapter將命令轉換
成服務的命令，但不同的服務需要不同的Service Adapter，Action要如何知道
需要取用哪一種Service Adapter? 從User Application的設計中，我們知道每
一個UI 上的資料夾就是一種服務，不同的服務有不同的資料夾，當使用者點選
某個資料夾時，Action 就知道使用者需要使用哪一種資源，如此 Action 就可以
尋找相對應的 Service Adapter 進行操作即可，由此可知，在UFP 中必須要有
元件紀錄服務與Service Adapter的對應關係，透過這個對應的關係，Action可
以正確的選取Service Adapter，在IFMS中我們使用Configuration File來紀錄
此對應關係，Configuration File是以檔案的形式存在，因為Service Adapter與
服務的關係不會經常變動，比較適合存放於檔案中，另外在選取Service Adapter
時，也必須給予Service Adapter該服務相關認證資訊，因此我們設計也將此資
圖 18 服務與Service Adapter對應關係
4.2.2 Service Adapter
Service Adapter是與服務溝通得主要橋樑，它同時具備以下兩種功能:
1. Protocol Converter
Service Adapter必須要將Action所傳送的命令轉換成服務所能接受的
Protocol[ 11]，例如: 當使用者要檢視在Gmail資料夾中存在哪些檔案時，
Action就會選用Gmail Adapter並且要求列出檔案，Gmail Adapter就必須將
命令轉換成IMAP protocol，透過IMAP對Gmail進行操作，同樣的，如果使
用者點選了FTP資料夾，代表使用者要列出FTP Server中的檔案，所以
Action必須尋找FTP Adapter，同樣要求列出檔案，此時FTP Adapter便會
使用FTP protocol對FTP server進行操作，因此相同的命令到Service
Adapter當中都會被轉換成不同的Protocol或是命令。
IFMS
FTP
IMAP
File I/O
FTP server
Service Adapter1 User Application Service Adapter2 Service Adapter3HTTP
2. Service Transformer
Service Adapter同時也是Service Transform，在Gmail的例子當中，我們
可以將Gmail的郵件服務轉換成可以儲存檔案的資源，當使用者要上載檔案
到Gmail資料夾時，UFP會將檔案變成信件的附加檔，在Gmail中雖然是以
郵件的形式呈現，不過在UFP中則是以檔案的形式存在，當使用者要下載檔
案時，便是將Gamil信件取回，同樣的概念也可以利用在其他的服務，原來
的信件服務透過UFP轉變成儲存的resource，因此Service Adapter也是一
種Service Transform。
為了要做到不同服務必須對應不同的實作方式，但是對上層IFMS又必須
提供統一的介面，讓protocol或是服務的轉換在Service Adapter中完成，
Service Adapter必須提供一個 Common Interface，讓Action對Service
Adapter的命令是一致，此Common interface所定義的動作事實上是一些檔
案操作的命令，各動作的實作則是在Service Adapter中根據不同的服務所
完成，透過這一層的Common interface的包裝，Service Adapter將各服務
異質性隱藏起來，使得上層IFMS甚至User Application都不會感覺到在使
用不同服務內的檔案。
圖 20 Service Adapter與Common Interface
由上面的分析可得知不同的服務需要有不同的Service Adapter，因此要實作
Service Adapter之前必須要先知道有哪些服務需要整合進UFP，我們將目前的
儲存服務分類成以下四大類:
1. Local Storage
與UFP透過硬體所直接連結的儲存裝置，例如:硬碟，USB拇指碟或是其他的連
接裝置，要存取這些儲存服務必須透過作業系統(Operation System) 的介面作
2. Online Storage service with API or standard protocol
在網路上的儲存服務，具有標準protocol或是API介面可供外界存取，使用者
可透過這些介面，開發客製化存取端程式，這類儲存服務如:Cloud storage或是
FTP server，使用者可透過Cloud storage所提供介面或是API對Cloud Storage
中的檔案進行存取，而我們也可以利用FTP protocol對FTP Server內的檔案進
行操作。
3. Online storage service with HTTP and HTML page
在網路上的儲存服務，但是只提供HTTP protocol的存取與HTML網頁的操作，
這類服務主要是設計給瀏覽器使用的儲存服務，使用者可透過瀏覽器進行檔案的
操作與存取，服務本身並沒有提供客製化之介面與API，代表性的服務如:
DropIO, Share1T 等免費的線上儲存空間。
4. Standalone storage device with network access
相較於以上第二與三類服務，這類裝置在網路上扮演的是Client端的角色，它通 常是需求的發出者，而不是服務的提供者，它本身具有網路能力與儲存裝置但卻 沒有提供外界任何的檔案存取介面，這類裝置服務列如: 手機，使用者的筆記型 電腦。 針對這四類需要整合的儲存服務，我們必須實作不同的Service Adapter，透 過標準介面或是作業系統所提供的檔案系統API，我們可以很簡單的實作出第 一，二類服務，針對第三與第四類服務，我們必須設計特別的Adapter或是額外 的元件才能讓這兩類的服務整合進UFP中，以下就針對這兩類服務的Adapter 設計作說明。 • 第三類服務的Adapter 由於此類服務是設計給瀏覽器所使用，因此我們設計在Service Adapter當 中實作一個HTTP Client，讓此HTTP Client模擬瀏覽器存取檔案過程，透過 HTTP Post與Get對檔案進行上載與下傳，若需要對檔案進行刪除，更改檔名
等動作，就必須對Metadata進行操作，而非resource本身，此類Adapter在使
用上還是有所限制，若是有認證圖片、Flash或script所組成的上下傳的服務，
圖 21 第三類服務之Service Adapter
• 第四類服務之Adapter:
此類服務在遠端的裝置上沒有檔案存取服務，因此在設計上我們必須透過一
個在遠端的裝置上的 Agent 代替 UFP 存取資源，我們稱此 Agent 為 IFMS
Agent，它接受UFP之命令存取檔案，IFMS Agent是由UFP所發佈或是從UFP
下載到裝置中，它必須具有以下兩大特性:
1. IFMS Agent必須是一個light weight的程式，它可透過網路發佈或是下載到
遠端的裝置，它不需要繁複的安裝過程或是耗費大量資源就可執行。
2. IFMS Agent 必須具有存取遠端裝置檔案系統的能力，如此在接收 Service
Adapter的命令後，才可以做出相對應的檔案操作。
IFMS Agent在遠端裝置上透過網路與UFP平台建立溝通的環境，讓原本沒有提
供檔案存取服務的裝置也具有檔案服務的能力，IFMS Agent與UFP溝通也是透
過特定之 Service Adapter 進行命令與結果的傳送，讓 UFP 可透過 Service
Adapter與裝置整合，使用此種方法之好處是透過IFMS Agent可將第四類的網
路儲存資源很容易的整合進UFP中，例如:使用者要拿取手機中的相片時，必須
使用傳輸線或是藍芽裝置與手機連線，再透過連線軟體才可取出，其中傳輸線的 準備、藍芽裝置的配對與連線軟體的安裝，對使用者來說是需要經過一番功夫才
能達成，完成這些項目才可存取到手機中的相片，若是使用IFMS Agent，使用
者可用手機連上特定UFP所開放的URL就可下載IFMS Agent，下載後直接安
並且從資料夾中存取到相片。 Service Adapter IFMS Agent
User
Application
download download IFMS AgentIFMS
圖 22 第四類服務與IFMS Agent4.3 UFP
檔案分享機制
在UFP的分享機制中，我們設計在各UFP之間可以彼此分享檔案，在分享 檔案之前，彼此的UFP必須先建立信賴的連線，有了此信賴的關係，才有接下 來的分享機制，在整個機制中，我們必須先定義兩種角色，分別是UFP Client 與 UFP Server。1. UFP Client: 發出檔案請求的UFP系統
2. UFP Server: 接收並處理檔案請求的UFP系統
當使用者公開發佈一個分享的檔案時，系統會將此紀錄存入Metadata
storage當中，當UFP Client想瀏覽UFP Server所分享出來的檔案時，在UFP
圖 23 UFP的分享角色與機制
圖23中的UFP A同時扮演UFP Server與UFP Client的角色，當UFP Client B
要存取A中的分享檔案時，UFP A就扮演UFP Server的角色，當UFP A的使
用者要存取UFP C的檔案時，它就是扮演UFP Client的角色，UFP會將分享檔
案的資訊儲存在Metadata中，但實際的resource還是存在網路上的服務，基於
安全的考量，UFP Client對所分享出來的檔案只具有讀取的權限，UFP Client
不能對分享檔案進行修改或是刪除。
因此到目前為止，Metadata storage中會儲存兩樣虛擬檔案的資訊，一是
virtual files，一是shared files，雖然兩種資訊都存在Metadata storage中，但
使用目的不同，彼此不會互相使用各自資源。
4.3.1
認證問題
由於真實的Resource還存在於網路上的服務中，所以當UFP Client要存
取UFP Server所分享的檔案時，會遇到服務對UFP Client認證的問題，在我們
的設計中，UFP Client存取分享檔案時，是透過信任的連線到UFP Server中，
利用UFP Server將網路上所存放在服務端的Resource取回，再傳送給UFP
Client，在UFP Server端，使用者已經將各服務認證方式紀錄在Configuration
File當中，所以當UFP Client的使用者點選分享檔案時，其存取步驟如下所述:
1. UFP Client之User Application透過XML over HTTP發送命令給IFMS。
2. UFP Client中之IFMS發配命令給Action。
3. Action選擇Service Adapter進行服務存取。
4. Service Adapter透過網路，對UFP Server之IFMS發送命令，IFMS檢查是
否為UFP 所信任Client端。
6. Server端Action 存取Metadata Storage中的分享檔案資料，找出Resource
的真實所在位置。
7. Action再根據真實所在位置到設定檔中找尋所需要服務之Service Adapter。
8. 在取得Service Adapter的同時， Action一並從Configuration File中取出該
服務所需認證資訊。
8. 透過適當的Service Adapter到服務中存取檔案，Adapter存取檔案時也會通
過該服務的認證
9. 取得檔案後，由UFP Server傳遞給UFP Client
10. 再由UFP Client之IFMS傳送給User Application，並且呈現在使用者面前。
UFP
Server
UFP
Client
Actions
Actions
IFMS IFMSP
Service Adapter Gmail AdapterUFP
Client
Actions
IFMS Service Adapter Configuration File 圖 24 分享檔案之存取流程 透過這種存取或是分享機制好處是: 1. 整個存取或是信賴過程當中，在UFP Client端只有一次認證需求，那就是在 建立信連線時的認證，建立信任之後，要取得UFP Server端所分享的檔案時， 皆不需再作額外的認證請求。2. UFP Client端存取UFP Server端所分享服務內的檔案時，不需再申請該服務
的帳號，另一方面，存取的同時，UFP Client也不需察覺到這些檔案是在哪些網
路儲存服務中，存取分享檔案就如同存取本地端檔案一般。
當你的朋友分享一個檔案時，你可以及時得知，並且進行存取，而不是定時 的瀏覽朋友的資訊或是資料夾才會知道他分享了哪些檔案。
要將分享資訊由被動的得知改成主動告知，在分享機制當中必須要有PUSH
的機制存在，事件由UFP Server中的Action觸發，當使用者分享檔案時，負責
處理的Action將此事件透過網路發佈出來，UFP Client之IFMS就會接收到此
資訊，再由接收處理之Action將此訊息Push給User Application。
五、實作與成果展示
5.1
系統實作
系統主要區分為兩大元件，IFMS與Service Adapter，另外在User
Application部分，我們使用Yahoo Widget[ 7]來實作此User Application，會使
用Widget成為使用者端的User Application，其原因可列為以下四點:
1. Widget的UI介面具有高度的客制化能力，從視窗到按鍵都可以自行訂製，透 過客制化的介面開發，能夠讓使用者介面具備完整的檔案操作，另一方面 Widget UI 具有很多特殊的UI效果，可提供滑鼠拖拉操作並且與桌面程式結 合，讓使用者可以更直覺的操作檔案。 2. Widget可停留在使用者桌面，不需要經常開啟或是關閉程式，Widget很適合 顯示及時的資訊，因為它能馬上顯示在使用者的桌面，讓使用者及時接收這些 訊息。 3. Widget是一種輕量級的程式，Widget通常只為特定功能或是目標所開發的程 式，它不需要消耗大量的系統資源，也不需要安裝或是建置太多的元件就能完 成某些工作，很適合當成個人檔案平台的使用者介面程式。
4. Widget的執行是透過widget engine，而通常widget engine有提供大量且多
樣化的API可供開發者開發不同的Widget程式， 透過這些API可以完整建
構使用者對檔案的操作以及其他不同的功能。
UFP系統本身則架構在Tomcat Web application之上，整個系統都使用Java
開發完成。
5.1.1 Widget
與
IFMS
之介面
Widget與IFMS是透過XML over HTTP作命令請求與結果回傳，Widget透過
傳送URL參數的方式指定UI的動作，請求進入IFMS之後，透過Dispatcher
將請求交給對應的Action進行處理，回應結果可分成三大類:
1. 檔案列表回應: 通常使用在取得服務列表或是檔案列表時所回傳的結果，以
Attribute Name Description name 檔案名稱 fstat 檔案種類 1 = 分享的資料夾 2 = 分享的檔案 3 = 未分享的資料夾 4 = 未分享的檔案 表 1 XML資料回傳內容 以下為其範例 <res> <fs-list> <fs name='0990503.rar' fstat='4'/> <fs name='vnc-4_1_2-x86_win32_viewer.exe' fstat='4'/> <fs name='y24022602.rm' fstat='4'/> <fs name='table.xls' fstat='4'/> </fs-list> </res> 2. 狀態回應: IFMS回應所執行的命令結果，其中包含錯誤訊息或是OK 以下為其範例
<res>format is not correct!</res>
3.檔案上下傳: 檔案上下傳回應的結果非XML文件，而是依照HTTP file
upload[ 8]與download的協定進行。
5.1.2 Actions
Action為負責處理User Application請求之邏輯單元，因此我們在實作上將
每種Action都設定為一種Action Class，每個Action Class都繼承MyAction
Interface使得Action都具有execute function，各Action Class的邏輯就實作在
於此function當中，IFMS的dispatch function在產生Action物件後就直接呼叫
每個Action之execute function，而Action Data則剛好為每個Action物件的data
member，不同Action物件可以擁有不同的data member，但所使用的Method
則是相同，Action物件回傳結果為XML文件，Action物件必須將處理結果組成
XML並回傳給User Application，MyAction之介面如下
public interface MyAction {
}
為了完成基本的檔案操作，我們在IFMS中實作了以下Action.
Action Name Description
InitAction 列出起始可使用之服務，從Configuration檔中讀取出
來
AddSrv 增加一個 Trusted UFP到可用服務中，加入後便可瀏
覽該UFP所公開分享的檔案 CdAction 變換目錄 SearchAction 搜尋本地端服務內之檔案 DelAction 刪除檔案 UploadAction 上載檔案 DownloadAction 下載檔案 PirvateAction 將公開分享檔案設定為不公開之狀態 PublicAction 公開分享檔案
RDLAction 從Trusted UFP中取回分享的檔案
RemoteSearchAction 搜尋Trusted UFP中的分享檔案
RemoteListAction 瀏覽Trusted UFP中的分享檔案
NotifyAction 接收Trusted UFP所傳送之event並PUSH給Widget
表 2 UFP中Action動作
5.1.3 Common Interface
Common Interface是存在於Service Adapter與IFMS之間的介面，在實作上我
們將此定義為Java的Interface類別，由於檔案的架構通常是以階層式呈現，因
FileSystem Root jFileObject jFileObject jFileObject SUB Mail C Mail A Mail B IMAP Client 圖 26 Common Interface中的階層架構 FileSystem代表整個檔案系統的介面，負責取得整個檔案目錄架構，包含開啟 關閉整個檔案系統，以及取得該目錄內的檔案物件，其擁有function如下: Function Name
Return value Input parameter Description
close N/A N/A 關閉檔案系統，實作上則是必
須與服務結束連線
getFileList jFileObejct [] String path 取得該目錄內的檔案物件，並
須輸入需要取得的路徑
getRootFile jFileObject N/A 取得第一階層目錄的檔案物件
putFile N/A String filename 上傳檔案，若不能取得
inputStream則使用此Method
putFile N/A InputStream fin,
String name 上傳檔案，若可取得 inputstream則使用此Method findFile List of jFileObject String filename 尋找檔案系統中之特定檔案 表 3 FileSystem介面中的function jFileObject則是代表每個檔案的物件，在經由FileSystem介面取得目錄內的檔
案物件後，IFMS可透過物件上的Method進行物件的操作，其中包含之function
Function Name Return value Input parameter
Description
delete N/A N/A 刪除檔案
rename N/A String
filename
更改檔名
getFileName String
filename
N/A 取得檔案名稱
listFile jFileObject [] N/A 若是該檔案物件為目錄時，取得該
目錄內的檔案物件
getInputStream InputStream N/A 取得InputStream，準備對檔案進
行下載
getOutputStream OutputStream N/A 取得OutputStream，準備對檔案
進行上載
isFolder Boolean N/A 檢驗該檔案物件是否為目錄
getParent jFileObject N/A 取的該檔案物件之上層目錄
表 4 jFileObject介面中的function
5.1.4 Service Adapter
根據設計，Service Adapter必須實作common interface用以完成不同服務
溝通的方法，而不同的服務必須要有不同的Service Adapter做聯繫，在系統中
我們分別實作四種Service Adapter，分別代表四種不同服務類型。
1. Local Storage
我們使用Apache common virtual file system library實作此類Service
Adapter，透過Apache VFS library，我們可以存取到不只是local儲存裝置，還
有FTP內的檔案也可經由VFS存取得到。
2. Online Storage service with API or standard protocol
我們選定Gmail為此類服務之整合目標，Gmial本身為信件服務，但有提供標準
的IMAP介面，要與Gmial溝通必須要使用IMAP Client為實作方法，每次上傳
檔案，即是傳送一封信件並且夾帶所要上傳的檔案，信件的主旨即是該檔放在
Gmial資料夾內的位置與檔名，若要下載檔案或是刪除檔案，在此Gmail Adapter
Widget
IMAP
Subject: /photo/car.gif
UFP
圖 27 Gmail Adapter之實作
其java mail library [ 13]與common interface之主要對應動作如下:
Common Interface Java main library
FileSystem Gmail連線並且尋找INBOX信件資料夾
Close 關閉Gmail信件資料夾 getFileList 在信件資料夾中搜尋以輸入路徑為主題的信件 putFile 將所指定之上傳檔案讀入buffer並且將其附加在信 件中寄出到Gmail。 getFileName 回傳該信件主旨 listFile 搜尋指定主題之信件
getInputStream 取得信件檔案附件之File stream
delete Purge信件
表 5 Java mail 與common interface之對應關係
3. Online storage service with HTTP and HTML page
在此類服務當中，我們選定Anyhub(http://anyhub.net)為此類服務的整合目標，
Anyhub具有簡潔的畫面，沒有flash與圖案認證，相對於Service Adapter的實
作來說會比較方便，與此類服務溝通主要發生在檔案上傳與下載，其他的檔案操
作皆是在Metadata Storage中完成，所以要實作此類服務之Service Adapter，
首先必須先了解服務的溝通message flow。
透過Ethereal等工具，觀察服務與瀏覽器之間的溝通可發現，要上傳檔案
時必須先利用HTTP File Upload到Http://anyhub.net/upload之URL，上傳成功
之後，系統會使用HTML回傳檔案所在之URL，此時UFP便可parsing回傳之
Metadata Storage中。
圖 28 服務之檔案上傳流程
圖 29 從HTML中找出下載資源之URL
當需要下載檔案時，並須先從Metadata Storage中取出該檔之URL，並且利用
HTTP GET請求檔案，此時系統便會依照HTTP File download protocol將檔案
回傳。
圖 30 檔案下載
根據這些觀察結果，我們可以依照此message flow來設計在Adapter中HTTP
4. Standalone storage device with network access
我們選定standalone PC為此類整合目標，在IFMS Agent的實作方面，我
們選擇Java Applet[ 9]實作IFMS Agent，透過遠端PC的瀏覽器存取UFP中特
定的URL下載IFMS Agent applet並安裝在瀏覽器中，在Applet當中必需要有
listen socket，透過此Applet在遠端PC接收Service Adapter所傳送的檔案命
令，我們就可以將這台PC整合進UFP中。
圖 31 Mobile Agent in Applet
使用Applet的好處是，Applet可以經由網路發送或是下載，並且在不同的平台
中只要有JVM就可以執行，雖然Applet本身在Sandbox中並沒有操作檔案與
網路連線能力，但透過Signed Applet的安全控制，Applet本身就可變成遠端的
小程式，完全操控遠端的PC，此時Applet就如同Agent般代替UFP在遠端PC
操作檔案。
5.1.5 Configuration File
設定檔
在UFP系統中，我們必須有Service Adapter與資料夾的對應關係，在實
作上，我們將此檔案設計為一XML格式的檔案，系統必須設定相對應的服務與
Service Adapter於此檔案中，另一方面，也必須將此服務會使用到的認證資訊
紀錄於此，檔案格式如下:
<fsconfig> <fslist>
<fs name=”Folder name in Widget”>service
adapter://security token@service host</fs>
</fslist> </fsconfig>
在security token中，若為user name/password，則使用username:password
圖 32 UFP之設定檔
5.1.6 Widget Notify
實作
在實作Notify的機制時，UFP Client之Notify Action在接收到UFP Server
所發布事件後，會透過HTTP通知User Application，但很多Widget engine為
了提供light weight的Widget程式，Widget engine本身並不提供listening socket
的能力，這使得在實作PUSH機制[ 10]時，我們必須要使用Long Pooling的方
式，其運作方式如下:
User
Application IFMS IFMS
Register Hold request Notify Trigger Trigger Hold request
UFP Client
UFP Server
OK Waiting handler Waiting handler 圖 33 UFP之PUSH流程
1. 在UFP系統啟始時，每個UFP之Widget就必須使用非同步的訊息之Ajax
訊息先對IFMS發出註冊event的請求。
2. IFMS回應註冊成功，此時User Application再發出waiting handler的請
端不須等待回應可繼續處理使用者介面操作。
3. 當遠端UFP Server發佈分享檔案的訊息時，UFP Client的Notify Action
接收到訊息後，會回應一開始的Ajax請求。
4. 請求從IFMS回應後，會觸動Widget中非同步訊息的callback function，
讓event顯示在Widget UI上，使用者就可以立刻接收到訊息。
5. Widget立刻再發出另一個waiting handler之Ajax請求，等待另一個事件
通知。
User Application端的Widget程式與IFMS之間只保持一個long polling的連
線，所有的event皆經由此管道進行對User Application的通知，所以不會
對IFMS系統造成太大的系統負擔。
5.1.7 Message flow
在完成各元件之實作後，各元件之間相互溝通message flow如下:
圖 35 檔案下載之基本流程
Widget Action Metadata
storage UFP client
UI command Execute logic in Action Store metadata Pass metadata return Send event Ack IFMS 圖 36 分享檔案之流程
圖 37 瀏覽分享檔案之流程
5.2
成果展示
在本章中，將展示一些系統操作之過程與畫面。 1. 系統開啟，並且將Widget安裝完成後之畫面如下圖 圖 39 基本Widget畫面 2. 點選”File”便可開啟檔案資料畫面，使用者可根據需求進入不同的資料夾，每 個資料夾就是一種服務，由此圖中可知，本系統目前有FTP、anyhub、Flicker、 Gmail與本地端磁碟五種服務。 圖 40 開啟服務內容之畫面3.點選進資料夾後，可見檔案或是子目錄，在檔案上按左鍵，可選擇瀏覽檔案、 刪除檔案或是設定分享檔案。 圖 41 設定分享檔案或開啟檔案 4.選擇公開分享檔案後，所分享的檔案會以”P”字母代表該檔案已被分享，可被 朋友存取。 圖 42 分享之檔案被標記”P”
5. 在主畫面選取”New”便可新增Trusted UFP server，將朋友的UFP加入，便
可互相分享檔案，輸入朋友系統代號、密碼以及IP address，加入後在檔案瀏覽
圖 43 建立遠端UFP之Trust Server
圖 44 新增朋友UFP後之資料夾
6.透過信賴關係，點選朋友的資料夾便會看到朋友所分享出來的檔案，如下
圖，圖45為UFP Server分享檔案，圖46為UFP Client看到所分享出來的
圖 45 UFP Server分享檔案
圖 46 UFP Client存取分享檔案
7. 當朋友分享檔案時，UFP會即時顯示資訊在Widget上。
圖 47 分享事件通知
48中的MobileDisk即遠端IFMS Agent所在的儲存裝置。
六、系統比較
6.1
功能比較
在本章中我們將UFP與現行整合性檔案系統在User Application
Interface、Web storage service整合與分享功能三方面來比較。
Unified File Platform (UFP)
Storage Resource Broker(SRB)
Cloud Storage XAM
User Application Interface - Customized user application - XML/HTTP - Customized user application - Web - Proprietary client - Customized user application - Customized user application - Binding interface Storage service integration - As many as possible - Need adapter module - Storage system - More effort in building system - Only vendor’s storage - Not free - Storage media - Need vendor support VIM Sharing Function - Between different service - No account needing - Real time event notify -Different storage system -Passive message notification - Share with non-member - Passive message notification - No data sharing mechanism 表 6 UFP功能比照表
• 在User Application Interface方面，幾乎所有的系統有提供API介面，可供
使用者自行開發User Application，也可以整合進其他檔案系統，但少部分系
統，如:XAM，必須透過binding的方式與系統函數連結，無法透過網路存取，
所以User Application也無法遠端存取系統，UFP提供XML/HTTP介面讓使
用者客製化User Application，也可讓使用者由遠端控制UFP平台。
• 在Storage service 整合方面，雲端服務多以自己所提供的儲存空間為主，對
其他儲存服務則無整合能力，SRB與XAM的整合目標則是以儲存設備或是
儲存系統為主而不是儲存服務，另外多數檔案整合系統的服務對象是以企業 用戶或是多人線上服務為主，而非個人用戶，在資源耗用與系統建構上不如
UFP簡便，UFP盡可能的將網路儲存服務整合到UFP中，線上儲存服務型
態多樣，透過Service Adapter將服務整進UFP中，但每一種服務就必須要
開發相對應的Adapter才行。
能夠進行分享，但只有 UFP能做到transparent分享能力，使用者不需知道 分享的檔案是位於分享者的哪個服務內的檔案，也不需額外的認證或是帳號 申請，即可存取到所分享出來的檔案，另一方面，也只有UFP能做到即時的 分享資訊通知。
6.2
效能比較
操作檔案時系統反應時間直接影響使用者對系統的使用意願，在本章中我們將同樣是屬於整合Gmail網路服務的GmailFS[ 16]與UFP做檔案移動的時間效
能比較，GmailFS是架構於FUSE上的userspace filesystem，透過不同大小檔
案的移進與移出系統做出兩者操作上的效能差異比較。
系統平台 : Linux RedHat Enterprise 5, Intel Core 2 Duo P8700 CPU, 1 GB
memory,3M/768 VDSL.，測試檔案分別為1MBytes ~ 5MBytes 之檔案，測試結
果如下圖；
Copy File into System
0 10 20 30 40 50 60 70 80 90 100 1 2 3 4 5
File Size (Mbytes)
T im e ( s e c ) GmailFS UFP 圖 49 檔案上載至Gmail服務 圖49為複製檔案進入系統，對Gmail服務來說為上載檔案到服務當中，由圖中 可知，UFP在檔案上傳至服務所需時間較FUSE為多，但兩者差異不大。
