特許 6087847 複数のソフトウェアアプリケーションを必要とするセッションを提供するための方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6087847

(24)【登録日】2017年2月10日

(45)【発行日】2017年3月1日

(54)【発明の名称】複数のソフトウェアアプリケーションを必要とするセッションを提供するための方法およびシステム

(51)【国際特許分類】

   G06F 15/00 20060101AFI20170220BHJP

   G06F 9/50 20060101ALI20170220BHJP

【ＦＩ】

   G06F15/00 470

   G06F9/46 465A

【請求項の数】19

【全頁数】26

(21)【出願番号】特願2013-558439(P2013-558439)

(86)(22)【出願日】2012年3月15日

(65)【公表番号】特表2014-512035(P2014-512035A)

(43)【公表日】2014年5月19日

(86)【国際出願番号】EP2012054563

(87)【国際公開番号】WO2012123544

(87)【国際公開日】20120920

【審査請求日】2015年2月16日

(31)【優先権主張番号】11305281.5

(32)【優先日】2011年3月15日

(33)【優先権主張国】EP

(31)【優先権主張番号】13/065,312

(32)【優先日】2011年3月18日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】509228994

【氏名又は名称】アマデウス エス．アー．エス．

【氏名又は名称原語表記】ＡＭＡＤＥＵＳ Ｓ．Ａ．Ｓ．

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100064908

【弁理士】

【氏名又は名称】志賀 正武

(74)【代理人】

【識別番号】100089037

【弁理士】

【氏名又は名称】渡邊 隆

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(72)【発明者】

【氏名】ピエール・ドール

(72)【発明者】

【氏名】ディートマー・ファウザー

(72)【発明者】

【氏名】ジェローム・ダニエル

(72)【発明者】

【氏名】ステファーヌ・モンベル

(72)【発明者】

【氏名】シリル・ドゥゲ

【審査官】 田中 幸雄

(56)【参考文献】

【文献】 特開２００６−５９３２１（ＪＰ，Ａ）

【文献】 特開２００４−３１０２９８（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００４／０２４９９２１（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １５／００

Ｇ０６Ｆ ９／４６

Ｇ０６Ｆ ９／５０

(57)【特許請求の範囲】

【請求項1】

ユーザ(1、2、3)にユーザセッションを提供する方法において、前記ユーザセッションが、システム(100)によって処理される複数のソフトウェアアプリケーションの動作を必要とし、前記システムが前記ユーザとクライアント/サーバモードで動作し、複数のソフトウェアアプリケーションが、前記ユーザセッションに関係するユーザコンテキストの少なくとも一部分にリンクされた方法であって、少なくとも1つのデータプロセッサを用いて実施される以下のステップ、すなわち、
- 各ユーザセッションにつき、ユーザコンテキストの少なくとも一部分にリンクされた各ソフトウェアアプリケーションが、前記ソフトウェアアプリケーションをそれぞれが独立して処理するアプリケーションサーバ(A1、A2、...)のグループ(20、30、40、50)のうちの専用アプリケーションサーバ(A1、A2、...)によって処理され、それにより、各セッションにつき、前記ユーザセッションとのアフィニティをそれぞれが有するアプリケーションサーバ(A3、B8、C4)のセットを定義するステップと、
- 前記ユーザセッションとのアフィニティを有する各アプリケーションサーバに、前記各アプリケーションサーバによって処理される前記ソフトウェアアプリケーションにリンクされた前記ユーザコンテキストの前記一部分を記憶するように構成されたデータ記憶手段を提供するステップと、
- 1つまたは複数のルーティング手段(10、11、12)において、前記ユーザからの要求を少なくとも受け取り、前記要求を満たすために、前記ユーザセッションとのアフィニティを有する前記アプリケーションサーバ(A3、B8、C4)に少なくとも向けて前記ユーザセッションのトランザクションをルーティングするステップであって、前記1つまたは複数のルーティング手段のうちの1つが、前記ユーザセッションを担当する主要ルーティング手段(10)であるステップとを含み、トランザクションをルーティングする前記ステップが、
○ アフィニティキーを含むように構成された相関レコード(DCX)を前記ユーザセッションに割り当てるステップであって、各アフィニティキーが、所与のソフトウェアアプリケーションについて前記ユーザセッションとのアフィニティを有するアプリケーションサーバを示すものであるステップと、
○ 相関レコードを各トランザクションと共に伝搬し、それにより、前記ルーティング手段(10、11、12)が、前記相関レコードを読み取って、前記ユーザセッションとのアフィニティを有し前記トランザクションの処理に関連する前記ソフトウェアアプリケーションを処理する前記アプリケーションサーバ(A3、B8、C4)をターゲットにすることができるようにするステップと
を含むことを特徴とする方法。

【請求項2】

前記1つまたは複数のルーティング手段(10、11、12)が、あらゆる単一アプリケーションサーバ(A3、B8、C4)にどのように到達するかを知っているように構成された、請求項1に記載の方法。

【請求項3】

前記相関レコードが、前記主要ルーティング手段(10)に関連するデータ記憶手段に記憶される、請求項1または2に記載の方法。

【請求項4】

前記主要ルーティング手段(10)が、前記ユーザからの前記要求を受け取る前記ルーティング手段(10、11、12)である、請求項1から3のいずれか一項に記載の方法。

【請求項5】

前記アフィニティキーが前記ルーティング手段(10、11、12)によって設定される、請求項1から4のいずれか一項に記載の方法。

【請求項6】

前記ルーティング手段(10、11、12)がエンタープライズサービスバス(ESB)である、請求項1から5のいずれか一項に記載の方法。

【請求項7】

ルーティング手段(10、11、12)が、ソフトウェアアプリケーションを処理するアプリケーションサーバから、前記ユーザセッションに割り当てられた前記相関レコードと共にトランザクションを受け取り、次いで、別のソフトウェアアプリケーションを処理する別のアプリケーションサーバに前記トランザクションをルーティングし、前記トランザクションをルーティングする前記ステップが、前記ルーティング手段(10、11、12)が前記相関レコードを読み取るステップを含む、請求項1から6のいずれか一項に記載の方法。

【請求項8】

前記相関レコードが前記ルーティング手段(10、11、12)において受け取られた際、前記別のアプリケーションサーバを示すアフィニティキーを前記相関レコードが含まない場合は、前記ルーティング手段(10、11、12)が前記トランザクションを別のアプリケーションサーバにルーティングする前記ステップが、前記別のソフトウェアアプリケーションにリンクされた前記ユーザコンテキストの前記一部分が記憶されている期間が前記ユーザセッションがアクティブである期間にリンクされなければならないかどうかを前記ルーティング手段(10、11、12)が判定するステップを含む、請求項7に記載の方法。

【請求項9】

前記相関レコードが前記ルーティング手段(10、11、12)において受け取られた際、前記別のアプリケーションサーバを示すアフィニティキーを前記相関レコードが含まない場合であって、前記別のソフトウェアアプリケーションにリンクされた前記ユーザコンテキストの前記一部分が記憶されている期間が前記ユーザセッションがアクティブである期間にリンクされなければならない場合は、前記ルーティング手段(10、11、12)が前記トランザクションを別のアプリケーションサーバにルーティングする前記ステップが、
- 前記ルーティング手段(10、11、12)がアフィニティ初期化の要求を前記主要ルーティング手段(10)に送る追加ステップと、
- 次いで前記主要ルーティング手段(10)が、
○ 前記別のソフトウェアアプリケーションを処理するアプリケーションサーバ(B1、B2、...)の前記グループのうちで前記別のアプリケーションサーバを選択し、
○ 前記別のアプリケーションサーバを示すアフィニティキーで前記相関レコードを拡充し、
○ 前記別のアプリケーションサーバにアフィニティ初期化のメッセージを送り、
○ 前記別のアプリケーションサーバからアフィニティ初期化の確認を受け取り、
○ 拡充された前記相関レコードを前記ルーティング手段(10、11、12)に送る追加ステップと、
- 次いで前記ルーティング手段(10、11、12)が、拡充された前記相関レコードの前記アフィニティキーに従って前記別のアプリケーションサーバに前記トランザクションをルーティングする追加ステップと
を含む、請求項7または8に記載の方法。

【請求項10】

前記相関レコードが前記ルーティング手段(10、11、12)において受け取られた際、前記別のアプリケーションサーバを示す前記アフィニティキーを前記相関レコードが含まない場合であって、前記別のソフトウェアアプリケーションにリンクされた前記ユーザコンテキストの前記一部分の前記記憶されている期間が前記ユーザセッションの前記アクティブである期間にリンクされなくてよい場合は、前記ルーティング手段(10、11、12)が前記トランザクションを前記別のアプリケーションサーバにルーティングする前記ステップが、前記ルーティング手段(10、11、12)が、前記別のソフトウェアアプリケーションを処理するアプリケーションサーバ(B1、B2、...)の前記グループのうちで前記別のアプリケーションサーバを選択し、前記別のアプリケーションサーバに前記トランザクションをルーティングする追加ステップを含む、請求項8に記載の方法。

【請求項11】

前記相関レコードが、前記別のアプリケーションサーバを示す前記アフィニティキーで拡充される、請求項10に記載の方法。

【請求項12】

前記相関レコードが前記ルーティング手段(10、11、12)によって拡充され、前記相関レコードが、前記主要ルーティング手段(10)に返されて、前記主要ルーティング手段(10)に関連するデータ記憶手段に記憶される、請求項11に記載の方法。

【請求項13】

前記相関レコードが前記ルーティング手段(10、11、12)において受け取られた際、前記別のアプリケーションサーバを示す前記アフィニティキーを前記相関レコードがすでに含む場合は、前記ルーティング手段(10、11、12)が前記アフィニティキーに従って前記トランザクションをルーティングする、請求項7に記載の方法。

