TUXEDO培训教材.doc

BEA TUXEDO 培训教材

BEA TUXEDO 6.5

培训材料

2003年1月16日 顾 强
第1节 概 述 5
1.1 培训目标： 5
1.2 培训的主要内容: 5
1.3 内容概述 5
1.3.1 TUXEDO基本特性介绍 5
1.3.2 使用TUXEDO进行应用的开发 5
1.3.3 TUXEDO配置参数详解 5
1.3.4 TUXEDO管理工具的使用 5
1.3.5 TUXEDO 应用系统设计要点 5
1.4 术语定义 6
第2节 中间件基本概念 6
2.1 商业计算模式的演变 6
2.2 中间件是三层结构的手段 7
第3节 BEA TUXEDO 简介 8
3.1 TUXEDO消息处理机制 8
3.1.1 client/server架构的两种模式 8
3.1.2 TUXEDO如何处理client/server架构模式 8
3.1.3 嵌套的服务请求（Nested Service Requests） 8
3.1.4 传递的服务请求(Forward Service Requests) 9
3.1.5 TUXEDO 会话（conversation）处理机制 9
3.1.6 主动通知/事件代理(Unsolicited Notification/ EventBroker) 9
3.2 BEA TUXEDO 3层Client/Server架构 10
3.3 BEA TUXEDO 功能详解 11
3.3.1 高速的数据甬道 11
3.3.2 TUXEDO具有丰富的通讯机制: 11
3.3.3 负载均衡 11
3.3.4 数据依赖路由(DDR) 11
3.3.5 TUXEDO service优先级机制(PRIO) 11
3.3.6 TUXEDO的交易完整性(分布式事务处理) 12
3.3.7 完善的安全机制 12
3.3.8 TUXEDO的开发性 13
3.3.9 自动的编码/解码 13
第4节 用BEA TUXEDO编程 14
4.1 TUXEDO应用的三个组成部分 14
4.2 编写一个BEA TUXEDO 应用的基本步骤 14
4.3 使用TUXEDO ATMI编写客户端程序 14
4.4 编写服务端程序 17
4.4.1 服务端程序在C/S模式中的角色 17
4.4.2 一个SERVER的基本组成 17
4.4.3 Service程序的一般框架 18
4.4.4 一个具体Service的例子 18
4.5 TPSVCINFO类型及TUXEDO常见函数的说明 19
4.5.1 TPSVCINFO类型 19
4.5.2 tpinit() 19
4.5.3 tpcall() 20
4.5.4 tpacall() 20
4.5.5 tpgetrply() 20
4.5.6 tpalloc() 21
4.5.7 tpfree() 21
4.5.8 tpreturn() 21
4.5.9 tpterm() 21
4.6 TUXEDO Buffer类型简介 22
4.6.1 STRING 22
4.6.2 CARRAY 22
4.6.3 VIEW 22
4.6.4 FML 22
4.7 具体DEMO 22
4.7.1 SHM模式应用 22
4.7.2 MP模式应用 22
4.7.3 conversation交易 23
4.7.4 DOMAIN之间交易调用 23
4.7.5 DDR(数据依赖路由) 24
第5节 BEA TUXEDO 配置详解 25
5.1 配置文件的8个组成部分及简要说明 25
5.2 RESOURCES SECTION 25
5.3 MACHINES Section 28
5.4 GROUPS Section 29
5.5 SERVERS Section 29
5.6 SERVICES Section 31
5.7 NETWORK Section 33
5.8 ROUTING Section 33
5.9 完整的UBB配置文件 34
第6节 TUXEDO管理监控工具的使用 37
6.1 应用程序启动、关闭必须要准备的步骤(preliminary steps) 37
6.2 创建TUXCONFIG配置文件 37
6.3 启动应用(tmboot 命令的介绍) 37
6.4 关闭应用(tmshutdown 命令介绍) 38
6.5 命令行管理(tmadmin) 38
6.5.1 tmadmin 命令 38
6.5.2 常见的管理命令的解释 38
6.6 TUXEDO WEB-GUI管理工具 41
第7节 TUXEDO 系统设计要点 42
7.1 业务逻辑代码与数据库逻辑代码分割 42
7.2 性能角度: 42
7.3 系统可扩展性： 42
7.4 服务组件(service/object)的粒度 42
7.5 service组合成server进程的考虑因素 42
7.6 XA问题(全局事务) 42
7.7 数据库连接 43
7.8 Client设计 43

