(57)【特許請求の範囲】
【請求項１】
分散アプリケーション・プログラム間の通信をサポートするための機構を有し、遠隔のアプリケーション・プログラムから受信した着信メッセージにして、その各々が一のメッセージ・タイプ・フィールド、一のメッセージ識別子フィールド及び一のウェーブ番号フィールドを有する着信メッセージのうち応答タイプ・メッセージの処理をサポートするための分散アプリケーション・インフラストラクチャ（AI）を含む分散データ処理システムであって、
前記分散アプリケーション・インフラストラクチャが、
メッセージ・タイプのリスト、各要求タイプ・メッセージを識別し、該要求タイプ・メッセージと各応答タイプ・メッセージとの対応関係を表わすためのメッセージ識別子のリスト、並びに、ウェーブ番号を記録する第１及び第２のフィールドを含むウェーブ・テーブルであって、前記第１のフィールドには、各要求タイプ・メッセージの送信時に、該要求タイプ・メッセージを参照する各現グローバル・ウェーブ番号が各応答タイプ・メッセージに対する予期されるウェーブ番号として記録され、該記録予期ウェーブ番号は、アプリケーション・プログラムの実行が該プログラムにより定義された変更点に到達する毎に、新たな参照番号で更新されるように構成され、前記第２のフィールドには、各応答タイプ・メッセージの着信時に、着信済み応答タイプ・メッセージのうちの最高のウェーブ番号が記録されるように構成されるウェーブ・テーブルと、
前記メッセージ・タイプのリストへの少なくとも読み取りアクセス、前記メッセージ識別子のリストへの読み取り及び書き込みアクセス、前記ウェーブ番号のリストへの読み取り及び書き込みアクセスを提供する手段と、
モジュール状アプリケーション・プログラム（AP）の別個に選択可能なアプリケーション・プログラム構成要素（APC）のリスト及び当該リストへの少なくとも読み取りアクセスを提供する手段と、
一の着信メッセージの前記メッセージ・タイプ・フィールドを前記メッセージ・タイプのリストと比較するとともに、前記着信メッセージの前記メッセージ識別子フィールドを前記メッセージ識別子のリストと比較することにより、前記着信メッセージが前記分散データ処理システムによって認識可能な応答タイプ・メッセージであるか否かを決定するための手段と、
前記応答メッセージが前記アプリケーション・プログラム内の前記変更点の前又は後のどちらで着信されたかを判別するための手段を含み、該応答メッセージの前記ウェーブ番号と前記ウェーブ・テーブルの現グローバル・ウェーブ番号との比較が一致か又は不一致かに従って、応答タイプ・メッセージの着信が時間通りであるか否かを決定し、不一致の場合には前記応答メッセージの前記ウェーブ番号が前記ウェーブ・テーブルの前記最高ウェーブ番号よりも大きいか又は小さいかに従って応答メッセージの到着が遅れているか、即ち順序通りでないか、又は時間外であるかを決定するための手段と、
前記応答メッセージの前記各フィールドに関連する前記決定結果及び通信中の１つ以上のアプリケーション・プログラムのインスタンス状態を応答タイプ・メッセージの処理条件用の１組の規則と比較することにより、前記アプリケーション・プログラム構成要素のリストから、前記応答タイプ・メッセージを処理するための１つ以上のアプリケーション・プログラム構成要素を選択するための手段と、
を含むことを特徴とする、前記分析データ処理システム。
【発明の詳細な説明】
［技術分野］
本発明は、分散データ処理及び通信に係り、更に詳細に説明すれば、アプリケーションの設計、開発及び／又は稼働時の実行（run−time execution）をサポートするとともに、アプリケーション・プログラム間のメッセージ交換の通信をサポートするための方法及びシステムに係る。
［背景技術］
特定の組織又は互いに異なる組織に属するか否かに拘わらず、複数の作業者がコンピュータ・ネットワークを使用して情報を交換することは、現在ではごく普通のことである。ネットワーク化の使用が普及し、ネットワーク化及び分散システムの信頼性や性能が向上するにつれて、共有データへの高速アクセスが可能となり、このため作業者の効率が向上しただけでなく、（例えば、高価なI/O装置をネットワーク内の複数のユーザに利用可能にすることを通して）諸データ処理資源の費用効果が向上した。
ネットワーク化は、データ及びプロセスを複数のデータ処理ステーション間に分散させ、そしてネットワーク内の何れのサイトにおいても、かかるデータ及びプロセスを最も効率的に位置付けることを可能にした。例えば、所定のデータについては、これをアクセス及び更新すべき諸プロセスの近傍に位置付け、また所定のプロセスについては、これをエンド・ユーザのワークステーションに位置付けるようにすると、ネットワーク内のデータ・トラヒックを減少させることができる。他方、中央の設置場所に、多数の遠隔ユーザがアクセスすべき大規模なデータベースを格納すると、整合性の維持やセキュリティ機構の設置が簡単となる。現在、広範に要請されているのは、全てのデータを複数の分散システムに分散させることなく、LANやワークステーションの利点を活用できるようにする、ということである。なぜなら、セキュリティの提供や企業内アクセスのバックアップなどのデータ管理タスクは、これを集中データについて行うよりも、分散データについて行う方が遥かに高価につくからである。
分散処理について有利なデータ処理方式は、「クライアント」プログラムが１つ以上の「サーバ」プログラム（これは異なるシステム上にあっても良い）に要求を送り、サーバから共有サービスを受け取るようにしたクライアント／サーバ方式である。単一のビジネス・アプリケーションは、複数のネットワーク・サイト上に分散可能であり、クライアント及びサーバ・プログラムの両者を含むことがある。
アプリケーションのロジックが地域的に分散されているか又は複数のプロセッサ上に分散されている場合（即ち、分散アプリケーション（DA）が複数のアプリケーション・プログラム（DAP）から成る場合）、このアプリケーションは、非分散アプリケーション（NDA）については生じないような技術上の問題に対処しなければならない。これらの問題は、このアプリケーションの互いに異なる部分の間の通信や、遠隔システム又はこのアプリケーションの遠隔部分における障害又は不十分な性能についての対処方法を含んでいる。
これらの問題に向けられた公知の１つのアプローチは、分散アプリケーション・インフラストラクチャ（DAI）が提供するサービスを使用して、分散アプリケーション内で通信が行われているという事実をマスクすることにより、このDAが、プログラマ及びエンド・ユーザに対し、恰もNDAであるかのように見えるようにする、というものである。このアプローチが使用されるのは、通信のために遠隔手順呼び出しが使用される場合である。かかるDAIを使用する意図は、アプリケーションのプログラミングを簡単にすることにある。
しかしながら、NDAでは、システム障害のような問題がこのアプリケーションの全体に影響を与えて（又は全く影響しないこともある）、このアプリケーションを全体として停止させることがある。これに対し、DAでは、１つのアプリケーション・プログラム（DAP）内の問題が、障害に陥っていない他のDAP内のコードによって、このアプリケーションのエンド・ユーザからマスクされることがある。かかるマスキングの効果は、問題を有するDAPの役割に依存する。この場合の重要な技術上の問題は、非分散の見せかけ（DAがNDAのように見えるようにすること）が、問題のマスキングを行うことを妨げる、という点にある。また、アプリケーション・プログラム内にマスキング・コードを含めると、メインライン・アプリケーションのプログラム・コードが著しく複雑となり、このため、アプリケーションのプログラミング作業が一層困難となる。
以下に、エラー条件のマスキングを行うことが望ましい状況を例示する。
＊  データベースの最終的な更新に終わるような一連の操作を包含するアプリケーションにおいて、通信障害のために更新要求がこのデータベースに到着することが一時的に妨げられる場合には、エンド・ユーザに悪影響を与えることなく、この最終的な更新を延期することができる。
＊  小売業アプリケーションにおいて、クレジット・チェック・システムが一時的にアクセス不能となる場合には、販売中の商品の価格が予定額以下であることを条件として、通常のクレジット・チェックを放棄することができる。
要請されているのは、分散アプリケーションにおけるエラー条件及びエラーの「マスキング」を効率的に処理することができる方法及びシステムである。また、非常に複雑なアプリケーション・プログラムを要することなく、諸問題のマスキングを容易に行うことができる方法及びシステムも要請されている。一般的に説明すれば、プログラム間通信用のサポート機構を有するコンピュータ・プログラムは、当該技術分野では公知であるが、かかるプログラムの機能は、情報を転送することに向けられていて、かかる情報を処理するための追加のサポートを提供することには向けられていない。IBM社の製品「MQSeries」（後述）のような市販のメッセージ交換ソフトウェアは、アプリケーション・プログラムがメッセージを送信及び受信することを可能にするための機構を提供するが、かかるメッセージの処理自体は、アプリケーション・プログラムに任されている。このため、アプリケーション・プログラムは、全ての着信メッセージを処理可能にするのに必要な命令として、エラー条件を生じさせるメッセージを処理するための命令や、何らかの理由で特別な処理を必要とするメッセージを処理するための命令を含んでいるのが普通である。例えば、一のメッセージが遅れて到着する場合は、一のメッセージが時間通りに（on time）到着する場合に行われるプロセスとは異なるプロセス（例えば、送信側に対し、遅れた要求がコンパイルされないことを通知すること）を実行しなければならないことがある。
（注:IBM及びMQSeriesは、インターナショナル・ビジネス・マシーンズ・コーポレイションの商標）。
かかる遅れた受信のほかにも、所定のメッセージを他のメッセージとは異なった態様で処理しなければならないような多くの条件が存在する。例えば、指定した数の関係するメッセージが到着するまで、一のメッセージの処理を遅延させることが望ましい場合があり、またアプリケーション・プログラム・インスタンスの異なる状態が、それぞれ異なるアクションを必要とすることもある。
エラー条件の特別なケース及び他の要因を扱うことは、異なるメッセージをそれぞれ異なる態様で処理するのに望ましいとしても、これはアプリケーション・プログラミングの困難な側面である。即ち、プログラミング作業に必要な時間を増加させるだけでなく、最終的なプログラミング・コードを複雑にするからである。
このため、メッセージの異なるタイプについてそれぞれ異なる処理を必要とするエラー条件及び他の基準を効率的に処理することができるだけでなく、アプリケーション・プログラミングの複雑さを軽減することができる方法及びシステムが要請されている。
［発明の要約］
本発明の第１の側面に従って、アプリケーション・プログラム間の通信をサポートするための機構を有するデータ処理システムであって、
当該システムによって受信される入力メッセージの処理をサポートするためのアプリケーション・インフラストラクチャ（AI）を含み、当該AIが、
入力メッセージのタイプをリストするための手段と、
前記AIによってサポートされるモジュール状アプリケーション・プログラム（AP）の別個に選択可能なアプリケーション・プログラム構成要素（APC）をリストするための手段と、
入力メッセージのタイプを識別するとともに、前記リストした入力メッセージのタイプとアプリケーション・プログラム構成要素との間の予め定義された関係に従って、前記入力メッセージを処理すべき１つ以上の適当なアプリケーション・プログラム構成要素を選択するための手段を含んでいる、前記データ処理システムが提供される。
「アプリケーション・インフラストラクチャ（AI）」がそのように命名されている所以は、アプリケーション・プログラム間の通信をサポートするためのサービスを提供するというその機能を、ソフトウェア製品又はソフトウェア製品の必須部分として実現することが好ましいからである。このAIは、入力メッセージ・タイプの前記リスト及びモジュール状アプリケーション・プログラム（AP）のアプリケーション・プログラム構成要素（APC）の前記リストへの少なくとも読み取りアクセスを有している。
このようなシステムは、アプリケーション・プログラムが着信メッセージを処理するのに先だって、当該アプリケーション・プログラム内の特定のコード構成要素又はモジュールを選択するための機構を有する。この選択又は当該アプリケーション・プログラムの「調整」は、この着信メッセージの「タイプ」に依存して行われるようになっている。なお、この文脈におけるメッセージの「タイプ」とは、選択すべき特定のアプリケーション・プログラム構成要素を決定するための基準として識別可能で且つ使用可能である、予め定義された任意の特性を意味する（例えば、メッセージの「タイプ」とは、当該メッセージが要求、応答又は情報メッセージのどれであるのか、或いは当該メッセージが削除命令又は更新命令のどれであるのかを意味することがある）。以下では、「メッセージのタイプ」又はこれと同義の「メッセージ・タイプ」という語句が、特定のメッセージについて静的な任意の特性を包括的に意味するものとする。
メッセージのタイプと特定のアプリケーション・プログラム構成要素との間の前記予め定義された関係は、当該システムにおいて諸テーブル・エントリとして実現することができるので、適当なアプリケーション・プログラム構成要素を選択するには、このテーブルを走査することが必要となる。各受信メッセージに関係するテーブル・エントリが存在する場合、このシステムは、特定のアプリケーション・プログラム構成要素を自動的に選択することができる。代替的に、他の所定の基準が満足された場合にのみ、かかる自動的な選択を行わせるようにすることもできる（後述）。もし、受信メッセージのタイプが前記予め定義された関係を有さなければ、デフォルトの選択をトリガすることができる。
本発明は、アプリケーション・プログラム内の諸構成要素のうち一の着信メッセージを処理すべき適当な構成要素を効率的に選択する（好ましくは、この選択ステップの一部としてこれらの構成要素のメソッドを自動的に呼び出す）ためのアプリケーション・インフラストラクチャを提供することにより、アプリケーションのプログラミングを簡単にすることができる。即ち、このアプリケーション・インフラストラクチャは、アプリケーション・プログラム自体が比較的に簡単で且つ比較的に明瞭となり得るような態様で、これらのアプリケーション・プログラムに代わってサービスを提供するものである。アプリケーションの機能は、これを実現するために容易に再使用可能な諸ユニット（例えば、メッセージの経路指定を行うためのナビゲーション・ロジック、プレゼンテーション・ロジック及びビジネス・ロジック）にカプセル化することができる。
前述のように、着信メッセージのタイプに依存して（及びオプションとして、他のメッセージ又はシステム特性に依存して）アプリケーション・プログラム内の特定の手順又は構成要素を選択するためにテーブルを使用するようにすると、主要な処理コードに悪影響を与えることなく、エラー又は障害をマスクするためのコードをアプリケーション・プログラムに追加することができる。このマスキング・コードは、エラー条件が検出される場合又は他の特定の状況においてのみ選択されるような特別のコード・モジュール内に設けることができる。
本発明のシステムは、分散アプリケーション（DA）におけるアプリケーション・プログラム（DAP）間のメッセージ通信をサポートするために特に有用であるが、これに限られない。
これらのモジュール状アプリケーション・プログラムが定義する各手順を、所定の規則が満足された場合にだけ呼び出すようにすることが好ましい。これを実現するために、前記のアプリケーション・インフラストラクチャは、各着信メッセージの所定の特性（及び／又はこのメッセージの到着時点における当該システムの特性）をメッセージ処理用の諸規則と比較するための手段を備えている。
かくて、このアプリケーション・インフラストラクチャは、メッセージのタイプとは異なる基準を含んでいるような適当なアプリケーション・プログラム構成要素を選択するための諸規則をサポートすることが好ましい。もし、メッセージの「タイプ」が静的で且つこのメッセージの固有の部分であるような特性を意味するのであれば、実行すべき操作を決定するために検査可能な他の特性を、動的特性と称することができる。これらの特性には、一のメッセージが遅れているか又は時間通りであるか、諸メッセージが順序外（out−of−sequence）で到着したか、当該アプリケーションがどの状態にあるか、などの特性を含めることができる。例えば、予め設定したタイムアウト期間が満了する場合、又は待機中の１組の応答メッセージのうち最後の応答メッセージを受信する場合にのみ、一の規則が選択すべき構成要素をトリガすることができる。一のメッセージ又はシステムの動的特性の基づいて、処理の制御をサポートすることは、本発明の重要な側面である。
かくて、分散アプリケーション内のエラー及び障害を処理するためにテーブル・ドリブン型のアプローチを採用することができるように、前記識別及び選択するための手段は、システム及び通信障害を考慮するような「タイムアウト」規則の適用をサポートする。これらの「タイムアウト」規則は、指定したタイムアウト期間内にメッセージが受信されなかった場合に行うべき適当なアクションを定義する。例えば、アプリケーションが、部分的な回答をエンド・ユーザに与えたり、又はビジネス・リスク上の基準を使用して、恰も障害が全く生じなかったかのように、ユーザが先に進むことを許容することができる。また、一のメッセージが遅れて到着したが依然として最新であるような場合に、何をなすべきか（即ち、不十分は性能並びに障害に起因する時間外（out of time）のメッセージを扱うこと）を定義するための諸規則を含ませることをサポートするのが好ましい。これらの規則は、アプリケーション・プログラムの内部又はアプリケーション・インフラストラクチャ自体の内部に設けることができる。
本発明の推奨実施例に従ったシステムは、当該システムからの一の発信メッセージに対し第１の識別子を割り当てるための手段と、当該システムからの諸発信メッセージの識別子のリストを維持するための手段と、着信メッセージの識別子を検査し且つこれを前記維持されたリストと比較することにより、前記リストした発信メッセージに関連（対応）する着信メッセージを識別するための手段とを有している。この比較を意味あるものとするためには、発信メッセージの送信先である受信システムの側に、これらの発信メッセージに応答して当該受信システムが送信する応答メッセージに対し、前記第１の識別子に関連する第２の識別子を付加するための手段を設けることが必要となる。
一般に、メッセージ通信に関与する各システムは、その各発信メッセージに対し第１の識別子を割り当てるための手段と、前記リストを維持し且つ検査するための手段と、各応答メッセージに対し第１の識別子に関連する第２の識別子を割り当てるための手段を含むことが好ましい。各識別子は、各メッセージの静的特性の１つである。
前記第１の識別子及び第２の識別子（例えば、要求メッセージの識別子及びこれに関連する応答メッセージの識別子）は、各メッセージのフィールド内にある単一の共通値から成ることが好ましい。このようにすると、一の要求メッセージに割り当てた値を応答メッセージを介して送信側に反射させ、これをテーブル内に保持された諸要求メッセージ内の値と容易に比較することができるからである。かくて、第１の識別子は、これを受信側で解釈することなく、応答メッセージ内に含めて要求メッセージの送信側に単にラップ・バックすることができる。本発明に従ったシステムは、受信した諸応答メッセージの識別子のリストを維持することが好ましい。このリスト内の各エントリは、そこにリストした応答メッセージが処理のために利用可能であることを指示する。
第１の識別子及び第２の識別子（前者を反射したもの）を使用すると、互いに関係するメッセージの認識及び関連付けを容易に行うことができる。本発明の推奨実施例に従ったシステムは、アプリケーション・プログラムが複数の要求メッセージを同時的に発信し、前述の識別子を使用して互いに異なるこれらの要求メッセージに関連する応答メッセージを判別することを可能にし、かくして順次的な要求メッセージのみをサポートするシステムよりも優れた処理性能を提供することができる。
本発明の他の側面に従って、「ウェーブ・テーブル」内に記録した「ウェーブ番号」を使用することにより、順序外で到着する諸応答メッセージに対する応答性を改善することができる。ウェーブ番号は、システムから送信される諸メッセージ用の順序番号と類似するような参照番号であるが、本発明に従ったウェーブ番号の使用の態様は、受信側が順序番号を使用してデータ伝送の信頼性をチェックするという従来技術のシステムと比較すると、著しく異なっている。即ち、かかる従来技術のシステムは、複数の順序番号が特定の受信側に対し順次であることを必要とするから、この順序内の穴がこの受信側にとって意味あるものとなる。他方、本発明のこの側面に従って使用するウェーブ番号は（単調に変化する数であるが）、任意の宛先に対し必ずしも順次とはならないから、従来技術のような順序番号を適用することはできないのである。これらのウェーブ番号は、メッセージの送信側によって当該メッセージに対しそれぞれ割り当てられ（例えば、一のメッセージ・フィールド又はメッセージ・ヘッダ内に記入され）、応答メッセージを介してこの送信側にラップ・バックされるようになっており、この点を除くと、受信側のアプリケーション・プログラムによって使用されることはないのである。
本発明のこの側面に従って、アプリケーション・プログラム間の通信をサポートするための機構及びアプリケーション・インフラストラクチャを有するデータ処理システムであって、当該アプリケーション・インフラストラクチャが、
サポートされる第１のアプリケーション・プログラムから送信される一の要求メッセージに対しその参照番号（ウェーブ番号）を割り当てるとともに、当該参照番号を予期応答メッセージの参照番号として記録するための手段と、
受信した応答メッセージの参照番号のうち最高の参照番号を記録及び更新するための手段と、
前記第１のアプリケーション・プログラム内でウォータシェッド（watershed）に到達するたびに、前記記録した予期応答メッセージの参照番号を新しく割り当てた一の参照番号で更新するための手段と、
前記要求メッセージに応答して前記アプリケーション・インフラストラクチャが受信し且つ関連する要求の参照番号を含んでいる応答メッセージを検査するとともに、受信した一の応答メッセージの参照番号が前記予期応答メッセージの参照番号又は前記最高の参照番号と一致するか否かを決定するための手段とを含んでいる、前記データ処理システムが提供される。
本発明のこの側面は、要求を受信したアプリケーション・プログラムをサポートすべく、アプリケーション・インフラストラクチャが、一の要求メッセージの参照番号を検索するための手段と、当該参照番号を関連する応答メッセージに対し割り当てるための手段とを有することを必要とする。
このアプリケーション内にウォータシェッドを生じさせるような諸条件は、このアプリケーション自体が決定する。これらの条件は、アプリケーションの或る側面を限界付けるのが適当である、当該アプリケーション内の任意のカットオフ点とすることができる。即ち、ウォータシェッドの前に受信したメッセージを当該ウォータシェッドの後に受信したメッセージとは異なった態様で処理することが望ましい場合は、このウォータシェッドは、設定したタイムアウト期間の満了とすることができる。本発明の前記決定するための手段は、一の応答メッセージを当該アプリケーション・プログラムのウォータシェッドの前又は後のどちらで受信したかを判別する。各ウォータシェッドは、タイムアウトやアプリケーションが開始した任意のアクションを含むような種々の条件によって生ぜられることがある。例えば、第１のアプリケーション・プログラムが他のアプリケーション・プログラムから一の要求メッセージを受信した後に、これに応答する場合には、この応答メッセージの送信が第１のアプリケーション・プログラム内にウォータシェッドを生じさせることがある。代替的に、待機中の１組のメッセージのうち最後のメッセージを受信すると、ウォータシェッド用の諸条件を満足させることがある。
かくて、これらの参照番号又は「ウェーブ番号」及び「ウェーブ・テーブル」（この内部には、予期応答メッセージのウェーブ番号及び受信した諸応答メッセージの参照番号のうち最高の参照番号が記録されている）を使用すると、前記アプリケーション・インフラストラクチャは、特定のタスク内で同時的な複数のメッセージを送信するようなアプリケーションをサポートするとともに、順序外で到着することがある諸応答メッセージを扱うことができる（かかる順序外の到着は、予期応答メッセージのウェーブ番号と受信した応答メッセージの参照番号が一致しない場合に相当する）。また、これらを使用すると、重複メッセージを容易に識別することができる（かかるメッセージの重複は、受信した一の応答メッセージのウェーブ番号が受信した応答メッセージの記録済みの最高のウェーブ番号と一致する場合に相当する）。この点については、以下で詳述する。
このように、重複メッセージを識別可能にすると、一の要求メッセージに関連する応答メッセージを待機しているユーザは、当該メッセージの送信を自由に再試行することができ、その場合でも、システムは最初のメッセージと再試行対象のメッセージを混同せずに確実に処理することができる。かくて、エンド・ユーザは、一の要求メッセージが失われたか又は遅延されたことが疑わしい場合には、両要求メッセージに対する応答メッセージを最終的に受信する場合の反復処理のリスクを負うことなく、要求メッセージの送信を再試行することができる。
本発明の第３の側面に従って、アプリケーション・プログラム間で送信されるメッセージの処理をサポートするための方法であって、
着信メッセージを検査して各メッセージのタイプを決定するためのステップと、
前記メッセージを処理すべきモジュール状アプリケーション・プログラムの特定のアプリケーション・プログラム構成要素を選択するためのステップとを含み、
前記選択が、入力メッセージのタイプとアプリケーション・プログラム構成要素との間の予め定義された関係に従って行われる、前記方法が提供される。
適当なアプリケーション・プログラム構成要素の選択は、着信メッセージの種々のタイプ及び特性ごとに行われるべき諸操作を定義するための複数の規則を適用することを含んでいるのが好ましい。サポートされるこれらの規則は、動的特性（例えば、メッセージが到着する前に一のタイマが満了したか、受信時点における当該アプリケーションの状態、待機中の１組の応答メッセージの全てを受信したか、等）を考慮することが好ましい。
本発明の推奨実施例に従った方法は、分散アプリケーション内のアプリケーション・プログラム（DAP）間で送信されるメッセージの処理をサポートする。
本発明の第４の側面に従って、アプリケーション・プログラム間の通信をサポートするための記録媒体に格納したプログラム製品であって、
前記プログラム製品を搭載したデータ処理システムによって受信される入力メッセージの処理をサポートするためのアプリケーション・インフラストラクチャ（AI）を含み、当該AIが、
入力メッセージのタイプをリストするための手段と、
前記AIによってサポートされるモジュール状アプリケーション・プログラムの別個に選択可能なアプリケーション・プログラム構成要素をリストするための手段と、
一の入力メッセージのタイプを識別するとともに、入力メッセージのタイプとアプリケーション・プログラム構成要素との間の予め定義された関係に従って、前記入力メッセージを処理すべき１つ以上のアプリケーション・プログラム構成要素を選択するための手段を含んでいる、前記プログラム製品が提供される。
［実施例の説明］
以下、添付図面を参照して、本発明の実施例を詳述する。
図１は、アプリケーション・プログラム間の両方向性メッセージ・キューイング通信を示す概略図である。
図２は、クライアント／サーバ・アプリケーションにおけるメッセージ・キューイング通信を示す概略図である。
図３は、本発明をその内部で実現可能なコンピュータ・システムを示す概略図である。
図４は、本発明の実施例に従ってサポートされるアプリケーションの３つの段（tier）を示す図である。
図５は、サポートされるアプリケーションが稼働する場合に使用されるアプリケーション・インフラストラクチャの主要な構成要素と、クライアント／サーバ環境におけるこれらの構成要素の位置を示す図である。
図６は、サポートされるアプリケーションの諸クラス、諸規則及び諸手順の間の関係と、交換メッセージを示す図である。
図7A〜図7Eは、許容された種々の規則のタイプについて行われる、本発明に従った方法の一連の操作を示す図である。
本発明の特定実施例の理解を助けるために、先ず、メッセージ・キューイング通信を説明する。メッセージ・キューイングとは、分散環境に適した公知のプログラム間通信方法であって、アプリケーション間に直接的な接続を確率することなく、アプリケーション特有のデータをこれらのアプリケーションが送信及び受信することを可能にするものである。以下でメッセージ・キューイングを説明するのは、本発明の特定の実現形態を理解できるようにするためであって、これにより本発明の適用性がメッセージ・キューイング・システムに制限されるわけではない。
プログラム間通信のメッセージ・キューイング方法は、非同期のコネクションレス通信をサポートする。コネクションレス通信を行うために、第１のアプリケーション・プログラム（Ｘ）が一のメッセージ・キューイング・サービスにメッセージを与え、第２のアプリケーション・プログラム（Ｙ）が当該メッセージ・キューイング・サービスからこれらのメッセージを獲得するようになっている。このメッセージ・キューイング・サービスは、中間手段として機能し、そしてかかるメッセージをＸのメッセージ・キューイング・サービスからＹのメッセージ・キューイング・サービスへ伝送するための機構は、アプリケーション・プログラムＸ及びＹから完全に隠すことができる。
キュー・マネージャとは、各アプリケーションが使用するメッセージ・キューイング機構を提供するようなシステム・サービスであって、通信マネージャ・プログラム製品として実現することができる。メッセージ・キューイング・サービスを得るため、各アプリケーションは、アプリケーション・プログラミング・インタフェース（API）を使用して、ローカルのキュー・マネージャ（即ち、当該アプリケーションと同一のシステム上に導入されているキュー・マネージャ）と通信する。
メッセージ・キューとは、名前の付いたオブジェクトであって、その内部にメッセージを累積し、そこからのメッセージの除去を時間に独立した態様で（即ち、送信側が決定する時間ではなく、受信側のアプリケーションの準備が完了した場合に）行うようなものである。このキューは特定の１つのキュー・マネージャに属し、当該キュー・マネージャがこれを維持するようになっている。メッセージ・キューの物理的表示は、環境に依存して、主記憶内の少なくとも１つのバッファ、ディスク若しくは他の永続記憶上の少なくとも１つのファイル、又はその両方とすることができる。しかしながら、メッセージ・キューの物理的管理は、キュー・マネージャの責任であり、このため、その詳細はアプリケーション・プログラムには明白にされない。
各アプリケーションは、名前の付いた特定のメッセージ・キューを使用することを合意した上で、通信を行うようになっている。例えば、図１に概略的に示しているように、プログラム10がプログラム20に情報を送信することを望んでいる場合、プログラム10はキュー30に一のメッセージを送信する。なぜなら、このキュー30について、その読み取りを行うことをプログラム20が合意しているからである。図１内の矢印f1〜f4は、プログラム10とキュー30との間のメッセージ流を示している。もし、プログラム20が応答することを望んでいれば、プログラム20はキュー40にメッセージを送信する。なぜなら、このキュー40について、その読み取りを行うことをプログラム10が合意しているからである。これらのキューの位置は、メッセージを送信する各アプリケーションには明白でない。即ち、各アプリケーション（10、20）は、そのローカルのキュー・マネージャ（60、50）と対話するに過ぎず、そしてこれらのアプリケーション・プログラムがネットワークの変動や複雑さから遮蔽されるような態様で、所定のキューにメッセージを移動させる責任は、相互接続されたキュー・マネージャのネットワークが負うからである。メッセージの転送や後続の処理によって回復可能な諸資源に加えられる全ての変更は、後の障害発生時に使用するために、回復ログ70、80内に記録するようになっている。このようなアプリケーション・サポートは、前掲のIBM社の製品「MQSeries」を含む、市販のメッセージ交換ソフトウェアによって提供される。
IBM社の製品「MQSeries」はIBM社から入手可能な次の刊行物に詳述されている。"MQSeries Message Queue Interface Technical Reference"（IBM document number SC33−0850−01）、及び"IBM Messaging and Queuing Series−An Introduction to Messaging and Queuing（IBM document number GC33−0850−00）。本明細書では、これらの刊行物を援用する。
図１に示しているような１対１の通信に加えて、１対多の通信（例えば、単一のアプリケーションの３つのインスタンスが並行的に稼働していて、同一のキューからメッセージを取り出すような場合）や、多対１の通信（例えば、単一のサーバにメッセージを送信するような複数のクライアントが存在する場合）や、これらの全ての関係の組み合わせを想定することも可能である。
メッセージ・キューイングは、多数のクライアント・プログラムが単一のサーバ・プログラムにメッセージを送信するようなクライアント／サーバ・アプリケーションに非常に適している。図２は、３つのクライアントＡ〜ＣがサーバＳにメッセージを送信するというケースを示している。サーバＳは、要求の送信元に依存して、３種類のキューに応答する。図２の例では、クライアントＡ及びＢがサーバＳから遠隔に設置されており、他方、クライアントＣはサーバＳに対しローカルに設置されている。図２は、単一のキュー（QS）上にメッセージを書き込む幾つかのクライアント・プログラムを示しているが、既に指摘したように、幾つかのクライアント・プログラムが単一のキューからメッセージを獲得することも可能である。このことが有用となるのは、メッセージ・トラヒックの量が１つのサーバ・アプリケーション・プログラム・インスタンスの処理能力を超えるような場合である。また、一のクライアントからの一の要求メッセージを複数の要求メッセージに分割した後、これらの要求メッセージを異なるサーバによって並列に処理できることに留意すべきである。
キュー・マネージャQM1、QM2は、相当なアプリケーション通信サポート（各メッセージ・キューを維持したり各メッセージと各キューとの間の関係を維持すること、ネットワークの障害及び再始動を処理すること、ネットワークを通してメッセージを移動させること、など）を提供するが、大規模で、拡張可能な統合型のクライアント／サーバ・アプリケーションを開発するというプログラミング作業は、依然として困難な状況にある。この作業に関連する諸問題を解決するために、本発明は、他のシステム構成要素（実際にはコンピュータ・ソフトウェア内で実現される１組の構成要素）、即ちクライアント／サーバ・アプリケーションの設計、開発及び稼働時の実行をサポートするためのアプリケーション・インフラストラクチャを提供する。
図３は、コンピュータ・システムの主要なシステム構成要素の階層構造を、簡略的に示している。これらのシステム構成要素は、本発明をその内部で実現するアプリケーション・インフラストラクチャを含んでいる。典型的な分散データ処理ネットワークは、複数の異種コンピュータ・システム100から成り、その各々はラップトップ又はデスクトップからメインフレーム・システムまでの範囲に及ぶことがあり、当該システム上で稼働中の特定のアプリケーション・プログラム110を有している。これらのアプリケーション110は、これが稼働しているシステム100上の特定のオペレーティング・システム120に適合している。また、本発明のこの実施例に従ったシステム内に設けられているのは、ネットワーク・リンク140を介してアプリケーション・プログラム110間の情報交換をサポートするための、アプリケーションのイネーブルを行う通信マネージャ150である。この通信マネージャ150は、オペレーティング・システム120とインタフェースするとともに、これらのアプリケーション110のためのサービスを提供する。即ち、これらのアプリケーション110を当該ネットワークの複雑さから遮蔽するとともに、安全なプログラム間通信を提供するという作業を管理するのである。
この通信マネージャ150にリンクされ且つこの通信マネージャ150及びオペレーティング・システム120の機能を利用するように適応されているのは、分散クライアント／サーバ・アプリケーションの設計、開発及び稼働時の実行をサポートするためのアプリケーション・インフラストラクチャ160である。以下、このアプリケーション・インフラストラクチャ160の実施例及びこれがサポート可能なクライアント／サーバ・アプリケーションの構造の例を説明する。
サポートされるアプリケーションの構造
アプリケーション・インフラストラクチャは、機能が再使用可能な複数のユニットにカプセル化されているような構造化アプリケーション・コードの使用を可能にする。アプリケーション・インフラストラクチャの諸機構を活用するように適応されたアプリケーション（以下「サポートされるアプリケーション」と表記）は、例えば、IBM社の「OS/2」オペレーティング・システムを搭載したワークステーションを使用してエンド・ユーザに対しサービスを提供するが、このアプリケーション全体のそれぞれ異なる部分は、ユーザのワークステーション、LANアプリケーション・サーバ及びホスト・システム（例えば、IBM社の「ES/9000」メインフレーム）上で稼働する。後述のように、このアプリケーションのロジックは、諸規則がこれを統合するようになっている（即ち、本発明のこの例では、諸規則は、当該アプリケーションの主要部分であって、諸規則を適用するための機能を提供するアプリケーション・インフラストラクチャの部分として定義されるのではない）。
「サポートされるアプリケーション」という表記を使用したとしても、このことは、本発明を実現するシステムが他のアプリケーションをサポートしないことを意味するものではない。この表記を使用した意図は、本発明に従ったアプリケーション・インフラストラクチャによって可能にされ且つこのアプリケーション・インフラストラクチャを十分に活用するような柔軟な分散クライアント／サーバ・アプリケーションの構造を表現することにある。
（注:OS/2及びES/9000は、インターナショナル・ビジネス・マシーンズ・コーポレイションの商標）。
サポートされるアプリケーションは、最上位のレベルにおいて、諸規則によって関連付けられた１組の「クラス」として構築される。以下に示すように、これらのクラスは、３つのタイプに類別することができる。
1.グラフィカル・ユーザ・インタフェース（GUI）クラス：これらのクラスは、ユーザのワークステーション上で稼働する。これらのクラスは、ユーザがアプリケーションと対話するためのウインドウを提供し、他方、これらのクラスは、メッセージの送信及び受信を通してアプリケーションの残りと対話する。
典型的なアプリケーションは、多数のGUIクラスを含んでいる。一般に、１つ以上のGUIクラスは、実行可能な単一のGUIプログラムにパッケージされることが多い。
2.ビジネス・ロジック（BL）クラス：これらのクラスは、LANアプリケーション・サーバ上で稼働する。これらのクラスは、当該アプリケーションに関係する進行中の作業データを収集及び格納し、当該データについて計算を行うとともに、当該データを他の諸クラスに送信する。これらのBLクラスは、メッセージの送信及び受信を通してアプリケーションの残りと対話する。
典型的なアプリケーションは、多数のBLクラスを含んでいる。一般に、これらのBLクラスは、互いに独立に単一の動的リンク・ライブラリとしてパッケージされることが多い。
3.ホスト・クラス：これらのクラスは、IBM社の「CICS」若しくは「IMS」トランザクション処理システムのようなバックエンド・システム、又はIBM社の「MQSeries」キュー・マネージャ製品を搭載した任意のシステム上で稼働する。これらのホスト・クラスは、トランザクション制御の下でホスト・データベースの読み取り及び書き込みを行うための手段を提供し、一般に、これらのクラスが更新するデータの完全性と監査性（auditability）を維持するための責任を有する。
これらのホスト・クラスは、アプリケーション・サポート・インタフェースの制御下では稼働しないが、関係する「MQSeries」キュー・マネージャ製品のメッセージ・キューイング・インタフェース（MQI）を使用して、諸要求を受信し且つこれに応答する際に標準のMQIガイドラインに従う。なお、MQIとは、前掲のIBM社の刊行物（IBM document number SC33−0850−01）に記述されているようなアプリケーション・プログラミング・インタフェース（API）である。
（注:CICS及びIMSは、インターナショナル・ビジネス・マシーンズ・コーポレイションの商標）。
これらの異なるタイプのクラスは、アプリケーション内の互いに異なる一般的な役割を反映する。例えば、一のGUIクラスがユーザとの対話をサポートし、一のホスト・クラスがホスト・データへのアクセスを提供するのに対し、一のBLクラスはキャッシュ機能を提供して、一のGUIがホストから一度検索したデータを後続アクセスの際にLANから一層速やかに検索できるようにする。全てのGUI及びBLクラスは、他のクラスに対しクライアント及びサーバとなることができる（即ち、諸クラス間の関係は、「ピア・ツー・ピア」である）。
図４は、この分散クライアント／サーバ方式の３つの段の間の関係を示している。各矢印は、分散アプリケーションを構成する複数のクラス210の間の可能なメッセージ流200を示している。
サポートされるアプリケーション内に存在する諸規則は、どのクラスがどのメッセージを他のどのクラスに送信可能であるかを定義及び制限することにより、コンパイル時及び稼働時のチェックを通して当該アプリケーションの開発、テスト及びサポートを援助することを可能にする。諸規則は、クライアント／サーバのメッセージ交換アプリケーションに関連する全ての非同期状態（例えば、タイムアウト、複数の応答メッセージを待機する必要性、無効メッセージのようなエラー）をどのように処理するかを定義する。諸規則の定義及びその使用法については、以下で詳述する。
次の細分性レベルでは、一のアプリケーション・クラスが１組の「手順」（その各々はモジュール状のアプリケーション・プログラム構成要素として実現される）として構築される。各手順は、クライアントの役割を行う他のクラスからの要求メッセージの到着、又はサーバの役割を行う他のクラスからの応答メッセージの到着のような単一の状態をそれぞれ扱う。一の手順は、実行後に終了する（例えば、一の要求メッセージを行った後、当該手順がその応答メッセージを待機しないような場合であり、この場合、当該クラスはその応答メッセージを処理するように書かれた他の手順を含むことになろう）。
かくて、アプリケーション・インフラストラクチャは、諸規則を使用して、どの状況でどの手順を呼び出すかを決定する。各規則は、一のクラス・ソース・ファイル内の一のRULEセクションにおいて定義するようになっている。このRULEセクションは、当該規則を満足させる場合に呼び出される手順の名前を指定する。この名前は、この手順をクラス・ソース・ファイル内のRULEセクションにおいて定義するに過ぎないから、この手順の定義は、当該規則を呼び出すようなプログラムの実際の名前を指定する必要はない。
また、このRULEセクションは、当該規則を満足させるのに必要な諸条件を指定する。これらの条件は、次の事項に基づくことがある。
＊  １つ以上のメッセージの到着
＊  タイマの満了
＊  当該インスタンスが置かれている状態
各規則内では、少なくとも１つのメッセージ・タイプ及び一のタイマを指定する。他方、インスタンス状態（即ち、当該規則を満足させるために、当該インスタンスが置かれていなければならない状態、又は置かれていてはならない状態）は、追加のオプション条件である。
一の規則内で指定可能な諸条件は、一定ではなく、しかも複雑なものとなり得る。なぜなら、３つの基本的なメッセージ・タイプ（情報、要求及び応答）と、指定可能な４つの基準（必須、条件付き、遅れ及びプレースホルダ）が存在する上に、一のタイマを当該規則に加えることができるからである。これらの規則の任意のものに対し、インスタンス状態に関する諸条件を追加することができる。
アプリケーション・インフラストラクチャの構成要素
ここで、このアプリケーション・インフラストラクチャの主要な構成要素を特定しておくのが有用である。図５は、サポートされるアプリケーションが稼働する場合に使用されるアプリケーション・インフラストラクチャの諸部分を示している。その主要な構成要素は、次の通りである。
＊  プレゼンテーション・ロジック・マネージャ：この構成要素（250）は、ユーザのワークステーション上で稼働し、諸GUI手順が使用する環境及びAPIを提供する。
＊  ビジネス・ロジック・マネージャ：この構成要素（260）は、LANアプリケーション・サーバ・システム上で稼働し、諸ビジネス・ロジック手順が使用する環境及びAPIを提供する。
＊  規則コンパイラ：この構成要素は、アプリケーション開発中に使用される。これは、アプリケーション・インフラストラクチャ特有の言語（規則定義言語として知られているもの）で書かれたASCIIソース・ファイルを読み取り、バイナリ・ファイルを出力する。このバイナリ・ファイルは、特定のメッセージの到着時にどの手順を呼び出すかを決定するべく、稼働時にビジネス・ロジック・マネージャ及びプレゼンテーション・ロジック・マネージャがこれを使用する。
＊  ジョブ・ビューア：この構成要素（270）は、ユーザのワークステーション上で稼働し、一のジョブに関連する諸ウインドウをリストし且つこれらの間のナビゲーションを許容するようなコンテナ・ウィンドウを提供する。ジョブとは、サポートされるアプリケーションの一の実行インスタンスであって、その境界をユーザが決定できるようなものである。また、この文脈における「インスタンス」とは、サポートされるアプリケーションの特定クラスの実行インスタンスを意味する。このジョブ・ビューアは、ユーザが稼働させている複数のジョブを援助して、一のジョブの諸ウインドウと他のジョブの諸ウインドウとの間の混同を回避させる。
アプリケーション・インフラストラクチャの特定の実現形態は、アプリケーションのテスト及びデバッグに関係付けられた追加の諸構成要素を含むことがあるが、本明細書においてこれらの構成要素を詳述する必要はない。
分散アプリケーション・インフラストラクチャの操作
この分散アプリケーション・インフラストラクチャは、着信メッセージを処理すべき適当なアプリケーション・プログラム構成要素を選択するために、テーブル・ドリブン型のアプローチを使用する。このテーブルは、特定のメッセージ・タイプ及びメッセージの他の静的特性を、これらのメッセージを処理すべき適当なコード・モジュールと関連付ける。このテーブルは、アプリケーション・プログラムが起動時に取る最初のアクションとして、構築されるようになっている。
これとは別個の「ウェーブ・テーブル」は、アプリケーション・プログラムから送信される発信メッセージに関連するような特定の参照番号（ウェーブ番号）を記録する。ウェーブ番号は、所定のメッセージを識別するために使用する単調に変化する数であって、代替処理や、時間通りの（正常に処理すべき）メッセージと、遅れている（が、依然として最新で且つ依然として処理すべき）メッセージと、順序外のメッセージとの間の判別を行うことを可能にする。この分散アプリケーション・インフラストラクチャは、かかるウェーブ・テーブルを構築して、全ての応答メッセージ用のスロットを提供する。このウェーブ・テーブルは、受信メッセージの最高のウェーブ番号（０に初期設定）を記入するためのフィールドと、現グローバル・ウェーブ番号（１に初期設定）を記入するための他のフィールドとを含んでいる。
この分散アプリケーション・インフラストラクチャの制御下で稼働しているアプリケーション・プログラムが、１つ以上の要求メッセージを送信して、これに関連する応答メッセージを予期する場合、この分散アプリケーション・インフラストラクチャは、現グローバル・ウェーブ番号を、発信メッセージのフィールド及び当該発信メッセージ用のテーブル・スロットへコピーする。
この要求メッセージを受信するアプリケーション・プログラムも、サポートされるアプリケーションでなければならない（或いは、少なくともこのウェーブ番号をその応答メッセージ内に保持させて、ラップ・バック可能でなければならない）。その下部でサポートされるアプリケーションを稼働させる分散アプリケーション・インフラストラクチャの各々は、受信メッセージのウェーブ番号を自動的に検索するとともに、このウェーブ番号を応答メッセージに付加するための手段（即ち、着信メッセージのフィールドからウェーブ番号を読み取り、これを発信メッセージのフィールドへ書き込むための手段）を有している。
応答メッセージが到着する場合、これを受信するアプリケーション・インフラストラクチャは、当該応答メッセージ内のウェーブ番号を、記録した現グローバル・ウェーブ番号と比較する。現グローバル・ウェーブ番号は、当該応答メッセージの予期されるウェーブ番号である。なぜなら、最も普通の処理条件を想定すれば、現グローバル・ウェーブ番号が変更される前に、要求メッセージに関連する当該応答メッセージが受信されることになるからである。現グローバル・ウェーブ番号が変更されるのは、当該アプリケーション・プログラム内のウォータシェッドに到達する場合である。ウォータシェッドとは、アプリケーション・プログラムの実行中における当該アプリケーションが定義した変更点であって、タイムアウトの発生又は明示的なアプリケーション・アクションの何れかとすることができる。このような１つのアプリケーション・アクションは、現アプリケーションからローカル・アプリケーションを呼び出した他のアプリケーションへ応答メッセージを送信することにより、当該ローカル・アプリケーション内の手順を完了することである。他のアプリケーション・アクションは、一の規則を満足させる場合に、新しいアプリケーションを呼び出すことである。
もし、受信済みの応答メッセージ内のウェーブ番号が現グローバル・ウェーブ番号（即ち、応答メッセージの予期されるウェーブ番号）と一致すれば、当該メッセージは、時間通りであると見なされる。他方、これらが一致しなければ、当該メッセージは、時間通りでないと見なされる。後者の状況において、アプリケーション・インフラストラクチャは、応答メッセージ内のウェーブ番号を、テーブル内にある受信済みの最高のウェーブ番号フィールドと比較する。もし、受信した応答メッセージ内のウェーブ番号が「受信済みの最高のウェーブ番号」よりも大きければ、当該応答メッセージは、「遅れている」メッセージと見なされる（後出）。他方、受信した応答メッセージ内のウェーブ番号が「受信済みの最高のウェーブ番号」よりも小さければ、当該メッセージは、「時間外」メッセージと見なされる（即ち、要求を送信したアプリケーション・プログラムの手順がウォータシェッドを通過した後に、当該応答メッセージが到着した、ということである）。更に、受信した応答メッセージ内のウェーブ番号が「受信済みの最高のウェーブ番号」に等しければ、当該応答メッセージは、重複メッセージであることが明白である。
前記の重複メッセージ及び「時間外」メッセージの両ケースは、エラー・メッセージの生成をトリガして、当該応答メッセージを廃棄させる。
「遅れている」応答メッセージとは、諸要求メッセージ及びこれに関連する諸応答メッセージが順序通りに生起しないという結果を引き起こすように、一の時点に到着した応答メッセージである。殆どのケースにおいて、受信中のアプリケーションは、ウォータシェッドの前に受信した応答メッセージ（即ち、「時間外」（out of time）応答メッセージではなく、単に順序通りではない応答メッセージ）を依然として処理することを望んでいる筈である。この操作時間シーケンスは、次のようになることがある。
1.  要求１の送信；
2.  要求２の送信；
3.  応答１の受信；
4.  応答２の受信。
前述の用語を使用すると、「応答１」は、「要求２」の送信後に受信されているから「遅れている」が、依然としてアプリケーションが処理することを望んでいるような現メッセージである。かくて、アプリケーション・インフラストラクチャは、「遅れている」（順序通りでない）が依然として有効であるような応答メッセージと、重複しているか又は「時間外」であるために無効であるような応答メッセージとを判別することを可能にする。これを簡単に且つ確実に行うには、一のメッセージ・フィールド内にある一の数を使用して、これをウェーブ・テーブル内にある記録済みの数と比較すればよい。かくて、アプリケーション・インフラストラクチャは、複数の同時的な要求メッセージを送信するとともに、これらの要求メッセージに関連する複数の応答メッセージを適正に処理することができるだけでなく、かかる要求メッセージと応答メッセージとの間の混同を生じさせないようにすることができる。
着信メッセージを受信する場合のアプリケーション・インフラストラクチャの操作は、次の通りである。分散アプリケーション内にあるアプリケーション・プログラム（DAP）への着信メッセージをその分散アプリケーション・インフラストラクチャ（DAI）が検査し、これらのメッセージ内の諸フィールドをテーブル内の一定値と比較する。このメッセージ・タイプが一のテーブル・リスティング・メッセージ・タイプの内部で位置付けられるか、又は関連するテーブル・エントリがなければ、エラーが生ずる。このメッセージは、要求メッセージ、応答メッセージ又は情報メッセージ（これらは、アプリケーション・インフラストラクチャが定義する３つのメッセージ「タイプ」である）とすることができ、また追加命令、更新命令又は削除命令（これらは、当該アプリケーションが定義するメッセージ「タイプ」の側面である）の何れかとすることができる。第２に、このメッセージの識別子の値を、システムが既に関係している諸タスク用のリストした識別子（即ち、当該システムにおいて発信した諸要求メッセージの識別子のリスト）と比較する。もし、この受信メッセージが新しい要求メッセージであれば、このテーブル内には一致する識別子が存在しないことになる。他方、このメッセージが現システムからの（時間外でない）一の要求メッセージに関連する応答メッセージであれば、一致するテーブル・エントリが存在することになる。第３に、ウェーブ・テーブルを検査して、このメッセージがエラー条件（例えば、時間外、順序外又は重複）を生じさせるか否かをチェックする。第４に、このメッセージの前記及び他の諸特性（並びに当該システム又は当該アプリケーションの他の可能な諸特性）を検査し、どのアプリケーション・プログラム構成要素を呼び出すべきかを指示する諸規則と比較する。
もし、このメッセージが要求メッセージであれば、このメッセージは、関連する規則内で指定されている適当なアプリケーション・プログラム構成要素に渡される。他方、このメッセージが応答メッセージであれば、このメッセージは、特定のリストに関連し且つ当該アプリケーション・プログラムによる処理のために利用可能な、応答のリストに追加される。処理用の諸規則を走査して１つの規則が今や満足されているか否かを決定し、もしそうであれば、適当なアプリケーション・プログラム構成要素が呼び出される。例えば、このような１つの規則は、１組の応答メッセージを処理すべき手順が呼び出される前に、これらの全ての応答メッセージが受信されていることを必要とすることがあり、そのため、受信した応答メッセージの識別子のリストを走査して全ての応答メッセージが今や利用可能であるか否かを決定するようにしている。もし、予定のタイムアウト期間内に全ての応答メッセージが到着しなければ、一の「タイムアウト規則」内で命名された手順が呼び出される。
以下では、タイマ制御及び他の動的制御を含む諸規則用のサポートを詳述する。前述のように、アプリケーション・インフラストラクチャのAPI及びこれに関係するサービスは、インスタンス間の通信を行うためにメッセージ交換を使用する。また、アプリケーション・インフラストラクチャ並びに管理用のアプリケーション・インスタンスは、前出のメッセージ・キューイング・インタフェース（MQI）への呼び出しを使用してかかる通信を実現しているから、サポートされるアプリケーションは、このMQIを直接的に使用しないでアプリケーション・インフラストラクチャのAPIを使用するようになっている。
アプリケーション・インフラストラクチャのプレゼンテーション・ロジック・マネージャは、一の規則の範囲内で一のタイマを起動するために使用することができる、API呼び出しMQTIMEをサポートする。この特定の時限付き規則（クラス・ソース・ファイルのRULEセクション内で定義されている）の名前は、このMQTIME呼び出しのパラメータであるが、タイムアウト期間はそのままであり当該タイムアウト期間の後は当該命名された規則についてのタイマが満了する。
一の手順における時限付き規則の各々ごとに、関連するタイマが存在する。各タイマは、PLM制御の下で呼び出し可能な４つのアクションを有する。即ち、デフォルトのタイムアウト期間（例えば、１秒）を持つタイマを起動すること、所定の値（即ち、該当するAPI呼び出し中に渡されるパラメータが設定したタイムアウト期間）を持つタイマを起動すること、直ちに満了するようにタイマを起動すること、そして無限に設定したタイムアウト期間（即ち、満了することがないタイムアウト期間）を持つタイマを起動することである。後者のオプションは、主として、時限付き規則を含んでいるアプリケーションをテストする場合に使用する。
一のタイマが満了し且つ一の規則が満足される場合、一の規則に関連する複数のメッセージのうち幾つかの又は全てのメッセージが存在しないことがある。
規則の充足
一のメッセージが一のクラス・ソース・ファイル内の一のメッセージ定義に一致して一の規則を満足させるには、次の諸条件を充足させなければならない。
＊  当該メッセージの宛先クラスは、プレゼンテーション・ロジック・マネージャ又はビジネス・ロジック・マネージャによってサポートされた一のクラスでなければならない。
＊  当該メッセージの次のプロパティは、当該規則内で指定されている当該メッセージの定義に一致しなければならない。
メッセージ・タイプ
操作コード
操作バージョン
役割（応答メッセージの場合のみ）
＊  当該メッセージは、当該規則内で指定されているものと同一のファーマットを有さなければならない。
＊  もし、当該メッセージが固定フォーマットを有するのであれば、そのメッセージ・データの長さは、当該規則内で指定されている当該メッセージのそれと同一でなければならない。
図５は、一の規則が満足される場合の処理シーケンスの１例に加えて、諸クラスと、諸規則と、諸手順との間の関係を示している。この例における処理シーケンスは、次の通りである。
1.  １つのクラスの一のインスタンスが、一のメッセージを他のクラスの一のインスタンスへ送信する。
2.  予定の１組のメッセージが到着する場合に、一の規則が満足される。
3.  この規則が、一の手順を呼び出す。
4.  この手順が、当該クラスについて或る作業を行う。この作業は、追加のメッセージを他のクラスに送信することを含むことがある。
許容された規則のタイプ
一の規則内で指定可能な諸条件は、複雑になり得る。以下では、使用可能な規則のタイプ及びこれらが指定可能なメッセージを説明する。
プレースホルダ・メッセージ：到着していないメッセージ用の場所を当該規則内に予約するために、プレースホルダ基準を利用することができる。これを使用する諸規則では、遅れている一の応答メッセージが、２以上の必須応答メッセージ用の規則と同一の手順を呼び出すことが好ましい。また、これらのプレースホルダが使用されるのは、現在のアプリケーションには関係ないが、このアプリケーションに対し将来追加されるであろうメッセージ用の場所を予約することを、プログラマが望んでいるような場合である。
許容された規則のタイプの例は、以下に示されている。
1.単一の情報メッセージ用の規則：この規則が満足されるのは、指定された単一の情報メッセージが到着する場合である。
例A:図7Aに示すように、インスタンス１が単一の情報メッセージをインスタンス２へ送信する。このメッセージの到着は規則１を満足させ、手順１が呼び出される。
アプリケーション・インフラストラクチャが手順１を呼び出す場合、これは、BL情報メッセージが到着したことを示すために、当該メッセージの識別子をこの手順に渡す。
2.単一の要求メッセージ用の規則：このタイプの規則が満足されるのは、指定された単一の要求メッセージが到着する場合である。
例B:図7Bに示すように、インスタンス１が単一の要求メッセージをインスタンス２へ送信する。このメッセージの到着は、規則２を満足させる。
この手順１が呼び出される場合、BL要求メッセージが到着したことを示すために、当該メッセージの識別子が手順１に渡される。
3.単一の遅れた応答メッセージ用の規則：一の要求メッセージを処理する手順が他のクラスからの情報を獲得するためにそれ自体の要求メッセージを送信しなければならない場合、その応答メッセージが必要な時点よりも遅れて到着することがある。もし、これが元の要求メッセージに関連する応答メッセージとして使用するには遅れすぎて到着するのであれば、この応答メッセージは「遅れている応答メッセージ」と見なされる。以下の例Ｃでは、応答２と命名されたメッセージは、遅れていると見なされる。なぜなら、このメッセージは、応答と命名されたメッセージが送信された後に到着するからである。
もし、アプリケーションが遅れている任意の応答メッセージを処理すべきであれば、このタイプ３の規則を使用しなければならない。もし、一のインスタンスが遅れている応答メッセージを処理すべき規則を有していなければ、このメッセージは廃棄される。このタイプ３の規則が満足されるのは、命名された単一の遅れている応答メッセージが到着する場合である。各規則内では、１つの遅れているメッセージだけが許容される。当該規則内の他の任意のメッセージは、プレースホルダでなければならない。
例C:図7Cに示すように、手順１が２つの要求メッセージを送信し、一のタイマをセットする。規則６が満足されるのは、１つの応答メッセージだけが到着するとしても、このタイマが満了する（手順２を呼び出す）場合である。この遅れている応答を処理するためには、タイプ３の規則が必要である。手順３が呼び出される場合、応答２のメッセージが到着したことを示すために、当該メッセージ用のメッセージ・データ・フラグが当該手順に渡される。
例D:図7Dに示すように、手順２は一の応答メッセージを使用して、これが作業を開始したことを確認する。最初の手順１は、それ自体の要求メッセージを発行した直後に、肯定応答を送信する。インスタンス３からインスタンス２への応答メッセージは、遅れていると見なされる。インスタンス２は、その要求メッセージに関連する応答メッセージを処理するために、タイプ３の規則を使用する。次に、インスタンス２は、当該遅れている応答メッセージ内に保持されているデータをインスタンス１へ送信するために、一の情報メッセージを使用する。もし、インスタンス２が遅れている一のメッセージを捕捉するための規則を有していなければ、この応答メッセージは廃棄されることになる。手順２が呼び出される場合、BL応答メッセージが到着したことを示すために、当該メッセージ用のメッセージ・データ・フラグがこの手順に渡される。
4.タイマ専用の規則：このタイプの規則が満足されるのは、そのタイマが満了する場合である。
例E:図7Eには、60秒ごとにメッセージを送信するタイマ・プログラムの例が示している。インスタンス１は、一の情報メッセージを手順１に送信して、この手順１を起動する。このメッセージを送信するとき、インスタンス１は、インスタンス２内にインタレストを登録する。手順１は、API呼び出しMQTIMEを使用してタイムアウト・イベントを生成し、60秒の持続時間を有するタイマを起動する。この呼び出しの際、当該タイマが満足させるべき当該規則の名前が指定される。
このタイマが満了するとき、これは規則４を満足させて、手順２を呼び出す。手順２は、60秒ごとに、当該ジョブ内の関係する全てのインスタンスへメッセージ（図7EにおいてTickと命名されたもの）を送信する。
手順２を呼び出すとき、アプリケーション・インフラストラクチャは、当該規則に関連するメッセージが存在しないために、この手順にメッセージ・データ・フラグを渡さない。
必須応答メッセージ用の規則：このタイプの規則が満足されるのは、全ての応答メッセージが到着した場合だけである。このような規則は、１つの応答メッセージを必要とする１つの要求メッセージのために使用するか、又は複数の要求メッセージ及びこれに関連する複数の応答メッセージのために使用することができる。
条件付き応答メッセージ及びタイマ用の規則：このタイプの規則が満足されるのは、如何なる応答メッセージも到着しなかったとしても、当該タイマが満了する場合でもある。もし、一の応答メッセージが、タイマの満了に起因してその規則が満足された後に受信されるのであれば、これは遅れている応答メッセージとして扱われ、これを処理するために時間通りに到着したメッセージを処理するためのものとは異なる手順が呼び出されることがある。
前述の諸規則は単なる例示であるに過ぎず、多数の形式の規則を本発明を実現したアプリケーション・インフラストラクチャによってサポートすることができることを理解すべきである。
また、当業者には明らかなように、着信メッセージをアプリケーション・プログラム構成要素と関係付けるために使用する諸テーブルを構築する作業が、アプリケーション・プログラムを起動する際の最初のアクションである必要はない。その構築は、一の稼働時テーブルを作成するためにテキスト形式の定義を使用するようなコンパイラによって行うことができる。また、かかるテーブルを最初に作成した後に、新しいテーブル・エントリ（例えば、新しいメッセージ識別子）を動的に追加することも可能である。
【図２】
0003560345.tif 000002
【図７Ａ】
0003560345.tif 000003
【図１】
0003560345.tif 000004
【図３】
0003560345.tif 000005
【図７Ｂ】
0003560345.tif 000006
【図４】
0003560345.tif 000007
【図５】
0003560345.tif 000008
【図６】
0003560345.tif 000009
【図７Ｃ】
0003560345.tif 000010
【図７Ｄ】
0003560345.tif 000011
【図７Ｅ】
0003560345.tif 000012