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