Delight in Thinking

雲計算本質上不是一種技術，而是一種新的信息處理和傳遞模式。 人們可以從不同的角度來界定雲計算，如從技術支持的角度看，雲計算的一個重要技術支撐是虛擬技術，通過虛擬技術可以實現計算資源的共享，虛擬技術並不是一種新的技術，它的發展可以追溯到計算機技術的初期，尤其是在主機—終端模式下，許多終端可以同時使用同一個主機的計算和存儲資源。 後來發展到客戶端—服務器模式，客戶端有自己的計算能力負責本地處理，而服務器提供數據。 互聯網的出現改變了計算機網絡的模式，尤其是Web的出現，使得客戶端—服務器模式變得更為簡單清晰，形成了瀏覽器—服務器模式。 這個模式可以說是雲計算的雛形。

雲計算是伴隨著互聯網的發展而形成的一種新的計算模式，這個模式的基礎是網絡，之所以用雲計算這個富有浪漫色彩的名字來命名這種計算模式，也完全是源自網絡，人們圖示網絡時往往用雲來表示，當云越畫越多， 圖示應用系統結構時幾乎每次都需要畫上雲來表示互聯網時，雲就被獨立出來，形成一種特定的模式，這個模式就被稱為雲計算模式。

雲計算模式根本上就是一種互聯網模式，在這個模式下，整個互聯網變成了一台超級計算機，人們可以通過這超級計算機來完成大部分計算任務，實現對信息的加工處理和傳遞，這就是雲計算。 當互聯網成為一台超級計算機後，人們的計算模式就完成了一個循環，即回到了原先的計算模式—主機模式，即互聯網的用戶都在使用一台計算機，這是虛擬技術成為了支撐這種計算模式的核心技術。 虛擬技術是一個完整的多層次的體系結構，包括硬件層、平台層、應用系統層等層次，包含了完成一次計算、實現計算機應用的所有組件。 這個體系結構的核心在於如何將各種組件整合起來形成一個完整的獨立的系統。 那麼，什麼是粘合各種組件的粘合劑？ 答案很簡單：服務。

服務成了雲計算的核心，在雲計算模式下，一切皆服務。 基礎設施變成了服務，即iaas；平台變成了服務，即paas；軟件變成了服務，即saas。 如果我們再擴展這樣的理念到一般層面上，那就是xaas。 所以，雲計算的一個基本方程就是：

Cloud computing = XaaS,一切皆服務！

這裡，我們需要對服務做一個解釋，在雲計算模式下，服務有著更為廣泛的含義，它不僅是指系統對用戶提供的服務，而且，在某種意義上說，更重要的是系統與系統之間的服務，即一切皆服務中的服務包括對用戶的服務，也包括對系統的服務，換句話說，既包括對人的服務，也包括對機器的服務。 當我們建立起雲計算一切皆服務這個基本方程後，那麼任何云計算應用就是解這個方程的過程，

我們圖書館的雲計算應用也是解這個方程的過程，如果我們將建立在雲計算模式下的圖書館服務稱之為雲圖書館，那麼，雲圖書館就可以用這個公式來表達：

Cloud library = LaaS，即云圖書館就是圖書館作為一種服務。

在雲計算語境下，圖書館作為一種服務包含了四個方面的含義：

1. 圖書館是基於網絡的信息服務，圖書館應該被畫在應用系統圖示中的雲裡面。 也就是說，圖書館應該成為一朵雲；
2. 圖書館通過網絡為最終用戶提供信息服務，即云圖書館應該是一種網絡存在；
3. 圖書館通過網絡為系統提供信息服務，即云圖書館成為一個大型的存在於網絡的數據庫，其他應用系統可以無逢地整合圖書館信息；
4. 圖書館系統應該可以和其他系統無逢地整合起來，獲取其他資源。

在雲計算環境下，圖書館服務成為一種基於信息和知識的基礎設施，是整個雲計算模式架構中的一個功能層，是一朵無所不在的圖書館雲。

此文獻給正在上海召開的“雲計算與圖書館”會議

