2011年5月15日 星期日

An Architecture for Context-aware Semantic Web Services

This paper appears in: IEEE International Conference
Issue Date : 23-26 Sept. 2008
Date of Current Version : 11 十一月 2008

在此篇PAPER中提出一種新的方法對於情境感知的語意WEB服務適用於任何環境。

在Ubiquitous Provision of Context Aware Web Services,情境感知的服務導向架構 (CA - SOA)的提出,主要使用在無所不在的Web服務發現和存取。

語義 Web服務描述:
情境感知的語義 Web服務需要取存情境訊息。主要常用的2個方法通過情境API和情境訊息透過函式輸入到服務。所有訊息相關的類型所須的情境是一個重要的問題,可以幫助服務的發現,選擇和執行。

架構:
根據用戶類型和應用,情境來源可以不同,此文提出了一個新的架構,使情境感知的語義 Web服務,可用於不同的環境(如無所不在網路)。

它的一個主要特點是獨立性從情境來源。,該體系結構的建立基於三個重要的屬性上描述如下:

情境中最低水平是情境訊息可能提供有關特定用戶和他的環境。利用這一概念意味著我們沒有為整個架構情境來源指定任何嚴格的設置, 因此架構更適應異質環境和用戶。

領域是必要的,原因有二。首先是情境依賴於領域,它可以不同於其他領域;其次,它提高了可伸縮性,其次它提高了可伸縮性,因為當我們專注於一個特定領域的情境模型。我們可以節省記憶體和處理程序。

最後一個是對情境提供的Web服務。 他們是一系列的程序代表了 Web服務,並負責提供情境
。

管理模塊負責處理用戶的請求,並指定情境層級和領域。這些信息可以通過捕獲延長的SOAP標頭,包括用戶的情境層次和領域。

Composer Module 是負責製作一個綜合服務基於可用的 Context Provider Web Services 和context-aware Semantic Web services.

最後,執行模塊和CPService執行模塊是負責執行指定語義Web服務和情境提供服務。

結果應該返回給用戶通過管理模塊。

該原型建議架構的實行,我們採用了composition algorithm和context model [CO4WS]。


結論:
這種架構依賴於三個主要特質,使它適用於異質的環境和用戶。此外,情境感知的語義 Web服務描述新方法的介紹。

2011年4月24日 星期日

[新聞] Amazon機房停擺近一日

Amazon機房停擺近一日 Foursquare等網站遭殃

文/沈經 2011-04-22

Amazon在美國多處有機房以支撐整個雲端服務,照理說僅一處機房故障時,會將工作移轉到其他正常運作的機房。Amazon也因此才敢號稱服務等級為99.95%。此次當機Amazon一方面將必須賠償客戶,亦打擊客戶對其雲端網站服務的信心。

根據Amazon Web Service的服務狀態網頁顯示,美國地區的Amazon雲端服務多個機房服務中斷,影響美國地區數千個網站,包括多個著名網站如Foursquare、Formspring.me、Reddit.com、Netflix、Zynga等。歐洲及亞洲機房則未受影響。

據媒體指出,主要是停電導致此次災難。Amazon的服務狀態網頁顯示,北維吉尼亞的機房在凌晨一點開始出現狀況,連接彈性儲存區塊(EBS,Elastic Block Store)及EC2的錯誤及延遲增高。使用Amazon網站服務的客戶大都採用EBS儲存MySQL資料庫,而大部分的EBS均置於該機房。

隨後該機房一直設法恢復EBS服務,但因重新建立鏡射(Mirror)等各種因素,導致系統無法負荷。一直到八個小時後,EC2雲端服務才陸續得以連結EBS,其客戶網站也陸續開始運作。

Amazon在美國多處有機房以支撐整個雲端服務,照理說僅一處機房故障時,會將工作移轉到其他正常運作的機房。Amazon也因此才敢號稱服務等級為99.95%,這意味一年只會故障262.8分鐘,約4.38小時。

此次當機Amazon一方面將必須賠償客戶,亦打擊客戶對其雲端網站服務的信心。更有媒體與專家指出,這證明企業不能完全依賴雲端服務。(編譯/沈經)

新聞連結:http://www.ithome.com.tw/itadm/article.php?c=67196


前天看到這篇新聞,讓大家討論起雲端強調的可靠度、可用性與安全性的問題,企業能不能完全依賴雲端呢? 許多人根據這次事情抱著不看好雲端的想法。

不過以Amazon如此規模的系統都發生這麼嚴重的事情,更何況是企業內部機房建置的系統,沒這麼多錢、也沒辦法與短時間解決突然其來的風險,還要自行吸收這些錢,充其量就是fire掉IT人員,而交由Amazon至少還可以領到賠償金,也不用花心思去解決這些問題。

2010年12月13日 星期一

Search Engine in Semantic Web (補充)

大部分的搜尋引擊都是跑一些蜘蛛機器人(spider)擷取於網頁程式中找到連至其他網頁的連結──並且儲存所找到的資料。過程中同時包含了將網頁下載並儲存至搜尋引擎擁有者的伺服器中,再經過一些SEO演算法..等等的一些處理動作。

不過搜尋後返回的結果通常都很大量,我們必須不斷點擊下一頁或看起來有相關的頁面去找尋是否是我們所需要的資料。

不過透過semantic web我們可以在HTML裡面嵌入可描述資源的RDF格式,加上各種不同領域的Ontology

我們就可以讓電腦具備一些邏輯、推理..等等的能力,用在搜尋引擊上藉由這些描述關係使關鍵字的搜尋結果更符合使用者所需要的。


比較:

1.資源分享平台需以管理員身分登入才可以進行更新,透過DOM去抓取
語意搜尋引擊則是透過crawler program 自動去收集Internet上的網頁


2.效率來說,當用戶提交關鍵字和對應的關係時,語意搜尋引擊必須去檢索資料庫中的資料建立出一個關係圖出來,且必須再從這個關係圖去切割成更符合、更精確的關係子圖才會提交給資料庫做網頁的索引並返回結果集給使用者,PAPER中有提到關鍵字過多會導致系統出狀況且時間複雜度不低。

專案資源分享平台在資料更新時,除了將資料放進資料庫外會在寫出 fact.rdf 的檔案,以RDF Triple 的關係紀錄抓取到的資料並和 Ontology 透過 Jena 去做推論,過程比較簡單;除了資料更新時如果有大量的資料才會更新比較久。


A Relation-Based Search Engine in Semantic Web
Author : Yufei Li, Yuan Wang, and Xiaotao Huang
Date : Feb. 2007
Source : IEEE