本次JavaOne会议上，第四天，JavaOne组织了这次Web框架的比较，TSS对于会议进行了报道，并将内容发布到TSS网站，网址如下：http://www.theserverside.com/articles/article.tss?l=JavaOne_Day4
翻译本文并非代表本人认可文中的观点，只有感觉这样的比较有助与我们更好的理解框架，选择框架！
Web Framworks 的决斗
译者：John Zhu
在本次JavaOne的周三的对话中，关于Web 框架的对决是非常有趣的对话之一。我们从这次对决的拥护者和格式开始报道，我们提供每个框架的概要描述和不同点，最后，我们发布TSS的自己的积分卡，那个框架在本次决斗中倒下，以及"Best Business Case" 和 "Best Technical Case"的胜利者。
决斗的拥护者:
参与的框架:
JavaServer Faces, championed by Ed Burns
Webwork, championed by Jason Carreira
Shale, championed by David Geary
Tapestry, championed by Howard Lewis Ship
Wicket, championed by Eelco Hillenius
缺席但是非常优秀的其他框架:
Struts 1.x
SpringMVC
Ruby on Rails
决斗的方式:
第一回合: 每个拥护者用三分钟介绍他们的框架.
第二回合: 主持人提问.
第三回合: 观众提问.
战斗的钟: 主持人是Kevin Osborn控制着战斗的钟声.控制现场秩序，以利于决斗不会使用非正当手段或者拥护者是否超过时间时.
我们的评论:
我们注意到在本次决斗中一个主要的趋势是针对组件。每个框架介绍自己的Web组件如何工作的优势。传递给观众的信息是web组件是如此的流行和时兴…拥护者介绍他们的组件的核心在于看上去像什么?我们还注意到，Struts已经明显落后，而所有其他的框架都努力在从Struts的阴影中突破，强调自己如何之不同和如何之更好。尽管Web框架已经前进并将Struts丢在后面，但是Struts仍然是经过实践检验并在成千的成功项目中实施。我们禁不住认为Structs没有包含Web组件的思路，所以开发者需要考虑其他的框架，web组件是一个好的开始。：）
框架概述 (第一回合)
JavaServer Faces (JSF)
技术特性
界面接口组件和事件模型的第一个类
POJO依赖注入（又称控制反转）
客户端独立性
使用或者不使用工具
可扩展的导航（类似于Struts导航，注：Page导航）
强大的扩展能力 （如Shale）
完全的集成（如JSP集成Spring）
本地化和易理解性
市场和商业特性
广泛的采用，包括SUN，Oracle，IBM,BEA,Apache,EDS
作为J2EE 5.0的部分
大型第三方组件市场（iLog, Business Objects, Oracle, Sun, IBM)
业内领先的工具支持（Sun Java Studio, Oracle JDeveloper, IBM WSAD, NitroX plugin for Eclipse, Exadel Studio)
已经有关于JSF的许多的书上架了
在Monster上三页长的关于JSF的工作需求
Webwork
核心价值
简单
可测试
可维护
可扩展
对于未知展示层技术的支持，这次JSP，Velocity,和其他的展示层技术
对于Http请求映射未逻辑（交互性）活动
通过分层的MVC和模板机制简化组件
Shale
集成JSP和Jakarta的框架
成为Struts 2.0的提议
作为Struts的子项目
于Struts类之间没有直接的联系
作为JSF技术的扩展：“JSF 1.0 并没有保护所有的我们需要的东西，所以我们加入目前需求的。所以Shale增加了比如说客户端校验，Ajax，等…作为JSF 2.0的铺路石。期间，Shale 作为证明的基础。”
Shale的特性
Web流
Ajax
Spring和Tiles的集成
客户端和服务端的校验
类似于Tapestry的展示层的参数化的子树
工具：Back-Button的滥用，文件上载，JNDI API
Shale的扩展点
ShalePropertyResolver
ShaleVariableResolver
DialogNavigationHandler
ShaleViewHandler
TilesViewHandler
“如果不知道JSF本身，JSF是非常非常易扩展的”
Tapestry
核心价值:
简化－Web应用不能像火箭科技！
一致性－为页面工作就是为组件工作，为小应用工作就是为大应用工作，不同的开发人员对于相似的问题应该有相似的解决方法
高效性－应用软件应该是高性能和易扩展
反馈－如果有什么地方出现问题了，本框架不会中断，事实上，它会提供一些有用的诊断
工具:
不需要使用工具
可以使用你已经使用的工具.
在Tapestry 4.0中的新特性（子集）:
支持注解
真正优秀的集成能力
管理服务端状态具有更大的弹性，非常高效的获取什么在事务的明细.
支持门户
Extensibility可扩展性:
Over 180 extension points 超过180个扩展点
Built around Component Object Model with many layers 在需要层上集成了组件对象模型
Terrific ability to override, change, and customize过载，更改和客户化的强大能力
Great support for component libraries which are open source and available.支持开源和可用组件库
“对于其他的框架来说，Tapestry是被追赶者！”
Wicket
还是一个新生家伙.
“Wicket是容易的，优雅的，并且是强有力的”
易用:
简化，一致，明显
重用组件
非插入的
安全
效率/可扩展
值得注意的引用:
“谁都知道JSF优于Struts，当然，JSF和Tapestry不相上下”
“Struts是一所老学校，所以恢复它”
“如果你需要一个像这样的工具，那么你的扩家可能太复杂了”
“你可以说，但是不能让人们去用它”
“如果你要节省你的Struts代码，JSF可以做到”
“在事实你可以采用标准的方法去扩展框架，从而达到在某个功能点构建你的扩展，但是事实你不会真在Struts和Webwork上真的这样去做”。有的人说你不需要使用一种想象的事件模型去获得Web应用的重用。
我们的积分卡
TSS尽量用分数来记录决斗，我们对每个框架在两个领域以5分总分作为记录:
技术特性
商业使用
技术特性
框架
分数
原因
JavaServer Faces (JSF)
4.8
JSF赢得大部分分是因为它是第一个真正支持Web组件的。我们的分析师感觉JSF在简单和优雅方面缺乏指控是不当的。JSF是易用的，强大的，并且是革命的。已经存在的Shale和Spring表明JSF的确是可扩展的。
Webwork
4.2
Webwork的多层MVC作为先驱是革命性的，然而我们感觉Webwork的HMVC和模板机制于JSF比已经黯然失色，其思想已经融入了JSF中。
Shale
4.95
如果说Shale站的比其他框架高，那是因为它站在巨人的肩膀上。通过扩展JSF，包含了Web流，支持Ajax，集成tiles,客户端检验，我们的感觉是Shale展示了Web框架的需求和机会的未来。
Tapestry
4.75
Tapestry是Web组件的先锋，在讨论中谈到的“JSF和Tapestry不相上下”本非遥远。然而，JSF的标准扩展点，和第一个支持门户的开发对于Tapestry来说是强有力的竞争优势。我们看比赛已经结束，当然我们乐意看到Tapestry支持JSF的标准接口和支持交互性。…明确的说，我们喜欢能够用Tapestry写JSF组件，用JSF组件的方法去用Tapestry组件。我们热切的期待下一次比赛
Wicket
没打分
Wicket是新兵，在JavaOne的几周前才发布了1.0版本，我们感觉对它了解得还是太少所以不能给之打分，然而，如果Wicket像它声明的那样的简单的化，我们确认是要对之加以关注，我们同样喜欢扩展Wicket相同的交互性于tapestry.
Struts
4.2
Struts并不是正式在本次决斗中，但是Struts负有作为其他框架对比的职责。当Struts发布它的对于Web世界革命性的版本，它包含了数据绑定控制，行为事件的控制(action event handlers)，和用包含Tiles来进行可扩展导航，Struts的校验功能，和通过Dynabeans的扩展性。然而，Struts同样是它的成功的牺牲品，缺乏正式的组件模型，尤其是它向后兼容的能力，妨碍了它继续成为新一轮回合的先锋。这也是为什么它的建立者Craig McClanahan开始成立Shale项目，希望Shale能够有一天成为事实上的标准。
商业使用
框架
打分
原因
JavaServer Faces (JSF)
3.9
JSF现在作为Java标准，已经包含在J2EE 5.0中，得到Sun, IBM, BEA, Oracle和成打的其他公司的认可，JSF展示了太多的承诺。
然而，我们不能忽视现在仅有的几个有限的JSF的应用。如果JSF要赢得IT经理离开Struts的心，JSF需要更多的成功案例。
简单的提一个打名字，比如FedEx，已经使用JSF在它的一些挑选的项目中，如果JSF如此强大，我们可以等待一个成功案例来传播我们是不是在拿商业做赌博。
然而，对比其他在本次决斗中的框架（Struts除外）JSF仍然是赢得3.9分的首选。
Webwork
3.1
当我们在观众提问回合站起来问每个框架巨大的并发性估计和当前使用该框架发布项目的个数的时候，所有的框架，包括JSF都在估左右而言它的逃避这个问题。但是我们喜欢Webwork的回答：“我可以将Google的每台作为我们框架部署者的服务器统计在内吗？”……如果google使用Webwork作为它的商业赌博，它已经赢得了观众的巨大的信任。s
Shale
1.3
虽然Shale具有JSF的顶级技术专家，但仍然未证明的。从商业风险的角度，它太新，未来具有不确定性。
当然，对于Shale声明自己作为Struts 2.0的期望，听上去很打动人，但是仍然只是一个期望，离开正式给庞大的Struts社区接纳还很远，还需要克服很多的困难，应对很对的挑战。
Tapestry
2.8
像Webwork一样，Tapestry已经多次被证明是一个健壮的框架(TheServerside.com 使用Tapestry.) Tapestry 4.0 发布了全新的令人兴奋的特性.然而我们感觉 Tapestry 的建立者 Howard Lewis Ship描述Tapestry 作为其他Web框架“研究项目”是最好的. 并且适用于小组精英开发人员小组使用最新的创新的技术，Tapestry是最好的。
庞大的IT市场接受的是工业界已经广泛采用的东西，有经验的开发人员庞大社区影响最终的选择，基于成百的成功已经的提交项目，我们不认为Tapestry会是合适的选择。我们的挑战是使Tapestry同JSF表现的更加好…只有标准的兼容才能够让Tapestry不不需要考虑IT经理们因为风险而反对。
Wicket
0.7
可能Wicket简单如同它的强大一样，他们只有不超过五个项目使用Wicket，并且所有的项目都属于Wicket的作者。作为一个新兵，Wicket的创新使相当受欢迎的，仍然Wicket仍然有很长的路去证明它自己.
Struts
4.6
伴随着成千的使用Struts的已经部署的项目 ，Struts作为框架已经被或大或小的IT组织所接受。
Struts本身不提出官方的标准，但是它已经使事实上的标准。IT经理不会因为风险而担心接受Struts。