第1节 概 述
1.1 培训目标：
Ø 了解使用中间件的三层应用架构模式。
Ø 了解BEA TUXEDO基本特性。
Ø 能应用TUXEDO进行具体应用的开发。
Ø 了解TUXEDO各项配置参数的含义。
Ø 了解TUXEDO管理工具的使用
1.2 培训内容:
Ø TUXEDO基本特性介绍
Ø 使用TUXEDO进行应用的开发
Ø TUXEDO配置参数介绍
Ø TUXEDO系统设计要点

1.3 内容概述
1.3.1 TUXEDO基本特性介绍
l 中间件的基本概念
l TUXEDO功能简介
1.3.2 使用TUXEDO进行应用的开发
l 编写一个TUXEDO应用程序的基本步骤
l 客户端程序的编写
l 服务端程序的编写
l TUXEDO常见ATMI函数说明
1.3.3 TUXEDO配置参数详解
l TUXEDO配置文件的组成
l 各组成部分的参数含义
1.3.4 TUXEDO管理工具的使用
l 启动、关闭TUXEDO应用
l 命令行管理工具的使用(tmadmin)
1.3.5 TUXEDO 应用系统设计要点

1.4 术语定义
l BB：（Bulletin Board）TUXEDO应用启动时由BBL进程创建的共享内存块，包含了TUXEDO用来进行管理所需要的全部信息
l ATMI：（Application-to-Transaction Monitor Interface）面向事务的应用程序编程接口
l Server:是一个进程，守候一个消息队列
l Service:是一个单一的函数。一个server可以包含多个services.
l DDR：（Data Dependant Routing）数据依赖路由
l PRIO：（Priority）TUXEDO服务优先级机制
l ACLs：（Access Control Lists）访问控制列表。TUXEDO的安全控制机制一种。
l CLOPT：（Command Line Option）命令行参数。这是TUXEDO配置文件Server Section一个参数，在服务进程启动时，用来向服务进程传递参数。
l MSSQ：（Multiple Server Single Queue）TUXEDO多服务单队列机制。多个server共享一个消息队列。

第2节 中间件基本概念
2.1 商业计算模式的演变
（1）集中式到分布式
集中式模式下，所有的应用逻辑、数据资源都集中在一台服务器上。这个服务器一般是大型机。
分布式系统中，每个应用逻辑独立一条机器。数据资源单独一台机器
演变模式如下图：
应用逻辑1
应用逻辑2

数据资源1
数据资源2

大型机系统
应用逻辑1

机器1
应用逻辑2

机器2
数据资源

机器3
集中式 分布式

(2)分布式系统的两层结构阶段
客户端应用:
l 用户界面处理
l 业务逻辑处理
服务端应用:
l 数据库服务器

(3)二层结构在关键业务采用的限制
l 前后台均是专用系统绑定
l 客户机端的扩展性差

l 不够模块化

l 业务逻辑在客户机端
l :
对安全性/业务变化的管理能力差
l
l 关系数据库系统间的互联性差

l 关系数据库间没有交易处理
l 适用于部门级解决方案：小于200个用户

(4)如何对两层的结构进行扩展:

采用多路集中方式，客户端不直接与服务库服务器相连，而是先与一个sesstion connector 相连，再由sesstion connector 与数据库服务器。

（5）分布式系统的三层结构阶段：
对二层系统的扩展,就演变成了分布式系统的三层结构：
将业务逻辑从客户端应用中分离出来，组成业务逻辑服务器。客户端与业务逻辑服务器相联，业务逻辑服务器与数据库相连。这样就演变成 “客户端、业务逻辑服务器、数据库服务器”的三层结构。

2.2 中间件是三层结构的手段
（1） 中间件是将应用映射到相关的资源上的软件技术，它是由一系列的API 和通讯协议所组成的。中间件使得三层的客户服务器架构得以实现。
（2） 使用中间件的应用的优点：
l 灵活地在客户与服务器之间划分数据与逻辑.
l 便于按照业务需求修改客户端或服务器端的逻辑.
l 分隔系统的开发与系统的部署.
l 提供分布交易的全程保护

（3）

