JP2008523483A - オン・デマンド・メッセージベースの金融ネットワーク統合ミドルウェア - Google Patents

Abstract

【課題】
【解決手段】本発明は、分散型ネットワーキングに関し、詳細には、メッセージベースのネットワーキング環境に関する。より詳細には、所定のロード・スケジュール内で何らかのミドルウェア（２７０）を介してネットワークにアクセスするビジネス・アプリケーション（１１０、１１２、１１４）に関する。
従来技術の不利な点を軽減するために、
ａ）現在のワークロードをモニタして測定するステップ、
ｂ）測定したワークロード・データを第１の適切なデータ・ストア（２８２）内に保存するステップ、
ｃ）複数の現在使用されているインスタンスに関する状態情報データを第２の適切なデータ・ストア（２４２、２４４、２４６）内に保存するステップ、
ｄ）前記保存された測定済みのワークロード・データおよび前記状態情報の双方を、所定のクォリティーオブサービス・ポリシーに準拠しているか分析するステップ、
ｅ）ワークロードを満たすために使用できるインスタンス（２２２、２２４、２２６）の数を、前記所定のクォリティーオブサービス・ポリシーによって必要とされるワークロードのニーズに適合させるステップという一連のステップを有する方法を実行することが提案されており、
ｆ）この方法においては、新たに作成されたインスタンスのメタ・データが、複数のメッセージ・ストア（２４２、２４４、２４６）内で管理され、そのデータ・コンテンツが、複数のクライアント・アプリケーション（１１０、１１２、１１４）を、それらのオペレーション中に特定のサービス・インスタンス（２２２、２２４、２２６）へ固定された結び付きから切り離すために頻繁に同期化される。
【選択図】図３

Description

本発明は、分散型ネットワーキングに関し、詳細には、メッセージベースのネットワーキング環境に関する。より詳細には、所定のロード・スケジュール内で何らかのミドルウェアを介してネットワークにアクセスするビジネス・アプリケーションに関する。ウェブベースのテクノロジにも関連している。

本発明への導入を行うために、用語に関する以降の説明が最初に提供される。

下記の用語は、http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci750567,00.htmlから明らかなものである。
「ウェブ・サービス」（アプリケーション・サービスと呼ばれる場合もある）は、ウェブ・ユーザ用のビジネスのウェブ・サーバまたはその他のウェブに接続されたプログラムから利用可能にされるサービスである（通常は、プログラミングとデータとの何らかの組合せを含むが、場合によっては、人的リソースも含む）。ウェブ・サービスのプロバイダーは、一般にアプリケーション・サービス・プロバイダーとして知られている。ウェブ・サービスは、ストレージ管理およびＣＲＭ（customer relationship management）などの広範なサービスから、株価情報の提供およびオークション・アイテムに対する入札のチェックなどのよりいっそう限定されたサービスまでの範囲にわたる。これらのサービスがますます生み出されて利用可能になっていくことが、ウェブの大きなトレンドである。
ユーザは、中央のサーバに行くのではなく、ピアツーピアの構成を通じて、いくつかのウェブ・サービスにアクセスすることができる。いくつかのサービスは、その他のサービスと通信することができ、このプロシージャおよびデータの交換は一般に、ミドルウェアとして知られている一種のソフトウェアによって可能になる。これまではＥＤＩ（Electronic Data Interchange）として知られている古い標準化されたサービスを用いてのみ可能であったサービスが、ウェブ・サービスになる可能性がますます高まっている。インターネットそのもののユーザおよびビジネスにとって標準化されて幅広く利用可能であることに加えて、ウェブ・サービスはまた、データ・フォーマットを標準化してデータを交換するための手段としてＸＭＬ（ExtensibleMarkup Language）を使用することによって、ますます可能になっている。ＸＭＬは、ＷＳＤＬ（Web Services DescriptionLanguage）にとっての土台である。

メッセージ・ブローカ：
公式に規定されたメッセージを交換することによって（すなわち、メッセージングという行為を通じて）プログラムどうしが通信する電気通信ネットワークにおいては、メッセージ・ブローカは、メッセージを送信側の公式のメッセージング・プロトコルから受信側の公式のメッセージング・プロトコルへと変換する中間のプログラムである。メッセージ・ブローカ・プログラムは、ミドルウェアとして知られている場合もある。

自律的な管理：
http://www.research.ibm.com/journal/sj/421/ganek.pdf：
この記事においては、今後のＩＢＭの次代を担うコンピューティングのためのイニシアチブを確立するシステム開発における今後のトレンドに関する概要が提供されている。
しかし、そこで言及されている自律的な管理技術は、コンピューティング・リソースの管理を自動化する傾向がある。これは、システム・コントロール、リソース・シェアリング、およびオペレーショナル・マネージメントの複雑さの分野におけるこれまでの取り組みの上に加わる次なる進化のステップとみなされている。自律的な管理技術は、不利なことに、処理状態を把握する動的なインスタンス（stateful dynamicinstance）、仮想化されたサービス、および顧客の要求に基づくオペレーショナル・メッセージ・ストア（operational message store）の連携には対処しておらず、これに対処できれば、オンデマンド・コンピューティングの分野において役立つであろう。

仮想化されたサービス：
http://news.webhosting.info/printthread.php?t=1306では、下記のことが開示されている：
「Egenera（ＴＭ） BladeFrame（Ｒ）システムのユニークなアーキテクチャは、サーバ・リソースのプールを作成することによってデータ・センタ・インフラストラクチャを仮想化し、そのプールから、非公開の保護された構成を動的に割り当ててアプリケーションをサポートし、そして必要に応じて解体することができる。このアプローチを用いれば、サーバのキャパシティを個々のアプリケーションの専用にする必要がなくなり、サービスは、特定のハードウェアまたはネットワーク・パスに拘束されない。結果として、ＳＡＶＶＩＳの顧客は、自分たちが利用するリソースに対してのみ支払いを行い、レガシー・システムによって必要とされる高価で過度な提供を伴わずに、高可用性、障害回復、リアルタイムの拡張性などの強力な機能にアクセスすることができる。」
Egenera BladeFrameシステムは、ＭＡＰＥ（Monitor, Analyze,Plan, and Execute）機能などの自律的な管理設備を提供しない。リソースの動的な割り当ては、不利なことに、完全には自動化されておらず、人間の介入を必要とする。

