JP2016042248A - オーケストレーションシステム、方法、およびプログラム - Google Patents

Abstract

【課題】極めて簡素なプロセス管理で、利用者が指定した各種のサービスシステムを構築する。
【解決手段】サービスシステム特定部１１が、システム要件データに基づき要求サービスシステムと対応する規定サービスシステムを対象サービスシステムとして特定し、抽象化プロセスフロー特定部１４が、要求サービスシステムのサービスカテゴリに関する抽象化プロセスフローを特定し、抽象化プロセスフロー実行部１６が、抽象化プロセスフローに記述された抽象化プロセスごとに当該抽象化プロセスと対応する抽象化ＡＰＩの呼び出しを行い、サービスシステム構築部１８が抽象化ＡＰＩの呼び出しに応じて、対象サービスシステムと対応するアダプタのうち、当該抽象化ＡＰＩと対応する処理を実装するアダプタで当該処理を実行してリソースマネージャ２０を制御する。
【選択図】 図１

Description

本発明は、サービスシステム構築技術に関し、特に通信回線を介してリソースの管理制御を行うリソースマネージャを制御することにより、利用者が要求する要求サービスシステムを構築するオーケストレーション技術に関する。

ＳＤＮ（Software-Defined Network：ソフトウェア定義ネットワーク）やＮＦＶ（Network Functions Virtualization：ネットワーク仮想化）などの技術分野では、通信回線を介して仮想化リソースを制御管理する技術として、ＮＦＶオーケストレーション技術がＥＴＳＩ（European Telecommunications Standards Institute：欧州電気通信標準化機構）にて標準化が進められている（例えば、非特許文献１など参照）。
従来、このようなＮＦＶオーケストレーション技術を利用して、オープン・クラウドを実現するソフトウェア製品（例えば、非特許文献２など参照）や、サービスを構築しアクティベーションするプラットフォーム（例えば、非特許文献３など参照）が提供されている。

このような従来技術によれば、対象となるサービスシステムの構築に用いる各リソースに対する制御管理手順をプロセスとして定義しておき、オーケストレータが、これらプロセスを実行して、下位に配置されているリソースマネージャ（リソースコントローラ）に対し、リソースマネージャが有するＡＰＩの呼び出し行うことにより、リソースマネージャ経由で個々のリソースの制御管理を行うものとなっている。

「Network Functions Virtualization (NFV); Architectural Framework」, ETSI, GS NFV 002 V1.1.1 (2-13-10) 「IBM SmarterCloud Orchestrator」, IBM, http://www-01.ibm.com/support/knowledgecenter/?lang=en#!/SS4KMC/welcome 「HP Service Activator & Suite of Solutions」, Hewlett-Packard, http://h50146.www5.hp.com/solutions/industry/telecom/activator.html

しかしながら、このような従来技術では、リソースの制御管理を行う場合、当該リソースに対応してオーケストレータの配下に設けた特定のリソースマネージャを、それぞれのリソースマネージャを個別に指定したＡＰＩでプロセスから呼び出すことにより、リソースマネージャ経由でリソースの制御管理を行う必要がある。
したがって、オーケストレータが所掌すべきリソースマネージャの数が増加すると、これに伴いプロセスの追加が必要になるため、結果としてプロセスの管理が極めて煩雑になってしまうという問題点があった。

また、構築対象となるサービスシステムに応じて制御管理すべきリソースおよびリソースマネージャも異なるとともに、リソースマネージャが持つインターフェースも異なる。このため、従来技術では、ＡＰＩにおける処理対象や処理内容の違いをプロセスごとに個別に決定しておく必要があり、プロセスとサービスシステムとの一体化が余儀なくされることになる。
したがって、利用者からの指示に応じて各種のサービスシステムを構築する場合、サービスシステムごとにプロセスを管理しておく必要があり、結果としてプロセスの管理が極めて煩雑になってしまうという問題点があった。

本発明はこのような課題を解決するためのものであり、極めて簡素なプロセス管理で、利用者が指定した各種のサービスシステムを構築することができるオーケストレーション技術を提供することを目的としている。

このような目的を達成するために、本発明にかかるオーケストレーションシステムは、通信回線を介してリソースの管理制御を行うリソースマネージャを制御することにより、利用者が要求する要求サービスシステムを構築するオーケストレーションシステムであって、利用者から指定された前記要求サービスシステムに関するシステム要件データに基づき、予め登録されている規定サービスシステムのうちから当該要求サービスシステムと対応する規定サービスシステムを、実際に構築する対象サービスシステムとして特定するサービスシステム特定部と、サービスシステムの種別を示すサービスカテゴリごとに予め登録されている、当該サービスカテゴリに属するサービスシステムの構築時に実行すべき抽象化プロセスが実行順に記述された抽象化プロセスフローのうちから、前記要求サービスシステムのサービスカテゴリに関する抽象化プロセスフローを特定する抽象化プロセスフロー特定部と、前記抽象化プロセスフローに記述された抽象化プロセスを実行順に選択し、選択した抽象化プロセスごとに当該抽象化プロセスと対応する抽象化ＡＰＩの呼び出しを行う抽象化プロセスフロー実行部と、前記規定サービスシステムごとに、当該規定サービスシステムの構築に用いるリソースマネージャを制御するためのアダプタを有し、前記抽象化ＡＰＩの呼び出しに応じて、前記対象サービスシステムと対応するアダプタのうちから、当該抽象化ＡＰＩと対応する処理を実装するアダプタを選択し、選択したアダプタで当該処理を実行して前記リソースマネージャを制御することにより、当該対象サービスシステムを構築するサービスシステム構築部とを備えている。

また、本発明にかかる上記オーケストレーションシステムの一構成例は、前記サービスシステム構築部が、前記抽象化ＡＰＩの呼び出しに応じて、前記対象サービスシステムと対応するアダプタのうち、当該抽象化ＡＰＩと対応するメソッドを実装するアダプタのインスタンスを生成し、生成したインスタンスで当該メソッドを実行して前記リソースマネージャを制御するようにしたものである。

また、本発明にかかる上記オーケストレーションシステムの一構成例は、前記サービスシステム特定部が、前記規定サービスシステムのうち、これら規定サービスシステムごとに予め登録されているシステム要件が、前記システム要件データで指定された前記要求サービスシステムに関するシステム要件と一致する規定サービスシステムを、前記対象サービスシステムとして特定するようにしたものである。

