この章では、COBOL アプリケーションを Enterprise Server の環境下で動作するサービスとしてエクスポーズする場合の留意点について説明します。
Enterprise Server 環境下にサービスとしてディプロイした COBOL アプリケーションは、常にサーバのサービス実行プロセス内で実行されます。 COBOL アプリケーションを実行する部分のサービス実行プロセスは、厳密に管理された COBOL ランタイム環境であり、アプリケーションコンテナとも呼ばれます。 Enterprise Server は、アプリケーションの呼び出しから次の呼び出しまでの間、一貫した状態を維持することによって、例外処理の動作に一貫性を与えます。
クライアントからの要求が着信すると、呼び出し対象のアプリケーションプログラムがロードされ、呼び出しが実際に実行される前に、コンテナによって実行環境がセットアップされます。この環境は、Interface Mapping Toolkit を使用して、ディプロイ設定の「Enterprise Server 実行時環境の構成」で指定した情報に基づいて構築されます。 この情報には、アプリケーションに必要な環境変数やチューナー、およびスイッチが含まれています。 サービスのディプロイ時にランタイム設定情報を指定しなかった場合には、デフォルト環境がセットアップされます。
クライアントからの要求には、短期実行と長期実行の要求があります。 短期実行のクライアント要求とは、クライアントとサービス間のやり取りが一度だけ実行される要求のことです。クライアントからの要求が着信するとサービスが実行され、応答がクライアントに返されます。 クライアントから Web サービスに送信される要求は、常に短期実行の要求です。一方、長期実行のクライアント要求とは、同じクライアントによって繰り返し実行されるサービス要求 (それぞれのサービス呼び出しの間でデータを保持する必要がある) か、トランザクションの一部を構成する要求のことです。したがって、クライアントが WebLogic や WebSphere などの J2EE サーバで実行されているステートフルな JavaBean の場合、この Bean の実行が続く限り、サービスも継続して実行されます。
アプリケーションが短期実行要求で呼び出された場合には、そのアプリケーションが終了 (正常終了、ランタイムシステムエラーによる終了の違いを問わない) すると、応答が生成されてクライアントに返される前にアプリケーションコンテナが初期状態に戻ります。
サービス実行プロセスは通常、クライアントに応答を送信した後、Enterprise Server から他の要求の処理を通知されるまで待機します。 ただし、次の条件のいずれかに該当する場合は、アプリケーションの実行終了後に、サービス実行プロセスも終了します。
これらの理由でコンテナが終了した場合には、Enterprise Server によって新しいサービス実行プロセスが開始されます。
長期実行要求は、トランザクションの開始時か、ステートフルなサービスの呼び出しが要求されたときに開始されます。 長期実行要求ではトランザクションが終了するか、ステートフルな処理が不要になった旨の通知がクライアントから送信されるまで、クライアントとサーバ間の接続が一貫して維持されます。ただし、長期実行要求の実行中にトランザクションが開始される場合 (トランザクション要求にステートフルなサービス要求が先行した場合など) や、トランザクションの最初のサービス要求としてステートフルなサービスが要求される場合もあります。 そのような場合はトランザクションが終了しても、サーバがステートフルモードで動作しているため、長期実行要求は終了しません。
長期実行要求がいったん開始されると、サービス実行プロセスは、その要求の発信元クライアントから着信する要求だけを処理するようになります。 そのため、他のクライアントからの要求にも応答できるように、Enterprise Server は既存のサービス実行プロセスでステートフル要求の処理が開始されるたびに、新しいサービス実行プロセスを開始します。
ステートフル処理の実行中には、サービス要求が正常に終了しても、アプリケーションコンテナは初期状態に戻りません。 ステートフルな処理が不要になった旨の通知をクライアントから受信するまで、コンテナはクライアント状態のまま複数のサービス要求にわたって維持されます (したがって、ユーザプログラムはキャンセルされず、環境変数やチューナー、およびスイッチは初期状態にリセットされず、ユーザライブラリはメモリ内に維持されます)。ステートフルな処理が不要になった旨の通知をクライアントから受信すると、アプリケーションコンテナは初期状態に戻ります。
また、サービス要求によってランタイムシステムエラーが発生した場合には、ステートフルモードは暗黙的に終了します。
Enterprise Server は、サービス実行プロセスの数が設定値を超えないように管理します。 したがって、 ステートフルなクライアント要求が完了したときに、Enterprise Server がその要求を実行していたサービス実行プロセスを終了させることもあります。
サービスとしてエクスポーズしている COBOL アプリケーションがデータベースやファイルなどの外部リソースを使用する場合、それらのリソースは COBOL アプリケーション自体で管理されるか、あるいはアプリケーションコンテナが管理を代行します。 使用するリソースをアプリケーション自体で管理するサービスはアプリケーション管理サービス、コンテナに管理を任せるサービスはコンテナ管理サービスと呼ばれます。
ディプロイするアプリケーションのリソース管理の種類は、[サービス] メニューの [設定] で指定できます。
サービスは、次のいずれかの条件に該当する場合、自身でリソースを管理する必要があります。
トランザクション以外の方法でファイルにアクセスする (COMMIT と ROLLBACK を含まない) アプリケーションによるサービスは、アプリケーション管理にする必要があります。
トランザクション処理を行うアプリケーション管理サービスは、必要なすべてのトランザクションロジックを含み、すべてのリソースをコミットまたはロールバックした状態で完了する必要があります。
アプリケーション管理サービスは、Net Express、Server Express または Application Server などの従来の実行環境でのアプリケーションと同じように実行されます。サービスの実行終了後もプロセスが継続されるという点で両者は大きく異なります。
サービスとして動作し、データベースやファイルを使用する一方で、トランザクションロジックをいっさい含まないアプリケーションは、リソース管理をアプリケーションコンテナに任せることができます。
アプリケーションコンテナでリソースを管理するには、必要なリソースマネージャを事前に指定しておく必要があります。 リソースマネージャは Enterprise Server で指定します。 指定できるのは XA 準拠のリソースマネージャだけであり、 具体的には次の 2 種類のデータベースリソースマネージャが指定可能です。
リソースマネージャの指定方法については、Enterprise Server の『構成と管理』マニュアルで『構成』の章の『リソースマネージャ』を参照してください。
アプリケーションコンテナは、「Enterprise Server 実行時環境の構成」ダイアログボックスの「ディプロイメントの特性」タブで設定された情報に基づいて、リソースの処理方法 (コミット/ロールバック) を決定します。このダイアログボックスを表示するには、ディプロイするマッピングを含む .mpr ファイルを右クリックして [Enterprise Server 実行時環境の使用] を選択し、[Enterprise Server 実行時環境の構成] をクリックします。 また、アプリケーションが呼び出しの成否を示す戻り値を返すかどうか、および呼び出しが成功した場合の戻り値の最大値も指定できます。 呼び出しの成否を示す戻り値を返さないように指定すると、アプリケーションコンテナは呼び出しがすべて成功したものと解釈します。
サービスとしてエクスポーズする場合、COBOL アプリケーションにはいくつかの制約が適用されます。 制約のほとんどは、プログラムをリモートユーザから呼び出される自己完結型のコンポーネントとして使用するために生じる、必然的なものです。
COBOL アプリケーションをサービスとしてエクスポーズする作業に着手する前に、アプリケーションがサービスに適しているかどうかを検討してください。 エクスポーズするすべての機能を調べ、この項で説明する条件を満たしていることを確認してください。 検討の結果、アプリケーションに多少の変更が必要になることもあります。
サービスは次の 2 つの方法でデータの受け渡しを行うことができます。
データ項目が連絡節項目経由で、または経由しないで渡されるかどうかに応じて、インターフェイスマッパーを使用してプログラムの入出力データを正しくマップする必要があります。
エンタープライズサーバ環境下でサービスとして動作しているアプリケーションでは、インターフェイスフィールドにマップされていない ANSI ACCEPT 文や ACCEPT FROM COMMAND-LINE 文は空白文字を返し、インターフェイスフィールドにマップされていない ANSI DISPLAY 文や RETURN-CODE 値は無視されます。ANSI ACCEPT、ACCEPT FROM COMMAND-LINE、または ANSI DISPLAY 以外の画面出力やキーボード入力処理が存在すると、ランタイムシステムエラー 197 が生成され、アプリケーションが終了します。
また、サービスは ACCEPT FROM CONSOLE 文および DISPLAY UPON CONSOLE 文を実行できます。DISPLAY UPON CONSOLE 文が実行されると、表示テキストがエンタープライズサーバのコンソールログに表示され、サービスが続行されます。ACCEPT FROM CONSOLE 文が実行されると、サービスは処理を一時停止して ESMAC のページを使用して入力を求めます。
サービスは常に、適切な手順を経て終了する必要があります。適切な手順とは、中断されることなく実行され、クライアントに処理結果を返してから終了し、サーバに制御を戻すことです。
したがって、どのようなエラーが発生した場合でも停止することなく、エラーの通知を出力パラメータで返してから終了すべきです。 プログラムがクラッシュしたり、中断されることがないように、FILE STATUS 句や宣言手順などの手段を通じて、あらゆるエラー状態を確実に検出させる必要があります。
同様の理由で、COBOL アプリケーションでは STOP RUN 文を使用すべきではありません。 サービスの実行中に STOP RUN 文が呼び出されると、プログラムが適切な手順を経ずに、ただちに終了してしまいます。
Enterprise Server のサービス実行プロセスでは、シングルスレッドのランタイムシステムを使用するアプリケーションのみが実行可能であるため、マルチスレッドアプリケーションをサービスとしてエクスポーズすることはできません。
短期実行クライアント要求で呼び出されるサービスの場合、アプリケーションは同じクライアントからの前回以前の呼び出しを関知することなく、Enterprise Server で実行されます。 呼び出し時のデータや状態を次の呼び出しまで保持する必要があるときには、データを作業ファイルに保存する方法など、開発者自身が適切な方法をプログラムに盛り込む必要があります。
Micro Focus がファイル操作用に提供している File Handler API を使用する場合、この API を通じて開いたすべてのファイルを、アプリケーションの終了時に確実に閉じてください。 ファイルを開いたままの状態で残すと、以降のサービス要求でサービス実行エラーが発生することがあります。
アプリケーションで使用したすべてのリソースは、COBOL ランタイムシステムで管理される部分を除き、すべて終了前に解放する必要があります。 リソースを正しく解放しないと、コンテナによる以降のサービス呼び出し時に、サービスの正しい動作が保証されません。 他のアプリケーションによって使用されているサードパーティ製モジュールなど、解放できないリソースが存在する場合には、サービスのディプロイ時に「コンテナの再利用を行わない」というオプションを通知してください。 このオプションを使用すれば、Enterprise Server 内のサービス実行プロセスは、そのアプリケーションの終了するたびに終了するようになります。
Copyright © 2006 Micro Focus International Limited. All rights reserved.