展望09年Java相關技術的興衰
對于2009年Java相關技術的變化，在這一點上，它與JavaOne大會給人的感覺非常類似，其中第一年充滿了規范、標準和新框架，緊隨之后的第二年就是規范的落實和前一年標準的成熟。在本篇文章中，我所提到的技術并不一定都是最新的，但是它一定是將被應用到現實開發中的。為了讓文章更生動有趣一點，我不僅僅會列出我認為會日漸重要的技術，還將列出那些我認為將逐漸衰落的技術。
日漸重要的技術
1.Java內容倉庫(JCR)
我認為，2008年是Java內容倉庫技術在規范上取得成功的一年，而在2009年則將是它被廣泛采用的一年。Jackrabbit是其中非常成功的一個實現。盡管在某些地方數據庫可能更加符合要求，不過我發現目前在越來越多地方，倉庫或許更加適合。最初的時候，Web內容管理系統似乎是唯一最適合Java內容倉庫的領域，但是我認為這一情形將在2009得以改變。
另外，我將來可能會對使用諸如db4o之類的對象數據庫更有興趣。我認為對象數據庫和倉庫之間有一些類似之處，因此對象數據庫如果日漸重要，也不是一件令人吃驚的事情。既然我們現在都在使用面向對象編程語言，為什么就不能使用一個對象數據庫呢?
2.Flex
從一個開發者的角度來看，Flex在2008年已經變成一個重要的備選工具，但是它似乎還缺少一些來自企業用戶的支持。我認為這個不足將在2009年得以彌補。
隨著企業越來越接受富互聯網應用(RIA)這個概念，它們也會發現Flex才是唯一真正切實可行的解決方案。就我個人來言，我更喜歡使用Flex來開發未來所有的Web應用。它與AIR聯合使用可以離線運行Web應用，這無疑是錦上添花的一個功能。我一直感覺在桌面應用和基于瀏覽器的Web應用之間存在一段距離。事實證明，AIR彌補了這個空白。
最后，我非常喜歡它的完全將業務層與展現層分開的特點。這是RESTful服務的成功之處，而Flex對這一點可以很好的支持。那么，我們可以想創建多少客戶端都可以，而不用管它們是使用Flex、Silverlight或傳統的AJAX技術。
3.RESTful服務
當然這不是一個新技術，但是隨著JAX-RS的發布，我認為在2009年企業將開始開發越來越多的RESTful風格的服務。
在2008年，SOAP網絡服務和RESTful服務的比例大約是70：30或60：40，顯然SOAP服務占據優勢。但是我認為在2009年兩者之間的比例將反過來。我甚至認為RESTful服務將實現更大的突破。
熱議技術：云計算，軟件即服務(SaaS)
眾多IT巨頭已經紛紛進軍云計算領域，云計算的出現，恰好解決了SaaS發展過程中面臨的一些問題，當SaaS提供商的客戶快速增加到一定程度，客戶所消耗的巨大資源將迫使SaaS供應商提供更多的硬件資源，但由于成本的問題，SaaS又不想花費大量資金購買硬件或帶寬資源的時候，云計算無疑是個不錯的選擇。
窮途末路的技術
1.ESB的衰落
坦白的說，我已經徹底對失去了對“SOA需要ESB”說法的信心。我只在一個項目(使用Mule ESB)中感覺這個說法言之有理，我們具有需要同步的多個完全不同應用(數據庫、命令行、服務)，Mule ESB證明了自己是這個問題的最完美解決方案。在其它項目中，我看到企業只是簡單的使用一個ESB來代理/路由/監控服務請求。但是我可以使用Apache來完成這些任務。
而且，SOAP只是企業整合的途徑之一，但并非唯一途徑。另外，如果人們甚至沒有任何企業整合需求時，又有多少人會實施SOA呢?
2.Web框架/AJAX的下滑
我曾經認為所有這些Web框架都是好東西，我喜歡嘗試新產品，我喜歡具有創新性的事物。但是現在它們卻讓我感到厭煩。
先來說一下AJAX，的確你可以使用它來做出許多非常酷的東西，但是這些是否是你想要或真正需要的呢?很明顯，人們沒有從需要的角度來考慮其能實現什么功能，而只是為了實現這個功能而使用這個功能。不過我認為，如果你不能放棄你喜愛的Web框架，那你將不得不繼續使用AJAX。
3.復雜的“組合”
這是Web框架下滑的一種延伸影響。我對到處充滿各種“組合”的過去記憶深刻，我們有Hibernate、Struts和Spring。然后我們必須增加一個安全框架和Web服務客戶端，諸如此類舉不勝舉。
我們最終得到的是一個相當復雜的組合，因為這樣就有了一個真正模塊化的應用程序，你可以使用其它同類技術來替換出特定的層。不過，這沒有多大意義，這種需要很少發生。一旦一個組合被設定后，很少再會去修改它。現在我喜歡讓我的應用程序盡可能的簡單。我寧愿手動編寫一些代碼，也不愿意去增加另一個框架。
其它可疑技術：商業化開源，應用程序服務器
對于商業化開源這個業務模式，我沒有異議，我懷疑的人們對它的期望太高，一個產品不能因為開源了就放松對其投入，這樣會致使其體系架構變陳舊，代碼質量下滑。
【編輯推薦】
