JP5461448B2

JP5461448B2 - 資源予約装置及び方法及びプログラム

Info

Publication number: JP5461448B2
Application number: JP2011007235A
Authority: JP
Inventors: 幸男築島; 一久山田; 和浩松田; 猛仁山本
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2011-01-17
Filing date: 2011-01-17
Publication date: 2014-04-02
Anticipated expiration: 2031-01-17
Also published as: JP2012150569A

Description

本発明は、資源予約装置及び方法及びプログラムに係り、特に、アプリケーション、データ、計算機、ストレージ及びネットワークなどの資源を管理し、クライアントからの予約要求に応じて資源を予約して提供するための資源予約装置及び方法及びプログラムに関する。

2006年前後までに計算機やネットワーク、ストレージなどの異種資源の予約技術は考案されていたが、それらは予約可能な計算機やストレージを決定した後、それらの間を接続するネットワークを決定していた（例えば、非特許文献1参照）。このような仕組みが考えられた要因として、計算機資源やストレージ資源を提供する事業者（主にデータセンタ）と、ネットワーク資源を提供する事業者（主に通信事業者）と、が異なっていたためである。

しかしながら、大手の通信事業者はデータセンタ事業も手掛けている場合がある。そのような大手通信事業者から見て、既存の資源予約技術では計算機資源やネットワーク資源、ストレージ資源からなるインフラ全体での資源予約の最適化を実現できていなかった。

インフラ全体での資源予約の最適化を図るためには、予約可能な計算機資源、ストレージ資源、ネットワーク資源を総合的に考えてから資源予約を実行する必要がある。

複数の異なる資源を予約する際、資源の組み合わせパターンを検討するアルゴリズムはこれまでも多く存在する。例えば、力任せ探索／しらみつぶし探索や、バックトラック法、ミニマックス法など原理的な方法がある。

さらには、線形計画法を利用して、組み合わせパターンの最適なものを求める技術も報告されている（例えば、非特許文献2参照）。

上記のような組み合わせアルゴリズムは、事前に予約可能な異種資源の情報を収集し、異種資源を統合的に並べた情報、すなわち、テーブルが必要である。しかしながら、これまで異種資源を予約する技術や異種資源の組み合わせを計算する技術は存在していても、その間に存在する計算テーブルを生成する技術は報告されていなかった。

近年、クライアントからの予約要求に応じ、サービスプロバイダが多種多様な資源を予約して提供するため、アプリケーション、データ、計算機、ストレージ、ネットワーク等のＩＣＴ(Information and Communication Technology)資源について資源の物理特性（例えば、種別／状態／環境）を隠蔽し、その属性を変換して同資源を異なるものしてみせるまたは使わせるための仮想化技術が研究開発され、多くの研究成果が既に報告されている（例えば、非特許文献３、非特許文献４、非特許文献５、非特許文献６、非特許文献７、非特許文献８、非特許文献９、非特許文献１０、非特許文献１１、非特許文献１２、非特許文献１３、特許文献１、特許文献２、特許文献３、特許文献４を参照）。

上記の先行技術文献で述べられているグリッド・リソース・スケジューラや資源管理装置は、本発明の資源予約装置の従来技術の一例であり、また、先行文献内の、コンピューティング・リソース・マネージャや端末管理装置は、本発明の計算機データベース管理部の従来の一例であり、ストレージ・リソース・マネージャは、本発明のストレージデータベース管理部の従前の一例である。同様に、ネットワーク・リソース・マネージャや通信管理装置、経路探索装置は、本発明のネットワークデータベース管理部の従前の一例である。

上記の先行文献でも示されている通り、サービスプロバイダがクライアントからの予約要求に応じて動的に計算機資源、ストレージ資源、ネットワーク資源を予約して提供するための基盤技術は既に確立されている。

特許公開2010-068140号公報特許公開2008-301225号公報特許公開2008-131247号公報特許公開2008-158844号公報

G.Lambda: coordination of a grid scheduler and lambda path service over GMPLS, Future Generation Computer Systems, Volume 22 Issue 8, October 2006. 竹房あつ子、中田秀基、工藤知宏、田中良夫、"高品質分散実行環境のための計算・ネットワーク資源のグローバルスケジューリング手法"情報処理学会研究報告 2008-HPC-1'19, 2009-02, pp.55-60. 竹房あつ子、他「グリッドにおける計算資源と光パスネットワーク資源のコアロケーション実験」SACSIS(Symposium on Advanced Computing systems and Infrastructures) 2006 竹房あつ子、他「計算資源とネットワーク資源を同時確保する予約ベースグリッドスケジューリングシステム」SACSIS(Symposium on Advanced Computing systems and Infrastructures) 2006 竹房あつ子、他「ミドルウェア連携による計算・ネットワーク資源の日米間グリッドコアロケーション実験」第164回計算機アーキテクチャ・第109回ハイパフォーマンスコンピューティング合同研究発表会竹房あつ子、他「多様な資源を事前予約で同時確保するためのグリッドコアロケーションシステムフレームワークGridARS」情報処理学会論文誌コンピューティングシステム、 48(SIG18)、pp. 32-42、2007 竹房あつ子、他「異種の複数スケジューラで管理される資源を事前同時予約するグリッド高性能計算の実行環境」HPCS 2007、2007年ハイパフォーマンスコンピューティングと計算科学シンポジウム論文集竹房あつ子、他「高品質分散実行環境のための計算・ネットワーク資源のグローバルスケジューリング手法」情報処理学会研究報告2008-HPC-119、2009 林通秋、他「グリッドアプリケーションのためのGMPLSネットワーク資源の管理制御」電子情報通信学会技術研究報告PN2006-8、2006 松田秀雄「次世代研究環境を目指すNAREGIデータグリッド」NAREGIシンポジウム2007 谷村勇輔、他「予約利用可能なオブジェクトベース・ストレージの設計」情報処理学会研究報告(HOKKE 2009)、2009-14、pp.79-84、2009 谷村勇輔、他「アクセス性能を保証する並列ファイルシステムの提案とストレージサーバの設計」、情報処理学会研究報告（SWoPP 2009）、2009-HPC-121-33、2009

しかしながら、上記の仮想化技術を適用されたサービスプラットフォームの上で既存のネットワーク上のアプリケーションを動作させる場合、クライアントに対して次のような変化を与えてしまい、結果的にクライアントが該アプリケーションを動作させることを困難にさせてしまう可能性がある。

まず、クライアントが該アプリケーションを動作させるための要求メッセージの内容と、クライアントが該アプリケーションを動作させるための計算機資源や、ストレージ資源、ネットワーク資源を予約するための要求メッセージの内容とが大きく異なる。

それゆえ、クライアントは、該アプリケーションを動作させるために上記の2種類の要求メッセージを使わなければならず、複雑な作業を強いられることとなる。

また、前述の特許文献４に示されるとおり、クライアントがアプリケーションを動作させるための計算機資源や、ストレージ資源、ネットワーク資源を予約するための要求メッセージについて、予約される計算機資源や、ストレージ資源、ネットワーク資源の特徴に関してのみ、クライアントがアプリケーションを動作させるための要求メッセージの内容に基づいて自動的にパラメータを補完する方法が提案されている。

しかしながら、クライアントが計算機資源、ストレージ資源、ネットワーク資源の内のどの資源を予約したいのか、というオブジェクト自体を補完する方法は提案されていない。

本発明は、上記の点に鑑みなされたもので、クライアントが予約すべき資源群の種別や、それぞれの資源の場所を明示的に指定しなくても、適切な資源を自動的に予約することが可能な資源予約装置及び方法及びプログラムを提供することを目的とする。

上記の課題を解決するために、本発明（請求項１）は、アプリケーション、データ、計算機、ストレージ及びネットワークを含む資源を管理し、クライアント装置からの予約要求に応じて資源を予約する資源予約装置であって、
ユーザ、前記アプリケーション、前記データ、前記計算機、前記ストレージ及び前記ネットワークの各情報を管理する複数のデータベース管理手段と接続され、前記クライアント装置との間で、所要サービスに対応するオブジェクトとコネクションが指定された資源予約メッセージを交換するメッセージ交換手段と、
前記複数のデータベース管理手段と管理対象のドメイン及びドメイン間の関係及びコネクションの端点が特定可能な情報を保持するサービスデータベース管理手段と、
前記資源予約メッセージに基づいて、前記サービスデータベース管理手段を参照して、サービス内容と性能保証の種別と、サービスのために必要となるオブジェクトとコネクション、アプリケーションデータとデータの配置方法、ネットワークインフラ条件に基づくコネクションの資源予約の必要性の、一部または全部について決定するサービス確認手段と、
前記資源予約メッセージにより前記クライアント装置から取得したオブジェクト群とコネクション群の存在や内容を確認するオブジェクト・コネクション解析手段と、
前記サービス確認手段と前記オブジェクト・コネクション解析手段の結果に基づいて、欠損しているオブジェクトを生成すると共に、前記メッセージ交換手段を介して前記各データベース管理手段との間でデータ交換を行うことによりオブジェクトの内容を補完してオブジェクト候補として前記サービスデータベース管理手段に格納するオブジェクト変更手段と、
前記サービス確認手段と前記オブジェクト・コネクション解析手段と前記オブジェクト変更手段の結果に基づいて、欠損しているコネクションを生成すると共に、前記メッセージ交換手段を介して、ネットワークデータを管理するデータベース管理手段とのデータ交換を行うことにより、コネクションの内容を補完してコネクション候補として前記サービスデータベース管理手段に格納するコネクション変更手段と、
前記オブジェクト変更手段と前記コネクション変更手段で探索され、前記サービスデータベース管理手段に格納されたオブジェクト群とコネクション群の組み合わせからなるサービスパターンの中から実際に資源予約する一つのサービスパターンを選択し、選択されたオブジェクトまたはコネクションを構成する資源を管理している各々のデータベース管理手段と連携して資源予約を行う機能を有する資源予約手段と、を有する。

また、本発明（請求項２）は、請求項１の前記オブジェクト変更手段に、
予約可能なオブジェクト候補が無い場合に、サービス内容を変更して、再度処理を行う手段を含む。

また、本発明（請求項３）は、請求項１または２の前記サービス確認手段に、
前記資源予約メッセージに基づいて、ドメインのタイプに関する情報を格納した前記サービスデータベース管理手段を参照する、
または、
資源予約装置を実現するソフトウェアのソースコードに物理的に記載されているか否かの判断、
のいずれかにより、前記資源予約メッセージで要求されているサービスに対し、ネットワーク資源を予約するか否かを判定する手段を含む。

