JP2009519531A - マクロ・サポートによりｈｔｔｐセキュリティ・メッセージ処理を外部化するための方法およびシステム - Google Patents

Abstract

【課題】
データ処理システムにおいてメッセージ処理を外部化するための方法を提供する。
【解決手段】
第１サーバにおいて、リソースをアクセスする要求がクライアントから受け取られる。要求の処理はメッセージがクライアントに送られることを必要とする、という第１サーバにおける決定に応答して、メッセージがクライアントに送られるために、第２サーバにおけるメッセージ処理機能に対応したオペレ-ション・コードを含むリダイレクト・メッセージが生成される。評価されたマクロを決定するために、評価可能マクロが評価され、その評価されたマクロがリダイレクト・メッセージに挿入される。しかる後、リダイレクト・メッセージがクライアントを介して第１サーバから第２サーバに送られる。第２のサーバがリダイレクト・メッセージからオペレ-ションコードを取り出し、その取り出されたオペレ-ションコードに対応するメッセージ処理機能を起動する。第２のサーバがリダイレクト・メッセージからその評価されたマクロを取り出し、その評価されたマクロをメッセージ処理機能に対する入力パラメーターとして第２のサーバにおいてを使用する。
【選択図】 図５

Description

本発明は、データ処理システムの改良に関し、マルチコンピュータのデータ転送のための方法および装置に関する。

電子商取引ウェブサイトおよびウェブ・アプリケーションは、ユーザに代わってコンピュータ・ネットワークを介して取引を行う。企業は、一般に、インターネットを含む様々なネットワークを通してユーザ・フレンドリな方法で許可ユーザに保護されたリソースへの安全なアクセスを提供することを望んでいる。電子商取引のウェブ・ベースの環境では、コンピュータ・システムは、多くの場合、ウェブサイトをアクセスするためのフロント・ドアまたはセントリ・ゲート（sentry gate）の形で認証業務を実施している。ユーザは、多くの場合、セキュリティ目的のための適正なレベルの確度に合うようユーザの身元を証明するためには認証手続きを通らなければならない。これらの認証業務は、ユーザがいずれかのリソースへのアクセスを得る前に認証されることを保証するために、申請の前に、即ち、ユーザと申請との間に位置する。これらの認証業務は、ウェブサーバ・プラグイン、リバース・プロキシ、或いは他の同様の技術として具現化することが可能である。企業は、標準のウェブ・ブラウザを操作する所定の装置に加えて、特殊のライトウェイト・ブラウザを備えたウェブをブラウズする携帯電話、ＰＤＡ(Portable Digital Assistant)等のようなモバイル装置を含む様々なクライアントをサポートすることを望んでいる。

しかし、プロキシ・コンポーネントにおける或る実装上の制約は、いずれの所与のインストールにおいても複数の異なる装置のサポートを禁じている。その問題は、ログインを必要とするユーザに通知するメッセージまたは或るタイプのエラー・メッセージのようなセキュリティ関連イベントに関する情報がクライアントに送られる必要があるとき、プロキシ・サーバ自身から供給される静的コンテンツに集中している。例えば、ユーザは、企業のイントラネットを介してコンテンツをアクセスするためにＰＤＡを使用することを望むことがあるが、イントラネット介してコンテンツはすべてプロキシ・サーバによって保護されている。ユーザが、ログオン操作を必要とするリンクをクリックするとき、プロキシ・サーバは静的ログインＨＴＭＬ(HyperTextMarkup Language)形式をＰＤＡに戻すことがある。残念ながら、ＰＤＡにおけるブラウザは、既にモバイルの装置に適合しているコンテンツを扱うことしかできないことがあり、ＰＤＡは、ＨＴＭＬ形式全体またはそれの或る部分を処理することができないことがある。従って、ユーザはイントラネットに対してログオンすることができない。

種々の装置にとって適正なコンテンツという問題に対処するために、下記のような解決策または次善の策が提案されている。上記のログオン問題に関して、ログオン形式、およびプロキシ・サーバによって供給される他の静的な形式は、モバイル装置用にエンコードされるページへのリダイレクト、または、ターゲット装置におけるブラウザのタイプを識別してそのターゲット装置にとって適正なコンテンツを生成し得るサーブレットへのリダイレクト、と共に「メタ」タグを含むことができる。残念ながら、ほとんどのモバイルの装置を含む多くの装置が「メタ」・リダイレクト・タグをサポートしていない。

もう１つの解決策または次善の策は、サポートされたクライアント装置の各タイプに対して１つずつ存在するような複数のプロキシ・サーバを操作することであろう。この解決策は、多くの場合、種々の装置のための「チャネル」をサポートするものとして説明されている。残念ながら、この解決策は、顧客、即ち、ウェブサイトを操作している企業に対して不合理なリソースおよび管理上の要件を設けている。更に、この解決策は、顧客にインフラストラクチャを販売しようとする業務上のパートナによって提案されるとき、顧客にとって不合理であるように見えることがある。

第３の解決策は、ＨＴＭＬを所与の装置にとって適切なフォーマットにするトランスコーディング・サーバをプロキシ・サーバの前に置くことであろう。しかし、そのトランスコーダは顧客の計算上のＤＭＺ(DeMilitarized Zone)に配備されなければならず、しかも、ＤＭＺは、セキュリティ問題の対処に専用化され且つ、通常、セキュリティの脆弱性を導く可能性のためにコンテンツ関連の機能に欠ける、データ処理システムの部分であるので、顧客はこれを機密漏れと見なしている。従って、トランスコーディング解決策はほとんどの顧客にとって受入れ難い。

更に別の解決策は、種々のコンテンツ・ページを種々のクライアント・タイプに直接送ることであろう。ほぼすべてのＨＴＴＰクライアントは、クライアント・タイプと、クライアントによって理解されるデータ・タイプとを識別する少量の情報を各要求において送る。例えば、ＷＡＰ（Wireless ApplicationProtocol）イネーブルド・モバイル電話は、ＷＭＬ（Wireless Markup Language）ドキュメントを変える方法を知っていることを示すために、「application/vnd.wap.wml」を含む「受諾」ヘッダを送るであろうし、一方、ｉモード（商標）電話は、それがコンパクトＨＴＭＬドキュメントを好むことを示すために「text/chtml」の「受諾」ヘッダを送るであろう。プロキシ・サーバは、種々のＨＴＴＰヘッダのコンテンツに基づいて、種々のクライアント・タイプが種々の種類のドキュメントを直接受け取るように構成され得る。しかし、ワイヤレス装置およびプロトコルの急速に拡大する多様性がこの解決策を管理的には非実用的なものにするので、この解決策は問題である。特定のベンダの装置がサポートされるということを保証するために、更新は恒常的に必要とされるであろう。

本発明は、データ処理システムにおいてメッセージ処理を外部化するためにコンピュータを利用する方法、コンピュータ・プログラム、および装置を提供する。

本発明の第１の局面である方法は、第１サーバにおいて、リソースをアクセスする要求をクライアントから受け取るステップと、前記要求の処理はメッセージが前記クライアントに送られることを必要とする、という前記第１サーバにおける決定に応答して、前記メッセージを前記クライアントに送るために第２サーバにおけるメッセージ処理機能に対応したオペレーション・コードを含むリダイレクト・メッセージを生成するステップと、評価されたマクロを決定するために構成可能マクロを評価するステップと、前記評価されたマクロを前記リダイレクト・メッセージに挿入するステップと、前記クライアントを介して前記リダイレクト・メッセージを前記第１サーバから前記第２サーバに送るステップと、を含む。

