|
級別: 初級 Duane Merrill (duane@duanemerrill.com), 自由作家, Freelance 2006 年 8 月 31 日 Mashup 是一種令人興奮的交互式 Web 應用程序，它利用了從外部數據源檢索到的內容來(lái)創(chuàng )建全新的創(chuàng )新服務(wù)。它們具有第二代 Web 應用程序的特點(diǎn)，也稱(chēng)為 Web 2.0。這篇簡(jiǎn)介性的文章對 mashup 是什么、目前流行的不同種類(lèi)的 mashup 以及 mashup 開(kāi)發(fā)人員用于創(chuàng )建自己的應用程序的支持技術(shù)進(jìn)行了探索。另外，您還將看到 mashup 開(kāi)發(fā)人員面臨的一些新的技術(shù)和社會(huì )挑戰。 簡(jiǎn)介 一種新型的基于 Web 的數據集成應用程序正在 Internet 上逐漸興起。通常用術(shù)語(yǔ) mashup 表示，它們的流行萌芽于對交互式用戶(hù)參與和集成第三方數據的類(lèi)似于科學(xué)怪人方式的重視。我們使用萌芽一詞是有一定原因的；mashup Web 站點(diǎn)的特點(diǎn)就表現為它正在 Web 上扎根發(fā)芽，它們利用了從組織邊界之外的數據源獲取的內容和功能。 mashup 這種隱晦的數據集成定義當然不是非常嚴格。要深入了解什么是 mashup，就應該了解一下這個(gè)單詞的起源：它源于流行音樂(lè )，mashup 是從兩首不同的歌曲（通常屬于不同的流派）中混合演唱和樂(lè )器的音軌而構成的一首新歌。與那些 “bastard pop” 歌曲類(lèi)似，mashup 也是內容的一種不常見(jiàn)的創(chuàng )新組合（通常都源自于無(wú)關(guān)的數據源），這都是人工進(jìn)行合成的（而不是通過(guò)計算機來(lái)合成的）。 那么，mashup 看起來(lái)到底是什么樣子呢？ChicagoCrime.org 的 Web 站點(diǎn)上有非常直觀(guān)的例子，它解釋了地圖 mashup 到底是什么。最初廣泛流行起來(lái)的 mashup 之一是一個(gè) Web 站點(diǎn)，它將芝加哥警局在線(xiàn)數據庫中的犯罪記錄與 Google Maps 上的地圖復合在一起。用戶(hù)可以與 mashup 站點(diǎn)進(jìn)行交互，例如告訴它在圖形界面上顯示一個(gè)包含圖釘的地圖，圖釘展示南加州最近所有入室搶劫案件的詳細信息。這種概念和呈現方式非常簡(jiǎn)單，犯罪和地圖數據復合之后提供的可視化的功能非常強大。 在 Mashup 流派 中，我們探索了流行的 mashup，包括地圖 mashup。相關(guān)技術(shù) 簡(jiǎn)要介紹了與 mashup 的構建和操作有關(guān)的技術(shù)前景。技術(shù)挑戰 和 社會(huì )挑戰 分別介紹了影響 mashup 的主要技術(shù)挑戰和社會(huì )挑戰。 Mashup 類(lèi)型 在本節中，我們將簡(jiǎn)要介紹對出名的 mashup 類(lèi)型進(jìn)行的一些調查。 地圖 mashup 在這個(gè)階段的信息技術(shù)中，人們搜集大量有關(guān)事物和行為的數據，二者都常常具有位置注釋信息。所有這些包含位置數據的不同數據集均可利用地圖通過(guò)令人驚奇的圖形化方式呈現出來(lái)。mashup 蓬勃發(fā)展的一種主要動(dòng)力就是 Google 公開(kāi)了自己的 Google Maps API。這仿佛打開(kāi)了一道大門(mén)，讓 Web 開(kāi)發(fā)人員（包括愛(ài)好者、修補程序開(kāi)發(fā)人員和其他一些人）可以在地圖中包含所有類(lèi)型的數據（從原子彈災難到波士頓的 CowParade 奶牛都可以）。為了不落于人后，Microsoft（Virtual Earth）、Yahoo（Yahoo Maps）和 AOL（MapQuest）也很快相繼公開(kāi)了自己的 API。 視頻和圖像 mashup 圖像主機和社交網(wǎng)絡(luò )站點(diǎn)（例如 Flickr 使用自己的 API 來(lái)共享圖像）的興起導致出現了很多有趣的 mashup。由于內容提供者擁有與其保存的圖像相關(guān)的元數據（例如誰(shuí)拍的照片，照片的內容是什么，在何時(shí)何地拍攝的等等），mashup 的設計者可以將這些照片和其他與元數據相關(guān)的信息放到一起。例如，mashup 可以對歌曲或詩(shī)詞進(jìn)行分析，從而將相關(guān)照片拼接在一起，或者基于相同的照片元數據（標題、時(shí)間戳或其他元數據）顯示社交網(wǎng)絡(luò )圖。另外一個(gè)例子可能以一個(gè) Web 站點(diǎn)（例如 CNN 之類(lèi)的新聞?wù)军c(diǎn)）作為輸入，并在新聞中通過(guò)照片匹配而將照片中的內容以文字的形式呈現出來(lái)。 搜索和購物 mashup 搜索和購物 mashup 在 mashup 這個(gè)術(shù)語(yǔ)出現之前就已經(jīng)存在很長(cháng)時(shí)間了。在 Web API 出現之前，有相當多的購物工具，例如 BizRate、PriceGrabber、MySimon 和 Google 的 Froogle，都使用了 B2B 技術(shù)或屏幕抓取的方式來(lái)累計相關(guān)的價(jià)格數據。為了促進(jìn) mashup 和其他有趣的 Web 應用程序的發(fā)展，諸如 eBay 和 Amazon 之類(lèi)的消費網(wǎng)站已經(jīng)為通過(guò)編程訪(fǎng)問(wèn)自己的內容而發(fā)布了自己的 API。 新聞 mashup 新聞源（例如紐約時(shí)報、BBC 或路透社）已從 2002 年起使用 RSS 和 Atom 之類(lèi)的聯(lián)合技術(shù)來(lái)發(fā)布各個(gè)主題的新聞提要。以聯(lián)合技術(shù)為基礎的 mashup 可以聚集一名用戶(hù)的提要，并將其通過(guò) Web 呈現出來(lái)，創(chuàng )建個(gè)性化的報紙，從而滿(mǎn)足讀者獨特的興趣。Diggdot.us 正是這樣的一個(gè)例子，它合并了 Digg.com、Slashdot.org 和 Del.icio.us 上與技術(shù)有關(guān)的內容。
相關(guān)技術(shù) 本節概要介紹了可以促進(jìn) mashup 發(fā)展的技術(shù)。有關(guān)這些技術(shù)的更多信息，請參閱本文最后的 參考資料。 架構 mashup 程序從架構上是由 3 個(gè)不同的部分組成的，它們在邏輯上和物理上都是相互脫離的（可能由網(wǎng)絡(luò )和組織邊界分隔）：API/內容提供者、mashup 站點(diǎn)和客戶(hù)機的 Web 瀏覽器。
Ajax 關(guān)于 Ajax 究竟是否是一個(gè)縮寫(xiě)詞（有人認為它表示 “Asynchronous JavaScript + XML”）還存在爭論。不論如何，Ajax 都是一個(gè) Web 應用模型，而不是一種特定的技術(shù)。它包括幾種關(guān)注內容的異步加載和呈現的技術(shù)：
將這些技術(shù)結合在一起使用時(shí)，它們的目標是通過(guò)與內容服務(wù)器交換少量的數據為用戶(hù)創(chuàng )造平滑、良好的 Web 體驗，而不用在用戶(hù)執行某些操作之后重新加載并重新呈現整個(gè)頁(yè)面。我們可以使用各種 Ajax 工具包和庫（例如 Sajax 或 Zimbra）為 mashup 構建 Ajax 引擎，這通常是使用 JavaScript 實(shí)現的。Google Maps API 包括一個(gè)專(zhuān)用的 Ajax 引擎，它對用戶(hù)體驗的影響著(zhù)實(shí)強大：它的工作方式類(lèi)似于一個(gè)真正的本地應用程序，其中沒(méi)有滾動(dòng)條可以操作，也沒(méi)有移動(dòng)按鈕強制頁(yè)面重新加載。 Web 協(xié)議：SOAP 和 REST SOAP 和 REST 都是與遠程服務(wù)進(jìn)行通信所使用的與平臺無(wú)關(guān)的協(xié)議。作為面向服務(wù)的架構范式的一部分，客戶(hù)機使用 SOAP 和 REST 與遠程服務(wù)進(jìn)行交互，而不用了解它們底層的平臺實(shí)現：服務(wù)的功能完全是由它請求和收到的顯影消息描述來(lái)實(shí)現的。 SOAP 是 Web 服務(wù)范式中的一種基本技術(shù)。最初它是 Simple Object Access Protocol 的縮寫(xiě)，現在代表 Services-Oriented Access Protocol（或直接縮寫(xiě)為 SOAP），這是因為它的重點(diǎn)已經(jīng)從基于對象的系統轉向消息交換的交互操作。SOAP 規范中有兩個(gè)關(guān)鍵組件。第一個(gè)組件是使用 XML 消息格式進(jìn)行平臺無(wú)關(guān)的編碼，第二個(gè)組件消息結構，包括消息頭和消息體。消息頭用來(lái)交換非特定于應用負載（消息體）的相關(guān)信息，例如認證信息。SOAP 消息體封裝了應用程序特有的負載。Web 服務(wù)的 SOAP API 是由 WSDL 文檔來(lái)描述的，它們本身都描述了一個(gè)服務(wù)對外提供哪些操作，它可以接受的消息格式（使用 XML Schema），以及如何對其進(jìn)行尋址。SOAP 消息通常都是通過(guò) HTTP 協(xié)議傳送的，不過(guò)也可以通過(guò)其他方式傳送（例如 JMS 或 e-mail）。 REST 是 Representational State Transfer 的縮寫(xiě)，這是一種只使用 HTTP 和 XML 進(jìn)行基于 Web 通信的技術(shù)。它的簡(jiǎn)單性和缺少?lài)栏衽渲梦募奶匦允顾c SOAP 很好地隔離開(kāi)來(lái)，并且吸引了大家廣泛的興趣。與我們在現代變成語(yǔ)言中可以找到的典型基于動(dòng)詞的接口不同（它們構成了各種方法，例如 屏幕抓取 正如前面介紹的一樣，缺乏內容提供者提供的 API 通常會(huì )強制要求 mashup 開(kāi)發(fā)人員采取屏幕抓取的方式來(lái)提取自己希望集成的信息。抓?。⊿craping） 是使用軟件工具處理并分析最初為人們閱讀而編寫(xiě)的內容，從而從中提取出可以通過(guò)編程進(jìn)行使用和操作的信息的語(yǔ)義數據結構表示。有些 mashup 使用屏幕抓取技術(shù)來(lái)獲取數據，特別是從公用領(lǐng)域提取數據。例如，房地產(chǎn)地圖 mashup 就可以在制圖供應商提供的地圖上顯示售價(jià)和租價(jià)，這些數據可能是從當地的記錄辦公室抓取來(lái)的 “comp” 數據。另外一個(gè)抓取數據的 mashup 項目是 XMLTV，這是一組匯聚了各地電視節目清單的工具集。 屏幕抓取通常被認為是一個(gè)不雅的解決方案，這是有一定的原因的。它有兩個(gè)主要的固有缺點(diǎn)。第一個(gè)缺點(diǎn)在于，與使用接口的 API 不同，抓取在內容提供者和內容消費者之間沒(méi)有明確的聯(lián)系。抓取者必須圍繞一個(gè)源內容模型設計自己的工具，并且希望提供者一直采用這種模型來(lái)呈現內容。Web 站點(diǎn)傾向于周期性地更新外觀(guān)，以保持新穎和時(shí)髦，對于抓取者來(lái)說(shuō)，這是一項非常頭痛的維護任務(wù)，因為工具很可能會(huì )失效。 第二個(gè)問(wèn)題是缺少成熟的可重用屏幕抓取工具包軟件，通俗地說(shuō)就稱(chēng)為 scrAPI。此類(lèi) API 和工具包的消亡很大程度上是由于每種抓取工具都有極為特定于應用程序的需求。這為開(kāi)發(fā)人員帶來(lái)了過(guò)多的開(kāi)發(fā)工作，他們必須對內容進(jìn)行反向工程處理、開(kāi)發(fā)數據模型、分析并從提供者站點(diǎn)上匯集原始數據。 語(yǔ)義 Web 和 RDF 屏幕抓取不好的一面直接源自于一個(gè)事實(shí)：為閱讀而創(chuàng )建的內容并不太適合機器自動(dòng)處理。這促進(jìn)了語(yǔ)義 Web 的誕生，它是現有 Web 的增強版本，在為人們設計的內容中增加了足夠多的可供機器閱讀的信息。在語(yǔ)義 Web 環(huán)境中，信息這個(gè)術(shù)語(yǔ)與數據有所差異；數據只有在傳達了自己的含義（即數據可被理解）之后才會(huì )變成信息。語(yǔ)義 Web 的目標是創(chuàng )建 Web 基礎設施，使用元數據對數據進(jìn)行增強，從而使數據變得有意義，最終使數據變得適合進(jìn)行自動(dòng)化、集成、推理和重用。 被稱(chēng)為資源描述框架（RDF）的 W3C 系列規范就是服務(wù)于這個(gè)目的的技術(shù)，它用來(lái)建立描述數據的語(yǔ)義結構。XML 本身并不足以實(shí)現這種功能；它太過(guò)隨意，我們可以使用很多方法進(jìn)行編碼來(lái)對相同的數據進(jìn)行描述。RDF-Schema 補充了 RDF 的能力，提供了以機器可讀的方式編碼概念的功能。一旦可通過(guò)一種數據模型描述數據對象，RDF 就提供了通過(guò)主語(yǔ)－謂語(yǔ)－對象三元組（主語(yǔ) S 與對象 O 具有關(guān)系 R）在數據對象之間構建關(guān)系的能力。數據模型與關(guān)系圖之間的區別讓我們可以進(jìn)行存在式的構建，這是可以進(jìn)行搜索和形式化推理的知識的層次化結構。例如，我們可以定義這樣一個(gè)模型：“肉食動(dòng)物” 是 “動(dòng)物” 的一個(gè)子類(lèi)，條件是它 “吃” 其他 “動(dòng)物”；并創(chuàng )建兩個(gè)實(shí)例：一個(gè)實(shí)例是印度豹和北極熊，并提供它們的生存環(huán)境；另外一個(gè)是瞪羚和企鵝，并提供它們的生存環(huán)境。假設我們將這些單獨的模型實(shí)例集成在一起，就可以推論說(shuō)印度豹可能會(huì )以瞪羚為食，但卻不會(huì )吃企鵝。 RDF 數據在很多領(lǐng)域中都迅速得到了應用，包括社交網(wǎng)絡(luò )應用程序（例如 FOAF —— Friend of a Friend）和聯(lián)合（例如 RSS，接下來(lái)就會(huì )介紹）。另外，RDF 軟件技術(shù)和組件都正在成熟到一定規模，尤其是在 RDF 查詢(xún)語(yǔ)言（例如 RDQL 和 SPARQL）、編程框架和推理引擎（例如 Jena 和 Redland）領(lǐng)域。 RSS 和 ATOM RSS 是一系列基于 XML 的聯(lián)合格式。在這種情況中，聯(lián)合（syndication）是指一個(gè)發(fā)布內容的 Web 站點(diǎn)可以創(chuàng )建 RSS 文檔并在 RSS 發(fā)布系統中注冊自己的文檔。支持 RSS 的客戶(hù)機可以查看新內容，并通過(guò)適當的方式連接到這些內容上。RSS 已經(jīng)被用來(lái)聯(lián)合廣泛的內容，從新聞到頭條、CVS 或 WIKI 頁(yè)面的修改日志、項目更新甚至諸如無(wú)線(xiàn)電節目之類(lèi)的視聽(tīng)數據。版本 1.0 基于 RDF，但最新的 2.0 版本不以 RDF 為基礎。 Atom 是一種更新但非常類(lèi)似的聯(lián)合協(xié)議。它是 Internet Engineering Task Force（IETF）提出的一項草案標準，人們希望通過(guò) Atom 提供比 RSS 更好的元數據維護；提供更好、更為全面的文檔，并結合構建通用數據表示的概念。 這些聯(lián)合技術(shù)對于集成基于事件或更新驅動(dòng)內容的 mashup 來(lái)說(shuō)都非常有用，例如新聞和 weblog 聚集程序。
技術(shù)挑戰 與其他數據集成領(lǐng)域一樣，mashup 開(kāi)發(fā)也充斥著(zhù)許多亟待解決的技術(shù)挑戰，隨著(zhù) mashup 應用程序特性和功能的進(jìn)一步豐富，這種挑戰也變得更加嚴峻。本節簡(jiǎn)單介紹了一些挑戰，其中有些挑戰目前已經(jīng)能夠解決或緩解，而其他問(wèn)題依然沒(méi)有解決。 數據集成挑戰：語(yǔ)義和數據的品質(zhì) 品質(zhì)調查顯示，當今的企業(yè) IT 首要關(guān)注的問(wèn)題就是是企業(yè)虛擬組織中的數據集成。（在這種情況中，我們使用了 虛擬組織（virtual organization） 這個(gè)術(shù)語(yǔ)表示很多聯(lián)合業(yè)務(wù)單元的組合，每個(gè)業(yè)務(wù)單元都包含在自己的管理域中。）與很多發(fā)現自己忙于集成傳統數據源的企業(yè) IT 管理人員一樣（例如，創(chuàng )建可以反映當前業(yè)務(wù)狀況的企業(yè)儀表板），mashup 開(kāi)發(fā)人員需要面對類(lèi)似源自于在異構數據集之間共享語(yǔ)義的挑戰。因此，要了解 mashup 開(kāi)發(fā)人員是如何為此作出準備，只需了解企業(yè) IT 所面臨的集成挑戰。 例如，我們必須設計數據模型之間的轉換系統。在將數據轉換成通用的格式時(shí)、在映射不完整時(shí)（例如，一個(gè)數據源可能有一個(gè)模型，其中一個(gè)地址類(lèi)型包含了一個(gè)國家字段，而另外一個(gè)模型中沒(méi)有這個(gè)字段），我們必須進(jìn)行一些合理的假設。盡管已經(jīng)面臨這些挑戰，但是 mashup 開(kāi)發(fā)人員可能并不是源數據模型領(lǐng)域的專(zhuān)家，因為這些模型可能是第三方的產(chǎn)品，這些合理的假設可能并不直觀(guān)清晰，這更加劇了挑戰的嚴峻性。 除了缺少數據和映射不完整之外，mashup 設計者可能會(huì )發(fā)現他們希望集成的數據并不適合進(jìn)行機器自動(dòng)化處理；這將帶來(lái)很多凈化工作。例如，執法逮捕記錄可能不一致：記錄中可能為名字使用了常用的縮寫(xiě)形式（例如，一條記錄中使用的是“mkt sqr”，另外一條記錄中使用的是“Market Square”），這使得關(guān)于等同性的自動(dòng)推理變得非常困難，即使采用很好的啟發(fā)式規則也很難實(shí)現。語(yǔ)義建模技術(shù)，例如 RDF，可以幫助簡(jiǎn)化對不同數據集之間自動(dòng)進(jìn)行推理所面臨的問(wèn)題，這些數據集是內嵌在數據存儲介質(zhì)中的。對于傳統的數據源來(lái)說(shuō)，通常需要投入大量人力物力，進(jìn)行分析和數據凈化工作，然后才能將其用于語(yǔ)義建模技術(shù)。 mashup 開(kāi)發(fā)人員可能還必須面對 IT 集成管理人員不需要面對的一些問(wèn)題，其中一個(gè)問(wèn)題是數據污染。作為應用程序設計的一部分，很多 mashup 都要求公共用戶(hù)提供輸入。wiki 應用程序領(lǐng)域的研究表明，這是一把雙刃劍：它可能非常強大，因為可以提供開(kāi)放的貢獻和最佳的數據革新，但這又會(huì )導致不一致、不正確或容易產(chǎn)生誤導的數據項。后者可能會(huì )危及數據的可信度，最終降低 mashup 帶來(lái)的價(jià)值。 mashup 開(kāi)發(fā)人員需要面對的另外一種集成問(wèn)題是由于獲取數據必須采用屏幕抓取技術(shù)而引起的。正如上一節所討論的一樣，分析和獲取工具以及數據模型都需要大量與反向工程相關(guān)的工作。在最理想的情況下，可以創(chuàng )建這些工具和模型，但依然存在一個(gè)問(wèn)題：源站點(diǎn)如何呈現自己的內容，這可能會(huì )破壞集成過(guò)程，并導致 mashup 應用程序出錯。 組件挑戰 盡管 Web 開(kāi)發(fā)的 Ajax 模型可以比傳統的整個(gè)頁(yè)面刷新技術(shù)提供更為豐富而且更加無(wú)縫的用戶(hù)體驗，但是也帶來(lái)了一些難題。作為基礎來(lái)說(shuō)，Ajax 要求將瀏覽器的客戶(hù)端腳本功能與自己的 DOM 配合使用，實(shí)現一種內容交付方法，這完全是由瀏覽器設計者所設想的。（可能 Ajax 類(lèi)似于黑客的特性增加了它的吸引力。）然而，這使基于 Ajax 的應用程序具有相同的瀏覽器兼容問(wèn)題，這些問(wèn)題從微軟開(kāi)發(fā) Internet Explorer 以來(lái)就一直困擾著(zhù) Web 開(kāi)發(fā)人員。例如，Ajax 引擎利用了一個(gè) 更加基本的一個(gè)需求是 Ajax 要求必須在用戶(hù)的瀏覽器上啟用 JavaScript。這對于大部分人來(lái)說(shuō)可能是一個(gè)合理的假設，但是對于某些特定的用戶(hù)，他們的瀏覽器或自動(dòng)化工具可能不支持 JavaScript，也可能沒(méi)有啟用對 JavaScript 的支持。這種工具有 robot、spider 和 為 Internet 和 Intranet 搜索引擎搜集信息的 Web 爬行榜。如果沒(méi)有功能方面的讓步，基于 Ajax 的 mashup 應用程序也可能會(huì )發(fā)現自己失去了部分用戶(hù)群，搜索引擎的吸引力也會(huì )降低。 使用 JavaScript 來(lái)異步更新頁(yè)面中的內容還會(huì )產(chǎn)生用戶(hù)界面的問(wèn)題。由于內容不再需要鏈接到瀏覽器地址欄中的 URL 上，用戶(hù)可能無(wú)法體驗到正常使用瀏覽器的 BACK 按鈕或書(shū)簽時(shí)的功能。另外，盡管 Ajax 可以通過(guò)請求增量?jì)热莞聛?lái)減少延時(shí)，但不好的設計可能會(huì )對用戶(hù)體驗造成負面影響，例如當更新粒度非常小時(shí)，所更新的數量和負載會(huì )占據所有的可用資源。另外，在加載界面或更新內容時(shí)，我們還需要關(guān)心如何為用戶(hù)提供支持（例如，使用諸如進(jìn)度條之類(lèi)的可視化反饋技術(shù)）。 與任何分布式交叉領(lǐng)域的應用程序一樣，mashup 開(kāi)發(fā)人員和內容提供者同樣也需要解決一些安全性問(wèn)題。身份的概念可能會(huì )成為一個(gè)棘手的主題，傳統 Web 主要是為匿名訪(fǎng)問(wèn)而構建的。單點(diǎn)登錄是一種令人滿(mǎn)意的特性，但在這方面存在多種彼此競爭的技術(shù)（從 Microsoft Passport 到 Liberty Alliance），因此可能會(huì )導致產(chǎn)生雜亂的身份命名空間，我們必須對之進(jìn)行集成。內容供應商可能會(huì )在自己的 API 中采用身份驗證和授權模式（這需要安全身份或安全確認屬性的概念）來(lái)強制采用涉及付費訂閱或敏感數據的業(yè)務(wù)模型。敏感數據也可能要求一定的機密性（即加密），我們必須要清楚何時(shí)將它們與其他資源集成在一起，而不會(huì )帶來(lái)風(fēng)險。身份對于審計和法規遵從性來(lái)說(shuō)也非常重要。另外，由于數據集成是在服務(wù)器和客戶(hù)端同時(shí)發(fā)生的，因此從用戶(hù)到 mashup 服務(wù)進(jìn)行的身份和證書(shū)委托也可能會(huì )成為一個(gè)需求。
社會(huì )挑戰 除了上一節介紹的技術(shù)挑戰之外，隨著(zhù) mashup 的進(jìn)一步普及，也出現了（或即將出現）一些社會(huì )問(wèn)題。 mashup 開(kāi)發(fā)人員需要面對的一個(gè)最嚴重的社會(huì )問(wèn)題就是：在知識產(chǎn)權的保護和消費者的私密性與公用化以及信息的自由流動(dòng)之間達成一種平衡。不知情的內容提供者（屏幕抓取的目標）、提供 API 來(lái)幫助數據檢索的內容提供者都可能需要確定其內容是否正在被他人以未獲得自己批準的方式使用。有關(guān) Web 聚合和規則的介紹，請參見(jiàn) 參考資料。 mashup Web 應用程序仍然處于萌芽階段，只是有一些開(kāi)發(fā)愛(ài)好者在業(yè)余時(shí)間編寫(xiě) mashup。這些開(kāi)發(fā)人員可能并沒(méi)有意識到（或不關(guān)心）安全性之類(lèi)的問(wèn)題。另外，內容供應者也只是剛剛開(kāi)始看到為基于機器的內容訪(fǎng)問(wèn)提供 API 的價(jià)值所在，而且還有很多人不認為這是一個(gè)核心業(yè)務(wù)關(guān)注點(diǎn)。這一切結合在一起，導致目前的軟件質(zhì)量低下，因為諸如測試和品質(zhì)保證等工作的優(yōu)先級都要低于概念驗證和創(chuàng )新的優(yōu)先級。為促進(jìn)軟件開(kāi)發(fā)過(guò)程的成熟，社區必須作為一個(gè)整體協(xié)同工作，制定開(kāi)放標準和可重用的工具包。 在 mashups 可以從一種炫酷的玩具變成程序的應用程序之前，還需要做大量的工作，形成高度健壯的標準、協(xié)議、模型和工具包。為此，主要的軟件開(kāi)發(fā)業(yè)界先驅、內容提供者和企業(yè)家必須認識到 mashup 的價(jià)值，它意味著(zhù)可行的商業(yè)模型。API 提供者需要確定是否對自己的內容收取費用，如果需要收取費用，應該怎樣收費（例如，通過(guò)訂閱還是按使用次數收費）?；蛟S他們將提供不同級別的服務(wù)品質(zhì)。有些市場(chǎng)提供者，例如 eBay 或 Amazon，可能會(huì )發(fā)現免費 API 將提高產(chǎn)品周轉。mashup 開(kāi)發(fā)人員可能要尋求一種基于廣告的創(chuàng )收模型，或者構建有趣的 mashup 應用程序贏(yíng)得人們的認同。
結束語(yǔ) mashup 的確是一種相當新穎的 Web 應用程序。源于語(yǔ)義 Web 領(lǐng)域的數據建模技術(shù)和松耦合、面向服務(wù)、與平臺無(wú)關(guān)的通信協(xié)議相結合，最終將提供一種開(kāi)發(fā)可充分利用并整合大量 Web 信息的應用程序所必需的基礎設施。隨著(zhù) mashup 應用程序越來(lái)越多地被人們所關(guān)注，了解它將對某些社會(huì )問(wèn)題（例如公共使用和知識產(chǎn)權保護之間的問(wèn)題）和其他應用程序領(lǐng)域（跨組織邊界集成數據，例如網(wǎng)格計算和 B2B 的工作流管理）產(chǎn)生怎樣影響，這一點(diǎn)非常有趣。 要深入了解 mashup 的開(kāi)發(fā)，請關(guān)注 developerWorks 的系列新教程，它將教您構建自己的 mashup。實(shí)際上，這個(gè)系列的文章還會(huì )向您介紹語(yǔ)義 Web 技術(shù)和使其他人創(chuàng )建自己的 mashup 的現有技術(shù)。 參考資料 學(xué)習
獲得產(chǎn)品和技術(shù)
討論
關(guān)于作者
|
||||||||||||||||||||||
聯(lián)系客服
