[計(jì)算機(jī)軟件及應(yīng)用]EJB-3課件

1、EJB 3.0Enterprise JavaBeansEnterprise JavaBeans架構(gòu)是一個(gè)用于開(kāi)發(fā)和部署基于組件的分布式業(yè)務(wù)應(yīng)用的組件架構(gòu)。采用Enterprise JavaBeans架構(gòu)編寫(xiě)的應(yīng)用是可伸縮的、事務(wù)性的、多用戶(hù)安全的。可以一次編寫(xiě)這些應(yīng)用，然后部署于任何支持Enterprise JavaBeans規(guī)范的服務(wù)器平臺(tái)上 Enterprise JavaBeans 是一個(gè)用于分布式業(yè)務(wù)應(yīng)用的標(biāo)準(zhǔn)服務(wù)器端組件模型。服務(wù)器端組件一個(gè)服務(wù)器端組件模型可以定義一個(gè)用來(lái)開(kāi)發(fā)分布式業(yè)務(wù)對(duì)象的架構(gòu)，以便將針對(duì)分布式對(duì)象系統(tǒng)的訪問(wèn)組合起來(lái)，該系統(tǒng)體現(xiàn)了目標(biāo)明確的業(yè)務(wù)邏輯的流動(dòng)性。服務(wù)器端

2、組件模型被用于中間層的應(yīng)用服務(wù)器，此類(lèi)服務(wù)器在運(yùn)行時(shí)管理組件，并使其可以被遠(yuǎn)程客戶(hù)端訪問(wèn)到。依賴(lài)于組件模型，服務(wù)器管理員通過(guò)給屬性設(shè)置特定取值，可以為服務(wù)器端組件聲明事務(wù)、安全，甚至持久化行為。EJB的分類(lèi)有三類(lèi)基本的bean：entity，session，以及message-driven。Entity bean是持久化的，它代表著人，場(chǎng)所，或者事物。Session bean則是客戶(hù)端的延伸，它包含著一個(gè)定義了其他bean如何交互的流程或任務(wù)流。Session bean不是持久化的：它們從客戶(hù)端接受狀態(tài)，并且只在客戶(hù)端需要它們的時(shí)候才存在。Message-driven bean則是用于整合的，

3、它允許其他應(yīng)用使用JMS或別的JCA1.5兼容資源與EJB應(yīng)用進(jìn)行交互。和stateless session bean一樣，message-driven bean不用持久化，并且不維持會(huì)話狀態(tài)。 Session BeanSession bean就像代理一樣為客戶(hù)端管理業(yè)務(wù)流程或任務(wù)，他們是安置業(yè)務(wù)邏輯的理想之所。Session bean時(shí)不必持久化的；在session bean里不存在任何直接映射到數(shù)據(jù)庫(kù)或者存儲(chǔ)于若干session 之間的信息。Session bean與entity bean、數(shù)據(jù)、還有其他用以控制任務(wù)流的資源一起工作。任務(wù)流是任何業(yè)務(wù)系統(tǒng)的本質(zhì)所在，因?yàn)樗磉_(dá)了實(shí)體間如何交

4、互，用以模塑實(shí)際的業(yè)務(wù)。Session bean控制任務(wù)和資源，但它們自身并不代表實(shí)際數(shù)據(jù)代理存根和bean實(shí)例當(dāng)你的業(yè)務(wù)邏輯與session bean交互時(shí)，它并不直接與bean class的實(shí)例打交道，而是經(jīng)由bean的遠(yuǎn)程或本地接口。當(dāng)調(diào)用遠(yuǎn)程或本地接口的方法時(shí)，你所使用的對(duì)象實(shí)例時(shí)一種被稱(chēng)為代理存根的東西。該代理存根實(shí)現(xiàn)了session bean的遠(yuǎn)程或本地接口，并且負(fù)責(zé)將你的session bean方法調(diào)用經(jīng)過(guò)網(wǎng)絡(luò)發(fā)生到遠(yuǎn)程EJB容器，或?qū)⒄?qǐng)求路由到位于本地JVM內(nèi)的EJB容器。代理存根可以由像RMI的rmic這樣的預(yù)編譯器生成，或者像JBoss那樣，在部署期間使用JDK所帶的jav

5、a.lang.reflect.Proxy動(dòng)態(tài)生成。Session Bean將任務(wù)流邏輯移到session bean中還簡(jiǎn)化了客戶(hù)端應(yīng)用，降低了網(wǎng)絡(luò)通信。過(guò)量的網(wǎng)絡(luò)通信是分布式對(duì)象系統(tǒng)的常見(jiàn)問(wèn)題：它能搞垮服務(wù)器和阻塞網(wǎng)絡(luò)，損害響應(yīng)時(shí)間和性能。如果使用得當(dāng)，通過(guò)限制執(zhí)行一項(xiàng)任務(wù)所需的請(qǐng)求數(shù)量，session bean能夠減小網(wǎng)絡(luò)通信流量。Sessoin bean的使用者將任務(wù)流所涉及的不同bean之間的彼此交互保持于服務(wù)器端。位于客戶(hù)端應(yīng)用的一次方法調(diào)用導(dǎo)致了服務(wù)器端的多次方法調(diào)用，但是網(wǎng)絡(luò)所看到的僅僅是由客戶(hù)端調(diào)用session bean所引起的通信流量。 Stateful和stateless

6、session beanSessoin bean既可以是有狀態(tài)的，也可以是無(wú)狀態(tài)的。當(dāng)客戶(hù)端使用stateless session bean時(shí)session bean就維持了會(huì)話狀態(tài)。會(huì)話狀態(tài)是不寫(xiě)入數(shù)據(jù)庫(kù)的。它是客戶(hù)端在維持與某一enterprise bean的會(huì)話時(shí)保存于內(nèi)存中的信息，并且一旦會(huì)話結(jié)束或EJB容器崩潰，就會(huì)隨即消失。 會(huì)話狀態(tài)僅在客戶(hù)端應(yīng)用正在使用bean 的時(shí)候才會(huì)被保持。一旦客戶(hù)端關(guān)閉或釋放了Session Bean，會(huì)話狀態(tài)就永久性消失了。Stateful Session Bean只為同一客戶(hù)端提供服務(wù)。持久化和 Entity Beans持久化是位于 JDBC 之上的

