专利名称：用于事务流水线分解的方法和系统的制作方法
技术领域：
本发明涉及一种改进的数据处理系统，并且特别涉及一种用于信息处理的方法和设备。还更特别的，本发明通常涉及记录和分析有关于在网络环境中的客户端应用程序和服务器应用程序之间的通信会话性能的信息。
背景技术：
由于电子商务已经产生，企业开始从发展其在万维网上的存在转向在万维网上维护和提高他们的电子商务操作。为了有效地与其它电子商务业务、诸如电子商务竞争，大多数电子商务企业需要提供高质量的业务以及专业的外观。现在有多种商用产品和业务可以通过测试Web站点功能和收集测量数据或量度的性能对Web站点的特征进行监视。
客户对电子商务的满意度的重要因素就是客户在进行电子商务交易时所经历的响应时间。如果用户感觉电子商务交易、诸如通过Web站点购买产品相对较慢，那么该用户就会对该站点不满意，并且会通过其它站点进行随后的购买。大多数电子商务想要确保客户接收到适当的响应时间，并且为了确定响应时间和用户可能会经历的其它业务质量特征，必须收集电子商务操作的量度性能。尽管面向资源的量度是确定电子商务设备的操作性能的重要量度，诸如服务器负荷因数和带宽利用，但是这些量度并非必须提供所谓的端到端响应时间，而响应时间才是用户对该电子商务设备的直接观察。因此已经开发了各种方法，通过对用户通过电子商务设备会请求的典型交易进行仿真来测量端到端的响应时间。
虽然发现典型用户的电子商务交易的平均端到端响应时间可以提供关于是否需要提高该响应时间的向导，这种信息通常不足以确定电子商务设备应该被修改的方式，以提高业务质量。尽管许多Web站点由相对简单的服务器配置支持，但是许多电子商务操作已经变得复杂。从用户的角度看，在Web站点上进行简单的购买可能只是单个事务。从操作者的角度看，用户与电子商务设备的交互会话包括一组通过许多不同应用的操作。换言之，单个用户的交互操作可能包括一组事务，也称为事务流水线。电子商务企业的操作者需要关于沿事务流水线的每一事务的信息，以改善较差的用户交互性能。
因此，有利地可以提供一种由于将事务流水线的操作分解成离散事务的方法和系统，从而可以收集在电子商务中关于许多事务中每一事务的信息。
发明内容
提供一种用于分解事务流水线(transaction pipeline)的方法、系统、设备和计算机程序产品，其通过捕获关于在事务流水线内完成事务的量度数据(metric data)，诸如在事务流水线的每一阶段完成事务所需要经历的时间。在一组响应于资源请求事务的服务器中有一组代理。两个或多个服务器实质上可逻辑地划分到一个事务流水线中，其中如果上游服务器启动随后的事务到下游服务器，以在下游服务器完成前面的事务，那么该上游服务器就在该下游服务器之前。在事务流水线中，每一代理都关联着服务器。代理收集关于由该代理启动的事务的量度数据，将其定向到与每一代理相关联的服务器的下游服务器。
在所附的权利要求书中陈述了本发明的新颖特征。当连同该附图一起阅读的时候，通过参照下面的详细描述，可以最好地理解本发明本身、进一步的目的、以及其优点，其中图1A描述了其中可以实施本发明的典型的分布式数据处理系统；图1B描述了可以在其中可以实施本发明的分布式数据处理系统中使用的典型计算机体系结构；
图2的方框图描述了数据处理系统的网络，其包括沿事务流水线与中央服务器协同工作的半自动或自动代理的构架；图3的流程图描述的过程是使用事务流水线分解(TPD)代理配置特定的事务流水线，以能够收集事务流水线的TPD量度数据；图4的流程图描述的过程是为特定的事务流水线收集将TPD量度数据进行集中收集；图5的流程图描述的过程是为特定的事务流水线收集将TPD量度数据进行集中分析；图6的流程图描述的过程是特定事务流水线的特定阶段的TPD代理接收和处理来自TPD中央服务器的命令；图7的流程图描述的过程是特定事务流水线的特定阶段的TPD代理收集和存储TPD量度数据；图8的流程图进一步详细描述了如图7中所述，TPD代理获得TPD量度数据的过程；图9的方框图描述了数据收集过程，其中TPD量度数据在被转发到中央服务器之前，从TPD代理上传到主TPD代理；图10的方框图描述的范例是根据本发明的实施例，使用沿事务流水线的一组TPD代理收集TPD量度数据；和图11的方框图描述了特定网络拓扑中的一组结点，以及排序后的一组事务，其代表该网络中的事务流水线。
具体实施例方式
通常该装置可以包括或涉及本发明，包括广泛的各种数据处理技术。因此，在详细描述本发明之前，作为背景技术先描述分布式数据处理系统中的硬件和软件组件的典型组织。
现在参照附图，图1A描述了数据处理系统的典型网络，其分别可以实施本发明的一部分。分布式数据处理系统100包含网络101，其是可以用来在各种装置与分布式数据处理系统100中连接在一起的计算机之间提供通信链路的媒体。网络101可以包括永久连接，诸如线缆或光学纤维电缆，或通过电话或无线通信进行的临时连接。在所说明的范例中，服务器102和服务器103连同存储单元104一起连接到网络101。另外，客户机105-107也连接到网络101。客户机105-107和服务器102-103可以通过各种计算装置表示，诸如主机、个人计算机、个人数字助理(PDA)等。分布数字处理系统100可以包括另外未示出的服务器、客户机、路由器、其它设备以及对等体系结构。
在所说明的范例中，分布式数据处理系统100可以包括因特网，并且网络101表示世界范围的网络和网关，其使用各种协议与其它网络通信，诸如简便目录存取协议(LDAP)、传输控制协议/网际协议(TCP/IP)、超文本传输协议(HTTP)、无线应用协议(WAP)等。当然，分布式数据处理系统100也可以包括多个不同类型的网络，诸如内联网、局域网(LAN)或广域网(WAN)。例如，服务器102直接支持客户机109和网络110，其包括无线通信链路。网络支持的电路111通过无线链路112与网络110连接，并且PDA113通过无线链路114与网络110连接。电话111和PDA113也可以使用适当的技术通过无线链路115在他们自己之间传送数据，诸如BluetoothTM无线技术，以创建所谓的个人区域网(PAN)或个人随意网络。通过相似的方式，PDA113可通过无线通信链路116向PDA107传送数据。
本发明可以在各种硬件平台上实施；图1A只是意欲作为范例说明异类计算环境，并不作为对本发明体系结构的限制。
现在参照图1B，该框图说明了数据处理系统的典型计算机体系结构，诸如图1A中所示的这些，本发明可以实施于其中。数据处理系统120包含一个或多个连接到内部系统总线123的中央处理单元(CPUs)122，该总线123连接着随机访问存储器(RAM)124、只读存储器126和输入/输出适配器128，其支持各种I/O装置，诸如打印机130、磁盘单元132或其它未示出的装置，诸如音频输出系统等。系统总线123也连接着能够接入通信链路136的通信适配器134。用户接口适配器148连接着各种用户装置，诸如键盘140和鼠标142，或其它未示出的装置，诸如触摸屏、指示笔、麦克风等。显示适配器144将系统总线123与显示装置146连接。
本领域的普通技术人员会理解的是，图1B中的硬件可以根据系统实施方式而变化。例如，系统具有一个或多个处理器，诸如基于IntelPentium的处理器和数字信号处理器，以及一个或多个类型的易失性和非易失性存储器。除了图1B中所示的硬件之外，另外也可以使用其它周边设备，或代替其使用。换言之，本领域的普通技术人员在Web支持的或网络支持的电话和具有完整功能的桌面工作站中是不会找到同样的组件或体系结构。所描述的范例并不意欲表明对关于本发明体系结构的限制。
本发明除了能够在各种硬件平台上实施外，也可以在各种软件环境中实施。可以使用典型的操作系统来控制每一数据处理系统内的程序执行。例如，一种装置可以运行Unix操作系统，而另一装置包含简单的Java运行环境。代表性的计算机平台可以包括浏览器，其是熟知的用于访问各种格式的超文本文档的软件应用，诸如图形文件、字处理文件、Extensible Markup Language(XML)、HypertextMarkup Language(HTML)、Handheld Device Markup Language(HDML)、Wireless Markup Language(WML)以及各种其它格式和类型的文件。因此应该注意到，认为图1A中所示的分布式数据处理系统完全能够支持各种对等子网络和对等业务。
如上所述，本发明可以在各种硬件和软件平台上实施。更具体地，虽然本发明涉及一种分解事务流水线的技术，例如电子商务设备中的服务器应用程序链，以获得比典型的现有技术方案更详细的信息，现有技术获得的是用户交互的端到端响应时间。本发明的技术能够在试图分离处理瓶颈和潜在故障中，对事务流水线内每一部分或“转发”的统计行为进行分析。换言之，所收集的信息应该在确定和分离减缓或其它问题、以及确定潜在补救中用作向导。现在参照其余附图更详细的描述本发明的技术。
现在参照图2，该方框图描述了根据本发明实施例的数据处理系统的网络，其包括沿事务流水线的与中央服务器协同工作的半自动或自动代理。从用户的角度，事务可以完全就是单用户请求的操作。从技术的角度，事务可以看作两个实体之间的一组通信协议的作用。
事务流水线包括一组实质上排序后的一个或多个事务，每一事务看作该流水线阶段的表示。在事务流水线内的每一阶段，为特定用户的交互或请求进行和/或完成一个或多个事务。例如，当用户从服务器请求Web页面的时候，该用户的请求表示原始事务，其可以启动一组一个或多个必须完成的事务，以完成该原始请求。因为原始服务器可能不会控制被请求以完成原始请求的所有资源，该原始服务器可能需要联系表示另一事务的另一服务器，并且该第二服务器可能需要向数据库引起提交查找请求，这又是另一事务。另外，有可能与该另一事务并行地，第一服务器可能需要对向用户提供的服务进行收费，因此第一服务器可以连接金融机构的服务器，因而启动了另一事务。我们可以理解，单用户请求可以快速散开，请求完成多个事务。
虽然词语“事务流水线”可以用来描述该用户请求所必须的一组事务，但是该组事务并非必须是线性序列的事务，而可以分支成一个或多个事务流水线或流，以包括多个事务的事务网；有时候，该事务流可以并行工作，而并非是严格地串行。事务流水线可以看作一种特殊情况下的事务网，其中事务流程基本上是线性的，而事务网可以看作更一般的情况，其中事务流程可以分支成为多个事务流。下面使用词语“事务流水线”作为通用词语，而只有在需要在事务流水线与事务网之间进行区别的时候才使用词语“事务网”。
包括事务流水线或事务网的事务可以实质上进行排序。如上所述，每一事务流水线阶段随后可以从另外的事务流水线阶段启动另外的事务。因此，对从原始事务得到的事务存在顺序或流程。从原用户请求到最后阶段事务流水线的那些另外事务的服务器请求流程可以被描述为“下行”穿过事务流水线阶段；这些请求的响应可以描述为“上行”穿过事务流水线阶段。如果事务网只包括线性序列的事务，即事务流水线，那么每一阶段的事务流水线至多具有一个相邻的下游阶段；如果事务流水线散开到多个事务流的网，那么至少某些阶段的事务流水线会具有多于一个的相邻的下游阶段。
如上所述，本发明涉及用于分解事务流水线的技术。词语“分解”(decompose)指的是用于获得关于事务流水线中阶段的有效性和/或性能量度的操作，并且在本发明中，收集关于整个事务流水线中的事务的信息。相比于只收集终端用户响应量度的现有技术，本发明获取以更加详细测量表示的资源有效性、资源消耗、经历时间、时延、或与整个事务流水线的事务阶段相关的其它量度的信息。
现在参照图2，客户装置200类似于图1中的客户机102，其支持典型的终端用户应用，诸如浏览器应用202。终端用户可以与客户机200交互，以访问基于网络的资源，诸如由系统206通过事务接口208支持的事务应用204。事务应用204表示Web页面服务器、查找引擎、目录、或某些其它类型的网络可访问资源。事务接口208提供进行事务所需要的任何支持，诸如通信协议，例如TCP/IP或HTTP，数据库引擎语言支持，例如SQL、或任何其它接口要求。图2中所示数据处理系统之间的通信可以通过直接通信链路或通过网络进行，诸如图1中的网络101。为了访问事务应用204支持的资源，客户机200通过事务接口208向事务应用204发送事务请求，并且在大多数情况下，客户机200随后接收到从事务应用204通过事务接口208的事务响应。
类似于系统206的方式，系统210通过事务接口214支持事务应用212。与系统206相比较，系统210也通过TPD接口218支持事务流水线分解(TPD)代理216。TPD接口218支持进行TPD操作所需要的任何支持，诸如通信协议，例如TCP/IP或HTTP，数据库引擎语言支持，例如SQL、或任何其它接口要求。应该注意到TPD接口218可以包括许多或所有包括事务接口214的资源。例如，每一这些接口可以包括在系统210上执行的操作系统中的功能，并且操作系统可以为在系统210上执行的处理提供通信设施等。而且，在分布数据处理环境中，应该注意到支持资源并非必须与使用该资源的处理位置相同，例如可以使用远程程序调用或类型的技术来获取处理的资源。
如上所述，本发明使用代理获取与整个事务流水线的事务阶段相关联的信息。通常，代理是软件程序或类似的实体，其代表另一实体收集信息或执行任务。在本发明中，TPD代理、诸如TPD代理216代表应用程序负责收集关于事务流水线中阶段的量度数据。TPD代理位于和/或分布在整个事务流水线中。在优选的实施例中，人们希望监视一个与事务流水线中每一阶段或事务相关联的TPD代理；在其它实施例中，人们希望监视至少一个与事务流水线中每一事务相关联的TPD代理。图2所示为沿事务流水线分布的多个TPD代理；例如系统220通过事务接口224支持事务应用222，并且在同时，系统220也通过TPD接口228支持TPD代理226。
本发明的TPD代理收集当分布有代理时，与其相关联的服务器和/或应用所经历的响应信息。换言之，本发明的TPD代理收集分布有代理的事务流水线阶段所经历的响应的信息。还可以按另一种方式描述本发明的TPD代理的操作，也就是TPD代理收集与来自至少一个相邻的事务流水线的下游阶段的响应相关的量度数据。
在每一事务流水线阶段，系统分析师可能需要收集量度数据；在这种情况下，TPD代理与每一事务流水线阶段相关联。在优选的实施例中，TPD代理与在相同的系统或装置上执行的事务流水线阶段向关联，其中包括该应用和/或事务流水线阶段的服务器在该系统或装置上执行。虽然在优选的实施例中，大多数TPD代理与所感兴趣的系统或应用都位于相同的事务流水线内，但是应该注意到事务流水线的第一阶段和最后阶段表示不同的情况。如图2中所示最后阶段情况下的范例是TPD代理226，其通过系统232的事务接口234启动事务到系统232上的事务应用230，但是系统232并不包括TPD代理。应该注意到，词语“服务器”可以指的是能够访问资源、或能够访问资源的软件应用的物理硬件装置，其中资源可以包括各种广泛的硬件或软件实体或其部分。
系统232不包括TPD代理的原因非常多。一个原因可能是，已知事务应用230是特定事务流水线或事务流中的最后一个事务阶段，换言之，已知事务应用230不会启动另外的下游事务，并因此没有设置TPD代理，因为已知事务应用230不会经历来自下游应用的任何响应。另一个原因可能是，系统分析师并没有请求向系统232分布TPD代理，因为系统分析师确定从系统220(在图2中未示出)下游的另外事务阶段并不会随之发生或并不重要；因此，并不关心从系统232进一步下游的事务的量度数据。
图2中所示第一阶段情况下的范例是主TPD代理240，其通过系统244上其TPD接口242工作。系统244上的TPD代理冠以“主”TPD代理，是因为其分析该事务流水线中的第一事务。通过这种方式，该主TPD代理可以解释为表示虚拟用户，因为由TPD代理收集的量度数据应该与实际用户，例如通过客户装置200会经历的端到端响应时间基本上相同。应该注意到，如果系统分析师确定通过整个事务流水线中的其它TPD代理收集的量度数据可以产生事务流水线性能的充足统计图片，那么主TPD代理并不是必须的。然而如上所述，通过主TPD代理收集的量度数据应该类似于实际用户的经历，因此在本发明的大多数实施方式中有可能会设置主TPD代理。也应该注意到，如图2中所示主TPD代理并不需要专用系统。例如，主TPD代理可以设置在TPD中央服务器250或客户装置252上。
TPD中央服务器250支持量度数据收集和TPD代理配置，并且如果需要，协同各种后端业务254控制。例如，各种分布构架可以用来支持本发明，诸如TivoliTMManagement Enviroment，其可以从本发明的申请人International Business Machines得到。从TPD代理收集的量度数据可以存储在TPD量度数据库256中。配置参数258、脚本260、进度表262或其它信息可以存储在TPD代理配置数据库264中。如图1中所示，这些数据库和其它业务可以位于整个网络中。
客户装置252支持TPD控制应用270，其可以是独立的应用或可以是通过Web浏览器类型的平台使用插件、ActiveX控制、Web页面、或其它类似技术的基于Web的应用。希望监视特定事务流水线性能的系统分析师可以连同TPD代理配置数据库264中的信息一起使用TPD控制应用270，以配置和监视特定事务流水线的一组TPD代理。下面连同上下文一起详细描述TPD代理工作的这种方式。
客户装置252也支持TPD量度数据分析应用272，其可以是独立的应用或Web浏览器类型平台上的应用。在TPD代理已经提交了关于特定事务流水线的量度数据以在TPD量度数据库256中进行存储之后，系统分析师可以使用TPD量度数据分析应用272检查该量度数据，以找到该事务流水线中的处理瓶颈或其它类型的效率低下或问题。下面更详细地描述分布系统收集TPD量度数据的方式。
现在参照图3，该流程图描述的是为了能够收集事务流水线的TPD量度数据，使用事务流水线分解(TPD)设置特定事务流水线的过程。如上参照图2所述，想要监视性能或特定事务流水线的系统分析师或类似用户可以使用TPD控制原因270，以配置和监视特定事务流水线的一组TPD代理。本发明中配置过程的范例如图3中所示。
该过程开始于用户选择所要分组成或与另一服务器逻辑地关联成事务流水线的一个或多个事务服务器(步骤302)。可以将事务流水线标识符(ID)与新创建的事务流水线相关联起来(步骤304)，并且该事务流水线ID可以用于与该给定事务流水线相关的各种操作。可替换的，可以从其它源获得一组事务服务器，诸如数据库或其它系统软件应用，例如管理服务器的电子商务软件包。
对于事务流水线中的每一服务器，按照下面的方式通过循环查找该组事务服务器单独地处理每一服务器。选择该组中的下一服务器标识作为待处理的事务流水线中的当前服务器(步骤306)。确定当前服务器的资源类型(步骤308)，并且通过各种可能的机制为该资源类型获取适当的TPD代理脚本(步骤310)，例如通过产生脚本、通过来自用户的输入构建脚本、或通过从数据库、例如TPD代理配置数据库264中检索脚本。产生或获取该脚本的适当脚本参数(步骤312)，以及适当的脚本执行进度表(步骤314)。
如果在网络中还没有布置TPD代理，那么就以适合于该TPD代理的工作框架的方式演示、分布、或布置与事务服务器相关联(和/或共同存在)的TPD代理(步骤316)。可以通过电子分布、通过从计算机程序产品手动安装、或通过某些其它方法提供TPD代理。然后发送配置命令到该新布置的TPD代理(步骤318)。应该注意到，可以根据下层技术框架改变准备和/或分配脚本、脚本参数、和脚本进度表的顺序和实质。例如，在本发明的一个实施例中，通过获取和/或产生必要控制数据/结构的集中应用配置TPD代理的工作行为，而在另一实施例中，必要控制数据/结构的获得是通过让系统分析师或类似的用户直接与TPD代理通信，使得每一TPD代理负责确保其适当的初始配置。在另外还有的实施例中，TPD代理可登录到中央服务器，并查询配置信息和/或更新。
然后做出判决，确定正被配置的事务流水线中是否还有另一事务服务器未配置(步骤320)。如果有，该过程分支返回到步骤306配置另一事务服务器；否则，结束该配置过程。
现在参照图4，该流程图描述了为特定的事务流水线集中收集TPD量度数据的过程。可能需要或由系统分析师或类似用户确定用于集中收集TPD量度数据的进度表或时间机制，作为使用本发明的事务流水线分解技术分析特定的事务流水线的配置过程的一部分。是否根据预定的进度表或机制收集TPD量度数据，是否需要收集TPD量度数据从而可以分析该TPD量度数据，如参照图4中所示的过程进行描述。
该数据收集过程开始于从中央服务器沿给定的事务流水线向TPD代理发送TPD量度数据收集命令(步骤402)，如上参照图3所述，按照在事务流水线的配置过程中所确定的，对于给定的事务流水线，中央服务器具有关于标识的信息和对一组TPD代理进行寻址的能力。响应于该TPD量度数据收集命令，该中央服务器接收TPD量度数据(步骤404)。来自该特定事务流水线中各个TPD代理的TPD量度数据可以使用普通事务流水线标识符相互进行关联，该标识符在前面的事务流水线配置过程中已经提供给每一TPD代理(步骤406)。然后可以存储相互关联的TPD量度数据，用作随后的分析(步骤408)，并且该数据收集过程结束。应该注意到，在本发明中可以使用替换的数据收集顺序，下面参照图8和图9对其中之一进行描述。
现在参照图5，该流程图描述了为特定的事务流水线集中分析TPD量度数据的过程。如上参照图2所提到的，为了找到事务流水线中的处理瓶颈或其它类型的效率低下或问题，在TPD已经收集了关于的特定事务流水线的量度数据之后，系统分析师或类似用户可以使用TPD量度数据分析应用，如下参照图5中所示的过程进行解释。
该过程开始于在数据分析应用接收到用户的分析请求(步骤502)。检索已经从TPD代理收集的TPD量度数据(步骤504)，为了对与特定事务流水线相关的数据进行关联，优选地已经对该TPD量度数据进行了预处理。然后分析该TPD量度数据的各个统计指示(步骤506)，并然后将该统计分析提供给用户(步骤508)，从而完成该后处理过程。
现在参照图6，该流程图描述了特定事务流水线的具体阶段的TPD代理接收和处理来自中央服务器的命令的过程。如上参照图2所提到的，TPD代理通过TPD接口通信和接收工作支持，如下参照图6中所示的过程进行解释。虽然没有示出，但是可以假定TPD代理通过某些形式的事件环接收和处理数据和命令。
该过程开始于TPD代理接收来自TPD中央服务器的命令(步骤602)，并然后确定已经接收到的是何种类型的命令或指示。如果所接收到的命令是配置命令(步骤604)，那么就对该配置命令进行语法分析(步骤606)，以提取并存储一个或多个脚本、脚本参数和脚本执行进度表(步骤608)。当接收到配置命令的时候，可以进行其它的处理，诸如根据接收到的脚本执行进度表设置软件事件定时器(步骤610)，从而完成对该特定命令的处理。
如果在步骤604没有接收到配置命令，那么就确定该TPD代理是否接收到数据收集命令(步骤612)。如果是，那么对该数据收集命令进行语法分析，以得到可能需要的任何参数(步骤6140)。例如，TPD代理可以支持多个事务流水线的TPD量度数据的收集。在这种情况下，TPD代理试图从不同的下游事务收集关于服务器所经历的事务响应的信息。换言之，可以逻辑地将TPD代理关联的服务器与多个可辨识的事务流水线相关联。因此，可以设置TPD代理执行多个事务流水线的多个操作。当接收到数据收集命令的时候，TPD代理需要确定应该返回其已经编译的TPD量度数据中的哪一组，以响应于该数据收集命令，并且可以从该数据收集命令中检索到用于该目的的事务流水线ID。响应于对事务流水线ID的确定，TPD代理检索与该事务流水线ID相关联的TPD量度数据(步骤616)，并将该TPD量度数据发送到TPD中央服务器(步骤618)，从而完成对该数据收集命令的处理。
如果在步骤612没有接收到数据收集命令，那么确定是否接收到某些其它类型的TPD命令或指示(步骤620)，并且如果是，那么就执行适当的处理(步骤622)。例如，TPD代理可以接收到终止其自身的命令，使得可以从中央位置、例如TPD配置应用关闭对事务流水线的监视。
如上所提到的，TPD代理工作时可以支持多个事务流水线的TPD量度数据的收集。换言之，可以逻辑地将TPD代理划分成多个不同组的TPD代理，其中每一不同组的TPD代理监视不同的事务流水线。在这种情况下，TPD代理可以使用事务流水线标识符管理脚本，每一标识符与不同的事务流水线相关联。因此应该注意到，在任何给定的时间，可以在网络中使用多个脚本和事务流水线标识符，将多个TPD代理设置为主TPD代理，以支持分解多个事务流水线的操作。在一个实施例中，TPD代理可以设置为关于第一事务流水线的非主TPD代理，同时也设置为关于第二事务流水线的主TPD代理。在这种情况下，发送到特定事务流水线的TPD代理的配置信息将指示TPD代理是否应该用作关于该特定事务流水线的主TPD代理。
现在参照图7，该流程图描述了特定事务流水线的具体阶段的TPD代理收集和存储TPD量度数据的过程。如上参照图2所解释的，TPD代理试图收集表示事务流水线内相关服务器所经历的响应的量度数据。可以通过各种机制配置该TPD代理，诸如使用由TPD代理在给定时间进度执行的脚本。如上参照图6所提到的，TPD代理可以接收脚本，在配置命令中带有其执行进度，并且作为响应，TPD代理可以设置软件定时器，其产生定时失效事件，使得该TPD代理可以确定何时应该执行收集TPD量度数据的某些操作。图7中所示的该过程描述了某些操作。
该过程开始于确定定时器是否失效(步骤702)，即TPD代理在前面已经根据相关的脚本执行进度表进行设置的定时器。如果该定时器还未失效，就可以继续该TPD代理的执行线程，以循环和检查其失效。可替换的，如果执行线程由下层系统支持，那么其可以休眠一个特定的时间段，并且其唤醒会说明所想要的时间段已经失效。
在任何情况下，在所想要的等待周期已经过去之后，该TPD代理确定哪一事务流水线与该定时器相关联(步骤704)，例如通过事务流水线标识符，因为TPD代理可以支持关于多个事务流水线的操作。使用事务流水线标识符，TPD代理检索适当的脚本(步骤706)，并根据脚本参数执行该脚本(步骤708)。通过执行该脚本产生TPD量度数据(步骤710)，并且通过TPD代理存储所产生的TPD量度数据(步骤712)，从而完成该过程。
现在参照图8，该流程图进一步详细描述了如图7中所述、特别是步骤710所述的TPD代理获得TPD量度数据的过程。该过程开始于在脚本开始执行的时候获取并存储表示当前系统时间值的时戳(步骤802)。解释该脚本，该脚本会使得各种操作启动，特别时启动发送到事务流水线中下游服务器的、被TPD代理观测的某些类型的事务(步骤804)。通过这种方式，TPD代理用作下游服务器的客户。预期在后面的某个点会出现响应，因此该TPD代理会等待事务响应(步骤806)。可以使用各种等待机制，包括使用超时定时器或休眠执行线程。
假定没有错误出现，接收到了响应并获得了指示当前系统时间值的当前时戳(步骤808)。计算并存储当前系统时间值与所存储的时戳之间的差值(步骤810)。然后产生TPD量度数据记录(步骤812)，并且将所计算的时差存储在TPD量度数据记录中，以指示TPD代理接收到对该事务的响应所需要的时间量。如果合适，可以在该TPD量度数据记录中存储其它数据，诸如来自响应信息自身的数据或从其上执行该TPD代理的系统收集的数据。
现在参照图9，该方框图描述了TPD量度数据在被转发到中央服务器之前，从TPD代理上传到主TPD代理的过程。如上所述，可以使用各种数据收集技术。在一个实施例中，TPD代理可以根据预定的进度表和/或配置参数向中央服务器提交TPD量度数据。在另一实施例中，每一TPD代理等待接收数据收集命令，并且一旦接收到数据收集命令时，TPD代理返回TPD量度数据，作为对发送该数据收集命令的实体的响应。在一种情况下，可以从中央服务器接收该数据收集命令。在另一种情况下，该数据收集命令可以源自主TPD代理，如图9中所示。
TPD代理902在事务流水线中用作关于其它TPD代理904-906的“主”TPD代理。当确定合适的时候，主TPD代理向TPD代理904发出数据收集命令908。作为响应，TPD代理904将该数据收集命令转发给其下游TPD代理。假定没有出错，最终TPD代理906接收到该数据收集命令，其表示该特定事务流水线的一组TPD代理中的最后一个TPD代理。作为响应，TPD代理906将其用于该请求事务流水线的TPD量度数据发送给发送该数据收集命令的上游TPD代理。为了保证特定TPD代理的故障不会完全破坏收集TPD量度数据的能力，TPD代理可以设置看门狗定时器，从而其不会无限地等待TPD量度数据的返回。
最终，TPD代理904从其下游TPD代理接收待TPD量度数据，附上其TPD量度数据，并将该TPD量度数据作为TPD量度数据响应910发送给发出该数据收集命令的TPD代理，即TPD代理902。在附上其TPD量度数据之后，TPD代理902将累加的TPD量度数据发送到中央服务器912，其存储支持分析功能的该数据。
相比于直接将TPD量度数据发送给中央服务器的另一种方法，图9所描述的方法是将TPD量度数据从最后阶段的事务流水线“上传”到第一阶段的事务流水线，其有利地是由于各种原因。例如，沿事务流水线的TPD代理，主TPD代理或是可能的每一TPD代理都可能对从下游TPD代理接收到的TPD量度数据和存储在该TPD代理中的TPD量度数据可选地执行某些类型的数据相关/分析。通过这种方式，TPD框架可以完成某些分布处理，使得对TPD量度收集进行相关/分析的全部负荷全落到一个实体、即中央服务器上。
现在参照图10，该方框图描述了根据本发明的实施例，使用沿事务流水线的一组TPD代理收集TPD量度数据的范例。图10所描述的情景是将本发明用于商业环境中，特别是银行，其希望在其信息构架中分解其一个事务流水线。
在计算装置1004上已经设置有TPD代理1002(该情况下是主TPD代理)，计算装置1004是专门选择用来测试服务器1006的装置，因为其物理地与服务器1006相隔遥远(Texas到California)。因此，计算装置1004可以准确地代表普通客户用来通过长途访问银行系统的典型客户机。已经使用TPD流水线标识符在TPD代理1002上配置了脚本1008，可以将该标识符与被观测的事务流水线中其它地方已经使用的同一标识符相互关联。在该范例中，脚本1008包括三个任务或步骤，用于访问或登录到California的银行的计算机系统。第一步是通过浏览器进入银行主页的在线客户银行；第二步是使用用户名和密码登录到在线客户银行系统；并且第三步是退出在线客户银行系统，从而产生账户摘要。脚本1008已经被配置为每15分钟重复一次。
应该注意到，对于TPD代理可以配置更加复杂的脚本。例如，脚本可以包含基于TPD代理响应于前一脚本操作可能会接收到的特定数据值的条件动作。因此，由TPD代理启动的事务的数目并非必须受到预定数目的限制。
计算装置用于接收银行的在线银行业务的客户请求，其上已经设置有TPD代理1010，其在该范例中是Web应用服务器1006。TPD代理1010已经配置了包含与脚本1008相同事务流水线标识符的脚本1012，该普通事务流水线标识符能够将来自每一代理的信息相关成为源自相同的事务流水线。脚本1012只包括一个步骤，如脚本1008中所配置使用相同的用户名和密码产生账户信息的数据库查询。脚本1012已经被配置为每3分钟重复一次。
银行计算系统的中央服务器1014已经被用来创建布置TPD代理1002和1010，并使用它们相应的脚本配置该TPD代理，其按照下面的方式使用。TPD代理1010每隔3分钟执行一次脚本1012，其使用所提供的用户名和密码创建到数据库1016的数据库连接，并然后发出检索账户摘要1020的SQL语句1018，其会包含格式成Web页面响应的相同的账户摘要数据，以显示给典型的在线银行客户。TPD代理1010监视完成数据库请求所需要的时间长度；TPD代理1010也可以编译与监视数据库1016相关的其它TPD量度信息。TPD代理1010可以对编译的TPD量度数据可选地执行某些统计分析。
TPD代理1002每隔15分钟执行一次脚本1008，其产生该主页请求，登录进入在线银行业务，并然后退出。作为响应，接收到账户摘要Web页面；如图10中所示为输入数据流1022和输出数据流1024。TPD代理1002单独地或共同地监视完成该请求所需要的时间长度；并且TPD代理1002可以收集与该请求相关的其它相应TPD量度数据。TPD代理1002也可以对编译的TPD量度数据可选地执行某些统计分析。
在图10中所示的范例中，主TPD代理按照类似于上述参照图9所解释的方式负责启动TPD量度数据收集过程、收集数据、和将其发送到中央服务器。在图10的范例中，在每次执行事务流水线的脚本之后，主TPD代理启动特定事务流水线的TPD量度数据收集过程。主TPD代理1002通过控制接口(未示出)向TPD代理1010发送TPD量度数据收集请求1026。TPD代理1010确定是否存在该TPD量度数据收集请求应该转发的任何下游TPD代理。由于其确定没有这种下游TPD代理，TPD代理1010将TPD量度数据响应1028返回给主TPD代理1002。在接收到该响应之后，主TPD代理1002将其TPD量度数据加入到所接收到的TPD量度数据中，并然后将该量度数据作为消息1030发送给中央服务器1014。在该范例中，该TPD量度数据会包括前15分钟期间来自TPD代理1002的单组TPD量度数据和前15分钟期间来自TPD代理1010的5组TPD量度数据。
现在参照图11，该方框图描述了特定网络拓扑结构中的一组结点，以及表示网络中事务流水线的一组排序后的事务。图11提供的简单网络用于解释从一组TPD代理获得的TPD量度数据可以用来确定事务流水线中效率低下或瓶颈的方式。结点1101-1108表示网络中响应于所接收到的请求而完成事务的结点。在图11中所示的范例中，事务流水线可以更恰当的称为事务网，因为事务流畅并不是严格的线性。可以假定在每一结点配置TPD代理，尽管其在图中未示出。
原始事务请求1110的完成需要在某一时间段完成多个事务。事务在该范例中如下通过该事务网。结点1102接收事务1110，并启动事务1111到结点1103，其然后启动事务1112到结点1104。结点1104启动事务1113，并且在事务1113已经完成之后，结点1104启动事务1114，该事务的完成才导致事务1111的完成。结点1112然后启动事务1115，其使得结点1106启动事务1116，该事务的完成才导致事务1115的完成。结点1102然后启动事务1117，其使得结点1107启动事务1118，该事务的完成才导致事务1117的完成。
假定在某一时间段收集了TPD量度数据，从而可以编译平均事务完成时间(或类似量度)的基线。通过监视来自多个TPD代理的历史TPD量度数据中的统计随时间的变化，可以发现事务的效率低下或瓶颈。使用本发明，由于可以在事务流水线或事务网的每一阶段收集TPD量度数据，那么就可以鉴别产生问题的特定阶段。
在图11中所示的范例中，可以存储事务1110-1118的一组平均完成时间，并将其用于比较。当完成时间偏离它们的历史标准时，可以将该改变警示给系统分析师。能够在每一事务流水线阶段收集量度数据的能力，使得在确定哪一结点产生问题的时候要考虑事务之间的相关性。结点1108的处理瓶颈会增加事务1111-1114、1117和1118的完成时间，而在结点1105的处理瓶颈只会增加事务1111-1113的完成时间。在分析应用中，如上参照图2所提到的，可以使用各种技术将该统计变化进行图形显示，诸如图标或色彩编码指示器。
根据上面提供的详细说明，本发明的优势应该比较明显。在现有技术中已经提出了几种收集关于事务流水线的信息的方案。一种方式建议使用某种形式的包含标志器的跟踪报头，其伴随着沿事务流水线的资源一起使用，以根据因原始请求而出现的处理。这种方式难以实现，因为其需要应用层，其能够沿事务流水线将标志器作为原始请求的数据包从一个应用协议映射或拷贝另一应用协议。例如，可以将包含标识标志器的客户报头加到HTTP请求，并且接收该HTTP请求的Web服务器然后可以识别该客户报头。然而，如果Web服务器向后端数据库请求，那么来自客户报头的该标识标志器应该与数据库请求一起，等等。如果后端数据库然后使用某种形式的资源，那么对该资源的请求也应该与该标识标志器一起。在任何其它事务流水线的参与者中提供这种类型的跟踪能力需要重要的仪表设备。
在美国专利US6,108,700中公开了与本发明具有共同申请人的另一种方案，其内容在此引作参考。该参考文献教导的方法是，对在事务流水线的每一阶段或在事务流水线阶段之间的中继可能出现的事件进行定义，并且跟踪关于这些事件的信息，并然后将其与其它事件相关联，从而可以确定已经被原始请求所使用的资源。尽管在某些环境中跟踪贯穿事务流水线的单个请求的资源消耗的能力具有某些优点，但是这样做所投入的大型仪表设备相对于所产生信息的重要性并且需要非常详细的跟踪信息就不合算了。
相比于现有技术，本发明贯穿整个事务流水线都不需要接入仪表设备。本发明不是对原始请求实际消耗的资源使用进行跟踪，而是捕获事务流水线中每一事务阶段的一组统计信息，其中该统计信息描述了在特定的时间段，事务流水线特定部分的工作表现。事务流水线每一阶段中的代理独立地获取与事务流水线的特定阶段相关的性能量度，并且周期性地包括该量度信息。通过从事务流水线中每一阶段收集量度数据，可以对事务流水线的性能进行更加详细的分析，并且通过在按照该详细分析所指示的事务流水线中任何已经表现出较差性能特征的阶段增加资源，可以改善用户的端到端响应时间。
重要的是要注意到，虽然已经在全功能的数据处理系统中描述了本发明，但是本领域的熟练技术人员会理解的是，与本发明相关的某些过程能够在计算机可读媒体中以指令的形式或类似方式，以及各种其它形式分布，而不管实际用来执行该分布的特定类型的信号承载媒体。计算机可读媒体的范例包括诸如EPROM、ROM、磁带、纸张、软盘、硬盘驱动、RAM、和CD-ROM的媒体，以及传输类型的媒体，诸如数字和模拟通信链路。
已经对本发明做出的说明只用于说明性的目的，其并不是无遗漏的，或是意欲将本发明限制为所公开的实施例。许多修改和变化对于本领域的熟练技术人员都是明显的。所选择的这些实施例用来解释本发明和其实际应用的原理，并且使得本领域的熟练技术人员能够理解本发明，从而能够按照所考虑的其它使用进行各种修改地实施各种实施例。
权利要求
1.一种用于监视分布式数据处理系统的方法，所述方法包括在分布式数据处理系统范围内提供一组代理；将该组代理中的每个代理与所述分布式数据处理系统中的一组服务器中的服务器相关联，其中该组服务器中的每个服务器在向该组服务器中的后续服务器请求后续事务之后，完成所请求的事务；和配置该组代理中的每个代理，以启动事务并获取关于所述事务的完成信息，其中所述事务被定向到所述代理所关联的服务器向其请求了后续事务的后续服务器。
2.权利要求1的方法，其中所述完成信息包括与完成所述事务所需要经历的时间相关的数据。
3.权利要求1或2中任一的方法，其中所述完成信息包括关于资源可用性、资源消耗或时延的与事务相关的数据。
4.权利要求1至3中任一的方法，进一步包括在所述分布式数据处理系统中提供主代理，其中所述主代理是不与该组服务器中的服务器相关联的代理；将所述主代理包括在该组代理中；和配置所述主代理，以启动事务并获取关于事务的完成信息，其中所述事务被定向到该组服务器中的服务器。
5.权利要求1至4中任一的方法，进一步包括为该组服务器中的每个服务器建立一个逻辑顺序；和由所述主代理向排序后的服务器组中逻辑上的第一服务器启动事务。
6.权利要求1至4中任一的方法，进一步包括从该组代理中的第一代理向该组服务器中的第一服务器启动第一事务；和在所述第一代理获取关于该第一事务的完成信息。
7.权利要求6的方法，进一步包括从该组代理中的第二代理向第一服务器启动第二事务；和在所述第二代理获取关于所述第二事务的完成信息。
8.权利要求1至4中任一的方法，进一步包括为该组代理分配公用的标识符；和在配置信息中将所述公用标识符分配给该组代理中的每个代理。
9.权利要求1至4中任一的方法，进一步包括在代理处执行脚本，以向一个或多个服务器启动一个或多个事务。
10.权利要求1至4中任一的方法，其中该组代理中的代理的配置信息包括用于指示代理何时应向服务器启动事务的时间信息。
11.权利要求1至4中任一的方法，进一步包括在指定的服务器直接从该组代理中的每个代理收集完成信息。
12.权利要求11的方法，进一步包括通过该主代理启动完成信息的收集。
13.权利要求1至12中任一的方法，进一步包括对来自多个代理的完成信息进行相关。
14.权利要求1至13中任一的方法，进一步包括对来自多个代理的完成信息进行统计分析。
15.一种数据处理系统，包括用于执行权利要求1至14中任一的方法的装置。
16.一种计算机程序产品，包括当在计算机上执行所述程序时，用于执行权利要求1至14中任一的方法的步骤的编程代码指令。
全文摘要
提供一种用于分解事务流水线的方法、系统、设备和计算机程序产品，其通过捕获关于在事务流水线内完成事务的量度数据，诸如在事务流水线的每一阶段完成事务所需要经历的时间。在一组响应于资源请求事务的服务器中有一组代理。两个或多个服务器实质上可逻辑地划分到一个事务流水线中，其中如果上游服务器启动随后的事务到下游服务器，以在下游服务器完成前面的事务，那么该上游服务器就在该下游服务器之前。在事务流水线中，每一代理都关联着服务器。代理收集关于由该代理启动的事务的量度数据，将其传送到与每一代理相关联的服务器的下游服务器。
文档编号H04L29/08GK1688979SQ03813848
公开日2005年10月26日 申请日期2003年5月13日 优先权日2002年6月20日
发明者罗纳德·C·艾伦 申请人:国际商业机器公司