また、本発明にかかるオーケストレーション方法は、通信回線を介してリソースの管理制御を行うリソースマネージャを制御することにより、利用者が要求する要求サービスシステムを構築するオーケストレーション方法であって、サービスシステム特定部が、利用者から指定された前記要求サービスシステムに関するシステム要件データに基づき、予め登録されている規定サービスシステムのうちから当該要求サービスシステムと対応する規定サービスシステムを、実際に構築する対象サービスシステムとして特定するサービスシステム特定ステップと、抽象化プロセスフロー特定部が、サービスシステムの種別を示すサービスカテゴリごとに予め登録されている、当該サービスカテゴリに属するサービスシステムの構築時に実行すべき抽象化プロセスが実行順に記述された抽象化プロセスフローのうちから、前記要求サービスシステムのサービスカテゴリに関する抽象化プロセスフローを特定する抽象化プロセスフロー特定ステップと、抽象化プロセスフロー実行部が、前記抽象化プロセスフローに記述された抽象化プロセスを実行順に選択し、選択した抽象化プロセスごとに当該抽象化プロセスと対応する抽象化ＡＰＩの呼び出しを行う抽象化プロセスフロー実行ステップと、サービスシステム構築部が、前記規定サービスシステムごとに、当該規定サービスシステムの構築に用いるリソースマネージャを制御するためのアダプタを有し、前記抽象化ＡＰＩの呼び出しに応じて、前記対象サービスシステムと対応するアダプタのうちから、当該抽象化ＡＰＩと対応する処理を実装するアダプタを選択し、選択したアダプタで当該処理を実行して前記リソースマネージャを制御することにより、当該対象サービスシステムを構築するサービスシステム構築ステップとを備えている。

また、本発明にかかるプログラムは、コンピュータを、前述したオーケストレーションシステムを構成する各部として機能させるためのプログラムである。

本発明によれば、サービスシステムの構築に用いるプロセスおよびプロセスフローが抽象化（上位概念化）されて、実際に構築するサービスシステムとは切り離されて、同一サービスカテゴリに属するシステムサービスで共用されることになる。このため、オーケストレーションシステムで管理すべきプロセスの数を大幅削減できる。また、サービスカテゴリごとに１つの抽象化プロセスフローを用意しておけばよくなるため、オーケストレーションシステムで管理すべきプロセスフローの数も大幅に削減できる。

したがって、システムサービスの構築時に連携させるリソースマネージャやリソースの増減に対して、プロセスフローやプロセスの軽微な変更により、柔軟に対応することができる。また、同一のプロセスで異なるサービス（例えば、ファイヤーウォーや侵入検知システム）を構築することができ、オーケストレーションシステムにおけるプロセス管理を大幅に簡素化することが可能となる。

また、対象サービスシステムに応じて処理対象であるリソースマネージャや処理内容が異なるメソッドを、抽象化されたメソッド名を有する抽象化ＡＰＩとしてアダプタに実装されているため、これらアダプタで、リソースの制御管理における対象サービスシステムに応じた処理対象や処理内容の違いが吸収されることになる。したがって、抽象化プロセス側からは、抽象化されたメソッド名で呼び出しを行うだけで、対象サービスシステムに応じた処理対象や処理内容の具体的なメソッドを実行することができ、結果として、プロセスおよびプロセスフローの抽象化が極めて容易に実現できる。

第１の実施の形態にかかるオーケストレーションシステムの構成を示すブロック図である。 第１の実施の形態にかかるシステム要件データの構成例である。 第１の実施の形態にかかるカタログデータの構成例である。 サービス設計書の構成例である。 抽象化プロセスフローの記述例である。 抽象化プロセスフローの構成例である。 ステータスデータの構成例である。 第１の実施の形態にかかるサービスシステム構築処理を示すフローチャートである。 第１の実施の形態にかかるサービスシステム特定処理を示すフローチャートである。 抽象化プロセスフロー特定処理を示すフローチャートである。 抽象化プロセスフロー実行処理を示すフローチャートである。 サービスシステム構築処理を示すフローチャートである。 第１の実施の形態にかかるサービスシステム構築動作を示すシーケンス図である。 第１の実施の形態にかかるサービスシステム構築動作（続き）を示すシーケンス図である。 第２の実施の形態にかかるシステム要件データの構成例である。 第２の実施の形態にかかるカタログデータの他の構成例である。 第２の実施の形態にかかるサービスシステム特定処理を示す他のフローチャートである。

次に、本発明の実施の形態について図面を参照して説明する。
［第１の実施の形態］
まず、図１を参照して、本発明の第１の実施の形態にかかるオーケストレーションシステム１０について説明する。図１は、第１の実施の形態にかかるオーケストレーションシステムの構成を示すブロック図である。

このオーケストレーションシステム１０は、全体として１つまたは複数のサーバ装置からなり、サービスポータルシステム３０で受け付けた利用者のシステム要件データに応じて、通信回線を介してリソース２１の管理制御を行うリソースマネージャ２０を制御することにより、利用者が要求する要求サービスシステムを構築する機能を有している。

オーケストレーションシステム１０で構築の対象となるサービスシステムとしては、仮想ファイヤーウォールや仮想ロードバランサーなどの仮想ネットワーク機能サービス、ＶＰＮ（Virtual Private Network）などのネットワーク通信サービス、シンクライアントのような仮想ディスクトップ、さらにはＷＥＢ勤務管理システムなどのＷＥＢアプリケーションサービスがある。したがって、本発明でいうサービスシステムは、一般的な商取引を含む役務を実現するためのシステムに限定されるものではなく、商取引を含まない役務を実現するためのシステムも含まれるものとする。

サービスポータルシステム３０には、要件入力用ポータルサイト３１とシステム要件ＤＢ３２が設けられている。このサービスポータルシステム３０は、要件入力用ポータルサイト３１で、利用者が構築したい要求サービスシステムに関する各種の要件を、通信回線を介して受け付け、システム要件データとしてシステム要件ＤＢ３２に登録する機能と、オーケストレーションシステム１０からの要求に応じて、通信回線を介してシステム要件ＤＢ３２に登録されているシステム要件データを通知する機能とを有している。

オーケストレーションシステム１０の配下には、サービスシステムの構築に用いるリソース２１を、通信回線を介して制御管理するリソースマネージャ２０が設けられている。リソースマネージャ２０の具体例としては、ＮＶＦコントローラのほか、サーバコントローラ（OpenStack等）、ＮＷコントローラ（ＤＣ内制御用）などのコントローラが用いられる。リソース２１の具体例としては、サーバ、ネットワーク機能、ストレージなどがあり、リソースマネージャ２０は、これらリソース２１の起動、設定、提示、情報取得などの制御管理を行う。

