(57)【要約】  メタデータドリブンのアンドゥが記載される。ある実施例では、メタデータレポジトリは、オペレーションに関連付けられるメタデータを格納する。各オペレーションに関連付けられる属性もメタデータに格納される。各オペレーションは、特定のオペレーションタイプのオペレーションについてアンドゥエントリを生成するための命令を含むアンドゥレットに関連付けられる。アンドゥログエントリは、アンドゥ可能なオペレーションを含む要求がインターセプトされると、メタデータおよびアンドゥレットを用いて生成される。アンドゥコマンドが発行されると、特定のビジネストランザクションに関連付けられるアンドゥログ中の命令は、トランザクションを「リワインド」するよう実行される。
2014534532.tif 000002
【特許請求の範囲】
【請求項１】
システムであって、
１つ以上のプロセッサと、
メタデータレポジトリを維持するための命令およびアンドゥロジックを提供するための命令を含む一時的でないコンピュータ可読記憶媒体とを含み、
前記メタデータレポジトリは、複数のオペレーションに関連付けられるメタデータを格納するためのものであり、各オペレーションはオペレーションタイプに関連付けられており、各オペレーションに関連付けられる前記メタデータは、ａ）当該オペレーションに関連付けられる１つ以上の属性と、ｂ）対応するオペレーションのオペレーションタイプに関連付けられるアンドゥレットとを少なくとも識別し、前記アンドゥレットは、アンドゥエントリを生成するための命令を含んでおり、
前記アンドゥロジックは、前記メタデータレポジトリにおける前記メタデータと前記アンドゥレットとに少なくとも部分的に基づきアンドゥログにおいて１つ以上のエントリを生成するためのものであり、前記アンドゥログにおける第１のエントリは、前記システムにインターセプトされる第１の要求における第１のオペレーションに基づいており、かつ前記オペレーションに関連付けられる第１の属性についての第１の属性値を含み、
前記アンドゥレットは、前記オペレーションタイプに関連付けられるオペレーションをアンドゥすることが可能なオブジェクトである、システム。
【請求項２】
前記第１の要求は、ターゲットシステム上の第１のオブジェクトの値を第２の値から第３の値に変更する要求であり、前記アンドゥロジックはさらに、前記要求をインターセプトすることに応答して、前記第１の要求に応答して前記第２の値が変更される前に前記ターゲットシステムから前記第２の値を抽出するように前記ターゲットシステムへの第２の要求を生成するよう構成される、請求項１に記載のシステム。
【請求項３】
前記アンドゥログ中の前記第１のエントリにおける前記第１の属性値は前記第２の値と同一であり、前記エントリは、前記１つ以上のプロセッサによって実行されると前記第１のオブジェクトの値が前記第１の属性値に設定される第１の命令を含む、請求項２に記載のシステム。
【請求項４】
前記アンドゥログ中の前記第１のエントリはさらに、１つ以上のプロセッサによって実行されると、アンドゥロジックに、ターゲットシステム上の前記第１のオブジェクトの値が前記第３の値と同一であるかどうかを決定させるとともに、前記ターゲットシステム上の前記第１のオブジェクトの値が前記第３の値と同一であると決定することに応答して、前記第１のオブジェクトの値が前記第１の属性値に設定される命令を実行させる第２の命令を含む、請求項３に記載のシステム。
【請求項５】
前記アンドゥロジックはさらに、前記システムによってインターセプトされる第２の要求における第２のオペレーションに基づき前記アンドゥログに第２のエントリを生成するよう構成されており、前記第２の要求は、第２のターゲットシステム上の第２のオブジェクトの値を第４の値から第５の値に変更する要求であり、前記第２のエントリは前記第４の値を含み、
前記第１の要求および前記第２の要求は、前記第１および第２の要求の両方を第１のセッションに関連付けるセッション識別情報を含み、
前記第２のエントリは、前記１つ以上のプロセッサによって実行されると、前記第２のオブジェクトの値が前記第４の値に設定される第２の命令を含み、
前記システムは、前記第１の要求を前記第１のターゲットシステムに送り、かつ前記第２の要求を前記第２のターゲットシステムに送るよう構成されており、
前記アンドゥロジックは、前記第１のセッションに関連付けられるアンドゥオペレーションを行うよう第３の要求を受け取ることに応答して、第１、第２および第３の命令が前記１つ以上のプロセッサ上で実行されるよう構成される、請求項４に記載のシステム。
【請求項６】
前記アンドゥロジックはさらに、前記第２の要求の前かつ第１の要求の後にインターセプトされる第３の要求における第３のオペレーションに基づき第２のアンドゥログに第３のエントリを生成するよう構成されており、前記第３の要求は、前記第１のターゲットシステム上で第３のオブジェクトの値を変更する要求であり、前記第３の要求は第２のセッションに関連付けられており、
前記アンドゥロジックは、前記第３のオブジェクトの値を変更することなしに、第１、第２および第３の命令が前記１つ以上のプロセッサ上で実行されるよう構成される、請求項５に記載のシステム。
【請求項７】
前記第１のオペレーションはコンストラクタオペレーションであり、前記第１の属性値は前記要求に応答してターゲットシステム上に構築されるオブジェクトの名前であり、前記アンドゥログにおける前記第１のエントリは、前記１つ以上のプロセッサによって実行されると、前記オブジェクトが前記ターゲットシステムから除去される命令を含む、請求項１〜６のいずれか１項に記載のシステム。
【請求項８】
一時的でないコンピュータ可読記憶媒体であって、前記一時的でないコンピュータ可読記憶媒体は命令を格納しており、前記命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
複数のオペレーションに関連付けられるメタデータを格納するメタデータレポジトリを維持することを行わせ、各オペレーションはオペレーションタイプに関連付けられており、各オペレーションに関連付けられる前記メタデータは、ａ）当該オペレーションに関連付けられる１つ以上の属性と、ｂ）対応するオペレーションのオペレーションタイプに関連付けられるアンドゥレットとを少なくとも識別し、前記アンドゥレットは、アンドゥエントリを生成するための命令を含んでおり、前記命令はさらに前記１つ以上のプロセッサに、
前記メタデータレポジトリにおける前記メタデータと前記アンドゥレットとに少なくとも部分的に基づきアンドゥログにおいて１つ以上のエントリを生成することを行わせ、
前記アンドゥログにおける第１のエントリは、前記システムにインターセプトされる第１の要求における第１のオペレーションに基づいており、かつ前記オペレーションに関連付けられる第１の属性についての第１の属性値を含み、
前記アンドゥレットは、前記オペレーションタイプに関連付けられるオペレーションをアンドゥすることが可能なオブジェクトである、一時的でないコンピュータ可読記憶媒体。
【請求項９】
前記第１の要求は、ターゲットシステム上の第１のオブジェクトの値を第２の値から第３の値に変更する要求であり、前記命令はさらに、
前記要求をインターセプトすることに応答して、前記第１の要求に応答して前記第２の値が変更される前に前記ターゲットシステムから前記第２の値を抽出するように前記ターゲットシステムへの第２の要求を生成するための命令を含む、請求項８に記載の一時的でないコンピュータ可読記憶媒体。
【請求項１０】
前記アンドゥログ中の前記第１のエントリにおける前記第１の属性値は前記第２の値と同一であり、前記エントリは、前記１つ以上のプロセッサによって実行されると前記第１のオブジェクトの値が前記第１の属性値に設定される第１の命令を含む、請求項９に記載の一時的でないコンピュータ可読記憶媒体。
【請求項１１】
前記アンドゥログ中の前記第１のエントリはさらに、１つ以上のプロセッサによって実行されると、アンドゥロジックに、ターゲットシステム上の前記第１のオブジェクトの値が前記第３の値と同一であるかどうかを決定させるとともに、前記ターゲットシステム上の前記第１のオブジェクトの値が前記第３の値と同一であると決定することに応答して、前記第１のオブジェクトの値が前記第１の属性値に設定される命令を実行させる第２の命令を含む、請求項１０に記載の一時的でないコンピュータ可読記憶媒体。
【請求項１２】
前記命令はさらに、
第２のインターセプトされる要求における第２のオペレーションに基づき前記アンドゥログに第２のエントリを生成するための命令を含み、前記第２の要求は、第２のターゲットシステム上の第２のオブジェクトの値を第４の値から第５の値に変更する要求であり、前記第２のエントリは前記第４の値を含み、
前記第１の要求および前記第２の要求は、前記第１および第２の要求の両方を第１のセッションに関連付けるセッション識別情報を含み、
前記第２のエントリは、前記１つ以上のプロセッサによって実行されると、前記第２のオブジェクトの値が前記第４の値に設定される第２の命令を含み、前記命令はさらに、
前記第１の要求を前記第１のターゲットシステムに送り、かつ前記第２の要求を前記第２のターゲットシステムに送るための命令と、
前記第１のセッションに関連付けられるアンドゥオペレーションを行うよう第３の要求を受け取ることに応答して、第１、第２および第３の命令が前記１つ以上のプロセッサ上で実行されるための命令とを含む、請求項１１に記載の一時的でないコンピュータ可読記憶媒体。
【請求項１３】
前記アンドゥロジックはさらに、前記第２の要求の前かつ第１の要求の後にインターセプトされる第３の要求における第３のオペレーションに基づき第２のアンドゥログに第３のエントリを生成するよう構成されており、前記第３の要求は、前記第１のターゲットシステム上で第３のオブジェクトの値を変更する要求であり、前記第３の要求は第２のセッションに関連付けられており、
前記アンドゥロジックは、前記第３のオブジェクトの値を変更することなしに、第１、第２および第３の命令が前記１つ以上のプロセッサ上で実行されるよう構成される、請求項１２に記載の一時的でないコンピュータ可読記憶媒体。
【請求項１４】
前記第１のオペレーションはコンストラクタオペレーションであり、前記第１の属性値は前記要求に応答してターゲットシステム上に構築されるオブジェクトの名前であり、前記アンドゥログにおける前記第１のエントリは、前記１つ以上のプロセッサによって実行されると、前記オブジェクトが前記ターゲットシステムから除去される命令を含む、請求項８〜１３のいずれか１項に記載の一時的でないコンピュータ可読記憶媒体。
【請求項１５】
方法であって、
複数のオペレーションに関連付けられるメタデータを格納するメタデータレポジトリを維持するステップを含み、各オペレーションはオペレーションタイプに関連付けられており、各オペレーションに関連付けられる前記メタデータは、ａ）当該オペレーションに関連付けられる１つ以上の属性と、ｂ）対応するオペレーションのオペレーションタイプに関連付けられるアンドゥレットとを少なくとも識別し、前記アンドゥレットは、アンドゥエントリを生成するための命令を含んでおり、前記方法はさらに、
前記メタデータレポジトリにおける前記メタデータと前記アンドゥレットとに少なくとも部分的に基づきアンドゥログにおいて１つ以上のエントリを生成するステップを含み、
前記アンドゥログにおける第１のエントリは、前記システムにインターセプトされる第１の要求における第１のオペレーションに基づいており、かつ前記オペレーションに関連付けられる第１の属性についての第１の属性値を含み、
前記方法は１つ以上のコンピューティング装置によって行われ、
前記アンドゥレットは、前記オペレーションタイプに関連付けられるオペレーションをアンドゥすることが可能なオブジェクトである、方法。
【請求項１６】
前記第１の要求は、ターゲットシステム上の第１のオブジェクトの値を第２の値から第３の値に変更する要求であり、前記方法はさらに、
前記要求をインターセプトすることに応答して、前記第１の要求に応答して前記第２の値が変更される前に前記ターゲットシステムから前記第２の値を抽出するように前記ターゲットシステムへの第２の要求を生成するステップを含む、請求項１５に記載の方法。
【請求項１７】
前記アンドゥログ中の前記第１のエントリにおける前記第１の属性値は前記第２の値と同一であり、前記エントリは、前記１つ以上のプロセッサによって実行されると前記第１のオブジェクトの値が前記第１の属性値に設定される第１の命令を含む、請求項１６に記載の方法。
【請求項１８】
前記アンドゥログ中の前記第１のエントリはさらに、１つ以上のプロセッサによって実行されると、アンドゥロジックに、ターゲットシステム上の前記第１のオブジェクトの値が前記第３の値と同一であるかどうかを決定させるとともに、前記ターゲットシステム上の前記第１のオブジェクトの値が前記第３の値と同一であると決定することに応答して、前記第１のオブジェクトの値が前記第１の属性値に設定される命令を実行させる第２の命令を含む、請求項１７に記載の方法。
【請求項１９】
第２のインターセプトされる要求における第２のオペレーションに基づき前記アンドゥログに第２のエントリを生成するステップをさらに含み、前記第２の要求は、第２のターゲットシステム上の第２のオブジェクトの値を第４の値から第５の値に変更する要求であり、前記第２のエントリは前記第４の値を含み、
前記第１の要求および前記第２の要求は、前記第１および第２の要求の両方を第１のセッションに関連付けるセッション識別情報を含み、
前記第２のエントリは、前記１つ以上のプロセッサによって実行されると、前記第２のオブジェクトの値が前記第４の値に設定される第２の命令を含み、前記方法はさらに、
前記第１の要求を前記第１のターゲットシステムに送り、かつ前記第２の要求を前記第２のターゲットシステムに送るステップと、
前記第１のセッションに関連付けられるアンドゥオペレーションを行うよう第３の要求を受け取ることに応答して、第１、第２および第３の命令が前記１つ以上のプロセッサ上で実行されるステップとを含む、請求項１８に記載の方法。
【請求項２０】
前記第１のオペレーションはコンストラクタオペレーションであり、前記第１の属性値は前記要求に応答してターゲットシステム上に構築されるオブジェクトの名前であり、前記アンドゥログにおける前記第１のエントリは、前記１つ以上のプロセッサによって実行されると、前記オブジェクトが前記ターゲットシステムから除去される命令を含む、請求項１５〜１９のいずれか１項に記載の方法。
【請求項２１】
１つ以上のプロセッサに請求項１５〜２０のいずれか１項に記載の方法を行わせるための、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
利益の請求
この出願は、２０１１年１１月３日に出願された仮出願第６１／５５５，４４３号の利益を請求しており、これによってその全ての内容は、米国特許法第１１９条（ｅ）により本願明細書において完全に記載されるかのように、参照により援用される。
【背景技術】
【０００２】
発明の背景
現代のコンピューティングシステムはしばしば、あるオペレーションを「アンドゥ（undo）」する能力を提供する。これは、コンピュータオペレータまたは彼らが用いるプログラムが時に誤りを起こすからである。誤りが発生すると、オペレータは、既知の状態に戻って再度試行したい場合がある。さまざまなアクションがこれらの誤りにつながり得る。たとえば、プログラマは時々、コンピューティングシステムが特定の態様で用いられるのを認識することを失敗する。プログラマが特定の使用ケースについてテストをしていなかった場合、ユーザはエラーをシステムに導入し得る。より複雑なビジネストランザクションにおいて、さまざまなコンピューティングシステム上で多くの変更がなされることが一般的である。このようなマルチステップのビジネストランザクションが始まった後であって終わる前にこれらのコンピューティングシステムの１つに変更がなされれば、不整合性が当該システムに導入され得る。これは、この間に起こる変更が、ビジネストランザクションにおいてなされた他の変更とのセキュリティ不整合性を伴う場合に特に問題である。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
いくつかのデータベースシステムは、データベーストランザクションの間の一貫性を確実にすることに関して利点を有する。これは、オラクル社によって提供されるデータベースシステムのようなＡＣＩＤトランザクションを実現するデータベースに特に該当する。ＡＣＩＤは原子性（Atomicity）、一貫性（Consistency）、分離性（Isolation）、および持続性（Durability）を表す。データベースコンピューティングにおいて、原子性とは、変更のシーケンスが単一のデータベーストランザクション内でなされる場合に、当該変更のすべてがなされるかまたは当該変更のいずれもなされないかを意味する。換言すると、ＡＣＩＤトランザクションは、「オール・オア・ナッシング」のアプローチを取る。したがってデータベースシステムは、全トランザクションが成功することを、そのトランザクションを行う前に確実にし得る。
【０００４】
他のコンピューティングシステムには、データベースシステムによって与えられる恵まれた一貫性がない。たとえば、ＬＤＡＰ（ライトウェイト・ディレクトリ・アクセス・プロトコル（Lightweight Directory Access Protocol））ベースのシステムは、変更を行う前のビルトインの一貫性チェックを有していない。ウェブサービスおよび他のシステムも、当該システムがデー夕ベースを使用して情報を格納しても、変更が与えられた際には当該変更を行う。たとえば、ビジネストランザクションによって必要とされる変更の１つは、ウェブサービスへの更新要求であり得る。ウェブサービスはデータを現代のデータベースに格納し得るが、当該デー夕ベースは、ビジネストランザクションによって要求される任意の他の変更に気づかない。なぜならば、１度に１つの変更のみがウェブサービスを通じて要求され、ウェブサービスは要求された際に単に変更を行うだけであるからである。次いで、データベースは、全ビジネストランザクションを完了するよう他のステップが必要とされても、データベースに提供された各トランザクションを行なう。
【０００５】
上で提供された例では、オペレーションのうちの１つが失敗することが起こり得る。たとえば、ビジネストランザクションは、１３個の別個のステップがなされることを必要とし得、１２番目のステップが失敗すると、システム上で不整合性が引き起こされ得る。このような不整合性は、単一のシステムでも問題であるが、ビジネストランザクションでは複数のシステム上でステップがなされることが必要とされ得、問題が増大する。
【０００６】
この問題に対する１つの可能性のあるソリューションは、アンドゥ能力が望まれる各システムまたはサービスについて、特殊目的の「アンドゥ」ロジックをプログラムすることである。しかしながら、ハードコーディングされたアンドゥロジックを変化しているシステム内で維持することは困難であり、しばしばエラーにつながる。さらに、労働コストが高くなりすぎる。失敗したビジネストランザクションをリワインドするよう必要なオペレーションのすべてを行うアンドゥロジックを記述することは、当該ロジックによって動的に生成される必要があるオペレーションの数が増加するので、複雑であり、非常に困難になる。さらに、このように実現されるアンドゥロジックは、サービスが変更するたびに無効になり、これによりコードを再び記述することが必要になる。
【０００７】
データベーストランザクションの快適さの外側で発生するビジネストランザクションについてアンドゥ機能性を提供する汎用のアンドゥシステムが必要とされる。
【図面の簡単な説明】
【０００８】
【図１Ａ】ある実施例が実現され得るコンピューティング環境の論理ブロック図を示す図である。
【図１Ｂ】ある実施例においてクライアントとサーバとの間の中間部として位置決めされるアンドゥエンジンを示す論理ブロック図を示す図である。
【図２】ある実施例におけるアンドゥエンジンの論理ブロック図を示す図である。
【図３】ある実施例におけるアンドゥエンジンの部分として実現され得るアンドゥロジックを示す論理ブロック図を示す図である。
【図４】ある実施例におけるオペレーションの分類を示す図である。
【図５】ある実施例が実現され得るコンピュータシステムを示す図である。
【発明を実施するための形態】
【０００９】
発明の詳細な説明
メタデータドリブンのアンドゥが記載される。以下の記載において、本発明の完全な理解を提供するよう、多くの特定の詳細を説明目的のために記載する。しかしながら、本発明はこれらの特定の詳細なしで実施され得るということは当業者には明らかであろう。他の場合では、不必要に本発明を不明瞭にすることを避けるために、周知の構造および装置がブロック図の形で示される。
【００１０】
本願明細書において次の概要に従って実施例が記載される。
１．０  一般概要
２．０  構造および機能概要
３．０  メタデータドリブンのアンドゥ
３．１  メタデータ
３．２  アンドゥログ
３．３  アンドゥレット（Undolet）
３．４  メタデータドリブンのアンドゥの実行
３．５  アンドゥポリシー
３．６  アンドゥエンジンの停止
４．０  実現メカニズム−ハードウェア概要
１．０  一般概要
メタデータドリブンのアンドゥが記載される。ある実施例では、メタデータレポジトリが、オペレーションに関連付けられるメタデータを格納する。たとえば、メタデータは、当該オペレーションがセッタ（setter）、ゲッタ（getter）、コンストラクタ（constructor）、デストラクタ(destructor)、アダー(adder)、リムーバ(remover)、または他のタイプのオペレーションかどうかといったようなオペレーションのタイプを識別し得る。各オペレーションおよび／またはオペレーションタイプに関連付けられる属性もメタデータに格納される。各オペレーションは、アンドゥエントリを生成するための命令を含むアンドゥレットに関連付けられる。アンドゥレットは、ターゲットシステムを考慮することなく当該オペレーションのタイプ（たとえばコンストラクタ、デストラクタ）に属する任意のオペレーションに対する任意の呼出しを取り扱うことができる。アンドゥロジックは、メタデータレポジトリ内のメタデータとアンドゥレットとに基づきアンドゥログ内にエントリを生成する。ある実施例では、アンドゥエントリが、ターゲットシステムに対するクエリに基づき生成される。アンドゥログにおけるエントリは、システムによってインターセプトされる要求におけるオペレーションに基づき得、オペレーションに関連付けられる属性についての属性値を含み得る。アンドゥコマンドが発行されると、アンドゥログにおける、特定のビジネストランザクションに関連付けられる命令が実行される。アンドゥ命令の実行が成功すれば、ビジネストランザクションに含まれるシステムの状態は、ビジネストランザクションに関連付けられるオブジェクトに関して、トランザクション前の状態に戻る。
【００１１】
２．０  構造および機能概要
図１Ａは、ある実施例が実現され得るコンピューティング環境の論理ブロック図を示す図である。クライアント１１０は、別のコンピューティングシステムもしくはコンピュータプロセスに要求を行うか、またはそうでなければ別のコンピューティングシステムもしくはコンピュータプロセスと遣り取りをすることが可能であるコンピューティングシステムを示す。クライアント１１０はさらに、コンピューティング装置上で実行しているプロセスを示し得る。たとえば、クライアント１１０およびサーバ１３０は、同じコンピューティング装置上で実行されているプロセスを示し得る。クライアント１２０は、ロジックと、実行されると１つ以上の要求がサーバ１３０に送られる命令とを有するよう構成される。サーバ１３０は、サーバロジックおよび格納された命令に従って他のプロセス、コンピューティング装置、またはクライアント１１０のような他のエンティティによってなされた要求に応答してオペレーションを行うよう構成されるコンピューティングシステムまたはコンピューティングシステム上のプロセスを示す。たとえば、クライアント１１０は、財務会計システムに関連付けられるユーザの役割を更新するよう要求を含む更新要求を送り得る。この要求を受け取ることに応答して、サーバ１３０は、クライアント１１０によって提供される命令に従ってユーザの役割を更新するために、データベースに発行する更新を生成し得る。
【００１２】
図１Ｂは、ある実施例においてクライアント１１０とサーバ１３０との間の中間部として位置決めされるアンドゥエンジン１２０を示す論理ブロック図を示す。アンドゥエンジン１２０は、それぞれクライアント１１０およびサーバ１３０といった、要求を行うエンティティと要求を許諾するエンティティとの間の通信をインターセプトする。ある実施例では、アンドゥエンジンはサーバ１３０のエクステンションであり得、サーバ１３０に完全に統合され得、またはサーバ１３０とは別個のコンピューティング装置上で動作し得る。ある実施例では、アンドゥエンジンは、クライアント１１０のエクステンションであり得、クライアント１１０に完全に統合され得、またはクライアント１１０とは別個のコンピューティング装置上で動作し得る。アンドゥエンジン１２０は、クライアント１１０からのアンドゥ要求に応答してアンドゥオペレーションを行うためのロジックを含む。たとえば、財務会計システムに関連付けられるユーザの役割を更新するようクライアント１１０によって送られた以前の要求がサーバ１３０によって行われたとすると、その後の要求は、当該以前の要求によってなされた変更をアンドゥするようクライアント１１０によって送られ得る。アンドゥエンジン１２０は、クライアント１１０から要求を受け取り、以前の要求が実行されなかったかのようにユーザを以前の役割に関連付ける。
【００１３】
図２は、ある実施例におけるアンドゥエンジンの論理ブロック図を示す図である。アンドゥエンジン１２０は入出力（Ｉ／Ｏ）インターフェイス２１０を含む。Ｉ／Ｏインターフェイス２１０は、入力２１０として信号もしくはデータを提供するネットワーク、ユーザ入力装置、または他の装置もしくは手段に結合するよう構成され得る。Ｉ／Ｏインターフェイス２１０はさらに、出力２１４を送信または表示することが可能であるネットワーク、出力ディスプレイ装置、または伝送媒体装置に結合するよう構成され得る。入力信号またはデータ２１２は、アンドゥエンジン１２０によってインターセプトされる、クライアント１１０からサーバ１３０への要求を含んでもよい。たとえば、入力２１２は、サーバ１３０または別のコンピューティングシステム上でユーザに関連付けられる役割を変更する要求を含んでもよい。要求は、新しい役割と、役割が設定されるべきユーザとを含んでもよい。入力２１２は、アンドゥエンジン１２０によってインターセプトされる、サーバ１３０からクライアント１１０への応答も含み得る。たとえば、入力２１２は、当該役割の変更が成功したことを確認するメッセージを含み得る。出力２１４は、サーバ１３０へのメッセージを含み得る。たとえば、アンドゥエンジン１２０によってインターセプトされるメッセージは、変更とともにまたは変更なしでサーバ１３０に転送され得る。出力２１４はさらに、ユーザに関連付けられる役割を設定または変更する要求といった要求の成功または失敗を示す、クライアント１１０への応答を含み得る。他の出力は、ある実施例において、ネットワーク管理ソフトウェアまたはユーザインターフェイス出力に送られるネットワーク管理メッセージを含み得る。
【００１４】
アンドゥエンジン１２０は、入力２１２をＩ／Ｏインターフェイス２１０から受け取るよう構成されるＩ／Ｏロジック２２０を含む。Ｉ／Ｏロジック２２０は、揮発性または不揮発性記憶媒体といった一時的でない媒体に、入力２１２または入力２１２に関連付けられる情報を格納するよう構成され得る。たとえば、Ｉ／Ｏロジック２２０は、ロギングロジック（logging logic）を含み得る。図１に示される実施例において、Ｉ／Ｏロジック２２０は、Ｉ／Ｏインターフェイス２１０、プロセッサ２７０、セッション管理ロジック２３０、アンドゥロジック２４０、およびメタデータ抽出ロジック２５０に通信可能に結合される。他の実施例では、アンドゥエンジンの付加的な要素がＩ／Ｏロジック２２０に結合され得る。
【００１５】
ある実施例では、セッション管理ロジック２３０、アンドゥロジック２４０、およびメタデータ抽出ロジック２５０はすべて、プロセッサ２７０およびデータベース２６０または他のストレージに結合される。セッション管理ロジック２３０は、どの要求が互いに関連付けられるのかを決定するよう構成される。たとえば、セッション管理ロジック２３０は、要求およびセッション識別子のログをデータベース２６０に格納し、および／またはセッション情報をアンドゥロジック２４０に渡し得る。セッション識別子は、セッション管理ロジック２３０によって割り当てられるか、またはインターセプトされた要求からセッション識別情報を抽出することにより決定され得る。ある実施例ではセッション情報は、要求が意図した受信側に転送される前に要求から取り除かれ得る。ある実施例では、セッション管理ロジックは、要求の非同期処理を管理するように構成される。たとえば、アンドゥエンジンが中間部として動作する場合、セッション管理ロジック２３０は、次の要求に移る前に、要求がなされたサーバからのコールバック通知を待たなければならなくても、受け取られた順番に要求を記録および処理する。タイムアウトまたは他のイベントが発生すると、アンドゥポリシーが呼び出されてアンドゥエンジン１２０がアンドゥポリシー命令に従ってタイムアウトを処理する。たとえば、ポリシーは、セッションに関連付けられるすべてのオペレーションを、タイムアウトがこれらのオペレーションのうちの１つの間に発生すれば、アンドゥし得る。
【００１６】
ある実施例において、メタデータ抽出ロジック２５０は、アンドゥ機能性をサポートするよう拡張されているサービスから自動的にメタデータを抽出する。たとえば、Ｊａｖａ（登録商標）アノテーションまたは他のメタデータのようなコメントが、Ｍｂｅａｎまたは他のオブジェクトに含まれ得る。これらのコメントは、オペレーション同士の間の関係を規定する関係情報を提供し得る。たとえば、setName(person,name)のようなオペレーションは、値を設定するので「セッタ」と考えられる。オブジェクトは、ある人についての現在の名前の値をチェックするよう用いられる、関連する「ゲッタ」であるgetName(person)を有し得る。setName()オペレーションは、「アンドゥ可能な」オペレーションとしてメタデータにおいて識別され得、オペレーションのタイプは、オペレーションを用いてオペレーションをアンドゥする方法がその人について以前の値を設定するよう同じオペレーションを用いることであることを示すよう、「ゲッタ」に設定され得る。
【００１７】
サービスから集められたメタデータは、ゲッタおよびセッタに限定される必要はない。コンストラクタおよびデストラクタならびに他のタイプのアンドゥ可能なオペレーションはメタデータによって識別され得る。さらに、ある実施例では、アンドゥ可能ではないリードオンリのオペレーションもメタデータテーブル２６２内に規定され得る。ある実施例では、メタデータは、メタデータテーブル２６２のようなデータベーステーブルに格納される。ある実施例では、メタデータテーブル２６２は、オペレーションタイプから、メタデータ抽出ロジック２５０によって抽出されるオペレーションへのマッピングを含む。
【００１８】
メタデータテーブル２６２はさらに、各オペレーションのパラメータタイプを識別するデータを含む。たとえば、あるオペレーションは、「ＫＥＹ」パラメータ、「ＳＥＬＥＣＴＯＲ」パラメータ、および「ＤＡＴＡ」パラメータといった異なるタイプのパラメータを有し得る。ＫＥＹパラメータは識別に使用される。たとえば、「ＳＳＮ」という名称のパラメータは、人を識別するのに用いられ得るので、ＫＥＹであり得る。なお、同じオペレーション上のゼロ、１つまたはそれ以上のパラメータがＫＥＹであり得る。ＳＥＬＥＣＴＯＲパラメータは、選択に関連付けられる。たとえば、setOffice(int officeNumber,String employeeNumber）というオペレーションでは、officeNumberという名称のパラメータが、オフィスを選択するよう用いられており、したがって、セレクタである。ＤＡＴＡパラメータは、データとして使用されており、任意のデータ値を含み得る。
【００１９】
ある実施例では、メタデータテーブル２６２は、手動もしくは動的または手動動作および自動動作の組合せを用いて、データ追加および更新され得る。他の実施例では、メタデータは、任意のデータファイルタイプまたはストレージシステムを用いて、任意の形態の揮発性または不揮発性コンピュータ可読ストレージ上に格納され得る。たとえばメタデータは、共有されたハードディスクアレイ上のフラットファイルもしくはＸＭＬファイル内またはメモリ５０６のようなメモリ内に格納され得る。
【００２０】
ある実施例において、アンドゥロジック２４０は、アンドゥ命令を生成および実行するよう構成される。アンドゥロジックは、行われるべきオペレーションについてのインターセプトされた要求を受け取る。たとえば、オペレーションは、ウェブサービスアプリケーションに関連付けられる特定の値を更新する要求であり得る。アンドゥロジック２４０は、セッション情報をセッション管理ロジック２３０から受け取り、１つ以上のセッションについて一連のアンドゥ命令を格納する。ある実施例では、アンドゥロジック２４０は、セッション管理ロジック２３０によって識別される各セッションについてアンドゥ命令を格納する。ある実施例において、アンドゥ命令は、アンドゥログデータデータベーステーブル２６４に格納される。他の実施例では、アンドゥ命令は、データベース２６０以外の揮発性メモリまたは不揮発性メモリといったメモリに格納される。１つ以上のプロセッサによって実行される際の、セッションについて生成されるアンドゥ命令によって、対応するセッションにおいてオペレーションによって変更された値がアンドゥされる。たとえば、セッションによって変更される値は、当該セッションに関連付けられるアンドゥ命令の実行が成功していれば、元の値に戻る。
【００２１】
他の実施例では、図２に示されない要素が加えられてもよく、コンピューティングシステムの要素の構成は、図２に示される構成とは異なり得る。たとえば、Ｉ／Ｏロジック２２０はアンドゥロジック２４０に組込まれ得、データベース２６０はリモートでアンドゥエンジン２２０に接続され得る。プロセッサ２７０は、各々が１つ以上のコアを有する１つ以上の中央処理装置（ＣＰＵ）の形態でハードウェアロジックを含み得る。
【００２２】
図３は、ある実施例においてアンドゥエンジンの部分として実現され得るアンドゥロジック２４０を示す論理ブロック図を示す図である。具体的には、図３は、アンドゥ能力がＭｂｅａｎサーバおよびＳＯＡＰサーバについて提供される実施例を示す。一般的なアンドゥエンジン３１０は、どのオペレーションがどのサービスによって行われるかを決定するよう構成される。たとえば、ビジネストランザクションは、識別子「ｋ６ｏＡＯｘＣＷＺｈ」を有するセッションによって識別され得る。しかしながら、セッションｋ６ｏＡＯｘＣＷＺｈに関連付けられるオペレーションのいくつかは、Ｍｂｅａｎサーバによって行われ得る一方、同じセッションに関連付けられる他のオペレーションはＳＯＡＰサーバによって行われ得る。一般的なアンドゥエンジン３１０は、アンドゥ要求が受け取られると、どのエンティティに命令が送られるべきかを識別するためのアンドゥ命令メタデータを生成する。プロキシＭｂｅａｎサーバ３２０およびＳＯＡＰルータ３３０は各々、各セッションに関連付けられる、サービス固有のアンドゥ命令を生成しており、一般的なアンドゥエンジン３１０によって生成されるシーケンシング情報に各命令を関連付ける。上で論じたように、ある実施例では、アンドゥロジック２４０が命令を生成および実行する。より具体的には、ある実施例では、プロキシＭｂｅａｎサーバ３２０およびＳＯＡＰルータ３３０は、このような命令を生成および実行する。上で論じられるように、ある実施例では、アンドゥロジック２４０が要求を受け取る。より具体的には、ある実施例では、一般的なアンドゥエンジン３１０がこのような要求を受け取る。上で論じられるように、ある実施例では、アンドゥロジック２４０がセッション情報を受け取る。より具体的には、ある実施例では、一般的なアンドゥエンジン３１０がこのようなセッション情報を受け取る。上で議論されるように、ある実施例では、アンドゥロジック２４０がアンドゥ命令を格納する。より具体的には、ある実施例では、プロキシＭｂｅａｎサーバ３２０およびＳＯＡＰルータ３３０がこのようなアンドゥ命令を格納する。
【００２３】
Ｍｂｅａｎサーバおよび他のアダプタは、それらに発行されるコマンドを実行する。さらに、これらのアダプタは、１）生成段階の間のデータの収集と、２）実際のアンドゥ段階の間のオペレーションの実行または（検証のための）データの採取とのために用いられる。
【００２４】
３．０  メタデータドリブンのアンドゥ
３．１  メタデータ
リソースを値に論理的にマッピングするメタデータがメタデータレポジトリに格納される。ある実施例では、メタデータレポジトリはデータベース２６０であり、メタデータはデータベーステーブルメタデータ２６２に格納される。メタデータは自動的に、メタデータ抽出ロジック２５０によってメタデータレポジトリに追加またはメタデータレポジトリから除去され得る。ある実施例では、コマンドラインオペレーション、ウェブベースのツールの使用によって、またはＸＭＬファイルのようなリソースメタデータを記述するファイルをメタデータレポジトリにコピーすることによって、メタデータが手動でメタデータレポジトリに追加またはメタデータレポジトリから除去され得る。ある実施例では、メタデータレポジトリに格納される各リソースメタデータオブジェクトが、オペレーションのためのメタデータおよび他のメタデータを提供する。リソースメタデータは、例示すると、オペレーションメタデータ、パラメータメタデータ、例外メタデータ、オペレーション間の関係、およびタイプメタデータといった要素の１つ以上から構成され得る。
【００２５】
オペレーションメタデータは、所与のオペレーションに関連付けられるメタデータであり、当該オペレーションの名前を提供する。当該オペレーションの名前は、オペレーションについてのメタデータを名前によってルックアップするよう用いられ得る。各オペレーションメタデータオブジェクトは、基本的な種類の属性に関連付けられる。ある実施例では、この属性は、{READ-ONLY,UNDOABLE,NOT-UNDOABLE}といった３つの値のうちの１つを有する。あるオペレーションの基本的な種類がREAD-ONLYであれば、このオペレーションの実行には副作用もなく、修正を引き起こさない。あるオペレーションの基本的な種類がUNDOABLEであれば、このオペレーションの実行はアンドゥされ得る。あるオペレーションの基本的な種類がNOT-UNDOABLEであれば、このオペレーションの実行は、修正を引き起こし得るが、これらはアンドゥされ得ない。図４は、ある実施例におけるオペレーションの分類を示しており、いくつかのオペレーションがリードオンリであり、他のオペレーションが修正を行うことを示している。修正を行うオペレーションは常にアンドゥ可能ではないが、アンドゥ可能なオペレーションと、どのオペレーションがそれらをアンドゥするのに必要とされるかとはメタデータに記載され得る。
【００２６】
ある実施例では、あるオペレーションに関連付けられる付加的なメタデータが、あるオペレーションについてのメタデータをルックアップするよう用いられ得る。たとえば、オペレーションの属性の数およびタイプは、多形性のオペレーションに関連付けられるメタデータをルックアップするよう用いられ得る。多形性のオペレーションは、同じ名前を有する異なるオペレーションを示すので、名前のみによって識別され得ない。多形性のオペレーションの例としては、updatePersonInfo(String ssn,String name)およびupdatePersonInfo(String ssn, String name,String address)といった異なるオペレーションを有するupdatePersonlnfoがある。ある実施例では、位置的に識別され得る引数の配列を取るオペレーションが、メタデータに関連付けられ得る。
【００２７】
ある実施例では、各オペレーションが、パラメータメタデータオブジェクトのセットに関連付けられ得る。パラメータメタデータはオペレーションのパラメータを記述するメタデータである。各パラメータメタデータオブジェクトは、ストリングによって提供される名前属性を有する。名前属性の値は、パラメータの名前を提供する。タイプ属性もストリングによって提供される。さらに、各パラメータメタデータオブジェクトは、ストリングによって提供される目的属性を有し得る。異なる実施例では他のストリング値が用いられ得るが、ある実施例では「ＫＥＹ」、「ＳＥＬＥＣＴＯＲ」または「ＤＡＴＡ」である値が用いられる。他の実施例では、パラメータは、名前ではなく位置によって識別され得る。
【００２８】
ある実施例では、例外メタデータも提供され得る。例外メタデータは、例外に遭遇した場合に取られ得るアクションを規定するよう用いられ得る。たとえば、ビジネストランザクションまたは他のトランザクションがアンドゥされていて、かつその間にあるオペレーションが値を変更したので特定のオペレーションが例外を引き起こす場合、いくつかの可能性のあるアクションがアンドゥの要求側に提示され得る。１つのオプションは、トランザクション前の状態に値を戻すよう変更することなくアンドゥ動作に進むことであり得、別のオプションは、トランザクション前の状態に値を変更しながらアンドゥ動作に進むことであり得る。別のオプションは、アンドゥプロセスを全部停止することであり得る。他のオプションは、例外メタデータにおいて規定されるように、利用可能であり得る。
【００２９】
例外メタデータはさらに、アンドゥログエントリの生成の間に使用されてもよい。たとえば、更新がターゲットシステムになされようとする場合、アンドゥエンジン１２０は、アンドゥログへの包含のためにエントリを準備するが、エントリをアンドゥログに配置しないかまたは一時的に配置する。次に、実際のオペレーションがターゲットシステムに対して行われる際に例外が発生した場合、アンドゥエンジン１２０は何をするべきか決定しなければならない。デフォルトでは、例外が発生すれば、アンドゥエンジン１２０は、１）アンドゥエントリをアンドゥログに配置しないかまたは２）アンドゥログからエントリを除去する。例外が発生した場合、起こり得るシナリオは、何も発生しなかったということである。さらに、例外は、認証拒絶のような、オペレーションに固有でない一般的な例外であり得る。したがって、何かによってターゲットのサーバに対するオペレーションが失敗した場合、デフォルトのアクションは、デフォルトの解釈は何も起こらなかったということであるので、エントリを格納しないことである。そのためアンドゥすべきものがない。
【００３０】
しかしながら、いくつかの状況では、例外が起こるが、ａ）例外は警告であるが、実際の更新は発生するので、エントリはアンドゥログに配置されるべきである。これが行われることを確実にするために、この例外は警告であるが更新が失敗したことを意味するものではないとアンドゥエンジン１２０に命令するようある例外メタデータが格納される。このメタデータによって通知されると、アンドゥエンジン１２０は、当該エントリをアンドゥログに配置（またはある実施例ではそこに保持）する。
【００３１】
例外メタデータはさらに、部分的な更新を管理するために使用されてもよい。たとえば、役割を割り当てるためのオペレーションは、ユーザに３つの役割が割り当てられるよう要求するために用いられ得るが、これらの３つの要求された役割のうち２つのみが与えられる。アンドゥエンジン１２０は、返された例外を検討することを可能にするプランを必要とし、その例外から、何の役割が実際に割り当てられたのかを決定する。すなわち、実際に割り当てられた役割を列挙するペイロードを例外が有していなければ、アンドゥエンジン１２０は、割り当てられるべきと考えられた役割が実際に割り当てられたかどうかを決定するようクエリを発行し得る。いずれかの役割が失われていれば、それらの役割が割り当てられなかったとアンドゥエンジン１２０によって暗示され得、アンドゥエンジンは、アンドゥエントリのためのペイロードを変更し得る。たとえば、役割Ａ、ＢおよびＣが割り当てられるはずであったが、ユーザは役割ＡおよびＣのみ有する場合、Ｂが割り当てられなかったと暗示され得る。したがって、この現実を反映するためにアンドゥエントリが変更されなければならない。
【００３２】
ある実施例では、同じ意味を有しているが同一の名前は有していない形式上のパラメータ同士が相互に関連付けられることを可能にするよう名前マップが用いられる。たとえば、setJobCode(String username,int jobCode)およびgetJobCode(String name)の両方が同時に存在し得る。形式上のパラメータ「username」と「name」とは同一ではないが、同じ意味を有し得る。<operation-name.name> == <operation-name.name>の形態にある名前マップが用いられる。上記の例を用いて、名前マップはsetJobCode.username = getJobCode.name.となる。名前の取り扱いは、アンドゥ命令から形成されるアンドゥプランは多くの場合、１つのオペレーションの実際の引数を別のオペレーションの引数に関連付ける必要があるので、重要である。アンドゥプランは、必要であれば、異なる名前を有する引数をマッチアップし得るように名前マップを認識する必要がある。名前マップがこれを可能にする。
【００３３】
ある実施例では、製品のレガシーバージョンに関連付けられるオペレーションに基づき生成されたアンドゥログが当該製品がアップグレードされた後でもビジネストランザクションをアンドゥするよう用いられ得ることを確実にするようメタデータが用いられ得る。たとえば、ある実施例では、変換メタデータは、古いオペレーション識別子から新しいオペレーション識別子にマッピングを提供し得る。アップグレードに耐えるアンドゥログの他の方法も用いられ得る。たとえばある実施例では、アンドゥログはアップグレードモジュールによってリライトされ得るので、アップグレードされた製品に関連付けられるエントリは、当該アップグレードされた製品に関連付けられるオペレーションを参照する。ある実施例ではエントリはメタデータを含み得る。たとえば、エントリは、ターゲットシステムまたは他の間に存在するシステムのアップグレードによって影響を受けるエントリとして、エントリにフラグを立てるメタデータを含み得る。
【００３４】
３．２  アンドゥログ
メタデータが、本願明細書においてアンドゥ命令と称される、ビジネストランザクションのようなトランザクションの一部として行われるオペレーションを反転させるアンドゥログエントリを生成するよう用いられる。アンドゥログは、順序付けられたエントリのリストである。本願明細書において使用されるように、「エントリ」という用語は、データの識別可能なセットを指すよう意図されており、任意の量の情報を含んでもよい。たとえば、エントリは、メタデータ、エントリの始まりまたは終わりを識別するエントリ境界マーカ、または特定のビジネストランザクションに関連付けられる１つ以上のエントリのセットの始まりまたは終わりを識別するビジネストランザクション境界マーカを含んでもよい。ある実施例では、エントリは、アンドゥエントリまたはベリフィケーションエントリのいずれかであってもよい。アンドゥエントリの目的は、アンドゥアクションの全セットの一部である何らかの更新を行うことである。ベリファイヤエントリは、データがOracle Rewindによって予測されるようなものであることを検証するよう存在する。データが検証されなければ、書き込みコンフリクトが発生している。ある実施例では、アンドゥエントリは以下の形態を取る。
{target-info, operation-name, [引数]}
ある実施例では、ベリフィケーションステップが、特定のビジネストランザクションに関連付けられるベリフィケーションの進行を記録するよう行われる際に、ベリフィケーションエントリはフラグを立てられ得る。ある実施例では、アンドゥステップが、特定のビジネストランザクションに関連付けられるアンドゥの進行を記録するよう行われる際に、アンドゥエントリはフラグを立てられ得る。復旧が必要な失敗の際に、アンドゥエントリフラグは、失敗により完了されなかったアンドゥオペレーションの状態を決定するようアンドゥエンジン１２０によってチェックされ得る。
【００３５】
ベリフィケーションエントリも復旧目的に使用されてもよい。ある実施例では、ベリフィケーションエントリは、値が１つ以上のオペレーションの実行の成功（すなわち「予測された」状態）と一貫しているかどうかを決定するよう用いられ得る。たとえば、ｘについて予測される値が「３」であることを示すベリファイヤが存在する場合があるが、この値が「２」であることが分かり、「２」がアンドゥアクションエントリ自体の値である。他方、現在の値が「２」であれば、前回の更新が失敗したと適切に結論付けることができる。エントリが成功と一貫していなければ、たとえば、値を正しい値に設定することによってこの問題を解決するようアンドゥポリシーまたはアドミニストレータアクションが用いられ得る。
【００３６】
target-infoのフィールドにおけるデータは、オパックブロブ（opaque blob）であると考えられ得る。ターゲットタイプに関連付けられるアダプタは、target-info中のデータと、operation name-nameと、引数とを取り、アクションを実行し得る。target-infoは実際のオブジェクトリファレンスであり得、ＪＤＢＣ接続を識別し得、またはターゲットに関する他の情報を提供する。target-infoは、ターゲットが識別およびアクセスされることを可能にするものであり得る。アンドゥロジックは、このtarget-infoを用いて、読込／書込目的のためにターゲットにアクセスする。ある実施例では、アンドゥエンジン１２０は、プロキシＭｂｅａｎサーバ３２０およびＳＯＡＰルータ３３０のようなターゲットに関連付けられるアダプタに依存しており、当該ターゲットとインターフェイス接続する。
【００３７】
アンドゥログエントリは、アンドゥログデータテーブル２６４に加えられてバーチャルアンドゥリストを作成し得る。ある実施例では、アンドゥログエントリは、リストの最後に加えられ得る。この場合、アンドゥ命令の実行は、逆の順番の復元が望まれる場合、リストの最後からリストの最初に実行される。換言すると、ある実施例では、オペレーションは、元来適用されたのと反対の順番でアンドゥされる。別の実施例では、オペレーションは、同時、または元々実行された順番とは逆の順番と異なる順番でアンドゥされる。
【００３８】
アンドゥ命令は、提供されたoperation nameおよび引数を用いて、アンドゥロジック２４０によって実行される。具体的には、各サービスについての命令を実行するようアダプタが使用される。アダプタの例は、プロキシＭｂｅａｎサーバ３２０、ＳＯＡＰルータ３３０、またはプロキシＬＤＡＰサーバといった他のプロキシである。各アダプタは、各命令の実行後、一般的なアンドゥエンジン３１０にランタイムを返す。
【００３９】
アンドゥ命令を実行しつつ、変更されているオブジェクトの現在の状態が、最初の変更がなされた直後のオブジェクトの状態と一貫するかどうかをアンドゥロジック２４０が決定することを可能にするようベリファイヤエントリがアンドゥログに加えられ得る。換言すると、実行される際のベリファイヤエントリは、その後の変更がオブジェクトに対してなされたかどうかをアンドゥロジック２４０に伝える。ベリファイヤエントリについて、当該アクションは、アダプタに対して実行され、ある値が返される。ベリフィケーションエントリは、「expected-value」によって示される予測値を保持する。実際の値（アダプタから返された値）を予測値と比較するよう、設けられたコンパレータが用いられる。コンパレータに従ってこれらの値が等しければ、予測値は検証されており、書き込みコンフリクトが存在しない。そうでなければ、書き込みコンフリクトが存在する。たとえば、「青」の値を有する属性がその後「赤」に設定される場合、ベリファイヤエントリがアンドゥログに生成される。実行される際のベリファイヤエントリは、値がその後のオペレーションによって変更された場合、値を青に戻すよう設定する前に、アンドゥエンジン１２０が値が「赤」であることを検証することを可能にする。本発明のある実施例では、より具体的には、Ｍｂｅａｎサーバ３２０およびＳＯＡＰルータ３３０は、変更されているオブジェクトの現在の状態が、最初の変更がなされた直後のオブジェクトの状態と一貫しているかどうかを決定するアンドゥロジック２４０のコンポーネントである。
【００４０】
以下の擬似コードは、ある実施例において用いられ得る１つのアンドゥログ実行ストラテジを示す。
【００４１】
【数１】
2014534532.tif 000003
【００４２】
３．３  アンドゥレット
基本的な種類のUNDOABLEを有する各オペレーションメタデータは、ある実施例では、「アンドゥレット（undolet）」に関連付けられる。アンドゥレットは、特定のオペレーションタイプに関連付けられるオペレーションをアンドゥすることが可能なオブジェクトである。たとえば、アンドゥレットは、「セッタ」オペレーションであるオペレーションをアンドゥすることが可能であり得る。ある実施例では、いくつかのアンドゥレットは特定のオペレーションをアンドゥすることが可能であり、オペレーションタイプに関連付けられない。別の実施例では、アンドゥレットは、ターゲットと単一の引数（またはパラメータ）とのみを有する「セッタ」オペレーションのようなあるオペレーションタイプのオペレーションのサブセットに関連付けられ得る。この場合、複数のアンドゥレットが、「セッタ」オペレーションタイプに関連付けられ得る。オペレーションのアクションをアンドゥすることは、関連付けられるアンドゥレットにおいて、ロジックによって行われる。ある実施例では、オペレーションがアンドゥレットに関連付けられなければ、オペレーションはアンドゥされ得ない。アンドゥレットは、それらのアンドゥレット識別子によって識別される。たとえば、名前はアンドゥレット識別子として使用されてもよい。したがって、setColorという名前のオペレーションについてのオペレーションメタデータは、「セッタ」のアンドゥレット識別子を有し得る。クラスPersonについてのPerson(String name)のようなＪａｖａコンストラクタは、「コンストラクタ」のアンドゥレット識別子を有し得る。
【００４３】
ある実施例では、アンドゥレットはアンドゥロジック２４０において実現されており、データベース２６０のようなアンドゥレットレポジトリに別個に格納され得る。UNDOABLEオペレーションの呼出しがあると、メタデータレポジトリにおける関連付けられたオペレーションメタデータ中の当該オペレーションによって参照されるアンドゥレットが呼び出される。各アンドゥレットは、抽象化レイヤーとして機能し、アンドゥレットのオペレーションタイプに関連付けられるオペレーションを、サービスによって必要とされる実際のオペレーションにマッピングする。たとえば、ある実施例では、アンドゥレットは、オペレーションsetColor()をsetXXX()と呼ばれる一般的な「セッタ」オペレーションにする。この抽象化は、すべてのセッタオペレーションのビヘイビアは同様のプロパティを有しているのでアンドゥロジック２４０によって同じ態様で処理され得るため、可能である。
【００４４】
アンドゥレットは、なんらかのターゲットに対する引数とともにアクションを取る能力を提供し、適切なアンドゥエントリを生成するとともに当該アクションについてエントリを検証する。アンドゥプランは、０、１つまたはそれ以上のエントリをアンドゥログ中に生成し得る。エントリの数およびそれらのエントリのタイプ（アクション対ベリフィケーション）は完全に、所与のタイプのオペレーション（たとえばゲッタ、セッタ、コンストラクタ、デストラクタなど）についてのアンドゥプラン次第である。各アンドゥプランは、所与のターゲットについてメタデータへのアクセスを得ることが可能である。このメタデータを用いて、アンドゥプランは次いで、適切であるアンドゥエントリを生成することを求め得る。さらに、アンドゥレットに有用であり得るデータを集めるためにクエリが使用されてもよい。以下はアンドゥレットの例である。
【００４５】
【数２】
2014534532.tif 000004
【００４６】
上記の例において用いられる「セッタ」オペレーションタイプの場合、アンドゥプランは、setXオペレーションについて「getter」フィールドの値をルックアップし得る。このデータは、このターゲットタイプについてのメタデータにおいて発見される。ゲッタフィールドは、「getX」の値を有し、引数を取らない。アンドゥプランは次いで、target info、operation（「getX」）および引数（なし）を提供するアダプタに対するコマンドを呼び出す。アダプタに対するこの呼出しは、たとえば、０を返し得る。次いで、このアンドゥプランは、このオペレーションについて「セッタ」をルックアップし得る。すなわち、アンドゥエントリについての値を書き込むのにどのオペレーションを用いるべきかをルックアップし得る。ここで、オペレーション「setX」についてのメタデータが、セッタが「setX」自体であることを示し得、したがってアンドゥエントリは「setX」であるtarget-infoとともに作成されることになる。したがって、アンドゥ可能なアンドゥエンジン１２０である各タイプのオペレーションについて、当該アクションについて適切なアンドゥエントリ（または複数のエントリ）を生成することに特化したアンドゥレットが存在する。アンドゥレットの実際のプランは、セッタについてのアンドゥレットの上記の記載によって示されるように相対的にシンプルであり得るか、またはより複雑なプランが生成され得る。一定のままであることは、アンドゥレットがメタデータ、データ収集および意思決定を用いて当該アクションについて０、１つまたはそれ以上のアンドゥエントリを適切に生成し得るプランを提供することである。
【００４７】
３．４  メタデータドリブンのアンドゥの実行
ある実施例では、データベース２６０のようなメタデータレポジトリは、オペレーションに関連付けられるメタデータを格納する。たとえば、メタデータは、オペレーションがセッタ、ゲッタ、コンストラクタ、デストラクタ、アダー、リムーバ、または他のタイプのオペレーションであるかどうかといったオペレーションのタイプを識別し得る。各オペレーションに関連付けられる属性も、メタデータに格納される。
【００４８】
ある実施例では、各オペレーションは、アンドゥエントリを生成するための命令を含むアンドゥレットに関連付けられる。ある実施例では、アンドゥレットは、ターゲットシステムを考慮せず、オペレーションのタイプまたはオペレーションカテゴリに属する任意のオペレーションに対する任意の呼出しを取り扱うことが可能である。たとえば、デストラクタについてのアンドゥレットは、Ｍｂｅａｎについてのデストラクタとウェブサービスについてのデストラクタとを含む任意のデストラクタのために動作する。たとえば、デストラクタについてのアンドゥレットは、当該オブジェクトを再作成しその属性を適切にセットするための命令を含む。たとえば、「ジョン」という名前と「灰色」という髪の色を有するパーソンオブジェクトが削除され、この削除オペレーションが「デストラクタ」のオペレーションタイプを有していれば、当該オペレーションタイプ「デストラクタ」に関連付けられるアンドゥレットが次いで、これらの属性の２つの値を、パーソンオブジェクト上にそれらをセットする適切なオペレーションとともに集め得、次いでアンドゥレットがアンドゥエントリを生成してパーソンオブジェクトを再作成する。逆の順で実行される場合、パーソンオブジェクトは、まず作成され、次いで属性値が割り当られ、削除されたオブジェクトを完全に復元する。「セッタ」のオペレーションタイプについてのアンドゥレットはさらに、当該オペレーションタイプ「セッタ」の任意のオペレーションについてエントリを生成するよう動作する。セッタアンドゥレットは、セッタオペレーションへの参照を含み、値が変更されたオブジェクトを示す属性と、変更の前の当該オブジェクトの値を示す別の属性とを含む。ある実施例では、セッタアンドゥレットは、メタデータレポジトリにおいてセッタオペレーションについてメタデータをルックアップし、セッタアンドゥレットが属性の現在値について問い合わせを行うよう用いられ得る関連付けられるゲッタオペレーションを識別することを可能にする。次いで、必要に応じて、セッタアンドゥレットは付加的なメタデータを用いて、このクエリにおいてどの引数（あれば）が用いられるのかを決定する。この構築されたクエリは次いで、この現在値を引き出すようアダプタを用いて実行され得る。このクエリの結果は、この属性の現在値を提供する。次いで、セッタアンドゥレットは、メタデータレポジトリにおいてセッタオペレーションについてのメタデータをルックアップし、この値をセットするようどのオペレーションが用いられるかを決定する。次いで、セッタアンドゥレットはアンドゥログにおいて適切なエントリを生成する。たとえばまずアンドゥエントリを生成して、次いでベリファイヤエントリを生成する。
【００４９】
ある実施例では、アンドゥロジック２４０は、メタデータレポジトリ中のメタデータとアンドゥレットとに基づき、アンドゥログ中に１つ以上のエントリを生成するよう構成される。アンドゥログ中のエントリは、システムによってインターセプトされる第１の要求中のオペレーションに基づいてもよく、当該オペレーションに関連付けられる第１の属性についての第１の属性値を含んでもよい。たとえば、ある実施例において、setColor(user123, red)についてのアンドゥレットは、一般的なセッタアンドゥレットであり得るセッタアンドゥレットである。アンドゥレットにおける命令とメタデータとを用いて、アンドゥロジック２４０は、ユーザ１２３（たとえば青）についての現在の色値を格納するエントリを生成し、その色に戻すための命令を、色が現在赤にセットされていれば、生成する。アンドゥポリシーは、色を黄色のような別の色に変更しても、色を青に戻すよう変更することが可能であり得る。古い色が決定されてから、getColor(user123)のようなゲッタを用いることにより新しい色が設定される。この場合、ベリファイヤは、getColor(user123)が「赤」を返し、オペレーションをアンドゥするためのアンドゥログにおける命令がsetColor(user123, blue)であるように見得ることを検証する。ベリファイヤが無視されるべきであるとアンドゥポリシーが指示する場合、ベリファイヤはアンドゥエンジン１２０によって無視され得る。本発明の実施例では、より具体的に、Ｍｂｅａｎサーバ３２０およびＳＯＡＰルータ３３０は、メタデータレポジトリ中のメタデータおよびアンドゥレットに基づき、アンドゥログに１つ以上のエントリを生成するよう構成されるアンドゥロジック２４０のコンポーネントである。
【００５０】
上記の段落に記載された擬似コードは、同じタスクを達成する任意の命令と置換されてもよい。たとえばある実施例では、ＳＱＬクエリ、またはウェブサービスを呼び出すとともに検証されるべき値と設定されるべき値とを識別するＵＲＬがアンドゥログエントリとして用いられ得る。ある実施例では、これらの命令は、getColor()オペレーションをアンドゥするよう要求をアンドゥエンジン１２０にて受け取ることに応答して実行される。
【００５１】
ある実施例では、オペレーションが同じビジネストランザクションに関連付けられる際にオペレーションをともにグループ化するようセッションが用いられる。たとえば、第１のビジネストランザクションは２０個のオペレーションを含み得、第２のビジネストランザクションは１５個のオペレーションを含み得る。これらのオペレーションは異なるターゲットシステムまたはサーバ１３０のようなサーバ上で実行され得る。各オペレーションは、さらにセッションを識別する要求の一部として受け取られる。たとえば、要求は、実行されるべき１つ以上のオペレーションと、セッション識別子値とを含み得る。ある実施例では、第１のビジネストランザクションおよび第２のビジネストランザクションは、アンドゥエンジン１２０がたとえ第１のビジネストランザクションに関連付けられる２つの他の要求の間に第２のビジネストランザクションに関連付けられる要求を受け取っても、異なるセッション識別子を有することになる。すなわち、要求が受け取られる順番は、どのセッションに要求および当該要求中のオペレーションが関連付けられるのかに必ずしも影響を与えない。ある実施例では、単一の要求が、異なる対応するセッション識別子によって関連付けられる複数のオペレーションを識別し得る。
【００５２】
ある実施例では、同じビジネストランザクションに関連付けられる異なるオペレーションは、必ずしも同じターゲットシステムに関連付けられない。アンドゥログは、アンドゥ命令のためのストレージメカニズムであり、命令の複数のセットを含み得る。命令の各セットはセッションに関連付けられ得る。アンドゥ命令の各セットは、複数のターゲットシステムに向けられる命令またはエントリを含み得る。アンドゥコマンドが呼び出されると、命令が複数のターゲットシステムに亘っても、セッションに関連付けられる命令のすべてが実行され得る。ある実施例では、第１のセッションに関連付けられる命令の１つのセットの実行は、異なるセッションに関連付けられる命令の実行を引き起こさない。
【００５３】
ある実施例では、セッション管理ロジック２３０は、ビジネストランザクションの境界を制御することができる、クライアントによって提供されるセッション情報を管理する。換言すると、クライアントは、同じビジネストランザクションのすべての部分であるいくつかの要求を行い得る。セッション管理ロジックは、要求に関連付けられるセッション識別情報を読み出すことによりビジネストランザクションの境界を決定する。あるセッション識別子および複数のセッション境界識別子は、ある実施例では、どの要求が特定のセッションに関連付けられるかを識別するよう用いられ得る。さらに、セッションにおける各要求は、シーケンシャル番号識別子を含み得、境界要求は、アンドゥエンジン１２０によって受け取られ得るまたはアンドゥエンジン１２０によって受け取られるべきだった要求の数またはタイプを規定する付加的なメタデータを含み得る。どのセッションに要求が関連付けられるかを識別することにより、要求に基づき生成されるアンドゥ命令は、適切なアンドゥログに配置され得る。次いで、クライアントは、セッションのみを識別することにより特定のセッションがアンドゥされることを要求し得る。
【００５４】
上で論じたように、実施例は、アンドゥログを維持することに関して、ビジネスオペレーションの取り扱いの完了を示すアンドゥログエントリを規定し得る。たとえば、セッタアンドゥレットは、変数をその以前の値に戻し、次いでベリファイヤエントリを加えるアクションを生成し得、アンドゥエンジンは次いで、ビジネスオペレーション境界エントリをアンドゥログに加えて、ビジネスオペレーションがアンドゥログを維持する点で完全に取り扱われたということを示す。このビジネスオペレーション境界エントリは、単一のビジネスオペレーションのこれらのエントリと、任意の他のビジネスオペレーションに関係付けられるエントリとの間の境界を示す。
【００５５】
同様に、実施例は、アンドゥログ中への包含のためにビジネストランザクション境界エントリを規定し得る。このビジネストランザクション境界エントリは、ビジネスオペレーションのすべてのオペレーションがアンドゥログに入力されていることを示す。ビジネストランザクションの完了を示すアンドゥログにおける情報は、特に電源異常のような深刻な障害から回復することにおいて有用であり得る。ビジネストランザクション境界エントリを有さないアンドゥログが検出される場合、ビジネストランザクション境界エントリがないことは、全体のビジネスプロセスの完了が成功しなかったことを示す。次いで、この情報に基づき、不完全なビジネストランザクションのすべての変更をアンドゥすることを決定するといった適切な決定がなされ得る。
【００５６】
ここで、これらの付加的なタイプのエントリを有するアンドゥログの一例がある。各エントリは数でラベリングされているので、テキストは、このアンドゥログにおける個々のエントリを指し得る。
【００５７】
【数３】
2014534532.tif 000005
【００５８】
business-transaction[9]の存在は、ビジネストランザクションが完了したことを示す。ここで、アドミニストレータが最後のビジネスオペレーションのアクションを個々にアンドゥすることを望んでいると仮定する。ある実施例は、１度に１つビジネスオペレーションをアンドゥする能力を提供し得る。上記のアンドゥログごとに、この発明のある実施例は、verifier[7]を用いてシステム状態を検証し得、action[6]、action[5]およびaction[4]のアクションを適用し得る。operation-boundary [3]の存在は、異なるビジネスオペレーションについてのエントリの開始を示すので、アンドゥエンジンは単一のビジネスオペレーションの更新をアンドゥした。所望の場合、次いで、アンドゥエンジンは、まずシステム状態をverifier[2]で検証するとともにaction[1]を適用することにより、第１のビジネスオペレーションの更新をアンドゥするよう進み得る。
【００５９】
この例は、一般に、アンドゥログにおける明瞭な境界が個々のビジネスオペレーションの効果が最後のビジネスオペレーションから最後から２番目などに１度に１つアンドゥされることをどのように可能にするかを示す。ある実施例では、他の境界またはマーカはアンドゥログにおいて実現され得る。たとえば、「セーブポイント」がアンドゥログに加えられ得る。セーブポイントは、アンドゥオペレーションがそのセーブポイントまで行なわれることを可能にするよう加えられ得る。これは、テスト目的のために特に有用である。
【００６０】
ある実施例では、クライアントは、アンドゥセッションに対して明示制御または暗黙制御を有し得る。たとえば、ＢＰＥＬ（Business Process Execution Language）エンジンが用いられる場合、次いでプロセスの開始が暗黙にアンドゥセッションをスタートさせ得る。もしアンドゥコマンドがＢＰＥＬプロセスのコンテキストの内で発行されれば、全体のプロセスがアンドゥされる（またはアンドゥが試みられる）。クライアントＡＰＩが使用される場合、クライアントはアンドゥセッションを開始する命令を提供し、アンドゥオペレーションを実行することなくアンドゥセッションを終了し、アンドゥセッション内でアンドゥオペレーションを実行する。
【００６１】
ある実施例では、アンドゥエンジン１２０はさらに、クライアントとサーバとの間の非同期要求を管理するためにセッションロジック２３０を使用する。まず、クライアントはアンドゥエンジン１２０にメッセージを送る。アンドゥエンジン１２０は、適切なアクションを取る（たとえばアンドゥログ中にアンドゥエントリを生成するようアンドゥレットを使用する）。次いで、アンドゥエンジン１２０は、サーバへの非同期要求をする。アンドゥエンジン１２０は、成功または失敗を示す通知またはコールバックのような、サーバからの返答またはペイロード中の他の情報を待つ。アンドゥエンジン１２０は応答に基づき適切なアクションを取り、応答をクライアントに返す。
【００６２】
３．５  アンドゥポリシー
ある実施例では、アンドゥエンジン１２０が直面し得る予想されるシナリオに対処するようアンドゥポリシーが用いられる。たとえば、アンドゥポリシーは、アンドゥされ得ない、NOT-UNDOABLEのタイプのオペレーションといったオペレーションが発生するのを防止するよう用いられ得る。不可逆的なオペレーションの実行を防止するようアンドゥエンジン１２０に命令するポリシーを規定することにより、アンドゥされ得ない、システムへの潜在的に損害の大きい変更に対して付加的な安全性が提供される。この例は、初期のオペレーションに影響を与えるポリシーを議論しているが、他のアンドゥポリシーが、要求が満たされた後またはアンドゥ要求の間に起こるシナリオに対処するよう実現され得る。
【００６３】
アンドゥポリシーは、失敗のシナリオのような多くの状況において用いられ得る。たとえば、アンドゥエンジン１２０は、６つのオペレーションを含むセッション１２３４５６に関連付けられるすべてのオペレーションをアンドゥする要求を受け取り得る。適切なアンドゥログエントリがオペレーションの各々について存在するが、オペレーションの１つに関連付けられるアンドゥ命令の実行が失敗し得る。たとえば、関係付けされない要求によって、アンドゥセッションに関連付けられる値が変更されるので、ベリフィケーションオペレーションは失敗し得る。上述したように、選択するようオプションをユーザに提供するようユーザインターフェイスが用いられてもよいが、アンドゥ要求を継続するかどうかを決定するアンドゥポリシーを規定するのがアドミニストレータにとってより簡便になり得る。たとえばポリシーは、アンドゥオペレーションの間に発生する如何なる失敗によって、アンドゥオペレーションが停止し、オペレーションが継続するべきかどうかをユーザに尋ねるユーザインターフェイス要素が生成されることを指示し得る。異なるポリシーは、アンドゥコマンドが常に実行され、失敗しているベリファイヤがそのセッションについて生成されたログファイル中で報告されることを指示し得る。
【００６４】
さらに、アンドゥオペレーションが始まる前にアンドゥログ内のすべてのベリファイヤがチェックされることを指示するようポリシーが用いられ得る。たとえば、セッション１２３４５６に関連付けられるすべてのオペレーションをアンドゥする要求は、アンドゥエンジン１２０によって受け取られ得る。ある実施例では、アンドゥエンジン１２０はまず、すべてのベリファイヤ命令を実行して、ビジネストランザクションに関連付けられるデータの現在の状態がトランザクション前のデータと一貫しているかどうか、または（たとえばデータに関連付けられるタイムスタンプをチェックすることにより）他のオペレーションがデータを変更しなかったことを決定する。データが一貫している場合、ポリシーはアンドゥオペレーションが継続することを指示し得る。データが一貫していない場合、ポリシーは、アンドゥオペレーションを終了してユーザに通知することを指示し得る。
【００６５】
３．６  アンドゥエンジンの停止
アンドゥエンジンのオペレーションの停止が有用であり得るいくつかの場合がある。たとえば、システムアドミニストレータが、複数のシステムに変更を加えており、アンドゥエンジン１２０によって提供される安全性なしで動作することができると感じていて、アンドゥエンジン１２０を無効にすることにより、アンドゥエンジン１２０によって使用されるリソースを解放することを好むことがある。ある実施例では、アンドゥエンジン１２０は、アンドゥログ生成、他の機能を停止もしくはオフにするかまたは完全にアンドゥエンジン１２０をシャットダウンする要求をサポートする。オフにされる効果は、実現例に依存して変動し得る。アンドゥエンジンは、中間部として実現されると、単純に各要求を受け取り、それをターゲットに渡す。アンドゥエンジンは、埋め込まれたフットプリントとして実現されれば、埋め込まれたアンドゥエンジン１２０のコンポーネントが全く呼び出されないようにそのロジックを変更する。ある実施例では、アンドゥエンジン１２０の一部を停止するために、全アンドゥエンジン１２０が停止される必要はない。任意の理由により、アンドゥエンジン１２０の如何なる部分も個々に停止され得る。たとえば、システムに対する間に存在する変更の可能性がほとんどないかまたは全くない場合には性能の増加のためにベリフィケーションステップを引き換えにすることをユーザが快適に感じるかもしれないので、単一ユーザ／非同時環境においてすべてのベリフィケーションメカニズムを停止することが適切であり得る。
【００６６】
４．０  実現メカニズム−ハードウェア概要
一実施例によれば、本願明細書において記載された技術は、１つ以上の特殊目的のコンピューティング装置によって実現される。当該特殊目的のコンピューティング装置は、これらの技術を行なうためにハードワイヤードされてもよく、または１つ以上の特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）のような、当該技術を行なうように持続的にプログラムされたデジタル電子装置を含んでもよく、またはファームウェア、メモリ、他のストレージまたは組合せ中のプログラム命令に従った技術を行なうようにプログラムされた１つ以上の汎用ハードウェアプロセッサを含んでもよい。このような特殊目的のコンピューティング装置はまた、当該技術を達成するために、カスタムハードワイヤードロジック、ＡＳＩＣまたはＦＰＧＡをカスタムプログラミングに組み合わせ得る。特殊目的のコンピューティング装置は、デスクトップコンピュータシステム、ポータブルコンピュータシステム、ハンドヘルドデバイス、ネットワーク装置、または当該技術を実現するようハードワイヤードおよび／またはプログラムロジックを統合する任意の他の装置であり得る。
【００６７】
たとえば、図５は、本発明の実施例が実現され得るコンピュータシステム５００を示すブロック図である。コンピュータシステム５００は、情報を通信するためのバス５０２または他の通信メカニズムと、データを処理するためにバス５０２に結合されるハードウェアプロセッサ５０４とを含む。ハードウェアプロセッサ５０４はたとえば、汎用マイクロプロセッサであり得る。
【００６８】
コンピュータシステム５００はさらに、ランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置のような、情報およびプロセッサ５０４によって実行される命令の格納のためにバス５０２に結合されたメインメモリ５０６を含む。メインメモリ５０６は、さらにプロセッサ５０４によって実行される命令の実行の間に、一時変数または他の中間情報を格納するために使用され得る。プロセッサ５０４にアクセス可能な記憶媒体に格納された際のこのような命令はコンピュータシステム５００を、当該命令において特定されたオペレーションを行うようカスタマイズされる特殊目的マシンにする。
【００６９】
コンピュータシステム５００はさらに、静的情報とプロセッサ５０４のための命令とを格納するために、バス５０２に結合されるリードオンリメモリ（ＲＯＭ）５０８または他の静的記憶装置を含む。磁気ディスクまたは光ディスクのような記憶装置５１０は、情報および命令を格納するために設けられバス５０２に結合される。
【００７０】
コンピュータシステム５００は、コンピュータユーザに情報を表示するために陰極線管（ＣＲＴ）のようなディスプレイ５１２にバス５０２を介して結合され得る。英数字および他のキーを含む入力装置５１４が、プロセッサ５０４に情報およびコマンド選択を通信するために、バス５０２に結合される。別のタイプのユーザ入力装置は、プロセッサ５０４に方向情報およびコマンド選択を通信するとともにディスプレイ５１２上でカーソル移動を制御するための、マウス、トラックボール、またはカーソル方向キーのようなカーソルコントロール５１６である。この入力装置は典型的に、装置がある面において位置を特定することを可能にする、第１の軸（たとえばｘ）および第２の軸（たとえばｙ）の２つの軸において２つの自由度を有する。
【００７１】
コンピュータシステム５００は、コンピュータシステムと組み合わされると、コンピュータシステム５００を特殊目的マシンにするまたは特殊目的マシンになるようプログラムするカスタマイズされたハードワイヤードロジック、１つ以上のＡＳＩＣもしくはＦＰＧＡ、ファームウェアおよび／またはプログラムロジックを用いて、本願明細書において記載された技術を実現し得る。一実施例によると、メインメモリ５０６に含まれる１つ以上の命令の１つ以上のシーケンスをプロセッサ５０４が実行することに応答してコンピュータシステム５００によって本願明細書における技術が行われる。このような命令は、記憶装置５１０のような別の記憶媒体からメインメモリ５０６に読み込まれ得る。メインメモリ５０６に含まれる命令のシーケンスの実行により、プロセッサ５０４が、本願明細書において記載されるプロセスステップを行う。代替的な実施例では、ハードワイヤードの回路網は、ソフトウェア命令の代わりにまたはソフトウェア命令と組み合わせて使用されてもよい。
【００７２】
本願明細書において用いられるような「記憶媒体」という用語は、データおよび／またはマシンを特定の態様で動作させる命令を格納する任意の媒体を指す。このような記憶媒体は、不揮発性媒体および／または揮発性媒体を含んでもよい。不揮発性媒体はたとえば、記憶装置５１０のような光学ディスクまたは磁気ディスクを含む。揮発性媒体は、メインメモリ５０６のような動的メモリを含む。記憶媒体の一般的な形態はたとえば、フロッピーディスク（登録商標）、フレキシブルディスク、ハードディスク、ソリッドステートドライブ、磁気テープ、または任意の他の磁気データ記憶媒体、ＣＤ−ＲＯＭ、任意の他の光学データ記憶媒体、穴のパターンを有する任意の物理的な媒体、ＲＡＭ、ＰＲＯＭ、およびＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、ＮＶＲＡＭ、任意の他のメモリチップまたはカートリッジを含む。
【００７３】
記憶媒体は、伝送媒体とは異なるが、伝送媒体に関連して用いられ得る。伝送媒体は、記憶媒体同士の間で情報を転送することに関与する。たとえば、伝送媒体は、バス５０２を含むワイヤを含む、同軸ケーブル、銅線、およびファイバオプティクスを含む。伝送媒体はさらに、電波および赤外線データ通信の間に生成されるもののような音波または光波の形態を取り得る。
【００７４】
媒体のさまざまな形態は、実行のために１つ以上の命令の１つ以上のシーケンスをプロセッサ５０４に搬送することに関係され得る。たとえば、命令は最初は、リモートコンピュータの磁気ディスクまたはソリッドステートドライブ上で担持され得る。リモートコンピュータは、当該命令を動的メモリにロードし、モデムを用いて電話回線上で命令を送る。コンピュータシステム５００に対してローカルのモデムが、電話回線上でデータを受け取り、赤外線送信機を用いてデータを赤外線信号に変換し得る。赤外線信号において運ばれたデータを赤外線検出器が受け取り得、適切な回路網がデータをバス５０２上に配置し得る。バス５０２はデータをメインメモリ５０６に運び、そこからプロセッサ５０４が命令を抽出および実行する。メインメモリ５０６によって受け取られた命令は、プロセッサ５０４による実行の前にまたはその実行の後に、記憶装置５１０上に随意に格納され得る。
【００７５】
コンピュータシステム５００はさらに、バス５０２に結合される通信インターフェイス５１８を含む。通信インターフェイス５１８は、ローカルネットワーク５２２に接続されるネットワークリンク５２０に結合する２方向のデータ通信を提供する。たとえば、通信インターフェイス５１８は、データ通信接続を対応するタイプの電話回線に提供するよう総合サービスデジタル網（ＩＳＤＮ）カード、ケーブルモデム、衛星モデム、またはモデムであり得る。別の例として、通信インターフェイス５１８は、データ通信接続を互換性のあるＬＡＮに提供するようローカルエリアネットワーク（ＬＡＮ）カードであり得る。無線リンクも実現され得る。任意のこのような実現例では、通信インターフェイス５１８は、さまざまなタイプの情報を示すデジタルデータストリームを運ぶ電気信号、電磁気信号または光学信号を送信および受信する。
【００７６】
ネットワークリンク５２０は、典型的に１つ以上のネットワークを通じて他のデータ装置にデータ通信を提供する。たとえば、ネットワークリンク５２０は、ローカルネットワーク５２２を通りホストコンピュータ５２４へのまたはインターネットサービスプロバイダ（ＩＳＰ）５２６によって動作されるデータ機器への接続を提供し得る。ＩＳＰ５２６は、現在一般に「インターネット」５２８と称されるワールドワイドパケットデータ通信ネットワークを通じてデータ通信サービスを提供する。ローカルネットワーク５２２およびインターネット５２８はともに、デジタルデータストリームを運ぶ電気信号、電磁気信号または光学信号を用いる。デジタルデータをコンピュータシステム５００に運ぶまたはコンピュータシステム５００から運ぶ、さまざまなネットワークを通る信号と、通信インターフェイス５１８を通るネットワークリンク５２０上の信号とは、伝送媒体の例示的な形態である。
【００７７】
コンピュータシステム５００は、ネットワーク、ネットワークリンク５２０および通信インターフェイス５１８を通じて、メッセージを送り、プログラムコードを含むデータを受け取り得る。インターネットの例では、サーバ５３０は、インターネット５２８、ＩＳＰ５２６、ローカルネットワーク５２２および通信インターフェイス５１８を通じて、アプリケーションプログラムについての要求されたコードを送信し得る。
【００７８】
受け取られたコードは、受け取られた際にプロセッサ５０４によって実行され得る、および／または後での実行のために記憶装置５１０もしくは他の不揮発性ストレージに格納され得る。
【００７９】
上記の明細書では、本発明の実施例は実現例ごとに変動し得る多くの特定の詳細を参照して記載された。したがって、明細書および図面は、限定的な意味ではなく例示的な意味であるとみなされるべきである。本発明の範囲の唯一かつ排他的な指標と、発明の範囲であることが出願人によって意図されるものとは、任意のその後の補正を含む、そのような請求項が発生する特定の形式にある、この出願から発生する請求項の組の文字どおりかつ等価な範囲である。なお、さまざまな実施例に対する修正例および変形例が考慮される。修正例はたとえば、異なる所望または必要とされる動作特性に基づき得る。変形例は、請求された特徴の組合せを含んでもよい。
【図１Ａ】
2014534532.tif 000006
【図１Ｂ】
2014534532.tif 000007
【図２】
2014534532.tif 000008
【図３】
2014534532.tif 000009
【図４】
2014534532.tif 000010
【図５】
2014534532.tif 000011
【国際調査報告】
2014534532.tif 000012
2014534532.tif 000013