JPH11510632A - コンピュータ・ネットワークにおいて通信リンクを提供する方法 - Google Patents

Abstract

(57)【要約】 種々の通信モデルの間をリンクするためのゲートウェイが提供される。サーバ・システム上にインストール可能なコンピュータ・プログラムにおいて実現されるゲートウェイは、同期通信セッションと非同期モデルの通信に基づくコンピュータ・プログラムとを必要とするコンピュータ・プログラム間の相互協調処理を容易にする。本発明は、同期的に接続されたクライアントがサーバ及び非同期通信プログラムとの対話を再開すること、複数のアプリケーションとの対話をインタリーブすること、及び長期実行アプリケーションの要求／応答の対を関連付けることを可能にする。特に、本発明は、インターネットＷＷＷサービスと汎用メッセージング・システムとの間のリンクを可能にする装置及び方法を提供する。

Description

【発明の詳細な説明】 コンピュータ・ネットワークに おいて通信リンクを提供する方法 技術分野 本発明は、ネットワークにおいてデータ通信及びデータ処理資源、又はそのど ちらかをリンクすることに関するものであり、特に、相異なる通信環境の間にリ ンクを設けることに関するものである。 背景技術 コンピュータの「ネットワーク」は、相互に情報を交換し得る任意の数のコン ピュータでよい。それらのコンピュータは、それらが情報を交換することができ るようにそれらを相互に接続するための何らかの方法（例えば、電話線又は他の 通信システムによる方法）が存在する限り、任意の構成で配列可能であって、し かも、同じ部屋に、或いは異なる国に設置可能である。複数のコンピュータが、 ネットワークを形成するように相互に接続可能であるのと同様に、複数のネット ワークが、ブリッジ及びゲートウェイとして知られたツールを通して、相互に接 続可能である。これらのツールは、１つのネットワークにおけるコンピュータが 他のネットワークにおけるコンピュータと情報を交換することを可能にする。イ ンターネットは、単独の所有者又はコントローラを持たず、しかも、大型及び小 型の公衆及び専用ネットワークを含む複数のネットワークより成るネットワーク である。それらのネットワークでは、インターネット・プロトコル・ソフトウエ アを実行するいずれの接続されたコンピュータも、セキュリティ・コントロール を受けて、そのインターネットに接続された他の任意のコンピュータと情報を交 換することができる。このような相互に接続するように取り決められたネットワ ークの複合集合体は単一の伝送媒体に依存するものではない（例えば、双方向通 信は、衛星リンク、光ファイバ中継回線、電話回線、ケーブルＴＶ線、及びロー カル無線リンクを介して生じ得るものである）。 ワールド・ワイド・ウェブ（ＷＷＷ）インターネット・サービスは、大量のネ ットワーク・アクセス可能な情報へのアクセスを提供し、しかもインターネット 接続されたコンピュータ相互間の低コスト通信を提供し得る広域情報検索機構で ある。ワールド・ワイド・ウェブに関する情報は、Andrew Ford著の「ウェブを スピンする(Spinning the Web)」と題した刊行物(International Thomson Publi shing，London 1995)、及びJohn December及びNeil Randall著の「解放されたワ ールド・ワイド・ウェブ(The World Wide Web Unleashed)」と題した刊行物(SAM S Publishing，Indianapolis 1994)において見ることができる。ＷＷＷの使用は 、それが、対話的なマルチメディア・プレゼンテーション機能と結合された融通 性、可搬性、及び使い易さを結集したものであるために、爆発的な速度で成長し つつある。ＷＷＷは、インターネットに接続されしかも適切なソフトウエア及び ハードウエア構成を有する任意のコンピュータが、インターネット上のどこかで 使用可能にされた任意のドキュメントを検索することを可能にするものである。 ＷＷＷにおける検索可能なドキュメントは、「ハイパーメディア」ドキュメント 、即ち、テキスト・ドキュメント、或いはサウンド及びイメージのような他の形 式のメディアであってもよいドキュメント、及び他のドキュメントに対するリン ク（ハイパーリンク）を有するドキュメントを含む。ＷＷＷにおけるテキスト・ ドキュメントのフォーマットは、１つのオペレーティング・システム及びハード ウエア・プラットフォーム上で作成されたドキュメントが、ウェブ・ブラウザ（ 下記参照）を有する他の任意のプラットフォーム上でユーザにより読み取り可能 であるようなＨＴＭＬ（ハイパーテキスト・マークアップ言語）における標準フ ォーマットである。イメージは、例えば、標準ＧＩＦ又はＪＰＥＧフォーマット で別々のグラフィックス・ファイルに記憶可能であり、ユーザが指定のイメージ ・ファイル及びＨＴＭＬテキストを検索するようにプロンプト指示されるように ＨＴＭＬテキストにおいて参照可能である。 ユーザは、「ウェブ・ブラウザ」又は「ウェブ・クライアント」を使用してこ の情報をアクセスする。その「ウェブ・ブラウザ」及び「ウェブ・クライアント 」は、ユーザのコン ピュータ上にインストールされたソフトウエアであり、インターネットを介して ウェブ・サーバからドキュメントをサービス提供又は検索するための機能を有す る。現在利用可能なウェブ・ブラウザは、ＩＢＭ社からの「WebExp1orer」及び ＮＣＳＡからの「Mosaic」を含む。そのようなブラウザはディレクトリ及びサー チ・ツールを含み、ＨＴＭＬ及び他のＷＷＷ標準フォーマットを理解し、ファイ ルをこれらのフォーマットで正しく表示又は出力することができる。これらのウ ェブ・ブラウザのユーザ・インターフェースはグラフィカル「ポイント・アンド ・クリック」インターフェースである（即ち、グラフィカル・ディスプレイを横 切ってカーソルを移動させ、しかる後にマウス・ボタンを押すことによってアイ テムを選択することができる）。ＷＷＷは、各々が特定のユニフォーム・リソー ス・ロケータ（又は，ＵＲＬ）を有するページ又はファイルとして構成される。 ＵＲＬは、サーバ・マシン及びそのマシンにおける特定のファイル又はページを 表す。ユーザは特定のＵＲＬを指定するか、又は「ハイパーリンク」によって１ つのＵＲＬから関連のＵＲＬにジャンプすることができる。即ち、ページ上のワ ード又は記号は、例えば、マウスを関連ロケーションにおいてクリックすること によって選択可能なもう１つのＵＲＬと関連付けられ、関連のページをブラウザ に検索及び表示させることができる。単一のサーバ上に多くのページが存在して もよく、関連のハイパーリンクされたページが種々のサーバ上に設けられてもよ い。 ＵＲＬが「http:」で始まる場合、これは、ファイルがハイパーリンクを含むこ とを表す。 ユーザが自分のウェブ・ブラウザを使用してウェブ・サーバ・システム上のペ ージに対するＵＲＬを選択する時、そのページに特有のアクションを遂行する単 発の要求が関連のサーバに送られる。多くの場合、サーバはその要求に応答して 、記憶されたページのデータベースからその要求されたページを検索し、ＨＴＭ Ｌページをユーザへの表示のためにインターネットを介してＷＷＷクライアント に伝送する。これは、単一の終端間同期通信セッションの範囲内で遂行される。 即ち、ブラウザはそれの要求を送り、応答を待ってからそれ以上の何らかの処理 を進行させ、又は他の要求を開始させる。ブラウザは、それがその要求された応 答を待っている間、「阻止」又は「中断」されていると云える。或る場合には、 ブラウザの要求は、ＨＴＭＬを発生するためのアプリケーションを立ち上げるよ うにサーバを導くであろうが、ブラウザは同時通信セッションに備えるものでは なく、しかもアプリケーション状態情報は要求相互間に維持されないので、ブラ ウザからの単発の要求はこの同期通信セッションの範囲内で応答を要求する。ブ ラウザによって要求されたページへのアクセスの失敗は、エラー・メッセージが ユーザの端末上に表示されることによってユーザに信号で知らされるが、サーバ が単に応答を遅らせる場合、ブラウザは無限期間にわたって中断されたままにな る。実際には、ユーザは、その遅れが通信 にとって受容し得ないものである場合、通信の試みを放棄することがある。ウェ ブ・ブラウザには、要求の自動再試行のための機能はない。 現代の企業は、その企業における他の部門との通信、及び異なる国にあること もある顧客又は納入業者のような関連企業とコミュニケートするための機能を必 要とする。ＷＷＷインターネット・サービスは、会社間の通信のための費用効果 のよい通信媒体を提供してそのような要求に対する部分的な答えを与えることが できるが、ＷＷＷインターネット・サービスの単発の要求／応答通信モデル及び ブラウザからの並列的な要求に対する備えの欠如は、要求された情報が受容可能 な期間内に得られない場合、厳しい制限を表すことがある。センダ・システムが 無期限に中断されるということは受容し得ないことであり、又、サーバ・アプリ ケーションが時間内に要求に応答するかどうかに従ってビジネス・クリティカル なアプリケーションの成功が決まるということも受容し得ないことである。ＷＷ Ｗインターネット・サービスは、多くのビジネス・クリティカルなアプリケーシ ョンの要件であるメッセージの確実な配送のための機能を提供するものではない （即ち、アプリケーションは、それが送ったメッセージが目的の宛先へ送られる 途中で失われないこと、及びそれが一度しか送られないことを知る必要がある） 。又、ビジネス・アプリケーションは多くの要求／応答の対を伴う会話に関わり 得るものであり、ウェブ・ブラウザ要求相互間で交換される 如何なるコンテキスト情報が欠如しても、同じビジネス・アプリケーションの一 部である要求を相互に関連付けるための機能が存在しないことを意味する。 同期的な時間依存の「要求及び応答待ち」モデルに対する代替えの通信モデル は非同期メッセージングである。メッセージをレシーバ・プログラムに送るプロ グラムはレシーバからの返事を待つためにブロックされる必要がなく、従って、 実行し続けることができ、センダ及びレシーバは相互に同期化（直列化）されな い。プログラム間の非同期メッセージングは、一般に、メッセージ・キューを中 間記憶機構として使用する。従って、メッセージは、それが第１プログラムから 送られた時、そのメッセージ・キューに入れられるし、レシーバ・プログラムが 作動可能である時、レシーバ・プログラムによってそのメッセージ・キューから 検索可能である。プログラム相互間には専用の論理的接続は存在しない。メッセ ージをキューに入れた後、センダ・プログラムは、ネットワークにおける他のプ ログラムにメッセージを送ることを含む他のタスクを実行するように進むことが できる。この分野では、非同期メッセージング・システムを設けることが知られ ている。その非同期メッセージング・システムは、異種のネットワークに跨るプ ログラム間通信をサポートし、アプリケーション・プログラム（それぞれが特定 のオペレーティング・システム環境に対して書かれている）が複雑なネットワー クに影響されないようにし、メッセージ・キューを維持及び 位置指定する作業がないようにするものである。種々のビジネス・アプリケーシ ョン・プログラム相互間の効果的な相互協調処理を達成することを必要とするが 、或る範囲の本質的に相違するオペレーティング・システム及びハードウエア環 境を含むデータ処理資源を有するというような多くの企業にとっては、そのよう なメッセージング・システムは重要である。 メッセージ待ち行列製品及び商業的に入手可能なメッセージ待ち行列製品は、 McGraw-Hill社発行（１９９４年）のB．Blakeley、H．Harris及びR．Lewis著の 「ＭＱＩを使用したメッセージング及びキューイング(Messaging and Queuing U sing the MQI)」において、及びＩＢＭ社から入手可能な次の刊行物、即ち、「 メッセージング及びキューイング入門(An Introduction to Messaging and Queu ing)」（ＩＢＭドキュメント番号GC33-0805-00）及び「ＭＱＳｅｒｉｅｓ−メッ セージ・キュー・インターフェース・テクニカル・リファレンス（MQSeries - M essage Queue Interface Technical Reference)」（ＩＢＭドキュメント番号SC3 3-0850-01）に記載されている。なお、ＩＢＭ及びＭＱＳｅｒｉｅｓはＩＢＭ社 の商標である。ＩＢＭ社のＭＱＳｅｒｉｅｓメッセージング・ソフトウエア製品 は、システム又は通信障害の場合でも１回の、しかも、１回だけの確実なメッセ ージ配送を行うメッセージング・プロトコルに従って作業の論理的ユニット内で メッセージを同期化するというトランザクション・メッ セージング・サポートを提供する。ＭＱＳｅｒｉｅｓ製品は、メッセージがレシ ーバ・システムによって安全に記憶されたとして確認されるまでセンダ・システ ムにおける記憶装置からそのメッセージを最終的に削除しないことによって、及 び複雑な回復機構を使用することによって確実な配送を提供する。記憶が成功し たことを確認した時にメッセージの転送をコミットする前に、センダ・システム における記憶装置からのメッセージの削除及びレシーバ・システムにおける記憶 装置への挿入の両方が「未確定」状態に保たれるし、失敗の場合には、それは原 子的にバックアウト可能である。このメッセージ伝送プロトコル並びに関連のト ランザクション概念及び回復機構は、国際特許出願ＷＯ ９５／１０８０５号及 び米国特許第５,４６５,３２８号に開示されている。 ＷＷＷインターネット・サービスのクライアント・システムのような同期通信 に適応した計算資源に非同期（オフ・ライン）処理の恩恵をもたらすことは望ま しいことであり、しかも、一般的には、既存の同期資源に対して大きな変更を必 要とすることなく、非同期モデルの通信に基づく資源及び同期モデルに基づく資 源の間の相互協調処理を可能にすることが望ましい。又、同期的に接続されたク ライアント・システムからの非同期メッセージの進行状況追跡を容易にすること も望ましい。 計算資源をインターネットにリンクすることに加えて、インターネット標準（ インターネット・プロトコル、ＨＴＭＬ の使用等）が「イントラネット」において、例えば、特定の企業におけるコンピ ュータのネットワーク（インターネットの標準に従ったネットワーク）において 有利に実現されることも企業はわかっている。今や、ブラウザ・ソフトウエアは 、イントラネット内で使用するために利用可能である。 上記の要件は、それらが種々の環境に適応するかどうか又は種々の通信モデル 又はアーキテクチャに基づくものであるかどうかに関係なく、データ処理資源の 多くのユーザがそれらの種々の資源の間で相互協調処理するための要件を例示す るものである。種々のオペレーティング・システムに対して書かれ、種々の通信 モデル又はパラダイムに基づいたアプリケーション・プログラム、並びに、種々 の通信プロトコル、データ・フォーマット、言語、又は通信のモードを使用する コンピュータ及び他の通信システムは、継ぎ目なく、しかも対話の複雑性をエン ド・ユーザが知ることもなく相互協調処理するためには益々要求される。本発明 は、種々の資源相互間にリンクを提供して相互協調処理が望ましい資源相互間の 明らかに固有の非互換性を処理するように働く。 発明の開示 本発明の第１の局面によれば、通信ネットワークのデータ通信サーバ・システ ムが提供される。その通信ネットワークでは、サーバ・システムは、そのサーバ ・システムとネットワークのクライアント・システムとの間の同期通信をサポー トするための機構を有する。又、サーバ・システムは、そのサーバ・システム上 の又はそのネットワークにおける他のシステム上のプログラム（アプリケーショ ン・プログラムのようなプログラム）との非同期通信をサポートするための機構 も有する。上記サーバ・システムは： クライアント・システムとサーバ・システムとの間の同期通信セッションにお いて前記クライアント・システムからの要求に応答して、サーバ・システムにお けるプログラム又はネットワークの他のシステムにおけるプログラムに要求（ク ライアント・システムに関連する要求）を非同期通信として送るための手段と、 前記非同期通信に対する応答の受信に応答して、前記応答をクライアント・シ ステムからの前記要求と関連付け、クライアント・システムに応答が送られるこ とを可能にするための手段と、 前記非同期通信に対する応答の受信前に仮応答を発生するための手段と、 前記非同期通信セッションにおいて前記クライアント・システムに少なくとも 仮応答を送るための手段と、 を含む。 従って、本発明によるシステムは、たとえ非同期要求に対する応答が未だ受信 されてなくても、同期通信セッションにおいてクライアントに少なくとも仮応答 を送るための手段を有する。 本発明の第２の局面は、前述のサーバ・システムの機構を使用してクライアン ト・プログラムと、サーバ・システム又はネットワークの他のシステムにおける プログラムとの間のプログラム間通信を提供する。 本発明は、たとえクライアント・システムにおけるプロセスがプログラム間通 信のための専用の同期通信セッションを必要としても、そのクライアント・シス テムにおけるプロセスが非同期通信プログラムとコミュニケートすることを可能 にする。サーバ・システム上のプログラム又はネットワークにおける他のシステ ム上のプログラムは、専用の通信セッションがなくても非同期メッセージを受信 及び送信するように適応されたアプリケーション・プログラムであってもよい。 又、初期の同期セッションにおいてクライアント・システムに送られる仮応答は 、サーバ・システムが要求を受信したことを確認するための手段を提供する。サ ーバ・システムはサーバ相互間でメッセージの確実な配送を行うサーバのネット ワークの一部であるが、同期的に接続されたクライアント・システムが、クライ アント及び接続されたサーバの間の通信ホップのための確実な配送をサポートし ない場合、要求がサーバに成功裏に到達したかどうかの追跡、即ち、通信経路の 非保証リンクに跨る通信の追跡を行うことが非常に望ましいことがある。 「仮応答」は、プリセット期間内に（例えば、システム管理者によって定義さ れた期間内に）クライアント・システム に送るための「完全応答」が得られない時に送られるだけであることが望ましい 。即ち、サーバがその要求された完全応答を未だ与えることができないようなプ リセット期間が満了した時、非同期通信のアプリケーション・プログラムから応 答が未だ受信されていない場合、サーバ・システムにおけるプロセスはクライア ント・システムに仮応答を送るためにトリガされる。その仮応答は、サーバ・シ ステムによって割り当てられ、しかもサーバ・システムにおいて独特のセッショ ン識別子を含むことが望ましい。 クライアント・システムに対する仮応答にセッション識別子を含むことは、ア プリケーション・プログラム又は他の非同期的にコミュニケートするプログラム からの期待された完全応答をタイムアウト前に受信しなかったクライアント・シ ステム（又は、クライアント・システムにおいて作業するエンド・ユーザ）が、 そのセッション識別子に関連した応答が未だ使用可能であるかどうかを決定する こと可能にする。従って、仮応答を受信したクライアントは他の処理タスクを進 めることができ、従って、セッション識別子を使用して、その後サーバとの対話 に戻ることができる。これはそうでない場合に生じる問題点、即ち、同期的に接 続されたクライアント・プロセスが応答を待つためにブロックされたままでなけ ればならないか、或いは応答が十分に早く得られない場合にアプリケーションを 放棄しなければならないという問題点を回避する。 本発明の望ましい実施例によれば、タイマの期間満了に応答してクライアント ・システムに送られた通信は、クライアント・システムにおける同期的に接続さ れたプロセスを中断されたままにしておく（即ち、現在のセッションが維持され る）べきか又はセッションが放棄されるべきかに関するクライアント・システム におけるプロセス又はユーザによる判断を促す。セッションが放棄される場合、 クライアント・プロセスはセッション識別子によって前の対話に戻ってもよい。 サーバが、同じセッション識別子を持つ前の要求に対する如何なる使用可能な応 答でも識別できるように、クライアント・システムに送られた識別子が、サーバ ・システムに送られたその後の要求に含まれてもよい。従って、タイムアウトの 後、専用の通信セッションを必要とするクライアントが、サーバに対するそれの 同期接続を維持すべきか、或いは関連の同期セッションを使用するサーバとの非 同期通信である通信に事実上変更すべきかを決定すること、或いは単にその通信 を永久的に放棄することを可能にされる。従って、クライアントは、無期限に中 断したままにするというオプション又はアプリケーションを放棄するというオプ ション以外のオプションを与えられる。 クライアントが前の対話に戻ることを可能にする他に、特定の対話に対するセ ッション識別子をクライアントに与えるということは、たとえクライアント・シ ステムにおける通信プロセスが単発の要求／応答モデルに基づくものであっても 、 クライアントが会話という多くの要求／応答の対と関連することを容易にする。 それは、クライアントが応答を待っている時にクライアントとサーバとの間のリ ンクに障害が起こることがあるという問題の処理を助ける。更に、それは、クラ イアント・プロセス又はユーザが幾つかの異なるアプリケーションとの対話を、 それらの間を区別するための手段を設けることによって、介在させることを可能 にし、しかも複数のユーザが同じアプリケーションを同時にアクセスすることを 可能にする。セッション識別子は、その後の使用のために、仮応答の受信時にク ライアント・システムによって自動的に記憶されてもよい。 「クライアント」及び「サーバ」という用語は、特定の対話において果たされ る役割を単に区別するために使用される。即ち、クライアントは要求を発生し、 サーバはその要求に応答してアクションを取る。他のコンピュータからの要求が あった時にタスクを遂行するコンピュータはいずれもサーバである。「クライア ント／サーバ」という用語は、クライアント（例えば、ワークステーション）が エンド・ユーザの対話のための機能を提供するだけであり、一方、サーバ（例え ば、メインフレーム・コンピュータ）がデータの記憶及びアクセスを行って複雑 な処理を遂行するという環境を呼ぶために、データ処理の分野において使用され ることが多い。本発明はそのような「クライアント／サーバ」環境に適用可能で あり、しかも、通信システムによって提供される機能の間にそのよ うな区別がない「対等」環境にも適用可能である。本発明は、第１システムにお けるコンピュータ・プログラムが同期通信に特に適応するという状況であって、 しかも、ウェブ・ブラウザがメッセージ・キューイング・システムを介して非同 期アプリケーション・プログラムと相互協調処理することが望ましいというよう な、そのコンピュータ・プログラムが、異なるシステムにおいて実行中の非同期 プログラム間通信に適応するアプリケーション・プログラムとコミュニケートす ることが望ましいという状況において特に価値がある。 本発明の望ましい実施例によれば、サーバがプリセット時間の経過前にそれの 非同期要求に対する応答を受信する場合、それは、サーバが同期セッションにお いて送るクライアント・システムへのそれの応答の中にその受信した応答からの 情報を含むであろう。従って、アプリケーション・プログラムとの通信の非同期 的な性質は、そのアプリケーション・プログラムからの応答が十分に速く得られ てクライアントが同期セッションにおいて完全応答を送られる場合、クライアン トにとって見えないものにされることがある。 本発明の別の実施例は、タイマの期間満了を待つことなくクライアント要求の 受信の仮確認をクライアント・システムに戻すことによって、クライアント・プ ロセスの阻止を回避する。その受信の確認は、サーバ・システムにおけるプロセ スによって割り当てられたセッション識別子（例えば、独特の参照番号）を含む 。この場合、クライアントは、それがそ の確認を受信すると、完全応答又はタイマの期間満了を待つために中断されるこ となく直ちに他のタスクを進行させてもよい。その後、アプリケーション・プロ グラムからの応答が受信される時、それはサーバにおける記憶装置に入れられ、 クライアントが、その割り当てられたセッション識別子を参照する更なる通信を サーバに送るような時間まで保持される。サーバは記憶された応答のセッション 識別子及び新しい要求を突き合わせ、しかる後、その記憶された応答をセッショ ン識別子に送る。 クライアント要求に対する応答のタイプをその要求の性質に依存させることも 本発明の技術的範囲にある。商品注文のような或る要求は、クライアント・プロ セスが中断される時間を最小にするために、割り当てられた注文番号でもって受 信を即時確認することを必要とすることがある。銀行の残高照会のような他の要 求は、そのような情報が速く得られる場合、それが単に必要とされるだけである ことが多いので、その要求された情報を供給する前にその要求の受信を確認する ことを必要としないことがある。そのような例では、クライアントが完全応答の ための所定の期間を待つことは明らかである。即時確認を送るべきか否かのこの 決定は、要求フォーム内に任意選択フィールド又はパラメータを設けることによ りそのような確認を希望することを表すための手段、及びこのフィールドにおけ るエントリに応答するための手段をエンド・ユーザに与えることによって実施さ れることが望ましい。 セッション識別子は、サーバ・システムにおけるプロセスによってクライアン ト・システムからの要求と関連付けられることが望ましく、そのプロセスは、ア プリケーション・プログラムに送られる関連の非同期要求にそのセッション識別 子を組み込む。従って、非同期サーバ要求は、初期クライアント要求からの情報 及び割り当てられた識別子を含む。その後、サーバ・システムが、このセッショ ン識別子を含む応答をアプリケーション・プログラムから受ける時、サーバはこ の応答をクライアント・システムからの要求と関連づけ、そのセッション識別子 を含む応答をクライアント・システムに送る。サーバが、複数の同期セッション を自動的にはサポートしないクライアント・プロセスとの対話にセッション識別 子を割り当てようとすることがあることに注意してほしい。セッション識別子の 交換及びクライアント・システムの記憶装置の使用は、それの戻されるセッショ ン識別子を記憶することを容易にし、これらの識別子が同時に生じたセッション を区別するために使用されることを可能にする。クライアントは、それが複数の 異なるアプリケーションを区別するための手段を有するので、それらの異なるア プリケーションとの対話をインタリーブすることを可能にされ、サーバは、非同 期メッセージに対する応答をそれぞれの要求と容易に関連付けることを可能にさ れる。アプリケーションの同時処理或いは並列処理のためのそのような対策はビ ジネス効率を非常に高めることがある。 本発明は、単発の同期通信のために設計された通信資源が非同期通信を利用す る資源を相互協調処理することを可能にする。 本発明によるシステム及び方法がクライアント・システムとアプリケーション ・プログラムとの間の対話の直列化をサポートすることは望ましいことである。 これは、クライアントに送り戻されるアプリケーション・プログラムからのメッ セージに含まれるセッション状態情報（現在の会話における対話の位置を識別す るシーケンス番号のようなもの）によって実現可能である。クライアント・シス テムからの更なる入力を必要とするアプリケーションは、それの応答におけるセ ッション状態情報によってこれを表すであろう。この情報はサーバ・システム及 びクライアント・システムの一方又は両方にとって識別可能である。セッション 識別子及びセッション状態情報によって、幾つかの連続したユーザ対話を伴うこ とのある特定のアプリケーションの関連の要求／応答の対を識別すること、及び セッションにおける通信の正しい直列的順序づけを保証することが可能である。 セッション識別子は、タイマの期間満了後にクライアントに送られる通信に、 及びクライアントとの更なる対話を期待しているアプリケーションからクライア ントに送られる応答に含まれることが望ましい。一実施例によれば、応答内にセ ッション識別情報を含むべきかどうかに関する決定がサーバ・システムにおいて 存在する。その決定プロセスは、通信ア プリケーション・プログラムから送られたセッション状態情報に応答し、しかも タイマの期間満了にも応答することが望ましい。クライアントからの更なる入力 （例えば、クライアント・システムにおけるエンド・ユーザ又はプロセスからの 入力）が期待されない場合、サーバ・システムは、クライアントに応答を送る時 にすべてのセッション特有の資源を保留解除し、セッション識別子は全く必要と されない。 この決定プロセスは、セッションが必要以上に長い期間の間維持されることに 関連する潜在的問題から見て望ましいかも知れない。第１に、セッションを維持 することは幾つものシステム資源を使用する。第２に、一連の要求／応答の対話 のうちの最後の対話において識別子情報を戻すことは、その識別情報がクライア ント・システムにおける記憶装置に無期限に残ることを必要とすることがある。 これは、セキュリティ・エクスポージャ並びにクライアント資源の使用であるか も知れない。識別子情報がいつもクライアント・システムに戻される場合（即ち 、前述の決定プロセスが実施されない場合）、上記の問題は、適当な時間後にク ライアント・システムから状態情報を削除することによって処理される。 本発明の望ましい実施例は、サーバ・システムがインターネット・ワールド・ ワイド・ウェブ（ＷＷＷ）サーバ・ソフトウエアをその上にインストールされ、 クライアント・システムが、インターネット接続されたサーバ・システムに要求 を供給するためのＷＷＷブラウザ・ソフトウエアをその上に インストールされるデータ通信システムを提供する。又、サーバ・システムは、 アプリケーション・プログラム相互間の非同期メッセージ通信をサポートするた めの機能も有する。サーバ・システムが、非同期通信用に設計されたアプリケー ション・プログラムとの対話を必要とするＨＴＭＬ要求を前記ＷＷＷクライアン ト端末（同期通信セッションにおける端末）から受ける時、サーバ・システムに おけるプロセスは、アプリケーション・プログラムの入力キューに送られるメッ セージとして、その要求をアプリケーション・プログラムに送る。アプリケーシ ョン・プログラムがＨＴＭＬを解釈し得ない場合、サーバにおけるプロセスは、 その受信したＨＴＭＬ要求を、アプリケーション・プログラムにとって認識可能 なメッセージ・フォーマットに変換し、しかる後、その変換されたメッセージを 送る。プリセット期間の満了前にアプリケーション・プログラムから応答メッセ ージを受信したことに応答して、サーバ・システムにおけるプロセスは（必要な 場合には）その応答メッセージをＨＴＭＬに逆変換し、その作成されたＨＴＭＬ ページをクライアント端末に応答として送る。ＷＷＷクライアントの視点から、 その応答がタイムアウト期間の経過前に得られる場合、その応答はオリジナル同 期通信セッション内である。 サーバ・システムは、前記クライアント・システムに送られた応答に含まれる ＨＴＭＬページ内にセッション識別情報を組み込むための手段を含む。サーバ・ システムは、非同期 要求に対するアプリケーション・プログラムの応答に含まれたセッション状態情 報に応答してエンド・ユーザによる終了のための１つ又は複数のＨＴＭＬフォー ムをＨＴＭＬページに含むための手段を有することが望ましい。セッション状態 情報もＨＴＭＬページに組み込み可能である。 サーバは、アプリケーション・プログラムから応答メッセージを受け取る前に プリセット期間が満了したことに応答して、ＷＷＷクライアント端末に通信（即 ち、ＨＴＭＬのページ）を送る。この通信はセッション識別子及び、望ましくは 、セッション状態の識別子を含む。クライアントに返送された通信はそれの同期 ＨＴＴＰセッションを終了させ、ＷＷＷクライアントは最早中断されないが、ゲ ートウェイを有するクライアントの長い実行中の通信「セッション」は、ＷＷＷ クライアント及びゲートウェイ・プログラムの間の対話の再開を可能にする情報 が保持されるという点で論理的には依然として存在している。エンド・ユーザは 、更なる期間のためにその中断状態に再入して新たな同期セッションを始動させ るべきか否かを決定することができる。セッション識別子及び状態情報は、ＷＷ ＷページをキャッシュするためのＷＷＷクライアントの機能を使用してＷＷＷク ライアント・システムのキャッシュ・メモリに記憶される。ＷＷＷクライアント は、このキャッシュされた情報を使用して初期の対話を再開し、アプリケーショ ン・プログラムからの応答メッセージがサーバにおいて得られるかどうかをその 後の或る時点でチェック することができる。オリジナル・セッションと関連するサーバへのその後の要求 にセッション識別子及びセッション状態情報を含むことによって、クライアント は、サーバが種々のセッション相互間を、及び同じアプリケーションの一部であ る種々の要求相互間を区別することを可能にする。 上述の本発明の実施例は、既知の手法に従ってＨＴＭＬメッセージ・フォーマ ットから非ＨＴＭＬメッセージ・フォーマットへの変換を行う。呼び出されるべ きアプリケーションがＨＴＭＬを解釈することができる場合、そのような変換は 明らかに必要ない。 従って、望ましい実施例における本発明は、ＷＷＷの同期環境及びメッセージ ・システムの非同期環境の間のリンクを提供する。本発明は、インターネットの サーバ・システムを介してアプリケーション・プログラムをコミュニケートする ためのブラウザ・ソフトウエアの使用に同様に適用可能である。 図面の簡単な説明 第１図は、インターネットを介したクライアント・システムとサーバ・システ ムとの間の通信の概略的表示である。 第２図は、非同期メッセージング及びキューイングを使用したプログラム間通 信の概略的表示である。 第３図は、本発明の実施例に従って、非同期的に接続されたウェブ・ブラウザ と非同期通信に適応したアプリケーショ ン・プログラムとの間の対話のためにサーバ・システム上にインストールされた ゲートウェイ・プログラムを示す。 第４図は、本発明の第２実施例に従ってゲートウェイ、ブラウザ、及びアプリ ケーション・プログラムの間の相互協調処理を示す。 第５図は、本発明の実施例に従って、要求がウェブ・ブラウザ・プログラムか ら送られる時、主としてサーバ・システムにおけるゲートウェイ・プログラムに よって遂行されるオペレーションを示す流れ図である。 発明を実施するための最良の形態 本発明は、種々の環境の間のリンクを必要とする多くの異なるデータ処理シス テム及び通信システムにおいて実現可能である。本発明は、特定のコンピュータ ・ハードウエア又はオペレーティング・システム、或いは特定のタイプの通信リ ンクに限定されるものではなく、ハードウエア又はソフトウエアにおいて、又は ハードウエア及びソフトウエア・コンポーネントの結合として実現可能である。 本発明の望ましい実施例は、非同期メッセージング及びキューイング環境と、 ワールド・ワイド・ウェブの同期環境との間のリンクを提供するサーバ・システ ムのソフトウエア実装コンポーネントを含む。 第１図に示されるように、及び上で説明したように、インターネットのエンド ・ユーザは、インターネット・アクセス を有するコンピュータ１０及びそのコンピュータ上にインストールされたウェブ ・ブラウザ・ソフトウエア２０を具備している。ウェブ・サーバ・システム３０ は、インターネットに接続され、ウェブ・サーバ・ソフトウエア４０（ＩＢＭイ ンターネット接続サーバのようなソフトウエア）を走らせるコンピュータ・シス テムより成る（そのシステムは、例えば、Ｗｉｎｄｏｗｓ ＮＴオペレーティン グ・システム・ソフトウエア又はＵＮＩＸオペレーティング・システム・ソフト ウエアを走らせるものでよく、或いは、ＯＳ／２オペレーティング・システム・ ソフトウエアを走らせるＩＢＭ ＰＳ／２ Ｍｏｄｅｌ ８０ コンピュータ、 又はＩＢＭのＭＶＳオペレーティング・システムをサポートするメインフレーム ・システムであってもよい）。なお、ＯＳ／２、ＭＶＳ、及びＰＳ／２はＩＢＭ 社の商標である。ウェブ・サーバ・ソフトウエアはウェブ・ブラウザからのＨＴ ＴＰ（ハイパーテキスト転送プロトコル）要求をサービスし、それらを静的ＨＴ ＭＬページに対する要求として、又は実行可能なプログラムに対する要求として 分析し、使用可能なＨＴＭＬページ（例えば、ディスク記憶装置に保持されたＨ ＴＭＬページ）をウェブ・ブラウザに送ることによって、或いはウェブ・サーバ ・システム上で又は異なるシステム上で走らせてＨＴＭＬを発生させるためにプ ログラム５０を呼び出すことによって応答する。プログラムは、共通ゲートウェ イ・インターフェース（ＣＧＩ）６０又はウェブ・サーバによって実現される他 の インターフェースを介してウェブ・サーバにより呼び出される（ほとんどのウェ ブ・サーバは２つのインターフェースをサポートし、そのうちの１つがＣＧＩで ある）。 第２図は、ＩＢＭのＭＱＳｅｒｉｅｓプログラムのようなキュー・マネージャ ・プログラムのネットワークの制御の下に非同期メッセージング及びキューイン グを使用するプログラム間通信の簡略化した概略図である。キュー・マネージャ は、アプリケーションによって使用されるメッセージ・キューイング機能を提供 するシステム・サービスである。第２図に示されるように、システム１１０にお ける第１アプリケーション・プログラム１００は、ローカル・キュー・マネージ ャ・プログラム１２０及びリモート・システム１６０上で走る通信キュー・マネ ージャ１３０の制御の下でキュー１４０上にメッセージを入れるためのコマンド を発生する。その後、サービング・アプリケーション・プログラム１５０は、そ れがメッセージを処理する準備のできた時にキュー１４０からメッセージを取り 出す。ビジネス・アプリケーションは、例えば、銀行の口座振替、又は航空機座 席予約アプリケーションでよい。メッセージ・キューは、メッセージが蓄積され る及びメッセージが後で取り出される名前付きオブジェクトである。 特定のキューの保全は、或る特定のキュー・マネージャの責任である。メッセ ージ・キューは単なるスタックではない。メッセージがキューに加えられる時、 それらは最後尾に加え られる。メッセージがキューから取り出される時、それらは、通常、前から取り 出される。メッセージ・キューの物理的表示は環境に依存するが、主記憶装置に おける１つ又は複数のバッファ、ディスク又は他の永続記憶装置における１つ又 は複数のファイル、又はこれらの両方であってもよい。メッセージ・キューの物 理的管理は全くキュー・マネージャ・プログラムの責任であり、そのような詳細 はアプリケーション・プログラムにとって明らかにされない。アプリケーション は、単に、メッセージが蓄積される「ブラック・ボックス」として、メッセージ ・キューを見なすことができる。アプリケーションは、メッセージ・キューイン グＡＰＩコールを使用することによってメッセージ・キューへのアクセスを行い 、そのアプリケーションと同じシステム上にインストールされるキュー・マネー ジャ（即ち、ローカル・キュー・マネージャ）とコミュニケートする アプリケーション・プログラムは、特定の名前付きメッセージ・キュー使用す ることに同意することによってコミュニケートし、アプリケーション・プログラ ムが読み取ることを同意した特定のターゲット・キューにメッセージを送る。こ れらのキューのロケーションは、それらのメッセージを送るアプリケーションに とって可視的である必要はない。各ロケーションはそれのローカル・キュー・マ ネージャとのみ対話し、意図されたキューにそれらのメッセージを移動させる責 任のあるのは相互接続されたキュー・マネージャのネットワ ークである。各キュー・マネージャは、ネットワークにおける他のキュー・マネ ージャを位置指定するためのローカル・ルーティング・テーブルを保全する。こ の方法では、アプリケーション・サポートのメッセージ・キューイング・ソフト ウエアは、アプリケーション・プログラムに関する必要な複雑さのレベルを単純 化し、それらがそれら自身の複雑な通信制御機能を実現する必要はないものにす る。 本発明は、ローカル・システム上にインストールされたキュー・マネージャ・ プログラムを持たないユーザに、相互接続されたキュー・マネージャのそのよう なネットワークへのアクセスを提供する。本発明は、ＩＢＭのＭＱＳｅｒｉｅｓ 製品のような既存のアプリケーション・イネーブリング・ミドルウエア・プログ ラムのサービスから利益を受け得る複雑な信頼性のあるＷＷＷアプリケーション の開発のための環境を提供する。 ソフトウエアで実現されるリンク・コンポーネントは、同期的に接続されたエ ンド・ユーザの代わりにメッセージを発生及び受信するためにＷＷＷサーバにお けるインストレーションを与えられる。以後、ゲートウェイ・プログラムと呼ば れるこのリンク・コンポーネントは前述のようにウェブ・ブラウザからの要求に よって呼び出される。ゲートウェイ・プログラムは、例えば、標準ＣＧＩ（共通 ゲートウェイ・インターフェース）を介してＷＷＷサーバとインターフェースす る。ゲートウェイ・プログラムは、後述するように、複数の コンカレント・ユーザ及びそれらのステータスの管理を可能にし、同期ＨＴＴＰ 及び非同期メッセージの間の相違を管理して、同期的に接続されたウェブ・ブラ ウザに、それがそのブラウザに代わって発生する非同期メッセージの進行に関す る情報を提供する。又、ゲートウェイ・プログラムは、保証付き配送メッセージ ング・システムと非保証付きＨＴＴＰ通信との間のリンクも管理する。アーキテ クチャ及びハードウエア・プラットフォームが異なるとデータ表示及びパラメー タも異なるので、データ変換（ＡＳＣＩＩ対ＥＢＣＤＩＣのような）が必要であ るけれども、そのような変換はその分野では知られており、既知のメッセージン グ・ソフトウエア製品は変換を処理するので、ゲートウェイ・プログラムによっ て実現される必要はない。広範囲のセキュリティ機能は既知のメッセージング・ ソフトウエア及びＷＷＷサーバ（ＩＢＭ社のセキュア・インターネット・サーバ のような）において実現されているので、ゲートウェイ・プログラムがそのよう な機能を提供する必要もない。 第３図は、コンピュータ・システム２３０上にインストールされたメッセージ ・キュー・マネージャ・プログラム２１０及びウェブ・サーバ・プログラム２２ ０の間をインターフェースするゲートウェイ・プログラム２００を示す。そのゲ ートウェイ・プログラムは、この例において示されるように、サーバ・システム ２３０以外の機械上でも動作し得るメッセージ・キューイング・アプリケーショ ン・プログラム２４０ とウェブ・サーバとの間をインターフェースするためにも使用可能である。この 場合、サーバ・システムにおけるアプリケーション・プログラムは必要ない。メ ッセージ・キューイング・アプリケーションが走っているシステムは、インター ネットを介して又は他の通信ネットワークを介してサーバ・システムに接続可能 である。この例のアプリケーション・プログラムは、ウェブ・ブラウザ２５０か らのＨＴＭＬフォーム・データを解釈することができ、それに応答してＨＴＭＬ ページを発生することができる。 第４図には、ウェブ・サーバ・システム上にインストールされたフォーマット 変換アプリケーション・コンポーネント２６０と関連したゲートウェイ・・プロ グラムの同様の使用が示される。その変換コンポーネントはウェブ・ブラウザの ＨＴＭＬ要求及び応答と、ＨＴＭＬを解釈することができないアプリケーション ・プログラム２７０の内部メッセージ構造との間で変換するように働く。従って 、この変換コンポーネント２６０は、本発明によるゲートウェイ・プログラム２ ００’が既存のメッセージキューイング・アプリケーションと共に使用されるこ とを可能にする。サーバ・コンポーネントは、幾つものターゲット・アプリケー ションに対する要求及びウェブ・ブラウザに対する応答を単一の作業単位におい て調整することもできる。ＨＴＭＬ変換はその分野においてよく知られており、 従って、ここでは更にこれを説明しないことにする。 第５図を参照して、ゲートウェイ・プログラム、及びウェブ・ブラウザと非同 期アプリケーション・プログラムとの間の通信フローを説明することにする。ゲ ートウェイ・プログラムと関連する各メッセージ・キューイング・アプリケーシ ョン・プログラムに対して、１つ又は複数のアプリケーション入力キューが定義 される。このアプリケーション及びそれの入力キーは、ウェブ・サーバ・マシン 上に設けられるか又はメッセージ・キューイング・ミドルウエアのサポートを使 用してサーバとの通信のために接続される任意のマシン上に設けられてもよい。 ゲートウェイはサーバ上に応答キューを設けられ、アプリケーション・プログラ ムから送られたメッセージをローカル・キュー・マネージャ・プログラムによっ て管理される。 ユーザは、それらが使用したいメッセージ・キューイング・アプリケーション 又はサービスの名前を表すＨＴＭＬフィル・イン・フォームＧＥＴ又はＰＯＳＴ 要求３００を介してゲートウェイ・プログラムと対話する（ステップ３００）。 本発明の望ましい実施例では、その名前はアプリケーション・キュー・ネームを 含むが、別の実施例では、これはアプリケーション・ネームに基づいてゲートウ ェイ・プログラムから取り出される。 ユーザがアプリケーションを呼び出すコマンドの例は次のようになる： <form method="post" action"/mig-bin/migcgi/ MQApp"> メッセージ・キューイング・システムを指定すると： <input type="input"； name="QMName"； size="48"； max length="48"> 及びアプリケーション： <input type="input"； name="QName"； size="48"； max length="48"> <input type="submit"； value="Click here to start the application"> </form> ONameは発生された非同期メッセージに対する宛先を指定するために必要であ り、通常、アプリケーション自身によって識別される。QMNameは任意選択的なも のである。それは、指定された場合、メッセージに対する宛先を指定するために ONameと共に使用される。それが指定されない場合、ブランク・ネームが使用さ れる。標準のメッセージング・システム・ネーム・リゾリューション規則が適用 可能である。アプリケーション特有の文字フォーマット・データを含む更なるフ ィールドをフォーム要求に含めることが可能である。これらのフィールドは、ゲ ートウェイによって提供されたメッセージにおけるアプリケーションに送られる 。 ユーザが行うアプリケーション・プログラム（アプリケーション”エントリ・ ポイント”）との第１の対話は、一般に、静的ＨＴＭＬウェブ・ページから到来 する。ユーザは特定の ＵＲＬを参照解除するか、又はゲートウェイ・プログラムと対話するＨＴＭＬフ ォームを提供する（ステップ３００）。ブラウザの初期ＨＴＭＬ要求は組込のセ ッション識別子を含まない。ユーザがそのようなエントリ・ポイントを最初に通 過し（即ち、既に存在するセッションに属しないＨＴＭＬ要求が送られ）、アプ リケーションを開始する時、ゲートウェイ・プログラムは、そのゲートウェイ内 の独特のセッション識別子によって識別されたセッションを構成して（ステップ ３４０）ユーザ要求のアプリケーションとその要求のインスタンスとの結合を表 す。セッション識別子は、各識別子がネットワーク全体に対して独特であること を保証するに十分なランダムネスをもって及び独特のサーバ識別を使用して発生 可能であるが、これは本質的なことではない。既存のメッセージ・キュー・マネ ージャ・プログラム（ＩＢＭ社のＭＱＳｅｒｉｅｓプログラムのようなプログラ ム）は独特の識別子を発生するための機能を有し、望ましい実施例のゲートウェ イ・プログラムはこの機能を利用する。 ゲートウェイは、クライアント・システム又はユーザ識別情報と共にセッショ ン識別情報をセッション・テーブル（例えば、ＯＳ／２又はＡＩＸオペレーティ ング・システム・プログラムを走らせるサーバ・システムのクロス処理された共 用メモリに保持されるメッセージ・キューにおけるエントリとして実現される） に加える（ステップ３５０）。なお、ＯＳ／２及びＡＩＸはＩＢＭ社の商標であ る。このテーブルは、 その後、後述のように、セッション識別子をユーザ要求及びアプリケーション・ プログラム応答と関連付けるために使用される。この方法でアプリケーション・ エントリ・ポイントを通過することによる以外にアプリケーションを開始させる 手段はない。ユーザ対話は、わずか１つのセッションに属し得るだけである。 セッション識別子をユーザの対話に割り当ててしまうと、ゲートウェイ・プロ グラムはアプリケーション・プログラムの定義した入力キュー上にメッセージを 入れ（ステップ３６０）、タイマを始動し（ステップ３７０）、アプリケーショ ン・プログラムから応答メッセージを受けるためのプロセスを開始させる（ステ ップ３７０）。応答の受信に関しては後で説明することにする。メッセージは、 要求したクライアント・プロセスとアプリケーション・プログラムとの間の通信 全体におけるこの対話の位置を識別するシーケンス番号の形でステータス情報を 含み、ユーザ又はクライアント・システムの識別子、並びにウェブ・ブラウザか ら供給された入力データを含む。このデータは、適切な文字セット及びコード・ ページとしてアプリケーションに与えられる（その場合、前述のように、ゲート ウェイ・プログラムとは別のサーバ・システム上のプロセスによって変換が遂行 される）。メッセージのターゲットは、長時間動作のメッセージ・キューイング ・アプリケーションであってもよく、又はそれの到着は、メッセージ・キューイ ング・アプリケーションをトリガして開 始させるために使用可能である。上で説明したように、本発明は、「ウェブ認識 」の（即ち、ＨＴＭＬページを理解し、発生することができる）アプリケーショ ン及びＨＴＭＬ変換を必要とするアプリケーションと共に使用するように実施可 能である。本発明の実施例に関する以下の説明は、ウェブ認識アプリケーション との対話の例に関するものである。 メッセージ・キューイング・アプリケーションは、受信したメッセージに応答 してＨＴＭＬページをゲートウェイ・プログラムの応答キューに送らなければな らない。前述のように、ゲートウェイ・プログラムは、これらの応答をそれのキ ューから取り出すためのプロセスを、それを受信した時に既に呼び出している。 これは、相互協調処理メッセージ・キューイング・プログラムの既知の機能を使 用して実施され、それによって、メッセージをキューから得るためのコマンドは 、Ｇｅｔオペレーションが最初に試みられる時に応答が直ちには得られない場合 、指定された期間を待つためのコマンドを任意選択的に含むことができる。ＩＢ Ｍ社のＭＱＳｅｒｉｅｓキュー・マネージャ製品では、この機能は、前に引用し た文献「ＭＱＳｅｒｉｅｓ−メッセージ・キュー・インターフェース・テクニカ ル・リファレンス」（ＩＢＭドキュメント番号ＳＣ−３３−０８５０−０１）に 開示されているように、メッセージＡＰＩ取得（Get Message API）コマンドで ある「MQGET_Wait」に関するオプションとして呼び出される。従って、ゲートウ ェイ・プログラムはメッセージを送り、応答メ ッセージを検索するためにコマンドを発生し（ステップ３７０）、応答キューか らＨＴＭＬページを検索してそれをゲートウェイに送る実際のメッセージ取得（ Get Message）オペレーションを制御する状態にキュー・マネージャ・プログラ ムをしておく（ステップ４２０）。そこで、ゲートウェイ・プログラムは、現在 のセッション識別子をＨＴＭＬにおける隠蔽フィールドとして含むＨＴＭＬペー ジをブラウザに伝送する（ステップ４２０）。 応答メッセージがゲートウェイ・プログラムによって得られる前に「メッセー ジ取得」オペレーションの待機インターバルが期間満了する場合、「メッセージ 取得」が戻り、ゲートウェイ・プログラムが反応して仮応答メッセージをブラウ ザに送る（ステップ３９０、４００）。この仮応答は同期セッションを終了させ るが、それはセッション識別子を含むので、セッションは後で「再始動」可能で ある（厳密には、新たなセッションが始動されるが、これは同じブラウザ及びゲ ートウェイ・プログラムの間の対話を必要とし、同じセッション識別子を参照す るので、それをオリジナル・セッションの再始動と見ることができる）。応答が 受信される前に、ＷＷＷブラウザとゲートウェイ接続されたＷＷＷサーバ・プロ グラムとの間の同期セッションが別の方法で放棄される場合、ゲートウェイはす べての疑わしい「メッセージ取得」オペレーションを取り消す。タイムアウト後 又はセッションの別の放棄後にゲートウェイ・プログラムの応答キュー上に入れ ら れた如何なる応答メッセージも、ＷＷＷブラウザが関連の応答メッセージのサー チにおいてゲートウェイと再び対話するような時間まで、そこに残るであろう。 そのようなその後のＷＷＷブラウザ要求が受信される時、ゲートウェイ・プログ ラムは「メッセージ取得」オペレーションを（待機インターバルの時）再び呼び 出すであろう。 そのセッション内にクライアントに送られたすべての通信はセッション識別子 を含む必要があるということではないが、更なるクライアント対話が期待される 時には、その識別子が含まれる。これは、一般的には、タイムアウト後に、又は アプリケーションの応答が得られる前に、通信が送られる時（ステップ４００） 、或いは、アプリケーション応答が受信され、その含まれたセッション状態情報 が更なるクライアント対話の可能性を確認する時のような場合である。ゲートウ ェイ・プログラムは、一般に、アプリケーション・プログラムからの応答が受信 された時、関連のセッションに対するセッション状態情報でもってそれのセッシ ョン・テーブルを更新する（ステップ４２０）。しかし、アプリケーションがク ライアント・システムにおけるユーザ又はプロセスからのそれ以上の対話を必要 としない場合（セッション状態情報によって、又はアプリケーション・プログラ ムからの応答におけるそれの欠如によって表されるように）、ゲートウェイ・プ ログラムは、それがページをブラウザに送る時、すべてのセッション特有の資源 を保留解除する（ステップ４２０）。 現在のアプリケーション・プログラムが更なるクライアント情報を「期待し」 又は必要とす時（即ち、アプリケーション全体が終了する前に現在のアプリケー ション・プログラム又は他のアプリケーション・プログラムと対話することをク ライアントが期待している時）、それは、サーバに対するそれの応答におけるフ ラッグによってこれを表す。それは、動的に作成されたＨＴＭＬフォームの各々 に組み込まれたセッション識別子と共にクライアントに送られるＨＴＭＬページ 内に更なるＨＴＭＬフォームも含む。 ウェブ・ブラウザはページをキャッシュするための機能を有し（ステップ４１ ０）、従って、組み込まれたセッション識別子を記憶することができる。これは 、単一のユーザが複数のオープン・セッションを持つことを可能にする。これら のセッションはネスト可能であり、或いは相互にオーバラップ可能である。セッ ション識別子を含むフォームがブラウザにおいて実質的に満たされる時（ステッ プ３００）、サーバにおけるゲートウェイ・プログラムがその後受信したフォー ムを正しいセッションと関連付けることができるように（ステップ３２０、３３ ０）、セッション識別子はサーバにおけるゲートウェイ・プログラムに戻るであ ろう。セッション識別子はその要求を他のユーザからの他の要求から区別するた めに、及び異なるアプリケーションに対する同じユーザからの他の要求から区別 するために使用される。ゲートウェイ・プログラムの一部であるプロセスが、テ ーブル・エントリと、 受信した要求のセッション識別子及びセッション状態情報との間の対応を求めて セッション・テーブルをスキャンする（ステップ３２０）。セッション及びステ ータス情報がアプリケーションとの既存の対話に対応しない場合、ゲートウェイ は、前述のように、ステータス情報及び入力データをアプリケーション入力キュ ーにおけるメッセージとして扱う（ステップ３６０）。しかし、受信した要求の セッション及び状態情報とセッション・テーブルにおけるエントリとの比較で一 致が見つかった場合、これは初期の要求の再試行でなければならず、従って、応 答は既に得られているかもしれない。前に送られたメッセージの確実な１回だけ の配送を行うためには関連のキュー・マネージャに依存することになるので、新 しいメッセージがアプリケーションに送られる必要はない。ゲートウェイ・プロ グラムは、期待された応答メッセージに関してそれの応答キューをチェックする ために、「待機を伴う取得（Get with Wait）」オペレーションを呼び出す（ス テップ３７０）。 ブラウザに戻されそしてそこに記憶されるセッション識別子をユーザ対話に割 り当てることは、多くの技術的問題を解決するものである。第１に、それは、ゲ ートウェイが受信する複数の応答をそのゲートウェイが区別することができる場 合、複数のユーザが同時に同じアプリケーション又はサービスをアクセスするこ とを可能にする。第２に、それは、アプリケーションの長期実行の会話に関する 複数の要求応答の対 を一緒に関連付けるために、十分なコンテキスト情報が、各ユーザによって各サ ーバ・アプリケーションに対して発生される連続した要求の間で持ち越されるこ とを保証する。第３に、それは、幾つもの異なるアプリケーションとの対話を区 別するための機構を設けることによって、ユーザがそれらの対話をインターリー ブすることを可能にする。第４に、それは、恐らく、サーバ又はゲートウェイ・ プログラムに如何なる通知も与えることなく、ユーザが任意の段階でアプリケー ションを放棄する可能性を与え、ユーザ及びサーバの間のリンクの可能性を処理 する。 動的に作成されたＨＴＭＬは、セッション識別子を含む他に、現在のセッショ ンにおける対話の位置を識別するシーケンス番号を含む。これは次のブラウザ要 求によってゲートウェイ・プログラムに戻され、ゲートウェイ・プログラムは期 待された値に対比してそれをチェックするであろう（ステップ３２０）。表にさ れたセッション識別子及びシーケンス番号を使用してデータ及び実行ステータス ・コンテキストを維持するこの機構は、相互に依存したクライアント要求のシー ケンスの遂行を可能にする。同じセッション内の複数のメッセージ相互間を区別 するために、サービング・アプリケーションが可能にされる。 次のような方法の１つでセッションを終了させることが可能である： ○ 要求される更なるユーザ入力がないことをサーバ・アプ リケーションがそれの応答メッセージにおいて表示し、ゲートウェイが、セッシ ョン特有の資源を保留解除することによって応答する（ステップ４２０）。 ○ フォームを含むＨＴＭＬページがユーザに送られるが、フィル・インされず 、アドミニストレータ定義の期間内に戻される。ユーザからの応答を期待してい たサービング・アプリケーションにゲートウェイが終了メッセージを送る（終了 していないサービング・アプリケーションの不必要な保全を回避する）。 ○ サービング・アプリケーションが受容可能な時間内にメッセージに応答しよ うとしない時、ユーザがゲートウェイ・プログラムとの会話を通してアプリケー ションを放棄することを選ぶ。ゲートウェイ・プログラムは、それが送ったメッ セージを検索しようとする。それができない場合、それは取消メッセージをサー ビング・アプリケーション・プログラムに送る。 セッション終了は、ゲートウェイ・プログラム及びサービング・アプリケーシ ョンが割り振ったすべてのセッション特有の資源をそれらが保留解除することを 可能にする。セッション識別子は、セッションが終了した後、それがユーザ又は サービング・アプリケーションからゲートウェイ・プログラムに送られる場合、 拒絶されるであろう（即ち、拒絶通知以外の更なる通信をトリガしないであろう ）。サーバ制御されたタイムアウト期間は、クライアント・プロセスが中断され たままになっている期間を決定するが、セッションを自動的には終了させないこ とに注意してほしい。従って、そのようなタイムアウトの後、ゲートウェイ・プ ログラムは、依然として、セッション識別子及びステータス情報を維持する。 ゲートウェイ・プログラムからのメッセージがアプリケーション入力キューに 配送されこと、及び応答がゲートウェイ・プログラムに戻されることを保証する ための機能を有するメッセージ・キュー・マネージャ・プログラムが知られてい る。しかし、メッセージ・キュー・マネージャ・プログラムは、通信リンクが特 定の時間に機能していること及びアプリケーションそのものがブラウザからの要 求を処理するために走ることを保証することはできない。キュー・マネージャ・ プログラムは、キュー・マネージャのネットワークに接続するウェブ・ブラウザ に確実な配送を提供することができない。前述のように、ゲートウェイ・プログ ラムは、到来するウェブ・ブラウザ要求に応答してサーバ・アプリケーションの 入力キュー上にメッセージを送る。メッセージが最初にそのキュー上に入れられ る時、ゲートウェイ・プログラムはカウント・ダウン・タイマを始動させ（ステ ップ３７０）、サーバ・アプリケーションからの応答を待つ。アプリケーション ・プログラムからのいずれの応答が受信される前にもタイマが期間満了した場合 、ゲートウェイ・プログラムはＨＴＭＬページを作成して（ステップ３９０）、 その期間満了をユーザに通知する（ステップ４００）。 従って、ゲートウェイ・プログラムは、システム・アドミニストレータ定義の 期間満了前にそれがアプリケーションからの応答を受けなかった場合、それ自身 の応答をブラウザに送るように構成される。設定されるべき最大のクライアント 中断期間は関連のアプリケーションに依存するであろう（１０秒又は１秒が適当 であろう）。この応答の主たる目的は、現在の通信セッションを維持して応答を 待つべきか、又はセッションを停止して（しかし、そのセッションと関連した情 報を保全して）他の作業を進めるべきかの決定を可能にするための情報をクライ アント・システムにおけるユーザ又は通信プロセスに提供することである。クラ イアントに対するこの応答は単にエンド・ユーザへのプロンプト指示であっても よいが、本発明の望ましい実施例のよれば、ブラウザに対するタイマ・トリガさ れた応答は、要求がターゲット・マシンによって受信されたかどうか及びアプリ ケーションが要求を読み取ったかどうかも表示する。到着時の確認（Confirm On Arrival）及び配送時の確認（Confirm On Delivery）のレポートを行うメッセ ージ・キュー・マネージャ・プログラムが知られている。望ましい実施例による ゲートウェイ・プログラムは、それのタイマ期間満了通知がそのセッションに対 する通信の進行に関して得られた情報すべてを含むように、利用可能なレポート 機能を使用してその通知を構成すべく適応する。 ゲートウェイがクライアント・システムから要求を受信し たということの即時確認として仮応答を行うことは本発明の技術的範囲内である 。この確認は、現在の同期セッションを終了させるであろうが、セッション識別 子を含むであろうし、従って、クライアントが後でその対話を再開することを可 能にする。この場合、クライアント・プロセスは非同期的に要求されたプログラ ムからの応答を待つために中断されないであろうけれども、通信リンク又はコミ ュニケートするシステム自体による問題のために、要求と受信の確認との間の遅 れの可能性が残っている。確認が受信されるものではない場合、クライアント要 求が放棄されなければならない時を自動化するためにクライアントのタイムアウ ト期間が使用されてもよいが、或るアプリケーションにとっては、クライアント 要求を放棄すべき時の決定は、既存のウェブ・ブラウザ・ソフトウエアのユーザ にとっては馴染み深いものであるとしてエンド・ユーザに決定させることが可能 である。 クライアント・システムからの受信した要求の「タイプ」に応答して即時仮応 答が必要であるかどうかを、或いは、完全応答が得られる場合、セットされた中 断又はタイムアウト期間がその期間内に完全応答を供給する目的で使用されるべ きかどうかを決定するプロセスをゲートウェイ・プログラム内に設けることも、 本発明の技術的範囲である。本発明の特定の実施例によれば、ゲートウェイ・プ ログラムは、それがデフォルトによって使用する構成可能なタイムアウト値を有 する。この値は、ゲートウェイ・プログラムがインストール されるサーバ・システム上の構成ファイルに保持され、ゲートウェイ・プログラ ムがインストールされる時にセット可能であり、その後、システム・アドミニス トレータによって修正可能である。このデフォルト値をオーバライドする任意選 択のパラメータがＨＴＭＬフォーム要求（QName及びQMNameパラメータと同様の もの）に含まれてもよい。前に参照した例を使用すると、要求の受信を確認する 即時応答を必要とする商品注文に適するようにＨＴＭＬフォームを設計する場合 、小さいタイムアウト値がその要求フォームにおいてコード化されるであろう。 一方、そのような即時確認を必要としない銀行残高に関する情報を要求する場合 、大きい値（恐らく、ユーザが許容することを期待される最長の待ち期間に対応 した値）がコード化されるであろう。 メッセージの確実な配送を行うためのメッセージ伝送プロトコルは、国際特許 出願ＷＯ ９５／１０８０５及び英国特許出願番号９６０６１８３.３の未決出 願に開示されている。一般に、基本ネットワーク・サポートは、信頼性の低い通 信媒体を介した機械相互間における信頼し得るパケット配送を保証するけれども 、それは、通常、確実な配送を行うことはできない。データは１回、しかも１回 だけしか送られるないこと、及び主要な機械又はネットワークの障害の後に通信 が適正に再始動及び回復するであろうということを保証するために、パケット配 送のための基本ネットワーク・サポート以上のものが要求される。特に、確実な 配送システムにおける 両パートナは、どのデータがうまく伝送され、「ハード化」されたかを覚えてお かなければならない。ハード化するということは、ディスクのような記憶媒体に データを書き込み、たとえハードウエア障害があってもそれが回復可能であるこ とを保証するステップである。メッセージ・キューイング・システムにおける資 源回復の対策が、McGraw-Hill社発行（１９９４年）のB．Blakeley，H．Harris 及びR．Lewis著の「ＭＱＩを使用したメッセージング及びキューイング（Messag ing and Queuing Using the MQI）」と題した文献の２０９乃至２１７ページに 詳しく開示されている。 ビジネス・アプリケーションは、トランザクション的な方法で調整される必要 のあるアクティビティを持った幾つものサービス・アプリケーションを伴い得る ものである。この問題は、サーバ・システムにおけるメッセージ・キュー・マネ ージャ・プログラムによって解決される。 ゲートウェイ・プログラムは、単一の制御メッセージ・キューイング・アプリ ケーション・プログラムにメッセージを送り、そのメッセージ・キューイング・ アプリケーション・プログラムは、必要な場合には、それを個々のサービング・ アプリケーションに対する個別の要求に分解する。これらのメッセージは送られ 、メッセージ・キュー・マネージャ・プログラムによるトランザクション制御の 下に再結合される。そのようなトランザクション制御を行う機能を持ったメッセ ージング・プログラムはその分野では知られている（例えば、 ＩＢＭ社のＭＱＳｅｒｉｅｓのメッセージング・プログラムである）。 ゲートウェイ・プログラムの設計は、増大した要求に対処するために、エクス トラ・サービング・アプリケーションが付加されることを可能にする。即ち、本 発明の望ましい実施例による解決方法は変動可能である。これは、ゲートウェイ ・プログラムが各非同期メッセージのメッセージ・デスクリプタ部分においてセ ッション識別子を含むことによって達成される（メッセージ・デスクリプタは、 そのメッセージの特性を定義する情報、及びメッセージを処理すべき方法を決定 するためにどれがメッセージ・キューイング・サービスによって使用されるかを 定義する情報を含む。メッセージそのものは２つの異なるコンポーネント、即ち 、アプリケーション・データ部分及びそのアプリケーション・データに付随した メッセージ・デスクリプタ情報を含むメッセージ・ヘッダ部分を含む）。これは 、複数のサービング・アプリケーション・プログラムを単一の作業キューに対し て並行して走らせることを可能にする。アプリケーションが連続した対話の間に それ自身のコンテキスト・メッセージを保持する必要がある場合、それは、それ のセッション識別子に符合したメッセージを検索することができる。それがコン テキスト情報を維持しない場合、サービング・アプリケーションのインスタンス は検索を行い、それらが見つけた第１メッセージを処理することができる。 従って、望ましい実施例による本発明は、既存のウェブ・ブラウザの修正を必 要とすることなく、汎用のメッセージング・システムとインターネットＷＷＷサ ービスとのリンクを容易にするが、本発明はこの実施方法に限定されるものでは ない。本発明は、任意の２つのデータ処理システムにおける一方のシステム上に インストールされたコンピュータ・プログラムが同期通信を必要とし、他方のシ ステムにおけるプログラムが非同期形式の通信を必要とする場合のそれら２つの データ処理システムの間のリンクを提供するように実施可能である。ＩＢＭ社の ＭＱＳｅｒｉｅｓ製品のようなメッセージング・ソフトウエアに関連した望まし い実施方法による場合の本発明は、ＭＱＳｅｒｉｅｓがＴＣＰ／ＩＰ、ＡＰＰＣ 、及びＮｅｔＢＩＯＳ通信プロトコルをサポートするので、インターネット・プ ロトコル（ＩＰ）をサポートしないネットワークに対するブリッジを提供する。 従って、本発明は、ＩＰネットワーク及び非ＩＰネットワークにおけるアプリケ ーション相互間の通信を容易にする。 上記の望ましい実施例は、メッセージング・システムと関連した別々にインス トール可能なゲートウェイ・プログラムを含む。別の実施例は、ゲートウェイを キュー・マネージャ・プログラムの内部コンポーネントとして実施する。セッシ ョン識別子及びセッション状態テーブルは、キュー・マネージャの制御の下にメ ッセージ・キューとして実施されることが望ましい。ＭＱＳｅｒｉｅｓキュー・ マネージャにおいて 既に実施されているＭｅｓｓａｇｅＩＤ識別子及びＣｏｒｅ１ＩＤ識別子は、キ ューをスキャンする時に適当なサーチ情報として使用可能である。しかし、エン トリがキュー・マネージャ制御されたキュー上に残っている間にエントリを修正 するための対策はないので、キュー・マネージャ制御されたキューに保持された エントリの更新は、キューからのそれらエントリの除去、修正、及びその後のそ のキューにおける置換というステップを必要とする。共用メモリに保持されたテ ーブルにおけるエントリの更新は、以前のエントリを単に上書きすることを必要 とするだけである。「事象待ち（即ち、応答）又はタイム・アウト（wait for e vent or timeout）」オペレーションに対するメッセージ・キュー・マネージャ ・プログラムの機能を利用することには利点があるけれども、この機能は、一般 に、マルチ・スレッド・オペレーティング・システムによって与えられ、メッセ ージ・キュー・マネージャ・プログラムは、実際には、基礎的なオペレーティン グ・システムの機能を利用するものでもよい。別の実施例は、新たな応答メッセ ージが最初に応答キュー上に入れられる時、ゲートウェイ・プログラムのトリガ を使用することができるが、クライアント・システムによる現在生きているセッ ションがない時のトリガは望ましくないので、これは望ましい実施方法ではない 。本発明の更に別の実施例は、「待機を伴う取得（Get with Wait）」オペレー ションを呼び出す代わりに新たな応答メッセージに対する応答キューの周期的ス キャン を実施してもよい。 上記の望ましい実施例では、セッション識別子はウェブ・ブラウザのキャッシ ュ記憶装置に（ＨＴＭＬページにおける組込フィールドとして）自動的に記憶さ れる。しかし、別の方法として、セッション識別子はディスプレイ・スクリーン を通してエンド・ユーザに表示可能であり、その後の関連要求を行う時、セッシ ョン識別子内にタイプすることを要求されることがある。タイムアウト後のクラ イアント・システムに対する仮応答が自動的記憶又は将来の要求における自動的 包含なしに単にユーザに表示されるという実施例では、現在のセッションが維持 されるべきか、或いは識別子がその後の要求の再試行のために記憶される場合に そのセッションが終了させられるべきかを決定するのはユーザである。上記の実 施例も、ブラウザに返送された或る通信内にセッション識別子及びセッション状 態情報だけが含まれるという特徴を有するが、明らかに本発明の技術的範囲内に ある代替え方法は、すべての応答内に少なくともセッション識別子情報を含むこ とを伴う。 上記の望ましい実施例の特徴はゲートウェイ・プログラムによる状態データの 保全である。本発明の別の実施例は、ゲートウェイ・プログラムがセッション状 態情報の保全を伴わないようにアプリケーション・プログラムが処理するという シーケンス問題をすべてそのまま残している。

