1、基于(jy)IPC機制淺析Tuxedo及其應(yīng)用摘 要:本文從底層IPC機制出發(fā),結(jié)合UNIX核心系統(tǒng)參數(shù)和ATMI技術(shù)，借用ipcs觀察Tuxedo所消耗的IPC系統(tǒng)資源狀況，淺析了Tuxedo強大功能背后的工作原理，進一步加深對Tuxedo應(yīng)用和ATMI編程的理解，提出了并解決實際工作中關(guān)鍵問題的思路和步驟。關(guān)鍵詞:進程間通信 共享內(nèi)存 信號量 消息隊列 Tuxedo ATMI一、進程間通信IPC主要工作機制簡介 HYPERLINK /bbs/jishudata/ArticleShow.jsp?Id=14 l top （目錄）進程間通信IPC (Inter-process communica

2、tion)是一個Unix標準通訊機制，提供在同一臺主機不同進程之間可以互相通訊的方法。 由于它是一種底層技術(shù)，因此具備了先天的靈活性。本文所涉及的IPC處理機制有3種：共享內(nèi)存、信號量和消息隊列。1.共享內(nèi)存共享內(nèi)存(Shared Memory)是一片指定的物理內(nèi)存區(qū)域，這個區(qū)域通常是在存放正常程序數(shù)據(jù)區(qū)域的外面, 它允許兩個或多個進程共享一給定的存儲區(qū)，是針對其他通信機制運行效率較低而設(shè)計的。因為數(shù)據(jù)不需要來回復制，更不需要在客戶機和服務(wù)器之間復制，進程可以直接讀寫內(nèi)存，所以是最快的一種進程間通信機制。為了實現(xiàn)更安全通信，它往往與其它通信機制，如信號量結(jié)合使用，來達到進程間的同步及互斥。在T

3、uxedo中，就是利用這個特性，將共享內(nèi)存空間變成一種公告牌，用來公告進程狀態(tài)信息和需要在進程間共享或傳遞的數(shù)據(jù)。2.信號量信號量(Semaphore)為那些訪問相同資源的進程以及同一進程不同線程之間提供一個同步機制。它不是用于傳輸數(shù)據(jù)，而只是簡單地協(xié)調(diào)對共享資源的訪問。可以使用ipcs和ipcrm實現(xiàn)對信號量使用狀態(tài)的查詢和刪除操作。信號量機制中，有一個概念是信號量組，它將相關(guān)信號量創(chuàng)建在同一個信號量組中，這樣既便于邏輯上的清晰理解也便于管理。一個信號量必須屬于一個信號量組，否則不能被系統(tǒng)所使用。信號量和信號量組，存儲于內(nèi)核系統(tǒng)區(qū)域，是隨內(nèi)核持續(xù)的，是不會被系統(tǒng)所自動清理的，所以當進程退出前

4、，需要清理進程生成的那些信號量們。信號量可以包含一個增加或減小的值，用以指出什么資源正被訪問和訪問的次數(shù)。它是一個記數(shù)器，用于控制多進程對共享數(shù)據(jù)的存儲。一旦成功擁有了一個信號量，對它所能做的只有2種：請求、釋放。當執(zhí)行釋放操作時, 系統(tǒng)將把該信號值減1。如果小于0，那就還設(shè)為0。而當執(zhí)行請求操作時，系統(tǒng)將把該信號值加1，如果該值大于設(shè)定的最大值，那么系統(tǒng)將掛起你的處理進程，直到其他進程釋放到小于最大值為止，這樣能夠保證多個進程不會造成互鎖。3.消息隊列消息隊列(MessageQueue)是一個結(jié)構(gòu)化的排序內(nèi)存段表，這個隊列是進程存放或檢索數(shù)據(jù)的地方，是一個消息的鏈表，可以被多個進程所共享，而

