Oracle Tuxedo ATMIのアーキテクチャ
次の各項では、Oracle Tuxedo ATMI環境の基本的な構成要素について説明します。
Oracle Tuxedo ATMI環境の基本アーキテクチャ
図2-1は、Oracle Tuxedo ATMI環境の基本的な構成要素である、環境への外部インタフェース、ATMIレイヤー、MIB、Oracle Tuxedoシステム・サービス、および標準準拠リソース・マネージャとの環境内インタフェースを示しています。
この図に示されているように、Oracle Tuxedo ATMI環境は次のコンポーネントで構成されています。
|
|
|
アプリケーションとOracle Tuxedo ATMI環境の間のインタフェース。ATMIおよびOracle Tuxedo環境は、トランザクション処理を行うX/Open DTPモデルを実装します。抽象的な環境であるATMIは、場所の透過性をサポートしており、実装の詳細を隠蔽します。そのため、プログラマはアプリケーション・コードを変更せずに、Oracle Tuxedoアプリケーションを構成して複数のプラットフォームにデプロイできます。
|
|
クライアントとサーバー間のメッセージ転送に関する各種のモデル。Oracle Tuxedo ATMIメッセージング・パラダイムには、リクエスト/レスポンス、会話、キューイング、パブリッシュ・アンド・サブスクライブおよび非請求通知が含まれます。
|
|
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のAPIであるApplication-to-Transaction Monitor Interface (ATMI)は、データ・バッファの通信、トランザクションおよび管理を行うためのインタフェースであり、Oracle Tuxedoシステムでサポートされるすべての環境で動作します。それは、アプリケーション・プログラムとOracle Tuxedoシステムとを接続します。ATMIは、包括的な機能セットに対する簡易インタフェースです。トランザクション処理のX/Open DTPモデルを実装しています。
ATMIライブラリには、Oracle Tuxedo ATMIアプリケーションでグローバル・トランザクションを定義および制御するための各種の機能(ルーチンやverbなど)が含まれています。グローバル・トランザクションを使用すると、分散アプリケーションにおいて複数のプログラムおよびリソース・マネージャにわたる排他的な操作単位を管理できます。1つのトランザクション内のすべての操作は論理単位として扱われるため、タスクを正常に完了できないプログラムが1つでもあると、そのトランザクション内ではいずれの操作もプログラムにより実行されません。
ATMI関数は、分散されたプログラム間でデータを送受信できるようにすることで、これらのプログラムを互いに結び付けます。すべてのATMI関数は、
型付きバッファ内でデータを送受信します。
表2-1に、CおよびCOBOLのバインディング用のATMI関数と、それにより実行されるタスクをリストします。関数はタスクごとに分類されています。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
サービスへの同期リクエスト/レスポンスを開始します。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
イベント・メッセージのサブスクリプションを削除します。
|
|
|
|
|
|
|
|
|
|
|
|
|
トランザクション・モードであるかどうかを確認します。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意:
|
Oracle Tuxedo ATMIトランザクション管理関数の使用は、オプションです。Oracle Tuxedoでは X/Open TXトランザクション管理関数もサポートされているため、トランザクション管理にこれらの関数を使用することもできます。
|
Oracle Tuxedo ATMIのメッセージング・パラダイムとは
Oracle Tuxedo ATMIは、アプリケーションのサーバー・プロセスの管理やトランザクションの管理に加えて、クライアント/サーバー通信も管理します(つまり、クライアント(およびサーバー)は、次の表に示されているメッセージング・パラダイムのいずれかを使用して、アプリケーション・サービスを起動できます)。
Oracle Tuxedo ATMIのメッセージング・パラダイム
|
|
|
クライアントから1つのリクエストが発行され、コールされたリクエスト/レスポンス型サーバーからの1つのレスポンスが返される、単純なタイプのダイアログ。通常、リクエスト/レスポンス型トランザクションでは人間が関与するため、即時の反応が要求され、高優先度モードで実行されます。
|
|
クライアントとコールされた会話サーバーの間の状態が保持される接続(メッセージからメッセージへコンテキストが保持されます)。会話トランザクションでも通常は人間が関与するため、即時の反応が要求され、高優先度モードで実行されます。
|
|
クライアントとサーバー間の時間に依存しない通信。キューに入れられたトランザクションは、優先度の高いまたは低いメッセージとして実行できます。Oracle Tuxedoシステムには、 /Qというリカバリ可能なキューの独自バージョンがバンドルされています。
|
|
Oracle Tuxedo ATMIアプリケーションのクライアントとサーバー間での イベントの非同期ルーティング。パブリッシュ・アンド・サブスクライブ・トランザクションは通常、優先度の高いメッセージとして実行されます。Oracle Tuxedoシステムには、 イベント・ブローカというトランザクション対応パブリッシュ・アンド・サブスクライブ・システムが備わっています。
|
|
クライアントまたはサーバーからクライアントへの通信で、受信側のクライアントによりリクエストも予測もされていなかったもの。非請求通知は、イベント・ブローカによって処理されます。
|
ATMIクライアントとサーバーの間のリクエスト/レスポンス型通信を実装するために、Oracle Tuxedoシステムではプロセス間通信(IPC)メッセージ・キューを使用しています。キューは、コネクションレス通信にの重要な要素です。各サーバーにはリクエスト・キューと呼ばれるIPCメッセージ・キューが割り当てられ、各クライアントにはレスポンス・キューが割り当てられます。このため、クライアント・アプリケーションは、サーバーとの接続を確立して維持するかわりに、リクエストをサーバーのキューに登録してリクエストをサーバーに送信し、その後でアプリケーションのレスポンス・キューからメッセージを取り出すことにより、サーバーからのメッセージを確認して取得できます。
リクエスト/レスポンス型モデルは、同期サービス・リクエストと非同期サービス・リクエストの両方に使用されます。
同期コールでは、クライアントがサーバーにリクエストを送信し、クライアントが待機している間にサーバーがリクエストされたアクションを実行します。その後、サーバーがクライアントに応答を送信し、クライアントが応答を受信します。
図2-3は、同期リクエスト/レスポンス型通信を示しています。
非同期コールでは、Oracle Tuxedo
クライアントは、発行したサービス・リクエストの処理完了を待機せずに、他のタスクを開始します。クライアントはリクエストの発行後も、追加のタスク(他のリクエストの発行など)を実行します。最初のリクエストへの応答が使用可能になると、クライアントはその応答を取得します。
図2-4は、非同期リクエスト/レスポンス型通信を示しています。
会話型通信はOracle Tuxedoシステムのメッセージ交換のパラダイムで、人の会話に似た通信がATMIクライアントとサーバー間で実装されています。この通信方法では、クライアントとサーバー間で仮想接続が維持されます。2人の人間で会話する場合と同じように、結論に達するまで多数のメッセージが2つのエンティティの間でやり取りされます。通信が行われている間、両者が会話のポイント(または状態)を記録しているため、比較的長い操作(非定型問合せ、レポート、ファイル転送など)をサポートできます。デフォルトで会話サーバーは使用可能ですが、必要に応じて追加のサーバーを自動生成することもできます。
Oracle Tuxedoシステムには、アプリケーションでの会話の作成に使用できるAPIが用意されているため、これを使用してクライアントをサーバーに接続し、メッセージを送受信し、会話を終了できます。
会話はネストできますが、ネストするとパフォーマンスが低下することがあります。会話にはトランザクションまたはサービス・リクエストのうち適切なほうが含まれます。会話型サービスはサービス・コールを行って会話を確立できますが、これらのサービス・コールおよび会話を転送することはできません。会話はトランザクションのスコープ内に設定し、トランザクションによって制御することができます。
Oracle Tuxedoシステムでは、データの永続ストレージを必要とするATMIアプリケーションに対して使用できる、
/Qと呼ばれるキューベースのアーキテクチャが提供されています。/Qコンポーネントを使用すると、どのクライアントまたはサーバーもメッセージまたはサービス・リクエストをキューに格納でき、格納されたリクエストは必ずトランザクション・プロトコルを介して送信されるため、安全なストレージが保証されます。
Oracle Tuxedoシステムのキューは、
後入れ先出し(LIFO)または
先入れ先出し(FIFO)、あるいは時刻や優先度に基づいて順序付けすることができます。キューの集まりは、キュー・スペースと呼ばれる1つのエンティティとして管理され、参照されます。
図2-6は、キューベースのメッセージングを示しています。
アプリケーション・キューは、時間に依存しない通信を行う必要がある場合に適しています。時間に依存しない通信では、プログラムが互いに独立して動作し、互いの通信を同期する必要がないことが特徴です。時間に依存しないプログラムでは、互いにメッセージをアプリケーション・キューに残すことによって同期を取ります。メッセージは、FIFO、優先度、時刻順などの順序付けスキームでデキューできます。Oracle Tuxedoのクライアント・プログラムおよびサーバー・プログラムは、メッセージをエンキューし、キューからメッセージをデキューできます。複数のクライアントおよびサーバーが同じキューにアクセスできます。
アプリケーション・キューを使用するには、プログラムで、アクセスされるキューと、そのキューが含まれるキュー・スペースに名前を付ける必要があります。アプリケーションでは複数のキュー・スペースを使用でき、各スペースには複数のメッセージ・キューを含めることができます。
アプリケーション・キューはディスク上に存在するため、格納されたメッセージは、マシンに障害が発生した場合でも使用できます。どのような場合にアプリケーション・キューを使用するかは、業務(注文書の入力など)で時間に依存しない同期をいつ行うかによって判断する必要があります。注文書はディスクにエンキューし、品目や出荷場所などの特定の注文条件に基づいて、異なるキュー・スペースに入れることができます。各キュー・スペース内に、コストや状態などの追加の条件を指定することもできます。
Oracle Tuxedoのパブリッシュ・アンド・サブスクライブ・コンポーネントは
イベント・ブローカと呼ばれ、任意の数のサプライヤが任意の数のサブスクライバにメッセージをポストできる通信パラダイムを提供します。イベント・ブローカを使用するATMIクライアント・プロセスおよびサーバー・プロセスは、
サブスクリプションのセットに基づいて相互通信を行います。イベント・ブローカは、購読料を支払っている顧客にのみ新聞を配達する新聞配達員のような役割を果たします。
図2-7は、イベントのポストとサブスクライブを示しています。
イベントの発信元(クライアントまたはサーバー)は、変更や問題が発生すると、イベント・ブローカにそれを通知します。このプロセスは、イベントのポストと呼ばれます。イベント・ブローカは、イベントの名前をサブスクライバのリストと関連付けられているイベント名と照合し、リスト内の各サブスクライバにそのイベントを通知します。
Oracle Tuxedoシステムでは、2種類のイベント・レポートをサポートしています。
•
|
アプリケーション定義のイベント・レポート: アプリケーション・プログラムは、特定の基準が満たされた場合に、イベントをポストできます。たとえば、銀行取引アプリケーションの場合、一定額を超える引出しが行われるとイベントがポストされます。
|
•
|
システム・イベント・レポート: サーバーやネットワークの障害など、Oracle Tuxedoシステム・イベントに関する詳細を提供します。クライアントまたはサーバーによってイベントがポストされると、イベント・ブローカはポストされたイベントの名前をそのイベントのサブスクライバと照合し、各サブスクリプションで指定されている適切なアクションを実行します。
|
プロセスは、イベント・ブローカにサブスクリプションを登録し、特定のイベントに関心があることを示します。以降は、指定されたイベントが発生したことが別のプロセスから通知されると、イベント・ブローカが、そのイベントに対してサブスクライブしているすべてのプロセスにイベントの発生を報告します。
図2-8は、イベントベースのメッセージングを示しています。
イベント・ブローカは、次のメカニズムを使用してイベントの公開(イベント通知の発行)を行います。
Oracle Tuxedoシステムには、非請求通知と呼ばれる強力な通信パラダイムがあります。非請求通知が発生すると、ATMIクライアントは、リクエストしていないメッセージを受け取ります。イベント・ブローカにより管理されるこの機能を使用すると、アプリケーション・クライアントは、アプリケーション固有のイベントが発生したときに、リアルタイムで明示的に通知をリクエストしなくても、そのイベントの通知を受け取ることができます。
非請求メッセージは、名前(
tpbroadcast)によって送信されるか、以前に処理されたメッセージとともに受け取られた識別子(
tpnotify)によって送信されます。
tpbroadcastを使用すると、メッセージをサービスまたは別のクライアントから送信できます。送信先は、狭い範囲にも広い範囲にもできます。
ポイントツーポイントの通知によって配信保証付きまたは配信保証なしのメッセージを個々のクライアントに送信したり(
tpnotify)、クライアントのグループに対して情報を送信することができます(
tpbroadcast)。たとえば、サーバーは、クライアントから照会された口座が解約されていることをそのクライアントのみに通知できます。あるいは、あるマシンがメンテナンスのために特定の時刻に停止されるというメッセージを、そのマシン上のすべてのクライアントに送信することもできます。
図2-9は、非請求通知のメッセージングを示しています。
特定のイベント(マシンをメンテナンスのために停止するなど)について通知を受ける必要のあるプロセスは、自動的に通知を受けるためのリクエストをシステムに
登録できます。登録後は、指定したイベントが発生するたびにクライアントまたはサーバーに通知されます。イベントに関するこのような自動通信は、
非請求通知と呼ばれます。
イベントを生成したり、このようなイベントに関する非請求通知を受信するクライアントおよびサーバーの数に制限はないため、このカテゴリの通信に対する管理タスクは複雑になる場合があります。
ネストおよび転送されたサービス・リクエストを使用すると、Oracle Tuxedo
サービスはATMIクライアントとして機能し、他のサービスをコールできます。
ネストは特に3層のクライアント/サーバー・アーキテクチャ、すなわちプレゼンテーション・ロジック・レイヤー、ビジネス・ロジック・レイヤーおよびデータベース・レイヤーから構成されるシステムで特に有用です。このようなシステムでは、プレゼンテーション・レイヤーによってデータベースへの1つ以上の問合せに関連する特定のビジネス関数のリクエストが構成されます。
図2-10は、ネストされたリクエストを示しています。
ネストされたリクエストを使用するメリットの1つは、各コード部分が限定されたタスクのみを行うので、コードが少なくて済み、再利用も可能であることです。ただし、システムのサービスが複数のサーバーに分散されている場合は、リクエストをネストするとパフォーマンスが低下することがあります。ネストされたリクエストが処理されている間、元のサービス(ネストされたリクエストを発行したサービス)は、続行前にレスポンスを待機する必要があります。レスポンスを受信するまで、元のサービスは別のリクエストを処理できません。そのため、このサービスが存在するサーバーのリクエスト・キュー内にメッセージをバックアップできます。
ある顧客が現金自動預入支払機を使用して普通預金口座から当座預金口座に預金を振り替えます。預金の振替えに必要な処理は、Oracle Tuxedoアプリケーションによって実行されます。まず、顧客にかわって、クライアントが
TRANSFERというサービスへのリクエストを発行すると、そのリクエストがそのサービスを提供するサーバーのキューに入れられます。次に、
TRANSFERサービスが他の2つのサービス(
WITHDRAWおよび
DEPOSIT)をリクエストすると、2番目のサーバーによってこれらのサービスが処理されます。
WITHDRAWサービスおよび
DEPOSITサービスは、
TRANSFERサービスにレスポンスを返します。最後に、
TRANSFERがレスポンスをクライアントのレスポンス・キューに送信します。クライアントがレスポンスをキューから取り出すと、現金自動預入支払機の画面に振替えが完了したことを通知するメッセージが表示されます。
サービス・リクエストのネストにかわる方法として、リクエストの転送と呼ばれる方法があります。サービスは、クライアントのリクエストを処理せずに、別のサービスに渡すことができます。2番目のサービスも、リクエストを処理するか、別のサービスに渡すことができます。
図2-11は、転送されたサービス・リクエストを示しています。
リクエストを転送できる回数に制限はありません。リクエストを転送したサービスは、リクエストを受信したサービスからの応答を待機する必要がないため、リクエストのネストとは異なり、転送ではサーバーがブロックされることはありません。ただし、転送はX/OpenプロトコルX/ATMIでサポートされていないため、アプリケーションによっては支障が出る場合があります。
Oracle Tuxedo ATMI環境内のすべての通信は、メッセージを転送することによって行われます。Oracle Tuxedoシステムでは、オペレーティング・システム(OS)のプロセス間通信(IPC)メッセージ・キューを介してATMIクライアントとサーバー間でサービス・リクエスト・メッセージの受渡しをします。システム・メッセージおよびデータは、
バッファ内の、OSでサポートされているメモリーベースのクライアントおよびサーバーのキューの間で受渡しされます。Oracle Tuxedo ATMI環境においては、メッセージは
型付きバッファにパッケージ化され、このバッファには、メッセージ・データと、送信されたメッセージ・データのタイプを識別するデータが両方含まれます。
クライアントは、ATMI 関数を使用してサービスを名前でリクエストします。指定されたサービスが現在使用可能かどうかは、
ネーミング機能を使用してMIBを確認することにより判断されます。
Oracle Tuxedoシステムでは、特定の基準(メッセージの値)を満たすメッセージを特定のサーバーにマップする自動ルーティング・オプションである
データ依存型ルーティングが使用されます。メッセージにデータ依存型ルーティングが使用される場合、ルーティング・アルゴリズムに基づいてバッファ内のデータが使用されます。このアルゴリズムでは、サービス・リクエストを処理できるサーバーのグループを選択できます。
一部のサーバーに多数のリクエストが集中し、同じサービスを通知している他のサーバーがアイドル状態になることを回避するために、Oracle Tuxedoシステムではサービス・リクエストをすべてのサーバー間で均等に分散するためにMIBを使用しています。この方法は
ロード・バランシングと呼ばれます。
選択したサーバーに対してローカルのサービス・リクエストが準備され、事前定義済の優先度でそのサーバーのキューにリクエストがエンキューされることがあります。この方法は
サービスの優先度付けと呼ばれます。サービス・リクエストがサーバーに到達すると、ランタイム・システムによってメッセージが優先度に基づいて取得されます。メッセージは、適切なサービスにディスパッチされて、処理されます。その後、結果がクライアント・キューに返されます。
Oracle Tuxedoシステムで提供されるソフトウェアには、メッセージ処理の際にアプリケーションが自動的かつ定期的に使用できる機能が備わっています。これらの機能には、データのエンコーディングとデコーディング、データの圧縮と解凍、トランザクション・コンテキストの設定、セキュリティ処理などがあります。さらに、Oracle Tuxedoシステム・ソフトウェアは、サービス関数をディスパッチして、適切に前処理されたバッファにそれを渡すことにより、アプリケーションのビジネス・ロジックを起動します。
サービス・ルーチンが実行され、応答(型付きバッファ)が返されます。ランタイム・システムは、メッセージを自動的にエンコードすることによって、クライアントへの応答を準備します: 異なるタイプのバイト順序を使用しているマシン間で転送できるようにデータをパッケージ化して、ネットワークやプラットフォームの境界を越えてデータを転送できるようにします。続いて、メッセージをクライアントに送信します。このプロセスは
データのエンコーディングと呼ばれます。クライアント上のランタイム・システムは、応答メッセージを取得し、必要に応じてデコードした後、フィールド操作言語(FML)バッファ(またはほかのメッセージ・バッファ・タイプのバッファ)を送信してアプリケーション・データをパッケージ化します。必要に応じて、タイプの検証、エンコーディング、ルーティングおよびロード・バランシングが行われます。サービス・リクエストは、同期でも非同期でも実行できます。
リモート・リクエストは、ローカル・ブリッジを通過してリモート・マシンに到達します(ここでは、リモート・ブリッジがクライアントとして動作し、クライアントとサーバーが同じマシン上にあるかのようにリクエストが処理されます)。ブリッジは、標準のデータ・エンコーディングまたはデコーディングを提供し、標準のネットワーク・トランスポートを使用して通信します。クライアントとサーバーからは、ブリッジは通常のローカル・サーバーのように見えます。
サービス・リクエスト処理には次のようなメリットがあります。
•
|
コネクションレス型の処理: この処理をクライアント/サーバー型のダイレクト通信と組み合せると、接続の確立に伴うオーバーヘッドを削減できます。
|
•
|
ネットワーク・トラフィックの削減: サービス・リクエストは、複雑なサービスがあればそれをリモート・マシン上で起動し、必要な最小限のデータのみを送信し、最小限の結果を受信します。
|
すべてのATMI関数は、型付きバッファを使用してデータを送受信します。Oracle Tuxedoシステムでは、異種のマシン間での変換とデータ変換を処理します。Oracle Tuxedoプログラムは、バッファを使用することで、データ表現の異なる異種のプラットフォーム間でやり取りされるデータを変換する必要性をなくしています。
バッファとは、データの論理的なコンテナとして機能するメモリー領域のことです。メタデータ(それ自身に関する情報)が含まれていないバッファは、
型なしバッファです。メタデータ(イプとサブタイプ、またはバッファを特徴付ける文字列名など、バッファに格納できる情報)が含まれるバッファは、
型付きバッファです。
型付きバッファは、Oracle Tuxedoシステムでサポートされる任意のプロトコルを使用して、任意のネットワークを任意のオペレーティング・システムに転送できます。また、データ表現の異なる複数のプラットフォーム上でも使用できます。このため、型付きバッファを使用すると、異種のマシン間での変換およびデータ変換のタスクが容易になります。
Oracle Tuxedoシステムでは、次の5種類の型付きバッファがサポートされています。
バッファ・タイプは、Oracle Tuxedo (
UBBCONFIG)構成ファイルの
MACHINESセクションに定義された
ENVFILEパラメータで割り当てます。Oracle Tuxedo構成ファイルの
SERVERSセクション内の
ENVFILEパラメータでバッファ・タイプの割当てまたはオーバーライドを行うと、それらのバッファ・タイプを必要とするプロセスでそれらを使用できなくなることがあります。
各種のメッセージ・バッファの定義については、
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の
tuxtypes(5)で
tm_typeswの説明を参照してください。
ATMI通信関数を使用する場合、アプリケーションは最初に
tpallocを使用して、バッファのサイズ、タイプおよびサブタイプ(オプション)を指定して、システムからバッファを取得する必要があります。Oracle Tuxedoシステムではバッファ・タイプが認識されて処理されるため、データはOracle Tuxedoシステムでサポートされるあらゆるタイプのネットワーク、プロトコルおよびオペレーティング・システム上で転送されます。様々なタイプのOracle Tuxedoバッファの詳細は、
Cを使用したOracle Tuxedo ATMIアプリケーションのプログラミングの型付きバッファの管理に関する項を参照してください。
データ圧縮は、ネットワーク上またはリモート・ドメインへの転送を高速化するために、アプリケーション・バッファを縮小するプロセスです。アプリケーション・バッファに最大サイズを設定することで、指定したサイズ以上のアプリケーション・バッファは自動的に圧縮されるように設定できます。バッファが宛先に到達すると、そのデータは解凍され、元のサイズに戻ります。
マシン間でファイルを送付する前にデータ圧縮を行うと、ネットワークのパフォーマンスが向上します。圧縮のプロセスでデータのスクランブリングも行われるので、セキュリティも若干強化されます。
Oracle Tuxedoシステムでは、クライアントが同じサービスに対するリクエストをそのサービスの複数のコピーに送信できるように、データ依存型ルーティングと呼ばれる操作を使用します。サービスのどのコピーが最終的にリクエストを受け入れて処理するかは、リクエスト・メッセージ内のデータによって決まります。管理者がアプリケーションにデータ依存型ルーティングを設定すると、クライアント・リクエストはリクエスト内のデータに基づいて自動的にサーバーにルーティングされます。
百科事典の第1巻にAで始まるエントリが含まれているのと同じように、1つのアプリケーションに同じサービスのコピーが複数含まれる場合、各コピーに対して固有の目的が割り当てられます。すべてのサービス・コピーのリストが、各コピーの目的を識別する情報とともに、Oracle Tuxedoの掲示板(MIBの動的な部分)のルーティング表のセットに保持されています。システムはクライアント・リクエストを受け取ると、リクエスト・メッセージ内の識別文字列を読み取り、その文字列を掲示板のルーティング表で検索します。この一致に基づいて、クライアント・リクエストの転送先の適切なサーバーが特定されます。
注意:
|
掲示板のルーティング表は、必要に応じて変更できます。
|
データ依存型ルーティングは、クライアントが次のものにサービスをリクエストした場合に有用です。
水平分離型データベースとは、セグメントに分割された情報リポジトリであり、各セグメントに異なるカテゴリの情報が格納されます。これは、図書館で各本棚に異なるカテゴリ(伝記、フィクションなど)の本が収納されているのと似ています。
ルール・ベース・サーバーとは、サービス・リクエストをサービス・ルーチンに転送する前に、サービス・リクエストが特定のアプリケーション固有の条件を満たしているかどうかを判定するサーバーです。ルール・ベース・サーバーは、ほとんど同じ複数のリクエストに対して、ビジネス上の理由で多少異なる処理を行う場合に使用すると有用です。
分散アプリケーションとは、1つ以上のローカル・クライアントまたはリモート・クライアントが、ネットワークで接続された複数のマシン上の1つ以上のサーバーと通信するアプリケーションのことです。クライアント(またはクライアントとして動作するサーバー)は、特定のサービスに対するリクエストを発行します。リクエストの
アドレスは、そのリクエストを処理できるサーバーを識別するデータ(リクエストと同じバッファ内で送信される)によって決まります。複数のサーバーがこれを実行できることもあります。Oracle Tuxedoシステムは、掲示板に提供されているルーティング基準とデータを照合することで、リクエストを受け取るサーバーを選択します。
水平分離型データベースでのデータ依存型ルーティングの例
銀行取引アプリケーションで2つのクライアントが口座3と口座17という2つの口座の現在の残高を照会するリクエストを発行したとします。アプリケーションでデータ依存型ルーティングが使用されている場合、Oracle Tuxedoシステムでは次の処理が行われます。
1.
|
2つのサービス・リクエストで指定された口座番号(3と17)を取得します。
|
2.
|
どのサーバーがどのデータ範囲の処理を行うかを示す、Oracle Tuxedoの掲示板のルーティング表を確認します。(この例では、サーバー1が口座1から10のすべてのリクエストを処理し、サーバー2が口座11から20のすべてのリクエストを処理します。)
|
3.
|
それぞれのリクエストを該当するサーバーに送信します。つまり、口座3へのリクエストをサーバー1に転送し、口座17へのリクエストをサーバー2に転送します。
|
ルール・ベース・サーバーでのデータ依存型ルーティングの例
次の規則を持つ銀行取引アプリケーションがあるとします。
•
|
顧客は、特別なパスワードを入力しなくても、$500まで引き出すことができます。
|
•
|
$500を超える額を引き出すには、特別なパスワードを入力する必要があります。
|
2つのクライアントが$100と$800の引出しのリクエストを発行したとします。引出しのルールをサポートするようにデータ依存型ルーティングが有効になっている場合、Oracle Tuxedoでは次のような処理が行われます。
1.
|
2つのサービス・リクエストで指定された引出し額($100と$800)を取得します。
|
2.
|
リクエストされた金額がどのサーバーにより処理されるかを示す、Oracle Tuxedoの掲示板のルーティング表を確認します。(この例では、$500までのすべての引出しリクエストはサーバー1により処理され、$500を超えるすべての引出しリクエストはサーバー2により処理されます。)
|
3.
|
それぞれのリクエストを該当するサーバーに送信します。つまり、$100のリクエストをサーバー1に転送し、$800のリクエストをサーバー2に転送します。
|
分散アプリケーションでのデータ依存型ルーティングの例
図2-16に、分散アプリケーションでクライアント・リクエストがサーバーにルーティングされる様子を示します。この例では、
bankappという銀行取引アプリケーションはデーた依存型ルーティングを使用しています。
bankappには3つのサーバー・グループ(
BANK1、
BANK2、および
BANK3)と2つのルーティング基準(
Account IDおよび
Branch ID)が含まれます。
WITHDRAW、
DEPOSIT、および
INQUIRYサービスは、
Account_IDフィールドを使用してルーティングされます。
OPENおよび
CLOSEサービスは、
Branch_IDフィールドを使用してルーティングされます。
前の図では、リクエストは次の表に示すようにルーティングされます。
|
|
支店1 - 4の口座番号10000 - 49999
|
|
支店5 - 7の口座番号50000 - 79999
|
|
支店8 - 10の口座番号80000 - 109999
|
|
エンコーディングおよび
デコーディングを行うと、データ表現(バイトの順序や文字セットなど)が異なるメッセージをマシン間で転送できるようになります。Oracle Tuxedoシステムは、Oracle Tuxedoアプリケーションに関与する他のマシンに転送できるように、データをマシンに依存しない表現にエンコードおよびデコードします。
Oracle Tuxedoシステムは、デフォルトで外部データ表現(XDR)アルゴリズムを採用していますが、このアルゴリズムはOracle Tuxedoシステム関数をユーザー記述関数で置き換えることによってカスタマイズできます。エンコーディングおよびデコーディングは、マシン間でのみ、またリモート・マシンで使用されるデータ表現がローカル・マシンで使用されているデータ表現と異なる場合にのみ使用されます。エンコーディングおよびデコーディングを行うと、異なるデータ・アーキテクチャを持つマシンが異種のOracle Tuxedoシステムで動作できます。プログラマは、それぞれの環境に適した表現でデータを管理できます。
Oracle Tuxedoシステムは、バッファ・タイプを使用して、メッセージに含まれているフィールドのタイプを判別し、コーディング作業に必要なマッピングを実行します。このマッピングは、
X_OCTETや
CARRAYなどの非構造化バッファ・タイプによって実行されるものではありません。このため、
X_OCTETおよび
CARRAYバッファを使用する開発者は、異種のマシンが混在する環境で自由にデプロイを実行できます。
暗号化は、メッセージをコード化された形式に変換して、メッセージの送信先のユーザー以外のユーザーには解読できないようにする処理です。暗号化されたメッセージは、送信先に到着すると復号化され、元の形式に変換されます。
暗号化によってデータのビット数が増えることはありませんが、メッセージ送信の処理時間は増えます。ただし、暗号化によってデータが圧縮されるため、ネットワーク上を送信されるデータ量が減少し、処理時間の増加がその分相殺されることもあります。また、データが圧縮されるときに多少のスクランブリングが行われるため、セキュリティも若干強化されます。
ロード・バランシングとは、同じサービスを提供するサーバー間でサービス・リクエストを均等に分散するために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は、ロード・バランシングを示しています。
優先度によって、サーバーによりサービス・リクエストがデキューされる順序が決まります。優先度は、クライアントによって個々のサービスに割り当てられます(値の範囲は1から100までで、100が最も高い優先度です)。
すべてのサービスに、優先度の初期値として50が割り当てられます。サーバーの優先度の初期値は、アプリケーションの構成時に変更できます。サービスのセットを定義した後、それらのサービスに適切な優先度を割り当てることができます。たとえば、業務上の優先度が比較的高いサービスに70を設定すると、これらのサービスはそれより低い優先度50のサービスよりも先にデキューされます。次の図では、サーバーはサービスA(優先度50)、B(優先度50)およびC(優先度70)を提供しています。
図2-19は、メッセージの優先度付けを示しています。
サービスCは優先度が高いため、サービスCのリクエストは常にAまたはBよりも先にデキューされます。AとBに対するリクエストは優先度が同じです。この機能は、アプリケーション内でリクエストの緊急度や重要度に差がある場合に使用すると有用です。
「スタベーション保護」メカニズムによって、優先度の低いメッセージがキューで永久に待機する状態が予防されます。10個目のメッセージは、優先度に関係なく
先入れ先出し(FIFO)の順序でキューが取り出されますが、1から9番目までのメッセージは優先度の順番でキューから取り出されます。
Oracle Tuxedoシステムは、サービス名、メッセージ・キュー名およびイベント名の3つのネーミング・デバイスを使用しています。名前には、ピリオド(.)で始まらない任意の単語または英数字文字列を使用できます。管理サーバーはOracle Tuxedoシステム・インフラストラクチャを使用するため、システムのリソースとアプリケーションのリソースを明確に区別する必要があります。
サービスに名前が付けられると、アプリケーション・コンポーネントは別のコンポーネントを名前から見つけることができます。名前には、単純な語(depositなど)や英数字文字列(deposit2)を使用できます。名前は、アプリケーションのスコープや、アプリケーション・コンポーネント間の関係の全体図を示すマップに基づいて選択する必要があります。これらのマップまたはサービスは、アプリケーション・コンポーネントが記載された電話帳のページのようなものです。
Oracle Tuxedoシステム・サーバーがアクティブになると、掲示板にそのサービスの名前が通知されます。サービス名は、リクエストをサーバーにルーティングできるように、そのサーバーの物理アドレスと関連付けられています。プログラマがアプリケーションで使用する名前は、完全に場所の透過性があります。クライアント・プログラムがサービスを名前で要求すると、Oracle Tuxedoシステムは掲示板でその名前レジストリを調べます。名前レジストリは、文字列の名前(
TICKETなど)マシン名に変換するために必要な情報を、そのサービスを通知するサーバーのマシン名および物理アドレスに提供します。次にOracle Tuxedoシステムは、リクエストを適切なサーバーに送信します。
図2-20は、名前によるサービスの検索を示しています。
Oracle Tuxedoシステムには、パブリッシュ・アンド・サブスクライブ・メカニズムが備わっており、クライアントおよびサーバーは、特定のイベントが発生したときにアラート(メッセージ)を受信するための未処理のリクエストを動的に登録または登録解除できます。他のクライアントおよびサーバーは、アプリケーションでユーザー定義イベントまたはシステム・イベントが発生すると、それらのイベントをポストします。クライアントまたはサーバーが特定のイベントに関する通知を受ける必要がなくなった場合は、関連するサブスクリプションを取り消すことができます。
クライアント/サーバー・アフィニティを使用すると、次の利点があります。
•
|
アフィニティ・セッションの作成時に、リソース(データベース接続オブジェクトやハンドラなど)をユーザーのサーバー側コンテキストに挿入できます。
|
•
|
同じセッションに関連するリソースを結果のリクエスト内に保持できます。
|
Oracle Tuxedoのクライアント/サーバー・アフィニティには、単純なセッション対応アプリケーション・モデルを設定できる柔軟性があります。Oracle Tuxedo ATMI RPCインフラストラクチャを使用して、仮想リクエスト・ルーティング・スコープが作成されます。セッションが確立されると、そのセッションを(明示的または暗黙的に)終了するまで、後続のコールはすべてそのルーティング・スコープの影響を受けます。
UBBCONFIGファイルおよびTM_MIBファイルの構成
C/SAを開始するには、次の構成を行う必要があります。
クライアント/サーバー・アフィニティのUBBCONFIGの例
リスト2に、クライアント/サーバー・アフィニティのUBBCONFIGの例を示します。
リスト2
クライアント/サーバー・アフィニティのUBBCONFIGの例
*SERVICES
SVCSTART SESSIONROLE=BEGIN AFFINITYSCOPE=SERVER AFFINITYSTRICT=MANDATORY
SVCSTOP SESSIONROLE=END