something about ejb

最近借ejb3 ea出台的機會review了一下ejb2.1 spec，順手也總結一下我對ejb的認識：

Enterprise JavaBeans is an architecture for component-based computing.

ejb規範明確的指出了ejb是基於組件的結構，也就是說是component architecture的東西，那麼它的基本出發點就是技術問題和業務問題的SoC，只有在這個認識的基礎上我們才能來談論ejb的輕重、ejb的複用。曾經有位在國內頗有些名聲的dx跟我說：“COM和EJB都鼓吹模組化和複用，模組化是真的，複用是騙人的”，當時我就寒了，說ejb不易複用我是承認的，可如果說複用是騙人，我想估計是這位dx沒有注意到ejb的component architecture吧，任何component architecture的東西都不可能脫離開容器談複用，因為component和container之間有一種約定，哪部分歸容器，哪部分歸component都是事先說明的，比如transaction，如果容器支援，那麼component就不會寫transaction代碼，而是在deploy的時候用annotation聲明，反之則必須寫。在ejb裡，ejb container擔負了很多的支援人員，比如調度、cache、transaction等，造成ejb不易複用的原因是他純粹是業務組建想複用必須提供足夠的技術context。component結構保證了的複用性是在等價的技術環境內複用component，因此ejb只可在ejb contianer間或者提供等價的技術環境內複用，ejb複用不是騙人，只是需要有個正確的認識。

Enterprise beans are components of transaction-oriented enterprise applications.

這句話是這次看的時候才注意到的，然後就如醍醐灌頂一下讓我理解了ejb為什麼是這個樣子。對ejb的詬病裡有一部分是因為對比jdo或者hibernate，entity bean不能提供完整的oo建模的能力，的確是這樣，但是人家在規範裡已經說了，所有ejb都是面對transaction-oritented enterprise application的，根本沒有承諾要支援oo建模，為什嗎？因為在大型公司專屬應用程式裡底層資料庫需要額外的調優，dba可能會針對一些多並發訪問的表作調優（比如根據可能的資料需要拆表以減少並發），那麼在真正的高效能企業系統裡，出現完整oo模型的機會不大，甚至是沒有，而ejb格外強調是面向公司專屬應用程式的，因此只支援transaction-oriented enterprise application也是對的。至於輕量社區的指摘，只能是因為他們需要的系統沒有這麼複雜，沒有這麼企業，那麼為enterprise量身定製的ejb顯然不適用也就顯得有些重。sun曾經說過對於大多數人而言用不到ejb，的確是這樣的，國內尤其如此，可能90%的j2ee程式員都不會用到ejb，因為作的系統太小了，太不夠enterprise了。

review ejb 2.1之後，對比ejb3，ejb3採用javaBean作為component model，持久化上支援了oo建模以及其他一些持久化的方法，ejb3從enterprise java bean變成了可具有enterprise能力的javabean，可能改叫enhanced java bean更合適。