JP5719349B2 - メッセージ交換 - Google Patents

Description

本発明は、通信システムを動作させる方法及びそのシステムに関する。この方法及びシステムは、メッセージ・フォーマットの動的交換を可能にする。

コンピュータ技術においては、クライアント及びサーバという表現は、２つのコンピュータ又はプログラムの動作を表しており、この動作では、一方すなわちクライアントが、他方すなわちサーバからのサービス及び／又は情報を要求する。電子メール交換、ウェブ・アクセス及びデータベース・アクセスのような標準的なネットワーク化された機能は、クライアント・サーバ・モデルに基づいている。クライアント・サーバ・アーキテクチャは恐らく最も一般的なものであるが、他の協働のモードが可能である。例えば、コンピュータが、メイン・データもアプリケーションも保持しないが、各々が自分自身の働きに対して責任を負っている場合には、２つのコンピュータ又はコンピュータ・プログラムは、ピアツーピア関係におけるピアであるといわれる。

コンピュータ間の通信は、それらのコンピュータの挙動関連性にかかわらず、プロトコルと呼ばれる一連の規則によって規定される。典型的な例として、多くのワールド・ワイド・ウェブ・アプリケーションに用いられるｈｔｔｐ（ハイパーテキスト転送プロトコル）と、１つのコンピュータが別のコンピュータに対してファイルを要求し受信するときに用いられるｆｔｐ（ファイル転送プロトコル）とが挙げられる。通信を制御するプロトコルすなわち一連の規則と同様に、実際の通信オブジェクトすなわちメッセージもまた、それらが受信側によってどのように解釈されるべきかを定義する一連のフォーマット規則に従う。典型的なフォーマットとして、ワールド・ワイド・ウェブ・ページのための基本フォーマットであるＨＴＭＬ（ハイパーテキスト・マークアップ言語）と、多くの異なる多様なアプリケーションのメッセージ・タイプに用いられる適応性の高いタグ付け言語であるＸＭＬ（拡張マークアップ言語）とが挙げられる。

こうしたマークアップ言語は、システム・インターフェース及びメッセージ・フォーマットを定める際に有用である。しかし、こうしたマークアップ言語には、多くのメッセージがコンピュータ間又はコンピュータ・プログラム間を通過するときに負荷が高くなるという欠点があり、この欠点が、典型的には性能に悪影響を及ぼすことになる。

本発明の第１の態様によると、サーバ及びクライアントを含む通信システムを動作させる方法であって、データ及び記述タグを含む第１のフォーマットのメッセージをクライアントから送信するステップと、メッセージをサーバで受信するステップと、サーバとクライアントとの間でメッセージ・フォーマット交換に関するネゴシエーションを開始するステップと、クライアントがメッセージ・フォーマット交換を受け入れることが可能であることを示すステップと、メッセージ・フォーマットを交換するようにクライアントに指示するステップと、データからなる第２のフォーマットの追加メッセージをクライアントから送信するステップとを含む方法が提供される。

本発明の第２の態様によると、サーバ及びクライアントを含む通信システムであって、クライアントは、データ及び記述タグを含む第１のフォーマットのメッセージを送信するように構成され、サーバは、メッセージを受信し、サーバとクライアントとの間でメッセージ・フォーマット交換に関するネゴシエーションを開始するように構成され、クライアントは、メッセージ・フォーマット交換を受け入れることが可能であることを示すように構成され、サーバは、メッセージ・フォーマットを交換するようにクライアントに指示するように構成され、クライアントは、データからなる第２のフォーマットの追加メッセージを送信するように構成されるシステムが提供される。

本発明の第３の態様によると、サーバを動作させるためのコンピュータ・プログラムであって、データ及び記述タグを含む第１のフォーマットのメッセージをクライアントから受信するための命令と、サーバとクライアントとの間でメッセージ・フォーマット交換に関するネゴシエーションを開始するための命令と、クライアントがメッセージ・フォーマット交換を受け入れることが可能であるという表示を受信するための命令と、メッセージ・フォーマットを交換するようにクライアントに指示するための命令と、データからなる第２のフォーマットの追加メッセージをクライアントから受信するための命令とを含むコンピュータ・プログラムが提供される。

