Java Web层的下一个王者是谁?

经过数年的“框架大战”,Java界的各种框架找到了自己应有的位置。

Spring+Hibernate+Struts已成为Java开发的主流体系。在这个体系中,Spring+Hibernate的地位应该说短期内是难以撼动了。除了新兴的Jboss Seam作为挑战者之外,几乎难有劲敌。有趣的是当初Spring、Hibernate作为挑战者,将官方的EJB成功挑落马下;这次反倒是官方的EBJ3成了挑战者,不知结局如何。

Java B/S编程中历来战火最激烈的其实还在Web层,框架的数量最多,争议最大。
一切由Struts而起,而Struts最终也坐稳了第一个时代的王座。在技术层面,Struts 1.x已经被无数人抱怨过、批评过,但终于还是稳坐王位,这充分说明了习惯的力量。“稳定压倒一切”,这句话在IT技术领域仍旧适用。
其实IT应用技术,什么新鲜玩意并不难学。难的是标准化和规范化。每个程序员都有自己的思路和习惯,写出来的代码自然是五花八门。Java何以成为编程界的老大,很重要的一点在于Java的规范化。这种规范化很高的语言适用于多人合作的大型项目,便于沟通和理解,也就便于集成和维护。Java世界为什么会框架横飞,说到底还是规范化的需要。纯JSP和Struts写Web谁快,摆明了是JSP。那撑饱了用Struts?原因在于100个人写出来的JSP,有100种写法;而100个人写出来的Struts,基本相似。Struts之成功,正缘于其在Java Web层的规范化方面所做出的贡献。

然而长江后浪推前浪,Struts 1.x的技术缺陷毕竟是隐患。
Sun力推JSF,打算一雪Web层框架缺失之耻。可惜JSF既要沿用Swing的技术路线,又要学ASP.NET,还要照顾产商的IDE,结果搞了个四不象,弄得里外不是人。当然Sun的技术实力毕竟是超强的,只要别重蹈EJB的覆辙,拿出点专断的精神(像这两年的NetBeans),做出像Swing那样水准的东西,JSF当大有作为。JSF现在比较有优势的是对Ajax的集成,这一点走在了其他框架的前面。

而Struts就更没有志气了,把WebWork换了个标签,凑出个Struts2,Bug多多。说实在话,根本不如原版的WebWork。如果不是靠了原先的fans捧场,根本就没得混。不过Struts原本就不是以技术取胜的,靠的是抢占先机带来的习惯优势。如果原先的fans们在这两年内都能转到Struts2,那么Struts二世仍将雄霸天下。

综上所述,未来两年,JSF与Struts将展开Java Web框架的最终战争。
以笔者愚见,结局有二:一是不论Struts还是JSF获胜,Java Web层都将结束混战的局面,这对Java Web开发的标准化是非常有利的,并有助于巩固Java在B/S界的地位;二是Struts1.x、Struts2、JSF三分天下,必然从整体上削弱Java在B/S界的竞争力,并将进一步被RoR、ASP.NET、PHP所蚕食。

有兴趣者参加讨论。

个人觉得java还是比较有前途的,就是上面说的规范化。虽然在web层操作是比较麻烦,但随着以后的发展前进会有一个好的框架出现的。

楼主很多想法我觉得都非常好,“难的是标准化和规范化”这句非常喜欢。至于下一个王者,呵呵,那个简单、好用那个就是王者。

我一向不看好EJB,对于Struts也不抱有很大的希望,不过两者选我还是希望选择Struts。可能用不了1年就会有一种新的流行框架出现。

时尚需要引领:)教育、图书、宣传跟上了,本身如果没有太大的问题就可以流行了。

struts+Spring+hibernate虽好,但开发效率不高,大量CRUD很浪费时间和精力。下一个王者则是那些快速开发框架(如Grails等),既继承以前良好的分层架构,又能够提高开发速度。

原来banq兄也看好快速开发框架,呵呵。

我有一个简化的判定框架好坏的个人标准:观察数据实体(对象或者表)增加一个属性时,系统代码要更改多少处,要改的地方越多的框架,就是越不好的框架

很多时候可重用性和可维护性、可靠性是矛盾的:分层越多的系统,可重用无疑会越好,但我们把东西掰得太碎,在组装上层功能时的复杂性也就增加了,可靠性也就会降低,可维护性也会变差。所以问题分解的粒度真是很难把握,太粗和太细都会有问题。

此外,还有,绝大部分的内存泄露的案例都发生于复杂分层的系统,事务不一致也多发生于复杂分层的系统,性能优化障碍也多发生于复杂分层的系统等等。

  
leebai@xjawa
 


