(57)【特許請求の範囲】
【請求項１】
トランスポートインフラストラクチャを用いて、第１アプリケーションから少なくとも第２アプリケーションへ、メッセージを伝達する方法であって、
ＡＰＩ層が、第２アプリケーションと関連した第１サービス識別子とメッセージとを第１アプリケーションから受信する段階と、
ＡＰＩ層が、第１サービス識別子を用いて、第１ディレクトリから第１パラメータセットを回収する段階と、
ＡＰＩ層が、メッセージおよび回収された第１パラメータセットを、トランスポートインフラストラクチャへ渡す段階と
を具備し、
前記第１パラメータセットは、第１アプリケーションから第２アプリケーションへメッセージを伝送するために、トランスポートインフラストラクチャにより必要とされ、
前記トランスポートインフラストラクチャは、第２アプリケーションへメッセージを伝達し、
ＡＰＩ層が、前記メッセージの到着時に、第２アプリケーションをトリガリングする段階と、
ＡＰＩ層が、第２サービス識別子を第２アプリケーションから受信する段階と、
ＡＰＩ層が、第２サービス識別子を用いて、第２ディレクトリから第２パラメータセットを回収する段階と、
ＡＰＩ層が、回収された第２パラメータセットのうち少なくとも幾つかを用いて、トランスポートインフラストラクチャからメッセージを回収する段階と
をさらに具備することを特徴とする方法。
【請求項２】
前記第１ディレクトリは、第２ディレクトリであることを特徴とする請求項１に記載の方法。
【請求項３】
前記メッセージは、第１アプリケーションのオペレーションに対して非同期に伝達されることを特徴とする請求項１に記載の方法。
【請求項４】
ＡＰＩ層が前記第１ディレクトリを更新することを特徴とする請求項１に記載の方法。
【請求項５】
前記第１ディレクトリの更新は、第２アプリケーションに関する変更に応答し、
前記第１ディレクトリの更新および第２アプリケーションに関する変更は、第１アプリケーションに対するいかなる変更をも必要としないことを特徴とする請求項４に記載の方法。
【請求項６】
前記第２アプリケーションに関する変更は、該第２アプリケーションの位置の変更であることを特徴とする請求項５に記載の方法。
【請求項７】
前記第２アプリケーションに関する変更は、該第２アプリケーションが実行されるプラットフォームの変更であることを特徴とする請求項５に記載の方法。
【請求項８】
前記第１ディレクトリの更新は、該第１ディレクトリに備えられるデフォルト設定の変更に応答することを特徴とする請求項４に記載の方法。
【請求項９】
前記デフォルト設定の変更は、トランスポートインフラストラクチャに関する所望のオペレーションの変更を反映することを特徴とする請求項８に記載の方法。
【請求項１０】
前記トランスポートインフラストラクチャに関する所望のオペレーションの変更は、伝達すべきメッセージの優先順位の変更であることを特徴とする請求項９に記載の方法。
【請求項１１】
前記第１ディレクトリの更新は、トランスポートインフラストラクチャに関する変更に応答し、
前記第１ディレクトリの更新およびトランスポートインフラストラクチャに関する変更は、第１アプリケーションに対するいかなる変更をも必要としないことを特徴とする請求項４に記載の方法。
【請求項１２】
前記トランスポートインフラストラクチャに関する変更は、該トランスポートインフラストラクチャの物理コンフィギュレーションに関する変更であることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記トランスポートインフラストラクチャに関する変更は、該トランスポートインフラストラクチャのインターフェースに関する変更であることを特徴とする請求項１１に記載の方法。
【請求項１４】
前記トランスポートインフラストラクチャに関する変更は、該トランスポートインフラストラクチャのソフトウェアコンポーネントに関する変更であることを特徴とする請求項１１に記載の方法。
【請求項１５】
前記トランスポートインフラストラクチャに関する変更は、該トランスポートインフラストラクチャにより用いられるメッセージルーティングに関する変更であることを特徴とする請求項１１に記載の方法。
【請求項１６】
前記第１パラメータセットは、第２アプリケーションに対するルーティング情報を有することを特徴とする請求項１に記載の方法。
【請求項１７】
前記回収段階は、第１ディレクトリから第１パラメータセットを回収すべく、第１ディレクトリにおいてルックアップを行うために、第１サービス識別子を用いる段階をさらに具備することを特徴とする請求項１に記載の方法。
【請求項１８】
前記第１ディレクトリは、複数のパラメータセットを有し、
前記回収段階は、第１サービス識別子と関連する第１パラメータセットのみを回収する段階をさらに具備することを特徴とする請求項１に記載の方法。
【請求項１９】
前記メッセージを、第２アプリケーションへ伝達する前にアーカイビングする段階をさらに具備することを特徴とする請求項１に記載の方法。
【請求項２０】
伝達用にトランスポートインフラストラクチャへ渡されたメッセージをトレーシングすることを特徴とする請求項１に記載の方法。
【請求項２１】
伝達用にトランスポートインフラストラクチャへ渡されたメッセージを調停することを特徴とする請求項１に記載の方法。
【請求項２２】
前記第１アプリケーションは、第１サービス識別子を有する制御ブロックを生成することを特徴とする請求項１に記載の方法。
【請求項２３】
前記アプリケーションは、伝達されたメッセージのための作業論理ユニット設定を変更するフラグを生成し、該フラグは、制御ブロックに備えられていることを特徴とする請求項２２に記載の方法。
【請求項２４】
前記アプリケーションは、持続性設定を変更するフラグを生成し、該フラグは、制御ブロックに備えられていることを特徴とする請求項２２に記載の方法。
【請求項２５】
前記アプリケーションは、メッセージの優先順位を上下させる優先順位表示を生成し、該優先順位表示は、制御ブロックに備えられていることを特徴とする請求項２２に記載の方法。
【請求項２６】
前記アプリケーションは、オーバーライドパラメータを生成し、該オーバーライドパラメータは、制御ブロックに備えられ、かつ、回収された第１パラメータセットのうち任意の対応するパラメータに優先することを特徴とする請求項２２に記載の方法。
【請求項２７】
前記トランスポートインフラストラクチャは、メッセージを中間メッセージ処理サーバー（ＭＰＳ）を介して、第２アプリケーションへ伝達することを特徴とする請求項１に記載の方法。
【請求項２８】
前記第１サービス識別子は、第２アプリケーションおよびＭＰＳと関連していることを特徴とする請求項２７に記載の方法。
【請求項２９】
前記ＭＰＳは、メッセージに基づいてオペレーションを行う段階をさらに具備することを特徴とする請求項２７に記載の方法。
【請求項３０】
メッセージの内容にしたがってＭＰＳにより行うべきオペレーションを決定する段階をさらに具備することを特徴とする請求項２７に記載の方法。
【請求項３１】
前記メッセージの到着時に、ＭＰＳをトリガリングする段階と、
第２サービス識別子を生成する段階と、
第２サービス識別子を用いて、第２ディレクトリから第２パラメータセットを回収する段階と、
回収された第２パラメータセットのうち少なくとも幾つかを用いて、トランスポートインフラストラクチャからメッセージを回収する段階と
をさらに具備することを特徴とする請求項２７に記載の方法。
【請求項３２】
ＭＰＳが、回収されたメッセージ上でオペレーションを行う段階と、
ＭＰＳが、回収されたメッセージから第３サービス識別子を抽出する段階と、
第３サービス識別子を用いて、第２ディレクトリから第３パラメータセットを回収する段階と、
メッセージおよび回収された第３パラメータセットを、トランスポートインフラストラクチャへ渡す段階と
を具備し、
前記トランスポートインフラストラクチャは、第２アプリケーションへメッセージを伝達することを特徴とする請求項３１に記載の方法。
【請求項３３】
前記メッセージ上で行われるオペレーションは、メッセージを再フォーマットすることを特徴とする請求項３２に記載の方法。
【請求項３４】
前記メッセージは、第２アプリケーションが実行されるプラットフォームのために再フォーマットされることを特徴とする請求項３３に記載の方法。
【請求項３５】
前記メッセージは、さらに、第３アプリケーションへ伝達され、前記方法は、
ＭＰＳが、メッセージを、第１アプリケーションから伝達された際に、インフラストラクチャから回収する段階と、
ＭＰＳが、前記メッセージ内のサービス識別子に基づいて、インフラストラクチャに、第２アプリケーションおよび第３アプリケーションの両方へメッセージを伝達させる段階と
をさらに具備することを特徴とする請求項２７に記載の方法。
【請求項３６】
ＭＰＳが、回収されたメッセージから第２サービス識別子を抽出することにより、
第２サービス識別子を用いて、第２ディレクトリから第２パラメータセットを回収することにより、
メッセージおよび回収された第２パラメータセットを、トランスポートインフラストラクチャへ渡すことにより、
ＭＰＳが、インフラストラクチャに、第２アプリケーションおよび第３アプリケーションの両方へメッセージを伝達させ、
前記トランスポートインフラストラクチャは、第２パラメータセットに応答して、第２アプリケーションおよび第３アプリケーションの両方へメッセージを伝達することを特徴とする請求項３５に記載の方法。
【請求項３７】
ＭＰＳが、回収されたメッセージから第２サービス識別子を抽出することにより、
第２サービス識別子を用いて、第２ディレクトリから第２パラメータセットおよび第３パラメータセットを回収することにより、
メッセージおよび回収された第２パラメータセットを、トランスポートインフラストラクチャへ渡すことにより、
メッセージおよび回収された第３パラメータセットを、トランスポートインフラストラクチャへ渡すことにより、
ＭＰＳが、インフラストラクチャに、第２アプリケーションおよび第３アプリケーションの両方へメッセージを伝達させ、
前記トランスポートインフラストラクチャは、第２パラメータセットに応答して、第２アプリケーションへメッセージを伝達し、
前記トランスポートインフラストラクチャは、第３パラメータセットに応答して、第３アプリケーションへメッセージを伝達することを特徴とする請求項３５に記載の方法。
【請求項３８】
前記メッセージのルーティングは、メッセージの内容に基づいて決定されることを特徴とする請求項３５に記載の方法。
【請求項３９】
ＡＰＩ層が、前記メッセージの到着時に、ＭＰＳをトリガリングする段階と、
ＡＰＩ層が、第２サービス識別子を生成する段階と、
ＡＰＩ層が、第２サービス識別子を用いて、第２ディレクトリから第２パラメータセットを回収する段階と
をさらに具備し、
前記ＭＰＳが、回収されたメッセージから第３サービス識別子を抽出することにより、
第３サービス識別子を用いて、第３ディレクトリから第３パラメータセットを回収することにより、
メッセージおよび回収された第３パラメータセットを、トランスポートインフラストラクチャへ渡すことにより、
ＭＰＳが、インフラストラクチャに、第２アプリケーションおよび第３アプリケーションの両方へメッセージを伝達させ、
前記トランスポートインフラストラクチャは、第３パラメータセットに応答して、第２アプリケーションおよび第３アプリケーションの両方へメッセージを伝達することを特徴とする請求項３５に記載の方法。
【請求項４０】
トランスポートインフラストラクチャを用いて、第１アプリケーションから少なくとも第２アプリケーションへ、メッセージを伝達するシステムであって、
第１アプリケーションとトランスポートインフラストラクチャとに結びつけられた送信モジュールと、
少なくとも第１パラメータセットを有する第１ディレクトリと
を具備し、
前記送信モジュールは、第１アプリケーションから第１サービス識別子を受信し、該第１サービス識別子は、メッセージおよび第２アプリケーションと関連しており、
前記第１パラメータセットは、第１アプリケーションから第２アプリケーションへメッセージを伝送するために、トランスポートインフラストラクチャにより必要とされ、前記送信モジュールは、第１サービス識別子の受信に応答して、第１ディレクトリから第１パラメータセットを回収し、
前記送信モジュールは、メッセージと回収された第１パラメータセットとをトランスポートインフラストラクチャへ渡し、該トランスポートインフラストラクチャは、メッセージを第２アプリケーションへ伝達し、
前記第１アプリケーションは、第１パラメータセットの内容について知らず、
第２アプリケーションとトランスポートインフラストラクチャとに結びつけられた受信モジュールと、
少なくとも第２パラメータセットを有する第２ディレクトリと
を具備し、
前記受信モジュールは、第２アプリケーションから第２サービス識別子を受信し、
前記第２パラメータセットは、トランスポートインフラストラクチャからメッセージを回収するために必要とされ、
前記受信モジュールは、第２サービス識別子の受信に応答して、第２ディレクトリから第２パラメータセットを回収し、
前記受信モジュールは、回収された第２パラメータセットのうち少なくとも幾つかを用いて、トランスポートインフラストラクチャからメッセージを回収することを特徴とするシステム。
【請求項４１】
前記第１ディレクトリは、第２ディレクトリであることを特徴とする請求項４０に記載のシステム。
【請求項４２】
前記メッセージは、第１アプリケーションのオペレーションに対して非同期に伝達されることを特徴とする請求項４０に記載のシステム。
【請求項４３】
第１ディレクトリに備えられる複数のパラメータセットをさらに具備することを特徴とする請求項４０に記載のシステム。
【請求項４４】
前記パラメータセットは、トランスポートインフラストラクチャのオペレーションのために必要とされるデフォルトパラメータであることを特徴とする請求項４３に記載のシステム。
【請求項４５】
前記第１ディレクトリを更新することを特徴とする請求項４０に記載のシステム。
【請求項４６】
前記更新は、第２アプリケーションに関する変更を反映し、
前記更新は、第１アプリケーションに対するいかなる変更をも必要としないことを特徴とする請求項４５に記載のシステム。
【請求項４７】
前記第２アプリケーションに関する変更は、該第２アプリケーションの位置の変更であることを特徴とする請求項４６に記載のシステム。
【請求項４８】
前記第２アプリケーションに関する変更は、該第２アプリケーションが実行されるプラットフォームの変更であることを特徴とする請求項４６に記載のシステム。
【請求項４９】
前記更新は、第１ディレクトリに備えられるデフォルト設定を変更することを特徴とする請求項４５に記載のシステム。
【請求項５０】
前記更新は、トランスポートインフラストラクチャに関する所望のオペレーションの変更を反映することを特徴とする請求項４９に記載のシステム。
【請求項５１】
前記トランスポートインフラストラクチャに関する所望のオペレーションの変更は、伝達すべきメッセージの優先順位の変更であることを特徴とする請求項５０に記載のシステム。
【請求項５２】
前記更新は、トランスポートインフラストラクチャの変更を反映し、
前記更新は、第１アプリケーションに対するいかなる変更をも必要としないことを特徴とする請求項４５に記載のシステム。
【請求項５３】
前記トランスポートインフラストラクチャの物理コンフィギュレーションをさらに具備し、
トランスポートインフラストラクチャの変更は、該トランスポートインフラストラクチャの物理コンフィギュレーションに関する変更であることを特徴とする請求項５２に記載のシステム。
【請求項５４】
前記送信モジュールとトランスポートインフラストラクチャとの間のインターフェースをさらに具備し、
前記トランスポートインフラストラクチャの変更は、該トランスポートインフラストラクチャのインターフェースに関する変更であることを特徴とする請求項５２に記載のシステム。
【請求項５５】
前記トランスポートインフラストラクチャのソフトウェアコンポーネントをさらに具備し、
前記トランスポートインフラストラクチャに関する変更は、該トランスポートインフラストラクチャのソフトウェアコンポーネントに関する変更であることを特徴とする請求項５２に記載のシステム。
【請求項５６】
前記トランスポートインフラストラクチャに関する変更は、該トランスポートインフラストラクチャにより用いられるメッセージルーティングに関する変更であることを特徴とする請求項５２に記載のシステム。
【請求項５７】
前記第１パラメータセットは、第２アプリケーションに対するルーティング情報を具備することを特徴とする請求項４０に記載のシステム。
【請求項５８】
前記メッセージをアーカイビングするアーカイビングモジュールをさらに具備することを特徴とする請求項４０に記載のシステム。
【請求項５９】
伝達用にトランスポートインフラストラクチャへ渡されたメッセージをトレースするトレーシングモジュールをさらに具備することを特徴とする請求項４０に記載のシステム。
【請求項６０】
伝達用にトランスポートインフラストラクチャへ渡されたメッセージを調停する調停モジュールをさらに具備することを特徴とする請求項５９に記載のシステム。
【請求項６１】
前記第１アプリケーションにより生成された制御ブロックをさらに具備し、該制御ブロックは、第１サービス識別子を有することを特徴とする請求項４０に記載のシステム。
【請求項６２】
前記第１アプリケーションにより生成されたフラグをさらに具備し、該フラグは、伝達されたメッセージのための作業論理ユニット設定を変更し、該フラグは、制御ブロックに備えられていることを特徴とする請求項６１に記載のシステム。
【請求項６３】
前記第１アプリケーションにより生成されたフラグをさらに具備し、該フラグは、持続性設定を変更し、該フラグは、制御ブロックに備えられていることを特徴とする請求項６１に記載のシステム。
【請求項６４】
前記第１アプリケーションにより生成された優先順位表示をさらに具備し、該優先順位表示は、メッセージの優先順位を上下させ、該優先順位表示は、制御ブロックに備えられていることを特徴とする請求項６１に記載のシステム。
【請求項６５】
前記第１アプリケーションにより生成されたオーバーライドパラメータをさらに具備し、該オーバーライドパラメータは、制御ブロックに備えられ、かつ、回収された第１パラメータセットのうち任意の対応するパラメータに優先することを特徴とする請求項６１に記載のシステム。
【請求項６６】
前記トランスポートインフラストラクチャに結びつけられたメッセージ処理サーバー（ＭＰＳ）をさらに具備することを特徴とする請求項４０に記載のシステム。
【請求項６７】
前記第１サービス識別子は、第２アプリケーションおよびＭＰＳと関連していることを特徴とする請求項６６に記載のシステム。
【請求項６８】
前記メッセージは、トランスポートインフラストラクチャによりＭＰＳへ伝達され、
前記ＭＰＳは、メッセージに基づいてオペレーションを行うことを特徴とする請求項６６に記載のシステム。
【請求項６９】
前記ＭＰＳは、メッセージの内容にしたがって行うべきオペレーションを決定することを特徴とする請求項６８に記載のシステム。
【請求項７０】
ＭＰＳとトランスポートインフラストラクチャとに結びつけられたＭＰＳ受信モジュールと、
少なくとも第２パラメータセットを有する第２ディレクトリと
を具備し、
前記受信モジュールは、ＭＰＳから第２サービス識別子を受信し、
前記第２パラメータセットは、トランスポートインフラストラクチャからメッセージを回収するために必要とされ、
前記ＭＰＳ受信モジュールは、第２サービス識別子の受信に応答して、第２ディレクトリから第２パラメータセットを回収し、
前記ＭＰＳ受信モジュールは、回収された第２パラメータセットのうち少なくとも幾つかを用いて、トランスポートインフラストラクチャからメッセージを回収することを特徴とする請求項６６に記載のシステム。
【請求項７１】
メッセージの内容にしたがってメッセージのルーティングを決定するＭＰＳ内に、ルーティングモジュールの配列をさらに具備することを特徴とする請求項７０に記載のシステム。
【請求項７２】
ＭＰＳ内に備えられる再フォーマットエンジンをさらに具備し、
メッセージ上で行われるオペレーションは、再フォーマットエンジンを用いてメッセージを再フォーマットする段階をさらに具備することを特徴とする請求項７１に記載のシステム。
【請求項７３】
前記メッセージは、第２アプリケーションが実行されるプラットフォームのために再フォーマットされることを特徴とする請求項７２に記載のシステム。
【請求項７４】
前記メッセージは、さらに、第３アプリケーションへ伝達され、
前記ＭＰＳは、マルチキャスティングＭＰＳであり、
前記システムは、
ＭＰＳとトランスポートインフラストラクチャとに結びつけられたＭＰＳ受信モジュールと、
トランスポートインフラストラクチャからメッセージを回収するために必要とされる第２パラメータセットを少なくとも有する第２ディレクトリと
ＭＰＳと、第２ディレクトリと、トランスポートインフラストラクチャとに結びつけられ、該第２ディレクトリから第３パラメータセットを回収するＭＰＳ送信モジュールと
をさらに具備し、
前記ＭＰＳ受信モジュールは、第２ディレクトリから第２パラメータセットを回収し、
前記ＭＰＳ受信モジュールは、回収された第２パラメータセットのうち少なくとも幾つかを用いて、トランスポートインフラストラクチャからメッセージを回収し、
前記ＭＰＳ送信モジュールは、回収された第３パラメータセットをトランスポートインフラストラクチャへ渡し、かつ、該トランスポートインフラストラクチャは、第２アプリケーションおよび第３アプリケーションへ、メッセージを伝達することを特徴とする請求項６６に記載のシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、概して、インターシステムまたはイントラシステムメッセージングシステムに関し、より詳細には、アプリケーションプログラム間の抽出層（abstraction layer）とメッセージングトランスポート層とを供給するメッセージングシステムアーキテクチャに関する。
【０００２】
【従来の技術】
数十年前にメインフレームコンピュータによって始まって、コンピューティング革命の最初の波は、大量の情報を管理する権限を企業に与え、世界的な商業の規模の多大な発展を促進した。パーソナルコンピュータの導入は、継続する革命の第２の波を開始させ、情報作成の力を個人に与えた。コンピュータの発展の１つの要因は、種々のコンピュータプログラムアプリケーションが互いにデータを渡すことを（そうでない場合には、互いに通信することを）可能にしたインターフェースの開発である。このアプリケーション間（inter-application）またはコンピュータ間（inter-computer）通信は、包括的に“メッセージング”として説明される。
【０００３】
現在、ネットワークが、企業および個人の両方が、世界中に迅速かつ容易に情報を伝達することを可能にするコンピューティング革命の第３の波として出現している。しかしながら、インターネットワークまたはイントラネットワーク通信を妨げる重大な問題は、インターフェース（何年にもわたって開発されてきたハードウェアおよびソフトウェアの両方）の多様性である。
【０００４】
この問題を認識して、１９８３年から始まった大手コンピュータおよび電気通信会社の代表らは、通信用の標準モデルを開発しかつ採用した。ＯＳＩ（Open Systems Interconnection）として公知の規格は、製品開発者や製造業者の製品が他の製品とともに一貫して作動するように彼らを案内するために用いられる。ＯＳＩは、国際標準化機構（ＩＳＯ）による国際的な規格として公式に採用された。
【０００５】
ＯＳＩモデルは、通信の各終端において発生する機能性の層を７つ定義する。ＯＳＩは、関連した機能を明確に定義された層内にともに保持する点においては必ずしも厳密に固着していないが、電気通信やメッセージングに関係する大部分ではないにしても多くの製品が、ＯＳＩモデルと関連づけて自らを説明しようとしている。
【０００６】
ＯＳＩにおいて重要な考えは、２人のエンドユーザー間での通信を、各々がそれ自体の特殊な関連した関数を追加している層に分割できることである。ある方法では、通信の各端部におけるシステムは、これら７層の関数を組み込んでいる。ユーザー間の所定のメッセージ内には、一方の端部において、送信側ユーザーにより用いられるコンピュータ内の層を下方へ通過する、各層を通過するデータ流れが存在し、かつ、他方の端部において、メッセージが到着すると、受信側ユーザーのコンピュータの層を上方へ通過する他のデータ流れが存在する。これら７層の関数を備える実際のプログラミングおよびハードウェアは、通常は、コンピュータオペレーティングシステム、（ウェブブラウザのような）アプリケーション、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）または代替のトランスポートおよびネットワークプロトコル、コンピュータが該コンピュータに取り付けられたハードウェアライン上に信号を物理的に配することを可能にするソフトウェアおよびハードウェアの組み合わせである。
【０００７】
７つのＯＳＩ層が、図１に図示されている。これら７層は、論理的に２つのグループに分割されている。下位３つの層１４０〜１６０は、任意のメッセージがホストコンピュータを通過するときに用いられる。上位３つの層１１０〜１３０は、ホストコンピュータ上で実行されるアプリケーションとメッセージがやりとりされるときに常に用いられる。２つのホストコンピュータ間のメッセージは、７つの層１００〜１６０全てを通過する。（例えば、インスタントホストがネットワーク内の中間ノードとして作用しているときに）他の何らかのホストに宛てられたメッセージは、上位層１００〜１３０まで渡されずに、ホスト（または他の中間ノード）へ転送される。
【０００８】
７つのＯＳＩ層は、アプリケーション層１００と、プレゼンテーション層１１０と、セッション層１２０と、トランスポート層１３０と、ネットワーク層１４０と、データリンク層１５０と、物理層１６０とを有する。アプリケーション層１００は、通信パートナーが識別され、サービスの質が識別され、ユーザー認証およびプライバシーが考慮され、かつ、データ構文（data syntax）上の任意の制約が識別される層である。アプリケーション層１００は、アプリケーションそれ自体ではなく、ユーザーへのインターフェースを供給することを特筆しておく。アプリケーションの中には、アプリケーション層の機能を行うことができるものもある。アプリケーション層１００に関する幾つかの実施手段は、Ｅメール、ニュースグループ、ウェブアプリケーション、ファイル転送、ホストセッション、ディレクトリサービス、ネットワーク管理、ファイルサービスを包含するが、これらに制約されるものではない。
【０００９】
プレゼンテーション層１１０は、通常は、あるプレゼンテーションフォーマットから他のフォーマットへ入力および出力データを変換するオペレーティングシステムの一部である。例えば、プレゼンテーション層１１０は、テキストストリームからのデータをポップアップウィンドウに変換することができる。プレゼンテーション層１１０は、時には、構文層と称される。プレゼンテーション層１１０に関する幾つかの実施手段は、ＰＯＰ／ＳＭＴＰ，Ｕｓｅｎｅｔ，ＨＴＴＰ，ＦＴＰ，ＴｅｌＮｅｔ，ＤＮＳ，ＳＮＭＰ，ＮＦＳを包含するが、これらに制約されるものではない。
【００１０】
セッション層１２０は、通信の各端部におけるアプリケーション間の変換、交換、および対話を、設定し、調整し、かつ、終了させる。セッション層１２０に関する幾つかの実施手段は、ＰＯＰ／２５，５３２，８０，２０／２１，２３，５３，１６１／１６２と、ＲＰＣ Ｐｏｒｔｍａｐｐｅｒとを包含するが、これらに制約されるものではない。
【００１１】
トランスポート層１３０は、通信に関するエンドツーエンド（end-to-end）制御（例えば、全てのパケットが到着したかどうかを確認すること、およびエラーチェック）を管理する。トランスポート層１３０は、完全なデータ転送を保証する。ＴＣＰおよびＵＤＰのような規格は、トランスポート層１３０の実施手段である。
【００１２】
ネットワーク層１４０は、データのルーティング（routing）を処理する。このルーティングは、出力伝送上において正しい方向に正しい宛先（destination）へメッセージを送信すること、および、入力伝送をパケットレベルにて受信することを伴う。ネットワーク層１４０は、メッセージのルーティングおよび転送を行う。インターネットプロトコルＶｅｒ．６およびＶｅｒ．４は、ネットワーク層１４０の実施手段である。データリンク層１５０は、物理層１６０に対するエラー制御や同期を与える。
【００１３】
データリンク層１５０は、さらに、伝送プロトコルの知識および管理を備える。ＳＬＩＰ，ＰＰＰ，８０２．２ ＳＮＡＰ，Ｅｔｈｅｒｎｅｔ（登録商標） IIのような規格は、データリンク層１５０の実施手段である。
【００１４】
物理層１６０は、電気的および機械的レベルにて、ネットワークを通してビットストリームを伝達する層である。この層１６０は、キャリア上でデータを送受信するハードウェア手段を提供する。物理層の規格は、Ｃｏａｘｉａｌ Ｃａｂｌｅｓの他に、ＲＳ−Ｘ，Ｃａｔ １，ＩＳＤＮ，ＡＤＳＬ，ＡＴＭ，ＦＤＤＩ，ＣＡＴ １−５を包含する。
【００１５】
ＯＳＩモデルの採用が、ある一定のレベルのメッセージの均一性という結果となったとしても、実際のモデルの実施手段の多様性は、アプリケーションプログラマーやシステムインテグレータにとって困った問題として残存する。この複雑さの結果は、アプリケーションが、メッセージングのために用いられる他の種々のアプリケーション、プラットフォーム、フォーマット、ルーティングの“ハードコーデッドされた（hardcoded）”記述を包含することを余儀なくされることである。（例えば、オペレーティングシステムの新バージョンによって）これらのパラメータのうち幾つかが変化すれば、アプリケーションプログラムを変更し、再コンパイルし、かつ、テストする必要がある。これは、従来のメッセージングアーキテクチャにおける膨大なプログラムである。
【００１６】
したがって、多様なプラットフォーム上の多様なアプリケーションが互いに通信することを可能にするメッセージングアーキテクチャのための産業において長い間切望されている必要性が存在する。このようなアーキテクチャは、アプリケーション開発者が、自分たちのアプリケーションの内容に集中しかつメッセージングに関連した複雑な物理的インフラストラクチャを無視することを可能にすべきである。
【００１７】
【発明が解決しようとする課題】
本発明は、メッセージを伝達するために実際に用いられるトランスポート機構とルーティング機構とから、アプリケーションプログラムを隔離するアプリケーションプログラミングインターフェース（ＡＰＩ）を有するメッセージングシステムを提供する。これらのＡＰＩは、さらに、抽出層として識別される。その理由は、アプリケーションが、トランスポートおよびルーティングのために必要とされる特定のフォーマットおよびルーティングのディテールと無関係に、トランスポートおよびルーティング機構を抽出して、概念的に見ることができるためである。
【００１８】
【課題を解決するための手段】
本発明のＡＰＩはこの隔離をもたらす方法は、ディレクトリファイルを用いることによる。ディレクトリファイルは、トランスポート機構およびルーティング機構とインターフェース接続するために必要な全ての特定のディテール（例えば、フォーマットパラメータおよびルーティングパラメータ）を有する。（例えば、更新されたバージョンまたは新たな機構に起因して）トランスポートおよびルーティングのディテールが変更される際には、アプリケーションプログラムを再コーディング（recoding）したり、再コンパイルしたり、または広範囲なテストを行ったりする必要がなく、ディレクトリファイルを変更する必要があるのみである。このことは、トランスポート機構およびルーティング機構とのインターフェース接続のディテールが、アプリケーションプログラムそれ自体の中に“ハードコード（hardcode）”されていた従来技術の重大な問題を解決する。
【００１９】
本発明の他の特徴は、アプリケーションが、トランスポート機構の非同期メッセージング能力を利用する能力を高めることである。このことは、宛先に対する全面的なメッセージの伝送およびルーティングを調整しかつ管理するためのアプリケーションを必要としていた従来技術に対する利点から派生する重大な新発展である。本発明において、いったん、アプリケーションがＡＰＩへメッセージを発行してしまうと、制御はアプリケーションへ戻り、該アプリケーションは、次に、メッセージのトランスポートおよびルーティングと関係する必要なしに、その本質的な処理を継続する。非同期メッセージングの大きな利点は、テスティング領域において見出される。従来技術による同期メッセージングにおいては、新たなまたは更新されたアプリケーションがオンラインでもたらされると、アプリケーションのテスティングは、新たなアプリケーションをテストするために、該アプリケーションがインターフェース接続していたシステムがサービスから取り出される必要があることを要求していた。本発明は非同期メッセージングの能力を高めるので、新たなアプリケーションをそれ自体によってテストすることができ、かつ、生成されるメッセージのテスティングを他のシステムにより一度に達成することができ、このことは、他のシステムにとって好都合である。この利点は、アプリケーションの開発およびテスティングを著しく迅速、安価、かつ容易に行えるという結果をもたらす。
【００２０】
本発明は、メッセージ処理サーバー（ＭＰＳ）をさらに有し、該メッセージ処理サーバーは、メッセージ記憶、トレーシング、調停（reconciliation）、統計的監査、再フォーマット、内容に基づくルーティング、マルチキャスティングのようなさらなるメッセージング機能性をもたらす。さらなる機能性が開発されているので、この機能性については、新たなＭＰＳ内に柔軟に組み込むことができる。
【００２１】
【発明の実施の形態】
本発明を例示する目的のために、当該の好ましい形式が図面に示されている。しかしながら、図面に示された精密な形式に本発明が制約されるものではないことが理解される。
【００２２】
図２は、本発明のメッセージングアーキテクチャの様々な層を図示している。前述したように、本発明の主要な目的は、実際にメッセージをトランスポートするために用いられる論理および物理メッセージングミドルウェアのディテールからアプリケーション２００を隔離することである。基底にある（underlying）トランスポート層からアプリケーション２００を隔離するために、メッセージングアーキテクチャは、隔離または抽出層２１０をトランスポート層およびルーティング層の上方に供給している。この開示の目的のために、抽出層２１０（および後述する抽出層２２０，２３０）の下方にある層は、トランスポートインフラストラクチャの一部として考えられている。トランスポートインフラストラクチャは、さらに、（例えば、電話線およびスイッチング装置のような）２つのポイント間でメッセージを伝達するために必要な全ての物理的コンポーネントを有している。
【００２３】
図２に示されるように、ＧＴＡ（Global Technology Architecture）ｃｏｍｍｏｎ ＡＰＩ（Application Programming Interface）層２１０は、アプリケーション２００に対して露出されている唯一の層である。本明細書において用いられるように、本発明は、時には、グローバルテクノロジーアーキテクチャ（ＧＴＡ）と称される。グローバルという語は、本発明の好ましい実施形態において、このアーキテクチャが世界中の企業のコンピューティングオペレーションの各々により採用されかつ該コンピューティングオペレーションの各々において用いられることが好ましい、ということを示すために用いられている。ＧＴＡ ｃｏｍｍｏｎ ＡＰＩは、ＧＴＡＰＵＴ，ＧＴＡＧＥＴ，ＧＴＡＣＭＩＴ，ＧＴＡＢＡＣＫ，ＧＴＡＴＥＲＭ，ＧＴＡＢＥＧＩＮというモジュールを包含し、これらのモジュールについては、より詳細に後述する。２つの最も一般的なモジュールは、メッセージ（ＧＴＡＰＵＴ）を送信しかつメッセージ（ＧＴＡＧＥＴ）を受信するために、アプリケーション２００により用いられる。
【００２４】
抽出層２１０の下方には、実際のトランスポート機構に対するインターフェースが存在する。図２には、トランスポート機構として用いられる２つの異なる形式のメッセージングミドルウェア、ＭＱＳｅｒｉｅｓ２６０およびＦＲＱＳ（Function Router Quene Subsystem）２４０が示されている。ＦＲＱＳ２４０は、本発明の譲受人により社内で開発されたプロプライエタリメッセージングミドルウェア製品である。ＭＱＳｅｒｉｅｓ２６０は、ＩＢＭ社により提供されるメッセージングミドルウェア製品であり、かつ、現在の所、メッセージングミドルウェア産業におけるデファクトスタンダードである。ＭＱＳｅｒｉｅｓ２６０の利用は、本発明の好ましい実施形態である。その理由は、ＭＱＳｅｒｉｅｓ２６０が、現在は、Ｗｉｎ ＮＴ，Ｗｉｎ ９５，Ｗｉｎ ９８，ＩＢＭ社のＡＩＸ Ｐｌａｔｆｏｒｍ，Ｓｕｎ Ｓｏｌａｒｉｓ，ＨＰＵＸ Ｐｌａｔｆｏｒｍｓを包含する（しかし、これらに制約されるものではない）３５の異なるプラットフォームに対して有効であるためである。
【００２５】
本発明については、ＤＥＣ Ｍｅｓｓａｇｅ Ｑのような任意のメッセージングミドルウェアとともに作動するように容易に適応させることができるが、本記載は、ＭＱＳｅｒｉｅｓ２６０およびＦＲＱＳ２４０製品に関してなされる。その理由は、本発明の工程が、これらのミドルウェア製品の両方に対して実行されるように限定されているためである。
【００２６】
図２に示されるように、ＧＴＡ ｃｏｍｍｏｎ ＡＰＩ２１０およびＦＲＱＳ２４０システム間のインターフェースは、さらなる抽出層を必要とせずに直結している。これに対し、ＭＱＳｅｒｉｅｓ２６０を用いたトランスポートのためにメッセージが意図されている場合には、２つのさらなる抽出層２２０または２３０、および２５０が存在する。本願発明者は、ＭＱＳｅｒｉｅｓ２６０には見出されないさらなる機能性を与えるために、ＧＴＡ Ｍｅｓｓａｇｉｎｇ（ＧＭＡ）層２２０を開発してきた。この点で、ＧＴＡ Ｍｅｓｓａｇｉｎｇのメッセージは、本来のＭＱＳｅｒｉｅｓメッセージのカスタマイズされた形式である。さらに後述するように、ＧＴＡ Ｍｅｓｓａｇｉｎｇにより与えられる機能性は、ブロック処理、非同期応答および達成（achieving）のための論理を有している。本発明のＧＴＡ Ｍｅｓｓａｇｉｎｇのアーキテクチャは、主に、メッセージに添付されたさらなるヘッダの利用によって達成される。これらのヘッダは、ＡＰＩが行うべき所望の処理（例えば、ブロック処理）のための命令を抽出するために、ＧＴＡ Ｍｅｓｓａｇｉｎｇ ＡＰＩにより読み出される。
【００２７】
パートナーアプリケーション（すなわち、メッセージ受信アプリケーション）がＧＴＡ Ｍｅｓｓａｇｉｎｇの機能性へのアクセスを有していないためにＧＴＡ Ｍｅｓｓａｇｉｎｇを受信することも解釈することもできない場合には、ＧＴＡ ｃｏｍｍｏｎ ＡＰＩは、Ｎａｔｉｖｅ ＭＱ Ｍｅｓｓａｇｉｎｇ層２３０を用いてメッセージを送信する能力を有する。トランスポート機構のためにＭＱＳｅｒｉｅｓ２６０を用いる全てのシステムは、Ｎａｔｉｖｅ ＭＱ Ｍｅｓｓａｇｉｎｇ層２３０により生成されたメッセージを受信することが可能である。
【００２８】
ＧＭＡ層２２０およびＮａｔｉｖｅ ＭＱ Ｍｅｓｓａｇｉｎｇ層２３０の下方には、ＭＱＳｅｒｉｅｓ Ａｂｓｔｒａｃｔｉｏｎ層２５０として示されるさらなる抽出層が存在する。この抽出層２５０は、本発明のアーキテクチャの簡略化をさらに促進するために、簡略化されたラッパー（wrapper）をＭＱＳｅｒｉｅｓ２６０の周囲に与える。ＭＱＳｅｒｉｅｓ Ａｂｓｔｒａｃｔｉｏｎ層２３０（ＧＭＱとしても知られている）は、ある一定のオプションをデフォルト化しかつ呼び出しストラクチャ（calling structure）を簡略化することにより、ＭＱＳｅｒｉｅｓコマンドを簡略化する。
【００２９】
図１に関して説明したＯＳＩモデルに関して、図２に示される本発明の抽出層２１０，２２０，２３０，２５０は、アプリケーション層１００、プレゼンテーション層１１０、セッション層１２０に対応する。図２のＭＱＳｅｒｉｅｓ２６０およびＦＲＱＳ２４０は、図１のトランスポート層１３０に対応する。
【００３０】
抽出は、アプリケーション２００を、特定のベンダー製品（例えば、ＭＱＳｅｒｉｅｓ２６０）に直接的に結びつけられることから解放する本発明の重要な概念である。さらに後述するように、本発明は、トランスポート機構に特有のディテールの大部分を包含するディレクトリの利用によって、ある一定の抽出レベルを達成する。抽出は、システム（この場合には、ＭＱＳｅｒｉｅｓ２６０およびＦＲＱＳ２４０）に関する簡略化された記述または仕様を得る方法であって、システムのディテールまたは特性の幾つかを際立たせ、その一方で、他のディテールまたは特性を抑制する。良好な抽出とは、ユーザーにとって重要なディテールを際立たせ、かつ、ユーザーが必要とする機能性にとって重要ではないディテールを抑制するものである。
【００３１】
層２０１〜２３０により与えられる抽出の例として、これらの抽出層２１０〜２３０はメッセージングを簡略化し、これにより、アプリケーション２００は、（メッセージそれ自体は別として）ＭＱＳｅｒｉｅｓ２６０がメッセージを送信する必要があるフィールドのうち、僅かなパーセンテージを供給する必要があるのみである。必要とされるフィールドの残りは、公衆ディレクトリからのデフォルトデータを用いて抽出層２１０〜２３０により占有される。さらに、抽出層２１０〜２３０は、アプリケーション２００が、ディレクトリにより与えられた限られた数のデフォルトフィールドよりも優先する（override）ことを可能にするのみである。
【００３２】
本発明は、抽出層２１０〜２３０における大部分の機能性を維持し、これにより、アプリケーション２００は、データフォーマットの差を感知および識別する必要がなくなる。万一アプリケーション２００がＭＱＳｅｒｉｅｓ２６０に対して直接的に通信することがあれば、メッセージの送信に関してアプリケーション２００が選択する必要があるオプションが非常に多く存在することになる。したがって、抽出層２１０〜２３０は、選択可能なオプションの数を低減させ、これにより、メッセージングタスクを簡略化する。したがって、このアーキテクチャは、安価で維持され、より短期のトレーニングしか必要とせず、かつ、トランスポート層２４０または２６０に対してアプリケーション２００が最大限のアクセスを有することを許容してしまうという本来の危険性を防ぐ。
【００３３】
層２１０〜２３０により与えられる抽出に関する特定の例として、ＭＱＳｅｒｉｅｓ２６０は、１〜１０の優先順位コードを有している。多数のアプリケーション２００がＭＱＳｅｒｉｅｓ２６０と直接的に通信し、かつ、各々のアプリケーション２００が、送信されている全てのメッセージに対して同じ優先順位（例えば、最も高い優先順位）を設定すれば、優先順位の機能は無意味となり、かつ、どのメッセージも、より高い優先順位によって送信されないことになる。本発明の抽出層２１０〜２３０において、全ての要求は、等しい優先順位にて処理されるものとして開始される。アプリケーション２００が１〜１０というＭＱＳｅｒｉｅｓに特有の優先順位を割り当てることを許容する代わりに、アプリケーション２００は、現在割り当てられている優先順位の上昇または下降を指定することができるのみである。
【００３４】
概して、抽出により生じる簡略化は、ある機能性を減ずる結果となる。大部分のメッセージングミドルウェア（例えば、ＭＱＳｅｒｉｅｓ２６０）が最も広範なユーザーを満足させるように開発されているので、本発明によるシステムにおいて、抽出層２１０〜２３０は、システムによりサービスされるアプリケーション２００が必要とする機能性のみを与えるように開発されている。幾つかの場合には、機能性の除去は、実際には、システムの必要性である。例えば、本発明の好ましい実施形態において、システムは、バンキング環境において動作する。この環境においては、金銭の振替を示すメッセージをユーザーが再ルーティング（rerouting）して、これによりその金銭を事実上着服してしまうことを防ぐために、ダイナミックメッセージングキューに対するアクセスまたは変化を防ぐことが望ましい。
【００３５】
図３は、ＧＴＡ ｃｏｍｍｏｎ ＡＰＩ２１０（図２を参照）メッセージ送信モジュールＧＴＡＰＵＴ３００のキーモジュールの１つのオペレーションを示す。モジュールＧＴＡＰＵＴ３００は、メッセージを送信する必要がある場合には、アプリケーション２０１と称される。アプリケーション２０１は、送信すべきメッセージと、メッセージに関する特定の処理（例えば、ブロック処理）の必要性を示す制御ブロックとによって、ＧＴＡＰＵＴ３００の実例を示す。
【００３６】
本発明の好ましい実施形態において、顧客情報制御システム（ＣＩＣＳ）の下で実行されるアプリケーションは、共通領域または一時的な貯蔵キュー（storage queue）を用いてメッセージおよび制御ブロックをＧＴＡＰＵＴモジュール３００へ渡す。分散されたプラットフォーム上において、ＧＴＡＰＵＴ３００は、ランタイムにおいてアプリケーション２０１に動的にリンクされる。リンクは、ランタイムライブラリを実行可能プログラムに変換する処理である。本発明のメッセージングアーキテクチャは、トランザクション処理（ＴＰ）モニタがある場合およびない場合のアプリケーションの作業論理ユニットをサポートしている。ＣＩＣＳのようにＴＰモニタがある場合のプラットフォームに関して、アーキテクチャは、ＴＰモニタの委託（commit）またはロールバックに関係する。ＴＰモニタがない場合には、本発明は、アプリケーションが、未定状態のＧＴＡＰＵＴまたはＧＴＡＧＥＴオペレーションを委託またはロールバックするために、ＧＴＡＣＭＩＴコマンドおよびＧＴＡＢＡＣＫコマンド（図２の２１０を参照）を明確に発行することを可能にする。
【００３７】
アプリケーション２０１は、複数のリソースにわたってのデータの完全無欠さを維持するために、作業論理ユニット（Logical Unit of Work：ＬＵＷ）を管理する必要がある。メッセージを入れるかまたは得る場合に、アプリケーション２０１は、適切な呼び出しオプションを用いることにより、メッセージがＬＵＷの一部であるかどうかを指定する必要がある。ＧＴＡＰＵＴおよびＧＴＡＧＥＴ ＡＰＩ実行メッセージ演算は、未定状態の（pending）入力および獲得を行うために、基底にあるサービス層（図２の２５０，２６０）を用いる。アプリケーション２０１がＧＴＡＣＭＩＴを発行する場合に、モジュールは、未定状態のメッセージ演算を委託するために、基底にあるサービス層を用いる。逆に、ＧＴＡＢＡＣＫコマンドは、本発明において、未定状態のメッセージ演算をロールバックする取り消し（backout）コマンドである。ＧＴＡＢＥＧＩＮへの呼び出しは、作業ユニット（この作業ユニットは、キューマネージャにより調整され、かつ、他のリソースマネージャにより所有されるリソースに対する変化を伴う）を開始させるために用いられる。
【００３８】
アプリケーション２０１によりＧＴＡＰＵＴ２００へ送信された制御ブロックは、トランスポート層（この場合は、ＭＱＳｅｒｉｅｓ２６０）への通過のためのメッセージをＧＴＡＰＵＴ３００が準備することを可能にするパラメータを有する。前述したように、抽出層２１０（図２を参照）への通過のためのアプリケーション２０１にとって有効なパラメータは、意図的に制約される。その理由は、本発明のアーキテクチャは可能な限り簡素であることが望ましいためである。
【００３９】
アプリケーション２０１によりＧＴＡＰＵＴ３００へ渡された制約パラメータは、ＭＱＳｅｒｉｅｓ２６０により必要とされるパラメータの全量をディレクトリ３１０から回収する（retrieve）。これらのパラメータの大部分は、アプリケーション２０１二より指定された制約パラメータに基づいてディレクトリ３１０から回収されたデフォルトパラメータである。ＭＱＳｅｒｉｅｓ２６０は、その処理を全て実行してしまった後に、メッセージ３４０をその最終的な形式で、物理トランスポート機構上で送信する。図３に示される記録３２０，３３０は、より詳細に後述するように、アーカイブ記録およびトレース記録をそれぞれ表す。アーカイブおよびトレースは、ディレクトリ３１０において設定されるオプションである。本発明の好ましい実施形態においては、アーカイブおよびトレースをメッセージに対してターンオンおよびターンオフすることは、アプリケーション２０１には与えられていない。むしろ、アーカイブおよびトレースは、ディレクトリ３１０において見出される設定にしたがって、イネーブル状態／ディスエーブル状態にされる。
【００４０】
本発明における約定の問題として、ディレクトリ３１０、ＭＱＳｅｒｉｅｓ２６０、ＧＴＡ Ｍｅｓｓａｇｉｎｇ ＡＰＩ（例えば、ＧＴＡＰＵＴ３００）には、同じキャラクタ指定を与える。これらのモジュール、テーブル、インターフェースが、異なる物理的位置において異なる物理的エンティティとして存在でき、また、確かに存在することが容易に理解されるが、各々により供給される機能は、設置されかつ用いられる場所に関わらず同じである。例えば、モジュールＧＴＡＰＵＴ３００の基本的機能は、ニューヨークにあるプラットフォーム上にある場合でも、ロンドンまたはダラスにあるプラットフォーム上にある場合と同じである。ディレクトリ３１０に関して、ある位置にあるディレクトリ３１０は、プラットフォーム上に存在するアプリケーションをサポートするために必要な異なるエントリーを当然備え、その一方で、異なるプラットフォーム上にあるディレクトリ３１０は、そのプラットフォーム上にあるアプリケーションをサポートするために必要なエントリーを有する。
【００４１】
図４は、本発明による、メッセージを送信する際に用いられる種々のコンポーネント間における相互作用を、より詳細に示す。前述したように、アプリケーション２０１は、メッセージと幾つかの制御ブロックとをＧＴＡＰＵＴ３００に渡すことにより、メッセージ送信演算を開始する。アプリケーション２０１によりＧＴＡＰＵＴ３００に渡される２つの最も重要な制御ブロックは、要求ブロック（request block）およびリターンブロック（return block）である。要求ブロックは、発信メッセージを処理するためにＧＴＡＰＵＴ３００が必要とする全てのパラメータを備え、かつ、リターンブロックは、アプリケーション２０１がメッセージの送信に関して何らかのフィードバックを所望する場合に必要な全てのパラメータを備える。
【００４２】
リターンブロックに備えられる最も重要なパラメータは、サービス識別子と称される。サービス識別子は、ＧＴＡＰＵＴ３００により、メッセージを送信するために必要な全てのディテールを記入すべくディレクトリ３１０にアクセスするための鍵として用いられる。ディレクトリ３１０に関してはさらに後述するように、各々のサービス識別子は、ＧＴＡＰＵＴ３００がメッセージを送信（または受信）すべくＭＱＳｅｒｉｅｓ２６０とインターフェース接続するために利用できる異なったデフォルトパラメータのセットを指す。単一のサービス識別子およびディレクトリアーキテクチャを用いた結果として、本発明は、アプリケーション２０１が、メッセージのトランスポートに関するあらゆるディテールから解放されることを可能にする。ＭＱＳｅｒｉｅｓ２６０は、図４に示されるように、（その広い商業的受容度に起因して）好ましいトランスポート層であるが、ＦＲＱＳ４００のような他のトランスポート機構を用いることもできる。本発明のアーキテクチャから逸脱することなく、他のトランスポート機構を利用できることが容易に理解される。
【００４３】
アプリケーション２０１は、通常は、自らのメッセージに関する所定の宛先を有している。例えば、位置Ａのプラットフォーム上で実行されるアプリケーション２０１は、ある形式のメッセージを、位置Ｂのプラットフォーム上で実行される第２アプリケーションへ送信するための規則的な必要性を、および、異なる形式のメッセージを、位置Ｃのさらに異なるプラットフォームへ送信するための規則的な必要性を有している。本発明のアーキテクチャを用いて、第１サービス識別子（例えば、Ｓｅｒ＿Ｉｄ＿Ｂ）は、位置Ｂのアプリケーションへメッセージを送信するのに必要とされる全てのディテールを指し、かつ、第２サービス識別子（例えば、Ｓｅｒ＿Ｉｄ＿Ｃ）は、位置Ｃのアプリケーションへメッセージを送信するのに必要とされるディテールを指すように設定される。
【００４４】
アプリケーション２０１が位置Ｂのアプリケーションへメッセージを送信する必要がある場合には、該アプリケーション２０１は、サービス識別子Ｓｅｒ＿Ｉｄ＿Ｂを指定する要求ブロックによってＧＴＡＰＵＴ３００を呼び出す。サービス識別子Ｓｅｒ＿Ｉｄ＿Ｂを用いて、ＧＴＡＰＵＴ３００は、メッセージを送信するためにＭＱＳｅｒｉｅｓ２６０により必要とされる全てのパラメータを識別するために、本質的にディレクトリ３１０内のルックアップであることを実行する。この例においては、アプリケーション２０１が何のオーバーライドも指定しなければ、メッセージを送信するために必要とされる全てのパラメータは、サービス識別子Ｓｅｒ＿Ｉｄ＿Ｂに関してディレクトリ３１０内に見出されるデフォルトパラメータである。手元にある全てのデフォルトパラメータによって、メッセージはＭＱＳｅｒｉｅｓ２６０へ渡され、該ＭＱＳｅｒｉｅｓ２６０は、物理伝送手段を介して発信メッセージを伝送する。
【００４５】
サービス識別子以外に、アプリケーション２０１からの要求ブロックは、送信されているメッセージがブロックの一部であるかどうかを識別するブロックインジケータと、（ディレクトリ内に見出される）デフォルトよりも高いかまたは低い優先順位がメッセージを送信するために用いられるべきかどうかを示す優先順位フラグとを有することができる。
【００４６】
様々な形式のメッセージが様々な形式のコンフィギュレーション（例えば、優先順位や持続性）を要求するという必要性をアプリケーション２０１が有していれば、別個のサービス識別子が、様々なコンフィギュレーションに対して存在する。この質素なアーキテクチャを固守することにより、これらのコンフィギュレーションに対する将来的な変更については、アプリケーション２０１のコードを変更することなく、ディレクトリ３１０内の変更により行うことができる。
【００４７】
さらに、前述した例において、位置Ｂまたは位置Ｃのいずれかのプラットフォーム内で変更があれば（プラットフォームがＡＩＸプラットフォームに変更されれば）、アプリケーション２０１に対しては何の変化も必要とされない。様々なプラットフォームを収容するために必要とされる変更は、ディレクトリ３１０内で行われる。同様に、アプリケーション２０１がメッセージを送信する宛先である受信アプリケーションが新たな位置Ｄへ移動すれば、メッセージングトランスポートのディテールを有するディレクトリ３１０のみを変更する必要がある。前述した変更の筋書きのいずれにおいても、アプリケーションＡは、なおも、全く同じサービス識別子（例えば、Ｓｅｒ＿Ｉｄ＿ＢまたはＳｅｒ＿Ｉｄ＿Ｃ）を用いてメッセージを送信し、かつ、アプリケーション２０１に対しては何の変化も必要とされない。
【００４８】
ＧＴＡＰＵＴ３００は、アプリケーション２０１が非同期にメッセージを送信するために用いられる。このことは、同期的に生じる（すなわち、所定のまたは規則的な間隔で生じる）メッセージングを必要としていた従来技術によるメッセージに対する重大な利点である。本発明による非同期メッセージングアーキテクチャのさらなる重大な利点は、このような変更が前述したように生じれば、変更をテストするために必要とされる全てのテストを、他のアプリケーションに悪影響を与えずに行うことができることである。例えば、アプリケーション２０１内で変更があれば、該アプリケーション２０１は、自らのメッセージを非同期で送信することができ、このメッセージについては、受信アプリケーションの準備ができている場合にはこの受信アプリケーションにより受信しかつ処理することができる。従来技術による同期メッセージングシステムにおいて、送信アプリケーションおよび受信アプリケーションの両方は、このようなテストに対してオフラインを選ぶ必要があり、この結果として、テストに関連した著しい費用がかかっていた。本発明の非同期性質は、テストに関連したこれら全ての費用を回避する。
【００４９】
図４に示されるように、ＧＴＡＰＵＴ３００は、ディレクトリサービスインターフェースモジュール（ＧＩＤＩＲＳＶＣ）４１０を呼び出して、送信アプリケーション２０１に関連するコンフィギュレーション情報を回収する。この呼び出しは、要求ブロック内のアプリケーション２０１により指定されたサービス識別子を用いてなされる。アプリケーション２０１は様々なサービスにアクセスするためにＧＴＡＰＵＴ３００を何度も用いることができるので、アプリケーション２０１は、前述したようなサービス識別子を多数必要とし得る。
【００５０】
サービス識別子の他に、送信アプリケーション２０１は、送信アプリケーションの名前および送信サブシステムを指定して、ディレクトリ３１０に対する３つの部分キーを形成する。アプリケーションの名前は、メッセージングを用いて、アプリケーションの成分を独自に識別する。これは、例えば、セキュリティの移動および会計システムに関するポストトレードコンポーネント（post trade component）である。前記サブシステムは、メッセージング関数を発行する成分が属するアプリケーションシステムを識別する。これは、例えば、セキュリティの移動および会計システムである。前述したように、サービス識別子は、アプリケーション成分が要求しているメッセージングサービスを独自に識別する。
【００５１】
さらに後述するように、アプリケーション２０１がメッセージを受信する場合には、アプリケーション２０１は、適切にディレクトリ３１０にアクセスするために、受信アプリケーションの名前と、受信サブシステムと、受信サービス識別子とを同様に供給する必要がある。
【００５２】
図５は、ディレクトリ３１０、および、Ｓｅｎｄ＿Ｔｒａｄｅ３１８，Ｄｅｆａｕｌｔ＿Ｐｕｔ３１９という２つの異なるサービス識別子に対する、該ディレクトリ３１０のエントリーの例を示す。各々のディレクトリエントリーは、サービス識別子３１２、サブシステム識別子３１４、およびアプリケーション識別子３１６の独自の組み合わせに対応している。以下に、ディレクトリ３１０内に備えることができるフィールドに関する簡単な説明を記す。以下に説明されるエントリーが全て図５に示されているわけではない。
【００５３】
Ａｒｃｈｉｖｅ Ｑ Ｏｐｅｎ Ｏｐｔｉｏｎフィールドは、ＧＴＡ Ｍｅｓｓａｇｉｎｇアーキテクチャがアーカイブキューを開くべきモードを示す。
【００５４】
Ａｒｃｈｉｖｅ Ｑｕｅｕｅフィールドは、アーカイバルな目的のためにメッセージの正確なコピーを送信するキューを指定する。このメッセージは、元のメッセージと同じＧＴＡヘッダおよびＭＱメッセージＩＤを有する。送信側においてアーカイブ保管されていれば、この項は、「再送信（Resend）」となり、受信側においてアーカイブ保管されていれば、この項は、「再生（Replay）」となる。
【００５５】
Ａｒｃｈｉｖｅ Ｑｕｅｕｅ Ｍａｎａｇｅｒフィールドは、アーカイブキューが配置されるキューマネージャを指定する。このフィールドは、プラットフォームのためのデフォルトキューマネージャを有するが、任意の遠隔キューマネージャとして指定され得る。
【００５６】
Ｄｅｓｔｉｎａｔｉｏｎ Ｑｕｅｕｅ Ｏｐｅｎ Ｏｐｔｉｏｎフィールドは、ＧＴＡ Ｍｅｓｓａｇｉｎｇアーキテクチャが宛先キューを開くべきモードを示す。
【００５７】
Ｄｅｓｔｉｎａｔｉｏｎ Ｑｕｅｕｅフィールドは、メッセージを送信するキューを指定する。このフィールドは、ＧＴＡＰＵＴ演算においてのみ用いられ、かつ、リターンブロックを介して、送信アプリケーションに返される。
【００５８】
Ｄｅｓｔｉｎａｔｉｏｎ Ｑｕｅｕｅ Ｍａｎａｇｅｒフィールドは、メッセージを送信しているキューマネージャを列挙する。このフィールドにおいて指定されたマネージャについては、宛先キューと関連して設定する必要がある。
【００５９】
本発明の一実施形態において、Ｅｒｒｏｒ Ｑｕｅｕｅ Ｍｅｓｓａｇｅフィールドは、エラーメッセージの送信先であるキューを指定する。キューから回収されたメッセージは、これらのメッセージを保持するためにアプリケーションにより割り当てられたメモリを超過し得る。この場合であれば、ＧＴＡ Ｍｅｓｓａｇｉｎｇアーキテクチャは、重大なエラーが生じたことを示し、かつ、このフィールドにおいて指定されたエラーキューへメッセージを転送する。可能性のある設定には、メッセージの送信元であるキューへメッセージを返信すること、デッドレターキューまたは特定用途向けエラーキューへメッセージを送信することが包含される。
【００６０】
Ｅｒｒｏｒ Ｑｕｅｕｅ Ｍａｎａｇｅｒフィールドは、エラーキューが存在するキューマネージャを有する。
【００６１】
Ｉｎｐｕｔ Ｏｐｅｎ Ｏｐｉｎｉｏｎフィールドは、ＧＴＡ ＭｅｓｓａｇｉｎｇアーキテクチャＡＰＩが入力キューを開くべきモードを示す。
【００６２】
Ｉｎｐｕｔ Ｑｕｅｕｅフィールドは、ＧＴＡＧＥＴ演算が着信メッセージを回収するために用いるキューを記述する（ＧＴＡＧＥＴに関しては後述の記載を参照）。ＭＱＳｅｒｉｅｓはローカルキューマネージャからメッセージを得ることをサポートするのみなので、何の入力キューマネージャも定義する必要がない。
【００６３】
ＬＵＷ Ｏｖｅｒｒｉｄｅ Ｆｌａｇフィールドは、アプリケーション２０１が作業論理ユニット（ＬＵＷ）制御にオーバーライドできるかどうかを、かつ、当該のＬＵＷの外側にメッセージを配することができるかどうかを示す。アプリケーション２０１は、メッセージング演算を当該の作業論理ユニット内に備えるべきかどうかを、要求ブロックにおいて指定することができる。
【００６４】
Ｍｅｓｓａｇｅ Ｆｏｒｍａｔフィールドは、設置されているメッセージがＭＱＳＴＲ形式かまたはＧＴＡ＿ＶＡ形式かを指定するために用いられる。これらの形式は、フラット（テキスト）データおよび２進データにそれぞれ対応する。ＧＴＡディレクトリサービス内のこのフィールドのために有効な設定は、０  ＭＱＳＴＲフォーマット；１  ＧＴＡ＿ＶＡフォーマットである。このフィールドは、メッセージヘッダのフォーマットフィールドを存在させる（populate）ためのアーキテクチャ内において用いられる。受信アプリケーションは、メッセージを回収に基づいて変換すべきかどうかを決定するために、このフィールドを用いる。
【００６５】
Ｍｅｓｓａｇｅ Ｐｅｒｓｉｓｔｅｎｃｅフィールドは、メッセージを送信する場合に何の持続性（persistence）を用いるべきかを示す。持続性は、キューマネージャが無効になった場合にキュー上のメッセージに生じることに関係する。持続性メッセージは、ログファイルとして記録され、かつ、キューマネージャが無効になった場合に失われないように、ＭＱＳｅｒｉｅｓ２６０により保証される。非持続性メッセージは、ログファイルとして記録されず、かつ、キューマネージャが無効になった場合にキューから除去されるように、ＭＱＳｅｒｉｅｓ２６０により保証される。ログファイルとして記録する結果として、持続性メッセージの利用は、性能面での悪影響を招く。
【００６６】
Ｍｅｓｓａｇｅ Ｐｒｉｏｒｉｔｙフィールドは、メッセージに割り当てられたデフォルト優先順位を有する。優先順位の設定は、あるメッセージが、優先順位をつけられたキュー上の他の設定に優先することを可能にする。好ましい実施形態においては、メッセージングアーキテクチャにおける全てのキューは、優先順位メッセージングをサポートする。好ましい実施形態におけるＧＴＡ Ｍｅｓｓａｇｉｎｇによりサポートされる優先順位の範囲は、０〜９である。５〜７という範囲は、アプリケーションメッセージのために予備とされており、５は標準よりも低く、６はデフォルト優先順位であり、かつ、７は、高い優先順位または緊急メッセージのためのものである。
【００６７】
Ｎａｔｉｖｅ ＭＱ Ｍｅｓｓａｇｉｎｇ Ｆｌａｇフィールドは、ＧＴＡメッセージまたは固有の（native）ＭＱメッセージが送信されているのか、または、回収されているのかを決定するために用いられる。固有のＭＱメッセージがターンオフされると、（全てのＧＴＡに特有のヘッダを備えた）ＧＴＡメッセージが送信される／期待される。そうでない場合には、ＧＴＡに特有の情報を何も備えていないメッセージが送信される／期待される。このフィールドのために有効な設定は次の通りである：Ｙ＝Ｎａｔｉｖｅ ＭＱメッセージングがターンオンされる；Ｎ＝Ｎａｔｉｖｅ ＭＱメッセージングがターンオフされる（この場合、ＧＴＡ Ｍｅｓｓａｇｉｎｇが用いられる）。
【００６８】
Ｒｅｐｌａｙ Ａｒｃｈｉｖｅ Ｆｌａｇフィールドは、メッセージのコピーを回収する際にこれをアーカイブ保管すべきかどうかを示す。これは、ＧＴＡＧＥＴのための標準的なアーカイブ機構である。
【００６９】
Ｒｅｐｌｙ ｔｏ Ａｐｐｌｉｃａｔｉｏｎフィールド、Ｒｅｐｌｙ ｔｏ Ｓｅｒｖｉｃｅフィールド、および、Ｒｅｐｌｙ ｔｏ Ｓｕｂｓｙｓｔｅｍフィールドは、返答する際に受信機がどのディレクトリエントリーを用いる必要があるのか命令する。アーキテクチャが集中ディレクトリサービスの代わりに分散ディレクトリサービスを用いる場合には、アプリケーションを受け取るアプリケーションが、返答する際に正しいディレクトリエントリーを用いることを保証するメッセージを伴って情報に対する返答を渡すことが必要となる。これらのＲｅｐｌｙ ｔｏ Ａｐｐｌｉｃａｔｉｏｎキー、Ｒｅｐｌｙ ｔｏ Ｓｅｒｖｉｃｅキー、および、Ｒｅｐｌｙ ｔｏ Ｓｕｂｓｙｓｔｅｍキーについては、応答が必要な場合のみに存在させるべきである。応答が必要とされない場合には、これらのフィールドは空白の状態にされる。これらのフィールドが存在すれば、受信アプリケーションは、返答が必要とされているものと想定する。
【００７０】
Ｒｅｓｅｎｄ Ａｒｃｈｉｖｅ Ｆｌａｇは、メッセージを送信側でアーカイブすべきかどうかを示す。これは、ＧＴＡＰＵＴ３００内で用いられる標準のアーカイビングである。アーカイブされたメッセージは、元のメッセージ内に見られかつ同じメッセージ識別子を有する全ての同じ情報を有する。これは、Ａｒｃｈｉｖｅ Ｑｕｅｕｅ Ｍａｎａｇｅｒ，Ａｒｃｈｉｖｅ Ｑｕｅｕｅに配される。
【００７１】
Ｔｒａｃｅ Ｆｌａｇフィールドは、所定のサービス識別子３１２に対してトレーシングがターンオンされるかどうかを示す。トレーシングメッセージについては、メッセージ処理されているかどうかを検出するための調停（reconciliation）処理を可能にするために、中央に集められた位置に送信することができる。
【００７２】
Ｔｒａｃｅ Ｏｐｅｎ Ｏｐｔｉｏｎフィールドは、トレーシングメッセージを送信する場合に用いられる。
【００７３】
Ｔｒａｃｅ Ｐｅｒｓｉｓｔｅｎｃｅフィールドは、トレーシングメッセージを送信する場合に何の持続性を用いるべきかを示す。持続性は、キューマネージャが落とされる際にキュー上のメッセージに発生することに関係する。持続性メッセージは、ログファイルとして記録され、かつ、キューマネージャが落とされるる場合に失われないようにＭＱＳｅｒｉｅｓ２６０により保証される。非持続性メッセージは、ログファイルとして記録されず、かつ、キューマネージャが落とされる場合にキューから除去されるようにＭＱＳｅｒｉｅｓ２６０により保証される。ログファイルとして記録した結果、持続性メッセージの利用は、性能に悪影響を招く。Ｔｒａｃｅ Ｐｅｒｓｉｓｔｅｎｃｅのために有効な設定は次の通りである；０−肘属性（デフォルト），１−持続性。
【００７４】
Ｔｒａｃｅ Ｐｒｉｏｒｉｔｙフィールドは、あるメッセージが、優先順位をつけられたキュー上の他のメッセージに優先することを可能にする。好ましい実施形態においては、このメッセージングアーキテクチャにおける全てのキューは、優先順位メッセージングをサポートしている。前述したように、本発明の好ましい実施形態において、ＧＴＡ Ｍｅｓｓａｇｉｎｇによりサポートされた優先順位の範囲は、０〜９である。５〜７という範囲は、アプリケーションメッセージのために予備とされており、５は標準よりも低く、６はデフォルト優先順位であり、かつ、７は高い優先順位または緊急メッセージのためのものである。したがって、トレースメッセージのためのデフォルト設定は、４（すなわち、全てのアプリケーションメッセージよりも低い）である。
【００７５】
Ｔｒａｃｅ Ｑｕｅｕｅフィールドは、このアプリケーションのためにトレース記録を送信すべきキューを記述している。
【００７６】
Ｔｒａｃｅ Ｑｕｅｕｅ Ｍａｎａｇｅｒフィールドは、トレースキューが存在するキューマネージャを有している。
【００７７】
Ｔｒａｎｓｐｏｒｔ Ｍｅｔｈｏｄフィールドは、トランスポート機構（例えば、ＭＱＳｅｒｉｅｓ２６０）がこのメッセージのために用いられるべきであることを記述している。
【００７８】
Ｗａｉｔ Ｆｌａｇは、メッセージを回収する際に、メッセージが到着するのをアプリケーションが待機するかどうかを示し、かつ、要求されたメッセージがキュー上に存在しなければ該アプリケーションが直ちに出ていくかどうかを示す。このエントリーのために有効な値は次の通りである；Ｙ−メッセージがキューに到着するのを待機する，Ｎ−メッセージがキューに到着するのを待機しない。
【００７９】
Ｗａｉｔ Ｉｎｔｅｒｖａｌフィールドは、メッセージを待機する際のタイムアウト間隔を設定する。
【００８０】
図４を参照すると、ディレクトリサービスモジュールＧＩＤＩＲＳＵＣ４１０によりディレクトリ３１０から回収された情報に基づいて、ＧＴＡＰＵＴ３００は、選択されたトランスポート方法のためにメッセージをフォーマットする準備ができている。前述したように、本発明の好ましい実施形態においては、ＭＱＳｅｒｉｅｓ（４４０，４５０）を用いたＧＴＡ Ｍｅｓｓａｇｉｎｇ、ＭＱＳｅｒｉｅｓ（４６０，４７０）を用いたネイティブ（native）ＭＱメッセージング、およびＦＲＱＳメッセージング（４００，４２０，４３０）、という３つの異なるトランスポート方法がサポートされている。
【００８１】
前述したように、ＦＲＱＳは、本発明の譲受人により社内で開発されたプロプライエタリトランスポート方法である。ＦＲＱＳは、本発明のいかなる部分も形成していないが、ＦＲＱＳに関する説明は、ＭＱＳｅｒｉｅｓ２６０以外のトランスポート機構による本発明のオペレーションを例示するために本明細書に包含されている。ＦＲＱＳメッセージングが、選択されたトランスポート方法であれば、モジュールＦＲＱＳ＿ＰＵＴ４００が、Ｔｒａｎｓｉｅｎｔ Ｄａｔａ Ｑｕｅｕｅ４２０へメッセージを配するために呼び出され、該Ｔｒａｎｓｉｅｎｔ Ｄａｔａ Ｑｕｅｕｅ４２０は、Ｖｉｒｔｕａｌ Ｓｔｏｒａｇｅ Ａｃｃｅｓｓ Ｍｅｔｈｏｄ（ＶＳＡＭ）ファイル４３０内にメッセージを配する。受信アプリケーションは、次に、ＶＳＡＭファイル４３０からメッセージを回収する。
【００８２】
ＦＲＱＳメッセージングが選択されなければ、メッセージは、ＧＴＡ Ｍｅｓｓａｇｉｎｇ（４４０，４５０）を用いて送信されるか、または、ネイティブＭＱメッセージング（４４０，４６０）を用いて送信される。前述したように、ＧＴＡ ＭｅｓｓａｇｉｎｇとネイティブＭＱメッセージングとの差は、ＧＴＡ Ｍｅｓｓａｇｉｎｇが、ＭＱＳｅｒｉｅｓ２６０により提供されていない特別の機能性（例えば、ブロックメッセージング）を提供することである。ＧＴＡメッセージ、またはインフラストラクチャメッセージは、ＧＴＡに特有のヘッダおよびトレイラを備えたアプリケーションデータとして定義されている。ネイティブＭＱメッセージは、ＧＴＡに特有のヘッダおよびトレイラのいずれも備えていないアプリケーションデータのみを有する。両方の形式のメッセージをサポートするために、本発明は、メッセージを送信または回収するためにネイティブＭＱメッセージングを用いるべきかまたはＧＴＡ Ｍｅｓｓａｇｉｎｇを用いるべきかを決定するために、ディレクトリ３１０内において維持されるコンフィギュレーションを用いる。したがって、ネイティブＭＱメッセージングの利用を必要とするアプリケーション２０１は、ネイティブＭＱメッセージの送信または回収を示すために適切にコンフィギュアされる（サービス識別子を介しての）サービスを要求する必要がある。適切なサービスを利用し損なえば、ＧＴＡメッセージが送信されるか、または、ＧＴＡメッセージの回収が試みられるという結果となり、このことは、最終的にエラーの要因となる。
【００８３】
ＧＭＡＳＥＴＵＰ４４０は、キューマネージャとローカル／遠隔キューオブジェクト接続とを確立するために必要な処理を実行する。ＧＭＡＳＥＴＵＰ４４０は、ＧＴＡ ＭｅｓｓａｇｉｎｇおよびネイティブＭＱメッセージングの両方のために用いられる。適切なキューマネージャ名および／またはキューオブジェクト名がディレクトリ３１０から供給されているので、このモジュール４４０は、呼び出しアプリケーション２０１により要求される際に、キューマネージャハンドルおよび／またはキューオブジェクトハンドルを戻す。情報は、後続のモジュールが参照することができる構造内にセーブされる。オブジェクト指向環境（例えば、Ｃ＋＋）において、ＧＭＡＳＥＴＵＰ４４０は、アプリケーション２０１を、キューマネージャと、全ての関連するローカル／遠隔キューオブジェクト（要求、応答、トレース／監査、アーカイブ）とに接続する。ＣＩＣＳ内において、ＧＭＡＳＥＴＵＰ４４０はキューマネージャに接続される必要はない。その理由は、この接続がＣＩＣＳによりオープン状態に保持されているためである。しかしながら、ＧＭＡＳＥＴＵＰ４４０は、なおも、（ディレクトリ３１０内におけるデフォルトとして指定されているような）アプリケーション２０１が用いるキューをオープンにする必要がある。ＣＩＣＳの外部では、ＧＭＡＳＥＴＵＰ４４０は、適切なキューマネージャに接続される必要があり、かつ、アプリケーション２０１が用いる適切なキューをオープンにする必要がある。
【００８４】
ＧＴＡ Ｍｅｓｓａｇｉｎｇに関して、ＧＭＡＳＥＮＤＭモジュール４５０は、少なくとも１つのメッセージを、Ｍｅｓｓａｇｅ Ｐｒｏｃｅｓｓｉｎｇ Ｓｅｒｖｅｒ（これについては後述する）の要求キューへ非同期に送信する。このモジュール４５０は、回収されたディレクトリ３１０の情報から指定されるような適切なＭＱおよびＧＴＡアーキテクチャオプションを設定し、適切なメッセージ処理のためにＧＴＡアーキテクチャヘッダおよびＭＱＭＤ（ＭＱメッセージ記述子）に記入し、かつ、作業論理ユニットに関係する。
【００８５】
メッセージについては、キュー上のメッセージのためのデフォルト優先順位に優先するディレクトリ３１０内の値に基づく特有の優先順位によって送信することができる。ブロック処理（これについては後述する）に関して、ＧＭＡＳＥＮＤＭ４５０は、相関ＩＤを受け入れることができるか、または、これを生成するＭＱ層に影響を及ぼすことができる。この相関ＩＤは、ＭＱメッセージヘッダ内のＣｏｒｒｅｌＩＤフィールドに保持される。シーケンス番号は、ＧＴＡアーキテクチャヘッダブロックを存在させるために用いられる。このことは、回収側のブロックから見当たらないメッセージの検出を促進する。
【００８６】
ネイティブＭＱメッセージングに関して、モジュールＧＭＡＳＥＮＤＭＱ４６０は、ネイティブＭＱメッセージを送信する責任を担う。このモジュール４６０は、適切なＭＱＭＤ（ヘッダ）フィールドを設定し、適用可能であればアーカイブメッセージおよびトレースメッセージを送信し、かつ、ＭＱＳｅｒｉｅｓ２６０を用いてアプリケーションデータを送信する。ＧＭＡＳＥＮＤＭ４５０のように、ＧＭＡＳＥＮＤＭＱ４６０は、メッセージを非同期に送信する。ＧＭＡＳＥＮＤＭＱ４６０は、作業論理ユニット（ＬＵＷ）内のメッセージを包含または除外するための適切なオプションを設定する。適切な優先順位の値および持続性の値は、呼び出しアプリケーションにより（通常は、ディレクトリ３１０から得られるデフォルト値から）渡される値に基づいて設定される。ＧＭＡＳＥＮＤＭＱ４６０は、メッセージを送信する前に、アーキテクチャヘッダを添付する。ＧＭＡＳＥＮＤＭＱ４６０は、さらに、適切なオプションが設定されていれば、アーカイブおよびトレース記録を生成する。
【００８７】
図４には、宛先キュー４７０、アーカイバルキュー４７５、トレース／監査キュー４８０が概略的に示されている。これらのキューの各々は、ＭＱＳｅｒｉｅｓ２６０により管理される。宛先キュー４７０は、メッセージ受信位置におけるキューを表す。アーカイバルキュー４７５は、メッセージをアーカイブするために用いられるキューであり、かつ、Ｔｒａｃｅ Ｑｕｅｕｅはメッセージの伝送をトレースするために用いられ、これらについては、共に、より詳細に後述する。
【００８８】
図６は、抽出層２１０（図２）ＧＴＡＧＥＴ５００の他の重要なモジュールの１つのオペレーションを示す。ＧＴＡＧＥＴ５００は、トランスポート層（例えば、ＭＱＳｅｒｉｅｓ２６０）からメッセージを受信する機能を行うモジュールである。メッセージ３４０がその宛先キュー上において受信されると、ＭＱＳｅｒｉｅｓ２６０またはＦＲＱＳ４００（図４）のいずれかを介して、受信アプリケーション２０２がトリガリングされる。この作用は、コンフィギュラブル（configurable）であるので、ある一定のアプリケーション２０２は、何らかの識別された作用に基づいてトリガリングされるよりも、むしろポーリングすることを選択することができる。ポーリングは、ステータス情報を得るためにトランスポート層へコマンドを発行するための公知の管理技術である。ポーリングについては、タイムアウト間隔によって行うことができる。
【００８９】
いったん、受信アプリケーション２０２がメッセージ３４０の到着に気づくと、受信アプリケーション２０２は、ＧＴＡＧＥＴ５００を用いてメッセージ５００を受信する。ＧＴＡＰＵＴ３００によってメッセージを送信するように、受信アプリケーション２０２は、ＧＴＡＧＥＴ５００を呼び出し、かつ、要求されたサービス識別子を包含するメッセージバッファおよびパラメータを渡す。ＧＴＡＧＥＴ５００は、渡されたパラメータを用いて、アプリケーション名とサブシステム識別子とサービス識別子とに基づいて、コンフィギュレーション設定に関し、ディレクトリ３１０においてルックアップを行う。ＧＴＡＧＥＴ５００は、どのキューを調べるべきかをディレクトリ３１０から回収する。ＧＴＡＧＥＴ５００は、次に、適切なキューからメッセージ３４０を回収し、かつ、該メッセージ３４０をアプリケーション２０２へ戻し、かつ、ディレクトリ３１０における設定にしたがって、トレース３３０のメッセージおよびアーカイブ３２０のメッセージを生成する。ディレクトリ３１０は、トレース３３０の記録およびアーカイブ３２０の記録のための宛先キューを有する。
【００９０】
ＧＴＡＰＵＴ３００のように、ＧＴＡＧＥＴ５００は、非同期に送信されたメッセージを回収するために用いられる。ＧＴＡＧＥＴ５００については、メッセージが到着するのを待機するために、そのディレクトリ３１０内にコンフィギュアすることができる。前述したように、ディレクトリ３１０は、ＧＴＡＧＥＴ５００に関するフラグおよび有効なタイムアウト間隔を利用する。
【００９１】
図７は、本発明によるメッセージ受信のオペレーションをより詳細に示す。図４に関連して前述したように、２つの異なるトランスポート層ＭＱＳｅｒｉｅｓおよびＦＲＱＳが図７に示されている。メッセージがＦＲＱＳシステムにしたがってＶＳＡＭファイル４２０を介して伝送されれば、ディレクトリサービスモジュールＧＩＤＩＲＳＶＣ４１０は、ＦＲＱＳ＿ＧＥＴを呼び出してメッセージを回収し、かつ、このメッセージを受信アプリケーション２０２に渡す。
【００９２】
さらに、図４に関連して説明したように、メッセージについては、ＧＴＡ ＭｅｓｓａｇｉｎｇまたはネイティブＭＱメッセージングのいずれかを介して渡すことができる。ＧＴＡ Ｍｅｓｓａｇｉｎｇが用いられれば（ディレクトリ３１０内のフラグにより示されれば）、ディレクトリサービスモジュールＧＩＤＩＲＳＶＣ４１０は、ＧＭＡＲＣＶＭ５２０を呼び出す。ＧＭＡＲＣＶＭ５２０は、識別されたサービス識別子のためにディレクトリ３１０内で指定されたキューから次のメッセージを回収する。アーカイバル記録またはトレース記録が必要とされることをディレクトリ３１０が示せば、ＧＭＡＳＥＮＤＭ４５０が呼び出されて、これらのアーカイバルメッセージおよびトレースメッセージを、自分たちのキュー４７６，４８１へそれぞれ送信する。
【００９３】
ＧＭＡＲＣＶＭ５２０は、メッセージのヘッダを検査して、このメッセージがメッセージブロックの一部であるかどうかを決定し、もしそうである場合には、かどうかを決定する。それがブロックの最初、中間、または最後のメッセージであるかどうかを決定する。この情報は、メッセージデータと共にアプリケーション２０２に戻される。もし破壊されたブロックであれば、ＧＭＡＲＣＶＭ５２０は、呼び出しプログラムへ適切なエラーを戻す。キューからメッセージを回収する際に、モジュールＧＭＡＲＣＶＭ５２０は、期待されたメッセージの提出されたサイズに基づいて、ダイナミック記録領域を割り当てる。
【００９４】
受信すべきメッセージがネイティブＭＱメッセージングを用いて送信されたことをディレクトリ３１０が示せば、ディレクトリサービスモジュールＧＩＤＩＲＳＶＣ４１０は、ＧＭＡＲＣＶＭＱ５３０を呼び出す。呼び出されると、モジュールＧＭＡＲＣＶＭＱ５３０は、メッセージのヘッダに基づいて適切なリターンブロックフィールドを設定し、適用可能であれば（４５０，４７６，４８１を参照）アーカイブメッセージおよびトレースメッセージを送信し、かつ、メッセージデータをアプリケーション２０２へ戻す。
【００９５】
回収されたメッセージが応答を要求すれば、ＧＴＡＧＥＴ５００は、受信アプリケーション２０２に、応答を送信する際に受信アプリケーション２０２により用いられるｒｅｐｌｙ−ｔｏ ｓｅｒｖｉｃｅ識別子およびｒｅｐｌｙ−ｔｏ ａｐｐｌｉｃａｔｉｏｎ識別子を供給する。このｒｅｐｌｙ−ｔｏ ｓｅｒｖｉｃｅ識別子は、メッセージングアーキテクチャが、（ディレクトリ３１０を用いることによって）応答メッセージのために必要とされるルーティングを識別することを可能にする。好ましい実施形態においては、本発明は、送信アプリケーション２０１が応答を要求しても、受信アプリケーション２０２が応答を生成することを強制しない。受信アプリケーション２０２が応答メッセージを生成すれば、該受信アプリケーション２０２は、応答を送信する際に、要求メッセージの独自のメッセージ識別子に等しい相関ＩＤを指定することができる。
【００９６】
前述したように、本発明は、ネイティブＭＱメッセージングおよびＧＴＡ Ｍｅｓｓａｇｉｎｇという、ＭＱＳｅｒｉｅｓを用いた２つの異なる形式のメッセージングを提供する。ネイティブＭＱメッセージングは、いかなる追加の機能性も備えずに、直接的にＭＱＳｅｒｉｅｓを用いる。ＧＴＡ Ｍｅｓｓａｇｉｎｇは、これらのさらなるサービスへのアクセスを容易にできるフレームワークを供給する。サービスは、アプリケーションのために提供される共通の機能である。ＧＴＡ Ｍｅｓｓａｇｉｎｇに関して、提供されるサービスの形式は、アプリケーションに特有の任意のサービスの他に、メッセージのダイナミック再フォーマット、内容に基づくルーティング、持続性アーカイビング、監査、調停、マルチキャスティングを包含するが、これらに制約されるものではない。これらのサービスのうち幾つかは、本発明のアーキテクチャのために直接的に提供され、その一方で、（例えば、ベンダーより供給されるような）他のサービスへのアクセスは、本発明のアーキテクチャにより容易にされる。
【００９７】
本発明によるＧＴＡ Ｍｅｓｓａｇｉｎｇは、さらなるサービスをアプリケーションに提供するために、柔軟性のあるサーバーに基づく方法を供給する。これらのさらなるサービスは、Ｍｅｓｓａｇｅ Ｐｒｏｃｅｓｓｉｎｇ Ｓｅｒｖｅｒｓ（ＭＰＳｓ）により、アプリケーションのメッセージ上で行われる。図８は、マルチキャスティングＭＰＳ６００のオペレーションを示す。
【００９８】
サーバー６００は、メッセージをそれぞれ送信および受信するために、前述したＡＰＩ ＧＴＡＰＵＴ３００およびＧＴＡＧＥＴ５００を用いる。これらのＡＰＩ３００，５００は、メッセージトレーシングおよびアーカイビングの容易さをサポートするために、ＭＰＳサーバー６００に関する共通のメッセージインターフェースおよび必要な技術的処理の両方を供給する。さらに、前述したように、ＧＴＡ ＭｅｓｓａｇｉｎｇＡＰＩ３００，５００は、ディレクトリ３１０を介して駆動されるコンフィギュレーションであり、かつ、サーバー６００を、メッセージキューの技術的複雑さから隔離することを可能にする。
【００９９】
カプセル化機能は、受信されたメッセージ６１０から送信されたメッセージ６２０，６２５へメッセージのコンテキスト情報を渡すべく、これらのサーバー６００を用いるために供給される。コンテキスト情報は、メッセージ６２０，６２５が宛先アプリケーション（例えば、相関識別子、機能的メッセージ識別子）により受信される際にこれらのメッセージと関連する必要がある送信アプリケーション６０２により設定されたフィールドを指す。
【０１００】
別々のＭＰＳ６００内において、アプリケーションへサービスを提供することによって、新たなサーバー６００を作り出すことにより、さらなるサービスがアプリケーションのために加えられる。アプリケーションが、例えば、マルチキャスティング（図８に示されるようなものであり、詳細については後述する）のような新たなサービスを利用したい場合には、マルチキャスティングを行う新たなＭＰＳ６００へメッセージをルーティングするために、ディレクトリ３１０のコンフィギュレーションを変更することができる。全てのサーバー６００がＧＴＡ Ｍｅｓｓａｇｉｎｇ（すなわち、ＧＴＡＰＵＴ３００およびＧＴＡＧＥＴ５００）を介して同じメッセージキューインターフェースを用いるので、既存のアプリケーションコードに対して何の変更も行う必要がない。
【０１０１】
図８に示されたマルチキャスティングの例において、現在は単一のパートナーメインフレームアプリケーションへメッセージを送っているメインフレームアプリケーション６０２は、同じ情報６１０をＡＩＸマシン上の新たなアプリケーションへ送信するように要求することができる。ＧＴＡ Ｍｅｓｓａｇｉｎｇを用いることにより、ディレクトリ３１０におけるコンフィギュレーション情報が更新され、これにより、アプリケーション６０２は、（ＧＴＡＰＵＴ３００とＭＱＳｅｒｉｅｓ２６０とを介して）マルチキャストＭＰＳ６００へメッセージ６１０を送信し、該マルチキャストＭＰＳ６００は、メッセージ６２０の１つのコピーを既存のメインフレームアプリケーションへ送信し、メッセージ６２５の他のコピーを新たなＡＩＸアプリケーションへ送信する。マルチキャスティングＭＰＳ６００は、メッセージ６１０を受信しかつメッセージ６２０，６３０を送信するために、前述したようなＧＴＡＰＵＴおよびＧＴＡＧＥＴを用いる。マルチキャスティングＭＰＳ６００の実際の実装については、多くの方法で達成することができる。例えば、２つの異なるディレクトリ３１０を確立することができ、一方は得るためのものであり、他方は配するためのものである。この実施形態においては、単一のメッセージを回収するために、単一のサービス識別子をＧＴＡＧＥＴ５００により用いることができる。単一のメッセージを回収する場合に、単一のサービス識別子に関するＧＴＡＧＥＴディレクトリ３１０のエントリーは、さらに、２つのサービス識別子を回収し、該２つのサービス識別子は、送信すべき２つの別々のメッセージに関するトランスポートのディテールを回収するためにＧＴＡＰＵＴ３００により用いられる。あるいはまた、ＧＴＡＧＥＴ５００は、単一のサービス識別子を回収することができ、該単一のサービス識別子は、２つのメッセージに関するトランスポートのディテールを全て同時に回収するためにＧＴＡＰＵＴ３００により用いられる。他の実施形態においては、図８に示されるように、ＧＴＡＧＥＴ５００およびＧＴＡＰＵＴ３００の両方が、単一のディレクトリ３１０を共有する。
【０１０２】
さらに、新たなアプリケーションが、送信されている既存のメッセージとは異なるフォーマットのメッセージを必要とすれば、ＡＩＸに送信されるメッセージについては、最初に、異なるＭＰＳ（図８には示されていない）における再フォーマットエンジンを介して送信することができ、次に、新たなＡＩＸアプリケーションへ転送することができる。図８は、さらに、ＭＱＳｅｒｉｅｓ２６０により各々のメッセージ伝送に対して記録されているトレース記録６３０を示している。
【０１０３】
この例においては、どのアプリケーション（６０２、または、パートナーアプリケーション、または、新たなＡＩＸアプリケーション）に対しても、何の変更も行う必要がない。その理由は、必要なルーティング情報は全てディレクトリ３１０内に維持され、かつ、必要なメッセージ処理（すなわち、マルチキャスティングおよび再フォーマット）は、ＧＴＡ Ｍｅｓｓａｇｉｎｇ内のサーバー６００により行われるためである。必要とされる唯一のアプリケーション開発は、メインフレームのメッセージフォーマットから、新たなＡＩＸアプリケーションメッセージフォーマットへ到達するための再フォーマットの規則である。
【０１０４】
前述したように、ＧＴＡ ＭｅｓｓａｇｉｎｇＡＰＩ ＧＴＡＰＵＴ３００，ＧＴＡＧＥＴ５００は、ディレクトリ３１０によりコンフィギュアされるメッセージルーティングを供給する。ディレクトリルックアップは、渡されたＡＰＩおよびパラメータを呼び出すアプリケーションに基づく。例えば、ＧＴＡＰＵＴ３００の呼び出しの範囲内で、ディレクトリ３１０内のエントリーは、次のようなメッセージ処理を制御する：パートナーアプリケーションまたは中間のメッセージングサービスのいずれかであるメッセージの直接の宛先、アプリケーションのメッセージのパスをトレースすることを可能にするためにトレースメッセージがＡＰＩにおいて中央調停設備へ送信されるＴｒａｃｅ ａｎｄ Ｒｅｃｏｎｃｉｌｉａｔｉｏｎ、および、送信されているメッセージの正確なコピーをアーカイビング位置（ここで、メッセージの負荷を降ろし（offload）、かつ、記憶することができる）へ転送できるＡｒｃｈｉｖｉｎｇ。
【０１０５】
ＧＴＡＧＥＴ５００によりアクセスされるディレクトリ３１０のエントリーは、同様のコンフィギュレーションを供給する。宛先の代わりに、ＧＴＡＧＥＴ５００に関するディレクトリ３１０のエントリーは、タイムアウト値の他に、メッセージが回収される起点位置（例えば、キュー）を制御する。アーカイブされたメッセージは受信されたメッセージでありかつトレースメッセージは僅かに異なる情報を備え得るが、アーカイブおよびトレースもまたコンフィギュラブルである。
【０１０６】
ＭＰＳ６００は、アプリケーションサービスをメッセージそれ自体に対して行うか（例えば、再フォーマット）、または、アプリケーションの代わりに重要な動作的（operational）および統計的情報を辿るために用いられ得る（例えば、調停およびトレース）。
【０１０７】
前述したように、ＭＰＳサーバー６００は、ＧＴＡ Ｍｅｓｓａｇｉｎｇ（例えば、ＧＴＡＰＵＴ３００およびＧＴＡＧＥＴ５００）を共通のインターフェースとして用いる。ＧＴＡディレクトリ３１０内のコンフィギュレーションを介して、メッセージを、そのサービスをアプリケーションに対して提供するために、任意のＭＰＳ６００へルーティングすることができる。この方法においては、メッセージを適切なＭＰＳ６００へルーティングするためにコンフィギュレーションエントリーをディレクトリ３１０内に加えることにより、さらなる機能性をメッセージングアプリケーションに対して明白に（transparently）加えることができる。本発明のこのアーキテクチャは、別々のＭＰＳサーバー６００内における機能性を発展させるために段階的に実行される方法を容易にし、これにより、サービスがアプリケーションにより必要とされる際に該サービスを提供することが可能となる。
【０１０８】
ＧＴＡ ＭｅｓｓａｇｉｎｇＡＰＩ（例えば、ＧＴＡＰＵＴ３００およびＧＴＡＧＥＴ５００）を用いることにより、ＭＰＳサーバー６００は、共通のメッセージングインターフェースを有しており、全ての処理はＧＴＡ ＭｅｓｓａｇｉｎｇＡＰＩ内において有効である。アーカイビング機能およびトレーシング機能は特定の値である。ディレクトリ３１０を介したコンフィギュレーションによって、ＧＴＡ ＭｅｓｓａｇｉｎｇＡＰＩは、さらなるアーカイブメッセージおよびトレースメッセージを送信することができる。特定のＭＰＳサーバー６００により回収されかつ送信されるメッセージのアーカイビングは、テストおよびデバッグを容易にするのに役立つ。ＭＰＳサーバー６００におけるトレーシングを可能にすることは、トラブルシューティング、および、送信中の（in-flight）メッセージの状態の判断に役立つ。
【０１０９】
前述したマルチキャスティングサービスの他に、ＭＰＳ６００により提供される他のサービスは、メッセージのダイナミック再フォーマット、ダイナミックな内容に基づくルーティング、アーカイビング（送信または受信されたメッセージのコピーの記憶）、トレーシングおよび調停（送信されたメッセージが時宜を得た形式で配信されていないかどうかを検出する）、メッセージトレースと監査記録とに基づいて統計的情報を提供することを包含するが、これらに制約されるものではない。多数のアプリケーションが共有する任意のメッセージングサービスは、ＭＰＳ６００として実装されることに対して非常に適している。本発明のＭＰＳ６００を用いるというアーキテクチャは、システム開発者／アドミニストレータに、以前には知られていないような重大な柔軟性をもたらす。このような人々が絶えず直面する購入／建築の決定は厄介ではなくなる。その理由は、ベンダー製品が、本発明によるディレクトリ３１０の利用に主に起因して、より容易にアーキテクチャの形に結びつけられるためである。ベンダー製品とインターフェース接続するために必要とされるディテールの大部分は、既存のアプリケーションに対する変更をほとんど必要とせずに、単にディレクトリ３１０の形に符号化される。ベンダー製品が更新される際に、通常は、ディレクトリ３１０に対する変更のみが要求され、ベンダー製品を用いるアプリケーションに対する変更は要求されない。
【０１１０】
好ましい実施形態においては、Ｍｅｓｓａｇｅ Ｓｔｏｒａｇｅ ＭＰＳは、メッセージを記憶するためのＲｅｌａｔｉｏｎａｌ Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ（ＲＤＢＭＳ）体系を備えている。Ｍｅｓｓａｇｅ Ｓｔｏｒｅ ＭＰＳは、ＧＴＡ ＭｅｓｓａｇｉｎｇＡＰＩ内から送信されるアーカイブメッセージを回収するために、かつ、これらのアーカイブメッセージをＲＤＢＭＳへアップロードするために用いられる。
【０１１１】
アーカイビングは、メッセージの再送信および再生を可能にするＭｅｓｓａｇｅ Ｓｔｏｒａｇｅ ＭＰＳにより行われるサービスである。メッセージの再送信は、最初のメッセージに適用された任意のサービス（例えば、マルチキャスティングおよび再フォーマット）がメッセージのアーカイブコピーに再適用されるように、既に首尾よく送信されたメッセージのためにＧＴＡＰＵＴ３００の呼び出しを再発行することを伴う。このことは、ＧＴＡＰＵＴ３００の下流でエラーが発生した場合に、送信されたメッセージを容易に再処理することを可能にする。例えば、再フォーマットの規則が不正確でありかつメッセージが再フォーマットエンジン（他のＭＰＳ）を介して再び渡される必要があれば、メッセージをアーカイブから再フォーマットＭＰＳへ再送信し、かつ、再処理することができる。
【０１１２】
ＧＴＡＧＥＴ５００において発生するアーカイビングは、メッセージを受信アプリケーションへ再配信または再生することを可能にする。この場合には、メッセージは、アーキテクチャにより再処理されず、かつ、アプリケーションにより受信された元のメッセージと同じ方法で配信される。このことは、エラーを有するアプリケーションが、その処理をロールバックしかつ以前に受信されたデータを再処理することを可能にする。この設備は、同じデータを再処理する必要のある環境（例えば、開発アプリケーションまたはサーバーをテストする）において有用である。
【０１１３】
メッセージの記憶については、アプリケーションの必要性に基づいてコンフィギュアすることができる。ＧＴＡ ＭｅｓｓａｇｉｎｇＡＰＩディレクトリ３１２内でのアーカイビングを可能にすることにより、ＡＰＩにより処理されるメッセージのコピーは、アーカイブキューへ送信される。Ｍｅｓｓａｇｅ Ｓｔｏｒｅ ＭＰＳは、このアーカイブキューからメッセージという負荷を降ろすための機構を供給する。これは、メッセージヘッダの部分や、アプリケーションデータ全体を有するメッセージのアーキテクチャ成分およびアプリケーション成分の両方へのアクセスを可能にする。記憶されている情報は、メッセージをアーカイブから再伝送するために必要最小限の量である。メッセージの記憶のためにＲＤＢＭＳストラクチャを用いることは、既存のキューイングツールをメッセージ記憶データベースに適用することを可能にする。
【０１１４】
他の実施形態においては、メッセージのためにＲＤＢＭＳ記憶設備に投資することに自発的ではないかまたは投資することが不可能なアプリケーションは、メッセージをローカルアーカイブキュー上に保持することができ、かつ、供給されたＧＵＩキューユーティリティを用いて、これらのメッセージを再生／再送信することができる。キュー上に記憶されるメッセージの数は、アプリケーションのシステムＤＡＳＤ制約により制限される。
【０１１５】
メッセージトレーシングおよび調停は、ＭＰＳにより行うことができる２つの重要なサービスである。調停およびトレーシングをサポートするために、ＧＴＡ ＭｅｓｓａｇｉｎｇＡＰＩは、メッセージがどこから来たのか、および、どこへ行き先を定められているのかについての情報の他に、処理されたメッセージを詳述するトレースメッセージを送信するようにコンフィギュアされる。Ｍｅｓｓａｇｅ Ｔｒａｃｉｎｇ ＭＰＳは、これらのメッセージを回収し、かつ、これらのメッセージをＭｅｓｓａｇｅ Ｔｒａｃｉｎｇ ＲＤＢＭＳへアップロードする。
【０１１６】
Ｍｅｓｓａｇｅ Ｔｒａｃｉｎｇ ＲＤＢＭＳの概要は、アプリケーションにより送信されたメッセージがなおもアーキテクチャにより処理されているかどうかを調べるために、また、どのくらいの間“送信中”であるのかを調べるために、調停を行うことができるというものである。同じ概要は、さらに、所定のメッセージが取る経路と、その上で行われたサービスとをトレースすること可能にする。
【０１１７】
Ｒｅｃｏｎｃｉｌｉａｔｉｏｎ ＭＰＳへ送信されたトレースメッセージについては、これらのトレースメッセージがパージされない際には、メッセージが首尾よく調停された後になおも検査することができる。問い合わせ（queries）については、標準のＳｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ（ＳＱＬ）を用いて、Ｍｅｓｓａｇｅ Ｔｒａｃｉｎｇ ＲＤＢＭＳと対立させることができる。これらの問い合わせは、可能となったトレーシングによって、任意のメッセージのエンドツーエンド経路を識別することができる。その理由は、メッセージに関する個々のトレースの全てが、独自の識別子により共に関連しているためである。
【０１１８】
本アーキテクチャ内における調停は、メッセージがメッセージングアーキテクチャにより途絶えているかどうかを検出し、かつさらに、送信されたメッセージをアプリケーションが受信しないかどうかを検出する。ある実施形態においては、調停は、さらに、“受け入れ可能な”時間量でメッセージが受信されたかどうかを検出する。そうでない場合には、調停は、送信アプリケーションに、メッセージが受信されなかったと警告することができる。調停は、アプリケーションデータの内容を検査せず、また、処理されたメッセージのエンドオブデイ（end of day）カウントをアプリケーションに供給しない。前述したように、メッセージおよび要求されたサービスを送信するアプリケーションに基づいて、ＧＴＡ Ｍｅｓｓａｇｉｎｇアーキテクチャは、どのメッセージがあまりにも長く突出しているのかを判断し、かつ、回復させるべきエラーが存在することを示すアーキテクチャメッセージを送信することができる。
【０１１９】
これらのアーキテクチャメッセージは、大部分のアプリケーションによりデフォルトの方法で処理される。特別なハンドラは、トレースメッセージおよびアーカイブメッセージを処理し、かつ、所望の場合には、警告を送信したりログファイルを書き込むような作用を行うことができる。特有の処理を必要とするアプリケーションは、任意のキューへ転送されるこれらのアーキテクチャメッセージを有することができ、かつ、カスタムハンドラによって、これらのアーキテクチャメッセージを処理することができる。
【０１２０】
統計的監査を行うために、Ｍｅｓｓａｇｅ Ｔｒａｃｉｎｇ ＲＤＢＭＳ内に記憶されたトレース情報を要約し、かつ、統計的監査をサポートするための履歴テーブルに記憶することができる。アーカイビングのためにＲＤＢＭＳを用いたアプリケーションは、さらに、メッセージ長さのようなメッセージ統計を要約することができる。次に、これらのテーブルについては、高度な性能をもたらすためのレポートおよび分析ツールと、メッセージング利用レポートとを用いて問い合わせることができる。
【０１２１】
再フォーマットは、ＭＰＳにより行うことができる理想的なサービスである。再フォーマットは、メッセージがあるフォーマット（例えば、メインフレームフォーマット）から異なるフォーマット（例えば、ＡＩＸ）へ変換される処理である。Ｒｅｆｏｒｍａｔｔｉｎｇ ＭＰＳは、アプリケーションが定義したダイナミックな内容に基づく再フォーマット規則によりメッセージングを処理することを可能にする。ＧＴＡ ＭｅｓｓａｇｉｎｇＡＰＩを用いたＲｅｆｏｒｍａｔｔｉｎｇ ＭＰＳは、最初のメッセージのコンテキスト情報を渡す一方で、単一のメッセージを１つ以上の出力メッセージに再フォーマットすることをサポートする。
【０１２２】
ダイナミック再フォーマットは、全体として、このアーキテクチャの重要なコンポーネントである。これは、アプリケーションの隔離を容易にし、かつ、特定のメッセージングに関する互いの必要性を知ることなくメッセージングパートナーがメッセージを渡すことを可能にする。これらのメッセージフォーマットは、Ｒｅｆｏｒｍａｔｔｉｎｇ ＭＰＳのリポジトリに記憶されることが好ましく、かつ、メッセージングパートナーの１つがそのメッセージフォーマットを変更する場合にはアプリケーションコードの外側で更新されることが好ましい。
【０１２３】
Ｃｏｎｔｅｎｔ Ｂａｓｅｄ Ｒｏｕｔｉｎｇは、ＭＰＳにより提供される他の重要なサービスである。このようなＭＰＳは、アプリケーションがメッセージの内容に基づいてルーティング規則を定義することを可能にする。Ｃｏｎｔｅｎｔ Ｂａｓｅｄ Ｒｏｕｔｉｎｇ ＭＰＳにおいて入力メッセージのフォーマットを定義することにより、アプリケーションは、特定のルーティング情報を、メッセージに包含されるデータフィールド内に配することができる。
【０１２４】
図９は、本発明によるメッセージングオペレーションのエンドツーエンド例を示す。この例において、アプリケーションＡ７００は、他の３つのアプリケーション（アプリケーションＢ７１０、Ｃ７２０、Ｄ７８０）へメッセージを送信する必要性を有している。このメッセージングを達成するために、アプリケーションＡ７００は、前述したようにＧＴＡＰＵＴ３００を呼び出す。ＧＴＡＰＵＴ３００への呼び出しは、サービス識別子によって行われ、該サービス識別子は、アプリケーションＢ７１０、アプリケーションＣ７２０、アプリケーションＤ７８０の各々へメッセージを送信するために必要とされるディテールをディレクトリ３１０から回収するためにＧＴＡＰＵＴ３００により用いられる。この特定の例においては、ディレクトリ３１０は、次の宛先としてのマルチキャストＭＰＳ７４０へ向けられる。この当面の宛先によって、メッセージは、ＭＱＳｅｒｉｅｓ２６０へ渡され、該ＭＱＳｅｒｉｅｓ２６０は、単一のメッセージ７３５を、マルチキャストＭＰＳ７４０に接続されたＭＱＳｅｒｉｅｓ宛先キューへ送信する。さらに、ディレクトリ３１０内のサービス識別子と関連した記録は、アーカイブ７２５の記録およびトレース７３５の記録がこのメッセージのために生成されるべきであることを示す。
【０１２５】
マルチキャストＭＰＳ７４０は、ＧＴＡＧＥＴ５００を用いて、ＭＱＳｅｒｉｅｓ２６０のメッセージキューから着信メッセージ７３５を回収する。前述したように、メッセージ７３５の到着はＭＰＳ７４０へトリガリングされるか、または、ＭＰＳ７４０は、新たなメッセージが到着したかどうかを調べるためにＭＱＳｅｒｉｅｓ２６０を能動的にポーリングする。メッセージ７３５に包含されるサービス識別子を用いて、マルチキャストＭＰＳ７４０はＧＴＡＰＵＴ３００を呼び出し、該ＧＴＡＰＵＴ３００は、次に、ディレクトリ３１０においてルックアップを行う。サービス識別子と関連するディレクトリ３１０のエントリーは、３つのアプリケーション（アプリケーションＢ７１０、Ｃ７２０、Ｄ７８０）へメッセージを送信する必要があることを示す。メッセージは、アプリケーションＢ７１０とアプリケーションＣ７２０とに配信される前に再フォーマットされる必要があるので、これにより、３つの宛先アプリケーションに関連するディレクトリ３１０に包含されるルーティングのディテールは、再フォーマットＭＰＳ７５０へ向けられる。
【０１２６】
アプリケーションＤ７８０へのメッセージの送信に関連して、ＧＴＡＰＵＴ３００は、ＭＱＳｅｒｉｅｓ２６０からメッセージ７７５を回収するために、ディレクトリ７９０を用いてＭＱＳｅｒｉｅｓ２６０を呼び出す。メッセージ７７５は、本質的に、元々はアプリケーション７００により送信されたメッセージ７３５の正確なコピーである。その理由は、このメッセージはいかなる再フォーマットも受ける必要がなかったためである。
【０１２７】
アプリケーションＢ７１０およびアプリケーションＣ７２０へのメッセージの伝送に関連して、ＭＱＳｅｒｉｅｓ２６０は、（ディレクトリ３１０を用いて）ＧＴＡＰＵＴ３００を介してマルチキャストＭＰＳ７４０により呼び出され、かつ、メッセージ７４５は、再フォーマットＭＰＳ７５０に添付されたＭＱＳｅｒｉｅｓ２６０内の宛先キューへ送信される。図９に示されたこの実施形態において、再フォーマットＭＰＳ７５０内のディレクトリは、メッセージ７４５において指定されたサービス識別子によって、再フォーマットＭＰＳ７５０が単一の着信メッセージを二度再フォーマットするように（一度目はアプリケーションＢ７１０のため、二度目はアプリケーションＣ７２０のため）コンフィギュアされる。他の実施形態においては、マルチキャストＭＰＳ７４０は、再フォーマットＭＰＳ７５０へ２つの別々のメッセージ（一方のメッセージは、アプリケーションＢ７１０のためのサービス識別子を有し、他方のメッセージは、アプリケーションＣ７２０と関連したサービス識別子を有する）を送信することができる。
【０１２８】
再フォーマットＭＰＳ７５０は、ＭＱＳｅｒｉｅｓ２６０のキューから着信メッセージ７４５を回収するためにＧＴＡＧＥＴ５００を呼び出す。アプリケーションＡ７００からの元のメッセージ７３５によって渡された、制御ブロックにおいて見出される命令を用いて、再フォーマットＭＰＳ７５０は、アプリケーションＢ７１０およびアプリケーションＣ７２０により要求されるようにメッセージがフォーマットされるべきフォーマットを知る。好ましい実施形態においては、単一の再フォーマットＭＰＳ７５０は、幾つかの異なるフォーマットにて再フォーマットオペレーションを行うことが可能である。図９に示された例において、アプリケーションＢ７１０は、あるフォーマットの形でメッセージが現れることを要求でき、その一方で、アプリケーションＣ７２０は、全く異なるフォーマットの形でのメッセージを要求する。
【０１２９】
再フォーマットＭＰＳ７５０は、アプリケーションＢ７１０およびアプリケーションＣ７２０により要求された各々のフォーマットにてメッセージをフォーマットした後に、実際にメッセージを伝送するためにＧＴＡＰＵＴ３００を呼び出す。前述したように、ＭＰＳ７５０は、ＧＴＡＰＵＴ３００に対して２つの別々の呼び出しを行うことができ、各々の呼び出しは、アプリケーションＢ７１０およびアプリケーションＣ７２０へそれぞれ送信するために必要とされる適切なサービス識別子によって行われる。あるいはまた、ディレクトリ３１０における単一のサービス識別子を、宛先をアプリケーションＢ７１０およびアプリケーションＣ７２０として同時に識別するＭＰＳ７５０により（ＧＴＡＰＵＴ３００を介して）用いることができる。さらに、ディレクトリ３１０におけるルックアップを用いて、ＧＴＡＰＵＴ３００は、実際にメッセージ７５５，７６５を伝送するために、トランスポート層へ渡される必要があるパラメータを回収する。
【０１３０】
図９において、アプリケーションＢ７１０に宛てられたメッセージ７５５は、ＭＱＳｅｒｉｅｓ２６０を用いて伝送される。これに対し、アプリケーションＣ７２０に宛てられたメッセージ７６５を伝送するトランスポート層７６０は、ＯＴＨＥＲとして指定されている。この指定は、任意の適切なトランスポート層を受け入れるように本発明のアーキテクチャをカスタマイズできることを示すためである。
【０１３１】
いったん、メッセージ７５５，７６５が、それぞれのアプリケーションＢ７１０およびアプリケーションＣ７２０に添付されたトランスポート層の入力キューに到達すると、アプリケーション７１０，７２０は、メッセージを回収するためにＧＴＡＧＥＴ５００を呼び出す。
【０１３２】
簡単に前述したように、本発明のＧＴＡ Ｍｅｓｓａｇｉｎｇアーキテクチャは、メッセージブロックの伝送をサポートする。ブロックメッセージは、送信された際と同じ順序で、このブロックに属さないメッセージを間に散在させずに配信されるメッセージのセットを指す。この機能は、ネイティブＭＱメッセージングによりサポートされていない。ネイティブＭＱメッセージングの利用を必要とするアプリケーションは、ネイティブＭＱメッセージのブロックを送信しかつ回収する能力を持たない。
【０１３３】
単一ブロックとして示されている本発明の一実施形態において、ブロックに属するメッセージは、共に、単一のＭＱＳｅｒｉｅｓメッセージの形に、内部的にブロック化される。ブロックについては、送信アプリケーションにより供給される識別子によって名づけることができる。この識別子は、記述的目的のみのために存在することができ（すなわち、機能的識別子）、または、相関識別子を用いることにより特定のメッセージブロックを入力キューから回収するために、受信アプリケーションにより用いられ得る。多数のブロックとして示される他の実施形態においては、ブロックは、幾つかのＭＱＳｅｒｉｅｓメッセージの形に分解される。この実施形態において、ブロック内の最初のメッセージのメッセージＩＤのコピーは、ブロックを形成する後続のＭＱＳｅｒｉｅｓメッセージの相関ＩＤ内にコピーされる。メッセージを送信するときに、メッセージブロックを送信していることを識別することが、送信アプリケーションの責任である。送信アプリケーションは、ブロックのうちでどれが最初のメッセージであってどれが最後のメッセージであるのかを識別する必要があり、かつ、メッセージを、これらのメッセージが受信されるべき順序で送信する必要がある。送信アプリケーションは、ブロックを共に結びつけるために重要な識別子を供給する必要はない。
【０１３４】
単一ブロックの実施形態において、アーキテクチャは、メッセージブロックを、該ブロックに属する全てのメッセージがアプリケーションにより供給されるまで、キューへ送信しない。ブロックのうち最後のメッセージが供給されると、アーキテクチャは、該アーキテクチャがキューへ送信する単一のインフラストラクチャメッセージを生成する。全てのブロックメッセージングについては、作業論理ユニット内において委託される必要がある。ブロックに属するメッセージをＧＴＡ Ｍｅｓｓａｇｉｎｇアーキテクチャへ送信できなければ、メッセージ全体をロールバックすべきである。
【０１３５】
メッセージを受信するときに、アプリケーションは、そのメッセージがブロックの始まりであるかどうかについて知らされる。このことは、情報の目的のためにもたらされ、これにより、アプリケーションは、適切なアプリケーション処理を開始することができる。後続のＧＴＡＧＥＴ５００は、メッセージを、これらのメッセージが配されたのと同じ順序で、受信アプリケーションへ返す。このメッセージがＭＱＳｅｒｉｅｓキューから回収されているのか、または、より大きなブロックメッセージの断片（segments）であるのかについては、受信アプリケーションにとって明白となっている。
【０１３６】
本発明について、その特定の実施形態に関連して説明してきたが、他の多くの変形例および他の利用法が当業者には明白である。したがって、本発明は、本明細書における特定の開示により制約されるのではなく、開示の要旨および範囲のみにより制約されることが好ましい。
【図面の簡単な説明】
【図１】  従来技術のオープンシステム相互接続アーキテクチャの７つの層を示す図である。
【図２】  本発明のメッセージングアーキテクチャ層を示す図である。
【図３】  メッセージ送信モジュールＧＴＡＰＵＴのオペレーションを示す図である。
【図４】  図３のメッセージ送信モジュールＧＴＡＰＵＴの詳細な実装を示す図である。
【図５】  ディレクトリおよびその内容の例を示す図である。
【図６】  メッセージ受信モジュールＧＴＡＧＥＴのオペレーションを示す図である。
【図７】  図５のメッセージ受信モジュールＧＴＡＧＥＴの詳細な実装を示す図である。
【図８】  本発明によるメッセージ処理サーバーのオペレーションを示す図である。
【図９】  本発明のメッセージングオペレーションのエンドツーエンド例を示す図である。
【符号の説明】
２６０  ＭＱＳｅｒｉｅｓ
３００  ＧＴＡＰＵＴ
３１０  ディレクトリ
５００  ＧＴＡＧＥＴ
６００  ＭＰＳサーバー
６０２  メインフレームアプリケーション
６１０，６２０，６２５，６３０  メッセージ
【図１】
0003837291.tif 000002
【図２】
0003837291.tif 000003
【図３】
0003837291.tif 000004
【図４】
0003837291.tif 000005
【図５】
0003837291.tif 000006
0003837291.tif 000007
【図６】
0003837291.tif 000008
【図７】
0003837291.tif 000009
【図８】
0003837291.tif 000010
【図９】
0003837291.tif 000011
0003837291.tif 000012