5、不管這幾個進程是否具有“親緣”關(guān)系。每個消息隊列都有一個隊列頭，用來描述該消息隊列的大量信息，包括消息隊列鍵值、用戶ID、消息隊列中消息數(shù)目等等，甚至記錄了最近對消息隊列讀寫進程的ID。消息可以看作一個記錄，具有特定的格式以及特定的優(yōu)先級。對消息隊列有寫權(quán)限的進程可以按照一定的規(guī)則添加新消息；對消息隊列有讀權(quán)限的進程則可以從消息隊列中讀走消息。消息隊列與信號量一樣的，是隨內(nèi)核持續(xù)的，只有在內(nèi)核重起或者顯示刪除一個消息隊列時，該消息隊列才會真正被刪除。二、IPC在Tuxedo中的使用 HYPERLINK /bbs/jishudata/ArticleShow.jsp?Id=14 l top （目錄

6、）1. Tuxedo及核心子系統(tǒng)簡介BEA Tuxedo是在企業(yè)、Internet這樣的分布式運算環(huán)境中，開發(fā)和管理三層結(jié)構(gòu)的客戶/服務(wù)器型關(guān)鍵任務(wù)應(yīng)用系統(tǒng)的強有力工具。它具備分布式事務(wù)處理和應(yīng)用通信功能，并提供完善的各種服務(wù)來建立、運行和管理關(guān)鍵任務(wù)應(yīng)用系統(tǒng)。它提供了一個開放的環(huán)境，支持各種各樣的客戶、數(shù)據(jù)庫、網(wǎng)絡(luò)、遺留系統(tǒng)和通訊方式，使得開發(fā)人員能夠利用它建立跨硬件平臺、數(shù)據(jù)庫和操作系統(tǒng)的交互應(yīng)用系統(tǒng)。Tuxedo的應(yīng)用程序是以業(yè)務(wù)邏輯服務(wù)、由這些邏輯服務(wù)組織成的高層服務(wù)器組件和在服務(wù)器結(jié)點環(huán)境中的組件分布為特征的。支持這種虛擬主機環(huán)境的Tuxedo元素，包括配置信息庫和實現(xiàn)運行時應(yīng)用管理

7、的核心子系統(tǒng)。限于篇幅的限制，這里只對核心子系統(tǒng)作簡單介紹。1.1公告牌Tuxedo應(yīng)用配置文件被映射到一個運行時數(shù)據(jù)結(jié)構(gòu):公告牌（BB）。BB 作為一個從配置文件中派生出來的共享信息庫，駐留在每個參與到由配置文件指定的應(yīng)用程序的Tuxedo的服務(wù)器結(jié)點上。BB不僅作為分布式應(yīng)用的名字服務(wù)數(shù)據(jù)庫，提供分布式環(huán)境下的應(yīng)用對象的位置信息，還作為應(yīng)用統(tǒng)計數(shù)據(jù)的運行時倉庫。BB由Tuxedo核心例程（對應(yīng)用開發(fā)者透明）訪問，由核心例程讀/修改BB庫。這個信息庫提供Tuxedo完成動態(tài)客戶/服務(wù)器映射所需的信息，同時也提供完成諸如負載平衡、 安全性和事務(wù)協(xié)調(diào)等功能的信息。1.2 事務(wù)管理器事務(wù)管理器既是

8、Tuxedo 體系結(jié)構(gòu)的中心，也是每個Tuxedo服務(wù)器的核心 ，提供重要的分布式應(yīng)用服務(wù)、命名、 消息路由、 負載平衡、配置管理、事務(wù)管理和安全性。它也包含BB結(jié)構(gòu)，使用維護和訪問BB信息的服務(wù)。換句話說，BB內(nèi)包含有執(zhí)行和管理大規(guī)模的基于組件的應(yīng)用程序所需的所有信息，它將對事務(wù)管理器進程起作用。圖1顯示了事務(wù)管理器的基本操作，客戶請求 到達駐留在服務(wù)器上的客戶代理進程 ，服務(wù)器通過注冊參加到該應(yīng)用中。作為客戶方通訊的一部分，事務(wù)管理器訪問BB，然后選擇服務(wù)器，接著，服務(wù)器消息隊列的地址被返回，客戶方的請求被馬上傳送到合適的隊列等待服務(wù)為它進行處理。圖1： 事務(wù)管理器工作流程示意圖1.3 工