特に、リソースマネージャ２０としてＮＶＦコントローラを用いた場合、オーケストレーションシステム１０の運営者に所属する物理的なリソース２１だけでなく、ユーザ拠点に位置する仮想化されたリソース２１もオーケストレーションシステム１０から制御管理することが可能となる。

［オーケストレーションシステム］
次に、図１を参照して、本実施の形態にかかるオーケストレーションシステム１０の構成について詳細に説明する。
オーケストレーションシステム１０には、主な機能部として、サービスシステム特定部１１、サービスカタログＤＢ１２、サービス設計書ＤＢ１３、抽象化プロセスフロー特定部１４、抽象化プロセスＤＢ１５、抽象化プロセスフロー実行部１６、ステータスＤＢ１７、サービスシステム構築部１８、アダプタ１９が設けられている。

サービスシステム特定部１１は、サービスポータルシステム３０のシステム要件ＤＢ３２に登録されている、利用者から指定された要求サービスシステムに関するシステム要件データを取得する機能と、サービスカタログＤＢ１２に予め登録されている規定サービスシステムのうちから当該システム要件データで指定された要求サービスシステムと対応する規定サービスシステムを、実際に構築する対象サービスシステムとして特定する機能と、特定した結果をサービス設計書に記述してサービス設計書ＤＢ１３に登録する機能とを有している。

図２は、第１の実施の形態にかかるシステム要件データの構成例である。ここでは、システム要件データとして、利用者が要件入力用ポータルサイト３１で入力したシステム要件データごとに固有のオーダーＩＤと、当該システム要件データを入力した利用者を示す利用者ＩＤと、当該システム要件データで指定された要求サービスシステムの種別を示すサービスカテゴリや要求サービスシステムに求められるパフォーマンス要件など、要求サービスシステムに求める各種の要件を示すシステム要件とが、組として登録されている。

サービスカタログＤＢ１２は、予め登録された、各種の規定サービスシステムに関するシステム要件データをカタログデータとして記憶する機能を有している。
図３は、第１の実施の形態にかかるカタログデータの構成例である。ここでは、規定サービスシステムごとに、当該規定サービスシステムのサービス名と、当該規定サービスシステムの種別を示すサービスカテゴリや当該規定サービスシステムが持つ能力価値を示すパフォーマンス要件など、規定サービスシステムが持つ各種の要件を示すシステム要件とが、組として登録されている。

パフォーマンス要件については、例えば、仮想ファイヤーウォールでは、信頼性、性能、価格などの要件が重要視され、ＶＰＮでは、通信パケットに関する転送遅延、ロス、ゆらぎ、帯域、価格などの要件が重要視され、シンクライアントでは、利用者数、信頼性、セキュリティ、ＯＳ、搭載アプリ、価格などの要件が重要視され、ＷＥＢ勤務管理システムでは、同時アクセス数上限、信頼性、セキュリティ、価格などの要件が重要視される。
このように、パフォーマンス要件は、規定サービスシステムの内容によって求められる要件が異なるため、カタログデータにおいて適応的に要件の項目を設定すればよい。なお、図３では、各要件項目の評価値として高・中・低を用いて表現した場合を例として示したが数値などの評価値を用いてもよい。

サービス設計書ＤＢ１３は、サービスシステム特定部１１から登録されたサービス設計書を記憶する機能を有している。
図４は、サービス設計書の構成例である。ここでは、サービス設計書（サービス設計データ）として、利用者から指定された要求サービスシステムを示すオーダーＩＤと、実際に構築する対象サービスシステムを示すサービス名とが、組として登録されている。

抽象化プロセスフロー特定部１４は、サービスポータルシステム３０のシステム要件ＤＢ３２に登録されている、利用者から指定された要求サービスシステムに関するシステム要件データを取得する機能と、抽象化プロセスＤＢ１５に予め登録されている抽象化プロセスフローのうちから、当該システム要件データで指定された要求サービスシステムのサービスカテゴリに関する抽象化プロセスフローを特定する機能と、特定した抽象化プロセスフローを示すプロセスフローＩＤをオーダーＩＤとともに抽象化プロセスフロー実行部１６に通知する機能とを有している。

図５は、抽象化プロセスフローの記述例である。ここでは、ファイヤーウォール（ＦＷ）の構築に関する抽象化プロセスフローが示されており、具体的にはファイヤーウォール（ＦＷ）構築を示す１つの抽象化プロセスから構成されている。複数の抽象化プロセスから抽象化プロセスフローが構成される場合には、実行する順に抽象化プロセスが列挙されることになる。抽象化プロセスフローの格納形式については、例えばＢＰＭＮ（Business Process Modeling Notation：ビジネスプロセスモデリング表記法）などのプロセス標準表記と変換可能なＸＭＬ（Extensible Markup Language）などの格納形式を用いればよい。

本発明は、サービスシステムの構築に用いるプロセスおよびプロセスフローを抽象化（上位概念化）して、実際に構築するサービスシステムとは切り離し、同一サービスカテゴリに属するシステムサービスで共用するようにしたものである。具体的には、個々の抽象化プロセスで、制御管理対象となるリソースマネージャ２０さらにはリソース２１を個別に指定せず、これら指定のためのパラメータを含まない抽象化ＡＰＩを呼び出すようにしたものである。これにより、オーケストレーションシステム１０で管理すべきプロセスの数を大幅削減できる。また、サービスカテゴリごとに１つの抽象化プロセスフローを用意しておけばよくなるため、オーケストレーションシステム１０で管理すべきプロセスフローの数も大幅に削減できる。

抽象化プロセスＤＢ１５は、予めサービスシステムの種別を示すサービスカテゴリごとに登録されている、当該サービスカテゴリに属するサービスシステムの構築時に実行すべき抽象化プロセスが実行順に記述された抽象化プロセスフローを記憶する機能を有している。
図６は、抽象化プロセスフローの構成例である。ここでは、抽象化プロセスフローとして、抽象化プロセスフローに固有のプロセスフローＩＤと、当該抽象化プロセスフローが構築するサービスシステムが属するサービスカテゴリと、当該抽象化プロセスフローを構成する抽象化プロセスが実行順に列挙されてなるプロセスリストとが、組として登録されている。

