JP7296515B2 - サービス提供システムおよびサービス提供方法 - Google Patents

Description

特許法第３０条第２項適用 ｈｔｔｐｓ：／／ａｘｉｓ－ｅｄｇｅ．ｇｉｔｈｕｂ．ｉｏ／ｑｍｏｎｕｓ－ｓｄｋ－ｐｒｏｇｒａｍｍｉｎｇ－ｇｕｉｄｅ／ｔｒａｎｓａｃｔｉｏｎ／ｔｒａｎｓａｃｔｉｏｎ／ ｈｔｔｐｓ：／／ａｘｉｓ－ｅｄｇｅ．ｇｉｔｈｕｂ．ｉｏ／ｑｍｏｎｕｓ－ｓｄｋ－ｐｒｏｇｒａｍｍｉｎｇ－ｇｕｉｄｅ／ｓｃｅｎａｒｉｏ／ｓｃｅｎａｒｉｏ／ ｈｔｔｐｓ：／／ａｘｉｓ－ｅｄｇｅ．ｇｉｔｈｕｂ．ｉｏ／ｑｍｏｎｕｓ－ｓｄｋ－ｐｒｏｇｒａｍｍｉｎｇ－ｇｕｉｄｅ／ｏｖｅｒｖｉｅｗ／ ｈｔｔｐｓ：／／ａｘｉｓ－ｅｄｇｅ．ｇｉｔｈｕｂ．ｉｏ／ｑｍｏｎｕｓ－ｄｏｃｓ／ｔｕｔｏｒｉａｌ／ｔｕｔｏｒｉａｌ４．ｈｔｍｌ ｈｔｔｐｓ：／／ａｘｉｓ－ｅｄｇｅ．ｇｉｔｈｕｂ．ｉｏ／ｑｍｏｎｕｓ－ｄｅｖｅｌｏｐｅｒ－ｐｏｒｔａｌ／ＱｍｏｎｕｓＩｎｔｒｏ．ｐｄｆ ウェブサイトの掲載日 令和２年１０月２７日

本発明は、サービス提供システムおよびサービス提供方法に関する。

近年、デジタルビジネスのシステムをマイクロサービスと呼ばれる小さな機能の組み合わせで実現するマイクロサービスアーキテクチャが知られている。マイクロサービスアーキテクチャでは、サービス区々に独立したシステム、ライフサイクルで構築、運用され、トランザクションマネジメントもサービスに閉じた一貫性スコープで構築される。また、様々なマイクロサービスを横断して複数のリソースの集約概念となる新たな付加価値サービスを生み出すシーンが増加傾向にある。

特開２０２０－６４５８６号公報

しかしながら、従来の技術では、サービスごとにトランザクションマネジメントを構築しなければならず、複数のマイクロサービスを実行するシステムを容易に構築することができないという課題があった。例えば、様々なマイクロサービスを横断して複数のリソースの集約概念となる新たな付加価値サービスを生み出すシーンが増加傾向にある。このような場合、新たにトランザクションマネジメントを備えた新たなオーケストレーションシステムが必要になる。また複合要件は複雑化しており、サービス毎にステートマシンも異なるため、オーケストレーションシステムの開発コストが高騰する。

本発明は、上記に鑑みてなされたものであって、複数のマイクロサービスを実行するシステムを容易に構築することができるサービス提供システムおよびサービス提供方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明のサービス提供システムは、複数のサービスサーバと、各サービスサーバのトランザクションを管理するトランザクションサーバとを有するサービス提供システムであって、各サービスサーバは、開始した一連の処理のうち、所定の単位ごとの処理が完了するたびに、前記トランザクションサーバに処理データを通知する通知部と、前記処理の途中でエラーが発生した場合には、前記トランザクションサーバに対して直前に通知した処理データを要求し、当該処理データを前記トランザクションサーバから取得する取得部と、前記取得部によって取得された処理データを用いて、エラーが発生した際に実行するエラー処理を実行するエラー処理実行部とを有し、前記トランザクションサーバは、前記サービスサーバから処理データを受信すると、当該処理データを記憶部に格納する格納部と、前記サービスサーバから処理データの要求を受け付けた場合には、前記記憶部に記憶された処理データを当該サービスサーバに送信する送信部とを有することを特徴とする。

本発明によれば、複数のマイクロサービスを実行するシステムを容易に開発することを可能とする。

