使用EJB 3.0簡化企業級Java開發一

2019-11-18 12:33:11

字體：大中小

來源：轉載

供稿：網友

　　概述
　　
　　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中，所有的容器服務都可以通過使用注釋的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

上一篇：EJB最佳實踐：構建更好的異常處理框架

下一篇：深入掌握Java技術 EJB調用原理分析二