将运行在产品环境中的应用更新到新版本并非易事。更新应该将对已连接用户的影响降到最低，同时如果更新不成功，那么应该可以轻松地回退到之前的版 本。运行在多个服务器（比如说集群）上的应用使得更新过程变得更加复杂。通常来说，该特性是由应用服务器厂商以一种私有解决方案的形式提供的。在 Apache Tomcat的最新版中，甚至连它都为这种零时间的停机更新提供了最低的支持。
ZeroTurnaround提供了LiveRebel 2.0，这是其针对Java EE应用在线更新解决方案的下一主版本。虽然JRebel用于项目的开发阶段，但LiveRebel的目标则是产品部署。LiveRebel的一个主要特性是它可用于多个应用服务器。这是通过一个特殊的Java agent（类似于JRebel的方式）实现的。目前支持如下环境：
- Tomcat 5、6、7
- Jetty 5、6、7、8
- JBoss 4、5、6
- Oracle Weblogic 9、10
- Oracle application server 9、10
- GlassFish open source 3.x
- WebShere 6、7
- 独立的Java应用
一个或多个服务器上分别安装了各自的agent后，管理员就可以统一查看所有受管理的服务器，并且可以即时更新运行着的应用。有几种更新策略，如hotpaching（类似于JRebel）或轮询的服务器重启等。LiveRebel能够确保所有更新都是事务性的（要么全部成功、要么全部失败）并且所有更新都是可逆的。
要想使用LiveRebel，Java应用还需要一个特殊的liverebel.xml文件，这是一个内容无法再精简的文件，它持有打包应用的版本号。如果应用是通过Maven构建的，那么就能很轻松地在构建阶段集成其生成的内容。
InfoQ有幸采访到了ZeroTurnaround的市场经理Oliver White以进一步了解LiveRebel：
InfoQ：可否将相同的应用部署到不同的服务器上（比如说一个是GlassFish，另一个是Tomcat），然后让LiveRebel对其进行更新？抑或所有服务器都要是一样的？
不必，服务器不需要是一样的。
InfoQ：LiveRebel 2.0还为“独立”更新提供了一个选项。这到底是如何做到的呢？这是针对那些没有运行在应用服务器上的应用的么？那么agent安装到哪里呢？
没错，这是针对那些通过常规的“main”方法运行的应用的。agent依旧安装到了JVM上，安装过程与使用应用服务器的情形是类似的（你需要通过 LiveRebel包装器来运行应用）。然而，该模式有一些严重的限制（由于LiveRebel并不知晓处理HTTP的socket，因此它无法代理 HTTP请求），这意味着在更新过程中是没有轮询重启和socket暂停的。在该模式下，唯一有用的更新方式就是Hotpatching了。
InfoQ：LiveRebel是否依赖于JRebel？这意味着新版本的JRebel总是会导致新版本的LiveRebel出现？
LiveRebel使用了JRebel技术来实现Hotpatch更新（作为一种更新策略），但在内部，我们是将其分开的，偶尔通过推/拉的方式实现两者间的变更。这种同步并不依赖于JRebel的发布计划。
InfoQ：能否向我们的读者介绍一下价格呢？
很遗憾，我们目前还不能披露价格，但不久之后我们的网站就会公布，现在我们只能说只要你有产品部署，那么你就能负担得起其价格。
ZeroTurnaround现已发布了2.0.7版，带有改进的用户界面。要想了解更多信息，请查看文档、FAQ以及入门指南。