EJB 叫我如何愛上你 --評《精通EJB》及EJB

2019-11-18 12:34:32

字體：大中小

供稿：網(wǎng)友

　　先談?wù)劇毒‥JB》這本書，Ed Roman是聞名網(wǎng)站TheServerSide.com的CEO,自己也擁有一家專門從事中間件開發(fā)的公司MiddleWare, 另外兩個合著者Tyler Jewell是BEA的J2EE專家，Scott W. Ambler也是面向?qū)ο笤O(shè)計和靈敏建模的大師，由這樣的專家寫出來的書籍，的確堪稱經(jīng)典，讓人看得放心，讀得順心。
　　
　　整個J2EE架構(gòu)是個非常復(fù)雜的架構(gòu)，而《精通EJB》用461頁（中文版）就把EJB從底層原理到實際應(yīng)用部署都講的清清楚楚，實在難能可貴。作者采用循序漸進的方式講述EJB, 構(gòu)造了一個非常好的學(xué)習(xí)EJB的思路，作者很細心的考慮了讀者看書時感受，告訴了讀者什么時候該關(guān)注什么內(nèi)容，什么內(nèi)容可以暫時放在一邊。在內(nèi)容講述上，作者基本采用提出問題，回答問題的方式，語言簡明扼要，卻又一語中的，讓你心領(lǐng)神會。讀完此書，的確能讓你把握EJB了(本書原名Mastering EnterPRise javaBeans，所謂精通其實就是把握的意思，要精通一門技術(shù)，哪是讀完一本書就能做到的呀)。
　　
　　本人從事Java的設(shè)計和開發(fā)也有三年了，但一直只做前端網(wǎng)站服務(wù)器和Java應(yīng)用程序，對EJB一直只有耳聞，并不十分了解，隨著業(yè)界對J2EE平臺的不斷投入，大量優(yōu)秀的設(shè)計思想都在EJB平臺上得到了應(yīng)用，所以我也非常想在以后的業(yè)務(wù)系統(tǒng)開發(fā)中采用EJB技術(shù)，但一項新技術(shù)的采用，絕不是因為它很時髦就采用的，應(yīng)用一項新技術(shù)以前，你一定要先了解它的基本原理，它能夠達到的功能和性能，有什么優(yōu)點和缺點，你的開發(fā)人員能不能把握它，你能否把自己獨特的技術(shù)優(yōu)勢應(yīng)用到這個平臺中去等等。《精通EJB》這本書可以達到這個目的，象我這樣希望考察EJB的人都可以看看這本書，從沒有接觸過EJB，希望將來成為EJB開發(fā)人員的程序員也應(yīng)該看看這本書。
　　
　　但在買這本書之前，你應(yīng)該注重以下幾點：
　　1、你應(yīng)該有Java的基礎(chǔ)知識，至少開發(fā)過一些Java應(yīng)用程序，最好開發(fā)過Java的企業(yè)信息系統(tǒng)，對網(wǎng)站技術(shù)、數(shù)據(jù)庫技術(shù)、通訊等都有個基本了解，假如你只是個剛畢業(yè)的菜鳥，現(xiàn)在還不是看這本書的時候
　　2、這本書是對EJB技術(shù)的全局介紹，它是讓你了解EJB的書，看完這本書，并不能讓你真正進行EJB開發(fā)，你至少還應(yīng)該讀一些關(guān)于EJB設(shè)計模式的書，比如《J2EE核心模式》等，避免對EJB技術(shù)的盲目應(yīng)用，EJB是一項復(fù)雜的技術(shù)，運用得不好會適得其反，給你的項目帶來災(zāi)難性的后果。
　　3、EJB只是一種規(guī)范，看完這本書你就知道，企業(yè)應(yīng)用的很多因素，比如負載均衡、容錯、事務(wù)治理策略、系統(tǒng)監(jiān)控等，EJB本身并沒有做具體的實現(xiàn)規(guī)定，很多方面必須依靠J2EE平臺生產(chǎn)廠家來實現(xiàn),而不同的J2EE平臺廠家，在實現(xiàn)上有很大的差異，要真正提供一個好的企業(yè)應(yīng)用系統(tǒng)，選好你的J2EE平臺產(chǎn)品是非常重要的事情。《精通EJB》這本書專注于EJB技術(shù)本身，對實際的J2EE產(chǎn)品基本沒有涉及，要真正應(yīng)用EJB技術(shù)，你應(yīng)該還要去考察具體的J2EE平臺產(chǎn)品，看廠家是如何解決上面提到的那些具體問題的，廠家的產(chǎn)品僅僅通過J2EE認證，并不能保證能夠用它就能構(gòu)造出性能卓越，運行穩(wěn)定的系統(tǒng)。
　　
　　EJB卻不是個好技術(shù)
　　遺憾的是，看完這本書，卻讓我做出了放棄EJB的決定,J2EE是一個非常好的企業(yè)應(yīng)用設(shè)計規(guī)范，它采用了大量優(yōu)秀的設(shè)計思想，但非常遺憾，作為J2EE的核心，EJB的設(shè)計方案讓人失望，J2EE設(shè)計的目標，就是讓企業(yè)應(yīng)用開發(fā)人員能夠在一個規(guī)范的平臺之上，不用考慮具體的技術(shù)問題，專注于業(yè)務(wù)邏輯實現(xiàn)，就可以開發(fā)出性能、穩(wěn)定性、可治理性各個方面的都達到較高水平的系統(tǒng)。但我很難想象，在EJB技術(shù)平臺能夠?qū)崿F(xiàn)這個目標,實際上，它存在根本的缺陷:
　　1、EJB技術(shù)的一項最根本的技術(shù)缺陷來自于對象序列化技術(shù)，對象序列化技術(shù)是EJB跨平臺通訊的基礎(chǔ)，所有的EJB之間通訊都依靠了對象序列化技術(shù)的應(yīng)用。從設(shè)計架構(gòu)上看，這是個簡單清楚的的設(shè)計，通過對象的序列化實現(xiàn)了對象在多個進程之間的復(fù)制傳遞。但非常遺憾的是，設(shè)計者對于Java平臺對于對象序列化的實現(xiàn)的考慮卻做的很草率，對象序列化的性能很差，我想很多人可能沒有注重到這一點，我也是在做到底層的開發(fā)時才發(fā)現(xiàn)這個問題，我們開發(fā)的一個企業(yè)應(yīng)用系統(tǒng)必須要實現(xiàn)跨Java平臺和C++平臺之間的訪問，為了實現(xiàn)跨平臺通訊，我們設(shè)計一項通用的數(shù)據(jù)表達格式，采用了xml格式實現(xiàn)了多種平臺之間的數(shù)據(jù)傳輸，大家知道把數(shù)據(jù)打包成XML格式，再從XML格式解包系統(tǒng)開銷是比較大的，會導(dǎo)致通訊性能下降，因此我們對此進行了優(yōu)化，剛開始的想法是在相同的平臺之間通訊時，將數(shù)據(jù)打包成二進制格式傳輸，只有在不同平臺之間傳輸時才采用XML格式。我們發(fā)現(xiàn)Java提供了對象序列化的機制，可以把一個對象直接序列化成為二進制數(shù)據(jù)傳遞，所以我們在Java平臺和Java平臺之間傳輸數(shù)據(jù)時，采用序列化的方式進行數(shù)據(jù)的打包和解包，但讓人驚奇的是，經(jīng)過我們的性能測試，采用了對象序列化技術(shù)之后，我們發(fā)現(xiàn)通訊的性能反而比原來采用XML格式打包方式更慢了，后來經(jīng)過測試也的確驗證了，將一個對象序列化成二進制數(shù)據(jù)的速度的確慢過你把它用XML格式打包成字符串，再轉(zhuǎn)換成二進制數(shù)據(jù)的速度。具體的原因我不具體說了，你寫個簡單的測試程序試一下就知道了。可想而知，基礎(chǔ)支撐的性能如此之差，在此之上構(gòu)造的EJB平臺，它的性能能好嗎？
　　
　　當(dāng)然，這個問題也不是不可避免的，你只要重載對象的序列化方法，實現(xiàn)你自己的序列化方式就可以達到高性能的序列化。但是你想象一下，為每個對象寫序列化函數(shù)，這是個多大的工作量，為什么SUN的JDK本身至今也沒有實現(xiàn)高性能的序列化？僅僅考慮設(shè)計架構(gòu)上的簡單性，而把大量的性能優(yōu)化工作推給業(yè)務(wù)開發(fā)人員，是不負責(zé)任的做法。
　　
　　2、另一項EJB技術(shù)更為嚴重的缺陷來自于RMI（遠程方法調(diào)用），EJB更限定必須遵守COBRA規(guī)范的RMI-IIOP技術(shù)，實際上我質(zhì)疑所有采用分布式對象調(diào)用的技術(shù)，包括COBRA、COM+、RMI等，這種技術(shù)的根本原理上都是一樣的，通過本地的一個遠程對象代理，通過網(wǎng)絡(luò)上的多次通訊實現(xiàn)對遠程對象的方法調(diào)用,這種設(shè)計架構(gòu)的初衷是隱藏對象的具體位置，可以讓對象使用者不用關(guān)心對象的實際位置，但是這種方法的實現(xiàn)性能極差，象COBRA這種系統(tǒng)的設(shè)計者當(dāng)初就沒有把性能問題作為一個重要問題去考慮，但正是性能問題，導(dǎo)致隱藏對象位置這個目的實際上也并沒有達到，因為通過通訊訪問遠程對象的性能太差，因此使用者處于系統(tǒng)性能的考慮不得不考慮遠程對象和本地對象的區(qū)別。更可悲的是，EJB的上層設(shè)計上也沒有能夠把遠程對象和本地對象的差別消除，從EJB設(shè)計人員自己的說法，遠程對象調(diào)用和本地對象調(diào)用在語義上就無法統(tǒng)一起來。既然上層就必須區(qū)分遠程對象和本地對象，那底層技術(shù)上就完全沒有必要采用這種性能很差的設(shè)計了。從COBRA開始，這種分布式對象訪問的技術(shù)就是不成熟的，EJB墨守了分布式對象技術(shù)的陳規(guī)，導(dǎo)致自己背上了沉重的包袱，使用者必須很小心地使用EJB技術(shù)，稍有不慎就會導(dǎo)致系統(tǒng)性能大幅度下降。我們從大量的J2EE設(shè)計模式中看到，很多設(shè)計模式都是為了補救EJB的性能缺陷而設(shè)計的，與其在一個有根本缺陷的平臺上施展你的才能彌補、避開系統(tǒng)的種種缺陷，不如放棄這種平臺，消除問題的根源所在，把你的精力放在能為客戶創(chuàng)造價值的地方去。
　　
　　我認為，在分布式系統(tǒng)中，對象與對象之間的通訊應(yīng)該采用輕量級的消息傳遞，我們不能為了實現(xiàn)面向?qū)ο蟮脑O(shè)計就一定要在每個地方強制使用面向?qū)ο笳{(diào)用的方式，面向?qū)ο蠹夹g(shù)本身也是需要不斷改進的，我們在自主開發(fā)的中間件平臺中，采用輕量消息傳遞的方式實現(xiàn)多個服務(wù)對象之間的數(shù)據(jù)交換，同樣實現(xiàn)了服務(wù)對象具體位置的隱藏，而且實現(xiàn)了很高的性能。當(dāng)然還可能存在其他很多高性能的解決方案，但我堅信EJB所基于的這種分布式對象調(diào)用技術(shù)遲早會被拋棄。
　　
　　3、與前面提到的兩個根本缺陷相比，EJB技術(shù)的其他方面的問題就顯得微不足道了，比如EJB本身定義的復(fù)雜性，實體Bean的性能問題等等，我相信這些問題一定可以解決，或者很輕易被新的設(shè)計替換掉，比如復(fù)雜性問題可以通過工具解決，實體Bean可以用輕量級的對象持久化層代替等等。
　　
　　我想說的是，EJB的很多設(shè)計方面是非常優(yōu)秀的，有許多設(shè)計思想值得我們借鑒采納，但由于它本身存在根本的缺陷，導(dǎo)致了它無法成為一個可以長期持續(xù)發(fā)展的平臺，它需要徹底的改變，EJB就像一個成長中的少女，在她真正向成熟轉(zhuǎn)變以前，你可以欣賞她，但不值得愛上她，更不要著急把她娶回家。

上一篇：Enterprise JavaBeans 基礎(chǔ)知識簡介

下一篇：EJB3.0概覽以及新版本的諸多進步