(57)【要約】【課題】  複数のシステム装置、ソフトウエアからなるＷｅｂベースの業務システムにおいて、業務システムの構築作業および運用作業の負担を軽減することを課題とする。【解決手段】  複数のシステム装置を有する業務システムに対する運用管理システムにおいて、記憶手段が、ユニット構成情報、共通インターフェースを構成する複数のメソッド、および、各メソッドに対応するプログラムとを記憶する。また、共通インターフェースは、少なくとも、前記ユニットに対して前記業務システムとしての動作を停止させる部分停止メソッドと、前記ユニットに対して前記業務システムとしての動作を再開させる部分再開メソッドとを有している。そして、演算処理手段が、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、所定システム装置を含むユニットに対して、部分停止させ、運用操作を行い、その後、部分再開させること。【選択図】      図１
2006127001.tif 000002
【特許請求の範囲】
【請求項１】
複数のシステム装置を有する業務システムを運用管理システムにより運用する業務システムの運用方法であって、
前記運用管理システムは、演算処理手段と記憶手段を有し、
前記記憶手段は、前記複数のシステム装置を所定数毎にそれぞれユニットとして関連付けて定義したユニット構成情報と、前記ユニットの構成パターンに関係なく不変な構築運用操作の共通インターフェースを構成する複数のメソッドと、その各メソッドに対応して実行され前記ユニットの構成パターンに依存して決定するプログラムとを記憶し、
前記共通インターフェースは、前記メソッドとして、少なくとも、前記ユニットに対して前記業務システムとしての動作を停止させる部分停止メソッドと、前記ユニットに対して前記業務システムとしての動作を再開させる部分再開メソッドとを有しており、
前記演算処理手段は、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記部分停止メソッドを実行することにより前記業務システムとしての動作を停止させる第１のステップと、前記運用操作を行う第２のステップと、前記運用操作終了後に前記部分再開メソッドを実行することにより前記業務システムとしての動作を再開させる第３のステップとを実行することを特徴とする業務システムの運用方法。
【請求項２】
前記業務システムは、外部通信装置からのアクセスを複数の前記ユニットに対して振り分ける負荷分散装置を含んで構成され、
前記共通インターフェースは、前記メソッドとして、さらに、前記負荷分散装置に対して所定ユニットへのアクセスの振り分けを停止させる振分停止メソッドと、前記負荷分散装置に対して所定ユニットへのアクセスの振り分けを再開させる振分再開メソッドとを有し、
前記演算処理手段は、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記第１のステップの前に、前記振分停止メソッドを実行することにより前記負荷分散装置に当該ユニットへのアクセスの振り分けを停止させる第４のステップを実行し、前記第３のステップの後に、前記振分再開メソッドを実行することにより前記負荷分散装置に当該ユニットへのアクセスの振り分けを再開させる第５のステップを実行することを特徴とする請求項１に記載の業務システムの運用方法。
【請求項３】
前記共通インターフェースは、前記メソッドとして、さらに、前記ユニット内のシステム装置が前記業務システムの一部としてサービスを提供するために必要なサービス定義情報を前記ユニット構成情報に基づいて作成するサービス定義メソッドと、前記サービス定義情報に基づいて各システム装置においてサービスをセットアップするセットアップメソッドと、前記サービス定義情報から各システム装置に関するコンフィグレーションファイルを作成および配布する設定メソッドとを有し、
前記演算処理手段は、前記業務システムの構築時に、前記ユニット構成情報を参照することで各ユニットに対してそれぞれ順番に、前記サービス定義メソッドを実行することにより前記サービス定義情報を作成する第６のステップと、前記セットアップメソッドを実行することにより各システム装置のセットアップを行う第７のステップと、前記設定メソッドを実行することにより各システム装置のコンフィグレーションファイルの作成および配布を行う第８のステップを実行することを特徴とする請求項１または請求項２に記載の業務システムの運用方法。
【請求項４】
前記共通インターフェースは、前記メソッドとして、さらに、前記ユニット内のシステム装置のアプリケーションを入れ替えるアプリケーション入替メソッドを有し、
前記演算処理手段は、所定システム装置に対する運用操作としてアプリケーションの入れ替えを行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記第２のステップとして、前記アプリケーション入替メソッドを実行することにより所定システム装置に対してアプリケーションの入れ替えを行うことを特徴とする請求項１または請求項２に記載の業務システムの運用方法。
【請求項５】
前記演算処理手段は、所定システム装置に対する運用操作として環境データであるパラメータの更新を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記第２のステップとして、予め変更されたパラメータを前記セットアップメソッドを実行することにより所定システム装置に反映させるステップと、前記設定メソッドを実行することにより所定システム装置のコンフィグレーションファイルの作成および配布を行うステップとを実行することを特徴とする請求項１または請求項２に記載の業務システムの運用方法。
【請求項６】
複数のシステム装置を有する業務システムに対する運用管理システムであって、
前記運用管理システムは、演算処理手段と記憶手段を有し、
前記記憶手段は、前記複数のシステム装置を所定数毎にそれぞれユニットとして関連付けて定義したユニット構成情報と、前記ユニットの構成パターンに関係なく不変な構築運用操作の共通インターフェースを構成する複数のメソッドと、その各メソッドに対応して実行され前記ユニットの構成パターンに依存して決定するプログラムとを記憶し、
前記共通インターフェースは、前記メソッドとして、少なくとも、前記ユニットに対して前記業務システムとしての動作を停止させる部分停止メソッドと、前記ユニットに対して前記業務システムとしての動作を再開させる部分再開メソッドとを有しており、
前記演算処理手段は、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記部分停止メソッドを実行することにより前記業務システムとしての動作を停止させ、前記運用操作を行い、前記運用操作終了後に前記部分再開メソッドを実行することにより前記業務システムとしての動作を再開させることを特徴とする運用管理システム。
【請求項７】
前記業務システムは、外部通信装置からのアクセスを複数の前記ユニットに対して振り分ける負荷分散装置を含んで構成され、
前記共通インターフェースは、前記メソッドとして、さらに、前記負荷分散装置に対して所定ユニットへのアクセスの振り分けを停止させる振分停止メソッドと、前記負荷分散装置に対して所定ユニットへのアクセスの振り分けを再開させる振分再開メソッドとを有し、
前記演算処理手段は、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記部分停止メソッドを実行することにより前記業務システムとしての動作を停止させる前に、前記振分停止メソッドを実行することにより前記負荷分散装置に当該ユニットへのアクセスの振り分けを停止させ、前記部分再開メソッドを実行することにより前記業務システムとしての動作を再開させた後に、前記振分再開メソッドを実行することにより前記負荷分散装置に当該ユニットへのアクセスの振り分けを再開させることを特徴とする請求項６に記載の運用管理システム。
【請求項８】
前記共通インターフェースは、前記メソッドとして、さらに、前記ユニット内のシステム装置が前記業務システムの一部としてサービスを提供するために必要なサービス定義情報を前記ユニット構成情報に基づいて作成するサービス定義メソッドと、前記サービス定義情報に基づいて各システム装置においてサービスをセットアップするセットアップメソッドと、前記サービス定義情報から各システム装置に関するコンフィグレーションファイルを作成および配布する設定メソッドとを有し、
前記演算処理手段は、前記業務システムの構築時に、前記ユニット構成情報を参照することで各ユニットに対してそれぞれ順番に、前記サービス定義メソッドを実行することにより前記サービス定義情報を作成し、前記セットアップメソッドを実行することにより各システム装置のセットアップを行い、前記設定メソッドを実行することにより各システム装置のコンフィグレーションファイルの作成および配布を行うことを特徴とする請求項６または請求項７に記載の運用管理システム。
【請求項９】
前記共通インターフェースは、前記メソッドとして、さらに、前記ユニット内のシステム装置のアプリケーションを入れ替えるアプリケーション入替メソッドを有し、
前記演算処理手段は、所定システム装置に対する運用操作としてアプリケーションの入れ替えを行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記運用操作として、前記アプリケーション入替メソッドを実行することにより所定システム装置に対してアプリケーションの入れ替えを行うことを特徴とする請求項６または請求項７に記載の運用管理システム。
【請求項１０】
前記演算処理手段は、所定システム装置に対する運用操作として環境データであるパラメータの更新を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記運用操作として、予め変更されたパラメータを前記セットアップメソッドを実行することにより所定システム装置に反映させ、前記設定メソッドを実行することにより所定システム装置のコンフィグレーションファイルの作成および配布を行うことを特徴とする請求項６または請求項７に記載の運用管理システム。
【請求項１１】
請求項１から請求項５までのいずれか１項に記載の業務システムの運用方法をコンピュータに実行させることを特徴とする運用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の装置やソフトウェアを組み合わせたスケーラブルで２４時間無停止の業務システムに対する運用方法、運用管理システムおよび運用プログラムに関する。
【背景技術】
【０００２】
近年のＷｅｂベースの業務システムは、高度化・複雑化が進み、そのシステム設計、キャパシティプランニング、構築、運用の負担が多大なものとなっている。一方、オンラインサービスなどに対する２４時間サービス提供の要求がますます高まっており、２４時間無停止でのメンテナンスのニーズが大きい。
Ｗｅｂベースの業務システムは、多数のシステム装置、ネットワークおよびソフトウエアからなり、そのトポロジあるいは構成は多種多様である。そのため、システム構成設計、システム運用設計、システム構築およびシステム自動運用プログラムの開発を、案件毎に特注で実施する必要がある。
【０００３】
たとえば、特許文献１では、プロセッサ装置、ストレージ装置およびネットワーク装置からなる業務システム（特許文献１では仮想サーバファームと記載）の構築運用作業のうち、初期構築作業および装置構成変更（プロセッサ装置の追加削除など）の自動化を実現する技術が開示されている。これらの自動化には、ＶＬＡＮ（Virtual Local Area Network）、ＳＡＮ（Strage Area Network）の設定、プロセッサ装置とオペレーティングシステム（ＯＳ、含むミドルウエア）ブートイメージとの関連付け、プロセッサ装置と負荷分散装置との関連付けが含まれるが、プロセッサ装置上で動作するミドルウエアの設定〔装置のトポロジに応じたＪ２ＥＥ（Java（登録商標） 2 Enterprise Edition：Ｒ）サーバおよびＨＴＴＰ（Hypre Text Transfer Protcol）サーバの設定、アプリケーションの配備〕は含まれていない。さらに、２４時間無停止での業務サービスの運用に関しては、仮想サーバファーム上で従来と同じように個別に運用設計し、運用プログラムを特注で開発する必要がある。
【０００４】
また、ティア横断的な運用管理の自動化という観点では、特許文献２において、マルチティアで構成される業務システムの、無停止でのソフトウエアバージョンアップの方法が開示されている。なお、ティアとは、物理層あるいは論理層という意味であり、以下、単に層と記載する場合も同義である。しかし、特許文献２では、Ｗｅｂベースの業務システムにおける、システム構成上の多様性という課題に対する解決法は示されておらず、ソフトウエアバージョンアップ以外の運用操作に対する２４時間無停止対応に関しても記載がない。
以上のように、特許文献１および特許文献２の課題は、多様なシステム構成のバリエーションを持つＷｅｂベースの業務システムに対して、多様な運用シナリオでの運用プログラムの設計・開発のフレームワーク化ができていない点である。
【０００５】
また、このフレームワークに関する課題に関して、非特許文献１では、システム構成のバリエーション毎に異なる運用操作ロジックと、汎用的に処理できるフレームワーク部分とを分離し、構成毎に異なる運用操作ロジック部分は、Configuration Provider Interfaceと呼ばれる共通インターフェースをサポートするプラグインプログラムとしてシステム構成のバリエーション毎に実装する技術が開示されている。そして、このフレームワークにより、運用操作のＧＵＩ（Graphical User Interface）部分の共通化がなされているが、ＧＵＩを除く大部分の処理は構成のバリエーション毎に特別に開発する必要があり、フレームワークにおける処理の共通化が不十分なままである。
【特許文献１】特表２００３−５０７８１７号公報（段落００１７〜００１９、図２）
【特許文献２】米国特許出願公開第２００３／０００５４２６号明細書
【非特許文献１】オファーバイラン外（Ofer Biran et al），「マルチティア・クラスタ・システムにおけるアプリケーション集合の管理（Management of Application Complexes in Multi-tier Clustered Systems）」，ＩＢＭシステムジャーナル（IBM System Journal），（米国），２００３，第４２巻（Vol.42），第１号（No.1）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
したがって、本発明は、複数のシステム装置、ソフトウエアからなるＷｅｂベースの業務システムにおいて、業務システムの構築作業および運用作業の負担を軽減すること、特に、２４時間無停止での業務システム運用に関する運用設計や運用プログラムの開発を軽減することを課題とする。
【課題を解決するための手段】
【０００７】
前記課題を解決するために、本発明は、複数のシステム装置を有する業務システムに対する運用管理システムにおいて、記憶手段が、ユニット構成情報、共通インターフェースを構成する複数のメソッド、および、各メソッドに対応するプログラムとを記憶する。また、共通インターフェースは、メソッドとして、少なくとも、前記ユニットに対して前記業務システムとしての動作を停止させる部分停止メソッドと、前記ユニットに対して前記業務システムとしての動作を再開させる部分再開メソッドとを有している。そして、演算処理手段が、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、所定システム装置を含むユニットに対して、部分停止させ、運用操作を行い、その後、部分再開させる。
【発明の効果】
【０００８】
本発明によれば、多数のシステム装置、ソフトウエアからなるＷｅｂベースの業務システムにおいて、業務システムの構築作業および運用作業の負担を軽減すること、特に、２４時間無停止での業務システム運用に関する運用設計や運用プログラムの開発を軽減することができる。
【発明を実施するための最良の形態】
【０００９】
本発明に係る業務システムに対する運用管理システムの実施形態について、まず、図１〜図３を参照しながら全体の構成や業務システムの構成について説明し、次に、図４〜図２６を参照しながら業務システムの構築と運用について説明する。なお、業務システムにおいて、構築とは、エンドユーザなどへのサービス提供の開始までに行われる作業や処理のことを指す。また、運用とは、狭義にはそのサービス提供開始以降の作業や処理のことを指すが、広義には構築も含めた概念を表わすものとする。
【００１０】
〔全体構成〕
図１に、業務システムと該業務システムを管理する運用管理システムを含む全体の構成を示す。運用管理者は、管理用端末システム装置１０１を利用して、運用管理システム１０２に接続し、業務システム１００を管理する。運用管理システム１０２は、プロセッサ、記憶部、通信部などから構成され、モジュールであるユーザインターフェース部１１１、プラグインファイルロード処理部１１６、システム構築運用制御処理部１１７などを用いることで、様々な処理や定義付けなどを行う。
【００１１】
管理用端末システム装置１０１、運用管理システム１０２および業務システム１００は、運用管理ネットワーク１０４で接続されている。業務システム１００は、業務トランザクション実行ネットワーク１０５にも接続され、業務トランザクションのデータは業務トランザクション実行ネットワーク１０５上で送受信される。業務トランザクション実行ネットワーク１０５はインターネット１０８とも接続され、エンドユーザの業務トランザクションをインターネット経由で受け付ける。
【００１２】
業務システム１００は、負荷分散装置１０７および複数の管理対象システム装置１０６（以下、単に「システム装置１０６」と記載）から構成される。なお、本実施形態ではネットワーク装置として負荷分散装置１０７を例にとって説明するが、他ネットワーク装置であるキャッシュサーバ、ファイアウォールなども本発明に適用可能である。負荷分散装置１０７は、インターネット１０８から送信されてくるデータを複数のシステム装置１０６に振り分ける機能を有しており、プロセッサ、記憶部、通信部などから構成される。なお、負荷分散装置１０７の負荷分散機能は、各システム装置１０６にソフトウェアとして組み込まれるようにしてもよい。
また、業務システム１００の多くはＤＢサーバを利用するが、本実施形態においては、運用管理システム１０２は業務システム１００のＤＢサーバを管理対象として含んでいない。しかし、業務システム１００におけるＤＢサーバの構成は、パラレルサーバ構成により複数システム装置から構成することができ、そして、その構築運用の簡略化には本発明の運用管理手法を適用することができる。さらに、本実施形態では、業務システム１００を、Ｊ２ＥＥベースのシステムであることを想定するが、本発明はＪ２ＥＥに限定されるものではない。
【００１３】
プラグインファイル１０３は、業務システム１００のシステム装置１０６の構成パターンの定義情報および運用プログラム（運用手順をプログラム化したもの）を保持するファイルであり、運用管理システム１０２を経由して管理対象システム装置１０６と接続された記憶手段１３１に格納されているものとする。なお、記憶手段１３１としては、磁気ディスク、光ディスクなどがあるが、記憶できる手段であれば他のものであってもよい。また、記憶手段１３１は、運用管理システム１０２の一部として一体に構成されていてもよい。
【００１４】
そして、プラグインファイルロード処理部１１６が、適切なタイミング（たとえば、運用管理システム１０２の起動時）に、プラグインファイル１０３を読み込み、読み込んだ内容を構成パターン定義テーブル１１３およびプラグインプログラムコード１１５として展開する。また、運用管理システム１０２の機能をＪａｖａ（登録商標）を用いて実現した場合、プラグインプログラムコード１１５は、Ｊａｖａ（登録商標）仮想マシン上のバイトコードとして実現され、Ｊａｖａ（登録商標）仮想マシン内のヒープ（メモリ）に格納される。プラグインファイル１０３は構成パターン毎に存在し、プラグインファイル１０３毎にプラグインプログラムコード１１５が存在する。
【００１５】
なお、業務システム１００を構成するシステム装置１０６のトポロジは多種多様であるが、その多様性は典型的な構成パターンに類型化することができる。そして、ユニット内のシステム装置１０６のトポロジおよびシステム装置１０６で稼働させるソフトウェアの配置構成は、構成パターンに応じた規則性を持つのである。そこで、ユニットに対してその構成パターンによらない基本的な運用操作の共通インターフェースを事前に定めておき、ユニット内の構成パターンに応じて作成された共通インターフェースの実装プログラムをユニットの定義情報と関連付けて管理することにより、業務システム１００の効率のよい構築や運用を行うことができるのである。
【００１６】
全体構成の説明に戻り、システム装置１０６は、プロセッサ、メモリ、ディスクストレージ、ネットワークインターフェースなどからなる装置であり、オペレーティングシステム（ＯＳ）およびＯＳ上の各種サービス（プロセス）である管理サービス対象群１１０が稼動する。なお、本実施形態において、「システム装置」とは、いわゆるサーバとほぼ同義であり、また同じ意味で「ホスト」、「サーバマシン」という表現も使用する。
本実施形態では、サービスとして、ＨＴＴＰプロトコルを処理するＨＴＴＰサービス、Ｊ２ＥＥの機能を実現するＪ２ＥＥサービス、サービス実行中のエラー情報や性能情報を収集するロギングサービスなどを想定する。システム装置１０６においては、業務用の管理対象サービス群１１０に加えて、管理エージェントサービス１１９も稼動している。管理エージェントサービス１１９は、運用管理システム１０２が業務システム１００を管理するときに機能するソフトウェアである。
【００１７】
業務システム１００に対する運用管理作業には多種多様な作業が存在するが、大きく、初期構築作業（初期構築後のシステム装置の追加と削除も含む）と日常運用作業の２つに分類できる。
【００１８】
初期構築作業はさらに、業務システム１００のインフラストラクチャレベルの構築作業と業務レベルの構築作業の２つに分類することができる。前者のインフラストラクチャレベルの構築作業には、ネットワーク環境の設定（ＩＰアドレス、ＶＬＡＮ、ＳＡＮの設定など）や、オペレーティングシステムやミドルウエアなどのソフトウエアのインストールなどがあり、インフラストラクチャレベルの構築作業の終了後に、業務レベルの構築作業を実施する。業務レベルの構築作業には、管理対象サービス（以下、単に「サービス」と記載）のセットアップ、設定情報の配布、業務アプリケーション（以下、単に「アプリケーション」と記載）のデプロイなどがある。日常運用作業には、サービスの設定変更、アプリケーションのバージョンアップ、システムの計画停止/起動などがある。
本実施形態は、初期構築作業の業務レベルの構築部分と日常運用作業の簡略化/セミ自動化を実現する。インフラストラクチャレベルの構築作業に関しては、特許文献１などに開示された従来技術あるいはマニュアル作業で事前に実施されていることを想定している。
【００１９】
管理者による、運用管理システム１０２を利用した、業務システム１００の構築運用の大きな流れは、次のようになる。
まず、管理者はユーザインターフェース部１１１を介して、業務システム１００に対するシステム構成定義を行い、定義情報をシステム構成定義テーブル群１１４に格納する。次に、管理者は、業務システム１００の環境構築および運用の実行を、ユーザインターフェース部１１１に命令する。ユーザインターフェース部１１１は該命令をシステム構築運用制御処理部１１７に伝え、システム構築運用制御処理部１１７は、システム構成定義テーブル群１１４の情報に基づいてプラグインプログラムコード１１５を制御し、環境構築および運用に必要な命令列および設定ファイルを、負荷分散装置１０７あるいはシステム装置１０６に送信する。
システム装置１０６において、管理エージェントサービス１１９が該命令列および設定ファイルを受信し、システム装置１０６上の各種管理対象サービス群１１０に対する環境構築および運用操作命令を実行する。たとえば、サービスがＨＴＴＰサービスの場合、設定ファイルとしてｈｔｔｐｄ．ｃｏｎｆがあり、運用操作命令としてＨＴＴＰサービスの起動停止用のコマンドがある。
【００２０】
管理エージェントサービス１１９の好適な実現方法としては、設定ファイルの送受信にはＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を、運用操作の命令列の発行には、Ｔｅｌｎｅｔなどを利用する方法がある。
負荷分散装置１０７の好適な例としては、Ｔｅｌｎｅｔなどによる命令列の送受信や、ＦＴＰあるいはＴＦＴＰ（Ｔｒｉｖｉａｌ Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などにより設定ファイルの送受信を行うものがある。
システム構成定義テーブル群１１４は、基本情報テーブル１３００（図１３）、負荷分散装置定義テーブル１４００（図１４）、ティア共通サービス環境定義テーブル１５００（図１５）、ユニット構成定義テーブル１６００（図１６）、サーバマシン定義テーブル１７００（図１７）およびサービスインスタンス定義テーブル１８００（図１８）からなる。
【００２１】
〔構成パターンとユニットの概念〕
本実施形態で想定する、業務システム１００の構成パターンのバリエーションと、閉塞可能な単位であるユニットの概念を、図２および図３を参照しながら説明する。
図２は、業務システム１００の基本的な構成パターンであり、２層構造になっている。第１の層２０１は、ＨＴＴＰサービス、Ｊ２ＥＥサービスおよびロギングサービスを稼動させたシステム装置２０５をクラスタ構成としたものである。
第２の層２０２はデータ層でありＤＢＭＳ用のシステム装置２０６からなる。ＤＢＭＳも複数システム装置を用いてクラスタ構成としてもよい。負荷分散装置１０７は第１の層２０１に対して負荷分散を行う。なお、システム装置２０５、２０６は、図１のシステム装置１０６に対応する。
層（ティア）の定義はすでに前記したが、さらに加えて説明すると、層とは、同種の機能を有するシステム装置の集合であり、特定の層に属するシステム装置上には、同一種類のサービスを同じコンフィグレーション（設定）で稼動させる。
【００２２】
この層の概念に対して、システム装置２０５およびその上で稼動する管理対象サービス群２１０、２１１、２１２のまとまりをユニットと呼ぶ。ユニットの特徴は、特定のユニットを停止しても、業務システム１００全体としては停止せずに縮退モードで動作することができることである。２４時間無停止で、図２の構成の業務システム１００をメンテナンスする場合、ユニット単位で、停止、メンテナンス、再開を繰り返し実行すればよい。したがって、ユニットを、業務システム１００を構成する部分であり、業務システム１００全体を停止することなく停止・再開できる単位と定義する。
【００２３】
図３は、図２の第１の層２０１を２つに分離することにより３層構造とし、第１層３０１と第２層３０２の装置間の接続関係を１：１とした構成である。第１層３０１はＨＴＴＰサービスおよびロギングサービスを稼動させたシステム装置３１１、３１３の集合（ＨＴＴＰティアと呼ぶ）である。第２層３０２はＪ２ＥＥサービスおよびロギングサービスを稼動させたシステム装置３１２、３１４の集合（Ｊ２ＥＥティアと呼ぶ）である。なお、システム装置３１１〜３１４は、図１のシステム装置１０６に対応する。
第３層２０２は、図２の場合と同様にＤＢＭＳ用のシステム装置２０６からなる。システム装置３１１、システム装置３１２およびそれら上で稼動する管理対象サービス群３２１〜３２４が、部分縮退可能な単位であるユニット３０４を形成する。図２の構成と比べ、図３の構成の特徴的な点は、ユニットがティア横断的である、つまり、ユニットが第１層３０１および第２層３０２のシステム装置の両方を含んでいる点である。図３の業務システム１００は、ユニット３０４とユニット３０５の２ユニットから構成される。
【００２４】
なお、第１層３０１と第２層３０２の装置間の接続関係には１：１（図３の場合）以外に、Ｎ：１、１：Ｎ、Ｍ：Ｎの３つのバリエーションがある。
Ｎ：１の場合、第２層３０２のシステム装置１つに対して、第１層３０１のシステム装置が複数接続され、接続関係にある第１層３０１の複数のシステム装置と第２層３０２のシステム装置１つがユニットを形成し、さらにユニットが複数集まって業務システム１００を構成する。
【００２５】
１：Ｎの場合、第１層３０１のシステム装置１つに対して、第２層３０２のシステム装置が複数接続され、接続関係にある第１層３０１の単一システム装置と第２層３０２の複数システム装置がユニットを形成する。第１層３０１のシステム装置１つが第２層３０２の複数のシステム装置に対して負荷分散を行う必要があり、Ｎ：１の場合と異なる設定・運用が必要となる。
【００２６】
Ｍ：Ｎの場合は、第１層３０１の任意のシステム装置は第２層３０２のシステム装置すべてと接続関係にあり、第１層３０１の任意のシステム装置は第２層３０２のシステム装置すべてに対して負荷分散を行う。第１層３０１と第２層３０２がメッシュで接続されるため、第１層３０１および第２層３０２に含まれるシステム装置は各々独立に停止し、業務システム１００全体として部分縮退可能である。したがって、第１層および第２層のシステム装置の各々をユニットとする。
【００２７】
第１層３０１と第２層３０２のシステム装置に対するサービスの配置にもバリエーションがある。Ｊ２ＥＥサービスは、一般にＷｅｂコンテナ機能とＥＪＢ（Enterprise Java(登録商標) Beans）コンテナ機能という２つの機能からなることから、第１層３０１のシステム装置にＨＴＴＰサービスおよびＷｅｂコンテナとしてのＪ２ＥＥサービスを稼動させ、第２層３０２のシステム装置にＨＴＴＰサービスおよびＥＪＢコンテナとしてのＪ２ＥＥサービスを稼動させるバリエーションがある。
【００２８】
また、より可用性を高めた構成として、たとえば、図２の符号２０５のシステム装置を単一の装置で実現するのではなく、現用系と待機系の２系統のシステム装置から実現する構成（フェイルオーバー構成）がある。図２の拡張であるフェイルオーバー構成のバリエーションでは、各ユニット２０３、２０４は各々現用系と待機系の２つのシステム装置からなる。
【００２９】
以上のように、ユニットという管理単位を規定することで、業務システム１００の多様な構成のいずれにおいても、複数のユニットからなる集合として正規化することができる。ユニットとは部分閉塞再開可能な業務システムの一部分を抽象化したものであるので、特定のユニットを停止した場合、業務システム１００は停止したユニットを除く残りのユニットで縮退動作を行い、業務システム１００全体としては停止しない。また、ユニット内の構成は業務システム１００の取りうる構成パターンにより異なる。
【００３０】
本実施形態の説明では、業務システム１００の構成パターンのバリエーションとして、システム装置の多層構成、多層構成における層間の接続トポロジ、システム装置上のサービスの配置および装置のフェイルオーバー構成に関するバリエーションを取り上げ説明した。その他考えられるバリエーションとして、負荷分散装置１０７のフェイルオーバー構成、ＤＢのパーティションニング構成、ＤＢのパーティションニング構成に即したＪ２ＥＥサーバ用装置の構成などがあり、ユニットの考え方はこれらのバリエーションにも適用可能である。
【００３１】
本発明の特徴は、ユニットと呼ぶティア横断的な管理単位を設け、また各メソッドから構成される共通インターフェース５０１を利用することにより、業務システム１００の多様な構成パターンにおいて、２４時間無停止運用の運用プログラムをシステム構築運用制御処理部１１７として共通化し、ユニット内の構成パターンに依存する部分はプラグインファイル１０３として局所化することが可能となっている点である。このシステムレベル（ユニット以上の単位）の運用ロジックの共通化とユニット内の動作の局所化により、新規構成パターンへの対応は局所化された運用ロジックの部分的な追加で対応することが可能となる。
【００３２】
以降において、図３の業務システム１００の構成を例にとって、プラグインファイル１０３の構造（図４）、システム構成定義の構造と定義手順（図５〜図１８）、システムレベルの運用ロジックの構成パターンによらない共通処理フロー（図１９〜図２１）、構成パターンに依存する運用ロジックの処理フロー（図２２〜図２６：プラグインプログラムの実装部分）の順で説明する。
【００３３】
〔プラグインファイルの構造とそのロード処理〕
図４は、プラグインファイル１０３のファイル構成と構成パターン定義例を示したものである。
プラグインファイル１０３は、構成パターンのメタ情報を保持する構成パターン定義部４０１と、構成パターンに即したユニットの運用動作を実装したプログラム部４０２からなる。構成パターン定義部４０１はＸＭＬ（Extensible Markup Language）に基づくテキストファイルで、その具体的な例が構成パターン定義４１０であり、構成パターン定義４１０の左側の数字は定義ファイル内の行番号を示す。プログラム部４０２の好適な実現例は、図５に示すＪａｖａ（登録商標）インターフェースを実装したＪａｖａ（登録商標）ソースプログラムをＪａｖａ（登録商標）コンパラによりコンパイルした結果出力されるＪａｖａ（登録商標）クラスファイルである。プラグインファイル１０３は、構成パターン定義部４０１のテキストファイルとプログラム部４０２のクラスファイルをＪａｖａ（登録商標） Ａｒｃｈｉｖｅ形式でアーカイブ化したファイル（Ｊａｒファイル）である。
【００３４】
次に、構成パターン定義４１０について説明する。１行目（４１２）で本構成パターンの構成パターン名を指定し、２行目から５行目（４１３）にかけて構成パターンの特徴を自然言語で説明している。６行目（４１４）には、ＧＵＩツールと連動する際、ＧＵＩツール上で構成パターンの特徴を画像表示する際に利用する画像ファイルのパス情報が指定されている。なお、画像ファイルはプラグインファイル１０３に同梱されており、パス情報により画像ファイルが存在するアーカイブファイル内の位置を指定する。
【００３５】
７行目から１７行目（４１５）にかけて、層（ティア）の構造が定義され、図３の構成パターンは“ＨＴＴＰティア”と呼ばれる第１層３０１と“Ｊ２ＥＥティア”と呼ばれる第２の層３０２からなり、ＨＴＴＰティア３０１に属するシステム装置上にはＨＴＴＰサービスとロギングサービスを稼動させることを定義し（４１６）、Ｊ２ＥＥティア３０２に属するシステム装置上にはＪ２ＥＥサービスとロギングサービスを稼動させることを定義している（４１７）。
【００３６】
図５は、前記したようにプログラム部４０２の実現例であり、ユニット運用操作のＪａｖａ（登録商標）インターフェースである共通インターフェース５０１を示す図である。共通インターフェース５０１の左側の数字は、インターフェース定義の行番号を示す。共通インターフェース５０１は、図２および図３で説明した業務システム１００の多様な構成パターンに対して、共通に定義される運用操作インターフェースである。ただし、共通インターフェース５０１の実装は構成パターン毎に異なる。また、基本的にすべてのオペレーションは操作対象のシステム名とユニット名を引数として指定する。システム名は第１引数のsystem-idで、ユニット名は第２引数のunit-idで指定する。
【００３７】
共通インターフェース５０１の各メソッドの機能について簡単に説明する。２行目のcreateServiceDefintionsは、業務システム１００の構成パターンに即してユニット内のサービスの定義情報を自動生成するメソッドである。３行目のsetupServicesは、構成パターンのサービス構成に即してサービス群をセットアップするメソッドである。４行目のunsetupServicesは、３行目のsetupServicesでセットアップされたサービスを削除するメソッドである。５行目のstartServicesは、ユニット内のサービス群を開始するメソッドである。６行目のstopServicesは、ユニット内のサービス群を停止するメソッドである。７行目のdistributeConfigurationは、設定ファイルをシステム装置１０６に配布するメソッドである。８行目のdeployApplicationsは、ユニット内のサービスにアプリケーションを配備するメソッドである。９行目のredeployApplicationsは、ユニット内のサービスにアプリケーションを再配備するメソッドである。
【００３８】
１０行目のundeployApplicationsは、ユニット内のサービスからアプリケーションを削除するメソッドである。１１行目のstartApplicationsは、ユニットに配備したアプリケーションを開始するメソッドである。１２行目のstopApplicationsは、ユニットに配備したアプリケーションを停止するメソッドである。１３行目のjoinVirtualServerは、ユニットを負荷分散装置１０７の振り分け対象に追加するメソッドである。１４行目のleaveVirtualServerは、ユニットを負荷分散装置１０７の振り分け対象から削除するメソッドである。また、１５行目のacceptRequestは、負荷分散装置１０７がインターネット１０８経由で受信するユーザトランザクションをユニット内のシステム装置１０６にルーティングするメソッドである。１６行目のblockRequestは、負荷分散装置１０７がインターネット１０８経由で受信するユーザトランザクションに対するユニット内のシステム装置１０６へのルーティングを停止するメソッドである。
このように、各メソッドにより共通インターフェース５０１が構成され、それが記憶手段１３１に記憶されている。
【００３９】
図６に、構成パターン定義テーブル１１３の詳細を示す。構成パターン定義テーブル１１３は、構成パターン名フィールド６０１、クラスアドレスフィールド６０２、説明用テキストフィールド６０３、画像用ＵＲＬフィールド６０４、ティア名フィールド６０５およびサービス種別名フィールド６０６の６つフィールド（カラム）からなるテーブルである。
構成パターン名フィールド６０１は、図４の符号４１２に対応する。クラスアドレスフィールド６０２は、プラグインプログラムコード１１５のＪａｖａ（登録商標）仮想マシン（ＶＭ）ヒープ上のアドレス情報を保持する。説明用テキストフィールド６０３は、図４の符号４１３に対応する。画像用ＵＲＬフィールド６０４は、図４の符号４１４に対応する。ティア名フィールド６０５は、図４の符号４１５に対応する。定義フラグメントである４１５の部分は２つのティアから構成されることを示しており、それぞれレコード６１１とレコード６１２のように展開される。サービス種別フィールド６０６は、図４の符号４１６および符号４１７に対応し、それぞれ、レコード６２１、６２２およびレコード６２３、６２４のように展開される。
【００４０】
プラグインファイルロード処理部１１６によるプラグインファイル１０３のロード手順は、次のとおりである。まず、記憶手段１３１上の特定のディレクトリ下にあるファイル一覧を取得する。次に、取得したファイル一覧の各ファイルに対して、プラグインファイル１０３を読み込み、構成パターン定義４１０を構成パターン定義テーブル１１３に展開し、プログラム部４０２のクラスファイルをＪａｖａ（登録商標）ＶＭのヒープ上にバイトコード（クラス）として展開し、そのアドレス情報を構成パターン定義テーブル１１３のクラスアドレスフィールド６０２に設定する。
【００４１】
〔管理者によるシステム構成定義の画面と手順〕
図７から図１２は、管理者によるシステム構成定義の手順を示したものである。管理者が定義した情報は、図１３から図１７に示すテーブル群に格納される。これらの画面は、ユーザインターフェース部１１１が制御し、表示する。
【００４２】
図７に、システム構成パターン選択画面７００を示す。運用管理システム１０２が構成パターン定義テーブル１１３に格納されているパターン名（フィールド６０１）の一覧をプルダウンメニュー７０１として表示する。管理者は、プルダウンメニュー７０１から適切な構成パターン名を選択し、テキストフィールド７０５にシステム名を入力し、ボタン７０２をクリックし、次画面である負荷分散装置定義画面８００（図８）に遷移する。図３の業務システム１００の場合、プルダウンメニュー７０１から選択すべき適切な構成パターンは“ＨＴＴＰ分離２ティア構成”である。符号７０３の画像および符号７０４の説明文は、それぞれ構成パターン定義テーブル１１３の画像用ＵＲＬフィールド６０４および説明用テキストフィールド６０３に対応する。
【００４３】
システム構成パターン選択画面７００でのユーザ入力情報は、図１３に示す基本情報テーブル１３００に格納される。テキストフィールド７０５の値はテーブル１３００のシステム名フィールド１３０１に格納され、プルダウンメニュー７０１で選択された構成パターン名はパターン名フィールド１３０２に格納される。
レコード１３１１は、図３に示す業務システム１００のシステム名が“システム１”であり、それが構成パターン“ＨＴＴＰ分離２ティア構成”に属していることを示している。構成パターン名１３０２の値をキーに、構成パターン定義テーブル１１３を検索することにより、構成パターンのメタ情報を参照することができる。
【００４４】
図８に、負荷分散装置１０７の負荷分散装置定義画面８００を示す。管理者は、負荷分散装置１０７の論理名称８０１、運用管理ＩＰアドレス８０２、仮想サーバのＩＰアドレス８０３、ポート番号８０４を入力し、ボタン８０５をクリックすることにより次画面であるサービス環境定義画面９００（図９）に遷移する。運用管理ＩＰアドレス８０２は、運用管理システム１０２が負荷分散装置１０７に運用管理命令列を発行する際、負荷分散装置１０７に接続するのに利用するＩＰアドレスである。仮想サーバのＩＰアドレス８０３は、いわゆるＶＩＰ（Ｖｉｒｔｕａｌ ＩＰ）と呼ばれるアドレスであり、エンドユーザがインターネット１０８を介して業務システム１００に接続する際に利用するＩＰアドレスである。
【００４５】
負荷分散装置定義画面８００でのユーザ入力情報は、図１４に示す負荷分散装置定義テーブル１４００に格納される。論理名称８０１、運用管理ＩＰアドレス８０２、仮想サーバのＩＰアドレス８０３、ポート番号８０４はそれぞれ、テーブル１４００の負荷分散装置名フィールド１４０１、運用管理ＩＰアドレスフィールド１４０３、仮想ＩＰアドレスフィールド１４０４、ポート番号フィールド１４０５に格納される。システム名フィールド１４０２には、そのとき定義中のシステムの名称（７０５の値）が格納される。図８の負荷分散装置定義画面８００での入力例が、レコード１４１１として格納されている。
【００４６】
図９に、ティア共通のサービス環境定義（パラメータ定義）画面９００を示す。図３に示すように、異なるユニットのサービスにおいても、それぞれのユニットに属するサービスが同一層（ティア）に属する場合、これらサービスのパラメータ定義は基本的に同じとなる。たとえば、図３の第２層３０２に属するＪ２ＥＥサービス３２３の場合、ユニット３０４とユニット３０５のそれぞれに対してＪ２ＥＥサービスを定義する必要があるが、これら２つのサービスは共通の環境定義（パラメータ定義）を持つため、サービス種別単位で一括して定義する。ただし、すべてのパラメータがサービス種別単位で一括して定義できるわけではなく、トポロジや構成により定まり個別サービスインスタンス毎に値が異なるパラメータもある。トポロジや構成により定まるパラメータの解決方法は、図２２のcreateServiceDefinitionsで説明する。
【００４７】
図９のサービス環境定義画面９００で、メニュー９０１、９０２から定義対象の層（ティア）とサービス種別を選択し、サービス種別毎の環境定義を一括して行う。図９は、Ｊ２ＥＥティア上のＪ２ＥＥサービスに共通な環境定義を行う（フィールド９０３部分に対応）場面を示している。環境定義は、各種パラメータに対して適切な値を入力あるいは選択することにより行う。環境定義対象のサービス種別がＪ２ＥＥサービスの場合、さらに、Ｊ２ＥＥアプリケーションの指定も必要であり、フィールド９１１にて、Ｊ２ＥＥアプリケーションのファイルパスを指定する。すべての層（ティア）のサービスの環境定義が終了した場合、ボタン９０５をクリックして、次画面であるユニット構成定義画面１０００（図１０）に遷移する。
【００４８】
サービス環境定義画面９００でのユーザ入力情報は、図１５に示すティア共通サービス環境定義テーブル１５００に格納される。そのとき定義中のシステムのシステム名７０５がティア共通サービス環境定義テーブル１５００のシステム名フィールド１５０１に格納される。メニュー９０１および９０２で選択した環境定義対象のティアとサービス種別の情報を、それぞれ、ティア名フィールド１５０２およびサービス種別名フィールド１５０３に格納する。フィールド９０３で定義したパラメータ定義情報は、パラメータ名と入力値からなる名前値ペアのリストとして環境定義フィールド１５０４に格納される。フィールド９１１で定義したアプリケーション情報はアプリケーション情報フィールド１５０５に格納される。
【００４９】
図９のサービス環境定義画面９００での入力例が、上から３つめのレコード１５１１として格納されている。なお、レコード１５１１の定義は、Ｊ２ＥＥティア３０２上の任意のユニット内のＪ２ＥＥサービスに対する共通の定義に関してのみであり、個別サービスインスタンスに関する環境定義（たとえばＪ２ＥＥサービス３２３に対する個別の環境定義）は、レコード１５１１の内容に基づいて、図２２で説明するcreateServiceDefintionsで生成する。
【００５０】
図１０、図１１は、ユニットの構成とシステム装置の配置を定義する画面である。図１０のユニット構成定義画面１０００において、ユニットの追加の場合、ボタン１０１１をクリックすることにより新規ユニットが追加され、ユニットの削除の場合、ボタン１０１２をクリックすることにより削除を行う。
ユニット追加時には、符号１０２０の行が新たに追加される。図１０は、ユニットがまったく定義されていない状態からボタン１０１１をクリックした直後の画面イメージである。
１０２０の行が追加されたのち、新規ユニットのユニット名フィールド１００１にユニット名を入力し、システム装置選択プルダウンメニュー１００２および１００３から、システム装置を１つずつ選択し、それぞれをＨＴＴＰティアおよびＪ２ＥＥティアのシステム装置とする。以上の操作により、図３のユニット３０４がユニット名“ユニット１”として定義され、ユニット３０５も同様にして定義する。
【００５１】
ユニット構成定義画面１０００でのユーザ入力情報は、図１６に示すユニット構成定義テーブル１６００に格納される。
ユニット名の指定（１００１）と新規ユニット内に配置するサーバマシンを２つ選択（１００２、１００３）したことにより、ユニット構成定義テーブル１６００に対して新規レコードが２つ追加される。追加された２つのレコードの各々に対して、そのとき定義対象となっているシステムのシステム名７０５の値がシステム名フィールド１６０１に、ユニット構成定義画面１０００のユニット名１００１で指定した値がユニット名フィールド１６０２に、選択したサーバマシン名（１００２の値あるいは１００３の値）がサーバマシン名フィールド１６０３に、サーバマシンが属するティア名（１００２の場合は“ＨＴＴＰティア”、１００３の場合“Ｊ２ＥＥティア”となる）がティア名フィールド１６０４に格納される。図１０のユニット構成定義画面１０００での入力例で生成された新規レコードは、レコード１６１１、レコード１６１２に対応している。
【００５２】
プルダウンメニュー１００２あるいは１００３に所望のシステム装置が事前に定義されていない場合は、プルダウンメニューから新規１００４を選択し、サーバマシン定義画面１１００（図１１）に遷移し、システム装置を定義する。システム装置の定義は、システム装置の論理名であるサーバマシン名１１０１、業務トランザクション実行ネットワーク１０５上のＩＰアドレスである業務実行ＩＰアドレス１１０２、運用管理ネットワーク１０４上のＩＰアドレスである運用管理ＩＰアドレス１１０３および管理エージェントサービス１１９のポート番号である運用サービスポート番号１１０４からなる。
【００５３】
サーバマシン定義画面１１００でのユーザ入力情報は、図１７に示すサーバマシン定義テーブル１７００に格納される。図１１のサーバマシン定義画面１１００のサーバマシン名１１０１、業務実行ＩＰアドレス１１０２、運用管理ＩＰアドレス１１０３、運用サービスポート番号１１０４を、それぞれ、サーバマシン定義テーブル１７００のサーバマシン名フィールド１７０１、実行ＩＰフィールド１７０２、管理ＩＰフィールド１７０３、管理ポートフィールド１７０４に格納する。図１１のサーバマシン定義画面１１００での入力例が、レコード１７１１として格納されている。以上の操作により、業務システム１００を、図３に示す構成の業務システム１００として定義できた。次に、これらの定義を元に、業務システム１００の構築、運用の処理について説明する。
【００５４】
〔システムレベルの構築運用ロジック：システム構築運用制御処理部１１７の処理フロー〕
共通インターフェース５０１を利用した、業務システム１００の構成に依存しない汎用的な、業務システム１００の構築、運用の手順（システム構築運用制御処理部１１７による処理）を、図１９〜図２１に示す。図１９および図２０は業務システム１００の構築に関しての処理であり、図２１は業務システム１００の運用に関しての処理である。そして、図１９〜図２１の手順中の各メソッド（図５）の処理については、図２２〜図２６を参照しながら説明する。
【００５５】
図１９から図２１において、システム構築運用制御処理部１１７が共通インターフェース５０１のメソッドを起動する。その起動手順は、操作対象の業務システム１００が属するパターン名を基本情報テーブル１３００のパターン名フィールド１３０２から取得し、パターン名に対応する共通インターフェース５０１の実装クラスのクラスアドレスを構成パターン定義テーブル６００のクラスアドレスフィールド６０２から取得する。そして、Ｊａｖａ（登録商標）言語のＲｅｆｌｅｃｔｉｏｎ機能を利用することにより、実装クラスのメソッドを呼び出す。
【００５６】
図１９は、システム構築運用制御処理部１１７による業務システム１００の構築手順を示したフローチャートである。本手順は図１０のボタン１００５のクリックを契機に実行される。本手順の実行により、システム装置内の各種サービスのセットアップと環境設定が終了し、業務システム１００が起動可能な状態となる。
【００５７】
まず、構築対象のシステム装置（３１１〜３１４）の名称をキーに負荷分散装置定義テーブル１４００から定義情報を取得し、負荷分散装置定義に基いて、負荷分散装置１０７に接続し、仮想サーバとポートの定義を実行する、つまり、仮想サーバと仮想サーバ上のポートの定義を指示する命令列を、運用管理ＩＰアドレス（１４０３）を介して接続した負荷分散装置１０７に対して送信する（ステップ１９０１）。負荷分散装置１０７の好適な例は、仮想サーバ定義として、仮想ＩＰアドレス（１４０４）とポート番号（１４０５）を引数として仮想サーバを定義する手段を有する。次に、構築対象のシステム名をキーにユニット構成定義テーブル１６００からユニットを検索し（ステップ１９０２）、検索結果の各ユニットに対して（ステップ１９０３で「はい」の場合、図１６の場合“ユニット１”と“ユニット２”の各々に対して）、ステップ１９０４、１９０５、１９０６、１９０７を実行する。
【００５８】
前記各ユニットに対して、共通インターフェース５０１のcreateServiceDefinitionsを実行し（ステップ１９０４）、サービスインスタンス定義テーブルを生成する。次に、共通インターフェース５０１のsetupServicesを実行し（ステップ１９０５）、ステップ１９０４で生成した定義に基づいてシステム装置１０６上にサービスをセットアップする。次に、共通インターフェース５０１のjoinVirtualServerを実行し（ステップ１９０６）、ステップ１９０５で生成したサービスのうち、負荷分散装置１０７の振り分け対象となるサービスに対して、負荷分散装置１０７の振り分け対象として追加する。最後に、共通インターフェース５０１のdistributeConfigurationを実行し（ステップ１９０７）、ステップ１９０４で生成した環境定義情報からコンフィグレーションファイルを生成し、ステップ１９０５でセットアップしたサービスに対して前記ファイルを送付する。
【００５９】
図２０は、システム構築運用制御処理部１１７が実行する業務システム１００の起動手順を示すフローチャートである。本手順は、図１２のボタン１２０５のクリックを契機に実行される。本手順の実行により、システム装置内の各種サービスの起動とアプリケーションのデプロイが実行され、業務システム１００がエンドユーザからの要求を受け付ける。
【００６０】
まず、起動対象のシステム名をキーにユニット構成定義テーブル１６００からユニットを検索し（ステップ２００１）、検索結果の各ユニットに対して（ステップ２００２で「はい」の場合、図１６の場合“ユニット１”と“ユニット２”の各々に対して）、ステップ２００３、２００４、２００５、２００６を実行する。
前記各ユニットに対して、共通インターフェース５０１のstartServicesを実行し（ステップ２００３）、ユニット内のサービスを起動する。次に、共通インターフェース５０１のdeployApplicationsを実行し（ステップ２００４）、ユニット内のサービスに対して、アプリケーションをデプロイする。次に、共通インターフェース５０１のstartApplicationsを実行し（ステップ２００５）、ユニット内のサービスに対してアプリケーションを開始する。最後に、共通インターフェース５０１のacceptRequestを実行し（ステップ２００６）、エンドユーザのリクエストの受付を開始する。
【００６１】
図２０では業務システム１００の起動手順を示したが、業務システム１００の停止手順は図２０の場合とほぼ同様である。業務システム１００を停止する場合、図１２のボタン１２０６をクリックすることでシステム構築運用制御処理部１１７が処理を開始し、図２０におけるステップ２００３、２００４、２００５、２００６の代わりに、起動と逆の順番で各ステップの逆オペレーション、つまり、blockRequest、 stopApplications、 stopServicesを実行すればよい。ただし、deployApplicationsの逆オペレーションであるundeployApplicationsは実行しない。
【００６２】
以上で業務システム１００の構築処理が終了し、その後、画面がシステム運用画面１２００（図１２、説明は後記）に遷移して、システム構築運用制御処理部１１７による運用処理が開始されることになる。運用操作としては、ユニット単位の部分停止（ボタン１２０２あるいは１２０４）、部分再開（ボタン１２０１あるいは１２０３）、システム全起動（ボタン１２０５）、システム全停止（ボタン１２０６）がある。それぞれのボタンをクリックすることにより、システム構築運用制御処理部１１７がそれぞれの処理を開始する。
【００６３】
前記の基本運用操作に加えて、パラメータの変更、業務アプリケーションの変更（バージョンアップを含む入れ替え）およびユニット構成変更（ユニットの追加と削除）などがあり、それぞれボタン１２０７、１２０８、１２０９をクリックして、図９あるいは図１０に示す画面に遷移して変更定義を行い、システム構築運用制御処理部１１７が変更処理を実行する。
【００６４】
次に、業務システム１００の運用に関する処理について、業務アプリケーションを変更する場合を例にとって、その手順について説明する。図２１は、システム構築運用制御処理部１１７が実行する業務アプリケーションのバージョンアップ（入れ替え）手順を示すフローチャートである。本手順は、業務システム１００の運用中に、図１２のＡＰ変更用のボタン１２０８のクリックから遷移する環境定義画面９００（図９）のフィールド９１１の変更後開始され、業務システム１００を全停止することなく、業務アプリケーションの入れ替えを実行する。
【００６５】
まず、構築対象のシステム名をキーにユニット構成定義テーブル１６００からユニットを検索し（ステップ２１０１）、検索結果の各ユニットに対して（ステップ２１０２で「はい」の場合、図１６の場合“ユニット１”と“ユニット２”の各々に対して）、ステップ２１０３、２１０４、２１０５、２１０６、２１０７を実行する。
【００６６】
前記各ユニットに対して、共通インターフェース５０１のblockRequestを実行し（ステップ２１０３）、業務アプリケーションを変更するユニットへの負荷分散装置１０７によるエンドユーザからのリクエストの振り分けを停止する。次に、共通インターフェース５０１のstopApplicationsを実行し（ステップ２１０４）、当該ユニット内のサービスに対して業務アプリケーションの実行を停止する。次に、共通インターフェース５０１のredeployApplicationsを実行し（ステップ２１０５）、当該ユニット内のサービスに対してアプリケーションを入れ替える。次に、共通インターフェース５０１のstartApplicationsを実行し(ステップ２１０６)、業務アプリケーションを開始する。最後に、共通インターフェース５０１のacceptRequestを実行し（ステップ２１０７）、負荷分散装置１０７による当該ユニットへのエンドユーザからのリクエストの振り分けを再開する。
【００６７】
このように、前記手順のステップ２１０３〜２１０７において、特定のユニットのみを停止して業務アプリケーションを入れ替えることで、業務システム１００全体としてはサービスを停止させず、エンドユーザからの要求を残りのユニットで処理することができる。
【００６８】
次に、運用操作の他の例として、２４時間無停止でのパラメータ定義更新手順について述べる。パラメータ定義の変更方法は、図９のフィールド９０３にパラメータの変更値を入力し、ティア共通サービス環境定義テーブル１５００の更新後、システム構築運用制御処理部１１７がパラメータ定義更新手順を開始する。処理フローは図２１とほぼ同様であり、順次ユニットを閉塞して業務システム１００を部分縮退させながら、停止中のユニットに対して環境定義の再配布処理を実行していく。具体的には、ステップ２１０４、２１０５、２１０６の代わりに、 stopServicesを実行してユニットのサービスを停止するステップ、setupServicesのステップ１９０５およびステップ１９０７と同じ手順を実行し、環境定義の再設定と設定ファイルの再配布を行うステップ、および、startServicesによりサービスを開始するステップ、に差し替えればよい。
【００６９】
なお、図２１の処理フローおよび前記した２４時間無停止でのパラメータ定義更新手順は、２４時間無停止運用時の典型的な処理パターンを示している。特定のユニットを停止し（blockRequest、stopServices、stopApplicationsのいずれかあるいは組み合わせの実行）、ユニット停止中に運用の目的に応じたメンテナンス操作を実行し、ユニットを再開させる(acceptRequest、startServices、startApplicationsのいずれかあるいは組み合わせの実行)処理を、業務システム１００を構成するユニットに対して繰り返し実行する。
【００７０】
また、図２１の処理フローで示されるメンテナンス操作は、アプリケーションの再配備（redeployApplications）であり、前記した２４時間無停止でのパラメータ定義更新手順では設定ファイルの再配布である。その他想定される運用操作として、ＯＳのパッチを適用する処理、記憶手段のバックアップなどがあり、それぞれの２４時間無停止運用時には、それぞれの目的に応じたユニット単位での運用操作を実装したプログラムを事前に準備し、図２１の処理フローと同様の手順で呼び出せばよい。
【００７１】
さらに、図１９、図２０は業務システム１００を最初に構築する際の手順である。これらの手順は、業務システム１００構築後にユニットの構成を変更（追加および削除）する場合にも適用できる。その場合、図１９、図２０が示すように業務システム１００を構成する全てのユニットに対して実行する必要はなく、特定ユニットに対してのみ処理するようにすればよい。また、業務システム１００の負荷が、それが想定する処理能力を超える場合、新規ユニットを追加することにより、処理能力を超えた部分の負荷に対応することができる。逆に、想定より負荷が大幅に低い場合は、稼動中のユニットの停止後にそのユニットを削除すればよい。ユニットの追加削除は、図１２のユニット構成変更ボタン１２０９により遷移する図１０の画面１０００で行う。
【００７２】
〔構成パターンに依存する運用ロジックの処理フロー〕
続いて、図３の業務システム１００が属する構成パターンに対する共通インターフェース５０１の実装例の処理フローについて、図２２〜図２６のフローチャートを参照しながら説明する。これらは、前記したように、業務システム１００の構成に依存しない構築や運用の手順（図１９〜図２１）における、各メソッドの処理である。各メソッドの処理内容は、システム装置１０６の構成パターンにより、変化することもある。
各メソッドの概要は、createServiceDefinitions（図５）が、図７から図１２で行った構成定義情報からサービスインスタンス定義情報テーブル１８００を生成するものであり、その他のメソッドは、テーブル１８００を利用して負荷分散装置１０７あるいはシステム装置１０６に各種構築運用命令や設定ファイルなどを送信するものである。
【００７３】
図２２は、createServiceDefinitionsメソッド実装の処理手順を示すフローチャートである。本手順が生成するサービスインスタンス定義情報は、図１８に示すサービスインスタンス定義テーブル１８００に格納される。図７から図１２で行った構成定義では、装置のトポロジとシステム装置情報、ティア共通に設定するサービス種別毎のパラメータを定義しているが、各装置上に稼動させる個別サービスのインスタンス定義はまだ実施していない。本処理フローは、ユニット構成定義テーブル１６００、サービス構成を保持する構成パターン定義テーブル１１３、ティア共通サービス環境定義テーブル１５００およびサーバマシン定義テーブル１７００を利用して、これら個別サービスのインスタンス定義を生成するものである。
【００７４】
まず、メソッドの引数であるシステム名とユニット名をキーにユニット構成定義テーブル１６００を検索し（ステップ２２０１）、検索結果の各レコードに対して（ステップ２２０２、“ユニット１”の場合、レコード１６１１とレコード１６１２の２つ）、ステップ２２０３からステップ２２０７を実行する。
ステップ２２０３において、基本情報テーブル１３００から引数のシステム名に対応する構成パターン名フィールド１３０２の値を取得し、取得した該パターン名（“システム１”の場合“ＨＴＴＰ分離２ティア構成”）と現在処理中のレコードのティア名（ティア名フィールド１６０４の値）をキーにティアがホスティングするサービス種別（サービス種別名フィールド６０６の値）の一覧を構成パターン定義テーブル１１３から取得する。
【００７５】
取得した各サービス種別に対して（ステップ２２０４）、サービスインスタンス定義を行う（ステップ２２０５〜２２０７）。たとえば、図６では、ＨＴＴＰティア(６１１)の場合、サービス種別としてＨＴＴＰサービス（６２１）とロギングサービス（６２２）の２種類があることから、ＨＴＴＰティアに属する各サーバマシンに対して、ＨＴＴＰサービスとロギングサービスの２つのサービスインスタンス定義を行う。Ｊ２ＥＥティア(６１２)も同様であり、図３の業務システム１００の場合、全体としてシステム装置が４つ（３１１〜３１４）あり、それぞれにサービスを２つ稼動させることから、計８つのサービスインスタンス定義を生成する(図１８)。
【００７６】
サービスインスタンス定義は、ステップ２２０５、ステップ２２０６、ステップ２２０７からなる。まず、サービスインスタンス定義テーブル１８００に新規サービスインスタンス定義レコードを生成する。該新規サービスインスタンス定義レコードのサービス名フィールド１８０１には、サービスインスタンス定義テーブル１８００で一意性が保証できる名前を自動生成し、格納する。該新規サービスインスタンス定義レコードのシステム名フィールド１８０２、ユニット名フィールド１８０３、サーバマシン名フィールド１８０４およびティア名フィールド１８０５には、それぞれ引数で指定されたシステム名、引数で指定されたユニット名、現在処理中のサーバマシンの名前（サーバマシン名フィールド１６０３の値に対応）およびティアの名前（ティア名フィールド１６０４の値に対応）を設定する。サービス種別１８０８には現在処理中のサービス種別の名前（サービス種別名フィールド６０６の値に対応）を格納する（ステップ２２０５）。
【００７７】
次に、引数で指定されたシステム名、現在処理中のサービス種別名および現在処理中のティアの名前（ティア名フィールド１６０４の値に対応）をキーに、ティア共通サービス環境定義テーブル１５００を検索し、環境定義（１５０４）とアプリケーション情報（１５０５）を取得し、前記新規サービスインスタンス定義レコードの環境定義フィールド１８０６とアプリケーション情報フィールド１８０７に格納する（ステップ２２０６）。なお、前記ステップ２２０６では、ティア共通に定義したパラメータ定義およびアプリケーション情報を同一ティアに属する個別サービスインスタンス定義に展開（コピー）している。
【００７８】
最後に、システム装置の情報（サーバマシン定義テーブル１７００）と構成パターンのトポロジから定まるパラメータを、前記新規サービスインスタンス定義レコードの環境定義フィールド１８０６のリストに追加する（ステップ２２０７）。たとえば、図３の例では、ホスト１（３１１）上のＨＴＴＰサービス３２１が接続するＪ２ＥＥサービスは、同一ユニット３０４内のホスト２（３１２）上のＪ２ＥＥサービス３２３である。したがって、ＨＴＴＰサービス３２１の設定パラメータである“接続するＪ２ＥＥサービスのアドレス情報”パラメータの値は、サーバマシン定義テーブル１７００からそのネットワークアドレスは“１９２．１．１．２”であることが定まる。このような構成に応じたパラメータ解決手順は、Ｊａｖａ（登録商標）言語と各種テーブル（１１３、１１４）を参照する処理を構成毎のプラグインファイル１０３にハードコードすることにより実現できる。
【００７９】
図２３は、setupServicesメソッド実装の処理手順を示したフローチャートである。まず、引数であるシステム名とユニット名をキーにサービスインスタンス定義テーブル１８００を検索し（ステップ２３０１）、検索結果の各サービスインスタンス定義に対して（ステップ２３０２）サービスセットアップを実行する。サービスセットアップは、以降のステップからなり、まず、サービスインスタンス定義のサーバマシン名（１８０４）に対するネットワーク情報（管理ＩＰアドレス（１７０３）とポート番号（１７０４））を、サーバマシン定義テーブル１７００から取得する（ステップ２３０３）。次に、前記管理ＩＰアドレスと前記ポート番号を用いて、サーバマシン上の管理エージェントサービス１１９に接続し、サービス種別に応じたサービスのセットアップの命令列を送付し、管理エージェントサービス１１９がその命令列を実行する（ステップ２３０４）。
【００８０】
なお、unsetupServicesの手順は図２３とほぼ同様であり、ステップ２３０４の代わりに、システム装置１０６上のサービスにかかわる各種ファイルおよび設定を削除することを指示する命令列を管理エージェントサービス１１９に送信し、負荷分散装置１０７に対しても図１９のステップ１９０１で行った仮想サーバに関する定義とjoinVirtualServerで行ったリアルサーバに関する定義を削除する命令列を送信する。
【００８１】
また、distributeConfigurationの手順は図２３とほぼ同様であり、ステップ２３０４の代わりに、各種設定パラメータの名前値ペアのリストである環境定義（１８０６）からサービス種別に応じた設定ファイルを生成し、管理エージェントサービス１１９に対して生成した前記設定ファイルを配布すればよい。生成されるファイルの例として、サービス種別がＨＴＴＰサービスの場合、ｈｔｔｐｄ.ｃｏｎｆと呼ばれるファイルなどがある。
さらに、startServicesの手順は図２３とほぼ同様であり、ステップ２３０４の代わりに、管理エージェントサービス１１９に対してサービス種別に応じたサービス起動処理の命令列を送信すればよい。
また、stopServicesの手順は図２３とほぼ同様であり、ステップ２３０４の代わりに、管理エージェントサービス１１９に対してサービス種別に応じたサービス停止処理の命令列を送信すればよい。
【００８２】
続いて、図２４は、deployApplicationsメソッド実装の処理手順を示すフローチャートである。まず、引数であるシステム名とユニット名をキーにサービスインスタンス定義テーブル１８００を検索し（ステップ２４０１）、検索結果の各サービスインスタンス定義に対して（ステップ２４０２）、アプリケーション情報フィールド１８０７がｎｕｌｌでない場合（ステップ２４０３）、アプリケーションのデプロイ処理を実行する。アプリケーションのデプロイ処理は、以降のステップからなり、まず、サービスインスタンス定義のサーバマシン（１８０４）に関するネットワーク情報（管理ＩＰアドレス（１７０３）とポート番号（１７０４））をサーバマシン定義テーブル１７００から取得する（ステップ２４０４）。次に、ステップ２４０４で取得した情報に基づいて、管理エージェントサービス１１９に接続し、サービスインスタンス定義テーブル１８００のアプリケーション情報フィールド１８０７で指定されるアプリケーションのファイルの送信後、サービス種別に応じたアプリケーションのデプロイ処理の命令列を送信する（ステップ２４０５）。
【００８３】
なお、undeployApplicationsの手順は図２４とほぼ同様であり、ステップ２４０５において、アプリケーションのアンデプロイ命令を、管理エージェントサービス１１９に送信する。
また、startApplicationsの手順は図２４とほぼ同様であり、ステップ２４０５において、アプリケーションの開始命令を、管理エージェントサービス１１９に送信する。
さらに、stopApplicationsの手順は図２４とほぼ同様であり、ステップ２４０５において、アプリケーションの停止命令を、管理エージェントサービス１１９に送信する。
【００８４】
次に、図２５は、redeployApplicationsメソッド実装の処理手順に示すフローチャートである。まず、undeployApplicationメソッドを実行し、ユニット内のアプリケーションをアンデプロイする（ステップ２５０１）。そして、引数であるシステム名とユニット名をキーにサービスインスタンス定義テーブル１８００を検索し（ステップ２５０２）、検索結果の各サービスインスタンス定義に対して（ステップ２５０３）、サービスインスタンス定義のティア名（１８０４）およびサービス種別（１８０８）をキーにティア共通サービス環境定義テーブル１５００からアプリケーション情報（１５０５）を取得し（ステップ２５０４）、取得したアプリケーション情報を、サービスインスタンス定義テーブルのアプリケーション情報フィールド１８０４に上書きする（ステップ２５０５）。最後に、deployApplicationsを起動する（ステップ２５０６）。
【００８５】
図２６は、joinVirtualServerメソッド実装の手順を示すフローチャートである。図３の業務システム１００の場合は、ユニット中のＨＴＴＰサービスが負荷分散の対象（振り分け対象のことをリアルサーバと呼ぶ）であることを負荷分散装置１０７に指示し（リアルサーバ定義）、仮想サーバとリアルサーバの振り分け定義を行う。たとえば、図３のユニット３０４を仮想サーバに追記する場合、ホスト１のＨＴＴＰサービス３２１に対してリアルサーバ定義を行い、“１９２．１．１００”をＶＩＰに持つ仮想サーバに対して前記リアルサーバを振り分けるよう定義する。
【００８６】
図２６の処理フローは、次のとおりである。まず、引数のシステム名をキーに負荷分散装置定義情報テーブル１４００から負荷分散装置１０７の運用管理ＩＰアドレス（１４０３）と仮想サーバ情報（仮想ＩＰアドレス（１４０４）とポート番号（１４０５））を取得する（ステップ２６０１）。次に、引数であるシステム名、ユニット名および負荷分散の対象となるティア名（図３の構成の場合、ＨＴＴＰティアが負荷分散の対象となる）をキーにサービスインスタンス定義テーブル１８００を検索する（ステップ２６０２）。検索結果の各サービスインスタンス定義に対して（ステップ２６０３）、仮想サーバの振り分け対象への参加処理を実行する。振り分け対象への参加処理は、以降のステップからなる。まず、サービスが稼動するサーバマシン（１８０４）の実行ＩＰアドレス（１７０２）をサーバマシン定義テーブル１７００から取得する（ステップ２６０４）。つまり、この実行ＩＰアドレスがリアルサーバのＩＰアドレスとなる。なお、本実施形態では、リアルサーバのポート番号は仮想サーバのポート番号と同じ値を利用することを想定する。
【００８７】
図２６の処理フローに戻ると、次に、先に取得した負荷分散装置定義情報のポート情報（１４０５）とサーバマシンの実行ＩＰアドレス（１７０２）から、負荷分散装置１０７への振り分け対象定義（リアルサーバ定義）の命令列を生成し、負荷分散装置１０７に送信する（ステップ２６０５）。なお、負荷分散装置１０７の好適な例としては、振り分け対象のＩＰアドレスおよびポート番号を引数にリアルサーバを定義する手段を有している。最後に、仮想サーバがリアルサーバの振り分けを行うことを指示する命令列を生成し、負荷分散装置１０７に送信する（ステップ２６０６）。前記手順において、負荷分散装置１０７との通信には、負荷分散装置定義情報テーブル１４００の運用管理ＩＰアドレス（１４０３）を用いる。
【００８８】
なお、leaveVirtualServerの処理手順は図２６の手順とほぼ同様であり、ステップ２６０５とステップ２６０６に代わりに、負荷分散装置１０７への振り分け対象定義を削除する命令列を、負荷分散装置１０７に送信する。
また、acceptRequestの処理手順は図２６の手順とほぼ同様であり、ステップ２６０５とステップ２６０６に代わりに、リアルサーバへの振り分けを有効化する命令列を、負荷分散装置１０７に送信する。
さらに、blockRequestの処理手順は図２６の手順とほぼ同様であり、ステップ２６０５とステップ２６０６の代わりに、リアルサーバへの振り分けを無効化する命令列を、負荷分散装置１０７に送信する。
【００８９】
このように、本実施形態に係る業務システムに対する運用管理システムよれば、業務システム１００において、ユニットという部分閉塞再開可能な管理単位を規定することで、業務システム１００全体としては停止することなく、システム装置１０６における運用操作（アプリケーションの入れ替えなど）を行うことができる。
また、共通インターフェース５０１を利用することで、システムレベルにおいては、業務システム１００の構成パターンに依存しない汎用的な構築および運用を行うことができる。そして、それぞれの構成パターンに対しては、ユニット内の構成パターンに応じて作成された共通インターフェース５０１の実装プログラムをユニットの定義情報と関連付けることで対応でき、業務システム１００の構築や運用の際の作業が局所化され、開発者や運用者の負担を低減することができる。
【００９０】
以上で実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。たとえば、エンドユーザとの接続は、インターネットでなくても、ＬＡＮ（Local Area Network）や専用線などの他の通信回線であってもよい。その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【図面の簡単な説明】
【００９１】
【図１】本発明の実施形態の全体構成を示したブロック図である。
【図２】図１のシステム装置構成が２層からなる場合の構成図である。
【図３】図２のシステム装置の第1の層を２つに分離した３層構造の場合の構成図である。
【図４】プラグインプログラムファイルの構造を示した図である。
【図５】プラグインプログラムが持つ共通インターフェースを示した図である。
【図６】構成パターン定義テーブルの構成図である。
【図７】システム構成パターン選択画面を示す画面図である。
【図８】負荷分散装置定義画面を示す画面図である。
【図９】サービス環境定義画面を示す画面図である。
【図１０】ユニット構成定義画面を示す画面図である。
【図１１】サーバマシン定義画面を示す画面図である。
【図１２】日常運用の操作を行うシステム運用画面を示す画面図である。
【図１３】基本情報テーブルを示した図である。
【図１４】負荷分散装置定義テーブルを示した図である。
【図１５】ティア共通サービス環境定義テーブルを示した図である。
【図１６】ユニット構成定義テーブルを示した図である。
【図１７】サーバマシン定義テーブルを示した図である。
【図１８】サービスインスタンス定義テーブルを示した図である。
【図１９】システム構築運用制御処理部１１７によるシステム構築の流れを示すフローチャートである。
【図２０】システム構築運用制御処理部１１７によるシステム起動の流れを示すフローチャートである。
【図２１】システム構築運用制御処理部１１７による業務入れ替えの流れを示すフローチャートである。
【図２２】図３の構成パターンに対するプラグインプログラム共通インターフェースのメソッドcreateServiceDefinitions実装の処理フローを示すフローチャートである。
【図２３】図３の構成パターンに対するプラグインプログラム共通インターフェースのメソッドsetupServices実装の処理フローを示すフローチャートである。
【図２４】図３の構成パターンに対するプラグインプログラム共通インターフェースのメソッドdeployApplications実装の処理フローを示すフローチャートである。
【図２５】図３の構成パターンに対するプラグインプログラム共通インターフェースのメソッドredeployApplications実装の処理フローを示すフローチャートである。
【図２６】図３の構成パターンに対するプラグインプログラム共通インターフェースのメソッドjoinVirtualServer実装の処理フローを示すフローチャートである。
【符号の説明】
【００９２】
１００  業務システム
１０１  管理用端末システム装置
１０２  運用管理システム
１０６  管理対象システム装置
１０７  負荷分散装置
１３１  記憶手段
２０１  第１の層
２０２  第２の層
３０１  第１層
３０２  第２層
５０１  共通インターフェース
１３００  基本情報テーブル
１４００  負荷分散装置定義テーブル
１５００  ティア共通サービス環境定義テーブル
１６００  ユニット構成定義テーブル
１７００  サーバマシン定義テーブル
１８００  サービスインスタンス定義テーブル
【図１】
2006127001.tif 000003
【図２】
2006127001.tif 000004
【図３】
2006127001.tif 000005
【図４】
2006127001.tif 000006
【図５】
2006127001.tif 000007
【図６】
2006127001.tif 000008
【図７】
2006127001.tif 000009
【図８】
2006127001.tif 000010
【図９】
2006127001.tif 000011
【図１０】
2006127001.tif 000012
【図１１】
2006127001.tif 000013
【図１２】
2006127001.tif 000014
【図１３】
2006127001.tif 000015
【図１４】
2006127001.tif 000016
【図１５】
2006127001.tif 000017
【図１６】
2006127001.tif 000018
【図１７】
2006127001.tif 000019
【図１８】
2006127001.tif 000020
【図１９】
2006127001.tif 000021
【図２０】
2006127001.tif 000022
【図２１】
2006127001.tif 000023
【図２２】
2006127001.tif 000024
【図２３】
2006127001.tif 000025
【図２４】
2006127001.tif 000026
【図２５】
2006127001.tif 000027
【図２６】
2006127001.tif 000028