7、一個(gè)更高層抽象。持久層將對(duì)象映射到數(shù)據(jù)庫(kù)，以便在查詢(xún)、裝載、更新，或刪除對(duì)象的時(shí)候，無(wú)須使用像 JDBC 那樣繁瑣的 API。在 EJB 的早期版本中，持久化是EJB 平臺(tái)的一部分。從EJB 3.0 開(kāi)始，持久化已經(jīng)自成規(guī)范，被稱(chēng)為 Java Persistence API。Java Persistence API 定義了一種方法，可以將常規(guī)的普通 Java 對(duì)象（有時(shí)被稱(chēng)作 POJO）映射到數(shù)據(jù)庫(kù)。這些普通 Java 對(duì)象被稱(chēng)作 entity bean。 Entity BeanJava Persistence1.0規(guī)范中的entity bean僅作為普通Java對(duì)象（POJO）來(lái)使用，并且是

8、映射到關(guān)系數(shù)據(jù)庫(kù)表的。與其他類(lèi)型的EJB不同，entity bean可以被分配，序列化，并像任何其他POJO那樣通過(guò)網(wǎng)絡(luò)被發(fā)送出去。用entity bean來(lái)模塑那些可以被表達(dá)成名詞的業(yè)務(wù)概念。例如，一個(gè)entity bean可以代表一位顧客、一臺(tái)設(shè)備、存貨清單中的一項(xiàng)，或者一個(gè)地點(diǎn)。為了實(shí)現(xiàn)entity bean，你需要定義一個(gè)bean class，并選擇合適的數(shù)據(jù)成員作為該bean class的標(biāo)識(shí)（即主鍵）。主鍵是一種提供數(shù)據(jù)庫(kù)指向的手段。它給予entity bean class以標(biāo)識(shí)，即作為內(nèi)存中的對(duì)象，也作為數(shù)據(jù)庫(kù)里表中的一行。主鍵可以是一個(gè)類(lèi)，也可以是基本類(lèi)型（primitive

9、type）。持久化和 Entity Beans在 EJB 2.1 規(guī)范中，entity bean 非常笨重并且依賴(lài)于應(yīng)用服務(wù)器和整個(gè) Java EE 運(yùn)行時(shí)環(huán)境。在 Java Persistence 里，entity bean 是受持久化服務(wù)管理的常規(guī) Java 對(duì)象。與 EJB 2.1 不同，Java Persistence 中的 entity bean 并不要求實(shí)現(xiàn)任何規(guī)范特有的接口或類(lèi)。舊規(guī)范的另一個(gè)缺點(diǎn)在于，它讓每個(gè)廠商自行決定對(duì)象如何映射到數(shù)據(jù)庫(kù)。這使得 EJB 2.1 的 entity bean通常無(wú)法在不同廠商間進(jìn)行移植。新的 Java Persistence 規(guī)范定義了一個(gè)完備

10、的對(duì)象關(guān)系映射（ORM），如此，entity bean 便能夠在廠商之間輕松移植。 持久化和 Entity Beans由于 entity bean在EJB3.0是普通Java對(duì)象了，它們不僅可以在應(yīng)用服務(wù)器之間進(jìn)行移植；還能用于應(yīng)用服務(wù)器之外的常規(guī)Java應(yīng)用程序，甚至可以用于客戶(hù)端和服務(wù)器之間的數(shù)據(jù)傳輸。這使得設(shè)計(jì)更加簡(jiǎn)潔，也更為緊湊。Java Persistence 中的entity bean不同于EJB2.1中的entity bean。應(yīng)用程序的代碼可以直接與entity bean class打交道，而且不用像EJB session bean那樣，通過(guò)一個(gè)組件接口來(lái)與entity交互。

11、與舊版本的EJB規(guī)范不同，在Java Persistence中，entity bean和Entity Manager不要求必須使用應(yīng)用服務(wù)器。你可以在單元測(cè)試和Java應(yīng)用程序中使用Java Persistence，就像使用任何別的Java庫(kù)一樣。 Message-Driven BeansMessage-driven bean處理異步消息的EJB。Message-driven bean是用來(lái)整合其他應(yīng)用系統(tǒng)的，這些系統(tǒng)和EJB應(yīng)用一起工作。需要訪問(wèn)EJB應(yīng)用的Java應(yīng)用或遺留系統(tǒng)可以通過(guò)JMS向message-driven bean發(fā)送消息。由這些bean來(lái)處理消息，并利用其他的entity

12、 bean和session bean來(lái)執(zhí)行必要的任務(wù)。 在許多場(chǎng)合下，JMS-MDB扮演著與stateless session bean同樣的角色：它們管理著entity bean和session bean的任務(wù)流。這些任務(wù)是由應(yīng)用系統(tǒng)利用JMS發(fā)送的異步消息來(lái)發(fā)起的。與session bean調(diào)用其組件接口的業(yè)務(wù)方法以做出響應(yīng)。因?yàn)橄⑹钱惒降?，所以發(fā)送消息的客戶(hù)端就不用期望有回復(fù)了?？蛻?hù)端簡(jiǎn)單的將消息發(fā)送，然后便可將其拋在腦后。 異步通信除了支持基于 RMI 的分布式業(yè)務(wù)對(duì)象，Enterprise JavaBeans 還支持異步通信。一個(gè)異步通信系統(tǒng)允許兩個(gè)或多個(gè)應(yīng)用以消息的形式交換信息。

13、在這里，消息（message）是一個(gè)攜帶業(yè)務(wù)數(shù)據(jù)和網(wǎng)絡(luò)路由包頭（network routing header）的自包含數(shù)據(jù)包（self-contained package）。包含在消息中的業(yè)務(wù)數(shù)據(jù)，根據(jù)業(yè)務(wù)場(chǎng)景可以是任何內(nèi)容，并且時(shí)常包含有關(guān)業(yè)務(wù)性事務(wù)的信息。在企業(yè)系統(tǒng)中，消息用于通知一個(gè)應(yīng)用系統(tǒng)中的某一事件，或是在其他系統(tǒng)內(nèi)發(fā)生的事件。異步通信使用面向消息的中間件（message-oriented middleware, MOM）可以在網(wǎng)絡(luò)上將異步消息從一個(gè)應(yīng)用傳送到另一個(gè)應(yīng)用。MOM 產(chǎn)品確保消息正確地分布于應(yīng)用系統(tǒng)間。此外，MOM通常還為需要可靠的交換大量消息的企業(yè)提供容錯(cuò)、負(fù)載均衡、可

