JP7147347B2

JP7147347B2 - 原子性保証装置および原子性保証方法

Info

Publication number: JP7147347B2
Application number: JP2018149980A
Authority: JP
Inventors: 彩鈴木
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2018-08-09
Filing date: 2018-08-09
Publication date: 2022-10-05
Anticipated expiration: 2038-08-09
Also published as: US11995482B2; JP2020027308A; US20210303374A1; WO2020031744A1

Description

本発明は、原子性保証装置および原子性保証方法に関する。

特許文献１には、「ユーザに通信を提供する端末機からの通信サービス利用のためのオーダ要求に応じて、卸サービス事業者毎に通信サービスＡＰＩで公開される各々異なる１つの通信サービスを１又は複数一括して提供する事業者間一括サービス構築装置であって、通信の卸サービスの仕様が記述されたカタログと、各種の通信サービスの連携を定めた連携ルールとを保持し、前記端末機から複数の通信サービス利用のオーダ要求があった場合に、前記保持された前記カタログ及び前記連携ルールに基づき、当該オーダ要求された複数の通信サービスに対応する前記通信サービスＡＰＩを一括に連携させて連携サービスを構築し、この構築された連携サービスを前記端末機へ提供する一括構築機能部を備えることを特徴とする事業者間一括サービス構築装置」について開示されている。

また、非特許文献１には、データベースにおけるトランザクションの原子性（Atomicity）のこと、および、トランザクションの原子性を保証する機能としてのコミットメント制御機能について開示されている。コミットメント制御機能は、すべてのデータ更新を予約し、すべてのデータ更新が可能であることを確認した後、データ更新を実行し（コミット）、更新不可のデータが１つでもある場合予約したデータ更新を取り消す（ロールバック）機能である。

特開２０１８－３２８９７号公報（請求項１）

"ISO/IEC 10026-1:1998(en) Information technology - Open Systems Interconnection - Distributed Transaction Processing - Part1: OSI TP Model"、［online］、［平成30年7月26日検索］、インターネット〈URL：https://www.iso.org/obp/ui/#iso:std:iso-iec:10026:-1:ed-2:v1:en〉

特許文献１の事業者間一括サービス構築装置は、複数種類のサービスが公開するWeb API（Web Application Programming Interface。以下、「ＡＰＩ」と呼ぶ）を組み合わせたサービスを連携サービスとして構築したり運用したりする連携サービス実行装置である。実行される連携サービスには原子性が求められる。つまり、サービス事業者が連携サービスの実行を要求する場合には、一部のＡＰＩで障害が発生しエラー応答があったとき、他の一部のＡＰＩが実行された状態を禁止しなければならない。

連携サービスを構成する複数種類のサービスは、すべてが実行処理済であるか、または、すべてが実行未処理であるか、の２状態しか許容されない。このような考え方は、非特許文献１のトランザクションの原子性に類似する。例えば、口座の預金引き出し処理を例にとると、預金の引き出し処理と、預金残高の更新処理とはどちらも完了していなければならず、片方の処理のみ完了することは許容されない。

従来の連携サービス実行装置は、連携サービスを構成する特定のサービスのＡＰＩが何らかの障害に起因してエラー応答を返した場合、連携サービスの実行を中断する（Held）。しかし、エラー応答を返したサービス以外のサービスについては、ＡＰＩが正常応答し更新処理が完了してしまっている場合がある。この場合、連携サービスの原子性が損なわれる。特許文献１を含め、従来の連携サービス実行装置は、連携サービスの原子性を保証する手段について記載も示唆も無い。

また、連携サービスの場合、連携対象のサービス（ＡＰＩ）が多様であるためコミットメント制御機能の「予約」の考え方を一律に適用することができない。さらに、サービスによって更新処理の取消方法が異なるためロールバックが複雑化する。よって、非特許文献１に記載のコミットメント制御機能は、連携サービスの原子性を保証する手段とはなり得ない。

