不斷增長的客戶和商業伙伴對實時信息的期望的持續增加，為了滿足這種期望的需要，企業被迫連接他們的那些異構的系統來增加產出、提高效率以及，最終的，使顧客滿足。為使一個組織內部IT系統互相通信，導致了企業應用集成(EAI)的發展。EAI通過建立底層結構，來聯系橫貫整個企業的異構系統、應用、數據源等。EAI解決方案的起源可以追溯到那些提供雙向的解決方案以完成在企業內部的ERP、CRM、SCM、
EAI不是一個能徹底解決最終問題的方案，他更可以說是正在建立一個靈活的、標準化的企業應用底層架構，可以答應新的基于IT的應用和商業處理能夠更輕易和更有效的被部署。新的底層架構答應企業中的應用能夠實時的，無縫的互相通信。
EAI解決方案可以呈現許多種形式并以多種級別出現。EAI合適的級別依靠于許多因素，包括公司的大小、公司的行業類別、公司應用的集成度或是項目的復雜度以及預算等等。
界面重組是一個面向用戶的整合，他將原先系統的終端窗口和PC的圖形界面使用一個標準的界面(有代表性的例子是使用瀏覽器)來替換。一般的，應用程序終端窗口的功能可以一對一地映射到一個基于瀏覽器的圖形用戶界面。新的表示層需要與現存的遺留系統的商業邏輯或者一些封裝的應用如ERP、CRM以及SCM等進行集成。
企業門戶應用(Enterprise Portal)也可以被看成是一個復雜的界面重組的解決方案。一個企業門戶合并了多個企業應用，同時表現為一個可定制的基于瀏覽器的界面。在這個類型的EAI中，企業門戶框架和中間件解決方案是一樣的。進入討論組討論。
數據集成
數據集成發生在企業內的數據庫和數據源級別。通過從一個數據源將數據移植到另外一個數據源來完成數據集成。數據集成是現有EAI解決方案中最普遍的一個形式。然而，數據集成的一個最大的問題是商業邏輯經常只存在于主系統中，無法在數據庫層次去響應商業流程的處理，因此這限制了實時處理的能力。
此外還有一些數據復制和中間件工具來推動在數據源之間的數據傳輸，一些是以實時方式工作的，一些是以批處理方式工作的。
下面列出了一些數據集成的方法：
1.批傳輸
2.數據合并
3.數據復制
4.析取、轉換、裝載解決方案(ETL Solution)
ETL解決方案(如上圖所示)，是基于ETL引擎的，從不同的應用程序析取、轉換、過濾和裝載數據到數據倉庫和(或)數據市集。現在ETL已經是企業實現數據集成的一個非常有效的途徑。
商務流程集成
雖然數據集成已經證實是EAI的一個流行的形式，然而，從安全性、數據完整性、商務流程角度來看，數據集成仍然存在著很多問題。組織內大量的數據是被商業邏輯所訪問和維持的。商業邏輯應用并加強了必須的商業規則、商務流程和安全性，而這些對于下層數據都是必需的。
商務流程集成產生于跨越了多個應用的商務流程層。通常通過使用一些高層的中間件來表現商務流程集成的特征。這類中間件產品的代表是消息中介，消息中介使用一個總線模式或者是HUB模式來對消息處理標準化并控制信息流。下面的圖示在一個較高的層次說明了一個開放的商務流程的組成：
函數或方法集成
函數和方法集成包括直接的和嚴格的，在網絡環境中的跨平臺應用程序之間的應用到應用(A2A)的集成。它涵蓋了普通的代碼(COBOL,C++,
java)撰寫、應用程序接口(APIs)、遠端過程調用(RPCs)、分布式中間件如TP監控、分布式對象、公共對象訪問中介(CORBA)、Java遠端方法調用(RMI)、面向消息的中間件以及Web服務等等各種軟件技術。
面向函數和方法的集成一般來說是處于同步模式的，即基于客戶(請求程序)和服務器(響應程序)之間的請求響應交互機制。
Web服務 Web服務提供了一個分布式的計算技術，用于在Internet 或者intranet上通過使用標準的
xml協議和信息格式來展現商業應用服務。使用標準的XML協議使得Web服務平臺、語言和發布者能夠互相獨立，這是EAI解決方案的一個理想的候選者。
通過開放的Internet標準：Web服務描述語言(WSDL，用于服務描述)，統一描述、發現和集成規范(UDDI，用于服務的發布和集成)，簡單對象訪問協議(SOAP，用于服務調用)和Web服務流語言(WSFL，用來定義工作流，這尚不是一個W3C標準)，Web服務消除了現存解決方案(如CORBA和DCOM)中的互用性問題。
EAI和Web服務
Web服務不是EAI或者是EAI的一部分，更甚者，Web服務是另外一個技術，Web服務能夠使EAI成為真正可能的、便捷實施的，同時又引人注目的解決方案。Web服務能徹底地改變傳統的EAI中點對點的集成處理方式。
使用Web服務，通過松散的應用集成，一個企業可以僅僅實現EAI的一個子集，即能取得實效。與之相反，EAI要實現一個全盤的方案，來緊密的集成和聯系支持公司業務的所有的系統和應用。在公司內部不同的業務系統和技術單體中可能需要花費數年的持續的努力，高投資以及為之配備的充實的資源。
Web服務，以這樣一種松散的服務捆綁集合形式(也可以說是一個非凡得解決方案)，能夠快速、低代價地開發、發布、發現和動態綁定應用。就當代Web服務的技術發展水平來看，Web服務可以實現應用程序之間的函數或方法級的集成。他們不是自然的基于事務的，同時僅提供了基本的“請求/響應”功能。然而，在下一代的Web服務中，在功能上和技術上都會更先進，將會提供用戶接口封裝和安全性，他們將能夠包裝一個應用程序并且把他嵌入到其他的應用程序中去。
現有的主要關注于應用集成的EAI解決方案將不得不因此而改變。在將來，包裝好的應用程序將使用如XML、SOAP、WSDL和UDDI技術來把他們的函數或方法作為Web服務的界面來顯示。因此，EAI解決方案將不得不提供一個對服務集成的廣泛的支持，而不僅僅是應用集成。進入討論組討論。
傳統EAI解決方案和Web服務之間的顯著的不同 下面是傳統的EAI解決方案和Web服務之間的一些基本的不同點：
(注重：有一些不同點所描述的Web服務的特點可能并非是Web服務目前有的特性，而是考慮了Web服務被提議的未來的改進)
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
簡單性：毫無疑問，相比于典型的EAI解決方案(也許包括分布式技術如DCOM和CORBA)，Web服務更便于設計、開發、維護和使用。既然開發和使用Web服務的平臺框架已經預備好了，創建跨越多個應用程序的商務流程處理將變得相對簡單。
開放標準：不像有所有權的EAI解決方案，Web服務是基于開放標準諸如UDDI、SOAP、HTTP的。這個可能是導致Web服務被廣泛接受的最重要的因素。事實上基于現存的開放標準消除了企業潛在地為了支持新出現的Web技術的投資的需要。
靈活性：既然EAI解決方案需要點對點集成，一端的改變必須告知另外一端，這自然使集成變得非常的生硬，同時也是浪費開發人員的時間的?；赪eb服務的集成是非常靈活的，因為他是建立在發布服務的應用程序和使用服務的應用程序之間的松散耦合。
便宜：EAI解決方案，諸如消息中介，其實施是非常昂貴的。而Web服務的實施則會變得便宜而快速。
范圍：EAI解決方案，諸如消息中介，把應用程序作為一個單個的實體來集成。然而Web服務答應企業把大的應用劃分為小的獨立的邏輯實體并且包裝他們。舉例來說，企業可以為一個ERP應用的不同的商業
組件進行包裝。如訂單治理、接受購買訂單、訂單情況、訂單確認、帳戶接受、帳戶支付等等。
高效性：已在前面幾點提到的，Web服務答應應用程序劃分為一些小的邏輯組件，因為在小粒度基礎上集成應用程序，集成將變得更輕易。這也使Web服務的EAI解決方案比傳統的EAI解決方案更有效率。
動態：Web服務通過提供動態的服務接口來實施一個動態的集成。然而傳統的EAI解決方案都是靜態處理的。
用Web服務的EAI示例
下面的[圖表]顯示了在一個在企業內使用Web服務的例子。在這個例子中，在應用服務器中運行的企業門戶從多個內部應用集成信息，并提供一個跨越這些應用的業務處理的入口點。企業門戶應用通過內部應用程序使用私有UDDI注冊中心(Private UDDI Registry)來獲得可提供的Web服務的技術信息，并且在企業內部Intranet上調用這些服務。一些經常被調用的Web服務的綁定信息將被企業門戶應用緩存，這樣得以避免花費在動態綁定上的資源和時間。在這個例子里面，Web服務把企業門戶和CRM、ERP應用程序松散的集成在一起。
流程步驟如下：
1.在登錄企業門戶之后，用戶發出請求信息；
2.支持企業門戶框架的應用程序通過瀏覽私有UDDI注冊中心獲得關于CRM和ERP應用的Web服務的技術；
3.Web服務的位置和WSDL綁定信息被穿送給應用服務器；
4.應用程序調用CRM應用發布的Web服務得到個人的信息，如名字、身份證號碼、地址以及用戶的Email。這個通訊過程是基于SOAP交互的；
5.應用程序調用ERP應用發布的Web服務獲得銀行帳號信息，諸如銀行帳號號碼，結余和用戶交易歷史記錄。這個通訊過程也是基于SOAP交互的；
6.信息被格式化后，被發給起初的調用用戶。
從哪里開始
企業在內部應用程序中使用Web服務來實施應用集成的項目，應當從函數、應用程序接口(API)，或者遠端過程調用(RPC)級別開始這一進程。這個將使企業內使用和實施Web服務的IT技術人員熟悉Web服務技術，當企業將來使用Web服務進行外部集成(B2B集成)項目時，將會有助于項目的有效進行。在Intranet內控制、治理、尋找、執行和維護Web服務相對來說也比通過企業防火墻在Internet上使用Web服務更為輕易。進一步來說，它將幫助企業來比較和鑒別，使用標準化和相對便宜的Web服務解決方案相對于昂貴的傳統的EAI解決方案到底是不是對提高企業的產出率更有幫助。
然而，要求企業拋棄現存的EAI底層架構并且盲目的轉向開發基于Web服務的解決方案來替代它是不太現實的。企業不會停止使用提供完整事務服務的EAI中間件框架。在使用Web服務的場所，不是替代(現在還不是)，而是應該使用Web服務來支撐現存的下層結構。
經過一段時間，Web服務將逐漸的由一個EAI解決方案進化為一個B2Bi(B2B Intergration)解決方案。
結論 通過一個被Web標準支持的方法而不是一個有私有知識產權的系統，Web服務提供一個中立的平臺來集成應用程序，從而被用于集成不同的應用系統。依靠Web服務，企業能夠實時地訪問不同部門、不同應用、不同平臺和不同系統的信息，這已是Web服務被接受的最重要和最有力的因素之一。在企業”冒險”在B2B中使用Web服務實施應用集成之前，企業應當首先在他們內部的非面向事務的一般商業流程集成中使用Web服務。進入討論組討論。
