JP2011003200A - 長時間のトランザクションを管理する方法およびシステム - Google Patents
長時間のトランザクションを管理する方法およびシステム Download PDFInfo
- Publication number
- JP2011003200A JP2011003200A JP2010152438A JP2010152438A JP2011003200A JP 2011003200 A JP2011003200 A JP 2011003200A JP 2010152438 A JP2010152438 A JP 2010152438A JP 2010152438 A JP2010152438 A JP 2010152438A JP 2011003200 A JP2011003200 A JP 2011003200A
- Authority
- JP
- Japan
- Prior art keywords
- activity
- entity
- transaction
- business
- transactions
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Human Resources & Organizations (AREA)
- Entrepreneurship & Innovation (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Software Systems (AREA)
- Economics (AREA)
- General Physics & Mathematics (AREA)
- Game Theory and Decision Science (AREA)
- Educational Administration (AREA)
- Development Economics (AREA)
- General Engineering & Computer Science (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】ビジネスアクティビティを用いて長時間トランザクションを管理する方法およびシステム。
【解決手段】本発明によれば、１つまたは複数のビジネスアクティビティが、複数の物理データベースにわたるビジネスオペレーションを含むことができる。ビジネスアクティビティは、トランザクション管理が複数の物理データベースにわたるトランザクションのために実行されるように論理トランザクションに関係づけられる。
【選択図】図２
【解決手段】本発明によれば、１つまたは複数のビジネスアクティビティが、複数の物理データベースにわたるビジネスオペレーションを含むことができる。ビジネスアクティビティは、トランザクション管理が複数の物理データベースにわたるトランザクションのために実行されるように論理トランザクションに関係づけられる。
【選択図】図２
Description
本発明は、コンピュータ化されたトランザクション管理に関し、より詳細には、長時間のコンピュータ化されたトランザクションを管理する方法およびシステムに関する。
コンピュータ化されたトランザクション処理設計における最も基本的な概念の１つは「作業単位」である。作業単位は通常、ＡＣＩＤセマンティクスを実装する。ＡＣＩＤとは、「原子性(Atomic)」、「一貫性(Consistent)」、「分離性(Isolated)」、および「持続性(Durable)」の概念をまとめたものである。ＡＣＩＤトランザクションモデルを完全に実装するシステムにより、プログラマは、マルチユーザの問題を本質的に無視することができる。システムのＡＣＩＤ動作は、コードが常に、あたかもシステム内のただ１つのユーザであるかのように実行されることを保証する。
ＡＣＩＤ動作はビジネスロジックを作成する作業をより単純にするが、スケーラビリティの犠牲を伴う。ＡＣＩＤの主な利点（それをシングルユーザのように見せる）は多くの場合、そのシステムをシングルユーザにする。例えば、厳格なＡＣＩＤセマンティクスは、ビジネスロジックによって参照されるだけのいかなるデータも、その処理の継続期間中はシングルユーザにしなければならないことを要求する（反復可能読み出し分離性(Repeatable Read Isolation)）。
市販のＳＱＬサーバは、ＡＣＩＤセマンティクスを実装する作業単位（データベーストランザクション）を長年サポートしてきている。本発明の実施形態は、ＳＱＬサーバトランザクションの新しい設計を記述しようとするものではない。しかし、ビジネスアプリケーションは、物理データベーストランザクションがサポートするよりもずっと長い作業単位を必要としている。したがって、複数の物理データベーストランザクションにわたることが可能な論理的作業単位をサポートするインフラストラクチャを構築することが必要である。
ビジネスアクティビティを用いて長時間トランザクションを管理する方法およびシステム。本発明の一態様によれば、１つまたは複数のビジネスアクティビティが、複数の物理データベースにわたるビジネスオペレーションを含むことができる。ビジネスアクティビティは、トランザクション管理が複数の物理データベースにわたるトランザクションのために実行されるように論理トランザクションに関係づけられる。
図１は、本発明を実施することができる適切なコンピューティングシステム環境１００の一例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の利用または機能の範囲に関するいかなる限定を示唆することも意図していない。また、コンピューティング環境１００は、例示的なオペレーティング環境１００に示されるいかなるコンポーネントまたはその組合せに関連して、いかなる依存性または要件も有するとは解釈されるべきではない。
本発明は、他の多くの汎用または専用のコンピューティングシステムの環境または構成とともに動作する。本発明とともに使用するのに適す可能性のある周知のコンピューティングシステム、環境、および／または構成の例としては、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサ方式のシステム、セットトップボックス、プログラム可能な消費者電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、電話システム、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境等があるが、これらには限定されない。
本発明は、コンピュータにより実行されるコンピュータ実行可能命令（例えば、プログラムモジュール）の一般的コンテキストで記述することができる。一般に、プログラムモジュールは特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。本発明はまた、通信ネットワークを介してリンクされるリモート処理デバイスによりタスクが実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールはメモリ記憶デバイスを含むローカルおよびリモートの両方のコンピュータ記憶媒体に配置することができる。
図１を参照すると、本発明を実施する例示的システムは、コンピュータ１１０の形態で汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントとしては、中央処理装置１２０、システムメモリ１３０、およびシステムメモリを含むさまざまなシステムコンポーネントを処理装置１２０に結合するシステムバス１２１を含むが、これらには限定されない。
システムバス１２１は、さまざまなバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含む、いくつかのタイプのバス構造のいずれとすることもできる。例として、限定されないが、このようなアーキテクチャとしては、Industry Standard Architecture（ＩＳＡ）バス、Micro Channel Architecture（ＭＣＡ）バス、Enhanced ISA（ＥＩＳＡ）バス、Video Electronics Standards Association（ＶＥＳＡ）ローカルバス、およびMezzanineバスとしても知られているPeripheral Component Interconnect（ＰＣＩ）バスがある。
コンピュータ１１０は通常、さまざまなコンピュータ読取可能な媒体を含む。コンピュータ読取可能な媒体は、コンピュータ１１０によりアクセス可能ないかなる利用可能な媒体とすることができ、揮発性および不揮発性媒体、リムーバブルおよび固定媒体の両方を含む。例として、限定されないが、コンピュータ読取可能な媒体にはコンピュータ記憶媒体および通信媒体が含むことができる。コンピュータ記憶媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュール等のデータのような情報の記憶のためのいかなる方法または技術で実装された揮発性および不揮発性、リムーバブルおよび固定媒体の両方を含む。コンピュータ記憶媒体としては、以下のものには限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ等のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）等の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶等の磁気記憶デバイス、または所望の情報を記憶するために使用可能でありコンピュータ１１０によりアクセス可能ないかなる他の媒体も含まれる。通信媒体は通常、搬送波等のトランスポートメカニズムのような変調データ信号でコンピュータ読取可能命令、データ構造、プログラムモジュール等のデータを具現化し、いかなる情報配信媒体も含む。「変調データ信号」という用語は、信号中に情報を符号化するような方法で１つまたは複数の信号の特性が設定または変更された信号を意味する。例として、限定されないが、通信媒体としては、有線ネットワークまたは直接有線接続のような有線媒体、および音響、ＲＦ、赤外線等の無線媒体のような無線媒体がある。上記のいずれかの組合せもまた、コンピュータ読取可能な媒体の範囲内に含まれるべきである。
システムメモリ１３０は、読み出し専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２といった揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。例えば起動中にコンピュータ１１０内の要素間で情報を転送するのを支援する基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３は、通常、ＲＯＭ１３１に記憶される。ＲＡＭ１３２は通常、処理装置１２０に直接アクセス可能な、および／または処理装置１２０によって現在実行されているデータおよび／またはプログラムモジュールを含む。例として、限定されないが、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。
コンピュータ１１０はまた、他のリムーバブル／固定、揮発性／不揮発性のコンピュータ記憶媒体を含むことができる。単なる例として、図１は、固定不揮発性磁気媒体の読み書きを行うハードディスクドライブ１４１、リムーバブル不揮発性磁気ディスク１５２の読み書きを行う磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭ等の光媒体のようなリムーバブル不揮発性光ディスク１５６の読み書きを行う光ディスクドライブ１５５を示している。例示したオペレーティング環境で使用可能な他のリムーバブル／固定、揮発性／不揮発性のコンピュータ記憶媒体としては、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭ等があるが、これらには限定されない。ハードディスクドライブ１４１は通常、インタフェース１４０のような固定メモリインタフェースを通じてシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インタフェース１５０のようなリムーバブルメモリインタフェースによりシステムバス１２１に接続される。
上記で説明し図１に示したドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ１１０のためのコンピュータ読取可能命令、データ構造、プログラムモジュール等のデータの記憶を行う。例えば図１において、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するように示す。なお、これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても異なってもいずれでも可能であることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７はここでは、少なくともそれらが別のコピーであることを示すために異なる番号が与えられている。
ユーザは、キーボード１６２、マイクロフォン１６３、およびマウス、トラックボールまたはタッチパッド等のポインティングデバイス１６１のような入力デバイスを通じてコンピュータ１１０にコマンドおよび情報を入力することが可能である。他の入力デバイス（図示せず）としては、ジョイスティック、ゲームパッド、衛星放送用アンテナ、スキャナ等があり得る。これらおよびその他の入力デバイスはしばしば、システムバスに結合したユーザ入力インタフェース１６０を介して処理装置１２０に接続するが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）のような他のインタフェースおよびバスアーキテクチャによって接続してもよい。モニタ１９１またはその他のタイプの表示デバイスもまた、ビデオインタフェース１９０のようなインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータはスピーカ１９７およびプリンタ１９６のような他の周辺出力デバイスを含んでもよく、これらは出力周辺インタフェース１９５を通じて接続することができる。
コンピュータ１１０は、リモートコンピュータ１８０のような１つまたは複数のリモートコンピュータへの論理接続を用いたネットワーク接続環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他の普通のネットワークノードとすることができ、通常、コンピュータ１１０に関して上記で説明した要素の多くまたはすべてを含む。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むことのできる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットで一般的である。
ＬＡＮネットワーキング環境で使用される場合、コンピュータ１１０はネットワークインタフェースすなわちアダプタ１７０を通じてＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１１０は通常、インターネットのようなＷＡＮ１７３を通じて通信を確立するためのモデム１７２等の手段を含む。モデム１７２は、内蔵でも外付けでもよいが、ユーザ入力インタフェース１６０等の適切なメカニズムを介してシステムバス１２１に接続することができる。ネットワーク接続環境では、コンピュータ１１０に関して図示したプログラムモジュールまたはその部分は、リモートメモリ記憶デバイスに記憶されてもよい。例として、限定されないが、図１は、リモートアプリケーションプログラム１８５がリモートコンピュータ１８０上に存在するように示されている。理解されるように、図示したネットワーク接続は例示であり、コンピュータ間に通信リンクを確立する他の手段も使用可能である。
図２は、本発明を実装することができる上位レベル環境のブロック図である。環境２００は、ツールおよびサーバプラットフォーム２０２、本発明が存在するビジネスフレームワーク２０４、ビジネスコンポーネント２０６およびビジネスソリューション２０８を示している。ツールおよびサーバプラットフォーム２０２は、例示的には、アプリケーションが広域ネットワークを通じてデータを通信および共有することを可能にするサービスのためのプラットフォームを提供する。プラットフォーム２０２は、例えば、この機能を可能にするためのツールおよびサーバシステムを含むことができる。ビジネスコンポーネント２０６は、例示的には、ビジネスフレームワーク２０４と開発者との対話に基づいて共にパッケージ化されるビジネスアプリケーションのための機能を含む。ビジネスコンポーネント２０６は、例えば、総勘定元帳および財務アプリケーションから、販売員自動化サービスおよび顧客関係管理アプリケーションにまでわたることができる。フレームワーク２０４を用いてビジネスコンポーネント２０６を書くことにより、これらのコンポーネントは拡張可能であり、どのようなレベルの機能および複雑サーガ所望されるかに応じて多くのユーザの要求を満たすために利用可能である。
各ビジネスソリューション２０８は、１つまたは複数のアプリケーションを含む。アプリケーションは、ユーザインタフェースを通じて提示され個別に配備されるビジネスコンポーネントのグループである。
ビジネスフレームワーク２０４は、ビジネスコンポーネント２０６の開発者により使用される。ビジネスフレームワークは、生産的で、信頼性が高く、一貫性のある形のビジネスアプリケーションを可能にする。
ビジネスフレームワークの概観
図３は、ビジネスフレームワーク２０４のいくつかの主要なサブシステムを示す。図３は、複数のビジネスコンポーネント２１４、２１６および２１８を含むアプリケーション層２１２をサポートするフレームワーク２１０を示している。ビジネスコンポーネントは、財務アプリケーション、企画アプリケーション、および流通アプリケーションを含む。フレームワーク２１０はまた、プラットフォーム２０２上に存在するように示されている。
図３は、ビジネスフレームワーク２０４のいくつかの主要なサブシステムを示す。図３は、複数のビジネスコンポーネント２１４、２１６および２１８を含むアプリケーション層２１２をサポートするフレームワーク２１０を示している。ビジネスコンポーネントは、財務アプリケーション、企画アプリケーション、および流通アプリケーションを含む。フレームワーク２１０はまた、プラットフォーム２０２上に存在するように示されている。
フレームワーク２１０自体は、ビジネスクラスライブラリ２２０のセット、ツールサブシステム２２２およびビジネスアプリケーションフレームワーク２２４を含む。ツールサブシステム２２２は、例示的には、コンポーネント、プロセス、レポートおよびエンドユーザインタフェースを設計するための複数の設計サブシステムを含む。ツールサブシステム２２２はまた、例示的に、設計されたコンポーネントをテストするために使用可能なテストサービスとともに、アプリケーションまたはソリューション内にコンポーネントをパッケージ化するために使用されるアプリケーションパッケージャも含む。
ビジネスクラスライブラリ２２０は、共通エンティティ２２６、パターン２２８およびデータ型２３０を含む。
２つのビジネスアプリケーションは、統合を行うことができるように、共有データ認識（ｓｈａｒｅｄ ｕｎｄｅｒｓｔａｎｄｉｎｇ ｏｆ ｄａｔａ）をしばしば必要とする。例えば、流通、財務、および顧客関係管理はすべて顧客データを扱う。したがってビジネスクラスライブラリ２２０は、対象となるコア属性を含むいくつかの共通エンティティ２２６をほとんどのビジネスアプリケーションに提供する。フレームワーク２１０上に構築されるアプリケーションは、カスタマイズ（後述）を通じて、シナリオ固有の属性および動作でこれらのエンティティを拡張することができる。
本発明の一態様の下では、長時間の論理トランザクションが、短期のデータベーストランザクションと補償ビジネスロジック（補償トランザクションとしても知られている）との組合せを用いて構築することができる。理想的な世界では、エンティティ利用者（ｅｎｔｉｔｙ ｃｏｎｓｕｍｅｒ）は、いかなる任意の論理作業単位をも指定することができる能力を望む。作業単位は簡潔に、単一のエンティティ属性に関する１回の更新を含むことができ、あるいはポスティングプロセス全体を包含することができる。その作業単位は任意であるため、利用者は次のように境界を定めることができるであろう：
Enterprise.BeginUnitOfWork();
// 利用者が望む...ことは何でもせよ
// エンティティの作成、エンティティの更新、エンティティの削除をせよ
// 任意の時点における作業単位のロールバックせよ
// マルチユーザ競合問題については心配不要
// 作業単位をずっと開放しておくこと...。
Enterprise.FinishUnitOfWork();
Enterprise.BeginUnitOfWork();
// 利用者が望む...ことは何でもせよ
// エンティティの作成、エンティティの更新、エンティティの削除をせよ
// 任意の時点における作業単位のロールバックせよ
// マルチユーザ競合問題については心配不要
// 作業単位をずっと開放しておくこと...。
Enterprise.FinishUnitOfWork();
残念ながら、無制限の任意の作業単位に対するこの要求は、エンティティ著作者（ｅｎｔｉｔｙ ａｕｔｈｏｒ）にとって、高度にスケーラブルなマルチユーザ型のサポートを行うには（不可能ではないにしても）過度に重い負担となる。物理データベーストランザクションは、エンティティ著作者にとって実装コストが安い。しかし、複数のデータベーストランザクションにわたる長時間の論理作業単位をサポートすることはエンティティ著作者にとって非常に高くつく。単一のデータベーストランザクションを超えて存続するいかなる論理作業単位も、補償トランザクションをサポートするエンティティ著作者が必要である。
理想的な世界であれば、すべてのビジネスロジックは、補償トランザクションをサポートするための関連するビジネスロジックを有するであろう。残念ながら、これは実質上、製品中のビジネスロジックの量を倍加し、実装するには法外に高くつく。したがって、任意の論理作業単位についてエンティティ利用者の究極的要望を満たすことに対しては設計の困難がある。これに代えて、エンティティ著作者により構築されなければならない補償ビジネスロジックの量を適度に制限しながら、利用者がその目標を満たすことを可能にする妥協策が開示される。
この妥協策は、プログラミングモデルに重大な影響を与える。作業単位は、ここで限界および制約を有することとなる。利用者が任意の論理作業単位を定めてもよいようなプログラミングモデルはもはやサポートされないのである。とはいっても、このことは、エンティティ著作者がいかなるレベルのトランザクションサポートをも実装することができること（全く実装しないことを含めて）を意味するわけではない。エンティティ著作者に対しては最小限の要件が依然として課されている。さもなければ、（独立系ソフトウェアベンダのような外部当事者を含む）エンティティ利用者は、所与のエンティティがどのようなトランザクションサポートを行うかをその都度調査しなければならないであろう。これは、エンティティ利用者に対する許容できない負担となると考えられる。
したがって、本発明の態様は、エンティティ著作者とエンティティ利用者の間のこの問題に対する妥協策を提供する。ある標準が、プログラミングモデルにおける論理作業単位に対して定義される。エンティティ著作者はこのレベルのトランザクションサポートを実装しなければならず、よってエンティティ利用者はある一定レベルのサポートに頼ることができるのである。
本発明の実施形態をより良く説明するため、一連の定義を以下に簡潔に行う。
・物理トランザクション−トランザクションの継続時間中にデータベースロックを保持するトランザクション。物理トランザクションは、リードおよびライトロックを保持しておくことができ（完全ＡＣＩＤセマンティクス）、またはライトロックのみを保持しておくこともできる（「リードコミッティド」による緩和ＡＣＩＤセマンティクス）。いずれの場合でも、物理トランザクションは、ロックを保持することによって、更新されるデータに対する完全分離セマンティクスを強制する。
・論理トランザクション−トランザクションの継続時間中にデータベースロックを保持しないトランザクション。具体的には、これは、更新されるデータに関する分離性を緩和する一方で、ＡＣＩＤの他の属性（ＡＣＤ部分）は依然として維持するトランザクションモデルである。
物理トランザクションを「ＡＣＩＤトランザクション」と呼び、論理トランザクションを「ＡＣＤトランザクション」と呼ぶこともできる。しかし、このような略語よりも「論理」および「物理」のほうが理解しやすい。論理トランザクションモデルは、物理トランザクションの基盤の上に構築される。
・トランザクションマネージャ−トランザクションマネージャは、トランザクションの「ライフサイクル」を制御する。市販のＳＱＬサーバは一般に、そのようなサーバ上の（BEGIN TRAN、COMMIT TRAN型の）物理トランザクションを管理することができる単純なトランザクションマネージャを含む。複数のサーバにわたる物理トランザクションを協調させることができる１つのトランザクションマネージャが、ワシントン州Redmondのマイクロソフト社（登録商標）から、Distributed Transaction Coordinator（ＤＴＣ）という商品名で市販されている。
・補償トランザクションマネージャ（ＣＴＭ）−従来の（ＳＱＬサーバやＤＴＣのような）トランザクションマネージャは物理トランザクションを管理する。長時間のトランザクションは複数の物理トランザクションにまで及ぶことが必要となる。複数の物理トランザクションが関与する場合、単純なトランザクションマネージャでは不十分かもしれない。ここで本明細書ではこのタイプのトランザクションマネージャを「補償トランザクションマネージャ」という。マイクロソフト（登録商標）から入手可能な１つの市販製品は、BizTalk Orchestration（ＢＴＯ）として知られており、論理トランザクションを管理することができる補償トランザクションマネージャを含む。
・物理トランザクション−トランザクションの継続時間中にデータベースロックを保持するトランザクション。物理トランザクションは、リードおよびライトロックを保持しておくことができ（完全ＡＣＩＤセマンティクス）、またはライトロックのみを保持しておくこともできる（「リードコミッティド」による緩和ＡＣＩＤセマンティクス）。いずれの場合でも、物理トランザクションは、ロックを保持することによって、更新されるデータに対する完全分離セマンティクスを強制する。
・論理トランザクション−トランザクションの継続時間中にデータベースロックを保持しないトランザクション。具体的には、これは、更新されるデータに関する分離性を緩和する一方で、ＡＣＩＤの他の属性（ＡＣＤ部分）は依然として維持するトランザクションモデルである。
物理トランザクションを「ＡＣＩＤトランザクション」と呼び、論理トランザクションを「ＡＣＤトランザクション」と呼ぶこともできる。しかし、このような略語よりも「論理」および「物理」のほうが理解しやすい。論理トランザクションモデルは、物理トランザクションの基盤の上に構築される。
・トランザクションマネージャ−トランザクションマネージャは、トランザクションの「ライフサイクル」を制御する。市販のＳＱＬサーバは一般に、そのようなサーバ上の（BEGIN TRAN、COMMIT TRAN型の）物理トランザクションを管理することができる単純なトランザクションマネージャを含む。複数のサーバにわたる物理トランザクションを協調させることができる１つのトランザクションマネージャが、ワシントン州Redmondのマイクロソフト社（登録商標）から、Distributed Transaction Coordinator（ＤＴＣ）という商品名で市販されている。
・補償トランザクションマネージャ（ＣＴＭ）−従来の（ＳＱＬサーバやＤＴＣのような）トランザクションマネージャは物理トランザクションを管理する。長時間のトランザクションは複数の物理トランザクションにまで及ぶことが必要となる。複数の物理トランザクションが関与する場合、単純なトランザクションマネージャでは不十分かもしれない。ここで本明細書ではこのタイプのトランザクションマネージャを「補償トランザクションマネージャ」という。マイクロソフト（登録商標）から入手可能な１つの市販製品は、BizTalk Orchestration（ＢＴＯ）として知られており、論理トランザクションを管理することができる補償トランザクションマネージャを含む。
ビジネスアプリケーションは、複数の物理データベーストランザクションにわたる処理を実行することが必要である。しかし、そのモデルに対する利用者が定義されるまでは、複雑な多重トランザクションをサポートするための設計を行うことはできない。複雑な多重トランザクションのシナリオを利用するのはプロセスである。より理解しやすくするため、以下ではこれらのプロセスは２つのタイプ、すなわち動的および静的のいずれか一方に入るものとして説明する。しかし、この区別は便宜上のものであり、本発明の実施形態を限定するものとみなされるべきではない。
動的プロセスは、本明細書においてワークフローともいうが、非同期的であり、プロセス実行中（例えば承認のための）ユーザの関与を必要とする。動的プロセスフローエディタが、エンドユーザに利用可能であり、一般に、プロセスを再構成するため「コーディング」は不要である。動的プロセスは一般に、（継続時間中に単一の物理トランザクションを保持することが実現可能でない場合）長期のトランザクションのために使用されるであろう。したがって、動的プロセスは補償を必要とする。結局、動的プロセスは補償を使用し、および一般に中間進行情報を公開することを必要とする。
他方、静的プロセスは一般に同期的である。場合によっては、静的プロセスは開始遅延を有し、呼出し側に対して非同期的に実行されるかもしれない。しかし、一旦開始されると、静的プロセスは完了まで実行される。非活動期間中に自分自身を一時停止あるいは不活性化させるメカニズムは有していない。静的プロセスは通常、年度末決算、郵便トランザクション、および複数通貨再評価トランザクションのような「バッチ処理」シナリオに見出される。静的プロセスは通常、非常に高い性能を要求し、一般にユーザの介入を要求しない。静的プロセスは、ユーザによる再構成を必要とすることはほとんどない。このようなプロセスは、動作を微調整するための「ノブ(knob)」、その他の制御機能を公開していることがある。静的プロセスは、適切なコードが書かれれば、拡張のためのイベントを生成することができる。しかし、場合によっては、バッチ処理は依然として複数のデータベーストランザクションに及ぶことが必要である。
動的プロセスは、ある場合には、論理トランザクションのためにBizTalk Orchestrationを使用することができる。しかし、一般的に静的プロセスはＢＴＯを使用することができない。ＢＴＯは静的プロセスを書くための最適な選択肢ではないのである。例えば、静的プロセスは、コードを書かずに再構成を行うためのＢＴＯの固有の能力を必要としない。さらに、ＢＴＯの性能では、企業向けバッチ処理の非常に高い性能要求には不十分かもしれない。
プロセスの記述が「静的」および「動的」の２つのグループに分かれるのは現在の技術の結果であるということは、留意すべき重要な点である。長期的には、静的プロセスの非常に高い性能要求を維持しながら、動的プロセスに要求されるすべての柔軟性を維持する環境が整うかもしれない。
ビジネスアプリケーションは、複数の物理データベーストランザクションにわたる処理を実行することが必要である。本発明の実施形態は一般に、ビジネスアプリケーション開発ツールのコンテキスト内で、３つの新しい要素を使用することによってこれを実現する。これらの要素としては、ビジネスアクティビティ(Business Activity)、静的プロセス(Static Process)、およびサーガマネージャ(Saga Manager)がある。
ビジネスアクティビティを考える１つの方法は、それを既知のビジネスエンティティ(Business Entity)と比較対照することである。ビジネスエンティティは一般に、オブジェクトモデル内のビジネスデータを公開し、利用者にとってはビジネスドキュメントと見える。例えば、
Order.OrderLines[1].Qty = 3.
Order.OrderLines[1].Qty = 3.
ビジネスエンティティは、ビジネス開発者にとって直感的であり、豊富な検証およびデフォルト動作をサポートするという点で「賢い」ビジネスドキュメントとみなすることができる。ビジネスエンティティの限界は、利用者のコードがエンティティオブジェクトモデルに結合され、場合によっては性能が低くなり得ることである。さらに、ビジネスエンティティは一般に、１つの属性を変更するためにエンティティ全体を撤回することが必要である。そして最後に、ビジネスエンティティの変更は、一般に補償がないため、永続化した後に一般的な方法では「アンドゥー」することができない。
これに対して、ビジネスアクティビティはビジネスデータに対する特定の処理を公開するために使用することができる。さらに、利用者コードはエンティティオブジェクトモデルに結合されない。例えば：
AllocateItem (ItemSku, ItemSite, Qty, UofM);
AllocateItem (ItemSku, ItemSite, Qty, UofM);
ビジネスアクティビティは、非常に高い性能を達成することができ、ストアドプロシージャ呼出しまたはＥＰセットオペレーションを含むことができる。ビジネスアクティビティはまた、規範的な補償インタフェースもサポートすることができる。
このように、ビジネスアクティビティは、ビジネスアプリケーション開発者のツールボックスにいくつかの新しい有益なツールをもたらす。プロセスは、もともと、一連のプロセスステップを実行するためのフレームワークを提供するために存在する。アクティビティは、ビジネスデータに対するオペレーションを実行することを必要とするプロセスのステップの実装を提供する。
ビジネスアプリケーションの開発者は、バッチ処理機能の構築に多大の時間と労力を注ぎ込んでいる。これは特に、企業システムの場合にそうである。企業システムでは、ソリューションが顧客の要求を満たすことができるかどうかを決めるのはこれらのバッチプロセスの堅牢性および性能であることが多い。「ビジネスロジックは、単一のデータベーストランザクションで実行されるか、またはワークフローであるかのいずれかである」と信じる人々もいる。この見方は、企業システムにおけるバッチ処理の役割の影響力を認識していないものである。本発明の実施形態の一態様によって、ビジネスアプリケーション開発フレームワーク内でバッチ処理の役割にこの認識および正確さが与えられる。
静的プロセスが、動的プロセスと同じレベルの柔軟性を提供しようとしていないことは、注意すべき重要な点である。むしろ、静的プロセスは、いかなる汎用ワークフローソリューションが提供することができるよりもずっと高いレベルの性能を達成することを目的に、意図的にある程度の柔軟性を犠牲にする。
静的プロセスは、GrayによるTransaction Processing Fundamentalsと題する本に記載されている「ミニバッチ(Mini-batch)」から導かれる概念の多くをサポートする。Grayは、ミニバッチという用語を、長時間のバッチプロセスのための一般的手法を記述するために用いている。さらに、ミニバッチを実装するためのより具体的形態は、サーガトランザクション処理モデルとして導入されている。サーガトランザクション処理モデルは、１９８７年にGarcia-MolinaとSalemによってはじめて発表された。そのアルゴリズムは、GrayのTransaction Processing Fundamentalsの本にやや詳細に論じられている。要約すれば、サーガ(saga)とは、定義された補償モデルを有するフラットな連鎖型の一連のトランザクションのことである。補償モデルは、次のように、もとの実行経路の逆となるように定義される。
Ａ１，Ａ２，Ａ３，... Ａｎ−１，Ａｎ ｜ −Ａｎ−１，...−Ａ３，−Ａ２，−Ａ１
Ａ１，Ａ２，Ａ３，... Ａｎ−１，Ａｎ ｜ −Ａｎ−１，...−Ａ３，−Ａ２，−Ａ１
ビジネスアプリケーションにおける大部分のバッチ処理はミニバッチモデルの境界内に当てはまる。「境界(bound)」という用語は慎重に選択されている。というのは、モデル全体に当てはまる処理のいくつかのサブタイプがあるからである。本明細書に開示される静的プロセスクラスは、以下のサブタイプをサポートするであろう：
・サーガ標準的なサーガの定義（上に提示）は順序付きサーガである。すなわち、補償が、もとの実行シーケンスと厳密に同じ順序（ただし、逆順であるが）で実行されることが保証される。さらに、失敗の場合、サーガは開始ポイントに復帰する。
・チェックポイント付きサーガ（ミニバッチ）−（Grayによって「ミニバッチ」とも呼ばれている）チェックポイント付きサーガ(Checkpointed-Saga)は、バッチ処理においてきわめて重要である。年度末決算のような巨大なバッチ処理オペレーションを考える。年度末決算は、数百ギガバイトのデータの移動または削除を行う可能性のあるアーカイブプロセスである。厳格なサーガモデルによれば、トランザクションの失敗は、Ｎ−１から１までさかのぼって補償トランザクションを実行することにより、作業単位全体をロールバックする。これは、年度末決算のような非常に大きいバッチプロセスの場合には好ましくない選択であろう。しばしば、バッチ処理オペレーションは夜間または週末に実行される。バッチプロセスは通常数時間実行され、規定の時間フレーム内に完了しなければならない。年度末決算が週末いっぱい実行され、失敗したので最初にロールバックするというのでは許されないであろう。チェックポイント付きサーガプロセスは、チェックポイントモデルをサポートできなければならない。チェックポイントは、作業サブ単位の正常完了を示す。一度チェックポイントが実行されれば、補償連鎖は断ち切られ、以後の失敗が、完了した作業サブ単位にロールバックすることはない。
・サーガ標準的なサーガの定義（上に提示）は順序付きサーガである。すなわち、補償が、もとの実行シーケンスと厳密に同じ順序（ただし、逆順であるが）で実行されることが保証される。さらに、失敗の場合、サーガは開始ポイントに復帰する。
・チェックポイント付きサーガ（ミニバッチ）−（Grayによって「ミニバッチ」とも呼ばれている）チェックポイント付きサーガ(Checkpointed-Saga)は、バッチ処理においてきわめて重要である。年度末決算のような巨大なバッチ処理オペレーションを考える。年度末決算は、数百ギガバイトのデータの移動または削除を行う可能性のあるアーカイブプロセスである。厳格なサーガモデルによれば、トランザクションの失敗は、Ｎ−１から１までさかのぼって補償トランザクションを実行することにより、作業単位全体をロールバックする。これは、年度末決算のような非常に大きいバッチプロセスの場合には好ましくない選択であろう。しばしば、バッチ処理オペレーションは夜間または週末に実行される。バッチプロセスは通常数時間実行され、規定の時間フレーム内に完了しなければならない。年度末決算が週末いっぱい実行され、失敗したので最初にロールバックするというのでは許されないであろう。チェックポイント付きサーガプロセスは、チェックポイントモデルをサポートできなければならない。チェックポイントは、作業サブ単位の正常完了を示す。一度チェックポイントが実行されれば、補償連鎖は断ち切られ、以後の失敗が、完了した作業サブ単位にロールバックすることはない。
チェックポイント付きサーガの導入によって、静的プロセスを「再開」するインフラストラクチャが必要となる。したがって、チェックポインティングを実装する静的プロセスはべき等性をもたければならない。システム障害の結果として再開される静的プロセスは、すでに完了している作業単位を正しく「スキップ」して、べき等性動作を保証しなければならない。
アクティビティは、データベースに対して委ねられた変更を「アンドゥー」するための補償インタフェースを提供する。しかし、「誰が補償インタフェースを呼び出すことになるのか？」という疑問が残る。必要となるのは、複数の物理トランザクションにわたる原子的作業を管理することが可能なトランザクションマネージャである。
あらゆるトランザクションシステムは、ビジネスロジック処理の最初から最後までのライフサイクルを制御するトランザクションマネージャを必要とする。トランザクションマネージャは、処理の結果が原子性、一貫性、分離性、および持続性を有することを保証する。所与のトランザクションマネージャは通常、より高度な同時並行性を優先して厳格なＡＣＩＤモデルが緩和されることを可能にするであろう。
トランザクションマネージャは常に、ビジネスロジック更新の制御をしなければならない。もちろん、市販のＳＱＬサーバはトランザクションマネージャを含む。このようなトランザクションマネージャは、すべてのビジネスロジック処理が単一の物理データベーストランザクションの一部として実行可能な限り動作する。これらのトランザクションマネージャは、特に読み出し側における低レベルの分離性を許容するさまざまなノブおよび制御機能を含んでいる。これらの制御機能は有用であり、そして実際、一部の製品は分離性のレベルを低減された「リードコミッティド(Read Comitted)」で完全に実行することができる。しかし、これらの低い分離レベルが有用であればあるだけ、トランザクションが約束（ｃｏｍｍｉｔ）するまでは、書き込まれるレコードにはロックが依然として掛けられなければならない。
トランザクションが複数の物理データベーストランザクションにわたらなければならない場合、「組込みの」ＳＱＬサーバトランザクションマネージャではもはや十分ではない。ビジネスアプリケーションにおける長時間の処理には、単一のデータベーストランザクションを使用することはできない。その代わりに、厳格な方法で補償をサポートするトランザクションマネージャが使用されなければならない。
上述の通り、BizTalk Orchestration（ＢＴＯ）によって、長時間処理に対するトランザクション管理義務のための１つの可能性ある選択肢が得られる。長時間プロセスと類型の例としてはワークフローがある。ＢＴＯは、ワークフローシステムのための基盤を提供するように設計されている。ワークフローが実際に実装されているのであれば、オーケストレーションは優れた選択肢である。しかし、ＢＴＯは補償トランザクションマネージャを提供するだけである。ビジネスアプリケーションは、ＢＴＯが呼び出すためのビジネスロジックを依然として提供しなければならない。このビジネスロジックは、補償ビジネスロジックが公開するインタフェースを実装しなければならない。これは、本明細書に開示される「ビジネスアクティビティ」がまさに供給するものである。
完全なソリューションは単に、単一のデータベーストランザクション処理にはＳＱＬサーバを使用し、複数のデータベーストランザクション処理にはＢＴＯを使用することであるかのように思われるかもしれない。しかし、これは理想的なソリューションではない。非ワークフロー指向の補償トランザクションマネージャが非常に必要となる。ビジネスアプリケーションには、同時並行性の理由から複数のデータベーストランザクションが必要とされる多くのシナリオがあるが、ＢＴＯはトランザクションマネージャとして利用するにはただあまりに扱いにくい。主として２つの問題点がある。性能(Performance)とワークフローバゲージ(Workflow Baggage)である。
ＢＴＯトランザクションマネージャは、ワークフローのすべての参加者がＣＯＭ＋ トランザクションを実装することを要求する。ＣＯＭ＋ トランザクションは、ＤＴＣの上に位置し、ＤＴＣはＳＱＬサーバの基本プロトコルの上に位置する。ＤＴＣが呼び出されるとすぐに、２相コミットが実行される。これは、重大な性能の影響を生じる。というのはこの場合、２相プロトコルを実装するために少なくとも２つのログ（通常はさらに多い）と、多くのプロセス間呼出しがあるからである。性能テストによれば、ＤＴＣを使用すると、基本的なＳＱＬサーバの「BEGIN TRAN」型のオペレーションを使用するよりも３〜８倍遅くなることが示されている。
ＣＯＭ＋は、各オブジェクトを「コンテキストバインド」オブジェクトにするというオーバーヘッドを追加する。基本的に、ＣＯＭ＋は、トランザクションオブジェクトに対するすべてのメソッド呼出しがトランザクションを開始および委ねるのを（メソッドレベルで）必要に応じてインターセプトする能力を必要とする。これがさらにオーバーヘッドを追加する。
性能分析によれば、ＣＯＭ＋ トランザクションは、データベースレコードを読み書きする作業全体よりも多くのオーバーヘッドが（それ自体で）課されることが示される。このため、基本的なＳＱＬサーバの「BEGIN TRAN」コマンドを優先して、ＣＯＭ＋ トランザクションの使用を回避するために、エンティティ永続性が再構築されている。
ワークフローバゲージは、ＢＴＯをトランザクションマネージャとして使用する場合のもう１つの問題である。ＢＴＯは強力で柔軟な環境であるが、このような能力はオーバーヘッドを伴うものである。ビジネスロジックが、単一のデータベーストランザクションの内部で存続するにはあまりに長い間実行されるものの、従来のワークフロー類型には確実には収まらない多くの場合が存在する。
販売注文の例を考える。各販売注文には作成時にＩＤが割り当てられる。このＩＤは人間が読むことが可能であり、あるテンプレート（例えばSALESXXXXX）に従う。この最初の注文は「SALES00001」であり、次は「SALES00002」である、などとなる。これらの識別子の割当てを高い性能で行うことは驚くほど困難である。これらの識別子の割当てを扱う唯一の実現可能な方法は、それらをサブトランザクションで作成し、補償モデルによって穴埋めを処理することである（Grayの用語では、これは単調性要件を緩和することであるが、補償はアルゴリズムを読み出し可能かつ密に保つ）。この例は、複数の物理データベーストランザクションにわたることが可能なトランザクションマネージャを要求するが、ワークフロー＼ＢＴＯの候補ではない。注文ＩＤを割り当てるアクションは、いかなるタイプの「再構成可能なワークフロー」も要求しない。注文ＩＤを割り当てるアクションは、開発者がＸＬＡＮＧスケジュールを作成することを要求すべきではない。また、注文ＩＤを割り当てるアクションは、ＣＯＭ＋ トランザクション全体を要求すべきでもない。本当に要求されるのは、非常に軽量のトランザクションマネージャだけである。ＣＯＭ＋ トランザクションのオーバーヘッドは、必要でもなく望ましくもない。多くの場合、ＤＴＣの２相コミットオーバーヘッドもまた、必要でも望ましくもない。ほとんどの場合は単一のＳＱＬサーバを使用するだけであろう。軽量トランザクションマネージャは単に、そのトランザクションコンテキストを、ビジネスロジックが使用するのと同じデータベースに格納し、したがって単一のログに「ピギーバック」することができるだけである。
これらの場合に対処するため、新しい補償トランザクションマネージャが実装される。補償トランザクションマネージャは、BusinessEntityクラスを介して現れるであろう。静的プロセスは、Ｃ＃プログラミング言語で書かれ、BusinessEntityを継承し、BusinessActivityを呼び出すのが望ましい。エンティティ内部の補償トランザクションマネージャは、必要なログレコードのロギングおよび消去とともに、物理トランザクション管理を扱う。
アクティビティは、「スタンドアローン」では実行されず、むしろ常にサーガ全体における１ステップとなる。サーガはアクティビティの論理グルーピングを形成するので、多重実行されるアクティビティはトランザクションとして正確な方法で確認またはアボートすることができる。利用者は、たとえ単一のアクティビティを実行したいだけであっても、アクティビティの実行をサーガ内に包含（ｗｒａｐ）することになる。利用者により実行される単一のアクティビティが、他の多くのアクティビティを内部的に入れ子（ｎｅｓｔｅｄ ｆａｓｈｉｏｎ）で呼び出す可能性があることから、これは重要である。したがって、利用者は単一のアクティビティを実行しているように思うだけであるが、実際には、原子性を持って確認またはアボートすることが必要な複数のアクティビティを実行している。その調整がサーガを用いて提供される。
図４に示すように、本質的に３種類のアクティビティ利用者がある。すなわち、動的プロセス３００（ワークフローともいう）、静的プロセス３０２、およびエンティティ３０４である。最初は、エンティティ３０４がこのリストに含まれることは奇妙に見えるかもしれない。しかし、エンティティ３０４はアクティビティを呼び出せることが必要である。アクティビティは常に「あるプロセス内のステップ」であるため、どうにかエンティティがプロセスのいくつかの側面を有することができるようにする必要がある。各アクティビティ利用者３００、３０２、および３０４は、３０６に示すようにサーガを始め、３０８に示すようにアクティビティを実行し、および３１０に示すようにサーガを完了することができる。さらに、アクティビティはまた、３１２に示すように追加の入れ子となったアクティビティを実行することもできる。そして最後に、サーガは、サーガを確認すること（３１４）によって、またはサーガをアボートすること（３１６）によって完了することができる。
各エンティティに組込みの「ライフサイクルプロセス」を与えることにより、プロセスの少なくともいくつかの態様をエンティティに提供することができる。各エンティティのグラフは、それがインスタンス化される時に組込みプロセスを開始し、保存または削除される時にプロセスを完了する。
エンティティおよびそれらに関連する仮想集合は、図５に示す単純で一貫性のある論理プログラミングモデルをそれらの利用者に提供する。すなわち、利用者３４０はサーバ上で（エンティティの仮想集合を介して）エンティティのグラフをインスタンス化し（３４２）、利用者３４０は利用者のクライアント上でエンティティのグラフと対話し（３４４）、利用者３４０はサーバ上で（エンティティの仮想集合を介して）エンティティのグラフを保存または破棄（永続化）する（３４６）。
このモデルは、エンティティ利用者のこの規則を破るものをプログラミングモデルに導入することは避けなければならないことから重要である。
利用者の例示的なプログラミングモデルは次の通りである：
order = orderVC.FindByID("TIMORDER");
order.Address.ZipCode = "58078";
order.OrderLines[1].Qty += 2;
orderVC.Save(order);
order = orderVC.FindByID("TIMORDER");
order.Address.ZipCode = "58078";
order.OrderLines[1].Qty += 2;
orderVC.Save(order);
この例では、両方の変更（郵便番号(ZipCode)と商品の個数(Qty)）が、原子性をもって持続的に約束されるため、データベースは一貫性が保たれる。また、次のように規則の「破棄」の場合をサポートすることも重要である：
order = orderVC.FindByID("TIMORDER");
order.Address.ZipCode = "58078";
order.OrderLines[1].Qty += 2;
order = null;
order = orderVC.FindByID("TIMORDER");
order.Address.ZipCode = "58078";
order.OrderLines[1].Qty += 2;
order = null;
この例では、いずれの変更もデータベースに対して永続化されなければならない。
本発明の態様にしたがって、使者に基づく手法が本来的に非連結モデルに適用される。仮想集合からの読み出しによって使者（当該エンティティ）が返される。利用者はその（非連結的）使者と対話する。利用者は、終了する時、仮想集合上のSave()メソッドにより使者をその管轄下（ｆｉｅｆｄｏｍ）に返す。使者に対するいかなる変更もすべて、永続化のために管轄下に戻される。
永続化は、エンティティ全体が一度にサーバに流れることから、基本的に原子性のあるオペレーションである。エンティティのグラフ全体は、図６の長方形３８０で示すように、１つの物理データベーストランザクションに永続化される。物理トランザクションはサーバ上にのみ存在することができる。したがって、長方形３８０のようなトランザクション長方形は、決してクライアント側にまたがることはない。
すべてのエンティティが完全に非連結的とすることができれば設計はずっと簡単であろうが、物事は一般にはより複雑である。多くの場合、顧客の要求は、より連結的なモデルでそのビジネス要求を満たすことを命じる。例えば、古典的な「航空券予約」シナリオを考える。顧客は、（１）予約エージェントに働きかけて航空機の空席を探し、（２）座席を見つけ、（３）クレジットカードおよび住所情報を提示し、および（４）予約が保存される。このシナリオでは、料金請求情報が追加されている最中に、選択した座席が他の誰かに奪われないことが十分に期待される。これは古典的な「リース」のシナリオである。
使用例の一例は、航空券リースのシナリオである。このシナリオは、エンティティと顧客との対話の一部がサーバへの呼出しを行うので「連結」である。この場合、座席の予約をするためサーバとの間の往復が生じる。予約は、データベースを更新し、他の予約エージェントが予約された席を奪うことがないようにその結果を約束する。なお、すべてのアクティビティリースオペレーションは、エンティティ利用者およびエンティティ著作者の両方にとって完全に透過的であるのが望ましいことに留意されたい。エンティティは単にBusinessEntityを継承してから、BusinessActivityクラスを継承している座席リースアクティビティを呼び出す。リースをロギングしそれを清掃することに関連するすべてのインフラストラクチャは自動的に行われる。
本発明の一態様によれば、このシナリオは、次の例示的なエンティティ利用者コード（単純化されている）で示すことができる：
order = orderVC.Create();
// 新しい航空券「注文(order)」を作成する
order.OrderLines.Add();
// 旅行のこの行程を表す項目を追加
order.OrderLines[1].Qty = 1;
// １つの座席の「購入」を表す。これはリースを受けなければならない
order.Address.ZipCode = "58078";
// 料金請求情報のエントリを表す
orderVC.Save(order);
// 実際に注文を永続化する
order = orderVC.Create();
// 新しい航空券「注文(order)」を作成する
order.OrderLines.Add();
// 旅行のこの行程を表す項目を追加
order.OrderLines[1].Qty = 1;
// １つの座席の「購入」を表す。これはリースを受けなければならない
order.Address.ZipCode = "58078";
// 料金請求情報のエントリを表す
orderVC.Save(order);
// 実際に注文を永続化する
なお、このタイプの機能は分散システムにとって重要であることに留意されたい。分散システムは、何らかの形の管轄（fiefdom）−使者（emissary）モデルに基づくことが必要となる。各管轄は、分散システムの他のすべての部分を完全に「信頼」することはできない。管轄は、（座席予約のような）外部当事者による管轄データへの管理されないコミットを決して許容することはできない。サーガマネージャによれば、本発明の諸実施形態を使用するアプリケーションは、作業単位全体が管轄に入る時に自動的に確認されるリース型の管轄インタラクションを自動的に取得することができる。
エンティティ利用者のプログラミングモデルが破壊されてはならないことを想起されたい。この利用者は、データベースを一貫性のないものにすることが許されてはならない。例えば、クライアントが（order = nullと設定するようなことをするか、またはクラッシュによって）注文を全く保存しない場合、このような場合を検出し座席リースを解放するメカニズムが用意されておくべきである。図７は、「行儀の良い」エンティティ利用者を示す使用例を示している。エンティティ利用者４００は、（この設計の一部として追加されている）仮想集合上のAbort()メソッド４０２を呼び出しているので行儀が良い。これにより、補償トランザクションマネージャは、エンティティが予約したいかなるリースも直ちに解放することができる。
図８は、アボートを呼び出すこと（４１４）なくエンティティを単に破棄する（４１２）「行儀の悪い」エンティティ利用者４１０を示す使用例を示している。この場合、タイムスタンプ手法を用いて、ステイル(stale)リースが検出される。「清掃（ｃｌｅａｎ ｕｐ）エージェント」４１６が、定期的にリースログテーブルをスキャンして清掃すべき非常に古いリースを探索し、そのようなリースが検出されたらアボートを呼び出す（４１４）。清掃エージェント４１６のアルゴリズムには、ソリューションフレームワークの「差し替え可能な(pluggable)ポリシー」が残される。３つの典型的な選択肢として、発見的コミット(Heuristic Commit)、発見的アボート(Heuristic Abort)、およびオペレータ介入(Operator Intervention)があることが望ましい。
エンティティは機動的である。典型的な使用パターンでは、エンティティは管轄を出て、利用者への使者として働く。エンティティは、管轄の外部にある時、完全に非連結的であることもあり、またはリースを受けるアクティビティを呼び出すことによって、より連結的なモデルを実装することもある。しかし、どこかの時点でエンティティは、有益な作業が行われるためには、管轄に再び入ることが必要である。エンティティは、管轄の外部にある時望むだけの数のリースを受けることができる。しかし、それらのリースは、エンティティが管轄に再び入ることに成功して永続化されなければ、すべて期限切れとなる。
ビジネスロジックアクティビティには、エンティティが管轄に再び入る時に生じる必要のあるかもしれないものが数多くある。管轄は通常、外部世界からの要求を信頼しない。管轄は通常、入ってくる使者（当該エンティティ）を検証するために、サーバ側ビジネスロジックを実行することを望むであろう。
サーバ側エンティティがデータベース更新を実行することになるような場合が多い。例えば、サーバ側エンティティビジネスロジックの最も単純な場合は、Entity -> Entity、である。これは、論理トランザクションモデルの規則、すなわち、永続するエンティティは常に「Requires」セマンティクスを使用するという規則を示している。第１のエンティティは、物理トランザクションが存在しないため、物理トランザクションを開始する。しかし、第２のエンティティは、新たに開始するのではなく、第１のエンティティのトランザクションに参加（ｅｎｌｉｓｔ）する。これは「Requires」の定義である。図９は、エンティティ利用者４３０がエンティティをインスタンス化し（４３２）、そのエンティティを変更し（４３４）、そしてそのエンティティを永続化する（４３６）という使用例を示している。しかし、そのエンティティが永続化されると、別のエンティティをインスタンス化し（４４０）、そのエンティティを変更し（４４２）、そしてそのエンティティを永続化する（４４４）というイベントを始動する（４３８）。
図１０は、エンティティのサーバ側永続化の期間中に実行されるアクティビティがどのように構成されるかを示す使用例を示している。これは基本的には、連結エンティティがクライアントからのアクティビティと対話する場合と同じ例である。なお、この使用例は、アクティビティ(Activity)の主要なトランザクション特性を実証していることに留意されたい。アクティビティは、エンティティのトランザクションに参加していない。アクティビティは、別のアクティビティのトランザクションに参加するだけである。（たとえエンティティがすでに永続化されているとしても、実行アクティビティは新しい物理トランザクションを開始した。）これは、非常に望ましい利点である。例えば、ある販売注文を考える。販売注文は、管轄に入ると、多くのアクティビティを実行しなければならない。例えば、販売注文の各品目は在庫から割り当てられなければならない。サーバ側ビジネスロジック実行インフラストラクチャは、各品目に対して、その品目が新規であるか、それともすでに存在しているが変更されたかに応じて、BeforeInsertまたはBeforeUpdateイベントを呼び出すことになる。販売注文商品に対するBeforeXXイベントは、各商品ごとに「AllocateInventory」アクティビティを呼び出すことになる。
これらの割当て呼出しのそれぞれを別々のデータベーストランザクションで実行することは非常に望ましい。別法として、アクティビティ呼出しを主要な永続化トランザクションに参加させることがある。これにより、注文全体が永続化されている間に、データベースのロックがすべての在庫量の利用可能なレコードで掛けられる。これは、許容できないほど長い時間、ロックを掛け続けることになり、かなりの同時並行性の不具合を引き起こす。
エンティティとアクティビティの間でどのように物理トランザクションが構成されるかについての規則は次のように記述される：
エンティティは常に、実行中の物理トランザクション内で構成され（「Requires」セマンティクス）、
アクティビティは決して他のトランザクションとともに構成されることはない（「RequiresNew」セマンティクス）。
エンティティは常に、実行中の物理トランザクション内で構成され（「Requires」セマンティクス）、
アクティビティは決して他のトランザクションとともに構成されることはない（「RequiresNew」セマンティクス）。
なお、アクティビティの参加について、より柔軟なモデルを提供することを排除するものは何もないことに留意されたい。しかし、RequiresまたはRequiersNewに対してその都度アクティビティに基づく「スイッチ(switch)」を可能にすることは困難である。１つの固定した動作(behavior)だけしか存在し得ない場合、それは「RequiresNew」でなければならない。さもなければ、エンティティおよびアクティビティは両方ともRequiresであることになるが、複数の物理データベーストランザクションで実行されるものを構築することは不可能である。しかし、アクティビティがRequiresまたはRequiresNewセマンティクスに対する意図を宣言することができるスイッチを追加することなら可能であると考えられる。これは、依然として複数のデータベーストランザクションを使用する一方で、なおグループ化することができる柔軟性を開発者に与えるであろう。
複数のエンティティが実行中の場合、エンティティは常に現在のトランザクション内で構成される。次の２つの使用例は、２つの可能な結果を実証する。図１１に示す第１の例では、エンティティはアクティビティ実行中に永続化されるため、そのアクティビティのトランザクションが実行中（ｃｕｒｒｅｎｔ）である。
図１２に示す第２の例は、イベントハンドラ内で実行中のコードがエンティティを順次更新した後、アクティビティを呼び出す場合である。この場合、エンティティは、主要なエンティティのトランザクションに参加する。（しかし、アクティビティは参加しない。というのは、アクティビティは「RequiersNew」だからである。）
アクティビティがどのように構成されるかは重要な設計上の考慮事項である。重要な設計点は、入れ子になっているアクティビティがどのようにアボートされ確認されるかである。アクティビティのアボートおよび確認は、ログレコードを書き出すことにより内部的に制御されるのが望ましい。ログレコードにより、システムは、アクティビティのアボートまたは確認を「覚えておく」ことができる。これは、プログラミングモデルに影響するので重要である。
図１３および図１４は、個別のログを使用するか、それとも親ログのみを使用するかという設計上の選択肢を対比する使用例を示している。最初は、これらの設計は両方とも妥当に見えるかもしれない。２つの手法の差は、Abort()およびConfirm()がどのように扱われるかをみると明らかになる。選択肢＃１（図１３）は、各アクティビティごとに個別のログレコードを発行する。選択肢＃２（図１４）は、「親」アクティビティについてのログレコードを発行するだけである。
システム障害の場合、サーガマネージャは、選択肢＃１では両方のアクティビティに対するAbort()を呼び出す。しかし、選択肢＃２では、サーガマネージャは第１のアクティビティに対するAbort()を呼び出すだけである。これは、コードが第１のアクティビティにとってどう見えるかに影響する。アクティビティ「Ｘ」がアクティビティ「Ｙ」を呼び出す第１のアクティビティであるという次の例を考える：
public class IncrementX_Service :
BusinessActivityService {
protected override void Execute (BusinessActivity
ActivityAgent) {
// 自分自身の処理を行う...
StoredProc.Execute("IncrementXProc", ActivityAgent.X);
// ここで他のアクティビティを呼び出すことに決める
IncrementY = (IncrementY)ActivityFactory.Get
(typeof(IncrementY), ActivityAgent);
IncrementY.Y = ActivityAgent.X * 2;
ActivityFactory.Execute(IncrementY);
}
// 選択肢＃２：親ログのみ
protected override void Abort (BusinessActivity
ActivityAgent) {
// 自分自身のデータをアンドゥーする（下記のマイナスに注意）...
StoredProc.Execute("IncrementXProc", -
ActivityAgent.X);
// サーガマネージャは呼び出さないので、"X"は"Y"に対するアボートを呼び出さなければならない。
IncrementY = (IncrementY)ActivityFactory.Get
(typeof(IncrementY), ActivityAgent);
IncrementY.Y = -ActivityAgent.X * 2;
ActivityFactory.Execute(IncrementY);
}
// 選択肢＃１：個別のログ
protected override void Abort (BusinessActivity
ActivityAgent) {
// 自分自身のデータをアンドゥーする（下記のマイナスに注意）...
StoredProc.Execute("IncrementXProc", -
ActivityAgent.X);
// "Y"に対するAbort()を呼び出すことはできない。サーガマネージャが呼び出すから
}
}
public class IncrementX_Service :
BusinessActivityService {
protected override void Execute (BusinessActivity
ActivityAgent) {
// 自分自身の処理を行う...
StoredProc.Execute("IncrementXProc", ActivityAgent.X);
// ここで他のアクティビティを呼び出すことに決める
IncrementY = (IncrementY)ActivityFactory.Get
(typeof(IncrementY), ActivityAgent);
IncrementY.Y = ActivityAgent.X * 2;
ActivityFactory.Execute(IncrementY);
}
// 選択肢＃２：親ログのみ
protected override void Abort (BusinessActivity
ActivityAgent) {
// 自分自身のデータをアンドゥーする（下記のマイナスに注意）...
StoredProc.Execute("IncrementXProc", -
ActivityAgent.X);
// サーガマネージャは呼び出さないので、"X"は"Y"に対するアボートを呼び出さなければならない。
IncrementY = (IncrementY)ActivityFactory.Get
(typeof(IncrementY), ActivityAgent);
IncrementY.Y = -ActivityAgent.X * 2;
ActivityFactory.Execute(IncrementY);
}
// 選択肢＃１：個別のログ
protected override void Abort (BusinessActivity
ActivityAgent) {
// 自分自身のデータをアンドゥーする（下記のマイナスに注意）...
StoredProc.Execute("IncrementXProc", -
ActivityAgent.X);
// "Y"に対するAbort()を呼び出すことはできない。サーガマネージャが呼び出すから
}
}
選択肢＃２が使用される場合、各アクティビティは、それが対話する相手となるいかなるアクティビティへのConfirm()呼出しも「パススルー(pass-through)」しなければならないことになる。確認(confirm)はめったに使用されないことが予想されるため、アプリケーション開発者に呼出しをパススルーさせることは、エラーを起こしやすくして厄介であると思われる。さらに、それは性能の問題でもある。開発者は、めったに使用されない時にも常にConfirm()を呼び出すことになる。
したがって、本発明の態様では、いくつかの理由で選択肢＃１、すなわち個別のログを使用するのが望ましい。第１に、プログラミングモデルの視点からは、Confirm()呼出しをパススルーすることは、人によってはあまりに厄介であると考えるかもしれない。しかし第２に、より重要なことであるが、選択肢＃２は見かけほど効果的ではない。選択肢＃２の図は、第２のアクティビティが、ログレコードを書き出すことなく、自分自身のトランザクション内で実行されることを示している。これは望ましくない。例えば、アクティビティ＃２がその変更をデータベースにコミットした直後であるがアクティビティ＃１が終了する前に電源が切れたと仮定すると、システムは、アクティビティ＃２が実行されたことを「忘れて」しまい、そのアボートまたは確認メソッドを実行しないであろう。
親のみのログをサポートすることができる唯一の方法は、図１５に示すように、すべての子アクティビティが親のトランザクションコンテキスト内で実行されるよう強制することである。これは実質的に、複雑な静的プロセスを構築するようにアプリケーション開発者の自由を拘束し、許容できない妥協策であると思われる。
トランザクションの正確さは、本発明の実施形態の場合、いくつかの規則に従う限り保証される。第１に、いかなるサブトランザクションも、ログレコードをトランザクションの一部として書き出さなければならない。これがなされない場合、電源が切れた時に、約束された作業が忘れられてしまうリスクがある。第２に、いかなるサブトランザクションも補償をサポートしなければならない。システムは、いったんトランザクションが約束された後は、ＳＱＬサーバのロールバックに頼ることはできないため、サブトランザクションは「アンドゥー」オプションを有していなければならない。これは、いかなるサブトランザクションも、補償インタフェースを供給するために何らかの形の「ルート(root)」アクティビティを有するべきであることを意味する。なお、エンティティは補償インタフェースをサポートしないことに留意されたい。したがって、エンティティのいかなる永続化も、アクティビティの「下」にあるか（その場合、そのアクティビティが補償を供給する）、または「ルート」自体にあるかのいずれかでなければならない。エンティティ利用者は、一度エンティティが保存された後は、それを「アンドゥー」することができないと解釈する。
動的プロセス（ワークフロー）は、多くのステップからなるプロセス全体を実装する。各ステップは、（１）タスク項目(TaskItem)（ユーザ承認）、（２）別の動的プロセス、または（３）ビジネスロジック、の３つのうちの１つであり得る。アクティビティは、ワークフローが「ビジネスロジックステップ」を実行するための実装メカニズムである。なお、ワークフローは通常、一時に単一のアクティビティを実行することが予想されることに留意されたい。しかし、前に論じたように、単一の「ルート」アクティビティが、ネ入れ子で多くの他のアクティビティを内部的に実行する可能性もある。これらのすべてのアクティビティは一貫性のある方法で確認またはアボートされる必要がある。このため、ワークフローは常にサーガマネージャを通して働くことになる。各アクティビティステップごとに、ワークフローは次のことを行う：
SagaManager.Begin()を呼び出してサーガを開始し、
ActivityFactoryを介してActivityを実行し（通常は単一アクティビティのみ）、
SagaManager.Confirm()を呼び出してサーガを完了する。
SagaManager.Begin()を呼び出してサーガを開始し、
ActivityFactoryを介してActivityを実行し（通常は単一アクティビティのみ）、
SagaManager.Confirm()を呼び出してサーガを完了する。
サーガマネージャを使用することは、いかなる入れ子になったアクティビティ呼出しも正しく扱われることを保証する。
静的プロセスとエンティティとは多くの類似点を有する。両方ともサーガ機能を必要とする。例えば、上記の航空券の場合は、エンティティが座席についてリースを受けることを必要とする例である。これは、サーガがエンティティによって駆動される場合であり、エンティティはサーバの外部に位置する。バッチ処理シナリオの例もまた提供されている。このシナリオは、静的プロセスと呼ばれてきたものによって駆動される。これらの場合における静的プロセスはサーバ側で実行される。
本発明の実施形態による長期トランザクションをサポートするために利用可能なフレームワークの具体例を提供するため、アクティビティおよびエンティティの両方に対するいくつかの要件を以下に示す。要件の第１のセットは、アクティビティ状態遷移に関するものである。ログレコード、およびそのログレコードに対する（それらが作成または削除される場合のような）オペレーションの存在は、ここに記載される状態遷移要件をサポートするためにのみ存在する内部実装の問題とみなされる。これらの要件は、エンティティであるかワークフローであるかにかかわらず、サーガマネージャを介してアクティビティを実行するいかなるものにも適用される。
次の要件のセットは、いかなるアクティビティ拡張にも有効である。エンティティによって、およびワークフローによって実行されるアクティビティは、好ましくは、すべて以下の要件を守る。
各エンティティグラフは、そのエンティティグラフがアクティビティを呼び出すことを可能にする組込みの「ライフサイクルプロセス」を有する。以下の要件は、このライフサイクルプロセスがどのように働くかについての規則を示す。
論理トランザクションコンテキストは、エンティティグラフに対し一意である。しかし、静的プロセスのような上位レベルのシナリオは、複数のエンティティグラフにわたるアクティビティオペレーションを追跡しグループ化することができると有益であろう。したがって、「論理トランザクショングループ(Logical Transaction Group)」の概念が導入される。論理トランザクショングループは、複数の論理トランザクションコンテキストにわたるアクティビティオペレーションがグループ化されることを可能にする。論理トランザクションコンテキストは、このエンティティグラフが属する「グループ」を表すGuidを含む。論理トランザクショングループに対する要件は次の通りである。
そして最後に、２つの一般的なアクティビティ規則がある。それらは次の通りである。
本発明の諸実施形態の１つの重要な目的は、ビジネス領域に照準を合わせているアプリケーション開発者がその技術的判断において支援されるような規範的アーキテクチャを提供することである。このため、この複雑なトランザクションの問題が、合理的なプログラミングモデルにおけるフレームワークを通して明らかになる。これは、次のプログラミングモデルで実現される：
Activity Agent Class:
using Microsoft.BusinessFramework.Activity;
public class MyActivity: BusinessActivity {
private decimal foo;
protected MyActivity() {};
public decimal Foo {
set {
foo = value;
}
get {
return(foo);
}
}
public override bool IsValid() {
// 有効(valid)であるかどうかを判断するロジックを追加する
if (foo < 10) {
return true;
}
return false;
}
}
Activity Service Class:
using Microsoft.BusinessFramework.Activity;
public class MyActivityService:
BusinessActivityService {
protected override object Execute
(BusinessActivity activityAgent) {
myActivity = (MyActivity)ActivityAgent;
// アクティビティを実行するビジネスロジックをここに書く
// 入力値を捕捉するためにActivityAgentをMyActivityにキャストしなければならない：
bar = (MyActivity)ActivityAgent.Foo;
}
protected override void Abort (BusinessActivity
activityAgent) {
// アクティビティを取り消すビジネスロジックをここに書く
// 任意。しかし実装されない場合、何らかのアプリケーションレベルでなければならない。
// このアクティビティの作業を確実にするためにインフラストラクチャがロールバックされる。
}
protected override void Confirm
(BusinessActivity activityAgent) {
// アクティビティを確認するビジネスロジックをここに書く
// 任意。監査型または清掃型のアクティビティのために使用可能
}
}
Activity Agent Class:
using Microsoft.BusinessFramework.Activity;
public class MyActivity: BusinessActivity {
private decimal foo;
protected MyActivity() {};
public decimal Foo {
set {
foo = value;
}
get {
return(foo);
}
}
public override bool IsValid() {
// 有効(valid)であるかどうかを判断するロジックを追加する
if (foo < 10) {
return true;
}
return false;
}
}
Activity Service Class:
using Microsoft.BusinessFramework.Activity;
public class MyActivityService:
BusinessActivityService {
protected override object Execute
(BusinessActivity activityAgent) {
myActivity = (MyActivity)ActivityAgent;
// アクティビティを実行するビジネスロジックをここに書く
// 入力値を捕捉するためにActivityAgentをMyActivityにキャストしなければならない：
bar = (MyActivity)ActivityAgent.Foo;
}
protected override void Abort (BusinessActivity
activityAgent) {
// アクティビティを取り消すビジネスロジックをここに書く
// 任意。しかし実装されない場合、何らかのアプリケーションレベルでなければならない。
// このアクティビティの作業を確実にするためにインフラストラクチャがロールバックされる。
}
protected override void Confirm
(BusinessActivity activityAgent) {
// アクティビティを確認するビジネスロジックをここに書く
// 任意。監査型または清掃型のアクティビティのために使用可能
}
}
Execute()メソッドの内部で、アクティビティ著作者は、エンティティＣＲＵＤ（作成(Create)、読み出し(Read)、更新(Update)、削除(Delete)）、エンティティSetOps、またはStored Procの呼出しのように、おおむねいかなる所望のオペレーションも実行可能である。返値はExecute()メソッドの「object」返値によって返される。「needsConfirm」および「needsAbort」パラメータは、ログレコードの抑制を可能にして性能を最適化するものである。アクティビティが、確認またはアボートの通知を必要としていないことを示している場合、サーガマネージャはこのアクティビティのためのログレコードの書き出しを必要としない。ただし、このアクティビティに対する確認またはアボートメソッドへの加入者がある場合には依然としてログレコードが書き出されることに留意されたい。
プログラミングモデルはまた、部分的に、アクティビティファクトリ(Activity Factory)の提供によってもサポートされる。
public class ActivityFactory: Agent {
public static BusinessActivity Create (type
DesiredType, ILogicalTransactionContext
Ctx);
public static object Execute (BusinessActivity
ActivityAgent);
public static void Abort (BusinessActivity
ActivityAgent);
// Confirm()はここには現れないことに注意。フレームワークのみが確認を行うことができるべきである。
// Abort()の呼出しはこのアクティビティをアボートするだけである。すべてをアボートするには、ＶＣ上のAbortを呼び出すこと。
}
Activity Consumer (Entity calling Activity):
public class OrderLine: BusinessEntity {
public decimal Qty {
set { // 要求された数量(qty)を割り当てることが必要
AllocateActivity AllocateAgent;
AllocateAgent=(AllocateActivity)ActivityFactory.Create(typeof(Al locateActivity),this);
AllocateAgent.Qty = value;
AllocateAgent.Item = Item;
ActivityFactory.Execute(AllocateAgent);
}
}
}
public class ActivityFactory: Agent {
public static BusinessActivity Create (type
DesiredType, ILogicalTransactionContext
Ctx);
public static object Execute (BusinessActivity
ActivityAgent);
public static void Abort (BusinessActivity
ActivityAgent);
// Confirm()はここには現れないことに注意。フレームワークのみが確認を行うことができるべきである。
// Abort()の呼出しはこのアクティビティをアボートするだけである。すべてをアボートするには、ＶＣ上のAbortを呼び出すこと。
}
Activity Consumer (Entity calling Activity):
public class OrderLine: BusinessEntity {
public decimal Qty {
set { // 要求された数量(qty)を割り当てることが必要
AllocateActivity AllocateAgent;
AllocateAgent=(AllocateActivity)ActivityFactory.Create(typeof(Al locateActivity),this);
AllocateAgent.Qty = value;
AllocateAgent.Item = Item;
ActivityFactory.Execute(AllocateAgent);
}
}
}
このプログラミングモデルは同期モデル（要求−応答）であることに留意されたい。別の実施形態では、エンティティからのアクティビティと対話するメッセージ型非同期モデルを導入するために、メッセージサービスブローカ(Message Service Broker)を使用することが可能である。
しかし、いったん非同期モデルが使用された後であっても、同期ＡＰＩにも依然として価値があると考えられる。非同期モデルでは、コールバック駆動モデルが必要となって、本質的にプログラミングモデルを複雑にする。エンティティ著作者は、同期または非同期のいずれを使用するかをその都度決定することができる。
例として航空機座席予約の問題を考える。同期または非同期の選択肢が与えられた場合、エンティティ著作者はおそらく、このアプリケーションに対して同期を選択するであろう。エンティティが連結できれば、リースを受けることが可能である。航空会社のサーバがオフラインである場合、同期座席予約呼出しは失敗し、したがってユーザに通知することができるのがおそらく望ましい。
これに代えて、座席リース要求を黙って待ち行列に加え、後でそれを実行するという方法があるであろう。これは、その時までには主なチケット予約は完了してしまい、顧客はとっくにいなくなっている可能性が高いことからそれほど有利ではない。
アクティビティは、連鎖させることも可能である。これは、アクティビティが他のアクティビティを呼び出すことができることを意味する。一例を下記に示す。
Activity Consumer (Activity calling Activity):
public class MyActivityService:
BusinessActivityService {
protected override object Execute
(BusinessActivity ActivityAgent,ref bool
needsConfirm,ref bool needsAbort) {
AllocActivity AllocateAgent;
AllocateAgent =
(AllocActivity)ActivityFactory.Create(
typeof(AllocActivity), ActivityAgent);
AllocateAgent.Qty =
(MyActivity)ActivityAgent.Foo;
AllocateAgent.Item =
(MyActivity)ActivityAgent.Bar;
ActivityFactory.Execute(AllocateAgent);
}
protected override void Abort
(BusinessActivity ActivityAgent) {
}
}
Activity Consumer (Activity calling Activity):
public class MyActivityService:
BusinessActivityService {
protected override object Execute
(BusinessActivity ActivityAgent,ref bool
needsConfirm,ref bool needsAbort) {
AllocActivity AllocateAgent;
AllocateAgent =
(AllocActivity)ActivityFactory.Create(
typeof(AllocActivity), ActivityAgent);
AllocateAgent.Qty =
(MyActivity)ActivityAgent.Foo;
AllocateAgent.Item =
(MyActivity)ActivityAgent.Bar;
ActivityFactory.Execute(AllocateAgent);
}
protected override void Abort
(BusinessActivity ActivityAgent) {
}
}
アクティビティを作成するために、そのアクティビティを参加させるための論理トランザクションコンテキストが提供される。単純な場合、この論理トランザクションコンテキストはエンティティから得られる。しかし、アクティビティが所与の論理トランザクションコンテキストで一度作成されると、そのアクティビティはそのコンテキストを他のアクティビティに渡すことができる。
本発明の実施形態では、ビジネスアクティビティを用いて長時間トランザクション管理を実装するために３つの相互に関係するサブシステムを使用するのが望ましい。これらのサブシステムには、BusinessActivityサブシステム、SagaManangerサブシステム、およびActivityManagementサブシステムがある。
BusinessActivityサブシステムは図１６に示されている。ビジネスアクティビティは常にエンティティグラフと関連づけられる。アクティビティは、論理トランザクションコンテキストをActivityFactory.Create()メソッドに渡すことによりエンティティグラフと関連づけられる。この論理トランザクションコンテキストは、両方ともILogicalTransactionインタフェースを実装することから、エンティティまたはアクティビティによって提供することができる。
ビジネスアクティビティは、エージェント＼サービスパターンを実装するのが望ましい。ActivityFactoryは、ファクトリセマンティクスを実装するのが望ましい。これが「VirtualCollection」ではなく「Factory」と呼ばれるのは、（シングルトンの）アクティビティを作成するだけであり「find」や「save」のセマンティクスを持たないためである。
エンティティが論理トランザクションコンテキストの所持者であることを示すために、図１６のモデルではBusinessEntityが含められている。
BusinessActivityServiceクラスの多数のExecuteXXX、AbortXXX、およびConfirmXXXというメソッドは、サービスに関するアクティビティからビジネスロジックへの直接呼出しを避けるために提供されている。代わりに、「フック」は、トランザクションコンテキストをセットアップし、アクティビティ状態を追跡するためのログレコードを書き出し、拡張（ｅｘｔｅｎｓｉｂｉｌｉｔｙ）イベントを始動するために、基本クラス内の項目を関連づける。
図１７に図式的に示すSagaManagerサブシステムは、アクティビティをエンティティにリンクする働きを持つ。エンティティグラフのコンテキスト内で実行されるアクティビティがサーガを形成する。新しいエンティティグラフの作成によってサーガが始まる。EntityBrokerクラスは論理トランザクションコンテキストを作成するために、SagaManager.Begin()メソッドを呼び出すことになる。エンティティグラフの保存または削除によって、サーガが完了する。EntityBrokerクラスはサーガを完了するためにSagaManager.Commit()を呼び出すことになる。エンティティグラフについてアボートすることによってサーガはアボートする。EntityBrokerクラスは、サーガをアボートするためにSagaManager.Abort()を呼び出すことになる。
論理トランザクションコンテキストは物理トランザクションを管理する。ビジネスアクティビティは、時には複数のデータベーストランザクションにわたることが必要となる可能性がある。したがって、適切なライフサイクルを有する接続をプールしておくことが要求される。論理トランザクションコンテキストはこの要求を満たす。
ActivityManagementサブシステムは図１８に示されている。ActivityManagementサブシステムは、アクティビティの実行を管理する。アクティビティのための実際のビジネスロジックコードはBusinessActivityServiceクラスの一部であるが、実行メソッドは一般に、単に実行し完了することはできない。エンティティに基づくサーガは、アクティビティが実行される前後に特別の「セットアップ」を要求する。これは、適切なトランザクションコンテキストが設定されることを保証するとともに、いかなる特別のロギング要求をも考慮している。
このため、BusinessActivityServiceクラスは実際に、アクティビティの実行をActivitySubTransactionに委任している。場合によっては、これはＣＯＭ＋の「Requires」トランザクションコンテキストがセットアップされることを可能にする。エンティティに基づくサーガの場合、SagaSubTransactionクラスが、適切なトランザクションコンテキスト（これはＳＱＬサーバコネクションによる、またはＣＯＭ＋の「RequiresNew」であるかもしれない）をセットアップする。SagaSubTransactionクラスはまた、アクティビティが状態を変更する時に適切なコミットおよびアボートメソッドが呼び出されることを保証するためにログレコードの書き出しも行う。
以上、本発明は特定の実施形態を参照して説明されたが、当業者に認識されるように、本発明の精神および範囲から逸脱することなく、形態および細部において変更が可能である。
１００ コンピューティングシステム環境
１１０ コンピュータ
１２０ 中央処理装置
１２１ システムバス
１３０ システムメモリ
１３１ 読み出し専用メモリ（ＲＯＭ）
１３２ ランダムアクセスメモリ（ＲＡＭ）
１３３ 基本入出力システム（ＢＩＯＳ）
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１４０ 固定メモリインタフェース
１４１ ハードディスクドライブ
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ リムーバブルメモリインタフェース
１５１ 磁気ディスクドライブ
１５２ 磁気ディスク
１５５ 光ディスクドライブ
１５６ 光ディスク
１６０ ユーザ入力インタフェース
１６１ ポインティングデバイス
１６２ キーボード
１６３ マイクロフォン
１７０ ネットワークインタフェース
１７１ ローカルエリアネットワーク（ＬＡＮ）
１７２ モデム
１７３ 広域ネットワーク（ＷＡＮ）
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム
１９０ ビデオインタフェース
１９１ モニタ
１９５ 出力周辺インタフェース
１９６ プリンタ
１９７ スピーカ
２００ 環境
２０２ ツールおよびサーバプラットフォーム
２０４ ビジネスフレームワーク
２０６ ビジネスコンポーネント
２０８ ビジネスソリューション
２１０ フレームワーク
２１２ アプリケーション層
２１４，２１６，２１８ ビジネスコンポーネント
２２０ ビジネスクラスライブラリ
２２２ ツールサブシステム
２２４ ビジネスアプリケーションフレームワーク
２２６ 共通エンティティ
２２８ パターン
２３０ データ型
３００ 動的プロセス
３０２ 静的プロセス
３０４ エンティティ
３４０ 利用者
４００ エンティティ利用者
４０２ Abort()メソッド
４１０ エンティティ利用者
４１６ 清掃エージェント
４３０ エンティティ利用者
１１０ コンピュータ
１２０ 中央処理装置
１２１ システムバス
１３０ システムメモリ
１３１ 読み出し専用メモリ（ＲＯＭ）
１３２ ランダムアクセスメモリ（ＲＡＭ）
１３３ 基本入出力システム（ＢＩＯＳ）
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１４０ 固定メモリインタフェース
１４１ ハードディスクドライブ
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ リムーバブルメモリインタフェース
１５１ 磁気ディスクドライブ
１５２ 磁気ディスク
１５５ 光ディスクドライブ
１５６ 光ディスク
１６０ ユーザ入力インタフェース
１６１ ポインティングデバイス
１６２ キーボード
１６３ マイクロフォン
１７０ ネットワークインタフェース
１７１ ローカルエリアネットワーク（ＬＡＮ）
１７２ モデム
１７３ 広域ネットワーク（ＷＡＮ）
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム
１９０ ビデオインタフェース
１９１ モニタ
１９５ 出力周辺インタフェース
１９６ プリンタ
１９７ スピーカ
２００ 環境
２０２ ツールおよびサーバプラットフォーム
２０４ ビジネスフレームワーク
２０６ ビジネスコンポーネント
２０８ ビジネスソリューション
２１０ フレームワーク
２１２ アプリケーション層
２１４，２１６，２１８ ビジネスコンポーネント
２２０ ビジネスクラスライブラリ
２２２ ツールサブシステム
２２４ ビジネスアプリケーションフレームワーク
２２６ 共通エンティティ
２２８ パターン
２３０ データ型
３００ 動的プロセス
３０２ 静的プロセス
３０４ エンティティ
３４０ 利用者
４００ エンティティ利用者
４０２ Abort()メソッド
４１０ エンティティ利用者
４１６ 清掃エージェント
４３０ エンティティ利用者
Claims (9)
- コンピュータによって、ビジネスプロセスを実装するプログラムを生成する方法であって、
ビジネスエンティティに含まれる論理トランザクションコンテキストをアクティビティファクトリメソッドに渡して、ビジネスアクティビティを該論理トランザクションコンテキストでインスタンス化するステップであって、前記論理トランザクションコンテキストは、グラフとしてエンティティを示すエンティティグラフ内で一意であり、コンピュータによってアクティビティを実行するため提供され、物理トランザクションにおいてデータを格納または削除することにより該物理トランザクションを管理するステップと、
１つの物理データベーストランザクションにおいて、前記エンティティのグラフ全体を永続化するステップと、
チェックポイント付きサーガを導入して、前記トランザクションを補償するステップと、
前記論理トランザクションコンテキスト内で前記ビジネスアクティビティに関連する少なくとも１つのイベントを実行するステップと
を備えたことを特徴とする方法。 - 前記少なくとも１つのイベントを実行した後、前記論理トランザクションコンテキストを前記アクティビティファクトリメソッドに渡して、前記論理トランザクションコンテキストを有する追加のビジネスアクティビティを生成しメモリに記憶するステップをさらに備えたことを特徴とする請求項１に記載の方法。
- 前記ビジネスアクティビティは、前記追加のビジネスアクティビティを呼び出すことによりアクティビティ連鎖を形成することを特徴とする請求項２に記載の方法。
- 前記論理トランザクションコンテキストは、複数の物理トランザクションにわたって物理トランザクションを管理することを特徴とする請求項１に記載の方法。
- 前記ビジネスアクティビティに関連する前記少なくとも１つのイベントを実行するステップは、サーバ上で実行されることを特徴とする請求項１に記載の方法。
- 前記ビジネスアクティビティは、アクティビティインスタンス識別子を有することを特徴とする請求項１に記載の方法。
- 前記ビジネスアクティビティは、エンティティを用いてインスタンス化されることを特徴とする請求項１に記載の方法。
- 前記ビジネスアクティビティは、静的プロセスを用いてインスタンス化されることを特徴とする請求項１に記載の方法。
- 前記ビジネスアクティビティは動的プロセスを用いてインスタンス化されることを特徴とする請求項１に記載の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US39723302P | 2002-07-19 | 2002-07-19 | |
| US10/623,208 US20050261914A1 (en) | 2002-07-19 | 2003-07-18 | Method and system for managing long running transactions |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003277911A Division JP2004164594A (ja) | 2002-07-19 | 2003-07-22 | 長時間のトランザクションを管理する方法およびシステム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2011003200A true JP2011003200A (ja) | 2011-01-06 |
Family
ID=30003360
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003277911A Pending JP2004164594A (ja) | 2002-07-19 | 2003-07-22 | 長時間のトランザクションを管理する方法およびシステム |
| JP2010152438A Withdrawn JP2011003200A (ja) | 2002-07-19 | 2010-07-02 | 長時間のトランザクションを管理する方法およびシステム |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003277911A Pending JP2004164594A (ja) | 2002-07-19 | 2003-07-22 | 長時間のトランザクションを管理する方法およびシステム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20050261914A1 (ja) |
| EP (1) | EP1385110A3 (ja) |
| JP (2) | JP2004164594A (ja) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8689185B1 (en) * | 2004-01-27 | 2014-04-01 | United Services Automobile Association (Usaa) | System and method for processing electronic data |
| US7805324B2 (en) * | 2004-10-01 | 2010-09-28 | Microsoft Corporation | Unified model for authoring and executing flow-based and constraint-based workflows |
| US20090158242A1 (en) * | 2007-12-18 | 2009-06-18 | Kabira Technologies, Inc., | Library of services to guarantee transaction processing application is fully transactional |
| US9268532B2 (en) | 2009-02-25 | 2016-02-23 | International Business Machines Corporation | Constructing a service oriented architecture shared service |
| US20100257010A1 (en) * | 2009-04-07 | 2010-10-07 | International Business Machines Corporation | Managing a service oriented architecture lifecycle |
| US8667329B2 (en) * | 2009-09-25 | 2014-03-04 | Ab Initio Technology Llc | Processing transactions in graph-based applications |
| US8732143B2 (en) * | 2010-08-27 | 2014-05-20 | Microsoft Corporation | Reducing locking during database transactions |
| US8311993B2 (en) | 2010-09-10 | 2012-11-13 | International Business Machines Corporation | Controlling and recovering long-lived transactions |
| US10163510B1 (en) * | 2013-08-09 | 2018-12-25 | Ellis Robinson Giles | System and method for atomic persistence in storage class memory |
| US9465832B1 (en) | 2016-02-04 | 2016-10-11 | International Business Machines Corporation | Efficiently committing large transactions in a graph database |
| US10534636B2 (en) * | 2017-03-13 | 2020-01-14 | Oracle Financial Services Software Limited | Interface and runtime environment for process definition and process execution tracking |
| US11290350B2 (en) * | 2019-01-15 | 2022-03-29 | Red Hat, Inc. | Distributed saga execution and coordination |
| CN111277639B (zh) * | 2020-01-16 | 2022-08-09 | 中国建设银行股份有限公司 | 一种保持数据一致性的方法和装置 |
| US11757735B2 (en) * | 2020-09-28 | 2023-09-12 | Jpmorgan Chase Bank, N.A. | Method and system for facilitating an audit of event-based business processes |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4627019A (en) * | 1982-07-08 | 1986-12-02 | At&T Bell Laboratories | Database management system for controlling concurrent access to a database |
| US5893117A (en) * | 1990-08-17 | 1999-04-06 | Texas Instruments Incorporated | Time-stamped database transaction and version management system |
| US5666524A (en) * | 1994-08-31 | 1997-09-09 | Price Waterhouse Llp | Parallel processing system for traversing a transactional database |
| US5799157A (en) * | 1994-12-13 | 1998-08-25 | Elcom Systems, Inc. | System and method for creating interactive electronic systems to present information and execute transactions |
| CN1183841A (zh) * | 1995-02-13 | 1998-06-03 | 英特特拉斯特技术公司 | 用于安全交易管理和电子权利保护的系统和方法 |
| DE69719269T2 (de) * | 1996-08-01 | 2003-10-30 | Ibm | Absicherung der Unteilbarkeit für eine Ansammlung von transaktionellen Arbeitsschritten in einem Arbeitsflussverwaltungssystem |
| US6035402A (en) * | 1996-12-20 | 2000-03-07 | Gte Cybertrust Solutions Incorporated | Virtual certificate authority |
| US6061708A (en) * | 1997-05-31 | 2000-05-09 | International Business Machines Corporation | System and method for supporting mixed-phase transactions in an object-oriented environment |
| US5920863A (en) * | 1997-05-31 | 1999-07-06 | International Business Machines Corporation | System and method for supporting transactions for a thin client lacking a persistent store in a distributed object-oriented environment |
| US6052672A (en) * | 1997-08-01 | 2000-04-18 | Financial Systems Technology Pty Ltd. | Data processing system for complex pricing and transactional analysis |
| GB2336006A (en) * | 1998-03-31 | 1999-10-06 | Ibm | Client/server computing with client selectable location of transaction objects |
| US7020697B1 (en) * | 1999-10-01 | 2006-03-28 | Accenture Llp | Architectures for netcentric computing systems |
| US7103597B2 (en) * | 2002-10-03 | 2006-09-05 | Mcgoveran David O | Adaptive transaction manager for complex transactions and business process |
-
2003
- 2003-07-18 US US10/623,208 patent/US20050261914A1/en not_active Abandoned
- 2003-07-21 EP EP03016430A patent/EP1385110A3/en not_active Ceased
- 2003-07-22 JP JP2003277911A patent/JP2004164594A/ja active Pending
-
2010
- 2010-07-02 JP JP2010152438A patent/JP2011003200A/ja not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| EP1385110A2 (en) | 2004-01-28 |
| US20050261914A1 (en) | 2005-11-24 |
| JP2004164594A (ja) | 2004-06-10 |
| EP1385110A3 (en) | 2006-10-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2011003200A (ja) | 長時間のトランザクションを管理する方法およびシステム | |
| US6078982A (en) | Pre-locking scheme for allowing consistent and concurrent workflow process execution in a workflow management system | |
| EP0788631B1 (en) | Distributed work flow management | |
| US6052684A (en) | System and method for performing consistent workflow process execution in a workflow management system | |
| McCarthy et al. | Workflow and transactions in InConcert | |
| US6275863B1 (en) | System and method for programming and executing long running transactions | |
| Cichocki et al. | Workflow and process automation: concepts and technology | |
| US7072913B2 (en) | Method, system and computer program for executing hot migrate operation using migration plug-ins | |
| US5872971A (en) | Data processing systems and methods providing interoperability between data processing resources | |
| AU2002318249B2 (en) | System and method for transaction processing with transaction property feature | |
| CN100594498C (zh) | 海量数据实时处理架构及用于该架构的实时随需处理平台 | |
| JP3512439B2 (ja) | チェックイン・チェックアウトモデルにおける施錠方式 | |
| WO2005015441A2 (en) | Dynamic meta data | |
| Halliday et al. | Flexible workflow management in the OPENflow system | |
| Froehlich et al. | Application framework issues when evolving business applications for electronic commerce | |
| US8463755B2 (en) | System and method for providing collaborative master data processes | |
| Limprecht | Microsoft transaction server | |
| US7203670B2 (en) | Method and system for maintaining enhanced file availability | |
| Schmit et al. | Model-driven development of web service transactions | |
| Silva et al. | A distributed transaction model based on mobile agents | |
| Cobb | The impact of object technology on commercial transaction processing | |
| Sung et al. | A component-based product data management system | |
| Laing et al. | Transaction Management Support in the VMS Operating System Kernel | |
| Cichocki | Migrating workflows and their transactional properties | |
| Frank et al. | Architecture for mobile control functions in supplier deliveries for distributed integrated ERP modules |
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: 20110104 |