このような背景に鑑みて、本発明は、連携サービスの原子性を保証することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、連携サービスの原子性を保証する原子性保証装置であって、前記連携サービスを構成する複数種類のサービスの実行要求に対し、前記複数種類のサービスのうち、第１のサービスについてエラー応答があった場合には、前記連携サービスを構成する複数種類のサービスのうち、前記第１のサービス以外となる第２のサービスの更新処理が完了しているか否かを、前記連携サービスを実行する連携サービス実行装置への照会を踏まえて判定する原子性判定部と、前記第２のサービスの更新処理が完了している場合には、完了した、前記第２のサービスの更新処理を取り消すための取消ＡＰＩリクエストを生成する取消ＡＰＩリクエスト生成部と、前記生成された取消ＡＰＩリクエストを、前記第２のサービスを提供するサーバに送信する取消ＡＰＩリクエスト送信部と、を備え、前記取消ＡＰＩリクエストは、取消ＡＰＩメソッドを用いたリクエストであり、前記第２のサービスの更新処理の取消手段を、前記サービスごと、かつ、前記取消ＡＰＩメソッドごとに記憶するサービス取消情報記憶部、をさらに備える、ことを特徴とする。

また、請求項４に記載の発明は、連携サービスの原子性を保証する原子性保証装置における原子性保証方法であって、前記原子性保証装置は、前記連携サービスを構成する複数種類のサービスの実行要求に対し、前記複数種類のサービスのうち、第１のサービスについてエラー応答があった場合には、前記連携サービスを構成する複数種類のサービスのうち、前記第１のサービス以外となる第２のサービスの更新処理が完了しているか否かを、前記連携サービスを実行する連携サービス実行装置への照会を踏まえて判定するステップと、前記第２のサービスの更新処理が完了している場合には、完了した、前記第２のサービスの更新処理を取り消すための取消ＡＰＩリクエストを生成するステップと、前記生成された取消ＡＰＩリクエストを、前記第２のサービスを提供するサーバに送信するステップと、を実行し、前記取消ＡＰＩリクエストは、取消ＡＰＩメソッドを用いたリクエストであり、前記第２のサービスの更新処理の取消手段を、前記サービスごと、かつ、前記取消ＡＰＩメソッドごとに記憶するステップ、をさらに実行する、ことを特徴とする。

請求項１，４に記載の発明によれば、連携サービスを構成する複数種類のサービスの実行要求に対し、複数種類のサービスのうち第１のサービスについてエラー応答があった場合において、連携サービスを構成する複数種類のサービスのうち第１のサービス以外となる第２のサービスの更新処理が完了している場合には、当該更新処理を取り消すことで、連携サービスの状態を実行前の状態に戻すことができる。
したがって、連携サービスの原子性を保証することができる
また、第２のサービスの更新処理の取消手段を、サービスごと、かつ、取消ＡＰＩメソッドごとに記憶するサービス取消情報記憶部を備えることで、更新処理の取消手段が多様となるサービス群から構成される連携サービスの原子性を保証する手段を提供することができる。

また、請求項２に記載の発明は、請求項１に記載の原子性保証装置であって、前記第２のサービスの更新処理の取消完了を示す状態レポートを生成する状態レポート生成部、をさらに備える、ことを特徴とする。

また、請求項５に記載の発明は、請求項４に記載の原子性保証方法であって、前記原子性保証装置は、前記第２のサービスの更新処理の取消完了を示す状態レポートを生成するステップ、をさらに実行する、ことを特徴とする。

請求項２，５に記載の発明によれば、第２のサービスの更新処理の取消完了を示す状態レポートを生成する状態レポート生成部を備えることで、連携サービスの状態が実行前の状態に戻ったことを連携サービス実行装置に通知することができる。その結果、連携サービス実行装置は、連携サービスの実行を要求したサービス事業者に対して、連携サービスの実行取消を通知することができる。

また、請求項３に記載の発明は、請求項１または請求項２に記載の原子性保証装置であって、前記第２のサービスで用いるＡＰＩが、サービスの更新処理が取消不可となる通知系ＡＰＩである場合には、前記第２のサービスの更新処理の取消手段は、先の通知内容が取り消された旨の通知をする手段である、ことを特徴とする。

