时间：2006-08-07 作者：John Straathof 浏览次数： 本文关键字：zyntax, tuxedo adaptor, rational robot, BEA Tuxedo, John Straathof

文章工具  推荐给朋友  打印文章

摘要

　　本文将描述Zyntax Tuxedo Adapter (ZTA)，它是一种Robot API适配器，能够大大提高用于BEA Tuxedo应用程序的性能测试脚本的可用性，方法是将原始Tuxedo缓冲区数据转换为符合人类阅读习惯的格式。它支持所有的主流通信范例，包括同步、异步和会话式范例。

概述

　　在本文中，我将从描述ZTA架构开始，它是少数几个使用IBM Rational Session Recording Extensibility框架的现有第三方产品之一。然后，我将展示一个小型测试应用程序的示例记录，以使您了解ZTA的特别之处。最后，我将考察一些使用实际应用程序时出现的特定问题。

对Tuxedo应用程序进行性能测试

　　当需要对Tuxedo应用程序进行性能测试时，有许多选择。一种通用策略是修改客户端应用程序，但是使用这种技术有许多缺点。首先，修改客户端应用程序要求开发人员进行输入操作，但是理想的测试应该不受开发人员影响地完成，以防止测试人员做出与开发人员相同的假设，而不是实际测试这些假设。然而，要在不受开发人员影响的情况下修改客户端代码，就要求测试人员具有较高的知识水平。其次，如果客户端应用程序被修改，人们就会质疑测试结果是否真正适用于此客户端应用程序，还是仅适用于它修改后的版本（而该版本永远不会投入生产）。再次，对于定制测试解决方案来说，生成、控制和执行多用户测试并正确解释产生的测试数据可能会花费大量时间。最后，应用程序源代码并非总是可用的；当使用从高级或基于GUI的代码自动生成代码的第三方产品，或者用户是不被允许访问代码的外部测试顾问的时候，这种情况就可能发生。

　　标准测试工具（例如IBM Rational Robot）消除了这些缺点，因此成为许多测试专业人员的首选。

Zyntax Tuxedo Adaptor简介

当在套接字级记录Tuxedo应用程序上的测试脚本时，Rational Robot截取写入网络的对Windows系统库的调用。因此，得到的脚本包含原始数据。所有数据碎片、并行通信线程、服务查找逻辑和数据加密都在该脚本中有详细的反映（图1）。这不仅使脚本的解释变得非常困难，而且由于存在特定于会话的信息（例如会话cookies和服务主机解析），实际上使生成的脚本不可进行多用户测试。如果此特定于会话的数据未被参数化，则多用户测试或者无法进行，或者过度偏离实际使用，而使测试结果没有意义。

图1. 来自未使用ZTA的Tuxedo应用程序记录的VU片段

　　因此要求在（细节更少的）更高级别执行记录，最好是可以识别原始应用程序意图的对应物的级别。图2说明了用于一个使用Tuxedo库的客户/服务器应用程序的三个记录级别。

图2. 记录级别

　　对于ZTA来说，记录发生在Tuxedo API级别。所以Robot截取从应用程序到Tuxedo库的调用，并将它们记录到脚本，而不是截取对Windows套接字库的调用或在网络级别进行侦听。这种方式将大部分Tuxedo的低级功能从脚本隐藏，仅留下数据和高级应用程序结构。

ZTA架构

　　Robot为第三方开发人员提供了一个API，它允许截取对任何Windows动态链接库(DLL)的库调用。（如果已经安装了Robot，则此API的文档是可用的。在开始菜单中找到Rational Robot程序组，并定位到Rational Test/API/Session Extensibility。笔者尚未找到此文档的在线版本。）使用此API要求第三方提供三个DLL供Robot使用：

• Recorder
• Filter
• Script Generator

　　Recorder DLL由Robot在记录会话时调用。在开始实际记录之前，Robot查询Recorder DLL，以获得要截取的目标应用程序库和函数清单。在记录过程中，所有应用程序对指定应用程序库的调用都被截取并被重发送到Recorder DLL。此recorder DLL知道如何解释与调用关联的数据，并将数据写入会话/监视文件（图3）。它也调用目标库中的原始函数，所以客户端应用程序事实上仍在工作（未在图中显示）。

图3. Recorder架构

　　Robot (RTL)截取应用程序客户端对应用程序库的调用。然后Robot将数据写入会话监视文件，并对Adaptor进行调用，而Adaptor将其数据写入会话监视文件。完成记录后，会话监视文件(.WCH)中的所有条目通过Filter DLL送入。Filter DLL选择API适配器感兴趣的条目（Robot自己也将条目写入会话文件）。

　　完成对会话文件条目的选择之后，选中的条目被送到Script Generator。此Generator可以编写任何格式，但是在ZTA的例子中，此Generator使用Robot VU语法编写语句，就像正常的HTTP或套接字记录一样（图4）。因此，一位经验丰富的Robot用户应该能够理解并可以以直观方式更改脚本。