【請求項14】

アプリケーションサーバが、ルーティング手段(10、11、12)からトランザクションを受け取り、前記トランザクションの処理を介して前記ユーザコンテキストの一部分を生成し、前記アプリケーションサーバに提供されたデータ記憶手段に前記ユーザコンテキストの前記一部分を記憶する、請求項1から13のいずれか一項に記載の方法。

【請求項15】

前記アプリケーションサーバが、前記アプリケーションサーバから前記ユーザコンテキストの前記一部分を取り出すのを可能にするアプリカティブコンテキストキーで前記相関レコードを拡充する、請求項14に記載の方法。

【請求項16】

前記アプリカティブコンテキストキーで拡充された前記相関レコードが、前記主要ルーティング手段(10)に送られ、前記主要ルーティング手段(10)に関連するデータ記憶手段に記憶される、請求項15に記載の方法。

【請求項17】

前記ユーザセッションに関係する更なるトランザクションが前記アプリケーションサーバで受け取られると、前記アプリケーションサーバが前記アプリカティブコンテキストキーに基づいて前記ユーザコンテキストの前記一部分を前記データ記憶手段中で位置特定する、請求項15または16に記載の方法。

【請求項18】

ソフトウェアアプリケーションにリンクされた前記ユーザコンテキストの一部分が記憶されている期間が前記ユーザセッションがアクティブである期間にリンクされなければならない場合は、前記ユーザセッションがアクティブである限り、前記主要ルーティング手段(10)と、前記ソフトウェアアプリケーションを処理する前記アプリケーションサーバとの間で、ステートフルなやり取りが機能しており、前記ユーザセッションが終わると前記ステートフルなやり取りが自動的に終了される、請求項1から9のいずれか一項に記載の方法。

【請求項19】

ユーザ(1、2、3)にユーザセッションを提供するためのシステム(100)において、複数のソフトウェアアプリケーションを備え、前記ユーザセッションを提供するために前記ソフトウェアアプリケーションの動作が必要とされ、前記ソフトウェアアプリケーションのうちの少なくとも1つが、前記ユーザセッションに関係するユーザコンテキストの少なくとも一部分にリンクされたシステム(100)であって、
○ 少なくともプロセッサをそれぞれが備える複数のマシンと、
○ それぞれがマシン上で稼動する複数のアプリケーションサーバ(A1、A2、...)であって、前記ユーザセッションについて、各ソフトウェアアプリケーションが、前記ソフトウェアアプリケーション専用に充てられたアプリケーションサーバ(A1、A2、...)のグループ(20、30、40、50)のうちの1つのアプリケーションサーバによって処理され、それにより、各ユーザセッションにつき、前記ユーザセッションとのアフィニティをそれぞれが有するアプリケーションサーバ(A3、B8、C4)のセットを定義するように、それぞれが構成されたアプリケーションサーバと、
○ 前記ユーザコンテキストの一部分にリンクされたソフトウェアアプリケーションを処理する各アプリケーションサーバに関連するデータ記憶手段であって、前記データ記憶手段に関連する前記アプリケーションサーバによって処理される前記ソフトウェアアプリケーションにリンクされた前記ユーザコンテキストの前記一部分を記憶するようにそれぞれが構成されたデータ記憶手段と、
○ 1つまたは複数のルーティング手段(10、11、12)とを備え、前記ルーティング手段のうちの主要ルーティング手段(10)が前記ユーザセッションを担当するように構成され、前記1つまたは複数のルーティング手段(10、11、12)が、
前記ユーザからの要求を少なくとも受け取り、前記要求を満たすために、前記ユーザセッションのトランザクションを、前記ユーザセッションとのアフィニティを有する前記アプリケーションサーバ(A3、B8、C4)に向けてルーティングするように構成され、前記ルーティング手段(10、11、12)は、トランザクションステップが
○ アフィニティキーを含むように構成された相関レコード(DCX)を前記ユーザセッションに割り当てるステップであって、各アフィニティキーが、所与のソフトウェアアプリケーションについて前記ユーザセッションとのアフィニティを有するアプリケーションサーバを示すものであるステップと、
○ 相関レコードを各トランザクションと共に伝搬し、それにより、前記ルーティング手段(10、11、12)が、前記相関レコードを読み取って、前記ユーザセッションとのアフィニティを有し前記トランザクションの処理に関連する前記ソフトウェアアプリケーションを処理する前記アプリケーションサーバ(A2、B3、C2)をターゲットにすることができるようにするステップとを含むように構成されたことを特徴とするシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は一般に、分散コンピューティング環境で、開かれている各セッションの一貫したビューをソフトウェアアプリケーションのユーザに提供する方法およびシステムに関する。より詳細には、本発明は、非常に多数のユーザセッションが同時におそらく開かれ、各ユーザセッションが、完了するために様々なソフトウェアアプリケーションの協働を必要とする可能性がある場合の、方法およびシステムに関する。

【背景技術】

【0002】

日常生活で電子サービスを使用する人々の数が日々増加するのに伴い、これらの電子サービスを提供するシステムは、数が常に増加するユーザセッションを処理することが必要とされる。加えて、ユーザは今や、送達される情報およびサービスがますます効率的かつ洗練されたものになることを期待している。そこで、この目標を達成するために、各ユーザセッションのトランザクションが複数の異なるソフトウェアアプリケーションによって処理される必要がしばしばある。

【0003】

例えば、旅行観光産業では、予約システムは、フライトの空席のチェックを要求する、同時に開かれた何万ものユーザセッションを処理しなければならない。ユーザからこのようなユーザセッションに提供される情報は通常、フライトの出発日、出発地、および到着地を含む。これらはこのセッションについてのユーザコンテキストの一部をなすが、ユーザコンテキストはまた、空席情報、価格、フライト参照など、セッションによって処理される様々なトランザクションから収集されるデータも含む。

【0004】

十分なスループットを維持するために、いくつかの解決法は、非常に強力な単一の処理ユニットを有する集中コンピューティングシステムに基づく。しかし、これらの集中システムは、新しい追加アプリケーションを配置することと処理能力を増大させることの両方の点で、ほとんどスケーラブルでない。加えて、これらのシステムは、集中処理ユニットの障害が全般的な停止につながることがあるため、信頼性がない。

【0005】

他の解決法は、総処理能力が多数の分散マシンに広がる、分散システムに依拠する。しかし、これらの既存の分散システム中では、所与のユーザセッション専用に充てられた全てのトランザクションが、やはり単一のマシンによって管理される。

【0006】

この場合、スケーラビリティは、単純にマシンの数を増加させることによって達成され、したがって、システムの全体的な処理能力を容易に適合させて、スループットのニーズを満たすことができる。

【0007】

しかし、これらの分散システムでは、新しいサービスの統合を管理することは難しいままである。特に、新しいサービスが、ユーザ側から見た一貫性を常に維持しながら、すでにロードされたソフトウェアアプリケーションと対話するように意図された新しいソフトウェアアプリケーションに基づくときには、そうである。

【0008】

このため、ユーザ側から見て一貫性があり統一されたビューを維持できるためには、新しいソフトウェアアプリケーションがあらゆる単一マシンにロードされなければならない。しかしこれは、時間がかかる操作である上に、ロードするステップが分散システム全体にわたって完了するまでは、全てのユーザ間の一貫性を実際に達成することはできない。

【発明の概要】

【発明が解決しようとする課題】

【0009】

したがって、本発明の一般的な目的は、処理能力のスケーラビリティを可能にし、新しいサービスの統合を容易にしながら、セッションの統一されたビューをユーザに提供することのできる、方法およびシステムについて述べることである。

【課題を解決するための手段】

【0010】

本発明の実施形態により、前述および他の目的が少なくとも部分的に達成され、他の利点が実現される。

【0011】

本発明は、コンピュータ化されたユーザセッションの統一されたビューをユーザに提供する方法に関し、ユーザセッションは、システムによって処理される複数のソフトウェアアプリケーションの動作を必要とし、システムはユーザとクライアント/サーバモードで動作し、複数のソフトウェアアプリケーションはそれぞれ、ユーザセッションに関係するユーザコンテキストの少なくとも一部分にリンクされる。この方法は、少なくとも1つのプロセッサを用いて実施される以下のステップ、すなわち、
- 各ユーザセッションにつき、ユーザコンテキストの少なくとも一部分にリンクされた各ソフトウェアアプリケーションが、このソフトウェアアプリケーションをそれぞれが独立して処理するアプリケーションサーバのグループのうちの専用アプリケーションサーバによって処理され、それにより、各セッションにつき、ユーザセッションとのアフィニティ(affinity)をそれぞれが有するアプリケーションサーバのセットが定義されるステップと、
- ユーザセッションとのアフィニティを有する各アプリケーションサーバに、前記各アプリケーションサーバによって処理されるアプリケーションソフトウェアにリンクされたユーザコンテキストの部分を記憶するように構成されたデータ記憶手段を提供するステップと、
- 1つまたは複数のルーティング手段において、ユーザからの要求を少なくとも受け取り、この要求を満たすために、ユーザセッションとのアフィニティを有するアプリケーションサーバに少なくとも向けてユーザセッションのトランザクションをルーティングするステップであって、1つまたは複数のルーティング手段のうちの1つが、ユーザセッションを担当する主要ルーティング手段であるステップとを含み、トランザクションをルーティングするステップが、
○ アフィニティキー(Affinity Key)を含むように構成された相関レコード(DCX)をユーザセッションに割り当てるステップであって、各アフィニティキーが、所与のソフトウェアアプリケーションについてユーザセッションとのアフィニティを有するアプリケーションサーバを示すものであるステップと、
○ 相関レコードを各トランザクションと共に伝搬し、それにより、ルーティング手段が、相関レコードを読み取って、ユーザセッションとのアフィニティを有しトランザクションの処理に関連するソフトウェアアプリケーションを処理するアプリケーションサーバをターゲットにすることができるようにするステップとを含むことを特徴とする。