本発明（請求項４）は、アプリケーション、データ、計算機、ストレージ及びネットワークを含む資源を管理し、クライアント装置からの予約要求に応じて資源を予約する資源予約方法であって、
ユーザ、前記アプリケーション、前記データ、前記計算機、前記ストレージ及び前記ネットワークの各情報を管理する複数のデータベース管理手段と接続される資源予約装置において、
メッセージ交換手段が、前記クライアント装置との間で、所要サービスに対応するオブジェクトとコネクションが指定された資源予約メッセージを交換するメッセージ交換ステップと、
サービス確認手段が、前記資源予約メッセージに基づいて、前記複数のデータベース管理手段と管理対象のドメイン及びドメイン間の関係及びコネクションの端点が特定可能な情報を保持するサービスデータベース管理手段を参照して、サービス内容と性能保証の種別と、サービスのために必要となるオブジェクトとコネクション、アプリケーションデータとデータの配置方法、ネットワークインフラ条件に基づくコネクションの資源予約の必要性の、一部または全部について決定するサービス確認ステップと、
オブジェクト・コネクション解析手段が、前記資源予約メッセージにより前記クライアント装置から取得したオブジェクト群とコネクション群の存在や内容を確認するオブジェクト・コネクション解析ステップと、
オブジェクト変更手段が、前記サービス確認ステップと前記オブジェクト・コネクション解析ステップの結果に基づいて、欠損しているオブジェクトを生成すると共に、前記各データベース管理手段との間でデータ交換を行うことによりオブジェクトの内容を補完してオブジェクト候補として前記サービスデータベース管理手段に格納するオブジェクト変更ステップと、
コネクション変更手段が、前記サービス確認ステップと前記オブジェクト・コネクション解析ステップと前記オブジェクト変更ステップを実行した結果に基づいて、欠損しているコネクションを生成すると共に、ネットワークデータを管理するデータベース管理手段とのデータ交換を行うことにより、コネクションの内容を補完してコネクション候補として前記サービスデータベース管理手段に格納するコネクション変更ステップと、
資源管理手段が、前記オブジェクト変更ステップと前記コネクション変更ステップで探索され、前記サービスデータベース管理手段に格納されたオブジェクト群とコネクション群の組み合わせからなるサービスパターンの中から実際に資源予約する一つのサービスパターンを選択し、選択されたオブジェクトまたはコネクションを構成する資源を管理している各々のデータベース管理手段と連携して資源予約を行う機能を有する資源予約ステップと、実行する。

また、本発明（請求項５）は、請求項４の前記オブジェクト変更において、
予約可能なオブジェクト候補が無い場合に、サービス内容を変更して、再度処理を行う。

また、本発明（請求項６）は、請求項４または５の前記サービス確認ステップにおいて、
前記資源予約メッセージに基づいて、ドメインのタイプに関する情報を格納した前記サービスデータベース管理手段を参照する、
または、
資源予約装置を実現するソフトウェアのソースコードに物理的に記載されているか否かの判断、
のいずれかにより、前記資源予約メッセージで要求されているサービスに対し、ネットワーク資源を予約するか否かを判定する。

本発明（請求項７）は、請求項１乃至３のいずれか1項に記載の資源予約装置を構成する各手段としてコンピュータを機能させるための資源予約プログラムである。

上記のように本発明によれば、既存のアプリケーションを動作させるためのクライアントからの要求メッセージの内容に基づいて、同アプリケーションを動作させるための計算機資源やストレージ資源、ネットワーク資源を予約するための要求メッセージの内容を容易に生成することができる。

さらに、予約可能な資源群を抽出し、その資源群の中から予約する資源を選択するため、高い予約成功確率を維持できる。

また、予約できない資源があった場合に、サービスを変更することで、資源予約メッセージ受信時における各資源の配置モデルに制限されて資源予約に失敗するケースを削減できる。

本発明の第１の実施の形態における資源予約装置の構成図である。本発明の第１の実施の形態における各データベース管理棒の管理方法の例である。本発明の第１の実施の形態における動作のフローチャートである。本発明の第１の実施の形態におけるコア部と各データベース管理部との通信方法の一例（その１）である。本発明の第１の実施の形態におけるコア部と各データベース管理部との通信方法の一例（その２）である。本発明の第１の実施の形態におけるコア部と各データベース管理部との通信方法の一例（その３）である。本発明の第１の実施の形態におけるコア部と各データベース管理部との通信方法の一例（その４）である。本発明の第１の実施の形態におけるデータベース管理部と管理対象のドメイン、及びドメインの関係である。本発明の第１の実施の形態におけるデータベース管理部と管理対象のドメイン、及びドメイン間野関係である。本発明の第１の実施の形態におけるドメインとそのドメインを管理するサービスデータベース管理部との対応テーブルの一例である。本発明の第１の実施の形態におけるドメイン間や各ドメインと外部ネットワークとの間のエンドポイントの対応テーブルの一例である。本発明の第１の実施の形態におけるサービスデータベース管理部が保持するサービス確認ステップに関するサービスと提供されるオブジェクトやコネクションとの関係を示すテーブルである。本発明の第１の実施の形態におけるサービスデータベース管理部が保持するユーザから提供されない場合に補完もされないオブジェクトやコネクションである。本発明の第１の実施の形態におけるサービスデータベース管理部が保持するサービスと補完対象となる可能性があるオブジェクトやコネクションの関係のテーブルである。本発明の第１の実施の形態におけるユーザから提供されながら補完対象となる可能性があるオブジェクトやコネクションのテーブルである。本発明の第１の実施の形態におけるサービスデータベース管理部が保持するサービスと計算機オブジェクトごとの計算機資源の所要台数の対応テーブルの例である。本発明の第１の実施の形態におけるサービスと各計算機資源に求められる特徴の対応テーブルの例である。本発明の第１の実施の形態におけるサービスとストレージオブジェクト毎のストレージ資源の所要台数の対応テーブルの例である。本発明の第１の実施の形態におけるサービスデータベース管理部が保持するサービスと各ストレージ資源に求められる特徴の対応テーブルの例である。本発明の第１の実施の形態におけるサービスデータベース管理部が保持するサービスとコネクション毎のエレメントの所要特徴の対応テーブルの例である。本発明の第１の実施の形態におけるコネクションの資源予約の必要性を判断する方法の例である。本発明の第１の実施の形態におけるサービス確認ステップの一例である。本発明の第１の実施の形態におけるメソッドによってサービスや性能保証の種別を選択する方法の一例である。本発明の第１の実施の形態におけるインタフェースによってサービスや性能保証の種別を選択する方法の一例である。本発明の第１の実施の形態における通信メッセージ内のあるフィールドにあるパラメータの値によってサービスや性能保証の種別を選択する方法の一例である。本発明の第１の実施の形態におけるサービスデータベース管理部が保持するアプリケーション種別に基づいて判断するためのテーブルの一例である。本発明の第１の実施の形態におけるデータ種別に基づいて判断するためのテーブルの一例である。本発明の第１の実施の形態におけるアプリケーション種別とデータ種別の組み合わせに基づいて判断するためのテーブルの一例である。本発明の第１の実施の形態におけるサービスや性能保証種別に基づいて判断するためのテーブルの一例である。本発明の第１の実施の形態におけるオブジェクト変更ステップの詳細な動作のフローチャートである。本発明の第１の実施の形態における各オブジェクト編集ステップにおける動作の例である。本発明の第１の実施の形態におけるユーザデータベース管理部のユーザ情報に基づいて利用可能な計算機を限定する方法の例である。本発明の第１の実施の形態におけるユーザデータベース管理部のユーザ情報に基づいて利用可能な計算機を限定する方法の例である。本発明の第１の実施の形態におけるユーザデータベース管理部のユーザ情報に基づいて最寄のドメインとの間のエンドポイントを限定する方法の例である。本発明の第１の実施の形態におけるデータデータベース管理部のデータの種別と識別子との対応付け方法の例である。本発明の第１の実施の形態におけるデータデータベース管理部のデータ情報に基づいて利用可能な計算機を限定する方法の例である。本発明の第１の実施の形態におけるデータデータベース管理部のデータ情報に基づいて利用可能なストレージを限定する方法の例である。本発明の第１の実施の形態におけるアプリケーションデータベース管理部のアプリケーションの種別と識別子との対応付け方法の例である。本発明の第１の実施の形態におけるアプリケーションデータベース管理部のアプリケーション情報に基づいて利用可能な計算機を限定する方法の例である。本発明の第１の実施の形態におけるアプリケーションデータベース管理のアプリケーション情報に基づいて利用可能なストレージを限定する方法の例である。本発明の第１の実施の形態における計算機データベース管理部の計算機資源と該計算機資源のエンドポイントの対応テーブルである。本発明の第１の実施の形態におけるストレージ資源と該ストレージ資源のエンドポイントの対応テーブルである。本発明の第１の実施の形態におけるコネクション編集ステップにおける動作の例である。本発明の第1の実施の形態におけるコネクション群計算の例（その１）である。特許文献２に基づくマルチドメインにわたるコネクション群の探索方法の例である。本発明の第1の実施の形態におけるコネクション群計算の例（その２）である。本発明の第1の実施の形態におけるコネクション群計算の例（その３）である。本発明の第1の実施の形態におけるコネクション群計算の例（その４）である。本発明の第１の実施の形態におけるサービスデータベース管理部が保持するサービスを実現するオブジェクト群とコネクション群の組み合わせパターンである。本発明の第１の実施の形態におけるパターンと利用料金の対応テーブルである。本発明の第１の実施の形態におけるサービスデータベース管理部が保持するｐターンとしよう頻度の対応テーブルである。本発明の第１の実施の形態におけるサービスデータベース管理部が保持するパターンと消費電力の対応テーブルである。本発明の第１の実施の形態におけるサービスデータベース管理部が保持するパターンと稼働率の対応テーブルである。本発明の第２の実施の形態における全体構成のイメージである。本発明の第２の実施の形態におけるＴＶ会議サービスを要求されるばあいのオブジェクトとコネクションの編集例（編集前）である。本発明の第２の実施の形態におけるＴＶ会議のサービスを要求される場合のオブジェクトとコネクションの編集例（編集後のイメージ）である。本発明の第２の実施の形態における資源予約の候補の例（その１）である。本発明の第２の実施の形態における資源予約の候補の例（その２）である。本発明の第２の実施の形態における資源予約の候補の例（その３）である。本発明の第３の実施の形態における全体構成のイメージである。本発明の第３の実施の形態におけるファイルダウンロードのサービスの場合のオブジェクトとコネクションの編集例（編集前）である。本発明の第３の実施の形態におけるファイルダウンロードのサービスの倍あのオブジェクトとコネクションの編集例（編集後のイメージ）である。本発明の第３の実施の形態における資源予約の候補の例（その１）である。本発明の第３の実施の形態における資源予約の候補の例（その２）である。本発明の第４の実施の形態におけるサービスシナリオ変更ステップのフローチャートである。本発明の第４の実施の形態におけるドメインの構成例である。本発明の第４の実施の形態における映像配信の場合のオブジェクトとコネクションの編集例（編集前）である。本発明の第４の実施の形態における映像配信の場合のオブジェクトとコネクションの編集例（編集後のイメージ）である。本発明の第４の実施の形態における映像配信の場合のオブジェクトとコネクションの編集例（編集後のイメージ）である。本発明の第４の実施の形態におけるサービスシナリオ変更の候補の例（その１）（変更前）である。本発明の第４の実施の形態におけるサービスシナリオ変更の候補の例（その１）（変更後）である。本発明の第４の実施の形態におけるサービスシナリオ変更の候補の例（その２）（変更前）である。本発明の第４の実施の形態におけるサービスシナリオ変更の候補の例（その２）（変更後）である。本発明の第４の実施の形態におけるサービスシナリオ変更の候補の例（その１）（変更に合せて全体サービスの設計）である。本発明の第４の実施の形態におけるサービスシナリオ変更の候補の例（その２）（変更に合せて全体サービスの設計）である。

以下、図面と共に本発明の実施の形態を説明する。

図１は、本発明の第1の実施の形態における資源予約装置の構成を示す。

資源予約装置１００は、コア部１１０、サービスデータベース管理部１２０、サービス確認部１３０、オブジェクト・コネクション解析部１４０、オブジェクト変更部１５０、コネクション変更部１６０から構成され、コア部１１０は、ユーザデータベース管理部１０、データデータベース管理部２０、アプリケーションデータベース管理部３０、計算機データベース管理部４０、ストレージデータベース管理部５０、ネットワークデータベース管理部６０に接続されている。図１では、各データベース管理部１０〜６０とコア部１１０とが直接接続されている例を示しているが、ネットワークを介して接続されていてもよい。