動的なインスタンス：
http://www.globus.org/wsrf/specs/ws-wsrf.pdfでは、ＷＳ（Web service）リソースの構成が、処理状態を把握するリソースとウェブ・サービスとの間における関係を表すための手段に的を絞って考察されている。この開示には、自律的な管理に必要な技術も、オペレーショナル・メッセージ・ストアのオペレーションも含まれておらず、それらがあれば、オンデマンド・コンピューティングの分野において役立つであろう。

前述の分野においては、本発明は、ネットワーク化された環境に対して特別な機器を有し、そうしたネットワーク化された環境では、応答時間が確実に短くなければならず、システムの可用性が保証されなければならず、必要とされるビジネスを行うために広範なメッセージ・スループットが実現される。その好例は、ＩＴ（information technology）環境においてウェブ・サービスを介して提供される金融サービスに関するものであり、その基本的なシステム構造の概要が、図１に示されている。

複数のカスタム・アプリケーション１１０、１１２、１１４が、銀行のビジネス・リソースに接続されている。これらは、他の銀行および取引機関に接続されている安全なバンキング・ネットワーク１５０を含むことによって、送金や株式の取引などの要求されたユーザ・サービスを実行するためにユーザの要求を銀行のＩＴ環境に提供するために使用される。バンキング・システム環境は、図面の中央の部分１０２に示されている。

このような環境は、メッセージ・ブローカ環境を含み、このメッセージ・ブローカ環境は、具体的なそれぞれのメッセージ・フローによって実現される複数のネットワーク接続サービス１０６を関連付けている。それらの例としては、資金振替サービス、有価証券コントローリング・サービス（Security-controlling service）、銀行間でのメッセージングがある。前述のビジネス・アプリケーションは、所定のソフトウェア・インターフェースを介してそれらのサービスにアクセスし、従来技術の待ち行列管理を介した要求の管理を含む。このメッセージング・ミドルウェアは、最新の従来技術においては、アプリケーションとオペレーティング・システムとの間をインターフェースで接続している何らかのミドルウェアを用いてコントロールされる。

従来技術においては、そのようなミドルウェアは、ビジネスのピーク・ロードによって含まれるトラフィックの所与のニーズを満たすためにいくつのリソース１０４が使用可能であるかを規定する。ピーク・ロードは、ＱｏＳ（Quality of Service）の所定のスケジュール内で規定されたルールに従って所望のサービスを実行するのに必要とされる事前に割り当てられるリソースの数を決定する。そのようなスケジュールは、下記の基本的なルールおよび要件を含むことができる。というのは、それらが、エレクトロニック・バンキングの従来技術から公知であるためである。エレクトロニック・バンキングの分野における一般的なヒューリスティックスから得られる典型的なルールは、カレンダ・スケジュールである。このアプローチの２つの変形形態は、下記のものとすることができる：
１．アカウントの年度決算：
１分あたりのオンライン・トランザクションの数：＞８００
２．アカウントの四半期決算：
１分あたりのオンライン・トランザクションの数：＞８００
たとえば、ＣＰＵのパワーおよびディスク・ストレージの容量に関する所与のニーズを提供する最大数のハードウェア・サーバは、ビジネスを行うためのそれぞれの最大数のサービスのインスタンス化を実行するために事前に使用されている。
したがって、利用可能な処理リソースは、ピーク・ワークロードの要件に適合するような大きさでなければならない。結果として、リソースは、許容可能なパフォーマンスおよび可用性の特徴を伴ったメッセージ・スループットおよびサービスの提供を確実にするために、著しく過度に提供される。これらのリソースは通常、小規模から中規模のメッセージ・トラフィックの間には利用されないままである。

不利な点は、静的なリソースの割り当てというこの固定的なコンセプトが、変動するロードに柔軟に対応しないという点である。したがって、小規模なトラフィックの間には、多くのハードウェア・リソースが結び付いているが、それらは使用されないままである。ピーク・ロードの間にのみ、良好なシステム効率が行き渡る。
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci750567,00.html http://www.research.ibm.com/journal/sj/421/ganek.pdf http://news.webhosting.info/printthread.php?t=1306 http://www.globus.org/wsrf/specs/ws-wsrf.pdf http://www-1.ibm.com/support/docview.wss?uid=pub1sc34606102に開示されているWebSphere MQ Queue Manager Clusters, SC34-6061

したがって本発明の目的は、複数のクライアント・アプリケーションがそれぞれのネットワーク化されたサービスを介してネットワーク・リソースを使用するネットワーキング環境においてメッセージベースのワークロードを管理するための方法およびそれぞれのシステムを提供することであり、この方法によって、上述の不利な点が軽減され、リソースを使用する際の効率が高まる。

本発明のこの目的は、同封の独立クレーム内に記載されている機能によって達成される。本発明のさらなる有利な構成および実施形態は、それぞれの従属クレーム内に記載されている。次いで、添付の特許請求の範囲を参照されたい。

本発明は、リソースの利用状況を動的に最適化するという一般的なアイディアに基づく。要求されているサービスの高いレベルを維持する一方で、本発明のメッセージング・ミドルウェアには、自律的な自己管理機能が組み込まれる。この目的から、それぞれのメッセージング・ミドルウェアを含む本発明のシステムは、緊密に結合された一枚岩の全体として構築されるのではなく、ネットワーク接続されたコンポーネントの集合体から構成される。その時点のワークロードの必要に応じて、さらなるコンポーネントを複製または追加することができる。

ピーク・メッセージ・トラフィックの間には、この仮想化によって、ミドルウェアは、システムの複数の時分割方式の動的な論理インスタンス（multiple time-shared, dynamic logical instances of the system）を同じサービス・インターフェース上に提供することができる。ワークロードが少なくなってくると、インスタンスの数をそれぞれ減らすことができる。この利点の結果、システム・リソースは、動的に変動するワークロードによりよく適合する。

