ソフトウェア実行システムおよびソフトウェア実行方法およびプログラム
【課題】複数のサービスを同時に実行するシステムにおいて、複数のサービスが同じリソースを同時に利用する場合に、サービスの競合を管理する為、個々のサービス同士に対して競合可否条件を定義する必要があった。
【解決手段】競合状態管理部１３４は、異なるサービスが同じリソースを利用して動作するか否かを判定する。そして、同じリソースを利用すると判定された場合、競合判定部１３３は、異なるサービスがリソースを利用する際の利用モードに基づき、異なるサービスの競合可否を判定する。そして、サービス実行管理システム１００は、個々のサービス同士に対する競合可否条件の定義することなく、サービスの競合を管理可能とする。
【解決手段】競合状態管理部１３４は、異なるサービスが同じリソースを利用して動作するか否かを判定する。そして、同じリソースを利用すると判定された場合、競合判定部１３３は、異なるサービスがリソースを利用する際の利用モードに基づき、異なるサービスの競合可否を判定する。そして、サービス実行管理システム１００は、個々のサービス同士に対する競合可否条件の定義することなく、サービスの競合を管理可能とする。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数のソフトウェアの競合を管理して実行するソフトウェア実行システムおよびソフトウェア実行方法およびプログラムに関する。
【背景技術】
【０００２】
近年、企業の統合・再編や企業内の組織変更の増加などに伴い、企業間や企業内のシステムを容易に連携させるための技術として、ＳＯＡ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）技術が利用されている。ＳＯＡ技術とは、ソフトウェアの機能を業務処理やプロセスの単位でまとめたサービスアプリケーションをネットワーク経由で相互に連携させることによって、システムを構築する技術である。サービスアプリケーションとしてまとめられた機能は、再利用が容易になり、開発コストの削減に繋げることができる。
【０００３】
ここで、ＳＯＡ技術において用いられるソフトウェアをサービスアプリケーションとも称する。すなわち、サービスアプリケーションはソフトウェアに対応する。なお、サービスアプリケーションは、以降「サービス」とも表記する。
また、サービスはリソースを利用して動作する。ここで、リソースとは、サービスが利用する例えばデータベースなどの情報源が挙げられる。リソースは、サービスリソースとも称する。
【０００４】
また、ＳＯＡ技術の１つの実現手段としてＥＳＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ Ｂｕｓ）というサービス連携基盤技術がある。これは、サービス同士をつなぐバスを実現する基盤であり、バスにはフォーマット変換やルーティング機能が含まれる。このサービス連携基盤の利用によって、サービスの組み合わせを自由に変更することが可能となる。ＥＳＢを用いて実現したシステムは、機能追加やフォーマットの変更がサービス自体を変更せずに実現することができる。
【０００５】
サービスは、前記のようなＥＳＢやＡＰサーバ（アプリケーションサーバ）といったサービスコンテナ上に配備されて実行される。そして、サービスコンテナは、複数のサービスが混在することが多くなり、新たにサービスを構築・提供する場合、既存のサービスとの競合が問題となる。ここで、サービスコンテナは、サービスの配備や起動・停止を制御する基本的な管理機能を提供しているが、サービス同士の競合を制御・管理する機能は有していない。
【０００６】
サービスコンテナは、サービス同士の競合を防ぐため、サービスの実行時にサービス同士が同時に実行できるかを判定し、判定の結果に応じて同時にサービスが実行されないよう制御する必要がある。
例えばすべてのサービス呼び出しの前段に中継サーバを配置することで、サービスの実行状況を監視可能な構成とし、サービス同士が同時に呼び出し可能か否かを判断するサービス競合可否条件を用いて、サービスへのリクエストに対して許可・不許可を判断することでサービスの同時実行を防ぐ方式がある（例えば特許文献１）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１０−２２００１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１の方式は、個々のサービス同士に対してサービス競合可否条件を定義する必要があり、サービス数が多くなると定義しなければならない情報が膨大となり、定義コストが大きくなってしまう。すなわち、サービスの競合関係をすべてのサービス間について定義するのでは、多数のサービスを管理する場合に、サービスの追加・変更の度に多大なコストを要してしまうことになる。このため、サービスの追加・変更時にも、既存サービスとの個々の関係を定義することなく、競合を排除できる仕組みが必要である。また、特許文献１の方式は、ＷＥＢ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サービスのようにＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）で中継可能なサービスしか対象にできないため、ＥＳＢ上のあらゆるサービスに適用できるわけではない点も問題がある。
【０００９】
この発明は前記のような課題を解決することを主な目的とするもので、例えば、全てのソフトウェア（サービス）同士の間の競合可否条件を定義することなく、ソフトウェア（サービス）の競合を管理するシステムを実現することを主な目的とする。
【課題を解決するための手段】
【００１０】
この発明に係るソフトウェア実行システムは、
第１のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第２のソフトウェアが前記第１のソフトウェアが利用している利用中リソースを利用して動作するか否かを判定するリソース判定部と、
前記リソース判定部により前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、前記第２のソフトウェアの前記利用中リソースの利用モードを判定し、前記第１のソフトウェアの前記利用中リソースの利用モードと前記第２のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第２のソフトウェアの起動の許否を判定する起動許否判定部と
を備えることを特徴とする。
【発明の効果】
【００１１】
この発明に係るソフトウェア実行システムは、ソフトウェア（サービス）間でリソースを共用する場合に、各ソフトウェア（サービス）が共用するリソースの利用モードに基づき、競合可否を判定する。よって、この発明に係るソフトウェア実行システムは、全てのソフトウェア（サービス）同士の間の競合可否条件を定義することなく、ソフトウェア（サービス）の競合を管理することが出来る。
【図面の簡単な説明】
【００１２】
【図１】実施の形態１を示す図で、サービス実行管理システム（ソフトウェア実行システム）の構成を示す図。
【図２】実施の形態１を示す図で、サービス実行管理システム１００の処理の概略を示すフローチャート。
【図３】実施の形態１を示す図で、ルーティング定義画面３００の例を示す図。
【図４】実施の形態１を示す図で、アクセスポリシー定義画面４００の例を示す図。
【図５】実施の形態１を示す図で、サービスリソース関係定義画面５００の例を示す図。
【図６】実施の形態１を示す図で、即時更新サービスルーティングの例を示す図。
【図７】実施の形態１を示す図で、一括更新サービスルーティングの例を示す図。
【図８】実施の形態１を示す図で、競合制御部呼び出しが追加されたルーティングの例を示す図。
【図９】実施の形態１を示す図で、サービスリソース関係定義情報１１２ｂの例を示す図。
【図１０】実施の形態１を示す図で、アクセスポリシー定義情報１１２ｃの例を示す図。
【図１１】実施の形態１を示す図で、条件情報１４００の例を示す図である。
【図１２】実施の形態１を示す図で、サービスリソース利用状態１２１ａの例を示す図。
【図１３】実施の形態１を示す図で、競合制御部呼び出し（ｉｎ）の処理を示すフローチャート。
【図１４】実施の形態１を示す図で、競合制御部呼び出し（ｏｕｔ）の処理を示すフローチャート。
【図１５】実施の形態２を示す図で、サービス実行管理システム１００の構成の例を示す図。
【図１６】実施の形態２を示す図で、サービスリソース関係抽出手段定義画面１６００の例を示す図。
【図１７】実施の形態２を示す図で、サービスリソース関係定義情報１１２ｂの例を示す図。
【図１８】実施の形態２を示す図で、サービスリソース関係抽出手段定義情報１４１４の例を示す図。
【図１９】実施の形態３を示す図で、即時更新サービスルーティングの例を示す図。
【図２０】実施の形態３を示す図で、一括更新サービスルーティングの例を示す図。
【図２１】実施の形態３を示す図で、競合制御部呼び出しが追加されたルーティングの例を示す図。
【図２２】実施の形態４を示す図で、サービス実行管理システム１００の構成の例を示す図。
【図２３】実施の形態４を示す図で、ルーティング定義画面３００の例を示す図。
【図２４】実施の形態４を示す図で、サービスコンテナ定義画面１５００の例を示す図。
【図２５】実施の形態４を示す図で、アクセスポリシー定義情報１１２ｃの例を示す図。
【図２６】実施の形態４を示す図で、サービスコンテナ定義情報１４１２の例を示す図。
【図２７】実施の形態４を示す図で、競合制御部呼び出し（ｉｎ）の処理を示すフローチャート。
【図２８】実施の形態４を示す図で、競合制御部呼び出し（ｏｕｔ）の処理を示すフローチャート。
【図２９】実施の形態１〜４を示す図で、入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０のハードウェア資源の一例を示す図。
【発明を実施するための形態】
【００１３】
実施の形態１．
（サービス実行管理システム（ソフトウェア実行システム）の概要）
図１は、サービス実行管理システム（ソフトウェア実行システム）の構成の例を示す図である。
ここで、サービス実行管理システム１００は、ソフトウェア実行システムに対応する。
そして、前述の通り、サービスは、ソフトウェアに対応する。
また、サービスは前述の通りＳＯＡにおけるサービスアプリケーションであっても良い。
【００１４】
サービス実行管理システム１００は、入力端末１０５、開発サーバ１１０、ＤＢサーバ１２０、サービス実行サーバ１３０から構成される。
ここで、ＤＢサーバ１２０は、データベースサーバのことである。
入力端末１０５、開発サーバ１１０、ＤＢサーバ１２０、サービス実行サーバ１３０等は、例えば、ＬＡＮやインターネットなどのネットワーク１５０に接続されている。
以下、入力端末１０５、開発サーバ１１０、ＤＢサーバ１２０、サービス実行サーバ１３０を個別に説明する。
【００１５】
（入力端末１０５の説明）
入力端末１０５は、例えばパソコンなどから構成されており、業務システムを連携するサービスやルーティングの開発者が、設計・開発作業を行う際に使用する端末である。（以降、業務システムを連携するサービスやルーティングの開発者を「開発者」と称する。）
【００１６】
（ＤＢサーバ１２０の説明）
ＤＢサーバ１２０は、各種の情報を保管する記憶装置であり、例えば、開発サーバ１１０で作成された定義情報を定義情報格納部１２２で格納する。定義情報とは、ルーティング定義情報１１２ａ、サービスリソース関係定義情報１１２ｂ、アクセスポリシー定義情報１１２ｃである。
ここで、定義情報格納部１２２は、条件情報（後述）を記憶する条件情報記憶部とリソース情報（後述）を記憶するリソース情報記憶部とに対応する。
また、定義情報の一部はサービスコンテナ１３１から情報の直接参照が必要な場合は、サービス実行サーバ１３０が備える記憶装置（図示は省略）に記憶されても良い。
【００１７】
（サービス実行サーバ１３０の説明）
サービス実行サーバ１３０は、開発サーバ１１０により開発された一連のサービスやルーティングを実行するサーバである。サービス実行サーバ１３０は、サービスを実行するサービスコンテナ１３１、サービスの競合発生時にサービスの一時停止などの制御を行う競合制御部１３２、競合制御部１３２から呼び出される競合判定部１３３、競合状態管理部１３４、サービスリソース特定部１３５から構成される。
ここで、サービスコンテナ１３１は計算機に対応する。すなわち、前述のようにサービスコンテナ１３１は、ＥＳＢやアプリケーションサーバなどの機能を持つ計算機もしくは仮想計算機であると言える。
また、競合判定部１３３は、起動許否判定部に対応し、競合状態管理部１３４はリソース判定部に対応する。
【００１８】
（開発サーバ１１０の説明）
開発サーバ１１０は、業務システムの連携やサービス間の競合管理に必要となる定義情報を開発するためのサーバである。定義情報設定部１１１は、例えば各種の情報を入力するキーボードやマウスなどのマンマシンインタフェース、あるいは、入力端末１０５で入力された各種の情報をネットワーク経由で取得するネットワークインタフェースなどから構成されている。そして、定義情報設定部１１１は、入力した情報から定義情報（ルーティング定義情報１１２ａ、サービスリソース関係定義情報１１２ｂ、アクセスポリシー定義情報１１２ｃ）を設定して、定義情報記憶部１１２に一時的に格納する処理を実施する。
ここで、サービスリソース関係定義情報１１２ｂは、リソース情報に対応する。
【００１９】
定義情報設定部１１１のルーティング定義部１１１ａは、例えば入力端末１０５からルーティング定義画面（後述）の表示要求があると、ルーティング定義画面（後述）を入力端末１０５のディスプレイ（図示は省略）に表示する。そして、ルーティング定義部１１１ａは、ルーティング定義画面（後述）上で、ルーティングを構成する一連のサービスの定義を受け付けて、その定義内容を示すルーティング定義情報１１２ａを出力する。そして、定義情報記憶部１１２は、出力されたルーティング定義情報１１２ａを一時的に記憶する。
【００２０】
このとき、競合制御機能挿入部１１３は、ルーティング定義部１１１ａで作成したルーティング定義情報１１２ａに対して、各サービスの前後に競合制御部１３２を呼び出すロジックを挿入する。（後述の実施の形態３においては、競合制御機能挿入部１１３は、ルーティング定義部１１１ａで作成したルーティング定義情報１１２ａに対して、指定したサービスの集合であるサービスセットの前後に競合制御部１３２を呼び出すロジックを挿入する。）
これにより、サービスの開始時と終了時に競合制御部１３２を呼び出すことが可能となる。（後述の実施の形態３においては、サービスセットの開始時と終了時に競合制御部１３２を呼び出すことが可能となる。）
【００２１】
サービスリソース関係定義部１１１ｂは、例えば入力端末１０５からサービスリソース関係定義画面（後述）の表示要求があると、サービスリソース関係定義画面（後述）を入力端末１０５のディスプレイ（図示は省略）に表示する。そして、サービスリソース関係定義部１１１ｂは、サービスリソース関係定義画面（後述）上で、サービスリソース関係の定義を受け付けて、その定義内容を示すサービスリソース関係定義情報１１２ｂを出力する。そして、定義情報記憶部１１２は、出力されたサービスリソース関係定義情報１１２ｂを一時的に記憶する。
【００２２】
アクセスポリシー定義部１１１ｃは、例えば入力端末１０５からアクセスポリシー定義画面（後述）の表示要求があると、アクセスポリシー定義画面（後述）を入力端末１０５のディスプレイ（図示は省略）に表示する。そして、アクセスポリシー定義部１１１ｃは、アクセスポリシー定義画面（後述）上で、アクセスポリシー情報の定義を受け付けて、その定義内容を表すアクセスポリシー定義情報１１２ｃを出力する。そして、定義情報記憶部１１２は、出力されたアクセスポリシー定義情報１１２ｃを一時的に記憶する。
【００２３】
なお、定義情報設定部１１１は、各種の定義情報を設定した後、登録要求が入力端末１０５から入力されると、定義情報記憶部１１２が一時的に記憶している各種の定義情報をＤＢサーバ１２０の定義情報格納部１２２に移動する。そして、定義情報格納部１２２は移動された各種の定義情報を記憶する。ただし、定義情報（ルーティング定義情報１１２ａ、サービスリソース関係定義情報１１２ｂ、アクセスポリシー定義情報１１２ｃ）の一部は、サービスコンテナ１３１から直接、情報の参照が必要な場合は、サービス実行サーバ１３０が備える記憶装置（図示は省略）に記憶されても良い。
【００２４】
（サービス実行管理システム１００の処理の概略説明）
図２は、サービス実行管理システム１００の処理の概略を示すフローチャートである。
サービス実行管理システム１００におけるサービスルーティングの設計からサービス実行までの大まかな手順を説明する。
【００２５】
ルーティング設計ステップ（Ｓ２１）は、定義情報設定部１１１が各種の定義情報の作成を行い、定義情報に基づいてサービスコンテナ１３１がルーティングを実行するために必要となるルーティング定義情報１１２ａを作成するステップである。
【００２６】
ここで、ルーティング定義情報１１２ａの生成において、競合制御機能挿入部１１３は、定義情報設定部１１１が設定したルーティングに対して、同時実行時の競合を制御するサービスの前後に、競合制御部１３２を呼び出すためのロジックを挿入する。
【００２７】
デプロイステップ（Ｓ２２）は、作成された各種の定義情報（ルーティング定義情報１１２ａ、サービスリソース関係定義情報１１２ｂ、アクセスポリシー定義情報１１２ｃ）を定義情報格納部１２２に登録するステップである。
【００２８】
サービス実行ステップ（Ｓ２３）は、サービスコンテナ１３１から各種の定義情報を参照してサービスを実行するステップである。
【００２９】
（ルーティング設計ステップの説明）
ルーティング設計ステップ（Ｓ２１）における、各種の定義情報の作成画面を図３、図４、図５に示す。
【００３０】
図３はルーティング定義画面３００の例を示す図である。
入力端末１０５のディスプレイ（図示は省略）に表示されたルーティング定義画面３００により、開発者が入力した内容に基づいて、ルーティング定義部１１１ａは、パレット３０２の中の「ノードリスト」から所望のノード（サービス、分岐、開始、終了）を選択して、そのノードをキャンバス３０１に配置することができる。またルーティング定義部１１１ａは、パレット３０２の中の「接続」からエッジを選択して、各ノードをお互いに接続することで、サービスの呼び出しフローであるルーティングを作成することができる。
（また、実施の形態３において、ルーティング定義部１１１ａは、パレット３０２の中の「その他」から「サービス領域」を選択して、その領域の位置をパレット上のルーティングに対して指定することで、同時実行時の競合を制御する単位としてサービスセットを設定することができる。）
【００３１】
図４は、アクセスポリシー定義画面４００の例を示す図である。
アクセスポリシー定義画面４００は、開発者がアクセスポリシーを定義することができる画面である。アクセスポリシー定義画面４００は、定義済みのアクセスポリシー定義の一覧を表示するアクセスポリシー定義テーブル４０１、アクセスポリシー定義テーブル４０１にアクセスポリシー定義を追加する追加ボタン４０３、アクセスポリシー定義テーブル４０１に含まれている定義を削除する削除ボタン４０２、指定した値で定義を更新する更新ボタン４０４から構成されている。
アクセスポリシー定義は、リソースの種別を表すリソースタイプ４１１、アクセスポリシー間で競合の判定を行う判定ロジック４１２、リソースへのアクセスタイム４１３、アクセスポリシー４１４のそれぞれが指定される。
アクセスポリシー４１４は例えば「Ｃ」、「Ｒ」、「Ｕ」、「Ｄ」が指定される。ここで「Ｃ」、「Ｒ」、「Ｕ」、「Ｄ」は、データベースへのデータアクセスの形態を示し、それぞれＣｒｅａｔｅ・Ｒｅａｄ・Ｕｐｄａｔｅ・Ｄｅｌｅｔｅの意味を表している。
アクセスタイム４１３は、例えば、リソースへのアクセスのタイミングが「実行時」または「常時」から選択する。
【００３２】
図５は、サービスリソース関係定義画面５００の例を示す図である。
サービスリソース関係定義画面５００は、定義済みのサービスリソース関係定義情報１１２ｂの一覧を表すサービスリソース定義関係定義テーブル５０１と、サービスリソース定義関係定義テーブル５０１に定義情報を追加する追加ボタン４０３と、サービスリソース定義関係定義テーブル５０１に含まれている定義を削除する削除ボタン４０２、指定した値で定義を更新する更新ボタン４０４から構成されている。
サービスリソース関係定義情報１１２ｂは、ルーティング定義情報１１２ａで定義されているサービス識別名５１１、リソースの識別子であるリソース識別名５１２、アクセスポリシー定義情報１１２ｃで定義されたリソースタイプ４１１、アクセスポリシー４１４のそれぞれが指定される。
【００３３】
（ルーティングの説明）
次に、図６、図７、図８を用いて、サービスを実行するルーティングモデルを説明する。
図６は、即時更新サービスルーティングの例を示す図である。
図７は、一括更新サービスルーティングの例を示す図である。
図８は、競合制御部呼び出しが追加されたルーティングの例を示す図である。
【００３４】
即時更新サービスルーティング（Ｒ６１）は、ＨＴＴＰ受付１（Ｔ６１１）でＨＴＴＰリクエストを受信すると、更新サービスＡ（Ｔ６１２）、更新サービスＢ（Ｔ６１３）、更新サービスＣ（Ｔ６１４）、メール通知（Ｔ６１５）を順次呼び出すルーティングである。また、一括更新サービスルーティング（Ｒ６２）は、ＨＴＴＰ受付２（Ｔ６２１）でＨＴＴＰリクエストを受信し、一括更新サービスＡ〜Ｃ（Ｔ６２２〜Ｔ６２４）、メール通知２（Ｔ６２５）を順次呼び出すルーティングである。
図６と図７に示すルーティングは、ルーティング定義部１１１ａによって定義されたものである。
【００３５】
そして、図８に示すルーティングは、図６に示す即時更新サービスルーティングの例に競合制御機能挿入部１１３がルーティング設計ステップ（Ｓ２１）において、サービス毎の競合制御を実現するために必要となる競合制御部呼び出しロジックを挿入した後のルーティングのフローである。
図８に示すルーティングは、競合制御機能挿入部１１３によって、各サービスの前に競合制御呼び出し（ｉｎ）（Ｔ９１）が追加され、各サービスの後に競合制御呼び出し（ｏｕｔ）（Ｔ９２）が追加されている。
すなわち、図８に示すルーティングがルーティング定義情報１１２ａの具体例である。
なお、図７に示す一括更新サービスルーティングも図６に示す即時更新サービスルーティングと同様に競合制御機能挿入部１１３によって競合制御部呼び出しロジックが挿入されるが図示は省略する。
【００３６】
（定義情報の説明）
図９、図１０、図１１を用いて、サービス実行管理システム１００がサービス競合の管理を行うための定義情報のデータ構造の例を説明する。
図９は、サービスリソース関係定義情報１１２ｂの例を示す図である。
図１０は、アクセスポリシー定義情報１１２ｃの例を示す図である。
図１１は、条件情報１４００の例を示す図である。
【００３７】
サービスリソース関係定義情報１１２ｂ（図９）は、各ルーティングのサービスがどういったリソースをどう利用するかを示している。サービスとリソースの関係は、サービス識別名５１１、リソース識別名５１２でサービスとリソースの対応を表し、リソースの種別を表すリソースタイプ４１１、リソース利用時のポリシーとしてアクセスポリシー４１４を用いて定義される。
【００３８】
アクセスポリシー定義情報１１２ｃ（図１０）は、サービスが利用するリソース間の関係を判定するために必要となる。
アクセスポリシー定義情報１１２ｃは、リソースの種別を表すリソースタイプ４１１、アクセスポリシーの識別名を表すアクセスポリシー４１４、リソースアクセスのタイミングを表すアクセスタイム４１３、アクセスポリシー間の競合判定を行うロジックをあらわす判定ロジック４１２から構成される。
リソースタイプ４１１、アクセスポリシー４１４は、サービスリソース関係定義情報１１２ｂのリソースタイプ４１１、アクセスポリシー４１４に対応する。
また、判定ロジック４１２はリソースタイプ４１１毎に定義される。
そして、アクセスポリシー定義部１１１ｃは、新たにリソースタイプ４１１を定義する場合に、合わせて判定ロジック４１２を追加することで、競合判定の対象とするリソースタイプを任意に追加することが可能となる。
【００３９】
条件情報１４００（図１１）は、アクセスポリシー定義情報１１２ｃに示された判定ロジック４１２に対応する。
図１１の条件情報１４００は、ＤＢテーブルの判定ロジック４１２である「ＤＢＴａｂｌｅＰｏｌｉｃｙＣｏｍｐａｒａｔｏｒ」の例を示すものである。
図１１の条件情報１４００は、ＤＢテーブルのリソースポリシー同士の判定内容を示したものであり、判定時のリソースのアクセス状態１４０１と、比較対象のアクセスポリシーである比較ポリシー１４０２、競合可否１４０３の結果を記述している。また、条件情報１４００は、競合可否１４０３の結果が可であった場合には、アクセス状態がどのように変わるかを変更後状態１４０４として記述している。
【００４０】
ここで、アクセス状態１４０１は、サービスがリソースを利用する利用モードに対応する。
そして、アクセス状態１４０１は、先に動作している先行サービス（先行ソフトウェア）の利用モードに対応し、比較ポリシー１４０２は、後から起動される後続サービス（後続ソフトウェア）の利用モードに対応する。
そして、競合可否１４０３が「可」となるアクセス状態１４０１と比較ポリシー１４０２との組合せが同時利用許可条件に対応し、競合可否１４０３が「不可」となるアクセス状態１４０１と比較ポリシー１４０２との組合せが同時利用禁止条件に対応する。
【００４１】
サービスリソース関係定義情報１１２ｂとアクセスポリシー定義情報１１２ｃとから、サービスの実行時にサービスが利用するリソースの関係を条件情報１４００に基づいて判定することで、サービス間の競合を判断することが可能となる。
なお、これらの定義情報は、図２のＳ２２に示すデプロイステップにおいて、定義情報格納部１２２に記憶される。
サービス実行ステップにおける具体的な例を用いて以降に説明する。
【００４２】
（サービス実行ステップの説明）
図１２、図１３、図１４を用いてサービス実行ステップの具体例を説明する。
図１２は、サービスリソース利用状態１２１ａの例を示す図である。（（ａ）は一括サービスルーティング（Ｒ６２）が実行された場合、（ｂ）は更新サービスＡ（Ｔ６１２）が実行された場合、（ｃ）は競合制御呼び出し（ｏｕｔ）（Ｔ９２ｂ）が実行された場合）
図１３は、競合制御部呼び出し（ｉｎ）の処理を示すフローチャートである。
図１４は、競合制御部呼び出し（ｏｕｔ）の処理を示すフローチャートである。
【００４３】
サービス実行ステップの説明にあたり、サービスコンテナ１３１（図１）は、図７に示す一括サービスルーティング（Ｒ６２）を実行中であり、かつ、一括サービスルーティング（Ｒ６２）に含まれる全てのサービスがリソースを利用中であると想定する。ここで、一括サービスルーティング（Ｒ６２）以外のルーティングは実行されていないものとする。
そして、サービスコンテナ１３１は、実行中のサービスが利用中のリソースの情報を実行時情報記憶部１２１に出力する。そして、実行時情報記憶部１２１は実行中のサービスが利用中のリソースの情報をサービスリソース利用状態１２１ａとして記憶する。
【００４４】
例えば、サービスコンテナ１３１が図７の「ＨＴＴＰ受付２」（Ｔ６２１）を実行した場合、図９に示すようにサービス識別名５１１「ＨＴＴＰ受付２」のリソース識別名５１２は「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅａｌｌ／」である。また、「ＨＴＴＰ受付２」のリソースタイプ４１１は「ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）」であり、アクセスポリシーは「バインド」である。
サービスコンテナ１３１は、図９のサービスリソース関係定義情報１１２ｂを参照することにより、これらの情報を得ることも出来、また「ＨＴＴＰ受付２」のサービスを実行時に「ＨＴＴＰ受付２」のサービスからこれらの情報を得ることも出来る。
そして、サービスコンテナ１３１は、図１２（ａ）に示すようにリソース識別名５１２として「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅａｌｌ／」、リソースタイプ４１１として「ＵＲＬ」、アクセス状態１４０１として「バインド」を実行時情報記憶部１２１に出力する。
ここで、例えばリソース識別名５１２「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅａｌｌ／」は、「ＨＴＴＰ受付２」のサービスが利用中の利用中リソースに対応する。
【００４５】
同様に例えば、サービスコンテナ１３１が図７の「一括更新サービスＡ」（Ｔ６２２）を実行した場合、図９に示すようにサービス識別名５１１「一括更新サービスＡ」のリソース識別名５１２は「ＤＢ１／テーブルＡ」である。また、「一括更新サービスＡ」のリソースタイプ４１１は「ＤＢテーブル」であり、アクセスポリシーは「Ｕ」である。
そして、サービスコンテナ１３１は、図１２（ａ）に示すようにリソース識別名５１２として「ＤＢ１／テーブルＡ」、リソースタイプ４１１として「ＤＢテーブル」、アクセス状態１４０１として「Ｕ」を実行時情報記憶部１２１に出力する。
【００４６】
図７に示す「一括更新サービスＢ」（Ｔ６２３）、「一括更新サービスＣ」（Ｔ６２４）についても同様である為、説明を省略する。
【００４７】
実行時情報記憶部１２１は、サービスリソース利用状態１２１ａとして、リソース識別名５１２、リソースタイプ４１１、アクセス状態１４０１を記憶する。
ここで、リソース識別名５１２とリソースタイプ４１１とは、実行中のサービスが利用中であるリソースを特定する為の情報であり、前述のように図９のサービスリソース関係定義情報１１２ｂや図１０のアクセスポリシー定義情報１１２ｃで定義した内容に対応する。
アクセス状態１４０１は、サービスリソースがどのように利用されているかを表す項目である。
【００４８】
なお、図７に示す「メール通知２」（Ｔ６２５）は、他のサービスと共用するようなリソースを利用しない為に、サービスリソース利用状態１２１ａとして実行時情報記憶部１２１には記憶されない。
【００４９】
そして、サービスコンテナ１３１（図１）が、図７に示す一括サービスルーティング（Ｒ６２）を実行中に、新たに図６に示す即時更新サービスルーティング（Ｒ６１）を実行する場合を想定する。
一括サービスルーティング（Ｒ６２）の場合は、他のルーティングが実行されていなかった為に競合制御部呼び出しの説明を省略した。しかし、ここでは一括サービスルーティング（Ｒ６２）が既に実行中の場合を考える為に、競合制御部呼び出しが明記された図８に示す即時更新サービスルーティング（Ｒ６１）を用いて説明する。
【００５０】
（図８のＴ９１ａ〜Ｔ６１１における処理の説明）
サービスコンテナ１３１（図１）は、図８に示す即時更新サービスルーティング（Ｒ６１）の実行にあたり、最初に競合制御部呼び出し（ｉｎ）（Ｔ９１ａ）を実行し、競合制御部１３２（図１）を呼び出す。
競合制御部１３２は、サービス実行前にそのサービスが実行できるか判定を行い、処理待ちや処理継続の制御を行う。
【００５１】
ここで、競合制御部呼び出し（ｉｎ）における競合制御部１３２の動作を図１３のフローチャートで説明する。
まず、競合制御部１３２は、即時更新サービスルーティング（Ｒ６１）において、競合制御部１３２の処理開始のトリガーとなるメッセージをサービスコンテナ１３１から受信する（Ｓ１０１）。
【００５２】
そして、競合制御部１３２は、サービスリソース特定部１３５（図１）を呼び出す。サービスリソース特定部１３５は、ルーティング定義情報１１２ａに示されたサービスが利用するリソースを特定する（Ｓ１０２）。
具体的には、図８の競合制御部呼び出し（ｉｎ）（Ｔ９１ａ）に基づき呼び出されたサービスリソース特定部１３５は、ルーティング定義情報１１２ａにおける次の処理である図８に示す「ＨＴＴＰ受付１（Ｔ６１１）」のサービスが利用するリソースを特定する。
ここで、サービスリソース特定部１３５は、図９に示すサービスリソース関係定義情報１１２ｂを参照し、ルーティング定義情報１１２ａに示されたサービス識別名「ＨＴＴＰ受付１」に対応するリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」を特定する。
【００５３】
次に図１３に示すＳ１０３において、競合制御部１３２は、競合状態管理部１３４（図１）を呼び出す。
競合状態管理部１３４は、図１２（ａ）に示すサービスリソース利用状態１２１ａに、サービスリソース特定部１３５が特定したリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」が有るか否かを判定することにより、異なるサービス間で同時に利用される同時利用リソースが有るか否かを判定する。
そして、「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」がサービスリソース利用状態１２１ａに無いので、競合状態管理部１３４は同時利用リソースが無いと判定する（Ｓ１０３の「Ｎｏ」）。（Ｓ１０３の「Ｙｅｓ」の場合は、後述する。）
【００５４】
そして、競合制御部１３２はリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」の情報を実行時情報記憶部１２１に入力し、実行時情報記憶部１２１は、図１２（ｂ）に示すようにサービスリソース利用状態１２１ａとして記憶する（Ｓ１０７）。
【００５５】
ここで、競合制御部１３２は例えばサービス実行サーバ１３０の記憶装置（図示は省略）にサービスリソース利用状態１２１ａが更新される前の状態を記憶することが可能である。すなわち、競合制御部１３２は、リソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」の情報を新たに入力する前は、サービスリソース利用状態１２１ａにリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」の情報が無かった状態（すなわち図１２（ａ）の状態）を記憶することが可能である。
【００５６】
最後に競合制御部１３２は、サービスの処理開始のトリガーとなるメッセージを次のサービス（すなわち図８の「ＨＴＴＰ受付１（Ｔ６１１）」）に転送する（Ｓ１０６）。
【００５７】
（図８のＴ９２ａにおける処理の説明）
サービスコンテナ１３１は、図８の「ＨＴＴＰ受付１（Ｔ６１１）」の処理を終了後、図８の「競合制御部呼び出し（ｏｕｔ）（Ｔ９２ａ）」を実行し、競合制御部１３２（図１）を呼び出す。
【００５８】
ここで、競合制御部呼び出し（ｏｕｔ）における競合制御部１３２の動作を図１４のフローチャートで説明する。
まず、競合制御部１３２は、即時更新サービスルーティング（Ｒ６１）において、競合制御部１３２の処理開始のトリガーとなるメッセージをサービスコンテナ１３１から受信する（Ｓ１１１）。
【００５９】
そして、図１３のＳ１０２と同様に競合制御部１３２は、サービスリソース特定部１３５（図１）を呼び出す。サービスリソース特定部１３５は、ルーティング定義情報１１２ａに示されたサービスが利用するリソースを特定する（Ｓ１１２）。
具体的には、図８の競合制御部呼び出し（ｏｕｔ）（Ｔ９２ａ）に基づき呼び出されたサービスリソース特定部１３５は、ルーティング定義情報１１２ａにおける前の処理である図８に示す「ＨＴＴＰ受付１（Ｔ６１１）」のサービスが利用するリソースを特定する。
ここで、サービスリソース特定部１３５は、図９に示すサービスリソース関係定義情報１１２ｂを参照し、ルーティング定義情報１１２ａに示されたサービス識別名「ＨＴＴＰ受付１」に対応するリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」を特定する。
【００６０】
図１４のＳ１１３において、競合制御部１３２は、サービス実行サーバ１３０の記憶装置（図示は省略）に記憶されたサービスリソース利用状態１２１ａが、ルーティング定義情報１１２ａ上で直前の競合制御部呼び出し（ｉｎ）によって更新される前の状態に戻す。
すなわち、競合制御部１３２は、図１３のＳ１０７において記憶したサービスリソース利用状態１２１ａにリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」の情報が無かった状態（すなわち図１２（ａ）の状態）に戻す。あるいは、競合制御部１３２は、サービスリソース利用状態１２１ａにリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」の情報としては残しておいて、アクセス状態１４０１を「バインド」から「なし」に変更することも可能である（図１２（ｃ））。
ここでは、「ＨＴＴＰ受付１（Ｔ６１１）」のサービスの実行が完了し、競合制御部１３２は、サービスリソースをサービスが利用中の状態から解放する処理を行っている。
【００６１】
最後に競合制御部１３２は、サービスの処理開始のトリガーとなるメッセージを次のサービス（すなわち図８の「競合制御部呼び出し（ｉｎ）（Ｔ９１ｂ）」）に転送する（Ｓ１１４）。
【００６２】
（図８のＴ９１ｂにおける処理の説明）
図８の「競合制御部呼び出し（ｉｎ）（Ｔ９１ｂ）」では、Ｔ９１ａと同様に競合制御部１３２を呼び出す。
そして、同様にサービスリソース特定部１３５が呼び出され、サービスリソース特定部１３５は、図８に示す「更新サービスＡ」（Ｔ６１２）」のサービスが利用するリソースを特定する。
ここで、サービスリソース特定部１３５は、図９に示すサービスリソース関係定義情報１１２ｂを参照し、ルーティング定義情報１１２ａに示されたサービス識別名「更新サービスＡ」に対応するリソース識別名「ＤＢ１／テーブルＡ」を特定する。
【００６３】
次に図１３に示すＳ１０３において、競合状態管理部１３４は、図１２（ｃ）に示すサービスリソース利用状態１２１ａに、サービスリソース特定部１３５が特定したリソース識別名「ＤＢ１／テーブルＡ」が有るか否かを判定することにより、異なるサービス間で同時に利用される同時利用リソースが有るか否かを判定する。
すなわち、競合状態管理部１３４は、第１のサービス「一括更新サービスＡ」がアクセス状態「Ｕ」（所定の利用モード）で「ＤＢ１／テーブルＡ」（所定のリソース）を利用して動作している場合に、新たに起動される第２のサービス「更新サービスＡ」が第１のサービス「一括更新サービスＡ」が利用している「ＤＢ１／テーブルＡ」（利用中リソース）を利用して動作するか否かを判定する。
そして、「ＤＢ１／テーブルＡ」がサービスリソース利用状態１２１ａに有るので、競合状態管理部１３４は同時利用リソースが有ると判定する（Ｓ１０３の「Ｙｅｓ」）。
【００６４】
そして、図１３に示すＳ１０４において、競合制御部１３２は、競合判定部１３３を呼び出す。競合判定部１３３は、サービスリソース関係定義情報１１２ｂのアクセスポリシー４１４と、サービスリソース利用状態１２１ａのアクセス状態１４０１とを参照する。すなわち、競合判定部１３３は、図９に示す「更新サービスＡ」のアクセスポリシー４１４「Ｒ」と、図１２に示す「ＤＢ１／テーブルＡ」のアクセス状態１４０１「Ｕ」とを参照する。
【００６５】
また、競合判定部１３３は、図９に示す「更新サービスＡ」のリソースタイプ４１１「ＤＢテーブル」を参照し、図１０に示すアクセスポリシー定義情報１１２ｃの「ＤＢテーブル」に対応する判定ロジック４１２「ＤＢＴａｂｌｅＰｏｌｉｃｙＣｏｍｐａｒａｔｏｒ」を参照する。
そして、競合判定部１３３は、「ＤＢＴａｂｌｅＰｏｌｉｃｙＣｏｍｐａｒａｔｏｒ」に対応する図１１の条件情報１４００を用いて、「更新サービスＡ」が「ＤＢ１／テーブルＡ」を利用可能か否か判定する。
すなわち、競合判定部１３３は、競合状態管理部１３４により第２のサービス「更新サービスＡ」が「ＤＢ１／テーブルＡ」（利用中リソース）を利用して動作すると判定された場合に、第２のサービス「更新サービスＡ」の「ＤＢ１／テーブルＡ」（利用中リソース）の利用モードを判定し、第１のサービス「一括更新サービスＡ」の「ＤＢ１／テーブルＡ」（利用中リソース）の利用モードと第２のサービス「更新サービスＡ」の「ＤＢ１／テーブルＡ」（利用中リソース）の利用モードとに基づき、第２のサービス「更新サービスＡ」の起動の許否を判定する。
【００６６】
図１１の条件情報１４００において、アクセス状態１４０１が「Ｕ」で（図１２に示す「ＤＢ１／テーブルＡ」のアクセス状態１４０１「Ｕ」に対応）、比較ポリシー１４０２が「Ｒ」（図９に示す「更新サービスＡ」のアクセスポリシー４１４「Ｒ」に対応）の場合の競合可否１４０３は「可」である。
よって、競合判定部１３３は、「更新サービスＡ」が「ＤＢ１／テーブルＡ」を利用可能と判定する（図１３のＳ１０４の「Ｎｏ」）。すなわち、競合判定部１３３は、「更新サービスＡ」の起動を許可する。
また、競合判定部１３３は、競合制御部１３２に競合可否１４０３が「可」であることと、図１１に示す変更後状態１４０４が「Ｃ」であることを通知する。
これは、他のサービスがデータベースに対し「Ｕｐｄａｔｅ」のアクセス形態で利用中であっても、新たなサービスが「Ｒｅａｄ」のアクセス形態であるならば同じリソースを利用可能であることを意味する。
【００６７】
一方、例えば、アクセス状態１４０１が「Ｃ」で、比較ポリシー１４０２も「Ｃ」の場合は、競合可否１４０３は「不可」である。これは異なるサービス同士が同じリソースに対して「Ｃｒｅａｔｅ」のアクセス形態では利用出来ないことを意味する。
このような場合、競合判定部１３３は、リソースの同時利用が出来ないと判定し（図１３のＳ１０４の「Ｙｅｓ」）、実行中のサービスが終了してリソースを解放するのを待つ（図１３のＳ１０８）。すなわち新たに実行されるサービスは処理待ちとなる。つまり、競合判定部１３３は、新たに実行されるサービス（後続ソフトウェア）の起動を禁止する。
そして、実行中のサービスが終了してリソースを解放後に、競合判定部１３３は、再度、図１３のＳ１０３において新たに実行されるサービスについて判定を行う。
アクセス状態１４０１と比較ポリシー１４０２とが「Ｕ」同士、「Ｄ」同士の場合も同様である。
【００６８】
競合判定部１３３が、「更新サービスＡ」が「ＤＢ１／テーブルＡ」を利用可能と判定した場合（図１３のＳ１０４の「Ｎｏ」）、図１３のＳ１０５において、競合制御部１３２は、まず現在のサービスリソース利用状態１２１ａを例えばサービス実行サーバ１３０の記憶装置（図示は省略）に記憶する。
すなわち、競合制御部１３２は、図１２（ｃ）に示すリソース識別名「ＤＢ１／テーブルＡ」のアクセス状態が「Ｕ」であったことを記憶装置に記憶する。
【００６９】
次に、競合制御部１３２は、実行時情報記憶部１２１が記憶しているサービスリソース利用状態１２１ａのリソース識別名「ＤＢ１／テーブルＡ」のアクセス状態を「Ｃ」に変更する（図１３のＳ１０５、図１２（ｄ））。
【００７０】
最後に競合制御部１３２は、サービスの処理開始のトリガーとなるメッセージを次のサービス（すなわち図８の「更新サービスＡ（Ｔ６１２）」）に転送する（Ｓ１０６）。
【００７１】
（図８のＴ９２ｂにおける処理の説明）
サービスコンテナ１３１は、図８の「更新サービスＡ（Ｔ６１２）」の処理を終了後、図８の「競合制御部呼び出し（ｏｕｔ）（Ｔ９２ｂ）」を実行し、競合制御部１３２（図１）を呼び出す。
【００７２】
図８のＴ９２ａの説明と同様に、図１３のＳ１１３において、競合制御部１３２は、サービス実行サーバ１３０の記憶装置（図示は省略）に記憶されたサービスリソース利用状態１２１ａが、ルーティング定義情報１１２ａ上で直前の競合制御部呼び出し（ｉｎ）によって更新される前の状態に戻す。
すなわち、競合制御部１３２は、リソース識別名５１２「ＤＢ１／テーブルＡ」のアクセス状態１４０１を「Ｃ」から「Ｕ」に戻す（図１２（ｃ））。
【００７３】
最後に競合制御部１３２は、サービスの処理開始のトリガーとなるメッセージを次のサービスに転送し、サービスコンテナ１３１はルーティングを継続する。以降の処理は同様である為、説明を省略する。
なお、本例では、２つのルーティング（即時更新サービスルーティングＲ６１と一括更新サービスルーティングＲ６２）が同時に実行される場合を説明したが、同時に実行されるルーティングの数は２つに限られず、実際には多数のルーティングが同時に実行される。
【００７４】
（実施の形態１の効果）
実施の形態１におけるサービス実行管理システム１００は、サービスがリソースを利用する場合のアクセス状態の関係に基づきサービスの競合判定を行うことで、全てのサービス間の競合可否条件の定義を不要とすることが可能である。
すなわち、全てのサービス間の競合可否条件の定義をすることなく、アクセス状態間の競合可否条件のみを定義することで、サービス実行管理システム１００は、同時に実行出来ないサービスを判定し、同時に実行出来ないと判定されたサービスを待機状態にすることで、サービスの競合を管理することが可能である。
【００７５】
実施の形態１においては、業務システムを連携するサービス実行基盤において、サービスとそのサービスが利用するサービスリソース間の関係を定義し、その関係定義に基づいてサービスリソースの利用関係からサービス間の競合関係を判定するサービス実行管理方式について説明した。また、サービスとサービスリソース間の利用関係にポリシーを定義し、サービスリソースの競合可否をポリシーにしたがって判定するサービス実行管理方式について説明した。
【００７６】
実施の形態２．
（サービス実行管理システム１００の概要）
図１５は、サービス実行管理システム１００の構成の例を示す図である。
実施の形態２のサービス実行管理システム１００は実施の形態１のサービス実行管理システム１００に比べ、開発サーバ１１０の定義情報設定部１１１にサービスリソース関係抽出手段定義部１４１３が追加されている。そして、開発サーバ１１０の定義情報記憶部１１２にサービスリソース関係抽出手段定義情報１４１４が追加されている。更に、サービス実行サーバ１３０にサービスリソース関係抽出部１４３１が追加されている。その他は、実施の形態１のサービス実行管理システム１００と同様の構成である。
以降、実施の形態１と同様の部分は、説明を省略する。
【００７７】
サービスリソース関係抽出手段定義部１４１３は、サービスとリソース間の関係を抽出するための手段を定義するもので、例えば入力端末１０５からサービスリソース関係抽出手段定義画面（後述）の表示要求があると、サービスリソース関係抽出手段定義画面（後述）を入力端末１０５のディスプレイ（図示は省略）に表示する。そして、サービスリソース関係抽出手段定義部１４１３は、サービスリソース関係抽出手段定義画面（後述）上で、サービスとリソース間の関係を抽出する手段の定義を受け付けて、その定義内容を表すサービスリソース関係抽出手段定義情報１４１４を出力する。そして、定義情報記憶部１１２は出力されたサービスリソース関係抽出手段定義情報１４１４を一時的に記憶する。
【００７８】
実施の形態２のサービス実行管理システム１００も実施の形態１と同様に図２に示すフローチャートに従って処理を進める。
【００７９】
（ルーティング設計ステップの説明）
サービスリソース関係抽出手段定義部１４１３を用いた定義情報の作成は、図２で示したルーティング設計（Ｓ２１）ステップ上で行う。
図１６は、サービスリソース関係抽出手段定義画面１６００の例を示す図である。
サービスリソース関係抽出手段定義画面１６００は、サービス実行時にサービスリソース関係定義情報１１２ｂを抽出する手段を表したサービスリソース関係抽出手段定義情報１４１４を定義することのできる画面である。サービスリソース関係抽出手段定義画面１６００は、定義済みのサービスリソース関係抽出手段定義の一覧を表示するサービスリソース関係抽出手段定義テーブル１６０１、サービスリソース関係抽出手段定義テーブル１６０１に定義情報を追加する追加ボタン４０３、指定した値で定義を更新する更新ボタン４０４、サービスリソース関係抽出手段定義テーブル１６０１に含まれている定義を削除する削除ボタン４０２から構成されている。
サービスリソース関係抽出手段定義情報１４１４は、抽出手段を識別する名称として手段識別名１６０５、サービスとリソース関係とを抽出する手段の対象となるリソースの種別を表すリソースタイプ４１１、そして実際にどのようにサービスとリソース関係を抽出するかを表した抽出手段１６０７が指定される。抽出手段１６０７は、例えば、Ｊａｖａ（登録商標）などのプログラムによって作成した抽出ロジックを表したもので、そのプログラムを呼び出すために必要となるクラス名などを指定する。
【００８０】
（定義情報の説明）
図１７は、サービスリソース関係定義情報１１２ｂの例を示す図である。
図１８は、サービスリソース関係抽出手段定義情報１４１４の例を示す図である。
実施の形態２におけるサービスリソース関係定義情報１１２ｂのデータ構造は図９に示す実施の形態１のサービスリソース関係定義情報１１２ｂと同じであるが、サービスリソース関係定義部１１１ｂは、サービス識別名５１１とリソースタイプ４１１のみ定義し、リソース識別名５１２、アクセスポリシー４１４は、定義しない。
サービスリソース関係抽出手段定義情報１４１４は、前述で説明の通り、手段識別名１６０５、リソースタイプ４１１、抽出手段１６０７から構成される。
サービスリソース関係抽出手段定義情報１４１４は図２のＳ２２に示すデプロイステップにおいて、定義情報格納部１２２に記憶される。
サービスリソース関係定義情報１１２ｂも実施の形態１と同様に定義情報格納部１２２に記憶される。
【００８１】
（サービス実行ステップの説明）
サービス実行ステップにおいて、実施の形態２のサービス実行管理システム１００は、図１３に示すＳ１０２における処理以外は、実施の形態１のサービス実行管理システム１００と同様の処理を行う。
図１３に示すＳ１０２における実施の形態２のサービス実行管理システム１００の処理を説明する。
図１３に示すＳ１０２は、実施の形態１と同様にルーティング上のサービスが利用するサービスリソースを特定するステップである。
まず、競合制御部１３２（図１５）は、実施の形態１と同様にサービスリソース特定部１３５（図１５）を呼び出す。そして、サービスリソース特定部１３５は、実施の形態１と同様にルーティング定義情報１１２ａに示されたサービスが利用するリソースを特定する為に、サービスリソース関係定義情報１１２ｂを参照する。
【００８２】
ここで、サービスリソース関係定義情報１１２ｂにリソース識別名５１２とアクセスポリシー４１４とが定義されていない場合、サービスリソース特定部１３５はサービスリソース関係抽出部１４３１を呼び出す。
サービスリソース関係抽出部１４３１は、サービスリソース関係抽出手段定義情報１４１４を参照し、サービスリソース関係定義情報１１２ｂに定義されたリソースタイプに応じた抽出手段を用いてサービスが利用するリソースを特定する。
【００８３】
例えば、サービスが利用するリソースタイプが「ＤＢテーブル」であれば、抽出手段「ＤＢＡｃｃｅｓｓＡｎａｌｙｚｅｒ」は、サービスが実行前に利用するＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）文を解析する。そして、抽出手段「ＤＢＡｃｃｅｓｓＡｎａｌｙｚｅｒ」は、そのＳＱＬ文のタイプ（ＩＮＳＥＲＴ文、ＳＥＬＥＣＴ文、ＵＰＤＡＴＥ文、ＤＥＬＥＴＥ文）をアクセスポリシー「Ｃ」、「Ｒ」、「Ｕ」、「Ｄ」に対応付ける。また、抽出手段「ＤＢＡｃｃｅｓｓＡｎａｌｙｚｅｒ」は、ＳＱＬ文のテーブル名から対象のリソース識別名を抽出することが出来る。
ここで、ＳＱＬ文は、サービスがリソースを利用する際に出力するコマンドに対応する。
【００８４】
サービスリソース特定部１３５は抽出手段が抽出したリソース識別名とアクセスポリシーを用いて、サービス識別名に対応するリソース識別名を特定する。
【００８５】
（実施の形態２の効果）
実施の形態２におけるサービス実行管理システム１００は、サービスリソース関係抽出手段を定義しておくことで、実施の形態１の効果に加え、サービス実行時にサービスが利用するリソースを抽出することが可能となる。すなわち、実施の形態２におけるサービス実行管理システム１００は、サービス実行時に実施の形態１におけるサービスリソース関係定義情報１１２ｂに相当する内容を抽出することが可能となる。そして、実施の形態２におけるサービス実行管理システム１００は、実行時にサービスが利用するリソースが変化する場合にもサービスの競合判定を行うことが可能となる。
【００８６】
実施の形態２においては、サービスとそのサービスが利用するサービスリソース間の関係定義について、サービス実行時に、そのサービスが利用するサービスリソースを自動で抽出する手段を定義し、サービスとサービスリソース間の関係を手動で定義することなく、サービス間の競合を判定するサービス管理方式について説明した。
【００８７】
実施の形態３．
（サービス実行管理システム１００の概要）
実施の形態３のサービス実行管理システム１００は、実施の形態１の構成（図１）もしくは実施の形態２の（図１５）構成と同様である。
以降、実施の形態１もしくは実施の形態２と同様の部分は、説明を省略する。
【００８８】
（ルーティングの説明）
次に、図１９、図２０、図２１を用いて、実施の形態３におけるルーティングモデルを説明する。
図１９は、即時更新サービスルーティングの例を示す図である。
図２０は、一括更新サービスルーティングの例を示す図である。
図２１は、競合制御部呼び出しが追加されたルーティングの例を示す図である。
【００８９】
実施の形態３において、ルーティング定義部１１１ａ（図１もしくは図１５）は、図３のルーティング定義画面３００のパレット３０２の中の「その他」から「サービス領域」を選択している点が実施の形態１もしくは実施の形態２とは異なる。
具体的には、ルーティング定義部１１１ａは図１９の「更新サービスＡ」（Ｔ６１２）から「更新サービスＣ」（Ｔ６１３）までをサービスセットＲ６１ａとして定義している。また、ルーティング定義部１１１ａは図２０の「一括更新サービスＡ」（Ｔ６２２）から「一括更新サービスＣ」（Ｔ６２４）までをサービスセットＲ６２ａとして定義している。
【００９０】
これらのサービスセットは、サービス間の競合が判定される時、単一のサービスごとではなく、複数のサービスセットを単位として、同時実行時の競合を制御される場合にルーティング定義部１１１ａが指定する領域である。この領域内に指定されたサービスは、すべてのリソースへのアクセスを同時に行い、リソースへのアクセスを一括で行うものと見なして、サービスセット間の競合判定が行われる。
【００９１】
図２１に示すルーティングは、図１９に示す即時更新サービスルーティングＲ６１に対して、競合制御機能挿入部１１３が競合制御部呼び出しロジックを挿入した後のルーティングのフローである。
「競合制御呼び出し（ｉｎ）（Ｔ９１ａ）」と「競合制御呼び出し（ｏｕｔ）（Ｔ９２ａ）」については、実施の形態１と同様であるが、サービスセットＲ６１ａの前後に「競合制御呼び出し（ｉｎ）（Ｔ９１ｂ）」と「競合制御呼び出し（ｏｕｔ）（Ｔ９２ｂ）」とが挿入されている点が、実施の形態１と異なる。
すなわち、ルーティング定義情報１１２ａ（図２１）の生成において、競合制御機能挿入部１１３は、定義情報設定部１１１が設定したルーティングに対して、同時実行時の競合を制御する単位として指定したサービスセットの領域の前後に、競合制御部１３２を呼び出すためのロジックを挿入する。
【００９２】
（サービス実行ステップの説明）
「競合制御呼び出し（ｉｎ）（Ｔ９１ｂ）」において、競合判定部１３３は、「更新サービスＡ（Ｔ６１２）」から「更新サービスＣ（Ｔ６１４）」の全てが実行可能か否かを実施の形態１もしくは実施の形態２と同様の方法で判定する。
「更新サービスＡ（Ｔ６１２）」から「更新サービスＣ（Ｔ６１４）」のいずれかが実行不可能な場合、競合判定部１３３は、「更新サービスＡ（Ｔ６１２）」から「更新サービスＣ（Ｔ６１４）」のいずれもが実行不可能と判定する。すなわち競合判定部１３３は、サービスセットＲ６１ａの実行が不可能と判定し、サービスセットＲ６１ａの処理待ちの制御を行う。
【００９３】
すなわち、ルーティング定義部１１１ａは、サービスセットＲ６１ａに含まれるサービスを互いに関連付けられているサービスとして定義する。そして、競合判定部１３３は、サービスセットＲ６１ａに含まれるサービスの起動を禁止する場合に、起動を禁止されたサービスにサービスセットＲ６１ａとして関連付けられている他のソフトウェアの起動も禁止する。
【００９４】
（実施の形態３の効果）
実施の形態３におけるサービス実行管理システム１００は、実施の形態１と実施の形態２との効果に加え、サービス単体ではなく、ルーティング上の複数サービスのセットを単位として競合を制御することが出来る。
【００９５】
実施の形態３においては、一連のサービスの処理フローを表すルーティング上で、処理フローのサブセットであるサービスセットを単位として定義し、定義されたサービスセットの前後に実行制御を行うコンポーネントを埋め込むことで、ルーティング実行時にサービスセット単位の競合制御を行うサービス管理方式について説明した。
【００９６】
実施の形態４．
（サービス実行管理システム１００の概要）
図２２は、サービス実行管理システム１００の構成の例を示す図である。
実施の形態４のサービス実行管理システム１００は、実施の形態２の構成（図１５）に比べ、開発サーバ１１０の定義情報設定部１１１にサービスコンテナ定義部１４１１が追加されている。そして、開発サーバ１１０の定義情報記憶部１１２にサービスコンテナ定義情報１４１２が追加されている。更に、サービス実行サーバがサービス実行サーバ１３０ａとサービス実行サーバ１３０ｂとの２台になっている。ここで、サービス実行サーバ１３０の数は、２台に限られるものでは無い。
また、実施の形態１と同様にサービスリソース関係抽出手段定義部１４１３、サービスリソース関係抽出手段定義情報１４１４、サービスリソース関係抽出部１４３１は無くても良い。
その他は、実施の形態１〜３のサービス実行管理システム１００と同様の構成である。以降、実施の形態１〜３と同様の部分は、説明を省略する。
【００９７】
サービスコンテナ定義部１４１１は、サービスコンテナに関する情報を定義するもので、例えば入力端末１０５からサービスコンテナ定義画面（後述）の表示要求があると、サービスコンテナ定義画面（後述）を入力端末１０５のディスプレイ（図示は省略）に表示する。そして、サービスコンテナ定義部１４１１は、サービスコンテナ定義画面（後述）上で、サービスコンテナの定義を受け付けて、その定義内容を示すサービスコンテナ定義情報１４１２を出力する。そして、定義情報記憶部１１２は、出力されたサービスコンテナ定義情報１４１２を一時的に記憶する。
【００９８】
（ルーティング設計ステップの説明）
サービスコンテナ定義部１４１１を用いた定義情報の作成は、図２で示したルーティング設計（Ｓ２１）ステップ上で行う。
図２３は、ルーティング定義画面３００の例を示す図である。
実施の形態１〜３との相違点は、パレット３０２の「その他」に各サービスが配置されるサービスコンテナを指定する要素が追加された点である。これにより、ルーティングの各サービスが実行されるサービスコンテナを指定することができる。
【００９９】
図２４は、サービスコンテナ定義画面１５００の例を示す図である。
サービスコンテナ定義画面１５００は、サービスコンテナ定義情報１４１２を定義することのできる画面である。サービスコンテナ定義画面１５００は、定義されたサービスコンテナ定義の一覧を表示するサービスコンテナ定義テーブル１５０１、サービスコンテナ定義テーブル１５０１に定義情報を追加する追加ボタン４０３と、指定した値で定義を更新する更新ボタン４０４、サービスコンテナ定義テーブル１５０１に含まれている定義を削除する削除ボタン４０２から構成されている。
サービスコンテナ定義情報１４１２は、サービスコンテナを識別するコンテナ識別名１５０５、サービスコンテナの種別であるコンテナタイプ１５０６、サービスコンテナの管理対象のＵＲＬである管理ＵＲＬ１５０７などが指定される。
【０１００】
（定義情報の説明）
図２５はアクセスポリシー定義情報１１２ｃの例を示す図である。
図２６は、サービスコンテナ定義情報１４１２の例を示す図である。
実施の形態４におけるアクセスポリシー定義情報１１２ｃは、実施の形態１で説明したアクセスポリシー定義情報１１２ｃの例（図１０）に加えて、スコープ１８０５が追加されている。このスコープ１８０５は、サービスが利用するリソースがサービスコンテナごとに独立しているのか、それとも複数サービスコンテナをまたがって利用されるのかを表している。図２５の例では、リソースタイプ４１１が「ローカルファイル」のリソースは、スコープ１８０５が「ローカル」であり、異なるサービスコンテナ間では、競合しない。すなわち、スコープ１８０５が「ローカル」のリソースは、異なるサービスコンテナ毎に備えられている。
サービスコンテナ定義情報１４１２は、前述で説明の通り、コンテナ識別名１５０５、コンテナタイプ１５０６、管理ＵＲＬ１５０７から構成される。
サービスコンテナ定義情報１４１２は図２のＳ２２に示すデプロイステップにおいて、定義情報格納部１２２に記憶される。
アクセスポリシー定義情報１１２ｃも実施の形態１と同様に定義情報格納部１２２に記憶される。
【０１０１】
（サービス実行ステップの説明）
図２７は、競合制御部呼び出し（ｉｎ）の処理を示すフローチャートである。
図２８は、競合制御部呼び出し（ｏｕｔ）の処理を示すフローチャートである。
サービス実行ステップにおいて、実施の形態４のサービス実行管理システム１００は、図２７に示すＳ１９１における処理以外は、実施の形態１〜３のサービス実行管理システム１００と同様の処理を行う。
例えば、実施の形態４のサービス実行管理システム１００は図２７のＳ１０２において実施の形態１のようにサービスリソース関係定義情報１１２ｂからリソースを特定しても良いし、実施の形態２のようにサービスリソース関係抽出部１４３１を用いてリソースを特定しても良い。また、実施の形態４のサービス実行管理システム１００はサービス毎に競合判定をしても良いし、サービスセット毎に競合判定をしても良い。
【０１０２】
図２７に示すＳ１９１において、競合制御部１３２は、ルーティング定義情報１１２ａに定義された各サービスが実行されるサービスコンテナ１３１を特定する。そして、例えばサービス実行サーバ１３０の記憶装置（図示は省略）は、競合制御部１３２が特定したサービスコンテナ１３１の情報を記憶する。
【０１０３】
そして、図２７のＳ１０３において、競合状態管理部１３４は、実行中のサービスと新たに実行されるサービスとが同じリソースを利用するか否かを判定する。
そして、実行中のサービスと新たに実行されるサービスとが同じリソース識別名のリソースを利用する場合を想定する。この場合、実施の形態１では、同時利用リソースが有ると判定された（Ｓ１０３の「Ｙｅｓ」）。一方、実施の形態４においては、実行中のサービスと新たに実行されるサービスとが異なるサービスコンテナ１３１で実行され、かつ、いずれかのサービスが利用するリソースのスコープ１８０５が「ローカル」である場合には、競合状態管理部１３４は、同時利用リソースが無いと判定する（Ｓ１０３の「Ｎｏ」）。
すなわち、実施の形態４のサービス実行管理システム１００は、利用するリソースのスコープ１８０５が「ローカル」である場合には、サービスコンテナ１３１毎に、サービスの競合判定を行う。
図２８については、実施の形態１で説明の図１４と同様である為、説明を省略する。
【０１０４】
ここでは、計算機が例えばサービスコンテナのような仮想計算機を想定し、サービスコンテナ毎にリソースが備えられており、サービスコンテナ毎に競合判定される例を説明した。しかし、例えばリソースがサービス実行サーバ１３０毎に備えられていれば、現実の計算機であるサービス実行サーバ１３０毎に競合判定を行なっても良い。
【０１０５】
（実施の形態４の効果）
実施の形態４におけるサービス実行管理システム１００は、実施の形態１と実施の形態２と実施の形態３との効果に加え、サービスコンテナの情報を定義し、サービスリソースがどのサービスコンテナ上に配置されているかを考慮することで、複数サービスコンテナをまたがってサービス同士の競合関係を管理することが可能とする。
【０１０６】
実施の形態４においては、サービスとそのサービスが配置されたサービスコンテナの関係を定義し、関係定義に基づいてサービスコンテナを考慮したサービスリソース間の関係から、サービスコンテナごとのサービス間の競合関係を判定するサービス実行管理方式について説明した。
【０１０７】
最後に、実施の形態１〜４に示した入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０のハードウェア構成例について説明する。
図２９は、実施の形態１〜４に示した入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０のハードウェア資源の一例を示す図である。
なお、図２９の構成は、あくまでも入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０のハードウェア構成の一例を示すものであり、入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０のハードウェア構成は図２９に記載の構成に限らず、他の構成であってもよい。
【０１０８】
図２９において、入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１〜４で説明した実行時情報記憶部１２１、定義情報格納部１２２、サービス実行サーバ１３０の記憶装置（図示は省略）、定義情報記憶部１１２は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１などは、出力装置の一例である。実施の形態１〜４で説明した入力端末１０５のディスプレイは、表示装置９０１等により実現される。
【０１０９】
通信ボード９１５は、図１、図１５、図２２に示すネットワーク１５０に接続されている。
例えば、ネットワーク１５０は、ＬＡＮ、インターネットの他、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などでも構わない。
【０１１０】
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
【０１１１】
また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
【０１１２】
また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
【０１１３】
上記プログラム群９２３には、実施の形態１〜４の説明において「〜部」（「〜記憶部」及び「〜格納部」以外、以下同様）として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
【０１１４】
ファイル群９２４には、実施の形態１〜４の説明において、「〜の判断」、「〜の計算」、「〜の比較」、「〜の照合」、「〜の参照」、「〜の検索」、「〜の抽出」、「〜の検査」、「〜の生成」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の入力」、「〜の受信」、「〜の接続」、「〜の作成」、「〜の挿入」、「〜の判定」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「ファイル」や「データベース」の各項目として記憶されている。
「ファイル」や「データベース」は、ディスクやメモリなどの記録媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示・移動・挿入・呼び出し・制御・判定・許可・禁止・識別などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示・移動・挿入・呼び出し・制御・判定・許可・禁止・識別などのＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜４で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【０１１５】
また、実施の形態１〜４の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態１〜４で説明したフローチャートに示すステップ、手順、処理により、本発明に係るサービス実行管理方法（ソフトウェア実行方法）を実現することができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、実施の形態１〜４の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１〜４の「〜部」の手順や方法をコンピュータに実行させるものである。
【０１１６】
このように、実施の形態１〜４に示す入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【符号の説明】
【０１１７】
１００ サービス実行管理システム、１０５ 入力端末、１１０ 開発サーバ、１１１ 定義情報設定部、１１１ａ ルーティング定義部、１１１ｂ サービスリソース関係定義部、１１１ｃ アクセスポリシー定義部、１１２ 定義情報記憶部、１１２ａ ルーティング定義情報、１１２ｂ サービスリソース関係定義情報、１１２ｃ アクセスポリシー定義情報、１１３ 競合制御機能挿入部、１２０ ＤＢサーバ、１２１ 実行時情報記憶部、１２１ａ サービスリソース利用状態、１２２ 定義情報格納部、１３０ サービス実行サーバ、１３１ サービスコンテナ、１３２ 競合制御部、１３３ 競合判定部、１３４ 競合状態管理部、１３５ サービスリソース特定部、１５０ ネットワーク、３００ ルーティング定義画面、３０１ キャンバス、３０２ パレット、４００ アクセスポリシー定義画面、４０１ アクセスポリシー定義テーブル、４０２ 削除ボタン、４０３ 追加ボタン、４０４ 更新ボタン、４１１ リソースタイプ、４１２ 判定ロジック、４１３ アクセスタイム、４１４ アクセスポリシー、５００ サービスリソース関係定義画面、５０１ サービスリソース定義関係定義テーブル、５１１ サービス識別名、５１２ リソース識別名、９０１ 表示装置、９０２ キーボード、９０３ マウス、９０４ ＦＤＤ、９０５ コンパクトディスク装置、９１１ ＣＰＵ、９１２ バス、９１３ ＲＯＭ、９１４ ＲＡＭ、９１５ 通信ボード、９２０ 磁気ディスク装置、９２１ オペレーティングシステム、９２２ ウィンドウシステム、９２３ プログラム群、９２４ ファイル群、１４００ 条件情報、１４０１ アクセス状態、１４０２ 比較ポリシー、１４０３ 競合可否、１４０４ 変更後状態、１４１１ サービスコンテナ定義部、１４１２ サービスコンテナ定義情報、１４１３ サービスリソース関係抽出手段定義部、１４１４ サービスリソース関係抽出手段定義情報、１４３１ サービスリソース関係抽出部、１５００ サービスコンテナ定義画面、１５０１ サービスコンテナ定義テーブル、１５０５ コンテナ識別名、１５０６ コンテナタイプ、１５０７ 管理ＵＲＬ、１６００ サービスリソース関係抽出手段定義画面、１６０１ サービスリソース関係抽出手段定義テーブル、１６０５ 手段識別名、１６０７ 抽出手段、１８０５ スコープ。
【技術分野】
【０００１】
この発明は、複数のソフトウェアの競合を管理して実行するソフトウェア実行システムおよびソフトウェア実行方法およびプログラムに関する。
【背景技術】
【０００２】
近年、企業の統合・再編や企業内の組織変更の増加などに伴い、企業間や企業内のシステムを容易に連携させるための技術として、ＳＯＡ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）技術が利用されている。ＳＯＡ技術とは、ソフトウェアの機能を業務処理やプロセスの単位でまとめたサービスアプリケーションをネットワーク経由で相互に連携させることによって、システムを構築する技術である。サービスアプリケーションとしてまとめられた機能は、再利用が容易になり、開発コストの削減に繋げることができる。
【０００３】
ここで、ＳＯＡ技術において用いられるソフトウェアをサービスアプリケーションとも称する。すなわち、サービスアプリケーションはソフトウェアに対応する。なお、サービスアプリケーションは、以降「サービス」とも表記する。
また、サービスはリソースを利用して動作する。ここで、リソースとは、サービスが利用する例えばデータベースなどの情報源が挙げられる。リソースは、サービスリソースとも称する。
【０００４】
また、ＳＯＡ技術の１つの実現手段としてＥＳＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ Ｂｕｓ）というサービス連携基盤技術がある。これは、サービス同士をつなぐバスを実現する基盤であり、バスにはフォーマット変換やルーティング機能が含まれる。このサービス連携基盤の利用によって、サービスの組み合わせを自由に変更することが可能となる。ＥＳＢを用いて実現したシステムは、機能追加やフォーマットの変更がサービス自体を変更せずに実現することができる。
【０００５】
サービスは、前記のようなＥＳＢやＡＰサーバ（アプリケーションサーバ）といったサービスコンテナ上に配備されて実行される。そして、サービスコンテナは、複数のサービスが混在することが多くなり、新たにサービスを構築・提供する場合、既存のサービスとの競合が問題となる。ここで、サービスコンテナは、サービスの配備や起動・停止を制御する基本的な管理機能を提供しているが、サービス同士の競合を制御・管理する機能は有していない。
【０００６】
サービスコンテナは、サービス同士の競合を防ぐため、サービスの実行時にサービス同士が同時に実行できるかを判定し、判定の結果に応じて同時にサービスが実行されないよう制御する必要がある。
例えばすべてのサービス呼び出しの前段に中継サーバを配置することで、サービスの実行状況を監視可能な構成とし、サービス同士が同時に呼び出し可能か否かを判断するサービス競合可否条件を用いて、サービスへのリクエストに対して許可・不許可を判断することでサービスの同時実行を防ぐ方式がある（例えば特許文献１）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１０−２２００１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１の方式は、個々のサービス同士に対してサービス競合可否条件を定義する必要があり、サービス数が多くなると定義しなければならない情報が膨大となり、定義コストが大きくなってしまう。すなわち、サービスの競合関係をすべてのサービス間について定義するのでは、多数のサービスを管理する場合に、サービスの追加・変更の度に多大なコストを要してしまうことになる。このため、サービスの追加・変更時にも、既存サービスとの個々の関係を定義することなく、競合を排除できる仕組みが必要である。また、特許文献１の方式は、ＷＥＢ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サービスのようにＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）で中継可能なサービスしか対象にできないため、ＥＳＢ上のあらゆるサービスに適用できるわけではない点も問題がある。
【０００９】
この発明は前記のような課題を解決することを主な目的とするもので、例えば、全てのソフトウェア（サービス）同士の間の競合可否条件を定義することなく、ソフトウェア（サービス）の競合を管理するシステムを実現することを主な目的とする。
【課題を解決するための手段】
【００１０】
この発明に係るソフトウェア実行システムは、
第１のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第２のソフトウェアが前記第１のソフトウェアが利用している利用中リソースを利用して動作するか否かを判定するリソース判定部と、
前記リソース判定部により前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、前記第２のソフトウェアの前記利用中リソースの利用モードを判定し、前記第１のソフトウェアの前記利用中リソースの利用モードと前記第２のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第２のソフトウェアの起動の許否を判定する起動許否判定部と
を備えることを特徴とする。
【発明の効果】
【００１１】
この発明に係るソフトウェア実行システムは、ソフトウェア（サービス）間でリソースを共用する場合に、各ソフトウェア（サービス）が共用するリソースの利用モードに基づき、競合可否を判定する。よって、この発明に係るソフトウェア実行システムは、全てのソフトウェア（サービス）同士の間の競合可否条件を定義することなく、ソフトウェア（サービス）の競合を管理することが出来る。
【図面の簡単な説明】
【００１２】
【図１】実施の形態１を示す図で、サービス実行管理システム（ソフトウェア実行システム）の構成を示す図。
【図２】実施の形態１を示す図で、サービス実行管理システム１００の処理の概略を示すフローチャート。
【図３】実施の形態１を示す図で、ルーティング定義画面３００の例を示す図。
【図４】実施の形態１を示す図で、アクセスポリシー定義画面４００の例を示す図。
【図５】実施の形態１を示す図で、サービスリソース関係定義画面５００の例を示す図。
【図６】実施の形態１を示す図で、即時更新サービスルーティングの例を示す図。
【図７】実施の形態１を示す図で、一括更新サービスルーティングの例を示す図。
【図８】実施の形態１を示す図で、競合制御部呼び出しが追加されたルーティングの例を示す図。
【図９】実施の形態１を示す図で、サービスリソース関係定義情報１１２ｂの例を示す図。
【図１０】実施の形態１を示す図で、アクセスポリシー定義情報１１２ｃの例を示す図。
【図１１】実施の形態１を示す図で、条件情報１４００の例を示す図である。
【図１２】実施の形態１を示す図で、サービスリソース利用状態１２１ａの例を示す図。
【図１３】実施の形態１を示す図で、競合制御部呼び出し（ｉｎ）の処理を示すフローチャート。
【図１４】実施の形態１を示す図で、競合制御部呼び出し（ｏｕｔ）の処理を示すフローチャート。
【図１５】実施の形態２を示す図で、サービス実行管理システム１００の構成の例を示す図。
【図１６】実施の形態２を示す図で、サービスリソース関係抽出手段定義画面１６００の例を示す図。
【図１７】実施の形態２を示す図で、サービスリソース関係定義情報１１２ｂの例を示す図。
【図１８】実施の形態２を示す図で、サービスリソース関係抽出手段定義情報１４１４の例を示す図。
【図１９】実施の形態３を示す図で、即時更新サービスルーティングの例を示す図。
【図２０】実施の形態３を示す図で、一括更新サービスルーティングの例を示す図。
【図２１】実施の形態３を示す図で、競合制御部呼び出しが追加されたルーティングの例を示す図。
【図２２】実施の形態４を示す図で、サービス実行管理システム１００の構成の例を示す図。
【図２３】実施の形態４を示す図で、ルーティング定義画面３００の例を示す図。
【図２４】実施の形態４を示す図で、サービスコンテナ定義画面１５００の例を示す図。
【図２５】実施の形態４を示す図で、アクセスポリシー定義情報１１２ｃの例を示す図。
【図２６】実施の形態４を示す図で、サービスコンテナ定義情報１４１２の例を示す図。
【図２７】実施の形態４を示す図で、競合制御部呼び出し（ｉｎ）の処理を示すフローチャート。
【図２８】実施の形態４を示す図で、競合制御部呼び出し（ｏｕｔ）の処理を示すフローチャート。
【図２９】実施の形態１〜４を示す図で、入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０のハードウェア資源の一例を示す図。
【発明を実施するための形態】
【００１３】
実施の形態１．
（サービス実行管理システム（ソフトウェア実行システム）の概要）
図１は、サービス実行管理システム（ソフトウェア実行システム）の構成の例を示す図である。
ここで、サービス実行管理システム１００は、ソフトウェア実行システムに対応する。
そして、前述の通り、サービスは、ソフトウェアに対応する。
また、サービスは前述の通りＳＯＡにおけるサービスアプリケーションであっても良い。
【００１４】
サービス実行管理システム１００は、入力端末１０５、開発サーバ１１０、ＤＢサーバ１２０、サービス実行サーバ１３０から構成される。
ここで、ＤＢサーバ１２０は、データベースサーバのことである。
入力端末１０５、開発サーバ１１０、ＤＢサーバ１２０、サービス実行サーバ１３０等は、例えば、ＬＡＮやインターネットなどのネットワーク１５０に接続されている。
以下、入力端末１０５、開発サーバ１１０、ＤＢサーバ１２０、サービス実行サーバ１３０を個別に説明する。
【００１５】
（入力端末１０５の説明）
入力端末１０５は、例えばパソコンなどから構成されており、業務システムを連携するサービスやルーティングの開発者が、設計・開発作業を行う際に使用する端末である。（以降、業務システムを連携するサービスやルーティングの開発者を「開発者」と称する。）
【００１６】
（ＤＢサーバ１２０の説明）
ＤＢサーバ１２０は、各種の情報を保管する記憶装置であり、例えば、開発サーバ１１０で作成された定義情報を定義情報格納部１２２で格納する。定義情報とは、ルーティング定義情報１１２ａ、サービスリソース関係定義情報１１２ｂ、アクセスポリシー定義情報１１２ｃである。
ここで、定義情報格納部１２２は、条件情報（後述）を記憶する条件情報記憶部とリソース情報（後述）を記憶するリソース情報記憶部とに対応する。
また、定義情報の一部はサービスコンテナ１３１から情報の直接参照が必要な場合は、サービス実行サーバ１３０が備える記憶装置（図示は省略）に記憶されても良い。
【００１７】
（サービス実行サーバ１３０の説明）
サービス実行サーバ１３０は、開発サーバ１１０により開発された一連のサービスやルーティングを実行するサーバである。サービス実行サーバ１３０は、サービスを実行するサービスコンテナ１３１、サービスの競合発生時にサービスの一時停止などの制御を行う競合制御部１３２、競合制御部１３２から呼び出される競合判定部１３３、競合状態管理部１３４、サービスリソース特定部１３５から構成される。
ここで、サービスコンテナ１３１は計算機に対応する。すなわち、前述のようにサービスコンテナ１３１は、ＥＳＢやアプリケーションサーバなどの機能を持つ計算機もしくは仮想計算機であると言える。
また、競合判定部１３３は、起動許否判定部に対応し、競合状態管理部１３４はリソース判定部に対応する。
【００１８】
（開発サーバ１１０の説明）
開発サーバ１１０は、業務システムの連携やサービス間の競合管理に必要となる定義情報を開発するためのサーバである。定義情報設定部１１１は、例えば各種の情報を入力するキーボードやマウスなどのマンマシンインタフェース、あるいは、入力端末１０５で入力された各種の情報をネットワーク経由で取得するネットワークインタフェースなどから構成されている。そして、定義情報設定部１１１は、入力した情報から定義情報（ルーティング定義情報１１２ａ、サービスリソース関係定義情報１１２ｂ、アクセスポリシー定義情報１１２ｃ）を設定して、定義情報記憶部１１２に一時的に格納する処理を実施する。
ここで、サービスリソース関係定義情報１１２ｂは、リソース情報に対応する。
【００１９】
定義情報設定部１１１のルーティング定義部１１１ａは、例えば入力端末１０５からルーティング定義画面（後述）の表示要求があると、ルーティング定義画面（後述）を入力端末１０５のディスプレイ（図示は省略）に表示する。そして、ルーティング定義部１１１ａは、ルーティング定義画面（後述）上で、ルーティングを構成する一連のサービスの定義を受け付けて、その定義内容を示すルーティング定義情報１１２ａを出力する。そして、定義情報記憶部１１２は、出力されたルーティング定義情報１１２ａを一時的に記憶する。
【００２０】
このとき、競合制御機能挿入部１１３は、ルーティング定義部１１１ａで作成したルーティング定義情報１１２ａに対して、各サービスの前後に競合制御部１３２を呼び出すロジックを挿入する。（後述の実施の形態３においては、競合制御機能挿入部１１３は、ルーティング定義部１１１ａで作成したルーティング定義情報１１２ａに対して、指定したサービスの集合であるサービスセットの前後に競合制御部１３２を呼び出すロジックを挿入する。）
これにより、サービスの開始時と終了時に競合制御部１３２を呼び出すことが可能となる。（後述の実施の形態３においては、サービスセットの開始時と終了時に競合制御部１３２を呼び出すことが可能となる。）
【００２１】
サービスリソース関係定義部１１１ｂは、例えば入力端末１０５からサービスリソース関係定義画面（後述）の表示要求があると、サービスリソース関係定義画面（後述）を入力端末１０５のディスプレイ（図示は省略）に表示する。そして、サービスリソース関係定義部１１１ｂは、サービスリソース関係定義画面（後述）上で、サービスリソース関係の定義を受け付けて、その定義内容を示すサービスリソース関係定義情報１１２ｂを出力する。そして、定義情報記憶部１１２は、出力されたサービスリソース関係定義情報１１２ｂを一時的に記憶する。
【００２２】
アクセスポリシー定義部１１１ｃは、例えば入力端末１０５からアクセスポリシー定義画面（後述）の表示要求があると、アクセスポリシー定義画面（後述）を入力端末１０５のディスプレイ（図示は省略）に表示する。そして、アクセスポリシー定義部１１１ｃは、アクセスポリシー定義画面（後述）上で、アクセスポリシー情報の定義を受け付けて、その定義内容を表すアクセスポリシー定義情報１１２ｃを出力する。そして、定義情報記憶部１１２は、出力されたアクセスポリシー定義情報１１２ｃを一時的に記憶する。
【００２３】
なお、定義情報設定部１１１は、各種の定義情報を設定した後、登録要求が入力端末１０５から入力されると、定義情報記憶部１１２が一時的に記憶している各種の定義情報をＤＢサーバ１２０の定義情報格納部１２２に移動する。そして、定義情報格納部１２２は移動された各種の定義情報を記憶する。ただし、定義情報（ルーティング定義情報１１２ａ、サービスリソース関係定義情報１１２ｂ、アクセスポリシー定義情報１１２ｃ）の一部は、サービスコンテナ１３１から直接、情報の参照が必要な場合は、サービス実行サーバ１３０が備える記憶装置（図示は省略）に記憶されても良い。
【００２４】
（サービス実行管理システム１００の処理の概略説明）
図２は、サービス実行管理システム１００の処理の概略を示すフローチャートである。
サービス実行管理システム１００におけるサービスルーティングの設計からサービス実行までの大まかな手順を説明する。
【００２５】
ルーティング設計ステップ（Ｓ２１）は、定義情報設定部１１１が各種の定義情報の作成を行い、定義情報に基づいてサービスコンテナ１３１がルーティングを実行するために必要となるルーティング定義情報１１２ａを作成するステップである。
【００２６】
ここで、ルーティング定義情報１１２ａの生成において、競合制御機能挿入部１１３は、定義情報設定部１１１が設定したルーティングに対して、同時実行時の競合を制御するサービスの前後に、競合制御部１３２を呼び出すためのロジックを挿入する。
【００２７】
デプロイステップ（Ｓ２２）は、作成された各種の定義情報（ルーティング定義情報１１２ａ、サービスリソース関係定義情報１１２ｂ、アクセスポリシー定義情報１１２ｃ）を定義情報格納部１２２に登録するステップである。
【００２８】
サービス実行ステップ（Ｓ２３）は、サービスコンテナ１３１から各種の定義情報を参照してサービスを実行するステップである。
【００２９】
（ルーティング設計ステップの説明）
ルーティング設計ステップ（Ｓ２１）における、各種の定義情報の作成画面を図３、図４、図５に示す。
【００３０】
図３はルーティング定義画面３００の例を示す図である。
入力端末１０５のディスプレイ（図示は省略）に表示されたルーティング定義画面３００により、開発者が入力した内容に基づいて、ルーティング定義部１１１ａは、パレット３０２の中の「ノードリスト」から所望のノード（サービス、分岐、開始、終了）を選択して、そのノードをキャンバス３０１に配置することができる。またルーティング定義部１１１ａは、パレット３０２の中の「接続」からエッジを選択して、各ノードをお互いに接続することで、サービスの呼び出しフローであるルーティングを作成することができる。
（また、実施の形態３において、ルーティング定義部１１１ａは、パレット３０２の中の「その他」から「サービス領域」を選択して、その領域の位置をパレット上のルーティングに対して指定することで、同時実行時の競合を制御する単位としてサービスセットを設定することができる。）
【００３１】
図４は、アクセスポリシー定義画面４００の例を示す図である。
アクセスポリシー定義画面４００は、開発者がアクセスポリシーを定義することができる画面である。アクセスポリシー定義画面４００は、定義済みのアクセスポリシー定義の一覧を表示するアクセスポリシー定義テーブル４０１、アクセスポリシー定義テーブル４０１にアクセスポリシー定義を追加する追加ボタン４０３、アクセスポリシー定義テーブル４０１に含まれている定義を削除する削除ボタン４０２、指定した値で定義を更新する更新ボタン４０４から構成されている。
アクセスポリシー定義は、リソースの種別を表すリソースタイプ４１１、アクセスポリシー間で競合の判定を行う判定ロジック４１２、リソースへのアクセスタイム４１３、アクセスポリシー４１４のそれぞれが指定される。
アクセスポリシー４１４は例えば「Ｃ」、「Ｒ」、「Ｕ」、「Ｄ」が指定される。ここで「Ｃ」、「Ｒ」、「Ｕ」、「Ｄ」は、データベースへのデータアクセスの形態を示し、それぞれＣｒｅａｔｅ・Ｒｅａｄ・Ｕｐｄａｔｅ・Ｄｅｌｅｔｅの意味を表している。
アクセスタイム４１３は、例えば、リソースへのアクセスのタイミングが「実行時」または「常時」から選択する。
【００３２】
図５は、サービスリソース関係定義画面５００の例を示す図である。
サービスリソース関係定義画面５００は、定義済みのサービスリソース関係定義情報１１２ｂの一覧を表すサービスリソース定義関係定義テーブル５０１と、サービスリソース定義関係定義テーブル５０１に定義情報を追加する追加ボタン４０３と、サービスリソース定義関係定義テーブル５０１に含まれている定義を削除する削除ボタン４０２、指定した値で定義を更新する更新ボタン４０４から構成されている。
サービスリソース関係定義情報１１２ｂは、ルーティング定義情報１１２ａで定義されているサービス識別名５１１、リソースの識別子であるリソース識別名５１２、アクセスポリシー定義情報１１２ｃで定義されたリソースタイプ４１１、アクセスポリシー４１４のそれぞれが指定される。
【００３３】
（ルーティングの説明）
次に、図６、図７、図８を用いて、サービスを実行するルーティングモデルを説明する。
図６は、即時更新サービスルーティングの例を示す図である。
図７は、一括更新サービスルーティングの例を示す図である。
図８は、競合制御部呼び出しが追加されたルーティングの例を示す図である。
【００３４】
即時更新サービスルーティング（Ｒ６１）は、ＨＴＴＰ受付１（Ｔ６１１）でＨＴＴＰリクエストを受信すると、更新サービスＡ（Ｔ６１２）、更新サービスＢ（Ｔ６１３）、更新サービスＣ（Ｔ６１４）、メール通知（Ｔ６１５）を順次呼び出すルーティングである。また、一括更新サービスルーティング（Ｒ６２）は、ＨＴＴＰ受付２（Ｔ６２１）でＨＴＴＰリクエストを受信し、一括更新サービスＡ〜Ｃ（Ｔ６２２〜Ｔ６２４）、メール通知２（Ｔ６２５）を順次呼び出すルーティングである。
図６と図７に示すルーティングは、ルーティング定義部１１１ａによって定義されたものである。
【００３５】
そして、図８に示すルーティングは、図６に示す即時更新サービスルーティングの例に競合制御機能挿入部１１３がルーティング設計ステップ（Ｓ２１）において、サービス毎の競合制御を実現するために必要となる競合制御部呼び出しロジックを挿入した後のルーティングのフローである。
図８に示すルーティングは、競合制御機能挿入部１１３によって、各サービスの前に競合制御呼び出し（ｉｎ）（Ｔ９１）が追加され、各サービスの後に競合制御呼び出し（ｏｕｔ）（Ｔ９２）が追加されている。
すなわち、図８に示すルーティングがルーティング定義情報１１２ａの具体例である。
なお、図７に示す一括更新サービスルーティングも図６に示す即時更新サービスルーティングと同様に競合制御機能挿入部１１３によって競合制御部呼び出しロジックが挿入されるが図示は省略する。
【００３６】
（定義情報の説明）
図９、図１０、図１１を用いて、サービス実行管理システム１００がサービス競合の管理を行うための定義情報のデータ構造の例を説明する。
図９は、サービスリソース関係定義情報１１２ｂの例を示す図である。
図１０は、アクセスポリシー定義情報１１２ｃの例を示す図である。
図１１は、条件情報１４００の例を示す図である。
【００３７】
サービスリソース関係定義情報１１２ｂ（図９）は、各ルーティングのサービスがどういったリソースをどう利用するかを示している。サービスとリソースの関係は、サービス識別名５１１、リソース識別名５１２でサービスとリソースの対応を表し、リソースの種別を表すリソースタイプ４１１、リソース利用時のポリシーとしてアクセスポリシー４１４を用いて定義される。
【００３８】
アクセスポリシー定義情報１１２ｃ（図１０）は、サービスが利用するリソース間の関係を判定するために必要となる。
アクセスポリシー定義情報１１２ｃは、リソースの種別を表すリソースタイプ４１１、アクセスポリシーの識別名を表すアクセスポリシー４１４、リソースアクセスのタイミングを表すアクセスタイム４１３、アクセスポリシー間の競合判定を行うロジックをあらわす判定ロジック４１２から構成される。
リソースタイプ４１１、アクセスポリシー４１４は、サービスリソース関係定義情報１１２ｂのリソースタイプ４１１、アクセスポリシー４１４に対応する。
また、判定ロジック４１２はリソースタイプ４１１毎に定義される。
そして、アクセスポリシー定義部１１１ｃは、新たにリソースタイプ４１１を定義する場合に、合わせて判定ロジック４１２を追加することで、競合判定の対象とするリソースタイプを任意に追加することが可能となる。
【００３９】
条件情報１４００（図１１）は、アクセスポリシー定義情報１１２ｃに示された判定ロジック４１２に対応する。
図１１の条件情報１４００は、ＤＢテーブルの判定ロジック４１２である「ＤＢＴａｂｌｅＰｏｌｉｃｙＣｏｍｐａｒａｔｏｒ」の例を示すものである。
図１１の条件情報１４００は、ＤＢテーブルのリソースポリシー同士の判定内容を示したものであり、判定時のリソースのアクセス状態１４０１と、比較対象のアクセスポリシーである比較ポリシー１４０２、競合可否１４０３の結果を記述している。また、条件情報１４００は、競合可否１４０３の結果が可であった場合には、アクセス状態がどのように変わるかを変更後状態１４０４として記述している。
【００４０】
ここで、アクセス状態１４０１は、サービスがリソースを利用する利用モードに対応する。
そして、アクセス状態１４０１は、先に動作している先行サービス（先行ソフトウェア）の利用モードに対応し、比較ポリシー１４０２は、後から起動される後続サービス（後続ソフトウェア）の利用モードに対応する。
そして、競合可否１４０３が「可」となるアクセス状態１４０１と比較ポリシー１４０２との組合せが同時利用許可条件に対応し、競合可否１４０３が「不可」となるアクセス状態１４０１と比較ポリシー１４０２との組合せが同時利用禁止条件に対応する。
【００４１】
サービスリソース関係定義情報１１２ｂとアクセスポリシー定義情報１１２ｃとから、サービスの実行時にサービスが利用するリソースの関係を条件情報１４００に基づいて判定することで、サービス間の競合を判断することが可能となる。
なお、これらの定義情報は、図２のＳ２２に示すデプロイステップにおいて、定義情報格納部１２２に記憶される。
サービス実行ステップにおける具体的な例を用いて以降に説明する。
【００４２】
（サービス実行ステップの説明）
図１２、図１３、図１４を用いてサービス実行ステップの具体例を説明する。
図１２は、サービスリソース利用状態１２１ａの例を示す図である。（（ａ）は一括サービスルーティング（Ｒ６２）が実行された場合、（ｂ）は更新サービスＡ（Ｔ６１２）が実行された場合、（ｃ）は競合制御呼び出し（ｏｕｔ）（Ｔ９２ｂ）が実行された場合）
図１３は、競合制御部呼び出し（ｉｎ）の処理を示すフローチャートである。
図１４は、競合制御部呼び出し（ｏｕｔ）の処理を示すフローチャートである。
【００４３】
サービス実行ステップの説明にあたり、サービスコンテナ１３１（図１）は、図７に示す一括サービスルーティング（Ｒ６２）を実行中であり、かつ、一括サービスルーティング（Ｒ６２）に含まれる全てのサービスがリソースを利用中であると想定する。ここで、一括サービスルーティング（Ｒ６２）以外のルーティングは実行されていないものとする。
そして、サービスコンテナ１３１は、実行中のサービスが利用中のリソースの情報を実行時情報記憶部１２１に出力する。そして、実行時情報記憶部１２１は実行中のサービスが利用中のリソースの情報をサービスリソース利用状態１２１ａとして記憶する。
【００４４】
例えば、サービスコンテナ１３１が図７の「ＨＴＴＰ受付２」（Ｔ６２１）を実行した場合、図９に示すようにサービス識別名５１１「ＨＴＴＰ受付２」のリソース識別名５１２は「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅａｌｌ／」である。また、「ＨＴＴＰ受付２」のリソースタイプ４１１は「ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）」であり、アクセスポリシーは「バインド」である。
サービスコンテナ１３１は、図９のサービスリソース関係定義情報１１２ｂを参照することにより、これらの情報を得ることも出来、また「ＨＴＴＰ受付２」のサービスを実行時に「ＨＴＴＰ受付２」のサービスからこれらの情報を得ることも出来る。
そして、サービスコンテナ１３１は、図１２（ａ）に示すようにリソース識別名５１２として「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅａｌｌ／」、リソースタイプ４１１として「ＵＲＬ」、アクセス状態１４０１として「バインド」を実行時情報記憶部１２１に出力する。
ここで、例えばリソース識別名５１２「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅａｌｌ／」は、「ＨＴＴＰ受付２」のサービスが利用中の利用中リソースに対応する。
【００４５】
同様に例えば、サービスコンテナ１３１が図７の「一括更新サービスＡ」（Ｔ６２２）を実行した場合、図９に示すようにサービス識別名５１１「一括更新サービスＡ」のリソース識別名５１２は「ＤＢ１／テーブルＡ」である。また、「一括更新サービスＡ」のリソースタイプ４１１は「ＤＢテーブル」であり、アクセスポリシーは「Ｕ」である。
そして、サービスコンテナ１３１は、図１２（ａ）に示すようにリソース識別名５１２として「ＤＢ１／テーブルＡ」、リソースタイプ４１１として「ＤＢテーブル」、アクセス状態１４０１として「Ｕ」を実行時情報記憶部１２１に出力する。
【００４６】
図７に示す「一括更新サービスＢ」（Ｔ６２３）、「一括更新サービスＣ」（Ｔ６２４）についても同様である為、説明を省略する。
【００４７】
実行時情報記憶部１２１は、サービスリソース利用状態１２１ａとして、リソース識別名５１２、リソースタイプ４１１、アクセス状態１４０１を記憶する。
ここで、リソース識別名５１２とリソースタイプ４１１とは、実行中のサービスが利用中であるリソースを特定する為の情報であり、前述のように図９のサービスリソース関係定義情報１１２ｂや図１０のアクセスポリシー定義情報１１２ｃで定義した内容に対応する。
アクセス状態１４０１は、サービスリソースがどのように利用されているかを表す項目である。
【００４８】
なお、図７に示す「メール通知２」（Ｔ６２５）は、他のサービスと共用するようなリソースを利用しない為に、サービスリソース利用状態１２１ａとして実行時情報記憶部１２１には記憶されない。
【００４９】
そして、サービスコンテナ１３１（図１）が、図７に示す一括サービスルーティング（Ｒ６２）を実行中に、新たに図６に示す即時更新サービスルーティング（Ｒ６１）を実行する場合を想定する。
一括サービスルーティング（Ｒ６２）の場合は、他のルーティングが実行されていなかった為に競合制御部呼び出しの説明を省略した。しかし、ここでは一括サービスルーティング（Ｒ６２）が既に実行中の場合を考える為に、競合制御部呼び出しが明記された図８に示す即時更新サービスルーティング（Ｒ６１）を用いて説明する。
【００５０】
（図８のＴ９１ａ〜Ｔ６１１における処理の説明）
サービスコンテナ１３１（図１）は、図８に示す即時更新サービスルーティング（Ｒ６１）の実行にあたり、最初に競合制御部呼び出し（ｉｎ）（Ｔ９１ａ）を実行し、競合制御部１３２（図１）を呼び出す。
競合制御部１３２は、サービス実行前にそのサービスが実行できるか判定を行い、処理待ちや処理継続の制御を行う。
【００５１】
ここで、競合制御部呼び出し（ｉｎ）における競合制御部１３２の動作を図１３のフローチャートで説明する。
まず、競合制御部１３２は、即時更新サービスルーティング（Ｒ６１）において、競合制御部１３２の処理開始のトリガーとなるメッセージをサービスコンテナ１３１から受信する（Ｓ１０１）。
【００５２】
そして、競合制御部１３２は、サービスリソース特定部１３５（図１）を呼び出す。サービスリソース特定部１３５は、ルーティング定義情報１１２ａに示されたサービスが利用するリソースを特定する（Ｓ１０２）。
具体的には、図８の競合制御部呼び出し（ｉｎ）（Ｔ９１ａ）に基づき呼び出されたサービスリソース特定部１３５は、ルーティング定義情報１１２ａにおける次の処理である図８に示す「ＨＴＴＰ受付１（Ｔ６１１）」のサービスが利用するリソースを特定する。
ここで、サービスリソース特定部１３５は、図９に示すサービスリソース関係定義情報１１２ｂを参照し、ルーティング定義情報１１２ａに示されたサービス識別名「ＨＴＴＰ受付１」に対応するリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」を特定する。
【００５３】
次に図１３に示すＳ１０３において、競合制御部１３２は、競合状態管理部１３４（図１）を呼び出す。
競合状態管理部１３４は、図１２（ａ）に示すサービスリソース利用状態１２１ａに、サービスリソース特定部１３５が特定したリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」が有るか否かを判定することにより、異なるサービス間で同時に利用される同時利用リソースが有るか否かを判定する。
そして、「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」がサービスリソース利用状態１２１ａに無いので、競合状態管理部１３４は同時利用リソースが無いと判定する（Ｓ１０３の「Ｎｏ」）。（Ｓ１０３の「Ｙｅｓ」の場合は、後述する。）
【００５４】
そして、競合制御部１３２はリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」の情報を実行時情報記憶部１２１に入力し、実行時情報記憶部１２１は、図１２（ｂ）に示すようにサービスリソース利用状態１２１ａとして記憶する（Ｓ１０７）。
【００５５】
ここで、競合制御部１３２は例えばサービス実行サーバ１３０の記憶装置（図示は省略）にサービスリソース利用状態１２１ａが更新される前の状態を記憶することが可能である。すなわち、競合制御部１３２は、リソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」の情報を新たに入力する前は、サービスリソース利用状態１２１ａにリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」の情報が無かった状態（すなわち図１２（ａ）の状態）を記憶することが可能である。
【００５６】
最後に競合制御部１３２は、サービスの処理開始のトリガーとなるメッセージを次のサービス（すなわち図８の「ＨＴＴＰ受付１（Ｔ６１１）」）に転送する（Ｓ１０６）。
【００５７】
（図８のＴ９２ａにおける処理の説明）
サービスコンテナ１３１は、図８の「ＨＴＴＰ受付１（Ｔ６１１）」の処理を終了後、図８の「競合制御部呼び出し（ｏｕｔ）（Ｔ９２ａ）」を実行し、競合制御部１３２（図１）を呼び出す。
【００５８】
ここで、競合制御部呼び出し（ｏｕｔ）における競合制御部１３２の動作を図１４のフローチャートで説明する。
まず、競合制御部１３２は、即時更新サービスルーティング（Ｒ６１）において、競合制御部１３２の処理開始のトリガーとなるメッセージをサービスコンテナ１３１から受信する（Ｓ１１１）。
【００５９】
そして、図１３のＳ１０２と同様に競合制御部１３２は、サービスリソース特定部１３５（図１）を呼び出す。サービスリソース特定部１３５は、ルーティング定義情報１１２ａに示されたサービスが利用するリソースを特定する（Ｓ１１２）。
具体的には、図８の競合制御部呼び出し（ｏｕｔ）（Ｔ９２ａ）に基づき呼び出されたサービスリソース特定部１３５は、ルーティング定義情報１１２ａにおける前の処理である図８に示す「ＨＴＴＰ受付１（Ｔ６１１）」のサービスが利用するリソースを特定する。
ここで、サービスリソース特定部１３５は、図９に示すサービスリソース関係定義情報１１２ｂを参照し、ルーティング定義情報１１２ａに示されたサービス識別名「ＨＴＴＰ受付１」に対応するリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」を特定する。
【００６０】
図１４のＳ１１３において、競合制御部１３２は、サービス実行サーバ１３０の記憶装置（図示は省略）に記憶されたサービスリソース利用状態１２１ａが、ルーティング定義情報１１２ａ上で直前の競合制御部呼び出し（ｉｎ）によって更新される前の状態に戻す。
すなわち、競合制御部１３２は、図１３のＳ１０７において記憶したサービスリソース利用状態１２１ａにリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」の情報が無かった状態（すなわち図１２（ａ）の状態）に戻す。あるいは、競合制御部１３２は、サービスリソース利用状態１２１ａにリソース識別名「ｈｔｔｐ：／／ｈｏｓｔＡ／Ｓｅｒｖｉｃｅｓ／ｕｐｄａｔｅ／」の情報としては残しておいて、アクセス状態１４０１を「バインド」から「なし」に変更することも可能である（図１２（ｃ））。
ここでは、「ＨＴＴＰ受付１（Ｔ６１１）」のサービスの実行が完了し、競合制御部１３２は、サービスリソースをサービスが利用中の状態から解放する処理を行っている。
【００６１】
最後に競合制御部１３２は、サービスの処理開始のトリガーとなるメッセージを次のサービス（すなわち図８の「競合制御部呼び出し（ｉｎ）（Ｔ９１ｂ）」）に転送する（Ｓ１１４）。
【００６２】
（図８のＴ９１ｂにおける処理の説明）
図８の「競合制御部呼び出し（ｉｎ）（Ｔ９１ｂ）」では、Ｔ９１ａと同様に競合制御部１３２を呼び出す。
そして、同様にサービスリソース特定部１３５が呼び出され、サービスリソース特定部１３５は、図８に示す「更新サービスＡ」（Ｔ６１２）」のサービスが利用するリソースを特定する。
ここで、サービスリソース特定部１３５は、図９に示すサービスリソース関係定義情報１１２ｂを参照し、ルーティング定義情報１１２ａに示されたサービス識別名「更新サービスＡ」に対応するリソース識別名「ＤＢ１／テーブルＡ」を特定する。
【００６３】
次に図１３に示すＳ１０３において、競合状態管理部１３４は、図１２（ｃ）に示すサービスリソース利用状態１２１ａに、サービスリソース特定部１３５が特定したリソース識別名「ＤＢ１／テーブルＡ」が有るか否かを判定することにより、異なるサービス間で同時に利用される同時利用リソースが有るか否かを判定する。
すなわち、競合状態管理部１３４は、第１のサービス「一括更新サービスＡ」がアクセス状態「Ｕ」（所定の利用モード）で「ＤＢ１／テーブルＡ」（所定のリソース）を利用して動作している場合に、新たに起動される第２のサービス「更新サービスＡ」が第１のサービス「一括更新サービスＡ」が利用している「ＤＢ１／テーブルＡ」（利用中リソース）を利用して動作するか否かを判定する。
そして、「ＤＢ１／テーブルＡ」がサービスリソース利用状態１２１ａに有るので、競合状態管理部１３４は同時利用リソースが有ると判定する（Ｓ１０３の「Ｙｅｓ」）。
【００６４】
そして、図１３に示すＳ１０４において、競合制御部１３２は、競合判定部１３３を呼び出す。競合判定部１３３は、サービスリソース関係定義情報１１２ｂのアクセスポリシー４１４と、サービスリソース利用状態１２１ａのアクセス状態１４０１とを参照する。すなわち、競合判定部１３３は、図９に示す「更新サービスＡ」のアクセスポリシー４１４「Ｒ」と、図１２に示す「ＤＢ１／テーブルＡ」のアクセス状態１４０１「Ｕ」とを参照する。
【００６５】
また、競合判定部１３３は、図９に示す「更新サービスＡ」のリソースタイプ４１１「ＤＢテーブル」を参照し、図１０に示すアクセスポリシー定義情報１１２ｃの「ＤＢテーブル」に対応する判定ロジック４１２「ＤＢＴａｂｌｅＰｏｌｉｃｙＣｏｍｐａｒａｔｏｒ」を参照する。
そして、競合判定部１３３は、「ＤＢＴａｂｌｅＰｏｌｉｃｙＣｏｍｐａｒａｔｏｒ」に対応する図１１の条件情報１４００を用いて、「更新サービスＡ」が「ＤＢ１／テーブルＡ」を利用可能か否か判定する。
すなわち、競合判定部１３３は、競合状態管理部１３４により第２のサービス「更新サービスＡ」が「ＤＢ１／テーブルＡ」（利用中リソース）を利用して動作すると判定された場合に、第２のサービス「更新サービスＡ」の「ＤＢ１／テーブルＡ」（利用中リソース）の利用モードを判定し、第１のサービス「一括更新サービスＡ」の「ＤＢ１／テーブルＡ」（利用中リソース）の利用モードと第２のサービス「更新サービスＡ」の「ＤＢ１／テーブルＡ」（利用中リソース）の利用モードとに基づき、第２のサービス「更新サービスＡ」の起動の許否を判定する。
【００６６】
図１１の条件情報１４００において、アクセス状態１４０１が「Ｕ」で（図１２に示す「ＤＢ１／テーブルＡ」のアクセス状態１４０１「Ｕ」に対応）、比較ポリシー１４０２が「Ｒ」（図９に示す「更新サービスＡ」のアクセスポリシー４１４「Ｒ」に対応）の場合の競合可否１４０３は「可」である。
よって、競合判定部１３３は、「更新サービスＡ」が「ＤＢ１／テーブルＡ」を利用可能と判定する（図１３のＳ１０４の「Ｎｏ」）。すなわち、競合判定部１３３は、「更新サービスＡ」の起動を許可する。
また、競合判定部１３３は、競合制御部１３２に競合可否１４０３が「可」であることと、図１１に示す変更後状態１４０４が「Ｃ」であることを通知する。
これは、他のサービスがデータベースに対し「Ｕｐｄａｔｅ」のアクセス形態で利用中であっても、新たなサービスが「Ｒｅａｄ」のアクセス形態であるならば同じリソースを利用可能であることを意味する。
【００６７】
一方、例えば、アクセス状態１４０１が「Ｃ」で、比較ポリシー１４０２も「Ｃ」の場合は、競合可否１４０３は「不可」である。これは異なるサービス同士が同じリソースに対して「Ｃｒｅａｔｅ」のアクセス形態では利用出来ないことを意味する。
このような場合、競合判定部１３３は、リソースの同時利用が出来ないと判定し（図１３のＳ１０４の「Ｙｅｓ」）、実行中のサービスが終了してリソースを解放するのを待つ（図１３のＳ１０８）。すなわち新たに実行されるサービスは処理待ちとなる。つまり、競合判定部１３３は、新たに実行されるサービス（後続ソフトウェア）の起動を禁止する。
そして、実行中のサービスが終了してリソースを解放後に、競合判定部１３３は、再度、図１３のＳ１０３において新たに実行されるサービスについて判定を行う。
アクセス状態１４０１と比較ポリシー１４０２とが「Ｕ」同士、「Ｄ」同士の場合も同様である。
【００６８】
競合判定部１３３が、「更新サービスＡ」が「ＤＢ１／テーブルＡ」を利用可能と判定した場合（図１３のＳ１０４の「Ｎｏ」）、図１３のＳ１０５において、競合制御部１３２は、まず現在のサービスリソース利用状態１２１ａを例えばサービス実行サーバ１３０の記憶装置（図示は省略）に記憶する。
すなわち、競合制御部１３２は、図１２（ｃ）に示すリソース識別名「ＤＢ１／テーブルＡ」のアクセス状態が「Ｕ」であったことを記憶装置に記憶する。
【００６９】
次に、競合制御部１３２は、実行時情報記憶部１２１が記憶しているサービスリソース利用状態１２１ａのリソース識別名「ＤＢ１／テーブルＡ」のアクセス状態を「Ｃ」に変更する（図１３のＳ１０５、図１２（ｄ））。
【００７０】
最後に競合制御部１３２は、サービスの処理開始のトリガーとなるメッセージを次のサービス（すなわち図８の「更新サービスＡ（Ｔ６１２）」）に転送する（Ｓ１０６）。
【００７１】
（図８のＴ９２ｂにおける処理の説明）
サービスコンテナ１３１は、図８の「更新サービスＡ（Ｔ６１２）」の処理を終了後、図８の「競合制御部呼び出し（ｏｕｔ）（Ｔ９２ｂ）」を実行し、競合制御部１３２（図１）を呼び出す。
【００７２】
図８のＴ９２ａの説明と同様に、図１３のＳ１１３において、競合制御部１３２は、サービス実行サーバ１３０の記憶装置（図示は省略）に記憶されたサービスリソース利用状態１２１ａが、ルーティング定義情報１１２ａ上で直前の競合制御部呼び出し（ｉｎ）によって更新される前の状態に戻す。
すなわち、競合制御部１３２は、リソース識別名５１２「ＤＢ１／テーブルＡ」のアクセス状態１４０１を「Ｃ」から「Ｕ」に戻す（図１２（ｃ））。
【００７３】
最後に競合制御部１３２は、サービスの処理開始のトリガーとなるメッセージを次のサービスに転送し、サービスコンテナ１３１はルーティングを継続する。以降の処理は同様である為、説明を省略する。
なお、本例では、２つのルーティング（即時更新サービスルーティングＲ６１と一括更新サービスルーティングＲ６２）が同時に実行される場合を説明したが、同時に実行されるルーティングの数は２つに限られず、実際には多数のルーティングが同時に実行される。
【００７４】
（実施の形態１の効果）
実施の形態１におけるサービス実行管理システム１００は、サービスがリソースを利用する場合のアクセス状態の関係に基づきサービスの競合判定を行うことで、全てのサービス間の競合可否条件の定義を不要とすることが可能である。
すなわち、全てのサービス間の競合可否条件の定義をすることなく、アクセス状態間の競合可否条件のみを定義することで、サービス実行管理システム１００は、同時に実行出来ないサービスを判定し、同時に実行出来ないと判定されたサービスを待機状態にすることで、サービスの競合を管理することが可能である。
【００７５】
実施の形態１においては、業務システムを連携するサービス実行基盤において、サービスとそのサービスが利用するサービスリソース間の関係を定義し、その関係定義に基づいてサービスリソースの利用関係からサービス間の競合関係を判定するサービス実行管理方式について説明した。また、サービスとサービスリソース間の利用関係にポリシーを定義し、サービスリソースの競合可否をポリシーにしたがって判定するサービス実行管理方式について説明した。
【００７６】
実施の形態２．
（サービス実行管理システム１００の概要）
図１５は、サービス実行管理システム１００の構成の例を示す図である。
実施の形態２のサービス実行管理システム１００は実施の形態１のサービス実行管理システム１００に比べ、開発サーバ１１０の定義情報設定部１１１にサービスリソース関係抽出手段定義部１４１３が追加されている。そして、開発サーバ１１０の定義情報記憶部１１２にサービスリソース関係抽出手段定義情報１４１４が追加されている。更に、サービス実行サーバ１３０にサービスリソース関係抽出部１４３１が追加されている。その他は、実施の形態１のサービス実行管理システム１００と同様の構成である。
以降、実施の形態１と同様の部分は、説明を省略する。
【００７７】
サービスリソース関係抽出手段定義部１４１３は、サービスとリソース間の関係を抽出するための手段を定義するもので、例えば入力端末１０５からサービスリソース関係抽出手段定義画面（後述）の表示要求があると、サービスリソース関係抽出手段定義画面（後述）を入力端末１０５のディスプレイ（図示は省略）に表示する。そして、サービスリソース関係抽出手段定義部１４１３は、サービスリソース関係抽出手段定義画面（後述）上で、サービスとリソース間の関係を抽出する手段の定義を受け付けて、その定義内容を表すサービスリソース関係抽出手段定義情報１４１４を出力する。そして、定義情報記憶部１１２は出力されたサービスリソース関係抽出手段定義情報１４１４を一時的に記憶する。
【００７８】
実施の形態２のサービス実行管理システム１００も実施の形態１と同様に図２に示すフローチャートに従って処理を進める。
【００７９】
（ルーティング設計ステップの説明）
サービスリソース関係抽出手段定義部１４１３を用いた定義情報の作成は、図２で示したルーティング設計（Ｓ２１）ステップ上で行う。
図１６は、サービスリソース関係抽出手段定義画面１６００の例を示す図である。
サービスリソース関係抽出手段定義画面１６００は、サービス実行時にサービスリソース関係定義情報１１２ｂを抽出する手段を表したサービスリソース関係抽出手段定義情報１４１４を定義することのできる画面である。サービスリソース関係抽出手段定義画面１６００は、定義済みのサービスリソース関係抽出手段定義の一覧を表示するサービスリソース関係抽出手段定義テーブル１６０１、サービスリソース関係抽出手段定義テーブル１６０１に定義情報を追加する追加ボタン４０３、指定した値で定義を更新する更新ボタン４０４、サービスリソース関係抽出手段定義テーブル１６０１に含まれている定義を削除する削除ボタン４０２から構成されている。
サービスリソース関係抽出手段定義情報１４１４は、抽出手段を識別する名称として手段識別名１６０５、サービスとリソース関係とを抽出する手段の対象となるリソースの種別を表すリソースタイプ４１１、そして実際にどのようにサービスとリソース関係を抽出するかを表した抽出手段１６０７が指定される。抽出手段１６０７は、例えば、Ｊａｖａ（登録商標）などのプログラムによって作成した抽出ロジックを表したもので、そのプログラムを呼び出すために必要となるクラス名などを指定する。
【００８０】
（定義情報の説明）
図１７は、サービスリソース関係定義情報１１２ｂの例を示す図である。
図１８は、サービスリソース関係抽出手段定義情報１４１４の例を示す図である。
実施の形態２におけるサービスリソース関係定義情報１１２ｂのデータ構造は図９に示す実施の形態１のサービスリソース関係定義情報１１２ｂと同じであるが、サービスリソース関係定義部１１１ｂは、サービス識別名５１１とリソースタイプ４１１のみ定義し、リソース識別名５１２、アクセスポリシー４１４は、定義しない。
サービスリソース関係抽出手段定義情報１４１４は、前述で説明の通り、手段識別名１６０５、リソースタイプ４１１、抽出手段１６０７から構成される。
サービスリソース関係抽出手段定義情報１４１４は図２のＳ２２に示すデプロイステップにおいて、定義情報格納部１２２に記憶される。
サービスリソース関係定義情報１１２ｂも実施の形態１と同様に定義情報格納部１２２に記憶される。
【００８１】
（サービス実行ステップの説明）
サービス実行ステップにおいて、実施の形態２のサービス実行管理システム１００は、図１３に示すＳ１０２における処理以外は、実施の形態１のサービス実行管理システム１００と同様の処理を行う。
図１３に示すＳ１０２における実施の形態２のサービス実行管理システム１００の処理を説明する。
図１３に示すＳ１０２は、実施の形態１と同様にルーティング上のサービスが利用するサービスリソースを特定するステップである。
まず、競合制御部１３２（図１５）は、実施の形態１と同様にサービスリソース特定部１３５（図１５）を呼び出す。そして、サービスリソース特定部１３５は、実施の形態１と同様にルーティング定義情報１１２ａに示されたサービスが利用するリソースを特定する為に、サービスリソース関係定義情報１１２ｂを参照する。
【００８２】
ここで、サービスリソース関係定義情報１１２ｂにリソース識別名５１２とアクセスポリシー４１４とが定義されていない場合、サービスリソース特定部１３５はサービスリソース関係抽出部１４３１を呼び出す。
サービスリソース関係抽出部１４３１は、サービスリソース関係抽出手段定義情報１４１４を参照し、サービスリソース関係定義情報１１２ｂに定義されたリソースタイプに応じた抽出手段を用いてサービスが利用するリソースを特定する。
【００８３】
例えば、サービスが利用するリソースタイプが「ＤＢテーブル」であれば、抽出手段「ＤＢＡｃｃｅｓｓＡｎａｌｙｚｅｒ」は、サービスが実行前に利用するＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）文を解析する。そして、抽出手段「ＤＢＡｃｃｅｓｓＡｎａｌｙｚｅｒ」は、そのＳＱＬ文のタイプ（ＩＮＳＥＲＴ文、ＳＥＬＥＣＴ文、ＵＰＤＡＴＥ文、ＤＥＬＥＴＥ文）をアクセスポリシー「Ｃ」、「Ｒ」、「Ｕ」、「Ｄ」に対応付ける。また、抽出手段「ＤＢＡｃｃｅｓｓＡｎａｌｙｚｅｒ」は、ＳＱＬ文のテーブル名から対象のリソース識別名を抽出することが出来る。
ここで、ＳＱＬ文は、サービスがリソースを利用する際に出力するコマンドに対応する。
【００８４】
サービスリソース特定部１３５は抽出手段が抽出したリソース識別名とアクセスポリシーを用いて、サービス識別名に対応するリソース識別名を特定する。
【００８５】
（実施の形態２の効果）
実施の形態２におけるサービス実行管理システム１００は、サービスリソース関係抽出手段を定義しておくことで、実施の形態１の効果に加え、サービス実行時にサービスが利用するリソースを抽出することが可能となる。すなわち、実施の形態２におけるサービス実行管理システム１００は、サービス実行時に実施の形態１におけるサービスリソース関係定義情報１１２ｂに相当する内容を抽出することが可能となる。そして、実施の形態２におけるサービス実行管理システム１００は、実行時にサービスが利用するリソースが変化する場合にもサービスの競合判定を行うことが可能となる。
【００８６】
実施の形態２においては、サービスとそのサービスが利用するサービスリソース間の関係定義について、サービス実行時に、そのサービスが利用するサービスリソースを自動で抽出する手段を定義し、サービスとサービスリソース間の関係を手動で定義することなく、サービス間の競合を判定するサービス管理方式について説明した。
【００８７】
実施の形態３．
（サービス実行管理システム１００の概要）
実施の形態３のサービス実行管理システム１００は、実施の形態１の構成（図１）もしくは実施の形態２の（図１５）構成と同様である。
以降、実施の形態１もしくは実施の形態２と同様の部分は、説明を省略する。
【００８８】
（ルーティングの説明）
次に、図１９、図２０、図２１を用いて、実施の形態３におけるルーティングモデルを説明する。
図１９は、即時更新サービスルーティングの例を示す図である。
図２０は、一括更新サービスルーティングの例を示す図である。
図２１は、競合制御部呼び出しが追加されたルーティングの例を示す図である。
【００８９】
実施の形態３において、ルーティング定義部１１１ａ（図１もしくは図１５）は、図３のルーティング定義画面３００のパレット３０２の中の「その他」から「サービス領域」を選択している点が実施の形態１もしくは実施の形態２とは異なる。
具体的には、ルーティング定義部１１１ａは図１９の「更新サービスＡ」（Ｔ６１２）から「更新サービスＣ」（Ｔ６１３）までをサービスセットＲ６１ａとして定義している。また、ルーティング定義部１１１ａは図２０の「一括更新サービスＡ」（Ｔ６２２）から「一括更新サービスＣ」（Ｔ６２４）までをサービスセットＲ６２ａとして定義している。
【００９０】
これらのサービスセットは、サービス間の競合が判定される時、単一のサービスごとではなく、複数のサービスセットを単位として、同時実行時の競合を制御される場合にルーティング定義部１１１ａが指定する領域である。この領域内に指定されたサービスは、すべてのリソースへのアクセスを同時に行い、リソースへのアクセスを一括で行うものと見なして、サービスセット間の競合判定が行われる。
【００９１】
図２１に示すルーティングは、図１９に示す即時更新サービスルーティングＲ６１に対して、競合制御機能挿入部１１３が競合制御部呼び出しロジックを挿入した後のルーティングのフローである。
「競合制御呼び出し（ｉｎ）（Ｔ９１ａ）」と「競合制御呼び出し（ｏｕｔ）（Ｔ９２ａ）」については、実施の形態１と同様であるが、サービスセットＲ６１ａの前後に「競合制御呼び出し（ｉｎ）（Ｔ９１ｂ）」と「競合制御呼び出し（ｏｕｔ）（Ｔ９２ｂ）」とが挿入されている点が、実施の形態１と異なる。
すなわち、ルーティング定義情報１１２ａ（図２１）の生成において、競合制御機能挿入部１１３は、定義情報設定部１１１が設定したルーティングに対して、同時実行時の競合を制御する単位として指定したサービスセットの領域の前後に、競合制御部１３２を呼び出すためのロジックを挿入する。
【００９２】
（サービス実行ステップの説明）
「競合制御呼び出し（ｉｎ）（Ｔ９１ｂ）」において、競合判定部１３３は、「更新サービスＡ（Ｔ６１２）」から「更新サービスＣ（Ｔ６１４）」の全てが実行可能か否かを実施の形態１もしくは実施の形態２と同様の方法で判定する。
「更新サービスＡ（Ｔ６１２）」から「更新サービスＣ（Ｔ６１４）」のいずれかが実行不可能な場合、競合判定部１３３は、「更新サービスＡ（Ｔ６１２）」から「更新サービスＣ（Ｔ６１４）」のいずれもが実行不可能と判定する。すなわち競合判定部１３３は、サービスセットＲ６１ａの実行が不可能と判定し、サービスセットＲ６１ａの処理待ちの制御を行う。
【００９３】
すなわち、ルーティング定義部１１１ａは、サービスセットＲ６１ａに含まれるサービスを互いに関連付けられているサービスとして定義する。そして、競合判定部１３３は、サービスセットＲ６１ａに含まれるサービスの起動を禁止する場合に、起動を禁止されたサービスにサービスセットＲ６１ａとして関連付けられている他のソフトウェアの起動も禁止する。
【００９４】
（実施の形態３の効果）
実施の形態３におけるサービス実行管理システム１００は、実施の形態１と実施の形態２との効果に加え、サービス単体ではなく、ルーティング上の複数サービスのセットを単位として競合を制御することが出来る。
【００９５】
実施の形態３においては、一連のサービスの処理フローを表すルーティング上で、処理フローのサブセットであるサービスセットを単位として定義し、定義されたサービスセットの前後に実行制御を行うコンポーネントを埋め込むことで、ルーティング実行時にサービスセット単位の競合制御を行うサービス管理方式について説明した。
【００９６】
実施の形態４．
（サービス実行管理システム１００の概要）
図２２は、サービス実行管理システム１００の構成の例を示す図である。
実施の形態４のサービス実行管理システム１００は、実施の形態２の構成（図１５）に比べ、開発サーバ１１０の定義情報設定部１１１にサービスコンテナ定義部１４１１が追加されている。そして、開発サーバ１１０の定義情報記憶部１１２にサービスコンテナ定義情報１４１２が追加されている。更に、サービス実行サーバがサービス実行サーバ１３０ａとサービス実行サーバ１３０ｂとの２台になっている。ここで、サービス実行サーバ１３０の数は、２台に限られるものでは無い。
また、実施の形態１と同様にサービスリソース関係抽出手段定義部１４１３、サービスリソース関係抽出手段定義情報１４１４、サービスリソース関係抽出部１４３１は無くても良い。
その他は、実施の形態１〜３のサービス実行管理システム１００と同様の構成である。以降、実施の形態１〜３と同様の部分は、説明を省略する。
【００９７】
サービスコンテナ定義部１４１１は、サービスコンテナに関する情報を定義するもので、例えば入力端末１０５からサービスコンテナ定義画面（後述）の表示要求があると、サービスコンテナ定義画面（後述）を入力端末１０５のディスプレイ（図示は省略）に表示する。そして、サービスコンテナ定義部１４１１は、サービスコンテナ定義画面（後述）上で、サービスコンテナの定義を受け付けて、その定義内容を示すサービスコンテナ定義情報１４１２を出力する。そして、定義情報記憶部１１２は、出力されたサービスコンテナ定義情報１４１２を一時的に記憶する。
【００９８】
（ルーティング設計ステップの説明）
サービスコンテナ定義部１４１１を用いた定義情報の作成は、図２で示したルーティング設計（Ｓ２１）ステップ上で行う。
図２３は、ルーティング定義画面３００の例を示す図である。
実施の形態１〜３との相違点は、パレット３０２の「その他」に各サービスが配置されるサービスコンテナを指定する要素が追加された点である。これにより、ルーティングの各サービスが実行されるサービスコンテナを指定することができる。
【００９９】
図２４は、サービスコンテナ定義画面１５００の例を示す図である。
サービスコンテナ定義画面１５００は、サービスコンテナ定義情報１４１２を定義することのできる画面である。サービスコンテナ定義画面１５００は、定義されたサービスコンテナ定義の一覧を表示するサービスコンテナ定義テーブル１５０１、サービスコンテナ定義テーブル１５０１に定義情報を追加する追加ボタン４０３と、指定した値で定義を更新する更新ボタン４０４、サービスコンテナ定義テーブル１５０１に含まれている定義を削除する削除ボタン４０２から構成されている。
サービスコンテナ定義情報１４１２は、サービスコンテナを識別するコンテナ識別名１５０５、サービスコンテナの種別であるコンテナタイプ１５０６、サービスコンテナの管理対象のＵＲＬである管理ＵＲＬ１５０７などが指定される。
【０１００】
（定義情報の説明）
図２５はアクセスポリシー定義情報１１２ｃの例を示す図である。
図２６は、サービスコンテナ定義情報１４１２の例を示す図である。
実施の形態４におけるアクセスポリシー定義情報１１２ｃは、実施の形態１で説明したアクセスポリシー定義情報１１２ｃの例（図１０）に加えて、スコープ１８０５が追加されている。このスコープ１８０５は、サービスが利用するリソースがサービスコンテナごとに独立しているのか、それとも複数サービスコンテナをまたがって利用されるのかを表している。図２５の例では、リソースタイプ４１１が「ローカルファイル」のリソースは、スコープ１８０５が「ローカル」であり、異なるサービスコンテナ間では、競合しない。すなわち、スコープ１８０５が「ローカル」のリソースは、異なるサービスコンテナ毎に備えられている。
サービスコンテナ定義情報１４１２は、前述で説明の通り、コンテナ識別名１５０５、コンテナタイプ１５０６、管理ＵＲＬ１５０７から構成される。
サービスコンテナ定義情報１４１２は図２のＳ２２に示すデプロイステップにおいて、定義情報格納部１２２に記憶される。
アクセスポリシー定義情報１１２ｃも実施の形態１と同様に定義情報格納部１２２に記憶される。
【０１０１】
（サービス実行ステップの説明）
図２７は、競合制御部呼び出し（ｉｎ）の処理を示すフローチャートである。
図２８は、競合制御部呼び出し（ｏｕｔ）の処理を示すフローチャートである。
サービス実行ステップにおいて、実施の形態４のサービス実行管理システム１００は、図２７に示すＳ１９１における処理以外は、実施の形態１〜３のサービス実行管理システム１００と同様の処理を行う。
例えば、実施の形態４のサービス実行管理システム１００は図２７のＳ１０２において実施の形態１のようにサービスリソース関係定義情報１１２ｂからリソースを特定しても良いし、実施の形態２のようにサービスリソース関係抽出部１４３１を用いてリソースを特定しても良い。また、実施の形態４のサービス実行管理システム１００はサービス毎に競合判定をしても良いし、サービスセット毎に競合判定をしても良い。
【０１０２】
図２７に示すＳ１９１において、競合制御部１３２は、ルーティング定義情報１１２ａに定義された各サービスが実行されるサービスコンテナ１３１を特定する。そして、例えばサービス実行サーバ１３０の記憶装置（図示は省略）は、競合制御部１３２が特定したサービスコンテナ１３１の情報を記憶する。
【０１０３】
そして、図２７のＳ１０３において、競合状態管理部１３４は、実行中のサービスと新たに実行されるサービスとが同じリソースを利用するか否かを判定する。
そして、実行中のサービスと新たに実行されるサービスとが同じリソース識別名のリソースを利用する場合を想定する。この場合、実施の形態１では、同時利用リソースが有ると判定された（Ｓ１０３の「Ｙｅｓ」）。一方、実施の形態４においては、実行中のサービスと新たに実行されるサービスとが異なるサービスコンテナ１３１で実行され、かつ、いずれかのサービスが利用するリソースのスコープ１８０５が「ローカル」である場合には、競合状態管理部１３４は、同時利用リソースが無いと判定する（Ｓ１０３の「Ｎｏ」）。
すなわち、実施の形態４のサービス実行管理システム１００は、利用するリソースのスコープ１８０５が「ローカル」である場合には、サービスコンテナ１３１毎に、サービスの競合判定を行う。
図２８については、実施の形態１で説明の図１４と同様である為、説明を省略する。
【０１０４】
ここでは、計算機が例えばサービスコンテナのような仮想計算機を想定し、サービスコンテナ毎にリソースが備えられており、サービスコンテナ毎に競合判定される例を説明した。しかし、例えばリソースがサービス実行サーバ１３０毎に備えられていれば、現実の計算機であるサービス実行サーバ１３０毎に競合判定を行なっても良い。
【０１０５】
（実施の形態４の効果）
実施の形態４におけるサービス実行管理システム１００は、実施の形態１と実施の形態２と実施の形態３との効果に加え、サービスコンテナの情報を定義し、サービスリソースがどのサービスコンテナ上に配置されているかを考慮することで、複数サービスコンテナをまたがってサービス同士の競合関係を管理することが可能とする。
【０１０６】
実施の形態４においては、サービスとそのサービスが配置されたサービスコンテナの関係を定義し、関係定義に基づいてサービスコンテナを考慮したサービスリソース間の関係から、サービスコンテナごとのサービス間の競合関係を判定するサービス実行管理方式について説明した。
【０１０７】
最後に、実施の形態１〜４に示した入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０のハードウェア構成例について説明する。
図２９は、実施の形態１〜４に示した入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０のハードウェア資源の一例を示す図である。
なお、図２９の構成は、あくまでも入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０のハードウェア構成の一例を示すものであり、入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０のハードウェア構成は図２９に記載の構成に限らず、他の構成であってもよい。
【０１０８】
図２９において、入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１〜４で説明した実行時情報記憶部１２１、定義情報格納部１２２、サービス実行サーバ１３０の記憶装置（図示は省略）、定義情報記憶部１１２は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１などは、出力装置の一例である。実施の形態１〜４で説明した入力端末１０５のディスプレイは、表示装置９０１等により実現される。
【０１０９】
通信ボード９１５は、図１、図１５、図２２に示すネットワーク１５０に接続されている。
例えば、ネットワーク１５０は、ＬＡＮ、インターネットの他、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などでも構わない。
【０１１０】
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
【０１１１】
また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
【０１１２】
また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
【０１１３】
上記プログラム群９２３には、実施の形態１〜４の説明において「〜部」（「〜記憶部」及び「〜格納部」以外、以下同様）として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
【０１１４】
ファイル群９２４には、実施の形態１〜４の説明において、「〜の判断」、「〜の計算」、「〜の比較」、「〜の照合」、「〜の参照」、「〜の検索」、「〜の抽出」、「〜の検査」、「〜の生成」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の入力」、「〜の受信」、「〜の接続」、「〜の作成」、「〜の挿入」、「〜の判定」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「ファイル」や「データベース」の各項目として記憶されている。
「ファイル」や「データベース」は、ディスクやメモリなどの記録媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示・移動・挿入・呼び出し・制御・判定・許可・禁止・識別などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示・移動・挿入・呼び出し・制御・判定・許可・禁止・識別などのＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜４で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【０１１５】
また、実施の形態１〜４の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態１〜４で説明したフローチャートに示すステップ、手順、処理により、本発明に係るサービス実行管理方法（ソフトウェア実行方法）を実現することができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、実施の形態１〜４の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１〜４の「〜部」の手順や方法をコンピュータに実行させるものである。
【０１１６】
このように、実施の形態１〜４に示す入力端末１０５、ＤＢサーバ１２０、サービス実行サーバ１３０、開発サーバ１１０は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【符号の説明】
【０１１７】
１００ サービス実行管理システム、１０５ 入力端末、１１０ 開発サーバ、１１１ 定義情報設定部、１１１ａ ルーティング定義部、１１１ｂ サービスリソース関係定義部、１１１ｃ アクセスポリシー定義部、１１２ 定義情報記憶部、１１２ａ ルーティング定義情報、１１２ｂ サービスリソース関係定義情報、１１２ｃ アクセスポリシー定義情報、１１３ 競合制御機能挿入部、１２０ ＤＢサーバ、１２１ 実行時情報記憶部、１２１ａ サービスリソース利用状態、１２２ 定義情報格納部、１３０ サービス実行サーバ、１３１ サービスコンテナ、１３２ 競合制御部、１３３ 競合判定部、１３４ 競合状態管理部、１３５ サービスリソース特定部、１５０ ネットワーク、３００ ルーティング定義画面、３０１ キャンバス、３０２ パレット、４００ アクセスポリシー定義画面、４０１ アクセスポリシー定義テーブル、４０２ 削除ボタン、４０３ 追加ボタン、４０４ 更新ボタン、４１１ リソースタイプ、４１２ 判定ロジック、４１３ アクセスタイム、４１４ アクセスポリシー、５００ サービスリソース関係定義画面、５０１ サービスリソース定義関係定義テーブル、５１１ サービス識別名、５１２ リソース識別名、９０１ 表示装置、９０２ キーボード、９０３ マウス、９０４ ＦＤＤ、９０５ コンパクトディスク装置、９１１ ＣＰＵ、９１２ バス、９１３ ＲＯＭ、９１４ ＲＡＭ、９１５ 通信ボード、９２０ 磁気ディスク装置、９２１ オペレーティングシステム、９２２ ウィンドウシステム、９２３ プログラム群、９２４ ファイル群、１４００ 条件情報、１４０１ アクセス状態、１４０２ 比較ポリシー、１４０３ 競合可否、１４０４ 変更後状態、１４１１ サービスコンテナ定義部、１４１２ サービスコンテナ定義情報、１４１３ サービスリソース関係抽出手段定義部、１４１４ サービスリソース関係抽出手段定義情報、１４３１ サービスリソース関係抽出部、１５００ サービスコンテナ定義画面、１５０１ サービスコンテナ定義テーブル、１５０５ コンテナ識別名、１５０６ コンテナタイプ、１５０７ 管理ＵＲＬ、１６００ サービスリソース関係抽出手段定義画面、１６０１ サービスリソース関係抽出手段定義テーブル、１６０５ 手段識別名、１６０７ 抽出手段、１８０５ スコープ。
【特許請求の範囲】
【請求項１】
第１のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第２のソフトウェアが前記第１のソフトウェアが利用している利用中リソースを利用して動作するか否かを判定するリソース判定部と、
前記リソース判定部により前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、前記第２のソフトウェアの前記利用中リソースの利用モードを判定し、前記第１のソフトウェアの前記利用中リソースの利用モードと前記第２のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第２のソフトウェアの起動の許否を判定する起動許否判定部と
を備えることを特徴とするソフトウェア実行システム。
【請求項２】
前記ソフトウェア実行システムは、更に、
先に動作している先行ソフトウェアの利用モードと後から起動される後続ソフトウェアの利用モードとの組み合わせであって、先行ソフトウェアと後続ソフトウェアとが同一のリソースを同時に利用することが許可される利用モードの組み合わせを同時利用許可条件として示し、
先に動作している先行ソフトウェアの利用モードと後から起動される後続ソフトウェアの利用モードとの組み合わせであって、先行ソフトウェアと後続ソフトウェアとが同一のリソースを同時に利用することが禁止される利用モードの組み合わせを同時利用禁止条件として示す条件情報を記憶する条件情報記憶部を備え、
前記起動許否判定部は、
前記第１のソフトウェアの前記利用中リソースの利用モードが、前記条件情報記憶部により記憶された条件情報の同時利用許可条件に示される先行ソフトウェアの利用モードと一致し、前記第２のソフトウェアの前記利用中リソースの利用モードが前記同時利用許可条件に示される後続ソフトウェアの利用モードと一致する場合に、前記第２のソフトウェアの起動を許可し、
前記第１のソフトウェアの前記利用中リソースの利用モードが、前記条件情報記憶部により記憶された条件情報の同時利用禁止条件に示される先行ソフトウェアの利用モードと一致し、前記第２のソフトウェアの前記利用中リソースの利用モードが前記同時利用禁止条件に示される後続ソフトウェアの利用モードと一致する場合に、前記第２のソフトウェアの起動を禁止することを特徴とする請求項１記載のソフトウェア実行システム。
【請求項３】
前記ソフトウェア実行システムは、更に、
前記第２のソフトウェアが利用するリソースと、前記第２のソフトウェアが利用するリソースの利用モードとを示すリソース情報を記憶するリソース情報記憶部を備え、
前記リソース判定部は、
前記リソース情報記憶部により記憶されたリソース情報が示す前記第２のソフトウェアが利用するリソースと、前記利用中リソースとが一致する場合に、前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定することを特徴とする請求項１又は２記載のソフトウェア実行システム。
【請求項４】
前記ソフトウェア実行システムは、更に、
前記第２のソフトウェアがリソースを利用する際に出力するコマンドを解析して、前記第２のソフトウェアが利用するリソースと、前記第２のソフトウェアが利用するリソースの利用モードとを識別するリソース識別部を備え、
前記リソース判定部は、
前記リソース識別部により識別された前記第２のソフトウェアが利用するリソースと、前記利用中リソースとが一致する場合に、前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定することを特徴とする請求項１又は２記載のソフトウェア実行システム。
【請求項５】
前記起動許否判定部は、
前記第２のソフトウェアの起動を禁止する場合に、前記第２のソフトウェアと関連付けられている他のソフトウェアの起動も禁止することを特徴とする請求項１〜４いずれか記載のソフトウェア実行システム。
【請求項６】
前記ソフトウェア実行システムは、更に、
各々が個別にリソースを管理し、各々が管理しているリソースを用いて複数のソフトウェアが動作する複数の計算機を備え、
前記リソース判定部は、
計算機ごとに、計算機で新たに起動する第２のソフトウェアが、当該計算機で動作中の第１のソフトウェアが利用中の前記計算機のリソースを利用して動作するか否かを判定することを特徴とする請求項１〜５いずれか記載のソフトウェア実行システム。
【請求項７】
前記第１のソフトウェア及び前記第２のソフトウェアは、ＳＯＡ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）におけるサービスアプリケーションであることを特徴とする請求項１〜６いずれか記載のソフトウェア実行システム。
【請求項８】
第１のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第２のソフトウェアが前記第１のソフトウェアが利用している利用中リソースを利用して動作するか否かを、コンピュータが判定するリソース判定ステップと、
前記リソース判定ステップにより前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、コンピュータが、前記第２のソフトウェアの前記利用中リソースの利用モードを判定し、前記第１のソフトウェアの前記利用中リソースの利用モードと前記第２のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第２のソフトウェアの起動の許否を判定する起動許否判定ステップと
を備えることを特徴とするソフトウェア実行方法。
【請求項９】
第１のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第２のソフトウェアが前記第１のソフトウェアが利用している利用中リソースを利用して動作するか否かを判定するリソース判定ステップと、
前記リソース判定ステップにより前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、前記第２のソフトウェアの前記利用中リソースの利用モードを判定し、前記第１のソフトウェアの前記利用中リソースの利用モードと前記第２のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第２のソフトウェアの起動の許否を判定する起動許否判定ステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項１】
第１のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第２のソフトウェアが前記第１のソフトウェアが利用している利用中リソースを利用して動作するか否かを判定するリソース判定部と、
前記リソース判定部により前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、前記第２のソフトウェアの前記利用中リソースの利用モードを判定し、前記第１のソフトウェアの前記利用中リソースの利用モードと前記第２のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第２のソフトウェアの起動の許否を判定する起動許否判定部と
を備えることを特徴とするソフトウェア実行システム。
【請求項２】
前記ソフトウェア実行システムは、更に、
先に動作している先行ソフトウェアの利用モードと後から起動される後続ソフトウェアの利用モードとの組み合わせであって、先行ソフトウェアと後続ソフトウェアとが同一のリソースを同時に利用することが許可される利用モードの組み合わせを同時利用許可条件として示し、
先に動作している先行ソフトウェアの利用モードと後から起動される後続ソフトウェアの利用モードとの組み合わせであって、先行ソフトウェアと後続ソフトウェアとが同一のリソースを同時に利用することが禁止される利用モードの組み合わせを同時利用禁止条件として示す条件情報を記憶する条件情報記憶部を備え、
前記起動許否判定部は、
前記第１のソフトウェアの前記利用中リソースの利用モードが、前記条件情報記憶部により記憶された条件情報の同時利用許可条件に示される先行ソフトウェアの利用モードと一致し、前記第２のソフトウェアの前記利用中リソースの利用モードが前記同時利用許可条件に示される後続ソフトウェアの利用モードと一致する場合に、前記第２のソフトウェアの起動を許可し、
前記第１のソフトウェアの前記利用中リソースの利用モードが、前記条件情報記憶部により記憶された条件情報の同時利用禁止条件に示される先行ソフトウェアの利用モードと一致し、前記第２のソフトウェアの前記利用中リソースの利用モードが前記同時利用禁止条件に示される後続ソフトウェアの利用モードと一致する場合に、前記第２のソフトウェアの起動を禁止することを特徴とする請求項１記載のソフトウェア実行システム。
【請求項３】
前記ソフトウェア実行システムは、更に、
前記第２のソフトウェアが利用するリソースと、前記第２のソフトウェアが利用するリソースの利用モードとを示すリソース情報を記憶するリソース情報記憶部を備え、
前記リソース判定部は、
前記リソース情報記憶部により記憶されたリソース情報が示す前記第２のソフトウェアが利用するリソースと、前記利用中リソースとが一致する場合に、前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定することを特徴とする請求項１又は２記載のソフトウェア実行システム。
【請求項４】
前記ソフトウェア実行システムは、更に、
前記第２のソフトウェアがリソースを利用する際に出力するコマンドを解析して、前記第２のソフトウェアが利用するリソースと、前記第２のソフトウェアが利用するリソースの利用モードとを識別するリソース識別部を備え、
前記リソース判定部は、
前記リソース識別部により識別された前記第２のソフトウェアが利用するリソースと、前記利用中リソースとが一致する場合に、前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定することを特徴とする請求項１又は２記載のソフトウェア実行システム。
【請求項５】
前記起動許否判定部は、
前記第２のソフトウェアの起動を禁止する場合に、前記第２のソフトウェアと関連付けられている他のソフトウェアの起動も禁止することを特徴とする請求項１〜４いずれか記載のソフトウェア実行システム。
【請求項６】
前記ソフトウェア実行システムは、更に、
各々が個別にリソースを管理し、各々が管理しているリソースを用いて複数のソフトウェアが動作する複数の計算機を備え、
前記リソース判定部は、
計算機ごとに、計算機で新たに起動する第２のソフトウェアが、当該計算機で動作中の第１のソフトウェアが利用中の前記計算機のリソースを利用して動作するか否かを判定することを特徴とする請求項１〜５いずれか記載のソフトウェア実行システム。
【請求項７】
前記第１のソフトウェア及び前記第２のソフトウェアは、ＳＯＡ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）におけるサービスアプリケーションであることを特徴とする請求項１〜６いずれか記載のソフトウェア実行システム。
【請求項８】
第１のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第２のソフトウェアが前記第１のソフトウェアが利用している利用中リソースを利用して動作するか否かを、コンピュータが判定するリソース判定ステップと、
前記リソース判定ステップにより前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、コンピュータが、前記第２のソフトウェアの前記利用中リソースの利用モードを判定し、前記第１のソフトウェアの前記利用中リソースの利用モードと前記第２のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第２のソフトウェアの起動の許否を判定する起動許否判定ステップと
を備えることを特徴とするソフトウェア実行方法。
【請求項９】
第１のソフトウェアが所定の利用モードで所定のリソースを利用して動作している場合に、新たに起動される第２のソフトウェアが前記第１のソフトウェアが利用している利用中リソースを利用して動作するか否かを判定するリソース判定ステップと、
前記リソース判定ステップにより前記第２のソフトウェアが前記利用中リソースを利用して動作すると判定された場合に、前記第２のソフトウェアの前記利用中リソースの利用モードを判定し、前記第１のソフトウェアの前記利用中リソースの利用モードと前記第２のソフトウェアの前記利用中リソースの利用モードとに基づき、前記第２のソフトウェアの起動の許否を判定する起動許否判定ステップと
をコンピュータに実行させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【公開番号】特開２０１３−２０４９４（Ｐ２０１３−２０４９４Ａ）
【公開日】平成２５年１月３１日（２０１３．１．３１）
【国際特許分類】
【出願番号】特願２０１１−１５３９７１（Ｐ２０１１−１５３９７１）
【出願日】平成２３年７月１２日（２０１１．７．１２）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
【公開日】平成２５年１月３１日（２０１３．１．３１）
【国際特許分類】
【出願日】平成２３年７月１２日（２０１１．７．１２）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
[ Back to top ]