【0012】

本発明の別の態様は、ユーザにユーザセッションを提供する方法に関し、ユーザセッションは、ユーザとクライアント/サーバモードで動作するシステムによって処理される複数のソフトウェアアプリケーションの動作を必要とし、ソフトウェアアプリケーションのうちの少なくとも1つは、ユーザセッションに関係するユーザコンテキストの少なくとも一部分にリンクされる。この方法は、各ユーザセッションにつき、各ソフトウェアアプリケーションが、前記各ソフトウェアアプリケーションをそれぞれが独立して処理するアプリケーションサーバのグループのうちの1つのアプリケーションサーバによって処理されること、および、それにより、ユーザコンテキストの部分にリンクされたソフトウェアアプリケーションを処理する各アプリケーションサーバが、ユーザコンテキストにリンクされ、すなわちセッションとのアフィニティを有し、リンク先のユーザコンテキストの部分を記憶するように構成されたデータ記憶手段を提供されることを特徴とする。この方法は、少なくとも1つのプロセッサを用いて実施されるステップであって、アフィニティキーを含むように構成された相関レコード(DCX)をユーザセッションに割り当てるステップを含み、各アフィニティキーは、所与のソフトウェアアプリケーションおよび前記ユーザセッションについてターゲットにしなければならないアプリケーションサーバを示す。この方法はまた、1つまたは複数のルーティング手段のうちの1つにおいてプロセッサを介して実施される以下のステップを含み、1つのルーティング手段は、ユーザセッションを担当する主要ルーティング手段である。すなわち、トランザクションを受け取るステップと、トランザクションによって呼び出されるソフトウェアアプリケーションを決定するステップと、ユーザコンテキストにリンクされたアプリケーションサーバにルーティングされることをトランザクションが必要とするかどうか判定するステップとを含み、
○ ユーザコンテキストにリンクされたアプリケーションサーバにルーティングされることをトランザクションが必要とする場合は、
- 相関レコードが、呼び出されたソフトウェアアプリケーションについてのいずれかのアフィニティキーを含む場合は、アフィニティキーに従ってトランザクションをルーティングし、
- 相関レコードが、呼び出されたソフトウェアアプリケーションについてのアフィニティキーを含まない場合は、ルーティング手段のうちの1つが、呼び出されたソフトウェアアプリケーションを処理するアプリケーションサーバのグループのうちのアプリケーションサーバを選択し、選択されたアプリケーションサーバを示すアフィニティキーで相関レコードを拡充し、選択されたアプリケーションサーバにトランザクションをルーティングし、主要ルーティング手段は、相関レコードを記憶する。

【0013】

任意選択で、かつ好ましくは、ユーザコンテキストにリンクされたアプリケーションサーバにルーティングされることをトランザクションが必要としない場合は、ルーティング手段は、呼び出されたソフトウェアアプリケーションを処理するアプリケーションサーバのグループのうちでアプリケーションサーバを選択し、選択されたアプリケーションサーバにトランザクションをルーティングする。

【0014】

任意選択で、かつ好ましくは、トランザクションを受け取るステップは、ユーザからトランザクションを受け取ることを含む。任意選択で、トランザクションを受け取るステップは、ソフトウェアアプリケーションからトランザクションを受け取ることを含む。

【0015】

本発明の別の態様は、ソフトウェアプログラム命令を含む非一時的なコンピュータ可読記録媒体に関する。ソフトウェアプログラム命令が少なくとも1つのデータプロセッサによって実行されると、前記請求項のいずれか一項における方法の実行を含む動作が実施される。

【0016】

別の態様によれば、本発明は、前述の特徴およびステップのいずれか1つにおける方法を実行するように構成された手段を備えるシステムに関する。

【0017】

本発明の別の態様は、ユーザにユーザセッションを提供するためのシステムに関し、このシステムは複数のソフトウェアアプリケーションを備え、ユーザセッションを提供するためにソフトウェアアプリケーションの動作が必要とされ、ソフトウェアアプリケーションのうちの少なくとも1つは、ユーザセッションに関係するユーザコンテキストの少なくとも一部分にリンクされる。このシステムは、
○ 少なくともプロセッサをそれぞれが備える複数のマシンと、
○ それぞれがマシン上で稼動する複数のアプリケーションサーバであって、このユーザセッションについて、各ソフトウェアアプリケーションが、このソフトウェアアプリケーション専用に充てられたアプリケーションサーバのグループのうちの1つのアプリケーションサーバによって処理され、それにより、各ユーザセッションにつき、ユーザセッションとのアフィニティをそれぞれが有するアプリケーションサーバのセットが定義されるように、それぞれが構成されたアプリケーションサーバと、
○ ユーザコンテキストの部分にリンクされたソフトウェアアプリケーションを処理する各アプリケーションサーバに関連するデータ記憶手段であって、前記記憶手段に関連するアプリケーションサーバによって処理されるソフトウェアアプリケーションにリンクされたユーザコンテキストの部分を記憶するようにそれぞれが構成されたデータ記憶手段と、
○ 1つまたは複数のルーティング手段とを備え、これらのルーティング手段のうちの主要ルーティング手段がユーザセッションを担当するように構成され、1つまたは複数のルーティング手段が、ユーザからの要求を少なくとも受け取り、この要求を満たすために、ユーザセッションのトランザクションを、ユーザセッションとのアフィニティを有するアプリケーションサーバに向けてルーティングするように構成され、ルーティング手段が、トランザクションステップが
○ アフィニティキーを含むように構成された相関レコード(DCX)をユーザセッションに割り当てるステップであって、各アフィニティキーが、所与のソフトウェアアプリケーションについてユーザセッションとのアフィニティを有するアプリケーションサーバを示すものであるステップと、
○ 相関レコードを各トランザクションと共に伝搬し、それにより、ルーティング手段が、相関レコードを読み取って、ユーザセッションとのアフィニティを有しトランザクションの処理に関連するソフトウェアアプリケーションを処理するアプリケーションサーバをターゲットにすることができるようにするステップとを含むように構成されたことを特徴とする。

【0018】

本発明の実施形態の前述および他の態様は、後続の詳細な説明を添付の図面と共に読めば、より明白になる。

【図面の簡単な説明】

【0019】

【図1】本発明の一実施形態によるシステムの例を示す図である。

【図2】例示的な使用事例が描かれた、本発明の別の実施形態によるシステムの例を示す図である。

【図3】図2のシステムと、ユーザコンテキストの部分の寿命がユーザセッションの寿命にリンクされる必要があるステップを示す別の例示的な使用事例とを示す図である。

【図4】アフィニティ初期化ステップを示す、システムのいくつかの構成要素の単純化された高レベルブロック図である。

【図5】例示的な使用事例を示す、システムのいくつかの構成要素の単純化された高レベルブロック図である。

【発明を実施するための形態】

【0020】

いくつかの有利な特徴およびステップについて以下に述べる。次いで、いくつかの例示的な実施形態および使用事例について、図面に関してさらに詳述する。

【0021】

上に示したように、本発明は、コンピュータ化されたユーザセッションの統一されたビューをユーザに提供する方法に関し、ユーザセッションは、システムによって処理される複数のソフトウェアアプリケーションの動作を必要とし、システムはユーザとクライアント/サーバモードで動作し、複数のソフトウェアアプリケーションはそれぞれ、ユーザセッションに関係するユーザコンテキストの少なくとも一部分にリンクされる。この方法は、少なくとも1つのプロセッサを用いて実施される以下のステップ、すなわち、
- 各ユーザセッションにつき、ユーザコンテキストの少なくとも一部分にリンクされた各ソフトウェアアプリケーションが、このソフトウェアアプリケーションをそれぞれが独立して処理するアプリケーションサーバのグループのうちの専用アプリケーションサーバによって処理され、それにより、各セッションにつき、ユーザセッションとのアフィニティをそれぞれが有するアプリケーションサーバのセットが定義されるステップと、
- ユーザセッションとのアフィニティを有する各アプリケーションサーバに、前記各アプリケーションサーバによって処理されるアプリケーションソフトウェアにリンクされたユーザコンテキストの部分を記憶するように構成されたデータ記憶手段を提供するステップと、
- 1つまたは複数のルーティング手段において、ユーザからの要求を少なくとも受け取り、この要求を満たすために、ユーザセッションとのアフィニティを有するアプリケーションサーバに少なくとも向けてユーザセッションのトランザクションをルーティングするステップであって、1つまたは複数のルーティング手段のうちの1つが、ユーザセッションを担当する主要ルーティング手段であるステップとを含み、トランザクションをルーティングするステップは、
○ アフィニティキーを含むように構成された相関レコード(DCX)をユーザセッションに割り当てるステップであって、各アフィニティキーが、所与のソフトウェアアプリケーションについてユーザセッションとのアフィニティを有するアプリケーションサーバを示すものであるステップと、
○ 相関レコードを各トランザクションと共に伝搬し、それにより、ルーティング手段が、相関レコードを読み取って、ユーザセッションとのアフィニティを有しトランザクションの処理に関連するソフトウェアアプリケーションを処理するアプリケーションサーバをターゲットにすることができるようにするステップとを含む。

【0022】