したがって本発明は、その最も基本的な態様によれば、ネットワーキング環境内でワークロードを管理する方法を開示し、この方法においては、複数のクライアント・アプリケーションが、それぞれのサービス・インスタンスを介してネットワーク・リソースを使用し、この方法は、
ａ）現在のワークロードをモニタして測定するステップと、
ｂ）測定したワークロード・データを第１の適切なデータ・ストア内に保存するステップと、
ｃ）複数の現在使用されているサービス・インスタンスに関する状態情報を第２の適切なデータ・ストア内に保存するステップと、
ｄ）前記保存された測定済みのワークロード・データおよび前記状態情報の双方を、所定のクォリティーオブサービス・ポリシーに準拠しているか分析するステップと、
ｅ）ワークロードを満たすために使用できるサービス・インスタンスの数を、前記所定のクォリティーオブサービス・ポリシーによって必要とされるワークロードのニーズに適合させるステップとによって特徴付けられ、
ｆ）前記サービス・インスタンスのメタ・データが、新たに作成されたものか、既存のものかを問わず、メッセージ・ストア内で管理され、そのデータ・コンテンツが、複数のクライアント・アプリケーションを、それらのオペレーション中に固定された特定のサービス・インスタンスへの結び付きから切り離すために同期化される。

せいぜい約１０〜２０個の動的なインスタンスを管理する比較的小さなシステムの場合には、単一のメッセージ・ストア・データベースをホストする単一のサーバを使用することが好ましいかもしれない。単一の動的なインスタンスを管理するためには、それぞれの単一のサーバによってホストされる１つのメッセージ・ストアを使用することが好ましい。

本発明のコンセプトおよび制約によって暗に示されているところによると、アプリケーションは、そのライフタイムの間にさまざまな論理インスタンスに関連し、それぞれのアプリケーションが、正しく割り当てられたサービス・インスタンスおよび物理的なリソースを使用できることを保証するためには、前記メタ・データを同期化しなければならない。

より大きなシステムの場合には、すべてのメッセージ・ストアを同期化するためにアクセス時間をできるだけ短くしておくには、自前の別個のメッセージ・ストア、すなわち単一のインスタンスのみの専用で、かつそれぞれの単一のサーバによってホストされるデータベース内にそれぞれのインスタンスの状態情報を保存して管理することが好ましい。

本発明は、例示として図示され、図面の各図の形状には限定されない。

各図を全体的に参照し、次いで特に図２を参照すると、本発明の原理を抽象的な論理レベルで示す概略図が最初に提供される。

図２は、本発明によって提供されるミドルウェアの一般的な機能に関する概観を提供する。リソース・コントロール・インターフェース２１０およびサービス・インターフェース２１５は、アプリケーション１１０、１１２、１１４のために、およびＭＡＰＥモジュール２８０のために、オペレーショナル・メッセージ・ストア２４２、２４４、２４６にアクセスする機能を提供する。アダプタ実装２２０は、メッセージ・ストアにアクセスするために必要なすべての詳細を実装するために、このミドルウェアの内部に提供される。これは、ストレージ・アクセス・プロセスを呼び出す前記アプリケーション１１０、１１２、１１４の従来技術のソフトウェア・インターフェースを変更する必要がないように実装されることが好ましい。

本発明によれば、本発明のメッセージング・ミドルウェアの上述のネットワーク接続コンポーネントは、要求／応答の対話パターンを使用するサービスとして提供される。それぞれのアダプタ実装を前記サービス・インターフェース５１５の後ろに上述のように「隠す」ことによって、基礎をなすサポートされているビジネス・ネットワークなど、物理的なリソースおよびレガシー・リソースへの接続が、実装の詳細をあらわにすることなく提供される。

各図を全体的に参照し、次いで特に図３を参照すると、本発明の方法の好ましい一実施形態の特に好ましい使用法が記載されており、ここでは、ネットワーキング環境はバンキング・アプリケーションを含む。

仮想化されたサービスおよび動的なインスタンスの下記の好ましい実装は、ウェブ・サービスと処理状態を把握するリソースとの間における関係を体系化する特定のパターンに依存する。一例として、この実装は、ＯＧＳＡ（Open Grid Services Architecture）に加わる。

ＯＧＳＡは、サービス・バンドル（service bundle）をＯＧＳＩ（OpenGrid Service Infrastructure）コンポーネントの動作モデルに準拠させることによって遵守される。このセクションに記載されている本発明の方法の特定の使用においては、本発明のワークロード・マネージャ２７０内に実装される本発明の金融メッセージング・ミドルウェアは、ＯＧＳＡインフラストラクチャの仕様の利点を享受し、このＯＧＳＡインフラストラクチャの仕様は、処理状態を把握するインスタンスを管理するための共通の基本的な機能の一貫したセットを提供し、メッセージベースのイベント・フレームワーク、ならびに要求側とサービスとの対話を規定および標準化するインターフェースの定義を提供する。

典型的なユーザ・プロセスは、銀行の顧客によってそれぞれのユーザ端末から上述のカスタム・アプリケーション１１０、１１２、１１４を使用して指示される資金振替と想定される。

安全なバンキング・ネットワーク１５０が、やはり左に示されている。「オートノミック・マネージャ」と呼ばれる本発明のミドルウェア２７０が、図面の中央の部分に示されている。

従来技術において知られている上述の動的なメッセージング・サービスは、図面の中央の部分に示されている本発明の手段をインストールしている顧客の銀行から前記バンキング・ネットワーク１５０を介してそれぞれの送金先の銀行へ前記資金振替の金融情報をメッセージングするために使用される。

より詳細には、本発明の好ましい特徴によれば、メッセージをそのそれぞれの送信者、宛先、ファイル番号、転送ＩＤなどに関連付けるために必要とされるメッセージおよびメタ情報を保存するために、オペレーショナル・メッセージ・ストア２４２、２４４、２４６が、それぞれのデータベース・サーバ上に提供され、必要に応じてより大きな地理的領域にわたって分散される。これについては、以降で図５を参照して詳述する。

動的に変動するトラフィック・ロードの中で所定のサービス・レベル・ポリシーを実行するために、本発明のミドルウェアは、前記オートノミック・マネージャ・コンポーネント２７０を含み、このオートノミック・マネージャ・コンポーネント２７０は、Monitoring、Analyzing、Planning、およびExecutionの機能（本明細書では、ＭＡＰＥ機能と呼ぶ）を指定する本発明のワークロード適合方法を提供するためにハードウェアおよびソフトウェア・リソース２８０を効果的に実装する。これは、本発明のコンセプトにとって、リソースを使用する際の効率を高めるために、測定されたトラフィック・ロードと、サービスおよび動的なインスタンスの動的な割り当ておよび割り当て解除を行うためのそれぞれのコントロールとの間においてフィードバックループを実現するために必要とされる。