图4. Filter和generator架构

　　Robot从会话监视文件中读取数据，并将其转换成脚本。它也将条目反馈到Filter DLL，Filter DLL仅选择Generator需要的数据元素。通过使用过滤后的元素，Generator将其代码行写入VU脚本。

　　生成脚本之后，无需修改即可编译，然后可重放它。要支持API适配器所添加的任何额外功能，可将Replay库与脚本关联。在ZTA的例子中存在一个头文件，它提供对由ZTA提供的符号和定制函数调用的定义。

脚本示例

　　现在我将展示一个简单的示例（清单1），以说明ZTA是如何工作的。此脚本是通过ZTA在一个非常简单的客户-服务器应用程序（具有单一Tuxedo服务调用）上记录的，并稍做了修改以便于阅读。用于参考的对应套接字脚本长200行，其中60％是类似于图1所示的原始数据。

　　此示例可被分为五个块（由空行分隔）：1) 定义头文件、2) 初始化、3) 登录、4) 服务调用和5) 注销。

　　在定义头文件中，可以看到标准的 #include <VU.h> 出现在每个VU脚本中，以及为ZTA读取头文件的 #include。初始化行 init_tuxedo() 执行初始化重放库、进行许可检查、配置Tuxedo等操作。用于此函数调用的代码驻留在ZTA重放库中。

　　登录块包括三行；第一行分配内存块以保存登录信息，第二行使用凭证对其进行填充并将其传给Tuxedo，第三行释放内存块。每行严格对应于Tuxedo ATMI（请参阅BEA文档）。

　　客户登录后，服务调用块随后启用。一个Tuxedo VIEW文件（名为view1）定义了服务调用输入数据格式。（VIEW文件是数据格式描述文件，它定义了请求和应答中字段的类型和大小。）此特定VIEW将一个二进制数据块定义为28字节，保存一个2字节的整型字段（称为svalue）、一个4字节的整型（称为lvalue）和一个20字节的ASCII字符串（称为data）。余下的2字节通过对齐填充方式进行填充。

　　在服务调用块中，分配了两个缓冲区：一个用于输入数据(_idata)，一个用于服务器返回的输出数据 (_odata)。data() 行填充输入数据缓冲区中的字段。tpcall() 行进行对Tuxedo子系统的实际调用。输出缓冲区 _odata 随后被填充并可为脚本开发人员使用。此块以释放分配的数据缓冲区结束。

#include 
#include 
{
init_tuxedo();

tpalloc(_idata, "TPINIT", "NULL", 140); 
tpinit(_idata, "user", "host", "password", "", 0, 0, TPNOFLAGS); 
tpfree(_idata);  tpalloc(_idata, "VIEW32", "view1", 28); 
tpalloc(_odata, "VIEW32", "view1", 28); 
data(_idata, _short, "svalue", "5");
data(_idata, _long, "lvalue", "10");
data(_idata, _string, "data", pad1("these",20));
tpcall("TIMER1", "VIEW1", _idata, 28, _odata, TPNOFLAGS); 

tpfree(_idata);
tpfree(_odata); 
 
tpterm(); 
}

　　清单1. 简单脚本示例

　　测试专业人员应该感兴趣的是，客户端发送的二进制数据块被按字段进行分解，值被转换为简单的字符串表示。这些表示可使用来自数据池的值以直观方式取代。服务器返回的数据未在此脚本中显示，但是很容易通过标准ZTA函数访问（如下所示）。

　　此脚本以 tpterm() 行结束，该行关闭到Tuxedo服务的连接。

参数化

　　一旦脚本被成功记录，通常会希望对此脚本进行参数化，以便重放使用多个虚拟用户的脚本能够对服务器产生逼真的负载。

　　参数化有两个主要目的：有效性（脚本可无错误地重放）和区分（不同的虚拟用户使用不同的数据）。正如您在示例脚本中所看到的，后一种参数化类型可以以直观方式完成，只需使用标准Robot数据池命令代替文字字符串。

　　如果服务器在会话期间返回特定于会话的数据，只取代脚本会导致服务器返回某种“bad session identifier”错误。人们通常通过以下方式标识这些种类的会话标识符：寻找服务器返回数据与随后的客户端请求之间的相同数据字符串，或两次使用完全相同的参数记录特定于客户端的行为，然后比较两个生成脚本。

　　ZTA简化了这两种策略，以可选方式提供服务器返回数据的翻译（通过使用data()中与用作输入数据构建块的行相同的行）。这些返回数据翻译也可用于标识记录过程中出现的错误。

　　一旦标识了特定于会话的数据，ZTA的 get_data() 函数就可用于从输出缓冲区检索任何字段。清单2展示了如何从 _odata缓冲区检索svalue字段。返回的字符串可直接用于替换脚本中随后出现的任何文字字符串。

