JP5052522B2 - ウェブ・サービス通信の履歴を駆使した最適化のためのシステム及び方法 - Google Patents

Description

本発明は一般にインターネット／ワールド・ワイド・ウェブなどのネットワーク通信に関し、より具体的には、ウェブ・ベースのサービス（ＷＳ）を提供し消費するエンティティに係る通信帯域幅及びオーバーヘッドを縮小するためのシステム及び方法に関する。

ウェブ・サービス（ＷＳ）は、遠隔のマシーン上のアプリケーション・ロジックへのプログラム的アクセスを提供するために開発された一組の規格を含んだプログラム・モデルである。このアプリケーション・ロジックは、あらゆるプラットフォーム上のクライアントにより、且つ、あらゆるプログラム言語でアクセス可能である。中核となるウェブ・サービス構築ブロックの一つはＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）であり、これは、限定的ではないがＲＰＣ（リモート・プロシージャ・コール）メッセージをＸＭＬドキュメントとして送信することを可能にしてウェブ・サービスの機能を呼び出す標準的なフレームワークである。ＷＳはインターネット（又はウェブ）上ばかりでなく企業内ネットワーク上でも、同じサイト又は同じ部屋に配置されているマシーンの間でさえも、広く用いられていることが知られている。当初ＷＳはウェブ全域でのアクセス用に設計されたが、現在、ＷＳはイントラネット、即ち企業内ネットワークの中で普及している。

図１（Ａ）は、ロジック・コンポーネントを含む典型的なＷＳアーキテクチャ１０を示す。図１（Ａ）に示すように、ウェブ・サービス・プロバイダ１８はウェブ・サービスの展開の関与し、それらを、サービス登録及びウェブ・サービスの発見に関与するウェブ・サービス・ブローカーとともに発行する。具体的には、ブローカーは種々のサービスのタイプ、説明、及び、サービス要求者が必要なサービスを見出して予約する助けとなるサービスのロケーションを列挙する。ウェブ・サービス要求者１２は、サービス・ブローカー１５を用いてウェブ・サービスのロケーションを見出してサービス呼び出しに関与し、必要なサービスを呼び出し、それをサービス・プロバイダにより実行する。さらに具体的には、非特許文献１に記載されているように、ウェブ・サービス・プロバイダ１８は、ウェブ・サービス・ランタイム環境として機能しサービス・プロバイダのホストとして働くサービス・コンテナ２８を含む。サービス・コンテナ２８は、具体的には、クライアント通信用の環境を定義し、標準化された方法を実施して、ウェブ・サービス定義言語（ＷＳＤＬ）として知られる、ウェブ・サービス記述用の標準的なＸＭＬスキーマ・ベースの仕様を用いてネットワーク・サービスを記述する。さらに、これは、サービス・レジストリ３０ａ、ｂによりサービス記述の登録を扱う。それらレジストリは、ユニバーサル・ディスクリプション、ディスカバリー及びインテグレーション（ＵＤＤＩ）標準３０ａ（www.UDDI.org）、又は、レジストリ・サービス、対話プロトコル、及びメッセージ定義を定義するｅｂＸＭＬレジストリ３０ｂを実施するレジストリを含み、さらに共有情報に対するストレージとして機能する（www.ebXML.org）。ウェブ・サービス要求者１２は、サービス・レジストリを調べて必要なサービスを見出し、それをＳＯＡＰメッセージング２５を用いてサービス・プロバイダから呼び出すことにより、クライアント・ランタイム環境として機能する、サービス配信コンポーネント２２を含む。既知のように、ＳＯＡＰプロトコルは以下の要素を含む。即ち、ＳＯＡＰメッセージの他の要素のコンテナとして機能するＳＯＡＰエンベロープと、下層のトランスポート・プロトコル用のＳＯＡＰトランスポート・バインディングと、メッセージ内のデータを表すための一組のＳＯＡＰ符号化規則（アプリケーション専用データ・タイプのインスタンスをＸＭＬメッセージにマッピングする）と、アプリケーション対話パターンとを含むが、そのパターンは、殆どの場合ＲＰＣ規則であって、ＲＰＣ要求及び応答用の表現を定義し、リモート・プロシージャ・コールをシリアル化する方式として定義されＳＯＡＰメッセージとして応答するＲＰＣ規則によるものである。（Ｊａｖａ、並びに全てのＪａｖａベースの登録商標及びロゴは、米国、他の国、又は両方におけるＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社の登録商標である。）

図１（Ｂ）は、従来のＳＯＡＰ ＲＰＣ実施における例示的なクライアント・サーバ間対話を示す。図１（Ｂ）に示すように、クライアント１２はサービス・プロバイダ（又は単に「サービス」）１８と、インターネットなどのネットワーク９９上で、ＳＯＡＰ／ＨＴＴＰプロトコル（即ち、ＨＴＴＰトランスポート・バインディングを用いるＳＯＡＰメッセージ・プロトコル）を用いて対話する。ＳＯＡＰメッセージング・プロトコルは、メッセージ２５を、サービス・プロバイダ・エンドポイント１８とサービス要求者エンドポイント１２の間で交換することを可能にする。これは、ＨＴＴＰ（インターネット）メッセージ・トランスポート及び／又はＲＰＣ規則によるＳＯＡＰ使用法である。ＳＯＡＰはＨＴＴＰ上でメッセージをどのように交換すべきかを規定するが、ＨＴＴＰの代わりに任意の通信プロトコル（例えば、ＳＭＴＰ、ＷｅｂＳｐｈｅｒｅ（登録商標）ＭＱ、Ｒａｗ Ｓｏｃｈｅｔなど）又は方法を使用できることを理解されたい。（ＷｅｂＳｐｈｅｒｅは、米国及び他の国におけるインターナショナル・ビジネス・マシーン社の登録商標である）。この従来の実施においては、クライアント１２は、サービス・プロバイダ１８へのリモート・プロシージャ・コールを、各々のコール毎に１つのメッセージを送信することにより行う。同様に、サービス・プロバイダ１８は、これらのコールに対して、各々の応答毎に１つのメッセージをクライアント１２に返信することにより応答する。ウェブ・サービスの主技術は、ＳＯＡＰメッセージを送信する前にそれを構成すること、及びＳＯＡＰメッセージを受信した後にそれを解読することの、それぞれのプロセスである。ＳＯＡＰメッセージに関するこれらのプロセスは、一般に、ＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）又は類似のツリー状オブジェクトをメモリ内に造ることによって実施される。このようにして、プロセスは、メッセージのテキスト表現を考慮せずに、ＳＯＡＰメッセージのツリー表現を用いて実施することができる。

ＸＭＬのＡＳＣＩＩ性質のために、ウェブ・サービスの実施は著しい帯域幅要件と通信オーバーヘッドを組み込む。さらに、ＷＳは自己記述的であり、クライアントとサーバは要求及び応答メッセージの形式と内容を認識することだけが必要である。ＷＳメッセージ形式の定義はメッセージと共に伝送され、外部のメタデータ・リポジトリ又はコード生成ツールは不要である。従って、何れのＳＯＡＰメッセージのコンテンツを解析するときにも、オーバーヘッドが当たり前となる。ＳＯＡＰとＸＭＬを使用することは、非常に大きなメッセージに変換する、即ちＴＣＰ／ＩＰスタック内の著しいオーバーヘッドと大きな帯域幅を使用するばかりでなく、ＳＯＡＰのリッチ構造のために、著しい構文解析オーバーヘッドにもなる。さらにその上、ＨＴＴＰは、ＷＳの最も普通に用いられるトランスポートであるが、付加的な通信及び構文解析オーバーヘッドを加える。