第3节 BEA TUXEDO 简介
3.1 TUXEDO消息处理机制
3.1.1 client/server架构的两种模式
Ø 在一个client/server结构的应用中，client(需要服务的实体)和server(提供服务的实体)是互相独立的两个逻辑对象，两者通过通讯来共同完成一个任务。
client发起一个服务请求，并接收server端返回的处理结果。
server端接收并处理client端的请求，并把结果返回到client端。
Ø 一个客户端应用（client application）的功能：组织服务请求数据，并接收请求处理结果。提供通过网络，发送服务请求数据、接收请求结果的机制
Ø 一个服务端应用 (server application) 的功能：接收client端的服务请求数据，根据业务逻辑处理客户请求，并将处理结果返回到client端。

Ø 有两种类型的client/server架构模式
ü 数据请求模式 （适合client/server之间传输大批量数据）
ü 服务请求模式 （适合快速的、级小数据传输的服务请求）

3.1.2 TUXEDO如何处理client/server架构模式
TUXEDO使用conversation(会话)方式来处理 “数据请求模式”
TUXEDO使用 request/reponse 方式来所处理 “服务请求模式”
使用TUXEDO的client/server应用的特点:
Ø 快速的，无连接的通讯：
在应用TUXEDO的系统中，客户端与TUXEDO bulletin board 建立连接(而不是与具体的Server建立直接的连接) ，然后由TUXEDO寻找最合适的SERVER来提供服务。这样节省了系统资源，提高了系统性能。
队列是实现无连接通讯结构的关键。每个SERVER被分配一个内部的消息队列，被称为“请求队列”，每一个客户端也被分配一个消息队列，被称为“响应队列”。这样客户端不用与具体的SERVER建立并维持连接，而只要检索“响应队列”来获得返回结果。

Ø 服务进程的透明性：
BB 包含一个后台所有service的目录，客户端只要按名调用后台service，而不用管service所在何处。

Ø 可扩展性：
因为service和server可以很容易的复制，并且它们可以是分布式的，因此，可以很方便的根据系统的负载来调整后台应用。

3.1.3 嵌套的服务请求（Nested Service Requests）
服务可以嵌套调用。一个service嵌套调用另外一个service,必须等到被调用的service返回，才能做下一步的处理。
嵌套调用优点：代码的可重用。缺点：影响系统的整体性能，尤其是在分布式应用服务器的架构中。
如果可能的话，嵌套应该限制在两层。在一个典型的三层模式的应用中，只有两层的嵌套调用会取得很好的效果。这三层是
Ø 表现层（Presetation Logic Layer）
Ø 业务逻辑层（Bussiness Logic Layer）
Ø 数据库层（Database Layer）

3.1.4 传递的服务请求(Forward Service Requests)
另外一种服务嵌套调用的方式是forward方式。在forward 方式中，service不是将处理结果返回给客户端，而是将服务请求传递给下一个service,下一个service或者将处理结果返回给客户端，或者继续传递。
forward 调用的层次没有限制，也不会导致server的堵塞。

3.1.5 TUXEDO 会话（conversation）处理机制
除了request-reply的消息机制，TUXEDO还支持大数据量的传输。TUXEDO采用叫做会话（CONVERSATION）的方式来处理。
在client端与server端建立一个虚连接(a virtual connection)，并且维持这个连接直到完成数据传输任务。
TUXEDO 提供一组API函数用于实现client与server端的这种通讯机制。主要包括
连接，发送、接受、终止连接。
Conversation这种通讯机制，是半双工的，只有取得控制权的一方，才可以发送数据。另外一方只能被动的接受数据。
在配置上conversation 模式的SERVER 要加 “CONV =Y”参数

3.1.6 主动通知/事件代理(Unsolicited Notification/ EventBroker)
TUXEDO还支持非listening -- reply的通讯方式，可以定义当某个“条件”满足时，系统自动与另外的系统进行通讯，即使其他系统没在listening。这个“条件”在TUXEDO中称为event
这种主动通讯方式叫做Unsolicited Notification

3.2 BEA TUXEDO 3层Client/Server架构

sss

采用BEA TUXEDO 开发分布式应用，开发人员只要处理
n 用户界面
n 业务逻辑
n 数据库访问
其他底层处理，全部由TUXEDO 来处理：
n 网络通讯
n 负载均衡
n 容错处理
n 数据一致性
n 可扩展性
n 跨平台性
n 安全控制
n 系统管理

因此要开发大型部门关键事务处理的分布式系统，TUXEDO完全可以胜任

3.3 BEA TUXEDO 功能详解
3.3.1 高速的数据甬道
1、在没有使用中级件的传统的二层模式中，每个客户机或客户应用程序均和服务器或服务程序建立“硬连接”。
客户端 N 个 ，服务端 M个，则网络连接数＝N × M 个