技術與人文之間的爭論其實很無聊，因為道理非常明白，不應該有所爭論的。 比如商學研究領域，電子商務的出現受到商學研究的熱烈追捧，沒見什麼人說服務是第一位的而排斥電子商務。 技術的發展延伸了服務，這是不用討論的，電子商務的成功說明了一個非常簡單的道理，那就是在網絡時代，任何服務只能架構在強有力的技術支撐之上。 圖書館服務當然也不可能是例外。 而恰恰很多圖書館界的“聰明人”看不到這些，不知道這是“聰明人”的悲哀還是圖書館界的悲哀。 有些人還振振有詞地打出“圖書館是製度安排”這樣的口號，那我要問，什麼社會機構不是製度安排？ 如果一定要說圖書館是什麼安排，那麼毫無疑問，圖書館是一種技術安排。
有些人可能並不反對技術，內心甚至也認同技術的重要性，他們只是反對“技術救圖”這個說法，他們擔心自己被排斥在技術圈子之外，無法參與轟轟烈烈的救圖事業，這樣的擔心非常可愛，但是沒有必要。 技術救圖不是幾個技術專家的事情，而是全體圖書館員的事情。 廈門大學有個非常了不起的製度創新–“飯糰”。 “飯糰”的起因我不清楚，但是這個“飯糰”集中全館所有熱愛關心圖書館發展的年輕人，不論他們是在什麼崗位，什麼專業背景，IT專家也好，編目專家也好，流通部的圖書館助理也好，都可以參加這個“飯糰”，“飯糰”成為一個跨部門、跨專業，以技術為核心，涉及整個圖書館業務領域的技術創新小組，群策群力一起為圖書館技術的發展添磚加瓦，成為圖書館技術創新的發動機、點子庫，我想，這應該是廈門大學圖書館在技術發展領域走在業界前列的重要原因。 飯糰的機制不僅在廈門大學圖書館有，而且我們也可以在上海圖書館、北京大學圖書館、上海交通大學圖書館等大型圖書館裡看到飯糰的影子，這些圖書館都是技術發展的佼佼者。 飯糰是個偉大的機制創新，在這個機制下，每一個圖書館人都可以投入到圖書館技術創新與發展的洪流中，那是多麼激動人心？ 那些反對技術救圖的人們，為什麼不甩掉包袱，投入到這樣的洪流中去？
技術救圖是全體圖書館員的事情，不只是技術專家們的事情，但是技術專家在技術救圖中毫無疑問地擔當了重要角色。 然而，圖書館技術專家卻被圖書館界輿論邊緣化了，當全世界圖書館技術專家享受著高工資高地位時，我們的技術專家卻被邊緣化，這是不正常的。 記得和“技術救圖”提出者討論提出這個口號的緣由時，他深深地為圖書館技術部門的邊緣化感到擔憂，技術部門集中了大量的優秀人才，擔負著舉足輕重的職責，他們應該得到更多的關注和重視，發揮更大的作用。 我深信他的看法是對的，是為圖書館未來的發展深謀遠慮的。 這也是我不遺餘力地為“技術救圖”搖旗吶喊的原因。
其實，像我這樣的普通圖書館員，無非只能在邊上鼓鼓掌喊喊加油而已，有時喊破了嗓子，被你一句帶套全部抵消。 我能做的無非是做個跳梁小丑駁大家一笑而已，而您卻可以有更大的作為，這是為什麼我突然想給您寫這封信。
程教授，你們這一代圖書館學家是值得尊重的，因為你們的搖旗吶喊和艱苦實踐，我們的圖書館從一個衙門為導向的事務性機構變成了一個服務為導向的社會性機構，這是30多年來，圖書館事業發生的革命性飛躍，您、老槐等等這一代承先啟後的圖書館學家中的佼佼者都是我們崇拜的偶像。 服務的確是圖書館賴以生存並持續發展的基礎，我們深深認同您的服務理念，但是，服務和技術並不矛盾，強調服務並不是要以排斥技術為代價，在現代技術高速發展的今天，服務和技術其實是密不可分的，技術即服務、服務即技術，我們無法分別彼此。 技術的發展總是出乎人的想像，也出乎人的情感，我知道您對書卷有著深深的眷戀，那書香會讓您如痴如醉，但是技術在變化、時代也在變化，我們的新一代用戶眷戀的不再是書卷，讓他們如痴如醉的也不再是書香，而是鼠標的喀喀聲。 我們怎麼辦？ 我們總不能把孔老二用過的竹簡攤在桌上，逼著年輕人讀罷，我們也不能像治療網癮那樣，電擊不讀書的讀者。 我們唯一能做的就是改變我們的服務模式，把我們的服務融入到他們熟悉的環境中去，這就是技術救圖的基本設想。 程教授，您作為一位圖書館學教授和一所大型學術圖書館的館長，應該能夠引起共鳴的。
程教授，您可能看不起技術酒徒，甚至您可能看不起現代技術，但生活在這樣一個技術世界裡，您可能無法迴避技術，既然無法迴避技術，為什麼不為技術鼓掌加油？ 也許您換個角度換個立場，對技術發展貢獻會是巨大的。
技術探索是一個痛苦的過程、寂寞的過程也是承受巨大壓力的過程，技術酒徒不僅需要有聰明才智，更具要有堅強的毅力。 在我心目中，這些堅強的圖書館技術探索者是英雄。 我無法成為他們的一員，但希望能夠為他們鼓掌歡呼，也懇請竹帛齋主加入到我們拉拉隊裡來，我們一起為技術酒徒們加油鼓勁。 好麼？

