TP-Monitor

(株)エクセムコンサルティング本部/APMチームキム・ダウン

概要

TP-Monitor（Transaction Processing Monitor）は、各種プロトコルで動作するセッションとシステムとデータベースとの間の最小処理単位であるトランザクションを監視し、一貫して保持および維持する役割をするトランザクション管理Middlewareです。

 TP モニターは、Web Application Server や Web Transaction Gateway などの Middleware のカテゴリーに属し、金融、公共、通信、製造、流通など一日数千万件のトランザクションが発生する負荷が高いシステムで負荷を調整し、システムの安定性を確保 する役割を担います。

これらのTP-Montitorの役割について学び、さらに代表的なTP-MonitorシステムであるTMAXとTuxedoの機能と構造、違いについても学ぶことにします。

Middleware

クライアント/サーバー環境で分散アプリケーションと分散データを透過的に接続する役割を担うことをMiddlewareと呼びます。

 Middlewareは、異なるコミュニケーションプロトコル、システムアーキテクチャ、オペレーティングシステム、データベース、およびさまざまなアプリケーションサービスをサポートするためにネットワークに沿ってハードウェアに独立して接続するソフトウェアを意味します。

つまり、クライアント/サーバーを物理的に接続してくれるのではなく、アプリケーション内での論理的な接続を意味します。

Middlewareの目標は、「Any-to-Any Operability」として、ファイル交換や共有、トランザクション、RPC（Remote Procedure Call）などのさまざまな方法を使用し、アプリケーションモジュール間の互換性を持ち運用するのに役立ちます。 結論として、Middlewareはアプリケーションプログラムがあらゆる情報システム環境で動作するのを助けます。

 ネットワークの7層のうち5層（セッション層）と6層（プレゼンテーション層）に存在しながら、コンピュータとコンピュータ間の通信を容易かつ安全にできるようにして、これに対する管理を助けるソフトウェアです。

 結局、Middlewareの最大の役割は、クライアントとサーバー間のデータを交換することです。つまり、Middlewareはクライアントとサーバー間（またはコンピュータとコンピュータ間）の通信機能を提供する製品であり、この機能を提供する場合いくら簡単な仕組みでもMiddlewareと呼ぶことができます。したがって、かなり多くのカテゴリのMiddlewareスイートが存在します。この点でTCP / IPもMiddlewareと見なすことができます。

しかし、本稿では現在市販されている商用Middlewareを中心に紹介する予定です。

これらの商用Middlewareには、通信を提供する方法や特化された機能によってDBゲートウェイ、TPモニター、ORBなど3～4種類に分けられます。しかし、通信機能を提供するという表現は誤解を招くことが多くあります。

Middlewareさえあれば通信できるわけではないからです。

ネットワーク通信で議論されるOSIのネットワーク7層モデルを見てみましょう。

 「図」に示すように、最も下にある物理層（Physical Layer）から最上部にあるアプリケーション層（Application Layer）まで、すべての段階を満たさなければ通信がきちんと行われません。このうち、Middlewareは5番目のセッション層（Session Layer）と6番目のプレゼンテーション層（Presentaion Layer）に存在しています。

したがって、Middlewareが提供する通信機能もOSI仕様の5層と6層で提示されている通信仕様によって規定されています。

役割

簡単に言えば、ネットワーク上で駆動するプログラムをより簡単に作成できるようにしてくれます。

つまり、使いやすく管理しやすい中間層を提供することで、ユーザーが望むアプリケーションを「迅速かつ安全に」開発できるようにしてくれるということです。

これらのMiddlewareの特徴は、企業で多くの人が使用する大規模なビジネスプログラムを作成する際に特に重要な役割を果たします。

迅速に書くことができるということは、通信のために簡単な機能を提供して開発生産性を高めるという意味で、安全であるということは、企業の中核業務が問題なく回るように支援するということです。

実際、ネットワーク上で働く通信プログラムを作成すること自体はそれほど難しいことではありませんが、多くのユーザーが汎用的に使用できる「安全な」通信プログラムを作成することは決して簡単ではないのです。

ネットワーク上では予測不可能な状況が起こる可能性が常に存在するため、これに対する処理があらかじめなされてこそ、安全なプログラムと言えます。

特に企業で使用されるプログラムは大部分企業競争力と直結するため、業務プログラムが誤動作を起こす場合には、業務上においてかなりの被害を招くことになります。