したがって、各サービスグループが、独立したアプリケーションサーバセット上で処理され、各アプリケーションサーバは、独立したマシンによっておそらく稼動され、サービスグループに関係するユーザコンテキストの部分は、このサービスグループを担当するアプリケーションサーバのうちの1つの上でローカルに記憶され、各ユーザは、システムが1つだけのアプリケーションサーバであるかのように、システムと対話する。DCXは、システムに入来する各トランザクションに追加されて、おそらく多数であるサーバにわたって広がる複数のユーザコンテキストの部分を相関させる。アフィニティキーは、所与のサービスセットについて、どのアプリケーションサーバ(およびマシン)がユーザコンテキストの部分を保持しているかを識別するための特定の情報である。次いで、アフィニティキーは、ユーザのコンテキストを管理する特定のアプリケーションサーバにトランザクションをルーティングするために、ESBによって使用される。

【0023】

したがって、本発明は、システムのモジュール性を保持して処理容量の増大を容易にするとともに、新しいサービス/製品の容易な統合を可能にして、一貫性があり統一されたユーザコンテキストのビューをユーザに提供するための、解決法を開示する。

【0024】

本発明はまた、様々なソフトウェアアプリケーションを含む大域的な製品の各下位部分に割り振られたリソースをより容易に制御できるようにするので、操作性の点で大きな利点をもたらす。本発明はまた、所与のマシンまたは1組のマシン上の停止が他のマシンに著しく影響を及ぼすことがないので、大域的な停止のリスクを最小限に抑えることも可能にする。

【0025】

全てのアプリケーションサーバは、相互から独立している。アプリケーションサーバは、相互を知らない。ルーティング手段によって読み取られる相関レコードのみが、異なるソフトウェアアプリケーションを処理する2つのアプリケーションサーバ間で会話を確立するのを可能にする。したがって、アフィニティキーは、相関レコードに追加される参照であり、アフィニティキーにより、ルーティング手段は、ユーザセッションにリンクされたユーザコンテキストの部分を保持しトランザクションの処理に関連するアプリケーションサーバを、ターゲットにすることができる。

【0026】

任意選択で、本発明は、以下の非限定的な特徴およびステップのうちの少なくとも1つを含んでもよい。

【0027】

1つまたは複数のルーティング手段は、あらゆる単一アプリケーションサーバにどのように到達するかを知っているように構成される。

【0028】

したがって、1つまたは複数のルーティング手段は、各アプリケーションサーバの存在と、各アプリケーションサーバがどこに位置するかとを知っている。1つまたは複数のルーティング手段はまた、所与のソフトウェアアプリケーションがどのアプリケーションサーバ上で処理されるかも知っている。

【0029】

好ましくは、相関レコードは、主要ルーティング手段に関連するデータ記憶手段に記憶される。

【0030】

主要ルーティング手段は、ユーザ要求を受け取るルーティング手段である。アフィニティキーは、ルーティング手段によって設定される。

【0031】

ルーティング手段は、エンタープライズサービスバス(ESB)である。

【0032】

ルーティング手段は、ソフトウェアアプリケーションを処理するアプリケーションサーバからのトランザクションと、セッションに割り当てられた相関レコードとを受け取り、トランザクションを、別のソフトウェアアプリケーションの処理に専用に充てられた別のアプリケーションサーバにルーティングする。トランザクションをルーティングするステップは、ルーティング手段が相関レコードを読み取るステップを含む。

【0033】

相関レコードが前記ルーティング手段において受け取られた際、トランザクションがルーティングされなければならない前記別のアプリケーションサーバを示すアフィニティキーを相関レコードが含まない場合は、前記ルーティング手段がトランザクションを別のアプリケーションサーバにルーティングするステップは、前記別のソフトウェアアプリケーションにリンクされたユーザコンテキストの部分の寿命がセッションの寿命にリンクされなければならないかどうかをルーティング手段が判定する追加ステップを含む。

【0034】

相関レコードが前記ルーティング手段において受け取られた際、トランザクションがルーティングされなければならない前記別のアプリケーションサーバを示すアフィニティキーを相関レコードが含まない場合であって、前記別のソフトウェアアプリケーションにリンクされたユーザコンテキストの部分の寿命がユーザセッションの寿命にリンクされなければならない場合は、前記ルーティング手段がトランザクションを別のアプリケーションサーバにルーティングするステップは、
- 前記ルーティング手段がアフィニティ初期化の要求を主要ルーティング手段に送る追加ステップと、
- 次いで主要ルーティング手段が、
○ 前記別のソフトウェアアプリケーションを処理するアプリケーションサーバのグループのうちで前記別のアプリケーションサーバを選択し、
○ 前記別のアプリケーションサーバにアフィニティ初期化のメッセージを送り、
○ 前記別のアプリケーションサーバからアフィニティ初期化の確認を受け取り、
○ 前記別のアプリケーションサーバを示すアフィニティキーで相関レコードを拡充し、
○ 拡充された相関レコードを前記ルーティング手段に送る追加ステップと、
- 次いで前記ルーティング手段が、拡充された相関レコードのアフィニティキーに従って前記別のアプリケーションサーバにトランザクションをルーティングする追加ステップとを含む。

【0035】

相関レコードが前記ルーティング手段において受け取られた際、トランザクションがルーティングされなければならない前記別のアプリケーションサーバを示すアフィニティキーを相関レコードが含まない場合であって、前記別のソフトウェアアプリケーションにリンクされたユーザコンテキストの部分の寿命がセッションの寿命にリンクされなくてよい場合は、前記ルーティング手段がトランザクションを前記別のアプリケーションサーバにルーティングするステップは、前記ルーティング手段が、トランザクションを達成するために処理しなければならない前記別のソフトウェアアプリケーションを処理するアプリケーションサーバのグループのうちで前記別のアプリケーションサーバを選択し、前記別のアプリケーションサーバにトランザクションをルーティングする追加ステップを含む。

【0036】

相関レコードは、前記別のアプリケーションサーバを示すアフィニティキーで拡充されるのが好ましい。

【0037】

相関レコードは前記ルーティング手段によって拡充され、相関レコードは、返信パスを介して主要ルーティング手段に返されて、主要ルーティング手段に関連するデータ記憶手段に記憶される。相関レコードを拡充するルーティング手段と、主要ルーティング手段とは、別個である。代替の一実施形態によれば、相関レコードを拡充するルーティング手段と、主要ルーティング手段とは、同じである。

【0038】

相関レコードが前記ルーティング手段において受け取られた際、トランザクションがルーティングされなければならない前記別のアプリケーションサーバを示すアフィニティキーを相関レコードがすでに含む場合は、前記ルーティング手段は、アフィニティキーに従って前記アプリケーションサーバにトランザクションをルーティングする。

【0039】

アプリケーションサーバは、ルーティング手段からトランザクションを受け取り、トランザクションの処理を介してユーザコンテキストの部分を生成し、前記アプリケーションサーバに提供されたデータ記憶手段にユーザコンテキストの部分を記憶する。

【0040】

アプリケーションサーバは、前記アプリケーションサーバからユーザコンテキストの前記部分を取り出すのを可能にするアプリカティブコンテキストキー(Applicative Context Key)で相関レコードを拡充する。

【0041】

したがって、アプリカティブコンテキストキーは、ソフトウェアアプリケーションにリンクされたユーザコンテキストの前記部分が前記アプリケーションサーバ上のどこに位置するかを示す参照である。

【0042】

アプリカティブコンテキストキーで拡充された相関レコードは、返信パスを介して主要ルーティング手段に返送され、主要ルーティング手段に関連するデータ記憶手段に記憶される。

【0043】

前記ユーザセッションに関係するさらに別のトランザクションが前記アプリケーションサーバで受け取られると、前記アプリケーションサーバは、アプリカティブコンテキストキーに基づいて、ユーザコンテキストの前記部分を前記記憶手段中で突き止める。次いで、ユーザコンテキストの前記部分をさらに取り出して処理することができる。これにより、ユーザコンテキストの全ての部分を、それがどこに位置しようと容易に取り出すことができる。

【0044】

相関レコードは、各トランザクションと共に伝搬される。相関レコードは、ルーティング手段によってアフィニティキーで拡充され、それによりルーティング手段は、ユーザセッションのコンテキストの部分を保持するアプリケーションサーバをターゲットにすることができる。相関レコードはまた、アプリケーションサーバによってアプリカティブコンテキストキーで拡充され、それにより各アプリケーションサーバは、記憶手段に記憶されたユーザコンテキストの部分を取り出すことができる。新しいアフィニティキーまたは新しいアプリカティブコンテキストキーで相関レコードが拡充される度に、相関レコードは主要ルーティング手段に返される。

【0045】

ソフトウェアアプリケーションにリンクされたユーザコンテキストの部分の寿命がユーザセッションの寿命にリンクされなければならない場合は、ユーザセッションがアクティブである限り、主要ルーティング手段と、前記ソフトウェアアプリケーションを処理するアプリケーションサーバとの間で、ステートフルな会話が開いている。このステートフルな会話は、ユーザセッションが終わると自動的に閉じられる。

【0046】

ユーザセッションがアクティブである限り、主要ルーティング手段は、ユーザコンテキストの前記部分が記憶されたままでなければならないことを、前記アプリケーションサーバに定期的に示すのが有利である。

【0047】

主要ルーティング手段は、前記別のソフトウェアアプリケーションにリンクされたユーザコンテキストの前記部分を削除してよいことを、前記アプリケーションサーバに示す。

【0048】

