远程数据收集系统和方法

专利名称：远程数据收集系统和方法
技术领域：
本发明总体上涉及远程数据收集。更具体地，本发明提供了一种远程数据收集系统和方法，用于按照自动的平台不可知方式通过网络上从多个远程位置处的一个或多个数据库和多个数据库类型检索(retrieve)数据，例如金融、销售额、市场和运作等数据。
背景技术：
特许经营是一种进行贸易的方法，从而商业概念的拥有者(即，特许人(franchisor))向独立的商业实体(即，被特许人(franchisee))许可商业模型，以在意义明确的特许协议条件下进行操作。特许人在协议中阐述的指南范围内授权证实的商业外观(trade dress)、操作方法和系统以及商业实践的使用。特许人提供各种支持服务，所述支 持服务可以包括广告/营销/公共关系、培训、操作/物理工具设计辅助、产品/目录规范、材料来源支持、包括营业范围(LOB)应用的生产和操作系统、销售点(POS)系统和/或其他商业支持。这种支持通常提供给被特许人，用于作为月销售额的百分比来计算特许费用，被特许人通常按月将所述月销售额传真或者发送电子邮件至特许人。在美国到2005年为止，特许经营商业模型已经在超过70个不同的工业部门使用，2500个特许人，超过900，000个单个的被特许位置，产生超过I万亿美元的收入。LOB应用是关键计算机应用集合之一，所述关键计算机应用对于运行诸如生产、操作、结算、供应链管理、资源计划应用等之类的商业是至关重要的。LOB应用通常是专用的程序，其包含多种集成能力，所述能力绑定到并且依赖于数据库特征和数据库管理系统，以存储、检索和管理关键事务和商业数据。特许人具有受托人法律义务，以支持被特许人在其成功操作所述概念时的努力。不幸地的是，特许人通常尽力知晓他们的被特许人如何执行，因为非常难以针对每一个被特许人收集、整合(consolidate)和报告关键的操作和金融指示器。这种困难的至少一个已知原因是因为这些单个的被特许人中的许多人利用不同的操作和金融报告系统，由于系统的不同数据存储形式、不同产品版本或非标准产品运用，不能从中容易地收集、整合或报告操作和金融报告系统。结果，特许人通常建议被特许人如何利用非常有限的数据来改进其商业和操作性能，并且他们缺乏将其与所述概念或工业内的同等组和地区规范进行比较的能力。此外，尽管大多数商业和商业顾问需要识别操作的关键性能指示器(KPI)，具有有限的数据使其难以对其进行识别和监测。尽管特许权是可以利用远程数据收集系统的工业的一种示例，存在可以受益于远程数据收集系统的多种其他工业或商业模型。其他示例包括同业公会、共同运作或发行人，但是也可以包括大公司的分部或外地办事处。另一个示例是银行或提供贷款方(creditprovider)需要监测他们向其贷款的、他们向其提供信用贷款之最高限额的一个或多个商业的金融健康，信用贷款之最高限额可以与诸如可接收账户(AR)现金流或收益率之类的金融措施进行绑定。典型地，需要远程监测商业的金融或操作参数的商业依赖于月报、季报或年报的电子邮件或传真副本，通常在接收或浏览它们时丢失、忽略或废弃报告。此外，这些报告不足以用于监测动态的商业条件，并且当然在没有广泛的定制信息技术(IT)系统和支持员工的情况下不能提供近似实时和一致方式的监测。通常，可以看出远程数据收集的问题和挑战适用于POS或LOB应用操作的多个位置的任意和所有商业应用，其中需要监测这些商业要求按照整合或“累积”方式从每一个位置对于数据的访问。在收集操作或商业数据的至少一些已知技术中，通过在所有远程站点对嵌入到诸如POS系统之类的单个LOB应用的收集特征进行标准化。也就是说，如果特许人想要从在他们的金融系统中操作的所有远程商店收集每天的销售和交易详细信息，他们必须首先对实际相同的POS系统卖方(如果不是POS应用的实际相同版本)上的每一个商店进行标准化。需要这种标准化以使系统能够累积和整合来自应用数据库的相同副本的数据以及在相同类型和版本级别的数据库中存储的相同交易细节。此外，许多这些单个版本的收集系统依赖于内置于数据库引擎中的数据整合系统，数据库引擎用于将数据存储(电读/写硬盘)在远程站点。诸如Microsoft、Oracle、Sybase之类的数据库卖方已经提供了嵌入到他们的产品中的许多种类型的私有“数据复制”技术，以允许独立的软件卖方(ISV)研发丰富的LOB应用(例如，P0S)，可以经由他们的嵌入式技术或应用程序编程接口(API)将相同的数 据库复印和复制到中心位置。商业必须将它们的POS系统标准化到单个POS卖方和版本以能够实现远程数据收集的事实是一种限制，其通常由POS系统将建立在只与其自己“对话”的数据库卖方的复制技术的顶层上的事实来驱动。对于这些挑战的先前定制IT方案是利用数据复制技术，数据复制技术要求使用私有工具和技术来开发定制软件。尽管数据库或软件工具卖方在多年来已经提供了远程数据复制技术，这些技术局限于用于它们自己例如单个数据库卖方API和复制系统可以用于构建单个LOB应用(例如，CRM系统或P0S)，其只收集和整合来自相同LOB类型和版本级别的远程数据。这些技术不允许通用处理，通用处理按照简化和自动的无人值守方式(lights out manner)作用于LOB应用和数据库卖方。此外,尽管大量企业已经使用传统的“中间件”消息总线(或者消息排队)体系结构来在两个独立的LOP系统之间复制数据，这些实现要求一贯的一组中央管理且昂贵的IT基础设施(例如集成安全模型、管理防火墙端口或私人网络和专用服务器)。因此，需要从多个远程站点或多个LOB系统复制数据的商业必须或者对一个数据库或中间设备卖方进行标准化，或者提供昂贵的IT研发并且在每一个站点进行支持。用于复制数据的替代技术依赖于数据的公共定义或者公共数据文件格式。尽管存在针对“数据互操作性”的许多工业标准(例如XML标准、CSV文本文件或者其他格式)，这些标准使得只有当从原始LOB系统“输出”数据时能够使用公共数据描述和数据格式，它们没有解决数据传输问题。因此，必须使用诸如因特网文件传输协议(FTP)或来自Tibco、IBM、Oracle/BEA的消息排队产品等之类的附加通信技术。或者替代地，可以写入定制软件，其利用新的网站服务通信标准来向中心位置“传输”公共数据格式的文件。使用这些技术来创建集中和自动的远程数据整合系统的挑战在于以下事实它们要求软件定制来使其适应于每一个LOB产品和版本，并且要求大范围的IT员工来支持通信信道两侧的通信基础设施。此外，这些方法依赖于让每一个LOB应用支持与“数据输出”选项相同的公共文件格式。当将来自不同LOB应用的数据收集到中央数据仓库或存储器中时可能存在附加的要求，其要求广泛的“数据变换”技术用于将数据归一化为公共格式。这些条件或要求不能容易地得到小规模或中等规模商业(例如特许人)的支持，或者这些条件没有在各种远程商业中同样地存在。这一事实尤其适用于其中本地员工不是试图对数据进行集中的商业雇员(例如被特许人)的远程站点，因此它们不熟悉、未经训练或者不愿意遵循详细的操作指南和程序，来将LOB数据从他们的本地系统中提取到公共数据文件并将其通过复杂的通信基础设施发送。对于远程LOB数据的自动收集的附加挑战在于系统经营和管理的问题。对于工作的任意系统，其必须具有用于唯一地识别位置和本地系统代理所要求的特定“规则”的处理，以在所述位置处自主地操作。这种识别和控制方案必须对商业操作规则、命名约定、组织结构(区域、属性、报告规则等)以及其他收集和整合规则要求(例如代码和数据库的版本)中的变体和变化进行处理。附加地，系统管理模型必须提供对于远程站点的导向、控制、监测和报告的灵活性，同时数据收集过程按照24X7X365的方式动态地操作。除了技术障碍之外，许多远程数据收集系统由于简单地管理在数百甚至数千个远程物理位置处的远程软件代理的开销和复杂度而失败。最后，用于将远程站点和中心整合点相连的通信方法必须容易并且按照“无人值守”的方式操作，以便有效地缩放管理、监测和系统控制，同时向中心站点提供远程数据的缺省容限、可靠性和确保的递送。
因此，需要在许多远程站点上具有LOB数据的整合观点的任何商业必须或者提供IT支持员工或者创建定制的软件程序，所述定制的软件程序如此简单以至于任何人无需对于一贯程序的大量培训就能操作。各种商业所希望的是通用远程数据整合系统，其可以迅速并且容易地适应于他们的LOB系统，而无需大量昂贵的定制编程。然后，这种通用系统必须作用于任意类型的远程位置，并且作用于各种LOB应用和数据库卖方以及单个远程站点处的多个数据库或LOB应用。然后需要这种系统迅速部署到许多远程站点而无需远程IT员工，并灵活且动态地工作，从一个或多个不同的LOB应用可靠且动态地收集数据，并且通过诸如TCP/IP和因特网之类的公共通信基础设置来发送数据。

发明内容
在各种典型实施例中，本发明提出了一种远程数据收集系统和方法，适用于按照自动的平台不可知方式从网络上的多个数据库类型检索诸如金融、销售额、市场和运作等之类的数据。本发明设计用于作用于LOB应用、数据库卖方和商业模型或贸易、以及商业基础设施(各种计算和POS设备)以及商业过程，同时提供从多个远程商业站点自动收集数据的集中能力。本发明包括与多个远程数据收集代理进行通信的一个或多个中央服务器。远程数据收集代理设计用于克服现有要求或限制，因为其能够从较大的商业范围以及多个LOB应用收集远程数据，同时按照在本发明中所包括的可管理可配置传输机制与多个数据库卖方和格式相联系。本发明的远程数据整合过程是灵活、全面和完整的，同时允许在远程站点处的多种情况下运行的多种LOB应用程序的可变性、复杂性和单个的要求。独有和新颖的设计特征和属性提供了这些能力，并且允许中央管理者动态地定义在许多站点从多种远程LOB应用和数据库格式收集什么数据以及如何收集，而无需研发定制程序代码，并且也无需本体协助，同时产生了整个商业操作的中央整合观点。通过使用可选的LOB增加部件或本地UI部件来向远程站点员工报警、并且作为与客户端站点处的整合数据库服务的可选配置一起允许它们自动过程的一部分，示出了附加的灵活性。结果，远程数据收集系统提供了一种集中的数据库，可以从中执行管理报告、执行控制板(executive dashboards)和监测，以增加这些远程站点的效率、效果和总体收益率，同时也允许对于表现不佳站点的增加的可见性，并且能够在较快向表现不佳的站点提供提前的支持。这是通过客户端代理和服务器设计、定义的使用和更新、以及中央管理方法来完成的，而无需昂贵且稀有的远程IT人员。本发明的灵活性是通过以下内容得出的在摘要消息传递结构的顶部建立的基础、加上使用“元数据”消息和分层代码设计来动态地控制和配置代理，分层代码设计允许在不干扰或重新安装整个系统的情况下替代代码层。系统的无人值守远程控制和操作的关键是由于使用自动安装的包，加上一系列系统元数据消息，一旦经由与数据收集相同的消息基础设施将所述系统元数据消息与集中日志记录、错误处理和报警系统一起进行安装，系统元数据消息定义且控制在远程代理处进行何种行为。这种体系结构允许在用于收集远程数据的相同消息通信基础设施上集中地管理和监测整个系统。元数据消息由配置数据库来构造，配置数据库限定了系统“定义规则”和客户端代理“更新版本”。所述系统还使用消息来提供所有远程代理状态或状况的集中日志。记录定义，所述定义存储了收集规则，所述收集规则告知远程客户端代理在远程站点或站点组操作的一个或多个LOB应用做什么、 如何做以及何时做。使用现有的数据复制系统，可以将系统定义和更新文件发送至远程站点，以更新现有的代理码并且重新配置收集过程。因此，迅速的适应性、灵活性和性能的总的独有和新颖系统特征是由于许多独有的因素，包括但是不局限于系统体系结构、远程代理和服务器设计以及元数据控制和管理系统的组合。要求这种灵活性以便在较宽范围的商业条件、各种LOB应用以及作为自动远程数据收集系统一部分的数据库上容易地修改所述系统，所述自动远程数据收集系统不要求远程员工支持以在成千个站远程站点上任意地缩放。在本发明的典型实施例中，远程数据收集系统包括与一个或多个数据库相连的一个或多个服务器；与一个或多个服务器通信耦合的一个或多个远程客户端，所述一个或多个远程客户端的每一个均包括与一个或多个客户端数据库通信耦合的远程客户端代理；以及元数据消息传输机制，配置用于对客户端数据库与一个或多个数据库之间的数据进行协调、控制和复制。所述远程数据收集系统还包括与所述一个或多个远程客户端的每一个通信耦合的定义服务器，其中所述定义服务器配置用于为每一个远程客户端代理提供多个定义，并且其中所述多个定义定义了针对每一个客户端数据库中的数据的收集规则。所述远程数据收集系统还包括与所述一个或多个远程客户端通信耦合的更新服务器，其中所述更新服务器配置用于向所述一个或多个远程客户端代理提供更新。所述客户端数据库包括来自一个或多个商业线应用或销售点应用的数据；并且所述远程客户端代理包括摘要工具，所述摘要工具配置用于操作多个数据库类型。可选地，所述元数据消息传输机制利用最初在Java消息服务上实现的可替代传输层；所述元数据消息传输机制包括在一个或多个远程客户端与一个或多个服务器之间交换的多种消息类型；以及所述元数据消息传输机制包含格式化的数据，所述格式化数据是使用消息处理器通过远程数据收集系统提炼的，从而能够实现对于消息处理器的未来升级。多种类型的消息类型可以包括数据消息、日志消息、异常消息、更新准备好消息、更新服务器在线消息、更新完成消息、更新中断消息、更新文件消息、更新配置消息、定义请求消息和定义消息。所述远程数据收集系统还包括在数据收集任务中使用的一个或多个影子数据库，其中所述数据收集任务将数据从一个或多个客户端数据库之一复制到一个或多个影子数据库之一，并且根据请求的收集定义对象来处理所复制的数据。所述数据收集任务包括比较功能，用于响应于所请求的收集定义对象来验证所复制的数据；以及发送功能，用于向一个或多个消息处理器进行发送，所述消息处理器理解将数据在集中管理的数据流之间进行复制的下层消息传输层。在本发明的另一个典型实施例中，一种计算机包括网络接口 ；到数据库的连接；以及与网络接口和所述连接通信耦合的处理器，其中所述处理器配置用于执行远程数据收集代理；其中所述远程数据收集代理配置用于对数据库和服务器之间的数据进行协调、控制和复制，以及其中所述远程数据收集代理利用元数据消息传输机制通过网络接口与服务器进行通信。所述远程数据收集代理配置用于从服务器接收多种定义，所述定义定义了针对数据路中的数据的收集规则。所述远程数据收集代理配置用于从服务器接收代码更新。所述数据库包括来自商业线应用和销售点应用之一的数据；并且所述远程数据收集代理包括摘要实现工具，所述摘要实现工具配置用于操作多个数据库类型。可选地，元数据消息传输机制利用最初在Java消息服务上实现的可替代传输层；所述元数据消息传输机制包括在远程数据收集代理和服务器之间交换的多种消息类型；以及所述元数据消息传输机制包含格式化的数据，所述格式化数据使用消息处理器，从而使得能够实现对于消息处理 器的未来升级。所述计算机还包括在数据收集任务中使用的影子数据库，其中所述影子数据库与处理器通信耦合，其中所述数据收集任务将数据从数据库之一复制到影子数据库之一，并且根据请求的收集定义目的来处理所复制的数据。所述数据收集任务包括比较功能，用于响应于所请求的收集定义目的来验证所复制的数据；以及发送功能，用于向一个或多个消息处理器进行发送，所述消息处理器理解下面的消息传输层，所述消息传输层将数据在集中管理的数据流之间进行复制。在本发明的再一个典型实施例中，一种远程数据收集方法包括在远程客户端处接收代理安装包；初始化代理安装包；安装服务过程，所述服务过程促进了自动开始启动过程(launcher process);加载启动过程,从而在远程客户端代理处安装多个部件；以及通过多个元数据消息与服务器通信，以将来自远程客户端处的数据库的定义数据提供给服务器。所述方法还包括从服务器接收收集定义；响应于所述收集定义从数据库提取数据；将所提取的数据写入到本地影子数据库；将所提取的数据与本地影子数据库中的数据进行比较；以及将包括所提取数据的数据消息发送至服务器。所述方法还可以包括从收集定义中提取表和列定义；以及将所请求的表和列定义与数据库、本地影子数据库和服务器数据库的至少一个的表和列进行匹配。所述方法还包括向服务器发送更新号码；从服务器接收更新包；以及将所述更新包安装到远程客户端上。可选地，所述数据库包括来自商业线应用以及销售点应用中的一个或多个的数据。


