<b>RIA和REST若何化解Java的劣势</b>[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语言将来的命运来说是至关重要的.