【手続補正書】 【提出日】１９９８年１１月１１日 【補正内容】 請求の範囲 １．通信ネットワークのためのデータ通信サーバ・システムにして、前記サーバ ・システムは前記サーバ・システムと前記ネットワークのクライアント・システ ムとの間の同期通信をサポートするための機能を有し、更に、前記サーバ・シス テムは前記サーバ・システムにおけるプログラム又は前記ネットワークの他のシ ステムにおけるプログラムとの非同期通信をサポートするための機能も有し、 前記クライアント・システム及び前記サーバ・システムの間の同期通信セッシ ョンにおける前記クライアント・システムからのリクエストに応答して、前記サ ーバ・システムにおけるプログラム又は前記ネットワークの他のシステムにおけ るプログラムにリクエストを非同期通信として送るための手段と、 前記クライアント・システムからのリクエストに応答してタイマを始動するた めの手段と、 前記非同期通信に対する応答の受信に応答して、前記クライアント・システム からのリクエストに前記応答を関連付けて前記クライアント・システムに応答が 送られることを可能にするための手段と、 前記非同期通信に対する応答を受信する前に、前記サーバ・システムによって 割り当てられたセッション識別子を含む仮応答を発生するための手段と、 前記非同期リクエストに対する応答が受信される前にプリセット期間が満了す る場合、前記同期通信セッションにおいて前記仮応答を前記クライアント・シス テムに送るための手段と、 を含むデータ通信サーバ・システム。 ２．前記同期セッションにおいて前記クライアントに応答を送るための手段を含 み、プリセット期間の満了前の前記非同期リクエストに対する応答の受信に応答 して、前記同期セッションにおいて送られる前記クライアント・システムに対す る応答内に前記受信された応答からの情報を含める請求の範囲第１項に記載のデ ータ通信サーバ・システム。 ３．前記クライアント・システムからのリクエストにセッション識別子を割り当 て、それがプログラムに送る前記非同期リクエストにおける前記セッション識別 子を含めるための前記サーバ・システムにおけるプロセスを含み、 前記セッション識別子を含む前記非同期リクエストに対する応答を前記プログ ラムから受信したことに応答して、前記プログラムからの応答を前記クライアン ト・システムからのリクエストと関連付けるために前記セッション識別子を使用 し、前記クライアント・システムに送られる応答に前記セッション識別子を含め るための手段を含む請求の範囲第１項に記載のデータ通信サーバ・システム。 ４．前記非同期リクエストに対する前記プログラムの応答に含まれたセッション 状態情報に応答して、前記クライアント ・システムに送られる前記応答にセッション状態情報を含めるための手段を含む 請求の範囲第３項に記載のデータ通信サーバ・システム。 ５．前記サーバ・システムは、クライアント・システム上にインストールされた インターネット・ワールド・ワイド・ウェブ（ＷＷＷ）ブラウザ・ソフトウエア からのリクエストに応答するためのＷＷＷサーバ・ソフトウエアをインストール され、クライアント・システムに送られる応答に含まれるＨＴＭＬページ内にセ ッション識別子情報を組み込むための手段を含む請求の範囲第３項に記載のデー タ通信サーバ・システム。 ６．前記サーバ・システムは、前記非同期リクエストに対する前記プログラムの 応答に含まれたセッション状態情報に応答して、エンド・ユーザによる完了のた めの前記セッション識別子を組み込まれた１つ又は複数のＨＴＭＬフォームを前 記ＨＴＭＬページ内に含めるための手段を含む請求の範囲第７項に記載のデータ 通信サーバ・システム。 ７．前記サーバ・システムは、前記非同期リクエストに対する前記プログラムの 応答に含まれたセッション状態情報に応答して、前記クライアント・システムに 送られる前記ＨＴＭＬページにセッション状態情報を組み込むための手段を含む 請求の範囲第５項又は第６項に記載のデータ通信サーバ・システム。 ８．クライアント・リクエストのＨＴＭＬデータを前記プロ グラムによって解釈可能なフォーマットに変換するための手段及び前記クライア ント・システムに対する応答に含めるために前記プログラムからの応答に含まれ た情報をＨＴＭＬに変換するための手段を含む請求の範囲第５項又は第６項に記 載のデータ通信サーバ・システム。 ９．前記サーバ・システムは、到着時の確認（ＣＯＡ）及び／又は配送時の確認 （ＣＯＤ）のレポートを行い、前記プリセット期間が満了する前のＣＯＡ又はＣ ＯＤのレポートの受信に応答して、前記プリセット期間の満了時に前記クライア ント・システムに送られる前記通信に前記ＣＯＡ又はＣＯＤのレポートを含める 請求の範囲第１項に記載のデータ通信サーバ・システム。 １０．前記サーバ・システムは、前記セッション状態の識別が前記非同期リクエ ストに対する前記プログラムの応答に含まれることに応答して、前記クライアン ト・システムに対する前記応答にセッション識別情報を含めるべきかどうかを決 定するための手段を含む請求の範囲第１項に記載のデータ通信サーバ・システム 。 １１．前記クライアント・システムに対する応答内にセッション状態情報を含め るための手段は前記セッション状態に従って前記セッション状態情報を含めるべ きかどうかを決定するための手段を含む請求の範囲第４項に記載のデータ通信サ ーバ・システム。 １２．前記クライアント・システムからのリクエストに応答 して、受信の確認が仮応答として前記クライアント・システムに送られるべきか 又は前記タイマが始動されるべきかを決定するための手段を含む請求の範囲第１ 項に記載のデータ通信サーバ・システム。 １３．通信ネットワークの第１システムにおける第１コンピュータ・プログラム と前記ネットワークの第２システムにおける第２コンピュータ・プログラムを介 してアクセス可能な第３コンピュータ・プログラムとの間のデータ通信の方法に して、 前記第１プログラムからの第１リクエストを前記第２システムへ同期通信セッ ションにおいて送るステップと、 前記第２システムが前記第１プログラムから同期リクエストを受信したことに 応答して、前記第２システムにおける第２プログラムによって割り当てられたセ ッション識別子を含むリクエストを前記第３プログラムに非同期通信として送る ステップと、 前記第２システムが前記非同期通信に対する応答を受信する時、前記第１プロ グラムに応答が送られることを可能にするために、前記セッション識別子を使用 して前記応答と前記第１プログラムからの前記リクエストとを関連付けるステッ プと、 前記同期通信セッションにおいて前記第１プロセスに応答を送るステップであ って、前記第１プロセスに送られる応答は前記非同期通信に対する応答がプリセ ット期間の満了前に 受信されない場合、前記セッション識別子を含む仮応答を含むステップと、 を含む方法。