図１は、実施の形態に係るサービス提供システムの構成の一例を示すブロック図である。 図２は、実施の形態に係るサービスサーバの構成の一例を示すブロック図である。 図３は、実施の形態に係るトランザクションサーバの構成の一例を示すブロック図である。 図４は、トランザクションサーバの記憶部に記憶されるデータの一例を示す図である。 図５は、トランザクションサーバによる状態遷移の管理を説明する図である。 図６は、ＡＰＩゲートウェイからリクエストを受け付けた際のシナリオサーバと、トランザクションサーバによる処理を説明する図である。 図７は、実施の形態に係るシナリオサーバにおける処理を示すフローチャートの一例である。 図８は、実施の形態に係るトランザクションサーバにおける処理を示すフローチャートの一例である。 図９は、プログラムを実行するコンピュータを示す図である。

以下に、本願に係るサービス提供システムおよびサービス提供方法の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態により本願に係るサービス提供システムおよびサービス提供方法が限定されるものではない。

［実施の形態］
以下の実施形態では、第１の実施形態に係るサービス提供システムの構成、サービスサーバの構成、トランザクションサーバの構成、サービスサーバおよびトランザクションサーバにおける処理の流れを順に説明し、最後に実施形態による効果を説明する。

［サービス提供システムの構成］
実施の形態に係るサービス提供システム１の構成を説明する。図１は、実施の形態に係るサービス提供システムの構成の一例を示すブロック図である。図１に示すように、サービス提供システム１は、複数のサービスサーバ１０Ａ～１０Ｃ、トランザクションサーバ２０、ＡＰＩ（Application Programming Interface）ゲートウェイ３０およびユーザ端末４０を有する。なお、サービスサーバ１０Ａ～１０Ｃについて、特に区別なく説明する場合には、サービスサーバ１０と記載する。また、図１に示す構成は一例にすぎず、具体的な構成や各装置の数は特に限定されない。また、図１に示すネットワークの形態について、各装置は、有線または無線を問わず、インターネット、ＬＡＮやＶＰＮ（Virtual Private Network）などの任意の通信網を介して通信してよい。

サービス提供システム１では、複数のサービスサーバ１０Ａ～１０Ｃがそれぞれ提供する各マイクロサービスについて、共通のトランザクションサーバ２０によってトランザクションマネジメントを行う。このため、サービス提供システム１では、マイクロサービスごとにトランザクションマネジメントを構築することなく、複数のマイクロサービスを実行するシステムを容易に構築することが可能である。

複数のサービスサーバ１０Ａ～１０Ｃは、マイクロサービスを提供するサーバ装置である。各サービスサーバ１０Ａ～１０Ｃは、ＡＰＩゲートウェイ３０を介してユーザ端末４０からリクエストを受信すると、マイクロサービスに関する処理を実行し、リクエストに対するレスポンスをユーザ端末４０に送信する。

トランザクションサーバ２０は、複数のサービスサーバ１０Ａ～１０Ｃがそれぞれ提供する各マイクロサービスについて、トランザクションマネジメントを行う。例えば、トランザクションサーバ２０は、サービスサーバ１０がサービスに関する一連の処理を開始する際に、サービスサーバ１０からｂｅｇｉｎ通知を受信すると、当該一連の処理に対してトランザクションＩＤを付与し、当該処理の状態を管理する。

ＡＰＩゲートウェイ３０は、ＡＰＩ利用者によるＡＰＩ活用のために種々の機能を有する。例えば、ＡＰＩゲートウェイ３０は、ユーザ端末４０から受け取ったリクエストを、それぞれのマイクロサービスにルーティングする。

ユーザ端末４０は、ＡＰＩの提供及びＡＰＩの利用に用いられる装置である。例えば、ユーザ端末４０は、ＡＰＩゲートウェイ３０を介してサービスサーバ１０に対してマイクロサービスに関するリクエストを送信し、ＡＰＩゲートウェイ３０を介してサービスサーバ１０からレスポンスを受信する。なお、ユーザ端末４０は、どのような装置であってもよく、例えば、タブレット型端末や、ノート型ＰＣや、スマートフォン、ＰＤＡ（Personal Digital Assistant）等の情報処理装置であってもよい。

このように、実施の形態に係るサービス提供システム１では、複数のサービスサーバ１０Ａ～１０Ｃがそれぞれ提供する各マイクロサービスについて、共通のトランザクションサーバ２０によってトランザクションマネジメントを行う。このため、サービス提供システム１では、マイクロサービスごとにトランザクションマネジメントを構築することなく、複数のマイクロサービスを実行するシステムを容易に構築することが可能である。

