寫在前面
SOA現在越發鬧騰的厲害了，各種宣傳越來越多，都把SOA吹上天；到底SOA是什么，有啥神奇之處，真的想宣傳說的那么好嗎？看了種種文章，只是越發混沌。
罷了，俺做技術的，商業上的宣傳，俺不在意。既然SOA只是理念，那么俺就從它的支持技術來看看，從過去到現在的區別，看看SOA到底是啥！

從EAI到SOA
1.史前時代，無論原始的socket，或者后來的RMI，都只能在同一平臺上傳輸數據，無法處理異構系統數據傳遞，比如RMI沒有辦法和.NET通信。
這個階段的問題是：1.點對點的傳輸通道依賴，如果目標地址變化或者故障，就出問題。沒有提供更多的交換管理能力。點對點的交換越多，管理成本就越高；2。數據格式綁定，依賴于雙方的嚴格的私有格式。
擴展——EDI的出現解決了異構系統的數據傳遞格式標準。

2. EAI時代。這個時代要解決的是數據交換管理。
技術平臺上看：基于中間件系統，采用了集中式管理的消息交換管理系統，就是所謂的信息總線技術——MQ技術。
統一消息格式是基本工作，對消息傳遞管理是其核心。包括了兩種不同的消息傳遞方式。時代特征導致它的問題：只關注于消息的格式和傳遞，而忽略的各個系統的集成程序：沒有提供對于這些集成程序的打包和管理。

擴展——JCA. 相對于JMS，JCA關注于集成程序的打包和管理，然而集成程序依然只是二等公民，但JCA 1.0的缺點與規范的未成熟有關。首先，JCA不支持在EAI方案中要求的異步調用。第二， JCA 1.0僅支持從應用程序服務器到EIS的調用。最后，JCA 1.0不支持定義從EIS接收應用程序事件的任何語義。JCA是用驅動整合過程的入口目標對準基于入口的整合。JCA 1.5規范增加支持JMS插入功能，EIS事件通知和異步方法。

3. SOA時代的到來。數據交換和信息共享之后，就是服務管理以及流程管理。
ESB是SOA的最佳技術平臺。ESB與MQ一樣也提供統一的消息格式，并管理消息傳遞；
不同的是，ESB重新發現了集成程序的價值，在集成環境中，集成程序代表其背后的應用系統，這些程序提供了各個子系統的應用服務，它們才是集成環境中最有價值的部分，是集成環境中的First Class，并對這些程序提供統一的打包方式，并提供運行時管理。

另一方面，ESB把集成程序進一步分解為服務（業務邏輯）以及Endpoint（服務的入口點）。這樣服務不僅僅是可重用，而且是可組裝編排; 可快速注冊發布; 質量可監控；生命周期可管理的，也正是因此，所謂的BPEL等面向業務的能力開始顯現，最終實現SOA的理念：在整個IT范圍內實現服務治理和優化，從而直接推動業務的優化。

EAI和SOA的區別
前EAI時代，有個啥事都給自己跑腿送信，遇到對方不在只能一遍遍的跑。
EAI時代，應用服務器是企業的收發室，只知道信件本身，對于信件收發者的身份卻不知道，更不知道信件所處的流程體系。
SOA時代，ESB是企業的辦公室，不僅知道信件本身，對于信件收發者的身份都清楚，還可以知道信件所處的流程體系。就可以很容易的組合各個服務，建立起各種組合服務，就像現實世界的專員（specialist），響應業務的變化。

SOA的產商利益
SOA的基礎框架提供了支撐平臺（也就是可能性）；然而要實現SOA的理想，卻還需要對業務重新梳理，發現和重用IT資產，正如ERP那樣，這才是SOA實施的關鍵所在；而像IBM這樣的公司正擁有這樣的咨詢能力，所以IBM每年都投入大量的資金來推動SOA的應用，就在情理之中了。?

?

轉載于:https://www.cnblogs.com/encounter/archive/2007/08/24/2189265.html

總結

以上是生活随笔為你收集整理的从EAI到SOA的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。