J2EE（Java 2 Enterprise Edition）平台自從問世以來，就是眾人矚目的焦點。這一方面要歸功於昇陽以及其他協力廠商對於J2EE平台不遺餘力的支援和行銷，但另一方面來說，J2EE平台的技術規格在當時也是頗令人驚豔。它是一個標準化、跨平台的新技術，而且整合以下功能：

這些強大的技術規格如(圖一)所示，在過去的幾年獨領風騷；然而，人的欲望是無止境的。功能面的強大已經無法抵消人們對於複雜度的忍受度，而J2EE平台的確是相當複雜而難以掌握的。

《圖一　J2EE技術規格架構》

J2EE是為了企業級應用程式的需求而設計的，因此功能面講求強大、穩定；付出的代價就是應用程式開發的複雜度。然而，現階段的企業級應用程式除了要求強大與穩定之外，還特別講求時效。以銀行業為例，每當某家銀行要針對某個信用卡客戶群進行優惠專案，隨之而來的結果可能就是要建置一個新的軟體系統來搭配；像這樣的軟體系統，其開發的生命週期一定不長，否則就無法配合銀行的行銷造勢活動。很明顯地，我們需要一個能夠保留J2EE強大穩定的優勢，又能夠讓軟體開發過程更順暢的解決方案。

在接下來的篇幅裡，我將為大家介紹一個叫做「Spring Framework」的J2EE應用程式框架；這個應用程式框架是由幾位業界資深的J2EE專家為了簡化J2EE應用程式開發而量身打造的；而個人在工作上的使用經驗也驗證了Spring Framework的確能夠大幅簡化J2EE應用程式開發的複雜度，相對的增加了產能，也讓我們能夠擁有更多的精力和時間來做更好的系統規劃和設計。

Spring Framework

一位名為Rod Johnson的J2EE專家在2002年10月份出版了一本標題為「Expert One-on-One J2EE Design and Development」的書。這本書主要的內容是對於整個J2EE平台進行的一個「水能載舟，亦能覆舟」式的反省：我們使用J2EE的方式是否正確？Spring Framework的一些設計雛形就這樣的形成了。經過了一年多的開發，Spring Framework 1.0的正式版終於在2004年的春天問世。Spring Framework的軟體授權採用LGPL（註2），也就是我們一般常聽到的開放原始碼授權模式；在這樣的開放模式之下，集結了眾人心血結晶的Spring Framework到底有何過人之處呢？

核心哲學：POJO

POJO是Plain Old Java Object的縮寫，說穿了就是一般的Java Class，而一個Class是一個物件導向軟體系統當中最小的程式單位。Spring Framework的核心哲學，就是希望程式設計師能夠直接利用最單純的方式撰寫一般的Java Class程式。

這麼做到底有什麼好處？

如果您有開發過EJB，應該就很容易瞭解。一個EJB元件最基本的要求就是必須實做某些特殊的程式介面，如在Java當中描述物件規格的一種程式單位，才會被J2EE平台的實作J2EE Container，通常也稱為Application Server辨識為一個合格的EJB元件。而這些介面卻和EJB元件所應該提供的功能一點關係都沒有，純粹只是方便J2EE Container管理和取用的用途；除此之外，EJB元件無法在沒有J2EE Container的狀態下運作，更別說是要除錯了。事實上，EJB元件的除錯一直都是J2EE程式設計師的一個痛：哪怕是功能再簡單的EJB，為了除錯某個小功能，你必須不斷啟動像是IBM出產的Websphere或是BEA出產的Weblogic這樣龐大的怪物，眼睜睜地看著它們耗盡你的系統資源。如果您是一位Java程式設計師，這樣的場景描述是否有觸動了你的心扉，撥動了你深沉的記憶呢？

在這裡，Spring Framework所提供的價值就是，讓你以最單純的Java Class來進行程式開發，卻仍然保留了EJB所提供的宣告式交易（Declarative Transaction）(註3)、宣告式權限控管（Declarative Authentication/Authorization），甚至，分散式交易（Distributed Transaction）的能力。於是，在程式的開發過程當中，你面對的是單純的、可進行單元測試(註4)的POJO；在系統建置的最後階段，再視需要來設定宣告式交易以及宣告式權限控管的功能即可。這樣的作法一樣可以提供能夠和EJB相提並論的功能，但是卻多了很多彈性。

讓我們以生活中簡單實際的例子做個比較吧！在現代的社會中，什麼場合穿什麼衣服是最起碼的常識。我們假設有兩個人，一個人的名字叫做EJB，另外一個人的名字叫做POJO，我們以一個簡單的對照表來比較這兩個人行為上的差異，請參考(表一)。