本発明によって、メッセージ・フォーマットとしてＸＭＬを用いる複雑なコンピュータ・システムの性能を向上させることが可能である。本発明は、サーバ及びクライアントがメッセージ・フォーマットを交換することを可能にし、これにより、システムは、マークアップ言語を用いて設計されたシステムの全ての適応性の利益を享受することができるが、同時に、より効率的なメッセージ・フォーマットを用いることによる性能向上の利点を活かすこともできる。

好ましくは、本方法は、クライアントからのメッセージ負荷を監視することと、メッセージ負荷について統計分析を実行することと、統計分析に従ってサーバとクライアントとの間でネゴシエーションを開始することとをさらに含む。サーバは、性能統計を用いて、いつ第２のメッセージ・フォーマットに交換すべきかを判断することができる。これにより、より簡単なメッセージ・フォーマットへの交換を行うことが実際に効果的であるときにのみ交換が行われることが確実になる。メッセージ負荷についての統計分析の実行は、クライアントからの負荷が所定の閾値を上回ることを判断することを含むことができる。サーバは、接続された各々のクライアントからの負荷を監視し、１秒あたりの特定のメッセージ数といった所定の閾値に到達したときに、この閾値を第２のメッセージ・フォーマットに交換するためのトリガとして用いることができるという方法を用いることが可能である。これにより、ネゴシエーションを行ってプロトコルを変更するオーバーヘッドを正当化するのに十分な処理能力があるときにのみ交換が行われることになる。

理想的には、本方法は、第２のフォーマットの記述をクライアントに送信することをさらに含む。第１の実施形態においては、クライアントは、交換が承諾された後で用いられる第２のメッセージ・フォーマットの構造をすでに認識していてもよい。しかしながら、クライアントは、第２のメッセージ・フォーマットを認識していない場合もあるが、それにもかかわらず、十分な適応性があるため現在のメッセージ・フォーマットから交換する能力を有する。この場合には、サーバは、第２のメッセージ・フォーマットの記述をクライアントに提供し、クライアントは、この記述に従ってクライアント自体を構成することになる。このことにより、システムが、サーバのメッセージ交換機能を認識していない幾つかのクライアントを組み込むことができるときに、システムの性能全体が向上する。これにより、システム内を流れるより多くのメッセージのサイズが減少する。

有利なことに、本方法は、メッセージがクライアントとサーバとの間で改変されていないことを確認することをさらに含む。通信システムの性質によっては、クライアントとサーバとの間の経路指定は、直接的なものではない場合がある。他の中間コンポーネントが、クライアントとサーバとの間を流れるメッセージを送受信することがある。この場合には、クライアントから受信されたメッセージがいずれの中間コンポーネントによっても改変されていないことをサーバが確認することが重要である。これにより、第１のメッセージ・フォーマットに対してメッセージから情報の幾つかを除去する、第２のメッセージ・フォーマットへの変更によって、いずれの中間コンポーネントについても問題が生じないことが確実になる。サーバが、クライアントとサーバとの間でメッセージが改変されていないことを確認できないか、又は、メッセージが改変されていることを発見した場合には、サーバは、第２のメッセージ・フォーマットへの交換を開始しない。サーバは、最後のサーバである場合か、又は、チェーン内の次のサーバが既に交換された場合には、安全に交換することを要求することができる。

通信システムの概略図である。 通信システムの概略図である。 システムでの通信フローを示す図である。 通信システムを動作させる方法のフローチャートである。 通信システムの更に別の実施形態の概略図である。

ここで、本発明の実施形態を、添付の図面を参照して単なる例として説明する。

通信システムの例が図１に示される。システムは、クライアント１０、サーバ１２及び中間コンポーネント１４を含む。クライアント１０は、メッセージ１６をサーバ１２に送るように動作可能である。種々のマシン１０、１２及び１４は、インターネットのような大きな通信ネットワークの一部を形成しており、このネットワークでは、多数のマシンが幾つかの適切なネットワーク技術によって相互接続される。この通信システムにおけるクライアント又はサーバとしてのマシンの指定は、論理的な指定であることに留意されたい。メッセージ１６を発信するマシン１０はクライアントであり、受信マシン１２はサーバであるが、いずれのマシンも、サーバとなる別のマシンに要求している場合にはクライアントとなり得る。

