JP2014522513A - マルチサーバ予約システムにおける同期化メカニズムのための方法及びシステム - Google Patents

Abstract

本発明の好ましい実施形態による方法によれば、ＰＮＲ値をマルチサーバ（できればマルチプラットフォーム）システムのサーバの間で効率的で首尾一貫したメカニズムによって同期化することができる。本メカニズムは、そのバージョニング及びそのレイジー動作（同期化が必要なときにのみ生じる）によって一貫性問題及び性能問題に対処している。本メカニズムは、データを共有するアプリケーションの漸進的移行による一つのシステムから別のシステムへの移行相中の解決手段として使用できるとともに、異なるプラットフォーム間の分散アプリケーションに対する永久的な解決手段としても使用することができる。本発明の好ましい実施形態によれば、予約サービスが２つの異なるプラットフォーム（例えば、メインフレーム及びオープンプラットフォーム）に分散されると、それらはそれらのビジネス機能を実行するために読み出し及び書き込みモードにおいて同じ乗客予約記録（ＰＮＲ）コンテキストデータを共有する必要がある。本発明の好ましい実施形態の方法及びシステムは、読み出し及び書き込みモードにおいて異なるプラットフォーム間及び異なる通信プロトコル（例えばＴＰＦマインフレーム及びオープンシステム）間で共有されるデータ（例えばＰＮＲで）の同期化を可能にするため、これらのシステムは最新のＰＮＲコンテキストデータを共有することができる。
【選択図】図１

Description

本発明は、旅行予約システムの分野に関し、特に旅行予約を多数のサーバで分散コンテキスト同期化メカニズムを使って処理する方法及びシステムに関する。

最近の旅行社（例えば航空会社）は顧客の予約要求を処理するために通常高性能のアプリケーションを使用している。会社システム全体で２以上のアーキテクチャを使用するケースがますます増えている。このような場合には、予約システムを設計及び計画する際に互換性及び同期問題を考慮しなければならない。一例は、予約管理の一部分をインターネットベースのアプリケーション又は通信インフラストラクチャで実行する場合である。別の例は、システム（必ずしも予約システムに限らない）をレガシーメインフレーム（ＴＰＦ）から新しいシステム（例えばオープンシステム）に移行させなければならない場合である。後者の例、即ちアプリケーションを例えばＴＰＦメインフレームから例えばオープンシステムへ移行させる必要があるとき、我々はこれを「退役」という。予約システムのサービスの中断を避けるために、この移行は、既存のシステムを閉鎖し、新システムに１回の移行で切り替える（この場合にはあらゆる問題が起こりうる）代わりに、徐々に行うのが望ましい。旧及び新システム間の切り替え時におけるビッグな活性化プロシージャは複雑であるのに加えて、新システムが構築中であり且つ旧システムが進化しつづける間、我々は両プラットフォーム上のソフトウェアを２重にメインテナンスする必要があることも考えなければならない。もしかすると、新機能を開発しなければならず、これは２倍の労力を必要とするが、両システムが一緒に動作できれば、すべての開発労力を新プラットフォームに注ぐことができる。これらの理由のために、段階的移行の方がいわゆる「ビッグバン」移行戦略より好ましいが、いくつかの難点を考慮しなければならない。特に、予約サービスが２つの異なるプラットフォーム（メインフレーム及びオープンプラットフォーム）に分散されると、それらはそれらのビジネス機能を実行するために読み出し及び書き込みモードにおいて同じ乗客予約記録（ＰＮＲ）コンテキストデータを共有する必要がある。考慮すべき問題の１つは、異なるプラットフォーム間及び異なる通信プロトコル間（例えばＴＰＦメインフレームシステム及びオープンシステム間）で読み出し及び書き込みモードにおいて共有されるデータを、両システムが同じ最新のＰＮＲコンテキストデータを共有し得るように同期化させることにある。ここで、「コンテキスト」とは、アクティブ（エンド）ユーザのセッションにリンクされるショッピングセッションコンテキストを意味する。このコンテキストは、この特定のユーザに対して要求された機能を実行するためにシステムで使用されるすべての機能的及び技術的情報を表し、例えば旅行予約システムでは、アクティブエンドユーザセッションにリンクされる予約（ショッピング）セッションコンテキストである。

本発明の目的は、従来のシステムと関連する問題の少なくとも一部分を軽減することにある。

本発明の一つの態様によれば、マルチサーバシステム上で動作する予約方法において、ユーザトランザクション中に前記マルチサーバシステムの少なくとも２つのサーバ間で最新のＰＮＲ記録が使用されるようにする同期化メカニズム（方法）が提供される。この同期化メカニズムにおいて、前記ＰＮＲのローカルコンテキストバージョンが前記マルチサーバシステムの各サーバに維持され、前記サーバがルーティング手段を介して相互接続され、前記同期化メカニズムは、
前記マルチサーバシステムのすべてのサーバがアクセス可能な共通コンテキスト記憶領域に、ＰＮＲの最終変更バージョンに関する情報を維持するステップ、
ユーザリクエストに応答して、前記サーバのうちの選択されたサーバに、次の操作：
・ 前記共通コンテキスト記憶領域を、どのサーバが前記ＰＮＲを最後に変更したかについて検査する操作、
・ 前記ＰＮＲを最後に変更したサーバが前記選択されたサーバと異なる場合に、前記ＰＮＲの最新バージョンを取得する操作、
・ 前記ユーザリクエストを満たすために前記ＰＮＲのローカルコンテキストバージョンを変更する操作、
・ 前記共通コンテキスト記憶領域を前記ＰＮＲの最終変更バージョンを反映するように更新する操作を、
を実行させて、前記ＰＮＲのローカルコンテキストバージョンを変更するステップ、
を含むことを特徴とする。