本発明のＭＡＰＥ機能は、下記のように実行されることが好ましい：
パフォーマンス・データやメッセージ待ち行列の深さのような生のメッセージ処理情報が、図３の円２８０内に「Ｍ」として示されているモニタリング・サービス２８１によって収集され、モニタリング・サービス２８１は、結果として生じるデータをそれぞれの知識ベース２８２内に保存し、この知識ベース２８２は、リレーショナル・データベースとすることができ、現在のシステムの動作が、それぞれのさらなるプログラム・モジュール「Ｐ」（これについても、円２８０を参照されたい）を用いて確立されているポリシーに準拠しているかどうかを評価するために、やはり前記円２８０内に示されているそれぞれのプログラム・モジュール「Ａ」によって頻繁に分析される。システムの動作が、特にそのパフォーマンスに関して、所定の全体的な目標と整合しない場合には、オートノミック・マネージャ２７０が、設定されたポリシーに従ってアクションのプランを選択し、さらなるプログラム・モジュール「Ｅ」（円２８０を参照されたい）を用いてそれを実行する。この実行は、オペレーショナル・メッセージ・ストア２４２、２４４、２４６の、動的なインスタンス２２２、２２４、２２６の、および仮想化されたサービス２１２、２１４、２１６の動的な管理を含む。

この点において、最適化の決定は、「複製された」インスタンスのプール全体にわたってバランスをとることや、メッセージ待ち行列マネージャのクラスタリングのような従来技術の技法を含めて適用されることが好ましい。

明確にするために、待ち行列マネージャ・クラスタは、１つまたは複数のコンピュータ上における複数の従来技術の待ち行列マネージャのグループであり、自動的な相互接続を提供し、ロード・バランシングおよび冗長性のためにメッセージ待ち行列をそれらの間で共有できるようにする。詳しくは、http://www-1.ibm.com/support/docview.wss?uid=pub1sc34606102に開示されているWebSphere MQ Queue Manager Clusters, SC34-6061を参照されたい。

任意選択で、および好ましくは、メッセージの分類区別、たとえば資金振替および有価証券取引に基づいてワークロードの優先順位付けが実施される。それぞれのＩＤ ４７（これについても、図５を参照されたい）によって識別されるそれぞれのメッセージ・クラス内では、メッセージ・コンテンツ、たとえば資金振替の金額に基づいて相対的な優先順位付けをさらに実現することができる。これによって、より高額の資金振替は、より低額の資金振替よりも高い優先順位で処理することができる。

オートノミック・マネージャ２７０は、最初に受信される顧客の要求よりも前に始動されるということを追記しておきたい。したがって、そのマン／マシン・インターフェース（図示せず）上で始動および停止オペレーションが必要とされる。オートノミック・マネージャの決定論理においては、さまざまなユーザ定義のサービス・ポリシーを確立しなければならないため、設定されたポリシーを展開する（そして、その展開を解く）ためのそれぞれのインターフェースが提供される。そのようなポリシーを特徴付けるデータも、それぞれのデータベース・テーブルにおけるデータベース２８２内に保存されることが好ましい。したがって、アクセスは実行しやすく、ＭＡＰＥ機能は、許容可能なコンピューティング・リソースを必要とする。
次いで、本発明の方法の好ましい一実施形態内における上述の仮想化されたサービス２１２、２１４、２１６の実施、および処理状態を把握する動的なインスタンス２２２、２２４、２２６の管理について、以降で説明する。

本発明の方法は、ＷＳＤＬ（Web Service DescriptionLanguage）および基礎をなすＸＭＬ（Extensible Markup Language）などのウェブ・サービス・テクノロジを使用して、そのメッセージング・サービスを提供する。基礎をなすメッセージング・パラダイムは、メッセージ・フローを管理および実行する能力に大きく依存しているため、一般的な従来技術のメッセージ・ブローカ、たとえば「IBMWebSphere Business Integration Message Broker andIntegrator Tool」が、技術的な基盤として使用され、本発明の特性に適合するように修正される。このブローカ環境はまた、さまざまなサーバ・プラットフォームにわたって共通の実装形態を活用する機会を可能にする。上述のような現況技術のブローカ・プラットフォームの使用を通じて、本発明の方法は、ブローカによって提供されたメッセージ処理「ノード」を通じてＨＴＴＰを介して伝送されるＳＯＡＰ（SimpleObject Access Protocol）でフォーマット設定されたメッセージ上で直接機能する。このプロトコルは、独自仕様のメッセージ待ち行列に基づく従来のインターフェース・スタイルに取って代わるか、またはそうした従来のインターフェース・スタイルを補完する。

仮想化されたサービスの外部インターフェースは、カスタマー・アプリケーション１１２、１１４、１１６から来るすべての要求を満たす。アプリケーション１１０と仮想化されたサービス２１２との間のインターフェースは、下記のように実装することができる：
たとえばアプリケーション１１０は、ＳＯＡＰの仕様に従ってフォーマット設定されたＸＭＬベースの要求メッセージを作成し、ＨＴＴＰを介してその送信先サービス２１２へそのメッセージを送信し、関連する応答メッセージをそのサービスから受信する。

本発明によれば、処理状態を把握する新たな動的なインスタンスが、現在のワークロードに従って作成されたり破棄されたりするため、仮想化されたサービスは、新たに作成または破棄される動的なインスタンス上で動的に機能する能力を有する必要がある。

したがって、オートノミック・マネージャ２７０によってトリガされる、処理状態を把握する動的なインスタンスのインターフェース上で実行される必要不可欠な本発明のオペレーションは、少なくとも下記のcreate( )およびdestroy( )機能のような「コンストラクタ」および「デストラクタ」オペレーションである。疑似コードの形態のＡＰＩが、下記のように提供される：
create( )
{
create unique identifier: dynamic instanceID
create the database associated with thedynamic instance
inform the monitor that virtual service hasto be monitored
connect to database
write initial record to database
return dynamic instance ID
}
destroy(dynamic instance ID)
inform the monitor that virtual serviceshould be removed
destroy the database
return
}
次いで、処理データベース、図３のオペレーショナル・メッセージ・ストア２４２、２４４、２４６のアーキテクチャおよびオペレーションについて、以降で説明する：

