多层计算环境中用于性能管理的系统和方法

专利名称：多层计算环境中用于性能管理的系统和方法
技术领域：
本发明涉及分布式计算环境的一般管理，特别涉及多层计算环境中用于应用性能管理的系统和方法。
背景技术：
信息技术(IT)利用混合有不同种类应用的逐渐复杂的多层生产环境来负责提供应用服务。IT解决方案正尽力在性能和可用性上满足所需的服务水平，并同时提升效率和资源使用。通过结合IT资源和商务需求来达到这种效果，扩展IT解决方案的功能以满足对计算资源不断改变的需求。性能及可用性管理的传统方式和工具是不停的“监控—调试—定位”循环的各种变形，其包括识别问题是否存在(即监控)、提高总体吞吐量以克服该问题(即调试)和执行根本原因分析，以揭示问题的每个具体实例的确切原因(即定位)。这种方式无法满足快速变化的IT环境的复杂性和可变性。
现在参见图1，该图为本领域公知的以标号50表示的多层计算环境的示意图。计算环境50包括运行第一应用的第一客户端62、运行第二应用的第二客户端64、第一层52、第二层54、第三层56、第四层58和第五层60。第一层52为WEB服务器，第二层54为应用服务器，即应用服务器A。第三层56为另一应用服务器，即应用服务器B。第四层58也为应用服务器，即应用服务器C。第五层60为数据库。第一层52与第一客户端62、第二客户端64及第二层54相连。第二层54还与第三层56和第四层58相连。第三层56还与第四层58和第五层60相连。第四层58还与第五层60相连。
“层”表示一种特定类型的处理，该处理为所提供的所有IT服务的一部分(例如WEB服务器层上的表现层处理或数据库层上的数据处理)。通常情况下，每一层都运行在不同的主机上。
第一应用发起一个用户请求R1并发送该用户请求R1至第一层52。用户请求R1是由用户发起的所有事务(transaction)的一部分。例如，用户请求R1可以是从特定应用中检索信息的基于WEB的查询。用户请求R1可以要求在计算环境50中的不同层的服务，并且可生成附加请求，以获得这些服务。接收到请求的层可以应答发送请求的层，或向不同层发送新的请求。最终，响应于初始的用户请求R1，返回应答。如果计算环境50中的两个层彼此直接相连，则给定的层仅能够从另一层请求服务。
分布式计算环境50的整体管理需要获知各层是如何处理其工作负荷的。例如，假定某一层资源短缺，则系统管理员可以通过垂直地(即，在同一主机内)或水平地(即，在多个主机内)创建该层的复制来调整该层。例如，在计算环境50下，系统管理员可以将附加应用服务器A2(未示出)添加到第二层54的应用服务器A，其中应用服务器A2是应用服务器A的复制。同理，如果某一层存在过多资源，则系统管理员可以将空闲资源转移至资源短缺的另一层。系统管理员可以进一步配置某一层，以便提高整体性能或指出用于对该层上所运行应用进行优先级划分的修改。这是一个用于性能管理的特定层应用监控的实例。需要注意的是，请求仅可以到达在计算环境50中的某些层。此外，可以使用多条路径将相同的请求到达某些层。例如，在计算环境50中，请求可通过第三层56的应用服务器B或第四层58的应用服务器C到达第五层60数据库。由于在整体环境中多个请求路径并不一致，所以解决在一层上资源短缺的问题没有必要保证可跨越多个层的整体应用的性能。在任一层中的处理瓶颈都会使得使用该层的所有应用功能延迟。
第一层52接收到用户请求R1。第一层52分配处理程序集(enclave)X1来处理用户请求R1。在处理用户请求R1的同时，在处理程序集X1中执行的应用逻辑确定在第二层54不提供附加信息或操作的情况下，处理程序集X1不能完成用户请求R1的处理。然后，第一层52向第二层54发送请求R2，以请求附加信息或操作。第二层54分配程序集X2来处理请求R2。在处理程序集X2中执行的应用逻辑确定请求R2需要由第四层58提供的进一步信息或操作。然后，第二层54向第四层58发送后续请求R3。第四层58分配处理程序集X4来处理请求R3。
处理程序集X4完成执行。第四层58响应于第二层54的先前请求R3向第二层54返回应答R3’。处理程序集X2接收应答R3’并且继续处理。一旦处理程序集X2完成执行，则第二层54响应于第一层52的先前请求R2向第一层52返回应答R2’。处理程序集X1接收应答R2’并且继续处理。一旦处理程序集X1完成执行，则第一层返回对用户请求R1的应答R1’，现在已完成用户请求R1的服务。
在计算环境50中，每个不同的层和不与其直接相连的层分隔。例如，从第二层54到与其直接相连的第四层58的请求R3没有必要包含在第二层54接收的来自第一层52的先前请求R2的相关信息，R3也没有必要包含用户请求R1的相关信息。给定层无法获得与该层上正被处理的请求相关的某些信息，例如哪个用户发起了该事务，哪些请求先于正在该层被处理的请求，先于该请求的请求特征。例如，第二层54不能识别请求R2的特征，例如发送至第一层52的用户请求R1是否先于该请求，或者是否由来自第一应用62的用户请求R1发起了该事务。结果，如果对于在某一层内处理请求的处理程序集分配优先级，那么仅考虑在该层上可用的最少信息来分配该优先级。该信息包含请求特征(例如由请求所使用的层登陆凭证)和关于处理该请求的处理程序集的可能信息(例如数据库会话标识)。尽管在本地给定层上有区分不同优先级的机制，但一般情况下，请求都是基于相等优先级进行处理的(例如先到先服务)。由于在处理计算环境50中的特定层时不能考虑其它层，所以必须基于各个层进行性能管理。典型情况下，负责管理多层计算环境(如计算环境50)的系统管理员通过为给定层调整资源分配来尝试提升性能。
题名为“用于监控多个包含操作系统内核中运行的接口的分布式应用的系统及方法”由Agarwal等人提交的申请号为5,958,010的美国专利提出监控分布式计算系统在整个企业范围内运行的系统及方法，以开发应用于系统性能、使用趋势、安全审计、能力计划和其它的商业事务级的管理数据。具有分布式计算构架的系统包含多个工作站、服务器及网络设备。每个工作站表示连接到网络的计算机系统。每个工作站能够从任一服务器请求服务。每个工作站具有用于和网络交换数据的通信栈。该系统还包含多个监控代理和具有与其相连的数据库的控制台模块。每个监控代理具有外部事件接口，所述外部事件接口提供关于企业各组成的事件信息。每个监控代理与每个服务器或工作站相关联。
所述监控代理物理上可以位于与其关联的客户端或服务器上。监控代理监控并收集在客户端与网络之间以及在服务器与网络之间交换的数据。每个监控代理可以是软件模块、硬件设备或这两者的组合。每个监控代理将表示收集到的数据的信息传递给控制台模块。控制台模块将这些信息存储在数据库中，以便于技术人员对其进行分析。运行在控制台模块上的应用程序可以阅览收集的数据，以显示任一进程的系统性能或企业组成。系统管理员可以发展企业级使用统计表和响应时间、发展图表和报告，并进行其它相关数据分析，以确定与企业运行相关的用户定义的统计表。
题名为“应用的端到端响应时间的测量和分解”由Maccabee等人提交的申请号为6,108,700的美国专利提出一种用于测量和报告端到端商业事务的可用性和性能的方法和系统。该系统运行在客户端-服务器应用构架上。该系统包括三个逻辑组件即事件生成、事务生成和报告生成，同时也包括通过系统配置实现的整体系统管理。
事件生成组件存在于在构架中正在被测量的每个计算机上。每个计算机都有一个代理、多个的传感器和多个处理器。传感器可以与运行商务应用的平台组件交互，可以监控应用程序活动，以及检测状态变化。在适当的时候，每个传感器生成用于描述状态变化的事件、事件发生的时间和位置以及识别事件所唯一必要的额外数据。事件包含时间戳和随后由系统用于使该事件和事务中其它事件关联的相关数据。传感器将生成的事件转发至它们各自的代理中。这些代理临时存储该数据，并可以将该数据发送给在该事件中已注册信息的其它系统组件。处理器分析这些事件并推导出状态的变化。状态的变化可以直接与商业事务平台组件中发生的操作相关，也可以通过组合从传感器或其它处理器先前生成的事件来获得状态的变化，从而描述所达到的状态。处理器将生成的事件转发给它们各自的代理。
该事务生成组件通常存在于网络中的一计算机上，并含有控制器。该控制器从被其控制的代理接收事件。基于事务生成规则对事件进行检查，并且关联和整理成事务。系统管理员确定生成哪些事务。
报告生成组件包括管理器。该管理器从控制器收集事务。对所收集的事务进行操作，以获得与商业事务的可用性及性能相关的信息。在从图形用户界面(GUI)输入特定或定期的请求时，可生成报告或连续图形监控。报告生成处理包括对事务初始选择的定义和事务的处理，也包括用于将事务事件数据统一成可用性和性能信息的分类和聚集方法。
题名为“用于分布式应用性能分解的嵌入式相关性能测量的方法和系统”由Mills等人提交的申请号为2002/0129137 A1的美国专利提出在与分布式应用关联的事务中用于嵌入式相关性能测量的技术。依照应用性能分解来使用这些技术。将数据嵌入到用于在分布式计算网络中的应用组件之间传输事务的通信协议中，而并不是改变实际事务数据本身。嵌入的数据可以包含时间戳和持续时间测量数据。嵌入的数据的格式由已定义的关键字前缀、用于识别定时源的可变后缀组成，接着是冒号分隔符和空格，以及接着是时间戳和持续时间信息。
分布式应用的后续处理阶段可以解释通信协议，以收集先前处理阶段的处理持续时间，以关于事务的处理作出确定。将测量信息嵌入至由该测量信息所描述的同一分布式应用中，以便于事务与可获知事务性能特征同时或同一时期完成。
可用的通信协议是超文本传输协议(HTTP)。可用的分布式计算环境是万维网(WWW)。应用组件可以是运行在客户端上的客户端应用和运行在应用服务器上的服务器应用。例如，客户端应用为WEB浏览器，服务器应用运行于WEB服务器上。应用事务是向应用服务器请求内容以及由应用服务器进行响应的客户端应用。生成性能信息，以从客户端应用的角度来测量往返响应时间，以及将该响应时间分解成由服务器应用用于服务请求和生成应答所采用的时间。特别地，在HTTP头添加划线来传输性能测量数据，使客户端接收在HTTP应答报头中的服务器测量持续时间。

