上一節簡單介紹了tuxedo 是什么，並且詳細介紹了安裝過程。我們學這個的目的就是讓其能夠跑起來，這一節就根據tuxedo自帶samples的例子，讓其運行起來。並通過這個例子，深入的理解tuxedo的通訊方式。
進入tuxedo的安裝目錄，samples目錄下自帶了一些例子
[root@localhost atmi]# pwd
/hzh/tuxedo/tuxedo11gR1/samples/atmi
[root@localhost atmi]# ls
bankapp CSIMPAPP qsample simpapp ws xmlstockapp
creditapp libutrace rpcsimp STOCKAPP xmlfmlapp
凡是了解tuxedo 的同學都知道這里面有個著名的例子 simpapp ，它的作用就是把客戶端發送的小寫字母轉換成大寫字母返回給客戶端。我們就把這個例子運行起來。
前期准備：
[root@localhost atmi]# cp -R simpapp/ /hzh/tuxedo/ 為了便於操作，把simpapp 拷貝到/hzh/tuxedo/ 目錄下面。
[root@localhost tuxedo11gR1]# ls
bin help inventory lib samples udataobj
cobinclude include jre locale tux.env uninstaller
[root@localhost tuxedo11gR1]# cp -R tux.env /hzh/tuxedo/simpapp/ 把tuxedo 安裝目錄下的tux.env 配置文件拷貝到/hzh/tuxedo/simpapp/ 目錄下
[root@localhost simpapp]# pwd
/hzh/tuxedo/simpapp
[root@localhost simpapp]# ls
README simpcl.c simpserv.c tux.env ubbsimple
配置運行 simpapp 例子
配置tux.env文件
[root@localhost simpapp]# vi tux.env 對配置文件進行修改
TUXDIR=/hzh/tuxedo/tuxedo11gR1; export TUXDIR
JAVA_HOME=$TUXDIR/jre; export JAVA_HOME
JVMLIBS=$JAVA_HOME/lib/i386/server:$JAVA_HOME/jre/bin
PATH=$TUXDIR/bin:$JAVA_HOME/bin:$PATH; export PATH
COBCPY=:$TUXDIR/cobinclude; export COBCPY
COBOPT="-C ANS85 -C ALIGN=8 -C NOIBMCOMP -C TRUNC=ANSI -C OSEXT=cbl"; export COBOPT
SHLIB_PATH=$TUXDIR/lib:$JVMLIBS:$SHLIB_PATH; export SHLIB_PATH
LIBPATH=$TUXDIR/lib:$JVMLIBS:$LIBPATH; export LIBPATH
LD_LIBRARY_PATH=$TUXDIR/lib:$JVMLIBS:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
WEBJAVADIR=$TUXDIR/udataobj/webgui/java; export WEBJAVADIR
APPDIR=/hzh/tuxedo/simpapp; export APPDIR TUXCONFIG=$APPDIR/tuxconfig; export TUXCONFIG LANG=C; export LANG
配置ubbsimple 文件
[root@localhost simpapp]# hostname //查看本機hostname
node1
[root@localhost simpapp]# vi ubbsimple
# (c) 2003 BEA Systems, Inc. All Rights Reserved. #ident "@(#) samples/atmi/simpapp/ubbsimple $Revision: 1.7 $" #Skeleton UBBCONFIG file for the TUXEDO Simple Application. #Replace the <bracketed> items with the appropriate values. *RESOURCES #IPCKEY <Replace with a valid IPC Key> #Example: IPCKEY 123456 DOMAINID simpapp MASTER simple MAXACCESSERS 10 MAXSERVERS 5 MAXSERVICES 10 MODEL SHM LDBAL N *MACHINES DEFAULT: APPDIR="/hzh/tuxedo/simpapp" TUXCONFIG="/hzh/tuxedo/simpapp/tuxconfig" TUXDIR="/hzh/tuxedo/tuxedo11gR1" #Example: # APPDIR="/home/me/simpapp" # TUXCONFIG="/home/me/simpapp/tuxconfig" # TUXDIR="/usr/tuxedo" node1 LMID=simple //node1為本機hostname名 #Example: #beatux LMID=simple *GROUPS GROUP1 .......
注意：APPDIR、TUXCONFIG和TUXDIR三個選項的路徑要與 tux.env 文件中的配置保持一致。
修改完成，保存退出
[root@localhost simpapp]# . ./tux.env
[root@localhost simpapp]# tmloadcf -y ubbsimple //運行此命令不出出任何提示，表示一切正常
[root@node1 simpapp]# buildserver -f simpserv.c -o simpserv -s TOUPPER //編譯服務器端程序
[root@node1 simpapp]# buildclient -f simpcl.c -o simpcl //編譯客戶端程序
這里需要說明的是，buildserver和buildclient命令需要系統安裝gcc 才能被執行，gcc -v 查看本機是否安裝GCC ，這里就不介紹gcc的安裝了。
[root@node1 simpapp]# tmboot -y 啟動進程
Booting all admin and server processes in /hzh/tuxedo/simpapp/tuxconfig
INFO: Oracle Tuxedo, Version 11.1.1.2.0, 32-bit, Patch Level (none)
Booting admin processes ...
exec BBL -A :
process id=2628 ... Started.
Booting server processes ...
exec simpserv -A :
process id=2629 ... Started.
2 processes started.
[root@node1 simpapp]# ps -ef 查看啟動進程
root 2628 1 0 12:21 pts/2 00:00:00 BBL -C dom=simpapp -g 30002 -i 0
root 2629 1 0 12:21 pts/2 00:00:00 simpserv -C dom=simpapp -g 1 -i
root 2634 2558 0 12:23 pts/2 00:00:00 ps -ef
// 能找到上面幾個進程表面已經啟動成功
驗證：
[root@node1 simpapp]# ./simpcl hello
Returned string is: HELLO
客戶端發送一個小寫的hello ，服務器端將返回一個大寫的HELLO
[root@node1 simpapp]# tmshutdown -y //停止進程
IPC & TCP/IP
通過上面的配置，我們將tuxedo 一個小例子跑起來了，但是目前客戶端與服務器同在一台機子上，同在一個機子上所使用的協議是IPC ，而我試驗的環境是在win 7 下的下的虛擬機上運行centOS ，那么如何在win 7 下發送請求到centOS上呢？
IPC ：inter Process Communication （進程間通訊），適用於同一台機子上進程與進程之間的通訊。IPC 包括共享內存，隊列，信號量等幾種形式。通過IPC的方式通訊效率高。
如果兩個進程分別在不同的機子上想實現通訊，就要走TCP/IP協議。
[root@node1 simpapp]# ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:27:48:F5:9C
inet addr:192.168.0.107 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe48:f59c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:932 errors:0 dropped:0 overruns:0 frame:0
TX packets:693 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:79614 (77.7 KiB) TX bytes:89327 (87.2 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:5895 errors:0 dropped:0 overruns:0 frame:0
TX packets:5895 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9015156 (8.5 MiB) TX bytes:9015156 (8.5 MiB)
結合上面信息再來分析，一台主機上的一個進程要想與另一台主機上的進程實現通訊，先將信息發送到eth0 網卡中，通過網線傳輸到另一台主機的eth0網卡，再由網卡傳給另一個進程。
lo : local Loopback 表示本地環路，lo是一個特殊的網卡，兩個進程之間通訊可以使用IPC協議，如果要使用TCP/IP協議的話就要通過lo這個特殊的網卡進行通訊。
通過上面的分析，我們知道兩個進程間通訊有三種方式。
兩個進程在同一台主機上：
一：通過IPC協議，使兩個進程直接通訊，效率高。
二：通過TCP/IP協議，使用lo特殊網卡時行通訊。
兩個進程在不同的兩個主機上：
三：通過TCP/IP協議，使用eth0物理網卡進行通訊。
配置第二種方式通訊
我們現在使用的是第一種通訊方式，下面我們要將上面的修改的文件重新修改配置，來完成第二種方式通訊。
修改tux.env文件
TUXDIR=/hzh/tuxedo/tuxedo11gR1; export TUXDIR
JAVA_HOME=$TUXDIR/jre; export JAVA_HOME
JVMLIBS=$JAVA_HOME/lib/i386/server:$JAVA_HOME/jre/bin
PATH=$TUXDIR/bin:$JAVA_HOME/bin:$PATH; export PATH
COBCPY=:$TUXDIR/cobinclude; export COBCPY
COBOPT="-C ANS85 -C ALIGN=8 -C NOIBMCOMP -C TRUNC=ANSI -C OSEXT=cbl"; export COBOPT
SHLIB_PATH=$TUXDIR/lib:$JVMLIBS:$SHLIB_PATH; export SHLIB_PATH
LIBPATH=$TUXDIR/lib:$JVMLIBS:$LIBPATH; export LIBPATH
LD_LIBRARY_PATH=$TUXDIR/lib:$JVMLIBS:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
WEBJAVADIR=$TUXDIR/udataobj/webgui/java; export WEBJAVADIR
APPDIR=/hzh/tuxedo/simpapp; export APPDIR
TUXCONFIG=$APPDIR/tuxconfig; export TUXCONFIG
LANG=C; export LANG
WSNADDR=//192.168.0.107:3200; export WSNADDR
修改ubbsimple文件
.......................
*MACHINES
DEFAULT:
APPDIR="/hzh/tuxedo/simpapp"
TUXCONFIG="/hzh/tuxedo/simpapp/tuxconfig"
TUXDIR="/hzh/tuxedo/tuxedo11gR1"
#Example:
# APPDIR="/home/me/simpapp"
# TUXCONFIG="/home/me/simpapp/tuxconfig"
# TUXDIR="/usr/tuxedo"
node1 LMID=simple
MAXWSCLIENTS=5
#Example:
#beatux LMID=simple
*GROUPS
GROUP1
LMID=simple GRPNO=1 OPENINFO=NONE
*SERVERS
DEFAULT:
CLOPT="-A"
simpserv SRVGRP=GROUP1 SRVID=1
WSL SRVGRP=GROUP1 SRVID=10 //增加一個WSL偵聽進程
CLOPT="-A -- -n //192.168.0.107:3200" //IP地址為本機IP，端口號3200可以任意取，與tux.env 文件中的WSNADDR參數保持一致
*SERVICES
TOUPPER
[root@node1 simpapp]# tmloadcf -y ubbsimple // 編譯文件
[root@node1 simpapp]# buildclient -f simpcl.c -o ws -w //重新編譯客戶端，ws 為編譯的可執行程序，-w 參數表示客戶端的編譯是按照TCP/IP方式通訊的。
[root@node1 simpapp]# tmboot -y //啟動進程
[root@node1 simpapp]# ./ws hello
Returned string is: HELLO
分析第二種通訊方式
我們在ubbsimple文件中配置了 WSL 參數
WSL SRVGRP=GROUP1 SRVID=10
CLOPT="-A -- -n //192.168.0.107:3200"
參數指向的IP為本機IP，在tux.env 文件中同樣需要指定本機IP 。
使用tmboot -y 命令啟動進程：
[root@node1 simpapp]# tmboot -y 啟動進程
[root@node1 simpapp]# ps -ef 查看進程
root 3402 1 0 18:03 pts/2 00:00:00 BBL -C dom=simpapp -g 30002 -i 0
root 3403 1 0 18:03 pts/2 00:00:00 simpserv -C dom=simpapp -g 1 -i
root 3404 1 0 18:03 pts/2 00:00:00 WSL -C dom=simpapp -g 1 -i 10 -u
root 3412 2580 0 18:07 pts/2 00:00:00 ps -ef
客戶端向tuxedo服務器發請求，由WSL進程處理，並返回另外一個IP及端口。客戶端拿到IP及端口去訪問真正的WSH進程。那為什么WSH進程為什么沒有啟動呢？ 這是因為WSH進程是在客戶端發送請求后自動生成的。
[root@node1 simpapp]# ./ws hello //向服務器端發送請求
Returned string is: HELLO
[root@node1 simpapp]# ps -ef 查看進程
root 3402 1 0 18:03 pts/2 00:00:00 BBL -C dom=simpapp -g 30002 -i 0
root 3403 1 0 18:03 pts/2 00:00:00 simpserv -C dom=simpapp -g 1 -i
root 3404 1 0 18:03 pts/2 00:00:00 WSL -C dom=simpapp -g 1 -i 10 -u
root 3421 3404 0 18:12 pts/2 00:00:00 WSH -c 11 -i 0 -s 3375121 -p 204
root 3423 2580 0 18:12 pts/2 00:00:00 ps -ef
// 這里已經生成了WSH進程
--------------------------------------------------