2 Oracle Tuxedo ATMIのアーキテクチャ
次の各項では、Oracle Tuxedo ATMI環境の基本的な構成要素について説明します:
2.1 Oracle Tuxedo ATMI環境の基本アーキテクチャ
次の図は、Oracle Tuxedo ATMI環境の基本的な構成要素である、環境への外部インタフェース、ATMIレイヤー、MIB、Oracle Tuxedoシステム・サービス、および標準準拠リソース・マネージャとの環境内インタフェースを示しています。
図2-1 Oracle Tuxedo ATMIの基本的なアーキテクチャ
この図に示されているように、Oracle Tuxedo ATMI環境は次のコンポーネントで構成されています。
| 構成部分 | 説明 |
|---|---|
| ATMI (Application-to- Transaction Monitor)インタフェース | アプリケーションとOracle Tuxedo ATMI環境の間のインタフェース。ATMIおよびOracle Tuxedo環境は、トランザクション処理を行うX/Open DTPモデルを実装します。抽象的な環境であるATMIは、場所の透過性をサポートしており、実装の詳細を隠蔽します。そのため、プログラマはアプリケーション・コードを変更せずに、Oracle Tuxedoアプリケーションを構成して複数のプラットフォームにデプロイできます。 |
| メッセージング・パラダイム | クライアントとサーバー間のメッセージ転送に関する各種のモデル。Oracle Tuxedo ATMIメッセージング・パラダイムには、リクエスト/レスポンス、会話、キューイング、パブリッシュ・アンド・サブスクライブおよび非請求通知が含まれます。 |
| MIB—管理情報ベース | MIBは、ユーザーがOracle Tuxedo ATMI環境を容易にプログラミングおよび管理できるようにするインタフェースです。MIBの操作によって、ユーザーはすべての管理タスク(モニタリング、構成、チューニングなど)を実行できます。MIBを使用すると、ユーザーは1つのオブジェクトに対して1つずつタスクを実行したり、タスクやオブジェクトの一括処理に使用できるツールキットを構築することができます。MIBおよびMIBインタフェースの詳細は、「Oracle Tuxedoの管理ツール」を参照してください |
| Oracle Tuxedoサービス(アプリケーション処理サービスおよび管理サービス) | Oracle Tuxedo ATMI環境インフラストラクチャにより提供される、アプリケーションを開発および管理するためのサービスや機能。
Oracle Tuxedoの開発者が使用できるアプリケーション処理サービスには、データ圧縮、データ依存型ルーティング、データ・エンコーディング、データ暗号化、ロード・バランシング、 メッセージの優先度付けおよびサービスとイベントのネーミングが含まれます。これらのサービスについては、以降で説明します。 Oracle Tuxedoの管理者が使用できる管理サービスには、アプリケーションの起動と停止、集中アプリケーション構成、分散アプリケーション管理、動的なアプリケーション再構成、ワークステーション管理、セキュリティ管理、トランザクション管理、メッセージ・キューイング管理およびイベント管理が含まれます。管理サービスを提供するシステム管理プロセスの詳細は、「Oracle Tuxedoシステムの管理およびサーバー・プロセス」および「Oracle Tuxedoの管理ツール」を参照してください。 |
| リソース・マネージャ | データはこのソフトウェア製品に格納され、アプリケーションベースの問合せを介して取得できます。リソース・マネージャ(RM)はOracle Tuxedo ATMI環境と対話し、XA標準インタフェースを実装します。リソース・マネージャの代表的な例はデータベースです。リソース・マネージャは、トランザクションの機能およびアクションの永続性を提供するエンティティであり、グローバル(分散)トランザクション内でアクセスおよび制御されます。 |
親トピック: Oracle Tuxedo ATMIのアーキテクチャ
2.2 ATMIを使用して実行できること
図2-2 ATMIの使用
ATMI関数は、分散されたプログラム間でデータを送受信できるようにすることで、これらのプログラムを互いに結び付けます。すべてのATMI関数は、型付きバッファ内でデータを送受信します
次の表に、CおよびCOBOLのバインディング用のATMI関数と、それにより実行されるタスクをリストします。関数はタスクごとに分類されています。
表2-1 ATMI関数の使用
| タスク | C関数 | COBOL関数 | タスクの説明 |
|---|---|---|---|
| クライアントのメンバーシップ | tpchkauth(3c) | TPCHKAUTH(3cbl) | 認証が必要かどうかを確認します |
| tpinit(3c) | TPINITIALIZE(3cbl) | クライアントをアプリケーションに参加させます。 | |
| tpterm(3c) | TPTERM(3cbl) | クライアントをアプリケーションから分離します。 | |
| バッファ管理 | tpalloc(3c) | 該当なし | メッセージ・バッファを作成します |
| tprealloc(3c) | 該当なし | メッセージ・バッファのサイズを変更します | |
| tpfree(3c) | 該当なし | メッセージ・バッファを解放します | |
| tptypes(3c) | 該当なし | メッセージのタイプとサブタイプを取得します | |
| メッセージの優先度 | tpgprio(3c) | TPGPRIO(3cbl) | 最後のリクエストの優先度を取得します |
| tpsprio(3c) | TPSPRIO(3cbl) | 次のリクエストの優先度を設定します | |
| リクエスト/レスポンス型通信 | tpcall(3c) | TPCALL(3cbl) | サービスへの同期リクエスト/レスポンスを開始します |
| tpacall(3c) | TPACALL(3cbl) | 非同期リクエスト(ファンアウト)を開始します。 | |
| tpgetrply(3c) | TPGETRPLY(3cbl) | 非同期レスポンスを受け取ります | |
| tpcancel(3c) | TPCANCEL(3cbl) | 非同期リクエストを取り消します | |
| 会話型通信 | tpconnect(3c) | TPCONNECT(3cbl) | サービスとの会話を開始します |
| tpdiscon(3c) | TPDISCON(3cbl) | 会話を異常終了します | |
| tpsend(3c) | TPSEND(3cbl) | 会話中にメッセージを送信します | |
| tprecv(3c) | TPRECV(3cbl) | 会話中にメッセージを受信します | |
| メッセージ・キューイング通信 | tpenqueue(3c) | TPENQUEUE(3cbl) | メッセージをメッセージ・キューに登録します |
| tpdequeue(3c) | TPDEQUEUE(3cbl) | メッセージをメッセージ・キューから取り出します | |
| パブリッシュ・アンド・サブスクライブ通信 | tpnotify(3c) | TPNOTIFY(3cbl) | クライアントに非請求メッセージを送信します |
| tpbroadcast(3c) | TPBROADCAST(3cbl) | 複数のクライアントにメッセージを送信します | |
| tpsetunsol(3c) | TPSETUNSOL(3cbl) | 非請求メッセージのコールバックを設定します | |
| tpchkunsol(3c) | TPCHKUNSOL(3cbl) | 非請求メッセージの到着を確認します | |
| 該当なし | TPGETUNSOL(3cbl) | 非請求メッセージを取得します。 | |
| tppost(3c) | TPPOST(3cbl) | イベント・メッセージをポストします | |
| tpsubscribe(3c) | TPSUBSCRIBE(3cbl) | イベント・メッセージをサブスクライブします | |
| tpunsubscribe(3c) | TPUNSUBSCRIBE(3cbl) | イベント・メッセージのサブスクリプションを削除します | |
| トランザクション管理(表の最後にあるノートを参照) | tpbegin(3c) | TPBEGIN(3cbl) | トランザクションを開始します |
| tpcommit(3c) | TPCOMMIT(3cbl) | 現在のトランザクションをコミットします | |
| tpabort(3c) | TPABORT(3cbl) | 現在のトランザクションをロールバックします | |
| tpgetlev(3c) | TPGETLEV(3cbl) | トランザクション・モードであるかどうかを確認します | |
| tpsuspend(3c) | TPSUSPEND(3cbl) | 現在のトランザクションを一時停止します | |
| tpresume(3c) | TPRESUME(3cbl) | トランザクションを再開します | |
| サービスの登録と応答 | tpsvrinit(3c) | TPSVRINIT(3cbl) | サーバーを初期化します |
| tpsvrdone(3c) | TPSVRDONE(3cbl) | サーバーを終了します | |
| tpservice(3c) | 該当なし | サービス・エントリ・ポイントのプロトタイプです。 | |
| 該当なし | TPSVCSTART(3cbl) | サービス情報を取得します | |
| tpreturn(3c) | TPRETURN(3cbl) | サービス関数を終了します | |
| tpforward(3c) | TPFORWAR(3cbl) | リクエストを転送します | |
| 動的な通知 | tpadvertise(3c) | TPADVERTISE(3cbl) | サービス名を通知します |
| tpunadvertise(3c) | TPUNADVERTISE(3cbl) | サービス名の通知を解除します | |
| リソース管理 | tpopen(3c) | TPOPEN(3cbl) | リソース・マネージャをオープンします |
| tpclose(3c) | TPCLOSE(3cbl) | リソース・マネージャをクローズします |
ノート:
Oracle Tuxedo ATMIトランザクション管理関数の使用は、オプションです。Oracle TuxedoではX/Open TXトランザクション管理関数もサポートされているため、トランザクション管理にこれらの関数を使用することもできます。- 表のC関数の詳細は、C関数のリファレンス・ページを参照してください
- 表のCOBOL関数の詳細は、COBOL関数のリファレンス・ページを参照してください
- 『Oracle Tuxedoアプリケーション実行時の管理』のATMIを使用したシステム・エラーおよびアプリケーション・エラーの処理に関する項
親トピック: Oracle Tuxedo ATMIのアーキテクチャ
2.3 Oracle Tuxedo ATMIのメッセージング・パラダイムとは
Oracle Tuxedo ATMIは、アプリケーションのサーバー・プロセスの管理やトランザクションの管理に加えて、クライアント/サーバー通信も管理します(つまり、クライアント(およびサーバー)は、次の表に示されているメッセージング・パラダイムのいずれかを使用して、アプリケーション・サービスを起動できます)。
| Oracle Tuxedo ATMIのメッセージング・パラダイム | 説明 |
|---|---|
| リクエスト/レスポンス型通信 | クライアントから1つのリクエストが発行され、コールされたリクエスト/レスポンス型サーバーからの1つのレスポンスが返される、単純なタイプのダイアログ。通常、リクエスト/レスポンス型トランザクションでは人間が関与するため、即時の反応が要求され、高優先度モードで実行されます。 |
| 会話型通信 | クライアントとコールされた会話サーバーの間の状態が保持される接続(メッセージからメッセージへコンテキストが保持されます)。会話トランザクションでも通常は人間が関与するため、即時の反応が要求され、高優先度モードで実行されます。 |
| メッセージ・キューイング通信 | クライアントとサーバー間の時間に依存しない通信。キューに入れられたトランザクションは、優先度の高いまたは低いメッセージとして実行できます。Oracle Tuxedoシステムには、/Qというリカバリ可能なキューの独自バージョンがバンドルされています。 |
| パブリッシュ・アンド・サブスクライブ通信 | Oracle Tuxedo ATMIアプリケーションのクライアントとサーバー間でのイベントの非同期ルーティング。パブリッシュ・アンド・サブスクライブ・トランザクションは通常、優先度の高いメッセージとして実行されます。Oracle Tuxedoシステムには、イベント・ブローカというトランザクション対応パブリッシュ・アンド・サブスクライブ・システムが備わっています。 |
| 非請求通知のメッセージング | クライアントまたはサーバーからクライアントへの通信で、受信側のクライアントによりリクエストも予測もされていなかったもの。非請求通知は、イベント・ブローカによって処理されます。 |
2.3.1 リクエスト/レスポンス型通信
ATMIクライアントとサーバーの間のリクエスト/レスポンス型通信を実装するために、Oracle Tuxedoシステムではプロセス間通信(IPC)メッセージ・キューを使用しています。キューは、コネクションレス通信にの重要な要素です。各サーバーにはリクエスト・キューと呼ばれるIPCメッセージ・キューが割り当てられ、各クライアントにはレスポンス・キューが割り当てられます。このため、クライアント・アプリケーションは、サーバーとの接続を確立して維持するかわりに、リクエストをサーバーのキューに登録してリクエストをサーバーに送信し、その後でアプリケーションのレスポンス・キューからメッセージを取り出すことにより、サーバーからのメッセージを確認して取得できます。
リクエスト/レスポンス型モデルは、同期サービス・リクエストと非同期サービス・リクエストの両方に使用されます。
2.3.1.1 同期メッセージング
同期コールでは、クライアントがサーバーにリクエストを送信し、クライアントが待機している間にサーバーがリクエストされたアクションを実行します。その後、サーバーがクライアントに応答を送信し、クライアントが応答を受信します。
図2-3 同期リクエスト/レスポンス型通信
親トピック: リクエスト/レスポンス型通信
2.3.1.2 非同期メッセージング
非同期コールでは、Oracle Tuxedoクライアントは、発行したサービス・リクエストの処理完了を待機せずに、他のタスクを開始します。クライアントはリクエストの発行後も、追加のタスク(他のリクエストの発行など)を実行します。最初のリクエストへの応答が使用可能になると、クライアントはその応答を取得します。
図2-4 非同期リクエスト/レスポンス型通信
親トピック: リクエスト/レスポンス型通信
2.3.2 会話型通信
会話型通信はOracle Tuxedoシステムのメッセージ交換のパラダイムで、人の会話に似た通信がATMIクライアントおよびサーバー間で実装されています。この通信方法では、クライアントとサーバー間で仮想接続が維持されます。2人の人間で会話する場合と同じように、結論に達するまで多数のメッセージが2つのエンティティの間でやり取りされます。通信が行われている間、両者が会話のポイント(または状態)を記録しているため、比較的長い操作(非定型問合せ、レポート、ファイル転送など)をサポートできます。デフォルトで会話サーバーは使用可能ですが、必要に応じて追加のサーバーを自動生成することもできます。
図2-5 会話型通信
2.3.3 メッセージ・キューイング通信
Oracle Tuxedoシステムでは、データの永続ストレージを必要とするATMIアプリケーションに対して使用できる、/Qと呼ばれるキューベースのアーキテクチャが提供されています。/Qコンポーネントを使用すると、どのクライアントまたはサーバーもメッセージまたはサービス・リクエストをキューに格納でき、格納されたリクエストは必ずトランザクション・プロトコルを介して送信されるため、安全なストレージが保証されます。
図2-6 キューベースのメッセージング
アプリケーション・キューは、時間に依存しない通信を行う必要がある場合に適しています。時間に依存しない通信では、プログラムが互いに独立して動作し、互いの通信を同期する必要がないことが特徴です。時間に依存しないプログラムでは、互いにメッセージをアプリケーション・キューに残すことによって同期を取ります。メッセージは、FIFO、優先度、時刻順などの順序付けスキームでデキューできます。Oracle Tuxedoのクライアント・プログラムおよびサーバー・プログラムは、メッセージをエンキューし、キューからメッセージをデキューできます。複数のクライアントおよびサーバーが同じキューにアクセスできます。
アプリケーション・キューを使用するには、プログラムで、アクセスされるキューと、そのキューが含まれるキュー・スペースに名前を付ける必要があります。アプリケーションでは複数のキュー・スペースを使用でき、各スペースには複数のメッセージ・キューを含めることができます。
アプリケーション・キューはディスク上に存在するため、格納されたメッセージは、マシンに障害が発生した場合でも使用できます。どのような場合にアプリケーション・キューを使用するかは、業務(注文書の入力など)で時間に依存しない同期をいつ行うかによって判断する必要があります。注文書はディスクにエンキューし、品目や出荷場所などの特定の注文条件に基づいて、異なるキュー・スペースに入れることができます。各キュー・スペース内に、コストや状態などの追加の条件を指定することもできます。
2.3.4 パブリッシュ・アンド・サブスクライブ通信
Oracle Tuxedoのパブリッシュ・アンド・サブスクライブ・コンポーネントはイベント・ブローカと呼ばれ、任意の数のサプライヤが任意の数のサブスクライバにメッセージをポストできる通信パラダイムを提供します。イベント・ブローカを使用するATMIクライアント・プロセスおよびサーバー・プロセスは、サブスクリプションのセットに基づいて相互通信を行います。イベント・ブローカは、購読料を支払っている顧客にのみ新聞を配達する新聞配達員のような役割を果たします。
図2-7 イベントのポストおよびサブスクライブ
イベントの発信元(クライアントまたはサーバー)は、変更や問題が発生すると、イベント・ブローカにそれを通知します。このプロセスは、イベントのポストと呼ばれます。イベント・ブローカは、イベントの名前をサブスクライバのリストと関連付けられているイベント名と照合し、リスト内の各サブスクライバにそのイベントを通知します。
2.3.4.1 通知されるイベントのタイプ
Oracle Tuxedoシステムでは、2種類のイベント・レポートをサポートしています。
- アプリケーション定義のイベント・レポート—アプリケーション・プログラムは、特定の基準が満たされた場合に、イベントをポストできます。たとえば、銀行取引アプリケーションの場合、一定額を超える引出しが行われるとイベントがポストされます。
- システム・イベント・レポート—サーバーやネットワークの障害など、Oracle Tuxedoシステム・イベントに関する詳細を提供します。クライアントまたはサーバーによってイベントがポストされると、イベント・ブローカはポストされたイベントの名前をそのイベントのサブスクライバと照合し、各サブスクリプションで指定されている適切なアクションを実行します。
親トピック: パブリッシュ・アンド・サブスクライブ通信
2.3.4.2 イベントの通知
プロセスは、イベント・ブローカにサブスクリプションを登録し、特定のイベントに関心があることを示します。以降は、指定されたイベントが発生したことが別のプロセスから通知されると、イベント・ブローカが、そのイベントに対してサブスクライブしているすべてのプロセスにイベントの発生を報告します。
図2-8 イベントベースのメッセージング
イベント・ブローカは、次のメカニズムを使用してイベントの公開(イベント通知の発行)を行います。
- ディスクベースのキューイング
- 非同期サービス・コール
- ユーザー・ログ・エントリ
- 非請求メッセージ
- システム・コマンド
親トピック: パブリッシュ・アンド・サブスクライブ通信
2.3.5 非請求通信
Oracle Tuxedoシステムには、非請求通知と呼ばれる強力な通信パラダイムがあります。非請求通知が発生すると、ATMIクライアントは、リクエストしていないメッセージを受け取ります。イベント・ブローカにより管理されるこの機能を使用すると、アプリケーション・クライアントは、アプリケーション固有のイベントが発生したときに、リアルタイムで明示的に通知をリクエストしなくても、そのイベントの通知を受け取ることができます。
tpbroadcast)によって送信されるか、以前に処理されたメッセージとともに受け取られた識別子(tpnotify)によって送信されます。tpbroadcastを使用すると、メッセージをサービスまたは別のクライアントから送信できます。送信先は、狭い範囲にも広い範囲にもできます。ポイントツーポイントの通知によって配信保証付きまたは配信保証なしのメッセージを個々のクライアントに送信したり(tpnotify)、クライアントのグループに対して情報を送信することができます(tpbroadcast)。たとえば、サーバーは、クライアントから照会された口座が解約されていることをそのクライアントのみに通知できます。あるいは、あるマシンがメンテナンスのために特定の時刻に停止されるというメッセージを、そのマシン上のすべてのクライアントに送信することもできます。
図2-9 非請求通知のメッセージング
特定のイベント(マシンをメンテナンスのために停止するなど)について通知を受ける必要のあるプロセスは、自動的に通知を受けるためのリクエストをシステムに登録できます。登録後は、指定したイベントが発生するたびにクライアントまたはサーバーに通知されます。イベントに関するこのような自動通信は、非請求通知と呼ばれます。
イベントを生成したり、このようなイベントに関する非請求通知を受信するクライアントおよびサーバーの数に制限はないため、このカテゴリの通信に対する管理タスクは複雑になる場合があります。
関連項目
- 『Oracle Tuxedo ATMIアプリケーション開発のためのチュートリアル』のリクエスト/レスポンス型モデル(同期コール)に関する項
- 『Oracle Tuxedo ATMIアプリケーション開発のためのチュートリアル』の会話型通信の使用に関する項
- Oracle Tuxedoメッセージ・キューイング・サーバー
- コマンド行ユーティリティを使用したアプリケーション・キューの管理
- 『Oracle Tuxedo ATMIアプリケーション開発のためのチュートリアル』のキューベースの通信の使用に関する項
- Oracle Tuxedoパブリッシュ・アンド・サブスクライブ・サーバー
- イベント・ブローカを使用したイベントの管理
- 『Oracle Tuxedo ATMIアプリケーション開発のためのチュートリアル』のイベントベースの通信の使用に関する項
- 『Oracle Tuxedo ATMIアプリケーション開発のためのチュートリアル』の非請求通知の使用に関する項
2.4 ネストおよび転送されたリクエストとは
ネストおよび転送されたサービス・リクエストを使用すると、Oracle TuxedoサービスはATMIクライアントとして機能し、他のサービスをコールできます。
2.4.1 ネストされたリクエスト
ネストは特に3層のクライアント/サーバー・アーキテクチャ、すなわちプレゼンテーション・ロジック・レイヤー、ビジネス・ロジック・レイヤーおよびデータベース・レイヤーから構成されるシステムで特に有用です。このようなシステムでは、プレゼンテーション・レイヤーによってデータベースへの1つ以上の問合せに関連する特定のビジネス関数のリクエストが構成されます。
図2-10 ネストされたサービス・リクエスト
2.4.1.1 ネストされたリクエストの利点
ネストされたリクエストを使用するメリットの1つは、各コード部分が限定されたタスクのみを行うので、コードが少なくて済み、再利用も可能であることです。ただし、システムのサービスが複数のサーバーに分散されている場合は、リクエストをネストするとパフォーマンスが低下することがあります。ネストされたリクエストが処理されている間、元のサービス(ネストされたリクエストを発行したサービス)は、続行前にレスポンスを待機する必要があります。レスポンスを受信するまで、元のサービスは別のリクエストを処理できません。そのため、このサービスが存在するサーバーのリクエスト・キュー内にメッセージをバックアップできます。
親トピック: ネストされたリクエスト
2.4.1.2 ネストされたサービス・リクエストの例
ある顧客が現金自動預入支払機を使用して普通預金口座から当座預金口座に預金を振り替えます。預金の振替えに必要な処理は、Oracle Tuxedoアプリケーションによって実行されます。まず、顧客にかわって、クライアントがTRANSFERというサービスへのリクエストを発行すると、そのリクエストがそのサービスを提供するサーバーのキューに入れられます。次に、TRANSFERサービスが他の2つのサービス(WITHDRAWおよびDEPOSIT)をリクエストすると、2番目のサーバーによってこれらのサービスが処理されます。WITHDRAWサービスおよびDEPOSITサービスは、TRANSFERサービスにレスポンスを返します。最後に、TRANSFERがレスポンスをクライアントのレスポンス・キューに送信します。クライアントがレスポンスをキューから取り出すと、現金自動預入支払機の画面に振替えが完了したことを通知するメッセージが表示されます。
親トピック: ネストされたリクエスト
2.4.2 転送されたリクエスト
図2-11 転送されたサービス・リクエスト
関連項目
- 『Oracle Tuxedo ATMIアプリケーション開発のためのチュートリアル』のネストされたコールの使用に関する項
- 『Oracle Tuxedo ATMIアプリケーション開発のためのチュートリアル』の転送されたコールの使用に関する項
親トピック: ネストおよび転送されたリクエストとは
2.5 Oracle Tuxedoによるメッセージの処理
図2-12 リクエストの処理
クライアントは、ATMI 関数を使用してサービスを名前でリクエストします。指定されたサービスが現在使用可能かどうかは、ネーミング機能を使用してMIBを確認することにより判断されます。
Oracle Tuxedoシステムでは、特定の基準(メッセージの値)を満たすメッセージを特定のサーバーにマップする自動ルーティング・オプションであるデータ依存型ルーティングが使用されます。メッセージにデータ依存型ルーティングが使用される場合、ルーティング・アルゴリズムに基づいてバッファ内のデータが使用されます。このアルゴリズムでは、サービス・リクエストを処理できるサーバーのグループを選択できます。
一部のサーバーに多数のリクエストが集中し、同じサービスを通知している他のサーバーがアイドル状態になることを回避するために、Oracle Tuxedoシステムではサービス・リクエストをすべてのサーバー間で均等に分散するためにMIBを使用しています。この方法はロード・バランシングと呼ばれます。
選択したサーバーに対してローカルのサービス・リクエストが準備され、事前定義済の優先度でそのサーバーのキューにリクエストがエンキューされることがあります。この方法はサービスの優先度付けと呼ばれます。サービス・リクエストがサーバーに到達すると、ランタイム・システムによってメッセージが優先度に基づいて取得されます。メッセージは、適切なサービスにディスパッチされて、処理されます。その後、結果がクライアント・キューに返されます。
Oracle Tuxedoシステムで提供されるソフトウェアには、メッセージ処理の際にアプリケーションが自動的かつ定期的に使用できる機能が備わっています。これらの機能には、データのエンコーディングとデコーディング、データの圧縮と解凍、トランザクション・コンテキストの設定、セキュリティ処理などがあります。さらに、Oracle Tuxedoシステム・ソフトウェアは、サービス関数をディスパッチして、適切に前処理されたバッファにそれを渡すことにより、アプリケーションのビジネス・ロジックを起動します。
サービス・ルーチンが実行され、応答(型付きバッファ)が返されます。ランタイム・システムは、メッセージを自動的にエンコードすることによって、クライアントへの応答を準備します: 異なるタイプのバイト順序を使用しているマシン間で転送できるようにデータをパッケージ化して、ネットワークやプラットフォームの境界を越えてデータを転送できるようにします。続いて、メッセージをクライアントに送信します。このプロセスはデータのエンコーディングと呼ばれます。クライアント上のランタイム・システムは、応答メッセージを取得し、必要に応じてデコードした後、フィールド操作言語(FML)バッファ(またはほかのメッセージ・バッファ・タイプのバッファ)を送信してアプリケーション・データをパッケージ化します。必要に応じて、タイプの検証、エンコーディング、ルーティングおよびロード・バランシングが行われます。サービス・リクエストは、同期でも非同期でも実行できます。
リモート・リクエストは、ローカル・ブリッジを通過してリモート・マシンに到達します(ここでは、リモート・ブリッジがクライアントとして動作し、クライアントとサーバーが同じマシン上にあるかのようにリクエストが処理されます)。ブリッジは、標準のデータ・エンコーディングまたはデコーディングを提供し、標準のネットワーク・トランスポートを使用して通信します。クライアントとサーバーからは、ブリッジは通常のローカル・サーバーのように見えます。
2.5.1 サービス・リクエスト処理の利点
サービス・リクエスト処理には次のようなメリットがあります。
- コネクションレス型の処理—この処理をクライアント/サーバー型のダイレクト通信と組み合せると、接続の確立に伴うオーバーヘッドを削減できます。
- ネットワーク・トラフィックの削減—サービス・リクエストは、複雑なサービスがあればそれをリモート・マシン上で起動し、必要な最小限のデータのみを送信し、最小限の結果を受信します。
関連項目
親トピック: Oracle Tuxedoによるメッセージの処理
2.6 型付きバッファとは
すべてのATMI関数は、型付きバッファを使用してデータを送受信します。Oracle Tuxedoシステムでは、異種のマシン間での変換とデータ変換を処理します。Oracle Tuxedoプログラムは、バッファを使用することで、データ表現の異なる異種のプラットフォーム間でやり取りされるデータを変換する必要性をなくしています。
バッファとは、データの論理的なコンテナとして機能するメモリー領域のことです。メタデータ(それ自身に関する情報)が含まれていないバッファは、型なしバッファです。メタデータ(イプとサブタイプ、またはバッファを特徴付ける文字列名など、バッファに格納できる情報)が含まれるバッファは、型付きバッファです。
型付きバッファは、Oracle Tuxedoシステムでサポートされる任意のプロトコルを使用して、任意のネットワークを任意のオペレーティング・システムに転送できます。また、データ表現の異なる複数のプラットフォーム上でも使用できます。このため、型付きバッファを使用すると、異種のマシン間での変換およびデータ変換のタスクが容易になります。
Oracle Tuxedoシステムでは、次の5種類の型付きバッファがサポートされています。
- STRING
- CARRAY
- VIEW
- FML
- XML
- MBSTRING
バッファ・タイプは、Oracle Tuxedo (UBBCONFIG)構成ファイルのMACHINESセクションに定義されたENVFILEパラメータで割り当てます。Oracle Tuxedo構成ファイルのSERVERSセクション内のENVFILEパラメータでバッファ・タイプの割当てまたはオーバーライドを行うと、それらのバッファ・タイプを必要とするプロセスでそれらを使用できなくなることがあります。
各種のメッセージ・バッファの定義については、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のtuxtypes(5)でtm_typeswの説明を参照してください。
2.6.1 バッファ・タイプの特徴
ATMI通信関数を使用する場合、アプリケーションは最初にtpallocを使用して、バッファのサイズ、タイプおよびサブタイプ(オプション)を指定して、システムからバッファを取得する必要があります。Oracle Tuxedoシステムではバッファ・タイプが認識されて処理されるため、データはOracle Tuxedoシステムでサポートされるあらゆるタイプのネットワーク、プロトコルおよびオペレーティング・システム上で転送されます。様々なタイプのOracle Tuxedoバッファの詳細は、『C言語を使用したOracle Tuxedo ATMIアプリケーションのプログラミング』の型付きバッファの管理に関する項を参照してください。
関連項目
- 『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のtuxtypes(5)、typesw(5)および
UBBCONFIG(5)に関する項
親トピック: 型付きバッファとは
2.7 データ圧縮とは
データ圧縮は、ネットワーク上またはリモート・ドメインへの転送を高速化するために、アプリケーション・バッファを縮小するプロセスです。アプリケーション・バッファに最大サイズを設定することで、指定したサイズ以上のアプリケーション・バッファは自動的に圧縮されるように設定できます。バッファが宛先に到達すると、そのデータは解凍され、元のサイズに戻ります。
マシン間でファイルを送付する前にデータ圧縮を行うと、ネットワークのパフォーマンスが向上します。圧縮のプロセスでデータのスクランブリングも行われるので、セキュリティも若干強化されます。
ノート:
データ圧縮は、暗号化の際にも頻繁に行われます。図2-13 データ圧縮
親トピック: Oracle Tuxedo ATMIのアーキテクチャ
2.8 データ依存型ルーティングとは
Oracle Tuxedoシステムでは、クライアントが同じサービスに対するリクエストをそのサービスの複数のコピーに送信できるように、データ依存型ルーティングと呼ばれる操作を使用します。サービスのどのコピーが最終的にリクエストを受け入れて処理するかは、リクエスト・メッセージ内のデータによって決まります。管理者がアプリケーションにデータ依存型ルーティングを設定すると、クライアント・リクエストはリクエスト内のデータに基づいて自動的にサーバーにルーティングされます。
ノート:
掲示板のルーティング表は、必要に応じて変更できます。親トピック: Oracle Tuxedo ATMIのアーキテクチャ
2.8.1 データ依存型ルーティング
データ依存型ルーティングは、クライアントが次のものにサービス・リクエストを発行したときに有用です。
- 水平分離型データベース
- ルール・ベース・サーバー
- 分散アプリケーション
水平分離型データベースとは、セグメントに分割された情報リポジトリであり、各セグメントに異なるカテゴリの情報が格納されます。これは、図書館で各本棚に異なるカテゴリ(伝記、フィクションなど)の本が収納されているのと似ています。
ルール・ベース・サーバーとは、サービス・リクエストをサービス・ルーチンに転送する前に、サービス・リクエストが特定のアプリケーション固有の条件を満たしているかどうかを判定するサーバーです。ルール・ベース・サーバーは、ほとんど同じ複数のリクエストに対して、ビジネス上の理由で多少異なる処理を行う場合に使用すると有用です。
分散アプリケーションとは、1つ以上のローカル・クライアントまたはリモート・クライアントが、ネットワークで接続された複数のマシン上の1つ以上のサーバーと通信するアプリケーションのことです。クライアント(またはクライアントとして動作するサーバー)は、特定のサービスに対するリクエストを発行します。リクエストのアドレスは、そのリクエストを処理できるサーバーを識別するデータ(リクエストと同じバッファ内で送信される)によって決まります。複数のサーバーがこれを実行できることもあります。Oracle Tuxedoシステムは、掲示板に提供されているルーティング基準とデータを照合することで、リクエストを受け取るサーバーを選択します。
親トピック: データ依存型ルーティングとは
2.8.2 水平分離型データベースでのデータ依存型ルーティングの例
銀行取引アプリケーションで2つのクライアントが口座3と口座17という2つの口座の現在の残高を照会するリクエストを発行したとします。アプリケーションでデータ依存型ルーティングが使用されている場合、Oracle Tuxedoシステムでは次の処理が行われます。
- 2つのサービス・リクエストで指定された口座番号(3と17).を取得します
- どのサーバーがどのデータ範囲の処理を行うかを示す、Oracle Tuxedoの掲示板のルーティング表を確認します。(この例では、サーバー1が口座1から10のすべてのリクエストを処理し、サーバー2が口座11から20のすべてのリクエストを処理します。)
- それぞれのリクエストを該当するサーバーに送信します。つまり、口座3へのリクエストをサーバー1に転送し、口座17へのリクエストをサーバー2に転送します。
図2-14 水平分離型データベースでのデータ依存型ルーティング
親トピック: データ依存型ルーティングとは
2.8.3 ルール・ベース・サーバーでのデータ依存型ルーティングの例
次の規則を持つ銀行取引アプリケーションがあるとします。
- 顧客は、特別なパスワードを入力しなくても、$500まで引き出すことができます。
- $500を超える額を引き出すには、特別なパスワードを入力する必要があります。
2つのクライアントが$100と$800の引出しのリクエストを発行したとします。引出しのルールをサポートするようにデータ依存型ルーティングが有効になっている場合、Oracle Tuxedoでは次のような処理が行われます。
- 2つのサービス・リクエストで指定された引出し額($100と$800)を取得します。
- リクエストされた金額がどのサーバーにより処理されるかを示す、Oracle Tuxedoの掲示板のルーティング表を確認します。(この例では、$500までのすべての引出しリクエストはサーバー1により処理され、$500を超えるすべての引出しリクエストはサーバー2により処理されます。)
- それぞれのリクエストを該当するサーバーに送信します。つまり、$100のリクエストをサーバー1に転送し、$800のリクエストをサーバー2に転送します。
図2-15 ルールベース・サーバーでのデータ依存型ルーティング
親トピック: データ依存型ルーティングとは
2.8.4 分散アプリケーションでのデータ依存型ルーティングの例
次の図は、分散アプリケーションでどのようにクライアント・リクエストがサーバーにルーティングされるかを示しています。この例では、bankappという銀行取引アプリケーションはデーた依存型ルーティングを使用しています。bankappには3つのサーバー・グループ(BANK1、BANK2、およびBANK3)と2つのルーティング基準(Account IDおよびBranch ID)が含まれます。WITHDRAW、DEPOSITおよびINQUIRYサービスは、Account_IDフィールドを使用してルーティングされます。OPENおよびCLOSEサービスは、Branch_IDフィールドを使用してルーティングされます。
図2-16 ルーティング基準を使用した銀行取引アプリケーションの例
前の図では、リクエストは次の表に示すようにルーティングされます:
| 次の口座の引出し、預入れ、照会、開設、解約などの請求 | ルーティング |
|---|---|
| 支店1–4の口座番号10000–49999 | Bank1 |
| 支店5–7の口座番号50000–79999 | Bank2 |
| 支店8–10の口座番号80000–109999 | Bank3 |
親トピック: データ依存型ルーティングとは
2.9 データのエンコーディングとデコーディングとは
エンコーディングおよびデコーディングを行うと、データ表現(バイトの順序や文字セットなど)が異なるメッセージをマシン間で転送できるようになります。Oracle Tuxedoシステムは、Oracle Tuxedoアプリケーションに関与する他のマシンに転送できるように、データをマシンに依存しない表現にエンコードおよびデコードします。
Oracle Tuxedoシステムは、デフォルトで外部データ表現(XDR)アルゴリズムを採用していますが、このアルゴリズムはOracle Tuxedoシステム関数をユーザー記述関数で置き換えることによってカスタマイズできます。エンコーディングおよびデコーディングは、マシン間でのみ、またリモート・マシンで使用されるデータ表現がローカル・マシンで使用されているデータ表現と異なる場合にのみ使用されます。エンコーディングおよびデコーディングを行うと、異なるデータ・アーキテクチャを持つマシンが異種のOracle Tuxedoシステムで動作できます。プログラマは、それぞれの環境に適した表現でデータを管理できます。
Oracle Tuxedoシステムは、バッファ・タイプを使用して、メッセージに含まれているフィールドのタイプを判別し、コーディング作業に必要なマッピングを実行します。このマッピングは、X_OCTETやCARRAYなどの非構造化バッファ・タイプによって実行されるものではありません。このため、X_OCTETおよびCARRAYバッファを使用する開発者は、異種のマシンが混在する環境で自由にデプロイを実行できます。
親トピック: Oracle Tuxedo ATMIのアーキテクチャ
2.10 データの暗号化とは
図2-17 データの暗号化
親トピック: Oracle Tuxedo ATMIのアーキテクチャ
2.11 ロード・バランシングとは
ロード・バランシングとは、同じサービスを提供するサーバー間でサービス・リクエストを均等に分散するためにOracle Tuxedoシステムで使用される手法です。ロード・バランシングを行うと、過負荷になっているサーバーがある一方で、アイドル状態または使用頻度が低いサーバーがあるという状況を回避できます。Oracle Tuxedoシステムでは、リクエストがサービス・ルーチンに送信される前に、そのリクエストを処理できるすべてのサーバーが特定され、構成内のすべてのサーバー間で負荷を均衡化するために最適なサーバーが選択されます。
ロードとは、サービスの実行に必要な時間に基づいて、サービス・リクエストに割り当てられる数値です。サービスにロードが割り当てられることにより、Oracle Tuxedoはリクエスト間の関係を認識できます。構成内の各サーバーによって実行されている処理量(ロードの合計)を追跡するために、管理者はすべてのサービスおよびサービス・リクエストにロード・ファクタを割り当てます。ロード・ファクタとは、サービスまたはリクエストを実行するために必要な時間を示す数値です。これらの数値に基づいて、サーバーごとに統計が生成され、各マシンの掲示板で管理されます。各掲示板で各サーバーに関連する累積負荷が記録されているため、すべてのサーバーがビジー状態のとき、Oracle Tuxedoは最も負荷の軽いサーバーを選択できます。
ロード・バランシング・アルゴリズムをシステム全体に対して使用するかどうかを制御できます。たとえば、必要な場合にのみ、すなわちサービスを提供するサーバーが複数のキューを使用している場合にのみこのアルゴリズムを使用するように設定します。サービスを提供するサーバーが1つしかない場合や、複数サーバー、単一キュー(MSSQ)にある複数のサーバーがサービスを提供する場合は、ロード・バランシングを行う必要はありません。これらのサービスのLDBALパラメータは、Nに設定してください。それ以外の場合は、LDBALをYに設定できます。
UBBCONFIGのSERVICESセクションにある)ロード・ファクタの割当てを決定するには、アプリケーションを長時間実行し、各サービスの実行にかかる平均時間を記録します。平均値に近い時間がかかっているサービスに対しては、LOAD値に50 (LOAD=50)を割り当てます。平均値よりも長い時間がかかるサービスにはLOAD>50を指定し、平均値よりも短い時間で済むサービスにはLOAD<50を指定します。
図2-18 ロード・バランシング
親トピック: Oracle Tuxedo ATMIのアーキテクチャ
2.12 メッセージの優先度付けとは
優先度によって、サーバーによりサービス・リクエストがデキューされる順序が決まります。優先度は、クライアントによって個々のサービスに割り当てられます(値の範囲は1から100までで、100が最も高い優先度です)。
図2-19 メッセージの優先度付け
「スタベーション保護」メカニズムによって、優先度の低いメッセージがキューで永久に待機する状態が予防されます。10個目のメッセージは、優先度に関係なく先入れ先出し(FIFO)の順序でキューが取り出されますが、1から9番目までのメッセージは優先度の順番でキューから取り出されます。
親トピック: Oracle Tuxedo ATMIのアーキテクチャ
2.13 ネーミングとは
Oracle Tuxedoシステムは、サービス名、メッセージ・キュー名およびイベント名の3つのネーミング・デバイスを使用しています。名前には、ピリオド(.)で始まらない任意の単語または英数字文字列を使用できます。管理サーバーはOracle Tuxedoシステム・インフラストラクチャを使用するため、システムのリソースとアプリケーションのリソースを明確に区別する必要があります。
2.13.1 サービスのネーミング
サービスに名前が付けられると、アプリケーション・コンポーネントは別のコンポーネントを名前から見つけることができます。名前には、単純な語(depositなど)や英数字文字列(deposit2)を使用できます。名前は、アプリケーションのスコープや、アプリケーション・コンポーネント間の関係の全体図を示すマップに基づいて選択する必要があります。これらのマップまたはサービスは、アプリケーション・コンポーネントが記載された電話帳のページのようなものです。
TICKETなど)マシン名に変換するために必要な情報を、そのサービスを通知するサーバーのマシン名および物理アドレスに提供します。次にOracle Tuxedoシステムは、リクエストを適切なサーバーに送信します。
図2-20 名前によるサービスの検索
親トピック: ネーミングとは
2.13.2 イベントのネーミング
Oracle Tuxedoシステムには、パブリッシュ・アンド・サブスクライブ・メカニズムが備わっており、クライアントおよびサーバーは、特定のイベントが発生したときにアラート(メッセージ)を受信するための未処理のリクエストを動的に登録または登録解除できます。他のクライアントおよびサーバーは、アプリケーションでユーザー定義イベントまたはシステム・イベントが発生すると、それらのイベントをポストします。クライアントまたはサーバーが特定のイベントに関する通知を受ける必要がなくなった場合は、関連するサブスクリプションを取り消すことができます。
親トピック: ネーミングとは
2.14 クライアント/サーバー・アフィニティとは
クライアント/サーバー・アフィニティを使用すると、次の利点があります。
- アフィニティ・セッションの作成時に、リソース(データベース接続オブジェクトやハンドラなど)をユーザーのサーバー側コンテキストに挿入できます。
- 同じセッションに関連するリソースを結果のリクエスト内に保持できます。
Oracle Tuxedoのクライアント/サーバー・アフィニティには、単純なセッション対応アプリケーション・モデルを設定できる柔軟性があります。Oracle Tuxedo ATMI RPCインフラストラクチャを使用して、仮想リクエスト・ルーティング・スコープが作成されます。セッションが確立されると、そのセッションを(明示的または暗黙的に)終了するまで、後続のコールはすべてそのルーティング・スコープの影響を受けます。
2.14.1 UBBCONFIGファイルおよびTM_MIBファイルの構成
C/SAを開始するには、次の構成を行う必要があります。
- UBBCONFIG
*SERVICESセクション - TM_MIB
- T_SERVICEクラスの定義
- T_SVCGRPクラスの定義
2.14.1.1 クライアント/サーバー・アフィニティのUBBCONFIGの例
リスト2 クライアント/サーバー・アフィニティのUBBCONFIGの例
*SERVICES
SVCSTART SESSIONROLE=BEGIN AFFINITYSCOPE=SERVER AFFINITYSTRICT=MANDATORY
SVCSTOP SESSIONROLE=END詳細は、Oracle Tuxedoリファレンス・ガイドの『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のUBBCONFIG(5)およびTM_MIB(5)に関する項を参照してください。
関連項目