web开发的下一个革命：基于富客户端+业务服务的“企业应用开发技术”与基于动态网页的“动态网站开发技术”彻底决裂（就像当年c/s结构与终端/主机结构彻底决裂一样），企业应用开发技术将进入第四代，Web应用开发进入第二代。在这场革命中，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开发者都关注这两个方向的进展，搞技术的也要有一定的前瞻性，否则老跟在别人屁股后面跑，实在没有意思。
