JP3578221B2 - データ通信サーバ・システム - Google Patents

Description

技術分野
本発明は、ネットワークにおいてデータ通信及びデータ処理資源、又はそのどちらかをリンクすることに関するものであり、特に、相異なる通信環境の間にリンクを設けることに関するものである。
背景技術
コンピュータの「ネットワーク」は、相互に情報を交換し得る任意の数のコンピュータでよい。それらのコンピュータは、それらが情報を交換することができるようにそれらを相互に接続するための何らかの方法（例えば、電話線又は他の通信システムによる方法）が存在する限り、任意の構成で配列可能であって、しかも、同じ部屋に、或いは異なる国に設置可能である。複数のコンピュータが、ネットワークを形成するように相互に接続可能であると同様に、複数のネットワークが、ブリッジ及びゲートウェイとして知られたツールを通して、相互に接続可能である。これらのツールは、１つのネットワークにおけるコンピュータが他のネットワークにおけるコンピュータと情報を交換することを可能にする。インターネットは、単独の所有者又はコントローラを持たず、しかも、大型及び小型の公衆及び専用ネットワークを含む複数のネットワークより成るネットワークである。これらのネットワークでは、インターネット・プロトコル・ソフトウエアを実行するいずれの接続されたコンピュータも、セキュリティ・コントロールを受けて、そのインターネットに接続された他の任意のコンピュータと情報を交換することができる。このような相互に接続するように取り決められたネットワークの複合集合体は単一の伝送媒体に依存するものではない（例えば、双方向通信は、衛星リンク、光ファイバ中継回線、電話回線、ケーブルTV線、及びローカル無線リンクを介して生じ得るものである）。
ワールド・ワイド・ウェブ（WWW）インターネット・サービスは、大量のネットワーク・アクセス可能な情報へのアクセスを提供し、しかもインターネット接続されたコンピュータ相互間の低コスト通信を提供し得る広域情報検索機構である。ワールド・ワイド・ウェブに関する情報は、Andrew Ford著の「ウェブをスピンする（Spinning the Web）」と題した刊行物（International Thomson Pulbishing,London 1995）、及びJohn December及びNeil Randall著の「解放されたワールド・ワイド・ウェブ（The World Wide Web Unleashed）」と題した刊行物（SAMS Publishing,Indianapolis 1994）において見ることができる。WWWの使用は、それが、対話的なマルチメディア・プレゼンテーション機能と結合された融通性、可搬性、及び使い易さを結集したものであるために、爆発的な速度で成長しつつある。WWWは、インターネットに接続されしかも適切なソフトウエア及びハードウエア構成を有する任意のコンピュータが、インターネット上のどこかで使用可能にされた任意のドキュメントを検索することを可能にするものである。WWWにおける検索可能なドキュメントは、「ハイパーメディア」ドキュメント、即ち、テキスト・ドキュメント、或いはサウンド及びイメージのような他の形式のメディアであってもよいドキュメント、及び他のドキュメントに対するリンク（ハイパーリンク）を有するドキュメントを含む。WWWにおけるテキスト・ドキュメントのフォーマットは、１つのアペレーティング・システム及びハード・ウエア・プラットフォーム上で作成されたドキュメントが、ウェブ・ブラウザ（下記参照）を有する他の任意のプラットフォーム上でユーザにより読み取り可能であるようなHTML（ハイパーテキスト・マークアップ言語）における標準フォーマットである。イメージは、例えば、標準GIF又はJPEGフォーマットで別々のグラフィックス・ファイルに記憶可能であり、ユーザが指定のイメージ・ファイル及びHTMLテキストを検索するようにプロンプト指示されるようにHTMLテキストにおいて参照可能である。
ユーザは、「ウェブ・ブラウザ」又は「ウェブ・クライアント」を使用してこの情報をアクセスする。その「ウェブ・ブラウザ」及び「ウェブ・クライアント」は、ユーザのコンピュータ上にインストールされたソフトウエアであり、インターネットを介してウェブ・サーバからドキュメントをサービス提供又は検索するための機能を有する。現在利用可能なウェブ・ブラウザは、IBM社からの「WebExplorer」及びNCSAからの「Mosaic」を含む。そのようなブラウザはディレクトリ及びサーチ・ツールを含み、HTML及び他のWWW標準フォーマットを理解し、ファイルをこれらのフォーマットで正しく表示又は出力することができる。これらのウェブ・ブラウザのユーザ・インターフェースはグラフィカル「ポイント・アンド・クリック」インターフェースである（即ち、グラフィカル・ディスプレイを横切ってカーソルを移動させ、しかる後にマウス・ボタンを押すことによってアイテムを選択することができる）。WWWは、各々が特定のユニフォーム・リソース・ロケータ（又は,URL）を有するページ又はファイルとして構成される。URLは、サーバ・マシン及びそのマシンにおける特定のファイル又はページを表す。ユーザは特定のURLを指定するか、又は「ハイパーリンク」によって１つのURLから関連のURLにジャンプすることができる。即ち、ページ上のワード又は記号は、例えば、マウスを関連ロケーションにおいてクリックすることによって選択可能なもう１つのURLと関連付けられ、関連のページをブラウザに検索及び表示させることができる。単一のサーバ上に多くのページが存在してもよく、関連のハイパーリンクされたページが種々のサーバ上に設けられてもよい。URLが「http:」で始まる場合、これは、ファイルがハイパーリンクを含むことを表す。
ユーザが自分のウェブ・ブラウザを使用してウェブ・サーバ・システム上のページに対するURLを選択する時、そのページに特有のアクションを遂行する単発の要求が関連のサーバに送られる。多くの場合、サーバはその要求に応答して、記憶されたページのデータベースからその要求されたページを検索し、HTMLページをユーザへの表示のためにインターネットを介してWWWクライアントに伝送する。これは、単一の終端間同期通信セッションの範囲内で遂行される。即ち、ブラウザはそれの要求を送り、応答を待ってからそれ以上の何らかの処理を進行させ、又は他の要求を開始させる。ブラウザは、それがその要求された応答を待っている間、「阻止」又は「中断」されていると云える。或る場合には、ブラウザの要求は、HTMLを発生するためのアプリケーションを立ち上げるようにサーバを導くであろうが、ブラウザは同時通信セッションに備えるものではなく、しかもアプリケーション状態情報は要求相互間に維持されないので、ブラウザからの単発の要求はこの同期通信セッションの範囲内で応答を要求する。ブラウザによって要求されたページへのアクセスの失敗は、エラー・メッセージがユーザの端末上に表示されることによってユーザに信号で知らされるが、サーバが単に応答を遅らせる場合、ブラウザは無限期間にわたって中断されたままになる。実際には、ユーザは、その遅れが通信にとって受容し得ないものである場合、通信の試みを放棄することがある。ウェブ・ブラウザには、要求の自動再試行のための機能はない。
現代の企業は、その企業における他の部門との通信、及び異なる国にあることもある顧客又は納入業者のような関連企業とコミュニケートするための機能を必要とする。WWWインターネット・サービスは、会社間の通信のための費用効果のよい通信媒体を提供してそのような要求に対する部分的な答えを与えることができるが、WWWインターネット・サービスの単発の要求／応答通信モデル及びブラウザからの並列的な要求に対する備えの欠如は、要求された情報が受容可能な期間内に得られない場合、厳しい制限を表すことがある。センダ・システムが無期限に中断されるということは受容し得ないことであり、又、サーバ・アプリケーションが時間内に要求に応答するかどうかに従ってビジネス・クリティカルなアプリケーションの成功が決まるということも受容し得ないことである。WWWインターネット・サービスは、多くのビジネス・クリティカルなアプリケーションの要件であるメッセージの確実な配送のための機能を提供するものではない（即ち、アプリケーションは、それが送ったメッセージが目的の宛先へ送られる途中で失われないこと、及びそれが一度しか送られないことを知る必要がある）。又、ビジネス・アプリケーションは多くの要求／応答の対を伴う会話に関わり得るものであり、ウェブ・ブラウザ要求相互間で交換される如何なるコンテキスト情報が欠如しても、同じビジネス・アプリケーションの一部である要求を相互に関連付けるための機能が存在しないことを意味する。
同期的な時間依存の「要求及び応答待ち」モデルに対する代替の通信モデルは非同期メッセージングである。メッセージをレシーバ・プログラムに送るプログラムはレシーバからの返事を待つためにブロックされる必要がなく、従って、実行し続けることができ、センダ及びレシーバは相互に同期化（直列化）されない。プログラム間の非同期メッセージングは、一般に、メッセージ・キューを中間記憶機構として使用する。従って、メッセージは、それが第１プログラムから送られた時、そのメッセージ・キューに入れられるし、レシーバ・プログラムが作動可能である時、レシーバ・プログラムによってそのメッセージ・キューから検索可能である。プログラム相互間には専用の論理的接続は存在しない。メッセージをキューに入れた後、センタ・プログラムは、ネットワークにおける他のプログラムにメッセージを送ることを含む他のタスクを実行するように進むことができる。この分野では、非同期メッセージング・システムを設けることが知られている。その非同期メッセージング・システムは、異種のネットワークに跨るプログラム間通信をサポートし、アプリケーション・プログラム（それぞれが特定のアペレーティング・システム環境に対して書かれている）が複数のネットワークに影響されないようにし、メッセージ・キューを維持及び位置指定する作業がないようにするものである。種々のビジネス・アプリケーション・プログラム相互間の効果的な相互協調処理を達成することを必要とするが、或る範囲の本質的に相違するアペレーティング・システム及びハードウエア環境を含むデータ処理資源を有するというような多くの企業にとっては、そのようなメッセージング・システムは重要である。
メッセージ待ち行列製品及び商業的に入手可能なメッセージ待ち行列製品は、McGraw−Hill社発行（1994年）のB.Blakeley、H.Harris及びR.Lewis著の「MQIを使用したメッセージング及びキューイング（Messaging and Queuing Using the MQI）」において、及びIBM社から入手可能な次の刊行物、即ち、「メッセージング及びキューイング入門（An Introduction to Messaging and Queuing）」（IBMドキュメント番号GC33−0805−00）及び「MQSeries−メッセージ・キュー・インターフェース・テクニカル・リファレンス（MQSeries−Message Queue Interface Technical Reference）」（IBMドキュメント番号SC33−0850−01）に記載されている。なお、IBM及びMQSeriesはIBM社の商標である。IBM社のMQSeriesメッセージング・ソフトウエア製品は、システム又は通信障害の場合でも１回の、しかも、１回だけの確実なメッセージ配送を行うメッセージング・プロトコルに従って作業の論理的ユニット内でメッセージを同期化するというトランザクション・メッセージング・サポートを提供する。MQSeries製品は、メッセージがレシーバ・システムによって安全に記憶されたとして確認されるまでセンダ・システムにおける記憶装置からそのメッセージを最終的に削除しないことによって、及び複雑な回復機構を使用することによって確実な配送を提供する。記憶が成功したことを確認した時にメッセージの転送をコミットする前に、センダ・システムにおける記憶装置からのメッセージの削除及びレシーバ・システムにおける記憶装置への挿入の両方が「未確定」状態に保たれるし、失敗の場合には、それは原子的にバックアウト可能である。このメッセージ伝送プロトコル並びに関連のトランザクション概念及び回復機構は、国際特許出願WO 95/10805号及び米国特許第5,465,328号に開示されている。
WWWインターネット・サービスのクライアント・システムのような同期通信に適応した計算資源に非同期（オフ・ライン）処理の恩恵をもたらすことは望ましいことであり、しかも、一般的には、既存の同期資源に対して大きな変更を必要とすることなく、非同期モデルの通信に基づく資源及び同期モデルに基づく資源の間の相互協調処理を可能にすることが望ましい。又、同期的に接続されたクライアント・システムからの非同期メッセージの信号状況追跡を容易にすることも望ましい。
計算資源をインターネットにリンクすることに加えて、インターネット標準（インターネット・プロトコル、HTMLの使用等）が「イントラネット」において、例えば、特定の企業におけるコンピュータのネットワーク（インターネットの標準に従ったネットワーク）において有利に実現されることも企業はわかっている。今や、ブラウザ・ソフトウエアは、イントラネット内で使用するために利用可能である。
上記の要件は、それらが種々の環境に適応するかどうか又は種々の通信モデル又はアーキテクチャに基づくものであるかどうかに関係なく、データ処理資源の多くのユーザがそれらの種々の資源の間で相互協調処理するための要件を例示するものである。種々のアペレーティング・システムに対して書かれ、種々の通信モデル又はパラダイムに基づいたアプリケーション・プログラム、並びに、種々の通信プロトコル、データ・フォーマット、言語、又は通信のモードを使用するコンピュータ及び他の通信システムは、継ぎ目なく、しかも対話の複雑性をエンド・ユーザが知ることもなく相互協調処理するためには益々要求される。本発明は、種々の資源相互間にリンクを提供して相互協調処理が望ましい資源相互間の明らかに固有の非互換性を処理するように働く。
発明の開示
本発明の第１の局面によれば、通信ネットワークのデータ通信サーバ・システムが提供される。その通信ネットワークでは、サーバ・システムは、そのサーバ・システムとネットワークのクライアント・システムとの間の同期通信をサポートするための機構を有する。又、サーバ・システムは、そのサーバ・システム上の又はそのネットワークにおける他のシステム上のプログラム（アプリケーション・プログラムのようなプログラム）との非同期通信をサポートするための機構も有する。上記サーバ・システムは：
クライアント・システムとサーバ・システムとの間の同期通信セッションにおける前記クライアント・システムからの要求に応答して、サーバ・システムにおけるプログラム又はネットワークの他のシステムにおけるプログラムに要求（クライアント・システムに関連する要求）を非同期通信として送るための手段と、
前記非同期通信に対する応答の受信に応答して、前記応答をクライアント・システムからの前記要求と関連付け、クライアント・システムに応答が送られることを可能にするための手段と、
前記非同期通信に対する応答の受信前に仮応答を発生するための手段と、
前記同期通信セッションにおいて前記クライアント・システムに少なくとも仮応答を送るための手段と、
を含む。
従って、本発明によるシステムは、たとえ非同期要求に対する応答が未だ受信されてなくても、同期通信セッションにおいてクライアントに少なくとも仮応答を送るための手段を有する。
本発明の第２の局面は、前述のサーバ・システムの機構を使用してクライアント・プログラムと、サーバ・システム又はネットワークの他のシステムにおけるプログラムとの間のプログラム間通信を提供する。
本発明は、たとえクライアント・システムにおけるプロセスがプログラム間通信のための専用の同期通信セッションを必要としても、そのクライアント・システムにおけるプロセスが非同期通信プログラムとコミュニケートすることを可能にする。サーバ・システム上のプログラム又はネットワークにおける他のシステム上のプログラムは、専用の通信セッションがなくても非同期メッセージを受信及び送信するように適応されたアプリケーション・プログラムであってもよい。又、初期の同期セッションにおいてクライアント・システムに送られる仮応答は、サーバ・システムが要求を受信したことを確認するための手段を提供する。サーバ・システムはサーバ相互間でメッセージの確実な配送を行うサーバのネットワークの一部であるが、同期的に接続されたクライアント・システムが、クライアント及び接続されたサーバの間の通信ホップのための確実な配送をサポートしない場合、要求がサーバに成功裏に到達したかどうかの追跡、即ち、通信経路の非保証リンクに跨る通信の追跡を行うことが非常に望ましいことがある。
「仮応答」は、プリセット期間内に（例えば、システム管理者によって定義された期間内に）クライアント・システムに送るための「完全応答」が得られない時に送られるだけであることが望ましい。即ち、サーバがその要求された完全応答を未だ与えることができないようなプリセット期間が満了した時、非同期通信のアプリケーション・プログラムから応答が未だ受信されていない場合、サーバ・システムにおけるプロセスはクライアント・システムに仮応答を送るためにトリガされる。その仮応答は、サーバ・システムによって割り当てられ、しかもサーバ・システムにおいて独特のセッション識別子を含むことが望ましい。
クライアント・システムに対する仮応答にセッション識別子を含むことは、アプリケーション・プログラム又は他の非同期的にコミュニケートするプログラムからの期待された完全応答をタイムアウト前に受信しなかったクライアント・システム（又は、クライアント・システムにおいて作業するエンド・ユーザ）が、そのセッション識別子に関連した応答が未だ使用可能であるかどうかを決定すること可能にする。従って、仮応答を受信したクライアントは他の処理タスクを進めることができ、また、セッション識別子を使用して、その後サーバとの対話に戻ることができる。これはそうでない場合に生じる問題点、即ち、同期的に接続されたクライアント・プロセスが応答を待つためにブロックされたままでなければならないか、或いは応答が十分に早く得られない場合にアプリケーションを放棄しなければならないという問題点を回避する。
本発明の望ましい実施例によれば、タイマの期間満了に応答してクライアント・システムに送られた通信は、クライアント・システムにおける同期的に接続されたプロセスを中断されたままにしておく（即ち、現在のセッションが維持される）べきか又はセッションが放棄されるべきかに関するクライアント・システムにおけるプロセス又はユーザによる判断を促す。セッションが放棄される場合、クライアント・プロセスはセッション識別子によって前の対話に戻ってもよい。サーバが、同じセッション識別子を持つ前の要求に対する如何なる使用可能な応答でも識別できるように、クライアント・システムに送られた識別子が、サーバ・システムに送られるその後の要求に含まれてもよい。従って、タイムアウトの後、専用の通信セッションを必要とするクライアントが、サーバに対するそれの同期接続を維持すべきか、或いは関連の同期セッションを使用するサーバとの非同期通信である通信に事実上変更すべきかを決定すること、或いは単にその通信を永久的に放棄することを可能にされる。従って、クライアントは、無期限に中断したままにするというオプション又はアプリケーションを放棄するというオプション以外のオプションを与えられる。
クライアントが前の対話に戻ることを可能にする他に、特定の対話に対するセッション識別子をクライアントに与えるということは、たとえクライアント・システムにおける通信プロセスが単発の要求／応答モデルに基づくものであっても、クライアントが会話という多くの要求／応答の対と関連することを容易にする。それは、クライアントが応答を待っている時にクライアントとサーバとの間のリンクに障害が起こることがあるという問題の処理を助ける。更に、それは、クライアント・プロセス又はユーザが幾つかの異なるアプリケーションとの対話を、それらの間を区別するための手段を設けることによって、介在させることを可能にし、しかも複数のユーザが同じアプリケーションを同時にアクセスすることを可能にする。セッション識別子は、その後の使用のために、仮応答の受信時にクライアント・システムによって自動的に記憶されてもよい。
「クライアント」及び「サーバ」という用語は、特定の対話において果たされる役割を単に区別するために使用される。即ち、クライアントは要求を発生し、サーバはその要求に応答してアクションを取る。他のコンピュータからの要求があった時にタスクを遂行するコンピュータはいずれもサーバである。「クライアント／サーバ」という用語は、クライアント（例えば、ワークステーション）がエンド・ユーザの対話のための機能を提供するだけであり、一方、サーバ（例えば、メインフレーム・コンピュータ）がデータの記憶及びアクセスを行って複雑な処理を遂行するという環境を呼ぶために、データ処理の分野において使用されることが多い。本発明はそのような「クライアント／サーバ」環境に適用可能であり、しかも、通信システムによって提供される機能の間にそのような区別がない「対等」環境にも適用可能である。本発明は、第１システムにおけるコンピュータ・プログラムが同期通信に特に適応するという状況であって、しかも、ウェブ・ブラウザがメッセージ・キューイング・システムを介して非同期アプリケーション・プログラムと相互協調処理することが望ましいというような、そのコンピュータ・プログラムが、異なるシステムにおいて実行中の非同期プログラム間通信に適応するアプリケーション・プログラムとコミュニケートすることが望ましいという状況において特に価値がある。
本発明の望ましい実施例によれば、サーバがプリセット時間の経過前にそれの非同期要求に対する応答を受信する場合、それは、サーバが同期セッションにおいて送るクライアント・システムへのそれの応答の中にその受信した応答からの情報を含むであろう。従って、アプリケーション・プログラムとの通信の非同期的な性質は、そのアプリケーション・プログラムからの応答が十分に速く得られてクライアントが同期セッションにおいて完全応答を送られる場合、クライアントにとって見えないものにされることがある。
本発明の別の実施例は、タイマの期間満了を待つことなくクライアント要求の受信の仮確認をクライアント・システムに戻すことによって、クライアント・プロセスの阻止を回避する。その受信の確認は、サーバ・システムにおけるプロセスによって割り当てられたセッション識別子（例えば、独特の参照番号）を含む。この場合、クライアントは、それがその確認を受信すると、完全応答又はタイマの期間満了を待つために中断されることなく直ちに他のタスクを進行させてもよい。その後、アプリケーション・プログラムからの応答が受信される時、それはサーバにおける記憶装置に入れられ、クライアントが、その割り当てられたセッション識別子を参照する更なる通信をサーバに送るような時間まで保持される。サーバは記憶された応答のセッション識別子及び新しい要求を突き合わせ、しかる後、その記憶された応答をクライアントに送る。
クライアント要求に対する応答のタイプをその要求の性質に依存させることも本発明の技術的範囲にある。商品注文のような或る要求は、クライアント・プロセスが中断される時間を最小にするために、割り当てられた注文番号でもって受信を即時確認することを必要とすることがある。銀行の残高照会のような他の要求は、そのような情報が速く得られる場合、それが単に必要とされるだけであることが多いので、その要求された情報を供給する前にその要求の受信を確認することを必要としないことがある。そのような例では、クライアントが完全応答のための所定の期間を待つことは明らかである。即時確認を送るべきか否かのこの決定は、要求フォーム内に任意選択フィールド又はパラメータを設けることによりそのような確認を希望することを表すための手段、及びこのフィールドにおけるエントリに応答するための手段をエンド・ユーザに与えることによって実施されることが望ましい。
セッション識別子は、サーバ・システムにおけるプロセスによってクライアント・システムからの要求と関連付けられることが望ましく、そのプロセスは、アプリケーション・プログラムに送られる関連の非同期要求にそのセッション識別子を組み込む。従って、非同期サーバ要求は、初期クライアント要求からの情報及び割り当てられた識別子を含む。その後、サーバ・システムが、このセッション識別子を含む応答をアプリケーション・プログラムから受ける時、サーバはこの応答をクライアント・システムからの要求と関連づけ、そのセッション識別子を含む応答をクライアント・システムに送る。サーバが、複数の同期セッションを自動的にはサポートしないクライアント・プロセスとの対話にセッション識別子を割り当てようとすることがあることに注意してほしい。セッション識別子の交換及びクライアント・システムの記憶装置の使用は、それの戻されるセッション識別子を記憶することを容易にし、これらの識別子が同時に生じたセッションを区別するために使用されることを可能にする。クライアントは、それが複数の異なるアプリケーションを区別するための手段を有するので、それらの異なるアプリケーションとの対話をインタリーブすることを可能にされ、サーバは、非同期メッセージに対する応答をそれぞれの要求と容易に関連付けることを可能にされる。アプリケーションの同時処理或いは並列処理のためのそのような対策はビジネス効率を非常に高めることがある。
本発明は、単発の同期通信のために設計された通信資源が非同期通信を利用する資源を相互協調処理することを可能にする。
本発明によるシステム及び方法がクライアント・システムとアプリケーション・プログラムとの間の対話の直列化をサポートすることは望ましいことである。これは、クライアントに送り戻されるアプリケーション・プログラムからのメッセージに含まれるセッション状態情報（現在の会話における対話の位置を識別するシーケンス番号のようなもの）によって実現可能である。クライアント・システムからの更なる入力を必要とするアプリケーションは、それの応答におけるセッション状態情報によってこれを表すであろう。この情報はサーバ・システム及びクライアント・システムの一方又は両方にとって識別可能である。セッション識別子及びセッション状態情報によって、幾つかの連続したユーザ対話を伴うことのある特定のアプリケーションの関連の要求／応答の対を識別すること、及びセッションにおける通信の正しい直列的順序づけを保証することが可能である。
セッション識別子は、タイマの期間満了後にクライアントに送られる通信に、及びクライアントとの更なる対話を期待しているアプリケーションからクライアントに送られる応答に含まれることが望ましい。一実施例によれば、応答内にセッション識別情報を含むべきかどうかに関する決定がサーバ・システムにおいて存在する。その決定プロセスは、通信アプリケーション・プログラムから送られたセッション状態情報に応答し、しかもタイマの期間満了にも応答することが望ましい。クライアントからの更なる入力（例えば、クライアント・システムにおけるエンド・ユーザ又はプロセスからの入力）が期待されない場合、サーバ・システムは、クライアントに応答を送る時にすべてのセッション特有の資源を保留解除し、セッション識別子は全く必要とされない。
この決定プロセスは、セッションが必要以上に長い期間の間維持されることに関連する潜在的問題から見て望ましいかも知れない。第１に、セッションを維持することは幾つものシステム資源を使用する。第２に、一連の要求／応答の対話のうちの最後の対話において識別子情報を戻すことは、その識別情報がクライアント・システムにおける記憶装置に無期限に残ることを必要とすることがある。これは、セキュリティ・エクスポージャ並びにクライアント資源の使用であるかも知れない。識別子情報がいつもクライアント・システムに戻される場合（即ち、前述の決定プロセスが実施されない場合）、上記の問題は、適当な時間後にクライアント・システムから状態情報を削除することによって処理される。
本発明の望ましい実施例は、サーバ・システムがインターネット・ワールド・ワイド・ウェブ（WWW）サーバ・ソフトウエアをその上にインストールされ、クライアント・システムが、インターネット接続されたサーバ・システムに要求を供給するためのWWWブラウザ・ソフトウエアをその上にインストールされるデータ通信システムを提供する。又、サーバ・システムは、アプリケーション・プログラム相互間の非同期メッセージ通信をサポートするための機能も有する。サーバ・システムが、非同期通信用に設計されたアプリケーション・プログラムとの対話を必要とするHTML要求を前記WWWクライアント端末（同期通信セッションにおける端末）から受ける時、サーバ・システムにおけるプロセスは、アプリケーション・プログラムの入力キューに送られるメッセージとして、その要求をアプリケーション・プログラムに送る。アプリケーション・プログラムがHTMLを解釈し得ない場合、サーバにおけるプロセスは、その受信したHTML要求を、アプリケーション・プログラムにとって認識可能なメッセージ・フォーマットに変換し、しかる後、その変換されたメッセージを送る。プリセット期間の満了前にアプリケーション・プログラムから応答メッセージを受信したことに応答して、サーバ・システムにおけるプロセスは（必要な場合には）その応答メッセージとHTMLに逆変換し、その作成されたHTMLページをクライアント端末に応答として送る。WWWクライアントの視点から、その応答がタイムアウト期間の経過前に得られる場合、その応答はオリジナル同期通信セッション内である。
サーバ・システムは、前記クライアント・システムに送られた応答に含まれるHTMLページ内にセッション識別情報を組み込むための手段を含む。サーバ・システムは、非同期要求に対するアプリケーション・プログラムの応答に含まれたセッション状態情報に応答してエンド・ユーザによる終了のための１つ又は複数のHTMLフォームをHTMLページに含むための手段を有することが望ましい。セッション状態情報もHTMLページに組み込み可能である。
サーバは、アプリケーション・プログラムから応答メッセージを受け取る前にプリセット期間が満了したことに応答して、WWWクライアント端末に通信（即ち、HTMLのページ）を送る。この通信はセッション識別子及び、望ましくは、セッション状態の識別子を含む。クライアントに返送された通信はそれの同期HTTPセッションを終了させ、WWWクライアントは最早中断されないが、ゲートウェイを有するクライアントの長い実行中の通信「セッション」は、WWWクライアント及びゲートウェイ・プログラムの間の対話の再開を可能にする情報が保持されるという点で論理的には依然として存在している。エンド・ユーザは、更なる期間のためにその中断状態に再入して新たな同期セッションを始動させるべきか否かを決定することができる。セッション識別子及び状態情報は、WWWページをキャッシュするためのWWWクライアントの機能を使用してWWWクライアント・システムのキャッシュ・メモリに記憶される。WWWクライアントは、このキャッシュされた情報を使用して初期の対話を再開し、アプリケーション・プログラムからの応答メッセージがサーバにおいて得られるかどうかをその後の或る時点でチェックすることができる。オリジナル・セッションと関連するサーバへのその後の要求にセッション識別子及びセッション状態情報を含むことによって、クライアントは、サーバが種々のセッション相互間を、及び同じアプリケーションの一部である種々の要求相互間を区別することを可能にする。
上述の本発明の実施例は、既知の手法に従ってHTMLメッセージ・フォーマットから非HTMLメッセージ・フォーマットへの変換を行う。呼び出されるアプリケーションがHTMLを解釈することができる場合、そのような変換は明らかに必要ない。
従って、望ましい実施例における本発明は、WWWの同期環境及びメッセージ・システムの非同期環境の間のリンクを提供する。本発明は、インターネットのサーバ・システムを介してアプリケーション・プログラムをコミュニケートするためのブラウザ・ソフトウエアの使用に同様に適用可能である。
【図面の簡単な説明】
第１図は、インターネットを介したクライアント・システムとサーバ・システムとの間の通信の概略的表示である。
第２図は、非同期メッセージング及びキューイングを使用したプログラム間通信の概略的表示である。
第３図は、本発明の実施例に従って、非同期的に接続されたウェブ・ブラウザと非同期通信に適応したアプリケーション・プログラムとの間の対話のためにサーバ・システム上にインストールされたゲートウェイ・プログラムを示す。
第４図は、本発明の第２実施例に従ってゲートウェイ、ブラウザ、及びアプリケーション・プログラムの間の相互協調処理を示す。
第５図は、本発明の実施例に従って、要求がウェブ・ブラウザ・プログラムから送られる時、主としてサーバ・システムにおけるゲートウェイ・プログラムによって遂行されるオペレーションを示す流れ図である。
発明を実施するための最良の形態
本発明は、種々の環境の間のリンクを必要とする多くの異なるデータ処理システム及び通信システムにおいて実現可能である。本発明は、特定のコンピュータ・ハードウエア又はアペレーティング・システム、或いは特定のタイプの通信リンクに限定されるものではなく、ハードウエア又はソフトウエアにおいて、又はハードウエア及びソフトウエア・コンポーネントの結合として実現可能である。
本発明の望ましい実施例は、非同期メッセージング及びキューイング環境と、ワールド・ワイド・ウェブの同期環境との間のリンクを提供するサーバ・システムのソフトウエア実装コンポーネントを含む。
第１図に示されるように、及び上で説明したように、インターネットのエンド・ユーザは、インターネット・アクセスを有するコンピュータ10及びそのコンピュータ上にインストールされたウェブ・ブラウザ・ソフトウエア20を具備している。ウェブ・サーバ・システム30は、インターネットに接続され、ウェブ・サーバ・ソフトウエア40（IBMインターネット接続サーバのようなソフトウエア）を走らせるコンピュータ・システムより成る（そのシステムは、例えば、Windows NTアペレーティング・システム・ソフトウエア又はUNIXアペレーティング・システム・ソフトウエアを走らせるものでよく、或いは、OS/2アペレーティング・システム・ソフトウエアを走らせるIBM PS/2 Model 80 コンピュータ、又はIBMのMVSアペレーティング・システムをサポートするメインフレーム・システムであってもよい）。なお、OS/2、MVS、及びPS/2はIBM社の商標である。ウェブ・サーバ・ソフトウエアはウェブ・ブラウザからのHTTP（ハイパーテキスト転送プロトコル）要求をサービスし、それらを静的HTMLページに対する要求として、又は実行可能なプログラムに対する要求として分析し、使用可能なHTMLページ（例えば、ディスク記憶装置に保持されたHTMLページ）をウェブ・ブラウザに送ることによって、或いはウェブ・サーバ・システム上で又は異なるシステム上で走らせてHTMLを発生させるためにプログラム50を呼び出すことによって応答する。プログラムは、共通ゲートウェイ・インターフェース（CGI）60又はウェブ・サーバによって実現される他のインターフェースを介してウェブ・サーバにより呼び出される（ほとんどのウェブ・サーバは２つのインターフェースをサポートし、そのうちの１つがCGIである）。
第２図は、IBMのMQSeriesプログラムのようなキュー・マネージャ・プログラムのネットワークの制御の下に非同期メッセージング及びキューイングを使用するプログラム間通信の簡略化した概略図である。キュー・マネージャは、アプリケーションによって使用されるメッセージ・キューイング機能を提供するシステム・サービスである。第２図に示されるように、システム110における第１アプリケーション・プログラム100は、ローカル・キュー・マネージャ・プログラム120及びリモート・システム160上で走る通信キュー・マネージャ130の制御の下でキュー140上にメッセージを入れるためのコマンドを発生する。その後、サービング・アプリケーション・プログラム150は、それがメッセージを処理する準備のできた時にキュー140からメッセージを取り出す。ビジネス・アプリケーションは、例えば、銀行の口座振替、又は航空機座席予約アプリケーションでよい。メッセージ・キューは、メッセージが蓄積される及びメッセージが後で取り出される名前付きオブジェクトである。
特定のキューの保全は、或る特定のキュー・マネージャの責任である。メッセージ・キューは単なるスタックではない。メッセージがキューに加えられる時、それらは最後尾に加えられる。メッセージがキューから取り出される時、それらは、通常、前から取り出される。メッセージ・キューの物理的表示は環境に依存するが、主記憶装置における１つ又は複数のバッファ、ディスク又は他の永続記憶装置における１つ又は複数のファイル、又はこれらの両方であってもよい。メッセージ・キューの物理的管理は全くキュー・マネージャ・プログラムの責任であり、そのような詳細はアプリケーション・プログラムにとって明らかにされない。アプリケーションは、単に、メッセージが蓄積される「ブラック・ボックス」として、メッセージ・キューを見なすことができる。アプリケーションは、メッセージ・キューイングAPIコールを使用することによってメッセージ・キューへのアクセスを行い、そのアプリケーションと同じシステム上にインストールされるキュー・マネージャ（即ち、ローカル・キュー・マネージャ）とコミュニケートする。
アプリケーション・プログラムは、特定の名前付きメッセージ・キューを使用することに同意することによってコミュニケートし、アプリケーション・プログラムが読み取ることを同意した特定のターゲット・キューにメッセージを送る。これらのキューのロケーションは、それらのメッセージを送るアプリケーションにとって可視的である必要はない。各ロケーションはそれのローカル・キュー・マネージャとのみ対話し、意図されたキューにそれらのメッセージを移動させる責任のあるのは相互接続されたキュー・マネージャのネットワークである。各キュー・マネージャは、ネットワークにおける他のキュー・マネージャを位置指定するためのローカル・ルーティング・テーブルを保全する。この方法では、アプリケーション・サポートのメッセージ・キューイング・ソフトウエアは、アプリケーション・プログラムに関する必要な複雑さのレベルを単純化し、それらがそれら自身の複雑な通信制御機能を実現する必要はないものにする。
本発明は、ローカル・システム上にインストールされたキュー・マネージャ・プログラムを持たないユーザに、相互接続されたキュー・マネージャのそのようなネットワークへのアクセスを提供する。本発明は、IBMのMQSeries製品のような既存のアプリケーション・イネーブリング・ミドルウエア・プログラムのサービスから利益を受け得る複雑な信頼性のあるWWWアプリケーションの開発のための環境を提供する。
ソフトウエアで実現されるリンク・コンポーネントは、同期的に接続されたエンド・ユーザの代わりにメッセージを発生及び受信するためにWWWサーバにおけるインストレーションを与えられる。以後、ゲートウェイ・プログラムと呼ばれるこのリンク・コンポーネントは前述のようにウェブ・ブラウザからの要求によって呼び出される。ゲートウェイ・プログラムは、例えば、標準CGI（共通ゲートウェイ・インターフェースを）介してWWWサーバとインターフェースする。ゲートウェイ・プログラムは、後述するように、複数のコンカレント・ユーザ及びそれらのステータスの管理を可能にし、同期HTTP及び非同期メッセージの間の相違を管理して、同期的に接続されたウェブ・ブラウザに、それがそのブラウザに代わって発生する非同期メッセージの進行に関する情報を提供する。又、ゲートウェイ・プログラムは、保証付き配送メッセージング・システムと非保証付きHTTP通信との間のリンクも管理する。アーキテクチャ及びハードウエア・プラットフォームが異なるとデータ表示及びパラメータも異なるので、データ変換（ASCII対EBCDICのような）が必要であるけれども、そのような変換はその分野では知られており、既知のメッセージング・ソフトウエア製品は変換を処理するので、ゲートウェイ・プログラムによって実現される必要はない。広範囲のセキュリティ機能は既知のメッセージ・ソフトウエア及びWWWサーバ（IBM社のセキュア・インターネット・サーバのような）において実現されているので、ゲートウェイ・プログラムがそのような機能を提供する必要もない。
第３図は、コンピュータ・システム230上にインストールされたメッセージ・キュー・マネージャ・プログラム210及びウェブ・サーバ・プログラム220の間をインターフェースするゲートウェイ・プログラム200を示す。そのゲートウェイ・プログラムは、この例において示されるように、サーバ・システム230以外の機械上でも動作し得るメッセージ・キューイング・アプリケーション・プログラム240とウェブ・サーバとの間をインターフェースするためにも使用可能である。この場合、サーバ・システムにおけるアプリケーション・プログラムは必要ない。メッセージ・キューイング・アプリケーションが走っているシステムは、インターネットを介して又は他の通信ネットワークを介してサーバ・システムに接続可能である。この例のアプリケーション・プログラムは、ウェブ・ブラウザ250からのHTMLフォーム・データを解釈することができ、それに応答してHTMLページを発生することができる。
第４図には、ウェブ・サーバ・システム上にインストールされたフォーマット変換アプリケーション・コンポーネント260と関連したゲートウェイ・・プログラムの同様の使用が示される。その変換コンポーネントはウェブ・ブラウザのHTML要求及び応答と、HTMLを解釈することができないアプリケーション・プログラム270の内部メッセージ構造との間で変換するように働く。従って、この変換コンポーネント260は、本発明によるゲートウェイ・プログラム200'が既存のメッセージキューイング・アプリケーションと共に使用されることを可能にする。サーバ・コンポーネントは、幾つものターゲット・アプリケーションに対する要求及びウェブ・ブラウザに対する応答を単一の作業単位において調整することもできる。HTML変換はその分野においてよく知られており、従って、ここでは更にこれを説明しないことにする。
第５図を参照して、ゲートウェイ・プログラム、及びウェブ・ブラウザと非同期アプリケーション・プログラムとの間の通信フローを説明することにする。ゲートウェイ・プログラムと関連する各メッセージ・キューイング・アプリケーション・プログラムに対して、１つ又は複数のアプリケーション入力キーが定義される。このアプリケーション及びそれの入力キーは、ウェブ・サーバ・マシン上に設けられるか又はメッセージ・キューイング・ミドルウエアのサポートを使用してサーバとの通信のために接続される任意のマシン上に設けられてもよい。ゲートウェイはサーバ上に応答キューを設けられる。この応答キューは、アプリケーション・プログラムから送られたメッセージをローカル・キュー・マネージャ・プログラムによって管理される。
ユーザは、それらが使用したいメッセージ・キューイング・アプリケーション又はサービスの名前を表すHTMLフィル・イン・フォームGET又はPOST要求を介してゲートウェイ・プログラムと対話する（ステップ300）。本発明の望ましい実施例では、その名前はアプリケーション・キュー・ネームを含むが、別の実施例では、これはアプリケーション・ネームに基づいてゲートウェイ・プログラムから取り出される。
ユーザがアプリケーションを呼び出すコマンドの例は次のようになる：
〈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 applecation"〉
〈/form〉
QNameは発生された非同期メッセージに対する宛先を指定するために必要であり、通常、アプリケーション自身によって識別される。QMNameは任意選択的なものである。それは、指定された場合、メッセージに対する宛先を指定するためにQNameと共に使用される。それが指定されない場合、ブランク・ネームが使用される。標準のメッセージング・システム・ネーム・リゾリューション規則が適用可能である。アプリケーション特有の文字フォーマット・データを含む更なるフィールドをフォーム要求に含めることが可能である。これらのフィールドは、ゲートウェイによって提供されたメッセージの形式でアプリケーションに送られる。
ユーザが行うアプリケーション・プログラムとの第１の対話（アプリケーション″エントリ・ポイント″）は、一般に、静的HTMLウェブ・ページから到来する。ユーザは特定のURLを参照解除するか、又はゲートウェイ・プログラムと対話するHTMLフォームを提供する（ステップ300）。ブラウザの初期HTML要求は組込のセッション識別子を含まない。ユーザがそのようなエントリ・ポイントを最初に通過し（即ち、既に存在するセッションに属しないHTML要求が送られ）、アプリケーションを開始する時、ゲートウェイ・プログラムは、そのゲートウェイ内の独特のセッション識別子によって識別されたセッションを構成して（ステップ340）ユーザ要求のアプリケーションとその要求のインスタンスとの結合を表す。セッション識別子は、各識別子がネットワーク全体に対して独特であることを保証するに十分なランダムネスをもって及び独特のサーバ識別を使用して発生可能であるが、これは本質的なことではない。既存のメッセージ・キュー・マネージャ・プログラム（IBM社のMQSeriesプログラムのようなプログラム）は独特の識別子を発生するための機能を有し、望ましい実施例のゲートウェイ・プログラムはこの機能を利用する。
ゲートウェイは、クライアント・システム又はユーザ識別情報と共にセッション識別情報をセッション・テーブル（例えば、OS/2又はAIXアペレーティング・システム・プログラムを走らせるサーバ・システムのクロス処理された共用メモリに保持されるメッセージ・キューにおけるエントリとして実現される）に加える（ステップ350）。なお、OS/2及びAIXはIBM社の商標である。このテーブルは、その後、後述のように、セッション識別子をユーザ要求及びアプリケーション・プログラム応答と関連付けるために使用される。この方法でアプリケーション・エントリ・ポイントを通過することによる以外にアプリケーションを開始させる手段はない。ユーザ対話は、わずか１つのセッションに属し得るだけである。
セッション識別子をユーザの対話に割り当ててしまうと、ゲートウェイ・プログラムはアプリケーション・プログラムの定義した入力キュー上にメッセージを入れ（ステップ360）、タイマを始動し（ステップ370）、アプリケーション・プログラムから応答メッセージを受けるためのプロセスを開始させる（ステップ370）。応答の受信に関しては後で説明することにする。メッセージは、要求したクライアント・プロセスとアプリケーション・プログラムとの間の通信全体におけるこの対話の位置を識別するシーケンス番号の形でステータス情報を含み、ユーザ又はクライアント・システムの識別子、並びにウェブ・ブラウザから供給された入力データを含む。このデータは、適切な文字セット及びコード・ページとしてアプリケーションに与えられる（その場合、前述のように、ゲートウェイ・プログラムとは別のサーバ・システム上のプロセスによって変換が遂行される）。メッセージのターゲットは、長時間動作のメッセージ・キューイング・アプリケーションであってもよく、又はそれの到着は、メッセージ・キューイング・アプリケーションをトリガして開始させるために使用可能である。上で説明したように、本発明は、「ウェブ認識」の（即ち、HTMLページを理解し、発生することができる）アプリケーション及びHTML変換を必要とするアプリケーションと共に使用するように実施可能である。本発明の実施例に関する以下の説明は、ウェブ認識アプリケーションとの対話の例に関するものである。
メッセージ・キューイング・アプリケーションは、受信したメッセージに応答してHTMLページをゲートウェイ・プログラムの応答キューに送らなければならない。前述のように、ゲートウェイ・プログラムは、これらの応答をそれのキューから取り出すためのプロセスを、それを受信した時に既に呼び出している。これは、相互協調処理メッセージ・キューイング・プログラムの既知の機能を使用して実施され、それによって、メッセージをキューから得るためのコマンドは、Getオペレーションが最初に試みられる時に応答が直ちには得られない場合、指定された期間を待つためのコマンドを任意選択的に含むことができる。IBM社のMQSeriesキュー・マネージャ製品では、この機能は、前に引用した文献［MQSeries−メッセージ・キュー・インターフェース・テクニカル・リファレンス」（IBMドキュメント番号SC−33−0850−01）に開示されているように、メッセージAPI取得（Get Message API）コマンドである「MQGET_Wait」に関するオプションとして呼び出される。従って、ゲートウェイ・プログラムはメッセージを送り、応答メッセージを検索するためにコマンドを発生し（ステップ370）、応答キューからHTMLページを検索してそれをゲートウェイに送る実際のメッセージ取得（Get Message）オペレーションを制御する状態にキュー・マネージャ・プログラムをしておく（ステップ420）。そこで、ゲートウェイ・プログラムは、現在のセッション識別子をHTMLにおける隠蔽フィールドとして含むHTMLページをブラウザに伝送する（ステップ420）。
応答メッセージがゲートウェイ・プログラムによって得られる前に「メッセージ取得」オペレーションの待機インターバルが期間満了する場合、「メッセージ取得」が戻り、ゲートウェイ・プログラムが反応して仮応答メッセージをブラウザに送る（ステップ390、400）。この仮応答は同期セッションを終了させるが、それはセッション識別子を含むので、セッションは後で「再始動」可能である（厳密には、新たなセッションが始動されるが、これは同じブラウザ及びゲートウェイ・プログラムの間の対話を必要とし、同じセッション識別子を参照するので、それをオリジナル・セッションの再始動と見ることができる）。応答が受信される前に、WWWブラウザとゲートウェイ接続されたWWWサーバ・プログラムとの間の同期セッションが別の方法で放棄される場合、ゲートウェイはすべての疑わしい「メッセージ取得」オペレーションを取り消す。タイムアウト後又はセッションの別の放棄後にゲートウェイ・プログラムの応答キュー上に入れられた如何なる応答メッセージも、WWWブラウザが関連の応答メッセージのサーチにおいてゲートウェイと再び対話するような時間まで、そこに残るであろう。そのようなその後のWWWブラウザ要求が受信される時、ゲートウェイ・プログラムは「メッセージ取得」オペレーションを（待機インターバルの時）再び呼び出すであろう。
そのセッション内にクライアントに送られたすべての通信はセッション識別子を含む必要があるということではないが、更なるクライアント対話が期待される時には、その識別子が含まれる。これは、一般的には、タイムアウト後に、又はアプリケーションの応答が得られる前に、通信が送られる時（ステップ400）、或いは、アプリケーション応答が受信され、その含まれたセッション状態情報が更なるクライアント対話の可能性を確認する時のような場合である。ゲートウェイ・プログラムは、一般に、ゲートウェイ・プログラムからの応答が受信された時、関連のセッションに対するセッション状態情報でもってそれのセッション・テーブルを更新する（ステップ420）。しかし、アプリケーションがクライアント・システムにおけるユーザ又はプロセスからのそれ以上の対話を必要としない場合（セッション状態情報によって、又はアプリケーション・プログラムからの応答におけるそれの欠如によって表されるように）、ゲートウェイ・プログラムは、それがページをブラウザに送る時、すべてのセッション特有の資源を保留解除する（ステップ420）。
現在のアプリケーション・プログラムが更なるクライアント情報を「期待し」又は必要とす時（即ち、アプリケーション全体が終了する前に現在のアプリケーション・プログラム又は他のアプリケーション・プログラムと対話することをクライアントが期待している時）、それは、サーバに対するそれの応答におけるフラッグによってこれを表す。それは、動的に作成されたHTMLフォームの各々に組み込まれたセッション識別子と共にクライアントに送られるHTMLページ内に更なるHTMLフォームも含む。
ウェブ・ブラウザはページをキャッシュするための機能を有し（ステップ410）、従って、組み込まれたセッション識別子を記憶することができる。これは、単一のユーザが複数のオープン・セッションを持つことを可能にする。これらのセッションはネスト可能であり、或いは相互にオーバラップ可能である。セッション識別子を含むフォームがブラウザにおいて実質的に満たされる時（ステップ300）、サーバにおけるゲートウェイ・プログラムがその後受信したフォームを正しいセッションと関連付けることができるように（ステップ320、330）、セッション識別子はサーバにおけるゲートウェイ・プログラムに戻るであろう。セッション識別子はその要求を他のユーザからの他の要求から区別するために、及び異なるアプリケーションに対する同じユーザからの他の要求から区別するために使用される。ゲートウェイ・プログラムの一部であるプロセスが、テーブル・エントリと、受信した要求のセッション識別子及びセッション状態情報との間の対応を求めてセッション・テーブルをスキャンする（ステップ320）。セッション及びステータス情報がアプリケーションとの既存の対話に対応しない場合、ゲートウェイは、前述のように、ステータス情報及び入力データをアプリケーション入力キューにおけるメッセージとして扱う（ステップ360）。しかし、受信した要求のセッション及び状態情報とセッション・テーブルにおけるエントリとの比較で一致が見つかった場合、これは初期の要求の再試行でなければならず、従って、応答は既に得られているかもしれない。前に送られたメッセージの確実な１回だけの配送を行うためには関連のキュー・マネージャに依存することになるので、新しいメッセージがアプリケーションに送られる必要はない。ゲートウェイ・プログラムは、期待された応答メッセージに関してそれの応答キューをチェックするために、「待機を伴う取得（Get with Wait）」オペレーションを呼び出す（ステップ370）。
ブラウザに戻されそしてそこに記憶されるセッション識別子をユーザ対話に割り当てることは、多くの技術的問題を解決するものである。第１の、それは、ゲートウェイが受信する複数の応答をそのゲートウェイが区別することができる場合、複数のユーザが同時に同じアプリケーション又はサービスをアクセスすることを可能にする。第２に、それは、アプリケーションの長期実行の会話に関する複数の要求応答の対を一緒に関連付けるために、十分なコンテキスト情報が、各ユーザによって各サーバ・アプリケーションに対して発生される連続した要求の間で持ち越されることを保証する。第３に、それは、幾つもの異なるアプリケーションとの対話を区別するための機構を設けることによって、ユーザがそれらの対話をインターリーブすることを可能にする。第４に、それは、恐らく、サーバ又はゲートウェイ・プログラムに如何なる通知も与えることなく、ユーザが任意の段階でアプリケーションを放棄する可能性を与え、ユーザ及びサーバの間のリンクの可能性を処理する。
動的に作成されたHTMLは、セッション識別子を含む他に、現在のセッションにおける対話の位置を識別するシーケンス番号を含む。これは次のブラウザ要求によってゲートウェイ・プログラムに戻され、ゲートウェイ・プログラムは期待された値に対比してそれをチェックするであろう（ステップ320）。表にされたセッション識別子及びシーケンス番号を使用してデータ及び実行ステータス・コンテキストを維持するこの機構は、相互に依存したクライアント要求のシーケンスの遂行を可能にする。同じセッション内の複数のメッセージ相互間を区別するために、サービス・アプリケーションが可能にされる。
次のような方法の１つでセッションを終了させることが可能である：
◯ 要求される更なるユーザ入力がないことをサーバ・アプリケーションがそれの応答メッセージにおいて表示し、ゲートウェイが、セッション特有の資源を保留解除することによって応答する（ステップ420）。
◯ フォームを含むHTMLページがユーザに送られるが、フィル・インされず、アドミニストレータ定義の期間内に戻される。ユーザからの応答を期待していたサービング・アプリケーションにゲートウェイが終了メッセージを送る（終了していないサービング・アプリケーションの不必要な保全を回避する）。
◯ サービング・アプリケーションが受容可能な時間内にメッセージに応答しようとしない時、ユーザがゲートウェイ・プログラムとの会話を通してアプリケーションを放棄することを選ぶ。ゲートウェイ・プログラムは、それが送ったメッセージを検索しようとする。それができない場合、それは取消メッセージをサービング・アプリケーション・プログラムに送る。
セッション終了は、ゲートウェイ・プログラム及びサービング・アプリケーションが割り振ったすべてのセッション特有の資源をそれらが保留解除することを可能にする。セッション識別子は、セッションが終了した後、それがユーザ又はサービング・アプリケーションからゲートウェイ・プログラムに送られる場合、拒絶されるであろう（即ち、拒絶通知以外の更なる通信をトリガしないであろう）。サーバ制御されたタイムアウト期間は、クライアント・プロセスが中断されたままになっている期間を決定するが、セッションを自動的には終了させないことに注意してほしい。従って、そのようなタイムアウトの後、ゲートウェイ・プログラムは、依然として、セッション識別子及びステータス情報を維持する。
ゲートウェイ・プログラムからのメッセージがアプリケーション入力キューに配送されこと、及び応答ゲートウェイ・プログラムに戻されることを保証するための機能を有するメッセージ・キュー・マネージャ・プログラムが知られている。しかし、メッセージ・キュー・マネージャ・プログラムは、通信リンクが特定の時間に機能していること及びアプリケーションそのものがブラウザからの要求を処理するために走ることを保証することはできない。キュー・マネージャ・プログラムは、キュー・マネージャのネットワークに接続するウェブ・ブラウザに確実な配送を提供することができない。前述のように、ゲートウェイ・プログラムは、到来するウェブ・ブラウザ要求に応答してサーバ・アプリケーションの入力キュー上にメッセージを送る。メッセージが最初にそのキュー上に入れられる時、ゲートウェイ・プログラムはカウント・ダウン・タイマを始動させ（ステップ370）、サーバ・アプリケーションからの応答を待つ。アプリケーション・プログラムからのいずれの応答が受信される前にもタイマが期間満了した場合、ゲートウェイ・プログラムはHTMLページを作成して（ステップ390）、その期間満了をユーザに通知する（ステップ400）。
従って、ゲートウェイ・プログラムは、システム・アドミニストレータ定義の期間満了時にそれがアプリケーションからの応答を受けなかった場合、それ自身の応答をブラウザに送るように構成される。設定されるべき最大のクライアント中断期間は関連のアプリケーションに依存するであろう（10秒又は１秒が適当であろう）。この応答の主たる目的は、現在の通信セッションを維持して応答を待つべきか、又はセッションを停止して（しかし、そのセッションと関連して情報を保全して）他の作業を進めるべきかの決定を可能にするための情報をクライアント・システムにおけるユーザ又は通信プロセスに提供することである。クライアントに対するこの応答は単にエンド・ユーザへのプロンプト指示であってもよいが、本発明の望ましい実施例によれば、ブラウザに対するタイマ・トリガされた応答は、要求がターゲット・マシンによって受信されたかどうか及びアプリケーションが要求を読み取ったかどうかも表示する。到着時の確認（Confirm On Arrival）及び配送時の確認（Confirm On Delivery）のレポートを行うメッセージ・キュー・マネージャ・プログラムが知られている。望ましい実施例によるゲートウェイ・プログラムは、それのタイマ期間満了通知がそのセッションに対する通信の進行に関して得られた情報すべてを含むように、利用可能なレポート機能を使用してその通知を構成すべく適応する。
ゲートウェイがクライアント・システムから要求を受信したということの即時確認として仮応答を行うことは本発明の技術的範囲内である。この確認は、現在の同期セッションを終了させるであろうが、セッション識別子を含むであろうし、従って、クライアントが後でその対話を再開することを可能にする。この場合、クライアント・プロセスは非同期的に要求されたプログラムからの応答を待つために中断されないであろうけれども、通信リンク又はコミュニケートするシステム自体による問題のために、要求と受信の確認との間の遅れの可能性が残っている。確認が受信されるものではない場合、クライアント要求が放棄されなければならない時を自動化するためにクライアントのタイムアウト期間が使用されてもよいが、或るアプリケーションにとっては、クライアント要求を放棄すべき時の決定は、既存のウェブ・ブラウザ・ソフトウエアのユーザにとっては馴染み深いものであるとしてエンド・ユーザに決定させることが可能である。
クライアント・システムからの受信した要求の「タイプ」に応答して即時仮応答が必要であるかどうかを、或いは、完全応答が得られる場合、セットされた中断又はタイムアウト期間がその期間内に完全応答を供給する目的で使用されるべきかどうかを決定するプロセスをゲートウェイ・プログラム内に設けることも、本発明の技術的範囲である。本発明の特定の実施例によれば、ゲートウェイ・プログラムは、それがデフォルトによって使用する構成可能なタイムアウト値を有する。この値は、ゲートウェイ・プログラムがインストールされるサーバ・システム上の構成ファイルに保持され、ゲートウェイ・プログラムがインストールされる時にセット可能であり、その後、システム・アドミニストレータによって修正可能である。このデフォルト値をオーバライドする任意選択のパラメータがHTMLフォーム要求（QName及びQMNameパラメータと同様のもの）に含まれてもよい。前に参照した例を使用すると、要求の受信を確認する即時応答を必要とする商品注文に適するようにHTMLフォームを設計する場合、小さいタイムアウト値がその要求フォームにおいてコード化されるであろう。一方、そのような即時確認を必要としない銀行残高に関する情報を要求する場合、大きい値（恐らく、ユーザが許容することを期待される最長の待ち期間に対応した値）がコード化されるであろう。
メッセージの確実な配送を行うためのメッセージ伝送プロトコルは、国際特許出願WO 95/10805及び英国特許出願番号9606183.3の未決出願に開示されている。一般に、基本ネットワーク・サポートは、信頼性の低い通信媒体を介した機械相互間における信頼し得るパケット配送を保証するけれども、それは、通常、確実な配送を行うことはできない。データは１回、しかも１回だけしか送られないこと、及び主要な機械又はネットワークの障害の後に通信が適正に再始動及び回復するであろうということを保証するために、パケット配送のための基本ネットワーク・サポート以上のものが要求される。特に、確実な配送システムにおける両パートナは、どのデータがうまく伝送され、「ハード化」されたかを覚えておかなければならない。ハード化するということは、ディスクのような記憶媒体にデータを書き込み、たとえハードウエア障害があってもそれが回復可能であることを保証するステップである。メッセージ・キューイング・システムにおける資源回復の対策が、McGraw−Hill社発行（1994年）のB.Blakeley,H.Harris及びR.Lewis著の「MQIを使用したメッセージング及びキューイング（Messaging and Queuing Using the MQI）」と題した文献の209乃至217ページに詳しく開示されている。
ビジネス・アプリケーションは、トランザクション的な方法で調整される必要のあるアクティビティを持った幾つものサービス・アプリケーションを伴い得るものである。この問題は、サーバ・システムにおけるメッセージ・キュー・マネージャ・プログラムによって解決される。
ゲートウェイ・プログラムは、単一の制御メッセージ・キューイング・アプリケーション・プログラムにメッセージを送り、そのメッセージ・キューイング・アプリケーション・プログラムは、必要な場合には、それを個々のサービング・アプリケーションに対する個別の要求に分解する。これらのメッセージは送られ、メッセージ・キュー・マネージャ・プログラムによるトランザクション制御の下に再結合される。そのようなトランザクション制御を行う機能を持ったメッセージング・プログラムはその分野では知られている（例えば、IBM社のMQSeriesのメッセージング・プログラムである）。
ゲートウェイ・プログラムの設計は、増大した要求に対処するために、エクストラ・サービング・アプリケーションが付加されることを可能にする。即ち、本発明の望ましい実施例による解決方法は変動可能である。これは、ゲートウェイ・プログラムが各非同期メッセージのメッセージ・デスクリプタ部分においてセッション識別子を含むことによって達成される（メッセージ・デスクリプタは、そのメッセージの特性を定義する情報、及びメッセージを処理すべき方法を決定するためにどれがメッセージ・キューイング・サービスによって使用されるかを定義する情報を含む。メッセージそのものは２つの異なるコンポーネント、即ち、アプリケーション・データ部分及びそのアプリケーション・データに付随したメッセージ・デスクリプタ情報を含むメッセージ・ヘッダ部分を含む）。これは、複数のサービング・アプリケーション・プログラムを単一の作業キューに対して並行して走らせることを可能にする。アプリケーションが連続した対話の間にそれ自身のコンテキスト・メッセージを保持する必要がある場合、それは、それのセッション識別子に符号したメッセージを検索することができる。それがコンテキスト情報を維持しない場合、サービング・アプリケーションのインスタンスは検索を行い、それらが見つけた第１メッセージを処理することができる。
従って、望ましい実施例による本発明は、既存のウェブ・ブラウザの修正を必要とすることなく、汎用のメッセージング・システムとインターネットWWWサービスとのリンクを容易にするが、本発明はこの実施方法に限定されるものではない。本発明は、任意の２つのデータ処理システムにおける一方のシステム上にインストールされたコンピュータ・プログラムが同期通信を必要とし、他方のシステムにおけるプログラムが非同期形式の通信を必要とする場合のそれら２つのデータ処理システムの間のリンクを提供するように実施可能である。IBM社のMQSeries製品のようなメッセージング・ソフトウエアに関連した望ましい実施方法による場合の本発明は、MQSeriesがTCP/IP、APPC、及びNetBIOS通信プロトコルをサポートするので、インターネット・プロトコル（IP）をサポートしないネットワークに対するブリッジを提供する。従って、本発明は、IPネットワーク及び非IPネットワークにおけるアプリケーション相互間の通信を容易にする。
上記の望ましい実施例は、メッセージング・システムと関連した別々にインストール可能なゲートウェイ・プログラムを含む。別の実施例は、ゲートウェイをキュー・マネージャ・プログラムの内部コンポーネントとして実施する。セッション識別子及びセッション状態テーブルは、キュー・マネージャの制御の下にメッセージ・キューとして実施されることが望ましい。MQSeriesキュー・マネージャにおいて既に実施されているMessageID識別子及びCore1ID識別子は、キューをスキャンする時に適当なサーチ情報として使用可能である。しかし、エントリがキュー・マネージャ制御されたキュー上に残っている間にエントリを修正するための対策はないので、キュー・マネージャ制御されたキューに保持されたエントリの更新は、キューからのそれらエントリの除去、修正、及びその後のそのキューにおける置換というステップを必要とする。共用メモリに保持されたテーブルにおけるエントリの更新は、以前のエントリを単に上書きすることを必要とするだけである。「事象待ち（即ち、応答）又はタイム・アウト（wait for event or timeout）」オペレーションに対するメッセージ・キュー・マネージャ・プログラムの機能を利用することには利点があるけれども、この機能は、一般に、マルチ・スレッド・アペレーティング・システムによって与えられ、メッセージ・キュー・マネージャ・プログラムは、実際には、基礎的なアペレーティング・システムの機能を利用するものでもよい。別の実施例は、新たな応答メッセージが最初に応答キュー上に入れられる時、ゲートウェイ・プログラムのトリガを使用することができるが、クライアント・システムによる現在生きているセッションがない時のトリガは望ましくないので、これは望ましい実施方法ではない。本発明の更に別の実施例は、「待機を伴う取得（Get with Wait）」オペレーションを呼び出す代わりに新たな応答メッセージに対する応答キューの周期的スキャンを実施してもよい。
上記の望ましい実施例では、セッション識別子はウェブ・ブラウザのキャッシュ記憶装置に（HTMLページにおける組込フィールドとして）自動的に記憶される。しかし、別の方法として、セッション識別子はディスプレイ・スクリーンを通してエンド・ユーザに表示可能であり、その後の関連要求を行う時、セッション識別子内にタイプすることを要求されることがある。タイムアウト後のクライアント・システムに対する仮応答が自動的記憶又は将来の要求における自動的包含なしに単にユーザに表示されるという実施例では、現在のセッションが維持されるべきか、或いは識別子がその後の要求の再試行のために記憶される場合にそのセッションが終了させられるべきかを決定するのはユーザである。上記の実施例も、ブラウザに返送された或る通信内にセッション識別子及びセッション状態情報だけが含まれるという特徴を有するが、明らかに本発明の技術的範囲内にある代替方法は、すべての応答内に少なくともセッション識別子情報を含むことを伴う。
上記の望ましい実施例の特徴はゲートウェイ・プログラムによる状態データの保全である。本発明の別の実施例は、ゲートウェイ・プログラムがセッション状態情報の保全を伴わないようにアプリケーション・プログラムが処理するというシーケンス問題をすべてそのまま残している。