9、作站工作站把Tuxedo ATMI API擴展到客戶應(yīng)用程序中，使得平臺透明化。使用ATMI的客戶端程序，可以訪問在Tuxedo分布式環(huán)境中任何地方的服務(wù)。一個多路網(wǎng)關(guān)進程，稱為工作站處理進程（WSL），駐留在Tuxedo應(yīng)用服務(wù)器上，配合Workstation Handler(WSH)，處理工作站客戶和事務(wù)管理器應(yīng)用服務(wù)之間的通訊。工作站處理進程把來自大量客戶應(yīng)用程序的請求，會聚到Tuxedo事務(wù)管理器，以便完成所管轄的服務(wù)。1.4 服務(wù)器及其隊列Tuxedo提供了一個簡單的可選機制，用于給應(yīng)用請求和回答進行進隊和出隊。 Tuxedo隊列服務(wù)使下列應(yīng)用變得可能：工作流應(yīng)用 提交和完成要求確保

10、完成的事務(wù) 提交時間敏感型請求 與Tuxedo MIB和GUI的集成 出隊請求的事務(wù)控制 利用簡單的服務(wù)鏡向和數(shù)據(jù)鏡向進行軟件容錯2.影響Tuxedo IPC的系統(tǒng)參數(shù)在UNIX系統(tǒng)，Tuxedo大量使用IPC資源，然而通常系統(tǒng)默認的參數(shù)值遠遠低于Tuxedo應(yīng)用程序的要求。因此，在安裝Tuxedo應(yīng)用程序前,必須合理地設(shè)置其參數(shù)值。這不僅決定應(yīng)用程序能否正常操作，還將影響日后投入運行時的性能。以下就是系統(tǒng)V影響Tuxedo IPC資源的可調(diào)整系統(tǒng)參數(shù)。表1. 系統(tǒng)V IPC參數(shù)名字描述取值共享內(nèi)存SHMMAX單個共享內(nèi)存段的最大尺寸（以字節(jié)為單位）越大越好，取決于可分配的系統(tǒng)內(nèi)存SHMSEG

11、一個進程可用的共享內(nèi)存段的最大可用數(shù)目取決于可分配的系統(tǒng)內(nèi)存SHMMNI系統(tǒng)范圍內(nèi)允許的共享內(nèi)存段最多數(shù)目取決于可分配的系統(tǒng)內(nèi)存SHMMIN單個共享內(nèi)存段的最小尺寸（字節(jié)）1信號量SEMMNS系統(tǒng)范圍的最大信號量數(shù)量至少需滿足MAXACCESSERS-MAXWSCLIENTS+13SEMMNI可被創(chuàng)建的信號集的數(shù)目通常等于SEMMNSSEMMSL每套信號集允許的最大信號量數(shù)量通常等于SEMMNS，因為Tuxedo不直接對信號集，但它對每個信號集分配盡可能多的信號量SEMMAP控制映射表里用于管理信號量的記錄數(shù)量SEMMNI+2SEMMNUUndo 結(jié)構(gòu)的數(shù)目Default 30至少SEMMNS

12、SEMUMEUndo 結(jié)構(gòu)中記錄數(shù)量1消息隊列MSGTQL系統(tǒng)核心中能夠存儲的系統(tǒng)消息頭的最大數(shù)量應(yīng)足夠大MSGMNB消息隊列最大尺寸（字節(jié)）至少等于MSGMAX，當消息長度大于75%的MSGMNB時，消息將被存到文件中去，這將大大降低總體性能。MSGMAX每條消息的最大尺寸（字節(jié)）應(yīng)足夠大來處理應(yīng)用程序的請求。MSGSEG系統(tǒng)擁有消息段數(shù)目取決于可分配的系統(tǒng)內(nèi)存MSGSSZ每個消息段的尺寸（字節(jié)）一條消息可使用多個消息段，取決于可分配的系統(tǒng)內(nèi)存MSGMNI最多可被創(chuàng)建的消息隊列數(shù)目至少要大于MAXACCESSERS + 7 +（number of servers with REPLYQ) +