だからといって間違いやエラーを完全に防ぐことはできませんが、これらのダメージを最小限に抑え、間違った部分をすばやく見つけて修正できるようにサポートしてくれるのがMiddlewareです。

また、企業の業務システムには、その業務を管理する管理者がいるため、これらの管理者が担当している業務が問題なく運営されるためには、動作状態を監視できる監視機能も必要になります。 Middlewareには、このような管理者のニーズに対応できる機能も付属しています。

結論として、Middlewareはアプリケーションの基盤を提供するもので、Middleware上で書かれたプログラムはより簡単で効果的に通信できる機能を持ち、管理や監視もはるかに容易になります。

Middlewareの種類

DB Middleware

DB MiddlewareはOracleやインフォミックスなどのDBに直接接続してSQLを使用できるようにするプロダクトのことです。 DB Middlewareは他のMiddlewareとは異なり、2層のクライアントサーバー（CS）構造で使用されるという特徴を持ち、代表的な製品としてはOracle SQLネットなどが挙げられます。 特にDB Middlewareの場合、DB企業ごとに専用技術を採用しており、互換問題が発生することを解決するために出てきた標準技術がオープン型DB接続(ODBC)になります。 DB Middlewareは2層のCSプログラムの主流を占めていますが、最近、コンピューティング環境が3層構造に移行するにつれて徐々に押し出される傾向にあります。

 リモートプロシージャコール(RPC:Remote Procedure Call)

ベースのMiddleware RPCとは、ネットワーク上の他のコンピュータ上のプログラムを実行させる作業を指します。 最近では一般的にRPC機能が運用体系（OS）に含まれて提供されることが多いです。

 したがって、RPCベースのMiddlewareファミリは、OSが提供するRPC機能をより使いやすくするのに役立ちます。

RPCは、コンピュータ間通信において最も単純な形態であるだけに、単純な形態のプログラム制作には最も簡単で楽に使用することができます。

 しかし、複雑な形態の環境のための機能を実装するには力不足です。 これらの製品には、インプライズとして買収されたOECのエンテラが代表製品です。

Message 指向 Middleware (MOM:Message-Oriented Middleware)

RPCが同期（Syncronous：要求を送信した後に応答があるまで待つことを意味）型の特徴を

装備されている一方、MOMは非同期（Asyncronous：応答があるまで待たずに後で結果を確認）的という特徴を持っています。

 MOMは通常、メッセージをキューと呼ばれる転送中継所に入れて処理し、キューによるメッセージ管理機能を提供します。

したがって、即時応答を望む場合ではなく、やや遅く安定した応答を必要とする場合に多く使用されます。 代表的な製品としてはIBM MQシリーズがあります。

 トランザクション処理 (TP:Transaction Processing) モニター

TP モニターは最も代表的な Middleware で、主にユーザーが多く、安定的ながらも即時処理

が必要な業務プログラムの開発に多く使われます。

 限られたコンピュータのリソースをより多くのユーザーが使用できるように効率的な管理と安定した運営を支援し、運用状態監視機能などを提供します。

主に銀行の窓口業務プログラム作成に多く使われ、メインフレーム領域でIBM「CICS」や「IMS」、UNIXおよびWindows NT領域ではBEAのタキシードとトップエンドなどがあります。

ORB（Object Request Brokers）ベースのMiddleware

ORB Middlewareは現在最も注目されているオブジェクトベースのMiddlewareです。

複数のコンピュータに分散されたプログラムとデータをそれぞれの独立した仮想オブジェクトのように便利に使用する方法を提供することがORB Middlewareの究極の目標です。

 Middleware領域の中で理論上で一番先に立っており、それだけ競争も最も激しい部分だ。 標準問題、全社的な規模の適用などでまだ不十分な部分も多いが、これを解決するためにMS「DCOM」、OMGグループの「コルバ（CORBA）」など標準技術が出ています。

アイオナ社の「オービックス」、BEAシステムズの「M3」などが代表的です。

TP-Monitor

当初、ほとんどの業務システムはメインフレームベースの集中型環境で構成されていました。

 中央集中型環境は、コストや管理上のいくつかの欠点を表し始めます。

この集中型環境の問題を補うために大豆が開放型分散システムです。

 しかしながら、開放型分散システムもシステムの運用または管理上の他の問題を示しました。

 これらの問題を解決するために導入されたソフトウェアがMiddlewareです。

 Middlewareのうち、TP-Monitorは、プロトコルで動作するセッションとシステムとデータベースの間の最小処理単位であるトランザクションを監視し、一貫して保存および維持する役割を果たすトランザクション管理Middlewareです。

