JP5931934B2 - マルチサーバー予約システムにおける集中型予約コンテキスト管理のための方法及びシステム - Google Patents

Description

本発明は、旅行予約システムの分野、特に、予約サービスインタセプタアーキテクチャを用いたマルチサーバーにおける集中型予約コンテキスト管理のための方法及びシステムに関する。

現代における（例えば航空会社のような）旅行会社は、通常顧客からの予約依頼を処理するために高度なアプリケーションを用いている。その会社のシステムを通じて１つ以上のアーキテクチャが使用されるケースがますます多くなっている。そのようなケースにおいては、予約システムを設計し計画する際に互換性及び同期の問題を考慮に入れる必要がある。その一例は、予約管理の一部がインターネットをベースにしたアプリケーション又は通信インフラストラクチャ上で実行されている場合である。他の例は、システム（必ずしも予約システムではない）をレガシーメインフレームシステム（例えば、ＴＰＦ）から新しいシステム（例えばオープンシステム）に移行しなければならない場合である。予約システムにおけるサービスの中断を回避するために、この移行は、ある単一の動作で既存のシステムを閉鎖し新しいシステムに切り換える代わりに、漸次実行するのが望ましいが、それは旧システムと新システムとの切り換え時の巨大なアクティブ化処理の複雑さに加えて、新しいシステムが構築中であり古いシステムが進化し続けている間は、両システムにおけるソフトウエアの二重のメンテナンスの必要性もまた考慮すべきであるといった、起こりうる全ての問題に対処するためである。恐らく、新たな機能性を開発する必要があり、これには二重の手間がかかるが、２つのシステムが一緒に稼動出来るのであれば、全ての開発努力を新しいプラットフォームに注ぐことができる。これらの理由により、いわゆる「ビッグバン」移行ストラテジーよりは漸次移行が好ましいが、いくつかの困難を考慮する必要がある。特に、予約サービスが２つの異なるプラットフォーム（例えばメインフレームとオープンプラットフォーム）間に分散される時には、これらのプラットフォームは、ビジネス機能を達成するために、読み出し及び書き込みモードにおいて同一の乗客名記録(Passenger Name Record(ＰＮＲ))コンテキストデータを共有する必要がある。

考慮すべき問題の１つは、異なるサーバー及びプラットフォーム間、並びに通信プロトコル（例えばＴＰＦメインフレーム及びオープンシステム）間にて、それぞれのシステムが同一の最新のＰＮＲコンテキストデータを共有することができるように読み出し及び書き込みモードにおいて共有されるデータ（例えばＰＮＲデータ）の同期をとることである。本出願と同一の出願人であり、同じ優先日を有する同時係属中の「マルチサーバー予約システムにおける同期メカニズムのための方法とシステム」は、マルチサーバー（又はプラットフォーム）間の同期の問題に対処している。その出願に開示されている方法は、効率的で、一貫性のあるメカニズムによってマルチプラットフォームシステム間におけるＰＮＲ値の同期をとることができる。このメカニズムは、そのバージョニング及びそのレイジー動作により一貫性とパフォーマンスの問題に対処している（同期は必要とされる際にのみ発生する）。そのメカニズムは、１つのシステムから他のシステムへの移行段階中に、データを共有するアプリケーションの漸次移行のためのソリューションとして、及び異なるプラットフォーム間に分散されたアプリケーションのための恒久的なソリューションとしても使用することができる。

同期は、必要なときにのみ実行され、ローカルコンテキストのコピーになすべき更新のみが提供される。上述の方法の鍵となる要素は、共有パラメータの最新の値がプロセス期間中いつでも用いられることを保証するメカニズムである。上記発明による方法及びシステムにおいては、分散型の共有コンテキストコリレータが用いられる。これは、ＤＣＸ（分散型コンテキストコリレータ）（Distributed context correlator）と呼ばれる。ＤＣＸは、マシーン又はアプリケーションサーバーとも呼ばれ、異なるプラットフォーム及びアプリケーション上の適用可能なコンテキストの分布を表すために、あらゆるタイプの通信プロトコルで、同一のユーザセッションから来る各メッセージの先頭に追加の情報を伝送する。

このＤＣＸエンティティは、様々なサーバーを接続するエンタープライズサービスバス(ＥＳＢ)上に生成されて格納され、且つセッションヘッダにおけるアマデウス(Amadeus)インフラストラクチャ内の全てのメッセージに伝えられる。それは、異なるプラットフォーム上のコンテキストに対する参照を含むのであって、コンテキストデータそのものを含むのではない。それは、ＸＭＬにフォーマット化され、３つの部分で構成される。その１つは、経路指定及び他のユースケースのために用いるＥＳＢコンテキスト情報のために確保され、もう１つの部分はセキュリティ及びユーザ認証専用であり、最後の第３の部分は、アプリケーションがそれらに関連するコンテキスト参照及び状態指標を付加できる適用可能部である。この適用可能部では、コンテキスト同期処理が分散されたＰＮＲコンテキストに関連した情報を格納し、それがこのメカニズムの基本である。