13、（number of MSSQ sets) - （number of servers in MSSQ sets)MSGMAP控制映射表里用于管理消息段的記錄數(shù)量等于MSGSEG在程序開發(fā)的過程中，如果系統(tǒng)參數(shù)無法滿足最小的要求，就會導致種種奇怪的問題。例如：（1）收到來自shmget的類似“Invalid argument” 這樣的錯誤信息，那么很有可能是超過了當前共享內(nèi)存SHMMAX的限制；（2）信號量集的最大數(shù)目SEMMNI以及系統(tǒng)范圍內(nèi)信號量的最大數(shù)目SEMMNS：超過這兩個限制將返回ENOSPC錯誤。在消息隊列參數(shù)中，MSGTQL，MSGMNB，MSGMAX，MSGSEG，MSGSSZ

14、這五個參數(shù)將決定隊列空間、隊列個數(shù)、消息尺寸。從表1中，我們發(fā)現(xiàn)UBBCONFIG 文件中的參數(shù)：MAXACCESSERS，MAXWSCLIENT影響著IPC資源的使用情況。MAXACCESSERS： 在本系統(tǒng)的一個節(jié)點(一臺服務(wù)器)上，同時可以訪問公告板的進程數(shù)。它包括本地客戶端進程、SERVER進程、WSL和WSH，但不包括管理進程如:BBL,DBBL等。MAXWSCLLINET：定義了需要在MAXACCESSERS專為遠程客戶端保留的記錄數(shù)目。這就可以解釋很多初學者遇到的問題，啟動失敗：因為系統(tǒng)默認的值沒有符合最小要求。3.關(guān)于Tuxedo IPC資源的實驗和觀察為加深對IPC資源和Tu

15、xedo的了解，筆者借助UNIX命令ipcs等對多個實驗作出的觀察。研究平臺配置如下：操作系統(tǒng)：HP-UNIX 11i：數(shù)據(jù)庫數(shù)目：Oracle, 3個服務(wù)程序：40個Service數(shù)目：1275種IPCKEY值：34268PERM值：0666客戶端類型：Workstation Client編程接口：ATMI3.1 關(guān)于共享內(nèi)存的實驗devt/tuxedo/appdir ipcs -am |grep tuxedoIPC status from /dev/kmem as of Fri Oct 15 17:46:05 2004Shared Memory:T ID KEY MODE OWNER GR

16、OUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIMEm 12311 0 x000085dc -rw-rw-rw- tuxedo gtux tuxedo gtux 42 2835444 8041 2090 11:26:36 11:29:21 14:03:10m 16408 0 x00000000 -rw- tuxedo gtux tuxedo gtux 2 352 8176 8325 14:04:16 no-entry 14:03:41 devt/tuxedo/appdir ps -efx |egrep 8041|2090tuxe

17、do 8041 1 0 Oct 14 ? 0:04 BBL -C dom=KFX -g 30002 -i 0 -u devt -U /tuxedo/appdir/log/ULOG -m 0-Atuxedo 22733 1362 0 17:22:04 pts/tv 0:00 egrep 8041|2090devt/tuxedo/appdir ps -efx |egrep 8176|8325|grep ?v greptuxedo 8325 8176 0 Oct 14 ? 0:00 WSH -c 11 -d /dev/tcp -i 0 -s 16408 -p 2048 -P 65535tuxedo