従来のデスクトップ／サーバ・プラットフォームには、これらのオーバーヘッドの影響は、ギガビット・イーサネット・ネットワーク、より高速のＣＰＵ及びより多くのメモリを用いることによって、そして初期のＳＯＡＰ実施、例えばアパッチ・アクシス・エンジンに存在する性能ボトルネックを除去することにより、十分に補われてきた。残念ながらリソースが限定されたモバイル・プラットフォーム、例えば、携帯電話、ＰＤＡ、又はラップトップ型コンピュータなどは、これらの解決法からは利益を得ない。ハードウェア指向の解決法は一般に、これらのエネルギーが限定されサイズが限定されたデバイスには適用できないが、何故ならより高速のネットワーク又はＣＰＵ，又はより多くのメモリは、より大きな電力を消費するので、所望のフォーム・ファクタに常に適合するとは限らないからである。同様に、ＳＯＡＰエンジンの実施は、それらのメモリ・フットプリントを縮小するための付加的な最適化を必要とする。

典型的なＢ２Ｂウェブ・サービス展開のシナリオにおいては、例えば、ウェブ・サービス・クライアントはサービス・エンド・ポイントに対して幾つかのコールを行うことができ、これらのコールは呼び出し毎には変化しない幾つかのパラメータを有する可能性がある。例えば、数人の買手がウェブ・サービス・コールを用いて売手のウェブ・サービス・エンド・ポイントと対話し、発注書を売手に送信する場合を考えてみよう。各々の発注書は幾つかの欄を有することができ、これらの欄の多くは買手を記述することができるので、特定の買手に対して、各々の呼び出しのために同じにすることになる。この種類のパラメータ繰り返しは、主として、ウェブ・サービスのステートレス特性によるものである。サービス・エンド・ポイントとクライアントの組合せに特有のステートを保存することは、簡単なステートレス・クイックジップ（ｑｚｉｐ）型の圧縮によって可能であるよりも優れた、ネットワーク・トラフィックの圧縮比を可能にすることができる。

ＷＳサービス、特にメッセージの圧縮を促進する様々な技術が当技術分野で知られている。そのような技術の例は、例えば、以下に列挙する通りである。
１）非特許文献２は、凡そ同じ速さでｑｚｉｐの約２倍の圧縮比を達成する、ＸＭＬデータ圧縮用ツールＸＭｉｌｌを記述している。ＸＭｉｌｌはデータから構造を分離し、関連データ項目をグループ化し、専用コンプレッサの集合を適用する。しかし、ＷＳメッセージが生成された後にのみ適用できるので、メッセージ待ち時間が増加する。
２）非特許文献３は、ＸＭＬを２進コード化されたものと、残りのインラインでコード化されたものとの所定のトークンに分割するＷＡＰ Ｂｉｎａｒｙ ＸＭＬ（ＷＢＸＭＬ）について記述している。トークン表は送信／受信側の両方に保存される。初めはＷＡＰに対するトークン表だけが使える。ＳｙｎｃＭＬ及びＤＲＭＲＥＬ（デジタル著作権管理著作権表示言語）に対する付加的な表が後で規定される。主要な利点はＷＢＸＭＬを意識したＳＡＸ構文解析プログラムは非常に小さなオーバーヘッドを有することである。主要な欠点は、ＸＭＬダイアレクトに対するトークン表は両エンドに存在しなくてはならないので、所定のＸＭＬダイアレクトに対してしか使用できないことである。
非特許文献４は、圧縮するためのテキストから構造を分離して関連するスキーマの利点を利用するＭｉｌｌａｕについて記述している。インライン・テキストを圧縮しＸＭＬ基本形を推測する際にＷＢＸＭＬに拡張される。ＭｉｌｌａｕはＷＢＸＭＬと同じ欠点を有する。
非特許文献５は、論文の初めの部分でＳＯＡＰ（．ＮＥＴ及びＪａｖａ）、ＲＭＩ−ＩＩＯＰ、Ｃｏｒｂａ、ＲＭＩ、及びｑｚｉｐｅｄ ＳＯＡＰの帯域幅要件を比較することを記述している。第２の部分は、メッセージと以前のメッセージの間の差分だけを送信する差分ＳＯＡＰ圧縮を記述している。実際には、差分コード化は、初めにＷＳＤＬファイルを用いてスケルトン・メッセージの集合を計算し、次に、メッセージと予測されたスケルトンの間の差分を計算し、その差分を送信するように働く。差分コード化において、コード化及びデコードのオーバーヘッドは相当に大きくなる可能性がある。
５）非特許文献６は、圧縮が、特にサーバをオーバーロードにするとき、いかに有益ではないかを記述している。
６）非特許文献７は、典型的な圧縮ツールによると、データを圧縮して送信する方が非圧縮データを送信するよりもいかに大きな電力を費やすかを記述している。ハードウェアを意識した圧縮ツールの最適化が圧縮に費やされる電力を削減する。この論文は圧縮スキームを注意深く選択しなければならないことを示す。
７）非特許文献８は、２つの最適化法、（１）Ｎａｍｅ Ｓｐａｃｅ Ｅｑｕｉｖａｌｅｎｃｙ（ＮＰＥ）、及び（２）ＷＳＤＬ Ａｗａｒｅ Ｅｎｃｏｄｉｎｇ（ＷＡＥ）を提案している。ＮＰＥは、ＸＭＬメッセージを異なるが等価な形式に回復することを可能にする。ＷＡＥは、モバイル・デバイス・ゲートウェイを必要とし、これがＷＳＤＬファイルに記述されるオペレーションに対するコーディング表を作成する。ＮＰＥは有意な圧縮を加えるようには見えず、一方ＷＡＥはゲートウェイを必要とする。
８）非特許文献９は、以前に見られた構文構造を識別するために履歴を利用し、一致する構造構文を再使用するＸＭＬパーサ（「Ｄｅｌｔａｒｓｅｒ」）について記述している。Ｄｅｌｔａｒｓｅｒパーサは受信側ノード上の構文解析オーバーヘッドを縮小するが、帯域幅要件を縮小せず、また送信ノード上のメッセージ生成のオーバーヘッドを縮小しない。