ＤＣＸは、異なる通信プロトコル間のアフィニティ及びコンテキストの共有と云った同期メカニズムに必要とされる他の２つの機能を提供する。アフィニティは、同じサービスが呼び出されるたびに、全く同じアプリケーションサーバーを対象としなければならず、これはアプリケーションサーバーに対してＰＮＲコンテキストはローカルであるから必要である。好適には、アフィニティに関する情報は、”Ａｆｆｉｎｉｔｙ Ｋｅｙｓ”と称されるキー内に含まれ、そのキーはＤＣＸ内に包括される。プロトコル間のコンテキスト情報の共有は、異なるプロトコル上でＰＮＲサービスを呼び出しているユーザが全く同じＰＮＲコンテキスト上で作業し続けるようにするために必要である。

コンテキストの寿命期間は、ＥＳＢとオープンシステム（又はメインフレーム）との間でなされる会話により制御される。ＤＣＸは、ユーザがある特定の会話（例えばＥＤＩＦＡＣＴ会話）を通じて作業する場合に、その他のプロトコルによる会話がプロトコル間の一貫性を保証するように維持されることを意味する、グローバルな観点でのユーザアクティビティを提供する。ユーザがＥＳＢとの接続を切ると（ある特定の終了する旨の会話又は非活動による中断による）、オープンシステム及びメインフレームとの会話もまた終了し、コンテキストのクリーンアップをトリガーする。ＤＣＸについての説明は、本出願と同一の出願人により出願され、同じ優先日を有する、同時係属出願である、「複数のソフトウエアアプリケーションを含むセッションを提供する方法並びにシステム」及び「異種の環境におけるセッションを提供する方法並びにシステム」においても成されている。

ＤＣＸに基づく同期メカニズムは、マルチプラットフォーム間にシステムを実装している際、場合によっては、例えば情報を高度に分散されたオープンバックエンドプラットフォーム内で処理してやり取りする際に、予約データを共有する観点では非常に有利である一方、コンテキスト処理を改善し得る予約データの集中処理の方がより一層望ましい。高度に分散された環境においては、同期メカニズムは、全てのサーバーが危険にさらされ（全てのサーバーは予約データをメモリにローカルに格納しているため）、且つ全てのサーバーは他のサーバーからデータを取得しなければならず、これはシステムのパフォーマンスに影響を及ぼすことになる。

本発明の目的は、従来のシステムに関連する問題のいくつかを軽減し、同じ分散環境内で情報を処理して、交換する際におけるＰＮＲデータの改善された処理方法を提供することである。

本発明の第１の態様によれば、複数のオープンバックエンドサーバー（ＯＢＥ）を有する分散型予約システム上で動作する予約方法であって、各ＯＢＥは、少なくとも２つのＯＢＥ間のユーザトランザクション中にＰＮＲ記録の一貫性を制御するためにサービスを提供するように適合され、前記方法は、予約インタセプタモジュールが少なくとも１つのサービスとＰＮＲ記録への参照のための要求を含むデータ構造を有するユーザ要求を受信するステップと、前記予約インタセプタモジュールが前記ＰＮＲ記録の内容を含む情報により前記データ構造を充実させるステップと、前記予約インタセプタモジュールが、前記ユーザ要求で要求された前記少なくとも１つのサービスに従って第１の少なくとも１つのＯＢＥに前記充実させたデータ構造を転送するステップと、前記充実させたデータ構造の最新バージョンを返送する前記第１の少なくとも１つのＯＢＥに応答して、前記予約インタセプタモジュールが、前記ユーザ要求に含まれる全ての要求されたサービスが提供されるまで、前記充実させたデータ構造を他のＯＢＥに順番に転送するステップと、前記ユーザによって要求された少なくとも１つのサービスに関連した応答を返送するステップとを含む。

本発明の好適な実施形態による方法は、ＰＮＲ記録が予約インタセプタモジュールにより制御され、複数のＯＢＥを含むサブシステム内で処理される際に、ＰＮＲ記録の一貫性を保証できるようにする。またシステムのセキュリティの改善も得られる。本発明の方法によれば、中枢の予約データを所持しているサーバーを（例えばバックアップにより）保護するだけでよく、ユーザの要求を処理するために予約データを必要とする別のサーバーは、クエリ内に組み込まれたこれらのデータにシームレスにアクセス可能であるため、追加の副次的な情報の交換は不要となる。