這個題目很豪華，囊括了目前信息技術領域許多的熱點詞彙，從Web2.0到雲計算，這些鮮亮詞彙構成了一幅Web世界從過去走向未來的線路圖。

網絡世界的生命週期大約是以十年為一個階段，從第一代Web到Web2.0大約經歷了10年左右，這10年中，Web解決了人與網絡的交互問題，即從Web1.0僅僅提供用戶閱讀網絡信息的便利發展到了Web2.0為用戶提供了交互通道，從此，Web 不僅僅是一個媒體，而是一個可以相互溝通的信息交換平台。 在Web2.0環境下，用戶不只是Web的閱讀者，而且也是Web內容的提供者和參與者, 今天，Web2.0基本已經成熟而成為Web的主流。 大量的Web2.0站點充斥網絡，並培育了大量的用戶，可以說，Web2.的興起真正培育了一個虛擬的網絡社會。

W eb2.0的一個主要特徵是參與，即Web用戶可以參與Web的內容建設。 這是一個表層的特徵，在這個特徵背後是技術構架的變遷，Web1.0主要是有網頁構成，而到了Web2.0, 網頁已經不再是Web的基礎，而是應用系統，尤其是被稱之為內容管理系統（CMS）的Web應用系統，Web1.0到Web2.0的發展是從Web Page 到Web Application的發展變遷。

這種技術結構的變遷改變了網絡的基本屬性，Web不再是一個個孤立的站點通過網絡聯繫起來，而是Web應用的各種整合，Web變成了通過功能和內容整合起來的一個整體，變成了一個大系統。 為了實現這樣的整合，需要解決在Web環境下系統之間的相互溝通，尤其是功能和數據的重用問題，因此催生了Web Service架構，這種面向服務的構架成為Web2.0的標誌性架構。 所以，從技術架構角度看，Web2.0的特徵就是Web Service即網絡服務。

W eb作為一個分佈式的大系統，不僅需要開放式的Web Application services(Web應用服務)，還需要被結構化描述的數據。 只有通過結構化描述的數據，才能被應用系統所理解，換言之，一個有效的分佈式的網絡應用系統需要有機器能理解的數據。 如果說Web2.0是建築在開放式的服務構架上，那麼新一代網絡將在此基礎上構建一個機器能理解的結構化的和相互關聯著的數據環境，一旦這個數據環境建立起來，那麼Web將進入一個新時代，這個新的Web環境我們可以稱之為Web3.0。

W eb3.0將要解決的是一個數據的表述，使得機器能夠理解數據的結構信息，這個結構信息被稱之為數據的語義信息，這就是語義網絡需要解決的核心問題，所以語義網可以看成是Web3.0的起點。 語義網經歷了一個從概念到現實的發展過程，其技術架構也越來越清晰，那就是備受關注的關聯數據（Linked Data）。 關聯數據有兩個基本點，那就是描述和連接。 描述和鏈接都是為機器服務的，通過描述可以實現機器自動發現和確認，鏈接可以支持機器自動鏈接。

我們再回過頭來看web1.0，1.0條件下，瀏覽器從服務器那裡獲得信息，直接顯示在屏幕上，並不知道信息的含義，網頁通過超鏈接相互聯結起來，但需要人工點擊觸發， 2.0可以通過機器來自動聚合各種信息，而到了3.0，網絡在數據層就建立了鏈接機制，數據的結構信息被很好地描述著，並通過URI來確保機器能夠自動鏈接各種數據，實現了信息聚合的智能化自動化。

那麼，雲計算不就順理成章了麼？

L inked data可以說是新一代語義互聯網的基礎，具有非常廣泛的應用前景。 不久前W3C宣布，SKOS將全面Linked Data化. (Needle, 2009)這對於圖書館界來說意義深遠。 SKOS的linked data化應該是得益於圖書館界，美國國會圖書館將國會標題表（Library of Congress Subject Headings）全部Linked Data化，成為Linked Data應用的成功範例，推動了Linked Data走向實用。 這又可以說是圖書館界對互聯網的發展做出貢獻的實例。

L inked Data的基礎是RDF和http協議，換言之，Linked Data是通過Http來傳遞RDF數據，而這個RDF數據是一個遵循特殊規則的語義數據，這個規則就是任何資源都用URI來表徵。 所以URI\RDF\HHTP構成了Linked Data 的三個基石。 任何Linked Data 的應用都圍繞著這三個方面展開的。 如：

• 如何構建資源的URI?
• 如何建立RDF 資源？
• 如何利用http 來傳遞RDF?
• 如何接受並解析RDF數據資源？ 等等。