ソフトウェアアプリケーションにリンクされたユーザコンテキストの部分は、ユーザによって、かつ/または、ユーザコンテキストの前記部分を記憶するデータ記憶手段を備えるアプリケーションサーバにリンクされたソフトウェアアプリケーションによって、生成されてよい。ソフトウェアアプリケーションにリンクされたユーザコンテキストの部分はまた、このソフトウェアアプリケーションによって必要とされるかまたは生成されてよい。

【0049】

所与のアプリケーションサーバの各データ記憶手段は、別のアプリケーションサーバのデータ記憶手段とは別個である。

【0050】

アプリケーションサーバは、プロセッサとデータ記憶手段とを備えるマシン上で稼動する。一実施形態によれば、少なくとも複数のアプリケーションサーバが、同じマシン上で稼動する。別の実施形態によれば、1つのマシンにつき、1つの単一アプリケーションサーバが稼動する。

【0051】

典型的には、セッションは、旅行製品の入手可能性をチェックすること、旅行製品をブッキングすること、旅行製品の支払いをすることのうちの、少なくとも1つを可能にする。例えば、ユーザコンテキストの部分は、旅行製品の入手可能性に関係する場合がある。典型的には、旅行製品は、フライト、鉄道、またはボート輸送の、チケットである。ユーザコンテキストの部分はまた、旅行の乗客名簿(PNR、passenger name record)に関係する場合もある。

【0052】

本発明のコンテキストでは、ユーザセッションは、ユーザに少なくともサービスが提供される場合のセッションと考えることができ、サービスは、1つまたは複数のソフトウェアアプリケーションが処理されることを必要とする。

【0053】

例えば、ユーザセッションの間、ユーザは、鉄道乗車券の入手可能性情報に関係するサービス、および航空券の入手可能性情報に関係するサービスにアクセスする。これらの各サービスは、ソフトウェアアプリケーションの動作を必要とする。ソフトウェアアプリケーションは例えば、出発日および/または出発地および/または到着地に関する入力をユーザから受け取るためのソフトウェアアプリケーション、ユーザ要求のプロトコルを別のプロトコルに変換するためのソフトウェアアプリケーション、鉄道在庫データベースから鉄道に関する入手可能性データを取り出すためのソフトウェアアプリケーション、航空会社在庫データベースから入手可能性データを取り出すためのソフトウェアアプリケーションなどである。

【0054】

図1に示すように、システムは、ユーザからの要求を受け取るルーティング手段を少なくとも備える。ルーティング手段は、エンタープライズサービスバスであることが好ましい。別法として、ルーティング手段は、トランザクションを適切なアプリケーションサーバにルーティングできるルータまたはいずれか他の手段であってもよい。以下では、ルーティング手段をESBと呼ぶ。その性質は、エンタープライズサービスバス、ルータなど、何であってもよい。

【0055】

各ユーザセッションにつき、1つのESBがそのセッションを担当する。このESBを、主要ESBと呼ぶ。主要ESBは、ユーザからの要求を受け取るESBであることが好ましい。

【0056】

システムは、複数のマシンを備えることが好ましい。各マシンは、少なくともアプリケーションサーバを稼動する処理手段を少なくとも備えるハードウェアデバイスである。マシンのうちの少なくともいくつかは、データ記憶手段も備える。少なくともアプリケーションサーバは、マシン上で稼動する。アプリケーションサーバは、処理手段を使用する。アプリケーションサーバのうちの少なくともいくつかは、データ記憶手段も使用する。したがって、アプリケーションサーバは、処理手段、および最終的にはデータ記憶手段にリンクされる。

【0057】

特定の一実施形態によれば、単一のマシン上で、複数のアプリケーションサーバが稼動する。各アプリケーションサーバは、それ自体のプロセッサ手段、および最終的にはそれ自体の最終的なデータ記憶手段を使用することができる。別法として、複数のアプリケーションサーバが、同じプロセッサ、および最終的には同じデータ記憶手段を共有することもできる。

【0058】

別の実施形態によれば、所与のマシンに対して、1つのアプリケーションサーバのみが稼動する。したがって、この別の実施形態によれば、マシンにトランザクションをルーティングすることはまた、以下の記述においては、アプリケーションサーバにトランザクションをルーティングすることを意味することになる。

【0059】

各アプリケーションサーバは、ソフトウェアアプリケーションを処理する。

【0060】

有利にも、同じソフトウェアアプリケーションが、複数のアプリケーションサーバによって独立して処理され、これらのアプリケーションサーバは、同じマシン上で、または異なるマシン上で稼動する。

【0061】

システムは、プラットフォームと呼ぶこともできる。

【0062】

アプリケーションサーバは、グループ20、30、40、50に編成される。

【0063】

同じアプリケーションサーバグループのうちの全てのアプリケーションサーバは、同じソフトウェアアプリケーションを処理する。例えば、グループ20の各アプリケーションサーバA1、A2、...、A12は、ソフトウェアアプリケーションAを処理する。グループ30の各アプリケーションサーバB1、B2、...、B8は、ソフトウェアアプリケーションBを処理する。グループ40の各アプリケーションサーバC1、C2、C3は、ソフトウェアアプリケーションCを処理する。

【0064】

所与のセッションに対して、ソフトウェアアプリケーション1つにつき動作するアプリケーションサーバは1つだけである。したがって、同じソフトウェアアプリケーションを処理するアプリケーションサーバのグループのうち、1つのアプリケーションサーバが、この所与のセッション専用に充てられる。

【0065】

上に示したように、データを記憶する必要のある各アプリケーションサーバには、データ記憶手段が提供される。あるセッション専用に充てられたアプリケーションサーバは、この専用アプリケーションサーバによって処理されるソフトウェアアプリケーションに関連するユーザコンテキストの部分を、その記憶手段に記憶する。

【0066】

本発明では、ユーザコンテキスト(コンテキストとも呼ぶ)は、ユーザに関係しセッションの処理に関連するコンテキストである。ユーザコンテキストは、要求された機能を実施するためにシステムがこの特定のユーザに対して使用する全ての機能的および技術的情報を表し、例えば、旅行予約システムでは、アクティブなエンドセッションにリンクされた予約(ショッピング)セッションコンテキストを表す。ユーザコンテキストの部分は、ユーザ個人参照、出発日、出発地、または到着地など、ユーザによって提供されたデータとすることができる。この、ユーザコンテキストの部分は、記憶手段にリンクされたソフトウェアアプリケーションによって必要とされることがある。ユーザコンテキストの部分はまた、ソフトウェアアプリケーションによって生成されるデータとすることもできる。例えば、ユーザコンテキストの部分は、ソフトウェアアプリケーションによって取り出されるフライト空席、または、ソフトウェアアプリケーションによって計算されるか取り出される価格に関係するものである場合がある。ユーザコンテキストの部分はまた、乗客名簿(PNR、passenger name record)、またはPNRの一部に関係するものである場合もある。

【0067】

したがって、ユーザのコンテキストは、おそらく非常に多数であるアプリケーションサーバにわたって分散し、ユーザコンテキストの各部分はローカルに記憶される。図1に示すように、ユーザUaのコンテキストは、部分a0、a1、a2、a3を含み、アプリケーションサーバA2、B3、C2にわたって分散する。ユーザUbのコンテキストは、部分b0、b1、b2、b3を含み、アプリケーションサーバA5、B5、C4にわたって分散する。より正確には、ユーザUaのコンテキストの部分a1は、アプリケーションサーバA2のデータ記憶手段に記憶される。ユーザUaのコンテキストの部分a2は、アプリケーションサーバB3のデータ記憶手段に記憶される。ユーザUcのコンテキストの部分c3は、アプリケーションサーバC3などのデータ記憶手段に記憶される。

【0068】

したがって、所与のユーザセッション専用に充てられた全てのアプリケーションサーバは、このセッションとのアフィニティをそれぞれが有するアプリケーションサーバのセットを形成する。

【0069】

セッションを処理し、セッションの統一されたビューをユーザに提供するためには、システムは、このセッションとのアフィニティを有する全てのアプリケーションサーバをターゲットにしなければならない。

【0070】

セッションの統一されたビューをユーザに提供することは、様々なソフトウェアアプリケーションが様々な独立したアプリケーションサーバによって処理されることに、ユーザが気付かないことを意味する。したがって、セッションに関係するソフトウェアアプリケーションおよびアプリケーションサーバの数は、ユーザにはトランスペアレントである。ユーザは、システムが1つの一意のアプリケーションサーバおよびマシンであるかのように、システムと対話する。

【0071】

関連する複数のアプリケーションサーバをターゲットにするための解決法については、後で図2〜5に関して詳述する。

【0072】

図1は、追加のアプリケーションサーバをシステムに加えてそれによりシステム全体の処理能力を高めることができることを、明確に示す。例えば、アプリケーションサーバA1、A2、...、A8を含むグループ20に、アプリケーションサーバA9、A10、A11、A12が追加される。したがって、グループ20によってより多くのトランザクションを処理することができ、処理時間を減少させずにより多数のセッションを同時に扱うことができる。加えて、追加のアプリケーションサーバを統合することは、容易であり、ユーザにとって完全にトランスペアレントである。

【0073】

有利にも、本発明はまた、新しいサービスまたは新しいソフトウェアアプリケーションをシステムに統合することも可能にする。アプリケーションサーバD1、D2、D3、D4のグループ50は、前に統合されたアプリケーションサーバによって処理されない新しいソフトウェアアプリケーションを処理するアプリケーションサーバが統合されることを例示する。したがって、すでに統合されたあらゆる単一アプリケーションサーバに新しいソフトウェアアプリケーションをロードする必要なしに、追加のサービスを全てのユーザに提供することができる。さらに、新しいソフトウェアアプリケーションをシステムに統合することは、非常に単純である。というのは、これらの新しいソフトウェアアプリケーションおよびアプリケーションサーバの存在を知らなければならないのは、ESBのみだからである。より正確には、新しい各アプリケーションサーバを統合するとき、アプリケーションサーバ、およびその上で稼動するソフトウェアアプリケーションが、ESBに対して宣言される。複数のESBがある場合、全てのESBは、システムのトポロジを知っている。すなわち、各ESBは、各アプリケーションサーバをどこに配置するか、および、各アプリケーションサーバ上で処理されるソフトウェアアプリケーションがどれであるかを知っている。

