| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > C 言語を使用した Tuxedo アプリケーションのプログラミング > BEA Tuxedo プログラミングの概要 |
|
C 言語を使用した Tuxedo アプリケーションのプログラミング
|
BEA Tuxedo プログラミングの概要
ここでは、次の内容について説明します。
BEA Tuxedo 分散アプリケーションのプログラミング
分散アプリケーションは、複数のハードウェア・システム上にあるソフトウェア・モジュールから構成され、これらのモジュールが互いに通信してアプリケーションのタスクが実行されます。たとえば、次の図に示すリモート・オンライン銀行業務システムの分散アプリケーションは、顧客のホーム・コンピュータで実行されるソフトウェア・モジュールと、すべての口座レコードを管理する銀行のコンピュータ・システムから構成されています。
図 1-1 分散アプリケーションの例 - オンライン銀行業務システム
たとえば、ログオンしてメニューからオプションを選択するだけで、残高を照会できます。この処理では、ローカル・ソフトウェア・モジュールが特別なアプリケーション・プログラミング・インターフェイス (API) 関数を使用して、リモート・ソフトウェア・モジュールと通信しています。 BEA Tuxedo 分散アプリケーション・プログラミング環境では、分散ソフトウェア・モジュール間で安全かつ信頼性の高い通信を行うために必要な API 関数が提供されています。BEA Tuxedo API は、アプリケーション・トランザクション・モニタ・インターフェイス (ATMI) と呼ばれます。 ATMI を使用すると、以下の操作を行うことができます。
コミュニケーション・パラダイム
次の表は、アプリケーション開発者が利用できる BEA Tuxedo のコミュニケーション・パラダイムを示しています。
表 1-1 コミュニケーション・パラダイム
BEA Tuxedo クライアント
BEA Tuxedo クライアントとは、ユーザの要求を収集し、その要求に対するサービスを提供するサーバにその要求を転送するソフトウェア・モジュールです。ほとんどのソフトウェア・モジュールは、BEA Tuxedo クライアントとして動作できます。その場合、ATMI クライアント初期化ルーチンを呼び出して、BEA Tuxedo アプリケーションに「参加」します。クライアントになると、メッセージ・バッファを割り当てて、サーバと情報を交換できるようになります。
クライアントは、ATMI 終了ルーチンを呼び出してアプリケーションから「分離」し、BEA Tuxedo システムにクライアントをトラッキングする必要がなくなったことを通知します。これにより、ほかの操作で BEA Tuxedo アプリケーションのリソースを使用できるようになります。
次は、基本的なクライアント・プロセスの処理を示す擬似コードです。
コード リスト 1-1 要求/応答型クライアントの擬似コード
main()
{
TPINIT バッファを割り当て
バッファに初期クライアント ID を配置
BEA Tuxedo アプリケーションのクライアントとして登録
バッファを割り当て
do while true {
ユーザ入力データをバッファに格納
サービス要求を送信
応答を受信
ユーザに応答を返信 }
アプリケーションを終了
}
この擬似コードに示したほとんどの処理は、ATMI 関数でインプリメントされます。ただし、ユーザ入力をバッファに格納する処理と、ユーザに応答を返す処理には、C 言語の関数を使用します。
バッファの割り当てでは、クライアント・プログラムによって型付きバッファと呼ばれるメモリ領域が BEA Tuxedo ランタイム・システムから割り当てられます。型付きバッファとは、C 構造体などの形式が指定されたメモリ・バッファです。
クライアントは、アプリケーションから分離する前に、サービス要求をいくつでも送受信できます。クライアントは、これらの要求を一連の要求/応答型呼び出しとして送信することができます。また、ある呼び出しから別の呼び出しに状態の情報を渡す必要がある場合は、会話型サーバに接続して要求を送ることもできます。どちらの方法でもクライアント・プログラムのロジックは同じですが、使用する ATMI 関数は異なります。
クライアントを実行するには、buildclient コマンドを実行してクライアントをコンパイルし、BEA Tuxedo ATMI および必要なライブラリとリンクします。buildclient コマンドの詳細については、クライアントのコーディングを参照してください。
BEA Tuxedo サーバ
BEA Tuxedo サーバとは、クライアントに対して 1 つ以上のサービスを提供するプロセスです。サービスとは、クライアントが処理を要求する特定のビジネス・タスクです。サーバは、クライアントから要求を受け取り、それらを適切なサービス・サブルーチンにディスパッチします。
サーバの基本的な動作
サーバのビルドでは、サービス・サブルーチンと、BEA Tuxedo システムで提供される main() プロセスとがアプリケーションによって組み合わされます。この main() 関数はシステムによって提供され、定義済みの関数から構成されています。この関数は、サーバの初期化と終了を行ったり、バッファを割り当てて、要求を受信してサービス・ルーチンへのディスパッチを行ったりします。このすべての処理は、アプリケーションに透過的です。
次の図は、サーバとサービス・ルーチン間の相互作用を示す疑似コードです。
図 1-2 要求/応答型サーバとサービス・サブルーチンの擬似コード
初期化後、サーバはバッファの割り当てを行い、要求メッセージがメッセージ・キューに登録されるまで待機し、その要求をキューから取り出してサービス・サブルーチンに送り、要求を処理します。応答が必要な場合は、その応答は要求処理の一部と見なされます。 会話型パラダイムは、次の図の擬似コードで示すように、要求/応答型パラダイムとは多少異なります。 図 1-3 会話型サービス・サブルーチンの擬似コード
BEA Tuxedo システム提供の main() プロセスには、プロセスをサーバとして登録し、サービスを宣言し、バッファを割り当て、キューから要求メッセージを取り出すために必要なコードが記述されています。ATMI 関数は、要求を処理するサービス・サブルーチンで使用されます。サービス・サブルーチンのコンパイルとテストを行う準備ができたら、これらをサーバの main() とリンクして、実行可能サーバを生成します。その場合、buildserver コマンドを実行します。 要求元としてのサーバ クライアントが複数のサービスや同じサービスを複数回要求する場合、サービスのサブセットを別のサーバに転送して実行することができます。その場合、サーバはクライアント、つまりサービスの要求元として動作します。つまり、クライアントとサーバの両方が要求元になることができます。ただし、クライアントは要求元にしかなれません。このようなモデルは、BEA Tuxedo の ATMI 関数を使用すると簡単にコーディングできます。 注記 要求/応答型サーバも、要求を別のサーバに転送できます。その場合、サーバはクライアント (要求元) としては動作しません。応答を必要としているのは、要求を転送したサーバではなく、元のクライアントだからです。
BEA Tuxedo API:ATMI
アプリケーションのロジックを記述する C 言語のほかに、アプリケーション・トランザクション・モニタ・インターフェイス (ATMI) を使用する必要があります。この ATMI は、アプリケーションと BEA Tuxedo システム間のインターフェイスになります。ATMI 関数は、オペレーティング・システム・コールに類似した C 言語の関数です。これらの関数により、必要なすべてのリソースも含め、BEA Tuxedo システムのトランザクション・モニタの下で動作するアプリケーション・モジュール間の通信がインプリメントされます。
ATMI は、リソースのオープンとクローズ、トランザクションの開始と終了、バッファの割り当てと解放、およびクライアントとサーバ間の通信のサポートなどの処理に使用されるコンパクトな関数セットです。次の表は、ATMI 関数をまとめたものです。各関数については、『BEA Tuxedo C リファレンス』を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
