TUXEDO服务端开发介绍.docx

TUXEDO服务端开发介绍
中海集团资金结算管理系统采用了三层体系结构，具有良好的稳定性、安全性。系统数据集中管理，易于维护。柜面应用程序采用C/S结构，前台界面采用Delphi开发工具，界面具有易于操作，方便快速录入等特点。交易中间件采用tuxedo，保证了前后台数据的交互、队列管理、事务处理。业务逻辑采用C语言开发。
这里，我向大家介绍一下TUXEDO服务器端开发：
一、服务的运行流程
为了更好的了解服务端的所有任务以编写服务端应用，有必要重新认识服务端在C/S模式中扮演的角色。
首先，服务是系统资源的联系点。例如，一个数据库服务联系实际数据库并对其进行查询和修改。为有效进行，应建立一个数据库连接。
其次，服务必须发布系统内可以访问的交易，保证客户端可以知道把请求发往何处。
以上两步结束后，服务进入一个循环——接收请求、处理请求并返回结果。接收请求包括进入消息队列，得到交易请求。处理请求包括检查请求数据缓冲，运行商业规则和逻辑，可能还包括访问数据库和返回结果数据缓冲。
当系统管理员需要关闭系统，可以通过系统管理工具将关闭系统的消息发给服务。服务完成所有交易，取消交易发布，关闭资源连接然后结束。

二、返回控制
接下来，我们说说返回控制。
在一般的C程序中，函数通过调用return()将控制返回，函数调用堆栈清空，控制返回调用点。
TUXEDO系统的交易函数必须结束于将回应返回给客户端或前转到另一交易。函数tpreturn()用来结束交易将回应数据缓冲发给客户端。函数tpforward()将交易前转给另一个交易，由其负责回应原来的客户端。
tpreturn()设计来代替常规的return()，结束绝大多数函数。它将回应数据缓冲返回请求的客户端，控制权返回给服务程序的标准main()（由TUXEDO提供）。
tpreturn()使用下列参数：
第一个值表示交易是否成功，有3种可能：
TPSUCCESS 交易完全成功，如果是一个会话，TPEV_SVCSUCC被生成
TPFAIL 交易失败，tperrno将被设成TPESVCFAIL。如果是事务模式，事务被标志成abort-only，如果是会话，TPEV_SVCFAIL被生成。
TPEXIT 与TPFAIL类似，但服务会中断，如果服务设成可以重启动，则可以由TUXEDO系统将其重启动。
第二个值是应用定义返回码，此处使交易可以发送一个整形代码到客户端，给出交易处理结果的详细信息。该值与/T系统无关，通过全程变量tpurcode送到客户端程序。
第三个值是回应数据缓冲的的指针
第四个值是回应数据缓冲的长度（仅缓冲类型为CARRY时需要）
第五个值是标志位，通常不用
下图是tpreturn()的示意图。

