john evdemon在其最新的一篇帖子展示了針對soa，業界進行定義、重定義和自相矛盾的嘗試。這些定義五花八門，無章可循。
首先是關於松耦合的大體定義：
隨著web服務和soa的來臨，我們正試圖建立耦合更鬆的架構和系統。松耦合系統提供了許多好處，包括：支援執行時遲繫結或動態繫結到其它元件，可以化解元件結構中的差異，安全模型、協議和語義，從而對易變性進行了抽象。接著，重用佔據了舞台**：
軟體重用的核心思想並不是什麼新東西，即從最初已經建立出的元件中獲取更多價值。在soa之前，由於組織內業務單位之間缺乏集中 控制和溝通，導致相同的解決方案一再重**明。為了確保組織內各業務單位不建立重複服務，soa干係人，如業務分析師和架構師，應該能夠以一種廣為人知和 系統的方法來尋找現有服務並評估它們是否能夠重用。業界最後發現真正的重用實在是太複雜了並且並不是總能實現：
建立可重用服務要求對未來進行**……服務建立者怎麼可能準確地猜到未來應用的需求？「車到山前必有路」的想法非常難以實現真正的重用。加上，鼓勵所建立元件可被其他小組重用的組織，即使有，也不多。接著，它談到了業務流程的松耦合：
硬連線流程應該是一種罪惡，我們要堅決地抵制它……松耦合將迫使我們反思業務活動的方方面面……它將對我們管理業務操作的方式產 生深遠影響。厚重的流程手冊留下了對我們硬連線業務操作方式的遺囑。預先指定全部活動的詳細細節，然後監測所有活動來清除任何不符合標準的變化。盡可能地 加固操作。松耦合業務流程的運轉方式完全不同。當soa無能為力之時，事件驅動架構（eda）成了（乙個更流行的）soa替補。：
eda交付了soa只是承諾卻沒有做到的松耦合。它並非同步的「命令並控制」型別的模式，而是其反面：非同步的「發布並訂閱」型別的模式。發布者和訂閱者完全不知道對方的存在；在某種程度上，元件是松耦合的：它們只共享了訊息的語義。接下來，它談到了業務/it的對齊：
自從發跡於物件導向設計和基於元件的軟體開發方**，soa已經進入了理想的崇高領域。隨著故事的發展，soa不單單是為重振it而設計的了；它還成了能改變it所服務於的業務的魔彈。並且，最終它發現soa跟技術沒有任何瓜葛：
太令人震驚了；soa似乎是第乙個對技術沒要求的技術。大廠商們告誡說，只要你堅持走有soa特色的架構基本路線不動搖，在技術上不管你做什麼都沒關係。這些定義明顯的不一致似乎是來自於以下幾個因素：
SOA系列一 SOA的定義
soa代表乙個開放的 敏捷的 可擴充套件的 可聯邦的 可組合的架夠，包含了自治的 高服務質量的 廠商多樣性的 可互操作的 可發現的和潛在可復用的服務，並使用web服務來實現。soa能夠建立乙個業務邏輯抽象和技術抽象，可能導致對業務流程建模和技術架構的改變，從而導致這些模型間的鬆散偶合。soa是既有平...
我對SOA的反思 SOA架構的本質
年初的時候，寫過一篇名為 國內eai正當時，bpm為時尚早，workflow持續增長，soa依然概念 的blog日誌。那個時候，我認為soa還依然是個很 虛 的概念。而現在，我只能說 sorry，那時候的我，錯了。soa已經不再是概念，而是乙個實實在在的構架了。在寫完那篇帖子之後，我一直在反思soa...
我對SOA的反思 SOA架構的本質
年初的時候，寫過一篇名為 國內eai正當時，bpm為時尚早，workflow持續增長，soa依然概念 的blog日誌。那個時候，我認為soa還依然是個很 虛 的概念。而現在，我只能說 sorry，那時候的我，錯了。soa已經不再是概念，而是乙個實實在在的構架了。在寫完那篇帖子之後，我一直在反思soa...