應用集成

應用集成主要可以用於企業內及企業間的服務整合，通過應用集成的方式，有效改善現有系統之間調用的網狀關係，使得系統之間的關係更加可視化，管控能力更強。它的高性能、高可靠性、高擴展性和業務化給客户帶來高管控能力、高投資回報、高運營能力等，從而提高企業的IT服務質量，更直接的為企業的業務擴展、業務創新、客户維護和卓越運營提供了有力的保障。

將所有的應用軟件安裝在EWEBS服務器（羣）上，客户端零安裝，就可以基於WEB實時靈活應用。通過極通獨創的AIP協議，把應用程序的人機交互邏輯（應用程序界面、鍵盤及鼠標的操作、音頻輸入輸出、讀卡器、打印輸出等）與計算邏輯隔離開來。在用户訪問EWEBS服務器虛擬化後的應用時，用户計算機只需要把人機交互邏輯通過AIP協議傳送到服務器端，服務器端為用户開設獨立的會話空間，應用程序的計算邏輯在這個會話空間中運行，把變化後的人機交互邏輯傳送給客户端，並且在客户端相應設備展示出來，從而使用户獲得如同運行本地應用程序一樣的訪問感受。

隨着面向服務和基於雲的架構脱穎而出，IT部門越來越重視良好的集成設計。為了避免過快的雲應用集成的潛在危險，需要精心策劃架構；同樣的，應用於複雜的基於SOA系統升級的設計的開發流程也是一樣。隨着應用集成需要更多的靈活性和普遍的可適用性，優化設計比以往便得更加重要。在即將到來的雲計算應用集成中，以集成為中心的雲計算，像iPaaS，顯示了雲應用者數量的快速增長，未來也將面臨着更加複雜的集成和實際挑戰 ^[1]  。

很多平台即服務（PaaS）和雲計算的應用者熱衷於更快的集成開發承諾。然而，根據以為早期的雲應用者所述，對於速度的需求也正是這個過程中最大的陷阱所在。

Pradip Sitaram是Enterprise Community Partners有限公司的CIO，他指出企業未能看到匆忙部署雲應用的潛在危險，日常需求和測試被忽視的時候，他們就會處於危險監管的風險之中。Sitaram也解釋了為什麼他自己的團隊花時間精心策劃其基於雲的系統的最佳設計方法。“集成是良好架構的記過，反之則不是這樣，”他説。他警告市場中的PaaS和雲計算：不要向軟件開發流程妥協，以換取集成開發速度。

醫療衞生機構尋求系統升級，需要同多種部門服務和需要統一的各種應用作鬥爭。Michael Sanchez是夏普醫療保健（Sharp Healthcare）的首席Web架構師，最近探討了用ESB聯合門户在三個正在使用的分離應用中，集成醫療健康記錄信息，構建一種有效的基於SOA的系統。

夏普醫療保健採用了甲骨文SOA套件和甲骨文WebLogic套件，來支持mySharp病人門户，這個項目運行在甲骨文服務總線上。Sanchez指出甲骨文ESB的使用對於同一分離的系統十分重要，從而確保它們能共同工作，為詢問的病人生成一個響應。Sanchez表示夏普醫療保健能夠按需增加新的後端病人照顧，並且有望擴展器門户來包含醫院中的其他系統。

隨着雲計算架構落地，中間件集成挑戰出現。在雲應用集成的早期階段，所謂的以集成為中心的雲計算，以“基礎架構即服務（IaaS）”，“平台即服務（PaaS）”或者“集成平台即服務（iPaaS）”為主，包括了廣泛的中間件服務，對於成功的雲集成奏效。但是iPaaS雲集成也有其自身的獨特挑戰，尤其是安全和數據處理問題，在雲工作中也會繼續保持這種複雜性。

隨着應用集成需要更多的靈活性和突發改變的適應性，應用程序接口（API）在集成設計中越來越重要。為了這個目的，API增加了支持REST接口，這也需要更多總體設計方法，以及允許更加廣泛的工作性情況。

