JP2006216024A - 交換フォーマットメッセージの効率的な変換 - Google Patents

Abstract

【課題】交換フォーマットメッセージに効率的な変換を提供すること。
【解決手段】コンピュータ化されたシステムにおいて、送信側コンピュータシステムと受信側コンピュータシステムが、リソース効率の良いやり方で交換フォーマットメッセージを交換する。例えば、送信側コンピュータシステムにおける変換ライタは、メッセージの複数のユニットのうち１つまたは少数だけを一度に選択し変換する。変換されたメッセージユニットは、次いで、例えばＸＭＬメッセージの場合には正規化基準などの、該当する変換基準に従って、受信側コンピュータシステムにストリームされる。受信側コンピュータシステムにおける変換リーダは、受け取られたメッセージユニットに対して充分に大きなバッファを使用してメッセージを変換し、変換したユニットをファイルに渡す。したがって、変換ライタは、メッセージを渡すためのストリームライタの役割をし、変換リーダは、受信側コンピュータシステムにおけるストリームリーダの役割をする。
【選択図】図１

Description

本発明は、送信側と受信側の間で効率的にＸＭＬメッセージなどの交換ファイルフォーマットメッセージを変換するためのシステム、方法、およびコンピュータプログラム製品に関する。

ＸＭＬなどの交換ファイルフォーマットは、様々なコンピューティングプラットフォームにわたってデータの閲覧または表示をすることができるオプションも理由となって、ますます普及しつつある。いくつかの異なるタイプの交換フォーマットファイルがあり、それらの一部は、画像データに適合し、他のいくつかは音に適合し、さらに他のいくつかは一般のテキストに適合している。いずれにしても、交換データフォーマットは、複雑さの低いインスタントメッセージ交換から、複雑さの高いセキュアな電子商取引交換まで及ぶ、幅広いデータ交換に共通して使用される。

一般に、交換データフォーマットは、適切なリーダを用いて任意のコンピューティングプラットフォームによって仮想的に読み取ることができる、ＸＭＬにおける名前空間コードなど一連の要素およびコードを含む。例えば、交換フォーマットで表されるファイルは、そのファイルが交換フォーマットファイルであることを示す１つまたは複数の要素、ならびに、メッセージのファイルのタイプ（すなわち、テキスト、オーディオ、ビデオなど）を示す識別子を含むことができる。交換フォーマットのタイプは、与えられたメッセージに関連するいくつかの可視プロパティおよび隠しプロパティを示すファイル内の特定のコードを指定することもできる。例えば、ドキュメントに関連する可視プロパティは、いくつかのタイプのテキストがどのように表示されるかについての、例えば、色、フォントサイズ、および配列などに関係することがある情報を含むことができる。一方、隠れプロパティは、ドキュメントを作成したエンティティ、ドキュメントを表示することを目的とするエンティティ、およびセキュリティ情報などを含むことができる。

送信側と受信側の間で期待されるように、送信され受信されて表示されるドキュメントに関して、送信側は、たいてい、該当する交換フォーマットに適切なメッセージ全体を変換する。次いで、受信側が特定の交換フォーマットを読み取る能力があることが想定されるとき、受信側は、ファイルを受け取り次第読み取る。ＸＭＬなどの交換フォーマットとともにしばしば使用される１つのタイプの変換方法は、「正規化（ｃａｎｏｎｉｃａｌｉｚａｔｉｏｎ）」と呼ばれ、重要でない差異を除去または最小限にするために、メッセージまたはメッセージユニットが正規形に縮減されるように変換する。例えば、ＸＭＬメッセージユニットの事例では、正規化規則は、レンダリングのための名前空間選択、改行正規化（ｌｉｎｅｆｅｅｄ ｎｏｒｍａｌｉｚａｔｉｏｎ）、文字変換、および内部コマンドの範囲などに対する特有の規則を含む。

遺憾なことに、いくつかの通信モードは、不意に介在する変更に対して他のモードより敏感であり、その結果、所期の受信者が、メッセージを適切に見ることに失敗する、あるいは第１のインスタンスでメッセージを受け取ることになる。例えば、高度なセキュリティの実装において、少量の変動で変換されるまたは一方の終端で一致しないデータは、所期の受信者によって適切に見るまたは受け取ることができず、あるいは第１のインスタンスで変換することさえできない。同様に、送信側で適切に変換することができない高度なセキュリティデータは、許容される方法で発生しうる移行中のデータの変更のため、やはり受信側で適切に受け取ることができない。

したがって、正確で一貫した変換方法は、交換フォーマットデータ転送、特にセキュア通信などの敏感な分野でますます重要となる。遺憾なことに、少なくとも部分的には、メッセージを適切に変換するために必要な措置に起因して、変換方法は、コンピュータ制御システムの処理の費用のかかる側面を構成しうる。

例えば、メッセージが送られる前にメッセージを変換しようとするときに、メッセージ全体のサイズに比例したサイズでバッファが作成される。次いで、メッセージ全体の表現が、バッファにロードされ、そのメッセージ表現のためのリーダおよびライタが作成される。ＸＭＬメッセージの事例では、メッセージ表現は、ドキュメントオブジェクトモデル（「ＤＯＭ」）コンポーネントにロードすることもでき、このコンポーネントは、メッセージの各要素をバッファ内に読み取り、続いて、単一の変換された出力としてメッセージを書き出す。いずれにしても、次いで、変換された出力は、受信側に送られる。

この手法に関する少なくとも１つの問題は、メッセージ全体を読み取るために充分な大きさのバッファ、および、変換されたメッセージ全体を受け取るために充分な大きさのバッファを作成する必要があることである。いくつかの事例では、メッセージが受信側に送られる前に、あるいは、メッセージが受け取られた後に受信側のコンピュータシステムにおいて、１つまたは複数のバッファが、メッセージ全体の変換されたバージョンと非変換のバージョンの両方に割り当てられる。特に、より大きいギガバイトの規模に及びうるメッセージについては、このようなバッファの割当ては、多数の要求を取り扱うコンピュータ化されたシステムの処理およびメモリリソースに大きな負担をかけるおそれがある。送信側コンピュータシステムは、通常、その書出し可能な速度よりかなり遅く読取りをするが、送信プロセスのために読取りおよび書込み機能の両方を実装するため、いくつかの事例では、上記および他の同様の問題は、さらに悪化する。

同様の複雑な問題を有する逆のプロセスが、受信側で行われる。具体的には、受信側コンピュータシステムは、送信側から一度に小さなかたまりのメッセージしか受け取らなくても、一般に、メッセージ全体に対して充分に大きなバッファを割り当てる必要がある。いくつかの事例では、受信側コンピュータシステムは、重複したバッファスペースを割り当てることもあり、したがって、受け取るメッセージ全体について変換されたバージョンと変換されないバージョンに対するバッファが存在する。さらに、受信コンピュータシステムは、メッセージの要素の読取りおよび書出しに加え、変換されたメッセージをバッファ内にロードする追加のリソースを消費する必要がある。受信側コンピュータシステムでは、送信側コンピュータシステムと同様だが逆の問題があり、一般に、読取りよりもかなり低速で書出しが行われる。したがって、いくつかの大きなバッファの割当てと、送信側と受信側の両方のコンピュータシステムについての読取と書出しの両方の処理機能の作成は、処理リソースおよびメモリリソースに対するかなりの負担を意味する。

したがって、送信および受信側の両方で交換フォーマットデータの効率的変換を提供するシステム、方法、およびコンピュータプログラム製品によって、当技術分野における利点を実現することができる。特に、それぞれのメッセージ全体をメモリに読み込むことなくデータを変換する方法は、当技術分野における利点となる。さらに、送信側コンピュータシステムまたは受信側コンピュータシステムの相対的強みを利用する、データ変換方法が、当技術分野における利点となる。

本発明は、上記の従来技術における問題の１つまたは複数を、交換フォーマットメッセージを効率的に変換するように構成されたシステム、方法、およびコンピュータプログラム製品によって解決する。特に、本発明の実装形態は、一態様では、メッセージ全体を変換し送信する前に、割り当てられたバッファにメッセージ全体を読み込むのではなく、交換メッセージユニット（例えば、正規化されたメッセージユニット）を、データストリームの離散コンポーネントに変換することに関する。

例えば、本発明の一実装形態による、送信側コンピュータの側からのメッセージを変換する方法は、複数の異なるメッセージユニットを含む交換フォーマットメッセージにアクセスすることを含む。一実装形態では、送信側コンピュータシステムにおける変換ライタが、１つまたは複数のメッセージユニットの初期セットをメッセージから選択し、変換基準に基づいて初期セットを変換する。次いで、変換ライタは、そのメッセージから１つまたは複数のユニットの次の異なるセットを選択し、基準に基づいて次のセットを変換する。それらのユニットが選択され処理されるとき、変換されたメッセージユニット（および、適切な場合は対応するダイジェスト）もまた、出力のためにユニットの変換されたセットを渡す。このように、交換メッセージは、一度に単一または少数のユニットごとに変換され、その結果、少なくともバッファの割当てならびに他のシステムリソースを、大幅に節約することができる。さらに、送信側コンピュータシステムは、交換フォーマットデータの書出しを主にするように構成され、それが、送信側コンピュータシステムの機能的利点の役割をする。

受信側コンピュータから見て、受信され変換されたメッセージユニットを変換する方法は、メッセージの１つまたは複数の変換されたユニットの初期セットをメモリに受け取ることを含む。ユニットの初期セットは、メッセージ内のすべてのユニットより少数のユニットであり、したがって、割り当てられたメモリは、メッセージ全体あるいは該当する場合はメッセージ全体とそれに伴うダイジェストを受け取るのではなく、単にユニットの初期セットを受け取るために充分な大きさがあればよい。次いで、受信側コンピュータシステムは、受け取った変換されたユニットの初期セットを、適切な変換基準に基づいて変換し、交換フォーマットメッセージの対応する初期部分をファイルに渡す。次いで、受信コンピュータシステムは、交換フォーマットメッセージの１つまたは複数の変換されたユニットの後続のセットをメモリ内に受け取り、この後続セットを変換し、それをファイルに渡す。したがって、受信側コンピュータシステムは、受信側コンピュータシステムの機能的利点の役割をする交換フォーマットデータの読取りを主に行うように構成される。

本発明の例示的実装形態のさらなる特徴および利点は、以下の説明に示され、部分的にはその説明から明瞭となり、あるいは、その例示的実装形態を実施することによって理解されうる。このような実施形態の特徴および利点は、添付の特許請求の範囲で詳細に示される手段および組合せによって理解し獲得することができる。上記および他の特徴は、以下の説明および添付の特許請求の範囲から、より完全に明らかにされ、あるいは、以下に示す例示的実装形態の実施によって理解されうる。

本発明の上記および他の利点を得ることができる方法を説明するために、添付の図面に示される本発明の特定の実施形態を参照することにより、上記で簡潔に説明した本発明のより詳細な説明を与える。これらの図面は、本発明の一般的な実施形態のみを示し、したがって本発明の範囲を限定するとは見なされないという理解のもとで、添付の図面を使用して、本発明は追加の特性および詳細とともに記述し説明される。

本発明は、交換フォーマットメッセージを効率的に変換するように構成されたシステム、方法、およびコンピュータプログラム製品に及ぶ。特に、本発明の実装形態は、一態様では、割り当てられたバッファにメッセージ全体を読み込むのではなく、交換メッセージユニット（例えば、正規化されたメッセージユニット）を、データストリームの離散コンポーネントに変換することに関する。