L inked Data的應用有兩種基本模式：一種模式是瀏覽器/服務器模式，即人們通過瀏覽器來訪問Linked Data;另一種模式是客戶端/服務器模式，這裡的客戶端主要是指應用系統，這個模式其實就是系統和系統之間的數據傳遞。 無論何種模式，Linked Data都是通過Http來傳遞的。

H ttp協議其實定義了兩個過程，一個是請求，另一個是響應。 以這兩個過程為藍圖，我們可以模擬一個Linked Data 傳遞過程。

• 客戶端或瀏覽器發送一個RDF文件請求給服務器，要求服務器返回一個RDF文件。 發送這個請求很簡單，你可以直接輸入一個rdf文件後綴，如http://www.cloudlibrary.info/rainzenfoaf.rdf 就是一個簡單的rdf 請求。 當然，這個請求是很弱的，文件用rdf 作後綴不一定就是RDF 格式的文件，反過來，RDF格式的文件的後綴也有可能不是rdf。 所以用文件後綴來傳遞RDF請求不很可靠。 我們需要的是一種強制性的非常明確的RDF 請求方式，這個請求只能通過系統（如瀏覽器）而不是人工來發出。 現在通用的瀏覽器無法發出這樣的請求，為了應用Linked Data我們需要能夠發出RDF 請求的瀏覽器。
• 當服務器接收到一個RDF請求後，需要返回一個RDF文件，並告知客戶端這是一個RDF文件。 這個過程被稱之為content negotiation。 為了實現這個基於RDF 的content negotiation，這就要設定MIMEType, 定義一個RDF類型。 2004年一個關於RDF的content type： Application/RDF+XML被註冊。 對Linked Data 而言，content negotiation是非常重要的，如果要發布Linked Data，需要服務器能夠很好地實現content negotiation。
• 服務器送交一個響應個客戶端，尤其是瀏覽器，那麼如何來解析這個RDF文件？ 特別是在瀏覽器模式下，由於RDF 不是給人看的，而是給機器看的，如何將機器語言翻譯成人能夠讀懂的表達方式？ 這又需要一種特別的瀏覽器來解析RDF。

從這個過程看，應用linked data需要:

• 一個能夠發送RDF請求，並能夠解析RDF的瀏覽器，我們稱之為RDF瀏覽器。 Keven 在其博客中介紹了很多RDF 瀏覽器或插件。 (Wei, 2009)
• 一個服務器能夠返回RDF類型的服務器。 幸運的是，我們常用的Apache開源http服務器:就是為數不多的能夠很好實現content negotiation的服務器。

在利用Apache發布Linked Data時，需要對Apache進行簡單設置，需要增加一個關於RDF的content-type，方法是在Apache的設置中，或在.htaccess中增加一個類型說明： AddType application/rdf+xml rdf 。 這樣Apache接收到RDF的請求時，就可以回送RDF類型消息。

但是，由於application/rdf+xml是新註冊的，有些瀏覽器還不兼容，我發現一個現象，訪問http://www.cloudlibrary.info/rdf/rainzenfoaf.rdf時，通過檢查文件頭的軟件得知，服務器返回了一個application/rdf+xml的文件，但通過Firefox看文件信息，卻被解釋成text/html。 看來firefox的默認content-type是text/html，而不認可application/rdf+xml類型，當接收到這個類型時，起用了默認值。

另一個有趣的現像是，Apache的默認類型是text/plain，如果不設RDF類型時，服務器無法確認RDF文件，從而啟動默認值，把RDF文件當成text/plain。 返還的是文本文件信息，這時在瀏覽器上顯示文本文件。 那麼，是不是必須增加application/rdf+xml這個類型呢？ 其實也是不一定的，上面已經說過，FireFox把application/rdf+xml解釋成text/html， 那麼我們添加一個類型： AddType text/html rdf 也行，或者直接將Apache的默認值設為text/html就行了。 那麼如何解釋回送過來的是text/html信息，而瀏覽器卻能解析成RDF呢？ 看來瀏覽器這端還需要一個判斷，通過分析標記語言來判斷是否是RDF文件。 不過在系統與系統之間的通訊，我以為還是應該啟用application/rdf+xml，這樣更加可靠明確。

本文是和Keven討論過程中形成的，感謝Keven對本文的貢獻。

參考文獻：

Needle, David. 2009. W3C's New SKOS Standard Advances Linked Data. [聯機] 2009年August月18日. [引用日期: 2009年August月27日.] http://www.internetnews.com/dev-news/ article.php/3835176 .

Wei, Liu keven. 2009.關聯數據瀏覽器.數圖研究筆記. [聯機] 2009年August月26日. [引用日期: 2009年August月27日.] http://www.kevenlw.name/archives /1844 .

背景鏈接

http://www.w3.org/Protocols/

http://www.iana.org/assignments/media-types/application/