"Ｄｅｖｅｌｏｐｉｎｇ ＪａｖａＴＭ Ｗｅｂ Ｓｅｒｖｉｃｅｓ"（Ｒａｍｅｓｈ Ｎａｇａｐｐａｎ他、Ｗｉｌｅｙ Ｐｕｂｌｉｓｈｉｎｇ，Ｉｎｃ．２００３）。 Ｈａｒｔｍｕｔ Ｌｉｅｆｋｅ及びＤａｎ Ｓｕｃｉｕ、「ＸＭｉｌｌ：ａｎ Ｅｆｆｉｃｉｅｎｔ Ｃｏｍｐｒｅｓｓｏｒ ｆｏｒ ＸＭＬ Ｄａｔａ」（ＡＣＭ ＳＧＭＯＤ ２０００）。 ＷＡＰ Ｂｉｎａｒｙ ＸＭＬ（ＷＢＸＭＬ）（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｗｂｘｍｌ／）１９９９年６月。 Ｍａｒｃ Ｇｉｒａｒｄｏｔ及びＮｅｅｌ Ｓｕｎｄａｒｅｓａｎ、「Ｍｉｌｌａｕ：ウェブ上のＸＭＬの効率的な表現及び交換のためのコード化形式」（ｈｔｔｐ：／／ｗｗｗ９．ｏｒｇ）２０００年５月。 Ｃｒｉｓｔｉａｎ Ｗｅｒｎｅｒ、Ｃａｒｓｔｅｎ Ｂｕｓｃｈｍａｎｎ、及びＳｔｅｆａｎ Ｆｉｓｃｈｅｒ、「差分コード化を用いたＳＯＡＰメッセージの圧縮」（ウェブ・サービスに関するＩＥＥＥ国際会議、２００４年７月）。 Ｍ．Ｔｉａｎ、Ｔ．Ｖｏｉｇｔ、Ｔ．Ｎａｕｍｏｗｉｃｚ、Ｈ．Ｒｉｔｔｅｒ、及びＪ．Ｓｃｈｉｌｌｅｒ、「モバイル・ウェブ・サービスに関する性能考察」（Ｅｌｓｅｖｉｅｒ Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｊｏｕｒｎａｌ、第２７巻、１１号、２００４年７月１日、ページ１０９７−１１０５）。 Ｋｅｎｎｅｔｈ Ｂａｒｒ及びＫｒｓｔｅ Ａｓａｎｏｖｉｃ、「電力を意識した無損失データ圧縮」（Ｍｏｂｉｓｙｓ ２００３、２００３年５月）。 Ｎａｒｅｓｈ Ａｐｔｅ、Ｋｅｉｔｈ Ｄｅｕｔｓｃｈ、及びＲａｖｉ Ｊａｉｎ、「無線ＳＯＡＰ：モバイル無線ウェブ・サービスの最適化」（ポスター、ｗｗｗ２００５．ｏｒｇ、２００５年５月）。 Ｔｏｓｈｉｒｏ Ｔａｋａｓｅ、Ｈｉｓａｓｈｉ Ｍｉｙａｓｉｔａ、Ｔｏｙｏｔａｒｏ Ｓｕｚｕｍｕｒａ、及びＭｉｃｈｉａｋｉ Ｔａｔｓｕｂｏｒｉ、「バイト・シークエンス記憶に基づく、適応性があり、迅速で、安全なＸＭＬパーサ」（ｗｗｗ２００５．ｏｒｇ、２００５年５月）。 Ｗ３Ｃ（登録商標）Ｎｏｔｅ「ウェブ・サービス記述言語（ＷＳＤＬ）１．１」２００１年３月１５日。 Ｗ３Ｃ（登録商標）Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ「拡張可能なマークアップ言語（ＸＭＬ）１．０（第２版）」（２０００年１０月６日）（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ）。 Ｗ３Ｃ（登録商標）Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ、ＳＯＡＰバージョン１．２、パート０：手引き（２００３年６月２４日）。 Ｗ３Ｃ（登録商標）Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ、ＳＯＡＰバージョン１．２、パート１：メッセージング構造（推奨）。 Ｗ３Ｃ（登録商標）Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ、ＳＯＡＰバージョン１．２、パート２：アジャンクト（推奨）。 Ｗ３Ｃ（登録商標）Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ、ＳＯＡＰバージョン１．２、パート２：仕様アサーション及びテスト・コレクション（推奨）。 Ｗ３Ｃ（登録商標）Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ、ＳＯＡＰメッセージ送信最適化機構（２００５年１月２５日）。 Ｗ３Ｃ（登録商標）Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ、ＸＭＬ−バイナリ最適化パッケージング。 Ｗ３Ｃ（登録商標）ドキュメント・オブジェクト・モデル（ＤＯＭ）（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＤＯＭ／）。

配備されたウェブ・サービス環境において、ＳＯＡＰメッセージング処理のオーバーヘッドを有意に縮小するための１つ又は複数の最適化法を与えるシステム及び方法が提供されることが好ましい。
配備されたウェブ・サービス環境において、ＳＯＡＰメッセージング通信のオーバーヘッドを有意に縮小するための１つ又は複数の最適化法を与えるシステム及び方法が提供されることが好ましい。
既存のＷＳ／ＳＯＡＰメッセージング圧縮スキームよりも有意に低い電力及び待ち時間損失で同等の圧縮をもたらす、ＷＳ／ＳＯＡＰメッセージング圧縮最適化スキームを与えるシステム及び方法が提供されることが好ましい。

本発明は、好ましい実施形態により、配備されたウェブ・サービス環境におけるＳＯＡＰメッセージングのオーバーヘッドを有意に縮小するための１つ又は複数の最適化法を与えるシステム、方法及びコンピュータ・プログラムに向けられる。

より具体的には、本発明は、好ましい実施形態により、２つのエンドポイント間のＷＳトラフィックの反復性を利用して、２つのデバイスのＳＯＡＰ及びＨＴＴＰエンジン内の幾つかの層にわたる一連の最適化法を識別する方法を提供する。より具体的には、両方のデバイスは、それぞれの方向に送受信された最新の「Ｎ」個のＷＳ関連バイトの履歴を保持することが好ましい。履歴のサイズは両方向に対して等しい必要はないが、一方向に関する送信及び受信エンドは正確に等しい履歴サイズを使用する必要がある。信頼度が高く順序正しいＷＳの配布は、２つのエンドが共通履歴に関する一致したビューを有することを保証する。

通信オーバーヘッドは、ＳＯＡＰメッセージ内の明確に規定された要素を以前のメッセージ内のリファレンスで置き換えることにより縮小することが好ましい。送信及び受信エンドの両方がそれらの履歴バッファ内で、リファレンスをそれらが参照するストリングで置き換えることが好ましい。これは、同じ方向に送信されるその後のメッセージにおける同じ又は類似の圧縮を可能にする。

従って、本発明の１つの態様により、メッセージ通信を行うためのシステム、方法及びコンピュータ・プログラムが提供される。メッセージ通信を行う方法は、送信側デバイスと受信側デバイスのそれぞれにおいて、送信され受信されるメッセージ・ストリングに対応するキャラクタ・ストリングをそれぞれの送信側及び受信側デバイスにストアするための、一定量の第１キャッシュ・ストレージを割り当てるステップと、通信すべきメッセージを表し、送信側デバイスにおける第２キャッシュ・ストレージ内でのストレージに適合する、中間データ構造体を構築するステップと、構築された中間データ構造体に基づいて通信すべきメッセージ・ストリングを構築するステップと、その後の通信を行う各々のメッセージに対して、構築中の最新メッセージに関する構築された中間データ構造体内の部分を、前の通信済みメッセージ・ストリングに対応する構築された中間データ構造体中に存在する類似部分と同一の部分によって識別するステップと、最新の構築された中間データ構造体に基づいて通信を行うべきメッセージ・ストリングを構築し、メッセージ・ストリング中の各々の識別された部分を、前の通信済みメッセージに付随する同一のキャラクタ・ストリング部分に対応する第１キャッシュ・ストレージ内のロケーションに対するリファレンス・インジケータで置き換えるステップと、受信側デバイスにおいて、受信メッセージ・ストリング内のリファレンス・インジケータを識別し、受信側デバイスにおける第１キャッシュ・ストレージ内にストアされた１つ又は複数のキャッシュされた同一のキャラクタ・ストリングで置き換えて受信メッセージを構築するステップとを含み、その際、送信及び受信デバイスにおけるメッセージ通信インフラストラクチャのリソースは保存される。

本発明の１つの実施形態において、中間データ構造体は、１つ又は複数のサブツリー又はツリー断片を含む識別されたストリング部分を有する、メッセージの構造化されたツリー表現を含む。

本発明の１つの実施形態において、送信側及び受信側デバイスにおけるキャッシュ履歴ストレージの割り当ては、デバイス間の初めのハンドシェイク・プロトコルを実施して割り当てられるべき第１キャッシュ・ストレージ量に関する通信を行うステップを含む。さらにこの実施形態に対しては、受信側デバイスにおける第１キャッシュ・ストレージの割当量は、送信側デバイスにおいて割り当てられた第１キャッシュのサイズと少なくとも同じであることが好ましい。

本発明の１つの実施形態において、リファレンス・インジケータは、前の通信済みメッセージ・ストリングに対応する構築された中間データ構造体中に存在する類似のサブツリー又は断片部分に同一の、構築された中間データ構造体中の識別されたサブツリー又は断片部分に対応するシリアル化されたメッセージ・ストリング部分の属性を指示する。
属性は、前の送信済みメッセージの指示、前の通信済みメッセージのツリー表現を識別するメッセージＩＤ、識別されたツリーに対応するストリングの長さ、及び、前の通信済みメッセージ内のオフセットの長さのうちの１つ又は複数を含むことができる。