14、伸縮，以及事務(wù)支持。Enterprise JavaBeans 將 MOM 的功能集成到其組件模型中。該集成擴(kuò)展了 EJB 平臺(tái)，因而它同時(shí)支持 RMI 和異步消息。EJB 3.0 借助 Java Message Service（JMS）和一個(gè)被稱(chēng)作message-driven bean 的新型組件來(lái)支持異步消息。 Java Message Service雖然每個(gè) MOM 廠商各自實(shí)現(xiàn)自己的網(wǎng)絡(luò)協(xié)議，路由和管理設(shè)施，但是不同 MOM 為開(kāi)發(fā)者所提供的 API，其基本語(yǔ)義是相同的。正是 API 的相似性使得 Java Message Service（JMS）成為可能。JMS 是一組廠商無(wú)關(guān)（ven

15、dor-agnostic）的 Java API，可以用于許多不同的 MOM 廠商。JMS 與 JDBC 非常類(lèi)似，應(yīng)用程序開(kāi)發(fā)者能夠重復(fù)使用同樣的 API 來(lái)訪問(wèn)許多不同的系統(tǒng)。如果廠商提供了 JMS 兼容服務(wù)提供程序，我們就可以使用 JMS API 來(lái)向其發(fā)送消息，并且接收來(lái)自該提供商的消息。 JCA 1.5在 EJB 2.1 中，借助新的 Java EE Connector Architecture（JCA 1.5），message-driven bean向其他協(xié)議的擴(kuò)展成為了可能。該規(guī)范定義了一個(gè)用于和企業(yè)信息系統(tǒng)交互的可移植的編程模型。在 Java EE 中使用 JCA 就如同在計(jì)算機(jī)

16、硬件中使用 USB。Web Services web service 代表了分布計(jì)算領(lǐng)域里最近的潮流。盡管 web service 這一術(shù)語(yǔ)已經(jīng)廣為流傳，但是要形成具體化的定義卻比較困難，因?yàn)樵谧罡邔用嫔?，web service 并非專(zhuān)屬于任何特定技術(shù)或平臺(tái)。 SOAPWSDLUDDIXML部署描述文件和JAR文件注解允許開(kāi)發(fā)人員在bean class文件中直接制定數(shù)據(jù)庫(kù)映射用元數(shù)據(jù)。Java Persistence規(guī)范允許你在一個(gè)叫做映射文件（mapping file）的XML部署描述文件中定義bean到數(shù)據(jù)庫(kù)的映射。該XML映射文件可以用來(lái)取代bean class的注解。如果bean cl

17、ass的注解早已存在，那么該映射文件能夠覆蓋這些注解，或是提供附加的元數(shù)據(jù)。XML映射文件的優(yōu)先級(jí)總是高于任何bean class的注解。一旦定義很好XML部署描述文件和entity bean class，你必須將它們?nèi)看虬M(jìn)一個(gè)Java Archive（JAR）文件里 Session Bean的開(kāi)發(fā)Session BeanSession bean可分為兩種基本類(lèi)型：stateless和stateful。Stateless session bean是一組相關(guān)服務(wù)的集合，每個(gè)服務(wù)由一個(gè)方法來(lái)表示。Stateless session bean不維護(hù)任何介于兩次方法調(diào)用間的狀態(tài)。當(dāng)你調(diào)用state

18、less session bean的某個(gè)方法時(shí)，它會(huì)執(zhí)行該方法并返回結(jié)果，既不了解也不關(guān)心前后還有哪些調(diào)用請(qǐng)求。因此，可以將stateless session bean理解為一組子程序(procedure)或批處理程序(batch progr。am)，它們根據(jù)傳的參數(shù)執(zhí)行請(qǐng)求，然后返回結(jié)果。Session BeanStateful session bean是客戶(hù)端應(yīng)用程序在服務(wù)器端的延續(xù)。它代表客戶(hù)端執(zhí)行各項(xiàng)任務(wù)，并維護(hù)著與客戶(hù)端的會(huì)話狀態(tài)。之所以被稱(chēng)為會(huì)話狀態(tài)是因?yàn)?，它們代表了stateful session bean和客戶(hù)端之間的一個(gè)持續(xù)的會(huì)話。調(diào)用stateful session bea

19、n的方法，可以從會(huì)話狀態(tài)中讀取數(shù)據(jù)，也可以向其中寫(xiě)入數(shù)據(jù)，這些數(shù)據(jù)在所有方法調(diào)用之間都是共享的。依賴(lài)于特定的EJB廠商，stateful session bean可能會(huì)有一個(gè)超時(shí)期(timeout period)。如果客戶(hù)端在stateful bean超時(shí)前沒(méi)有對(duì)其進(jìn)行任何調(diào)用，bean實(shí)例就會(huì)被容器自動(dòng)銷(xiāo)毀，與之關(guān)聯(lián)的EJB object引用也會(huì)隨之失效。這可以避免stateful session bean在客戶(hù)端關(guān)閉后很久才被銷(xiāo)毀的情況。我們不希望與此類(lèi)客戶(hù)端相關(guān)聯(lián)的stateful session bean始終占據(jù)著服務(wù)器。除了超時(shí)以外，客戶(hù)端也可以通過(guò)調(diào)用bean的remove方法明確

20、將其移除。Session Bean由于stateless session bean不保存任何會(huì)話狀態(tài)，并且不是專(zhuān)門(mén)為某個(gè)客戶(hù)端提供服務(wù)，因而它可以在服務(wù)器端駐留更長(zhǎng)的時(shí)間。只要一個(gè)stateless session bean方法調(diào)用完成，它就可以被重新分派，為新的客戶(hù)端提供服務(wù)。Stateless session bean也可能存在一個(gè)超時(shí)期，同樣也可以被客戶(hù)端強(qiáng)制移除，但是其效果與stateful session bean有所不同。超時(shí)或移除操作只是簡(jiǎn)單地讓該客戶(hù)端指向EJB object的引用失效；而bean實(shí)例并不會(huì)被銷(xiāo)毀，它可以繼續(xù)為其他客戶(hù)端請(qǐng)求提供服務(wù)。Stateless sess

