DWR 中的反向全推Ajax技术的实现原理和应用实例.docx
- 文档编号:11602932
- 上传时间:2023-03-20
- 格式:DOCX
- 页数:21
- 大小:531.62KB
DWR 中的反向全推Ajax技术的实现原理和应用实例.docx
《DWR 中的反向全推Ajax技术的实现原理和应用实例.docx》由会员分享,可在线阅读,更多相关《DWR 中的反向全推Ajax技术的实现原理和应用实例.docx(21页珍藏版)》请在冰豆网上搜索。
DWR中的反向全推Ajax技术的实现原理和应用实例
1.1DWR中的反向“全推”Ajax技术的实现原理和应用实例
1.1.1反向Ajax技术的实现原理
1、什么是反向Ajax技术
反向Ajax技术的基本概念是指客户端程序不必从服务器端程序中获取信息,服务器端的应用程序会把对应的信息直接推送到客户端相关的程序中。
2、为什么要应用反向Ajax技术
这样做的目的是解决Ajax传统Web模型下的实时信息获取的问题,常规的实现方式是客户端程序如浏览器必须要不断地请求服务器程序,并主动询问服务器程序是否存在有变更的数据信息,如果有变更的数据信息,则立即更新当前的页面(或者页面中的一部分)。
反向Ajax技术的应用场景非常广泛,比如监控(后台硬件热插拔、LED、温度、电压发生变化)、即时通信(其它用户登录、发送信息)、即时报价系统(后台数据库内容发生变化)都需要将后台发生变化的数据实时地传送到客户端程序而无须客户端程序如浏览器不停地刷新,从而提高客户端程序的应用效率。
3、反向Ajax技术能够更好地解决数据实时更新的应用问题
应用反向Ajax技术,能够实现由服务器主动地联系所有的客户端程序如浏览器,并通告这些客户端程序如浏览器,服务器端的数据信息已经发生了变更。
4、常规的Web应用系统无法实现反向Ajax技术
(1)常规的AJAX技术所存在的局限性
AJAX技术提高了单用户操作的响应性,但Web本质上是一个多用户的系统。
现有的AJAX技术的发展并不能解决在一个多用户的Web应用中,将更新的信息实时地传送给各个客户端程序,从而导致客户端程序或者用户可能在“过时”的信息下进行操作。
(2)为什么常规的Web应用中无法实现反向Ajax技术
因为HTTP的特点是需要客户端浏览器产生请求后,服务器端响应的程序才会产生响应输出。
如果客户端浏览器等程序不再对服务器端程序产生新的请求,服务器端响应的程序也就不响应客户端程序的请求。
因此,在正常的情况下,服务器端的程序是不可能操纵客户端浏览器。
而反向Ajax是克服这个限制的一种方式。
5、反向Ajax技术的实现方式
主要存在“主动式”的反向Ajax(如下面所描述的轮询和服务器推技术等)和“被动式”的反向Ajax的实现技术(如下面所描述的回传)两种不同类型的实现方式。
具体的实现形式如下:
1)而以其中的轮询(polling)方式实现最简单,但是会造成服务器的负载;
2)而服务器推(Comet)方式下的数据能够及时地响应,但是会造成服务器系统资源的浪费;
3)回传(PiggyBack)方式可以说是最好的技术实现方式,但是数据响应存在不定时性,这要取决于客户端程序的下次请求间隔。
6、轮询方式的实现原理和注意事项
(1)轮询(polling)实现方式
在Web页面中使用刷新标签,客户端浏览器定时轮询服务器端程序,看是否存在更新的数据,并且立即显示从服务器端程序传回的当前信息。
由于是每隔数秒就更新当前的页面,因此该形式也被称为轮询技术——其实完全不需要使用Ajax相关的实现技术。
(2)在AJAX技术应用中可以利用setTimeout()定时触发请求
当然,在Ajax的实现技术中,可以利用setTimeout()定时器函数定时触发向服务器端请求的事件,同样也能够达到刷新标签的轮询技术实现效果,而且不会产生刷新标签所造成的“闪屏”现象。
如下为setTimeout函数的语法:
vartimeoutID=window.setTimeout(func,delay,[param1,param2,...]);
vartimeoutID=window.setTimeout(code,delay);
(3)轮询方式的主要缺点
当系统中存在有大量的客户端请求时将会产生大量的传输浪费,因为每个客户端系统都必须要有规律地请求服务器以获得更新后的数据,这是服务器资源的一个重担。
而最坏的情况是服务器端的程序很少更新的应用场合,例如基于Ajax技术实现的邮件收件箱。
在这种应用场景下,大量的客户端程序的轮询是多余的,服务器端的程序也仅仅是简单地响应“没有数据”。
7、服务器推方式的实现原理和注意事项
(1)服务器推(Comet)方式其实是一种基于HTTP长连接的服务器推方式
客户端向服务器发送请求后,服务器端程序将数据通过response发送给客户端,但并不会将此response关闭,而是一直通过response将最新的数据发送给客户端的浏览器程序,直到客户端浏览器程序关闭为止。
在如下示例图所示的应用中为每隔1分钟又重新发送请求。
当超时连接到期失效时,这个JavaScript库就会重新打开对服务器的连接并一直保持打开,直到超时。
因此在Comet方式下,客户端程序不会产生前面的轮询方式下特有的传输浪费。
因为,一旦有客户端程序触发请求的事件发生,更新后的数据就会及时地被发布到客户端系统中。
(2)使用AJAX实现“服务器推”与传统的AJAX实现“服务器拉”在应用方面的不同之处
1)服务器端会阻塞客户端的请求直到有数据信息传递或超时才返回。
2)客户端JavaScript响应处理函数会在处理完服务器返回的信息后,再次发出请求,重新建立连接。
3)当客户端处理接收的数据、重新建立连接时,服务器端可能有新的数据到达;这些信息会被服务器端保存直到客户端重新建立连接,客户端会一次把当前服务器端所有的信息取回。
长时间保持连接活跃是服务器过载和用完请求处理进程的原因。
(3)维持长连接也将会消耗服务器端系统的资源
由于J2EEServlet程序独占一个线程,传统的Servlet引擎就限制了Comet方式在应用中的可伸缩性,因为在客户端的数量迅速可能会超过服务器栈所可能有效处理的线程数量。
8、回传方式的实现原理和注意事项
(1)回传(PiggyBack)的实现原理
在PiggyBack方法下,服务器端程序将最新的数据排成队列,然后等待客户端下一次请求,接收到请求后就将等待更新的数据发给客户端。
(2)在DWR系统的默认实现方式是PiggyBack,该方式不会导致服务器端系统超载
因为在数据无变化时不需要应答客户端的定时查询。
9、使用Comet模型时的基本要求
由于基于AJAX技术实现的各种应用中的请求一般都是频繁触发的,而Comet方式其实是Http长连接形式,会长时间占用一个连接,因此会导致系统的效率降低。
在应用Comet方式时需要遵守一定的规则。
(1)不要在同一客户端同时使用超过两个的HTTP长连接
在使用IE浏览器下载文件时会有这样的体验,从同一个Web服务器下载文件,最多只能有两个文件同时被下载。
第三个文件的下载请求会被阻塞,直到前面下载的文件下载完毕。
这是因为在HTTP1.1规范中规定,客户端不应该与服务器端建立超过两个的HTTP连接,新的连接会被阻塞。
而IE浏览器在实现中严格遵守了这种HTTP1.1的规定。
HTTP1.1对两个长连接的限制,会对使用了长连接的Web应用带来如下现象:
在客户端如果打开超过两个的IE窗口去访问同一个使用了长连接的Web服务器,第三个IE窗口的HTTP请求被前两个窗口的长连接阻塞。
(2)服务器端的性能和系统的可扩展性要求比较高
一般Web服务器会为每个连接创建一个线程,如果在大型的商业应用中使用Comet方式,服务器端程序需要维护大量并发的长连接。
在这种应用背景下,服务器端系统需要考虑负载均衡和集群技术或是在服务器端为长连接作一些改进的措施。
(3)控制信息与数据信息使用不同的HTTP连接
在设计上,需要使客户端的控制请求和数据请求(用于往服务器端发送长连接请求)使用不同的HTTP连接,才能使控制请求不会被阻塞(用于往服务器端发送控制请求,控制请求能很快收到响应,不会被堵塞)
(4)在客户端系统和服务器端系统之间需要保持“心跳”信息
在浏览器与服务器之间维持一个长连接会为通信带来一些不确定性:
因为数据传输是随机的,客户端不知道何时服务器才有数据传送。
服务器端程序也还需要确保当客户端系统不再工作时,释放为这个客户端分配的系统资源,以防止内存泄漏。
因此需要一种机制使双方知道彼此都在正常运行。
在实现上:
1)服务器端在阻塞读时会设置一个时限,超时后阻塞读调用会返回,同时发给客户端没有新数据到达的心跳信息。
此时如果客户端已经关闭,服务器往通道写数据会出现异常,服务器端程序就会及时释放为这个客户端分配的资源。
2)如果客户端使用的是基于AJAX的长轮询方式;服务器端返回数据、关闭连接后,经过某个时限没有收到客户端的再次请求,会认为客户端不能正常工作,会释放为这个客户端分配、维护的资源。
3)当服务器处理信息出现异常情况,需要发送错误信息通知客户端,同时释放资源、关闭连接。
1.1.2DWR框架中的反向“全推”Ajax技术的实现实例
1、在DWR框架中可以配置使用3个不同的机制实现反转Ajax技术
(1)DWR从2.0版以后就提供对反转Ajax技术的支持
该机制将服务端系统事件“推”给客户端。
而客户端的DWR程序代码将透明地处理连接的建立和应答解析数据,因此可以从服务端Java代码简单地发布信息到客户端。
(2)DWR可以配置使用3个不同的机制来反转Ajax技术
1)其一是轮询方式
由浏览器定时向服务端发送Ajax请求,询问后台是否有什么内容需要推送,有的话就会由服务端返回推送内容。
这种方式和直接在页面通过定时器发送Ajax请求,然后查询后台是否有变化内容的实现是类似的。
只不过用了DWR之后这部分工作由DWR框架帮助开发人员完成了。
2)第二种方式称为Comet风格的长连接
当服务端程序建立和客户端浏览器的连接后,将页面内容发送到浏览器之后,对应的连接并不关闭,只是暂时挂起。
如果后面有什么新的内容需要推送到客户端的时候直接通过前面挂起的连接再次传送数据。
但由于服务器端系统所能提供的连接数目是有限的,在大量的挂起的连接没有关闭的情况下,可能将会造成新的连接请求不能接入,从而影响到新的请求处理。
3)最后一种机制使用piggyback
在DWR中默认的实现方式是piggyback,piggyback方式下不创建任何到服务器的长连接,而是等待直到另一个DWR服务调用发生并。
这可以获得高效率但是意味着客户端事件通知被延迟直到客户端程序再次发出一个新的请求。
因此,如果后台有什么内容需要推送到前台,是要等到那个页面进行下一次Ajax请求的时候,将需要推送的内容附加在该次请求之后,传回到页面。
只有等到下次请求页面主动发起了,中间的变化内容才传递回页面。
2、在web.xml部署描述文件中配置DWR的Servlet程序
(1)应用Comet风格的长连接的配置项目示例
--设置使用反向Ajax技术-->
--通知DWR在应用程序启动时初始化创建远程Java对象-->
--毫秒数,页面默认的请求间隔时间值为60秒-->
其中的maxWaitAfterWrite参数,也可以改变为下面的配置项目:
(2)应用轮询技术的配置项目示例
(3)应用piggyback技术实现方式的配置项目示例
1.1.3设计服务器端的Java程序类
1、主要的核心API说明
通过WebContext类获得DWR应用的Web上下文,再用ServletContext获得DWR的DWRServlet程序的上下文,以及通过Web上下文获取访问本应用的客户端浏览器的ScriptSession。
一旦获得当前页面的名称,就可以获取当前连接到这个页面的所有会话列表。
然后,启用监听客户端当前页线程,把数据添加到客户端调用的方法中。
其中的WebContext是DWR中取得servletAPI的类,它从WebContextFactory中获取。
2、DWR的服务器端系统程序跟踪访问者的访问状态
在服务器端如果出现新的数据后,需要更新附加到服务器端的每个客户端的会话。
DWR会记录与之联系的每个客户端,分别存储每个客户端的会话信息。
3、代码示例
本示例程序代码是推送到所有的浏览器中,程序类名称为SendMessageToAllClients,程序包名称为com.px1987.webcrm.onlineim。
(1)程序类创建的截图
(2)SendMessageToAllClients程序类的代码示例
packagecom.px1987.webcrm.onlineim;
importjava.util.Date;
importjava.util.LinkedList;
importjava.util.List;
importorg.directwebremoting.Browser;
importorg.directwebremoting.ScriptSessions;
importorg.directwebremoting.WebContext;
importorg.directwebremoting.WebContextFactory;
publicclassSendMessageToAllClients{
publicSendMessageToAllClients(){
}
publicvoidboardcastMessageToAllClients(StringoneClientMessageInfo){
WebContextoneWebContext=WebContextFactory.get();
StringrequestClientIP=oneWebContext.getHttpServletRequest().getRemoteAddr();
System.out.println(newDate().toLocaleString()+",有IP地址为:
"+
requestClientIP+"的客户发来请求,消息为:
"+oneClientMessageInfo);
allMessageInfos.add(oneClientMessageInfo);
Browser.withCurrentPage(newRunnable(){//启用监听客户端当前页线程
publicvoidrun(){//把数据添加到客户端调用的方法中
ScriptSessions.addFunctionCall("receiveMessagesFromServer",
allMessageInfos);
}
});
}
privateList
}
4、对示例代码的说明
在DWR中服务器端的Java方法可以取得浏览器端的Web上下文,并可以调用javascript的方法,将服务器端的数据异步地传输给浏览器。
ScriptSessions类中的静态函数addFunctionCall调用所有在线的客户端页面中的一个名称为receiveMessagesFromServer的JavaScript函数。
后面是参数一定要求是对象型的,最终实现数据推的效果——第一个参数是页面中的JavaScript函数,而第二个参数是服务器程序传递给该函数的参数。
由于boardcastMessageToAllClients方法是实现广播的方法,而不是向某个特定的请求返回处理的结果,因此该方法的返回值可以为void。
5、远程化该Java类的dwr.xml配置文件示例
xmlversion="1.0"encoding="UTF-8"?
>
DOCTYPEdwrPUBLIC"-//GetAheadLimited//DTDDirectWebRemoting3.0//EN""http:
//getahead.org/dwr/dwr30.dtd">
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- DWR 中的反向全推Ajax技术的实现原理和应用实例 中的 反向 Ajax 技术 实现 原理 应用 实例