在Gartner AADI會議上，Gartner副總兼分析師Daniel Sholler引用了REST架構的普遍性作為其在廣大開發者中流行的原因，以及REST能夠同第三方雲和移動應用成功合作。而且，REST原則的應用來進行Web服務設計，Sholler稱之為面向Web的架構，或者WOA，是基於設計應該“完全應用中立”和“儘可能普遍”的想法，根據Sholler所述。隨着雲和移動應用繼續擴展，實現API設計的中立性，同時確保REST只有在需要的地方使用且運轉良好是集成設計成功的關鍵所在。

快速深入應用集成架構

應用集成定義了在多個應用之間移動數據的原則，來降低不一致的風險，並且減少通過多個手動更新來鏈接應用程序所需的工作。它包含數據庫設計和應用數據的流水線的組合。不出意料，應用被分割為數據庫相關和數據流相關，這一點並沒有多大變化。

被改變的是我們構建應用的方式，以及應用程序託管的方式。最近這些年裏，企業架構（EA）被接受為正式的IT原則，應用自身的組件化，應用開發的方式以及雲計算和虛擬化成為託管的新途徑，這些都增加了應用集成的重要性，並且促進應用集成所需的流水線化和自動化的需求。當高級管理團隊想要更加敏捷，達到更加高效的IT支持時，所有這些因素都匯聚到CIO前，因此找到解決這些問題的系統方法至關重要。

EA從高層定義了業務流程架構，並且從高層定義衍生出應用需求。EA創造了更多信息共享的需求，但是它還鼓勵用户在傳統應用之外滿足需求。

EA對應用集成的影響

EA對應用集成的影響在於信息集成的以數據庫為中心的理念。如果業務數據存儲在某個倉庫裏，可以通過查詢使用這些數據，那麼單個信息的使用是和查詢及分析相關的，而和特定應用程序無關。

應用的組件化將大而全的軟件分解成很多小部分，每一小部分和其他部分都是松耦合的關係。信息在應用內的組件之間的流動必須非常高效，否則工作的體驗和生產效率就會受到影響。因此，大家做了大量工作，致力於改進組件間信息的交換。移動和移動工作的巨大作用鼓勵越來越多的組件化，因為嘗試解決這些生產力問題的公司需要更加高效。

組件化的一大驅動因素是組件重用，從一個通用組件集構建出多個應用。因為在應用間重用組件，應用本身的壁壘被打破，應用集成和組件集成成為趨勢。組件集成工具，比如服務和消息總線或服務數據定義語言，也能夠用來集成應用程序。

雲計算和虛擬化已經打破了應用程序或者組件和服務器資源之間的傳統壁壘。服務器已經是池的一部分，一些服務器甚至可能在公司外的公有云上。任何功能都可能運行在任何地方，因此需要記錄下來它到底在哪裏運行，這樣其他組件才能夠找到它。以動態方式部署應用意味着在部署組件之間提供動態的鏈接。

應用集成隨着應用開發的進化而演變

因為應用開發的其他方面在演進，促使應用集成也在持續改進。敏捷運營創建出了新工具集的需求，並且這些工具已經進化為更為複雜的編排工具，來部署並且鏈接運行在資源池上的應用和組件。這些工具，隨着進化和改進，吸收了一些曾經是應用集成傳統部分的功能。

這些趨勢影響着數據庫和信息流的使用方式，來為業務流程鏈接IT所支持的各個組件。在傳統理念裏，如今應用集成領域最為重要的趨勢不再是唯一的問題或者甚至不是最重要的問題。如果你問CIO們如今他們最大的挑戰是什麼，應用集成可能不是最大的，但是三個新要素卻可能是。

應用集成的觀點需要適應這樣的現實。EA驅動關注於分析，軟件組件化以及雲都會影響到信息的移動，從而影響到解決應用集成的方式。支持這三種要素的工具已經正在互相融合，應用集成顯然也會隨着時間的推進成為越來越多的工具會考慮到的領域。 ^[2]