繼續以OSGI R4的Declarative Services(DS)來講講Service-Oriented Component Model(SOCM)，SOCM對于現有的Component-Oriented Model或者是Service-Oriented Model來說到底有什么不同的地方，到底DS能給我們帶來什么樣的好處呢？
首先來看看SOCM的概念，Component-Oriented Model、Service-Oriented Model曾經風行過很長一段時間，現在Component-Oriented Model聽得更少了，Service-Oriented Model則在如今的SOA中體現的淋漓盡致了，那么為什么會有SOCM這樣的概念冒出來呢，其實SOCM并不是DS提出來的，DS也是從Gravity中學習過來的，Component-Oriented Model強調的是系統以component方式的一種復用，而Service-Oriented Model強調的是系統以一種服務的方式來完成系統功能的實現，而SOCM則強調兩者，SOCM認為Component是Service的提供者，一個Component可以提供0至多個Service，其實這樣的概念放到SOA中仍然是可行的，同樣可以認為SOA也是一種SOCM，當然，DS的目的和SOA是不同的，所以表現出來兩者并無重復，而且作為SOCM來說DS的表現則更為優秀一些。
在了解了SOCM的概念后，來看看DS提出的目的，DS提出的目的其實強調的是對于Service Dependency的動態管理的實現，而在SOA中更在乎的是Service的動態Dependency的實現，但不是管理，這和DS是不同的，DS作為OSGI R4的一部分，自然要繼承OSGI本身的理念，就是系統足夠的動態化，DS強調自己是一種context-aware architecture，為什么這么說呢，這個在后面會講到。
講講OSGI R4為什么要引入DS呢，OSGI自己本身其實就是一種SOCM，它的Activator就代表著Component，而在這個Component中可以通過BundleContext進行Service的發布/查找/綁定，同樣的實現了SOCM，那它為什么還要引入DS呢？如果你使用過OSGI來進行系統的實現，就會知道通過Activator來完成Service的發布/查找/綁定是多么麻煩的一件事情，更關鍵的是還得監聽服務的狀態，以便根據服務的狀態對Component做出適當的行為，如果忘記根據依賴的服務的狀態進行處理，系統很容易出現某個Component不可用甚至造成系統崩潰的現象，DS的提出就是為了解決這個麻煩的，DS允許將任何一個POJO定義為Component，這樣就不用只通過Activator來完成Service Dependency的設置了，同時DS會幫忙根據Component所依賴的服務的狀態來決定Component的生命周期，而不用自己去處理這個問題，而且DS還能幫助完成Component中Service Dependency的動態管理，如根據Service的狀態自動綁定或注銷Service、自動的替換Service等，而這所以的自動化的管理依賴的都是系統運行的context，而不是通過應用去管理。
其實象現在的Spring IoC Container可以看作是一種Component-Oriented Model的支持，它解決了其中Component之間依賴的實現，但至于Component之間依賴的動態管理(例如Component根據其所依賴的Component的動態生命周期管理等)，暫時還沒有什么支持，在SOA中同樣也是如此，這就造成了如果要對系統進行調整，就必須在靜態配置階段完成，而不能在系統運行時進行動態的調整，也不能根據系統目前運行的狀態來自動的對Component、Service的Dependency進行管理，而在DS中這些都是可以做到的，所以DS強調自己是一種Context-aware architecture，也就是說它可以根據上下文來動態的對Component的生命周期進行管理、動態的對Service Dependency進行管理，^_^，智能化的管理系統。
簡單的說說在DS中DI的使用方式以及Service Dependency的動態管理的一些策略：
DI的使用方式
在前面的一篇blog中已經有提及了，在DS中可以采用lookup或類似setter DI這樣的方式來完成service的注入。
Service Dependency的動態管理
通過設置Service Dependency的policy、target、cardinality來實現動態的管理，例如policy就控制了是否根據所依賴的服務的狀態來管理Component的生命周期，如果設置為static，在所依賴的service變得不可用的情況下，DS就會自動的將這個Component的狀態設置為不可用，同時自動的處理依賴于這個Component所提供的Service的那些Component，target則是針對在DS中允許出現實現同一接口的多種實現的過濾策略，可以通過target準確的找到自己想要的service的實現，cardinality就指明了所依賴的是多少個服務接口的實現，也就是說允許使用一個接口的多種實現，^_^，在系統運行時，如Component所依賴的服務變得可用了了，那么DS會自動將這個Component的狀態設置為statisfied，這個時候如果外部有調用到這個component，那么component就被真正的實例化(這是對于lazy性質的Component而言)，當Component所依賴的服務變得不可用時，DS會嘗試尋找系統中是否仍然有可用的所依賴的服務(因為在DS中一個服務接口是可能有多個實現的)，如果找到DS則重新設定，如沒找到DS則會將Component的狀態重新設置為unstatisfied，同時通知引用了這個component提供的service的那些component。
經過這樣一些說明，可以看出DS主要強調的是動態的Service Dependency的管理，而不僅僅是之前業界流行并已經得到認可的DI，Service Dependency的管理為系統帶來了很大的靈活性，使得系統自身可以根據系統運行的context做出相應的響應，不過正因為這個原因，我們也不難發現這給測試工作帶來了更大的復雜度，測試時需要更多的模擬出系統的運行狀態，DS另一方面則給我們帶來了動態替換系統實現的好處，另外，我覺得的好處就是依托于OSGI這樣一個plugin architecture上，它使得面向接口的編程更加的突出和得以強制。