JP2006216034A - 相関メッセージを、ネットワークを介して通信するための待機セッション - Google Patents

Abstract

【課題】メッセージがネットワークを介してあるアプリケーションから別のアプリケーションに個別のグループ分けまたは通信セッションで送達されることを可能にする。
【解決手段】送信側コンピュータシステムは、受信側コンピュータシステムのキューに関連メッセージのグループを送信する。受信側コンピュータシステムは、そのグループのメッセージが関連していることを識別し、セッション指向通信チャネルを開始する。受信側コンピュータは、適切なアプリケーションにそのメッセージグループを渡し、第１のメッセージグループに関連していない新しいメッセージグループのための新しい異なるセッション指向通信チャネルを開く。受信された各メッセージの順序識別子が、グループ内のメッセージが特定のアプリケーションによって、どんな順序で処理されるかについて受信コンピュータシステムに指示する。
【選択図】図１

Description

本発明は、相関のあるメッセージを、ネットワークを介してあるアプリケーションから別のアプリケーションに安全でリソース効率のよいやり方で送信するためのシステム、方法およびコンピュータプログラム製品に関する。

コンピュータ化されたシステムの普及が進むにつれて、ローカルエリアネットワークなどの小規模なネットワーク、ならびにインターネットなどの大規模のまたは世界的規模のネットワーク内でコンピュータシステムを相互接続する必要性も高まってきた。一般にコンピュータシステムおよび関連装置は、たとえば単純に個人的な電子メールを交換するためであろうが、商品を販売するためであろうが、様々な理由のために所与のネットワークに接続され、ファイルの共有などのためにアカウント情報を提供する。しかし、コンピュータシステムが個人的な使用のためにますます洗練されるにつれて、ネットワーク上でコンピュータシステムを相互接続することに付随する課題も増加してきたことが理解されよう。

一般にコンピューティングシステムは、アプリケーションプログラムでメッセージを構成し、次いでメッセージがその宛先に適切に届くように１つまたは複数のやり方でメッセージをパッケージ化することによって、ネットワーク上の別のコンピューティングシステムにメッセージを通信する。具体的には、送信側コンピュータシステム上の１つまたは複数のコンポーネントまたはモジュールはアドレスまたはルーティング情報をメッセージに追加することがあり、別のコンポーネントまたはモジュールはメッセージが転送中に読み出され得ないようにそれを暗号化し得る。次いで、受信側のコンピュータシステムは、メッセージを取り、適宜データをアンパックし、データを処理する。したがって、送信側と受信側コンピュータ上の１つまたは複数のアプリケーション間でデータを渡すことは、一般に複数の異なるコンピュータシステム上の複数のアプリケーション、モジュール、コンポーネント、プロトコルおよび処理リソースを要する。

残念なことに、現在のいくつかの待機メッセージ通信機構に付随する複数の問題がある。別のコンピュータから相関のあるメッセージを受信するときに受信側コンピュータは一般に、個々のメッセージがどのように処理されるか、それが処理されるべきかどうか、またはどのアプリケーションで処理されるかについての何らかのコンテキストを得るために、受信される各メッセージを「ピーク」(peek)（または照会）しなければならない。一般に受信側のコンピュータもまた、メッセージが一緒に処理されるようにそれがグループ内で相関しているかどうか判断するために、この「ピーク」または「照会」機能を行わなければならないことがある。このようにメッセージをピークまたは照会するために、受信側コンピュータシステム上のモジュールは、メッセージが別のアプリケーションではなく、あるアプリケーションによって、あるいは関連のないメッセージと共にではなく、アプリケーション上の関連のある別のメッセージと共に処理される必要があることなどを認識する前に、メッセージを非直列化(deserialize)し、次いでメッセージ内の数層のヘッダを読み出す必要があり得る。場合によっては、これは、完全に異なるコンピュータシステムによってメッセージが処理される必要があることを認識する前に受信側コンピュータシステムがメッセージ内の数層のヘッダを読み出すことを必要とし得る。

したがって、メッセージを受信し、転送し、処理するための従来のシステムは、具体的には所定の順序およびグループ分けで処理される関連するメッセージについての複数の問題をもたらし得る。たとえばメッセージをグループで処理するためのある従来方法は、メッセージが受信される順序でそれを処理することである。残念なことに、メッセージがそれぞれ適切な順序でグループで、さらには特定のグループ分けで受信側コンピュータに届くという保証はほとんどない。たとえばメッセージの通過経路に沿った任意の数の中継または処理機構は、あるメッセージを次のメッセージよりも遅延させることがあり、メッセージが順序が狂って届くことを引き起こす。これは、関連のないメッセージが関連のあるメッセージのグループと混合されて受信される場合に悪化され得る。したがって、受信側コンピュータシステムは、メッセージがどのように処理されるべきかについての適切なコンテキストを得るためにかなりの量のメッセージを読む必要があり得る。

リソース処理の観点からの問題を潜在的にもたらすことに加えて、メッセージを適切なアプリケーションに転送する前にある量のメッセージを読み出す（または「ピークする」または「照会する」）ことを受信側のコンピュータシステムに求めることは、セキュリティに関する他の問題をもたらし得る。たとえば、メッセージがアンパックされ、非直列化されまたは復号されるまでメッセージの処理コンテキストが確認され得ない場合、メッセージ内の機密情報は、不適切なアプリケーションまたはプロセスによるインターセプトに対して脆弱であり得る。

したがって、この技術の利点は、メッセージがネットワークを介してあるアプリケーションから別のアプリケーションに相関が取られるやり方で、また適切なときに意図される処理順序でまたはグループ分けで送信されることを可能にするシステム、方法およびコンピュータプログラム製品で実現され得る。さらに、この技術の利点は、メッセージが適切なアプリケーションによって受信される前に、意図されないアプリケーションまたはコンピュータシステムにメッセージの一部を非直列化しまたは復号することを求めずにメッセージがネットワークを介して送信されることを可能にするシステムおよび方法で実現され得る。

本発明は、個別の通信セッションおよびセッション指向チャネルを介して関連メッセージをキューに入れることによって、相関を取るやり方で意図されるようにメッセージが通信されることを可能にするシステム、方法およびコンピュータプログラム製品を用いて当技術の上記問題の１つまたは複数を解決する。具体的には、本発明によるシステムおよび方法は、受信側のコンピュータシステムがそれぞれ異なるメッセージグループを適切に処理し得るように、あるアプリケーションから別のアプリケーションに個別の通信セッションでメッセージが送信されることを可能にする。

たとえば本発明の少なくとも１つの実装では、送信側コンピュータの観点からの一方法は、受信側コンピュータシステム上で処理される相関するメッセージのグループを作成する行為を備え、該グループ内のあるメッセージは第１のメッセージであり、該グループ内の別のメッセージは最後のメッセージである。この方法は、そのメッセージグループのためのセッション指向通信チャネルを作成し、受信側コンピュータシステム上のアドレス指定可能なキューにメッセージグループを送信する行為をも備える。送信側コンピュータシステムの観点からのこの方法は、異なるメッセージグループのための異なるセッション指向通信チャネルを作成する行為をさらに備える。したがって、本発明の実施は、送信側コンピュータシステムが個別の通信セッションを介して個別のグループ分けで相関メッセージを送信することを可能にする。

受信側コンピュータシステムの観点からの本発明の一方法は、キューで１つまたは複数のメッセージを受信する行為を備え、このキューで、メッセージのうちの少なくとも１つは、相関メッセージのグループの第１のメッセージとして識別可能である。この方法は、相関メッセージのグループのためのセッション指向通信チャネルを作成し、グループの最後のメッセージなど、グループの残りのメッセージのうちの１つまたは複数を最終的に受信する行為をも備える。グループの最後のメッセージを受信し、受信側コンピュータシステムがセッション内のすべてのメッセージが受信されたことを認識し、かつ／またはグループ内の受信された相関メッセージのすべてを処理した後に、セッションチャネルは閉じられる。相関メッセージの異なるグループの第１のメッセージを受信すると、受信側コンピュータは、異なるセッション指向の通信チャネルを作成する。したがって、本発明の実施は、受信側コンピュータシステムが個別のセッション指向通信チャネルを使用してメッセージグループを相関させることを可能にする。

さらに、グループ内の十分に関連したメッセージは、受信側のコンピュータシステム上で、コンテキストを求めて詳細に読み出される必要はなく、また関連のないメッセージグループと混合されない。さらに、所与の通信セッション内のメッセージは、送信側コンピュータシステムによって示されるように、指定された順序またはグループ分けで処理され得る。さらに、相関メッセージのグループは、メッセージが受信されまたは送信されるときに、また適切なときに、指定されたアプリケーションによって部分的に処理されることもできる。さらに、送信側または受信側のアプリケーションは、部分的に処理されたグループを識別するセッション識別子をもつセッションチャネルを作成することによって、部分的に処理されたグループに再接続することができる。さらに、メッセージは、転送中の遅延、メッセージサイズまたは送信の失敗による受信順序の変化に対処するやり方で送信され得る。さらに、本発明の実施は、断続的なルータが、同じセッションの一部である複数のメッセージのルートを「選択し」、同じ受信側処理ノードに「付ける」ことを可能にする。

本発明の追加の特徴および利点について、以下の説明で述べ、またそれは説明から一部明らかであり、あるいはこうした例示的な実施を行うことによって知ることができる。こうした実施の特徴および利点は、添付の特許請求の範囲中に具体的に指摘する手段および組合わせによって実現され取得され得る。これらのおよび他の特徴は、以下の説明および添付の特許請求の範囲からより完全に明らかになり、または以下で述べる例示的な実施を行うことよって知ることができる。

本発明の上記および他の利点および特徴が取得され得るやり方について述べるために、上記で簡潔に述べた本発明についてのより具体的な説明は、添付の諸図面中に示されるその具体的な実施形態を参照することによって提供される。これらの図面は本発明の一般的な実施形態を示すものにすぎず、したがってその範囲を限定するものと見なすべきでないとの理解のもとに、本発明について、添付の諸図面を使用することによってさらに具体的にかつ詳細に示し説明する。

本発明は、個別の通信セッションおよびセッション指向チャネルを介して関連メッセージをキューに入れることによって、相関を取るやり方で意図されるようにメッセージが通信されることを可能にするシステム、方法およびコンピュータプログラム製品に及ぶ。具体的には、本発明によるシステムおよび方法は、受信側コンピュータシステムがそれぞれ異なるメッセージグループを適切に処理することができるように、メッセージがあるアプリケーションから別のアプリケーションに個別の通信セッションで送信されることを可能にする。

たとえば、本明細書および特許請求の範囲から理解されるように、本発明のある態様は、キューイングプロトコルの側面を通信セッションの一般的な側面と組み合わせることを伴う。本発明の別の態様は、特定のキューに送信され、次いで単一の処理ノードまたはアプリケーションによって相関を取るやり方で処理される相関のあるメッセージを準備し、受信することを伴う。本発明の別の態様は、セッション内で特定の順序で、またはグループの一部として適宜メッセージを識別し処理することに関する。

たとえば図１に、本発明の１つまたは複数の実施を行うための概要概略図を示す。具体的には、図１は、送信側コンピュータシステム１００上のアプリケーション１０３が、特定の処理ノードによってたとえば順次に、またはグループの一部として任意の順序で処理されるなど、相関を取るやり方で処理される１つまたは複数の相関するメッセージ１１０、１１３および１１５を作成することを示している。たとえば、ユーザは、オンライン銀行で特定のアプリケーションの使用を必要とするある取引を要求し、次いでその取引の完了後に、同じアプリケーションを使用するが、異なる１組の相関データをユーザに必ずしも求めない別の取引をオンライン銀行で要求することがある。

一般に、送信側コンピュータシステム１００は、そうするように構成されている場合、個別の通信セッション、および対応するセッション指向チャネル１２０を開始する。送信側コンピュータシステム１００は、何らかのやり方でメッセージグループを相関させるための機構を伴って構成されている限りは、本明細書で述べるように、セッション通信を必ずしも理解する必要はない。たとえば、通信セッションを実施しない送信側コンピュータシステムは、グループ内のあるメッセージは第１のメッセージであり、グループ内の別のメッセージは最後のメッセージであることを示すことによって単純にメッセージグループを相関させることができる。

一般に、通信チャネルは単純に、ネットワーク通信の状態を定義する１つまたは複数の層を有するネットワークスタックなどの通信スタックである。一方、セッションは、相関メッセージのあるグループはある通信セッションに関連付けられ、異なる相関メッセージのグループは異なる通信セッションに関連付けられるような、相関メッセージのグループのための個別の識別子と理解されよう。次いで、セッション指向チャネルは、個別のメッセージセッションを通信するために使用されるチャネルである。本発明の一部の実装では、送信側または受信側コンピュータシステムは、所与の任意の通信セッションについて、１つのセッション指向通信チャネルを作成する。他の実装では、１つのセッション内で複数の通信チャネル有すること、および１つのセッション指向チャネルに関連して使用される複数の通信セッションを有することが可能である。

いずれにせよ図１は、相関が取られるように処理されるメッセージ１１０、１１３および１１５のそれぞれが最初にセッション指向チャネル１２０を介して受信側コンピュータシステム１５０に送信されることを示している。したがって、ライタ１０５は、各メッセージ１１０、１１３および１１５が共通のセッション識別子を有するように、各メッセージが相関グループの一部であることを示すセッション情報を各メッセージ１１０、１１３および１１５内に含める。ライタ１０５は、セッションが順序付けられたセッションであるか、それともセッション内のメッセージが任意の順序で処理され得るかどうかなど、メッセージの順序付けに関するヘッダ情報をも含めることができる。セッションが順序付けられたセッションである場合、ライタ１０５は、たとえばメッセージ１１０がグループ内の３つのメッセージのうちの第１のメッセージであることを示す順序識別子を含め得る。

しかし、順序識別子は、すべての場合で必要であるとは限らない。たとえば送信側コンピュータシステム１００がセッションを実施しないように構成されているが、メッセージグループが相関していることを識別し得る場合、本発明の実施は、受信側コンピュータシステム１５０がメッセージグループをセッションに関連付け、次いで単一の処理ノードでメッセージグループをいずれかの任意の順序で処理することを可能にする。具体的には、受信側コンピュータシステム１５０は、メッセージ１１０、１１３および１１５がどのように受信されようが、順番正しくであろうが、順序が乱れた状態であろうが、順序付けられまたは順序付けられないセッションにメッセージが関連付けられていようが、そうでなかろうが、メッセージ１１０、１１３および１１５を処理し得る。したがって、本発明の実施は、順序付けが相関メッセージの所与のグループに関連付けられ、または必ずしも関連付けられない場合に適用することができる。

さらに、アプリケーションライタ１０５は、キューマネージャ１４０で特定のセッション指向のキューを識別するキューアドレス１２３の情報を含めることによってメッセージを準備することができる。アプリケーションライタ１０５は、ローカルキューマネージャ１３０によって維持される通信チャネル１２０についての状態情報をも含め得る。具体的には、通信チャネルについての状態情報は、特に挙げると、各メッセージ１１０、１１３および１１５を特定のセッションの一部として相関させる情報を含み得る。したがって、送信側コンピュータシステム１００上で、キューマネージャ１３０は、アプリケーション１０３とインターフェースする１つまたは複数のコンポーネントと、セッション指向チャネルの１つまたは複数の層とを備える。さらに、キューマネージャ１３０（および／またはキューマネージャ１４０）は、チャネル通信スタック内の各層についての状態情報、ならびにメッセージ１１０、１１３、１１５などのグループ分けが通信セッション１１７に関連することを識別する状態情報を維持することができる。キューマネージャ１３０、１４０は、送信側および／または受信側コンピュータシステムに対してローカルとすることができ、またリモートとし、したがってルーティング経路上の中間システム上に存在し得る。

図１に示すように、キューマネージャ１３０は、受信側キューマネージャ１４０にメッセージを送信する前に、相関するメッセージグループ（すなわちセッション）をキュー内に格納するなど、任意の数の適切な機能を実施し得る。キューマネージャ１３０は、メッセージ１１０、１１３および１１５への対応する１つまたは複数のヘッダ、ならびに移送のための各メッセージのパッケージを含み得る。具体的には、キューマネージャ１３０は、適切な場合に所与のメッセージヘッダ内に状態値を含め得る。キューマネージャ１３０は、メッセージがアドレス指定されたキュー１２３にトンネルされ得るように、他のデータ構造内に機密のデータ構造体を挿入することによって各メッセージ１１０、１１３および１１５の一部をカプセル化することもできる。

さらに、キューマネージャ１３０は、特定の通信セッションのメッセージが適切に転送されることを確実にするのに役立つ単純オブジェクトアクセスプロトコル（「ＳＯＡＰ」：Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）メッセージの場合には、「経由」情報などのヘッダ情報を挿入することができる。このようなＳＯＡＰヘッダ情報は、「ＳＯＡＰ認識型（ＳＯＡＰ−ａｗａｒｅ）」である中間ルータにとって特に有用であり得る。接続経路内の中間ルータがＳＯＡＰ認識型である場合、ヘッダ情報（「経由」(Via)など）は、特定の通信セッションで受信され渡されるすべてのメッセージが、処理に適したノードに転送されることを中間ルータが保証する助けとなり得る。

アプリケーションライタ１０５によってまだ挿入されていない場合、キューマネージャ１３０はセッション識別子をメッセージ１１０、１１３および１１５内に挿入することができ、このセッション識別子は、相関メッセージの指定されたグループのための通信セッションを一意に識別する。相関メッセージの別のグループとは異なるやり方で処理される相関メッセージの各グループについて新しい異なるセッションが作成されるので、相関メッセージの各グループ分けは、一意のセッション識別子（「ＩＤ」）を有する。したがって、図１に示すようにメッセージ１１０は、そのメッセージがセッション１１７の一部であることの情報を含む。メッセージ１１３および１１５にセッション１１７の識別子が設けられる場合、受信側コンピュータシステム１５０は、処理のために各メッセージ１１０、１１３および１１５を相関グループの一部として容易に認識する。

図１は、送信側コンピュータシステム１００がメッセージ１１０、１１３、１１５をアドレス指定されたキュー１２３に直接に向けることができる。ある実装では、メッセージの中継は、１つまたは複数のストア、ならびに送信側および／または受信側コンピュータシステム間の転送中間物（図示せず）に沿ってメッセージを渡すことを伴う。メッセージ（１１０、１１３および／または１１５）の転送中に１つまたは複数の点で接続が失敗し得ることも理解されよう。しかし、少なくとも一部はそれぞれのメッセージが各メッセージグループに一意のセッション識別子を含むという理由から、またＳＯＡＰメッセージヘッダ内でこの情報がＳＯＡＰ認識型ルータにとって使用可能である場合には、接続の中断および失敗は対処され得る。

具体的には、失敗し、中断されまたは再開された通信セッション内のメッセージは、適切な処理ノードに依然としてルーティングされ、好ましい順序またはグループ分けで最終的に処理され得る。たとえば、送信側コンピュータシステム１００は、セッション内のメッセージのうちの１つ（１１３など）が適切に送信されなかったことの表示を受信し得る。送信側コンピュータシステム１００は、失敗したメッセージを適切なセッション（１１７など）の識別子情報に単純に再び関連付け、メッセージを再送し得る。

さらに、送信側コンピュータシステム１００上のアプリケーション１０３（および受信側コンピュータシステム１５０上のアプリケーション１６０）は、アプリケーション１０３がクラッシュした場合に通信セッションに再接続することができる。たとえばアプリケーション１０３は、１つまたは複数のメッセージを作成している間、相関メッセージグループのための現在のセッションを適切な位置に格納することができる。たとえばアプリケーション１０３はクラッシュすると、新しいセッション指向チャネルを作成し、新しいセッション識別子を使用するか、それともストレージからセッション識別子を回復するかどうかをも決定する。グループが完全には送信されていない場合、アプリケーション１０３は、単純に新しいセッション指向チャネルを回復されたセッション識別子に関連付けることができる。受信側コンピュータシステム１５０についての議論から理解されるように、アプリケーションのクラッシュの後にアプリケーション１６０が新しいセッション指向チャネルを回復されたセッション識別子に関連付ける場合には、類似のプロセスが発生し得る。

したがって、送信側コンピュータシステム１００（および受信側コンピュータシステム１５０）は、それぞれのメッセージ１１０、１１３および１１５が適切なキューマネージャに関してそれが送信されまたは受信される順序に関係なく適切なセッションの一部として適切に通信されることを保証し、したがって適宜それを送信し、または処理することができる。さらに、送信側コンピュータシステム１００は以前に送信したメッセージをキューマネージャ１３０に再送する必要がなく、また受信側コンピュータシステム１５０は以前に受信したすべてのメッセージをキューマネージャ１４０から再送させる必要がないので、処理リソースは節約される。

受信側コンピュータシステム１５０がグループ内のメッセージのうちの１つまたは複数を受信するときに、特定のアプリケーション１６０のためのリスナモジュール１４５は、アプリケーション１６０などのアプリケーションによって処理される必要がある相関メッセージのグループが送信中であることを識別する。応答してリスナ１４５は、受信される相関メッセージを適切なアプリケーションに直接に中継するためにセッション指向チャネル１２１を開始する。たとえば、受信側コンピュータシステム１５０は、相関メッセージのグループが入力メッセージ１１０、１１３などのヘッダ情報内に見られる１つまたは複数のセッション識別子（１１７など）を識別することによって、送信メッセージのグループが受信中であることを識別する。別の実装では、メッセージが何らかの他の相関情報、たとえば「第１のメッセージ」または「最後のメッセージ」の標識などを含むときに、受信側コンピュータシステム１５０は、相関メッセージのグループが送信中であり、または受信されたことを識別する。

一般に通信セッション内の各メッセージは、アンパックされまたは詳細に読み出される必要なしに、アドレス指定されたキュー１２３で受信される。メッセージ１１０、１１３および１１５が受信されるときに、キューマネージャ１４０はメッセージを瞬間的に格納することができ、キュー１２３は、その各順序識別子内に示されるように、受信されるメッセージを順序付けることができる。もちろん、セッション内のメッセージのセッション情報が、そのセッションが順序付けられていないことを示す場合、キュー１２３は、処理の前に必ずしもメッセージを順序付けない。したがって、順序識別子は、セッションが順序付けられたセッションとして示されている状況において実装される。

たとえば、図１は、メッセージ１１０が順序付けられたセッション内でアプリケーション１６０によって処理される３つのメッセージのうちの１つであることを示している。受信されるメッセージ内の別の識別子は、メッセージ１１０が同時に、あるいは順次にではなく、他のメッセージ１１３および１１５と共に単一の処理ノードによって消費される任意の順序で処理されることを示し得る。したがって、ある実施形態では、キュー１２３は、順序付けられまたは適宜処理されるのに十分な数のメッセージが受信されるまで、キューマネージャ１４０で、受信される各メッセージをバッファに入れる。これは、複数の理由のために有用であり得る。

たとえば、メッセージ１１５は、接続経路内の転送中間物での何らかの遅延によりメッセージ１１３より早く到達し得る。あるいは、キュー１２３への送信は、一時的に失敗し得る。送信は同じグループで再開され得るが、メッセージがキュー１２３に送信されまたはそこで受信される順序に何らかの誤った順序付けが存在し得る。しかし、順序付けられたセッション内の各メッセージは特定の順序識別子で相関が取られ得るので、多岐に渡るメッセージ遅延が比較的に容易に対処され得る。さらに、メッセージは受信されるときにバッファ内に入れられ得るので、アプリケーション１０３およびキューマネージャ１３０は、正確に送信された前のメッセージを再処理し再送しなければならないのではなく、メッセージが適切に中継されなかった点で、適切なセッション識別子を含むメッセージを単純に再作成し得る。

いずれにせよ、図１は、次いでリスナモジュール１４５が受信されたメッセージ１１０、１１３および１１５を適切な順序で取り、処理のためにセッション指向チャネル１２１を介してアプリケーション１６０にそれを渡すことを示している。図１は、別のアプリケーション１７０のための別のリスナ１４７が、異なるキューに１２５に向けられた他のメッセージを識別したことも示している。したがって、リスナ１４７は、キューアドレス１２５で受信される相関メッセージをアプリケーション１７０に渡すために使用される異なるセッション指向チャネル１２７を作成する。したがって、図１は、それぞれ異なるリスナ１４５および１４７が、それぞれ異なるセッション指向チャネル１２１、１２７を介して相関メッセージの関連のないグループを区別し得ることを示している。さらに、個々のリスナ１４５、１４７などは、キューマネージャ１４０のキューから同じアプリケーション１６０または１７０への、複数であるが異なっているセッション指向通信チャネルを適宜作成し得る。

いずれにせよ、受信された各メッセージをアプリケーション１６０に渡した後に、リスナモジュール１４５は、最後のメッセージを識別し、セッション指向チャネル１２１を閉じ、あるいはメッセージの新しいグループのための新しいまたは異なるセッションを再開する。たとえばある実施形態では、最後のメッセージは単純に、最後のメッセージの順序識別子によって推論され得る。すなわち、リスナモジュール１４５は、メッセージ１１５が３つのメッセージのうちの３番目を表すこと、ならびにメッセージ１１０および１１３のそれぞれが既に受信されていることを識別する。もちろん、最後のメッセージの標識は最後のメッセージ（１１５など）を送信した後に送信側コンピュータシステムによって送信される別個のメッセージとすることもでき、またはメッセージ自体が、それが送信側コンピュータシステム１００によって送信された単純に最後のメッセージであることの標識を含み得る。したがって、リスナモジュール１４５は、相関メッセージの新しいセッションについて新しい異なるセッション指向チャネルを開始することができ、また相関メッセージのそれぞれ異なるグループについてこうしたセッションを同時に作成することができる。したがって、相関メッセージの関連のないグループの分離を確実にするために、送信側と受信側の両方のコンピュータシステム上で様々な手順が実施され得る。

図２は、複数のメッセージが指定されたアプリケーションによって意図されるように処理され得るように、複数の相関メッセージをリソース効率のよいやり方で通信する方法の一連の行為を示している。図２の諸行為について図１を参照して以下で論じ、またそれは、送信側と受信側の両方のコンピュータシステムの観点からの行為を含む。たとえば、図２は、送信側コンピュータの観点１００からの本発明の実施による方法が、相関メッセージのグループを作成する行為２００を備えることを示している。行為２００は、受信側コンピュータシステム上で処理される相関メッセージのグループを作成することを含み、該グループ内のあるメッセージは第１のメッセージであり、該グループ内の別のメッセージは最後のメッセージである。たとえば、送信側のコンピュータシステム１００は、個別の通信セッション用に構成される場合は、それぞれが一意のセッションＩＤを含む相関メッセージのグループを作成し得る。あるいは、送信側コンピュータシステム１００は、複数のセッション用に構成されない場合は、少なくとも１つのメッセージがグループ内の第１のメッセージとして識別可能であり、また別のメッセージがグループ内の最後のメッセージとして識別可能であるように他の機構によってメッセージを相関させることができる。

送信側コンピュータ１００の観点からの方法もまた、セッションを作成する行為２１０を含む。行為２１０は、メッセージグループのためのセッション指向通信チャネルを作成することを含む。たとえば、送信側コンピュータシステム１００は、キューマネージャ１３０によって維持される１つまたは複数の状態層を有するセッション指向通信チャネルを開始する。キューマネージャ１３０は開始された通信チャネル１２０についてのセッション情報をアプリケーション１０３に渡し、アプリケーションライタ１０５は、グループの各相関メッセージ内にセッションＩＤを挿入する。アプリケーションライタ１０５は、セッションが順序付けられたセッションであること、または処理にとって順序付けが重要でないこと、またはメッセージグループが単一の処理ノードによって任意の順序で処理されることを示すヘッダ情報を挿入することもできる。順序付けられたセッションの場合のいくつかの例では、ライタインターフェース１０５は、メッセージが順序付けられ処理されるべき特定の順序を示す（「３の１」などの）順序標識を各メッセージ内に挿入することもできる。これらのおよび類似の挿入機能が代わりに、または共有されるやり方で、アプリケーション１０３および／またはキューマネージャ１３０によって実施され得る。

送信側コンピュータ１００の観点からの方法は、グループを送信する行為２２０をも備える。行為２２０は、受信側コンピュータシステム上のアドレス指定可能なキューにメッセージグループを送信することを含む。たとえば複数のメッセージのうちの少なくとも１つが準備された後に、送信側コンピュータシステム１００は、グループの相関メッセージ１１０、１１３および１１５をキューマネージャ１４０上のアドレス指定されたキュー１２３に送信する。メッセージは、受信側コンピュータシステム１４０上のその最終宛先に中継されるときに１つまたは複数のストアおよび転送点を介して中継され、このストアおよび転送点で、メッセージは１つまたは複数の目的のためにバッファに入れられる。上記で示したように、送信側コンピュータシステム１００は、相関メッセージのうちの１つが失敗し、または適切に送信されていないことの表示を受信する場合には、単純にメッセージを適切なセッションＩＤに再び関連付け、そのメッセージを再送し得る。最終的に、複数の各メッセージは、受信側コンピュータシステム１４０上の指定されたセッション指向キュー１２３に中継される。

さらに、図２は、送信側コンピュータ１００の観点からの方法が、異なるセッションを作成する行為２３０をさらに備えることを示している。行為２３０は、相関メッセージの異なるグループについて異なるセッション指向通信チャネルを作成することを含む。たとえば１組のメッセージと同時に、あるいはメッセージグループの最後のメッセージ１１５が適切に作成されまたは送信された後に、アプリケーション１０３は、相関する１つまたは複数のメッセージ（図示せず）の新しい異なるグループのための新しい通信セッション（図示せず）を開始する。もちろん、送信されるさらなるメッセージがない場合、新しいセッションは必ずしも作成される必要はない。しかし、アプリケーションは、異なるグループがそれぞれ異なるセッション識別子を有するように、相関を取るやり方で処理される相関メッセージの各セットが確実に１つの個別のセッション識別子にだけ関連付けられるようにする。

図示するように図２は、複数のメッセージが意図されるように処理され得るように、相関メッセージのグループをリソース効率のよりやり方で処理する、受信側コンピュータ１５０の観点からの方法をも示している。具体的には図２は、受信側からの方法が、１つまたは複数のメッセージを受信する行為２４０を備えることを示している。行為２４０は、キューで１つまたは複数のメッセージを受信すること含み、該メッセージの少なくとも１つは相関メッセージのグループの第１のメッセージとして識別可能である。たとえば受信側コンピュータシステム１５０が、通信セッションを理解するように構成された送信側コンピュータシステムからメッセージグループを受信している場合、受信側コンピュータシステムは、メッセージヘッダ内に含まれるセッション情報を識別することによって相関グループを容易に識別する。あるいは、送信側コンピュータシステム１００が通信セッションを実施するようには構成されていないが、メッセージグループ化に対処するようには構成されている場合、受信側コンピュータシステム１５０は、受信されるメッセージのグループ内の最初のメッセージおよび最後のメッセージの標識を識別するなど、他の表示で相関グループ化を識別する。

受信側コンピュータ１５０の観点からの図２の方法は、セッションを作成する行為２５０をも備える。行為２５０は、メッセージグループのためのセッション指向通信チャネルを作成することを含む。受信側コンピュータシステム１５０上のリスナモジュール１４５は、キュー１２３からアプリケーション１６０にメッセージを渡すために使用されるセッション指向通信チャネル１２１を開始する。順序付けられたセッションの場合にキューマネージャ１４０でメッセージが適切に順序付けられるときに、受信されたメッセージ１１０、１１３および１１５をアプリケーション１６０に渡すためセッション指向チャネル１２１が使用される。適切な場合にこれは、アプリケーション１７０が相関メッセージのグループを部分的に処理し得るように、メッセージが受信されるときに行われ得る。あるいは、たとえば順序付けられていないセッションの場合には、すべてのメッセージが受信されると、かつ／またはそのメッセージグループに関連しない相関メッセージの新しいグループのために新しいセッション指向チャネルが開始されるとすぐに、メッセージはセッション指向チャネルを介してアプリケーション１６０に渡され得る。

したがって、受信側コンピュータ１５０の観点からの図２の方法は、グループの最後のメッセージを受信する行為２６０をも備える。行為２６０は、メッセージグループの最後のメッセージを受信することを含む。たとえば、メッセージ１１０は、そのメッセージが３つのメッセージのシーケンス内の第１のメッセージとして処理されることの順序識別子を含み得る。あるいは別の実装では、複数のメッセージ内の各メッセージと共に含まれる別個のメッセージ（図示せず）が、メッセージセッションのインデックスとして働き、またセッション内のメッセージの数、およびそのそれぞれの順序、ならびにそれがどのように処理されるべきかを示す。いずれの場合にも、最後のメッセージは、そのセッション指向チャネルを介して送信されるさらなるメッセージが存在せず、セッションに関連する他のすべてのメッセージが受信されたと見なすことを受信側コンピュータシステム１５０に示す。

受信側コンピュータの観点からの図２の方法はさらに、異なるセッションを作成する行為２７０を備える。行為２７０は、相関メッセージの異なるグループの第１のメッセージを受信すると、異なる後続のセッション指向通信チャネルを作成することを含む。たとえばある実装では、リスナモジュール１４５は、最後のメッセージを識別するまで、あるいはセッション内のすべてのメッセージが受信され、セッション指向チャネル１２１を介してアプリケーション１６０に渡されたことを識別するときまで、セッション指向チャネルを使用可能な状態に保つ。すなわち、リスナモジュール１４５は、たとえば各メッセージ１１０、１１３、１１５が受信されるまで、またはたとえば「３の１」、「３の２」および「３の３」などが受信されるまでセッション指向チャネルを開いたまま保つ。

メッセージグループに関連しない新しいメッセージを受信すると、リスナ１４５は、メッセージの新しいグループ化のための異なる通信セッションを開始し得る。これは、受信側コンピュータシステムが相関メッセージのグループを個別のセッションに配列しまたは編成することを可能にする。これはさらに、受信側コンピュータシステム１５０および送信側コンピュータシステム１００が、確実にメッセージがグループとして、かつ／または適切な場合には指定された順序で処理されるようにすることを可能にする。したがって、別のセッションまたはグループ分けの一部として送信される相関メッセージ（図示せず）の異なるグループが、不注意に相関メッセージの別のグループと共に処理されない。

したがって、本発明の実施は、グループ内の各メッセージがいずれかの意味のあるやり方でアンパックされ、読み出されることを必要とせずにメッセージグループが定められたやり方で送信され処理されることができる複数のやり方を提供する。さらに、本発明の実施は、相関メッセージが送信側コンピュータシステムによって指定された順序で（またはそれ無しで）、また単一の処理ノードで処理され得るように、（順序付けられまたは順序付けられない）特定の通信セッション内のメッセージがキューに入るように送信されることを可能にする。さらに、セッション内のメッセージがセッション識別子に関連付けられ得るので、本発明の実施は、アプリケーションの障害時の送信を提供する。たとえば本発明の実施は、送信側または受信側コンピュータシステムが重複する前のデータを送信しまたは受信することを必要とせずに、送信側および受信側のキューマネージャが送信の様々なシーケンスで送信を停止し、開始し、かつ／または回復されたセッション識別子との関連付けを再開することを可能にする。

さらに、メッセージが、特定のキューおよびセッション指向チャネルに向けられる特定の通信セッションにグループ分けされ得るので、本発明の実施は、メッセージが相関メッセージの他のグループと混合されるのではなく、適切にグループ分けされることを提供する。ある場合では、これは、受信側コンピュータシステム上でメッセージがソートされ、グループから取り除かれることを必要としないのでリソース効率をもたらす。さらに、具体的にはＳＯＡＰメッセージなどのメッセージでは、各セッションがメッセージヘッダ内の特定のキューに向けられ得るので、個別の通信セッションチャネルを介して送信されるメッセージは、アドレス指定されたキューまたはアプリケーションに届くまで、たとえばアドレス指定のために非直列化されまたは復号される必要はない。

