使用Ant和Weblogic開發EJB

2019-11-18 12:35:55

字體：大中小

來源：轉載

供稿：網友

　　無論是設計還是實施EJB，都是一件復雜的事情。僅在實施EJB的各階段中要用的為數不少的應用服務器，就會使事情變得很糟。然后，假如我們使用BEA的Weblogic應用服務器再配合 http://jakarta.apache.org/ant' TARGET=_blank>　 Ant 就會使一切變得是那么的輕易。
　　Ant是一個構造基于Java應用程序的開源工具，是Apache Jakarta工程的一部分。Ant使用XML作為構造描述語言，這種描述文件由一些有著有限狀態的target組成，每一個target要么成功要么失敗。開發者或者構造治理者定義各屬性，在ant的配置文件中將各種任務轉化成一系列target，并定義各target之間的依靠關系。在ONJava.com站點上通過http://www.onjava.com/pub/au/133' TARGET=_blank>David Thomson 寫的http://www.onjava.com/pub/a/onjava/2001/02/22/open_source.Html' TARGET=_blank>　overview of Ant 我們可以找到更多的有用信息。
　　Ant的開發者提供一系列能夠構造部署EJB的任務，一旦完成，就能夠應用到weblogic4.5,5.1,6.0中，同樣也能夠創建可以在其它應用服務器中被處理的通用EJB包。只要通過適當的配置一個工程的ant文件，就可以使用<ejbjar>任務和<weblogic>元素等相似的五到八行xml語句構造出成百的EJB。
　　本文中是用Weblogic5.1作為服務器，但是只要精心設計，開發者或者構造治理者也可以使用其它的服務器，部署中的EJB和Weblogic任務標簽是可擴展的。用戶要非凡關注的是，在下一個版本Ant 1.4中，它將支持iplanet,Borland應用服務器以及Jboss。但是不支持在　nightly builds 上的Ant的一些可選任務以及其它的服務器。感愛好的讀者還可以從http://marc.theaimsgroup.com/?l=ant-user&r=1&w=2(search the Ant-user mailing lists)上找到關于Ant和EJBs以及iPlanet的更多的有用信息。
　　本文將分四個部份對使用Ant及Weblogic服務器開發EJB進行描述。第一部分描述怎樣使用<ejbjar>任務及<weblogic>元素來配置一個工程。第二部分用實例講述怎樣在一個工程中部署構造一系列的EJB。第三部分教你怎樣針對單個EJB來寫一個Ant任務。最后，在第四部分中還會涵蓋一些更為有用的可選功能，也有一些提示與技巧。
　　由于Ant使用自己的命名協定，所以可能導致與其它的EJB開發工具產生沖突。本文解決了一些已知的沖突。但是隨著更多的工具的使用，將會有更多的沖突產生。在http://jakarta.apache.org/ant/manual/index.html' TARGET=_blank> Ant document．tion 上可以找到更多的有關在其它集成開發環境上使用Ant的細節。
　　
　　命名模式
　　使用Weblogic的開發者要想使用Ant中<ejbjar>任務的強大功能，必需繞過一些陷井。實際上Ant配置文件中棘手的代碼是很少的，也就那么七八行（不包含屬性配置信息等）。一些有著幾個月或者是幾年經驗的開發者們往往輕易的就開始了一個工程，但是他們卻發現通過集成Ant卻讓事情變得更糟了。對于這些人，希望本文能給于他們足夠的啟發，讓他們重新審閱一下他們的工程，從而走出迷茫的誤區。即使他們的工程將不打算使用Ant，設計一個好的工程結構對任何人在今后相當長的一段時間內都是有好的幫助的。
　　由于以前的EJB的例子及書籍（尤其是Monson_haefel’s的有關EJB的書）中的規定，下面的java類和模塊命名慣例被開發者廣泛使用。
　　• 執行類--<Bean名>Bean.java
　　• Home接口--<Bean名>Home.java
　　• Remote接口--<Bean名>.java
　　• 主鍵類--<Bean名>PK.java
　　鑒于以上所見，不能輕易的找到遵循任何命名協定和正當組織的部署描述符。局部來講，這是由于容器把約束放置到描述符名上造成的，但是這可以通過腳本或簡易EJB編譯程序來解決。 Ant的　EJB任務需要好的組織來引導。沒有一個標準的組織，EJB工程就會難以維持，同時隨著工程的進展，描述符也會分散于整個文件系統中。Ant的模式為很多典型的無結構的java工程提供結構化。
　　在開始，我列出工程組織的一些關于使用<ejbjar>的規則：
　　所有的EJB類文件都必需遵循下面的標準的類命名規定，使用 bean名前綴。例如，不能用像IThumbMyNoseAtNamingConventions.java這種方式來命名，而是<Bean名>Bean.java這種形式。這雖然枯燥但卻實用。
　　所有的EJB描述符都遵循這樣的類名約定，在描述符前使用bean名作為前綴。
　　描述符協定并不像所說的那樣嚴格。所有的描述符都以<Bean Name>開始(如:Account-ejb-jar.xml)。在Weblogic部署描述符中，容器治理的持久(CMP)的描述符名要求是明確的。但這并下要求有什么要改變，僅僅是文件名或者文件系統要遵循這個約定。在其它的一些章節我們也會討論到這種潛在的命名協定沖突。
　　描述符從他們自己的目錄使用bean名來得到每一個bean。
　　這條規則沒有一二兩點那么重要，便是它確實起到了良好的作用。
　　這些規則都不是必需的。
　　一些大的復雜的系統可能還要求一些當前的功能中不能滿足的特定需求，或者有滿足的需求但是本文卻沒有涉及到。對于這些項目，命名模式及工程布局可能沒有應用。任何工程經過足夠的努力都能使用<ejbjar>；使用這目經過規則會使<ejbjar>變得很簡單。
　　
　　布局
　　工程布局對于有效的編碼及構造治理都是很重要的。創建模塊化的文件系統組織會使打包及改動代碼都很輕易實現。Java的包系統就是這種設計概念的一個例子。在整個工程會議中概念圖將受益于好的布局。在CVS或者其它的版本控制系統中治理代碼會使問題更簡單。
　　客觀的說，假如不是這些約定，<ejbjar>任務就會變得像ant的其它任務一樣，沒有這樣大的功能。工程越接近這些規則的需求，ant文件的代碼就會越少。假如不遵循這一規則，ant文件就不得不描述及定義怎樣來構造每一個EJB。使用這一約定，<ejbjar>任務就變得非常強大，而這卻只需很少的工作量。
　　下面是一個工程布局的樣例：
　　
　　bigPRoject/
　　　Java/
　　　　　...
　　　　　　　com/duffbrew/Account.java
　　　　　　　com/duffbrew/AccountHome.java
　　　　　　　com/duffbrew/AccountBean.java
　　　descriptor/
　　　　　...
　　　　　　　Account/
　　　　　　　 Account-ejb-jar.xml
　　　　　　　　　　　 Account-weblogic-ejb-jar.xml
　　　　　　　　　　　 Account-weblogic-cmp-rdbms-jar.xml
　　　build/
　　　　　...
　　　deploy/
　　　　　Account/
　　　　　　Account.jar
　　　 doc/
　　　 lib/
　　
　　這個工程構架遵循以上所有提到的規則。Account EJB 代碼模塊都被適當的命名。描述符文件在它們自己的目錄中，也遵循代碼模塊的命名模式。
　　
　　構造所有的EJB
　　下面就是<ejbjar>任務的大概樣子。其中${weblogic.classpath}包含Weblogic需要的服務包、jar包及類目錄。
　　
　　<ejbjar srcdir="build"
　　　　　　　　　　descriptordir="descriptor">
　　　　　　　　　　<weblogic destdir="build/deploy"
　　　　　　　　　　　classpath="${weblogic.classpath}:build"
　　　　　　　　　　　　　　　　　　　compiler="javac"/>
　　　　　　　　　　<include name="**/*-ejb-jar.xml"/>
　　　　　　　　　　<exclude name="**/*weblogic*.xml"/>
　　</ejbjar>
　　
　　八行代碼就可以編譯任意數量的EJB(在實際的ant文件中，還要有其它的一些屬性要配置，所以實際代碼行數會比這里的多。為了不浪費篇幅，本文已經明確的定義了這些屬性。)。整個操作主要由兩個主要的任務來完成 :<ejbjar>和<weblogic>。在document．tion列表中還有更多屬性和嵌套元素，但是這里只需要上面這些就足夠了。<ejbjar>構造通用的EJB，為指定容器的編譯及部署作預備。<weblogic>在通用的EJB上運行weblogic.ejbc，為weblogic容器部署作預備。這里沒有定義特定類和模塊的屬性。為了得到更好的性能，編譯器屬性要用Jikes替換成下面的樣子:
　　compiler="jikes -nowarn"
　　Weblogic.ejbc將用到’no_warn’這個參數。由于它將Jikes傳來的警告當作錯誤處理，這將有可能構造EJB失敗。
　　通過這種方式，編譯100個EJB所化的時間并不是簡單的疊加。經驗表明編譯EJB是要化費大量的時間。這里的性能是非常好的。例如，編譯一個有700個類文件和70個EJB的工程可以用不到100分鐘的時間完成(在奔III800內存512M的機器上)。但是假如用javac命名編譯同樣的工程則要30到40分鐘。但是在兩種情況下，對單個類的編譯都在30秒以下(jikes版本會化更少的時間)。
　　
　　僅編譯單個Bean
　　通過使用命令行或是屬性文件中指定屬性，就可以對指定的單個EJB進行編譯。
　　
　　<ejbjar srcdir="build" descriptordir="descriptor/${bean.name}"> <weblogic destdir="build/${bean.name}/${bean.name}.jar" classpath="${weblogic.classpath}:build" keepgenerated="true" compiler="javac"/> <include name="**/*-ejb-jar.xml"/> <exclude name="**/*weblogic*xml"/>
　　 </ejbjar>
　　
　　以上的代碼片段已經說明了用<ejbjar>和<weblogic>來創建，編譯以及放置一個EJB到${bean.name}指定的目錄。利用這些簡單的代碼片段就能夠不重新編譯整個系統。應該注明的是靜態依靠或者類似靜態依靠的在整個依靠檢查時不會考慮重新編譯的。每次都重新編譯整個系統是毫無益處的。
　　
　　技巧與可選功能
　　描述符的差異
　　包括Weblogic在內的一些容器，更希望描述符遵循一個不同于ant任務所要求的那種命名協定。<ejbjar>考慮到這種內在關系，就重新命名并將它們

上一篇：EJB中數據驗證出現在什么地方最合適

下一篇：JavaBeans教程