メッセージを受け取る装置のタイプによってメッセージのコンテンツが処理されるようにセキュリティ関連イベントに対するメッセージを提供する方法および装置が提供されることが望ましい。

本発明の第２の局面であるコンピュータ・プログラムは、メッセージ処理を外部化するためにデータ処理システムにおいて使用するための、コンピュータ可読記憶媒体におけるコンピュータ・プログラムである。そのコンピュータ・プログラムは、第１サーバにおいて、リソースをアクセスする要求をクライアントから受け取る機能と、前記要求の処理はメッセージが前記クライアントに送られることを必要とする、という前記第１サーバにおける決定に応答して、前記メッセージを前記クライアントに送るために第２サーバにおけるメッセージ処理機能に対応したオペレーション・コードを含むリダイレクト・メッセージを生成する機能と、評価されたマクロを決定するために構成可能マクロを評価する機能と、前記評価されたマクロを前記リダイレクト・メッセージに挿入する機能と、前記クライアントを介して前記リダイレクト・メッセージを前記第１サーバから前記第２サーバに送る機能と、を含む。

本発明の第３の局面である装置は、データ処理システムにおいてメッセージ処理を外部化するための装置である。その装置は、第１サーバにおいて、リソースをアクセスする要求をクライアントから受け取るための手段と、前記要求の処理はメッセージが前記クライアントに送られることを必要とする、という前記第１サーバにおける決定に応答して、前記メッセージを前記クライアントに送るための第２サーバにおけるメッセージ処理機能に対応したオペレーション・コードを含むリダイレクト・メッセージを生成するための手段と、評価されたマクロを決定するために構成可能マクロを評価するための手段と、前記評価されたマクロを前記リダイレクト・メッセージに挿入するための手段と、前記クライアントを介して前記リダイレクト・メッセージを前記第１サーバから前記第２サーバに送るための手段と、を含む。

本発明の好適な実施例によれば、データ処理システムにおいてメッセージ処理を外部化するための方法が提供される。第１サーバにおいて、リソースをアクセスする要求がクライアントから受け取られる。要求の処理はメッセージがクライアントに送られることを必要とする、という第１サーバにおける決定に応答して、メッセージがクライアントに送られるために、第２サーバにおけるメッセージ処理機能に対応したオペレ-ション・コードを含むリダイレクト・メッセージが生成される。評価されたマクロを決定するために、評価可能マクロが評価され、その評価されたマクロがリダイレクト・メッセージに挿入される。しかる後、リダイレクト・メッセージがクライアントを介して第１サーバから第２サーバに送られる。第２のサーバがリダイレクト・メッセージからオペレ-ションコードを取り出し、その取り出されたオペレ-ションコードに対応するメッセージ処理機能を起動する。第２のサーバがリダイレクト・メッセージからその評価されたマクロを取り出し、その評価されたマクロをメッセージ処理機能に対する入力パラメータとして第２のサーバにおいてを使用する。

一般に、本発明を含み得る装置或いは本発明に関連し得る装置は広範な種々のデータ処理技術を含んでいる。従って、背景として、本発明を詳細に説明する前に、分散型データ処理システムにおけるハードウェアおよびソフトウェア・コンポーネントの典型的な構成を説明することにする。

次に図面を参照すると、図１は、各々が本発明の一部分を具現化し得る複数のデータ処理システムの典型的なネットワークを示す。分散型データ処理システム１００はネットワーク１０１を含み、そのネットワークは、分散型データ処理システム１００内で相互接続された種々の装置およびコンピュータ間の通信リンクを提供するために使用し得る媒体である。ネットワーク１０１は、ワイヤまたは光ファイバ・ケーブルのような永続的接続或いは電話または無線通信を介して行われる一時的接続を含み得る。図示の例では、サーバ１０２およびサーバ１０３が記憶ユニット１０４と共にネットワーク１０１に接続される。更に、クライアント１０５〜１０７もネットワーク１０１に接続される。クライアント１０５〜１０７およびサーバ１０２〜１０３は、メインフレーム、パーソナル・コンピュータ、パーソナル・デジタル・アシスタント（ＰＤＡ）等のような種々のコンピューティング装置によって代表され得る。分散型データ処理システム１００は、更なるサーバ、クライアント、ルータ、他の装置、および図示されていないピア・ツー・ピア・アーキテクチャを含み得る。

図示の例では、分散型データ処理システム１００は、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）、トランスポート・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）、ファイル・トランファ・プロトコル（ＦＴＰ）、ハイパーテキスト・トランスポート・プロトコル（ＨＴＴＰ）、ワイヤレス・アプリケーション・プロトコルなど（ＷＡＰ）等のような種々のプロトコルを相互に通信するために使用するネットワークおよびゲートウェイの世界的な集合体を表わすネットワーク１０１を備えたインターネットを含み得る。もちろん、分散型データ処理システム１００は、例えば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、または広域ネットワーク（ＷＡＮ）のような多くの種々のタイプのネットワークを含み得る。例えば、無線通信リンクを組込んだサーバ１０２がクライアント１０９およびネットワーク１１０を直接サポートする。ネットワーク使用可能電話１１１が無線リンク１１２を介してネットワーク１１０に接続し、ＰＤＡ１１３が無線リンク１１４を介してネットワーク１１０に接続する。電話１１１およびＰＤＡ１１３は、いわゆるパーソナル・エリア・ネットワーク（ＰＡＮ）またはパーソナル・アドホック・ネットワークを形成するようにBluetooth（商標）無線技術のような適切な技術を使用して、無線リンク１１５にまたがって相互にデータを直接転送することも可能である。同様に、ＰＤＡ１１３は、無線通信リンク１１６を介してＰＤＡ１０７にデータを転送することも可能である。

本発明は、種々のハードウェア・プラットフォーム上で具現化することが可能であろう。図１は、異種のコンピューティング環境の一例として意図されており、本発明に対するアーキテクチャ上の限定として意図されたものではない。

次に図２を参照すると、図１に示されたような、本発明を具現化し得るデータ処理システムの典型的なコンピュータ・アーキテクチャが示される。データ処理システム１２０は、内部システム・バス１２３に接続された１つまたは複数の中央処理装置（ＣＰＵ）１２２を含んでいる。システム・バス１２３は、ランダム・アクセス・メモリ（ＲＡＭ）１２４、読取り専用メモリ１２６、および入出力（Ｉ／Ｏ）アダプタ１２８に相互接続している。入出力アダプタ１２８は、プリンタ１３０、ディスク装置１３２、または音声出力システムのような図示されてない他の装置等のような種々のＩ／Ｏ装置をサポートする。システムバス１２３は、更に、通信リンク１３６にアクセスを行なう通信アダプタ１３４に接続している。ユーザ・インターフェース・アダプタ１４８が、キーボード１４０およびマウス１４２のような種々のユーザ装置、またはタッチ・スクリーン、スタイラス、マイクロホン等のような図示されてない他の装置に接続している。ディスプレイ・アダプタ１４４がシステム・バス１２３をディスプレイ装置１４６に接続している。

図２におけるハードウェアがシステムの具現化態様に従って変わり得るということは当業者には明らかであろう。例えば、システムは、Intel（商標）Pentium（登録商標）ベースのプロセッサおよびデジタル信号プロセッサ（ＤＳＰ）のような１つまたは複数のプロセッサ、並びに１つまたは複数のタイプの揮発性および不揮発性メモリを有し得る。図２に示されたハードウェアに加えて、またはそれらのハードウェアに代わりに、他の周辺機器が使用されてもよい。図示の例は、本発明に関してアーキテクチャ上の限定を暗示することを意味しない。（なお、IntelおよびPentiumは、米国およびその他の国におけるインテル社またはその子会社の商標または登録商標である。）

