专利名称：保证服务供应商所推荐的服务的可用性的方法和系统的制作方法
技术领域：
本发明涉及服务供应商向连接到Internet的用户所提供的服务的可访问性，具体地说，涉及一种用于保证由服务供应商等通过Internet所推荐的服务的可用性的方法。
背景技术：
服务供应商市场沿着价值链(value chain)从纯连接服务提升到提供增值和税收产生服务。服务供应商的商业模型最初由使用记录(minutes of use)驱动，并越来越多地由数据通信所替代，该商业模型由访问外部服务的用户产生，通常不是由服务供应商本人来维护而是通过服务供应商平台来访问。因为服务供应商是用户和外部服务的媒介，所以他扮演着重要的角色。他的特权地位允许他不仅提供“简单”访问，而且在其可保证服务等级的条件下提供诸如安全、单独签名、开账单、定位等一样的增值服务。
就用于访问外部网络服务的服务一般是网络浏览器的World Wide Web而言，这个简单的问题通常需要复杂的答案。
当网络首次出现时，它似乎是极好的通信新方法。按照开放、简单和易于实现的主要目标来设计每件事情。用于搭建网页的超文本标记语言简单、清晰而且易于掌握。超链接为开发者提供新的方法来清楚地连接并组织信息。文件可以容易的跨过国界。但是，重大的损失之一是状态保持。网络服务器不关心它在谁的计算机上，该计算机在哪个国家，该计算机如何到达该网页，谁在该计算机上打字和点击，或者该网页已经加载多久了。每个与服务器的连接是独立的事件，与此前的任何事件都无联系。网络服务器没有能力控制和调节它所接收的业务量。
为了控制由客户产生的业务量，将一部件置于客户和服务器之间。就WWW而言，该名为代理的部件位于服务供应商平台中，通过配置规则强迫客户网络浏览器通过网络代理。
有多种方式来采用代理。其中之一是采用如“逆向代理(reverse proxy)”的代理，以为它们的平台增加更多的安全性并以有效的方法来保护它们的后端网络服务。这些服务时常需要保持对话上下文以便能够将网络对话与用户上下文相联系。
当将代理服务器配置为逆向代理服务器时，可见客户是目标内容服务器。对于内容服务器来说，逆向代理服务器作为客户需求的发起者。假如客户期望访问一文件，例如main.html，则他将它的浏览器指向代理服务器www.DomainA.com，并认为这是内容服务器的Internet地址。该逆向代理服务器将接收该客户对main.html的请求，从位于w3.DomainB.com的内容服务器取回所请求的网页，并且将该网页返回客户。
因为仅有逆向代理服务器可以直接地与防火墙之外的内容服务器通信，所以逆向代理服务器隐藏了来自公共Internet的内容服务器。而且，因为网址内容可以跨越多个网络服务器以便提高性能和便于内容发布，所以逆向代理模式可用于内部或者后端网络服务器。
客户所发出的请求通常使用超文本传输协议(HTTP)。采用该协议，请求(和响应)包括三部分识别客户所请求的资源的请求行、用于在客户和服务器之间传输信息的HTTP报头和消息内容。在采用HTTP协议的系统中，可配置HTTP代理以保护对内容服务器及其资源的访问。可将其配置为通过提示输入可向用户注册进行校验的用户名和密码，能够对所有的试图访问代理功能的用户进行基本的验证。
但是，尽管在用户和内容服务器之间使用逆向代理能够保证通信的安全性，在发送任何新的请求之前，仍然无法实时地控制服务供应商的可用性。因此，当代理接收请求时，尽管在先的请求已经使服务器过载并由此引发服务器性能降低的故障，该代理服务器仍然无法拒绝请求。
发明内容
所以，本发明的主要目的是实现一方法，该方法利用在代理中实现的现有HTTP协议来保证由服务供应商等所推荐的服务的可用性。
由此，本发明涉及用于在数据传输系统中保证由服务供应商等所推荐的服务的可用性的方法，该系统包括连接到Internet网络的至少一个用户工作站，为了响应来自所述用户工作站的服务请求而能够提供由服务供应商所提供的服务的多个内容服务器，和互连于所述Internet网络和所述内容服务器之间用于接收来自所述用户工作站的所述服务请求并将每一个发送到提供请求服务的内容服务器代理服务器；所述方法包括下列步骤当所述代理服务器接收服务请求时，-在上下文表中查找相应于在所述服务请求中定义的统一资源定位符的入口，以确定能够提供请求服务的内容服务器，-在从所述代理服务器向所确定的内容服务器发送所述服务请求之前，将服务可用性请求附加到所述服务请求，-在从所确定的内容服务器向所述代理服务器发送所述应答之前，将服务可用性令牌附加到由所确定的内容服务器提供的应答，-当接收该应答时，由所述代理服务器从所述应答中删除所述服务可用性令牌，-在发送所述应答至所述用户工作站之前，通过使用包括在所述服务可用性令牌中的信息在所述代理服务器中更新所述上下文表。
本发明的上述和其他目的、特点和优点将通过结合附图阅读下面更详细的说明书得以更好的理解，其中图1是表示采用本发明的方法的系统方框图。
图2是表示在代理服务器中，实现发送服务可用性请求的方法的步骤的流程图。
图3是表示当入口必须被更新时，在代理服务器中实现的方法的步骤的流程图。
图4是表示当接收到服务可用性令牌时，在代理服务器中实现的方法的步骤的流程图。
具体实施例方式
图1说明采用本发明的方法来实现的系统。该系统包括Internet网络10、连接到Internet网络的多个用户工作站12、14、16，和通过代理服务器24连接到Internet网络的多个内容服务器18、20和22。该代理服务器可以是前向代理或者逆向代理。但是，最好采用逆向代理以便为系统增加安全性并以有效的方法来保护后端网络服务。作为代理功能的部分，可配置HTTP代理来保护对该代理服务器及其资源的访问。可将其配置为通过提示输入用户名和密码，能够对用户进行基本的验证。
为了实现根据本发明的方法，采用上下文表是必要的特征，该表包括至少如下的信息
-服务器名是包括在URL中的后端服务器的主机名。
-IP地址采用IP V4或者IP V6格式。
-URL与该服务器名相联系的一个URL。
-可用性不“可用的”百分比或NA。
-最后接收从服务器最后接收令牌的日期和时间。
-请求发送表示是否可用性请求已经被发送的标记。在每次接收响应时，该标记被复位。
-重试次数已经发送的服务可用性请求的次数。
-最后发送最后发送可用性请求的日期和时间。
图2中的流程图表示在代理中所执行的本发明方法中的一部分。首先，从客户接收请求(步骤30)。检验是否包含在请求中的URL或服务器名在上下文表中(步骤32)。请注意，因为单个主机名可以与多个URL相联系，所以在上下文表中有多个与同一服务器相联系的入口。也请注意，在查找上下文表之前，代理必须通过使用用户档案信息(profile information)验证和/或授权以访问服务。
然后，通过查看该表的“可用性”列，来检验在上下文表中服务器或URL是否可用(步骤34)。假如否，则拒绝客户请求(步骤36)。假如该服务器或URL可用，则检验当通过多个服务器可访问服务时是否有多个入口(步骤38)。如果是，则选择具有最高可用性的入口(步骤40)。在这两种情况中，检验所选择的入口是否需要刷新(步骤42)。这种需要取决于在如下定义的上下文表中读出的标准。假如需要刷新，则将服务可用性请求附加到从代理发送到内容服务器的客户请求(步骤44)。然后，通过修改“重试次数”和“最后发送”参数来更新上下文表(步骤46)。假如在更新上下文表之后入口已经被刷新的情况下并且当由于服务器不可用而使客户请求被拒绝时入口不需被刷新，则处理返回起点等待来自客户的新的请求(步骤30)。
当时，在上下文表中没有发现URL或服务器名，检验是否必须监测服务器或URL的可用性(步骤48)。假如是这样，则将服务可用性请求附加到从代理发送到内容服务器的客户请求(步骤50)。在这种情况下，由于在表中必须建立新的入口，所以上下文表必须被更新(步骤52)。在更新上下文表之后或者假如不需要监测服务器的可用性，则处理返回起点等待来自客户的新的请求(步骤30)。
请注意，服务可用性请求被发送进入HTTP请求的HTTP报头中，该HTTP请求是由代理发送到服务器的。该HTTP报头采用如说明书RFC 2616中所说明的格式。
建议的报头的格式如下服务-可用性version_number(version_number是由代理所支持的服务可用性协议的版本号(缺省为1.0))。
包括该报头的HTTP请求的例子是GEThttp//urlHTTP/1.0User-agentMozilla/4.0Accepttext/html，image/gifForwardedbyhttp//proxy.company.com8080Service-availability1.0图3说明了与刷新上下文表入口的步骤有关的方法的一部分。首先，在上下文表中指定新的入口(步骤60)。然后，检验该入口是否按照标准必须被刷新(步骤62)，该标准在如下所述的上下文表中给出。假如是，则在上下文表中检验是否已实现最大重试次数(步骤64)。假如是这样，则这意味着在上下文表中URL或服务器被设置为不可用(步骤66)。假如还没有实现最大重试次数，则将新的HTTP服务可用性请求发送到服务器(步骤68)。在这两种情况下并且当入口不需刷新时，处理返回起点指向在上下文表中下一个入口(步骤60)。
为了确定入口是否必须被刷新，代理使用诸如“请求发送”、“重试次数”、“最后接收”、“最后发送”一样的上下文表的参数和包括以下变量的配置文件-SARetry服务可用性重试定时器-SARefresh服务可用性刷新定时器-MxRet重试最大次数在考虑到下述因素的情况下，执行入口需要刷新的测试从最后被接收的令牌起所花费的时间(参数“最后接收”)，从最后发送的请求起所花费的时间(参数“最后发送”)，在没有接收到令牌的情况下请求已被发送的事实和已经执行的重试次数。通过以下程序实现该测试<pre listing-type="program-listing">IF ((current time-last_received)＞SARefresh)THEN IF (request_sent＝Yes)THENIF ((current time-last_sent)＞SARetry)THEN IF(Number of retries＜MxRet)THENAppend Service Availability RequestRequest sent＝YesNumber of retries＝1Last_sent＝current_timeELSEUpdate Context Table with Availabilitv＝NotAvailable/*实现最大重试次数ELSE /*空闲 ELSE Append Service Availability Request Request sent＝Yes Number of retries＝1 Last_sent＝current_timeELSE Do nothing</pre>
图4的流程图说明方法的一部分，该方法与当接收来自服务器对服务可用性请求的应答时在代理中所实现的步骤相关。首先，通过代理接收应答(步骤70)。代理判断在应答中是否存在服务可行性令牌(步骤72)。假如是，则代理对服务可行性令牌进行解码(步骤74)。然后，如果必要，则通过修改参数“最后接收”和写入参数“可用性”来更新上下文表(步骤76)。在此之后，将令牌从应答消息中删除(步骤78)。然后，将所接收的不带令牌的应答或者当已删除令牌时的应答转发到用户(步骤80)。
附加到应答的服务可行性令牌由内容服务器发送，包括对于提供服务的整个服务器的可用性的至少一个百分比(0-100％)，并且也可包括详细的信息如●需要被监测的、由服务器所提供的资源的特定URL；●该URL允许的请求/时间帧(秒或分)的最大数目●重定向URL●服务可用性时间窗口在本发明的优选实施例中，该信息可以XML格式编码，由此需要描述在服务可用性档案中所支持的标签的文件类型定义文件。例如下文所述，为每个资源指定的4个标签(RES_TYPE，RES_ID，RES_AVAILABILITY，RES_UNIT)的DTD描述。单个的服务可用性档案可包括多个资源信息<pre listing-type="program-listing">＜？xml version＝′1.0′encoding＝“UTF-8”？＞＜！ELEMENT RESOURCE(RES_TYPE，RES_ID，RES_AVAILABIL1TY，RES_UNIT)＞＜！ELEMENT RES_AVAILABILITY(#PCDATA)＞＜！ELEMENT RES_ID(#PCDATA)＞＜！ELEMENT RES_TYPE(#PCDATA)＞＜！ELEMENT RES_UNIT(#PCDATA)<!-- SIPO <DP n="7"> --><dp n="d7"/>＞＜！ELEMENT SAP(RESOURCE+)＞</pre>这样，应答所包括的服务可用性令牌将如下所示<pre listing-type="program-listing">HTTP/1.1 200 okServerNetscape-Enterprise/4.0DatexxxContent-typetext/htmlService-availabilitv token＂＜？xmlversion＝″1.0″？＞＜！DOCTYPE SAP SYSTEM sap.dtd＞＞＞＜SAP＞＜RESOURCE＞＜RES_TYPE＞url＜/RES_TYPE＞＜RES_ID＞＜/start.html＞＜/RES ID＞＜RES_AVAILABITY＞3/RES_AVAILABILITY＞＜RES_UNIT＞minute＜/RES_UNIT＞＜/RESOURCE＞＜/SAP＞″</pre>
权利要求
1.用于在数据传输系统中保证由服务供应商等所推荐的服务的可用性的方法，该系统包括连接到Internet网络(10)的至少一个用户工作站(12、14、16)，响应来自所述用户工作站的服务请求而能够提供由服务供应商所提供的服务的多个内容服务器(18、20和22)，和连接于所述Internet网络和所述内容服务器之间用于接收来自所述用户工作站的所述服务请求并将每一个发送到提供请求服务的内容服务器代理服务器(24)；所述方法的特征在于当所述代理服务器接收服务请求时的如下步骤，-在上下文表中查找相应于在所述服务请求中定义的统一资源定位符的入口，以确定能够提供请求服务的内容服务器，-在从所述代理服务器向所确定的内容服务器发送所述服务请求之前，将服务可用性请求附加到所述服务请求，-在从所确定的内容服务器向所述代理服务器发送所述应答之前，将服务可用性令牌附加到由所确定的内容服务器提供的应答，-当接收该应答时，由所述代理服务器从所述应答中删除所述服务可用性令牌，-在发送所述应答至所述用户工作站之前，通过使用包括在所述服务可用性令牌中的信息在所述代理服务器中更新所述上下文表。
2.如权利要求1所述的方法，其中所述上下文表包括多个相应于与同一个服务器名相联系的多个URL的入口。
3.如权利要求2所述的方法，其中所述上下文表包括与URL相联系的可用性，该与URL相联系的可用性作为每个入口的参数，该参数是可用性的百分比或者“不可用”。
4.如权利要求3所述的方法，其中假如在所述上下文表中的参数“可用性”被定义为不可用，则拒绝所述服务请求。
5.如权利要求4所述的方法，其中所述上下文表包括相同服务器名的多个入口，在查找入口的步骤中选择具有最高参数“可用性”的入口。
6.如权利要求5所述的方法，其中所述上下文表包括多个与所述被发送的服务可用性请求相联系的参数，当从所述代理服务器向所述内容服务器发送所述服务可用性请求时，该参数被更新。
7.如权利要求6所述的方法，还包括步骤考虑作为包括在所述上下文表中的参数的函数的一些变量来刷新所述上下文表的入口，该变量诸如从最后接收的令牌起所花费的时间，从最后发送的请求起所花费的时间，在没有接收到令牌的情况下请求已被发送的事实和已经执行的重试的次数。
8.如权利要求7所述的方法，其中当所述重试次数等于预定最大次数时，将所述上下文表的参数“可用性”设置为不可用。
9.如权利要求8所述的方法，其中所述服务请求使用超文本标记语言编写，并且所述服务可用性请求包括在所述HTTP服务请求的报头中。
10.如权利要求9所述的方法，其中所述服务可用性令牌采用XML格式。
11.如权利要求10所述的方法，其中当从所述内容服务器接收所述服务可用性令牌时，更新所述上下文表，并且假如必要，则改变参数“可用性”。
12.一种系统，包括适用于实现根据权利要求1到11中任何一个方法的步骤的装置。
全文摘要
用于在数据传输系统中保证由服务供应商等所推荐的服务的可用性的方法，该系统包括至少一个用户工作站；多个内容服务器，响应用户工作站的服务请求而能够提供由服务供应商所提供的服务；和代理服务器，连接于Internet网络和内容服务器之间用于接收服务请求并将每一个发送到服务器以提供请求服务。该方法包括在上下文表中查找在服务请求中定义的统一资源定位符，在向服务器发送请求前，将服务可用性请求附加到由服务器提供的请求，在向代理发送应答前，将服务可用性令牌附加到由服务器所提供的应答，当接收该应答时，由代理从应答删除所述服务可用性令牌，和在发送应答至所述用户工作站前，通过使用包括在服务可用性令牌中的信息在代理中更新上下文表。
文档编号H04L29/08GK1475927SQ03147448
公开日2004年2月18日 申请日期2003年7月10日 优先权日2002年7月11日
发明者菲利普·巴佐特, 弗朗科伊斯-泽维尔·德劳伊特, 伊斯-泽维尔 德劳伊特, 菲利普 巴佐特 申请人:国际商业机器公司