つまり、実施の形態に係るサービス提供システム１では、様々な異なるサービスを横断して全体の一貫性を保証するトランザクションマネジメント機能そのものをメタマイクロサービスとして捉え、フレームワークとして様々なオーケストレーション案件に適用できる。また、これにより、サービス提供システム１では、サービス複合のオーケストレーションワークフローを定義する開発者が、トランザクションマネジメントを意識せず、通常処理とキャンセル処理といった業務処理のみに着目して実装でき、生産性が向上し、複数のサービス複合オーケストレーション型マイクロサービスの増産が可能になる。

［サービスサーバ］
次に、サービスサーバ１０について説明する。図２は、実施の形態に係るサービスサーバの構成の一例を示すブロック図である。図２に示すように、サービスサーバ１０は、通信処理部１１、制御部１２及び記憶部１３を有する。

通信処理部１１は、無線または有線にて他の装置との間で通信を行う。通信処理部１１は、ネットワーク等を介して接続された他の装置との間で、各種情報を送受信する通信インタフェースである。通信処理部１１は、ＮＩＣ（Network Interface Card）等で実現され、ＬＡＮ（Local Area Network）やインターネットなどの電気通信回線を介した他の装置と制御部１２（後述）との間の通信を行う。例えば、通信処理部１１は、ＡＰＩゲートウェイ３０からリクエストを受信し、ＡＰＩゲートウェイ３０にリクエストに対するレスポンスを送信する。

記憶部１３は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、光ディスク等の記憶装置である。なお、記憶部１３は、ＲＡＭ（Random Access Memory）、フラッシュメモリ、ＮＶＳＲＡＭ（Non Volatile Static Random Access Memory）等のデータを書き換え可能な半導体メモリであってもよい。記憶部１３は、サービスサーバ１０で実行されるＯＳ（Operating System）や各種プログラムを記憶する。さらに、記憶部１３は、プログラムの実行で用いられる各種情報を記憶する。

制御部１２は、サービスサーバ１０全体を制御する。制御部１２は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等の電子回路や、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等の集積回路である。また、制御部１２は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、内部メモリを用いて各処理を実行する。また、制御部１２は、各種のプログラムが動作することにより各種の処理部として機能する。制御部１２は、作成部１２ａ、通知部１２ｂ、取得部１２ｃおよびエラー処理部１２ｄを有する。

作成部１２ａは、サービスを実行するためのシナリオを作成する。具体的には、作成部１２ａは、シナリオを作成するためのシナリオエディタ上で開発者の操作を受け付けることで、シナリオエディタ上でエンドポイントが定義され、ワークフローを作成する。ここでワークフローを定義する開発者は、トランザクションマネジメントを意識せず、通常処理とキャンセル処理といった業務処理のみに着目して実装でき、生産性が向上する。また、開発者は、フローエディタで正常な処理とエラー発生時のキャンセル処理等を記述する必要があるが、トランザクションマネジメントを意識せずに、正常処理とエラー処理を分離して記述できるため処理を簡素化することができる。

通知部１２ｂは、処理の開始時に処理開始をトランザクションサーバ２０に通知し、開始した一連の処理のうち、所定の単位ごとの処理が完了するたびに、トランザクションサーバ２０に処理データを通知する。例えば、通知部１２ｂは、マイクロサービスの一連の処理が予め設定されたブロックごとに分けられており、ブロックの処理が完了するたびに、スナップショットを作成し、ブロックの処理が完了したタイミングをチェックポイントとして、スナップショットをトランザクションサーバ２０に通知し、トランザクションサーバ２０に保存させる。

取得部１２ｃは、処理の途中でエラーが発生した場合には、トランザクションサーバ２０に対して直前に通知した処理データを要求し、当該処理データをトランザクションサーバ２０から取得する。例えば、取得部１２ｃは、処理の途中でエラーが発生した場合には、エラー発生時の処理を実行し、ａｂｏｒｔをトランザクションサーバ２０に通知する。そして、取得部１２ｃは、直前のチェックポイントの処理データのスナップショットをトランザクションサーバ２０から取得する。

エラー処理部１２ｄは、取得部１２ｃによって取得された処理データを用いて、エラーが発生した際に実行するエラー処理を実行する。例えば、エラー処理部１２ｄは、トランザクションサーバ２０から取得したスナップショットを用いて、エラー発生時のキャンセル処理を実行したり、直前のチェックポイントまで処理をロールバックしたりする。

