不论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开发的下一个革命：基于富客户端+业务服务的“企业应用开发技术”与基于动态网页的“动态网站开发技术”彻底决裂（就像当年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开发者都关注这两个方向的进展，搞技术的也要有一定的前瞻性，否则老跟在别人屁股后面跑，实在没有意思。
?
摘录自jdon web层下一个王者
http://www.xjawa.org/xjawa/kontent/80039.html
?