JP2010146103A - 補償処理手順方式選択装置、方法、プログラム及びそれを記録した記録媒体、並びにワークフローシステム - Google Patents

補償処理手順方式選択装置、方法、プログラム及びそれを記録した記録媒体、並びにワークフローシステム Download PDF

Info

Publication number
JP2010146103A
JP2010146103A JP2008320017A JP2008320017A JP2010146103A JP 2010146103 A JP2010146103 A JP 2010146103A JP 2008320017 A JP2008320017 A JP 2008320017A JP 2008320017 A JP2008320017 A JP 2008320017A JP 2010146103 A JP2010146103 A JP 2010146103A
Authority
JP
Japan
Prior art keywords
compensation
processing
service
workflow
update
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2008320017A
Other languages
English (en)
Inventor
Shinji Kikuchi
伸治 菊地
Yoshihiro Jinnan
吉宏 神南
Yosuke Isozaki
洋祐 磯崎
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2008320017A priority Critical patent/JP2010146103A/ja
Publication of JP2010146103A publication Critical patent/JP2010146103A/ja
Withdrawn legal-status Critical Current

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】分散トランザクション処理の整合性維持を行う補償処理において最適な計算資源を用いてこれを行う補償処理手順方式選択装置、方法、プログラム及び記録媒体並びにワークフローシステムを提供する。
【解決手段】分散トランザクション処理を実施するワークフロー処理系２ａ〜２ｎの中に、分散トランザクション処理において異常を検出した場合に、その整合性を維持するための補償処理を部分実施する補償部分実施部２１ａ〜２１ｎを配置する部分補償配置部１１と、実施済みの分散トランザクション処理の実績を基に、少なくとも合意サービス水準をパラメータとして定義された事項を複数の補償処理の手順方式に関して評価して期待値データを算出するコスト期待値計算部１２と、補償部分実施部２１ａ〜２１ｎからの問い合わせに応じて、期待値データに基づいて補償処理の手順方式を指定する補償コスト期待値管理部１３とを含む。
【選択図】図１

Description