請求項３に記載の発明によれば、第２のサービスで用いるＡＰＩが、サービスの更新処理が取消不可となる通知系ＡＰＩであったとしても、実質的に、連携サービスの状態を実行前の状態に戻すことができ、連携サービスの原子性を保証することができる。

本発明によれば、連携サービスの原子性を保証することができる。

本実施形態の原子性保証装置の機能構成図である。サービス取消情報記憶部のデータ構造図である。連携サービスの実行を取り消すための一連の処理を示すシーケンス図である。

以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）について説明する。

≪構成≫
図１に示すように、本実施形態のシステムは、原子性保証装置１と、連携サービス実行装置２と、サービス事業者端末３と、サーバ４１～４３とを備える。
原子性保証装置１は、連携サービスの原子性を保証する装置である。原子性保証装置１の詳細は、後記する。

連携サービス実行装置２は、連携サービスを実行する装置である。本実施形態の連携サービス実行装置２は、特許文献１に記載の事業者間一括サービス構築装置であるとするが、これに限定されない。よって、連携サービス実行装置２の詳細な説明は省略する。

サービス事業者端末３は、連携サービスを利用するサービス事業者が用いる端末である。サービス事業者端末３は、連携サービス実行装置２に対し、連携サービスの実行を要求する。

サーバ４１～４３は、連携サービスを構成する各サービスを卸す卸サービス事業者が用いる装置である。
サーバ４１は、サービスＡを提供する装置である。サーバ４１は、サービスＡが公開するＡＰＩであるサービスＡ＿ＡＰＩ４１ａを備える。
サーバ４２は、サービスＢを提供する装置である。サーバ４２は、サービスＢが公開するＡＰＩであるサービスＢ＿ＡＰＩ４２ａを備える。
サーバ４３は、サービスＣを提供する装置である。サーバ４３は、サービスＣが公開するＡＰＩであるサービスＣ＿ＡＰＩ４３ａを備える。

なお、連携サービス実行装置２は、連携サービスを構成する各サービス（卸サービス）の仕様が記述されたカタログと、当該各サービス間の連携を定めた連携ルールとを保持している。サービス事業者端末３から連携サービス実行の要求があった場合、連携サービス実行装置２は、保持されたカタログおよび連携ルールに基づき、要求された連携サービスを構成する各サービスに対応するＡＰＩを一括に連携させて連携サービスを構築することができる。連携サービスを構成する各サービスのカタログと、当該各サービス間の連携を定めた連携ルールとを纏めたものを「連携サービスカタログ」と呼ぶ場合がある。

また、連携サービス実行装置２は、サービスＡ＿ＡＰＩ４１ａ、サービスＢ＿ＡＰＩ４２ａ、サービスＣ＿ＡＰＩ４３ａの各々に対応するアダプタを備えている。サービスＡが連携サービスを構成するサービスである場合、連携サービス実行装置２は、サーバ４１に対してサービスＡの実行を要求し、サーバ４１から応答を受信する。サービスＢが連携サービスを構成するサービスである場合、連携サービス実行装置２は、サーバ４２に対してサービスＢの実行を要求し、サーバ４２から応答を受信する。サービスＣが連携サービスを構成するサービスである場合、連携サービス実行装置２は、サーバ４３に対してサービスＣの実行を要求し、サーバ４３から応答を受信する。サーバ４１～４３の応答は、要求を正常に実行できたことを示す完了応答、および、要求を正常に実行できなかったことを示すエラー応答に分類される。

［原子性保証装置の詳細］
図１に示すように、原子性保証装置１は、連携部１１と、連携サービス解析部１２と、原子性判定部１３と、取消ＡＰＩリクエスト生成部１４と、取消ＡＰＩリクエスト送信部１５と、状態レポート生成部１６と、サービス取消情報記憶部Ｔとを備える。

連携部１１は、連携サービス実行装置２と情報のやり取りをするためのインタフェースである。

連携サービス解析部１２は、連携サービスを解析する機能部である。連携サービス解析部１２は、所定条件下で、連携サービスを構成するサービスから、エラー応答のあったサービス（第１のサービス）以外のサービス（第２のサービス）を抽出する。

