Tuxedo入门学习
中间件介绍：
介于客户机和服务器之间的夹层，突破了传统的c/s架构，为构建大规模，高性能，分布式c/s应用程序提供了通信，事物，安全，容错等基础服务，屏蔽了底层应用细节，应用程序不必从底层开发，以自身的复杂性换取应用程序开发的简单。
Tuxedo是什么？
Tuxedo:Transaction for Unix has been Extended for Distributed Operation分布式操作扩展之后的Unix事务系统。
交易中间件位于client和server之间
Tuxedo是一个事务处理(TP)监督器（transaction processing monitor），它管理联机事务处理(OLTP)系统操作的事务。客户通过结构化查询语言(SQL)调用，或其它类型的请求，产生对服务器的请求。这个事务处理监督器确信，正确地进行了修改，以保证数据的完整性。这在一个事务可以改变多个位置的数据库的分布式数据库环境是非常重要的。这个事务处理监督器使用双阶段提交，以保证所有的数据库都已经接收和认可了这些数据的正确性。否则，这个数据库返回它的事务前状态
WTC:WebLogic Tuxedo Connector
OLTP: On-Line Transaction Processing 联机事务处理
OLAP: On-Line Analytical Processing 联机分析处理
ATMI:application-to-Transaction Monitor Interface 应用程序到事务监视器接口
DTP:Distributed Transaction Processing分布式事务处理
MSSQ：Mutile Server,Singal Queue
TUXEDO 采用三层结构的组件软件模型 ：
² Client 为第一逻辑层。实现用户交互和数据表示，向第二层的Server发请求，调用业务逻辑处理服务。
² Server组件中间层，这些组件由TUXEDO管理，实现业务逻辑服务,接收服务请求，并返回服务结果。
² 第三层为资源管理器，比如像关系数据库。负责管理应用系统的数据资源
Tuxedo的核心子系统：
事务管理器 TM(Transaction Manager)
工作站 WorkStation
域 Domain
队列 Queue
队列：
s
X/Open DTP 模型：
Tuxedo 与 WebLogic 通过WTC互联：
通常用TUXEDO实现系统的核心业务，用WEBLOGIC做为系统扩展到web的平台，实现电子商务。由WEBLOGIC 调用 TUXEDO上的服务，需要在Tuxedo和Weblogic之间建立连接。
WTC不仅能让WEBLOGIC调用TUXEDO中的SERVICE，而且能让TUXEDO调用WEBLOGIC中的EJB。但WTC仅能实现这两个平台之间的互联。
Tuxedo与WebLogic 之间通过Domain实现互联调用，Tuxedo与Weblogic分别代表两个TDOMAIN。
使用WTC时，Tuxedo方面要配置相应的Domain配置文件(dmconfig)，指明本身以及weblogic所在Domain的IP和Port。
使用WTC时Weblogic方面要做的修改是：
—在ClassPath 中，加入jamti.jar所在的路径。
—在weblogic的配置文件，bdmconfig.xml 中，加入描述两个TDOMAIN的部分
在Tuxedo和weblogic 启动相应服务后，weblogic通过client端掉用相应ejb，再有该ejb调用tuxedo service。
Tuxedo应用开发：
开发TUXEDO C/S系统的必要步骤：
Ø 设置环境变量，通常写在setenv.sh
TUXDIR：Tuxedo应用的安装路径。
TUXCONFIG:便以后的Tuxedo配置文件路径。
VIEWDIR/VIEWFILES：view文件的路径和文件名。
LD_LIBRARY_PATH：Tuxedo应用时，需要寻找的库文件的路径。
PATH: Tuxedo特用的一些可执行文件的路径
如果涉及到Domain，还有相应的环境变量。
Ø 编码，并编译客户端/服务端程序。
Ø 编写/编译Tuxedo配置文件。
Tuxedo配置文件ubbconfig 描述了应用配置信息。Ubbconfig文件是二进制文件，是由文本文件通过tmloadcf 命令编译而成。
Ubb 文件的内容包括如下的Section：
Resources:包含整个应用范围的信息。必须在配置在文件第一节，不可缺少。
Machines:节包含应用有关的每个处理器的信息。本节必须在*RESOURCES节后列出。
Groups:节包含服务组的定义。一台机器至少要定义一个服务组,每个组只要定义组名，映射组名的组号和逻辑机器名
SERVERS：包含了服务进程的信息。一个入口代表一个应用启动时加载的服务。这些信息包含服务名，命令行参数，服务环境，重启动等等。
SERVICES：提供了应用的特殊交易的信息，包括负载平衡（LOAD）和数据缓冲类型检查（BUFTYPE）。如果全部都是缺省值则本节可以省略。
上述每一个Section中，包含众多的Option选项，具体应用时，察看Tuxedo相关文档，进行配置。
l 在运行时，这些配置信息被装入一段共享内存，称为（Bulletin-Board）。
l TUXEDO提供一个管理进程，称为BBL(Bulletin Board Liaison),包含了一个公告牌的本地拷贝和本地服务器上应用的状态。
l TUXEDO提供的另一个管理进程DBBL(Distinguished Bulletin Board Liaison)，用于多服务器配置时。DBBL与BBL协同，保证所有部分的公告牌内容的一致性。
Ø 启动服务。
Ø 测试（功能测试、压力测试）。
客户端/Client开发
客户端的任务：
获取采集执行操作应得的数据。
发起向服务端的请求并等待服务端回应。
将结果按照一定格式返回给用户
客户端的程序设计和实现应该分成两个部分：
用户处理过程。
Tuxedo功能部分。
开发Client涉及的API:
进程管理的API：
int tpinit(TPINIT *tpinfo)
负责将Client端连接到BB，使Client端可以进一步调用ATMI函数。
TPINIT参数是一个Tuxedo定义的结构，用以存放一些安全相关的数据（必须在tuxedo的配置文件中打开security选项）。否则，可以使用NULL。
tpinit，不能在server端中出现，否则tuxedo会产生TPEPROTO（协议错）这样一个错误。
int tpterm( )
客户端调用tpterm( )切断与应用的连接，结束了客户端的TUXEDO进程 .
编写完成的Client代码，用buildclient 命令进行编译。
buildclient –f filename -O output file
如果client端是一个workstation（本地没有Tuxedo server），还要加上-w 选向。
Clieng与Server 之间的通讯接口：
Client通过ATMI提供的API，与Server之间进行通讯，调用Server提供的服务。
通讯主要分为两种方式：
同步方式：采用同步通讯时，Client端在向Server端发出请求后就被阻塞，等待Server端的返回。
同步通讯方式的API：
int tpcall( char *svc, char *idata, long ilen, char **odata, long *olen, long flags)
Svc ： 调用的服务（service）名称
idata： 指向输入数据缓冲区指针。
ilen： 输入数据的缓冲区大小。
odata：指向输出数据缓冲区指针的指针。
olen： 输出数据缓冲区的大小的指针。
flags： 通讯控制标志。
异步方式：采用异步方式时，Client端在发出请求后，可以继续其他的任务，需要结果时，使用API去获取response队列中的结果。
异步通信方式的API
— int tpacall(char *svc, char *data, long len, long flags)
— tpacall 调用成功后返回一个整数，称为descriptor，client使用这个整数在以后的某个时间来获取结果。
ATMI提供tpgetrply( ) 来获取异步调用的结果
— int tpgetrply(int *cd, char **data, long *len, long flags)
— 参数cd , 就是存放tpacall返回descriptor的指针。
无论是tpcall、tpacall以及tpgetrply，在client端和server端都可以使用。
Server端开发：
l Server是系统资源的联系点。
l Server必须发布系统内可以访问的交易，保证客户端可以知道把请求发往何处
l Server启动后，进入一个循环：接收请求/处理请求/返回节后，周而复始。
l 系统管理员通过命令tmshutdown，显式地关掉tuxedo的服务。
Server端开发涉及的API：
l tpreturn( ): 在Tuxedo中，tpreturn用来代替常规的return函数，执行tpreturn后，server将回应的数据缓冲区返回请求的发起点，交出程序的控制权。
void tpreturn(int rval, long rcode, char *data, long len, long flags)
rval :是返回的结果，通常是TPSUCCESS, TPFAIL, TPEXIT。
rcode：是用户自定义的返回值，用以进一步区分返回结果。
data ：是返回结果缓冲区。len:是缓冲区长度。
flags : 结果返回的标志，通常都是0。
l tpsvrinit()和tpsvrdone()分别用来启动和关闭服务。
如果在server的代码中，不提供这两个函数，Tuxedo将使用缺省函数。
tpsvrinit()用tpopen()缺省打开RM连接。
tpsvrdone()用tpclose()关闭RM连接。
tpsvrinit()只在服务boot起来时执行一次。相应的 tpsvrdone()也只在服务shutdown时执行一次。
设计服务时的几点考虑：
l 最好不要使用收到的数据缓冲向其他服务请求，因为该缓冲可能被改变引起错误。
l 所有在服务中分配的数据缓冲，在程序结束时必须全部释放；唯一例外是用在tpreturn()中的返回数据缓冲。
l 服务中的交易不应调用本服务中的交易，因为容易产生死锁。
l 一个MSSQ集中的服务需要返回时，应有自己的返回队列；否则会与本集中其他服务冲突。（RQADDR = XXXX ,同时REPLYQ = Y）。
缓冲区数据类型：
l Client与Server之间，Server与Server之间，都要通过数据缓冲区来传递数据。
l sTuxedo支持下图所示的缓冲区类型：
l Buffer type包含：STRING,CARRY,VIEW,FML等。
STRING：是以空值结尾的单字字符串
CARRY：有长度定义的二进制数据。
VIEW： 类似于C的structure。
FML： 固定结构的自定义缓冲。
Tuxedo中的事务处理
l 无论是Client还是Server都可以主动发起一个全局事务。
l Tuxedo会对一个transaction产生一个全局交易ID（GTRID)，这个ID号在所有的交易参与这种共享，并唯一标示这个transaction。
l Tuxedo通过TLOG，来跟踪一个全局交易。
l 提供通知(notify)RM的方法，使得RM知道自己参加到一个交易中，并lock住相应的记录。
l Tuxedo作为TM，可以管理两阶段提交（two-phase commit）。使得所有交易参与者一起提交，保持结果的一致性。
TMS和RM之间，使用XA接口来协调工作。
Tuxedo提供tpbegin, tpcommit, tpabort 等API来管理交易
Tuxedo中的事务处理：
事务管理器：