2、如果使用了中间件，则客户端与中间件相联，中间件与后台服务相联。
客户端 N 个 ，服务端 M个，则网络连接数＝N ＋ M 个

3.3.2 TUXEDO具有丰富的通讯机制:
Ø 同步调用(tpcall)
Ø 异步调用(tpacall)
Ø 会话(conversation)
Ø 广播
Ø 管道(tpforward)
Ø 发布&订阅(Unsolicited Notification)

3.3.3 Unsolicited Notification实现
TUXEDO ATMI提供了相关的函数来进行主动提供的消息的发送和接收。（主动通知的）消息可能被发送到一个或多个客户端。
为了能够接收TUXEDO系统主动提供的消息，TUXEDO客户端必须指明一个函数来处理主动通知的消息（类似于处理信号的signal()函数）。

3.3.4 负载均衡
Ø 服务器间的负载均衡
Ø 应用进程间的负载均衡
多服务单队列机制（MSSQ）,自动增减应用进程。
Ø 数据依赖路由(DDR)

3.3.5 数据依赖路由(DDR)
客户端对同一个service的调用，TUXEDO可以根据客户端的具体数据，分发到不同服务进程,TUXEDO BB包含一个路由分配表。路由分配表中定义具体的哪个service所服务的请求范围。通过数据路由功能,可以将对同一个service请求的数据扩展到多台服务器。
DDR机制支持了service的多态性。
我们将通过具体的例子来说明DDR机制

3.3.6 TUXEDO service优先级机制(PRIO)
优先级只是针对service而言。优先级高的service优先得到调用。
每个service默认的优先级是50。
例子:A、B、C为三个优先级不同的services
A （20）
B（30）
C（50）
则service调用顺序是CBA。
为了保证优先级低的service有机会得到调用，TUXEDO 以10次为1个循环。第10次不论优先级，而是执行请求队列中多靠前的服务(FIF0)。
3.3.7 TUXEDO的交易完整性(分布式事务处理)
TUXEDO应用中，通过使用TUXEDO提供的事务处理函数来创建一个事务。在事务中的业务处理被看做一个整体，要么一起提交，要么一起回滚。TUXEDO提供一组API函数来begin,commit,rollback 事务。
在一个service中包含一个事务，在事务内部又调用远程主机的一个service
,对远程主机的调用是事务处理的一部分，因此要保证一致性，就要使用TUXEDO的全局事务机制。
为了跟踪分布式事务处理TUXEDO要保留复杂的数据，以便随时都能回滚到事务开始的地方。
为了跟踪事务的参与者，TUXEDO创建事务日志。为了跟踪应用程序的状态，TUXEDO采用一个或多个资源管理器RM（Resource Manager）。这些RM通过XA interface进行交流信息。为了协调事务处理中的所有操作，TUXEDO采用了Transaction Manager (TM)。
为了说明RMs域TM的关系，可以假设RMs是演员，TM是导演。
TUXEDO采用二级提交机制，来实现全局事务的提交。首先是RM进行预提交，预提交全部成功后，TM做最后的真正的提交。

3.3.8 完善的安全机制
在应用层TUXEDO提供5级安全策略。
1、 操作系统级（Operating System）
安全机制由操作系统提供，TUXEDO没有增加另外的安全机制。在配置文件中，security 设置为NONE

2、 应用级密码(Application Password)
要求每个客户端在tpinint时提供应用程序口令。在配置文件中，security 设置为APP_PW.

3、 用户级密码（User Authentication）
每个tpcall都需要提供应用程序口令。在配置文件中，security 设置为USER_AUTH.
缺省的授权控制服务是AUTHSVC,这个服务有BEA TUXEDO系统自带的SERVER程序AUTHSVR提供。

4、 可选的访问控制列表(Optional Access Control Lists)
只要设定某些需要控制的service，任何人都可访问的service不用配置ACL
举例：
用户名 后台service
A TOUPPER(ACL1)
B TOLOWER
C
TOUPPER配置了访问控制列表ACL1,用户A、B有权访问该service
TOLOWER没有配置ACL。
则，TOUPPER，只有A、B用户可以访问，TOLOWER所有用户(A 、B 、C)都可访问

5、 强制的访问控制列表(Mandatory Access Control Lists)
The second ACL security level is MANDATORY_ACL
所有service多必须设定ACL，没有设计ACL的service任何人都不能访问。
上例中，service TOLOWER 任何人不能访问。Service TOUPPER，只有A、B可以访问。