本明細書および特許請求の範囲から理解されるように、本発明の一態様は、１つまたは複数のメッセージユニットを対応するシステムに変換するなどのように、一度にメッセージの数ビットのみをストリームに変換することを含む。一般に、要約が、変換プロセスと結合され、したがって、メッセージの選択されたユニットごとに再使用することができるとき、種々の変換コンポーネントに対して、メッセージ全体のサイズと独立して比較的小さいバッファのみが変換ライタによって割り振られることが必要となりうる。次いで、各メッセージユニットは、単純に、変換され、ストリームアキュムレータ（ｓｔｒｅａｍ ａｃｃｕｍｕｌａｔｏｒ）などに渡され直接出力される。

本発明の他の態様では、変換されたメッセージユニットは、変換された後すぐに受信側に送られ、事例によっては、変換、要約、および署名がされた後すぐに受信側に送られる。本発明のさらに他の態様では、受信者がストリームされたメッセージユニットを受け取るように構成されていない場合、変換されたユニットを、受信側に送る前に他のバッファにさらに蓄積することができる。したがって、大きなメッセージに対して大きなバッファを必ずしも作成する必要なしに、メッセージを選択し、変換し、受信側に送ることができる様々な方法が存在する。

受信側では、受信側コンピュータシステムが、ストリームとして受信される変換されたユニットを受け取り、次いで、変換されたユニットを処理する。本発明の一態様では、受信側コンピュータシステムは、個々のユニットごとにバッファを使用し、そのバッファは、同じバッファであっても異なるバッファであってもよいが、いずれにしてもメッセージ内のすべてのユニットを保持するために必要なサイズより小さい。本発明の他の態様では、受信側コンピュータシステムは、変換されたユニットを、正規化コンポーネントに直接読み取り、次いで、そのユニットを、ストレージ内のファイルなどのアプリケーションまたはファイルに渡す。本発明のさらに他の態様では、受信側コンピュータシステムは、送信側コンピュータシステムで要約された、変換されたユニットを要約し、それぞれのダイジェストを比較する。

例えば、図１は、１つまたは複数のユニット１１０、１１５、および１２０を有する交換フォーマットメッセージ１０５が、変換され、送信側コンピュータシステム１００から受信側コンピュータシステム１５５に送られる概要のブロック図を示す。一般に、メッセージ１０５は、ＸＭＬ、ＨＴＭＬ、ＧＩＦ、ＷＡＶ、または他のタイプの任意の交換フォーマットを有するが、ここでは、ＸＭＬメッセージをしばしば参照する。少なくとも１つの実装形態では、メッセージ１０５のユニット（１１０、１１５、１２０）は、ＸＭＬやＨＴＭＬドキュメントにおけるようなネストされた要素を一般に意味するものとして理解されたい。このような各ユニットそれぞれはまた、一般に、例えばＸＭＬでは要素型および属性名としてのＵＲＩ参照によって識別される名前の集合を表す１つまたは複数の名前空間を含む。とはいえ、ＸＭＬにおける「名前空間」は、時として他の交換フォーマットに比べて独自の意味を有することがある。しがしながら、他のファイルフォーマットにおける同様のデータ構造に、本明細書に記載の同様の取り扱いを適用できることは理解されよう。

本発明に従って、送信側１００が、メッセージ１０５を受信側１５５に送る場合、送信側１００の変換ライタ１２５は、一度に単一または少数のメッセージユニット（すなわち、ユニットの初期または後続のセット）のみを選択する。一般に、変換ライタ１２５は、アプリケーションに関連付けられたプログラムクラスなどのコンピュータ実行可能命令のセットとして理解されよう。図１に示されるように、例えば、変換ライタ１２５は、メッセージ１０５にアクセスし、一連の間隔で、メッセージユニット１１０を選択し、次いでメッセージユニット１１５を選択し、その次にメッセージユニット１２０を選択し、以下同様に行う。

少なくとも一つの実装形態では、変換ライタ１２５は、メッセージ１０５全体のサイズとは独立しているが、予め定められた量のメッセージ選択に対して充分なサイズのバッファメモリを割り当てる。例えば、変換ライタ１２５が、アクセスされたメッセージから一度に１００バイトを選択することが適切であると決定した場合、バッファは、およそ１００バイトかそれより少し大きければよい。次いで、割り当てられたバッファは、選択されたメッセージユニットごとに再使用することができ、選択された各メッセージユニットは、およそ１００バイトもしくは少なくとも割り当てられたバッファのパラメータサイズの範囲内となり、したがって、割り当てられたバッファに収まる。選択物のサイズについては、処理に使用可能なリソースや接続帯域幅などいくつかのファクタに基づくことが可能である。したがって、変換ライタ１２５は、変換され送信される必要のあるメッセージごとに、処理およびメモリリソースを必ずしも調整する必要なしに、任意の時点で適切なメモリおよび処理リソースを効率的に使用することができる。

与えられたユニット、例えばユニット１１０を選択後、変換ライタ１２５は、メッセージ内のＸＭＬ属性を識別し管理する、属性マネージャ１２３と対話する。変換ライタ１２５はまた、追跡エンジン１３０と対話する。追跡エンジン１３０は、ＸＭＬメッセージの事例ではドキュメントオブジェクトモデル（「ＤＯＭ」）を使用せずに、与えられたユニットごとに名前空間（図示せず）を管理する。一般に、各ユニット１１０、１１５、１２０は、最終的にシステムアキュムレータ１５０内に表現される、１つまたは複数の名前空間を有することになる。ただし、先行のユニットにおける同一の名前空間が、既にレンダリングされている場合があるため、与えられたユニットのすべての名前空間が、直ちに必要とされるわけではなく、あるいは、レンダリングされる必要が生じるわけではない。したがって、追跡エンジン１３０は、レンダリングすべき名前空間、および／または、適切な変換プロトコルにおいてレンダリングされないが使用可能な名前空間を、識別するように構成される。