21、ion bean具有很好的性能，并且相對(duì)而言比較容易開(kāi)發(fā)。 同樣，由于stateless bean不保存任何會(huì)話狀態(tài)，因此也就不需要鈍化或激活，這進(jìn)一步降低了切換的開(kāi)銷(xiāo)。簡(jiǎn)言之，stateless session bean是輕量而快速的。Stateless Bean這些限制并不意味著stateless session bean不能擁有實(shí)例變量，或者維護(hù)內(nèi)部狀態(tài)。你大可以利用實(shí)例變量來(lái)跟蹤bean的調(diào)用次數(shù)，或保存調(diào)試用數(shù)據(jù)。你還可以利用實(shí)例變量來(lái)保存對(duì)外部資源的引用，例如：用于日志記錄的uRL連接，用于信用卡驗(yàn)證的外部EJB引用，或是其他任何有用的資源。因此，任何保存于實(shí)例變量中的數(shù)據(jù)都應(yīng)該是

22、“普適性”的。 報(bào)表生成、批處理，或者像信用卡驗(yàn)證這樣的無(wú)狀態(tài)服務(wù)可以使用stateless session bean來(lái)實(shí)現(xiàn)。 業(yè)務(wù)接口 一個(gè)stateless session bean擁有一個(gè)或多個(gè)業(yè)務(wù)接口(business interface)。 業(yè)務(wù)接口可以是遠(yuǎn)程接口，也可以是本地接口，但是不能二者兼?zhèn)?。遠(yuǎn)程業(yè)務(wù)接口可以接受來(lái)自遠(yuǎn)程客戶(hù)端的方法調(diào)用。當(dāng)客戶(hù)端調(diào)用session bean的遠(yuǎn)程接口方法時(shí)，無(wú)論客戶(hù)端運(yùn)行于bean所在的同一JVM，還是網(wǎng)絡(luò)中的另一臺(tái)機(jī)器，EJB容器都將對(duì)參數(shù)和返回值進(jìn)行值拷貝。這就是遠(yuǎn)程接口的call-by-value語(yǔ)義。本地接口只用于session be

23、an所在的JVM。調(diào)用本地接口不會(huì)引起參數(shù)和返回值的值拷貝。因此，我們稱(chēng)本地接口遵循所謂的call-by-reference語(yǔ)義。應(yīng)用程序異常 任何遠(yuǎn)程接口或本地接口都可以拋出應(yīng)用程序異常(application exception)。應(yīng)用程序異常用于描述業(yè)務(wù)邏輯錯(cuò)誤。應(yīng)用程序異常對(duì)客戶(hù)端而言應(yīng)該是有意義的，它提供一種標(biāo)示錯(cuò)誤的簡(jiǎn)明手段。EJBException表明容器在處理一個(gè)業(yè)務(wù)接口調(diào)用時(shí)遇到了問(wèn)題。由于EJBException是unchecked exception(繼承自java1angRuntimeException)，因此即便你不捕獲它也不會(huì)產(chǎn)生編譯錯(cuò)誤。不過(guò)在某些情況下，捕獲EJ

24、BException不失為一個(gè)良策；而其他情況下，則應(yīng)讓它繼續(xù)傳播下去。由于應(yīng)用程序異常會(huì)被傳播到作為調(diào)用方的客戶(hù)端，因而此類(lèi)異常中的任何實(shí)例變量都必須能夠被序列化。而非應(yīng)用程序異常則總會(huì)被包裝為EJBException。 SessionContextSessionContext對(duì)象被作為Bean實(shí)例與EJB容器交互的接口。Session bean可以通過(guò)它獲取到方法調(diào)用的上下文信息，也可以快速訪問(wèn)各種EJB服務(wù)。你可以通過(guò)SessionContext獲取諸如當(dāng)前是哪個(gè)用戶(hù)在調(diào)用EJB之類(lèi)的信息。Sessioncontext.getBusinessObject()方法返回一個(gè)指向當(dāng)前EJB的引

25、用，它可以供其他客戶(hù)端調(diào)用，作用等同于Java中的this指針。 Session Context方法/ security methods public java.security.Principal getCallerPrincipal( ); public boolean isCallerInRole(java.lang.String roleName); / transaction methods public javax.transaction.UserTransaction getUserTransaction( ) throws java.lang.IllegalStateExcep

26、tion; public boolean getRollbackOnly( ) throws java.lang.IllegalStateException; public void setRollbackOnly( ) throws java.lang.IllegalStateException; Stateless Bean生命周期 Session BeanStateful session beanStateful session bean維護(hù)著會(huì)話狀態(tài)，也就是說(shuō)：bean class的實(shí)例變量可以在不同的方法調(diào)用間維護(hù)特定于某個(gè)客戶(hù)端的數(shù)據(jù)。這將使得方法間的彼此依賴(lài)成為可能：如果某個(gè)方法

27、調(diào)用修改了bean的狀態(tài)，其后的方法調(diào)用也會(huì)受到影響。正因?yàn)槿绱耍瑏?lái)自客戶(hù)端的每次方法調(diào)用都必須由同一個(gè)實(shí)例來(lái)處理(至少概念上是如此)，從而，兩次方法調(diào)用之間的實(shí)例狀態(tài)變化是可預(yù)期的。相反，stateless session bean并不在方法調(diào)用間維護(hù)與客戶(hù)端相關(guān)的數(shù)據(jù)，因而任何實(shí)例都可以用來(lái)處理來(lái)自任何客戶(hù)端的任何方法調(diào)用請(qǐng)求。Stateful session beansession bean與其他類(lèi)型的bean最大的不同之處在于它是不使用實(shí)例池的。Stateful bean 在其整個(gè)生命周期中只服務(wù)于一個(gè)客戶(hù)端，因此對(duì)實(shí)例進(jìn)行交換或池化都是不可能的。當(dāng)它們閑置時(shí)，stateful ses

28、sion bean的實(shí)例會(huì)被容器簡(jiǎn)單地從內(nèi)存中移除。EJB object仍然會(huì)與客戶(hù)端保持連接，但是bean實(shí)例已經(jīng)無(wú)法被引用到。并且，這些bean實(shí)例會(huì)在系統(tǒng)空閑期間被垃圾收集器徹底清除。這意味著，每個(gè)stateful bean在移除之前都必須被鈍化，這可以保證會(huì)話狀態(tài)被有效的保存。從而，當(dāng)EJB object被重新激活時(shí)，會(huì)話狀態(tài)可以再次恢復(fù)。激活機(jī)制 stateful session bean會(huì)在不同的方法調(diào)用之間維護(hù)會(huì)話狀態(tài)會(huì)話狀態(tài)的完整性需要得到保障。不同于stateless session bean和message-driven bean，stateful session bean

