对通信档案进行协调和补救的制作方法

专利名称：对通信档案进行协调和补救的制作方法
对通信档案进行协调和补救背景电子邮件(e-mail)提供了用于端对端消息传递的存储并转发方法，这种方法允 许消息跨越多个机器、通过各种组织和网络传播，并幸免于暂时连接中断。这一异步方法的 不利之处在于，发送用户或组织没有办法真正知道接收者是否以及何时接收到消息以及是 否已经成功完成任何接收后处理。在电子邮件档案的情况中，这一问题尤其普遍。经受由于遵守规章制度和法院指 令而带来的电子邮件保留要求的企业和组织需要能够从这样的档案搜索和产生电子邮件。 不能这样做的话，会导致大笔罚金和声誉损害。由于当前的电子邮件系统不能保证被发送 给档案的消息已经被成功地保存在档案中，这些企业蒙受除了在他们的档案中进行搜索之 外还不得不在冗余备份中进行搜索的大量成本。从消息生成电子邮件系统的观点来看，沿着到档案的通道上存在若干潜在的数据 丢失点。例如，生成电子邮件系统或中介电子邮件系统会遭受软件或硬件故障，且丢失去往 档案的消息。另外，其中接收到消息的档案的前端电子邮件系统或其中消息被保存到数据 库的档案注入系统会遭受软件或硬件故障，且丢失去往档案的消息。因此，需要进行改进以 便解决这些问题和其他问题，并保证在没有事务处理的环境中消息的端对端传递和归档。概述提供本概述以便以简化形式介绍将在以下详细描述中进一步描述的一些概念。本 发明内容并不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于限定所 要求保护的主题的范围。各实施例涉及用于协调和补救由服务器发送以供存储在档案中的消息的技术。一 些技术可以包括接收对应于由服务器发送给档案以供存储的消息的要协调的消息、对所接 收的要协调的消息进行分类、根据要协调的消息的分类来向档案发出传递确认查询、以及 基于对传递确认查询的响应来确定从服务器发送给档案的消息是否被存储在档案中。在接 收到对传递确认查询的否定响应之后，可以发出重试查询。在接收到对重试查询的否定响 应之后，可将要协调的消息重新提交给档案。可以存储要协调的消息直到接收到确认，且在 接收到对传递确认查询的肯定响应之后删除该消息。描述并要求保护其他实施例。通过阅读下面的“详细描述”并参考相关联的图形，这些及其他特点和优点将变得 显而易见。应该理解，前面的一般性的说明和下面的详细描述只是说明性的，不会对如权利 要求所述的方面形成限制。附图简述

