アーキテクチャの概要

ここでは、Enterprise Serverアーキテクチャの概要について説明します。

Enterprise Server の概要

Enterprise Server は、COBOL アプリケーションプログラムの実行環境を提供します。この実行環境はエンタープライズサーバとして知られています。このマニュアルおよび関連マニュアルでは、用語「エンタープライズサーバ」は実行環境を、「Enterprise Server」は製品名を意味します。

COBOL アプリケーションは、各種のクライアントが発行したサービス要求に応じてエンタープライズサーバ内で実行されます。COBOL 開発システムの一部である Interface Mapping Toolkit を使用すると、既存の COBOL アプリケーションをサービスとして公開できます。公開された COBOL サービスは、Web サービスとして、または J2EE コネクタや COM を介してクライアントから起動できます。

サービスを実装する COBOL プログラムは、パラメータブロックを読み込んで処理し、処理した結果ブロックを返します。サービスへのインターフェイスは、サービスの定義によって公開します。すべての COBOL アプリケーションがサービスとして公開するのに適しているわけではありません。詳細は、『Interface Mapping Toolkit』の『 Enterprise Server へのアプリケーションの実装』の章を参照してください。

エンタープライズサーバは、COBOL アプリケーションのセッション管理と状態管理を提供します。また、オプションで外部リソースマネージャとのインターフェイスを取り、リソースの更新の整合を取ります。

エンタープライズサーバは、初期化済みのサービス実行プロセスプールを提供します。COBOL アプリケーションはこのプール内で実行されます。 COBOL アプリケーションは独自のアドレス空間で実行されるため、エンタープライズサーバ内で実行されている他のプログラムから分離されます。複数のプロセスを実行することで、クライアントの要求メッセージに対応する COBOL プログラムを同時に複数実行できます。

Enterprise Server をインストールすると、エンタープライズサーバが 1 つ自動的に設定されます。エンタープライズサーバは新規に作成することもできます。

前提条件

唯一の前提条件として、クライアント側とサーバ側の両方のマシンで TCP/IP 通信ソフトウェアが実行されている必要があります。

エンタープライズサーバのアーキテクチャ

エンタープライズサーバにはいくつかの構成要素があります。図 1-1 に、エンタープライズサーバのアーキテクチャの概要を示します。

図 1-1: エンタープライズサーバのアーキテクチャ

エンタープライズサーバには、複数のプロセスと、プロセス間通信で使用する領域が 1 つあります。

プロセスにはコンソールデーモン、サーバマネージャ、通信プロセスがあります。これらのプロセスは次の機能を実行します。

コンソールデーモンは、エンタープライズサーバのプロセスとログメッセージを管理します。
サーバマネージャは、プロセス間通信領域の作成と管理を行い、コンソールデーモンと連動してプロセスを管理します。
通信プロセスは、着信クライアント要求を受信し、その要求を該当するサービスに送信します。また、通信サーバは要求の処理結果を受信し、クライアントに返します。要求は次のどちらかのクライアントから発行されます。
- Web サービスを要求するクライアント。これらのクライアントからの要求は、HTTP で SOAP (Simple Object Access Protocol) メッセージとして受信します。
- サービスを要求する J2EE クライアント。 J2EE クライアントからの要求は、Micro Focus 製の符号化と転送プロトコルを使用して受信します。
すべての種類の要求で、基本的な通信機構として TCP/IP を使用します。

エンタープライズサーバは 1 つの通信プロセスとともに作成されますが、信頼性と耐障害性を高めるために通信プロセスを追加することもできます。

エンタープライズサーバは、2 つのサービス実行プロセスとともに作成されます。サービス実行プロセスは、名前が示すように、クライアント要求を処理する COBOL プログラムを実際に実行するプロセスです。サービス実行プロセスは追加することができます。

プロセス間通信領域には、エンタープライズサーバ内で利用できるすべてのサービスの定義を保持する共有メモリ領域があります。これらのサービスの定義は、図 1-1 に示す Directory Server で行われます。Directory Server はエンタープライズサーバの外側に位置し、複数のエンタープライズサーバの情報を保持します。また、プロセス間通信領域は、エンタープライズサーバのプロセス間で要求と応答を受け渡すためにも使用します。

サービス実行プロセス

サービスを提供する COBOL アプリケーションは、サービス実行プロセス内で実行されます。エンタープライズサーバは、複数のサービス実行プロセスをもつことができます。サーバを起動すると、サーバ内のすべてのサービス実行プロセスがクライアント要求を処理できます。サービス実行プロセスが要求の処理を完了すると、別の要求の処理が可能になります。