以下はTP-Monitorの主な機能です。

l アプリケーション開発が容易です。 複雑な業務プロセスを開発する際、データ中心から機能中心に分散して開発します。 既存のメインフレーム環境は、ビジネスロジックとデータ処理ロジックが混在して開発されました。

したがって、メインフレーム環境でのアプリケーションの開発はかなり難しものでした。

 ただし、TP-Montiorを使用すると、Middlewareはビジネスロジックを実装し、クライアントプログラムはユーザーに提供するモジュールを実装するだけです。

 そして、データベースサーバープログラムは、データ管理の機能を実装するだけです。 この機能の分離はアプリケーションの開発を容易にします。

・効率的なアプリケーション管理が簡単です。 分散された各業務システムをTP-Monitorを介して管理することで、各アプリケーションを効率的に管理できます。

・異機種DBMSリソース管理が容易です。 DBMSのトランザクションを統合管理することで、異機種間データベース間のリソース管理が可能です。

・負荷調整が容易です。 最適なリソース使用を管理するので、負荷を分散し、分散トランザクションをサポートします。

・実行速度と信頼性が高い。 少ないサーバーリソースで多数のクライアントを管理し、DBMSのオーバーヘッドを減らし、応答時間を向上させます。

TMAX

Tmaxは、Transaction Maximizationの略で、トランザクション処理の最大化を意味します。 Tmaxはシステムの分散環境で異機種コンピュータ間のトランザクション処理を完全に保証しながら負荷を分散させ、エラー発生時に適切な措置を担当するTP-Monitorです。

トランザクションの特性をサポートしながら、ユーザーに最適な開発環境を提供し、クライアント/サーバー環境で最適なソリューションを提供し、パフォーマンスの向上だけでなく、すべての障害に完全に対処します。

 Tmaxは、分散トランザクション処理の国際標準であるX/Open Distributed Transaction Processing（DTP）モデルに準拠し、国際標準機構であるOSI（Open Systems Interconnection group）のDTPサービスの機能的分散と機能コンポーネント間のAPIとシステムインタフェースの定義に従って開発されます。

また、分散環境における異機種間の透明な業務処理およびOLTP(On-Line Transaction Processing)をサポートし、トランザクション処理のACID(Atomic, Consistent, Isolated, Durable: transaction properties)特性を満足させます。

Tmaxは、透明な業務処理を通じてパフォーマンスを最大化し、重要度の高い期間計業務を完全に処理し、開発者とシステム管理者に最適化されたコンピューティング環境を提供します。また、金融、公共、通信、製造、流通など、全産業分野で一日数千万件のトランザクションが発生する重要度の高いシステムで負荷を調整し、障害発生を防止して顧客システムの安定性を確保します。 Tmaxは、Large-scale OLTPアプリケーション開発や、航空およびホテル、病院、防衛分野や銀行オンライン業務やクレジットカード承認業務、顧客および販売管理業務など、さまざまな事業分野や業務で使用されます。

Tmax構造

• APシステムを構成しながら、Middleware製品をたくさん選択します。
   Tmax製品を使用しながら、APプログラムに加えて内部プロセスと管理命令について多くのことがわかります。
   Tmaxには、内部的に7つの運用プロセス（TMM、TMS、CLL、CLH、RQS、GW、CAS）と4つの管理命令（tmadmin、racd、tmboot、tmdown）があります。
   これらの中で、CLHはトランザクション量が大幅に増加するにつれてメモリに大きな影響を与えます。
• TMM(Tmax Manager)

・Tmaxシステムを運営管理するコアプロセスとして、Tmaxシステムのすべての共有情報とCLL、CLH、TMS、およびAP（Application Program）サーバープロセスを管理します。

---

– Note

・ 共有メモリ（Shared Memory）割り当て：設定した環境情報をcfl命令でコンパイルしたバイナリは、エンジンが起動する時点でTMMプロセスが共有メモリにロードします。 TMMはロードされた運用情報を使用してシステムを運営します。

– プロセス管理：TMMは、すべてのシステムの運営と終了の主体となります。

– ログ管理：Tmaxで発生するシステムログ（slog）とユーザーログ（ulog）を管理します。