さらに、本発明の１つの実施においては、受信側デバイスにおいて、同一部分の識別は、受信メッセージ・ストリングを構文解析し、受信側デバイスにおける第２キャッシュ・ストレージ内でのストレージのための構造化ツリー表現を構築するステップを含む。構造化ツリー表現はストアされて、次に受信側において受信メッセージを構築するのに用いられる。
有利には、置き換えの候補は通信プロトコル・ヘッダ（例えば、ＨＴＴＰヘッダ）及びＷＳメッセージ（例えば、ＳＯＡＰエンベロープ）の要素を含むことが好ましい。しかし、オペレーション、名称、及びパラメータ又は結果さえも置き換えるさらに進んだ最適化を利用することができる。

別の態様によれば、ウェブ環境においてメッセージ通信を行うための装置が提供され、その装置は、送信側デバイスにおいて受信側デバイスに通信を行うべきＷＳメッセージ・ストリングを生成するためのウェブ・サービス（ＷＳ）スタックの実施をサポートする手段であって、前記の通信を行うメッセージ・ストリングは前記の送信側デバイスにおける第１キャッシュ・ストレージ内にストアされ、且つ、前記の受信側デバイスにおける第１キャッシュ・ストレージ内にストアされる、手段と、受信側デバイスにおいて、この受信側デバイスに通信された受信ＷＳメッセージ要求ストリングに応答するＷＳスタック実施をサポートする手段とを含み、前記の送信側及び受信側デバイスにおける各々のＷＳスタック実施は、送信及び受信されたＷＳメッセージ・ストリング・コンテンツを表す中間データ構造体を構築してストアし、そして構築された中間データ構造体をそれぞれ送信側及び受信側デバイスにおいてローカルにストアし、前記の送信側デバイスにおける前記のＷＳスタック実施は、通信を行うべきメッセージ・ストリングを最新の構築された中間データ構造体に基づいて構築し、メッセージ・ストリング内の各々の識別された部分を、前の通信済みメッセージに付随する同一のキャラクタ・ストリング部分に対応する前記の第１キャッシュ・ストレージ内のロケーションに対するリファレンス・インジケータで置き換える方法を実施し、前記の受信側デバイスにおける前記のＷＳスタック実施は、受信メッセージ・ストリング内のリファレンス・インジケータを識別し、そして前記の受信側デバイスにおける前記の第１キャッシュ・ストレージ内ストアされた１つ又は複数のキャッシュされた同一のキャラクタ・ストリング部分で置き換えて受信メッセージを構築するが、その際、前記の送信及び受信デバイスにおけるＷＳメッセージ通信インフラストラクチャのリソースは保存される。

別の態様によれば、機械により可読であり、且つ、メッセージ通信を行う方法ステップを実行するための機械により実行可能な命令のプログラムを有形に具体化したプログラム・ストレージ・デバイスが提供されるが、このプログラム・ストレージ・デバイスは、送信側デバイスと受信側デバイスのそれぞれにおいて、送信され受信されたメッセージ・ストリングに対応するキャラクタ・ストリングをそれぞれ送信側及び受信側デバイスにおいてストアするための、一定量の第１キャッシュ・ストレージを割り当てるステップと、通信を行うべきメッセージを表し、送信側デバイスにおける第２キャッシュ・ストレージ内でのストレージに適合する、中間データ構造体を構築するステップと、前記の構築された中間データ構造体に基づいて通信を行うべきメッセージ・ストリングを構築するステップと、その後の通信を行う各々のメッセージに対して、構築中の最新のメッセージに関する構築された中間データ構造体中の部分を、前の通信済みメッセージ・ストリングに対応する構築された中間データ構造体中に存在する類似部分に同一の部分によって識別するステップと、通信を行うべきメッセージ・ストリングを前記の最新の構築された中間データ構造体に基づいて構築し、メッセージ・ストリング内の各々の識別された部分を、通信済みの前のメッセージに付随する同一のキャラクタ・ストリング部分に対応する前記の第１キャッシュ・ストレージ内のロケーションに対するリファレンス・インジケータで置き換えるステップと、受信側デバイスにおいて、受信メッセージ・ストリング内のリファレンス・インジケータを識別し、受信側デバイスにおける第１キャッシュ・ストレージ内にストアされた１つ又は複数のキャッシュされた同一のキャラクタ・ストリングで置き換えて受信メッセージを構築するステップとを含み、その際、送信及び受信デバイスにおけるメッセージ通信インフラストラクチャのリソースは保存される。

ここで本発明の好ましい実施形態を、実施例としてだけ、添付の図面を参照しながら説明する。
本発明は、好ましい実施形態により、図１（Ａ）、（Ｂ）に示されるような配備されたウェブ・サービス環境においてＳＯＡＰメッセージングのオーバーヘッドを有意に縮小するための１つ又は複数の最適化法を与えるシステム、方法及びコンピュータ・プログラムを提供する。本明細書において、印刷形態又はオンラインで入手可能であり、引用により本明細書に組み入れられる、以下の論文を引用する。
１．非特許文献１０。
１．非特許文献１１。
１．非特許文献１２。
１．非特許文献１３。
１．非特許文献１４。
１．非特許文献１５。
１．非特許文献１６。
１．非特許文献１７。
１．非特許文献１８。

ＳＯＡＰメッセージング・プロトコルに対する第１の随意の拡張によると、特定の方向、例えば送信に関する履歴サイズを提案する第１の要求メッセージ内に新しいＨＴＴＰ選択肢が設けられる。他の（例えば受信）エンドポイントが拡張を実施するならば、それは、応答方向に関する履歴サイズを伴い、そして場合によっては逆方向に対するより小さな履歴サイズに関する要求を伴って応答することになる。この初めのハンドシェイクはＴＣＰプロトコルに対するＳＡＣＫ（選択的確認）拡張にわずかに類似する。履歴サイズを協定する機能がこのハンドシェイク・プロトコルに加えられている。その後の履歴サイズの調整は、何れかの方向において新しい履歴サイズのバイト数を提案することにより実行される。承認又は拒絶は、応答メッセージ内に表示される。

図２（Ａ）、（Ｂ）は、ＷＳ受信エンドポイント（ＷＳクライアント）１２及びＷＳ送信エンドポイント（ＷＳサーバ）１８の両方が本発明の好ましい実施形態の最適化を実施するかどうかを判断して両エンドにおける履歴サイズを同じ値に設定するために用いられるハンドシェイク・プロトコル４０を具体的に示す。

図２（Ａ）に示すように、ウェブ・サーバ・クライアント１２は初めのハンドシェイク・メッセージ４５ａにおいて履歴サイズに関する値を提案するが、これは付加的にクライアントが提案した最適化を実施することをサーバに示す。ウェブ・サービス・サーバ１８がその最適化を実施して必要な使用可能メモリを有する場合には、それはハンドシェイク応答メッセージ４５ｂ内で同じ履歴サイズ又はより小さな値を返す。そうでない場合には、図２（Ｂ）に示すように、ウェブ・サービス・サーバ１８は提案された履歴サイズを無視する。これを実施するには複数の方法がある。例えば、ＷＳベースの実施は、所定の名称及びシグニチャを有する付加的なオペレーションを利用し、これは最適化を実施する全てのエンドポイントに加えられる。従って、例えば、クライアント１２からの第１コールはこのオペレーションのＷＳ呼び出しとなり、サーバ１８は履歴サイズに関する値を返す（図２（Ａ））か、又は要求を理解できない、即ち、提案された最適化を実施しない場合にはＳＯＡＰ障害を返す（図２（Ｂ））。この実施は、付加的なＷＳ呼び出しを必要とする不利な点を有する。代替的な実施は、上記の協定に対するプロローグ内に新しいＨＴＴＰヘッダ・フィールド又はＸＭＬコメントを用いる。後者の実施には、ハンドシェイク・プロトコル４０が第１アプリケーション呼び出しの背に乗るので、付加的なＭＳ呼び出しは必要としない。ハンドシェイク・プロトコル４０は、後に対話中に履歴サイズを変更するか又は提案された最適化の使用を終了するのに付加的に用いることができる。それらのシナリオにおいては、後者の実施のうちの一つを用いる場合に、ＷＳサーバにより再協定を開始することができる。

