對於JAVA調TUXEDO服務，有三種方法：壹是通過JNI，二是通過WTC，三是通過JOLT！這三種方式各有優劣，簡單的描述為：
JNI
優--無需購買License；發布TUXEDO服務無需做額外限制；無需借助於任何J2EE容器
劣--JNI影響系統移植；防止過度JNI帶來性能問題
WTC（WEBLOGIC為TUXEDO定制）
優--因定制，存在壹套和TUXEDO API相對應的JAVA API；發布TUXEDO服務無需做額外限制；雙向調用
劣--需要購買License；依賴於WEBLOGIC容器，不能移植到其它J2EE容器（如WEBSPHERE，JBOSS）
JOLT
優--可用於但不依賴於J2EE容器（如WEBLOGICWEBSPHERE，JBOSS）；提供的API用WTC類似但不同；
劣--需要購買License；發布TUXEDO服務有些額外的要求；不提供集成的 WebLogic Server-Tuxedo 事務的機制
由此可知，第壹，在受限於License經濟壓力或無法要求UXEDO服務方發布服務的情況下，我們可以選擇JNI方式調TUXEDO服務；
第二，當需要壹般 Java 客戶端或其他 Web 服務器應用程序且 WebLogic Server 不是解決方案的壹部分時，用戶應使用 Jolt（而不使用 WTC）作為解決方案。
對於jolt方式調TUXEDO服務，3個必須的JAR包：jolt.jar、joltjse.jar、joltwls.jar，下面信息也許對您有幫助：
[轉貼]不涉及wls的jolt客戶端實現
1、如果不使用wls，同樣可以使用jolt提供的pool功能，而這又分為兩種：壹種是基於web容器的servlet jolt
pool，另壹種則是普通java客戶端的jolt
pool。前者在$TUXDIR/udataobj/jolt/examples/servlet/simpapp下有示例，後者則未提供。
2、如果不使用jolt產品自帶的pool，也可以自己實現。套路為：創建Jolt Session >
基於此session構建JoltRemoteService對象並發起tuxedo調用 > 釋放jolt
session。這裏有個要點就是在使用session前需要用session.isAlive()來判斷當前session是否可用，因為JSL的-T
參數及防火墻對idle連接的幹擾都可能導致已有的session是無效的。
3、創建JoltRemoteSession時壹定記得為三個超時屬性（IDLETIMEOUT/RECVTIMEOUT/SENDTIMEOUT）進行
顯式的設置。idle超時和tuxedo的JSL
-T屬性對應，該設置將保證session.isAlive()返回正確的布爾值。RECV超時則控制client端自發起call至收到tuxedo
return這壹過程的預期時常。
5、tuxedo側在ubb裏為相應的service配置了SVCTIMEOUT，所以service執行超時後會收到SIGKILL而被終止，這樣壹
來，客戶端的call會收到TPESVCERR錯，對應的異常為bea.jolt.ServiceException。客戶端需要對此異常進行處理，此
外，客戶端捕獲此異常的時間點應當和ulog中該server被kill的時間點對應。
6、在客戶端，時不時會發現由於達到RECVTIMEOUT而導致的客戶端接收超時。客戶的疑問是：當前RECVTIMEOUT設置為25s，而ubb中
相應SVCTIMEOUT設置為10s且scanunit為默認的10s，所以理論上不應發生25s的客戶端RECVTIMEOUT超時。庹達人提出了壹
種懷疑，即client端請求抵達tuxedo側時，server出現排隊情況，請求未被及時處理，這個排隊時長決定了20s以外的時間差。對於此，建議
客戶使用MSSQ，並監控pq的情況。
使用XMLink和Jolt實現IBM WebSphere與BEA Tuxedo的互連 第壹部分
使用XMLink和Jolt實現IBM WebSphere與BEA Tuxedo的互連 第二部分
下面，我們重點關註下WTC，WebLogic Tuxedo Connector (WTC) 提供了 WebLogic Server 應用程序與
Tuxedo 服務之間的互操作性。WTC 允許 WebLogic Server 客戶端調用 Tuxedo 服務，Tuxedo 客戶端調用
WebLogic Server Enterprise Java Bean (EJB) 來響應服務請求，兩者之間的簡單關聯關系如下圖：
關於WTC的配置原則和最佳實踐可參考下面的鏈接：
配置準則
最佳實踐
為方便記，摘錄過來：
配置準則
在配置 WebLogic Tuxedo Connector 時請使用以下準則：
最佳實踐
以下部分提供了使用 WTC 時的最佳實踐：
請參閱“WebLogic Tuxedo Connector 編程人員指南”中的應用程序錯誤管理。
請參閱“WebLogic Tuxedo Connector 管理指南”中的系統級調試設置。
將 Security 的值設置為 DM_PW。請參閱“WebLogic
Tuxedo Connector 管理指南”中的遠程訪問點的身份驗證。
啟用鏈接級加密並將 min-encrypt-bits 參數設置為
40，將 max-encrypt-bits 設置為 128。請參閱“WebLogic Tuxedo Connector 管理指南”中的鏈接級加密。
在 WebLogic Server 群集的所有節點上配置 WTC 實例。
每個群集節點中的每個 WTC 實例都必須具有相同的配置。
請參閱“WebLogic Tuxedo Connector 管理指南”中的如何管理群集環境中的
WebLogic Tuxedo Connector。
在配置連接策略時，請使用 ON_STARTUP 和 INCOMING_ONLY。
ON_STARTUP 和 INCOMING_ONLY 總是成對出現。例如，如果使用 ON_STARTUP 配置了
WTC 遠程訪問點，則必須將遠程訪問點的 Tuxedo 域配置的 DM_TDOMAIN 部分配置為 INCOMING_ONLY。在此情況下，WTC
總是充當會話發起方。請參閱“WebLogic Tuxedo Connector 管理指南”中的配置訪問點之間的連接。
避免使用連接策略 ON_DEMAND。首選連接策略是 ON_STARTUP 和 INCOMING_ONLY。這樣會減少因路由ON_DEMAND 的語義而引起的服務請求失敗。請參閱“WebLogic
Tuxedo Connector 管理指南”中的配置訪問點之間的連接。
在設計應用程序時，請考慮使用以下 WTC 功能：鏈接級故障轉移、服務級故障轉移和負載平衡。請參閱“WebLogic Tuxedo Connector 管理指南”中的配置故障轉移和故障回復。
請考慮使用 WebLogic Server 群集提供額外的負載平衡和故障轉移。要在 WebLogic Server 群集中使用 WTC，請執行下列操作：
如果 WTC 到 Tuxedo 的連接使用了 Internet，則要使用以下安全設置：
應用程序邏輯應該提供機制來管理和解釋應用程序中的錯誤條件。
避免在 TypedFML32 緩沖區內使用嵌入的 TypedFML32 緩沖區。請參閱“WebLogic
Tuxedo Connector 編程人員指南”中的將 FML 用於 WebLogic Tuxedo
Connector。
如果應用程序處理重負載，請考慮配置更多的遠程 Tuxedo 訪問點並讓 WTC 平衡訪問點之間的工作負載。請參閱“WebLogic Tuxedo Connector 管理指南”中的配置故障轉移和故障回復。
在使用事務應用程序時，盡量讓同壹事務中涉及的遠程服務能夠從同壹遠程訪問點訪問。請參閱“WebLogic Tuxedo Connector 編程人員指南”中的 WebLogic
Tuxedo Connector JATMI 事務。
從網關調度服務時，可用的客戶端線程數可能會限制運行的並發服務數。沒有任何 WebLogic Tuxedo Connector 特性可以增加可用線程的數量。在調用服務時請使用合理的線程模型。請參閱“配置
WebLogic Server 環境”中的線程管理和使用工作管理器優化調度的工作。
WebLogic Server 9.2 及更高版本提供了改進的路由算法，這增強了事務性能。具體說就是，當 2 階段提交 (2PC) 事務中具有不止壹項 Tuxedo 服務請求時，性能就會相應提高。如果應用程序僅向
Tuxedo 域執行單個服務請求，則可以通過設置以下 WebLogic Server 命令行參數來禁用此功能：
通過在緩沖區中使用最大數量的對象來調用構造方法 TypedFML32。即使是很難預測最大數量，提供合理的數量也可以提高性能。可以通過將字段的數量乘以
1.33 得到近似的最大數量。
註意：
註意，此性能提示不應用於 TypedFML 緩沖區類型。
例如：
如果在 TypedFML32 緩沖區類型中有 50 個字段，那麽最大數量就是
63。調用構造方法 TypedFML32(63, 50) 比 TypedFML32() 執行得更好。
如果在 TypedFML32 緩沖區類型中有 50 個字段，並且每個字段最多可以有
10 個事件，則調用構造方法 TypedFML32(625, 50) 將會有比 TypedFML32() 更好的性能。
當配置 Tuxedo 應用程序（這些應用程序可以作為與 WTC 客戶端互操作的服務器）時，請考慮平行問題，這壹點可以通過在不同 Tuxedo 計算機上仔細配置不同服務器來實現。
要知道在 Tuxedo 應用程序中可能會存在數據庫訪問死鎖現象。可以通過認真配置 Tuxedo 應用程序來避免死鎖現象。
如果正在使用 WTC 負載平衡或服務級故障轉移，BEA 建議不要禁用 WTC 事務關系。
針對負載平衡出站請求，為導入服務配置使用不同密鑰的多個條目。導入服務將使用復合密鑰來確定每個記錄的唯壹性。復合密鑰的構成：服務名稱 + 本地訪問點 + 遠程訪問點列表中的主要路由。
下面是壹個如何為 service1 在 TDomainSession(WDOM1,TUXDOM1) 和TDomainSession(WDOM1,TUXDOM2) 之間正確配置負載平衡請求的示例：
ResourceName
LocalAccessPoint
RemoteAccessPointList
RemoteName
service1
WDOM1
TUXDOM1
TOLOWER
service1
WDOM1
TUXDOM2
TOLOWER2
下面是壹個錯誤配置負載平衡請求的示例。下面的配置會導致 service1 具有相同的復合密鑰：
ResourceName
LocalAccessPoint
RemoteAccessPointList
RemoteName
service1
WDOM1
TUXDOM1
TOLOWER
service1
WDOM1
TUXDOM1
TOLOWER
在建立連接/會話前更改該會話/連接配置（本地 AP、遠程 AP、密碼和資源）：
接受更改並在新的會話/連接中實現這些更改。
在建立連接/會話後更改該會話/連接配置（本地 AP、遠程 AP、密碼和資源）：
接受更改，但是要到連接斷開並重新連接後，才在現有的連接/會話中實現這些更改。請參閱“管理控制臺聯機幫助”中的定位
WTC 服務。
更改導入和導出服務配置：
接受更改並在下壹個入站或出站請求中實現這些更改。BEA 建議不要使用此做法，因為這會讓正在進行的請求處於未知狀態。
更改 tBridge 配置：
對已部署的 WTC 服務進行任何更改都會導致異常。在進行任何 tBridge 配置更改前都必須先取消對 WTC 服務的定位。在取消定位和進行配置更改後，必須定位 WTC 服務以便實現更改。
在配置中可以有多種 WTC 服務。
只能將壹種 WTC 服務定位到服務器實例。
WTC 不支持連接緩沖池。WTC 通過單個物理連接多路傳輸請求。
配置更改可按照如下方式實現：