--sunfruit
Ioc模式是一種框架技術性質(zhì)的模式，它同時也為AOP的Java實現(xiàn)提供了一種途徑
注：原貼來自J道
Ioc模式
分離關注（ Separation of Concerns : SOC）是Ioc模式和AOP產(chǎn)生最原始動力，通過功能分解可得到關注點，這些關注可以是 組件Components, 方面Aspects或服務Services。
從GoF設計模式中，我們已經(jīng)習慣一種思維編程方式：Interface Driven Design 接口驅(qū)動，接口驅(qū)動有很多好處，可以提供不同靈活的子類實現(xiàn)，增加代碼穩(wěn)定和健壯性等等，但是接口一定是需要實現(xiàn)的，也就是如下語句遲早要執(zhí)行：
AInterface a = new AInterfaceImp();
AInterfaceImp是接口AInterface的一個子類，Ioc模式可以延緩接口的實現(xiàn)，根據(jù)需要實現(xiàn)，有個比喻：接口如同空的模型套，在必要時，需要向模型套注射石膏，這樣才能成為一個模型實體，因此，我們將人為控制接口的實現(xiàn)成為"注射"。
Ioc英文為 Inversion of Control，即反轉(zhuǎn)模式，這里有著名的好萊塢理論：你呆著別動，到時我會找你。
其實Ioc模式也是解決調(diào)用者和被調(diào)用者之間的一種關系，上述AInterface實現(xiàn)語句表明當前是在調(diào)用被調(diào)用者AInterfaceImp，由于被調(diào)用者名稱寫入了調(diào)用者的代碼中，這產(chǎn)生了一個接口實現(xiàn)的原罪：彼此聯(lián)系，調(diào)用者和被調(diào)用者有緊密聯(lián)系，在UML中是用依賴 Dependency 表示。
但是這種依賴在分離關注的思維下是不可忍耐的，必須切割，實現(xiàn)調(diào)用者和被調(diào)用者解耦，新的Ioc模式 Dependency Injection 模式由此產(chǎn)生了， Dependency Injection模式是依賴注射的意思，也就是將依賴先剝離，然后在適當時候再注射進入。
Ioc模式（Dependency Injection模式）有三種：
第一種類型 從JNDI或ServiceManager等獲得被調(diào)用者，這里類似ServiceLocator模式。 1. EJB/J2EE
2. Avalon（Apache的一個復雜使用不多的項目）
第二種類型 使用JavaBeans的setter方法 1. Spring Framework,
2. WebWork/XWork
第三種類型 在構造方法中實現(xiàn)依賴 1. PicoContainer,
2. HiveMind
有過EJB開發(fā)經(jīng)驗的人都知道，每個EJB的調(diào)用都需要通過JNDI尋找到工廠性質(zhì)的Home接口，在我的教程EJB是什么章節(jié)中，我也是從依賴和工廠模式角度來闡述EJB的使用。
在通常傳統(tǒng)情況下，為了實現(xiàn)調(diào)用者和被調(diào)用者解耦，分離，一般是通過工廠模式實現(xiàn)的，下面將通過比較工廠模式和Ioc模式不同，加深理解Ioc模式。
工廠模式和Ioc
假設有兩個類B 和 C：B作為調(diào)用者，C是被調(diào)用者，在B代碼中存在對C的調(diào)用：
public class B{
private C comp;
......
}
實現(xiàn)comp實例有兩種途徑：單態(tài)工廠模式和Ioc。
工廠模式實現(xiàn)如下：
public class B{
private C comp;
private final static MyFactory myFactory = MyFactory.getInstance();
public B(){
this.comp = myFactory.createInstanceOfC();
}
public void someMethod(){
this.comp.sayHello();
}
......
}
特點：
每次運行時，MyFactory可根據(jù)配置文件XML中定義的C子類實現(xiàn)，通過createInstanceOfC()生成C的具體實例。
使用Ioc依賴性注射( Dependency Injection )實現(xiàn)Picocontainer如下，B類如同通常POJO類，如下：
public class B{
private C comp;
public B(C comp){
this.comp = comp;
}
public void someMethod(){
this.comp.sayHello();
}
......
}
假設C接口/類有有一個具體實現(xiàn)CImp類。當客戶端調(diào)用B時，使用下列代碼：
public class client{
public static void main( String[] args ) {
DefaultPicoContainer container = new DefaultPicoContainer();
container.registerComponentImplementation(CImp.class);
container.registerComponentImplementation(B.class);
B b = (B) container.getComponentInstance(B.class);
b.someMethod();
}
}
因此，當客戶端調(diào)用B時，分別使用工廠模式和Ioc有不同的特點和區(qū)別：
主要區(qū)別體現(xiàn)在B類的代碼，如果使用Ioc，在B類代碼中將不需要嵌入任何工廠模式等的代碼，因為這些工廠模式其實還是與C有些間接的聯(lián)系，這樣，使用Ioc徹底解耦了B和C之間的聯(lián)系。
使用Ioc帶來的代價是：需要在客戶端或其它某處進行B和C之間聯(lián)系的組裝。
所以，Ioc并沒有消除B和C之間這樣的聯(lián)系，只是轉(zhuǎn)移了這種聯(lián)系。
這種聯(lián)系轉(zhuǎn)移實際也是一種分離關注，它的影響巨大，它提供了AOP實現(xiàn)的可能。
Ioc和AOP
AOP我們已經(jīng)知道是一種面向切面的編程方式，由于Ioc解放自由了B類，而且可以向B類實現(xiàn)注射C類具體實現(xiàn)，如果把B類想像成運行時的橫向動作，無疑注入C類子類就是AOP中的一種Advice，如下圖：
通過下列代碼說明如何使用Picocontainer實現(xiàn)AOP，該例程主要實現(xiàn)是記錄logger功能，通過Picocontainer可以使用簡單一行，使所有的應用類的記錄功能激活。
首先編制一個記錄接口：
public interface Logging {
public void enableLogging(Log log);
}
有一個LogSwitcher類，主要用來激活具體應用中的記錄功能：
import org.apache.commons.logging.Log;
public class LogSwitcher
{
protected Log m_log;
public void enableLogging(Log log) {
m_log = log;
m_log.info("Logging Enabled");
}
}
一般的普通應用JavaBeans都可以繼承這個類，假設PicoUserManager是一個用戶管理類，代碼如下：
public class PicoUserManager extends LogSwitcher
{
..... //用戶管理功能
}
public class PicoXXXX1Manager extends LogSwitcher
{
..... //業(yè)務功能
}
public class PicoXXXX2Manager extends LogSwitcher
{
..... //業(yè)務功能
}
注意LogSwitcher中Log實例是由外界賦予的，也就是說即將被外界注射進入，下面看看使用Picocontainer是如何注射Log的具體實例的。
DefaultPicoContainer container = new DefaultPicoContainer();
container.registerComponentImplementation(PicoUserManager.class);
container.registerComponentImplementation(PicoXXXX1Manager.class);
container.registerComponentImplementation(PicoXXXX2Manager.class);
.....
Logging logging = (Logging) container.getComponentMulticaster();
logging.enableLogging(new SimpleLog("pico"));//激活log
由上代碼可見，通過使用簡單一行l(wèi)ogging.enableLogging()方法使所有的應用類的記錄功能激活。這是不是類似AOP的advice實現(xiàn)？
總之，使用Ioc模式，可以不管將來具體實現(xiàn)，完全在一個抽象層次進行描述和技術架構，因此，Ioc模式可以為容器、框架之類的軟件實現(xiàn)提供了具體的實現(xiàn)手段，屬于架構技術中一種重要的模式應用。
--sunfruit
講述了SOA的基本概念，理論上讓大家混個臉熟
Web service已經(jīng)不再是新婚的娘子。眾多企業(yè)都已經(jīng)創(chuàng)建各種實驗性Web Services 項目，事實證明，這項新興的分布式計算技術確實能夠降低集成和開發(fā)的成本。另外，一些關鍵的Web Services標準紛紛制定，強安全（robust security）和管理方面的產(chǎn)品也陸續(xù)問世。對于志向遠大的企業(yè)來說，他們已經(jīng)在考慮下一步了。
對大多數(shù)公司來說，下一步要考慮的不再是點對點的應用，而是Web services在企業(yè)間以及業(yè)務伙伴間更為寬廣的應用。這種技術的變遷需要更松散耦合、面向基于標準的服務的架構。這樣一個架構要求對IT在組織中的角色有新的觀點和認識，而不僅僅是一種實現(xiàn)方法。通過對業(yè)務的敏捷反應，企業(yè)可以得到實實在在的回報，而要達到這一點，面向服務架構設計師的角色非常關鍵。除此之外，潛在的回報更是不可勝數(shù)－分布計算技術能夠保證對業(yè)務需求足夠靈活的反應，而這種業(yè)務上的敏捷正是各公司夢寐以求而目前還遙不可及的。
分布式計算將網(wǎng)絡上分布的軟件資源看作是各種服務。面向服務架構是一種不錯的解決方案。但這種架構不是什么新思想；CORBA和DCOM就很類似，但是，這些過去的面向服務架構都受到一些難題的困擾：首先，它們是緊密耦合的，這就意味著如分布計算連接的兩端都必須遵循同樣API的約束。打比方說，如果一個COM對象的代碼有了更改，那么訪問該對象的代碼也必須作出相應更改。其二，這些面向服務架構受到廠商的約束。Microsoft控制DCOM自不必說，CORBA也只是一個偽裝的標準化努力，事實上，實現(xiàn)一個CORBA架構，經(jīng)常都是在某個廠商對規(guī)范的實現(xiàn)上進行工作。
Web services是在改進DCOM和CORBA缺點上的努力。今天應用Web services的面向服務架構與過去不同的特點就在于它們是基于標準以及松散耦合的。廣泛接受的標準（如XML和SOAP）提供了在各不同廠商解決方案之間的交互性。而松散耦合將分布計算中的參與者隔離開來，交互兩邊某一方的改動并不會影響到另一方。這兩者的結合意味著公司可以實現(xiàn)某些Web services而不用對使用這些Web services的客戶端的知識有任何了解。我們將這種基于標準的、松散耦合的面向服務的架構簡稱為SOA。
SOA的強大和靈活性將給企業(yè)帶來巨大的好處。如果某組織將其IT架構抽象出來，將其功能以粗粒度的服務形式表示出來，每種服務都清晰地表示其業(yè)務價值，那么，這些服務的顧客（可能在公司內(nèi)部，也可能是公司的某個業(yè)務伙伴）就可以得到這些服務，而不必考慮其后臺實現(xiàn)的具體技術。更進一步，如果顧客能夠發(fā)現(xiàn)并綁定可用的服務，那么在這些服務背后的IT系統(tǒng)能夠提供更大的靈活性。
但是，要得到種強大和靈活性，需要有一種實現(xiàn)架構的新方法，這是一項艱巨的任務。企業(yè)架構設計師必須要變成“面向服務的架構設計師”，不僅要理解SOA，還要理解SOA的實踐。在架構實踐和最后得到的架構結果之間的區(qū)別非常微妙，也非常關鍵。本文將討論SOA的實踐，即：面向架構的設計師在構建SOA時必須要做的事情。
SOA的原則
SOA是一種企業(yè)架構，因此，它是從企業(yè)的需求開始的。但是，SOA和其它企業(yè)架構方法的不同之處在于SOA提供的業(yè)務敏捷性。業(yè)務敏捷性是指企業(yè)對變更快速和有效地進行響應、并且利用變更來得到競爭優(yōu)勢的能力。對架構設計師來說，創(chuàng)建一個業(yè)務敏捷的架構意味著創(chuàng)建這樣一個IT架構，它可以滿足當前還未知的業(yè)務需求。
要滿足這種業(yè)務敏捷性，SOA的實踐必須遵循以下原則：
* 業(yè)務驅(qū)動服務，服務驅(qū)動技術
從本質(zhì)上說，在抽象層次上，服務位于業(yè)務和技術中間。面向服務的架構設計師一方面必須理解在業(yè)務需求和可以提供的服務之間的動態(tài)關系，另一方面，同樣要理解服務與提供這些服務的底層技術之間的關系。
* 業(yè)務敏捷是基本的業(yè)務需求
SOA考慮的是下一個抽象層次：提供響應變化需求的能力是新的“元需求”，而不是處理一些業(yè)務上的固定不變的需求。從硬件系統(tǒng)而上的整個架構都必須滿足業(yè)務敏捷的需求，因為，在SOA中任何的瓶頸都會影響到整個IT環(huán)境的靈活性。
* 一個成功的SOA總在變化之中
SOA工作的場景，更象是一個活的生物體，而不是象傳統(tǒng)所說的“蓋一棟房子”。IT環(huán)境唯一不變的就是變化，因此面向服務架構設計師的工作永遠不會結束。對于習慣于蓋房子的設計師來說，要轉(zhuǎn)向設計一個活的生物體要求嶄新的思維方式。如下文所寫的，SOA的基礎還是一些類似的架構準則。
SOA基礎
在IT行業(yè)有兩個越來越普遍的發(fā)展方向，一個是架構方面的，一個是方法學方面的，面向服務的架構設計師可以從中有所收獲。第一個就是MDA（模型驅(qū)動架構），由提出CORBA的OMG模型提出。MDA認為架構設計師首先要對待創(chuàng)建的系統(tǒng)有一個形式化的UML（也是由OMG提出）的模型。MDA首先給出一個平臺無關的模型來表示系統(tǒng)的功能需求和use cases，根據(jù)系統(tǒng)搭建的平臺，架構設計師可以由這個平臺無關的模型得到平臺相關的模型，這些平臺相關模型足夠詳細，以至于可以用來直接生成需要的代碼。
MDA的核心就在于在設計階段系統(tǒng)就已經(jīng)完全描述，這樣，在創(chuàng)建系統(tǒng)的時候，幾乎就沒有錯誤解釋的可能，模型也就可以直接生成代碼。但MDA有一些局限性：首先，MDA假設在創(chuàng)建模型之前，業(yè)務需求已經(jīng)全部描述，而這一點，在當前典型的動態(tài)業(yè)務環(huán)境中幾乎是不可能的。第二，MDA沒有一個反饋機制。如果開發(fā)人員對模型有需要改動的地方，并沒有提供給他們這么一個途徑。
SOA的另一個基礎是敏捷方法（AM），其中非常有名的方法是極限編程（XP）。象XP這樣的AM提供了在需求未知或者多變的環(huán)境中創(chuàng)建軟件系統(tǒng)的過程。XP要求在開發(fā)團隊中要有一個用戶代表，他幫助書寫測試來指導開發(fā)人員的日常工作。開發(fā)團隊中的所有成員都參與到設計之中，并且設計要盡量小并且非形式化。AM的目標是僅僅創(chuàng)建用戶想要的，而不是在一些形式化模型上耗費工作量。AM的核心思想就在于其敏捷性－處理需求變更的敏捷性。AM的主要弱點是其規(guī)模上的限制，例如，XP在一個小團隊和中型項目中效果不錯，但是當項目規(guī)模增大時，如果沒有一個一致的清晰的計劃，項目成員很難把握項目中的方方面面。
從表面看來，MDA和AM似乎是相對立的－MDA假定需求是固定的，而AM恰恰相反。MDA的中心是形式化的模型，而AM恰恰要避開它們。但是，我們還是決定冒險把這些不同方法中的一些元素提取出來，放入到一個一致的架構實踐中。
在SOA中有三個抽象層次，按照SOA的第一條準則：業(yè)務驅(qū)動服務、服務驅(qū)動技術。AM將業(yè)務模型直接和實踐連接起來，表現(xiàn)在平臺相關的模型之中。MDA并沒有把業(yè)務模型和平臺無關模型分開來，而是把平臺無關模型做為起點。SOA必須連接這些模型，或者說抽象層次，得到單一的架構方法。我們將從五個視圖的架構實現(xiàn)方法來實現(xiàn)這個連接。
SOA的五視圖實現(xiàn)方法
企業(yè)架構設計師發(fā)現(xiàn)他們的職業(yè)非常有競爭力并且值得驕傲，因為他們要從很多方面來通盤考慮IT系統(tǒng)。Kruchten（RUP的開發(fā)負責人）將這些方面提取出來，在應用到SOA時，我們稱為五視圖實現(xiàn)方法（five-view approach）。
四個方框表示對一個架構的不同審視方法，分別代表不同的涉眾（stakeholder）。弟五個視圖，use-case視圖涵蓋了其它視圖，在架構中扮演的是一個特殊的角色。部署視圖將軟件映射到底層平臺和相關硬件上，是系統(tǒng)部署人員對架構的視圖；實現(xiàn)視圖描述了軟件代碼的組織，是從開發(fā)人員角度出發(fā)的視圖；業(yè)務分析人員則利用過程視圖進行工作，它描述的是軟件系統(tǒng)的運行時特性。最后，邏輯視圖表示的是用戶的功能需求。在SOA中，面向服務的架構必須能夠以use-case視圖中的用例將用戶連接到服務，將服務連接到底層的技術。
為了表示面向?qū)ο蟮募軜嬍侨绾喂ぷ髟谶@些視圖之上，讓我們將他們置于SOA元模型的上下文之中。SOA中兩個領域存在重疊：由業(yè)務模型和服務模型表示的業(yè)務領域和由服務模型及平臺相關模型表示的技術領域（兩個領域共享服務模型）。業(yè)務用戶通過邏輯視圖和過程視圖處理粗粒度的業(yè)務服務，根據(jù)變化的業(yè)務需求，按照需要將它們安排在過程之中。另一方面，技術專家的工作是創(chuàng)建并維護服務和地層技術之間的抽象層。表示這些服務的中間模型，起到的是軸心的作用，業(yè)務以它為中心進行。
SOA元模型從MDA中繼承平臺無關模型和平臺相關模型，但是添加了AM和用戶交互以及敏捷的反饋這兩部分，后者通過橢圓之間的雙向箭頭來表現(xiàn)。類似地，元模型通過引入由中心的服務模型提供的中間層抽象解決了AM在伸縮性方面的問題。這樣，服務模型中的任何需求的變化，都會反映到用戶每天的業(yè)務處理中。同樣，由于底層技術是模型驅(qū)動的，技術專家也可以根據(jù)這些變化的需求迅速而有效地作出應變。
SOA實踐和過去解決企業(yè)架構傳統(tǒng)方式的不同之處就在于其對敏捷性的支持。如前所說，SOA的第三條原則就在于它總在變化之中。這種恒在的變化性環(huán)境是SOA實踐的基石。如圖所示，涉眾（stakeholders，譯者注：RUP中也有這個詞，表示軟件開發(fā)中涉及到的各種角色如：用戶、設計人員、開發(fā)人員乃至測試人員等等。）在一個必需的基礎上影響到整個架構的變化。在當技術專家在每天的日常工作中不斷對變化的業(yè)務需求作出響應的這種情況下，設計階段和運行階段之間的界限變得模糊起來，很難清晰地分離這兩個階段。
剩下的部分
我們已經(jīng)為面向服務的架構提供了一個高層次的框架，其中MDA和AM的元素幫助工具的使用者來創(chuàng)建和維護SOA。但是，SOA中還缺少一些內(nèi)容－那就是軟件開發(fā)商和專業(yè)的服務組織必需提供的。理想情況下，開發(fā)商必需提供面向服務的業(yè)務流程、工作流以及服務的協(xié)調(diào)工具和服務；另外，能夠以一種敏捷的、平臺無關的方式充分反映業(yè)務服務的建模工具也是必須的；技術專家必須配備可以從模型中自動生成代碼，并在代碼變化時更新模型的工具，最后，開發(fā)商必須提供支持SOA的軟件，幫助面向服務的架構設計師以一種可信并且可伸縮的方式創(chuàng)建位于服務和底層技術之間的抽象層次。幸運的是，這方面的產(chǎn)品即將上市。
另外，最重要的就是貫穿本文的自頂而下的SOA實現(xiàn)方法了。今天關于Web services的大部分思考都是自底而上的：“這是如何創(chuàng)建Web services的方法，現(xiàn)在，我們來使用它們集成吧”，對Web services技術的這種方法是偉大的第一步，因為它可以驚人地降低集成的開銷，這是現(xiàn)在的技術管理人員最樂意見到的了。但當經(jīng)濟進一步發(fā)展，IT走出低谷，企業(yè)會尋求IT的幫助來提高組織戰(zhàn)略意義上的核心價值。使用面向服務的架構，IT可以提供給企業(yè)實現(xiàn)業(yè)務敏捷性的這樣一個框架。