探秘雲端應用集成平臺

基於雲的資料整合在很多是由是有效的。 但是基於雲的應用集成(基於雲的EAI)就有點新品上市的意味了。

像SnapLogic和Boomi這樣的廠商協助我們殺進基於雲的資料整合領域，像Informatica這樣的重量級選手則協助其成為主流技術。

第一個基於雲的應用集成平臺

MuleSoft是著名的開源消息匯流排軟體廠商，隨時準備用其新的iON基於雲的應用集成平臺，改變應用集成領域和雲集成領域的格局。 MuleSoft的iON是第一個功能完整的，為雲應用集成構建的套件。

資料VS.應用集成

資料整合，是一種「批次處理模式」或者被調度的操作，是不同的資料來源和目標之間同步資料的，涵蓋了資料操作、調和、重複刪除、淨化、標準化和其他的資料密集操作。 本質上，資料整合提供最下層資料來源的抽象層。 資料整合任務可能一周、一天或者一小時，甚至是時刻都要運行一次。 但不會一小時運行數百萬次上千萬次。 資料整合任務可能包含資料或者位元組的單一記錄。

應用集成是關於應用之間(而不是資料來源之間)的消息交換的可靠性和準時性。 通常在以一種接近即時的速度在運轉，通常包括核心消息層的頂部的功能工作流類型。 應用集成讓業務流程可以跨越多重不同的系統，提供底層應用和業務流程的抽象層。 通常資料綜合包含在一個單一的應用集成任務中的非常小(儘管在一小時的過程中可能存在無數應用集成任務要處理)。

下圖顯示了兩種不同類型的集成之間的區別的高層次描述。 資料整合是關於資料從一個地方到另一個地方的轉移和轉換，忽略了應用或者業務邏輯，而應用集成考慮在應用邏輯層將系統連接在一起，資料就是作為一個簡單的旁觀者。

決策：你適合哪種集成方法

正如我以前所寫的，資料整合不必應用集成優越，也不比應用集成差勁。 只是取決於需求的不同。 例如，如果你需要從許多交易系統填充一個巨大的資料倉儲，資料整合可能更適合你。 如果你想構建一個簡單的業務流程，可以跨多個獨立的應用，應用集成就是可行之路。 差不多所有具有集成需求的企業都需要這兩種類型的集成技術。

應用集成案例

就像解釋基於雲的應用集成的好處一樣，可能最有效的就是在通用案例的環境中表現出來。

訂單到現金(Order to Cash (OTC))是最常見的業務流程，每一個商業產品交換都需要這個類型的業務流程來獲取報酬。 考慮這樣一個場景，商人賣了一個實體產品給其他商人。 他們收到來自客戶的訂單。 他們處理訂單，開發票、發貨單、收取款項。 這個流程跨越了多種不同的系統，可能還跨越多種組織(就像很多公司外包運輸)。 這個流程的圖表如下：

對於像OTC這樣的業務流程，是一個單一的邏輯業務流程，應用集成比資料整合更適合，主要由於以下原因：

(1)時間：應用集成是事件驅動的接近即時(而不是按計劃)。 流程完成更快，企業就會更快獲得收益，縮短應收賬款天數，更好的現金流。 更快和更精確的訂單，客戶滿意度就越高。

(2)流程完整性很重要。 應用集成框架保證了某一事件的發生，將會在正確的訂單中發生。 訂單中事件的發生很重要。 例如，一個訂單在沒開發票時不能運輸。 訂單將會把產品和發票一同運輸。 儘快獲得支付，財務資料在多個地方需要更新，客戶記錄、合同帳目等。

基於雲的應用集成將會改變EAI

MuleSoft的iON在應用集成市場將會是一場顛覆，主要有以下原因：

首先，本地EAI平臺已經存在多時，自二十世紀九十年代就是主流。 它們能力高，但是實現起來非常複雜和昂貴。

相當多的企業級軟體被雲終結了。 對比Siebel的本地應用和Salesforce的SaaS，就知道了。

並不是雲可以變魔術一樣讓事物整合在一起，而是為雲構建的套裝軟體是新的，更加整潔的構架，免費處理遺留問題。 例如，很多本地集成堆疊的代碼可以追溯到上個世紀九十年代，使用者介面還是Windows 95環境的。

其二，企業中越來越多的運營和分析應用逐漸轉移到雲端，像NetSuite或者Salesforce這樣的SaaS應用增加，基於雲的分析平臺成為重大分析和數位運算的預設選擇。

隨著應用和資料的軌跡逐漸轉移到雲端，集成將會繼續增加。 就像SaaS和雲不僅會成為主流，而且會成為業務應用的較好選擇，基於雲的應用集成將會成為EAI的更好選擇。