要深入了解什麼是mashup，就應該了解一下這個單字的起源：它源自於流行音樂，mashup 是從兩首不同的歌曲(通常屬於不同的流派)中混合演唱和樂器的音軌而構成的一首新歌。在Mashup 流派中，我們探索了流行的mashup，
一.簡介
一種新型的基於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 的工作流程管理)產生怎樣影響，這點非常有趣。