［トランザクションサーバ］
次に、トランザクションサーバ２０について説明する。図３は、実施の形態に係るトランザクションサーバの構成の一例を示すブロック図である。図３に示すように、トランザクションサーバ２０は、通信処理部２１、制御部２２及び記憶部２３を有する。

通信処理部２１は、無線または有線にて他の装置との間で通信を行う。通信処理部２１は、ネットワーク等を介して接続された他の装置との間で、各種情報を送受信する通信インタフェースである。通信処理部２１は、ＮＩＣ（Network Interface Card）等で実現され、ＬＡＮ（Local Area Network）やインターネットなどの電気通信回線を介した他の装置と制御部２２（後述）との間の通信を行う。

記憶部２３は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、光ディスク等の記憶装置である。なお、記憶部２３は、ＲＡＭ（Random Access Memory）、フラッシュメモリ、ＮＶＳＲＡＭ（Non Volatile Static Random Access Memory）等のデータを書き換え可能な半導体メモリであってもよい。記憶部２３は、トランザクションサーバ２０で実行されるＯＳ（Operating System）や各種プログラムを記憶する。さらに、記憶部２３は、プログラムの実行で用いられる各種情報を記憶する。

例えば、記憶部２３は、トランザクションを一意に識別するトランザクションＩＤに対応付けて、チェックポイントにおいて保存されたスナップショット、エンドポイント情報およびインデックスを記憶する。また、記憶部２３は、トランザクションの排他制御を行うためのロック情報を記憶する。ロックは、トランザクションがコミットされると自動的に解放される。また、例えば、記憶部２３は、図４に例示するように、トランザクションＩＤに対応付けて、トランザクションの状態を示すステータスを記憶する。記憶部２３は、トランザクションＩＤに対応するトランザクションの状態が遷移するたびにステータスのデータを更新する。

ここで、図５を用いて、トランザクションサーバ２０による状態遷移の管理を説明する。図５は、トランザクションサーバによる状態遷移の管理を説明する図である。トランザクションサーバ２０は、図５に例示するような状態マシンによってトランザクションを管理する。図５に例示するように、トランザクションサーバ２０は、ステータスとして、「Ｐｒｏｃｅｓｓｉｎｇ」、「Ｃｏｍｐｌｅｔｅ」、「Ｓｕｓｐｅｎｄｉｎｇ」、「Ａｂｏｒｔｅｄ」、「Ｃａｎｃｅｌｌｉｎｇ」、「Ｃａｎｃｅｌｌｅｄ」、「Ｒｅｃｏｖｅｒｙ Ｐｒｏｃｅｓｓｉｎｇ」、「Ｒｅｃｏｖｅｒｙ Ｃｏｍｐｌｅｔｅ」、「Ｆｏｒｃｅ Ｒｅｃｏｖｅｒｙ Ｃｏｍｐｌｅｔｅ」のいずれかに遷移させる。

例えば、トランザクションサーバ２０は、サービスサーバ１０からｂｅｇｉｎの通知を受信した場合には、トランザクションＩＤを払い出し、ステータス「Ｐｒｏｃｅｓｓｉｎｇ」に遷移させる。そして、トランザクションサーバ２０は、サービスサーバ１０からトランザクション処理の確定を依頼するｃｏｍｍｉｔの通知を受信した場合には、ステータス「Ｃｏｍｐｌｅｔｅ」の状態に遷移させ、その後、当該トランザクションを終了する。

また、例えば、トランザクションサーバ２０は、サービスサーバ１０からａｂｏｒｔの通知を受信した場合またはタイムアウトが起きた場合には、ステータス「Ａｂｏｒｔｅｄ」に遷移させる。そして、例えば、トランザクションサーバ２０は、キャンセル処理または強制キャンセル処理を行う場合には、ステータス「ｃａｎｃｅｌｌｅｄ」に遷移させる。そして、トランザクションサーバ２０は、サービスサーバ１０からｃｏｍｍｉｔの通知を受信した場合には、キャンセル処理を確定させる「Ｃａｎｃｅｌｌｅｄ」に遷移させ、その後、当該トランザクションを終了する。

