剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Bryan Clauser译者 王丽娟 发布于 2008年1月17日 下午9时48分
对Web应用开发人员来说,状态管理一直是一个挑战。对话应该在应用层而不是请求层来处理交互。Jacob Orshalick以Seam的酒店预订示例应用为例,论述了Seam的对话模型,并解释了如何将嵌套对话运用于该示例。
Seam的对话模型提供了一个简化方法来处理continuations。如果你熟悉continuation server的概念,你就知道它们提供了包括无缝后退按钮处理和自动状态管理在内的功能。一个用户会话有很多continuations,它们是执行过程中简单的状态快照,可在任何时候恢复。如果你对这个概念不熟悉,别担心,Seam使其变得很简单。
这只是模型的一部分,Seam还允许对话的嵌套:
嵌套对话提供了一个状态容器,它堆叠在最早的对话或外部对话的状态容器之上。任何在嵌套对话状态容器中设置的对象,都不影响可从父对话状态容器中访问的对象。这就允许每个嵌套对话能保持其自己独有的状态。
Orshalick从定义嵌套对话到确保它被妥善地清空一路演示下来。他用JBoss Developer Studio来扩展Seam的酒店预订示例应用,生动地完成了嵌套对话的讲解。
Jacob Orshalick不止澄清了嵌套对话,他还讨论了对话超时的话题:
对话超时似乎是一个普遍被误解的Seam概念。在Seam论坛上,我常常看见一些帖子宣称对话超时不起作用。实际上它工作得很正常,只不过你必须去理解它的语义。
Orshalick用与嵌套对话相同的例子说明了,在处理多对话时,只有后台对话会受到对话超时的影响。照这样来说,只有会话本身超时时,前台对话才会超时。
Orshalick最后总结到:
通过其简单的对话模型,Seam提供了一个非常有吸引力的方法来管理状态。过去开发人员艰难处理的复杂问题,包括多窗口操作和后退按钮处理,都能处理得天衣无缝了。查看英文原文:Understanding Seam Nested Conversations and Timeouts
本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目,怎样配置一个JSF应用去使用JBoss Portlet Bridge,以及JBoss Portlet Bridge所具备的功能。
在这篇文章里,Bryon Jacob和Chris Berry将和我们继续探讨AtomServer,它是基于Apache Abdera的完整Atom存储实现。作者还创建了几个Atompub规范扩展,其中包括自动标记、批处理和Feeds聚合。
InfoQ中文站的电子杂志《架构师》试刊第二期出版了!相比于上期,我们在内容的选择安排和版式上都根据读者的意见重新做了修正。“细节决定成败”,我们希望基于InfoQ中文站的专业内容,《架构师》能逐渐成为大家喜欢的电子刊物!
在本文中,Steven Haines探讨了Web应用性能调优问题。该领域过去更像是一门艺术而不是一门科学。他提出了一种称为基于等待调优的方法,使整个调优过程更加可度量,也因此更具科学性。
通常来说,改变技术路线时最艰难的部分是辨别语言语法之间的不同。这篇文章就为Java开发者提供了一份如何转向Flex基础语言ActionScript的指南。
本视频主要以财帮子为例,介绍了如何创建一个PV为百万级的Rails应用。其中包括:Rails应用的服务器架构、Rails Cache的优化、负载均衡的处理、Web服务器的调试、分布式解决方案、Open API的设计等等。
InfoQ首席架构师Alexandru Popescu在采访中谈论了InfoQ架构、Webwork与DWR、Hibernate与JCR、Hibernate可扩展性、最新的InfoQ视频流系统和InfoQ的未来规划。
1 条回复
回复