Claims (1)

1. 【特許請求の範囲】 １．通信ネットワークのためのデータ通信サーバ・システムにして、前記サーバ ・システムは前記サーバ・システムと前記ネットワークのクライアント・システ ムとの間の同期通信をサポートするための機能を有し、更に、前記サーバ・シス テムは前記サーバ・システムにおけるプログラム又は前記ネットワークの他のシ ステムにおけるプログラムとの非同期通信をサポートするための機能も有し、 前記クライアント・システム及び前記サーバ・システムの間の同期通信セッシ ョンにおける前記クライアント・システムからの要求に応答して、前記サーバ・ システムにおけるプログラム又は前記ネットワークの他のシステムにおけるプロ グラムに要求を非同期通信として送るための手段と、 前記非同期通信に対する応答の受信に応答して、前記クライアント・システム からの要求に前記応答を関連付けて前記クライアント・システムに応答が送られ ることを可能にするための手段と、 前記非同期通信に対する応答を受信する前に仮応答を発生するための手段と、 前記同期通信セッションにおいて少なくとも仮応答を前記クライアント・シス テムに送るための手段と、 を含むデータ通信サーバ・システム。 ２．仮応答は前記サーバ・システムによって割り当てられた セッション識別子を含む請求の範囲第１項に記載のデータ通信システム。 ３．前記クライアント・システムからの要求に応答してタイマを始動するための 手段を含み、 前記応答をクライアント・システムに送るための手段は、前記非同期要求に対 する応答が受信される前にプリセット期間が満了した時、前記クライアント・シ ステムに仮応答を送るようにトリガされる請求の範囲第２項に記載のデータ通信 システム。 ４．前記応答をクライアント・システムに送るための手段は、プリセット期間の 満了前の前記非同期要求に対する応答の受信に応答して、前記同期セッションに おいて送られる前記クライアント・システムに対する応答内に前記受信された応 答からの情報を含める請求の範囲第１項乃至第３項の何れか１つに記載のデータ 通信システム。 ５．前記クライアント・システムからの要求にセッション識別子を割り当て、そ れがプログラムに送る前記非同期要求における前記セッション識別子を含めるた めの前記サーバ・システムにおけるプロセスを含み、 前記セッション識別子を含む前記非同期要求に対する応答を前記プログラムか ら受信したことに応答して、前記プログラムからの応答を前記クライアント・シ ステムからの要求と関連付けるために前記セッション識別子を使用し、前記クラ イアント・システムに送られる応答に前記セッション識別子 を含めるための手段を含む請求の範囲第１項に記載のデータ通信システム。 ６．前記非同期要求に対する前記プログラムの応答に含まれたセッション状態情 報に応答して、前記クライアント・システムに送られる前記応答にセッション状 態情報を含めるための手段を含む請求の範囲第５項に記載のデータ通信システム 。 ７．前記サーバ・システムは、クライアント・システム上にインストールされた インターネット・ワールド・ワイド・ウェブ（ＷＷＷ）ブラウザ・ソフトウエア からの要求に応答するためのＷＷＷサーバ・ソフトウエアをインストールされ、 クライアント・システムに送られる応答に含まれるＨＴＭＬページ内にセッショ ン識別子情報を組み込むための手段を含む請求の範囲第５項又は第６項に記載の データ通信システム。 ８．前記サーバ・システムは、前記非同期要求に対する前記プログラムの応答に 含まれたセッション状態情報に応答して、エンド・ユーザによる完了のための前 記セッション識別子を組み込まれた１つ又は複数のＨＴＭＬフォームを前記ＨＴ ＭＬページ内に含めるための手段を含む請求の範囲第７項に記載のデータ通信シ ステム。 ９．前記サーバ・システムは、前記非同期要求に対する前記プログラムの応答に 含まれたセッション状態情報に応答して、前記クライアント・システムに送られ る前記ＨＴＭＬページにセッション状態情報を組み込むための手段を含む請求の 範囲第７項又は第８項に記載のデータ通信システム。 １０．クライアント要求のＨＴＭＬデータを前記プログラムによって解釈可能な フォーマットに変換するための手段及び前記クライアント・システムに対する応 答に含めるために前記プログラムからの応答に含まれた情報をＨＴＭＬに変換す るための手段を含む請求の範囲第７項乃至第９項の何れか１つに記載のデータ通 信システム。 １１．前記サーバ・システムは、到着時の確認（ＣＯＡ）及び／又は配送時の確 認（ＣＯＤ）のレポートを行い、前記プリセット期間が満了する前のＣＯＡ又は ＣＯＤのレポートの受信に応答して、前記プリセット期間の満了時に前記クライ アント・システムに送られる前記通信に前記ＣＯＡ又はＣＯＤのレポートを含め る請求の範囲第３項に記載のデータ通信システム。 １２．前記サーバ・システムは、前記セッション状態の識別が前記非同期要求に 対する前記プログラムの応答に含まれることに応答して、前記クライアント・シ ステムに対する前記応答にセッション識別情報を含めるべきかどうかを決定する ための手段を含む請求の範囲第１項乃至第１１項の何れか１つに記載のデータ通 信システム。 １３．前記クライアント・システムに対する応答内にセッション状態情報を含め るための手段は前記セッション状態に従って前記セッション状態情報を含めるべ きかどうかを決定するための手段を含む請求の範囲第６項に記載のデータ通信シ ステム。 １４．前記クライアント・システムからの要求に応答して、受信の確認が仮応答 として前記クライアント・システムに送られるべきか又は前記タイマが始動され るべきかを決定するための手段を含む請求の範囲第３項に記載のデータ通信シス テム。 １５．通信ネットワークのためのデータ通信クライアント・システムにして、 特定の同期通信セッションにおいて、前記ネットワークのサーバ・システムに 要求を送るための手段と、 前記サーバ・システムからの応答を受信するための手段と、 受信された応答に応答して、前記サーバ・システムにおけるプロセスによって 割り当てられ、前記応答に含まれたセッション識別子情報を記憶するための手段 と、 前記サーバ・システムとのその後の対話において使用するために前記記憶され た情報を検索するための手段と、 を含むクライアント・システム。 １６．前記検索するための手段は、 クライアント要求のための入力情報と受信された応答の記憶された情報とを前 記クライアント要求を送る前に比較するための手段と、 前記入力情報及び前記記憶された情報の間の符合を決定することに応答して前 記記憶された情報を検索し、前記記憶されたセッション識別子情報を前記クライ アント要求に含めるための手段と、 を含む請求の範囲第１５項に記載のシステム。 １７．前記クライアント・システムにおいて前記セッション識別子情報を記憶す べき時を、サーバ・システムからの応答に含まれたセッション状態情報に従って 決定するための手段を含む請求の範囲第１５項又は第１６項に記載のシステム。 １８．前記セッション状態情報が前記クライアント・システムに記憶される時に タイマを始動するための手段と、 前記タイマの期間満了時に前記セッション状態情報を削除するための手段と、 を含む請求の範囲第１５項乃至第１７項の何れか１つに記載のシステム。 １９．通信ネットワークの第１システムにおける第１コンピュータ・プログラム と前記ネットワークの第２システムを介してアクセス可能である第３コンピュー タ・プログラムとの間のデータ通信の方法にして、 同期通信セッションにおいて前記第１プログラムからの要求を前記第２システ ムが受信したことに応答して、前記第３プログラムに要求を非同期通信として送 るステップであって、前記要求は前記第２システムにおける第２プログラムによ って割り当てられたセッション識別子を含むステップと、 前記非同期通信に対する応答を前記第２システムが受信したことに応答して、 前記第１プログラムに応答が送られることを可能にするように、前記セッション 識別子を使用して前記応答を前記第１プログラムからの前記要求と関連付けるス テップと、 を含む方法。 ２０．通信ネットワークの第１システムにおける第１コンピュータ・プログラム と前記ネットワークの第２システムにおける第２コンピュータ・プログラムを介 してアクセス可能な第３コンピュータ・プログラムとの間のデータ通信の方法に して、 前記第１プログラムからの第１要求を前記第２システムへ同期通信セッション において送るステップと、 前記第２システムが前記第１プログラムから同期要求を受信したことに応答し て、前記第２システムにおける第２プログラムによって割り当てられたセッショ ン識別子を含む要求を前記第３プログラムに非同期通信として送るステップと、 前記第２システムが前記非同期通信に対する応答を受信する時、前記第１プロ グラムに応答が送られることを可能にするために、前記セッション識別子を使用 して前記応答と前記第１プログラムからの前記要求とを関連付けるステップと、 前記同期通信セッションにおいて前記第１プロセスに応答を送るステップであ って、前記第１プロセスへの応答は前記非同期通信に対する応答が受信される前 に送られる場合、前記セッション識別子を含む仮応答を含むステップと、 を含む方法。 ２１．プリセット期間の満了前に前記非同期通信に対する応答が受信されない場 合、仮応答が前記第１プロセスに送られ る請求の範囲第２０項に記載の方法。