【0074】

特定の一実施形態では、複数のアプリケーションサーバが単一のハードウェアマシン上で稼動する。しかし、ESBは、各ソフトウェアアプリケーション専用に充てられた全てのアプリケーションサーバを知っている。

【0075】

すでにシステム中にあるアプリケーションサーバのグループは、追加のアプリケーションサーバまたは追加のソフトウェアアプリケーションが統合されたことを知らなくてもよい。したがって、追加の処理容量または追加のサービスを統合しても、システムの残りの部分には影響せず、ユーザにはトランスペアレントである。

【0076】

本発明により、新しいソフトウェアアプリケーションを全てのユーザに同時に利用可能にすることもまた容易であり、時間がかからない。

【0077】

例示する使用事例では、あらゆるアプリケーションサーバは、ユーザコンテキストの部分を保持する。いくつかの実施形態では、アプリケーションサーバは、ユーザコンテキストの部分を記憶しない。例えば、このようなアプリケーションサーバは、販売トランザクションを外部プロバイダに伝搬する場合に、担当のHTMLリソースなど何らかの静的データを取り出すことを担う。

【0078】

アフィニティキー
次に、ユーザセッションの統一されたビューをユーザに提供するための解決法を、さらに詳細に説明する。

【0079】

セッション中は、ユーザは、同じESBを介してシステムに入る。好ましくは、エントリポイントを形成するESBは、主要ESBであり、このセッションの最後までセッションを担当する。

【0080】

システムに入来する各トランザクションにつき、主要ESBは、分散コンテキストコリレータ(DCX、Distributed Context Correlator)と呼ばれるレコードを作成する。

【0081】

DCXは、一意のユーザセッションに専用とされる。DCXは、主要ESBにおいて記憶される。DCXは、参照を含む。参照は、所与のソフトウェアアプリケーションまたはソフトウェアアプリケーションセットについて、どのアプリケーションサーバがユーザコンテキストを保持しているかを識別する。この参照を、アフィニティキーと呼ぶ。各ESBはシステムのトポロジを知っているので、ESBは、DCXのアフィニティキーを読み取ることにより、セッションとのアフィニティを有するアプリケーションサーバ、すなわち、ユーザコンテキストの部分を記憶するデータ記憶手段を使用するアプリケーションサーバを、ターゲットにすることができる。したがって、ユーザのコンテキスト全体が多数の独立したマシンにわたり広がっている場合であっても、ユーザのコンテキスト全体にアクセスすることができる。

【0082】

DCXは、各トランザクションに追加される。DCXは、2つのアプリケーションサーバ間の全てのトランザクションにカスケードされる。あるアプリケーションサーバが別のアプリケーションサーバを呼び出すとき、この別のアプリケーションサーバにDCXが送信される。このような、あるアプリケーションサーバが別のアプリケーションサーバを呼び出すトランザクションを、コラテラル(collateral)呼出しまたはコラテラルトランザクションと呼ぶ。

【0083】

DCXを受け取った各アプリケーションサーバは、前記アプリケーションサーバがその記憶手段に記憶されたユーザコンテキストの部分を取り出すのを可能にする追加の情報で、DCXを拡充できることが好ましい。したがって、次にアプリケーションサーバがこのセッションのトランザクションを受け取ったとき、アプリケーションサーバは、単にDCXのこの情報を読み取ることによって、また、このトランザクションの送出元である他のアプリケーションサーバがどこであっても、このセッションについてのユーザコンテキストの部分を容易に取り出すことができるようになる。本発明では、DCXに記憶されるこの情報を、アプリカティブコンテキストキーと呼ぶ。

【0084】

このように、DCXは、それが帰属するセッションの参照と、このセッションとのアフィニティを有するアプリケーションサーバをターゲットにするためのアフィニティキーと、各アプリケーションサーバがそのユーザコンテキストの部分を取り出せるようにするためのアプリカティブコンテキストキーとを含む。

【0085】

アプリカティブコンテキストキー
DCXはまた、一意の識別子も含む。特定の一実施形態によれば、特定の参照を使用する代わりに、この一意の識別子を使用してサブアプリカティブコンテキストを参照することができる。したがって、アプリケーションサーバは、それら自体のアプリカティブコンテキストキーを作成して記憶する代わりに、この一意の識別子を暗黙的なアプリカティブコンテキストキーとして使用することができる。このような場合、アプリケーションコンテキストは、記憶手段中で一意の識別子で索引付けされる。したがって、DCXは、より少ない情報を含むが、なお、アプリケーションサーバがそれらのユーザコンテキストの部分を取り出すのを可能にする。

【0086】

有利にも、DCXは、トランザクションにおいて使用される通信プロトコルから独立して、任意のトランザクションに対して利用可能である。

【0087】

したがって、ソフトウェアアプリケーションが呼び出されるときはいつでも、トランザクションを受け取ったESBは、このトランザクションが、このセッションとのアフィニティを有するアプリケーションサーバにルーティングされることを必要とするかどうか判定する。

【0088】

アフィニティが必要とされる場合、すなわち、このソフトウェアアプリケーションに関連するユーザコンテキストの部分を保持するアプリケーションサーバにトランザクションがルーティングされる必要がある場合は、ESBは、このアプリケーションサーバをターゲットにしなければならない。このために、ESBは、DCXのアフィニティキーを読み取り、該当するアプリケーションサーバを識別する。

【0089】

次いで、前記該当するアプリケーションサーバは、トランザクションおよびDCXを受け取る。次いで、このアプリケーションサーバは、アプリケーションコンテキストキーを読み取って、トランザクションを処理するのに必要とされるユーザコンテキストの部分を取り出すことができる。

【0090】

ESBに到達したトランザクションによってアフィニティが必要とされない場合は、呼び出されたソフトウェアアプリケーションを処理するアプリケーションサーバグループのうちの特定のアプリケーションサーバに、前記トランザクションをルーティングする必要はない。

【0091】

例えばこれは、それ自体のユーザコンテキストの部分を生成するソフトウェアアプリケーションの場合に、かつ、前記ソフトウェアアプリケーションを処理するアプリケーションサーバが、このセッションに関係するトランザクションを初めて受け取ったときに、生じる。この最初のトランザクションの前には、前記アプリケーションサーバによってどんなユーザコンテキストの部分も生み出されていない。典型的な一例は、アプリケーションサーバが、所与のパラメータ(日付/出発地/到着地)について、入手可能なフライトを取り出そうとする使用事例に関するものである。これらのパラメータを受け取る前は、アプリケーションサーバは、このセッションについてどんなコンテキストも保持していない。しかし、最初の処理の後は、前記アプリケーションサーバは、取り出されたフライトをその専用の記憶手段に記憶し、それによりユーザコンテキストの部分を生み出す。

【0092】

次いで、このアプリケーションサーバとセッションとの間に、アフィニティが生み出される。アプリケーションサーバは、アフィニティキーでDCXを拡充する。このアフィニティキーによってさらに、あらゆるESBがこのアプリケーションサーバをターゲットにすることができるようになる。アプリケーションサーバはまた、アプリカティブコンテキストキーでDCXを拡充することが好ましく、このアプリカティブコンテキストキーにより、アプリケーションサーバは、次にこのセッションのトランザクションを受け取ったときに、入手可能なフライトを取り出すことができるようになる。

【0093】

DCXが拡充されると、DCXは、返信パスを使用して主要ESBに返送され、そこで記憶される。

【0094】

アフィニティが必要とされない別の例は、セッションに関係するどんなデータも記憶する必要がないソフトウェアアプリケーションに関するものである。例えば、このようなソフトウェアアプリケーションは、メッセージのフォーマットを別のプロトコルに適するように修正することを可能にする。メッセージが変換されると、次いでメッセージは伝搬されるが、フォーマット変換を実施したアプリケーションサーバにおいて記憶される必要はない。この場合、DCXは、このソフトウェアアプリケーションについてのどんなアフィニティキーで拡充されることもない。

【0095】

ESBが、トランザクションを受け取り、このトランザクションがアフィニティを必要としないと判定したとき、ESBは、トランザクションのルーティング先となるアプリケーションサーバを決定する。通常、ESBは、負荷平衡または近接パラメータを考慮に入れる。

【0096】

次に、例示的な使用事例を示す図2を参照しながら、本発明を説明する。

【0097】

明確にするために、図2では、ユーザUaのみが表されている。セッションの初めには、ユーザコンテキストはない。この実施形態では、システムは、複数のESB10、11、12を備える。ESBは、アプリケーションサーバ上での各処理後にトランザクションがESBに到達するように構成される。

【0098】

