(57)【要約】【課題】回復不可能な致命的な障害を引き起こす可能性の高いロングライブトランザクション（ＬＬＴ）の実行を抑止すること。【解決手段】計算機システム1000は、ＬＬＴの要求元となる任意の１つのトランザクション要求アプリケーション（ＡＰ）機能と、サービスの提供元となる１以上のサービス提供機能と、サービスを仲介する１以上のサービス仲介機能とを、複数の計算機1100上に分散して配置し、各機能を使用してＬＬＴの実行を行う。モニタ手段1300は、ＬＬＴのインスタンスを実施する直前に、各機能から送信されるＬＬＴ定義通知メッセージを受信解析して、ＬＬＴのインスタンスの実施直前の呼出関係に基づく実行計画を生成し、実行計画の検証を行って、検証結果をＬＬＴのインスタンスを起動したトランザクション要求ＡＰ機能に通知する。トランザクション要求ＡＰ機能は、通知された検証結果に応じて、ＬＬＴのインスタンスの実行可否を決定する。【選択図】図１
2010231309.tif 000002
【特許請求の範囲】
【請求項１】
トランザクションの要求元となる任意の１つのトランザクション要求アプリケーション機能と、サービスの提供元となる１以上のサービス提供機能と、前記トランザクション要求アプリケーション機能と前記サービス提供機能との間に位置してサービスを仲介する１以上のサービス仲介機能とを、複数の計算機上に分散して配置し、前記の各機能を使用してロングライブトランザクションの実行を行う計算機システムにおけるロングライブトランザクション実行管理方法であって、
ａ）前記ロングライブトランザクションのインスタンスの実施直前に実行される準備相ステップと、
ｂ）前記ロングライブトランザクションのインスタンスを実施する実行相ステップとを含み、
前記準備相ステップａは、
ａ−１）モニタ手段が、前記の各機能から送信されるロングライブトランザクション定義通知メッセージを受信解析して、前記ロングライブトランザクションのインスタンスの実施直前の呼出関係に基づく実行計画を生成するステップと、
ａ−２）前記モニタ手段が、前記生成した実行計画の検証を行い、その検証結果を前記ロングライブトランザクションのインスタンスを起動した前記トランザクション要求アプリケーション機能に通知するステップと、
ａ−３）前記トランザクション要求アプリケーション機能が、通知された検証結果に応じて、前記実行相ステップの実行可否を決定するステップと、
を含むことを特徴とするロングライブトランザクション実行管理方法。
【請求項２】
前記モニタ手段は、前記実行計画の検証において、１以上の前記サービス仲介機能から呼び出されている前記サービス提供機能の全てから前記ロングライブトランザクション定義通知メッセージを受信したか否かの検証を行うことを特徴とする請求項１に記載のロングライブトランザクション実行管理方法。
【請求項３】
前記モニタ手段は、前記実行計画の検証において、受信した全ての前記ロングライブトランザクション定義通知メッセージに記載される補償トランザクション方式がすべてsaga方式であるか否かの検証を行うことを特徴とする請求項２に記載のロングライブトランザクション実行管理方法。
【請求項４】
通知された検証結果が、１以上の前記サービス仲介機能から呼び出されている前記サービス提供機能の全てから前記ロングライブトランザクション定義通知メッセージを受信しており、かつ、受信した全ての前記ロングライブトランザクション定義通知メッセージに記載される補償トランザクション方式がすべてsaga方式であることを示す場合、前記実行相ステップの実行可と判断することを特徴とする請求項３に記載のロングライブトランザクション実行管理方法。
【請求項５】
通知された検証結果が、１以上の前記サービス仲介機能から呼び出されている前記サービス提供機能の全てから前記ロングライブトランザクション定義通知メッセージを受信していないことを示す場合、または、受信した全ての前記ロングライブトランザクション定義通知メッセージに記載される補償トランザクション方式がすべてsaga方式でないことを示す場合、前記実行相ステップの実行不可と判断することを特徴とする請求項３に記載のロングライブトランザクション実行管理方法。
【請求項６】
トランザクションの要求元となる任意の１つのトランザクション要求アプリケーション機能と、サービスの提供元となる１以上のサービス提供機能と、前記トランザクション要求アプリケーション機能と前記サービス提供機能との間に位置してサービスを仲介する１以上のサービス仲介機能とを、複数の計算機上に分散して配置し、前記の各機能を使用してロングライブトランザクションの実行を行う計算機システムであって、
前記ロングライブトランザクションのインスタンスを実施する直前に、前記の各機能から送信されるロングライブトランザクション定義通知メッセージを受信解析して、前記ロングライブトランザクションのインスタンスの実施直前の呼出関係に基づく実行計画を生成し、該生成した実行計画の検証を行って、その検証結果を前記ロングライブトランザクションのインスタンスを起動した前記トランザクション要求アプリケーション機能に通知するモニタ手段を備え、
前記トランザクション要求アプリケーション機能は、通知された検証結果に応じて、前記ロングライブトランザクションのインスタンスの実行可否を決定する、
ことを特徴とする計算機システム。
【請求項７】
トランザクションの要求元となる任意の１つのトランザクション要求アプリケーション機能と、サービスの提供元となる１以上のサービス提供機能と、前記トランザクション要求アプリケーション機能と前記サービス提供機能との間に位置してサービスを仲介する１以上のサービス仲介機能とを、複数の計算機上に分散して配置し、前記の各機能を使用してロングライブトランザクションの実行を行う計算機システムにおける前記ロングライブトランザクションの管理を行うモニタ装置であって、
前記ロングライブトランザクションのインスタンスを実施する直前に、前記の各機能から送信されるロングライブトランザクション定義通知メッセージを受信解析して、前記ロングライブトランザクションのインスタンスの実施直前の呼出関係に基づく実行計画を生成する実行計画生成手段と、
前記再生された実行計画の検証を行って、その検証結果を前記ロングライブトランザクションのインスタンスを起動した前記トランザクション要求アプリケーション機能に通知する検証手段と、
を備えたロングライブトランザクションモニタ装置。
【請求項８】
トランザクションの要求元となる任意の１つのトランザクション要求アプリケーション機能と、サービスの提供元となる１以上のサービス提供機能と、前記トランザクション要求アプリケーション機能と前記サービス提供機能との間に位置してサービスを仲介する１以上のサービス仲介機能とを、複数の計算機上に分散して配置し、前記の各機能を使用してロングライブトランザクションの実行を行う計算機システムにおける前記計算機の何れかを、
前記ロングライブトランザクションのインスタンスを実施する直前に、前記の各機能から送信されるロングライブトランザクション定義通知メッセージを受信解析して、前記ロングライブトランザクションのインスタンスの実施直前の呼出関係に基づく実行計画を生成する実行計画生成手段と、
前記再生された実行計画の検証を行って、その検証結果を前記ロングライブトランザクションのインスタンスを起動した前記トランザクション要求アプリケーション機能に通知する検証手段と、
して機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の計算機により構成される計算機システムにおいてロングライブトランザクションの実行を管理する方法に関する。
【背景技術】
【０００２】
一般にトランザクションには、ＡＣＩＤトランザクション、アトミックトランザクションあるいは密結合トランザクションと呼ばれる種類のトランザクション（以下、ＡＣＩＤトランザクションで代表する）と、ロングライブトランザクション、ロングラニングトランザクションあるいは疎結合トランザクションと呼ばれる種類のトランザクション（以下、ロングライブトランザクションで代表する）がある。本発明は後者のロングライブトランザクションの実行を管理する技術に関する。
【０００３】
ロングライブトランザクションの実行を管理する技術の一例が特許文献１に記載されている。
【０００４】
特許文献１に記載された技術では、プログラマーが、フローデバッガーやフローシミュレータを使用して、ロングライブトランザクションを定義し、チェックし、デバッグを行う。定義されてチェック等の済んだロングライブトランザクションは、作業記述フローデータベースと呼ばれるデータベースに保持されて管理され、実行時に参照される。
【０００５】
ロングライブトランザクションのインスタンスを実行するプロセスは、フローコントローラによって制御される。外部的に発生された入力事象信号がフローコントローラにより受信された場合に、ロングライブトランザクションの実行が開始される。ロングライブトランザクションの実行の間に、入力信号の定義された組が受信された場合にのみロングライブトランザクションの各ステップはインスタンス化され、実行される。
【０００６】
各ステップの終了時に、ステップからの出力信号が他のステップに対する入力事象信号に変換される。また、ログ記録が、ロングライブトランザクションの各ステップのインスタンスの実行と終了に基づいて蓄積され、かつ出力事象信号もまた記録される。
【０００７】
このようなログ記録によって、システム障害の前に行われた作業の実効的な損失なしに、ロングライブトランザクションの回復に十分なデータを蓄積することができる。例えば、ロングライブトランザクションの任意のステップが何らかの原因で実行に失敗すると、ロングライブトランザクションの放棄の判定となり、失敗したステップの補償トランザクションが実行され、更に、前に実行されたフローの全てのステップについても補償トランザクションが実行される。各ステップの補償トランザクションもまた、作業記述フローデータベースにおいて定義される。ロングライブトランザクションを、その各々がＡＣＩＤトランザクションであるサブトランザクションに分割した場合に、各サブトランザクション毎に補償トランザクションを定義しておくことによって補償を行う方式を、saga方式と呼ぶ。
【０００８】
なお、ロングライブトランザクションに関する技術を記載した他の文献として、特許文献２がある。特許文献２には、論理トランザクションコンテキスト、アクティビティ連鎖、アクティビティインスタンス識別子、静的プロセスによりインスタンス化されるビジネスアクティビティ、並びに動的プロセスによりインスタンス化されるビジネスアクティビティ、およびサーガマネージャと全般的なフレームワークが定義されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開平６−８３８４１号公報
【特許文献２】特開２００４−１６４５９４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
特許文献１に記載された技術は、ロングライブトランザクションの定義が、プログラマーによって事前にチェックされ、デバッグが完了していることを前提としている。しかしながら、全てのロングライブトランザクションの定義について、プログラマーによる事前のチェックやデバッグを完全に行うことには、人的かつ時間的に無理な場合がある。若し、プログラマーが定義内容における矛盾や欠落を見過ごした場合、矛盾や欠落のある状態でロングライブトランザクションが実行されてしまって、回復不可能な致命的な障害を与える危険性がある。
【００１１】
また特許文献１に記載された技術は、ロングライブトランザクションの定義が作業記述フローデータベースと呼ばれるデータベースの一箇所で集中して管理されているシステムを前提としている。しかし、ロングライブトランザクション全体の定義情報を一箇所で管理せず、ロングライブトランザクションを実行する個々の機能（トランザクション要求アプリケーション機能、サービス仲介機能、サービス提供機能）ごとに、その機能に関連する定義情報を持たせるシステムも考えられる。このようなシステムの場合には、ロングライブトランザクション全体の定義情報のチェックをプログラマーが事前に行うこと自体、困難な作業となる。
【００１２】
本発明の目的は、回復不可能な致命的な障害を引き起こす可能性の高いロングライブトランザクションの実行を抑止することのできるロングライブトランザクション実行管理方法を提供することにある。
【課題を解決するための手段】
【００１３】
本発明のロングライブトランザクション実行管理方法は、トランザクションの要求元となる任意の１つのトランザクション要求アプリケーション機能と、サービスの提供元となる１以上のサービス提供機能と、前記トランザクション要求アプリケーション機能と前記サービス提供機能との間に位置してサービスを仲介する１以上のサービス仲介機能とを、複数の計算機上に分散して配置し、前記の各機能を使用してロングライブトランザクションの実行を行う計算機システムにおけるロングライブトランザクション実行管理方法であって、ａ）前記ロングライブトランザクションのインスタンスの実施直前に実行される準備相ステップと、ｂ）前記ロングライブトランザクションのインスタンスを実施する実行相ステップとを含み、前記準備相ステップａは、ａ−１）モニタ手段が、前記の各機能から送信されるロングライブトランザクション定義通知メッセージを受信解析して、前記ロングライブトランザクションのインスタンスの実施直前の呼出関係に基づく実行計画を生成するステップと、ａ−２）前記モニタ手段が、前記生成した実行計画の検証を行い、その検証結果を前記ロングライブトランザクションのインスタンスを起動した前記トランザクション要求アプリケーション機能に通知するステップと、ａ−３）前記トランザクション要求アプリケーション機能が、通知された検証結果に応じて、前記実行相ステップの実行可否を決定するステップと、を含む。
【発明の効果】
【００１４】
本発明によれば、回復不可能な致命的な障害を引き起こす可能性の高いロングライブトランザクションの実行を抑止することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明で扱う準動的に決定されるロングライブトランザクションのモニタリング・管理方法を定義するための基本的な環境を模式的に記した構成図である。
【図２】図1で定義された環境において実施されるロングライブトランザクション方式による分散トランザクション処理の一部概要をモニタリング・管理方法を実現する機能を含めて記したシーケンス図である。
【図３】図2で記された分散トランザクション処理の一部である[Step.1]準備相の処理手順をモニタリング・管理方法を実現する機能を含めて記したシーケンス図である。
【図４】図2で記された分散トランザクション処理の一部である[Step.2]実行相の正常時の処理手順をモニタリング・管理方法を実現する機能を含めて記したシーケンス図である。
【図５】図2で記された分散トランザクション処理の一部である[Step.2]実行相の異常時の処理手順をモニタリング・管理方法を実現する機能を含めて記したシーケンス図である。
【図６】図2で記された分散トランザクション処理の一部である[Step.3]調整相の処理手順をモニタリング・管理方法を実現する機能を含めて記したシーケンス図である。
【図７】図2で記された分散トランザクション処理内の準備要求処理に関連し、図3で記された分散トランザクション処理の一部である[Step.1]準備相で利用されるlLTransactionPrepareRequestメッセージの一定義例を記した図である。
【図８−１】図2で記された分散トランザクション処理内のLLトランザクション定義通知処理に関連し、図3で記された分散トランザクション処理の一部である[Step.1]準備相で利用されるlLTransactionDefinitionNotificationメッセージの定義例の一部を記した図である。
【図８−２】図2で記された分散トランザクション処理内のLLトランザクション定義通知処理に関連し、図3で記された分散トランザクション処理の一部である[Step.1]準備相で利用されるlLTransactionDefinitionNotificationメッセージの定義例の一部を記した図である。
【図８−３】図2で記された分散トランザクション処理内のLLトランザクション定義通知処理に関連し、図3で記された分散トランザクション処理の一部である[Step.1]準備相で利用されるlLTransactionDefinitionNotificationメッセージの定義例の一部を記した図である。
【図９−１】図2で記された分散トランザクション処理内のトランザクションEvent通知処理に関連し、図4並びに図5で記された分散トランザクション処理の一部である[Step.2]実行相で利用されるlLTransactionEventNotificationメッセージの定義例の一部を記した図である。
【図９−２】図2で記された分散トランザクション処理内のトランザクションEvent通知処理に関連し、図4並びに図5で記された分散トランザクション処理の一部である[Step.2]実行相で利用されるlLTransactionEventNotificationメッセージの定義例の一部を記した図である。
【図９−３】図2で記された分散トランザクション処理内のトランザクションEvent通知処理に関連し、図4並びに図5で記された分散トランザクション処理の一部である[Step.2]実行相で利用されるlLTransactionEventNotificationメッセージの定義例の一部を記した図である。
【図９−４】図2で記された分散トランザクション処理内のトランザクションEvent通知処理に関連し、図4並びに図5で記された分散トランザクション処理の一部である[Step.2]実行相で利用されるlLTransactionEventNotificationメッセージの定義例の一部を記した図である。
【図１０】図1で定義された環境に対応して生成されるExecutionPlanTreeの全体概要の図である。
【図１１】図10で定義されたExecution Plan Treeの生成途上の状態を記した図である。
【図１２】図10で定義されたExecution Plan Treeの生成途上の状態を記した図である。
【図１３】図10で定義されたExecution Plan Treeの生成途上の状態を記した図である。
【図１４】図10で定義されたExecution Plan Treeの生成途上の状態を記した図である。
【図１５】図10で定義されたExecution Plan Treeの生成途上の状態を記した図である。
【図１６】図1で定義された環境に対応して生成されるExecutionPlanTreeの送信側のアドレス上の関係を定義した図である。
【図１７】本発明の第１の実施の形態のブロック図である。
【発明を実施するための形態】
【００１６】
［第１の実施の形態］
図１７を参照すると、本発明の第１の実施の形態に係る計算機システム1000は、複数の計算機1100と、計算機1100どうしを通信可能に接続するLAN,WAN,インターネット等のネットワーク1400とから構成されている。各計算機1100は、CPU、ROM、RAM、大容量メモリ（例えば磁気ディスクや光ディスク）、ユーザインタフェース（例えばキーボード、ディスプレイ、プリンタ）、通信ポートを備えたパーソナルコンピュータ等のコンピュータで構成されている。
【００１７】
ロングライブトランザクションの実行に関連し、複数の計算機1100には複数の機能1200が分散して設けられている。１台の計算機1100に設けられる１以上の機能1200は、ロングライブトランザクションの要求元となる１以上のトランザクション要求アプリケーション機能、サービスの提供元となる１以上のサービス提供機能、トランザクション要求アプリケーション機能とサービス提供機能との間に位置してサービスを仲介する１以上のサービス仲介機能の何れか１つまたは複数である。また、何れかの計算機1100に、ロングライブトランザクションの実行を管理するモニタ手段1300が配置されている。
【００１８】
或るロングライブトランザクションは、任意の１つのトランザクション要求アプリケーション機能、１以上のサービス提供機能、１以上のサービス仲介機能を組み合わせて実現される。或るロングライブトランザクションを構成する当該１つのトランザクション要求アプリケーションが、配下の１以上のサービス仲介機能に対してロングライブトランザクション実施要求を送出し、この１以上のサービス仲介機能が配下の１以上のサービス提供機能、もしくは１以上のサービス仲介機能に対してトランザクション実施要求を送出し、これを受けた１以上のサービス提供機能がサービスの提供を行うといった機能間の連鎖によって、ロングライブトランザクションの実行が行われる。このロングライブトランザクションの実行を行う段階を、実行相と呼ぶ。
【００１９】
本発明のロングライブトランザクションの実行管理プロトコルでは、実行相は、無条件で開始できるわけではなく、その直前に、準備相と呼ぶ段階を経る必要がある。
【００２０】
準備相では、或るロングライブトランザクションを実現する任意の１つのトランザクション要求アプリケーション機能は、自機能と呼出し先の機能との関係や補償トランザクションの方式などを記述したトランザクション定義通知メッセージをモニタ手段1300に送信すると共に、自機能から呼び出す全てのサービス仲介機能に対して準備要求メッセージを送信する。準備要求メッセージを受信した１以上のサービス仲介機能は、自機能と呼出し先の機能との関係や補償トランザクションの方式などを記述したトランザクション定義通知メッセージをモニタ手段1300に送信すると共に、自機能から呼び出す全てのサービス提供機能もしくはサービス仲介機能に対して準備要求メッセージを送信する。準備要求メッセージを受信した１以上のサービス提供機能もしくは１以上のサービス仲介機能は、自機能と呼出し先の機能との関係や補償トランザクションの方式などを記述したトランザクション定義通知メッセージをモニタ手段1300に送信する。モニタ手段1300は、ロングライブトランザクションを実現する当該トランザクション要求アプリケーション機能、１以上のサービス提供機能、１以上のサービス仲介機能から送信されるロングライブトランザクション定義通知メッセージを受信して解析する。モニタ手段1300は、受信した全てのロングライブトランザクション定義通知メッセージの解析結果に基づいて、当該ロングライブトランザクションのインスタンスの実施直前の呼出関係に基づく実行計画を生成する。そして、モニタ手段1300は、生成した実行計画の検証を行い、その検証結果を当該ロングライブトランザクションのインスタンスのトランザクション要求アプリケーション機能に通知する。
【００２１】
トランザクション要求アプリケーション機能は、通知された検証結果に応じて、実行相の実行可否を決定する。若し、補償トランザクションが用意されていない等、実行計画に不備が存在することが発見され、その旨の検証結果がモニタ手段1300からトランザクション要求アプリケーション機能に通知されたのであるならば、トランザクション要求アプリケーション機能は、実行相の実行を取りやめる。
【００２２】
本実施の形態によれば、回復不可能な致命的な障害を引き起こす可能性の高いロングライブトランザクションの実行を未然に防止することができる。その理由は、ロングライブトランザクションのインスタンスを実施する直前に、モニタ手段1300は、各機能1200から送信されるロングライブトランザクション定義通知メッセージを受信解析して、ロングライブトランザクションのインスタンスの実施直前の呼出関係に基づく実行計画を生成し、この生成した実行計画の検証を行って、その検証結果をロングライブトランザクションのインスタンスのトランザクション要求アプリケーション機能に通知し、トランザクション要求アプリケーション機能は、通知された検証結果に応じて、ロングライブトランザクションのインスタンスの実行可否を決定するためである。
【００２３】
従って、プログラマーのチェック漏れやデバッグ漏れにより、ロングライブトランザクションを構成する個々の機能1200に補償トランザクションが用意されていないといった不備があった場合に、そのことが実施直前の実行計画の検証によって発見され、補償トランザクションが不完全な状態でロングライブトランザクションの実行が開始され、システムに致命的な影響を与えることを防止することができる。
【００２４】
また、ロングライブトランザクションの構築手法として、公開されている多種多様なサービス提供機能を適宜組み合わせて、新たなサービスを提供するロングライブトランザクションを構築するマッシュアップ技法という手法が考えられる。このような手法は、新規なサービスを実現するロングライブトランザクションを簡易かつ迅速に作成できる利点を有する反面、作成されたロングライブトランザクションに、特許文献２等に記載される標準のフレームワークに則ったサービス提供機能以外のものが含まれる可能性があるため、その信頼性は保証されない。このような場合、本実施の形態によれば、実施直前の準備相による検証によって、信頼性の疑われるロングライブトランザクションの実行を未然に防止することができる。
【００２５】
［第２の実施の形態］
本発明である準動的に決定されるロングライブトランザクションのモニタリング・管理方法、並びにそのプロトコルを実現する基本的な環境の一実施例について、図1、図10、図16を用いて説明する。ここで、準動的とは、明確な定義情報を持たず、実施直前にその内容を把握するものを意味し、実施段階で判断する”動的”とは異なる。
【００２６】
この実施例では１以上のトランザクション要求アプリケーション機能(Transaction Requestor)、１つ以上のサービス仲介機能(Broker)、１つ以上のサービス提供機能(Terminator)から構成され、ロングライブトランザクションの実施状況を管理する１つのロングライブトランザクションモニタ(Long Live Transaction Monitor)を含む。
【００２７】
図1では、１つのトランザクション要求アプリケーション機能(Transaction Requestor)10が、サービス仲介機能(Broker.1)12、並びにサービス仲介機能(Broker.2)16を呼び出す。当該サービス仲介機能(Broker.2)16が、サービス仲介機能(Broker.2.1)20、並びにサービス仲介機能(Broker.2.2)24を呼び出す。サービス仲介機能(Broker.1)12が、サービス提供機能(Terminator.1)28、並びにサービス提供機能(Terminator.2)34を呼び出す。サービス仲介機能(Broker.2.1)20が、サービス提供機能(Terminator.3)40を呼び出すと共に、サービス仲介機能(Broker.2.2)24が、サービス提供機能(Terminator.4)46を呼び出す。
【００２８】
これらの機能構成要素間の関係は、トランザクション実行範囲(Scope of Transaction Execution)9として認識される。
【００２９】
ロングライブトランザクションモニタ(Long Live Transaction Monitor)1には、ロングライブトランザクションの個々のインスタンスに付番するトランザクション識別子管理機能(Transaction Identifier Manager)2、当該ロングライブトランザクションのインスタンスの実行計画を管理する実行計画管理機能(Execution Plan Manager)3が含まれる。
【００３０】
更に当該ロングライブトランザクションモニタ(Long Live Transaction Monitor)1には、当該実行計画管理機能(Execution Plan Manager)3の生成する各種情報を検証する検証実施機能(Validation Executor)7並びに、当該実行計画管理機能(Execution Plan Manager)3の生成する各種情報を管理するメタデータ管理(Meta Data Management)5も含まれる。
【００３１】
更に当該ロングライブトランザクションモニタ(Long Live Transaction Monitor)1には、当該ロングライブトランザクションのインスタンスの実行状況を把握管理する実施モニタ機能(Execution Monitor)8並びに、当該ロングライブトランザクションのインスタンスの実行状況に関する実行履歴を管理するプロセスデータ管理(Process Data Management)6も含まれる。
【００３２】
実行計画管理機能(Execution Plan Manager)3には、当該環境に対応して生成されるExecutionPlanTreeのインスタンス4が含まれる。
【００３３】
サービス提供機能(Terminator)は、サービス提供を行なうため通信機能を提供するアプリケーションサーバ機能(Application Server)、データを管理するデータベース管理機能(DBMS)、当該データベース管理機能(DBMS)のアクセス結果を記録するログ管理機能(logging)、ロングライブトランザクションに関する通信機能を提供すると共に当該ロングライブトランザクションの実行制御を行なう組込みコーディネータ機能(Sub-coordinator)、実際のサービス機能を提供するアプリケーション機能(Application)を含んでモデル化される。
【００３４】
具体的には、サービス提供機能(Terminator.1)28は、アプリケーションサーバ機能(Application Server)29、データベース管理機能(DBMS)31、ログ管理機能(logging)32、組込みコーディネータ機能(Sub-coordinator)33、アプリケーション機能(Application)30を含んで構成される。
【００３５】
更に、サービス提供機能(Terminator.2)34は、アプリケーションサーバ機能(Application Server)35、データベース管理機能(DBMS)37、ログ管理機能(logging)38、組込みコーディネータ機能(Sub-coordinator)39、アプリケーション機能(Application)36を含んで構成される。
【００３６】
更に、サービス提供機能(Terminator.3)40は、アプリケーションサーバ機能(Application Server)41、データベース管理機能(DBMS)43、ログ管理機能(logging)44、組込みコーディネータ機能(Sub-coordinator)45、アプリケーション機能(Application)42を含んで構成される。
【００３７】
更に、サービス提供機能(Terminator.4)46は、アプリケーションサーバ機能(Application Server)47、データベース管理機能(DBMS)49、ログ管理機能(logging)50、組込みコーディネータ機能(Sub-coordinator)51、アプリケーション機能(Application)48を含んで構成される。
【００３８】
サービス仲介機能(Broker)には、ロングライブトランザクションに関する通信機能を提供すると共に当該ロングライブトランザクションの実行制御を行なう組込みコーディネータ機能(Sub-coordinator)を含んでモデル化される。特に、この組込みコーディネータ機能(Sub-coordinator)には、アプリケーションサーバ機能(Application Server)が提供するサービス提供を行なうため通信機能も含まれることを想定する。また、サービス仲介機能(Broker)には、データを管理するデータベース管理機能(DBMS)、当該データベース管理機能(DBMS)のアクセス結果を記録するログ管理機能(logging)が含まれることもある。
【００３９】
具体的には、サービス仲介機能(Broker.1)12には、組込みコーディネータ機能(Sub-coordinator)13を含むと共に、データベース管理機能(DBMS)14、ログ管理機能(logging)15を含んで構成される。
【００４０】
更に、サービス仲介機能(Broker.2)16には、組込みコーディネータ機能(Sub-coordinator)17を含むと共に、データベース管理機能(DBMS)18、ログ管理機能(logging)19を含んで構成される。
【００４１】
更に、サービス仲介機能(Broker.2.1)20には、組込みコーディネータ機能(Sub-coordinator)21を含むと共に、データベース管理機能(DBMS)22、ログ管理機能(logging)23を含んで構成される。
【００４２】
更に、サービス仲介機能(Broker.2.2)24には、組込みコーディネータ機能(Sub-coordinator)25を含むと共に、データベース管理機能(DBMS)26、ログ管理機能(logging)27を含んで構成される。
【００４３】
最後にトランザクション要求アプリケーション機能(Transaction Requestor)10には、前述のサービス仲介機能(Broker.1)12等を呼び出し可能とするために、当該ロングライブトランザクションの実行制御を行なうコーディネータ呼び出し機能(Coordination Library)11を組み込んで構成する。
【００４４】
図1で定義された環境において実施されるロングライブトランザクション方式による分散トランザクション処理の一部概要をモニタリング・管理方法を実現する機能を含めてシーケンス図で記すと、図2の様になる。
【００４５】
当該分散トランザクション処理は、３つの部分から構成される。あるロングライブトランザクションのインスタンスの実行直前に、当該ロングライブトランザクションの実行する直前の実施計画情報を収集し、Execution Plan Treeのインスタンス4を生成する[Step.1]準備相91、当該ロングライブトランザクションの実行を実施する[Step.2]実行相52、当該ロングライブトランザクションの実行の結果、一部に不具合等が存在した上、その対策により実行される補償トランザクションの実行の結果、更に不具合が発生したため当該ロングライブトランザクションの状態に不整合が残存しており、是正を行なう処理を含む[Step.3]調整相53により構成される。
【００４６】
[Step.1]準備相91についての具体的手順、並びに[Step.2]実行相52についての具体的手順、並びに[Step.3]調整相53についての具体的手順については、［動作の説明］の節にて後述する。
【００４７】
図１の環境に対応して実行計画管理機能(Execution Plan Manager)3に生成・維持されるExecution Plan Treeのインスタンス4の構成について図10で説明する。
【００４８】
これは、トランザクション要求アプリケーション機能(Transaction Requestor)10、サービス仲介機能(Broker.1)12、サービス仲介機能(Broker.2)16、サービス仲介機能(Broker.2.1)20、サービス仲介機能(Broker.2.2)24、サービス提供機能(Terminator.1)28、サービス提供機能(Terminator.2)34、サービス提供機能(Terminator.3)40、サービス提供機能(Terminator.4)46間の呼び出し関係をグラフでモデル化したものである。
【００４９】
図10では、楕円で表現されるノードは各機能を表す。特に二重線楕円で表現されるノードは、前述の末端のサービス提供機能(Terminator)に相当する。
【００５０】
前述の末端のサービス提供機能(Terminator)には２種類のものが存在する。一つは通常のサービス提供をするものであり、「Terminator」のラベルで識別される。もう一つは、補償トランザクション相当のサービス提供をするものであり、「Compensation」のラベルで識別される。
【００５１】
また当該末端のサービス提供機能(Terminator)の粒度は、通常、起動インスタンス毎に定義される。
【００５２】
このため、例えば、サービス仲介機能(Broker.1)12が、サービス提供機能(Terminator.1)28、サービス提供機能(Terminator.2)34を、条件分岐で選択的に呼び出す場合、サービス提供機能(Terminator.1)28とサービス提供機能(Terminator.2)34は別のものとして扱われる。もしくはLoop処理により繰り返し呼び出す場合、サービス提供機能(Terminator.1)28の繰り返し呼び出しは別のものとして扱われる。当該に基づき、当該Execution Plan Treeのインスタンス4は構成される。これを"Execution Plan Treeのインスタンスの個別化作成制約"と呼ぶ。
【００５３】
尚、図10をはじめとする全ての図は実施例の本質的部分の説明を行うため、当該条件分岐で選択的に呼び出す場合、もしくは当該Loop処理により繰り返し呼び出す場合については省略して記す。
【００５４】
当該ノードの２つを結ぶ矢印は、ロングライブトランザクションの呼び出し関係を表す。更に当該ノードの２つを結ぶ当該矢印を囲む点線の丸角四角は、分散トランザクション処理の一部である[Step.1]準備相91で利用されるlLTransactionDefinition  Notificationメッセージで記述される範囲を意味する。
【００５５】
ノード1001は、トランザクション要求アプリケーション機能(Transaction Requestor)10を意味する。
【００５６】
ノード1002は、サービス仲介機能(Broker.1)12を意味する。ノード1003は、サービス仲介機能(Broker.2)16を意味する。ノード1004は、サービス仲介機能(Broker.2.1)20を意味する。ノード1005は、サービス仲介機能(Broker.2.2)24を意味する。
【００５７】
ノード1006は、サービス提供機能(Terminator.1)28を意味する。ノード1008は、サービス提供機能(Terminator.2)34を意味する。ノード1010は、サービス提供機能(Terminator.3)40を意味する。ノード1012は、サービス提供機能(Terminator.4)46を意味する。
【００５８】
ノード1007は、サービス提供機能(Terminator.1)28に連携した補償トランザクション相当のサービス提供であり、当該ノード1007はノード1006と対応関係1060で連結される。
【００５９】
ノード1009は、サービス提供機能(Terminator.2)34に連携した補償トランザクション相当のサービス提供であり、当該ノード1009はノード1008と対応関係1061で連結される。
【００６０】
ノード1011は、サービス提供機能(Terminator.3)40に連携した補償トランザクション相当のサービス提供であり、当該ノード1011はノード1010と対応関係1062で連結される。
【００６１】
ノード1013は、サービス提供機能(Terminator.4)46に連携した補償トランザクション相当のサービス提供であり、当該ノード1013はノード1012と対応関係1063で連結される。
【００６２】
図10においてノード1011は、点線で表現されている。これは開示されない条件が指定された場合を意味する。具体的には、図8で記されるlLTransaction  DefinitionNotificationメッセージの記述である「disclosable」が「hide」の場合にその様に処理される。
【００６３】
これに対して、図10においてノード1012、ノード1013も、点線で表現されている。これは図8で記されるlLTransactionDefinitionNotificationメッセージがサービス提供機能(Terminator.4)46から提供されない場合に、その様に処理される。
【００６４】
ノード1001とノード1002の一部を含み、ノード1001とノード1002を連結する矢印1015を含んで定義される丸角四角領域1014は、トランザクション要求アプリケーション機能(Transaction Requestor)10から送信される図8で定義される形式であるlLTransactionDefinitionNotificationメッセージ502内のelementalRelationの一情報に基づき記載されるデータから指定されるものである。
【００６５】
当該矢印1015は、トランザクション要求アプリケーション機能(Transaction Requestor)10が、サービス仲介機能(Broker.1)12を呼び出すことを意味する。
【００６６】
ノード1001とノード1003の一部を含み、ノード1001とノード1003を連結する矢印1017を含んで定義される丸角四角領域1016は、トランザクション要求アプリケーション機能(Transaction Requestor)10から送信される図8で定義される形式であるlLTransactionDefinitionNotificationメッセージ502内のelementalRelationの、丸角四角領域1014相当のものとは異なる一情報に基づき記載されるデータから指定されるものである。
【００６７】
当該矢印1017は、トランザクション要求アプリケーション機能(Transaction Requestor)10が、サービス仲介機能(Broker.2)16を呼び出すことを意味する。
【００６８】
ノード1002とノード1006の一部を含み、ノード1002とノード1006を連結する矢印1018を含んで定義される丸角四角領域1019は、サービス仲介機能(Broker.1) 12から送信される図8で定義される形式であるlLTransactionDefinitionNotificationメッセージ506内のelementalRelationの一情報に基づき記載されるデータから指定されるものである。
【００６９】
当該矢印1018は、サービス仲介機能(Broker.1)12がサービス提供機能(Terminator.1)28を呼び出すことを意味する。
【００７０】
ノード1002とノード1007の一部を含み、ノード1002とノード1007を連結する矢印1021を含んで定義される丸角四角領域1020は、サービス仲介機能(Broker.1) 12から送信される図8で定義される形式であるlLTransactionDefinitionNotificationメッセージ506内のelementalRelationの一情報に基づき記載される補償動作に関するデータから指定されるものである。
【００７１】
当該矢印1021は、サービス仲介機能(Broker.1)12がサービス提供機能(Terminator.1)28に付属する補償トランザクションに関するサービスを呼び出すことを意味する。
【００７２】
ノード1002においては、丸角四角領域1014、並びに丸角四角領域1019、もしくは丸角四角領域1014、並びに丸角四角領域1020を連結する場合、その関係である連結関係1046が指定される。当該連結関係1046においては、サービス仲介機能(Broker.1)12が送信側になる場合と受信側になる場合でアクセス先が異なる故、当該連結関係1046を生成する場合は特別な対応が必要となる。
【００７３】
図16では、Execution Plan Treeの送信側のアドレス上の関係を定義した図であり、送信側と受信側の対応関係上の課題を模式化したものである。
【００７４】
図16では２つの機能間でメッセージの送受信する場合を想定する。機能73、並びに機能70は、サービス仲介機能(Broker)、若しくはサービス提供機能(Terminator)の何れかである。
【００７５】
当該機能73はトランザクション要求アプリケーション機能(Transaction Requestor)に成り得るアプリケーション機能(Application)74、並びにアプリケーションサーバ機能(Application Server)75により構成される。
【００７６】
当該機能70はアプリケーション機能(Application)71、並びにアプリケーションサーバ機能(Application Server)72により構成される。
【００７７】
アプリケーション機能(Application)74が送信側になる場合、アプリケーションサーバ機能(Application Server)75を介して、機能70の受信側WSDL(Web Service Description Language)86を指定して、任意形式のTransactionRequestメッセージ76が送信される。当該TransactionRequestメッセージ76に対して、概ねの場合、機能70側からは該当形式のAcknowledgementメッセージ77が返信されることになる。但し、返信されない場合もある。
【００７８】
その後、機能70では、受信側WSDL(Web Service Description Language)86を介して、TransactionRequestメッセージ76を受信すると、概ねの場合、非同期でアプリケーション機能(Application)71の処理を実施し、その応答を前述の送信側の機能73に戻すことになる。
【００７９】
アプリケーション機能(Application)71が送信側になる場合、アプリケーションサーバ機能(Application Server)72を介して、機能73の受信側WSDL(Web Service Description Language)87を指定して、対応形式のTransactionResponseメッセージ78を送信する。当該TransactionResponseメッセージ78に対して、概ねの場合、機能73側からはAcknowledgementメッセージ79が返信される。但し、返信されない場合もある。
【００８０】
受信側WSDL(Web Service Description Language)87が指定されると、該当するアプリケーション機能(Application)74が指定される。このため、受信側WSDL(Web Service Description Language)87には対応関係84が指定されていると考えることが出来る。
【００８１】
ここで、受信側WSDL(Web Service Description Language)86に対して、送信するアプリケーション機能(Application)74の送信側のアドレスは必ずしも開示されるものとは限らず、実装に応じて変わる可能性がある。そこで当該機能73が受信側と送信側とで同一である旨を明確化させる必要がある。
【００８２】
以上の目的で、lLTransactionDefinitionNotificationメッセージ形式の中に、その関係を指定する部分が存在する。lLTransactionDefinitionNotificationメッセージのインスタンス81には、送信側のApplication名である、<sourceDescriptionList>のタグ83が指定される。これにより例えば、受信側WSDL(Web Service Description Language)86に向けて送信するアプリケーション機能(Application)74とその送信側アドレスの対応関係85が指定されることになる。
【００８３】
実際に送信する場合は、当該lLTransactionDefinitionNotificationメッセージ形式の中に、<elementRelation>のタグ内の<sourcePoint>タグ82を記述することになる。これにより、前述の対応関係85からアプリケーション機能(Application)74を特定することが可能となる。
【００８４】
受信側WSDL(Web Service Description Language)86については、同様に当該lLTransactionDefinitionNotificationメッセージ形式の中の<destinationPoint>タグ80にて指定される。これは他の受信側WSDL(Web Service Description Language)87についても同様であるが、異なるインスタンスによって実施される。
【００８５】
以上により、受信側WSDL(Web Service Description Language)、アプリケーション機能、送信側アドレス間の対応関係を把握することが可能となる。以上により、図10における連結関係1046を特定することが可能である。
【００８６】
ノード1006を含んで定義される丸角四角領域1030は、サービス提供機能(Terminator.1)28から送信される図8で定義される形式であるlLTransactionDefinitionNotificationメッセージ512内のelementalRelationの一情報に基づき記載されるデータから指定されるものである。
【００８７】
ノード1006においては、丸角四角領域1019、並びに丸角四角領域1030を連結する場合、その関係である連結関係1050が指定される。サービス提供機能(Terminator.1)28においては同期通信、非同期通信のいずれかで処理されることになる。ここでは送信側、受信側での扱いは曖昧であるが、トランザクションの末端であるため、当該連結関係1050に基づき、対応を行う。
【００８８】
ノード1007を含んで定義される丸角四角領域1031は、サービス提供機能(Terminator.1)28から送信される図8で定義される形式であるlLTransactionDefinitionNotificationメッセージ512内のelementalRelationのノード1006と関連する情報に基づき記載されるデータから指定されるものである。
【００８９】
ノード1007においては丸角四角領域1020、並びに丸角四角領域1031を連結する場合、その関係である連結関係1051が指定される。サービス提供機能(Terminator.1)28においては、サービス提供機能(Terminator.1)28に関係した補償トランザクション相当のサービス提供は同期通信、非同期通信のいずれかで処理されることになる。ここでは送信側、受信側での扱いは曖昧であるが、トランザクションの末端であるため、当該連結関係1051に基づき対応付けを行う。
【００９０】
前述の通り、ノード1007は、サービス提供機能(Terminator.1)28に関係した補償トランザクション相当のサービス提供であり、当該ノード1007はノード1006と対応関係1060で対応付けを行う必要がある。このために、図8で定義される形式であるlLTransactionDefinitionNotificationメッセージ512内のelemental Relationでは、「destinationPoint」に１対１対応する形で「compensationPoint」が指定される。
【００９１】
ノード1002、ノード1006、ノード1007、並びに丸角四角領域1019、丸角四角領域1020、丸角四角領域1030、丸角四角領域1031、連結関係1046、連結関係1050、連結関係1051、対応関係1060の構成する関係については、ノード1002、ノード1008、ノード1009、並びに丸角四角領域1023、丸角四角領域1025、丸角四角領域1032、丸角四角領域1033の関係する矢印1022、矢印1024、連結関係1047、連結関係1052、連結関係1053、対応関係1061にも同等に適用される。ここでは同等であるため、説明を省略する。
【００９２】
更にノード1001、ノード1002、ノード1006、ノード1007、ノード1008、ノード1009、並びに丸角四角領域1014、丸角四角領域1019、丸角四角領域1020、丸角四角領域1030、丸角四角領域1031、丸角四角領域1023、丸角四角領域1025、丸角四角領域1032、丸角四角領域1033、並びに矢印1015、丸角四角領域1023、丸角四角領域1025、丸角四角領域1032、丸角四角領域1033の関係する矢印1022、矢印1024、連結関係1047、連結関係1052、連結関係1053、対応関係1061、並びに丸角四角領域1019、丸角四角領域1020、丸角四角領域1030、丸角四角領域1031の関係する矢印1018、矢印1021、連結関係1046、連結関係1050、連結関係1051、対応関係1060の構成する関係については、ノード1001、ノード1003、ノード1004、ノード1005、ノード1010、ノード1011、ノード1012、ノード1013、並びに丸角四角領域1016、丸角四角領域1026、丸角四角領域1028、丸角四角領域1034、丸角四角領域1036、丸角四角領域1038、丸角四角領域1040、丸角四角領域1042、丸角四角領域1043、丸角四角領域1044、丸角四角領域1045の関係する矢印1017、矢印1027、矢印1029、矢印1035、矢印1037、矢印1039、矢印1041、連結関係1048、連結関係1049、連結関係1054、連結関係1055、連結関係1056、連結関係1057、連結関係1058、連結関係1059、対応関係1062、対応関係1063にも同等に適用される。
【００９３】
但し、ノード1001、ノード1002、ノード1006、ノード1007、ノード1008、ノード1009、並びに丸角四角領域1014、丸角四角領域1019、丸角四角領域1020、丸角四角領域1030、丸角四角領域1031、丸角四角領域1023、丸角四角領域1024、丸角四角領域1032、丸角四角領域1033の構成する関係に対して、ノード1001、ノード1003、ノード1004、ノード1005、ノード1010、ノード1011、ノード1012、ノード1013、並びに丸角四角領域1016、丸角四角領域1026、丸角四角領域1028、丸角四角領域1034、丸角四角領域1036、丸角四角領域1038、丸角四角領域1040、丸角四角領域1042、丸角四角領域1043、丸角四角領域1044、丸角四角領域1045の構成する関係については、３段構成であり、この点は異なる。
【００９４】
更に前述の通り、図10においてノード1011は、点線で表現されている。これは開示されない条件が指定された場合を意味し、図8で記されるlLTransaction DefinitionNotificationメッセージの記述である「disclosable」が「hide」の場合にその様に処理される。更に前述の通り、図10においてノード1012、ノード1013も、点線で表現されている。これは図8で記されるlLTransaction DefinitionNotificationメッセージがサービス提供機能(Terminator.4)46から提供されない場合を意味する。
【００９５】
図1における各種の信号は、図3、図4、図5、図6と重複する部分があるため、［動作の説明］の節にて説明する。
【００９６】
［動作の説明］
前述の様に、図2は当該ロングライブトランザクション方式による分散トランザクション処理の一部概要をシーケンス図にて記したものであり、[Step.1]準備相91、[Step.2]実行相52、[Step.3]調整相53を含んで構成される。
【００９７】
前述の様に、当該[Step.1]準備相91は、あるロングライブトランザクションのインスタンスの実行直前に、当該ロングライブトランザクションの実施計画情報を収集し、Execution Plan Treeのインスタンス4を生成するための手順である。
【００９８】
これに対して、[Step.2]実行相52は、ロングライブトランザクションの実行をする手順である。
【００９９】
最後に、[Step.3]調整相53は、ロングライブトランザクションの実行の結果、一部に不具合等が存在した上、その対策処理として起動される補償トランザクションの実行に於いても、不具合が発生したため当該ロングライブトランザクションの状態に不整合が存在しており、是正を行なうための処理手順である。[Step.1]準備相91の結果に応じて、[Step.2]実行相52、[Step.3]調整相53の実行に影響を与えるが、当該事項は後述する。
【０１００】
[Step.1]準備相91は、トランザクション要求アプリケーション機能(Transaction Requestor)10が、本方式によりトランザクションを開始する場合、トランザクション識別子を登録するための［Step.1.1］LLトランザクション開始要求処理200、続けてトランザクション要求アプリケーション機能(Transaction Requestor)10がlLTransactionDefinitionNotificationメッセージ502を転送する［Step.1.2］LLトランザクション定義通知処理201を含んで構成される。
【０１０１】
更に[Step.1]準備相91は、当該［Step.1.2］LLトランザクション定義通知処理201の後続処理として、配下の関連ノードにロングライブトランザクションの実行のため、準備を要求する準備要求処理202、204、205、続けてロングライブトランザクションモニタ(Long Live Transaction Monitor)1内の実行計画管理機能(Execution Plan Manager)3にLLトランザクション定義通知を行う処理203、206、207、続けて定義検査処理208を行う［Step.1.3］の処理群も含む。
【０１０２】
更に[Step.1]準備相91は、当該［Step.1.3］処理群の後続として、実行計画管理機能(Execution Plan Manager)3内で構成されるExecution Plan Treeのインスタンス4が妥当か、否かを通知する［Step.1.4］LLトランザクション検索結果通知処理209をも含む。
【０１０３】
これに対して[Step.2]実行相52は、本方式により分散トランザクション処理を開始する場合の[Step.2.1]の処理群として、LLトランザクション実施要求処理210、その後続として１フェーズコミットメントトランザクション実施要求・処理実施211、212、当該LLトランザクション実施要求処理210、並びに当該１フェーズコミットメントトランザクション実施要求・処理実施211、212の後続処理としてトランザクションEvent通知処理213、214、215を含む。
【０１０４】
また、当該トランザクションEvent通知処理213、214、215の実施状況を確認する検査処理218、トランザクション要求アプリケーション機能(Transaction Requestor)10に実施結果を通知する結果応答処理219も含む。
【０１０５】
更に、１フェーズコミットメントトランザクション実施要求・処理実施211、もしくは212のいずれかが失敗したため、成功したものを実施前の状況に戻す補償トランザクション処理実施216、当該補償トランザクション処理実施216の後続としてトランザクションEvent通知処理217を含む。
【０１０６】
最後に[Step.3]調整相53では、当該トランザクションEvent通知処理217の実施状況を確認する[Step.3.1]検査処理・抽出221を含み、当該検査処理の結果を受けて、必要な場合に[Step.3.2]再補償要求処理220を含む。
【０１０７】
更に[Step.3]調整相53では、前述の[Step.3.1]検査処理・抽出221で検出した補償トランザクション処理実施の失敗を是正するため、[Step.3.2]再補償要求処理220により起動される［Step.3.2］補償トランザクション処理実施222、当該補償トランザクション処理実施222の後続として[Step.3.2]トランザクションEvent通知処理223を含む。その上で、当該[Step.3.2]トランザクションEvent通知処理223の実施状況を確認する[Step.3.2]検査処理224をも含む。
【０１０８】
最後に、[Step.3]調整相53では、トランザクション要求アプリケーション機能(Transaction Requestor)10に補償に関する実施結果を通知する[Step.3.3]トランザクション補償状況報告処理225も含む。
【０１０９】
次に図3を用いて、[Step.1]準備相91の処理を、手順に従い、詳細に説明する。
【０１１０】
［Step.1.1］LLトランザクション開始要求処理200は、図3においては[Step.1.1.1]  lLTransactionStartRequestメッセージ500の送信、並びに[Step.1.1.2]Returnメッセージ501の返信の２つに分解される。
【０１１１】
また、［Step.1.2］LLトランザクション定義通知処理201は、図3においては[Step.1.2.1]lLTransactionDefinitionNotificationメッセージ502の送信、[Step.1.2.2]  Createコマンド503の実施、[Step.1.2.3]Returnメッセージ504の返信の３つに分解される。
【０１１２】
［Step.1.3］準備要求処理202は、図3においては[Step1.3.1]lLTransaction  PrepareRequestメッセージ505の送信と、[Step.1.3.18]Returnメッセージ525の返信に分解される。
【０１１３】
［Step.1.3］準備要求処理204は、図3においては[Step1.3.6]lLTransaction  PrepareRequestメッセージ511の送信と、[Step.1.3.11]Returnメッセージ517の返信に分解される。
【０１１４】
［Step.1.3］準備要求処理205は、図3においては[Step1.3.12]lLTransaction  PrepareRequestメッセージ518の送信と、[Step.1.3.17]Returnメッセージ524の返信に分解される。
【０１１５】
［Step.1.3］LLトランザクション定義通知処理203は、図3においては[Step1.3.2]lLTransaction  DefinitionNotificationメッセージ506の送信、[Step1.3.3]Addコマンド507の実施、[Step1.3.4]Returnメッセージ508の返信の３つに分解される。
【０１１６】
［Step.1.3］LLトランザクション定義通知処理206は、図3においては[Step1.3.7]lLTransaction  DefinitionNotificationメッセージ512の送信、[Step1.3.8]Addコマンド513の実施、[Step1.3.9]Returnメッセージ514の返信の３つに分解される。
【０１１７】
［Step.1.3］LLトランザクション定義通知処理207は、図3においては[Step1.3.13]lLTransaction  DefinitionNotificationメッセージ519の送信、[Step1.3.14]Addコマンド520の実施、[Step1.3.15]Returnメッセージ521の返信の３つに分解される。
【０１１８】
［Step.1.3］定義検査処理208は、図3においては[Step1.3.5]Verification要求コマンド509の実施、[Step1.3.5]Verification実行コマンド510の実施、[Step1.3.10]Verification要求コマンド515の実施、[Step1.3.10]Verification実行コマンド516の実施、[Step1.3.16]Verification要求コマンド522の実施、[Step1.3.16]Verification実行コマンド523の実施の６つに分解される。
【０１１９】
［Step.1.4］LLトランザクション検索結果通知処理209は、図3においては[Step1.4.1]lLTransactionReportメッセージ526の送信に対応する。
【０１２０】
続けて、図3に記した[Step.1]準備相91の処理手順を説明する。図3はフローチャート図で記した手順ではなく、且つ、図１の構成図に依存するが、本方式の特徴を失う訳ではないため、フローチャート図を用いることなく、シーケンス図形式の図3にて処理手順を説明する。
【０１２１】
本方式により分散トランザクション処理を開始する場合、トランザクション要求アプリケーション機能(Transaction Requestor)10は、当該機能に埋め込まれているコーディネータ呼び出し機能(Coordination Library)11のインスタンス54を用いて処理を実施する。
【０１２２】
更にロングライブトランザクションモニタ(Long Live Transaction Monitor)1に含まれるトランザクション識別子管理機能(Transaction Identifier Manager)2には、インスタンス62が常駐する。
【０１２３】
同様にロングライブトランザクションモニタ(Long Live Transaction Monitor)1に含まれる実行計画管理機能(Execution Plan Manager)3も、インスタンス64が常駐する。
【０１２４】
同様にロングライブトランザクションモニタ(Long Live Transaction Monitor)1に含まれる検証実施機能(Validation Executor)7もインスタンス63が常駐する。
【０１２５】
同様に実行計画管理機能(Execution Plan Manager)3内にもExecution Plan Treeのインスタンス4が存在するが、[Step.1]準備相91を通して、構築されるものであり、[Step.2]実行相52を通して、その状態が変化するものである。従って途中の状況のものを常駐するインスタンス65として定義する。
【０１２６】
トランザクション要求アプリケーション機能(Transaction Requestor)10が、本方式により分散トランザクション処理を開始する場合、当該機能に埋め込まれているコーディネータ呼び出し機能(Coordination Library)11のインスタンス54が、ロングライブトランザクションモニタ(Long Live Transaction Monitor)1内のトランザクション識別子管理機能(Transaction Identifier Manager)2のインスタンス62へ、lLTransaction  StartRequestメッセージ500を送信する。この手順を［Step.1.1.1］と命名する。
【０１２７】
その結果、一意性を持つトランザクション識別子が登録され、その後、インスタンス62から当該トランザクション要求アプリケーション機能(Transaction Requestor)10内のコーディネータ呼び出し機能(Coordination Library)11のインスタンス54にReturnメッセージ501が返信される。この手順を[Step.1.1.2]と命名する。
【０１２８】
その後、当該コーディネータ呼び出し機能(Coordination Library)11の当該インスタンス54により、ロングライブトランザクションモニタ(Long Live Transaction Monitor)1内の実行計画管理機能(Execution Plan Manager)3のインスタンス64にlLTransactionDefinitionNotificationメッセージ502が転送される。その際は、トランザクション識別子を含む。この手順を［Step.1.2.1］と命名する。
【０１２９】
実行計画管理機能(Execution Plan Manager)3のインスタンス64が、当該lLTransactionDefinitionNotificationメッセージ502を受信すると、Execution Plan Treeのインスタンス4を新たに構築するため、その途中状況のインスタンス65を生成するため、Createコマンド503を実施する。その結果、当該インスタンス65が生成されることになる。この手順を[Step.1.2.2]と命名する。
【０１３０】
その後、実行計画管理機能(Execution Plan Manager)3のインスタンス64は、コーディネータ呼び出し機能(Coordination Library)11のインスタンス54に対して、前述のReturnメッセージ504を返信する。この手順を[Step.1.2.3]と命名する。
【０１３１】
コーディネータ呼び出し機能(Coordination Library)11のインスタンス54は、分散トランザクション処理の実施準備に移る。このために予定しているサービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13に対してlLTransactionPrepareRequestメッセージ505を送信する。当該組込みコーディネータ機能(Sub-coordinator)13は、当該lLTransactionPrepare  Requestメッセージ505を受信すると、その分散トランザクション処理に関するトランザクション識別子を維持する組込みコーディネータ機能(Sub-coordinator)13のインスタンス55を起動する。この手順を[Step1.3.1]と命名する。
【０１３２】
組込みコーディネータ機能(Sub-coordinator)13の当該インスタンス55は、配下の任意のサービス仲介機能(Broker)、もしくは任意のサービス提供機能(Terminator)へのアクセスの前に自身の登録を行うため、実行計画管理機能(Execution Plan Manager)3のインスタンス64に対して、トランザクション識別子を引き継いだlLTransaction  DefinitionNotificationメッセージ506を送信する。この手順を[Step1.3.2]と命名する。
【０１３３】
実行計画管理機能(Execution Plan Manager)3のインスタンス64が、当該lLTransactionDefinitionNotificationメッセージ506を受信すると、構築中のExecution Plan Treeのインスタンス4に関するインスタンス65に情報を追加するため、Addコマンド507を実施する。その結果、当該インスタンス65が更新されることになる。更新は図10で説明した前述の関係を維持することになる。また、更新手順については図11、図12、図13、図14、図15を用いて後述する。この手順を[Step.1.3.3]と命名する。
【０１３４】
その後、実行計画管理機能(Execution Plan Manager)3の当該インスタンス64は、サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス55に対して、前述のReturnメッセージ508を返信する。この手順を[Step.1.3.4]と命名する。
【０１３５】
検証実施機能(Validation Executor)7のインスタンス63は常駐しており、常に構築中のExecution Plan Treeのインスタンス4に関する当該インスタンス65の情報を監視している。このため、当該インスタンス65に対してVerification要求コマンド509を発行し、図10に記されるExecution Plan Treeのインスタンス4のサブセット情報を入手する。
【０１３６】
その後、検証実施機能(Validation Executor)7のインスタンス63は当該サブセット情報に対して、Verification実行コマンド510を発行し、検証を実施する。当該検証の実施結果は、後述される手順[Step.1.4.1]にてトランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11のインスタンス54へ応答されることになる。以上の一連の手順を[Step.1.3.5]と命名する。
【０１３７】
サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス55は、予定しているサービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33に対してlLTransactionPrepareRequestメッセージ511を送信する。当該組込みコーディネータ機能(Sub-coordinator)33は、当該lLTransactionPrepareRequestメッセージ511を受信すると、その分散トランザクション処理に関するトランザクション識別子を維持する組込みコーディネータ機能(Sub-coordinator)33のインスタンス57を起動する。この手順を[Step1.3.6]と命名する。
【０１３８】
組込みコーディネータ機能(Sub-coordinator)33の当該インスタンス57は、自身の登録を行うため、実行計画管理機能(Execution Plan Manager)3のインスタンス64に対して、トランザクション識別子を引き継いだlLTransactionDefinition  Notificationメッセージ512を送信する。この手順を[Step1.3.7]と命名する。
【０１３９】
実行計画管理機能(Execution Plan Manager)3のインスタンス64が、当該lLTransactionDefinitionNotificationメッセージ512を受信すると、構築中のExecution Plan Treeのインスタンス4に関するインスタンス65に情報を追加するため、Addコマンド513を実施する。その結果、当該インスタンス65が更新されることになる。更新は図10で説明した前述の関係を維持することになる。この手順を[Step.1.3.8]と命名する。
【０１４０】
その後、実行計画管理機能(Execution Plan Manager)3の当該インスタンス64は、サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス57に対して、前述のReturnメッセージ514を返信する。この手順を[Step.1.3.9]と命名する。
【０１４１】
検証実施機能(Validation Executor)7のインスタンス63は、構築中のExecution Plan Treeのインスタンス4に関するインスタンス65に対してVerification要求コマンド515を発行し、図10に記されるExecution Plan Treeのインスタンス4のサブセット情報を入手する。
【０１４２】
その後、検証実施機能(Validation Executor)7のインスタンス63は当該サブセット情報に対して、Verification実行コマンド516を発行し、検証を実施する。当該検証の実施結果は、後述される手順[Step.1.4.1]にてトランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11のインスタンス54へ応答されることになる。以上の一連の手順を[Step.1.3.10]と命名する。
【０１４３】
サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス57が、Returnメッセージ514を受信すると、その結果をもとにサービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス55に対して、Returnメッセージ517を返信する。この手順を[Step.1.3.11]と命名する。
【０１４４】
その後、サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス55は、次に予定しているサービス提供機能(Terminator.2)34内の組込みコーディネータ機能(Sub-coordinator)39に対してlLTransactionPrepareRequestメッセージ518を送信する。当該組込みコーディネータ機能(Sub-coordinator)39は、当該lLTransactionPrepareRequestメッセージ518を受信すると、その分散トランザクション処理に関するトランザクション識別子を維持する組込みコーディネータ機能(Sub-coordinator)39のインスタンス59を起動する。この手順を[Step1.3.12]と命名する。
【０１４５】
組込みコーディネータ機能(Sub-coordinator)39の当該インスタンス59は、自身の登録を行うため、実行計画管理機能(Execution Plan Manager)3のインスタンス64に対して、トランザクション識別子を引き継いだlLTransactionDefinition  Notificationメッセージ519を送信する。この手順を[Step1.3.13]と命名する。
【０１４６】
実行計画管理機能(Execution Plan Manager)3のインスタンス64が、当該lLTransactionDefinitionNotificationメッセージ519を受信すると、構築中のExecution Plan Treeのインスタンス4に関するインスタンス65に情報を追加するため、Addコマンド520を実施する。その結果、当該インスタンス65が更新されることになる。更新は図10で説明したの関係を維持することになる。この手順を[Step.1.3.14]と命名する。
【０１４７】
その後、実行計画管理機能(Execution Plan Manager)3の当該インスタンス64は、サービス提供機能(Terminator.2)34内の組込みコーディネータ機能(Sub-coordinator)39のインスタンス59に対して、前述のReturnメッセージ521を返信する。この手順を[Step.1.3.15]と命名する。
【０１４８】
検証実施機能(Validation Executor)7のインスタンス63は、構築中のExecution Plan Treeのインスタンス4に関するインスタンス65に対してVerification要求コマンド522を発行し、図10に記されるExecution Plan Treeのインスタンス4のサブセット情報を入手する。
【０１４９】
その後、検証実施機能(Validation Executor)7のインスタンス63は、当該サブセット情報に対して、Verification実行コマンド523を発行し、検証を実施する。特に、この場合はインスタンス65の構築が完了しているか、構築中でタイムアウト等を検知し、構築が未完了となっているかも含めて検証する。当該検証の実施結果は、後述される手順[Step.1.4.1]にてトランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11のインスタンス54へ応答されることになる。以上の一連の手順を[Step.1.3.16]と命名する。
【０１５０】
サービス提供機能(Terminator.2)34内の組込みコーディネータ機能(Sub-coordinator)39のインスタンス59が、Returnメッセージ521を受信すると、その結果をもとにサービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス55に対して、Returnメッセージ524を返信する。この手順を[Step.1.3.17]と命名する。
【０１５１】
更にサービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス55がReturnメッセージ524を受信すると、それが配下の任意サービス仲介機能(Broker)、サービス提供機能(Terminator)で最後のものであることを確認した場合、その結果をもとにトランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11のインスタンス54に対して、Returnメッセージ525を返信する。この手順を[Step.1.3.18]と命名する。
【０１５２】
検証実施機能(Validation Executor)7のインスタンス63は、Execution Plan Treeのインスタンス4に関するインスタンス65を検証し、当該インスタンス65の構築が完了しているか、構築中でタイムアウト等を検知する。更に後述するようにExecution Plan Treeのインスタンス4の完成度について検証する。当該検証の実施結果は、トランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11のインスタンス54にlLTransactionReportメッセージ526で応答されることになる。以上の一連の手順を[Step.1.4.1]と命名する。
【０１５３】
その後、当該Execution Plan Treeのインスタンス4に関する当該インスタンス65は後に参照、再利用するため、図１に記された様にメタデータ管理(Meta Data Management)5に格納されることになる。そのために格納コマンド610が実施され、当該[Step.1]準備相91の処理を終える。
【０１５４】
続いて、[Step.2]実行相52の処理に移行することになる。但し、手順[Step.1.4.1]でトランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11のインスタンス54にlLTransactionReportメッセージ526で応答される検証結果によっては、当該[Step.2]実行相52が起動しない場合や、後述[Step.3]調整相53の処理内容が変化する場合も存在する。これら条件は、本節最後で説明する。
【０１５５】
次に図4、図5を用いて[Step.2]実行相52の処理を手順に従い、詳細説明する。
【０１５６】
[Step.2.1]LLトランザクション実施要求処理210は、図4、図5では、[Step.2.1.1]TransactionRequestに関するメッセージ527の送信、[Step.2.2.1]Transaction  Requestに関するメッセージ527の送信に相当する。
【０１５７】
ここで、当該TransactionRequestに関するメッセージ527は所要の任意形式である。
【０１５８】
[Step.2.1]トランザクションEvent通知処理213は、図4、図5では[Step.2.1.2]lLTransactionEventNotificationメッセージ528の送信、[Step2.1.4]Returnメッセージ531の返信、並びに[Step.2.2.2]lLTransactionEventNotificationメッセージ528の送信、[Step2.2.4]Returnメッセージ531の返信の２組の２つに分解される。
【０１５９】
[Step.2.1]１フェーズコミットメントトランザクション実施要求・処理実施211は、図4、図5では、[Step.2.1.5] TransactionRequestに関するメッセージ532の送信、[Step.2.1.6] Localの1フェーズコミットメントトランザクション実行、並びに成功533、[Step.2.1.10] Returnメッセージ538の返信、並びに[Step.2.2.5] TransactionRequestに関するメッセージ532の送信、[Step.2.2.6] Localの1フェーズコミットメントトランザクション実行、並びに成功533、[Step.2.2.10] Returnメッセージ538の返信の２組の３つに分解される。
【０１６０】
[Step.2.1]１フェーズコミットメントトランザクション実施要求・処理実施212は、図4、図5では、[Step.2.1.11]TransactionRequestに関するメッセージ539の送信、[Step.2.1.12]Localの1フェーズコミットメントトランザクション実行、並びに失敗540、[Step.2.1.16]Returnメッセージ538の返信、並びに[Step.2.2.11]TransactionRequestに関するメッセージ539の送信、[Step.2.2.12]Localの1フェーズコミットメントトランザクション実行、並びに失敗540、[Step.2.2.16] Returnメッセージ538の返信の２組の３つに分解される。
【０１６１】
[Step.2.1]トランザクションEvent通知処理214は、図4、図5では、[Step.2.１.7]lLTransaction EventNotificationメッセージ534の送信、[Step.2.１.9]Returnメッセージ537の返信、並びに[Step.2.2.7]lLTransaction EventNotificationメッセージ534の送信、[Step.2.2.9]Returnメッセージ537の返信の２組の２つに分解される。
【０１６２】
[Step.2.1]トランザクションEvent通知処理215は、図4、図5では、[Step.2.１.13]lLTransaction EventNotificationメッセージ541の送信、[Step.2.１.15]Returnメッセージ545の返信、並びに[Step.2.2.13]lLTransaction EventNotificationメッセージ541の送信、[Step.2.2.15]  Returnメッセージ545の返信の２組の２つに分解される。
【０１６３】
[Step.2.1]補償トランザクション処理実施216は、図4、図5では、[Step.2.1.17]  Compensation TransactionRequestに関するメッセージ547の送信、[Step.2.1.18]  Localの1フェーズコミットメントトランザクション実行、並びに成功548、[Step.2.1.22]Returnメッセージ553の返信、並びに[Step.2.2.17]Compensation TransactionRequestに関するメッセージ547の送信、[Step.2.2.18]Localの1フェーズコミットメントトランザクション実行、並びに失敗544、[Step.2.2.22]  Returnメッセージ556の返信の２組の３つに分解される。
【０１６４】
[Step.2.1]トランザクションEvent通知処理217は、図4、図5では、[Step.2.１.19]lLTransaction EventNotificationメッセージ549の送信、[Step.2.１.21]Returnメッセージ552の返信、並びに[Step.2.2.19]lLTransaction EventNotificationメッセージ549の送信、[Step.2.2.21]  Returnメッセージ552の返信の２組の２つに分解される。
【０１６５】
[Step.2.1]検査処理218は、図4、図5では、[Step.2.1.3]Verification要求コマンド529、[Step.2.1.3]Verification実行コマンド530、[Step.2.1.8]Verification要求コマンド535、[Step.2.1.8]Verification実行コマンド536、[Step.2.1.14]Verification要求コマンド542、[Step.2.1.14]Verification実行コマンド543、[Step.2.1.20]Verification要求コマンド550、[Step.2.1.20]Verification実行コマンド551、並びに[Step.2.2.3]Verification要求コマンド529、[Step.2.2.3]Verification実行コマンド530、[Step.2.2.8]Verification要求コマンド535、[Step.2.2.8]Verification実行コマンド536、[Step.2.2.14]Verification要求コマンド542、[Step.2.2.14]Verification実行コマンド543、[Step.2.2.20]Verification要求コマンド550、[Step.2.2.20]Verification実行コマンド551の２組の８つに分解される。
【０１６６】
[Step.2.1]結果応答処理219は、図4、図5では、[Step.2.1.23]Returnメッセージ554の返信、並びに[Step.2.2.23]Returnメッセージ557の返信に相当する。
【０１６７】
続けて図4、並びに図5に記した[Step.2]実行相52の処理手順を説明する。図4、並びに図5はフローチャート図で記した手順ではなく、且つ、図１の構成図に依存するが、本方式の特徴を失う訳ではないため、フローチャート図を用いることなく、シーケンス図形式の図4、並びに図5にて処理手順を説明する。
【０１６８】
[Step.1]準備相の手順[Step1.3.1]以下で、分散トランザクション処理の実施の準備を行っており、[Step.1]準備相におけるサービス仲介機能(Broker)、サービス提供機能(Terminator)で関係付けた順番で、この分散トランザクション処理の実施を行うことになる。
【０１６９】
この分散トランザクション処理の実施に合わせて、ロングライブトランザクションモニタ(Long Live Transaction Monitor)1に含まれる実施モニタ機能(Execution Monitor)8には、インスタンス90が起動され、常駐する。
【０１７０】
トランザクション要求アプリケーション機能(Transaction Requestor)10に埋め込まれているコーディネータ呼び出し機能(Coordination Library)11のインスタンス54は、サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13に対してTransactionRequestに関するメッセージ527を送信する。その場合、［Step.1.1.1］［Step.1.1.2］手順で入手したトランザクション識別子、並びにそのコンテキストを当該TransactionRequestに関するメッセージ527に含める。
【０１７１】
当該サービス仲介機能(Broker.1)12内の当該組込みコーディネータ機能(Sub-coordinator)13は、当該TransactionRequestに関するメッセージ527を受信すると、インスタンス55とは異なる新たなインスタンス56を新たに起動させる。この手順を図4では[Step.2.1.1]、図5では[Step.2.2.1]と命名する。
【０１７２】
組込みコーディネータ機能(Sub-coordinator)13の当該インスタンス56は、発生したイベントを報告するため、実施モニタ機能(Execution Monitor)8のインスタンス90に対して、lLTransactionEventNotificationメッセージ528を送信する。その場合、前述の［Step.1.1.1］［Step.1.1.2］手順で入手したトランザクション識別子、並びにコンテキストを当該lLTransactionEventNotificationメッセージ528に含める。この手順を図4では[Step.2.1.2]、図5では[Step.2.2.2]と命名する。
【０１７３】
実施モニタ機能(Execution Monitor)8のインスタンス90は、lLTransaction  EventNotificationメッセージ528を受信すると、当該メッセージに含まれるトランザクション識別子、並びにコンテキストを元に、参照するべきExecution Plan Treeのインスタンス4に関する状態インスタンス65を特定する。その後、当該インスタンス65に対してVerification要求コマンド529を発行し、図10に記されるExecution Plan Treeのインスタンス4のサブセット情報を入手する。
【０１７４】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は当該サブセット情報に対して、Verification実行コマンド530を発行し、履歴状況を含む整合性の検証を実施する。特に履歴状況を把握する場合は、図１で記した様にメタデータ管理(Meta Data Management)5から実施モニタ機能(Execution Monitor)8が格納されているメタデータ611を取り出した後、履歴状況検索コマンド612を発行し、関連情報613を入手する。以上の一連の手順を図4では[Step.2.1.3]、図5では[Step.2.2.3]と命名する。
【０１７５】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は、サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス56に対してReturnメッセージ531を返信する。この手順を図4では[Step.2.1.4]、図5では[Step.2.2.4]と命名する。
【０１７６】
サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-  coordinator)13のインスタンス56は、予定していたサービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33に対してTransactionRequestに関するメッセージ532を送信する。その場合、前述の［Step.1.1.1］［Step.1.1.2］手順で入手したトランザクション識別子、並びにそのコンテキストを当該TransactionRequestに関するメッセージ532に含める。この手順を図4では[Step.2.1.5]、図5では[Step.2.2.5]と命名する。
【０１７７】
当該組込みコーディネータ機能(Sub-coordinator)33は、当該TransactionRequestに関するメッセージ532を受信すると、当該トランザクション識別子を確認の上で組込みコーディネータ機能(Sub-coordinator)33のインスタンス57に関連した別インスタンス58を起動させる。その後、当該組込みコーディネータ機能(Sub-coor  dinator)33のLocalな1フェーズコミットメントトランザクションを実行し、その結果533を得る。ここでは成功したものと考える。この手順を図4では[Step.2.1.6]、図5では[Step.2.2.6]と命名する。
【０１７８】
その後、サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス58は、前述の実行、並びにその結果533を受けて、発生したイベントを報告するため、実施モニタ機能(Execution Monitor)8のインスタンス90に対して、lLTransactionEventNotificationメッセージ534を送信する。その場合、前述の［Step.1.1.1］［Step.1.1.2］手順で入手したトランザクション識別子、並びにコンテキストを当該lLTransactionEventNotificationメッセージ534に含める。この手順を図4では[Step.2.1.7]、図5では[Step.2.2.7]と命名する。
【０１７９】
実施モニタ機能(Execution Monitor)8のインスタンス90は、lLTransaction  EventNotificationメッセージ534を受信すると、当該メッセージに含まれるトランザクション識別子、並びにコンテキストを元に、参照するべきExecution Plan Treeのインスタンス4に関する状態インスタンス65を特定する。その後、当該インスタンス65に対してVerification要求コマンド535を発行し、図10に記されるExecution Plan Treeのインスタンス4のサブセット情報を入手する。
【０１８０】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は当該サブセット情報に対して、Verification実行コマンド536を発行し、履歴状況を含む整合性の検証を実施する。特に履歴状況を把握する場合は、図１で記した様にメタデータ管理(Meta Data Management)5から実施モニタ機能(Execution Monitor)8が格納されているメタデータ611を取り出した後、履歴状況検索コマンド612を発行し、関連情報613を入手する。以上の一連の手順を図4では[Step.2.1.8]、図5では[Step.2.2.8]と命名する。
【０１８１】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は、サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス58に対してReturnメッセージ537を返信する。この手順を図4では[Step.2.1.9]、図5では[Step.2.2.9]と命名する。
【０１８２】
サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス58が、Returnメッセージ537を受信すると、その結果をもとにサービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス56に対して、Returnメッセージ538を返信する。この手順を図4では[Step.2.1.10]、図5では[Step.2.2.10]と命名する。
【０１８３】
サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス56は、その後、別のサービス提供機能(Terminator.2)34内の組込みコーディネータ機能(Sub-coordinator)39に対してTransactionRequestに関するメッセージ539を送信する。その場合、前述の［Step.1.1.1］［Step.1.1.2］手順で入手したトランザクション識別子、並びにそのコンテキストを当該TransactionRequestに関するメッセージ539に含める。この手順を図4では[Step.2.1.11]、図5では[Step.2.2.11]と命名する。
【０１８４】
当該組込みコーディネータ機能(Sub-coordinator)39は、当該TransactionRequestに関するメッセージ539を受信すると、当該トランザクション識別子を確認の上で組込みコーディネータ機能(Sub-coordinator)39のインスタンス59に関連した別インスタンス60を起動させる。その後、当該組込みコーディネータ機能(Sub-coor  dinator)39のLocalな1フェーズコミットメントトランザクションを実行し、その結果540を得る。ここでは失敗したものと考える。この手順を図4では[Step.2.1.12]、図5では[Step.2.2.12]と命名する。
【０１８５】
その後、サービス提供機能(Terminator.2)34内の組込みコーディネータ機能(Sub-coordinator)39のインスタンス60は、前述の実行、並びにその結果540を受けて、発生したイベントを報告するため、実施モニタ機能(Execution Monitor)8のインスタンス90に対して、lLTransactionEventNotificationメッセージ541を送信する。その場合、前述の［Step.1.1.1］［Step.1.1.2］手順で入手したトランザクション識別子、並びにコンテキストを当該lLTransactionEventNotificationメッセージ541に含める。この手順を図4では[Step.2.1.13]、図5では[Step.2.2.13]と命名する。
【０１８６】
実施モニタ機能(Execution Monitor)8のインスタンス90は、lLTransaction  EventNotificationメッセージ541を受信すると、当該メッセージに含まれるトランザクション識別子、並びにコンテキストを元に、参照するべきExecution Plan Treeのインスタンス4に関する状態インスタンス65を特定する。その後、当該インスタンス65に対してVerification要求コマンド542を発行し、図10に記されるExecution Plan Treeのインスタンス4のサブセット情報を入手する。
【０１８７】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は当該サブセット情報に対して、Verification実行コマンド543を発行し、履歴状況を含む整合性の検証を実施する。特に履歴状況を把握する場合は、図１で記した様にメタデータ管理(Meta Data Management)5から実施モニタ機能(Execution Monitor)8が格納されているメタデータ611を取り出した後、履歴状況検索コマンド612を発行し、関連情報613を入手する。
【０１８８】
この場合、手順[Step.2.1.12]、もしくは手順[Step.2.2.12]で失敗となっているため、失敗として扱う。以上の一連の手順を図4では[Step.2.1.14]、図5では[Step.2.2.14]と命名する。
【０１８９】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は、サービス提供機能(Terminator.2)34内の組込みコーディネータ機能(Sub-coordinator)39のインスタンス60に対してReturnメッセージ545を返信する。この手順を図4では[Step.2.1.15]、図5では[Step.2.2.15]と命名する。
【０１９０】
サービス提供機能(Terminator.2)34内の組込みコーディネータ機能(Sub-coordinator)39のインスタンス60が、Returnメッセージ545を受信すると、その結果をもとにサービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス56に対して、Returnメッセージ546を返信する。その際、失敗を意味するNGで返答する。この手順を図4では[Step.2.1.16]、図5では[Step.2.2.16]と命名する。
【０１９１】
サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス56は、NGを含むReturnメッセージ546を受信すると、トランザクションの状態に不整合があることから、[Step.2.1]補償トランザクション処理実施216に相当する処理を行う。具体的には、手順[Step.2.1.6]、もしくは手順[Step.2.2.6]でLocalな1フェーズコミットメントトランザクションを実行し、成功したサービス提供機能(Terminator.1)28の当該組込みコーディネータ機能(Sub-  coordinator)33に対して、Compensation TransactionRequestに関するメッセージ547を送信する。この手順を図4では[Step.2.1.17]、図5では[Step.2.2.17]と命名する。
【０１９２】
当該組込みコーディネータ機能(Sub-coordinator)33は、当該Compensation TransactionRequestに関するメッセージ547を受信すると、当該トランザクション識別子を確認の上で組込みコーディネータ機能(Sub-coordinator)33のインスタンス58を再起動させる。その後、当該組込みコーディネータ機能(Sub-coordinator)33のLocalな1フェーズコミットメントトランザクションを補償トランザクションとして実行する。成功の場合、その結果548を得る。失敗の場合は、その結果544を得る。ここで図4では成功した場合を記す。図5では失敗した場合を記す。この手順を図4では[Step.2.1.18]、図5では[Step.2.2.18]と命名する。
【０１９３】
その後、サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス58は、の実行、並びにその成功結果548、もしくは失敗結果544を受けて、発生したイベントを報告するため、実施モニタ機能(Execution Monitor)8のインスタンス90に対して、lLTransactionEvent  Notificationメッセージ549を送信する。その場合、前述の［Step.1.1.1］［Step.1.1.2］手順で入手したトランザクション識別子、並びにコンテキストを当該lLTransactionEventNotificationメッセージ549に含める。この手順を図4では[Step.2.1.19]、図5では[Step.2.2.19]と命名する。
【０１９４】
実施モニタ機能(Execution Monitor)8のインスタンス90は、lLTransaction  EventNotificationメッセージ549を受信すると、当該メッセージに含まれるトランザクション識別子、並びにコンテキストを元に、参照するべきExecution Plan Treeのインスタンス4に関する状態インスタンス65を特定する。その後、当該インスタンス65に対してVerification要求コマンド550を発行し、図10に記されるExecution Plan Treeのインスタンス4のサブセット情報を入手する。
【０１９５】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は当該サブセット情報に対して、Verification実行コマンド550を発行し、履歴状況を含む整合性の検証を実施する。特に履歴状況を把握する場合は、図１で記した様にメタデータ管理(Meta Data Management)5から実施モニタ機能(Execution Monitor)8が格納されているメタデータ611を取り出した後、履歴状況検索コマンド612を発行し、関連情報613を入手する。一連の手順を図4では[Step.2.1.20]、図5では[Step.2.2.20]と命名する。
【０１９６】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は、サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス58に対してReturnメッセージ552を返信する。この手順を図4では[Step.2.1.21]、図5では[Step.2.2.21]と命名する。
【０１９７】
サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス58が、Returnメッセージ552を受信すると、その結果をもとにサービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス56に対して、Returnメッセージを返信する。成功の場合は、Returnメッセージ553を返答する。この手順を図4で[Step.2.1.22]と命名する。失敗の場合は、Returnメッセージ556を返答する。この手順を図5で[Step.2.2.22]と命名する。
【０１９８】
更にサービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス56がReturnメッセージ553、もしくはReturnメッセージ556を受信すると、それが配下の任意サービス仲介機能、サービス提供機能(Terminator)で最後のものであることを確認した場合、その結果をもとにトランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11のインスタンス54に対して、Returnメッセージを返信する。成功の場合は、Returnメッセージ554を返答する。この手順を図4で[Step.2.1.23]と命名する。失敗の場合は、Returnメッセージ557を返答する。この手順を図5で[Step.2.2.23]と命名する。
【０１９９】
次に図6を用いて、[Step.3]調整相53の処理を、手順に従い、詳細に説明する。
【０２００】
前述の通り、[Step.2.1]補償トランザクション処理実施216は、図6では[Step.2.2.17]  Compensation TransactionRequestに関するメッセージ送信547、[Step.2.2.18]  Localの1フェーズコミットメントトランザクション実行、並びに失敗544、[Step.2.2.22]Returnメッセージ返信556の３つに分解される。
【０２０１】
ここで[Step.2.2.18]  Localの1フェーズコミットメントトランザクション実行、並びに失敗544の結果は、[Step.2.2.19]lLTransaction EventNotificationメッセージ送信549により、実施モニタ機能(Execution Monitor)8に通知される。
【０２０２】
この結果、[Step.2.2.20]Verification要求コマンド550、並びに[Step.2.2.20]  Verification実行コマンド551が実施される。当該[Step.2.2.20]Verification実行コマンド551にてCompensation TransactionRequestに関する失敗であることを検出した場合は、[Step.2.2.21]Returnメッセージ返信552にて失敗を応答する。
【０２０３】
以上の結果、[Step.2.2.22]Returnメッセージ返信556、並びに[Step.2.2.23]  Returnメッセージ返信557の各々に対して失敗が応答されることになる。
【０２０４】
[Step.3.1]検査処理・抽出221は、図6においては[Step3.1.1]Verification要求コマンド実施558、[Step3.1.1]Verification実行コマンド559に分解される。
【０２０５】
[Step.3.2]再補償要求処理220は、図6においては[Step.3.2.1]request CompensationTransactionメッセージ560の送信に相当する。
【０２０６】
[Step.3.2］補償トランザクション処理実施222は、図6においては[Step.3.2.2]Compensation TransactionRequestに関するメッセージ561の送信、[Step.3.2.3]Localの1フェーズコミットメントトランザクション実行、並びに成功562、[Step.3.2.7]Returnメッセージ567の返信の３つに分解される。
【０２０７】
[Step.3.2]トランザクションEvent通知処理223は、図6においては[Step.3.2.4]lLTransactionEventNotificationメッセージ563の送信、[Step.3.2.6]Returnメッセージ566の返信の２つに分解される。
【０２０８】
[Step.3.2]検査処理224は、図6においては[Step.3.2.5]Verification要求コマンド564、並びに[Step.3.2.5]Verification実行コマンド565の２つに分解される。
【０２０９】
[Step.3.3]トランザクション補償状況報告処理225は、図6においては[Step.3.3.1]  notificationTransactionRecoveryメッセージ568の送信に相当すると共に[Step.3.3.2]  Clearコマンド555の実施も行う。
【０２１０】
続けて図6に記した[Step.3]実行相53の処理手順を説明する。図6はフローチャート図で記した手順ではなく、且つ、図１の構成図に依存するが、本方式の特徴を失う訳ではないため、フローチャート図を用いることなく、シーケンス図形式の図6にて処理手順を説明する。
【０２１１】
図6に記載された手順[Step.2.2.1]から手順[Step.2.2.23]のすべての処理内容は、図5のものと同一である。従って、図6における調整機能の繰り返し実行範囲69の部分を中心に手順を説明する。
【０２１２】
実施モニタ機能(Execution Monitor)8のインスタンス90は、随時、Execution Plan Treeのインスタンス4に関する状態インスタンス65の状態確認、異常検知を実施しており、当該インスタンス65に対してVerification要求コマンド558を発行し、図10に記されるExecution Plan Treeのインスタンス4のサブセット情報を入手する。
【０２１３】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は当該サブセット情報に対して、Verification実行コマンド559を発行し、履歴状況を含む整合性の検証、状態確認、異常検知を実施する。特に履歴状況を把握する場合は、図１で記した様にメタデータ管理(Meta Data Management)5から実施モニタ機能(Execution Monitor)8が格納されているメタデータ611を取り出した後、履歴状況検索コマンド612を発行し、関連情報613を入手する。一連の手順を図6では[Step.3.1.1]と命名する。
【０２１４】
当該実施モニタ機能(Execution Monitor)8のインスタンス90が、履歴状況を含む整合性の検証、状態確認を行った場合、またはサービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス58が[Step.2.2.19]で実施したlLTransactionEventNotificationメッセージ549の送信により、[Step.2.2.18]で実施した補償トランザクションが失敗であったことを検知すると、当該実施モニタ機能(Execution Monitor)8のインスタンス90は、サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13に対して、再度補償トランザクションの実施を促すため、requestCompensation  Transactionメッセージ560を送信する。この場合、前述の［Step.1.1.1］［Step.1.1.2］手順で入手したトランザクション識別子、並びにコンテキストを当該request  CompensationTransactionメッセージ560に含める。
【０２１５】
当該サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13がrequestCompensationTransactionメッセージ560を受信すると、インスタンス56とは異なる新たなインスタンス67を新たに起動させる。以上の一連の手順を図6では[Step.3.2.1]と命名する。
【０２１６】
サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス67は起動すると、[Step.3.2]補償トランザクション処理実施222に相当する処理を行う。具体的には、手順[Step.2.1.17]、もしくは手順[Step.2.2.17]でLocalな1フェーズコミットメントトランザクションを実行し、失敗したサービス提供機能(Terminator.1)28の当該組込みコーディネータ機能(Sub-coordinator)33に対して、CompensationTransactionRequestに関するメッセージ561を再送信する。この手順を図6では[Step.3.2.2]と命名する。
【０２１７】
当該組込みコーディネータ機能(Sub-coordinator)33は、当該Compensation TransactionRequestに関するメッセージ561を受信すると、当該トランザクション識別子を確認の上で組込みコーディネータ機能(Sub-coordinator)33のインスタンス58とは異なる新たなインスタンス68を新たに起動させる。その後、当該組込みコーディネータ機能(Sub-coordinator)33のLocalな1フェーズコミットメントトランザクションを補償トランザクションとして実行する。ここでは成功とし、その結果562を得る。この手順を図6では[Step.3.2.3]と命名する。
【０２１８】
その後、サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス68は、前述の実行、並びにその成功結果562を受けて、発生したイベントを報告するため、実施モニタ機能(Execution Monitor)8のインスタンス90に対して、lLTransactionEvent  Notificationメッセージ563を送信する。その場合、前述の［Step.1.1.1］［Step.1.1.2］手順で入手したトランザクション識別子、並びにコンテキストを当該lLTransactionEventNotificationメッセージ563に含める。この手順を図6では[Step.3.2.4]と命名する。
【０２１９】
実施モニタ機能(Execution Monitor)8のインスタンス90は、lLTransaction  EventNotificationメッセージ563を受信すると、当該メッセージに含まれるトランザクション識別子、並びにコンテキストを元に、参照するべきExecution Plan Treeのインスタンス4に関する状態インスタンス65を特定する。その後、当該インスタンス65に対してVerification要求コマンド564を発行し、図10に記されるExecution Plan Treeのインスタンス4のサブセット情報を入手する。
【０２２０】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は当該サブセット情報に対して、Verification実行コマンド565を発行し、履歴状況を含む整合性の検証を実施する。特に履歴状況を把握する場合は、図１で記した様にメタデータ管理(Meta Data Management)5から実施モニタ機能(Execution Monitor)8が格納されているメタデータ611を取り出した後、履歴状況検索コマンド612を発行し、関連情報613を入手する。一連の手順を図6では[Step.3.2.5]と命名する。
【０２２１】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は、サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス68に対してReturnメッセージ566を返信する。この手順を図6では[Step.3.2.6]と命名する。
【０２２２】
サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス68が、Returnメッセージ566を受信すると、その結果をもとにサービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のインスタンス67に対して、Returnメッセージ567を返信する。この手順を図6で[Step.3.2.7]と命名する。
【０２２３】
以上の一連の手順[Step.3.1.1]から、手順[Step.3.2.7]までの処理は、調整機能の繰り返し実行範囲69に含まれ、手順[Step.3.2.3]内の補償トランザクションが成功する、もしくは失敗の場合はディフォルト規定回数まで実施されることになる。当該処理を複数実施の結果、失敗となった場合は、システム管理者等に報告され、後に別対応の実施が想定される。
【０２２４】
以上の一連の手順[Step.3.1.1]から、手順[Step.3.2.7]までの処理が成功した場合、実施モニタ機能(Execution Monitor)8のインスタンス90は、トランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11に対して、[Step.3.3]トランザクション補償状況報告処理225としてnotificationTransactionRecoveryメッセージ568を送信する。この手順を図6で[Step.3.3.1]と命名する。
【０２２５】
トランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11は、notificationTransaction Recoveryメッセージ568を受信すると、インスタンス54とは異なる別のインスタンス66を起動し、相応の処理を行い、一連のトランザクション処理が終了することになる。
【０２２６】
また、実施モニタ機能(Execution Monitor)8のインスタンス90が、履歴状況を含む整合性の検証、状態確認を行った際、サービス提供機能(Terminator.1)28内の組込みコーディネータ機能(Sub-coordinator)33のインスタンス58が[Step.2.2.7]で実施したlLTransactionEventNotificationメッセージ534、もしくは[Step.2.2.19]で実施したlLTransactionEventNotificationメッセージ549により、[Step.2.2.6]で実施した１フェーズコミットメントトランザクション、[Step.2.2.18]で実施した補償トランザクションも実施が予定されていないことを検知した場合、[Step.1]準備相91段階で全て確定的としないまま、[Step.2]実行相52を実施した、もしくは当該[Step.2]実行相52の状態で挙動が変化した、と判断する。
【０２２７】
斯様な場合は、該当するlLTransaction DefinitionNotificationメッセージを受信していないため、Execution Plan Treeのインスタンス4に関するインスタンス65に該当するものが存在しないことにより検知される。
【０２２８】
この場合、当該実施モニタ機能(Execution Monitor)8のインスタンス90は、サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13に対して、当該状況を解消する補償トランザクションの実施を促すため、requestCompensation  Transactionメッセージ560を送信する。この場合、前述の［Step.1.1.1］［Step.1.1.2］手順で入手したトランザクション識別子、並びにコンテキストを当該request  CompensationTransactionメッセージ560に含める。
【０２２９】
その後、実施モニタ機能(Execution Monitor)8のインスタンス90は、最早、不要となったExecution Plan Treeのインスタンス4に関する状態インスタンス65を消去するため、Clearコマンド555の実施も行う。この手順を図6で[Step.3.3.2]と命名する。
【０２３０】
尚、図１において、サービス仲介機能(Broker.2)16に対するアクセスも存在する。これについて幾つかメッセージが定義されるが、サービス仲介機能(Broker.1)12、並びに、サービス提供機能(Terminator.1)28、並びにサービス提供機能(Terminator.2)34間のものと等価である。そこで詳細は省略する。
【０２３１】
例えば、[Step.1]準備相91の場合、図1のメッセージ600はlLTransactionPrepare Requestメッセージ505に、図1のメッセージ601は、Returnメッセージ525に、図1のメッセージ602はlLTransactionPrepare Requestメッセージ511に、図1のメッセージ603はReturnメッセージ517に、図1のメッセージ604はlLTransactionPrepareRequestメッセージ518に、図1のメッセージ605はReturnメッセージ524に、図1のメッセージ606はlLTransactionPrepareRequestメッセージ511に、図1のメッセージ607はReturnメッセージ517に、図1のメッセージ608はlLTransactionPrepareRequestメッセージ518に、図1のメッセージ609はReturnメッセージ524にそれぞれ等価となる。
【０２３２】
次に図11、図12、図13、図14、図15を用いて、Execution Plan Treeのインスタンス4に関するインスタンス65の生成、更新の手順を概説する。
【０２３３】
図11は、手順[Step.1.2.1]において、コーディネータ呼び出し機能(Coordination Library)11のインスタンス54から、実行計画管理機能(Execution Plan Manager)3のインスタンス64が、lLTransaction Definition Notificationメッセージ502を受信した場合に生成されるものであり、図10に記載したもののサブセットとなる。
【０２３４】
その後、手順[Step.1.3.2]において、組込みコーディネータ機能(Sub-coordinator)13の当該インスタンス55から、実行計画管理機能(Execution Plan Manager)3のインスタンス64が、lLTransactionDefinitionNotificationメッセージ506を受信した場合に図12の様な関係が定義されることになる。
【０２３５】
この場合、前述の様に、ノード1002において、丸角四角領域1014、並びに丸角四角領域1019、もしくは丸角四角領域1014、並びに丸角四角領域1020を連結する場合、その関係である連結関係1046が指定される。
【０２３６】
当該連結関係1046においては、サービス仲介機能(Broker.1)12が送信側になる場合と、受信側になる場合でアクセス先が異なるため、当該連結関係1046を生成する場合は特別な対応が必要となる。そこで、lLTransactionDefinitionNotificationメッセージ506に含まれる<sourceDescriptionList>タグ部分の対応関係を指定することで、当該連結関係1046が生成される。
【０２３７】
手順[Step.1.3.2]において、組込みコーディネータ機能(Sub-coordinator)13の当該インスタンス55から、実行計画管理機能(Execution Plan Manager)3のインスタンス64が、lLTransactionDefinitionNotificationメッセージ506を受信した場合は、図12のみならず、図13の様な関係も定義されることになる。ここでは、詳細説明を省略する。
【０２３８】
その後、手順[Step.1.3.7]において、組込みコーディネータ機能(Sub-coordinator)33の当該インスタンス57から、実行計画管理機能(Execution Plan Manager)3のインスタンス64が、lLTransactionDefinitionNotificationメッセージ512を受信した場合、図14の様な関係が定義されることになる。
【０２３９】
この場合、ノード1007に関する情報はノード1006に関する情報と同じlLTransactionDefinitionNotificationメッセージ512に記載されても、別の同等なlLTransactionDefinitionNotificationメッセージ512のインスタンスに記載されても良い。
但し、両者の関係はlLTransactionDefinitionNotificationメッセージ512に明示的に記載されるため、対応関係1060が明確に定義されることになる。
【０２４０】
図14における連結関係1050、並びに連結関係1051は、前述の連結関係1046と同等の位置付けであり、手順も同じである。このため、ここでは詳細説明を省略する。
【０２４１】
その後、手順[Step.1.3.13]において、組込みコーディネータ機能(Sub-coordinator)39の当該インスタンス59から、実行計画管理機能(Execution Plan Manager)3のインスタンス64が、lLTransactionDefinitionNotificationメッセージ519を受信した場合、図15の様な関係が定義されることになる。
【０２４２】
この場合、ノード1008に関する情報はノード1009に関する情報と同じlLTransactionDefinitionNotificationメッセージ519に記載されても、別の同等なlLTransactionDefinitionNotificationメッセージ519のインスタンスに記載されても良い。
但し、両者の関係はlLTransactionDefinitionNotificationメッセージ519に明示的に記載されるため、対応関係1061が明確に定義されることになる。
【０２４３】
図15における連結関係1052、並びに連結関係1053は、前述の連結関係1046と同等の位置付けであり、手順も同じである。このため、ここでは詳細説明を省略する。
【０２４４】
以上の手順に基づき、Execution Plan Treeのインスタンス4に関するインスタンス65の生成、更新が実施されることになる。
【０２４５】
最後に手順[Step.1.4.1]において検証の結果、応答されるlLTransactionReportメッセージ526の内容と、[Step.2]実行相52、[Step.3]調整相53の起動条件、内容について説明する。大きく５つのケースが存在する。
【０２４６】
ケース(1)は完全なケースであり、[Step.1]準備相91の手順[Step.1.4.1]で、トランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11が受信するlLTransactionReportメッセージ526に問題がないため、当該コーディネータ呼び出し機能(Coordination Library)11の判断に基づき、[Step.2]実行相52の処理は実施され、[Step.3]調整相53の処理も限定的に実施される。当該ケース(1)は下記の具体的条件(1.1)(1.2)を全て満足する場合に該当する。
【０２４７】
当該具体的条件(1.1)は、実行計画管理機能(Execution Plan Manager)3のインスタンス64が、全てのlLTransaction DefinitionNotificationメッセージを受信していることである。当該事項は、作成されるExecution Plan Treeのインスタンス4に関するインスタンス65の末端に相当する全ての部分が、TerminatorかCompensationである場合にのみに該当し、この場合、全てのlLTransaction DefinitionNotificationメッセージを受信した、と判断する。これは、当該インスタンス65の末端に相当する部分に一つでもTerminatorかCompensation以外のものが存在すると、lLTransaction DefinitionNotificationメッセージの一部を受信出来ていないためである。図8に記載される当該lLTransaction DefinitionNotificationメッセージの定義で、”terminationPoint”要素で記述される部分が”terminationNode”である場合、当該インスタンス65の末端に相当する部分がTerminatorかCompensationに相当する。
【０２４８】
ケース(1)の具体的条件(1.2)は、全てのlLTransactionDefinition Notificationメッセージに関する図8で記載される補償トランザクションに関する記述が全て、Saga方式を意味する“pureSaga”であることである。具体的には図8にて”compensationPoint”要素で記述される部分が”pureSaga”である場合に、その様に定義される。
【０２４９】
ケース(1)の当該２つの具体的条件(1.1)(1.2)を全て満足する場合、[Step.3]調整相53の処理内容は以下の様になる。図6の手順[Step.3.2.1]に記した様に当該ロングライブトランザクションモニタ(Long Live Transaction Monitor)1の実施モニタ機能(Execution Monitor)8は、当該サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13にrequestCompensationTransactionメッセージ560を送信するだけで、[Step.3]調整相53の実質処理は、トランザクション実行範囲(Scope of Transaction Execution)9側の機能構成要素群に委託する。
【０２５０】
ケース(2)は不完全なケースを含む準完全なケースであり、[Step.1]準備相91の手順[Step.1.4.1]で、トランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11が受信するlLTransactionReportメッセージ526には、限定的・部分的な問題があることが通知される。しかし、当該コーディネータ呼び出し機能(Coordination Library)11の判断に基づき、[Step.2]実行相52の処理は実施され、[Step.3]調整相53の処理も限定的に実施される。当該ケース(2)は下記の具体的条件(2.1)(2.2)を全て満足する場合に該当する。
【０２５１】
ケース(2)の具体的条件(2.1)として、実行計画管理機能(Execution Plan Manager)3のインスタンス64が、全てのlLTransaction DefinitionNotificationメッセージを受信していることである。この具体的定義は、前述の具体的条件(1.1)と等価である。
【０２５２】
ケース(2)の具体的条件(2.2)として、全てのlLTransactionDefinition  Notificationメッセージに関する図8で記載される補償トランザクションに関する記述が全てSaga方式を意味する“pureSaga”ではなく、任意の１つだけが“pureSaga”でないか、もしくは補償トランザクションが実装されていないことである。具体的には図8にて”compensationPoint”要素で記述される部分の任意の一つが”pureSaga”でない、もしくは空要素等になっている場合に相当する。当該補償トランザクションに関する記述が全てSaga方式を意味する“pureSaga”であるとは限らない場合は、準完全なケースに相当する。これに対して、当該補償トランザクションが実装されていない等の理由に基づき、当該記述が存在しない場合は不完全なケースに相当する。
【０２５３】
ケース(2)の当該２つの具体的条件(2.1)(2.2)を全て満足する場合、[Step.3]調整相53の処理内容は以下の様になる。図6の手順[Step.3.2.1]に記した様に当該ロングライブトランザクションモニタ(Long Live Transaction Monitor)1の実施モニタ機能(Execution Monitor)8は、当該サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13にrequestCompensationTransactionメッセージ560を送信するだけで、[Step.3]調整相53の実質処理は、トランザクション実行範囲(Scope of Transaction Execution)9側の機能構成要素群に委託する。
【０２５４】
但し、具体的条件(2.2)により、補償トランザクションが実装されておらず、補償動作が不完全な場合、当該ロングライブトランザクションモニタ(Long Live Transaction Monitor)1の実施モニタ機能(Execution Monitor)8で、当該補償トランザクションに残存があることが検出される場合も考えられる。このため、トランザクション実行範囲(Scope of Transaction Execution)9側の機能構成要素群で更なる対応策が実装されることを前提として、当該サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13にrequestCompensationTransactionメッセージ560を送信する場合、「補償トランザクションが全て定義されているが混在であること」、もしくは「補償トランザクションが定義されておらず不完全」である旨を通知する。
【０２５５】
ケース(3)は、対応可能な不完全ケースであり、[Step.1]準備相91の手順[Step.1.4.1]で、トランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11が受信するlLTransactionReportメッセージ526は、問題がある旨が記載される。しかし、対応可能な不完全ケースであるため、当該コーディネータ呼び出し機能(Coordination Library)11の判断に基づき、[Step.2]実行相52の処理は実施され、[Step.3]調整相53の処理も限定的に実施される。当該ケース(3)は、下記の具体的条件(3.1)(3.2)を全て満足する場合に該当する。
【０２５６】
ケース(3)の具体的条件(3.1)として、実行計画管理機能(Execution Plan Manager)3のインスタンス64が、末端に位置付けられる任意、かつ１つのサービス提供機能(Terminator)のみからlLTransactionDefinitionNotificationメッセージを受信していない場合である。これは、具体的条件(1.1)を違反する１つのケースであり、作成されるExecution Plan Treeのインスタンス4に関するインスタンス65の末端に相当する部分の任意の一つが、TerminatorかCompensationではない場合である。図8に記載される当該lLTransaction DefinitionNotificationメッセージの定義で、”terminationPoint”要素で記述される部分の一つに”terminationNode”でないものが含まれる場合に、具体的条件(3.1)が満足されると、判断される。
【０２５７】
ケース(3)の具体的条件(3.2)として、全てのlLTransactionDefinition  Notificationメッセージに関する図8で記載される補償トランザクションに関する記述が全て、Saga方式を意味する“pureSaga”であることである。この具体的定義は、前述の具体的条件(1.2)と等価である。
【０２５８】
ケース(3)の当該２つの具体的条件(3.1)(3.2)を全て満足する場合は、[Step.3]調整相53の処理内容は以下の様になる。図6の手順[Step.3.2.1]に記した様に当該ロングライブトランザクションモニタ(Long Live Transaction Monitor)1の実施モニタ機能(Execution Monitor)8は、requestCompensationTransactionメッセージを送信する場合、当該サービス仲介機能(Broker.1)12内の組込みコーディネータ機能(Sub-coordinator)13のみに留まらず、選択的に送信を実施することになる。但し、補償トランザクションの実施は、トランザクション実行範囲(Scope of Transaction Execution)9側の機能構成要素群に委託する。
【０２５９】
上記の場合、実行計画管理機能(Execution Plan Manager)3のインスタンス64にILTransactionDefinitionNotificationメッセージを送信していないサービス提供機能(Terminator)において、分散トランザクション処理に関する失敗が発生した場合、その補償動作はケース(2)に記した処理手順と同一の手順で対応することになる。
【０２６０】
これに対して、実行計画管理機能(Execution Plan Manager)3のインスタンス64にILTransactionDefinitionNotificationメッセージを送信していないサービス提供機能(Terminator)以外で、分散トランザクション処理に関する失敗が発生した場合、ILTransactionDefinitionNotificationメッセージを送信していない当該サービス提供機能(Terminator)での補償動作を行うことが困難になる。このため、分散トランザクション処理の要求元であるトランザクション要求アプリケーション機能(Transaction Requestor)10内のコーディネータ呼び出し機能(Coordination Library)11に、直接、requestCompensationTransactionメッセージを送信することを行う。これにより、配下の補償トランザクションを、トップダウンに実施することで対応する。
【０２６１】
ケース(4)は対応不可能な不完全ケースであり、実行計画管理機能(Execution Plan Manager)3のインスタンス64が末端に位置付けられる任意、かつ１つのサービス提供機能(Terminator)だけではなく、任意の２つ以上のサービス提供機能(Terminator)、サービス仲介機能（Broker）のいずれかからもlLTransactionDefinitionNotificationメッセージを受信していない場合である。具体的には具体的条件(1.1)、かつ具体的条件(3.1)の両者を満足しないことである。
【０２６２】
当該ケース(4)の場合、図3の手順[Step.1.4.1]に記した様に、当該ロングライブトランザクションモニタ(Long Live Transaction Monitor)1の実行計画管理機能(Execution Plan Manager)3のインスタンス63は、lLTransactionReportメッセージ526を送信する場合、「統制不可能故、トランザクション失敗」である旨を通知する。
【０２６３】
当該lLTransactionReportメッセージ526を、トランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11が受信すると、当該コーディネータ呼び出し機能(Coordination Library)11の判断に基づき、当該トランザクションに関連する[Step.2]実行相52の実施、並びに[Step.3]調整相53の実施は取り止めとなる。
【０２６４】
ケース(5)は、対応不可能な不完全ケースであり、[Step.1]準備相91の手順[Step.1.4.1]で、トランザクション要求アプリケーション機能(Transaction Requestor)10のコーディネータ呼び出し機能(Coordination Library)11が受信するlLTransactionReportメッセージ526には、「統制不可能故、トランザクション失敗」である旨が記載され、ケース(4)と同様の処理を行う。当該ケース(5)は、下記の具体的条件(5.1)(5.2)を全て満足する場合に該当する。
【０２６５】
ケース(5)の具体的条件(5.1)として、実行計画管理機能(Execution Plan Manager)3のインスタンス64が、末端に位置付けられる任意、かつ１つのサービス提供機能(Terminator)のみからlLTransactionDefinitionNotificationメッセージを受信していない場合である。これは、具体的条件(1.1)を違反する１つのケースであり、作成されるExecution Plan Treeのインスタンス4に関するインスタンス65の末端に相当する部分の任意の一つが、TerminatorかCompensationではない場合である。図8に記載される当該lLTransaction DefinitionNotificationメッセージの定義で、”terminationPoint”要素で記述される部分の一つに”terminationNode”でないものが含まれる場合に、具体的条件(5.1)が満足されると、判断される。
【０２６６】
ケース(5)の具体的条件(5.2)として、全てのlLTransactionDefinition Notificationメッセージに関する図8で記載される補償トランザクションに関する記述が全て、Saga方式を意味する“pureSaga”であるとは限らない、もしくは補償トランザクションが実装されていない等の理由に基づき、当該記述が存在しないことである。この具体的定義は、前述の具体的条件(2.2)と等価である。
【０２６７】
以上の例では、完全なケース(1)だけでなく、不完全なケースを含む準安全なケース(2)、対応可能な不完全ケース(3)についても、[Step.2]実行相52の実施を行った。しかし、信頼性をより重視するポリシーでシステムを運用する場合、完全なケース(1)の場合だけ、[Step.2]実行相52の実施を行い、残りのケース(2)〜(5)の場合、[Step.2]実行相52の実施を取りやめるようにすることができる。
【符号の説明】
【０２６８】
1・・・ロングライブトランザクションモニタ(Long Live Transaction Monitor)
2・・・トランザクション識別子管理機能(Transaction Identifier Manager)
3・・・実行計画管理機能(Execution Plan Manager)
4・・・Execution Plan Treeのインスタンス
5・・・メタデータ管理(Meta Data Management)
6・・・プロセスデータ管理(Process Data Management)
7・・・検証実施機能(Validation Executor) 
8・・・実施モニタ機能(Execution Monitor)
9・・・トランザクション実行範囲(Scope of Transaction Execution)
10・・・トランザクション要求アプリケーション機能(Transaction Requestor)
11・・・コーディネータ呼び出し機能(Coordination Library)
12・・・サービス仲介機能(Broker.1)
13・・・組込みコーディネータ機能(Sub-coordinator)
14・・・データベース管理機能(DBMS)、 15・・・ログ管理機能(logging)
16・・・サービス仲介機能(Broker.2)
17・・・組込みコーディネータ機能(Sub-coordinator)
18・・・データベース管理機能(DBMS)、 19・・・ログ管理機能(logging)
20・・・サービス仲介機能(Broker.2.1)
21・・・組込みコーディネータ機能(Sub-coordinator)
22・・・データベース管理機能(DBMS)、 23・・・ログ管理機能(logging)
24・・・サービス仲介機能(Broker.2.2)
25・・・組込みコーディネータ機能(Sub-coordinator)
26・・・データベース管理機能(DBMS)、 27・・・ログ管理機能(logging)
28・・・サービス提供機能(Terminator.1)
29・・・アプリケーションサーバ機能(Application Server)
30・・・アプリケーション機能(Application)、 31・・・データベース管理機能(DBMS)  32・・・ログ管理機能(logging)
33・・・組込みコーディネータ機能(Sub-coordinator)
34・・・サービス提供機能(Terminator.2)
35・・・アプリケーションサーバ機能(Application Server)
36・・・アプリケーション機能(Application)、 37・・・データベース管理機能(DBMS)  38・・・ログ管理機能(logging)
39・・・組込みコーディネータ機能(Sub-coordinator)
40・・・サービス提供機能(Terminator.3)
41・・・アプリケーションサーバ機能(Application Server)
42・・・アプリケーション機能(Application)、 43・・・データベース管理機能(DBMS)  44・・・ログ管理機能(logging)
45・・・組込みコーディネータ機能(Sub-coordinator)
46・・・サービス提供機能(Terminator.4)
47・・・アプリケーションサーバ機能(Application Server)
48・・・アプリケーション機能(Application)、 49・・・データベース管理機能(DBMS)  50・・・ログ管理機能(logging)
51・・・組込みコーディネータ機能(Sub-coordinator)
52・・・[Step.2]実行相、 53・・・[Step.3]調整相
54・・・コーディネータ呼び出し機能(Coordination Library)インスタンス
55・・・組込みコーディネータ機能(Sub-coordinator)インスタンス
56・・・組込みコーディネータ機能(Sub-coordinator)インスタンス
57・・・組込みコーディネータ機能(Sub-coordinator)インスタンス
58・・・組込みコーディネータ機能(Sub-coordinator)インスタンス
59・・・組込みコーディネータ機能(Sub-coordinator)インスタンス
60・・・組込みコーディネータ機能(Sub-coordinator)インスタンス
61・・・ロングライブトランザクションモニタ(Long LiveTransactionMonitor)インスタンス
62・・・トランザクション識別子管理機能(TransactionIdentifierManager)インスタンス
63・・・検証実施機能(ValidationExecutor)インスタンス
64・・・実行計画管理機能(Execution Plan Manager)インスタンス
65・・・Execution Plan Treeのインスタンスの状態インスタンス
66・・・コーディネータ呼び出し機能(Coordination Library)インスタンス
67・・・組込みコーディネータ機能(Sub-coordinator)インスタンス
68・・・組込みコーディネータ機能(Sub-coordinator)インスタンス
69・・・調整機能の繰り返し実行範囲、 70・・・機能
71・・・アプリケーション機能(Application)
72・・・アプリケーションサーバ機能(Application Server)
73・・・機能、 74・・・アプリケーション機能(Application)
75・・・アプリケーションサーバ機能(Application Server)
76・・・TransactionRequestメッセージ、 77・・・Acknowledgementメッセージ
78・・・TransactionResponseメッセージ、 79・・・Acknowledgementメッセージ
80・・・<destinationPoint>タグ、
81・・・lLTransactionDefinitionNotificationメッセージインスタンス
82・・・<sourcePoint>タグ、 83・・・<sourceDescriptionList>のタグ
84・・・対応関係、 85・・・対応関係
86・・・受信側WSDL(Web Service Description Language)
87・・・受信側WSDL(Web Service Description Language)
90・・・実施モニタ機能(Execution Monitor)のインスタンス
91・・・[Step.1]準備相、
200・・・[Step.1.1］LLトランザクション開始要求処理
201・・・[Step.1.2］LLトランザクション定義通知処理
202・・・[Step.1.3］準備要求処理
203・・・[Step.1.3］LLトランザクション定義通知処理
204・・・[Step.1.3］準備要求処理
205・・・[Step.1.3］準備要求処理
206・・・[Step.1.3］LLトランザクション定義通知処理
207・・・[Step.1.3］LLトランザクション定義通知処理
208・・・[Step.1.3］定義検査処理
209・・・[Step.1.4］LLトランザクション検索結果通知処理
210・・・[Step.2.1]LLトランザクション実施要求処理
211・・・[Step.2.1]１フェーズコミットメントトランザクション実施要求・処理実施
212・・・[Step.2.1]１フェーズコミットメントトランザクション実施要求・処理実施
213・・・[Step.2.1]トランザクションEvent通知処理
214・・・[Step.2.1]トランザクションEvent通知処理
215・・・[Step.2.1]トランザクションEvent通知処理
216・・・[Step.2.1]補償トランザクション処理実施
217・・・[Step.2.1]トランザクションEvent通知処理
218・・・[Step.2.1]検査処理、 219・・・[Step.2.1]結果応答処理
220・・・[Step.3.2]再補償要求処理、 221・・・[Step.3.1]検査処理・抽出
222・・・[Step.3.2］補償トランザクション処理実施
223・・・[Step.3.2]トランザクションEvent通知処理
224・・・[Step.3.2]検査処理、
225・・・[Step.3.3]トランザクション補償状況報告処理
500・・・lLTransactionStartRequestメッセージ
501・・・Returnメッセージ
502・・・lLTransactionDefinitionNotificationメッセージ
503・・・Createコマンド、 504・・・Returnメッセージ
505・・・lLTransactionPrepareRequestメッセージ
506・・・lLTransactionDefinitionNotificationメッセージ
507・・・Addコマンド、 508・・・Returnメッセージ
509・・・Verification要求コマンド、 510・・・Verification実行コマンド
511・・・lLTransactionPrepareRequestメッセージ
512・・・lLTransactionDefinitionNotificationメッセージ
513・・・Addコマンド、 514・・・Returnメッセージ
515・・・Verification要求コマンド、 516・・・Verification実行コマンド
517・・・Returnメッセージ、518・・・lLTransactionPrepareRequestメッセージ
519・・・lLTransactionDefinitionNotificationメッセージ
520・・・Addコマンド、 521・・・Returnメッセージ
522・・・Verification要求コマンド、 523・・・Verification実行コマンド
524・・・Returnメッセージ、 525・・・Returnメッセージ
526・・・lLTransactionReportメッセージ
527・・・TransactionRequestに関するメッセージ
528・・・lLTransactionEventNotificationメッセージ
529・・・Verification要求コマンド、 530・・・Verification実行コマンド
531・・・Returnメッセージ
532・・・TransactionRequestに関するメッセージ
533・・・Localの1フェーズコミットメントトランザクション実行、並びに成功
534・・・lLTransactionEventNotificationメッセージ
535・・・Verification要求コマンド、 536・・・Verification実行コマンド
537・・・Returnメッセージ、 538・・・Returnメッセージ
539・・・TransactionRequestに関するメッセージ
540・・・Localの1フェーズコミットメントトランザクション実行、並びに失敗
541・・・lLTransactionEventNotificationメッセージ
542・・・Verification要求コマンド、 543・・・Verification実行コマンド
544・・・Localの1フェーズコミットメントトランザクション実行、並びに失敗
545・・・Returnメッセージ、 546・・・Returnメッセージ
547・・・Compensation TransactionRequestに関するメッセージ
548・・・Localの1フェーズコミットメントトランザクション実行、並びに成功
549・・・lLTransactionEventNotificationメッセージ
550・・・Verification要求コマンド、 551・・・Verification実行コマンド
552・・・Returnメッセージ、 553・・・Returnメッセージ
556・・・Returnメッセージ、 557・・・Returnメッセージ
558・・・Verification要求コマンド、 559・・・Verification実行コマンド
560・・・requestCompensationTransactionメッセージ
561・・・Compensation TransactionRequestに関するメッセージ
562・・・Localの1フェーズコミットメントトランザクション実行、並びに成功
563・・・lLTransactionEventNotificationメッセージ
564・・・Verification要求コマンド、 565・・・Verification実行コマンド
566・・・Returnメッセージ、 567・・・Returnメッセージ
568・・・notificationTransactionRecoveryメッセージ、
600・・・lLTransactionPrepareRequestメッセージ
601・・・Returnメッセージ
602・・・lLTransactionPrepareRequestメッセージ
603・・・Returnメッセージ
604・・・lLTransactionPrepareRequestメッセージ
605・・・Returnメッセージ
606・・・lLTransactionPrepareRequestメッセージ
607・・・Returnメッセージ
608・・・lLTransactionPrepareRequestメッセージ
609・・・Returnメッセージ、 610・・・格納コマンド
611・・・メタデータ、 612・・・履歴状況検索コマンド
613・・・関連情報、 1001・・・ノード
1002・・・ノード、 1003・・・ノード
1004・・・ノード、 1005・・・ノード
1006・・・ノード、 1007・・・ノード
1008・・・ノード、 1009・・・ノード
1010・・・ノード、 1011・・・ノード
1012・・・ノード、 1013・・・ノード
1014・・・丸角四角領域、 1015・・・矢印
1016・・・丸角四角領域、 1017・・・矢印
1018・・・矢印、 1019・・・丸角四角領域
1020・・・丸角四角領域、 1021・・・矢印
1022・・・矢印、 1023・・・丸角四角領域
1024・・・矢印、 1025・・・丸角四角領域
1026・・・丸角四角領域、 1027・・・矢印
1028・・・丸角四角領域、 1029・・・矢印
1030・・・丸角四角領域、 1031・・・丸角四角領域
1032・・・丸角四角領域、 1033・・・丸角四角領域
1034・・・丸角四角領域、 1035・・・矢印
1036・・・丸角四角領域、 1037・・・矢印
1038・・・丸角四角領域、 1039・・・矢印
1040・・・丸角四角領域、 1041・・・矢印
1042・・・丸角四角領域、 1043・・・丸角四角領域
1044・・・丸角四角領域、 1045・・・丸角四角領域
1046・・・連結関係、 1047・・・連結関係
1048・・・連結関係、 1049・・・連結関係
1050・・・連結関係、 1051・・・連結関係
1052・・・連結関係、 1053・・・連結関係
1054・・・連結関係、 1055・・・連結関係
1056・・・連結関係、 1057・・・連結関係
1058・・・連結関係、 1059・・・連結関係
1060・・・対応関係、 1061・・・対応関係
1062・・・対応関係、 1063・・・対応関係
【図１】
2010231309.tif 000003
【図２】
2010231309.tif 000004
【図３】
2010231309.tif 000005
【図４】
2010231309.tif 000006
【図５】
2010231309.tif 000007
【図６】
2010231309.tif 000008
【図７】
2010231309.tif 000009
【図８−１】
2010231309.tif 000010
【図８−２】
2010231309.tif 000011
【図８−３】
2010231309.tif 000012
【図９−１】
2010231309.tif 000013
【図９−２】
2010231309.tif 000014
【図９−３】
2010231309.tif 000015
【図９−４】
2010231309.tif 000016
【図１０】
2010231309.tif 000017
【図１１】
2010231309.tif 000018
【図１２】
2010231309.tif 000019
【図１３】
2010231309.tif 000020
【図１４】
2010231309.tif 000021
【図１５】
2010231309.tif 000022
【図１６】
2010231309.tif 000023
【図１７】
2010231309.tif 000024