---

CLL (Client Listener)

CLLは、クライアントとTmaxの間の接続を管理するリスナープロセスです。 クライアントが初めてTmaxに接続するときは、CLLと接続して通信が行われますが、サービス要求がある場合、内部的にCLHと接続され、すべてのサービス処理が行われます。

CLH(Client Handler)

クライアントマネージャとも呼ばれ、実質的にクライアントとサーバの業務処理プロセス間を中継するプロセスです。 CLHは、業務処理プロセスと他のゲートウェイ、RQプロセス、TMAXプロセスとの接続を確立し、それらとの通信を通じてすべての実際のデータの流れを管理します。 つまり、クライアントのサービス要求を受けてそれに対応する業務を処理し、その結果を受け取り、再びクライアントに返します。

TMM(Tmax Manager)

Tmaxシステムを運営管理するコアプロセスとして、Tmaxシステムのすべての共有情報とCLL、CLH、TMS、およびAP（Application Program）サーバープロセスを管理します。

TMS(Transaction Management Server)

データベース管理および分散トランザクション処理を担当するプロセスとして、当該データベースのライブラリを利用して作成される。 Tmaxシステムの運用に不可欠なTMM、CLL、CLHプロセスとは異なり、TMSはDBMSに関連する作業を行うTmaxシステムでのみ動作します。

RQS(Reliable Queue Server)

Tmax システムのディスクキューを管理するプロセスです。 通常、データはメモリに保存され処理されるため、システムが故障した場合にメモリ内のデータは消去されます。 重要なサービスを実行する際にデータの信頼性を高めるために、Tmaxシステムが提供するRQSは、サービス要求の前後のデータをディスクに保存し、システムが再起動された後に障害の前に保存されたデータを再処理できるようにします。サービスの実行速度を遅くすることができるため、Tmaxシステムの起動時にデフォルトでは動作しません。 ユーザーのニーズに応じて環境ファイルで定義されたシステムでのみ動作するようになります。

GW(Gateway)

マルチドメインでシステムを構築した場合、ドメイン間の通信を担当するプロセスで、Tmaxシステム間にはもちろん、TCP/IP、SNA/LU0、SNA/LU6、X.25など、さまざまなシステムとの連動が可能です。 実際に実行されるプロセス名は、ユーザーが環境ファイルに定義することによって異なり、ゲートウェイの種類によって特別な設定をさらに必要とする場合もあります。 このプロセスもTmaxシステムで常にデフォルトで動作するプロセスではなく、環境ファイルにGATEWAYが定義されているシステムでのみ動作します。

CAS (Client Authentication Server)

セキュリティが必要なTmaxシステムを運用している場合に使用されるプロセスは、ステップ1と2のセキュリティを担当し、ユーザーの身元を確認するのに役立ちます。

tmadmin (Tmas Administration)

tmadmin は、Tmax が提供するアドミンツールで、運用中の Tmax システムの環境を確認したり動的に変更したりする機能を提供し、現在のサーバープロセスの動作状態と統計情報、サービスやキューの状態情報を確認できます。

Racd (Remote Access Control Daemon)

複数のノードを 1 つのドメインで Tmax システムを構築した場合、あるノードで別のシステムを管理できるように各ノードにあらかじめ起動するデーモンプロセスです。 racd を使用して、ドメイン内の 1 つのノードで tmadmin を介してふるいノードを監視し、ファイルをコピーする必要なく、1 つの環境ファイルをすべてのノードに適用できます。

Tmboot (Tmax System Boot)

tmbootは、環境ファイルで定義されている内容に従ってTmaxシステムを初期化して起動します。 最も一般的には、Tmaxシステムプロセス（TMM、CLL、CLH）が最初に起動され、その後追加の環境のためのRQ、TMS、GWプロセスが起動され、最後に開発されたサーバープロセスが起動されます。 tmbootはさまざまなオプションを提供し、さまざまな方法でTmaxシステムを起動できます。

Tmdown (Tmax System Down)

tmdownは、環境ファイルの内容に基づいてtmbootで起動されたシステムを終了させる命令です。 終了順序はtmbootとは逆に、最初にすべてのアプリケーションサーバープロセスを終了した後Tmaxシステム管理プロセスを終了します。

Tmax機能

以下はTmaxの主な機能の説明です。

プロセス管理