ハンドシェイク・メッセージ４５ａにおいて協定されるキャッシュの履歴サイズは、「管理された」メモリ、即ち、ＳＯＡＰメッセージ・ストリング履歴のみをストアするために割り当てられたキャッシュであることを理解されたい。（サブ）ツリーをキャッシュするのに用いられるメモリ（例えば、ツリー・キャッシュ）は、そのコンテンツはストリング・キャッシュ内に保持されるストリングによって決定されるが、このハンドシェイク・プロトコルによっては協定されず、このメモリはクライアント（送信側）及び受信側エンドの両方で同じである必要はない。ＳＯＡＰメッセージ・ストリング履歴に割り当てられるキャッシュだけが、両エンドで同じサイズを有する必要がある。

図３は、本発明の好ましい実施形態の最適化による、送信側のＳＯＡＰ／ＨＴＴＰ処理を説明するフローチャートである。
図３において、送信エンドポイントにおけるＷＳスタックの生成において、１つの実施形態による圧縮が実行される、即ち、ＳＯＡＰメッセージが構築される際にＳＯＡＰメッセージ要素の置き換えが識別される。これは、新しいメッセージを利用可能な履歴と比較することにより機能する典型的なストリング圧縮スキームとは対照的である。より具体的には、送信エンドポイントにおけるＳＯＡＰエンジンの種々のコンポーネントは、ローカル履歴においてなお利用可能なＳＯＡＰコンポーネントの小履歴を保持することが必要となる。この圧縮は、ＳＯＡＰ発信パスと深く結合するので、ＳＯＡＰプロトコルのセマンティクスの利点を十分に利用する。この特徴は、既存のスキームよりも有意に低い電力及び待ち時間損失で同等の圧縮をもたらし、より多く通信されればより多く学習される、即ち、十分な履歴が保持される場合より大きく圧縮されるという付加的な利益を伴う。その結果、適合アルゴリズムを用いて履歴サイズを調整することがさらに可能になる、即ち、クライアント側と受信側が、それぞれの側が維持するキャッシュ履歴サイズの量を再協定することができる。しかし、両側が同じ量のメッセージ・ストリング・キャッシュを維持することを理解されたい。このアルゴリズムが働くためには、受信側は送信側と少なくとも同じ量又はより多くの量のキャッシュを維持する必要がある。

１つの実施形態において、ＳＯＡＰメッセージが図３に示すように生成される送信側において、クライアント・デバイスにおいて実施される方法１００は、送信スタッブを呼び出す典型的なステップを含む。実行コード（ルーチン）及びスタッブがその上で動作する本発明の１つの実施形態により修正されたＷＳスタック・インフラストラクチャはステップ１０２で確立され、そこでトランザクション（例えば、メソッド呼び出し）をサーバ上のＷＳオブジェクトへルーティングすることが可能となり、及び／又はサーバ・オブジェクトと対話してウェブ・サービスを呼び出すことが可能になる。次に、ステップ１０５において、キャッシュ履歴が前のハンドシェイク・プロトコルにより前に協定されている（送信側及び受信側においてＤＯＭ（様）ツリー・データ構造体のコンテンツをストアするために）と想定して、ツリー・キャッシュが空であるかどうかの判断がなされる。このキャッシュは、履歴が構築されていないときに第１メッセージが送信される時点又はその前では、空である可能性がある。ツリー・キャッシュがステップ１０５において空であると判断される場合には、次にステップは、ドキュメントへの動的アクセス及びその更新を可能にする階層的なドキュメント・オブジェクト・モデルＤＯＭ（様）ツリー構造体をステップ１０８において構築し、構築されたツリーをツリー・キャッシュ内にストアするステップを含む。次いで、次のステップ１１３において、ツリーは、例えば、送信側においてストアされたツリー・データ構造体をオリジナルのメッセージ・データ構造体と同一のコピーに再構築して戻すことができるキャラクタ・ストリームに変換するルーチンを実施することにより、シリアル化することができる。最後にステップ１１５において、シリアル化されたバイト・ストリームがＨＴＴＰヘッダに付加（ラップ）され、要求がサーバに送信される。

再び図３を参照すると、ステップ１０５において、本発明の好ましい実施形態の最適化修正により、ツリー・キャッシュが空でない、即ち、第１及び／又は前のメッセージから以前に構築されたＤＯＭ（様）ツリー・データ構造体又はサブツリー又はツリー断片（例えば、ブランチ）を含んだ履歴を含むと判断される場合には、次のステップは、ステップ１２０に示されるように、キャッシュ内の既存のツリー構造体から拡張ツリー構造体を構築するステップを含む。拡張ツリー構造体のストリング表現をセーブするのに利用可能なキャッシュ・サイズの量が利用できない場合には、ステップ１２０において、より古い構築されたツリー又はそれの部分（サブツリー又はツリー断片）を剪定することができる。いずれにしても、拡張ツリー構造体はステップ１２３に示されるようにセーブされる。この最適化において、存在するキャッシュ・ツリー構造体は、以前のツリーの要素（サブツリー又はツリー断片）を用いて構築され、従って、ツリーをスクラッチから構築する必要性をなくし、処理のためのリソースを保存する。ステップ１２６に進むと、メッセージを解析してそのストリング表現を構築するステップにおいて、拡張ツリー構造体はシリアル化され、送信に適したデータ・バイトに変換される。しかし、好ましい実施形態の最適化のために、構築されたツリーの全てをシリアル化する必要はない。即ち、以前のメッセージ内で送信されたストリング（例えば、サブツリー又はツリー断片に対応する）が、そのメッセージ部分が送信されたストリング・キャッシュ履歴内の位置を示すバック・リファレンス・ポインタで置き換えられる際に圧縮が施される。そのようなバック・リファレンス・ポインタ又は類似のインジケータは、ストリングの位置に設けられ、キャッシュ履歴内のツリー部分が存在する位置を指示する属性、例えば、前に用いられたサブツリー又はツリー断片データ構造体に付随する構築されたストリングを検索するためにストリング・キャッシュ履歴内をルック・バックするのに要するバイト数、及び、そのサブツリー又はツリー断片のために生成されたキャラクタ量の指示、を有する。このように、圧縮は、ツリー・コンテンツは送信する必要がなく、受信側ＷＳスタック処理がそのキャッシュ履歴内ストアされた正確なコンテンツを検索し関連するメッセージを構築することを可能にする、置き換えられたバック・リファレンス・ポインタのみを送信するように、実施される。次に、ステップ１２８において、ＳＷメッセージの通信に関与するネットワーク・プロトコル・ヘッダ、例えば、ＨＴＴＰヘッダを圧縮するステップが実行される。このように、最後に、ステップ１２９において、圧縮されたＨＴＴＰヘッダがシリアル化されたバイト・ストリームに付加され、圧縮された要求が送信される。