本発明の好ましい実施形態による方法によれば、ＰＮＲ値をマルチサーバ（できればマルチプラットフォーム）システムのサーバの間で効率的で首尾一貫したメカニズムによって同期化することができる。本メカニズムは、そのバージョニング及びそのレイジー動作（同期化が必要なときにのみ生じる）によって一貫性問題及び性能問題に対処している。本メカニズムは、データを共有するアプリケーションの漸進的移行による一つのシステムから別のシステムへの移行相中の解決手段として使用できるとともに、異なるプラットフォーム間の分散アプリケーションに対する永久的な解決手段としても使用することができる。

本発明の第２の態様によれば、上述した方法を実行するように構成された１以上のコンポーネントを備えるシステムが提供される。

本発明のさらに他の実施形態によれば、コンピュータシステムで実行可能な、上述した方法を実行する命令を備えるコンピュータプログラムが提供される。

図面を参照して本発明をさらに例示的に説明する。

本発明の一実施形態によるイベントリシステムを示す図である。 本発明の好ましい実施形態で使用される分散コンテキストコリレータの可能な構造を概略的に示す。 異なるプラットフォームでのリクエスト処理を共有コンテキスト内の値の関連する変化とともにユースケースフォーマリズムで示す図である。 本発明の好ましい実施形態の方法をサポートするように構成された汎用コンピュータシステムの構成図である。 本発明の好ましい実施形態における、分散コンピュータ同期化の５つのサービスのうちの１つのＥＤＩＦＡＣＴ構造（ａ図）及びユースケースダイアグラム（ｂ図）を示す。 本発明の好ましい実施形態における、分散コンピュータ同期化の５つのサービスのうちの他の１つのＥＤＩＦＡＣＴ構造（ａ図）及びユースケースダイアグラム（ｂ図）を示す。 本発明の好ましい実施形態における、分散コンピュータ同期化の５つのサービスのうちの他の１つのＥＤＩＦＡＣＴ構造（ａ図）及びユースケースダイアグラム（ｂ図）を示す。 本発明の好ましい実施形態における、分散コンピュータ同期化の５つのサービスのうちの他の１つのＥＤＩＦＡＣＴ構造（ａ図）及びユースケースダイアグラム（ｂ図）を示す。 本発明の好ましい実施形態における、分散コンピュータ同期化の５つのサービスのうちの他の１つのＥＤＩＦＡＣＴ構造（ａ図）及びユースケースダイアグラム（ｂ図）を示す。 本発明の一実施形態による方法のプロセスステップを示すフローチャートである。

本開示は、予約システムの複雑なＴＰＦアーキテクチャをオープンシステムアーキテクチャへ移行する例に基づいている。上述した多くの理由のために、この移行は１回の移行で行うのは望ましくない。そのため、移行期間（数ヶ月から数年に及び得る）の間、予約システムはメインフレーム、例えばＩＢＭ社のＴＰＦ又はＭＶＳシステムと、オープンプラットフォーム、例えばＵｎｉｘ又はＬｉｎｕｘシステムとの間で分散される。この予約システムは、例えばアマデウスインフラストラクチャで実施することができる。しかしながら、本発明は異なるプラットフォームを有する多数のサーバ間で動作する予約システムの任意の実施に適用可能である。

メインフレームからオープンプラットフォームへの移行の例では、ＴＰＦメインフレーム上のＰＮＲアプリケーションはメモリ内に同じＰＮＲコンテキストを共有し、読み出し及び／又は書き込みモードにおいてＡＰＩを介してデータに直接アクセスすることができる。ＴＰＦの再設計及びＴＰＦメインフレームからのＰＮＲアプリケーションの移行のために、異なるプラットフォーム間でＰＮＲコンテキストを共有する問題が生じる。異種プラットフォーム間でユーザコンテキストを共有する単一システムのコンセプトは、異なるプラットフォームに分散されたアプリケーションが、異なるプラットフォーム間で実行されるビジネス機能操作の一貫性を確保するために、同じＰＮＲにアクセスできることを必要とする。