図３および以下の議論は、本発明が実施され得る適切なコンピューティング環境についての簡潔で一般的な説明を提供するためのものである。必須ではないが、本発明について、ネットワーク環境内でコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で述べる。プログラムモジュールは一般に、特定のタスクを実施し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などを含む。データ構造体およびプログラムモジュールに関連するコンピュータ実行可能命令は、本明細書で開示する諸方法のステップを実行するためのプログラムコード手段の例を表す。こうした実行可能命令または関連のデータ構造体の特定のシーケンスは、こうしたステップ中で述べる機能を実施するための対応する行為の例を表す。

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

図３を参照すると、本発明を実施するための例示的なシステムが、処理装置３２１と、システムメモリ３２２と、システムメモリ３２２を含めて様々なシステム構成要素を処理装置３２１に結合するシステムバス３２３とを含む従来型コンピュータ３２０の形の汎用コンピューティング装置を含んでいる。システムバス３２３は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを用いたローカルバスを含めて、複数タイプのバス構造のいずれかであり得る。システムメモリは、読出し専用メモリ（ＲＯＭ：ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）３２４と、ランダムアクセスメモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）３２５とを含む、起動時などにコンピュータ３２０内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム（ＢＩＯＳ：ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）３２６は、ＲＯＭ３２４に格納され得る。

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

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

コンピュータ３２０は、リモートコンピュータ３４９ａおよび３４９ｂなどの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境内で動作することができる。リモートコンピュータ３４９ａおよび３４９ｂはそれぞれ、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、また図３にはメモリ記憶装置３５０ａおよび３５０ｂ、ならびにその関連のアプリケーションプログラム３３６ａおよび３３６ｂだけが示されているが、コンピュータ３２０に関して上記で述べた要素の多くまたはすべてを一般に含む。図３に示す論理接続は、限定のためではなく例を挙げるために本明細書で提示されているローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）３５１と、広域ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）３５２とを含む。こうしたネットワーキング環境は、オフィス規模または企業規模のコンピュータネットワーク、イントラネットおよびインターネットでは一般的である。

ＬＡＮネットワーキング環境内で使用される場合、コンピュータ３２０は、ネットワークインターフェースまたはアダプタ３５３を介してローカルネットワーク３５１に接続される。ＷＡＮネットワーキング環境内で使用される場合、コンピュータ３２０は、モデム３５４、無線リンク、またはインターネットなどの広域ネットワーク３５２を介して通信を確立する他の手段を含み得る。内部にあっても、外部にあってもよいモデム３５４は、シリアルポートインターフェース３４６を介してシステムバス３２３に接続され得る。ネットワーク環境内では、コンピュータ３２０に関して示したプログラムモジュール、またはその一部は、リモートメモリ記憶装置内に格納され得る。図示するネットワーク接続は例示的なものであり、広域ネットワーク３５２を介して通信を確立する他の手段が使用され得ることが理解されよう。

本発明は、その精神または本質的な特性から逸脱せずに他の特定の形で実施され得る。説明した諸実施形態は、すべての点において、限定的ではなく、例示的なものにすぎないと見なすべきである。したがって、本発明の範囲は、上記の説明ではなく、添付の特許請求の範囲によって示される。特許請求の範囲の等価物の意味および範囲内に含まれるすべての変更は、その範囲内に包含される。

相関メッセージを受信側コンピュータシステムに送受信するための本発明による概要概略図である。 本発明に従って相関メッセージを通信する行為を備える、送信側および受信側コンピュータシステムの観点からの方法を示す図である。 本発明の１つまたは複数の実施を行うのに適したコンピューティング環境の概略図である。

符号の説明

１００ 送信側コンピュータシステム
１０３ アプリケーション
１０５ ライタ
１１０ メッセージ
１１７ セッション
１２０ チャネル
１２１ チャネル
１２３ キュー：アドレス
１２５ キュー：アドレス
１２７ チャネル
１３０ キューマネージャ
１４０ キューマネージャ
１４５ リスナ
１４７ リスナ
１５０ 受信側コンピュータシステム
１６０ アプリケーション
１７０ アプリケーション

Claims (20)

1. 送信側システム上のアプリケーションが、受信側コンピュータシステム上で処理される相関メッセージのグループを送信するコンピュータ化された環境内の送信側コンピュータシステム上で、前記相関メッセージが意図されるように処理され得るように前記複数のメッセージをリソース効率のよいやり方で通信する方法であって、
   受信側コンピュータシステム上で処理される相関メッセージのグループを作成する行為であって、前記グループ内の１つのメッセージは第１のメッセージであり、前記グループ内の別のメッセージは最後のメッセージである行為と、
   前記メッセージグループのためのセッション指向通信チャネルを作成する行為と、
   前記メッセージグループを受信側コンピュータシステム上のアドレス指定可能なキューに送信する行為と、
   相関メッセージの異なるグループのための異なるセッション指向通信チャネルを作成する行為と
   を備えることを特徴とする方法。
2. 前記セッション指向通信チャネルを介して前記メッセージグループを送信し、前記異なるセッション指向通信チャネルを介して前記異なる相関メッセージグループを送信する行為をさらに備えることを特徴とする請求項１に記載の方法。
3. キューマネージャは、前記相関メッセージグループが前記セッションに関連付けられる、前記セッション指向通信チャネルの状態を維持することを特徴とする請求項２に記載の方法。
4. 前記グループ内のメッセージのうちの少なくとも１つが前記受信側コンピュータシステムに適切に送信されたことの表示を受信する行為と、
   前記メッセージが前記相関メッセージグループの一部であることを示すための対応するセッション識別子を含む前記メッセージを再送する行為と
   をさらに備えることを特徴とする請求項１に記載の方法。
5. 前記グループ内の各メッセージはセッション識別子に関連付けられ、前記異なるグループの各メッセージは異なるセッション識別子に関連付けられることを特徴とする請求項１に記載の方法。
6. 前記送信側コンピュータシステム上の前記アプリケーションに障害が生じる場合に、
   前記アプリケーションが再開すると新しいセッション指向通信チャネルを開始する行為と、
   前記新しいセッション指向チャネルが、前記アプリケーションに障害が生じる前に前記アプリケーションで使用されていた前記セッション識別子に関連付けられるように、また前記アプリケーションが前のセッションに再接続されるように、前記セッション指向通信チャネルに関連する前記セッション識別子を回復する行為と
   をさらに備えることを特徴とする請求項５に記載の方法。
