作者简介: Shashank Tiwari（又名Shanky），Saven Technologies的首席架构师。有多年从事高性能应用程序设计和开发的经验。近年来，主要关注面向服务架构。他定期地在许多科技期刊上发表文章，并且常以开发者导师和架构师的身份出席研讨会。他同时也是开源软件的热心支持者。现和他的妻子以及两个儿子居住在美国纽约。

摘要: 本文分析了JBoss Seam有望取代Struts成为Java Web应用框架”下一个王者”的原因，并且指出了Spring和Google Web工具包的不足。

时至今日，Apache Struts仍旧是最受欢迎的Java Web应用框架。然而，对于新的应用开发，它显得有些过时，并且存在很多不足。

目前已经出现了几个有望取代Struts的框架，但是还没有最终的胜利者。你认为谁会当之无愧地成为领导者呢？如果你是一个Java Web应用程序的开发者，你会选择哪种框架呢？

目前已经有了很多受欢迎的Web UI技术，包括富界面、AJAX、RIA和其他一些相似的技术。

然而，在服务器端仍然只有Java——Java中有许多基于JSP和Servlets的、流行的服务器端技术。许多时候，这些服务器端技术需要和客户端的富界面技术一起使用。

举例来说，许多开发人员将AJAX与新生代的Java Web框架JSF合并起来一起使用；还有些开发人员通过Java远程调用库、开源或者商业代码来调用JavaScript和ActionScript，用于远程访问服务器端。

这是否意味着，我们需要应用一个像Apache Shale那样，可以很好地和JSF工作的框架呢？这是否意味着，我们只需要根据Web应用中的Java部分，只使用远程访问包和Servlets呢？或 者意味着，我们应该使用一个包含两者的框架，例如，JBoss Seam？

在回答这些问题之前，让我们先关注一下另外一个问题：了解Sun究竟在说什么。

不幸的是，在这点上，Sun没有明确的信息。它有三种战略，并且在同一时间，它说出了全部这三种。它们是：

1. JSF——基于规范的服务器端组件，用于加强早期的Servlets和JSF模型。

2. Swing——用于Web的、以虚拟机为基础的解决方案。在”富界面时代”，应该有这样一个领导者，毕竟它诞生于10年前。但是，不幸的是，它落伍了。Swing应用框架被誉为能使Swing复活的”救世主”。但是，我不认为这能”破冰”。

3. JavaFX——目前主要是在新闻上会提到它，而实际应用还是很少。富Web应用框架包含手机、网站和任何其他接口，这就是答案所在。而只有时间才能告诉 什么会变成它。我的观点是，在做更多事情之前，Sun已经使开发者们兴奋起来。所以，在开发者们感到失望并且离开这个阵营之前，它实际上可能是一个奇妙的 选择。

现在，我们有了这些信息，但是我对Sun的方向却产生了困惑，我们应该选择哪种作为Web应用技术呢？

我的观点是，Swing会败下阵来（或许Swing技术是伟大的，但是要改变这一印象，还有大量的工作需要做)；JavaFX在当前阶段只是一个承诺，在很长时间内，它的真正特性不会变得明朗起来；

因此，唯一可行的选择是JSF。当然，JSF自身有一系列的问题。但是，像Seam这样的框架和包含ICEfaces这样的AJAX组件，将会是一个好的选择。

此外，使用Seam这样的框架，你不需要依赖于JSF，并且你甚至可以使用它来远程访问Java服务器端的纯JavaScript（例如，Dojo 工具包）或者Adobe Flex应用。JSF 2.0和JavaServlets 3.0也即将推出，两者的推出将会对之前的版本有大大的改进。

在我们结束讨论，并且有点倾向于使用Seam作为选择的框架之前，还有两个选择值得考虑——Spring和Google Web工具包。

如果你已经在服务器端使用了Spring，将会发现Spring是一个伟大的选择，项目组里的每个人都知道Spring很棒！

然而，Spring在很多方面，偏离了Java EE标准，但是我建议紧跟标准。

有趣的是，Seam可以和Spring工作在一起，并且Spring beans可以被用作Seam组件。

Google Web工具包是一个充满想象力的工具，它通过把Java代码转换成JavaScript来抚慰Java开发者们。我认为它像”技术摇滚明星”一样吸引了许多开发人员的关注。目前，它也在被大量采用。

然而，它不是一个完整的Web框架。

有趣的是，它也可以和Seam工作在一起。所以，我不认为今天还有什么能够好过Seam？！

JBoss Seam或许不是100%的答案，也或许还没有达到Apache Struts所达到的级别。但是，它已经在领跑了，并且毫无疑问的是，它将继续领跑，除非有新的选择出现。

审校：Richard