２つのアプリケーションを有する例が図１のブロック図に示され、１つのアプリケーションは他のアプリケーションにより提供されるＰＮＲ情報に依存する。この図は、ビジネス機能を実行可能にするためには両ローカルＰＮＲコンテキストを同期させなければならないことを示している。２つのアプリケーション（Ａｐｐ１及びＡｐｐ２）は予約システム内で協働し、Ａｐｐ１（一例では予約アプリケーション）はシステム１０１上で動作するが、Ａｐｐ２（例えば価額決定アプリケーション）はシステム１０３上で動作する。本例では、システム１０１はＴＰＦメインフレームであるが、システム１０３はオープンシステムであり、例えばＵｎｉｘシステムである。概して、２つのシステム１０１及び１０３は２つの異なるプラットフォームに関して任意の既知のシステムとすることができる。２つのシステム１０１及び１０３は、ユーザも端末１０７を介してアクセスすることができるエンタープライズサービスバス（ＥＳＢ）１０５により互いに接続される。端末１０７とＥＳＢ１０５との間の接続は、任意の適切なネットワーク配置（例えばＴＣＰ／ＩＰ）で実行できる。また、ＥＳＢは一つの実装例であり、他の既知の構造、例えばルータ、ポータル又はリクエストブローカを使用することもできる。各システム１０１及び１０３はＰＮＲ情報を維持するローカル記憶領域（それぞれ１０９及び１１１）にアクセスできる。ローカルＰＮＲ情報はローカルシステムに対して最新であるが、他のシステムに対して最新でないこともあり得る。本実施形態では、２つの異なるプラットフォームで動作する２つのシステム１０１及び１０３を有する例を使用するが、当業者であればいくつかの異なるシステムを備える他の実施が可能であることは認識されよう。図１の例では、ユーザは端末１０７及びＥＳＢ１０５を介して、ＰＮＲ１０９のローカルバージョンに作用するＡｐｐ１に予約を要求する（ステップ１）。ＰＮＲはＡｐｐ１により行われるエラボレーションに従って更新される（ステップ２）。制御がＡｐｐ２に移ると（ステップ３）、そのアプリケーションはＰＮＲ１１１のローカルバージョンに作用する（ステップ４）。その前にローカルＰＮＲが最新バージョンであるかどうか（本例では最新でない）を検証する必要があり、そうでなければ更新が必要である。Ａｐｐ２はそのエラボレーションを完了するために外部システム１１３（例えば価額決定データベース）にアクセスする。

本発明の好ましい実施形態による方法及びシステムにおいては、ＰＮＲコンテキストのローカルメモリ内コピーが各プラットフォームで複製され、更新がローカルに実行され、別のプラットフォームが最新コンテキストデータにアクセスする必要があるとき同期化が行われる。我々は、これを分散コンテキストの同期化と呼ぶ。同期化メカニズムの複雑さは、ローカルコピーが古いか古くないかを決定すること、及び最新のＰＮＲデータを得るためにそれがどこにあるのかを決定することにある。このメカニズムは、通信プロトコルが何であろうと、またプラットフォームの技術特性、例えばデータ表現（例えばビッグ又はリトルエンディアン）に依存することなく、あらゆるタイプのユーザクエリに対し働く。

本ＰＮＲコンテキスト同期化方法は、必要なときにのみ同期化が実行され、ローカルコンテキストのコピーについて更新が実行されるのみであるので、これらの要求のすべてに最適に答えることができる。本発明の重要な要素は、共有パラメータの最新の値をプロセス中の任意の時間に使用できるようにするメカニズムにある。本発明の好ましい実施形態による方法及びシステムでは、分散共有コンテキストコリレータを使用する。前記のアマデウス予約システムにおける一例では、これはＤＣＸ（Distributed context correlator）と呼ばれている。ＤＣＸは、異なるプラットフォーム及びアプリケーションに関する適用可能なコンテキストの分散を表すために、同じユーザセッションから到来する各メッセージに加えて追加の情報をあらゆるタイプの通信プロトコルで送付する。

このＤＣＸエンティティは生成され、ＥＳＢに格納され、アマデウスインフラストラクチャ内においてセッションヘッダにてあらゆるメッセージで送られる。図２は、本発明の好ましい実施形態によるＤＣＸ構造２００の一例を示す。ＤＣＸ構造は、異なるプラットフォームに関するコンテキストに対するリファレンスを含む。これは、コンテキストデータ自体は含まないことを意味する。ＤＣＸ構造はＸＭＬでフォーマット化され、図２に示すように３つの部分からなり、第１の部分はルーティング及び他のユースケースのために使用されるＥＳＢコンテキスト情報のための部分（２０１）であり、第２の部分はセキュリティ及びユーザ認証のための部分（２０３）であり、最後の第３の部分は応用可能部分（２０５）であり、この部分においてアプリケーションはそれらに関連するそれらのコンテキストリファレンス及びステータス標識を追加することができる。コンテキスト同期化プロセスが分散ＰＮＲコンテキストに関連する情報を記憶するのは応用可能部分においてであり、これがメカニズムの基礎をなし、これなしでは同期化プロセスは働かない。

ＤＣＸは同期化メカニズムに必要な他の２つの特徴を提供し、それらはアフィニティ及び異なる通信プロトコル間で共有するコンテキストである。アフィニティは同じサービスが呼び出される度に全く同じアプリケーションサーバを目標とするために必要とされ、ＰＮＲコンテキストがアプリケーションサーバに対してローカルであるとき必要とされる。アフィニティに関する情報はキーに含められ、これは「アフィニティキー」と呼ぶことができ、ＤＣＸに含められる。プロトコル間でのコンテキスト情報の共有は、異なるプロトコルでＰＮＲサービスを呼び出すユーザがなおも全く同じＰＮＲコンテキストで操作することを保証するために必要とされる。