29、使用激活而不是實(shí)例池來(lái)降低資源的消耗。當(dāng)EJB服務(wù)器需要節(jié)省資源時(shí)可以從內(nèi)存中收回stateful session bean。收回stateful session bean時(shí)，bean會(huì)釋放它所占有的內(nèi)存資源，并將其所保持的會(huì)話狀態(tài)序列化到輔助存儲(chǔ)器中。若此時(shí)客戶(hù)端對(duì)該EJB對(duì)象再次發(fā)出請(qǐng)求，EJB容器會(huì)重新實(shí)例化一個(gè)stateful session bean的實(shí)例，并從輔助存儲(chǔ)器中將之前的狀態(tài)恢復(fù)。鈍化鈍化（passivation）是解除stateful bean實(shí)例與相關(guān)EJB對(duì)象間的關(guān)聯(lián)，并保存其狀態(tài)的一種操作。鈍化的過(guò)程要求bean實(shí)例的狀態(tài)，根據(jù)其所關(guān)聯(lián)的EJB對(duì)象，被保存起來(lái)。當(dāng)b

30、ean被鈍化以后，我們就可以安全地將它的實(shí)例從EJB對(duì)象和內(nèi)存中移除。然而客戶(hù)端并不了解鈍化的整個(gè)過(guò)程，它使用的是bean的遠(yuǎn)程引用，該遠(yuǎn)程引用是由EJB的存根代理實(shí)現(xiàn)的，因此客戶(hù)端不直接與bean的實(shí)例進(jìn)行通信。于是，即使在bean被鈍化以后，EJB容器仍然可以維護(hù)客戶(hù)端與EJB對(duì)象的連接。激活激活bean的操作則是根據(jù)其所關(guān)聯(lián)的EJB對(duì)象將bean實(shí)例的狀態(tài)重新恢復(fù)。當(dāng)調(diào)用鈍化了的EJB對(duì)象的方法時(shí)，容器會(huì)自動(dòng)創(chuàng)建一個(gè)新的實(shí)例，并按照鈍化期間保存的內(nèi)容逐一設(shè)置數(shù)據(jù)成員。然后，EJB對(duì)象會(huì)像往常一樣將方法調(diào)用委托給這個(gè)bean實(shí)例。 Stateful bean的生命周期 Stateful S

31、ession Bean和Extended Persistence Context當(dāng)persistence context被標(biāo)記為EXTENDED時(shí)，查詢(xún)所得的entity將一直保持托管狀態(tài)，并會(huì)被關(guān)聯(lián)于session bean的EntityManager。在這種情況下，updateAddress()方法會(huì)變得簡(jiǎn)單一些，因?yàn)槲覀儾辉傩枰狤ntityMangermerge()方法了。當(dāng)任何事務(wù)性方法被調(diào)用時(shí)，stateful bean中的所有extended persistence context都會(huì)被自動(dòng)注冊(cè)到事務(wù)中去。 Entity Bean實(shí)體Bean一個(gè)實(shí)體Bean 由實(shí)體類(lèi)和persis

32、tence.xml 文件組成。persistence.xml 文件在Jar 文件的META-INF 目錄。persistence.xml 文件指定實(shí)體Bean 使用的數(shù)據(jù)源及EntityManager 對(duì)象的默認(rèn)行為java:/DefaultMySqlDSpersistence-unitpersistence-unit 節(jié)點(diǎn)可以有一個(gè)或多個(gè)，每個(gè)persistence-unit 節(jié)點(diǎn)定義了持久化內(nèi)容名稱(chēng)、使用的數(shù)據(jù)源名稱(chēng)及Hibernate 屬性。name 屬性用作設(shè)置持久化名稱(chēng)。jta-data-source 節(jié)點(diǎn)用作指定實(shí)體Bean 使用的數(shù)據(jù)源名稱(chēng)。如果hibernate.hbm2ddl

33、.auto的值設(shè)為create-drop，在實(shí)體Bean 發(fā)布及卸載時(shí)將自動(dòng)創(chuàng)建及刪除相應(yīng)數(shù)據(jù)庫(kù)表(注意：Jboss 服務(wù)器啟動(dòng)或關(guān)閉時(shí)會(huì)引發(fā)實(shí)體Bean 的發(fā)布及卸載)JBoss數(shù)據(jù)源的配置Jboss有一個(gè)默認(rèn)的數(shù)據(jù)源DefaultDS，他使用Jboss內(nèi)置的HSQLDB數(shù)據(jù)庫(kù)。實(shí)際應(yīng)用中你可能使用不同的數(shù)據(jù)庫(kù)，如MySql、MsSqlServer、Oracle等。各種數(shù)據(jù)庫(kù)的數(shù)據(jù)源配置模版你可以在Jboss安裝目錄docsexamplesjca 目錄中找到，默認(rèn)名稱(chēng)為：數(shù)據(jù)庫(kù)名+ -ds.xml 。實(shí)體Bean 發(fā)布前的準(zhǔn)備工作1. 配置數(shù)據(jù)源并放置在jboss 安裝目錄/server/a

34、ll/deploy 目錄，把數(shù)據(jù)庫(kù)驅(qū)動(dòng)Jar 包放置在Jboss 安裝目錄serveralllib 目錄下，放置后需要重啟Jboss服務(wù)器。如果數(shù)據(jù)源已經(jīng)存在就不需要配置。2. 配置persistence.xml文件，在文件中指定使用的源據(jù)源及各項(xiàng)參數(shù)。3. 把實(shí)體類(lèi)和persistence.xml文件打成Jar，persistence.xml 放在jar 文件的META-INF目錄Entity BeanCabin bean class 被標(biāo)注javax.persistence.Entity 和javax.persistence.Table。注解Entity 告知 persistence pr