１つの実施形態において、ＨＴＴＰヘッダはＳＯＡＰメッセージの重要な部分を表す可能性があるので、ＨＴＴＰヘッダも圧縮を実行することが有利である。このことは、ＨＴＴＰ要求及び応答メッセージの両方に対して、現在規定される又は想定される全てのＨＴＴＰバインドに対して当てはまる。埋め込みシステム用及び比較的簡単な呼び出し用に設計されたＳＯＡＰスタックに対して、この部分は、例えば、図５（Ａ）及び（Ｂ）に示す例示的なＷＳ呼び出し２００の中の例示的なＨＴＴＰヘッダ・メッセージ・コンテンツに示されるように、特に大きくなる可能性がある。送信側において、ＨＴＴＰヘッダは、ストリング圧縮に非常によく似た方法を用いて、しかし遥かに小さなオーバーヘッドで圧縮される。例えば、ＨＴＴＰ圧縮は、修正ＬＺＷ（Ｌｅｍｐｅｌ Ｚｉｖ Ｗｅｌｃｈ）アルゴリズムを実施することにより実行されるが、ここで「修正」は、ＬＺＷを全体のストリング・キャッシュには適用せず、以前に送信されたＨＴＴＰヘッダにのみ適用するステップからなる。この理由は、圧縮を実行するスタック・コンポーネントが、新しいヘッダを比べることができる数個のサブストリング、即ち、以前に送信されたメッセージのヘッダだけが存在することを首尾よく認識するからである。受信側において、圧縮されたヘッダは、それが指示するサブストリング、即ち以前に受信されたメッセージのヘッダで置き換えられ、ウェブ・コンテナ、即ちＨＴＴＰ処理層に送られ、この層が有するあらゆる情報と共に、サブストリングの処理中にそれに結合される。この付加的な情報は、大部分は（属性、値）の対からなるが、サブストリングのその後の処理を補助するようにセーブされ、この付加された情報の使用により、受信側のＨＴＴＰ処理のオーバーヘッドが縮小される。このように、図３のステップ１２９は、圧縮されたＨＴＴＰヘッダを付加するステップを意図するものである。

既知のように、ＤＯＭパーサは入力ドキュメントからメモリ内にツリー構造体を作成する。ＤＯＭは、プログラム及びスクリプトがドキュメントのコンテンツ、構造体及び形式に動的にアクセスして更新することを可能にする、プラットフォーム及び言語に中立的なインタフェースである。これはさらに、ＸＭＬドキュメントを、他のさらに特殊化されたインタフェースを実施するノード・オブジェクトの階層として表現するための仕様を与える（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＤＯＭ／＃ｓｐｅｃｓ参照）。幾つかの型のノードは、種々の型のチャイルド・ノードを有することができ、他のノードは、ドキュメント構造体内のそれより下には何ももつことのできないリーフ・ノードである。ＷＳスタック実施はＤＯＭインタフェースを用い、ＤＯＭパーサはＳＯＡＰメッセージを処理する。しかし、他の型の構造化言語パーサ、例えば、ＳＡＸパーサを、本発明の趣旨及び範囲から逸脱せずに用いることができる。従って、ＤＯＭ法はＳＡＸパーサ（Ｓｉｍｐｌｅ ＡＰＩ ｆｏｒ ＸＭＬ、最新バージョンはＳＡＸ２．０．１）の使用により置き換えて入力するＳＯＡＰメッセージのツリー表現を構築することができる。

従って、図３をより詳しく拡張すると、ツリー・ベースのＡＰＩはツリー構造体の回りに集中され、従ってツリーのコンポーネント上に、ドキュメント・インタフェース、ノード・インタフェース、ノードリスト・インタフェース、要素インタフェース、Ａｔｔｒインタフェースなどのインタフェースが設けられる。好ましい実施形態の最適化をサポートするＷＳスタックの実施は、類似のアプローチを用いる。しかし、少なくとも３つの付加的なノード属性、即ち、１）そのノードに根付いたツリーに対応するＸＭＬストリングの長さ、２）メッセージを識別するためにツリーが表示するメッセージＩＤ、及び、３）メッセージ内のオフセット、が用いられる。これらの属性は、シリアル化されたサブツリー部分又はツリー断片のデータ表現の代りに加えられるバックポインタを生成するのに用いられる。

ステップ１０５において評価されるツリー・キャッシュ構造体について詳しく説明すると、ツリー・キャッシュは、最新の数個の送信又は受信されたメッセージ、又はそれらメッセージの断片に対応するツリー／サブツリーの集合であり、新しいメッセージが送信又は受信されると、最も古いメッセージは破棄される。送信側が用いることのできるツリー／メッセージの上限数があり、同様に、受信側が保持すべきメッセージ／ツリーの下限数がある。この２つの数は、協定された履歴サイズよりも大きな累積長を有する最短のメッセージ履歴として決定される。従って、図３のステップ１２６を詳しく説明すると、ツリー・キャッシュの実施は同一のサブツリーの複数のコピーの保存を避け、既存のツリーから新しいツリー（再使用）の構築を促進する。

従って、ツリーを構築する（ステップ１２３−１２６）ための送信側の機能性を詳しく説明すると、新しいメッセージを構成するとき、修正ＷＳスタックはツリー・キャッシュ・コンテンツから可能な限り多くのサブツリーの再使用を試みる。ＳＯＡＰメッセージ内で、再使用されたサブツリーは以前に送信されたメッセージ内のＸＭＬサブストリングに対するリファレンスに変換される。受信側キャッシュ内にあることが保証されるメッセージに対応するサブツリーだけが、ＳＯＡＰ／ＸＭＬメッセージ内のバック・リファレンスを作成するのに用いられる。

図４は、本発明の好ましい実施形態による最適化による受信側ＳＯＡＰ／ＨＴＴＰ処理を説明するフローチャートである。受信側において、ＳＯＡＰメッセージは図４に示すように受信され、サーバにおいて実施される方法１３０は、クライアントのＳＯＡＰメッセージ（要求）を受信してＨＴＴＰヘッダを剥離するステップ（ステップ１３２）を含む。次に、ステップ１３５において、ＨＴＴＰヘッダが圧縮されているかどうかの判断がなされる。ステップ１３５においてＨＴＴＰヘッダが圧縮されていると判断される場合には、次にステップ１３８において、ＨＴＴＰヘッダが解凍され、プロセスはステップ１４０に進み、これは、メッセージが受信されたときにＨＴＴＰヘッダに実施される正規の処理を示す。そうではなく、ステップ１３５においてＨＴＴＰヘッダが圧縮されていないと判断される場合には、プロセスはステップ１４０に進み、これは、メッセージが受信されたときにＨＴＴＰヘッダに実施される正規の処理を示す。処理ステップ１４０の後、ステップ１４２において、キャッシュ（ＤＯＭ（様）ツリー・データ構造体コンテンツをストアするための）が空であるかどうかの判断がなされる。このサーバ（受信側）キャッシュは、この特定の送信側からの第１メッセージが受信された時点では、受信側において履歴がまだ構築されていないので、空である可能性がある。ステップ１４２でツリー・キャッシュが空であると判断される場合には、受信側の処理は、要求ストリングを構文解析してＤＯＭ（様）ツリーを構築するステップ（ステップ１４５）、新しいツリーをツリー・キャッシュ内にセーブするステップ（ステップ１４６）、及び、要求内のオペレーション／パラメータを識別してＷＳ受信側スタッブを呼び出すステップ（ステップ１４８）などを含むステップを実行する。クライアントはサーバからの応答を構成する入力メッセージを同様に処理することを理解されたい。

ＳＯＡＰ／ＨＴＴＰメッセージが受信される受信側において、ステップ１４２においてツリー・キャッシュ（ＤＯＭ（様）ツリー・データ構造体コンテンツをストアするための）が空で出ないと判断される場合には、次のステップは、ステップ１５０において要求ストリングを構文解析してＤＯＭ（様）拡張ツリーを構築するステップを含む。しかし、この実施形態において、構築されるツリーは、前のメッセージ（呼び出し）からのローカルなストリング・キャッシュ履歴内に以前にストアされた、以前のキャッシュされた（指示された）サブツリー又はツリー断片データ表現を利用する。好ましい実施形態によれば、受信メッセージに対応するツリーを構築するときに、受信側はキャッシュされたサブツリーを、入力ＳＯＡＰ／ＸＭＬメッセージ内のバック・リファレンス・ポインタがあれば、それに指示される通りに用いる。即ち、明示的なＸＭＬコンテンツ受信されるとき、新しいサブツリーが構築され、メッセージを表現するツリー内に挿入される。新しいツリーは、入力メッセージ内のバック・リファレンスによって指示される通りに、受信側キャッシュ内の既存のツリーの大きな部分を再使用することができる。次に、ステップ１５３に示されるように、新しいＤＯＭ（様）拡張ツリー構造体がキャッシュ内にセーブされる。最後に、ステップ１５６において、オペレーション／パラメータが識別され、ステップ１５６に示されるようにＷＳ機能性を呼び出すことにより、受信されたメッセージに応答してＷＳ受信側スタッブが呼び出される。