抽象化プロセスフロー実行部１６は、抽象化プロセスフロー特定部１４から通知されたプロセスフローＩＤおよびオーダーＩＤに応じて、当該プロセスフローＩＤに対応する抽象化プロセスフローを抽象化プロセスＤＢ１５から取得する機能と、取得した抽象化プロセスフローに記述されている抽象化プロセスを実行順に選択し、選択した抽象化プロセスごとに当該抽象化プロセスと対応する抽象化ＡＰＩの呼び出しをオーダーＩＤとともにサービスシステム構築部１８へ通知する機能と、抽象化ＡＰＩの呼び出しに応じてサービスシステム構築部１８から通知された実行結果に基づき抽象化プロセスの実施状況を示すステータスデータをステータスＤＢ１７へ記録する機能とを有している。

ステータスＤＢ１７は、抽象化プロセスフロー実行部１６から記録されたステータスデータを記憶する機能を有している。
図７は、ステータスデータの構成例である。ここでは、プロセスフローＩＤごとに、対応する抽象化プロセスフローを構成する各抽象化プロセスのプロセス番号、プロセスＩＤ、実施状況を示す実施ステータスが、組として登録されている。

サービスシステム構築部１８は、規定サービスシステムごとに、当該規定サービスシステムの構築に用いるリソースマネージャ２０を制御するためのアダプタ１９を複数有し、抽象化プロセスフロー実行部１６から通知された抽象化ＡＰＩの呼び出しごとに、対象サービスシステムと対応するアダプタ１９のうちから、当該抽象化ＡＰＩを実装するアダプタ１９を選択する機能と、選択したアダプタ１９で抽象化ＡＰＩの処理を実行してリソースマネージャ２０を制御することにより、当該対象サービスシステムを構築する機能と、リソースマネージャ２０からの実行結果を抽象化プロセスフロー実行部１６へ通知する機能とを有している。

これらアダプタ１９は、オブジェクト指向プログラミングに基づくオブジェクトで構成されており、サービスシステム構築部１８には、実際に構築する対象サービスシステムごとに、アダプタ１９を構成するインスタンスを生成するためのクラスがライブラリとして予め登録されている。したがって、各アダプタ１９には、当該対象サービスシステムに固有の処理内容を示すプログラムとパラメータが予め登録されている。
サービスシステム構築部１８は、抽象化ＡＰＩの呼び出しごとに、指定されたオーダーＩＤと対応するサービス設計書ＤＢ１３のサービス設計書を参照し、このサービス設計書で指定されている対象サービスシステムと対応するクラスから、当該抽象化ＡＰＩをメソッドとして実装するアダプタ１９のインスタンスを生成する。

本発明は、対象サービスシステムに応じて処理対象であるリソースマネージャ２０や処理内容が異なるメソッドを、抽象化されたメソッド名を有する抽象化ＡＰＩとしてアダプタ１９に実装するようにしたものである。これにより、アダプタ１９で、リソース２１の制御管理における対象サービスシステムに応じた処理対象や処理内容の違いが吸収されることになる。したがって、抽象化プロセス側からは、抽象化されたメソッド名で呼び出しを行うだけで、対象サービスシステムに応じた処理対象や処理内容の具体的なメソッドが実行されることになる。

［第１の実施の形態の動作］
次に、図８を参照して、本実施の形態にかかるオーケストレーションシステム１０の動作について説明する。図８は、第１の実施の形態にかかるサービスシステム構築処理を示すフローチャートである。
オーケストレーションシステム１０は、サービスポータルシステム３０からのサービスシステム構築指示に応じて、図８のサービスシステム構築処理を実行する。

まず、サービスシステム特定部１１は、サービスポータルシステム３０からのサービスシステム構築指示に応じて、サービスポータルシステム３０のシステム要件ＤＢ３２に登録されている、利用者から指定された要求サービスシステムに関するシステム要件データを取得し、サービスカタログＤＢ１２に予め登録されている規定サービスシステムのうちから、当該システム要件データで指定された要求サービスシステムと対応する規定サービスシステムを、実際に構築する対象サービスシステムとして特定し、特定した結果をサービス設計書に記述してサービス設計書ＤＢ１３に登録する（ステップ１００）。

一方、抽象化プロセスフロー特定部１４は、サービスポータルシステム３０からのサービスシステム構築指示に応じて、システム要件ＤＢ３２からシステム要件データを取得し、抽象化プロセスＤＢ１５に予め登録されている抽象化プロセスフローのうちから、当該システム要件データで指定された要求サービスシステムのシステム要件の１つであるサービスカテゴリと一致するサービスカテゴリに属する抽象化プロセスフローを特定し、特定した抽象化プロセスフローを示すプロセスフローＩＤを抽象化プロセスフロー実行部１６に通知する（ステップ１０１）。

この後、抽象化プロセスフロー実行部１６は、抽象化プロセスフロー特定部１４から通知されたプロセスフローＩＤに応じて、当該プロセスフローＩＤに対応する抽象化プロセスフローを抽象化プロセスＤＢ１５から取得し、取得した抽象化プロセスフローに記述されている抽象化プロセスを実行順に選択し、選択した抽象化プロセスごとに当該抽象化プロセスと対応する抽象化ＡＰＩの呼び出しをサービスシステム構築部１８へ通知する（ステップ１０２）。

サービスシステム構築部１８は、抽象化プロセスフロー実行部１６から通知された抽象化ＡＰＩの呼び出しごとに、サービス設計書ＤＢ１３のサービス設計書で指定されている対象サービスシステムと対応するクラスから、当該抽象化ＡＰＩをメソッドとして実装するアダプタ１９のインスタンスを生成し、生成したインスタンスで抽象化ＡＰＩの処理を実行してリソースマネージャ２０を制御管理することにより、当該対象サービスシステムを構築し（ステップ１０３）、一連のサービスシステム構築処理を終了する。

［サービスシステム特定処理］
次に、図９を参照して、本実施の形態にかかるサービスシステム特定部１１でのサービスシステム特定処理（図８：ステップ１００）について詳細に説明する。図９は、第１の実施の形態にかかるサービスシステム特定処理を示すフローチャートである。

まず、サービスシステム特定部１１は、サービスポータルシステム３０からのサービスシステム構築指示に応じて、サービスポータルシステム３０のシステム要件ＤＢ３２に登録されている、利用者から指定された要求サービスシステムに関するシステム要件データを取得する（ステップ１１０）。

次に、サービスシステム特定部１１は、サービスカタログＤＢ１２に予め登録されている規定サービスシステムのうちから、当該システム要件データで指定された要求サービスシステムのサービスカテゴリと一致する規定サービスシステムを検索する（ステップ１１１）。

