一.簡介
一種新型的基於 Web 的數據集成應用程序正在 Internet 上逐漸興起。通常用術語 mashup表示，它們的流行萌芽於對交互式用戶參與和集成第三方數據的類似於科學怪人方式的重視。我們使用萌芽一詞是有一定原因的;mashup Web 站點的特點就表現為它正在 Web 上扎根發芽，它們利用了從組織邊界之外的數據源獲取的內容和功能。
mashup 這種隱晦的數據集成定義當然不是非常嚴格。要深入了解什麼是 mashup，就應該了解一下這個單詞的起源：它源於流行音樂，mashup 是從兩首不同的歌曲(通常屬於不同的流派)中混合演唱和樂器的音軌而構成的一首新歌。與那些 “bastard pop” 歌曲類似，mashup 也是內容的一種不常見的創新組合(通常都源自於無關的數據源)，這都是人工進行合成的(而不是通過計算機來合成的)。
那麼，mashup 看起來到底是什麼樣子呢?ChicagoCrime.org 的 Web 站點上有非常直觀的例子，它解釋了地圖 mashup到底是什麼。最初廣泛流行起來的 mashup 之一是一個 Web 站點，它將芝加哥警局在線數據庫中的犯罪記錄與 Google Maps 上的地圖復合在一起。用戶可以與 mashup 站點進行交互，例如告訴它在圖形界面上顯示一個包含圖釘的地圖，圖釘展示南加州最近所有入室搶劫案件的詳細信息。這種概念和呈現方式非常簡單，犯罪和地圖數據復合之後提供的可視化的功能非常強大。
在Mashup 流派中，我們探索了流行的 mashup，包括地圖 mashup。簡要介紹了與 mashup 的構建和操作有關的技術前景。技術挑戰和社會挑戰部分分別介紹了影響mashup 的主要技術挑戰和社會挑戰。
二.Mashup類型
在本節中，我們將簡要介紹對出名的 mashup 類型進行的一些調查。
地圖 Mashup
在這個階段的信息技術中，人們搜集大量有關事物和行為的數據，二者都常常具有位置注釋信息。所有這些包含位置數據的不同數據集均可利用地圖通過令人驚奇的圖形化方式呈現出來。mashup 蓬勃發展的一種主要動力就是 Google 公開了自己的 Google Maps API。這仿佛打開了一道大門，讓 Web 開發人員(包括愛好者、修補程序開發人員和其他一些人)可以在地圖中包含所有類型的數據(從原子彈災難到波士頓的 CowParade 奶牛都可以)。為了不落於人後，Microsoft(Virtual Earth)、Yahoo(Yahoo Maps)和 AOL(MapQuest)也很快相繼公開了自己的 API。
視頻和圖象 Mashup
圖像主機和社交網絡站點(例如 Flickr 使用自己的 API 來共享圖像)的興起導致出現了很多有趣的 mashup。由於內容提供者擁有與其保存的圖像相關的元數據(例如誰拍的照片，照片的內容是什麼，在何時何地拍攝的等等)，mashup 的設計者可以將這些照片和其他與元數據相關的信息放到一起。例如，mashup 可以對歌曲或詩詞進行分析，從而將相關照片拼接在一起，或者基於相同的照片元數據(標題、時間戳或其他元數據)顯示社交網絡圖。另外一個例子可能以一個 Web 站點(例如 CNN 之類的新聞站點)作為輸入，並在新聞中通過照片匹配而將照片中的內容以文字的形式呈現出來。
搜索和購物 Mashup
搜索和購物 mashup 在 mashup 這個術語出現之前就已經存在很長時間了。在 Web API 出現之前，有相當多的購物工具，例如 BizRate、PriceGrabber、MySimon 和 Google 的 Froogle，都使用了 B2B 技術或屏幕抓取的方式來累計相關的價格數據。為了促進 mashup 和其他有趣的 Web 應用程序的發展，諸如 eBay 和 Amazon 之類的消費網站已經為通過編程訪問自己的內容而發布了自己的 API。
新聞 Mashup
新聞源(例如紐約時報、BBC 或路透社)已從 2002 年起使用 RSS 和 Atom 之類的聯合技術來發布各個主題的新聞提要。以聯合技術為基礎的 mashup 可以聚集一名用戶的提要，並將其通過 Web 呈現出來，創建個性化的報紙，從而滿足讀者獨特的興趣。Diggdot.us 正是這樣的一個例子，它合並了 Digg.com、Slashdot.org 和 Del.icio.us 上與技術有關的內容。
三.技術挑戰
與其他數據集成領域一樣，mashup 開發也充斥著許多亟待解決的技術挑戰，隨著 mashup 應用程序特性和功能的進一步豐富，這種挑戰也變得更加嚴峻。本節簡單介紹了一些挑戰，其中有些挑戰目前已經能夠解決或緩解，而其他問題依然沒有解決。
數據集成挑戰：語意和數據的品質
品質調查顯示，當今的企業 IT 首要關注的問題就是是企業虛擬組織中的數據集成。(在這種情況中，我們使用了 虛擬組織(virtual organization)這個術語表示很多聯合業務單元的組合，每個業務單元都包含在自己的管理域中。)與很多發現自己忙於集成傳統數據源的企業 IT 管理人員一樣(例如，創建可以反映當前業務狀況的企業儀表板)，mashup 開發人員需要面對類似源自於在異構數據集之間共享語義的挑戰。因此，要了解 mashup 開發人員是如何為此作出准備，只需了解企業 IT 所面臨的集成挑戰。
例如，我們必須設計數據模型之間的轉換系統。在將數據轉換成通用的格式時、在映射不完整時(例如，一個數據源可能有一個模型，其中一個地址類型包含了一個國家字段，而另外一個模型中沒有這個字段)，我們必須進行一些合理的假設。盡管已經面臨這些挑戰，但是 mashup 開發人員可能並不是源數據模型領域的專家，因為這些模型可能是第三方的產品，這些合理的假設可能並不直觀清晰，這更加劇了挑戰的嚴峻性。
除了缺少數據和映射不完整之外，mashup 設計者可能會發現他們希望集成的數據並不適合進行機器自動化處理;這將帶來很多淨化工作。例如，執法逮捕記錄可能不一致：記錄中可能為名字使用了常用的縮寫形式(例如，一條記錄中使用的是“mkt sqr”，另外一條記錄中使用的是“Market Square”)，這使得關於等同性的自動推理變得非常困難，即使采用很好的啟發式規則也很難實現。語義建模技術，例如 RDF，可以幫助簡化對不同數據集之間自動進行推理所面臨的問題，這些數據集是內嵌在數據存儲介質中的。對於傳統的數據源來說，通常需要投入大量人力物力，進行分析和數據淨化工作，然後才能將其用於語義建模技術。
mashup 開發人員可能還必須面對 IT 集成管理人員不需要面對的一些問題，其中一個問題是數據污染。作為應用程序設計的一部分，很多 mashup 都要求公共用戶提供輸入。wiki 應用程序領域的研究表明，這是一把雙刃劍：它可能非常強大，因為可以提供開放的貢獻和最佳的數據革新，但這又會導致不一致、不正確或容易產生誤導的數據項。後者可能會危及數據的可信度，最終降低 mashup 帶來的價值。
mashup 開發人員需要面對的另外一種集成問題是由於獲取數據必須采用屏幕抓取技術而引起的。正如上一節所討論的一樣，分析和獲取工具以及數據模型都需要大量與反向工程相關的工作。在最理想的情況下，可以創建這些工具和模型，但依然存在一個問題：源站點如何呈現自己的內容，這可能會破壞集成過程，並導致 mashup 應用程序出錯。
組件挑戰
盡管 Web 開發的 Ajax 模型可以比傳統的整個頁面刷新技術提供更為豐富而且更加無縫的用戶體驗，但是也帶來了一些難題。作為基礎來說，Ajax 要求將浏覽器的客戶端腳本功能與自己的 DOM 配合使用，實現一種內容交付方法，這完全是由浏覽器設計者所設想的。(可能 Ajax 類似於黑客的特性增加了它的吸引力。)然而，這使基於 Ajax 的應用程序具有相同的浏覽器兼容問題，這些問題從微軟開發 Internet Explorer 以來就一直困擾著 Web 開發人員。例如，AJax 引擎利用了一個 XMLHttpRequst對象來與遠程服務器異步交換數據。在 Internet Explorer 6 中，這個對象是使用 ActiveX 實現的，而不是使用本地 JavaScript 實現的，這要求必須啟用 ActiveX。
更加基本的一個需求是 AJax 要求必須在用戶的浏覽器上啟用 JavaScript。這對於大部分人來說可能是一個合理的假設，但是對於某些特定的用戶，他們的浏覽器或自動化工具可能不支持 Javascript，也可能沒有啟用對 JavaScript 的支持。這種工具有 robot、spider 和 為 Internet 和 Intranet 搜索引擎搜集信息的 Web 爬行榜。如果沒有功能方面的讓步，基於 AJax 的 mashup 應用程序也可能會發現自己失去了部分用戶群，搜索引擎的吸引力也會降低。
使用 JavaScript 來異步更新頁面中的內容還會產生用戶界面的問題。由於內容不再需要鏈接到浏覽器地址欄中的 URL 上，用戶可能無法體驗到正常使用浏覽器的 BACK 按鈕或書簽時的功能。另外，盡管 AJax 可以通過請求增量內容更新來減少延時，但不好的設計可能會對用戶體驗造成負面影響，例如當更新粒度非常小時，所更新的數量和負載會占據所有的可用資源。另外，在加載界面或更新內容時，我們還需要關心如何為用戶提供支持(例如，使用諸如進度條之類的可視化反饋技術)。
與任何分布式交叉領域的應用程序一樣，mashup 開發人員和內容提供者同樣也需要解決一些安全性問題。身份的概念可能會成為一個棘手的主題，傳統 Web 主要是為匿名訪問而構建的。單點登錄是一種令人滿意的特性，但在這方面存在多種彼此競爭的技術(從 Microsoft Passport 到 Liberty Alliance)，因此可能會導致產生雜亂的身份命名空間，我們必須對之進行集成。內容供應商可能會在自己的 API 中采用身份驗證和授權模式(這需要安全身份或安全確認屬性的概念)來強制采用涉及付費訂閱或敏感數據的業務模型。敏感數據也可能要求一定的機密性(即加密)，我們必須要清楚何時將它們與其他資源集成在一起，而不會帶來風險。身份對於審計和法規遵從性來說也非常重要。另外，由於數據集成是在服務器和客戶端同時發生的，因此從用戶到 mashup 服務進行的身份和證書委托也可能會成為一個需求。
四.社會挑戰
除了上一節介紹的技術挑戰之外，隨著 mashup 的進一步普及，也出現了(或即將出現)一些社會問題。
mashup 開發人員需要面對的一個最嚴重的社會問題就是：在知識產權的保護和消費者的私密性與公用化以及信息的自由流動之間達成一種平衡。不知情的內容提供者(屏幕抓取的目標)、提供 API 來幫助數據檢索的內容提供者都可能需要確定其內容是否正在被他人以未獲得自己批准的方式使用。mashup Web 應用程序仍然處於萌芽階段，只是有一些開發愛好者在業余時間編寫 mashup。這些開發人員可能並沒有意識到(或不關心)安全性之類的問題。另外，內容供應者也只是剛剛開始看到為基於機器的內容訪問提供 API 的價值所在，而且還有很多人不認為這是一個核心業務關注點。這一切結合在一起，導致目前的軟件質量低下，因為諸如測試和品質保證等工作的優先級都要低於概念驗證和創新的優先級。為促進軟件開發過程的成熟，社區必須作為一個整體協同工作，制定開放標准和可重用的工具包。
在 mashups 可以從一種炫酷的玩具變成程序的應用程序之前，還需要做大量的工作，形成高度健壯的標准、協議、模型和工具包。為此，主要的軟件開發業界先驅、內容提供者和企業家必須認識到 mashup 的價值，它意味著可行的商業模型。API 提供者需要確定是否對自己的內容收取費用，如果需要收取費用，應該怎樣收費(例如，通過訂閱還是按使用次數收費)。或許他們將提供不同級別的服務品質。有些市場提供者，例如 eBay 或 Amazon，可能會發現免費 API 將提高產品周轉。mashup 開發人員可能要尋求一種基於廣告的創收模型，或者構建有趣的 mashup 應用程序贏得人們的認同。
結束語
mashup 的確是一種相當新穎的 Web 應用程序。源於語義 Web 領域的數據建模技術和松耦合、面向服務、與平台無關的通信協議相結合，最終將提供一種開發可充分利用並整合大量 Web 信息的應用程序所必需的基礎設施。隨著 mashup 應用程序越來越多地被人們所關注，了解它將對某些社會問題(例如公共使用和知識產權保護之間的問題)和其他應用程序領域(跨組織邊界集成數據，例如網格計算和 B2B 的工作流管理)產生怎樣影響，這一點非常有趣。
