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

2019-11-18 12:34:32

字體：大中小

來源：轉載

供稿：網友

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

上一篇：Enterprise JavaBeans 基礎知識簡介

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