18、8176 1 0 Oct 14 ? 0:02 WSL -C dom=KFX -g 8 -i 705 -u devt -U /tuxedo/appdir/log/ULOG -m 0 -e/tuxedo/appdir/log/WSL.err -o /tuxedo/appdir/log/WSL.out -A -r - -d /dev/tcp -n /devt:5035devt/tuxedo/appdir ps -ef |grep tuxedo |grep -v grep |grep 8176tuxedo 8325 8176 0 Oct 14 ? 0:00 WSH -c 11 -d /dev/tcp

19、-i 0 -s 16408 -p 2048 -P 65535tuxedo 8176 1 0 Oct 14 ? 0:02 WSL -C dom=KFX -g 8 -i 705 -u devt -U /tuxedo/ap從上述實驗中，不難觀察到：（1）CPID指出了這兩個共享內(nèi)存的所有者是：公告牌和WSL進程。WSH并不創(chuàng)建共享內(nèi)存。（2）LPID指出了最后一次訪問WSL的共享內(nèi)存段的是WSH。（3）共享內(nèi)存Id不是固定得,每次由系統(tǒng)分配指定。但BB公告牌的共享內(nèi)存的十六進制KEY值x000085dc 轉(zhuǎn)換成十進制，就是UBBCONFIG中設(shè)定的IPCKEY值34268，（4）注意到公告牌和WSL

20、進程的訪問模式是不同的。BB的訪問模式等于與UBBCONFIG中PERM的值0666。3.2關(guān)于信號量的實驗devt/tuxedo/appdir ipcs ?as |grep tuxedo |grep -v grepIPC status from /dev/kmem as of Fri Oct 15 17:46:21 2004T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIMESemaphores:s 60035 0 x000085dc -ra-ra-ra- tuxedo gtux tuxedo gtux 3 17:49:50 1

21、4:03:10s 140036 0 x00000000 -ra-ra-ra- tuxedo gtux tuxedo gtux 816 no-entry 14:03:10從上述實驗中，不難觀察到：（1）有兩個信號集，其中一個KEY值是公告牌的。（2）在兩個信號集內(nèi)，分別容納了3和816個信號量。（3）最后一次對ID 為60035信號集中的信號量的操作時間是17:49:50。另從從創(chuàng)建的時間和訪問模式都一樣來推測，另一個信號集也是屬于BB的。它們的具體作用有待進一步深入研究。3.3關(guān)于消息隊列的實驗3.3.1 實驗1：關(guān)于應(yīng)用程序的隊列devt/tuxedo/appdir ipcs ?aq |gr

22、ep tuxedo |grep -v grepIPC status from /dev/kmem as of Fri Oct 15 18:07:04 2004T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIMEMessage Queues:q 12556 0 x00000000 -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8151 8325 13:54:27 13:54:27 14:04:16q 10523 0 x00

23、0085dc -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8163 8041 16:48:06 16:48:06 14:03:13q 6430 0 x00000000 -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8151 8043 13:54:21 13:54:21 14:03:13q 6431 0 x00000000 -rw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8041 8042 14:03:13 14:03:13 14:03:13q 43

24、95 0 x00000000 -rw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8041 8050 14:03:15 14:03:15 14:03:15q 2563 0 x00000000 -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8151 8162 10:48:07 10:48:07 14:03:36q 6666 0 x00000000 -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8165 8172 14:16:36 14:16:36 14:0

25、3:39q 2571 0 x00000000 -rw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8160 8172 14:16:36 14:16:36 14:03:39q 2643 0 x00000000 -rw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 0 0 no-entry no-entry 14:03:41*共70個隊列，限于篇幅不一一列出從上述實驗中，不難觀察到：（1）對于多服務(wù)器單隊列的服務(wù)器（MSSQ），都有一個隊列用來接收請求，訪問模式為-rw-rw-rw- 。另一個隊列用來回復，訪問模式為

