通常、EAIは間違いが許されることなくしかも割高で複雑また高度な技術を要する作業であると見られてきた。EAIの基礎理論はインテグレーションがハブとスポーク、またはバスアーキテクチャを使用してバックエンド上で実行されるというものだ。しかし最近 Web 2.0マッシュアップを通したインテグレーションが可能なマッシュアップツールに関するベンダーの声明を多々耳にしている。
"Enterprise Integration Patterns"の著者であるGregor HohpeはEAIの次世代アプローチとなりつつあるマッシュアップのコンセプトに関して考慮していた。
マッシュアップは異なるソースにデータを引き出し集結し他の異なるコンテキストに使用できるようそのデータを変換する。EAIの場合は異なるソースにデータを引き出し集結し他の異なるコンテキストに使用できるようそのデータを変換するのだろうか?GregorはマイスペースやDigg、del.icio.usのような新しいサイトを見てみるとWeb2.0の技術はEAIのイネーブラとなることを指摘している。
また彼らは複数のサイトからシェアードデータを表示するプラットフォームとしてウェブを使用している。このようなマッシュアップはデータを引き出すためにJavaScriptのような軽量のプログラミングモデルを使用してユーザー達に能率良く提供するのだ。例えば、このようなマッシュアップはリストサイトから適当なアパートの情報を引き出しそれらをグーグルマップに表示するようなものだ。Gregorは地図上のイベントロケーションの表示とカレンダーエントリーのAtomフィードをどのように引き出すかを説明するグーグルマッシュアップエディターのチュートリアルを提供した。マッシュアップのキーポイントはそれらが共通のプロトコルを利用しているところだ。Gregorがサンプルアプリケーションに関して説明する。
一方マッシュアップに関する技術とツールは比較的新しいが、現在のデザインパターンにも関連性がある。 Gregorはデータストリームを向上させるためにYahoo Pipesのパイプとフィルターのパターンを使った。このバージョンにおいて場所の経度と緯度を探し出すためにJavaスクリプトは必要ないが代わりにフィードからのコーディネイトがグーグルマップコンポーネントに直接通過するのでこの解決策をより緩く連結させているのだ。しかしながらマッシュアップに頼り切ってはいけない。コンテンツ上の認証と保証のようなインテグレーションの問題は存在し続けるのだ:地球を揺るがすことまででもないがジオコーディング、RSS、Atom、グーグルマップが発明される5年前にこのタイプのアプリケーションを作るには大変長い時間を要しただろう。 標準的なプロトコルと強力なツールの存在はこのタイプのインテグレーションを比較的簡単にさせているのだ。
例えば、トークンとIDマネージメントがマッシュアップはすでにマッシュアップの課題となっている。セマンティックのミスマッチと不適合データフォーマットはデータインテグレーションの掛け橋となっており消えることはほとんどない。
Gregorはマッシュアップソリューションに対する期待は、従来のEAIソリューションのようにわかりやすいものではないという結論を出している。
事業レベルの大規模なインテグレーション統合問題解決策を見出そうとしているのに対してマッシュアップは小規模で高品質な部分的解決策を提供しているのだ。Bill Burnham氏は2004年にWeb2.0とロングテール以前"ローエンド EAI"が注目されるべきであったことを予想している。マッシュアップがEAI2.0になる日が遂に来たのだろうか?