本文的源自于martin fowler的著作《patterns of enterprise application architecture》中关于web表示模式的一些启发。作者做了多年web开发，并不限于企业级web应用。在娱乐方面的应用（如聊天室，即时消息，web场景聊天等）得到的一些工作经验促使我在企业级应用上进行了深层次的探索和思考，并形成了这篇文章。目前国内外并没有明显在这方面的文章或著作，希望此文能够给做web开发的同仁一点借鉴之处。
本文的最先在2004年11月13日的javaparty聚会上以ppt提出，后经过整理完成。
1 观点提出
标准的遵循http get/post的web开发方式往往遵循这样一个流程：客户端发送一个请求：get或者post给web服务器，web服务器处理完成后将结果以response返回给客户端。在得到服务器的响应之前，客户端一直在等待，页面停滞，用户将看见浏览器长长的的等待条慢慢增长。
而google gmail给了我们完全不同的体验。你无法感受到页面的跳转，系统反应非常快。获取新邮件不需要手动或者自动的刷新浏览器。这一切给人的感觉是那么友好，以至于它一经推出便得到了众多用户的宠爱，并同时成为sina，yahoo等邮件提供商的追赶对象。
这便是我要提出的面向异步消息的web应用(asynchronous-messaging oriented web application, 简称amowa)的一个小例子。一个具备amowa特征的web应用具备以下三条：
1. 系统必须是一个web应用。事实上，在非web环境中设计与实现异步调用非常简单，考虑也很自然。但在web环境下，设计与实现相对比较麻烦，思维方式也稍微会有些跳跃感。
2. 系统中必须具备消息特征，无论是隐式或者显式。在网络游戏，即时消息工具等应用中，消息特征比较明显，这方面的论述也比较多；但有些企业应用，也能够发现一些隐含的消息模式。比如，一个商业智能web客户端，需要进行钻取、上溯、切片等操作，这些操作和返回值可以被包装为消息（事实上，目前已经有相关的规范，分别是mdx和xml/a）；在操作型web应用中，操作同样可以被抽象为消息，比如一个bug管理系统，提交bug, 查看bug等，都可以包装为消息。
3. 消息必须是异步的。这一点是与传统方式的根本不同之处。传统的方式在完成某个操作一定存在页面切换，而amowa不必。消息是异步传输，在操作完成之前客户可以看到一个友好的loading或者其他友好的提示，等到操作完成数据可用之后，前台的ui采用javascript/flash的方式进行刷新。
2 amowa的出生历程
amowa的提出来自于网页出现的这十多年。
最初始阶段传统的聊天室。前台网页往往需要经过几秒钟自动刷新一次来获取其他在线用户的发言。后来出现了无刷新聊天室，或多或少采用了隐藏帧来处理消息的定时收发。在这期间出现了pushlet, 一种意图将http消息"推"到客户端而不是客户端主动"拉"的方式。这种方式在客户端看来，就像是一个有一个永远也下载不完的页面；服务器端往往不允许buffer, 并通过response.write然后直接response.flush的方式向客户端写数据。
之后的一段时间web应用一直停留在标准的request/response的方式很久，直到xmlhttp的出现，面向异步消息的应用才多了起来，同时由于思维方式的扩展，很多采用同样思维的应用也出现了，这些应用跨越了很多行业，包括商用和娱乐行业，直到现在，面向异步消息的web应用已经能够成功胜任大多数的web应用，并以改善用户体验为最终目标，越来越受到重视。
3 应用场景
商用领域，包括但不限于
l 邮件应用程序。这一点，在gmail上已经得到验证。邮件应用是最典型的异步、消息的应用，在web环境下，异步消息模式完全有理由应用在邮件系统客户端中。如果有一种方式能够让你不刷新就能够获取新邮件，让你不需切换页面就能够阅读/编写邮件，你还会想回到老路上吗？
2 即时消息应用。典型的无外乎msn web messenger. 即时消息并不要求实时性。在即时消息系统中，延迟2~3秒用户是完全符合用户期待。而这宝贵的2~3秒给了即时消息的web应用提供了生存空间，并给了即时消息服务提供商新的卖点。
3 商业智能客户端。商业智能产品越来越趋向于web--或许这是整个世界应用的发展趋势；web上对数据立方的钻取、旋转、切片如果需要切换页面，没有多少人会很愉快的接受这样的系统。这样需要频繁操作的系统，amowa是当仁不二的选择。
4 web地图系统。www.go2map.com 上的地图，大家可以看到异步操作模式下的地图是多么自然；相反，icq提供的地图服务让人难以接受：每次点击或者圈选地图之后，就要等待一段时间的白屏。
5 其它操作性强的系统。比如，财务信息管理系统，前面提到的bug管理系统，具备明显或者能够抽象成命令特征的系统。注意，国内政府或者大型国企需要的oa等项目不太适合应用amowa，原因是大多数情况下，消息格式的定义比起需求的控制、界面的变更以及项目完成后的使用率，显得微不足道且毫无意义。
娱乐与游戏领域，包括但不限于：
l 聊天室。没有什么比一边聊天一边听着浏览器自动刷新时发出的"叭哒"声更讨厌了。更加细心的定义amowa的消息结构，你会发现聊天室的访问者更多了。
2 web在线游戏。不要以为不可能，请访问www.51js.com, 那里有令很多传统web开发者意想不到的东西。目前已经实现的有：livechatv2, 一个纯javascript+html的场景聊天室；中国象棋，纯javascript+html的网络版中国象棋。目前台湾有一款真正的web网络即时战略游戏，正在线运营，月卡好几十台币。
当然，由于异步消息的限制，web在线游戏不可能做到实时，因此目前web网游被限制在消息实时性要求不高的领域，如棋牌，社区，简单的网络游戏。3 其它。
4 优点
4.1 从用户来看：
1. 更好的用户体验。
很多高级用户不愿意听到浏览器刷新发出的声音。这个用户群体在扩大。在现代的企业级web应用中，经常有及时消息传递的要求；让他们听到刷新的声音是不合适的。amowa的引入将彻底无刷新，用户感觉更好。
2. 更好的用户体验
对用户而言，单页面的操作更为友好。大部分用户对于切换页面时那段漫长的时光感到度日如年，并且感到不自然。在商业智能/报表这样的操作中，单页面操作显得格外重要。
3. 更好的用户体验
等待的页面更为友好。在操作得到数据返回之前，用户将看到的不是白屏和长长的浏览器状态条，取而代之更为友好的提示和状态条。对于高级用户，这样的改变将令他们惊喜。
4….呃，更好的用户体验
由于系统中传递的是纯粹的数据，对用户而言，系统显得比普通的应用更快了，感觉当然更好。
4.2 技术观点
1. 在某些场景下，客户端可以是纯粹的html, 而不是讨厌的jsp tag, 或者tapestry难以理解的jwcid（实际上一点也不难理解^_^）, 或者struts那恐怖的tag, 或者毫无ide工具支持的jsf。业务逻辑、服务器端特定语言特征与客户端彻底分开。美工可以真正安心的做页面。
2. 服务器端可以进行一些有趣的设计，例如任务队列。由于客户端发送来的是消息，服务器端可以将发送来的消息按照队列来进行处理，而不用马上响应。
3. 容易实现分布式部署。由于客户端与服务器端的完全分离，服务器端的分布、状态迁移、cache共享将不成为问题。
5 基于amowa的设计
基于amowa的设计将分为两个部分：面向企业级典型web应用和面向娱乐游戏的典型web应用。
5.1 面向企业级典型web应用
基本原则：一个典型的企业级web应用一定是一个分层结构、设计良好的应用。分层设计意味着数据层，业务逻辑层与表示层能够清晰的分开。
amowa专著于web表示层，它连接了系统的业务逻辑与前端web页面。amowa gateway负责解析前台发送来的消息包，将消息包解析为相应的业务操作，调用业务逻辑操作，将操作结果进行序列化，封包为消息，发送给客户端。
客户端有一个客户端引擎，能够接收、解析消息包，并根据消息内容，对ui进行刷新。这里的刷新可能对应一个javascript脚本，也可能对应一个flash的action script脚本。
amowa定位在与struts, webwork, tapestry等web框架的同一个层次上，并能够取代他们。
下图表示了这种架构：
这种web应用在amowa看来，具备最大的特征是：各个会话之间的交互较少。在下面的面向娱乐游戏的amowa设计中，会话之间的交互显得格外重要。
5.2 面向娱乐游戏的amowa设计
面向娱乐的amowa与面向企业web应用的根本不同在于，前者会话交互需求较高，比如在一个网络游戏中，经常需要知道另一个在线玩家的当前状态，因此，在这种设计中存在一个中央context来保存这些信息，来保证在线操作者之间的交互。基本设计图如下：
context连接了基本的底层设施--比如，保存玩家经验值，扣点等。
