中間件介紹：
介於客戶機和server之間的夾層，突破了傳統的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)調用，或其他類型的請求，產生對server的請求。這個事務處理監督器確信，正確地進行了改動，以保證數據的完整性。這在一個事務能夠改變多個位置的數據庫的分布式數據庫環境是很重要的。這個事務處理監督器使用雙階段提交，以保證全部的數據庫都已經接收和認可了這些數據的正確性。否則，這個數據庫返回它的事務前狀態
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，還有對應的環境變量。
Ø 編碼，並編譯client/服務端程序。
Ø 編寫/編譯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),包括了一個公告牌的本地拷貝和本地server上應用的狀態。
l TUXEDO提供的還有一個管理進程DBBL(Distinguished Bulletin Board Liaison)，用於多server配置時。DBBL與BBL協同，保證全部部分的公告牌內容的一致性。
Ø 啟動服務。
Ø 測試（功能測試、壓力測試）。
client/Client開發
client的任務：
獲取採集運行操作應得的數據。
發起向服務端的請求並等待服務端回應。
將結果依照一定格式返回給用戶
client的程序設計和實現應該分成兩個部分：
用戶處理過程。
Tuxedo功能部分。
開發Client涉及的API:
進程管理的API：
int tpinit(TPINIT *tpinfo)
負責將Client端連接到BB，使Client端能夠進一步調用ATMI函數。
TPINIT參數是一個Tuxedo定義的結構，用以存放一些安全相關的數據（必須在tuxedo的配置文件里打開security選項）。否則，能夠使用NULL。
tpinit，不能在server端中出現，否則tuxedo會產生TPEPROTO（協議錯）這樣一個錯誤。
int tpterm( )
client調用tpterm( )切斷與應用的連接，結束了client的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必須公布系統內能夠訪問的交易，保證client能夠知道把請求發往何處
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 服務中的交易不應調用本服務中的交易，由於easy產生死鎖。
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中的事務處理：
事務管理器：