原子性判定部１３は、連携サービスの原子性を判定する。具体的には、原子性判定部１３は、連携サービス解析部１２が抽出したサービスのうち、更新処理が完了したサービスが存在するか否かを判定する。存在する場合、原子性判定部１３は、連携サービスの原子性が損なわれたと判定する。原子性判定部１３は、判定結果を踏まえて、更新処理が完了したサービスを抽出する。

更新処理が完了したサービスが存在するか否かの判定は、判定対象のサービスの更新処理が完了したか否かの判定と同義である。判定対象のサービスの更新処理が完了したか否かは、例えば、当該サービスのカタログ、および、当該サービスに対する実行要求やその応答に基づいて判定することができるが、これに限定されない。

取消ＡＰＩリクエスト生成部１４は、完了した更新処理を取り消すための取消ＡＰＩリクエストを生成する。取消ＡＰＩリクエスト生成部１４は、サービス取消情報記憶部Ｔを参照して、原子性判定部１３が抽出したサービスで完了した更新処理に応じた（固有の）取消ＡＰＩリクエストを生成する。

取消ＡＰＩリクエスト送信部１５は、取消要求として、取消ＡＰＩリクエスト生成部１４が生成した取消ＡＰＩリクエストを、取消対象の更新処理が実行されたサービスを提供するサーバに送信する。

状態レポート生成部１６は、連携サービスの状態を示す状態レポートを生成し、連携部１１を経由して、連携サービス実行装置２に送信する。具体的には、取消ＡＰＩリクエスト送信部１５から取消要求によって更新処理が取り消された場合、状態レポート生成部１６は、当該更新処理の取消完了を示す状態レポートを生成し、連携部１１を経由して、連携サービス実行装置２に送信する。連携サービス実行装置２は、状態レポートを利用して、サービス事業者端末３に対し、要求のあった連携サービスの実行取消を通知することができる。なお、例えば、状態レポート生成部１６は、更新処理が完了していないサービスについては、当該更新処理を中断した旨を示す状態レポートを生成し、連携部１１を経由して、連携サービス実行装置２に送信することができる。

サービス取消情報記憶部Ｔは、完了した更新処理の取消手段となるサービス取消情報として記憶する。サービス取消情報は、例えば、取消ＡＰＩ、または、取消ＡＰＩに準ずるＡＰＩを生成可能な情報とすることができるが、これらに限定されない。

図２に示すように、サービス取消情報記憶部Ｔは、複数種類のサービス取消情報をエントリｅ１～ｅ４、・・・として記憶している。サービス取消情報は、「サービス名」、「ＨＴＴＰメソッド」、「ＡＰＩリソース」、「取消ＡＰＩメソッド」、「取消ＡＰＩリソース」、および、「取消ＡＰＩパラメータ情報」（図示の便宜上、図２では、一部内容のみ記載。）といった欄を有している。ＨＴＴＰは、Hypertext Transfer Protocolの略である。

「サービス名」の欄には、卸サービス事業者が提供するサービスの名称が格納される。
「ＨＴＴＰメソッド」は、原子性保証装置１からサーバ４１～４３に対して発行する直接の命令が格納される。
「ＡＰＩリソース」は、原子性保証装置１が発行するＨＴＴＰメソッドによる命令の対象となるリソースが格納される。
「取消ＡＰＩメソッド」は、取消ＡＰＩとして機能するＨＴＴＰメソッドによる命令が格納される。
「取消ＡＰＩリソース」は、取消ＡＰＩメソッドによる命令の対象となるリソースが格納される。
「取消ＡＰＩパラメータ情報」は、取消ＡＰＩメソッドによる命令を実行するために必要となるパラメータが格納される。

図２に示すように、完了した更新処理の取消手段は多様であり、サービスごと、かつ、取消ＡＰＩメソッドごとに異なっており、データベースのコミットメント制御機能（非特許文献１参照）を利用することを妨げる要因となっている。なお、図２中のエントリｅ２，ｅ３については、取消ＡＰＩメソッドを実現するためには、連携サービス実行装置２による連携サービス実行前に、ＧＥＴ（注文照会）リクエストにより更新前の注文状態を取得する必要がある。また、エントリｅ４については、サービスの更新処理が取消不可となる通知系ＡＰＩを用いたサービスの場合にあっては、通知内容の取消状態を再度通知することとするとよい。つまり、（サービス事業者向けの）先の通知内容が取り消された旨の通知をする。