原创文章如转载，请注明：转载自JBoss Seam中文站
[ http://www.jbossseam.com/ ]
本文链接地址：http://www.jbossseam.com/2007/11/14/seam-replace-struts/

摘要: 本文从多角度、较全面地总结了Seam的优势。

一、增加AJAX特征的最快捷方式

在功能上，Ajax改变了Web的交互模型。传统Web客户端所使用的同步、粗粒度的请求，引发了很多服务器端应用吃掉少量的缓存，并且没有带来缓存级别的并发操作。

许多情况下，”无状态”的架构只是基本的解决方案，却远远不够！Ajax客户端通过很多异步、并行、细粒度的请求和服务器连接，使开发人员可以轻易地连接和获取远端”数据库”信息。

可是如果状态在交互时被保存到内存，并行相关的bugs将会非常危险，因为Java EE平台并不处理会话级别的并发。

最初设计的时候，Seam被构想成在Ajax基础上，整合并行模型和状态管理模型。

Seam1.1整合了许多基于JSF的开源Ajax解决方案，像ICEfaces和Ajax4JSF，同时加入了Seam的状态和并行管理引擎。开 发人员可以轻松地在程序中应用Ajax，甚至不需要学习JavaScript；并且将远离单独使用Ajax时潜在的bugs和性能问题。

二、开始使用EJB 3.0的最简单方式

EJB 3.0是成熟的事务组件模型，也是最新JPA（Java持久层API）关注的技术，但支持EJB 3.0的Java Web应用框架却很少。这样，你需要去写自己的整合代码。但在大多数情况下，开发人员整合的方式并不能充分利用EJB 3.0的优势。

EJB 3.0是Seam使用的核心技术，你可以无处不在地使用整合的EJB 3.0组件模型。因为在Seam应用中，每个类都是一个EJB组件。你甚至不用写任何整合代码，即可”美化”你的框架。

当然，你也可以选择不使用EJB 3.0，JBoss Seam使你”鱼与熊掌可兼得”。

三、充分挖掘JSF特性的最佳方式

JSF已经有许多组件库和插件以供使用，也当之无愧地成为Java界最有吸引力的Web开发框架。但是JSF过度地依赖于XML配置，并且创建丰富网页界面的特性并不多。

Seam将使用注解的方式代替繁琐的XML配置，减少代码量的同时也提高了开发效率。

Seam在很多方面扩展了JSF的功能：包括多窗口操作、工作空间管理、基于模型的验证、基于jBPM的页面流、国际化和页面分段缓存等等。

Seam甚至还加入了控制标签化页面的机制。

JSF没有涉及访问事务资源，Seam考虑到了这一点，将JTA、JPA和EJB 3.0与JSF无缝地整合起来。

四、实现业务流程管理（BPM）的最简单方式

jBPM是用于解决存在复杂人员协作或者复杂用户交互的Web应用程序的解决方案。

BPM技术不仅方便开发人员和分析人员建模、应用以及优化业务过程，而且可以在整个操作和管理过程中评估业务流程的效率和发掘业务流程中会出现的问题。

Seam深度整合了jBPM，使用jBPM进行任务管理和页面流管理将变得异常简单。

Seam和jBPM的结合将使一些项目的开发时间减少一个月左右。

五、使得CRUD同样简单

Seam也同样处理复杂企业应用中的棘手问题：增删改查。但这并不意味着解决的方式会很难上手。

在创建数据驱动的应用中，Seam将整合现有易用的数据层框架，包括JPA、Hibernate等，使开发人员可以通过一些数据库反向工程工具和命令行工具高效地开发数据库应用。

六、持久层工作将是”小菜一碟”

Seam来源于Hibernate社区，由Hibernate创始者Gavin King设计和开发。

Seam会话模型解决了传统无状态的Web应用架构导致的持久层相关问题。无论你是使用Hibernate还是JPA，Seam使用扩展的持久化上下文都将使开发变成简单，同时也可以使开发人员避免在集成环境下使用持久化上下文时不必要的状态重复。

七、注释功能

Seam是第一个从始至终、从持久层到表示层，都使用Java 5注释功能的程序模型。

你将不会再因为繁琐的XML配置而感到迷失方向。同时在Seam中，开发人员也可以使用XML，Seam提供成熟的基于XML的组件配置机制，使开发人员不会再在XML配置里迷失。

八、为自动化集成测试而喝彩

任何项目都需要自动单元测试，但是仅仅依靠单元测试是十分危险的。许多的bugs出现在组件之间或者组件和容器的交互过程中。单元测试无法捕捉容器的行为，也无法捕捉组件间的交互。

Seam引入了一种新方式：”自动化集成测试”。你可以模拟每个请求或者会话的全部业务流，来测试应用中从持久层到表示层的所有Java代码。

九、开放性标准与开源的结合

Seam建立在实现开放标准的、像JSF和 EJB 3.0这样的开源项目基础上，并且整合了其他优秀的开源项目，如Hibernate、jBPM、Facelets、Drools等等。

Seam的缔造者们都是EJB、JPA、Bean验证和JSF等领域的专家组成员，并且领导过制定Web Beans规范（JSR-299）的专家组–用于将Seam里的一些想法带入Java EE标准中。

Seam项目是完全建立在”致力于Java平台的创新和提高”的开源项目理念上的开源框架。

十、快速上手

只要你试用它，就会爱上它！

审校：骆驼

原创文章如转载，请注明：转载自JBoss Seam中文站
[ http://www.jbossseam.com/ ]
本文链接地址：http://www.jbossseam.com/2007/11/10/ten-good-reasons-to-use-seam/

作者: 路易十三

摘要: 本文介绍了如何在JBoss AS下部署Seam示例程序。

本文使用的JBoss AS版本为4.2.2.GA ，JBoss Seam版本为2.0.0.GA。

请确保您安装了JDK 5.0（或以上版本）以及Ant 1.6（或以上版本）。

让我们开始吧！

一、安装JBoss应用服务器

访问http://labs.jboss.com/jbossas/downloads/，下载JBoss AS 4.2.2.GA。

（图1）

下载完毕，将jboss-4.2.2.GA.zip解压。以解压到D:\Java\jboss-4.2.2.GA为例：

进入D:\Java\jboss-4.2.2.GA\bin目录，运行run.bat，运行结果大致如下：

（图2）

为了验证安装的有效性，请访问http://localhost:8080/。如果安装成功，会出现以下画面：

（图3）

注意：Seam 2.0版本需要JBoss 4.2（或以上版本）的支持。

二、安装并配置JBoss Seam

访问http://labs.jboss.com/jbossseam/download/index.html，下载JBoss Seam 2.0.0.GA。

（图4）

下载完毕，将jboss-seam-2.0.0.GA.zip解压。以解压到D:\Java\jboss-seam-2.0.0.GA为例：

修改D:\Java\jboss-seam-2.0.0.GA下的build.properties文件，添加一行：

jboss.home D:\\Java\\jboss-4.2.2.GA

其中，D:\\Java\\jboss-4.2.2.GA为JBoss AS 4.2.2.GA的安装目录。

三、部署应用

进入D:\Java\jboss-seam-2.0.0.GA\examples\booking，运行：ant deploy。

其中D:\Java\jboss-seam-2.0.0.GA为JBoss Seam 2.0.0.GA的安装目录。

如果部署成功，会出现以下画面：

（图5）

四、大功告成

访问http://localhost:8080/seam-booking，运行结果如下：

（图6）

恭喜您，您成功地在JBoss AS上部署了Seam程序。

审校：Richard

原创文章如转载，请注明：转载自JBoss Seam中文站
[ http://www.jbossseam.com/ ]
本文链接地址：http://www.jbossseam.com/2007/11/07/deploy-seam-application-in-jbossas/

Introduction to the Spring Framework 2.5

Benchmark Analysis: Guice vs Spring

俞敏洪：不要为眼前的得失而抓狂

Web Site Optimization: 13 Simple Steps

10 Warning Signs of Project Failure


Tons of new Flex / AIR articles and videos online

1. 慎重选择。好的结果源自好的选择。
   1. 不急着做决定；
   2. 听大多数人意见和少数人商量；
   3. 将决定写出来，拆细分析；
   4. 选可以兼顾和修正的方案，避免孤注一掷。宁愿慢点，也不错。
2. 沿着一个方向积累。
   1. 你能，不是你比别人聪明，是你比别人用的时间多；
   2. 修正、提高；再修正、再提高。如此往复。温故而知新，不亦乐乎？创新太难，从旧的基础出发，一样可以提高。
3. 不在错误的人、错误的事上浪费时间。
   1. 不招惹不相关的人；
   2. 只对很少的事情感兴趣；
   3. 不可能完成的任务，提早放弃。
4. 装备自己。人能打败狮子，是因为人会用武器。
   1. 多去书店，多买书；
   2. 多读哲学和历史。思想的高度决定实践的高度。 
   3. 买最快的计算机、手机和更多的数码产品；
   4. 多用Google的产品。
5. 多沟通。信任源于沟通。机会源于沟通。
   1. 多打电话。
   2. 多写邮件。
   3. 多用IM。
   4. 多写文档。
6. 坚守底线。有操守才能被信任。信任能降低成本。
7. 尊重偏好。发自心地地喜欢各种文化，各种个性。这样才能团结人，和人合作。

本文由亚洲商港独家冠名赞助。

简单整理出了下面的清单，本土的web2.0服务，未来会联合投票帮、爱唠叨、9Fav、Mywowo以及其他一些Web2.0团队联合举办一次完 全草根的“我最喜爱的WEB2.0服务”的投票活动，下面这个清单是我临时整理出来的，算是一个草稿吧。可以肯定的，还有很多优秀的服务没有出现在下面列 表中。发动长尾的力量，欢迎大家在下面更帖补充某一个分类的内容或者增加分类来完善这个列表吧，也欢迎所有的创业团队毛遂自荐啦，只要是属于中国本土的互 联网服务（未来可能会加入一些本地化比较彻底的服务，例如Pageflakes、Jimdo、Mister Wong、Last.fm等等）都应该出现在下面

社会性书签类：QQ书签，百度收藏，雅虎收藏，就喜欢，抽屉，乐收，易游，统录、黑米、标签公社、

视频分享类：土豆，56，优酷，六间房，琥珀，播播，Mofile，UUMe ，QQ播客，

Digg类：Diglog、草根网、我挖、淘客、

音乐分享网站：八音盒、爱酷播、友播、维众、SongTaste、八乐、Lifepop、Ubox、AoBo音乐盒、乐泡、九天

博客托管服务商：Yo2、72pines、 Lifesterblog、Blogcn、51、新浪、搜狐、网易、百度、Qzone、Bokee、BlogBus、Donews blog、

微型博客系统：饭否、唧歪de、爱唠叨、来咕拉、腾讯滔滔、

RSS周边：抓虾、鲜果、365Bloglink、Anothr、看天下、周伯通、OPML、RSS邮天下、胖葫芦、Aobo、FunP

图片分享：又拍，巴巴变，多拍，捷拍，趣多，拍拍乐，Fotolog，Fotoky，茄子，

地图服务：百度地图、雅虎地图、城市吧、E都市、

在线应用程序：小i，魔击体，Picidea，Sayjoy，

个性化主页：是我的， 咕谷，雅客，火柴，我用，P.cn，

社会性网络：校内、花名册、占座、9公寓、亿聚、联络家、UUzone、若邻网络、网聚，酷兜， 拍客地带，爱情公寓，图葩，宝宝树

评论分享：豆瓣、口碑、饭桶

网络电视：PPlive、QQlive、PPstream 、MySee、

敏捷软件开发又称敏捷开发，是一种从1990年代开 始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏 捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地 适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

[编辑] 词源

敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。

[编辑] 价值观

雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述：

• 人和交互重于过程和工具。
• 可以工作的软件重于求全责备的文档。
• 客户协作重于合同谈判。
• 随时应对变化重于循规蹈矩。

其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。

[编辑] 原则

宣言中还包括以下原则：

• 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
• 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
• 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
• 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
• 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
• 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
• 可以工作的软件是进度的主要度量标准。
• 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
• 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
• 简单——尽可能减少工作量的艺术至关重要。
• 最好的架构、需求和设计都源自自我组织的团队。
• 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

[编辑] 对比其他的方法

敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

[编辑] 对比迭代方法

相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。

[编辑] 对比瀑布式开发

两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。

有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法，另外的人可能将选择各种工作并行进行，例如极限编程。

[编辑] 敏捷方法的适用性

在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏 捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组 织结构的角度看，组织结构的文化、人员、沟通泽决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：

• 组织文化必须支持谈判
• 人员彼此信任
• 人少但是精干
• 开发人员所作决定得到认可
• 环境设施满足成员间快速沟通之需要

最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法适更用于较小的队伍，20、40人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。

另外的问题是项目初期的大量假定或者快速收集需求可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。与之类似，人之天性很容易造成某 个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常能把不恰当的方案授予客户，并且直到最后发现问题前都能获得客户认同。虽然理论上快速交互 的过程可以限制这些错误的发生，但前提是有效的负反馈，否则错误会迅速膨胀。

[编辑] 方法列表

目前列入敏捷方法的有：

• 软件开发节奏，Software Development Rhythms
• 敏捷数据库技术，AD/Agile Database Techniques
• 敏捷建模，AM/Agile Modeling
• 自适应软件开发，ASD/Adaptive Software Development
• 水晶方法，Crystal
• 特性驱动开发，FDD/Feature Driven Development
• 动态系统开发方法，DSDM/Dynamic Systems Development Method
• 精益软件开发，Lean Software Development
• Scrum
• 测试驱动开发，TDD/Test-Driven Development
• XBreed
• 极限编程，en:XP/en:Extreme Programming

[编辑] 外部链接

• 敏捷联盟 (英语，Agile Alliance)