Claims (11)

1. 通信ネットワークのためのデータ通信サーバ・システムにして、前記サーバ・システムは、前記サーバ・システムと前記ネットワークのクライアント・システムとの間の同期通信をサポートするための機能と、前記サーバ・システム上のプログラム又は前記ネットワークの他のシステム上のプログラムとの非同期通信をサポートするための機能とを有し、更に、前記サーバ・システムは、
   前記クライアント・システム及び前記サーバ・システムの間の同期通信セッションにおける前記クライアント・システムからの要求に応じて、前記サーバ・システム上のプログラム又は前記ネットワークの他のシステム上のプログラムに要求を非同期通信要求として送るための手段と、
   前記クライアント・システムからの前記要求に応じて、タイマを始動するための手段と、
   前記非同期通信要求に対する応答を前記プログラムから受信したことに応じて、前記クライアント・システムからの前記要求に当該受信された応答を関連付けることにより、前記クライアント・システムに応答が送られることを可能にするための手段と、
   前記非同期通信要求に対する応答を受信する前に、前記サーバ・システムによって割り当てられたセッション識別子を含む仮応答を発生するための手段と、
   前記非同期通信要求に対する応答が受信される前にプリセット期間が満了する場合、前記同期通信セッションにおいて前記仮応答を前記クライアント・システムに送るための手段と、
   前記同期通信セッションにおいて前記クライアント・システムに応答を送るための手段とを有し、
   当該応答を送るための手段は、プリセット期間の満了前の前期非同期通信要求に対する応答の受信に応じて、前記同期通信セッションにおいて前記クライアント・システムに対する応答内に前記受信された応答からの情報を含める、データ通信サーバ・システム。