制御部２２は、トランザクションサーバ２０全体を制御する。制御部２２は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等の電子回路や、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等の集積回路である。また、制御部２２は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、内部メモリを用いて各処理を実行する。また、制御部２２は、各種のプログラムが動作することにより各種の処理部として機能する。制御部２２は、管理部２２ａ、格納部２２ｂおよび送信部２２ｃを有する。

管理部２２ａは、サービスサーバ１０から処理開始の通知を受信すると、当該処理の状態の遷移を管理する。例えば、管理部２２ａは、サービスサーバ１０からｂｅｇｉｎの通知を受信した場合には、新規のトランザクションＩＤを払い出し、当該トランザクションＩＤのステータス「Ｐｒｏｃｅｓｓｉｎｇ」として記憶部２３に記憶させる。そして、管理部２２ａは、サービスサーバ１０からトランザクション処理の確定を依頼するｃｏｍｍｉｔの通知を受信した場合には、ステータスを「Ｃｏｍｐｌｅｔｅ」の状態に遷移させ、その後、当該トランザクションの管理を終了する。

また、例えば、管理部２２ａは、ステータスが「Ｐｒｏｃｅｓｓｉｎｇ」であるトランザクションについてサービスサーバ１０からａｂｏｒｔの通知を受信した場合には、記憶部２３に記憶されたステータスについて、当該トランザクションのトランザクションＩＤに対応するステータスを「Ａｂｏｒｔｅｄ」に更新する。

また、管理部２２ａは、タイムアウトが発生した場合には、記憶部２３に記憶された処理データを用いてロールバック処理を行う。例えば、管理部２２ａは、ステータスが「Ｐｒｏｃｅｓｓｉｎｇ」であるトランザクションについてタイムアウト（トランザクションタイムアウト）が発生した場合には、記憶部２３に記憶されたステータスについて、当該トランザクションのトランザクションＩＤに対応するステータスを「Ａｂｏｒｔｅｄ」に更新する。そして、管理部２２ａは、当該トランザクションのトランザクションＩＤに対応するスナップショットを記憶部２３から読み出し、読みだしたスナップショットを用いて、直前のチェックポイントまで処理をロールバックする。

格納部２２ｂは、サービスサーバ１０から処理データを受信すると、当該処理データを記憶部２３に格納する。例えば、格納部２２ｂは、サービスサーバ１０からスナップショットを受信した場合には、トランザクションＩＤに対応付けて、スナップショットとエンドポイント情報とインデックスとを対応付けて記憶部２３に格納する。また、例えば、格納部２２ｂは、スナップショットを受信するとともに、任意の残り必要時間をサービスサーバ１０から受信してもよい。格納部２２ｂがこの任意の残り必要時間を受信した場合には、前述した管理部２２ａは、トランザクションタイムアウトまでの時間で残り必要時間を満たせない場合は、満たすようにトランザクションタイムアウトを延長する。つまり、管理部２２ａは、現在からトランザクションタイムアウトまでの時間が、任意の残り必要時間より短い場合には、任意の残り必要時間を満たすようにトランザクションタイムアウトを延長する。これにより、サービスサーバ１０側で処理に応じて、タイムアウト時間を延長することができるので、異常発生の検出精度を向上させることが可能である。

送信部２２ｃは、サービスサーバ１０から処理データの要求を受け付けた場合には、記憶部２３に記憶された処理データを当該サービスサーバ１０に送信する。例えば、送信部２２ｃは、サービスサーバ１０からａｂｏｒｔの通知を受信するとともに、スナップショットの要求を受信した場合には、直前のチェックポイントの処理データのスナップショットをサービスサーバ１０に送信する。つまり、サービスサーバ１０が、処理の途中でエラーが発生した場合には、エラー発生時の処理を実行するため、直前のチェックポイントの処理データのスナップショットをトランザクションサーバ２０に要求する。

ここで、図６を用いて、ＡＰＩゲートウェイ３０からリクエストを受け付けた際のシナリオサーバ１０と、トランザクションサーバ２０による処理を説明する。図６は、ユーザ端末からリクエストを受け付けた際のシナリオサーバと、トランザクションサーバによる処理を説明する図である。図６に例示するように、シナリオサーバ１０は、ＡＰＩゲートウェイ３０からのエンドポイントへのアクセスによりリクエストを受信すると、リクエストの検証を行い、サービスに関する一連の処理を開始する。ここで、シナリオサーバ１０は、サービスに関する一連の処理を開始する際に、トランザクションサーバ２０に対してｂｅｇｉｎを通知する。