メッセージ１６の構造は、通信システムによって用いられている特定のプロトコルによって決定される。これは、例えば、ＸＭＬとすることができる。メッセージ・フォーマットは、データ及び記述タグを含む。タグは、メッセージ１６によって搬送されているデータを記述する。例えば、メッセージ１６は、＜ｌｏｃａｔｉｏｎ＞ＰＡＲＩＳ＜／ｌｏｃａｔｉｏｎ＞を含むことができ、ここで、「ＰＡＲＩＳ」の部分はメッセージ内のデータであり、「＜ｌｏｃａｔｉｏｎ＞」の部分は幾つかの特定のタイプのデータの開始を定義し、「＜／ｌｏｃａｔｉｏｎ＞」の部分はその特定のタイプのデータの終了を定義しており、この場合には、データ・タイプは「ｌｏｃａｔｉｏｎ」と定義される。メッセージ１６の後者の２つの部分は、メッセージ１６内の記述タグである。記述タグの存在は、受信サーバ１２がメッセージ１６を理解し処理する際に役立つ。

図１に示される通信システムは、商用ウェブサイトをサポートするバックエンド・システムの一部とすることができる。ウェブサイトのユーザがウェブサイト上で商品を購入するときに、メッセージ１６は、システム内を回って異なるマシン間を流れる。例えば、１つのマシンは、主にクライアント・アカウントの詳細を格納するデータベースとして動作することができる。アカウントを有するユーザが買い物を行うときには、ＸＭＬフォーマットの１つ又は複数のメッセージ１６が、そのマシンによる処理のために特定のマシンに送られる。負荷の高いウェブサイトの場合には、これにより、多数のメッセージ１６が生成されることになる。

図２は、クライアント１０及びサーバ１２を有する通信システムの一部を示すものであり、ここでは、多数のメッセージ１６が、クライアント１０からサーバ１２に流れる。多くのアプリケーションにおいて、クライアント１０からサーバ１２に送信されているメッセージ１６の数は、１秒あたり何千ものオーダーになる場合がある。これらのメッセージ１６の各々は、クライアント１０とサーバ１２との間のバンド幅を用いる。ネットワーク状況において、ネットワークの使用可能なバンド幅は減少し、及び／又は、ネットワークの待ち時間は増大し、そのいずれも、通信システム又はネットワークに依存する他のいずれかのシステムの動作について、性能に影響を与える。

好ましい実施形態によれば、クライアント１０とサーバ１２との間の通信チャネルの過負荷と、それによるネットワーク全体の過負荷の問題を軽減するために、通信システムは、メッセージ・フォーマットを交換する能力を有する。適切な状況においては、通信システムは、データ及び記述タグを用いる第１のフォーマットから、単なるデータのみのより簡単な第２のフォーマット、すなわちワイヤ・フォーマットに交換する。記述タグは、メッセージがサーバ１２に送信される前に、クライアント１０によってメッセージ１６から削除される。これにより、メッセージ１６のサイズが減少し、従って、メッセージ１６によって用いられるバンド幅が減少する。大きなＸＭＬメッセージは、記述タグを含まないワイヤ・フォーマット・メッセージと置き換えられる。ワイヤ・フォーマット・バージョンは、ＸＭＬタグが除去された状態の一組のバイトである。

第２のメッセージ・フォーマットへの変更は、通信システムが変更を行うことが望ましいと判断したときに行われる。この判断を行うために、クライアント１０とサーバ１２との間のメッセージ負荷に関する情報が取得される。例えば、通信システムは、クライアント１０からのメッセージ負荷を監視し、メッセージ負荷について統計分析を実行し、統計分析の結果に従ってサーバ１２とクライアント１０との間でネゴシエーションを開始する。１つの好ましい実施形態においては、メッセージ負荷についての統計分析の実行は、クライアント１０からの負荷が所定の閾値を上回ることを判断することを含む。第２のメッセージ・フォーマットに交換するためのトリガとして、１期間あたりの特定のメッセージ数を用いることができる。これにより、要求されるバンド幅が第２のメッセージ・フォーマットへの交換によって減少するときに交換が行われることが確実になる。