说明：
要使用访问控制列表的安全机制，后台必须增加3个配置文件。分别是 tpgrp,tpusr,tpacl
在unix系统中，如果没有配置tpgrp,tpuser两个文件，则TUXEDO使用/etc/group,/etc/passwd
文件代替。
说明：
1、 使用2－4级安全级别级别即（tuxedo 所带的安全控制机制），客户端在tpinit时需要加上必要的客户信息。
同时后台需要增加一个单独的SERVER来处理安全验证。

3.3.9 TUXEDO的开发性
SERVER 端支持的平台有：
u HP-UNIX
u AIX
u Solaris
u SCO OPER SERVER
u UNIXWARE
u LINIX
u Windows NT ,Windows 2000

客户端支持的平台有：
u WINDOWS
u DOS
u 各种UNIX操作系统。
TUXEDO几乎支持所有的常见开发工具

3.3.10 自动的编码/解码
不同机器之间的通讯,由TUXEDO自动进行Ecode/Decode(编码/解码),在配置文件中可以指定机器的类型。如果不指定，TUXEDO默认所有机器类型相同。

第4节 用BEA TUXEDO编程
4.1 TUXEDO应用的三个组成部分
Ø Client端:需要服务的部分
Ø Server端：提供服务的部分
Ø 配置文件：用来描述应用程序信息，如应用的架构模式、机器信息、server信息等。
4.2 编写一个BEA TUXEDO 应用的基本步骤
1、 设置正确的环境变量
u TUXDIR TUXEDO的安装目录
u PATH 必须包括$TUXDIR/bin
u LD_LIBRARY_PATH 必须包括$TUXDIR/lib
u TUXCONFIG 二进制的tuxconfig配置文件的全路径
u APPDIR 服务端可执行文件目录

2、 编写并编译客户端程序
buildclient –o simpcl –f simpcl.c

3、 编写并编译服务端程序
buildserver –o simpserv –f simpserv.c –s TOUPPER –r INFORMIX-OnLine

-r RM(Resource Manager),RM在$TUXDIR/udataobj/RM文件中定义。

4、 编译应用程序的配置文件(UBBCONFIG)，创建二进制配置文件(tuxconfig)
tmloadcf –y ubbsimple

5、 启动TUXEDO应用
tmboot -y

6、 通过client程序测试应用

7、 关闭TUXEDO应用
tmshutdown –y

4.3 使用TUXEDO ATMI编写客户端程序

客户端程序是应用的表示层:负责收集服务请求的数据，发起交易请求，处理交易返回数据并将交易处理结果显示给操作员。

1、 客户端通讯方式
BEA TUXEDO提供一组函数来支持5种通讯方式
Ø 同步（synchronous）
客户端发起一个交易请求(tpcall)并且block等待交易的返回
Ø 异步(asychronous)
客户端发起一个交易请求(tpacall), 但是没有等待交易的立即返回。
在随后的时间里，来检索交易返回数据
Ø 会话(converstaion)
客户端与后台的会话SERVER建立一个“dialogue”(tpconnect),这个连接是逻辑上连接。客户端与服务端不断交换数据(tpsend,tprecv),直到会话结束。

Ø 存储(stored)
客户端发送一个请求到一个消息队列(tpenqueue)，在随后的时间的检索结果（tpdequeue）。这个通讯方式TUXEDO/Q 特征才具备。
Ø 主动传播（unsolicited）

2、 加入/离开应用程序(joining/leaving Application)
加入应用程序(joining application) (tpinit)
Ø 如果需要安全校验的话，首先进行安全校验
Ø attach to 共享内存BB(bulletin board),在BB中登记这个客户端。
Ø 为这个客户端创建一个消息队列
离开应用程序(leaving application)（tpterm）
Ø updates BB to unregister itself
Ø deattach from BB
Ø removes message queue

3、 具体一个客户端例子
调用后台名为TOUPPER的service,将输入的参数转换成大写。
/* Attach to System/T as a Client Process */
if (tpinit((TPINIT *) NULL) == -1)
{
(void) fprintf(stderr, "Tpinit failed\n");
exit(1);
}

/* Allocate STRING buffers for the request and the reply */
if((sendbuf = (char *) tpalloc("STRING", NULL, sendlen+1)) == NULL)
{
(void) fprintf(stderr,"Error allocating send buffer\n");
tpterm();
exit(1);
}