本発明は、種々のハードウェア・プラットフォームにおいて実施され得ることに加えて、種々のソフトウェア環境においても実施され得る。各データ処理システム内のプログラム実行を制御するために、一般的なオペレーティング・システムを使用することも可能である。例えば、或る装置は、Unix（登録商標）オペレーティング・システムを走らせることも可能であり、一方、別の装置は、簡単なJava（登録商標）ランタイム環境を含むことも可能である。代表的なコンピュータ・プラットフォームは、グラフィック・ファイル、ワード処理ファイル、エクステンシブル・マークアップ言語（ＸＭＬ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、ハンドヘルド・デバイス・マークアップ言語（ＨＤＭＬ）、ワイヤレス・マークアップ言語（ＷＭＬ）、並びに、種々の他のフォーマットおよびタイプのファイルのような種々のフォーマットにおけるハイパーテキスト・ドキュメントをアクセスするための周知のソフトウェア・アプリケーションであるブラウザを含み得る。（JavaおよびすべてのJavaベースの商標およびロゴは米国におけるSunMicrosystems社の商標であり、UnixはアメリカにおけるOpen Groupの商標である。）

図１および図２に関して上述したように、本発明は、種々のハードウェアおよびソフトウェア・プラットフォーム上で具現化することが可能である。しかし、更に詳しく云えば、本発明はデータ処理環境の改良に関するものである。本発明をより詳細に説明前に、典型的なデータ処理環境のいくつかの実施態様を説明する。

図面に関する説明は、クライアント装置またはそのクライアント装置のユーザのいずれかによる或るアクションを含むことがある。クライアントへの／クライアントからの応答および／またはクライアントからの要求がユーザによって開始されることがあり、別のときには、クライアントによって、多く場合、そのクライアントのユーザのために、自動的に開始されるということも当業者には明らかであろう。従って、クライアントまたはクライアントのユーザが図面の説明において言及される場合、その説明されたプロセスの意味に著しく影響を与えることなく、「クライアント」および「ユーザ」という用語を交換可能に使用することができることも当然である。

或る計算タスクは、以下では機能ユニットによって行なわれるものとして説明することが可能である。機能ユニットは、ルーチン、サブルーチン、プロセス、サブプロセス、プロシージャ、関数、方法、オブジェクト指向のオブジェクト、ソフトウェア・モジュール、アプレット、プラグ・イン、ActiveX（商標）コントロール、スクリプト、或いは計算タスクを行なうためのファームウェアまたはソフトウェアの他のコンポーネント相当し得る。

図に関する説明は、種々のコンポーネント間の情報の交換を含み得るし、情報の交換は、メッセージの交換、例えば、要求メッセージに続いて生じる応答メッセージ、によって実施されるものとして説明され得る。適切な場合、同期または非同期要求／応答交換を含み得る計算コンポーネント間の情報の交換は、メッセージ、メソッド呼出し、リモート・プロシージャ呼出し、イベント・シグナリング、または他の機構のような種々のデータ交換機構を介して実施され得るということに留意されたい。

次に図３を参照すると、典型的な企業のデータ処理システムのブロック図が示される。図１はクライアントおよびサーバを備えた典型的なデータ処理システムを示しているが、それとは対照的に、図３は、リソースをアクセスするというクライアント要求をサポートするために使用可能なサーバ・サイドのエンティティのいくつかに関して、ネットワーク内のクライアントを示す。典型的なコンピューティング環境におけるように、企業ドメイン２００は、例えば、ネットワーク２０８を介してクライアント２０６上のブラウザ・アプリケーション２０４を使用することによって、ユーザ２０２がアクセスし得るリソースをホスティングする。コンピュータ・ネットワークは、図１に示されるように、インターネット、イントラネット、或いは他のネットワークであってもよい。

企業ドメイン２００は複数のサーバをサポートする。アプリケーション・サーバ２１０は、制御されたリソースおよび／または制御されてないリソースを、ウェブ・ベースのアプリケーションおよび、レガシ・アプリケーションを含む他のタイプのバックエンド・アプリケーション、を介してサポートする。リバース・プロキシ・サーバ２１４、更に簡単云えば、プロキシ・サーバ２１４は、企業ドメイン２００のための広範な機能を遂行する。例えば、プロキシ・サーバ２１４はアプリケーション・サーバからのコンテンツをミラーリングするためにウェブ・ページをキャッシュに入れてもよい。種々のポリシにおいて指定される目的および条件に従って、或いは配備されたソフトウェア・モジュールの構成に従って、着信する要求および発信する応答に関する種々の処理タスクを遂行するために、着信および発信するデータ・ストリームは、それぞれ、入力データ・ストリーム・フィルタ２１６および出力データ・ストリーム・フィルタ２１８によって処理され得る。

セッション管理ユニット２２０が、セッション識別子、キャッシュに入れられたクリデンシャル、或いは、プロキシ・サーバ２１４によって認識されるようなセッションに関する他の情報を管理する。ウェブ・ベースのアプリケーションが、認証情報を、多くの場合、ＨＴＭＬ形式におけるユーザ名／パスワードの組合せとして、入力することをユーザにプロンプト指示するために種々の手段を利用する。図３に示される例では、ユーザ２０２は、クライアント２０６がリソースをアクセスする前に認証され、しかる後そのクライアント２０６に対するセッションが確立されることを必要とする。代替の実施例では、認証および認可オペレーションは、ドメイン２００におけるリソースへのアクセスをユーザに提供する前に行なわれない。ユーザ・セッションは、付随する認証オペレーションなしで生じ得るであろう。

企業ドメイン２００内の上記エンティティは、多くのコンピューティング環境における典型的なエンティティを表わす。しかし、多くの企業ドメインは、保護された計算リソースへのアクセスを制御するためのセキュリティ機構を有する。計算リソースは、アプリケーション、オブジェクト、ドキュメント、ウェブ・ページ、ファイル、実行可能なコード・モジュール、或いは何らかの他の計算リソースまたは通信タイプ・リソースであってもよい。保護されたリソースまたは制御されたリソースは、要求元クライアント或いは要求元ユーザが確証および／または認可される場合、単なるアクセス可能なまたは検索可能なリソースである。場合によっては、認証されたユーザは、デフォルトによる許可されたユーザである。認証サーバ２２２は、ユーザ名／パスワード、Ｘ.５０９証明書または安全なトークンのような種々の認証機構をサポートし得る。特殊の認証方法に対しては、複数の認証サーバが専用化されることもある。許可サーバ２２４は、許可データベース２２６を使用し得る。許可データベース２２６は、アクセス制御リスト２２８、許可ポリシ２３０、ユーザ・グループまたはロール２３２に関する情報、および特別の管理グループ２３４内の管理ユーザに関する情報のような情報を含む。この情報を使用して、認可サーバ２２４は、特定の要求が続行することを許されるべきかどうか、例えば、制御されたリソースへのアクセスがクライアント２０６からの要求に応答して許されるべきかどうか、の表示をプロキシ・サーバ２１４に供給する。本発明が種々の認証および許可アプリケーションに関連して具現化され得るということに留意すべきである。本明細書に示された発明の実施例は、認証および許可サービスの構成に関して本発明の範囲を限定するものと解釈されるべきではない。