通信システム環境において、典型的なクライアント１０は、クライアントによって生成されたいずれの要求メッセージ１６も、一旦送信されると、それらに何が起こるかを知る方法がない。メッセージ１６は、例えば中間コンポーネント１４によって仲介され処理されて判別不能になる場合があり、クライアント１０は、これを認識しない。従って、メッセージ・フォーマット交換はサーバ１２によってのみ開始することができ、すなわち、中間コンポーネント１４がクライアント１０に対するサーバとしての役割をする場合には、中間コンポーネント１４がフォーマット交換を要求することができる。論理的には、中間コンポーネント１４は次に、サーバ１２に対してクライアントとして機能することができる。その場合、サーバ１２は、中間コンポーネント１４に対して、そのフォーマットを交換する要求を開始しなければならない。しかしながら、中間コンポーネント１４が、クライアント１０とサーバ１２との間で単なる仲介体として機能する場合には、中間コンポーネント１４は、クライアント１０に対してフォーマット交換を要求しない。フォーマット交換のネゴシエーションのためのプロトコルは、以下に説明され、図３に示される基本ステップからなる。クライアント１０は、例えばＸＭＬフォーマットでメッセージをサーバ１２に送信し、サーバ１２は、クライアント１０に返信することができる。

サーバ１２は、各々のクライアント１０からの負荷を追跡し、経験的統計分析技術を用いて、どのクライアントのメッセージ負荷がＸＭＬメッセージからワイヤ・フォーマット・メッセージへの交換による利益を享受するのに十分な程大きいかを決定する。サーバ１２は、このクライアントのメッセージ１６が通過するときにメッセージを追跡し、それらが、現在のフォーマットのメッセージ１６を待っている別のプロセスによって改変されていないことを確認する。サーバ１２が、メッセージに関与するいずれかのコードが新しいワイヤ・フォーマットをサポートできるためにメッセージ・フォーマットが実際に交換される可能性があることを確認したときには、サーバ１２は、クライアント１０とネゴシエーションを行うことができる。

ネゴシエーションにおいては、サーバ１２は、クライアント１０とハンドシェイクを開始して、クライアント１０がプロトコル交換をサポートすることを確認する。クライアント１０が、定義されたワイヤ・フォーマットをすでにサポートしているか、又は、クライアント１０が、例えばインタープリタ型言語環境において動的に交換することができる場合には、サーバ１２は、サーバ１２が交換することを期待するクライアント１０にフォーマットの記述を送る。ワイヤ・フォーマットが承諾されてインスタンスが作成されると、サーバ１２は、いつ交換すべきかをクライアント１０に通知し、各々の主体は、新しいワイヤ・フォーマットに交換する。サーバ１２は、交換して元のフォーマットに戻すようにクライアント１０に単に通知することによって、いつでも承諾を無効にすることができる。交換が行われると、それ以降のメッセージはワイヤ・フォーマットのものとなる。

図４は、通信システムを動作させる方法を要約したものである。本方法は、最初に、データ及び記述タグを含む第１のフォーマットのメッセージ１６をクライアント１０から送信するステップＳ１と、次に、メッセージ１６をサーバ１２で受信するステップＳ２とを含む。ステップＳ３において、サーバ１２は、サーバ１２と、メッセージ１６を受信しているクライアント１０との間で、メッセージ・フォーマット交換の問題に関するネゴシエーションを開始する。このネゴシエーションは、両方のマシンがサポートするいずれかのプロトコルに応じて、サーバ１２とクライアント１０との間のハンドシェイクの形態をとることができる。

ステップＳ４において、クライアント１０は、メッセージ・フォーマット交換を受け入れることが可能であることを示し、クライアント１０が第２のメッセージ・フォーマットをすでに認識しているか又はクライアント１０が動的なフォーマット交換をサポートすることができるため、新しいフォーマットに従ってメッセージを生成する。クライアント１０が後者の場合には、サーバ１２は、サーバ１２がクライアント１０に対して採用することを望む新しいフォーマットの記述をクライアント１０に送る。クライアント１０は、次に、この記述をローカルに格納する。ステップＳ５において、サーバ１２は、メッセージ・フォーマットを交換するようにクライアント１０に指示し、ステップＳ６において、クライアント１０は、単にデータからなるいずれかの追加メッセージを第２のフォーマットでサーバ１２に送信する。