if((rcvbuf = (char *) tpalloc("STRING", NULL, sendlen+1)) == NULL)
{
(void) fprintf(stderr,"Error allocating receive buffer\n");
tpfree(sendbuf);
tpterm();
exit(1);
}

/* Request the service TOUPPER, waiting for a reply */
ret = tpcall("TOUPPER", (char *)sendbuf, 0, (char **)&rcvbuf, &rcvlen, (long)0);

/* Free Buffers & Detach from System/T */
tpfree(sendbuf);
tpfree(rcvbuf);
tpterm();

4、 错误返回值宏定义
当一个ATMI call出现错误，TUXEDO的一个全局变量tperrno将被置值,使用宏定义=tpstrerrno(tperrno)。具体的宏定义:

TPEABORT Transaction can not commit
TPEBADDESC Bad descriptor for tpgetrply(3c)
TPEBLOCK Blocking condition found and no-block specified
TPEINVAL Invalid arguments given
TPELIMIT Too many handles outstanding
TPENOENT No entry found or no room on the Bulletin Board
TPEOS Operating system error
TPEPERM Bad permissions or failed authentication
TPEPROTO Protocol error
TPESVCERR Server error while handling request
TPESVCFAIL Application level service failure
TPESYSTEM Internal BEA TUXEDO error (userlog(3c)) message written)
TPETIME Time-out occurred and TPNOTIME was not specified
TPETRAN Caller in transaction mode and transaction aborted
TPGOTSIG Signal received and TPSIGRSTRT not specified
TPERMERR Resource Manager failure
TPEITYPE Type and/or subtype do not match services
TPEOTYPE Type and/or subtype do not match buffers or unknown
TPERELEASE Caller has made a 3.0 library call
TPEHAZARD Hazard exists that transaction heuristically completed
TPEHEURISTIC Transaction heuristically completed
TPEEVENT Event occurred
TPEMATCH Service name cannot be advertised due to matching conflict

4.4 编写服务端程序
4.4.1 服务端程序在C/S模式中的角色
服务进程在启动时，与数据库建立连接，并循环等待、处理客户端服务请求，直到进程被关闭。

“OPEN”Resources

Advertise Services

Server Message Queue

Recevice Request

Shutdown?

Client

YES
NO

Database
Process Request

Client
Reply Queue

Send Reply

Unadvertise Services

“CLOSE”Resources

4.4.2 一个SERVER的基本组成
SERVER包括两个部分：标准的main函数和用户函数部分

1、 标准main函数处理
Ø 屏蔽用户信号
Ø 处理命令行参数(具体参数件后面的配置说明)
Ø 创建一个消息队列，接收并响应服务请求
Ø 在BB上创建一个entry
Ø 在BB上advertise进程所有的services
Ø 执行tpsrvinit函数，进行应用程序的初始化(如打开数据库)。
Ø 循环处理服务请求，直到进程关闭。在每次处理服务请求中,所做的工作:
ü 等待一个请求消息出现在进程的队列中
ü 将请求消息出队（dequeue）
ü 如果使用了-r参数，记录消息请求的时间
ü 更新Bulletin Board,标记SERVER is busy.
ü 调用用户函数来处理具体的消息请求
ü 如果使用了-r参数，记录消息请求处理完成时间
ü 更新Bulletin Board,标记SERVER is idle.
Ø server 被shutdown时，调用tpsrvdone函数，完成应用的清除工作
Ø remove 进程所创建的消息队列，并且删除在BB上的entry

2、 用户函数处理
Ø 程序员写的用来处理客户端请求的函数

4.4.3 Service程序的一般框架
SERVICE_NAME(TPSVCINFO * rqst)
{
取得输入数据 rqst->data
判断输入数据的合法性
构造SQL语句
开始交易
执行SQL语句，操纵数据库
交易结束
返回结果给client端/*tpreturn*/

}
4.4.4 一个具体Service的例子
tpsvrinit(int argc, char *argv[])
{
userlog("Welcome to the simple server");
return(0);
}
void
TOUPPER(TPSVCINFO *rqst)
{

int i;
for(i = 0; i < rqst->len-1; i++)
rqst->data[i] = toupper(rqst->data[i]);

/* Return the transformed buffer to the requestor. */
tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);
}

4.5 TPSVCINFO类型及TUXEDO常见函数的说明
4.5.1 TPSVCINFO类型
TPSVCINFO 是TUXEDO 自带的$TUXDIR/include/atmi.h 中的 自定义类型