[该贴被leebai于2007年04月20日 21:53修改过]

“很多时候可重用性和可维护性、可靠性是矛盾的:分层越多的系统,可重用无疑会越好,但我们把东西掰得太碎,在组装上层功能时的复杂性也就增加了,可靠性也就会降低,可维护性也会变差。所以问题分解的粒度真是很难把握,太粗和太细都会有问题。”
深有同感!

>以问题分解的粒度真是很难把握,太粗和太细都会有问题

基本同意这样想法,以前我也觉得很难把握,但是我现在发现一个原则:分解的粒度是设计领域,如果我们在分析领域来进行分解,问题就好解决多,而且“问题分解”在如今框架支撑环境下,大多数就变成对“需求问题的分解”,这就是分析。

有了好的分析方法,如四色图 MF的分析模式 和Evans DDD等等,就不至于造成给设计人员造成模型粒度分解问题。

为什么我现在大力倡导OO,而不是在两年前,虽然当时OO也很盛行,主要就是你说的问题,但是当我发现现在软件方法已经将模式分解为分析模式和设计模式,与业务相关的模式在分析领域解决(可解决业务模型的重用),与业务无关的、与构件组件相关模式在设计领域解决(可解决构件功能重用,这些都以框架形式出现)。可以说,OO领域中很多重大可操作性问题都已经基本解决。

说到这里 ,好像与本主题无关,其实关键在下面得出的结论。

所以,如果又想做到软件质量好,也就是重用性 扩展性都好(分业务性质和构件性质),又做到快速性好(以前分析和设计分离,分析半年,设计半年),那么无疑从分析和设计两个方面一起抓。这项构想目前在两个技术上得到实现:MDA(DSL)和Evans DDD,而Evans DDD无疑是相对成熟,这也是Martin Fowler在该书前言对其肯定的原因。

如今,在非Java领域,RoR是一个遵循Evans DDD出现的快速工具,这是对Java提出的挑战,所以Java现在有了Grails,好像性能还比RoR高:
http://www.jdon.com/article/30295.html

说了这么多,还是改不了喜欢做广告嫌疑,我主持开发的JdonFramework无疑也是向这个方向努力的,JiveJdon作为JdonFramework一个应用,代码非常简单,前几天添加一些防spam功能也非常快速,当思路确定以后,添加功能代码工作几乎是在半个小时内完成的,就象将文章思路写在纸上一样流畅。我相信,做编程就应该这样,将主要精力放在构思创意上。
[该贴被banq于2007年04月23日 09:38修改过]

也许如板兄所言,这几年技术确实有进步(我已经好多年不关心数据库后台情况下的面向对象分析和设计了,在ejb1.1时代我就认为OO无法适应RDBMS的存储),看来得找时间补补课了。

不过总的来说,只要是用RDBMS保存系统状态(持久化),不管OO分析和设计在新技术下能否顺畅,我还是怀疑OO状态与RDBMS状态的转换过程在编程上能够顺利匹配,并提高生产效率(更不用说运行效率)。还有,板兄的快速添加“防spam功能”例子,我认为不是企业应用中的典型情况,因为此例不牵涉“RDBMS持久化状态”,而非DB持久化时的OO分析和设计,其效率和各种其他各种优点,我是完全认同。

leebai 非常谦虚。

确实OO与RDBMS是不匹配的Mismatch,而且从一开始就在争论,还会争论下去,甚至成为技术政治。

我是新手,希望多多学习.

前面几贴跑题了,拉回来。


我的观点:Web层框架的下一个王者,如果不是Ajax,将是业界的悲哀
-------------------------------------------------------------

不论Struts还是JSF,还是.net,或者此前的任何主流Web程序,都是在服务器上构造用户界面,而客户端只是单纯显示界面,这种技术架构和早期的字符终端模式本质上是一样的,是原始、落后、丑陋、低效率、混杂的

之所以这么多年的web程序都是这种模式,是因为:最初HTML是作为“带链接的文档”,而非“交互程序界面”而设计的,为了在HTML下实现“交互程序界面”技术,后来HTML中增加了<Form>,可以实现简单“交互”,再后来又有了javascript,“交互”又进了一步,但Form、javascript的可编程性都太差,所以每次交互都必须由服务器代替客户端来构造下一步的用户界面,客户端只是单纯的显示,这就是“瘦客户”的由来。这里大家应该看出来:Web应用的客户端之所以“瘦”,并不是因为“瘦”好,而是因为早期的浏览器是为HTML而生,先天不足。不管是Struts还是JSF,或者.net,本质上都是为这种先天不足的“弱智型”浏览器而设计的,所以问题就出来的:今天的浏览器还是这么“弱智”吗?

