(57)【要約】【課題】ソースデータ構造から同一アイテムを表すターゲットデータ構造へ生データを転送する。【解決手段】データ転送中に、ソースデータ構造によって提供されるフィールドに対応しないフィールドがターゲットデータ構造に存在する場合には、転送メカニズムは、ソースデータ構造がそのフィールドを提供することが必須であるかどうかを判断する。それが必須である場合には、転送は失敗する。それが必須でない場合には、転送は続行される。ターゲットデータ構造のフィールドに対応しないフィールドがソースデータ構造のフィールドにある場合には、転送メカニズムは、ターゲットデータ構造がそのフィールドを有することが必須であるかどうかを判断する。それが必須である場合には、転送は失敗する。それが必須でない場合には、その対応するデータを、ターゲットデータ構造の未知データ用の残余フィールドに提供することができる。【選択図】図６
2006216027.tif 000002
【特許請求の範囲】
【請求項１】
ソースデータ構造からターゲットデータ構造にデータを転送するためのコンピュータ化された方法において、
前記ターゲットデータ構造に対応する所与のフィールドについて、該所与のフィールドが前記ソースデータ構造内に関連するフィールドを有していないと判断し、それに応じて以下のアクト、すなわち、
転送が成功するために前記ソースデータ構造が前記所与のフィールドに対応するフィールドを提供することが必須であるかどうかを判断するアクト、
前記ソースデータ構造が前記所与のフィールドに対応するフィールドを提供することが必須である場合には、転送に失敗するアクト、および
前記ソースデータ構造が前記所与のフィールドに対応するフィールドを提供することが必須でない場合には、転送を続行するアクト
を実行するアクトと、
前記ソースデータ構造の所与のフィールドについて、前記ターゲットデータ構造内に対応するフィールドが存在しないと判断し、それに応じて以下のアクト、すなわち、
転送が成功するために前記ターゲットデータ構造が前記ソースデータ構造内の前記所与のフィールドに対応するフィールドを有することが必須であるかどうかを判断するアクト、
前記ターゲットデータ構造が前記ソースデータ構造内の前記所与のフィールドに対応するフィールドを有することが必須である場合には、転送に失敗するアクト、および
前記ターゲットデータ構造が前記ソースデータ構造内の前記所与のフィールドに対応するフィールドを有することが必須でない場合には、第１のデータ構造の他のフィールドからのデータを第２のデータ構造の残余フィールドに提供するアクト
を実行するアクトと
を含むことを特徴とするソースデータ構造からターゲットデータ構造にデータを転送するためのコンピュータ化された方法。
【請求項２】
前記ソースデータ構造がネットワークを通じてソースコンピュータシステムから提供され、前記ターゲットデータ構造がターゲットコンピュータシステム上に存在し、前記コンピュータ化された方法が該ターゲットコンピュータシステム上で実行されることを特徴とする請求項１に記載のソースデータ構造からターゲットデータ構造にデータを転送するためのコンピュータ化された方法。
【請求項３】
前記ソースデータ構造がコンピュータシステムによってデータストアから読み出され、前記ターゲットデータ構造が該コンピュータシステム上のメモリ内で表現されることを特徴とする請求項１に記載のソースデータ構造からターゲットデータ構造にデータを転送するためのコンピュータ化された方法。
【請求項４】
前記ターゲットデータ構造がフォームテンプレートであることを特徴とする請求項１に記載のソースデータ構造からターゲットデータ構造にデータを転送するためのコンピュータ化された方法。
【請求項５】
前記ターゲットデータ構造に対応する前記所与のフィールドが、転送が成功するために該所与のフィールドが前記ソースコンピュータシステムによって提供されなければならないかどうかを表すことを特徴とする請求項１に記載のソースデータ構造からターゲットデータ構造にデータを転送するためのコンピュータ化された方法。
【請求項６】
前記ソースデータ構造の前記所与のフィールドが、転送が成功するために前記ターゲットデータ構造が前記ソースデータ構造内の前記所与のフィールドに対応するフィールドを有することが必須であるかどうかを指定することを特徴とする請求項１に記載のソースデータ構造からターゲットデータ構造にデータを転送するためのコンピュータ化された方法。
【請求項７】
転送が成功するために前記ソースデータ構造が前記所与のフィールドに対応するフィールドを提供することが必須であると判断されることを特徴とする請求項１に記載のソースデータ構造からターゲットデータ構造にデータを転送するためのコンピュータ化された方法。
【請求項８】
前記ソースデータ構造の前記所与のフィールドについて、前記ターゲットデータ構造内に対応するフィールドが存在しないと判断されることを特徴とする請求項７に記載のソースデータ構造からターゲットデータ構造にデータを転送するためのコンピュータ化された方法。
【請求項９】
前記ソースデータ構造の前記所与のフィールドについて、前記ターゲットデータ構造内に対応するフィールドが存在しないと判断されることを特徴とする請求項１に記載のソースデータ構造からターゲットデータ構造にデータを転送するためのコンピュータ化された方法。
【請求項１０】
１つまたは複数のコンピュータ可読媒体に備えたコンピュータプログラムにおいて、該コンピュータプログラムは、コンピュータシステムの１つまたは複数のプロセッサによって実行される時に、該コンピュータシステムに、ソースデータ構造からターゲットデータ構造にデータを転送する方法を実行させ、該方法が、
前記ターゲットデータ構造に対応する所与のフィールドについて、該所与のフィールドが前記ソースデータ構造内に関連するフィールドを有していないと判断し、それに応じて以下のアクト、すなわち、
転送が成功するために前記ソースデータ構造が前記所与のフィールドに対応するフィールドを提供することが必須であるかどうかを判断するアクト、
前記ソースデータ構造が前記所与のフィールドに対応するフィールドを提供することが必須である場合には、転送に失敗するアクト、および
前記ソースデータ構造が前記所与のフィールドに対応するフィールドを提供することが必須でない場合には、転送を続行するアクト
を実行するアクトと、
前記ソースデータ構造の所与のフィールドについて、前記ターゲットデータ構造内に対応するフィールドが存在しないと判断し、それに応じて以下のアクト、すなわち、
転送が成功するために前記ターゲットデータ構造が前記ソースデータ構造内の前記所与のフィールドに対応するフィールドを有することが必須であるかどうかを判断するアクト、
前記ターゲットデータ構造が前記ソースデータ構造内の前記所与のフィールドに対応するフィールドを有することが必須である場合には、転送に失敗するアクト、および
前記ターゲットデータ構造が前記ソースデータ構造内の前記所与のフィールドに対応するフィールドを有することが必須でない場合には、第１のデータ構造の他のフィールドからのデータを第２のデータ構造の残余フィールドに提供するアクト
を実行するアクトと
を含むことを特徴とするコンピュータプログラム。
【請求項１１】
前記ソースデータ構造がネットワークを通じてソースコンピュータシステムから提供され、前記ターゲットデータ構造がターゲットコンピュータシステム上に存在し、前記コンピュータ化された方法が該ターゲットコンピュータシステム上で実行されることを特徴とする請求項１０に記載のコンピュータプログラム。
【請求項１２】
前記ソースデータ構造がコンピュータシステムによってデータストアから読み出され、前記ターゲットデータ構造が前記コンピュータシステム上のメモリ内に表現されることを特徴とする請求項１０に記載のコンピュータプログラム。
【請求項１３】
前記ターゲットデータ構造がフォームテンプレートであることを特徴とする請求項１０に記載のコンピュータプログラム。
【請求項１４】
前記ターゲットデータ構造に対応する前記所与のフィールドが、転送が成功するために該所与のフィールドが前記ソースコンピュータシステムによって提供されなければならないかどうかを表すことを特徴とする請求項１０に記載のコンピュータプログラム。
【請求項１５】
前記ソースデータ構造の前記所与のフィールドが、転送が成功するために前記ターゲットデータ構造が前記ソースデータ構造内の前記所与のフィールドに対応するフィールドを有することが必須であるかどうかを指定することを特徴とする請求項１０に記載のコンピュータプログラム。
【請求項１６】
転送が成功するために前記ソースデータ構造が前記所与のフィールドに対応するフィールドを提供することが必須であると判断されることを特徴とする請求項１０に記載のコンピュータプログラム。
【請求項１７】
前記ソースデータ構造の前記所与のフィールドについて、前記ターゲットデータ構造内に対応するフィールドが存在しないと判断されることを特徴とする請求項１６に記載のコンピュータプログラム。
【請求項１８】
前記ソースデータ構造の前記所与のフィールドについて、前記ターゲットデータ構造内に対応するフィールドが存在しないと判断されることを特徴とする請求項１０に記載のコンピュータプログラム。
【請求項１９】
複数のフィールドを含むデータ構造を有する１つまたは複数のコンピュータ可読媒体において、該複数のフィールドが、
第１のフィールドであって、該第１のフィールドがターゲットデータ構造に転送される時に該フィールドが該ターゲットデータ構造において必須であるかどうかを指定する属性を含む第１のフィールドと、
前記データ構造への以前の転送中に認識されなかったデータを含む残余エリアを表す第２のフィールドと
を含むことを特徴とする１つまたは複数のコンピュータ可読媒体。
【請求項２０】
前記１つまたは複数のコンピュータ可読媒体が物理媒体であることを特徴とする請求項１９に記載の１つまたは複数のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ技術に関し、より詳細には、あるデータ構造から同じアイテムを表す別のデータ構造に生データを転送するメカニズムに関する。
【背景技術】
【０００２】
コンピュータ技術はわれわれの仕事および娯楽のあり方を変えた。現在、コンピュータシステムは、デスクトップコンピュータ、ラップトップコンピュータ、タブレットＰＣ、携帯情報端末（ＰＤＡ）、家電製品等の多様な形態をとっている。コンピュータシステムの機能はソフトウェアによって支配される。ソフトウェアは、実行時にコンピュータシステムにその機能を実行させる一連のコンピュータ実行可能命令である。
【０００３】
相互作用するオブジェクトと呼ばれる論理的単位を用いてソフトウェアの作成を組織化するためのメカニズムとして、オブジェクト指向プログラミングが開発されている。オブジェクトは、そのオブジェクトのプロパティ（属性）を表す１つまたは複数のデータフィールドと、そのオブジェクトの挙動に関係するコンピュータ実行可能コードを含む０個以上のメソッド（操作命令）（またはメソッドへのポインタ）を含む。オブジェクトは、他のオブジェクトによって公開されているメソッドを呼び出すことによって相互作用することができる。このようなオブジェクトは、本明細書では、「データオブジェクト」あるいは「データ構造」（data structures）とも呼ばれる。
【０００４】
メモリ内にある時、データ構造は、関連するデータフィールドおよびメソッドのコレクション（収集体）である。しかし、あるデータ構造から、同じアイテム（項目）を表す別のデータ構造に生データを転送することが必要となる場合がある。これは、ソースデータ構造には存在するがターゲットデータ構造には存在しないデータフィールドに対して生データがある場合や、ターゲットデータ構造には存在するがソースデータ構造には設けられていないデータフィールドに対して生データがある場合には問題となることがある。その場合、転送は通常失敗する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
転送したいフィールドのすべてが両方のデータ構造に含まれるとは限らない場合でも、一方のデータ構造から他方のデータ構造に生データを転送するようなメカニズムがあれば都合が良いことである。
【課題を解決するための手段】
【０００６】
従来技術における上記の課題は本発明の原理によって解決される。本発明は、ソース（源の）データ構造からターゲット（対象の）データ構造に生データを転送することに関する。データ構造はそれぞれ同じコアアイテム（例えば個人）を表し得るが、そのデータ構造の異なるバージョンを表してもよい。
【０００７】
データ転送中に、ソースデータ構造によって提供されるフィールドに対応しないフィールドがターゲットデータ構造に存在する場合には、転送メカニズムは、ソースデータ構造がそのフィールドを提供することが必須のものであるかどうかを判断する。そのフィールドに対応するデータコントラクト（data contract）が、例えば、それが必須であるかどうかを指定する「任意性（optionality）」（または随意性）フィールドを指定できる。ソースデータ構造が当該フィールドに対応するフィールドを提供することが必須である場合、転送は失敗する。他方、ソースデータ構造が当該フィールドを提供することが必須でない場合、転送はデータなしで続行される。
【０００８】
また、ターゲットデータ構造のフィールドに対応しないソースデータ構造のフィールドがある場合には、転送メカニズムは、ターゲットデータ構造がそのフィールドを有することが必須であるかどうかを判断する。当該データフィールド自体が、対応フィールドをターゲットデータ構造が有しなければならないかどうかを指定する「要理解（must understand）」フィールドを指定してもよい。ターゲットデータ構造がこのような対応フィールドを有することが必須である場合には、転送は失敗する。他方、ターゲットデータ構造がこのような対応フィールドを有することが必須でない場合には、そのデータを、ターゲットデータ構造の未知データ用の残余フィールドに未知データとして提供することができる。
【０００９】
したがって、各フィールドについて「任意性」フィールドおよび「要理解」フィールドを設定することにより、データ構造の異なるバージョン間で転送を必要に応じて遂行することができ、あるいはバージョン互換性を適宜無効にすることができる。本発明のさらなる特徴および利点は、以下の説明に記載され、一部はその説明から明らかとなるであろうし、あるいは本発明の実施によって知られるであろう。本発明の特徴および利点は、特に添付の特許請求の範囲に記載の手段および組合せによって実現され達成され得る。本発明のこれらおよびその他の特徴は、以下の説明および添付の特許請求の範囲から十分に明らかとなるであろうし、あるいは以下に記載される本発明の実施によって知られるであろう。
【００１０】
本発明の上記およびその他の利点および特徴を実現し得る態様を説明するため、添付図面に示す本発明の具体的実施形態を参照して、上記で概説した本発明のより詳細な説明を行う。これらの図面が本発明の典型的実施形態を示すだけであり、したがってその範囲を限定するものとみなしてはならないとの了解の下に、本発明について、添付図面を用いてさらに具体的かつ詳細に記述し説明する。
【発明を実施するための最良の形態】
【００１１】
本発明の原理は、ソースデータ構造からアイテムを表すターゲットデータ構造への生データの転送に関する。データ構造はそれぞれ同じコアアイテムを表してもよいが、そのデータ構造の異なるバージョンを表してもよい。データ転送中に、ソースデータ構造によって提供されるフィールドに対応しないフィールドがターゲットデータ構造に存在する場合、転送メカニズムは、ソースデータ構造がそのフィールドを提供することが必須であるかどうかを判断する。必須である場合、転送は失敗する。必須でない場合、転送は続行される。ターゲットデータ構造のフィールドに対応しないソースデータ構造のフィールドがある場合、転送メカニズムは、ターゲットデータ構造がそのフィールドを有することが必須であるかどうかを判断する。必須である場合、転送は失敗する。必須でない場合、対応するデータを、ターゲットデータ構造の未知データ用の残余フィールドに提供することができる。
【００１２】
図面において、同一参照番号は同一要素を指す。図面には、好適なコンピュータ環境において本発明が実施される状態が例示される。以下の説明は、例示された本発明の実施形態に基づくが、本明細書に明示的に記載されない代替実施形態に関して本発明を限定するものと解釈してはならない。
【００１３】
以下の説明では、特に断りのない限り、本発明は１つまたは複数のコンピュータによって実行されるアクト（行為）、およびオペレーションの記号的表現に関して説明される。したがって、理解されるように、このようなアクトおよびオペレーション（これらはコンピュータ実行可能である、と称されることがある）は、構造化された形態でデータを表現する電気信号に対する、コンピュータの処理ユニットによる操作を含む。この操作は、データを変換し、あるいはデータをコンピュータのメモリシステム内のさまざまな位置に保持する。コンピュータは、当業者に十分に理解されるやり方でコンピュータのオペレーションを再設定し、あるいは変更する。データが保持されるデータ構造は、データのフォーマットによって規定される特定の性質を有するメモリの物理的記憶場所である。ただし、本発明は以上の状況において説明されるが、これは限定的に解釈されてはならない。当業者には理解されるように、以下で説明するアクトおよびオペレーションのいくつかがハードウェアとして実施されてもよい。図１は、これらの装置で使用可能な例示的なコンピュータアーキテクチャの概略図である。
【００１４】
説明の目的上、記述されるアーキテクチャは好適な環境の単なる一例であり、本発明の用途や機能の範囲に関するいかなる限定を示唆することも意図していない。また、コンピュータシステムは、図１に例示されるコンポーネントのいずれかまたはその組合せに関するいかなる依存関係あるいは要件を有するものとも解釈してはならない。
【００１５】
本発明は、数多くの他の汎用または専用のコンピュータ用または通信用の環境あるいは構成とともに動作可能である。本発明とともに用いるのに好適な周知のコンピュータシステム、環境、および構成の例として、以下のものに限定されないが、携帯電話、ポケットコンピュータ、パーソナルコンピュータ、サーバ、マルチプロセッサシステム、マイクロプロセッサ方式のシステム、ミニコンピュータ、メインフレームコンピュータ、および上記のシステムまたは装置の任意のものを含む分散コンピュータ環境がある。
【００１６】
その最も基本的な構成において、コンピュータシステム１００は一般に、少なくとも１つの処理ユニット１０２およびメモリ１０４を含む。メモリ１０４は揮発性（例えばＲＡＭ）でも、不揮発性（例えばＲＯＭ、フラッシュメモリ等）でも、あるいはこれら２種の何らかの組合せでもよい。この最も基本的な構成は、図１において破線１０６で示されている。
【００１７】
記憶媒体装置は、付加的な特徴および機能を有してもよい。例えば付加的なストレージ（リムーバブル（取り外し可能）および非リムーバブル（取り外し不能））を含んでもよい。これには、以下のものに限定されないが、ＰＣＭＣＩＡカード、磁気および光ディスク、ならびに磁気テープがある。このような付加的ストレージ（記憶装置）は、図１において、リムーバブルストレージ１０８および非リムーバブルストレージ１１０で示されている。コンピュータ記憶媒体には、揮発性および不揮発性、リムーバブルおよび非リムーバブルの媒体があり、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータのような情報の記憶のための任意の方法あるいは技術で実施される。メモリ１０４、リムーバブルストレージ１０８、および非リムーバブルストレージ１１０はすべてコンピュータ記憶媒体の例である。コンピュータ記憶媒体としては、以下のものに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ等のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク等の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ等の磁気記憶装置、および、所望の情報を格納するために使用可能でありコンピュータシステムからアクセス可能な任意の他の媒体がある。
【００１８】
本明細書で用いる場合、「モジュール」あるいは「コンポーネント」という用語は、コンピュータシステム上で実行されるソフトウェアオブジェクトまたはルーチンを意味し得る。本明細書に記載されるさまざまなコンポーネント、モジュール、エンジン、およびサービスは、コンピュータシステム上で実行されるオブジェクトまたはプロセスとして（例えば別個のスレッドとして）実施可能である。本明細書に記載されるシステムおよび方法は好ましくはソフトウェアとして実施されるが、ソフトウェアおよびハードウェアによる実施態様、またはハードウェアによる実施態様も可能であり想定される。
【００１９】
また、コンピュータシステム１００は、ホストがネットワーク１２０を通じて他のシステムおよび装置と通信することを可能にする通信チャネル１１２も含み得る。通信チャネル１１２は通信媒体の例である。通信媒体は一般に、搬送波またはその他のトランスポートメカニズムのような変調データ信号としてコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを具現化し、任意の情報伝達媒体を含む。例として、限定ではないが、通信媒体には、有線ネットワークや直接線接続（direct-wired connections）のような有線媒体、音響、電波、赤外線、およびその他のワイヤレス媒体のような無線媒体がある。本明細書で用いられる場合、コンピュータ可読媒体という用語は、記憶媒体および通信媒体の両方を含む。
【００２０】
また、コンピュータシステム１００は、キーボード、マウス、ペン、音声入力コンポーネント、タッチ入力装置等のような入力コンポーネント１１４も有し得る。出力コンポーネント１１６としては、スクリーンディスプレイ、スピーカ、プリンタ等と、それらを駆動するためのレンダリングモジュール（しばしば「アダプタ」と呼ばれる）がある。コンピュータシステム１００は電源１１８を有する。これらすべてのコンポーネントは当技術分野で周知であり、ここで詳細に説明するには及ばない。
【００２１】
図２は、ソースデータ構造２０１の１つまたは複数のフィールドが転送メカニズム２０３を用いてターゲットデータ構造２０２に転送される環境２００を例示している。ソースデータ構造２０１およびターゲットデータ構造２０２は、同一アイテムを表すことができるが、それらをさまざまな方法や様式で表してもよい。例えば、データ構造はそれぞれ特定の個人、組織、航空券予約、あるいはその他の、関連するデータを有し得る任意の想定されるオブジェクト（対象）またはエンティティ（実体）を表すことができる。ソースデータ構造２０１およびターゲットデータ構造２０２は、いかなる媒体（無線通信のような無形の媒体であってもよい）上に具現化されてもよく、さらに別のデータ構造のシリアライズされた表現であってもよいが、必ずしもそうである必要はない。
【００２２】
データ構造のいくつかのデータフィールドが同一であってもよい。例えば、図２に例示するように、ソースデータ構造２０１はデータフィールド２０１Ａを有するが、これはターゲットデータ構造２０２のデータフィールド２０２Ａと同じデータを含む。一例として、そのデータ構造がそれぞれ、特定の個人に関連するデータを表す場合を考える。ソースデータ構造２０１のデータフィールド２０１Ａがその個人の名前を表すのに対して、データフィールド２０２Ａは、転送メカニズム２０３が書き込みを行なう名前フィールドである。
【００２３】
他方、ソースデータ構造２０１は、ターゲットデータ構造２０２に存在しないフィールド（例えばフィールド２０１Ｂ）を有してもよい。例えば、ターゲットデータ構造２０２にはフィールド２０２Ｂがない。一具体例では、フィールド２０１Ｂは、関連する個人が存命中か否かを表すブール値（Boolean value）であるのに対して、ターゲットデータ構造２０２はそのようなフィールドを有しない。
【００２４】
以下でさらに説明する一例示的実施態様において、特定のエンティティ（例えば個人）を表す際にどのようなフィールドがデータ構造に含まれるべきかを記述するために、「データコントラクト」（data contract;データ規約）が用いられる。ソースデータ構造２０１およびターゲットデータ構造２０２は、「個人」データコントラクトの相異なるバージョンに準拠してもよい。ここで、ソースデータ構造２０１が準拠するバージョンは、当該個人が存命中かどうかを表すフィールドがデータ構造に含まれるべきことを指定する。これに対して、ターゲットデータ構造が準拠する個人データコントラクトのバージョンは、当該個人が存命中かどうかを表すフィールドがデータ構造に含まれるべきことを指定しない。特定のエンティティに対する異なるデータフィールドの必要性が時間とともに変化するのに応じて、データコントラクトの異なるバージョンが作成されることがあり得る。
【００２５】
このようなデータコントラクトは、図２、図３、図４、図５Ａおよび図５Ｂに関して本発明の一般的原理を説明する際には、一般的用語で記述される。というのは、本発明の原理は、最広義において、データ構造がデータコントラクトに準拠するかどうかにかかわらず、ソースデータ構造からターゲットデータ構造へのデータの一般的転送に関するからである。しかし、その説明を完全にするため、データコントラクトの概念を、図６〜図１０においてさらに詳細に説明する。
【００２６】
上記のように、データ構造がデータコントラクトの異なるバージョンに準拠するために、ソースデータ構造２０１はターゲットデータ構造２０２とは異なるフィールドを含むことがある。また、データコントラクトのバージョンが異なることにより、ターゲットデータ構造２０２がソースデータ構造２０１とは異なるフィールドを含むこともあり得る。例えば、ターゲットデータ構造はデータフィールド２０２Ｃを含むように示されているが、ソースデータ構造は対応するデータフィールド２０１Ｃを含んでいない。個人データコントラクトの例では、データフィールド２０２Ｃは社会保障番号を表してもよい。これは、ターゲットデータ構造２０２が準拠する個人データコントラクトのバージョンには表されているが、ソースデータ構造２０１が準拠する個人データコントラクトのバージョンには表されていない。
【００２７】
ソースデータ構造２０１およびターゲットデータ構造２０２は、データ構造の間で共通である１つのフィールド（ソースデータ構造２０１のフィールド２０１Ａ、およびターゲットデータ構造２０２のフィールド２０２Ａ）（以下「共通データフィールド」という）を含むとして示されている。また、ソースデータ構造２０１は、ターゲットデータ構造２０２に含まれないデータフィールド（例えばデータフィールド２０１Ｂ）（以下「ソース限定データフィールド」と称する）を含むように示されている。最後に、ターゲットデータ構造２０２は、ソースデータ構造２０１に含まれないデータフィールド（例えばデータフィールド２０２Ｃ）（以下「ターゲット限定データフィールド」と称する）を含むように示されている。
【００２８】
ただし、ソースデータ構造２０１は、適宜（例えば、データ構造２０１および２０２のそれぞれが準拠するデータコントラクトバージョンの相違に従って）、任意個数（０個以上）の共通データフィールド、および任意個数（０個以上）のソース限定データフィールドを含み得る。また、ターゲットデータ構造２０２は、適宜（例えばコントラクトバージョンの相違に従って）、任意個数（０個以上）の共通データフィールド、および任意個数（０個以上）のターゲット限定データフィールドを含み得る。縦の省略記号２０１Ｄおよび２０２Ｄは単に、ソースデータ構造２０１およびターゲットデータ構造２０２がそれぞれ適宜、さらに他のデータフィールドを含み得ることを表すために図示されているものである。また、ターゲットデータ構造２０２は、残余フィールド（residual field）２０２Ｅを含むように示されている。この残余フィールド２０２Ｅの目的については、図５Ａを参照してさらに詳細に説明する。
【００２９】
図４は、本発明の原理による、ソースデータ構造からターゲットデータ構造にデータを転送するコンピュータ実施メッソード（操作命令）４００のフローチャートを示している。メッソード４００の一環として、ソースデータ構造およびターゲットデータ構造にアクセスする（アクト４０１）。本明細書において、「データ構造」という用語は、当該データ構造が具現化される媒体にかかわらず、１つまたは複数のフィールドを含む任意の構造化されたデータ（シリアライズされたデータでもよい）を含むものとして広義に定義される。例えば、コンピュータシステムはネットワークを通じてソースデータ構造にアクセスできる。この場合、メッソード４００はターゲットコンピュータシステム上で実行される。例えば、ターゲットコンピュータシステムが図１のコンピュータシステム１００である場合に、ターゲットコンピュータシステムはネットワーク１２０を通じてソースデータ構造にアクセスできる。しかし、そのコンピュータシステムは、例えば揮発性、または不揮発性のメモリのような他のデータ記憶媒体のソースデータ構造にもアクセス可能である。図１の場合に、ターゲットデータ構造は、システムメモリ１０４および／またはストレージ（記憶装置）１０８もしくは１１０においてアクセス可能としてもよい。
【００３０】
共通データフィールドがある場合、コンピュータシステムは単に、ソースフィールドから対応するターゲットフィールドにデータをコピーするだけである。もちろん、そのコピーは、符号化フォーマットの何らかの変換を伴う場合がある。また、コンピュータシステムは、ターゲットデータ構造には含まれていないソースデータ構造内のソース限定データフィールドを識別する（アクト４０２Ａ）。このようなソース限定フィールドがある場合には、コンピュータシステムは、図５Ａのメッソード５００Ａ（アクト４０３Ａおよび図５Ａ）を実行する。また、そのコンピュータシステムは、ソースデータ構造には含まれていないターゲットデータ構造内のターゲット限定データフィールドを識別する（アクト４０２Ｂ）。このようなターゲット限定フィールドがある場合には、コンピュータシステムは、図５Ｂのメッソード５００Ｂ（アクト４０３Ｂおよび図５Ｂ）を実行する。
【００３１】
図５Ａのメッソード５００Ａを参照すると、識別されたソース限定データフィールドがある場合に、コンピュータシステムは、転送が成功するために、そのソース限定データフィールドに対応するフィールドがターゲットデータ構造内にあることが必須であるかどうかを判断する（判断ブロック５０１Ａ）。それが必須である場合には（判断ブロック５０１Ａの「必須である」）、コンピュータシステムは、転送に失敗する（アクト５０２Ａ）。それが必須でない場合には（判断ブロック５０１Ａの「必須でない」）、コンピュータシステムはソース限定データフィールドから残余フィールドにデータを供給する（アクト５０３Ａ）。残余フィールド（例えば図２の残余フィールド２０２Ｅ）は、ソースデータ構造からのデータのうち、ターゲットデータ構造によって理解されなかったすべてのデータを保持する論理的コンテナ（入れ物）である。残余フィールド内のデータは、各データの抽出元のフィールドタイプを後で識別できるようにタグづけされてもよい。残余フィールド内のデータは、データ構造がさらに別のターゲットデータ構造に再送される場合には再転送されることにより、データコントラクトの前のバージョンからのデータを保持することも可能である。
【００３２】
図３は、データコントラクトの一端として使用可能なデータフィールドテンプレート３００を例示している。これは、データフィールドタイプ３０１（例えば、個人データコントラクトの場合には名前）と、転送が成功するためにソースデータ構造がターゲットデータ構造に含まれる特定のフィールドを有しなければならないかどうかを定義する任意性（随意性、選択性）フィールド３０２と、転送が成功するためにターゲットデータ構造がソースデータ構造に含まれる特定のフィールドを有しなければならないかどうかを定義する要理解フィールド３０３とを定義する。テンプレート３００によって定義されるのと同じデータタイプのデータフィールドを含むソースデータ構造が、送信あるいは格納される場合には、データタイプ３０１に関連する生データ（raw data）が、そのテンプレートによって定義される対応する要理解の指示３０３とともに送信あるいは格納される。したがって、ソース限定データフィールドが必須であるかどうかは、ソース限定データフィールド自身に関連する要理解フィールドから知ることができる。
【００３３】
図５Ｂのメッソード５００Ｂを参照すると、識別されたターゲット限定データフィールドがある場合には、コンピュータシステムは、転送が成功するために、ソースデータ構造がターゲット限定データフィールドに対応するフィールドを提供する（supply）ことが必須であるかどうかを判断する（判断ブロック５０１Ｂ）。それが必須である場合には（判断ブロック５０１Ｂの「必須である」）、コンピュータシステムは、転送に失敗する（アクト５０２Ｂ）。それが必須でない場合には（判断ブロック５０１Ｂの「必須でない」）、コンピュータシステムは、転送を続行する（アクト５０３Ｂ）。例えば、コンピュータシステムが次のフィールドを評価（検討）し、ソースおよびターゲットのフィールドがすべて評価された場合には、全転送が正しく完了する。
【００３４】
ターゲット限定データフィールドが必須であるかどうかは、ターゲット限定データフィールド自身に関連するメタデータから理解し得る。例えば、ターゲット限定データフィールドが、図３のデータフィールド３００について例示したように構造化されているとする。ターゲット限定データフィールド（またはターゲット限定データフィールドに関連する構造（例えばデータコントラクト））は、任意性フィールド３０２を含み得る。任意性フィールド３０２は、ソースデータ構造が、ある関連するフィールドを提供しなければならないかどうかについてのブール表現とすることができる。判断ブロック５０１Ｂにおける判断は、任意性フィールド３０２に基づいてなされ得る。
【００３５】
本発明の基本原理を説明したので、次に、図６〜図１０に関して、本発明の具体的実施形態を説明する。図６〜図１０では、データコントラクトを用いて、シリアライゼーションおよびデシリアライゼーションの際にデータ構造の形式を定義する。
【００３６】
図６は、シリアライゼーションメカニズムを用いたシリアライゼーションのプロセス（処理過程）の概略図である。シリアライゼーションメカニズム６００は、シリアライゼーションエンジン６０１およびフォーマッタ６０２を含む。シリアライゼーションエンジン６０１およびフォーマッタ６０２は、同一ルーチン内に統合されても、別個のルーチンによって実施されてもよく、いずれでも本発明の原理に影響を及ぼさない。シリアライゼーションエンジン６０１およびフォーマッタ６０２は、図１のコンピュータシステム１００の環境内で実行されるコンポーネントであってもよい。しかし、本発明の原理は、いかなる特定のハードウェア環境に対しても独立であり、それには限定されない。図６に示した残りの構成は図７に関して説明する。図７は、本発明の原理によるシリアライズのメッソードのフローチャートを示している。
【００３７】
本実施形態において、データオブジェクトは、抽象データ（abstract data）を包囲する構造体をシリアライズするのではなく、データオブジェクトから抽出された抽象データのみをシリアライズすることによって、シリアライズされる。したがって、シリアライズされたデータにアクセスするエンティティは、データの抽出元のデータオブジェクトの構造を理解する必要がない。また、シリアライゼーションは、データオブジェクトの形式に関する、おそらくは機密性のある情報を開示しない。
【００３８】
図７を参照する。まず、シリアライゼーションの対象となるデータオブジェクトにアクセスする（アクト７０１）。例えば、図６のシリアライゼーションエンジン６０１がデータオブジェクト６３１にアクセスし得る。データオブジェクト６３１は任意のデータオブジェクトタイプでよい。説明の目的上、データオブジェクト６３１は、データフィールド６３１Ａ〜６３１Ｃを含むものとして例示されているが、他のものがあってもよく、それらは縦の省略記号６３１Ｄで表されている。
【００３９】
次に、データオブジェクトが「データコントラクト」に関連するかどうかを判断する（アクト７０２）。本明細書および特許請求の範囲において、「データコントラクト」は、シリアライズされるべきデータフィールドに対応する１つまたは複数のデータフィールドタイプの識別情報として定義される。
【００４０】
例えば、シリアライゼーションエンジン６０１は、任意個数のデータコントラクトを含み得るデータコントラクト６１１のコレクションにアクセスできる。図示されているように、データコントラクト６１１はデータコントラクト６１１Ａ〜６１１Ｄを含むが、他のものがあってもよく、それらは省略記号６１１Ｅで表されている。データコントラクトは、特定の論理エンティティタイプに対応してもよい。例えば、データコントラクト６１１Ａは、個人データタイプに対応してもよい。ただし、対応するデータコントラクトを有し得るデータオブジェクトのタイプに制限はない。
【００４１】
図６は、データコントラクト６１１Ａを拡大して、いくつかのデータフィールドタイプ６２１を含む様子を示している。各データフィールドタイプは、データフィールドタイプ識別情報６２２と、当該データタイプに関係する１つまたは複数の他の指示子（designator）６２３を含み得る。例えば、データコントラクト６１１Ａは、個人データオブジェクト全般に対応すると想定する。例えば、データフィールドタイプ６２１Ａは名前データタイプ、データフィールドタイプ６２１Ｂは年齢データタイプ、データフィールドタイプ６２１Ｃは性別データタイプ、データフィールドタイプ６２１Ｄは住所データタイプ、等とすることができる。図示されている指示子は、前述の「要理解（must understand）」に対する「ＭＵ」と、「任意性（optionality）」に対するＯを含む。それら指示子には、ターゲットによって理解されないデータを残余フィールド（例えば図２の残余フィールド２０２Ｅ）に入れるべきかどうかを示す「ＲＴ」指示子を含んでもよい。
【００４２】
図７に戻って、次に、データオブジェクトが、データコントラクトに規定されているデータフィールドタイプに対応するデータフィールドを有するかどうかを判断する（判断ブロック７０３）。例えば、図６のシリアライゼーションエンジン６０１がデータコントラクト６１１Ａを、アクセスしたデータオブジェクト６３１に関連するものと識別したと想定する。その場合には、シリアライゼーションエンジン６０１は、データフィールドタイプ６２１Ａを評価（検討）して、そのデータフィールドタイプ６２１Ａに対応するデータオブジェクト６３１の関連データフィールドがデータオブジェクト６３１のデータフィールド６３１Ａ〜６３１Ｄのいずれかのうちにあるかどうかを判断する。例えば、データフィールドタイプ６２１Ａが名前データタイプであると想定する。その場合には、シリアライゼーションエンジン６０１は、データオブジェクト６３１のすべてのデータフィールドを評価して、「名前」フィールドがあるかどうかを判断する。
【００４３】
データオブジェクトが、データフィールドタイプに対応するデータフィールドを有していると判断された場合には（判断ブロック７０３のＹｅｓ）、その対応するデータをデータオブジェクトから抽出する（アクト７０４）。例えば、データエクストラクタコンポーネント６４１が、データオブジェクトからデータフィールドタイプ（例えば名前データタイプ）に対応する適切なデータフィールド（例えば特定の１つまたは複数の名前）を抽出できる。この抽出プロセスの一環として、抽出した各データフィールドごとに、関連する要理解フィールドも抽出される。
【００４４】
データコントラクトに指定されたデータフィールドタイプが他に存在しない場合（判断ブロック７０５のＮｏ）、抽出されたデータフィールド（およびそれらの関連する要理解フィールド）があればそれをシリアライズする（アクト７０６）。別法として、データフィールドは、抽出した直後にシリアライズしてもよい。例えば、シリアライゼーション（アクト７０６）は、すべてのデータフィールドを抽出する（判断ブロック７０５のＮｏ）まで待機するのではなく、抽出（アクト７０４）の直後に行われてもよい。抽出したデータは図６の抽象データ（abstract data）６４２で表されている。このデータは、データオブジェクトとは独立であって、データオブジェクト全体ではなく、抽出したデータのみを含む。次に、フォーマッタ６０２が、どのシリアライゼーションフォーマットにシリアライズすべきかを判断し、コンバータ６１２のライブラリから、そのシリアライゼーションフォーマットに対応する妥当なコンバータを選択する。例として、コンバータ６１２のライブラリは、対応するコンバータ６１２Ａ、６１２Ｂ、６１２Ｃ、６１２Ｄを含むように図示されているが、他のものがあってもよく、それらは省略記号６１２Ｅで表されている。シリアライゼーションフォーマットの例としては、バイナリ（２値）、ＸＭＬ（eXtensible Markup Language；拡張マークアップ言語）が挙げられるが、従来のものかどうか、あるいはまだ存在していないかどうかを問わず、他のシリアライゼーションフォーマットであってもよい。次に、フォーマッタ６０２は、その適切なコンバータコンポーネント（例えばコンバータコンポーネント６１２Ａ）を用いて、抽象データ６４２をその適切なシリアライゼーションフォーマットにシリアライズする。
【００４５】
図７に戻って、データコントラクト内に評価すべきデータフィールドタイプがまだ他にもある場合には（判断ブロック７０５のＹｅｓ）、フローは判断ブロック７０３に戻り、データコントラクト内の次のデータフィールドタイプについて、データオブジェクト内にそのデータフィールドタイプに対応するデータフィールドがあるかどうかを判断し（アクト７０３）、プロセスは繰り返される。
【００４６】
データコントラクト内にあるデータフィールドタイプに対応するデータフィールドがデータオブジェクト内にない場合には（判断ブロック７０３のＮｏ）、いつでも、そのデータフィールドタイプは必須であるか、それとも任意であるかを判断する（判断ブロック７０７）。この判断は、データコントラクト内の対応するデータフィールドタイプ内の指示子６２３を参照することによって行うことができる。
【００４７】
データフィールドタイプが任意である場合（判断ブロック７０７のＹｅｓ）、フローは判断ブロック７０５に戻り、そこで、データコントラクト内に評価すべき他のデータフィールドタイプがなければ、シリアライゼーションを実行し（アクト７０６）、評価すべきデータフィールドタイプが他にもあれば、次のデータフィールドタイプを評価する（判断ブロック７０３）。
【００４８】
他方、データフィールドタイプが任意でなく、送信側から見て必須である場合（判断ブロック７０７のＮｏ）、データオブジェクトに対応する補助データ構造において、関連するデータフィールドが存在するかどうかを検索することができる（アクト７０８）。例えば、図６のシリアライゼーションエンジン６０１は、データオブジェクト６３１に関連する補助データ構造６４４において、データコントラクト内の現在のデータフィールドタイプに対応するデータフィールドが存在するかどうかを検索できる。このようなデータフィールドが補助データ構造内に見つかった場合（判断ブロック７０９のＹｅｓ）、そのデータフィールドを抽出し（アクト７０４）、抽象データのコレクションに追加する。このようなデータフィールドが補助データ構造内に見つからない場合には（判断ブロック７０９のＮｏ）、シリアライゼーションエンジン６０１は、シリアライゼーションが失敗したことを指示する（アクト７１０）。もちろん、シリアライゼーションメカニズムにおいて、データフィールドが常に補助データ構造内に見つかることが保証されている場合には、アクト７１０のシリアライゼーションエラーは決して生じないこともある。このような補助データ構造の一例は、図２の残余フィールド２０２Ｅである。送信されるべきオブジェクトは、以前のデータ転送試行中にそのオブジェクトに受け入れるべきデータの認識に失敗したことがある場合には、残余フィールド２０２Ｅ内の未知データを含んでいてもよい。別法として、シリアライゼーションプロセスは、すべてのデータフィールドを、それらの任意性ステータスにかかわらずそのままシリアライズし、転送が失敗するかどうかの形式的評価を受信側に委ねることもできる。
【００４９】
オプションとして、データフィールドタイプが任意であると判断される場合（判断ブロック７０７で任意の場合）にも、補助データ構造６４４を検索してもよい。その場合、対応するデータフィールドが補助データ構造に見つからない場合には、フローはそのまま判断ブロック７０５に進み、データコントラクト内に評価すべきデータフィールドタイプが他にもあるかどうかを判断する。
【００５０】
図７の破線のボックス７１１は、データコントラクトから評価すべき各データタイプごとの評価プロセスを表す。このプロセスは、対応するデータフィールドがない必須データフィールドタイプに遭遇するまで（判断ブロック７０９のＮｏ）、またはすべてのデータフィールドタイプを評価し終えるまで（判断ブロック７０５のＮｏ）、繰り返すことができる。
【００５１】
このように、メッソード７００は、データオブジェクトからデータコントラクトに対応する抽象データを抽出するように作動する。抽象データの性質はデータコントラクトによって定義される。また、メッソード７００は、データオブジェクトフォーマットとは独立にこのような抽象データをシリアライズするように作動する。メッソード７００は、多数のデータオブジェクトについて、異なるデータコントラクトがそれらの他のデータオブジェクトに関連しているかどうかにかかわらず、また、使用されるシリアライゼーションフォーマットにかかわらず、繰り返すことができる。このような抽象データは、ある与えられたフィールドが、転送が成功するために、ターゲットによって理解されなければならないかどうかに関する情報も含み得る。このような抽象データは、図２、図３、図４、図５Ａおよび図５Ｂに関して上記で説明したソースデータ構造の一例である。
【００５２】
デシリアライゼーションの説明に進む前に、データオブジェクトの具体例を説明するとともに、データコントラクトがそのデータオブジェクトとどのように関連しているか、および対応するデータフィールドがデータオブジェクト内でどのように識別され得るかを具体的な適応に沿って記述する。下記は例示的データオブジェクトのＣ＃ソースコードである。明確にするため行番号を付加してある。
1.    namespace SomeOtherNamespace {
2.        [DataContract(Namespace="Example", Name="Person")]
3.        public class AnotherPersonThatSomeOneElseCreated {
4.            [DataMember("_name")]
5.            public string FullNameOfThisPerson;
6.        }
7.    }
【００５３】
データオブジェクトに関連するデータコントラクトは、そのデータコントラクトの名前空間（ネームスペース）と名前の組合せによって識別され得る。第２行は、データコントラクトを識別するために必要なすべての情報を含むメタデータを表している。具体的には、データコントラクトの名前空間は「Example」である。データコントラクトの名前は「Person」である。こうしてデータコントラクトが識別される。
【００５４】
データオブジェクトは、クラス「AnotherPersonThatSomeOneElseCreated」（第３行参照）のデータオブジェクトであり、ただ１つのデータフィールドを含む（第５行参照）。データフィールドは、「FullNameOfThisPerson」という名前の文字列（string）である。しかし、その前の行（第４行）は、この文字列データフィールドが、データコントラクトを評価する目的のために、タイプ「_name」とみなされるべきであることを示している。したがって、データフィールドタイプ「string _name」が評価される時、文字列FullNameOfThisPersonがそのデータフィールドタイプに対応すると解釈できる。そして、その文字列を、シリアライズされるべき抽象データとして抽出することができる。
【００５５】
下記は、もう１つの例示的データオブジェクトを示す。
1.    namespace Example {
2.        [DataContract]
3.        class Person {
4.            [DataMember]
5.            private string _name;
6.        }
7.    }
【００５６】
この例では、データオブジェクト名前空間名とデータコントラクトの名前空間名が「Example」で同一である。したがって、第２行でデータコントラクト名前空間をさらに指示する必要がない。また、データコントラクトの名前とデータオブジェクトの名前が「Person」で同一である。したがって、第２行でデータコントラクト名をさらに指示する必要がない。最後に、データオブジェクトおよびデータフィールドタイプにおいて指定されるデータフィールドの名前が「string _name」で同一である。したがって、第４行でデータフィールドタイプをさらに指示する必要がない。
【００５７】
図８は、本発明の原理によるデシリアライゼーションメカニズムを用いたデシリアライゼーションのプロセスの概略図である。図８のデシリアライゼーションメカニズム８００は、図６のシリアライゼーションメカニズム６００と類似している。また、デシリアライゼーションメカニズム８００はデシリアライゼーションエンジン８０１を含み、これは図６のシリアライゼーションエンジン６０１と類似したものであってもよい。フォーマッタ８０２は、図６のフォーマッタ６０２と同一でもよい。フォーマッタ８０２もまたコンバータライブラリ６１２にアクセスでき、一方、デシリアライゼーションエンジン８０１もまたデータコントラクト６１１にアクセスできる。図８の残りの部分については図９に関して説明する。図９は、本発明の原理によるデシリアライズメッソード９００のフローチャートを示している。
【００５８】
まず、デシリアライゼーションメカニズム８００（これは図２の転送メカニズム２０３の一例である）が、シリアライゼーションフォーマットを有するシリアライズされたデータ構造を受信する（アクト９０１）。例えば、フォーマッタ８０２が、シリアライズされたデータ８４３を受信し、このデータは特定のシリアライゼーションフォーマットを有する。
【００５９】
デシリアライゼーションメカニズム８００は、シリアライズされたデータ構造に関連するデータコントラクトを識別する（アクト９０２）。この識別は、シリアライズされたドキュメントに関連するメタデータを評価することによって実行できる。この識別は、ルール（規定）に基づくものでもよい。例えば、ルールは、特定の送信者から受信され特定のドキュメント名を有するシリアライズされたドキュメントが、特定のデータコントラクトに対応することを指定できる。こうしたルールは、管理者によって設定されても、ソフトウェア開発者によってハードコードされても、あるいは他の何らかの方法で設定されてもよい。
【００６０】
さらに、デシリアライゼーションメカニズムは、シリアライズされたデータ構造から、データコントラクトによって規定されている１つまたは複数のデータフィールドタイプに属する１つまたは複数のデータフィールドを復元する（アクト９０３）。これを行うには、フォーマッタ８０２が、シリアライズされたデータ８４３のシリアライゼーションフォーマットに対応する適切なコンバータ６１２を選択するのでもよい。こうしてフォーマッタ８０２は抽象データ８４２を復元する。
【００６１】
データコントラクトに規定されているデータフィールドタイプに対応する、それぞれの抽出されたデータフィールドについて、デシリアライゼーションエンジンは、そのデータフィールドをデータオブジェクトに投入する（populate）ことができるかどうかを判断する（判断ブロック９０４）。これは、データポピュレータ８４１で判断できる。そのデータフィールドを対応するデータオブジェクトに入れることができる場合には（判断ブロック９０４のＹｅｓ）、データポピュレータ８４１は、このデータフィールドを、データオブジェクトに入れるべきデータアイテムのコレクションに追加する（アクト９０５）。別法として、直ちにそのデータフィールドをデータオブジェクトに入れてもよい。データオブジェクトに入れるべきデータフィールドが他に存在しない場合には（判断ブロック９０６のＮｏ）、データオブジェクトに投入する（アクト９０７）。そうでない場合（判断ブロック９０６のＹｅｓ）、次の復元されたデータフィールドを評価し（判断ブロック９０４）、プロセスは繰り返される。
【００６２】
復元されたデータフィールドをデータオブジェクトに入れることができないと判断された場合には（判断ブロック９０４のＮｏ）いつでも、そのデータフィールドが必須であるか、それとも任意であるかを判断する（判断ブロック９０８）。これは、対応するデータコントラクト内の対応するデータフィールドタイプを調べることで判断できる。「要理解」フラグ「ＭＵ」がセットされている場合には、データフィールドタイプはデータオブジェクトによって理解されなければならず、そのデータフィールドは必須であると判断される。要理解フィールドがセットされていない場合には、そのデータフィールドタイプは受信側で任意である。
【００６３】
そのデータフィールドが任意である場合（判断ブロック９０８の「任意」）、そのデータフィールドを、データオブジェクトではなく、補助データ構造（例えば図２の残余フィールド２０２Ｅ）に入れる。例えば、データポピュレータ８４１がそのデータフィールドを補助データ構造８４４に供給することができる。一実施形態では、アクト９０９は、ラウンドトリップ（往復切符）指示子（ＲＴ）がデータコントラクトの対応するデータフィールドタイプにセットされている場合にのみ実行される。いずれの場合でも、フローは次に判断ブロック９０６に進み、投入すべきデータフィールドが他にもあるかどうかを判断する（判断ブロック９０６）。他方、そのデータフィールドが必須である場合には（判断ブロック９０８の「必須」）、デシリアライゼーションが失敗したことを指示する（アクト９１０）。
【００６４】
破線のボックス９１１内に含まれるこのプロセスは、評価すべきデータフィールドがなくなるまで（判断ブロック９０６のＮｏ）、またはデシリアライゼーションが失敗するまで（アクト９１０）、すべての復元されたデータフィールドについて繰り返すことができる。また、破線のボックス９１１内のプロセスは、データオブジェクトに対応するデータフィールドが取得されないようなデータフィールドタイプについても繰り返すことができる。ただしその場合にはフローの性質が以下で説明するように若干変わる。すなわち、データフィールドが存在しないので、データフィールドはデータオブジェクトに入れなくてよい（判断ブロック９０４のＮｏ）。データフィールドタイプが任意である場合（判断ブロック９０８の「任意」）、フローは直接判断ブロック９０６に進み、評価すべきデータフィールドが他にも取得されているかどうか、あるいは取得されたデータフィールドに対応しないようなデータフィールドタイプが他にもあるかどうかを判断する。データフィールドタイプが必須である場合（判断ブロック９０８の「必須」）、デシリアライゼーションは失敗する（アクト９１０）。
【００６５】
メッソード９００は、シリアライズされたドキュメントのフォーマットにかかわらず、またシリアライズされたドキュメントにどのデータコントラクトが関連しているかにかかわらず、受信した任意のシリアライズされたドキュメントについて繰り返すことができる。
【００６６】
このように、本発明の原理は、データオブジェクト全体をシリアライズするのではなく、抽象データをデータオブジェクトから抽出してシリアライズするシリアライゼーションメカニズムを提供する。同様に、デシリアライゼーションメカニズムは、データオブジェクト全体をデシリアライズするのではなく、抽象データを復元し、その抽象データをデータオブジェクトに入れる。したがって、シリアライゼーションおよびデシリアライゼーションのメカニズムは、メモリ内で処理されるデータオブジェクトタイプの性質を公開することを必要とせずに、多数のシリアライゼーションフォーマットおよびデータオブジェクトタイプに適合する。
【００６７】
図１０は、本発明の原理によるサービスの機能を表示するメッソードのフローチャートを示している。このプロセスは、上述したシリアライゼーションおよびデシリアライゼーションの前に実行できる。メッソード１０００は、サービスの機能の表示要求を受け取った場合に実行できるが、必ずしもそうである必要はない。
【００６８】
まず、サービスオブジェクトを評価することにより、サービスオブジェクトによって提供される１つまたは複数のメソッドを識別する（アクト１００１）。このサービスオブジェクトは、例えばウェブサービス全体であってもよい。次に、メソッド（操作命令）のパラメータを評価することにより、どのパラメータがそれに関連するデータコントラクトを有するかを判断する（アクト１００２）。次に、各データコントラクトについて、データコントラクトをパラメータのスキーマ化記述に変換する（アクト１００３）。例えば、シリアライゼーションメカニズム６００は、関連するデータコントラクトに基づいて各パラメータについてＸＭＬスキーマ記述（ＸＳＤ）を生成するように構成されていてもよい。次に、サービスは、メソッドのスキーマ化記述（例えばウェブサービス記述言語（ＷＳＤＬ）の形式で）を、受け入れたパラメータの関連するスキーマ化記述（例えば、各パラメータに対するＸＳＤドキュメントの形式で）とともに提供することができる。
【００６９】
本発明は、その精神あるいは本質的特性から逸脱することなく他の具体的形態で実施されてもよい。記載した実施形態は、すべての点で、単なる例示とみなすべきであり、限定的とみなすべきではない。したがって、本発明の範囲は、上記の説明によってではなく添付の特許請求の範囲によって示される。特許請求の範囲の意味および均等の範囲内に入るすべての変更は本発明の範囲内に包含されるものとする。
【図面の簡単な説明】
【００７０】
【図１】本発明の特徴を実施し得る好適なコンピュータシステムを示す図である。
【図２】本発明の原理による転送メカニズムを用いたソースデータ構造からターゲットデータ構造への生データの転送を示す図である。
【図３】データフィールドタイプの識別情報、任意性フィールド、および「要理解」フィールドを含むデータフィールドテンプレートの概略図である。
【図４】本発明の原理によるソースデータ構造からターゲットデータ構造に生データを転送するメッソードのフローチャートである。
【図５Ａ】関連するターゲットフィールドが要求されるかどうかに応じてソースフィールドを処理するメッソードのフローチャートである。
【図５Ｂ】関連するソースフィールドが要求されるかどうかに応じてターゲットフィールドを処理するメッソードのフローチャートである。
【図６】本発明の原理によるシリアライゼーションメカニズムを用いたシリアライゼーションのプロセスの概略図である。
【図７】本発明の原理によるシリアライズメッソードのフローチャートである。
【図８】本発明の原理によるデシリアライゼーションメカニズムを用いたデシリアライゼーションのプロセスの概略図である。
【図９】本発明の原理によるデシリアライズメッソードのフローチャートである。
【図１０】本発明の原理によるサービスの機能を表示するメッソードのフローチャートである。
【符号の説明】
【００７１】
１０２  処理ユニット
１０４  システムメモリ
１０８  リムーバブルストレージ
１１０  非リムーバブルストレージ
１１２  通信チャネル
１１４  入力コンポーネント
１１６  出力コンポーネント
１１８  電源
１２０  ネットワーク
２０１  ソースデータ構造
２０２  ターゲットデータ構造
２０２Ｅ  残余
２０３  転送メカニズム
３００  データフィールドテンプレート
３０１  データタイプ
３０２  任意性
３０３  要理解
６００  シリアライゼーションメカニズム
６０１  シリアライゼーションエンジン
６０２  フォーマッタ
６１１  データコントラクト
６１２  コンバータ
６２１  フィールドタイプ
６３１  データオブジェクト
６４１  データエクストラクタ
６４２  抽象データ
６４３  シリアライズされたデータ
６４４  補助構造
８００  デシリアライゼーションメカニズム
８０１  デシリアライゼーションエンジン
８０２  フォーマッタ
８３１  データオブジェクト
８４１  データポピュレータ
８４２  抽象データ
８４３  シリアライズされたデータ
８４４  補助構造
【図１】
2006216027.tif 000003
【図２】
2006216027.tif 000004
【図３】
2006216027.tif 000005
【図４】
2006216027.tif 000006
【図５Ａ】
2006216027.tif 000007
【図５Ｂ】
2006216027.tif 000008
【図６】
2006216027.tif 000009
【図７】
2006216027.tif 000010
【図８】
2006216027.tif 000011
【図９】
2006216027.tif 000012
【図１０】
2006216027.tif 000013