JPH11502044A - 分散環境におけるアプリケーション・プログラム用のサポート - Google Patents

Abstract

(57)【要約】 アプリケーション・プログラム間の通信及びこれらのプログラムによるメッセージの処理をサポートするためのシステム及び方法が提供される。受信メッセージを処理すべきモジュール状アプリケーション・プログラムの適当な構成要素を選択するために、テーブル・ドリブン型のアプローチが使用される。この選択を行うため、メッセージのタイプ（例えば、要求、情報、応答）とメッセージの他の特性（例えば、当該メッセージが（識別子の値によって識別されるような）予期された応答メッセージであるか否かということ）との間の関係が使用される。また、この選択を行うため、当該メッセージ又はシステムの動的特性（例えば、タイムアウトの満了の可能性、又はアプリケーションの状態）も使用される。複数の規則によってこれらの基準が結合されて、特定のアプリケーション・プログラム構成要素を呼び出すための条件を決定する。更に、順序外で受信したが依然として最新である応答メッセージと、無効な応答メッセージとを判別するための機構が設けられる。

Description

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

【手続補正書】特許法第１８４条の８第１項 【提出日】１９９７年６月１８日 【補正内容】 前記プログラム製品を搭載した一のシステムによって受信される入力メッセー ジの処理をサポートするための手段を含み、 前記処理をサポートするための手段が、 入力メッセージのタイプをリストするための手段と、 モジュール状アプリケーション・プログラムの別個に選択可能なアプリケーシ ョン・プログラム構成要素をリストするための手段と、 一の入力メッセージのタイプを識別するとともに、入力メッセージ・タイプ及 び一のメッセージに関連する動的特性とアプリケーション・プログラム構成要素 との間の予め定義された関係に従って、前記入力メッセージを処理すべき１つ以 上のアプリケーション・プログラム構成要素を選択するための手段を含むことを 特徴とする、前記コンピュータ・プログラム製品。 １０．前記処理をサポートするための手段が、 サポートされる第１のアプリケーション・プログラムから送信される一の要求 メッセージに対し一の参照番号を割り当てるとともに、当該参照番号を予期応答 メッセージの参照番号として記録するための手段と、 受信した応答メッセージの参照番号のうち最高の参照番号を記録及び更新する ための手段と、 前記第１のアプリケーション・プログラム内でウォータシェッドに到達するた びに、前記記録した予期応答メッセージ の参照番号を新しく割り当てた一の参照番号で更新するための手段と、 前記処理をサポートするための手段によって受信され且つ関連する要求メッセ ージの参照番号を含んでいる応答メッセージを検査するとともに、受信した一の 応答メッセージの参照番号が前記予期応答メッセージの参照番号又は前記最高の 参照番号と一致するか否かを決定するための手段とを含むことを特徴とする、請 求の範囲第１項乃至第６項の何れかに記載のデータ処理システム。 【手続補正書】特許法第１８４条の８第１項 【提出日】１９９７年８月６日 【補正内容】 前記第１のノードが、当該第１のノードからの一の発信メッセージに第１の識 別子を割り当てるための手段と、当該第１のノードからの発信メッセージの識別 子のリストを維持するための手段と、着信メッセージの前記識別子を検査し且つ 当該識別子を当該リストと比較することにより、前記リストした発信メッセージ に関連する着信メッセージを識別するための手段を有し、 前記第２のノードが、前記第１のノードからの一の受信メッセージに応答して 当該第２のノードから送信される一の応答メッセージに対し前記第１の識別子に 関連する第２の識別子を付加するための手段を有することを特徴とする、請求の 範囲第１項乃至第３項の何れかに記載のデータ処理システム。 ５．前記第２の識別子を付加するための手段が、前記第１のノードから送信され た前記メッセージの一のフィールドから前記第１の識別子の値を抽出し且つ当該 第１の識別子の値を当該メッセージに応答して送信されるメッセージの一のフィ ールド内に挿入するための手段を含むことを特徴とする、請求の範囲第４項に記 載のデータ処理システム。 ６．前記第１のノードに関連して設けられ、受信した着信メッセージのうち前記 発信メッセージ識別子のリスト内に関連する一の識別子が存在するような着信メ ッセージの識別子のリストを格納することにより、処理のために利用可能な応答 メッセージを識別するための手段を含むことを特徴とする、請求の範囲第４項又 は第５項に記載のデータ処理システム。 ７．アプリケーション・プログラム間で送信されるメッセージの処理をサポート するための方法であって、 各着信メッセージを検査してそのメッセージ・タイプを決定するためのステッ プと、 前記メッセージを処理すべきモジュール状アプリケーション・プログラムの特 定のアプリケーション・プログラム構成要素を選択するためのステップとを含み 、 前記選択が、入力メッセージ・タイプ及び一のメッセージに関連する動的特性 とアプリケーション・プログラム構成要素との間の予め定義された関係に従って 行われることを特徴とする、前記方法。 ８．分散システムにおけるメッセージの処理をサポートするために、 前記システムの第１のノードから送信される一の発信メッセージに第１の識別 子を割り当てるとともに、当該第１のノードにおいて当該第１のノードから送信 されたメッセージの識別子のリストを維持するステップと、 前記第１のノードからの一の受信メッセージに応答して前記システムの第２の ノードから送信される一の応答メッセージに対し前記第１の識別子に関連する第 ２の識別子を付加するステップと、 前記第１のノードに到着するメッセージの前記識別子を検査し且つ当該識別子 を前記リストと比較することにより、前記リストした発信メッセージに関連する 着信メッセージを識 別するステップとを含むことを特徴とする、請求の範囲第７項に記載の方法。 ９．アプリケーション・プログラム間の通信をサポートするための、コンピュー タが読み取り可能な記録媒体上に記録されたコンピュータが読み取り可能なプロ グラム・コードから成るコンピュータ・プログラム製品であって、 前記プログラム・コードが、

