RIA+REST如何来化解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应用”，将会是将来几年的一个技能热点。
#p#分页标题#e#
Java在对付REST的支持这个方面动作要迟缓的多。官方正在制订的JSR 311类型主要照旧面向差异的应用之间的集成，也就是主要包围SOAP所包围的规模，而不是面向RIA+REST这样一类新型的Web应用开拓方法。不外，一些支持REST的Java框架已经存在，也可以基于Adobe的Flex框架(本年之内就会开源)来做设计，这些框架使得基于Java做REST设计和开拓成为了一件较量容易的工作。我们不指望Sun已经有许多年了，日子不是一样过来了吗?Sun其实可以坦承：“我不做老大已经许多年了”。
综上所述，我认为支持REST对付JavaEE而言，意义甚至要比RoR更大。是否可以或许拥抱将来Web开拓技能的成长趋势，对付Java语言将来的运气来说是至关重要的。