35、ovider，這是一個(gè)映射到數(shù)據(jù)庫(kù)的實(shí)體類(lèi)，并且可以受管于 EntityManager 服務(wù)。注解Table 則告知 EJB 容器，bean class 應(yīng)當(dāng)被映射到哪一張數(shù)據(jù)庫(kù)表。Bean class 實(shí)現(xiàn)了 java.io.Serializable 接口，但這并非是必須的。假如實(shí)體類(lèi)實(shí)現(xiàn)了 Serializable，就可以用作 session bean 中遠(yuǎn)程接口方法的參數(shù)和返回值。這使你能夠?qū)⑼粋€(gè)類(lèi)既用于持久化，又用于數(shù)據(jù)傳輸。ColumnColumn注釋定義了映射到列的所有屬性,如列名是否唯一，是否允許為空，是否允許更新等，他的屬性介紹如下：name: 映射的列名。如：映射Perso

36、n表的PersonName列，可以在name屬性的getName 方法上面加入Column(name = PersonName)，如果不指定映射列名，容器將屬性名稱(chēng)作為默認(rèn)的映射列名。unique: 是否唯一nullable: 是否允許為空l(shuí)ength: 對(duì)于字符型列，length屬性指定列的最大字符長(zhǎng)度insertable: 是否允許插入updatable: 是否允許更新columnDefinition: 定義建表時(shí)創(chuàng)建此列的DDLsecondaryTable: 從表名。如果此列不建在主表上（默認(rèn)建在主表），該屬性定義該列所在從表的名字。Column(name = PersonName,nu

37、llable=false,length=32)IdId 注釋指定personid屬性為表的主鍵，它可以有多種生成方式：TABLE：容器指定用底層的數(shù)據(jù)表確保唯一。SEQUENCE：使用數(shù)據(jù)庫(kù)的SEQUENCE 列來(lái)保證唯一IDENTITY：使用數(shù)據(jù)庫(kù)的INDENTIT列來(lái)保證唯一AUTO：由容器挑選一個(gè)合適的方式來(lái)保證唯一NONE：容器不負(fù)責(zé)主鍵的生成，由調(diào)用程序來(lái)完成。GeneratedValue注釋定義了標(biāo)識(shí)字段的生成方式,本例personid的值由MySQL數(shù)據(jù)庫(kù)自動(dòng)生成。EntityManagerEntityManager 是由EJB容器自動(dòng)地管理和配置的，不需要用戶(hù)自己創(chuàng)建，他用作操

38、作實(shí)體Bean。在類(lèi)中并沒(méi)有看到對(duì)EntityManager em進(jìn)行賦值，后面卻可以直接使用他。這是因?yàn)樵趯?shí)體Bean加載時(shí)，容器通過(guò)PersistenceContext注釋動(dòng)態(tài)注入EntityManager 對(duì)象。如果persistence.xml文件中配置了多個(gè)不同的持久化內(nèi)容。你需要指定持久化名稱(chēng)注入EntityManager 對(duì)象，可以通過(guò)PersistenceContext注釋的unitName屬性進(jìn)行指定，例：PersistenceContext(unitName=foshanshop)EntityManager em;如果只有一個(gè)持久化內(nèi)容配置，不需要明確指定。托管與非托管實(shí)體

39、在進(jìn)一步討論 entity manager 服務(wù)之前，我們需要更加深入地理解實(shí)體對(duì)象實(shí)例的生命周期。一個(gè) entity bean 實(shí)例或者受 entity manager 托管（也稱(chēng)為 attached），或者不受其托管（也稱(chēng)為 detached）。若 entity bean 與 EntityManager相關(guān)聯(lián)，則 EntityManager 會(huì)跟蹤實(shí)體的狀態(tài)變更，并在 entity manager 決定對(duì)實(shí)體狀態(tài)進(jìn)行 flush 操作的時(shí)候，將這些變更保存到數(shù)據(jù)庫(kù)中。一旦實(shí)體被解除了關(guān)聯(lián)，它就不再受托管了。Entity manager 不會(huì)對(duì)任何解除關(guān)聯(lián)的實(shí)體做狀態(tài)變更的跟蹤。Persis

40、tence contextPersistence context 是由一組受托管的實(shí)體對(duì)象實(shí)例所構(gòu)成的集合。它受 entity manager 的管理。Entity manager 追蹤 persistence context 中所有對(duì)象的修改和更新情況，并根據(jù)指定的 flush 模式（本章稍后會(huì)做討論）將這些修改保存到數(shù)據(jù)庫(kù)中。一旦 persistence context被關(guān)閉，所有實(shí)體對(duì)象實(shí)例都會(huì)脫離EntityManager而成為非托管對(duì)象。對(duì)象一旦從persistence context 中脫離，就不再受 entity manager 管理了，任何對(duì)此對(duì)象的狀態(tài)變更也將不會(huì)被同步到數(shù)據(jù)

41、庫(kù)。一旦persistence context被關(guān)閉，所有的實(shí)體對(duì)象實(shí)例都會(huì)脫離entity manager 而成為非托管對(duì)象。Java Persistence 中有兩種類(lèi)型的 persistence context，分別是 transaction-scoped persistence context 和 extended persistence context。Transaction-scoped persistence context有的persistence context可能只在事務(wù)范圍內(nèi)存在，它們會(huì)在事務(wù)結(jié)束后被關(guān)閉，這樣的persistence context 被稱(chēng)作 transa

42、ction-scoped persistence context。當(dāng)事務(wù)結(jié)束時(shí)，transaction- scoped persistence context 將被銷(xiāo)毀，而所有的托管實(shí)體對(duì)象實(shí)例也將處于游離狀態(tài)（detached）。只有受應(yīng)用服務(wù)器管理的 persistence context 才可以是事務(wù)范圍的。換言之，只有標(biāo)注了PersistenceContext 注解（或是其 XML 的等價(jià)描述）的 EntityManager實(shí)例才可以是事務(wù)范圍的。Extended persistence context 我們也可以將 persistence context配置成超出事務(wù)的范圍，我們稱(chēng)之

43、為 extended persistence context。與 extended context 相關(guān)聯(lián)的實(shí)體對(duì)象實(shí)例會(huì)一直保持托管狀態(tài)，甚至在事務(wù)提交之后也是如此。在某些場(chǎng)合下，這一特性極為有用。例如，你想保持與數(shù)據(jù)庫(kù)的會(huì)話，又不希望使用長(zhǎng)事務(wù)（long-running transaction），因?yàn)殚L(zhǎng)事務(wù)會(huì)一直占用像 JDBC 連接、數(shù)據(jù)庫(kù)鎖這樣的寶貴系統(tǒng)資源。Extended persistence context 可以由應(yīng)用代碼自行創(chuàng)建和管理。 游離實(shí)體（Detached entities）當(dāng) transaction scope persistence context 或 exten

