|
|
分散アプリケーションは、複数のハードウェア・システム上にあるソフトウェア・モジュールから構成され、これらのモジュールが互いに通信してアプリケーションの必要なタスクが実行されます。たとえば、図1-1に示すリモート・オンライン銀行業務システムの分散アプリケーションは、顧客のホーム・コンピュータで実行されるソフトウェア・モジュールと、すべての口座レコードを管理する銀行のコンピュータ・システムから構成されています。
たとえば、ログオンしてメニューからオプションを選択するだけで、残高を照会できます。この処理では、ローカル・ソフトウェア・モジュールが特別なアプリケーション・プログラミング・インタフェース(API)ルーチンを使用して、リモート・ソフトウェア・モジュールと通信しています。
Oracle Tuxedo分散アプリケーション・プログラミング環境では、分散ソフトウェア・モジュール間で安全かつ信頼性の高い通信を行うために必要なAPIルーチンが提供されています。このAPIは、アプリケーション・トランザクション・モニター・インタフェース(ATMI)と呼ばれます。
表1-1は、アプリケーション開発者が利用できるOracle Tuxedo ATMIの通信パラダイムを示しています。
リクエスト/レスポンス型通信では、あるソフトウェア・モジュールが2番目のソフトウェア・モジュールにリクエストを送り、そのレスポンスを受け取ります。リクエスタがレスポンスを受け取るまで処理が行われずに待機する同期通信、またはリクエスタがレスポンスを待機する間も処理が継続される非同期通信の2種類があります。
このパラダイムの詳細は、「クライアントおよびサーバーへのリクエスト/レスポンスのコーディング」を参照してください。
|
|
会話型通信はリクエスト/レンポンス型通信に似ていますが、会話が終了する前に複数のリクエストやレンポンスが発生します。会話型通信では、会話が切断されるまでクライアントとサーバーで状態の情報が保持されます。クライアントとサーバー間でメッセージをやり取りする方法は、使用するアプリケーション・プロトコルによって決定されます。
このパラダイムの詳細は、「会話型クライアントおよびサーバーのコーディング」を参照してください。
|
|
アプリケーション・キュー・ベースの通信では、遅延通信、つまり時間に依存しない通信が行われます。この通信では、クライアントとサーバーがアプリケーション・キューを使用して通信します。Oracle Tuxedo/Q機能を使用すると、メッセージを永続的な記憶装置(ディスク)や一時的な記憶装置(メモリー)のキューに入れることができ、後で処理したり取り出すことができます。
|
|
|
このパラダイムの詳細は、「イベント・ベースのクライアントおよびサーバーのコーディング」を参照してください。
|
Oracle Tuxedo ATMIクライアントとは、ユーザーのリクエストを収集し、そのリクエストに対するサービスを提供するサーバーにそのリクエストを転送するソフトウェア・モジュールです。ほとんどのソフトウェア・モジュールは、ATMIクライアント初期化ルーチンを呼び出して、Oracle Tuxedoアプリケーションに参加することで、Oracle Tuxedoクライアントとして動作できます。クライアントになると、サーバーと情報を交換できるようになります。
クライアントは、ATMI終了ルーチンを呼び出してアプリケーションから分離し、Oracle Tuxedoシステムにクライアントを追跡する必要がなくなったことを通知します。これにより、他の操作でOracle Tuxedoアプリケーションのリソースを使用できるようになります。
リスト1-1は、基本的なクライアント・プロセスの処理を示す擬似コードです。
START PROGRAM
enroll as a client of the BEA TUXEDO application
place initial client identification in data structure
perform until end
get user input
place user input in DATA-REC
send service request
receive reply
pass reply to the user
end perform
leave application
END PROGRAM
このリストに示したほとんどの処理は、ATMI呼出しで実装されます。ただし、ユーザー入力をDATA-RECに格納する処理と、ユーザーに応答を返す処理には、COBOLルーチンで実装されます。
ATMIクライアントは、アプリケーションから分離する前に、サービス・リクエストをいくつでも送受信できます。クライアントは、これらのリクエストを一連のリクエスト/レスポンス呼出しとして送信できますが、ある呼出しから別の呼出しに状態の情報を渡す必要がある場合は、会話型サーバーに接続してリクエストを送ることもできます。どちらの方法でもクライアント・プログラムのロジックは同じですが、必要なATMI呼出しは異なります。
ATMIクライアントを実行するには、buildclient -Cコマンドを実行してクライアントをコンパイルし、Oracle Tuxedo ATMIおよび必要なライブラリとリンクする必要があります。buildclient(1)コマンドの詳細は、「クライアントのコーディング」を参照してください。
Oracle Tuxedo ATMIサーバーとは、クライアントに対して1つ以上のサービスを提供するプロセスです。サービスとは、クライアントが処理を要求する特定のビジネス・タスクです。サーバーは、クライアントからリクエストを受け取り、それらを適切なサービス・サブルーチンにディスパッチします。
サーバーのビルドでは、サービス・サブルーチンと、Oracle Tuxedoシステムで提供される制御プログラムがアプリケーションによって組み合されます。この制御プログラムはシステムによって提供され、定義済のルーチンから構成されています。これは、サーバーの初期化と終了を実行したり、ユーザー入力をデータ構造体に格納して、リクエストを受信してサービス・ルーチンへのディスパッチを実行できるようにします。この処理はすべてアプリケーションに透過的です。
図1-2は、サーバーとサービス・サブルーチン間の相互作用を示す疑似コードを示しています。
初期化後、ATMIはリクエスト・メッセージがメッセージ・キューに登録されるまで待機し、そのリクエストをキューから取り出してサービス・サブルーチンにディスパッチし、リクエストを処理します。応答が必要な場合、その応答はリクエスト処理の一部とみなされます。
会話型パラダイムは、図1-3の疑似コードで示すように、リクエスト/レスポンス型パラダイムとは多少異なります。
Oracle Tuxedoシステム提供の制御プログラムには、プロセスをATMIサーバーとして登録してサービスを通知し、キューからリクエストを取り出すために必要なコードが記述されています。ATMI呼出しは、リクエストを処理するサービス・サブルーチンで使用されます。サービス・サブルーチンのコンパイルとテストを行う準備ができたら、これらをサーバーとリンクして、実行可能サーバーを生成します。その場合、buildserver -Cコマンドを実行します。
クライアントが複数のサービスや同じサービスを複数回リクエストする場合、サービスのサブセットを別のサーバーに転送して実行できます。その場合、サーバーはクライアント、つまりサービスのリクエスタとして動作します。クライアントとサーバーの両方がリクエスタになることができますが、クライアントはリクエスタにしかなれません。このようなモデルは、Oracle Tuxedo ATMI呼出しを使用すると簡単にコーディングできます。
| 注: | リクエスト/レスポンス・サーバーも、リクエストを別のサーバーに転送できます。その場合、サーバーはクライアント(リクエスタ)としては動作しません。応答を必要としているのは、要求を転送したサーバーではなく、元のクライアントだからです。 |
アプリケーションのロジックを記述するCOBOLコードの他に、アプリケーションとOracle Tuxedoシステム間のインタフェースになるアプリケーション・トランザクション・モニター・インタフェース(ATMI)を使用する必要があります。
ATMIは、リソースのオープンとクローズ、トランザクションの開始と終了、およびクライアントとサーバー間の通信のサポートなどの処理に使用されるコンパクトな呼出しのセットです。表1-2は、ATMI呼出しをまとめたものです。各呼出しについては、『Oracle Tuxedo ATMI COBOL関数リファレンス』を参照してください。
  
|