基本的に、サービスデータベース管理部１２０は、図３のように各種データベース管理部１０〜６０と、それらのデータベース管理部へアクセスをするためのIPアドレスやポート番号などのアクセス方法の対応テーブルを記憶している必要がある。但し、サービスデータベース管理部１２０は、コア部１１０がネットワークを介して通信する場合、コア部１１０を実現するソフトウェアのソースコード、もしくはソフトウェアの設定データに予めサービスデータベース管理部１２０の宛先を記入しておく必要がある。

資源予約装置１００は、クライアント装置（図示せず）からの資源予約メッセージに応じて前記の各データベース管理部１０〜６０の一部もしくは全部とメッセージを交換し、所要のアプリケーション資源と、データ資源と、計算機資源と、ストレージ資源と、ノード資源と、それらの間を結ぶ機能を有する通信路資源と、を予約する機能を有する。

資源予約メッセージは、所要のアプリケーションと、データと、計算機と、ストレージと、ノードと、についてそれぞれを表現するオブジェクトと、オブジェクト間のそれぞれの通信路を表現するコネクションを含む。

オブジェクトは、前記資源予約メッセージ内で交換される他のオブジェクト群との間で識別されるための識別子、オブジェクトを構成する資源の種別、その資源を特定する識別子、その資源の使用時間、その資源の性能を示す特徴、およびそのオブジェクトの個数、についての一部もしくは全部の情報を有する。

コネクションは、コネクションの端点、コネクションを構成する資源を特定する識別子、資源の使用時間、その資源の性能を示す特徴、についての一部もしくは全部の情報を有する。

ユーザデータベース管理部１０は、ユーザの識別子や所在を管理するとともに、資源予約装置１００からの指示に応じてユーザが最寄りのネットワークエッジにアクセスするエンドポイント、使用可能な計算機やストレージ、ネットワークの制約条件、もしくはそれらの一部を探索して応答する機能を有する。

データデータベース管理部２０は、データ資源の種別、識別子、所在、使用可能な時間の一部もしくは全部を管理するとともに、資源予約装置１００からの指示に応じて使用可能なデータの識別子や使用可能な時間、もしくはそれらの一部を探索して応答する機能を有する。

アプリケーションデータベース管理部３０は、アプリケーション資源の種別、識別子、所在、使用可能な時間の一部もしくは全部を管理し、資源予約装置１００からの指示に応じて使用可能なアプリケーションの識別子や使用可能な時間、もしくはそれらの一部を探索して応答する機能を有する。

計算機データベース管理部４０は、計算機資源の種別、識別子、所在、使用可能な時間の一部もしくは全部を管理し、資源予約装置１００からの指示に応じて使用可能な計算機資源の識別子や使用可能な時間、もしくはそれらの一部を探索して応答する機能を有する。

ストレージデータベース管理部５０は、ストレージ資源の種別、識別子、所在、使用可能な時間の一部もしくは全部を管理し、資源予約装置１００からの指示に応じて使用可能なストレージ資源の識別子や使用可能な時間、もしくはそれらの一部を探索して応答する機能を有する。

ネットワークデータベース管理部６０は、ノードや通信路のネットワーク資源の種別、識別子、所在、使用可能な時間の一部もしくは全部を管理し、資源予約装置１００からの指示に応じて使用可能なネットワーク資源の識別子や使用可能な時間、もしくはそれらの一部を探索して応答する機能を有する。

上記の構成における資源予約方法の流れ概要を下記に示す。

図３は、本発明の第１の実施の形態における概要動作のフローチャートである。

ステップ１１０）コア部１１０は、クライアントと資源予約メッセージを交換する（資源予約メッセージ交換ステップ）。

ステップ１２０）サービス確認部１３０は、資源予約メッセージに基づいて、サービスデータベース管理部１２０を参照して、サービスの内容と、性能保証の種別と、サービスのために必要となるオブジェクトとコネクションと、アプリケーションとデータの配置方法と、図21で示されるネットワークインフラ（基盤構造）条件に基づくコネクションの資源予約の必要性と、の一部もしくは全部について決定する（サービス確認ステップ）。

ステップ１３０) オブジェクト・コネクション解析部１４０が、資源予約メッセージを通じ、クライアントから提供されたオブジェクト群とコネクション群の存在や内容を確認する（オブジェクト・コネクション解析ステップ）。

ステップ１４０）オブジェクト変更部１５０が、サービス確認ステップ（ステップ１２０）とオブジェクト・コネクション解析ステップ（ステップ１３０）の結果を通じ、欠損しているオブジェクトを生成し、尚且つ各データベース管理部１０〜６０とのデータ交換を通じてオブジェクトの内容を補完し、サービスデータベース管理部１２０に格納する。オブジェクト変更部１５０は、コア部１１０を介して各データベース管理部１０〜６０と通信する（オブジェクト変更ステップ）。

ステップ１５０）コネクション変更部１６０が、サービス確認ステップ（ステップ１２０）とオブジェクト・コネクション解析ステップ（ステップ１３０）とオブジェクト変更ステップ（ステップ１４０）との結果を通じ、欠損しているコネクションを生成し、尚且つネットワークデータベース管理部６とのデータ交換を通じてコネクションの内容を補完し、サービスデータベース管理部１２０に格納する。コネクション変更部１６０はコア部１１０を介して各データベース管理部１０〜６０と通信する（コネクション変更ステップ）。

ステップ１６０）コア部１１０が、サービスデータベース管理部１２０に格納されている探索されたオブジェクト群とコネクション群の組合せから成るサービスパターンの中から実際に資源予約するひとつのサービスパターンを選択し、選択されたオブジェクトやコネクションを構成する資源を管理しているそれぞれのデータベース管理部１０〜６０と連携して資源予約を実行する（資源予約ステップ）。

以下、詳細に説明する。

本実施の形態における資源予約装置１００は、非特許文献３〜非特許文献９までに示されるグリッド・リソース・スケジューラを機能拡張したものである。また本実施の形態における計算機データベース管理部４は、非特許文献３〜非特許文献９までに示されるコンピュータ・リソース・マネージャと同等のものであり、本実施の形態のストレージデータベース管理部５は、非特許文献１０〜非特許文献１２までに示されているストレージ・リソース・マネージャと同等のものである。同様、ネットワークデータベース管理部６は、非特許文献３〜非特許文献９までに示されているネットワーク・リソース・マネージャと同等のものである。

コア部１１０と各データベース管理部１０〜６０とのメッセージシーケンスの例を図４〜図７に示す。メッセージシーケンスは図４〜図７のいずれかでも良い。

図４のシーケンスにおいて、コア部１１０は各データベース管理部１０〜６０とひとつずつ順番に通信でき、コア部１１０からの処理要求メッセージに応じて各データベース管理部１０〜６０は処理応答メッセージを返す。これにより、単純なメッセージ処理を実現できる。

図５において、コア部１１０は複数のデータベース管理部１０〜６０と並列に通信でき、コア部１１０からの処理要求メッセージに応じて各データベース管理部１０〜６０は処理応答メッセージを返す。これにより、図４よりも迅速なメッセージ処理を実現できる。

図６において、コア部１１０は複数のデータベース管理部１０〜６０と並列に通信でき、コア部１１０からの仮処理要求メッセージに応じて各データベース管理部１０〜６０は仮処理応答メッセージを返す。仮処理応答メッセージを受信したコア部１１０は、仮処理応答メッセージの内容に基づいて本処理要求メッセージを送信する。コア部１１０は仮処理応答メッセージの内容に基づいて本処理要求メッセージを送信しないと判断した場合、仮処理中止メッセージを送信する。これにより、図５よりもメッセージ処理の迅速性を失っている一方、２フェーズコミットプロトコルを採用しており、トランザクションのアトミック性を高めることができる。

図７において、図６のメッセージシーケンスに基づき、コア部１１０と各データベース管理部１０〜６０とのメッセージ交換の間にトランザクションマネージャ７０を配置する。トランザクションマネージャ７０は図６においてコア部１１０が実行していた仮処理要求と本処理要求を代行して行う。これにより、図６のコア部１１０と比べ、図７のコア部１１０のメッセージ処理は簡単となり、コア部１１０の実装が容易となる。

クライアントとコア部１１０との間のメッセージシーケンスも図４〜図７のいずれかで良い。

本実施の形態では、非特許文献３〜非特許文献９までを参考にして図６に示されるメッセージシーケンスに基づいて説明する。

各資源を提供するインフラ全体は複数のドメインから構成され、各ドメインは資源種別や、地域別、管理者別などの要因に基づいて分割される。各データベース管理部１０〜６０は、自ドメイン内の資源を管理する。なお、インフラ全体の中で、データデータベース管理部が複数存在してもよく、サービスデータベース管理部１２０や、ユーザデータベース管理部１０、アプリケーションデータベース管理部５０、計算機データベース管理部５０、ストレージデータベース管理部５０、ネットワークデータベース管理部６０も同様である。

資源予約装置１００のサービスデータ管理部１２０では図８や図９に示されるような、データベース管理部１０〜６０と管理対象のドメイン、及びドメイン間の関係を管理する。その管理のため、サービスデータベース管理部１２０では、図１０や図１１に示されるようなテーブルを記憶する。図１０のドメインの識別子とデータベース管理部の識別子からなるテーブルを記憶することにより、資源予約装置１００は各ドメインと、そのドメインを管理するデータベース管理部１０〜６０との対応関係を把握できる。また、各ドメインにどのような資源が管理されているか、ということも把握できる。一方、複数のドメインを横断する通信路を予約する際に通信路はドメイン単位に分割されてドメイン単位のコネクションに基づいて予約されるが、図１１に示すように、サービスデータ管理部１２０において、対象ドメインの識別子、隣接ドメインの識別子、対象ドメインのエンドポイントの識別子、隣接ドメイン側のエンドポイントの識別子からなるテーブルを記憶することにより、コネクションの端点を確定できる。

資源予約メッセージを通じてクライアント装置と交換される情報はオブジェクトとコネクションという単位で分離できる。

オブジェクトの一例を下記に示す。
オブジェクト＜識別子＞｛
＜種別＞
＜個数＞
エレメント｛
＜識別子＞
＜使用時間＞
＜特徴＞
｝
｝
「オブジェクト」の識別子は、例えば数字や文字列などで表現されてもよい。この識別子は、資源予約メッセージを通じて、クライアント装置から資源予約装置に送付されたオブジェクト群やコネクション群の中で特定のオブジェクトを指し示すための値である。それゆえクライアントが指定しなくてもよく、資源予約装置が自動的に付与してもよい。

