從 Inversion of Control 談 SOA 與 IoC

SOA 是 IoC 的自然演化或延伸, IoC 是 SOA 的開路先鋒

1. IoC 強調的是依賴注入，控制權反轉。在控制權反轉這事上，SOA 與 IoC 所扮演的角色相同，都是希望元件開發者所開發出來的元件，具有 "Don't call us, we'll call you" - the Hollywood Principle 的特質。然而 IoC 相形之下，著重於元件開發層次，它強調個別元件如何實作，才能達到這項訴求 (例如： type 1 IoC: interface injection, type 2 IoC: setter injection, type 3 IoC: constructor injection)。而 SOA 相形之下，則著重於系統及整體架構。SOA 提供了在系統架構層次，如何達到控制權反轉這類機制的思維。
2. 關 於依賴注入，SOA 較之 IoC 有更高一層的訴求，即是希望達到 "沒有依賴"，或是最低限度依賴的程式。IoC 導向的系統元件，可以達成兩個元件之間，僅相依於兩者間的特定介面。在這種情況下，只要這一介面關係存在，就能替換其中各別元件的實作。而 SOA 則希望能做到，讓系統中的每個元件，儘量使用同一組介面或協定，而不是依賴於其中某些元件的特定介面。如果整個系統都使用同一組介面或協定，代表整個系統 中的任意元件，都可以任意組合。為達到這樣的訴求，系統元件介面便需傾向於使用粗粒度 (coarse-grained) 的介面。
3. 由於粗粒度的介面無法提供如細粒度 (fine-grained) 介面那樣豐富的語意，因此只好轉由介面參數身上著手，這也就是為何 SOA 強調使用文件導向的參數(亦即參數本身為一含括豐富語意的文件)
4. 沒 有 IoC，就做不到 SOA：試想，若你的系統架構設計沒有辦法做到控制權反轉及依賴注入，又如何在系統上線後，指定元件之間的參引關係，或是將許多元件編織 (waving) 起來，成為一個作業流程呢。所以有人說，SOA 的觀念或想法並不是用來取代現有的軟體設計觀念，而是在面對模組重用或系統整合時，所需 "額外"、"附加" 考量的思維。