ここで、要求サービスシステムのサービスカテゴリと一致する規定サービスシステムが１つ見つかった場合（ステップ１１２：ＹＥＳ）、サービスシステム特定部１１は、検索された規定サービスシステムを、実際に構築する対象サービスシステムとして特定し、特定した規定サービスシステムを、実際に構築する対象サービスシステムとしてサービス設計書に記述してサービス設計書ＤＢ１３に登録し（ステップ１１３）、一連のサービスシステム特定処理を終了する。

一方、要求サービスシステムのサービスカテゴリと一致する規定サービスシステムが登録されていない場合や、要求サービスシステムのサービスカテゴリと一致する規定サービスシステムが複数見つかった場合など、要求サービスシステムに対応する規定サービスシステムが一意に特定できなかった場合（ステップ１１２：ＮＯ）、サービスシステム特定部１１は、システム要件データで指定された要求サービスシステムに対応する対象サービスシステムが特定できなかった旨の処理結果をサービスポータルシステム３０へ通知して、一連のサービスシステム特定処理を終了する。これにより、オーケストレーションシステム１０でのサービスシステム構築処理も中止される。

なお、要求サービスシステムに対応する規定サービスシステムが一意に特定できなかった場合、サービスシステム特定部１１は、オーケストレーションシステム１０に設けられている管理画面などを用いて、システム要件データで指定された要求サービスシステムに対応する対象サービスシステムが特定できなかった旨の処理結果を通知する。これにより、システム管理者は、サービスカタログＤＢ１２に登録されている規定サービスシステムの追加や見直しを行うことができる。

また、図９では、サービスカテゴリを検索条件として規定サービスシステムを検索する場合を例として説明したがこれに限定されるものではない。例えば、サービスカテゴリに代えてシステム要件データでシステム要件として指定されているパフォーマンス要件と一致する規定サービスシステムを検索するようにしてもよく、さらにはサービスカテゴリおよびパフォーマンス要件の両方と一致する規定サービスシステムを検索するようにしてもよい。これにより、利用者の細かな要件に対応した対象サービスシステムを特定することができる。

［抽象化プロセスフロー特定処理］
次に、図１０を参照して、本実施の形態にかかる抽象化プロセスフロー特定部１４での抽象化プロセスフロー特定処理（図８：ステップ１０１）について詳細に説明する。図１０は、抽象化プロセスフロー特定処理を示すフローチャートである。

まず、抽象化プロセスフロー特定部１４は、サービスポータルシステム３０からのサービスシステム構築指示に応じて、サービスポータルシステム３０のシステム要件ＤＢ３２に登録されている、利用者から指定された要求サービスシステムに関するシステム要件データを取得する（ステップ１２０）。

次に、抽象化プロセスフロー特定部１４は、抽象化プロセスＤＢ１５に予め登録されている抽象化プロセスフローのうちから、当該システム要件データで指定された要求サービスシステムのサービスカテゴリと一致する抽象化プロセスフローを検索する（ステップ１２１）。

ここで、要求サービスシステムのサービスカテゴリと一致する抽象化プロセスフローが見つかった場合（ステップ１２２：ＹＥＳ）、抽象化プロセスフロー特定部１４は、検索された抽象化プロセスフローを示すプロセスフローＩＤを抽象化プロセスフロー実行部１６に通知し（ステップ１２３）、一連の抽象化プロセスフロー特定処理を終了する。

一方、要求サービスシステムのサービスカテゴリと一致する抽象化プロセスフローが見つからなかった場合（ステップ１２２：ＮＯ）、抽象化プロセスフロー特定部１４は、システム要件データで指定された要求サービスシステムに対応する抽象化プロセスフローが特定できなかった旨の処理結果をサービスポータルシステム３０へ通知して、一連のサービスシステム特定処理を終了する。これにより、オーケストレーションシステム１０でのサービスシステム構築処理も中止される。

なお、要求サービスシステムに対応する抽象化プロセスフローが一意に特定できなかった場合、サービスシステム特定部１１は、オーケストレーションシステム１０に設けられている管理画面などを用いて、システム要件データで指定された要求サービスシステムに対応する抽象化プロセスフローが特定できなかった旨の処理結果を通知する。これにより、システム管理者は、抽象化プロセスＤＢ１５に登録されている抽象化プロセスフローの追加や見直しを行うことができる。

［抽象化プロセスフロー実行処理］
次に、図１１を参照して、本実施の形態にかかる抽象化プロセスフロー実行部１６での抽象化プロセスフロー実行処理（図８：ステップ１０２）について詳細に説明する。図１１は、抽象化プロセスフロー実行処理を示すフローチャートである。

まず、抽象化プロセスフロー実行部１６は、抽象化プロセスフロー特定部１４から通知されたプロセスフローＩＤを受信した場合（ステップ１３０：ＹＥＳ）、当該プロセスフローＩＤに対応する抽象化プロセスフローを抽象化プロセスＤＢ１５から取得する（ステップ１３１）。

続いて、抽象化プロセスフロー実行部１６は、取得した抽象化プロセスフローに記述されている抽象化プロセスを実行順に選択し、選択した抽象化プロセスごとに当該抽象化プロセスと対応する抽象化ＡＰＩの呼び出しをサービスシステム構築部１８へ通知することにより、抽象化プロセスフローを実行する（ステップ１３２）。すべての抽象化プロセスについて抽象化ＡＰＩの呼び出しが終了した時点で、一連の抽象化プロセスフロー実行処理を終了する。

一方、プロセスフローＩＤではなく（ステップ１３０：ＮＯ）、抽象化ＡＰＩの呼び出しに応じてサービスシステム構築部１８から通知された実行結果を受信した場合（ステップ１３３：ＹＥＳ）、抽象化プロセスフロー実行部１６は、受信した実行結果に基づいて抽象化プロセスの実施状況を示すステータスデータをステータスＤＢ１７へ記録し（ステップ１３４）、一連の抽象化プロセスフロー実行処理を終了する。

［サービスシステム構築処理］
次に、図１２を参照して、本実施の形態にかかるサービスシステム構築部１８でのサービスシステム構築処理（図８：ステップ１０３）について詳細に説明する。図１２は、サービスシステム構築処理を示すフローチャートである。

まず、サービスシステム構築部１８は、抽象化プロセスフロー実行部１６から通知された抽象化ＡＰＩの呼び出しを受信した場合（ステップ１４０：ＹＥＳ）、サービス設計書ＤＢ１３のサービス設計書で指定されている対象サービスシステムと対応するクラスから、当該抽象化ＡＰＩをメソッドとして実装するアダプタ１９のインスタンスを生成する（ステップ１４１）。
この後、サービスシステム構築部１８は、生成したアダプタ１９で抽象化ＡＰＩの処理と対応する、リソースマネージャ２０さらにはリソース２１を制御管理するためのメソッドを実行し（ステップ１４２）、一連のサービスシステム構築処理を終了する。

