有这么几个概念以及它们之间的关系：
GROUP：一个组中可以有多个server SERVER：一个server中可以有多个service
从上向下看：可以理解成tuxedo通过对组的部署，管理所有的server及service 从资源管理（RM）的角度看：GROUP中的信息（如：要连接的数据库信息）被组中的所有server共享。
从 管理维护的角度看：server与service的关系。一个service对应一个server是最简单的方式，但这会增加server的数量，也就是 进程数，使tuxedo系统对系统的IPC资源要求增大，导致系统性能下降；或超过系统限制
（UNIX:maxfiles，maxfiles_lim）， 导致tuxedo系统无法启动成功。所以需要把多个service放到一个server中，以降低tuxedo对系统IPC资源的要求。当把一些 service放到一起时，有这么几个原则：
1.有相互调用的service不要放到一个server中，以免引起死锁现象。 2.执行时间相近的service可以放到一个server中。
3.同一个server中的service最好有相同的服务优先级。如果不同，优先级最低的请求可能要很长时间才得到处理。 4.一个server中不要有太多的service。
5.把资源要求相近的service放到同一个server中。 6.可根据业务规则把service放到同一个server中。
7.把一些使用率较高的service应单独放在一个server中，并采用MSSQ方式。
tuxedo中关于超时的参数较多,现收集整理了下相关文档与大家分享 SCANUNIT
BBL 系统进程对Bulletin Board的管理和监控是基于时间片的轮询方式，时间片的大小就是SCANUNIT的值，SCANUNIT是Tuxedo对系统进行管理的最基本时间单 位，其他许多时间方面的参数均是SCANUNIT的倍数。每隔SCANUNIT，BBL对Bulletin Board进行一次检查，看看有无超时的事务或服务请求。SCANUNIT必须是大于0的5的倍数，最大是60，缺省10，单位为秒。 BLOCKTIME
服务请求的超时值，BBL发现有超时的Request时，会给相应的Client端发信息，Client端如果在调用时未加TPNOTIME标记，会报错返 回，tperrno值为13。由于BLOCKTIME是以SCANUNIT为单位的，所以时间的绝对值为(BLOCKTIME * SCANUNIT)，BLOCKTIME缺省为(60/SCANUNIT)。
SANITYSCAN
健全性检查扫描，健 全性检查主要检查Server进程状态和Bulletin Board数据结构， BBL检查Server进程是否存活，如果已经不存在，会清理Bulletin Board中相应的数据项及IPC资源，并根据参数配置决定是否重新启动，如果设了RESTART=Y，所占的Message Queue不会被清，Queue中的Request得到保留，仍会被处理。如果是MP模式，BBL还会给DBBL发状态消息。 SANITYSCAN缺省为(120/SCANUNIT)。
BBLQUERY
BBL 检查，在MP模式下，DBBL会每隔一段时间检查是否所有的BBL都发了\心跳信息给自己，如果没有收到某个BBL的信息，它会发Request给那个BBL，如果等了DBBLWAIT后仍然没有回复，DBBL会认为那台机器 有问题，将其partition。BBL QUERY缺省为(300/SCANUNIT)，DBBLWAIT缺省为(20/SCANUNIT)。BBLQUERY必须大于等于 SANITYSCAN，tmloadcf 时会强制检查，如果设的值小于SANITYSCAN，tmloadcf会自动调整为SANITYSCAN。
其它和时间相关的参数还有:
WSL [-I init-timeout]
WorkStation Client和后台建立连接的超时参数值，缺省60秒
WSL [-T Client-timeout]
WorkStation Client和WSH建立连接后，如果在指定的时间内没有信息交互，WSH会自动释放和这个Client端的连接，并将此Client在Bulletin Board中的数据项请空，RollBack它未完成的事务 。
WSL [-N network-timeout]
此值实际上是WorkStation Client在做receive时的超时值，如果发生超时，此操作会出错，WorkStation Client会断开和后台的连接。
SERVICES中的SVCTIMEOUT
如果SERVICE执行时间超过SVCTIMEOUT，BBL会自动将此Server进程Kill掉。
SERVICES中的TRANTIME
如果此SERVICE设置了AUTOTRAN=Y，则此值为事务超时值，超时后Transaction
Manager会自动RollBack此transaction。
.在会话连接后如发生网络故障，连接断开后是否tuxedo能够自动恢复连接？
2.在使用会话通讯中，通讯双方一方接必然一方收，是否通讯便只能同步处理，客户端发一条请求，通讯控制就交给服务端，客户端就无法向SERVER提交新的请求直到服务端处理完反馈给客户端，把会话控制交回。 3.tuxedo长联方式中只有会话一种吗？
1. TUXEDO/WS客户端在建立和服务端的连接时，首先发送请求到WSL，WSL按照负载均衡算法，挑一个比较闲的WSH的端口号，送回。客户端于是断开与WSL的连接，然后发送SOCKET连接请求给WSH。即一个tpinit()有两次TCP建链动作。
2. WSH接到客户端请求，就为其在共享内存中建立上下文，同时在BBL中注册该客户端。这里，WSH就是WORKSTATION在本地的代理了。
3. TUXEDO的长连接，短连接一般指在一个tpinit()/tpterm()之间是否有多个tpcall()/tpacall()等，即如果建链一次，反复做业务，为长连接；如果每次做业务都要先建链，为短连接。
4. 在TUXEDO的常用函数内部，比如tpcall()都包含了tpinit()代码，在未建链时会自动做初始化动作，但仅限于不含SECURITY的DOMAIN，否则怎么知道该填什么用户名和密码呢？
5. 如果是会话断开，那客户端的上下文也没了，真实情况比较复杂。简单的话，可以理解为不能自动重连。
6. 会话中，可以不把控制权交出去，可以在tpsend()中设置FLAG，让它SEND_ONLY. 7. 由于TUXEDO的SERVICE是无状态的，你所指的长联如果是在一个SERVICE不出来时来回交互，大概会话是最好的实时方法了。如果用广播，时间等等，也可以在一个SERVICE内部执行很多次活动，但不直观。
Fiat兄说得很对,不用tpinit,直接tpcall也是可以的,因为你编译的时候有或者无-w参数已经连接了不同的库了,这样tpcall就知道你 的连接是本地还是WS的,在没有连接的时候,它会先去连接,和tpinit的作用一样的.这个我已经试验过了,效果一样.正如他所说,这个只限于最低的安 全级别的,后3种都不行.
tpinit是一个可选的函数。如果直接使用tpcall或其他API也是可以得
尽管是这样,但是我觉得还是显式的做tpinit是一个好的风格,这样可以及早的发现join application的错误,程序的思路也比较清晰.
同意qiupeng的建议，还是使用tpinit，因为如果网络等有问题，在tpinit就发现了，不会做了什么tpalloc，Fchg32了，到 tpcall才报告网络不通或server有问题等。而且如果使用安全认证的，必须使用tpinit了。
你一个WSL的例子：
WSL SRVGRP=GP_COMMON SRVID=1 CLOPT=\-x5\
CLOP中参数的含义
-A ：option requests that the WSL offer all its services when it is booted. tuxedo启动时开放所有的service -t ：The amount of time to allow for a client to connect to the WSH tuxedo允许一个client连接的时间多长，指连接的动作，不是连接后的持续时间，如果你用tuxedo6.5的client去连tuxedo7, 则必须要写此参数(自己总结的)
-- ：The double-dash (--) marks the beginning of a list of parameters that is passed to the WSL after it has been booted. 表示服务器起来之后的参数，其总的值与UBB中的参数有约束。
-n//10.1.2.69:8888 ：The network address used by WSCs to contact the listener. The WSC must set the appropriate environment variable (WSNADDR) to the value specified after -n. 网络连接参数，客户端可以按照这个设置。
－m : The minimum number of handlers that should be booted and always available. The default is 0. 服务器起来之后的最小常连接
-M : The maximum number of handlers that can be booted. The default is the value of MAXWSCLIENTS for the machine being configured, divided by the multiplexing value (specified with -x).最大常连接，默认值是UBB中的MAXWSCLIENTS的数量。
-x : The maximum number of clients that a WSH can multiplex at one time. The value must be greater than 0. The default is 10.服务器一次处理的最大客户端数量，必须大于0，默认值是10。
可以在CLOPT中加入[-m minh] [-M maxh] [-x mpx-factor]来说明， 例如最大客户端为50时，可以这样说明， WSL SRVGRP=GROUP1 SRVID=100
CLOPT=\
WSL负责监听，由WSH进程和客户端进行通讯，每个WSH最多连接5个客户端（缺省10个），当客户端超过处理数时，WSL增加一个WSH进程来处理，直到达到-M参数指定的值。
In addtional,
-I, 客户端与服务器端建立连接的超时时间； -N, 客户端发起请求的响应超时时间；
-T, 客户端在与服务器端建立连接后，允许最大的空闲时间（即没有任何请求提交）。
Tuxedo是用C开发的中间件，不走J2EE路线, 是和IBM的CICS类似的中间件，和WEBLOGIC概念是不一样的，作用不一样的。WEBLOGIC一般用于Web Service,例如在用JAVA的系统中就很可能用WebLogic.性能上Tuxedo比其他J2EE应用服务器都好。