程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> RIA+REST如何來化解Java劣勢

RIA+REST如何來化解Java劣勢

編輯:關於JAVA

Java的劣勢在何處?與前些年相比,現在看的已經很清楚了,Java的劣勢就在於做Web表現層的開發。Web表現層開發需求變化頻繁,Java這類靜態類型的語言不夠敏捷,嚴重影響了開發的效率。

而JavaEE的一個最大的缺點,就是企圖在服務器端搞定一切,我將這種開發方式稱作“傳統集中式的開發方式”。標准的J2EE三層架構——Web表現層、業務層、持久層,也許對於傳統的基於HTML表單的Web應用來說是恰當的,但是現在已經顯得落伍了。JavaEE企圖在服務器端完全搞定Web表現層的開發,給自己制造了一個大麻煩。無論是從這門語言本身,還是從支持這門語言主要的公司Sun、IBM、BEA、Oracle來說,他們並不擅長此道。擅長此道的是哪些公司呢?Adobe/Macromedia、M$、Borland/CodeGear。

如果Web表現層必須要在服務器端開發,Ruby on Rails的優勢與JavaEE相比要明顯的多。RoR要比任何主流的JavaEE Web表現層框架和技術(Struts、WebWork、Spring MVC、JSF、Tapestry、etc.)更加靈活,學習成本更低,開發效率更高。

換個思路來思考,如果我們不再假設客戶端就是幾乎毫無智能的Thin Client將會如何?假設我們能夠充分利用客戶端的Ajax組件庫和各種RIA技術,將Web表現層完全或者絕大部分前推到客戶端來開發,並且通過REST風格的API來與服務器通信,那麼服務器的角色就變成了類似於Web服務提供者(注意:這裡和Web服務還是有很大的差別,因為REST在這裡是用於同一個應用內部的通信,即連接一個應用的客戶端和服務器端)的角色,這樣就能夠極大地簡化服務器端Java的開發工作,讓它從自己所不擅長的領域退出來,集中精力做自己最擅長的一些工作。

這個趨勢其實在3年多前我在JavaEye論壇中宣傳基於XMLHttpRequest的開發方式的時候就已經看到了,現在這個趨勢已經越來越明顯了,新一代Web開發方式的面貌已經逐漸浮出水面。Adobe AIR/Flex、M$ WPF/Silverlight都是這樣一類的開發方式,當然Ajax也可以以這種方式來做開發。我給這樣一類開發方式取名叫做“RIA+REST”。

在服務器端搞定一切當然也有好處,因為這樣可以獲得最佳的控制,安全問題解決起來也比較容易。但是其代價就是無法得到最佳的交互設計,強迫用戶不得不承受降級的使用體驗。如果這樣的用戶體驗是能夠接受的,那麼采用這種方式做設計和開發問題不大。但是如果這樣的用戶體驗是無法接受的,那麼就需要嚴肅地考慮RIA+REST的開發方式了。與傳統集中式的開發方式相比,這是一類新型的分布式的開發方式,在一些方面(交互設計、服務器端架構)得到了簡化的同時,也會使得一些方面(服務器端的控制能力、安全性)復雜化,所以要求架構師作出慎重的權衡。分布式應用必然會帶來很大的復雜性,但是REST無疑是基於Web的分布式應用的最理想的架構風格,在Web領域REST的優勢要比RPC和分布式對象等架構風格大的多。同時REST是簡練實用的,可以很大程度上降低分布式應用的巨大復雜性。

根據我的經驗,在絕大多數中小型項目中,Web表現層開發的工作量要比後面兩層的開發工作量的總和還要大,也就是占到項目開發工作量的一半以上。當用戶需要較為苛刻的使用體驗時,傳統集中式的開發方式完全無法滿足要求,而必須由Ajax來補充。然而,對於有復雜交互需求的應用來說,RoR應用的開發效率同樣也會受到基於DHTML的開發效率的拖累,而無法充分體現出其敏捷的優勢。

如果Java將做Web表現層開發的負擔卸掉,讓客戶端的RIA技術來承擔,那麼Java在服務器端開發中與Ruby相比的劣勢就不是那麼明顯了,甚至在很多方面還有優勢。從整體架構的開發效率來考慮,

RIA + REST + Java

RIA + REST + Ruby

兩種架構組合也許可以達到大致相同的級別,即使Java在開發效率上仍有劣勢,但是也不會像在傳統集中式的開發方式中那樣懸殊。有很多傳言說基於RoR開發的項目與基於Java開發的項目相比,開發效率能夠高出5-10倍。我雖然對於Java並不樂觀,但是對於RIA+REST這種新的開發方式,我估計開發效率的差距應該可以降低到2倍左右。不過開發效率只是一個方面,如果服務器端的代碼經過良好重構,重用性非常好,不會在半年之後就成為必須要拋棄的遺留代碼,那麼Ruby在開發效率方面的巨大優勢也許只會停留在最初的階段。隨著代碼的積累,這種開發效率的優勢會逐漸降低下來。

Ruby會不會擁抱RIA呢?RoR 2.0將會是完全基於REST設計的開發框架,他們現在擁抱REST,就是為將來擁抱RIA做准備。對於傳統集中式的開發方式來說,應用REST當然也會帶來很大的好處,但是我認為這並不是RoR的主要的目的。RoR擁抱REST,是希望使自己在將來的技術變遷過程中處於一個非常有利的位置。對於未來Web開發技術的發展,REST處在一個核心的位置,它是連接客戶端和服務器端的紐帶,REST也會極大影響客戶端架構和服務器端架構的設計和建模。“面向資源的Web應用”,將會是未來幾年的一個技術熱點。

Java在對於REST的支持這個方面行動要遲緩的多。官方正在制訂的JSR 311規范主要還是面向不同的應用之間的集成,也就是主要覆蓋SOAP所覆蓋的領域,而不是面向RIA+REST這樣一類新型的Web應用開發方式。不過,一些支持REST的Java框架已經存在,也可以基於Adobe的Flex框架(今年之內就會開源)來做設計,這些框架使得基於Java做REST設計和開發成為了一件比較容易的事情。我們不指望Sun已經有很多年了,日子不是一樣過來了嗎?Sun其實可以坦承:“我不做老大已經很多年了”。

綜上所述,我認為支持REST對於JavaEE而言,意義甚至要比RoR更大。是否能夠擁抱未來Web開發技術的發展趨勢,對於Java語言未來的命運來說是至關重要的。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved