JP2004295894A - ストリームのためのメッセージ処理パイプライン - Google Patents

Abstract

【課題】 メッセージングシステムが所与のバッファサイズを使用して比較的大きなメッセージを送信または受信することができる、メッセージングシステムにおけるバッファ要件を削減する方法を提供する。
【解決手段】 ストリーム指向インターフェースを備えるストリーム化部分を有するメッセージオブジェクトに対して実行するための対応する処理演算を各々識別するメッセージハンドラが提供される。メッセージハンドラの順序付けられた集成物を含むパイプラインもまた提供される。メッセージオブジェクトは、メッセージパイプライン内でメッセージハンドラによって処理され、その結果、少なくとも１つのメッセージハンドラが、その対応する処理演算でメッセージオブジェクトのストリーム化部分をカプセル化する。対応する処理演算は将来実行しようとするものであり、ストリーム部分はバッファ内で具現化されない。
【選択図】 図４

Description

本発明は、メッセージ処理に関する。より詳細には、本発明は、メッセージを処理するためのバッファ要件を削減し、したがって、メッセージングシステムが所与のバッファサイズを使用して比較的大きなメッセージを送信または受信することを可能にする方法、システム、およびコンピュータプログラムに関する。

メッセージ処理は、分散アプリケーションサポートを含め、概して通信プロトコル内など、様々な状況で行われる。メッセージ処理システムが絶えず直面する問題の１つは、サイズに限りのないメッセージを処理することに関する。一般に、従来のメッセージ処理システムは適度なサイズのメッセージをバッファするが、大きなメッセージは、拒絶されなければ、予測不可能な、おそらくは膨大なメモリ要件に通ずる。「大きな」は相対的な用語であり、一部には、メッセージ処理システム自体によって決まる。しかし、ネットワーク速度が高まるにつれて、特にマルチメディアやグラフィックコンテントの交換の普及により、メッセージサイズもまた増大した。ネットワーク帯域の点からは、マルチメガバイトメッセージはもはやあまり問題にならないかもしれないが、メモリと処理時間を共に含む処理上の考慮すべき点を考え合せると、マルチメガバイトメッセージは、特にいくらか定期的に受信される場合、メッセージングシステムに対する著しく重い負担を意味する可能性がある。

もちろん、処理パワーが高まり続けるコンピュータと、使用可能なメモリは、日々それほど高価でなくなり、大きなメッセージによって引き起こされる資源需要の一部を緩和する。過去数年間にわたるハードウェアの進歩を考えると、１つの手法には、使用可能なバッファサイズと処理速度を増大し、大きなメッセージに対処することが含まれる可能性がある。大抵のメッセージは比較的小さいものとなる可能性があり、したがって、１つの推論の方法では、時折生じる大きなメッセージはあまり問題にならないことが示唆される。

この推論の方法が考慮していない少なくとも２つの考慮すべき点がある。第１の最も重要なものは、大きなメッセージは時折届くだけであろうという前提である。メッセージングシステムがサービス拒否攻撃（denial of service attack）を受ける可能性は常にある。一般に、サービス拒否攻撃は、送信するコンピュータまたはコンピュータ群が生成するのにかかる時間よりも受信するコンピュータが処理するのに長い時間がかかる要求で１つのハードウェアを圧倒しようと試みる。大きなメッセージをメッセージ処理システムに送信することは、悪意あるサービス拒否攻撃にとって論理的な出発地であり、したがって、大きなメッセージは時折受け取るだけであろうと仮定することは、大きなメッセージを扱うのに危険な戦略である。第２に、多数のメッセージ処理システムは、時折、最大能力近くで動作するため、大きなメッセージが忙しい時に届く可能性を無視することはできない。

従来のメッセージングシステムで判明したこれら、および他の問題により、メッセージを処理するときのバッファ要件を削減し、メッセージングシステムが所与のバッファサイズを使用して比較的大きなメッセージを送信または受信することができるようにするための方法、システム、およびコンピュータプログラムが望まれている。

本発明は、メッセージングシステムにおけるバッファ要件を削減し、メッセージングシステムが所与のバッファサイズを使用して比較的大きなメッセージを送信または受信することができるようにする方法、システム、およびコンピュータプログラムに関する。以下でより十分に述べる本発明の例示的な実施形態によれば、メッセージングシステムは、１つまたは複数のメッセージトランスポートを介してエンドポイントにメッセージを送信し、またはエンドポイントからメッセージを受信する。メッセージングシステムは、メッセージオブジェクトを経路指定するための中間部、またはメッセージを送受信するエンドポイントとすることができる。

例示的な一実施形態では、１つまたは複数のメッセージハンドラが提供され、メッセージハンドラの各々が、メッセージオブジェクトに対して実行するための対応する処理演算を識別する。メッセージオブジェクトは、ストリーム指向インターフェースを有するストリーム化部分を含む。１つまたは複数のメッセージハンドラを順序付けられた集成物として管理するために、パイプラインもまた提供される。メッセージオブジェクトは、メッセージパイプライン内の１つまたは複数のメッセージハンドラによって処理され、その結果、少なくとも１つのメッセージハンドラが、その対応する処理演算でメッセージオブジェクトのストリーム化部分をカプセル化する。対応する処理演算は将来実行しようとするものであり、ストリーム化部分をバッファ内で具現化することなしに、メッセージオブジェクトのストリーム化部分をカプセル化する。いくつかの実施形態では、メッセージオブジェクトを様々なメッセージハンドラで処理するために、入れ子のパイプライン（nested pipelines）を含む複数のパイプラインを提供することができる。

パイプラインが複数のメッセージハンドラを備える場合、各ハンドラは、メッセージハンドラに対応する処理演算がメッセージオブジェクトのストリーム部分上でレイヤリングされるように、ストリーム化部分を連続的にラップすることができる。メッセージオブジェクトは、１つまたは複数のヘッダ部分、１つまたは複数のボディ部分、および１つまたは複数のアタッチメント部分を含むことができ、少なくともボディ部分および／またはアタッチメント部分は、一般的に、メッセージオブジェクトのストリーム化部分を含む。

例示的な実施形態では、メッセージオブジェクトは、たとえば、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ：Simple Object Access Protocol）メッセージとすることができる。ＳＯＡＰメッセージを経路指定あるいは処理するために、ストリーム化部分を具現化することを必要とせずに、そのメッセージについてのヘッダは具現化され、あるいはアクセスのためにバッファされる。経路指定は、複数のエンドポイントに送達するためにメッセージオブジェクトを複製することを含むことができる。

メッセージパイプラインのメッセージハンドラの１つまたは複数を呼出すことは、ストリームがメッセージオブジェクトのストリーム部分に割り当てられる前に行われる可能性がある。メッセージハンドラが呼び出されたときストリーム部分を具現化する必要がないため、最初にパイプライン内のメッセージハンドラの処理演算がそのメッセージについて識別され、次いで、その演算を実行する実際のストリームが、後でメッセージオブジェクトのストリーム部分に割り当てられる。メッセージオブジェクトを別のエンドポイントに送信または別のエンドポイントから受信することは、ストリーム化部分をカプセル化する処理演算がそのストリーム化部分に対して実行される結果となる。

本発明の追加の特徴および利点は、以下の説明で述べられることになり、一部には、説明から明らかとなり、あるいは本発明を実施することによって学習することができる。本発明の特徴および利点は、添付の特許請求の範囲の中で特に指摘されている手段および組合せによって実現されおよびもたらされることができる。本発明のこれら、および他の特徴は、以下の説明および添付の特許請求の範囲から、より完全に明らかになり、あるいは以下に述べられている本発明を実施することによって学習することができる。

本発明の上記の、ならびに他の利点および特徴を得ることができる方法について述べるために、手短に上述した本発明について、添付の図面に例示されている本発明の特定の実施形態を参照することによって、より具体的に説明する。これらの図面は本発明の典型的な実施形態を示すにすぎず、したがって、その範囲を限定すると見なすべきでないことを理解して、本発明について、添付の図面を使用することにより、追加の特殊性および詳細と共に述べ、説明する。

本発明は、メッセージオブジェクトの少なくとも一部についてバッファ要件を削減するメッセージオブジェクトを処理するための方法、システム、およびコンピュータプログラムに及ぶ。本発明は、バッファ要件を削減することにより、メッセージングシステムが所与のバッファサイズを使用して、他の方法で可能であるはずのものより比較的大きいメッセージを送信または受信することを可能にする。本発明の実施形態は、以下でより詳細に論じるように、様々なコンピュータハードウェアを含む１つまたは複数の専用コンピュータおよび／または汎用コンピュータを含むことができる。

図１は、本発明によるメッセージングシステムによって処理する例示的なメッセージオブジェクト１００を示す。メッセージは、エンドポイント間の通信の基本単位である。メッセージオブジェクト１００は、ヘッダ１１２、ヘッダ１１４、ヘッダ１１６、および潜在的にその他を含むヘッダ集成体１１０を含む。また、メッセージオブジェクト１００はコンテント１２０を含む。図では、メッセージオブジェクト１００のヘッダ集成体１１０がバッファされ、一方、コンテント１２０がストリーム化される。メッセージオブジェクトのヘッダをバッファする１つの動機は、メッセージを実際に処理する前に、メッセージをどう処理するか判断する場合に一般にヘッダが使用されることにある。たとえば、メッセージオブジェクト１００を適切なエンドポイントに経路指定するために、一般に、決まったヘッダを調べることが必要である。しかし、一般に経路指定は、コンテントを調べることを必要としない。したがって、コンテント１２０をストリーム化し、適宜ヘッダをバッファするのは、いくつかの状況の下で適切である可能性がある。

当然ながら、ヘッダ集成体１１０をバッファし、コンテント１２０をストリーム化することは、一例のメッセージレイアウトにすぎない。ヘッダは、比較的小さく、かなり明確であるため、メッセージコンテントで見られる無制限のバッファ要件をもたらさない。しかし、本発明は、ヘッダ集成体１１０を含め、メッセージオブジェクト１００のすべてをストリーム化することを除外しない。さらに、メッセージオブジェクト１００のレイアウトは多数の可能なレイアウトの１つにすぎないことを強調しておくべきである。メッセージオブジェクト１００は、しばしば別個のヘッダ集成体１１０と、コンテントまたはボディ１２０とを含むことになるが、本発明は、いずれかの特定のメッセージレイアウトに限定されず、いずれかの特定のメッセージレイアウトの参照は例にすぎないと見なすべきである。

一般に、メッセージオブジェクト１００のレイアウトは、ＳＯＡＰメッセージに対応する。ＳＯＡＰは、ウェブサービス要求内の情報および応答メッセージを、ネットワークを介して送信する前に符号化するために使用されるＸＭＬ（eXtensible Markup Language）に基づく軽いメッセージングプロトコルである。ＳＯＡＰメッセージは、オペレーティングシステムに依存せず、ＳＭＴＰ（Simple Mail Transfer Protocol）、ＨＴＴＰ（HyperText Transfer Protocol）、ＭＩＭＥ（Multipurpose Internet Mail Extensions）、ＤＩＭＥ（Direct Internet Mail Encapsulation）など、様々なインターネットプロトコルのいずれかを使用して転送および符号化することができるため、ウェブサービスに非常に適している。

汎用のＳＯＡＰメッセージプロセッサは、その正しい処理を決定するために、メッセージ内に存在する少なくとも特定のヘッダにアクセスできることを必要とする。以下でより詳細に述べるように、例示的な一実施形態では、メッセージハンドラのパイプラインを使用してメッセージを処理することができる。これらのハンドラの各々は、メッセージ内に存在するゼロ個以上のヘッダを点検し、それらに対して作用することができる（また、ハンドラは、ストリーム化されたメッセージコンテントを点検し、それに対して作用することもできる）。これらのハンドラの組み合わされた処置は、メッセージに影響を及ぼすことになる処理を規定する。ＳＯＡＰプロセッサは、そのジョブを完了した後で、そのメッセージの目的の受取先にメッセージを渡す。

しかし、この状態で、ＳＯＡＰプロセッサは、メッセージの正しい処理を実行するためにバッファ内の完全なメッセージを具現化することを必要としなかったことに留意されたい。具体的には、ＳＯＡＰプロセッサは、特定のヘッダ要素、さらに、おそらくは一部のボディ要素にアクセスできることを必要とするだけであり、その他にアクセスできることを必要としない。したがって、以下で述べる例示的な実施形態では、ＳＯＡＰメッセージの様々なヘッダをバッファすることができる一方、ＳＯＡＰメッセージのボディは、必要とされるときだけバッファされる。必要とされるときだけＳＯＡＰメッセージのボディを取り出すことは、本質的にボディへの参照を渡すことにより成され、コンシューマがオンデマンドでコンテンツを取り出すことを可能にする。

例示的な一実施形態では、メッセージヘッダ集成体１１０は、ヘッダ集成体内で個々のヘッダを見つけるための発見メソッド（find method）を有する。発見メソッドは、一般に、ヘッダ特有のメッセージハンドラによって使用され、ターゲットとされているヘッダについて、ヘッダのタイプ、ヘッダのＸＭＬ要素名、ヘッダが定義されているＸＭＬ名前空間、および／または、エンドポイントに対応するアクタ／ロール（actor/role）によって適切なヘッダを検索する。単純化するために、ヘッダはすべて、使用可能なメモリの制約内でバッファされているが、上記で示したように、特定の実施について適切である場合、本発明は、１つまたは複数のヘッダをストリーム化することを排除しない。さらにサービス拒否攻撃から守るために、たとえば３２キロバイトなどのメモリ割当てを、ヘッダをバッファするために確立することができる。

図２Ａ〜２Ｂは、メッセージオブジェクトをストリームから読み取り、またメッセージオブジェクトをストリームに書き込む例を示す。フォーマッタ２３０Ａおよび２３０Ｂは、メッセージをストリームで表したものとメモリ内メッセージインスタンスとの間で変換を行う。別のエンドポイントからネットワークを介してメッセージを受信するとき、フォーマッタ２３０Ａは、ストリーム２１０Ａから読み取り（２２０Ａ）、メッセージを処理するためにメッセージハンドラ２５０Ａを呼び出す（２４０Ａ）。同様に、メッセージをネットワークを介して別のエンドポイントに送信するとき、フォーマッタ２３０Ｂは、メッセージハンドラ２５０Ｂによって生成されたメモリ内インスタンスからストリーム２１０Ｂに書き込む（２２０Ｂ）。上述のように、典型的には、メッセージハンドラ２５０Ａおよび２５０Ｂは、メッセージハンドラの１つまたは複数のパイプラインである。

図３Ａ〜３Ｂは、メッセージオブジェクトを処理するための例示的なパイプラインを示す。メッセージハンドラの順次実行は、共通のメッセージ処理パターンである。パイプラインは、同期コードメッセージハンドラの管理を単純化する。パイプラインは、メッセージハンドラであり、メッセージハンドラを使用することができる任意のところで使用することができる。図３Ａでは、パイプライン３３０は、メッセージハンドラ３３２、メッセージハンドラ３３４、メッセージハンドラ３３６を含む。メッセージ３００を処理するためにパイプライン３３０が呼び出されたとき、このパイプラインは、各メッセージハンドラをその集成体の形で１つずつ順番に呼び出し、メッセージを処理する。ストリーム化されたコンテントに対するメッセージパイプラインの効果については、以下でより詳細に述べる。

パイプラインはメッセージハンドラであるため、パイプラインは、図３Ｂに示されているように入れ子にすることができる。図３Ａと共に上述したように、メッセージ３００を処理するためにパイプラインが呼び出されたとき、メッセージは、（エラーが発生するが、ハンドラが他の処理を一時停止すべきであると判断することがない限り）パイプライン内の各ハンドラを通過する。図３Ｂに示されているように、パイプライン内のハンドラの１つがそれ自体パイプラインである場合、メッセージは、これらのハンドラのそれぞれを通過する、以下同様である。図３Ｂで、パイプライン３３０は、メッセージハンドラ３３２、パイプライン３４０、メッセージハンドラ３３６という３つのメッセージハンドラを有する。また、パイプライン３４０は、メッセージハンドラ３４２、メッセージハンドラ３４４、メッセージハンドラ３４６という３つのメッセージハンドラを有する。ハンドラが呼び出される順序は、線によって示されている。メッセージハンドラ３４４などのメッセージハンドラが、他のメッセージ処理を行うべきでないことを示している場合、メッセージハンドラ３４６もメッセージハンドラ３３６も呼び出されないことになる。当然ながら、図３Ａ〜３Ｂに示されているパイプラインは、比較的単純なパイプラインの例であり、はるかに複雑なパイプラインを使用することができることを理解されたい。

図４は、メッセージオブジェクトのストリーム化されたメッセージコンテントをラップまたはカプセル化することを示す。ストリーム化されたメッセージコンテントの場合、図３Ａ〜３Ｂに示されているメッセージハンドラなどのメッセージハンドラは、そのメッセージハンドラの処理演算でストリーム化メッセージコンテントをラップまたはカプセル化する。ラップまたはカプセル化が行われるのは、メッセージハンドラが呼び出された時点でストリーム化メッセージコンテントに対する処理演算の実行が、ストリーム化メッセージコンテントをバッファリングまたは具現化することを要求するからであり、すなわちメッセージコンテントをストリームとして有することの目的を損なうことになるためである。

図４に示されているように、メッセージ４００のストリーム化メッセージコンテント４２０は、パイプライン４１０を通過するとき、様々な処理演算でラップまたはカプセル化される。メッセージハンドラ４３２は、ストリーム化メッセージコンテント４２０を処理演算４３２Ａでカプセル化する。メッセージハンドラ４３４は、ストリーム化コンテント４２０および処理演算４３２Ａを処理演算４３４Ａでラップする。最後に、メッセージハンドラ４３６は、ストリーム化コンテント４２０、処理演算４３２Ａ、および処理演算４３４Ａを、処理演算４３６Ａでカプセル化する。

これらの処理演算がストリーム化コンテント上でレイヤリングされていれば、コンシューマがストリーム化コンテントにアクセスし始めたとき、ストリーム化コンテントを具現化することを必要とせずに、メッセージハンドラがパイプライン４１０内で呼び出されたとき順序付けられた適切な処理演算が実行されることになる。その結果、メッセージ４００を処理するためのバッファ要件が削減され、それにより、メッセージングシステムが所与のバッファサイズを使用して比較的大きなメッセージを送信または受信することができる。上記で示されているように、レイヤリングされた処理はまた、大きなメッセージに基づくサービス拒否攻撃の影響を受けにくくなる。メッセージングシステムは、必要とされる処理の多くを、コンテントを具現化することを必要とせずに、実行することができるからである。これは特に、メッセージングシステムが、図５Ａ〜５Ｃに関連して以下で述べる経路指定機能を実行する場合に有益である。ストリームの一部分またはチャンクがアクセスされたとき、ストリーム化コンテントの何らかのバッファ処理が行われる可能性があるが、このバッファ処理は、ストリーム全体ではなくチャンクサイズに基づいているため、制限されることを理解されたい。その最終宛先および中間部では、受信されたストリームコンテントを、最終宛先のディスクまたは次のホップのためのストリームなど別のストリームに単に書き込むことができる。

この段階で、さらに２つの具体的な例を用いて、図４について論じることは役に立つ可能性がある。パイプライン４１０が、書き込むべきメッセージ４００についてストリーム化コンテント４２０を作成しているところを考えてみる。メッセージハンドラ４３２はデジタル署名演算４３２Ａを含み、メッセージハンドラ４３４は暗号化演算４３４Ａを含み、メッセージハンドラ４３６は圧縮演算４３６Ａを含む。メッセージ４００がパイプライン４１０を通り抜けるとき、デジタル署名演算４３２Ａ、暗号化演算４３４Ａ、圧縮演算４３６Ａは、ストリーム化コンテント４２０の上にレイヤリングされ、ストリーム化コンテント４２０をカプセル化またはラップする。したがって、トランスポートするためにストリーム化コンテント４２０が書き込まれたとき、ストリーム化コンテント４２０は、デジタル署名演算４３２Ａでデジタル署名され、暗号化演算４３４Ａによって暗号化され、および圧縮演算４３６Ａで圧縮されるストリームの一部分またはチャンクを提供する。したがって、書き込まれるのは、署名済み、暗号化済み、圧縮済みバージョンのストリーム化コンテント４２０である。

反対に、パイプライン４１０が、読み取るべきメッセージ４００についてストリーム化コンテント４２０を作成しているところを考えてみる。読取りの場合には、パイプライン４１０内のメッセージハンドラの順序が、上記の書込みの例から逆になる。メッセージハンドラ４３２は圧縮解除演算４３２Ａを含み、メッセージハンドラ４３４は解読演算４３４Ａを含み、メッセージハンドラ４３６はデジタル署名検証演算４３６Ａを含む。メッセージ４００がパイプライン４１０を通り抜けるとき、圧縮解除演算４３２Ａ、解読演算４３４Ａを含み、デジタル署名検証演算４３６Ａは、ストリーム化コンテント４２０の上にレイヤリングされ、またはストリーム化コンテント４２０をカプセル化またはラップする。

したがって、ストリーム化コンテント４２０が読み取られたとき、ストリーム化コンテント４２０は、圧縮解除演算４３２Ａで圧縮解除され、解読演算４３４Ａによって解読され、およびデジタル署名がデジタル署名検証演算４３６Ａで検証される、ストリームの一部分またはチャンクを提供する。したがって、読み取られるのは、署名され、暗号化され、圧縮されたストリーム化コンテント４２０の圧縮解除済み、解読済み、デジタル署名検証済みバージョンである。パイプライン４１０内で行われるレイヤリングまたはカプセル化は、各メッセージハンドラ内の処理演算に対応するオブジェクトのための一連のコールバック関数として実装することができる。換言すれば、最初にストリームで開始し、次いで、圧縮解除演算がストリームを圧縮解除済みストリームにし、解読演算がストリームを解読済み、圧縮解除済みストリームにし、デジタル署名検証演算がストリームを検証済み、解読済み、圧縮解除済みストリームにする。これは、受信された署名済み、暗号化済み、圧縮済みストリームについてまさに必要とされることである。各演算が実行されると、対応するオブジェクトは、一連のコールバックを形成すべく前の演算が何であったかを追跡する。これは、処理演算をカプセル化またはラップするために可能な一実施にすぎず、他に多数の実施が可能であり、カプセル化、ラップ、および／またはレイヤリングの範囲内にあると見なすべきである。

図５Ａ〜５Ｃは、メッセージオブジェクト５００を経路指定する一例を示す。図５Ａは、メッセージオブジェクト５００が、ヘッダ１ ５１２、ヘッダ２ ５１４、ヘッダ３ ５１６を含むヘッダの集成体５１０と、ボディ５２０とを含む点で図１に類似している。図５Ｂでは、メッセージオブジェクト５００がルータ５３０に達したとき、ルータ５３０はヘッダの集成体５１０を見て、メッセージをどのように経路指定すべきか決定する。上記で述べたように、メッセージオブジェクトのボディ部分５２０は、経路指定するために具現化することを必要とするのではなく、ラップすることができる。次いで、図５Ｃに示すように、ヘッダの集成体５１０およびボディ５２０は、適切に経路指定される。メッセージボディ５２０をラップしたことにより、ルータ５３０で読み取られたストリームは、具現化されることなしに、書き込みされ経路指定されるストリームに戻されることができる。したがって、ルータについてバッファ要件が削減され、ルータ５３０が所与のバッファサイズで比較的大きなメッセージを処理することを可能にし、ルータ５３０をサービス拒否攻撃に対してより弾力性のあるものにする。

図６は、たとえばメッセージオブジェクトを複数の宛先に送信する際に、ストリーム化部分をバッファすることを必要とせずにメッセージオブジェクトを複製することの一例を示す。ストリームをベースとするモデルを有するということが意味することの１つは、同じメッセージオブジェクトを２度送信することができないことである。転送コード６６０は、受信されたメッセージを送信することを可能にし、新しいメッセージを構築するために必要とされる作業を自動的に実行する。

この場合も図１と同様に、ソースワイヤメッセージ６００は、ヘッダの集成体６１０と、ストリーム化されたボディ６２０とを含む。ヘッダの集成体６１０、およびストリーム化ボディ６２０の一部分６２２は、転送コード６６０によってすでに処理済みである。宛先１ワイヤメッセージ６００−１は、ヘッダ集成体６１０とボディ部分６２２のコピーを含み、ヘッダ集成体６１０−１およびボディ部分６２２−１と呼ばれることに留意されたい。同様に、宛先２ワイヤメッセージ６００−２もまた、ヘッダ集成体６１０とボディ部分６２２のコピーを含み、これらは、ヘッダ集成体６１０−２およびボディ部分６２２−２と呼ばれる。

ボディ６２０のチャンク６２４は、転送コード６６０にストリーム６２４Ａとして見える。転送コード６６０はストリーム６２４Ａから読み取り、転送コード６２４内でチャンク６２４を形成する。転送コード６６０は、ボディ６２０のチャンク６２４をバッファすることに留意されたい。しかし、上記のように、ストリームのチャンクをバッファすることは、有限のバッファサイズを意味し、無制限のバッファを意味するボディ６２０すべてをバッファすることとは対象である。転送コード６６０は、チャンク６２４を宛先１メッセージコンテント６５２−１および宛先２メッセージコンテント６５２−２に書き込み（６６４）、チャンク６２４は、それぞれストリーム６２４Ａ−１およびストリーム６２４Ａ−２として現れる。次いで、ストリーム６２４Ａ−１および６２４Ａ−２は、宛先１ワイヤメッセージ６００−１および宛先２ワイヤメッセージ６００−２でチャンク６２４−１および６２４−２として書き込まれる。転送コード６６０がソースワイヤメッセージ６００をすべて処理したとき、宛先１も宛先２は共にコピーを有することになる。

本発明はまた、機能的ステップおよび／または非機能的動作を含む方法の観点から述べることができる。以下は、本発明を実施する際に実行され得る動作およびステップの説明である。通常、機能的ステップは、本発明について達成される効果の観点から本発明について述べ、一方、非機能的動作は、特定の結果を得るためのより具体的な処置について述べる。機能的ステップと非機能的動作について特定の順序で述べ、特許請求することになるが、本発明は、必ずしも特定の順序、あるいは動作および／またはステップの組合せにも限定されない。

図７Ａ〜７Ｂは、本発明による、バッファ要件を削減するメッセージオブジェクトを処理する方法の例示的な動作およびステップを示す。メッセージオブジェクト用のメッセージオブジェクト定義を指定するステップ（７１０）は、少なくとも１つのストリーム化された部分と、対応するストリーム指向インターフェースを定義するメッセージオブジェクト用のメッセージオブジェクト定義を作成する動作（７１２）を含むことができる。メッセージハンドラのそれぞれが、メッセージオブジェクトに対して実行する、対応する処理演算を識別する１つまたは複数のメッセージハンドラを提供するステップ（７２０）は、その１つまたは複数のメッセージハンドラを定義する動作（７２２）を含むことができる。１つまたは複数のメッセージハンドラからなる順序付けられた集成体を備えるメッセージパイプラインを提供するステップ（７３０）は、構成可能なパイプライン内に含まれることになる１つまたは複数のメッセージハンドラを識別し、順序付ける動作（７３２）を含むことができる。

少なくとも１つのメッセージハンドラがメッセージオブジェクトのストリーム化部分をカプセル化するように、メッセージパイプラインの１つまたは複数のメッセージハンドラでメッセージオブジェクトを処理するステップ（７４０）は、１つまたは複数のメッセージハンドラを呼び出す動作（７４２）を含むことができる。本発明による例示的な一方法は、ストリームをメッセージオブジェクトのストリーム部分に割り当てる動作（７５２）を含むことができる。上記で示したように、この割当ては、メッセージパイプラインの１つまたは複数のメッセージハンドラを呼び出した後で行われることができる。

メッセージオブジェクトの１つまたは複数の非ストリーム部分をバッファするステップ（７６０）は、１つまたは複数の非ストリーム部分をバッファ内に格納する動作（７６２）を含むことができる。別のエンドポイントまたは中間部からメッセージオブジェクトを受信するステップ（７９０）は、メッセージオブジェクトをメッセージトランスポートストリームから読み取る動作（７９２）を含むことができる。メッセージオブジェクトを別のエンドポイントに送信するステップ（７８０）、または複数のエンドポイントに送達するために、メッセージオブジェクトを複製するステップ（７８０）は、メッセージオブジェクトをメッセージトランスポートストリームに書き込む動作（７８２）を含むことができる。読取りと書込みはどちらも、メッセージハンドラからの処理演算をメッセージオブジェクトのストリーム化部分に対して実行させることができることに留意されたい。本発明による例示的な一方法は、メッセージオブジェクトのストリーム化部分をオンデマンドで具現化する動作をさらに含むことができる。

また、本発明の範囲内にある実施形態は、コンピュータ実行可能命令またはデータ構造を担持または記憶するコンピュータ可読媒体を含む。そのようなコンピュータ可読媒体は、汎用コンピュータまたは専用コンピュータによってアクセスすることができる任意の使用可能な媒体とすることができる。限定ではなく例を挙げると、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、コンピュータ実行可能命令またはデータ構造の形態で所望のプログラムコード手段を担持または記憶するために使用することができ、汎用コンピュータまたは専用コンピュータによってアクセスすることができる他の任意の媒体を含むことができる。ネットワークまたは別の通信接続（有線、無線、または有線もしくは無線の組合せ）を介して情報がコンピュータに転送または提供されるとき、コンピュータは当然、その接続をコンピュータ可読媒体と見る。したがって、そのようなどの接続もコンピュータ可読媒体と称するのが妥当である。上記の組合せもまた、コンピュータ可読媒体の範囲内に含むべきである。コンピュータ実行可能命令は、たとえば、汎用コンピュータ、専用コンピュータ、または専用処理デバイスに特定の機能または機能群を実行させる命令およびデータを含む。

図８および以下の考察は、本発明を実施することができる好適なコンピューティング環境について手短に、また一般的に述べることが意図されている。必須ではないが、本発明について、ネットワーク環境内でコンピュータによって実行される、プログラムモジュールなどコンピュータ実行可能命令の一般的な形態で述べることにする。一般に、プログラムモジュールは、特定のタスクを実行する、あるいは特定の抽象データタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。コンピュータ実行可能命令、関連データ構造、およびプログラムモジュールは、本明細書に開示されている方法のステップを実行するためのプログラムコード手段の例を表す。そのような実行可能命令または関連データ構造の特定のシーケンスは、上述したステップの機能を実施するための対応する動作の例を表す。

パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサをベースとする、もしくはプログラム可能な家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む多数のタイプのコンピュータシステム構成と共に、ネットワークコンピューティング環境内で本発明を実施することができることを、当業者なら理解するであろう。本発明はまた、通信ネットワークを介して（有線リンク、無線リンクによって、または有線リンクもしくは無線リンクの組合せによって）リンクされているローカルおよびリモート処理装置によってタスクが実行される分散コンピューティング環境で実施することができる。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモートの双方のメモリ記憶デバイス内に位置する可能性がある。

図８を参照すると、本発明を実施するための例示的なシステムは、処理装置８２１、システムメモリ８２２、およびシステムメモリ８２２を含む様々なシステム構成要素を処理装置８２１に結合するシステムバス８２３を含む従来型コンピュータ８２０の形態で、汎用コンピューティングデバイスを含む。システムバス８２３は、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺機器バス、およびローカルバスを含むいくつかのタイプのバス構造のいずれかとすることができる。システムメモリは、読出し専用メモリ（ＲＯＭ）８２４およびランダムアクセスメモリ（ＲＡＭ）８２５を含む。起動中などにコンピュータ８２０内の要素間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）８２６は、ＲＯＭ８２４内に記憶されている可能性がある。

コンピュータ８２０はまた、磁気ハードディスク８３９との間で読出しまたは書込みをする磁気ハードディスクドライブ８２７、取外し式の磁気ディスク８２９との間で読出しまたは書込みをする磁気ディスクドライブ８２８、ＣＤ−ＲＯＭまたは他の光媒体など取外し式の光ディスク８３１との間で読出しまたは書込みをする光ディスクドライブ８３０を含むことができる。磁気ハードディスクドライブ８２７、磁気ディスクドライブ８２８、光ディスクドライブ８３０は、それぞれハードディスクドライブインターフェース８３２、磁気ディスクドライブインターフェース８３３、光ドライブインターフェース８３４によってシステムバス８２３に接続される。ドライブ群とそれらの関連コンピュータ可読媒体は、コンピュータ実行可能命令、データ構造、プログラムモジュール、およびコンピュータ８２０用の他のデータの不揮発性記憶を実現する。本明細書に述べられている例示的な環境は、磁気ハードディスク８３９、取外し式の磁気ディスク８２９、および取外し式の光ディスク８３１を使用するが、磁気カセット、フラッシュメモリカード、デジタル多用途ディスク、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなどを含む、データを記憶するための他のタイプのコンピュータ可読媒体を使用することができる。

１つまたは複数のプログラムモジュールを含むプログラムコード手段は、ハードディスク８３９、磁気ディスク８２９、光ディスク８３１、ＲＯＭ８２４、またはＲＡＭ８２５に記憶することができ、オペレーティングシステム８３５、１つまたは複数のアプリケーションプログラム８３６、他のプログラムモジュール８３７、およびプログラムデータ８３８を含む。ユーザは、キーボード８４０、ポインティングデバイス８４２、または他の入力デバイス（図示せず）、たとえばマイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどを介して、コンピュータ８２０にコマンドおよび情報を入力することができる。これら、および他の入力デバイスは、しばしばシステムバス８２３に結合されたシリアルポートインターフェース８４６を介して処理装置８２１に接続される。あるいはまた、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）など他のインターフェースによって、入力デバイスを接続することができる。また、モニタ８４７または別のディスプレイデバイスは、ビデオアダプタ８４８などのインターフェースを介して、システムバス８２３に接続される。モニタに加え、パーソナルコンピュータは一般に、スピーカおよびプリンタなど、他の周辺出力デバイス（図示せず）を含む。

コンピュータ８２０は、リモートコンピュータ８４９ａおよび８４９ｂなど、１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク環境内で動作することができる。リモートコンピュータ８４９ａおよび８４９ｂはそれぞれ、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードとすることができ、図８では、メモリ記憶デバイス８５０ａおよび８５０ｂとそれらの関連アプリケーションプログラム８３６ａおよび８３６ｂが例示されているだけであるが、一般に、コンピュータ８２０に関連して上記で述べた要素の多数または全部を含む。図８に示されている論理接続は、ここでは限定ではなく例示のために提示されているローカルエリアネットワーク（ＬＡＮ）８６１およびワイドエリアネットワーク（ＷＡＮ）８６２を含む。そのようなネットワーク環境は、事務所規模または全社規模のコンピュータネットワーク、イントラネットおよびインターネットが一般的である。

コンピュータ８２０は、ＬＡＮネットワーク環境内で使用されるとき、ネットワークインターフェースまたはアダプタ８６３を介してローカルネットワーク８６１に接続される。コンピュータ８２０は、ＷＡＮネットワーク環境内で使用されるとき、インターネットなどワイドエリアネットワーク８６２を介して通信を確立するためのモデム８６４、無線リンク、または他の手段を含むことができる。モデム８６４は、内部にあっても外部にあってもよく、シリアルポートインターフェース８４６を介してシステムバス８２３に接続される。ネットワーク環境では、パーソナルコンピュータ８２０に関して図示されたプログラムモジュール、またはその一部分を、リモートメモリ記憶デバイス内に記憶することができる。図のネットワーク接続は例であり、ワイドエリアネットワーク８６２を介して通信を確立する他の手段を使用することができることは理解されるであろう。

本発明は、その趣旨または本質的な特徴から逸脱することなしに、他の特定の形態で実施することができる。上述の実施形態は、あらゆる面において限定的なものではなく、例示的なものにすぎないと見なすべきである。したがって、本発明の範囲は、前述の説明によって示されるものではなく、添付の特許請求の範囲によって示される。特許請求の範囲およびその均等の範囲に属するすべては、本発明の範囲に包含される。

本発明によるメッセージングシステムによって処理する例示的なメッセージを示す図である。 ストリームからメッセージオブジェクトを読み取る一例を示す図である。 ストリームにメッセージオブジェクトを書き込む一例を示す図である。 メッセージオブジェクトを処理するための例示的なパイプラインを示す図である。 メッセージオブジェクト処理のための入れ子のパイプライン例を示す図である。 メッセージオブジェクトのストリーム化されたメッセージコンテントをラップまたはカプセル化することを示す図である。 メッセージオブジェクトを経路指定することの一例を示す図である。 メッセージオブジェクトを経路指定することの一例を示す図である。 メッセージオブジェクトを経路指定することの一例を示す図である。 ストリーム化部分をバッファすることを必要とせずにメッセージオブジェクトを複製することの一例を示す図である。 本発明による、バッファ要件を削減するメッセージオブジェクトを処理する方法の例示的な動作およびステップを示す図である。 本発明による、バッファ要件を削減するメッセージオブジェクトを処理する方法の例示的な動作およびステップを示す図である。 本発明に適した動作環境を提供する例示的なシステムを示す図である。

符号の説明

４００ メッセージ
４１０ パイプライン
４２０ ストリーム化コンテント
４３２ メッセージハンドラ
４３２Ａ 演算
４３４ メッセージハンドラ
４３４Ａ 演算
４３６ メッセージハンドラ
４３６Ａ 演算

Claims (42)

1. １つまたは複数のメッセージトランスポートを介してメッセージを送信または受信するための、所与のバッファサイズを有するメッセージングシステムにおいて、前記メッセージの少なくとも一部分についてバッファ要件を削減することにより、前記メッセージングシステムが前記所与のバッファサイズを使用して比較的大きなメッセージを送信または受信することを可能にするメッセージ処理方法であって、
   ストリーム指向インターフェースを有する少なくとも１つのストリーム化部分を含むメッセージオブジェクトに対して実行するための対応する処理演算をそれぞれ識別する１つまたは複数のメッセージハンドラを定義する動作と、
   構成可能なパイプライン内に含まれることになる１つまたは複数のメッセージハンドラを識別し、順序付ける動作と、
   前記メッセージオブジェクトを処理するために前記メッセージパイプラインの前記１つまたは複数のメッセージハンドラを呼び出す動作であって、バッファ内で前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を具現化することなしに、少なくとも１つのメッセージハンドラが、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を、将来実行される、前記少なくとも１つのメッセージハンドラに対応する処理演算で、ラップする動作とを含むことを特徴とする方法。
2. 前記パイプラインは複数のメッセージハンドラを含むこと、ならびに、前記複数のメッセージハンドラの各々は、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を、前記複数のメッセージハンドラの各々に対応する処理演算で連続的にラップし、その結果、複数の処理演算が、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分上でレイヤリングされることを特徴とする請求項１に記載の方法。
3. 前記メッセージオブジェクトは、１つまたは複数のヘッダ部分と少なくとも１つのボディ部分とを備えること、ならびに、前記ボディ部分は、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を備えることを特徴とする請求項１に記載の方法。
4. 前記メッセージオブジェクトは、シンプルオブジェクトアクセスプロトコルメッセージオブジェクトを含むことを特徴とする請求項３に記載の方法。
5. 前記メッセージングシステムは、前記メッセージオブジェクトを経路指定する責任を負う中間部であることを特徴とする請求項４に記載の方法。
6. 前記中間部は、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を具現化することを必要とせずに、前記メッセージを経路指定するために少なくとも１つのヘッダを具現化することを特徴とする請求項５に記載の方法。
7. 前記メッセージングシステムはエンドポイントであり、前記方法はさらに、前記メッセージオブジェクトをメッセージトランスポートストリームに書き込む動作を含み、前記メッセージオブジェクトを前記メッセージトランスポートストリームに書き込む前記動作は、前記少なくとも１つの処理動作を前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分に対して実行させることを特徴とする請求項１に記載の方法。
8. 前記メッセージングシステムはメッセージコンシューマを含み、前記方法はさらに、前記メッセージコンシューマが前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分をオンデマンドで具現化する動作を含むことを特徴とする請求項１に記載の方法。
9. 前記メッセージオブジェクトについて前記少なくとも１つのストリーム化部分と、対応するストリーム指向インターフェースとを定義する、前記メッセージオブジェクト用のメッセージオブジェクト定義を作成する動作をさらに含むことを特徴とする請求項１に記載の方法。
10. 複数のメッセージパイプラインが定義され、前記方法はさらに、前記メッセージオブジェクトを処理するために各メッセージパイプラインの前記１つまたは複数のメッセージハンドラを呼び出す動作を含むことを特徴とする請求項１に記載の方法。
11. 前記メッセージパイプラインの少なくとも１つが、別のメッセージパイプライン内で入れ子にされることを特徴とする請求項１０に記載の方法。
12. １つまたは複数のメッセージトランスポートを介してメッセージを送信または受信するための、所与のバッファサイズを有するメッセージングシステム用として、前記メッセージの少なくとも一部分についてバッファ要件を削減することにより、前記メッセージングシステムが前記所与のバッファサイズを使用して比較的大きなメッセージを送信または受信することを可能にするメッセージ処理方法をコンピュータに実行させるための実行可能命令を含むコンピュータプログラムであって、前記方法が、
    ストリーム指向インターフェースを有する少なくとも１つのストリーム化部分を含むメッセージオブジェクトに対して実行するための対応する処理演算をそれぞれが識別する１つまたは複数のメッセージハンドラを定義する動作と、
    構成可能なパイプライン内に含まれることになる１つまたは複数のメッセージハンドラを識別し、順序付ける動作と、
    前記メッセージオブジェクトを処理するために前記メッセージパイプラインの前記１つまたは複数のメッセージハンドラを呼び出す動作であって、バッファ内で前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を具現化することなしに、少なくとも１つのメッセージハンドラが、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を、将来実行される、前記少なくとも１つのメッセージハンドラに対応する処理演算でラップする動作とを含むことを特徴とするコンピュータプログラム。
13. 前記パイプラインは複数のメッセージハンドラを含むこと、ならびに、前記複数のメッセージハンドラの各々は、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を、前記複数のメッセージハンドラの各々に対応する処理演算で連続的にラップし、その結果、複数の処理演算が、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分上でレイヤリングされることを特徴とする請求項１２に記載のコンピュータプログラム。
14. 前記メッセージオブジェクトは、１つまたは複数のアタッチメント部分を備えることを特徴とする請求項１２に記載のコンピュータプログラム。
15. 前記メッセージパイプラインの前記１つまたは複数のメッセージハンドラを呼び出すことが、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分にストリームが割り当てられる前に行われることを特徴とする請求項１２に記載のコンピュータプログラム。
16. 前記メッセージングシステムはエンドポイントであり、前記方法はさらに、前記メッセージオブジェクトをメッセージトランスポートストリームから読み取る動作を含み、前記メッセージオブジェクトを前記メッセージトランスポートストリームから読み取る前記動作は、前記少なくとも１つの処理動作を前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分に対して実行させることを特徴とする請求項１２に記載のコンピュータプログラム。
17. 前記メッセージオブジェクトは、１つまたは複数の非ストリーム化部分を備え、前記方法はさらに、前記１つまたは複数の非ストリーム化部分をバッファ内に格納する動作を含むことを特徴とする請求項１２に記載のコンピュータプログラム。
18. 前記メッセージングシステムはメッセージコンシューマを含み、前記方法はさらに、前記メッセージコンシューマが前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分をオンデマンドで具現化する動作を含むことを特徴とする請求項１２に記載のコンピュータプログラム。
19. 前記方法は、バッファ内で前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を具現化することなしに、複数のエンドポイントに送達するために、前記メッセージオブジェクトを複数のトランスポートストリームに書き込む動作を含むことを特徴とする請求項１２に記載のコンピュータプログラム。
20. 複数のメッセージパイプラインが定義され、前記方法はさらに、前記メッセージオブジェクトを処理するために各メッセージパイプラインの前記１つまたは複数のメッセージハンドラを呼び出す動作を含むことを特徴とする請求項１２に記載のコンピュータプログラム。
21. １つまたは複数のメッセージトランスポートを介してメッセージを送信または受信するための、所与のバッファサイズを有するメッセージングシステムにおいて、前記メッセージの少なくとも一部分についてバッファ要件を削減することにより、前記メッセージングシステムが前記所与のバッファサイズを使用して比較的大きなメッセージを送信または受信することを可能にするメッセージ処理方法であって、
    ストリーム指向インターフェースを有する少なくとも１つのストリーム化部分を含むメッセージオブジェクトに対して実行するための対応する処理演算をそれぞれ識別する１つまたは複数のメッセージハンドラを提供するステップと、
    １つまたは複数のメッセージハンドラからなる順序付けられた集成体を備えるメッセージパイプラインを提供するステップと、
    前記メッセージオブジェクトを前記メッセージパイプラインの前記１つまたは複数のメッセージハンドラで処理するステップであって、バッファ内で前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を具現化することなしに、少なくとも１つのメッセージハンドラが、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を、前記少なくとも１つのメッセージハンドラに対応する処理演算でカプセル化するステップとを含むことを特徴とする方法。