本発明の第２の態様によれば、上述の方法を実行するのに適した１つ以上のコンポーネントを有する予約サブシステムが提供される。

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

添付図面への参照を例示により記載する。

本発明の実施形態によるシステムのブロック図である。 本発明の他の実施形態によるシステムのブロック図である。 本発明の好適な実施形態の方法をサポートするのに適した一般的なコンピュータシステムのブロック図である。 本発明の一実施形態による、方法ステップのフローチャートである。

図１に示すように、オープンシステム上のＰＮＲコンテキストは、全てのコンテキスト部分を集めることがパフォーマンス問題を招くので、分散型環境でのコンテキストの断片化を回避するために集中化させる。更に、ＰＮＲコンテキストに係るトランザクションの開始、中間の更新、及び最後のコミット又はロールバックを処理するためにトランザクションセッションプロトコルを実装する代わりに、サービスインタセプタアーキテクチャの原理は、機能的なユースケースの全てが終了した応答時にのみ、ＰＮＲコンテキストの中央レポジトリにて変更されるであろう現在のユーザのＰＮＲコンテキストに機能的なクエリを委譲することである。そのような集中化は、全ての予約サーバーの間で共有される予約データのみに限定され、ＰＮＲコンテキストは、持続性のデータ構造ではない、ＧＣＸ（汎用コンテキストコンテナ）(Generic Context Container)と呼ばれるエンティティに伝送される。いったんユーザ応答が提供されたら、ＧＣＸをもはや維持する必要は無い。図１は、本発明の好適な実施形態によるシステムの可能な実装を示している。機能的なコンポーネントがデータ構造（ＤＣＸ及びＧＣＸ）と一緒に示されている。ユーザによる可能なサービス要求の通信ステップは、図に数字１〜８で示されている。この例は、アマデウスインフラストラクチャ、例えばアマデウス予約サービスインタセプタ(Amadeus Reservation Service Interceptor)により構築される。ユーザ１０１は、例えば図１につき説明したようにコンピュータにより予約システムに接続される。読み出し又は書き込みモードにおいてユーザＰＮＲコンテキストへのアクセスが必要なサービスの全ての機能的なクエリは、予約サービスインタセプタＯＢＥ１０５（予約インタセプタとも呼ばれる）を経由し、これらのクエリがＰＮＲコンテキストデータを含むＧＣＸエンティティで充実されるようにしなければならない。そして、ビジネス要求を達成するために、クエリは実際の機能的なサービスに委譲される。コンテキスト更新は、機能的な応答で伝えられるＧＣＸにおける機能的なサービスによって提供される。応答は、再び予約サービスインタセプタを経由し、これは更新コンテキストをユーザのＰＮＲコンテキストに統合し、ＧＣＸを削除し、機能的な応答をユーザに転送する。このアーキテクチャでは、２種類のＩＳＡＰ（Integration Service Access Points）が使用され、それらは、外部ユーザ用外部ＩＳＡＰ１０３と他のサービスを呼び出す内部サービス及び内部アプリケーション用の内部ＩＳＡＰ１０７である。ＩＳＡＰはユーザ又はアプリケーションが、必ずしもサービストポロジの詳細を知らなくてもサービスを目標とすることができるＥＳＢのエンティティである。本例で述べた実施形態によれば、ＤＣＸエンティティは、外部ユーザが接続される外部ＩＳＡＰ１０３にて生成され格納される。それはユーザクエリの先頭に付加され、アマデウスインフラストラクチャ内の全てのメッセージに伝えられる。ＤＣＸ及びＧＣＸエンティティのどちらも、クエリ及び応答におけるそのようなエンティティを通すも、それらをコンテキストには格納しない内部ＩＳＡＰを通過可能である。

機能的なサービスは、最初にそれらのサービスを予約サービスインタセプタに通すために、予約サービスインタセプタのルートを用いて外部ＩＳＡＰ上に公開される。同じ機能的なサービスは、機能的なオープンシステムへの実際のルートを用いて、予約サービスインタセプタの後方にある固有の内部ＩＳＡＰ上でも公開されて、ビジネス要求を処理することができる。このように、ルーティングは、ＰＮＲコンテキストの付加又は削除のみを行うサービスインタセプタ内のルーティングロジックを二重にすること無く、ＥＳＢによって対処される。ＤＣＸ及びＧＣＸエンティティは、プロトコルレベルにあるので、機能的なクライアントアプリケーションは通信ミドルウエアによって自動的に削除されて、脇へ保持されるこれらのエンティティを見ることはない。コンテキストがローカルに格納されていたかのように、ＧＣＸからＰＮＲデータにアクセスするために、委譲インターフェースが機能的なクライアントアプリケーションに伝えられる。機能的なサービスインターフェースはＤＣＸ又はＧＣＸの影響は受けないが、これは、それらがメッセージ文法の一部ではないからである。そのような場合には、コンテキストを得るためにクエリを送信する必要が無いため、サーバーアプリケーションにとってユーザＰＮＲコンテキストへのアクセスはシームレスである。