次に図４を参照すると、クライアントがサーバにおける保護されたリソースをアクセスしようとするときに使用し得る典型的な認証プロセスにおけるデータの流れ図が示される。図示のように、クライアント・ワークステーション３００におけるユーザが、そのクライアント・ワークステーション上で実行されるユーザのウェブ・ブラウザを通してサーバ３０２上の保護されたリソースにコンピュータ・ネットワークを介してアクセスを求める。その保護されたリソースは、ユニフォーム・リソース・ロケーター（ＵＲＬ）によって、或いは、更に一般的には、認証および許可されたユーザによってのみアクセスされ得るユニフォーム・リソース識別子（ＵＲＩ）によって、識別され得る。

ユーザがドメイン内のウェブ・ページ「ibm.com」のようなサーバ側の保護されたリソースを要求するとき、プロセスが開始される（ステップ３０４）。「サーバ側」および「クライアント側」という用語は、それぞれ、ネットワーク化された環境内のサーバまたはクライアントにおけるアクションまたはエンティティを指す。ウェブ・ブラウザ（或いは、関連するアプリケーションまたはアプレット）は、ドメイン「ibm.com」をホスティングしているウェブ・サーバに送られるＨＴＴＰ要求を発生する（ステップ３０６）。「要求」また「応答」という用語は、メッセージ、通信プロトコル情報、または他の関連情報のような特定のオペレーションに関係する情報の転送に適したデータのフォーマット化を含むものと理解されたい。

サーバは、それがクライアントのためのアクティブ・セッションを持たないということを決定し（ステップ３０８）、従って、サーバは、クライアントに或るタイプの認証チャレンジを送ることによって認証プロセスを行なうことをユーザに要求する（ステップ３１０）。認証チャレンジはＨＴＭＬ形式のような種々のフォーマットにおけるものでよい。しかる後、ユーザは、ユーザ識別子および関連のパスワードのような要求された情報または必要な情報を提供し（ステップ３１２）、或いは、クライアントがデジタル証明書のような或る情報を自動的に戻すことも可能である。

認証応答情報がサーバに送られ（ステップ３１４）、その時点で、サーバは、例えば、事前に提出された登録情報を検索することおよびその表わされた認証情報とユーザの格納された情報とを突き合わせることによって、ユーザまたはクライアントを認証する（ステップ３１６）。認証が成功したと仮定すると、その認証されたユーザまたはクライアントに対して、アクティブなセッションが確立される。

しかる後、サーバはその要求されたウェブ・ページを検索し、クライアントにＨＴＴＰ応答メッセージを送る（ステップ３１８）。その時点で、ユーザは、ハイパーテキスト・リンクをクリックすることによりブラウザにおいて「ibm.com」内の別ページを要求することがあり（ステップ３２０）、ブラウザは別のＨＴＴＰ要求メッセージをサーバに送る（ステップ３２２）。その時点で、サーバは、ユーザがサーバによって維持されているセッション状態情報に基づいてアクティブなセッションを持っているということを認識する（ステップ３２４）。例えば、サーバは、ユーザのクライアントがＨＴＴＰ要求メッセージ内のセッションＩＤを戻すので、サーバは要求元のユーザのために適切なセッション状態情報を認識する。キャッシュに入れられたユーザ・セッション情報に基づいて、サーバは、例えば、ユーザのクリデンシャルのコピーが入手可能であることによって、ユーザが既に認証されているということを決定する。しかる後、サーバは、認証オペレーションのような或るオペレーションが、ユーザの要求を満たす前に遂行される必要がないということを決定する。サーバは、その要求されたウェブ・ページを別のＨＴＴＰ応答メッセージ（ステップ３２６）においてクライアントに返送し、それによって、保護されたリソースを求めるユーザの当初の要求を満たす。

背景情報のために、図３は典型的なデータ処理システムを示し、図４は、クライアントがサーバにおける保護されたリソースをアクセスしようとするときに使用し得る典型的な認証プロセスを示す。本発明をサポートするデータ処理システムにおいて同様のコンポーネントおよびプロセスが使用され得るが、本発明の好適な実施例が残りの図において示され、それらの図に関連して検討される。

特に、本発明は、好適な実施例に従って、コンテンツが、そのコンテンツを受け取る装置のタイプによって処理され得るような動的な態様でセキュリティ関連のイベントまたは他のイベントに対する適正メッセージまたは他のコンテキスト適正コンテンツを提供する方法、装置、コンピュータ・プログラム、またはシステムに関するものである。更に詳しく云えば、以下で詳細に説明されるように、本発明の好適な実施例に従って、プロキシ・サーバからメッセージ処理サーバにメッセージまたはコンテンツの処理を外部化する改善されたインフラストラクチャが提供される。

次に図５を参照すると、本発明の実施例に従って外部化されたメッセージ処理を行うためのデータ処理システムの一部分を表わすブロック図が示される。図５に示されるデータ処理システムは、図３に示されたデータ処理システムと同様のものである。例えば、その２つの図では、クライアント４０２がクライアント２０６と同様のものであり、リバース・プロキシ・サーバ４０４がプロキシ・サーバ２１４と同様のものであるがその拡張バージョンであり、保護されたリソース４０６がアプリケーション・サーバ２１０および他のタイプの保護されたリソースを表わし得る。

リバース・プロキシ・サーバ４０４は、そのサーバ４０４におよびそのサーバ４０４から送られるデータがファイアウォール４０８および４１０を通り抜けなければならないような計算ＤＭＺ（DeMilitarized Zone）の内に存在することが望ましい。リバース・プロキシ・サーバ４０４は、保護されたリソース４０６を含む安全領域内で作成されるユーザ・セッションに関連したセッション管理の責任を負う。

リバース・プロキシ・サーバ４０４および保護されたリソース４０６は、例えば、図２に示されるような企業ドメイン２００と同様の企業ドメインにおける計算リソースを表し得るトラステッド・ネットワーク内に存在してもよい。

図５は、クライアント/ユーザと、そのクライアント／ユーザによってアクセスされる保護されたリソースをサポートするコンポーネントとの間における或るデータ・フローを示す。更に、図５は、動的なメッセージ処理がプロキシ・サーバから別のサーバに外部化され得る本発明の実施態様を検討するためのコンポーネントを示す。

多くの操作シナリオまたは取引では、クライアント４０２のユーザは、プロキシ・サーバ４０４がユーザのためのクリデンシャルを有するように、プロキシ・サーバ４０４を介して認証プロセスを既に終了していてもよい。プロキシ・サーバ４０４は、例えば、ユーザが受け取った要求を保護されたリソース４０６に転送または送信するとき、いくつかの保護されたリソース４０６へのアクセスをユーザに提供するためにクリデンシャルを使用する。多くの場合、プロキシ・サーバ４０４が、保護されたリソースをアクセスするという要求を受け取り、要求元ユーザのクリデンシャルが十分であるということを決定するとき、プロキシ・サーバ４０４は如何なるエラー処理も行うことなく要求を処理する。

しかし、図５に示される例では、リソース要求４１２がプロキシ・サーバ４０４によって受け取られるとき、リソース要求４１２は、例えば、仮定的に転送される要求４１４として、保護されたリソース４０６に転送されない。この例では、プロキシ・サーバ４０４は、リソース要求４１２が何らかの理由で、特に、何らかのセキュリティ関連のイベント、エラー誘起したイベント、または何らかの他のタイプの問題イベントを検知したために、履行され得ない或いは遂行され得ない要求であるということを認識する。例えば、プロキシ・サーバ４０４は、そのプロキシ・サーバが、保護されたリソースをアクセスすることを要求されるクライアント／ユーザのためのクリデンシャルを持っていないということを認識し、それによってユーザがログオン・オペレーションまたは、例えば、ユーザ名とパスワードを備えたログオン形式の成功したサブミッションにより同様の認証オペレーションを行なうことを要求されるということを決定し得る。