そして、シナリオサーバ１０は、ブロック０からブロックｎまでの処理を順次実行し、ブロックの処理が完了するたびに、スナップショットを作成し、ブロックの処理が完了したタイミングをチェックポイントとして、スナップショットをトランザクションサーバ２０に通知し、トランザクションサーバ２０に保存させる。そして、トランザクションサーバ２０は、サービスサーバ１０からトランザクション処理の確定を依頼するｃｏｍｍｉｔの通知を受信した場合には、ステータス「Ｃｏｍｐｌｅｔｅ」の状態に遷移させ、その後、当該トランザクションを終了する。

また、シナリオサーバ１０は、処理の途中でエラーが発生した場合には、リカバリ処理を行って処理を進めてもよいし、キャンセル処理を行って直前のチェックポイントまで処理をロールバックしてもよい。なお、シナリオサーバ１０が、エラー発生時においてリカバリ処理を行うかキャンセル処理を行うかは、予め設定していてもよいし、条件に応じて、どちらを行うかを決定してもよい。

例えば、図６の例では、シナリオサーバ１０は、ブロック０の処理において、エラーが発生した場合に、エラー発生時のリカバリ処理を実行し、ａｂｏｒｔをトランザクションサーバ２０に通知する。そして、シナリオサーバ１０は、直前のチェックポイントの処理データのスナップショットをトランザクションサーバ２０から取得する。そして、シナリオサーバ１０は、トランザクションサーバ２０から取得したスナップショットを用いて、リカバリ処理を行い、ブロック０の処理を完了させる。

また、シナリオサーバ１０は、ブロックｎの処理において、エラーが発生したため、エラー発生時のキャンセル処理を実行し、ａｂｏｒｔをトランザクションサーバ２０に通知する。そして、シナリオサーバ１０は、直前のチェックポイントの処理データのスナップショットをトランザクションサーバ２０から取得する。そして、シナリオサーバ１０は、トランザクションサーバ２０から取得したスナップショットを用いて、キャンセル処理を行い、直前のチェックポイントまで処理をロールバックする。

また、トランザクションサーバ２０が、シナリオサーバ１０のエラー発生を検知して、リカバリ処理やキャンセル処理を行ってもよい。例えば、トランザクションサーバ２０が、ステータスが「Ｐｒｏｃｅｓｓｉｎｇ」であるトランザクションについてタイムアウトが発生した場合には、記憶部２３に記憶されたステータスについて、当該トランザクションのトランザクションＩＤに対応するステータスを「Ａｂｏｒｔｅｄ」に更新する。そして、トランザクションサーバ２０は、当該トランザクションのトランザクションＩＤに対応するスナップショットを記憶部２３から読み出し、読み出したスナップショットを用いて、直前のチェックポイントまで処理をロールバックする。

［シナリオサーバおよびトランザクションサーバの処理手順］
次に、図７および図８を用いて、第１の実施形態に係るシナリオサーバ１０およびトランザクションサーバ２０による処理手順の例を説明する。図７は、実施の形態に係るシナリオサーバにおける処理の一例を示すフローチャートである。図８は、実施の形態に係るトランザクションサーバにおける処理の一例を示すフローチャートである。

まず、図７を用いて、シナリオサーバ１０の処理の一例を説明する。図７に例示するように、シナリオサーバ１０の通知部１２ｂは、ＡＰＩサーバ３０からリクエストを受け付けてマイクロサービスに関する処理を開始すると（ステップＳ１０１肯定）、トランザクションサーバ２０にｂｅｇｉｎ通知する（ステップＳ１０２）。そして、シナリオサーバ１０の取得部１２ｃは、処理中のブロックの処理が完了したか判定する（ステップＳ１０３）。

そして、取得部１２ｃは、処理の途中でエラーが発生し、ブロックの処理が完了していないと判定した場合には（ステップＳ１０３否定）、トランザクションサーバ２０にａｂｏｒｔを通知する（ステップＳ１０４）。続いて、取得部１２ｃは、直前のチェックポイントの処理データのスナップショットをトランザクションサーバ２０から取得する（ステップＳ１０５）。その後、エラー処理部１２ｄは、取得した処理データを用いて、リカバリ処理を行い（ステップＳ１０６）、ステップＳ１０３に戻る。