応答では、機能的サーバーアプリケーションは、ＰＮＲコンテキストの更新と共に、サービスインタセプタ上で実行すべきアクションを提供できる。現在、可能なアクションは、単に機能的な応答をユーザに転送するか、又はＰＮＲディスプレイを有するユーザに応答することであり、これにはインタセプタからＰＮＲディスプレイサービスへの新たなクライアントの呼び出し、及び／又はユーザのＰＮＲコンテキストを無視するような所定の事象を知らせるべき要求を必要とする。

この実施例では、ユーザ１０１は価格設定サービスへの要求を送信する（ステップ１）。このクエリは上述したように最新のＤＣＸを検索して、このＤＣＸ情報をユーザクエリと一緒に予約インタセプタＯＢＥ１０５に渡す（ステップ２）外部ＩＳＡＰ１０３を経て受信される。予約インタセプタＯＢＥはこのユーザに集中化されたＰＮＲコンテキストにアクセスし（このシナリオでは、このコンテキストはオープンシステム上の最新のコンテキストである）、それを機能的要求の先頭にあるＧＣＸに付加する。この完成データ構造（ＤＣＸ＋ＧＣＸ＋Ｑｕｅｒｙ）は、次に内部ＩＳＡＰ１０７を経て価格設定機能をホストする価格設定ＯＢＥ１０９に転送される（ステップ３及び４）。いったん、ビジネスプロセスが実行されると、価格設定ＯＢＥ１０９はコンテキストの更新で予約インタセプタ１０５に向けて応答し（再び内部ＩＳＡＰ１０７を経るステップ５及び６）、予約インタセプタ１０５は外部ＩＳＡＰ１０３を介してユーザ１０１に応答する（ステップ７及び８）。応答におけるコンテキスト更新は、インタセプタによる集中化されたＰＮＲコンテキストに統合され、その応答はユーザに転送される。このメカニズムは、機能的サービスを提供するリモートオープンシステム及び予約オープンシステムにより直接提供されるローカルサービスにも有効である。

図１に示す例は、説明の容易化のために故意に非常に単純化しているが、しかし当業者にとっては、いくつかのサービスＯＢＥが同一の予約インタセプタＯＢＥ１０５によって配置され、制御されることは明らかである。ＧＣＸ上に格納されているユーザＰＮＲは、あるステップから次のステップへと渡され、それが常に更新されるようにする。即ち、セッションが終了したときのみＰＮＲはユーザに戻され、ＧＣＸの一時的なデータ構造は廃棄され、削除される。図２は、予約インタセプタ１０５のインフラストラクチャ内で動作する２つのサービスＯＢＥを伴う、より完全な実施例を示す。この実施例では、ユーザ１０１は、上述の最新のＤＣＸを検索する外部ＩＳＡＰ１０３を介して価格設定サービスに対する要求を送信し、そのＤＣＸ情報をユーザクエリと一緒に予約インタセプタＯＢＥ１０５へと渡す（ステップ２）。予約インタセプタＯＢＥはこのユーザに対する集中型ＰＮＲコンテキストにアクセスし、それを機能的要求の先頭のＧＣＸ内に加える。この完全なデータ構造（ＤＣＸ＋ＧＣＸ＋クエリ）は、内部ＩＳＡＰ１０７を介して価格設定の機能性をホストする価格設定ＯＢＥ１０９に転送される（ステップ３及び４）。いったんこのようなビジネスプロセスが実行されると、価格設定ＯＢＥ１０９は、予約インタセプタ１０５にコンテキストの更新で応答する（再び内部ＩＳＡＰ１０７を通るステップ５及び６）。この場合、予約インタセプタ１０５は、表示ＯＢＥ２０３にクエリを送信する（ステップ７及び８）別の内部ＩＳＡＰ２０１を介してユーザへの応答をフォーマット化するために表示サービスを呼び出す。そのような場合にも、関連する表示をフォーマット化するために表示サービスが正しいＰＮＲデータにアクセスできるように同一の委譲パターンを用いる。いったんこれが実行されると、応答中のコンテキストの更新が予約インタセプタ１０５に返送され（ステップ９及び１０）、インタセプタによって集中型ＰＮＲコンテキスト内に統合され、表示応答は外部ＩＳＡＰ１０３を通じてユーザ１０１へと転送される（ステップ１１及び１２）。このメカニズムは、機能的サービスを提供するリモートオープンシステム及び予約オープンシステムにより直接提供されるローカルサービスにも有効である。クエリメッセージがサブシステムを離れると、すなわちそのメッセージが予約インタセプタ１０５により外部に伝えられると、ＧＣＸはその機能を終了し、それは削除される。そしてＰＮＲ情報の一貫性は、更新が、サービス呼び出しの全体のつながりに相当する一貫性のある更新セットを表すユーザのサービス要求への最終応答のみで集中型コンテキスト内に統合されるという事実によって保証される。そのユーザに提供される応答は、予約システム（例えばアマデウスインフラストラクチャ）内でのみ交換される全ての付加的な情報（ＤＣＸ及び／又はＧＣＸ）から解放される。