Tmaxは、3tierベースのクライアント/サーバー環境を提供し、クライアントごとに生成されるサーバーの業務処理プロセス数を調整し、システムを最適な環境として活用できるように管理します。

トランザクション管理

クライアント分散トランザクションが処理されると、2フェーズコミットをサポートしてデータの整合性を保証し、いくつかの簡単な関数（tx_begin、tx_commit、tx_rollbackなど）を提供してグローバルトランザクションを容易にします。

また、マルチスレッド方式のトランザクションマネージャを提供し、少ないリソースに対して高い効率性を提供し、動的ロギングでエラーが発生した場合に迅速に対応するため、Recovery/Rollbackによる安定性を確保します。

 すべてのトランザクションは一元管理されているため、トランザクションのスケジューリングや管理が簡単です。

負荷調整

TmaxはSLM、DDR、DLM方式で負荷調整機能を提供し、システム全体のスループットを向上させ、処理時間を短縮します。

障害対策

ハードウェア障害が発生した場合、Load Balancingによる障害対策とサービスバックアップによる正常な運用が可能です。

サーバープロセスがダウンしているソフトウェア障害が発生した場合、プロセスは再起動されるため、中断のないサービスが提供されます。

便利なAPIと多様な通信方式をサポート

同期通信(Synchronous)、非同期通信(Asynchronous)、対話型通信(Conversational)、要求再要求(Request Forwarding)、アラーム通知(Notify)、メッセージ同時配信(Broadcasting)などの多様な通信方式をサポートし、これに便利なAPIを提供します。

ウェブとの連動

セキュリティがクライアント/サーバー環境とWeb環境をJava Applet/Servlet、PHPなどを通じて連動することで、迅速な応答時間を確保し、システム性能を向上させることができます。 Tmaxはサービス連携を容易にするためにWebTを提供します。

---

– Note

• SLM(system Load Management) : 定義された負荷率で分散処理する方法
• DDR(Data Dependent Routing) : データ値に応じた分散処理方法
• DLM(Dynamic Load Management) : 負荷率に応じて動的に処理グループを選択する方法

---

Tuxedo

Tuxedoの機能と構造

分散トランザクション処理

実質的に無制限の拡張が可能であるため、ピーク時のトランザクションボリュームが効率的に管理され、ビジネスの俊敏性が向上し、IT企業はビジネス要件とスループットの変更に迅速に対応できます。 Oracle Tuxedoは、アクセスプロトコルに関係なく、複数のデータベースでトランザクションを最適化し、すべての関連リソースのデータ整合性を維持します。

システムは、トランザクションに関連するすべての要素を追跡し、拡張アドレッシング（TXA）2フェーズコミットプロトコルを監視し、すべてのトランザクションコミットとロールバックが正しく処理されるようにします。

Oracle TSAM

Oracle Tuxedo System and Applications Monitor（TSAM）は、エンドツーエンドのトランザクションとサービスモニタリング用に設計されており、これを使用して応答時間のサービスレベルアグリーメント（SLA）を設定、監視し、使用しているアプリケーションサービスのパフォーマンスと動作を確認し、Oracle Tuxedoインフラストラクチャのすべてのコンポーネントの活用メトリクスを介した容量計画を改善することができます。 Oracle TSAMを使用して使用中のアプリケーション・リクエスト、サービス・アクティビティ、XAトランザクションおよびOracle Tuxedoサーバーのスループットなどを監視できます。ユーザーは、アプリケーション要求とサービスの実行時間とプロセス間の通信キューに設定されたメッセージの数、およびOracle Tuxedoドメイン、サーバー、ゲートウェイ、およびその他のコンポーネントの状態に関する警告を設定および監視できます。 Oracle TSAMアラートは、Oracle Tuxedoイベント・サーバーでイベントをトリガーし、これによりカスタム・サービスとアラートを関連付けることができます。さらに、ユーザはサービス要求ツリー上のデータを介してサービス性能、システム性能、および特定のアプリケーションパターンに関する統計を問い合わせることができます。

リソース管理

Oracle Tuxedoを使用すると、リソースの使用を管理し、指定されたアプリケーション・インスタンスで実行されるすべてのアクティビティを実行するのに十分な容量があることを確認でき、リクエストが利用可能なネットワーク資産に動的にルーティングされてトランザクションを正常に実行できるようにサポートできます。

 企業は強力な統合機能で既存の技術投資を活用してリソースの使用を最大化することができます。