ユーザUaは、セッションを開始し、ESB10を介してシステムに入る。したがって、ESB10は、このセッションについての主要ESBである。ユーザUaは、ユーザコンテキストの部分a₀を形成する情報を、主要ESB10に提供する。主要ESB10は、ユーザコンテキストの部分a₀を保持する。通常、a₀は、主要ESBに記憶されたDCXを含むかまたはDCXである。ESB10は、ソフトウェアアプリケーションAが呼び出されると決定する。ESB10は、アフィニティが要求されるかどうか判定する。アフィニティがこの段階で要求され、かつDCXがソフトウェアアプリケーションAについてのどんなアフィニティキーも含まないときは、ESBは、ソフトウェアアプリケーションAを処理するアプリケーションサーバのグループのうちの、いずれか1つのアプリケーションサーバを選択する。この例では、アプリケーションサーバA3が選択される。主要ESB10は、アプリケーションサーバA3にトランザクション(トランザクション1)を送る(ステップ201)。アプリケーションサーバA3は、トランザクションを処理し、ユーザコンテキストの部分a1を生成し、A3が稼動しているマシンのデータ記憶手段にa1を記憶する。主要ESBはまた、アフィニティキーでDCXを拡充する。このアフィニティキーにより、任意のESBが、このセッションについてソフトウェアアプリケーションAが呼び出されたときにターゲットアプリケーションサーバA3をさらにターゲットにすることができるようになる。アフィニティの要求は、ESB構成の一部である。トランザクションパラメータ(ESBに到達するトランザクションのソース、宛先、ソフトウェアアプリケーションなど)に基づいて、このESBはその構成により、アフィニティを考慮してトランザクションを処理しなければならないかどうか判定することができる。したがって、アフィニティが要求されるかどうか判定するために、静的な情報(ESBの構成)が考慮される。一方、DCXの内容は、動的な情報である。

【0099】

アプリケーションサーバA3は、アプリケーションコンテキストキーをDCXに追加するのが好ましく、このアプリケーションコンテキストキーによってさらに、アプリケーションサーバA3は、次にこのセッションのトランザクションを受け取ったときにコンテキストの部分a₁を容易に取り出すことができるようになる。

【0100】

次いで、DCXは主要ESB10に返され、そこで記憶される。ESB11が、アプリケーションサーバA3からトランザクションを受け取り、ソフトウェアアプリケーションAによってソフトウェアアプリケーションBが呼び出されると決定する(ステップ202)。このような呼出しは、コラテラル呼出しまたはコラテラルトランザクションである。ソフトウェアアプリケーションBによってアフィニティが要求されるが、アプリケーションBについてのアフィニティがDCXに記憶されていないときは、ESB11は、ソフトウェアアプリケーションBを実行するアプリケーションサーバのグループのうちの、いずれか1つのアプリケーションサーバを選択することができる。ESB11は、アプリケーションサーバB8を選択し、B8に対応するアフィニティキーでDCXを拡充し、トランザクション1の処理に必要とされるコラテラルトランザクションがアプリケーションサーバB8に到達する。アプリケーションサーバB8は、トランザクションを処理し、ユーザUaのコンテキストの部分a₂を生み出す。コラテラル呼出しを介して生み出されたユーザコンテキストの部分は、サブコンテキストとも呼ぶ。

【0101】

DCXは、アプリケーションサーバB8に関係するアプリカティブコンテキストキーで拡充される。

【0102】

ソフトウェアアプリケーションAおよびソフトウェアアプリケーションBによって受け取られた呼出し201、202と同様、ソフトウェアアプリケーションCが、アフィニティを求める要求なしで呼び出される(ステップ203)。トランザクション1を処理するために、ソフトウェアアプリケーションCを処理するアプリケーションサーバC4が選択される。アプリケーションサーバC4は、ユーザコンテキストの部分a₃を生み出して、それをそのデータ記憶手段に記憶する。DCXはアフィニティキーで拡充されるが、このアフィニティキーは、ユーザコンテキストの部分a₃を取り出すためにアプリケーションサーバC4をターゲットすることを可能にするものである。DCXは、返信によって主要ESB10に返される。

【0103】

主要ESB10は、ユーザUaから新しいトランザクション(トランザクション2)を受け取る。主要ESB10は、この新しいトランザクションを処理するためにソフトウェアアプリケーションBが呼び出され、かつアフィニティが要求される、と決定する。したがって、サービスBのグループのうち、このサービスに関連するユーザコンテキストの部分を保持するアプリケーションサーバをターゲットにしなければならない。DCXを読み取ることにより、主要ESB10は、サービスBのグループのうちの、このセッションでの該当するアプリケーションサーバの参照を読み取り、したがってアプリケーションサーバB8をターゲットにする。

【0104】

次いで、主要ESB10は、新しいトランザクションをアプリケーションサーバB8にルーティングする(ステップ204)。

【0105】

次いで、アプリケーションサーバB8は、新しいトランザクションを受け取り、そのユーザコンテキストの部分a₃を取り出し、新しいトランザクションを処理することになる。

【0106】

したがって、様々なサーバおよびESBが対話できるようにすることにより、本発明は、セッションのコンテキストが分散されローカルに記憶される一方で、セッションの統一されたビューを提供するための、効率的な解決法を提供する。

【0107】

ユーザコンテキストの部分のコンテキスト寿命
次に、本発明の非限定的だが特に有利な特徴について述べる。これらの特徴により、セッションの間にトランザクションを処理するために最終的に必要とされる可能性のある、ユーザコンテキストのいくつかの部分を、このセッションの間ずっと利用可能に維持することができる。セッションが終わったとき、コンテキストのこれらの部分は除去される。

【0108】

実際、ユーザコンテキストは、セッションの寿命の間だけ有効であることが好ましい。したがって、セッションのコンテキストは永続的ではなく、セッションが終わると、コンテキストはそれ以上記憶されず除去される。

【0109】

例えば、ブッキングを管理するためのユーザセッションのユーザコンテキストにおいて使用されるユーザコンテキストの全ての部分は、ユーザセッションの終わりまで保持される。

【0110】

分散コンテキストコリレータ(DCX)は、ユーザセッションの全寿命の間、利用可能である。ユーザコンテキストの部分を保持するどんなアプリケーションサーバも、そのコンテキストの寿命をユーザセッションの寿命にリンクすることを要求することができる。

【0111】

ユーザコンテキストとユーザセッションは、DCXを保持するESBと、ユーザコンテキストを保持するアプリケーションサーバとの間でステートフルな会話を開くことによって、寿命の点でリンクされる。

【0112】

ステートフルな会話を開く要求は、呼び出されるサービスの一部として、ESB構成において静的に定義される。より正確には、ESBがトランザクションを受け取ったとき、ESBは、トランザクションのソース、宛先、および呼び出されたソフトウェアアプリケーションなど、トランザクションのパラメータを分析する。次いでESBは、その構成により、ステートフルな会話が開かれなければならないかどうか判定することができる。トランザクションがアフィニティを考慮に入れなければならないかどうかの判定にも、同じメカニズムが当てはまる。

【0113】

あるアプリケーションサーバが、別のアプリケーションサーバ上で処理されるサービスまたはソフトウェアアプリケーションを呼び出す場合であって、そのユーザコンテキストの寿命がDCXの寿命にリンクされることを必要とする場合、コラテラルトランザクションのルーティングを担当するESBは、次いで、主要ESBを呼び出し、主要ESBに、前記別のアプリケーションサーバとのステートフルな会話を開くよう求める。次いで主要ESBは、前記別のアプリケーションサーバとのステートフルな会話を開く。次いで、コラテラルトランザクションのルーティングを担当するESBは、主要ESBとのステートフルな会話が開かれた前記別のアプリケーションサーバに、トランザクションをルーティングする。

【0114】

主要ESBと所与のアプリケーションサーバとの間のステートフルな会話は、この所与のアプリケーションサーバにいずれかのトランザクションが行く前に、開いているはずである。この理由は次のとおりである。すなわち、トランザクションが、ステートフルな会話が開かれる前にコラテラルトラフィックによって所与のアプリケーションサーバにルーティングされなければならない場合は、コラテラルトランザクションをルーティングするESBは、ステートフルな会話を開くよう主要ESBに要求した後でトランザクションをアプリケーションサーバにルーティングすることになるからである。この機能を、会話の自動初期化と呼ぶ。

【0115】

このようなステートフルな会話が開かれると、DCXの寿命は、主要ESBとのステートフルな会話中であるアプリケーションサーバが稼動しているマシンに記憶されたユーザコンテキストの寿命にリンクされる。前記ユーザコンテキストは、DCXが消えることになるときにのみ削除されることになる。

【0116】

この解決法により、本発明は、セッション終了時に記憶されているデータを制限しながら、セッション中に利用可能でなければならないコンテキストの全ての部分を維持することを可能にする。加えて、この解決法は、アプリケーションサーバ間で送信されるトラフィックおよびデータのボリュームを制限する。

【0117】

好ましい一実施形態によれば、ステートフルな会話が開いているとき、ESBは、そのステートフルな会話を共有するアプリケーションサーバに、ユーザコンテキストが維持されなければならないことを示すメッセージを定期的に送る。これらのメッセージは、「キープアライブ(keep alive)」メッセージと呼ばれる。したがって、「キープアライブ」メッセージが、主要ESBから、この主要ESBとのステートフルな会話中である全てのアプリケーションサーバに送られる。セッションが終わると、DCXは削除されてよく、主要ESBは、ステートフルな会話中にある全てのアプリケーションサーバに、ユーザコンテキストを削除してよいことを示すメッセージを送る。これらのメッセージを、「終了(terminate)」メッセージと呼ぶ。

【0118】

アプリケーションサーバまたはマシンおよびユーザコンテキストごとに、DCXの主要ESBオーナからのステートフルな会話は1つしかない。全てのコラテラルトランザクションは、大域的なトランザクションがステートフルであっても、ステートレスな会話を使用している。

【0119】

図3に、ステートフルな会話が開いていなければならないトランザクションの第1の例を示す。

【0120】

