本申请要求2014年11月25日递交的发明名称为“处理通知信道断连的方法(MethodofHandlingNotificationChannelDisconnection)”的第14/553,545号美国非临时专利申请案的在先申请优先权，该在先申请的内容以引入的方式并入本文本中。
背景技术：
：：表征状态转移(representationalstatetransfer，REST)是万维网架构的一种抽象。更准确地说，REST是一种架构风格，其包括应用到分布式超媒体系统内的组件、连接器和数据元的一组协调的架构约束。REST忽略组件实施和协议语法的细节，以便专注于组件的作用、对这些组件与其它组件的交互的约束、这些组件对重要数据元的解释。REST架构风格可作为简单对象访问协议(SimpleObjectAccessprotocol，SOAP)等其它分布式计算规范的备选应用于网络服务开发。如果网络服务遵从涉及或关于客户端—服务器模型、无状态协议、网络缓存、分层系统、按需代码(可选)和统一接口的某些架构约束，则可以将这些网络服务描述为“RESTful”。在一些情况下，REST架构风格可应用于网络应用编程接口(applicationprogramminginterface，API)。遵守架构约束的网络API称为RESTful。技术实现要素：在一项实施例中，本发明包括一种处理通知信道断连的方法，所述方法包括：检测与REST客户端对应的通知信道的断连，向应用服务器发送表明所述通知信道断连的断连请求，以及从所述应用服务器接收表明所述REST客户端的订阅已删除的响应。在另一项实施例中，本发明包括一种处理通知信道断连的方法，所述方法包括：从通知服务器接收表明所述通知服务器与REST客户端之间的通知信道断连的断连请求，以及向所述通知服务器发送表明所述REST客户端的订阅已删除的响应。在又一项实施例中，本发明包括一种通知服务器，所述通知服务器包括可操作地耦合到存储器的处理器，以及存储在所述存储器中的通知信道断连模块，所述通知信道断连模块在由所述处理器执行时用于：检测与REST客户端对应的通知信道断连，向应用服务器发送表明所述通知信道断连的断连请求，以及从所述应用服务器接收表明所述REST客户端的订阅已删除的响应。结合附图和权利要求书可以从以下的详细描述中更清楚地理解这些和其它特征。附图说明为了更透彻地理解本发明，现参阅结合附图和具体实施方式而描述的以下简要说明，其中的相同参考标号表示相同部分。图1为在RESTful环境中创建和删除通知信道和订阅的方法的协议图。图2为通知信道断连方法的一实施例的协议图。图3为能够促进图3的方法的计算设备的一实施例的示意图。图4为处理通知信道断连的方法的一实施例的流程图。图5为处理通知信道断连的方法的一实施例的流程图。具体实施方式首先应理解，尽管下文提供一项或多项实施例的说明性实施方案，但所公开的系统和/或方法可使用任何数目的技术来实施，无论该技术是当前已知还是现有的。本发明决不应限于下文所说明的说明性实施方案、附图和技术，包括本文所说明并描述的示例性设计和实施方案，而是可在所附权利要求书的范围以及其等效物的完整范围内修改。本文公开了处理通知信道断连的各种实施例。如将在下文更充分说明的一样，本文公开的系统和方法允许通知服务器在通知信道已断连时通知应用服务器。因为应用服务器的通知信道当前状态保持最新，所以在通知信道断连时，与通知信道绑定的任何订阅均可由应用服务器删除。图1为在RESTful环境中创建和删除通知信道和订阅的方法100的协议图。在2013年7月30日发布的“通知信道的RESTful网络API，候选版本1.0(RESTfulNetworkAPIforNotificationChannel,CandidateVersion1.0)”规范中更详细地描述了使用REST架构和API创建、删除和使用通知信道，该规范的全部内容以引入的方式并入本文本中。图1的方法100在计算设备的上下文中说明，为方便起见，计算设备在本文中将称为客户端102、通知服务器104、API服务器106和核心服务器108。客户端102可为个人计算机(personalcomputer，PC)、移动设备(例如智能手机、平板电脑等等)。每个客户端102包括用于处理网络应用的一个或多个API。举例来说，网络应用可以是用于进行视频通话的网络应用(例如MicrosoftSkypeTM)或者用于促进客户端102之间的通信的网络应用。每个客户端102包括一个浏览器(例如MozillaGoogleMicrosoftInternet或Apple)。如本领域公知的一样，浏览器是一种用于在万维网上获取、提供和遍历信息资源的软件应用。一些网络浏览器利用一种称为网页实时通信(webreal-timecommunications，WebRTC)的技术。WebRTC是一种由万维网联盟(WorldwideWebConsortium，W3C)起草的API，该API支持浏览器到浏览器应用以进行视频通话、视频聊天、端对端(peer-to-peer，P2P)文件共享等，无需浏览器中的插件。如果客户端102的浏览器包括对WebRTC的支持时，则客户端102可参与浏览器到浏览器通信，无需插件。如图1所示，客户端102用于与通知服务器104和API服务器106进行通信。在一项实施例中，API服务器106是融合通信套件(RichCommunicationSuite，RCS)API服务器。在一些实施例中，通知服务器104和API服务器106之一是或者两者都是WebRTC用户网络接口(usernetworkinterface，UNI)服务器。API服务器106用于与核心服务器108进行通信。在一项实施例中，核心服务器108是互联网协议(InternetProtocol，IP)多媒体子系统或IP多媒体核心网子系统(IPMultimediaCoreNetworkSubsystem，IMS)。如图1所示，当(例如，运行应用的)客户端102向通知服务器104发送通知信道请求时，通知信道开始创建。在一些实施例中，该通知信道请求的格式是超文本传输协议(HypertextTransferProtocol，HTTP)。例如，可使用如2014年2月6日发布的Internet工程任务组(InternetEngineeringTaskForce，IETF)文件，超文本传输协议(HTTP/1.1)：语义与内容，draft-ietf-httpbis-p2-semantics-26，以及2014年6月发布的请求注解(RequestforComments，RFC)文件，超文本传输协议(HTTP/1.1)：语义与内容，RFC7231中描述的HTTPPOST操作来实施通知信道请求，这两个文件的全部内容以引入的方式并入本文本中。在接收到通知信道请求时，通知服务器104创建通知信道。然后，通知服务器104向客户端102发回响应以告知客户端102通知信道已建立。在一些实施例中，返回给客户端102的响应包括信道信息，诸如信道数据、回调统一资源定位符(uniformresourcelocator，URL)和信道URL。然后，客户端102向API服务器106发送订阅请求。订阅请求可以是例如聊天通知订阅、文件传输通知订阅等等。订阅请求包括例如回调URL。在一些实施例中，订阅请求的格式是HTTP。例如，可使用HTTPPOST操作来实施订阅请求。在接收到订阅请求时，API服务器106创建订阅。然后，API服务器106向客户端102返回响应以告知客户端102订阅已建立。返回给客户端102的响应可包括资源URL。在一些实施例中，客户端102和通知服务器104用于利用HTTP长轮询(例如，长轮询协议)，使得在客户端102与通知服务器104之间存在“心跳”。换言之，通知服务器104与客户端102之间存在连续双向通信。在一些实施例中，建立其它双向通信，例如基于同步HTTP的双向流(Bidirectional-streamsOverSynchronousHTTP，BOSH)、异步JavaScript+可扩展标记语言(ExtensibleMarkupLanguage，XML)(asynchronousJavaScript+XML，AJAX)，等等。为了启动长轮询过程，客户端102向通知服务器104发送长轮询请求。该长轮询请求包括例如信道URL。在一些实施例中，长轮询请求的格式是HTTP。例如，可使用HTTPPOST操作来实施长轮询请求。在接收到长轮询请求时，通知服务器104向客户端102发回响应以告知客户端102长轮询已建立。客户端102发起新的长轮询请求以便获得后续事件。如果例如长轮询请求在一个完整响应被发送到客户端102之前超时，则通知服务器104可向客户端102发回超时响应。这种情况可能在例如通知服务器104花太长时间来响应来自客户端102的信息或数据请求时发生。在接收到超时响应后，客户端102可立即进行另一个长轮询请求以保持客户端102与通知服务器104之间的通信是激活的或开启的。仍然参见图1，当API服务器106从核心服务器108接收事件通知时，API服务器106向通知服务器104发送该事件通知。当通知服务器104从客户端102接收下一长轮询请求时，通知服务器104在发往客户端102的长轮询响应中包括事件信息。例如，通知服务器通过该响应向客户端102发送包括事件的通知列表。当客户端102需要删除通知信道时，该客户端向通知服务器发送删除通知信道请求。在一些实施例中，删除通知信道请求的格式是HTTP。例如，可使用2014年2月6日发布的IETF文件，超文本传输协议(HTTP/1.1)：语义与内容，draft-ietf-httpbis-p2-semantics-26，以及2014年6月发布的RFC文件，超文本传输协议(HTTP/1.1)：语义与内容，RFC7231中描述的HTTPDELETE操作来实施删除通知信道请求，这两个文件的全部内容以引入的方式并入本文本中。在接收到删除通知信道请求时，通知服务器104删除通知信道。然后，通知服务器104向客户端102发回响应以告知客户端102通知信道已删除。然后，客户端102向API服务器106发送订阅删除请求。在一些实施例中，订阅删除请求的格式是HTTP。例如，可使用HTTPDELETE操作来实施订阅删除请求。在接收到订阅删除请求时，API服务器106删除订阅。然后，API服务器106向客户端102返回响应以告知客户端102订阅已删除。但是，上述创建和删除通知信道和订阅的过程没有定义任何在通知信道断连时的处理。事实上，通知服务器104检测到通知服务器104与客户端102之间的通知信道已中断，通知服务器104无法通知API服务器106。因此，API服务器106无法删除订阅。图2为解决前述问题的通知信道断连方法200的一实施例的协议图。方法200在通知信道临时或永久断连或者中断时使用。方法200使用(例如，运行应用的)客户端202、通知服务器204和API服务器206实施。在一些实施例中，客户端202、通知服务器204和API服务器206与图1中的客户端102、通知服务器104和API服务器106类似配置。图2所示的创建通知信道、请求订阅和在客户端202与通知服务器204之间建立长轮询的过程与结合图1描述的那些过程相似或相同。为简单起见，本文有意不重复这些过程的完整描述。在客户端202与通知服务器204之间的长轮询已建立后，如图2所示，通知信道可能非期望地断连。如果发生这种情况，客户端202向通知服务器204发送的任何长轮询通信都将失败，如图2中轮询请求上的“X”所示。通知服务器204能够检测到通知信道的故障或断连。在一些实施例中，通知服务器204在长轮询过程的“心跳”不再能感觉到或已停止时，确定通知信道已发生故障。在一些实施例中，如果通知服务器204在预定时间内没有从客户端202接收到通信，则确定通知信道断连。在已检测到通知信道断连时，通知服务器204向API服务器206发送断连请求。该请求向API服务器206表明客户端202与通知服务器204之间的通知信道断连。在一些实施例中，断连请求包括回调URL和在客户端202上运行的应用的用户标识(例如，用户ID)。在一些实施例中，断连请求的格式是HTTP。例如，可使用HTTPPOST操作来实施断连请求。在接收到断连请求时，API服务器206删除与客户端202对应的订阅。例如，API服务器206根据从通知服务器204接收的用户ID和回调URL删除订阅。然后，API服务器206向通知服务器204发回响应。该响应表明关于客户端202的订阅(例如，与用户ID和/或回调URL对应的订阅)已删除。通过在客户端202与通知服务器204之间的通知信道已断连时删除客户端202的订阅，避免了服务通知的无效订阅。换言之，去除了无效资源。图3为用于通过图1至图2所示的系统的至少一部分发送和接收消息或信息的服务器300的一实施例的示意图。本发明中描述的至少一些特征/方法可在服务器300中实施。例如，本发明的特征/方法可在硬件、固件和/或安装以运行于该硬件上的软件中实施。服务器300可为通过网络、系统和/或域传输数据的任意设备。此外，术语服务器、计算机、逻辑设备和/或类似术语可互换地使用以概括性地描述服务器并且没有特定或特殊意义，除非本发明内另有特殊说明和/或要求。在一项实施例中，服务器300可为用于参与图2所示的通知信道断连处理的装置。另外，服务器300的组件或功能可实施和/或集成在如图1至图2所描述和示出的客户端202、通知服务器204、API服务器206或核心网108中的设备中。服务器300可包括耦合到收发器(transceiver，Tx/Rx)320的一个或多个下游端口310，收发器320可以是发射器、接收器或其组合。Tx/Rx320可通过下游端口310传输和/或接收来自其它网络设备(例如服务器等)的消息或信息。类似地，服务器300可包括耦合到多个上游端口340的另一Tx/Rx320，其中Tx/Rx320可通过上游端口340传输和/或接收来自其它网络设备的消息或信息。下游端口310和/或上游端口340可包括电和/或光传输和/或接收组件。处理器330可耦合到Tx/Rx320，并可用于处理消息或信息和/或确定向哪些服务器发送(例如传输)消息或信息。在一实施例中，处理器330可包括一个或多个多核处理器和/或存储器模块350，其可用作数据存储器、缓冲器等。处理器330可实施为通用处理器或可为一个或多个专用集成电路(applicationspecificintegratedcircuit，ASIC)、现场可编程门阵列(field-programmablegatearray，FPGA)和/或数字信号处理器(digitalsignalprocessor，DSP)的一部分。尽管示为单个处理器，但处理器330不限于此并可包括多个处理器。处理器330可用于本文所述的媒体资源的自适应且动态的分配。图3示出了存储器350可耦合至处理器330并且可以是用于存储各种类型的数据的非瞬时性介质。存储器350可包括存储器设备，包括辅助存储器、只读存储器(read-onlymemory，ROM)和随机存取存储器(random-accessmemory，RAM)。辅助存储器通常包括一个或多个磁盘驱动器、光驱、固态驱动器(solid-statedrives，SSD)和/或磁带驱动器，并且用于数据的非易失性存储，而且如果RAM的容量不足以存储所有工作数据，辅助存储器则用作溢流数据存储设备。辅助存储器可用于当加载到RAM中程序被选择执行时存储这类程序。ROM用于存储指令，可能还存储在程序执行期间读取的数据。ROM是非易失性存储器设备，通常具有相对于辅助存储器的大存储容量来说较小的内存容量。RAM用于存储以易失性数据，可能还存储指令。访问ROM和RAM通常都快于访问辅助存储器。存储器350可用于存储用于执行本文所描述的各种示例实施例的指令。在一项实施例中，存储器350可包括模块360。在一实施例中，模块360代表设置在图2所示的通知服务器204和/或API服务器206内的通知信道断连模块。模块360能够实施通知信道断连过程并允许通知服务器204与API服务器206交换消息。换言之，模块360允许通知服务器204与API服务器206就客户端202与通知服务器204之间的通知信道的断连等进行相互通信。应理解，通过将可执行指令编程和/或加载到服务器300上，处理器330、缓存和长期存储器中的至少一个被改变，从而将服务器300的一部分转换成特定机器或装置，例如本发明宣扬的拥有新颖功能的多核转发架构。加载可执行软件至计算机所实现的功能可以通过现有技术中公知的设计规则转换成硬件实施，这在电力工程和软件工程领域是很基础的。决定使用软件还是硬件来实施一个概念通常取决于对设计稳定性及待生产的单元数量的考虑，而不是从软件领域转换至硬件领域中所涉及的任何问题。通常，仍然频繁改变的设计可优先在软件中实施，因为重新编写硬件实施方式比重新编写软件设计更为昂贵。通常，稳定及大规模生产的设计更适于在软件中(例如，在ASIC中)实施，因为运行硬件实施的大规模生产比软件实施更为便宜。设计通常可以以软件形式进行开发和测试，之后通过现有技术中公知的设计规则转变成ASIC中等同的硬件实施，该ASIC硬线软件指令。由新的ASIC控制的机器是一种特定机器或装置，同样地，编程和/或加载有可执行指令的计算机可视为特定机器或装置。本发明的任何处理可以通过使处理器(例如，通用多核处理器)执行计算机程序来实施。在这种情况下，可以使用任何类型的非瞬时性计算机可读介质向计算机或网络设备提供计算机程序产品。计算机程序产品可存储在计算机或网络设备中的非瞬时性计算机可读介质中。非瞬时性计算机可读介质包括任何类型的有形存储介质。非瞬时性计算机可读介质的示例包括磁性存储介质(例如，软盘、磁盘、硬盘驱动器等)、光磁存储介质(例如，磁光盘)、只读光盘(compactdiscread-onlymemory，CD-ROM)、可录光碟(compactdiscrecordable，CD-R)、带读写式光驱(compactdiscrewritable，CD-R/W)、数字多功能光盘(digitalversatiledisc，DVD)、蓝(注册商标)光(Blu-raydisc，BD)，以及半导体存储器(例如，掩蔽ROM、可编程ROM(programmableROM，PROM)、可擦除PROM、快闪ROM，以及RAM)。还可以使用任何类型的瞬时性计算机可读介质向计算机或网络设备提供计算机程序产品。瞬时性计算机可读介质的示例包括电信号、光信号和电磁波。瞬时性计算机可读介质可以经由有线通信线路(例如，电线或光纤)或无线通信线路将程序提供给计算机。在一示例实施例中，通知服务器用于处理通知信道断连。通知服务器包括：检测模块，检测与表征状态转移(representationalstatetransfer，REST)客户端对应的通知信道的断连；断连模块，向应用服务器发送表明通知信道断连的断连请求；以及接收模块，从应用服务器接收表明REST客户端的订阅已删除的响应。在一些实施例中，通知服务器可包括用于执行实施例中描述的任一步骤或步骤组合的其它或附加模块。在一示例实施例中，应用服务器用于处理通知信道断连。应用服务器包括：接收模块，从通知服务器接收表明通知服务器与表征状态转移(representationalstatetransfer，REST)客户端之间的通知信道断连的断连请求；以及响应模块，向通知服务器发送表明REST客户端的订阅已删除的响应。在一些实施例中，应用服务器可包括用于执行实施例中描述的任一步骤或步骤组合的其它或附加模块。图4为处理通知信道断连的方法400的实施例的流程图。在一实施例中，用于执行方法400的指令存储在通知信道断连模块360中，方法400使用处理器330来实施。方法400在客户端202与通知服务器204之间的通知信道断连时实施，以通知API服务器206，客户端202与通知服务器204之间的通知信道断连，因此可以删除有关客户端202的订阅。在方框402中，检测到与REST客户端对应的通知信道的断连。在一实施例中，图2的通知服务器204能够检测到通知信道的故障或断连。在一些实施例中，通知服务器204在长轮询过程的“心跳”不再能感觉到或已停止时，确定通知信道已发生故障。在一些实施例中，如果通知服务器204在预定时间内没有从客户端202接收到通信，则确定通知信道断连。在方框404中，向应用服务器发送表明通知信道断连的断连请求。在一实施例中，在已检测到通知信道断连时，图2的通知服务器204向API服务器206发送断连请求。该请求向API服务器206表明客户端202与通知服务器204之间的通知信道断连。在一些实施例中，断连请求包括回调URL和在客户端202上运行的应用的用户标识(例如，用户ID)。在一些实施例中，断连请求的格式是HTTP。例如，可使用HTTPPOST操作来实施断连请求。在方框406中，从应用服务器接收表明REST客户端的订阅已删除的响应。在一实施例中，在接收到断连请求时，图2的API服务器206删除与客户端202对应的订阅。例如，API服务器206根据从通知服务器204接收的用户ID和回调URL删除订阅。然后，API服务器206向通知服务器204发回响应。在一实施例中，该响应表明关于客户端202的订阅(例如，与用户ID和/或回调URL对应的订阅)已删除。通过在客户端202与通知服务器204之间的通知信道已断连时删除客户端202的订阅，避免了服务通知的无效订阅。换言之，去除了无效资源。图5为处理通知信道断连的方法500的一实施例的流程图。在一实施例中，用于执行方法500的指令存储在通知信道断连模块360中，方法500使用处理器330来实施。方法500在客户端202与通知服务器204之间的通知信道断连时实施，以通知API服务器206，客户端202与通知服务器204之间的通知信道断连，因此可以删除有关客户端202的订阅。在方框502中，从通知服务器接收表明通知服务器与REST客户端之间的通知信道断连的断连请求。在一实施例中，图2的通知服务器204能够检测到通知信道的故障或断连。在一些实施例中，通知服务器204在长轮询过程的“心跳”不再能感觉到或已停止时，确定通知信道已发生故障。在一些实施例中，如果通知服务器204在预定时间内没有从客户端202接收到通信，则确定通知信道断连。在一实施例中，在已检测到通知信道断连时，图2的通知服务器204向API服务器206发送断连请求。该请求向API服务器206表明客户端202与通知服务器204之间的通知信道断连。在一些实施例中，断连请求包括回调URL和在客户端202上运行的应用的用户标识(例如，用户ID)。在一些实施例中，断连请求的格式是HTTP。例如，可使用HTTPPOST操作来实施断连请求。在方框504中，向通知服务器发送表明REST客户端的订阅已删除的响应。在一实施例中，在接收到断连请求时，图2的API服务器206删除与客户端202对应的订阅。例如，API服务器206根据从通知服务器204接收的用户ID和回调URL删除订阅。然后，API服务器206向通知服务器204发回响应。在一实施例中，该响应表明关于客户端202的订阅(例如，与用户ID和/或回调URL对应的订阅)已删除。通过在客户端202与通知服务器204之间的通知信道已断连时删除客户端202的订阅，避免了服务通知的无效订阅。换言之，去除了无效资源。虽然本发明中已提供若干实施例，但应理解，在不脱离本发明的精神或范围的情况下，本发明所公开的系统和方法可以以许多其它特定形式来体现。本发明的实例应被视为说明性而非限制性的，且本发明并不限于本文本所给出的细节。例如，各种元件或部件可以在另一系统中组合或合并，或者某些特征可以省略或不实施。此外，在不脱离本发明的范围的情况下，各种实施例中描述和说明为离散或单独的技术、系统、子系统和方法可以与其它系统、模块、技术或方法进行组合或合并。展示或论述为彼此耦合或直接耦合或通信的其它项也可以采用电方式、机械方式或其它方式通过某一接口、设备或中间部件间接地耦合或通信。其它变化、替代和改变的示例可以由本领域的技术人员在不脱离本文精神和所公开的范围的情况下确定。在一示例实施例中，通知服务器用于处理通知信道断连。通知服务器包括：检测模块，检测与表征状态转移(representationalstatetransfer，REST)客户端对应的通知信道的断连；断连模块，向应用服务器发送表明通知信道断连的断连请求；以及接收模块，从应用服务器接收表明REST客户端的订阅已删除的响应。在一些实施例中，通知服务器可包括用于执行实施例中描述的任一步骤或步骤组合的其它或附加模块。在一示例实施例中，应用服务器用于处理通知信道断连。应用服务器包括：接收模块，从通知服务器接收表明通知服务器与表征状态转移(representationalstatetransfer，REST)客户端之间的通知信道断连的断连请求；以及响应模块，向通知服务器发送表明REST客户端的订阅已删除的响应。在一些实施例中，应用服务器可包括用于执行实施例中描述的任一步骤或步骤组合的其它或附加模块。当前第1页1 2 3 当前第1页1 2 3