また、取得部１２ｃが、処理の途中でエラーが発生し、ブロックの処理が完了したと判定した場合には（ステップＳ１０３肯定）、通知部１２ｂは、全てのブロックの処理が完了したかを判定する（ステップＳ１０７）。この結果、通知部１２ｂは、全てのブロックの処理が完了していないと判定した場合には（ステップＳ１０７否定）、トランザクションサーバ２０にチェックポイントのスナップショットを指示し（ステップＳ１０８）、ステップＳ１０３に戻る。

また、通知部１２ｂは、全てのブロックの処理が完了したと判定した場合には（ステップＳ１０７肯定）、トランザクションサーバ２０にトランザクション処理の確定を依頼するｃｏｍｍｉｔを通知し（ステップＳ１０９）、処理を終了する。

続いて、図８を用いて、トランザクションサーバ２０の処理の一例を説明する。図８に例示するように、トランザクションサーバ２０の管理部２２ａは、サービスサーバ１０からｂｅｇｉｎの通知を受信した場合には（ステップＳ２０１肯定）、新規のトランザクションＩＤの払い出しを行う（ステップＳ２０２）。

そして、管理部２２ａは、サービスサーバ１０からトランザクション処理の確定を依頼するｃｏｍｍｉｔの通知を受信したかを判定する（ステップＳ２０３）。この結果、管理部２２ａは、サービスサーバ１０からトランザクション処理の確定を依頼するｃｏｍｍｉｔの通知を受信していないと判定した場合には（ステップＳ２０３否定）、サービスサーバ１０からスナップショットの指示を受信したか判定する（ステップＳ２０４）。この結果、サービスサーバ１０からスナップショットの指示を受信した場合には（ステップＳ２０４肯定）、格納部２２ｂは、トランザクションＩＤに対応付けて、スナップショットを記憶部２３に格納し（ステップＳ２０５）、ステップＳ２０３の処理に戻る。

また、管理部２２ａは、サービスサーバ１０からスナップショットの指示を受信していない場合には（ステップＳ２０４否定）、タイムアウトが発生もしくはサービスサーバ１０からａｂｏｒｔを受信したかを判定する（ステップＳ２０６）。この結果、タイムアウトが発生もしくはサービスサーバ１０からａｂｏｒｔを受信した場合には（ステップＳ２０６肯定）、送信部２２ｃは、リカバリ処理を行う（ステップＳ２０７）。例えば、送信部２２ｃは、直前のチェックポイントの処理データのスナップショットをサービスサーバ１０に送信することで、リカバリ処理を行う。

また、ステップＳ２０３の処理において、管理部２２ａは、サービスサーバ１０からトランザクション処理の確定を依頼するｃｏｍｍｉｔの通知を受信したと判定した場合には（ステップＳ２０３肯定）、当該トランザクションＩＤのステータスを「Ｃｏｍｐｌｅｔｅ」の状態に更新し（ステップＳ２０８）、その後、当該トランザクションの管理を終了する。

［実施の形態の効果］
サービス提供システム１では、サービスサーバ１０が、処理の開始時に処理開始をトランザクションサーバに通知し、開始した一連の処理のうち、所定の単位ごとの処理が完了するたびに、トランザクションサーバ２０に処理データを通知する。そして、トランザクションサーバ２０が、サービスサーバ１０から処理開始の通知を受信すると、当該処理の状態の遷移を管理する。続いて、トランザクションサーバ２０が、サービスサーバ１０から処理データを受信すると、当該処理データを記憶部２３に格納する。そして、サービスサーバ１０が、処理の途中でエラーが発生した場合には、トランザクションサーバ２０に対して直前に通知した処理データを要求し、当該処理データをトランザクションサーバ２０から取得する。続いて、サービスサーバ１０が、取得した処理データを用いて、エラーが発生した際に実行するエラー処理を実行する。その後、トランザクションサーバ２０が、サービスサーバ１０から処理データの要求を受け付けた場合には、記憶部２３に記憶された処理データを当該サービスサーバ１０に送信する。

このように、実施の形態に係るサービス提供システム１では、複数のサービスサーバ１０Ａ～１０Ｃがそれぞれ提供する各マイクロサービスについて、共通のトランザクションサーバ２０によってトランザクションマネジメントを行う。このため、サービス提供システム１では、マイクロサービスごとにトランザクションマネジメントを構築することなく、複数のマイクロサービスを実行するシステムを容易に構築することが可能である。