ユーザUaは、主要ESB10を介してシステムに要求を送る。ステップ301および302は、図2のステップ201および202と同様である。アプリケーションサーバB8がトランザクションを処理すると、ESB12が、トランザクションを受け取り(ステップ303)、このトランザクションのルーティングを担当する。ESB12は、ソフトウェアアプリケーションBによって呼び出されたソフトウェアアプリケーションCが、そのユーザコンテキストの部分の寿命をセッションの寿命にリンクさせることを必要とすると決定する。

【0121】

サービスグループCのどのアプリケーションサーバ上にも顧客Uaのユーザコンテキストの部分がまだ存在しない場合は、トランザクションをサービスグループCにルーティングするのを担当するESB12は、DCXを保持する主要ESB10を呼び出し、主要ESB10に、サービスグループCのうちの1つのアプリケーションサーバとのステートフルな会話を開くよう要求する(ステップ304)。次いで主要ESB10は、サービスグループCのアプリケーションサーバのうちの1つのアプリケーションサーバとのステートフルな会話を開く(ステップ305)。次いでDCXは、選択されたアプリケーションサーバC4の参照で拡充される。次いでDCXは、コラテラルトランザクションのルーティングを担当するESB12に返される。次いでESB12は、DCXを読み出すことによってアプリケーションサーバC4をターゲットにし、主要ESBとの会話中にあるアプリケーションサーバC4にトランザクションをルーティングする(ステップ306)。

【0122】

図4に、ステートフルな会話が開かれていなければならないトランザクションの別の例を示す。

【0123】

ステップ401で、主要ESBは、グラフィカルユーザインタフェース(GUI)を介してユーザからの要求を受け取る。例えば、この要求は、乗客ファイルの作成である。この要求のプロトコルはHTMLである。システムによって処理されるためには、要求は、EDIFACTプロトコルなど、別のプロトコルに変換されなければならない。主要ESBは、要求を変換するために、ソフトウェアアプリケーションAを処理するアプリケーションサーバのグループのうちのアプリケーションサーバをターゲットにしなければならないと決定する。このような変換には、アフィニティは必要とされない。次いで主要ESBは、サービスAのグループのうちのアプリケーションサーバを選択し、このアプリケーションサーバにトランザクションをルーティングする(ステップ402)。このアプリケーションサーバをA1と呼ぶ。

【0124】

A1は、プロトコルを変換することによってトランザクションを処理する。A1によって記憶されなければならないデータはない。したがって、A1においてユーザコンテキストの部分は生み出されない。主要ESBとA1との間の会話は、ステートレスである。

【0125】

次いで、ESB(コラテラルESB(ESB Col)とも呼ぶ)が、トランザクションを受け取る(ステップ403)。コラテラルESBは、ソフトウェアアプリケーションBを処理するアプリケーションサーバにトランザクションがルーティングされなければならないと決定する。コラテラルESBはまた、アフィニティが要求されること、および、次の処理を担当するアプリケーションサーバに関連するコンテキストの部分の寿命がセッションの寿命にリンクされなければならなくなることを決定する。コラテラルESBは、DCXを読み取り、DCX中でソフトウェアアプリケーションBについてアフィニティが設定されていないと判定する(ステップ404)。次いでコラテラルESBは、主要ESBを呼び出し、主要ESBに、ソフトウェアアプリケーションBを処理するアプリケーションとのステートフルな会話を開くよう要求する(ステップ405)。主要ESBは、ソフトウェアアプリケーションBを処理するのに専用に充てられたアプリケーションサーバ(B2と呼ぶ)を選択する。主要ESBは、B2に対応するアフィニティキーでDCXを拡充し(ステップ406)、アフィニティ初期化の要求をこのアプリケーションサーバに転送する(ステップ407)。したがって、B2には、そのユーザコンテキストの部分の寿命がセッションの寿命にリンクされなければならないことが通知される(ステップ405)。B2は、そのデータ記憶手段の一部をユーザコンテキストの部分に割り振る(ステップ408)。B2は、アプリカティブコンテキストキーでDCXを拡充し、DCXを主要ESBに返送する(ステップ409)。DCXは、主要ESBにおいて記憶され、コラテラルESBに返送される(ステップ410)。

【0126】

コラテラルESBは、元のメッセージを取り出し、このメッセージを新しいDCXで更新し、DCXのアフィニティキーに従ってアプリケーションサーバB2をターゲットにする(ステップ411)。したがって、トランザクションはB2にルーティングされる(ステップ411)。次いでB2は、EDIFACTプロトコルで要求を受け取り、要求を処理する。例えば、要求は、乗客ファイルの作成に存するものとすることができる。

【0127】

B2のユーザコンテキストの部分の寿命がセッションの寿命にリンクされているので、乗客ファイルは、セッションの全タイムライフの間はB2において利用可能であることになり、その後は削除されることになる。

【0128】

図5に、本発明の別の使用事例を示す。この例示的な使用事例では、ESB10は、複数のマルチプレクサ(MUX1、MUX2、MUX3)と、マルチプレクサX3に関連する少なくともサーバ(SRV2)とを備える。

【0129】

ステップ501で、ユーザがサーバSRV2に要求を送る。サーバSRV2は、このセッションについてのDCXレコードを作成する。

【0130】

セッションが開始した直後は、利用可能なコンテキストはまだなく、ソフトウェアアプリケーションAを処理するアプリケーションサーバA1が呼び出され、アプリケーションサーバA1は、トランザクションをDCXと共に受け取る。DCXは、このアプリケーションサーバA1のアフィニティキーで拡充される。したがって、ソフトウェアアプリケーションAについてのアフィニティが設定される(ステップ502)。A1は、トランザクションを処理し、そのユーザコンテキストの部分を記憶し、そのアプリカティブコンテキストキーでDCXを拡充する。例えば、ユーザコンテキストはフライト空席に関係し、A1は、入手可能なフライトの参照を取り出すことを担当する。次いでDCXは、主要ESB10に返送され(ステップ503)記憶される(ステップ504)。ステップ505で、A1の処理の結果(入手可能なフライトの参照)がユーザに提供される。これにより、このセッションの最初のトランザクションが終了する。

【0131】

次いで、ユーザは別のトランザクションを開始する。例えば、ユーザは、トランザクション1を介して取り出されたフライトのうちの1つのセグメントを購入したいと望む。

【0132】

SRV2は、購入要求を受け取り、ソフトウェアアプリケーションBが呼び出されなければならないと決定する(ステップ506)。次いで、サービスBのグループのうちのアプリケーションサーバB1とのアフィニティが作成される。このアプリケーションサーバB1にDCXが送られる(ステップ507)。B1についてのアプリカティブコンテキストキーも作成される(508)。次いでDCXは、ソフトウェアアプリケーションBを処理するアプリケーションサーバから来る全てのトランザクションを扱うことを担当するマルチプレクサMUX1を介して、カスケードされる(ステップ509)。MUX1は、アフィニティの要求付きでソフトウェアアプリケーションAが呼び出されると決定する。DCXにより、MUX1は、A1をターゲットにすることができる(ステップ510)。A1は、そのアプリカティブコンテキストキーにより、前のトランザクションの間に記憶されたそのコンテキストの部分(入手可能なフライトの参照)を取り出す。次いでA1は、トランザクションをDCXと共にMUX1に返送する(ステップ511)。A1からの返信は、ESBによってB1に返される(ステップ512)。B1は、A1から取り出されたデータにより、トランザクションを処理する。例えば、入手可能なセグメントに価格が付けられる。DCXは、カスケードされ(ステップ513)、処理の結果と共に主要ESBに送られる(ステップ514)。DCXは記憶される。処理の結果はユーザに提供される(ステップ515)。

【産業上の利用可能性】

【0133】

上記に詳述したように、本発明は、システムのモジュール性を保持して処理容量の増大を容易にするとともに、新しいサービス/製品の容易な統合を可能にして、一貫性があり統一されたユーザコンテキストのビューを提供するための、解決法をもたらす。

【0134】

本発明はまた、様々なソフトウェアアプリケーションを含む大域的な製品の各下位部分に割り振られたリソースをより容易に制御できるようにするので、操作性の点で大きな利点をもたらす。本発明はまた、所与のマシンまたは1組のマシン上の停止が他のマシンに著しく影響を及ぼすことがないので、全体的な停止のリスクを最小限に抑えることも可能にする。

【0135】

以上の記述では、本発明の例示的な実施形態を実現するための様々な方法、装置、およびコンピュータプログラムソフトウェアに関する完全で有益な記述を、例示的かつ非限定的な例として提供した。しかし、以上の記述を添付の図面および添付の特許請求の範囲と共に読めば、様々な修正および適応が当業者には明らかになるであろう。いくつかの例に過ぎないが、他の類似のまたは等価なデータ構造および論理フローの使用を、当業者によって試みることもできる。しかし、本発明の教示のこのような修正および類似の修正もなお、本発明の実施形態の範囲に入ることになる。

【0136】

さらに、本発明の例示的な実施形態の特徴のいくつかは、他の特徴の対応する使用なしで有利に使用することができる。したがって、以上の記述は、本発明の原理、教示、および実施形態の限定において考えるのではなく、これらの例示に過ぎないと考えるべきである。

【符号の説明】

【0137】

1 ユーザUa
2 ユーザUb
3 ユーザUc
10 ESB
11 ESB
12 ESB
20 アプリケーションサーバのグループ
30 アプリケーションサーバのグループ
40 アプリケーションサーバのグループ
50 アプリケーションサーバのグループ
100 システム
A1、A2、...、A12 アプリケーションサーバ
B1、B2、...、B8 アプリケーションサーバ
C1、C2、C3 アプリケーションサーバ
D1、D2、D3、D4 アプリケーションサーバ

【図5】

【図1】

【図2】

【図3】

【図4】