|
次の項では、Oracle Tuxedoシステム上に構築されたATMIアプリケーションのインフラストラクチャを連携して構成する、Oracle Tuxedoコア・システムの管理およびサーバー・プロセスについて説明します。
次のカテゴリのOracle Tuxedoシステム・プロセスが、アプリケーション・サービス・リクエストの効率的なルーティング、ディスパッチおよび管理、アプリケーション・キュー、そしてATMIアプリケーションのイベント・ポスティングと通知のためのインフラストラクチャを構成します。
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という文字列から始まり、その次にニーモニック文字列(ubbsimpleというファイル名のsimpleなど)が続きます。
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システム・ソフトウェアを実行する必要があります。
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アプリケーション(ドメイン)で掲示板を設定および管理する管理プロセスを中心に説明します。
Oracle Tuxedoアプリケーションの起動、停止および動的な再構成で使用される管理プロセスの詳細は、「Oracle Tuxedoの管理ツール」を参照してください。
掲示板(BB)は、Oracle Tuxedoアプリケーションのすべてのアプリケーション構成情報および動的処理情報が実行時に格納されるメモリー・セグメントです。掲示板の機能は次のとおりです。
Oracle Tuxedoアプリケーション内のそれぞれのサーバー・マシンに掲示板があります。
Bulletin Board Liaison (BBL)は、Oracle Tuxedoアプリケーション内の各サーバー・マシン上で実行されるOracle Tuxedo管理プロセスであり、ローカルな掲示板への変更を調整し、ローカル・マシンでアクティブになっているソフトウェア・プログラムの健全性を検証します。Oracle Tuxedoドメイン内の各サーバー・マシン(マスター・マシンを含む)で実行されるBBLは1つのみです。

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管理サーバーや掲示板をサポートしていないマシンにワークステーション・クライアント(リモート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つの接続に対して特定のワークステーション・クライアントを使用して、すべてのリクエストおよび応答を多重化します。
NFIG(5)、WS_ MIB(5)およびW SL(5)
AUTHSRVというOracle Tuxedo認証サーバーを使用すると、システム管理者は、ワークステーション・クライアントの認証および認可に必要な追加のセキュリティを構成できます。AUTHSVRは、ユーザーに適切な認証レベルがあるかどうかを検証する単一サービスを提供します。
管理者は、認証および認可の増分レベルを使用してOracle Tuxedoアプリケーションを構成できます。管理者は、AUTHSVR以外のサーバーから共有リソース(共有メモリーやメッセージ・キューなど)へのアクセスが制限されるようにアプリケーションを構成できます。
アプリケーション設計者は、アプリケーションに特有のロジックを実装する認証サーバーをAUTHSVRのかわりに使用できます。たとえば、広く使用されているKerberosのメカニズムを認証に使用できるように、企業がカスタム認証サーバーを開発する場合もあります。
HSVR(5)
TMSという名称のOracle Tuxedoトランザクション管理サーバーは、Oracle Tuxedo ATMIアプリケーションのかわりに、トランザクションをその起点(通常はクライアント)から1つ以上のサーバー・マシン、そして元のクライアント全体を管理できます。TMSは、トランザクション参加者を追跡し、2フェーズ・コミット・プロトコルを監視することにより、トランザクションのコミットおよびロールバックが各サイトで適切に処理されるようにします。

実行されるすべての操作およびトランザクションの影響を受けるすべてのモジュールを調整するために、TMSは1つ以上のリソース・マネージャ(リレーショナル・データベース、階層データベース、ファイルシステム、ドキュメント・ストア、メッセージ・キュー、その他のバックエンド・サービスなど)のアクションを転送します。トランザクションの原子性はTMSとリソース・マネージャが連携して管理しますが、2フェーズ・コミット・プロトコルおよびトランザクションのリカバリ(必要な場合)を実際に管理するのはTMSです。
TMSは、2フェーズ・コミットの最初のフェーズの終了時にグローバル・トランザクションの参加者からすべてのyes応答を受け取った後、グローバル・トランザクションをトランザクション・ログ(TLOG)に記録します。TLOGレコードがある場合はグローバル・トランザクションをコミットする必要があり、TLOGレコードがない場合はトランザクションをロールバックする必要があります。Oracle Tuxedoドメイン内の各サーバー・マシンはそれぞれのTLOGを持つ必要があります。
B(5)
Oracle Tuxedoメッセージ・キューイング・サーバーは、Oracle Tuxedo ATMIアプリケーション内のクライアントとサーバー間での時間に依存しない通信を実現します。これにより、アプリケーションはグローバル・トランザクション内でクライアントおよびサーバーで生成されたメッセージを安定した記憶域に格納し、後で処理することができます。メッセージ・キューイング通信に関連するクライアント・プロセスまたはサーバー・プロセスが、キューからいつメッセージを取り出すかを決定します。
Oracle Tuxedoメッセージ・キューイング・サーバーは、TMQUEUEという名前の「メッセージ・キュー・マネージャ」サーバーと、TMQFORWARDという名前の「メッセージ転送」サーバーで構成されます。
TMQUEUEサーバーは、クライアントおよびサーバーにかわってメッセージを格納(エンキュー)および取得(デキュー)します。次の図に、TMQUEUEの処理の流れを示します。

TMQFORWARDサーバーはメッセージをデキューして、処理のために適切なサーバーに転送します。TMQFORWARDが必要になるのは、キューに格納されたメッセージにサービス・コールが必要な場合のみです。たとえば、あるプロセスでメッセージをキューに格納し、別のプロセスでメッセージをキューから取り出すようなプロセス間通信を行う場合、(Oracle Tuxedoのクライアントまたはサーバーで)キューを使用できます。次の図に、TMQFORWARDの処理の流れを示します。

tpenqueue(3c)およびtpdequeue(3c) MIB(5)、TMQU EUE(5)、TMQFORW ARD(5)およびUBBC ONFIG(5)
Oracle Tuxedoのパブリッシュ・アンド・サブスクライブ・サーバーは、Oracle Tuxedo ATMIアプリケーション内で実行されるプロセス間でのアプリケーションおよびシステム・イベントの非同期ルーティングを提供します。イベントとは、アプリケーション・プログラムまたはOracle Tuxedoシステム内で、管理者、オペレータまたはソフトウェアの興味を引く状態の変化またはその他の事象です。イベントの例として、「株式が指定された価格以上で取引された」、「ネットワーク障害が発生した」などがあります。
Oracle Tuxedoのパブリッシュ・アンド・サブスクライブ・サーバーは、アプリケーション・イベント・サーバー(TMUSREVT)およびシステム・イベント・サーバー(TMSYSEVT)で構成されます。TMUSREVTサーバーは、クライアントおよびサーバーにかわってアプリケーション・イベントを処理し、TMSYSEVTサーバーはクライアントおよびサーバーにかわってシステム・イベントを処理します。次の図に、TMUSREVTおよびTMSYSEVTの処理の流れを示します。

tppost(3c)、tpsubscribe(3c)およびtpunsubscribe(3c) EVENTS(5)、 EVENT_MIB(5)、 TMSYSEVT(5)、 TMUSREVT(5)および UBBCONFIG(5)
Oracle Tuxedoドメイン(複数ドメイン)サーバー・プロセスは、Oracle Tuxedoシステムのクライアント/サーバー・モデルを拡張して、トランザクション・プロセス(TP)ドメイン全体でのトランザクションの相互運用性を実現します。この拡張により、リモート・ドメイン上のサービスへのアクセス(またはリモート・ドメインからのサービス・リクエストの受入れ)がアプリケーション・プログラマとエンド・ユーザーのどちらにも透過的になるため、モデルおよびATMIインタフェースが保持されます。
Oracle Tuxedo Domainsサーバー・プロセスは、ドメイン管理サーバー(DMADM)、ゲートウェイ管理サーバー(GWADM)およびドメイン・ゲートウェイ・サーバー・タイプの1つ(GWTDOMAINプロセスにより実装されたTDomainゲートウェイ・サーバーなど)で構成されます。次の図に、DMADM、GWADMおよびGWTDOMAINの処理の流れを示します。


DMADMサーバーは、ゲートウェイ・グループの登録サービスを提供します。このサービスは、GWADMサーバーでサーバー初期化プロシージャの一部としてリクエストされます。登録サービスは、リクエスト側のゲートウェイ・グループで必要な構成情報をダウンロードします。DMADMサーバーは、登録済のゲートウェイ・グループのリストを保守し、ドメイン構成ファイル(BDMCONFIG)が変更されると、変更内容をこれらのゲートウェイ・グループに伝播します。
複数のドメインがどのように接続され、それらのドメインがどのサービスに相互アクセスするかは、Domains構成ファイルで定義されます。このファイルのテキストとバイナリ・バージョンはそれぞれ、DMCONFIGおよびBDMCONFIGとして知られています。Domains構成に関与する各Oracle Tuxedoドメインでは、それ専用のDomains構成ファイルが必要です。
GWADMサーバーはDMADMサーバーに登録して、対応するゲートウェイ・グループにより使用される構成情報を取得します。GWADMは、実行時の統計や指定されたゲートウェイ・グループの実行時オプションの変更についてDMADMからのリクエストを受け入れます。
ドメイン・ゲートウェイは、非同期性の高いマルチタスク型のサーバー・プロセスであり、リモート・ドメインとの間で送受信されるサービス・リクエストを処理します。これらにより、ドメイン間でのサービスへのアクセスがアプリケーション・プログラマとアプリケーション・ユーザーのどちらにも透過的になります。
次の図に示すように、Oracle Tuxedoシステムは複数のタイプのドメイン・ゲートウェイをサポートしているため、Oracle Tuxedoアプリケーションは他のOracle Tuxedoアプリケーションや、他のTPシステムで実行されているアプリケーションと通信できます。

次の表では、Oracle Tuxedoシングル・マシン、マルチ・マシン(分散型)およびDomainsアプリケーションで使用可能なOracle Tuxedoシステム・サービスが一覧表示されています。シングル・マシンおよびマルチ・マシンのアプリケーションは、Oracle Tuxedoドメイン構成になります。Domainsアプリケーションは、TDomain (GWTDOMAIN)ゲートウェイ経由で相互に通信する2つ以上のOracle Tuxedoドメインから構成されるOracle Tuxedoドメイン構成です。
UBBCONFIG、TUXCONFIG、掲示板(BB)、Bulletin Board Liaison (BBL)、Distinguished Bulletin Board Liaison (DBBL)、 ULOG、TLOG、 ブリッジ Oracle Tuxedo管理プロセスの概要は、「コマンド行ユーティリティを使用した操作の管理」を参照してください。
|
|||
|
Oracle Tuxedo Domains管理プロセスの概要は、「コマンド行ユーティリティを使用したDomainsアプリケーションの管理」を参照してください。
|
|||
| 注: | 単一マシン構成のOracle Tuxedoアプリケーションの場合、DBBLプロセスが実行されているかどうかは、UBBCONFIGファイルのRESOURCESセクション内のMODELパラメータの値に基づきます。MODEL=SHMであればDBBLプロセスは実行されておらず、MODEL=MPであればDBBLプロセスおよびBridgeプロセスは実行されています。DBBLを使用するメリットは、BBLのヘルスが定期的にチェックされ、BBLが停止すると再起動されるということです。デメリットは、追加で2つのシステム・プロセス(DBBLとBridge)が実行されるということです。 |
|