22. メッセージパイプラインを提供する前記ステップは、前記１つまたは複数のメッセージハンドラを識別し、順序付ける動作を含むことを特徴とする請求項２１に記載の方法。
23. 前記パイプラインは複数のメッセージハンドラを含むこと、ならびに、前記複数のメッセージハンドラの各々は、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を、前記複数のメッセージハンドラの各々に対応する処理演算で連続的にラップし、その結果、複数の処理演算が、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分上でレイヤリングされることを特徴とする請求項２１に記載の方法。
24. 前記メッセージオブジェクトは、１つまたは複数のアタッチメント部分を備えることを特徴とする請求項２１に記載の方法。
25. 前記メッセージパイプラインの前記１つまたは複数のメッセージハンドラを呼び出すことが、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分にストリームが割り当てられる前に行われることを特徴とする請求項２１に記載の方法。
26. 前記メッセージングシステムはエンドポイントであり、前記方法はさらに、前記メッセージオブジェクトを別のエンドポイントまたは中間部から受信するステップを含み、前記メッセージオブジェクトを受信する前記ステップは、前記少なくとも１つの処理動作を前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分に対して実行させることを特徴とする請求項２１に記載の方法。
27. 前記メッセージオブジェクトは、１つまたは複数の非ストリーム化部分を備え、前記方法はさらに、前記１つまたは複数の非ストリーム化部分をバッファするステップを含むことを特徴とする請求項２１に記載の方法。
28. 前記メッセージングシステムはメッセージコンシューマを含み、前記方法はさらに、前記メッセージコンシューマが前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分をオンデマンドで具現化する動作を含むことを特徴とする請求項２１に記載の方法。
29. バッファ内で前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を具現化することなしに、複数のエンドポイントに送達するために、前記メッセージオブジェクトを複製するステップを含むことを特徴とする請求項２１に記載の方法。
30. 複数のメッセージパイプラインが提供され、前記方法はさらに、各メッセージパイプラインの前記１つまたは複数のメッセージハンドラのそれぞれで前記メッセージオブジェクトを処理するステップを含むことを特徴とする請求項２１に記載の方法。
31. １つまたは複数のメッセージトランスポートを介してメッセージを送信または受信するための、所与のバッファサイズを有するメッセージングシステム用として、前記メッセージの少なくとも一部分についてバッファ要件を削減することにより、前記メッセージングシステムが前記所与のバッファサイズを使用して比較的大きなメッセージを送信または受信することを可能にするメッセージ処理方法をコンピュータに実行させるための実行可能命令を含むコンピュータプログラムであって、前記方法は、
    ストリーム指向インターフェースを有する少なくとも１つのストリーム化部分を含むメッセージオブジェクトに対して実行するための対応する処理演算をそれぞれ識別する１つまたは複数のメッセージハンドラを提供するステップと、
    １つまたは複数のメッセージハンドラからなる順序付けられた集成体を備えるメッセージパイプラインを提供するステップと、
    前記メッセージオブジェクトを前記メッセージパイプラインの前記１つまたは複数のメッセージハンドラで処理するステップであって、バッファ内で前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を具現化することなしに、少なくとも１つのメッセージハンドラが、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を、前記少なくとも１つのメッセージハンドラに対応する処理演算でカプセル化するステップとを含むことを特徴とするコンピュータプログラム。
32. メッセージパイプラインを提供する前記ステップは、前記１つまたは複数のメッセージハンドラを識別し、順序付ける動作を含むことを特徴とする請求項３１に記載のコンピュータプログラム。
33. 前記パイプラインは複数のメッセージハンドラを含むこと、ならびに、前記複数のメッセージハンドラの各々は、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を、前記複数のメッセージハンドラの各々に対応する処理演算で連続的にラップし、その結果、複数の処理演算が、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分上でレイヤリングされることを特徴とする請求項３１に記載のコンピュータプログラム。
34. 前記メッセージオブジェクトは、１つまたは複数のヘッダ部分と少なくとも１つのボディ部分とを備えること、ならびに、前記ボディ部分は、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を備えることを特徴とする請求項３１に記載のコンピュータプログラム。
35. 前記メッセージオブジェクトは、シンプルオブジェクトアクセスプロトコルメッセージオブジェクトを含むことを特徴とする請求項３４に記載のコンピュータプログラム。
36. 前記メッセージングシステムは、前記メッセージオブジェクトを経路指定する責任を負う中間部であることを特徴とする請求項３５に記載のコンピュータプログラム。
37. 前記中間部は、前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分を具現化することを必要とせずに、前記メッセージを経路指定するために少なくとも１つのヘッダを具現化することを特徴とする請求項３６に記載のコンピュータプログラム。
38. 前記メッセージングシステムはエンドポイントであり、前記方法はさらに、前記メッセージオブジェクトを別のエンドポイントに送信するステップを含み、前記メッセージオブジェクトを送信する前記ステップは、前記少なくとも１つの処理動作を前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分に対して実行させることを特徴とする請求項３１に記載のコンピュータプログラム。
39. 前記メッセージングシステムはメッセージコンシューマを含み、前記方法はさらに、前記メッセージコンシューマが前記メッセージオブジェクトの前記少なくとも１つのストリーム化部分をオンデマンドで具現化する動作を含むことを特徴とする請求項３１に記載のコンピュータプログラム。
40. 前記方法はさらに、前記メッセージオブジェクトについて前記少なくとも１つのストリーム化部分と、対応するストリーム指向インターフェースとを定義する、前記メッセージオブジェクト用のメッセージオブジェクト定義を指定するステップをさらに含むことを特徴とする請求項３１に記載のコンピュータプログラム。
41. 複数のメッセージパイプラインが提供され、前記方法はさらに、各メッセージパイプラインの前記１つまたは複数のメッセージハンドラのそれぞれで前記メッセージオブジェクトを処理するステップを含むことを特徴とする請求項３１に記載のコンピュータプログラム。
42. 前記メッセージパイプラインの少なくとも１つが、別のメッセージパイプライン内で入れ子にされることを特徴とする請求項４１に記載のコンピュータプログラム。

Images