我們可以看到，EJB不管是面對哪一種場合，都是用一套萬年的西裝來應對，而POJO卻可以自由的針對不同的狀況來選擇不同的衣服，做出最舒適且合時宜的選擇。

軟體系統的開發，有時候就很像穿衣服：不同的場合和場景，有不同的需求和不同的適用性。EJB有其適用的場合，但也有其不適用的場合；而Spring Framework所提供的POJO能針對任何場合選擇其適用的「服裝」的能力，相較之下就多了許多彈性。這彈性到底怎麼來的？又是用什麼技術來做到的呢？接下來，就讓我為大家介紹讓Spring Framework能夠提供如此強大彈性的技術：AOP。

Spring Framework的核心技術：AOP

AOP是Aspect Oriented Programming的簡稱。在目前，所謂的OOP（Object Oriented Programming，物件導向）是軟體開發界的顯學，包括OOA（物件導向系統分析）、OOD（物件導向系統設計）以及OOP（物件導向程式設計）等；但是就像我們所熟知的歷史一樣，這世界上永遠都會有改革進步的力量，而這股力量的名字就是AOP。但是值得注意的一點是：AOP並不是為了推翻我們所熟知的物件導向開發模式而產生的。相反的，AOP是為了要「補強」一些物件導向開發模式所可能帶來的結構性缺陷而誕生的，如(圖二)。

《圖二 AOP技術架構》

在一個典型的物件導向開發的軟體專案當中，我們常常可以看到一個系統按照著物件導向的原則不斷的被細分拆解成模組、元件以及類別。我們可能就此以為，以類別為基礎的系統設計應該就已經是模組化的極致了─其實不然。隨著時間我們會發現，系統中各類別常常會共同擁有某些特徵，例如說交易控管、權限控管以及定時執行排程等所謂的Crosscutting Concern（橫切關鍵點，暫譯）會不斷的重複出現在各類別的程式碼當中。我們會赫然發現，其實可模組化的還有一種系統的Aspect（面向，也是AOP名稱的由來）；將這些Aspect從我們的物件導向程式碼當中抽出，會讓我們的程式碼更簡潔，更具有可設定性（Configurable），能夠達到更進一步的模組化。

就拿剛剛所提到的交易控管作為例子吧！其實交易控管相關的程式碼在各種企業應用系統當中應該是非常普遍的。一段程式碼的邏輯如果有去更動到資料庫的資料，為求資料的完整性，通常都會有交易控管的動作：

如果我們可以將實作1、3、4步驟的程式碼從原來的物件中抽離，這麼一來我們的交易控管機制就可以交由一個專門的程式─稱之為Aspect─來處理了！我們的程式碼可以簡潔許多，系統中做重功的程式碼也變少。至於Aspect所使用的交易控管機制為何？這就讓Aspect來自己來決定了。以此為前提，同一個物件有辦法在不同的情況下，藉由套用不同的Aspect實作來享有各種層次的交易控管能力。例如，在一個簡單的系統中，如果一個物件只處理來自單一的資料來源的資料，我們就可以讓它使用實作JDBC API中預設提供的交易控管機制的Aspect；如果一樣的物件被用在一個複雜的多資料來源環境當中，我們則可以讓它使用實作JTS的Aspec。

圖三當中的交易控管行為隱藏在一個很典型的方法呼叫method Invocation當中，每當UserApplication Instance呼叫aBusinessObject實體中的methodInvocation（）方法時，Spring AOP所隱藏的交易控管機制就會啟動。要讓這個交易控管機制能運作，我們首先得決定要使用的交易管理實作。從(圖三)的例子當中，我們可依不同的情況選用四種選擇：

值得一提的是，Spring Framework使用了XML描述定義檔(註7)來描述物件以及其使用的Aspect之間的關係（Pointcut）(註8)，因此以上四種交易管理機制實作的切換完全不需要重新編譯程式碼；需要修改的就只有XML定義檔而已。關於上述的範例設定檔，有興趣者請參考我在JavaTwo研討會演講的Powerpoint Slides，網址http://www.timerwell.com.tw/event/images/java2.ppt。

另舉一個簡單的例子：定時排程（Cronjob）。有些時候我們會想讓某些程式區段定時的執行；有了Spring AOP的幫助後，撰寫一個定時排程執行的程式變得相當容易，如下：

public class HelloworldJob {
	public void sayHello() {
		System.out.println( "Hello!" );}
}

我們在上述的程式碼當中用了超級典型的入門級程式：Hello World。但是，要讓Spring Framework能夠和這段程式互動，還需要一些設定：

＜beans＞
	＜bean id="hello" class="HelloworldJob"/＞(註10)
	＜bean id="methodInvokingJobDetail" (註11)
