预测：企业应用系统开发的下一个革命，Web应用2.0 (非Web2.0)

背景贴：

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

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开发者都关注这两个方向的进展，搞技术的也要有一定的前瞻性，否则老跟在别人屁股后面跑，实在没有意思。

xform 就是这个类型的组件  还有xul svg等等. 组合这些元素我认为应该是cilent+server模式 但不是目前.net 和 jsf那种方式.

cilent->xmlhttp server->webservice(rest) 中间是xml处理框架执行xml pipeline 比如cocoon ops   

第一点不太理解，第二点非常赞同！
另外，前瞻性是很好的，但是对于还需混饭吃的兄弟，也不能望得太远，失去了对脚下的注意。

理解第一点是比较难，因为目前还没有人做这件事，甚至没有完整的理论模型。

或者是第一点封装的太大,提供强大功能的同事,不能细粒度的使用,作为一个公司的产品还可以,作为通用的可编程工具不行.

第二点的就不同了,通用的,可编程性,灵活性很大,当然就不同了.

其实第一条有两个主题：
一是给现在的应用服务器瘦身，compact化；二才是增强功能，二可以设计成可选的，如现在的EJB容器一样。

您所说的第一点，是否是将应用服务器的职责细分，比如说负责比较单一的某一方面，然后在某个职责方面功能增强，比如说负责权限等？

要不这样理解吧：

compact化呢，就是把目前的web容器砍掉，不要了；

增强呢，就把目前的EJB容器改造成直接接受HTTP（只要一个小的协议子集）请求的东西。