説明のため、名前空間がレンダリングされるかどうかは、変換プロトコルに応じている。例えば、ＸＭＬ正規化は、通常、「排他的（ｅｘｃｌｕｓｉｖｅ）」と「包含的（ｉｎｃｌｕｓｉｖｅ）」の２つのバージョンを含む。「排他的正規化（ｅｘｃｌｕｓｉｖｅ ｃａｎｏｎｉｃａｌｉｚａｔｉｏｎ）」では、名前空間は、それが直ちに利用され、かつ認識できる先祖のコンテキスト（ａｎｃｅｓｔｒａｌ ｃｏｎｔｅｘｔ）で既にレンダリングされていない場合のみ、レンダリングされる。これは、「包含的プレフィックスリスト（ｉｎｃｌｕｓｉｖｅ ｐｒｅｆｉｘｅｓ ｌｉｓｔ）」によって洗練することができ、このリストにより、名前空間が直ちに使用されない場合でも、既にレンダリングされてはいない場合、名前空間がレンダリングされるようになる。

いずれにしても、選択されたユニット（例えばユニット１１０）は、次いで、正規化コンポーネント１３５に渡され、正規化コンポーネント１３５は、変換基準に基づいてそのユニットを変換する。例えば、変換基準として正規化を用いる場合、正規化コンポーネント１３５は、ｃ１４ｎ正規化基準に従って、ユニット１１０を変換することができる。一般に、変換基準は、特定の交換フォーマットを読み取ることが意図される任意のオペレーティングシステムによって読み取ることができるユニバーサルな可読フォーマットで、テキストファイルの文字列や文字などのデータを送る方法を規定する。例えば、正規化基準は、「ｆｏｏ」などの文字列がそのままで渡され、「＜」などの文字が「＆ｌｔ；」として出力で表現されうることを指示することができる。

セキュア交換メッセージについて、送信ライタ１２５は、１つまたは複数のユニットを選択するステップと、選択された各ユニットの所期の送信および受信が効果的に行われることが保証されるように１つまたは複数のユニットを変換するステップとを追加して実行することができる。例えば、メッセージ１０５が、セキュアメッセージの場合、メッセージ内の１つまたは複数の部分またはユニットにおいてメッセージヘッダなどに識別子を有するが、残りの他の各ユニットにおいては必ずしも識別子を有していない。通常、メッセージ１０５の少数の部分に識別子を有するだけで、従来の変換プロトコルを使用する場合には充分である。

しかし、本発明の実装形態では、別個に各ユニットを受信者に渡すことを伴うため、変換ライタ１２５は、セキュアメッセージのすべてのユニットがそれぞれ関連する識別子を有するようにデジタルで署名されることを保証する必要がありうる。したがって、変換ライタ１２５は、セキュアメッセージの、メッセージヘッダを表すユニットなど個々のユニットをスキャンして、各ユニットが識別子を有するかどうかを検出することができる。ユニットが、セキュアメッセージの一部分であるが関連する識別子を含まない場合、変換ライタ１２５は、識別子をそのユニット内に挿入することができる。少なくとも１つの実装形態において、変換ライタ１２５は、識別子をスキャンするステップと、識別子を挿入するステップと、ユニットの単一パスにおいてユニットを変換するステップとを実行する。

変換されたメッセージユニットは、次いで、例えば、受信側コンピュータシステム１５５との接続によって開始したストリームソケットに直接送信され、ストリームアキュムレータ１５０に直接送信される。他の事例では、特にセキュアメッセージについて、変換されたユニットは、ハッシュアキュムレータ（ｈａｓｈ ａｃｃｕｍｕｌａｔｏｒ）１４５に渡され、ハッシュアキュムレータ１４５は、エラー検出のために、ユニットごとに対応するダイジェスト１５７を作成し、次いで、生のオクテット１５３とそれに対応するダイジェスト１５７を対として出力を渡す。他の事例では、例えば、受信者１５５が、個々のメッセージユニットのストリームを受け取るように構成されていない場合、「メッセージ蓄積（Ａｃｃｕｍｕｌａｔｅ Ｍｅｓｓａｇｅ）」コンポーネント１４０にメッセージをバッファすることもできる。

そのような状況においても、この実装形態では、変換ライタ１２５がメッセージ１０５を最初に選択したとき、同様のサイズにされたバッファは、第１のインスタンスに同様に作成する必要はないため、効率利得を実現することができる。次いで、蓄積されたメッセージを、ストリームアキュムレータ１５０に直接渡すことができ、あるいは、ハッシュアキュムレータ１４５に渡し、それからダイジェストと対でストリームアキュムレータ１５０に渡すことができる。しかし、出力に送られると、その結果の生のオクテット１５３は、受信側コンピュータシステム１５５の入力１６０にストリームされる。一実装形態では、データストリームは、連続した２０バイトのチャンクのデータを含む。

次に、受信側コンピュータシステム１５５を参照すると、データのストリームを、変換リーダ１６５を介してメッセージ１０５の対応する表現に読み込むとき、逆の順序の機能が実行される。変換リーダ１６５は、変換ライタ１２５と同様に、アプリケーションプログラムと関連付けられたプログラムクラスなどの１組のコンピュータ実行可能命令である。受信側コンピュータシステム１５５は、変換されたユニットまたはユニットのセット（例えば、変換されたユニット１１０）を受け取るとき、受信側コンピュータシステムにおける変換リーダ１６５は、バッファ（図示せず）を割り当てるが、そのバッファは、通常、受け取った各変換されたユニットに対して充分なサイズであるが、メッセージ１０５全体に対して充分な大きさのサイズではない。したがって、受信側コンピュータシステム１５５は、割り当てられたバッファを簡単に再使用することができ、したがって、追加の着信メッセージユニットごとに、新しいバッファを必ずしも作成する必要がない。一実装形態では、特に大きなメッセージに関する場合、これにより、かなりのメモリ空間および処理の節約となりうる。

