程式碼高𠅙

2006/07/16

從 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 的觀念或想法並不是用來取代現有的軟體設計觀念,而是在面對模組重用或系統整合時,所需 "額外"、"附加" 考量的思維。