2. 前記クライアント・システムからの前記要求にセッション識別子を割り当てるとともに、当該セッション識別子を前記非同期通信要求内に含めるためのプロセスと、
   前記非同期通信要求に対する応答にして、前記セッション識別子を含む応答を前記プログラムから受信したことに応じて、当該受信された応答を前記クライアント・システムからの前記要求と関連付けるために前記セッション識別子を使用するとともに、前記クライアント・システムに送られる応答内に前記セッション識別子を含めるための手段とを有する、請求の範囲第１項に記載のデータ通信サーバ・システム。
3. 前記非同期通信要求に対する前記プログラムの応答内に含まれたセッション状態情報に応じて、前記クライアント・システムに送られる前記応答内にセッション状態情報を含めるための手段を有する、請求の範囲第２項に記載のデータ通信サーバ・システム。
4. 前記サーバ・システムは、前記クライアント・システム上にインストールされたインターネット・ワールド・ワイド・ウェブ（WWW）ブラウザ・ソフトウェアからの要求に応答するためのWWWサーバ・ソフトウェアをインストールされ、前記クライアント・システムに送られる応答に含まれるHTMLページ内にセッション識別子情報を組み込むための手段を有する、請求の範囲第２項に記載のデータ通信サーバ・システム。
5. 前記サーバ・システムは、前記非同期通信要求に対する前記プログラムの応答内に含まれたセッション状態情報に応じて、エンド・ユーザによる完了のための前記セッション識別子を組み込まれた１つ又は複数のHTMLフォームを前記HTMLページ内に含めるための手段を有する、請求の範囲第４項に記載のデータ通信サーバ・システム。
6. 前記サーバ・システムは、前記非同期通信要求に対する前記プログラムの応答内に含まれたセッション状態情報に応じて、前記クライアント・システムに送られる前記HTMLページ内にセッション状態情報を組み込むための手段を有する、請求の範囲第４項又は第５項に記載のデータ通信サーバ・システム。
7. クライアント要求のHTMLデータを前記プログラムによって解釈可能なフォーマットに変換するための手段及び前記クライアント・システムに対する応答内に含めるために前記プログラムからの応答内に含まれた情報をHTMLに変換するための手段を有する、請求の範囲第４項又は第５項に記載のデータ通信サーバ・システム。
8. 前記サーバ・システムは、到着時の確認（COA）又は配送時の確認（COD）のレポートを行い、前記プリセット期間が満了する前のCOA又はCODのレポートの受信に応じて、前記プリセット期間の満了時に前記クライアント・システムに送られる前記仮応答内に前記COA又はCODのレポートを含める、請求の範囲第１項に記載のデータ通信サーバ・システム。
9. 前記サーバ・システムは、前記セッション状態の識別が前記非同期通信要求に対する前記プログラムの応答内に含まれることに応じて、前記クライアント・システムに対する前記応答内にセッション識別情報を含めるべきかどうかを決定するための手段を有する、請求の範囲第１項に記載のデータ通信サーバ・システム。
10. 前記クライアント・システムに対する応答内にセッション状態情報を含めるための手段は前記セッション状態に従って前記セッション状態情報を含めるべきかどうかを決定するための手段を有する、請求の範囲第３項に記載のデータ通信サーバ・システム。
11. 前記クライアント・システムからの前記要求に応じて、受信の確認が前記仮応答として前記クライアント・システムに送られるべきか又は前記タイマが始動されるべきかを決定するための手段を有する、請求の範囲第１項に記載のデータ通信サーバ・システム。

Images