使用DWR反转AJAX的失败经验和教训

 

                 使用DWR反转AJAX的失败经验和教训

 

 

过去一周，我试图使用DWR的反转AJAX功能，开发一个基于Web的页面即时通讯系统，但是失败了。

出现的技术障碍是，除了当前得到的ScriptSession外，想尽办法得到的其他ScriptSession，都像是被阉割过的，根本不能够从服务器端向客户端发送消息和JavaScript代码。

可能是因为，DWR的反转AJAX功能是使用定时轮询实现的，如果客户端浏览器不发起轮询，服务器端再怎么做都是没用的！

这样，点对点通过Html页面通讯，就无法实现了。只能够实现DWR提供的例子那样的Web聊天室的应用。

下面，总结一下发现的浏览器和DWR反转AJAX功能的Bug和一些经验。

 

一、IE是能力最差的浏览器，Firefox不错

其他浏览器，还没有试过。

1，反转AJAX的功能，在Firefox上能够得到正确的应用，但是，在IE上，就无法实现即时的页面接收。

2，IE是最不符合规范的浏览器。DOM的实现也不够规范，使用标准的DOM方法，在Firefox中正确显示，但在IE7中却毫无作用。当然，这并不是大问题，还是有一些办法可以克服IE的缺点的。

 

二、DWR的反转AJAX功能

1，除了当前得到的ScriptSession外，想尽办法得到的其他ScriptSession，都像是被阉割过的，根本不能够从服务器端向客户端发送消息和JavaScript代码。

2，DWR框架的 DwrUtil 类

DwrUtil类是一个服务器端的代理类，允许Java程序员调用客户端的Java代码。

这个类实际上只是一个助手类，它实际上是使用ScriptSession的Script字段，向客户端发送特定的JavaScript代码而已。这个类的存在，仅仅是方便了用户使用一些常见的功能而已。

3，DwrUtil类和ScriptSession类，缺少区分向哪一个浏览器的哪一个页面发送JavaScript代码的能力。

这造成了严重的问题。

1）缺少区分浏览器的能力，就不能够实现浏览器用户的点对点之间的通讯。

2）即使我得到了ScriptSession,它们也失去了向客户端传输JS代码的能力。

3）不能区分页面，这样，就会发生服务器传输的信息发祥错误的页面的情况。如果2个页面没有相同的页面元素，会报缺少页面元素的错误。如果2个页面的元素一样，那么就会发生显示错误的信息的情况。

 

总之，现在DWR的反转AJAX功能还有很大的不足！

 

三、DWR

DWR提供了使用JS远程调用Java类的功能。这是一种RPC远程调用的机制。类似于RMI等远程方法调用。每一个发布的Java类都会自动生成一个对应的JavaScript类。

这个javaScript类，是远程Java类的本地存根，是一个代理类。它们简单的通过XMLHttpRequest对象，调用服务器端的Java类的对应方法，然后把结果返回。

DWR对于广大的Java程序员来说是一大福音。不必学习和编写复杂的JavaSript代码和AJAX代码，只需要编写Java类和方法，就能够完成大部分的AJAX应用。

另一方面，DWR这样的远程RPC调用，存在安全问题，这和其他远程调用机制是一样的，必须要有安全机制的保证，才能够真正运用。DWR已经提供了安全机制。不过我还没有细看 J

DWR的远程调用机制，需要采用与其他远程调用机制一样的编程模式。那就是，应当远程发布粗粒度的Java类和方法，而不应该公布细粒度的对象，否则将会造成严重的性能问题。

如，应该公布业务模块的服务层的类，或者是表现层的业务委派层的业务委派类这样粗粒度，面向具体应用的类。

绝不能够公布数据访问层的类。那些类是细粒度的。而且，使用数据访问类的方法，能够实现对数据库的CRUD操作，将会造成严重的安全漏洞。

要记住，DWR的客户端是浏览器。任何人都能够在自己的机器上编写JS代码，然后远程访问我们发布的Java类。不进行安全控制，是绝对危险的！

 

我对DWR框架，也只是略知一二，看来有必要对DWR框架进行深入和系统的学习和研究。研究和发展DWR的反转AJAX功能。必要的时候，自己创造这样一种反转AJAX的功能。如，使用定时器，定时使用AJAX异步查询服务器的方式，我想，DWR可能也是这样实现反转AJAX功能的。