コンテキストのライフタイム持続時間はＥＳＢとオープンシステム（又はメインフレーム）との間で確立された会話によって制御される。ＤＣＸはユーザアクティビティのグローバルビューを提供する。これは、ユーザが１つの特定の会話（例えばＥＤＩＦＡＣＴ会話）を通じて作業する場合、プロトコル間の一貫性を保証するために他のプロトコルの会話が維持されることを意味する。ユーザがＥＳＢから（会話の個別の終了又は不活性（時間切れ）によって）切り離すとき、オープンシステム及びメインフレームとの会話も終了され、コンテキストの一掃をトリガする。ＤＣＸの説明は本出願人が出願した本出願と同じ優先日を有する同時継続出願「Method and system for providing a session involving a plurality of software applications」及び「Method and system for providing a session in a heterogeneous environment」においても得られる。

本発明の実施形態においては、サーバ間の接続はＥＳＢによって実現されるが、当業者であれば、トランザクションを適切なアプリケーションサーバに送付し得る任意の他の最新の技術、例えばルータ、ポータル又はリクエストブローカを使用することができることは理解されよう。

分散コンテキスト同期メカニズムは、異なるプラットフォーム（マシン又はアプリケーションサーバとも称される）上でローカルコンテキスト状態に関する情報を格納するために、共有コンテキスト（ＤＣＸ）エンティティの応用可能部分を使用する。各プラットフォームは、そのローカルコンテキストを参照し、コンテキストの変化を伴う各トランザクションにおいてその状態を更新する必要がある。コンテキストに関連するデータは次のように構成される。

分散ＰＮＲコンテキスト同期化システムに含まれるすべてのプラットフォームは、ＤＣＸ内に同じアプリケーションタイプ（ここでは「ＳＢＲ」と名づけられている）で格納されたそれらのコンテキストキーを有する。
フィールド「Platform」はシステムを設計するために一般に使用される３字の頭文字、例えばＴＰＦ又はＲＥＳオープンシステム、に相当する。
フィールド「Context Version」は関連するプラットフォーム上に存在するコンテキストのバージョンに相当し、これはコンテキストが変更されるたびに増加する数である。
フィールド「Context Key」、適用可能コンテキストキーとも称される、は関連するプラットフォーム上でコンテキストの検索を可能にする一意の識別子に相当する。
フィールド「Context State」は関連するプラットフォーム上のコンテキストの状態に相当する。コンテキスト状態は、そのコンテキストがアクティブ、インアクティブ、破壊及び最後に更新されたコンテキストであることを表すことができる。

ＴＰＦ上で処理された１ユースケース後及び続くＲＥＳ ＯＢＥ（オープンバックエンド）上で処理された１ユースケース後におけるＤＣＸ内のアプリケーションキーの一例は下記のように表せる。
<Application = SBR>

<TPF, 1, Key1, ACT>

<RES, 1, Key2, ACT/Last>

</Applicatin>

ローカルコンテキストのバージョニングは、アルゴリズムに関する次のチャプタで示されるように、レイジー同期化メカニズム（必要のときにのみ実行される）を実行するための鍵である。「最終更新」の標識も、どのプラットフォームが最新のコンテキストを有するかを決定し、同期化をこのプラットフォームに対して行うための鍵である。

ＤＣＸエンティティ内ですべてのメッセージで送られる分散ＰＮＲコンテキストの現在状態に加えて、各プラットフォームはそのコンテキストに関連するローカル同期化状態を格納している。このローカル同期化状態は、最後に実行された同期化の時刻における他のプラットフォーム上の分散ＰＮＲコンテキストの状態を表す。これによりローカルコンテキストが他のプラットフォームと比較して時間遅れであることを決定することができ、これは同期化のトリガ条件である。いくつかの連続する更新が１つの正確なコンテキストについて行われた場合、そのローカルコンテキストが他のプラットフォームコンテキストに比較して最新であるとき、同期化はその都度行われない。

上述したデータ構造は可能な代替構造の一つであるが、同じ共有パラメータの異なるインスタンスの一貫性を保証するように他の実施形態を実現することもできる。このようなデータ構造の要件は、ＰＮＲの最新バージョンの位置に関する情報がシステムで使用されるすべてのプラットフォームにわたってすべてのアプリケーション間で共有されることにある。

図３に示すように、同期化部分に対する共有コンテキスト（本例ではＤＣＸ）内の適用可能キーについて行われる変更の全体的な流れが、システム１及びシステム２と呼ぶ２つのプラットフォーム（例えば１つはメインフレームで、他の１つはオープンシステムで動作する）を例にとって説明される。図３のダイアグラムにおいて、共有コンテキスト内の関連する値の変化を有する異なるプラットフォーム上でのユースケースの処理が記載されている。共有コンテキストで送られる現在状態及び異なるプラットフォームのローカル同期化状態が、それらの状態の間の相違を示すためにダイアグラムに示されている。

第１のステップ（図３のステップ１）において、ユーザはＥＳＢを介してシステムにログインする。この段階において、空の共有コンテキストがこのユーザのセッションに対して生成され、ＥＳＢに保存される（ステップ２）。