本明細書中に説明されている本発明の好適な実施形態による方法は、（上述の同時係属中の出願においても説明されているように）ＤＣＸに基づく同期メカニズムを有する予約システムを参照する。しかし、当業者は、異なるプラットフォーム間の同期をどのようにして確保するのかについて何ら制限を設けること無く（もし同期が必要であれば）その他のインフラストラクチャを代わりに使用できることを理解するであろう。本発明による方法によれば、ユーザ（例えばユーザＰＮＲ）に対応する予約コンテキストが上述の予約インタセプタモジュールにより厳格に制御される一種のサブシステムを実現することができる。そのような制御の「範囲」は、リモートサービスプロバイダ（ＯＢＥ）にまで広げることができ、その影響は、そのような範囲内、すなわちクエリがサブシステムの外部に伝達されなくなるまでの範囲内において、ＰＮＲが常に一貫して同じであり、予約インタセプタ（それはＯＢＥそのものである）の制御無しでは変更することが出来ないと云うことである。いくつかの異なるシステム構造及び複雑な構成が可能であるが、情報の安全性／一貫性とシステムパフォーマンスとのバランスが考慮されるべきである。現在説明中の好適な実施形態によれば、ＤＣＸの目的は、異なるプラットフォーム及びアプリケーション上の適用可能なコンテキストの分布を表すために全てのタイプの通信プロトコル上で、同一のユーザセッションから来る各メッセージの先頭に追加情報を伝送することである。

ＧＣＸの機能は、異なるプラットフォーム及びアプリケーション上の適用可能なコンテキストの分布を表すあらゆるタイプの通信プロトコル上で、同一のユーザセッションから来る各メッセージの先頭に追加情報を伝送することである。

このＧＣＸは、１つのクエリ上又は１つの応答上にのせて伝送されるのみであり、（ＤＣＸの場合のように）コンテキストデータへの参照の代わりにコンテキストデータそのものを含む。これは、全てのメッセージにコンテキストデータを伝送することを意図しておらず、これは、ＧＣＸが永続的なエンティティではない理由である。

ＧＣＸは、後に呼び出されるいくつかのアプリケーションが既に存在しているものの先頭にそれ自身のコンテキストデータを付加することができるようにペアのセット（キー、値）を含む。ＧＣＸはＥＤＩＦＡＣＴとＸＭＬ双方のメッセージ上で伝送することができ、それは、メッセージ追跡のロギングを容易にするためにメッセージの最後に位置づけられる。

予約サービスインタセプタは、価格設定クエリのようなユーザの機能的なクエリを受信し、そのクエリを最新のユーザＰＮＲコンテキストデータで充実(enrich)させる。分散型コンテキスト同期メカニズムのおかげで、予約インタセプタは最新のＰＮＲデータを必要に応じてＴＰＦから検索し、そして価格設定クエリを機能的な価格設定ＯＢＥに委譲する前にＧＣＸ内に付加する。機能的サービスによりプロセスが実行されると、関連したＰＮＲコンテキスト更新を伴う機能的応答が予約サービスインタセプタに返送される。サービスインタセプタは予約ＯＢＥ内のメモリに格納されたユーザＰＮＲコンテキスト内のコンテキスト更新を削除及び統合し、機能的応答をユーザに転送する。

予約サービスインタセプタは機能的クエリをＤＣＸと一緒に受信する。予約サービスインタセプタはＤＣＸの内容をチェックし、分配型コンテキスト同期メカニズムを用いてＴＰＦメインフレームとの同期が必要かどうかをローカルのＰＮＲコンテキスト情報を使用して分析する。いったん最新のＰＮＲコンテキストデータが現在のユーザに対して検索されると、ＰＮＲコンテキストをＧＣＸエンティティにエンコードするために、委譲ライブラリーが用いられる。そしてサービスインタセプタは機能的クエリをＤＣＸ及びＧＣＸと一緒に委譲する。