一方、抽象化ＡＰＩの呼び出しではなく（ステップ１４０：ＮＯ）、メソッドの実行に応じてリソースマネージャ２０から通知された実行結果を受信した場合（ステップ１４３：ＹＥＳ）、サービスシステム構築部１８は、受信した実行結果を抽象化プロセスフロー実行部１６へ通知し（ステップ１４４）、一連のサービスシステム構築処理を終了する。

なお、インスタンスを生成する際、サービス設計書で指定されている対象サービスシステムのサービス名と、アダプタ１９のクラス名とが一致しない場合も考えられる。このような場合には、サービス名とクラス名との対応関係を示すテーブルを予め登録しておき、インスタンス生成時に、当該テーブルを参照してサービス名と対応するクラス名を特定するようにしてもよい。

［動作例］
次に、図１３および図１４を参照して、本実施の形態にかかるオーケストレーションシステム１０のサービスシステム構築動作に関する動作例について説明する。図１３は、第１の実施の形態にかかるサービスシステム構築動作を示すシーケンス図である。図１４は、第１の実施の形態にかかるサービスシステム構築動作（続き）を示すシーケンス図である。

まず、サービスシステム特定部１１は、サービスポータルシステム３０のシステム要件ＤＢ３２から取得したシステム要件データに応じて（ステップ１５０）、サービスカタログＤＢ１２から、当該システム要件データで指定された要求サービスシステムのサービスカテゴリと一致する規定サービスシステムを検索する（ステップ１５１）。

次に、サービスシステム特定部１１は、検索により得られた規定サービスシステムを、実際に構築する対象サービスシステムとして特定し（ステップ１５２）、特定した規定サービスシステムを、実際に構築する対象サービスシステムとしたサービス設計書を作成し（ステップ１５３）、サービス設計書ＤＢ１３に登録する（ステップ１５４）。

これと並行あるいは前後して、抽象化プロセスフロー特定部１４は、サービスポータルシステム３０のシステム要件ＤＢ３２から取得したシステム要件データに応じて（ステップ１５０）、抽象化プロセスＤＢ１５から、当該システム要件データで指定された要求サービスシステムのサービスカテゴリと一致する抽象化プロセスフローを検索する（ステップ１５５）。

次に、抽象化プロセスフロー特定部１４は、検索により得られた抽象化プロセスフローを、要求サービスシステムの構築のために実際に実行すべき抽象化プロセスフローとして特定し（ステップ１５６）、当該抽象化プロセスフローを示すプロセスフローＩＤを抽象化プロセスフロー実行部１６に通知する（ステップ１５７）。

この後、抽象化プロセスフロー実行部１６は、抽象化プロセスフロー特定部１４から通知されたプロセスフローＩＤに応じて、抽象化プロセスＤＢ１５から当該プロセスフローＩＤに対応する抽象化プロセスフローを取得し（ステップ１６０）、取得した抽象化プロセスフローに基づき抽象化プロセスフロー実行処理を実行する（ステップ１６１）。

抽象化プロセスフロー実行処理において、抽象化プロセスフロー実行部１６は、まず、取得した抽象化プロセスフローに記述されている抽象化プロセスを実行順に選択し（ステップ１７０）、選択した抽象化プロセスごとに当該抽象化プロセスと対応する抽象化ＡＰＩの呼び出しをサービスシステム構築部１８へ通知する（ステップ１７１）。

抽象化ＡＰＩの呼び出しに応じて、サービスシステム構築部１８は、まず、抽象化ＡＰＩの呼び出し時に通知された、要求サービスシステムを示すオーダーＩＤに関するサービス設計書をサービス設計書ＤＢ１３から取得し（ステップ１７２）、当該サービス設計書で指定されている対象サービスシステムと対応するクラスから、当該抽象化ＡＰＩをメソッドとして実装するアダプタ１９のインスタンスを生成する（ステップ１７３）。

続いて、サービスシステム構築部１８は、生成したアダプタ１９のインスタンスに対して抽象化ＡＰＩと対応する処理（メソッド）の実行を指示する（ステップ１７４）。
これに応じて、アダプタ１９のインスタンスは、抽象化ＡＰＩと対応する処理（メソッド）を実行することにより、リソースマネージャ２０に対してリソース２１の連携指示を行う（ステップ１７５）。これにより、リソースマネージャ２０が、指定されたリソース２１に対して対象サービスシステムの構築に関する制御管理を実行する。

次に、リソースマネージャ２０から通知された実行結果に応じて、アダプタ１９のインスタンスは、当該実行結果をサービスシステム構築部１８へ通知し（ステップ１７６）、サービスシステム構築部１８は、通知された実行結果を抽象化プロセスフロー実行部１６へ通知する（ステップ１７７）。
これに応じて、抽象化プロセスフロー実行部１６は、受信した実行結果に基づいて抽象化プロセスの実施状況を示すステータスデータをステータスＤＢ１７へ記録する（ステップ１７８）。

この後、抽象化プロセスフロー実行部１６は、抽象化プロセスフローのうち、未実行の抽象化プロセスが存在するか確認し（ステップ１７９）、存在する場合には（ステップ１７９：ＹＥＳ）、ステップ１７０へ戻る。これにより、未実行の抽象化プロセスが実行順に選択され、ステップ１７１〜１７８が繰り返し実行される。
一方、すべての抽象化プロセスの実行が終了している場合には（ステップ１７９：ＮＯ）、一連のサービスシステム構築動作が終了する。

［第１の実施の形態の効果］
このように、本実施の形態は、サービスシステム特定部１１が、システム要件データに基づき要求サービスシステムと対応する規定サービスシステムを対象サービスシステムとして特定し、抽象化プロセスフロー特定部１４が、要求サービスシステムのサービスカテゴリに関する抽象化プロセスフローを特定し、抽象化プロセスフロー実行部１６が、抽象化プロセスフローに記述された抽象化プロセスごとに当該抽象化プロセスと対応する抽象化ＡＰＩの呼び出しを行い、サービスシステム構築部１８が抽象化ＡＰＩの呼び出しに応じて、対象サービスシステムと対応するアダプタ１９のうち、当該抽象化ＡＰＩと対応する処理を実装するアダプタ１９で当該処理を実行してリソースマネージャ２０を制御することにより、当該対象サービスシステムを構築するようにしたものである。