クライアントに、例えば静的ＨＴＭＬ形式のようなコンテキスト適正コンテンツを戻そうとするのではなく、プロキシ・サーバ４０４が、その代りに、クライアント４０２にリダイレクト・メッセージ４１６を送る。クライアント４０２は、そのリダイレクト・メッセージをメッセージ処理サーバ４１８に転送する。このリダイレクト・メッセージは、メッセージ処理サーバ４１８が、クライアント４０２からのオリジナル要求に応答してクライアント４０２にコンテキスト適正コンテンツを送る責任を負うことを可能にする情報を含んでいる。メッセージ処理サーバ４１８は、更に詳細に後述するように、プロキシ・サーバ４０４によってメッセージ処理サーバ４１８のためのリダイレクト・メッセージ４１６内に特別に含まれた情報に基づいて、コンテキスト適正コンテンツ４２０を動的に生成し,それをクライアント４０２に送る。

次に図６を参照すると、本発明の実施例に従って、プロキシ・サーバからメッセージ処理サーバへのリダイレクト・メッセージのコンテンツを表わすブロック図が示される。メッセージ５０２は、クライアント装置を介して、プロキシ・サーバからメッセージ処理サーバに送られるリダイレクト・メッセージを表わす。メッセージ５０２は種々の実施態様特有の方法でフォーマットされ得るが、メッセージ５０２は、無線装置またはモバイルの装置を含むほとんどのＨＴＴＰ対応の装置によってエラーなしで処理され得るＨＴＴＰ「３０２」リダイレクトとしてフォーマットされることが望ましい。リダイレクト・メッセージ５０２はロケーション・ヘッダ５０４を含み、そのロケーション・ヘッダは、リダイレクト・メッセージが、この場合メッセージ処理サーバである宛先として意図されるエンティティのＵＲＩを含む。好適な実施例では、ロケーション・ヘッダ５０４は、メッセージ処理要求５０８と共に、メッセージ処理サーバのＵＲＬを表わすベースＵＲＬ５０６を含む。メッセージ処理要求５０８は、クライアント要求に応答してメッセージ生成タスクを行なうためにプロキシ・サーバからメッセージ処理サーバに送られる情報を表わす。

次に図７を参照すると、本発明の実施例に従って、プロキシ・サーバからメッセージ処理サーバへのメッセージ処理要求のコンテンツを表わすブロック図が示される。メッセージ処理要求６０２は、図６に示されたメッセージ処理要求５０８と同様のものである。メッセージ処理要求６０２は、プロキシ・サーバがメッセージ処理サーバに遂行することを要求するオペレーションまたはメッセージ生成機能を表わすオペレ-ション・コード、即ち、ｏｐコードを含む。マクロ起動の情報６０６は、プロキシ・サーバにおいてで構成され得るマクロに従って、プロキシ・サーバによりメッセージ処理サーバに提供されるゼロまたはそれ以上のデータ項目を表す。その評価されたマクロは、メッセージを生成するとき、メッセージ処理サーバによってメッセージ生成機能で或いは何らかの他の方法で使用され得る。

図８を参照すると、本発明の実施例に従って、メッセージ処理サーバに送られるリダイレクト・メッセージを生成するためにプロキシ・サーバによって使用される情報のブロック図が示される。図８に示される情報項目のいくつかは、他の図に示された要素を単に繰り返している。例えば、リダイレクト・メッセージ７０２は図６におけるリダイレクト・メッセージ５０２と同様のものである。ｏｐコード７０４は図７におけるｏｐコード６０４と同様のものであり、メッセージ処理要求５０８の一部を構成する。マクロ起動のＵＲＩ７０６は、図７におけるマクロ起動の情報６０６と同様のものであり、メッセージ処理要求５０８の一部を構成する。

プロキシ・サーバ７００は、リダイレクト・メッセージ７０２を形成するために使用されるデータ項目に関する種々のデータ・ストアまたはソースをアクセスする。プロキシ・サーバ７００がアクセスし得るデータ・ストアの１つはコンフィギュレーション・ファイル７１０であり、そのファイル７１０は、好適な実施例の機能を含む、プロキシ・サーバ７００の処理の広範な種々の態様をガイドする構成可能な変数に関する値を含む。構成ファイル７１０はメッセージ処理（ＭＨ）ＵＲＬ７１２を含む。そのＭＨＵＲＬは、構成ファイ内の名前−値のペアとして格納されてもよい。プロキシ・サーバ７００は、リダイレクト・メッセージ７０２を生成するとき、メッセージ処理サーバＵＲＬ７１２をメッセージ処理ＵＲＬ７０８としてコピーする。

例えば、設定ファイルは下記のストリングを含み得る。
「local-response-redirect-uri =/ibmysa/jct/handler」

ストリング「local-response-redirect-uri」は、メッセージ処理サーバに対するリダイレクトＵＲＩを表す変数の名前を表す。ストリング「/ibmusa/jct/handler」は、その変数の値を表す。従って、ストリング「/ibmusa/jct/handler」は、リダイレクト・メッセージ７０２におけるＭＨ ＵＲＬ７０８の値であり、ストリング「/ibmusa/jct/handler」は、リダイレクト・メッセージ７０２におけるロケーションＵＲＩのベース部分を形成する。

プロキシ・サーバ７００は、本発明の実施態様に依存する種々の方法でｏｐコード７０４を決定し得る。例えば、ｏｐコード７０４は、セキュリティ関連のイベント通知に基づいて、または検知されたエラー状態に基づいて選択され得る。それとは別に、ｏｐコード７０４は、クライアント要求メッセージ７１４内の情報に基づいて、即ち、保護されたリソースを、特にクライアント要求のＵＲＩ７１６に関連して、アクセスしようとしたクライアントからのオリジナル要求メッセージ内の情報に基づいて、選択され得る。プロキシ・サーバ７００がｏｐコード７０４を決定し得る方法は、構成ファイル７１０を介して構成し得るものであってもよい（図には示されていない）。それとは別に、それは、プロキシ・サーバ７００のソース・コード・ロジック内に組み込まれてもよく、或いはプロキシ・サーバ７００は何らかの別の方法でその値を受け取るかまたは検索する。

例えば、クライアント装置がログオン・ウェブ・ページのようなログオン・リソースをアクセスしようとする場合、ｏｐコード７０４は、特定のＵＲＬ７１６に基づいて、或いは関連するリソースのグループにおけるそれの分類に基づいて、選択されることがある。従って、オペレーション・コードの値は「LOGON」に等しいことがあり、ｏｐコード７０４は、リダイレクト・メッセージ７０２におけるロケーションＵＲＩの一部分として現われるストリング「OP_CODE=logon」によって表わされることも可能である。更に詳しく云えば、より詳細に後述するように、ｏｐコード７０４は、照会引数としてリダイレクト・メッセージ７０２におけるロケーションＵＲＩに置かれることも可能である。

プロキシ・サーバ７００は、構成ファイル７１０におけるマクロ７１８の存在に基づいてリダイレクト・メッセージ７０２内にマクロ関連のＵＲＩ７０６を組み込むように指示される。この例では、マクロ７１８は、当初要求されたＵＲＩがメッセージ処理サーバに供給されることを表わす。従って、プロキシ・サーバ７００は、クライアント要求のＵＲＩ７１６をリダイレクト・メッセージ７０２にマクロ関連のＵＲＩ７０６としてコピーする。