26、-Rrw-rw-rw-。（2）KEY值：只有一個是屬于公告牌的（值為0 x000085dc），其余都為0 x00000000。（3）ipcs告訴我們更多關(guān)于消息隊列的信息：所有者、創(chuàng)建者、創(chuàng)建者組別、消息隊列字節(jié)數(shù)、正在排隊的消息數(shù)、隊列的最大字節(jié)容量、最近一次的發(fā)送者和接收者以及時間和創(chuàng)建時間。（4）另逐個shudown服務(wù)程序，經(jīng)比較發(fā)現(xiàn)：對于每個資源上的事務(wù)管理器，每個進程都有自己獨立的請求隊列，但回復隊列只有一個。3.3.2 實驗2：關(guān)于tmadmin會話的隊列devt/tuxedo/appdir/temp ipcs -aq |grep tuxedo |wc -l70devt/tuxe

27、do/appdir/temp ipcs -aq |grep tuxedo ipcs_q_noclient.txt#在另一個SHELL開了一個tmadmin進程devt/tuxedo/appdir/temp ipcs -aq |grep tuxedo |wc -l71devt/tuxedo/appdir/temp ipcs -aq |grep tuxedo ipcs_q_1client.txtdevt/tuxedo/appdir/temp diff ipcs_q_noclient.txt ipcs_q_1client.txt1c1,2 q 24676 0 x00000000 -rw-rw-rw-

28、 tuxedo gtux tuxedo gtux 0 0 1048560 371 14981 16:11:54 16:11:54 16:11:42 q 18700 0 x000085dc -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 14981 371 16:11:54 16:11:54 20:07:15devt/tuxedo/appdir/temp grep 24676 ipcs_q_noclient.txt |wc -l0devt/tuxedo/appdir/temp ipcs -aq |grep tuxedo |wc -l71#退出tma

29、dmin進程devt/tuxedo/appdir/temp ipcs -aq |grep tuxedo |wc -l70此實驗告訴我們，針對每個新的tmadmin會話，Tuxedo都會為它創(chuàng)建一個新的消息隊列。此實驗中，ID為24676就是為tmadmin會話創(chuàng)建的。3.3.3 實驗3：關(guān)于WSL/WSH的隊列在本地Windows PC，開啟一個遠程客戶端程序后。devt/tuxedo/appdir/temp ipcs -aq |grep tuxedo |wc ?l71devt/tuxedo/appdir/temp tmadmin pcltLMID User Name Client Name

30、Time Status Bgn/Cmmt/Abrt- - - - - -FX tuxedo WSH 0:04:28 IDLE 0/0/0FX tuxedo tmadmin 0:00:01 IDLE 0/0/0 quitdevt/tuxedo/appdir/temp ipcs -aq |grep tuxedo |wc -l71devt/tuxedo/appdir/temp ipcs -aq |grep tuxedo pcs_q_feclient.txtdevt/tuxedo/appdir/temp diff ipcs_q_noclient.txt ipcs_q_feclient.txt1c1,2

31、 q 26724 0 x00000000 -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 414 15288 16:21:27 16:21:27 16:21:08 q 18700 0 x000085dc -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 15133 371 16:16:32 16:16:32 20:07:15此實驗告訴我們，除了WSL本身有自己的回復隊列，針對每個新的WSH，Tuxedo都會為它創(chuàng)建一個新的回復消息隊列。此實驗中，WSH的消息隊列ID為24724。因為在0個遠程客戶端接

32、入之前，WSL是不會自動啟動WSH。在這之后的另一個實驗是將WSL關(guān)閉之后,發(fā)現(xiàn)WSL和WSH的消息隊列同時，跟著進程的關(guān)閉而關(guān)閉。3.4 關(guān)于PERM的實驗上述3個實驗中，UBBCONFIG中*RESOURCES段的PERM值為0666，*SERVERS段的RQPERM和RPPERM均為0666。將*RESOURCES段的PERM改為將PERM 設(shè)為0660后，重新創(chuàng)建TUXCONFIG。devt/tuxedo/appdir/log ipcs -as|grep tuxedos 80035 0 x000085dc -ra-ra- tuxedo gtux tuxedo gtux 3 19:58:

33、13 19:51:10s 180036 0 x00000000 -ra-ra- tuxedo gtux tuxedo gtux 816 no-entry 19:51:10devt/tuxedo/appdir/log ipcs -am|grep tuxedom 16407 0 x000085dc -rw-rw- tuxedo gtux tuxedo gtux 43 2835444 28873 28932 19:51:53 no-entry 19:51:10m 20504 0 x00000000 -rw- tuxedo gtux tuxedo gtux 1 352 28922 28922 19:5

34、1:39 no-entry 19:51:39從此實驗中，觀察到除了*SERVERS段中另有制定訪問模式外，共享內(nèi)存和信號量均使用*RESOURCES中的PERM值。4. 關(guān)于ATMI的理解Tuxedo提供了一個基于C語言的編程接口，即應(yīng)用程序事務(wù)監(jiān)控接口ATMI，這套接口使得創(chuàng)建Tuxedo的客戶程序與在C和C+編程語言中創(chuàng)建其它應(yīng)用程序一樣容易，方便了開發(fā)客戶程序和服務(wù)程序。4.1 ATMI簡介4.1.1 客戶程序的任務(wù)客戶程序一般執(zhí)行如下任務(wù)： 調(diào)用tpchkauth()決定加入一個應(yīng)用程序所需的安全級別。 調(diào)用tpinit()來連接到一個Tuxedo應(yīng)用程序，所需的安全信息作為tpini

35、t()的參數(shù)傳給了應(yīng)用程序； 執(zhí)行服務(wù)請求；調(diào)用tpterm()來斷開和Tuxedo應(yīng)用程序的連接。圖2： 客戶程序的工作流程4.1.2 服務(wù)程序的任務(wù)盡管開發(fā)者使用ATMI編程接口來創(chuàng)建Tuxedo客戶程序和服務(wù)程序，但服務(wù)程序不全部由開發(fā)者來編寫，開發(fā)者只需寫一些稱為服務(wù)的商業(yè)邏輯函數(shù)，然后和Tuxedo的一些二進制程序，聯(lián)合編譯成一個可執(zhí)行的服務(wù)程序。其任務(wù)包括： 在Tuxedo服務(wù)程序啟動時，執(zhí)行tpsvrinit()函數(shù)，可以在里面打開一些如數(shù)據(jù)庫之類的資源供以后使用； 在Tuxedo服務(wù)程序關(guān)閉時，執(zhí)行tpsvrdone()函數(shù)，可以在里面關(guān)閉tpsvrinit()中打開的資料；

36、Tuxedo服務(wù)程序以服務(wù)的形式來響應(yīng)客戶程序的請求，客戶程序不是通過名字來調(diào)用服務(wù)程序的，而是調(diào)用服務(wù)，客戶程序不知道處理它請求的服務(wù)程序的位置；服務(wù)程序調(diào)用tpreturn()函數(shù)來結(jié)束服務(wù)請求，并返回一個緩沖區(qū)，必要時，將它傳給客戶程序；圖3： 服務(wù)程序的工作流程4.1.3 類型緩沖區(qū)在Tuxedo系統(tǒng)中的所有通信過程都是通過類型緩沖區(qū)來完成的，Tuxedo系統(tǒng)提供了大量的類型緩沖區(qū)來供開發(fā)者使用。所有類型緩沖區(qū)都必須通過Tuxedo的tpalloc(), tprealloc(), tpfree()這些ATMI來分配回收，它們都有特定的頭部。4.1.4 通信模式在和客戶端程序的通信過程中

37、，Tuxedo系統(tǒng)提供多達9種的多種通信模式，其中包括基于隊列的通信和基于事務(wù)的通信。4.1.5 事務(wù)要使用事務(wù)，應(yīng)用程序開發(fā)者需要使用如下ATMI函數(shù)： tpbegin()，用于開始一個事務(wù)； tpcommit()，開始一個二階段提交處理； tpabort()，產(chǎn)即終止事務(wù)。在下面的例子中，客戶程序打開了一個事務(wù)，請求了兩個服務(wù)，并且提交了事務(wù)。因為服務(wù)請求是在事務(wù)開始和提交之間完成的，所以兩個服務(wù)的行為都被了事務(wù)記錄。圖4： 事務(wù)流程圖4.2 對ATMI的理解從上面對ATMI的簡介，筆者認為Tuxedo通過ATMI，實質(zhì)上是對IPC資源本身API的再次封裝，從而提供了更高一層的API以建立