这里参考不同的

和描述本发明，其中相似的参考数字分别表示相似的方法步骤和/或系统部件，其中图I是远程数据收集系统体系结构的图；图2是包括单个远程客户端或代理的远程数据收集系统的图；图3Α和3Β是针对远程数据收集在客户端侧和服务器侧的通信信道的图4是在数据中心处的传输空间视图；图5是远程数据收集系统的客户端侧的图；图6是收集过程的图；图7是关键代理代码分类的图；图8是收集调度的部分图；图9是代理节点发送者/收听者对的图；图10是消息控制器对象的图；图11是数据收集任务过程的图；
图12是各种节点消息发送者分类类型的表；图13是远程数据收集系统的服务器侧的图；图14是准备好的客户端队列目的的图；图15是描述了一些定义规则属性和元数据的表；图16是定义服务器的表；图17是数据整合服务器(DCS)过程的图；图18是DCS过程的附加图；图19是元数据或日志服务器过程的图；图20是更新服务器的图；图21是DC服务器文件系统的图；图22是作为用于远程数据收集的客户端和/或服务器操作的计算机的图；以及图23-25是盈亏账目、现金流和资产负债表的⑶I屏幕。
具体实施例方式本发明的远程数据整合过程是灵活的、全面的和完整的，同时允许在远程站点处的多种情况下运行的多种LOB应用程序的可变性、复杂性和单个的要求。由本发明的定义摘要模型提供的独有和新颖的设计特征和属性允许这些能力适用于多种LOB应用，而无需将可执行程序代码引入到LOB或数据库应用中。这种设计的附加益处允许中央管理者在无需本地IT协助的情况下的许多站点对来自多种远程LOB应用和数据库格式的数据收集进行调度，同时产生整个商业操作的集中整合观点。通过可选的LOB附加部件的使用示出了附加的灵活性，本地Π部件用于警告远程站点人员，并且允许它们与客户端站点处的整合数据库服务器的可选配置一起作为自动过程的一部分。结果，远程数据收集系统提供了数据库，可以从所述数据库执行管理报告、控制板(dashboard)和监测以增加这些远程站点的效率、效果和总体收益率，同时也允许对于表现不佳站点的增加可见性，并且能够较快向表现不佳的站点提供提前的支持。这是通过客户端代理和服务器设计、定义的使用和更新、以及集中管理方法来完成的，而无需昂贵且稀有的远程IT人员。本发明的灵活性是通过以下内容得出的在摘要消息传递结构顶部上建立的基础、加上使用“元数据”消息和分层代码设计一起来控制和配置代理，所述分层代码设计允许在不干扰或重新安装整个系统的情况下替代代码层。系统的无人值守远程控制和操作的关键是由于使用自动安装的包，加上一系列系统元数据消息，一旦安装了代理，系统元数据消息定义且控制在远程代理处进行何种行为。这种体系结构允许在相同的消息通信基础设施上集中地管理和监测整个系统，消息通信基础设施用于收集远程数据。元数据消息由配置数据库来构造，配置数据库限定了系统“定义规则”和客户端代理“更新版本”。系统还使用消息来提供所有远程代理状态或状况的集中日志。记录定义，所述定义存储了收集规则，收集规则告知远程客户端代理做什么、如何做以及何时做。使用现有的数据复制系统，可以将系统定义和更新文件发送至远程站点，以更新现有的代理码并且重新配置收集过程。因此，包括具有低IT开销的灵活性、适应性和性能的总体系统特征归因于许多独有的因素，包括但是不局限于系统体系结构、远程代理和服务器设计以及元数据控制和管理系统的组合。要求这种灵活性以便在较宽范围的商业条件、各种LOB应用以及作为自动远程数据收集系统一部分的数据库上容易地修改所述系统，所述自动远程数据收集系统不要求远程员工支持。图I是根据本发明的典型实施例的远程数据收集100的体系结构图。所述系统可以独立地作用于所有类型的远程商业位置102、L0B应用104、本地或远程主控数据库106等。如这里所使用的，术语“Zee”意味着被特许人、分支机构、远程商业站点等，并且术语 “Zor”意味着特许人或者商业概念的拥有者，特许人向独立的Zee授权商业模型来操作，或者是希望从远程和/或独立站点收集数据的任意高级商业组织或实体等。术语销售点(“P0S”)设备意味着用于记录客户端购买的电子现金收入记录机。术语商业线(“L0B”)应用意味着是否在个人计算机(“PC”)或其他嵌入式计算设备上运行的过程，用于营业、本地地存储数据。示例的LOB应用包括(根据Intuit)快速订购(QuickBook)、Cyrius或者配置用于提供结算、供应链管理、资源计划应用等的任意其他程序。各种Zee远程位置(Zee1、Zee2、…、Zeen)每一个均彼此相关联,并且组成Zor或特许系统(Z0ri、Z0r2、-,Zorn)的概念。远程商业位置102的每一个均包括网络连接性，例如通过因特网110。每一个Zee位置可以包括一个或多个本地数据库106，本地数据库包括数据元素(整个数据集合或者数据的子集)，相关联的Zor将整合成单个数据库，即整合数据库112。整合数据库112可以位于中央数据中心114，中央数据中心114配置用于操作服务器侧数据整合和管理过程116，以对来自各种远程商业位置102的各种数据库106的数据进行整合。整合数据库112附加地包括系统报告和控制板118，系统报告和控制板配置用于基于整合的数据提供各种用户界面(UI)屏幕和图像、以及数值表、表格和KPI报告。图2是远程数据收集系统200的图，远程数据收集系统包括根据本发明典型实施例的单个远程客户端或代理202。所述远程数据收集系统200包括两个站点远程站点204和数据中心(DC) 206，通过诸如因特网110之类的网络互连。代理202配置用于从范围广的商业、以及多个LOB应用208、以及单个远程站点204的数据库210自动收集远程数据，并且保持本地代理状态、记录过去和当前动作的结果214。远程代理202的控制和操作归因于其独有且中心管理的元数据命令和在一组“配置”数据库212中的DC 206处存储的控制消息。灵活的系统体系结构允许这种元数据同时定义和控制在远程代理202处做什么，同时允许集中地管理和监测整个系统200。元数据配置数据库212定义了系统“定义规则”和客户端代理“更新版本”。此外，数据中心包括数据库，数据库包含所有远程代理状态或状态230的集中日志。将远程代理202的元数据命令和控制定义限定为存储数据收集规则的对象，数据收集规则告知远程客户端代理202做什么、如何做、何时做以及使用代理代码部件的哪个版本或更新来执行针对每一个LOB所请求的动作。将这些定义对象串行化，存储为配置数据库212中的数据库记录，并且通过定义服务器216进行检索。通过包含对于存储在服务器的文件系统的目录中的代码文件的“指针”或参考的记录来定义更新配置元数据命令，服务器的文件系统包含新的客户端代码“版本”。将更新元数据命令存储在配置数据库212中，并且通过更新服务器218进行检索。可以将定义和更新对象自动地从数据中心206发送至远程站点204以对远程客户端代理202处的现有代码和收集过程规则进行更新。系统200也可以包括更新代码文件220，更新代码文件在一个实施例中是Java jar包和配置文本文件，配置文本文件将可用于远程代理202的更新封装为由更新元数据定义。系统体系结构、远程代理202和服务器设计、与元数据命令和控制以及集中管理系统一起的组合允许系统200具有极大的远程灵活性。需要这种灵活性以便快速且容易地在宽广范围的商业条件、LOB应用和数据库上适应远程数据收集系统200，以使远程数据收集自动化而无需远程IT人员。远程数据收集系统200的体系结构允许产生独有的数据整合过程，该数据整合过程可以作用于Zee，或者远程商业站点，以及Zor的不同集合，或者想要自动从远程个人计算机(“PC”)、嵌入式计算设备或POS设备自动收集数据的任意其他类型的商业。在每一 个远程站点204处，商业可以让不同的LOB或POS应用208运行，并且这些应用每一个均可以使用不同的数据库引擎210。这些商业还可以具有针对不同的商业过程的不同集合的安装PC、软件和数据收集需求。本发明的远程数据整合过程可以容易地从中央位置适应为经由元数据命令和控制定义对象212作用于这种远程目标站点和基础设施。另外，可以Zor内的Zee以及在订购远程数据收集服务的所有Zor上自动地管理这种灵活性。这种设计导致集中地管理和整合LOB数据集合，存储在整合的LOB数据库222中并且通过数据整合服务器224从远程站点204检索，通过识别关键商业趋势和操作统计并且提供累积的金融性能和其他类型的管理报告226，例如关键性能指示器(KPI)报告，订户可以使用数据整合服务器来(在Zee或Zor层面)改善其商业性能。注意，尽管贯穿该文档使用术语Zor和Zee，远程商业的任何集合可以是“收集客户端”，并且商业方法不局限于特许或任意特定的工业或LOB应用类型。远程数据收集系统200促进了对于多种问题提供单个的系统解决方案，所述问题面临着不能拥有或者控制远程站点、或者不存在本地IT员工来管理该过程的工业和公司。当这些商业试图对来自远程或独立商业位置204的数据进行整合以便监测商业活动时，很快发现了这一过程的复杂性。然而，还没有对于可以购买并且容易地配置的这些类型场景的现有打包(shrink-wrapped)工具或解决方案。系统200可以迅速且容易地适用于广泛范围的工业和商业应用，以提供远程数据整合系统，系统可以设计为但不局限于以下属性(I)数据库独立性(系统200可以作用于SQL服务器、Oracle、Sybase、Paradox、Access、私有格式、文本文件、XML文件等);(2)计算机应用独立性(系统200可以从各种类型的LOB应用收集数据)；(3)站点独立性(所述系统200能够实现自动远程数据收集，而无需现场IT支持)；(4)商业模型独立性(作用于工业范围内，例如特许经营等)；(5)容易的系统代理202经由电子邮件通知、即时消息服务或经由嵌入式URI链接的网页或者自解压安装程序来转入转出(rollout) ； (6)经由可选的LOB应用附加和/或系统托盘(tray)工具的用户交互或诊断；(7)能够在交替的位置整合数据同时仍然集中管理的能力；以及(8)提供对于整合数据的成批统计、分析和报告的能力，即基于整合数据库222、230中的数据通过全系统的报告226。系统200可以迅速地适应于多种LOB应用情况，同时成功地配置用于成百上千个远程操作的远程站点，按照“无人值守”方式提供整合的LOB数据。此外，系统200可以使用灵活的消息传递、分层的LOB数据访问体系结构，所述分层的LOB数据访问体系结构允许其集中地控制和操作、同时实现了对于在安全可靠的通信传输信道232上来回传递的这些消息进行响应的简单远程代理202。重要的是需要注意，许多年来，数据库或其他软件工具卖方已经提供了许多类似的探测特性，例如“公布和订阅”，但是这些数据复制产品的实现局限于被合并到利用与卖方的数据库复制技术构件的单个LOB系统中。本发明所解决的问题比单个LOB应用(例如CRM系统)所面临的问题更加广泛，因为那些是在单个数据库卖方上配置并且只从这些数据库收集数据的专用或单一目的的收集系统。系统200包括通用过程，其按照自动和无人值守方式作用于任意类型的LOB应用和数据库卖方。类似地，尽管企业商业已经使用了传统的“中间件”消息总线或消息队列体系结构来链接远程站点或者将两个独立的LOB系统 链接在一起，这些实现要求受管理IT基础设施的一致集合(例如共享的安全模型、私有网络和专用IT员工来开发定制软件并且管理这些系统)，以便支持将作用于LOB应用或数据库卖方平台的数据收集系统。因此，远程数据收集系统200的能力是独有的，用于作用于所有类型的LOB应用、数据库卖方和商业模型或商业、以及作用于不同类型的商业基础设施(各种计算机和POS设备)并且无需IT支持过程，同时提供了从多个远程商业站点集中和自动的数据收集能力。在远程数据的收集期间，使用通过元日志服务器228从远程代理202接收并且存储在代理状态数据库230中的系统“定义和更新”消息和关于远程代理活动的多个状态报告来控制和集中管理远程代理202。定义可以是针对一个或多个远程代理202的一组商业规则和其他设置，商业规则描述做了什么、如何做，其他设置作为被称作数据收集定义对象的一组元数据进行存储。可以在配置数据库212中使用一组管理应用或网页来集中地管理这些定义，所述管理应用或网页允许单个管理者容易地改变针对一个、多个或所有远程代理202在一个或多个Zor的收集过程。对于系统适用于支持的每一个L0B，所述定义可以是串行化的商业对象，存储为对商业操作规则进行定义的记录，例如在远程站点204收集哪个LOB数据、使用哪种“方法或方式”或命令状态或API来收集数据、在哪里找到数据、以及客户端侧配置信息(什么时间对其进行收集、使用哪个客户端更新版本、将其发送至何方等等)。远程客户端代理202周期性地基于可配置的周期检查新定义，当需要时使用定义服务器216将新定义向下发送至客户端。通过更新号码(“UN”)来跟踪更新，更新号码定义了使用特定版本的代码来执行远程代理202所请求的动作。使用商业专用元数据在更新数据库218中存储和组织更新，(商业专用元数据的示例包括但不局限于通过商业或分类类型、通过LOB应用、公司ID或“ZorlD”、专用存储位置或客户端ID、地理区域或分组码等来组织更新)，商业专用元数据允许单个管理者利用特定版本的代理代码来自动地定向一组远程代理202。更新元数据参考服务器的文件系统目录，目录组织和存储二进制Java代码文件(例如JAR文件和基于文本的配置文件(例如.conf)220两者。可以通过以下方式来管理和配置更新全系统(例如所有Zor)、经由其专用客户端ID的每个商业概念(ZorID)、每一组远程客户端或每一个单个的远程站点。注意，版本的定向也可以支持Zor内的Zee的分组或Zor，例如通过区域或低于或者通过共同的LOB应用。更新文件220包含新的远程代理代码文件，当远程代理向更新服务器218发送请求消息时，通过远程代理202领取(pulldown)新的远程代理代码文件。这些更新文件220可以经由自动更新过程来提向当前的远程客户端代码附加新的系统特征或者提供补丁 /缺陷修补。注意，可以从客户端侧202发起控制和管理信息(定义和更新)的整个流程。客户端代理202可以使用消息传递模型来发起与DC服务器206的会话，DC服务器使得远程客户端202能够按照可靠且可预测的方式“增加”收集数据或者“领取”定义或更新。此外，可以沿用于集中数据分布的两个方向发送消息和数据的流。可以利用在通信传输信道232上建立的可扩展和灵活的消息传递机制，按照安全和可靠的方式在因特网110上传输远程收集的信息。已经对客户端204和服务器206之间信息的实际传输进行提炼，使得系统200可以使用各种方法的组合或者按照未来的需要进行替换。在示例的实施例中，系统200可以使用可扩展消息，所述可扩展消息经由受管理的 通信传输信道232在因特网110上传递。可以在安全和可靠的传输层上建立受管理的信道，例如但不局限于Java消息服务(“ JMS”)，并且用于按照异步或同步方式发送和接收数据和系统控制消息两者。在典型实施例中，远程数据收集系统200包括但不局限于可以在客户端204和数据中心206之间创建的信道中流动的11种独有类型的消息232，例如在因特网110上的消息包232。这些消息可以包括但不局限于数据消息、日志消息、异常消息、更新准备好消息、更新服务器在线消息、更新完成消息、更新中断消息、更新文件消息、更新配置消息、定义请求消息和定义消息。每一个消息232可以包括使用消息处理器从系统200提炼的格式化数据，以便允许处理器的未来更新，未来更新可以在系统200中附加新消息或者扩展现有的消息能力。远程代理202使用通过这种消息处理机制创建的消息232向DC 206发送LOB收集数据。远程代理202使用定义规则来提取数据并且手动切断消息发送节点，所述消息发送接节点利用处理器来创建和发送消息。将消息232移交给JMS层用于实际的可靠传输并且递送至DC206。除了数据之外，还经由附加的独有消息类型使用这种相同的消息传递机制将所有其他客户端状态或状况/日志信息发送至中央DC206站点。可以通过消息处理器按照多种格式来构建数据消息232，所述消息处理器可以产生多种消息格式，包括来自远程站点处的具体LOB数据库表的客户端数据的基于XML的表示。这些消息232可以包含来自表的一行或多行。以字节为单位的总消息大小是可配置的设置，并且用于调谐传输层面性能和可靠性。在典型实施例中，可以将数据消息232从客户端侧204发送至DC 206服务器处的服务器侧数据整合服务器224。在另一个典型实施例中，数据消息232可以沿两个方向流动。日志消息可以包括构建为文本串的远程代理日志消息，其源自远程客户端202，远程客户端然后通过元日志服务器228被日志记录到服务器侧代理状况数据库230。日志消息可以包括客户端应用的进展或状态，例如什么时候开始收集行程的时间戳、改变或更新具体的表的数据元素的时间、所述表具有的行数、以及是否存在对于LOB数据库的问题或变化、等等。异常消息可以隐藏发生的任意Java虚拟机(JVM)或Java代码例外。所述异常消息促进了将例外数据从远程代理202递送至中央服务器日志。
可以通过客户端202使用更新准备好消息来告知DC更新服务器218客户端准备好接收更新，并且向服务器提供客户端的当前更新号码版本。这种消息发起了服务器和客户端之间的更新会话。也通过服务器使用更新准备消息来搜索配置数据库，以确定什么更新号码是可用的(在更新号码与客户端的当前更新号码相同的情况下，没有更新可用，并且客户端将继续使用其当前版本)。当更新服务器在线时，可以通过更新服务器218使用更新服务器在线消息。更新服务器218可以向这一时刻连接的任意客户端广播这一消息，以让客户端知晓更新服务器已经完成了重新启动。因为实质上通知了客户端“忘记” 了从最近重新启动服务器218开始的任意在先消息，这种广播的消息使任意当前的更新会话无效。这种过程促进了防止失速(stalled)的远程客户端无限地等待(即当远程客户端等待更新完成消息时，由于服务器侧中断和重新启动而不会发送更新完成消息)。客户端可以重新开始更新过程，并且再次检查更新以发起新的会话。更新服务器218可以使用更新完成消息来告知远程客户端202其已经完成了发送所有的更新消息。这种消息终止了更新会话(从服务器端的观点来看)，并且客户端可以关断消息通信信道，并且在开始新的收集行程之前加载新的客户端代码。客户端可以使用更新中断消息来告知更新服务器218在客户端侧发生中断。在中 断服务器的情况下，服务器可以发送更新服务器在线消息来告知客户端已经中断了服务器并且请求再次更新。例如，中断可能是由于java线程“threw”由于无法处理的例外而“启动”java异常、例如尝试写入已经充满的本地客户端存储介质，但是不局限于此。更新文件消息可以是二进制消息，二进制消息包括可以写入到客户端侧存储介质中的JAR文件。例如，存在但是不局限于每个文件一个消息或每个消息一个文件。更新配置消息可以是包含用于对客户端配置文件进行更新的当前设置和值的消息。例如，存在但是不局限于每一个客户端配置文件一个消息。替代地，所述消息可以包括配置文件中的至少一个设置。客户端可以使用定义请求消息来请求定义服务器216发送它们应该使用的当前定义版本。例如，客户端可以在继续获得他们的当前规则之前等待从服务器216接收定义消息响应。定义消息可以隐藏或封装可以从定义服务器216发送至客户端以控制其操作的收集定义商业规则对象。图3A和图3B是客户端侧302和服务器侧304之间的通信信道300的图，用于根据本发明典型实施例的远程数据收集。在本发明的典型实施例中，通信信道300可以包括JMS传输层318以促进在因特网110上的消息通信。总体来说，客户端侧302和服务器侧304是图2的远程数据收集系统200的一部分，其使用“节点”326、328在传输层318发送和接收消息。更具体地，系统200可以使用特定类型的“节点”310、312、320作为“数据发送者”并且使用“节点”314、316、322作为“数据接收者或收听者”，用于在客户端侧302和服务器侧304之间的消息传输。节点提炼了网络层传输“端点”的概念，即网络通信发起或终止的地方。节点“对”是一个节点发送者310和一个节点收听者314、以及另外它们在特定机器(图9)处的共享节点状态306的组合。节点对封装了在网络传输层上的双向通信(发送和接收)的所有逻辑。例如，JMS传输层可以使用每一个线程的单向同步通信-或者发送或者接收。节点对可以用于对单线程JMS单向通信模型进行提炼，并且代替地对整个双向(发送和接收)通信进行封装。两个节点(一个客户端侧302和一个服务器侧304处的一个节点发送者310、312、320和一个节点收听者314、316、322)在诸如JMS之类的网络传输层上通信，网络传输层利用诸如因特网110之类的更低层的网络层来创建通信信道318，通信信道318用于从客户端侧向服务器侧传输消息或者反之亦然。通信信道318可以是总共两个节点，客户端侧302的一个节点和服务器侧304的一个节点(例如320，322)，用于单向通信。替代地，通信信道可以是总共四个节点，客户端侧302的一个节点对以及服务器侧304的一个节点对，用于双向通信。因此，系统200使用与客户端302至服务器304的相应过程匹配的节点对集合，反之亦然。系统200可以使用JMS传输空间318作为管理模型或提炼层以提供递送可靠和可缩放的网络通信基础设施的装置。在典型实施例中，任何特定机器(客户端302或者服务器304)上的节点发送者310,312,320和节点收听者314、316、322可以一起工作，并且可以共享共同集合的状态信息或者节点状态306、308，其允许节点将执行节点提炼层面的消息传输工作的线程进行同步。系统200 “目的地”是受管理的对象，其包含向特定位置(代理、服务器或服务)递送信息的消息。系统200使用JMS目的地作为通信信道318目的地的具体实现，并且所有目的地的集合形成了“传输空间”。也就是说，节点与特定的JMS目的地相连，并且消息业务量包含在目的地内。通过服务器主机名称、端口号和目的地名称和类型来定义JMS目的地。将这些属性存储在配置文件内，向下将所述配置文件作为定义配置信息的一部分发送至远 程代理，定义配置信息限定了远程代理使用哪些地方的节点应该发送它们的消息以及可以通过更新消息对这一远程站点节点配置进行更新。使用JMS工具来管理JMS目的地，所述JMS工具允许系统200的管理者手动地创建或破坏目的地对象。注意，可以代替地通过使用客户端发起的目的地的JMS特征来自动地管理JMS对象。也就是说，不需要服务器侧的JMS服务的用户管理来对新的目的地进行管理，因为使用JMS客户端发起的自动创建方法自动地创建了所述用户管理。一旦创建了目的地，节点过程立即能够利用它们的名称来识别向什么地方“发送”它们的消息。可以在DC服务器上运行的JMS实现使得系统200能够创建高级别目的地或者通信信道管理模型，其能够用于容易地显现和管理通信传输信道。这里将这种目的地的管理模型观点称作是传输层空间318，所述传输层空间是附加的系统提炼层。是由远程数据收集过程利用的总传输层空间提供按照摘要方式的可靠的传输消息包，摘要方式允许系统适用于其他数据传输系统。这种相同的通信信道基础设施也用于向远程代理202提供更新的代码和目的地。可以通过商业概念(例如ZorID)组织JMS目的地名称以提供一致且便利的管理组织模型。替代地，可以按照共享模式命名和利用所述目的地，以代替地使效率而不是管理名称清晰度最大化。在JMS体系结构中，依赖于需要的通信信道的类型，将传输目的地定义为主题或者队列。在典型实施例中，主题可以提供一个或多个节点发送者310、312、320和一个或多个节点收听者314、316、322之间的多对多通信信道。此外，替代的实现可以使用队列来提供一个或多个节点发送者310、312、320与使队列变空的单个节点收听者314、316、322之间的多对一通信信道。在典型实施例中，数据整合服务器224从通过单个远程代理204增加的JMS队列中检索数据，同时定义和更新服务器216、218代替地利用JMS主题用于与许多远程代理204的双向通信。此外，在典型实施例中，可以将数据从远程站点发送至数据整合服务器224。具体地，DC处的数据整合服务器224包括接地-收听者对象314、316,3220替代地，DC处的数据整合服务器24可以包括节点-收听者对象314、316、322和/或节点发送者对象310、312、320。在另一个典型实施例中，系统200可以分配和向下发送LOB数据至远程站点204并且将其向上收集至DC 206，所述LOB数据包括但不局限于针对LOB数据库的新商业规则。图4是根据本发明的典型实施例的数据中心处的传输空间318视图的图。传输空间318促进了对于在图2的远程数据收集系统上流动消息的信道进行管理。通过节点收听者314、316、322过程对消息队列进行服务，所述过程从用于处理的队列和集中的存储器采集消息。此外，数据整合服务器可以利用队列404允许多个客户端向服务器过程发送数据，例如多线程、多主机和/或并行集合的服务。服务器过程然后可以对数据消息进行串行化以创建唯一的数据记录，然后在中央数据库224中对所述唯一的数据记录进行插入、更新和/或删除。当已经对远程LOB数据进行了整合和集中之后，系统200可以提供另外的数据处理特征，包括但是不局限于数据挖掘、统计分析或趋势分析、KPI以及和大量报告一起与其他商业系统的集成。这种成批的远程数据向商业用户提供了用于获取对于它们的远程商业的操作特性、性能和总体健康程度的洞察力或商业智能的独有机会。 注意，使用自动客户端创建方法，管理者不需要执行主动的管理来创建JMS传输空间318。代替地，远程客户端凭借名称向JMS目的地发送消息，如果还没有存在这种目的地，则可以将这种目的地自动地创建为服务器侧JMS对象(主题402或队列404)。此外，管理工具可以监测传输空间318以识别不具有相应的收听者节点线程的新端点。也就是说，尽管JMS按照永久且持久的方式处理了服务器侧上端点的自动创建并且为其存储了消息限制，如果这是远程客户端首次运行则收集过程不能服务于这些新的端点。因此，将服务器侧自监测过程用于监视需要创建新服务器侧进行过程的自动创建端点，以便服务于所述新的收集端点。可选地，可以产生异常报告226以通知管理者已经检测到了新的收集客户端。节点主题402或队列404对象可以在JMS服务上运行。此外，系统200利用这一传输空间318中的这些JMS对象和服务来在客户端和数据中心之间的网络上提炼可靠发送和接收的数据包。替代地，系统200可以通过在新的传输层实现该相同的传输空间来在JMS层使用和/或替换附加的传输层技术。此外，可以与使得系统200按照这里所述方式操作的任意类型的传输或消息层一起使用系统200。可以保留将数据从许多远程站点移动至中央数据中心的远程数据收集过程，使得当需要时将数据发送回远程客户端。下面描述了特定的客户端代理和服务器设计。注意，在独立的图中对客户端和服务器进行表示和建模，因为它们经由消息传递体系结构300松散地耦合。然而，可以将客户端和服务器过程看作是单个系统设计的一部分，其适应了在多种系统上自动工作所要求的灵活性和适应性。例如，特定的客户端不知道远程服务器或消息传输规范，反之亦然；然而中央DC 206不会跟踪远程客户端状态和配置。消息传递节点326、328将每一侧与其相应的对应方相连，并且允许传递控制和配置消息以及LOB数据两者以可靠和自动的方式进行。图5是根据本发明典型实施例的远程数据收集系统的客户端侧500的图。客户端侧500和中央服务器侧依赖于消息发送的提炼，以协调和控制他们的工作。在本发明的典型实施例中，系统200利用Java代码，Java代码是平台无关的，并且允许其附着至多种LOB应用、数据库和操作系统、计算设备或POS平台。这种便携性允许使用创建摘要层的包装层，包装层隐藏了针对各种数据库、传输或操作系统部件和其他软件层的实现细节。分层的体系结构向系统200提供了对多种独立商业系统中的远程数据收集问题所要求的独立性和便携性特征。也就是说，为了对于远程的非IT管理的计算机系统施加最小的影响，系统200可以使用通过集中配置容易修改、定义、更新和版本控制的可替代层或部件。可以经由单击安装包将远程客户端代理202下载到客户端侧500并且进行安装，单击安装包可以可选地自动验证包括远程站点标识(例如客户端ID)多种数据值和配置要求，并且然后基于周期性自动地更新其自己。可以在不改变整个系统或者要求完全重装的情况下按照要求或请求独立地改变或更新部件层。此外，这种自我更新特征消除了对于用于完成对于远程代理202的改变或更新的本地人为干预的需要。Java虚拟机(“JVM”)(未示出)可以运行远程客户端代理202的软件代码。此外，JVM可以主控和运行标准的JMS类，JMS类向消息传输空间318提供接口，接口控制在因特网110上实际消息的发送。在远程客户端侧500处，服务器包装过程502部件可以用于自动开始远程数据收集过程，用于服务于本地商业设备(PC或P0S)，并且配置JVM加载和运行其他远程数据收集部件。服务包装过程502监测JVM的重新开始消息，并且如果检测到则自动重新加载启动过程504。服务包装过程502确保了在加电引导时间以及贯穿本地商业设备(PC或P0S)的操作时开始和运行启动过程504。最后，服务包装过程502可以配置JVM经由文件路径设 置、存储器要求等初始地加载当前远程数据收集JAR文件。启动过程504是单个Java过程，其可以加载和启动其他远程数据收集过程。远程数据收集系统200是一种分层服务，其中每一层负责小的隔离特征集合，小的隔离特征允许系统200使用Java调用、消息、.conf设置和JMS与其他层相互作用。可以将启动过程504抽象地看作确保其他远程数据收集过程正确运行的高级过程。具体地，利用启动作为同步根来允许松散地耦合分离的线程上的子特征或过程，以彼此抽象地相互作用。此外，其提供对于全局配置信息的访问。替代地，启动过程504可以设置退出条件并且关闭JVM。可以在退出JVM时通过服务包装过程502来监测或读取由启动过程504设置的退出条件，并且退出条件可以用于向应该重新开始JVM及其过程的服务包装过程502发信号。这种监测的看门狗过程提供了远程站点处的简化和可预测的可靠性。当开始JVM时，启动过程504自动开始，并且启动过程读取本地配置文件以确定应该在存储器中存储哪些其他过程。然后，启动过程504将那些其他Java类加载到JVM内部。同样，启动过程504用作所有输入/输出(I/O)对于本地文本配置文件(例如.conf)的接口。启动过程504重新定向JVM标准错误输出端口，以使用日志过程来确保将所有的Java错误写入到客户端侧中央日志214中。在一个典型实施例中，启动过程504是经由元数据消息可配置的。启动过程504也保持了代理状态信息，例如用于“正在收集”、“正在更新”、“更新开始”的数据值，这些数据值使得各种远程代理202子过程能够进行对于全局代理状态信息的摘要访问。更新器和收集器过程506、508可以询问启动过程504当前系统状态，以确定它们应该或不应该采取什么动作。此外，启动过程504经由定制的版本化文件系统类加载器(“VFSCL”)来构建和启动更新器和收集器Java类，VFSCL允许比标准的嵌入式JVM类加载机制更多的Java文件加载过程的控制。通过VFSCL来管理类加载，而无须使用文件锁定，所述文件锁定提供了本发明的另一个独有特征，因为其确保了代码更新改变不彼此冲突，代码更新改变不会由当前远程代理操作阻碍、并且能够重新运行。最后，启动过程504在需要时负责切断更新和收集器过程506、508，并且如果需要则切断整个JVM。在这种情况下，通过需要时切断并且重新开始JVM的服务包装502来通知启动信号。更新过程506负责保持本地安装为远程数据收集代码的最新当前版本，按照在数据中心212处存储的主更新数据库表来定义所述版本。在操作期间，更新过程506将更新请求消息张贴到由更新服务器218接收的目的地传输空间318中。更新请求消息的目的是为了基于由其更新号码定义的客户端当前运行版本来检查任意更新的代码或配置文件。通常，更新过程506询问DC其是否已经具有了在DC处可用的远程数据收集系统的新版本。这种摘要允许更新过程506保持在本地站点处由远程数据收集系统管理者定义的正确当前代码版本和配置设置。另外，客户端只需要知晓其当前的版本和所有更新的可用性，并且通过DC处的更新服务器218处理判定和递送。当客户端更新过程506接收到响应时，其开始接收文件更新消息或者如果其已经是最新时则接收更新完成消息。然后，更新过程506确定其是否需要重新开始服务包装过程502和JVM以重复需要的过程。通过更新服务器218对更新进行打包并且作为消息发送，通过客户端处理所述更新以创建在本地存储介质214上存储的新远程数据收集代码或配置文件。收集器过程508与配置定义本地LOB数据库210的一个或多个相连，提取要求的信息，并且可以向目的地发送数据或者将信息写入到本地影子数据库522中，然后准备数据消息以经由消息信道传输空间300发送至DC。收集器过程508包括在操作时同步的多个子过程和线程。收集器过程508也可以创建在本地状态数据库214中存储的日志条目，以便识别运行(或者上一个)哪一级或哪个过程，以及其要取什么值或动作。此外，可以将收集器状态打包为消息并且经由信道传输空间发送至元日志服务器228，元日志服务器允许中央管理者产生报告226，所述报告以最小的成本示出了多个站点上的这种复杂过程的状态和状况。托盘工具过程510可以是本地系统代理过程，其与PC或POS设备的本地用户相互作用，通知用户重要的状况或诊断消息，并且允许用户采取动作来改变或校正远程代理202的状况。托盘工具过程510的目的是向远程代理202的通常自动和手动操作提供可选的用户接口(UI)。例如，只要系统200识别出问题，托盘工具过程510可以通知用户。此外，用户可以使用托盘工具UI来请求系统200的远程代理202的当前状况。托盘工具过程510按照与其他操作系统效用和工具一致的方式来作为系统对象运行。在典型实施例中，托盘工具过程510可以包括改变状态(红/绿)的图标，或者创建弹出消息来警告用户系统需要他们的注意。示例可以包括由于功率故障或者如果因特网连接断掉导致的调度时间期间不能运行收集过程的时间。托盘工具图标允许用户在其上点击以显示目录，所述目录包含附加的状态信息(例如最后一次收集时间、版本号等等)，运行附加的诊断测试(例如经由查验DC的连接性测试)或者试图使用手动“现在运行”命令来立即开始收集过程。因此，系统200可以按照无人值守的自动过程运行，或者托盘工具510可以向本地用户提供与自动的远程数据收集过程相互作用、并且诊断诸如本地LOB连接性问题之类的本地问题的能力。每个LOB附加过程512是系统200的可选部件，将托盘工具过程510特征直接扩展到每一个本地LOB应用208中，代理202可以从本地LOB应用执行数据收集。这种特征允许本地用户在LOB应用菜单系统内执行“现在运行”命令和其他远程数据收集管理特征。在 操作期间，本地用户可以在BOB应用208范围内工作，并且确定使用哪个LOB附加过程512将当前数据发送至DC。例如，在本发明的一个典型实施例中，本地用户可以选择LOB应用208中的文件菜单，然后选择称作“现在运行收集”的附加菜单，他们可以手动地触发数据收集过程立即运行。替代地，命令位置、文本和功能可以是由定义文件限定的可配置成分，并且与针对特定LOB产品的LOB附加扩展方法兼容。这种附加模型允许用户通过与使用托盘工具510相同的方式导引系统200来控制什么时候收集数据。最后，可以按照平台专用的方式来将整个远程代理202打包，用于使用可以通过鼠标点击激活的适当安装过程或者通过软件配置工具自动进行的其他类型动作来安装和加载到远程客户端PC、POS或嵌入式设备中。这种安装过程可以经由多种机制开始，包括但不局限于发送给通过远程自动收集的管理者针对的每一个位置处的用户的电子邮件消息。在这一实施例中，电子邮件可以包含对远程数据收集转入转出程序的目的进行解释的文本，以及指向专用下载安装包的HTTP或FTP位置的URL。远程代理202安装包可以定制为特定的收集需要和针对本地设备的远程数据收集代码。可以通过电子邮件指导远程站点的商业用户点击链接来促使经由HTTP或FTP下载从因特网110将安装包复制到本地设备。一旦本地复制了安装包，可以自动运行安装包代码以提取远程数据收集文件、将其复制到预定的位置、并且将其配置为根据嵌入到安装包中的配置文件进行操作。如果需要，安装过程也可以将JVM代码复制到远程PC，并且进行配置以操作。此外，安装过程可以安装本地服务包装过程，所述本地服务包装过程然后可以加载JVM，并且在开启远程设备时自动地启动收集过程部件。如前所述，当远程数据收集过程首次加载时，服务过程502引起加载启动过程504。启动过程504的功能是在首次加载时启动更新过程506。第一次允许更新过程506时，更新服务发送更新请求消息以检测代码文件的新版本。这种自动检查确保了甚至当安装包具有更老或陈旧代码版本时本地客户端202也运行代码和定义文件的正确版本。系统200可以指导本地客户端202每当运行时寻找当前系统定义。这种自动引导促进了将当前版本的代码和定义自动安装到远程PC或POS设备，而无须扩展的本地人为干涉或动作。在安装和首次更新过程506已经运行之后，正常的远程数据收集操作程序接管，允许收集器过程按照调度地运行。一旦安装了当前和正确的文件集合，收集器过程508按照由定义对象所定义的规则调度间隔来发生。注意，尽管收集器过程508典型地按照由定义所定义的规则调度间隔发生，也可以经由可选的托盘工具510或者LOB附加工具512或者其他方法使用“现在运行”命令来启动立即的操作。图6是根据本发明典型实施例的收集器过程508的详细图600。在远程客户端202上运行的收集器过程508包括定义节点收听者602、定义节点发送者604、数据节点发送者606 (未示出可选的数据节点收听者)、元数据/日志节点发送者608以及收集调度过程612。通过远程本地客户端202实现的本地节点发送者604、606、60或者节点收听者对象602发送或接收消息以在DC 206处镜像实现。收集过程节点对象促进了对于经由消息信道传输层300来回发送的消息进行处理。这种通用目的的消息传递框架使得远程数据收集系统能够操作。收集调度过程612包括定义定时器614、定义检查任务616、数据定时器618和数据收集任务620。图7是图6的替代视图，其基于在远程代理202处包括的关键类700的代码级或对象级视图。代理202使用收集器过程508来从根据本发明典型实施例的远程数据库收集 数据。收集器过程可以包含附加的共享库代码702和多个其他标准java类，以便于创建经由消息信道发送消息所需要的客户端侧收集过程，所述消息信道328经由在JMS(未示出)中包含的类实现以通过因特网110发送数据。附加地，为了进一步从消息实现过程中提炼数据收集过程，DCT 620使用数据消息发送者704类对来自各种和多个LOB数据库210的数据消息的创建进行处理。可选地，DMS过程可以利用数据加密过程706来确保消息的内容。最后，数据收集调度器612创建用于收集过程的定时器614、618作为对本地设备时间进行监测的存储器对象，以便在适当时间启动定义检查和收集任务。图8是收集调度800的部分图。收集调度800只定义了密钥的子集，来自在定义和配置数据库212中定义的完全收集定义对象的调度相关性质。其可以包括首先调度DCT620启动的日期和时间、重复DCT 620的启动的间隔、如果非无限时启动DCT 620的总次数的个数、是完全调度DCT620还是只经由托盘工具510的用户调度、以及是否按照由系统管理者或订户配置和定义的特定客户端代理202来使用托盘工具510。客户端代理202过程使用的节点可以是定义节点对602、604(例如本地发送者和收听者310、314)、主收集数据节点发送者606加上元数据、或者日志节点发送者608 (例如，本地发送者320)。如上所述，这些节点是对由所选择的传输层提供的通信过程进行封装的 类，这里是JMS，并且用于从物理传输层实现中提炼数据收集过程。收集器调度过程612还可以包括确定收集调度800应该是什么、当前时间是什么以及用于检查新信息的收集定义所需要的代码。收集调度过程612可以在适当的时间使用启动定时器任务的定时器集合来启动数据收集任务(“DCT”)620和定义检查任务616。在典型实施例中，定时器614、618可以是对其调度任务的对象，以在所需的时间和/或以所需的间隔运行。在操作期间，收集调度器612首先从通过定义服务器216发送的定义消息中检索最近收集的定义对象，并且确定所述定义是否配置用于立即运行或者所述托盘工具是否已经设置了“现在运行”标记。如果任一种情况成立，则收集调度器612调度DCT620立即运行。否则，从整个系统定义对象中提取调度定义800。这种调度定义800可以包含限定的收集启动时间和间隔，其可以用于基于数据定时器618来调度DCT 620。接下来，对定义检查器任务616进行调度以按照重复的间隔在定义定时器614上运行。可以将这种间隔值存储为配置设置。定义检查器任务611是一种小后台过程，其在保持客户端与最近的收集定义和相应调度同步的间隔上运行。因为定义检查器任务周期性地运行，其使用通过节点对310、314处理的定义消息从由定义服务器21发送的整个定义对象检索当前定义，然后将检索的和当前的存储器内定义启动次数进行比较，并且如果需要重新调度收集。图9是具有收集节点发送者310、902和收集节点收听者314、904的远程代理202的节点发送者/收听者对326、900的图。节点发送者902和节点收听者904可以使用在因特网110或类似上的JMS消息通过消息信道318通信。节点发送者/收听者对326、900配置用于利用摘要消息作为对象来封装传输层以隐藏来自节点类的细节。节点发送者902和节点收听者904使用消息控制器908创建摘要消息，并且获取或者设置任意的消息内容。节点类型可以是发送者902或收听者904，并且所述消息可以是多种类型之一。收集节点发送者902与摘要目的地或者信道通信，在典型实施例中，所述摘要目的地或信道或者是JMS主题402或者是队列404 (图4)。存在对于通过节点状态306、906同步的节点收听者904的分离线程。节点收听者904实现了 java “可运行”接口，以允许容易地将其启动为与节点发送者902分离的线程。节点可以成对326、900工作以发送和接收消息。在典型实施例中，可以将节点状态306、906实现为共享的存储器对象，其包含所述节点对通过其进行通信的通信信道318的状况。节点状态306、906可以用于在节点发送者310、902和节点收听者314、904之间通信任意状态信息，具体是在它们分离的线程上必须同步的信息(即当收听者是激活的且能够进行接收时，使得发送者知晓传输是安全的)。图10是消息控制器对象908的图1000。在典型实施例中，可以将消息控制器对象908、1000实现为消息控制器摘要层，所述消息控制器摘要层产生数据和元数据控制消息。收集节点，即收听者310、904或发送者314、902，与消息控制器908相互作用，以使用因特网110上的JMS等创建用于在消息信道318上传输的消息1002。消息控制器908处理内部消息，例如报头、性质和有效载荷等。通过实现标准工厂图样来构件消息、并且附加地向展现用于促进来自消息1002的性质或数据设置或者提取来实现这种消息处理摘要。图11是作为本发明关键构件的数据收集任务(DCT)过程620、1100的两个阶段(调整/收集)的图。DCT过程620、1100是使用两个阶段来完成其工作的复杂内部过程。第一阶段(调整)具有三个关键步骤其确定要提取什么数据1110、以及如何成功地提取 数据1112、1114。步骤1110用于检索在定义对象1104中存储的最近一组收集规则。检索获取这些规则1110使得远程数据收集系统200能够经由调整过程1114提取所请求的数据，调整过程1114首先将一组请求的数据1104与LOB数据库210的当前状态进行比较1112，以动态地建立当前收集对象1108。依赖于LOB数据库210的当前状态和步骤1112的结果，比较步骤1114可能需要更改选择方法来通过动态地产生附加数据检索声明来提取数据。如果已经存在影子数据库1102，步骤1112尝试利用影子数据库522中的相同表和列来调整由当前收集对象1108定义的LOB数据库纲要(schema)。替代地，如果还没有存在影子数据库，根据由当前收集对象1108定义的数据库纲要、表和列来创建影子数据库。针对本地影子数据库来重复比较过程，并且对LOB数据库210和影子数据库1102之间的任何差别进行识别，以使得影子数据库对于使用当前收集对象1108通过动态数据同步脚本(script)处理收集数据(步骤1112、1114)是安全的。在完成调整阶段之后，DCT过程1100可以假设可以从本地LOB数据库中安全且精确地提取请求的数据，并且将其复制到影子数据库中。在调整阶段结束时(步骤1114)，当前收集对象1108对针对数据同步的所有可用表和列加以表示，并且影子数据库522、1102准备好处理本地数据并且提取所请求的数据集合用于发送至DC 206。步骤1114是独有的比较操作，其可以动态地产生新数据提取规则，或者更改现有规则或者进行收集规则的子集。也就是说，步骤1114用于确保收集系统200尝试完成最大量的工作并且提取尽可能多的数据，给出LOB数据库210的当前状态、代理202代码的当前版本和当前定义对象1108定义的规则。这种新颖和独有的特征确保了系统200可以按照突然和自动的方式操作，或者在非优选条件下适度地失败。在任意未完成收集运行1100的情况下，可以集中地日志记录和收集发生的任何误差或状态消息，以便产生异常报告226来警告中央管理者。这些异常报告允许中央管理者准备更新的定义或收集规则，其可以成功地克服由远程系统造成的任意改动，包括在没有本地用户交互作用或影响情况下对于LOB数据库210的纲要变动。一旦完成比较/调整阶段，可以进行收集任务过程的第二阶段。收集阶段执行可实现工作的当前设置，由步骤1114和当前收集对象1108定义，其从一个或多个本地LOB数据库210提取一组同步和请求的数据。一旦已经调整了数据和定义，DCT的收集阶段可以开始。在实际的收集阶段期间，所述过程可以分为两个步骤。在步骤1120中定义的同步过程使用“只读”命令声明来提取可收集的数据，所述“只读”命令声明是通过DCT调整阶段动态定义的。将通过动态步骤1120提取的数据复制到本地“影子”数据库522、1102，可以在每次运行收集过程1100期间动态地重新创建本地“影子”数据库。步骤1120从本地源数据库210中选择数据，并且在影子数据库1102中插入、更新或删除相应的数据。影子数据库1102中的一种重要实现包括能够跟踪和标记用于发送步骤1120的数据的能力。在影子数据库中存储的数据值可以通过元数据进行标记，以在现有数据、修改数据、删除数据或新数据之间进行区分，以便促进更加智能和有效的远程数据收集过程。步骤1120的完成使得影子数据库与对于本地LOB数据库210进行的改动以及使用之前可能还没有收集的新定义对象1108由管理者定义的可能的新数据的请求进行了同步。DCT过程的最后步骤是发送步骤1130，其中从影子数据库522中检索由收集定义对象1104定义的被请求的收集数据，并且使用消息摘要层1000对其进行封装用于传输。发送步骤1130可以利用由在影子数据库1102中存储的元数据属性标记的数据按照多种方式工作。发送模 式可以包括“重发所有”数据检索模式、发送确定日期/时间“以来”的模式、或者只发送最后收集运行模式以来的“变化或新”模式。发送步骤1130使用简单的逐行过程从影子数据库提取所请求的数据(例如新的、改变或删除的数据)，并且通过将每一行传递至数据消息发送者(“DMS”)类704，所述类将数据封装成由定义对象1104定义的大小。DMS704使用消息控制器908来将大块数据封装成用于移交至数据节点发送器606、902的适当大小的消息，所述数据节点发送者606、902然后使用消息信道318进行消息传输。由数据收集任务(DCT)过程508、620的调整阶段提供的灵活性是本发明的独有特征之一。可以将DCT 508、620看作是包含两个基本内容，或者标记为调整和收集阶段的摘要层，但是这是通过系统代理202依赖于用于检索数据的LOB应用程序208或数据库210或API的性质而按照多种方式实现的。通常，DCT 602过程的调整阶段执行标记为1110、1112和1114的处理步骤的独有和新颖功能。数据收集过程1100可以开始于从完整的收集定义对象1104提取收集规则数据1110，以学习中央管理者从本地LOB数据库210请求什么数据以及如何提取数据。在示范实施例中，DCT 620通过首先测试1112看看是否可以从本地LOB数据库210提取由调整阶段1110的第一步骤表示的收集定义对象1104定义的表和列名称，促进了从本地LOB 210提取数据。这一步骤1112用于验证本地LOB数据库210不具有本地数据访问问题，其可能是由于升级、打补丁和手动编辑等引起的对于LOB数据库纲要的变化引起的。如果数据访问步骤1112是成功的，DCT 620过程利用影子数据库522、1102的状态来调整本地数据库210的状态，选择与请求同样多且可用的数据赋予本地数据库210的当前状态。调整阶段的比较步骤1114执行任意处理或者规则比较或者选择声明，以便只选择与当前收集对象1108相匹配的那些数据值。DCT处理620的调整阶段也使用本地影子数据库522、1102来防止冗余数据或之前收集数据的重新发送。在服务器304或客户端302处执行这种重复数据删除过程(de-duplication)。替代地，在除了中心DC 206之外的每一个站点执行重复数据删除过程，以促进在客户端302而不是在中心服务器304平行执行所述过程。附加的替代实现是利用本地LOB API (例如快速订购XML API)来执行在步骤1112和1114中提供的类似数据过滤功能。在典型实施例中，DCT 620可以使系统200能够从LOB数据库210提取数据，将数据复制到本地影子数据库1102，提取所要求的数据并且对其进行封装以便移交至消息传输层318。DCT 620可以经由Java数据库连接性(JDBC)连接或一些其他LOB专用应用程序编程接口(API)例如用于快速订购QBXML)与本地LOB数据库210相连。DCT 620可以调度为经由收集调度器过程创建的定时器618来运行，通过JVM和启动过程504来自动开始所述收集调度器过程。因此，当需要或请求时可以激活DCT 620。一旦激活了 DCT 620,DCT620每当运行以执行步骤1110的当前动作的最近定义时就检索当前最近的调度定义。每当DCT 620运行时，其可以从本地LOB数据库210提取1112所请求的数据，并且在将所请求的数据与先前收集的数据进行比较的同时准备影子数据库1114，以便确定哪个数据值是最后收集时间以来新的、改变的或删除的。使用由定义对象1108定义的规则来完成收集什么的决定，例如但是不局限于新的，新的加上变化的数据，包括新的、变化的和删除的数据的所有数据等。比较步骤114促进了对于最后一次收集过程以来本地LOB数据库210中变化的识别，并且通过只提取和发送特定请求的新信息集合来使得过程1100更加有效。DCT 620也可以在处理时将状态信息214本地和远程地日志记录到服务器，或者将数据插入到影子数据库1102中。为了日志记录状态数据214，DCT 620可以发送由服务于元日志服务器228的收听者节点检索的日志消息，元日志服务器将日志消息插入到中央日志数据库230中。日志条目允许中央管理者产生报告226，对于任何远程产生的错误设置警报，并且提供前期主动管理来解决任何潜在的问题。此外，在发生任何问题的情况下(例如本地数据库丢失 /移动、破坏或锁定等)，DCT 620向元日志收听者节点发送任意客户端java异常消息进行日志记录。注意，也作为远程数据收集过程的一部分发送本地日志条目，其提供了移交或突然远程数据收集过程。可以集中地管理226日志文件并且进行报告，以识别可以利用定义或更新变化修理的任何问题。DCT过程1100可以使用多种实现方式来运行，以使得可以从中进行摘要并且与特定LOB数据库引擎无关地运行,例如但是不局限于SQL服务器、Oracle、MS Jet、Paradox、Dbase等等。这种数据库(“DB”)摘要层可以在调整步骤1112、1114中实现，以遮蔽本质LOB数据访问层或影子数据库存储机制中的不足。例如，LOB数据访问可以提供对于列或表的非标准名称，或者截断这些名称并且返回不正确的列性质，例如对于非空列返回NULL。DCT数据访问包装层使用动态SQL声明产生对象来处理和校正这些条件，所述对象客观地表示了本地LOB数据库或影子数据库的摘要视图。例如，Paradox JDBC驱动器可能缺少特定JDBC特征，但是其仍然可以由DCT过程支持，因为DCT DB摘要层实现了源和目的地收集数据库作为对象。DCT过程使用这种数据对象表示来驱动SQL声明的正确产生，以确保其利用本地和影子数据库正确操作，以提供独有的数据库独立能力。此外，DB对象摘要层用于提取当前的LOB数据，并且在不依赖于本地数据库引擎特征集合的情况下，使用收集定义对象中的规则将其与影子数据库522的本地数据(即最新收集的数据)进行比较。可以通过现有本地LOB数据库210内存储的分离数据库或者在分离安装的影子数据库522、1102(对于本地PC或用户透明)内存储的分离数据库来执行这种比较。数据库摘要层也以每个表为基础支持在分离的影子数据库522、1102中创建或重新创建整个本地LOB数据库206。在一个实施例中，数据库摘要层经由步骤1112、1114，利用当前LOB数据的全新副本来刷新(flush)当前临时本地影子数据库522、1102。在通信损失、分组讹误或DC 206操作损失的情况下，数据库摘要层还支持以时间戳为基础从本地数据存储单元重新发送数据。因此，DCT过程1100具有由真实的自动远程和突然远程LOB数据收集过程所要求的一组鲁棒的数据连接、摘要、比较、重传、重发和错误处理特征。在典型的实施例中，经由步骤1112、1114实现的比较功能对多种传统比较功能和大量的特定“边缘情况”进行处理，所述“边缘情况”是由于多个LOB应用的变换导致的，并且示出了如何在各种数据库和数据纲要版本和变化中实现。经由定义对象1104提取现有LOB数据1110、1112并且将其与由中央配置服务器定义的规则进行比较的能力使得远程数据收集过程变得容易且无需DBA或IT管理。比较过程可以使用分离的比较元数据表和目的地或数据存储表的关键设计概念。这些数据表的结构使得能够在客户端侧迅速且高效地执行比较过程，每次运行收集时将这些表结构(即纲要)调整或更新为当前收集定义。注意，DCT收集过程1100可以使用比较功能来执行定义文件中的表列与源和影子数据中两者中的现有或本地本地表列之间的调整。这种技术允许DCT过程1100安全地捕获新请求的数据，例如但是不局限于新的列或值，并且允许当本地数据库已经改变其纲要定义时通知中央服务器。例如，比较和调整过程可以通知中央管理者已经更新了特定的本地LOB应用，以及现在存储之前没有收集的附加数据。这种表定义的比较允许DCT过程1100动态地适应丢失或添加的列，并且在不中断当前收集运行的情况下将当前本地纲要调整为收集定义请求。比较功能1114促进了调整阶段过程，其防止了微小的数据库纲要变化引起错误循环，其结果是连续数据检索和错误报告的循环，将使得DC 206服务器被压垮(overwhelm)。结果，可以向客户端安全地提供数据，同时使得用户心平气和且有信心微小的应用程序或数据库修补不会停止数据收集的流程。附加的错误和异常处理代码允许收集过程适应本地数据库条件，例如在源数据库之内单个行的损坏，或者在对于本地LOB数据库206、主关键字或其他纲要元素改变的情况下防止影子和远程数据中心数据库的损坏。因此，每当DCT过程1100运行时，比较功能可以检索在本地(例如当前的本地LOB数据库纲要210)源表中存在的当前数据库列定义，以确保利用影子数据522、1102和收集规则1108调整本地变化。这种特征实现了数据收集可靠性，并且防止了由于在本地LOB数据库206和大范围的独立远程站点上数据内容中的变化导致的错误。一旦进行了调整过程，最终结果是收集定义的表和列对象的消减表示1108。另一个独有特征是使用这些对象动态地产生本地SQL脚本，本地SQL脚本执行源数据检索和影子数据库插入/比较功能，而不依赖于在本地LOB数据库210内包含的触发文件、存储的过程或其他数据库软件逻辑。DCT过程1100也可以利用动态源和/或影子数据库驱动器，其可以嵌入到定义中来辅助SQL脚本的产生。这种特征允许灵活性和交叉数据库实现，来利用在卖方之间可能发生的数据类型、关键字或其他数据库属性来处理变化或不一致性。注意，DCT数据库摘要过程不允许在源数据库上执行任意的SQL声明。DCT脚本产生和执行引擎只执行选择类型SQL声明，从而确保了所述收集是不会损坏现有的LOB数据库210的只读过程。还应该注意，因为通过收集定义对象1104中定义的参数来驱动脚本产生，脚本产生是自动的。最后，这种分层且摘要的设计允许DCT过程1100同时从多个客户端或数据库收集。这在主控环境下是有用的，其中单个服务器可以主控LOB过程的多种实现，或者其中单个LOB应用可以使用多个数据库，或者其中远程站点可以使用多个LOB应用，并且希望从所有的LOB数据源收集。从本地LOB数据库206或及机器的实现规范中提炼DCT过程1100，从而允许单个本地代理执行整个数据收集任务集合。最后，应该注意的是通过使用 JDBC或本质LOB API，收集过程可以与多个源数据库独立地工作，源数据库本地的位于机器或者位于可以使用操作系统(ο/s)文件系统的远程机器、网络套接字层、或者包括因特网网站服务调用的其他API来检索在LOB数据库内存储的数据。数据消息发送者(DMS)过程704可以使用消息控制器908对象来将收集的数据封装到可以适合由收集定义对象1104规定的分组大小的数据消息中，收集定义对象1104可以进行调谐以匹配当前传输层和节点发送者操作环境。DMS对接收源数据、确定当前数据比特大小和利用消息控制器908将数据封装成数据消息(将其发送至DC206)进行内部处理。DMS还通知正确的类以使用可选数据加密过程706来开始或停止对于数据消息的加密。一旦DMS 704已经具有配置大小的数据消息，其将所述消息传递给收集节点发送者606，收集节点发送者606然后利用传输空间318到达中央DC 206处的数据整合节点收听者322。再次需要注意的是由于使用消息控制器908摘要层，客户端和DC处的所有数据节点简单地知晓作为对象的数据消息的存在，而不知晓任何内部细节。这种类型的摘要实现允许将实际消息格式化为与下面的通信传输层318无关。在典型实施例中，系统200可以适配于使用许多其他传输层技术，包括其他对象代理或中间件产品。可以通过传输层318处理实际的消息传递和传输，包括在通信故障的情况下肯定应答、消息继续、自动排队、串行化和重试处理。将任何适当的传输误差记录到本地日志214中，用于随后收集到集中误差日志230中进行进一歩的分析和报告。图12是各种数据消息发送者704的子类别类型的表。因为数据收集过程200的关键概念是经由消息控制器层908提供的摘要，这里为了清楚性和设计完整性提供了数据消息发送者类别和子类别1200的细节。具体地，可以消息类别处理器周围建立收集过程，消息类别处理器理解如何创建如图2所示的数据或消息条目，但是不局限于此。例如，示范的消息发送类别类型可以包括数据消息发送者、数据行发送者、快速订购消息发送者、表数据发送者等。图13是远程数据收集系统200的服务器侧304的图。注意，图13中所示的DC 206只是示例实现，并且本领域普通技术人员应该认识到通过本发明也可以预期其他实现。可以将所述过程的服务器侧304看作是实现与客户端侧302的节点对的镜像集合，但是具有一定程度的扩展与整合过的数据库服务器222、224的替代配置一起向客户端站点的消息排队，同时仍然維持在主DC 206处的中央定义、更新和日志处理数据库。可以将远程数据收集系统200的服务器侧304或DC 206概略地如图13所示建模。注意，未示出标准的JMS 服务和JVM代码。图14是准备好的客户端队列对象1400的图。通常，系统200的服务器侧304可以实现对于远程客户端302的节点收听者316、222的匹配集合。此外，服务器还对节点收听者316、322进行扩展，以提供在客户端侧302上不需要的增强特征。这些服务器侧304扩展可以包括从服务器专用配置文件加载它们的数据库和JMS连接的能力，服务器专用配置文件允许管理者通过改变新配置设置来迅速且容易地开始单个集合或多个集合的服务器示例。定义和更新服务器216、218的收听者扩展也引入了称作准备好客户端队列(“RCQ”)对象1400的另ー个关键特征，准备好客户端队列对象可以存储在服务器上共享的节点状态308对象中。RCQ1400可以由更新和定义服务器使用来促进对来自多个同时连接的远程代理202的消息请求的处理。因为服务器节点发送者/收听者对的每ー个部分按照分离的思路操作，RCQ 1400可以用作同步点，这些独立的思路可以通过所述同步点通信并且调整它们的操作。尽管许多客户端代理202可以同时发送定义请求消息，当定义服务器收听者节点316进入并且将它们的当前客户端状态1402信息设置为RCQ 1400吋，定义服务器收听者节点得到这些请求的每ー个。相反地，定义服务器发送者节点312监视RCQ 1400，并且当其准备好处理下ー个客户端状态时将每ー个客户端的状态信息1402弹出队列。按照这种方式，服务器的任一半都不会等待另一半。相反，它们同时尽可能快地操作。更新服务器218使用类似的模型处理更新请求消息。此外，定义和更新服务器216、218使用RCQ1400来处理客户端状态1402。数据和元数据日志服务器上的收听者节点316不需要实现RCQ，因为它们可以直接从传输空间318消息队列404接收客户端数据消息，立即从所述消息提取数据，并且对其进行处理以插入到收集或日志数据库中。图15是对收集定义对象1104属性和元数据1500的一些进行描述的表，可以将其存储在配置和定义数据库212中。收集定义对象通过定义LOB数据库206与什么相连、从哪个表和列进行收集、以及用于收集的实际记录(例如新的、只有更新的、所有的等等)或者替代地使用哪个API方法来访问LOB数据206，促进了告知代理202收集和发送什么数据可以将这些定义作为记录存储在定义服务器数据库212中，定义服务器数据库可以包含 对于多个站点、站点组、ー组站点处的多个LOB应用以及多个收集客户端的定义。可以将定义记录存储在定义服务器中，其中针对每个本地LOB数据库206每个Zor (或者远程收集客户端的类型)具有ー个定义记录，或者可以将其存储在表中以从中进行收集和/或针对特定的“边缘情況”纲要变化或者本地操作条件来进行收集。可以通过提取关键LOB和数据库性质、并且将关键设置存储在配置数据库中来实现所述定义。因此，所述定义提供了中央数据仓库，以甚至在多个Zor或者商业模型以及多种类型的LOB应用之间控制所有的远程数据收集配置。收集定义消息对象1104包含许多详细的数据定义，所述详细的数据定义在DCT过程的步骤1110、1112和1114期间驱动远程数据收集过程的配置和操作。图16是定义服务器216的图。每ー个远程客户端代理202可以通过在远程代理启动时向定义服务器216发送定义请求消息来检查其定义，在定义服务器216处收听者节点316对包含客户端当前状态的定义请求消息进行处理。定义服务器收听者节点316使用消息控制器908来提取远程代理202的当前客户端状态1402，并且将状态放置于节点状态RCQ 1400中。定义发送者312过程从RCQ 1400中弹出客户端状态1402，提取特性，并且通过使用一组存储的过程从定义数据库212中直接检索当前客户端定义来处理客户端定义请求。定义发送者使用客户端状态信息来构造所存储的过程(SP)SQL声明，在定义数据库212上执行所述声明。SP作为“串”(即，定义对象的串行化版本)返回针对特定客户端的匹配定义。服务器节点响应于定义请求消息，始終将定义消息发送回客户端。也需要注意的是，由于使用消息控制器908，定义服务器发送者节点不知晓定义规则对象1104和定义消息1002的细节。因此，定义的中央存储和消息的使用允许单个管理者通过简单地管理中央定义配置数据库212，容易地监视和指导每个远程代理202的操作。管理目标的远程客户端可以响应于定义请求消息，经由收集定义对象1104接收包含新的或改变的收集指令的新定义。通过更新过程使用类似的体系结构，允许将当前收集代理代码文件发送至远程站点，容易地更新远程代码。图16示出了在已经从RCQ 1400弹出客户端状态1402之后，如何使用数据库存储的过程(“SP”)来处理定义消息。图17是数据整合服务器(DCS)过程1700的图。图18是DCS过程1700的附加图。在典型实施例中，DCS过程1700是服务器侧过程224，其中至少ー个DCS服务器1702可以构建用于从每一个远程站点处的远程客户端代理202收集数据。在ー个典型实施例中，DCS1702可以是通过Zor或客户端自我控制的，同时其他服务器216、218、228可以位于DC206。DCS 1702促进了对于客户端侧数据消息的处理，其可以包含LOB收集数据210，并且将数据消息插入到合适的中央LOB整合数据库222中。在ー个典型实施例中，数据通信可以是单向的(即从客户端到服务器)；然而定义和更新消息可以双向流动。在替代实施例中，可以将数据发送回远程客户端。替代地，过程1700可以使用DCS 170上的数据节点发送者来利用双向数据通信过程。可以使用可扩展消息模型来支持这种类型的特征。还应该注意的是，在典型实施例中，可以将传输层空间318实现为利用JMS服务来提供由客户端202发送的任何消息的“有保证的递送”。例如在已经将客户端与中央DC JMS服务断开的情况下，JMS层可以重试或重发消息。一旦服务器侧JMS服务接收到数据消息，将所述消息放置于合适的服务器JMS队列404中，其中在通过合适的服务器队列节点收听者1704消费之前，所述 队列等待。图18示出了可以是使用与客户端侧实质上类似的摘要消息控制器体系结构实现的数据整合器1706，以确保与消息格式和类型无关地处理消息。数据整合器1706可以从数据整合队列收听者节点1704接收消息，然后其利用数据消息定义处理器1800来识别应该将当前消息数据存储在哪个整合数据库222和表中。在典型实施例中，可以根据需要通过数据解密处理器1802或QB XML消息剖析器1804将附加的消息处理提供给数据整合器1706，其结果是正确格式化的数据记录用于插入到合适的整合数据库222中。注意，存在至少两种类型的数据消息。数据消息可以包含SQL数据库记录数据，或者数据消息可以包含XML数据记录，所述XML数据记录可以是来自于LOB网站服务区或者是从快速订购的LOB应用提取的数据。数据库数据消息可以包含内部数据表定义，可以将所述内部数据表定义作为XML存储在消息内。数据表定义处理器1800读取在数据消息内的XML数据，以识别在当前数据消息内包含哪个表和列。整合器1706然后可以从整合数据库222、或者从高速缓存定位和加载相同的数据库表示，并且调整来自所述消息和实际整合目的地表的列。然后，整合过程1700调用“颠倒(upset)”功能进行更新或插入，“ upset”可以是基于调整数据的已存储过程(“SP”)声明。将颠倒的SP与在数据消息中存在的任意參数或列构造在一起。将任何丢失的列设置为空(“NULL”)，并且丢弃所述消息中额外的列。在替代实施例中，可以将额外的客户端信息存储在整合服务器222中用于稍后使用。可以在产生数据消息中的丢失或额外列的示例场景可能是由于以下原因引起的L0B应用208和数据库210中的差异，或者对于LOB的版本号、修补或更新，或者客户端专用LOB数据库210纲要变化。在一个实施例中，对于快速订购数据消息，QBXML数据消息包含当通过QB API从远程客户端的QB应用数据库检索时的原始QBXML。这种独有的QB特征使得XML消息剖析器1804的使用成为必要，以便将QBXML格式转换为存储器内数据库对象表示，用于快速地插入到合适的整合数据库中。在快速订购XML消息剖析器1804的情况下，不需要检查XML消息的结构中包含的丢失或额外的列，因为当从本地QB数据文件提取时，通过快速订购API创建和验证。一旦数据整合器1706具有了合适的数据库插入对象，将来自快速订购或任意其他LOB应用的最终收集的数据回路通过，并且重复地调用颠倒存储的过程以将远程客户端数据存储在合适的整合数据库222中。替代地，可以将附加的数据转换和数据仓库类型处理应用于包括映射到标准化列中的远程LOB列名称的整合数据中，以促进正确和有效的报告206或者更快速的预计算统计和KPI用于可执行控制板。图19是元数据或日志服务器228过程的图1900。元数据或日志服务器过程1900实质上可以像DCS过程1700那样类似地执行。元数据服务器过程1900获取客户端日志消息，并且将其插入到服务器侧数据库230、1902中，以提供针对所有客户端代理202状态消息的中央数据仓库。元数据服务器228使用消息控制器908来提取消息类型和值，并且将其传递至颠倒存储的程序中，以将其放置于元数据日志数据库230、1902中。在异常消息包含更多信息的情况下，所存储的过程因而具有更多參数来进行构造。利用在ー个数据库中集中的所有状态消息，管理者可以产生通知，警告或者报告226以迅速有效地识别可能有问题的任意远程代理。在这种情况下，通过改变更新号码、向其发送新客户端版本和/或使 用DC 206处的新定义或其他动作来发送重启消息来针对性进行校正动作。图20是更新服务器218的图。在典型实施例中，更新服务器218功能可以是自动自更新远程数据收集系统200的部件。更新服务器218促进了从中央管理配置页面改变远程站点处的代码和收集配置两者。可以从中央点、或者位于DC206处的更新数据库来管理更新发布。更新数据库2000存储对更新属于哪一个客户端或客户端组进行定义的元数据。在ー个典型实施例中，可以基于针对代理的远程LOB应用和独有商业概念需要(例如地域、等级、同年龄组等)的代理202实现的特定需要来组织远程客户端的分组。由在更新数据库中存储的元数据进行编码的等级规则提供了对于多种远程客户端202的新版本的版本描述、分组、更新和离开。更新规则还允许向单个客户端、一组客户端或商业概念内的所有客户端发布更新和/或使用单个的数据库记录或更新号码(UN)向每ー个客户端发布更新。使用更新号来将远程代理202与代码能力的匹配允许对于交叉客户或整个系统200的代码更新。在通过ー组更新规则在数据库中识别出发布时，可以设置目标为按照自动方式分配给现有客户端202。将对什么进行封装加以定义的版本元数据作为“版本”存储在更新数据库212，2000中。一旦识别出目标的列表，通过远程客户端202使用更新请求消息来请求被更新的内容。更新服务器收听者节点316接收消息，并且将客户端状态放置于准备好客户端队列中1400。相分离地，更新服务器发送者节点312获取下一个状态1402，并且将客户端的当前更新号码与由更新数据库212，2000中的管理者定义或设置的客户端的可用更新号码进行比较，如果需要，从文件系统220中检索代码和.conf文件的新版本。注意，可以存在ー个更新服务器，其中每个“受管理概念”或ZorID具有一个或多个准备好的客户端队列308，1400。更新服务器可以触发更新的.conf文件和或java代码jar文件的发送。然后通过更新消息控制器908将新的客户端更新封装到更新消息中，并且更新服务器节点发送者312针对识别的远程客户端的目的地主题对其进行处理。图21是DC服务器文件系统2100的图。在典型实施例中，更新数据库212使用元数据记录2104的概念来通过唯一的更新号码(“UN”)将多个部件(例如jar文件，.conf文件)2106逻辑地封装为远程代理“版本”，所述更新号码用于定向远程代理202的ー个或多个。元数据概念使用更新号码(“UN”)来指向在本地服务器文件系统2102中存储的特定组的文件，在所述本地服务器文件系统中，单个或多个集合的文件可以构成远程系统204的新更新。文件系统2102可以存储配置文本文件(例如.conf文件)和java代码文件(例如.jar文件)的多个版本，其构成了由更新数据库212逻辑地组织的虚拟更新数据库220。这些更新212可以用于配置和/或控制远程客户端侧的代理202。可以在更新数据库212、2000中使用更新号码来对系统更新进行版本控制。UN版本化使得能够使用称作版本化文件系统分类加载器(“VFCL”)的定制java分类加载器在客户端侧加载代理代码的特定版本。这ー过程使得启动器能够将代码文件的正确更新号码版本加载到存储器中，并且执行所述代码文件。此外，VFCL可以在不維持锁定到.jar文件上的文件系统的情况下加载java类，在仍然运行于远程客户端机的Java虚拟机(JVM)的同时促进了客户端202的更新。这允许使用没有被文件系统锁定的旧的客户端文件，允许通过新的更新版本来重写所述旧的客户端文件。VFCL使得系统能够按照自动和无人监管模式在远程站点处运行，并且可以通过集中的配置站点使用UN来维护。VFCL还按照除了缺省的java系统分类加载器搜索方法之外的预定顺序或者方式来捜索分类。此外，VFCL可以忽略CLASSPATH本地环境变量设置选项，而是代替地按照预定方式加载jar文件，例如从java分类的最高可用版本到最低可用版本。这允许客户端202存储和使用代码文件的多个版本，例如加载由.conf文件规定的当前版本，并且如果当前版本丢失或中断则附加地退回到文件的前ー个版本。 图22是用于本发明的远程数据收集的客户端和/或服务器而操作的计算机2200的图。计算机2200可以是数字计算机，在硬件体系结构方面其通常包括处理器2202、输入/输出(I/O)接ロ 2204、网络接ロ 2206、数据存储器2208和存储器2210。部件(2202,2204,2206、2208和2210)经由本地接ロ 2212通信地耦合。本地接ロ 2212可以是例如但是不局限于ー个或多个总线或者其他有线或无线连接，如现有技术已知的。本地接ロ 2212可以具有附加的元件(为了简单起见将其省略)，例如控制器、缓冲器(高速缓存)、驱动器、转发器和许多其他元件以实现通信。另外，本地接ロ 2212可以包括地址、控制和/或数据连接来在上述部件之间实现适当的通信。处理器2202是用于执行软件指令的硬件设备。处理器2202可以是任意定制或商用的处理器、中央处理单元(CPU)、与计算机2200相关联的几个处理器中的辅助处理器、基于半导体的微处理器(以微芯片或芯片集合的形式)或者通常用于执行软件指令的任意设备。当计算机2200操作时，处理器2202配置用于执行在存储器2210中存储的软件以与存储器2210通信数据，以及根据软件指令对于计算机2200的控制操作。I/O接ロ 2204可以用于从ー个或多个设备或部件接收用户输入和/或向一个或多个设备或部件提供系统输出。例如，可以经由键盘和/或鼠标来提供用户输入。可以经由显示设备和打印机(未示出)来提供系统输出。例如，I/o接ロ可以包括串行端ロ、并行端ロ、小计算机系统接ロ(SCSI)、红外(IR)接ロ、射频(RF)接口和/或通用串行总线(USB)接ロ。网络接ロ 2206可以用于使得计算机2200能够在网络上通信，例如与客户端等。网络接ロ 2206可以包括例如以太网卡(例如，lOBaseT、快速以太网、G比特以外网)或者无线局域网(WLAN)卡(例如802. lla/b/g/n)。网络接ロ 2206可以包括地址、控制和/或数据连接以实现网络上的适当通信。数据存储単元2208可以用于存储诸如配置数据等之类的数据。数据存储単元2208可以包括易失性存储元件(例如随机访问存储器(RAM，例如DRAM、SRAM、SDRAM等))、非易失性存储元件(例如ROM、硬盘驱动器、磁带、⑶ROM等)及其组合的任ー个。此外，数据存储単元2208可以合并电、磁、光和/或其他类型的存储介质。在一个示例中，数据存储单元2208可以位于计算机2200内部，例如与计算机2200中的本地接ロ 2212相连的内部
硬盘驱动器。存储器2210可以包括易失性存储元件(例如随机访问存储器(RAM，例如DRAM、SRAM,SDRAM等))、非易失性存储元件(例如ROM、硬盘驱动器、磁带、CDROM等)及其组合的任ー个。此外，存储器2210可以合并电、磁、光和/或其他类型的存储介质。注意，存储器2210可以具有分布式体系结构，其中各种部件位置彼此远离，但是可以通过处理器2202进行访问。存储器2210中的软件可以包括一个或多个软件程序，每ー个软件程序包括用于实现逻辑功能的可执行指令的顺序列表。在图22的示例中，存储器系统2210中的软件包括合适的操作系统(0/S)2240以及ー个或多个程序2242。操作系统2240实质上控制其他计算机程序的执行，并且提供调度、输入输出控制、文件和数据管理、存储器管理以及通信控制和相关服务。操作系统2240可以是以下的任一种Windows NT、Windows 2000、WindowsXP、Windows Vista>ffindows Server(所有都是来自 WA,Redmond 的微软公司)、Solaris(来自CA Palo Alto的Sun微系统公司)、LINUX (或者其他UNIT变体)(来自NC，Raleigh的RedHat)等。另外，根据例如由计算设备的元件执行的动作序列来描述许多实施例。应该理解的是可以通过专用电路(例如应用专用集成电路(ASCI))、通过ー个或多个处理器执行的程序指令或其组合来执行这里描述的各种动作。此外，可以将这里所述动作的顺序看作是完全在任意形式的计算机可读存储介质中实现，所述计算机可读存储介质中存储了相应集合的计算机指令，在执行所述计算机指令时将引起相关联的处理器执行这里所述的功能。因此，本发明的各个方面可以按照多种不同的形式来实现，所有形式都已经落在本发明要求权利的范围内。此外，对于这里所述实施例的姆ー个，例如任意这些实施例的相应形式可以在这里描述为“逻辑上配置用干”以执行所述动作。计算机系统还包括主存储器，例如与总线相连的随机存取存储器(RAM)或其他动态存储设备(例如动态RAM(DRAM)、静态RAM(SRAM)和同步DRAM(SDRAM)，用于存储信息和由处理器执行的指令。此外，主存储器可以用于存储在处理器执行指令期间的临时变量或其他中间信息。计算机系统还包括与总线相连的只读存储器(ROM)或其他静态存储设备(例如可编程ROM(PROM)、可擦除PROM(EPROM)、和电可擦除PROM(EEPROM))，用于存储针对处理器的静态信息和指令。所述计算机系统还包括与总线相连的盘控制器，以控制用于存储信息和指令的ー个或多个存储设备，例如磁盘硬盘驱动器和可移除媒体驱动器、光盘点播机、磁带驱动器和可移除磁光驱动器)。存储设备可以使用合适的设备接ロ(例如，小计算机系统接ロ(SCSI)、集成设备电子装置(IDE)、增强型IED(E-IDE)、直接存储器存取(DMA)或超级-DMA)添加到计算机系统中。计算机系统还可以包括专用目的逻辑设备(例如应用程序专用集成电路(ASIC)或可配置逻辑设备(例如简单的可编程逻辑设备(SPLD)，复杂可编程逻辑设备(CPLD)和现场可编程门阵列(FPGA))。
计算机系统还可以包括与总线相连的显示控制器，用于控制诸如阴极射线管(CRT)、液晶显示器(LCD)或任意类型显示器之类的显示器来向计算机用户显示信息。所述计算机系统包括诸如键盘和定点设备之类的输入设备，用干与计算机用户相互作用并且向处理器提供信息。此外，可以结合显示器来采用触摸屏。例如，定点设备可以是鼠标、轨迹球或定向杆，定向杆用于与处理器通信方向信息和命令选择，并且用于控制显示器上的光标移动。此外，打印机提供由计算机系统存储和/或产生的打印数据列表。计算机系统响应于处理器执行在诸如主存储器之类的存储器中包含的一个或多个指令的ー个或多个序列，执行本发明的处理步骤的一部分或全部。可以从诸如硬盘或可移除介质驱动器之类的另一个计算机可读介质中将这些指令读入到主存储器中。多处理结构的ー个或多个处理器也可以用于执行在主存储器中包含的指令序列。在替代实施例中，硬连线电路可以代替地软件指令来使用或者与软件指令组合地使用。因此，实施例并不局限于硬件电路和软件的任意特定組合。如上所述，计算机系统包括至少ー个计算机可读介质或存储器，用于保持根据本发明的教导进行编程的指令，或者包含这里所述的数据结构、表、记录或其他数据。计算机 可读介质的示例是光盘、硬盘、软盘、磁带、磁光盘、PR0M(EPR0M、EEPR0M、N—EPR0M)、DRAM、SRAM、SDRAM或任意其他磁介质、光盘(例如CD-ROM)、或者任意其他光学介质、穿孔卡片、纸帯，或者具有孔洞图案的其他物理介质、载波(如下所述)，或者计算机可以从中读取的其他介质。在计算机可读介质的任一个或组合上存储的本发明包括用于控制计算机系统、用于驱动实现本发明的设备、用于使得计算机系统能够与人类用户相互作用的软件。这种软件可以包括但是不局限于设备驱动器、操作系统、开发工具和应用程序软件。这种计算机可读介质还包括本发明的计算机程序产品，用于执行在实现本发明时执行的处理的全部或一部分(如果处理是分布式的)。本发明的计算机代码设备可以是任意可编译或可执行代码机制，包括但是不局限于脚本、可编译程序、动态链接库(DLL)、Java类和完整的可执行程序。此外，本发明处理的一部分可以为了更好的性能、可靠性和/或成本而分布。这里所使用的术语“计算机可读介质”指的是在向处理器提供指令来执行时參与的任意介质。计算机可读介质可以采取许多形式，包括但是不局限于非易失性介质、易失性介质和传输介质。例如，非易失性介质包括光盘、磁盘和磁光盘，例如硬盘或其他可移除介质驱动器。易失性介质包括动态存储器，例如所述主存储器。传输介质包括同轴电缆、铜线和光纤，包括构成总线的引线。传输介质也可以采取声波或光波的形式，例如在无线电波通信和红外数据通信期间产生的波。可以在执行对于处理器的ー个或多个指令的序列时包含多种形式的计算机可读介质来执行。例如，所述指令可以最初在远程计算机的磁盘上执行。远程计算机可以将用于实现本发明的全部或一部分的指令远程地加载到动态存储器中，并且使用调制解调器在电话线路上发送所述指令。对于计算机系统本地的调制解调器可以接收电话线路上的数据，并且使用红外发射机将数据转换为红外信号。计算机系统还包括与总线相连的通信接ロ。所述通信接ロ向由网络链接相耦合的双向数据通信，网络链接例如与局域网(LAN)或诸如因特网之类的另ー个通信网络相连。例如，通信接ロ可以是网络接ロ卡，以附接到任意分组交换LAN。作为另ー个示例，所述通信接ロ可以是非对称数字订户线路(ADSL)卡、综合业务数字网(ISDN)卡或调制解调器，来向相应类型的通信线路提供数据通信连接。也可以实现无线链接。在任意这种实现中，通信接ロ发送和接收承载对各种类型信息加以表示的数字数据流的电、电磁或光信号。网络链接典型地通过与其他数据设备的一个或多个网络提供数据通信。例如，所述网络链接可以通过局域网(例如LAN)或通过服务提供商操作的设备提供与另ー个计算机或远程位置演示设备的连接，所述服务提供商通过通信网络提供通信服务。在优选实施例中，局域网和通信网络优选地使用承载数字数据流的电、电磁或光信号。通过各种网络的信号以及网络链接上并且通过通信接ロ的信号是传输信息的载波形式，所述通信接口承载去往和来自计算机系统的数字数据。计算机系统可以通过网络、网络连接以及通信接ロ发射和接收包括程序代码的数据。此外，网络链接可以提供通过LAN与诸如个人数字助理(PDA)、膝上型计算机或蜂窝电话之类的移动设备的连接。LAN通信网络和通信网络都使用承载数字数据流的电、电磁或光信号。通过各种网络的信号和在网络链接上并且通过通信接ロ的信号是传输信息的载波的典型形式，所述通信结构承载来自系统和去往系统的数字数据。所述处理器系统可以通过网络、网络链接和通信接ロ发射通知并且接收包括程序代码的数据。图23-25是根据本发明典型实施例的简档和损失2300、现金流2302和资产负债表2304的图形用户界面(⑶I)屏幕照片。这些屏幕照片2300、2302、2304可以通过计算机2200创建并且可以显示在计算机2200上。替代地，这些屏幕照片2300、2302、2304可以显示在与计算机2200相连的远程计算机上。利用通过上述远程数据收集系统和方法收集的数据，屏幕照片2300、2302、2304提供可视机制来理解数据。例如，示出了相对于特许权的屏幕照片2300、2302、2304。本发明的视觉报告系统的独有元素之ー是创建“可视现金流”表2390，“可视现金流”表能够使得新手用户能够按照清楚的图片格式理解他们的LOB或者可操作数据的影响(例如，将有利数据值显示为绿色，并且显示条指向右侧，而不利的值显示为红色，并且条指向左侧)。这种新颖和独有的格式允许那些不具备专家级会计、商务和操作技能的人们迅速且容易地理解他的单个或整合商业操作的最終結果。注意，设计专利可以应用于所述报告的这一元素。最后，本领域的普通技术人员将认识到所述屏幕照片2300、2302、2304可以适用于其他商业和其他类型的收集数据。屏幕照片2300、2302、2304的每ー个包括多个图标2310，使得用户能够在屏幕照片2300、2302、2304之间进行导航，并且导航至主页或简要页面。屏幕照片2300、2302、2304还包括说明显示信息的日期范围的报告日期、标题和最后完成收集的日期。注意，用户可以修改日期范围和信息类型进行显示，例如通过主页。此外，每ー个屏幕照片2300、2302、2304包括底部的图标，以改变对于年-日期、最近一年、最近一个月等的视图。图23说明了收入综述或者简档和损失报告2300，以使得用户能够监视商业健康。简档和损失屏幕照片2300包括各种商业属性的列表2300(例如，销售、销售货物的成本(COGS)、毛利等)，并且按照表格格式2330将具体条目(例如特许权)与种类平均(即特许权的国家销售平均值或者同年龄组销售平均值)进行比较。这种表格格式2330还示出了在实体值和选定的比较平均值之间的有利/不利(Fav/Unfav)的差。另外，曲线2390显示了上所述差的特定可视条形图。
图24示出了现金流2302，以使得用户能够理解与运行商业相关联的各个方面。现金流屏幕照片2302包括各种商业属性(例如，净收入、应收账款等)的列表2340，并且按照表格格式2350将具体实体(例如特许权)与平均值(即特许权的国家平均或同年龄组平均)进行比较。另外，曲线2390显示了需选定的实体操作值的独有可视现金流条形图。图25示出了资产负债表2304以使得用户能够提供实体与预期的同等比较。资产负债表屏幕照片2304包括资产2360和债务2370的列表，将其在实体和平均值之间进行比较。尽管这里已经參考优选实施例及其特定示例说明和描述了本发明，本领域普通技 术人员应该理解的是其他实施例和示例可以执行类似的功能和/或实现相似的結果。所有这些等价实施例和示例落在本发明的精神和范围之内，并且由所附权利要求覆盖。
权利要求
1.一种远程数据收集系统，包括 与一个或多个数据库相连的一个或多个服务器； 与一个或多个服务器通信耦合的一个或多个远程客户端，所述一个或多个远程客户端的每一个包括与一个或多个客户端数据库通信耦合的远程客户端代理；以及 元数据消息传输机制，配置用于对远程客户端与一个或多个数据库之间的数据进行协调、控制和复制。
2.根据权利要求I所述的远程数据收集系统，还包括 与所述一个或多个远程客户端的每一个通信耦合的定义服务器，其中所述定义服务器配置用于为每一个远程客户端代理提供多个定义，其中所述多个定义对针对客户端数据库中的数据的收集规则进行定义。
3.根据权利要求I所述的远程数据收集系统，还包括 与所述一个或多个远程客户端中的每一个通信耦合的更新服务器，其中所述更新服务器配置用于向所述一个或多个远程客户端代理提供更新。
4.根据权利要求I所述的远程数据收集系统,其中所述客户端数据库包括来自商业线应用和销售点应用之一的数据；以及 所述远程客户端代理包括摘要实现工具，所述摘要实现工具配置用于操作多个数据库类型。
5.根据权利要求I所述的远程数据收集系统，其中所述元数据消息传输机制包括在一个或多个远程客户端与一个或多个服务器之间交换的多种消息类型；以及 其中所述元数据消息传输机制包含格式化的数据，所述格式化数据是使用消息处理器通过远程数据收集系统提炼的，从而能够实现对于消息处理器的未来升级。
6.根据权利要求5所述的远程数据收集系统，其中所述多种消息类型包括数据消息、日志消息、异常消息、更新准备好消息、更新服务器在线消息、更新完成消息、更新中断消息、更新文件消息、更新配置消息、定义请求消息和定义消息。
7.根据权利要求I所述的远程数据收集系统，还包括 在数据收集任务中使用的一个或多个影子数据库，其中所述数据收集任务将数据从一个或多个客户端数据库之一复制到一个或多个影子数据库之一，并且根据请求的收集定义对象来处理所复制的数据。
8.根据权利要求7所述的远程数据收集系统，其中所述数据收集任务包括比较功能，用于响应于所请求的收集定义对象来验证复制的数据；以及发送功能，用于向一个或多个消息处理器进行发送。
9.一种计算机,包括 网络接口 ； 到数据库的连接；以及 与网络接口和所述连接通信耦合的处理器，其中所述处理器配置用于执行远程数据收集代理； 其中所述远程数据收集代理配置用于对数据库和服务器之间的数据进行协调、控制和复制，所述远程数据收集代理利用元数据消息传输机制，通过网络接口与服务器进行通信。
10.根据权利要求9所述的计算机，其中所述远程数据收集代理配置用于从服务器接收多种定义，所述定义对针对数据路中的数据的收集规则进行定义。
11.根据权利要求9所述的计算机，其中所述远程数据收集代理配置用于从服务器接收代码更新。
12.根据权利要求9所述的计算机，其中所述数据库包括来自商业线应用和销售点应用之一的数据；以及 其中所述远程数据收集代理包括摘要实现工具，所述摘要实现工具配置用于操作多个数据库类型。
13.根据权利要求9所述的计算机，其中所述元数据消息传输机制使用Java消息服务; 所述元数据消息传输机制包括在远程数据收集代理和服务器之间交换的多种消息类型；以及 所述元数据消息传输机制包含格式化的数据，所述格式化数据使用消息处理器，从而能够实现对于消息处理器的未来升级。
14.根据权利要求9所述的计算机，还包括 在数据收集任务中使用的影子数据库，其中所述影子数据库与处理器通信耦合，所述数据收集任务将数据从数据库之一复制到影子数据库之一，并且根据请求的收集定义对象来处理所复制的数据。
15.根据权利要求14所述的计算机，其中所述数据收集任务包括比较功能，用于响应于所请求的收集定义对象来验证所复制的数据；以及发送功能，用于向数据库进行发送。
16.一种远程数据收集方法，包括 在远程客户端处接收代理安装包； 初始化代理安装包； 安装服务过程，所述服务过程促进了自动开始启动过程； 加载启动过程，从而安装远程客户端代理的多个部件；以及 通过多个元数据消息与服务器通信，以将来自远程客户端处的数据库的定义数据提供给服务器。
17.根据权利要求16所述的方法，还包括 从服务器接收收集定义； 响应于所述收集定义从数据库提取数据； 将所提取的数据写入到本地影子数据库； 将所提取的数据与本地影子数据库中的数据进行比较；以及 将包括所提取数据的数据消息发送至服务器。
18.根据权利要求17所述的方法，还包括 从收集定义中提取表和列定义；以及 将所请求的表和列定义与数据库、本地影子数据库和服务器数据库的至少一个的表和列进行匹配。
19.根据权利要求16所述的方法，还包括 向服务器发送更新号码； 从服务器接收更新包；以及将所述更新包安装到远程客户端上。
20.根据权利要求16所述的方法，其中所述数据库包括来自商业线应用和销售点应用之一的数据。
21.—种远程数据收集系统，包括 动态创建的一个或多个网络通信端点，用于将多个远程代理与一个或多个中央服务器相连，所述中央服务器包括端点的网络名称空间，动态监测和管理所述端点，并且所述端点提供远程代理和中央数据库之间的实时链接。
全文摘要
本发明公开提出了一种远程数据收集系统和方法，用于按照自动的平台不可知方式通过网络远程地从一个或多个数据库检索数据和数据类型，所述数据包括金融、销售额、市场和运作等。本发明设计为作用于多个LOB应用、数据库卖方和商业模型或商业、以及商业基础设施(各种PC、嵌入式设备和POS设备)和商业过程，同时仍然提供集中能力来自动从多个远程商业站点收集数据。本发明包括与多个远程数据收集代理通信的一个或多个中央服务器。远程数据收集代理设计用于克服现有的要求或限制，因为其能够从范围广泛的商业、多个LOB应用自动地收集远程数据，同时与多个数据库卖方和格式相连接。
文档编号G06F17/30GK102648465SQ201080048475
公开日2012年8月22日 申请日期2010年7月13日 优先权日2009年8月26日
发明者乔舒亚·希克斯, 克拉克·S·吉尔德, 巴托斯·J·亚勒沃斯基 申请人:杰维斯股份公司