図４の方法は、クライアント１０からのメッセージ負荷を監視することと、メッセージ負荷について統計分析を実行することと、統計分析の結果に従ってサーバ１２とクライアント１０との間でネゴシエーションを開始することとをさらに含むことができる。メッセージ負荷についての統計分析の実行は、クライアント１０からの負荷が所定の閾値を上回ることを判断することを含む。従って、ステップＳ３の前に、サーバ１２は、クライアント１０がより効率的な第２のメッセージ・フォーマットへの交換に適応することを判断しなければならない。これは、関係するクライアント１０によってもたらされる負荷を監視することによって行うことができる。

ウェブ・サービス記述言語（ＷＳＤＬ）は、ウェブ・サービスを記述するためのモデルを提供するＸＭＬベースの言語である。ＷＳＤＬは、サービスをネットワーク・ポートの集合と定義し、ＸＭＬフォーマットを提供する。メッセージは、やりとりされているデータの抽象的な記述であり、ポート・タイプは、サポートされる動作の抽象的な集合である。特定のポート・タイプについてのプロトコル及びデータ・フォーマット仕様は、再利用可能なバインディングを構成し、動作及びメッセージは、ネットワーク・プロトコル及びメッセージ・フォーマットにバインドされる。このように、ＷＳＤＬは、ウェブ・サービスへの公共インターフェースを記述する。ＷＳＤＬは、インターネット上でウェブ・サービスを提供するために、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）及びＸＭＬスキーマと組み合わせて用いられることが多い。ウェブ・サービスに接続するクライアント・プログラムは、ＷＳＤＬを読み込んで、どの機能がサーバ上で利用可能であるかを判断することができる。用いられるいずれかの特別なデータ・タイプは、ＸＭＬスキーマの形でＷＳＤＬファイルに組み込まれる。次いで、クライアントは、ＳＯＡＰを用いて、ＷＳＤＬ内に挙げられた機能の１つを実際に呼び出すことができる。

図５は、セキュリティ上の理由で少なくとも実際の物理マシン及びポートを除去することによって、内部ＷＳＤＬ２４を外部クライアント１０による使用により適した形に変換する中間コンポーネント１４（バス）にＷＳＤＬをどのように配置することができるかを示す。新しい外部ＷＳＤＬはクライアント１０によってダウンロードされ、クライアント１０は、新しい外部ＷＳＤＬを用いて、クライアント１０が他のいずれかの言語方法であるＷｅｂサービス１２を呼び出すことを可能にするスタブ１８を生成する。このスタブ１８は、バイナリ・パラメータを採用し、それらをＸＭＬ ＳＯＡＰ構造内にラップし、それらを外部ＷＳＤＬ２２によって定義された所定のターゲット（例えば、ＨＴＴＰポート又はジャバ・メッセージング・サービス（ＪＭＳ）キュー）に送ることによって機能する。

ＷＳＤＬがバス１４に到着したときに、ユーザは、メッセージを途中で遮って、メッセージの内容を変更するか、又はメッセージを全く異なるサービス１２に経路変更する機会を有する。メッセージは、バス１４を通過して呼び出し元２０に到着し、呼び出し元２０は、ＳＯＡＰメッセージを変換して、ＷＳＤＬによって記述されたバイナリ機能の実際の呼び出しを可能にするバイナリ形式に戻す。バイナリの結果は、ＳＯＡＰ応答の中に組み込まれ、バスを通じてクライアント１０に返送される。

フォーマット交換の可能性からの利益を享受するために、システムは、サービス１２が始めからワイヤ・フォーマットを用いるように管理者がサービス１２を構成できるようにするか、又は、バス１４が特定のサービス１２の負荷を監視して、性能上の理由からフォーマットを交換することが有益であるかどうかを判断できるようにする。バス１４は、幾つかの簡単な規則に従って、例えば、外部ＷＳＤＬ２２のＷＳＤＬポートと内部ＷＳＤＬ２４のＷＳＤＬポートとを比較し、メッセージが途中で変更されなかったことを確認することによって、フォーマットを交換することが可能かどうかを決定することができる。コンポーネントがメッセージを「仲介」している場合には、この仲介体は、ワイヤ・フォーマット・メッセージをサポートできるかどうかを調べるように問い合わせを行うことができる。