受信側コンピュータシステム１５５の変換リーダ１６５は、処理用の適切な１つまたは複数のコンポーネントまたはモジュールを介して、受信した変換されたユニットを渡すこともできる。例えば、受信側コンピュータシステム１５５は、ダイジェストと関連付けられていないような一般的な変換されたユニットを受け取り、変換リーダ１６５は、入力１６０から変換されたユニットを受け取って正規化コンポーネント１３５に渡す。あるいは、ＸＭＬメッセージなどの事例では、受け取った変換ユニットにダイジェストが含まれるとき、受信側コンピュータシステム１５５の正規化コンポーネント１３５が、受け取ったデータを、受信側コンピュータシステム１５５のハッシュアキュムレータ１４５に渡し、ハッシュアキュムレータ１４５が、変換されたユニット上の他のダイジェスト１７０を計算する。次いで、送信側コンピュータシステム１００から受け取ったダイジェスト１５７が、計算されたダイジェスト１７０と比較される。この２つのダイジェストが一致した場合、受信側コンピュータシステム１５５の正規化コンポーネント１３５は、正規化基準に基づいて、変換されたユニットを変換し、そのユニットが対応するファイルに渡される。

ＸＭＬメッセージの事例では、変換リーダ１６５は、属性マネージャ１２３によって、着信メッセージユニットの属性を管理することもできる。変換リーダ１６５は、さらに、受信側コンピュータシステムの追跡エンジン１３０と同様の名前空間の追跡機能を実行し、名前空間をレンダリングするかそれともレンダリングせずに使用可能かを調べるために、各ユニットの名前空間を比較することができる。次いで、ユニットは、個別に読み取られ、対応する蓄積ファイルに渡され、最終的にはメッセージ１０５を表すことになる。一例では、受信側コンピュータシステム１５５は、システムメモリ内に蓄積ファイルを作成する。このファイルは、複数のユニット（例えば、ユニット１１０、１１５、および１２０など）が受け取られ元の表現に変換されたあとに、それらを蓄積するために充分な大きさのメモリバッファである。しかし、他の事例では、蓄積ファイルは、ハードドライブストレージに位置し、したがって、着信メッセージユニットが受け取られ変換されるとき、それらのユニットのために追加のシステムメモリバッファを作成する必要がない。

図２は、リソース効率の良いやり方でメッセージを交換する方法における、送信側コンピュータシステムの側からの一連の動作を示す。図２の動作は、図１に関連して後で述べる。例えば、図２は、本発明の実装形態による方法が、交換フォーマットメッセージを選択する動作２００を含む。動作２００は、複数の異なるメッセージユニットを含む交換フォーマットメッセージを選択することを含む。例えば、ＸＭＬメッセージ１０５は、複数のユニット１１０、１１５、および１２０を含むことができる。

この方法は、メッセージから１つまたは複数のユニットの初期セットを選択する動作２１０をさらに含む。動作２１０は、複数の異なるメッセージユニットのうちすべてより少ないユニットが選択されるように、メッセージから、１つまたは複数のユニットの初期セットをメモリ内に選択する。例えば、変換ライタ１２５は、メッセージ内の選択可能なすべてのユニットを選択することはできないが、ユニット１１０および／またはユニット１１５などを選択することができ、選択したユニットを、メッセージ１０５のサイズとは独立したサイズの割り当てられたメモリ部分に配置する。セキュアな実装形態などのような他の実装形態では、変換ライタ１２５は、識別子を探してユニット１１０をスキャンし、必要な場合はユニット１１０に識別子を挿入する。したがって、変換ライタ１２５は、特に、受信側コンピュータシステムに送られる非常に大きなメッセージを変換することが必要なとき、メッセージを抽出する際に、さもなければ必要となるよりも非常に小さいメモリ空間だけを使用することによって、コンピュータ化されたシステムに対する要求を軽減することができる。

さらに、図２の方法は、初期セットを変換する動作２２０を含む。動作２００は、初期セットの１つまたは複数のユニットを、基準に基づいて、１つまたは複数の変換されたユニットからなる変換された初期セットに変換することを含む。例えば、ＸＭＬメッセージ１０５の事例では、セット内の各ユニットのレンダリングされたまたは予めレンダリングされた名前空間は、正規化コンポーネント１３５に渡され、正規化コンポーネント１３５は、初期セットの各ユニットを正規化して正規化ユニットにし、ストリームアキュムレータ１５０に渡すことができる。正規化されたユニットはまた、ストリームアキュムレータ１５０に渡す前にハッシュアキュムレータ１４５に渡すことや、ハッシュアキュムレータ１４５に渡す前にメッセージ蓄積コンポーネント１４０に渡すこともでき、あるいは、受信側の必要に応じてストリームアキュムレータ１５０に直接ストリームすることができる。

さらに、図２の方法は、１つまたは複数のユニットからなる後続の異なるセットを選択する動作２３０を含む。動作２３０は、複数の異なるメッセージユニットのうちすべてより少ないユニットが選択されるように、メッセージから、１つまたは複数のユニットの後続セットをメモリ内に選択することを含む。例えば、ユニット１１０および／または１１５の選択（または選択および変換）の後、変換ライタ１２５は、後続の１つの異なるメッセージユニット１２０を選択することができ、これは、もちろん、メッセージ１０５内の複数のユニット（すなわち、１１０、１１５、１２０など）のすべてよりも少ない。

後続の異なるメッセージユニット１２０が、同様の一連の動作によって渡される。特に、図２の方法は、後続の異なるセットを変換する動作２４０を同様に含む。動作２４０は、異なる後続のセットの１つまたは複数のユニットを、１つまたは複数の変換されたユニットからなる変換された後続セットに変換することを含む。例えば、ＸＭＬメッセージ１０５の事例では、後続セットのレンダリングされたまたは予めレンダリングされたユニット１２０の名前空間は、正規化コンポーネント１３５に渡され、正規化コンポーネント１３５は、正規化基準に基づいて後続セットのユニット１２０の１つまたは複数の名前空間を正規化する。変換されたユニットの後続セットは、次いで、ストリームアキュムレータ１５０に直接渡されるか、ハッシュアキュムレータ１４５に渡され次いでストリームアキュムレータ１５０に渡されるか、あるいは、メッセージ蓄積コンポーネント１４０に渡され次いでハッシュアキュムレータ１４５および／またはストリームアキュムレータ１５０に渡される。いくつかの事例では、さらに、後続セットのユニットを処理して、選択された１つまたは複数のユニットの初期セットと使用された、以前に割り当てられたメモリに渡すことも伴う。したがって、図２は、送信側コンピュータシステム１００の変換ライタ１２５などのコンポーネントが、主にストリームライタとして振る舞い、与えられたメッセージ１０５の各要素を読み取るために必ずしもリソースを消費する必要がないことを示している。

