EJB提供的應用程序可移植性，抽象性以及由抽象性而提供的向後兼容性

首先，EJB不是人們想象中的樣子：重量級。實際上，它的目標與「重量級」這三個字偏偏相反：輕量級。

意味着它的目標在於減輕企業級軟件開發的任務。企業級開發的特色是什麼呢？它的特色是：認爲軟件只是一個工具。企業有不少事情須要考慮。軟件只是其中的一個環節。軟件不是全部。因此，儘可能減小在軟件開發上的投資以及最大化軟件資源的利用價值，對企業來講，是一件很重要的事情。

一切都是標準。EJB與SERVLET，JTA，JPA，JSP等同樣，他們都是標準。這是另外一個很重要的思想，也是理解J2EE的一個很重要的出發點------J2EE是一個標準：界於程序員與軟件服務提供者之間的標準。微軟作技術，SUN作標準。這是SUN與微軟的主要差距。微軟是小家。SUN纔是大「家」。

爲何我要用EJB？由於你要麼用EJB，要麼用別的東西。你總要用些東西。但不是每同樣東西都是標準。當你想把你的東西創建在標準之上的時候，EJB是惟一的選擇。有人把SPRING與EJB做比較，這是不能比的。把SPRING與EJB做比較，就等於把微軟與SUN做比較。由於技術與標準是不能比的。技術是實現標準的手段。技術不是標準。二者不屬於同一個範疇。所以不能比較。

設想我已經把應用創建在EJB的基礎上。由於EJB整個其實只是一個抽象化的體系，它已經囊括了幾乎全部我須要考量的事情如事務，安全，持久化，緩存，會話，消息，分佈式等等。而且，隨着時間的發展，它還會包括進更多的東西------以一種徹底抽象化的手段，這給我提供了莫大的方便：我不再用關心個人系統的可移植性，或隨着時間的轉移，個人應用的「潮流化」需求。由於萬變不離其宗：技術也許每天都在改變，可是我要的東西卻永遠都不會變或者說基本上，至少會變得很慢------我要什麼？我要事務，安全性，持久化，緩存，會話，消息，分佈式。。。。。。就跟我要吃飯同樣：我每天都要吃飯。雖然我天天吃的東西都不同。但吃飯這件事情，從本質上說，卻亙古不變。

若是硬要說它有問題。它惟一的問題即是，它並不包括全部。如隱私保護，IT審計，配置管理，質量管理等等，全部的東西，可是基本上全部這些東西都屬於個性化需求。它們並非全部應用或每一個人都須要的東西。可是至少，它標準化了一些東西。減輕了我很大的壓力。我只需FOCUS到個人特殊需求上：如做爲出發點的業務需求。我固然須要工做。但我也只想爲「我」工做。若是單獨爲了出行就獨自去修路，那是一件很愚蠢的事。單獨爲了事務去寫一個事務庫，那固然也是愚蠢的。爲何我會去作那件事情？個人工做究竟是什麼？

 

那麼，EJB與SERVLET是什麼關係呢？

首先要擺正的是視角。從程序員或軟件開發者的視角來看，EJB提供一個向（提供實現手段）下的標準，而SERVLET提供一個向上（提供服務）的標準。雖然EJB也能夠用來實現向上的服務，若是個人客戶端能夠接受採用一個對象級而不是一個文本級的WEB服務的話。EJB是一個對象級的標準。對象級的東西曆來都是複雜的，因此很難理解，如WEB SERVICE，CORBA，IIOP，IDL等（如不少人想象的相反，OO並非一種適合於人類的思考模式------咱們並非以對象的模式去思考問題的。關於咱們究竟是怎麼思考的，它一直是個問題）。這極可能是EJB很難流行的緣由之一。我以爲，若是SUN能嘗試把EJB與SERVLET結合起來，也許會是一個很好的推廣手段。象COLDFUSION開始作的同樣，EJB在COLDFUSION裏面用得就很舒服。所以在COLDFUSION環境裏面，EJB獲得很好的應用。。。。想象一下，即便在J2EE的環境裏面，居然不存在一種方便地使用EJB的手段。這難道不是個問題嗎？。。。。。。語義上的連結，在編程理論中是一個不容忽視的因素！

爲何EJB寧願提供WEB SERVICE服務卻不肯意提供更基礎的HTTP服務呢？若是是這樣的話，咱們還須要SERVLET嗎？WEB SERVICE真是個奇怪的東西，它先把對象級的東西封裝成文本級的東西，而後又在這個文本級的東西上面實現對象級的技術（RPC）。難怪人們理解不了它。它徹底超出了常理。

對象級的東西，只應該存在於本地應用即同一片地址空間如進程，或虛擬機中。

爲何它會進入通訊系統呢？。。。