これにより、サービスシステムの構築に用いるプロセスおよびプロセスフローが抽象化（上位概念化）されて、実際に構築するサービスシステムとは切り離されて、同一サービスカテゴリに属するシステムサービスで共用されることになる。このため、オーケストレーションシステム１０で管理すべきプロセスの数を大幅削減できる。また、サービスカテゴリごとに１つの抽象化プロセスフローを用意しておけばよくなるため、オーケストレーションシステム１０で管理すべきプロセスフローの数も大幅に削減できる。

したがって、システムサービスの構築時に連携させるリソースマネージャ２０やリソース２１の増減に対して、プロセスフローやプロセスの軽微な変更により、柔軟に対応することができる。また、同一のプロセスで異なるサービス（例えば、ファイヤーウォーや侵入検知システム）を構築することができ、オーケストレーションシステム１０におけるプロセス管理を大幅に簡素化することが可能となる。

また、対象サービスシステムに応じて処理対象であるリソースマネージャ２０や処理内容が異なるメソッドを、抽象化されたメソッド名を有する抽象化ＡＰＩとしてアダプタ１９に実装されているため、これらアダプタ１９で、リソース２１の制御管理における対象サービスシステムに応じた処理対象や処理内容の違いが吸収されることになる。したがって、抽象化プロセス側からは、抽象化されたメソッド名で呼び出しを行うだけで、対象サービスシステムに応じた処理対象や処理内容の具体的なメソッドを実行することができ、結果として、プロセスおよびプロセスフローの抽象化が極めて容易に実現できる。

また、本実施の形態は、サービスシステム構築部１８が、抽象化ＡＰＩの呼び出しに応じて、対象サービスシステムと対応するアダプタ１９のうち、当該抽象化ＡＰＩと対応するメソッドを実装するアダプタ１９のインスタンスを生成し、生成したインスタンスで当該メソッドを実行してリソースマネージャ２０を制御するようにしたので、対象サービスシステムに対応するリソースマネージャ２０さらにはリソース２１とのインターフェースを実現する適切なアダプタ１９を、動的に切替選択することができる。これにより、対象サービスシステムによるインターフェースの違いに幅広くかつ柔軟に対応することが可能となる。

また、本実施の形態は、サービスシステム特定部１１が、規定サービスシステムのうち、これら規定サービスシステムごとに予めシステム要件として登録されているサービスカテゴリが、システム要件データで指定された要求サービスシステムに関するシステム要件のサービスカテゴリと一致する規定サービスシステムを、対象サービスシステムとして特定するようにしたので、利用可能な規定サービスシステムが増大しても、利用者の要求サービスシステムに対応する対象サービスシステムを容易に特定することができる。

また、本実施の形態において、サービスシステム特定部１１が、規定サービスシステムのうち、これら規定サービスシステムごとに予めシステム要件として登録されている当該規定サービスシステムのパフォーマンスに関するパフォーマンス要件が、システム要件データで指定された要求サービスシステムに関するシステム要件のパフォーマンス要件と一致する規定サービスシステムを、対象サービスシステムとして特定するようにしてもよく、利用可能な規定サービスシステムが増大しても、利用者の要求サービスシステムに対応する対象サービスシステムを容易に特定することができる。

［第２の実施の形態］
次に、本発明の第２の実施の形態にかかるオーケストレーションシステム１０について説明する。
第１の実施の形態では、要求サービスシステムに対応する対象サービスシステムを特定する際、具体的には、システム要件データで利用者がシステム要件として指定した要求サービスシステムのサービスカテゴリに基づき対象サービスシステムを特定する場合を例として説明した。本実施の形態では、システム要件データで利用者がシステム要件として指定したキーワードに基づき対象サービスシステムを特定する場合を例として説明する。

本実施の形態において、サービスシステム特定部１１は、サービスカタログＤＢ１２に予め登録されている規定サービスシステムのうちから当該システム要件データでシステム要件として指定された要求サービスシステムに関するキーワードと対応する規定サービスシステムを、実際に構築する対象サービスシステムとして特定する機能を有している。

図１５は、第２の実施の形態にかかるシステム要件データの構成例である。ここでは、システム要件データとして、利用者が要件入力用ポータルサイト３１で入力したシステム要件データごとに固有のオーダーＩＤと、当該システム要件データを入力した利用者を示す利用者ＩＤと、当該システム要件データで指定された要求サービスシステムに関するキーワードや要求サービスシステムに求められるパフォーマンス要件など、要求サービスシステムに求める各種の要件を示すシステム要件とが、組として登録されている。

図１６は、第２の実施の形態にかかるカタログデータの構成例である。ここでは、規定サービスシステムごとに、当該規定サービスシステムのサービス名と、当該規定サービスシステムに関するキーワード群や当該規定サービスシステムが持つパフォーマンス要件など、規定サービスシステムが持つ各種の要件を示すシステム要件とが、組として登録されている。

［第２の実施の形態の動作］
次に、図１７を参照して、本実施の形態にかかるサービスシステム特定部１１でのサービスシステム特定処理（図８：ステップ１００）について詳細に説明する。図１７は、第２の実施の形態にかかるサービスシステム特定処理を示すフローチャートである。

まず、サービスシステム特定部１１は、サービスポータルシステム３０からのサービスシステム構築指示に応じて、サービスポータルシステム３０のシステム要件ＤＢ３２に登録されている、利用者から指定された要求サービスシステムに関するシステム要件データを取得する（ステップ２００）。

次に、サービスシステム特定部１１は、サービスカタログＤＢ１２に予め登録されている規定サービスシステムのうちから、当該システム要件データでシステム要件として指定された要求サービスシステムのキーワードをキーワード群として含む規定サービスシステムを検索する（ステップ２０１）。

ここで、要求サービスシステムのキーワードを含む規定サービスシステムが１つ見つかった場合（ステップ２０２：ＹＥＳ）、サービスシステム特定部１１は、検索された規定サービスシステムを、実際に構築する対象サービスシステムとして特定し、特定した規定サービスシステムを、実際に構築する対象サービスシステムとしてサービス設計書に記述してサービス設計書ＤＢ１３に登録し（ステップ２０３）、一連のサービスシステム特定処理を終了する。

一方、要求サービスシステムのキーワードを含む規定サービスシステムが登録されていない場合や、要求サービスシステムのキーワードを含む規定サービスシステムが複数見つかった場合など、要求サービスシステムに対応する規定サービスシステムが一意に特定できなかった場合（ステップ２０２：ＮＯ）、サービスシステム特定部１１は、システム要件データで指定された要求サービスシステムに対応する対象サービスシステムが特定できなかった旨の処理結果をサービスポータルシステム３０へ通知して、一連のサービスシステム特定処理を終了する。これにより、オーケストレーションシステム１０でのサービスシステム構築処理も中止される。

