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的引入，从根本上讲，完全是为了给用户更好的体验，从而使产品更具人性化，更有竞争力。
更快。