答案是否定的,其实自从1997年IE4推出后,答案已经出来了,只是大部分人没有看出来而已。IE4和此前的浏览器到底有何不同呢?NetScape Navigator真的是因为微软的捆绑政策而被挤垮的吗?真正的答案是:IE4提出了DHTML,是DHTML打败了Navigator。

DHTML为什么有这么大能量?在DHTML之前,DOM只是一个抽象的概念,在浏览器端,编程语言(javascript)和其编程接口(API)是混杂在一起,我们分不清、NetScape也没告诉我们document.write()到底是javascript语言本身还是编程接口。直到如今,很多关于javascript编程的书籍也把javascript语言和编程接口混为一谈,很多程序员还会去javascript语言的函数参考中去找document.write()的资料,这就是NetScape留给我们的技术遗产。IE4的DHTML第一次以微软的方式实现了DOM,将javascript语言和DOM编程接口彻底分开,IE4也成为第一个完整地实现了基于DOM理念(不是DOM标准,但超越当年的DOM标准)的浏览器,无论是功能性、稳定性、可扩展性、可编程性,都完全超越了Navigator,所以IE4想不挤垮Navigator都不可能。我从98年开始涉及Web开发,2000年后专职做Web开发,一直到现在,Web前端开发的主要参考文档还是1997版MSDN Lib中的DHTML参考,10年也没觉过时,这就是核心技术的生命力。


回到主题,再谈Web层的架构。如今,DHTML/DOM已经非常成熟,浏览器的可编程性已经非常好,2005年,业界也“良心发现”似地提出并认可了"Ajax",所谓的“富客户端”系统(我认为用“中客户端”更合适,即界于胖客户与瘦客户之间)也被追捧。问题是,像Struts、JSF、.net这些由服务器端构造界面的框架是否适合“富客户端”系统?是否有必要在这类架构上修修补补来适应“富客户端”系统?在浏览器功能非常强大的今天,服务器的CPU和内存资源是否还要为早期的“弱智”浏览器背书,或者说继续为一个健康的成年人当保姆?未来的Web架构是否应该继续基于“弱智”前端来设计?


答案当然也是否定的。“富客户端系统”已经和原始的“动态网页”不是一个层次的东西,“富客户端系统”界面的强交互性,使用户界面编程空前复杂,这种客户端的复杂如果由服务器端来解决,只能使问题更加复杂。因此理想的Web层模型应该是:

-----------------------------------
浏览器完全负责界面构造和流转(服务器对界面构造和流转只提供HTML服务,即由www服务器提供静态HTML页面,而不是由应用服务器提供动态页面);而应用服务器只提供业务服务,即只接受业务请求(http Request的含义与传统不同,服务器不参与界面层功能)。
------------------------------------

在这种新的模型中,应用服务器从界面构造和流转控制的繁重任务中解脱出来,专注于业务服务,MVC的控制器被自然废除,后端只需编写业务服务代码,这也刚好与WebService、SOA的概念吻合。这种模型比Struts、JSF、.net,都要漂亮得多。


最后,总结一下:很多人还认为Ajax只是相当于网页的花边装饰,或者是Web程序的局部效果;在我看来,整个应用都应该基于Ajax构造。可以预测,Ajax+SOA将颠覆传统的Web程序结构,Web应用将走出“服务器动态网页”时代,进入“富客户端”+“面向服务编程”的光明未来。


上面的Web架构理念,我已经做了一个初步实现,有兴趣的朋友可以参考:

7wxAop@xjawa.org

[该贴被leebai于2007年04月26日 14:51修改过]

看到李白兄上边这篇帖子,深有同感。web服务器只提供只有他能完成的功能,其他显示的功能全部交给前台处理的方案我也提出过,见这篇文章。我也在实现这个结构的设计方案,但现在处于初级阶段,还在测试中。由于本人开发大型站点经验不足,现在进入了卡壳期,看了您的7wxAop开发框架觉得自己差的太远了,致敬!

s79客气了,呵呵:

我也看过你的《一个小的WEB项目中的实现方法讨论 - 又一篇[原创] 》,其实基本上所有大的方面你都想到了,看这里:

http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=31458&message=23105050#23105050

我预测web开发的下一个革命:基于富客户端+业务服务的“企业应用开发技术”与基于动态网页的“动态网站开发技术”彻底决裂(就像当年c/s结构与终端/主机结构彻底决裂一样),企业应用开发技术将进入第四代。在这场革命中,ajax和webservice(指概念,不指标准)只是两个导火索,真正的大变革还在后面。