要求は次のように処理されます。

クライアント要求は通信プロセスで受信され、共有メモリ領域内のキューに置かれることでその実行がスケジュールされます。
サービス実行プロセスの 1 つが使用可能になると、要求の処理を開始します。サービス実行プロセスは、Enterprise Server の環境で動作するように適合された COBOL ランタイムシステムである、アプリケーションコンテナを呼び出します。
アプリケーションコンテナは、要求ハンドラを呼び出して、受け取った要求を解読します。 Enterprise Server が処理できる各種類のクライアント要求を処理する Micro Focus 製の要求ハンドラがあります。この要求ハンドラは、Interface Mapping Toolkit が作成したマッピング情報を使用して、要求パラメータを COBOL アプリケーションの呼び出しインターフェイスにマップします。
COBOL アプリケーションが要求の処理を完了すると、アプリケーションコンテナは要求ハンドラを呼び出して出力パラメータをクライアントが解読できる形式にマップします。
アプリケーションコンテナは、応答を通信マネージャに渡します。通信マネージャは、受け取った応答をクライアントに返します。

図 1-2 に、サービス実行プロセスの構成要素を示します。

図 1-2: サービス実行プロセスの構成要素

トランザクション管理構成要素は、コンテナ管理サービスのトランザクションを管理します。つまり、COMMIT と ROLLBACK トランザクションを管理します。リソースマネージャインターフェイスは、データベースやファイルアクセスなど、リソースへの要求を処理します。トランザクション管理とリソースマネージャの詳細は、『リソース管理』を参照してください。

Directory Server

Directory Server は、サービスと他の関連する構成要素を定義する一連の情報を管理するプロセスです。 Directory Server が取り扱う構成要素はオブジェクトと呼ばれます。 Directory Server のリポジトリには、オブジェクトに関する情報が格納されます。 Directory Server は、次の情報を管理します。

サーバ
サービス
通信プロセス
サービスリスナー
要求ハンドラ
実装パッケージ
XA リソース

Interface Mapping Toolkit を使用して COBOL アプリケーションをサービスとしてディプロイすると、サービスの情報のほとんどが自動的に作成されます。管理者は、必要に応じて情報を編集できます。

サーバオブジェクトは Directory Server の最上位オブジェクトです。他のオブジェクトは、サーバから独立して存在することはできません。図 1-3 に、2 つのサービスがあるエンタープライズサーバを示します。矢印はオブジェクト間の関係を示します。サーバに 1 つ以上のサービスを COBOL 開発システムからディプロイするのではなく、手動で設定する場合は、すべてのオブジェクトを作成してからオブジェクト間の関係をビルドします。

エンタープライズサーバのオブジェクト

図 1-3: エンタープライズサーバ内のオブジェクト

デフォルトでは、Directory Server はエンタープライズサーバが実行されているマシンで実行されます。

サーバ

Directory Server は、次の 2 種類のサーバオブジェクトに関する情報を格納します。

エンタープライズサーバ (『エンタープライズサーバのアーキテクチャ』を参照)。エンタープライズサーバは、複数のサービスにアクセスできます。
CCI サーバ。Micro Focus 製の共通通信インターフェイス (CCI) を使用し、CCITCP2 プロセスに登録しないでネーミングサーバとして Directory Server を使用するサービスを提供します。 CCI サーバは下位互換性のためにサポートされています。

サーバの詳細は、『サーバ』の章を参照してください。

サービス

サービスオブジェクトはサービスを定義します。サービスにより、クライアントは、特定のビジネス機能にアクセスすることができます。

サービスには複数のオペレーションを含むことができます。たとえば、計算プログラムでは加算、減算、乗算、および除算を行います。各作業は、クライアントが、その機能へのインターフェイスを理解している場合に使用できる計算サービス内のオペレーションです。

エンタープライズサーバでは、エンタープライズサーバにディプロイするサービスのほかに、1 つ以上のシステムサービスを含むことができます。デフォルトのエンタープライズサーバには、次の 2 つのシステムサービスがあります。

ディプロイサービス。Net Express から、起動されているエンタープライズサーバへサービスを自動的にディプロイできます。
テストサービス。これは、エコーサービスです。 Web ブラウザを開いてサービスリスナーのアドレスを入力すると、サーバが起動されている場合には HTML 応答があります。この HTML 応答は、要求が受信されていることを示します。

