図 1-1 ： エンタープライズサーバのアーキテクチャ
ここでは、Enterprise Server について説明します。
Enterprise Server は、COBOL アプリケーションプログラムの実行環境を提供します。この実行環境はエンタープライズサーバとして知られています。このマニュアルおよび関連マニュアルでは、用語「エンタープライズサーバ」は明記しない限り、製品ではなく、実行環境を意味します。
COBOL アプリケーションは、各種のクライアントが発行したサービス要求に応じてエンタープライズサーバ内で実行されます。COBOL 開発システムの一部である Interface Mapping Toolkit では、既存の COBOL アプリケーションをサービスとして公開できます。公開された COBOL サービスは、クライアントから Web サービスとして、または J2EE コネクタを介して起動できます。
サービスを実装する COBOL プログラムは、パラメータブロックを読み込んで処理し、処理した結果ブロックを返します。 この COBOL プログラムは、非対話式プログラムである必要があります。 サービスへのインターフェイスは、サービスの定義によって公開します。 すべての COBOL アプリケーションがサービスとして公開するのに適しているわけではありません。詳細は、『分散コンピューティング』の『Enterprise Server へのアプリケーションの実装』の章を参照してください。
エンタープライズサーバは、COBOL アプリケーションのセッション管理と状態管理を提供します。また、オプションで外部リソースマネージャとのインターフェイスを取り、リソースの更新の整合を取ります。
エンタープライズサーバは、初期化済みのサービス実行プロセスプールを提供します。COBOL アプリケーションはこのプール内で実行されます。 COBOL アプリケーションは独自のアドレス空間で実行されるため、エンタープライズサーバ内で実行されている他のプログラムから分離されます。 複数のプロセスを実行することで、クライアントの要求メッセージに対応する COBOL プログラムを同時に複数実行できます。
Enterprise Server をインストールすると、エンタープライズサーバが 1 つ自動的に設定されます。エンタープライズサーバは新規に作成することもできます。
エンタープライズサーバを実行するにはライセンスが必要です。詳細は、『ディプロイライセンスガイド』を参照してください。
唯一の前提条件として、クライアント側とサーバ側の両方のマシンで TCP/IP 通信ソフトウェアが実行されている必要があります。
エンタープライズサーバにはいくつかの構成要素があります。図 1-1 に、エンタープライズサーバのアーキテクチャの概要を示します。
図 1-1 ： エンタープライズサーバのアーキテクチャ
エンタープライズサーバには、複数のプロセスと、プロセス間通信で使用する領域が 1 つあります。
また、コンソールデーモン、サーバマネージャ、通信サーバがそれぞれ 1 つあります。 これらのプロセスは次の機能を実行します。
すべての種類の要求では、基本的な通信機構として TCP/IP を使用します。
エンタープライズサーバには、1 つ以上のサービス実行プロセスがあります。 サービス実行プロセスは、名前が示すように、クライアント要求を処理する COBOL プログラムを実際に実行するプロセスです。
プロセス間通信領域には、エンタープライズサーバ内で利用できるすべてのサービスの定義を保持する共有メモリがあります。 これらのサービスの定義は、図 1-1 に示す Directory Server で行われます。 Directory Server はエンタープライズサーバの外側に位置し、このため、複数のエンタープライズサーバの情報を保持できます。 また、プロセス間通信領域は、エンタープライズサーバのプロセス間で要求と応答を受け渡すためにも使用します。
サービスを提供する COBOL アプリケーションは、サービス実行プロセス内で実行されます。 エンタープライズサーバは、複数のサービス実行プロセスを含むことができます。 サーバを起動すると、サーバ内のすべてのサービス実行プロセスはクライアント要求を処理できます。 サービス実行プロセスが要求の処理を完了すると、別の要求の処理が可能になります。
要求は次のように処理されます。
図 1-2 に、サービス実行プロセスの構成要素を示します。
図 1-2 ： サービス実行プロセスの構成要素
トランザクション管理構成要素は、コンテナ管理サービスのトランザクションを管理します。つまり、COMMIT と ROLLBACK トランザクションを管理します。 リソースマネージャインターフェイスは、データベースやファイルアクセスなど、リソースへの要求を処理します。トランザクション管理とリソースマネージャの詳細は、『リソース管理』を参照してください。
Directory Server は、サービスと他の関連する構成要素を定義する一連の情報を管理するプロセスです。 Directory Server が取り扱う構成要素はオブジェクトと呼ばれます。 Directory Server のリポジトリには、オブジェクトに関する情報が格納されます。 Directory Server は、次の情報を管理します。
Interface Mapping Toolkit を使用して COBOL アプリケーションをサービスとしてディプロイすると、サービスの情報のほとんどが自動的に作成されます。 管理者は、必要に応じて情報を編集できます。
サーバオブジェクトは、Directory Server の最上位オブジェクトです。 他のオブジェクトは、サーバと切り離すことはできません。図 1-3 に、2 つのサービスがあるエンタープライズサーバを示します。 矢印はオブジェクト間の関係を示します。サーバに 1 つ以上のサービスを手動で設定する場合は (COBOL 開発システムからディプロイするのではなく)、オブジェクトをすべて作成してからオブジェクト間の関係をビルドします。
図 1-3 ： エンタープライズサーバ内のオブジェクト
デフォルトでは、Directory Server はエンタープライズサーバが実行されているマシンで実行されます。
Directory Server は、次の 2 種類のサーバオブジェクトに関する情報を格納します。
サーバの詳細は、『サーバ』の章を参照してください。
サービスオブジェクトはサービスを定義します。サービスにより、クライアントは、特定のビジネス機能にアクセスすることができます。
サービスには複数のオペレーションを含むことができます。 たとえば、計算プログラムでは加算、減算、乗算、および除算を行います。 各作業は、クライアントが、その機能へのインターフェイスを理解している場合に使用できる計算サービス内のオペレーションです。
エンタープライズサーバでは、エンタープライズサーバにディプロイするサービスのほかに、1 つ以上のシステムサービスを含むことができます。 デフォルトのエンタープライズサーバには、次の 2 つのシステムサービスがあります。
ESDEMO 以外のエンタープライズサーバへディプロイする場合は、ディプロイサービスが必要になります。
サービスには 1 つ以上のサービスリスナーが必要です。 ビジネス機能を提供するサービスの場合は、要求ハンドラが 1 つ、サービスに関連する実装パッケージが 1 つそれぞれ必要です (システムサービスの場合にはハンドラやパッケージは必要ありません)。
サービスの詳細は、『サービス、パッケージ、および要求ハンドラ』の章を参照してください。
サービスリスナーオブジェクトには、サービスのために着信クライアント要求を受信するネットワークアドレスが含まれます。 サービスには複数のリスナーを含めることができ、1 つのリスナーでは複数のサービスのためにクライアント要求を受信できます。
各サービスリスナーは 1 つのコネクタに関連付けられています。 コネクタは、リスナーが処理する種類の要求を処理するロジックを含むソフトウェアです。
Enterprise Server には以下に示すコネクタなどの、複数のコネクタが用意されています。
サービスリスナーの詳細は、『サービスリスナー』の章および『構成』の章にある『ディプロイサービスとディプロイリスナー』の項を参照してください。
要求ハンドラオブジェクトは要求ハンドラを定義します。 要求ハンドラは、クライアントからのサーバへのアクセス要求を受信し、要求をビジネス機能を提供するアプリケーションが解読できる形式に変換するプログラムです。 アプリケーションが作業を完了すると、要求ハンドラはアプリケーションの出力をクライアントが解読できる形式に変換し、通信サーバを介して出力をクライアントに返します。
SOAP プロトコルと Micro Focus 製のバイナリプロトコル用の要求ハンドラが提供されています。 ユーザ出口プログラムを使用して、SOAP プロトコル用の既存の要求ハンドラをカスタマイズできます。
要求ハンドラの詳細は、『サービス、パッケージ、および要求ハンドラ』の章を参照してください。
実装パッケージオブジェクトには、サービスを提供する COBOL アプリケーションの情報が含まれています。 パッケージは IDT (interface definition table; インターフェイス定義テーブル) に関連付けられています。IDT には、クライアント要求を COBOL プログラムインターフェイスにマップするための情報が含まれます。
実装パッケージの詳細は、『サービス、パッケージ、および要求ハンドラ』の章を参照してください。
データベースやファイルなどの外部リソースを使用するサービスを提供する COBOL アプリケーションは、独自のリソースを管理することも、独自のリソースをアプリケーションコンテナに管理させることもできます。 独自のリソースを管理するサービスは、アプリケーション管理サービスと呼ばれます。独自のリソースを管理しないサービスは、コンテナ管理サービスと呼ばれます。
サービスが Fileshare を使用してファイルを更新する場合は、サービスが実行されるエンタープライズサーバのfhredir.cfg ファイル名とその位置を指定する必要があります。 Fileshare の詳細は、『Fileshare ユーザガイド』を参照してください。
サービスは、次の場合に独自のリソースを管理する必要があります。
アプリケーションがトランザクションを使用しない (つまり、COMMIT と ROLLBACK を含まない) でファイルにアクセスするサービスは、アプリケーション管理サービスです。
トランザクションを使用するアプリケーション管理サービスの場合は、必要なすべてのトランザクションロジックを含む必要があります。つまり、すべてのリソースをコミットまたはロールバックする必要があります。
アプリケーション管理サービスは、Net Express、Server Express または Application Server などの従来の実行環境でのアプリケーションと同じように動作します。 主な違いのうちの 1 つは、サービスの実行終了時にプロセスが終了しないことです。
サービスとして実行しているアプリケーションがデータベースとファイルを使用し、トランザクションロジックを含まない場合は、アプリケーションコンテナに独自のリソースを管理させることができます。
アプリケーションコンテナは、必要なリソースマネージャを事前に知る必要があります。 リソースは、サービスごとではなく、エンタープライズサーバごとに定義します。 XA 互換のリソースマネージャのみ定義できます。 定義できるデータベースリソースマネージャの種類は次のとおりです。
エンタープライズサーバとそのサービス実行プロセスを起動すると、エンタープライズサーバマネージャは、そのエンタープライズサーバ内のサービスに必要なすべてのリソースへの接続を開きます。 コンテナ管理サービスを起動すると、エンタープライズサービスマネージャは必要なファイルアクションとデータベースアクションをすべて実行します。
アプリケーションコンテナは、XA コマンドを使用してデータベースを管理します。
アプリケーションコンテナは、サービスを作成し COBOL 開発システムにディプロイしたときに得た情報を使用して、リソースをコミットするかロールバックするかを決定します。詳細は、『分散コンピューティング』の『Interface Mapping Toolkit による COBOL Web Services の作成』の章を参照してください。 ただし、アプリケーションコンテナ自体にエラーがある場合には、リソースは必ずロールバックされます。
コンテナ管理サービスとアプリケーション管理サービスを同一のエンタープライズサーバ内に混在させることができます。ただし、この環境では、アプリケーション管理サービスはすべてのリソースをコミットまたはロールバックすることがより重要となります。 これは、コンテナ管理アプリケーションのためにアプリケーションコンテナがリソースをコミットまたはロールバックする場合に、前回実行されたアプリケーション管理サービスの未処理の更新を含め、未処理のすべての更新をコミットまたはロールバックしてしまうためです。
J2EE クライアントは、IBM WebSphere または BEA WebLogic などの J2EE アプリケーションで実行されます。 サービスが J2EE クライアントからの要求を処理する場合に、J2EE アプリケーションサーバは、トランザクションに関連するリソースへのすべての更新を管理するトランザクションマネージャとすることができます。 この場合には、エンタープライズサーバはリソースマネージャのように動作し、COBOL サーバがコンテナ管理であろうとアプリケーション管理であろうと、J2EE アプリケーションサーバからのコミット要求またはロールバック要求に応答します。
Enterprise Server Administration ツールを使用して Enterprise Server を構成および管理できます。 このツールを使用して、Directory Server が管理するエンタープライズサーバに関する情報を表示および変更できます。 Enterprise Server Administration には Web ブラウザからアクセスします。
Enterprise Server を構成した後は、一部の管理作業を、Web インターフェイスを使用する代わりに、Enterprise Server コマンドを使用して実行できます。 コマンド行インターフェイスの詳細は、『サーバ』の章を参照してください。
管理作業は、特別な管理作業と日常の管理作業の 2 つに分類できます。 エンタープライズサービスにサービス、サービスリスナー、要求ハンドラ、および実装パッケージをすべて定義した後は、日常の管理作業はそれほどありません。 開発者が Interface Mapping Toolkit を使用して Enterprise Server へ直接ディプロイする場合は、必要なオブジェクト定義は自動的に作成されます。
特別な管理作業には、次の作業があります。
日常の管理作業には、次の作業があります。
Directory Server とエンタープライズサーバを構成してから、Enterprise Server を起動します。構成の詳細は、『構成』の章を参照してください。
Directory Server への Web インターフェイスについては、『Enterprise Server Administration の概要』を参照してください。
Directory Server が管理するオブジェクトの詳細は、『サーバ』、『サービスリスナー』、および『サービス、パッケージ、および要求ハンドラ』の章を参照してください。
Micro Focus 社が提供している要求ハンドラをカスタマイズする方法は、『要求ハンドラのユーザ出口プログラム』の章を参照してください。
Copyright © 2004 Micro Focus International Limited.All rights reserved.