本発明は、複数のサーバによって実施されるロングライブトランザクション方式に基づく分散トランザクション処理の整合性を維持管理する技術・方法に関し、特に分散トランザクション処理に関する整合性を維持するための性能、それに基づく分散トランザクション処理全体の性能を改善させる補償処理手順方式選択装置、方法、プログラム及びそれを記録した記録媒体、並びにワークフローシステムに関する。
トランザクション処理に関連する技術として、特許文献１がある。特許文献１に開示される発明は、トランザクション処理方式及びその実施装置、並びにその処理プログラムを記録した媒体であり、トランザクション処理時の障害回復手段であるSagaの補償トランザクションを並列化することで高速化を実現する。
特許文献１に開示される発明では、複数のサーバに対して、複数のアダプタを使ってワークフロー処理に伴う分散トランザクションの処理を実施する際、障害が発生した場合、障害発生時点までに行った一連のトランザクション処理を取り消す回復処理を行う。通常は、Sagaと呼ばれる方法を用いて一連のトランザクション処理とは逆の順序で対応する補償トランザクション群を実行することで取り消しを実施する。
特許第４０９４７５２号公報
特許文献１に開示される発明は、並列化を実施することで一連の補償トランザクション群を高速に処理しようとしている。
しかし、並列化することで処理の高速化を図っても、発生する補償トランザクション群には一定量以上の計算機の資源消費が発生する。さらに、補償トランザクション群で消費する計算機資源が多いほど、トランザクション全体のスループット効率が低下し、ワークフローの処理品質も低下するという問題が生じる。
特に、発生する補償トランザクション群で消費する計算機資源は、ワークフローの持つ複雑さに起因し、計算機資源の消費量も異なる可能性も残る。さらに、補償トランザクションの実施においては、Saga以外の方法も存在しうる。
このため、トランザクション全体のスループット効率が低下することを回避するため、単に一連の補償トランザクション群を並列化して実施するだけではなく、適正な方式を状況に応じて選択することが好ましい。しかし、特許文献１にはそのような仕組みは開示されていない。
本発明は係る問題に鑑みてなされたものであり、複数サーバにより実施されるロングライブトランザクション方式に基づく分散トランザクション処理の整合性を最適な計算資源を用いながら維持管理可能な補償処理手順方式選択装置、方法、プログラム及びそれを記録した記録媒体、並びにワークフローシステムを提供することを目的とする。
上記目的を達成するため、本発明は、第１の態様として、ロングライブトランザクション方式に基づく分散トランザクション処理を実施する複数のワークフロー処理手段の中に、分散トランザクション処理において異常を検出した場合に、その整合性を維持するために実施される補償処理を部分実施する補償部分実施手段を配置する部分補償配置手段と、既に実施した分散トランザクション処理の実績を基に、少なくとも合意サービス水準をパラメータとして定義された事項を複数の補償処理の手順方式の各々に関して評価して期待値データを算出するコスト期待値計算手段と、複数の期待値データを管理し、補償部分実施手段からの問い合わせに応じて、期待値データに基づいて補償処理の手順方式を指定する補償コスト期待値管理手段とを含み、補償処理の手順方式を、当該分散トランザクション処理全体の性能を最適化するよう、合意サービス水準を考慮して選択することを特徴とする補償処理手順方式選択装置を提供するものである。
上記目的を達成するため、本発明は、第２の態様として、ロングライブトランザクション方式に基づく分散トランザクション処理において異常を検出した場合に、当該分散トランザクション処理の整合性を維持するため実施される補償処理を部分実施する補償部分実施手段を複数サーバ内に配置し、既に実施した分散トランザクション処理の実績を基に、少なくとも合意サービス水準をパラメータとして定義された事項を複数の補償処理の手順方式の各々に関して評価して期待値データを算出し、補償部分実施手段からの問い合わせに応じて、期待値データに基づいて補償処理の手順方式を指定し、補償処理の手順方式を、当該分散トランザクション処理全体の性能を最適化するよう、合意サービス水準を考慮して選択することを特徴とする補償処理手順方式選択方法を提供するものである。
上記目的を達成するため、本発明は、第３の態様として、コンピュータに、ロングライブトランザクション方式に基づく分散トランザクション処理において異常を検出した場合に、当該分散トランザクション処理の整合性を維持するため実施される補償処理を部分実施する補償部分実施手段を複数サーバ内に配置する処理と、既に実施した分散トランザクション処理の実績を基に、少なくとも合意サービス水準をパラメータとして定義された事項を複数の補償処理の手順方式の各々に関して評価して期待値データを算出する処理と、補償部分実施手段からの問い合わせに応じて、期待値データに基づいて補償処理の手順方式を指定し、補償処理の手順方式を、当該分散トランザクション処理全体の性能を最適化するように合意サービス水準を考慮して選択する処理とを実行させることを特徴とする補償処理手順方式選択プログラムを提供するものである。
上記目的を達成するため、本発明は、第４の態様として、上記本発明の第３の態様に係る補償処理手順方式選択プログラムが記録されたコンピュータ可読の記録媒体を提供するものである。
上記目的を達成するため、本発明は、第５の態様として、ロングライブトランザクション方式に基づく分散トランザクション処理を実施する複数のワークフロー処理装置と、分散トランザクション処理において異常を検出した場合に、その整合性を維持するために実施される補償処理の手順方式を、当該分散トランザクション処理全体の性能を最適化するよう、合意サービス水準を考慮して選択する補償処理手順方式選択装置とを有するワークフローシステムであって、補償処理手順選択装置は、ワークフロー処理装置のそれぞれの中に、分散トランザクション処理において異常を検出した場合に、その整合性を維持するために実施される補償処理を部分実施する補償部分実施手段を配置する部分補償配置手段と、既に実施した分散トランザクション処理の実績を基に、少なくとも合意サービス水準をパラメータとして定義された事項を複数の補償処理の手順方式の各々に関して評価して期待値データを算出するコスト期待値計算手段と、複数の期待値データを管理し、補償部分実施手段からの問い合わせに応じて、期待値データに基づいて補償処理の手順方式を指定する補償コスト期待値管理手段とを含むことを特徴とするワークフローシステムを提供するものである。
本発明によれば、複数サーバにより実施されるロングライブトランザクション方式に基づく分散トランザクション処理の整合性を最適な計算資源を用いながら維持管理可能な補償処理手順方式選択装置、方法、プログラム及びそれを記録した記録媒体、並びにワークフローシステムを提供できる。
図１に示すように、本発明に係る補償処理手順方式選択装置１は、ロングライブトランザクション方式に基づく分散トランザクション処理を実施する複数のワークフロー処理系２ａ〜２ｎの中に、分散トランザクション処理において異常を検出した場合に、その整合性を維持するために実施される補償処理を部分実施する補償部分実施部２１ａ〜２１ｎを配置する部分補償配置部１１と、既に実施した分散トランザクション処理の実績を基に、少なくとも合意サービス水準をパラメータとして定義された事項を複数の補償処理の手順方式の各々に関して評価して期待値データを算出するコスト期待値計算部１２と、複数の期待値データを管理し、補償部分実施部２１ａ〜２１ｎからの問い合わせに応じて、管理する期待値データに基づいて補償処理の手順方式を指定する補償コスト期待値管理部１３とを含み、補償処理の手順方式を、当該分散トランザクション処理全体の性能を最適化するよう、合意サービス水準を考慮して選択することを特徴とする。
このような構成とすることにより、複数サーバにより実施されるロングライブトランザクション方式に基づく分散トランザクション処理の整合性を最適な計算資源を用いながら維持管理可能となる。
なお、補償処理手順方式選択装置の各機能部は、コンピュータにプログラムを実行させることによりソフトウェア処理で実現することも可能である。
以下、本発明の好適な実施の形態について説明する。
補償トランザクションの処理の概要について図２〜図１１を用いて説明する。
図２に、補償トランザクションの処理モデルを定義するための最も基本的な計算機ネットワーク環境を模式的に示す。
ここで、ロングライブトランザクション方式による分散トランザクション処理を起動する計算機を、サービスクライアントノードＡ１とする。そして、サービスクライアントノードＡ１は、分散トランザクション処理では、サービス中間ノードＡ２に相当する計算機、及びサービス中間ノードＡ３に相当する計算機を順次又は同時に通信を使って呼び出すものとする。なお、サービス中間ノードの数は２以上であれば任意である。
サービス中間ノードＡ２は、分散トランザクション処理を受けると、サービス末端ノードＡ４に相当する計算機、及びサービス末端ノードＡ５に相当する計算機を順次又は同時に通信を使って呼び出すものとする。なお、サービス中間ノードＡ２の配下のサービス末端ノードの数は１以上であれば任意である。
さらに、サービス中間ノードＡ２の配下には、サービス中間ノードＡ２とサービス末端ノードＡ４及びサービス末端ノードＡ５との間に別のサービス中間ノードを１段以上配置しても良い。
サービス中間ノードＡ３は、分散トランザクション処理を受けると、サービス末端ノードＡ６に相当する計算機、及びサービス末端ノードＡ７に相当する計算機を順次又は同時に通信を使って呼び出すものとする。なお、サービス中間ノードＡ３の配下のサービス末端ノードの数は１以上であれば任意である。
さらに、サービス中間ノードＡ３の配下には、サービス中間ノードＡ３とサービス末端ノードＡ６及びサービス末端ノードＡ７との間に別のサービス中間ノードを１段以上配置しても良い。
ロングライブトランザクション方式による分散トランザクション処理の正常処理を図３を用いて説明する。図３では、各種メッセージが、サービスクライアントノードＡ１、サービス中間ノードＡ２（サービス中間ノード−１）、Ａ３（サービス中間ノード−ｎ）及びサービス末端ノードＡ４（サービス末端ノード−１−１）、Ａ５（サービス末端ノード−１−ｋ）、Ａ６（サービス末端ノード−ｎ−１）、Ａ７（サービス末端ノード−ｎ−ｍ）で交換される。その際、メッセージの略称として以下のルールを用いる。
正常系の更新要求メッセージは記号：［更新要求-x(+)］で表す。この記号における文字列ｘは、メッセージの送信先のサイトを意味する。また、文字列（＋）は、正常系の更新要求メッセージであることを意味する。
更新応答メッセージは、記号：［更新応答-x(+:Y)］で表す。この記号における文字列ｘは、正常系の更新要求メッセージの発信元であるサイトを意味する。また文字列（＋）は、正常系の更新応答メッセージであることを意味する。また、文字列（：Ｙ）は、応答に含まれる結果を意味し、処理が成功した場合はリテラル“：Ｔｒｕｅ”が、失敗した場合はリテラル“：Ｆａｌｓｅ”が記載される。
また、記号：［更新要求-x(+)］で表された更新要求メッセージに対する、補償要求に関する補償要求メッセージについては、記号［補償要求-x(-)］で表す。さらに、この補償要求メッセージに対する補償応答メッセージは記号：［補償応答-x(-:Y)］で表す。ここで、以上の記号のｘ及びＹの意味は、正常系の更新要求メッセージと同様である。
サービスクライアントノードＡ１が、ロングライブトランザクション方式による分散トランザクション処理を開始する場合、サービス中間ノードＡ２に更新要求メッセージＡ１００（［更新要求-1(+)］）を送信する。
サービス中間ノードＡ２は、更新要求メッセージＡ１００を受信すると、配下に分散トランザクション処理を構成する他のサイトがある場合は、相当の更新要求メッセージを改めて送信する。例えば、サービス末端ノードＡ４、Ａ５が存在する場合、サービス末端ノードＡ４に更新要求メッセージＡ１０１（［更新要求-1-1(+)］）を送信する。
分散トランザクション処理が並列に処理可能である場合は、サービス末端ノードＡ４からの更新応答メッセージＡ１０２（［更新応答-1-1(+:true)］）を受信する前に、続けてサービス末端ノードＡ５へ更新要求メッセージＡ１０３（［更新要求-1-k(+)］）を送信する。
サービス末端ノードＡ４では、更新要求メッセージＡ１０１を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。この場合、ロングライブトランザクション方式を採用しているため、２フェーズコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新の結果を意味する更新応答メッセージＡ１０２が返信される。
分散トランザクション処理が直列に処理される場合は、サービス中間ノードＡ２が更新応答メッセージＡ１０２を受信すると、サービス末端ノードＡ５に更新要求メッセージＡ１０３を送信する。
サービス末端ノードＡ５では、更新要求メッセージＡ１０３を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。この場合、ロングライブトランザクション方式を採用しているため、２フェーズコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新の結果を意味する更新応答メッセージＡ１２５が返信される。
サービス中間ノードＡ２が、全ての更新応答メッセージ（更新応答メッセージＡ１０２、Ａ１２５）を受信すると、送信元であるサービスクライアントノードＡ１に更新応答メッセージＡ１２６（［更新応答-1(+:True)］）を返信する。
以上と同等の処理について、サービス中間ノードＡ３とも行う。このため、サービスクライアントノードＡ１は、サービス中間ノードＡ３に更新要求メッセージＡ１０６（［更新要求-n(+)］）を送信し、更新応答メッセージＡ１１１（［更新応答-n(+:True)］）を受信する。
サービスクライアントノードＡ１は、全ての更新応答メッセージ（更新応答メッセージＡ１２６及び更新応答メッセージＡ１１１）を受信すると、ロングライブトランザクション方式による分散トランザクション処理を正常終了したとみなす。
図４は、図３に示したロングライブトランザクション方式による分散トランザクション処理の正常処理を、流通するメッセージ群及び処理タイミングを含んで定義したシーケンス図であり、直列化して実施する場合を示す。
これに対して図５は、図３に示したロングライブトランザクション方式による分散トランザクション処理の正常処理を、流通するメッセージ群及び処理タイミングを含んで定義したシーケンス図であり、並列化して実施する場合を示す。
サービスクライアントノードＡ１が、ロングライブトランザクション方式による分散トランザクション処理を開始する場合、起動要求Ａ１５０を受信したのち、サービスクライアントノードＡ１内にプロセスＡ１５３が立ち上がる。その後、サービス中間ノードＡ２に更新要求メッセージＡ１００を送信する。
サービス中間ノードＡ２は、更新要求メッセージＡ１００を受信すると、内部にプロセスＡ１５４が立ち上がる。その後、サービス末端ノードＡ４及びサービス末端ノードＡ５のような、配下に分散トランザクション処理を構成する他のサイトがある場合、相当の更新要求メッセージを改めて送信する。ここでは、サービス中間ノードＡ２は、サービス末端ノードＡ４へ更新要求メッセージＡ１０１を送信する。
サービス末端ノードＡ４では、更新要求メッセージＡ１０１を受信すると、内部プロセスＡ１５５が立ち上がる。プロセスＡ１５５は、サービス末端ノードＡ４内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。その後、更新の結果を意味する更新応答メッセージＡ１０２が返信される。
分散トランザクション処理が直列に処理される場合は、サービス中間ノードＡ２のプロセスＡ１５４が、更新応答メッセージＡ１０２を受信すると、サービス末端ノードＡ５に更新要求メッセージＡ１０３を送信する。
サービス末端ノードＡ５では、更新要求メッセージＡ１０３を受信すると、内部にプロセスＡ１５６が立ち上がる。プロセスＡ１５６は、サービス末端ノードＡ５内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。その後、更新の結果を意味する更新応答メッセージＡ１２５が返信される。
サービス末端ノードＡ４及びＡ５の他にサービス末端ノードが存在する場合は、更新応答メッセージＡ１０２の受信及びサービス末端ノードＡ５への更新要求メッセージＡ１０３の送信の間、又は前後で処理することが可能である。
サービス中間ノードＡ２のプロセスＡ１５４が、全ての更新応答メッセージ（更新応答メッセージＡ１０２、Ａ１２５）を受信すると、送信元であるサービスクライアントノードＡ１のプロセスＡ１５３に更新応答メッセージＡ１２６を返信する。
その後、他のサービス中間ノードが存在する場合は、サービスクライアントノードＡ１のプロセスＡ１５３は、サービス中間ノードＡ２と同等の処理を他のサービス中間ノード行う。ここでは、サービス中間ノードＡ３に更新要求メッセージＡ１０６を送信する。
サービス中間ノードＡ３は、更新要求メッセージＡ１０６を受信すると、内部にプロセスＡ１５７が立ち上がる。その後、サービス中間ノードＡ２と同様の処理を行った後、送信元であるサービスクライアントノードＡ１のプロセスＡ１５３に更新応答メッセージＡ１１１を返信する。
サービスクライアントノードＡ１のプロセスＡ１５３は、全ての更新応答メッセージ（更新応答メッセージＡ１２６、Ａ１１１）を受信すると、ロングライブトランザクション方式による分散トランザクション処理を正常終了したとみなし、正常終了Ａ１５１を通知する。
図５において、サービスクライアントノードＡ１が、ロングライブトランザクション方式による分散トランザクション処理を開始する場合、起動要求Ａ１５０を受信の後、サービスクライアントノードＡ１内にプロセスＡ１５３が立ち上がる。その後、分散トランザクション処理が並列に処理される場合は、サービス中間ノードＡ２に更新要求メッセージＡ１００を送信するとともに、サービス中間ノードＡ３に更新要求メッセージＡ１０６を送信する。
サービス中間ノードＡ２は、更新要求メッセージＡ１００を受信すると、内部にプロセスＡ１５４が立ち上がる。その後、サービス末端ノードＡ４及びＡ５のような、配下に分散トランザクション処理を構成する他のサイトがある場合、サービス末端ノードＡ４に更新要求メッセージＡ１０１を、サービス末端ノードＡ５に更新要求メッセージＡ１０３をそれぞれ出力する。
サービス末端ノードＡ４は、更新要求メッセージＡ１０１を受信すると、内部にプロセスＡ１５５が立ち上がる。プロセスＡ１５５は、サービス末端ノードＡ４内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。その後、更新の結果を意味する更新応答メッセージＡ１０２が返信される。
サービス末端ノードＡ５は、更新要求メッセージＡ１０３を受信すると、内部にプロセスＡ１５６が立ち上がる。プロセスＡ１５６は、サービス末端ノードＡ５内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。その後、更新の結果を意味する更新応答メッセージＡ１２５が返信される。
サービス末端ノードＡ４、Ａ５の他にサービス末端ノードが存在する場合は、サービス末端ノードＡ５への更新要求メッセージＡ１０３の送信同様の処理を行う。
サービス中間ノードＡ２のプロセスＡ１５４が、全ての更新応答メッセージ（更新応答メッセージＡ１０２、Ａ１２５）を受信すると、送信元であるサービスクライアントノードＡ１のプロセスＡ１５３に更新応答メッセージＡ１２６を返信する。
サービス中間ノードＡ３は、サービス更新要求メッセージＡ１０６を受信すると、内部にプロセスＡ１５７が立ち上がる。その後、サービス中間ノードＡ２と同様の処理を行った後、送信元であるサービスクライアントノードＡ１のプロセスＡ１５３に更新応答メッセージＡ１１１を返信する。
サービスクライアントノードＡ１のプロセスＡ１５１は、全ての更新応答メッセージ（更新応答メッセージＡ１２６、Ａ１１１）を受信すると、ロングライブトランザクション方式による分散トランザクション処理を正常終了したとみなし、正常終了Ａ１５１を通知する。
ロングライブトランザクション方式による分散トランザクション処理で障害が発生した場合に実施される補償トランザクション群についてSaga方式を採用した場合の処理を、図６を用いて説明する。図６では、各種メッセージがサービスクライアントノードＡ１、サービス中間ノードＡ２、Ａ３及びサービス末端ノードＡ４、Ａ５、Ａ６、Ａ７で交換される。
サービスクライアントノードＡ１が、ロングライブトランザクション方式による分散トランザクション処理を開始する場合、サービス中間ノードＡ２に更新要求メッセージＡ１００を送信する。
サービス中間ノードＡ２は、更新要求メッセージＡ１００を受信すると、配下に分散トランザクション処理を構成する他のサイトがある場合は、相当の更新要求メッセージを改めて送信する。例えば、サービス末端ノードＡ４、Ａ５が存在する場合、サービス末端ノードＡ４に更新要求メッセージＡ１０１を送信する。
分散トランザクション処理が並列に処理可能である場合は、サービス末端ノードＡ４からの更新応答メッセージＡ１０２を受信する前に、続けてサービス末端ノードＡ５に更新要求メッセージＡ１０３を送信する。
サービス末端ノードＡ４は、更新要求メッセージＡ１０１を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。この場合、ロングライブトランザクション方式を採用しているため、２フェーズコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新の結果を意味する更新応答メッセージＡ１０２が返信される。
分散トランザクション処理が直列に処理される場合は、サービス中間ノードＡ２が更新応答メッセージＡ１０２を受信すると、サービス末端ノードＡ５に更新要求メッセージＡ１０３を送信する。
サービス末端ノードＡ５では、更新要求メッセージＡ１０３を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。更新不可能な場合はその旨応答する。この場合、ロングライブトランザクション方式を採用しているため、２フェーズコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新不可の結果を意味する更新応答メッセージＡ１０４（［更新応答-1-k(+:False)］）が返信される。
サービスクライアントノードＡ１は、並列処理を行う場合、サービス中間ノードＡ２に更新要求メッセージＡ１００を送信するとともに、サービス中間ノードＡ３に更新要求メッセージＡ１０６を送信する。
サービス中間ノードＡ３は、更新要求メッセージＡ１０６を受信すると、配下に分散トランザクション処理を構成する他のサイトがある場合は、相当の更新要求メッセージを改めて送信する。例えば、サービス末端ノードＡ６、Ａ７が存在する場合、サービス末端ノードＡ６に更新要求メッセージＡ１０７（［更新要求-n-1(+)］）を送信する。
サービス末端ノードＡ６では、更新要求メッセージＡ１０７を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。この場合、ロングライブトランザクション方式を採用しているため、２フェーズコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新の結果を意味する更新応答メッセージＡ１０８（［更新応答-n-1(+:True)］）が返信される。
分散トランザクション処理が直列に処理される場合は、サービス中間ノードＡ３が更新応答メッセージＡ１０８を受信すると、サービス末端ノードＡ７に更新要求メッセージＡ１０９（［更新要求-n-m(+)］）を送信する。
サービス末端ノードＡ７では、更新要求メッセージＡ１０９を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は更新処理を実施する。この場合、ロングライブトランザクション方式を採用しているため、２フェーズコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新の結果を意味する更新応答メッセージＡ１１０（［更新応答-n-m(+:True)］）が返信される。
サービス中間ノードＡ３が全ての更新応答メッセージ（更新応答メッセージＡ１０８、Ａ１１０）を受信すると、送信元であるサービスクライアントノードＡ１に更新応答メッセージＡ１１１（［更新応答-n(+:True)］）を返信する。
サービス中間ノードＡ２は、更新応答メッセージＡ１０４を受信すると、配下に分散トランザクション処理を構成する他のサイトがあり、Saga方式で補償トランザクション群を実施する場合、サービス末端ノードＡ４に補償処理の補償要求メッセージＡ１１３（［補償要求-1-1(-)］）を送信する。
サービス末端ノードＡ４では、補償処理の補償要求メッセージＡ１１３を受信すると、内部に保持するデータベース等のデータについて元の状態に戻すため、更新処理を実施する。この結果を意味する補償応答メッセージＡ１１４（［補償応答-1-1(-:True)］）が返信される。
サービス中間ノードＡ２は、全ての配下のサービス末端ノードに対して、補償処理の要求処理を行い、その結果として、補償応答メッセージＡ１１４相当のものを受信すると、送信元であるサービスクライアントノードＡ１に更新応答メッセージＡ１０５（［更新応答-1(+:False)］）を返信する。
サービスクライアントノードＡ１は、補償処理を行うため、サービス中間ノードＡ３に補償処理の補償要求メッセージＡ１１８（［補償要求-n(-)］）を送信する。
サービス中間ノードＡ３は、補償処理の補償要求メッセージＡ１１８を受信すると、サービス末端ノードＡ６に補償処理の補償要求メッセージＡ１１９（［補償要求-n-1(-)］）を送信する。
分散トランザクション処理が並列に処理可能である場合は、サービス末端ノードＡ６からの補償処理の補償応答メッセージＡ１２０（［補償応答-n-1(-:True)］）を受信する前に、続けてサービス末端ノードＡ７に補償処理の補償要求メッセージＡ１２１（［報償要求-n-m(-)］）を送信する。
サービス末端ノードＡ６では、補償処理の補償要求メッセージＡ１１９を受信すると、内部に保持するデータベース等のデータについて元の状態に戻すため、更新処理を実施する。この結果を意味する補償処理の補償応答メッセージＡ１２０（［補償応答-n-1(-:True)］）が返信される。
分散トランザクション処理が直列に処理される場合は、サービス中間ノードＡ３が、補償処理の補償応答メッセージＡ１２０を受信すると、サービス末端ノードＡ７に補償処理の補償要求メッセージＡ１２１（［補償要求-n-m(-)］）を送信する。
サービス末端ノードＡ７では、補償要求メッセージＡ１２１を受信すると、内部に保持するデータベース等のデータについて元の状態に戻すため、更新処理を実施する。この結果を意味する補償処理の補償応答メッセージＡ１２２（［補償応答-n-m(-:True)］）が返信される。
サービス中間ノードＡ３が補償処理の全ての補償応答メッセージ（補償応答メッセージＡ１２０、Ａ１２２）を受信すると、送信元であるサービスクライアントノードＡ１に補償処理の補償応答メッセージＡ１２３（［補償応答-n(-:True)］）を返信する。
サービスクライアントノードＡ１は、全ての更新応答メッセージ及び補償処理の補償応答メッセージ（更新応答メッセージＡ１０５等、補償応答メッセージＡ１２３）を受信すると、ロングライブトランザクション方式による分散トランザクション処理を異常終了したと見なす。
図７は、図６に示されたロングライブトランザクション方式による分散トランザクション処理で障害が発生した場合に実施される補償トランザクション群についてSaga方式を採用した場合の処理を、流通するメッセージ群及び処理タイミングを含んで定義したシーケンス図であり、直列化して実施する場合を示す。
図７では、直列化して実施されるため、サービス中間ノードＡ２のプロセスＡ１５４がサービス末端ノードＡ５に対して更新要求メッセージＡ１０３を送信し、更新不可の結果を意味する更新応答メッセージＡ１０４が返信された場合、サービス末端ノードＡ５に対する処理は存在せずに、サービス末端ノードＡ４に対する補償処理を行うに留まる。さらに、サービス中間ノードＡ３に対する更新要求メッセージＡ１０６が送信されていないため、サービスクライアントノードＡ１のプロセスＡ１５３が更新応答メッセージＡ１０５を受信すると、ロングライブトランザクション方式による分散トランザクション処理を異常終了したとみなし、異常終了Ａ１５２を通知する。
これに対して図８は、図６に示されたロングライブトランザクション方式による分散トランザクション処理で障害が発生した場合に実施される補償トランザクション群についてSaga方式を採用した場合の処理を、流通するメッセージ群及び処理タイミングを含んで定義したシーケンス図であり、並列化して実施する場合を示す。
図８では、並列化して実施されるため、サービス中間ノードＡ２のプロセスＡ１５４がサービス末端ノードＡ５に対して更新要求メッセージＡ１０３を送信し、更新不可の結果を意味する更新応答メッセージＡ１０４が返信された場合、サービス末端ノードＡ４対する補償処理を行う。さらに、サービス中間ノードＡ３に対する更新要求メッセージＡ１０６が送信されているため、サービスクライアントノードＡ１のプロセスＡ１５３が更新応答メッセージＡ１０５を受信すると、補償処理を行うため、サービス中間ノードＡ３に補償処理の補償要求メッセージＡ１１８を送信する。
サービス中間ノードＡ３は、補償処理の補償要求メッセージＡ１１８を受信すると、サービス末端ノードＡ６に補償処理の補償要求メッセージＡ１１９を送信する。
続けてサービス末端ノードＡ７に補償処理の補償要求メッセージＡ１２１を送信する。
以上の結果を受けて、サービス中間ノードＡ３が全ての補償応答メッセージ（補償応答メッセージＡ１２０、Ａ１２２）を受信すると、送信元であるサービスクライアントノードＡ１に補償処理の補償応答メッセージＡ１２３を返信する。
サービスクライアントノードＡ１は、補償処理の全ての更新応答メッセージ及び補償応答メッセージ（更新応答メッセージＡ１０５等、及び補償応答メッセージＡ１２３）を受信すると、ロングライブトランザクション方式による分散トランザクション処理を異常終了したとみなし、異常終了Ａ１５２を通知する。
ロングライブトランザクション方式による分散トランザクション処理で障害が発生した場合に実施される補償トランザクション群についてTop Down打ち消し再試行方式を採用した場合の処理を、図９を用いて説明する。図９では各種メッセージがサービスクライアントノードＡ１、サービス中間ノードＡ２、Ａ３及びサービス末端ノードＡ４、Ａ５、Ａ６、Ａ７で交換される。
サービスクライアントノードＡ１がロングライブトランザクション方式による分散トランザクション処理を開始する場合、サービス中間ノードＡ２に更新要求メッセージＡ１００を送信する。
サービス中間ノードＡ２は、更新要求メッセージＡ１００を受信すると、配下に分散トランザクション処理を構成する他のサイトがある場合は、相当の更新要求メッセージを改めて送信する。例えば、サービス末端ノードＡ４、Ａ５が存在する場合、サービス末端ノードＡ４に更新要求メッセージＡ１０１を送信する。
分散トランザクション処理が並列に処理可能である場合は、サービス末端ノードＡ４からの更新応答メッセージＡ１０２を受信する前に、続けてサービス末端ノードＡ５に更新要求メッセージＡ１０３を送信する。
サービス末端ノードＡ４では、更新要求メッセージＡ１０１を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は更新処理を実施する。この場合、ロングライブトランザクション方式を採用しているため、２フェーズコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新結果を意味する更新応答メッセージＡ１０２が返信される。
分散トランザクション処理が直列に処理される場合は、サービス中間ノードＡ２が更新応答メッセージＡ１０２を受信すると、サービス末端ノードＡ５に更新要求メッセージＡ１０３を送信する。
サービス末端ノードＡ５では、更新要求メッセージＡ１０３を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は更新処理を実施する。更新不可能な場合は、その旨応答する。この場合、ロングライブトランザクション方式を採用しているため、２フェーズコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新不可の結果を意味する更新応答メッセージＡ１０４が返信される。
サービスクライアントノードＡ１は、並列処理を行う場合、サービス中間ノードＡ２に更新要求メッセージＡ１００を送信するとともに、サービス中間ノードＡ３に更新要求メッセージＡ１０６を送信する。
サービス中間ノードＡ３は、更新要求メッセージＡ１０６を受信すると、配下に分散トランザクション処理を構成する他のサイトがある場合は、相当の更新要求メッセージを改めて送信する。例えば、サービス末端ノードＡ６、Ａ７が存在する場合、サービス末端ノードＡ６に更新要求メッセージＡ１０７を送信する。
分散トランザクション処理が並列に処理可能である場合は、サービス末端ノードＡ６からの更新応答メッセージＡ１０８を受信する前に、続けてサービス末端ノードＡ７に更新要求メッセージＡ１０９を送信する。
サービス末端ノードＡ６では、更新要求メッセージＡ１０７を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。この場合、ロングライブトランザクション方式を採用しているため、２フェーズコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新の結果を意味する更新応答メッセージＡ１０８が返信される。
分散トランザクション処理が直列に処理される場合は、サービス中間ノードＡ３が更新応答メッセージＡ１０８を受信すると、サービス末端ノードＡ７に更新要求メッセージＡ１０９を送信する。
サービス末端ノードＡ７では、更新要求メッセージＡ１０９を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。この場合、ロングライブトランザクション方式を採用しているため、２フェーズコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新の結果を意味する更新応答メッセージＡ１１０が返信される。
サービス中間ノードＡ３が、全ての更新応答メッセージ（更新応答メッセージＡ１０８、Ａ１１０）を受信すると、送信元であるサービスクライアントノードＡ１に更新応答メッセージＡ１１１を返信する。
Top Down打ち消し再試行方式で補償トランザクション群を実施する場合、サービス中間ノードＡ２が更新応答メッセージＡ１０４を受信すると、サービスクライアントノードＡ１に更新不可の結果を意味する更新応答メッセージＡ１０５が返信される。
サービスクライアントノードＡ１は、更新応答メッセージＡ１０５を受信すると、サービス中間ノードＡ３等で更新されたことにより発生する不具合を是正するため、補償処理を実施する。このため、サービス中間ノードＡ２に更新要求メッセージＡ１００の打ち消しに相当する補償処理の補償要求メッセージＡ１１２（［補償要求-1(-)］）を送信する。
サービス中間ノードＡ２は、補償要求メッセージＡ１１２を受信すると、配下に分散トランザクション処理を構成する他のサイトがある場合は、打ち消しに相当する補償処理の補償要求メッセージを送信する。例えば、サービス末端ノードＡ４、Ａ５が存在する場合、サービス末端ノードＡ４に補償要求メッセージＡ１１３（［補償要求-1-1(-)］）を送信する。
補償処理に関する分散トランザクション処理が並列に処理可能である場合は、サービス末端ノードＡ４からの補償応答メッセージＡ１１４（［補償応答-1-1(-:True)］）を受信する前に、続けてサービス末端ノードＡ５に補償処理の補償要求メッセージＡ１１５（［補償要求-1-k(-)］）を送信してもよい。この補償処理は、更新要求メッセージＡ１０３に対応するものである。したがって、サービス中間ノードＡ２が更新要求メッセージＡ１０３との対応関係を把握しており、更新不可能であることを把握できている場合は、補償要求メッセージＡ１１５は送信されなくても良い。
サービス末端ノードＡ４では、補償処理の補償要求メッセージＡ１１３を受信すると、内部に保持するデータベース等のデータについて元の状態に戻すため、更新処理を実施する。この結果を意味する補償応答メッセージＡ１１４が返信される。
サービス中間ノードＡ２は、全ての配下のサービス末端ノードに対して、補償処理の要求を行い、その結果として、補償応答メッセージＡ１１４、補償応答メッセージＡ１１６（［補償応答-1-k(-:True)］）相当のものを受信すると、送信元であるサービスクライアントノードＡ１に補償応答メッセージＡ１１７（［補償応答-1(-:True)］）を返信する。
サービスクライアントノードＡ１は、補償処理を行うため、サービス中間ノードＡ３に補償処理に補償要求メッセージＡ１１８を出力する。
サービス中間ノードＡ３は、さらに補償処理の補償要求メッセージＡ１１８を受信すると、サービス末端ノードＡ６に補償処理の補償要求メッセージＡ１１９を送信する。
分散トランザクション処理が並列に処理可能である場合は、サービス末端ノードＡ６からの補償処理の補償応答メッセージＡ１２０を受信する前に、続けてサービス末端ノードＡ７に補償要求メッセージＡ１２１を送信する。
サービス末端ノードＡ６では、補償処理の補償要求メッセージＡ１１９を受信すると、内部に保持するデータベース等のデータについて元の状態に戻すために、更新処理を実施する。この結果を意味する補償処理の補償応答メッセージＡ１２０が送信される。
分散トランザクション処理が直列に処理される場合は、サービス中間ノードＡ３が補償処理の補償応答メッセージＡ１２０を受信すると、サービス末端ノードＡ７に補償処理の補償要求メッセージＡ１２１を送信する。
サービス末端ノードＡ７では、補償要求メッセージＡ１２１を受信すると、内部に保持するデータベース等のデータについて元の状態に戻すため、更新処理を実施する。この結果を意味する補償処理の補償応答メッセージＡ１２２が返信される。
サービス中間ノードＡ３が、補償処理の全ての補償応答メッセージ（補償応答メッセージＡ１２０、Ａ１２２）を受信すると、送信元であるサービスクライアントノードＡ１に補償処理の補償応答メッセージＡ１２３を返信する。
サービスクライアントノードＡ１は、補償処理に関する全ての補償応答メッセージ（補償応答メッセージＡ１１７、Ａ１２４）を受信すると、ロングライブトランザクション方式による分散トランザクション処理が異常終了し、その後の補償処理が正常終了したと見なす。
図１０は、図９に示すロングライブトランザクション方式による分散トランザクション処理で障害が発生した場合に実施される補償トランザクション群についてTop Down打ち消し再試行方式を採用した場合の処理を、流通するメッセージ群及び処理タイミングを含んで定義したシーケンス図であり、直列化して実施する場合を示す。
図１０では、Top Down打ち消し再試行方式を直列化して実施するため、サービス中間ノードＡ２のプロセスＡ１５４が、サービス末端ノードＡ５に対して更新要求メッセージＡ１０３を送信し、更新不可の結果を意味する更新応答メッセージＡ１０４が返信された場合、サービスクライアントノードＡ１のプロセスＡ１５３に送信する前に一切の補償処理を実施しない。
サービスクライアントノードＡ１のプロセスＡ１５３は、サービス中間ノードＡ２からの更新応答メッセージＡ１０５を受信すると、ロングライブトランザクション方式による分散トランザクション処理が異常終了したと見なし、異常終了Ａ１５２を通知する。
続けて、サービスクライアントノードＡ１は、更新要求メッセージＡ１００の打ち消しに相当する補償処理の補償要求メッセージＡ１１２をサービス中間ノードＡ２に送信する。補償処理の実施順序については、更新要求メッセージＡ１００の実施の際の実施順序を継承する。最後に、サービスクライアントノードＡ１は、打ち消しに相当する補償処理が正常に終了した旨の正常終了Ａ１９０を通知する。
これに対して図１１は、図９に示すロングライブトランザクション方式による分散トランザクション処理で障害が発生した場合に実施される補償トランザクション群についてTop Down打ち消し再試行方式を採用した場合の処理を、流通するメッセージ群及び処理タイミングを含んで定義したシーケンス図であり、並列化して実施する場合を示す。
図１１では、Top Down打ち消し再試行方式が並列化して実施される。しかし、図１０の直列化して実施された場合と比較して、大きな差異は存在しない。この場合、サービス中間ノードＡ２のプロセスＡ１５４がサービス末端ノードＡ５に対して更新要求メッセージＡ１０３を送信し、更新不可の結果を意味する更新応答メッセージＡ１０４が返信された場合、サービスクライアントノードＡ１のプロセスＡ１５３に返信する前に一切の補償処理を実施しない。
サービスクライアントノードＡ１のプロセスＡ１５３は、サービス中間ノードＡ２からの更新応答メッセージＡ１０５を受信すると、ロングライブトランザクション方式による分散トランザクション処理が異常終了したとみなし、異常終了Ａ１５２を通知する。
続けて、サービスクライアントノードＡ１は、サービス中間ノードＡ２に更新要求メッセージＡ１００の打ち消しに相当する補償処理の補償要求メッセージＡ１１２を送信する。補償処理の実施順序については、更新要求メッセージＡ１００の実施の際の実施順序を継承する。最後に、サービスクライアントノードＡ１は、打ち消しに相当する補償処理が正常に終了した旨の正常終了Ａ１９０を通知する。
合意サービス水準（Service Level Agreement:SLA）を考慮して補償トランザクション方法を選択する装置について図１２、図１３〜１５、図１６及び図１７を用いて説明する。
図１２に、図４及び図５のシーケンスに示されたロングライブトランザクション方式による分散トランザクション処理の正常終了と、図７及び図８のシーケンスに示されたSaga方式の補償トランザクション群の処理と、図１０及び図１１に示されたTop Down打ち消し再試行方式の補償トランザクション群の処理とを、合意サービス水準を考慮して選択的に実施する装置の構成を示す。
この構成においては、１以上のサービスクライアント、１以上のサービス処理系、１以上のワークフロー処理系が存在するものとする。また、トランザクション・SLAモニタ管理部Ｂ１１、デプロイヤＢ１３、Ｂ１５、ＳＯＡ（Service Oriented Architecture）リポジトリＢ１２、開発環境Ｂ１４を有する。トランザクション・SLAモニタ管理部Ｂ１１は、複数備えていても良い。さらに、デプロイヤＢ１３、Ｂ１５、ＳＯＡリポジトリＢ１２、開発環境Ｂ１４は、複数備えていても良いし、備えていなくても良い。
サービスクライアントとは、複数のサービスとワークフローとを合成してできる合成ワークフローを呼び出すプログラム、システムであり、複数存在し、具体的にはサービスクライアントＢ１、Ｂ２及びＢ３が含まれる。
サービスとは、データの書き込みや提供を伴う、決められた個別機能を提供するプログラムのことであり、サービスクライアント等から呼びされて起動し、決められた機能・結果を提供するものである。サービス処理系とは、１以上のサービスを実行する処理系のプログラム、システムのことであり、複数存在し、具体的にはサービス処理系Ｂ６、Ｂ７、Ｂ８、Ｂ９、Ｂ１０が相当する。
ワークフローとは、複数のサービスを纏まった形で束ね、あるまとまった作業を順次行うものであり、サービスクライアント等から呼び出されて起動し、決められたサービスを順次利用しながら決められた機能・結果を提供するものである。なお、ワークフローをプロセスと称することもある。ワークフロー処理系とは、１以上のワークフローであるプロセスを実行する処理系のプログラム、システムのことであり、複数存在し、具体的にはワークフロー処理系Ｂ４、Ｂ５が相当する。なお、ワークフロー処理系Ｂ４、Ｂ５は図１のワークフロー処理系２ａ〜２ｎに相当する。
トランザクション・SLAモニタ管理部Ｂ１１は、実際に処理されるサービス群、ワークフロー群、特に複数のワークフロー群が集積して定義される合成ワークフロー群の実行状況を、合成ワークフロー群の個々の起動単位でモニタリングするとともに、モニタリングした結果を基にサービス群、ワークフロー群、合成ワークフロー群の実行環境を調整する。
モニタリングには、個々の起動単位が仕様に基づき起動しているか否かを判断すること、及び起動にあたって利用されるメモリ量、ＣＰＵ使用率、ネットワーク使用量等の計算機資源の時間経過に対する変動状況を把握すること、並びに変動状況の時間微分的変化、統計情報等の時間微分的変化を把握することが含まれる。
把握された変動状況の時間微分的変化、統計情報等の時間微分的変化については、計算機資源の新規追加、又は解放等の制御機能に利用され、複数のサービス処理系、複数のワークフロー処理系の制御に利用される。
デプロイヤは複数存在し、サービス処理系に展開するデプロイヤＢ１３と、トランザクション・SLAモニタ管理部Ｂ１１に必要なものを登録するためのデプロイヤＢ１５とに大別できる。なお、デプロイヤＢ１３は図１の部分補償配置部１１に相当する。
ＳＯＡリポジトリＢ１２には、複数のサービス処理系、複数のワークフロー処理系に展開する一切のプログラム、定義情報が登録、維持、管理される。
一つのサービス処理系を一般的なモデルで表すと、０以上の参照系サービス、１以上の更新系サービス、１以上の更新系サービス補償、データを管理するData、Dataに対する操作ログを管理する操作ログを含んで構成される。
以上を受けて、サービス処理系Ｂ６には、参照系サービスＢ３０、更新系サービスＢ３１、更新系サービス補償Ｂ３２、DataＢ３３及び操作ログＢ３４が含まれる。
同様に、サービス処理系Ｂ７には、参照系サービスＢ３５、更新系サービスＢ３６、更新系サービス補償Ｂ３７、DataＢ３８及び操作ログＢ３９が含まれる。
同様に、サービス処理系Ｂ８には、参照系サービスＢ４０、更新系サービスＢ４１、更新系サービス補償Ｂ４２、DataＢ４３及び操作ログＢ４４が含まれる。
同様に、サービス処理系Ｂ９には、参照系サービスＢ４５、更新系サービスＢ４６、更新系サービス補償Ｂ４７、DataＢ４８及び操作ログＢ４９が含まれる。
同様に、サービス処理系Ｂ１０には、参照系サービスＢ５０、更新系サービスＢ５１、更新系サービス補償Ｂ５２、DataＢ５３及び操作ログＢ５４が含まれる。
一つのワークフロー処理系を一般的なモデルで表すと、複数のワークフロー定義、その補償処理の定義であるワークフロー補償及び操作ログを含んで構成される。
以上を受けて、ワークフロー処理系Ｂ４には、ワークフローＢ１６、ワークフロー補償Ｂ１８及び操作ログＢ２８が含まれる。
同様に、ワークフロー処理系Ｂ５には、ワークフローＢ１７、ワークフロー補償Ｂ１９及び操作ログＢ２９が含まれる。
ワークフローＢ１６、Ｂ１７、ワークフロー補償Ｂ１８、Ｂ１９は、WS-BPEL（Web Business Process Execution Language）やXPDL（XML Process Definition Language）等のプロセスを記述する任意言語によって記述される。
記述されたものはプロセスとして定義され、ワークフローＢ１６は、その内部にプロセスの定義Ｂ６７を持つ。また、ワークフローＢ１７は、その内部にプロセスの定義Ｂ６９を持つ。さらに、ワークフロー補償Ｂ１８は、その内部にプロセスの定義Ｂ６８を持ち、ワークフロー補償Ｂ１９はその内部にプロセスの定義Ｂ７０を持つ。
ワークフロー補償Ｂ１８は、Top Down打ち消し再試行方式にてワークフローＢ１６における補償処理を実施する場合に利用される。同様に、ワークフロー補償Ｂ１９は、Top Down打ち消し再試行方式にてワークフローＢ１７における補償処理を実施する場合に利用される。
ワークフローＢ１６は、補償ハンドララッパＢ２０を含む。補償ハンドララッパＢ２０は、実際の補償処理を実施する補償ハンドラＢ２４（補償ハンドラ1-1(+)）を含んでいる。補償ハンドラＢ２４は、ワークフローＢ１６における補償処理をSaga方式にて実施する場合に利用される。なお、補償ハンドララッパＢ２０及び補償ハンドラＢ２４は、図１の部分補償実施部２１ａ〜２１ｎに相当する。
ワークフローＢ１７は、補償ハンドララッパＢ２２を含む。補償ハンドララッパＢ２２は、実際の補償処理を実施する補償ハンドラＢ２６（補償ハンドラX-1(+)）を含んでいる。補償ハンドラＢ２６は、ワークフローＢ１７における補償処理をSaga方式にて実施する場合に利用される。なお、補償ハンドララッパＢ２２及び補償ハンドラＢ２６は、図１の部分補償実施部２１ａ〜２１ｎに相当する。
補償ハンドララッパＢ２０、Ｂ２２は、補償処理をTop Down打ち消し再試行方式とするかSaga方式とするかを問い合わせる機能を有する。Saga方式で補償処理を行う場合は、内部に保持する補償ハンドラＢ２４、Ｂ２６を呼び出すこととなる。
ワークフロー補償Ｂ１８は、補償ハンドララッパＢ２１を含む。補償ハンドララッパＢ２１は、ワークフロー補償Ｂ１８が行う補償処理で発生する不具合を解決するためにSaga方式で補償処理を実施する補償ハンドラＢ２５（補償ハンドラ1-1(-)）を含んでいる。
ワークフロー補償Ｂ１９は、補償ハンドララッパＢ２３を含む。補償ハンドララッパＢ２３は、ワークフロー補償Ｂ１９が行う補償処理で発生する不具合を解決するためにSaga方式で補償処理を実施する補償ハンドラＢ２７（補償ハンドラX-1(-)）を含んでいる。
操作ログＢ２８、Ｂ２９は、補償処理を行う際に参照され、Saga方式で補償処理を行う場合は、これらの操作ログの記載順序と逆の順序に従って補償処理を行う。
プロセスの定義Ｂ６７、Ｂ６８、Ｂ６９、Ｂ７０は、プロセスを記述する任意言語（WS-BPELやXPDL等）によって記述される。そのため、個々のサービスを呼び出す単位はアクティビティとして定義される。
例えば、プロセスの定義Ｂ６７では、サービス処理系Ｂ８内の更新系サービスＢ４１を呼び出すアクティビティＢ７３、サービス処理系Ｂ８内の参照系サービスＢ４０を呼び出すアクティビティＢ７２、サービス処理系Ｂ７内の更新系サービスＢ３６を呼び出すアクティビティＢ７４、及び、アクティビティＢ７４、Ｂ７２及びＢ７３を順次呼び出すアクティビティＢ７１を有する。
トランザクション・SLAモニタ管理部Ｂ１１は、いくつかの要素を含む。主要なものは、ログ受信部Ｂ５７、イベントインスタンスデータ管理部Ｂ５８である。
ログ受信部Ｂ５７は、分散トランザクションの実施に伴って発生するトランザクションに関連した複数のサービス処理系、複数のワークフロー処理系のイベントをモニタリングとして活用できるように収集する。
そして、イベントインスタンスデータ管理部Ｂ５８にて実際の管理を行う。ここでは、サービス群、ワークフロー群、特に複数のワークフロー群が集積して定義される合成ワークフロー群の個々の起動単位が仕様であるメタデータ通りに起動しているか否かを把握するためのイベントインスタンスデータや、起動に対して利用されるメモリ量、ＣＰＵ使用率、ネットワーク使用量等の計算機資源の時間経過に対する変動状況を補足したデータ、変動状況の時間微分的変化、統計情報等の時間微分的変化を意味するデータ等が管理される。
トランザクション・SLAモニタ管理部Ｂ１１は、他にも要素を含めて構成できる。WS-BPELやXPDLで記述されるサービス定義のメタデータについて管理するメタデータ管理部Ｂ５６、メタデータ管理部Ｂ５６に登録されているプロセス定義群、サービス定義群から合成ワークフロー定義について合成、定義する統合処理部Ｂ５５、合成ワークフロー定義の一つから定義可能である正常系のAction Tree群及び補償処理を含んだ全Action Tree群を合成するAction Tree生成部Ｂ６６を含めることができる。
イベントインスタンスデータ管理部Ｂ５８内で管理されるイベントインスタンスデータを基にサービスを始めとする各レベルごとの品質水準（合意サービス水準等で定義された事項）を、一定時間間隔で計算するSLA計算部Ｂ６０、SLA計算部Ｂ６０の計算結果を計測時刻とともに管理するSLA実績管理部Ｂ６１、個々のサービス群、個々のワークフロー群、個々の合成ワークフロー群のサービス条件、品質条件について定義し、記載しているデータを管理するSLA管理部Ｂ５９を含めることができる。また、これらはトランザクション・SLAモニタ管理部Ｂ１１の外部に配置しても良い。
トランザクション・SLA管理部Ｂ１１は、他にも要素を含めて構成することができる。
例えば、SLA実績管理部Ｂ６１内に管理される一定時間間隔で算出される計算結果を、SLA管理部Ｂ５９内で管理される個々のサービス群、個々のワークフローの定義するプロセス群、個々の合成ワークフロー群のサービス条件、品質条件と比較し、是正が必要であれば自動的な制御を実施する制御部Ｂ６２を含めることができる。
さらに、各種の補償ハンドララッパＢ２０等で、分散トランザクション処理が異常であることを検出し、その際の補償トランザクション方式を問い合わせるためのコスト問い合わせ受信部Ｂ６５、及びSaga方式、Top Down打ち消し再試行方式、その他の方式各々で補償トランザクション群を実施した場合の分散トランザクション処理全体のスループット効率に関するコストの期待値を、SLA実績管理部Ｂ６１内の計算結果を用いて計算するコスト期待値計算部Ｂ６３、コスト期待値計算部Ｂ６３が計算した結果を管理し、コスト問い合わせ受信部Ｂ６５に提供する補償コスト期待値管理部Ｂ６４を含めることができる。また、これらはトランザクション・SLAモニタ管理部Ｂ１１の外部に配置しても良い。これらはトランザクション・SLAモニタ管理部Ｂ１１の外部に配置しても良い。なお、コスト期待値計算部Ｂ６３は、図１のコスト期待値計算部１２に相当する。また、補償コスト期待値管理部Ｂ６４は、図１の補償コスト期待値管理部１３に相当する。
コスト期待値計算部Ｂ６３は、複数の方法で実現することが可能である。例えば、Saga方式、Top Down打ち消し再試行方式、その他の方式の各々で補償トランザクション群を実施した場合の分散トランザクション処理をペトリネットによる記述でモデル化することができる。そして、各々のペトリネット記述群を同じ処理系で各々シミュレーション動作させ、終了するまでの時間を比較することで、Saga方式、Top Down打ち消し再試行方式、その他の方式等の各々の効率を求めることもできる。
これに対して、図１３〜１５に定義するAction Treeを用いる方法も可能である。
図１３は、計算機ネットワークの一例を示す。図１４及び図１５は、Action Tree生成部Ｂ６６が内部に持つAction Treeの構成を示す。図１４は、図１３に示す計算機ネットワークにおいてサービス末端ノード間で並列化が可能な場合のAction Treeの構成であり、図１５は、サービス末端ノード間で直列化した場合のAction Treeの構成を示す。Action Treeとは、ある分散トランザクション処理となる合成ワークフロー定義が取りうる全ての挙動を履歴を意味する木構造で表現したものである。
図１３の例では、サービスクライアントノードＡ１が直接サービス末端ノードＡ８とサービス末端ノードＡ９とに対して、ロングライブトランザクション方式による分散トランザクション処理を行う場合を想定している。
この場合、サービスクライアントノードＡ１が、ロングライブトランザクション方式による分散トランザクション処理を開始する場合、サービス末端ノードＡ８に更新要求メッセージＡ１７１（［更新要求-1(+)］）を送信する。
分散トランザクション処理が並列に処理可能である場合は、サービス末端ノードＡ８からの更新応答メッセージＡ１７２（［更新応答-1(+:True/False)］を受信する前に、続けてサービス末端ノードＡ９に更新要求メッセージＡ１７３（［更新要求-n(+)］）を送信する。
サービス末端ノードＡ８では、更新要求メッセージＡ１７１を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。更新不可能である場合、又は更新して失敗した場合は、その旨回答する。この場合、ロングライブトランザクション方式を採用しているため、２フェースコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新の結果を意味する更新応答メッセージＡ１７２が返信される。
分散トランザクション処理が直列に処理される場合は、サービスクライアントノードＡ１が更新応答メッセージＡ１７２を受信すると、サービス末端ノードＡ９に更新要求メッセージＡ１７３（［更新要求-n(+)］）を送信する。
サービス末端ノードＡ９では、更新要求メッセージＡ１７３を受信すると、内部に保持するデータベース等のデータについて更新可能であるか否かを確認する。更新可能である場合は、更新処理を実施する。更新不可能である場合、又は更新して失敗した場合は、その旨回答する。この場合、ロングライブトランザクション方式を採用しているため、２フェーズコミットメント方式のような投票相、決定相のメッセージ交換手順は無く、更新の結果を意味する更新応答メッセージＡ１７４（［更新応答-n(+:True/False］）が返信される。
もし、ロングライブトランザクション方式による分散トランザクション処理で不具合となった場合は、補償処理が実施される。その場合は、更新要求メッセージＡ１７１の代わりに補償要求メッセージＡ１７５（［補償要求-1(-)］）が送受信される。
さらに、更新応答メッセージＡ１７２の代わりに、補償応答メッセージＡ１７６（［補償応答-1(-:True/False)］）が送受信される。
さらに、更新要求メッセージＡ１７３の代わりに、補償要求メッセージＡ１７７（［補償要求-n(-)］）が送受信される。
さらに、更新応答メッセージＡ１７４の代わりに、補償応答メッセージＡ１７８（［補償応答-n(-:True/False)］）が送受信される。
Action Treeは、始点のシンボルでノードであるＡ１８０と、末端のノードを意味する終端のシンボルでノードであるＡ１８２とを、Actionとして定義されノード間を連結するアークであるＡ１８１を複数連結して表現される。なお、ノードＡ１８０とノードＡ１８２との間には任意のノードシンボルを配置可能である。またAction Treeの任意の一部に相当するAction Sub Treeを省略した三角のシンボルＡ１８３で代替表現することも可能である。
ここで、Action Tree上の任意のノードは、サービスクライアントノードＡ１、サービス末端ノードＡ８、Ａ９等の構成要素のノード全体が取る状態を意味し、アークＡ１８１は発生するイベントを意味する。この場合、各メッセージの送受信を意味するAction Treeの定義は、サービス末端ノードＡ８、Ａ９等の構成要素のノードのうち、注目するノードに応じて変化する。特に並列化する場合は、割り込み処理が存在するため、異なる場合も存在する。ここでは、受信側を主体とした場合を示しているが、他の論点でもAction Treeの作成は可能である。
図１４は、分散トランザクション処理が並列に処理される場合のAction Treeに相当する。これに対して、図１５は、分散トランザクション処理が直列に処理される場合のAction Treeに相当する。特に、図１５では、メッセージの動きに対応してアークを定義する。
サービス末端ノードＡ８に更新要求メッセージＡ１７１を送信する処理は、ノードＡ１８０から出るアークＡ１９１に相当する。
サービス末端ノードＡ８では、更新要求メッセージＡ１７１を受信後、更新の結果を意味する更新応答メッセージＡ１７２を返信する。更新可能である場合は更新応答メッセージＡ１７２（［更新応答-1(+:True)］）となり、アークＡ１９２に相当する。更新不可能である場合は、更新応答メッセージＡ１７２（［更新応答-1(+:False)］）となり、アークＡ１９３に相当する。
サービス末端ノードＡ９に更新要求メッセージＡ１７３を送信する処理は、アークＡ１９４に相当する。
サービス末端ノードＡ９では、更新要求メッセージＡ１７３を受信後、更新の結果を意味する更新応答メッセージＡ１７４を返信する。更新可能である場合は、更新応答メッセージＡ１７４（［更新応答-n(+:True)］となり、アークＡ１９５に相当する。更新不可能である場合は、更新応答メッセージＡ１７４（［更新応答-n(+:False)］となり、アークＡ１９６に相当する。
ロングライブトランザクション方式による分散トランザクション処理で不具合となった場合は、補償処理が実施される。その場合は、補償要求メッセージＡ１７５が送受信される。これはアークＡ１９７に相当する。
さらに応答として、補償応答メッセージＡ１７６が送受信される。補償処理が成功した場合は補償応答メッセージＡ１７６（［補償応答-1(-:True)］）が送受信され、アークＡ１９８に相当する。これに対して補償処理が失敗した場合は補償応答メッセージＡ１７６（［補償応答-1(-:False)］）が送受信され、アークＡ１９９に相当する。
Action Treeでは、終端のシンボルでノードであるＡ１８２は複数存在し、その各々にケース名とともに二つのパラメータを持つアノテーションラベルを一意に定義できる。例えば、Case:P11のノードでは、アノテーションラベルＡ１８４が定義される。同様に、アノテーションラベル群Ａ１８５、Ａ１８６も定義される。二つのパラメータを持つアノテーションラベルはAction Tree全体に亘り、定義することも可能である。例えば、図１５におけるアノテーションラベルＡ１８７が相当する。この場合、二つのパラメータを組で定義する。
二つのパラメータのうち、一つ目のパラメータはAction Treeの枝長に相当するAction Depthであり、下記式（１）で定義される変数で表現できる。
Figure 2010146103
ここで、変数ｉは、ケース名に一意に対応する累積ケース番号に相当する。このAction Depthは、分散トランザクション処理を並列又は直列に実施するかに応じて変化する。さらに、補償処理の方式をSaga方式又はTop Down打ち消し再試行方式にするかに応じて変化する。そこで、Saga方式、Top Down打ち消し再試行方式の各方式を一般化して方式（Ｘ）と表記すると、方式（Ｘ）によるAction Depthを下記式（２）で定義される変数で表現できる。
Figure 2010146103
これに対して二つ目のパラメータは、その終端が発生する確率である。分散トランザクション処理の一部であるサービス末端ノードＡ８に対するトランザクション失敗の確率を確率変数ｆ1、サービス末端ノードＡ９に対するトランザクション失敗の確率を確率変数ｆn、さらにサービス末端ノードＡ８に対する補償処理のトランザクション失敗の確率を確率変数ｇ1、サービス末端ノードＡ９に対する補償処理のトランザクション失敗の確率を確率変数ｇnとすると、その終端が発生する確率は、下記式（３）で表現される関数で定義可能である。ここで、変数ｉは、ケース名に一意に対応する累積ケース番号に相当する。
Figure 2010146103
 式（３）は、分散トランザクション処理を並列、又は直列に実施するかに応じて式の内容が変化する。さらに、サービス末端ノードＡ８、Ａ９のサービス品質の状況に応じても変化する。特に、サービス末端ノードＡ８、Ａ９のサービス品質が時間に応じて変動する場合、式（３）の値へ経年変化を持つこととなる。さらに、分散トランザクションに参加するサービス末端ノード数の増加に応じて確率変数ｆ、ｇの種類は増加する。
ここで、方式（Ｘ）による発生確率は下記式（４）で表現される関数で定義する。
Figure 2010146103
式（２）及び式（４）を元にすると、方式（Ｘ）により定義される処理効率を下記式（５）にて定義することが可能となる。
Figure 2010146103
これは、Action Depthの期待値で分散トランザクション処理を収束させるまでに発生する手続長の期待値に相当する。そこで、複数の方式に関する式（５）を事前に求めておけば、どの方式が最も効率的に分散トランザクション処理を実施でき、かつ更新異常時にどの方法が有効的に対策をとることができるかを評価することが可能となる。ここで、方式（１）は、例えば「直列化された分散トランザクション処理をSaga方式で補償する」のように定義される。
図１６は、図１２にて定義されるワークフロー処理系が持つワークフロー定義群を一つの表現形式で示す。具体的には、WS-BPELとXPDLとの記述例を示す。標準化されていないワークフロー定義や他の記述でも通常はほぼ等価な情報項目を持つことが一般的である。
図１６でプロセス定義Ｂ２００は、一つのWS-BPELのインスタンスとして記載される。プロセス定義Ｂ２００は、定義部Ｂ２０２、アクティビティ部Ｂ２０３、Ｂ２０４、Ｂ２０５等を含む。
アクティビティ部は、該当するメッセージを受信した場合の挙動を定義するアクティビティ部Ｂ２０３、実際の業務ロジックに相当する挙動を定義するアクティビティ部Ｂ２０４、該当するメッセージを往信する場合の挙動を定義するアクティビティ部Ｂ２０５に分類される。
これに対して、具体的なサービス定義Ｂ２０１は、一つのWSDLのインスタンスとして記載される。サービス定義Ｂ２０１は、プロセス定義Ｂ２００と直接関係するものと独立に記載されるものとの２種類が存在する。
一つのサービス定義Ｂ２０１は、サービスを呼び出す場合のメッセージ形式、サービスを呼び出したことで発生する往信メッセージの形式を定義するメッセージ定義部Ｂ２０６、メッセージ定義部Ｂ２０６を使い実際のインタフェースを定義するポート定義部Ｂ２０７、ポート定義部Ｂ２０７を実際のトランスポートに対応付けるバインディング部Ｂ２０８、バインディング部Ｂ２０８等を使いサービスとして定義するサービス定義部Ｂ２０９を含んで構成される。
メッセージを受信した場合の挙動を定義するアクティビティ部Ｂ２０３で、任意のサービスを特定する場合、サービスに相当するサービス定義Ｂ２０１のポート定義部Ｂ２０７を参照する。同様に、メッセージを往信する場合の挙動を定義するアクティビティ部Ｂ２０５や、実際の業務ロジックに相当する挙動を定義するアクティビティ部Ｂ２０４で任意のサービスを特定する場合、間接的にサービスに相当するサービス定義Ｂ２０１のポート定義部Ｂ２０７を参照する。
図１６のサービス定義部Ｂ２０１、プロセス定義Ｂ２００は、通常計算機が可読の表現で記載され、意味的な情報を直接含むことは少ない。
図１７は、図１３のデプロイ段階で実施する処理手順の一環として、メタデータ管理部、結合処理部、Action Tree生成部が、Action Treeを生成する際の処理概要を示す。大きくは四つの工程から構成される。第１の工程では、分散配置された複数のワークフロー処理系に保持されているワークフローに関連した全てのプロセス定義のメタデータ、及び全てのサービス定義のメタデータを収集した後、統合されたワークフロー定義である合成ワークフロー定義を構築する。これは上記の統合処理部Ｂ５５によって実行される。
第２の工程では、合成ワークフロー定義に基づき、Action Treeを構築するためのノードの呼び出し関係の特定、明確化を行う。これは上記のAction Tree生成部Ｂ６６によって実行される。第３の工程では、図１３〜１５での説明に従い、特定されたノードの呼び出し関係を基に、Action Treeを構築する。これも上記のAction Tree生成部Ｂ６６によって実行される。この第２、第３の工程では、さらに二つのサブ工程に分解できる。一つ目は正常系のAction Treeを構築するサブ工程であり、二つ目は正常系のAction Treeを元に補償処理を含んだ複数のAction Treeを構築するサブ工程となる。
第４の工程では、複数のAction Treeを元に確率関数を付与し、評価のために利用できるように記述を強化した後、メタデータ管理部Ｂ５６に登録する工程である。これも上記のAction Tree生成部Ｂ６６によって実行される。
第１の工程を実行するため、統合処理部Ｂ５５は、プロセス定義のメタデータや、サービス定義のメタデータを収集する。プロセス定義のメタデータは、具体的にはWS-BPELで記載されており、例えばプロセス名が「１Ｘ」で定義されるプロセス定義のメタデータＢ２１０、プロセス名が「２Ｘ」で定義されるプロセス定義のメタデータＢ２１２、プロセス名が「３Ｘ」で定義されるプロセス定義のメタデータＢ２１４等である。
これに対してサービス定義のメタデータは、具体的にはWSDLで記述されており、例えばサービス名が「１Ｘ」で定義されるサービス定義のメタデータＢ２１１、サービス名が「２Ｘ」で定義されるサービス定義のメタデータＢ２１３、サービス名が「３Ｘ」で定義されるサービス定義のメタデータＢ２１５、サービス名が「１Ｙ」で定義されるサービス定義のメタデータＢ２１９、サービス名が「２Ｙ」で定義されるサービス定義のメタデータＢ２１８、サービス名が「３Ｙ」で定義されるサービス定義のメタデータＢ２１７等である。
ここで、メタデータ間の関係を簡単に記すと以下のようになる。サービス定義のメタデータＢ２１１は、プロセス定義のメタデータＢ２１０と関連して定義され、サービスが呼び出されると、プロセス定義のメタデータＢ２１０に記載されたワークフロー、プロセスが起動する。
これに対して、サービス定義のメタデータＢ２１３は、プロセス定義のメタデータＢ２１２と関連して定義され、サービスが呼び出されると、プロセス定義のメタデータＢ２１２に記載されたワークフロー、プロセスが起動する。
さらに、サービス定義のメタデータＢ２１５は、プロセス定義のメタデータＢ２１４と関連して定義され、サービスが呼び出されると、プロセス定義のメタデータＢ２１４に記載されたワークフロー、プロセスが起動する。
さらに、ここではサービス定義のメタデータＢ２１３は、プロセス定義のメタデータＢ２１０から呼び出される。さらに、サービス定義のメタデータＢ２１５は、プロセス定義のメタデータＢ２１２から呼び出される。また、サービス定義のメタデータＢ２１９、Ｂ２１８は、プロセス定義のメタデータＢ２１４から呼び出されるという関係を持つ。
図１７では、図１６にて定義されたアクティビティ部のうち、該当するメッセージを受信した場合の挙動を定義するアクティビティ部Ｂ２０３をシンボル「Ｒｖ」の修飾子、実際のロジックに相当する挙動を定義するアクティビティ部Ｂ２０４をシンボル「ｌ」の修飾子、該当するメッセージを往信する場合の挙動を定義するアクティビティ部Ｂ２０５をシンボル「Ｒｐ」の修飾子を付けて表現する。
例えば、プロセス名が「１Ｘ」で定義されるプロセス定義のメタデータＢ２１０内の、受信した場合の挙動を定義するアクティビティ部は、シンボル「１Ｒｖ」で表現される。また、実際の業務ロジックに相当する挙動を定義するアクティビティ部は、シンボル「１ｌ１」で表現される。ここで、業務ロジックに相当する挙動を定義するアクティビティ部は複数定義しうるので、シンボル「１ｌ１」、「１ｌ２」と複数出現しうる。また、該当するメッセージを往信する場合の挙動を定義するアクティビティ部は、シンボル「１Ｒｐ」で表現する。
統合処理部Ｂ５５は、実際に第１の工程を実施するため、メタデータ管理部Ｂ５６に登録されているプロセス定義のメタデータや、サービス定義のメタデータを取り出す。その際、サービス定義のメタデータＢ２１１とプロセス定義のメタデータＢ２１０は、転送形式データＢ２２０として統合処理部Ｂ５５に渡される。
また、サービス定義のメタデータＢ２１３とプロセス定義のメタデータＢ２１２とは、転送形式データＢ２２１として統合処理部Ｂ５５に渡される。また、サービス定義のメタデータＢ２１５とプロセス定義飲めたデータＢ２１４は、転送形式データＢ２２２として統合処理部Ｂ５５に渡される。最後に、サービス定義のメタデータＢ２１７、Ｂ２１８、Ｂ２１９は、転送形式データＢ２２３として統合処理部Ｂ５５に渡される。
統合処理部Ｂ５５は、転送形式データＢ２２０、Ｂ２２１、Ｂ２２２、Ｂ２２３として入手すると、それらを統合処理部Ｂ５５の持つ内部メモリに空間Ｂ２２４に展開し、合成ワークフロー定義として展開する。その後、メモリ空間Ｂ２２４上でサービス中間ノード、サービス末端ノードを特定していく。
サービス末端ノードは、他サービスの呼び出しが無いサービス定義が相当する。サービス中間ノードは、他サービスの呼び出し関係を持つサービス定義、さらにはサービス定義に関連したプロセス定義が相当する。ここでプロセス定義Ｂ２２５、Ｂ２２６、Ｂ２２７、Ｂ２２８は、他サービスの呼び出し関係を持つサービス定義と関連しているため、サービス中間ノードとして特定される。
これに対して、プロセス定義Ｂ２２７、Ｂ２２８から呼ばれるサービス名が「１Ｙ」で定義されるサービス定義、及びサービス名が「２Ｙ」で定義されるサービス定義は、サービス末端ノードと特定される。
その後、統合処理部Ｂ５５は、内部メモリ空間Ｂ２２４上に展開された合成ワークフロー定義を保存するため、転送形式データＢ２５３に変換し送付の上でメタデータ管理部Ｂ５６上の合成ワークフロー定義Ｂ２４４として命名の上で書き込み、保存する。
続けて、第２の工程を実施するため、統合処理部Ｂ５５は、Action Tree生成部Ｂ６６を起動する。Action Tree生成部Ｂ６６が起動すると、統合処理部Ｂ５５の内部メモリ空間Ｂ２２４に保存される全てのプロセス定義と、全てのサービス定義とが、Action Tree生成部Ｂ６６内の内部メモリ空間Ｂ２２９に引き渡される。
例えば、プロセス定義Ｂ２２５は、転送形式データＢ２４８として、Action Tree生成部Ｂ６６に引き渡された後、内部メモリ空間Ｂ２２９上にサービス中間ノード１Ｘ記述定義Ｂ２３１として展開される。
プロセス定義Ｂ２２６は、転送形式データＢ２４９として、Action Tree生成部Ｂ６６に引き渡された後、内部メモリ空間Ｂ２２９上にサービス中間ノード２Ｘ記述定義Ｂ２３２として展開される。
プロセス定義Ｂ２２７は、転送形式データＢ２５０として、Action Tree生成部Ｂ６６に引き渡された後、内部メモリ空間Ｂ２２９上にサービス中間ノード３Ｘ記述定義Ｂ２３３として展開される。その後、分岐で表現される部分についても取り込まれる。具体的には、プロセス定義Ｂ２２８も、転送形式データＢ２５０として取り込まれ、Action Tree生成部Ｂ６６に引き渡された後、内部メモリ空間Ｂ２２９上にサービス中間ノード３Ｘ記述定義Ｂ２３３の一部として取り込まれる。
プロセス定義Ｂ２２８から呼ばれるサービス名が「１Ｙ」で定義されるサービス定義は、転送形式データＢ２５１としてAction Tree生成部Ｂ６６に引き渡された後、内部メモリ空間Ｂ２２９上にサービス末端ノード１Ｙ記述定義Ｂ２３４として展開される。
最後に、プロセス定義Ｂ２２７から呼ばれるサービス名が「２Ｙ」で定義されるサービス定義は、転送形式データＢ２５２としてAction Tree生成部Ｂ６６に引き渡された後、内部メモリ空間Ｂ２２９上にサービス末端ノード２Ｙ記述定義Ｂ２３５として展開される。
Action Tree生成部Ｂ６６は、記述定義を展開の後、サービス中間ノード１Ｘ記述定義Ｂ２３１、サービス中間ノード２Ｘ記述定義Ｂ２３２、サービス中間ノード３Ｘ記述定義Ｂ２３３から開始点となるものを特定する。この場合、サービス中間ノード１Ｘ記述定義Ｂ２３１がこれに相当する。その後、サービス中間ノード１Ｘ記述定義Ｂ２３１が参照するサービス定義のメタデータＢ２１１を基に呼び出しインタフェースを特定した後、サービスの起動側であるサービスクライアントノードの記述定義Ｂ２３０を追加する。
その後、Action Tree生成部Ｂ６６は、内部メモリ空間Ｂ２２９上の全ての記述定義を含んだ記述定義を完成させると、Action Treeを構成するためのノードの呼び出し関係の特定を行い、第２の工程を終了する。
続けてAction Tree生成部Ｂ６６は、内部メモリ空間Ｂ２２９上で第３の工程を実施する。これは、Action Tree生成部Ｂ６６内部に定義される補償処理Action Tree生成部Ｂ２６０によって実施される。補償処理Action Tree生成部Ｂ２６０は、補償処理の方式数に応じて、正常系Action TreeＢ２３６を基に、図１３〜１５で示した方法で補償処理を含んだ複数のAction Treeを構築する。
補償処理Action Tree生成部２６０は、例えば、Saga方式の場合、例えば図３の正常処理定義と図６の定義との差分を行う処理を実施し、補償処理で必要となるメッセージ群の特定を図る。そして、補償処理Action Tree生成部Ｂ２６０は、特定されたメッセージ群を基に、正常系Action TreeＢ２３６にAction Sub Treeを追加することで、Saga方式Action TreeＢ２３８を生成する。
補償処理Action Tree生成部Ｂ２６０は、例えばTop Down打ち消し再試行方式の場合、例えば図３の正常処理定義と図９の定義との差分を行う処理を実施し、補償処理で必要となるメッセージ群の特定を図る。そして、補償処理Action Tree生成部Ｂ２６０は、特定されたメッセージ群を基に、正常系Action TreeＢ２３６にAction Sub Treeを追加することで、Top Down打ち消し方式Action TreeＢ２３９を生成する。
その他の方式が存在する場合は、同様の手順に基づき、補償処理Action Tree生成部Ｂ２６０は、その他方式Action TreeＢ２３７を生成する。以上により、第３の工程を終了する。
その後、Action Tree生成部Ｂ２６０は、第４の工程を実施するため、Action Tree生成部Ｂ６６内部に定義される確率関数記述付与部Ｂ２４０を起動する。確率関数記述付与部Ｂ２４０は、補償処理Action Tree生成部Ｂ２６０の定義するAction Treeの総数分、Action Tree記述を定義する。例えば、Saga方式Action TreeＢ２３８が存在する場合、図１３〜１５に示されるAction Tree内部に定義される全ての終端のノードに対して上記式（１）、式（４）の拡張で定義されるパラメータを算出してアノテーションラベルを定義し、これを含めてAction Tree記述が作成される。
その後、全ての終端のノードに対してアノテーションラベルを付与した後、上記式（５）で定義される計算式相当の記述を生成する。式（５）で確率変数として定義されている部分は、適当なリテラル表現として記述され、後に具体的なパラメータに対してバインドされる。このバインド処理は、Action Tree生成部Ｂ６６では実施せず、コスト期待値計算部Ｂ６３の起動時に実施する。
以上の結果、確率関数記述付与部Ｂ２４０は、Saga方式Action TreeＢ２３８からSaga方式Action tree記述Ｂ２４２を生成する。同様にTop Down打ち消し再試行方式Action TreeＢ２３９からTop Down打ち消し方式Action Tree記述Ｂ２４３を生成する。同様に、その他方式Action TreeＢ２３７からその他方式Action Tree記述Ｂ２４１を生成する。
その後、Action Tree生成部Ｂ６６は、メタデータ管理部Ｂ５６にAction Tree記述を登録することで、第４の工程を終了する。具体的には、Saga方式Action tree記述Ｂ２４２を転送、コピーするコマンドを実施し、転送形式データＢ２５５を生成の後、メタデータ管理部Ｂ５６にコピーであるSaga方式Action tree記述Ｂ２４６を生成させる。メタデータ管理部Ｂ５６では先に登録している合成ワークフロー定義Ｂ２４４と管理関係Ｂ２５８とを生成維持することで、Saga方式Action tree記述Ｂ２４６を管理する。
同様に、具体的には、Top Down打ち消し再試行方式Action tree記述Ｂ２４３を転送、コピーするコマンドを実施し、転送形式データＢ２５６を生成の後、メタデータ管理部Ｂ５６にコピーであるTop Down打ち消し再試行方式Action tree記述Ｂ２４７を生成させる。メタデータ管理部Ｂ５６では先に登録している合成ワークフロー定義Ｂ２４４と管理関係Ｂ２５９とを生成維持することで、Top Down打ち消し再試行方式Action tree記述Ｂ２４７を管理する。
同様に、その他方式Action Tree記述Ｂ２４５を生成させる。メタデータ管理部Ｂ５６では、先に登録している合成ワークフロー定義Ｂ２４４と管理関係Ｂ２５７とを生成維持することで、その他方式Action tree記述Ｂ２４５を管理する。
合意サービス水準を考慮して補償トランザクション方法を選択する装置の動作を、図１３及び図１９、２２〜２４を用いて説明する。また、図２０における一部の手順を図２１、２２、２４、２５に示す。
図１３は、ロングライブトランザクション方式による分散トランザクション処理の正常終了及びSaga方式の補償トランザクション群の処理、及びTop Down打ち消し再試行方式の補償トランザクション群を合意サービス水準を考慮して選択的に実施する装置を機能させるデプロイ段階で実施する処理手順を構成とともに示す。
開発者・管理者が開発環境Ｂ１４を用いて、ワークフローＢ１６等の図１２を構成する環境の構成要素を開発すると、ＳＯＡリポジトリＢ１２に全て登録される。ＳＯＡリポジトリＢ１２には、複数のサービス処理系、複数のワークフロー処理系に展開する一切のプログラム、定義情報が登録、維持、管理される。
ここで、サービス処理系、複数のワークフロー処理系に展開する一切のプログラム、定義情報を実際の実行環境であるサービス処理系Ｂ６、Ｂ７、Ｂ８、Ｂ９、Ｂ１０及びワークフロー処理系Ｂ４、Ｂ５に展開する場合は、デプロイヤＢ１３を利用することとなる。
デプロイヤＢ１３は、ＳＯＡリポジトリＢ１２から更新系サービスＢ５１に関する定義Ｂ１００を取り出した後、定義Ｂ１００を更新系サービスエントリＢ１０３として、サービス処理系Ｂ１０へ転送し、更新系サービスＢ５１として登録する。
さらに、デプロイヤＢ１３は、ＳＯＡリポジトリＢ１２からワークフローＢ１７に関する定義Ｂ１０１を取り出した後、定義Ｂ１０１をワークフローエントリＢ１０４としてワークフロー処理系Ｂ５に転送し、ワークフローＢ１７として登録する、他の参照系サービスＢ５０についても同様である。
デプロイヤＢ１３は、ＳＯＡリポジトリＢ１２から補償ハンドラＢ２７に関する定義Ｂ１０２を取り出す場合は、異なる手順をとる。この場合、補償ハンドラＢ２７に関する定義Ｂ１０２に記載されている挙動が正規化されていない場合が想定される。そこで、デプロイヤＢ１３は、補償ハンドララッパテンプレートＢ８０を用いて、補償処理の挙動を正規化することを試みる。
具体的には、最初に補償ハンドララッパテンプレートＢ８０の定義情報Ｂ８１を読み込む。続けて、デプロイヤＢ１３は、先に取り出した補償ハンドラＢ２７に関する定義Ｂ１０２の内容を評価し、その内容が予め指定している挙動と等価である場合は、定義情報Ｂ８１の一部に補償ハンドラＢ２７に関する定義Ｂ１０２を嵌め込み、補償ハンドラＢ２７に関する定義Ｂ１０２を取り込んだ補償ハンドララッパのエントリＢ１０５を生成する。予め指定している挙動と等価でない場合は、定義情報Ｂ８１で既に指定されているものを採用し、補償ハンドラＢ２７に関する定義Ｂ１０２を一部参照した補償ハンドララッパのエントリＢ１０５を生成する。
以上の評価において等価か否かの判断は、例えば補償ハンドラＢ２７に関する定義Ｂ１０２に付与された形式化された仕様記述に関するアノテーションを用いれば可能である。さらに、アスペクト技術を応用することで実現することも可能である。
その後、デプロイヤＢ１３は、補償ハンドラＢ２７に関する定義Ｂ１０２と関連した補償ハンドララッパのエントリＢ１０５をワークフロー処理系Ｂ５に転送する。その後、補償ハンドラＢ２７と補償ハンドララッパＢ２３とが登録される。
サービス処理系、複数のワークフロー処理系で利用され、WS-BPEL等の言語により記述されるプロセス定義のメタデータ、WSDLで記述されるサービス定義のメタデータは、トランザクション・SLAモニタ管理部Ｂ１１内のメタデータ管理部Ｂ５６にも登録される必要がある。
メタデータ管理部Ｂ５６への登録を実施する場合は、デプロイヤＢ１５を利用する。
デプロイヤＢ１５は、ＳＯＡリポジトリＢ１２からWS-BPEL等の言語により記述されるプロセス定義の全メタデータＢ１０６を読み出し、WSDLで記述されるサービス定義の全メタデータＢ１０７を読み出す。さらに、全てのサービス群、ワークフロー群、合成ワークフロー群のサービス条件・品質条件について定義し、記載している全データＢ８２（サービス条件・品質条件定義データ）を読み出す。
その後、デプロイヤＢ１５は、プロセス定義の全メタデータＢ１０６及びサービス定義の全メタデータＢ１０７を登録エントリＢ１０８として、メタデータ管理部Ｂ５６に登録する。
さらにデプロイヤＢ１５は、全てのサービス群、ワークフロー群、合成ワークフロー群のサービス条件・品質条件について定義し、記載している全データＢ８２を登録エントリＢ１０９としてSLA管理部Ｂ５９に登録する。
統合管理部Ｂ５５は、図１７の説明で定義された第１の工程であるプロセス定義の全メタデータＢ１１０及びサービス定義の全メタデータＢ１１１を収集する。具体的には、全メタデータＢ１１０には、プロセス定義のメタデータＢ２１０、Ｂ２１２、Ｂ２１４等が含まれる。これに対して、サービス定義の全メタデータＢ１１１には、サービス定義のメタデータＢ２１１、Ｂ２１３、Ｂ２１５、Ｂ２１７、Ｂ２１８、Ｂ２１９等が含まれる。
この結果、合成ワークフロー定義Ｂ２４４相当のデータＢ１１２が作成される。その後、図１７のようにメタデータ管理部に合成ワークフロー定義Ｂ２４４として登録される。
図１７を用いて説明したように、Action Tree生成部Ｂ６６は、統合処理部Ｂ５５からデータの入力を受ける。具体的には、転送形式データ群Ｂ１１３であり、これは転送形式データＢ２４８、Ｂ２４９、Ｂ２５０、Ｂ２５１、Ｂ２５２を含んで構成される。
図１７を用いて説明したように、Action Tree生成部Ｂ６６は、メタデータ管理部Ｂ５６へのデータの出力を行う。具体的には、転送形式データＢ１１４であり、これは転送形式データＢ２５４、Ｂ２５５、Ｂ２５６を含んで構成される。
図１９に、ロングライブトランザクション方式による分散トランザクション処理の正常処理に該当する処理を、図１２に示す装置にて実施した場合の処理手順を示す。
分散トランザクション処理を含む合成ワークフローを起動するには、例えば、サービスクライアントＢ２から更新要求メッセージＢ３００が送信され、ワークフロー処理系Ｂ４により受信される。この結果、ワークフロー処理系Ｂ４に含まれるワークフローＢ１６が起動する。
ワークフローＢ１６が起動すると、その内部に持つプロセスの定義Ｂ６７に従いアクティビティを順次呼び出していく。まず、起点であり、後続のアクティビティ（アクティティＢ７２、Ｂ７４）を呼び出すアクティビティＢ７１が呼び出される。
その後、アクティビティＢ７１はプロセスの定義Ｂ６７に従い、直列化又は並列化して後続のアクティビティＢ７２、Ｂ７４を呼び出していく。アクティビティＢ７４が立ち上がると、サービス処理系Ｂ７に更新要求メッセージＢ３０１を送信する。これは、図３における更新要求メッセージＡ１０１に相当する。
サービス処理系Ｂ７は、更新要求メッセージＢ３０１を受信すると、更新系サービスＢ３６を起動する、更新系サービスＢ３６は、操作ログＢ３９に更新前イメージ及び更新要求メッセージＢ３０１内の値に基づく操作内容Ｂ３５０を記録する。その後、更新要求メッセージＢ３０１内の値を基に、内部で管理するDataＢ３８を値Ｂ３５１で更新する。その後、サービス処理系Ｂ７は、ワークフロー処理系Ｂ４に更新応答メッセージＢ３０２を返信する。これは、図３における更新応答メッセージＡ１０２に相当する。
ワークフロー処理系Ｂ４は、更新応答メッセージＢ３０２を受信すると、その内部の操作ログＢ２８にメッセージ送信イベントＢ３０７、正常応答メッセージ受信イベントＢ３０８を書き込む。その後、後続のアクティビティに処理を移す。
続けてアクティビティＢ７２が立ち上がると、サービス処理系Ｂ８に参照要求メッセージＢ３０３を送信する。
サービス処理系Ｂ８は、参照要求メッセージＢ３０３を受信すると、参照系サービスＢ４０を起動する。参照系サービスＢ４０は、参照要求メッセージＢ３０３内の問い合わせ条件を基に、内部で管理するDataＢ４３を検索するとともに、その検索結果Ｂ３５４を取り出す。その後、参照系サービスＢ４０は、参照応答メッセージＢ３０４を返信する。
ワークフロー処理系Ｂ４は、参照応答メッセージＢ３０４を受信すると、その内部の操作ログＢ２８にメッセージ送信イベントＢ３０９、正常応答メッセージ受信イベントＢ３１０を書き込む。その後、後続のアクティビティに処理を移す。
アクティビティＢ７２が参照応答メッセージＢ３０４を受信すると、ワークフローＢ６７は、処理を進め、アクティビティＢ７３を起動する。アクティビティＢ７３が立ち上がると、サービス処理系Ｂ８に更新要求メッセージＢ３０５を送信する。これは、図３における更新要求メッセージＡ１０３に相当する。
サービス処理系Ｂ８は、更新要求メッセージＢ３０５を受信すると、更新系サービスＢ４１を起動する。更新系サービスＢ４１は、操作ログＢ４４に更新前イメージ及び更新要求メッセージＢ３０５内の値に基づく操作内容Ｂ３５２を記録する。その後、更新要求メッセージＢ３０５内の値を基に、内部で管理するDataＢ４３を値Ｂ３５３で更新する。その後、サービス処理系Ｂ８は、ワークフロー処理系Ｂ４に更新応答メッセージＢ３０６を送信する。これは、図３における更新応答メッセージＡ１２５に相当する。
ワークフロー処理系Ｂ４は、更新応答メッセージＢ３０６を受信すると、その内部の操作ログＢ２８にメッセージ送信イベントＢ３１１、正常応答メッセージ受信イベントＢ３１２を書き込む。その後、後続のアクティビティに処理を移す。
その後、ワークフロー処理系Ｂ４は、操作ログＢ２８に書き込んだメッセージ送信イベントＢ３０７相当のイベントメッセージＢ３１３、正常応答メッセージ受信イベントＢ３０８相当のイベントメッセージＢ３１４、メッセージ送信イベントＢ３０９相当のイベントメッセージＢ３１５、正常応答メッセージ受信イベントＢ３１０相当のイベントメッセージＢ３１６、メッセージ送信イベントＢ３１１相当のイベントメッセージＢ３１７、正常応答メッセージ受信イベントＢ３１２相当のイベントメッセージＢ３１８をトランザクション・SLAモニタ管理部Ｂ１１内のログ受信部Ｂ５７に送信する。
イベントメッセージのトランザクション・SLAモニタ管理部Ｂ１１内のログ受信部Ｂ５７への送付は、サービス処理系でも実施される。サービス処理系Ｂ７は、更新要求メッセージＢ３０１の受信イベント相当のイベントメッセージＢ３２３、及び更新応答メッセージＢ３０２の送信イベント相当のイベントメッセージＢ３２４をログ受信部Ｂ５７へ送付する。
同様に、サービス処理系Ｂ８は、参照要求メッセージＢ３０３の受信イベント相当のイベントメッセージＢ３１９、参照応答メッセージＢ３０４の送信イベント相当のイベントメッセージＢ３２０、更新要求メッセージＢ３０５の受信イベント相当のイベントメッセージＢ３２１、更新応答メッセージＢ３０６の送信イベント相当のイベントメッセージＢ３２２をログ受信部Ｂ５７へ送付する。
ワークフロー処理系Ｂ４は、一連のアクティビティを正常に終了すると、呼び出し元のサービスクライアントＢ２に更新応答メッセージＢ３６１を返信する。その後、ワークフロー処理系Ｂ４は、操作ログＢ２８に書き込むとともに、更新応答メッセージＢ３６１相当のイベントメッセージＢ３６０をログ受信部Ｂ５７に返信する。
ログ受信部Ｂ５７は、一連のイベントメッセージＢ３１３、Ｂ３１４、Ｂ３１５、Ｂ３１６、Ｂ３１７、Ｂ３１８、Ｂ３１９、Ｂ３２０、Ｂ３２１、Ｂ３２２、Ｂ３２３、Ｂ３２４、Ｂ３６０を受信するたびにイベントインスタンスデータ管理部Ｂ５８内で管理される関連イベントインスタンスデータ群Ｂ３５６を検索の後、取り出すとともに、メタデータ管理部Ｂ５６内に管理されている合成ワークフロー定義の一部データＢ３５５、プロセス定義のメタデータの一部データＢ３２５、サービス定義のメタデータの一部データＢ３２６も検索、参照して、イベントメッセージを対応付け、新たなイベントインスタンスデータＢ３２７として登録する。
SLA計算部Ｂ６０は一定時間間隔で起動し、イベントインスタンスデータ管理部Ｂ５８内で管理されるイベントインスタンスデータ群Ｂ３３１を検索する。その後、メタデータ管理部Ｂ５６内に管理されている合成ワークフロー定義の一部データＢ３２８、プロセス定義のメタデータの一部データＢ３２９、サービス定義のメタデータの一部データＢ３３０を検索、参照して、合成ワークフロー定義ごと、個々ワークフローの定義するプロセスごと、個々サービスごとの品質水準を意味するSLAを計算する。一定時間間隔で算出される計算結果Ｂ３３３は、合成ワークフローの定義ごと、個々ワークフローの定義するプロセスごと、個々サービスごとにSLA実績管理部Ｂ６１で管理される。
SLA実績管理部Ｂ６１で管理される一定時間間隔で算出される計算結果は、一定時間間隔でSLA実績値Ｂ３３４として制御部Ｂ６２に渡された後、参照され、SLA管理部Ｂ５９内で管理される個々のサービス群、個々ワークフローの定義するプロセス群、個々の合成ワークフロー群のサービス条件・品質条件Ｂ３３２と比較し、是正が必要であれば制御部Ｂ６２が必要な対応をとる。
次に、コスト期待値計算部Ｂ６３の処理が実施される。Action Tree等を用いて補償コスト期待値を計算する手順、及び図１２で実施される分散トランザクション処理で障害が発生した場合に補償トランザクション群をどの方法に基づいて実施するか、問い合わせる手順とともに、コスト期待値計算部Ｂ６３の構成を図２０に示す。また、コスト期待値計算部Ｂ６３がAction Tree等を用いて補償コスト期待値を計算する手順を図２１、２２にフローチャートとして示す。以下、図１９〜２２を用いて説明する。
制御部Ｂ６２と同様に、コスト期待値計算部Ｂ６３の一定時間間隔で起動する。起動は一定時間ごとに起動タイマＢ６０１が発する起動イベントＢ６２３によって行われる。
コスト期待値計算部Ｂ６３は、メタデータ取得部Ｂ６０５、実績データ取得部Ｂ６０６、Saga方式におけるAction Depth期待値算出モジュールＢ６０７、Top Down打ち消し再試行方式におけるAction Depth期待値算出モジュールＢ６０８、その他方式におけるAction Depth期待値算出モジュールＢ６０９を含む。
コスト期待値計算部Ｂ６３が起動すると、メタデータ取得部Ｂ６０５は、メタデータ管理部Ｂ５６内で管理される合成ワークフロー定義の一覧を得るため、取得依頼コマンドＢ６２４を発行する（図２１、ステップＳ１）。その後、メタデータ管理部Ｂ５６は、合成ワークフロー定義の一覧Ｂ６２５を戻す（図２１、ステップＳ２）。
メタデータ取得部Ｂ６０５は、その後、合成ワークフロー定義の一覧Ｂ６２５から一つの合成ワークフロー定義を選択する（図２１、ステップＳ３）。そして、以降の操作を合成ワークフロー定義が取得できなくなるまで繰り返す。
具体的には、合成ワークフロー定義のエントリを指定することで、図１７の管理関係Ｂ２５８を基にSaga方式Action Tree記述Ｂ６０３を指定し、そのエントリＢ６２６をダウンロードする。その後、エントリＢ６２６を基にコスト値期待値計算部Ｂ６３上にデプロイするコマンドＢ６２７を発行し、Saga方式におけるAction Depth期待値算出モジュールＢ６０７を生成する（図２１、ステップＳ４）。
Saga方式におけるAction Depth期待値算出モジュールＢ６０７を生成するに当たっては、エントリＢ６２６で記載される上記式（２）で与えられるAction Depthに関する変数のリテラル表現や、上記式（４）で与えられる発生確率に関する変数のリテラル表現は、Saga方式におけるAction Depth期待値算出モジュールＢ６０７の実行する処理系の変数にバインドされる。また、SLA実績管理部Ｂ６１で管理され、一定時間間隔で算出される合成ワークフローの定義ごと、個々ワークフローの定義するプロセスごと、個々サービスごとの計算結果Ｂ３３３を参照する形で、所要とされる計算結果の参照先がポイントされる（図２１、ステップＳ５）。
同様に、合成ワークフロー定義のエントリを指定することで、図１７の管理関係Ｂ２５９を基にTop Down打ち消し再試行方式Action Tree記述Ｂ６０４を指定し、そのエントリＢ６２８をダウンロードする。その後、エントリＢ６２８を基にコスト期待値計算部Ｂ６３上にデプロイするコマンドＢ６２９を発行し、Top Down打ち消し再試行方式におけるAction Depth期待値算出モジュールＢ６０８を生成する（図２１、ステップＳ６）。
Top Down打ち消し再試行方式におけるAction Depth期待値算出モジュールＢ６０８を生成するに当たっては、エントリＢ６２８で記載される上記式（２）で与えられるAction Depthに関する変数のリテラル表現や、上記式（４）で与えられる発生確率に関する変数のリテラル表現は、Top Down打ち消し再試行方式におけるAction Depth期待値算出モジュールＢ６０８の実行する処理系の変数にバインドされる。また、SLA実績管理部Ｂ６１で管理され、一定時間間隔で算出される合成ワークフローの定義ごと、個々ワークフローの定義するプロセスごと、個々サービスごとの計算結果Ｂ３３３を参照する形で、所要とされる計算結果の参照先がポイントされる（図２１、ステップＳ７）。
同様に、合成ワークフロー定義のエントリを指定することで、図１７の管理関係Ｂ２５７を基にその他方式Action Tree記述Ｂ６０２を指定し、そのエントリＢ６３０をダウンロードする。その後、エントリＢ６３０を基にコスト期待値計算部Ｂ６３上にデプロイするコマンドＢ６３１を発行し、その他方式におけるAction Depth期待値算出モジュールＢ６０９を生成する（図２１、ステップＳ８）。
その他方式におけるAction Depth期待値算出モジュールＢ６０９を生成するに当たっては、エントリＢ６３０で記載される上記式（２）で与えられるAction Depthに関する変数のリテラル表現や、上記式（４）で与えられる発生確率に関する変数のリテラル表現は、その他方式におけるAction Depth期待値算出モジュールＢ６０９の実行する処理系の変数にバインドされる。また、SLA実績管理部Ｂ６１で管理され、一定時間間隔で算出される合成ワークフローの定義ごと、個々ワークフローの定義するプロセスごと、個々サービスごとの計算結果Ｂ３３３を参照する形で、所要とされる計算結果の参照先がポイントされる（図２１、ステップＳ９）。
コスト期待値計算部Ｂ６３は、一連のデプロイメント操作を終えると、具体的には上記式（５）にて定義さえるAction Depth期待値の計算を行う。計算に当たっては、Saga方式、Top Down打ち消し再試行方式、その他方式を順次連続して行う、又は並列して実施することも可能である。
Saga方式におけるAction Depth期待値算出モジュールＢ６０７は、内部変数にバインドされAction Depth期待値を計算する上で必要なデータのリスト、及び合成ワークフロー定義のエントリを引数で指定し、実績データ取得部Ｂ６０６にデータ取得要求コマンドＢ６３２を発行する（図２１、ステップＳ１０ａ）。
その後、実績データ取得部Ｂ６０６は、データ取得要求コマンドＢ６３２で引数として与えられる合成ワークフロー定義のエントリ、及びAction Depth期待値を計算する上で必要なデータを含んだ検索要求Ｂ６３３をSLA実績管理部Ｂ６１へ発行する。
SLA実績管理部Ｂ６１では、検索要求Ｂ６３３で指定された合成ワークフロー定義のエントリを基に、Action Depth期待値を計算する上で必要なデータを指定された順序で設定し、応答Ｂ６３４として実績データ取得部Ｂ６０６へ戻す。応答Ｂ６３４に含まれるデータは、定義されたデータ及び一定時間間隔で算出される合成ワークフローごと、個々ワークフローの定義するプロセスごと、個々サービスごとの計算結果Ｂ３３３を含む。
実績データ取得部Ｂ６０６は、データ取得要求コマンドＢ６３２に対する応答として、応答Ｂ６３４に含まれるデータをSaga方式におけるAction Depth期待値算出モジュールＢ６０７に応答Ｂ６３５で戻す（図２２、ステップＳ１１ａ）。
Saga方式におけるAction Depth期待値算出モジュールＢ６０７では、応答Ｂ６３４で受信したデータを加工し、上記式（５）に基づきAction Depth期待値を計算実施する。（図２２、ステップＳ１２ａ）。計算により算出された値は、補償コスト期待値管理部Ｂ６４上のSaga方式におけるAction Depth期待値データＢ６１０として登録するように、起動した時刻と指定した合成ワークフロー定義のエントリを引数として登録コマンドＢ６４４が発行される。
補償コスト期待値管理部Ｂ６４は、Saga方式におけるAction Depth期待値データＢ６１０が更新されている場合は、計算により算出された値に基づき、Saga方式におけるAction Depth期待値データＢ６１０を書き換える。また、Saga方式におけるAction Depth期待値データＢ６１０が存在していない場合は、新規に生成する（図２２、ステップＳ１３ａ）。
指定した合成ワークフロー定義のエントリが異なると、再度実績データ取得部Ｂ６０６を用いてデータを取得の上で算出する。さらに、引数が変わるため新たな登録コマンドＢ６４７が発行され、補償コスト期待値管理部Ｂ６４上に、異なるSaga方式におけるAction Depth期待値データＢ６１１が生成・更新される。
Top Down打ち消し再試行方式におけるAction Depth期待値算出モジュールＢ６０８は、内部変数にバインドされAction Depth期待値を計算する上で必要なデータのリスト、及び合成ワークフロー定義のエントリを引数で指定し、実績データ取得部Ｂ６０６に、データ取得要求コマンドＢ６３６を発行する（図２１、ステップＳ１０ｂ）。
その後、実績データ取得部Ｂ６０６は、データ取得要求コマンドＢ６３６で引数として与えられる合成ワークフロー定義のエントリ、及びAction Depth期待値を計算する上で必要なデータを含んだ、検索要求Ｂ６３７をSLA実績管理部Ｂ６１に発行する。
SLA実績管理部Ｂ６１では、検索要求Ｂ６３７で指定された合成ワークフロー定義のエントリを基に、Action Depth期待値を計算する上で必要なデータを指定された順序で設定し、応答Ｂ６３８として実績データ取得部Ｂ６０６に戻す。応答Ｂ６３８に含まれるデータは定義されたデータ及び一定時間間隔で算出される合成ワークフローの定義ごと、個々ワークフローの定義するプロセスごと、個々サービスごとの計算結果Ｂ３３３を含む。
実績データ取得部Ｂ６０６は、データ取得要求コマンドＢ６３６に対する応答として、応答Ｂ６３８に含まれるデータを、Top Down打ち消し再試行方式におけるAction Depth期待値算出モジュールＢ６０８に応答Ｂ６３９で戻す（図２２、ステップＳ１１ｂ）。
Top Down打ち消し再試行方式におけるAction Depth期待値算出モジュールＢ６０８では、応答Ｂ６３９で受信したデータを加工し、上記式（５）に基づきAction Depth期待値を計算実施する（図２２、ステップＳ１２ｂ）。計算により算出された値は、補償コスト期待値管理部Ｂ６４上のTop Down打ち消し再試行方式にAction Depth期待値データＢ６１２として登録するように、起動した時刻と、指定した合成ワークフロー定義のエントリを引数として登録コマンドＢ６４５が発行される。
補償コスト期待値管理部Ｂ６４は、Top Down打ち消し方式におけるAction Depth期待値データＢ６１２が更新されている場合は、計算により算出された値に基づき、Top Down打ち消し再試行方式におけるAction Depth期待値データＢ６１２を書き換える。また、Top Down打ち消し再試行方式におけるAction Depth期待値データＢ６１２が存在していない場合は、新規に作成する（図２２、ステップＳ１３ｂ）。
指定した合成ワークフロー定義のエントリが異なると、再度実績データ取得部Ｂ６０６を用いてデータを取得の上で算出する。さらに、引数が変わるため新たな登録コマンドＢ６４８が発行され、補償コスト期待値管理部Ｂ６４上に異なるTop Down打ち消し再試行方式におけるAction Depth期待値データＢ６１３が生成・更新される。
その他方式におけるAction Depth期待値算出モジュールＢ６０９は、内部変数にバインドされAction Depth期待値を計算する上で必要なデータのリスト、及び合成ワークフロー定義のエントリを引数で指定し、実績データ取得部Ｂ６０６に、データ取得要求コマンドＢ６４０を発行する（図２１、ステップＳ１０ｃ）。
その後、実績データ取得部Ｂ６０６は、データ取得要求コマンドＢ６４０で引数として与えられる合成ワークフロー定義のエントリ、及びAction Depth期待値を計算する上で必要なデータを含んだ、検索要求Ｂ６４１をSLA実績管理部Ｂ６１に発行する。
SLA実績管理部Ｂ６１では、検索要求Ｂ６４１で指定された合成ワークフロー定義のエントリを基に、Action Depth期待値を計算する上で必要なデータを指定された順序で設定し、応答Ｂ６４２として実績データ取得部Ｂ６０６に戻す。応答Ｂ６４２に含まれるデータは定義されたデータ及び一定時間間隔で算出される合成ワークフローの定義ごと、個々ワークフローの定義するプロセスごと、個々サービスごとの計算結果Ｂ３３３を含む。
実績データ取得部Ｂ６０６は、データ取得要求コマンドＢ６４０に対する応答として、応答Ｂ６４２に含まれるデータを、その他方式におけるAction Depth期待値算出モジュールＢ６０９に応答Ｂ６４３で戻す（図２２、ステップＳ１１ｃ）。
その他方式におけるAction Depth期待値算出モジュールＢ６０７では、応答Ｂ６４３で受信したデータを加工し、上記式（５）に基づきAction Depth期待値を計算実施する（図２２、ステップＳ１２ｃ）。計算により算出された値は、補償コスト期待値管理部Ｂ６４上のその他方式にAction Depth期待値データＢ６１２として登録するように、起動した時刻と、指定した合成ワークフロー定義のエントリを引数として登録コマンドＢ６４６が発行される。
補償コスト期待値管理部Ｂ６４は、その他方式におけるAction Depth期待値データＢ６１４が更新されている場合は、計算により算出された値に基づき、その他方式におけるAction Depth期待値データＢ６１４を書き換える。また、その他方式におけるAction Depth期待値データＢ６１４が存在していない場合は、新規に作成する（図２２、ステップＳ１３ｃ）。
指定した合成ワークフロー定義のエントリが異なると、再度実績データ取得部Ｂ６０６を用いてデータを取得の上で算出する。さらに、引数が変わるため新たな登録コマンドＢ６４９が発行され、補償コスト期待値管理部Ｂ６４上に異なるその他方式におけるAction Depth期待値データＢ６１５が生成・更新される。
その後、メタデータ取得部Ｂ６０５に処理を戻す。メタデータ取得部Ｂ６０５は、合成ワークフロー定義の一覧Ｂ６２５から全ての合成ワークフロー定義を選択したか否かをチェックする（図２２、ステップＳ１４）。全てのワークフロー定義を選択し、処理を完了した場合は（図２２、ステップＳ１４／Ｙｅｓ）、コスト期待値計算部Ｂ６３は、起動タイマＢ６０１が一定時間ごとに発する次の起動イベントｂ６２３まで休止し、終了とする。
図２３は、Saga方式の補償トランザクション群の処理に該当する処理を、図１２に示される装置にて実施した場合の処理手順を示す。
分散トランザクション処理を含む合成ワークフローを起動するには、例えば、サービスクライアントＢ２から更新要求メッセージＢ４００が送信され、ワークフロー処理系Ｂ４により受信されることとなる。この結果、ワークフロー処理系Ｂ４に含まれるワークフローＢ１６が起動する。
ワークフローＢ１６が起動すると、その内部に持つプロセスの定義Ｂ６７に従い、アクティビティを順次呼び出していく。まず、起点であり、後続のアクティビティ（アクティビティＢ７２、Ｂ７４）を呼び出すアクティビティＢ７１が呼び出される。
その後、アクティビティＢ７１は、プロセスの定義Ｂ６７に従い、直列化又は並列化して後続のアクティビティＢ７２、Ｂ７４を呼び出していく。アクティビティＢ７４が立ち上がると、サービス処理系Ｂ７に更新要求メッセージＢ４０１を送信する。これは、図６における更新要求メッセージＡ１０１に相当する。
サービス処理系Ｂ７は、更新要求メッセージＢ４０１を受信すると、更新系サービスＢ３６を起動する。更新系サービスＢ３６は、操作ログＢ３９に更新前イメージ及び更新要求メッセージＢ４０１内の値を基に、内部で管理するDataＢ３８を値Ｂ４０３で更新する。その後、サービス処理系Ｂ４に更新応答メッセージＢ４０４を返信する。これは、図６における更新応答メッセージＡ１０２に相当する。
ワークフロー処理系Ｂ４は、更新応答メッセージＢ４０４を受信すると、その内部の操作ログＢ２８にメッセージ送信イベントＢ４０５、正常応答メッセージ受信イベントＢ４０６を書き込む。その後、後続のアクティビティに処理を移す。
続けてアクティビティＢ７２が立ち上がると、サービス処理系Ｂ８に参照要求メッセージＢ４０７を送信する。
サービス処理系Ｂ８は、参照要求メッセージＢ４０７を受信すると、参照系サービスＢ４０を起動する。参照系サービスＢ４０は、参照要求メッセージＢ４０７内の問い合わせ条件を基に、内部で管理するDataＢ４３を検索するとともに、その検索結果Ｂ４０８を取り出す。その後、参照系サービスＢ４０は、参照応答メッセージＢ４０９を返信する。
ワークフロー処理系Ｂ４は、参照応答メッセージＢ４０９を受信すると、その内部の操作ログＢ２８にメッセージ送信イベントＢ４１０、正常応答メッセージ受信イベントＢ４１１を書き込む。その後、後続のアクティビティに処理を移す。
アクティビティＢ７２が、参照応答メッセージＢ４０９を受信すると、ワークフローＢ６７は、処理を進め、アクティビティＢ７３を起動する。アクティビティＢ７３が立ち上がると、サービス処理系Ｂ８に更新要求メッセージＢ４１２を送信する。これは、図６における更新要求メッセージＡ１０３に相当する。
サービス処理系Ｂ８は、更新要求メッセージＢ４１２を受信すると、更新系サービスＢ４１を起動する。更新系サービスＢ４１は、操作ログＢ４４に更新前イメージ及び更新要求メッセージＢ４１２内の値に基づく操作内容を記録する。その後、更新要求メッセージＢ４１２内の値を基に、内部で管理するDataＢ４３を値Ｂ４１４で更新するが、ここでは失敗したと想定する。
その場合、サービス処理系Ｂ８は、内部で管理するDataＢ４３が途中まで変更されている場合、元の状態に戻すため、操作ログＢ４４に記録した更新前イメージＢ４１５を検索の上で取り出し、DataＢ４３を更新前の状態に戻す。その後、ワークフロー処理系Ｂ４に異常更新応答メッセージＢ４１６を返信する。これは、図６における更新応答メッセージＡ１０４に相当する。
ワークフロー処理系Ｂ４は、異常更新応答メッセージＢ４１６を受信すると、その内部の操作ログＢ２８にメッセージ送信イベントＢ４１７、異常応答メッセージ受信イベントＢ４１８を書き込む。
ワークフロー処理系Ｂ４は、操作ログＢ２８に書き込んだメッセージ送信イベントＢ４０５相当のイベントメッセージＢ４１９、正常応答メッセージ受信イベントＢ４０６相当のイベントメッセージＢ４２０、メッセージ送信イベントＢ４１０相当のイベントメッセージＢ４２１、正常応答メッセージ受信イベントＢ４１１相当のイベントメッセージＢ４２２、メッセージ送信イベントＢ４１７相当のイベントメッセージＢ４２３、及び異常応答メッセージ受信イベントＢ４１８相当のイベントメッセージＢ４２４をトランザクション・SLAモニタ管理部Ｂ１１内のログ受信部Ｂ４７に送信する。
イベントメッセージのトランザクション・SLAモニタ管理部Ｂ１１内のログ受信部Ｂ５７への送付は、サービス処理系でも実施される。サービス処理系Ｂ７は、更新要求メッセージＢ４０１の受信イベント相当のイベントメッセージＢ４５５、及び更新応答メッセージＢ４０４の送信イベント相当のイベントメッセージＢ４５６をログ受信部ｂ５７へ送付する。
同様に、サービス処理系Ｂ８は、参照要求メッセージＢ４０７の受信イベント相当のイベントメッセージＢ４２５、参照応答メッセージＢ４０９の送信イベント相当のイベントメッセージＢ４２６、更新要求メッセージＢ４１２の受信イベント相当のイベントメッセージＢ４２７、更新応答メッセージＢ４１６の送信イベント相当のイベントメッセージＢ４２８をログ受信部Ｂ５７へ送付する。
ワークフロー処理系Ｂ４は、異常更新応答メッセージＢ４１６を受信し、操作ログＢ２８に異常応答メッセージ受信イベントＢ４１８を書き込んだ後、補償処理を行うため、ワークフローＢ１６内の補償処理に関する定義を呼び出す。この場合は、補償ハンドララッパＢ２０が起動する。
補償ハンドララッパＢ２０は、起動すると、とるべき補償トランザクション群の方式を確定するために、トランザクション・SLA管理部Ｂ１１内部のコスト問い合わせ受信部Ｂ６５に、問い合わせメッセージＢ４２９を送信する。その後、コスト問い合わせ受信部Ｂ６５を介して補償トランザクション群の方式を指定する応答メッセージＢ４３０を受信する。
問い合わせメッセージＢ４２９を受信した場合に、コスト問い合わせ受信部Ｂ６５が実施する処理の概要を図２０に示す。さらに、ロングライブトランザクション方式による分散トランザクション処理で障害が発生した場合に補償トランザクション群をどの方法に基づいて実施するかを決定する手順を図２４、２５にフローチャートとして示す。
図２０においては、問い合わせメッセージＢ４２９は問い合わせメッセージＢ６５１に相当する。また、応答メッセージＢ４３０は応答メッセージｂ６６６に相当する。
コスト問い合わせ受信部Ｂ６５は、その構成要素として、実際に問い合わせメッセージを受信する問い合わせ管理部Ｂ６１９、問い合わせ管理部Ｂ６１９から起動を受けて、それぞれ該当するAction Depth期待値データを取得するSaga方式の関係データ取得部Ｂ６１６、Top Down打ち消し再試行方式の関係データ取得部Ｂ６１７、その他方式の関係データ取得部Ｂ６１８、三つの関係データ取得部が入手するデータを受けて、それらを比較して一つの結果を算出するデータ比較・判断部Ｂ６２０、データ比較・判断部Ｂ６２０からの応答を受けて、応答メッセージＢ６６６を送信する応答部Ｂ６２１から構成される。
問い合わせ管理部Ｂ６１９は、問い合わせメッセージＢ６５１を受信するまでは受信状況の確認を行う（図２４、ステップＳ１０１）。そして、問い合わせメッセージＢ６５１を受信すると処理を開始する。その後、問い合わせメッセージＢ６５１を取り出し、補償処理を開始する位置と合成ワークフロー定義の特定とを行う（図２４、ステップＳ１０２）。
問い合わせ管理部Ｂ６１９は、補償処理を開始する位置と合成ワークフロー定義の特定とを行うと、その情報及び出力先であるデータ比較・判断部Ｂ６２０の参照先情報を引数として、Saga方式の関係データ取得部Ｂ６１６を起動するコマンドＢ６５２を発行する（図２４、ステップＳ１０３ａ）。
Saga方式の関係データ取得部Ｂ６１６が起動すると、合成ワークフロー定義を引数として補償コスト期待値管理部Ｂ６４内で管理するSaga方式におけるAction Depth期待値データ群Ｂ６１０、Ｂ６１１を検索するコマンドＢ６５５を発行する（図２４、ステップＳ１０４ａ）。
補償コスト期待値管理部Ｂ６４内部において検索が実施される。その後、補償コスト期待値管理部Ｂ６４は、該当するSaga方式におけるAction Depth期待値Ｂ６５６をSaga方式の関係データ取得部Ｂ６１６に戻す（図２４、ステップＳ１０５ａ）。
Saga方式の関係データ取得部Ｂ６１６は、Saga方式におけるAction Depth期待値Ｂ６５６を出力先であるデータ比較・判断部Ｂ６２０にAction Depth期待値Ｂ６６１として渡す（図２４、ステップＳ１０６ａ）。
並行して問い合わせ管理部Ｂ６１９は、補償処理を開始する位置と合成ワークフロー定義の特定情報、及び出力先であるデータ比較・判断部Ｂ６２０の参照先情報を引数として、Top Down打ち消し再試行方式の関係データ取得部Ｂ６１７を起動するコマンドＢ６５３を発行する（図２４、ステップＳ１０３ｂ）。
Top Down打ち消し再試行方式の関係データ取得部Ｂ６１７が起動すると、合成ワークフロー定義を引数として補償コスト期待値管理部Ｂ６４内で管理するTop Down打ち消し再試行方式におけるAction Depth期待値データ群Ｂ６１２、Ｂ６１３を検索するコマンドＢ６５７を発行する（図２４、ステップＳ１０４ｂ）。
補償コスト期待値管理部Ｂ６４内部において検索が実施される。その後、補償コスト期待値管理部Ｂ６４は、該当するTop Down打ち消し再試行方式におけるAction Depth期待値Ｂ６５８をTop Down打ち消し再試行方式の関係データ取得部Ｂ６１７に戻す（図２４、ステップＳ１０５ｂ）。
Top Down打ち消し再試行方式の関係データ取得部Ｂ６１７は、Top Down打ち消し再試行方式におけるAction Depth期待値Ｂ６５８を出力先であるデータ比較・判断部Ｂ６２０にAction Depth期待値Ｂ６６２として渡す（図２４、ステップＳ１０６ｂ）。
並行して問い合わせ管理部Ｂ６１９は、補償処理を開始する位置と合成ワークフロー定義の特定情報、及び出力先であるデータ比較・判断部Ｂ６２０の参照先情報を引数として、その他方式の関係データ取得部Ｂ６１８を起動するコマンドＢ６５４を発行する（図２４、ステップＳ１０３ｃ）。
その他方式の関係データ取得部Ｂ６１８が起動すると、合成ワークフロー定義を引数として補償コスト期待値管理部Ｂ６４内で管理するその他方式におけるAction Depth期待値データ群Ｂ６１４、Ｂ６１５を検索するコマンドＢ６５９を発行する（図２４、ステップＳ１０４ｃ）。
補償コスト期待値管理部Ｂ６４内部において検索が実施される。その後、補償コスト期待値管理部Ｂ６４は、該当するその他方式におけるAction Depth期待値Ｂ６６０をその他方式の関係データ取得部Ｂ６１８に戻す（図２４、ステップＳ１０５ｃ）。
その他方式の関係データ取得部Ｂ６１８は、その他方式におけるAction Depth期待値Ｂ６６０を出力先であるデータ比較・判断部Ｂ６２０にAction Depth期待値Ｂ６６３として渡す（図２４、ステップＳ１０６ｃ）。
データ比較・判断部Ｂ６２０は、Saga方式におけるAction Depth期待値Ｂ６６１、Top Down打ち消し再試行方式におけるAction Depth期待値Ｂ６６２、その他方式におけるAction Depth期待値Ｂ６６３を全て受信すると、その内部で比較し、最小のAction Depth期待値を持つ方法を選択する（図２５、ステップＳ１０７）。
その後、データ比較・判断部Ｂ６２０は、問い合わせ管理部Ｂ６１９で管理される問い合わせメッセージＢ６５１に関係するデータを引数として応答部Ｂ６２１を起動するコマンドＢ６６５を発行する（図２５、ステップＳ１０８）。
その後、応答部Ｂ６２１は、データ比較・判断部Ｂ６２０が手順６にて選択した最小のAction Depth期待値を持つ方法に関する結果とその特定事項についてのデータＢ６６４を取得する（図２５、ステップＳ１０９）。
その後、応答部Ｂ６２１は、結果とその特定事項についてのデータＢ６６４を用いて、SLA実績管理部Ｂ６１に合意サービス水準を満足するか否かを確認する問い合わせメッセージＢ６６７を送信し、その結果である応答メッセージＢ６６８を得る（図２５、ステップＳ１１０）。
その後、応答部Ｂ６２１は、結果とその特定事項についてのデータＢ６６４とから方式の選択を行う（ステップＳ１１１）。Saga方式が指定されている場合には（ステップＳ１１１／Saga方式）、補償トランザクション群の方式としてSaga方式の旨を意味する応答メッセージ記述を作成する。その際、応答メッセージＢ６６８を判定し、合意サービス水準違反か否かの判定結果を含める（図２５、ステップＳ１１２ａ）。
これに対して、Top Down打ち消し再試行方式が指定されている場合には（ステップＳ１１１／Top Down打ち消し再試行方式）、補償トランザクション群の方式としてTop Down打ち消し再試行方式の旨を意味する応答メッセージ記述を作成する。その際、応答メッセージＢ６６８を判定し、合意サービス水準違反か否かの判定結果を含める（図２５、ステップＳ１１２ｂ）。
また、その他方式が指定されている場合には（ステップＳ１１１／その他方式）、補償トランザクション群の方式としてその他方式の旨を意味する応答メッセージ記述を作成する。その際、応答メッセージＢ６６８を判定し、合意サービス水準違反か否かの判定結果を含める（図２５、ステップＳ１１２ｃ）。
その後、応答部は、応答メッセージ記述を応答メッセージＢ６６６として送信する（図２５、ステップＳ１１３）。図２３では、応答メッセージＢ６６６は、補償トランザクション群の方式を指定する応答メッセージＢ４３０となる。これに対して図２６では応答メッセージＢ５３０となる。
図２３にて、補償ハンドララッパＢ２０が、補償トランザクション群の方式を指定する応答メッセージＢ４３０を受信し、補償トランザクション群の方式としてSaga方式が指定されている場合は、Saga方式の補償トランザクション群の処理を実施するため、内部の操作ログＢ２８を参照し、操作ログＢ２８に書き込まれた送受信イベントとは逆順序により、補償トランザクション群を実施する。そこで、サービス処理系Ｂ８からの異常応答メッセージ受信イベントＢ４１８を受信したログＢ４３１を参照する。
実際の補償トランザクションは、補償ハンドララッパＢ２０ではなく、それが取り込み参照する補償ハンドラＢ２４が実施する。補償ハンドラＢ２４は補償要求メッセージＢ４３２をサービス処理系Ｂ８へ送信する。
サービス処理系Ｂ８は、補償要求メッセージＢ４３２を受信すると、更新系サービス補償Ｂ４２を起動する。その後、更新系サービス補償Ｂ４２でもSaga方式の補償トランザクション群の処理を実施するため、内部ログＢ４４を参照し、更新前イメージＢ４１５を検索の上で取り出す。その上で、これに基づき必要であればDataＢ４３の補償処理を実施するため、更新前の値Ｂ４３３で更新する。なお、既に補償処理が実施されている場合はこの限りではない。
補償処理が成功すると、サービス処理系Ｂ８は、ワークフロー処理系Ｂ４に補償応答メッセージＢ４３４を送信する。
ワークフロー処理系Ｂ４は、補償応答メッセージＢ４３４を受信すると、その内部の操作ログＢ２８に補償要求メッセージ送信イベントＢ４４０、補償応答メッセージ受信イベントＢ４４１を書き込む。
補償ハンドララッパＢ２０は、続けてSaga方式の補償トランザクション群の処理を実施するため、内部の操作ログＢ２８を参照し、操作ログＢ２８に書き込まれた送受信イベントとは逆順序により次の補償トランザクション群を実施する。そこでサービス処理系Ｂ７から正常応答メッセージ受信イベントＢ４０６を受信したログＢ４３５を参照する。
補償ハンドラＢ２４は、補償要求メッセージＢ４３６をサービス処理系Ｂ７へ送信する。これはいわば、図６における補償要求メッセージＡ１１８に相当する。
サービス処理系Ｂ７は、補償要求メッセージＢ４３６を受信すると、更新系サービス補償Ｂ３７を起動する。その後、更新系サービス補償Ｂ３７でもSaga方式の補償トランザクション群の処理を実施するため、内部の操作ログＢ３９を参照し、更新前イメージＢ４３７を検索の上で取り出す。その上で、これに基づきDataＢ３８の補償処理を実施するため、更新前の値Ｂ４３８で更新する。
補償処理が成功すると、サービス処理系Ｂ７は、ワークフロー処理系Ｂ４に補償応答メッセージＢ４３９を送信する。これはいわば図６における補償応答メッセージＡ１２４に相当する。
ワークフロー処理系Ｂ４は、補償応答メッセージＢ４３９を受信すると、その内部の操作ログＢ２８に補償要求メッセージ送信イベントＢ４４２、及び補償応答メッセージ受信イベントＢ４４３を書き込む。
ワークフロー処理系Ｂ４は、操作ログＢ２８に書き込んだ補償要求メッセージ送信イベントＢ４４０相当のイベントメッセージＢ４４４、補償応答メッセージ受信イベントＢ４４１相当のイベントメッセージＢ４４５、補償要求メッセージ送信イベントＢ４４２相当のイベントメッセージＢ４４６、及び補償応答メッセージ受信イベントＢ４４３相当のイベントメッセージＢ４４７をトランザクション・SLAモニタ管理部Ｂ１１内のログ受信部Ｂ５７へ送信する。
また、サービス処理系Ｂ７は、補償要求メッセージＢ４３６の受信イベント相当のイベントメッセージＢ４５０、及び補償応答メッセージＢ４３９の送信イベント相当のイベントメッセージＢ４５１をログ受信部Ｂ５７へ送付する。
同様に、サービス処理系Ｂ８は、補償要求メッセージＢ４３２の受信イベント相当のイベントメッセージＢ４４８、及び補償応答メッセージＢ４３４の送信イベント相当のイベントメッセージＢ４４９をログ受信部Ｂ５７へ送付する。
ワークフロー処理系４は、一連のアクティビティを正常に終了すると、呼び出し元のサービスクライアントＢ２に異常終了を意味する更新応答メッセージＢ４５２を返信する。その後、ワークフロー処理系Ｂ４は、操作ログＢ２８に書き込むとともに、更新応答メッセージＢ４５２相当のイベントメッセージＢ４５３をログ受信部Ｂ５７に送信する。
図２６は、Top Down打ち消し再試行方式の補償トランザクション群の処理に該当する処理を、図１２に示す装置で実施した場合の処理手順を示す。
分散トランザクション処理を含む合成ワークフローを起動するには、例えばサービスクライアントＢ２から更新要求メッセージＢ５００が送信され、ワークフロー処理系Ｂ４により受信される。この結果、ワークフロー処理系Ｂ４に含まれるワークフローＢ１６が起動する。
ワークフローＢ１６が起動すると、その内部に持つプロセスの定義Ｂ６７に従いアクティビティを順次呼び出していく。まず、起点であり、後続のアクティビティ（アクティビティＢ７２、Ｂ７４）を呼び出すアクティビティＢ７１が呼び出される。
その後、アクティビティＢ７１は、プロセスの定義Ｂ６７に従い、直列化又は並列化して、後続のアクティビティＢ７２、Ｂ７４を呼び出していく。アクティビティＢ７４が立ち上がると、サービス処理系Ｂ７に更新要求メッセージＢ５０１を送信する。これは、図９における更新要求メッセージＡ１０１に相当する。
サービス処理系Ｂ７は、更新要求メッセージＢ５０１を受信すると、更新系サービスＢ３６を起動する。更新系サービスＢ３６は、操作ログＢ３９に更新前イメージ及び往信要求メッセージＢ５０１内の値に基づく操作内容Ｂ５０２を記録する。その後、更新要求メッセージＢ５０１内の値を基に、内部で管理するDataＢ３８を値Ｂ５０３で更新する。その後、サービス処理系Ｂ７は、ワークフロー処理系Ｂ４に更新応答メッセージＢ５０４を送信する。これは、図９における更新応答メッセージＡ１０２に相当する。
ワークフロー処理系Ｂ４は、更新応答メッセージＢ５０４を受信すると、その内部の操作ログＢ２８にメッセージ送信イベントＢ５０５、正常応答メッセージ受信イベントＢ５０６を書き込む。その後、後続のアクティビティに処理を移す。
続けてアクティビティＢ７２が立ち上がると、サービス処理系Ｂ８に参照要求メッセージＢ５０７を送信する。
サービス処理系Ｂ８は、参照要求メッセージＢ５０７を受信すると、参照系サービスＢ４０を起動する。参照系サービスＢ４０は、参照要求メッセージＢ５０７内の問い合わせ条件を基に、内部で管理するDataＢ４３を検索するとともに、その検索結果Ｂ５０８を取り出す。その後、参照系サービスＢ４０は、参照応答メッセージＢ５０９を返信する。
ワークフロー処理系Ｂ４は、参照応答メッセージＢ５０９を受信すると、その内部の操作ログＢ２８にメッセージ送信イベントＢ５１０、及び正常応答メッセージ受信イベントＢ５１１を書き込む。その後、後続のアクティビティに処理を移す。
アクティビティＢ７２が参照応答メッセージＢ５０９を受信すると、ワークフローＢ６７は処理を進め、アクティビティＢ７３を起動する。アクティビティＢ７３が立ち上がると、サービス処理系Ｂ８に更新要求メッセージＢ５１２を送信する。これは、図９における更新要求メッセージＡ１０３に相当する。
サービス処理系Ｂ８は、更新要求メッセージＢ５１２を受信すると、更新系サービスＢ４１を起動する。更新系サービスＢ４１は、操作ログＢ４４に更新前イメージ及び更新要求メッセージＢ５１２内の値に基づく操作内容Ｂ５１３を記録する。その後、更新要求メッセージＢ５１２内の値を基に、内部で管理するDataＢ４３を値Ｂ５１４で更新するが、ここでは失敗したと想定する。
その場合、サービス処理系Ｂ８は、内部で管理するDataＢ４３が途中まで変更されている場合、元の状態に戻すため、操作ログＢ４４に記録した更新前イメージＢ５１５を検索の上で取り出して、DataＢ４３を更新前の状態に戻す。その後、ワークフロー処理系Ｂ４に異常更新応答メッセージＢ５１６を返信する。これは、図６における更新応答メッセージＡ１０４に相当する。
ワークフロー処理系Ｂ４は、異常更新応答メッセージＢ５１６を受信すると、その内部の操作ログＢ２８にメッセージ送信イベントＢ５１７、及び異常応答メッセージ受信イベントＢ５１８を書き込む。
ワークフロー処理系Ｂ４は、操作ログＢ２８に書き込んだメッセージ送信イベントＢ５０５相当のイベントメッセージＢ５１９、正常応答メッセージ受信イベントＢ５０６相当のイベントメッセージＢ５２０、メッセージ送信イベントＢ５１０相当のイベントメッセージＢ５２１、正常応答メッセージ受信イベントＢ５１１相当のイベントメッセージＢ５２２、メッセージ送信イベントＢ５１７相当のイベントメッセージＢ５２３、及び異常応答メッセージ受信イベントＢ５１８相当のイベントメッセージＢ５２４をトランザクション・SLAモニタ管理部Ｂ１１内のログ受信部Ｂ５７に送信する。
イベントメッセージのトランザクション・SLAモニタ管理部Ｂ１１内のログ受信部Ｂ５７への送付は、サービス処理系でも実施される。サービス処理系Ｂ７は、更新要求メッセージＢ５０１の受信イベント相当のイベントメッセージＢ５８１及び更新応答メッセージＢ５０４の送信イベント相当のイベントメッセージＢ５８２をログ受信部Ｂ５７へ送付する。
同様に、サービス処理系Ｂ８は、参照要求メッセージＢ５０７の受信イベント相当のイベントメッセージＢ５２５、参照応答メッセージＢ５０９の送信イベント相当のイベントメッセージＢ５２６、更新要求メッセージＢ５１２の受信イベント相当のイベントメッセージＢ５２７、更新応答メッセージＢ５１６の送信イベント相当のイベントメッセージＢ５２８をログ受信部Ｂ５７へ送付する。
ワークフロー処理系Ｂ４は、異常更新応答メッセージＢ５１６を受信し、操作ログＢ２８に異常応答メッセージ受信イベントＢ５１８を書き込んだ後、補償処理を行うため、ワークフローＢ１６内の補償処理に関する定義を呼び出す。この場合は、補償ハンドララッパＢ２０が起動する。
補償ハンドララッパＢ２０は、起動すると、とるべき補償トランザクション群の方式を確定するために、トランザクション・SLA管理部Ｂ１１内部のコスト問い合わせ受信部Ｂ６５に、問い合わせメッセージＢ４２９を送信する。その後、コスト問い合わせ受信部Ｂ６５を介して補償トランザクション群の方式を指定する応答メッセージＢ５３０を受信する。
問い合わせメッセージＢ５２９を受信した場合に、コスト問い合わせ受信部Ｂ６５が実施する処理の概要を図２０に示す。さらに、ロングライブトランザクション方式による分散トランザクション処理で障害が発生した場合に補償トランザクション群をどの方法に基づいて実施するかを決定する手順を図２４、２５にフローチャートとして示す。
図２０においては、問い合わせメッセージＢ５２９は問い合わせメッセージＢ６５１に相当する。また、応答メッセージＢ５３０は応答メッセージｂ６６６に相当する。
図２６にて、補償ハンドララッパＢ２０が、補償トランザクション群の方式を指定する応答メッセージＢ５３０を受信し、補償トランザクション群の方式としてTop Down打ち消し再試行方式が指定されている場合は、補償ハンドララッパＢ２０は、ワークフロー処理系Ｂ４に処理を戻し、呼び出し元のサービスクライアントＢ２に、異常終了で打ち消し処理が必要である旨を意味する更新応答メッセージＢ５３１を返信する。その後、ワークフロー処理系Ｂ４は、操作ログＢ２８に書き込むとともに、更新応答メッセージＢ５３１相当のイベントメッセージＢ５３２をログ受信部Ｂ５７に送信する。
呼び出し元のサービスクライアントＢ２では、補償動作が実施されていないため、それに相当する処理を起動する。具体的には、サービスクライアントＢ２から補償要求メッセージＢ５５０が送信され、ワークフロー処理系Ｂ４により受信される。この結果、ワークフロー処理系Ｂ４に含まれ、ワークフローＢ１６に対応するワークフロー補償Ｂ１８が起動する。
ワークフロー補償Ｂ１８が起動すると、その内部に持つプロセスの定義Ｂ６８に従いアクティビティを順次呼び出していく。まず、起点であり、後続のアクティビティ（アクティビティＢ７６、Ｂ７７）を呼び出すアクティビティＢ７５が呼び出される。
その後、アクティビティＢ７５は、プロセスの定義Ｂ６８に従い、直列化又は並列化して、後続のアクティビティＢ７６、Ｂ７７を呼び出していく。アクティビティＢ７７が立ち上がると、サービス処理系Ｂ７に補償要求メッセージＢ５５１を送信する。これは、図９における更新要求メッセージＡ１１３に相当する。
サービス処理系Ｂ７は、補償要求メッセージＢ５５１を受信すると、更新系サービス補償Ｂ３７ではなく、更新系サービスＢ３６を起動する。更新系サービスＢ３６は、操作ログＢ３９に更新前イメージ及び補償要求メッセージＢ５５１内の値に基づく操作内容Ｂ５５２を記録する。その後、補償要求メッセージＢ５５１内の値を基に、内部で管理するDataＢ３８を値Ｂ５５３で更新する。その後、サービス処理系Ｂ７は、ワークフロー処理系Ｂ４に補償応答メッセージＢ５５４を送信する。これは、図９における更新応答メッセージＡ１１４に相当する。
ワークフロー処理系Ｂ４は、補償応答メッセージＢ５５４を受信すると、その内部の操作ログＢ２８に補償要求メッセージ送信イベントＢ５５５、補償応答メッセージ受信イベントＢ５５６を書き込む。その後、後続のアクティビティに処理を移す。
続けてアクティビティＢ７６が立ち上がると、サービス処理系Ｂ８に補償要求メッセージＢ５５７を送信する。
サービス処理系Ｂ８は、補償要求メッセージＢ５５７を受信すると、更新系サービス補償Ｂ４２ではなく、更新系サービスＢ４１を起動する。更新系サービスＢ４１は、操作ログＢ４４に更新前イメージ及び補償要求メッセージＢ５５７内の値に基づく操作内容を記録する。その後、補償要求メッセージＢ５５７内の値を基に、内部で管理するDataＢ４３を値Ｂ５５９で更新する。
その後、サービス処理系Ｂ８は、ワークフロー処理系Ｂ４に補償応答メッセージＢ５６０を返信する。これは、図９における補償応答メッセージＡ１１６に相当する。
ワークフロー処理刑Ｂ４は、補償応答メッセージＢ５６０を受信すると、その内部の操作ログＢ２８に補償要求メッセージ送信イベントＢ５６１、補償応答メッセージ受信イベントＢ５６２を書き込む。その後、後続のアクティビティに処理を移す。
ワークフロー処理系Ｂ４は、操作ログＢ２８に書き込んだ補償要求メッセージ送信イベントＢ５５５相当のイベントメッセージＢ５６３及び補償応答メッセージ受信イベントＢ５５６相当のイベントメッセージＢ５６４、補償要求メッセージ送信イベントＢ５６１相当のイベントメッセージＢ５６５、及び補償応答メッセージ受信イベントＢ５６２相当のイベントメッセージＢ５６６を、トランザクション・SLAモニタ管理部Ｂ１１内のログ受信部Ｂ５７に送信する。
イベントメッセージのトランザクション・SLAモニタ管理部Ｂ１１内のログ受信部Ｂ５７への送付は、サービス処理系でも実施される。サービス処理系Ｂ７は、補償要求メッセージＢ５５１の受信イベント相当のイベントメッセージＢ５６９、及び補償応答メッセージＢ５５４の送信イベント相当のイベントメッセージＢ５７０をログ受信部ｂ５７へ送付する。
同様に、サービス処理系Ｂ８は、補償要求メッセージＢ５５７の受信イベント相当のイベントメッセージＢ５６７、及び補償応答メッセージＢ５６０の送信イベント相当のイベントメッセージＢ５６８をログ受信部Ｂ５７へ送付する。
ワークフロー処理系Ｂ４は、一連のアクティビティを正常に終了すると、呼び出し元のサービスクライアントＢ２に打ち消し処理要求が正常に終了したことを通知する補償応答メッセージＢ５７１を返信する。その後、ワークフロー処理系Ｂ４は、操作ログＢ２８に書き込むとともに、補償応答メッセージＢ５７１相当のイベントメッセージＢ５７２をログ受信部Ｂ５７に送信する。
このように、本実施形態によれば、複数サーバにより実施されるロングライブトランザクション方式に基づく分散トランザクション処理の整合性を最適な計算資源を用いながら維持管理できる。
なお、上記実施形態は本発明の好適な実施の一例であり、本発明はこれに限定されることなく様々な変形が可能である。
本発明に係る補償処理手順選択装置の構成を示す図である。 補償トランザクションの処理モデルを定義するための最も基本的な計算機ネットワーク環境を模式的に示す図である。 ロングライブトランザクション方式による分散トランザクション処理の正常処理を、流通するメッセージ群の関係で示す図である。 ロングライブトランザクション方式による分散トランザクション処理の直列化した正常処理を、流通するメッセージ群及び処理タイミングを用いて示すシーケンス図である。 ロングライブトランザクション方式による分散トランザクション処理の並列化した正常処理を、流通するメッセージ群及び処理タイミングを用いて示すシーケンス図である。 ロングライブトランザクション方式による分散トランザクション処理で障害が発生した場合に実施される補償トランザクション群についてSaga方式を採用した場合の処理を、流通するメッセージ群の関係で示す図である。 直列化したSaga方式の補償トランザクション群の処理を、流通するメッセージ群及び処理タイミングを用いて示すシーケンス図である。 並列化したSaga方式の補償トランザクション群の処理を、流通するメッセージ群及び処理タイミングを用いて示すシーケンス図である。 ロングライブトランザクション方式による分散トランザクション処理で障害が発生した場合に実施される補償トランザクション群についてTop Down打ち消し再試行方式を採用した場合の処理を、流通するメッセージ群の関係で示す図である。 直列化したTop Down打ち消し再試行方式の補償トランザクション群の処理を、流通するメッセージ群及び処理タイミングを用いて示すシーケンス図である。 並列化したTop Down打ち消し再試行方式の補償トランザクション群の処理を、流通するメッセージ群及び処理タイミングを用いて示すシーケンス図である。 ロングライブトランザクション方式による分散トランザクション処理の正常処理、Saga方式の補償トランザクション群の処理、Top Down打ち消し再試行方式の補償トランザクション群の処理を、合意サービス水準を考慮して選択的に実施する装置の構成を示す図である。 Action Treeを用いて補償トランザクション群を評価する場合のAction Treeの構成方法を示す図である。 Action Treeを用いて補償トランザクション群を評価する場合のAction Treeの構成方法を示す図である。 Action Treeを用いて補償トランザクション群を評価する場合のAction Treeの構成方法を示す図である。 ワークフロー定義群の一つの表現形式を示す図である。 デプロイ段階で実施するAction Treeを生成する際の処理の概要を示す図である。 デプロイ段階で実施する処理手順を構成とともに示す図である。 ロングライブトランザクション方式による分散トランザクション処理の正常処理の手順を示す図である。 補償コスト期待値を計算する手順及び分散トランザクション処理で障害が発生した場合の問い合わせ手順を示す図である。 補償コスト期待値を算出する処理の流れを示すフローチャートである。 補償コスト期待値を算出する処理の流れを示すフローチャートである。 Saga方式の補償トランザクション群の処理に該当する処理手順を示す図である。 分散トランザクション処理で障害が発生した場合の問い合わせ、補償方式決定の処理の手順を示す図である。 分散トランザクション処理で障害が発生した場合の問い合わせ、補償方式決定の処理の手順を示す図である。 Top Down打ち消し再試行方式の補償トランザクション群の処理に該当する処理手順を示す図である。
符号の説明
１ 補償処理手順方式選択装置
２ａ、２ｂ、２ｎ ワークフロー処理系
１１ 部分補償配置部
１２、Ｂ６３ コスト期待値計算部
１３、Ｂ６４ 補償コスト期待値管理部
２１ａ、２１ｂ、２１ｎ 補償部分実施部
Ａ１ サービスクライアントノード
Ａ２、Ａ３ サービス中間ノード
Ａ４、Ａ５、Ａ６、Ａ７、Ａ８、Ａ９ サービス末端ノード
Ａ１００、Ａ１０１、Ａ１０３、Ａ１０６、Ａ１０７、Ａ１０９、Ａ１７１、Ａ１７３、Ｂ３００、Ｂ３０１、Ｂ３０５、Ｂ４００、Ｂ４０１、Ｂ４１２、Ｂ５００、Ｂ５０１、Ｂ５１２ 更新要求メッセージ
Ａ１０２、Ａ１０４、Ａ１０５、Ａ１０８、Ａ１１０、Ａ１１１、Ａ１２５、Ａ１２６、Ａ１７２、Ａ１７４、Ｂ３０２、Ｂ３０６、Ｂ３６１、Ｂ４０４、Ｂ４５２、Ｂ５０４、Ｂ５３１ 更新応答メッセージ
Ａ１１２、Ａ１１３、Ａ１１５、Ａ１１８、Ａ１１９、Ａ１２１、Ａ１７５、Ａ１７７、Ｂ４３２、Ｂ４３６、Ｂ５５０、Ｂ５５１、Ｂ５５７ 補償要求メッセージ
Ａ１１４、Ａ１１６、Ａ１１７、Ａ１２０、Ａ１２２、Ａ１２３、Ａ１２４、Ａ１７６、Ａ１７８、Ｂ４３４、Ｂ４３９、Ｂ５５４、Ｂ５６０、Ｂ５７１ 補償応答メッセージ
Ａ１５０ 起動要求
Ａ１５１、Ａ１９０ 正常終了
Ａ１５２ 異常終了
Ａ１５３、Ａ１５４、Ａ１５５、Ａ１５６、Ａ１５７ プロセス
Ａ１８０ 始点ノードシンボル
Ａ１８１、Ａ１９１、Ａ１９２、Ａ１９３、Ａ１９４、Ａ１９５、Ａ１９６、Ａ１９７、Ａ１９８、Ａ１９９ アーク
Ａ１８２ 終端ノードシンボル
Ａ１８３ Action Sub Treeシンボル
Ａ１８４、Ａ１８５、Ａ１８６、Ａ１８７ アノテーションラベル
Ｂ１、Ｂ２、Ｂ３ サービスクライアント
Ｂ４、Ｂ５ ワークフロー処理系
Ｂ６、Ｂ７、Ｂ８、Ｂ９、Ｂ１０ サービス処理系
Ｂ１１ トランザクション・SLAモニタ管理部
Ｂ１２ ＳＯＡリポジトリ
Ｂ１３、Ｂ１５ デプロイヤ
Ｂ１４ 開発環境
Ｂ１６、Ｂ１７ ワークフロー
Ｂ１８、Ｂ１９ ワークフロー補償
Ｂ２０、Ｂ２１、Ｂ２２、Ｂ２３、Ｂ２４、Ｂ２５、Ｂ２６、Ｂ２７ 補償ハンドララッパ
Ｂ２８、Ｂ２９、Ｂ３４、Ｂ３９、Ｂ４４、Ｂ４９、Ｂ５４ 操作ログ
Ｂ３０、Ｂ３５、Ｂ４０、Ｂ４５、Ｂ５０ 参照系サービス
Ｂ３１、Ｂ３６、Ｂ４１、Ｂ４６、Ｂ５１ 更新系サービス
Ｂ３２、Ｂ３７、Ｂ４２、Ｂ４７、Ｂ５２ 更新系サービス補償
Ｂ３３、Ｂ３８、Ｂ４３、Ｂ４８、Ｂ５３ Data
Ｂ５５ 統合処理部
Ｂ５６ メタデータ管理部
Ｂ５７ ログ受信部
Ｂ５８ イベントインスタンスデータ管理部
Ｂ５９ SLA管理部
Ｂ６０ SLA計算部
Ｂ６１ SLA実績管理部
Ｂ６２ 制御部
Ｂ６５ コスト問い合わせ受信部
Ｂ６６ Action Tree生成部
Ｂ６７、Ｂ６８、Ｂ６９、Ｂ７０、Ｂ２００、Ｂ２２５、Ｂ２２６、Ｂ２２７、Ｂ２２８ プロセス定義
Ｂ７１、Ｂ７２、Ｂ７３、Ｂ７４、Ｂ７５、Ｂ７６、Ｂ７７ アクティビティ
Ｂ８０ 補償ハンドララッパテンプレート
Ｂ８１ 補償ハンドララッパテンプレートの定義情報
Ｂ８２ サービス条件・品質条件定義データ
Ｂ１００ 更新系サービスＹに関する定義
Ｂ１０１ ワークフローＸ−１に関する定義
Ｂ１０２ 補償ハンドラＸ−１（−）に関する定義
Ｂ１０３ 更新系サービスＹエントリ
Ｂ１０４ ワークフローＸ−１エントリ
Ｂ１０５ 補償ハンドララッパのエントリ
Ｂ１０６、Ｂ１１０、Ｂ２１０、Ｂ２１２、Ｂ２１４ プロセス定義のメタデータ
Ｂ１０７、Ｂ１１１、Ｂ２１１、Ｂ２１３、Ｂ２１５、Ｂ２１７、Ｂ２１８、Ｂ２１９ サービス定義のメタデータ
Ｂ１０８、Ｂ１０９ 登録エントリ
Ｂ１１２ 合成ワークフロー定義相当データ
Ｂ１１３、Ｂ１１４、Ｂ２２０、Ｂ２２１、Ｂ２２２、Ｂ２２３、Ｂ２４８、Ｂ２４９、Ｂ２５０、Ｂ２５１、Ｂ２５２、Ｂ２５３、Ｂ２５４、Ｂ２５５、Ｂ２５６ 転送形式データ
Ｂ２０１ サービス定義
Ｂ２０２ 定義部
Ｂ２０３、Ｂ２０４、Ｂ２０５ アクティビティ部
Ｂ２０６ メッセージ定義部
Ｂ２０７ ポート定義部
Ｂ２０８ バインディング部
Ｂ２０９ サービス定義部
Ｂ２２４、Ｂ２２９ 内部メモリ空間
Ｂ２３０ サービスクライアントノード記述定義
Ｂ２３１ サービス中間ノード１Ｘ記述定義
Ｂ２３２ サービス中間ノード２Ｘ記述定義
Ｂ２３３ サービス中間ノード３Ｘ記述定義
Ｂ２３４ サービス末端ノード１Ｙ記述定義
Ｂ２３５ サービス末端ノード２Ｙ記述定義
Ｂ２３６ 正常系Action Tree
Ｂ２３７ その他方式Action Tree
Ｂ２３８ Saga方式Action Tree
Ｂ２３９ Top Down打ち消し再試行方式Action Tree
Ｂ２４０ 確率関数記述付与部
Ｂ２４１ その他方式Action Tree記述
Ｂ２４２ Saga方式Action Tree記述
Ｂ２４３ Top Down打ち消し再試行方式Action Tree記述
Ｂ２４４ 合成ワークフロー定義
Ｂ２４５、Ｂ６０２ その他方式Action Tree記述
Ｂ２４６、Ｂ６０３ Saga方式Action Tree記述
Ｂ２４７、Ｂ６０４ Top Down打ち消し再試行方式Action Tree記述
Ｂ２５７、Ｂ２５８、Ｂ２５９ 管理関係
Ｂ２６０ 補償処理Action Tree生成部
Ｂ３０３、Ｂ４０７、Ｂ５０７ 参照要求メッセージ
Ｂ３０４、Ｂ４０８、Ｂ５０９ 参照応答メッセージ
Ｂ３０７、Ｂ３０９、Ｂ３１１、Ｂ４０５、Ｂ４１０Ｂ４１７、Ｂ５０５、Ｂ５１０、Ｂ５１７ メッセージ送信イベント
Ｂ３０８、Ｂ３１０、Ｂ３１２、Ｂ４０６、Ｂ４１１、Ｂ５０６、Ｂ５１１ 正常応答メッセージ受信イベント
Ｂ３１３、Ｂ３１４、Ｂ３１５、Ｂ３１６、Ｂ３１７、Ｂ３１８、Ｂ３１９、Ｂ３２０、Ｂ３２１、Ｂ３２２、Ｂ３２３、Ｂ３２４、Ｂ３６０、Ｂ４１９、Ｂ４２０、Ｂ４２１、Ｂ４２２、Ｂ４２３、Ｂ４２４、Ｂ４２５、Ｂ４２６、Ｂ４２７、Ｂ４２８、ｂ４４４、Ｂ４４５、Ｂ４４６、Ｂ４４７、Ｂ４４８、Ｂ４４９、Ｂ４５０、Ｂ４５１、Ｂ４５３、Ｂ４５５、Ｂ４５６、Ｂ５１８、Ｂ５１９、Ｂ５２０、Ｂ５２１、Ｂ５２２、Ｂ５２３、Ｂ５２４、Ｂ５２５、Ｂ５２６、Ｂ５２７、Ｂ５２８、Ｂ５３２、Ｂ５６３、Ｂ５６４、Ｂ５６５、Ｂ５６６、Ｂ５６７、Ｂ５６８、Ｂ５６９、Ｂ５７０、Ｂ５７２、Ｂ５８１、Ｂ５８２ イベントメッセージ
Ｂ３２５、Ｂ３２９ プロセス定義メタデータの一部データ
Ｂ３２６、Ｂ３３０ サービス定義メタデータの一部データ
Ｂ３２７ イベントインスタンスデータ
Ｂ３２８、Ｂ３５５ 合成ワークフロー定義の一部データ
Ｂ３３１、Ｂ３５６ イベントインスタンスデータ群
Ｂ３３２ サービス条件・品質条件
Ｂ３３３ 計算結果
Ｂ３３４ SLA実績値
Ｂ３５０、Ｂ３５２、Ｂ４１３、Ｂ５０２、Ｂ５１３、Ｂ５５２、Ｂ５５８ 操作内容
Ｂ３５１、Ｂ３５３、Ｂ４０３、Ｂ４１４、Ｂ４３３、Ｂ４３８、Ｂ５０３、Ｂ５１４、Ｂ５５３、Ｂ５５９ 値
Ｂ３５４、Ｂ５０８ 検索結果
Ｂ４１５、Ｂ４３７、Ｂ５１５ 更新前イメージ
Ｂ４１６、Ｂ５１６ 異常更新応答メッセージ
Ｂ４１８、Ｂ５１８ 異常応答メッセージ受信イベント
Ｂ４２９、Ｂ５２９、Ｂ６５１、Ｂ６６７ 問い合わせメッセージ
Ｂ４３０、Ｂ５３０、Ｂ６６６、Ｂ６６８ 応答メッセージ
Ｂ４３１、Ｂ４３５ ログ
Ｂ４４０、Ｂ４４２、Ｂ５５５、Ｂ５６１ 補償要求メッセージ送信イベント
Ｂ４４１、Ｂ４４３、Ｂ５５６、Ｂ５６２ 補償応答メッセージ受信イベント
Ｂ６０１ 起動タイマ
Ｂ６０５ メタデータ取得部
Ｂ６０６ 実績データ取得部
Ｂ６０７ Saga方式におけるAction Depth期待値算出モジュール
Ｂ６０８ Top Down打ち消し再試行方式におけるAction Depth期待値算出モジュール
Ｂ６０９ その他方式におけるAction Depth期待値算出モジュール
Ｂ６１０、Ｂ６１１ Saga方式におけるAction Depth期待値データ
Ｂ６１２、Ｂ６１３ Top Down打ち消し再試行方式におけるAction Depth期待値データ
Ｂ６１４、Ｂ６１５ その他方式におけるAction Depth期待値データ
Ｂ６１６ Saga方式の関係データ取得部
Ｂ６１７ Top Down打ち消し再試行方式の関係データ取得部
Ｂ６１８ その他方式の関係データ取得部
Ｂ６１９ 問い合わせ管理部
Ｂ６２０ データ比較・判断部
Ｂ６２１ 応答部
Ｂ６２３ 起動イベント
Ｂ６２４ 取得依頼コマンド
Ｂ６２５ 合成ワークフロー定義の一覧
Ｂ６２６、Ｂ６２８、Ｂ６３０ エントリ
Ｂ６２７、Ｂ６２９、Ｂ６３１、Ｂ６５２、Ｂ６５３、Ｂ６５４、Ｂ６５５、Ｂ６５７、Ｂ６５９、Ｂ６６５ コマンド
Ｂ６３２、Ｂ６３６、Ｂ６４０ データ取得要求コマンド
Ｂ６３３、Ｂ６３７、Ｂ６４１ 検索要求
Ｂ６３４、Ｂ６３５、Ｂ６３８、Ｂ６３９、Ｂ６４２、Ｂ６４３ 応答
Ｂ６４４、Ｂ６４５、Ｂ６４６、Ｂ６４８、Ｂ６４９ 登録コマンド
Ｂ６５６、Ｂ６６１ Saga方式におけるAction Depth期待値
Ｂ６５８、Ｂ６６２ Top Down打ち消し再試行方式におけるAction Depth期待値
Ｂ６６０、Ｂ６６３ その他方式におけるAction Depth期待値
Ｂ６６４ 結果とその特定事項についてのデータ

Claims (25)

  1. ロングライブトランザクション方式に基づく分散トランザクション処理を実施する複数のワークフロー処理手段の中に、前記分散トランザクション処理において異常を検出した場合に、その整合性を維持するために実施される補償処理を部分実施する補償部分実施手段を配置する部分補償配置手段と、
    既に実施した前記分散トランザクション処理の実績を基に、少なくとも合意サービス水準をパラメータとして定義された事項を複数の前記補償処理の手順方式の各々に関して評価して期待値データを算出するコスト期待値計算手段と、
    複数の前記期待値データを管理し、前記補償部分実施手段からの問い合わせに応じて、前記期待値データに基づいて前記補償処理の手順方式を指定する補償コスト期待値管理手段とを含み、
    前記補償処理の手順方式を、当該分散トランザクション処理全体の性能を最適化するよう、合意サービス水準を考慮して選択することを特徴とする補償処理手順方式選択装置。
  2. 前記コスト期待値計算手段において、数理的モデルを用いて前記補償処理の手順方式を評価することを特徴とする請求項１記載の補償処理手順方式選択装置。
  3. 前記数理的モデルがAction Treeを用いて表現されたことを特徴とする請求項２記載の補償処理手順方式選択装置。
  4. 前記補償部分実施手段は、前記補償処理のハンドラと、該ハンドラの周辺機能で共通的に定義され、前記補償処理を実施する段階で前記補償コスト期待値に基づく前記補償処理の手順方式を選択するための問い合わせを実施する手順を含むハンドララッパとを含むことを特徴とする請求項１から３のいずれか１項記載の補償処理手順方式選択装置。
  5. 前記部分補償配置手段は、所定の定義情報に基づいて挙動を評価し、正規化した前記補償部分実施手段を前記ワークフロー処理手段の中に配置することを特徴とする請求項１から４のいずれか１項記載の補償処理手順方式選択装置。
  6. 前記コスト期待値計算手段は、前記期待値データを定期的に算出することを特徴とする請求項１から５のいずれか１項記載の補償処理手順方式選択装置。
  7. ロングライブトランザクション方式に基づく分散トランザクション処理において異常を検出した場合に、当該分散トランザクション処理の整合性を維持するため実施される補償処理を部分実施する補償部分実施手段を前記複数サーバ内に配置し、
    既に実施した前記分散トランザクション処理の実績を基に、少なくとも合意サービス水準をパラメータとして定義された事項を複数の前記補償処理の手順方式の各々に関して評価して期待値データを算出し、
    前記補償部分実施手段からの問い合わせに応じて、前記期待値データに基づいて前記補償処理の手順方式を指定し、前記補償処理の手順方式を、当該分散トランザクション処理全体の性能を最適化するよう、合意サービス水準を考慮して選択することを特徴とする補償処理手順方式選択方法。
  8. 前記期待値データを算出する際に、数理的モデルを用いて前記補償処理の手順方式を評価することを特徴とする請求項７記載の補償処理手順方式選択方法。
  9. 前記数理的モデルを、Action Treeを用いて表現することを特徴とする請求項８記載の補償処理手順方式選択方法。
  10. 前記補償部分実施手段は、前記補償処理のハンドラと該ハンドラの周辺機能で共通的に定義され、前記補償処理を実施する段階で前記補償コスト期待値に基づく前記補償処理の手順方式を選択するための問い合わせを実施する手順を含むハンドララッパとを含むことを特徴とする請求項７から９のいずれか１項記載の補償処理手順方式選択方法。
  11. 所定の定義情報に基づいて挙動を評価し、正規化した前記補償部分実施手段を前記ワークフロー処理手段の中に配置することを特徴とする請求項７から１０のいずれか１項記載の補償処理手順方式選択方法。
  12. 前記期待値データを定期的に算出することを特徴とする請求項７から１１のいずれか１項記載の補償処理手順方式選択方法。
  13. コンピュータに、
    ロングライブトランザクション方式に基づく分散トランザクション処理において異常を検出した場合に、当該分散トランザクション処理の整合性を維持するため実施される補償処理を部分実施する補償部分実施手段を前記複数サーバ内に配置する処理と、
    既に実施した前記分散トランザクション処理の実績を基に、少なくとも合意サービス水準をパラメータとして定義された事項を複数の前記補償処理の手順方式の各々に関して評価して期待値データを算出する処理と、
    前記補償部分実施手段からの問い合わせに応じて、前記期待値データに基づいて前記補償処理の手順方式を指定し、前記補償処理の手順方式を、当該分散トランザクション処理全体の性能を最適化するように合意サービス水準を考慮して選択する処理とを実行させることを特徴とする補償処理手順方式選択プログラム。
  14. 前記コンピュータに、
    前記期待値データを算出する際に、数理的モデルを用いて前記補償処理の手順方式を評価させることを特徴とする請求項１３記載の補償処理手順方式選択プログラム。
  15. 前記コンピュータに、
    前記数理的モデルを、Action Treeを用いて表現させることを特徴とする請求項１４記載の補償処理手順方式選択プログラム。
  16. 前記補償部分実施手段は、前記補償処理のハンドラと該ハンドラの周辺機能で共通的に定義され、前記補償処理を実施する段階で前記補償コスト期待値に基づく前記補償処理の手順方式を選択するための問い合わせを実施する手順を含むハンドララッパとを含むことを特徴とする請求項１３から１５のいずれか１項記載の補償処理手順方式選択プログラム。
  17. 前記コンピュータに、所定の定義情報に基づいて挙動を評価させ、正規化した前記補償部分実施手段を前記ワークフロー処理手段の中に配置させることを特徴とする請求項１３から１６のいずれか１項記載の補償処理手順方式選択プログラム。
  18. 前記コンピュータに、前記期待値データを定期的に算出させることを特徴とする請求項１３から１７のいずれか１項記載の補償処理手順方式選択プログラム。
  19. 請求項１３から１８のいずれか１項記載の補償処理手順方式選択プログラムが記録されたコンピュータ可読の記録媒体。
  20. ロングライブトランザクション方式に基づく分散トランザクション処理を実施する複数のワークフロー処理装置と、前記分散トランザクション処理において異常を検出した場合に、その整合性を維持するために実施される補償処理の手順方式を、当該分散トランザクション処理全体の性能を最適化するよう、合意サービス水準を考慮して選択する補償処理手順方式選択装置とを有するワークフローシステムであって、
    前記補償処理手順選択装置は、
    前記ワークフロー処理装置のそれぞれの中に、前記分散トランザクション処理において異常を検出した場合に、その整合性を維持するために実施される前記補償処理を部分実施する補償部分実施手段を配置する部分補償配置手段と、
    既に実施した前記分散トランザクション処理の実績を基に、少なくとも合意サービス水準をパラメータとして定義された事項を複数の前記補償処理の手順方式の各々に関して評価して期待値データを算出するコスト期待値計算手段と、
    複数の前記期待値データを管理し、前記補償部分実施手段からの問い合わせに応じて、前記期待値データに基づいて前記補償処理の手順方式を指定する補償コスト期待値管理手段とを含むことを特徴とするワークフローシステム。
  21. 前記コスト期待値計算手段において、数理的モデルを用いて前記補償処理の手順方式を評価することを特徴とする請求項２０記載のワークフローシステム。
  22. 前記数理的モデルがAction Treeを用いて表現されたことを特徴とする請求項２１記載のワークフローシステム。
  23. 前記補償部分実施手段は、前記補償処理のハンドラと、該ハンドラの周辺機能で共通的に定義され、前記補償処理を実施する段階で前記補償コスト期待値に基づく前記補償処理の手順方式を選択するための問い合わせを実施する手順を含むハンドララッパとを含むことを特徴とする請求項２０から２２のいずれか１項記載のワークフローシステム。
  24. 前記部分補償配置手段は、所定の定義情報に基づいて挙動を評価し、正規化した前記補償部分実施手段を前記ワークフロー処理手段の中に配置することを特徴とする請求項２０から２３のいずれか１項記載のワークフローシステム。
  25. 前記コスト期待値計算手段は、前記期待値データを定期的に算出することを特徴とする請求項２０から２４のいずれか１項記載のワークフローシステム。
JP2008320017A 2008-12-16 2008-12-16 補償処理手順方式選択装置、方法、プログラム及びそれを記録した記録媒体、並びにワークフローシステム Withdrawn JP2010146103A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008320017A JP2010146103A (ja) 2008-12-16 2008-12-16 補償処理手順方式選択装置、方法、プログラム及びそれを記録した記録媒体、並びにワークフローシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008320017A JP2010146103A (ja) 2008-12-16 2008-12-16 補償処理手順方式選択装置、方法、プログラム及びそれを記録した記録媒体、並びにワークフローシステム

Publications (1)

Publication Number Publication Date
JP2010146103A true JP2010146103A (ja) 2010-07-01

Family

ID=42566519

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008320017A Withdrawn JP2010146103A (ja) 2008-12-16 2008-12-16 補償処理手順方式選択装置、方法、プログラム及びそれを記録した記録媒体、並びにワークフローシステム

Country Status (1)

Country Link
JP (1) JP2010146103A (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020504927A (ja) * 2016-12-19 2020-02-13 スワールズ，インコーポレイテッド イベントの削除を可能にする分散データベースのための方法および装置
JP2023045424A (ja) * 2021-09-22 2023-04-03 株式会社日立製作所 分散トランザクションシステム及び分散トランザクションシステムにおける分散トランザクション処理方法
US11734260B2 (en) 2015-08-28 2023-08-22 Hedera Hashgraph, Llc Methods and apparatus for a distributed database within a network
US11797502B2 (en) 2015-08-28 2023-10-24 Hedera Hashgraph, Llc Methods and apparatus for a distributed database within a network

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11734260B2 (en) 2015-08-28 2023-08-22 Hedera Hashgraph, Llc Methods and apparatus for a distributed database within a network
US11797502B2 (en) 2015-08-28 2023-10-24 Hedera Hashgraph, Llc Methods and apparatus for a distributed database within a network
JP2020504927A (ja) * 2016-12-19 2020-02-13 スワールズ，インコーポレイテッド イベントの削除を可能にする分散データベースのための方法および装置
JP7211943B2 (ja) 2016-12-19 2023-01-24 スワールズ，インコーポレイテッド イベントの削除を可能にする分散データベースのための方法および装置
US11657036B2 (en) 2016-12-19 2023-05-23 Hedera Hashgraph, Llc Methods and apparatus for a distributed database that enables deletion of events
JP2023045424A (ja) * 2021-09-22 2023-04-03 株式会社日立製作所 分散トランザクションシステム及び分散トランザクションシステムにおける分散トランザクション処理方法
JP7284791B2 (ja) 2021-09-22 2023-05-31 株式会社日立製作所 分散トランザクションシステム及び分散トランザクションシステムにおける分散トランザクション処理方法

Similar Documents

Publication Publication Date Title
US11853748B2 (en) Methods and systems that share resources among multiple, interdependent release pipelines
Broman et al. Determinate composition of FMUs for co-simulation
US8788569B2 (en) Server computer system running versions of an application simultaneously
US9235380B2 (en) Software modeling framework
US10656971B2 (en) Agile framework for vertical application development and delivery
US10762062B2 (en) Data governance: change management based on contextualized dependencies
US8984534B2 (en) Interfacing between a receiving component of a server application and a remote application
KR101087364B1 (ko) 철회 기반구조
CN112668386A (zh) 使用机器人过程自动化用于文档处理的长时间运行工作流
US8396846B2 (en) Database trigger modification system and method
Demuth et al. Co-evolution of metamodels and models through consistent change propagation
US20100281061A1 (en) Semantic Data Validation of Disjoint Data
US9459859B2 (en) Template derivation for configuration object management
Brandozzi et al. Transforming goal-oriented requirement specifications into architecture prescriptions
US20150220553A1 (en) Expandable ad hoc domain specific query for system management
US20150220404A1 (en) Undo configuration transactional compensation
CN110890987A (zh) 自动创建集群的方法、装置、设备和系统
JP2010146103A (ja) 補償処理手順方式選択装置、方法、プログラム及びそれを記録した記録媒体、並びにワークフローシステム
US7836449B2 (en) Extensible infrastructure for task display and launch
Bergmayr et al. From out-place transformation evolution to in-place model patching
Yongchareon et al. UniFlexView: A unified framework for consistent construction of BPMN and BPEL process views
US11741255B2 (en) System and method of block chain based protection for customized data integration processes
Kim Design pattern based model transformation with tool support
Chondamrongkul et al. Software architectural migration: an automated planning approach
Bianchi et al. An ASM-based model for grid job management

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20120306