44、ded persistence context 結(jié)束之后，實(shí)體的實(shí)例就會(huì)不受托管而處于游離狀態(tài)。游離實(shí)體的一個(gè)值得注意的特征是，它可以被序列化并通過(guò)網(wǎng)絡(luò)發(fā)送給遠(yuǎn)程客戶(hù)端。客戶(hù)端可以修改這些經(jīng)過(guò)序列化的對(duì)象實(shí)例，并將它們發(fā)送回服務(wù)器，服務(wù)器再將客戶(hù)端的修改重新合并到數(shù)據(jù)庫(kù)中。這與 EJB 2.1 的實(shí)體模型有很大的不同。在 EJB 2.1 中，實(shí)體是始終受容器管理的，使用entity bean 的應(yīng)用程序總要帶一個(gè)指向 entity bean 的代理（譯注：proxy，即遠(yuǎn)程接口或本地接口）；而在 EJB 3.0 中，你是直接與普通 Java 類(lèi)的具體實(shí)例打交道的。 獲取 EntityManag

45、er 我們可以通過(guò) EntityManagerFactory 來(lái)創(chuàng)建和獲得 EntityManager。在 Java SE 環(huán)境中，你必須使用 EntityManagerFactory 來(lái)創(chuàng)建 EntityManager 的實(shí)例，在 Java EE 中則還有其他選擇。package javax.persistence;public interface EntityManagerFactory EntityManager createEntityManager(); EntityManager createEntityManager(java.util.Map map); void close(

46、); boolean isOpen();與 Java SE 相比，在 Java EE 中獲取 EntityManagerFactory 要更為容易一些。通過(guò)使用javax.persistence.PersistenceUnit 注解，EJB 容器會(huì)將 EntityManagerFactory 的實(shí)例直接注入或通過(guò) setter 方法注入到 EJB 的數(shù)據(jù)成員中。EntityManagerpersist()方法 entityManager.persist(cust); find()和 getReference()方法 public interface EntityManager T find(C

47、lass entityClass, Object primaryKey); T getReference(Class entityClass, Object primaryKey); getReference()方法與find()方法的不同之處在于：如果在數(shù)據(jù)庫(kù)中找不到相應(yīng)的實(shí)體，getReference()方法將拋出javax.persistence.EntityNotFoundException異常；并且該方法并不保證返回實(shí)例的內(nèi)部狀態(tài)會(huì)被初始化。persistence context 的不同而有所不同：若 EntityManager 是 transactionscoped persist

48、ence context，則會(huì)返回游離對(duì)象；而若是 extended persistence context，則返回托管對(duì)象。 Entity Manager查詢(xún)Query createQuery(String queryString);Query createNamedQuery(String name);Query createNativeQuery(String sqlString);Query createNativeQuery(String sqlString, Class resultClass);Query createNativeQuery(String sqlString, S

49、tring resultSetMapping);更新 一旦你調(diào)用了 find()，getReference()，或創(chuàng)建并執(zhí)行了一次查詢(xún)，所得的 entity bean實(shí)例在 persistence context 關(guān)閉前仍將處于托管狀態(tài)。在此期間，你可以像其他對(duì)象那樣隨便更改 entity bean 實(shí)例的狀態(tài)，任何更改都將被自動(dòng)（取決于 flush 模式）或手工（通過(guò)調(diào)用 flush()方法）地同步到數(shù)據(jù)庫(kù)中。合并實(shí)體 在 Java Persistence 中，你可以使用 EntityManager 的 merge()方法，將游離實(shí)體的狀態(tài)變更合并到數(shù)據(jù)庫(kù)中。 Entity Manager刪

50、除實(shí)體調(diào)用EntityManager.remove()可以將實(shí)體從數(shù)據(jù)庫(kù)中刪除。不過(guò)，remove()方法并不立即生效，而是在 EntityManager 決定執(zhí)行 flush 操作時(shí)，根據(jù)定義好的 flush 規(guī)則才會(huì)執(zhí)行 SQL DELETE 操作。refresh()如果發(fā)現(xiàn)當(dāng)前受托管的實(shí)體并非數(shù)據(jù)庫(kù)中的最新數(shù)據(jù)，你可以調(diào)用 EntityManager. refresh()方法。refresh()方法會(huì)根據(jù)數(shù)據(jù)庫(kù)的情況刷新內(nèi)存中實(shí)體的狀態(tài)，同時(shí)覆蓋對(duì)實(shí)體所做的任何修改。contains()方法與 clear()方法 contains()方法接受實(shí)體實(shí)例作為參數(shù)，如果該對(duì)象實(shí)例目前正受 pe

51、rsistence context 管理，則返回 true。若該參數(shù)并非實(shí)體類(lèi)型，則會(huì)拋出 IllegalArgumentException 異常。你可以使用 EntityManager.clear()方法將 persistence context 中所有的托管實(shí)體都變成游離對(duì)象。需要注意的是，一旦你調(diào)用了 clear()方法，對(duì)實(shí)體所做的任何修改都將被丟棄。因此，使用 clear()時(shí)需要格外小心。在調(diào)用 clear()之前，先調(diào)用 flush()方法以免丟失更改實(shí)為明智之舉。flush()方法和 FlushModeType 調(diào)用persist()，merge()，remove()方法之后，

52、這些更改操作只有在EntityManager 決定執(zhí)行 flush 操作時(shí)才會(huì)被同步到數(shù)據(jù)庫(kù)中。你也可以在任何時(shí)候通過(guò)調(diào)用flush()方法做強(qiáng)行同步。缺省情況下，flush操作會(huì)在相關(guān)查詢(xún)執(zhí)行之前和事務(wù)提交之時(shí)自動(dòng)執(zhí)行（一些低效的 Java Persistence 實(shí)現(xiàn)甚至可能會(huì)在任何查詢(xún)執(zhí)行之前都做 flush操作）。但需注意的是，與一般查詢(xún)不同，調(diào)用 find()和 getReference()方法并不會(huì)引起 flush。這是因?yàn)橥ㄟ^(guò)主鍵來(lái)查詢(xún)實(shí)體是不會(huì)受任何更新操作的影響的?？梢酝ㄟ^(guò)枚舉類(lèi)型 javax.persistence.FlushModeType 來(lái)控制和修改這一默認(rèn)行為。pu

