分类：
2009-07-08 20:52:50
l 服务的运行流程
l 返回控制
l 创建服务
l 规划服务的考虑
l 启动和关闭
l 一个服务中的交易可以调用另一个服务中的交易
l 一个服务可以提供多个交易
l 发布交易
为了更好的了解服务端的所有任务以编写服务端应用，有必要重新认识服务端在C/S模式中扮演的角色。
首先，服务是系统资源的联系点。例如，一个数据库服务联系实际数据库并对其进行查询和修改。为有效进行，应建立一个数据库连接。
其次，服务必须发布系统内可以访问的交易，保证客户端可以知道把请求发往何处。
以上两步结束后，服务进入一个循环——接收请求、处理请求并返回结果。接收请求包括进入消息队列，得到交易请求。处理请求包括检查请求数据缓冲，运行商业规则和逻辑，可能还包括访问数据库和返回结果数据缓冲。
在一般的C程序中，函数通过调用return()将控制返回，函数调用堆栈清空，控制返回调用点。
TUXEDO系统的交易函数必须结束于将回应返回给客户端或前转到另一交易。函数tpreturn()用来结束交易将回应数据缓冲发给客户端。函数tpforward()将交易前转给另一个交易，由其负责回应原来的客户端。下图是tpreturn()的示意图。
tpreturn()设计来代替常规的return()，结束绝大多数函数。它将回应数据缓冲返回请求的客户端，控制权返回给服务程序的标准main()（由TUXEDO提供）。
tpreturn()使用下列参数：
第一个值表示交易是否成功，有3种可能：
² TPSUCCESS 交易完全成功，如果是一个会话，TPEV_SVCSUCC被生成
² TPFAIL 交易失败，tperrno将被设成TPESVCFAIL。如果是事务模式，事务被标志成abort-only，如果是会话，TPEV_SVCFAIL被生成。
² TPEXIT 与TPFAIL类似，但服务会中断，如果服务设成可以重启动，则可以由TUXEDO系统将其重启动。
第二个值是应用定义返回码，此处使交易可以发送一个整形代码到客户端，给出交易处理结果的详细信息。该值与/T系统无关，通过全程变量tpurcode送到客户端程序。
第三个值是回应数据缓冲的的指针
第四个值是回应数据缓冲的长度（仅缓冲类型为CARRY时需要）
第五个值是标志位，通常不用
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]
例：
buildserver –s DEPOSIT –o TLR –f TLR.o –f appinit.o
参数解释如下：
-o 生成的可执行文件名
-f 需要在连接TUXEDO库之前传给编译器的文件名。如有多于一个的文件名，名字应用空格分隔并用引号引起。也可以使用多个-f参数。
-l 需要在连接TUXEDO库之前传给编译器的文件名。语法同上。
-v 编译过程显示。
-b 指定SHM或MP模式。如无此项，两种模式都包括；使用此项可以使生成的可执行文件小一点
-r 连接此处指出的RM库。该RM的名字必须含在$TUXDIR/udataobj/RM文件中。
在TUXEDO应用中，必要时服务可以仿客户端方式工作。例如：一个服务可能需要其他服务提供的交易，而建立一个副本并不太合理；当然，有时这样做会高效些。这种特性使程序员在多机配置应用逻辑可以改善编码和执行效率。关于这方面的例子，请参见TUXEDO提供的应用实例bankapp中的TRANSFER交易。
一般是出于以下考虑，使用此种方式：
² 最好不要使用收到的数据缓冲向其他服务请求，因为该缓冲可能被改变引起错误
² 服务中的交易不应调用本服务中的交易，因为容易产生死锁（仅当设置TPNOREPLY时可以）
² 一个MSSQ集中的服务需要返回时，应有自己的返回队列；否则会与本集中其他服务冲突。
数据缓冲管理
数据缓冲管理大部分内容与客户端相同
与请求数据缓冲不同，传给交易的数据缓冲可能已经被tpalloc(),tprealloc(),tpfree()函数处理过。
因为传给交易的请求数据缓冲已经被tpalloc()分配，所以可以tprealloc()。
所有在服务中分配的数据缓冲，在程序结束时必须全部释放；唯一例外是用在tpreturn()中的返回数据缓冲。
如有剩余数据缓冲没有释放，会在每次交易调用时都生成一些，最终耗尽服务器内存。这可以很容易通过监视进程大小发现，它会随时间增长而加大。
仿客户端的方式
下图展示的流程控制表示一个服务仿客户端方式工作。服务接收客户端请求，进一步向另一个交易进行请求。后者处理后返回前者，前者继续进行处理，准备回应数据缓冲，发回客户端。
此结构不能超过2级！
转发的方式
下图展示的流程控制表示交易请求从客户端来到一个服务，转发到另一个服务，然后返回客户端。
多个交易
一个商业应用处理可能会需要来自不同数据源的相似信息或功能。
例如下图，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 协议错误（如被客户端调用）
动态发布范例1
$tmadmin
>advertise AUDIT:doaudit –g SYSGRP –i 1
AUDIT发布在组SYSGRP,服务srvid=1
动态发布范例2
void Adminservices(TPSVCINFO *transb)
{
/* 取时间time*/
if ( time>12 midnight && time <
{
if (tpadvertise(“AUDIT”,doaudit) == -1)
{
userlog(“unable to advertise AUDIT service”);
tpreturn(TPFAIL,0,transb->data,
}
}
}
void doaudit(TPSVCINFO *transb)
{
……
}