Claims (1)

1. 【特許請求の範囲】 １．アプリケーション・プログラム間の通信をサポートするための機構を有し、 受信した入力メッセージの処理をサポートするための手段を含み、前記処理をサ ポートするための手段が、入力メッセージ・タイプのリスト及びモジュール状ア プリケーション・プログラム（ＡＰ）の別個に選択可能なアプリケーション・プ ログラム構成要素（ＡＰＣ）のリストへの少なくとも読み取りアクセスを有する ようにしたデータ処理システムであって、 前記処理をサポートするための手段が、 入力メッセージのタイプを識別するとともに、前記リストした入力メッセージ ・タイプとアプリケーション・プログラム構成要素との間の予め定義された関係 に従って、前記入力メッセージを処理すべき１つ以上のアプリケーション・プロ グラム構成要素を選択するための手段を含み、 当該識別及び選択するための手段が、メッセージ・タイプ及び一のメッセージ に関連する動的特性を特定のアプリケーション・プログラム構成要素と関係付け るメッセージ処理用の規則に依存して、アプリケーション・プログラム構成要素 の前記選択をサポートすることを特徴とする、前記データ処理システム。 ２．前記処理をサポートするための手段が、前記規則を定義するのに使用される アプリケーション・プログラム・インタ フェース（ＡＰＩ）呼び出しをサポートするためのＡＰＴを含み、前記サポート されたＡＰＩ呼び出しが、一のタイマをセットし且つ一のタイムアウト期間を定 義するための一の呼び出しを含むことを特徴とする、請求の範囲第１項に記載の データ処理システム。 ３．第１及び第２のアプリケーション・プログラム間で送信され且つ各々が一の メッセージ・タイプ・フィールド、一のメッセージ識別子フィールド及び一のウ ェーブ番号フィールドを有するメッセージの処理をサポートし、 前記処理をサポートするための手段が、認識可能なメッセージ・タイプのリス トへの少なくとも読み取りアクセスを有し、認識可能なメッセージ識別子のリス トへの読み取り及び書き込みアクセスを有し、ウェーブ番号のリストへの読み取 り及び書き込みアクセスを有し、 前記識別及び選択するための手段が、 一の着信メッセージの前記フィールドを検査するための手段と、 前記タイプ・フィールドを前記リストしたメッセージ・タイプと比較するとと もに、前記識別子フィールドを前記リストしたメッセージ識別子と比較すること により、当該メッセージが前記システムによって認識可能であるか否かを決定す るための手段と、 前記ウェーブ番号フィールドを前記リストしたウェーブ番号と比較することに より、当該メッセージが時間通りで且つ 順序通りであるか否かを決定するための手段と、 前記メッセージ・フィールド及び１つ以上のアプリケーション・プログラムの 状態を、メッセージ・フィールド及び／又は互いに通信中のアプリケーション・ プログラムの状態に依存して前記システムによって受信されるメッセージをどの ように処理すべきかを決定する１組の規則と比較するための手段とを含むことを 特徴とする、請求の範囲第１項又は第２項に記載のデータ処理システム。 ４．一のデータ・リンクによって相互接続された第１のノード及び第２のノード を含み、 前記第１のノードが、当該第１のノードからの一の発信メッセージに第１の識 別子を割り当てるための手段と、当該第１のノードからの発信メッセージの識別 子のリストを維持するための手段と、着信メッセージの前記識別子を検査し且つ 当該識別子を当該リストと比較することにより、前記リストした発信メッセージ に関連する着信メッセージを識別するための手段を有し、 前記第２のノードが、前記第１のノードからの一の受信メッセージに応答して 当該第２のノードから送信される一の応答メッセージに対し前記第１の識別子に 関連する第２の識別子を付加するための手段を有することを特徴とする、請求の 範囲第１項乃至第３項の何れかに記載のデータ処理システム。 ５．前記第２の識別子を付加するための手段が、前記第１のノードから送信され た前記メッセージの一のフィールドから 前記第１の識別子の値を抽出し且つ当該第１の識別子の値を当該メッセージに応 答して送信されるメッセージの一のフィールド内に挿入するための手段を含むこ とを特徴とする、請求の範囲第４項に記載のデータ処理システム。 ６．前記第１のノードに関連して設けられ、受信した着信メッセージのうち前記 発信メッセージ識別子のリスト内に関連する一の識別子が存在するような着信メ ッセージの識別子のリストを格納することにより、処理のために利用可能な応答 メッセージを識別するための手段を含むことを特徴とする、請求の範囲第４項又 は第５項に記載のデータ処理システム。 ７．アプリケーション・プログラム間で送信されるメッセージの処理をサポート するための方法であって、 各着信メッセージを検査してそのメッセージ・タイプを決定するためのステッ プと、 前記メッセージを処理すべきモジュール状アプリケーション・プログラムの特 定のアプリケーション・プログラム構成要素を選択するためのステップとを含み 、 前記選択が、入力メッセージ・タイプ及び一のメッセージに関連する動的特性 とアプリケーション・プログラム構成要素との間の予め定義された関係に従って 行われることを特徴とする、前記方法。 ８．分散システムにおけるメッセージの処理をサポートするために、 前記システムの第１のノードから送信される一の発信メッ セージに第１の識別子を割り当てるとともに、当該第１のノードにおいて当該第 １のノードから送信されたメッセージの識別子のリストを維持するステップと、 前記第１のノードからの一の受信メッセージに応答して前記システムの第２の ノードから送信される一の応答メッセージに対し前記第１の識別子に関連する第 ２の識別子を付加するステップと、 前記第１のノードに到着するメッセージの前記識別子を検査し且つ当該識別子 を前記リストと比較することにより、前記リストした発信メッセージに関連する 着信メッセージを識別するステップとを含むことを特徴とする、請求の範囲第７ 項に記載の方法。 ９．アプリケーション・プログラム間の通信をサポートするように、受信した入 力メッセージの処理をサポートするための手段を含むデータ処理システム上に搭 載され且つ記録媒体に格納されるプログラム製品であって、 前記処理をサポートするための手段が、 入力メッセージのタイプをリストするための手段と、 モジュール状アプリケーション・プログラムの別個に選択可能なアプリケーシ ョン・プログラム構成要素をリストするための手段と、 一の入力メッセージのタイプを識別するとともに、入力メッセージ・タイプ及 び一のメッセージに関連する動的特性とアプリケーション・プログラム構成要素 との間の予め定義さ れた関係に従って、前記入力メッセージを処理すべき１つ以上のアプリケーショ ン・プログラム構成要素を選択するための手段を含むことを特徴とする、前記プ ログラム製品。 １０．アプリケーション・プログラム間の通信をサポートするための機構を有し 、受信した入力メッセージの処理をサポートするための手段を含むようにしたデ ータ処理システムであって、 前記処理をサポートするための手段が、 サポートされる第１のアプリケーション・プログラムから送信される一の要求 メッセージに対し一の参照番号を割り当てるとともに、当該参照番号を予期応答 メッセージの参照番号として記録するための手段と、 受信した応答メッセージの参照番号のうち最高の参照番号を記録及び更新する ための手段と、 前記第１のアプリケーション・プログラム内でウォータシェッドに到達するた びに、前記記録した予期応答メッセージの参照番号を新しく割り当てた一の参照 番号で更新するための手段と、 前記処理をサポートするための手段によって受信され且つ関連する要求メッセ ージの参照番号を含んでいる応答メッセージを検査するとともに、受信した一の 応答メッセージの参照番号が前記予期応答メッセージの参照番号又は前記最高の 参照番号と一致するか否かを決定するための手段とを含むことを特徴とする、前 記データ処理システム。