たとえば前記金融取引などのトランザクションのプロセスのライフタイムにわたって状態情報を管理するために、および個々のメッセージどうしの間における相関データを管理するために、本発明の方法は、従来技術のソリューションと同様に、有利なことに、ＦＳＭ（finite state machine）と、永続的な処理データベース、すなわち、関連するすべてのメタ・データ、すなわち作成されたすべてのインスタンスのコントロール・データを保存するためにリレーショナル情報およびＸＭＬ情報を含む「アプリケーション・メッセージ・ストア」のようにデータを永久に保存するデータベースとを採用する。
動的な論理インスタンスをこれらの物理的なデータベースに結び付けるのをできるだけ遅らせるために、アプリケーション・データと個々のインスタンスとの緊密な結び付きは、従来技術の分散型データ管理技術を通じて回避される。このような技術は、頻繁にデータを同期化することを通じて、可用性、パフォーマンス、データの質、および時点（point-in-time）に関する要件を満たすために、データを配置および移動するためのメカニズムを含む。

この目的から、この実施形態においては、本発明のミドルウェア・プラットフォーム・コードは、レガシー・プログラミング・モデルによるそのメッセージ・ストアへのアクセスを維持するために従来技術の「IBM DB2 Information Integrator」製品によって提供される「データ・フェデレーション」のコンセプトを使用する。オペレーショナル・データ・ストアは、通常はサイズが限定されているため、複製、キャッシング、または従来技術の「最適化されたストレージ・サブシステムのコピー（optimizedstorage subsystem copy）」などのハードウェアベースのプロトコルのような従来技術の方法を代替方法として検討することができる。これらの従来技術の技法は、それぞれの動的な論理インスタンスが自分自身によるデータ・ストアのコピーにアクセスできるようにし、他のすべてのインスタンスのコピーを更新する際の連携を必要とする。

本発明の方法が機能するための重要な必要条件は、使用中にすべてのメッセージ・ストア２４２、２４４、２４６・・・上に保存されるデータが、それぞれの従来技術のデータベース同期化メカニズムによって、それらのストアの間で十分な頻度で同期化されることである。しかしデータの同期化に関しては、いくつかの代替方法が存在する。

第１に、レプリカ・コントロール・プロトコルを使用することが、データベース・レベルでデータ・ストアを同期化するための代替方法として選択された場合には、トランザクション・アトミシティによって、トランザクション、たとえば金融メッセージ交換のステータスに対する更新が保証され、すべての論理インスタンス、すなわち動的なインスタンス２２２、２２４、２２６上で同時に実行される。

応答時間を短くしておくために、従来技術の「IBM DatabasePropagator」製品内に実装されている「遅延」複製スキーム（“lazy” replication scheme）が、トランザクションの終了後に変更の波及を遅延させ、更新の波及をバックグラウンド・プロセスとして実施する。

第２に、データベース・レベルの複製に対するハードウェアベースの代替方法として、オペレーショナル・データ・ストア２４２、２４４、２４６・・・をホストしているストレージ・サブシステムを、接続されているデータベース・サーバから独立してそれぞれのディスク・アレイ・コントローラ上で作動するソフトウェアを通じて「ミラー・コピーする（mirror）」ことができる。このシナリオにおいては、１つの論理インスタンスによって実行されるデータの更新は、生じた際にアレイ全体にわたってコピーされる。

この実施形態においては、監査およびメッセージ・ウェアハウス・データベース・テーブル（auditand message warehouse database tables）など、大容量で長期のデータ・ストアは、従来のデータベースによって引き続き管理されることが好ましい。これは、それらに対する結び付きがさほど緊密ではなく、それらに対するアクセスがさほどタイムクリティカルではないためである。

続く図４における図表は、例示的な送金において本発明に従って上述の本発明のＭＡＰＥモジュール２８３を含む適切なミドルウェア２８０内で実施されるコントロール・フローを示している。

バンキング・プロセスを実行するための上述のカスタム・アプリケーション１１２、１１４、１１６をインストールしている論理端末は、それぞれの個人データおよび受信側のアドレス・データ、ならびに送金する所与の金額を指定する要求メッセージを送信する。このような要求を本発明に適合させる必要はない。

この要求は、ステップ３１０において、本発明のＭＡＰＥミドルウェアのそれぞれのコントロール・シェル（control shell）２８１によって受信される。
次いで、本発明のＭＡＰＥモジュール２８３に関連付けられたこのコントロール・シェルは、ステップ３１５において、仮想化されたサービスのＩＤを提供するように要求される。
ＭＡＰＥモジュール２８３は、図４の右に示されているエンドレス・ループ内で従来技術によるモジュール間の通信に従って連携し、現在のワークロードを測定するステップ５１０、測定したワークロード・データを第１のデータ・ストレージ、すなわち前述の知識ベース２８２内に保存するステップ５１５、測定したワークロードと保存されているポリシーとを比較するステップ５２０、適合できるコントロール・プランを選択するステップ５３０、およびステップ５４０においてリソースの割り当てや割り当て解除を行うステップ５４０をそれぞれ、図４の左に示されているアクティビティと同時に実行する。

したがって、ＭＡＰＥ機能によって可能にされて、動的なインスタンス２２２、２２４、２２６は、受信される要求に割り当てられ、その割り当ては、それぞれのステップ３１８において、本発明のオートノミック・ワークロード・マネージャ２７０の上述のコントロール・シェルによって受信される。

次のステップであるステップ３２０においては、要求が動的なインスタンス２２２へ回送される。

ステップ３３０においては、動的なインスタンス２２２は、受信したメッセージを、この動的なインスタンス２２２のために提供されているオペレーショナル・メッセージ・ストア２４２内に記録する。このオペレーショナル・メッセージ・ストアは、好ましくはオートノミック・ワークロード・マネージャ２７０をホストする銀行の付近に配置されている何らかの専用のサーバに備わっている物理的なストレージである。