図３は、図２の方法の受信側での一連の動作を含む方法を示す。図３の動作は、以下で図１のコンポーネントおよびモジュールに関連して論じられる。特に、受け取られた交換フォーマットメッセージをリソース効率の良いやり方で変換する方法は、変換された初期ユニットを受け取る動作３００を含む。動作３００は、メモリ内への交換フォーマットメッセージの、少なくとも１つの変換された初期ユニットを受け取ることを含み、少なくとも１つの交換された初期ユニットは、メッセージ内の複数の変換されたユニットのうちすべてより少ないユニットである。

例えば、受信側コンピュータシステム１５５は、メッセージ１０５の１つまたは複数の変換されたユニット１１０、１１５を受け取ることができ、それらはやはり、メッセージ１０５全体の複数の変換されたユニット（例えば、１１０、１１５、１２０など）のうちすべてより少ないユニットである。したがって、変換リーダ１６５は、受け取ったユニットの初期セットのサイズに対して充分であるが複数のすべてのユニットに対しては充分でないサイズのメモリのみを割り当てる。例えば、変換された初期ユニットのサイズが約２０バイトの場合、変換リーダ１６５は、変換された初期ユニットを収容するために、約２０バイトまたはそれ以上のメモリを割り当てる。

図３の方法はまた、初期ユニットを変換する動作３１０を含む。動作３１０は、変換された初期ユニットを、基準に基づいて、交換フォーマットメッセージの対応する初期の部分に変換する。例えば、ＸＭＬメッセージの事例では、入力コンポーネント１６０においてオクテットとして受け取った変換されたユニット１１０を、正規化コンポーネント１３５に渡しそしてハッシュアキュムレータ１４５に渡すことができ、ダイジェスト１５７を伴わない場合は正規化コンポーネント１３５のみに渡すことができる。ダイジェスト１５７が生のオクテット１５３とともに受け取られた場合、計算されたダイジェスト１７０と受け取られたダイジェスト１５７を比較することなどによるエラー検出のために、ハッシュアキュムレータ１４５を使用して、受け取られたユニット１５７の計算されたダイジェスト１７０を生成することができる。次いで、正規化コンポーネント１３５は、ｃ１４ｎ正規化基準に基づいて正規化されたユニット１１０を、ＸＭＬメッセージ１０５の一部分に変換することができる。例えば、与えられた要素の文字列「ｆｏｏ」をそのまま渡す一方で、文字「＆ｌｔ；」を文字「＜」に変換することができる。

図３の方法はまた、対応する初期の部分をファイルに渡す動作３２０を含む。動作３２０は、交換フォーマットメッセージの対応する初期の部分をファイルに渡すことを含む。例えば、ユニット１１０が正規化コンポーネント１３５を経由して渡された後、変換リーダ１６５が、ユニット１１０を読み取りファイル内またはアプリケーションに渡す。システムメモリのリソースを節約するために、ファイルをシステムメモリではなくストレージに割り当てられたバッファとすることができる。この時点では、送信側コンピュータシステム１００から、メッセージ１０５の複数の変換されたユニットのうち１つ（または、すべてより少数）のみが受け取られており、変換リーダ１６５によってユニット１１０が送られる先のファイル（例えば、受信側コンピュータシステム１５５におけるメッセージ１０５）は、不完全である。

したがって、図３の方法はまた、変換された後続ユニットを受け取る動作３３０を含む。動作３３０は、交換フォーマットメッセージの少なくとも１つの変換された後続ユニットを受け取る。この少なくとも１つの変換された後続ユニットは、メッセージ内の複数の変換されたユニットのすべてより少数のユニットである。例えば、ユニット１１０を入力１６０における初期のオクテットとして受け取ったあと、受信側コンピュータシステム１５５は、変換されたユニット１１５および／または１２０などを含む後続のオクテットをさらに受け取ることができる。後続のオクテットは、送信側コンピュータシステムにおける元のメッセージ１０５すべてに存在するよりも少数を表しているので、受信側コンピュータシステム１５５は、比較的小さなメモリ部分に後続のオクテットを配置することができる。最終的に、ファイルが、送信側１００からの元のすべてのユニットを含むとき、そのファイルは、受信側コンピュータシステム１５５におけるメッセージ１０５と等しくなり、送信側コンピュータシステム１００におけるメッセージ１０５の実質的な表現となる。

上記の図および方法は、本発明の原理と一貫する任意の様々な方法によって変更されうることは理解されよう。例えば、交換メッセージ１０５は、ＸＭＬやＨＴＭＬ以外の任意の様々な交換フォーマットとすることができ、該当するファイルを変換するための基準は、正規化以外の基準にすることもできる。さらに、上記の方法および図を、変換ライタ１２５が主としてストリームライタとして振る舞い、変換リーダ１６５が主としてストリームリーダとして振舞う限り、セキュアメッセージなどに関係しうるメッセージの様々な単純さまたは複雑さに対応するためにさらに修正することができる。

したがって、送信側コンピュータシステムと受信側コンピュータシステムは、メモリ割当て要件を大幅に軽減すること、相対的な書込みおよび読取り速度の強みを利用すること、および、従来の変換方法の多数を単一のルーチンで達成することによって、かなりの効率性の利得を得ることができる。したがって、本明細書および特許請求の範囲は、コンピューティングリソースに過度の負担をかけることなく、ＸＭＬやＨＴＭＬなどの交換フォーマットメッセージを、送信側システムから受信側システムに渡すための新規の方法、システム、および装置を提供する。