従って、解凍が行われる受信エンドポイントにおいて、本発明の好ましい実施形態により以下の最適化法が提供される。具体的には、あらゆるバック・リファレンス・ポインタがローカル・ストリング・キャッシュ履歴内のストリングで置き換えられ、受信されたメッセージ・ストリーム内に結合される。リファレンスは常に、ローカルＳＯＡＰエンジンの入力パスによって以前に構文解析されたストリングによって置き換えられることが好ましい。構文解析された後、ストリングは、それらのＨＴＴＰ／ＳＯＡＰレベルのラベル、例えば、ＵＲＬ，ＥｎｃｏｄｉｎｇＳｔｙｌｅＴｏｋｅｎなどで注釈を付けられる。従って、本発明は好ましくは、予め構文解析されたストリングを受信されたＷＳメッセージの構文解析内に直接結合することを可能にするように入力パスに対する修正を提案する。これは、圧縮されたストリング部分のそれぞれに対して一回だけの構文解析をもたらすことになる。

好ましい実施形態により実施される圧縮操作の非常に簡単な実施例において、ここで図５（Ａ）、（Ｂ）を参照すると、ＷＳ呼び出し及び応答２００における繰返しの型を示す例示的なメッセージ・トレースが具体的に示される。トレースは、ＴＣＰＭｏｎｉｔｏｒと呼ばれるツールによって取り込まれるが、このツールは、ＳＯＡＰ仕様のオープン・ソース実施でありＡｐａｃｈｅウェブ・サイト（ｗｗｗ．ａｐａｃｈｅ．ｏｒｇ）から入手できるＡｘｉｓの一部分である。図５（Ａ）、（Ｂ）には、例示的なＷＳ ＳＯＡＰトラフィックは双方向（（Ａ）でクライアントからサーバへ、（Ｂ）でサーバからクライアントへ）に通信されるように示されている。図５（Ａ）に示すように、第１要求（クライアントからサーバへ）はＨＴＴＰヘッダ、及び、それに続く「ａｄｄ」呼び出しに関するＳＯＡＰメッセージ２０５を含む、演算「ａｄｄ」のこの実施例において、２つの例示的なパラメータは「７」及び「５」である。第２要求（クライアントからサーバへ）において、ＨＴＴＰヘッダの後に、例示的なパラメータ「３」及び「１１」を伴う「ｍｕｌ」演算の第２呼び出しに関するＳＯＡＰメッセージ２１０が続く。図５（Ｂ）は、第１「ａｄｄ」呼び出し２０５、第２「ｍｕｌ」呼び出し２１０のそれぞれに応答する、それぞれの応答メッセージ（サーバからクライアントへ通信されるメッセージ）２１５、２２０を示す。

図６は、図５（Ａ）に示す２つの要求メッセージ２０５、２１０のそれぞれのツリー表現２５５，２６０を示す。２つの呼び出しの各々における共通のメッセージ断片２７５（重なり）が示される。メッセージのＳＯＡＰ部分だけがツリーとして表現される、即ち、ＨＴＴＰヘッダは表現されないことに注意されたい。属性は要素ノード（円）に結び付けられた正方形ノード２６５、２８０として表されている。

図７（Ａ）は、図５（Ａ）の２つのＳＯＡＰ要求メッセージ２０５、２１０に対応するそれぞれのストリング２８５，２９０の間の重なり２７７を示す。修正ＷＳスタックは強調された範囲を、コンパクト・エンコーディングを用いて、バック・リファレンス・ポインタで置き換える。図７（Ｂ）は、同じ２つの要求メッセージの間であるが、それらのＨＴＴＰヘッダにおける重なり２７７を示す。この最適化は、ＷＳスタックの両方の部分である、ＳＯＡＰエンジンをサポートするＨＴＴＰエンジンにおける変更を必要とする。

有利なことに、好ましい実施形態による本発明の機構は、入力パスに対する修正を必要とし、ＣＰＵ時間及びメモリ使用における実質的な節約を生むことが期待され、これはＷＳメッセージ処理中の実質的な電力節約につながる。

提案された最適化は対称的である必要はないことに注意されたい。デスクトップ／携帯電話の対のように、２つのデバイスが非常に大きく異なるリソース特性を有する場合、或いは、一方向のメッセージが、非常に大きく暗号化された結果のような疑似乱数コンポーネントにより支配される場合には、最適化は一方向においてのみ可能とすることができる。所与の方向における最適化を動作不能にするためには、履歴サイズをゼロに設定する。

本発明は、本発明の実施形態による方法、装置（システム）及びコンピュータ・プログラムの図を参照しながら説明された。各々の図はコンピュータ・プログラム命令によって実施できることを理解されたい。これらのコンピュータ・プログラム命令は、汎用コンピュータ、専用コンピュータ、埋め込みプロセッサ、又は機械を製造するための他のプログラム可能データ処理装置のプロセッサに供給することができ、その結果、コンピュータ又は他のプログラム可能データ処理装置のプロセッサにより実行する命令が、本明細書において述べられた機能を実施する手段を作成することができる。

これらのコンピュータ・プログラム命令はまた、コンピュータ又は他のプログラム可能なデータ処理装置に特定の様式で機能するように指示することができるコンピュータ可読メモリ内にストアして、コンピュータ可読メモリ内にストアされた命令が本明細書において述べられた機能を実施する命令手段を含む製品を製造するようにすることができる。

これらのコンピュータ・プログラム命令はまた、コンピュータ可読又は他のプログラム可能なデータ処理装置にロードして、一連の演算ステップをコンピュータ又は他のプログラム可能な装置上で実行させ、コンピュータ又は他のプログラム可能な装置上で実行する命令が本明細書において述べられた機能を実施するステップを与えるコンピュータ実施プロセスを作成することができる。

本発明は、その例証となる好ましい実施形態に関して具体的に示され説明されたが、当業者であれば、添付の特許請求の範囲によってのみ限定されるべき本発明の趣旨及び範囲から逸脱せずに、その形態及び細部に前述及び他の変更を施すことができることを理解するであろう。

本発明が好ましい実施形態によって実施されるウェブ・サービス・アーキテクチャ１０（Ａ）及びメッセージング・ダイアグラム（Ｂ）を示す。 受信及び送信エンドの両方が本発明の好ましい実施形態の最適化を実施するかどうかを判断して両エンドにおける履歴サイズを同じ値に設定するために用いられるハンドシェイク・プロトコルを示す。 本発明の好ましい実施形態の最適化により、送信側のＳＯＡＰ／ＨＴＴＰ処理を説明するフローチャートである。 本発明の好ましい実施形態の最適化により、受信側のＳＯＡＰ／ＨＴＴＰ処理を説明するフローチャートである。 ２つの連続したＷＳ呼び出しに関する双方向の通信（クライアントからサーバへ（Ａ）及びサーバからクライアントへ（Ｂ））を示すＷＳ ＳＯＡＰトラフィックを例示する。 本発明の好ましい実施形態による、図５（Ａ）に示される２つの要求メッセージ２０５、２１０のそれぞれのツリー表現２５５、２６０を示す。 本発明の好ましい実施形態による、図５（Ａ）の要求メッセージ呼び出し２０５、２１０内のＳＯＡＰメッセージ／ＨＴＭＬヘッダ内の２つのストリングに対応するそれぞれのストリング２８５、２９０の間のそれぞれの重なりを示す。

符号の説明