次に、ユーザは作業を開始し、システム１上に位置するサービスにより処理されるビジネスクエリを送信する（ステップ３）。ＥＳＢは自動的に共有コンテキストをユーザクエリとともにシステム１に送る。システム１は同期情報をローカルコンテキスト内にも共有コンテキスト内にも発見しないので、システム１は受信したユーザクエリを直接処理する（ステップ４）。このクエリの処理により予約コンテキストが生成された場合には、ローカル同期化データが、システム１がバージョン１の予約コンテキストを獲得したこと及びこのコンテキストが最終更新であることを示す新しい状態で更新される（ステップ５）。次にビジネスリプライが同期化データで更新された共有コンテキストと一緒にユーザに返送される。共有コンテキストは、ユーザにより実行される次のクエリで使用できるように、ユーザへのリプライの転送前にＥＳＢに保存される（ステップ６）。その後、ユーザはシステム２上に位置するサービスで処理される別のビジネスクエリを送る（ステップ７）。ＥＣＢは自動的に共有コンテキストをユーザクエリとともにシステム２に送る。システム２上にはローカル同期化状態は保存されておらず、クエリとともに受信された共有コンテキスト内に存在する同期化データとの比較は、システム１が新しい予約コンテキストを保持するので、システム１との同期化が必要であること示す（ステップ８）。従って、システム２はシステム１に、その予約コンテキストをローカルに保存することを要求し（ステップ９）、ユーザクエリの処理を許可する（ステップ１０）。予約コンテキストの保存と一緒に、ローカル同期化状態がその状態を表す異なる適用可能キーで初期化される。次に、クエリの処理が行われ（ステップ１１）、それが終了すると、予約コンテキストが更新された場合に、ローカル同期化が、システム２は現在予約情報の最終更新であること及びそのコンテキストは現在バージョン１であることを表すために更新される（ステップ１２）。ビジネスリプライが同期化データで更新された共有コンテキストと一緒にユーザに返送され、この共有コンテキストは、ユーザにより実行される次のクエリで使用できるように、ユーザへのリプライの転送前にＥＳＢに保存される（ステップ１３）。ユーザからの後続のクエリに対して、上記と同じシーケンス動作がシステム１又はシステム２を目標にして独立に続けられる。ローカル同期化状態と共有コンテキストの比較に応じて、システムは同期化が必要か否かを決定する。

例えば、システム１のプラットフォーム上で、予約コンテキスト（例えばＰＮＲ）を使ってサービスを読み出し又は書き込みモードで呼び出すとき、別のシステムとの同期化が必要か否かを決定するために次のアルゴリズムが適用される。

０−リクエストを受信する
１-ユーザリクエストに基づいて受信した現在の共有コンテキスト内のアプリケーションキーを取得する（例えばSystem1 v1 / System2 v2 Last）
２-ローカルに格納された前同期化状態を取得する（例えばSystem1 v1 / System2 v1 Last）
３-一貫性検査の実行：
３ａ-現在のシステム１のバージョンはローカル保存の前バージョンと同じか？ キーは同じか？（イエスの場合ＯＫ）
３ｂ-現在のシステム２のバージョンはローカル保存の前バージョン以上か？（イエスの場合ＯＫ）
４-同期化検査の実行：現在のシステム２のバージョンはローカル保存のバージョンより大きいか？及び「最終更新」フラグが存在するか？（イエスの場合、同期化が必要）
５-同期化が必要な場合、
５ａ-同期化を実行する（システム２のプラットフォームからコンテキストを取得する）
５ｂ-成功の場合、システム１はローカル保存の同期化状態を値：System1 v1 / Sytem2 v2：で更新する（これは現在システム１上でコンテキストがシステム２のバージョン２と同期化されたことを意味する）
６-ビジネスクエリをシステム１で処理する
７-予約（ＰＮＲ）コンテキストに変更が行われた場合、システム１のバージョンを更新する
７ａ-現在の共有コンテキスト内のシステム１のバージョンを更新する（System1 v2 Last / System2 v2）。この共有コンテキストは次のユーザクエリのために保存するためにＥＳＢに返送される
７ｂ-ローカル保存の前同期化状態にあるシステム１のバージョンを値：System1 v2 / System2 v2：で更新する。
８-回答

このアルゴリズムでは、同期化の観点から何をすべきかを決定可能にするためには２組のコンテキストキーを比較する必要がある。３以上のプラットフォームがＰＮＲコンテキストを有するとき、コンテキストの最新バージョンを有するプラットフォームを決定するためには「最終更新」フラグが必要とされる。２つのプラットフォームに対して、このメカニズムはこのフラグなしで動作する。

このメカニズムの１つの追加の利点は、共有コンテキスト送信エラーを次の同期フェーズで検出できる点にある。一貫性検査及びローカル保存同期情報のおかげで、エラーが発生した場合、それを決定できる。ローカルプラットフォームのバージョンが一致しない又はコンテキストキーが異なることは共有コンテキストの内容の破壊を示し、これはエラーの結果である可能性が高い。エラー処理は通信及びコラテラル交換のために極めて複雑になり得るため、ここでは詳述しないが、当業者であれば、このタスクを実施するためにいくつかの最新の技法を使用できることが理解されよう。

