(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023064102
(43)【公開日】2023-05-10
(54)【発明の名称】サービス提供システムおよびサービス提供方法
(51)【国際特許分類】
G06F 9/46 20060101AFI20230428BHJP
G06F 9/48 20060101ALI20230428BHJP
【FI】
G06F9/46 430
G06F9/48 370
【審査請求】有
【請求項の数】3
【出願形態】OL
(21)【出願番号】P 2022198839
(22)【出願日】2022-12-13
(62)【分割の表示】P 2021173957の分割
【原出願日】2021-10-25
【新規性喪失の例外の表示】特許法第30条第2項適用申請有り https://axis-edge.github.io/qmonus-sdk-programming-guide/transaction/transaction/ https://axis-edge.github.io/qmonus-sdk-programming-guide/scenario/scenario/ https://axis-edge.github.io/qmonus-sdk-programming-guide/overview/ https://axis-edge.github.io/qmonus-docs/tutorial/tutorial4.html https://axis-edge.github.io/qmonus-developer-portal/QmonusIntro.pdf ウェブサイトの掲載日 令和2年10月27日
(71)【出願人】
【識別番号】399035766
【氏名又は名称】エヌ・ティ・ティ・コミュニケーションズ株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】橋本 昭二
(57)【要約】
【課題】複数のマイクロサービスを実行するシステムを容易に開発すること。
【解決手段】サービス提供システム1では、サービスサーバ10は、処理の開始時に処理開始をトランザクションサーバ20に通知し、開始した一連の処理のうち、所定の単位ごとの処理が完了するたびに、トランザクションサーバ20に処理データを通知する。そして、サービスサーバ10が、処理の途中でエラーが発生した場合には、トランザクションサーバ20に対して直前に通知した処理データを要求し、当該処理データをトランザクションサーバ20から取得する。続いて、サービスサーバ10が、取得した処理データを用いて、エラーが発生した際に実行するエラー処理を実行する。
【選択図】
図1
【特許請求の範囲】
【請求項1】
複数のサービスサーバと、各サービスサーバのトランザクションを管理するトランザクションサーバとを有するサービス提供システムであって、
各サービスサーバは、
開始した一連の処理のうち、所定の単位ごとの処理が完了するたびに、前記トランザクションサーバに処理データを通知する通知部と、
前記処理の途中でエラーが発生した場合には、前記トランザクションサーバに対して直前に通知した処理データを要求し、当該処理データを前記トランザクションサーバから取得する取得部と、
前記取得部によって取得された処理データを用いて、エラーが発生した際に実行するエラー処理を実行するエラー処理実行部と
を有し、
前記トランザクションサーバは、
前記サービスサーバから処理データを受信すると、当該処理データを記憶部に格納する格納部と、
前記サービスサーバから処理データの要求を受け付けた場合には、前記記憶部に記憶された処理データを当該サービスサーバに送信する送信部と
を有することを特徴とするサービス提供システム。
【請求項2】
前記通知部は、予め設定された所定の単位ごとの処理が完了するたびに、スナップショットを作成し、前記処理が完了したタイミングをチェックポイントとして、前記スナップショットを前記トランザクションサーバに通知することを特徴とする請求項1に記載のサービス提供システム。
【請求項3】
複数のサービスサーバと、各サービスサーバのトランザクションを管理するトランザクションサーバとを有するサービス提供システムによって実行されるサービス提供方法であって、
各サービスサーバが、開始した一連の処理のうち、所定の単位ごとの処理が完了するたびに、前記トランザクションサーバに処理データを通知する通知工程と、
前記トランザクションサーバが、前記サービスサーバから処理データを受信すると、当該処理データを記憶部に格納する格納工程と、
前記各サービスサーバが、前記処理の途中でエラーが発生した場合には、前記トランザクションサーバに対して直前に通知した処理データを要求し、当該処理データを前記トランザクションサーバから取得する取得工程と、
前記各サービスサーバが、前記取得工程によって取得された処理データを用いて、エラーが発生した際に実行するエラー処理を実行するエラー処理実行工程と、
前記トランザクションサーバが、前記サービスサーバから処理データの要求を受け付けた場合には、前記記憶部に記憶された処理データを当該サービスサーバに送信する送信工程と
を含むことを特徴とするサービス提供方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、サービス提供システムおよびサービス提供方法に関する。
【背景技術】
【0002】
近年、デジタルビジネスのシステムをマイクロサービスと呼ばれる小さな機能の組み合わせで実現するマイクロサービスアーキテクチャが知られている。マイクロサービスアーキテクチャでは、サービス区々に独立したシステム、ライフサイクルで構築、運用され、トランザクションマネジメントもサービスに閉じた一貫性スコープで構築される。また、様々なマイクロサービスを横断して複数のリソースの集約概念となる新たな付加価値サービスを生み出すシーンが増加傾向にある。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、従来の技術では、サービスごとにトランザクションマネジメントを構築しなければならず、複数のマイクロサービスを実行するシステムを容易に構築することができないという課題があった。例えば、様々なマイクロサービスを横断して複数のリソースの集約概念となる新たな付加価値サービスを生み出すシーンが増加傾向にある。このような場合、新たにトランザクションマネジメントを備えた新たなオーケストレーションシステムが必要になる。また複合要件は複雑化しており、サービス毎にステートマシンも異なるため、オーケストレーションシステムの開発コストが高騰する。
【0005】
本発明は、上記に鑑みてなされたものであって、複数のマイクロサービスを実行するシステムを容易に構築することができるサービス提供システムおよびサービス提供方法を提供することを目的とする。
【課題を解決するための手段】
【0006】
上述した課題を解決し、目的を達成するために、本発明のサービス提供システムは、複数のサービスサーバと、各サービスサーバのトランザクションを管理するトランザクションサーバとを有するサービス提供システムであって、各サービスサーバは、開始した一連の処理のうち、所定の単位ごとの処理が完了するたびに、前記トランザクションサーバに処理データを通知する通知部と、前記処理の途中でエラーが発生した場合には、前記トランザクションサーバに対して直前に通知した処理データを要求し、当該処理データを前記トランザクションサーバから取得する取得部と、前記取得部によって取得された処理データを用いて、エラーが発生した際に実行するエラー処理を実行するエラー処理実行部とを有し、前記トランザクションサーバは、前記サービスサーバから処理データを受信すると、当該処理データを記憶部に格納する格納部と、前記サービスサーバから処理データの要求を受け付けた場合には、前記記憶部に記憶された処理データを当該サービスサーバに送信する送信部とを有することを特徴とする。
【発明の効果】
【0007】
本発明によれば、複数のマイクロサービスを実行するシステムを容易に開発することを可能とする。
【図面の簡単な説明】
【0008】
【
図1】
図1は、実施の形態に係るサービス提供システムの構成の一例を示すブロック図である。
【
図2】
図2は、実施の形態に係るサービスサーバの構成の一例を示すブロック図である。
【
図3】
図3は、実施の形態に係るトランザクションサーバの構成の一例を示すブロック図である。
【
図4】
図4は、トランザクションサーバの記憶部に記憶されるデータの一例を示す図である。
【
図5】
図5は、トランザクションサーバによる状態遷移の管理を説明する図である。
【
図6】
図6は、APIゲートウェイからリクエストを受け付けた際のシナリオサーバと、トランザクションサーバによる処理を説明する図である。
【
図7】
図7は、実施の形態に係るシナリオサーバにおける処理を示すフローチャートの一例である。
【
図8】
図8は、実施の形態に係るトランザクションサーバにおける処理を示すフローチャートの一例である。
【
図9】
図9は、プログラムを実行するコンピュータを示す図である。
【発明を実施するための形態】
【0009】
以下に、本願に係るサービス提供システムおよびサービス提供方法の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態により本願に係るサービス提供システムおよびサービス提供方法が限定されるものではない。
【0010】
[実施の形態]
以下の実施形態では、第1の実施形態に係るサービス提供システムの構成、サービスサーバの構成、トランザクションサーバの構成、サービスサーバおよびトランザクションサーバにおける処理の流れを順に説明し、最後に実施形態による効果を説明する。
【0011】
[サービス提供システムの構成]
実施の形態に係るサービス提供システム1の構成を説明する。
図1は、実施の形態に係るサービス提供システムの構成の一例を示すブロック図である。
図1に示すように、サービス提供システム1は、複数のサービスサーバ10A~10C、トランザクションサーバ20、API(Application Programming Interface)ゲートウェイ30およびユーザ端末40を有する。なお、サービスサーバ10A~10Cについて、特に区別なく説明する場合には、サービスサーバ10と記載する。また、
図1に示す構成は一例にすぎず、具体的な構成や各装置の数は特に限定されない。また、
図1に示すネットワークの形態について、各装置は、有線または無線を問わず、インターネット、LANやVPN(Virtual Private Network)などの任意の通信網を介して通信してよい。
【0012】
サービス提供システム1では、複数のサービスサーバ10A~10Cがそれぞれ提供する各マイクロサービスについて、共通のトランザクションサーバ20によってトランザクションマネジメントを行う。このため、サービス提供システム1では、マイクロサービスごとにトランザクションマネジメントを構築することなく、複数のマイクロサービスを実行するシステムを容易に構築することが可能である。
【0013】
複数のサービスサーバ10A~10Cは、マイクロサービスを提供するサーバ装置である。各サービスサーバ10A~10Cは、APIゲートウェイ30を介してユーザ端末40からリクエストを受信すると、マイクロサービスに関する処理を実行し、リクエストに対するレスポンスをユーザ端末40に送信する。
【0014】
トランザクションサーバ20は、複数のサービスサーバ10A~10Cがそれぞれ提供する各マイクロサービスについて、トランザクションマネジメントを行う。例えば、トランザクションサーバ20は、サービスサーバ10がサービスに関する一連の処理を開始する際に、サービスサーバ10からbegin通知を受信すると、当該一連の処理に対してトランザクションIDを付与し、当該処理の状態を管理する。
【0015】
APIゲートウェイ30は、API利用者によるAPI活用のために種々の機能を有する。例えば、APIゲートウェイ30は、ユーザ端末40から受け取ったリクエストを、それぞれのマイクロサービスにルーティングする。
【0016】
ユーザ端末40は、APIの提供及びAPIの利用に用いられる装置である。例えば、ユーザ端末40は、APIゲートウェイ30を介してサービスサーバ10に対してマイクロサービスに関するリクエストを送信し、APIゲートウェイ30を介してサービスサーバ10からレスポンスを受信する。なお、ユーザ端末40は、どのような装置であってもよく、例えば、タブレット型端末や、ノート型PCや、スマートフォン、PDA(Personal Digital Assistant)等の情報処理装置であってもよい。
【0017】
このように、実施の形態に係るサービス提供システム1では、複数のサービスサーバ10A~10Cがそれぞれ提供する各マイクロサービスについて、共通のトランザクションサーバ20によってトランザクションマネジメントを行う。このため、サービス提供システム1では、マイクロサービスごとにトランザクションマネジメントを構築することなく、複数のマイクロサービスを実行するシステムを容易に構築することが可能である。
【0018】
つまり、実施の形態に係るサービス提供システム1では、様々な異なるサービスを横断して全体の一貫性を保証するトランザクションマネジメント機能そのものをメタマイクロサービスとして捉え、フレームワークとして様々なオーケストレーション案件に適用できる。また、これにより、サービス提供システム1では、サービス複合のオーケストレーションワークフローを定義する開発者が、トランザクションマネジメントを意識せず、通常処理とキャンセル処理といった業務処理のみに着目して実装でき、生産性が向上し、複数のサービス複合オーケストレーション型マイクロサービスの増産が可能になる。
【0019】
[サービスサーバ]
次に、サービスサーバ10について説明する。
図2は、実施の形態に係るサービスサーバの構成の一例を示すブロック図である。
図2に示すように、サービスサーバ10は、通信処理部11、制御部12及び記憶部13を有する。
【0020】
通信処理部11は、無線または有線にて他の装置との間で通信を行う。通信処理部11は、ネットワーク等を介して接続された他の装置との間で、各種情報を送受信する通信インタフェースである。通信処理部11は、NIC(Network Interface Card)等で実現され、LAN(Local Area Network)やインターネットなどの電気通信回線を介した他の装置と制御部12(後述)との間の通信を行う。例えば、通信処理部11は、APIゲートウェイ30からリクエストを受信し、APIゲートウェイ30にリクエストに対するレスポンスを送信する。
【0021】
記憶部13は、HDD(Hard Disk Drive)、SSD(Solid State Drive)、光ディスク等の記憶装置である。なお、記憶部13は、RAM(Random Access Memory)、フラッシュメモリ、NVSRAM(Non Volatile Static Random Access Memory)等のデータを書き換え可能な半導体メモリであってもよい。記憶部13は、サービスサーバ10で実行されるOS(Operating System)や各種プログラムを記憶する。さらに、記憶部13は、プログラムの実行で用いられる各種情報を記憶する。
【0022】
制御部12は、サービスサーバ10全体を制御する。制御部12は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)等の電子回路や、ASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)等の集積回路である。また、制御部12は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、内部メモリを用いて各処理を実行する。また、制御部12は、各種のプログラムが動作することにより各種の処理部として機能する。制御部12は、作成部12a、通知部12b、取得部12cおよびエラー処理部12dを有する。
【0023】
作成部12aは、サービスを実行するためのシナリオを作成する。具体的には、作成部12aは、シナリオを作成するためのシナリオエディタ上で開発者の操作を受け付けることで、シナリオエディタ上でエンドポイントが定義され、ワークフローを作成する。ここでワークフローを定義する開発者は、トランザクションマネジメントを意識せず、通常処理とキャンセル処理といった業務処理のみに着目して実装でき、生産性が向上する。また、開発者は、フローエディタで正常な処理とエラー発生時のキャンセル処理等を記述する必要があるが、トランザクションマネジメントを意識せずに、正常処理とエラー処理を分離して記述できるため処理を簡素化することができる。
【0024】
通知部12bは、処理の開始時に処理開始をトランザクションサーバ20に通知し、開始した一連の処理のうち、所定の単位ごとの処理が完了するたびに、トランザクションサーバ20に処理データを通知する。例えば、通知部12bは、マイクロサービスの一連の処理が予め設定されたブロックごとに分けられており、ブロックの処理が完了するたびに、スナップショットを作成し、ブロックの処理が完了したタイミングをチェックポイントとして、スナップショットをトランザクションサーバ20に通知し、トランザクションサーバ20に保存させる。
【0025】
取得部12cは、処理の途中でエラーが発生した場合には、トランザクションサーバ20に対して直前に通知した処理データを要求し、当該処理データをトランザクションサーバ20から取得する。例えば、取得部12cは、処理の途中でエラーが発生した場合には、エラー発生時の処理を実行し、abortをトランザクションサーバ20に通知する。そして、取得部12cは、直前のチェックポイントの処理データのスナップショットをトランザクションサーバ20から取得する。
【0026】
エラー処理部12dは、取得部12cによって取得された処理データを用いて、エラーが発生した際に実行するエラー処理を実行する。例えば、エラー処理部12dは、トランザクションサーバ20から取得したスナップショットを用いて、エラー発生時のキャンセル処理を実行したり、直前のチェックポイントまで処理をロールバックしたりする。
【0027】
[トランザクションサーバ]
次に、トランザクションサーバ20について説明する。
図3は、実施の形態に係るトランザクションサーバの構成の一例を示すブロック図である。
図3に示すように、トランザクションサーバ20は、通信処理部21、制御部22及び記憶部23を有する。
【0028】
通信処理部21は、無線または有線にて他の装置との間で通信を行う。通信処理部21は、ネットワーク等を介して接続された他の装置との間で、各種情報を送受信する通信インタフェースである。通信処理部21は、NIC(Network Interface Card)等で実現され、LAN(Local Area Network)やインターネットなどの電気通信回線を介した他の装置と制御部22(後述)との間の通信を行う。
【0029】
記憶部23は、HDD(Hard Disk Drive)、SSD(Solid State Drive)、光ディスク等の記憶装置である。なお、記憶部23は、RAM(Random Access Memory)、フラッシュメモリ、NVSRAM(Non Volatile Static Random Access Memory)等のデータを書き換え可能な半導体メモリであってもよい。記憶部23は、トランザクションサーバ20で実行されるOS(Operating System)や各種プログラムを記憶する。さらに、記憶部23は、プログラムの実行で用いられる各種情報を記憶する。
【0030】
例えば、記憶部23は、トランザクションを一意に識別するトランザクションIDに対応付けて、チェックポイントにおいて保存されたスナップショット、エンドポイント情報およびインデックスを記憶する。また、記憶部23は、トランザクションの排他制御を行うためのロック情報を記憶する。ロックは、トランザクションがコミットされると自動的に解放される。また、例えば、記憶部23は、
図4に例示するように、トランザクションIDに対応付けて、トランザクションの状態を示すステータスを記憶する。記憶部23は、トランザクションIDに対応するトランザクションの状態が遷移するたびにステータスのデータを更新する。
【0031】
ここで、
図5を用いて、トランザクションサーバ20による状態遷移の管理を説明する。
図5は、トランザクションサーバによる状態遷移の管理を説明する図である。トランザクションサーバ20は、
図5に例示するような状態マシンによってトランザクションを管理する。
図5に例示するように、トランザクションサーバ20は、ステータスとして、「Processing」、「Complete」、「Suspending」、「Aborted」、「Cancelling」、「Cancelled」、「Recovery Processing」、「Recovery Complete」、「Force Recovery Complete」のいずれかに遷移させる。
【0032】
例えば、トランザクションサーバ20は、サービスサーバ10からbeginの通知を受信した場合には、トランザクションIDを払い出し、ステータス「Processing」に遷移させる。そして、トランザクションサーバ20は、サービスサーバ10からトランザクション処理の確定を依頼するcommitの通知を受信した場合には、ステータス「Complete」の状態に遷移させ、その後、当該トランザクションを終了する。
【0033】
また、例えば、トランザクションサーバ20は、サービスサーバ10からabortの通知を受信した場合またはタイムアウトが起きた場合には、ステータス「Aborted」に遷移させる。そして、例えば、トランザクションサーバ20は、キャンセル処理または強制キャンセル処理を行う場合には、ステータス「cancelled」に遷移させる。そして、トランザクションサーバ20は、サービスサーバ10からcommitの通知を受信した場合には、キャンセル処理を確定させる「Cancelled」に遷移させ、その後、当該トランザクションを終了する。
【0034】
制御部22は、トランザクションサーバ20全体を制御する。制御部22は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)等の電子回路や、ASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)等の集積回路である。また、制御部22は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、内部メモリを用いて各処理を実行する。また、制御部22は、各種のプログラムが動作することにより各種の処理部として機能する。制御部22は、管理部22a、格納部22bおよび送信部22cを有する。
【0035】
管理部22aは、サービスサーバ10から処理開始の通知を受信すると、当該処理の状態の遷移を管理する。例えば、管理部22aは、サービスサーバ10からbeginの通知を受信した場合には、新規のトランザクションIDを払い出し、当該トランザクションIDのステータス「Processing」として記憶部23に記憶させる。そして、管理部22aは、サービスサーバ10からトランザクション処理の確定を依頼するcommitの通知を受信した場合には、ステータスを「Complete」の状態に遷移させ、その後、当該トランザクションの管理を終了する。
【0036】
また、例えば、管理部22aは、ステータスが「Processing」であるトランザクションについてサービスサーバ10からabortの通知を受信した場合には、記憶部23に記憶されたステータスについて、当該トランザクションのトランザクションIDに対応するステータスを「Aborted」に更新する。
【0037】
また、管理部22aは、タイムアウトが発生した場合には、記憶部23に記憶された処理データを用いてロールバック処理を行う。例えば、管理部22aは、ステータスが「Processing」であるトランザクションについてタイムアウト(トランザクションタイムアウト)が発生した場合には、記憶部23に記憶されたステータスについて、当該トランザクションのトランザクションIDに対応するステータスを「Aborted」に更新する。そして、管理部22aは、当該トランザクションのトランザクションIDに対応するスナップショットを記憶部23から読み出し、読みだしたスナップショットを用いて、直前のチェックポイントまで処理をロールバックする。
【0038】
格納部22bは、サービスサーバ10から処理データを受信すると、当該処理データを記憶部23に格納する。例えば、格納部22bは、サービスサーバ10からスナップショットを受信した場合には、トランザクションIDに対応付けて、スナップショットとエンドポイント情報とインデックスとを対応付けて記憶部23に格納する。また、例えば、格納部22bは、スナップショットを受信するとともに、任意の残り必要時間をサービスサーバ10から受信してもよい。格納部22bがこの任意の残り必要時間を受信した場合には、前述した管理部22aは、トランザクションタイムアウトまでの時間で残り必要時間を満たせない場合は、満たすようにトランザクションタイムアウトを延長する。つまり、管理部22aは、現在からトランザクションタイムアウトまでの時間が、任意の残り必要時間より短い場合には、任意の残り必要時間を満たすようにトランザクションタイムアウトを延長する。これにより、サービスサーバ10側で処理に応じて、タイムアウト時間を延長することができるので、異常発生の検出精度を向上させることが可能である。
【0039】
送信部22cは、サービスサーバ10から処理データの要求を受け付けた場合には、記憶部23に記憶された処理データを当該サービスサーバ10に送信する。例えば、送信部22cは、サービスサーバ10からabortの通知を受信するとともに、スナップショットの要求を受信した場合には、直前のチェックポイントの処理データのスナップショットをサービスサーバ10に送信する。つまり、サービスサーバ10が、処理の途中でエラーが発生した場合には、エラー発生時の処理を実行するため、直前のチェックポイントの処理データのスナップショットをトランザクションサーバ20に要求する。
【0040】
ここで、
図6を用いて、APIゲートウェイ30からリクエストを受け付けた際のシナリオサーバ10と、トランザクションサーバ20による処理を説明する。
図6は、ユーザ端末からリクエストを受け付けた際のシナリオサーバと、トランザクションサーバによる処理を説明する図である。
図6に例示するように、シナリオサーバ10は、APIゲートウェイ30からのエンドポイントへのアクセスによりリクエストを受信すると、リクエストの検証を行い、サービスに関する一連の処理を開始する。ここで、シナリオサーバ10は、サービスに関する一連の処理を開始する際に、トランザクションサーバ20に対してbeginを通知する。
【0041】
そして、シナリオサーバ10は、ブロック0からブロックnまでの処理を順次実行し、ブロックの処理が完了するたびに、スナップショットを作成し、ブロックの処理が完了したタイミングをチェックポイントとして、スナップショットをトランザクションサーバ20に通知し、トランザクションサーバ20に保存させる。そして、トランザクションサーバ20は、サービスサーバ10からトランザクション処理の確定を依頼するcommitの通知を受信した場合には、ステータス「Complete」の状態に遷移させ、その後、当該トランザクションを終了する。
【0042】
また、シナリオサーバ10は、処理の途中でエラーが発生した場合には、リカバリ処理を行って処理を進めてもよいし、キャンセル処理を行って直前のチェックポイントまで処理をロールバックしてもよい。なお、シナリオサーバ10が、エラー発生時においてリカバリ処理を行うかキャンセル処理を行うかは、予め設定していてもよいし、条件に応じて、どちらを行うかを決定してもよい。
【0043】
例えば、
図6の例では、シナリオサーバ10は、ブロック0の処理において、エラーが発生した場合に、エラー発生時のリカバリ処理を実行し、abortをトランザクションサーバ20に通知する。そして、シナリオサーバ10は、直前のチェックポイントの処理データのスナップショットをトランザクションサーバ20から取得する。そして、シナリオサーバ10は、トランザクションサーバ20から取得したスナップショットを用いて、リカバリ処理を行い、ブロック0の処理を完了させる。
【0044】
また、シナリオサーバ10は、ブロックnの処理において、エラーが発生したため、エラー発生時のキャンセル処理を実行し、abortをトランザクションサーバ20に通知する。そして、シナリオサーバ10は、直前のチェックポイントの処理データのスナップショットをトランザクションサーバ20から取得する。そして、シナリオサーバ10は、トランザクションサーバ20から取得したスナップショットを用いて、キャンセル処理を行い、直前のチェックポイントまで処理をロールバックする。
【0045】
また、トランザクションサーバ20が、シナリオサーバ10のエラー発生を検知して、リカバリ処理やキャンセル処理を行ってもよい。例えば、トランザクションサーバ20が、ステータスが「Processing」であるトランザクションについてタイムアウトが発生した場合には、記憶部23に記憶されたステータスについて、当該トランザクションのトランザクションIDに対応するステータスを「Aborted」に更新する。そして、トランザクションサーバ20は、当該トランザクションのトランザクションIDに対応するスナップショットを記憶部23から読み出し、読み出したスナップショットを用いて、直前のチェックポイントまで処理をロールバックする。
【0046】
[シナリオサーバおよびトランザクションサーバの処理手順]
次に、
図7および
図8を用いて、第1の実施形態に係るシナリオサーバ10およびトランザクションサーバ20による処理手順の例を説明する。
図7は、実施の形態に係るシナリオサーバにおける処理の一例を示すフローチャートである。
図8は、実施の形態に係るトランザクションサーバにおける処理の一例を示すフローチャートである。
【0047】
まず、
図7を用いて、シナリオサーバ10の処理の一例を説明する。
図7に例示するように、シナリオサーバ10の通知部12bは、APIサーバ30からリクエストを受け付けてマイクロサービスに関する処理を開始すると(ステップS101肯定)、トランザクションサーバ20にbegin通知する(ステップS102)。そして、シナリオサーバ10の取得部12cは、処理中のブロックの処理が完了したか判定する(ステップS103)。
【0048】
そして、取得部12cは、処理の途中でエラーが発生し、ブロックの処理が完了していないと判定した場合には(ステップS103否定)、トランザクションサーバ20にabortを通知する(ステップS104)。続いて、取得部12cは、直前のチェックポイントの処理データのスナップショットをトランザクションサーバ20から取得する(ステップS105)。その後、エラー処理部12dは、取得した処理データを用いて、リカバリ処理を行い(ステップS106)、ステップS103に戻る。
【0049】
また、取得部12cが、処理の途中でエラーが発生し、ブロックの処理が完了したと判定した場合には(ステップS103肯定)、通知部12bは、全てのブロックの処理が完了したかを判定する(ステップS107)。この結果、通知部12bは、全てのブロックの処理が完了していないと判定した場合には(ステップS107否定)、トランザクションサーバ20にチェックポイントのスナップショットを指示し(ステップS108)、ステップS103に戻る。
【0050】
また、通知部12bは、全てのブロックの処理が完了したと判定した場合には(ステップS107肯定)、トランザクションサーバ20にトランザクション処理の確定を依頼するcommitを通知し(ステップS109)、処理を終了する。
【0051】
続いて、
図8を用いて、トランザクションサーバ20の処理の一例を説明する。
図8に例示するように、トランザクションサーバ20の管理部22aは、サービスサーバ10からbeginの通知を受信した場合には(ステップS201肯定)、新規のトランザクションIDの払い出しを行う(ステップS202)。
【0052】
そして、管理部22aは、サービスサーバ10からトランザクション処理の確定を依頼するcommitの通知を受信したかを判定する(ステップS203)。この結果、管理部22aは、サービスサーバ10からトランザクション処理の確定を依頼するcommitの通知を受信していないと判定した場合には(ステップS203否定)、サービスサーバ10からスナップショットの指示を受信したか判定する(ステップS204)。この結果、サービスサーバ10からスナップショットの指示を受信した場合には(ステップS204肯定)、格納部22bは、トランザクションIDに対応付けて、スナップショットを記憶部23に格納し(ステップS205)、ステップS203の処理に戻る。
【0053】
また、管理部22aは、サービスサーバ10からスナップショットの指示を受信していない場合には(ステップS204否定)、タイムアウトが発生もしくはサービスサーバ10からabortを受信したかを判定する(ステップS206)。この結果、タイムアウトが発生もしくはサービスサーバ10からabortを受信した場合には(ステップS206肯定)、送信部22cは、リカバリ処理を行う(ステップS207)。例えば、送信部22cは、直前のチェックポイントの処理データのスナップショットをサービスサーバ10に送信することで、リカバリ処理を行う。
【0054】
また、ステップS203の処理において、管理部22aは、サービスサーバ10からトランザクション処理の確定を依頼するcommitの通知を受信したと判定した場合には(ステップS203肯定)、当該トランザクションIDのステータスを「Complete」の状態に更新し(ステップS208)、その後、当該トランザクションの管理を終了する。
【0055】
[実施の形態の効果]
サービス提供システム1では、サービスサーバ10が、処理の開始時に処理開始をトランザクションサーバに通知し、開始した一連の処理のうち、所定の単位ごとの処理が完了するたびに、トランザクションサーバ20に処理データを通知する。そして、トランザクションサーバ20が、サービスサーバ10から処理開始の通知を受信すると、当該処理の状態の遷移を管理する。続いて、トランザクションサーバ20が、サービスサーバ10から処理データを受信すると、当該処理データを記憶部23に格納する。そして、サービスサーバ10が、処理の途中でエラーが発生した場合には、トランザクションサーバ20に対して直前に通知した処理データを要求し、当該処理データをトランザクションサーバ20から取得する。続いて、サービスサーバ10が、取得した処理データを用いて、エラーが発生した際に実行するエラー処理を実行する。その後、トランザクションサーバ20が、サービスサーバ10から処理データの要求を受け付けた場合には、記憶部23に記憶された処理データを当該サービスサーバ10に送信する。
【0056】
このように、実施の形態に係るサービス提供システム1では、複数のサービスサーバ10A~10Cがそれぞれ提供する各マイクロサービスについて、共通のトランザクションサーバ20によってトランザクションマネジメントを行う。このため、サービス提供システム1では、マイクロサービスごとにトランザクションマネジメントを構築することなく、複数のマイクロサービスを実行するシステムを容易に構築することが可能である。
【0057】
つまり、実施の形態に係るサービス提供システム1では、様々な異なるサービスを横断して全体の一貫性を保証するトランザクションマネジメント機能そのものをメタマイクロサービスとして捉え、フレームワークとして様々なオーケストレーション案件に適用できる。これにより、サービス提供システム1では、サービス複合のオーケストレーションワークフローを定義する開発者が、トランザクションマネジメントを意識せず、通常処理とキャンセル処理といった業務処理のみに着目して実装でき、生産性が向上する。また、複数のサービス複合オーケストレーション型マイクロサービスの増産が可能になる。
【0058】
また、サービス提供システム1のトランザクションサーバ20は、タイムアウトが発生した場合には、記憶部23に記憶された処理データを用いてロールバック処理を行うので、サービスサーバ10がワークフローの途中でクラッシュした場合でもロールバックを行うことが可能である。
【0059】
また、サービス提供システム1のサービスサーバ10は、予め設定された所定の単位ごとの処理が完了するたびに、スナップショットを作成し、処理が完了したタイミングをチェックポイントとして、スナップショットをトランザクションサーバ20に通知する。このため、サービスサーバ10は、エラー発生時にトランザクションサーバに記憶されたスナップショットを用いて、ロールバック処理等を行うことが可能である。
【0060】
[システム構成等]
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUやGPU及び当該CPUやGPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【0061】
また、本実施形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【0062】
[プログラム]
また、上記実施形態において説明したサービスサーバ10またはトランザクションサーバ20が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施形態におけるサービスサーバ10またはトランザクションサーバ20が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。
【0063】
図9は、プログラムを実行するコンピュータを示す図である。
図9に例示するように、コンピュータ1000は、例えば、メモリ1010と、CPU1020と、ハードディスクドライブインタフェース1030と、ディスクドライブインタフェース1040と、シリアルポートインタフェース1050と、ビデオアダプタ1060と、ネットワークインタフェース1070とを有し、これらの各部はバス1080によって接続される。
【0064】
メモリ1010は、
図9に例示するように、ROM(Read Only Memory)1011及びRAM1012を含む。ROM1011は、例えば、BIOS(Basic Input Output System)等のブートプログラムを記憶する。ハードディスクドライブインタフェース1030は、
図9に例示するように、ハードディスクドライブ1090に接続される。ディスクドライブインタフェース1040は、ディスクドライブ1100に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ1100に挿入される。シリアルポートインタフェース1050は、例えばマウス1110、キーボード1120に接続される。ビデオアダプタ1060は、例えばディスプレイ1130に接続される。
【0065】
ここで、
図9に例示するように、ハードディスクドライブ1090は、例えば、OS1091、アプリケーションプログラム1092、プログラムモジュール1093、プログラムデータ1094を記憶する。すなわち、上記の、プログラムは、コンピュータ1000によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ1090に記憶される。
【0066】
また、上記実施形態で説明した各種データは、プログラムデータとして、例えばメモリ1010やハードディスクドライブ1090に記憶される。そして、CPU1020が、メモリ1010やハードディスクドライブ1090に記憶されたプログラムモジュール1093やプログラムデータ1094を必要に応じてRAM1012に読み出し、各種処理手順を実行する。
【0067】
なお、プログラムに係るプログラムモジュール1093やプログラムデータ1094は、ハードディスクドライブ1090に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してCPU1020によって読み出されてもよい。あるいは、プログラムに係るプログラムモジュール1093やプログラムデータ1094は、ネットワーク(LAN(Local Area Network)、WAN(Wide Area Network)等)を介して接続された他のコンピュータに記憶され、ネットワークインタフェース1070を介してCPU1020によって読み出されてもよい。
【0068】
上記の実施形態やその変形は、本願が開示する技術に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【0069】
1 サービス提供システム
10、10A~10C サービスサーバ
11、21 通信処理部
12、22 制御部
12a 作成部
12b 通知部
12c 取得部
12d エラー処理部
13、23 記憶部
20 トランザクションサーバ
30 APIゲートウェイ
40 ユーザ端末