string id;
tpcall("TIMER1", "VIEW1", _idata, 28, _odata, TPNOFLAGS);
id = get_data( _odata, "svalue", 0 ); 

　　清单2. 参数化示例

Tuxedo环境

　　大多数Tuxedo应用程序严重依赖于环境变量，这些环境变量描述应用程序配置，例如连接字符串、VIEW定义文件的位置和Tuxedo软件本身的位置。Tuxedo和ZTA都使用这些环境变量；Tuxedo需要VIEW定义文件以构建请求，而ZTA使用相同的文件解释这些请求及其响应。

　　ZTA在Tuxedo会话生命周期中的多个阶段记录配置环境，并以可选方式将行写入脚本，以便重放环境可以与原始客户端应用程序环境相同。

其他通信范例的处理

　　以上示例使用了Tuxedo支持的最简单通信范例：同步客户-服务器范例。在此范例中，客户端以串行方式工作，向服务器发出请求，等待响应，然后发出进一步请求。

　　然而对于某些应用程序来说，客户端需要来自不同服务器的多个数据，而并不关心收到这些结果的顺序。在这种情况下，首选异步范例。在此范例中，客户端将请求发到服务器而不等待回答，直到所有请求均已发出。为了了解哪个响应对应哪个请求，Tuxedo客户端为每个请求指定独有的标识符；这些标识符随后随服务器响应返回。ZTA以直观方式支持此范例，如以下的简单脚本所示。Tuxedo开发人员可以使用底层ATMI函数调用来识别非常严密的对应。请参阅ATMI参考资料（见上），以获得关于 tpacall 和 tpgetrply 函数的解释。存储独有标识符和缓冲区长度的必要变量被自动插入到脚本。

int length1;
int rply1;

tpalloc(_idata, "FML32", "NULL", 0);
tpalloc(_odata, "FML32", "NULL", 0);
tpalloc(_buf3, "FML32", "NULL", 0);
tpalloc(_buf4, "FML32", "NULL", 0);
data(_idata, _string, "FIRST_NAME",    pad1("Betsy",6));
call1 = tpacall("FML32", _idata, 40, TPNOFLAGS);
data(_buf3,  _string, "FIRST_NAME",    pad1("Camilla",21));
call2 = tpacall("FML32", _buf3, 56, TPNOFLAGS);
data(_buf4,  _string, "FIRST_NAME",    pad1("Daniel",7));
call3 = tpacall("FML32", _buf4, 40, TPNOFLAGS);
tpgetrply(&call3, _odata, &length1, TPNOCHANGE); 
tpgetrply(&rply1, _odata, &length1, TPGETANY|TPNOCHANGE); 
tpgetrply(&rply1, _odata, &length1, TPGETANY|TPNOCHANGE);
tpfree(_idata); tpfree(_odata);
tpfree(_buf3); tpfree(_buf4);

　　清单3 异步脚本示例

　　在以上讨论的异步和同步范例中，每个操作均由客户端请求开始，以服务器响应结束。Tuxedo还支持一种客户端和服务器均可以开始操作的通信范例：会话式范例。诸如telnet和SSH之类的流行服务就使用此范例。ZTA以与支持tpcall 和 tpacall/tpgetrply 函数的方式相同的方式支持Tuxedo会话函数tpconnect、tpsend、tprecv和tpdiscon。

　　应该认识到，如果对话式会话中的参与者之间的通信真正是双向的，那么重放记录脚本就没有什么意义，因为生成的脚本的串行性质会强制此会话的对话方向与记录时的方向完全相同。然而，如果对话是“半双工”（各方轮流讲话，每隔一定时间将通道控制权交给另一方），重放脚本运行正常。

　　目前ZTA不支持Tuxedo事务（如果一个或多个请求失败，则请求块会全部回滚）。

结束语

　　本文描述了Zyntax Tuxedo Adaptor，它是一种IBM Rational Robot扩展，允许测试BEA Tuxedo版本7和更高版本。还解释了如何编写适配器以与IBM Rational Robot一起工作，展示了ZTA是如何通过Session Extensibility框架与Robot集成的，提供并解释了一个简单的示例脚本，以使您了解ZTA是如何工作的。还描述了如何实现参数化。最后，讨论了不同的通信范例以及ZTA如何支持它们。

参考资料

• Zyntax Tuxedo Adapter
• 请阅读ZTA用户指南(PDF)和函数参考(PDF)，以获得进一步信息
• 请访问Dev2Dev上的Tuxedo产品中心（Tuxedo中文产品中心）

原文出处:http://dev2dev.bea.com/pub/a/2006/06/performance-tuxedo.html

您对本文的评价
您对这篇文章的看法如何?
太棒了！5分 不错啊 4分 一般般 3分 有待提高 2分 不好 1分