Oracle Tuxedo分散アプリケーションのプログラミング
分散アプリケーションは、複数のハードウェア・システム上にあるソフトウェア・モジュールから構成され、これらのモジュールが互いに通信してアプリケーションの必要なタスクが実行されます。たとえば、
図1-1に示すリモート・オンライン銀行業務システムの分散アプリケーションは、顧客のホーム・コンピュータで実行されるソフトウェア・モジュールと、すべての口座レコードを管理する銀行のコンピュータ・システムから構成されています。
たとえば、ログオンしてメニューからオプションを選択するだけで、残高を照会できます。この処理では、ローカル・ソフトウェア・モジュールが特別なアプリケーション・プログラミング・インタフェース(API)関数を使用して、リモート・ソフトウェア・モジュールと通信しています。
ATMIを使用すると、以下の操作を行うことができます。
•
|
クライアントとサーバー間でのメッセージのやり取り。ネットワークを介して異機種マシン間でやり取りすることも可能です。
|
•
|
クライアントの名前付けおよびセキュリティ機能の設定と使用。
|
•
|
複数の場所に格納されているデータを処理するトランザクションの定義と管理。
|
•
|
データベース管理システム(DBMS)などのリソース・マネージャのオープンとクローズ。
|
•
|
サービス・リクエストのフロー管理、およびサービス・リクエストを処理するサーバーの可用性の管理。
|
表1-1は、アプリケーション開発者が使用できるOracle Tuxedo ATMIの通信パラダイムを示しています。
|
|
|
リクエスト/レスポンス型通信では、あるソフトウェア・モジュールが2番目のソフトウェア・モジュールにリクエストを送り、そのレスポンスを受け取ります。リクエスタがレスポンスを受け取るまで処理が行われずに待機する同期通信、またはリクエスタがレスポンスを待機する間も処理が継続される非同期通信の2種類があります。
このモードは、クライアント/サーバー相互作用とも呼ばれます。最初のソフトウェア・モジュールがクライアント、2番目のソフトウェア・モジュールがサーバーになります。
|
|
会話型通信はリクエスト/レンポンス型通信に似ていますが、会話が終了する前に複数のリクエストやレンポンスが発生します。会話型通信では、会話が切断されるまでクライアントとサーバーで状態の情報が保持されます。クライアントとサーバー間でメッセージをやり取りする方法は、使用するアプリケーション・プロトコルによって決定されます。
通常、会話型通信はサーバーからクライアントへの長いレスポンスのバッファとして使用されます。
|
|
アプリケーション・キュー・ベースの通信では、遅延通信、つまり時間に依存しない通信が行われます。この通信では、クライアントとサーバーがアプリケーション・キューを使用して通信します。Oracle Tuxedo/Q機能を使用すると、メッセージを永続的な記憶装置(ディスク)や一時的な記憶装置(メモリー)のキューに入れることができ、後で処理したり取り出すことができます。
アプリケーション・キュー・ベースの通信は、たとえば、メンテナンスのためにシステムをオフラインにしたときにリクエストをキューに登録する場合や、クライアントとサーバーの処理速度が異なる場合に通信をバッファに格納する場合に使用します。
/Q機能の詳細は、『ATMI /Qコンポーネントの使用』 を参照してください。
|
|
イベント・ベースの通信では、特別な状況(イベント)が発生した場合に、クライアントやサーバーがそれをクライアントに通知します。
•
|
非請求イベント。クライアントやサーバーからクライアントに直接通知される予測不能な状況です。
|
•
|
ブローカ・イベントとは、予測不能な状況、または発生は予測できても発生時間を予測できない状況で、メッセージの受信と転送を行う無名ブローカ・プログラムによって、サーバーからクライアントに間接的に通知されます。
|
イベント・ベースの通信は、Oracle Tuxedoのイベント・ブローカ機能に基づいています。
|
Oracle Tuxedo ATMI
クライアントとは、ユーザーのリクエストを収集し、そのリクエストに対するサービスを提供するサーバーにそのリクエストを転送するソフトウェア・モジュールです。ほとんどのソフトウェア・モジュールは、ATMIクライアント初期化ルーチンを呼び出して、Oracle Tuxedoアプリケーションに
参加することで、Oracle Tuxedoクライアントとして動作できます。クライアントになると、メッセージ・バッファを割り当てて、サーバーと情報を交換できるようになります。
クライアントは、ATMI終了ルーチンを呼び出してアプリケーションから
分離し、Oracle Tuxedoシステムにクライアントを追跡する必要がなくなったことを通知します。これにより、他の操作でOracle Tuxedoアプリケーションのリソースを使用できるようになります。
次は、基本的なクライアント・プロセスの処理を示す擬似コードです。
リスト1-1
リクエスト/レスポンス型クライアントの擬似コード
main()
{
allocate a TPINIT buffer
place initial client identification in buffer
enroll as a client of the BEA Tuxedo application
allocate buffer
do while true {
place user input in buffer
send service request
receive reply
pass reply to the user }
leave application
}
この擬似コードに示したほとんどの処理は、
ATMI関数で実装されます。ただし、ユーザー入力をバッファに格納する処理と、ユーザーに応答を返す処理には、C言語の関数を使用します。
バッファの割当てでは、クライアント・プログラムによって
型付きバッファと呼ばれるメモリー領域がOracle Tuxedoランタイム・システムから割り当てられます。型付きバッファとは、C構造体などの形式が指定されたメモリー・バッファです。
ATMIクライアントは、アプリケーションから分離する前に、サービス・リクエストをいくつでも送受信できます。クライアントは、これらのリクエストを一連のリクエスト/レスポンス呼出しとして送信できますが、ある呼出しから別の呼出しに状態の情報を渡す必要がある場合は、会話型サーバーに接続してリクエストを送ることもできます。どちらの方法でもクライアント・プログラムのロジックは同じですが、使用するATMI関数は異なります。
Oracle Tuxedo ATMIサーバー
とは、クライアントに対して1つ以上のサービス
を提供するプロセスです。サービスとは、クライアントが処理を要求する特定のビジネス・タスクです。サーバーは、クライアントからリクエストを受け取り、それらを適切なサービス・サブルーチンにディスパッチします。
サーバーのビルドでは、サービス・サブルーチンと、Oracle Tuxedoシステムで提供される
main()プロセスとがアプリケーションによって組み合わされます。この
main()関数はシステムによって提供され、定義済の関数から構成されています。この関数は、サーバーの初期化と終了を行ったり、バッファを割り当てて、リクエストを受信してサービス・ルーチンへのディスパッチを行ったりします。この処理はすべてアプリケーションに透過的です。
図1-2は、サーバーとサービス・サブルーチン間の相互作用を示す疑似コードをまとめたものです。
初期化後、ATMIサーバーはバッファの割当てを行い、リクエスト・メッセージがメッセージ・キューに登録されるまで待機し、そのリクエストをキューから取り出してサービス・サブルーチンに送り、リクエストを処理します。応答が必要な場合、その応答はリクエスト処理の一部とみなされます。
会話型パラダイムは、
図1-3の疑似コードで示すように、リクエスト/レスポンス型パラダイムとは多少異なります。
Oracle Tuxedoシステム提供の
main()プロセスには、プロセスをATMIサーバーとして登録し、サービスを公開し、バッファを割り当て、キューからリクエスト・メッセージを取り出すために必要なコードが記述されています。ATMI関数は、リクエストを処理するサービス・サブルーチンで使用されます。サービス・サブルーチンのコンパイルとテストを行う準備ができたら、これらをサーバーの
main()とリンクして、実行可能サーバーを生成します。その場合、
buildserverコマンドを実行します。
クライアントが複数のサービスや同じサービスを複数回リクエストする場合、サービスのサブセットを別のサーバーに転送して実行できます。その場合、サーバーはクライアント、つまりサービスの
リクエスタとして動作します。クライアントとサーバーの両方がリクエスタになることができますが、クライアントはリクエスタにしかなれません。このようなモデルは、Oracle Tuxedo ATMI関数を使用すると簡単にコーディングできます。
注意:
|
リクエスト/レスポンス・サーバーも、リクエストを別のサーバーに転送できます。その場合、サーバーはクライアント(リクエスタ)としては動作しません。応答を必要としているのは、要求を転送したサーバーではなく、元のクライアントだからです。
|
アプリケーションのロジックを記述するC言語のほかに、アプリケーション・トランザクション・モニター・インタフェース(ATMI)を使用する必要があります。このATMIは、アプリケーションとOracle Tuxedoシステム間のインタフェースになります。ATMI関数は、オペレーティング・システム・コールに類似したC言語の関数です。これらの関数により、必要なすべてのリソースも含め、Oracle Tuxedoシステムのトランザクション・モニターの下で動作するアプリケーション・モジュール間の通信が実装されます。
ATMIは、リソースのオープンとクローズ、トランザクションの開始と終了、バッファの割当てと解放、およびクライアントとサーバー間の通信のサポートなどの処理に使用されるコンパクトな関数セットです。
表1-2は、ATMI関数をまとめたものです。各関数については、
『Oracle Tuxedo ATMI C言語関数リファレンス』を参照してください。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
現在のスレッドのコンテキストの識別子を取得します。
|
|
|
マルチコンテキスト・プロセスに現在のスレッドのコンテキストを設定します。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ドメイン内で一意のサービス名を持つサービスを通知するか、Oracle Tuxedoサーバーのセカンダリ・リクエスト・キューにサービスを通知します。
|
|
|
|
|
|
|
|
|
|
|
サービスへの同期リクエスト/レスポンスを開始します。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
イベント・メッセージのサブスクリプションを削除します。
|
|
|
|
|
|
|
|
|
|
トランザクション・モードであるかどうかを確認します。
|
|
|
|
|
|
|
|
『Oracle Tuxedoアプリケーションの設定』
|
|
|
|
|
|
『Oracle Tuxedo ATMI C言語関数リファレンス』
|
|
ブロック・タイム値を秒単位またはミリ秒単位で設定します。
|
|
|
デジタル署名の生成、メッセージの暗号化/復号化のためのキー・ハンドルをオープンします。
|
CORBAアプリケーションにおけるセキュリティの使用
|
|
|
|
キー・ハンドルに関連付けられた属性(オプション)を設定します。
|
|
すでにオープンされているハンドルをクローズします。
|
|
デジタル署名を生成するための型付きメッセージ・バッファをマークします。
|
|
暗号化エンベロープを生成するための型付きメッセージ・バッファをマークします。
|
|
型付きメッセージ・バッファに関連付けられたデジタル署名と受信側の情報にアクセスします。
|
|
型付きメッセージ・バッファをエクスポート可能でマシンに依存しない(外部化された)文字列表現に変換します。
|
|
外部化された文字列表現を型付きメッセージ・バッファに変換します。
|