在UFP的分享機制中，我們設計在各UFP之間可以彼此分享檔案，在分享 檔案之前，彼此的UFP必須先建立信賴的連線，有了此信賴的關係，才有接下 來的分享機制，在整個機制中，我們必須先定義兩種角色，分別是UFP Client 與 UFP Server。
1. UFP Client: 發出檔案請求的UFP系統
2. UFP Server: 接收並處理檔案請求的UFP系統
當使用者公開發佈一個分享的檔案時，系統會將此紀錄存入Metadata storage當中，當UFP Client想瀏覽UFP Server所分享出來的檔案時，在UFP Server中的Action會到Metadata storage中取出使用者所分享出來的檔案。
圖 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端。
5. UFP Server接受後，再交由Server端Action處理。
6. Server端Action 存取Metadata Storage中的分享檔案資料，找出Resource 的真實所在位置。
7. Action再根據真實所在位置到設定檔中找尋所需要服務之Service Adapter。
8. 在取得Service Adapter的同時， Action一並從Configuration File中取出該 服務所需認證資訊。
8. 透過適當的Service Adapter到服務中存取檔案，Adapter存取檔案時也會通 過該服務的認證
的帳號，另一方面，存取的同時，UFP Client也不需察覺到這些檔案是在哪些網 路儲存服務中，存取分享檔案就如同存取本地端檔案一般。
4.3.2 即時的檔案分享資訊
當你的朋友分享一個檔案時，你可以及時得知，並且進行存取，而不是定時 的瀏覽朋友的資訊或是資料夾才會知道他分享了哪些檔案。
要將分享資訊由被動的得知改成主動告知，在分享機制當中必須要有PUSH 的機制存在，事件由UFP Server中的Action觸發，當使用者分享檔案時，負責
處理的Action將此事件透過網路發佈出來，UFP Client之IFMS就會接收到此
資訊，再由接收處理之Action將此訊息Push給User Application。
圖 25 主動分享訊息之發佈