例えば、構成ファイルは、当初要求されたＵＲＩをメッセージ処理要求に含めるためにプロキシ・サーバ７００を起動するストリング「macro=URI」を含み得る。ストリング「https://ibmUSA/jct/protected/」がその当初要求されたＵＲＩを表わす場合、更に詳細に後述するように、ストリング「URI=https://ibmUSA/jct/protected/」が、ロケーションＵＲＩの一部分における照会引数としてリダイレクト・メッセージ７０２に置かれてもよい。

或る視点から見ると、本発明の好適な実施例におけるいくつかの態様を、リダイレクト・メッセージの「ロケーション」・ヘッダの構造をＡＰＩ（アプリケーション・プログラム・インターフェイス）の１つのタイプとして使用するものと見なすことも可能である。パラメータは、定義されたインターフェースを使用して、プロキシ・サーバからメッセージ処理サーバに伝えられる。図６に示されるように、「ロケーション」・ヘッダ内のコンテンツは下記の部分から構成され得る。
<MH URL> <OP CODE>{<MACRO-INVOKEDINFO>}

なお、その「ロケーション」・ヘッダにおける<MH URL>は、メッセージ処理サーバのＵＲＬを表わすストリングである。<OP CODE>は、オペレ-ション・コードを表わすストリングである。{<MACRO-INVOKEDINFO>}は、構成ファイル内のマクロ変数の存在によって要求される情報項目を表わすゼロまたはそれ以上のストリングである。

好適な実施例では、オペレ-ション・コードおよびマクロ起動の情報項目がリダイレクト・メッセージの「ロケーション」・ヘッダ内に照会引数として含まれる。上記の例を参照すると、「OP_CODE=logon」が照会引数になる。「macro=URI」が１つの構成されたマクロであると仮定すると、「https://ibmUSA/jct/protected/」が照会引数になる。これらのストリングの各々は、「ロケーション」・ヘッダ全体を表わすそのストリング値内のサブストリングになる。従って、この例を続けると、「ロケーション」・ヘッダの値は（プロトコル標準を厳守するように何らかのＡＳＣＩＩデータ・フォーマット化を行った後では）下記のようになる。
https://ibmUSA/jct/handler?OP_CODE=LOGON&URI=https%３A//ibmUSA/jct/protected/

その値における文字「?」は、照会引数とＵＲＩのベース部分とを区別するための標準のデリミッタである。文字「&」は、更なる照会引数を付加するための標準のデリミッタである。同じ例を続けると、「macro=URI」および「macro=username」は構成され、ユーザのユーザ名が「jsmith」であった場合、「ロケーション」・ヘッダの値は次のようになるであろう。
https://ibmUSA/jct/handler?OP_CODE=LOGON&URL=https%3A//ibmUSA/jct/protected/&username=jsmith

ユーザ名は、セッション状態変数、クリデンシャル、ユーザ・レジストリ、或いは何らかの他のデータ・ストアまたはデータ構造から検索されてもよい。いずれのマクロもアクティブであるように構成されない場合、「ロケーション」・ヘッダの値は次のようになるであろう。
https://ibmUSA/jct/handler?OP_CODE=LOGON

種々のオペレ-ション・コードを表すストリングは、本発明の実施態様に従って変わり得る。メッセージ処理サーバへのメッセージの生成のためにプロキシ・サーバによって使用される情報は、セッション・キャッシュにおけるクライアントのエントリに保存されているデータ、当初に受取られたＨＴＴＰ要求の要素、認証エンジンから戻された値、または何らかの他のロケーションのような図面に示されていない他のロケーションを含む種々のロケーションから生じ得るということに留意されたい。

次に図９を参照すると、本発明の好適な実施例に従って、リソースに対するクライアント要求に応答してクライアントに送られるべきコンテキスト適正コンテンツ・メッセージを生成することを求める要求をメッセージ処理サーバに送るための、プロキシ・サーバにおけるプロセスのフローチャートが示される。なお、そのリソースは、本発明の実施例によれば、そのコンテンツ・メッセージがクライアントに送られることを要求する或る検知されたイベントを生じたリソースである。プロセスは、リソースまたは保護されたリソースをアクセスするという要求をプロキシ・サーバがクライアントから受け取るときに開始する（ステップ８０２）。受け取られた要求の処理中、プロキシ・サーバは、コンテキスト適正コンテンツをクライアントに１つの応答として送信することを必要とするイベントを検知するかまたは通知される（ステップ８０４）。例えば、コンテキスト適正コンテンツは、ユーザが要求した取引あるいはログオン送信勧誘（invitation）に対するエラー・メッセージのような、クライアントのユーザへのメッセージであってもよい。

プロキシ・サーバがリダイレクト・メッセージを作成する（ステップ８０６）。リダイレクト・メッセージは、そのリダイレクト・メッセージを受け取るメッセージ処理サーバによって使用されるべき情報を含む。リダイレクト・メッセージは、プロキシ・サーバがメッセージ処理サーバにおいて起動したい機能に関するオペレ-ション・コード、即ち、ｏｐコードを含む。リダイレクト・メッセージは、更に、プロキシ・サーバを構成した特定のマクロに基づいてそのリダイレクト・メッセージに入れられるデータ項目も含む。次に、プロキシ・サーバが、クライアントを介してメッセージ処理サーバにリダイレクト・メッセージを送り（ステップ８０８）、プロセスは終了する。

次に図１０を参照すると、本発明の好適な実施例に従って、メッセージ処理要求を含むリダイレクト・メッセージを作成するためのプロセスのフローチャートが示される。図１０に示されるプロセスは、図９に示されたステップ８０６に対する補足的な細部を提供する。プロセスは、プロキシ・サーバがメッセージ処理要求を発生することによって開始する（ステップ９０２）。適切なメッセージ処理のｏｐコードが決定され、メッセージ処理要求内に組み込まれる（ステップ９０４）。

次に、プロキシ・サーバが、構成された或いは活性化されたマクロのリストを決定する（ステップ９０６）。構成されたマクロの各々の対する値が得られる。これらの値は「評価されたマクロ」と名付けられてもよく、その評価されたマクロがメッセージ処理要求内に組み込まれる（ステップ９０８）。

次に、リダイレクト・メッセージが生成され（ステップ９１０）、メッセージ処理要求がリダイレクト・メッセージに組み込まれる（ステップ９１２）。しかる後、メッセージ処理サーバのＵＲＬが検索され、リダイレクト・メッセージに組み込まれ（ステップ９１４）、それによって、プロセスが終了する。

次に図１１を参照すると、本発明の実施例に従って、リダイレクト・メッセージの「ロケーション」・ヘッダ、およびその「ロケーション」・ヘッダのＵＲＩにおける照会引数を使ってＨＴＴＰリダイレクト・メッセージを作成するためのプロセスのフローチャートが示される。図１１に示されるプロセスは、図１０に示されたプロセスと同様のものである。しかし、図１１に示されるプロセスは、メッセージ処理要求がＨＴＴＰリダイレクト・メッセージ内にフォーマットされるという本発明の一部分である特定の好適な実施例を示す。

