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