class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean"＞
    ＜property name="targetObject"＞＜ref bean="hello"/＞＜/property＞
    ＜property name="targetMethod"＞＜value>sayHello＜/value＞＜/property＞
＜/bean＞
＜bean id="cronTrigger" class="org.springframework.scheduling.quartz.CronTriggerBean"＞
  ＜property name="jobDetail"＞(註12)
    ＜ref bean="methodInvokingJobDetail"/＞
  ＜/property＞
  ＜property name="cronExpression"＞
    ＜value＞0 6 * * 1＜/value＞
  ＜/property＞
＜/bean＞
＜bean class="org.springframework.scheduling.quartz.SchedulerFactoryBean"＞(註13)
  ＜property name="triggers"＞
    ＜list＞
      ＜ref local="cronTrigger"/＞
    ＜/list＞
  ＜/property＞
＜/bean＞
＜/beans>＞

上述的設定會在每天早上六點執行sayHello（）這個方法。是不是很簡單呢？

結論

進步的本質，理論上就是要讓過去是很複雜的事情變得很簡單。Spring Framework就是擁有將複雜的J2EE簡化的這種本質；或者，至少它為J2EE該往哪個方向發展開發出一條路。事實上，根據目前的蛛絲馬跡來看，下一個改版的J2EE將會和目前Spring Framework所提供以POJO為開發重心的開發模式相當類似。所以我們可藉由使用Spring Framework的方式整合J2EE來品嘗未來；至於J2EE未來的發展，就讓我們拭目以待吧！

註1：「分散式交易」存在的目的是希望能夠提供多重資料源的交易控管機制

註2：LGPL：是一種任何人都可以自由下載、使用並且更改該軟體的程式碼的授權模式；商業化的產品可自由的採用LGPL授權的軟體，但是如果有牽涉到修改原始程式碼的部份，則必須貢獻回軟體版權所有人。

註3：「宣告式交易」是一種將交易控管的能力從程式碼中抽出，在程式碼之外另外定義交易控管範圍與機制的一種技術。

註4：單元測試是針對一個類別（Class）所進行的測試。這測試的目的是想確保該類別有滿足設計規格的規範。

註5：Hibernate是非常強大的OR-Mapping工具，聲勢和使用者甚至超越了Java標準的OR-Mapping工具：JDO和EJB CMP Entity Bean。關於Hibernate的資訊，請參考http://hibernate.sf.net/

註6：OR-Mapping是一種讓主流的關聯式資料庫能夠呈現物件導向特性的一種技術。使用這種技術後，在程式設計師眼中，塞進資料庫的不再是一筆一筆的資料，而是一個一個的物件

註7：Spring Framework以XML語法來描述物件之間的相依性，以及物件和Aspect之間的Pointcut定義。

註8：Pointcut是將Aspect和物件結合為一體的機制。Pointcut描述了一個Aspect必須根據哪些規則內嵌到所對應的物件方法中。舉例來說，一個合理的Pointcut描述可能是要求交易控管的Aspect必須內嵌到所有方法名稱（method signiture）以do為開頭的方法，例如doSomething（）

註9：EJB和Spring所提供的「POJO導向應用程式開發」之間最大的差異，也就是適用性的差異。

註10：將HelloworldJob以hello的名稱向Spring註冊

註11：這個Spring所提供的工具類別會藉由AOP method interception的方式來乎叫我們HelloworldJob類別中的sayHello（）方法

註12：cronTrigger中我們指定了cronjob要排程執行的時間Pattern。Unix-like系統的管理員應該對這部份相當熟析。

註13：把cronTrigger加入此類別，完成工作排程註冊的動作。

延 伸 閱 讀

?J2EE的核心規範是 Enterprise Java Beans（EJBs）。EJB依照特性的不同，目前共分為三種，分別是Session Bean、Entity Bean，以及 Message Driven Bean 。其中 Session Bean 與Entity Bean 算是EJB的始祖，這兩種EJB規格在EJB 1.x版本推出時就已經存在，而Message Driven Bean則是出現在EJB 2.0的規格之中。相關介紹請見「Enterprise Java Beans，EJB的三種特性???」一文。 EJB元件在J2EE規範中自成一層，把應用程式的表示層和後端資訊系統捆綁。而其物件可分為會話Beans、實體Beans以及訊息驅動Beans。你可在「?????細說EJB」一文中得到進一步的介紹。 到底什麼是Spring Frameworks。在「作者簡伯宇在JavaTwo 2004演講入門級的Tutorial Powerpoint Slide 」一文為你做了相關的評析。

相關組織網站	昇陽J2EE網站 spring framework官方網站 hibernate官方網站