ESDEMO 以外のエンタープライズサーバへディプロイする場合は、ディプロイサービスが必要になります。

サービスには 1 つ以上のサービスリスナーが必要です。ビジネス機能を提供するサービスの場合は、要求ハンドラが 1 つ、サービスに関連する実装パッケージが 1 つそれぞれ必要です (システムサービスの場合にはハンドラやパッケージは必要ありません)。

サービスの詳細は、『サービス、パッケージ、および要求ハンドラ』の章を参照してください。

通信プロセス

通信プロセスオブジェクトは、通信プロセスを定義します。これについては、『エンタープライズサーバのアーキテクチャ』の節で説明しています。通信プロセスにはサービスリスナーがあります。新しいエンタープライズサーバを追加すると、そのサーバには、2 つのシステムサービスのリスナーを含む 1 つの通信プロセスが作成されます。そのエンタープライズサーバで予測されている作業負荷に対応するため、必要に応じてリスナーを追加できます。プロセスを希望どおりに定義した後は、既存の通信プロセスをコピーして通信プロセスを追加することができます。複数の通信プロセスをもつことの利点は次のとおりです。

通信障害が起きてもサーバが堅牢であること。1 つの通信プロセスに障害が発生しても、他のプロセスは継続してクライアントの要求を受信して処理し、応答を返すことができます。
サーバが処理できるクライアント要求の数が多くなること。通信プロセスはスレッドアーキテクチャを使用しているので、通信プロセスの数が増えると利用可能なスレッドの数も増えることになります。

通信プロセスの詳細は、『通信プロセスとサービスリスナー』の章を参照してください。

サービスリスナー

サービスリスナーオブジェクトには、サービスのために着信クライアント要求を受信するネットワークアドレスが含まれます。サービスには複数のリスナーを含むことができ、1 つのリスナーでは複数のサービスのためにクライアント要求を受信できます。

各サービスリスナーは 1 つのコネクタに関連付けられています。コネクタは、リスナーが処理する種類の要求を処理するロジックを含むソフトウェアです。

Enterprise Server には次のコネクタを含め、複数のコネクタが用意されています。

soap コネクタ。Web サービスの SOAP 要求と、J2EE 要求のために使用する Micro Focus 製の Binary Protocol の両方を処理します。
http-switch コネクタ。サービスのディプロイに使用し、簡単な Web サーバ機能を提供します。
http-echo コネクタ。接続テストに使用でき、HTTP 要求に対して短い HTML 応答を返します。

サービスリスナーの詳細は、『通信プロセスとサービスリスナー』の章、および『構成』の章にある『ディプロイサービスとディプロイリスナー』を参照してください。

要求ハンドラ

要求ハンドラオブジェクトは要求ハンドラを定義します。要求ハンドラは、クライアントからのサーバへのアクセス要求を受信し、要求をビジネス機能を提供するアプリケーションが解読できる形式に変換するプログラムです。アプリケーションが作業を完了すると、要求ハンドラはアプリケーションの出力をクライアントが解読できる形式に変換し、通信プロセスを介して出力をクライアントに返します。

SOAP プロトコルと Micro Focus 製のバイナリプロトコル用の要求ハンドラが提供されています。 SOAP プロトコル用の要求ハンドラは、ユーザ出口を使用してカスタマイズすることができます。

要求ハンドラの詳細は、『サービス、パッケージ、および要求ハンドラ』の章を参照してください。

実装パッケージ

実装パッケージオブジェクトには、サービスを提供する COBOL アプリケーションの情報が含まれています。パッケージは、IDT (interface definition table; インターフェイス定義テーブル) に関連付けられています。IDT には、クライアント要求を COBOL プログラムインターフェイスにマップするための情報が含まれています。

実装パッケージの詳細は、『サービス、パッケージ、および要求ハンドラ』の章を参照してください。

XA リソース

XA リソースオブジェクトには、XA 互換のデータベースマネージャに関する情報が含まれています。1 つまたは複数のコンテナ管理サービスに対してデータベースアクセスを行うには、このデータベースマネージャが必要です。

XA リソースの詳細は、この章の『リソース管理t 』の節と、『構成』の章の『リソースマネージャ』の節を参照してください。

リソース管理