发明内容
依据所公开的技术，提供了一种用于监控多层计算环境中的所选层的装置。所述装置包括环境代理和动态层扩展。所述环境代理与所选层关联，并且与其它的环境代理相连，每个其它的环境代理与各自层关联。动态层扩展与环境代理以及与所选层的特定预定点(例如至少所选层的请求进入端口)相连。动态层扩展监控通过所选层的请求通信量，被监控的请求通信量包括在所述请求进入端口接收到的来自所述计算环境的相邻层的至少一个进入请求。动态层扩展识别在被监控的请求通信量中的每个请求，并至少将请求标识符发送给环境代理。环境代理还从与相邻层关联的环境代理接收与进入请求的请求环境相关的信息。环境代理依据接收到的请求标识符将与进入请求的请求环境相关的信息与进入请求关联。
动态层扩展还可以与所选层的请求退出端口相连，此被监控的请求通信量还包括从所选层退出至相邻层的至少一个退出请求。动态层扩展获得退出请求的请求环境，并向环境代理至少发送请求标识符和与退出请求的请求环境相关的信息。环境代理依据接收到信息和请求标识符将进入请求与退出请求相关联。环境代理还向与退出请求被发送到的相邻层关联的环境代理提供与退出请求的请求环境相关的信息。
依据所公开的技术，还提供一种在包括多个层的多层计算环境中用于应用性能管理的系统。该系统包括对于至少两个所述被监控层的每个层的各自的动态层扩展和各自的环境代理。动态层扩展至少与被监控层的请求进入端口相连。环境代理与动态层扩展以及与直接连接至所述各自层的层关联的其它所述环境代理相连。动态层扩展监控通过所选层的请求通信量，被监控的请求通信量包括在请求进入端口收到的来自相邻层的至少一个进入请求。动态层扩展识别在被监控请求通信量中的每个请求，并至少发送请求标识符给环境代理。环境代理也从与相邻层关联的环境代理接收与进入请求的请求环境相关的信息。环境代理依据接收到的请求标识符将与进入请求的请求环境相关的信息与进入请求关联。该系统还包括环境网络管理服务器。该环境网络管理服务器与环境代理相连。该环境网络管理服务器收集和分析从环境代理接收到的性能数据。
依据所公开的技术，还提供一种在包括多个层的多层计算环境中用于监控所述多个层的所选被监控层的应用性能管理方法。该方法包括，对于多个层的至少两个被监控的层中的每个层，接收与至少一个进入请求的请求环境相关的请求环境信息的步骤，所述信息至少包括请求标识符和事务标识符。该方法还包括监控通过所述被监控层的请求通信量的步骤，所述被监控的请求通信量至少包括所述至少一个进入请求。该方法还包括依据所述请求标识符，识别所述至少一个进入请求的步骤，以及依据所述事务标识符，将所述至少一个进入请求和事务相关联的步骤。
依据所公开的技术，还提供一种在包括多个层的多层计算环境中用于监控所述多个层的所选被监控层的应用性能管理方法。该方法包括，对于多个层的至少两个被监控的层中的每个层，监控通过所述被监控层的请求通信量的步骤，所述被监控请求通信量包括至少一个进入请求和退出请求，所述所选层向相邻层发送所述退出请求。该方法还包括确定与所述进入请求的请求环境相关的环境信息的步骤，以及识别在所述被监控请求通信量中包括的每一个请求的步骤。该方法还包括将所述进入请求与所述退出请求相关联的步骤，以及向与所述相邻层关联的另一环境代理发送信息的步骤，所述信息与所述退出请求的请求环境相关。


