Oracle Tuxedoシステムの管理およびサーバー・プロセス
次の項では、Oracle Tuxedoシステム上に構築されたATMIアプリケーションのインフラストラクチャを連携して構成する、Oracle Tuxedoコア・システムの管理およびサーバー・プロセスについて説明します。
Oracle Tuxedo ATMIのインフラストラクチャ
次のカテゴリのOracle Tuxedoシステム・プロセスが、アプリケーション・サービス・リクエストの効率的なルーティング、ディスパッチおよび管理、アプリケーション・キュー、そしてATMIアプリケーションのイベント・ポスティングと通知のためのインフラストラクチャを構成します。
•
|
Oracle Tuxedoワークステーション・サーバー・プロセス
|
•
|
Oracle Tuxedoトランザクション管理サーバー・プロセス
|
•
|
Oracle Tuxedoメッセージ・キューイング・サーバー・プロセス
|
•
|
Oracle Tuxedoパブリッシュ・アンド・サブスクライブ・サーバー・プロセス
|
•
|
Oracle Tuxedo Domains (マルチドメイン)サーバー・プロセス
|
Oracle Tuxedoシステム・プロセスのこれらのカテゴリについて詳しく説明する前に、Oracle Tuxedoの次の重要な用語および概念について説明します。
Oracle Tuxedoドメインとは、1つのTuxedo構成ファイルから1単位として管理されるTuxedoシステム・プロセス、クライアント・プロセスおよびサーバー・プロセスのセットであり、Oracle Tuxedoアプリケーションとも呼ばれます。Oracle Tuxedoドメインは、多数のシステム・プロセス、1つ以上のアプリケーション・クライアント・プロセス、1つ以上のアプリケーション・サーバー・プロセスおよびネットワークで接続された1つ以上のコンピュータ・マシンで構成されます。
次の図は、Oracle Tuxedoドメインの全体像を示しています。
Oracle Tuxedoの用語において
ドメインは
アプリケーション(ビジネス・アプリケーション)と同義であり、Oracle Tuxedoのユーザー・ドキュメント全体にわたってこの2つの語は同義語として使用されています。現在Oracle Tuxedoで稼働しているビジネス・アプリケーションの例としては、航空会社やホテルの予約システム、クレジット認可システム、証券委託売買、ATMなどがあります。
Oracle Tuxedoクライアント/サーバー・アプリケーションのクライアント側で実行されるアプリケーション・プロセスは通常、
アプリケーション・クライアントあるいは単に
クライアントと呼ばれます。Oracle Tuxedoクライアント/サーバー・アプリケーションのサーバー側で実行されるアプリケーション・プロセスは通常、
アプリケーション・サーバーと呼ばれます。
注意:
|
ドメインまたは アプリケーションという語は通常、Oracle Tuxedoクライアント/サーバー・アプリケーションのサーバー側ソフトウェアを意味します。
|
各Oracle Tuxedoドメインは、構成ファイルによって制御され、インストール時の設定に基づくパラメータが定義されています。テキスト形式の構成ファイルは
UBBCONFIGと呼ばれますが、そのファイルの内容が
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のリファレンス・ページ
UBBCONFIG(5)で説明されている形式に準拠している場合にかぎり、構成ファイルに任意の名前を付けることができます。通常の構成ファイル名は文字列
ubbで始め、その後に簡略的な文字列を追加します(たとえば、
simpleを追加して
ubbsimpleというファイル名にします)。
Oracle Tuxedoドメインの
UBBCONFIGファイルには、アプリケーションを起動するために必要なすべての情報、たとえばリソース、マシン、グループ、サーバー、使用可能なサービスなどのリストが含まれています。9つのセクションで構成され、そのうちの5つのセクション、
RESOURCES、
MACHINES、
GROUPS、
SERVERSおよび
SERVICESはすべての構成に必要です。
UBBCONFIGファイルのバイナリ・バージョンは、
TUXCONFIGと呼ばれます。
UBBCONFIGと同様に、
TUXCONFIGファイルにも任意の名前を付けることができますが、実際の名前は
TUXCONFIG環境変数で指定されているデバイス・ファイル名またはシステム・ファイル名になります。
Oracle Tuxedoドメインのマスター・マシン(あるいはマスター・ノード)は、ドメインの
UBBCONFIGファイルが格納されているサーバー・マシンであり、
UBBCONFIGファイルの
RESOURCESセクションでマスター・マシンとして指定されています。Oracle Tuxedoドメイン内の1つ以上のサーバー・マシンの起動、停止および管理は、このマスター・マシンを介して行います。
Oracle Tuxedoドメインのマスター・マシンには、
TUXCONFIGファイルのマスター・コピーも格納されています。マスター・マシンでTuxedoシステムが起動されるたびに、
TUXCONFIGファイルのコピーがOracle Tuxedoドメイン内の他のすべてのサーバー・マシン(
非マスター・マシン)に伝播されます。
複数のマシンからなるドメインで異なるリリースのOracle Tuxedoシステム・ソフトウェアを実行する場合、マスター・マシンがドメイン内の最新のリリースのOracle Tuxedoシステム・ソフトウェアを実行する必要があります。
Oracle Tuxedo TUXCONFIG環境変数
TUXCONFIG環境変数は、
tmloadcf(1)コマンドによってバイナリ・ファイル
TUXCONFIGがロードされるマスター・マシン上の場所を定義します。この環境変数は、
TUXCONFIGがロードさるデバイスまたはシステム・ファイルの名前で終わる絶対パス名に設定する必要があります。
TUXCONFIGパス名の値は、
UBBCONFIGファイルの
MACHINESセクションで指定されます。これは、マスター・マシン
およびOracle Tuxedoドメイン内の他のすべてのサーバー・マシンに対して指定されます。システム起動時にバイナリ
TUXCONFIGファイルのコピーが非マスター・マシンに伝播されると、
TUXCONFIGパス名の値に基づいて、コピーが非マスター・マシンに格納されます。
TUXDIR環境変数は、マスター・マシンのOracle Tuxedoシステム・ソフトウェアのインストール・ディレクトリを定義します。この環境変数は、インストール・ディレクトリの名前で終わる絶対パス名に設定する必要があります。
TUXDIRパス名の値は、
UBBCONFIGファイルの
MACHINESセクションで指定されます。これは、マスター・マシン
およびOracle Tuxedoドメイン内の他のすべてのサーバー・マシンに対して指定されます。
Oracle Tuxedoシステムは、
TUXCONFIGファイルを使用して、Oracle Tuxedoドメイン内の各サーバー・マシンに
掲示板(BB)を設定します。Oracle Tuxedoサーバー・プロセスは、アクティブになったときに自身のサービスの名前を掲示板で通知します。掲示板の一部の情報はグローバルで、Oracle Tuxedoドメイン内のすべてのサーバーでレプリケートされます(特定のサービスを提供するすべてのサーバーの名前と場所など)。また、ローカルな情報(ローカル・サーバーのリクエスト・キューで現在待機しているクライアント・リクエストの実際の数やタイプなど)は、ローカルな掲示板にのみ表示されます。
掲示板は、Oracle Tuxedoドメイン内部での位置とネームスペースの透過性を実現します。場所の透過性とは、Oracle Tuxedoのクライアント・プロセスおよびサーバー・プロセスがOracle Tuxedoドメイン内のリソースの場所を認識する必要がないことを示します。ネームスペースの透過性とは、Oracle Tuxedoクライアント・プロセスとサーバー・プロセスが同じ命名規則(およびネームスペース)を使用してOracle Tuxedoドメイン内のリソースを検索できることを示します。
Oracle Tuxedo管理プロセスでは、次のような分散アプリケーションの管理タスクのほとんどが自動的に行われます。
ここでは、単一マシン構成または複数マシン構成のOracle Tuxedoアプリケーション(ドメイン)で掲示板を設定および管理する管理プロセスを中心に説明します。
•
|
単一マシン構成のアプリケーション: 1つ以上のローカル・アプリケーション・クライアントまたはリモート・アプリケーション・クライアントが、同じマシン上に存在し1つのOracle Tuxedoドメインに属する1つ以上のアプリケーション・サーバーと通信します。
|
•
|
複数マシン構成のアプリケーション: 1つ以上のローカル・アプリケーション・クライアントまたはリモート・アプリケーション・クライアントが、複数のマシン上に存在して1つのOracle Tuxedoドメインに属する1つ以上のアプリケーション・サーバーと通信します。Oracle Tuxedo Bridgeプロセスによって、サーバー・マシン間でサービス・リクエストが送受信され、ローカルに実行されているシステム・プロセスやアプリケーション・サーバー・プロセスにルーティングされます。
|
掲示板(BB)は、Oracle Tuxedoアプリケーションのすべてのアプリケーション構成情報および動的処理情報が実行時に格納されるメモリー・セグメントです。掲示板の機能は次のとおりです。
•
|
サービス・リクエストを特定のサーバーに割り当てます。サービスがコールされると、掲示板は、リクエストされたサービスを提供するサービスをルックアップします。この情報およびデータ依存型ルーティング基準に基づいて、掲示板はリクエスト・データを有効なサーバーのリクエスト・キューに配置します。
|
•
|
アプリケーションの 状態に関する動的な情報(特定のサーバーのキューで待機しているリクエストの数や、処理が完了したリクエストの数など)を管理します。
|
•
|
サーバーの場所の透過性を実現することにより、デプロイメントに依存しないアプリケーション開発を可能にします。このため、開発とデプロイメントのコストを最小限に抑えることができます。
|
•
|
サービス名の別名をサポートすることにより、同じサービスに複数の名前を割り当てることが可能になります。この機能は、ゲートウェイなどのインタプリタを構成する場合に便利です。
|
Oracle Tuxedoアプリケーション内のそれぞれのサーバー・マシンに掲示板があります。
Bulletin Board Liaisonの役割とは
Bulletin Board Liaison (BBL)は、Oracle Tuxedoアプリケーション内の各サーバー・マシン上で実行されるOracle Tuxedo管理プロセスであり、ローカルな掲示板への変更を調整し、ローカル・マシンでアクティブになっているソフトウェア・プログラムの健全性を検証します。Oracle Tuxedoドメイン内の各サーバー・マシン(
マスター・マシンを含む)で実行されるBBLは1つのみです。
Distinguished Bulletin Board Liaison (DBBL)とは
Distinguished Bulletin Board Liaison (DBBL) は、アプリケーションを複数のサーバー・マシンに分散できるようにするOracle Tuxedo管理プロセスです。DBBLによって、各サーバー・マシンでのBulletin Board Liaison (BBL)サーバーの正常な動作が保証されます。DBBLはアプリケーションの
マスター・マシン上で実行され、すべての管理機能と直接通信します。
DBBLによって、構成内の各サーバー・マシンの掲示板への構成情報およびサービス・アドレッシング情報のレプリケートが確実に行われます。リモート・マシン上のサーバーへのアクセスは、ローカル・マシンで実行されているBridgeプロセスを介して行います。ローカル・マシン上のサーバーには、直接アクセスします。ローカルな通信はすべて、高パフォーマンスのオペレーティング・システム・メッセージ・キューを介して実行されます。リモート通信は2つのフェーズで実行されます。最初のフェーズでは、サービス・リクエストが(ローカルな)Bridgeを介してリモート・マシンに転送されます。2番目のフェーズでは、リクエストがリモート・マシンに到達すると、オペレーティング・システム・メッセージを使用してリクエストが適切なサーバー・プロセスに送信されます。
注意:
|
単一マシン構成のOracle Tuxedoアプリケーションの場合、DBBLプロセスが実行されているかどうかは、 UBBCONFIGファイルの RESOURCESセクション内の MODELパラメータの値に基づきます。 MODEL=SHMであればDBBLプロセスは実行されておらず、 MODEL=MPであればDBBLプロセス およびBridgeプロセスは実行されています。DBBLを使用するメリットは、BBLのヘルスが定期的にチェックされ、BBLが停止すると再起動されるということです。デメリットは、追加で2つのシステム・プロセス(DBBLとBridge)が実行されるということです。
|
Oracle Tuxedoワークステーション・サーバー
Oracle Tuxedoワークステーション・サーバー・プロセスでは、Oracle Tuxedoのサーバー側機能がフルインストールされていないリモート・マシン、つまりOracle Tuxedo管理サーバーや掲示板をサポートしていないマシンにワークステーション・クライアント(リモートATMIクライアント)を収容できます。ワークステーション・クライアントとOracle Tuxedoサーバー・アプリケーションとの間の通信はすべて、ネットワーク経由で行われます。
ワークステーション・クライアントには、リクエストに関連付けられた情報をパッケージ化するためのOracle Tuxedoシステム・ソフトウェアが必要です。これにより、ATMI機能やネットワーキング・ソフトウェアを含むすべてのOracle Tuxedoシステム・ソフトウェアをサポートしているOracle Tuxedoアプリケーション内で実行されているWSL (ワークステーション・リスナー)およびWSH (ワークステーション・ハンドラ)のサーバー・プロセスのペアに、その情報を送信できます。次の図は、WSLプロセスおよびWSHプロセスでワークステーション・クライアントがOracle Tuxedoサーバー・アプリケーションに接続される仕組みを示しています。
WSL (ワークステーション・リスナー)は、Oracle Tuxedoサーバー・マシン上で実行されるOracle Tuxedoリスニング・プロセスであり、ワークステーション・クライアントからの接続リクエストを受け入れ、同じくサーバー・マシン上で実行されているワークステーション・ハンドラに接続を割り当てます。また、
ロード需要に基づいてワークステーション・ハンドラを起動および停止することにより、ワークステーション・ハンドラ・プロセスのプールの管理も行います。
管理者は1つのOracle Tuxedoドメイン内に複数のWSLを定義して、複数のサーバー・マシン間でワークステーション通信ロードの分散およびバランシングを行うことができます。
WSH (ワークステーション・ハンドラ)は、Oracle Tuxedoサーバー・マシン上で実行されるOracle Tuxedoゲートウェイ・プロセスであり、ワークステーション・クライアントとOracle Tuxedoサーバー・アプリケーションの間の通信を処理します。WSHプロセスはアプリケーションの管理ドメインに常駐し、ローカルのOracle Tuxedo掲示板にクライアントとして登録されます。
各WSHプロセスは複数のワークステーション・クライアントを管理できます。WSHは、1つの接続に対して特定のワークステーション・クライアントを使用して、すべてのリクエストおよび応答を多重化します。
•
|
『Oracle Tuxedo ATMIワークステーション・コンポーネントの使用』
|
•
|
『ATMIアプリケーションにおけるセキュリティの使用』の セキュリティの管理に関する項
|
•
|
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の UBBCONFIG(5)、 WS_MIB(5)および WSL(5)
|
AUTHSRVというOracle Tuxedo認証サーバーを使用すると、システム管理者は、ワークステーション・クライアントの認証および認可に必要な追加のセキュリティを構成できます。
AUTHSVRは、ユーザーに適切な認証レベルがあるかどうかを検証する単一サービスを提供します。
管理者は、認証および認可の増分レベルを使用してOracle Tuxedoアプリケーションを構成できます。管理者は、
AUTHSVR以外のサーバーから共有リソース(共有メモリーやメッセージ・キューなど)へのアクセスが制限されるようにアプリケーションを構成できます。
アプリケーション設計者は、アプリケーションに特有のロジックを実装する認証サーバーを
AUTHSVRのかわりに使用できます。たとえば、広く使用されているKerberosのメカニズムを認証に使用できるように、企業がカスタム認証サーバーを開発する場合もあります。
•
|
『ATMIアプリケーションにおけるセキュリティの使用』の セキュリティの管理に関する項
|
•
|
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の AUTHSVR(5)
|
Oracle Tuxedoトランザクション管理サーバー
TMSという名称のOracle Tuxedoトランザクション管理サーバーは、Oracle Tuxedo ATMIアプリケーションのかわりに、トランザクションをその起点(通常はクライアント)から1つ以上のサーバー・マシン、そして元のクライアント全体を管理できます。
TMSは、トランザクション参加者を追跡し、2フェーズ・コミット・プロトコルを監視することにより、トランザクションのコミットおよびロールバックが各サイトで適切に処理されるようにします。
実行されるすべての操作およびトランザクションの影響を受けるすべてのモジュールを調整するために、
TMSは1つ以上のリソース・マネージャ(リレーショナル・データベース、階層データベース、ファイルシステム、ドキュメント・ストア、メッセージ・キュー、その他のバックエンド・サービスなど)のアクションを転送します。トランザクションの原子性は
TMSとリソース・マネージャが連携して管理しますが、2フェーズ・コミット・プロトコルおよびトランザクションのリカバリ(必要な場合)を実際に管理するのは
TMSです。
TMSは、2フェーズ・コミットの最初のフェーズの終了時にグローバル・トランザクションの参加者からすべてのyes応答を受け取った後、グローバル・トランザクションをトランザクション・ログ(TLOG)に記録します。TLOGレコードがある場合はグローバル・トランザクションをコミットする必要があり、TLOGレコードがない場合はトランザクションをロールバックする必要があります。Oracle Tuxedoドメイン内の各サーバー・マシンはそれぞれのTLOGを持つ必要があります。
•
|
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の TM_MIB(5)
|
Oracle Tuxedoメッセージ・キューイング・サーバー
Oracle Tuxedoメッセージ・キューイング・サーバーは、Oracle Tuxedo ATMIアプリケーション内のクライアントとサーバー間での時間に依存しない通信を実現します。これにより、アプリケーションはグローバル・トランザクション内でクライアントおよびサーバーで生成されたメッセージを安定した記憶域に格納し、後で処理することができます。メッセージ・キューイング通信に関連するクライアント・プロセスまたはサーバー・プロセスが、キューからいつメッセージを取り出すかを決定します。
Oracle Tuxedoメッセージ・キューイング・サーバーは、
TMQUEUEという名前の「メッセージ・キュー・マネージャ」サーバーと、
TMQFORWARDという名前の「メッセージ転送」サーバーで構成されます。
TMQUEUEサーバーは、クライアントおよびサーバーにかわってメッセージを格納(エンキュー)および取得(デキュー)します。次の図に、
TMQUEUEの処理の流れを示します。
TMQFORWARDサーバーはメッセージをデキューして、処理のために適切なサーバーに転送します。
TMQFORWARDが必要になるのは、キューに格納されたメッセージにサービス・コールが必要な場合のみです。たとえば、あるプロセスでメッセージをキューに格納し、別のプロセスでメッセージをキューから取り出すようなプロセス間通信を行う場合、(Oracle Tuxedoのクライアントまたはサーバーで)キューを使用できます。次の図に、
TMQFORWARDの処理の流れを示します。
•
|
BEA Tuxedo ATMI C関数リファレンスの tpenqueue(3c)および tpdequeue(3c)
|
•
|
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の APPQ_MIB(5)、 TMQUEUE(5)、 TMQFORWARD(5),および UBBCONFIG(5)
|
Oracle Tuxedoパブリッシュ・アンド・サブスクライブ・サーバー
Oracle Tuxedoのパブリッシュ・アンド・サブスクライブ・サーバーは、Oracle Tuxedo ATMIアプリケーション内で実行されるプロセス間でのアプリケーションおよびシステム・イベントの非同期ルーティングを提供します。イベントとは、アプリケーション・プログラムまたはOracle Tuxedoシステム内で、管理者、オペレータまたはソフトウェアの興味を引く状態の変化またはその他の事象です。イベントの例として、「株式が指定された価格以上で取引された」、「ネットワーク障害が発生した」などがあります。
Oracle Tuxedoのパブリッシュ・アンド・サブスクライブ・サーバーは、アプリケーション・イベント・サーバー(
TMUSREVT)およびシステム・イベント・サーバー(
TMSYSEVT)で構成されます。
TMUSREVTサーバーは、クライアントおよびサーバーにかわって
アプリケーション・イベントを処理し、
TMSYSEVTサーバーはクライアントおよびサーバーにかわって
システム・イベントを処理します。次の図に、
TMUSREVTおよび
TMSYSEVTの処理の流れを示します。
•
|
BEA Tuxedoアプリケーションの実行時の管理の イベント・ブローカに関する項
|
Oracle Tuxedo Domains(マルチドメイン)サーバー
Oracle Tuxedoドメイン(複数ドメイン)サーバー・プロセスは、Oracle Tuxedoシステムのクライアント/サーバー・モデルを拡張して、トランザクション・プロセス(TP)ドメイン全体でのトランザクションの相互運用性を実現します。この拡張により、リモート・ドメイン上のサービスへのアクセス(またはリモート・ドメインからのサービス・リクエストの受入れ)がアプリケーション・プログラマとエンド・ユーザーのどちらにも透過的になるため、モデルおよびATMIインタフェースが保持されます。
Oracle Tuxedo Domainsサーバー・プロセスは、ドメイン管理サーバー(
DMADM)、ゲートウェイ管理サーバー(
GWADM)およびドメイン・ゲートウェイ・サーバー・タイプの1つ(
GWTDOMAINプロセスにより実装されたTDomainゲートウェイ・サーバーなど)で構成されます。次の図に、
DMADM、
GWADMおよび
GWTDOMAINの処理の流れを示します。
さらに、Domains構成内の接続を示す図を次に示します。
DMADMサーバーは、ゲートウェイ・グループの登録サービスを提供します。このサービスは、
GWADMサーバーでサーバー初期化プロシージャの一部としてリクエストされます。登録サービスは、リクエスト側のゲートウェイ・グループで必要な構成情報をダウンロードします。
DMADMサーバーは、登録済のゲートウェイ・グループのリストを保守し、ドメイン構成ファイル(
BDMCONFIG)が変更されると、変更内容をこれらのゲートウェイ・グループに伝播します。
複数のドメインがどのように接続され、それらのドメインがどのサービスに相互アクセスするかは、Domains構成ファイルで定義されます。このファイルのテキストとバイナリ・バージョンはそれぞれ、
DMCONFIGおよび
BDMCONFIGとして知られています。Domains構成に関与する各Oracle Tuxedoドメインでは、それ専用のDomains構成ファイルが必要です。
GWADMサーバーは
DMADMサーバーに登録して、対応するゲートウェイ・グループにより使用される構成情報を取得します。
GWADMは、実行時の統計や指定されたゲートウェイ・グループの実行時オプションの変更について
DMADMからのリクエストを受け入れます。
ドメイン・ゲートウェイは、非同期性の高いマルチタスク型のサーバー・プロセスであり、リモート・ドメインとの間で送受信されるサービス・リクエストを処理します。これらにより、ドメイン間でのサービスへのアクセスがアプリケーション・プログラマとアプリケーション・ユーザーのどちらにも透過的になります。
次の図に示すように、Oracle Tuxedoシステムは複数のタイプのドメイン・ゲートウェイをサポートしているため、Oracle Tuxedoアプリケーションは他のOracle Tuxedoアプリケーションや、他のTPシステムで実行されているアプリケーションと通信できます。
異なるOracle Tuxedo構成から利用できるシステム・サービス
次の表では、Oracle Tuxedoシングル・マシン、マルチ・マシン(分散型)およびDomainsアプリケーションで使用可能なOracle Tuxedoシステム・サービスが一覧表示されています。シングル・マシンおよびマルチ・マシンのアプリケーションは、Oracle Tuxedoドメイン構成になります。Domainsアプリケーションは、TDomain (
GWTDOMAIN)ゲートウェイ経由で相互に通信する2つ以上のOracle Tuxedoドメインから構成されるOracle Tuxedoドメイン構成です。
表3-1
Oracle Tuxedo構成の各タイプに使用可能な機能
|
|
|
|
|
|
|
|
|
|
|
|
tmloadcf、 tmunloadcf、 tmboot、 tmadmin、...
Oracle Tuxedo管理プロセスの概要は、 「コマンド行ユーティリティを使用した操作の管理」を参照してください。
|
|
|
|
DMCONFIG、 BDMCONFIG、 DMADM、 GWADM、 GWTDOMAIN、 DMTLOG
dmloadcf、 dmunloadcf、 dmadmin
Oracle Tuxedo Domains管理プロセスの概要は、 「コマンド行ユーティリティを使用したDomainsアプリケーションの管理」を参照してください。
|
|
|
|
アプリケーション・プロセス: クライアント、サーバーおよびサービス
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意:
|
単一マシン構成のOracle Tuxedoアプリケーションの場合、DBBLプロセスが実行されているかどうかは、 UBBCONFIGファイルの RESOURCESセクション内の MODELパラメータの値に基づきます。 MODEL=SHMであればDBBLプロセスは実行されておらず、 MODEL=MPであればDBBLプロセス およびBridgeプロセスは実行されています。DBBLを使用するメリットは、BBLのヘルスが定期的にチェックされ、BBLが停止すると再起動されるということです。デメリットは、追加で2つのシステム・プロセス(DBBLとBridge)が実行されるということです。
|