背景技术
[0002] 用于服务器侧应用的当前流行的架构模型是基于
反应性原理，其中，服务器响应于从请求方接收到外部请求而执行某些工作并随后向请求方传送响应（即，结果）。服务器性能的主要指示符是服务器请求等待时间，其是从服务器接收到请求的时间直至服务器提供响应的时间所经过的时间。
[0003] 出于理解和准确地确定延迟的根源的目的，性能分析员通常对诸如哪些特定服务器请求执行起来花费相对长的时间和用于这些服务器请求的内部处理细节的因素感兴趣。
[0004] 常规服务器请求可以产生多个辅助请求，因为出于满足该请求的目的，最初联系的服务器可以向其他服务器传送附加请求。此类跨服务器通信通常使诊断分析复杂，因为涉及许多部件，并且可能突然插入对在对初始服务器请求进行响应时的总等待时间有所贡献的相应问题。
附图说明
[0005] 图1是根据示例性实施方式的物理机的系统的方
框图。
[0006] 图2是根据示例性实施方式的与服务器请求相关联的示例性拓扑。
[0007] 图3是描述了根据示例性实施方式的用以跟踪产生辅助请求的服务器请求的技术的
流程图。
[0008] 图4是描述了图示出根据示例性实施方式的用以处于处理相关令牌的目的补充接收到的应用程序间消息的处理的代码
片段（code snippet）的使用的技术的流程图。
[0009] 图5是描述了图示出根据示例性实施方式的用以出于处理相关令牌的目的补充要传送的应用程序间消息的处理的代码片段的使用的技术的流程图。
[0010] 图6是描述根据示例性实施方式的被代码片段与监视工具API相结合地使用以处理输入应用程序间消息的技术的流程图。
[0011] 图7是描述了根据示例性实施方式的被代码片段与监视工具API相结合地使用以处理输出应用程序间消息的技术的流程图。
具体实施方式
[0012] 在本文中出于跟踪由客户端做出且被提供给服务器侧编程
框架（在本文中称为“服务器侧”）的服务器请求的目的公开了系统和技术。在服务器侧，来自客户端的服务器请求可以导致大量的请求，其包括从客户端接收到的初始请求和在初始请求的处理中在服务器侧产生的结果得到的辅助请求。更具体地，通常，来自客户端的给定服务器请求的处理涉及不同部件或服务器侧的应用程序之间的消息（在本文中称为“应用程序间消息”）的传送。在这方面，服务器侧可以由多个层或应用程序构成，其又可以存在于一个或多个服务器上。
当服务器侧上的应用程序从客户端接收到请求时，处理请求的过程中的应用程序可以向其他应用程序发布辅助请求（以应用程序间消息的形式）；并且此过程可以继续且是递归的。
[0013] 如在本文中公开的，出于跟踪在服务器侧上的不同应用程序进行的服务器请求处理的目的，向出于满足请求的目的传送的每个应用程序间消息附加着色或相关令牌。如下文进一步描述的，例如诊断工具的监视工出于分析与服务器请求的处理相关联的执行的目的处理相关令牌，即使服务器请求的最后处理涉及服务器侧上的多个应用程序。换言之，诊断工具出于分析与跨服务器侧上的所有部件的处理相关联的等待时间、执行时间等的目的使用相关令牌。
[0014] 在本文中公开的技术和系统允许监视应用程序间消息通信，无论是使用标准化通信协议还是使用不遵守任何特定标准的传统协议（例如，专有协议）来传送应用程序间消息。因此，某些服务器侧部件可能是传统应用程序，其使用限制或未知的通信协议。以这种方式，在服务器请求的处理中使用的某些应用程序可能是多年以前或过去的几十年开发的。监视工具仍可以与此类应用程序一起使用，因为相关令牌和代码片段（下文描述）的使用允许应用程序间消息传送的监视，无论应用程序所采用的通信协议的类型如何。
[0015] 作为更特定的示例，根据本发明的某些
实施例，可以在系统上实现服务器侧，诸如在图1中描述的示例性系统。通常，图1的系统包括被网络130互连的多个物理机100（在图1中描述的示例性机器100a、100b和100c）。物理机的示例包括计算机（例如，
应用服务器、存储服务器、网络服务器等）、通信模
块（例如，交换机、路由器等）及其他类型的机器。网络130还可以包括
系统总线或其他快速互连。“物理机”指示该机器是由可执行程序指令和
硬件构成的实际机器。
[0016] 网络130的示例包括局域网（LAN）、广域网（WAN）、因特网、任何其他类型的通信链路或其组合。物理机100可以位于一个机柜（或
机架）内；或者替换地，物理机100可以位于多个机柜（或机架）中或者甚至在地理上分散。
[0017] 在图1中描述的系统可以是应用服务器、存储服务器场（或
存储器域网）、网络服务器场、交换机或路由器场、其他类型的
数据中心等中的任何一个。并且，虽然在图1中描述了三个物理机100，但注意的是根据其他实施方式，可以使用多于三个物理机100、两个物理机或一个物理机100。
[0018] 虽然在图1中将每个物理机100描述为包含在箱子内，但注意的是物理机100可以是具有多个
节点的分布式机器，其提供分布式和并行处理系统。
[0019] 如在图1中描述的，在某些实施方式中，物理机100可以存储机器可执行指令106。这些指令106可以包括一个或多个应用程序116、
操作系统188和一个或多个设备
驱动器120（其可以是操作系统118的一部分）。
[0020] 物理机100还可以包括硬件122，其包括处理器，诸如一个或多个中央处理单元（CPU）124（出于非限制性示例的目的，在图1中描述了一个CPU 124）。每个CPU 124可以具有一个或多个处理核。硬件122还可以包括系统存储器126和网络
接口128。在某些实施方式中，一个或多个CPU 124执行机器可执行指令106。可以将机器可执行指令106存储在各种形式的机器可读介质中的任何一个中，诸如存储器126、可移动介质、磁存储器、光存储器、另一机器上的存储器等。
[0021] 根据某些实施方式，一个或多个物理机100上的应用程序116形成特定复合型服务器侧应用程序框架的部件的全部或一部分。如在图1中所描述的，除上述部件之外，可执行指令106还包括监视工具117，其用于跟踪服务器侧上的服务器请求的部件间处理的目的，诸如跟踪来自客户端的初始请求的处理、处理结果得到的辅助请求、聚集并处理中间结果且最后将最终结果提供给客户端。
[0022] 物理机100a仅仅是用于服务器的特定物理机100的示例。注意的是服务器侧可以由多个物理机形成，诸如与其他物理机100组合的机器100a，例如，诸如物理机100b和/或物理机100c。因此，给定服务器侧可以包括具有物理机100a的一个或多个应用程序116；具有另一物理机100b的一个或多个应用程序116；在多个物理机100上的一个或多个应用程序116等。
[0023] 无论特定实施方式如何，针对在本文中公开的示例，给定服务器请求随初始请求一起产生，其由客户端提供（经由在图1中未描述的物理机）且被应用程序116中的一个接收以发起处理，该处理最终导致满足客户端请求的响应。来自客户端的初始请求的处理可以产生附加辅助请求，其传播（经由应用程序间消息）至可以位于同一物理机100上和/或不同物理机100上的其他应用程序116。
[0024] 根据本文公开的实施方式，出于即使当在这些通信中使用标准化和/或非标准化通信协议的目的也监视与请求处理相关联的应用程序间消息发送的目的，由代码片段119来动态地
修改服务器侧上的每个应用程序116。通常，代码片段119是出于促使应用程序116在仪表化点处执行预定功能的目的在应用程序116的代码中的特定执行或仪表化点处插入的程序代码。作为更特定示例，根据某些实施方式，代码片段119是由编写未编译程序代码以执行特定功能的程序分析员导出的；并且，运行时间编译程序对此未编译代码进行编译，并在应用程序116正在执行的同时将其插入用于应用程序116的另一已编译代码中，如在题为“Compiling And Inserting Code Snippets At Runtime”美国
专利申请公开序号20090172653中所述的，其在2008年9月27日提交，在2009年6月2日公布。用于给定应用程序的代码片段119的使用有效地允许应用程序116的自动修改以允许向和从应用程序116传送的消息中的相关令牌的传送，无论应用程序116所采用的消息发送通信协议如何。
[0025] 根据某些实施方式，代码片段119使应用程序116暴露于监视工具117的应用编程界面（API），并且监视工具117的这些API被配置成处理和更新附加在应用程序间消息上的相关令牌。更具体地，可以出于在与发送应用程序间消息相关联的应用程序116的仪表化点处插入代码的目的编写特定代码片段119。针对本示例，代码片段119使应用程序116暴露于监视工具117的API，其被配置成将已更新相关令牌附着到输出应用程序间消息中。作为另一示例，可以出于在应用程序116的仪表化点处插入代码的目的编写特定代码片段
119，在该处应用程序116接收与（初始和辅助）请求有关的消息。因此，当接收到应用程序间消息时，可以使用代码片段119来使应用程序116暴露于监视工具117的相应API以便处理消息以例如提取并解析相关令牌。如下面进一步描述的，此更新相关令牌可以包括用于消息的已更新拓扑以指示直到消息的时间为止的用于服务器请求的处理历史。
[0026] 在某些实施方式中，可以使用相关令牌的附着来利用（leverage）在应用程序部件之间传递的消息的结构，并且可以在不影响消息结构的完整性的情况下将相关令牌插入消息中。例如，如果使用超文本传输协议（HTTP）作为通信协议，则可以将附加HTTP报头字段用于传递相关令牌的目的。在另一示例中，如果将Java消息服务（JMS）用于应用程序部件之间的通信，则可以使用JMS消息性质来将相关令牌插入消息中。
[0027] 在其他实施方式中，当在应用程序部件之间传递的消息的结构不灵活或者甚至未知时，代码片段119可以使用“打包”技术，亦即，产生复合消息，其包含相关令牌和未修改原始消息。在接收侧，另一代码片段（对于本示例而言，“接收侧代码片段119”）将接收到的消息“解开”并将提取的相关令牌传递至监视工具；并且对于本示例而言，接收侧代码片段119还提取原始应用程序消息并将其传递至接收应用程序部件。在所有情况下，在不需要改变应用程序或工具源代码或重新编译的情况下将相关令牌附着并从消息分离。
[0028] 因此，从应用程序间消息进行的附加相关令牌的提取以及相关令牌到应用程序间消息的附加与用来传送应用程序间消息的通信协议无关。结果，可以在工具117的开发者或提供者不具有关于预期客户所使用的应用程序所采用的通信协议/技术的任何知识的情况下开发监视工具117。协议/技术的知识被编程分析员用于开发代码片段119的目的。由于可以在发布了应用程序116或监视工具117之后的任何时间创建代码片段119，所以可以提供“一般”监视支持。因此，即使给定应用程序116使用某种模糊传统通信技术，支持此监视仅仅涉及编写用于应用程序116的代码片段119，其可以涉及例如相对少的编程代码行。根据本文所述的实施方式，这全部在不改变应用程序源代码、修改监视工具源代码或进行重新编译的情况下发生。
[0029] 作为非限制性示例，图2描述了根据某些实施方式的与示例性服务器请求相关联的示例性拓扑150。参考图2，对于本示例而言，拓扑150与贷款申请的处理相关联，并且服务器侧处理代表贷方或
银行的贷款申请。以这种方式，客户端151（例如，贷款
申请人所使用的
计算机系统）通过向因特网服务器（作为非限制性示例）传送初始请求180（例如，包含用于由银行处理的已完成贷款申请）来发起服务器请求，所述因特网服务器出于最初处理请求180的目的发起应用程序116（参见图1）的实例160a。如下文所述，应用程序实例160a可以直接地和间接地生成附加辅助请求186以发起与处理贷款申请相关联的各种处理功能，并且这些辅助请求186中的每一个又可以产生附加辅助请求。在成功结束时，应用程序实例160a向客户端151提供响应190，其可以是用于更多信息的请求、贷款的拒绝、试行贷款批准、与贷款申请的处理相关联的初步或中间结果等。
[0030] 应用程序实例160出于处理相关令牌的目的被暴露于监视工具117（参见图1）的关联实例170的API，所述相关令牌被附加在被实例160c接收到和从其传送的应用程序间消息上。在这方面，代码片段119出于提取用于输入应用程序间消息的相关令牌并生成用于输出应用程序间消息的适当相关令牌的目的使应用程序实例160a暴露于监视工具实例170的API。其他应用程序实例160b、160c、160d和160e被相应代码片段119配置成以类似方式暴露于关联监视工具实例170的API。
[0031] 作为非限制性示例，应用程序实例160a可以接收原始贷款申请并生成辅助请求186以促使应用程序实例160b确定申请人是否被承认为银行的客户。在这方面，应用程序实例160b可以例如出于确定申请人是否是银行客户的目的基于申请人的社会安全号、出生日期和/或驾驶执照号来搜索
数据库。申请人实例160b向应用程序实例160a返回结果（经由响应190），应用程序实例160a然后可以出于从其他应用程序实例请求附加服务的目的使用识别确定的结果。
[0032] 例如，应用程序实例160a可以出于请求应用程序实例160c对申请人执行犯罪背景搜索的目的向应用程序实例160c提交辅助请求186。作为另一示例，应用程序实例160a可以出于请求应用程序实例160d确定是否银行具有给申请人的任何现有抵押的目的向应用程序实例160d提交辅助请求186。应用程序实例160c和160d经由各响应190向应用程序实例160a返回结果。
[0033] 由应用程序实例160a向应用程序实例160c和160d提交的辅助请求186是异步辅助请求的实例，因为应用程序实例160a可以继续进行其处理，这不依赖首先接收到哪些响应190。其他辅助请求186是同步的，因为可以在进行另一请求（例如，用以检查关于已识别抵押的留置权的请求）之前要求对一个请求（例如，用以确定申请人是否具有给银行的任何抵押的请求）的响应。
[0034] 作为辅助请求的又另一示例，图2描述了应用程序实例160d可以向应用程序实例160e提交辅助请求186。作为非限制性示例，应用程序实例160d可以出于识别关于与银行保持的抵押相对应的财产的任何留置权的目的而使用应用程序实例160e。
[0035] 根据某些实施方式，作为非限制性示例，相关令牌是随输出呼叫的每次执行而变的串。通常，相关令牌跨企业是唯一的，这意味着不同机器上的不同输出呼叫不能生成同一相关令牌。此设置可以用于追踪的目的，即连接服务器请求的实例。作为另一非限制性示例，出于诊断目的，相关令牌还可以包括信息，这允许出于构造请求拓扑的目的以聚合方式将实体链接在一起。
[0036] 参考图3，概括地说，一般地可以出于跟踪服务器请求的目的根据本发明的实施例来执行技术200。按照技术200，代码片段被插入应用程序中（按照方框204），以使应用程序暴露于监视工具的API，并且因此促使应用程序关于应用程序间消息与监视工具通信。技术200包括使用监视工具（按照方框208）来出于跟踪服务器请求的目的对与消息相关联的相关令牌进行操作，所述消息与由客户端提供的服务器请求的处理相关联。
[0037] 根据某些实施方式，代码片段119可以出于处理被应用程序116接收到的应用程序间消息的目的执行在图4中描述的技术210。可以在应用程序116的仪表化点处插入此代码片段119，其对应于在其上应用程序116处理接收到的
进程间消息的执行点。按照技术210，代码片段119接收（方框212）复合应用程序间消息，其包含消息主体和附属（pendant）相关令牌。代码片段119通过使应用程序116暴露于监视工具的API来将复合消息解析（方框214）成主体和相关令牌，并且然后将该消息主体传送（方框218）至应用程序116。代码片段119还按照方框222将相关令牌传送至监视工具117。
[0038] 根据某些实施方式，代码片段119出于提供从应用程序116传送的复合消息的目的来执行在图5中描述的技术230。可以在执行点处插入此代码片段119，应用程序在该执行点处传送输出应用程序间消息。按照技术230，代码片段119使应用程序116暴露于监视工具117的适当API以促使适当API从应用程序116接收消息主体（按照方框234）并从监视工具117接收（方框236）关联的相关令牌。按照方框238，代码片段119然后执行适当的API以向应用程序提供复合消息以用于传输。
[0039] 参考图6，根据某些实施方式，代码片段119与监视工具117的API相结合出于处理输入相关令牌的目的执行技术250。按照技术250，监视工具117从应用程序116接收（方框254）相关令牌，并且按照方框258，从相关令牌提取（方框258）起源服务器请求的身份。按照方框262，监视工具117然后可以另外处理相关令牌。根据其目的，监视工具117可以分析某些等待时间，识别服务器应用程序框架中的问题点等。
[0040] 参考图7，根据某些实施方式，代码片段119与监视工具117的API相结合出于处理输出复合应用程序间消息的目的执行技术300。按照技术300，按照方框304，监视工具生成相关令牌。以这种方式，根据某些实施方式，监视工具117更新用于输出进程间消息的请求拓扑并向应用程序116提供（方框308）此相关令牌。
[0041] 虽然已相对于有限数目的实施例描述了本发明，但受益于本公开的本领域技术人员将认识到其许多修改和变更。意图在于所附
权利要求覆盖落在本发明的精神和范围内的所有此类修改和变更。