≪処理≫
本実施形態の原子性保証装置１の処理について、図３を参照して説明する。図３は、連携サービスの実行を取り消すための一連の処理を示すシーケンス図である。図３の処理の対象となる連携サービスは、サービスＡ～Ｃを組み合わせたものとして説明する。サービスＡを提供するサーバ４１、および、サービスＣを提供するサーバ４３（図示の便宜上、図３では図示略）には障害はなく、連携サービス実行装置２からの要求に正常に応答することができる。一方、サービスＢを提供するサーバ４２には障害が発生しているため、連携サービス実行装置２からの要求にエラー応答を返すとする。

サービス事業者端末３は、サービス事業者が所望する連携サービスを実行するための連携サービス実行要求を連携サービス実行装置２に送信する（ステップＳ１）。連携サービス実行装置２は、連携サービス実行要求のあった連携サービスの連携サービスカタログに従い、連携サービスを構成するサービスＡについて、サービスＡを実行するためのサービスＡ実行要求をサーバ４１に送信する（ステップＳ２）。サーバ４１は、サービスＡ実行要求を受信すると、サービスＡ＿ＡＰＩ４１ａを実行することで、サービスＡの実行が完了したことを示す完了応答（正常応答）を連携サービス実行装置２に送信する（ステップＳ３）。

同様に、連携サービス実行装置２は、連携サービスを構成するサービスＢについて、サービスＢを実行するためのサービスＢ実行要求をサーバ４２に送信する（ステップＳ４）。しかし、サーバ４２は、障害に陥っているため、サービスＢ実行要求を受信しても、サービスＢ＿ＡＰＩ４２ａを実行することができず、サービスＡを実行することができないことを示すエラー応答を連携サービス実行装置２に送信する（ステップＳ５）。

なお、図３には示されていないサービスＣについては、サービスＡと同等に扱うことができるため、詳細な説明は省略する。連携サービス実行装置２は、サービスＣ実行要求をサーバ４３に送信すれば、サーバ４３から完了応答（正常応答）を受信する。

連携サービス実行装置２は、エラー応答があったサービスＢについて、再開処理を試行するが、図３の処理では、失敗し、サーバ４２から完了応答が得られなかったとする（ステップＳ６）。再開処理は、例えば、サービスＢ実行要求をサーバ４２に再度送信することを含むが、これに限定されない。連携サービス実行装置２は、サービスＢの再開失敗を示す再開失敗通知を原子性保証装置１に送信する（ステップＳ７）。

原子性保証装置１は、連携サービス解析部１２によって、再開失敗通知がなされたサービスＢを含む連携サービスの連携サービスカタログを連携サービス実行装置２に照会する（ステップＳ８）。連携サービス実行装置２は、照会のあった連携サービスカタログを原子性保証装置１に送信する（ステップＳ９）。

原子性保証装置１は、連携サービス解析部１２によって、連携サービス実行装置２から受信した連携サービスカタログを解析し、連携サービスを構成するサービスから、連携サービスに含まれるサービスＢ以外のサービスを抽出する（ステップＳ１０）。具体的には、原子性保証装置１は、連携サービスカタログから、サービスＢ以外の、正常応答済のサービスＡ（および説明略のサービスＣ）のＡＰＩを抽出する。

原子性保証装置１は、抽出したサービスＡについて、サービスＡカタログを連携サービス実行装置２に照会するとともに、サービスＡ要求＆応答を連携サービス実行装置２に照会する（ステップＳ１１）。サービスＡカタログとは、サービスＡに関するカタログであり、連携サービス実行装置２が保持する。サービスＡ要求＆応答は、連携サービス実行装置２とサーバ４１との間でなされたやり取りの履歴であり、連携サービス実行装置２が保持する。連携サービス実行装置２は、ステップＳ１１の照会に対し、サービスＡカタログ、および、サービスＡ要求＆応答を原子性保証装置１に送信する（ステップＳ１２）。