TP-Monitor比較（TmaxとTuxedo）

TMAXとTUXEDOは、基本的にOSIのTP規格とXopenのDTP規格に準拠したMiddlewareです。 どちらも標準に準拠して作成されたMiddlewareであり、両方のM / Wの基本的なスケルトン、API名、またはコンポーネントはほぼ似ています。

 特にAPIの名前はほとんどほとんど同じで、名前が違ってもTMAX側ではTUXEDOのAPIと同じ名前のAPIが追加的にありますので、プログラム開発者レベルではほとんど何の心配もなくプログラムを開発することができます。

しかし、いくつかの部分に入るとその違いが現れます。

特に、運営者やシステム管理者の立場から見れば差がかなり大きいと見ることができます。 TUXEDOは、システム操作の重要な手段として、共有メモリ、セマフォ、メッセージキューなどのIPCリソースを使用します。 また、domain内の各nodeを制御

する方法として master node を設定し、ここで全体 node に関する情報を管理するようになります。

 そのため、マルチノードの場合を見るとTUXEDOとTMAXのブート時間が違いがかなり多く出るのがわかります。 理由は、TUXEDOは、プロセスが駆動される時点でシステムから各IPCリソースが割り当てられるロジックを実行するためであり、これは非常に重要です。 しかし、TMAXは少し違います。 TMAXは、マルチノードであっても、すべてのノードが論理的に平等な位置で動作します。

つまり、どのNodeでもadminを実行できることを意味します。これは、マスターノードが急にダウンするとシステム上の混乱を招くTUXEDOとはまったく異なる条件です。また、システム資源の側面も異なります。

もちろん、TMAXもTMMの場合はshared memoryを使用し、server APにrequestが渡されるときはmessage queueを使用するのですが、基本的な通信はstream pipeで行われます。これは、処理速度が速くなることを意味したり、またシステムリソースを少なく消費することを意味したりします。実際、TUXEDOをインストールするためにはSHMMAXをはじめとするいくつかのシステムパラメータが規格に合うかを調べてこれを調整しなければならないのですが、概ねnfiles以外の他のパラメータに手を加えることがなく、それだけエンジンが軽いということです。構築または運用中のシステムが1つの業務に対するbackup nodeを持っているかどうかという点がTUXEDOとTMAXの違いをもたらすことができます。

TUXEDOでやや不便なhot-stand by概念のAP設定がTMAXではcousinというモードで非常に簡単に実装されるという特徴があります。これは非常に便利な特性になるでしょう。しかし、かなりの数のサイトは事実上backup nodeがないようにするので、この便利な特性を使う機会をつかむことは容易ではないです。

もし、事実上backupがなくて障害が発生ときには「30分以内の復旧」などの原則を持って運用中ならば、backup nodeを構成してクラスタリング時間に障害のある装備をturn off/turn onさせるのが良いだろうからです。

C/S環境でのTuxedoの使用例

クライアント（主にPC）/サーバー（主にUNIX）構造の分散システム環境（↔Mainframe、端末構造の中央集中型環境）でクライアント数が多くなるにつれて、次のような問題点が生じます。 つまり、より多くの user license を持つ DB を使用する必要があるため、DB 構築コストが高く、 process が多くなるためメモリをより多く必要とし、ネットワーク Traffic 増加するにつれて Transaction 速度が大きく低下します。

 上記の規模の大きな分散システムの問題を解決するために、従来の2段階

システム（クライアント – サーバー）からMiddlewareを導入した3段階のシステム（クライアント – Middleware – サーバー）を構成します。

Middlewareは広い意味でODBCのようなデータベースMiddlewareも含むが、一般的に使用するMiddlewareはOLTP Middleware（OLTP：On Line Transaction Processing。これを一般的にTP Monitorと呼ぶ）を指します。

 Middlewareの構成を見ると、クライアントに配置されたり、サーバーに配置されたり、別のホストに配置されたりすることがあります。

 Tuxedo のような TP モニターを使用した場合の利点を一例として、Middleware がない場合、1000 個の process 管理を 50 個程度の process 管理に減らすことができ、同時ユーザー数を減らすため、DB ライセンスを減らし、メモリーが少なく使用され、 30％程度のシステムコスト削減が可能です。

参考文献
http://blog.daum.net/mybbok/5288610 http://blog.naver.com/PostView.nhn?blogId=u3478&logNo=60153867482

TMAX技術文書

---