Burgess 不是漢堡

大多數 Tuxedo 應用都是採用 ATMI（Application-to- Transaction Monitor Interface）來實現運行環境和程式設計介面。

ATMI 的體系結構如下圖所示：

整個結構可以分為外部介面層和 Tuxedo 系統服務層兩個部分。

外部介面層的基礎是ATMI 層，之上是客戶端。

包括 Tuxedo 開發工具、Tuxedo 工作站、協力廠商管理工具和管理控制台。

Tuxedo 系統服務層包括messaging paradigm、MIBs、應用伺服器和管理伺服器。

messaging paradigm指的是 Tuxedo 用戶端與伺服器，以及 Tuxedo 伺服器與伺服器之間傳遞消息的模式。

ATMI 環境支援的通信模型有：

Request/response communication

(Synchronous Messaging)                                                         (Asynchronous)

Conversational communication、

Message queuing communication、

Publish-and-subscribe communication和

Unsolicited notification messaging。

MIBs為其它應用程式管理和配置 Tuxedo 系統提供了一套程式設計介面，通過這套介面可以對 Tuxedo 系統進行動態調整和監控。

應用服務為 ATMI 應用程式提供了資料壓縮、資料依賴路由、資料編碼、資料加密、資料編集、負載均衡、消息優先順序、命名服務和事務管理等基礎服務。

管理服務為 ATMI 應用程式提供了事件管理、安全管理、事務管理、工作站管理、應用程式運營維護管理等基礎服務。

資源管理器（resource manager ，RM）是一種管理持久資料存儲軟體產品。最常見的資源管理器是 DBMS 和訊息佇列。

Tuxedo 的事務系統實現了 X/Open 的 DTP 模型 ，是一個標準的事務監控器（TP Monitor ,TM），

它通過兩階段提交協議（2PC）來協調參與全域事務的資源管理器。

Tuxedo ATMI 的 OLTP 模型

按照服務形式的不同，可以將 C/S 模型分為以資料請求為核心的會話模型和以服務請求為核心的連線交易處理（Online Transaction Processing，OLTP）模型。

在以數據請求為核心的模型中，客戶端給伺服器發送 SQL 指令，伺服器給客戶端返回資料；

在以服務請求為核心的模型中，客戶端給伺服器發送服務請求，伺服器執行業務邏輯並返回給客戶端一個響應。

Tuxedo 系統屬於以服務請求為核心的 OLTP 模型，結構如下圖：

OLTP 最大的特點是併發用戶數量大，突發性強，交易時間短，輸入輸出格式固定。大多數 OLTP 系統都有多個資源管理器來提供資料服務，

因此需要借助事務監控器（TPMonitor，TM）來協調分散式事務。

Tuxedo ATMI 的命名服務

Tuxedo 使用公告版來提供命名服務。

公告版是一塊共用記憶體區域，它保存著服務進程、服務、訊息佇列、事件、運行環境的配置和統計資訊。

為了便於快速訪問，在運行時系統中，他會被複製到 Tuxedo 系統的每個成員節點上。

Tuxedo 客戶端和伺服器可以直接使用名字來調用一個服務，引用一個消息佇列和事件，

ATMI 命名服務會把這些邏輯請求映射到伺服器節點或伺服器進程環境內指定的服務實例上。

Tuxedo ATMI 的訊息緩衝區

在 ATMI 程式設計環境中，客戶端和伺服器之間使用訊息緩衝區來進行資料交換。

由於ATMI 訊息緩衝區具有格式化和自描述的特點，因此又稱為類型緩衝區（type buffers）。

類型緩衝區克服了平臺的差異，為不同系統下的資料表示提供了一個統一的格式，使Tuxedo 跨平臺進行連線交易和資料轉換成為可能，因此它是 ATMI 分散式系統程式設計環境中最基本，最重要的特徵。

Tuxedo 支援的類型緩衝區有：STRING、VIEW、CARRAY、FML、XML、MBSTRING。

Tuxedo ATMI 訊息處理流程

在 ATMI 程式設計環境中，Tuxedo 客戶端和伺服器不直接建立通信連接，而是使用面向無連接的 IPC 訊息佇列來進行資料交換。

Tuxedo 客戶端使用 tpalloc()分配一個請求緩衝區，然後往裡面放入請求消息，再執行 tpcall()去調用一個服務。

客戶端 Tuxedo 系統會根據 tpcall()指定的服務名進行命名映射(name mapping)，找出實現這個服務的後臺進程的 IPC 訊息佇列入口，

然後進行類型判斷(type validation)，檢查請求消息的緩衝區格式是否是符合服務參數的要求。

如果符合，就從 Tuxedo 伺服器的運行系統中讀出服務的優先順序，並把它綁定到請求消息上(service prioritization)。

在資料依賴路由處理中，客戶端 Tuxedo 系統根據路由標準決定把請求消息發送到哪一個後臺進程 IPC 訊息佇列。

如果有多個不屬於同一個 MSSQ 集合的後臺進程可以同時處理這個客戶請求，那麼，客戶端 Tuxedo 系統根據負載均衡(load balancing)的演算法，

來決定把請求放入哪個後臺進程 IPC 訊息佇列。

接下來 Tuxedo 系統還可以對請求消息進行編碼(encode)、壓縮(compress)、事務上下文設置、安全設置等。

最後，客戶端 Tuxedo 把請求消息發送到某個服務進程的 IPC 訊息佇列中。

在 Tuxedo 伺服器端，服務進程從 IPC 訊息佇列中取出來請求消息，經過解壓縮(decompress)、解碼(decode)之後，交給有名服務去處理，

處理結果通過 tpreturn()返回到客戶端的 IPC 訊息佇列中。