原子性保証装置１は、原子性判定部１３によって、サービスＡカタログおよびサービスＡ要求＆応答に基づいて、サービスＡに関する更新処理を示すサービスＡ更新処理が完了しているか否かを判定する（ステップＳ１３）。図３の処理では、サービスＡ更新処理は完了しているとして説明を続ける。

原子性保証装置１は、取消ＡＰＩリクエスト生成部１４によって、完了した、サービスＡ更新処理の取消ＡＰＩリクエストを生成する（ステップＳ１４）。取消ＡＰＩリクエスト生成部１４は、サービス取消情報記憶部Ｔ（図２）を参照して、サービスＡ更新処理の取り消しに必要となる取消ＡＰＩメソッドを選択することで、取消ＡＰＩリクエストを生成することができる。

なお、サービスＣに関して、原子性判定部１３が、サービスＣに関する更新処理を示すサービスＣ更新処理が完了していると判定した場合には、取消ＡＰＩリクエスト生成部１４は、完了したサービスＣ更新処理の取消ＡＰＩリクエストを生成する。

原子性保証装置１は、取消ＡＰＩリクエスト送信部１５によって、取消ＡＰＩリクエスト生成部１４が生成した、サービスＡ更新処理の取消ＡＰＩリクエストを含む取消要求をサーバ４１に送信する（ステップＳ１５）。サーバ４１は、取消要求を受信すると、取消ＡＰＩリクエストに従って、サービスＡ更新処理の取消処理を実行することで、サービスＡの更新処理の取り消しが完了したことを示す完了応答（取消完了）を原子性保証装置１に送信する（ステップＳ１６）。

原子性保証装置１は、状態レポート生成部１６によって、サービスＡ更新処理の取消完了を示す状態レポートを生成する。また、原子性保証装置１は、生成した状態レポートを含む状態通知（例：取消完了）を、連携部１１を経由して、連携サービス実行装置２に送信する（ステップＳ１７）。

連携サービス実行装置２は、原子性保証装置１から受信した状態通知に応じて、サービス事業者端末３から要求のあった連携サービスの実行を取り消したことを示す状態通知（例：連携サービス実行取消）をサービス事業者端末３に送信する（ステップＳ１８）。連携サービス実行装置２は、サービス事業者端末３に対し、サービスＢがエラー状態にあることを通知してもよい。
以上で、図３の処理が終了する。

≪まとめ≫
本実施形態によれば、連携サービスを構成する複数種類のサービスの実行要求に対し、複数種類のサービスのうち第１のサービスについてエラー応答があった場合において、連携サービスを構成する複数種類のサービスのうち第１のサービス以外となる第２のサービスの更新処理が完了している場合には、当該更新処理を取り消すことで、連携サービスの状態を実行前の状態に戻すことができる。
したがって、連携サービスの原子性を保証することができる。

また、第２のサービスの更新処理の取消完了を示す状態レポートを生成する状態レポート生成部１６を備えることで、連携サービスの状態が実行前の状態に戻ったことを連携サービス実行装置に通知することができる。その結果、連携サービス実行装置は、連携サービスの実行を要求したサービス事業者に対して、連携サービスの実行取消を通知することができる。

また、第２のサービスの更新処理の取消手段を、サービスごと、かつ、取消ＡＰＩメソッドごとに記憶するサービス取消情報記憶部Ｔを備えることで、更新処理の取消手段が多様となるサービス群から構成される連携サービスの原子性を保証する手段を提供することができる。

また、第２のサービスで用いるＡＰＩが、サービスの更新処理が取消不可となる通知系ＡＰＩであったとしても、実質的に、連携サービスの状態を実行前の状態に戻すことができ、連携サービスの原子性を保証することができる。

