第1のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第2のソフトウェアが前記第1のソフトウェアが利用している利用中リソースを利用して動作するか否かを判定するリソース判定部と、前記リソース判定部により前記第2のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、前記第2のソフトウェアの前記利用中リソースの利用モードを判定し、前記第1のソフトウェアの前記利用中リソースの利用モードと前記第2のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第2のソフトウェアの起動の許否を判定する起動許否判定部とを備えることを特徴とするソフトウェア実行システム。前記ソフトウェア実行システムは、更に、先に動作している先行ソフトウェアの利用モードと後から起動される後続ソフトウェアの利用モードとの組み合わせであって、先行ソフトウェアと後続ソフトウェアとが同一のリソースを同時に利用することが許可される利用モードの組み合わせを同時利用許可条件として示し、先に動作している先行ソフトウェアの利用モードと後から起動される後続ソフトウェアの利用モードとの組み合わせであって、先行ソフトウェアと後続ソフトウェアとが同一のリソースを同時に利用することが禁止される利用モードの組み合わせを同時利用禁止条件として示す条件情報を記憶する条件情報記憶部を備え、前記起動許否判定部は、前記第1のソフトウェアの前記利用中リソースの利用モードが、前記条件情報記憶部により記憶された条件情報の同時利用許可条件に示される先行ソフトウェアの利用モードと一致し、前記第2のソフトウェアの前記利用中リソースの利用モードが前記同時利用許可条件に示される後続ソフトウェアの利用モードと一致する場合に、前記第2のソフトウェアの起動を許可し、前記第1のソフトウェアの前記利用中リソースの利用モードが、前記条件情報記憶部により記憶された条件情報の同時利用禁止条件に示される先行ソフトウェアの利用モードと一致し、前記第2のソフトウェアの前記利用中リソースの利用モードが前記同時利用禁止条件に示される後続ソフトウェアの利用モードと一致する場合に、前記第2のソフトウェアの起動を禁止することを特徴とする請求項1記載のソフトウェア実行システム。前記ソフトウェア実行システムは、更に、前記第2のソフトウェアが利用するリソースと、前記第2のソフトウェアが利用するリソースの利用モードとを示すリソース情報を記憶するリソース情報記憶部を備え、前記リソース判定部は、前記リソース情報記憶部により記憶されたリソース情報が示す前記第2のソフトウェアが利用するリソースと、前記利用中リソースとが一致する場合に、前記第2のソフトウェアが前記利用中リソースを利用して動作すると判定することを特徴とする請求項1又は2記載のソフトウェア実行システム。前記ソフトウェア実行システムは、更に、前記第2のソフトウェアがリソースを利用する際に出力するコマンドを解析して、前記第2のソフトウェアが利用するリソースと、前記第2のソフトウェアが利用するリソースの利用モードとを識別するリソース識別部を備え、前記リソース判定部は、前記リソース識別部により識別された前記第2のソフトウェアが利用するリソースと、前記利用中リソースとが一致する場合に、前記第2のソフトウェアが前記利用中リソースを利用して動作すると判定することを特徴とする請求項1又は2記載のソフトウェア実行システム。前記起動許否判定部は、前記第2のソフトウェアの起動を禁止する場合に、前記第2のソフトウェアと関連付けられている他のソフトウェアの起動も禁止することを特徴とする請求項1~4いずれか記載のソフトウェア実行システム。前記ソフトウェア実行システムは、更に、各々が個別にリソースを管理し、各々が管理しているリソースを用いて複数のソフトウェアが動作する複数の計算機を備え、前記リソース判定部は、計算機ごとに、計算機で新たに起動する第2のソフトウェアが、当該計算機で動作中の第1のソフトウェアが利用中の前記計算機のリソースを利用して動作するか否かを判定することを特徴とする請求項1~5いずれか記載のソフトウェア実行システム。前記第1のソフトウェア及び前記第2のソフトウェアは、SOAServiceOrientedArchitectureにおけるサービスアプリケーションであることを特徴とする請求項1~6いずれか記載のソフトウェア実行システム。第1のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第2のソフトウェアが前記第1のソフトウェアが利用している利用中リソースを利用して動作するか否かを、コンピュータが判定するリソース判定ステップと、前記リソース判定ステップにより前記第2のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、コンピュータが、前記第2のソフトウェアの前記利用中リソースの利用モードを判定し、前記第1のソフトウェアの前記利用中リソースの利用モードと前記第2のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第2のソフトウェアの起動の許否を判定する起動許否判定ステップとを備えることを特徴とするソフトウェア実行方法。第1のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第2のソフトウェアが前記第1のソフトウェアが利用している利用中リソースを利用して動作するか否かを判定するリソース判定ステップと、前記リソース判定ステップにより前記第2のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、前記第2のソフトウェアの前記利用中リソースの利用モードを判定し、前記第1のソフトウェアの前記利用中リソースの利用モードと前記第2のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第2のソフトウェアの起動の許否を判定する起動許否判定ステップとをコンピュータに実行させることを特徴とするプログラム。特許文献1の方式は、個々のサービス同士に対してサービス競合可否条件を定義する必要があり、サービス数が多くなると定義しなければならない情報が膨大となり、定義コストが大きくなってしまう。すなわち、サービスの競合関係をすべてのサービス間について定義するのでは、多数のサービスを管理する場合に、サービスの追加変更の度に多大なコストを要してしまうことになる。このため、サービスの追加変更時にも、既存サービスとの個々の関係を定義することなく、競合を排除できる仕組みが必要である。また、特許文献1の方式は、WEBWorldWideWebサービスのようにHTTPHyperTextTransferProtocolで中継可能なサービスしか対象にできないため、ESB上のあらゆるサービスに適用できるわけではない点も問題がある。この発明は前記のような課題を解決することを主な目的とするもので、例えば、全てのソフトウェアサービス同士の間の競合可否条件を定義することなく、ソフトウェアサービスの競合を管理するシステムを実現することを主な目的とする。この発明に係るソフトウェア実行システムは、第1のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第2のソフトウェアが前記第1のソフトウェアが利用している利用中リソースを利用して動作するか否かを判定するリソース判定部と、前記リソース判定部により前記第2のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、前記第2のソフトウェアの前記利用中リソースの利用モードを判定し、前記第1のソフトウェアの前記利用中リソースの利用モードと前記第2のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第2のソフトウェアの起動の許否を判定する起動許否判定部とを備えることを特徴とする。この発明に係るソフトウェア実行システムは、ソフトウェアサービス間でリソースを共用する場合に、各ソフトウェアサービスが共用するリソースの利用モードに基づき、競合可否を判定する。よって、この発明に係るソフトウェア実行システムは、全てのソフトウェアサービス同士の間の競合可否条件を定義することなく、ソフトウェアサービスの競合を管理することが出来る。実施の形態1.サービス実行管理システムソフトウェア実行システムの概要図1は、サービス実行管理システムソフトウェア実行システムの構成の例を示す図である。ここで、サービス実行管理システム100は、ソフトウェア実行システムに対応する。そして、前述の通り、サービスは、ソフトウェアに対応する。また、サービスは前述の通りSOAにおけるサービスアプリケーションであっても良い。サービス実行管理システム100は、入力端末105、開発サーバ110、DBサーバ120、サービス実行サーバ130から構成される。ここで、DBサーバ120は、データベースサーバのことである。入力端末105、開発サーバ110、DBサーバ120、サービス実行サーバ130等は、例えば、LANやインターネットなどのネットワーク150に接続されている。以下、入力端末105、開発サーバ110、DBサーバ120、サービス実行サーバ130を個別に説明する。入力端末105の説明入力端末105は、例えばパソコンなどから構成されており、業務システムを連携するサービスやルーティングの開発者が、設計開発作業を行う際に使用する端末である。以降、業務システムを連携するサービスやルーティングの開発者を開発者と称する。DBサーバ120の説明DBサーバ120は、各種の情報を保管する記憶装置であり、例えば、開発サーバ110で作成された定義情報を定義情報格納部122で格納する。定義情報とは、ルーティング定義情報112a、サービスリソース関係定義情報112b、アクセスポリシー定義情報112cである。ここで、定義情報格納部122は、条件情報後述を記憶する条件情報記憶部とリソース情報後述を記憶するリソース情報記憶部とに対応する。また、定義情報の一部はサービスコンテナ131から情報の直接参照が必要な場合は、サービス実行サーバ130が備える記憶装置図示は省略に記憶されても良い。サービス実行サーバ130の説明サービス実行サーバ130は、開発サーバ110により開発された一連のサービスやルーティングを実行するサーバである。サービス実行サーバ130は、サービスを実行するサービスコンテナ131、サービスの競合発生時にサービスの一時停止などの制御を行う競合制御部132、競合制御部132から呼び出される競合判定部133、競合状態管理部134、サービスリソース特定部135から構成される。ここで、サービスコンテナ131は計算機に対応する。すなわち、前述のようにサービスコンテナ131は、ESBやアプリケーションサーバなどの機能を持つ計算機もしくは仮想計算機であると言える。また、競合判定部133は、起動許否判定部に対応し、競合状態管理部134はリソース判定部に対応する。開発サーバ110の説明開発サーバ110は、業務システムの連携やサービス間の競合管理に必要となる定義情報を開発するためのサーバである。定義情報設定部111は、例えば各種の情報を入力するキーボードやマウスなどのマンマシンインタフェース、あるいは、入力端末105で入力された各種の情報をネットワーク経由で取得するネットワークインタフェースなどから構成されている。そして、定義情報設定部111は、入力した情報から定義情報ルーティング定義情報112a、サービスリソース関係定義情報112b、アクセスポリシー定義情報112cを設定して、定義情報記憶部112に一時的に格納する処理を実施する。ここで、サービスリソース関係定義情報112bは、リソース情報に対応する。定義情報設定部111のルーティング定義部111aは、例えば入力端末105からルーティング定義画面後述の表示要求があると、ルーティング定義画面後述を入力端末105のディスプレイ図示は省略に表示する。そして、ルーティング定義部111aは、ルーティング定義画面後述上で、ルーティングを構成する一連のサービスの定義を受け付けて、その定義内容を示すルーティング定義情報112aを出力する。そして、定義情報記憶部112は、出力されたルーティング定義情報112aを一時的に記憶する。このとき、競合制御機能挿入部113は、ルーティング定義部111aで作成したルーティング定義情報112aに対して、各サービスの前後に競合制御部132を呼び出すロジックを挿入する。後述の実施の形態3においては、競合制御機能挿入部113は、ルーティング定義部111aで作成したルーティング定義情報112aに対して、指定したサービスの集合であるサービスセットの前後に競合制御部132を呼び出すロジックを挿入する。これにより、サービスの開始時と終了時に競合制御部132を呼び出すことが可能となる。後述の実施の形態3においては、サービスセットの開始時と終了時に競合制御部132を呼び出すことが可能となる。サービスリソース関係定義部111bは、例えば入力端末105からサービスリソース関係定義画面後述の表示要求があると、サービスリソース関係定義画面後述を入力端末105のディスプレイ図示は省略に表示する。そして、サービスリソース関係定義部111bは、サービスリソース関係定義画面後述上で、サービスリソース関係の定義を受け付けて、その定義内容を示すサービスリソース関係定義情報112bを出力する。そして、定義情報記憶部112は、出力されたサービスリソース関係定義情報112bを一時的に記憶する。アクセスポリシー定義部111cは、例えば入力端末105からアクセスポリシー定義画面後述の表示要求があると、アクセスポリシー定義画面後述を入力端末105のディスプレイ図示は省略に表示する。そして、アクセスポリシー定義部111cは、アクセスポリシー定義画面後述上で、アクセスポリシー情報の定義を受け付けて、その定義内容を表すアクセスポリシー定義情報112cを出力する。そして、定義情報記憶部112は、出力されたアクセスポリシー定義情報112cを一時的に記憶する。なお、定義情報設定部111は、各種の定義情報を設定した後、登録要求が入力端末105から入力されると、定義情報記憶部112が一時的に記憶している各種の定義情報をDBサーバ120の定義情報格納部122に移動する。そして、定義情報格納部122は移動された各種の定義情報を記憶する。ただし、定義情報ルーティング定義情報112a、サービスリソース関係定義情報112b、アクセスポリシー定義情報112cの一部は、サービスコンテナ131から直接、情報の参照が必要な場合は、サービス実行サーバ130が備える記憶装置図示は省略に記憶されても良い。サービス実行管理システム100の処理の概略説明図2は、サービス実行管理システム100の処理の概略を示すフローチャートである。サービス実行管理システム100におけるサービスルーティングの設計からサービス実行までの大まかな手順を説明する。ルーティング設計ステップS21は、定義情報設定部111が各種の定義情報の作成を行い、定義情報に基づいてサービスコンテナ131がルーティングを実行するために必要となるルーティング定義情報112aを作成するステップである。ここで、ルーティング定義情報112aの生成において、競合制御機能挿入部113は、定義情報設定部111が設定したルーティングに対して、同時実行時の競合を制御するサービスの前後に、競合制御部132を呼び出すためのロジックを挿入する。デプロイステップS22は、作成された各種の定義情報ルーティング定義情報112a、サービスリソース関係定義情報112b、アクセスポリシー定義情報112cを定義情報格納部122に登録するステップである。サービス実行ステップS23は、サービスコンテナ131から各種の定義情報を参照してサービスを実行するステップである。ルーティング設計ステップの説明ルーティング設計ステップS21における、各種の定義情報の作成画面を図3、図4、図5に示す。図3はルーティング定義画面300の例を示す図である。入力端末105のディスプレイ図示は省略に表示されたルーティング定義画面300により、開発者が入力した内容に基づいて、ルーティング定義部111aは、パレット302の中のノードリストから所望のノードサービス、分岐、開始、終了を選択して、そのノードをキャンバス301に配置することができる。またルーティング定義部111aは、パレット302の中の接続からエッジを選択して、各ノードをお互いに接続することで、サービスの呼び出しフローであるルーティングを作成することができる。また、実施の形態3において、ルーティング定義部111aは、パレット302の中のその他からサービス領域を選択して、その領域の位置をパレット上のルーティングに対して指定することで、同時実行時の競合を制御する単位としてサービスセットを設定することができる。図4は、アクセスポリシー定義画面400の例を示す図である。アクセスポリシー定義画面400は、開発者がアクセスポリシーを定義することができる画面である。アクセスポリシー定義画面400は、定義済みのアクセスポリシー定義の一覧を表示するアクセスポリシー定義テーブル401、アクセスポリシー定義テーブル401にアクセスポリシー定義を追加する追加ボタン403、アクセスポリシー定義テーブル401に含まれている定義を削除する削除ボタン402、指定した値で定義を更新する更新ボタン404から構成されている。アクセスポリシー定義は、リソースの種別を表すリソースタイプ411、アクセスポリシー間で競合の判定を行う判定ロジック412、リソースへのアクセスタイム413、アクセスポリシー414のそれぞれが指定される。アクセスポリシー414は例えばC、R、U、Dが指定される。ここでC、R、U、Dは、データベースへのデータアクセスの形態を示し、それぞれCreateReadUpdateDeleteの意味を表している。アクセスタイム413は、例えば、リソースへのアクセスのタイミングが実行時または常時から選択する。図5は、サービスリソース関係定義画面500の例を示す図である。サービスリソース関係定義画面500は、定義済みのサービスリソース関係定義情報112bの一覧を表すサービスリソース定義関係定義テーブル501と、サービスリソース定義関係定義テーブル501に定義情報を追加する追加ボタン403と、サービスリソース定義関係定義テーブル501に含まれている定義を削除する削除ボタン402、指定した値で定義を更新する更新ボタン404から構成されている。サービスリソース関係定義情報112bは、ルーティング定義情報112aで定義されているサービス識別名511、リソースの識別子であるリソース識別名512、アクセスポリシー定義情報112cで定義されたリソースタイプ411、アクセスポリシー414のそれぞれが指定される。ルーティングの説明次に、図6、図7、図8を用いて、サービスを実行するルーティングモデルを説明する。図6は、即時更新サービスルーティングの例を示す図である。図7は、一括更新サービスルーティングの例を示す図である。図8は、競合制御部呼び出しが追加されたルーティングの例を示す図である。即時更新サービスルーティングR61は、HTTP受付1T611でHTTPリクエストを受信すると、更新サービスAT612、更新サービスBT613、更新サービスCT614、メール通知T615を順次呼び出すルーティングである。また、一括更新サービスルーティングR62は、HTTP受付2T621でHTTPリクエストを受信し、一括更新サービスA~CT622~T624、メール通知2T625を順次呼び出すルーティングである。図6と図7に示すルーティングは、ルーティング定義部111aによって定義されたものである。そして、図8に示すルーティングは、図6に示す即時更新サービスルーティングの例に競合制御機能挿入部113がルーティング設計ステップS21において、サービス毎の競合制御を実現するために必要となる競合制御部呼び出しロジックを挿入した後のルーティングのフローである。図8に示すルーティングは、競合制御機能挿入部113によって、各サービスの前に競合制御呼び出しinT91が追加され、各サービスの後に競合制御呼び出しoutT92が追加されている。すなわち、図8に示すルーティングがルーティング定義情報112aの具体例である。なお、図7に示す一括更新サービスルーティングも図6に示す即時更新サービスルーティングと同様に競合制御機能挿入部113によって競合制御部呼び出しロジックが挿入されるが図示は省略する。定義情報の説明図9、図10、図11を用いて、サービス実行管理システム100がサービス競合の管理を行うための定義情報のデータ構造の例を説明する。図9は、サービスリソース関係定義情報112bの例を示す図である。図10は、アクセスポリシー定義情報112cの例を示す図である。図11は、条件情報1400の例を示す図である。サービスリソース関係定義情報112b図9は、各ルーティングのサービスがどういったリソースをどう利用するかを示している。サービスとリソースの関係は、サービス識別名511、リソース識別名512でサービスとリソースの対応を表し、リソースの種別を表すリソースタイプ411、リソース利用時のポリシーとしてアクセスポリシー414を用いて定義される。アクセスポリシー定義情報112c図10は、サービスが利用するリソース間の関係を判定するために必要となる。アクセスポリシー定義情報112cは、リソースの種別を表すリソースタイプ411、アクセスポリシーの識別名を表すアクセスポリシー414、リソースアクセスのタイミングを表すアクセスタイム413、アクセスポリシー間の競合判定を行うロジックをあらわす判定ロジック412から構成される。リソースタイプ411、アクセスポリシー414は、サービスリソース関係定義情報112bのリソースタイプ411、アクセスポリシー414に対応する。また、判定ロジック412はリソースタイプ411毎に定義される。そして、アクセスポリシー定義部111cは、新たにリソースタイプ411を定義する場合に、合わせて判定ロジック412を追加することで、競合判定の対象とするリソースタイプを任意に追加することが可能となる。条件情報1400図11は、アクセスポリシー定義情報112cに示された判定ロジック412に対応する。図11の条件情報1400は、DBテーブルの判定ロジック412であるDBTablePolicyComparatorの例を示すものである。図11の条件情報1400は、DBテーブルのリソースポリシー同士の判定内容を示したものであり、判定時のリソースのアクセス状態1401と、比較対象のアクセスポリシーである比較ポリシー1402、競合可否1403の結果を記述している。また、条件情報1400は、競合可否1403の結果が可であった場合には、アクセス状態がどのように変わるかを変更後状態1404として記述している。ここで、アクセス状態1401は、サービスがリソースを利用する利用モードに対応する。そして、アクセス状態1401は、先に動作している先行サービス先行ソフトウェアの利用モードに対応し、比較ポリシー1402は、後から起動される後続サービス後続ソフトウェアの利用モードに対応する。そして、競合可否1403が可となるアクセス状態1401と比較ポリシー1402との組合せが同時利用許可条件に対応し、競合可否1403が不可となるアクセス状態1401と比較ポリシー1402との組合せが同時利用禁止条件に対応する。サービスリソース関係定義情報112bとアクセスポリシー定義情報112cとから、サービスの実行時にサービスが利用するリソースの関係を条件情報1400に基づいて判定することで、サービス間の競合を判断することが可能となる。なお、これらの定義情報は、図2のS22に示すデプロイステップにおいて、定義情報格納部122に記憶される。サービス実行ステップにおける具体的な例を用いて以降に説明する。サービス実行ステップの説明図12、図13、図14を用いてサービス実行ステップの具体例を説明する。図12は、サービスリソース利用状態121aの例を示す図である。aは一括サービスルーティングR62が実行された場合、bは更新サービスAT612が実行された場合、cは競合制御呼び出しoutT92bが実行された場合図13は、競合制御部呼び出しinの処理を示すフローチャートである。図14は、競合制御部呼び出しoutの処理を示すフローチャートである。サービス実行ステップの説明にあたり、サービスコンテナ131図1は、図7に示す一括サービスルーティングR62を実行中であり、かつ、一括サービスルーティングR62に含まれる全てのサービスがリソースを利用中であると想定する。ここで、一括サービスルーティングR62以外のルーティングは実行されていないものとする。そして、サービスコンテナ131は、実行中のサービスが利用中のリソースの情報を実行時情報記憶部121に出力する。そして、実行時情報記憶部121は実行中のサービスが利用中のリソースの情報をサービスリソース利用状態121aとして記憶する。例えば、サービスコンテナ131が図7のHTTP受付2T621を実行した場合、図9に示すようにサービス識別名511HTTP受付2のリソース識別名512はhttp://hostA/Services/updateall/である。また、HTTP受付2のリソースタイプ411はURLUniformResourceLocatorであり、アクセスポリシーはバインドである。サービスコンテナ131は、図9のサービスリソース関係定義情報112bを参照することにより、これらの情報を得ることも出来、またHTTP受付2のサービスを実行時にHTTP受付2のサービスからこれらの情報を得ることも出来る。そして、サービスコンテナ131は、図12aに示すようにリソース識別名512としてhttp://hostA/Services/updateall/、リソースタイプ411としてURL、アクセス状態1401としてバインドを実行時情報記憶部121に出力する。ここで、例えばリソース識別名512http://hostA/Services/updateall/は、HTTP受付2のサービスが利用中の利用中リソースに対応する。同様に例えば、サービスコンテナ131が図7の一括更新サービスAT622を実行した場合、図9に示すようにサービス識別名511一括更新サービスAのリソース識別名512はDB1/テーブルAである。また、一括更新サービスAのリソースタイプ411はDBテーブルであり、アクセスポリシーはUである。そして、サービスコンテナ131は、図12aに示すようにリソース識別名512としてDB1/テーブルA、リソースタイプ411としてDBテーブル、アクセス状態1401としてUを実行時情報記憶部121に出力する。図7に示す一括更新サービスBT623、一括更新サービスCT624についても同様である為、説明を省略する。実行時情報記憶部121は、サービスリソース利用状態121aとして、リソース識別名512、リソースタイプ411、アクセス状態1401を記憶する。ここで、リソース識別名512とリソースタイプ411とは、実行中のサービスが利用中であるリソースを特定する為の情報であり、前述のように図9のサービスリソース関係定義情報112bや図10のアクセスポリシー定義情報112cで定義した内容に対応する。アクセス状態1401は、サービスリソースがどのように利用されているかを表す項目である。なお、図7に示すメール通知2T625は、他のサービスと共用するようなリソースを利用しない為に、サービスリソース利用状態121aとして実行時情報記憶部121には記憶されない。そして、サービスコンテナ131図1が、図7に示す一括サービスルーティングR62を実行中に、新たに図6に示す即時更新サービスルーティングR61を実行する場合を想定する。一括サービスルーティングR62の場合は、他のルーティングが実行されていなかった為に競合制御部呼び出しの説明を省略した。しかし、ここでは一括サービスルーティングR62が既に実行中の場合を考える為に、競合制御部呼び出しが明記された図8に示す即時更新サービスルーティングR61を用いて説明する。図8のT91a~T611における処理の説明サービスコンテナ131図1は、図8に示す即時更新サービスルーティングR61の実行にあたり、最初に競合制御部呼び出しinT91aを実行し、競合制御部132図1を呼び出す。競合制御部132は、サービス実行前にそのサービスが実行できるか判定を行い、処理待ちや処理継続の制御を行う。ここで、競合制御部呼び出しinにおける競合制御部132の動作を図13のフローチャートで説明する。まず、競合制御部132は、即時更新サービスルーティングR61において、競合制御部132の処理開始のトリガーとなるメッセージをサービスコンテナ131から受信するS101。そして、競合制御部132は、サービスリソース特定部135図1を呼び出す。サービスリソース特定部135は、ルーティング定義情報112aに示されたサービスが利用するリソースを特定するS102。具体的には、図8の競合制御部呼び出しinT91aに基づき呼び出されたサービスリソース特定部135は、ルーティング定義情報112aにおける次の処理である図8に示すHTTP受付1T611のサービスが利用するリソースを特定する。ここで、サービスリソース特定部135は、図9に示すサービスリソース関係定義情報112bを参照し、ルーティング定義情報112aに示されたサービス識別名HTTP受付1に対応するリソース識別名http://hostA/Services/update/を特定する。次に図13に示すS103において、競合制御部132は、競合状態管理部134図1を呼び出す。競合状態管理部134は、図12aに示すサービスリソース利用状態121aに、サービスリソース特定部135が特定したリソース識別名http://hostA/Services/update/が有るか否かを判定することにより、異なるサービス間で同時に利用される同時利用リソースが有るか否かを判定する。そして、http://hostA/Services/update/がサービスリソース利用状態121aに無いので、競合状態管理部134は同時利用リソースが無いと判定するS103のNo。S103のYesの場合は、後述する。そして、競合制御部132はリソース識別名http://hostA/Services/update/の情報を実行時情報記憶部121に入力し、実行時情報記憶部121は、図12bに示すようにサービスリソース利用状態121aとして記憶するS107。ここで、競合制御部132は例えばサービス実行サーバ130の記憶装置図示は省略にサービスリソース利用状態121aが更新される前の状態を記憶することが可能である。すなわち、競合制御部132は、リソース識別名http://hostA/Services/update/の情報を新たに入力する前は、サービスリソース利用状態121aにリソース識別名http://hostA/Services/update/の情報が無かった状態すなわち図12aの状態を記憶することが可能である。最後に競合制御部132は、サービスの処理開始のトリガーとなるメッセージを次のサービスすなわち図8のHTTP受付1T611に転送するS106。図8のT92aにおける処理の説明サービスコンテナ131は、図8のHTTP受付1T611の処理を終了後、図8の競合制御部呼び出しoutT92aを実行し、競合制御部132図1を呼び出す。ここで、競合制御部呼び出しoutにおける競合制御部132の動作を図14のフローチャートで説明する。まず、競合制御部132は、即時更新サービスルーティングR61において、競合制御部132の処理開始のトリガーとなるメッセージをサービスコンテナ131から受信するS111。そして、図13のS102と同様に競合制御部132は、サービスリソース特定部135図1を呼び出す。サービスリソース特定部135は、ルーティング定義情報112aに示されたサービスが利用するリソースを特定するS112。具体的には、図8の競合制御部呼び出しoutT92aに基づき呼び出されたサービスリソース特定部135は、ルーティング定義情報112aにおける前の処理である図8に示すHTTP受付1T611のサービスが利用するリソースを特定する。ここで、サービスリソース特定部135は、図9に示すサービスリソース関係定義情報112bを参照し、ルーティング定義情報112aに示されたサービス識別名HTTP受付1に対応するリソース識別名http://hostA/Services/update/を特定する。図14のS113において、競合制御部132は、サービス実行サーバ130の記憶装置図示は省略に記憶されたサービスリソース利用状態121aが、ルーティング定義情報112a上で直前の競合制御部呼び出しinによって更新される前の状態に戻す。すなわち、競合制御部132は、図13のS107において記憶したサービスリソース利用状態121aにリソース識別名http://hostA/Services/update/の情報が無かった状態すなわち図12aの状態に戻す。あるいは、競合制御部132は、サービスリソース利用状態121aにリソース識別名http://hostA/Services/update/の情報としては残しておいて、アクセス状態1401をバインドからなしに変更することも可能である図12c。ここでは、HTTP受付1T611のサービスの実行が完了し、競合制御部132は、サービスリソースをサービスが利用中の状態から解放する処理を行っている。最後に競合制御部132は、サービスの処理開始のトリガーとなるメッセージを次のサービスすなわち図8の競合制御部呼び出しinT91bに転送するS114。図8のT91bにおける処理の説明図8の競合制御部呼び出しinT91bでは、T91aと同様に競合制御部132を呼び出す。そして、同様にサービスリソース特定部135が呼び出され、サービスリソース特定部135は、図8に示す更新サービスAT612のサービスが利用するリソースを特定する。ここで、サービスリソース特定部135は、図9に示すサービスリソース関係定義情報112bを参照し、ルーティング定義情報112aに示されたサービス識別名更新サービスAに対応するリソース識別名DB1/テーブルAを特定する。次に図13に示すS103において、競合状態管理部134は、図12cに示すサービスリソース利用状態121aに、サービスリソース特定部135が特定したリソース識別名DB1/テーブルAが有るか否かを判定することにより、異なるサービス間で同時に利用される同時利用リソースが有るか否かを判定する。すなわち、競合状態管理部134は、第1のサービス一括更新サービスAがアクセス状態U所定の利用モードでDB1/テーブルA所定のリソースを利用して動作している場合に、新たに起動される第2のサービス更新サービスAが第1のサービス一括更新サービスAが利用しているDB1/テーブルA利用中リソースを利用して動作するか否かを判定する。そして、DB1/テーブルAがサービスリソース利用状態121aに有るので、競合状態管理部134は同時利用リソースが有ると判定するS103のYes。そして、図13に示すS104において、競合制御部132は、競合判定部133を呼び出す。競合判定部133は、サービスリソース関係定義情報112bのアクセスポリシー414と、サービスリソース利用状態121aのアクセス状態1401とを参照する。すなわち、競合判定部133は、図9に示す更新サービスAのアクセスポリシー414Rと、図12に示すDB1/テーブルAのアクセス状態1401Uとを参照する。また、競合判定部133は、図9に示す更新サービスAのリソースタイプ411DBテーブルを参照し、図10に示すアクセスポリシー定義情報112cのDBテーブルに対応する判定ロジック412DBTablePolicyComparatorを参照する。そして、競合判定部133は、DBTablePolicyComparatorに対応する図11の条件情報1400を用いて、更新サービスAがDB1/テーブルAを利用可能か否か判定する。すなわち、競合判定部133は、競合状態管理部134により第2のサービス更新サービスAがDB1/テーブルA利用中リソースを利用して動作すると判定された場合に、第2のサービス更新サービスAのDB1/テーブルA利用中リソースの利用モードを判定し、第1のサービス一括更新サービスAのDB1/テーブルA利用中リソースの利用モードと第2のサービス更新サービスAのDB1/テーブルA利用中リソースの利用モードとに基づき、第2のサービス更新サービスAの起動の許否を判定する。図11の条件情報1400において、アクセス状態1401がUで図12に示すDB1/テーブルAのアクセス状態1401Uに対応、比較ポリシー1402がR図9に示す更新サービスAのアクセスポリシー414Rに対応の場合の競合可否1403は可である。よって、競合判定部133は、更新サービスAがDB1/テーブルAを利用可能と判定する図13のS104のNo。すなわち、競合判定部133は、更新サービスAの起動を許可する。また、競合判定部133は、競合制御部132に競合可否1403が可であることと、図11に示す変更後状態1404がCであることを通知する。これは、他のサービスがデータベースに対しUpdateのアクセス形態で利用中であっても、新たなサービスがReadのアクセス形態であるならば同じリソースを利用可能であることを意味する。一方、例えば、アクセス状態1401がCで、比較ポリシー1402もCの場合は、競合可否1403は不可である。これは異なるサービス同士が同じリソースに対してCreateのアクセス形態では利用出来ないことを意味する。このような場合、競合判定部133は、リソースの同時利用が出来ないと判定し図13のS104のYes、実行中のサービスが終了してリソースを解放するのを待つ図13のS108。すなわち新たに実行されるサービスは処理待ちとなる。つまり、競合判定部133は、新たに実行されるサービス後続ソフトウェアの起動を禁止する。そして、実行中のサービスが終了してリソースを解放後に、競合判定部133は、再度、図13のS103において新たに実行されるサービスについて判定を行う。アクセス状態1401と比較ポリシー1402とがU同士、D同士の場合も同様である。競合判定部133が、更新サービスAがDB1/テーブルAを利用可能と判定した場合図13のS104のNo、図13のS105において、競合制御部132は、まず現在のサービスリソース利用状態121aを例えばサービス実行サーバ130の記憶装置図示は省略に記憶する。すなわち、競合制御部132は、図12cに示すリソース識別名DB1/テーブルAのアクセス状態がUであったことを記憶装置に記憶する。次に、競合制御部132は、実行時情報記憶部121が記憶しているサービスリソース利用状態121aのリソース識別名DB1/テーブルAのアクセス状態をCに変更する図13のS105、図12d。最後に競合制御部132は、サービスの処理開始のトリガーとなるメッセージを次のサービスすなわち図8の更新サービスAT612に転送するS106。図8のT92bにおける処理の説明サービスコンテナ131は、図8の更新サービスAT612の処理を終了後、図8の競合制御部呼び出しoutT92bを実行し、競合制御部132図1を呼び出す。図8のT92aの説明と同様に、図13のS113において、競合制御部132は、サービス実行サーバ130の記憶装置図示は省略に記憶されたサービスリソース利用状態121aが、ルーティング定義情報112a上で直前の競合制御部呼び出しinによって更新される前の状態に戻す。すなわち、競合制御部132は、リソース識別名512DB1/テーブルAのアクセス状態1401をCからUに戻す図12c。最後に競合制御部132は、サービスの処理開始のトリガーとなるメッセージを次のサービスに転送し、サービスコンテナ131はルーティングを継続する。以降の処理は同様である為、説明を省略する。なお、本例では、2つのルーティング即時更新サービスルーティングR61と一括更新サービスルーティングR62が同時に実行される場合を説明したが、同時に実行されるルーティングの数は2つに限られず、実際には多数のルーティングが同時に実行される。実施の形態1の効果実施の形態1におけるサービス実行管理システム100は、サービスがリソースを利用する場合のアクセス状態の関係に基づきサービスの競合判定を行うことで、全てのサービス間の競合可否条件の定義を不要とすることが可能である。すなわち、全てのサービス間の競合可否条件の定義をすることなく、アクセス状態間の競合可否条件のみを定義することで、サービス実行管理システム100は、同時に実行出来ないサービスを判定し、同時に実行出来ないと判定されたサービスを待機状態にすることで、サービスの競合を管理することが可能である。実施の形態1においては、業務システムを連携するサービス実行基盤において、サービスとそのサービスが利用するサービスリソース間の関係を定義し、その関係定義に基づいてサービスリソースの利用関係からサービス間の競合関係を判定するサービス実行管理方式について説明した。また、サービスとサービスリソース間の利用関係にポリシーを定義し、サービスリソースの競合可否をポリシーにしたがって判定するサービス実行管理方式について説明した。実施の形態2.サービス実行管理システム100の概要図15は、サービス実行管理システム100の構成の例を示す図である。実施の形態2のサービス実行管理システム100は実施の形態1のサービス実行管理システム100に比べ、開発サーバ110の定義情報設定部111にサービスリソース関係抽出手段定義部1413が追加されている。そして、開発サーバ110の定義情報記憶部112にサービスリソース関係抽出手段定義情報1414が追加されている。更に、サービス実行サーバ130にサービスリソース関係抽出部1431が追加されている。その他は、実施の形態1のサービス実行管理システム100と同様の構成である。以降、実施の形態1と同様の部分は、説明を省略する。サービスリソース関係抽出手段定義部1413は、サービスとリソース間の関係を抽出するための手段を定義するもので、例えば入力端末105からサービスリソース関係抽出手段定義画面後述の表示要求があると、サービスリソース関係抽出手段定義画面後述を入力端末105のディスプレイ図示は省略に表示する。そして、サービスリソース関係抽出手段定義部1413は、サービスリソース関係抽出手段定義画面後述上で、サービスとリソース間の関係を抽出する手段の定義を受け付けて、その定義内容を表すサービスリソース関係抽出手段定義情報1414を出力する。そして、定義情報記憶部112は出力されたサービスリソース関係抽出手段定義情報1414を一時的に記憶する。実施の形態2のサービス実行管理システム100も実施の形態1と同様に図2に示すフローチャートに従って処理を進める。ルーティング設計ステップの説明サービスリソース関係抽出手段定義部1413を用いた定義情報の作成は、図2で示したルーティング設計S21ステップ上で行う。図16は、サービスリソース関係抽出手段定義画面1600の例を示す図である。サービスリソース関係抽出手段定義画面1600は、サービス実行時にサービスリソース関係定義情報112bを抽出する手段を表したサービスリソース関係抽出手段定義情報1414を定義することのできる画面である。サービスリソース関係抽出手段定義画面1600は、定義済みのサービスリソース関係抽出手段定義の一覧を表示するサービスリソース関係抽出手段定義テーブル1601、サービスリソース関係抽出手段定義テーブル1601に定義情報を追加する追加ボタン403、指定した値で定義を更新する更新ボタン404、サービスリソース関係抽出手段定義テーブル1601に含まれている定義を削除する削除ボタン402から構成されている。サービスリソース関係抽出手段定義情報1414は、抽出手段を識別する名称として手段識別名1605、サービスとリソース関係とを抽出する手段の対象となるリソースの種別を表すリソースタイプ411、そして実際にどのようにサービスとリソース関係を抽出するかを表した抽出手段1607が指定される。抽出手段1607は、例えば、Java登録商標などのプログラムによって作成した抽出ロジックを表したもので、そのプログラムを呼び出すために必要となるクラス名などを指定する。定義情報の説明図17は、サービスリソース関係定義情報112bの例を示す図である。図18は、サービスリソース関係抽出手段定義情報1414の例を示す図である。実施の形態2におけるサービスリソース関係定義情報112bのデータ構造は図9に示す実施の形態1のサービスリソース関係定義情報112bと同じであるが、サービスリソース関係定義部111bは、サービス識別名511とリソースタイプ411のみ定義し、リソース識別名512、アクセスポリシー414は、定義しない。サービスリソース関係抽出手段定義情報1414は、前述で説明の通り、手段識別名1605、リソースタイプ411、抽出手段1607から構成される。サービスリソース関係抽出手段定義情報1414は図2のS22に示すデプロイステップにおいて、定義情報格納部122に記憶される。サービスリソース関係定義情報112bも実施の形態1と同様に定義情報格納部122に記憶される。サービス実行ステップの説明サービス実行ステップにおいて、実施の形態2のサービス実行管理システム100は、図13に示すS102における処理以外は、実施の形態1のサービス実行管理システム100と同様の処理を行う。図13に示すS102における実施の形態2のサービス実行管理システム100の処理を説明する。図13に示すS102は、実施の形態1と同様にルーティング上のサービスが利用するサービスリソースを特定するステップである。まず、競合制御部132図15は、実施の形態1と同様にサービスリソース特定部135図15を呼び出す。そして、サービスリソース特定部135は、実施の形態1と同様にルーティング定義情報112aに示されたサービスが利用するリソースを特定する為に、サービスリソース関係定義情報112bを参照する。ここで、サービスリソース関係定義情報112bにリソース識別名512とアクセスポリシー414とが定義されていない場合、サービスリソース特定部135はサービスリソース関係抽出部1431を呼び出す。サービスリソース関係抽出部1431は、サービスリソース関係抽出手段定義情報1414を参照し、サービスリソース関係定義情報112bに定義されたリソースタイプに応じた抽出手段を用いてサービスが利用するリソースを特定する。例えば、サービスが利用するリソースタイプがDBテーブルであれば、抽出手段DBAccessAnalyzerは、サービスが実行前に利用するSQLStructuredQueryLanguage文を解析する。そして、抽出手段DBAccessAnalyzerは、そのSQL文のタイプINSERT文、SELECT文、UPDATE文、DELETE文をアクセスポリシーC、R、U、Dに対応付ける。また、抽出手段DBAccessAnalyzerは、SQL文のテーブル名から対象のリソース識別名を抽出することが出来る。ここで、SQL文は、サービスがリソースを利用する際に出力するコマンドに対応する。サービスリソース特定部135は抽出手段が抽出したリソース識別名とアクセスポリシーを用いて、サービス識別名に対応するリソース識別名を特定する。実施の形態2の効果実施の形態2におけるサービス実行管理システム100は、サービスリソース関係抽出手段を定義しておくことで、実施の形態1の効果に加え、サービス実行時にサービスが利用するリソースを抽出することが可能となる。すなわち、実施の形態2におけるサービス実行管理システム100は、サービス実行時に実施の形態1におけるサービスリソース関係定義情報112bに相当する内容を抽出することが可能となる。そして、実施の形態2におけるサービス実行管理システム100は、実行時にサービスが利用するリソースが変化する場合にもサービスの競合判定を行うことが可能となる。実施の形態2においては、サービスとそのサービスが利用するサービスリソース間の関係定義について、サービス実行時に、そのサービスが利用するサービスリソースを自動で抽出する手段を定義し、サービスとサービスリソース間の関係を手動で定義することなく、サービス間の競合を判定するサービス管理方式について説明した。実施の形態3.サービス実行管理システム100の概要実施の形態3のサービス実行管理システム100は、実施の形態1の構成図1もしくは実施の形態2の図15構成と同様である。以降、実施の形態1もしくは実施の形態2と同様の部分は、説明を省略する。ルーティングの説明次に、図19、図20、図21を用いて、実施の形態3におけるルーティングモデルを説明する。図19は、即時更新サービスルーティングの例を示す図である。図20は、一括更新サービスルーティングの例を示す図である。図21は、競合制御部呼び出しが追加されたルーティングの例を示す図である。実施の形態3において、ルーティング定義部111a図1もしくは図15は、図3のルーティング定義画面300のパレット302の中のその他からサービス領域を選択している点が実施の形態1もしくは実施の形態2とは異なる。具体的には、ルーティング定義部111aは図19の更新サービスAT612から更新サービスCT613までをサービスセットR61aとして定義している。また、ルーティング定義部111aは図20の一括更新サービスAT622から一括更新サービスCT624までをサービスセットR62aとして定義している。これらのサービスセットは、サービス間の競合が判定される時、単一のサービスごとではなく、複数のサービスセットを単位として、同時実行時の競合を制御される場合にルーティング定義部111aが指定する領域である。この領域内に指定されたサービスは、すべてのリソースへのアクセスを同時に行い、リソースへのアクセスを一括で行うものと見なして、サービスセット間の競合判定が行われる。図21に示すルーティングは、図19に示す即時更新サービスルーティングR61に対して、競合制御機能挿入部113が競合制御部呼び出しロジックを挿入した後のルーティングのフローである。競合制御呼び出しinT91aと競合制御呼び出しoutT92aについては、実施の形態1と同様であるが、サービスセットR61aの前後に競合制御呼び出しinT91bと競合制御呼び出しoutT92bとが挿入されている点が、実施の形態1と異なる。すなわち、ルーティング定義情報112a図21の生成において、競合制御機能挿入部113は、定義情報設定部111が設定したルーティングに対して、同時実行時の競合を制御する単位として指定したサービスセットの領域の前後に、競合制御部132を呼び出すためのロジックを挿入する。サービス実行ステップの説明競合制御呼び出しinT91bにおいて、競合判定部133は、更新サービスAT612から更新サービスCT614の全てが実行可能か否かを実施の形態1もしくは実施の形態2と同様の方法で判定する。更新サービスAT612から更新サービスCT614のいずれかが実行不可能な場合、競合判定部133は、更新サービスAT612から更新サービスCT614のいずれもが実行不可能と判定する。すなわち競合判定部133は、サービスセットR61aの実行が不可能と判定し、サービスセットR61aの処理待ちの制御を行う。すなわち、ルーティング定義部111aは、サービスセットR61aに含まれるサービスを互いに関連付けられているサービスとして定義する。そして、競合判定部133は、サービスセットR61aに含まれるサービスの起動を禁止する場合に、起動を禁止されたサービスにサービスセットR61aとして関連付けられている他のソフトウェアの起動も禁止する。実施の形態3の効果実施の形態3におけるサービス実行管理システム100は、実施の形態1と実施の形態2との効果に加え、サービス単体ではなく、ルーティング上の複数サービスのセットを単位として競合を制御することが出来る。実施の形態3においては、一連のサービスの処理フローを表すルーティング上で、処理フローのサブセットであるサービスセットを単位として定義し、定義されたサービスセットの前後に実行制御を行うコンポーネントを埋め込むことで、ルーティング実行時にサービスセット単位の競合制御を行うサービス管理方式について説明した。実施の形態4.サービス実行管理システム100の概要図22は、サービス実行管理システム100の構成の例を示す図である。実施の形態4のサービス実行管理システム100は、実施の形態2の構成図15に比べ、開発サーバ110の定義情報設定部111にサービスコンテナ定義部1411が追加されている。そして、開発サーバ110の定義情報記憶部112にサービスコンテナ定義情報1412が追加されている。更に、サービス実行サーバがサービス実行サーバ130aとサービス実行サーバ130bとの2台になっている。ここで、サービス実行サーバ130の数は、2台に限られるものでは無い。また、実施の形態1と同様にサービスリソース関係抽出手段定義部1413、サービスリソース関係抽出手段定義情報1414、サービスリソース関係抽出部1431は無くても良い。その他は、実施の形態1~3のサービス実行管理システム100と同様の構成である。以降、実施の形態1~3と同様の部分は、説明を省略する。サービスコンテナ定義部1411は、サービスコンテナに関する情報を定義するもので、例えば入力端末105からサービスコンテナ定義画面後述の表示要求があると、サービスコンテナ定義画面後述を入力端末105のディスプレイ図示は省略に表示する。そして、サービスコンテナ定義部1411は、サービスコンテナ定義画面後述上で、サービスコンテナの定義を受け付けて、その定義内容を示すサービスコンテナ定義情報1412を出力する。そして、定義情報記憶部112は、出力されたサービスコンテナ定義情報1412を一時的に記憶する。ルーティング設計ステップの説明サービスコンテナ定義部1411を用いた定義情報の作成は、図2で示したルーティング設計S21ステップ上で行う。図23は、ルーティング定義画面300の例を示す図である。実施の形態1~3との相違点は、パレット302のその他に各サービスが配置されるサービスコンテナを指定する要素が追加された点である。これにより、ルーティングの各サービスが実行されるサービスコンテナを指定することができる。図24は、サービスコンテナ定義画面1500の例を示す図である。サービスコンテナ定義画面1500は、サービスコンテナ定義情報1412を定義することのできる画面である。サービスコンテナ定義画面1500は、定義されたサービスコンテナ定義の一覧を表示するサービスコンテナ定義テーブル1501、サービスコンテナ定義テーブル1501に定義情報を追加する追加ボタン403と、指定した値で定義を更新する更新ボタン404、サービスコンテナ定義テーブル1501に含まれている定義を削除する削除ボタン402から構成されている。サービスコンテナ定義情報1412は、サービスコンテナを識別するコンテナ識別名1505、サービスコンテナの種別であるコンテナタイプ1506、サービスコンテナの管理対象のURLである管理URL1507などが指定される。定義情報の説明図25はアクセスポリシー定義情報112cの例を示す図である。図26は、サービスコンテナ定義情報1412の例を示す図である。実施の形態4におけるアクセスポリシー定義情報112cは、実施の形態1で説明したアクセスポリシー定義情報112cの例図10に加えて、スコープ1805が追加されている。このスコープ1805は、サービスが利用するリソースがサービスコンテナごとに独立しているのか、それとも複数サービスコンテナをまたがって利用されるのかを表している。図25の例では、リソースタイプ411がローカルファイルのリソースは、スコープ1805がローカルであり、異なるサービスコンテナ間では、競合しない。すなわち、スコープ1805がローカルのリソースは、異なるサービスコンテナ毎に備えられている。サービスコンテナ定義情報1412は、前述で説明の通り、コンテナ識別名1505、コンテナタイプ1506、管理URL1507から構成される。サービスコンテナ定義情報1412は図2のS22に示すデプロイステップにおいて、定義情報格納部122に記憶される。アクセスポリシー定義情報112cも実施の形態1と同様に定義情報格納部122に記憶される。サービス実行ステップの説明図27は、競合制御部呼び出しinの処理を示すフローチャートである。図28は、競合制御部呼び出しoutの処理を示すフローチャートである。サービス実行ステップにおいて、実施の形態4のサービス実行管理システム100は、図27に示すS191における処理以外は、実施の形態1~3のサービス実行管理システム100と同様の処理を行う。例えば、実施の形態4のサービス実行管理システム100は図27のS102において実施の形態1のようにサービスリソース関係定義情報112bからリソースを特定しても良いし、実施の形態2のようにサービスリソース関係抽出部1431を用いてリソースを特定しても良い。また、実施の形態4のサービス実行管理システム100はサービス毎に競合判定をしても良いし、サービスセット毎に競合判定をしても良い。図27に示すS191において、競合制御部132は、ルーティング定義情報112aに定義された各サービスが実行されるサービスコンテナ131を特定する。そして、例えばサービス実行サーバ130の記憶装置図示は省略は、競合制御部132が特定したサービスコンテナ131の情報を記憶する。そして、図27のS103において、競合状態管理部134は、実行中のサービスと新たに実行されるサービスとが同じリソースを利用するか否かを判定する。そして、実行中のサービスと新たに実行されるサービスとが同じリソース識別名のリソースを利用する場合を想定する。この場合、実施の形態1では、同時利用リソースが有ると判定されたS103のYes。一方、実施の形態4においては、実行中のサービスと新たに実行されるサービスとが異なるサービスコンテナ131で実行され、かつ、いずれかのサービスが利用するリソースのスコープ1805がローカルである場合には、競合状態管理部134は、同時利用リソースが無いと判定するS103のNo。すなわち、実施の形態4のサービス実行管理システム100は、利用するリソースのスコープ1805がローカルである場合には、サービスコンテナ131毎に、サービスの競合判定を行う。図28については、実施の形態1で説明の図14と同様である為、説明を省略する。ここでは、計算機が例えばサービスコンテナのような仮想計算機を想定し、サービスコンテナ毎にリソースが備えられており、サービスコンテナ毎に競合判定される例を説明した。しかし、例えばリソースがサービス実行サーバ130毎に備えられていれば、現実の計算機であるサービス実行サーバ130毎に競合判定を行なっても良い。実施の形態4の効果実施の形態4におけるサービス実行管理システム100は、実施の形態1と実施の形態2と実施の形態3との効果に加え、サービスコンテナの情報を定義し、サービスリソースがどのサービスコンテナ上に配置されているかを考慮することで、複数サービスコンテナをまたがってサービス同士の競合関係を管理することが可能とする。実施の形態4においては、サービスとそのサービスが配置されたサービスコンテナの関係を定義し、関係定義に基づいてサービスコンテナを考慮したサービスリソース間の関係から、サービスコンテナごとのサービス間の競合関係を判定するサービス実行管理方式について説明した。最後に、実施の形態1~4に示した入力端末105、DBサーバ120、サービス実行サーバ130、開発サーバ110のハードウェア構成例について説明する。図29は、実施の形態1~4に示した入力端末105、DBサーバ120、サービス実行サーバ130、開発サーバ110のハードウェア資源の一例を示す図である。なお、図29の構成は、あくまでも入力端末105、DBサーバ120、サービス実行サーバ130、開発サーバ110のハードウェア構成の一例を示すものであり、入力端末105、DBサーバ120、サービス実行サーバ130、開発サーバ110のハードウェア構成は図29に記載の構成に限らず、他の構成であってもよい。図29において、入力端末105、DBサーバ120、サービス実行サーバ130、開発サーバ110は、プログラムを実行するCPU911CentralProcessingUnit、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいうを備えている。CPU911は、バス912を介して、例えば、ROMReadOnlyMemory913、RAMRandomAccessMemory914、通信ボード915、表示装置901、キーボード902、マウス903、磁気ディスク装置920と接続され、これらのハードウェアデバイスを制御する。更に、CPU911は、FDD904FlexibleDiskDrive、コンパクトディスク装置905CDDと接続していてもよい。また、磁気ディスク装置920の代わりに、SSDSolidStateDrive、光ディスク装置、メモリカード登録商標読み書き装置などの記憶装置でもよい。RAM914は、揮発性メモリの一例である。ROM913、FDD904、CDD905、磁気ディスク装置920の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。実施の形態1~4で説明した実行時情報記憶部121、定義情報格納部122、サービス実行サーバ130の記憶装置図示は省略、定義情報記憶部112は、RAM914、磁気ディスク装置920等により実現される。通信ボード915、キーボード902、マウス903、FDD904などは、入力装置の一例である。また、通信ボード915、表示装置901などは、出力装置の一例である。実施の形態1~4で説明した入力端末105のディスプレイは、表示装置901等により実現される。通信ボード915は、図1、図15、図22に示すネットワーク150に接続されている。例えば、ネットワーク150は、LAN、インターネットの他、WANワイドエリアネットワーク、SANストレージエリアネットワークなどでも構わない。磁気ディスク装置920には、オペレーティングシステム921OS、ウィンドウシステム922、プログラム群923、ファイル群924が記憶されている。プログラム群923のプログラムは、CPU911がオペレーティングシステム921、ウィンドウシステム922を利用しながら実行する。また、RAM914には、CPU911に実行させるオペレーティングシステム921のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、RAM914には、CPU911による処理に必要な各種データが格納される。また、ROM913には、BIOSBasicInputOutputSystemプログラムが格納され、磁気ディスク装置920にはブートプログラムが格納されている。入力端末105、DBサーバ120、サービス実行サーバ130、開発サーバ110の起動時には、ROM913のBIOSプログラム及び磁気ディスク装置920のブートプログラムが実行され、BIOSプログラム及びブートプログラムによりオペレーティングシステム921が起動される。上記プログラム群923には、実施の形態1~4の説明において~部~記憶部及び~格納部以外、以下同様として説明している機能を実行するプログラムが記憶されている。プログラムは、CPU911により読み出され実行される。ファイル群924には、実施の形態1~4の説明において、~の判断、~の計算、~の比較、~の照合、~の参照、~の検索、~の抽出、~の検査、~の生成、~の設定、~の登録、~の選択、~の入力、~の受信、~の接続、~の作成、~の挿入、~の判定等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、ファイルやデータベースの各項目として記憶されている。ファイルやデータベースは、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してCPU911によりメインメモリやキャッシュメモリに読み出される。そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出検索参照比較演算計算処理編集出力印刷表示移動挿入呼び出し制御判定許可禁止識別などのCPUの動作に用いられる。抽出検索参照比較演算計算処理編集出力印刷表示移動挿入呼び出し制御判定許可禁止識別などのCPUの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。また、実施の形態1~4で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。データや信号値は、RAM914のメモリ、FDD904のフレキシブルディスク、CDD905のコンパクトディスク、磁気ディスク装置920の磁気ディスク、その他光ディスク、ミニディスク、DVD等の記録媒体に記録される。また、データや信号は、バス912や信号線やケーブルその他の伝送媒体によりオンライン伝送される。また、実施の形態1~4の説明において~部として説明しているものは、~回路、~装置、~機器であってもよく、また、~ステップ、~手順、~処理であってもよい。すなわち、実施の形態1~4で説明したフローチャートに示すステップ、手順、処理により、本発明に係るサービス実行管理方法ソフトウェア実行方法を実現することができる。また、~部として説明しているものは、ROM913に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子デバイス基板配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、DVD等の記録媒体に記憶される。プログラムはCPU911により読み出され、CPU911により実行される。すなわち、プログラムは、実施の形態1~4の~部としてコンピュータを機能させるものである。あるいは、実施の形態1~4の~部の手順や方法をコンピュータに実行させるものである。このように、実施の形態1~4に示す入力端末105、DBサーバ120、サービス実行サーバ130、開発サーバ110は、処理装置たるCPU、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。そして、上記したように~部として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。