专利名称：企业客户端-服务器系统以及用于通过网页套接字通信的分布仿效提供网页应用支持的方法
专利说明图6是详细示出根据本发明的优选实施例的网页浏览器客户端应用的基于iframe的优选实施方式的框图。图7是示出根据本发明的优选实施例的、网页浏览器客户端应用在建立仿效的网页套接字的网络连接中的初始化和执行的序列图。图8A和图SB是示出根据本发明的优选实施例构造的网页浏览器客户端应用的优选封装的实施方式的框图。图9是示出根据本发明的优选实施例的、网页浏览器客户端封装的应用在建立仿效的网页套接字网络连接中的执行的序列图。图10是如在本发明的优选实施例中实施的网关服务器的优选实施方式的框图。图11是示出结合本发明的优选实施例使用的优选服务重定向(redirection)技术的流图。 图12提供了示出根据本发明的优选实施例的、在网页浏览器客户端与网关服务器之间建立仿效的网页套接字连接的优选过程的序列图。图13提供了示出根据本发明的优选实施例的、在网页浏览器客户端和网关服务器之间的仿效网页套接字连接的建立和维持中的代理服务器参与的处理的序列图。
具体实施例方式本发明满足对实时、全双工通信能力的需求，该能力基本与可以用于访问网页服务的客户端网页浏览器的当前固有能力无关。在本发明的以下详细描述中，同样的附图标记用于表示一个或多个附图中描绘的同样部分。草拟HTML5规范(包括支持规范)定义了建议用于实施网页浏览器和基于HTTP的类似客户端应用的网页套接字和服务器发送的事件(SSE)的固有架构和操作特征。网页套接字和服务器发送的事件基于客户端应用能够使用全双工的直接TCP通信信道的假设。在关于本发明的应用10中，如图I中一般性地示出的，传统客户端系统12、14执行网页浏览器应用，以通过公共因特网、私有内部网或其它通信网络16访问一个或多个远程服务器系统18、20、22，以双向地请求和接收实时信息。在典型实例中，最初将通过由客户端系统12执行的网页浏览器客户端发出的信息请求指引到初级或源服务器18，并且建立实时双向信息馈送连接，如其它次级服务器20、22所需要的。例如，可以从源服务器18请求网页页面，其在所传送的页面的用户界面表示内的适当的指定的窗口区域内呈现来自新闻源服务器20的实时新闻故事、以及来自股票信息服务器22的股票价格信息。传统地，同与源服务器18协调的服务器20、22的实时双向的次级连接的透明建立取决于由客户端系统12、14执行的网页浏览器客户端中对网页套接字和服务器发送的事件的固有支持。缺少广泛的固有网页套接字和服务器发送的事件的支持，并进一步以跨所有主要的独立网页浏览器客户端实施方式兼容的方式，建立基于网页套接字的系统(商业的或其它的)是不实际的。根据本发明，提供网关服务来使得传统的与HTML5之前兼容的网页浏览器客户端的实施能够立即支持全面兼容的网页套接字和服务器发送的事件，甚至在特定的网页浏览器实施方式没有或仅具有HTML5标准的一些部分固有实施的情况下也是如此。此网关服务可以在现有的服务器18、20、22上实施，或者作为优选实施例，在独立的专用网关服务器系统上实施。在合适时，可以利用相符的固有特征实施，通常本质上是部分的。另外，本发明实施这样的仿效系统，其获得与HTML5规范相符的固有实施一致的功能上相符的系统。参照图2，网页套接字和服务器发送的事件的各个方面的有效仿效传统上被建立的安全和功能限制所排除，这些安全和功能限制内建在现有的传统标准相符的网页浏览器中，特别是不与草拟HTML5规范完全相符的那些。网页套接字的服务器发送的事件仿效的关键要求是透明地实施跨来源通信的能力。这样的通信传统上被现有标准指定的同一来源安全策略要求所排除。即，文档(尤其是包括从源来源服务器34传送到客户端系统32的网页页面)被限制为仅引用和请求同一来源范围内的某些资源。作为一般的定义，来源由传输协议、域和端口号定义。来源访问限制排除了跨站点脚本攻击，并更一般地阻止了来自不同来源的文档之间的无意交互。不幸的是，传统来源安全特征也阻止了具有不同源来源范围的页面之间的无害通信。传统上，例如从源来源服务器34提供的文档被阻止访问从不同来源中的任何目标服务器36、38提供的文档或服务，或与其交换数据。根据本发明，一般地如图3所示，根据本发明的优选实施例所构造的跨文档消息传输系统40选择性地允许客户端系统32所加载的文档安全地跨不同的来源互操作。为了当前说明的目的，将目标来源请求限定为从源来源服务器34接收的源来源文档所导致的资源请求，该资源请求针对由源来源服务器34的来源的范围之外的来源限定的服务器提供的文档或服务。如果指定的域、端口和传输协议中的任一个在源和目标来源之间不同，则来源范围不同且这些来源之间的请求是跨来源请求。根据本发明，来自于客户端系统32的目标来源请求被具体指引到网关服务器42，网关服务器42接着实施合适的服务，以实现与目标服务器36、38的通信。网关服务器42可以且通常在源来源服务器34的来源以及客户端系统32的来源的范围之外的来源中。如图4中更详细地表示的50，在客户端系统32上执行的网页浏览器客户端应用52向用户选择的源来源网页服务器34发出请求。评估后，源来源网页服务器34返回请求对应的网页页面文档54。优选地，网页页面文档54被预编码，以包括要检索的初始配置资源的标识。当网页浏览器客户端应用52遇到对象引用时，将初始配置资源请求发送给源来源网页服务器34，其返回对应的客户端库56。根据对象引用的资源的本质，可以返回一个或多个文件作为客户端库56的一部分。优选地，还利用初始目标引用预编码网页页面文档54，该初始目标引用用于识别所指定的代表源来源网页服务器34操作的网关服务器42。图5中将客户端库56的优选实施例一般地显示为分层的库栈70。共同地，客户端库56当在传统的与HTML5之前相符的网页浏览器应用52中执行时提供功能上与HTML5相符的网页套接字仿效。较低层的更基本的层位于分层库栈70的底部，较高层的功能逐渐地提供在较高层中。除图5中所示的层之外的附加层出现在传统的与HTML5之前相符的网页浏览器中。如果网页浏览器应用层插件(包括Adobe Flash、Microsoft Silverlight以及OracleJava)存在于网页浏览器执行环境中，则也可以使用它们。客户端库56的基层是传统的XmlHttpRequest(XHR)层72，其名义存在，而不需要在与HTML5前相符的网页浏览器中仿效。XmlHttpRequest层72提供应用编程接口(API)，其使得HTTP和HTTPS请求能被直接发送给 指定的目标网页服务器系统。直接接收服务器响应，作为接着可通过API而被启动该请求的网页应用使用的数据。名义上,XmlHttpRequest的执行和完成被限制到单个来源。即，请求源和目标网页服务器系统必须存在于共同来源的范围内。提供postMessage层74,以通过提供可访问在客户端浏览器52的背景内执行的网页应用的附加API调用来支持仿效的跨来源消息传递。如在本发明的优选实施例中所实施的，postMessage层74管理传统网页浏览器的严格安全策略的实施，但安全地允许由单个基础网页页面文档定义的多个帧通信，即使对从不同的来源加载嵌入在这些窗口内的文档的情况也是如此。如果目标显式地期望和接受来自所指定的源来源的消息，则通过postMessage层74许可基础文档与嵌入在页面内的文档之间的通信。在源显式地侦听和接受来自所指定的目标来源的消息的情况下，支持双向通信。某些当前的传统网页浏览器支持postMessageAPI的初始固有实施。postMessage层74优选检测任何现有postMessageAPI的存在和符合。在不存在固有postMessage API的情况下，或者固有postMessage API不符合的情况下，使得postMessage层74能够通过仿效处理所有postMessage API调用。在优选实施例中，postMessage层74利用取决于所嵌入的窗口技术(典型的是 JavaScript、Flash 和 Silverlight)的实施方式仿效 postMessage API。对于每个， 在所嵌入的窗口来源的范围内检索嵌入的文档或等效物。此嵌入的文档功能上提供与postMessage API兼容的桥通信处理。在JavaScript的情况下,与当前优选实施例一致地，使用客户端iframe作为至由网关服务器42处理的对应来源的桥，以结构化的方式实施仿效，从而功能地建立源至目标的通信路径。通过iframe传递postMessage消息,作为按照URL身份标识(id)段传送的短数据段，典型的是iframe URL的“#”以后的部分。更大的消息被分离为多个数据段用于传送。在Java、Flash和Silverlight的情况下,与窗口对应的嵌入文档组合地操作的所安装的runtime (运行时)提供用于使用如根据本发明所构造的技术对应的桥机制建立通信的基础。跨来源请求层76提供W3C跨来源资源共享(CORS)规范的仿效，通过与HTML5相符的跨来源资源共享API可访问该规范。在网页浏览器客户端不支持固有跨来源资源共享或者固有实施方式不相符的情况下，实现跨来源请求层76。如在本发明的优选实施例中所实施的，在网页浏览器客户端52中，通过postMessage层74和XmlHttpRequest层72的有效使用，仿效跨来源资源共享。通过postMessage和XmlHttpRequest层74、72处理跨来源资源请求，并通过网关服务器42将跨来源资源请求连接到由对应的目标服务器36、38服务的指定目标来源。在本发明的优选实施例中，网关服务器42实施与HTML5相符的跨来源资源共享组件，其能够建立至目标服务器36、38的符合规范的连接。服务器发送的事件层78允许网页客户端连接到与HTML5相符的服务器发送的事件的流。服务器发送的事件层78本地地管理从远程目标服务器发送给网页浏览器52的数据的流。服务器发送的数据流传统上被实施为从下游发送给网页浏览器客户端52的网络消息的单向异步序列。虽然某些传统网页浏览器具有SSE协议的早期固有实施，但本发明的优选实施例通过扩展代理(agent)特定的固有实施，提供了服务器发送的事件层78的完整实施。即，服务器发送的事件层78检测当前代理，并补充完成对SSE协议的支持所必须的功能性。当甚至部分固有支持也不可得或不可用时，服务器发送的事件层78执行对于支持SSE协议合适的完全仿效。在本发明的优选实施例中，网关服务器42实施管理与网页浏览器客户端52的跨来源XMLHttpRequest响应流传输连接的程序，以在侦听来源于在服务器发送的事件流的源中操作的上游目标服务器的附加消息时保持HTTP响应开放。
网页套接字仿效层80支持双向连接。当建立时，所述连接将网页浏览器客户端52与通常在目标服务器36、38上主管的后端服务直接链接。一旦建立，该连接保持开放，并且客户端和服务器都可以异步地来回发送信息。网页套接字仿效层80支持基于文本的协议，诸如Jabber、IMAP等。在优选实施例中，网页套接字仿效层80提供与HTML5相符的网页套接字API的全面实施。优选提供字节套接字(ByteSocket)层82，以支持通过网页套接字仿效层80的二进制数据传输。W3C或IETF没有提供对应的二进制传输协议规范。根据本发明，字节套接字层82实施一般与网页套接字API并行的API。字节套接字API提供附加的方法，以允许二进制原语(primitives)(包括原始字节值)的读和写。字节套接字层82使得能够实施全范围的二进制协议，并且还在用于基于文本的协议的网络上应用二进制压缩和加密。附加的(通常是专用的)客户端协议库可以被包括在客户端库56中作为客户端协议库层84的一部分。这些客户端协议库将典型地实施应用或服务器特定的协议。在本发明的优选实施例中，客户端协议库层84可以包括XmppClient客户端库,其实施例如被Google Talk所使用的传统的XMPP协议。优选地，XmppClient客户端库利用网页套接字仿 效层80来交换面向XMPP文本的消息。客户端协议库层84也可以包括StompClient客户端库,其实施面向流传输文本的消息传递协议(Stomp)。优选地,StompClient客户端库利用字节套接字客户端库来与执行与Stomp相符的应用(诸如ApacheActiveMQ)的远程服务器交换Stomp消息。类似地,可以提供IrcClient客户端库来支持与远程因特网中继聊天(IRC)服务器的消息交换。可以实施更多的专用客户端库(诸如远程帧缓冲客户端库)来支持专用的双向协议。远程帧缓冲协议由虚拟网络客户端(VNC)的实施使用来发送键盘和鼠标事件，并接收网络上的图形屏幕更新。在本发明的替代实施例中，在仿效层70的初始化期间，进行测试，以在网页浏览器客户端52的执行背景内检测Flash插件的潜在存在。如果检测到且被合适地配置为允许用作仿效的辅助，则仿效层70可以选择性地向插件指派某些联网和套接字通信操作，足以建立与指定的网关服务器42的单TCP套接字连接。S卩，虽然Flash插件一般用于支持UI操作，但可以获得内建于插件中的有限联网层和有限套接字能力的选择性的优点。通过仅利用网络和套接字层方面，不产生可视的显示假象(artifact)。然而，由于防火墙、HTTP代理和其它通信壁垒的存在，Flash插件不总是可获得、以可使用的方式配置、或者可使用。仍可以在有限的情况下使用Flash插件提供的联网层。在典型的使用中，网页应用被实施为由网页浏览器客户端52执行的客户端侧应用与分布服务器侧的应用的组合，该分布服务器侧的应用在功能上以源来源服务器34与一个或多个目标服务器36、38的某一组合而实现。网页页面54中的对象引用使得网页浏览器客户端52能够初始地加载作为一个或个多个文档的客户端侧的应用。客户端侧的应用将被典型地设计为与API交互并使用API，所述API与服务器发送的事件层78、网页套接字层80以及字节套接字层82关联。虽然预期网页套接字层80是使用的主导API，但所有的层都可以被客户端侧的应用使用。参照图6，在网页浏览器客户端52的背景中，客户端侧的应用被表示为可执行文档92。如在本发明的优选实施例中所实施的，由于文档92的执行而对客户端库56的API调用将最终实现为postMessage请求94。每个postMessage请求94最少由相关的源和目标来源以及由请求表示的操作限定。源来源是文档92的来源。通过所实施的仿效的本质，消息的目标来源效果上是网关服务器42的来源。为了加载平衡和相对几何关系的原因，可以同时实施多个网关服务器42。实际上，postMessage请求94还将识别目标网关服务器42。在客户端侧应用实施的技术是JavaScript的情况下,建立一个或多个iframe 92作为通信桥。通过跨来源请求层74处理的每个跨来源XmlHttpRequest将实现为对应的postMessage请求94,其继而被优选地作为文档事件而传送到inframe 96的实例。基于与请求关联的源和目标来源的唯一组合选择iframe 96的实例，其中目标来源仍然对应于服务网关服务器42的来源。在本发明的优选实施例中，按需要创建iframe 96的实例，并优选地保持所述实例直到网页页面54或网页浏览器客户端52被关闭。在还未创建用于源和目标来源的组合的iframe的情况下,postMessage层74创建对应的iframe 96,并且,通过与网关服务器42的飞行前(pre-flight)请求/响应事务,通过iframe 96的实例建立信任关系。·
从网关服务器42的角度，飞行前请求的发生与标准的CORS飞行前请求一致，从而许可符合CORS的网页浏览器与网关服务器42协同操作。作为建立该信任关系的一部分，从网关服务器42将通信桥例程下载到iframe 96的实例中，以在iframe 96的实例中实施postMessage API的目标侧。由于该信任关系，对应于启动postMessage请求的XmlHttpRequest可以接着被发送给网关服务器42，并且如果合适，转发给服务的服务器，诸如目标服务器36。在本发明的优选实施例中，在网关服务器42上管理性地建立映射，以限定由其它目标服务器36、38提供的可以通过网关服务器42访问的服务。因此，在postMessage请求表示网页套接字请求的情况下，典型结果是建立了文档92通过对应的iframe 96的实例、网关服务器42至远程服务之间的双向能力的连接，该远程服务42典型地由目标服务器36提供，该目标服务器操作为去往文档92的数据的实时异步源。优选由网关服务器42执行源来源的验证。在JavaScript仿效环境中，网关服务器42验证每个接收的请求包括XMLHttpRequest “Referer”报头和XMLHttpRequest “X_0rigin”报头，该“Referer”报头具有与网关服务器42的目标源匹配的值，且该“X-Origin”报头具有许可的源来源的值。优选地，“X-Origin”报头的值由从网关服务器42下载到iframe 96的实例中的通信桥例程确定。因为网关服务器42是通信桥例程的来源，且通信桥例程确定包含来自于网页浏览器客户端52的iframe 96的实例的文档92的源来源，所以网关服务器42可以信任“X-Origion”报头的值，以精确地识别请求的源来源。对于其它客户端侧的应用的实施技术，诸如Flash和Silverlight，使用类似的仿效架构。一般地，取决于所识别的技术，postMessage请求94将在基础文档92中创建对应的子窗口(类似于iframe 96)。窗口的初始化将产生要被网关服务器42引用和从网关服务器42检索的文档或等效物，作为飞行前请求/响应事务的一部分或等效物。在本发明的优选实施例中，所检索的文档功能上包括通信桥例程，其实施postMessage API的目标侧，从而允许按需要实现基础文档92与子窗口文档之间的安全通信路径。图7中一般地示出了建立与网关服务器42的信任关系的优选过程110。响应于传统页面请求112 (典型地由网页浏览器客户端112的用户启动)，向来源服务器34发出加载页面请求，如请求112所标识的。加载对应页面114，并初始评估116，以定位和加载该页面需要的任何附加对象。在本发明的优选实施例中，嵌入页面的对客户端库56的引用导致从嵌入引用被识别的网关服务器42对基本静态的资源的加载118。网页浏览器客户端52完成与所加载的页面有关的初始化120，包括客户端库的任何必须的初始化，以对于客户端库层70检测和建立对网页浏览器客户端的仿效截取。响应于启动事件(典型地来源于某些用户交互122或文档92的自动操作)，针对客户端库层70作出网页套接字、字节套接字、跨来源请求或其它请求。为了示例的目的，该请求是来源于文档92表示的JavaScript客户端应用的网页套接字请求。该请求还被指定为对由网关服务器42提供的特定服务的请求连接。请求被处理到postMessage层74中124。根据本发明的优选实施例，在合适的iframe 96的示例还不存在的情况下，利用识别网页页面基本文档54的源来源的功能源来源、和识别服务的有效位置的功能目标来源，创建iframe。可以例如利用以下代码，在JavaScript中实施iframe的创建
·
ifrm = document. createElement(〃 iframe")；ifrm. setAttribute(" src"，" http://gateway, com:2750/stockService")；document, body. appendChild(ifrm)；iframe的功能源来源未被显式地设定，而是由通信桥例程对网页浏览器客户端52的调用自动确定。优选在iframe 96的实例的创建以及通信桥例程被下载到iframe96的实例中之后的通信桥例程的初始化期间进行该调用。iframe 96的实例的功能源来源因此被确定为文档92的源来源，例如“http://retailer. com:80”,负责iframe 96的实例的创建。使用“src”属性将功能目标来源显式地指定为例如 “http: //gateway, com: 2750”。飞行前XmlHttpRequest消息(优选标识启动postMessage请求的相关源和目标来源以及所请求的服务)接着发送126到指定的网关服务器42。针对该请求评估网关服务器42上的管理性建立的服务访问策略。在本发明的优选实施例中，该策略一般是如下形式
<service>
<accept>ws://gateway.com:2750/stockService</accept>
<co n nect >f cp ://ta rget.com: 1330〈/connect〉
<type > p. roxy < /ty pe >
<cross-site-constraint>
<albw-origin> http ://retai I er.com: 80 </allow-origin></cross-site-constrai nt>
</service>因此，针对服务“/gwStockService” 的从“http://retailer. com:80^ 至“Ws://gateway. com:2750”的特定跨来源资源请求被确定为可接受。在建立至例如由远程目标服务器36提供的实际服务源“tcp://target. com: 1330/stockService”的基于TCP的网页套接字连接的情况下，该请求还将被网关服务器42的按需要创建支持。在本发明的优选实施例中，可以直接在网关服务器42上主管可由网页浏览器客户端应用92请求的各种服务。在这样的情况下，由服务访问策略指定的连接是对本地主机的连接引用。取决于服务访问策略的评估，返回确认消息128。如果任何情况下都不许可服务连接，则来源请求124本质上失败。在许可的情况下，初始化130网页套接字连接的必要仿效支持。在本发明的优选实施例中，这包括在iframe96的实例内安装postMessage侦听器，以处理到来的请求事件，一般地如以下JavaScript示例所示
var xhr;
window.onmessage = function(event) {
// Create an XMLHttpRequest on the first outgoing transmission if (Ixhr) {
xhr = new XMLHttpRequest();
// when downstream messages arrive,
// post them to the parent window xhr· on progress = function (event) {
// process the incoming event and
// send it to the parent document
window.postMessage(xhr.responseText, bridgeOrigin);
}
}
// if necessary send a pre-flight request
I I * * *
// gateway.com:2750 is the URL of the Gateway in the target origin
xhr,open(method# http://gateway.com:2750, true);
// then, send the data contained In the postMessage
xhr.send(event.data)对应于网页套接字请求124的postMessage请求接着在功能上转换为XmlHttpRequest。具体地，在基础网页页面54的文档内的表示目标文档的窗口上调用与HTML5相符的postMessage请求。该请求传递表示为postMessage数据的消息以及请求的源来源。在先前已建立iframe96的示例的情况下，通过postMessage 74的API传递postMessage 请求。接着将请求发送给网关服务器42并基于服务访问策略验证其合格。网关服务器42接着建立与所标识的目标服务器36的对应连接134。连接134的性质取决于所请求的服务的性质，并且可以是例如TCP或网页套接字连接。接收对XMLHttpRequest的响应,并通过iframe链将其传递回，以向基础网页页面54文档返回响应数据载荷。后续的网页套接字请求124重使用iframe96的示例，从而有效利用源与目标来源之间建立的信任关系。关于其它网页浏览器客户端应用92的技术，与基础页面54的交互可能受限制。如在图8A中一般性地示出的，网页浏览器基础页面54可以嵌入封装的FlasKSilverlight、或其它应用152，其与嵌入在基础页面54中的另一网页浏览器客户端应用92具有有限的必要交互(如果存在)。在本发明的优选实施例中，可以从网关服务器42将这样的封装应用152加载为资源118。在Flash封装的应用152的情况中，作为Flash插件的一部分而提供的Flashruntime库包括一般的私有网络和套接字型的通信能力。优选包括客户端库56作为封装的应用152的一部分，从而允许封装的应用152直接与网关服务器42的外部服务通信。这样的通信是同来源的。本发明的优选Flash实施例提供对具有跨来源资源共享的Flash应用执行的支 持。参照图8B，从源来源服务器34加载的文档92包括对也从源来源服务器34加载的Flash客户端应用156的引用。Flash客户端应用156 (如由网页浏览器客户端52执行的)因此在文档92的源来源和源来源服务器34内执行。Flash客户端应用156继而包括对Flash桥应用158的引用，Flash桥应用158进一步被指定为从网关服务器42加载。Flash桥应用158因此在网关服务器42的目标来源内执行。Flash客户端和桥应用156、158优选被实施为加载为SWF文件格式文档的Flash电影文件。Flash客户端应用156优选包括客户端库56。根据本发明，在Flash客户端与桥应用156、158之间建立了安全通信能力，类似于通过iframe的postMessage通信。优选地，使用共享事件建立此信道，如通过Flashruntime库所支持的，从而允许双向发送数据。通过要求Flash桥应用158的执行来验证标识有网关服务器42验证合格的源来源的Flash客户端应用156，并仅与该Flash客户端应用通信，来确保此通信信道为源与目标来源的唯一组合。在通信信道的初始化中，由Flash桥应用158从Flash客户端应用156的LoaderInfo元数据中检索Flash客户端应用156的源来源。此源来源被返回给网关服务器42。如果允许该来源，则在评估网关服务器42本地的管理性建立的安全策略时，通过返回消息，使得Flash桥应用158能够与Flash客户端应用156进行共享事件通信。一旦可以，当需要访问由例如目标服务器36提供的远程服务时，由Flash客户端应用156实施的客户端侧网页应用就可以跨来源访问网关服务器42。替代地，Flash客户端应用156可以使用网页套接字连接直接与网关服务器42通信。如果期望固有的网页套接字连接，则Flash桥应用尝试向目标网关服务器42发出网页套接字请求。不是通过Flash桥应用158通信，而是Flash客户端应用156的初始执行通过作为Flash客户端应用156的一部分提供的客户端库56发出网页套接字连接请求。使用Flash runtime仿效此连接请求，以请求与网关服务器42的基于套接字的连接。接着从期望的网页套接字的目标来源检索Flash跨域策略文件。网关服务器42优选被配置为具体侦听这样的请求，并返回有效的Flash跨域策略文件。Flash客户端应用156背后的Flashruntime评估该策略并判定是否许可具有目标来源的跨来源网页套接字连接。示例跨域策略文件如下<cross-domain-policy>
<allow-access-from domain =" retailer, com:80" to-ports =" 2750" /></cross-domoin-policy>如果Flash runtime接收到相符的策略文件并且域来源(from-domain)与Flash客户端应用156的源来源一致，则runtime允许客户端库在指定的端口上向目标来源开放套接字，并通过固有网页套接字协议通信。作为网页套接字协议握手(handshake)的一部分，还要求发送用于目标来源的cookie (本地存储信息)。然而，固有套接字连接缺省不发送cookie，所以还向目标网关发送最小的HTTP请求，以便发现附加在目标域上的任何cookie。从HTTP响应解析cookie，并将cookie包括在网页套接字握手通信中。跨来源通信在桌面和小应用(applet) Java客户端中的实施优选采用类似的客户端应用156和桥应用158的架构。对于Java客户端应用156，从源来源服务器34将应用代码加载在.jar文件中，优选包括客户端库56的Java实施。Java客户端应用156因此在文档92的源来源中。在初始执行时，Java客户端应用156将作出从网关服务器42加载桥应 用158 (也作为.jar文件提供)的请求。桥应用158的加载被许可。执行在目标来源中进行。Java客户端runtime包括套接字和HTTP请求库的实施。如果期望固有网页套接字协议连接，则桥应用158可以作出向网关服务器42的套接字连接。如果仿效的网页套接字协议是必要的，例如，如穿过中间介入的代理服务器所需要的，则使用runtime HTTP请求库。为了隔离来自不同来源的代码防止以不安全的方式相互作用，Javaruntime以不同的“类加载器(class loader)”加载来自不同来源的类。缺省地，在一个类加载器中加载的代码不能访问或执行在另一类加载器中加载的代码。然而，runtime系统的核心代码加载在可以被任何其它代码安全地访问的特殊“runtime类加载器”中。为了创建Java客户端与桥应用之间的通信信道(类似于postMessage),客户端与桥.jar内的客户端库56中的代码都实例化已作为核心Java runtime的一部分存在的接口或可扩展类。在runtime类加载器上加载的该类对于Java客户端应用156和Java桥应用158都是可访问的。可用于此目的的示例类是标准的Java类“ java. beans. PropertyChangeSupport”。在所有执行环境的Java runtime中都可用该类，因此,其可以被Java客户端应用156和Java桥应用158调用而不发生安全异常(exception)。PropertyChangeSupport类以及其它的这种类具有足够的一般性(generic),其允许许可在两个方向上传送任意数据的扩展或实施。如在其它客户端runtime环境中所要求的，任何目标通信的报告源来源必须准确且受到不被篡改的保护。为了确保准确，Java桥应用158实施对Javaruntime环境的调用，以确定Java客户端应用156的源来源。具体地,Java桥应用158进行调用，以加载已知存在于Java客户端应用156的.jar文件内的.class文件。在例如此.class文件被命名为“SourceOriginLocation. class”的情况下，Java桥应用158进行以下调用以加载该类URLurl = getClassLoader(). getResource ( " SourceOriginLocation.class")；返回的URL值将包括所加载的.class文件的来源的身份标识，并因此包括源来源。例如，如果Java客户端应用156的.jar文件的名称是“client, jar”，则返回的URL将是以下形式jar:http://retailer. com:80/client, jar ! /SourceOriginLocation. class其中，“http://retailer. com:80”因此是Java客户端应用156的源来源。接着在任何连接期间，将此源来源传递给网关服务器42，从而允许网关服务器42验证并选择性地许可来自此源来源的跨来源连接。因为可以在类加载期间信任Java客户端runtime本身，以返回正确的资源字符串，所以也可以信任源来源值。在本发明的优选实施例中寻址的Silverlight封装的应用152的情况中存在限制。概括地，Silverlight runtime支持的来源安全范围对于与广泛分布的网页应用相结合的实际使用提供了不足够的细节。在本发明的优选实施例中，通过在封装的应用152的设立期间验证合格跨来源通信策略来管理该限制。参照图9，典型地响应于某个用户交互162,封装的Silverlight应用152将通过客户端库56处理Silverlight服务请求(被表示为网页套接字请求164)。如在本发明的优选实施例中所实施的，两个报头将自动地添加 到网页套接字请求164中。在本发明的优选实施例中，报头指定为X-Origin:http://retailer, com:80X-0rigin-http% 3A% 2F% 2Fretailer% 3A80:http://retailer, com:80其中，第一个报头标识有效的源来源，第二个报头是动态产生的报头，其对源来源进行编码。在处理指引到网关服务器42的网页套接字请求164时，Silverlightruntime将辨识跨来源通信企图。接着，Silverlight runtime将启动飞行前请求166,以检索客户端访问策略。飞行前请求常规被指引到来源的根目录，以检索具体命名为“clientaccesspolicy. xml”的文档。因此，在所规定的目标来源是http://gateway.com: 2750 的情况下，文档请求被指引到 http://gateway, com: 2750/c lientaccesspo I icy.xmlo在Silverlight访问的预期中，网关服务器42侦听这样的请求并利用定制的客户端访问策略168响应，其服从具有许可跨来源访问的服务访问策略的网关服务器42。S卩，针对服务访问策略的<cross-site-constraint>条目检查请求的源来源。当约束满足时，动态地产生和返回168clientaccesspolicy. xml文档。客户端访问策略一般将是以下形式
权利要求
1.一种在与HTML5前相符的网页浏览器客户端中提供网页应用支持的方法，使得源服务器提供的应用能够使用目标服务器提供的服务，其中，从被保护而不能与所述源服务器的源来源通信的目标来源提供所述目标服务器的服务，所述方法包括以下步骤 a)通过网页浏览器客户端执行从具有规定的源来源的源来源服务器接收的客户端侧网页应用，其中所述执行的步骤包括请求与请求标识的网页应用服务进行连接的步骤； b)通过所述网页浏览器客户端进行仿效客户端库，在所述网页浏览器客户端与网关服务器之间首先建立双向能力的基于HTTP的通信连接，用于访问所述请求标识的网页应用服务，其中所述网关服务器与所述规定的源来源的范围之外的规定的目标来源关联，并且其中所述双向能力的基于HTTP的通信连接包括跨来源通信桥，其在所述规定的源来源与所述目标来源之间提供安全通信路径；以及 c)通过所述网关服务器，再次建立至由目标服务器提供的目标规定的服务的与HTML5相符的连接，所述目标规定的服务与所述请求标识的网页应用服务具有预先规定的关系。
2.如权利要求I所述的方法，其中所述执行的步骤包括由所述网页浏览器客户端执行通信桥程序，其中响应于所述请求的步骤，从所述网关服务器接收所述通信桥程序，其中在所述规定的源来源内执行所述客户端侧网页应用，并且其中在所述规定的目标来源内执行所述通信桥程序，并且其中在所述通信桥程序与所述网页浏览器客户端之间建立所述跨来源通信桥。
3.如权利要求2所述的方法，还包括通过所述网关服务器验证合格所述双向能力的基于HTTP的通信连接的步骤，其中所述请求提供所述规定的源来源的身份标识以及所述请求标识的网页应用服务，并且其中所述网关服务器判定是否接受所述请求。
4.如权利要求3所述的方法，其中所述验证合格的步骤包括评估服务访问策略，以确定所述规定的源来源与所述请求标识的网页应用服务之间的许可的关系的步骤。
5.如权利要求4所述的方法，其中所述验证合格的步骤包括确定与所述请求标识的网页应用服务的所述预先规定的关系的步骤。
6.如权利要求3所述的方法，其中所述网关服务器还判定是否重定向所述请求，所述验证合格的步骤返回封包在HTTP响应消息中的HTTP重定向消息，以将所述HTTP重定向消息传送给所述客户端侧网页应用。
7.如权利要求6所述的方法，其中所述仿效客户端库包括网页套接字仿效层，并且其中所述首先建立的步骤响应于所述HTTP重定向消息，在所述网页浏览器客户端与重定向网关服务器之间建立所述双向能力的基于HTTP的通信连接，以用于访问所述请求标识的网页应用服务，其中所述重定向网关服务器与所述规定的源来源的范围之外的规定的重定向目标来源关联。
8.一种支持分布网页应用的执行的服务器系统，所述服务器系统包括 a)耦合到网络的源来源服务器系统，所述源来源服务器系统包括客户端侧网页应用，其中能够通过所述网络在源来源的范围内访问所述源来源服务器系统； b)耦合到所述网络的网关服务器系统，所述网关服务器系统包括通信桥程序，其中能够通过所述网络在目标来源的范围内访问所述网关服务器系统，并且其中所述网关服务器能够操作来提供与网页应用服务的网络连接；以及 c)耦合到所述网络的客户端系统，其中所述客户端系统能够操作来执行网页浏览器客户端，其中所述网页浏览器客户端是与HTML5前相符的网页浏览器客户端， 其排除跨来源的消息传递，其中所述网页浏览器客户端能够操作来从所述源来源服务器系统下载所述客户端侧网页应用，其中所述网页浏览器客户端还能够操作来在所述源来源的范围内在所述客户端系统上执行所述客户端侧网页应用，其中所述网页浏览器客户端能够操作来从所述网关服务器系统下载所述通信桥程序，其中所述网页浏览器客户端还能够操作来在所述目标来源的范围内在所述客户端系统上执行所述通信桥程序，并且其中所述客户端侧网页应用和所述通信桥程序实施跨来源的通信信道，所述客户端侧网页应用还能够操作来通过所述通信桥程序和所述网关服务器系统跨来源地发送对于所述网页应用服务的请求。企业客户端-服务器系统以及用于通过网页套接字通信的分布仿效提供网页应用支持的方法
本申请要求2009年5月I日提交的美国临时申请No. 61/174,923的权益。技术领域
本发明一般涉及网络通信系统，并具体涉及能够支持在基于HTTP的网络上实时双向通信的企业级客户端-服务器系统。
背景技术：
虽然网页(Web)应用的开发和使用持续增长，但存在着重要的限制，即广泛使用的HTTP协议仅支持半双工通信。正如在传统的客户端-服务器应用的使用模型的情 况中，在不需要与各种后端系统能够进行客户端交互的情况下，非常期望连续的层至层(tier-to-tier)双向或全双工通信连接。对网页上实时服务的需求是本质的且在不断地增长，所述对网页上实时服务的需求诸如显示实时股票馈送消息、允许特设(ad-hoc)信息更新、使得多个用户之间能够积极参与实时操作，尤其是相遇在竞价、聊天、游戏和其他应用中。
虽然可以使用由私有的客户端和服务器应用支持的其它协议，但网页浏览器客户端无处不在的事实实际上需要使用基本HTTP协议。固有地，基于传统网页浏览器的客户端应用已基本被限制到数据请求和响应一个时刻仅在一个方向上流动的通信。传统上仿效(emulate)双向通信的尝试通常涉及使用轮询技术,诸如Comet和Reverse Ajax中所实施的。本质上，服务器在选择的情况下能够将信息推送(push)给客户端。然而，这些技术存在许多限制，诸如缺少标准化、性能不够以及可扩展性受限。
例如，直接轮询技术要求通常在网页浏览器的背景中实施的客户端应用来以规则的间隔向目标网页服务器重复地发送HTTP请求。每个请求立即接收到服务器生成的响应，并取决于服务器是否有任何更新的信息而潜在地返回更新的实时信息。取决于轮询间隔，可能不是真正实时地接收到接收信息，相反，可能频繁地仅接收到没有响应信息的接收信息，这遭受服务器请求的高开销(overhead)。此开销既影响客户端也影响服务器的性能，并耗费网络带宽。
为了避免直接轮询的开销，已经开发了一种称为长轮询的变型。在长轮询(也被称为异步轮询)中，客户端应用(通常仍然是网络浏览器)向目标网页服务器系统发出请求。代替提供立即响应，目标服务器将延迟某一规定的间隔，等待具有一些信息以提供作为响应。如果在延迟间隔期间服务器获得了一些新(即，实时)数据，则将包含该实时信息的服务器响应发送给客户端。如果没有接收到新信息，则向客户端应用返回空响应，终止待决的请求。因此，长轮询具有降低实时数据的传送等待时间的潜力，并且可以一定程度上减少请求/响应循环(cycle)的数目。然而，长轮询相对于传统轮询不能提供任何实质的性能改善，这是因为在长轮询和轮询两者中，仍然必须在客户端和服务器之间交换大量所需要的请求/响应循环以及类似数量的HTTP报头。
流传输(streaming)是另一传统变型。在使用流传输的情况下，客户端网页浏览器发送完整的请求，但目标服务器以允许该连接保持开放(open)至少一规定的间隔的方式响应。实际上，目标服务器推迟确认响应完成。这允许目标服务器利用该目标服务器接收到的附加实时信息继续响应。建立流传输的连接的益处在于部分降低了客户端和服务器系统的开销。还减少了网络业务量，这是因为客户端和服务器系统仅发送HTTP报头分组一次，以建立流传输连接。仅在需要时发送响应连续(continuance)网络分组,并且所述响应连续网络分组仅包含数据，从而施加最小开销。不幸的是，以HTTP封装流传输，因此，流传输完全取决于网络总体上如何路由低层的HTTP传送。因此，流传输遭受不可预见的连接断开和较大的缓冲等待时间，其由任何给定连接可能路由通过的大量系统整体决定。因此，传统的流传输不可靠。
作为替代，建议的HTML5草拟规范定义了新的协议特征，包括网页套接字 (WebSocket)、服务器发送的事件(Server-Sent Events)、以及关联的访问安全要求,作为能够使用HTTP协议进行可靠双向通信的方法。虽然HTML5规范意在标准化全双工、直接TCP通信等，但最终的规范离被正式采用很有可能要一年或若干年。功能上集成到下一代的网页浏览器、并且在操作上统一采用下一代的网页浏览器，这一点许多年内不太可能发生。此外，由于实际的、商业的以及其它限制而反对更新现已安装的网页浏览器，这一点将可能在许多年中阻止大规模的采用。
因此，需要一种方法，用于基本独立于客户端的网页浏览器而提供实时的全双工通信能力，其可以用于访问所有性质的网页服务，包括商务和其它商业服务、娱乐和信息服务。发明内容
因此，本发明的一般目的是提供一种有效网关服务器系统架构，其使得能够进行实时双向的浏览器通信，其在适用的情况下与当前建议的HTML5规范一致。
在本发明中所述目的通过提供一种系统而实现，所述系统使得能够在与HTML5前(pre-HTML5)兼容的网页浏览器客户端中进行服务器之间的分布网页应用中的服务通信，所述服务器在其它情况下由于跨来源(cross-origin)安全限制而不可访问。网页浏览器客户端执行从具有规定的源来源的源来源服务器接收的客户端侧网页应用，并请求与请求识别的网页应用服务的连接。仿效客户端库的执行在网页浏览器客户端与网关服务器之间建立双向能力的基于HTTP的通信连接，使源来源的范围之外的目标来源提供向请求识别的网页应用服务的访问。双向能力的基于HTTP的通信连接包括在源与目标来源之间提供安全通信路径的跨来源通信桥。网关服务器可以建立与目标规定的服务的HTML5兼容的连接，该连接由目标服务器提供，该目标规定的服务与请求识别的网页应用服务具有预先规定的关系。
本发明的优点在于可以一般地实施分布网页应用，而与参与的网页浏览器客户端是否与HTML5完全兼容无关。通过使用本发明的实施例实施分布网页应用，以功能上与HTML5规范兼容的方式，在后端系统与服务直到网页浏览器客户端之间确保了合适的消息处理传送。此外，优选实施例在功能上与HTML5标准兼容。固有兼容的HTML5网页浏览器客户端可以透明地参与到并且处于本发明所支持的分布网页应用中，而不需要改变服务器或客户端应用代码。
本发明的另一优点在于客户端仿效库提供基于二进制和文本两者的协议支持。二进制协议支持是非常期望的规范扩展，其允许其它仅文本网页套接字协议的特征增强，并且通常使得能够在客户端和服务器之间进行原始的TCP通信。二进制协议支持的提供被有效地接口到网页套接字协议支持中，而不影响HTML5的兼容性。固有兼容的HTML5的网页浏览器客户端同样受益于二进制协议并可以使用二进制协议。
本发明的另一优点在于网页浏览器客户端仿效栈(stack)以及与网关服务器的协同工作性能很高(highly performant)。消息传送是有弹性的(resilient)。因为客户端启动了所有连接性，包括用于下游服务器发送的事件请求的连接，所以客户端和网关服务器之间的通信由于实施了 HTTP协议而可以无缝地穿过防火墙和代理服务器。在连接断开或请求丢失的情况下，客户端侧的网页应用可以选择自动地重连，确保消息的传送。优选将重连操作实施为客户端协议库84。此外，仿效层可以自动地辨别和认可本地网页浏览器客户端的代理服务器设置，消除必须穿过网页代理服务器的连接的任何潜在的问题。此外， 可以以不同的客户端技术实施客户端库，并且在所有情况中，客户端库都可以提供合适的API,以允许针对服务的协议事务(transaction)。不需要复杂的基于小服务器(servlet)的以及其它定制服务器侧的支持逻辑(潜在地包括多客户端/服务器通信事务)来实施应用服务器逻辑。而是，网页浏览器客户端应用可以与文本和合适的二进制数据分组通信，从而减小通信开销、复杂度和执行等待时间。本发明所表示的分布网页应用构架易于扩展来支持非常大的用户社区，甚至是全球商业应用的环境。
本发明的再一优势是网关服务器对在分布网页应用环境中并因此任何特定组的网页浏览器客户端可以访问的服务和来源服务器的组提供易于管理的控制。
本发明的再一优势是网关服务器的使用提供了用于从一个或多个后端服务可获得的或从所述后端服务向所有参与的连接的网页浏览器客户端发送的数据的广播和多播通知的有效基础。后端数据源可以向一个或几个涉及的网关服务器发送数据，从而允许以有效的方式从单个接触点向网关服务器支持的网页浏览器客户端散布，作为新服务器发送的事件的通知。
本发明的再一优势是仿效客户端库可以用来支持许多不同的专门客户端协议。通过调节可用于通过网关服务器下载的客户端库资源，可以有效地支持需要特定或甚至私有客户端协议的任何分布网页应用。
图I是用于本发明的优选实施例的优选操作环境的一般图示。
图2是示出适用于在实施分布客户端/服务器网页应用中实施本发明的优选实施例的客户端/服务器系统的框图。
图3是示出适用于在实施分布客户端/服务器网页应用中实施本发明的优选实施例的优选客户端/服务器系统的框图。
图4提供了示出与本发明的优选实施例一致的分布客户端/服务器网页应用相结合的、用于实施客户端侧应用而配置的网页浏览器客户端的细节框图。
图5是实施为与本发明的优选实施例一致的分层库栈的客户端库的框图。
全文摘要
一种能够在服务器之间的分布网页应用中进行服务通信的系统，所述服务器在其它情况下由于与HTML5前相符的网页浏览器客户端中跨来源安全限制而不可访问。网页浏览器客户端执行从具有规定源来源的源来源服务器接收的客户端侧网页应用，并请求连接到标识的网页应用服务。仿效客户端库的执行在网页浏览器客户端与具有源来源的范围之外的目标来源的网关服务器之间建立双向的基于HTTP的通信连接，提供对请求标识的网页应用服务的访问。双向的基于HTTP的通信连接包括跨来源通信桥，其在源和目标来源之间提供安全的通信路径。网关服务器可以建立至由目标服务器提供的目标规定的服务的与HTML5相符的连接，该目标规定的服务与请求标识的网页应用服务具有预先规定的关系。
文档编号G06F15/16GK102893270SQ201080028945
公开日2013年1月23日 申请日期2010年5月1日 优先权日2009年5月1日
发明者J.R.法罗斯, F.萨利姆, D.B.冈斯, S.埃拉亚 申请人:卡金公司