１０：ウェブ・サービス（ＷＳ）アーキテクチャ
１２：ウェブ・サービス要求者、ＷＳ受信エンドポイント（ＷＳクライアント）
１５：ウェブ・サービス・ブローカー
１８：ウェブ・サービス・プロバイダ、ＷＳ送信エンドポイント（ＷＳサーバ）
２２：サービス配信コンポーネント
２５：ＳＯＡＰメッセージング
２８：サービス・コンテナ
３０ａ、３０ｂ：サービス・レジストリ
９９：ネットワーク
４０：ハンドシェイク・プロトコル
４５ａ：初めのハンドシェイク・メッセージ
４５ｂ：ハンドシェイク応答メッセージ
１００、１３０：方法
２００：ＷＳ呼び出し
２０２、２０３：ＨＴＴＰヘッダ
２０５：「ａｄｄ」呼び出し（要求メッセージ）
２１０：「ｍｕｌ」呼び出し（要求メッセージ）
２１５：呼び出し２０５に対する応答メッセージ
２２０：呼び出し２１０に対する応答メッセージ
２５５：要求メッセージ２０５のツリー表現
２６０：要求メッセージ２１０のツリー表現
２７５：共通のメッセージ断片
２６５、２８０：正方形ノード（属性）
２８５：要求メッセージ２０５のストリング
２９０：要求メッセージ２１０のストリング
２７７：ストリング２８５と２９０の重なり
２９７：２つの要求メッセージ２０５、２１０の重なり

Claims (14)

1. メッセージ通信を行う方法であって、
   送信側デバイスと受信側デバイスとの間でハンドシェイク・プロトコルを実施することにより、それぞれ送信側及び受信側デバイスにおいて送信及び受信ＳＯＡＰメッセージ・ストリングに対応するキャラクタ・ストリングをストアするための、同じ第１キャッシュ・ストレージの量を割り当てるステップと、
   通信を行うべきメッセージを表し、前記送信側デバイスにおける第２キャッシュ・ストレージ内でのストレージに適合する、中間データ構造体を構築するステップと、
   通信を行うべきメッセージ・ストリングを、前記構築された中間データ構造体に基づいて構築するステップと
   を含み、さらに、各々のその後の通信を行うメッセージに対して、
   構築中の最新のメッセージに対する構築された中間データ構造体中の部分を、前の通信済みメッセージ・ストリングに対応する構築された中間データ構造体中に存在する類似部分と同一の部分により識別するステップと、
   前記最新の構築された中間データ構造体に基づいて通信を行うべきメッセージ・ストリングを構築し、メッセージ・ストリング中の各々の識別された部分を、前記前の通信済みメッセージ・ストリングに付随する同一のキャラクタ・ストリング部分に対応する前記第１キャッシュ・ストレージ内のロケーションに対するリファレンス・インジケータで置き換えるステップと、
   前記受信側デバイスにおいて、受信メッセージ・ストリング内のリファレンス・インジケータを識別し、前記受信側デバイスにおける前記第１キャッシュ・ストレージ内にストアされている１つ又は複数のキャッシュされた同一のキャラクタ・ストリング部分で置き換えて受信メッセージを構築するステップと
   を含み、
   前記送信側及び受信側デバイスにおけるメッセージ通信インフラストラクチャ・リソースは保存される、
   方法。
2. 通信を行うべきメッセージ・ストリングを前記構築するステップは、前記構築された中間データ構造体をシリアル化してメッセージ・ストリングを形成するステップを含む、請求項１に記載の方法。
3. 前記中間データ構造体はメッセージの構造化されたツリー表現を含み、前記識別されたストリング部分は１つ又は複数のサブツリー又はツリー断片を含む、請求項２に記載の方法。
4. 前記リファレンス・インジケータは、前の通信済みメッセージ・ストリングに対応する構築された中間データ構造体中に存在する類似のサブツリー又は断片部分に同一の、構築された中間データ構造体中の識別されたサブツリー又は断片部分に対応するシリアル化されたメッセージ・ストリング部分の属性を指示する、請求項３に記載の方法。
5. 属性は前の送信済みメッセージの指示を含む、請求項４に記載の方法。
6. 属性は前の通信済みメッセージの前記ツリー表現を識別するメッセージＩＤを含む、請求項４又は５に記載の方法。
7. 属性は前記識別されたツリーに対応する前記ストリングの長を含む、請求項４乃至６のいずれか１項に記載の方法。
8. 属性は前記前の通信済みメッセージ内のオフセットの長を含む、請求項４乃至７のいずれか１項に記載の方法。
9. 前記受信側デバイスにおいて、前記部分を識別するステップは、前記受信メッセージ・ストリングを構文解析して前記受信側デバイスにおける第２キャッシュ・ストレージ内でのストレージのために構造化されたツリー表現を構築するステップを含み、前記構造化されたツリー表現はストアされて、後で前記受信側デバイスにおいて受信メッセージを構築するのに用いられる、請求項３に記載の方法。
10. 新しいメッセージがそれぞれ送信及び受信されるにつれて、前記送信側及び受信側デバイスにおける前記第２キャッシュ・ストレージ内の同一部分の前記ツリー表現を間断なく更新するステップをさらに含む、請求項９に記載の方法。
11. クライアント送信側デバイス及び受信側デバイスの各々において割り当てられる前記第１キャッシュ・ストレージの量は固定され、新しいメッセージが送信又は受信されるとき、より古い１つ又は複数のサブツリー又はツリー断片は、対応するストリング・メッセージが前記第１キャッシュ・ストレージ内にドロップインされるときに破棄される、請求項１に記載の方法。
12. ウェブ環境下でメッセージ通信を行うための装置であって、
    送信側デバイスにおいてウェブ・サービス（ＷＳ）スタック実施をサポートして受信側に通信を行うべきＷＳメッセージ・ストリングを生成する手段であって、前記通信を行うメッセージ・ストリングはＳＯＡＰメッセージ・ストリングであって、前記送信側デバイスにおける第１キャッシュ・ストレージ・デバイス内にストアされ、且つ、前記受信側デバイスにおける第１キャッシュ・ストレージ内にストアされる、手段と、
    受信側デバイスにおいてＷＳスタック実施をサポートして前記受信側デバイスに通信された受信ＷＳメッセージ要求ストリングに応答する手段であって、前記送信側及び受信側デバイスにおける各々の前記ＷＳスタック実施は、送信及び受信されたＷＳメッセージ・ストリング・コンテンツを表す中間データ構造体を構築しストアし、そして構築された中間データ構造体をそれぞれ送信側及び受信側デバイスにおいてローカルにストアする、手段と、
    前記送信側デバイスにおける前記ＷＳスタック実施が、通信を行うべきメッセージ・ストリングを最新の構築された中間データ構造体に基づいて構築し、メッセージ・ストリング内の各々の識別された部分を、前の通信済みメッセージに付随する同一のキャラクタ・ストリング部分に対応する前記第１キャッシュ・ストレージ内のロケーションに対するリファレンス・インジケータで置き換えるための実施手段と、
    前記受信側デバイスにおける前記ＷＳスタック実施が、受信メッセージ・ストリング内にリファレンス・インジケータを識別し、前記受信側デバイスにおける前記第１キャッシュ・ストレージ内にストアされている１つ又は複数のキャッシュされた同一のキャラクタ・ストリング部分で置き換えるための実施手段と
    を含み、
    前記送信側デバイスにおける第１キャッシュ・ストレージ・デバイス及び前記受信側デバイスにおける第１キャッシュ・ストレージは、前記送信側デバイスと前記受信側デバイスとの間におけるハンドシェイク・プロトコルにより協定された同じサイズを有し、
    前記送信側及び受信側デバイスにおけるＷＳメッセージ通信インフラストラクチャ・リソースは保存される、
    装置。
13. 請求項１乃至１１のいずれか１項に記載の方法を実施するように動作可能な手段を含む装置。
14. コンピュータ・プログラムであって、該プログラムがコンピュータ上で動作するとき、請求項１乃至１１のいずれか１項に記載の方法の各ステップをコンピュータに実行させる、コンピュータ・プログラム。

Images