由多個源站點無縫合并而成的一個web站點或web應用被稱為“mashup”。它帶給用戶集成體驗:分散在各地的頁面被以一種新奇的重用模式合并、表達出來。
典型mashup的內容通過公共接口或是API取自第三方來獲得。而另一種方式就是通過包含web feeds(比如RSS、Atom)和Javascript(比如google AdSense)來獲得內容。
大家會在以下的地方對mashup有所體驗:eBay、Amazon、Google、Windows Live和Yahoo開發網絡。
二、“物美價廉”的樂高平臺
mashup作為一個建立web應用的新方式，它在單一頁面中合并了來自多個源站點的程序和數據服務。通稱，通過將javascript作為各個源頁面之間的“粘合劑”使這些組件和連接被乖巧地布局在同一個頁面里，這樣并無需昂貴的花費就生產出有價值的“新產品”。
mashup就如一套樂高玩具(比如樂高星戰系列)，把現存的有趣東西粘合在一起。
三、互聯網上的“裸奔”
這里的裸奔并非在光天化日之下的赤裸行為，而是將自己一絲不掛的充分暴露在互聯網中，等待著種種無情的“欺辱”。
下面來看一下可能導致mashup裸奔的原因:
1.束手無措的javascript:在組件包含私有信息或者帶有私有連接時mashup就無法工作了(至少整個頁面已經被forbidden提示搞得丑陋不堪)。javascript提供了一些穿過這些“封鎖”的暗門，但它所依賴的單獨的全局對象卻由于包含頁面和被包含頁面之間的互不信任而被禁止。
2.無衣遮身的DOM:mashup中的DOM對安全來講真是很糟糕，因為每個DOM節點都直接或者間接地鏈接到另一個節點，這導致不能在有效地隱藏DOM的同時充分地調用其全部功能。
3.相對過激的iframe:<iframe>結構隔離了組件是它們之間不能相互攻擊，這中隔離策略對安全很好，但這支雙刃劍也刺破了組件之間的“協作”。而mashup是需要組件協作的。
4.能力有限的ajax:采用XMLHttpRequest調用有限的服務——無法訪問到被包含頁的未開放服務。如果沒有通過服務器的代理就無法mash up。
另外，一些富媒體(rich media)廣告是mashup的。這些ad腳本需要訪問頁面的所有信息，包括cookie和到服務器的授權連接。而當前的瀏覽器設計并沒有關照這個集成層次，安全模式仍然遵守著保護本站安全的原則。
所以mashup需要一個更加細粒度的解決方案。
四、安全的馳騁
想要克服mashup的陋習，結束裸奔生活也非難事。完全的內容隔離是不靈活的，而開放的內容訪問又是沒有安全感的，看來只有進行雙方商定的局部通訊才是安全馳騁的“起跑點”。
JSON出于這個觀點提出了很好的解決方案。采用JSON的模塊技術就能輕松的給你的mashup裝上工作時必要的安全服(不僅防止觸電哦!)。
JSON的作者提議一種新的HTML tag，采用它分割單一頁面為多個模塊。
用法如下:
<module id="NAME" href="URL" style="STYLE" />
module的三個屬性:
1.id:被腳本用來訪問模塊節點;
2.href:定義了腳本文件或者HTML文件的url;
3.style:就是該模塊的風格定義——設置模塊的尺寸和位置。
每個模塊有兩個節點(外部節點、內部節點)。其中外部節點只暴露給外部的文檔，內部節點是模塊的windows對象。在這個模塊中一邊的腳本不能調用另一邊的腳本來訪問或修改另一邊的數據結構和文檔結構。只允許在內部、外部的節點之間進行收/發通訊。
外部節點具有發送方法，可以發送一個JSON字符串給內部節點的腳本。
外部節點還具有接收方法，可以接收來自內部節點的JSON字符串。
內部節點也有同樣的發送和接收功能。
當調用發送方法時，如果對方的接收方法沒有定義，那么拋出一個異常。
這樣的通訊只允許通過相互協來發送和接收。而且通訊內容只能為JSON text，JSON text可以承擔簡單的交換和復雜的數據結構(沒有交換javascript對象時發生的容量泄漏)。
和模塊內部通訊機制類似，每個模塊可與一個頁面進行協作，而頁面也可以使在模塊之間的通訊更為方便。模塊與頁面之間通訊的能力僅僅依靠協作式發送和接收功能。而模塊的來源和頁面是不相關的。
五、啟示:
JSON作者提供了達到一種全新瀏覽器安全模式的起點。web應用開發因此可以“領先于”瀏覽器技術(也許瀏覽器會很快跟上來)。
而這種模塊的作法沒有對javascript進行任何修改，而只是對HTML進行微小改動。
六、參考資源:http://www.json.org/module.html
文章來源于領測軟件測試網 http://www.kjueaiud.com/