这场革命完成的标志有两个:

一是出现专门的“业务服务器”,或者目前的应用服务器演变成“业务服务器”。为什么这么说呢?因为目前的应用服务器是为“生成动态网页”服务的,在架构上处于Web服务器的后面,用来处理web服务器不能处理的所谓“动态内容”,因为是做为web服务器的一个下家,所以要考虑HTTP协议的所有规范,比如各种HTTP请求方法、各种HTTP头标,各种BODY数据格式,HTTP缓存逻辑,编码规范,等等等。而如果未来的后台服务器只需要提供“业务服务”,那么HTTP协议至少80%以上的spec可以不考虑,不实现(比如请求方法,我看只支持POST就够了),这样后台服务器的体系结构可以精简,也会带来更高的运行效率;另外,后台服务器还可以专门针对“业务服务”进行增强,比如session跟踪,用户访问监控,权限管理等等目前需要由应用程序自身来实现的功能,完全可以在“业务服务器”中做通用的实现。这种服务器端架构重新设计的结果就是:目前应用服务器的“Web容器”和“业务(EJB)容器”,很可能整合成“业务服务器”中单一的“业务容器”。这也是为什么7wxAop要把Jetty服务器作为部件嵌入框架的原因之一,我认为只有我们对“服务器”本身的架构有变革的能力,才可以在这场革命中占据有利的位置。


二是粗粒度界面组件(像Treeview,Listview,EidtableGrid等等)成为浏览器的标准支持。如今DHTML/DOM已经很成熟,基于HTML/DHTML/DOM/CSS的应用的用户界面,可以做得比以往任何类型的应用的界面都漂亮,都富于交互功能,以前从来没有一种界面技术能给开发者提供如此细粒度的控制可能。但问题也恰恰出现在这种过于细粒度的界面构造方式,它导致了严重的界面生产效率问题。目前大部分的Ajax框架都在做这样的工作:将这种细粒度技术的基础上构造粗粒度的界面组件,比如国内的dorado,我这个7wxAop中的7wx也是;另一种工作是设计全新的粗粒度界面组件,如adobe的Flex;还有一种工作做得很早,估计已经被大部分人忘记了,就是在IE中直接使用ActiveX界面组件。我认为,不管是哪种粗粒度界面组件实现,最好都由浏览器厂家联合来做,做出标准、通用、有持久生命力的界面组件。微软推出.net的时候,粗看简介我还以为是理想中的界面层技术,细看代码原来还是“服务器动态页面”,后来SUN的JSF也这么学,我们公司一个项目组现在在用的SAP的webDypro也是,因此我都有点怀疑:业界大佬们之所以不愿意在客户端组件上下功夫,之所以不想变革目前的Web应用架构,不是因为他们没看到技术需求,而是因为,他们的根本利益在于利润丰厚的各种服务器端产品;Web开发之所以搞得这么复杂,里面说不定有什么惊天大阴谋;或者说,这些业界大佬们睁一只眼闭一只眼地看着广大Web开发者累得死去活来,看着Web独立开发商和集成商一个个倒下去,却背过身去窃笑着点着大把的钞票----扯远了:),这问题有空发个专贴,反正做了6年IBM独立开发商就给我这种感觉。


建议所有Web开发者都关注这两个方向的进展,搞技术的也要有一定的前瞻性,否则老跟在别人屁股后面跑,实在没有意思。
[该贴被leebai于2007年04月27日 12:22修改过]

反正不是jdon,不是说一定不好。广告宣传跟别人不是一个档次,而且也没有知名后台。

另外,说到客户端,我认为ajax不会火到哪里去,最多ERP用一下,因为大多数ERP都是在局域网里面用

不关浏览器的事,带宽限制

想像一下你只想看一下新闻,却不得不等半天才打开网页,仅仅为了下载一大串为了界面美观或者方便操作的字符,你恼火不?

WEB框架多,我们这些新手就不好选择,往往就是因为资料多而文档齐全就选择了用struts,
个人觉得各有各的好,但随着Java EE5的出台,
应该看到点方向了,SUN决心让JSF来一统江河,
而JSF和SWING相像都是面向组件就大大方便了我们初学者,
可惜现在很多人都不看好JSF,就像当年的EJB2.1,大家都怕雷声大雨点小.
我是菜鸟,所以了解各框架的程度不深,
但我觉得很有必要大家形成一种共识,那才是社区的力量.
中国并不缺乏软件人才,只是不知道在培养些什么人才,
希望大家都关注JSF,特别是出版社(关于JSF的书太少了,强烈抗议)