図４および以下の議論では、本発明を実装することができる適切なコンピューティング環境についての簡潔な一般的な説明を与える。必須ではないが、ネットワーク環境におけるコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的コンテキストにおいて本発明を説明する。一般に、プログラムモジュールには、特定のタスクを実行するかまたは特定の抽象データ形を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造などが含まれる。コンピュータ実行可能命令、関連するデータ構造、およびプログラムモジュールは、本明細書に開示の方法のステップを実行するためのプログラムコード手段の例である。このような実行可能命令や関連するデータ構造の特定のシーケンスは、開示の方法のステップとして記述される機能を実装するための対応する動作の例である。

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

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

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

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

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

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

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

本発明の実装形態による、変換された交換フォーマットメッセージの送信および受信の概要を示すブロック図である。 本発明の実装形態による、変換された交換フォーマットメッセージを送信する方法を示す図である。 本発明の実装形態による、変換された交換フォーマットメッセージを受信するための方法を示す図である。 本発明による使用に適した例示的コンピューティング環境を示すブロック図である。

符号の説明

１００ 送信側
１０５ メッセージ
１１０ ユニット
１１５ ユニット
１２０ ユニット
１２３ 属性マネージャ
１２５ 変換ライタ
１３０ 追跡エンジン
１３５ 正規化コンポーネント
１４０ メッセージ蓄積
１４５ ハッシュアキュムレータ
１５０ ストリームアキュムレータ
１５３ 生のオクテット（Ｒａｗ Ｏｃｔｅｔｓ）
１５５ 受信側
１５７ ダイジェスト
１６０ 入力
１６５ 変換リーダ
１７０ 計算されたダイジェスト
２００ 交換ファイルフォーマットメッセージにアクセスする
２１０ メッセージから１つまたは複数のユニットの初期セットを抽出する
２２０ 初期セットを変換する
２３０ １つまたは複数のユニットの後続の異なるセットを抽出する
２４０ 後続の異なるセットを変換する
３００ 変換された初期ユニットを受け取る
３１０ 変換された初期ユニットを変換する
３２０ 対応する初期部分をファイルに渡す
３３０ 変換された後続ユニットを受け取る
４２０ コンピュータ
４２１ 処理装置
４２２ システムメモリ
４２３ システムバス
４２４ （ＲＯＭ）
４２５ （ＲＡＭ）
４２６ ＢＩＯＳ
４２７ 磁気ハードディスクドライブ
４２８ 磁気ディスクドライブ
４２９ リムーバル磁気ディスク
４３０ 光ディスクドライブ
４３１ リムーバル光ディスク
４３２ ハードドライブインターフェース
４３３ 磁気ディスクドライブインターフェース
４３４ 光ドライブインターフェース
４３５ オペレーティングシステム
４３６ アプリケーションプログラム
４３６ａ アプリケーションプログラム
４３６ｂ アプリケーションプログラム
４３７ 他のプログラムモジュール
４３８ プログラムデータ
４３９ 磁気ハードディスク
４４０ キーボード
４４２ ポインティングデバイス
４４６ シリアルポートインターフェース
４４７ モニタ
４４８ ビデオアダプタ
４４９ａ リモートコンピュータ
４４９ｂ リモートコンピュータ
４５０ａ メモリ記憶装置
４５０ｂ メモリ記憶装置
４５１ ＬＡＮ
４５２ ＷＡＮ
４５３ ネットワークインターフェース
４５４ モデム

Claims (20)

1. 送信側コンピュータシステムと受信側コンピュータシステムが交換フォーマットで１つまたは複数のメッセージを交換することができる、コンピュータ化された環境における、送信側コンピュータシステムにおいて、リソース効率の良いやり方で交換フォーマットメッセージを変換する方法であって、
   交換フォーマットメッセージにアクセスする動作であって、前記交換フォーマットメッセージは、複数の異なるメッセージユニットを含む動作と、
   前記複数の異なるメッセージユニットのうちすべてより少ないユニットが選択されるように、前記メッセージから１つまたは複数のメッセージの初期のセットを選択する動作と、
   前記初期セットの前記１つまたは複数の選択されたメッセージユニットを、基準に基づいて、１つまたは複数の変換されたユニットの変換された初期セットに変換する動作と、
   複数の異なるメッセージユニットのうちすべてより少ないユニットが選択されるように、メモリ内の前記メッセージから、１つまたは複数のユニットの後続の異なるセットを選択する動作と、
   前記後続の異なるセットの前記１つまたは複数のユニットを、１つまたは複数の変換されたユニットの変換された後続セットに変換する動作とを備えることを特徴とする方法。
2. １つまたは複数の選択されたメッセージユニットの前記初期および後続のセットは、追加のバッファリングまたは構文解析のコストが発生しないように、各選択された１つまたは複数の初期または後続のユニットに関連する変換ライタを使用して変換されることを特徴とする請求項１に記載の方法。
3. １つまたは複数のメッセージユニットの前記変換された初期セットを、受信側に送る動作をさらに備えることを特徴とする請求項１に記載の方法。
4. 前記交換フォーマットメッセージは、ＸＭＬメッセージであることを特徴とする請求項１に記載の方法。
5. 前記基準は、排他的正規化基準または包含的正規化基準の一方であり、前記初期または後続セットの前記１つまたは複数のメッセージユニットを変換する動作は、前記初期または後続セットの前記１つまたは複数のメッセージユニットを正規化する動作を含むことを特徴とする請求項４に記載の方法。
6. 前記メッセージ内の少なくとも前記初期セットの１つまたは複数のユニットを受け取るために充分であるが前記メッセージ内の前記複数のユニットのすべてには充分ではない、システムメモリの一部分を割り当てる動作をさらに備えることを特徴とする請求項１に記載の方法。
7. １つまたは複数のユニットの前記後続セットをメモリ内に選択する動作は、
   １つまたは複数のメッセージユニットの前記初期セットが変換された後、前記割り当てられたメモリ部分を開放する動作と、
   １つまたは複数のメッセージユニットの前記初期セットによって占められた前記割り当てられたメモリ部分を、１つまたは複数のユニットの前記後続セットによって上書きする動作とを含むことを特徴とする請求項６に記載の方法。