予約サービスインタセプタが機能的応答を受信すると、予約サービスインタセプタは、提供されたＧＣＸをデコードするために委譲ライブラリーを用いる。ＰＮＲコンテキストデータは、予約ＯＢＥ上に集中化されたユーザＰＮＲコンテキスト内に統合させるために、ＧＣＸから抽出される（詳細は、分散型コンテキスト同期メカニズムを参照のこと）。ＧＣＸからはアクションも抽出され、予約インタセプタはそれを実行する。例えば前述のブロック図は機能的応答の単純な転送のアクションを示し、したがって、予約インタセプタは受信した機能的な応答でユーザに応答するのみである。

委譲メカニズムは、アプリケーションから他のサービスを呼び出すクライアントインターフェースと、同様に他のサービスにこのアプリケーションを呼び出させるサーバーインターフェースとの双方からなる。

本発明の好適な実施形態において、委譲メカニズムは次のいくつかの要求に応えるように設計されている。
−マルチプラットフォームでの委譲と構造の容易な展開をサポートする（異なるＯＢＥ上に異なるバージョンの委譲ライブラリーを有することができ、委譲メッセージは前向きの互換性を有するコンテキストデータのＥＤＩＦＡＣＴシリアライゼーションを用いており、それは古いバージョンの文法で読み取り可能でなければならないからである）。
−いくつかのタイプのコンテキストをサポートする。
−いくつかのモードの委譲をサポートする。
−いくつかのその後の委譲をサポートし、一連のアプリケーションがお互いに機能性の一部を委譲させる。
−委譲の応答の中で、コンテキスト更新及び後処理をサポート（アクションは、機能的な応答の転送、又はユーザへの応答としてのＰＮＲ表示のための要求）。
−コンテキストの取り消しのようなイベントを通知するために委譲の応答の中で、機能的なアプリケーションの登録をサポート。

更に、この委譲データのおかげで、機能的なメッセージと共にいくつかのコンテキストを同時に伝送できる。

これらの要求は、我々が次のセクションで見るＧＣＸ内のコンテキスト情報の内容に直接の影響を与える。ＤＣＸメカニズムに関する限り、その機能性の完全な説明は、同一出願人且つ同一出願日であり、同時係属中の出願である「マルチサーバー予約システム上の同期メカニズムのための方法及びシステム」において見ることができる。好適な実施形態によれば、ＰＮＲコンテキストのローカルメモリ内のコピーは各プラットフォームにおいて複製され、ローカルで更新が実行され、他のプラットフォームが最新のコンテキストデータにアクセスする必要がある時に同期が発生する。これは、我々が分散型コンテキスト同期と呼ぶものである。この同期メカニズムの複雑性は、ローカルにあるコピーが古いかどうかを決定し、最も新しいＰＮＲデータがどこにあるかを決定することにある。このメカニズムは通信プロトコルが何であれ、全てのタイプのユーザクエリ上で動作し、データ表示（ビッグエンディアン又はリトルエンディアン）などのプラットフォームの技術的な特性に依存しない。

ＰＮＲコンテキストの同期に対する現在のアプローチは、同期が必要なときにのみ実行され、ローカルのコンテキストコピーにおいてなされた更新のみを提供するというような、最適な方法でこれらの要求すべてに応える。

本発明の説明の例において、サーバー間の接続はＥＳＢにより実現されるが、当業者は、適切なアプリケーションサーバーへのトランザクションを経路指定することができる従来の経路指定手段の他の任意の状態を、例えばルータ、ポータル、又はリクエストブローカの代わりに用いることができる。

図３を参照し、一般的なコンピュータシステム（例えば、任意のコンピュータ、予約サーバー、ＴＰＦメインフレーム、オープンシステムサーバー、データベースマネジメントサブシステム、ルータ、ネットワークサーバー）を３５０として表示する。コンピュータ３５０は、システムバス３５３に並列に接続されるいくつかの装置により形成される。詳細には、１又は複数のマイクロプロセッサ３５６がコンピュータ３５０の動作を制御し、ＲＡＭ３５９がマイクロプロセッサ３５６によりワークメモリとして直接使用され、ＲＯＭ３６２はコンピュータ３５０のブートストラップのためのベーシックコードを保持する。周辺装置はローカルバス３６５の周囲に（各々のインターフェースの手段により）結集させる。特に、大容量メモリは、ハードディスク３６８及びＣＤ−ＲＯＭ３７４を読み出すためのドライブ３７１から構成される。更に、コンピュータ３５０は入力装置３７７（例えば、キーボード及びマウス）、並びに出力装置３８０（例えば、モニタ及びプリンタ）を備える。ネットワークインターフェースカード３８３を用いて、コンピュータ３５０をネットワークに接続する。ブリッジ装置３８６は、システムバス３５３をローカルバス３６５とインターフェース接続する。各マイクロプロセッサ３５６とブリッジ装置３８６は、情報を伝送するためにシステムバス３５３へのアクセスを要求する主エージェントとして動作する。アービタ３８９は、システムバス３５３への相互除外を伴うアクセスの承諾を管理する。もし、システムが異なる形態を有していたり、他のネットワークをベースにしていても、同様の考えが成り立つ。代わりに、コンピュータは異なる構造を有し、同等の装置を含み、又は他のデータ処理エンティティ（例えばＰＤＡ、携帯電話など）から構成される。

