建立样品客户端应用
要建立样品客户端应用,请将下列文件系统添加到ide中:<download directory>/metrics/transactionclient.
该文件系统包含一个应用类和一个xact 软件包。应用类可模仿客户端事务的执行,xact 软件包包含客户端web服务处理器。
xact软件包可使用sun web服务开发者工具包来创建,这个工具包包括在sun one应用框架内。批文件gen.bat使用wscompile命令创建xact软件包。如果你想重建该软件包的话, 你只需调整环境变量和它使用的config.xml 中的url。但是,如果你这样做的话,你得重写添加到stub 类web方法的代码行,你要用它来覆盖原来的代码行。
我们看看xactclientapp,样品客户端应用程序类:
先看它的内部循环。客户端应用判断商业事务的组成。在本例中,它包括三个web服务调用:针对submitwork()、checkwork()和getresult()的分别调用。客户端使用begintransaction()和 committransaction()定界事务。在该循环的第二个循环中,在currentreport.lastreport 对象中将出现一个完整的clientreport。当客户端调用submitwork()时,web 服务客户端stub 类中相应方法调用serializer.attachpendingreporttomessage() 将该报告连接到soap信息上。
cyclesperxact和numberxacts用于控制每件事务的web服务调用数和客户端在运行过程中递交的事务数。
右击应用程序图标xactclientapp;先选择build all项,接着选择execute项。在执行窗口中,你会看到:对于每件事务,应用都报告它收到的事务标志符。观察应用服务windows输出控制台,你可以看到以下的代码行:
info: core3274: successful server startup
info: core5053: application onready complete.
info: core3282: stdout: exception occurred connecting to queue: javax.naming.nam
enotfoundexception
info: core3282: stdout: exception occurred connecting to queue: javax.naming.nam
enotfoundexception
info: core3282: stdout: exception occurred connecting to queue: javax.naming.nam
enotfoundexception
info: core3282: stdout: exception occurred connecting to queue: javax.naming.nam
enotfoundexception
我们还没有安装应用服务次数排列或者配置应用服务次数读取器ejb。客户端产生次数福建,服务器接收它,并试图将它列队到一个不存在的队列中。serializer 类只是报告错误并允许应用程序继续运行。回想我们的目标之一就是保持商业事物系统的总可靠性。可是我们却看到即使新的次数组件失败,关键的商业事务仍然可以照常进行。 定义服务器次数队列
为了定义服务器的次数队列,我们必须创建一个java messaging service (jms) 队列以便我们可以异步地传递来自于web服务处理器的次数附件到处理次数的ejb组件中。
sun one应用服务器有一个嵌入式的sun one信息队列(mq) 服务器。你可以三步完成应用服务器内的队列的定义。首先,定义一个物理目的文件。其次,创建一个关联的jms 目的文件的源文件。最后,定义queueconnectionpool,使它能允许应用连接到队列中并完成操作。
你可以使用application server administration console 来完成这三个步骤。在windows下,点击开始菜单,依次选择程序、sun 微系统、sun one应用服务 、最后选择start administrator console即可。
要创建物理目的文件,你得通过应用服务器来实现,这可以通过依次选择jms、services 和physical destinations来完成。点击按钮new 就可创建一个新的目的文件。将新文件命名为testmdbqueue,选择一个队列类型,然后点击ok。
创建队列的源目的文件也得通过应用服务器。同样的,选择jms,再选destination resources。点击按钮new,输入jms/testmdbqueue作为jndi (java 命名和目录接口) 名,选择类型javax.jms.queue并点击ok。创建了目的文件后,惦记他,然后点击它的properties 按钮。输入唯一的属性imqdestinationname,并将它赋值为testmdbqueue。这可以使队列与我们刚才创建的物理目的文件关联起来。
最后,我们要创建连接工厂。这也得在应用服务器上进行。选择jms,然后选择connection factories;点击new,输入jms/testmdbfactory作为jndi名,选择类型javax.jms.queueconnectionfactory,然后点击ok。
你必须将修改应用到实际的队列组件上。点击应用服务器上的apply changes 按钮, 在服务器控制台输出窗口内你将看到创建的新组件:
info: jms5002: binding [< jms destination: jms/testmdbqueue, javax.jms.queue, [
imqdestinationname=testmdbqueue ] >]
info: jms5002: binding [< jms connection factory: jms/testmdbfactory, javax.jms.
queueconnectionfactory, no properties >]
建立和配置服务器次数读取器ejb组件
我们已经创建了一个服务器队列,现在我们可以配置信息驱动的ejb组件,它可读取来自队列的次数附件。首先安装文件系统<download directory>/metrics/mdbtester 并点击 testmdb(ejb) 图标。在它的属性窗口内,点击sun one as 跳格键并检测最后两个属性:映射访问。点击这两个属性并确认他们能够访问我们前面定义的jms 源文件。
右击ejbmodule_testmdb并选择deploy项。在ejb组件配置后,我们在应用服务器控制台的输出窗口内会看到与下列信息类似的信息:
info: mdb00044: deploying message-driven bean [ejbmodule_testmdb:testmdb], consu
ming from [jms/testmdbqueue]
info: mdb0001: create message-driven bean pool with maximum pool size [640], bea
n idle timeout [600] seconds
info: mdb00022: [ejbmodule_testmdb:testmdb]: message-driven bean listening on jm
s destination [testmdbqueue]
info: ldr5010: all ejb(s) of [ejbmodule_testmdb] loaded successfully!
这个 ejb组件可放在一个单独的模块内因为我们在其他的服务中配置它的机率比事务服务应用中的配置机率还大一些。 运行样品实现
至此,我们已经配置了次数报告所需的所有基础设施,我们可以看一些客户端相应次数的报告。再次执行xactclientapp ;这一次,应用服务控制台输出窗口内将出现下列信息:
info: core3282: stdout: took:2613 ms. for: 1 submit,check,gets
info: core3282: stdout: took:431 ms. for: 1 submit,check,gets
info: core3282: stdout: took:4307 ms. for: 1 submit,check,gets
info: core3282: stdout: took:871 ms. for: 1 submit,check,gets
每一次次数读取器ejb组件都收到一个客户端报告,它将报告解码到clientreport 上并报告clientelapsedms 字段。在本例中,ide和应用服务器都在 compaq公司的 presario 膝上型电脑上运行,所以报告的响应次数当然不是典型的应用服务次数。
注意,当客户端执行五个事务时,实际上只有四个报告。客户端应用会话期的最后一个事务不报告因为对于整个报告来说没有后续的事务可运载报告。
此次实现基本上是一个取样。它收集了大多数事务――当然足够测量服务的质量――但是不是全部。要纠正它我们得对客户端应用做一些调整。提高payload软件包可持续会话期间的次数报告,但是这仍然不能保证所有事务都报告。因为我们在次数收集失败时仍然允许事务继续,这是一个很重要的目标,整个系统必须总是一个事务取样器,而不是彻底的记录器。
改进和后续工作
这个实现可在几个方面得到改进,从而为企业提供更多的便利。
你可以扩展clientreport类,这样客户端就可以报告更多关于事务的信息。当分析服务器上的响应次数时,我们知道的关于事务的信息越多,分析就会越好。辨别出哪种事务要占用很长时间,这很重要。由于服务器瓶颈问题,占用很长时间的事务与生俱来的就要复杂一些。减小服务器瓶颈的压力是原则性的目标。改进clientreport最好的方法是添加 (attribute,value)字符串排列,该排列允许客户端报告事务的二进制特征。
次数收集结构也有助于企业服务管理的其它方面。当服务器在域中有上千个或者上万个客户端的话,保证服务器软件升级后仍与现有的客户端库兼容,这很重要。但是哪种软件版本是客户端运行的呢?这常常难以确定,但是如果clientreport 类可以使用客户端软件版本域扩展,也可使用客户端操作系统版本扩展,简单的次数数据库查询就会提供该信息。
你可以改进payload软件包来报告客户端软件错误。客户端异常处理可保存产生失败的上下文的细节,这样当应用程序重启时payload软件包可以上传该信息。这突出了主要潜在问题的一个方面:警报。 次数读取器ejb组件在收到客户端软件错误报告时,就可以开始它的商业工作流程处理。它可以产生一个snmp (简单网络管理协议)陷阱或者发送email,允许客户服务人员启动一个调用到擅长解决问题的用户那里去。
接收精确的客户端响应次数
在本文中,我展示了如何将事务响应次数记录层压到现有的j2ee服务应用上。该方法可用于测量客户端应用方面的精确的响应次数。这个实现是轻便的。客户端和服务器之间不需要新的网络通信。次数有效载荷为低优先级的登记列队等待,所以预订服务器资源来处理应用程序。(全文完)
要建立样品客户端应用,请将下列文件系统添加到ide中:<download directory>/metrics/transactionclient.
该文件系统包含一个应用类和一个xact 软件包。应用类可模仿客户端事务的执行,xact 软件包包含客户端web服务处理器。
xact软件包可使用sun web服务开发者工具包来创建,这个工具包包括在sun one应用框架内。批文件gen.bat使用wscompile命令创建xact软件包。如果你想重建该软件包的话, 你只需调整环境变量和它使用的config.xml 中的url。但是,如果你这样做的话,你得重写添加到stub 类web方法的代码行,你要用它来覆盖原来的代码行。
我们看看xactclientapp,样品客户端应用程序类:
| import xact.*; import javax.xml.rpc.stub; import payload.*; public class xactclientapp { /** creates a new instance of xactclientapp */ public xactclientapp() { } /** * @param args the command line arguments */ public static void main(string[] args) { try { int cyclesperxact = 1; int numberxacts = 5; string transactionid = ""; string transactiontype = string.valueof(cyclesperxact) +" submit,check,gets"; stub stub = createproxy(); xactserviceservantinterface xact = (xactserviceservantinterface)stub; currentreport cr = new currentreport(); for (int x=1; x<= numberxacts;x++){ cr.begintransaction(); for (int i=1; i<=cyclesperxact;i++){ transactionid = xact.submitwork("new transaction"); system.out.println("transaction:" + transactionid); boolean unused = xact.checkwork(transactionid); string ignore = xact.getresult(transactionid); } cr.committransaction(transactionid, transactiontype,"success"); } } catch (exception ex) { ex.printstacktrace(); } } private static stub createproxy() { return (stub)(new xactservice_impl()).getxactserviceservantinterfaceport(); } } |
先看它的内部循环。客户端应用判断商业事务的组成。在本例中,它包括三个web服务调用:针对submitwork()、checkwork()和getresult()的分别调用。客户端使用begintransaction()和 committransaction()定界事务。在该循环的第二个循环中,在currentreport.lastreport 对象中将出现一个完整的clientreport。当客户端调用submitwork()时,web 服务客户端stub 类中相应方法调用serializer.attachpendingreporttomessage() 将该报告连接到soap信息上。
cyclesperxact和numberxacts用于控制每件事务的web服务调用数和客户端在运行过程中递交的事务数。
右击应用程序图标xactclientapp;先选择build all项,接着选择execute项。在执行窗口中,你会看到:对于每件事务,应用都报告它收到的事务标志符。观察应用服务windows输出控制台,你可以看到以下的代码行:
info: core3274: successful server startup
info: core5053: application onready complete.
info: core3282: stdout: exception occurred connecting to queue: javax.naming.nam
enotfoundexception
info: core3282: stdout: exception occurred connecting to queue: javax.naming.nam
enotfoundexception
info: core3282: stdout: exception occurred connecting to queue: javax.naming.nam
enotfoundexception
info: core3282: stdout: exception occurred connecting to queue: javax.naming.nam
enotfoundexception
我们还没有安装应用服务次数排列或者配置应用服务次数读取器ejb。客户端产生次数福建,服务器接收它,并试图将它列队到一个不存在的队列中。serializer 类只是报告错误并允许应用程序继续运行。回想我们的目标之一就是保持商业事物系统的总可靠性。可是我们却看到即使新的次数组件失败,关键的商业事务仍然可以照常进行。 定义服务器次数队列
为了定义服务器的次数队列,我们必须创建一个java messaging service (jms) 队列以便我们可以异步地传递来自于web服务处理器的次数附件到处理次数的ejb组件中。
sun one应用服务器有一个嵌入式的sun one信息队列(mq) 服务器。你可以三步完成应用服务器内的队列的定义。首先,定义一个物理目的文件。其次,创建一个关联的jms 目的文件的源文件。最后,定义queueconnectionpool,使它能允许应用连接到队列中并完成操作。
你可以使用application server administration console 来完成这三个步骤。在windows下,点击开始菜单,依次选择程序、sun 微系统、sun one应用服务 、最后选择start administrator console即可。
要创建物理目的文件,你得通过应用服务器来实现,这可以通过依次选择jms、services 和physical destinations来完成。点击按钮new 就可创建一个新的目的文件。将新文件命名为testmdbqueue,选择一个队列类型,然后点击ok。
创建队列的源目的文件也得通过应用服务器。同样的,选择jms,再选destination resources。点击按钮new,输入jms/testmdbqueue作为jndi (java 命名和目录接口) 名,选择类型javax.jms.queue并点击ok。创建了目的文件后,惦记他,然后点击它的properties 按钮。输入唯一的属性imqdestinationname,并将它赋值为testmdbqueue。这可以使队列与我们刚才创建的物理目的文件关联起来。
最后,我们要创建连接工厂。这也得在应用服务器上进行。选择jms,然后选择connection factories;点击new,输入jms/testmdbfactory作为jndi名,选择类型javax.jms.queueconnectionfactory,然后点击ok。
你必须将修改应用到实际的队列组件上。点击应用服务器上的apply changes 按钮, 在服务器控制台输出窗口内你将看到创建的新组件:
info: jms5002: binding [< jms destination: jms/testmdbqueue, javax.jms.queue, [
imqdestinationname=testmdbqueue ] >]
info: jms5002: binding [< jms connection factory: jms/testmdbfactory, javax.jms.
queueconnectionfactory, no properties >]
建立和配置服务器次数读取器ejb组件
我们已经创建了一个服务器队列,现在我们可以配置信息驱动的ejb组件,它可读取来自队列的次数附件。首先安装文件系统<download directory>/metrics/mdbtester 并点击 testmdb(ejb) 图标。在它的属性窗口内,点击sun one as 跳格键并检测最后两个属性:映射访问。点击这两个属性并确认他们能够访问我们前面定义的jms 源文件。
右击ejbmodule_testmdb并选择deploy项。在ejb组件配置后,我们在应用服务器控制台的输出窗口内会看到与下列信息类似的信息:
info: mdb00044: deploying message-driven bean [ejbmodule_testmdb:testmdb], consu
ming from [jms/testmdbqueue]
info: mdb0001: create message-driven bean pool with maximum pool size [640], bea
n idle timeout [600] seconds
info: mdb00022: [ejbmodule_testmdb:testmdb]: message-driven bean listening on jm
s destination [testmdbqueue]
info: ldr5010: all ejb(s) of [ejbmodule_testmdb] loaded successfully!
这个 ejb组件可放在一个单独的模块内因为我们在其他的服务中配置它的机率比事务服务应用中的配置机率还大一些。 运行样品实现
至此,我们已经配置了次数报告所需的所有基础设施,我们可以看一些客户端相应次数的报告。再次执行xactclientapp ;这一次,应用服务控制台输出窗口内将出现下列信息:
info: core3282: stdout: took:2613 ms. for: 1 submit,check,gets
info: core3282: stdout: took:431 ms. for: 1 submit,check,gets
info: core3282: stdout: took:4307 ms. for: 1 submit,check,gets
info: core3282: stdout: took:871 ms. for: 1 submit,check,gets
每一次次数读取器ejb组件都收到一个客户端报告,它将报告解码到clientreport 上并报告clientelapsedms 字段。在本例中,ide和应用服务器都在 compaq公司的 presario 膝上型电脑上运行,所以报告的响应次数当然不是典型的应用服务次数。
注意,当客户端执行五个事务时,实际上只有四个报告。客户端应用会话期的最后一个事务不报告因为对于整个报告来说没有后续的事务可运载报告。
此次实现基本上是一个取样。它收集了大多数事务――当然足够测量服务的质量――但是不是全部。要纠正它我们得对客户端应用做一些调整。提高payload软件包可持续会话期间的次数报告,但是这仍然不能保证所有事务都报告。因为我们在次数收集失败时仍然允许事务继续,这是一个很重要的目标,整个系统必须总是一个事务取样器,而不是彻底的记录器。
改进和后续工作
这个实现可在几个方面得到改进,从而为企业提供更多的便利。
你可以扩展clientreport类,这样客户端就可以报告更多关于事务的信息。当分析服务器上的响应次数时,我们知道的关于事务的信息越多,分析就会越好。辨别出哪种事务要占用很长时间,这很重要。由于服务器瓶颈问题,占用很长时间的事务与生俱来的就要复杂一些。减小服务器瓶颈的压力是原则性的目标。改进clientreport最好的方法是添加 (attribute,value)字符串排列,该排列允许客户端报告事务的二进制特征。
次数收集结构也有助于企业服务管理的其它方面。当服务器在域中有上千个或者上万个客户端的话,保证服务器软件升级后仍与现有的客户端库兼容,这很重要。但是哪种软件版本是客户端运行的呢?这常常难以确定,但是如果clientreport 类可以使用客户端软件版本域扩展,也可使用客户端操作系统版本扩展,简单的次数数据库查询就会提供该信息。
你可以改进payload软件包来报告客户端软件错误。客户端异常处理可保存产生失败的上下文的细节,这样当应用程序重启时payload软件包可以上传该信息。这突出了主要潜在问题的一个方面:警报。 次数读取器ejb组件在收到客户端软件错误报告时,就可以开始它的商业工作流程处理。它可以产生一个snmp (简单网络管理协议)陷阱或者发送email,允许客户服务人员启动一个调用到擅长解决问题的用户那里去。
接收精确的客户端响应次数
在本文中,我展示了如何将事务响应次数记录层压到现有的j2ee服务应用上。该方法可用于测量客户端应用方面的精确的响应次数。这个实现是轻便的。客户端和服务器之间不需要新的网络通信。次数有效载荷为低优先级的登记列队等待,所以预订服务器资源来处理应用程序。(全文完)
闽公网安备 35060202000074号