図４を参照すると、システムの汎用コンピュータ（例えば、任意のコンピュータ、予約サーバ、ＴＰＦメインフレーム、オープンシステムサーバ、データベースマネジメントサブシステム、ルータ、ネットワークサーバ）は４５０で示されている。コンピュータ４５０はシステムバス４５３に並列に接続された幾つかの装置からなる。詳細には、１つ以上のマイクロプロセッサ４５６はコンピュータ４５０の動作を制御し、ＲＡＭ４５９はマイクロプロセッサ４５６により作業メモリとして直接使用され、ＲＯＭ４６２はコンピュータ４５０のブートストラップ用の基本コードを格納する。周辺装置はローカルバス４６５の周囲に（それぞれのインタフェースによって）集合配置される。具体的には、大容量メモリはハードディスク４６８及びＣＤ−ＲＯＭ４７４を読み出すドライブ４７１からなる。さらに、コンピュータ４５０は入力装置４７７（例えばキーボード及びマウス)及び出力装置４８０（例えば、モニタ及びプリンタ）を含む。ネットワークインタフェースカード４８３はコンピュータ４５０をネットワークに接続するために使用される。ブリッジ装置４８６はシステムバス４５３をローカルバス４６５とインタフェース接続する。各マイクロプロセッサ４５６及びブリッジ装置４８６は、情報を送信するためにシステムバス４５３へのアクセスを要求するマスタエージェントとして動作することができる。アービタ４８９はシステムバス４５３へのアクセスの許可を相互排除式に管理する。システムが異なるトポロジーを有する場合又は他のネットワークに基づく場合にも同様の考察が適用される。また、コンピュータは異なる構造を有し、等価な装置を含み、また他のデータ処理エンティティ（例えばＰＤＡ、携帯電話等）からなるものとすることもできる。

ＰＮＲコンテキスト同期化メカニズムで使用され、ＰＮＲデータを送るＥＤＩＦＡＣＴサービスは以下の情報で構成される。
・ＰＮＲコンテキストデータを要求する又は提供するプラットフォームのローカル同期化状態。この情報はローカルコンテキストについて検索し適用しなければならないユーザトランザクションの数を決定するために必要とされる。この情報はプラットフォーム間で交換されるデータの量を低減する最適化も可能にする。
・シリアライズされたＰＮＲコンテキスト。このＰＮＲコンテキストは、最初の同期化の場合は完成とすることができ、またコンテキストの最新バージョンを要求するプラットフォームが既にローカルコンテキストコピーを持っているときはコンテキスト更新で完成させることができる。シリアライズされたコンテキストはＰＡＳＢＣＱであり、ＥＤＩメッセージ自体である。

コンテキストをＥＤＩメッセージにシリアライズすることによりコンテキストを提供するプラットフォームのデータ表現の特殊性を取り除くことが可能になる。実際には、データ内容が標準化され、プラットフォームのデータ表現と無関係になる。

分散コンテキスト同期化は、ＴＰＦ及びＯＢＥの両プラットフォームで実施できる又はマスタ／スレーブプラットフォームに特有の５つの異なるサービスに基づいている。

ＤＣＸは一貫性検査をコンテキスト同期化の状態で実行可能にするために、各サービスはＤＣＸをメッセージと一緒に送付する。各サービスはＥＤＩＦＡＣＴ構造（リクエスト及びレスポンス）及びシュー交換データ(shoe exchanged data)に対するユースケースを参照してここで説明される。

コンテキストの取得：ＰＣＳＧＲＱ／Ｒ
図５ａ及び５ｂに示すこのサービスは、リモートプラットフォームからそのコンテキストの最新バージョンを検索するために使用される。このサービスは、コンテキストを読み取り可能なすべてのプラットフォーム上で実施する必要がある。

データの交換
クエリに応じて、クライアントはその同期化状態を与える必要がある。この同期化状態は<Platform, Context Key, Version>の３つの値のリストからなる。
リプライに応じて、サーバはそのバージョンとともにシリアライズされたコンテキストに関連するその同期化状態を与える必要がある。

コンテキストシリアライゼーションバージョンの取得：ＰＣＳＶＲＱ／Ｒ
図６ａ及び６ｂに示すこのサービスは、コンテキストのシリアル化に関連するすべてのバージョンを検索するために使用される。このサービスはＯＢＥ上で実行される。ＯＢＥ上で、コンテキストはＳＢＲモデルに基づき、ＰＡＳＢＣＱというＥＤＩＦＡＣＴメッセージにシリアライズされる。ＰＡＳＢＣＱは関連するバージョンを有するいくつかのブロブからなる。ＴＰＦはＰＡＳＢＣＱのバージョンのマスタであるので、ＯＢＥは、それらを前から知らないときは、首尾一貫したメッセージを書き込むためにＴＰＦから現在のシリアルライゼーションバージョンを検索しなければならない。この状態は外部システムが勝手な更新をＯＢＥに直接要求するときに起こる。

