面向异步消息的Web应用(AMOWA)

本文的源自于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连接了基本的底层设施--比如，保存玩家经验值，扣点等。

6 实现
以下是一个AMOWA接口的伪代码
* 客户端将操作包装成消息并发送：
    clientOperation.sendMessageBundle(msgBundle, callback);
    callback定义了消息的处理策略。
* AMOWA Gateway负责获取前台发送的消息，并处理
    messageBundle = buildMessage(request); //将Request包装成MessageBundle
    returnedMSGBundle = process(messageBundle); // 处理消息包
    sendReturnedBundle(returnedMSGBundle );  //发送处理结果
* 在process方法内部，简单的调用业务逻辑层的处理方式：
    bizDTO = bizService.doSomething();
    return bizDTO;
AMOWA Engine将会将bizDTO序列化为系统能够辨认的消息格式，生成消息包。

以上的实现相对简略，实际上，设计这样的一个AMOWA Framework技术上不是太难的。如果想偷懒，XML-RPC的实现可以直接拿来使用。XML-RPC在几乎所有语言上都有实现。

7 相关技术
客户端技术：
DHTML, JavaScript
我在文中偏向于这两点，是因为我对这两种技术相对较熟悉，实际上Flash更适合用来做前台表现。当然，前台用何种技术并不影响AMOWA的架构方式。AMOWA定义了客户机于服务器之间的一种通信方式，而并非客户端实现方式。

服务器端技术：
任意一种服务器端技术都是可以的。然而，具备面向对象特征的服务器端技术在实现上能够更自由、合理一些。那些老式的服务器端技术如ASP，想要实现一个AMOWA Framework显得较为困难，这一点在设计WEB网络游戏时显得格外突出。

XML-Binding的技术一定是需要的，无论是客户端或者是服务器端。这是由于我们的消息格时往往用XML的方式来定义。在服务器端返回对象时，能够直接序列化为XML将会给消息的包装带来便利之处；客户端若能够将HTML或者Flash某个控件直接与XML一个节点或者属性进行绑定，那么前台的工作量将会更少。鉴于服务器端的XML绑定已经有很多不同的实现，如JAXB, Castor, JiBX等，笔者最近在试图无浏览器差别的将XML对象绑定到HTML元素上。

选择一种消息传输协议是必要的。目前有两种选择：Web-Service和XML-RPC。在现有系统的消息特征明确并且不太可能会将每个方法暴露给外界的前提下，Web-Service是最不推荐的选择。Web-Service冗余的信息太多，传输或解析都会带来时间和带宽损耗。如果没有时间定义消息格式，那么XML-RPC将是一种比较好的选择。他对数据类型进行了较好的包装，对于WEB应用足够，并且有足够多的语言实现支持，客户端和服务器端都有。

如果时间足够，最好能够自行定义消息结构，和编码、解码方法。这并不是很复杂的事情。这样编码的消息能够以最小的带宽损耗进行传输。这一点，在带宽有限制的应用中显得格外重要，例如银行的业务系统。

8 相关问答
问：AMOWA与RIA有什么关系？
答：没有关系。AMOWA定义了WEB应用一种新型的交互方式--采用消息方式。RIA可以是AMOWA客户端的一种实现，AMOWA的客户端实现可以是Flash, XUL, 或者HTML.

问：AMOWA与XMLHTTP的关系？
答：XMLHTTP是AMOWA实现无刷新、异步消息的一种手段。目前只有这样一种手段来获得异步连接。其他方式如动态加载远程javascript, 动态加载远程网页，多少是同步的方式，会导致客户端浏览器的瞬间不可用。

问：AMOWA有没有实现？
答：暂时没有。我正在编写一个，主要面向在线游戏。但是由于工作繁忙，进展缓慢。基本思想如同上面的描述，有兴趣的同仁可以自行实现，造福人类。

问：发送和接收为什么是MessageBundle，而不是单个Message?
答：这是为了保证执行效率。在LiveChatV2中，用户每次的鼠标点击将会发送一个消息，如果用户鼠标点击速度相当快--比如每秒几十次，这么密集的访问可能会造成服务器没必要的繁忙。因此，客户端采取没隔一段时间记录一次，将这段时间的鼠标动作捆绑成一个消息包，发送给服务器。

其他问题，欢迎交流：mechiland [###] gmail.com

9 总结
AMOWA引入一种新的WEB开发模式，可以换掉标准的MVC开发方式了！
AMOWA的引入，从根本上讲，完全是为了给用户更好的体验，从而使产品更具人性化，更有竞争力。
更快。

摘录自:http://webuc.net/mechiland/archive/2004/11/15/2195.aspx