「種別」は、例えばユーザ、アプリケーション、データ、計算機、ストレージ、ノードである。それぞれのオブジェクトの呼称をユーザオブジェクト、アプリケーションオブジェクト、データオブジェクト、計算機オブジェクト、ストレージオブジェクト、ノードオブジェクトとする。ただし、種別をさらに詳細に分類してもよい。例えばアプリケーションについて、映像配信、(多地点）ビデオ会議、(多地点)音声会議、シンクライアント、ファイルアップロード、ファイルダウンロード、データ編集／データ演算、などのようなアプリケーション名に細分化してもよい。データの詳細な種別は例えばデータ名である。ノードの場合の例は、ルータ、イーサネットスイッチ、ファイヤーウォールである。但し、これら以外の種別が存在してもよい。

「個数は」、オブジェクトで指定された資源を複数欲しい場合に指定される値である。個数は例えば数字で表現されてもよい。クライアントはこの値を指定しなくてもよく、その場合の個数のデフォルトの値は1となる。

本発明の特徴として、クライアントは計算機資源やストレージ資源、ネットワーク資源などのエレメントの識別子や使用時間、特徴を指定する必要はない。なぜならば資源予約装置１００がクライアントの条件に該当する資源や使用時間、特徴を探索するからである。但し、エレメントの識別子はクライアントが明示的に指定してもよい。その場合、資源予約装置１００はクライアントによって指定された識別子に該当する資源を資源予約する必要がある。同様に、エレメントの使用時間はクライアントが明示的に指定してもよい。その場合、資源予約装置１００はクライアントによって指定された使用時間に該当する資源を資源予約する必要がある。同様に、エレメントの特徴はクライアントが明示的に指定してもよい。その場合、資源予約装置１００はクライアントによって指定された特徴を満足する資源を資源予約する必要がある。

エレメントの特徴の例を下記に示す。

アプリケーションの場合の例は、所要の計算機仕様、所要のストレージ仕様、所要のネットワーク仕様、もしくはそれらの一部であってもよい。データの場合もアプリケーションの場合と同様である。計算機の場合の一例は、所要のCPUや、メモリ、ハードディスク、ネットワークインターフェースカード、オペレーティングシステム、マネージメントプロトコルである。例えばCPUをブランド名や型番、もしくは動作周波数やキャッシュサイズで指定してもよい。また、例えばメモリを記憶サイズやデータ転送速度で指定してもよい。同様、ストレージを記憶サイズや、データ転送速度、秒間I/O数、平均シークタイムで指定してもよい。ノードの場合の例は、所要の装置のスイッチング容量やポート数、ポート当たりの伝送速度、ポートの媒体種別、マネージメントプロトコル、もしくはそれらの一部であってもよい。

次にコネクションの一例を下記に示す。
コネクション＜識別子＞｛
エレメント｛
＜コネクションの端点＞
＜上記端点の反対側の端点＞
＜識別子＞
＜使用時間＞
＜特徴＞
｝
｝
コネクションの識別子は例えば数字や文字列などで表現されてもよい。この識別子は、資源予約メッセージを通じて、クライアント装置から資源予約装置１００に送付されたオブジェクト群やコネクション群の中で特定のコネクションを指し示すための値である。それゆえクライアントが指定しなくてもよく、資源予約装置が自動的に付与してもよい。

コネクションの端点、ならびに反対側の端点は図９で示されたエンドポイント、もしくは計算機資源やストレージ資源のエレメントの識別子となる。

本発明の特徴として、クライアントはネットワーク資源のエレメントの識別子や使用時間、コネクションの端点ならびに反対側の端点、特徴を指定する必要はない。なぜならば資源予約装置１００がクライアントの条件に該当する資源や使用時間、コネクションの端点、特徴を探索するからである。但し、エレメントの識別子はクライアントが明示的に指定してもよい。その場合、資源予約装置１００はクライアントによって指定された識別子に該当する資源を資源予約する必要がある。同様に、エレメントの使用時間はクライアントが明示的に指定してもよい。その場合、資源予約装置１００はクライアントによって指定された使用時間に該当する資源を資源予約する必要がある。同様にエレメントのコネクションの端点ならびに反対側の端点はクライアントが明示的に指定してもよい。その場合、資源予約装置１００はクライアントによって指定されたコネクションの端点ならびに反対側の端点に該当する資源を資源予約する必要がある。同様にエレメントの特徴はクライアントが明示的に指定してもよい。その場合、資源予約装置１００はクライアントによって指定された特徴を満足する資源を資源予約する必要がある。

エレメントの特徴の例を下記に示す。

例えば、媒体種別、伝送速度もしくは通信容量、伝搬遅延時間であってもよい。

但し、上記において、オブジェクトやコネクションというものは資源予約メッセージの中で情報を分類してまとめるための概念であり、明示的にオブジェクトやコネクションというものを作成する必要はない。

サービスデータベース管理部１２０は、図１２、図１３、図１４、図１５、図１６、図１７、図１８、図１９、および図２０に示される情報を記憶する。図１２はサービス確認ステップ（ステップ１２０）に関するサービスと提供されるオブジェクトやコネクションとの関係を示すテーブルを示す。図１３と図１４はそれぞれ、ユーザから提供されない場合に補完もされないオブジェクトやコネクションの関係図と、サービスと補完対象となる可能性があるオブジェクトやコネクションの関係と、を示す。また、図１５はユーザから提供されながら補助対象となる可能性があるオブジェクトやコネクションの関係を示すテーブルである。図１６はサービスと計算機オブジェクト毎の計算機の所要台数の対応表の例であり、図１７はサービスと各計算機資源に求められる特徴の対応を示すテーブルの例である。また、図１８はサービスとストレージオブジェクト毎のストレージの所要台数の対応を示すテーブルの例であり、図１９はサービスと各ストレージ資源に求められる特徴の対応を示すテーブルの例である。

＜資源予約メッセージ交換ステップ（ステップ１１０）＞
クライアントが所要のサービスを実現できるように資源予約メッセージを送信する際、資源予約メッセージは図１２と図１３の内容を満足するように所要サービスに対応したオブジェクトやコネクションを含む必要がある。

本発明の資源予約装置１００は、クライアントの所望サービスに基づいて図１４に示されるオブジェクトやコネクションを自動的に生成する。各サービスのすべてのオブジェクトとコネクションは図１２と図１４とによって示す通りである。

また、本発明の資源予約装置１００は、クライアントの所望サービスと、図１６、図１７、図１８、図１９、及び図２０の内容に基づいてオブジェクトの個数や、オブジェクトやコネクションのエレメント部分の特徴を自動的に補完できる。

本発明では、オブジェクトやコネクションを利用した資源予約を通じ、サービスの性能保証を図っている。

性能保証の形態を下記に示す。
種別１：計算機
種別２：ストレージ
種別３：ネットワーク（＝コネクション＋ノード）
種別４：計算機とストレージ
種別５：計算機とネットワーク（＝コネクション＋ノード）
種別６：ストレージとネットワーク（＝コネクション＋ノード）
種別７：計算機とストレージとネットワーク（＝コネクション＋ノード）
種別8：なし（どの資源も性能保証をしない）
しかしながら、図２１に示されるとおり、サービスの種別や性能保証の有無に関わらずコネクションの補完が必要となる場合がある。図２１の判断の分岐条件２に示されるとおり、ネットワークのインフラがコネクション型網である場合、資源予約装置１００は性能保証の要求の有無にかかわらず、コネクションに基づいてネットワーク資源を予約し、通信路を確立する必要がある(ステップ２０１，２０２、Yes)。一方、コネクションレス型網であり、尚且つクライアントから性能保証の要求がない場合、資源予約装置１００はネットワーク資源を予約しない（ステップ２０１,No、２０２,No,２０３、Yes/No）。その場合、性能保証された通信路を確立できないが、オブジェクトに該当する資源と、他の資源との間の通信自体は確立できる。それゆえまず、図２１の判断の分岐条件１で示されるとおりに資源予約装置１００のサービス確認部１３０は、クライアントがコネクションの資源予約の要否を確認する。資源予約装置１００のサービス確認部１３０はクライアントとの間でサービス確認ステップより前、もしくは同時にコネクションの資源予約の要否についてのメッセージを交換する。具体的なメッセージ交換は、図２３や、図２４、図２５を用い、後述する。但し、サービスとして常にコネクションの資源を予約するものとして規定してもよく、その場合は資源予約の要否を確認する必要もない。

図２１の判断の分岐条件２に関し、資源予約装置１００のサービス確認部１３０は、下記の方法のいずれかによってネットワークがコネクション型網であるのか、コネクションレス型網であるのか、というタイプを把握できる。

＜方法１＞
方法１を下記に示す。

図１０のようなサービスデータベース管理部１２０のドメイン関係のデータベースのテーブルについて、各ドメインのタイプも記憶する。

＜方法２＞
方法２を下記に示す。

資源予約装置１００を実現するソフトウェアのソースコードに物理的に記載される場合である。

本発明ではどちらの実現方法でもよい。本実施の形態では方法1に基づいて説明する。

資源予約メッセージを通じたクライアントからコア部１１０へのオブジェクト群やコネクション群の伝達方法を下記に例示する。伝達方法は下記のいずれでもよい。
・伝達方法１：サービス（複数のオブジェクトやコネクション）の単位での交換；
・伝達方法２：オブジェクトやコネクションの単位での交換；
・伝達方法３：オブジェクトやコネクションを構成する情報単位での交換；
上記の伝達方法２を実現するための実装条件としては、交換されるメッセージは、交換された情報がどの資源予約要求の一部であるのか、を識別するための識別子を含む。

また、伝達方法３を実現するための実装条件としては、交換されるメッセージは、交換された情報がどの資源予約要求の一部であるのか、を識別するための識別子や、どのオブジェクトやコネクションの一部であるのか、を識別するための識別子を含む。

上記の内容に基づき、資源予約メッセージ交換ステップ（ステップ１１０）において、クライアント装置とコア部１１０との間で資源予約メッセージの交換を行う。

＜サービス確認ステップ（ステップ１２０）＞
次にサービス確認ステップ（ステップ１２０）において、コア部１１０はサービス確認部１３０と連携してサービスの内容を確認する。図２２はサービス確認ステップ（ステップ１２０）の詳細な流れの一例である。

ステップ１２１）まず、サービス確認部１３０は、クライアントがどのようなサービスや、性能保証を求めているのか、ということを確認する。実現手段は、例えば、図２３に示すメソッドによってサービスや性能保証の種別を選択する方法、図２４に示すインタフェースによってサービスや性能保証の種別を選択する方法、もしくは図２５に示す通信メッセージ内のあるフィールドにあるパラメータの値によってサービスや性能保証の種別を選択する方法のいずれでもよく、また別の手段でもよい。

クライアント装置から資源予約装置１００への資源予約メッセージの交換方法は、例えば下記のような階層構造のインタフェースを介して実現できる。この場合、フィールドのところでオブジェクトやコネクションに該当する情報が記載される。
インタフェース <インタフェース名>｛
メソッド＜メソッド名＞｛
フィールド＜フィールド名＞｛
＜値＞
｝
｝
｝
図２３に示す方法はインタフェース名の違いを利用して実現する例である。一方、図２４はメソッド名の違いを利用して実現する例である。また、図２５では、サービスや性能保証を区分するためのフィールドを設け、そのフィールドのパラメータの値の違いを利用して実現する例である。図２３もしくは図２４の実現手段を採用した資源予約装置１００は、サービス確認部１３０が不要となり、コア部１１０が資源予約メッセージ交換ステップ１１０を行うことによりサービスや性能保証種別を確認する。

上記の実現手段を介し、補完すべきオブジェクトやコネクションを確認できる。

ステップ１２２）所要のアプリケーションとデータを同じ計算機もしくはストレージに集めて実行することの必要性を判断する。判断基準を設定する上での選択肢は下記のいずれでもよく、また下記以外でもよい。
・選択肢１：装置仕様に基づいて判断ならびに確定
・選択肢２：アプリケーション種別に基づいて判断
・選択肢３：データ種別に基づいて判断
・選択肢４：アプリケーション種別とデータ種別の組合せに基づいて判断
・選択肢５：サービス、性能保証の種別、もしくはその両方に基づいて判断
選択肢１の実現方法は、資源予約装置のソフトウェアのソースコードに明記する方法である。もしくはサービスデータベース管理部１２０において、アプリケーションとデータを常に同じ計算機もしくはストレージに集める、もしくは常に分離しておく、ということを識別するための値を記憶しておき、サービス確認部１３０がサービスデータベース管理部１２０を参照することによって確定する方法である。この場合、アプリケーション種別やデータ種別に関係なく、アプリケーションとデータとを同じ計算機もしくはストレージに集める、もしくは分離する、ということを常に実行する。

選択肢２の実現方法は、サービスデータベース管理部１２０が図２６に例示されたアプリケーション種別と必要性の対応テーブルを記憶しておき、サービス確認部１３０が同テーブルを参照することによって確定する方法である。この場合、サービス確認部１３０は、アプリケーション種別に応じて、アプリケーションとデータとを同じ計算機もしくはストレージに集めるという処理を実行する。

選択肢３の実現方法は、サービスデータベース管理部１２０が図２７に例示されたデータ種別と必要性の対応テーブルを記憶しておき、サービス確認部１３０が同テーブルを参照することによって確定する方法である。この場合、サービス確認部１３０は、データ種別に応じて、アプリケーションとデータとを同じ計算機もしくはストレージに集めるという処理を実行する。

選択肢４の実現方法は、サービスデータベース管理部１２０が図２８に例示されたアプリケーション種別とデータ種別と必要性の対応テーブルを記憶しておき、サービス確認部１３０が同テーブルを参照することによって確定する方法である。この場合、サービス確認部１３０は、アプリケーション種別とデータ種別の関係に応じて、アプリケーションとデータとを同じ計算機もしくはストレージに集めるという処理を実行する。

選択肢５の実現方法は、サービスデータベース管理部１２０が図２９に例示されたアプリケーション種別とデータ種別と必要性の対応テーブルを記憶しておき、サービス確認部１３０が同テーブルを参照することによって確定する方法である。この場合、サービス確認部１３０は、アプリケーション種別とデータ種別の関係に応じて、アプリケーションとデータとを同じ計算機もしくはストレージに集めるという処理を実行する。

本実施の形態では選択肢５に基づいて説明する。

ステップ１２３）サービスに関係しない、もしくは性能保証外のオブジェクトやコネクションを指定された場合の対処方法を判断する。すなわち、上記で述べたネットワークがコネクション型ネットワークとコネクションレス型ネットワークのいずれであるのか、ということを判断する。

本発明では上記のサービス確認ステップ１２０のステップ１２２とステップ１２３の処理の順番を入れ替えてもよい。本実施の形態では図２２に従って説明する。

もし、資源予約メッセージに含まれるオブジェクトやコネクションが不足している場合、サービス確認部１３０はサービスを特定できないために次のように動作することを決定する。以下のどちらか一方だけでよい。また、下記動作と異なる動作を実行しても良い。
・選択肢１：クライアントに資源予約失敗を応答し、尚且つ資源予約メッセージを廃棄
・選択肢２：資源予約メッセージを廃棄
また、もし資源予約メッセージの中にサービスに関係しない、もしくは性能保証外のオブジェクトやコネクションが含まれる場合、サービス確認部１３０は次のように動作することを決定する。以下のいずれかだけでよい。また、下記動作と異なる動作を実行しても良い。
・選択肢１：エラーで応答
・選択肢２：該オブジェクトを無視して資源予約
・選択肢３：必要に応じて内容を補完しながら該オブジェクトに従って資源予約
本実施の形態では選択肢１に基づいて説明する。

以上により、所要のサービスを提供するために必要なオブジェクトやコネクションの確認方法を示した。

＜オブジェクト・コネクション解析ステップ（ステップ１３０）＞
次に、オブジェクト・コネクション解析部は資源予約メッセージの交換を通じて提供されるオブジェクト群やコネクション群を確認し、さらにサービス確認ステップの結果に基づいて情報の欠損しているオブジェクトやコネクションを確認する。

本ステップでは、サービス確認ステップにおいて図１２や図１３の内容を確認しており、資源予約メッセージによって交換されると可能性のあるオブジェクト群やコネクション群を確認できている。さらに、図１４や図１５に示されるとおり、補完される可能性あるオブジェクト群とコネクション群も確認できている。
本ステップでは、上記のとおり、資源予約メッセージで交換されるオブジェクト群とコネクション群と、図１２から図１３の差異にもとづき、図１４および図１５にしたがってオブジェクト群とコネクション群の欠損状況を確認できる。

＜オブジェクト変更ステップ（ステップ１４０）＞
次にオブジェクト変更ステップの内容を説明する。

オブジェクト変更ステップでは、図３０に示されるとおり、ユーザオブジェクト編集ステップ（ステップ１４１）と、データオブジェクト編集ステップ（ステップ１４２）と、アプリケーションオブジェクト編集ステップ（ステップ１４３）と、計算機オブジェクト編集ステップ（ステップ１４４）と、ストレージオブジェクト編集ステップ（ステップ１４５）と、ノードオブジェクト編集ステップ（ステップ１４６）と、から成る。ただし、それぞれのオブジェクト編集ステップの順番を入れ替えてもよい。本実施の形態では図３０の内容に従って説明する。

次に各オブジェクト編集ステップ（ステップ１４１〜１４６）は、図３１に示されるとおり、オブジェクト問合せステップ（ステップ３０１，３０２）と、オブジェクト編集ステップと（ステップ３０３，３０４）、によって構成される。各オブジェクト編集ステップ（ステップ１４１〜１４６）では、各オブジェクト問合せステップ（ステップ３０１、３０２）とサービス確認ステップ（ステップ１２０）との結果に基づいてオブジェクトの内容を編集ならびに補完する。各オブジェクト編集ステップ（ステップ３０３、３０４）において、オブジェクト問合せステップ（ステップ３０１，３０２）以降は該当オブジェクトの内容が十分に揃っている場合や、該当するオブジェクト自体がない場合には省略される。また、オブジェクト問合せステップ（ステップ３０１，３０２）で該当オブジェクトの条件を満足する資源が存在しない場合、資源予約処理に失敗したこととなり、資源予約処理が終了される。

下記にオブジェクト編集ステップ（ステップ１４０）の実現方法の例について説明する。

プラットフォーム上では複数のドメインが存在し、尚且つ同じ種別の資源を管理しているドメインも複数存在する可能性がある。それゆえ、オブジェクト変更部１５０はオブジェクト問合せステップ（ステップ３０２）を通じて問い合わせるドメインを適切に選択する必要がある。下記では、オブジェクト変更部１５０が問合せ先のドメイン、ならびにそのデータベース管理部１０〜６０を選択する方法の例を示す。選択方法は下記のいずれでもよく、また下記以外の方法でもよい。下記の"N"とは数字であり、資源予約装置１００に設定される。
・選択肢１：対象の種別の資源を管理している全ドメインを選択；
・選択肢２：対象の種別の資源を管理し、尚且つユーザとオブジェクト群との間の中継ドメイン数が少なくなるようなドメインを優先的にＮ個選択；
・選択肢３：対象の種別の資源を管理し、尚且つオブジェクト間の中継ドメイン数が少なくなるようなドメインを優先的にＮ個選択；
・選択肢４：対象の種別の資源を管理し、尚且つユーザ及び各オブジェクトの間の中継ドメイン数が少なくなるようなドメインを優先的にＮ個選択；
・選択肢５：対象の種別の資源を管理し、尚且つオブジェクト間の中継ドメイン数が多くなるようなドメインを優先的にＮ個選択；
・選択肢６：対象の種別の資源を管理し、尚且つ利用頻度の高いドメインを優先的にＮ個選択；
・選択肢７：対象の種別の資源を管理し、尚且つ利用頻度の低いドメインを優先的にＮ個選択；
・選択肢８：ランダムに対象の種別の資源を管理しているドメインをＮ個選択；
・選択肢９：上記の選択肢１から選択肢８までのうちの一部の組合せ；
選択肢２は選択肢１と比べ、予約される資源がユーザの近くに集まり易いためにユーザと各資源との間で交換される通信信号の伝搬遅延時間が少なくなり易い。結果的に高性能なサービスを提供しやすい。

選択肢３は選択肢１と比べ、予約される資源同士が近くに集まり易いために資源間で交換される通信信号の伝搬遅延時間が少なくなり易い。結果的に高性能なサービスを提供しやすい。

選択肢４は選択肢２や選択肢３と比べ、予約される資源同士やユーザが近くに集まり易いために各資源の間やユーザと資源の間で交換される通信信号の伝搬遅延時間が少なくなり易い。結果的に高性能なサービスを提供しやすい。

選択肢５は選択肢１と比べ、予約される資源同士が遠くに離れ易いために地震などの天災に対してひとつのサービスにおける全壊を防ぎ易い。結果的に高信頼のサービスを提供しやすい。

選択肢６は選択肢１と比べ、クライアントへの提供サービスを一部のドメインに集中させ易い。結果的にサービスの運用管理が容易となる。

選択肢７は選択肢５と比べ、各サービスが遠くに分散され易いためにサービスプラットフォームの全壊を防ぎ易い。結果的に高信頼のサービスを提供しやすい。

次に、オブジェクト変更部１５０は上記で選択された各ドメインについて対象のオブジェクトを問い合わせる（ステップ３０２）。

該当の種別の資源を管理するドメインが複数存在する場合も考慮すると、オブジェクト変更部１５０から同ドメイン群への問合せ方法は下記の通りである。但し、問合せ方法は下記のいずれでもよく、また下記以外の方法でもよい。
・選択肢１：該当のデータベース管理部群のそれぞれに並列的に問合せ
・選択肢２：該当しているデータベース管理部群のそれぞれに順番に問合せ
本実施の形態では選択肢１に従って説明する。

また、オブジェクト変更部１５０から各ドメインのデータベース管理部１２０への問合せ方法の例を下記に示す。問合せ方法は下記のいずれでもよく、また下記以外の方法でもよい。
・選択肢１：オブジェクト毎に問合せ；
・選択肢２：複数のオブジェクトを一括で、もしくは並列して問合せ；
本実施の形態では選択肢２に従って説明する。

次に、オブジェクト問合せステップ(ステップ３０２)においてオブジェクト変更部１５０からの問合せに応じて該当のデータベース管理部がオブジェクト変更部１５０に応答する。問い合わされたオブジェクトに該当する資源が複数存在する場合を考慮すると、データベース管理部１０〜６０からオブジェクト変更部１５０への応答方法は下記とおりである。ただし、応答方法は下記のいずれでもよく、また下記以外の方法でもよい。下記の"N"とは数字であり、各データベース管理部１０〜６０に設定される。
・選択肢１：ひとつのオブジェクトに対して該当候補のすべてを応答；
・選択肢２：ひとつのオブジェクトに対して該当候補のうちのＮコに限定して応答；
本実施の形態では選択肢１に従って説明する。

また、上記の選択肢２において各データベース管理部１０〜６０が下記のように該当候補を限定する。ただし、限定する方法は下記のいずれでもよく、また下記以外の方法でもよい。
・選択肢１：利用料金が低い候補を優先的に選択；
・選択肢２：使用頻度の高い資源を優先的に選択；
・選択肢３：使用頻度の低い資源を優先的に選択；
・選択肢４：消費電力の低い資源を優先的に選択；
・選択肢５：稼働率の高い資源を優先的に選択；
・選択肢６：ランダム；
本実施の形態では選択肢２に従って説明する。

最後に、オブジェクト問合せステップ（ステップ３０２）においてオブジェクト変更部１５０は各データベース管理部１０〜６０から応答されたオブジェクト候補を限定してもよい。下記に限定方法の例を示す。本発明では下記のいずれでもよい。また下記以外の方法でもよい。下記の"N"とは数字であり、各データベース管理部１０〜６０に設定される。
・選択肢１：限定しない；
・選択肢２：応答された候補のうちのＮコに限定；
本実施の形態では選択肢１に従って説明する。

以上により、オブジェクト変更部１５０は各データベース管理部１０〜６０との連携を通じてオブジェクトに該当する資源候補を探索して選定し、さらに必要に応じて補完できる。

以上で得られた情報に基づき、オブジェクト編集ステップを通じて問い合わされたオブジェクトの内容が補完される。

上記のオブジェクト編集ステップ（ステップ３０４）について、より詳細な例を下記に示す。

第１のステップについて説明する。

オブジェクト変更部１５０がユーザオブジェクトのユーザの識別子に従ってユーザデータベース管理部１０に問い合わせる例であり、同ユーザが使用できる計算機資源と、ストレージ資源についての問合せである。また、同ユーザが最寄りのドメインにアクセスするためのエンドポイントについての問合せである。ユーザデータベース管理部１０は、例えば、図３２や、図３３、図３４に示されるテーブルを記憶している。コア部１１０からの問合せに対し、ユーザデータベース管理部１０は、そのユーザが使用することを許可されている計算機資源や、ストレージ資源の候補、エンドポイントを応答する。その結果、オブジェクト変更部１５０は使用可能な計算機資源やストレージ資源、エンドポイントを確認できる。もし、サービスプラットフォームにおいてユーザ毎にネットワーク資源を限定して提供する場合、本実施の形態のようにユーザデータベース管理部１０はユーザ識別子とネットワーク資源との対応テーブルを記憶しておく。

第２のステップについて説明する。

オブジェクト変更部１５０がデータ種別に従ってデータデータベース管理部２０に問い合わせる例であり、指定されたデータ種別のデータを保有する計算機資源やストレージ資源についての問合せである。データデータベース管理部２０は、例えば、図３５、図３６、及び図３７に示されるテーブルを記憶している。オブジェクト変更部１５０からの問合せに対し、データデータベース管理部２０は、図３５のテーブルに従ってデータの識別子を限定する。さらにデータの識別子と図３６及び図３７の各テーブルに基づいて指定のデータを保有する計算機資源やストレージ資源を限定する。但し、データ名の同じデータがコピーなどの操作を通じて複数存在している可能性があり、該当のデータの識別子は複数存在する可能性がある。それゆえ、該当の識別子のデータを保有する計算機資源やストレージ資源も複数存在する可能性がある。

第３のステップについて説明する。

オブジェクト変更部１５０がアプリケーション種別に従ってアプリケーションデータベース管理部３０に問い合わせる例であり、指定されたアプリケーション種別のアプリケーションを保有する計算機資源やストレージ資源についての問合せである。アプリケーションデータベース管理部３０は、例えば、図３８、図３９、及び図４０に示されるテーブルを記憶している。オブジェクト変更部１５０からの問合せに対し、アプリケーションデータベース管理部３０は図３８のテーブルに従ってアプリケーションの識別子を限定する。さらにアプリケーションの識別子と図３９及び図４０の各テーブルに基づいて指定のアプリケーションを保有する計算機資源やストレージ資源を限定する。但し、アプリケーション名の同じアプリケーションがコピーなどの操作を通じて複数存在している可能性があり、該当のアプリケーションの識別子は複数存在する可能性がある。それゆえ、該当の識別子のアプリケーションを保有する計算機資源やストレージ資源も複数存在する可能性がある。

上記の第１、第２、及び第３のステップに基づいて使用できる計算機資源や、ストレージ資源、エンドポイントを限定する例を示した。

上記に基づき、クライアントの要求に該当する計算機資源の識別子をさらに限定する例は、非特許文献３、非特許文献４、非特許文献５、非特許文献６、非特許文献７、非特許文献８に示されている。この場合、オブジェクト変更部１５０は、計算機データベース管理部４０に対してResourceQueryもしくはAvailableResourceQueryというメソッドを通じ、利用可能な計算機資源を限定する。また、計算機データベース管理部４０は図４１のような計算機資源と該計算機資源のエンドポイントの対応テーブルを記憶しており、同計算機資源とコネクションとを関連付けるためのエンドポイントを応答する。

同様、クライアントの要求に該当するストレージ資源の識別子をさらに限定する例は、非特許文献１１、非特許文献１２に示されている。この場合、オブジェクト変更部１５０はストレージデータベース管理部５０に対して、ResourceQueryもしくはAvailableResourceQueryというメソッドを通じ、利用可能なストレージ資源を限定する。また、ストレージデータベース管理部５０は、図４２のようなストレージ資源と該ストレージ資源のエンドポイントの対応テーブルを記憶しており、同ストレージ資源とコネクションとを関連付けるためのエンドポイントを応答する。

次に、クライアントの要求に該当するノード資源の識別子を限定する例は、非特許文献３、非特許文献４、非特許文献５、非特許文献６、非特許文献７、非特許文献８、非特許文献９、特許文献１、特許文献２、特許文献３に示されている。この場合、オブジェクト変更部１５０はネットワークデータベース管理部６０に対してResourceQueryもしくはAvailableResourceQueryというメソッドを通じ、利用可能なノード資源を限定する。

以上により、クライアントの要求に該当するデータ資源や、アプリケーション資源、計算機資源、ストレージ資源、ノード資源を限定できる。但しこの時点において、該当する資源が複数存在している可能性がある。その場合、後述される資源予約ステップにおいて該当の各種資源の識別子や使用時間をひとつに特定する。

＜コネクション変更ステップ（ステップ１５０）＞
次に、コネクション変更部１６０における、図４３の例に従ってコネクション変更ステップ（ステップ１５０）を説明する。

コネクション変更ステップ（ステップ１５０）は、コネクション問合せステップ(ステップ１５１，１５２)とコネクション編集ステップ（ステップ１５３，１５４）からなる。上記のオブジェクト変更ステップ（ステップ１４０）を通じ、各コネクション候補のエンドポイントが既に明らかになっている。そこで、各コネクション候補のエレメント部分に求まったエンドポイントを補完する。

例えば、図４４に示されるとおり、計算機ドメイン１においてオブジェクト候補１が存在し、同様に計算機ドメイン２においてオブジェクト候補２、および計算機ドメイン３においてオブジェクト候補３がそれぞれ存在する例を考える。この例において、クライアントから要求されたサービスを実現する方法として、次の３パターンを考える。パターン１は、オブジェクト候補１とオブジェクト候補２とそれらの間を結ぶコネクション群である。パターン２は、オブジェクト候補２とオブジェクト候補３とそれらの間を結ぶコネクション群である。パターン３は、オブジェクト候補１とオブジェクト候補３とそれらの間を結ぶコネクション群である。

本実施の形態では、コネクション群を計算する例としてパターン１に注目して説明する。コネクション変更部１６０は、オブジェクト候補１に基づくコネクション候補のエンドポイントを決定する。同様、オブジェクト候補２に基づくコネクション候補のエンドポイントを決定する。次にコネクション変更部１６０は、特許文献２に基づく経路探索技術により、ドメイン間の接続関係を計算する。特許文献２の経路探索技術は、始点から終点までのすべての経路を探索することができる。特許文献２に示される経路探索技術の簡略図を図４５に示す。これにより、図４６や、図４７、図４８に示されるとおり、コネクション候補１からコネクション候補６までを求めることができ、同時に各コネクションのエンドポイントを求めることができる。同様、パターン２とパターン３についても同じことを実行することにより、エンドポイントの定まったコネクション候補群を求めることができる。これにより、コネクション変更部１６０はコネクション候補と、それらについて問い合わせるべき各ネットワークデータベース管理部６０を明らかにできる。但しコネクション変更部１６０は、特許文献２と異なる経路探索技術を用いても良い。

次に、非特許文献３、非特許文献４、非特許文献５、非特許文献６、非特許文献７、非特許文献８、非特許文献９、特許文献1、特許文献２、特許文献３の内容に従ってコネクションの条件を満足するネットワーク資源についてネットワークデータベース管理部６０に問い合わせる。この場合、コネクション変更部１６０はネットワークデータベース管理部６０に対してResourceQueryもしくはAvailableResourceQueryというメソッドを通じ、利用可能な通信路資源を限定する。

上記のコネクション問合せステップ（ステップ１５２）において、エンドポイントに基づいてコネクション変更部１６０から問い合わせるネットワークデータベース管理部６０は決定している。

次に、コネクション変更部１６０は各コネクションについて該当のドメインに問い合わせる。

コネクションの数が複数存在し、尚且つ複数のドメインにわたって存在する場合、コネクション変更部１６０は次のいずれかの方法に従って問い合わせる。本実施の形態では非特許文献３から非特許文献９までに倣って、以下の選択肢１に従って説明する。
・選択肢１：該当のデータベース管理部群のそれぞれに並列的に問合せ；
・選択肢２：該当しているデータベース管理部群のそれぞれに順番に問合せ；
また、ひとつのドメインに複数のコネクションが存在する可能性がある。それゆえ、コネクション変更部１６０から各データベース管理部１０〜６０への問合せ方法は一般的に下記のいずれかに従って実現される。但し、下記以外の方法でもよい。
・選択肢１：コネクション毎に問合せ；
・選択肢２：複数のコネクションを一括で、もしくは並列して問合せ；
本実施の形態では、上記の選択肢２に従って説明する。

次に、コネクション問合せステップにおいてコネクション変更部１６０からの問合せに応じて該当のデータベース管理部がコネクション変更部１６０に応答する。問い合わされたコネクションに該当する通信路資源が複数存在する場合を考慮すると、データベース管理部１０〜６０からコネクション変更部１６０への応答方法は下記とおりである。但し、応答方法は下記のいずれでもよく、また下記以外の方法でもよい。下記の"N"とは数字であり、各データベース管理部１０〜６０に設定される。
・選択肢１：ひとつのコネクションに対して該当候補のすべてを応答；
・選択肢２：ひとつのコネクションに対して該当候補のうちのＮ個に限定して応答；
本実施の形態では上記の選択肢１に従って説明する。

また、上記の選択肢２において各データベース管理部１０〜６０が下記のように該当候補を限定する。但し、限定する方法は下記のいずれでもよく、また下記以外の方法でもよい。
・選択肢１：利用料金が低い候補を優先的に選択
・選択肢２：使用頻度の高い資源を優先的に選択
・選択肢３：使用頻度の低い資源を優先的に選択
・選択肢４：消費電力の低い資源を優先的に選択
・選択肢５：稼働率の高い資源を優先的に選択
・選択肢６：ランダム
本実施の形態では選択肢２に従って説明する。

最後に、コネクション問合せステップにおいてコネクション変更部１５０は各データベース管理部１０〜６０から応答されたコネクション候補を限定してもよい。下記に限定方法の例を示す。本発明では下記のいずれでもよい。また下記以外の方法でもよい。下記の"N"とは数字であり、各データベース管理部１０〜６０に設定される。
・選択肢１：限定しない
・選択肢２：応答された候補のうちのＮ個に限定
本実施の形態では選択肢１に従って説明する。

以上により、クライアントの要求に該当する通信路資源を限定できる（ステップ１５４）。但し、この時点において、該当する資源が複数存在している可能性がある。その場合、後述される資源予約ステップ（ステップ１６０）において該当の各種資源の識別子や使用時間をひとつに特定する。

＜資源予約ステップ（ステップ１６０）＞
最後に、図３の資源予約ステップ（ステップ１６０）について説明する。

上記で述べたオブジェクト変更ステップ(ステップ１４０)とコネクション変更ステップ（ステップ１５０）を通じ、それぞれのオブジェクトやコネクションについて1つ以上の資源候補が探索され、サービスデータベース管理部１２０に例えば、図４９に示されるようなテーブルがされる。資源予約ステップ（ステップ１６０）では、コア部１１０がサービスデータデータベース管理部１２０の図４９のテーブルを参照し、適当なパターンを選択する。次に、コア部１１０は選択されたパターンに基づき、エレメントの識別子まで補完されたオブジェクトやコネクションを使って各データベース管理部と連携して資源を予約する。

上記において、1つ以上のパターンの中から適当なものを選択する方法を下記に示す。但し、下記のいずれでもよく、また下記以外でもよい。
・選択肢１：トータルでの利用料金が低いパターンを優先的に選択；
・選択肢２：トータルでの使用頻度の高いパターンを優先的に選択；
・選択肢３：トータルでの使用頻度の低いパターンを優先的に選択；
・選択肢４：トータルでの消費電力の低いパターンを優先的に選択；
・選択肢５：トータルでの稼働率の高いパターンを優先的に選択；
・選択肢６：コネクション群だけについて利用料金が低いパターンを優先的に選択；
・選択肢７：コネクション群だけについて使用頻度の高いパターンを優先的に選択；
・選択肢８：コネクション群だけについて使用頻度の低いパターンを優先的に選択；
・選択肢９：コネクション群だけについて消費電力の低いパターンを優先的に選択；
・選択肢１０：コネクション群だけについて稼働率の高いパターンを優先的に選択；
・選択肢１１：オブジェクト群だけについて利用料金が低いパターンを優先的に選択；
・選択肢１２：オブジェクト群だけについて使用頻度の高いパターンを優先的に選択；
・選択肢１３：オブジェクト群だけについて使用頻度の低いパターンを優先的に選択；
・選択肢１４：オブジェクト群だけについて消費電力の低いパターンを優先的に選択；
・選択肢１５：オブジェクト群だけについて稼働率の高いパターンを優先的に選択；
・選択肢１６：パターンの識別子の若番から優先的に選択；
・選択肢１７：パターンの識別子の老番から優先的に選択；
・選択肢１８：ランダム；
・選択枝１９：上記のうちの一部の組合せ；
選択肢１を実現する場合、サービスデータベース管理部１２０は、図５０に示されるようなテーブルを保有し、尚且つコア部１２０は同テーブルを参照して適当なパターンを選択する。

上記の選択肢２や選択肢３を実現する場合、サービスデータベース管理部１２０は図５１に示されるようなテーブルを保有し、尚且つコア部１１０は、同テーブルを参照して適当なパターンを選択する。

上記の選択肢４を実現する場合、サービスデータベース管理部１２０は図５２に示されるようなテーブルを保有し、尚且つコア部１１０同テーブルを参照して適当なパターンを選択する。

上記の選択肢５を実現する場合、サービスデータベース管理部１２０は図５３に示されるようなテーブルを保有し、尚且つコア部１１０は同テーブルを参照して適当なパターンを選択する。

それ以外の選択肢の場合、上記のデータベースのいずれかを参照することで実現できる。

以上により、請求項1に対応する資源予約方法を実現できる。

これにより、既存のアプリケーションを動作させるための要求メッセージの内容にもとづき、同アプリケーションを動作させるための計算機資源や、ストレージ資源、ネットワーク資源を予約するための要求メッセージの内容をできるだけ自動的に生成できる。

［第２の実施の形態］
本実施の形態は、第１の実施の形態に基づいた、TV会議サービスの例であり、図５４に示されるドメイン構成を例として説明する。便宜上、計算機ドメイン"1"に計算機データベース管理部"1"とアプリケーションデータベース管理部"1"が配備され、計算機ドメイン"２"に計算機データベース管理部"２"とアプリケーションデータベース管理部"２"が配備されるモデルとする。同様、ネットワークドメイン"X"にはネットワークデータベース管理部"X"が配備されるモデルとする。本実施の形態において"X"は数字である。

クライアントは、図５５に示されるようなユーザ"1"についてのユーザオブジェクト"1"と、ユーザ"2"についてのユーザオブジェクト"2"と、ユーザ"3"についてのユーザオブジェクト"3"と、種別が「TV会議アプリケーション」のアプリケーションオブジェクトと、を含む資源予約メッセージをコア部１１０と交換する。

サービス確認ステップ（ステップ１２０）を通じて、サービス確認部１３０は図５６に示されるようなオブジェクトやコネクションが必要であると判断する。同様に、オブジェクト・コネクション解析ステップ（ステップ１３０）を通じて、オブジェクト・コネクション解析部１４０は計算機オブジェクトと、同計算機資源と各ユーザの間を結ぶコネクションが不足していると判断する。

まず、オブジェクト変更部１５０は、ユーザデータベース管理部１０との連携により、ユーザ"1"のエンドポイントと、ユーザ"2"のエンドポイントと、ユーザ"3"のエンドポイントと、を確認する。

次に、オブジェクト変更部１５０は、対象のアプリケーションの所在を確認するために計算機ドメイン"１"に存在するアプリケーションデータベース管理部３０_１と、計算機ドメイン"2"に存在するアプリケーションデータベース管理部３０_２と、に問い合わせる。

その結果、オブジェクト変更部１５０は各計算機ドメインに対象のアプリケーションが存在することを確認すると共に、同アプリケーションを保有する計算機資源の識別子も確認する。本実施の形態では計算機"1"と計算機"2"が対象のアプリケーションを保有している。

次に、コネクション変更部１６０は、ユーザの最寄りのエンドポイントや、ドメイン間の境界のエンドポイントに基づき、コネクションを補完する。

以上により、図５７に示される組合せパターンと、図５８に示される組合せパターンと、及び図５９に示される組合せパターンと、が抽出される。

資源予約ステップ（ステップ１６０）において、コア部１１０は上記の３つの内のいずれかを一つ選択して予約する。

［第３の実施の形態］
本実施の形態は、第１の実施の形態に基づいたファイルダウンロードサービスの例であり、図６０に示されるドメイン構成を例として説明する。便宜上、ストレージドメイン"1"にストレージデータベース管理部"1"とアプリケーションデータベース管理部"1"とデータデータベース管理部"1"が配備され、ストレージドメイン"2"にストレージデータベース管理部"2"とアプリケーションデータベース管理部"2"とデータデータベース管理部"2"が配備されるモデルとする。同様、ネットワークドメイン"X"にはネットワークデータベース管理部"X"が配備されるモデルとする。本実施の形態において"X"は数字である。

クライアント装置は、図６１に示されるようなユーザオブジェクトと、種別がファイルダウンロードのアプリケーションオブジェクトと、種別が対象のデータ名のデータオブジェクトを含む資源予約メッセージをコア部１１０と交換する。

サービス確認ステップ（ステップ１２０）において、サービス確認部１３０は図６２に示されるようなオブジェクトやコネクションが必要であると判断する。同様、オブジェクト・コネクション解析ステップ（ステップ１３０）において、オブジェクト・コネクション解析部１４０はストレージオブジェクトと、同ストレージ資源とユーザとの間を結ぶコネクションが不足していると判断する。

まず、オブジェクト変更部１５０は、ユーザデータベース管理部１０との連携により、ユーザのエンドポイントを確認する。

次に、オブジェクト変更部１５０は、対象のデータの所在を確認するためにストレージドメイン"１"に存在するストレージデータベース管理部５０_１と、ストレージドメイン"2"に存在するストレージデータベース管理部５０_２と、ストレージドメイン"3"に存在するストレージデータベース管理部５０_３と、に問い合わせる。

その結果、オブジェクト変更部１５０は各ストレージドメインに対象のデータが存在することを確認するとともに、同データを保有するストレージ資源の識別子も確認する。本実施の形態ではストレージ"1"とストレージ"2"とストレージ"3"が対象のデータを保有している。

次に、オブジェクト変更部１５０は、対象のアプリケーションの所在を確認するためにストレージドメイン"１"に存在するアプリケーションデータベース管理部３０_１と、ストレージドメイン"2"に存在するアプリケーションデータベース管理部３０_２と、ストレージドメイン"3"に存在するアプリケーションデータベース管理部３０_３と、に問い合わせる。

その結果、オブジェクト変更部１５０はストレージ"2"とストレージ"3"に対象のアプリケーションが存在することを確認すると共に、同アプリケーションを保有するストレージ資源の識別子も確認する。本実施の形態ではストレージ"2"とストレージ"3"が対象のアプリケーションを保有している。

以上により、図６３に示される組合せパターンと、図６４に示される組合せパターンと、が抽出される。

資源予約ステップ（ステップ１６０）において、コア部１１０は上記の2つの内のいずれかを一つ選択して予約する。
〔第４の実施の形態〕

本実施の形態は、第１の実施の形態に基づいた映像配信サービスの例であり、請求項２請求項５に相当する。

本実施の形態では、オブジェクト変更ステップ（ステップ１４０）において、予約可能なオブジェクト候補がない場合にオブジェクト変更ステップを再試行するため、コア部１１０がサービスの内容を変更する。サービスの内容を変更したものに基づいて、オブジェクト変更ステップを再試行する。

例えば、所望のアプリケーション資源やデータ資源を保有している全ての計算機資源やストレージ資源が資源予約メッセージの指定された所望の使用時間に予約できないという状況が発生する可能性がある。この時点でオブジェクト変更ステップ（ステップ１４０）は資源予約失敗で終了してしまう。その場合、コア部１１０において、同使用時間に空いている計算機資源やストレージ資源に同アプリケーションや同データをコピーもしくは移動することにより、オブジェクト変更部１５０は、オブジェクト変更ステップにおいて資源予約成功で完了できる。

図６５は、請求項２に対応するサービスシナリオ変更ステップのフローであり、図３のフローと同一動作には同一符号を付与する。本実施の形態では、オブジェクト変更ステップ１４０において、他に予約可能なオブジェクト候補がないと判定された場合に、当該サービスについて他のサーバについて検索した履歴が１回以上あるか否かを判定し（ステップ５１０）、ある場合には資源予約失敗とし、ない場合（他のサーバについて検索を行っていない場合）は、再度オブジェクト変更ステップ１４０を行うものである。

また、図６６は本実施の形態におけるドメイン構成例である。便宜上、計算機ドメイン"1"に計算機データベース管理部"1"とアプリケーションデータベース管理部"1"とデータデータベース管理部"1"が配備され、計算機ドメイン"2"に計算機データベース管理部"2"とアプリケーションデータベース管理部"2"とデータデータベース管理部"2"が配備され、計算機ドメイン"3"に計算機データベース管理部"3"とアプリケーションデータベース管理部"3"とデータデータベース管理部"3"が配備されるモデルとする。同様、ネットワークドメイン"X"にはネットワークデータベース管理部"X"が配備されるモデルとする。本実施の形態において"X"は数字である。

クライアント装置は、図６７に示されるようなユーザオブジェクトと、種別が映像配信のアプリケーションオブジェクトと、種別が対象のデータ名のデータオブジェクトを含む資源予約メッセージをコア部１１０と交換する。

サービス確認ステップ（ステップ１２０）において、サービス確認部１３０は図６８に示されるようなオブジェクトやコネクションが必要であると判断する。同様に、オブジェクト・コネクション解析ステップ（ステップ１３０）において、オブジェクト・コネクション解析部１４０は、同データを保有するストレージオブジェクトと、同アプリケーションを保有する計算機オブジェクトと、同ストレージ資源と同計算機資源との間のコネクションと、同計算機資源とユーザとの間を結ぶコネクションが不足していると判断する。本実施の形態において、データとアプリケーションは別の場所、すなわち上記のストレージ資源と計算機資源とに分かれて実行してもよい。

次に、オブジェクト変更部１５０は、対象のデータの所在を確認するために計算機ドメイン"１"に存在するデータデータベース管理部"1"と、計算機ドメイン"2"に存在するデータデータベース管理部"2"と、計算機ドメイン"3"に存在するデータデータベース管理部"3"と、に問い合わせる。

その結果、オブジェクト変更部１５０は計算機ドメイン"1"のみに対象のデータが存在することを確認すると共に、同データを保有するストレージ資源の識別子も確認する。本実施の形態ではストレージ"1"が対象のアプリケーションを保有していると仮定する。

次に、オブジェクト変更部１５０は、対象のアプリケーションの所在を確認するために計算機ドメイン"１"に存在するアプリケーションデータベース管理部"1"と、計算機ドメイン"2"に存在するアプリケーションデータベース管理部"2"と、計算機ドメイン"3"に存在するアプリケーションデータベース管理部"3"と、に問い合わせる。

その結果、オブジェクト変更部１５０は計算機ドメイン"1"と計算機ドメイン"2"に対象のアプリケーションが存在することを確認すると共に、同アプリケーションを保有する計算機資源の識別子も確認する。本実施の形態では計算機"1"と計算機"2"が対象のアプリケーションを保有していると仮定する。

但し、このときストレージ"1"がエレメントの使用時間もしくは特徴を満足できないと仮定する。

この場合、ストレージ"1"に存在する対象データを他の使用可能なストレージ資源にコピーすることにより、問題が解決する。それゆえ、サービス内容変更ステップ（ステップ５１０）において、オブジェクト変更部１５０は映像配信のサービスに加え、事前に『"データ転送1"のサービスを実施する』というサービス内容に変更する。

これにより、サービスに必要となる資源は図６９に示されるようなオブジェクトとコネクションで表わされる。

このとき、オブジェクト変更部１５０は新たに追加されたコネクション"3"とストレージオブジェクトのエレメントを自動的に補完しなければならない。

移動先のストレージオブジェクトのエレメントは移動元のストレージオブジェクトに求められたエレメントの内容と同じである。同様に、コネクション"２"は移動前と移動先で同じである。但し、データのコピー作業はクライアントの所望の使用時間よりも前に完了している必要がある。

それゆえ移動先と移動元のストレージオブジェクト、およびコネクション"３"には次のような条件のすべてを満たすようにエレメントを変更する必要がある。
・条件１：クライアントの所望の使用時間よりも以前にデータのコピー作業を実行できるために、同使用時間以前にも対象のストレージ資源が予約可能であること。
・条件２：コネクション"３"のエレメントの特徴となる帯域は、予約されるストレージ資源の有するネットワークインターフェースカードの物理帯域とする。もしくは、サービスデータベース管理部１２０に予め規定の帯域が設定されており、オブジェクト変更部１５０やコネクション変更部１６０がその値を参照する。
・条件３：条件２に基づき、新たに追加される使用時間は次のように設定される。

"データ転送１"の実行所要時間＝データサイズ÷条件２でのコネクション帯域
新たに追加される使用時間は次の時間よりも以前になることを満たす必要がある。

新たに追加される使用時間＜＝
当初のクライアントの所望の開始時刻−"データ転送１"の実行所要時間
なお、上記において"＜＝"とは"以前"を表現する記号とし、"−"とは"時間を遡ること"を表現する記号とする。

新たに追加されたストレージオブジェクトと、コネクション"３"は上記の条件１〜３を満足するように予約される必要がある。

上記のように"データ転送１"のサービスを追加した結果、データ資源の状態は図７０から図７１に示されるように移動する仮定する。もしくは図７２から図７３に示されるように移動すると仮定する。

上記の前者の仮定に基づく場合、映像配信サービスの予約自体は図７４示された内容となる。一方、後者の仮定に基づく場合、映像配信サービスの予約自体は図７５に示される内容となる。具体的な資源予約処理の内容は第２の実施の形態や第３の実施の形態と同じである。

以上により、請求項２、５に示されるサービス変更ステップを実現できる。

上記のように、例えばアプリケーション資源やデータ資源などをコピーしたり、移動したりすることにより、資源予約メッセージの受信時における各資源の配置モデルに制限されて資源予約に失敗するケースを削減できる。

上記の第１〜第４の実施の形態における資源予約装置１００の構成要素の動作をプログラムとして構築し、資源予約装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。

１０ユーザデータベース管理部
２０データデータベース管理部
３０アプリケーションデータベース管理部
４０計算機データベース管理部
５０ストレージデータベース管理部
６０ネットワークデータベース管理部
７０トランザクションマネージャ
１００資源予約装置
１１０コア部
１２０サービスデータベース管理部
１３０サービス確認部
１４０オブジェクト・コネクション解析部
１５０オブジェクト変更部
１６０コネクション変更部

Claims

アプリケーション、データ、計算機、ストレージ及びネットワークを含む資源を管理し、クライアント装置からの予約要求に応じて資源を予約する資源予約装置であって、
ユーザ、前記アプリケーション、前記データ、前記計算機、前記ストレージ及び前記ネットワークの各情報を管理する複数のデータベース管理手段と接続され、前記クライアント装置との間で、所要サービスに対応するオブジェクトとコネクションが指定された資源予約メッセージを交換するメッセージ交換手段と、
前記複数のデータベース管理手段と管理対象のドメイン及びドメイン間の関係及びコネクションの端点が特定可能な情報を保持するサービスデータベース管理手段と、
前記資源予約メッセージに基づいて、前記サービスデータベース管理手段を参照して、サービス内容と性能保証の種別と、サービスのために必要となるオブジェクトとコネクション、アプリケーションデータとデータの配置方法、ネットワークインフラ条件に基づくコネクションの資源予約の必要性の、一部または全部について決定するサービス確認手段と、
前記資源予約メッセージにより前記クライアント装置から取得したオブジェクト群とコネクション群の存在や内容を確認するオブジェクト・コネクション解析手段と、
前記サービス確認手段と前記オブジェクト・コネクション解析手段の結果に基づいて、欠損しているオブジェクトを生成すると共に、前記メッセージ交換手段を介して前記各データベース管理手段との間でデータ交換を行うことによりオブジェクトの内容を補完してオブジェクト候補として前記サービスデータベース管理手段に格納するオブジェクト変更手段と、
前記サービス確認手段と前記オブジェクト・コネクション解析手段と前記オブジェクト変更手段の結果に基づいて、欠損しているコネクションを生成すると共に、前記メッセージ交換手段を介して、ネットワークデータを管理するデータベース管理手段とのデータ交換を行うことにより、コネクションの内容を補完してコネクション候補として前記サービスデータベース管理手段に格納するコネクション変更手段と、
前記オブジェクト変更手段と前記コネクション変更手段で探索され、前記サービスデータベース管理手段に格納されたオブジェクト群とコネクション群の組み合わせからなるサービスパターンの中から実際に資源予約する一つのサービスパターンを選択し、選択されたオブジェクトまたはコネクションを構成する資源を管理している各々のデータベース管理手段と連携して資源予約を行う機能を有する資源予約手段と、
を有することを特徴とする資源予約装置。
前記オブジェクト変更手段は、
予約可能なオブジェクト候補が無い場合に、サービス内容を変更して、再度処理を行う手段を含む
請求項1記載の資源予約装置。
前記サービス確認手段は、
前記資源予約メッセージに基づいて、ドメインのタイプに関する情報を格納した前記サービスデータベース管理手段を参照する、
または、
資源予約装置を実現するソフトウェアのソースコードに物理的に記載されているか否かの判断、
のいずれかにより、前記資源予約メッセージで要求されているサービスに対し、ネットワーク資源を予約するか否かを判定する手段を含む
請求項１または２記載の資源予約装置。
アプリケーション、データ、計算機、ストレージ及びネットワークを含む資源を管理し、クライアント装置からの予約要求に応じて資源を予約する資源予約方法であって、
ユーザ、前記アプリケーション、前記データ、前記計算機、前記ストレージ及び前記ネットワークの各情報を管理する複数のデータベース管理手段と接続される資源予約装置において、
メッセージ交換手段が、前記クライアント装置との間で、所要サービスに対応するオブジェクトとコネクションが指定された資源予約メッセージを交換するメッセージ交換ステップと、
サービス確認手段が、前記資源予約メッセージに基づいて、前記複数のデータベース管理手段と管理対象のドメイン及びドメイン間の関係及びコネクションの端点が特定可能な情報を保持するサービスデータベース管理手段を参照して、サービス内容と性能保証の種別と、サービスのために必要となるオブジェクトとコネクション、アプリケーションデータとデータの配置方法、ネットワークインフラ条件に基づくコネクションの資源予約の必要性の、一部または全部について決定するサービス確認ステップと、
オブジェクト・コネクション解析手段が、前記資源予約メッセージにより前記クライアント装置から取得したオブジェクト群とコネクション群の存在や内容を確認するオブジェクト・コネクション解析ステップと、
オブジェクト変更手段が、前記サービス確認ステップと前記オブジェクト・コネクション解析ステップの結果に基づいて、欠損しているオブジェクトを生成すると共に、前記各データベース管理手段との間でデータ交換を行うことによりオブジェクトの内容を補完してオブジェクト候補として前記サービスデータベース管理手段に格納するオブジェクト変更ステップと、
コネクション変更手段が、前記サービス確認ステップと前記オブジェクト・コネクション解析ステップと前記オブジェクト変更ステップを実行した結果に基づいて、欠損しているコネクションを生成すると共に、ネットワークデータを管理するデータベース管理手段とのデータ交換を行うことにより、コネクションの内容を補完してコネクション候補として前記サービスデータベース管理手段に格納するコネクション変更ステップと、
資源管理手段が、前記オブジェクト変更ステップと前記コネクション変更ステップで探索され、前記サービスデータベース管理手段に格納されたオブジェクト群とコネクション群の組み合わせからなるサービスパターンの中から実際に資源予約する一つのサービスパターンを選択し、選択されたオブジェクトまたはコネクションを構成する資源を管理している各々のデータベース管理手段と連携して資源予約を行う機能を有する資源予約ステップと、
を実行することを特徴とする資源予約方法。
前記オブジェクト変更において、
予約可能なオブジェクト候補が無い場合に、サービス内容を変更して、再度処理を行う
請求項４記載の資源予約方法。
前記サービス確認ステップにおいて、
前記資源予約メッセージに基づいて、ドメインのタイプに関する情報を格納した前記サービスデータベース管理手段を参照する、
または、
資源予約装置を実現するソフトウェアのソースコードに物理的に記載されているか否かの判断、
のいずれかにより、前記資源予約メッセージで要求されているサービスに対し、ネットワーク資源を予約するか否かを判定する
請求項４または５記載の資源予約方法。
請求項１乃至３のいずれか1項に記載の資源予約装置を構成する各手段としてコンピュータを機能させるための資源予約プログラム。