好適な実施形態の方法はまた、図４に示すブロック図で表現される。その方法は、複数のオープンバックエンドサーバー（ＯＢＥ）を有し、各ＯＢＥはサービスを提供し、少なくとも２つのＯＢＥを越えたユーザの取引の間ＰＮＲ記録の一貫性を制御するために採用され、その方法は、黒丸４０１から開始し、ユーザ要求が予約サービスインタセプタにおいて受信されるボックス４０３へと向かう。ステップ４０５において、データ構造をユーザ要求の情報で充実化するように構造が生成され、そのユーザ要求は通常ＰＮＲ（又は要求しているユーザの予約情報を含む同様のデータ構造）を含む。そのような構造（ここではＧＣＸと呼ぶ）は現在のアプリケーションにおいてあるレベルで詳細に説明されているが、しかし当業者は、いくつかの異なる実装が代わりに用いられ得ると評価するであろう。単なる実施例として、付加的な情報が、ＯＢＥ間の取引におけるユーザクエリ及び／又はＰＮＲを伴う個別のデータ構造として生成されうる。ステップ４０７において、（ＧＣＸを含む）満たされたデータ構造は次に予約インタセプタからＯＢＥの１つに転送され、（ユーザ要求において詳細に述べているように）要求されたサービスの１つを受信する。応答が予約インタセプタに返送されると（ステップ４０９）、予約インタセプタは他のサービスが必要かどうかを確認する（ステップ４１１）。もし必要であれば、満たされたデータ構造が他のＯＢＥに転送され、処理はステップ４０７に戻される。ユーザが要求した全てのサービスが提供されると、予約インタセプタはユーザによって呼び出されていたサービスに関連した応答をユーザに返信し、そのユーザに関連する一貫性のあるＰＮＲコンテキストは後の要求のために維持される。

本開示の範囲から逸脱すること無く、上述の実施形態に改変及び変更を加えうることは理解されよう。本来、ローカルの、そして特定の要求を満たすために、当業者は上述のソリューションに多くの変更及び改変を適用しうる。特に、本開示は好適な実施形態を参照してある程度詳細に説明されているが、その形態及び詳細において、様々な省略、代用及び変更だけでなく他の実施形態も可能であることを理解すべきであり、更に開示されたあらゆる実施形態に関連して記載された特定の要素及び／又は方法ステップは、一般的な設計上の選択事項として他のあらゆる実施形態に組み込まれうることが明らかに意図されている。

もし、（開示されている各実施形態を実施するのに用いられる）プログラムを異なる方法で構成する場合、または付加的なモジュール又は機能が提供される場合、同様にメモリ構造が他のタイプであったり、（必ずしも物理的なストレージメディアを構成しない）同等のエンティティで置換される場合、同様の考え方を適用しうる。更に、提案されたソリューションは、（たとえ異なる順序であっても、同様の又は付加的なステップにより）同等の方法で実現するのに向いている。どのような場合でもプログラムは、例えば外部又は専用のソフトウエア、ファームウエア、又は（オブジェクトコード又はソースコードの形式の）マイクロコードのようなあらゆるデータ処理システムにより、又はデータ処理システムと関連して用いられるのに適したあらゆる実体へと発達する。更に、プログラムはコンピュータで使用可能なあらゆるメディアにより提供され、そのメディアは、プログラムを含み、保持し、伝達し、普及させ、又は移動させるのに適したあらゆる要素であって良い。そのようなメディアの実施例は、（プログラムがあらかじめロード可能な）固定ディスク、リムーバブルディスク、テープ、カード、ワイヤ、繊維、ワイヤレス通信、ネットワーク、放送波などであり、例えばそのメディアは、電気的、磁気的、光学的、電磁気的、赤外線によるもの、又は半導体型であっても良い。