根据以下结合附图所进行的详细描述，所公开的技术将更容易理解和认识，其中；图1为本领域公知的多层计算环境的示意图；图2为依据所公开技术的实施例而建立和实施的应用性能管理系统的示意图；图3为在图2所示系统的两个环境代理之间中继的信息的示意图；图4为在图2所示系统的两个层上的取样请求生命周期的示意图；图5为依据所公开技术的实施例而建立和实施的应用性能管理系统的示意图；图6为图5所示多层计算环境的两个层的示意图；图7为图5所示系统的动态层扩展的示意图；图8为图5所示系统的环境代理的示意图；图9为示出依据所公开技术的另一实施例而实施的在获得请求环境的处理和随后处理中所包括的阶段的框图；图10为示出依据所公开技术的另一实施例而实施的在图5所示系统的本地层上获得UOW分配的处理以及将请求与UOW关联的处理所包括的阶段的框图；以及图11为示出依据所公开的技术的另一个实施例而实施的在获得已发送至图5所示系统的远处的层的退出请求的处理以及将发送的请求与请求环境关联的处理所包括的阶段的框图。
具体实施例方式
通过提供一种用于多层计算环境中的应用性能管理的系统和方法使得所公开技术克服了现有技术的缺点。该系统监控每一层的请求进入端口和请求退出端口，并通过多个环境代理(context agent)来检测来自或到达给定层的请求的进入或退出。在多层计算环境中，每一个环境代理都与一个层关联，并且能够和其它环境代理通信。环境代理收集对于与该环境代理关联的层的请求执行相关联的信息。环境代理识别用户请求的请求环境。环境代理将用户请求划分成请求类别。环境代理将退出与其关联的层的请求特征中继至与该请求被发送到的层关联的随后的环境代理。
环境代理将请求与用户请求关联，并也将请求与在同一事务中其它先前的请求相关联。环境代理依据请求类别和本地存储的动态服务类别策略来为请求分配服务类别。环境代理可以进行干预来影响请求的处理，例如在层的请求进入端口调整队列中请求的次序，更改用于执行请求的处理程序集的优先级，更改用于执行请求的处理程序集的处理类型，指示层分配或拒绝用于处理请求的计算资源(例如中央处理单元-CUP，存储器等)，保持请求并释放处理程序集，或终止请求。环境网络管理服务器可以概括在多个层之间的不同类型请求的操作，并可以设置适合的跨层服务类别策略。从而，在多层计算环境下的不同层之间，系统可在事务层次上提供环境相关的资源管理。
所公开的技术提供在IT基础链中所有层之间的主动(proactive)事务工作负荷管理的功能。系统结合多种IT基础层，例如WEB、应用程序、数据库和中间件服务器。系统自动概括工作负荷，协助为此工作负荷分类，并使用户创建适合的服务类别性能策略。该系统将这些策略连续应用于在计算环境中的多个层之间的事务。该系统利用现有的IT基础设施，并对现有的IT基础设施强化，使其能够以与商业利益一致的最优服务水平提供稳定的服务。在本具体实施例的描述中使用以下术语·以下用到的术语“层”是指提供某类服务的实体，其中该服务为所提供的所有IT事务的一部分。该服务可以是WEB服务器层上的表现层处理、应用服务器层上的应用程序功能、数据库层上的数据处理等。尽管在一台主机上可以有多个层，但通常每一层都运行在不同的主机上，一个层可包括存在于多个主机上的多个组件。以下，在至少一个层上运行的主机被称为“层主机”。层的实例包括但不仅限于Java 2平台、企业版(J2EE)应用服务器实例；J2EE应用服务器实例的群集；包括对数据库服务器的访问组件(如Java数据库连接/开放式数据库连接(JDBC/ODBC)的驱动器)的数据库服务器；数据库群集等。
·术语“事务”表示由用户发起的单个处理，例如在商业应用中的商业处理过程中的一个阶段。事务的实例可以是在线拍卖服务中的一次出价，或金融机构中新用户的开户。事务是由用户请求开始的在多个层之间的请求链组成。因此，每个请求都与唯一的用户请求(例如事务的用户请求)关联。通过唯一的标识符可以识别每个事务，这种标识符称为“事务ID”。需要注意的是，“相关事务组”是指具有关联性的多个事务(例如每个事务都代表单一的商务处理过程中的不同阶段)。对事务中请求的处理不仅考虑该事务，还考虑该请求所属的相关事务组。
·以下所用术语“请求”是指为提供作为事务一部分的某种服务而从一层向另一层发送的系统请求。通过唯一的标识符可以识别每个请求，这种标识符被称为“请求ID”。每个请求都会在被调用层上产生一个工作单元(UOW)。请求的实例包括但不限于向WEB服务器发送超文本链接协议(HTTP)请求的客户端WEB浏览器；向应用服务器发送远程方法呼叫(RMI)调用的JAVA程序；在远端应用服务器上(通过RMI)调用实体BEAN的J2EE应用服务器会话BEAN等。
·以下所用术语“用户请求”是指由用户或应用发起的初始请求，该请求由未被本文所公开的技术监控的层发起。用户请求是组成事务的请求链中的第一个。请求链可以表示为树型结构，其中用户请求在该树的根节点。
·以下所用术语“UOW”是指在分配给该层的可用请求的处理程序集上执行的应用程序代码(即UOW调用)。UOW与源和目的关联，可以包括参数(用于指示应用程序代码的操作)，并使用在单个层中的层级资源。
·以下所用术语“处理程序集”是指在给定层中执行UOW的任何线程、子处理、数据库会话等。在层中对请求进行排队，直至分配可用的处理程序集和对该处理程序集分配应用程序代码(即，UOW)。处理程序集为轮流执行不同应用程序代码的常规执行单元。
·以下所用术语“请求环境”是指初始从用户请求获得的并随着事务请求链发送到随后请求的特征组，其在这个过程中可以在任一层被修改。请求环境使所公开的技术能够识别、跟踪和按优先级排列作为由用户请求发起的单个事务的一部分所得到的请求链。例如，请求环境可以包括提交请求的用户特征、作为请求主题的项目特征、发起请求的地理位置、请求生成的时间和日期、请求所属的相关事务组等。请求环境的某些部分在随后层可以被修改。例如，在第一层被加入请求环境的用户请求的服务类别可以被随后的层所修改(即使用所公开技术的另一个实施例)。
·以下所用术语“请求类别”是指共享一个或多个预定请求环境特征的一类事务。例如，“股票投资组合概要查询”就可以属于“股票投资组合概要查询”请求类别，也可以和另一个事务(例如“股票投资组合历史查询”)一起作为更大范围的“股票投资组合查询”请求类别的一部分。每个请求类别都依据动态服务类别策略进行处理。一旦对该用户请求分配请求类别，则在由该用户请求发起的事务中对每一个随后的请求自动分配请求类别。
·以下所用术语“服务类别”指用于表示对请求进行处理的重要性级别的各种参数的等级的组。该参数可以包括分配给请求的优先级、分配给请求的CPU百分比、分配给请求的存储空间、使得输入/输出(I/O)设备分配给请求和对请求进行访问的优先级等。根据合适的动态服务类别策略，由各个环境代理将服务类别分配给在给定层执行的请求。
·以下所用术语“服务类别策略”是指这样一种规则，即对于在其上正处理请求层，将服务类别分配给在请求类别中的请求。每一个环境代理都包含特定层服务类别策略的组，其中每个特定服务类别策略对于与该环境代理关联的特定层将服务类别映射到请求类别。“跨层服务类别策略数据库”描述了对于在多层计算环境中所有的层从服务类别到请求类别的映射组。需要注意的是用户可以定义一组服务类别策略。这种策略下面被称为“用户定义的服务类别策略”。
·术语“动态服务类别策略”包含了当前有效的请求类别到服务类别的映射。支持多个服务类别策略，并且在系统运行的不同时间可以安排不同的策略，以反映工作负载的变化或者各种系统事件，或者仅仅是一个特别的决定。
现在请参见图2，该图为依据所公开技术的实施例而建立和实施的应用性能管理系统的示意图，该系统通常用100表示。系统100运行在多层计算环境中，所述多层计算环境通常用132表示。计算环境132包括运行第一应用的第一客户端112、运行第二应用的第二个客户端114、第一层102、第二层104、第三层106、第四层108和第五层110。第一层102为WEB服务器。第二层104为应用服务器，即应用服务器A。第三层106为另一个应用服务器，即应用服务器B。第四层108也为应用服务器，即应用服务器C。第五层110为数据库。
第一层102与第一客户端112、第二个客户端114和第二层104相连。第二层104还与第三层106相连。第三层106还与第四层108和第五层110相连。第四层108还与第五层110相连。运行在第一客户端112的第一应用发起用户请求R1。运行在第二客户端114上的第二应用发起用户请求118。
系统100包括环境代理122、124、126、128和130，和环境网络管理服务器(CNMS)120。在如图2所示的实例中，存在与每一层关联的单独的环境代理。特别地，环境代理122、124、126、128和130分别与第一层102、第二层104、第三层106、第四层108和第五层110相关联。环境代理122、124、126、128和130都与CNMS 120相连。根据计算环境132中的层的连接关系，每个环境代理也会与其他环境代理相连。特别地，环境代理122与环境代理124相连，环境代理124还与环境代理126相连，环境代理126还与环境代理128和环境代理130相连以及环境代理128也与环境代理130相连。
第一客户端112需要来自第一层102的服务，因此第一客户端112向第一层102发送用户请求R1。用户请求R1在第一层102的请求进入端口排队等候。第一层102分配可用的处理程序集X1来处理用户请求R1。在处理用户请求R1的同时，在处理程序集X1中执行的应用逻辑确定在第二层104不提供附加信息或操作的情况下，处理程序集X1不能完成用户请求R1的处理。因此，第一层102向第二层104发送新请求R2，以请求附加信息或存在。第二层104分配可用的处理程序集X3来处理请求R2。在处理程序集X2中执行的应用逻辑确定处理程序集X2需要由第三层106提供的进一步信息或操作。因此，第二层104向第三层106发送新请求R3。第三层106分配可用的处理程序集X3来处理请求R3。需要注意的是，每个请求R1，R2，R3都是从第一客户端112上运行的应用所发起的单个事务的一部分。
处理程序集X3完成处理。第三层106响应于来自第二层104的先前请求R3，向第二层104返回应答R3’。在处理程序集X2中执行的应用逻辑接收应答R3’并继续执行。一旦处理程序集X2完成执行，则第二层104响应于来自第一层102的先前请求R2，向第一层102返回应答R2’。在处理程序集X1中执行的应用逻辑接收到应答R2’并继续执行。一旦处理程序集X1已经完成处理，则第一层102返回对用户请求R1的应答R1’，现在已完成用户请求R1的服务。
每个环境代理都在请求进入端口和请求退出端口(在图2和图3中表示的小圆圈)监控与其相关联的层。环境代理通过检测请求进入或退出所关联的层来监控经过所关联的层的通信量。如果该请求为用户请求(即，请求链中的初始请求)，则第一层的环境代理识别用户请求的请求环境，将用户请求分成请求类别，并基于动态服务类别策略为用户请求分配服务类别。每个环境代理都具有策略高速缓存(未示出)，其包含对于与各环境代理相关联的层的特定层服务类别策略的组。CNMS 120利用特定层动态服务类别策略周期性地更新每个环境代理。如果该请求不是用户请求，则环境代理从与发起请求的层相关联的环境代理接收与请求的请求环境相关的信息以及与请求相关的附加信息(即“环境信息”)。需要注意的是，在环境代理中继至另一环境代理的环境信息中包括的最少信息至少是请求ID、事务ID、请求类别和与该请求关联的环境相关数据。环境相关数据可以包括请求环境本身，或者对处于另一位置的请求环境的指示(例如，指针)。
环境代理将接收到的环境信息和在该层上执行的请求进行关联。环境代理依据分配给请求的服务类别，通过各层可以影响请求的处理。例如，环境代理可以在层的请求进入端口调整请求队列的次序，命令层分配或拒绝用于执行该请求的来自该层的计算资源。如果环境代理检测到请求已经退出了相关联的层，则环境代理将环境信息中继至与该请求被发送到的层相关联的另一环境代理。所述另一环境代理将接收到的环境信息与相关请求和在与所述另一环境代理关联的层上执行请求的处理程序集进行关联。
需要注意的是，环境代理监控层的请求进入端口和请求退出端口，而不是广泛的监控层自身内发生的活动(例如执行请求的处理程序集)。结果，从软件的角度，系统100并不干预给定层的实际操作或在该层中执行的用户应用代码，系统100为层添加最小附加负载。
环境代理还通过动态层扩展(DTE-图2中未示出)连接相关联的层。DTE使环境代理收集与在该层上执行UOW相关的数据。为了实现该目的，环境代理可以将原始数据发送到CNMS 120。环境代理还可以把统计数据发送到CNMS 120，以用于集中分析。环境代理可以从CNMS 120接收信息(例如行为映像(下面参考图6定义))和用于处理不同类型请求类别的新动态服务类别策略。环境代理在随后的图8介绍中进行详细阐述。
特别地，环境代理122监控第一层102，并检测到用户请求R1已经进入第一层102。环境代理122识别用户请求R1的请求环境，并将用户请求R1与处理该请求的处理程序集X1相关联。环境代理122将用户请求R1分类为适合的请求类别。环境代理122通过在环境代理122中存储的服务类别策略组中检索适当的动态服务类别策略来确定在第一层102中的用户请求R1的服务类别，并将确定的服务类别分配给用户请求R1。环境代理122将分配的服务类别添加到请求环境中。当新请求R2退出第一层102并进入第二层104时，环境代理122监测到请求R2与用户请求R1相关。然后环境代理122向环境代理124发送与用户请求R1的请求环境相关的信息、以及请求ID、请求类别和与请求R2相关的事务ID。
现在请参见图3，该图为在图2所示系统的两个环境代理之间中继的信息的示意图。环境代理122发送消息134给环境代理124。消息134包括请求R2的请求ID、请求R2的事务ID、环境代理122为请求R2划分的请求类别和请求R2的请求环境。环境代理124接收消息134，并通过在环境代理124所存储的服务类别策略组中检索适当的动态服务类别策略来确定在第二层104上将被执行的请求R2的服务类别。环境代理124将所确定的服务类别分配给请求R2。例如，请求R2的请求类别为组“15”。环境代理124检索将服务类别映射至在第二层104上执行的请求类别为“15”的请求的动态服务类别策略。合适的服务类别策略为该请求分配优先级“5”、CPU分配“90”、存储器分配“48”和I/O设备访问优先级“2”。然后，环境代理124可以依据所分配的服务类别来影响请求R2的处理。
系统100基于请求环境执行应用性能管理。系统100识别请求，与每个请求关联的特征在与该层所关联的环境代理上可用。这些特征可以包括在哪里发起请求、在事务中哪些请求先于该请求和该请求是什么类型。例如，环境代理124识别出在第二层104上运行的请求R2与由第一层102处理并且在第一客户端112发起的用户请求R1相关联。由于给定层的环境代理知道请求环境和在各层正被执行的每个请求的请求类别，因此环境代理可基于服务类别策略来确定各请求的适当的特定层服务类别。CNMS 120可以对于各不同请求类别来设置在多个层之间的整体管理策略，并因此更新环境代理。
现在请参见图4，该图为在图2所示系统的两个层上的取样请求生命周期的示意图，所述取样请求生命周期通常用140表示。取样生命周期140描述了当请求在多层计算环境132(图2)中接受服务时该请求所经历的多个阶段。上文提到，请求可以产生能在相同层中的内部(通过向正执行UOW的相同层发送请求)或外部(向其它层发送请求)进一步生产附加请求的UOW调用。因此，用户请求通常生成一系列UOW调用，其中的每个调用都可以在不同的层上执行。这些UOW调用可以是同步的(即，执行UOW调用的处理程序集等到被调用的UOW应答之后再继续处理)，也可以是异步的(即，执行UOW调用的处理程序集不等待被调用的UOW应答而继续处理UOW调用)。在以上两种情况下，被调用层N+1上的UOW专用于由调用层N所请求的服务。在同步处理方式下，出现这样的情况，即在层N上的调用UOW等待在层N+1上的被调用UOW结束(即，在层N+1上的UOW被释放)。在其它情况下，在层N+1上被调用的UOW可以由调用层多次引用，直至在层N+1上被调用的UOW结束。
在阶段142中，在计算环境132中第一请求被发送给层N(即任一个代表层)。第一请求在层N上对于先前层或用户应用产生UOW调用，以提供服务。第一请求在层N上的队列158中等候。
在阶段144中，在层N上第一请求退出队列158并对其分配UOW，即UOW-A。UOW分配包括从层N中的处理程序集162中的一个分配可用处理程序集，和调度在该处理程序集上运行的请求应用程序代码。当目标层资源可用并且能够在层N上将应用程序代码分配给可用处理程序集时，发生UOW分配操作。在取样本生命周期140中，UOW-A在层N上开始执行。
在阶段146，UOW-A向层N+1发出第二请求。随后层N+1调用UOW-B来执行层N的请求。在阶段148，层N+1调用UOW-B来执行由层N发送的第二请求。所述第二请求在层N+1上的队列160中等候。在阶段150，第二请求退出队列160，并且对所述第二请求分配UOW-B。UOW-B的分配导致从层N+1中的处理程序集164中的一个分配可用处理程序集给UOW调度的应用程序代码，以及调度在该处理程序集上运行的请求应用程序代码。然后，由此UOW-B开始在层N+1上运行。需要注意的是，由于UOW-B调用是同步的，因此处理UOW-A的处理程序集在等待来自UOW-B的应答的同时并不继续处理。
在UOW-B调用是异步的情况下，处理UOW-A的处理程序集从层N+1接收对于从UOW-A发送给层N+1的第二请求已被接受的确认。在接收到该确认时，处理UOW-A的处理程序集继续执行，直至该处理程序集最终返回对第一请求的应答。在层N+1接受异步的第二请求之后，所述第二请求在队列160中等候。随后，由处理所述第二请求的一个或多个处理程序集读取所述第二请求，直至这些处理程序集中的一个也将第二请求从队列160中移除。处理第二请求的每个处理程序集也可以将第二请求变成新用户请求，所述新用户请求可以自身开始另一请求链，从而开始新的事务。
例如，包括异步请求的事务可以是用户确认在电子商务网站上对书籍购买的事务。购买请求向用户返回用于通知订单正在处理中的屏幕，并且通知用户(例如，通过电子邮件或文本消息)。同时将同一购买请求放置于随后通过以下处理程序集来处理购买请求的消息队列中，所述处理程序集包括向信用卡公司发送最终确认请求的处理程序集；向仓库发送购买订单请求的处理程序集；向计费系统发送结账请求的处理程序集等。
在阶段152中，UOW-B响应于UOW-A的先前调用向UOW-A发送应答，UOW-B的执行现在完成。第二请求现在终止。在阶段154中，UOW-A接收到应答，并继续执行，此时UOW-B实际上已被层N+1释放。然后，UOW-A可以继续执行。在调用UOW发送请求的时间和调用UOW从被调用UOW接收到应答的时间之间的时间段被称为“潜伏”期，或称作对给定UOW请求的响应时间。
在阶段156中，UOW-A完成执行，并且第一请求终止。需要注意的是，在完成之前，UOW-A可以要求另一层的服务，并调用进一步请求来提供此服务。
需要注意的是，在阶段150中在UOW-B被分配并在层N+1上开始执行后，可能发生无法恢复的错误(例如程序异常)。依据所公开技术的实施例，与层N+1关联的环境代理将记录错误，并将此错误与在层N上由被调用的UOW-A的用户请求所开始的事务相关联，从而提供发生在层N+1上的错误的特征。
现在参见图5，该图为依据所公开技术的实施例而建立和实施的应用性能管理系统的示意图，该系统通常用200表示。系统200运行在多层计算环境中，所述多层计算环境通常用248表示。计算环境248包括客户端214、第一层202、第二层204、第三层206、第四层208和第五层210。第一层202为WEB服务器。第二层204为应用服务器A。第三层206为应用服务器B。第二层204和第三层206都处于单个主机212上。第四层208为另一应用服务器，即应用服务器C。第五层210为数据库。第一层202与客户端214和主机212相连。主机212还与第四层208和第五层210相连。第四层208还与第五层210相连。
系统200包括多个动态层扩展222、224、226、228和230，多个环境代理232、234、236和238，多个本地日志240、242、244和246，环境网络管理服务器(CNMS)216，服务水平目标(SLO)策略数据库218和管理工作站220。每一层都包含动态层扩展(DTE)。具有与每个层相关联的环境代理。具有与每个环境代理相关联的本地日志。根据在计算环境中层的连接关系，给定层的环境代理与该层中的DTE(或几个DTE)相连，与和环境代理相关联的本地日志相连，以及与其它环境代理相连。每个环境代理还与CNMS 216相连。CNMS 216与SLO策略数据库218相连。管理工作站220与CNMS 216和SLO策略数据库218相连。
特别地，第一层202包含DTE 222。环境代理232与第一层202相关联。本地日志240与环境代理232相关联。第二层204包含DTE 224。第三层206包含DTE 226。由于第二层204和第三层206都处于主机212上，所以仅存在与第二层204和第三层206两者相关联的单个环境代理234。需要注意的是，环境代理234与DTE 224和DTE 226都直接相连。本地日志242与环境代理234关联。第四层208包含DTE 228。环境代理236与第四层208关联。本地日志244与环境代理236相关联。最后，第五层210包含DTE 230。环境代理238与第五层210相关联。本地日志246与环境代理238相关联。环境代理232与环境代理234相连。环境代理234还与环境代理236和环境代理238相连。环境代理236还与环境代理238相连。
动态层扩展在特定的预定点与层相连。这些预定点为层的请求进入端口、层的请求退出端口和在该层内的可能附加区域(例如层控制端口)。根据所公开技术的请求端口是在由层处理请求之前或者由层处理请求之后用于管理这些请求的层中的模块。这种请求端口可以是到在层入口的请求队列的连接点(即，入口、出口或者任何其它的访问机制)。由于请求需要来自由处理程序集在层上运行的应用程序代码的服务，因此各请求端口都是处于应用级而不是网络级。需要注意的是，依据所公开技术的请求端口不是处于网络级(例如不是TCP/IP或UDP端口)。
所述DTE位于与该层所关联的同一层主机上(即DTE位于层正在运行的至少一主机上)。DTE的功能之一在于获得请求环境。DTE还监控层的请求进入端口和请求退出端口，以检测进入请求和退出请求。DTE为用户请求分配事务ID，并获得进入或退出该层的每个请求的请求ID。DTE在以下图7描述中进行详细阐述。
环境代理保持在给定请求、该请求的被调用UOW和与该请求在同一事务中的用户请求的请求环境之间的关联。环境代理将分配给每一请求的请求环境(即环境相关数据)中继至处理其它层的其它环境代理。环境代理可以中继整个请求环境，也可以中继请求环境中的一部分。而且，环境代理可以将请求环境本身或指示(例如指针)中继至处于另一位置的请求环境。需要注意的是，环境代理没有必要处于与该层相同的主机上，但是在所公开技术的优选实施例中却属于这种情况。环境代理在下面图8的描述中将进行详细阐述。CNMS 216收集并分析性能数据。SLO策略数据库218存储跨层服务类别策略，并不断被更新。
现在参见图6，该图为图5所示多层计算环境中的两个层的示意图。需要注意的是，图6所示的第四层208和第五层210表示在计算环境248中任意两个连续的层(例如层N和层N+1)。
进入第四层208的请求在第四层208的请求进入端口的队列262中等候。第四层208调用UOW来执行该请求。该请求退出队列262，并且第四层208通过从处理程序集252将可用处理程序集分配给UOW以及调度在该处理程序集上运行的请求应用程序代码，来将UOW分配给该请求。UOW在第四层208上执行。然后，该UOW可以从第五层210请求服务。所述新请求在请求退出端口退出第四层208，并在第五层210的请求进入端口的队列264中等候。第五层210调用UOW来执行所述新请求。所述新请求退出队列264，并且第五层210通过从处理程序集254将可用的处理程序集分配给UOW以及调度在该处理程序集上运行的新请求的应用程序代码，来将UOW分配给新请求。DTE 228监控第四层208的请求进入端口和请求退出端口，以分别检测进入或退出第四层208的请求。
动态层扩展涉及在不更改应用程序代码的情况下在请求的整个生命周期内对该请求进行跟踪。DTE动态地连接到层环境，其中DTE侦听除了应用程序代码之外的请求环境。请求跟踪包括获得请求环境、将请求与层上的UOW关联和从层上的UOW接触与请求的关联。DTE还收集来自层的性能、可用性及错误的指标。DTE还可以例如通过调整层请求进入端口的请求队列次序、分配用于处理请求的计算资源(例如CUP、存储器、I/O等)或者更改处理程序集或分配资源的优先级等方式来动态调整该层上请求的处理。将参考这里描述的图9、10和11来详细阐述这些任务。
需要注意的是，存在两种在环境代理之间中继请求环境的选择带内和带外。在带内环境中继中，当请求退出某层而进入下一层时，将请求环境添加到请求本身(即，到有效负载上)。因此，当请求及其随后请求在不同层间被处理时，将所更新的请求环境添加到请求调用中。相反，带外中继不涉及将请求环境添加到请求调用的处理。而是环境代理相互间直接发送环境信息。环境代理向另一个环境代理发送请求环境。DTE检索来自该环境代理的请求。需要注意的是，与系统200(图5)类似的系统的每个环境代理都使用带外技术将请求环境中继到另一环境代理。
再参见图5，系统200进行行为映像处理(activity profiling)。行为映像处理包括创建行为映像。行为映像包括在请求跟踪期间获得的综合事务、层和系统级性能指标与统计分析。例如，性能指标可以包括在层上的请求所用时间、请求服务时间、消耗的CPU时间等。行为映像数据是根据时间来收集的，并用于监控(即在GUI上的显示)和支持由用户生成用户定义的服务类别策略的操作。行为映像控制台(未示出)是用于显示由环境代理所收集的性能和可用性集成数据的GUI组件。该性能和可用性集成数据包括按不同种类(例如层、请求类别、事务等)的行为映像数据的概要视图(summaryview)。位于CNMS 216中的行为映像处理引擎(未示出)执行行为映像处理。
每个环境代理都具有收集在每个层中的执行细节信息的任务。DTE使环境代理能够收集与在该层上UOW的执行相关的数据。然后，环境代理将所收集的信息发送给CNMS 216。对于每个UOW所存储的信息包括开始时间、该UOW被分配的请求的请求ID、该UOW被分配的请求的事务ID、该UOW被分配的请求的请求类别、用户细节、生产网络地址的细节、该UOW被分配的请求的服务类别、结束时间、资源消耗(例如CPU)等。
环境代理将与当前正在执行UOW相关的信息存储到存储器中(未示出)。当UOW在该层上完成执行时，环境代理将该信息传送到最近历史数据存储点中(未示出)，该存储点存储在与环境代理相同的本地层主机的磁盘(未示出)上。在某一时间段之后，环境代理将信息的条目从最近历史数据存储点转移到概要数据存储点(未示出)。将概信息存储为概要超过给定时间段(例如在半小时的时间段内所收集的指标平均值)。摘要数据存储点中的信息是轮换存储的。轮换是基于周期存储的(即在积累了一定量的轮换之后这些信息进行循环)。
系统200还包括服务类别策略。如上文所述，服务类别策略是指对于在其上正处理请求的层，将请求类别分配给在请求类别中的请求的规则。位于环境代理中的实时服务类别策略引擎依据请求环境中信息(例如请求类别、先前执行的具有相同请求环境的请求的性能特征)以及依据活动服务类别策略将适合的服务类别分配给概请求。另外，服务类别的分配还可以考虑附加的信息，例如对于每个请求类别的性能指标组。该组性能指标具有请求类别的特征，并创建对于典型性能操作的基线。该过程使用了在所有层之间创建的日志数据和与其相关联的请求类别。这些请求类别在SLO策略数据库218中以树型结构存储。服务类别策略引擎添加并更新与每个请求类别相关的信息，并据此更新SLO策略数据库218。
在第一层中对于用户请求确定服务类别，然后在请求环境中，该服务类别随请求从一层传递至另一层(从一个环境代理到另一个环境代理)。无需访问CNMS 216就可以确定动态服务类别策略以及到服务类别的映射。另外，每个环境代理在其中具有最新的策略高速缓存(未示出)，从而在本地执行到合适的服务类别的映射。
在周期性时间间隔、或在必要时和在需要时(例如，当用户希望查看在性能控制台上当前运行的请求时)，行为映像处理引擎对关于完成的和当前运行的请求的信息来轮询本地环境代理。或者，在固定时间间隔、或在到达阈值(即记录的数量)时，行为映像处理引擎可以指示每个环境代理开始将新记录发送至该行为映像处理引擎。行为映像处理引擎收集对于每个请求的数据，进行计算(例如平均值、方差等)，并且在不同的时间间隔将结果存储在SLO策略数据库218中，作为分析每个请求类别的基线。基于存储在SLO策略数据库218中的可用数据，位于CNMS 216中的服务类别策略生成引擎创建一组规则，这些规则用作对新服务类别策略的推荐。CNMS 216使用这些推荐来确定服务类别策略。在SLO策略数据库218中存储这些服务类别策略。
需要注意的是，SLO策略数据库218存储自动生成的策略和用户定义的服务类别策略。用户可以通过系统200的用户界面(未示出)或通过编辑环境代理的配置文件来创建一组服务类别策略(即，用户定义的服务类别策略)。用户定义的服务类别策略的创建包括行为映像的用户分析，以及由CNMS 216获得对被提议的服务类别策略的许可。
环境代理从CNMS 216接收更新的服务类别策略。需要注意的是，无论新服务类别策略是自动生成还是用户定义的，对环境代理来说都是透明的。环境代理对请求分配位于环境代理的本地策略高速缓存中的适合的特定层动态服务类别策略中所指定的服务类别。
或者，环境代理可以对请求分配与在某些情况下(例如，如果层当前不能提供用于实现该服务类别所需的全部资源，如果大量的高优先级请求进入该层并导致对于低优先级请求的资源短缺等)由动态服务类别所指定的不同的服务类别。又或者，环境代理可以更改请求的请求类别，随后为请求分配由用于新请求类别的适合特定层动态服务类别策略所指定的服务类别。
系统200还执行请求分类。这种分类包括根据不同的标准将多个请求(其中的每个请求都由它们的事务ID和请求环境指定)分类成请求类别。自动请求分类处理收集与请求关联的一般信息(例如，头信息、诸如查询字符串的参数、在HTTP请求类型的情况下的统一资源定位符(URL)参数等)。当相同请求类别的另一个请求到达时，该请求将以与处理该请求类别中的其它请求相类似的方式进行处理。依照在相关行为映像中的请求类别性能特征，请求类别可以分成不同的种类(例如，具有大于两秒的响应时间的请求类别组)。请求类别分组处理可以应用于报告的目的，以实现请求类型性能数据的较高级概要视图。
系统200也支持用户定义的分类处理，在所述用户定义的分类处理中，用户基于用于自动分类处理的同一请求信息来创建对请求进行分类的规则。用户可以通过系统200的用户界面(未示出)来创建分类规则。自动请求分类处理使用了一种如H.Zhu和T.Yang(2000年加州大学圣芭芭拉分校计算机科学系技术报告TRCS00-13的“动态WEB内容的基于类的高速缓存管理”)所述的“基于类的高速缓存管理”算法。分类处理的输出是表示请求类别和父类别的树型(即在自动请求分类处理中)或者是分类规则组(即在用户定义的分类处理)。分类处理所有的结果都存储在SLO策略数据库218中。
如在动态服务类别策略中所定义的，系统200也用于对每一层和每个被监控的层来强化服务类别。由DTE和环境代理两者来执行策略强化。可以通过控制在每层中的请求排队(即在该层中实际处理的请求的顺序)，或通过临时更改在执行期间运行该请求的处理程序集的处理优先级来实现所述强化操作。
所述强化操作的实现取决于特定的层结构。例如，在数据库层中的实现可以包括使用数据库资源管理方案，以根据适当的服务类别策略控制会话资源分配。这种实现的另一实例是通过以下操作来使用J2EE应用服务器的应用，以在应用服务器层中实现所述强化操作，其中所述操作包括扩展应用服务器WEB队列以支持请求优先级化分，扩展企业级JavaBEAN(EJB)队列以支持优先级化分，控制Java线程优先级等。
现在参见图7，该图为图5系统的动态层扩展的示意图。需要注意的是，图5所示第四层208的DTE 228是表示在系统200中所有的动态层扩展。DTE 228包括多个软连接(hook)或用于进入第四层208的侦听点。用标号266和268表示的这些连接用于收集请求相关信息和性能数据。这些连接也可以更改用于执行UOW的处理程序集的优先级。连接将所收集到的信息放置在专用消息队列270中。软连接和侦听技术依赖于特定环境。例如，该环境可以是WEB服务器、基于JAVA的J2EE应用服务器、数据库、消息发送服务器等。需要注意的是，侦听点266或268可以由控制者实时激活或停止。
DTE 228还包括在第四层208上运行的进程。该进程处理来自侦听点的消息，将消息通信至环境代理236，将消息返回至侦听点，并执行DTE的管理控制功能(例如，开始/停止跟踪请求，设置或去除软连接)。DTE 228包括DTE后台程序(daemon)272、DTE管理器274、DTE消息发送模块276、DTE日志事件处理器278和DTE通信接口280。
DTE后台程序272是在该层中运行的人工创建的处理程序集。该DTE后台程序272执行与不需保持请求的通知事件关联的异步处理。报告事件有两种情况。在第一种情况下，不需要保持请求，直至接收到响应。例如，当报告一请求已经结束时，不需要对该请求进行延迟，直至在已经实际通知环境代理之后。第二种情况下，在处理重新开始前，该请求需要保持某一时间段。例如，当获得请求的服务类别或执行请求的分类处理时，在由环境代理确定请求类别和服务类别之前，不能开始处理，否则可使用错误的服务类别或错误的请求类别进行处理。
DTE后台程序272用于处理第一种情况，即不需保持请求的情况。处理是异步进行的，从而请求没有被延迟。由此请求很快(几乎立即)被释放。DTE后台程序272具有与其关联的队列270。在由侦听点266和268通知请求进入或请求退出之后，DTE后台程序272从队列270中提取这些通知，并执行任何必要的附加处理。
DTE管理器274使DTE228接收与应如何处理请求相关的消息。例如，这些消息可以包括停止跟踪请求、继续跟踪请求但停止优先级化分等。DTE消息模块276使用消息与环境代理236进行通信。例如，这种消息可以包括UOW的开始和结束、UOW和给定请求的关联等。DTE日志事件处理器278记录涉及DTE运行的跟踪信息为日志，以及记录由DTE 228发出的报警为日志。这些记录为日志事件可以被发送到多个目的地，例如本地文件、系统消息控制台、系统日志等。DTE日志事件处理器278支持多个工业标准协议，例如简单网络管理协议(SNMP)等。DTE通信接口280用作DTE 228和环境相关代理236之间的接口。DTE通信接口280将从环境代理236的代理消息发送模块286发送的消息中继至DTE 228。DTE通信接口280还将从DTE228的DTE消息发送模块276发送的消息中继至环境代理236。支持多个通信协议，每个DTE使用在其构架上可用的最有效的通信方法，例如进程间通信，传输控制协议/互联网协议(TCP/IP)等。
现在参见图8，该图为图5所示系统的环境代理的示意图。需要注意的是，图5所示的第四层208的环境代理236表示在系统200中所有的环境代理。环境代理236经由多种机制(例如TCP/IP、进程间通信信道等)从DTE228接收通知。所述通知为层内所发生的事件通知，例如请求环境的获得、UOW的开始、UOW的结束、UOW的资源消耗、在远处的层上UOW的调用/分配、在远处的层上UOW的应答/释放等。环境代理236包括代理日志事件处理器282、代理通信接口284、代理消息发送模块286、环境表管理器288、分类管理器290、策略管理器292和代理管理器294。
环境代理236将代理日志事件处理器282用于内部事务管理的目的，以及用于记录由环境代理236发出的报警作为日志。代理日志事件处理器282记录进入环境表的信息作为日志(下文将进行介绍)，也用于内部跟踪和消息发送的目的，例如用以检测在环境代理236内部发生的运行异常(即问题或错误)。这些被记录为日志的事件可以被发送给多个目的地，例如本地文件、系统消息控制台、系统日志等。代理日志事件处理器282支持如SNMP等的多个工业标准协议。
代理通信接口284用作DTE 228和环境代理236之间的接口。代理通信接口284将从DTE 228的DTE消息发送模块276发送的消息中继至环境代理236。代理通信接口284还将从环境代理236的代理消息发送模块286发送的消息中继至DTE 228。可存在多个用于连接DTE 228和环境代理236的信道，以保障在上述两者之间快速可靠的通信，并且这些信道中至少有几条信道是一直打开的，例如高优先级信道和管理信道。对于不同类型的消息，还存在每种类型信道的多个连接。因此，代理通信接口284可用于容纳这些不同的可能性。
代理消息发送模块286向与远处的层相关联的其它环境代理通知请求已经被发送给所述远处的层。代理消息发送模块286还使用消息与DTE 228通信。例如，这种消息包括UOW的开始或结束，UOW和请求的关联等。代理消息发送模块286通过代理通信接口284与DTE 228进行通信。
环境表管理器288用作环境代理的记录器。环境表管理器288中维护有称为“环境表”的交叉参考表，其用于将运行在层上的UOW和它们的请求环境相关联。请求环境可以来自当前层(即在用户请求的情况下)，从来自请求执行链的先前层中继，或以上两者(即请求环境被修改或在其中加入新信息)。请求环境表储存与每个请求相关的信息(例如，事务ID、请求类别、服务类别、请求源等)。在代理消息模块286接收到来自DTE 228的消息之后，代理消息模块286访问环境表，并查询信息记录。环境表管理器288基于与请求相关的信息和环境表中存储的数据来识别请求。由此，环境代理236获得与进入该层的请求相关的信息，例如请求类别、服务类别以及与请求关联的其它相关信息。
分类管理器290和策略管理器292用于处理进入第一层的每个用户请求。当用户请求第一次进入计算环境中时，在环境表中不存在与该用户请求相关的信息。因此需要对此用户请求进行分类。在分类阶段，收集在请求进入端口关于用户请求已知的所有信息。例如，如果用户请求是HTTP请求，则这种信息包括HTTP头、查询字符串、URL参数等。对于在每一层中使用的每种类型的协议，都具有对用户请求实际分类的通用插件。
分类处理通过将技术请求相关的信息(例如HTTP请求)解释成与商务处理(例如检索银行帐户余额)相关的正式请求类别来从用户请求中提取商务前景信息。将用户请求处于特定的请求类别。用户请求可以被识别为商务处理的一部分或一组相关事务。例如，帐户余额的检索可以是申请抵押这一较大过程的一部分。当从环境代理236将信息传送到CNMS 216时，CNMS216可以确定行为映像，并检测对于请求类别的请求行为趋势。
策略管理器292为请求分配服务类别。策略管理器292接收分类管理器290的输出，并基于请求类别、请求环境和动态服务类别策略，来确定给定请求的服务类别。例如，策略管理器292可以设置某一请求类别的所有请求，以具有比不同请求类别的所有请求较高优先级的服务类别。环境代理通过依据动态服务类别策略更新具有合适的服务类别的请求环境来对于在与其关联的层上正处理的请求分配服务类别。
跨层服务类别策略数据库包括在多层计算环境下对于所有层的从服务类别到请求类别的映射组。根据正处理请求的层，可对属于某请求类别的每一请求分配不同的服务类别。参见图2，可以在第一层102上对用户请求R1分配具有较低优先级的服务类别，在第二层104上对请求R2分配具有较高优先级的服务类别，以及在第三层106上对请求R3分配具有中等优先级的服务类别。跨层服务类别策略存储在SLO策略数据库218中。跨层服务类别策略可以自动生成(即系统定义)，也可以由系统的用户定义。
另外，本层的主管(例如数据库管理员)可以对该层进行管理控制，如果认为必要可以修改该层的服务类别策略。层主管可通过该层的环境代理来更改分配给请求的服务类别。层主管对该层上的运行所有处理具有充分的总体认识。需要注意的是，还可以存在系统的总主管，该总主管通常是运行用户应用本身，并对系统全局负责的人。
需要注意的是，在对用户请求的初始分类和策略分配之后，当环境代理将此信息从一层中继至另一层时(即存储在每一层的环境表中)，请求类别被保持用于同一事务的随后的请求。通过这种方式，在每一层环境代理识别请求所属的请求类别，请求所在的特定层服务类别以及与请求相关的其它信息。
代理管理器294是对于CNMS 216的接口。代理管理器294向CNMS 216通知历史数据。例如，DTE指示UOW已经结束时，与该UOW关联的信息不需保存在环境表中。然后，将所述信息从环境表发送到代理管理器294，其中代理管理器294对所述信息进行存档，并周期性地将所述信息发送给CNMS 216。代理管理器294还从CNMS 216接收新动态服务类别策略、环境代理的新配置等。代理管理器294也可以被实时查询，以获得状态指示。所述状态指示可以包括环境表中当前存储什么信息，哪些UOW正在运行等。
现在参见图9，此图为示出依据所公开技术的另一实施例而实施的在获得请求环境的处理和随后处理中所包括的阶段的框图。在过程310，获得了请求环境。新用户请求被识别，并且其请求环境被DTE软连接所侦听。参见图5，DTE 222获得进入第一层202的用户请求的请求环境。
在过程312，获得的请求环境被标准化。DTE将该请求环境转换成与所有类型的层(例如数据库，应用服务器等)相同的标准格式。DTE对用户请求分配唯一的标识符(即事务ID)，该标识符用于识别在由用户请求发起的事务中的该用户请求和随后的请求。DTE还从该层获得用户请求的请求ID。参见图5，DTE 222将获得的请求环境转换成标准格式，对用户请求分配事务ID，并获得用户请求的请求ID。
在过程314，DTE向与该层关联的环境代理发送请求环境、事务ID和请求ID。DTE通知环境代理已经发送了新请求环境。参见图5，DTE 222向环境代理232发送该用户请求的请求环境、事务ID和请求ID。
在过程316，用户请求被分类。环境代理应用基于请求环境来确定请求类别的特定层分类方案。参见图5，环境代理232将用户请求分类为某一请求类别。
在过程318，从在本地策略高速缓存中存储的服务类别策略中检索适合的动态服务类别策略。环境代理使用请求类别和可能的其它请求环境字段来检索动态服务类别策略。参见图5，环境代理232依据对于第一层202特定的用户请求的请求类别检索用于用户请求的适合的动态服务类别策略。
在过程320，依据检索到的服务类别策略来确定用户请求的服务类别，并将此服务类别分配给请求。随后环境代理可以将被分配的服务类别添加到请求环境中。参见图5，环境代理232将检索到的合适的服务类别策略的服务类别分配给用户请求，并将服务类别添加到请求环境中。
在过程322，对于由用户请求调用的UOW确定层优先级。从服务类别中提取用于执行UOW的处理程序集的本地优先级。参见图5，环境代理232从分配的服务类别中提取已分配给用于执行UOW的用户请求的处理程序集的本地优先级。
在过程324，环境代理将请求类别和优先级划分信息发送回DTE。此信息对于某些任务是必要的，例如更改在DTE中发生的处理程序集的优先级。参见图5，环境代理232向DTE 222发送对于执行UOW的处理程序集的所分配的请求类别和本地优先级。
在过程326，将请求环境和相关信息(例如请求类别和事务ID)转发至其它环境代理和环境代理的内部组件，其中最特别地包括储存请求的以及可检索请求环境和相关信息以用于进一步引用的环境表。参见图5，环境代理232将请求环境和与请求相关的附加信息(例如请求ID，事务ID，请求类别等)转发至与其相连的其它环境代理(例如环境代理234)以及环境代理232的内部组件，例如环境表管理器288、分类管理器290和策略管理器292(参见图8)。
现在参见图10，该图为示出依据所公开技术的另一实施例而实施的在图5所示系统的本地层上获得UOW分配的处理以及将请求与UOW关联的处理所包括的阶段的框图。如上文所述，UOW是在该层上在与请求关联的处理程序集中执行的应用逻辑。在过程340，由DTE获得UOW分配。当由该层初始调用UOW时，在进入请求进入在层的请求进入端口的队列时，在进入请求保持排队时，或者一旦在该层中资源可用时和请求退出队列时，可进行所述获得处理。参见图5，DTE 228获得由第四层208分配的UOW。
在过程342，DTE确定与UOW分配相关联的进入请求的请求ID。基于从先前层发送的信息(包括请求环境和连接UOW与请求的关联键，例如socket标识符等)来确定请求ID。参见图5，DTE 228基于从先前连接的层(例如第三层206)收到的信息确定与获得的UOW分配相关联的进入请求的请求ID。
在过程342发生时，可以出现请求环境和连接键还未到达DTE的情况。因此，可通过等待所述信息，或者通过在随后的阶段分配临时请求ID并且将进入请求与UOW关联来配置该系统，以继续进行处理。
在过程344，DTE向环境代理发送与UOW识别相关的信息和进入请求的已确定的请求ID。UOW识别信息是用于识别执行UOW的处理程序集的唯一特征组。由环境代理使用UOW识别信息来跟踪UOW。参见图5，DTE228向环境代理236发送用于UOW的关联信息(例如像socket标识符的连接UOW和请求的关联键)和进入请求的所确定的请求ID。
在过程346，环境代理检索在与UOW识别信息或请求ID相关的环境表中的条目。参见图5，环境代理232通过与获得的UOW分配或确定的请求ID关联的环境表管理器288(图8)定位在环境表中的条目。
如果该条目被找到，则在过程348，使用UOW识别信息和相关信息来更新该条目。参见图5，环境代理232使用所获得的UOW分配和相关信息的识别信息通过环境表管理器288(图8)来更新在环境表中的相关条目。
如果该条目未被找到，则在过程350，向环境表添加一个新条目。所述新条目包括进入请求的请求ID和所关联的UOW分配的识别信息。缺省的请求类别和服务类别与新添加的条目关联。参见图5，环境代理232通过环境表管理器288(图8)向环境表添加一个新条目，其中所述新条目包括进入请求的请求ID和UOW分配的识别信息，并将缺省请求类别和服务类别与新添加的条目关联。
在过程352，环境代理确定用于执行UOW的处理程序集的本地优先级，并在需要的情况下收集请求统计信息。参见图5，环境代理232提取用于执行UOW的处理程序集的本地优先级，其中所述UOW由来自分配给该请求的服务类别的请求所调用。
在过程354，环境代理对分配给进入请求的服务列表进行强化。参见图5，环境代理232例如通过更改用于执行由该请求调用的UOW的处理程序集的优先级水平、更改处理程序集的执行类型或者分配或拒绝用于处理该请求的计算资源来影响在第一层202的进入请求的处理。
需要注意的是，如果环境代理接收到与请求相关的新关联信息，则环境代理可随后更改服务类别、请求类别或请求环境的其他参数。这发生在这样的情况下，即请求环境从远处的环境代理到达与该层关联的环境代理的情况(例如参见图5，环境代理234从环境代理232接收关于请求的信息)。由于时间原因，环境代理可以获得与请求关联的UOW分配，然后在以后的阶段接收该请求的请求环境。
现在参见图11，该图为示出依据所公开的技术的另一个实施例而实施的在获得已发送至图5所示系统的远处的层的退出请求的处理以及将发送的请求与请求环境关联的处理所包括的阶段的框图。在过程370，由第一层的DTE获得从第一层发送到第二层的请求。参见图5，将请求从第一层202发送到第二层204。DTE 222在第一层202上获得退出请求。
在过程372，DTE确定退出请求的请求ID。参见图5，DTE 222确定从第一层202发送到第二层204的退出请求的请求ID。
在过程374，DTE向本地环境代理发送与UOW识别信息相关的信息和退出请求的已确定的请求ID。参见图5，DTE 228向本地环境代理236发送与UOW识别信息相关的信息和退出请求的已确定的请求ID。
在过程376，本地环境代理在环境代理表中检索与退出请求的请求ID或UOW识别信息相关的条目。参见图5，环境代理232通过环境表管理器288(图8)在环境表中定位与已确定的退出请求ID或UOW识别信息相关的条目。
如果该条目被找到，则在过程378中，使用UOW识别信息和相关信息来更新该条目。例如，可使用当前不在该条目中的退出请求的请求环境中的信息来更新该条目。参见图5，环境代理232使用UOW识别信息以及使用在相关条目中先前存储的退出请求的请求环境中的信息通过环境表管理器288(图8)来更新在环境表中的条目。
如果该条目未被找到，则在过程380中，向环境表添加一个新条目。所述新条目包括退出请求的请求ID和所关联的UOW分配的识别信息。将请求类别、服务类别以及请求环境中存储的其它请求特征信息添加到新条目中。如果在请求环境中不存在某些特征，那么将缺省特征(例如，请求类别和服务类别)与新添加条目关联。参见图5，环境代理232通过环境表管理器288(图8)向环境表添加一个新条目，其中所述新条目包括退出请求的请求ID和存储在退出请求的请求环境中的请求的特征。
在过程382，本地环境代理发送消息给远程环境代理(即退出请求被发送给的环境代理)。该消息包括退出请求的请求ID、事务ID和请求类别。参见图5，与第一层202关联的环境代理232发送消息给与第二层204关联的环境代理235。该消息包括退出请求的请求ID、事务ID及其请求类别。
在所公开技术的另一个实施例中，可以存在与多层主机相关联的单独的环境代理。需要注意的是，环境代理与DTE通信的方式使环境代理处于网络上的任何位置。还需要注意的是，环境代理通过对请求和UOW附加层标识符来保持对其的跟踪，从而对每个层提供分别的记录。例如，由于安全的考虑或者将环境代理添加至层主机所产生的用户额外负载的考虑，可使用这种实施例。
本领域的技术人员应该理解，所公开技术并不限于以上特别示出和描述出的内容。然而，所公开技术的范围仅由如下权利要求来限定。
权利要求
1.一种用于监控多层计算环境中的所选层的装置，所述装置包括环境代理，其与所述计算环境的所述所选层相关联，以及与其它环境代理相连，每个所述其它环境代理与所述计算环境的各个层相关联；和动态层扩展，所述动态层扩展与所述环境代理相连，以及至少与所述所选层的请求进入端口相连，至少用于监控通过所述所选层的请求通信量，所述被监控的请求通信量包括在所述请求进入端口接收到的来自所述计算环境的相邻层的至少一个进入请求，所述动态层扩展向所述环境代理提供请求信息，所述请求信息至少用于识别包含在所述被监控的请求通信量中的每个请求，其中所述环境代理从与所述相邻层关联的另一环境代理接收环境信息，所述接收到的环境信息与所述至少一个进入请求的请求环境相关；和其中对所述至少一个进入请求中的每一个进入请求，所述环境代理将所述环境信息分别与所述请求信息相关联。
2.根据权利要求1所述的装置，其中所述动态层扩展还至少与所述所选层的请求退出端口相连，并且其中所述被监控的请求通信量还包括在所述请求退出端口接收到的至少一个退出请求，所述所选层向所述计算环境的另一相邻层提供所述至少一个退出请求，其中所述环境代理使得所述至少一个退出请求和所述至少一个进入请求相关联；并且，向与所述另一相邻层相关联的另一环境代理发送与所述至少一个退出请求的请求环境相关的环境信息。
3.根据权利要求1所述的装置，其中所述动态层扩展还与所述所选层的层控制端口相连。
4.根据权利要求3所述的装置，其中所述环境代理还更改用于执行所述至少一个进入请求的处理程序集的优先级水平。
5.根据权利要求3所述的装置，其中所述环境代理还更改用于执行所述至少一个进入请求的处理程序集的执行类型。
6.根据权利要求1或3所述的装置，其中所述环境代理还调整在所述请求进入端口的队列中的所述至少一个进入请求的次序。
7.根据权利要求1或3所述的装置，其中所述环境代理还指示所述所选层分配用于处理所述至少一个进入请求的计算资源。
8.根据权利要求1或3所述的装置，其中所述环境代理还指示所述所选层拒绝用于处理所述至少一个进入请求的计算资源。
9.根据权利要求1所述的装置，其中所述环境信息至少包括请求标识符、事务标识服务、请求类别和环境相关数据。
10.根据权利要求9所述的装置，其中所述环境相关数据包括所述至少一个进入请求的整个所述请求环境。
11.根据权利要求9所述的装置，其中所述环境相关数据包括所述至少一个进入请求的所述请求环境的一部分。
12.根据权利要求9所述的装置，其中所述环境相关数据包括所述至少一个进入请求的所述请求环境的指示。
13.根据权利要求2所述的装置，其中所述环境代理包括代理通信接口，用于在所述动态层扩展和所述环境代理之间中继消息；代理消息发送模块，用于通知所述另一环境代理所述至少一个退出请求已经被发送到所述另一相邻层，所述代理消息发送模块还使用此消息与所述动态层扩展进行通信；和环境表管理器，用于维护一张参考表，该参考表使得运行在所述所选层上的至少一个工作单元和已分配所述工作单元的所述至少一个进入请求的所述请求环境相关联，所述参考表为环境表，所述环境表还存储与所述至少一个进入请求所相关的信息，所述环境表管理器还基于在所述环境表中存储的信息来识别至少一个进入请求。
14.根据权利要求13所述的装置，其中所述环境代理还包括分类管理器，基于所述接收到的环境信息来用于对所述至少一个进入请求进行分类，所述分类管理器还识别所述至少一个进入请求作为事务的一部分。
15.根据权利要求13所述的装置，其中所述环境代理还包括策略管理器，用于依据动态服务类别策略和所述至少一个进入请求的所述分类，来对所述至少一个进入请求分配服务类别策略。
16.根据权利要求13所述的装置，其中所述环境代理还包括代理日志事件处理器，用于执行事件日志记录、内部跟踪和消息发送，以及检测在所述环境代理内的操作异常。
17.根据权利要求13所述的装置，其中所述环境代理还包括代理管理器，用于对信息进行存档、将历史数据发送至环境网络管理服务器(CNMS)、从所述CNMS接收动态服务类别策略和附加数据。
18.根据权利要求3所述的装置，其中所述动态层扩展包括动态层扩展后台程序，用于执行与不保持所述至少一个进入请求的通知事件关联的异步处理；动态层扩展消息发送模块，用于使用消息与所述环境代理进行通信；和动态层扩展通信接口，用于在所述动态层扩展和所述环境代理之间中继消息。
19.根据权利要求18所述的装置，其中所述动态层扩展还包括动态层扩展管理器，用于使所述动态层扩展接收与应如何处理所述至少一个进入请求相关的消息。
20.根据权利要求18所述的装置，其中所述动态层扩展包括动态层扩展日志事件处理器，用于记录涉及所述动态层扩展的跟踪信息为日志，以及记录由所述动态层扩展发出的报警为日志。
21.根据权利要求1所述的装置，其中所述环境代理处于与所述所选层的同一主机上。
22.根据权利要求3所述的装置，其中所述动态层扩展从所述所选层收集性能、可用性和错误的指标。
23.一种用于监控多层计算环境中的所选层的装置，所述装置包括环境代理，其与所述所选层相关联，以及与至少一个其它环境代理相连，每个所述至少一个其它环境代理与所述计算环境的各个层相关联；和动态层扩展，所述动态层扩展与所述环境代理相连，以及与所述所选层的请求进入端口和请求退出端口中的至少一个相连，所述动态层扩展至少中的至少一个监控通过所述所选层的请求通信量，所述被监控的请求通信量包括在所述请求进入端口接收到的至少一个进入请求和在所述退出端口接收到的至少一个各自的退出请求，所述所选层向相邻层提供所述至少一个各自的退出请求，所述动态层扩展获得所述至少一个进入请求的请求环境，所述动态层扩展向所述环境代理提供请求信息和环境信息，所述请求信息至少用于识别包含在所述被监控的请求通信量中的每个请求，所述环境信息与所述至少一个进入请求的所述被获得的请求环境相关联，其中所述环境代理将所述至少一个进入请求与所述至少一个退出请求相关联，和其中所述环境代理向与所述相邻层相关联的另一环境代理提供环境信息，该环境信息与所述至少一个各自的退出请求的请求环境相关。
24.根据权利要求23所述的装置，其中所述至少一个进入请求为从用户应用接收的用户请求。
25.根据权利要求23所述的装置，其中所述环境信息至少包括请求标识符、事务标识符、请求类别和环境相关数据。
26.根据权利要求23所述的装置，其中所述环境代理依据所述环境信息将所述至少一个进入请求划分成请求类别。
27.根据权利要求26所述的装置，其中所述环境代理包含特定层服务类别策略组，每个所述特定层服务类别策略都将服务类别映射到用于所述所选层的请求类别，其中动态服务类别策略包含当前有效的请求类别到服务类别的映射；和其中所述环境代理基于所述请求类别和在所述特定层服务类别策略组中的适合的动态服务类别策略对所述至少一个进入请求分配服务类别。
28.根据权利要求26所述的装置，其中所述环境代理包含特定层服务类别策略组，每个所述特定层服务类别策略都将服务类别映射到用于所述所选层的请求类别，其中动态服务类别策略包含当前有效的请求类别到服务类别的映射；和其中所述环境代理对所述至少一个进入请求分配服务类别，所述服务类别与所述请求类别和所述特定层服务类别策略组中的适合的动态服务类别策略所指定的服务类别不同。
29.根据权利要求27或28所述的装置，其中所述服务类别包括将要分配给所述至少一个进入请求的优先级。
30.根据权利要求27或28所述的装置，其中所述服务类别包括将要分配给所述至少一个进入请求的中央处理单元的百分比。
31.根据权利要求27或28所述的装置，其中所述服务类别包括将要分配给所述至少一个进入请求的存储器。
32.根据权利要求27或28所述的装置，其中所述服务类别包括对于所述至少一个进入请求而分配和访问输入和输出设备的优先级。
33.根据权利要求27或28所述的装置，其中周期性地更新所述服务类别策略。
34.根据权利要求27或28所述的装置，其中由所述多层计算环境的用户来定义所述服务类别策略。
35.根据权利要求27或28所述的装置，其中所述环境代理向所述请求环境添加所述被分配的服务类别。
36.根据权利要求23所述的装置，其中所述动态层扩展还与所述所选层的层控制端口相连。
37.根据权利要求36所述的装置，其中所述环境代理还更改用于执行所述至少一个进入请求的处理程序集的优先级水平。
38.根据权利要求36所述的装置，其中所述环境代理还更改用于执行所述至少一个进入请求的处理程序集的执行类型。
39.根据权利要求23或36所述的装置，其中所述环境代理还调整在所述请求进入端口的队列中的所述至少一个进入请求的次序。
40.根据权利要求23或36所述的装置，其中所述环境代理还指示所述所选层分配用于处理所述至少一个进入请求的计算资源。
41.根据权利要求23或36所述的装置，其中所述环境代理还指示所述所选层拒绝用于处理所述至少一个进入请求的计算资源。
42.根据权利要求23所述的装置，其中所述动态层扩展对于包含在所述被监控的请求通信量中的每一个请求分配事务标识符。
43.根据权利要求23所述的装置，其中所述动态层扩展获得包含在所述被监控的请求通信量的每一个请求的请求标识符。
44.根据权利要求23所述的装置，其中所述环境代理包括代理通信接口，用于在所述动态层扩展和所述环境代理之间中继消息；代理消息发送模块，用于通知所述另一环境代理所述至少一个退出请求已经被发送到所述另一相邻层，所述代理消息发送模块还使用此消息与所述动态层扩展进行通信；环境表管理器，用于维护将运行在所述所选层上的至少一个工作单元和已分配所述工作单元的所述至少一个进入请求的所述请求环境相关联的参考表，所述参考表为环境表，所述环境表还存储与所述至少一个进入请求所相关的信息，所述环境表管理器还基于在所述环境表中存储的信息来识别至少一个进入请求；分类管理器，基于所述接收到的环境信息来用于对所述至少一个进入请求进行分类，所述分类管理器还识别所述至少一个进入请求作为事务的一部分；策略管理器，用于依据动态服务类别策略和所述至少一个进入请求的所述分类，来对所述至少一个进入请求分配服务类别策略。
45.根据权利要求44所述的装置，其中所述环境代理还包括代理日志事件处理器，用于执行事件日志记录、内部跟踪和消息发送，以及检测在所述环境代理内的操作异常。
46.根据权利要求44所述的装置，其中所述环境代理还包括代理管理器，用于对信息进行存档、将历史数据发送至环境网络管理服务器(CNMS)、从所述CNMS接收动态服务类别策略和附加数据。
47.根据权利要求36所述的装置，其中所述环境代理还包括动态层扩展后台程序，用于执行与不保持所述至少一个进入请求的通知事件关联的异步处理；动态层扩展消息发送模块，用于使用消息与所述环境代理进行通信；和动态层扩展通信接口，用于在所述动态层扩展和所述环境代理之间中继消息。
48.根据权利要求47所述的装置，其中所述环境代理还包括动态层扩展管理器，用于使所述动态层扩展接收与应如何处理所述至少一个进入请求相关的消息。
49.根据权利要求47所述的装置，其中所述环境代理还包括动态层扩展日志事件处理器，用于记录涉及所述动态层扩展的跟踪信息为日志，以及记录由所述动态层扩展发出的报警为日志。
50.根据权利要求23所述的装置，其中所述环境代理处于与所述所选层的同一主机上。
51.根据权利要求36所述的装置，其中所述动态层扩展从所述所选层收集性能、可用性和错误的指标。
52.一种在包括多个层的多层计算环境中用于应用性能管理的系统，所述应用与所述多个层的至少所选的被监控层相关联，该系统包括对于至少两个所述被监控层的每个层的各自的动态层扩展，其至少与所述被监控层的请求进入端口相连，所述动态层扩展至少监控通过所述各自被监控层的请求通信量，所述被监控的请求流量包括在所述请求进入端口收到的至少一个进入请求；和对于所述至少两个所述被监控层的每个层的各自的环境代理，其与所述各自动态层扩展相连，所述环境代理与直接连接至所述各自层的层关联的其它所述环境代理相连，所述各自环境代理从所述各自动态层扩展接收请求信息，所述请求信息至少识别包含在所述被监控的请求通信量中的每个请求，所述各自环境代理还从与所述相邻层关联的另一环境代理接收环境信息，所述环境信息与所述至少一个进入请求的请求环境相关，对于所述至少一个进入请求中的每个进入请求，所述各自环境代理将所述环境信息分别与所述请求信息相关联。
53.一种在包括多个层的多层计算环境中用于应用性能管理的系统，所述应用与所述多个层的至少所选的被监控层相关联，该系统包括对于至少两个所述被监控层的每个层的各自的动态层扩展，其与所述被监控层的请求进入端口和请求退出端口中的至少一个相连，所述动态层扩展至少监控通过所述各自被监控层的请求通信量，所述被监控的请求通信量包括在所述请求进入端口接收到的至少一个进入请求和在所述退出端口接收到的至少一个各自的退出请求，所述所选层向相邻各自被监控层提供所述至少一个各自的退出请求，所述动态层扩展获得所述至少一个进入请求的请求环境；和对于所述至少两个所述被监控层的每个层的各自的环境代理，其与所述各自动态层扩展相连，所述环境代理与直接连接至所述各自层的层关联的其它所述环境代理相连，所述各自环境代理从所述各自动态层扩展接收请求信息，所述请求信息至少识别包含在所述被监控的请求通信量中的每个请求，所述各自环境代理还从所述各自动态层扩展接收环境信息，所述环境信息与所述至少一个进入请求的请求环境相关联，对于所述至少一个进入请求中的每个进入请求，所述各自环境代理将所述至少一个进入请求与所述至少一个退出请求相关联，并且所述各自环境代理向与所述相邻层关联的另一环境代理提供环境信息，所述环境信息与所述至少一个各自退出请求的请求环境相关。
54.根据权利要求52或53所述的系统，还包括与所述环境代理相连的环境网络管理服务器(CMNS)，所述CNMS至少收集和分析从所述环境代理接收的性能数据。
55.根据权利要求52或53所述的系统，其中所述至少一个进入请求是从用户应用接收的用户请求。
56.根据权利要求52所述的系统，其中每一个所述动态层扩展还至少与所述各自层的请求退出端口相连，并且其中所述被监控的请求通信量还包括在所述请求退出端口接收到的至少一个退出请求，所述所选层向所述计算环境的另一相邻层提供所述至少一个退出请求，其中所述各自环境代理使得所述至少一个退出请求和所述至少一个进入请求相关联；并且，向与所述另一相邻层相关联的另一环境代理发送与所述至少一个退出请求的请求环境相关的环境信息。
57.根据权利要求54所述的系统，还包括与所述CNMS相连的策略数据库，所述策略数据库存储至少服务类别策略。
58.根据权利要求57所述的系统，还包括与所述CNMS以及与所述策略数据库相连的管理工作站。
59.根据权利要求54所述的系统，其中所述CNMS还执行行为映像、创建包括综合事务、层和系统级性能指标与统计分析的行为映像。
60.一种在包括多个层的多层计算环境中用于监控所述多个层的所选被监控层的应用性能管理方法，该方法包括以下步骤接收与至少一个进入请求的请求环境相关的请求环境信息，所述环境信息至少包括请求标识符和事务标识符；监控通过所述被监控层的请求通信量，所述被监控的请求通信量至少包括所述至少一个进入请求；依据所述请求标识符，识别所述至少一个进入请求；和依据所述事务标识符，将所述至少一个进入请求和事务相关联。
61.一种在包括多个层的多层计算环境中用于监控所述多个层的所选被监控层的应用性能管理方法，该方法包括以下步骤监控通过所述被监控层的请求通信量，所述被监控请求通信量包括至少一个进入请求和至少一个各自退出请求，所述所选层向相邻层提供所述至少一个各自退出请求；确定与所述至少一个进入请求的请求环境相关的环境信息；识别在所述被监控请求通信量中包括的每一个请求；将所述至少一个进入请求与所述至少一个退出请求相关联；和向与所述相邻层关联的另一环境代理发送环境信息，所述环境信息与所述至少一个退出请求的请求环境相关。
62.根据权利要求1-51中任一所述的装置，基本如上文所述或者如任一附图中所示。
63.根据权利要求52-59中任一所述的系统，基本如上文所述或者如任一附图中所示。
64.根据权利要求60-61中任一所述的应用，基本如上文所述或者如任一附图中所示。
全文摘要
提供一种用于监控多层计算环境中的所选层的装置，所述装置包括环境代理和动态层扩展，该环境代理与所选层关联以及与其它环境代理相连，其中的每个环境代理与各自层关联，该动态层扩展与环境代理相连以及与所选层的特定预定点相连，动态层扩展监控通过所选层的请求通信量，被监控的请求流量包括在所述请求进入端口接收到的来自所述计算环境的相邻层的至少一个进入请求，动态层扩展识别在被监控的请求通信量中的每一个请求以及向环境代理至少发送请求标识符，环境代理还从与相邻层关联的环境代理接收信息，该信息与进入请求的请求环境相关，环境代理依据接收到的请求标识符将与进入请求的请求环境相关的信息与进入请求关联。
文档编号H04L29/08GK101044462SQ200580025893
公开日2007年9月26日 申请日期2005年3月31日 优先权日2004年6月4日
发明者阿米尔·阿隆, 约拉姆·约里·拉维, 莫迪凯·达 申请人:奥普蒂尔有限公司