データベースやファイルなどの外部リソースを使用するサービスを提供する COBOL アプリケーションは、独自のリソースを管理することも、独自のリソースをアプリケーションコンテナに管理させることもできます。独自のリソースを管理するサービスは、アプリケーション管理サービスと呼ばれます。独自のリソースを管理しないサービスは、コンテナ管理サービスと呼ばれます。

サービスが Fileshare を使用してファイルを更新する場合は、サービスが実行されるエンタープライズサーバに対して fhredir.cfg ファイル名とそのファイルの位置を指定する必要があります。詳細は、『構成』の章の『 Fileshare』の節を参照してください。

コンテナ管理サービス

サービスとして実行しているアプリケーションがデータベースとファイルを使用し、トランザクションロジックを含まない場合は、アプリケーションコンテナに独自のリソースを管理させることができます。

アプリケーションコンテナは、必要なリソースマネージャを事前に知る必要があります。リソースは、サービスごとではなく、エンタープライズサーバごとに定義します。 XA 互換のリソースマネージャのみ定義できます。

エンタープライズサーバとそのサービス実行プロセスを起動すると、エンタープライズサーバマネージャは、そのエンタープライズサーバ内のサービスに必要なすべてのリソースへの接続を開きます。コンテナ管理サービスを起動すると、エンタープライズサービスマネージャは必要なファイルアクションとデータベースアクションをすべて実行します。

アプリケーションコンテナは、XA コマンドを使用してデータベースを管理します。

アプリケーションコンテナは、サービスの作成時およびサービスの COBOL 開発システムへのディプロイ時に得た情報を使用して、リソースのコミットまたはロールバックを決定します。ただし、アプリケーションコンテナ自体にエラーがある場合には、リソースは必ずロールバックされます。

アプリケーション管理サービス

サービスは、次の場合に独自のリソースを管理する必要があります。

アプリケーションが、ファイルやデータベース (またはその両方) にトランザクションを使用してアクセスし、トランザクションロジックを含む場合。つまり、COMMIT と ROLLBACK トランザクションを含む場合。
アプリケーションが、Enterprise Server の環境でサポートされていないリソースマネージャを使用する場合 (readme の『補足情報』の節を参照)。

アプリケーションがトランザクションを使用しない (つまり、COMMIT と ROLLBACK を含まない) でファイルをアクセスするサービスは、アプリケーション管理サービスです。

トランザクションを使用するアプリケーション管理サービスの場合は、必要なすべてのトランザクションロジックを含む必要があります。つまり、すべてのリソースをコミットまたはロールバックする必要があります。

アプリケーション管理サービスの実行方法は、Net Express、Server Express、Micro Focus Server といった従来の実行環境でのアプリケーションの実行方法と類似していますが、主な違いのうちの 1 つは、サービスの実行終了時にプロセスが終了しないことです。

コンテナ管理サービスとアプリケーション管理サービスの混在

コンテナ管理サービスとアプリケーション管理サービスを同一のエンタープライズサーバ内に混在させることができます。ただし、この環境では、アプリケーション管理サービスはすべてのリソースをコミットまたはロールバックすることがより重要となります。これは、コンテナ管理アプリケーションのためにアプリケーションコンテナがリソースをコミットまたはロールバックする場合に、前回実行されたアプリケーション管理サービスの未処理の更新を含め、未処理のすべての更新をコミットまたはロールバックしてしまうためです。

リソースマネージャとして動作するエンタープライズサーバ

J2EE クライアントは、IBM WebSphere または BEA WebLogic などの J2EE アプリケーションで実行されます。サービスが J2EE クライアントからの要求を処理する場合に、J2EE アプリケーションサーバは、トランザクションに関連するリソースへのすべての更新を管理するトランザクションマネージャとすることができます。この場合には、エンタープライズサーバはリソースマネージャのように動作し、COBOL サーバがコンテナ管理であろうとアプリケーション管理であろうと、J2EE アプリケーションサーバからのコミット要求またはロールバック要求に応答します。

XAへの呼び出し時にエラーが発生した場合の再接続を行うオプション

環境変数 ES_XA_RECONNECT で値 YES が設定されていると、XAへの呼び出し時にエラーがあった場合、サーバーが SEP を再利用して、リソースマネージャへの再接続を試みます。

再接続できない場合は、サーバーは再接続の試行回数を監視します。

再接続の試行回数は環境変数 ES_XA_????_NB_RETRIES で制御されます。この環境変数で試行回数の最大値を指定することができます。

構文は次の通りです。

ES_XA_????_NB_RETRIES=number