さらに図５を参照すると、本発明に従って提供されるそのようなメッセージ・ストレージ２４２、２４４、２４６内に保存されるメタ情報を開示するために、例示的なデータセットの記述が与えられている。

複数のデータセット４０ Ａ、Ｂ、・・Ｎのそれぞれは、一般にデータセットＩＤ ４１を含む。これは、所与のデータセットを容易に検索するために従来技術に従って管理されるインデックスとすることができ、メッセージ・ストレージ・デバイスおよび特性に適合して実装される。これがリレーショナル・データベースである場合には、従来技術のリレーショナル・キー・フィールドを使用することができる。

さらに、送信元、すなわちどのマシンがそれぞれの要求を送信したかが分かるように、論理端末のＩＤ ４２が保存される。これは、ビジネス・データおよびビジネス・プロセスのインテグリティを保証するために必要とされることがあるロールバック・プロセスのために不可欠である。

さらに、どのビジネス・データ４６がどのメッセージに属するかという基準を有するために、メッセージＩＤ ４３が保存される。

さらに、たとえば確認の目的やエラーについて記述する目的から逆の情報の流れを提供するために、返信先アドレス４４が保存される。

さらに、および任意選択で、監査を実行する目的から、動的なインスタンスの識別子４５が保存される。これが行われるのは、使用される動的なインスタンスのＩＤを再構築することができないためであり、というのも、動的なインスタンスを割り当て解除して、それらのＩＤを解き放つことができ、それによって、割り当て解除されたインスタンスを追跡把握することが従来技術の技法では不可能になるためである。

再び図４のコントロール・フローを参照すると、メッセージは、ステップ３４０において、従来技術に存在するような前記安全なバンキング・ネットワーク１５０を通じて送達され、メッセージの転送が完了する。

本発明のオートノミック・マネージャ２７０は、ユーザ定義のポリシーに基づいて、ステップ５１０においてその測定サービスによって、およびそれぞれのクォリティーオブサービス・ポリシーにおけるそれぞれのワークロードの限界の設定との比較５２０によって、ピーク・ワークロードを検知すると想定される。このようなピーク・ワークロードは、端末１１２、１１４、およびその他の多くの端末（図示せず）から指示される送金額の増大によって生じると想定することができる。

その結果、増大したロードに対応するために、それぞれの数の新しい動的なインスタンス２２４、２２６などが、さらなる関連付けられたオペレーショナル・メッセージ・ストア２４４、２４６などと共に確立される。これは、「仮想化されたサービス」と呼ばれている上述の従来技術から分かるように、ステップ５４０においてそれぞれのリソース、すなわちハードウェア、ソフトウェア、およびサービスを割り当てることによって行われる。

次いでオペレーショナル・メッセージ・ストア２４４、２４６は、ステップ５５０において、以前に既に割り当てられているメッセージ・ストア２４２と同期化される。この点において、従来技術のデータ同期化技術は、好ましくは高速の同期化および関連するデータの一貫性に焦点を合わせて、場合によってはビジネス・データの一貫性を保証するために従来技術のロール・バックの方法を含めて適用することできる。したがって、有利なことに、同期化データの量を少なくしておくために差分情報のみを複製することができる。

好ましい本発明のミドルウェアの鍵となる特徴は、そのインスタンスがカスタマー・アプリケーションによって使用されている間に、それらのインスタンスを動的な方法で管理できることである。たとえば、再び図３を参照すると、パフォーマンス関連のサービス目標を実行するためには、インスタンス２２２、２２４、または２２６を、それを使用している１つまたは複数のアプリケーションに結び付けたままで、別のメッセージ・ブローカ環境に移してホストし直すことが必要かもしれない。
これらのアプリケーションは、たとえばメッセージ待ち行列マネージャおよびメッセージ待ち行列の名前によって暗に示される、インスタンスを有しているインターフェース・メッセージ待ち行列の実際の「場所」を知っていることを当てにしてはならないため、有利なことに、それぞれのカスタマー・アプリケーションと、そのカスタマー・アプリケーションが対話するサービスとの間において、シンボル的な回り道（symbolic indirection）が使用される。この目的から、ＯＧＳＩによって規定されるサービス・ハンドル（servicehandle）が、それぞれのサービスに関するシンボル的な名前として採用される。カスタマー・アプリケーションは、ハンドルを、サービスのアドレスとしての役割を果たすサービス・リファレンス（servicereference）へと帰着させるように要求され、その後に、サービスへのアクセスが可能となる。サービスが移転された際に、万一サービス・リファレンスが「古く」または無効になった場合には、アプリケーションは、再びハンドルを帰着させるプロセスを経て、その新たな場所におけるサービスへの新たなリファレンスを得る。

そして論理端末２０２は、それぞれの金額を指定する別の要求メッセージを送信すると想定することができる。この要求は、前述の動的なインスタンス２１２が利用できない場合には、仮想化されたサービス２１２に宛てられ、動的なインスタンス２２４へ回送される。
動的なインスタンス２２４は、受信したメッセージをそのそれぞれのオペレーショナル・メッセージ・ストア２４４内に記録する。
したがって、結果として生じるオペレーショナル・メッセージ・ストア２４４に対する変更は、本発明に従ってストア２４４から２４２へ、そしてストア２４６へ、また使用中のその他のすべてのストアへも複製される。

前述の説明およびそれぞれの図面は、明確さを高めるためにシンプルにしてあるという点を理解されたい。実際には、本発明の方法は、資金振替などの数百または数千のプロセスに適合するように装備され、それらのプロセスは、それぞれの数の論理端末、カスタム・アプリケーション、仮想化されたサービス、動的なインスタンス、およびオペレーショナル・メッセージ・ストア内のデータセットを用いて同時に処理される。

典型的な送金のようなかなりの数のプロセスが完了し、相対的に少ない数のプロセスが入ってきた場合、すなわちワークロードが減少した場合には、測定サービスは、ステップ５１０、５２０において、割り当てられているサービスおよびインスタンスのうちのいくつかをそれ以上使用しないと決定する。この場合には、それらは、従来技術の技法によって割り当てを解除される。

図６は、自前のソフトウェア・インターフェースを含む本発明のＭＡＰＥモジュールの好ましい実装形態を示すシステム図である。これに加えて、図４も参照されたい。
これらの図の助けを借りて、４つの本発明のＭＡＰＥモジュール（Ｍ、Ａ、Ｐ、Ｅ）内における処理のコントロール・フローについて、以降でさらに詳しく説明する。

