Web框架选型思考
经过漫长的商务折磨，终于确定了自己平台规划负责人的角色，任务非常明确：采用开源技术进行组装，开发一个具备业务含义、能够进行快速开发的软件平台。
现有项目的运行情况让我认识到了一点：在持久层与业务逻辑的相对成熟的情况下，WEB层的工作最为繁重，哪怕是引入了Tiles改善布局也如此。Struts天生的缺陷，让整个项目中WEB层显得笨拙不堪，成为整个系统中bad smell最重的的区域。从软件技术大会回来的同事说，很多同行都认为B/S系统中WEB端的工作量是整个系统的瓶颈。这一点看来已经得到了业界的普遍认可。
而现有的这个平台一定是持续使用的。如果不在WEB开发上进行改善，那么这个平台显得毫无意义：在依托面向对象技术的Java平台下，大部分其它的东西都有现成并且健壮的，对我而言都是熟悉的；而在WEB层，一定要有一个具备重用、珍惜每一个可重用WEB组件的框架在支撑。由于我们这个行业的特殊性，再带宽上也应当有所考虑。
基于这些特征，我首先想到的就是面向组件的WEB框架。这里的组件一定是网页上可见的组件，能够天生穿透Java/Javascript/Html，而不是笨拙的在JSP中import javascript；或者采用不堪的JSP tag. 这么看来，具备这一特征的、成熟的框架只有Tapestry了。
然而我对tapestry还有所保留，原因有两点：一个是对大型系统的支持不足。我们要面临的系统达到十几个子系统，3000多种交易。而Tapestry模块的支持区分不足，这一点上，WebWork来的要自然的多，Struts也提供了支持（我实在是难以出口这个词，虽然Struts将我引入了MVC的门，但是我对其丑陋的设计，臃肿的配置文件充满了憎恶）。
第二是Tapestry难以理解的URL，总让人觉得诡异（刚开始觉得挺有意思），不便于书签。好在有成功的项目证明进行修改是可行的，这个工作量也应该不大。
如果我的AMOWA概念有实现，那么我一定会选择Amowa的实现。因为Amowa中异步的概念刚好满足了系统带宽的要求。Web框架的选择过程让我了解到，组件式的web框架在知识积累上有多么重要。试问一下，我们以前做的WEB应用中，web端有多少能够自如的重用？
纵然Tapestry不尽人意，我还是决定选择Tapestry来作为平台的WEB框架（有人会说Tapestry不便于测试，试问又有多少合理的项目会将业务逻辑写在XXXPage中？），对其进行一些改造是必需的，比起持续使用与知识积累带来的好处，这么点工作量算不了什么。
July 8th, 2005 at 5:28 pm
你好，我刚学Tapestry，能不能指导我一下，我的MSN是gonghonggong@hotmail.com
January 23rd, 2006 at 2:04 pm
各位网友，您们好！
***这是JWC(Java Web Component)开源组织的公开信。
首先作自我介绍：组织名称——JWC(Java Web Component)
*************技术名称——DMVC(Double Model View Contraller)
*************创建组织的目的：推动IT技术的进步，为社会作做贡献。
***酬薪问题：因为本项目的公益性质，所以所有成员都没有薪水；但不
等于没有回报，成果实行公产主义分配策略。
***诚邀各位仁人志士加盟JWC(Java Web Component)开源组织。
组织机构：
（1）顾问团：由关注、指导、帮助这个项目的朋友组成。
（2）组长：一名，负责该项目开发的全面工作。
（3）副组长：两2，协助组长工作。
（4）框架设计师：10名，负责DMVC框架设计
（5）命名规范组：5名=1名组长+四名组员，负责命名规范规范的制定和
稽核。
（6）技术推广组：10名=1名组长+两名副组长+7名组员，负责将DMVC
技术推广到个Web应用开发商。
（7）资料组：3名=1名组长+两名组员，负责资料的收集维护
（8）程序设计组10个：作为DMVC框架的实现者，队伍必然是强大的。
由于系统各模块的工作量和劳动强度不同，每个程序设计组由1名
组长和若干名组员构成。并且程序设计组的个数会动态增加。
（9）人事组：5名=1名组长+四名组员，负责发现团结组织需要的人才。
纪律组：5名=1名组长+四名组员，无有规矩不成方圆。负责组织纪律和
制度的制定、监督、执行。
（10）测试组：10名=1名组长+两名副组长+7名组员，负责测试方法的
研究和测试。
报名方式：请将您的姓名、参考职务、电话、QQ号、Email、简介、代表
性作品发到JWC组织的电子邮箱：org_jwc@126.com ，备用邮箱：
org_jwc@56.com
*********************************技术概要摘录
***DMVC框架建立在J2EE架构的基础之上，是一个不错的企业级J2EE解决方案，DMVC充分吸收Strust 、extra 、Tapestry 、EOS 的MVC思想，利用Ajax 技术发展起来的。在传统的Web框架下，浏览器与服务器数据交互频繁，客户端一个小小的动作，页面不得不刷新，既影响了客户端的操作效果，同时也增大了网络流量、服务器负载。虽然可以使用隐含刷新技巧欺骗用户的眼睛，但数据在浏览器与服务器之间一个来回的路费还是少不了的。举一个购物车的实例吧：在传统模式下，用户每添加一个产品到购物车中，则必须向服务器发一个Http请求，更新Session Bean ,然后从服务器应答一个HttpServletResponse 来同步Session Bean 与浏览器视图的状态，这样才能在购物车中看到新添加的产品。在服务器应答浏览器(Response) 的过程中，那些构成界面元素的HTML标记被一次又一次的重复传输,增大了网络流量。并且要求给每一个购物车分配一个Session Bean ，在购物高峰期，EJB容器里一定创建了不少的Session Bean实例吧，是不是很耗资源，这就增大了服务器负载；而被分配出去的Session Bean 是否都很忙，得时时维护自己的状态。最糟糕的是下面两种情况，情况一、用户购了半天物，最后决定不要了，服务器白忙了一阵子，资源浪费呀！情况二、用户的购物车刚刚分配得到一个Session Bean 就有事离开了，而服务器必须等待Session Bean超时才能回收其资源，很郁闷吧！不用那么难过，DMVC 能为你解决以上烦恼。
*** DMVC 对界面和数据采用完全分离的解决方案，分别实现MVC模型。为了比较，还是举刚才购物车的例子吧。当用户添加一个产品到购物车中时，因为界面和数据完全分离，购物车的界面元素没有更改，所以浏览器不需要向服务器发送Http请求，服务器更不用重新生成界面应答浏览器，好处有以下几点：1、减轻服务器的负载。2、减轻网络流量。3、页面不用刷新。4、提高响应速度。那数据又是怎样运着的呢？首先，客户把数据添加到ESB（Enterprise Script Bean）容器中以XML数据岛的形式存形成ESB,ESB是DMVC中的数据模型（Data Model），当Data Model改变时，自动发送消息通知Data View 更新保持与DataModel同步。这样用户就在购物车中看到了刚才添加的产品。当必要的时候才进行Bean Bean（EJB and ESB）状态同步,什么时机才是必要的时候呢？当然是客户去收银台后将要把购物车中的数据持久化到数据库中时。这个Bean Bean同步的过程是这样的，首先由用户在Data view 上触发一个Bean Bean同步事件以消息的形式发送给Data Controller，Data Controller分析事件并作出决定，向服务器发出XmlHttp请求，要求同步Bean Bean 状态。这样EJB容器里只需要只需要少量的悠闲的EJB，他们可以在EJB Container 里玩、聊天、谈恋爱、睡觉都可以，当Bean Bean 同步的那一瞬间才给购物车分配一个Session Bean ,EJB持久化完毕后立刻回到EJB Container 容器待命，高效吧！
***DMVC为提高程序运行效率和编程效率，让程序做必要的事，程序员不做重复的事。这是DMVC的一大特色。举个树（tree）的实例吧：在传统模式下，要在浏览器中显示一棵树，得把树的子子孙孙都从数据库中查询出来发到浏览器，而特定用户在一时间内不可能点击所有节点，程序做了些无用工，只是白白浪费服务器的CPU 、内存、网络带宽。 DMVC是这样提高效率的：因为HTML标记中无树标签，在DMVC中树（tree）是由节点数据在JavaScript控制下利用层标记生成的。而树的显示期间树的界面元素不会改变，改变的只是节点的逐步增多。数据的流程是这样的，用户在地址栏敲入网址形成Http请求，请求中包含有树，服务器查询树的根和子节点连同树的JavaScript 相对地址一起发到浏览器中。用户看到了树的根及子节点。 随着用户点击树节点对树的张开。在tree 的 data view 上不断形成树的张开事件，Data Controller 分析张开事件，若发现该节点的子节点不在ESB Container中则向服务器中发出XmlHttp请求，服务器查询子节点的结果形成XML格式的数据以HttpServletResponse应答浏览器，更新Data Model，当Data Model 更新后立即以消息的形式通知Data View 与其同步。用户看到了子节点。当用户再次点击相同的节点并形成张开事件发出消息时，Data Controller 分析张开事件发现该节点的子节点在ESB Container 中则不处理该事件，直接张开树节点。节点的增加、删除、更新，我就一笔概括了，由于用户对节点的增删改必然造成Bean Bean 状态不同步，我们把这个差值叫Δ(增量)，EJB状态小于ESB状态时，Δvalue的取值为负，反之Δvalue的取值为正。当要对ESB状态持久化时，只需要Bean Bean状态同步，持久化EJB即可。
***把业务逻辑与界面显示层分离是设计模式的一大进步，而把数据与界面元素完全分离可谓百尺杆头 更进一步。 数据与界面元素完全分离表现在：1、数据格式不同，界面数据格式为超文本标记格式，而数据岛采用XML格式。2、传输协议不同，界面用HTTP协议，数据岛采用XmlHttp协议。3、界面元素与数据岛的更新不相互影响。
***用最少的代码实现复杂的功能是DMVC的又一特点。DMVC在最大程度上满足了当今应用大规定制时代的随需应变要求，符合应用平台化，功能构件化的要求。
—————————————————————— 2006-01-18
—————————————————————— jwc
April 2nd, 2010 at 8:42 pm
期待能加入，不求回报，只求共同努力，共同进步！