ワイヤ・フォーマットに交換することが決定されると、クライアント１０が用いているスタブ１８には、クライアントのバイナリ・データをＳＯＡＰメッセージ内にラップしていないがメッセージをバス１４に直接送ることを通知するメッセージが送られる。バス１４は、次に、メッセージを呼び出し元２０に真っ直ぐ転送し、呼び出し元２０は、元のデータを用いてターゲット・サービス１２を直接呼び出す。システムが変更され、例えば仲介体がこのサービスのためにシステムに追加された場合には、クライアントのスタブ１８に、メッセージのＳＯＡＰフォーマットに交換して戻すように通知するメッセージを送ることができる。

１０：クライアント
１２：サーバ（サービス）
１４：中間コンポーネント（バス）
１６：メッセージ
１８：スタブ
２０：インボーカ
２２：外部ＷＳＤＬ
２４：内部ＷＳＤＬ

Claims (11)

1. サーバ及びクライアントを含む通信システムを動作させる方法であって、
   データ及び記述タグを含む第１のフォーマットのメッセージを前記クライアントから送信するステップと、
   前記メッセージを前記サーバで受信するステップと、
   メッセージ・フォーマット交換が望ましいかどうかを判断するステップと、
   メッセージ・フォーマット交換が望ましいと判断したときに、前記サーバと前記クライアントとの間でメッセージ・フォーマット交換に関するネゴシエーションを開始するステップと、
   前記クライアントがメッセージ・フォーマット交換を受け入れることが可能であることを示すステップと、
   メッセージ・フォーマットを交換するように前記クライアントに指示するステップと、
   データからなり、前記記述タグを含まない第２のフォーマットの追加メッセージを前記クライアントから送信するステップと
   を含む方法。
2. 前記判断するステップは、前記クライアントからのメッセージ負荷を監視することと、前記メッセージ負荷について統計分析を実行することとを含み、前記統計分析に従って、前記サーバと前記クライアントとの間で前記ネゴシエーションが開始される、請求項１に記載の方法。
3. 前記メッセージ負荷についての前記統計分析の実行は、前記クライアントからの前記負荷が所定の閾値を上回ることを判断することを含む、請求項２に記載の方法。
4. 前記第２のフォーマットの記述を前記クライアントに送信することをさらに含む、請求項１、請求項２又は請求項３のいずれかに記載の方法。
5. 前記メッセージが前記クライアントと前記サーバとの間で改変されていないことを確認することをさらに含む、請求項１乃至請求項４のいずれかに記載の方法。
6. サーバ及びクライアントを含む通信システムであって、
   前記クライアントは、データ及び記述タグを含む第１のフォーマットのメッセージを送信するように構成され、
   前記サーバは、前記メッセージを受信し、メッセージ・フォーマット交換が望ましいかどうかを判断し、メッセージ・フォーマット交換が望ましいと判断したときに、前記サーバと前記クライアントとの間でメッセージ・フォーマット交換に関するネゴシエーションを開始するように構成され、
   前記クライアントは、メッセージ・フォーマット交換を受け入れることが可能であることを示すように構成され、
   前記サーバは、メッセージ・フォーマットを交換するように前記クライアントに指示するように構成され、
   前記クライアントは、データからなり、前記記述タグを含まない第２のフォーマットの追加メッセージを送信するように構成される、
   システム。
7. 前記サーバは、前記クライアントからのメッセージ負荷を監視し、前記メッセージ負荷について統計分析を実行し、前記統計分析に従って、前記サーバと前記クライアントとの間で前記ネゴシエーションを開始するようにさらに構成される、請求項６に記載のシステム。
8. 前記サーバは、前記メッセージ負荷についての前記統計分析を実行するときに、前記クライアントからの前記負荷が所定の閾値を上回ることを判断するように構成される、請求項７に記載のシステム。
9. 前記サーバは、前記第２のフォーマットの記述を前記クライアントに送信するようにさらに構成される、請求項６、請求項７又は請求項８のいずれかに記載のシステム。
10. 前記サーバは、前記メッセージが前記クライアントと前記サーバとの間で改変されていないことを確認するようにさらに構成される、請求項６乃至請求項９のいずれかに記載のシステム。
11. 請求項１〜５の何れか１つに記載の方法の各ステップをコンピュータに実行させる、コンピュータ・プログラム。

Images