38、分布式應(yīng)用組件，包括服務(wù)程序、客戶程序和事務(wù)管理器等。這些組件在執(zhí)行時以消息相互通訊，由Tuxedo的內(nèi)部服務(wù)機制統(tǒng)一管理。這些服務(wù)機制實現(xiàn)了復雜的分布式事務(wù)控制和廣泛的分布式應(yīng)用管理。而在通信過程中，所有的過程都是通過類型緩沖區(qū)來完成的。這實際上就是對消息隊列的操作，從而獲得相應(yīng)的IPC資源。統(tǒng)一定義的類型緩沖區(qū)、更高一層的API，使得它們在跨越不同網(wǎng)絡(luò)、不同協(xié)議、不同CPU構(gòu)架以及不同操作系統(tǒng)之間，得到統(tǒng)一的處理。在加上編譯程序builderserver和builderclient的再次封裝，開發(fā)者在分布式計算環(huán)境中，完全可以有效地避開了異構(gòu)網(wǎng)絡(luò)和異構(gòu)計算機系統(tǒng)帶來的差異，而把精力集中在商

39、業(yè)邏輯的開發(fā)上。通過調(diào)用ATMI的API，開發(fā)基于ATMI的客戶端程序，編寫普通的c程序相當。理解了這些含義，我們可以理直氣壯地說：ATMI已經(jīng)超越了字面上“監(jiān)控接口”的含義，它是一種高度封裝的Tuxedo 應(yīng)用編程接口。它是一個真正的事務(wù)處理和消息傳遞中間件。下圖有助于我們更好地理解整個體系架構(gòu)。圖5： Tuxedo體系架構(gòu)5. Tuxedo與IPC的關(guān)系從上文對IPC資源的介紹中，我們知道了Tuxedo應(yīng)用程序的工作原理。然而這些底層技術(shù)的背后，是離不開復雜的數(shù)據(jù)結(jié)構(gòu)和API。下表是筆者將IPC資源及其數(shù)據(jù)結(jié)構(gòu)和API、核心系統(tǒng)參數(shù)、ATMI函數(shù)，按照IPC資源類別制作的一個列表，以更清楚

40、地將它們的關(guān)系呈現(xiàn)出來。表2. Tuxedo與IPC資源關(guān)系列表IPC資源IPC主要數(shù)據(jù)結(jié)構(gòu)主要IPC API相關(guān)核心參數(shù)相關(guān)的ATMI 函數(shù)共享內(nèi)存shmid_kernel結(jié)構(gòu)；dentry,inode結(jié)構(gòu)shmget：用來獲得共享內(nèi)存區(qū)域的ID，如果不存在指定的共享區(qū)域就創(chuàng)建相應(yīng)的區(qū)域。shmat:把共享內(nèi)存區(qū)域映射到調(diào)用進程的地址空間中去。shmdt:解除進程對共享內(nèi)存區(qū)域的映射。shmctl:實現(xiàn)對共享內(nèi)存區(qū)域的控制操作。SHMMAXSHMSEGSHMMNISHMMIN動態(tài)廣播 HYPERLINK /tuxedo/tux80/atmi/1021630 t _blank tpadvertise HYPERLINK /tuxedo/tux80/atmi/1045888 t _blank tpunadvertise信號量struct ipc_ids sem_ids：系統(tǒng)中記錄信號量的數(shù)據(jù)結(jié)構(gòu)，位于內(nèi)核中，系統(tǒng)中的所有信號量都可以在結(jié)構(gòu)sem_ids中找到訪問入