三、初始化和结束服务
tpsvrinit()和tpsvrdone()分别用来启动和关闭服务。如果应用不提供这两个函数，可以使用替代函数。tpsvrinit()用tpopen()缺省打开RM连接。tpsvrdone()用tpclose()关闭RM连接。
tpsrvinit()象标准C语言的main（）一样使用参数argc,argv。服务的命令行参数可以传入该函数，被getopt()解析。该部分的用法参见应用配置部分。本函数出错时返回-1，成功返回0。
tpsvrdone()无参数，无返回值。
四、创建服务
当C语言的交易程序编码完后，需要连接正确的库并编译。使用buildserver可以使该过程容易一点。该命令引用了C语言编译器并按正确的次序连接TUXEDO系统的库,连接TUXEDO生成的main（）等。buildserver还用-s参数产生合适的交易名/函数名映射表。要使用buildserver，必须先正确设定环境变量TUXDIR，PATH，LD_LIBRARY_PATH。命令语法如下：
buildserver [-v] [–o executable] [-s service2,service3:func] [-f source/object] [-l object/library file]
参数解释如下：
-o 生成的可执行文件名
-f 需要在连接TUXEDO库之前传给编译器的文件名。如有多于一个的文件名，名字应用空格分隔并用引号引起。也可以使用多个-f参数。
-l 需要在连接TUXEDO库之前传给编译器的文件名。语法同上。
-v 编译过程显示。
-b 指定SHM或MP模式。如无此项，两种模式都包括；使用此项可以使生成的可执行文件小一点
-r 连接此处指出的RM库。该RM的名字必须含在$TUXDIR/udataobj/RM文件中。
五、规划服务的考虑
在TUXEDO应用中，必要时服务可以仿客户端方式工作。例如：一个服务可能需要其他服务提供的交易，而建立一个副本并不太合理；当然，有时这样做会高效些。这种特性使程序员在多机配置应用逻辑可以改善编码和执行效率。
一般是出于以下考虑，使用此种方式：
最好不要使用收到的数据缓冲向其他服务请求，因为该缓冲可能被改变引起错误
服务中的交易不应调用本服务中的交易，因为容易产生死锁（仅当设置TPNOREPLY时可以）
一个MSSQ集中的服务需要返回时，应有自己的返回队列；否则会与本集中其他服务冲突。
A.数据缓冲管理
数据缓冲管理大部分内容与客户端相同
与请求数据缓冲不同，传给交易的数据缓冲可能已经被tpalloc(),tprealloc(),tpfree()函数处理过。
因为传给交易的请求数据缓冲已经被tpalloc()分配，所以可以tprealloc()。
所有在服务中分配的数据缓冲，在程序结束时必须全部释放唯一例外是用在tpreturn()中的返回数据缓冲。
如有剩余数据缓冲没有释放，会在每次交易调用时都生成一些，最终耗尽服务器内存。这可以很容易通过监视进程大小发现，它会随时间增长而加大。
B.仿客户端的方式
下图展示的流程控制表示一个服务仿客户端方式工作。服务接收客户端请求，进一步向另一个交易进行请求。后者处理后返回前者，前者继续进行处理，准备回应数据缓冲，发回客户端。
此结构不能超过2级！

C.转发的方式
下图展示的流程控制表示交易请求从客户端来到一个服务，转发到另一个服务，然后返回客户端。

D.多个交易
一个商业应用处理可能会需要来自不同数据源的相似信息或功能。
例如下图，TUXEDO有多种方式实现：
各交易功能分隔在独立的可执行服务中
因为功能分布在不同的可执行服务中，编译如下：
buildserver –f read70.c –o read70 –s READ70
buildserver –f read80.c –o read80 –s READ80
buildserver –f read90.c –o read90 –s READ90
将不同功能组织在一个可执行服务中，分隔成不同交易
服务程序包含3个交易函数，编译如下：
buildserver –f read.c –o read –s READ70 –s READ80 –s READ90
合并各功能成一个交易，使用别名调用
使用TUXEDO的别名功能，使交易以不同名字发布，如：
buildserver –f read.c –o read –s READ70,READ80,READ90:READ
READ是真正的交易函数，但服务可以接受对READ70，READ80和READ90的请求
六、动态发布
当交易运行时，交易可以用tmadmin在启动时发布，也可以通过调用ATMI动态发布。交易例程可以通过调用服务发布或取消发布。
tpadvertise()可以被一个服务调用，发布一个交易
tpunadvertise()可以被一个服务调用，取消发布一个交易
tpadvertise()
该函数允许服务为自己动态发布一个交易，参数如下：
被发布的交易名
交易请求处理函数地址
返回值-1表示失败。
如果交易已经被同一函数发布，tpadvertise()立即返回成功。
如果tpadvertise()被一个MSSQ集中的服务调用，交易被发布到该集所有服务上。
出错原因包括：
TPEMATCH 交易已经被其他函数发布
TPELIMIT 可发布交易最大数已经达到，该限制在配置文件中的MAXSERVICES规定
TPEINVAL 有参数为NULL
TPEPROTO 协议错误（如被客户端调用）