(57)【要約】【課題】一連に呼び出される処理を実行させるときに、無駄な呼び出しを削減すること。【解決手段】一連処理実行装置１は、一連処理の構成要素であるすべての個別処理に対する個別予約がイネーブラ提供装置７に対して成功したときに、前記一連処理の実行を許可するとともに、前記一連処理の構成要素である個別処理に対する個別予約のうちの少なくとも１つの個別予約が失敗したときに、前記一連処理の実行を不許可とし、前記一連処理の実行要求を受信し、その一連処理の実行を許可されているときには、個別予約をした前記イネーブラ提供装置７に対して、前記一連処理の構成要素である各個別処理を実行させる。【選択図】図６
2016001355.tif 000002
【特許請求の範囲】
【請求項１】
複数の個別処理から構成される一連処理のための予約要求を受信し、個別処理を行うためのリソースを提供するイネーブラ提供装置に対して、個別処理ごとに要するリソース量を予約する個別予約を実行し、
前記一連処理の構成要素であるすべての個別処理に対する個別予約が成功したときに、前記一連処理の実行を許可するとともに、前記一連処理の構成要素である個別処理に対する個別予約のうちの少なくとも１つの個別予約が失敗したときに、前記一連処理の実行を不許可とする予約制御部と、
前記一連処理の実行要求を受信し、その一連処理の実行を許可されているときには、個別予約をした前記イネーブラ提供装置に対して、前記一連処理の構成要素である各個別処理を実行させる実行制御部と、を有することを特徴とする
一連処理実行装置。
【請求項２】
前記実行制御部は、前記イネーブラ提供装置のリソースを予約しない実行処理よりも、前記イネーブラ提供装置のリソースを予約する前記個別処理に対して、前記イネーブラ提供装置のリソースを優先的に使用させることを特徴とする
請求項１に記載の一連処理実行装置。
【請求項３】
前記実行制御部は、実行してエラーとなる個別処理が存在する場合には、その個別処理が属する前記一連処理の他の個別処理もエラーとみなすことを特徴とする
請求項１または請求項２に記載の一連処理実行装置。
【請求項４】
前記予約制御部は、前記一連処理の実行を許可した後の所定期間に前記一連処理が開始されない場合、タイムアウトとして、前記一連処理を構成する各個別処理に対する個別予約を解放することを特徴とする
請求項１ないし請求項３のいずれか１項に記載の一連処理実行装置。
【請求項５】
一連処理実行装置は、予約制御部と、実行制御部とを有しており、
前記予約制御部は、
複数の個別処理から構成される一連処理のための予約要求を受信し、個別処理を行うためのリソースを提供するイネーブラ提供装置に対して、個別処理ごとに要するリソース量を予約する個別予約を実行し、
前記一連処理の構成要素であるすべての個別処理に対する個別予約が成功したときに、前記一連処理の実行を許可するとともに、前記一連処理の構成要素である個別処理に対する個別予約のうちの少なくとも１つの個別予約が失敗したときに、前記一連処理の実行を不許可とし、
前記実行制御部は、
前記一連処理の実行要求を受信し、その一連処理の実行を許可されているときには、個別予約をした前記イネーブラ提供装置に対して、前記一連処理の構成要素である各個別処理を実行させることを特徴とする
一連処理実行方法。
【請求項６】
一連処理実行装置は、実行制御部と、予約制御部とを有しており、
前記実行制御部は、
複数の個別処理から構成される一連処理の実行要求を受信し、
前記予約制御部は、
前記個別処理を行うためのリソースを提供するイネーブラ提供装置に対して、個別処理ごとに要するリソース量を予約する個別予約を実行し、
前記一連処理の構成要素であるすべての個別処理に対する個別予約が成功したときに、前記一連処理の実行を許可するとともに、前記一連処理の構成要素である個別処理に対する個別予約のうちの少なくとも１つの個別予約が失敗したときに、前記一連処理の実行を不許可とし、
前記実行制御部は、
前記一連処理の実行を許可されているときには、個別予約をした前記イネーブラ提供装置に対して、前記一連処理の構成要素である各個別処理を実行させることを特徴とする
一連処理実行方法。
【請求項７】
請求項５または請求項６に記載の一連処理実行方法を、コンピュータである前記一連処理実行装置に実行させるための一連処理実行プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一連処理実行装置、一連処理実行方法、および、一連処理実行プログラムの技術に関する。
【背景技術】
【０００２】
非特許文献１には、送信側と受信側との通信経路の途中に位置するアクセスポイントが、通信経路に過剰に流れるトラヒックに対してパケット廃棄などの流量制御を実施することで、他の通信中のトラヒックに対する通信品質劣化を防止し、安定した通信を提供するシステムが提案されている。
ここで、流量制御の度合いを決定するために、あらかじめ通信量の上限値を定めておく。そして、その上限値からの超過分を過剰トラヒックとみなして廃棄対象とする。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】ＮＴＴアクセスサービスシステム研究所、"6.トラヒック流量制御技術"、［online］、［平成26年2月10日検索］、インターネット〈URL：http://www.ansl.ntt.co.jp/j/times/051/01/06.html〉
【発明の概要】
【発明が解決しようとする課題】
【０００４】
アプリケーションを実行する装置が、外部に機能を提供するイネーブラ（Enabler）に対して、その機能を呼び出すためのＡＰＩ（Application Programming Interface）呼び出しを行う形態が普及している。これにより、アプリケーションの開発者は、自身でイネーブラが提供する機能を実装しなくて済むため、開発コストを削減することができる。
【０００５】
Web APIを用いたサービスでは、１つのサービスを実現するために、複数のＡＰＩ呼び出しが組み合わされて一連に呼び出される場合も多い。そのときに、どれか１つのＡＰＩ呼び出しが実行不可であると、サービスを提供できないだけでなく、実行不可であるＡＰＩ呼び出しよりも前に実行したＡＰＩ処理が無駄になってしまう。
【０００６】
非特許文献１のシステムのように、単に上限値からの超過分を廃棄対象とするだけでは、イネーブラへの過剰な負荷をある程度削減できるものの、一連に呼び出されるＡＰＩ呼び出しを対象として、無駄なＡＰＩ呼び出しを削減することは困難である。
【０００７】
そこで、本発明は、一連に呼び出される処理を実行させるときに、無駄な呼び出しを削減することを、主な課題とする。
【課題を解決するための手段】
【０００８】
前記課題を解決するために、本発明は、複数の個別処理から構成される一連処理のための予約要求を受信し、個別処理を行うためのリソースを提供するイネーブラ提供装置に対して、個別処理ごとに要するリソース量を予約する個別予約を実行し、前記一連処理の構成要素であるすべての個別処理に対する個別予約が成功したときに、前記一連処理の実行を許可するとともに、前記一連処理の構成要素である個別処理に対する個別予約のうちの少なくとも１つの個別予約が失敗したときに、前記一連処理の実行を不許可とする予約制御部と、前記一連処理の実行要求を受信し、その一連処理の実行を許可されているときには、個別予約をした前記イネーブラ提供装置に対して、前記一連処理の構成要素である各個別処理を実行させる実行制御部と、を有することを特徴とする。
【０００９】
これにより、一連処理の単位でリソースを事前確保するので、一連に呼び出される処理を実行させるときに、無駄な呼び出しを削減することができる。
【００１０】
本発明は、前記実行制御部が、前記イネーブラ提供装置のリソースを予約しない実行処理よりも、前記イネーブラ提供装置のリソースを予約する前記個別処理に対して、前記イネーブラ提供装置のリソースを優先的に使用させることを特徴とする。
【００１１】
これにより、実行開始された一連処理に対して事前予約されたリソースが優先的に割り当てられるので、リソースの予約から消費までの待ち時間を短縮でき、リソースの有効活用ができる。
【００１２】
本発明は、前記実行制御部が、実行してエラーとなる個別処理が存在する場合には、その個別処理が属する前記一連処理の他の個別処理もエラーとみなすことを特徴とする。
【００１３】
これにより、実行する必要がなくなった個別処理を実行する無駄を省くことができる。
【００１４】
本発明は、前記予約制御部が、前記一連処理の実行を許可した後の所定期間に前記一連処理が開始されない場合、タイムアウトとして、前記一連処理を構成する各個別処理に対する個別予約を解放することを特徴とする。
【００１５】
これにより、リソースの予約から消費までの待ち時間が長い無駄なリソース予約を削減できる。
【発明の効果】
【００１６】
本発明によれば、一連に呼び出される処理を実行させるときに、無駄な呼び出しを削減することができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態に関する一連処理実行システムによる一連処理の第１段階（図１（ａ））、第２段階（図１（ｂ））を示す説明図である。
【図２】本発明の一実施形態に関する一連処理実行システムによる一連処理の第３段階（図２（ａ））、第４段階（図２（ｂ））を示す説明図である。
【図３】本発明の一実施形態に関する一連処理実行システムによる一連処理の第５段階（図３（ａ））、第６段階（図３（ｂ））を示す説明図である。
【図４】本発明の一実施形態に関する一連処理実行システムの一連予約に関する処理部を示す構成図である。
【図５】本発明の一実施形態に関する一連処理管理テーブル（図５（ａ））およびリソース管理テーブル（図５（ｂ））を示す構成図である。
【図６】本発明の一実施形態に関する一連処理実行システムの一連実行に関する処理部を示す構成図である。
【発明を実施するための形態】
【００１８】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００１９】
図１（ａ）は、一連処理実行システムの第１段階を示す説明図である。
一連処理実行システムは、アプリ実行装置８ａ〜８ｃと、一連処理実行装置１と、イネーブラ提供装置７ａ，７ｂとを含めて構成される。
これらの一連処理実行システムの各装置は、ＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
【００２０】
イネーブラ提供装置７ａ，７ｂは、機能を提供する実体であり、バックエンドシステムとも呼ばれる。例えば、イネーブラ提供装置７ａは、セキュリティ機能およびＳＭＳ（Short Message Service）機能を提供し、イネーブラ提供装置７ｂは、クラウド制御機能を提供する。
一連処理実行装置１は、各イネーブラ提供装置７が提供するイネーブラの機能を束ねて、ＡＰＩとしてアプリ実行装置８ａ〜８ｃに提供する。
アプリ実行装置８ａ〜８ｃは、アプリケーション（アプリと略す）を実行する装置であり、そのアプリの実行中にイネーブラ提供装置７ａ，７ｂの機能を呼び出すための個別処理を一連処理実行装置１に依頼する。
【００２１】
ここで、本実施形態で主に使用する用語を定義する。
「個別処理」とは、一連処理実行装置１がＡＰＩを介して実行する個別のＡＰＩ処理である。
「個別予約」とは、イネーブラ提供装置７ａ，７ｂの提供するリソースを個別処理ごとに予約する処理である。つまり、１つの個別処理が実行される前に、１つの個別予約が行われる。なお、ベストエフォート（品質無保証）の個別処理を行うときには、個別予約は不要である。
「一連処理」とは、同じアプリ実行装置８ａ〜８ｃから実行を要求される１つ以上の個別処理をグルーピングした処理であり、それらの個別処理を実行順序に従って並べたものである。
「一連予約」とは、一連処理の構成要素である個別処理ごとの個別予約をグルーピングした予約の束である。つまり、１つの一連処理が実行される前に、１つの一連予約が行われる。
【００２２】
なお、図１（ａ）のアプリ実行装置８ａには「１ａ，１ｂ，１ｃ」の記号が付加され、アプリ実行装置８ｂには「２ａ，２ｂ，２ｃ」の記号が付加され、アプリ実行装置８ｃには「３ａ，３ｂ，３ｃ」の記号が付加されている。これらの記号は、個別処理と一連処理とを例示したものである。例えば、アプリ実行装置８ａは、「１ａ，１ｂ，１ｃ」という３つの個別処理を、１つの一連処理（同じアプリ実行装置８ａから要求される複数の個別処理）として一連処理実行装置１に要求している旨を示す。
【００２３】
そして、図１（ａ）の個別処理１ａからイネーブラ提供装置７ａへは、破線の矢印が接続されている。この破線矢印は予約関係を示すものであり、例えば、個別処理１ａを実行するための個別予約がイネーブラ提供装置７ａのリソースに対して行われている旨を示す。
また、図１（ｂ）の個別処理１ａからイネーブラ提供装置７ａへは、実線の矢印が接続されている。この実線矢印は実行関係を示すものであり、例えば、個別処理１ａの実行がイネーブラ提供装置７ａのリソースに対して行われている旨を示す。
【００２４】
一連処理実行装置１は、以下に示すルールＲ１〜Ｒ４のうちの少なくとも１つのルールに従って、一連処理を実行する。
「ルールＲ１」は、一連予約が成功した後に、一連処理の実行を許可（開始）するルールである。つまり、一連処理実行装置１は、一連予約を構成するすべての個別予約が成功した後に、一連処理を構成する最初の個別処理の実行を許可（開始）する。一方、最初の個別処理に対する個別予約が成功していても、一連処理を構成する最後の個別処理に対する個別予約が成功するまでは、最初の個別処理は開始されない。
これにより、一連処理を構成する個別処理の実行は、それぞれ個別予約によりリソースがあらかじめ確保されているので、一連処理の実行を保証することができる。
【００２５】
「ルールＲ２」は、リソースを予約しない（ベストエフォートの）ＡＰＩ実行処理よりも、リソースを予約する個別処理に対して、イネーブラ提供装置７のリソースを優先的に使用させるルールである。その結果、ベストエフォートのＡＰＩ実行処理は、リソース不足により、実行時間が長くかかったり、実装できずにエラーとなったりする場合もある。
「ルールＲ３」は、実行してエラーとなる個別処理が存在する場合には、その個別処理が属する一連処理の他の個別処理も実行成否や未実行にかかわらずエラー応答する旨のルールである。
「ルールＲ４」は、一連予約が成功した後の所定期間に一連処理が開始されない場合、または、一連処理を構成する前の個別処理を実行した後の所定期間に、一連処理を構成する後の個別処理が開始されない場合には、タイムアウトとして、一連予約を構成する個別予約を解放する旨のルールである。
以下、図１〜図３を参照して、ルールＲ１〜Ｒ４を適用した各処理を説明する。
【００２６】
図１（ａ）の第１段階では、アプリ実行装置８ａが、ルールＲ１に従い、個別処理１ａ〜１ｃを束ねた一連処理を行う前準備として、その一連予約を一連処理実行装置１に依頼する。一連処理実行装置１は、個別処理１ａ，１ｃのための個別予約をイネーブラ提供装置７ａに対して実施し、個別処理１ｂのための個別予約をイネーブラ提供装置７ｂに対して実施する。この３つの個別予約（個別処理１ａ，１ｂ，１ｃ）は、すべて成功した（つまり、一連予約に成功した）ものとする。
【００２７】
図１（ｂ）の第２段階では、一連処理実行装置１は、ルールＲ１に従い、一連予約に成功したアプリ実行装置８ａの一連処理（個別処理１ａ〜１ｃ）の実行を許可する。そして、個別処理１ａ，１ｂが、順に実行される。
また、アプリ実行装置８ｂは、ベストエフォート（予約不要）の３つの個別処理２ａ，２ｂ，２ｃを一連処理実行装置１に依頼する。一連処理実行装置１は、依頼された個別処理２ａをイネーブラ提供装置７ｂに対して実行させる。
ここで、同じイネーブラ提供装置７ｂで実行される２つの個別処理１ｂ，２ａについて、ルールＲ２に従い、個別処理１ｂには個別処理２ａよりも優先的に多くのリソースが割り当てられる。
【００２８】
図２（ａ）の第３段階では、第２段階で優先された一連処理（個別処理１ａ〜１ｃ）がすべて成功し、イネーブラ提供装置７ａ，７ｂからアプリ実行装置８ａに対して正常応答が送信される。一方、第２段階で優先されなかった個別処理２ａは、実行中である。
図２（ｂ）の第４段階では、イネーブラ提供装置７ｂには、リソース不足により輻輳が発生してしまう。よって、今後、イネーブラ提供装置７ｂには、リソースの予約が困難となる。
【００２９】
図３（ａ）の第５段階では、一連処理実行装置１は、アプリ実行装置８ｂから依頼された残りの個別処理２ｂ，２ｃをイネーブラ提供装置７ａに対して実行し、この実行は成功する。
さらに、一連処理実行装置１は、アプリ実行装置８ｃから３つの個別予約（個別処理３ａ，３ｂ，３ｃ）を束ねた一連処理を受け付け、そのための一連予約を試みる。しかし、イネーブラ提供装置７ｂのリソース不足により、個別処理３ｂのための個別予約は、失敗してしまう。
【００３０】
図３（ｂ）の第６段階では、一連処理実行装置１は、ルールＲ３に従い、個別処理３ｂの失敗によって、その個別処理３ｂが属する一連処理の他の個別処理３ａ，３ｃも失敗とみなす。これにより、個別処理３ａの個別予約は成功していたものの、そのエラー応答がアプリ実行装置８ｃに送信される。
また、失敗とみなされた個別処理３ａについての個別予約は、キャンセル（リソース解放）される。さらに、個別処理３ｃの個別予約は未実行であるものの、そのエラー応答がアプリ実行装置８ｃに送信される。
以上説明したように、一連処理実行装置１は、リソース不足によりリソースが保証できる見込みのないアプリ実行装置８ｃからの個別処理３ａ，３ｂ，３ｃを、実際に実行する前に中断することができる。
さらに、一連処理実行装置１は、リソースが保証できるアプリ実行装置８ａからの個別処理１ａ，１ｂ，１ｃを一連処理として優先させることで、イネーブラ提供装置７ａ，７ｂのリソースを有効活用することができる。
【００３１】
図４は、一連処理実行システムの一連予約に関する処理部（予約制御部）を示す構成図である。
一連処理実行装置１は、一連処理登録受付部１１ａと、一連処理登録応答部１１ｂと、リソース予約依頼部２１ａと、リソース予約受付部２１ｂと、一連処理判定部１３と、一連処理登録部１４と、タイマ機能部１７と、一連処理管理テーブル１９と、リソース管理テーブル２９とを含めて構成される。
【００３２】
一連処理登録受付部１１ａは、アプリ実行装置８（図１でのアプリ実行装置８ａ〜８ｃ）から受信した登録開始要求に含まれる一連処理（個別処理の束）のための一連予約を、リソース予約依頼部２１ａに指示する。
なお、「登録開始要求」とは、各アプリ実行装置８から一連処理実行装置１に対して送信される要求メッセージのうちの「一連予約」を開始する旨のメッセージである。
リソース予約依頼部２１ａは、イネーブラ提供装置７（図１でのイネーブラ提供装置７ａ，７ｂ）に対して一連予約を構成する個別予約を実施する。個別予約では、個別処理の特定情報と、その個別処理が要するリソース量とが指定される。予約結果は、リソース管理テーブル２９（詳細は後記）、リソース予約受付部２１ｂへと通知される。
【００３３】
ここで、リソース予約依頼部２１ａは、１つの個別処理を行うための１つの個別予約を行ってもよいし、複数の個別処理を行うためのリソースが同じイネーブラ提供装置７を対象とする場合、その複数の個別処理を行うためのリソース量の総和をまとめて、１つの個別予約としてもよい。
例えば、図１（ａ）では、個別処理１ａと個別処理１ｃとは、同じイネーブラ提供装置７ａを対象として個別予約が行われる。ここで、個別処理１ａでリソース量「１０」を要し、個別処理１ｃでリソース量「５」を要するときに、リソース予約依頼部２１ａは、イネーブラ提供装置７ａに対して「１５＝１０＋５」のリソース量の個別予約を行ってもよい。
【００３４】
一連処理判定部１３は、リソース予約受付部２１ｂから受信した個別予約の結果を束ね、ルールＲ１に従い、登録開始要求に含まれる各個別処理の個別予約がすべて成功したときに、その登録開始要求の一連予約が成功する（つまり、ルールＲ１に従って、一連処理の実行を許可する）と判定する。
一連処理登録部１４は、一連処理判定部１３が実行可と判定した登録開始要求を一連処理管理テーブル１９およびタイマ機能部１７（詳細は後記）に登録する。
【００３５】
図５（ａ）は、一連処理管理テーブル１９を示す構成図である。一連処理管理テーブル１９は、一連処理ＩＤと、その一連処理の構成要素である個別処理ＩＤと、一連処理の登録日時と、登録開始要求の送信元であるアプリ実行装置８のアプリＩＤとを対応づけて管理する。
例えば、一連処理管理テーブル１９の第１行には、「アプリ1」のアプリ実行装置８から要求された一連処理ＩＤ「API_group_1」が示す一連処理は、２つの個別処理（API1、API2の順に実行される）から構成され、その登録日時は「2014-04-07-13:00:12」であり、すでに最初の個別処理（API1）の実行が開始されたことを示す。
【００３６】
図５（ｂ）は、リソース管理テーブル２９を示す構成図である。リソース管理テーブル２９は、一連処理管理テーブル１９の一連処理ＩＤに対して、その一連処理を構成する個別処理が使用するイネーブラＩＤと、その個別処理が要する個別処理リソース量と、イネーブラＩＤのイネーブラが提供するイネーブラリソース量とが対応づけられている。
例えば、一連処理管理テーブル１９の第１行には、一連処理ＩＤ「API_group_1」の一連予約の１つとして、イネーブラＩＤ「イネーブラ1」が提供するイネーブラリソース量「10」のうちの個別処理で要するリソース量「10」を消費する旨の個別予約がなされている旨を示す。
なお、リソース量の指標として、1秒間あたりのＡＰＩ処理数を示すＴＰＳ（Transaction Per Sec）や、同時に接続するセッション数を示す同時接続数などが挙げられる。
【００３７】
また、個別処理リソース量と、イネーブラリソース量との関係について、イネーブラリソース量を超過しない範囲で個別処理リソース量を消費してもよい。
一方、イネーブラ提供装置７ごとにそのイネーブラリソース量に余裕があるうちは、事前に予約したイネーブラリソース量を超過して個別処理リソース量の消費を許可し、イネーブラ提供装置７のイネーブラリソース量に余裕が無くなった時点で、事前に予約したイネーブラリソース量からの超過分の個別処理リソース量の消費を不許可としてもよい。
【００３８】
図４に戻って、一連処理登録応答部１１ｂは、一連処理登録部１４が登録した結果、または、一連処理判定部１３で実行不可と判定された結果を、登録開始要求への依頼結果として、その登録開始要求の送信元のアプリ実行装置８に返答する。ここで、一連処理登録応答部１１ｂは、ルールＲ１に従って、一連予約の構成要素である個別予約がすべて成功したときに一連予約が成功した旨を返信する。
【００３９】
図６は、一連処理実行システムの一連実行に関する処理部（実行制御部）を示す構成図である。一連処理実行装置１は、図４で列挙した構成に加え、一連処理実行受付部１２ａと、一連処理実行応答部１２ｂと、一連処理削除部１５と、処理実行部１６と、リソース解放依頼部２２ａと、リソース解放受付部２２ｂを含めて構成される。以下、一連処理が正常に実行された場合（図１〜図３では、個別処理１ａ〜１ｃ）に着目して、一連処理実行装置１の各処理部を説明する。
【００４０】
一連処理実行受付部１２ａは、アプリ実行装置８から実行開始要求を受信すると、その実行開始要求に含まれる個別処理（公開されたＡＰＩを指定した処理）を処理順序に従って１つずつ順番に処理実行部１６に通知する。
「実行開始要求」とは、各アプリ実行装置８から一連処理実行装置１に対して送信される要求メッセージのうちの「一連処理」を開始する旨のメッセージである。
【００４１】
処理実行部１６は、ルールＲ１に従い、通知された個別処理のうちのリソース管理テーブル２９で個別予約されていない個別処理、および、一連処理管理テーブル１９に登録されていない（一連予約されてない）個別処理をそれぞれ実行対象から除外する。除外された個別処理は、エラー応答されるか、除外要因が無くなるまで処理待ちされる。
そして、処理実行部１６は、除外されなかった実行対象の個別処理について、ルールＲ２に従って、リソースの割り当ての優先度合いを指定させて実行する。
【００４２】
さらに、処理実行部１６は、イネーブラ提供装置７から「正常」の実行結果を受信すると、その旨をリソース解放依頼部２２ａに通知することで、リソース管理テーブル２９から今回実行された個別処理についての個別予約を解放する。
リソース解放受付部２２ｂは、リソース管理テーブル２９から個別予約の解放を読み取ると、今回の解放をもって、一連処理管理テーブル１９に登録された一連予約がすべて解放された（つまり、一連処理がすべて実行された）か否かを判定する。
【００４３】
一連処理削除部１５は、一連予約がすべて解放されたことをリソース解放受付部２２ｂから通知されると、その一連予約に関するレコードを一連処理管理テーブル１９から削除（登録解除）するとともに、実行開始要求への正常応答を一連処理実行応答部１２ｂ経由で、アプリ実行装置８に返答する。
【００４４】
次に、一連処理がエラーとなった場合（図１〜図３では、個別処理３ａ〜３ｃ）に着目して、一連処理実行装置１の各処理部を説明する。
処理実行部１６は、イネーブラ提供装置７から「エラー」の（個別予約または個別実行に失敗した旨の）実行結果を受信すると、正常の実行結果と同様に、リソース解放依頼部２２ａを介して、リソース管理テーブル２９から今回の個別予約を解放する。
さらに、処理実行部１６は、ルールＲ３に従い、一連処理のうちのエラーの個別処理とは別の個別処理の予約や実行を省略する。省略された個別処理の個別予約は、リソース管理テーブル２９から事前キャンセルされるとともに、実行開始要求へのエラー応答が、一連処理実行応答部１２ｂを介して、アプリ実行装置８に返答される。
【００４５】
さらに、タイマ管理に着目して、一連処理実行装置１の各処理部を説明する。
タイマ機能部１７は、ルールＲ４を実現するために、実行開始要求への応答（一連予約ＯＫ）送信時刻または一連処理管理テーブル１９への登録時刻を起点時刻として、タイマを開始する。そして、タイマ機能部１７は、起点時刻からの経過時間（タイマ時間）が所定時間経過しても処理実行部１６によって一連処理が実行されない場合は、時間切れで一連処理を失敗と判定する。
失敗の場合、タイマ機能部１７は、前記したエラーの実行結果を受信したときと同様に、リソース管理テーブル２９の個別予約をそれぞれキャンセルし、一連処理管理テーブル１９の一連予約のレコードを削除し、実行開始要求へのエラー応答をアプリ実行装置８に返答する。
【００４６】
以上、登録開始要求に従った一連予約処理（図４）と、実行開始要求に従った一連処理（図６）とを説明した。
一方、一連処理実行装置１（一連処理実行受付部１２ａ）は、登録開始要求を受信せずに、一連処理が指定された実行開始要求を受信することもある。その場合は、一連予約がなされていないことを理由として、エラーを応答する代わりに、実行開始要求に含まれる一連処理の一連予約を行い（図４で説明した各実行部の処理を呼び出し）、その後に、実行開始要求に従った一連処理（図６）を実行すればよい。
これにより、アプリ実行装置８は、登録開始要求と実行開始要求という２つの要求を個別に送信しなくて済むので（換言すると、実行開始要求が登録開始要求の役割も兼任するので）、一連処理の実行時間を短縮できる。
【００４７】
以上説明した本実施形態では、一連処理実行装置１がルールＲ１に従い、一連予約を完結してから一連処理の実行を開始することで、一連処理中のリソース不足を事前に回避し、一連処理の実行を保証する。よって、一連処理実行装置１は、一連処理という大きな粒度でリソースの確保状況を管理することで、個別処理という小さな粒度でのリソース不足を防止できる。
これにより、イネーブラ提供装置７に輻輳が発生したなどの理由で、一連処理が途中までしか実行されないような低効率な状態を低減し、Web APIを活用したサービスやアプリケーションの実行品質を向上させることができる。
【符号の説明】
【００４８】
１      一連処理実行装置
７      イネーブラ提供装置
８      アプリ実行装置
１１ａ  一連処理登録受付部
１１ｂ  一連処理登録応答部
１２ａ  一連処理実行受付部
１２ｂ  一連処理実行応答部
１３    一連処理判定部
１４    一連処理登録部
１５    一連処理削除部
１６    処理実行部
１７    タイマ機能部
１９    一連処理管理テーブル
２１ａ  リソース予約依頼部
２１ｂ  リソース予約受付部
２２ａ  リソース解放依頼部
２２ｂ  リソース解放受付部
２９    リソース管理テーブル
【図１】
2016001355.tif 000003
【図２】
2016001355.tif 000004
【図３】
2016001355.tif 000005
【図４】
2016001355.tif 000006
【図５】
2016001355.tif 000007
【図６】
2016001355.tif 000008