图1示出操作环境的实施例。图2示出计算设备的实施例。图3示出协调应用程序的实施例。图4示出图的实施例。图5示出消息流的实施例。图6示出逻辑流程的实施例。
图7示出制品的实施例。详细描述各实施例包括被配置为执行某些操作、功能或服务的物理或逻辑结构。结构可以 包括物理结构、逻辑结构或两者的组合。物理或逻辑结构是使用硬件元素、软件元素或两者 的组合来实现的。然而，参考特定硬件或软件元素对实施例的描述只作为示例而非限制。 使用硬件或软件元素以实际实践实施例的决定取决于若干个外部因素，如所希望的计算速 率、功率水平、耐热性、处理周期预算、输入数据速率、输出数据速率、存储器资源、数据总线 速度，及其他设计或性能约束。此外，物理或逻辑结构还可以具有对应的物理或逻辑连接， 以便以电子信号或消息的形式在各结构之间传达信息。连接可以包括对于信息或特定结构 适合的有线和/或无线连接。值得注意的是，任何对“一个实施例”或“一实施例”的引用 都意味着结合该实施例所描述的特定的特征、结构、或特性被包括在至少一个实施例中。出 现在说明书中各个地方的短语“在一个实施例中”不必全都指的是同一实施例。提供用于协调和补救由服务器发送以供存储在档案中的消息的各种技术。一些技 术可以包括接收对应于由服务器发送以供存储在档案中的消息的要协调的消息。可以对所 接收的要协调的消息进行分类，且可以根据要协调的消息的分类来向档案发出传递确认查 询。基于对传递确认查询的响应，可以肯定地确定被发送给档案以供存储的消息是否确实 被存储在该档案中。另外地或另选地，在接收到对传递确认查询的否定响应之后，可以发出 重试查询。如果接收到对重试查询的否定响应，可将要协调的消息重新提交给档案。可以 存储要协调的消息直到接收到确认，且仅在接收到对传递确认查询的肯定响应之后删除该 消息，以保证消息的可用性。图1示出了适于实施各实施例的操作环境100的框图。操作环境100可以包括为 通过单个实体环境或多个实体分布式环境的实现而设计的元素。根据对于给定一组设计参 数或性能约束的需要，每一元素都可以实现为硬件元素、软件元素或其任何组合。硬件元素 的示例可包括器件、组件、处理器、微处理器、电路、电路元件(例如，晶体管、电阻器、电容 器、感应器等等)、集成电路、专用集成电路(ASIC)、可编程逻辑器件(PLD)、数字信号处理 器(DSP)、现场可编程门阵列(FPGA)、存储器单元、逻辑门、寄存器、半导体器件、芯片、微芯 片、芯片集等等。软件元素的示例可包括任何软件元素组件、程序、应用、计算机程序、应用 程序、系统程序、机器程序、操作系统软件、中间件、固件、软件模块、例程、子例程、函数、方 法、接口、软件接口、应用程序接口(API)、指令集、计算代码、计算机代码、代码段、计算机代 码段、文字、值、符号，或其任何组合。 如此处所使用的，术语“系统”、“子系统”、“组件，，和“模块，，旨在指示计算机相关 的实体，包括硬件、硬件和软件的组合、软件、或执行中的软件。例如，组件可被实现为在处 理器上运行的进程、处理器、硬盘驱动器、多个存储驱动器(光学和/或磁存储介质)、对象、 可执行程序、执行的线程、程序，和/或计算机。作为说明，在服务器上运行的应用程序和服 务器两者都可以是组件。根据给定实现的需要，一个或多个组件可以驻留在进程和/或执 行的线程内，组件可以被局部化在一台计算机上和/或分布在两个或更多计算机之间。在 此上下文中，实施例不受限制。 在图1中所示出的示例中，操作环境100可以包括电子邮件服务器110和档案140 以及其他元件。尽管在图1中示出的操作环境100具有以某种拓扑结构的有限数量的节点，但应明白，根据给定实现的需要，操作环境100可以包括以替换拓扑结构的更多或更少 的节点。在各实施例中，可以在电子邮件消息收发系统中实现电子邮件服务器110，以便通 过电子通信系统发送和接收消息。档案140可以被实现为用于归档通过电子通信系统从电 子邮件消息收发系统接收到的消息的现场或场外归档系统或数据存储设施。如图所示，电 子邮件服务器110和档案140可以经由网络118和适当的无线或有线通信介质在通信上耦 合。电子邮件服务器110和档案140可以通过网络118传递信息且在相互之间协调操作， 这可以涉及信息的单向交换和双向交换。网络118可以包括分组交换网络、电路交换网络 或两者的组合。通过网络118传递的信息可以被实现为跨各种网络接口发送的数据消息。 示例性网络接口包括并行接口、串行接口和总线接口。电子邮件服务器110可用于与各种类型的消息收发客户机通信。在一些实现中， 电子邮件服务器110可以提供用于与基于客户机的软件程序进行通信的接口，基于客户机 的软件程序例如来自华盛顿州雷蒙德市的微软公司的MICROSOFT OFFICE OUTLOOK . 应用 程序软件。电子邮件服务器110还可以提供用于与各种其他类型的电子邮件客户机进行通 信的接口，各种其他类型的电子邮件客户机包括但不限于简单邮件传输协议(SMTP)客户 机、超文本传输协议(HTTP)客户机、消息收发应用程序编程接口(MAPI)客户机、邮局协议 3 (P0P3)客户机、因特网消息访问协议(IMAP或IMAP4)客户机、网络新闻传输协议(NNTP) 客户机、webmail客户机等等。电子邮件服务器110可以用来提供web访问、移动访问和同步功能、因特网信息 服务(IIS)和因特网服务器应用程序编程接口(ISAPI)应用程序，因特网服务器应用程 序编程接口(ISAPI)应用程序提供SMTP、NNTP, IMAP4和P0P3服务，以允许在多种因特网 访问协议和基于HTTP的协议上进行通信，基于HTTP的协议包括在HTTP通信上的远程过 程调用(RPC)。在一些实现中，电子邮件服务器110可以传送被格式化为压缩无线二进制 XML(WbXML)数据的数据，以充分利用移动客户机的带宽。当由公司或其他组织使用时，除了 标准网际协议之外，电子邮件服务器110还可以支持在专有或非标准协议上进行通信。在各种实现中，根据所描述的实施例，电子邮件服务器110和/或档案140可以执 行一种或多种协调和补救技术。在一些实施例中，电子邮件服务器110可以包括实现基于 服务器的电子邮件软件程序的服务器计算设备。因此，在一些实施例中，一种或多种协调和 补救技术可以被实现为基于服务器的软件程序内的特征，基于服务器的软件程序例如来自 华盛顿州雷蒙德市的微软公司的MICROSOFT EXCHANGE SERVER 。应明白，各实施例在该上 下文中受限，且电子邮件服务器110可以实现包括提供经由web浏览器的对电子邮件服务 的访问的基于web的电子邮件应用程序在内的其他类型的应用程序、程序或服务。在一些实施例中，档案140可以包括实现一个或多个服务器应用程序和/或web 服务的服务器计算设备。档案140可以实现使用平台和语言无关格式的各种web服务， 这些格式被设计成使用诸如超文本传输协议(HTTP)、安全套接字层上的超文本传输协议 (HTTPQ、简单邮件传输协议(SMTP)、文件传输协议(FTP)等通信协议来通过诸如因特网等 网络进行通信。因此，在一些实施例中，一种或多种协调和补救技术可以被实现为服务器应 用程序和/或web服务内的特征。应明白，各实施例在该上下文中不受限，且档案140可以 由其他类型的现场或场外归档系统和/或或数据存储设施来实现。—般地，根据所描述的实施例，电子邮件服务器110和档案140都可以包括具有计算能力和通信能力的任何合适类型的计算设备或由这样的计算设备实现。为实现这样的能 力，电子邮件服务器110和档案140可以包括各自的计算系统120、120a和通信系统130、 130a。计算系统120，120a可包括各种计算元件，诸如一个或多个处理器、协处理器、存储器 单元、芯片集、控制器、外围设备、接口、振荡器、定时设备、视频卡、音频卡、多媒体输入/输 出(I/O)组件等等。通信系统130，130a可包括各种通信元件，如发射机、接收机、收发机、 无线电、网络接口、基带处理器、天线、放大器、滤波器等等。计算系统120、120a可以实现各自的服务器程序122、142以及其他元件。根据所描 述的实施例，服务器程序122、142和它们所包括的元件可以包括支持电子邮件服务器110 和档案140的操作的一种或多种类型的应用程序、软件组件、程序模块和/或程序数据或由 其实现。在一些实现中，服务器程序122可以在一个物理服务器计算机设备上实现。或者， 各种服务器程序122可以跨越可能位于不同的域和站点以满足地理部署要求和/或在支持 大量用户时提供性能和容错的多个服务器而实现。在图1中所示出的示例中，服务器程序122可以实现一个或多个服务器角色，这些 服务器角色包括例如用来提供用于电子邮件服务器110的特定服务和特征的中枢传输服 务器角色1 和邮箱服务器角色126。中枢传输服务器角色IM可以用来处理传入消息和 传出消息，而邮箱服务器角色1 可以用于主存邮箱和公共文件夹数据。如图所示，中枢传 输服务器角色1 可以包括日志记录代理125，而邮箱服务器角色1 可以包括协调代理 127。根据各实施例，日志记录代理125和协调代理127可以执行一种或多种协调和补救技 术，如下面更详细地描述的。根据所描述的实施例，服务器程序122还可以包括其他服务器 程序128，诸如其他服务器角色和/或其他类型的服务器应用程序。在图1所示的示例中，服务器程序142可以实现一个或多个服务器应用程序，包括 例如日志记录应用程序144和协调应用程序146，这些应用程序用来提供用于档案140的特 定服务和特征。根据各实施例，日志记录应用程序146和协调应用程序146可以与日志记 录代理125以及协调代理127进行通信，以便执行一种或多种协调和补救技术，如下面更详 细地描述的。根据所描述的实施例，服务器程序142还可以包括其他服务器程序148，诸如 其他类型的服务器应用程序和/或web服务。根据所描述的实施例，电子邮件服务器110和档案140可以包括用于将诸如电子 邮件消息和其他数据等项目存储在邮箱和文件夹中的各自的数据存储或与该数据存储进 行通信。参见图1，用于电子邮件服务器110的数据存储可以由电子邮件服务器数据库150 实现，而用于档案140的数据存储可以由档案数据库160实现。尽管出于说明的目的而被示 出为独立元件，但应明白，在一些实施例中，电子邮件服务器数据库150可以形成电子邮件 服务器110的一部分，和/或档案数据库160可以形式档案140的一部分。还应明白，用于 电子邮件服务器110和档案140的各自的数据存储可以与电子邮件服务器110和档案140 驻留在一起或驻留在其他远程设备中。图2提供了适于实施各实施例的计算设备200的说明性体系结构。计算设备200 可以表示例如电子邮件服务器110。如图所示，计算设备200示出了个人或服务器计算机的 常规计算体系结构，包括包含处理器202和系统存储器204的处理系统。系统存储器204 可包括，除其他类型的存储器之外，随机存取存储器(RAM) 206和只读存储器(ROM) 208。诸 如基本I/O系统(BIOS)之类的输入/输出(I/O)系统可以实现诸如在启动操作期间使用存储在ROM 208中的逻辑来帮助在计算设备200内的各元件之间传输信息的例程。系统总 线210可通信地耦合计算设备200的所有元件以促进信息传输和数据处理操作。计算设备200还可包括大容量存储设备212，该存储设备用于存储诸如来自华盛 顿州雷蒙德市的微软公司的MICROSOFT WINDOWS 操作系统或其他合适的操作系统等操作 系统214。大容量存储设备212还可存储如下文中更详细地描述的各种应用程序，以及其他 程序模块216和程序数据218。大容量存储设备212可以通过连接到系统总线210的大容量存储控制器(未示 出)连接到处理器202。大容量存储设备212以及其相关联的计算机可读介质，为计算设 备200提供非易失性存储器。虽然此处包含的计算机可读介质的描述引用了诸如硬盘或 CD-ROM驱动器之类的大容量存储设备，但是，本领域的技术人员应该了解，计算机可读介质 可以是可以被计算设备200访问的任何可用的介质。作为示例而非限制，计算机可读介质 可以包括计算机存储介质和通信介质。计算机存储介质包括以存储如计算机可读指令、数 据结构、程序模块或其他数据等信息的任何方法或技术来实现的易失性和非易失性、可移 动和不可移动介质。计算机存储介质包括，但不限于，RAM、R0M、EPR0M、EEPR0M、闪存或其它 固态存储器技术、CD-ROM、DVD或其它光学存储、磁带盒、磁带、磁盘存储或其它磁性存储设 备、或能用于存储所需信息且可以由计算机访问的任何其它介质。根据各实施例，计算设备200可以通过网络118，使用到远程计算机的逻辑连接在 联网环境中操作，在一些实现中，网络118可以是诸如因特网之类的传输控制协议(TCP)和 网际协议(IP)网络。计算设备200可以通过连接到系统总线210的网络接口 220(例如， 有线或无线网络接口)连接到网络118。可以理解，网络118可以包括根据所描述的实施例 的任何类型的网络，包括，但不仅限于，广域网(WAN)、局域网(LAN)，和/或蜂窝电话网络， 并且网络接口 220可以支持各种传输层，如GPRS、CDMA IxRTT, IEEE 802. 11、蓝牙 (PAN) 及用于连接到各种网络和/或远程计算机系统的其他。计算设备200可包括用于接收和处理来自多个输入设备224的输入的1/0控制器 222。用户可以通过诸如键盘和定点设备(如，鼠标、跟踪球或触摸板)之类的各种输入设 备224向计算设备200中输入命令和信息。输入设备2M的其他示例可包括话筒、游戏杆、 游戏手柄、圆盘式卫星天线、扫描仪等等。输入设备2M可以通过耦合到系统总线210的I/ 0控制器222连接到处理器202，但是，也可以通过诸如并行端口、游戏端口或通用串行总线 (USB)之类的其他接口和总线结构来进行连接。1/0控制器222也可以提供到诸如监视器 或经由1/0控制器222连接到系统总线210的其他类型的显示设备、打印机、扬声器和其他 外围设备之类的各种输出设备224的输出。如上文所提及的，许多程序模块和数据文件可以存储在计算设备200的大容量存 储设备212和RAM 206中。在图2所示的示例中，大容量存储设备212和RAM206可存储操 作系统214以及一个或多个服务器程序122，包括包含日志记录代理125的中枢传输服务器 角色IM和包含协调代理127的邮箱服务器角色126。根据各实施例，协调代理127可用于 执行一种或多种协调和补救技术。例如，在一个实施例中，协调代理127可以如参考图3所 描述的那样实现。图3示出适用于实践各实施例的协调应用程序300的一个实施例。参考图1和2， 在一些实现中，协调应用程序300可以用作作为驻留在电子邮件服务器110上的服务器程序122中的一个的协调代理127。电子邮件应用程序300的一个或多个部分还可以由计算 设备200的RAM 206或计算机软件领域中的技术人员想到的任何其他变体中的应用程序程
序实现。如图所示，电子邮件应用程序300可以包括消息存储310。尽管出于说明而非限制 的目的将消息存储310示为协调应用程序300的一部分，但应明白，根据所描述的实施例， 消息存储310可以驻留在各个位置中。例如，消息存储310可以驻留在电子邮件服务器110 和/或电子邮件服务器数据库150上。作为一个非限制性示例，协调应用程序300的消息 存储310可以以数据库和/或以一个或多个文件驻留在计算设备200的程序数据218内。 作为另一非限制性示例，消息存储310可以全部或部分驻留在由用户在诸如操作系统214 之类的操作系统的文件系统中指定的目录中。在图3所示的示例中，消息存储310包括一个或多个待协调消息，待协调消息可 以被分类为0代(Gen-O)消息312、1代(Gen-I)消息314、2代(Gen-2)消息316和3代 (Gen-3)消息318。在各实施例中，可以根据消息分类来发出查询。例如，可以基于协调代 来发出查询以便优化协调过程的性能并最小化对档案140的查询的数量。在一些实施例中，可以基于与档案140相关联的等待时间来将待协调消息分类为 Gen-O消息312。被协调应用程序300接收并被分类为Gen-O消息312的消息可以对应于 最近被发送给档案140的消息。根据各实施例，不为待决Gen-O消息312发出查询，且查询 延迟直到与档案14相关联的等待时间已经过去。对于在特定消息被协调应用程序300接收之后的短时间间隔，特定消息的副本可 以被本地存储在高速缓存320中并可从该高速缓存访问。在一些实施例中，基于可以从高 速缓存320本地获得特定消息的副本时的时间间隔，待协调消息可以被分类为Gen-I消息 314。被协调应用程序300接收并被分类为Gen-I消息314的消息可以对应于预期已经被 传递至档案140和/或由档案140处理的消息。另外，当可以从高速缓存320获得消息的 副本时，可以实现I/O节省。在各种实现中，为Gen-I消息314发送传递确认查询，且尝试 在高速缓存320的生存期内处理几乎所有消息。当接收到对关于特定消息的传递确认查询的肯定响应时，协调应用程序300确认 消息被归档且可以从消息存储310中删除消息。当协调应用程序300接收到关于特定消息 的否定响应时，在消息存储310中维护未经确认的消息以保证其可用性，直到可以确认该 消息被归档。在一些实施例中，可以基于确认此类消息的归档失败来对待协调消息进行分类。 当接收到对特定消息的否定响应时，协调应用程序300可以将消息分类为Gen-2消息316。 基于解决消息延迟所需要的时间，消息可以保持被分类为Gen-2消息316。被协调应用程序 300分类为Gen-2消息316的待决消息可以对应于经历延迟问题的未经确认的消息。根据 各实施例，不为Gen-2消息316发出查询并且延迟查询以允许解决邮件延迟。被协调应用程序300分类为Gen-3消息318的待决消息可以对应于具有现在可以 解决的延迟问题的未经确认的消息。协调应用程序300可以发出关于Gen-3消息218中的 一个或多个的重试查询。当接收到对特定消息的肯定响应时，协调应用程序300可以确认 先前未经确认的消息已经被归档且可以从消息存储310中删除该消息。当接收到对重试查 询的否定响应时，未经确认的消息保留在消息存储310中以保证其可用性，直到可以确认
9该消 息被归档。当不能确认一个或多个Gen-3消息218时，协调代理127可以通过将Gen-3消息 318重新提交给档案140来执行补救。未经确认的消息保留在消息存储310中以保证其可 用性，直到确认特定消息被归档。协调应用程序300可以将未经确认的Gen-3消息318重 新提交给档案140，且可以将每一未经确认的消息的副本保存在消息存储310中。在特定的 未经确认的消息被重新提交给档案140后，协调过程可以再次开始直到确认该特定消息被 归档。应明白，即使是在特定消息不能被协调时，消息也保留在消息存储310中以保证其可 用性。如图所示，电子邮件应用程序300可以包括负责执行在此所描述的协调和补救技 术中的部分或全部的协调和补救逻辑330。在图3所示的示例中，协调和补救逻辑330包括 用于接收要协调的消息的逻辑332、用于对待协调消息进行分类的逻辑334，用于发出档案 查询的逻辑336，用于确认已归档消息的逻辑338、用于删除经确认的消息的逻辑340以及 用于补救未经确认的消息的逻辑342。在一些实现中，协调和补救逻辑330可以作为电子邮件服务器110上的协调代理 127的一部分来驻留在协调应用程序300内。然而，应明白，根据所描述的实施例，协调和补 救逻辑330可以另选地或另外地被具体化为存储在各种位置中的一种或多种类型的计算 机可读存储介质上的计算机可执行指令。尽管图3所示的示例包括特定逻辑集，但应明白，协调和补救逻辑330提供一般功 能的示例性实现。可以理解，逻辑的序列不一定必须按呈现的顺序执行，除非另有陈述。此 夕卜，尽管协调和补救逻辑330可以被描述为执行特定步骤序列，但是，根据替换实施例，还 可执行其他步骤序列。此外，由协调和补救逻辑330所执行的某些个体步骤可包括多个子 步骤，这些子步骤可以对个体步骤合适的各种序列执行。此外，取决于特定实现，还可以执 行额外的步骤，或者某些步骤可以被协调和补救逻辑330省略。图4示出例示适用于实施各实施例的各代协调的图400的一个实施例。参考图 1-图3，在一些实现中，待协调消息可以被协调应用程序300分类成各代协调，协调应用程 序300又可以由驻留在电子邮件服务器110上的协调代理127实现。然而，各实施例不限 于这样的实现。此外，应明白，根据所描述的实施例，术语分类或代(和它们的派生词)可 以是指任何合适的技术或消息组。尽管当指代消息的分类或消息组时一些操作系统或应用 程序可以不使用术语分类或代，但这样场景旨在被所描述的实施例涵盖。如图所示，根据对应的时间间隔(T0-T3)，待协调消息可以被分类为0代(Gen-O)、 1代(Gen-I)、2代(Gen-2)和3代(Gen-3)消息。在此示例中，当与消息相关联的时间在时 间间隔TO内时，消息可以被分类为Gen-O消息，当该时间在时间间隔Tl内时，消息可以被 分类为Gen-I消息，当该时间在时间间隔Tl内时，消息可以被分类为Gen-2消息，当该时间 在T3期间时，消息可以被分类为Gen-3消息。尽管一些实施例可以描述与时间间隔相关联 的特定示例性值(T0-T3)，但应理解，可以使用其他合适的值。还应明白，根据所描述的实施 例，可以按其他方式对消息进行分类。在各个实现中，与特定消息相关联的时间可以对应于自从接收到包括该特定消息 在内的日志报告的副本以来过去的时间量。例如，与特定消息相关联的时间可以是协调代 理127接收到包含该特定消息的日志报告的副本的时间，和/或可以是该特定消息被存储在消息存储310中的时间。在其他实施例中，与该消息相关联的时间可以基于可以在曰志 报告的副本中提供的消息被发送给档案140的时间。在协调代理127接收到在日志报告的副本中的特定消息之后，需要较短时间间隔 来将原始的日志报告传递给档案140和/或由档案140处理该报告。因此，在一些实施例 中，可以基于诸如与档案140相关联的传递和/或处理等待时间等等待时间来对待协调消 息进行分类。在图4所示的示例中，当与消息相关联的时间是在时间间隔TO内时，消息可以被 分类为Gen-O消息。如图所示，时间间隔TO的长度可以对应于原始日志报告被传递给档案 140的预期水平协议(SLA)或等待时间(ASLA)。一般地，时间间隔Δ SLA将是相对较短的 时间段，例如约5秒。根据各实施例，时间间隔△ SLA可以基于被发送给档案140的消息的传 递和/或 处理等待时间。在一些实施例中，时间间隔Δ SLA可以是大多数日志报告被传递给档案140 所需要的假定的或观察到的时间量。时间间隔ASLA还可以由厂商SLA定义，该厂商SLA 指定档案140约定的服务水平和/或执行时间。在一些情况下，时间间隔Δ SLA可以基于 由档案140提供的信息。例如，在一些实现中，协调代理127可以查询档案140以获得某些 配置信息，诸如用于处理消息的预期SLA或等待时间。如图所示，时间间隔TO可以对应于Δ SLA且在Δ SLA过去后结束。在各种实现中， 在时间间隔TO期间，且直到ASLA从与该消息相关联的时间起已经过去，特定消息可以被 分类为Gen-O消息，该时间诸如包含特定消息的日志报告的副本被协调代理127接收的时 间和/或消息被存储在消息存储310中的时间。因此，被协调代理127接收到且被分类为 Gen-O的消息可以对应于最近被发送给档案140的消息。对于在特定消息被协调代理127接收到之后的较短时间间隔，要协调的消息的副 本可以被本地存储在高速缓存320中且从高速缓存320访问。因此，在一些实施例中，可以 基于此时间间隔或与高速缓存320相关联的高速缓存生存期(△高速缓存)来对待协调消 息进行分类。一般地，高速缓存生存期Δ高速缓存将是，且在某些情况下必须是比预期等 待时间Δ SLA长。在一些实施例中，高速缓存生存期Δ高速缓存可以是约10秒。高速缓存生存期Δ高速缓存一般将与系统上可用的RAM诸如RAM 206成正比地 变化。例如，在具有10分钟的高速缓存生存期△高速缓存的电子邮件服务器110上，高速 缓存生存期Δ高速缓存通常可以通过使RAM翻倍来翻倍。因此，Δ高速缓存时间间隔通 常比往往是大约5秒且相对难以改变的诸如时间间隔ASLA等其他时间间隔中的大多数易 变得多。由于其与RAM的线性关系，可以通过在运行协调代理127的服务器上添加RAM来 容易地增加高速缓存生存期△高速缓存。这允许高速缓存生存期△高速缓存在需要时宽 裕地超过SLA时间间隔并且产生I/O节省。在图4所示的示例中，当与消息相关联的时间在时间间隔Tl内时，消息可以被分 类为Gen-I消息。如图所示，时间间隔Tl的长度可以对应于Δ SLA期满之后且高速缓存生 存期△高速缓存期满之前的时间窗口。在各种实现中，在时间间隔Tl期间且直到自从与 消息相关联的时间起已经过去高速缓存生存期△高速缓存，特定消息可以被分类为Gen-I 消息，该与消息相关联的时间诸如当包含特定消息的日志报告的副本被协调代理127接收 和/或当该消息被存储在消息存储310中的时间。因此，被协调代理127接收且被分类为Gen-I的消息可以对应于预期已经被传递给档案140和/或由档案140处理的消息。在各实施例中，可以根据消息分类来发出查询。例如，可以基于协调世代来发出查询以优化协调过程的性能并最小化对档案140的查询的数量。被协调代理127接收并被分类为Gen-O的消息可以对应于最近被发送给档案140 的消息。根据各实施例，协调代理127不发出关于被分类为Gen-O的待决消息的查询。例 如，如果在八SLA已经过去之前将关于日志报告的部署的查询发送给档案140，则该查询将 很有可能得到否定响应(Nak)。因此，不为TO期间的Gen-O消息执行查询发出，且可以延迟 查询的发出直到Δ SLA期满。被协调代理127接收并被分类为Gen-I的消息对应于预期被存储在档案140中的 消息。另外，在可以从高速缓存320获得消息的副本时，可以实现I/O节省。然而，在高速缓 存生存期(△高速缓存)期满之后，消息的副本可以从高速缓存320里掉出，且I/O节省不 再可能。在各实施例中，发送关于分类为Gen-I的待决消息的初始查询。在这样的实施例 中，协调代理127可以在时间间隔Tl期间尝试处理几乎所有消息，这可以基于并延伸至高 速缓存生存期△高速缓存的期满高速缓存。因此，协调过程的性能自从协调代理127发出 关于预期被存储在档案140中的消息的查询依赖可以进行优化且可以通过从高速缓存320 访问消息实现I/O节省。在时间间隔Tl期间，协调代理127可以联系档案140的协调应用程序146并发出 包括一个或多个Gen-I消息的消息ID在内的初始查询。初始查询可由档案140经由协调 应用程序146接收，且可以确定查询中所标识的每一个消息是否已经被接收并由档案140 完全存储。在确定查询中所标识的所有消息被完全存储之后，档案140可以经由协调应用 程序146用指示每一消息均被存储的肯定响应(Ack)来响应。当接收到对特定消息的肯定 响应之后，协调代理127确认消息被归档且可以从本地消息存储310删除该消息。然而，在某些情况下，可以确定在查询中标识的消息中的一个或多个未被档案140 存储。例如，档案140在接收到查询时可能没有接收到特定消息。在这样的情况下，档案140 可以经由协调应用程序146用标识未被存储的消息的否定响应(Nak)来响应。因为由协 调代理127发出的初始传递确认查询针对预期被存储在档案140中的消息，所以接收到否 定响应可以指示典型的消息传递和处理延迟或更严重的问题。当协调代理127从档案140 接收到关于特定消息的否定响应时，在消息存储310中维护未经确认的消息以保证其可用 性，直到可以确认该消息被归档。当接收到关于特定消息的否定响应时，协调代理127可以将消息分类为Gen-2。因 此，在一些实施例中，可以基于不能确认这样的消息的归档来对待协调消息进行分类。如果 不能确认消息的归档，则可能是正在经历典型的消息传递和处理延迟且需要额外的时间来 允许解决延迟的情况。在图4所示的示例中，当与消息相关联的时间在时间间隔T2内时，该消息可以被 分类为Gen-2消息。如图所示，时间间隔T2的长度可以对应于问题解决SLA( △问题解决) 时间间隔。根据各实施例，时间间隔Δ问题解决可以基于解决消息延迟所需要的时间。例 如，时间间隔△问题解决可以是按正常过程通过自动修正和/或通过手动干预解决引起延 迟的问题来解决大多数消息延迟问题所耗费的假设的或观察到的时间量。一般地，时间间 隔Δ问题解决将是相对较长的时间段，例如约5小时。
可以基于用于解决消息延迟的时间间隔来对待协调消息进行分类。应明白，理想 地，将消息分类为Gen-2或Gen-3很少出现。在各种实现中，在时间间隔T2期间且直到时 间间隔Δ问题解决已经过去，特定消息可以被分类为Gen-2消息，且然后被分类为Gen-3。 例如，特定的未经确认的消息可以被分类为Gen-2，直到从协调代理127接收到包含特定的 未经确认的消息的日志报告的副本和/或未经确认的消息最初被存储在消息存储310中的 时间起已经过去时间间隔(△高速缓存+ △问题解决)。或者，特定的未经确认的消息可以 被分类为Gen-2，直到从发送关于特定的未经确认的消息的初始传递确认查询的时间起已 经过去时间间隔Δ问题解决。 被协调代理127分类为Gen-2的待决消息可以对应于经历延迟问题的未经确认的 消息。根据各实施例，协调代理127不发出关于被分类为Gen-2的待决消息的查询。例如， 如果在已经过去Δ问题解决之前发送关于日志报告的部署的重试查询，则该查询将很可 能得到另一否定响应(Nak)。因此，不为T2期间的Gen-2消息执行查询发出，且可以延迟该 查询发出直到Δ问题解决期满。在各实施例中，被分类为Gen-3消息的消息可以包括比T0+T1+T2更老的消息。在 一些实施例中，例如，被分类为Gen-3的消息跨越在当前时间之前的时间间隔(△高速缓存 + Δ问题解决)之前提交的所有消息。被协调代理127分类为Gen-3的待决消息可以对应 于具有现在可以解决的延迟问题的未经确认的消息。在允许时间间隔Δ问题解决过去以解决邮件延迟之后，协调代理127可以发出关 于被分类为Gen-3的一个或多个未经确认的消息的重试查询。在时间间隔T3期间，例如，协 调代理127可以联系档案140的协调应用程序146并发出包括一个或多个Gen-3消息的消 息ID在内的重试查询。在一些实施例中，协调代理127可以周期性地发出关于待决Gen-3 消息中的部分或全部的重试查询。例如，协调代理127可以每隔24小时就联系档案140的 协调应用程序146，并发出包括先前在当前时间之前的时间间隔(△高速缓存+△问题解 决)之前提交的所有Gen-3消息的消息ID在内的重试查询。重试查询可由档案140经由协调应用程序146接收，且可以确定在重试查询中标 识的每一个消息现在是否已经被档案140接收并完全地存储。如果确定在重试查询中标识 的所有Gen-3消息都被完全存储，则档案140可以经由协调应用程序146用指示每一消息 均被存储的肯定响应(Ack)来响应。当接收到对特定消息的肯定响应时，协调代理127可 以确认先前未经确认的消息已经被归档且可以从本地消息存储310删除该消息。然而，如果确定在重试查询中标识的消息中的一个或多个未被存储，则档案140 可以经由协调应用程序146用标识未被存储的消息的否定响应(Nak)来响应。当协调代理 127从档案140接收到关于特定消息的否定响应时，在消息存储310中维护未经确认的消息 以保证其可用性，直到可以确认该消息被归档。在一些实施例中，当接收到对关于Gen-3消息的重试查询的否定响应时，协调代 理127可以确定是否已经达到最大等待时间阈值。如果还没有达到最大等待时间阈值，则 协调可以周期性地联系档案140的协调应用程序146并发出对未经确认的消息的进一步的 重试查询，直到达到最大等待时间阈值。在其他实施例中，当接收到对关于Gen-3消息的重试查询的否定响应时协调代理 127可以确定是否已经达到最大重试尝试次数。如果没有达到最大重试尝试次数，则协调可以周期性地联系档案140的协调应用程序146并发出对未经确认的消息的进一步的重试查询，直到达到最大尝试次数。当不能确认消息时，协调代理127可以通过将未经确认的消息重新提交给档案 140来执行对未经确认的消息的补救。在一些实施例中，当已经达到最大等待时间或最大重 试尝试次数时，协调代理127可以执行对未经确认的消息的补救。在其他实施例中，可以不 存在最大等待时间或最大重试尝试次数，且协调代理127可以在单次重试尝试失败后开始 补救。例如，如果对Gen-3消息的第一重试尝试失败，则协调代理127可以在接收到来自档 案140的否定响应之后立即补救消息。直到确认特定消息被归档，未经确认的消息保留在消息存储310中以保证其可用 性。根据各实施例，协调代理127可以将未经确认的消息重新提交给档案140，并将未经确 认的消息的副本保存在消息存储310中。在未经确认的消息被重新提交给档案140之后， 协调过程可以再次开始，直到确认该特定消息被归档。如果在若干重新提交尝试之后不能协调特定消息，则需要干预。根据各实施例， 在补救失败诸如特定数量的重新提交尝试失败之后，协调代理127可以生成和发送警告警 告。例如，如果在若干重新提交尝试之后协调失败，则可以给生成电子邮件系统的管理员发 送告知管理员该问题以及需要手动过程来解决该问题的警告。应明白，即使是在特定消息 不能被协调时，消息仍保留在消息存储310中以保证其可用性。图5示出适用于实施各实施例的消息流500的一个实施例。如图所示，消息流500 可以涉及在电子邮件服务器Iio和档案140之间交换消息501-509。在一些实现中，日志 记录代理125、协调代理127、日志记录应用程序144和协调应用程序146发送和接收消息 501-509，如以上所描述的。然而，各实施例不限于这样的实现。此外，尽管图所示的示例包 括特定消息集，但应明白，消息流500提供一般功能的示例性实现。应理解，可以包括替换 或附加消息，且取决于特定实现可以省略一些消息。如图所示，电子邮件服务器110经由日志记录代理125，将日志报告501发送给档 案140。在各种实现中，可以基于日志记录条件集来创建日志报告501。例如，当电子邮件 消息被电子邮件服务器110发送给接收者时，日志记录代理125可以确定电子邮件消息是 否满足日志记录的条件。如果满足这些条件且要应用日志记录，则日志记录代理125将电 子邮件消息打包为日志报告501。日志报告501可以包括，例如满足档案140的日志记录条件的电子邮件消息的副 本以及包括消息的消息ID、接收者身份和消息的其他传输数据的元数据。电子邮件服务器 110将电子邮件消息发送给接收者并经由经由日志记录代理125将日志报告501发送给档 案140。可以例如通过SMTP经由电子邮件将日志报告501发送给档案140。根据各实施例，当日志报告501被创建时，日志记录代理125还将日志报告的副本 502发送给协调代理127以便存储在本地邮箱或保存区，诸如消息存储310中。日志报告的 副本502包括要协调的消息，其可以包括被发送给接收者并被发送给档案140的相同消息 的副本。日志报告的副本502还可以包含包括消息的消息ID、接收者身份和消息的其他传 输数据元数据的元数据。如上所述，在一些实现中，保存区中的待协调消息可以被分类成多代协调。根据各 实施例，待协调消息可基于与档案140相关联的等待时间、在可以从高速缓存320中本地地获得要协调的消息的副本时、确认消息归档失败、用于解决消息延迟的时间间隔或以其他 方式来进行分类。在这样的实现中，可以根据消息分类来发出查询以便优化协调过程的性 能并最小化对档案140的查询的数量。 在图5所示的示例中，协调代理127可以联系档案140的协调应用程序146并发 送配置查询503。在各种实现中，配置查询503可以包括向档案140请求诸如处理消息的预 期SLA或等待时间等特定配置信息的web服务查询。档案140可以经由协调应用程序146 接收配置查询503。档案140经由协调应用程序146用包括所请求的配置信息的配置响应 504来响应配置查询503。如图所示，电子邮件服务器110可以经由协调代理127向协调应用程序146发出 一个或多个查询，以保证特定消息到达并存储在档案140处。在各实施例中，协调代理127 可以执行异步协调过程，该异步协调过程用于联系档案140、询问被发送给档案140的消息 是否已经被完全保存以及确认消息在档案140中的存储。如果档案140不能确认给定消息 的存储，则协调代理127可以在稍后时刻再次执行询问档案140的一系列步骤。即使档案 140从不确认存储，协调代理127也将维护消息的本地副本，以供查看、打印、保存等等。在图5所示的示例中，协调代理127可以联系档案140的协调应用程序146和发 送传递确认查询505。在各种实现中，在ASLA期满之后在时间间隔Tl期间，可以发送传递 确认查询505。传递确认查询505可以包括，例如一个或多个Gen-I消息的消息ID。由协 调代理127接收并被分类为Gen-I的消息可以对应于预期被存储在档案140中的消息。另 夕卜，消息的副本可以从高速缓存320中获得，以实现I/O节省。传递确认查询505可以由档案140经由协调应用程序146接收，且可以确定传递 确认查询505中标识的每一个消息是否已经由档案140接收并完全存储。基于该确定，档 案140经由协调应用程序146用传递确认查询响应506来响应传递确认查询505。在各种 实现中，传递确认查询响应506可以在时间间隔Tl期间发送并包括一个或多个Gen-I消息 的消息ID。如果确定传递确认查询505中标识的所有消息被完全存储，则档案140可以经由 协调应用程序146用包括指示每一个消息都已被存储的肯定响应(Ack)的传递确认查询响 应506来响应。当传递确认查询响应506包括肯定响应时，协调代理127确认消息被归档 且可以从本地消息存储310删除该消息。如果确定传递确认查询505中标识的消息中的一个或多个没有被档案140存储， 则档案140可以经由协调应用程序146用包括标识未被存储的消息的否定响应(Nak)的传 递确认查询响应506来响应。当协调代理127接收到包括否定响应的传递确认查询响应 506时，在消息存储310中维护未经确认的消息以保证可用性，直到可以确认消息被归档。当一个或多个消息未被确认时，协调代理127可以联系档案140的协调应用程序 146并发送重试查询507。在各种实现中，可以在允许用于解决邮件延迟的时间间隔Δ问 题解决过去之后的时间间隔Τ3期间发送重试查询507。重试查询507可以包括一个或多个 Gen-3消息的消息ID。由协调代理127分类为Gen-3的待决消息可以对应于具有现在可以 解决的延迟问题的未经确认的消息。重试查询507可以由档案140经由协调应用程序146接收，且可以确定重试查询 507中标识的每一个消息是否已经由档案140接收并完全存储。基于该确定，档案140经由协调应用程序146用重试查询响应508来响应重试查询507。在各种实现中，重试响应508 可以在时间间隔T3期间发送并包括一个或多个Gen-3消息的消息ID。
如果确定重试查询507中标识的所有消息已被完全存储，则档案140可以经由协 调应用程序146用包括指示每一消息被存储的肯定响应(Ack)的传递确认查询响应508来 响应。当重试查询响应508包括肯定响应时，协调代理127确认消息被归档和可以从本地 消息存储310删除该消息。如果确定重试查询507中标识的消息中的一个或多个没有被档案140存储，则档 案140可以经由协调应用程序146用包括标识没有被存储的消息的否定响应(Nak)的重试 查询响应508来响应。当协调代理127接收到包括否定响应的重试查询响应508时，在消 息存储310中维护未经确认的消息以保证可用性，直到可以确认消息被归档。在一些实施例中，当接收到包括否定响应的重试查询响应508时，协调代理127可 以发出进一步的重试查询，直到达到最大的等待时间阈值和/或最大尝试次数。在其他实 施例中，在单次重试尝试失败时，协调代理127就可以立即开始补救。当消息不能被确认时，通过将消息重新提交给档案140，协调代理127可以执行对 未经确认的消息的补救。如图所示，在一些实施例中，通过将重新提交消息509发送给日志 记录应用程序144，协调代理127可以执行对未经确认的消息的补救。在其他实施例中，通 过将重新提交消息509发送给日志记录代理125以便重新提交给档案140，协调代理127可 以执行对未经确认的消息的补救。重新提交消息509可以包括未经确认的消息的副本且可以通过例如SMTP作为日 志报告电子邮件消息被发送给档案140。在各种实现中，发送重新提交消息509重演被发送 给档案140的原始日志报告501。协调代理127还将未经确认的消息的副本保存在消息存 储310中。在重新提交消息509被发送之后，协调过程可以再次开始，直到确认特定消息被 归档。如果在若干重新提交尝试之后，特定消息不能被协调，则协调代理127可以生成警告
并将警告发送给管理员。根据各实施例，根据用于在电子邮件服务器110和档案140之间通信的协调协议， 消息流500可以涉及一个或多个消息的交换。使用web服务协议和web服务模式，协调协议 可以例如被实现为web服务。在一些实施例中，协调协议可以被实现为根据简单的对象访 问协议(SOAP)通信协议和应用程序之间的通信过程来传递XML文档。当被实现为web服务 时，协调协议可以使用各种平台和语言无关格式，这些格式被设计成根据诸如HTTP、HTTPS、 SMTP、FTP等通信协议通过诸如因特网等计算机网络来进行通信。应明白，协调协议可以有 利地被实现为web服务，这是由于防火墙通常允许HTTP通信并且许多档案已经提供HTTP 前端以允许管理员登陆归档内容并对其执行搜索。在一些实施例中，协调协议的查询和响应消息可以包括被实现为XML文档的web 服务查询和响应。查询和响应XML文档可以使用XML架构和诸如XML命名空间(xmlns)、 XML架构实例(xsi)、XML架构定义(xsd)扩展文件名等属性来实现。在一些实现中，查询和 响应XML文档可以包括SOAP消息，SOAP消息包括SOAP包封和包含调用和响应信息的SOAP 正文。以下示出根据web服务协调协议实现的配置查询503和配置响应504的一个非限制性示例。在此示例中，配置查询503正在询问以获得特定配置信息，诸如用于处理消息的 预期SLA或等待时间。查询

< ？ xml version = “ 1.0〃 encoding = “ utf-8 “ ？ ><soap Envelope xmlns xsi = “ http://www.w3.org/2001/ XMLSchema-instance“xmlns :xsd = ‘‘ http //www. w3. org/2001/XMLSchema"xmlns:soap = " http://schemas.xmlsoap.org/soap/envelope/" ><soap:Body>〈Configuration xmlns =" http://localhost/reconcile" ><IgnoredParameter xmlns =" " />〈/Configuration〉</soap:Body></soap:Envelope)响应SLA是“O年O月O天O小时10分钟O秒”所支持的版本是1.0和1.5< ？ xml version = ” 1.0〃 encoding = ” utf-8” ？ ><soap Envelope xmlns xsi = “ http://www.w3.org/2001/ XMLSchema-instance“xmlns :xsd = ‘‘ http //www. w3. org/2001/XMLSchema"xmlns: soap = " http://schemas.xmlsoap.org/soap/envelope/" ><soap:Body><ConfigurationResponse xmlns = " http://localhost/ reconcile" >〈Configuration xmlns = 〃 〃 ><Sla>P0Y0M0DT0H10M0S</Sla><SupportedVersions>〈Version〉<MajorVersion>l</MajorVersion><MinorVersion>0</MinorVersion>〈/Version〉〈Version〉<MajorVersion>l</MajorVersion><MinorVersion>5</MinorVersion>〈/Version〉</SupportedVersions>〈/Configuration〉</ConfigurationResponse)
〈/soap: Body〉</soap: Envelope) 以下示出根据web服务协调协议实现的传递确认查询505和传递确认响应506的 一个非限制性示例。在此示例中，传递确认查询505正在向档案帐户bank_customer@ehs. com询问已发送所示次数的两个消息的状态(‘V后缀指示XML架构的UTC)。查询< ？ xml version = “ 1.0〃 encoding = “ utf-8 “ ？ ><soap Envelope xmlns xsi = “ http://www.w3.org/2001/ XMLSchema-instance“xmlns :xsd = ‘‘ http //www. w3. org/2001/XMLSchema"xmlns:soap = " http://schemas.xmlsoap.org/soap/envelope/" ><soap:Body><ConfirmDe 1 ivery xmlns=" http://localhost/reconcile" >〈Account xmlns="" ><EmailAddress>bank_customeriehs. com</EmailAddress>〈/Account〉〈MessageldList xmlns="" ><MessageIdSentTime = " 2008-09-01T09:00:OOZ " >12345ijournal. report. messageicK/ Messageld><MessageIdSentTime = " 2008-09-01T09:01:OOZ〃 >67890ijournal. report. messageicK/ Messageld>〈/MessageldList〉</ConfirmDelivery>〈/soap: Body〉</soap: Envelope)响应对于第一消息，消息等待时间为9分15秒，而对于第二消息，消息等待时间为8分 12秒。< ？ xml version = “ 1.0〃 encoding = “ utf-8 “ ？ ><soap Envelope xmlns:xsi = “ http://www.w3.org/200 1/ XMLSchema-instance“xmlns :xsd = ‘‘ http //www. w3. org/2001/XMLSchema"xmlns:soap = " http://schemas.xmlsoap.org/soap/envelope/" ><soap:Body><ConfirmDeIiveryResponse xmlns = " http://localhost/ reconcile" >〈MessageldList xmlns="" >
<MessageIdLatency = “ P0Y0M0DT0H9M15S “ >12345ijournal. report. messageicK/ Messageld><MessageIdLatency = “ P0Y0M0DT0H8M12S “ >67890ijournal. report. messageicK/ Messageld></MessageIdList></ConfirmDeliveryResponse>〈/soap: Body〉</soap: Envelope)可以理解，尽管一些实施例可以被描述为根据web服务协议来实现协调协议，但 是可以使用其他协议，包括但不限于，远程过程调用(RPC)协议、电子邮件消息收发协议、 诸如传输控制协议(TCP)等网际协议、代表性状态传输(REST)协议、诸如真正简单聚合 (RSS)等web馈源协议、和/或任何其他合适的同步或异步协议。可以参考一个或多个逻辑流程进一步描述上文所描述的实施例的操作。可以理 解，代表性的逻辑流程不一定必须按呈现的顺序执行，或按任何特定顺序执行，除非另有陈 述。此外，参考逻辑流程所描述的各种活动可以串行地或并行地执行。逻辑流程可以根据 给定一组设计和性能约束的需要，使用所描述的各实施例一个或多个硬件元素和/或软件 元素，或替换的元素来实现。例如，逻辑流程可以实现为由逻辑设备(例如，通用或特定用 途计算机)执行的逻辑(例如，计算机程序指令)。图6示出了适于实施各实施例的逻辑流程600的一个实施例。逻辑流程600可以 代表由此处所描述的一个或多个实施例执行的某些或全部操作。如图所示，逻辑流程600可以包括接收要协调的消息(框610)。在各种实现中，要协调的消息可以对应于由电子邮件服务器110发送给档案140以供存储的消息。在一些实 现中，例如，要协调的消息可以包括被发送给档案140以供存储的消息的副本。要协调的消 息可以在日志报告502的副本中接收，日志报告502对应于由电子邮件服务器110发送给 档案140的日志报告501。日志报告502的副本可以包括被发送给接受者并被发送给档案 140以供存储的相同消息的副本。逻辑流程600可以包括对所接收的要协调的消息进行分类(框620)。在各实施例 中，要协调的消息可以基于一个或多个时间间隔来分类，诸如对应于与档案相关联的等待 时间的时间间隔、可以在本地高速缓存320中获得要协调的消息的副本的时间间隔和用于 解决延迟问题的时间间隔。要协调的消息还可以基于接收到对传递确认查询的否定响应来 分类。逻辑流程600可以包括根据要协调的消息的分类来向档案发出的传递确认查询 (框630)。在各实施例中，传递确认查询可以基于档案140的等待时间来延迟。在一些实 现中，传递确认查询可以根据web服务协议被发送给档案140。逻辑流程600可以包括确认被发送给服务器的消息的归档(框640)。在各实施 例中，要协调的消息被存储在诸如消息存储310等保存区中，直到确认发送给档案140的消 息被存储。在确认消息被存储在档案140中之后，可以从消息存储310中删除要协调的消息。如果接收到对传递确 认查询的否定响应，则可以向档案140发送重试查询，直到达到最 大等待时间和/或最大尝试次数。逻辑流程600可以包括补救未经确认的消息(框650)。在各实施例中，在接收到 对重试查询的否定响应之后，可将要协调的消息重新提交给档案。在未经确认的消息被重 新提交给档案140之后，协调过程可以再次开始，直到确认特定消息被归档。应明白，即使 在无法确认特定消息时，消息也保留在消息存储310中以保证其可用性。可以理解，尽管逻辑流程600可以被描述为执行特定步骤序列，但是，根据替换实 施例，还可执行其他步骤序列。此外，由逻辑流程600的某些单独步骤可包括多个子步骤， 这些子步骤可以按对单独步骤合适的各种顺序执行。此外，取决于特定实现，可以添加附加 步骤或者可以移除某些步骤。图7示出了适于存储各实施例的逻辑的制品700的示图。如图所示，制品700可 以包括用于存储逻辑704的存储介质702。存储介质702的示例可包括能够存储电子数据 的一种或多种类型的计算机可读存储介质，包括易失性存储器或非易失性存储器，可移动 或不可移动存储器，可擦除或不可擦存储器，可写入或可重写的存储器等等。逻辑704的示 例可包括各种软件元素，如软件组件、程序、应用、计算机程序、应用程序、系统程序、机器程 序、操作系统软件、中间件、固件、软件模块、例程、子例程、函数、方法、过程、软件接口、应用 程序接口(API)、指令集、计算代码、计算机代码、代码段、计算机代码段、文字、值、符号，或 其任何组合。在一个实施例中，例如，制品700和/或计算机可读存储介质702可以存储包括可 执行计算机程序指令的逻辑704，当由计算机执行所述指令时，所述指令使计算机执行根据 所描述的实施例的方法和/或操作。计算机的示例可包括具有根据所述实施例的计算能力 和/或通信能力的任何合适的计算设备。示例性计算设备可包括但不限于，移动设备、个 人数字助理、移动计算设备、智能电话、蜂窝电话、手机、单向寻呼机、双向寻呼机、消息通信 设备、计算机、个人计算机(PC)、台式计算机、膝上型计算机、笔记本计算机、手持式计算机、 服务器、服务器阵列或服务器场、web服务器、网络服务器、因特网服务器、工作站、小型计算 机、大型计算机、超级计算机、网络设备、web设备、分布式计算系统、多处理器系统、基于处 理器的系统、消费电子产品、可编程消费电子产品、电视机、数字电视机、机顶盒、无线接入 点、基站、用户站、移动用户中心、无线电网络控制器、路由器、集线器、网关、网桥、交换机、 机器、或其组合。可执行的计算机程序指令可包括任何合适类型的代码，如源代码、已编译的代码、 已解释的代码、可执行代码、静态代码、动态代码等等。可执行计算机程序指令可以根据预 定义的计算机语言、方式或语法来实现，以便指令计算机来执行某一功能。指令可以使用任 何合适的高级、低级、面向对象、可视、已编译和/或解释性编程语言，诸如c#、c、c++、java、 BASIC、Perl、Matlab、Pascal、Visual BASIC、汇编语言，及其他语言来实现。各实施例可以使用硬件元素、软件元素或两者的组合来实现。硬件元素的示例可 包括如前面为逻辑设备提供的示例中的任何一个，并且还包括微处理器、电路、电路元件 (例如，晶体管、电阻器、电容器、感应器等等)、集成电路、逻辑门、寄存器、半导体器件、芯 片、微芯片、芯片集等等。软件元素的示例可包括软件组件、程序、应用、计算机程序、应用程 序、系统程序、机器程序、操作系统软件、中间件、固件、软件模块、例程、子例程、函数、方法、过程、软件接口、应用程序接口(API)、指令集、计算代码、计算机代码、代码段、计算机代码 段、文字、值、符号，或其任何组合。确定一个实施例是否使用硬件元素和/或软件元素来实 现可以根据诸如根据给定实现所需的任意数量的因素而不同，诸如所希望的计算速率、功 率水平、耐热性、处理周期预算、输入数据速率、输出数据速率、存储器资源、数据总线速度， 及其他设计或性能约束。可以使用表达“耦合”和“连接”以及它们的派生词来描述某些实施例。这些术语 不一定作为彼此的同义词。例如，一些实施例可使用术语“连接的”和/或“耦合的”来描 述以指示两个或更多元件彼此有直接的物理或电接触。然而，术语“耦合的”还可以意味着 两个或更多元件彼此不直接接触，而仍彼此合作或交互。要强调的是，提供了本公开的摘要以符合37C.F.R. 1.72(b)节，该节要求使读者 能快速确定本技术公开的特性的摘要。但应理解，它不能被用来解释或限制权利要求的范 围或含义。此外，在前面的“具体实施方式
”中，可以看出，各种特点可以编组到一个实施例 中，以便简化说明。本公开的此方法不应被解释为反映所要求保护的各实施例需要比每一 个权利要求中明确地记载的特征更多的特征的意图。相反，如下面的权利要求所反映的，本 发明的主题在于少于单个所公开的实施例的所有特征。如此，下面的权利要求被包括到“具 体实施方式”，且每一个权利要求本身也作为单独的实施例。在所附权利要求书中，术语“包 括(including)”和“其中(其中)”被分别用作相应的术语“包括(comprising)”和“其中 (wherein)”的普通英语等效词。此 外，术语“第一”、“第二”、“第三”等等只用作标记，并不 旨在对它们的对象施加数值要求。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权 利要求书中定义的主题不必限于上述具体特征或动作。相反，上述具体特征和动作是作为 实现权利要求的示例形式公开的。
权利要求
1.一种方法，所述方法包括接收(610)要协调的消息，所述要协调的消息对应于由服务器(110)发送给档案(140) 以供存储的消息；对所接收的要协调的消息进行分类(620)；根据所述要协调的消息的分类来向所述档案发出(630)传递确认查询；以及基于对所述传递确认查询的响应来确认(640)从所述服务器发送到所述档案的消息 是否被存储在所述档案中。
2.如权利要求1所述的方法，其特征在于，包括接收对应于由所述服务器发送到所述 档案的日志报告的日志报告的副本。
3.如权利要求1所述的方法，其特征在于，包括发出向所述档案请求包括预期等待时 间的配置信息的配置查询。
4.如权利要求1所述的方法，其特征在于，包括基于一个或多个时间间隔来对所述要 协调的消息进行分类。
5.如权利要求4所述的方法，其特征在于，所述时间间隔包括以下时间间隔中的一个 或多个对应于与所述档案相关联的等待时间的时间间隔、可从本地高速缓存中获得所述 要协调的消息的副本的时间间隔、以及用于解决延迟问题的时间间隔。
6.如权利要求1所述的方法，其特征在于，包括基于接收到对所述传递确认查询的否 定响应来对所述要协调的消息进行分类。
7.如权利要求1所述的方法，其特征在于，包括在接收到对所述传递确认查询的否定 响应之后发出重试查询。
8.如权利要求7所述的方法，其特征在于，包括在接收到对所述重试查询的否定响应 之后将所述要协调的消息重新提交给所述档案。
9.如权利要求1所述的方法，其特征在于，包括存储所述要协调的消息；以及在接收到对所述传递确认查询的肯定响应之后，删除所述要协调的消息。
10.如权利要求1所述的方法，其特征在于，包括根据web服务协议来向所述档案发出 所述传递确认查询。
11.一种包括包含指令的机器或计算机可读存储介质的制品，所述指令在被执行时使 系统能够实现如权利要求1到10中的任一项所述的方法。
12.一种装置，包括消息接收组件(332)，所述消息接收组件(332)从日志记录代理(125)接收日志报告的 副本，所述日志报告的副本包括对应于由所述日志记录代理发送给档案(140)以供存储的 消息的要协调的消息；分类组件(334)，所述分类组件(334)对所接收的要协调的消息进行分类；以及查询发出组件(336)，所述查询发出组件(336)向所述档案发出传递确认查询，以便确 定从服务器(110)发送到所述档案的消息是否被存储在所述档案中。
13.如权利要求12所述的装置，其特征在于，包括查询响应接收组件(338)，所述查询响应接收组件(338)从所述档案接收对所述传递 确认查询的响应，其中所述查询发出组件在接收到对所述传递确认查询的否定响应之后发出重试查询；以及补救组件(342)，所述补救组件(34 在接收到对所述重试查询的否定响应后将所述 要协调的消息重新提交给所述档案。
14.如权利要求12所述的装置，其特征在于，所述装置包括所述日志记录代理。
15.如权利要求12所述的装置，其特征在于，所述传递确认查询包括web服务查询。
全文摘要
描述了用于协调和补救由服务器发送以供存储在档案中的消息的技术。一些技术可以包括接收要协调消息，该消息对应于由服务器发送以便存储在档案中的消息。可对所接收的要协调的消息进行分类，且可以根据供协调的消息的分类来向档案发出传递确认查询。基于对传递确认查询的响应，可以肯定地确定被发送给档案以供存储的消息是否确实被存储在档案中。描述并要求保护其他实施例。
文档编号G06Q50/00GK102077237SQ200980125607
公开日2011年5月25日 申请日期2009年5月28日 优先权日2008年6月27日
发明者G·普拉, J·凯, N·昌德, S·托马斯, Y·王 申请人:微软公司