Event-driven Architecture 如何延伸 Service-oriented Architecture
今天為了用 Web service技術實現EDA，需要一個額外的SOAP感知的訊息佇列基礎設施，而這並非是基於SOA實作的Web服務。
基本形式的SOA在現有的網絡基礎設施上，如HTTP層，藉由Web service就完全可以實作。這就是當前的‘SOA炒作’的來源，這也可能是SOA壓倒性EDA的原因。
當前的 ESB（企業服務總線）基礎設施提供了一種聯合訊息佇列和Web service的技術。這就是為什麼使用ESB的基礎設施是很適合實作 EDA和SOA解決方案，並適合結合這兩種架構風格。
不斷發展的Web service標準如WS-Eventing、WS-Notification、WS-MetadataExchange、WS-ReliableMessaging、WS-Security、WS-Choreography，還有很多，結合新興的SOAP感知架構組件如網路設備和作業系統將在未來提供大部分的ESB功能，這些在目前我們必須ESB的供應廠商獲得。
SOA和EDA的實作必須被看作是業務流程管理（BPM）的範疇。
現代的BPM工具是基於 BPEL（業務流程執行語言）。目前的BPEL實作強烈地聚焦在指揮和控制模型、服務的編排，也放在SOA上。除了編排BPEL - 在一定的延伸 - 也支援工作流程，一種編排方法，這走上EDA的方向。
然而， BPEL有一個程序性的本質和運行的實作需要一個控制的BPEL引擎。這在SOA情況下不是問題，但要實作EDA目標的鬆散耦合，它是有問題的。良
好的EDA支援寧願是一個聲明性模型而不是程序性模型。簡單地說是一個其設計師以點擊機制可連接事件到出版者和訂閱者的模型。
運行的實作應該是和控制引擎無關，而是根據先前提到的Web service標準。很明顯地解決方案是在這個方向發展的。在這個時刻，及時地使用SOAP over JMS或ESB提供的其他SOAP為基礎的替代品是適當的。
藉由創建基於普遍被認可、被理解和被實作的Web service技術的目前解決方案，系統未來將在後續的技術的、經濟的和組織的演變和革新呈現強勁的能力。
自我LV~