专利名称：用于在计算机设备之间传送数据的方法和设备的制作方法
技术领域：
本发明涉及一种在多个计算机设备之间传送数据的方法和设备，具体地，涉及一种用于允许多个后端服务按高效的方式发起与使用这些后端服务的多个应用之间的通信的方法和设备，这些后端服务由诸如移动无线网络的单个后端系统提供，并且这些后端服务使得(内部或外部)应用开发者可以对后端系统的一个或更多个特征进行受控访问。
背景技术：
本发明人开发了一种系统(以下称为网关或平台)，通过该系统，移动网络(或其他类似的“后端”系统)可以向第三方应用开发者提供许多(基本成批的)服务，这些第三方应用开发者接着可以容易地开发并向最终客户部署新的(零售)服务。这为移动网络操作者和第三方应用开发者均提供了商业机会。
例如，大部分GSM移动电话网络都具有对连接到该网络的移动手机(即，用户单元)(即，当开机并且位于合适基站的范围内时)进行定位的能力。然而，大部分这种网络目前并不向最终用户提供该服务。这是因为，网络不能简单地以不受控制的方式向第三方提供该服务，因为例如存在拒绝服务型攻击的可能性(在该服务型攻击中，第三方可以不断地请求用户单元的位置，直到由网络提供的服务水平由于过大负荷而劣化到可能降低其他用户单元执行和接收电话呼叫的能力的程度)。另一方面，开发(在或大或小的程度上)包括了这种设施的受到良好控制具有完整功能并且有利可图的服务，是通常由专业的第三方应用开发者更高效地完成的活动。然而，这仍然要求网络运营商控制对这种设施的访问，并且针对每个新提出的应用逐个地进行这种控制是相对缓慢和低效的事情。
因此本发明人开发了一种无线应用程序接口(API)服务网关以提供用于在应用开发者与网络运营商的需求之间架设桥梁的基础设施。该网关使得运营商可以向开发者的广大市场提供商业无线API服务(如定位、消息传递以及计费)，而这又使得可以开发并在成本上高效地推广新应用。该网关向开发者提供了宽范围的容易使用、可靠并且安全的服务。
该网关的一个重要特征在于，它包括服务暴露引擎(SEE)，其上运行有各应用的远程设备可以在诸如因特网的标准网络上联系该SEE。这向各许可应用提供了对由网络运营商提供的服务的受限访问。该SEE包括许多公共特征，这些公共特征确保了在应用与网关之间的连接是安全的和经认证的，并且网关还包括如下机制，该机制使得在任何时候都可以对应用可以导致施加于网络上的最大负荷进行控制。
为了通过网关访问网络服务，应用发起与网关的安全连接。注意，总是由应用而不是由网关发起该连接。其原因是，非发起方需要执行一定量的处理，以尤其确保发起方是它所要求的(即，确保正确的认证)。这是通过向网关提供所谓的“web服务器”功能来实现的。如果每个应用还必须具有处理建立由网关使用web服务器功能发起的连接的能力，那么所有应用的复杂性必定会显著增大。如果网关开发者带来了额外的复杂性，那么这将为网关管理员带来额外的维护问题(优选地，总是避免需要远程支持安装在远程第三方机器上的软件的情况)。另选地，这将给应用开发者/管理员带来相当大的额外负担，因此只要有可能就应当使该复杂性理想地最小化。
因此，目前，应用为了在某个未知时刻从服务接收数据，它必须按等时间间隔不断地联系服务并询问所述服务是否有要提供给该应用的任何新数据。该间歇式通信方法被广泛用于数据通信系统中，并且通常工作良好，只要在以下两种情况之间找到了正确的平衡频繁联系网关，以至于导致网关上的过大负荷；和不频繁联系网关，以至于在某个数据到达网关服务与它被传送到相应应用之间可能存在不希望的长延迟。不幸的是，在目前的情况下网关运营商与应用运营商(它们的需求是完全不相一致的，因为轮询越不频繁网关上的负荷就越小，但是应用就越可能必须等待某个数据)是分离的商业实体，因此就任何一方而言都根本没有试图牺牲其需求的动机。
发明内容
本发明试图提供这样一种方法，其在不明显偏离上述网关的设计特征的情况下至少在某种程度上解决了上述冲突。
注意，对这种网关的使用并不限于移动电话网络的情况，可以将相同类型的网关应用于具有可用于生成许多不同端用户应用的某些基本功能的任何大系统，只要可以按直接、简单、安全并且可靠的方式将这些功能提供给第三方应用开发者即可。
根据本发明的第一方面，提供了一种通过网关设备向一个或更多个应用宿主子系统提供由第一子系统提供的服务，将所述网关和所述或每个应用宿主子系统配置成使得允许所述或每个应用宿主子系统通过非安全数据网络连接发起到所述网关的安全并且经认证的连接，并且在逻辑上将所述网关连接到第一子系统，以使得可以将由第一子系统提供的服务提供给所述或每个应用宿主子系统，所述网关包括通知装置，该通知装置用于通知所述多个应用宿主子系统中的一个或更多个它或它们应当发起与所述网关的安全的经认证的连接。
优选地，由所述通知服务器提供的所述多个通知不包括任何敏感或有价值的数据(这是为了如果在非安全数据网络上恶意的第三方拦截了该信息或者无意地将该信息无寄送给恶意的第三方，那么不能误用该信息，使得给对该系统的任一方感兴趣的多方中的任一方带来损害或不便)。优选地，在所述多个通知不包括任何可执行代码的意义上，所述多个通知是完全被动的。优选地，所述多个通知是简单文本文件，优选地，具有所述简单文本文件具有可扩展标记语言(XML)文件的具体形式。
该形式的系统与其中应用宿主子系统必须不断地对网关进行轮询以查看它们是否有任何新消息(等，等待这些新消息)的上述系统相比具有所述多个应用宿主子系统所需的额外复杂性最低的优点，并且还在不增大在第一子系统上的服务接收到应用的某个信息与所述应用接收到该数据之间的最大延迟的情况下避免了对所述网关的过大负荷。
优选地，所述多个通知精确地指定哪个服务希望联系所述应用宿主子系统(或者更精确地说，希望由所述应用宿主子系统来联系哪个服务)。优选地，在所述通知服务器与由第一子系统提供的所有服务之间存在公共接口，并且在所述通知服务器与所述多个应用宿主子系统中的每一个之间存在公共接口，使得所述通知服务器能够对通知执行与源无关并且与接受者无关的操纵、择路以及分派。
优选地，由第一子系统提供的在所述通知服务器与所述多个服务中的每一个之间的公共接口允许一服务针对单个通知指定标识了所述目的地应用的标识符、标识了所述请求服务的标识符以及一个或更多个操纵行为参数。优选地，所述多个操纵行为参数可以包括以下两者中的一个或两个在发生了一次或更多次对所述通知的发送的不成功尝试的情况下应当尝试发送所述通知的尝试次数；和在发生了一次或更多次对所述通知的发送的不成功尝试的情况下在再次尝试发送所述通知之间的延迟。
优选地，所述通知服务器可进行操作以生成用于控制在所述不安全数据网络上对各个不同的通知的发送的不同执行线程。这具有如下优点如果使用不同的线程来发送许多不同的通知，由于可以“并行地”发送它们，因此使得所述通知服务器为多个通知生成服务提供对通知的足够的吞吐量，尽管存在每个通知都可能耗费大量时间来穿过网络的可能性。
优选地，所述通知服务器保留对其的传送失败了的多个通知，并在达到了服务指定或默认次数的尝试的服务指定或默认延迟之后重新试图传送它们。
本发明还提供了一种用于本发明的上述第一方面的系统的通知服务器，及其相对应的方法、计算机程序以及计算机程序产品。
为了可以更好地理解本发明，以下仅以示例的方式参照附图对本发明的多个实施例进行描述，在附图中
图1是根据本发明一实施例的系统的示意性例示图；图2是使用图1的系统来提供端用户定位服务的示例应用的示意性例示图；图3是示出在提供上述端用户定位服务时在图1和2的系统的各种要素之间交换的信号的信号图；图4是例示由与端用户和在客户机应用与后端系统之间的网关相交互的客户机应用执行的步骤的流程图；图5是例示由在客户机应用与后端系统之间的网关中的服务插件执行的步骤的流程图；图6是图1的通知服务器的原理功能结构的示意性例示图；以及图7(a)到7(e)是由图1和6的通知服务器的5个重要模块/对象执行的步骤的流程图。
具体实施例方式
参照图1，优选实施例的系统具有3个域客户机应用域100、网关域200以及后端系统域300。通过不安全数据网络将客户机应用域100与网关域200连接起来。在本实施例中，还通过不安全网络将网关域200与后端系统域300连接起来，然而，在另选实施例中该不安全网络通常可以是安全网络连接。
客户机应用域100包括以各种第三方服务器机器(未示出)为宿主的多个客户机应用110、120、130、140、150(注意，客户机应用通常既充当客户机应用又充当服务器应用，因为对于与它们进行联系的端用户客户机它们将充当服务器应用，而当它们与网关域200进行联系时它们将充当客户机应用)。在图1所示的这些具体示例中，由包围框101表示的单个组织通过网关域200的操作员使用单个顾客账号来操作所有应用110、120、130，以下将对其意义进行更详细的说明。此外，如图1所示，某些应用(如应用150)可以访问诸如数据库152的不同资源，所有这些应用都被视为落在当前应用域100内。
网关域200包括以下主要组件主入口205和平台操作员入口210；Java消息传递服务器(JMS)队列软件组件215；通知服务器软件组件220(以下待更详细描述)和服务暴露引擎(SEE)250。SEE 250包括一组分级服务层252和一组服务插件模块254到257。所述一组分级服务层252向所有服务插件254到257提供多个基本服务，包括对在不安全网络上传送的数据进行加密和解密处理、对在不安全网络上相互进行通信的多方进行认证等。多个服务插件254中的一个是完整性管理器服务器站插件(IMSS)254，其执行对如何允许各客户机应用110到150与SEE 250相通信进行调控的特殊功能。
在相关专利申请EP01308317.5中可以找到包含在各客户机应用110到215内的IMSS和相对应的完整性管理器客户机端(IMCS)组件的全部详情，通过引用将该专利申请并入于此。简言之，IMSS 254与多个客户机应用中的每一个中的对应的IMCS进行通信，以对各客户机应用可以与SEE 250进行联系的频度进行调控；网关平台操作员可以利用该机制来“遏制”任何特定应用可以与SEE进行联系的频度，以减小在使用强度高时SEE上的负荷。该机制包括所谓的“心跳(heart beat)”，在该“心跳”中，各客户机应用IMCS联系IMSS，并从IMSS更新一组当前参数，该组当前参数指定了当前应用可以与SEE内的指定服务插件进行联系的频度(或者，在另选实施例中，它们那可以简单地(即，与它希望联系的实际服务插件无关地)指定该应用可以与SEE进行联系的频度)。
在本实施例中，所示出的其他服务插件是GSM定位服务插件255、GPS定位服务插件255、GPS定位服务插件256以及短信服务(SMS服务插件257)。以下对这些服务插件的功能进行更详细的描述。
在本实施例中，由网关平台操作员和网关的客户均可以浏览的网站服务提供主入口205和平台操作员入口210，并且，在合适的情况下，对在网关操作员与客户机应用设备之间的商业关系的详情进行更改。例如，特定客户机应用可以与网关平台操作员进行协商，以访问特定服务并且按商定的价格在特定时段内对该服务进行最大次数的请求。如果当前应用操作员接着要求增加他希望能够在特定时段中对SEE内的特定服务插件进行的请求的最大次数，那么可以使用主入口来改变它，只要存在用于允许相应地提高对当前应用计费的价格的合适的配置即可。类似地，如果客户通过某种另选机制(例如，通过电子邮件)与网关操作员进行联系以请求对在多方之间的契约关系的这种改变，那么可以使用平台操作员入口来标识并修改各客户账户的所有详情。
在本实施例中，后端系统域300是GSM移动电话网络310，该GSM移动电话网络310包括移动定位中心312和SMS中心314(以下将参照图2和3对其功能进行更详细的描述)，还包括通常与诸如基站的移动网络基础设施相关联的各种特征和通过数据网络互连并与各种其他电信和数据网络相连接的关联广播天线杆305。
作为图1所示的系统的操作的示例，以下参照图2对图1的客户机应用110的操作进行描述。以下将当前应用110称为iLocate。iLocate应用110使得用户(例如“爸爸”)9可以使用他的经由因特网连接到iLocate应用110的个人计算机10通过另一用户(例如“爸爸”的女儿“凯特”)19的GSM移动电话20来确定她的位置。为此，客户机应用iLocate 110将使用GSM定位服务插件255和/或GPS定位服务256来搜索凯特的手机20的位置，并且还可以使用SMS服务插件257，以向凯特的手机20发送SMS和从该手机20接收SMS。服务插件255、256以及257接着与后端系统300进行通信，后端系统300通过基站天线杆305向凯特的手机20发送数据并从该手机20获得数据。
为了确定移动手机装置的位置，GSM定位服务插件255和GPS定位服务插件256实质上简单地与移动定位中心312进行联系并询问它以获得所述信息。移动定位中心获得该信息的方式与本发明并不相关，因此不对它进行详细描述。简言之，如由这些服务的名称表示的，对于GSM服务，移动定位中心确定用户在哪个小区中，并通过将其与该小区覆盖的地理区域相关联来给出该移动站的大致位置；对于GPS服务(仅当待定位手机包括GPS接收器时才可用该服务)，移动定位中心发送一SMS消息，该SMS消息使得手机使用它的机载GPS接收器自动查找它的位置，然后向移动定位中心发送回带有所确定的位置的详情的SMS。其意义在于对移动定位系统进行操作的后端系统信任网关，以确保该网关既不会使移动定位中心过载也不会不恰当地使用它的服务。
下面参照图3，对为了允许用户9(爸爸)向用户19(他的女儿凯特)发送SMS并从用户19接收SMS而在图2所例示的各种组件之间交换的信号进行描述。
为了使得可以对SMS进行这种交换，iLocate应用110发起与网关200的连接。它通过首先从iLocate应用111的开发者控制部分向由平台操作员提供的完整性管理器客户机端(IMCS)模块114发送请求发起信号405，来执行所述发起。IMCS 114在接收到发起请求信号405时生成另一发起信号410，该发起信号410被发送给位于网关域200内的完整性管理器服务器端(IMSS)服务插件模块254。信号410是在IMCS 114与IMSS 254(其具有被设置为服务暴露引擎250的一部分的一组分级服务层252的优点)之间经完全认证并加密的通信。在该通信过程中，IMCS114向IMSS提供与iLocate应用110有关的各种详情，在本实施例中，这些详情包括与监听器地址(即，服务器的网际协议(IP)地址和端口号)有关的详情，iLocate应用110针对由通知服务器220提供的通知消息对该监听器地址进行监听。此外，作为通信410的一部分，IMSS 254向IMCS 114传送与IMCS 114应当发起心跳通信的频度有关的详情。
当完成了通信410时，IMCS 114发起心跳通信415a。这同样是利用了所述一组分级服务层252的安全的经认证的通信，所述一组分级服务层252确保呼叫方确实是iLocate应用110而不是假冒者并且此时IMCS确实是经授权而与IMSS 254进行联系的。通信415a(以及随后的心跳通信415n)的规则心跳的主要功能是为了指定iLocate应用110可以从服务插件255到257(应用110被适时地与它们注册在一起)中的任一个请求服务的频度。(由主入口205或平台操作员入口210执行注册)。随后的心跳通信415按等时间间隔发生，并被用作遏制应用110可以与服务暴露引擎250进行联系的频率的机制，而且提供了用于确保服务暴露引擎250和应用110(以及互连数据网络)均仍然正在正确地运行的机制。在相关欧洲专利申请EP01308317.5中可以找到心跳通信的全部详情。
按此方式在应用110与网关200之间建立了通信线路之后，然后应用110等待用户请求。由此，当接收到来自PC 10的登录请求通信420时，应用110将向PC 10提供到它的网站的接入口，从该网站向PC 10的用户(“爸爸”)提供各种服务。在登录之后，PC 10的用户从由应用110提供的网站中选择发送带有用户指定的插入文本“你好吗？”的SMS信号，希望将该SMS信号发送给由其移动电话号码标识的移动电话，这使得将已发送SMS信号425从PC 10发送到iLocate应用110。
当完成了发送SMS通信425时，应用110试图使用SMS插件257发起发送SMS通信430。为了实现该目的，执行许多较低层活动(对于其详情，请读者参见相关欧洲专利申请EP01308317.5)，但是这些活动包括使用IMCS 114检查应用110当前有权利发起这种连接以及在服务暴露引擎250内与分级服务层组252进行协商。一旦已经成功地完成了通信430，SMS服务插件257(通过包括SMS中心314和移动网络基础设施305在内的各种中间体)发起向手机20的又一发送SMS通信435。
在本示例中，当接收到SMS时，手机20的用户(“凯特”)希望发送响应SMS。注意，在本实施例中，SMS服务插件257只具有与其相关联的单个电话号码，必须将所有来达SMS文本消息都定址到该电话号码。在本实施例中，SMS服务插件257保持有它先前已向其发送了文本消息的目的地电话号码的记录，并使用在该文本消息中包括的呼叫者ID来确定应当将所接收到的SMS传送给哪个应用。在另选实施例中，SMS服务插件257可以具有任意大数量个移动电话号码，可以将来达SMS寄给这些移动电话号码；或者SMS服务插件257可以包括一种用于更明确地指定应当将来达SMS传送给谁的另选标识机制。
由此，在本示例中，手机20生成回复SMS(“很好”)，将该回复SMS从手机20通过与在发送SMS通信435中使用的中间体相同的中间体发送到SMS服务插件257。
当接收到回复SMS 440时，服务插件257向JMS队列215“投入”一“事件”，该事件指定要向应用110发送请求它与SMS服务插件257进行联系的通知。随后，通知服务器220从该JMS队列取出该事件并(按以下待更详细地描述的方式)对其进行处理。将事件投入JMS队列与随后由通知服务器220从JMS队列获取该事件的组合构成了如图3所例示的事件通信445。
作为由通知服务器220执行的处理的结果，通知服务器220发起与监听器112的简单(未认证并且未加密的)TCP/IP连接450，并通过该连接向监听器112发送一通知(以下对该通知的本质进行更详细的描述)。
当接收到该通知时，监听器112通过转发通知通信455将该通知转发给位于应用110的主(客户机应用专用)部分111内的通知处理模块(未示出)，应用110对该通知进行处理，从而确定它应当试图与SMS服务插件257进行联系。
因此应用110试图(按与建立发送SMS通信430相对应的方式)建立收集SMS通信460；注意，在本实施例中，该通知并不具体指定应用110应当与SMS服务插件257进行联系的目的，而仅仅是回调型通知，该通知使得应用110与服务插件257进行联系，并通知该服务插件它是由于接收到通知而进行该联系的。当建立了收集SMS通信460时，服务插件257将它具有的针对应用110的任何数据(包括它已从手机20接收到的SMS)传递给应用110。
作为接收到该回复SMS的结果，应用110对信息进行更新(在其网站上将该信息显示给PC 10)，当PC 10接着刷新(即，重新加载)来自应用110的网页时，将通知该PC 10有一SMS正在等待它，并且可以通过按常规方式从该网页选择合适的链接来收集该SMS。由iLocate应用110执行的方法在参照图3对在图1和2所示的系统的各种要素之间的交互示例组进行了描述之后，以下参照图4对当应用110在图1的系统内正常地操作时由应用110执行的多个步骤进行更一般性的描述。由此，在该方法开始时，流程进行到步骤405，在步骤405处该应用执行任何初始化过程，重要的是，这些初始化过程包括建立监听器112。如上所述，监听器112是这样一种简单的编程结构只要给出了正确的IP地址和端口号，该编程结构就使得第三方可以建立与该监听器的TCP连接。本领域的技术人员很好理解，通过指定只可以按此方式向监听器发送简单的文本文件，即使在相当强有力的防火墙(如希望针对经由因特网的未授权访问来保护其内部网络的组织经常使用的防火墙)的背后也可以建立这种监听器。
在步骤405完成后，本方法进行到步骤410，在步骤410处，IMCS 114建立与IMSS 254的通信，以按上述并且在相关申请EP 01308317.5中更详细地描述的方式将所述应用与网关200注册在一起。
在步骤410完成后，本方法进行到步骤415，在步骤415中，确定该应用是否已接收到从应用110请求服务的用户请求。如果接收到了请求，则处理进行到步骤420，在步骤420处对该请求进行及时的处理；为了完成该请求，如果有必要，则该处理包括与服务暴露引擎250中的一个或更多个服务进行联系。在步骤420完成之后，本方法回到步骤415。
如果在步骤415中确定不存在等待处理的已接收请求，则本方法进行到步骤425，在步骤425中，确定应用是否已通过其监听器112接收到来自通知服务器220的通知。如果没有接收到这种通知，则本方法返回到步骤415并继续下去，然后等待新用户请求或新通知。
如果在步骤425中确定已接收到新通知，则本方法进行到步骤430，在步骤430中对该通知进行处理以识别出服务插件255到257中的哪个服务插件发起了对该通知的发送。
在步骤430完成后，本方法进行到步骤435，在步骤435中与在步骤430中识别出的服务插件进行联系。在与有关服务插件进行联系时，所述应用接着对它从服务插件接收到的信息执行任何必要的后续步骤。例如，在SMS插件257的情况下，可能已接收到新的SMS文本消息，以由应用110将该新SMS文本消息向前发送给它的多个用户中的一个。类似地，如果有关服务插件是GPS定位插件256，则可能GPS定位插件256最近已接收到如先前由应用110的用户所请求的关于一移动装置的所在之处的信息。
在步骤435完成后，本方法返回到步骤415，在步骤415中，等待其他用户请求或通知以进行合适的处理。
由服务插件255到257执行的方法下面参照图5，以下对服务插件(如服务插件255到257中的任何一个)的基本操作方法进行描述。当启动服务插件时，本方法进行到步骤505，在步骤505中确定是否已从一应用(如该服务插件被与其注册在一起的应用110)接收到新服务请求。若是，则本方法进行到步骤510，在步骤510中对该请求进行处理。该处理包括检查该请求是否合法，并且，为了完成该请求，如果有必要，服务插件与远程服务(如由后端系统310提供的服务312、314中的一个)进行联系。在510完成后，本方法返回到步骤505。
如果在步骤505中确定尚未从应用接收到新请求，则本方法进行到步骤515，在步骤515中，确定服务插件是否已接收到针对与该服务插件注册在一起的多个应用中的一个(如应用110)的任何数据(注意，这里“数据”是指如下任何种类的事件服务插件注意到该事件，并且，对于该事件，该插件服务认为应当通知与该插件服务注册在一起的多个应用中的一个)。如果确定尚未接收到这种数据，则本方法返回到步骤505。否则，本方法进行到步骤520，在步骤520中，确定待向其通知新接收到的数据的应用是否具有与服务暴露引擎250注册在一起的监听器，如果所关注的应用没有合适的监听器，则本方法返回到步骤505。在此情况下，服务插件仅仅进行等待，直到所讨论的应用下一次试图与服务插件进行联系，此时服务插件会自动将数据或其他事件通知给该应用。
然而，如果在步骤520中确定所关注的应用确实具有合适的监听器，则本方法进行到步骤525，在步骤525中，该应用生成一通知请求。在本实施例中，该通知请求具有如在公知的Java消息传递服务(JMS)中使用的消息对象的形式。
接着本方法进行到步骤525，在步骤525中，使用Java消息传递服务将所生成的通知请求消息发送给通知服务器。具体地，在本实施例中，通过服务插件将该通知请求消息置于JMS队列215上来执行该发送，随后通知服务器220从该JMS队列215消耗通知请求消息。在由通知服务器消耗通知消息时，通知服务器对请求进行处理并生成具有XML文档的形式的通知并将该通知发送给合适的应用监听器。在图5中通过子例程700例示了由通知服务器执行的操作。由图5中的点线例示了在服务插件与通知服务器之间的间接(解耦)连接，这表示该连接是经由JMS队列215的异步连接。
在步骤525完成后，服务插件的方法返回到步骤505。注意，以下参照图7a到7d对在子例程700中执行的步骤进行更详细的描述。通知服务器220下面参照图6，对本实施例中的通知服务器220的构架软件特征或模块进行描述。
监听器模块610执行从JMS队列215取出寻址到通知服务器220的消息的功能，并将它们作为事件(可以根据如从JMS队列215接收到的消息在格式上对这些事件进行修改)存储在先入先出(FIFO)事件存储部620中。
假脱机程序(spooler)模块625取出存储在FIFO事件存储部620中的事件，并将它们提供给“调度器”，该调度器定期地调用假脱机程序以使用假脱机程序625查看是否存在任何未处理事件。该假脱机程序与高速缓存模块630进行通信，该高速缓存模块630又与地址映射存储部635进行通信，以使得假脱机程序可以找出作为待派发事件的目的地的应用的监听器的IP地址和端口号(高速缓存630和地址映射635按常规方式进行操作，使得如果在高速缓存中不存在希望的地址详情，则该高速缓存从地址映射中请求这些地址详情，将这些详情传递给假脱机程序625并将这些详情的拷贝存储预定时段，以使得可以在不必与地址映射635进行联系的情况下直接由高速缓存回答对同一详情的随后查询)。假脱机程序625还与重试控制器模块640进行通信，该重试控制器模块640接收调度器未成功地尝试派发的多个事件，并确定是否应当在某个随后时间点重试派发它们；若是，则存储它们直到这种时间点，然后将它们再提交给FIFO事件存储部620。
通知服务器220还包括调度器工厂模块670，该调度器工厂模块670对FIFO事件存储部620进行监测，如果它检测到在FIFO事件存储部中存在需要派发的新事件，则它生成新调度器对象671、672。每个调度器对象671、672都按它自己的执行线程运行，并且在任何一个时刻都只负责单个通知，使得网络延迟不会累积增加到使随后的通知延迟得不被发送，直到已成功发送先前的通知(或者对先前的通知进行了尝试然后失败)为止。一旦调度器671、672完成了对通知的处理(要么通过成功地发送它，要么通过将其报告回假脱机程序625)，它就使用假脱机程序625进行检查以查看是否存在待派发的未处理通知，若是，则它取出该通知并尝试派发该通知，否则它自我销毁；该自动池大小确定行为针对当前需求使派发容量均衡化。
在图6中示出的还有这样的机制诸如iLocate Live应用111的应用通过该机制可以将它们的监听器112套接字ID(即，IP地址和端口号)与通知服务器注册在一起。如图6所示，在本实施例中，通过以下两者中的任一个可以执行该注册应用直接通知服务插件(例如SMS服务插件257)，然后该服务插件将地址详情传递给地址映射635本身；或者另选地，应用使用它的监听器地址详情与访问控制模块680的公共点进行联系，然后由控制部680将该监听器地址详情传递给地址映射635。
通知服务器操作概要由此可以对通知服务器的总体操作进行如下描述。调度器工厂670对FIFO事件存储部620进行监测，当它确定存在过多等待派发的事件时，它启动新调度器671、672。如上所述，调度器671、672按它们自己的执行线程运行；这是有必要的，因为网络延迟会使各派发操作延迟极其长的时段(几秒)。调度器671、672调用假脱机程序625以给予它们待派发事件；如果假脱机程序625报告不存在等待事件，则调度器671、672自我销毁。
客户机应用开发者从提供XML-感知监听器的许多提供者中的一个寻找这种组件，并将其与应用的其余部分相集成。开发者理解来自服务平台的所有事件将遵循一个标准形式(例如，服务ID、事件类型、事件参数)。
在操作中，执行以下步骤1)客户机(对于服务平台，通过唯一ID对该客户机进行了认证)通过接入部680的公共点或通过任何服务256、257报告它的监听器地址(IP地址和端口)。
2)将客户机监听器的[ID+地址]提交给地址映射635。
3)客户机通过它们的API使用多个服务256、257。
4)出现了一事件，有关服务256、257生成被发送给通知服务器事件队列215的事件。该事件包括它所寻址到的客户机110的ID。
5)监听器610获取该事件并将它置于FIFO(先入先出)事件存储部620中。
6)调度器671、672调用假脱机程序625以向它供应一事件。
7)假脱机程序625从FIFO事件存储部620中取出下一事件。
8)假脱机程序625提取客户机ID并针对一地址对高速缓存630进行查询。如果有必要，高速缓存630对地址映射存储部635进行查询。假脱机程序625将该事件和传送地址提供给调度器671、672。调度器将该事件转换成XML文件并试图将它传送给客户机监听器112。
9)假设第一次传送尝试失败了，则调度器671、672报告传送已失败。
10)假脱机程序625将该事件提交给重试控制器640，该重试控制器640丢弃该事件(如果它已达到它的重试极限)或将该事件保持一定时段(重试时段)。
11)一旦已经过了该事件的重试时段，则重试控制器640将它提交给FIFO事件存储部620。
12)调度器671、672调用假脱机程序以向它供应一事件。
13)假脱机程序625从FIFO事件存储部620中取出下一事件。
14)假脱机程序625提取客户机ID并针对一地址对高速缓存630进行查询。如果有必要，高速缓存630对地址映射存储部635进行查询。假脱机程序625将该事件和传送地址供应给调度器671、672。
15)调度器671、672将该事件转换成XML文件并将它传送给客户机监听器112。
16)调度器671、672调用假脱机程序625以向它供应一事件。如果假脱机程序作出表示不存在其他入队事件的响应，则调度器671、672自我销毁。
对该处理的更改允许通知服务器220为事件设置不同的重试尝试极限、重试时段、持久性等。在本实施例中由服务用于提交事件(以上步骤4)的事件记录的形式包括用于表示所需事件处理行为的占位符。
通知服务器220可以对传送失败进行检测并通过另选方式(例如，电子邮件)向客户机所有者告警。
当接收到该通知时，监听器112与客户机应用111相交互，该客户机应用111采取合适的动作(典型地，引起到服务器中对合适的服务API的调用，以例如获取来达SMS消息)。
在本实施例中还根据接入部680的公共点或通过任何服务255、256、257提供了测试方法。在请求时，生成一测试事件。按照任何其他事件来处理该测试事件，并将其传送给合适的已注册监听器。如果未传送测试事件通知，则客户机111能够检测到事件传送机制的故障。对通知服务器220的具体模块的详细考察下面参照图7a到7e，对由通知服务器220内的5个主要模块/对象执行的具体步骤进行描述。
监听器模块610的方法首先参照图7a，在步骤705处在启动本方法之后，由监听器模块610执行的方法启动了，在步骤705中，确定在JMS队列215中是否存在寻址到通知服务器220的新消息。如果不存在这种等待消息，则本方法继续返回到步骤705，直到检测到这种消息为止。
如果在步骤705处检测到寻址到通知服务器220的消息，则本方法进行到步骤710，在步骤710中，从JMS队列获取该消息。在步骤710完成后，本方法进行到步骤715，在步骤715中将所获取的事件存储在FIFO事件存储部620中。在本实施例中，通过简单地获得如从JMS队列215获取的消息对象并按不修改方式存储它，将它存储在FIFO事件存储部620中。然而，在另选实施例中，可以读取该消息的主要内容并将其调整为另选格式(例如不同的Java对象)，然后按该修改的格式存储在FIFO事件存储部中。在步骤715完成后，本方法返回到步骤705，并等待其他待处理消息。
调度器工厂模块670的方法下面参照图7b，在调度器工厂670执行的方法启动之后，该方法进行到步骤720，在步骤720中，确定在FIFO存储部620中是否存在等待派发的任何事件。如果不存在这种等待派发的事件，则本方法继续返回到步骤720，直到在FIFO存储部620中检测到这种待处理的事件为止。
如果在FIFO存储部620中检测到事件，则本方法进行到步骤725，在步骤725中，生成新调度器对象。在本实施例中，在步骤725完成后，本方法返回到步骤720，并再次查看是否存在等待派发的事件。这意味着在本实施例中，如果在本方法回到步骤720之前假脱机程序仍然未从FIFO存储部中获得事件，那么即使实际上只需要一个调度器对象，也可能会生成一个或更多个其他调度器对象。这不会带来问题，因为这种过多的调度器对象会在适当的时候自我销毁。然而，可以使用更复杂的方法来避免发生该情况，如在生成调度器之后在返回步骤720之前引入小的延迟，或者针对特定事件检查是否已生成了调度器，等等。在图7b的步骤725与图7d的开始步骤之间的点线表示对新调度器对象(图7d例示了其操作方法)的实例化。
假脱机程序模块625的方法下面参照图7c，由假脱机程序模块625执行的方法在它启动之后进行到步骤730，在步骤730中，确定是否一调度器已请求一新事件以将其派发给客户机应用(如应用110)。如果未检测到调度器对象的这种请求，则本方法进行到步骤735，在步骤735中，确定调度器是否试图返回失败事件(即，调度器已尝试并且未能成功地派发给合适的监听器的事件)。若是，则在步骤740中假脱机程序625获取该失败事件并将其传递给重试控制器640。否则，本方法返回到步骤730，并等待调度器与其进行联系以接收待派发的新事件或返回失败事件。
如果在步骤745处确定存在等待要派发的新事件的空闲调度器，则本方法进行到步骤745，在步骤745中，从FIFO存储部620中取出待派发的下一事件(注意，即使在图7c中未明确示出，但是如果在FIFO存储部中不存在等待派发的事件，则跳过步骤750，并且在步骤735处，通知调度器不存在等待事件，于是调度器简单终止)。
在步骤745完成后，本方法进行到步骤750，在步骤750中，从高速缓存中(或者，如果必要的话，通过高速缓存从地址映射中)查找作为所述事件待发送到的目的地的监听器地址，然后本方法进行到步骤755，在步骤755中，将该事件传递给调度器，然后调度器试图适当地派发该事件。在步骤755完成后，本方法返回到步骤730，并再次等待调度器与其进行联系以接收待派发的新事件或返回失败事件。
调度器对象671、672的方法下面参照图7d，由各调度器对象671、672执行的方法在(在步骤725处由调度器工厂模块670)实例化了之后进行到步骤760，在步骤760中，调度器671、672与假脱机程序625进行联系以请求待派发的新事件。在步骤765处，调度器确定它是否从假脱机程序625接收到了待派发的新事件，或者确定假脱机程序是否已报告它当前没有等待派发的事件。如果后者是本情况(即不存在等待派发的事件)，则调度器对象自我终止(该自我终止的能力是在Java和其他面向对象语言中的标准特征，其防止了不被使用的对象占用计算资源)。
然而，如果在步骤765中确定向调度器给予了待派发的新事件，则本方法进行到步骤770，在步骤770中，调度器根据在由假脱机程序传递给它的事件中包含的信息生成形成了待传送给客户机应用的通知的内容的XML文件；在生成了该XML文件之后，调度器接着使用在假脱机程序向它传递事件时由假脱机程序传递给调度器的地址详情，试图将该通知发送给监听器。
在步骤770完成后，本方法进行到步骤775，在步骤775中确定传送是否成功。如果传送成功了，则本方法返回到步骤760，以请求其他待派发事件。然而，如果由于某种原因而传送不成功，则本方法进行到步骤780，在步骤780中将未成功传送(即，失败)的事件传递回假脱机程序(该假脱机程序又将该失败事件传递给重试控制器640)。在步骤780完成后，本方法再次返回到步骤760。
重试控制器模块640的方法下面参照图7e，由重试控制器模块640执行的方法在启动之后进行到步骤782，在步骤782中，确定是否已从假脱机程序625向它传递了失败事件。若是，则本方法进行到步骤784，在步骤784中，确定该事件是否为待重试的事件。在本实施例中，通过读取与该事件相关联的重试参数以查看它是否具有零值，确定该事件是否为待重试的事件。重试参数指定了在对事件的传送失败的情况下待对其进行重试的次数，并且可以具有在表示根本不重试的零与某个预定最大值之间的任何整数值；首先由最初生成该事件(其被置于JMS队列215上)的服务插件来设置该重试参数。
如果在步骤784中确定不对事件进行重试，则本方法进行到步骤786，在步骤786中由重试控制器简单地删除该事件并且本方法返回到步骤782。另选地，如果在步骤784中确定要对事件进行重试，则本方法进行到步骤788，在步骤788中，由重试控制器存储该事件并对重试该事件的时间进行计算和监测。在本实施例中，通过读取重试时间间隔参数并将其加上由系统时钟(未示出)给出的当前时间来计算重试该时间的时间。在计算了该重试时间之后，本方法回到步骤782。
如果在步骤782处确定未接收到失败事件，则本方法不进行到步骤784，而是进行到步骤790，在步骤790中，确定是否已达到或经过所述(多个)事件等待重试的(最早)重试时间。若否，则本方法返回到步骤782。否则，本方法进行到步骤792，在步骤792中使已达到或超过了其重试时间的事件的重试参数递减1。在步骤792完成后，本方法进行到步骤794，在步骤794中接着将该事件置于FIFO存储部620中，随后将按前述方式再从FIFO存储部620中拾取出该事件并由假脱机程序625来重试。在步骤794完成后，重试控制器640的方法返回到步骤782。
通知格式在本实施例中，如在网关域200与应用域100之间的不安全网络上发送的每个通知都具有可由以下文件类型定义(DTD)文件来验证的可扩展标记语言(XML)文件的形式<!ELEMENT event(parameter*)><!ATTLIST eventappAccID CDATA #REQUREDserviceID CDATA #REQUREDtype CDATA #REQURED><!ELEMENT parameter(#PCDATA)><!ATTLIST parametername CDATA #REQURED>
该形式实质上规定按可由该DTD验证的XML文件的形式提供的通知是可以包含零个或更多个“参数”(它们构成了“事件”的子“元素”)的“事件”。事件必须具有被称为“appAccID”(其为作为该通知的目的地的客户机应用的标识)、“serviceID”(其为发送通知的服务插件的标识)以及“type”(其指定了通知的类型(例如测试通知或回调通知))的三个属性。它还规定每个参数必须具有被称为“name”(其给出了参数的名称)并含有可解析的字符数据(即几乎是任何事情)的属性。
例如，以下XML文件可由该DTD来验证。< xml version=”1.0” ><!DOCTYPE event SYSTEM“event.dtd”><event appAccID=”iLocate”serviceID=”SMS”type=”callBack”><parameter name=”Event_Number”>1</parameter><parameter name=”Param2”>Val2</parameter><parameter name=”Param3”>Val3</parameter></event>
该XML文件实质上表明该通知是针对iLocate应用110的，它发自SMS服务插件257并且其类型是回调型。此外，它含有3个参数，第一个参数被称为Event Number并具有值1(即，这是一个序列号，它使得接收应用可以将该通知与随后的类似通知区分开，还使得应用可以在网络错误地对该通知发送了一次以上的情况下避免对同一通知作用一次以上)。它还含有被称为Param2和Param3的分别具有值Val2和Val3的两个其他参数，在本示例中这些参数是冗余的，但是可用于指定例如各方9、19(在它们之间正在发送由客户机应用拾取的文本消息)的标识等。
监听器112在本实施例中，使用XML(SAX)工具箱(其为用于对XML进行解析的工具箱)的Simple API并将XML类事件推发到应用中，来形成监听器112。Java以及诸如Microsoft的其他环境提供了该监听器。在本实施例中，采用Java编写iLocate应用110。
在本实施例中，通过使用SAX工具箱形成监听器112，如本领域的技术人员很好地理解的，SAX工具箱要求注册内容处理程序，该内容处理程序是客户机应用110内的(Java)方法(对象)，其知道在XML内预期会有什么元素并且在传送这些元素时如何处理它们(以及它们的值)。同样，本领域的技术人员很好理解，按如下方式使用SAX工具箱通过DTD来建立监听器112监听器112将针对DTD对来达XML进行验证，并且在XML中存在任何错误的情况下将调用(同样在客户机110内的)错误处理器方法。客户机应用110接着在网络上打开一套接字，当它从服务器得到连接时它打开该连接作为输入流并将该XML传递给内容处理程序(作为由SAX工具箱提供的parse()方法上的参数)。在它对XML进行解析时，由SAX工具箱提供的继承方法使得该内容处理程序方法可以在对XML进行解析的过程中注意任何重要点(起始文件、起始元素等)。按此方式(这是对SAX的所有标准使用)，内容处理程序能够建立来自XML内的所有值(appAccID、serviceID、类型、参数)的记录。当使内容处理程序知道已达到事件元素的末端时，内容处理程序获取它在对XML文件进行解析的过程中使用被传递给它的值填充后的事件对象，并将该事件对象传递给按合适的方式对该事件起反应(例如，与所标识的服务插件进行联系，由此，例如从服务器中取出SMS消息)的事件处理器。
出于如下几个原因，客户机端事件对象(即，在应用域100中)与代表服务器端(即，在网关域200中)的事件的对象不同在服务器端的事件对象内有在对事件进行传送时使用的许多参数(例如，重试参数)，因此不适合于客户机看到。此外，使用XML的全部要义是将服务器端与客户机端解耦开。同样显见的是，在SAX的外部定义客户机端的事件对象。SAX仅仅告诉内容处理程序它正在XML中寻找什么，而内容处理程序使用该信息作为应用所需的信息。
注意，可以采用任何希望的开发范式(如Java、Perl、Microsoft等)来开发诸如iLocate应用110的客户机应用。Java开发者可以决定使用其他XML工具箱来开发诸如DOM或JDOM的监听器模块(等同于监听器112)。Microsoft开发者可以使用SAX或Microsoft XML Parser(MSXML)。Perl开发者也可以使用SAX，或使用为Perl专门提供的某些其他工具箱。其他客户机开发环境可以使用它们自己的XML工具箱。
权利要求
1.一种在不安全网络上从服务器应用向客户机应用提供数字服务的方法，其中，所述客户机应用能够在所述不安全网络上发起安全的客户机到服务器连接，以请求服务并从所述服务器应用接收所得输出数据，该方法包括以下步骤响应于当在所述客户机应用与所述服务器应用之间不存在安全连接时所述服务器应用检测到一事件的发生，生成标识了所述服务器应用并定址到所述客户机应用的通知；将所述通知转发给通知服务器应用；将所述通知从所述通知服务器应用转发给所述客户机应用；以及，响应于接收到所述通知，所述客户机应用发起在所述客户机应用与所述服务器应用之间的所述不安全网络上的安全连接。
2.根据权利要求1所述的方法，其中，所述通知具有非可执行数据文件的形式。
3.根据权利要求2所述的方法，其中，所述通知具有含有可扩展标记语言文件的简单文本文件的形式。
4.根据前述任一权利要求所述的方法，该方法还包括以下步骤在所述通知服务器应用内运行用于对将多个分立通知转发到所述客户机应用的步骤进行控制的多个分立线程。
5.根据前述任一权利要求所述的方法，该方法还包括以下步骤如果对所述通知的传送失败，那么所述服务器应用指定要重试传送所述通知的次数；如果在所述不安全网络上对所述通知的传送失败，那么所述通知服务器重试传送所述通知达指定的次数。
6.根据前述任一权利要求所述的方法，其中，单个通知服务器从多个服务器应用接收多个通知，并将所述多个通知转发给多个客户机应用。
7.一种客户机服务器系统，其包括客户机子系统、服务器子系统以及互连数据网络，所述客户机子系统包括可进行操作以发起在所述互连网络上与所述服务器子系统的安全连接的客户机应用，所述服务器子系统包括服务器应用，所述服务器应用可进行操作以与所述客户机应用相协作，来在所述客户机应用发起所述连接时完成对与所述客户机应用的安全连接的建立，并且所述服务器应用还可进行操作以响应于对由所述客户机应用提供的服务的请求而在这种连接上传送输出数据，其中，所述服务器子系统还包括通知服务器，并且其中所述服务器应用还可进行操作以响应于检测到在所述服务器应用与所述客户机应用之间当前尚未建立安全连接时发生了事件而生成一通知，并将所述通知发送给所述通知服务器，并且其中所述通知服务器可进行操作以在所述互连网络上将所述通知转发给所述客户机应用。
8.根据权利要求7所述的客户机服务器系统，该客户机服务器系统还包括向所述服务器子系统提供服务的后端系统，其中，所述服务器子系统充当在所述客户机子系统与所述后端系统之间的受信中间体。
9.一种用于在权利要求7或权利要求8的系统中使用的通知服务器，该通知服务器包括用于从一个或更多个服务器应用接收通知的装置；用于处理所述通知以建立所述通知的目的地地址的装置；以及用于将所述通知传送给在所述通知中标识的相应客户机应用的装置。
10.一种用于在权利要求7或权利要求8的系统中使用的通知服务器，该通知服务器包括用于从一个或更多个服务器应用接收通知的接收模块；用于处理所述通知以建立所述通知的目的地地址的处理器；以及用于将所述通知传送给在所述通知中标识的相应客户机应用的传送模块。
11.一种用于在权利要求7或权利要求8的系统中使用的服务器应用，该服务器应用包括如下装置，该装置用于响应于检测到在所述服务器应用与客户机应用之间当前尚未建立安全连接时发生了事件而生成一通知，并将所述通知发送给通知服务器，以将所述通知向前转发给所述客户机应用。
12.一种用于在权利要求7或权利要求8的系统中使用的客户机应用，该客户机应用包括监听器模块，所述监听器模块用于通过通知服务器从服务器应用接收通知，并用于使得所述客户机应用通过发起到所述服务器应用的安全连接对所述通知进行响应。
13.一种客户机服务器系统，该客户机服务器系统包括客户机子系统、服务器子系统以及互连数据网络，所述客户机子系统包括客户机应用，所述客户机应用具有用于发起在所述互连网络上与所述服务器子系统的安全连接的装置，所述服务器子系统包括服务器应用，所述服务器应用具有用于与所述客户机应用相协作以在所述客户机应用发起所述连接时完成对与所述客户机应用的安全连接的建立的装置；和用于响应于对由所述客户机应用提供的服务的请求而在这种连接上传送输出数据的装置，其中，所述服务器子系统还包括通知服务器，并且其中所述服务器应用还包括用于响应于检测到在所述服务器应用与所述客户机应用之间当前尚未建立安全连接时发生了事件而生成一通知的装置，和用于将所述通知发送给所述通知服务器的装置，并且其中所述通知服务器包括用于在所述互连网络上将所述通知转发给所述客户机应用的装置。
14.一种计算机程序或计算机程序套件，其用于在执行所述计算机程序或计算机程序套件的过程中对一个或更多个计算机处理器进行控制以执行根据权利要求1到6中的任何一项所述的步骤。
15.承载有根据权利要求14所述的计算机程序或计算机程序套件的计算机可读介质。
全文摘要
本发明提供了用于在计算机设备之间传送数据的方法和设备。客户机服务器系统(100、200、300)包括客户机子系统(100)、服务器子系统(200)以及互连数据网络。客户机子系统包括可进行操作以发起在互连网络上与服务器子系统(200)的安全连接的客户机应用(110、120、130、140、150)。服务器子系统包括服务器应用(254、255、256、257)，该服务器应用可进行操作以与客户机应用相协作，来在客户机应用发起连接时完成对与客户机应用的安全连接的建立，并且服务器应用还可进行操作以响应于对由客户机应用提供的服务的请求而在这种连接上传送输出数据。服务器子系统还包括通知服务器(220)，并且服务器应用还可进行操作以响应于检测到在服务器应用与客户机应用之间当前尚未建立安全连接时发生了事件而生成一通知，并将该通知发送给通知服务器(220)。通知服务器(220)还可进行操作以在互连网络上将通知转发给客户机应用。
文档编号H04L29/06GK1939035SQ200580010782
公开日2007年3月28日 申请日期2005年3月23日 优先权日2004年3月31日
发明者大卫·罗克斯巴勒, 西蒙·亚历山大·贝德斯, 帕特里克·布赖恩·法利, 迈克尔·罗伯特·霍斯金 申请人:英国电讯有限公司