プロセスは、ＨＴＴＰリダイレクト・メッセージの発生によって開始する（ステップ１００２）。メッセージ処理サーバのＵＲＬが構成ファイルから検索され（ステップ１００４）、リダイレクト・メッセージの「ロケーション」・ヘッダにおけるＵＲＩのベース部分としてリダイレクト・メッセージに挿入される（ステップ１００６）。プロキシ・サーバが、メッセージ処理サーバにおける特定の機能を要求するものとしてメッセージ処理サーバにより解釈されるオペレ-ション・コード即ちｏｐコードを決定した後、それは、リダイレクト・メッセージの「ロケーション」・ヘッダにおけるＵＲＩの照会引数としてリダイレクト・メッセージに挿入される（ステップ１００８）。

次に、構成されたマクロのリストが、例えば、構成ファイルからの検索によって決定され（ステップ１０１０）、各構成されたマクロに対する値が、各マクロにとって適正な方法で得られる（ステップ１０１２）。しかる後、各構成されたマクロの値が、リダイレクト・メッセージの「ロケーション」・ヘッダにおけるＵＲＩの照会引数としてリダイレクト・メッセージに挿入され（ステップ１０１４）、それによって、プロセスは終了する。

開示された解決方法の利点は上記の詳細な説明から見て明らかであろう。図５に示されるように、プロキシ・サーバはリダイレクト・メッセージ、例えば、ＨＴＴＰ「３０２」リダイレクトを、クライアント装置を介してメッセージ処理サーバに送る。無線装置を含むほとんどのクライアント装置はＨＴＴＰ「３０２」リダイレクトを取り扱うことができる。クライアントは、プロキシ・サーバ内のＨＴＴＰ応答本体を生成するのではなく、特定の装置に支援される装置に対する顧客／ベンダによって保守されることがある別のサーバにリダイレクトされる。しかる後、図５ではメッセージ処理サーバ４１８として示されたこのバックエンド・サーバが、クライアント装置のタイプを決定し且つ適正な応答を生成する責任を負うであろう。開示された解決法の主たる利点は、それがコンテキスト適正コンテンツの生成から完全にプロキシ・サーバを不用にするということである。適正な応答を決定することに対する責任を別のサーバに負わせることは、ログインおよびエラー・ページに関するコンテンツを生成するためのクライアント側プログラミングではなく、サーバ側プログラミングを使用するための顧客抽出の要件に適合する。開示された解決方法は、更に、メッセージ処理サーバがコンテキスト適正コンテンツを生成することを可能にするために、プロキシ・サーバからメッセージ処理サーバにパラメータまたは可変値を伝達し得るタイプのＡＰＩを提供する。

完全に機能するデータ処理システムに関連して本発明を説明したが、本発明のプロセスが、コンピュータ可読媒体における命令の形および種々の他の形で分散され得るということおよびその分散を実行するために実際に使用される特定のタイプの信号保持媒体に関係ないということが当業者には明らかであるということに留意することが重要である。コンピュータ可読媒体の例は、ＥＰＲＯＭ、ＲＯＭ、テープ、用紙、フロッピ・ディスク、ハードディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭのような媒体、並びに、デジタルおよびとアナログ通信リンクのような伝送型の媒体を含む。

一般に、方法は、望ましい結果に通じるステップの首尾一貫したシーケンスであると考えられる。これらのステップは、物理的量の物理的操作を必要とする。通常、これらの量は、必ずしも、保存、転送、結合、比較、およびそれ以外の操作を可能にする電気的または磁気的信号の形をとる必要はない。これらの信号を、主として一般的な使用のために、ビット、値、パラメータ、項目、要素、オブジェクト、記号、文字、用語、数字等として参照することも時には都合がよい。しかし、これらの用語および同様の用語はすべて適切な物理的量に関連付けられ、これらの量に付された単なる便宜上のラベルであるということも留意すべきである。

本発明に関する説明は例示を目的に行われたが、網羅的であることまたは開示された実施例に限定されることを意図するものではない。多くの修正および変更が当業者には明らかであろう。なお、実施例は、発明の原理およびその実用的応用例を説明するために、および、当業者が、他の意図した使用に適するように種々の実施例を種々の修正と共に具現化するべく本発明を理解することを可能にするために選択された。

それぞれが本発明を具現化し得るデータ処理システムの典型的なネットワークを示す概略図である。 本発明を具現化し得るデータ処理システムにおいて使用され得る典型的なコンピュータ・アーキテクチャのブロック図である。 典型的な企業データ処理システムを示すブロック図である。 クライアントがサーバにおける保護されたリソースにアクセスしようとするときに使用される典型的な認証プロセスを示すデータ・フローの概略図である。 本発明の好適な実施例に従って、外部化されたメッセージ処理を行なうためのデータ処理システムの一部分を示すブロック図である。 本発明の好適な実施例に従って、プロキシ・サーバからメッセージ処理サーバへのリダイレクト・メッセージのコンテンツを示すブロック図である。 本発明の好適な実施例に従って、プロキシ・サーバからメッセージ処理サーバへのメッセージ処理要求のコンテンツを示すブロック図である。 本発明の好適な実施例に従って、メッセージ処理サーバに送られるリダイレクト・メッセージを生成するためにプロキシ・サーバによって使用される情報を示すブロック図である。 本発明の好適な実施例に従って、コンテンツ・メッセージがクライアントに送られることを要求する検知されたイベントを生じたリソースに対するクライアント要求に応答して、クライアントに送られるべきコンテキスト適正コンテンツ・メッセージを生成するために、メッセージ・ハンドラ・サーバに要求を送るためのプロキシ・サーバにおけるプロセスを示すフローチャートである。 本発明の好適な実施例に従って、メッセージ処理要求を含むリダイレクト・メッセージを作成するためのプロセスを示すフローチャートである。 本発明の好適な実施例に従って、リダイレクト・メッセージの「ロケーション」・ヘッダおよび「ロケーション」・ヘッダのＵＲＩにおける照会引数を使用して、ＨＴＴＰリダイレクト・メッセージを作成するためのプロセスを示すフローチャートである。

Claims (22)

1. データ処理システムにおいてメッセージ処理を外部化するためにコンピュータを利用する方法であって、
   第１サーバにおいて、リソースをアクセスする要求をクライアントから受け取るステップと、
   前記要求の処理はメッセージが前記クライアントに送られることを必要とする、という前記第１サーバにおける決定に応答して、前記メッセージを前記クライアントに送るために第２サーバにおけるメッセージ処理機能に対応したオペレーション・コードを含むリダイレクト・メッセージを生成するステップと、
   評価されたマクロを決定するために構成可能マクロを評価するステップと、
   前記評価されたマクロを前記リダイレクト・メッセージに挿入するステップと、
   前記クライアントを介して、前記リダイレクト・メッセージを前記第１サーバから前記第２サーバに送るステップと、
   を含む、方法。
2. 前記第２サーバにおいて、前記リダイレクト・メッセージから前記オペレーション・コードを取り出すステップと、
   前記第２サーバにおいて、取り出されたオペレーション・コードに対応するメッセージ処理機能を起動するステップと、
   を更に含む、請求項１に記載の方法。
3. 前記第２サーバにおいて、前記リダイレクト・メッセージから前記評価されたマクロを取り出すステップと、
   前記第２サーバにおいて、前記評価されたマクロを前記メッセージ処理機能に対する入力パラメータとして使用するステップと、
   を更に含む、請求項１または請求項２に記載の方法。
4. 第１構成可能マクロを、前記クライアントからの要求におけるＵＲＩ（Uniform Resource Identifier）に対応するものとして識別するステップと、
   前記クライアントからの前記要求から前記ＵＲＩを取り出すステップと、
   前記第１構成可能マクロを、前記要求から取り出されたＵＲＩに等しいものとして評価するステップと、
   を更に含む、請求項１乃至請求項３のいずれか１つに記載の方法。
