Primitive Service Model and Interceptor in HiveMind

    最簡單的服務模式就是primitive service model。在這種模式下服務在第一次應用的時候就會被建立。這種建立方法對與服務工廠，攔截器工廠和一些由hivemind.module提供的基本服務是很合適的。
    在使用者代碼裡面很少需要使用到這種模式。它主要是為了支援hivemind module自身的服務存在的（單例模式服務就是建立在幾個由簡單模式建立的服務基礎上的）。
    簡單模式的服務建立很簡單，只包括建立核心服務和在必要時產生攔截器。核心服務的產生由指定的產生器完成，攔截器由指定的攔截器工廠產生。
    攔截器（Interceptor）簡單點說就是把實際調用的對象封裝起來，並且可以在調用被封裝類的方法之前或之後做一些特定的處理。作為一個攔截器最大的特點是它必須和被封裝的對象有相同的介面簽名，使用者程式不必關心調用的是攔截器還是實際對象。
    攔截器的產生一般有兩種方法。一種是通過動態代碼產生，這種方法的優點是調用開銷小，只需要在產生時需要多一些的系統開銷，缺點是代碼編寫難度大，調試複雜。另一種是通過java.lang.reflect.Proxy類或其它類似於它的技術，通過動態方法引動過程完成代理的產生，這種方法的優點是易於編寫，但是需要大量的放射調用，增加了調用的系統開銷。具體使用哪種方法產生攔截器HiveMind沒有強制限定，使用者可以在攔截器工廠裡面指定。
    HiveMind在解析完模組描述符（XML設定檔）後，會為每一個服務擴充點(service-point)產生一個ServicePoint的對象用於管理和產生實際的核心服務。展示了整個類的結構。

    一個服務擴充點主要就由確定的結構構成。Schema是用於定義參數格式的，Module是包含個擴充點的模組。ServiceImplementationConstructor負責產生核心服務，目前HiveMind支援兩種產生方式，一種是直接從指定類產生，一種是由別的服務產生。HiveMind的基本構造工廠BuilderFactory就是由第一種構造方式直接從類產生，這種方式的好處是不需要Schema，不需要其它工廠支援，適合用於作為最地層的支援服務。ServiceModel是用於管理服務建置規則和生命週期的，目前HiveMind提供了簡單模式，單例模式，與線程繫結模式和基於池模式四種。使用者也可以根據自己的需要可以很方便的對它進行擴充。ServiceInterceptorContribution是用於儲存攔截器資訊的，它會根據指定的攔截器工廠服務和指定的攔截器產生順序為核心服務產生攔截器。
    現在再回討論簡單模式，當指定服務第一次被引用的時候，PrimitiveServiceModel會直接調用ServiceImplementationConstructor方法產生核心服務。如果有攔截器再調用ServiceInterceptorContribution的集合，依次對核心服務產生攔截器。