（その他）
（ａ）本実施形態では、原子性保証装置１と連携サービス実行装置２とを別体の装置として説明したが、例えば、連携サービス実行装置２が原子性保証装置１を含む構成をとってもよい。
（ｂ）本実施形態では、原子性保証装置１が連携サービス実行装置２に、サービスカタログやサービス要求＆応答を照会することで、サービスの更新処理が完了しているか否かの判定を行った（図３のステップＳ１１～ステップＳ１３）。しかし、サービスの更新処理が完了しているか否かの判定方法は上記に限らず、例えば、サーバ４１～４３とやり取りした連携サービス実行装置２自身が、各サービスの更新処理が完了しているか否かの判定をし、原子性保証装置１からの照会があれば当該判定結果を原子性保証装置１に通知するようにしてもよい。
（ｃ）各実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。

１原子性保証装置
１１連携部
１２連携サービス解析部
１３原子性判定部
１４取消ＡＰＩリクエスト生成部
１５取消ＡＰＩリクエスト送信部
１６状態レポート生成部
Ｔサービス取消情報記憶部
２連携サービス実行装置
３サービス事業者端末
４１～４３サーバ
４１ａサービスＡ＿ＡＰＩ
４２ａサービスＢ＿ＡＰＩ
４３ａサービスＣ＿ＡＰＩ

Claims

連携サービスの原子性を保証する原子性保証装置であって、
前記連携サービスを構成する複数種類のサービスの実行要求に対し、前記複数種類のサービスのうち、第１のサービスについてエラー応答があった場合には、前記連携サービスを構成する複数種類のサービスのうち、前記第１のサービス以外となる第２のサービスの更新処理が完了しているか否かを、前記連携サービスを実行する連携サービス実行装置への照会を踏まえて判定する原子性判定部と、
前記第２のサービスの更新処理が完了している場合には、完了した、前記第２のサービスの更新処理を取り消すための取消ＡＰＩリクエストを生成する取消ＡＰＩリクエスト生成部と、
前記生成された取消ＡＰＩリクエストを、前記第２のサービスを提供するサーバに送信する取消ＡＰＩリクエスト送信部と、を備え、
前記取消ＡＰＩリクエストは、取消ＡＰＩメソッドを用いたリクエストであり、
前記第２のサービスの更新処理の取消手段を、前記サービスごと、かつ、前記取消ＡＰＩメソッドごとに記憶するサービス取消情報記憶部、をさらに備える、
ことを特徴とする原子性保証装置。
前記第２のサービスの更新処理の取消完了を示す状態レポートを生成する状態レポート生成部、をさらに備える、
ことを特徴とする請求項１に記載の原子性保証装置。
前記第２のサービスで用いるＡＰＩが、サービスの更新処理が取消不可となる通知系ＡＰＩである場合には、前記第２のサービスの更新処理の取消手段は、先の通知内容が取り消された旨の通知をする手段である、
ことを特徴とする請求項１または請求項２に記載の原子性保証装置。
連携サービスの原子性を保証する原子性保証装置における原子性保証方法であって、
前記原子性保証装置は、
前記連携サービスを構成する複数種類のサービスの実行要求に対し、前記複数種類のサービスのうち、第１のサービスについてエラー応答があった場合には、前記連携サービスを構成する複数種類のサービスのうち、前記第１のサービス以外となる第２のサービスの更新処理が完了しているか否かを、前記連携サービスを実行する連携サービス実行装置への照会を踏まえて判定するステップと、
前記第２のサービスの更新処理が完了している場合には、完了した、前記第２のサービスの更新処理を取り消すための取消ＡＰＩリクエストを生成するステップと、
前記生成された取消ＡＰＩリクエストを、前記第２のサービスを提供するサーバに送信するステップと、を実行し、
前記取消ＡＰＩリクエストは、取消ＡＰＩメソッドを用いたリクエストであり、
前記第２のサービスの更新処理の取消手段を、前記サービスごと、かつ、前記取消ＡＰＩメソッドごとに記憶するステップ、をさらに実行する、
ことを特徴とする原子性保証方法。
前記原子性保証装置は、
前記第２のサービスの更新処理の取消完了を示す状態レポートを生成するステップ、をさらに実行する、
ことを特徴とする請求項４に記載の原子性保証方法。