7. カプセル化された前記メッセージグループまたは異なるメッセージグループがトンネリングプロトコルを介して中継されるように、前記メッセージグループまたは異なるメッセージグループのいずれかをカプセル化する行為をさらに備えることを特徴とする請求項１に記載の方法。
8. ルータは、前記相関メッセージグループ内のメッセージのうちの少なくとも１つと、前記相関メッセージグループ内のメッセージのうちの少なくとも第２のメッセージと、前記相関メッセージグループの一部でない別のメッセージとを中継し、前記ルータは、前記少なくとも１つのメッセージと前記少なくとも第２のメッセージとが共通の通信セッションに関連すること、および前記別のメッセージが前記共通の通信セッションに関連しないことを識別することを特徴とする請求項１に記載の方法。
9. 少なくとも前記相関メッセージグループは、ＳＯＡＰメッセージングプロトコルを使用して前記受信側コンピュータシステムに送信され、前記グループ内の各メッセージのメッセージヘッダ内に１つまたは複数の経由情報(via)を挿入する行為をさらに備えることを特徴とする請求項１に記載の方法。
10. 前記セッション指向チャネルは順序付けられたセッションのために作成され、前記相関メッセージグループ内の各メッセージ内に順序識別子を挿入する行為をさらに備えることを特徴とする請求項１に記載の方法。
11. 受信される複数のメッセージの相関が取られるコンピュータ化された環境内の受信側コンピュータシステム上で、前記複数の相関メッセージが意図されるように処理され得るように前記複数のメッセージをリソース効率のよいやり方で受信し処理する方法であって、
    キューで１つまたは複数のメッセージを受信する行為であって、前記１つまたは複数のメッセージのうちの少なくとも１つは相関メッセージグループの第１のメッセージとして識別可能である行為と、
    前記相関メッセージグループのためのセッション指向通信チャネルを作成する行為と、
    前記相関メッセージグループの最後メッセージを受信する行為と、
    異なる相関メッセージグループの第１のメッセージを受信すると、異なるセッション指向通信チャネルを作成する行為とを備えることを特徴とする方法。
12. 前記相関メッセージグループのメッセージは、前記受信側コンピュータシステムが前記相関メッセージグループ内のいずれかのメッセージ内で通信セッション識別子を識別することに基づいて前記セッション指向通信チャネルを開始するように、前記通信セッション識別子を備えることを特徴とする請求項１１に記載の方法。
13. 前記異なるグループの前記第１メッセージ内の新しい異なる通信セッション識別子を識別する行為と、
    前記新しい通信セッション識別子に基づいて前記異なるセッション指向通信チャネルを開始する行為と
    をさらに備えることを特徴とする請求項１２に記載の方法。
14. 前記相関メッセージグループの少なくとも前記第１メッセージを、前記セッション指向通信チャネルを介して特定のアプリケーションに渡す行為と、
    前記グループの前記相関メッセージが部分的に処理されるように、前記相関メッセージグループの前記最後のメッセージを受信する前に前記特定のアプリケーション上で前記相関メッセージグループの少なくとも前記第１メッセージを処理する行為と
    をさらに備えることを特徴とする請求項１１に記載の方法。
15. 前記セッション指向通信チャネルは順序付けられたセッションのために作成され、
    前記グループの各メッセージ内で順序識別子を識別する行為と、
    前記順序識別子に従って前記特定のアプリケーション上で前記グループのメッセージを処理する行為と
    をさらに備えることを特徴とする請求項１１に記載の方法。
16. 前記受信側コンピュータシステム上の前記アプリケーションに障害が生じる場合に、
    前記アプリケーションが再開すると新しいセッション指向通信チャネルを開始する行為と、
    前記新しいセッション指向チャネルが、前記アプリケーションに障害が生じる前に前記アプリケーションで使用されていた前記セッション識別子に関連付けられ、また前記アプリケーションが前のセッションに再接続されるように、前記セッション指向通信チャネルに関連する前記セッション識別子を回復する行為と
    をさらに備えることを特徴とする請求項１１に記載の方法。
17. 前記相関メッセージグループ内のメッセージのうちの１つの送信が失敗したことの表示を受信する行為と、
    受信された前記相関メッセージグループの他のメッセージをバッファに入れる行為と、
    新しいメッセージを受信する行為と、
    前記新しいメッセージ内のセッション識別子に基づいて、前記新しいメッセージが前記相関メッセージグループの一部であることを識別する行為と
    をさらに備えることを特徴とする請求項１１に記載の方法。
18. 前記セッション指向チャネルは、前記特定のアプリケーションに関連するリスナモジュールによって開始されることを特徴とする請求項１１に記載の方法。
19. 前記メッセージグループは受信側コンピュータシステムの宛先キューで受信され維持され、前記キューは送信側コンピュータシステムによって具体的にアドレス指定されることを特徴とする請求項１１に記載の方法。
20. 受信される複数のメッセージが特定のアプリケーションによって処理される受信側コンピュータシステム上で使用するためのコンピュータプログラム製品であって、プロセッサによって実行されるときに前記受信側コンピュータシステムに
    キューで１つまたは複数のメッセージを受信する行為であって、前記１つまたは複数のメッセージのうちの少なくとも１つは相関メッセージグループの第１のメッセージとして識別可能である行為と、
    前記相関メッセージグループのためのセッション指向通信チャネルを作成する行為と、
    前記相関メッセージグループの最後メッセージを受信する行為と、
    異なる相関メッセージグループの第１のメッセージを受信すると、異なるセッション指向通信チャネルを作成する行為とを備える、前記複数の相関メッセージをリソース効率のよいやり方で意図されるように受信し処理する方法を実施させるコンピュータ実行可能命令がそれ上に格納された１つまたは複数のコンピュータ読取り可能媒体を備えることを特徴とするコンピュータプログラム製品。
    

Images