轻量级开发的成功秘诀，第 9 部分: 基于 Continuation 的框架

核心提示： 仅此一项较高的抽象就能为 Web 编程带来这样巨大的飞跃，这真是难以置信，轻量级开发的成功秘诀，第 9 部分: 基于 Continuation 的框架(5)，但事实的确如此，如果 Java 语言能为 continuation 提供内置支持，我们都会用上某种形式的 continuation 服务器

仅此一项较高的抽象就能为 Web 编程带来这样巨大的飞跃，这真是难以置信，但事实的确如此。如果 Java 语言能为 continuation 提供内置支持，那我们最好全部采用这种方式编写代码。实际上，某些 Java 框架（如 Apache Cocoon、RIFE 和 Spring Web Flow）都在尝试使用这一模型，其取得的成就各有不同，有些框架采用了像状态机这样的技术（在 RIFE 和 Spring Web Flow 中），有些框架采用了其他语言（如 Apache Cocoon 中的 JavaScript 引擎）和字节码增强（在 RIFE 中）。这些技术的确改进了典型的 Java 解决方案，但仍不能与其他语言中最佳的服务器带来的用户体验相提并论。

continuation 的缺点

当然，天下没有免费的午餐。就使用 continuation 而言，也有三四种常见的反对意见：

会话状态 在某些方面，自动化会话管理使得在会话中存储更多数据变得更加容易。只需声明一个实例变量，将其提交给会话即可。为了可以更容易地存储会话数据，开发人员可能要存储更多的状态数据，从而限制了可伸缩性。当然，还要额外付出高级语言的代价。可伸缩性 保存调用堆栈的代价高昂。而且保存许多调用堆栈是禁止的。有趣的是，如果仅仅存储在各用户之间有所不同的堆栈部分，即可将所存储的堆栈数据数量限制在合理范围。这种方法称为部分 continuation。难以理解的 URL 如果为各用户请求存储了一个难以理解的标识符，那么 URL 不可能美观易读。可以首先显示 URL 中美观可读的部分，后附难以理解的标识符，通过这样的方式缓解这一问题。这正是 Amazon.com 采纳的办法，看上去十分有效。但相对而言，局限性是比较严重的。

或许天下没有完全免费的午餐，但 continuation 服务器可为您带来近乎完美的东西，帮助您节省大量资金。我相信在 5 年之内（或许还会更快），我们都会用上某种形式的 continuation 服务器。也许会出现一种流行的 Java 派生技术，也许会是因 continuation 服务器而展露头角的其他一些语言。