(57)【要約】  サービス連携装置（１）は、オーダ管理ＤＢ（１５）に登録された連携オーダをオーダ管理ＤＢ（１５）から読み出して実行することで、連携サービスの使用リソース上に生成された連携サービスのインスタンスに対する処理を行うオーダ実行部（１３）と、同じインスタンスを処理対象とするために競合する複数の連携オーダがオーダ実行部（１３）によって同時期に実行される前に、競合する複数の連携オーダのうちの先に実行が開始された連携オーダを優先しつつ、その他の連携オーダを実行させないことで、連携オーダ間の排他制御を行う排他制御部（１４）とを有する。
2019159939.tif 000002
【特許請求の範囲】
【請求項１】
複数のサービスを連携させた連携サービスを実行させるための連携オーダを受け付けるオーダ受付部と、
前記オーダ受付部が受け付けた連携オーダをオーダ管理ＤＢに登録するオーダ管理部と、
前記オーダ管理ＤＢに登録された連携オーダを読み出して実行することで、前記連携サービスの使用リソース上に生成された前記連携サービスのインスタンスに対する処理を行うオーダ実行部と、
同じインスタンスを処理対象とするために競合する複数の連携オーダが前記オーダ実行部によって同時期に実行される前に、競合する複数の連携オーダのうちの先に実行が開始された連携オーダを優先しつつ、その他の連携オーダを実行させないことで、連携オーダ間の排他制御を行う排他制御部とを有することを特徴とする
サービス連携装置。
【請求項２】
前記オーダ実行部は、前記オーダ管理ＤＢから読み出して実行した連携オーダを実行状態とし、
前記排他制御部は、前記オーダ受付部が新たな連携オーダを受け付けたときに、競合する他の実行状態である連携オーダが存在するときは、前記新たな連携オーダを前記オーダ管理ＤＢに登録しないようにすることを特徴とする
請求項１に記載のサービス連携装置。
【請求項３】
前記オーダ実行部は、前記オーダ管理ＤＢから読み出して実行した連携オーダを実行状態とし、
前記排他制御部は、前記オーダ管理ＤＢから所定の連携オーダを読み出して実行するときに、競合する他の実行状態である連携オーダが存在するときは、前記所定の連携オーダを実行しないようにすることを特徴とする
請求項１に記載のサービス連携装置。
【請求項４】
前記オーダ受付部は、オーダ実行日時が指定された予約オーダと、オーダ実行日時の指定が無い即時オーダとをそれぞれ前記オーダ管理ＤＢに受付状態として登録し、
前記排他制御部は、前記オーダ受付部が新たな即時オーダを受け付けたときに、競合する他の受付状態である即時オーダが存在するときは、前記新たな即時オーダを前記オーダ管理ＤＢに登録しないようにすることを特徴とする
請求項１に記載のサービス連携装置。
【請求項５】
前記オーダ管理部は、
前記オーダ管理ＤＢに登録されている予約オーダに対して、そのオーダ実行日時またはインスタンスへの処理内容を変更する旨のオーダ変更要求を受け付けると、前記オーダ管理ＤＢから該当する予約オーダを検索し、
該当する予約オーダが前記オーダ管理ＤＢに登録されていないとき、または、該当する予約オーダが受付状態ではないときには、受け付けたオーダ変更要求を前記オーダ管理ＤＢに反映させないようにすることを特徴とする
請求項４に記載のサービス連携装置。
【請求項６】
オーダ受付部と、オーダ管理ＤＢと、オーダ管理部と、オーダ実行部と、排他制御部とを有するサービス連携装置によって実行されるサービス連携方法であって、
前記オーダ受付部は、複数のサービスを連携させた連携サービスを実行させるための連携オーダを受け付け、
前記オーダ管理部は、前記オーダ受付部が受け付けた連携オーダを前記オーダ管理ＤＢに登録し、
前記オーダ実行部は、前記オーダ管理ＤＢに登録された連携オーダを読み出して実行することで、前記連携サービスの使用リソース上に生成された前記連携サービスのインスタンスに対する処理を行い、
前記排他制御部は、同じインスタンスを処理対象とするために競合する複数の連携オーダが前記オーダ実行部によって同時期に実行される前に、競合する複数の連携オーダのうちの先に実行が開始された連携オーダを優先しつつ、その他の連携オーダを実行させないことで、連携オーダ間の排他制御を行うことを特徴とする
サービス連携方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス連携装置、および、サービス連携方法に関する。
【背景技術】
【０００２】
各サービス事業者は、ネットワーク（NW）、クラウド（Cloud）、アプリ（APL）などの卸サービスを個別に提供する。そして、サービス事業者間で複数の卸サービスを連携させる連携サービスが構築される機会が増えている。連携サービスでは、サービスを実行させるためのオーダである「連携オーダ」に従って、ＡＰＩ（Application Programming Interface）を介して、各種の卸サービスが利用される。【０００３】
特許文献１には、複数のネットワークサービスのリソース予約方法として、使用可能性の低いリソースの占有やＮＷ事業者のＯｐＳ（Operation System）の処理負荷の増大を回避して、サービス予約を可能とするサービス予約方法が記載されている。
非特許文献１には、複数事業者間でサービスを連携させるときに、連携対象となるサービス仕様を定義したカタログを用意し、そのカタログの記述方法として「構成要素」と「アクションルール」とを分離させるアーキテクチャが記載されている。これにより、新たな連携対象サービスやＡＰＩへの追従を柔軟に実現する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１７−１４３４２６号公報
【非特許文献】
【０００５】
【非特許文献１】高橋謙輔、他、「複数事業者間サービス連携を柔軟にするアーキテクチャ」、電子情報通信学会（IEICE）  通信ソサエティ大会、2017年9月12日
【発明の概要】
【発明が解決しようとする課題】
【０００６】
連携サービスでは、複数の卸サービスを連携させる複雑な構成を採用するために、いつ、どのような連携オーダを受けて、どのようにリソースを使用させるかというオーダ管理も複雑になる。しかし、従来のオーダ管理システムでは、複雑な連携サービスに対するオーダ管理としては、ユーザにとってはやや不満が残っていた。【０００７】
不満点として、例えば、連携オーダを発行するときに、同じリソースを使用する連携オーダが同時期に競合してしまうこともある。この競合状態をオーダ管理システムの側では事前に対処できず、実際にリソース上で競合処理が実行されてしまい、不便であった。【０００８】
そこで、本発明は、複数の卸サービスを連携させる連携サービスのオーダを、適切に管理することを、主な課題とする。
【課題を解決するための手段】
【０００９】
前記課題を解決するために、本発明のサービス連携装置は、以下の特徴を有する。
本発明は、複数のサービスを連携させた連携サービスを実行させるための連携オーダを受け付けるオーダ受付部と、
前記オーダ受付部が受け付けた連携オーダをオーダ管理ＤＢに登録するオーダ管理部と、
前記オーダ管理ＤＢに登録された連携オーダを読み出して実行することで、前記連携サービスの使用リソース上に生成された前記連携サービスのインスタンスに対する処理を行うオーダ実行部と、
同じインスタンスを処理対象とするために競合する複数の連携オーダが前記オーダ実行部によって同時期に実行される前に、競合する複数の連携オーダのうちの先に実行が開始された連携オーダを優先しつつ、その他の連携オーダを実行させないことで、連携オーダ間の排他制御を行う排他制御部とを有することを特徴とする。【００１０】
これにより、同じインスタンスを処理対象とするために競合する複数の連携オーダが同時期に実行されないように排他制御されることで、複数の卸サービスを連携させる連携サービスのオーダを、適切に管理することができる。【００１１】
本発明は、前記オーダ実行部が、前記オーダ管理ＤＢから読み出して実行した連携オーダを実行状態とし、
前記排他制御部が、前記オーダ受付部が新たな連携オーダを受け付けたときに、競合する他の実行状態である連携オーダが存在するときは、前記新たな連携オーダを前記オーダ管理ＤＢに登録しないようにすることを特徴とする。【００１２】
これにより、新たな連携オーダを受け付ける時点で、適切に連携オーダ間の排他制御が実施される。【００１３】
本発明は、前記オーダ実行部が、前記オーダ管理ＤＢから読み出して実行した連携オーダを実行状態とし、
前記排他制御部が、前記オーダ管理ＤＢから所定の連携オーダを読み出して実行するときに、競合する他の実行状態である連携オーダが存在するときは、前記所定の連携オーダを実行しないようにすることを特徴とする。【００１４】
これにより、新たな連携オーダを受け付ける時点では問題が無かった連携オーダでも、その後の実行時点において適切に連携オーダ間の排他制御が実施される。【００１５】
本発明は、前記オーダ受付部が、オーダ実行日時が指定された予約オーダと、オーダ実行日時の指定が無い即時オーダとをそれぞれ前記オーダ管理ＤＢに受付状態として登録し、
前記排他制御部が、前記オーダ受付部が新たな即時オーダを受け付けたときに、競合する他の受付状態である即時オーダが存在するときは、前記新たな即時オーダを前記オーダ管理ＤＢに登録しないようにすることを特徴とする。【００１６】
これにより、オーダ管理ＤＢに登録される即時オーダをインスタンスごとに１つに絞り込むことで、すぐに実行される即時オーダ間での排他制御が実施される。【００１７】
本発明は、前記オーダ管理部が、
前記オーダ管理ＤＢに登録されている予約オーダに対して、そのオーダ実行日時またはインスタンスへの処理内容を変更する旨のオーダ変更要求を受け付けると、前記オーダ管理ＤＢから該当する予約オーダを検索し、
該当する予約オーダが前記オーダ管理ＤＢに登録されていないとき、または、該当する予約オーダが受付状態ではないときには、受け付けたオーダ変更要求を前記オーダ管理ＤＢに反映させないようにすることを特徴とする。【００１８】
これにより、オーダ実行日時を指定した予約オーダが登録された後でも、予約オーダの内容を変更するような柔軟性の高い予約管理を提供できる。
【発明の効果】
【００１９】
本発明によれば、複数の卸サービスを連携させる連携サービスのオーダを、適切に管理することができる。
【図面の簡単な説明】
【００２０】
【図１】本実施形態に係わる予約管理システムの構成図である。
【図２】本実施形態に係わる連携オーダ間の競合状態を示す説明図である。
【図３】本実施形態に係わるオーダ管理ＤＢの構成図である。
【図４】本実施形態に係わるオーダ実行部が、卸オーダのオーダ状態から連携オーダのオーダ状態を特定するためのテーブルである。
【図５】本実施形態に係わる予約オーダの受付状態から実行完了状態までの遷移を示す時系列のテーブルである。
【図６】本実施形態に係わる受付状態の予約オーダが存在する状態から、新たな即時オーダの受付状態から実行完了状態までの遷移を示す時系列のテーブルである。
【図７】本実施形態に係わる実行状態の予約オーダが存在する状態から、新たな即時オーダを中断状態にするときの時系列のテーブルである。
【図８】本実施形態に係わる新たな即時オーダを実行する前に、別の予約オーダが実行状態に遷移したときの時系列のテーブルである。
【図９】本実施形態に係わる新たな追加種別オーダがオーダ登録要求として発行されたときのフローチャートである。
【図１０】本実施形態に係わる登録済みの連携オーダに対するオーダ変更要求を受け付けたときのフローチャートである。
【図１１】本実施形態に係わるオーダ実行日時になった予約オーダをオーダ管理ＤＢから読み出す処理を示すフローチャートである。
【図１２】本実施形態に係わる予約オーダを実行する処理の詳細を示すフローチャートである。
【図１３】本実施形態に係わる新たな更新種別オーダまたは削除種別オーダがオーダ登録要求として発行されたときのフローチャートである。
【図１４】本実施形態に係わる受付時の排他チェック処理の詳細を示すフローチャートである。
【図１５】本実施形態に係わる実行時の排他チェック処理の詳細を示すフローチャートである。
【発明を実施するための形態】
【００２１】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００２２】
図１は、予約管理システムの構成図である。まず、基本的な用語を定義する。
「使用リソース」とは、サービスを提供するために使用するリソースであり、例えば、ＳＩＭ（Subscriber Identity Module）などの通信資源や、仮想サーバとしてクラウドを介して提供される計算機資源などである。使用リソースは、ネットワーク（NW）、クラウド（Cloud）、アプリ（APL）などの個別の「卸サービス」として提供される。
そして、「連携サービス」とは、複数の卸サービスを連携させることにより、１つに束ねてサービス事業者に提供されるサービスである。なお、１つの連携サービスが複数の卸サービスを従属させる関係にあるので、連携サービスを親サービスと呼び、卸サービスを子サービスと呼ぶこともある。
【００２３】
「サービスオーダ」とは、使用リソース上で各種の処理を実行させるためのサービス事業者からのオーダ（申込み）である。サービスオーダは、例えば、アカウント情報（Billing Acount）と、カタログ（Product Offering）と、ユーザが設定可能なパラメータ（characteristic）とを含めた構造化ファイルとして構成される。
「連携オーダ」は使用リソース上で連携サービスを実現するためのサービスオーダであり、「卸オーダ」は連携オーダによって連携される個々の卸サービスを実現するためのサービスオーダである。例えば、クラウドサービスを用いて仮想計算機の環境を構築する第１卸オーダと、モバイル通信サービスを用いてＳＩＭを活性化させる第２卸オーダと、アプリケーションサービスを用いてユーザ登録を受け付ける第３卸オーダとが、１つの連携オーダにより連携される。
【００２４】
なお、個々の連携オーダを区別して説明するために、連携オーダの識別子である「連携オーダＩＤ」を用いる。また、サービスオーダの実行時刻に着目すると、オーダ実行日時が未来の時刻に指定された「予約オーダ」か、オーダ実行日時の指定が無いため今すぐ実行する「即時オーダ」かのいずれかに分類される。
【００２５】
予約管理システムは、サービス連携装置１がサービス事業者から連携オーダ（予約オーダ、即時オーダ）を受け付けて、その連携オーダを構成する各卸サービスの使用リソース上に、連携オーダを具現化（インスタンス化）する。
サービス連携装置１は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。
【００２６】
サービス連携装置１は、オーダ受付部１１と、オーダ管理部１２と、オーダ実行部１３と、排他制御部１４と、オーダ管理ＤＢ１５とを有する。
オーダ受付部１１は、サービス事業者からの連携オーダを受け付ける。なお、連携オーダのやりとりには、例えば、標準化団体ＴＭＦ（TeleManagement Forum）が発行する技術仕様「TMF622」に規定されているＡＰＩ（Application Programming Interface）が用いられる。
オーダ管理部１２は、図３で後記する各種のオーダ管理用の情報を用いて、オーダ受付部１１が受け付けた連携オーダをオーダ管理ＤＢ１５に反映させる。つまり、オーダ管理部１２は、オーダ受付部１１が受け付けたオーダ登録要求に従って、新規の連携オーダを図３のオーダ管理ＤＢ１５に登録する。そして、オーダ管理部１２は、オーダ受付部１１が受け付けたオーダ変更要求に従って、オーダ管理ＤＢ１５に登録済の連携オーダを変更する。また、オーダ管理ＤＢ１５のレコードを削除するときも、オーダ変更要求を用いてサービス事業者に指定させる。
【００２７】
オーダ実行部１３は、現在時刻がオーダ実行日時になると、登録済みの予約オーダをオーダ管理ＤＢ１５から読み出して実行する。即時オーダについてはオーダ実行日時が指定されていないので、ただちにオーダ管理ＤＢ１５から読み出して実行する。なお、オーダの実行処理には、技術文書「TMF622」に規定されている「カタログ」の解釈処理も含まれている。このカタログもオーダ管理ＤＢ１５に管理されており、オーダ実行時に読み出されるデータである。
排他制御部１４は、オーダ実行部１３のオーダの実行処理によって同一の使用リソースが複数の連携オーダによって同時期に使用されてしまう競合状態をその発生前に検知する。そして、排他制御部１４は、各時点での１つの使用リソースを１つの連携オーダだけが使用するように排他制御することで、競合状態を事前に回避する。
【００２８】
図２は、連携オーダ間の競合状態を示す説明図である。以下で説明する３つの連携オーダ（Ｌ０１，Ｌ０２，Ｌ０３）は、それぞれ同じリソースを使用する。
１日目にオーダ受付部１１が受け付けた予約オーダＬ０１は、オーダ実行日時が３日目に指定されている。２日目にオーダ受付部１１が受け付けた即時オーダＬ０２と、３日目にオーダ受付部１１が受け付けた即時オーダＬ０３とは、オーダ実行日時が指定されていない。
２日目の即時オーダＬ０２は、同時期に実行する他のオーダが存在しないので、競合が発生せずにそのまま実行できる。
一方、３日目は、即時オーダＬ０３を受け付けて実行する時期と、予約オーダＬ０１のオーダ実行日時に従って実行する時期とが重複するため、使用リソース上での競合が発生する。
【００２９】
なお、図２では、同じリソースを使用することを示すために「プロダクトＩＤ＝Ｐ０１」と表現した。以下では、プロダクトと、そのプロダクトＩＤとを説明する。
「プロダクト」は、連携オーダが使用リソース上にインスタンス化された状態、つまり、連携オーダが実行可能な状態に構築された状態のものである。そして、「プロダクトＩＤ」は、プロダクトを個別に区別するための識別子である。なお、技術仕様「TMF622  Product Order resource」には、連携オーダ（＝Product Order）により作成されたインスタンス（Product）の記載がある。
【００３０】
ここで、２つの使用リソースが同じリソースか、異なるリソースかの判定について説明する。例えば、連携オーダの手順をプログラムコードで表現した実行ファイルＡを物理計算機Ｘ上で実行する場合を考える。
まず、１つの物理計算機Ｘ上で、２つの実行ファイルＡが別々の時刻に起動されることもある。そのときには、実行ファイルＡを先にインスタンス化したプロセスＡ１と、後にインスタンス化したプロセスＡ２とが同じ物理計算機Ｘ内の同じメモリチップ上の異なるメモリ空間を使用する。このときには、互いに異なるメモリ空間を使用しているので、プロセスＡ１の使用リソースと、プロセスＡ２の使用リソースとは、異なる使用リソースで実行されている。
【００３１】
そして、プロセスＡ１の連携オーダと、プロセスＡ２の連携オーダとは、同じ物理計算機Ｘを同時に使用していたとしても、異なる使用リソースなので、競合が発生しない。
一方、インスタンス化した１つのプロセスが１つのプロダクトに該当するので、プロセスＡ１用のプロダクトＩＤと、プロセスＡ２用のプロダクトＩＤとは、別々のＩＤが割り当てられる。ここで、プロセスＡ１用のプロダクトＩＤを指定し、同時刻のオーダ実行日時が指定された予約オーダが２つ存在したときには、２つの予約オーダは同じ使用リソースを扱うので、競合が発生する。
【００３２】
図３は、オーダ管理ＤＢ１５の構成図である。オーダ管理ＤＢ１５は、連携オーダＩＤと、オーダ実行日時と、オーダ種別と、オーダ状態と、プロダクトＩＤとを対応付けて管理する。
連携オーダＩＤ（ProductOrder Id）は、連携オーダの識別子である。
オーダ実行日時（requested Start Date）は、予約オーダである連携オーダの実行日時か、即時オーダであることを示す「なし」のいずれかを示す。オーダ実行日時の形式は、例えばDateTime型（YYYY-MM-DDThh:mm:ss）とする。
【００３３】
オーダ種別（ProductOrder Action）は、連携オーダが使用リソース上に行う操作の種別を示す。以下に、３種類のオーダ種別を列挙する。
・追加種別オーダ（add）は、連携オーダをインスタンス化したプロダクトを、使用リソースに対して追加する旨のオーダである。
・更新種別オーダ（modify）は、既に使用リソース上に構築されているプロダクトに対して、その内容を更新する旨のオーダである。更新内容の一例として、クラウドの構築済み仮想サーバが動作するＣＰＵ種別やＣＰＵ数を変更する旨のオーダが挙げられる。
・削除種別オーダ（delete）は、既に使用リソース上に構築されているプロダクトに対して、プロダクトを使用リソース上から削除する旨のオーダである。
なお、「オーダ実行日時」と「オーダ種別」とについては、サービス事業者がオーダ登録要求で初期値を指定するだけでなく、オーダ変更要求で登録後に変更することができる。
【００３４】
オーダ状態（ProductOrder State）は、技術仕様「TMF622  Product Ordering_Management_API」に規定され、連携オーダのライフサイクルを示す。連携オーダは、以下のオーダ状態を遷移する。
・受付状態（Acknowledged）は、連携オーダの発行を受け付けた状態である。
・実行状態（InProgress）は、受付状態の連携オーダの実行を開始した状態である。受付状態の予約オーダの場合はオーダ実行日時まで待ってから実行状態に遷移し、受付状態の即時オーダの場合は受付状態からただちに実行状態に遷移する。
・中断状態（Held）は、実行状態の連携オーダに対して使用リソースの競合などの問題が発生することにより、処理が中断されてしまった状態である。そして、問題が解決したら、中断状態から実行状態に復帰する。
・実行完了状態（Completed）は、実行状態の連携オーダについて、その連携オーダの処理内容が完了した状態（正常終了の状態）である。
【００３５】
プロダクトＩＤ（ProductRef ID）は、図２で説明したように、連携サービスが使用リソース上にインスタンス化されたプロダクトごとのＩＤである。追加種別オーダにより使用リソース上に追加（インスタンス化）されたときにプロダクトＩＤが発行される。その後の更新種別オーダや削除種別オーダでの既存のインスタンスへの修正に対しては、プロダクトＩＤは値を変更せずに用いられる。
【００３６】
図４は、オーダ実行部１３が、卸オーダのオーダ状態から連携オーダのオーダ状態を特定するためのテーブルである。第２列〜第５列の各卸オーダのオーダ状態（卸オーダ状態）の組み合わせを満たすときに、オーダ実行部１３は、それらの卸オーダを束ねる連携オーダのオーダ状態（連携オーダ状態）を、第１列の状態として特定する。
例えば、卸オーダ状態＝「受付状態、実行完了状態、受付状態」という３つの卸オーダは、受付状態が２つ有り、実行状態が無し、実行完了状態が１つあり、中断状態が無しである。よって、オーダ実行部１３が、卸オーダ状態の集合が図４のテーブルの第３行に該当することを参照し、連携オーダ状態＝「実行状態」（第３行第１列）と特定する。
【００３７】
また、図４のテーブルの第１行は、連携オーダの実行によりリソース補完処理（図９のＳ１０４で後記）が行われるまでは連携オーダ状態＝「受付状態」とし、リソース補完処理が行われた後は連携オーダ状態＝「実行状態」とすることを示す。
さらに、図４のテーブルの第８行は、卸オーダ状態の集合に中断状態が１つでも含まれているときには、他の卸オーダ状態にかかわらず、連携オーダ状態＝「中断状態」とすることを示す。
【００３８】
以下、図５〜図８を参照して、オーダ管理ＤＢ１５に登録される連携オーダ間の競合状態の各事例を説明する。
排他制御部１４は、以下の制御ポリシをもとに、競合状態を解消する。
（ポリシ１）プロダクトＩＤが異なる連携オーダ間には、使用リソースが異なるので競合状態は発生しない。
（ポリシ２）連携オーダ間に競合状態が発生した場合、オーダ状態のライフサイクルが後段階のオーダ状態（実行状態）を優先し、前段階のオーダ状態を待たせる（中断状態）。
（ポリシ３）オーダ登録要求で所定の即時オーダを受け付けた時（リクエスト受付時）の排他チェックでは、プロダクトＩＤが同一の他連携オーダが実行状態として先行していたときには、所定の即時オーダを受け付けない。
（ポリシ４）登録済みの所定の連携オーダを実行する時（リクエスト実行時）の排他チェックでは、プロダクトＩＤが同一の他連携オーダが実行状態として先行していたときには、所定の連携オーダを実行させない。
（ポリシ５）リクエスト受付時の排他チェックでは、所定の即時オーダを受け付けたとき、プロダクトＩＤが同一の他即時オーダが受付状態で登録済みであるときには、所定の連携オーダを受け付けない。
【００３９】
図５は、予約オーダの受付状態から実行完了状態までの遷移を示す時系列のテーブルである。なお、図５〜図８の時系列のテーブルでは、第１列を現時刻とし、第２列〜第６列を図３のオーダ管理ＤＢ１５の内容（第１列〜第５列）とする。
現時刻Ｔ０１において、オーダ受付部１１は、オーダ実行日時＝Ｔ０２が指定された予約オーダ（追加種別オーダ）のオーダ登録要求を受け付ける。オーダ管理部１２は、受付状態の予約オーダをオーダ管理ＤＢ１５に登録する。
現時刻Ｔ０２においてオーダ実行日時になったことで、オーダ実行部１３は、Ｔ０１で受け付けた予約オーダを実行状態にする。
現時刻Ｔ０３において、オーダ実行部１３は、Ｔ０２で実行を開始した予約オーダの実行を終え、実行完了状態とする。これにより、予約オーダがインスタンス化され、そのインスタンス（プロダクト）にプロダクトＩＤ＝Ｐ０１が割り当てられる。
【００４０】
図６は、受付状態の予約オーダが存在する状態から、新たな即時オーダの受付状態から実行完了状態までの遷移を示す時系列のテーブルである。
現時刻Ｔ１１において、オーダ受付部１１は、オーダ実行日時＝Ｔ１９（Ｔ１１〜Ｔ１４よりも後）が指定された予約オーダ（更新種別オーダ）のオーダ登録要求を受け付ける。オーダ管理部１２は、受付状態の予約オーダをオーダ管理ＤＢ１５に登録する。
現時刻Ｔ１２において、オーダ受付部１１は、オーダ実行日時の指定が無い即時オーダのオーダ登録要求を受け付ける。オーダ管理ＤＢ１５に登録されているプロダクトＩＤが同一の予約オーダはまだ受付状態なので、Ｔ１２の時点では競合は発生しない（ポリシ３）。よって、オーダ管理部１２は、受付状態の即時オーダをオーダ管理ＤＢ１５に登録する。
現時刻Ｔ１３において、オーダ実行部１３は、Ｔ１２で受け付けた即時オーダを実行状態にする。Ｔ１３の時点でも、プロダクトＩＤが同一の予約オーダはまだ受付状態なので、競合は発生しない（ポリシ４）。
現時刻Ｔ１４において、オーダ実行部１３は、Ｔ１３で実行を開始した即時オーダの実行を終え、実行完了状態とする。
【００４１】
図７は、実行状態の予約オーダが存在する状態から、新たな即時オーダを中断状態にするときの時系列のテーブルである。
現時刻Ｔ２１において、オーダ受付部１１は、オーダ実行日時＝Ｔ２２が指定された予約オーダを受け付け、その予約オーダをオーダ管理ＤＢ１５に登録する。
現時刻Ｔ２２においてオーダ実行日時になったことで、オーダ実行部１３は、Ｔ２１で受け付けた予約オーダを刈り取って実行状態にする。
現時刻Ｔ２３において、オーダ受付部１１は、新たな即時オーダを受け付ける。ここで、オーダ管理ＤＢ１５に登録されているプロダクトＩＤが同一の予約オーダがすでに実行状態なので、新たな即時オーダとの間で競合が発生する（ポリシ３）。排他制御部１４は、中断状態とした即時オーダを、サービス事業者にエラー通知する。
【００４２】
図８は、新たな即時オーダを実行する前に、別の予約オーダが実行状態に遷移したときの時系列のテーブルである。
現時刻Ｔ３１において、オーダ受付部１１は、オーダ実行日時＝Ｔ３３が指定された予約オーダを受け付け、その予約オーダをオーダ管理ＤＢ１５に登録する。
現時刻Ｔ３２において、オーダ受付部１１は、即時オーダを受け付ける。プロダクトＩＤが同一の予約オーダはまだ受付状態なので、Ｔ３２の時点では競合は発生しない（ポリシ３）。よって、オーダ管理部１２は、受付状態の即時オーダをオーダ管理ＤＢ１５に登録する。
現時刻Ｔ３３においてオーダ実行日時になったことで、オーダ実行部１３は、Ｔ３１で受け付けた予約オーダを刈り取って実行状態にする。
現時刻Ｔ３４において、オーダ実行部１３は、Ｔ３２で受け付けた即時オーダを実行しようとする。しかし、オーダ管理ＤＢ１５に登録されているプロダクトＩＤが同一の予約オーダがすでに実行状態なので、Ｔ３２の即時オーダとの間で競合が発生する（ポリシ４）。排他制御部１４は、中断状態とした即時オーダを、サービス事業者にエラー通知する。
【００４３】
図９は、新たな追加種別オーダがオーダ登録要求として発行されたときのフローチャートである。
Ｓ１０１で、オーダ受付部１１は、サービス事業者から新規に発行された連携オーダのオーダ登録要求を受け付ける。
Ｓ１０２で、オーダ受付部１１は、Ｓ１０１の連携オーダが即時オーダであるか否かを判定する。連携オーダでオーダ実行日時が指定されていないときには新規の即時オーダであるので（Ｓ１０２，Ｙｅｓ）、Ｓ１１１に進む。連携オーダでオーダ実行日時が指定されているときには新規の予約オーダであるので（Ｓ１０２，Ｎｏ）、Ｓ１０３に進む。
Ｓ１０３で、オーダ実行部１３は、新規の予約オーダを受付状態にする。
【００４４】
Ｓ１０４で、オーダ実行部１３は、新規の予約オーダのリソース補完処理を行う。リソース補完処理とは、サービス事業者からの連携オーダの記載内容に対して、他の記載内容を自動的に補完することで、連携オーダの使用リソースを使用可能にするためのコマンドを生成する処理である。以下、保守者が事前に登録しておいた、補完されるデータの一例を、技術仕様「TMF622」の用語で例示する。
・ProductOffering
・ProductSpecification
・ProductSpecCharacteristic
・ProductSpecCharacteristicValue
【００４５】
Ｓ１０５で、オーダ管理部１２は、Ｓ１０４でリソース補完された新規の予約オーダを、オーダ管理ＤＢ１５に登録する。つまりＳ１０５で登録される新規の予約オーダは、（ポリシ３）で示したリクエスト受付時の排他チェックの対象外である。
【００４６】
Ｓ１１１で、オーダ実行部１３は、新規の即時オーダを受付状態にする。
Ｓ１１２で、オーダ実行部１３は、新規の即時オーダについても、Ｓ１０４と同様にリソース補完処理を行う。
Ｓ１１３で、オーダ実行部１３は、新規の即時オーダを実行状態にする。
Ｓ１１４で、オーダ実行部１３は、新規の即時オーダの処理を実行する。
Ｓ１１５で、オーダ実行部１３は、新規の即時オーダを実行完了状態にする。
【００４７】
図１０は、登録済みの連携オーダに対するオーダ変更要求を受け付けたときのフローチャートである。
Ｓ２０１で、オーダ受付部１１は、サービス事業者から発行されたオーダ変更要求で対象となる連携オーダについての各種情報（オーダ実行日時、プロダクトＩＤ、オーダ状態＝受付状態）を、受信したオーダ変更要求から読み込む。
【００４８】
Ｓ２０２で、オーダ受付部１１は、Ｓ２０１で読み込んだオーダ実行日時をもとに、変更対象の連携オーダが即時オーダであるか否かを判定する。Ｓ２０２でＹｅｓならＳ２１１に進んで図１４に示す受付時の排他チェック処理（ポリシ３のチェック処理）を呼び出す。Ｓ２０２でＮｏならＳ２０３に進む。
Ｓ２０３で、オーダ管理部１２は、Ｓ２０１で読み込んだプロダクトＩＤと一致するレコードをオーダ管理ＤＢ１５から取得する。
Ｓ２０４で、オーダ管理部１２は、Ｓ２０３で取得したレコード（つまりプロダクトＩＤが一致するレコード）が存在するか否かを判定する。Ｓ２０４でＹｅｓならＳ２１２に進み、ＮｏならＳ２０５に進む。
Ｓ２０５で、オーダ管理部１２は、「オーダ変更要求で対象となる連携オーダがオーダ管理ＤＢ１５には未登録である」旨のエラーメッセージを、オーダ受付部１１を介してサービス事業者に返却する。
【００４９】
Ｓ２１２で、オーダ管理部１２は、Ｓ２０３で取得したレコードのオーダ状態が受付状態であるか否かを判定する。Ｓ２１２でＹｅｓならＳ２２１に進み、ＮｏならＳ２１３に進む。
Ｓ２１３で、オーダ管理部１２は、「オーダ変更要求で対象となる連携オーダは既に実行が開始された後なので、今からの内容変更はできない」旨のエラーメッセージを、オーダ受付部１１を介してサービス事業者に返却する。
Ｓ２２１で、オーダ管理部１２は、オーダ変更要求で対象となる連携オーダへの変更を許可し、オーダ変更要求に従ってオーダ管理ＤＢ１５の内容を変更する。なお、オーダ管理ＤＢ１５の連携オーダに対応するレコードそのものを削除する操作も、例えばオーダ実行日時を遠い（例えば１００年後の）未来日に指定することで、オーダ変更要求として受け付ける。
Ｓ２２２で、オーダ管理部１２は、「オーダ変更要求で対象となる連携オーダを変更した」旨の正常のメッセージを、オーダ受付部１１を介してサービス事業者に返却する。
【００５０】
図１１は、オーダ実行日時になった予約オーダをオーダ管理ＤＢ１５から読み出す処理を示すフローチャートである。
Ｓ３０１で、オーダ管理部１２は、事前に用意された外部設定ファイルを読み込み、予約オーダの実行確認（Ｓ３０２〜Ｓ３０６）の繰り返し処理の周期を例えば秒単位で決定する。この周期とは、オーダ管理ＤＢ１５に登録された各予約オーダについて、それぞれオーダ実行日時になったかどうかをチェックする間隔を示す。
Ｓ３０３で、オーダ管理部１２は、オーダ管理ＤＢ１５に登録された各予約オーダのオーダ実行日時を取得する。なお、オーダ管理部１２は、オーダ管理ＤＢ１５に直接アクセスする代わりに、各予約オーダのオーダ実行日時をリストアップした外部ファイルにアクセスすることで、Ｓ３０３の処理を行ってもよい。
【００５１】
Ｓ３０４で、オーダ管理部１２は、現時刻がオーダ実行日時を経過した予約オーダが存在するか否かを判定する。Ｓ３０４でＹｅｓならＳ３０５に進み、ＮｏならＳ３０６に進む。
Ｓ３０５で、オーダ管理部１２は、オーダ管理ＤＢ１５から予約オーダを刈り取って実行するために、図１２に示す処理を呼び出す。なお、オーダ実行日時を経過した予約オーダが複数存在するときには、各予約オーダは非同期処理で実行される。つまり、第１の予約オーダの実行終了を待たずに、第２の予約オーダの実行を開始してもよい。
【００５２】
図１２は、Ｓ３０５から呼び出される、予約オーダを実行する処理の詳細を示すフローチャートである。
Ｓ３２１で、オーダ管理部１２は、現時刻がオーダ実行日時を経過した受付状態の予約オーダをオーダ管理ＤＢ１５から取得する。
Ｓ３２２で、オーダ管理部１２は、Ｓ３２１で取得した予約オーダを、オーダ実行日時が古い順にソートする。なお、オーダ実行日時が同時刻の場合、オーダ管理部１２は、オーダ管理ＤＢ１５への登録時刻が古い順に、予約オーダをソートする。
Ｓ３２３〜Ｓ３２６で、オーダ管理部１２は、ソート順に予約オーダを選択するループを実行する。
Ｓ３２４で、オーダ管理部１２は、ループで選択した予約オーダのオーダ種別により処理を分岐させる。オーダ種別＝追加種別オーダならＳ３１１に進み、更新種別オーダまたは削除種別オーダならＳ３３１に進む。
【００５３】
Ｓ３１１で、オーダ実行部１３は、Ｓ１０４と同様に、選択した予約オーダに対するリソース補完処理を非同期に実行する。
Ｓ３１２で、オーダ実行部１３は、選択した予約オーダを実行状態にする。
Ｓ３１３で、オーダ実行部１３は、選択した予約オーダを非同期に実行する。
Ｓ３２５で、オーダ実行部１３は、Ｓ３１２と同様に、選択した予約オーダを実行状態にする。
【００５４】
Ｓ３３１で、オーダ実行部１３は、Ｓ１０４と同様に、選択した予約オーダに対するリソース補完処理を非同期に実行する。
Ｓ３３２で、オーダ実行部１３は、図１５に示す実行時の排他チェック処理（ポリシ４のチェック処理）を呼び出す。
Ｓ３３３で、オーダ実行部１３は、選択した予約オーダを非同期に実行する。
【００５５】
図１３は、新たな更新種別オーダまたは削除種別オーダがオーダ登録要求として発行されたときのフローチャートである。
Ｓ４０１で、オーダ受付部１１は、既存のプロダクトＩＤに対する更新種別オーダまたは削除種別オーダについてのオーダ登録要求を受け付ける。
Ｓ４０２で、オーダ受付部１１は、Ｓ４０１の連携オーダが即時オーダであるか否かを判定する。Ｓ４０２でＹｅｓならＳ４１０に進み、ＮｏならＳ４０３に進む。
Ｓ４０３で、オーダ実行部１３は、Ｓ１０４と同様に、Ｓ４０１の予約オーダに対するリソース補完処理を実行する。
Ｓ４０４で、オーダ管理部１２は、Ｓ４０１の予約オーダをオーダ管理ＤＢ１５に登録する。
【００５６】
Ｓ４１０で、オーダ実行部１３は、Ｓ４０１の即時オーダについて、図１４に示す受付時の排他チェック処理（ポリシ３のチェック処理）を呼び出す。
Ｓ４１７で、オーダ実行部１３は、Ｓ４０１の即時オーダを受付状態にする。
Ｓ４１８で、オーダ実行部１３は、Ｓ１０４と同様に、Ｓ４０１の即時オーダに対するリソース補完処理を実行する。
Ｓ４２０で、オーダ実行部１３は、図１５に示す実行時の排他チェック処理（ポリシ４のチェック処理）を呼び出す。
Ｓ４２６で、オーダ実行部１３は、Ｓ４０１の即時オーダを実行状態にする。
Ｓ４２７で、オーダ実行部１３は、Ｓ４０１の即時オーダの処理を実行する。
【００５７】
図１４は、Ｓ２１１およびＳ４１０からチェック対象の連携オーダが指定されて呼び出される、受付時の排他チェック処理の詳細を示すフローチャートである。
Ｓ４１２で、排他制御部１４は、チェック対象の連携オーダが扱うプロダクトＩＤをオーダ管理ＤＢ１５から取得する。
Ｓ４１３で、排他制御部１４は、Ｓ４１２で取得したプロダクトＩＤが共通となる（つまり、ポリシ１により競合相手となり得る）既存の連携オーダをオーダ管理ＤＢ１５から取得する。Ｓ４１３で既存の連携オーダが存在しないときには、Ｓ４１４に進まずに競合なしである正常のチェック結果を呼出元に返却する（図示省略）。
Ｓ４１４で、排他制御部１４は、Ｓ４１３で取得した既存の連携オーダについて、オーダ状態とオーダ実行日時とをオーダ管理ＤＢ１５から取得する。
【００５８】
Ｓ４１５で、排他制御部１４は、プロダクトＩＤが互いに同一であるチェック対象の連携オーダと、既存の連携オーダとの間で競合が発生しているか否かを判定する。例えば、既存の連携オーダが実行状態であるときには、ポリシ３で示したように競合が発生している。または、既存の連携オーダが受付状態であっても、その既存の連携オーダが即時オーダであるときには、ポリシ５で示したように競合が発生している。Ｓ４１５でＹｅｓならＳ４１６に進み、Ｎｏなら競合なしである正常のチェック結果を呼出元に返却する。
Ｓ４１６で、排他制御部１４は、競合状態である既存の連携オーダを優先させるために、チェック対象の連携オーダを中断状態にして（ポリシ２）、エラーをサービス事業者に返却する。
【００５９】
図１５は、Ｓ３３２およびＳ４２０から呼び出される、実行時の排他チェック処理の詳細を示すフローチャートである。
Ｓ４２２で、排他制御部１４は、チェック対象の連携オーダが扱うプロダクトＩＤをオーダ管理ＤＢ１５から取得する。
Ｓ４２３で、排他制御部１４は、Ｓ４２２で取得したプロダクトＩＤが共通となる（つまり、ポリシ１により競合相手となり得る）既存の連携オーダをオーダ管理ＤＢ１５から取得する。Ｓ４２３で既存の連携オーダが存在しないときには、Ｓ４２４に進まずに競合なしである正常のチェック結果を呼出元に返却する（図示省略）。
【００６０】
Ｓ４２４で、排他制御部１４は、プロダクトＩＤが互いに同一であるチェック対象の連携オーダと、既存の連携オーダとの間で競合が発生しているか否かを判定する。例えば、既存の連携オーダが実行状態であるときには、ポリシ４で示したように競合が発生している。Ｓ４２４でＹｅｓならＳ４２５に進み、Ｎｏなら競合なしである正常のチェック結果を呼出元に返却する。
Ｓ４２５で、排他制御部１４は、競合状態である既存の連携オーダを優先させるために、チェック対象の連携オーダを中断状態にして（ポリシ２）、エラーをサービス事業者に返却する。
【００６１】
以上説明した本実施形態では、オーダ管理ＤＢ１５を管理するオーダ管理部１２は、図９で示したオーダ管理ＤＢ１５へのオーダ登録要求だけでなく、登録済みの連携オーダに対するオーダ変更要求も扱うことができる（図１０）。
さらに、排他制御部１４は、図１４，図１５に示したように、同一の使用リソースを同時期に使用する複数の連携オーダ間の競合を回避するように制御する。ここで、どの連携オーダ間で競合が発生し、競合した連携オーダのうちのどの連携オーダを優先させて処理を継続するかは、（ポリシ１）〜（ポリシ５）に従う。これにより、連携サービスを実行させる連携オーダを、適切に管理することができる。
【００６２】
なお、本実施形態においては、本発明に係る連携サービスの構成として、図１に示す３つの卸サービスで説明したが、これらの個数や構成に限定されない。また、本発明では、一般的なコンピュータのハードウェア資源を、サービス連携装置１の各手段として動作させるプログラムによって実現することができる。そして、このプログラムは、通信回線を介して配布したり、ＣＤ−ＲＯＭ等の記録媒体に記録して配布したりすることも可能である。
【符号の説明】
【００６３】
１      サービス連携装置
１１    オーダ受付部
１２    オーダ管理部
１３    オーダ実行部
１４    排他制御部
１５    オーダ管理ＤＢ
【図１】
2019159939.tif 000003
【図２】
2019159939.tif 000004
【図３】
2019159939.tif 000005
【図４】
2019159939.tif 000006
【図５】
2019159939.tif 000007
【図６】
2019159939.tif 000008
【図７】
2019159939.tif 000009
【図８】
2019159939.tif 000010
【図９】
2019159939.tif 000011
【図１０】
2019159939.tif 000012
【図１１】
2019159939.tif 000013
【図１２】
2019159939.tif 000014
【図１３】
2019159939.tif 000015
【図１４】
2019159939.tif 000016
【図１５】
2019159939.tif 000017
【国際調査報告】
2019159939.tif 000018
2019159939.tif 000019