Ｍ（monitor）６１０は、動的なインスタンスなど、さまざまなソースからデータを収集する。その入力パラメータ（左の矢印）は、要求側の論理端末、要求されているサービスのタイプを含む。
Ａ（analyzer）６２０は、モニタによって提供された生のデータを評価し、ユーザ定義のポリシーに照らしてチェックを行い、潜在的な問題を検知する。その入力パラメータは、ユーザ定義のポリシーを含む。Ｐ（Plan）モジュール６３０は、さらなる動的なインスタンスを作成することや、ワークロードが再び減少したためにそれらのインスタンスが不要になった場合にはそれらの割り当てを解除することなど、必要なアクションを決定する。その入力パラメータは、アナライザによって割り出された逸脱およびその他の結果を含む。Ｅ（Execute）モジュール６４０は、新たに作成されたサービスを呼び出すことや、それらの割り当てを解除することなど、プラン・モジュールによって規定されたアクションを実行する。
前記ＭＡＰＥコントロール・フロー内で提供されるエラー・コントロールは、たとえば実行モジュール６４０が取り組めるよりも多くの潜在的な問題が検知された場合に発生する例外的なワークロード状況を取り扱うことを含むことが好ましい。そして、それらの問題が収集されて、さらなる処理のために従来技術の待ち行列メカニズムへ送信されることが好ましい。通知が別途送信され、それによってシステムは、その後の状況において、そのような例外的な状況に備えることが好ましい。

本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組合せにおいて実現することができる。本発明によるツールは、１つのコンピュータ・システムにおいて集中化された方法で、またはいくつかの相互接続されたコンピュータ・システムにわたってさまざまな要素が散らばっている分散化された方法で実現することができる。本明細書に記載の方法を実行するように適合されているいかなる種類のコンピュータ・システムやその他の装置も適している。ハードウェアとソフトウェアとの典型的な組合せは、ロードされて実行されると、本明細書に記載の方法を実行するようにコンピュータ・システムをコントロールするコンピュータ・プログラムを備えた汎用コンピュータ・システムとすることができる。

本発明は、コンピュータ・プログラム製品の中に組み込むこともでき、このコンピュータ・プログラム製品は、本明細書に記載の方法を実施できるようにするすべての機能を含み、コンピュータ・システム内にロードされると、これらの方法を実行することができる。

この文脈におけるコンピュータ・プログラム手段またはコンピュータ・プログラムとは、情報処理機能を有するシステムに、特定の機能を直接、あるいは
ａ）別の言語、コード、もしくは表記への変換、
ｂ）別の素材形態での複製
のうちのいずれか、または双方の後で実行させることを意図する一式の命令の、任意の言語、コード、もしくは表記による任意の表現を意味する。

金融ネットワーキング環境の従来技術によるシステム構造を示す概略図である。 本発明の原理を抽象的な論理レベルで示す概略図である。 本発明の好ましい一実施形態による金融ネットワーキング環境のシステム構造を示す概略図である。 図３のシステム内で使用されている本発明の方法の基本的なステップを示す概略的なコントロール・フロー図である。 本発明のコンセプトによって構築されたストレージ内でこの実施形態に従って使用できるデータを示すテーブル表示である。 自前のソフトウェア・インターフェースを含む本発明のＭＡＰＥモジュールの好ましい実装形態を示すシステム図である。

Claims (16)

1. ネットワーキング環境内でメッセージベースのワークロードを管理する方法において、複数のクライアント・アプリケーション（１１０、１１２、１１４）が、それぞれのネットワーク化されたサービス（１０６）を介してネットワーク・リソース（１０４）を使用する方法であって、
   ａ）現在のワークロードをモニタして測定するステップ（５１０）と、
   ｂ）測定したワークロード・データを第１の適切なデータ・ストア（２８２）内に保存するステップ（５１５）と、
   ｃ）複数の現在使用されているサービス・インスタンス（２２２、２２４、２２６）に関する状態情報を第２の適切なデータ・ストア（２４２、２４４、２４６）内に保存するステップ（３３０）と、
   ｄ）前記保存された測定済みのワークロード・データおよび前記状態情報の双方を、所定のクォリティーオブサービス・ポリシーに準拠しているか分析するステップ（５２０）と、
   ｅ）前記ワークロードを満たすために使用できるサービス・インスタンス（２２２、２２４、２２６）の数を、前記所定のクォリティーオブサービス・ポリシーによって必要とされる前記ワークロードのニーズに適合させるステップ（５４０）とによって特徴付けられ、
   ｆ）前記サービス・インスタンスのメタ・データ（４１、４２、・・４７）が、メッセージ・ストア（２４２）内で管理され、そのデータ・コンテンツが、前記複数のクライアント・アプリケーション（１１０、１１２、１１４）を、それらのオペレーション中に固定された特定のサービス・インスタンスへの結び付きから切り離すために同期化される方法。
2. 複数のメッセージ・ストア（２４２、２４４、２４６）が、前記メタ・データを管理するために使用される、請求項１に記載の方法。
3. 単一のメッセージ・ストア（２４２）が、単一のメッセージ・サーバによってホストされる、請求項１ないし２に記載の方法。
4. 前記ワークロードが、金融サービスのメッセージ処理を含む、請求項１に記載の方法。
5. 使用できるインスタンスの前記数を適合させる前記ステップ（５４０）が、複製されたインスタンス（２２２、２２４、２２６）の所定のプールにわたってバランスをとることを含む、請求項１に記載の方法。
6. 使用できるインスタンスの前記数を適合させる前記ステップ（５４０）が、メッセージ待ち行列マネージャのクラスタリングを含む、請求項１に記載の方法。
7. ワークロードの優先順位付けが、メッセージ・クラスの区別に基づいて実施される、請求項１に記載の方法。
8. メッセージ・クラス内で、メッセージ・コンテンツに基づいてさらなる優先順位付けが実施される、請求項１ないし７に記載の方法。
9. ＦＳＭ（finite state machine）が、トランザクションのライフタイムにわたる状態情報、および個々のメッセージどうしの間における相関データを管理するために使用される、請求項１に記載の方法。
10. リレーショナル情報およびＸＭＬ情報を含む永続的な処理データベース（２４２、２４４、２４６）が、トランザクションのライフタイムにわたる状態情報、および個々のメッセージどうしの間における相関データを管理するために使用される、請求項１に記載の方法。
11. ａ）データ・フェデレーション、
    ｂ）データの複製、
    ｃ）データのキャッシング、
    ｄ）ハードウェアベースのプロトコル、
    のうちのいずれか、またはそれらの組合せが、前記複数のオペレーショナル・メッセージ・ストア（２４２、２４４、２４６）の同期化を達成するために使用される、請求項２または請求項３に記載の方法。