なお、要求サービスシステムに対応する規定サービスシステムが一意に特定できなかった場合、サービスシステム特定部１１は、オーケストレーションシステム１０に設けられている管理画面などを用いて、システム要件データで指定された要求サービスシステムに対応する対象サービスシステムが特定できなかった旨の処理結果を通知する。これにより、システム管理者は、サービスカタログＤＢ１２に登録されている規定サービスシステムの追加や見直しを行うことができる。

また、図１７では、キーワードを検索条件として規定サービスシステムを検索する場合を例として説明したがこれに限定されるものではない。例えば、指定されたキーワードを含むとともにパフォーマンス要件が一致する規定サービスシステムを検索するようにしてもよい。これにより、利用者の細かな要件に対応した対象サービスシステムを特定することができる。

［第２の実施の形態の効果］
このように、本実施の形態は、サービスシステム特定部１１が、これら規定サービスシステムごとに予め登録されているキーワード群に、システム要件データでシステム要件として指定された要求サービスシステムに関するキーワードを含む規定サービスシステムを、対象サービスシステムとして特定するようにしたものである。
これにより、利用者が要求サービスシステムのサービス内容に関するキーワードを指定するだけで、当該要求サービスシステムに対応する規定サービスシステムを特定することができ、利用者が予め要求サービスシステムのサービスカテゴリを調べるなどの作業負担を削減することができる。

［実施の形態の拡張］
以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解しうる様々な変更をすることができる。また、各実施形態については、矛盾しない範囲で任意に組み合わせて実施することができる。

１０…オーケストレーションシステム、１１…サービスシステム特定部、１２…サービスカタログＤＢ、１３…サービス設計書ＤＢ、１４…抽象化プロセスフロー特定部、１５…抽象化プロセスＤＢ、１６…抽象化プロセスフロー実行部、１７…ステータスＤＢ、１８…サービスシステム構築部、１９…アダプタ、２０…リソースマネージャ、２１…リソース、３０…サービスポータルシステム、３１…要件入力用ポータルサイト、３２…システム要件ＤＢ。

Claims (5)

1. 通信回線を介してリソースの管理制御を行うリソースマネージャを制御することにより、利用者が要求する要求サービスシステムを構築するオーケストレーションシステムであって、
   利用者から指定された前記要求サービスシステムに関するシステム要件データに基づき、予め登録されている規定サービスシステムのうちから当該要求サービスシステムと対応する規定サービスシステムを、実際に構築する対象サービスシステムとして特定するサービスシステム特定部と、
   サービスシステムの種別を示すサービスカテゴリごとに予め登録されている、当該サービスカテゴリに属するサービスシステムの構築時に実行すべき抽象化プロセスが実行順に記述された抽象化プロセスフローのうちから、前記要求サービスシステムのサービスカテゴリに関する抽象化プロセスフローを特定する抽象化プロセスフロー特定部と、
   前記抽象化プロセスフローに記述された抽象化プロセスを実行順に選択し、選択した抽象化プロセスごとに当該抽象化プロセスと対応する抽象化ＡＰＩの呼び出しを行う抽象化プロセスフロー実行部と、
   前記規定サービスシステムごとに、当該規定サービスシステムの構築に用いるリソースマネージャを制御するためのアダプタを有し、前記抽象化ＡＰＩの呼び出しに応じて、前記対象サービスシステムと対応するアダプタのうちから、当該抽象化ＡＰＩと対応する処理を実装するアダプタを選択し、選択したアダプタで当該処理を実行して前記リソースマネージャを制御することにより、当該対象サービスシステムを構築するサービスシステム構築部と
   を備えることを特徴とするオーケストレーションシステム。
2. 請求項１に記載のオーケストレーションシステムにおいて、
   前記サービスシステム構築部は、前記抽象化ＡＰＩの呼び出しに応じて、前記対象サービスシステムと対応するアダプタのうち、当該抽象化ＡＰＩと対応するメソッドを実装するアダプタのインスタンスを生成し、生成したインスタンスで当該メソッドを実行して前記リソースマネージャを制御することを特徴とするオーケストレーションシステム。
3. 請求項１または請求項２に記載のオーケストレーションシステムにおいて、
   前記サービスシステム特定部は、前記規定サービスシステムのうち、これら規定サービスシステムごとに予め登録されているシステム要件が、前記システム要件データで指定された前記要求サービスシステムに関するシステム要件と一致する規定サービスシステムを、前記対象サービスシステムとして特定することを特徴とするオーケストレーションシステム。
4. 通信回線を介してリソースの管理制御を行うリソースマネージャを制御することにより、利用者が要求する要求サービスシステムを構築するオーケストレーション方法であって、
   サービスシステム特定部が、利用者から指定された前記要求サービスシステムに関するシステム要件データに基づき、予め登録されている規定サービスシステムのうちから当該要求サービスシステムと対応する規定サービスシステムを、実際に構築する対象サービスシステムとして特定するサービスシステム特定ステップと、
   抽象化プロセスフロー特定部が、サービスシステムの種別を示すサービスカテゴリごとに予め登録されている、当該サービスカテゴリに属するサービスシステムの構築時に実行すべき抽象化プロセスが実行順に記述された抽象化プロセスフローのうちから、前記要求サービスシステムのサービスカテゴリに関する抽象化プロセスフローを特定する抽象化プロセスフロー特定ステップと、
   抽象化プロセスフロー実行部が、前記抽象化プロセスフローに記述された抽象化プロセスを実行順に選択し、選択した抽象化プロセスごとに当該抽象化プロセスと対応する抽象化ＡＰＩの呼び出しを行う抽象化プロセスフロー実行ステップと、
   サービスシステム構築部が、前記規定サービスシステムごとに、当該規定サービスシステムの構築に用いるリソースマネージャを制御するためのアダプタを有し、前記抽象化ＡＰＩの呼び出しに応じて、前記対象サービスシステムと対応するアダプタのうちから、当該抽象化ＡＰＩと対応する処理を実装するアダプタを選択し、選択したアダプタで当該処理を実行して前記リソースマネージャを制御することにより、当該対象サービスシステムを構築するサービスシステム構築ステップと
   を備えることを特徴とするオーケストレーション方法。
5. コンピュータを、請求項１〜請求項３のいずれか１つに記載されたオーケストレーションシステムを構成する各部として機能させるためのプログラム。

Images