つまり、実施の形態に係るサービス提供システム１では、様々な異なるサービスを横断して全体の一貫性を保証するトランザクションマネジメント機能そのものをメタマイクロサービスとして捉え、フレームワークとして様々なオーケストレーション案件に適用できる。これにより、サービス提供システム１では、サービス複合のオーケストレーションワークフローを定義する開発者が、トランザクションマネジメントを意識せず、通常処理とキャンセル処理といった業務処理のみに着目して実装でき、生産性が向上する。また、複数のサービス複合オーケストレーション型マイクロサービスの増産が可能になる。

また、サービス提供システム１のトランザクションサーバ２０は、タイムアウトが発生した場合には、記憶部２３に記憶された処理データを用いてロールバック処理を行うので、サービスサーバ１０がワークフローの途中でクラッシュした場合でもロールバックを行うことが可能である。

また、サービス提供システム１のサービスサーバ１０は、予め設定された所定の単位ごとの処理が完了するたびに、スナップショットを作成し、処理が完了したタイミングをチェックポイントとして、スナップショットをトランザクションサーバ２０に通知する。このため、サービスサーバ１０は、エラー発生時にトランザクションサーバに記憶されたスナップショットを用いて、ロールバック処理等を行うことが可能である。

［システム構成等］
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵやＧＰＵ及び当該ＣＰＵやＧＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

［プログラム］
また、上記実施形態において説明したサービスサーバ１０またはトランザクションサーバ２０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施形態におけるサービスサーバ１０またはトランザクションサーバ２０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。

図９は、プログラムを実行するコンピュータを示す図である。図９に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、図９に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図９に例示するように、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。

ここで、図９に例示するように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の、プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０９０に記憶される。

また、上記実施形態で説明した各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各種処理手順を実行する。

なお、プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

上記の実施形態やその変形は、本願が開示する技術に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１ サービス提供システム
１０、１０Ａ～１０Ｃ サービスサーバ
１１、２１ 通信処理部
１２、２２ 制御部
１２ａ 作成部
１２ｂ 通知部
１２ｃ 取得部
１２ｄ エラー処理部
１３、２３ 記憶部
２０ トランザクションサーバ
３０ ＡＰＩゲートウェイ
４０ ユーザ端末

Claims (3)

1. 複数のサービスサーバと、各サービスサーバのトランザクションを管理するトランザクションサーバとを有するサービス提供システムであって、
   各サービスサーバは、
   開始した一連の処理のうち、所定の単位ごとの処理が完了するたびに、前記トランザクションサーバに処理データを通知する通知部と、
   前記処理の途中でエラーが発生した場合には、前記トランザクションサーバに対して直前に通知した処理データを要求し、当該処理データを前記トランザクションサーバから取得する取得部と、
   前記取得部によって取得された処理データを用いて、エラーが発生した際に実行するエラー処理を実行するエラー処理実行部と
   を有し、
   前記トランザクションサーバは、
   前記サービスサーバから処理データを受信すると、当該処理データを記憶部に格納する格納部と、
   前記サービスサーバから処理データの要求を受け付けた場合には、前記記憶部に記憶された処理データを当該サービスサーバに送信する送信部と
   を有することを特徴とするサービス提供システム。
2. 前記通知部は、予め設定された所定の単位ごとの処理が完了するたびに、スナップショットを作成し、前記処理が完了したタイミングをチェックポイントとして、前記スナップショットを前記トランザクションサーバに通知することを特徴とする請求項１に記載のサービス提供システム。
3. 複数のサービスサーバと、各サービスサーバのトランザクションを管理するトランザクションサーバとを有するサービス提供システムによって実行されるサービス提供方法であって、
   各サービスサーバが、開始した一連の処理のうち、所定の単位ごとの処理が完了するたびに、前記トランザクションサーバに処理データを通知する通知工程と、
   前記トランザクションサーバが、前記サービスサーバから処理データを受信すると、当該処理データを記憶部に格納する格納工程と、
   前記各サービスサーバが、前記処理の途中でエラーが発生した場合には、前記トランザクションサーバに対して直前に通知した処理データを要求し、当該処理データを前記トランザクションサーバから取得する取得工程と、
   前記各サービスサーバが、前記取得工程によって取得された処理データを用いて、エラーが発生した際に実行するエラー処理を実行するエラー処理実行工程と、
   前記トランザクションサーバが、前記サービスサーバから処理データの要求を受け付けた場合には、前記記憶部に記憶された処理データを当該サービスサーバに送信する送信工程と
   を含むことを特徴とするサービス提供方法。

Images