Java企業級版本，或者說Java EE(以前叫J2EE),對於程式開發伺服器端的應用來說是一個強大的但卻又過於複雜的的平台。從它誕生之日起，過於複雜一直是對使用Java EE猶豫不決的一個重要因素。在JavaWorld的以前的一篇文章”簡化之路”中，我指出了那些讓Java EE應用變複雜的因素，其中很多都是與當前的EJB 2.1規範有關。
在過去的三年中，Java開放原始碼社區，Java社區進 程（JCP）以及主要的Java EE供應商，一直致力於讓Java EE更簡單。舉例來說：新的設計範例，比如POJO服務，服務攔截器和依賴注入，已經可以在實際應用中用來簡化Java EE的開發了。還有，新的工具和架構，比如Hibernate, AOP(aspect-oriented programming，面向方面編程)，Struts,Xdoclet和Spring, 也已經被廣泛用於同一目的。
簡化不是功能的減少
簡化一個編程模型並沒有減少它的功能。簡化只是把複雜的邏輯隱藏到了架構代碼或可重用的組件中去了。根本上，它是把複雜的東西從需要應用開發人員直接管理的地方轉移到了大多數開發人員看不到的地方。
上述的模板和工具讓初學者更容易上手，同時也提高了有經驗的Java開發人員的生產力，現在它們正在被JCP合并到下一代的Java EE標準中（比如：EJB 3.0）。由Java開發人員Raghu Kodali最近所做的研究顯示：將Java EE的樣本程式RosterApp從EJB 2.1轉到EJB 3.0可以減少百分之五十以上的代碼。
Java注釋是 EJB3.0背後的關鍵，它將POJO服務，POJO持久化和依賴注入一起綁定為一個完整的企業級中介軟體解決方案。這篇文章中，我使用了一個樣本應用： JBoss EJB 3.0 TrailBlazer，來示範使用注釋開發輕量級的EJB 3.0 POJO應用。TrailBlazer的應用使用EJB 3.0中不同的工具和API重複實現了一個投資計算機。樣本程式完全可以在JBoss 應用伺服器4.0.3版本中運行，並且與最新的EJB 3.0標準完全相容（完成時）。
讓我們來開始體驗一下注釋驅動編程模型的好處吧。
EJB 3.0的注釋驅動編程模型
從開發人員的觀點來看，EJB 3.0廣泛地使用了Java 注釋.注釋有兩個關鍵優勢：它們取代了過多的XML設定檔並且消除了嚴格組件模型需求。
注釋 vs XML
基於XML的布署描述和注釋一起都可以用來在Java EE應用中佈建服務的相關屬性。它們的區別在於：XML文檔是與代碼分開處理的，特別是在運行時刻，而注釋是與代碼編譯在一起的並被編譯器檢查的。對於開發人員來說這就有了一些重要的含義，正如我下面所列出的：
o冗長：XML設定檔是出了名的冗長的。為了配置代碼，XML檔案必須複製許多資訊：比如代碼中類名字和方法名字。Java注釋則不同，它是代碼的一部分，不需要額外的引用就可以指明配置資訊。
o強壯性：在XML檔案中重複的代碼資訊引入了多處出錯的可能。比如,如果你寫錯了方法的名字，那應用直到運行時刻才會出錯垮掉。也就是說，XML設定檔的強壯性就不如注釋，注釋是被編譯器檢查的，並和其它代碼一起被處理的。
o靈活性：既然XML檔案是在代碼之外被單獨處理的，那也就是說基於XML的配置資訊不是“寫入程式碼”的，是可以以後修改的。部署的靈活性對系統管理員來說是非常非常重要的特性。
注釋是簡單易用的，已證明對大多數應用來說足夠了。XML檔案更複雜，但能被用來處理更進階的問題。EJB 3.0允許你通過注釋來配置大多數的應用。EJB 3.0也支援用XML檔案來覆蓋預設的注釋，及配置像資料庫聯結這樣的外部資源。
除了替換和簡化XML描述符，注釋也允許我們廢除困擾EJB 1.x, EJB 2.x的嚴格組件模型。
POJO vs 嚴格組件
EJB 組件是容器管理(container-managed)的對象。容器在運行時刻操作Bean的狀態和行為。為了讓行為發生，EJB 2.1規範定義了一個Bean必須遵守的嚴格的組件模型。每一個EJB類必須從某一種抽象類別中繼承，並為容器提供了回調的鉤子。既然Java只支援單繼 承，嚴格組件模型就限制了開發人員使用EJB組件建立一個複雜物件結構的能力。當把複雜的應用資料對應到實體 Bean中的時候，正如我們在第二部分中看到的，這會成為一個很大的問題。
在EJB 3.0中，所有的Container Service都可以通過使用注釋的POJO應用來配置和交付。大多數情況下，並不需要特殊的組件類。讓我們通過JBoss EJB 3.0 TrailBlazer樣本看一下如何在EJB 3.0中使用注釋。
開發藕合鬆散的服務物件
像Java EE這樣的企業級中介軟體的一個最重要的好處是允許開發人員使用藕合鬆散的組件來開發應用。這些組件僅僅通過他們自己發布的商業介面來藕合。因此這些組件的實 現類可以在不改變應用其餘部分的情況下改變自己的實現。這將會使應用更加強壯，更容易測試，更易移植。EJB 3.0使得在POJO中建立藕合鬆散的商業組件變得更簡單了。
Session bean
在EJB 3.0應用中，藕合鬆散的服務元件的典型應用是Session Bean。一個Session Bean至少有一個介面（也就是：商業介面），其它應用組件通過它獲得服務。下面的代碼為我們的投資計算機服務提供了商業介面。它只有一個方法，根據給定 的起始年齡，終止年齡，增長率，月存金額，計算出總投資額。
public interface Calculator { public double calculate (int start, int end, double growthrate, double saving);}
Session bean類簡單地實現了商業介面。你必須通過使用Stateless或Stateful注釋來告訴EJB 3.0容器這個POJO類是一個Session Bean。有狀態(Stateful)的session bean在不同的服務要求間維護著客戶的狀態。相反地，對於無狀態(Stateless)的session bean，每次的請求都是被隨機挑選的session bean執行個體處理的。這些行為是與EJB 2.1規範中的有狀態和無狀態session bean的定義是一致的。EJB 3.0容器算出何時執行個體化Bean對象，並通過商業介面讓其可用。下面是session bean實作類別的代碼：
@Statelesspublic class CalculatorBean implements Calculator { public double calculate (int start, int end, double growthrate, double saving) { double tmp = Math.pow(1. + growthrate / 12., 12. * (end - start) + 1); return saving * 12. * (tmp - 1) / growthrate; }}
你也可以為一個session bean指明多個介面－一個為本地客戶服務，一個為遠程客戶服務。只要使用@Local和@Remote注釋來區分。下面的代碼片斷顯示了同時實現了本地 和遠程介面的CalculatorBean。如果你沒有@Local和@Remote注釋，session bean介面預設為本地介面。
@Stateless@Local ({Calculator.class})@Remote ({RemoteCalculator.class})public class CalculatorBean implements Calculator, RemoteCalculator { public double calculate (int start, int end, double growthrate, double saving) { double tmp = Math.pow(1. + growthrate / 12., 12. * (end - start) + 1); return saving * 12. * (tmp - 1) / growthrate; } public String getServerInfo () { return "This is the JBoss EJB 3.0 TrailBlazer"; }}
Session bean使用者通過JNDI得到bean的一個存根（Stub）對象。容器所提供的存根對象實現了session bean的商業介面。所有針對存根的調用都被引向了容器，由容器調用相應的實作類別中的介面。對於有狀態的的session bean，你必須自己在用戶端緩衝存根對象，這樣在每次的後續調用時，容器才知道要提供相同的的bean執行個體。下面的片斷顯示如何調用session bean.在後面，你將會學到擷取存根對象的更簡單的方法。
InitialContext ctx = new InitialContext();cal = (Calculator) ctx.lookup(Calculator.class.getName());double res = cal.calculate(start, end, growthrate, saving);
Session bean生命週期的管理
為達到藕合鬆散的目的，應用把session bean執行個體的建立、緩衝、銷毀全部交給EJB 3.0容器（也就是，反向控制設計模式）。應用只和bean的商業介面打交道。
但如果應用需要對session對象更好的控制呢？比如說，應用可能需要在建立session bean的時候初始化資料庫聯結，而在銷毀bean時關閉外部的聯結。上述這些，你都可能通過在bean類中定義生命週期的回調方法來實現。這些方法將會 被容器在生命週期的不同階段調用（如：建立或銷毀時）。通過使有下面所列的注釋，EJB 3.0允許你將任何方法指定為回調方法。這不同於EJB 2.1，EJB 2.1中，所有的回調方法必須實現，即使這是空的。EJB 3.0中，bean可以有任意數量，任意名字的回調方法。
o@PostConstruct:當bean對象完成執行個體化後，使用了這個注釋的方法會被立即調用。這個注釋同時適用於有狀態和無狀態的session bean。
o@PreDestroy:使用這個注釋的方法會在容器從它的對象池中銷毀一個無用的或者到期的bean執行個體這前調用。同時適用於有狀態和無狀態的session bean.
o@PrePassivate:當一個有狀態的session bean執行個體空閑過長的時間，容器將會鈍化它，並把它的狀態儲存下來。使用這個注釋的方法會在容器鈍化bean執行個體之前調用。適用於有狀態session bean。
o＠PostActivate:當用戶端再次使用已經被鈍化的的有狀態session bean時，新的執行個體被建立，狀態被恢複。使用此注釋的session bean會在bean的啟用完成時調用。
o@Init:這個注釋指定了有狀態session bean初始化的方法。它區別於@PostConstruct注釋在於：多個@Init注釋方法可以同時存在於有狀態session bean 中，但每個be
註：以上內容來自網路，本人不承擔連帶責任
文章轉自：http://java.ok6.org/ejb/200610/750.html
