【文章內(nèi)容簡(jiǎn)介】 享的數(shù)據(jù)。 基于 J2EE 的 Web 服務(wù)的核心構(gòu)架： RMI 1. RMIIIOP 2. RMI 是在 java 中使用 remote method invocation 的最初的方法， RMI 使用 包 RMI－ IIOP 是 RMI 的一個(gè)特殊版本， RMI－ IIOP 可以和 CORBA 兼容， RMIIIOP 使用 JAF(Java活動(dòng)構(gòu)架 ) 開(kāi)發(fā)者可以使用 JAF來(lái)決定任意一塊數(shù)據(jù)的類型、封裝對(duì)數(shù)據(jù)的訪 問(wèn)、尋找合適的操作、實(shí)例化相關(guān)的 bean來(lái)執(zhí)行這些操作等。 例如， JavaMail就是使用 JAF根據(jù) MIME類型來(lái)決定實(shí)例化那一個(gè)對(duì)象。 EJB 1. EJB 組件實(shí)現(xiàn)代碼的限制 EJB組件的約束 EJB的開(kāi)發(fā)者并不需要在 EJB的組件實(shí)現(xiàn)代碼中編寫(xiě)系統(tǒng)級(jí)的服務(wù)， EJB提供商 /開(kāi)發(fā) 者需知道并且嚴(yán)格地遵守一些限制，這些限制與開(kāi)發(fā)穩(wěn)定的和可移植的 EJB組件的利益有 關(guān)。 以下是你應(yīng)該回避使用的一些 Java特色，并且在你的 EJB組件的實(shí)現(xiàn)代碼中要嚴(yán)格限 制它們的使用： static，非 final 字段。建議你在 EJB 組件中把所有的 static 字段都聲明為final 型的。這樣可以保證前后一致的運(yùn)行期語(yǔ)義，使得 EJB 容器有可以在多個(gè) Java虛擬機(jī)之間分發(fā)組件實(shí)例的靈活性。 。避免這個(gè)問(wèn)題，你就可以使 EJB容器靈活的在多個(gè) Java虛擬機(jī)之間分發(fā)組件實(shí)例。 AWT函數(shù)完成鍵盤(pán)的輸入和顯示輸出。約束它的原因是服務(wù)器方的商業(yè)組件意味著提供商業(yè)功能而不包括用戶界面和鍵盤(pán)的 I/O功能。 / 操作 。 EJB商業(yè)組件意味著使用資源管理器如 JDBC來(lái)存儲(chǔ)和檢索數(shù)據(jù)而不是使用文件系統(tǒng) API。同時(shí)，部署工具提供了在部署描述器（ descriptor）中存儲(chǔ)環(huán)境實(shí)體，以至于 EJB組件可以通過(guò)環(huán)境命名上下文用一種標(biāo)準(zhǔn)的方法進(jìn)行環(huán)境實(shí)體查詢。所以，使用文件系統(tǒng)的需求基本上是被排除了。 socket連接，或者用 socket進(jìn)行多路發(fā)送。 EJB組件并不意味著提供網(wǎng)絡(luò) socket 服務(wù)器功能，但是，這個(gè)體系結(jié)構(gòu)使得 EJB 組件可以作為 socket 客戶或是 RMI客戶并且可以和容器所管理的環(huán)境外面的代碼進(jìn)行通 訊。 API查詢 EJB 組件由于安全規(guī)則所不能訪問(wèn)的類。這個(gè)約束加強(qiáng)了 Java 平臺(tái)的安全性。 ，設(shè)置或創(chuàng)建一個(gè)新的安全管理器，停止 Java虛擬機(jī)，改變輸入、輸出和出錯(cuò)流。這個(gè)約束加強(qiáng)了安全性同時(shí)保留了 EJB容器管理運(yùn)行環(huán)境的能力。 socket工廠被 URL39。s ServerSocket,Socket和 Stream handler使用。避免這個(gè)特點(diǎn)，可以加強(qiáng)安全性同時(shí)保留了 EJB容器管理運(yùn)行環(huán)境的能力。 、停止 和管理線程。這個(gè)約束消除了與 EJB容器管理死鎖、線程 和并發(fā)問(wèn)題的責(zé)任相沖突的可能性。 通過(guò)限制使用 10－ 16幾個(gè)特點(diǎn)，你的目標(biāo)是堵上一個(gè)潛在的安全漏洞： 。 。 。 Java一般角色所不能訪問(wèn)的包和類。 。 （策略、安全、提供者、簽名者和實(shí)體）。 Java序列化特點(diǎn)中的細(xì)分類和對(duì)象替代。 this引用指針作為一個(gè)參數(shù)或者作為返回值返回 this引用指針。你必須使用 SessionContext或 EntityContext中的 getEJBObject()的結(jié)果。 Java2平臺(tái)的安全策略 以上所列的特點(diǎn)事實(shí)上正是 Java編程語(yǔ)言和 Java2標(biāo)準(zhǔn)版中的標(biāo)準(zhǔn)的、強(qiáng)有力的特色。EJB 容器允許從 J2SE中使用一些或全部的受限制的特色，盡管對(duì)于 EJB組件是不可用的，但需通過(guò) J2SE的安全機(jī)制來(lái)使用而不是通過(guò)直接使用 J2SE的 API。 Java2 平臺(tái)為 的 EJB 容器所制定的安全策略定義了安全許可集，這些許可在 EJB 組件的編程限制中出現(xiàn)。通過(guò)這個(gè)策略，定義了一些許可諸如：,以便加強(qiáng)先前所列出的編程限制。 許多 EJB容器沒(méi)有加強(qiáng)這些限制，他們希望 EJB組件開(kāi)發(fā)者能遵守這些編程限制或者是帶有冒險(xiǎn)想法違背了這些限制。違背這些限 制的 EJB組件，比標(biāo)準(zhǔn)方法依賴過(guò)多或過(guò)少的安全許可，都將很少能在多個(gè) EJB容器間移植。另外，代碼中都將隱藏著一些不確定的、難以預(yù)測(cè)的問(wèn)題。所有這些都足以使 EJB組件開(kāi)發(fā)者應(yīng)該知道這些編程限制，同時(shí)也應(yīng)該認(rèn)真地遵守它們。 任何違背了這些編程限制的 EJB組件的實(shí)現(xiàn)代碼在編譯時(shí)都不能檢查出來(lái)，因?yàn)檫@些特點(diǎn)都是 Java語(yǔ)言和 J2SE中不可缺少的部分。 對(duì)于 EJB組件的這些限制同樣適用于 EJB組件所使用的幫助 /訪問(wèn)（ helper/access）類，J2EE應(yīng)用程序使用 Java文檔（ jar）文件格式打包 到一個(gè)帶 .ear（代表 Enterprise Archive）擴(kuò)展名的文件中，這個(gè) ear文件對(duì)于發(fā)送給文件部署器來(lái)說(shuō)是標(biāo)準(zhǔn)的格式。 ear文件中包括在一個(gè)或多個(gè) ejb－ jar文件中的 EJB組件，還可能有 ejb－ jar所依賴的庫(kù)文件。所有 ear文件中的代碼都是經(jīng)過(guò)深思熟慮開(kāi)發(fā)的應(yīng)用程序并且都遵守編程限制和訪問(wèn)許可集。 未來(lái)版本的規(guī)范可能會(huì)指定通過(guò)部署工具來(lái)定制安全許可的能力，通過(guò)這種方法指定了一個(gè)合法的組件應(yīng)授予的許可權(quán)限，也指定了一個(gè)標(biāo)準(zhǔn)方法的需求：如從文件系統(tǒng)中讀文件應(yīng)有哪些要求。一些 EJB容器 /服務(wù)器目前在 它們的部署工具中都提供了比標(biāo)準(zhǔn)權(quán)限或多或少的許可權(quán)限，這些并不是 。 理解這些約束 EJB容器是 EJB組件生存和執(zhí)行的運(yùn)行期環(huán)境， EJB 容器為 EJB組件實(shí)例提供了一些服務(wù)如：事務(wù)管理、安全持久化、資源訪問(wèn)、客戶端連接。 EJB容器也負(fù)責(zé) EJB組件實(shí)例整個(gè)生命期的管理、擴(kuò)展問(wèn)題以及并發(fā)處理。所以， EJB組件就這樣寄居在一個(gè)被管理的執(zhí)行環(huán)境中－－即 EJB容器。 因?yàn)?EJB容器完全負(fù)責(zé) EJB組件的生命期、并發(fā)處理、資源訪問(wèn)、安全等等，所以與容器本身的鎖定和并發(fā)管 理相沖突的可能性就需要消除，許多限制都需要使用來(lái)填上潛在的安全漏洞。除了與 EJB容器責(zé)任與安全沖突的問(wèn)題， EJB組件還意味著僅僅聚焦于商務(wù)邏輯，它依賴于 EJB容器所提供的服務(wù)而不是自己來(lái)直接解決底層的系統(tǒng)層的問(wèn)題。 可能的問(wèn)題 通常， EJB組件在容器之間的移植不可避免地與如下問(wèn)題相關(guān)： EJB容器中沒(méi)有得到加強(qiáng)。 。 為了保證 EJB組件的可移植性和一致的行為，你應(yīng)該使用一個(gè)具有與 Java2平臺(tái) 安全 策略集相一致的策略集的容器來(lái)測(cè)試 EJB組件，并且其加強(qiáng)了前述的編程限制。 總結(jié) EJB組件開(kāi)發(fā)者應(yīng)該知道這些推薦的關(guān)于 EJB組件的編程限制，明白它們的重要性，并且從組件的穩(wěn)定性和可移植性利益方面考慮來(lái)遵循它們。因?yàn)檫@些編程限制能阻止你使用標(biāo)準(zhǔn)的 Java語(yǔ)言的特點(diǎn)，違背了這些編程限制在編譯時(shí)不會(huì)知道，并且加強(qiáng)這些限制也不是EJB容器的責(zé)任。所有這些原因都使你應(yīng)很小心地遵守這些編程限制，這些限制在組件的合同中已經(jīng)成為了一個(gè)條款，并且它們對(duì)于建造可靠的、可移植的組件是非常重要的。 2. 優(yōu)化 EJB entity bean為在應(yīng)用程序和設(shè)計(jì)中描述持久化商業(yè)對(duì)象（ persistent business objec ts）提供了一個(gè)清晰的模型。在 java對(duì)象模型中，簡(jiǎn)單對(duì)象通常都是以一種簡(jiǎn)單的方式進(jìn)行處理但是，很多商業(yè)對(duì)象所需要的事務(wù)化的持久性管理沒(méi)有得到實(shí)現(xiàn)。 entity bean將持久化機(jī)制封裝在容器提供的服務(wù)里，并且隱藏了所有的復(fù)雜性。 entity bean允許應(yīng)用程序操縱他們就像處理一個(gè)一般的 java 對(duì)象應(yīng)用。除了從調(diào)用代碼中隱藏持久化的形式和機(jī)制外， entity bean還允許 EJB容器對(duì)對(duì)象的 持久化進(jìn)行優(yōu)化，保證數(shù)據(jù)存儲(chǔ)具有開(kāi)放性，靈活性，以及可部署性。在一些基于 EJB技術(shù)的項(xiàng)目中，廣泛的使用 OO技術(shù)導(dǎo)致了對(duì) entity bean的大量使用， SUN的工程師們已經(jīng)積累了很多使用 entity Bean的經(jīng)驗(yàn)，這篇文章就詳細(xì)闡述的這些卡發(fā)經(jīng)驗(yàn)： *探索各種優(yōu)化方法 *提供性能優(yōu)化和提高適用性的法則和建議 *討論如何避免一些教訓(xùn)。 法則 1：只要可以，盡量使用 CMP CMP方式不僅減少了編碼的工作量，而且在 Container中以及 container產(chǎn)生的數(shù)據(jù)庫(kù)訪問(wèn)代碼中包括了許多優(yōu)化的可能。 Container 可以訪問(wèn)內(nèi)存緩沖中的 bean,這就允許它可以監(jiān)視緩沖中的任何變化。這樣的話就在事物沒(méi)有提交之前，如果緩存的數(shù)據(jù)沒(méi)有變化就不用寫(xiě)到數(shù)據(jù)庫(kù)中。就可以避免許多不必要的數(shù)據(jù)庫(kù)寫(xiě)操作。另外一個(gè)優(yōu)化是在調(diào)用 find 方法的時(shí)候。通常情況下 find方法需要進(jìn)行以下數(shù)據(jù)庫(kù)操作： 查找數(shù)據(jù)庫(kù)中的紀(jì)錄并且獲得主鍵 將紀(jì)錄數(shù)據(jù)裝入緩存 CMP 允許將這兩步操作優(yōu)化為一步就可以搞定。 [具體怎么做我也沒(méi)弄明白，原文沒(méi)有具體闡述 ] 法則 2：寫(xiě)代碼時(shí)盡量保證對(duì) BMP和 CMP都支持 許多情況下， EJB 的開(kāi)發(fā)者可能無(wú)法控制他們寫(xiě)的 bean 怎么樣被部署，以及使用的container是不是支持 CMP. 一個(gè)有效的解決方案是，將商業(yè)邏輯的編碼完全和持久化機(jī)制分離。再 CMP類中實(shí)現(xiàn)商業(yè)邏輯，然后再編寫(xiě)一個(gè) BMP類，用該類繼承 CMP類。這樣的話，所有的商業(yè)邏輯都在 CMP類中，而持久化機(jī)制在 BMP中實(shí)現(xiàn)。 [我覺(jué)得這種情況在實(shí)際工作中很少遇到，但是作者解決問(wèn)題的思路值得學(xué)習(xí) ] 法則 3：把 ejbStore中的數(shù)據(jù)庫(kù)訪問(wèn)減小到最少。 如果使用 BMP,設(shè)置一個(gè)緩存數(shù)據(jù)改變標(biāo)志 dirty 非常有用。所有改變數(shù)據(jù)庫(kù)中底層數(shù)據(jù)的操作，都要設(shè)置 dirty,而在 ejbStore（）中，首先檢測(cè) dirty的值，如果 dirty的值沒(méi)有改變，表明目前數(shù)據(jù)庫(kù)中的數(shù)據(jù)與緩存的一致，就不必進(jìn)行數(shù)據(jù)庫(kù)操作了，反之，就要把緩存數(shù)據(jù)寫(xiě)入數(shù)據(jù)庫(kù)。 法則 4：總是將從 lookup和 find中獲得的引用進(jìn)行緩存。（ cache） 引用緩存對(duì) session bean和 entity bean 都是適用的。 通過(guò) JNDI lookup獲得 EJB資源。比如 DataSource,bean的引用等等都要付出相當(dāng)大的代價(jià)。因此應(yīng)該避免多余的 ： 將這些引用定義為實(shí)例變量。 從 setEntityContext(session Bean 使用 setSessionContext)方法查找他們。SetEntityContext方法對(duì)于一個(gè) bean實(shí)例只執(zhí)行一次，所有的相關(guān)引用都在這一次中進(jìn)行查找，這樣查找的代價(jià)就不是那么昂貴了。應(yīng)該避免在其他方法中查找引用。尤其是訪問(wèn)數(shù)據(jù)庫(kù)的方法： ejbLoad()和 ejbStore(),如果在這些頻繁調(diào)用的方法中進(jìn)行 DataSource的查找，勢(shì)必造成時(shí)間的浪費(fèi)。 調(diào)用其他 entity bean的 finder方法也是一種重量級(jí)的調(diào)用。多次調(diào)用 finder()方法的代價(jià)非常高。如果這種引用不適合放在 setEntityContext 這樣的初始化時(shí)執(zhí)行的方法中執(zhí)行，就應(yīng)該在適當(dāng)?shù)臅r(shí)候緩存 finder 的執(zhí)行結(jié)果。只是要注意的是，如果這個(gè)引用只對(duì)當(dāng)前的 entity有效，你就需要在 bean從緩沖池中取出來(lái)代表另外一個(gè)實(shí)體時(shí)清除掉這些引用。，這些操作應(yīng)該在 ejbActivate（）中進(jìn)行。 法則 5:總是使用 prepare statements 這條優(yōu)化法則適用于所有訪問(wèn)關(guān)系數(shù)據(jù)庫(kù)的操作。 數(shù)據(jù)庫(kù)在處理每一個(gè) SQL Statement的時(shí)候，執(zhí)行前都要對(duì) Statement進(jìn)行編 譯。一些數(shù)據(jù)庫(kù)具有緩存 statement 和 statement 的編譯后形式的功能。數(shù)據(jù)庫(kù)可以把新的Statement和緩存中的進(jìn)行匹配。然而，如果要使用這一優(yōu)化特性，新的 Statement要必須和緩存中的 Statement完全匹配。 對(duì)于 Nonprepared Statement,數(shù)據(jù)和 Statement本身作為一個(gè)字符串傳遞，這樣由于前后調(diào)用的數(shù)據(jù)不同而不能匹配，就導(dǎo)致無(wú)法使用這種優(yōu)化。而對(duì)于 prepared Statement,數(shù)據(jù)和 Statement 是分開(kāi)傳遞給數(shù)據(jù)庫(kù)的，這樣 Statement 就可以和 cache 中已編譯的Statement進(jìn)行匹配。 Statement就不必每次都進(jìn)行編譯操作。從而使用該優(yōu)化屬性。 這項(xiàng)技術(shù)在一些小型的數(shù)據(jù)庫(kù)訪問(wèn)中能夠減少 Statement將近 90%的執(zhí)行時(shí)間。 法則 6： 完全關(guān)閉所有的 Statement 在編寫(xiě) BMP 的數(shù)據(jù)庫(kù)訪問(wèn)代碼時(shí)，記住一定要在數(shù)據(jù)庫(kù)訪問(wèn)調(diào)用之后關(guān)閉 Statement,因?yàn)槊總€(gè)打開(kāi)的 Statement對(duì)應(yīng)于數(shù)據(jù)庫(kù)中的一個(gè)打開(kāi)的游標(biāo)。 Security 1．加密 對(duì)稱加密 （ 1）分組密碼 （ 2）流密碼 常用的對(duì)稱加密算法： DES和 TripleDE