用 continuation 开发复杂的 Web 应用程序(2)

look_wt

常规 Web 开发中的问题模型 - 视图 - 控制器（Model-View-Controller，MVC）是广泛采用的交互式应用程序（包括 Web 程序）的开发模式。这个众所周知的模型把交互式应用程序组织成三个单独的模块：一个针对应用程序模型，代表数据和业务逻辑；第二个针对视图，提供数据表示和用户输入；第三个针对控制器，负责分派请求和控制流。
模型 1 架构 vs. 模型 2 架构严格地说，只有 MVC 的模型 2 架构有控制器 servlet。模型 1 架构的控制是分散的，在这种架构中浏览器直接与 servlet 或 JSP 技术交互，后二者则访问并使用表示应用程序模型的 JavaBean 组件。在这种架构中，要显示的下一页面由用户在当前页单击的链接或者随请求一起发送的参数决定。今天多数基于 MVC 的 Web 应用程序都实现了模型 2 架构。

那么控制器管理的这个 "流（flow）" 是什么呢？从页面加载、等候填写的表单返回角度来讲，典型的 Web 应用程序由定义良好的与用户进行交互的序列组成。在这种情况下，Web 应用程序就像是一个事件驱动的状态机（state machine）。这个事件模型就是典型的 MVC 架构通过控制器实现的模型。
例如，假设用户向服务器请求某个页面，页面中包含要填充的表单。用户花了些时间思考，填充答案，然后提交表单。当这个事件到达服务器（控制器模块）时，根据当前状态、用户提交的数据和业务逻辑，把应用程序移动到下一个逻辑状态。这种状态转换的结果，正如用户所看到的那样，是按顺序排列的或早期页面（和错误信息）的下一页的显示。
当状态机在从开始状态到结束状态的途中推进时，就重复这个循环，在某一点上，Web 应用程序被认为是实现了特定用例要求的功能。状态图控制着从 "开始" 状态到 "结束" 状态的各种可能的数据流，它既可以由控制器模块（通常是 servlet）显式实现的，也可以像在某些 Web 开发框架中那样，被外部化为配置文件中的元数据。
不论框架是如何实现的，与状态机的基本思想总是一致。在开发基于这个模型的 Web 应用程序时，就会出现大量问题，如下所述：

• 根据状态机的尺寸和维护客户当前状态所需要的数据量（因为一个 Web 应用程序在同一时间可能会有大量客户同时访问），应用程序逻辑可能会变得没有必要的杂乱或复杂。
• 在状态转换的序列中，客户单击浏览器的 Back 按钮的时间是不一定的，而且客户还可能克隆浏览器窗口，从而初始化并行的动作序列。任何一种情况都会导致已经传递的状态在原来的交互中发生多重（有时甚至是并发）提交。结果，应用程序必须跟踪每一个事务，并对每个事务提供正确的响应。
• 当 Web 应用程序要从跨多个页面的一系列表单中搜集用户信息时，也会出现类似的问题。如果后一个表单的生成取决于用户在前一个表单中提供的响应的组合，那么应用程序就必须跟踪在每个交互中输入的响应，并确保每一个交互都返回正确的页面。

一般来说，模型 2 Web 开发框架提供了定制技术，可以调节上述的一个或多个问题。但是，没有一个技术像基于 continuation 的方案那样直观、容易开发，基于 continuation 的方案提供了解决所有这些问题的一揽子方案。