從EAI到SOA

寫在前面
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重新發現了整合程式的價值，在Integration Environment中，整合程式代表其背後的應用系統，這些程式提供了各個子系統的應用服務，它們才是Integration Environment中最有價值的部分，是Integration Environment中的First Class，並對這些程式提供統一的打包方式，並提供運行時管理。

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

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

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