12. 処理状態を把握するインスタンスが、処理状態を把握するウェブサービス・プロトコルによって管理される、請求項１に記載の方法。
13. 前記プロトコルが、ＯＧＳＡ（Open Grid Services Architecture）によって、またはWS-Resource Frameworkによって提供される、請求項１ないし１２に記載の方法。
14. ネットワーキング環境内でメッセージベースのワークロードを管理するためのコンピュータ・システムにおいて、複数のクライアント・アプリケーション（１１０、１１２、１１４）が、それぞれのネットワーク化されたサービス（１０６）を介してネットワーク・リソース（１０４）を使用するコンピュータ・システムであって、
    ａ）現在のワークロードをモニタして測定する（５１０）ための手段（６１０）と、
    ｂ）測定したワークロード・データを保存する（５１５）ための第１の適切なデータ・ストア（２８２）と、
    ｃ）複数の現在使用されているサービス・インスタンス（２２２、２２４、２２６）に関する状態情報を保存する（３３０）ための第２の適切なデータ・ストア（２４２、２４４、２４６）と、
    ｄ）前記保存された測定済みのワークロード・データおよび前記状態情報の双方を、所定のクォリティーオブサービス・ポリシーに準拠しているか分析する（５２０）ための手段（６２０）と、
    ｅ）前記ワークロードを満たすために使用できるサービス・インスタンス（２２２、２２４、２２６）の数を、前記所定のクォリティーオブサービス・ポリシーによって必要とされる前記ワークロードのニーズに適合させる（５４０）ための手段（６３０、６４０）と、
    ｆ）前記サービス・インスタンスのメタ・データ（４１、４２、・・４７）を管理するためのメッセージ・ストア（２４２）であって、そのデータ・コンテンツが、前記複数のクライアント・アプリケーション（１１０、１１２、１１４）を、それらのオペレーション中に固定された特定のサービス・インスタンスへの結び付きから切り離すために同期化されるメッセージ・ストア（２４２）とによって特徴付けられるコンピュータ・システム。
15. ネットワーキング環境内でメッセージベースのワークロードを管理するための機能コンポーネントを含むデータ処理システム内で実行するためのコンピュータ・プログラムにおいて、複数のクライアント・アプリケーション（１１０、１１２、１１４）が、それぞれのネットワーク化されたサービス（１０６）を介してネットワーク・リソース（１０４）を使用するコンピュータ・プログラムであって、
    ａ）現在のワークロードをモニタして測定するステップ（５１０）と、
    ｂ）測定したワークロード・データを第１の適切なデータ・ストア（２８２）内に保存するステップ（５１５）と、
    ｃ）複数の現在使用されているサービス・インスタンス（２２２、２２４、２２６）に関する状態情報を第２の適切なデータ・ストア（２４２、２４４、２４６）内に保存するステップ（３３０）と、
    ｄ）前記保存された測定済みのワークロード・データおよび前記状態情報の双方を、所定のクォリティーオブサービス・ポリシーに準拠しているか分析するステップ（５２０）と、
    ｅ）前記ワークロードを満たすために使用できるサービス・インスタンス（２２２、２２４、２２６）の数を、前記所定のクォリティーオブサービス・ポリシーによって必要とされる前記ワークロードのニーズに適合させるステップ（５４０）とによって特徴付けられ、
    ｆ）前記サービス・インスタンスのメタ・データ（４１、４２、・・４７）が、メッセージ・ストア（２４２）内で管理され、そのデータ・コンテンツが、前記コンピュータ・プログラムがコンピュータ上で実行されると、前記複数のクライアント・アプリケーション（１１０、１１２、１１４）を、それらのオペレーション中に固定された特定のサービス・インスタンスへの結び付きから切り離すために同期化されるコンピュータ・プログラム。
16. ネットワーキング環境内でメッセージベースのワークロードを管理するための機能コンポーネントを含むコンピュータで読み取り可能なプログラム手段を含むコンピュータで使用できるメディア上に格納されているコンピュータ・プログラム製品において、複数のクライアント・アプリケーション（１１０、１１２、１１４）が、それぞれのネットワーク化されたサービス（１０６）を介してネットワーク・リソース（１０４）を使用するコンピュータ・プログラム製品であって、
    ａ）現在のワークロードをモニタして測定するステップ（５１０）と、
    ｂ）測定したワークロード・データを第１の適切なデータ・ストア（２８２）内に保存するステップ（５１５）と、
    ｃ）複数の現在使用されているサービス・インスタンス（２２２、２２４、２２６）に関する状態情報を第２の適切なデータ・ストア（２４２、２４４、２４６）内に保存するステップ（３３０）と、
    ｄ）前記保存された測定済みのワークロード・データおよび前記状態情報の双方を、所定のクォリティーオブサービス・ポリシーに準拠しているか分析するステップ（５２０）と、
    ｅ）前記ワークロードを満たすために使用できるサービス・インスタンス（２２２、２２４、２２６）の数を、前記所定のクォリティーオブサービス・ポリシーによって必要とされる前記ワークロードのニーズに適合させるステップ（５４０）とによって特徴付けられ、
    ｆ）前記サービス・インスタンスのメタ・データ（４１、４２、・・４７）が、メッセージ・ストア（２４２）内で管理され、そのデータ・コンテンツが、前記コンピュータ・プログラム製品がコンピュータ上で実行されると、前記複数のクライアント・アプリケーション（１１０、１１２、１１４）を、それらのオペレーション中に固定された特定のサービス・インスタンスへの結び付きから切り離すために同期化されるコンピュータ・プログラム製品。

Images