8. 前記選択された１つまたは複数のユニットのサイズは、現在使用可能な処理リソース、システムメモリリソース、または接続帯域幅に基づくことを特徴とする請求項６に記載の方法。
9. 前記アクセスされるメッセージは、セキュアメッセージであり、
   前記初期セットの前記１つまたは複数のユニットを、識別子を求めてスキャンする動作と、
   識別子が前記ユニットに必要とされるが見つからない場合、前記初期セットの前記１つまたは複数のユニットの任意のユニットに識別子を挿入する動作と、
   識別子のスキャン、前記識別子の挿入、および変換が単一のパスで達成されるように、各前記１つまたは複数のメッセージユニットを同時に変換する動作とを備えることを特徴とする請求項１に記載の方法。
10. 前記初期セットの前記１つまたは複数のユニットのうち少なくとも１つは、ＸＭＬメッセージのメッセージヘッダであることを特徴とする請求項９に記載の方法
11. 前記初期セットの前記１つまたは複数のユニットを要約する動作と、
    前記初期セットの前記１つまたは複数のユニットをデジタルで署名する動作とをさらに備えることを特徴とする請求項９に記載の方法。
12. 前記アクセスされたメッセージの所期の受信者が、前記メッセージ全体のストリームを必要とすることを識別する動作と、
    前記メッセージの前記複数の各ユニットを、それらが変換されるときに蓄積する動作と、
    前記蓄積された、前記メッセージの変換されたユニットを、ストリームする動作とをさらに備えることを特徴とする請求項１に記載の方法。
13. １つまたは複数のメッセージユニットの前記初期セットを選択する前記動作と、１つまたは複数のユニットの前記初期セットを変換する前記動作は、変換ライタによって行われ、前記変換ライタは、アプリケーションに関連付けられたプログラムクラスであることを特徴とする請求項１に記載の方法。
14. 受信側コンピュータシステムと送信側コンピュータシステムが交換フォーマットで１つまたは複数のメッセージを交換することができる、コンピュータ化された環境における、受信側コンピュータシステムにおいて、リソース効率の良いやり方で受信された交換フォーマットメッセージを変換する方法であって、
    交換フォーマットメッセージの１つまたは複数の変換されたユニットの初期セットをメモリ内に受け取る動作であって、前記初期セットは、前記メッセージ内の複数の変換されたユニットのうちすべてより少ないユニットである動作と、
    前記受け取った変換されたユニットの初期セットを、基準に基づいて、前記交換フォーマットメッセージの対応する初期部分に変換する動作と、
    前記交換フォーマットメッセージの前記対応する初期部分を、ファイルに渡す動作と、
    前記交換フォーマットメッセージの１つまたは複数の変換されたユニットの後続セットをメモリ内に受け取る動作であって、前記後続セットのユニットは、前記メッセージ内の前記複数の変換されたユニットのうちすべてよりも少ないユニットである動作とを備えることを特徴とする方法。
15. 前記初期または後続のセットを受け取るために充分なメモリの一部分を割り当てる動作をさらに備えることを特徴とする請求項１４に記載の方法。
16. 前記初期セットのダイジェストを計算する動作と、前記受信側コンピュータシステムで前記計算されたダイジェストを、１つまたは複数の変換されたユニットの前記初期セットについて、前記送信側コンピュータシステムにより送られたダイジェストと比較する動作とをさらに含むことを特徴とする請求項１４に記載の方法。
17. 前記メッセージの前記複数の変換されたユニットのすべてが受け取られた後、前記ファイルは、前記交換フォーマットメッセージの実質的表現であることを特徴とする請求項１４に記載の方法。
18. 前記交換フォーマットメッセージは、ＸＭＬメッセージであり、前記基準は、正規化基準であることを特徴とする請求項１４に記載の方法。
19. １つまたは複数の変換されたユニットの前記初期セットを変換する前記動作と、１つまたは複数の変換されたユニットの前記初期セットを渡す前記動作は、変換リーダによって行われ、前記変換リーダは、アプリケーションに関連付けられたプログラムクラスであることを特徴とする請求項１４に記載の方法。
20. 送信側コンピュータシステムと受信側コンピュータシステムが交換フォーマットで１つまたは複数のメッセージを交換することができる、コンピュータ化された環境における、送信側コンピュータシステムにおいて使用するためのコンピュータプログラム製品であって、リソース効率の良いやり方で交換フォーマットメッセージを変換する方法を実装するためのコンピュータプログラム製品であって、コンピュータ実行可能命令を格納している１つまたは複数のコンピュータ可読媒体を含み、前記コンピュータ実行可能命令は、プロセッサによって実行されるとき、
    複数の異なるメッセージユニットを含む交換フォーマットメッセージにアクセスすること、
    前記複数の異なるメッセージユニットのうちのすべてより少ないユニットが選択されるように、前記メッセージから１つまたは複数のメッセージユニットの初期セットを選択すること、
    前記初期セットの前記１つまたは複数の選択されたメッセージユニットを、基準に基づいて、１つまたは複数の変換されたユニットの変換された初期セットに変換すること、
    前記複数の異なるメッセージユニットのうちのすべてより少ないユニットが選択されるように、前記メッセージから１つまたは複数のユニットの後続の異なるセットをメモリ内に選択すること、および、
    前記後続の異なるセットの前記１つまたは複数のユニットを、１つまたは複数の変換されたユニットの変換された後続セットに変換することを、前記送信側コンピュータシステムに実行させることを特徴とするコンピュータプログラム製品。
    

Images