53、blic enum FlushModeType AUTO, COMMITAUTO 是前述的默認(rèn)行為。COMMIT 則表示，僅當(dāng)事務(wù)提交時(shí)才對(duì)更改做 flush 操作，而在任何查詢(xún)執(zhí)行之前都不會(huì)引發(fā)flush操作。你可以通過(guò)調(diào)用setFlushMode()方法來(lái)指定 EntityManager 的 FlushModeType。 getDelegate()getDelegate() 方法允許你獲 得一個(gè)指向底層persistence provider對(duì)象引用 ， 該persistence provider 實(shí)現(xiàn)了EntityManager 接口。大多數(shù)廠商都提供了針對(duì) EntityManager接

54、口的 API 擴(kuò)展，為了使用這些擴(kuò)展功能，你可以將獲取到的 delegate 對(duì)象強(qiáng)制類(lèi)型轉(zhuǎn)換為廠商的私有接口。雖然從理論上講，你應(yīng)該可以編寫(xiě)出廠商無(wú)關(guān)的代碼。但實(shí)際上，多數(shù)廠商都提供了大量針對(duì)Java Persistence的擴(kuò)展，你可以在應(yīng)用程序中充分利用這些功能。而 getDelegate()方法提供了一種獲取并使用廠商專(zhuān)有 API 的途徑。createQuery()Query query = em.createQuery(select p from Person p where p. name=黎明);List result = query.getResultList();Iterat

55、or iterator = result.iterator();while( iterator.hasNext() )/處理PersonQuery query = em.createQuery(update Person as p set =?1 where p. personid=?2);query.setParameter(1, “黎明” );query.setParameter(2, new Integer(1) );int result = query.executeUpdate(); /影響的記錄數(shù)Query query = em.createQuery(delete

56、from Person);int result = query.executeUpdate(); /影響的記錄數(shù)Message-Driven BeanJMS和Message-Driven Bean所有EJB 3.0開(kāi)發(fā)商都必須提供一個(gè)JMS provider的實(shí)現(xiàn)。大多數(shù)開(kāi)發(fā)商都應(yīng)該在EJB容器中內(nèi)置一個(gè)JMS provider，并通過(guò)JCA接入其他類(lèi)型的JMS provider。但是不管開(kāi)發(fā)商是自己提供JMS provider還是允許你整合其他provider，JMS provider對(duì)于Message-Driven bean而言絕對(duì)是必須的。 JMSJMS是一套用于訪問(wèn)企業(yè)消息系統(tǒng)的開(kāi)發(fā)商

57、中立的API。企業(yè)消息系統(tǒng)(也就是面向消息的中間體)可以協(xié)助應(yīng)用軟件通過(guò)網(wǎng)絡(luò)進(jìn)行消息交互。JMS在其中扮演的角色于JDBC很相似：正如JDBC提供了一套用于訪問(wèn)各種不同關(guān)系數(shù)據(jù)庫(kù)的公共API，JMS也提供了獨(dú)立于特定廠商的企業(yè)消息系統(tǒng)訪問(wèn)方式。JbossMQ,IBM的MQSerles、BEA的WebLogic JMS service、Sun Microsystems的Sun ONE Message Queue和Sonic的SonicMQ。 JMS使用JMS的應(yīng)用程序被稱(chēng)為JMS客戶(hù)端，處理消息的路由與傳遞的消息系統(tǒng)被稱(chēng)為JMS provider，而JMS應(yīng)用則是由多個(gè)JMS客戶(hù)端和一個(gè)JMS

58、provider(通常是一個(gè))構(gòu)成的業(yè)務(wù)系統(tǒng)。發(fā)送消息的JMS客戶(hù)端被稱(chēng)為生產(chǎn)者(producer)，而接收消息的JMS客戶(hù)端則被稱(chēng)為消費(fèi)者consumer)。同一JMS客戶(hù)端既可以是生產(chǎn)者也可以是消費(fèi)者。ConnectionFactory和Topic 為了發(fā)送JMS消息，我們需要一個(gè)指向JMS provider的連接和一個(gè)消息目標(biāo)地址。使用JMS連接工廠(JMS connection factory) 可以獲得JMS provider 連接；而消息目標(biāo)地址則可以由一個(gè)Topic 對(duì)象來(lái)表示。我們可以利用javax.annotation.Resource注解直接將連接工廠和Topic 對(duì)象注入

59、到TravelAgent EJB的數(shù)據(jù)成員中。Resource(mappedName = “ConnectionFactoryNameGoes”)Private ConnectionFactory connectionFactory;Resource(mappedName = “TicketTopic”)Private Topic topic ;TopicTopic對(duì)象代表了獨(dú)立于具體網(wǎng)路結(jié)構(gòu)的消息目的地址。在JMS中，消息并不是直接發(fā)送給應(yīng)用程序，而是發(fā)送到主題(topic)或隊(duì)列(queue)中。主題類(lèi)似于郵件列表或新聞組，任何獲得許可的應(yīng)用程序都可以接收來(lái)自主題的消息或向主題發(fā)送消息。如

60、果JMS客戶(hù)端受到了來(lái)自某個(gè)主題的消息，我們就稱(chēng)該客戶(hù)端訂閱了該主題。JMS通過(guò)目標(biāo)地址實(shí)現(xiàn)了應(yīng)用程序間的消息傳遞，消息目標(biāo)地址就像一個(gè)虛擬通道，JMS利用它對(duì)應(yīng)用程序進(jìn)行了解耦。 Connection & Session擁有了Connection，你就可以用它來(lái)創(chuàng)建Session對(duì)象。Session對(duì)象允許你將一系列發(fā)送和接收消息的操作組織在一起。 Session對(duì)象采用單線程模型，因此你不能在多個(gè)線程中并發(fā)的訪問(wèn)同一個(gè)Session對(duì)象。創(chuàng)建Session對(duì)象的線程通常也就是使用該Session對(duì)象的生產(chǎn)者和消費(fèi)者所在的線程 createSession()方法有兩個(gè)參數(shù)。createSes