DWR的工作原理和优缺点

  一直以来，我都认为DWR是逆ajax的框架，其实这样理解，是很不全面的，逆ajax只是它的一部分而已。

  针对DWR的理解，简单的说就是”简化数据的获取“，用专业的语言来说，那就是通过客户端的engine.js作为客户端的引擎和服务端的dwr.jar作为服务端的引擎，以RPC的方式来获取数据。

  举个栗子，比如用户的注册

服务端，有一个入口，com.zy.action.regist.java类，类里有个registUser方法

客户端，dwr.xml文件里，配置 com.zy.action.regist为regist(javascript中使用的对象)

在容器启动的时候，会去加载web.xml中的配置，其中就包括 （表示加载服务端的引擎）

启动完成后，用户进入regist.jsp页面，填好用户信息，点击按钮进行注册。即：在regist.jsp页面的script代码中，regist.registUser(username，password)。regist对象就是在

dwr.xml中定义的java类转换后的javascript对象(此处用到了反射)，而且，调用regist.registUser(username，password)，DWR会封装一个ajax请求，叫做regist.registUser.dwr

向后台发出请求。也就是说，实际上，DWR还是用的ajax，只不过是封装了一层。

优点：
1.浏览器兼容：
2.json的封装
3.多种对象的转换（ssh对象转换）
4.可以写更少的JS代码，做更多的事情
 
缺点：
1.出错不容易找
2.dwr配置很复杂

ps：

在 DWR 逆ajax 实现网页聊天 中，有两个问题我不是很明白

1.比如A和B发消息，DWR是怎么知道A找的是B，而不是C

2.A在messageSend.jsp发送消息，B只有在messageAccept.jsp中才接收到消息，B在index.jsp界面是接收不到消息的，这是为什么呢？

思考了很长时间，边看DWR的源码边猜测，勉强给出了一个满意的答案

针对第一个问题：

  1.A登录，java中创建scriptSession写入用户信息
  2.在消息界面，进行DWR的初始化，和把步骤1的scriptSession加入ScriptSessionListener监听
  3.A发送消息，java中接收请求，把消息以DWR的规定格式，追加到scriptSession上(ScriptBuffer.append("methodName",parems))
  4.步骤2的Listener监听到消息的追加，字节流的方式输出javaScript片段到客户端的jsp里面

针对第二个问题：

在上面问题中，步骤2，消息界面，这里称呼它为messageAccept.jsp，在messageAccept.jsp有DWR的客户端引擎(dwr/engine.js)，

所以，步骤4，只会在有引擎的jsp界面输出服务端生成的js(打开两个message.jsp，是会同时接收到相同消息，亲测)，或者DWR会在

引入DWR引擎的jsp集合中，根据步骤3中的methodName进行过滤，找到精确的页面，进行js的输出