5. 前記リダイレクト・メッセージ内の「ロケーション」・ヘッダにおけるＵＲＩの照会引数として、前記オペレーション・コードを前記リダイレクト・メッセージに挿入するステップを更に含み、
   前記リダイレクト・メッセージはＨＴＴＰ（HyperTextTransport Protocol）リダイレクト・メッセージである、請求項１乃至請求項４のいずれか１つに記載の方法。
6. 前記リダイレクト・メッセージ内の「ロケーション」・ヘッダにおけるＵＲＩの照会引数として、前記評価されたマクロを前記リダイレクト・メッセージに挿入するステップを更に含み、
   前記リダイレクト・メッセージはＨＴＴＰ（HyperTextTransport Protocol）リダイレクト・メッセージである、請求項１乃至請求項５のいずれか１つに記載の方法。
7. 評価されたマクロのセットを決定するために構成可能マクロのセットを評価するステップと、
   前記評価されたマクロを前記リダイレクト・メッセージに挿入するステップと、
   を更に含む、請求項１乃至請求項６のいずれか１つに記載の方法。
8. メッセージ処理を外部化するためにデータ処理システムにおいて使用するためのコンピュータ・プログラムであって、
   第１サーバにおいて、リソースをアクセスする要求をクライアントから受け取る機能と、
   前記要求の処理はメッセージが前記クライアントに送られることを必要とするという前記第１サーバにおける決定に応答して、前記メッセージを前記クライアントに送るために第２サーバにおけるメッセージ処理機能に対応したオペレーション・コードを含むリダイレクト・メッセージを生成する機能と、
   評価されたマクロを決定するために構成可能マクロを評価する機能と、
   前記評価されたマクロを前記リダイレクト・メッセージに挿入する機能と、
   前記クライアントを介して、前記リダイレクト・メッセージを前記第１サーバから前記第２サーバに送る機能と、
   を含む、コンピュータ・プログラム。
9. 前記第２サーバにおいて、前記リダイレクト・メッセージから前記オペレーション・コードを取り出す機能と、
   前記第２サーバにおいて、取り出されたオペレーション・コードに対応するメッセージ処理機能を起動する機能と、
   を更に含む、請求項８に記載のコンピュータ・プログラム。
10. 前記第２サーバにおいて、前記リダイレクト・メッセージから前記評価されたマクロを取り出す機能と、
    前記第２サーバにおいて、前記評価されたマクロを前記メッセージ処理機能に対する入力パラメータとして使用する機能と、
    を更に含む、請求項８または請求項９に記載のコンピュータ・プログラム。
11. 第１構成可能マクロを、前記クライアントからの要求におけるＵＲＩ（Uniform Resource Identifier）に対応するものとして識別する機能と、
    前記クライアントからの前記要求から前記ＵＲＩを取り出す機能と、
    前記第１構成可能マクロを、前記要求から取り出されたＵＲＩに等しいものとして評価する機能と、
    を更に含む、請求項８乃至請求項１０のいずれか１つに記載のコンピュータ・プログラム。
12. 前記リダイレクト・メッセージ内の「ロケーション」・ヘッダにおけるＵＲＩの照会引数として、前記オペレーション・コードを前記リダイレクト・メッセージに挿入する機能を更に含み、
    前記リダイレクト・メッセージはＨＴＴＰ（HyperTextTransport Protocol）リダイレクト・メッセージである、請求項８乃至請求項１１のいずれか１つに記載のコンピュータ・プログラム。
13. 前記リダイレクト・メッセージ内の「ロケーション」・ヘッダにおけるＵＲＩの照会引数として、前記評価されたマクロを前記リダイレクト・メッセージに挿入する機能を更に含み、
    前記リダイレクト・メッセージはＨＴＴＰ（HyperTextTransport Protocol）リダイレクト・メッセージである、請求項８乃至請求項１２のいずれか１つに記載のコンピュータ・プログラム。
14. 評価されたマクロのセットを決定するために構成可能マクロのセットを評価する機能と、
    前記評価されたマクロを前記リダイレクト・メッセージに挿入する機能と、
    を更に含む、請求項８乃至請求項１３のいずれか１つに記載のコンピュータ・プログラム。
15. データ処理システムにおいてメッセージ処理を外部化するため装置であって、
    第１サーバにおいて、リソースをアクセスする要求をクライアントから受け取るための手段と、
    前記要求の処理はメッセージが前記クライアントに送られることを必要とする、という前記第１サーバにおける決定に応答して、前記メッセージを前記クライアントに送るために第２サーバにおけるメッセージ処理機能に対応したオペレーション・コードを含むリダイレクト・メッセージを生成するための手段と、
    評価されたマクロを決定するために構成可能マクロを評価するための手段と、
    前記評価されたマクロを前記リダイレクト・メッセージに挿入するための手段と、
    前記クライアントを介して、前記リダイレクト・メッセージを前記第１サーバから前記第２サーバに送るための手段と、
    を含む、装置。
16. 前記第２サーバにおいて、前記リダイレクト・メッセージから前記オペレーション・コードを取り出すための手段と、
    前記第２サーバにおいて、取り出されたオペレーション・コードに対応するメッセージ処理機能を起動するための手段と、
    を更に含む、請求項１５に記載の装置。
17. 前記第２サーバにおいて、前記リダイレクト・メッセージから前記評価されたマクロを取り出すための手段と、
    前記第２サーバにおいて、前記評価されたマクロを前記メッセージ処理機能に対する入力パラメータとして使用するための手段と、
    を更に含む、請求項１５または請求項１６に記載の装置。
18. 第１構成可能マクロを、前記クライアントからの要求におけるＵＲＩ（Uniform Resource Identifier）に対応するものとして識別するための手段と、
    前記クライアントからの前記要求から前記ＵＲＩを取り出すための手段と、
    前記第１構成可能マクロを、前記要求から取り出されたＵＲＩに等しいものとして評価するための手段と、
    を更に含む、請求項１５乃至請求項１７のいずれか１つに記載の装置。
19. 前記リダイレクト・メッセージ内の「ロケーション」・ヘッダにおけるＵＲＩの照会引数として、前記オペレーション・コードを前記リダイレクト・メッセージに挿入するための手段を更に含み、
    前記リダイレクト・メッセージはＨＴＴＰ（HyperTextTransport Protocol）リダイレクト・メッセージである、請求項１５乃至請求項１８のいずれか１つに記載の装置。
20. 前記リダイレクト・メッセージ内の「ロケーション」・ヘッダにおけるＵＲＩの照会引数として、前記評価されたマクロを前記リダイレクト・メッセージに挿入するための手段を更に含み、
    前記リダイレクト・メッセージはＨＴＴＰ（HyperTextTransport Protocol）リダイレクト・メッセージである、請求項１５乃至請求項１９のいずれか１つに記載の装置。
21. 評価されたマクロのセットを決定するために構成可能マクロのセットを評価するための手段と、
    前記評価されたマクロを前記リダイレクト・メッセージに挿入するための手段と、
    を更に含む、請求項１５乃至請求項２０のいずれか１つに記載の装置。
22. プログラム・コードを含むコンピュータ・プログラムであって、前記コンピュータ・プログラムがコンピュータ上で実行されるとき、請求項１乃至請求項７に記載の方法を遂行するように適合したコンピュータ・プログラム。

Images