重新思考J2EE的意義

最近抽空又重新拜讀了一本過去J2EE的經典書籍：Mastering Enterprise JavaBean 2nd Edition。這本書是在J2EE1.3的規格塵埃落定的時候出的，到現在少說也有大約三、四年的時間了吧！

綜 觀過去三四年Enterprise Java的發展，我發現有兩種互相矛盾的現象同時在發生。第一種現象，當然就是J2EE成為許多企業的標準資訊基礎架構。Mission Critical的Deployment到處都見到了J2EE的影子，J2EE的運用不可不說是欣欣向榮；然而相對的，抱怨J2EE太複雜的聲音也越來越 多─這就是我要討論的第二種現象。



針對J2EE的檢討最有建設性的恐怕就是Spring Framework這個近年來最成功的Open Source Java Project。首先必須要澄清的是，其實Spring Framework的用途不僅只在J2EE的層次；在我過去的工作當中，我們利用Spring Framework加上MX4J打造了分散式的網路流量分析代理程式。Spring的概念對於近兩年來的Java開發造成相當大的衝擊：更少的Code、 更大的彈性、更好的Design。另外比較眾所皆知的，Spring和JTA的整合讓過去EJB獨有的Declarative Transaction能夠發生在Pure Java Class的層次；這大大的簡化了任何Server Side系統開發的Effort。

Spring 的成功無庸置疑。在2004年的JavaTwo大會上，我興奮的利用有限的時間分享Spring簡化開發的成果；2005年的JavaTwo大會，歐宣修 先生再度的分享了Spring開發的心得。Spring目前所獲得的注意力，恐怕只有當年的Struts能夠相比擬。

然而在這邊我必須澄 清的是，Spring的使用不代表放棄J2EE。很多支持EJB的專家認為使用Spring這樣light-weight Framework即代表放棄J2EE的核心價值；而許多使用Spring的開發人員也認為從此以後再也不需要考慮到EJB。我個人認為：Spring的 出現，增強了許多J2EE沒有考慮到的地方，讓J2EE的開發能夠更漂亮；然而J2EE當初許多的設計以及考量，也不是現在的Spring能夠完全 Cover的。

當我重溫Mastering Enterprise JavaBean這本書的時候，這種感覺更強烈。我幾乎忘了當初EJB設計的目的，是要提供一個強大可靠的分散式Middleware系統。我身為一個 Programmer的本能，往往造成視野上的盲點：彷彿這世界就只有漂亮的API以及乾淨的Design，不需要去操心Clustering、Load Balance、Fail Over等問題。舉例來說，在Spring當中的Singleton/Prototype Instance，萬一有了內部狀態，要怎樣來做Replication來因應Fail-over？純粹的Servlet Container加上Spring Framework，要怎麼樣去處理非同步訊息這樣的系統需求？

從純粹的功能角度來說，一些狀態的東西可以藉由ServletContext、HttpSession來作為一種cache的機制；而非同步的訊息架構，可以利用另外控制Thread的方式來達成非同步的效果。然而這樣真的好嗎？我們來看看。

首 先，ServletContext本身不是Replicatable。這也就是說，ServletContext裡面的東西在Cluster的環境當中沒 有一種簡單的機制能夠達成同步。HttpSession是可以跨越實體Server的限制來達到同步，我也的確認為某些使用者操作的狀態很適合用 HttpSession來儲存；但是一個我們認定為後端Service的POJO，要另外想辦法手動把他放入HttpSession來維持Cluster 之間的同步狀態嗎？這樣不但手續多了一層，似乎也不是很好的Design。至於利用直接操作Thread的方式來達到非同步的效果更是危險。Thread 的狀態是無法跨VM做Replication的，因此這種Solution也不夠Reliable。

我想，了解一種技術想達到的目的和了 解它的限制一樣重要。Light-Weight Framework並不是Middleware；而Middleware的設計其實主要的焦點在於可靠性。我們可以利用一個像是Spring這樣的 Framework來幫我們隱藏以及簡化許多Server-side開發的細節，但是Spring仍然需要一個Middleware來解決High Availability的相關的問題。因此我相信，Spring和J2EE是相輔相成，而不是互相衝突的；EJB的專家應該仔細研究Spring的開發 模型能夠為J2EE帶來的彈性；而Spring的使用者也必須意識到Spring是一個Framework，並無法取代一個Middleware的價值。