データの交換
クエリに応じて、クライアントは何のデータも提供する必要はない。
リプライに応じて、サーバはＰＡＳＢＣＱというＥＤＩＦＡＣＴメッセージをシリアライズするために使用されるそのバージョンを与える。そのバージョンはシリアル化に使用されるすべてのバージョンをブロブバージョンと一緒に含むブロブで構成されなければならない。エラーに遭遇しうるので、リプライには問題を記述するエラーグループを含めるべきである。

コンテキストの転送：ＰＣＳＰＵＱ／Ｒ
このサービス（図７ａ及び７ｂ）は、リモートプラットフォーム上のコンテキストを更新するためにローカルコンテキストの最新バージョンをリモートプラットフォームに転送するために使用される。このサービスは、コンテキストのマスタでないプラットフォームで実行されなければならない。このサービスはコンテキストのマスタを最新にする同期化メカニズムの最適化である。コンテキストの場合には、マスタはコンテキスト取得サービスを使用しない。ＴＰＦ上でのクライアントコールはコストがかかるので、これはリソース消費を低減するのに役立てることができる。

データの交換
クエリに応じて、クライアントはシリアライズされたコンテキストに関連するその同期状態にそのバージョンを付与しなければならない。
リプライに応じて、サーバは肯定応答するだけでよい。エラーに遭遇しうるので、リプライには問題を記述するエラーグループを含めるべきである。

コンテキストの転送及びＥＯＴ：ＰＣＳＥＵＱＲ／Ｒ
このサービス（図８ａ及び８ｂ）は、リモートプラットフォーム上のコンテキストを更新するためにローカルコンテキストの最新バージョンをリモートプラットフォームに転送するとともに、このコンテキストに関するトランザクションプロセスの終了（ＥＴＯ）を呼び出すために使用される。このサービスは、ＰＮＲコンテキストを更新するとともにそれらの変更に関するトランザクションプロセスの終了を呼び出す必要があるすべてのプラットフォームで実行しなければならない。このサービスは、チケットプリントリクエスト（ＴＴＰ）又は外部システムからのチケット肯定応答などの処理エントリを管理するために必要とされる。

データの交換
クエリに応じて、クライアントはシリアライズされたコンテキストに関連するその同期化状態にそのバージョンを付与しなければならない。
リプライに応じて、サーバは肯定応答するだけでよい。エラーに遭遇しうるので、リプライには問題を記述するエラーグループを含めるべきである。

コンテキスト伝播の無視：ＰＣＳＩＮＱ／Ｒ
このサービスは、フローに含まれる異なるプラットフォームにまたがってＳＢＲ上で行われるすべての変更を無視するために使用される。ＴＰＦは「ＩＧ」エントリを受信すると、ＤＣＸに登録されたＳＢＲコンテキストを有するＯＢＥに伝播するため、ＯＢＥはそれらのコンテキストを一掃することができる。これは図９ａ及び９ｂに示されている。

データの交換
クエリに応じて、クライアントはシリアライズされたコンテキストに関連するその同期化状態にそのバージョンを付与しなければならない。
リプライに応じて、サーバは肯定応答するだけでよい。エラーに遭遇しうるので、リプライには問題を記述するエラーグループを含めるべきである。

上述した方法は図１０に示す流れ図で表すことができる。本方法は、マルチサーバシステム上で動作する予約方法において、ユーザトランザクション中に前記マルチサーバシステムの少なくとも２つのサーバ間で最新のＰＮＲ記録が使用されるようにする同期化メカニズムを実現する。このメカニズムにおいて、前記ＰＮＲのローカルコンテキストバージョンが前記マルチサーバシステムの各サーバに維持され、前記サーバがシステムバスを介して相互接続されている。本方法は、黒丸１００１で開始し、次にボックス１００３に進み、トランザクションに含まれるすべてのサーバがアクセスし得る記憶領域にＰＮＲの最新バージョンが維持される。ＰＮＲの更新操作を必要とするユーザリクエストがマルチサーバ予約システムにより、例えばサーバ「Ａ」で受信される（ステップ１００５）。システムバス（概して任意のルーティング手段、例えばＥＳＢ）がリクエストを処理するためにどのサーバが必要とされるか決定し選択する。ステップ１００７及び１００９において、選択されたサーバはローカルコンテキストＰＮＲをＥＳＢ上の共有コンテキストＰＮＲで入手しうる情報と比較することによってそれが最新であるかどうかを検査し、ローカルコンテキストＰＮＲが最新でない場合（即ち、選択されたサーバによる最後の更新後に別のサーバによるそのＰＮＲの変更がある場合）、選択されたサーバはＰＮＲの最新バージョンを取得する（ステップ１０１１）。その後、選択されたサーバは要求されたアクティビティを実行し、ローカルコンテキストＰＮＲを変更し（ステップ１０１３）、このコンテキストも最新バージョンとなり、このような情報はその後ＥＳＢ上の共有コンテキストＰＮＲに送られ、マルチサーバシステムのすべての他のサーバに利用可能にされる（ステップ１０１５）。情報をサーバ、ＥＳＢ及びユーザ間で伝送する方法の詳細は前項で説明されている。