???? : MFDS で定義された XA リソースの ID
number : 最大の試行回数

この環境変数が設定されていない場合の省略値の試行回数は5回で、その後、XAスイッチが使用不可になります。

設定例：

この環境変数は、[Enterprise Server Administration] > [サービス] > [編集] > [サーバー] > [プロパティ] > [一般] の構成情報に以下のように設定することができます。

[ES-Environment]
ES_XA_RECONNECT=YES
ES_XA_MFID_NB_RETRIES=1000

このオプション機能は、Server Express 5.1 WrapPack 4 以降で実装されています。

サービスインターフェイスのディプロイ

Interface Mapping Toolkit を使用して COBOL プログラムをマップした後、COBOL プログラムをエンタープライズサーバにディプロイする必要があります。ディプロイ処理の際、開発者は、Interface Mapping Toolkit の一部であるディプロイツールを用いてインターフェイスをディプロイします。このツールはエンタープライズサーバにインターフェイスを自動的にディプロイするだけでなく、COBOL アーカイブファイル (.car ファイル) にサービスをディプロイするために必要なファイルをすべてパッケージ化します。通常、運用環境でサービスを実行する準備がいったん整うと、ディプロイはユーザ側の責任になります。ディプロイツールが最後に使用されたときに作成された .car ファイルから、インターフェイスをディプロイします。

サービスが EJB インターフェイスとしてマップされている場合は、以下の作業も実行します。

EJB を J2EE アプリケーションサーバにディプロイする。
リソースアダプタをディプロイする。

.car ファイルからのディプロイと、EJB およびリソースアダプタのディプロイの詳細は、『インターフェイスのディプロイ』の章を参照してください。 Interface Mapping Toolkit を使用したインターフェイスの自動ディプロイの詳細は、『Interface Mapping Toolkit』の『 Interface Mapping Toolkit 』の章にある『ディプロイツール』の節を参照してください。

Enterprise Server の管理

Enterprise Server Administration ツールを使用して Enterprise Server を構成および管理できます。このツールを使用して、Directory Server が管理するエンタープライズサーバに関する情報を表示および変更できます。 Enterprise Server Administration には Web ブラウザからアクセスします。

Enterprise Server をいったん構成すると、Web インターフェイスのかわりに Enterprise Server のコマンドを使用して管理作業ができるようになります。コマンド行インターフェイスの詳細は、『サーバ』の章を参照してください。

管理作業は、特別な管理作業と日常の管理作業の 2 つに分類できます。エンタープライズサーバにサービス、サービスリスナー、要求ハンドラ、および実装パッケージをすべて定義した後は、日常の管理作業はそれほどありません。開発者が Interface Mapping Toolkit を使用して Enterprise Server へ直接ディプロイする場合は、必要なオブジェクト定義は自動的に作成されます。

特別な管理作業には、次の作業があります。

Directory Server の構成
サービス、要求ハンドラなどのオブジェクトの作成
オブジェクトの削除
サービスの再ディプロイ

日常の管理作業には、次の作業があります。

サーバの開始と停止
必要に応じたオブジェクトの編集
イベントに対応する他のオブジェクトの状態の変更。たとえば、ネットワーク障害に応じてリスナーを使用不能にします。
システムのパフォーマンスを最大にするパフォーマンスの監視とシステムのチューニング。たとえば、サーバ内のサービス実行プロセスの数を増やします。

他の章について

Directory Server とエンタープライズサーバを構成してから、Enterprise Server を起動します。構成の詳細は、『構成』の章を参照してください。

マップしたインターフェイスのエンタープライズサーバへのディプロイと、EJB としてマップしたサービスをディプロイするために必要な他の作業についての詳細は、『インターフェイスのディプロイ』の章を参照してください。

Directory Server への Web インターフェイスについては、『 Enterprise Server Administration の概要』を参照してください。 ESMAC (起動されたエンタープライズサーバでのみ使用できる管理機能のセット) については、『 ESMAC 使用によるサーバの管理』の章を参照してください。

Directory Server が管理するオブジェクトの詳細は、『サーバ』、『通信プロセスとサービスリスナー』、および『通信プロセスとサービスリスナー』、および『サービス、パッケージ、および要求ハンドラ』の章を参照してください。

トラブルシューティングの問題については、『トラブルシューティング』の章を参照してください。

Micro Focus 社が提供している要求ハンドラをカスタマイズする方法は、『要求ハンドラのユーザ出口』の章を参照してください。