あらゆる場合において、本開示によるソリューションは、（例えば、半導体材料のチップ内に集積化した）ハードウエア構造により、又はソフトウエア及びハードウエアの組み合わせにより実現されるように適応する。

Claims (6)

1. 複数のオープンバックエンドサーバー（ＯＢＥ）を有する分散型予約システム上で動作する予約方法であって、
   各ＯＢＥは、少なくとも２つのＯＢＥ間のユーザトランザクション中にＰＮＲ記録の一貫性を制御するためにサービスを提供するように適合され、
   前記方法は、
   予約インタセプタモジュールが少なくとも１つのサービスとＰＮＲ記録への参照のための要求を含むデータ構造を有するユーザ要求を受信するステップと、
   少なくとも１つのサービスとＰＮＲ記録への参照のための要求を含むデータ構造を有する前記ユーザ要求の受信に応答して、前記予約インタセプタモジュールが前記ＰＮＲの最新バージョンを取得するステップと、
   前記予約インタセプタモジュールが前記ＰＮＲ記録の内容を含む情報により前記データ構造を充実させるステップと、
   前記予約インタセプタモジュールが、前記ユーザ要求で要求された前記少なくとも１つのサービスに従って第１の少なくとも１つのＯＢＥに前記充実させたデータ構造を転送するステップと、
   前記充実させたデータ構造の最新バージョンを返送する前記第１の少なくとも１つのＯＢＥに応答して、前記予約インタセプタモジュールが、前記ユーザ要求に含まれる全ての要求されたサービスが提供されるまで、前記充実させたデータ構造を他のＯＢＥに順番に転送するステップと、
   前記予約インタセプタモジュールが、前記データ構造から前記ＰＮＲ記録の内容を含む情報を削除するステップと、
   前記ユーザによって要求された少なくとも１つのサービスに関連した応答を返送するステップと
   を含み、
   前記ユーザと前記予約インタセプタモジュールとの間の通信は、第１の統合サービスアクセスポイント（ＩＳＡＰ）を通して行われ、
   前記予約インタセプタモジュールと前記少なくとも１つのＯＢＥの各々との間の通信は、追加の統合サービスアクセスポイント（ＩＳＡＰｓ）を通して行われる、予約方法。
2. ＯＢＥによるサービスの提供は、前記ＰＮＲ記録の変更を含む、請求項１に記載の方法。
3. 前記分散型予約システムはマルチプラットフォームシステムであり、異なるプラットフォーム上で動作する複数のサーバーを含み、
   前記方法は、前記最新のＰＮＲ記録が前記マルチプラットフォームシステムの少なくとも２つのプラットフォーム間のユーザトランザクション中に使用されることを保証するための同期メカニズムを更に含み、前記マルチプラットフォームシステムの各プラットフォーム内には前記ＰＮＲのローカルコンテキストバージョンが維持され、前記マルチプラットフォームの前記システムはシステムバスを介して相互接続され、前記メカニズムは、
   前記マルチプラットフォームシステムの全てのプラットフォームのサーバーによりアクセス可能な共有コンテキスト格納領域内に、ＰＮＲの最後に更新したバージョンについての情報を維持するステップと、
   ユーザ要求に応答して、選択した前記サーバーの１つに以下のアクションを実行させて前記ＰＮＲのローカルコンテキストバージョンを変更させるステップと
   を含み、前記アクションは、
   サーバーが前記ＰＮＲを最後に更新した前記共有コンテキスト格納領域を確認し、
   前記ＰＮＲを最後に更新したサーバーが前記選択したサーバーとは異なるプラットフォーム上でアクティブである場合に、前記最新バージョンのＰＮＲを取得し、
   前記ユーザ要求を満たすために前記ローカルコンテキストバージョンのＰＮＲを変更し、
   前記最後に更新したバージョンのＰＮＲを反映するように前記共有コンテキスト格納領域を更新することである、請求項１又は２に記載の方法。
4. 前記最後に更新したバージョンのＰＮＲについての情報は、前記最後に更新したバージョンのＰＮＲの位置を含む、請求項３に記載の方法。
5. コンピュータ上で実行される際に、請求項１乃至４のいずれか一項に記載の方法におけるステップを実行するための命令を有するコンピュータプログラム。
6. 複数のオープンバックエンドサーバー（ＯＢＥ）を有する予約サブシステムであって、各ＯＢＥは、少なくとも２つのＯＢＥ間のユーザトランザクション中にＰＮＲ記録の一貫性を制御するために、サービスを提供するように適合され、前記サブシステムは、請求項１乃至４のいずれか一項に記載の方法を実行するように適合された１つ以上のコンポーネントを備える、予約サブシステム。
   

Images