以上の方法及びメカニズムは開示の範囲から逸脱することなく多くの変更及び修正が可能であることは理解されよう。当然のことながら、当業者であれば、部分的用件及び特定の要件を満たすために、上述した解決手段に多くの変更及び修正を加えることができる。特に、本開示は好ましい実施形態を参照してある程度入念に記載されているが、形態及び細部において様々な省略、置換及び変更が可能であるのみならず、他の実施形態も可能であることも理解されたい。さらに、開示の任意の実施形態と関連して記載されている特定の要素及び／又は方法のステップは任意の他の実施形態において一般的な設計選択事項として組み込むことができることが明確に意図されている。

同様の考えが（開示の各実施形態を実施するために使用できる）プログラム
が異なる方法で構成される場合、又は追加のモジュール又は機能が提供される場合にも当てはまる。同様に、メモリ構造は他のタイプのものにすることも、同等のエンティティ（必ずしも物理的な記憶媒体からなるものである必要はない）と置き換えることもできる。さらに、提案の解決法は（同様の又は追加のステップを異なる順序で有する）同等の方法で実施するのに適している。いずれの場合にも、プログラムは、外部又は常駐ソフトウェア、ファームウェア又はマイクロコード（オブジェクトコード又はソースコードのいずれか）等の任意のデータ処理システムにより又は関連して使用されるのに適したに似の形をとることができる。さらに、プログラムは任意のコンピュータ利用可能媒体に設けることができ、この媒体はプログラムを収容、記憶、通信、配布、又は転送するのに適した要素とすることができる。このような媒体の例には、固定ディスク（プログラムをプリロードできる）、リムーバブルディスク、テープ、カード、ワイヤ、ファイバ、無線接続、ネットワーク、放送波などがあり、例えばこの媒体は電子タイプ、磁気タイプ、光学タイプ、電磁気タイプ、赤外タイプ又は半導体タイプとすることができる。

いずれにせよ、本発明による解決方法はハードウェア構造（例えば半導体材料のチップに集積化されている）で実施する又はソフトウェアとハードウェアの組み合わせで実施するのに適している。

Claims (10)

1. マルチサーバシステム上で動作する予約方法において、ユーザトランザクション中に前記マルチサーバシステムの少なくとも２つのサーバ間で最新のＰＮＲ記録が使用されるようにする同期化メカニズムにおいて、前記ＰＮＲのローカルコンテキストバージョンが前記マルチサーバシステムの各サーバに維持され、前記サーバがルーティング手段を介して相互接続され、前記同期化メカニズムは、
   前記マルチサーバシステムのすべてのサーバがアクセス可能な共通コンテキスト記憶領域に、ＰＮＲの最終変更バージョンに関する情報を維持するステップ、
   ユーザリクエストに応答して、前記サーバのうちの選択されたサーバに、次の操作：
   ・ 前記共通コンテキスト記憶領域を、どのサーバが前記ＰＮＲを最後に変更したかについて検査する操作、
   ・ 前記ＰＮＲを最後に変更したサーバが前記選択されたサーバと異なる場合に、前記ＰＮＲの最新バージョンを取得する操作、
   ・ 前記ユーザリクエストを満たすために前記ＰＮＲのローカルコンテキストバージョンを変更する操作、
   ・ 前記共通コンテキスト記憶領域を前記ＰＮＲの最終変更バージョンを反映するように更新する操作、
   を実行させることによって前記ＰＮＲのローカルコンテキストバージョンを変更するステップ、
   を含むことを特徴とする、同期化メカニズム。
2. 前記マルチサーバシステムの前記サーバは、サービス指向アーキテクチャ（ＳＯＡ）システムによって前記ルーティング手段及びユーザとメッセージを交換する、請求項１記載の同期化メカニズム。
3. 前記メッセージは前記ＰＮＲの最終変更バージョンに関する情報を含むメッセージヘッダを含む、請求項２記載の同期化メカニズム。
4. 前記ＰＮＲの最終変更バージョンに関する情報は前記ＰＮＲの最終変更バージョンの位置を含む、請求項１−３のいずれかに記載の同期化メカニズム。
5. 前記ＰＮＲの最終変更バージョンに関する情報は前記ＰＮＲの最終変更バージョンへのポインタを含む、請求項１−４のいずれかに記載の同期化メカニズム。
6. 前記ルーティング手段はシステムバス、例えばエンタープライズサービスバス（ＥＳＢ）を含む、請求項１−５のいずれかに記載の同期化メカニズム。
7. コンピュータ上で実行される、請求項１−6のいずれかに記載の方法のステップを実行する命令を備える、コンピュータプログラム。
8. 請求項７に記載のコンピュータプログラムを具体化したコンピュータ読み取り可能な手段を含むコンピュータプログラム製品。
9. ユーザトランザクション中にマルチサーバシステムの少なくとも２つのサーバ間で最新のＰＮＲ記録が使用されるようにする同期化メカニズムを含み、前記ＰＮＲのローカルコンテキストバージョンが前記マルチサーバシステムの各サーバに維持され、前記サーバがルーティング手段を介して相互接続され、請求項１−６のいずれかに記載の方法を実行するように構成された１以上のコンポーネントを備える、予約マルチサーバデータ処理システム。
10. 請求項１−６のいずれかに記載の方法を実施するデータ処理システムに配備されるサービス。

Images