(57)【特許請求の範囲】
【請求項１】
異なるデータシェイプに基づく異なる構造型に対応する１又は複数のデータ要素を使用する１又は複数のアプリケーションと処理モジュールとを含むコンピュータ化された環境のオブジェクト指向システムにおいて、異なる構造型を使用するアプリケーションが相互利用可能となるように、前記処理モジュールが、共通データ構造を使用して、マップされたデータ構造をアプリケーションに提供することにより異なる構造型のデータへのアクセスをアプリケーションに提供する方法であって、前記共通データ構造は、オペレーションに対する構造型スキーマ、シーケンスに対する構造型スキーマ、レコードに対する構造型スキーマ、及び認識不可能なデータシェイプを有するデータに対する構造型スキーマを含み、前記データシェイプは、前記共通データ構造における前記１又は複数のデータ要素の構造型に関して分類された、前記１又は複数のデータ要素の構造型を特定するための識別子であり、前記方法は、
前記処理モジュールが、異なるアプリケーションによって保持されたデータへのアクセスを要求するためのアクセス要求を要求アプリケーションから受信する動作であって、前記異なるアプリケーションは、前記要求アプリケーションが使用する構造型とは異なる構造型を使用する、動作と、
前記処理モジュールが、前記異なるアプリケーションに対応するプロキシを識別する動作と、
前記処理モジュールが、当該識別されたプロキシを起動し、当該起動したプロキシを使用して、前記異なるアプリケーションの前記１又は複数のデータ要素をトラバースすることにより前記異なるアプリケーションによって保持される前記１又は複数のデータ要素の各々のデータシェイプを識別し、各識別されたデータシェイプに対応する前記共通データ構造内の構造型を識別する動作と、
前記処理モジュールが、前記異なるアプリケーションの前記１又は複数のデータ要素の各々を前記共通データ構造の当該識別された対応する構造型の各々に関連付けて前記共通データ構造にマップすることにより生成された前記マップされたデータ構造を前記識別されたプロキシから受信する動作であって、前記マップされたデータ構造は、前記共通データ構造の構造型と前記異なるアプリケーションの前記１又は複数のデータ要素の各々との間のマッピング情報を含む、動作と、
前記処理モジュールが、前記マップされたデータ構造を前記要求アプリケーションに提供する動作と
を含み、
前記マッピング情報を使用して前記要求アプリケーションから送信された前記異なるアプリケーションのデータ要素を変更する要求は、前記マッピング情報と結合されて前記異なるアプリケーションに送信され、前記異なるアプリケーションによって前記マッピング情報を使用して処理されることを特徴とする方法。
【請求項２】
前記プロキシは、前記異なるアプリケーションの前記１又は複数のデータ要素の１つが値を返す引数又は関数に対応する前記データシェイプを有することを判断した場合、当該１つのデータ要素に前記オペレーションの構造型を割り当てることを特徴とする請求項１に記載の方法。
【請求項３】
前記プロキシは、前記異なるアプリケーションの前記１又は複数のデータ要素のうちの少なくともいくつかのデータ要素が前記認識不可能なデータシェイプを有することを判断した場合、前記少なくともいくつかのデータ要素に前記認識不可能なデータシェイプを有するデータに対する構造型を割り当てることを特徴とする請求項１に記載の方法。
【請求項４】
前記プロキシは、前記異なるアプリケーションの前記１又は複数のデータ要素の１つが値の集合に対応する前記データシェイプを有することを判断した場合において、
前記値の集合が識別可能なラベルを有しないことを判断した場合、当該１つのデータ要素に前記シーケンスの構造型を割り当て、
前記値の集合は１又は複数の識別可能なラベルを有することを判断した場合、当該１つのデータ要素に前記レコードの構造型を割り当てることを特徴とする請求項１に記載の方法。
【請求項５】
請求項１に記載の方法をプロセッサに実行させるためのプログラムを格納したことを特徴とするコンピュータ可読記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、共通データ構造を介した異なる型の構造へのアクセスに関する。
【背景技術】
【０００２】
コンピュータ化されたシステムの普及につれ、様々なアプリケーションプログラム及びドキュメントがコンピュータ化されたシステムで使用されてきた。特に、現在、複雑なオペレーティングシステム、データベース等として、機能するかどうか、又は、狭小な目的のために構成されたより簡単なアプリケーションプログラムとして機能するかどうか、いろいろな目的のために構成された広範囲のアプリケーションプログラムが存在する。多くの場合において、ソフトウェア開発者は、適切な種々のプログラミング言語を使用して特定のオペレーティングシステム／フレームワークを念頭において、新たなアプリケーションプログラムを作成するだろう。ソフトウェアが完成すると、開発者はアプリケーションをマシン実行可能コードにコンパイルするだろうし、そのマシン実行可能コードは適切なオペレーティングシステムを有するコンピュータシステムにインストールされ得る。多くの場合において、新たなアプリケーションプログラムを実行すると、システム／フレームワーク内のいくつかの他の要素又はアプリケーションを同時に利用する必要があるであろう。
【０００３】
したがって、オペレーティングシステム若しくは汎用フレームワークの開発者並びにフレームワーク内で動作する個々のアプリケーションプログラムの開発者が考慮しなければならない多くの問題があることが十分理解されるだろう。これら関心の多くが一層競合し得る。例えば、多くのオペレーティングシステム／フレームワークの開発者が、セキュリティと安定性に関して興味を持っているものの、多くのアプリケーションプログラム開発者が、高速でかつカスタマイズ可能なオペレーションに関して興味を有し得る。ある場合には、セキュリティ及び安定性に関する要求により、いくつかのアプリケーションプログラムが動作する手法の速度とカスタマイズ性が制限されてしまう。
【０００４】
この対立が明らかである１つの領域が、特定の種類の「型フレームワーク」にある。型フレームワークにおいて、関数、引数、及びデータ値さえも、特定の「型」と相関し得る。別のアプリケーション又は要素が対応するデータにアクセスし又はかかるデータを処理することができる前に、その特定の「型」は、種々のデータ（すなわち、関数、引数、又は値）がどのように現れる必要があるのかを一般的に定義する。強い型のフレームワークを採用するシステムにおいて、１つの型を使用するアプリケーション又は要素が他の型に対応する機能及びデータを実行し又はアクセスすることが禁止されるように、フレームワークは構成され得る。多くの異なる種類の型フレームワークがあるものの、いくつかの例示的フレームワークは、ノミナル（又は主格）構造型のフレームワークを含む。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許第６６９３４５７号明細書
【特許文献２】米国特許出願公開第２００５／０１８７９８０号明細書
【特許文献３】国際公開第２００７／０６７２４８号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
一般に、１つのノミナル型のデータが、厳密に同一の型名を使用する（同一のノミナル型である）他のデータにアクセスのみし得る（又はアクセスのみされ得る）よう、ノミナル（又は主格）型のフレームワークが構成される。したがって、「顧客記録」と称する型名を使用する１つのアプリケーションは、型構造（例えば、記録フィールド等の数と名前）は同一であり得るものの、「メンバ記録」と称する型名の下で別のアプリケーションによって管理された類似のデータにアクセスすることが禁止され得る。例えば、顧客記録のノミナル型とメンバレコードのノミナル型の双方が等しい数と種類のフィールド（例えば、第１の名称＝「文字列、」及び第２の名称＝「文字列、」等を含むセット）を含む場合において、構造上の同一性が生じ得る。対照的に、構造型フレームワークは、名称よりもむしろ構造間の一致に依存している。構造型は不正確な型名称に制限されないものの、型のうちの１つが、別の型よりも多くの種類の構造又は異なる種類の構造（例えば、メンバレコードは、第１の名称＝「文字列、」、第２の名称＝「文字列、」及び電話番号＝値を含む）を含むときに、構造の不一致が生じ得る。
【０００７】
多くの場合、ノミナル型及び構造型を含む種々の異なる型間の不一致に対して、種々の回避方法があるので、アプリケーションが相互利用することができる。ノミナル型フレームワークにおいて、例えば、開発者は対象となる各アプリケーションのために新たなコードを作成し得る。その新たなコードは、１つのノミナル型の型構造を別のノミナル型の同一の型の構造にマップし又は変換する。また、合致していない型構造間において類似の回避方法も可能であるものの、構造型のそのような変換は、より複雑である傾向がある。例えば、Ｌｉｓｐプログラミング言語は、基本構造はデータのペアである１つの共通の従来の構造型フレームワークを実装する。したがって、別のアプリケーションプログラムのデータを使用するために、Ｌｉｓｐベースのアプリケーションは、他方のアプリケーションにおけるデータ構造をデータペア構造に変換する必要が通常あり、これは困難であり得る。
【０００８】
同様に、Ｌｉｓｐデータペア構造から別のアプリケーションの別の型の構造に変換することは、難しい場合がある。これが正しいのは、データがＬｉｓｐにおいてどのように配置されるかという点における差異だけでなく、Ｌｉｓｐデータペアの値は、データペアの計算上効果で完全なトラバースをすることなく、確かめることが多くの場合困難であるからである。この原因は、部分的には、データペアが「シーケンス」であることを除いて、Ｌｉｓｐデータペアが基本的なクエリを介して非常に多くの情報を提供しない傾向があるからである。しかしながら、Ｌｉｓｐプログラミングフレームワークは、異なる型の構造に関する問題を提示し得る唯一の言語でない。各々が自身の異なる構造型フレームワークを使用する他の共通言語はＸＭＬ、ＳＱＬ、．ＮＥＴ、及びＪａｖａを含み、相互利用は多くの場合いくつかの型構造の変換を意味する。
【０００９】
従って、アプリケーションプログラム間の相互利用を確実にする１つの手法が、あらかじめ適切であるとしてノミナル構造及び／又は型構造の詳細に一致する類似のプラットフォーム上で作業するアプリケーション開発者のためにある。もちろん、そのような厳密で正確な一致は必ずしも可能ではなく、後に同じシステムで使用されるだろう要素を作成し得る他の開発者に対して柔軟性をほとんど提供しない。したがって、開発者は、（先に説明したように）１つ以上のインタフェースを作成するはめに多くの場合なってしまう。その１つ以上のインタフェースは、より新しいアプリケーションの型のデータを別のアプリケーションの型のデータに変換し又はマップする。例えば、１つの構造型フレームワークで作成されたアプリケーションを作成する開発者は、Ｌｉｓｐプログラミング言語で作成された他のアプリケーションに対する１つのアダプタを作成する必要があり得るし、そして／又は、場合によっては、ＸＭＬ、ＳＱＬ、．ＮＥＴ、及びＪａｖａプログラミング言語の各々で作成されたアプリケーションに対する個別のアダプタを作成する必要があり得る。
【００１０】
これは新たなアプリケーションプログラムの開発者が他のプログラムで使用される型に関して知る（学習する）必要があるだろうということを意味していると、十分理解されるだろう。考慮すべき少数のアプリケーションにおいて、この問題はよりいっそうの不便が生ずる。しかしながら、より一般的には、特に、システム上の類似の又は同一の種類のデータ（例えば、会員資格記録、機能等）を使用するアプリケーションプログラムの数が増大するにつれて、この種のシナリオにより多くの開発者にとって問題が指数関数的に増大してしまう。さらにこの問題は悪化せしめられ得る。種々のアプリケーションプログラムの各々が変更し得るし種々なアップグレードによって変更され得るからであり、これにより、型名及び又は構造がさらに一層変更されうる結果となり得る。
【００１１】
従って、型ベースのフレームワークにおいて解決され得る多くの困難がある。
【課題を解決するための手段】
【００１２】
本発明の実施形態は、１つのアプリケーション又は要素によるアクセスを、共通／ユニバーサルデータ構造を介して、事実上すべての他のアプリケーションのすべてのデータに対して提供するように構成されているシステム、方法、及びコンピュータプログラムプロダクトにまで及ぶ。一実施形態において、例えば、アプリケーションによるデータの要求は、１つ以上のプロキシの始動を含み得る。その１つ以上のプロキシは、別のアプリケーションのデータを共通データ構造の１つ以上のスキーマにマップすることができる。そして、要求するアプリケーションは、プロキシによって作成されて返信された（マッピング情報の）データ構造を介して、要求されたデータと情報のやり取りを行うことができる。その結果、アプリケーションがあらかじめ共通データ構造を必然的に認識しているか否かに関係なく、そして、アプリケーションが他のアプリケーションで使用された特定の型の構造に従って自身のデータを構成しているか否かに関係なく、システムの各アプリケーションは、相互利用することができる。
【００１３】
従って、全体的なシステムの観点からの方法は、１つ以上の異なるアプリケーションによって保持されたデータに対する１つ以上のアクセス要求をアプリケーションから受信することを含み得る。この場合、当該要求されたデータは１つ以上の異なる型の構造に対応する。また、方法は、前記１つ以上の異なるアプリケーションに対応する１つ以上のプロキシを識別することを含み得る。さらに、方法は、当該識別された１つ以上のプロキシを使用して、当該要求されたデータを共通データ構造にマップすることを含み得る。当該識別された１つ以上のプロキシは、当該要求されたデータを前記共通データ構造にマップするマップされたデータ構造を作成する。その上、方法は、当該マップされたデータ構造を前記要求するアプリケーションに提供することを含み得る。
【００１４】
さらに、アプリケーションの観点から方法は、１つ以上の異なる型の構造に対応するデータに対して１つ以上のアクセス要求を送信することを含む。また、方法は、当該要求されたデータと共通データ構造の１つ以上の構造型との間のマッピング情報を含む１つ以上のマップされたデータ構造を受信することを含む。さらに、方法は、１つ以上のマップされたデータ構造に対して１つ以上の動作を要求することを含み得る。この場合、当該要求された１つ以上の動作は、前記１つ以上の異なる型の構造の前記データに変換される。その上、方法は、前記１つ以上の要求された動作が前記１つ以上の異なる型の構造に対応する前記要求されたデータに対して完了した旨の１つ以上の確認を受信することを含み得る。
【００１５】
本概要は、発明の詳細な説明においてさらに後述する単純化した形態での概念の選択を導くために与えられている。この発明の概要は、特許請求の範囲に記載された発明の重要な特色若しくは本質的な特徴を特定することを目的としておらず、又は、特許請求の範囲に記載された発明の範囲を決定する際の補助手段として利用されることを目的としていない。
【００１６】
本発明の更なる特徴及び利点が以下の詳細な説明に部分的に記述されており、詳細な説明から部分的に明らかとなり、又はこの発明の実施によって理解されるであろう。本発明の特徴及び利点は、添付された請求の範囲において特に指摘された手段及び組合せによって認識され且つ得られるであろう。本発明のこれら特徴及び他の特徴は、以下の説明及び添付した請求の範囲から、より完全に明らかになるだろうし、又は、以下に詳細に説明するように、本発明の実施によって理解され得る。
【００１７】
本発明の上述の利点及び他の利点及び特徴が理解され得るように説明するために、簡単に上記説明された本発明のさらなる特定の説明が、添付図面に図示された特定の実施形態を参照することによって提供されるだろう。これら図面は本発明の典型的実施形態のみを示すものであり、本発明の範囲を限定するものとして考慮されるべきものでないことを理解すれば、本発明は、添付図面を使用してさらなる特異性及び詳細と共に、記述され且つ説明されるだろう。
【図面の簡単な説明】
【００１８】
【図１Ａ】１つ以上の異なる型の構造を実装する１つ以上のアプリケーションプログラムが共通のデータ構造を介して相互利用する本発明の実施形態に係る概要概略図である。
【図１Ｂ】プロキシがデータを共通のデータ構造にマップするように始動せしめられる図１Ａの概略図である。
【図２】アプリケーションが別のアプリケーションのデータをマップされたデータ構造を介して相互利用する図１Ａー図１Ｂの概略図である。
【図３】共通データ構造を使用して、データにアクセスするか若しくは異なる構造型のデータへのアクセスを提供するアプリケーションプログラム及び全体的なシステムの観点に基づく方法のフロー図である。
【発明を実施するための形態】
【００１９】
本発明の実施形態は、１つのアプリケーション又は要素によるアクセスを、共通／ユニバーサルデータ構造を介して、事実上すべての他のアプリケーションのすべてのデータに対して提供するように構成されたシステム、方法、及びコンピュータプログラムプロダクトにまで及ぶ。一実施形態において、例えば、アプリケーションによるデータの要求は、１つ以上のプロキシの始動を含み得る。その１つ以上のプロキシは、別のアプリケーションのデータを共通データ構造の１つ以上のスキーマにマップすることができる。そして、要求するアプリケーションは、プロキシによって作成されて返信された（マッピング情報の）データ構造を介して、要求されたデータと情報のやり取りを行うことができる。その結果、アプリケーションがあらかじめ共通データ構造を必然的に認識しているか否かに関係なく、そして、アプリケーションが他のアプリケーションで使用された特定の型の構造に従って自身のデータを構成したか否かに関係なく、システムの各アプリケーションは、相互利用することができる。
【００２０】
従って、及び、本明細書において完全に理解されるように、本発明の少なくとも１つの実施形態は、共通データ構造（若しくは「ユニバーサルデータモデル」）を提供することに関連する。共通データ構造／ユニバーサルデータモデルは、言い換えると、「アトム」、「シーケンス」、「レコード」、又は「オペレーション」に関して、システムのすべてのアプリケーションのデータをも定義し若しくは分類する。共通データ構造又は別のアプリケーションによって使用される型構造に従う所定のアプリケーションのデータが厳密に分類若しくは構成されていなくとも、この分類システムは、開発者がアプリケーションを開発しているポイントだけでなく、ランタイムにおいても、使用され得る。
【００２１】
したがって、このシステムは広く拡張可能であり得るし、多くの異なるフレームワーク内で存在し又は使用され得ることが十分理解されるだろう。例えば、本発明の実施形態は、共通言語ランタイム（「ＣＬＲ」：common language runtime）環境における使用のために、及び／又は、すべての特定の言語フレームワークに関しても、容易に構成され又は拡張され得る。例えば、本発明の少なくとも１つの実施形態は、ＸＭＬに基づくアプリケーションにも特に利用可能である。実際、基本的なデータのシェイプが何らかのポイントで決定され得る限り、事実上全ての言語若しくはランタイム環境が使用され得る。
【００２２】
図１Ａは、本発明の実施形態に係る概要概略図を示しており、その実施形態は、システム１００の１つ以上の異なるアプリケーション又は要素が共通データ構造を介して互いに情報のやりとりを行う。例えば、図１Ａは、１つ以上の処理モジュール１０５を含むシステム１００について図示しており、その１つ以上の処理モジュール１０５は共通データ構造（「ユニバーサルデータモデル」）１１０に対して１つ以上のリファレンスをさらに含む。少なくとも１つの実施形態において、システム１００は、ノミナル型の環境のサブスペース内で構成された一般化された構造型のシステムを含む。例えば、システム１００は、ＣＬＲベースのノミナル型環境内で実装される共通構造型のシステムを含み得る。
【００２３】
さらに、図１Ａは、共通データ構造１１０が１つ以上のスキーマを含み、その１つ以上のスキーマが、特定のデータ「シェイプ（shape）」に関連する特定の構造型及びスキーマを定義することを示している。また、本明細書において完全に理解されるように、データ「シェイプ」とは、共通データ構造１１０に関してデータ要素を広く分類するのに使用され得るデータ要素の基本的であり識別可能な特徴を意味している。例えば、図１Ａは、共通データ構造１１０が、データシェイプ１３５を有してオペレーションに対する構造型スキーマと、データシェイプ１４０を有してシーケンスに対する構造型スキーマと、データシェイプ１４５を有してレコードに対する構造型スキーマと、を含むことを示している。また、図１Ａは、共通データ構造１１０が「アトム」に対する構造型スキーマをさらに分類することを示しており、その「アトム」に対する構造型スキーマは本質的には未定義のデータシェイプ（すなわち、「---」）を有するものである。
【００２４】
一般に、「オペレーション」とは、個別又はすべてのセットの他の機能の一部にかかわらず、実行され又は処理されるときに結果を返信する関数又は引数であるとデータを識別するデータシェイプを有する１つ以上のデータ要素のあらゆるセットをも意味している。少なくとも１つの実施形態において、例えば、オペレーションは、本質的にはコアとして、データの呼び出しできるピースとして解釈され得る。ＣＬＲに関して、ＣＬＲインスタンスを共通データ構造１１０にマップする際に、「方法」及び「デリゲイト」はオペレーションとして解釈され得る。そのため、ＣＬＲ環境におけるオペレーションは、不特定数の「StructuredValue」パラメータを取って、「StructuredValue」を返すデリゲイトとして理解され得る。少なくとも１つの実施形態において、StructuredValueは、構造化された値を動作せしめるコードのインスタンスを分類するヘルパーとして提供される特定のノミナル型である。さらに、型StructuredValueは、構造化されたスペースに導入されている値を作動させると明確に予想するマーカ型としてＡＰＩ（アプリケーションプログラムインターフェイス）上で使用され得る。
【００２５】
さらに、「シーケンス」とは、本明細書において、値の１つ以上の（順不同の）集合のあらゆるセットのデータシェイプを有するデータをいう。ＣＬＲ環境に関し、例えば、シーケンスは「StructuredValues」の順不同の集合として理解され得る。一般に、シーケンスは、個別にラベル付けされていない値を含み、又は、ラベル若しくは名前が各値の単位で固有でないか若しくはシステム１００の観点からすれば集合の値を区別するには不十分である値を含む。
【００２６】
対照的に、レコードの値が１つ以上の固有のフィールド名等の１つ以上の固有のラベルに関連づけられる更なるシェイプの特徴を有することを除いて、「レコード」はシーケンスのような値の集合のシェイプを有するデータを含む。ＣＬＲ環境の少なくとも１つの実施形態において、例えば、レコードは、（自身が各々いくつかの「StructuredValue」である値を有する）１セットの名前を付されたメンバとして解釈され得るし、レコードが読み取り専用であるかを示すフラッグとして解釈され得る。したがって、かかる環境において、レコード及びシーケンスは、データシェイプを表現する主要な機構と解釈され得ることが十分理解され得る。
【００２７】
もちろん、上記の説明にもかかわらず、１つの特定のオペレーティングシステム若しくはアプリケーションプログラムにおいていくつかの特定的用法を有し得るすべての特定の要素、機能、又は動作環境に対する本明細書における言及は、描写的な利便性を目的としていることが十分理解されるだろう。特に、本出願の明細書及び請求の範囲から、本発明の実施形態が、広範な範囲の動作環境及びオペレーティングシステム、及び／又は、フレームワーク／環境において実施され得ることが十分理解できるだろう。したがって、特定のオペレーティングシステム又はアプリケーションプログラムに限定するものと解釈するべきでない。
【００２８】
いずれにせよ、図１Ａは、システム１００が１つ以上のアプリケーション又は要素１２０、１２５、及び１３５を含むことをも示す。その１つ以上のアプリケーション又は要素１２０、１２５、及び１３５は、本明細書により完全に説明されているように、共通データ構造１１０の利益を享受する。例えば、図１Ａは、アプリケーション１２０、１２５、及び１３０の各々がデータセット１２３、１２７、及び１３３をそれぞれ含む。それらデータセット１２３、１２７、及び１３３は共通データ構造１１０のスキーマの１つに対応してもよいし又は対応しなくてもよい。特に、図１Ａは、アプリケーション１２０がデータ要素Ａ、Ｂ、及びＣを含むデータセット１２３を含むことを示している。この場合、データ要素Ａ、Ｂ、及びＣは、対応するデータシェイプ１３５、１４０、及び１４５に少なくとも部分的にそれぞれ基づいて、オペレーション、シーケンス、又はレコードの構造型にそれぞれ対応している。
【００２９】
対照的に、図１Ａは、型構造とデータシェイプが共通データ構造１１０に関して明確に定義されないものの、アプリケーション１２５及び１３０がデータセットをも含むことをも示している。例えば、図１Ａは、アプリケーション１３５がデータ要素Ｄ、Ｅ、及びＦに関するデータセット１２７を含むことを示している。これらのうち、データ要素Ｄだけが、データシェイプ１３５に基づいて「オペレーション」の構造型に対応することが知られている。特に、図１Ａは、データ要素Ｅがデータシェイプ１４５を有し、Ｅが特定の構造型にまだ関連づけられていないことを示している。同様に、データ要素Ｆは、構造型に関連づけられておらず、既知のデータシェイプを含まない。
【００３０】
さらに、図１Ａは、アプリケーション１３０がデータ要素Ｇ、Ｈ、Ｉ、及びＪを含むデータセット１３３を含むことを示している。これらのうち、データ要素Ｇ、Ｈ、及びＩはそれぞれ識別可能なデータシェイプ１４０、１３５、及び１４５を有する。しかしながら、図示されているように、データ要素Ｉのみがレコードの構造型に対応するものと識別されている。その上、図１Ａは、データ要素Ｊが、識別された構造型も、容易に識別可能なデータシェイプをも有しないことを示している。
【００３１】
したがって、（アプリケーション１２０に比較された）アプリケーション１２５及び／又は１３５の種々のデータ要素における構造／型の観点から識別される差異は、いくつかの因子に依存し得ることが十分理解されるだろう。アプリケーション１２０に関して、例えば、開発者は、共通データ構造１１０及び要求されたスキーマの知識を考慮して、アプリケーション１２０を作成したかもしれないし、適切な構造型を有するデータ要素Ａ、Ｂ、及びＣを宣言したかもしれない。したがって、アプリケーション１２０のインストールの際に、処理モジュール１０５は、データ要素Ａ、Ｂ、及びＣの各々が共通データ構造１１０の図示された型及びデータシェイプに対応することを直ちに識別するように構成され得る。
【００３２】
対照的に、アプリケーション１２５及び／又は１３０の開発者は、特定の明確に定義されたデータシェイプを使用して、初めにアプリケーション１２５及び／又は１３０を作成したかもしれないし、他の異なる型のフレームワークに基づいて特定の構造型を宣言したかもしれない。したがって、インストールの際に、又は、データがシステム１００によって識別された他のいくつかのポイントにおいて、アプリケーション１２５及び１３０が、共通データ構造１１０に対応する型構造の識別を具体的に提供してはいないかもしれない（又は、システム１００は型構造を識別しなかった）。あるいは、アプリケーション１２５及び１３０は、共通データ構造１１０を考慮して開発されたかもしれないものの、何らかの理由のために、データ要素Ｄ−Ｊは処理モジュール１０５によって未だ識別されておらず、又は、特定の構造型に関連付けられていない。
【００３３】
一般に、構造の型が特定のデータ要素に関連づけられ得る多くの方法がある。例えば、その関連付けられた型構造とデータ要素のシェイプとをインストール等の際に処理モジュール１０５に対して発行するように、アプリケーションは構成され得る。同様に、アプリケーションは、所定のアプリケーションによって管理されたデータ（すなわち、データセット１２３）が共通データ構造１１０に一致することを識別する１つ以上のメッセージを用いて、（例えば、インストール中又はランタイム中に）処理モジュール１０５に単に応答し得る。しかしながら、本発明の少なくとも１つの利点は、１つ以上のプロキシ（例えば、１６５、１７０、１７５）を使用して、この情報の多く又はすべてがランタイムにて判断され得るということである。例えば、図１Ａは、システム１００がプロキシのレジストリ１１５を含み。そのプロキシのレジストリ１１５は、この場合、アプリケーション１２０に基づいたプロキシ１６５を少なくとも含むことを示している。また、図１Ａは、レジストリ１１５がアプリケーション１２５に基づくプロキシ１７０、及びアプリケーション１３０に基づくプロキシ１７５を含むことを示している。
【００３４】
単に説明として、「プロキシ」とは、システム１００において呼出され且つ特定のアプリケーションと連動させるのに使用される１つ以上のコンピュータ実行可能命令のセットを意味する。一実施形態において、これらプロキシは、既にコンパイルされて実行可能な命令として存在し得る。その既にコンパイルされて実行可能な命令は、事実上いつでも呼出しされ得る。しかしながら、さらなる実施形態又は代替実施形態において、これらプロキシは、システム１００によって提供され且つ呼出される場合に最初にコンパイルされて実行される中間言語コードの形態を含み得る。いずれの場合においても、プロキシは、所定のアプリケーションプログラムに適切な特定のプログラム言語で作成されたようなアプリケーションに特有なものであり得ることが十分理解されるだろう。例えば、所定のプロキシは、特に、ＸＭＬ、ＳＱＬ、Ｌｉｓｐ等で作成されたプログラムに対して構成され得る。ＣＬＲに基づく少なくとも１つの実施形態において、例えば、「ClrStructureServices」として知られているプロキシは、「StructuredValues」に対してＣＬＲインスタンスを表すように構成され得る。
【００３５】
これらプロキシは、アプリケーション開発者によって作成され得るし、又は、システム１００によって単に提供され得る。例えば、（アプリケーション１２０、１２５、１３０等の）アプリケーション開発者は、所定のアプリケーションに特有の１つ以上のプロキシを準備し得るし、アプリケーションのインストールの際にそのプロキシを登録し得る。ある場合には、いくつかの開発者にとって、この事は望ましいかもしれない。アプリケーション開発者は、プロキシがデータ要素を未定義の「アトム」として過度に分類することを避けることを確実になすより良い立場にあり得るからである。しかしながら、他の場合において、アプリケーション開発者は、共通データ構造１１０の構造型内で定義されたシェイプに少なくとも部分的に一致するそれらデータを準備し得るし、そういうものとして、開発者はデフォルトのプロキシを使用するという利便性を選択してもよい。
【００３６】
一般に、実行されると、所定のプロキシがアプリケーション（１２０、１２５、１３０等）によって保持された１つ以上のデータ構造又は要素にトラバースするように、各プロキシが構成されている。トラバースの際に、プロキシは、様々なデータ要素の「シェイプ」を識別するように最小限で構成される。上記から分かるように、これは、アプリケーションによって保持されたデータ要素が、ある最小のプロパティ（例えば、結果を返す）に従う機能又は引数であるか否かをプロキシコードが識別するように通常構成されるだろうということを意味している。本明細書に記載されるように、共通データ構造１１０のスキーマに対して、あるデータ要素が値の集合を形成するか否か、及び／又は、それら値がシーケンス若しくはレコードとしてデータ要素を分類し得る付加的ラベリングを含むか否かを識別するように、同一のプロキシは構成されるだろう。
【００３７】
図１Ｂは、システム１００が、１つ以上のプロキシの幇助により、１つ以上のアプリケーション１２５及び１３０内のデータに対するアクセスをアプリケーション１２０に提供する概要概略図を示している。例えば、図１Ｂは、アプリケーションプログラム１２０が、１つ以上のデータアクセス要求１８０を送信して、アプリケーション１２５によって保持されたデータのアクセスを要求することを示している。この要求は、処理モジュール１０５を介する等して、システム１００によって処理される。要求は、（アプリケーション１２０と比べて）異種の／互換性がない型の構造に対応するデータを含むので、図１Ｂは、処理モジュール１０５がプロキシレジストリ１１５に問い合わせて、いかなるプロキシがアプリケーション１２５の型構造を共通データ構造１１０にマップするのに使用されるべきであるかを識別することを示している。従って、図１Ｂは、処理モジュール１０５は、プロキシ１７０がアプリケーション１２５と相関することを識別し、要求１８５を介してプロキシ１７０を（すなわち、実行時間中に）始動することを示している。
【００３８】
さらに、図１Ｂは、プロキシ１７０がアプリケーション１２５に関して初期化されることを示している。少なくとも１つの実施形態において、プロキシ１７０は異なるデータ要素Ｄ、Ｅ、Ｆ等の各々に行き来し始める。これは、利用可能な全ての構造型の同一性を識別し、且つ／又は各データ要素のデータシェイプを識別することを目的とする。少なくとも１つの実施形態において、例えば、プロキシ１７０は、データ要素Ｄが共通データ構造１１０に対する構造型フレームワーク内で理解されるようなオペレーションを含むことを識別する。さらに、プロキシ１７０は、データ要素Ｅがデータシェイプ１４５を有することを判断し得る。そのデータシェイプ１４５は、共通データ構造１０５のレコードに対する構造型に使用されるシェイプと一致する。その上、プロキシ１７０は、データシェイプのすべての構造型がデータ要素Ｆと同一であると識別し得ないので、データ要素Ｆをアトムとして割り当てる。
【００３９】
データ要素に関してこのトラバース及びマッピングを終了する際に、プロキシ１７０は１つ以上のデータ構造を返信する。その１つ以上のデータ構造は、トラバースされた（又は要求された）データ要素を共通データ構造にマップする。例えば、図１Ｂは、プロキシ１７０が処理モジュール１０５を介してマップされたデータ構造１９５を送信することを示している。処理モジュール１０５はマップされたデータ構造１９５をアプリケーション１２０に送る。さらなる実施形態又は代替実施形態において、処理モジュール１０５は、マップされたデータ構造１９５が作成されていることを示すメッセージをアプリケーション１２０に単に返信し、さらに、アプリケーション１２０がマップされたデータ構造１９５にアクセスするのに使用することができる１つ以上のレファレンスを提供する。そして、アプリケーション１２０は、マップされたデータ構造１９５に関するマッピングを使用して、アプリケーション１２５におけるデータに対して１つ以上の動作を実行する。
【００４０】
例えば、図２は、アプリケーション１２０が、マップされたデータ構造１９５を介してアプリケーション１２５のデータを相互利用する少なくとも１つの例を示している。例えば、図２は、マップされたデータ構造１９５が、共通データ構造スキーマとアプリケーション１２５のデータ要素との間のマッピング若しくは相関情報を含むことを示している。特に、図２は、マップされたデータ構造１９５が、データ要素Ｄをオペレーションとして定義し若しくは関連付けるマッピング２１０を含むことを示している。さらに、図２は、マップされたデータ構造が、データ要素Ｅをレコードとして定義し若しくは関連付けるマッピング２２０、及び、データ要素Ｆをアトムとして定義し若しくは関連付けるマッピング２３０を含むことを示している。そして、アプリケーション１２０は、これら種々のマッピングを参照することによって、アプリケーション１２５のデータを操作し若しくは使用することができる。
【００４１】
例えば、図２は、アプリケーション１２０が要求２００を処理モジュール１０５に送信することを示している。この場合、要求２００は、レコードＥを「Ｅ´」に変更して、レコードＥを作成する要求を含む。この要求を処理するために、図２は、処理モジュール１０５が、マップされたデータ構造１９５に対するリファレンスを介して要求２００を処理することを示している。一実施例において、これは、処理モジュール１０５が要求２００をマッピング情報と結合し、新たな要求（若しくは変更された形態の要求２００）をアプリケーション１２５に送信することを意味している。例えば、図２は、処理モジュール１０５が要求２４０をアプリケーション１２５に送ることを示している。アプリケーション１２５は、要求２４０に含まれるマッピング情報２２０を理解しているので、アプリケーション１２５は、アプリケーション１２０からのデータ要素Ｅを変更するという要求を理解し、処理し得る。
【００４２】
そういうものとして、アプリケーション１２５は要求を処理し、通信チャネルを介して確認を送り返す。例えば、図２は、アプリケーション１２５が、データ要素Ｅが要求された通りＥ’に変更されたことを確認する応答２５０を準備し且つ送信することを示している。一実施例において、これは、メッセージ２５０を処理モジュール１０５に送信することを含み、そして、処理モジュール１０５がメッセージをアプリケーション１２０に転送する。その結果、アプリケーション１２０は、アプリケーション１２５によって使用された型コンベンションに関する詳細な知識を有することなく、アプリケーション１２５によって管理された１つ以上のデータ要素を操作した。
【００４３】
従って、図１Ａ、１Ｂ、及び２は、データにおける特定の構造型の割り当てに実質的に関係なく、アプリケーション間でデータを処理する多くの異なる概略図、要素、及び図を示している。むしろ、アプリケーションが互いを相互利用するために、考慮されなければならないすべてが、データの最も基本的なシェイプである。強くシェイプ付けされたシステムの重要な性能及びセキュリティ上の利点を保持するにもかかわらず、柔軟にシェイプ付けされたシステムには通常一般的であるような（すなわち、特定の型のコンベンションを懸念する必要なく）極めて高い柔軟性が、これにより開発者に提供され得ることが十分理解されるだろう。
【００４４】
前述に加えて、また、本発明の実施形態は、特定の結果を達成する１つ以上の動作を含む方法に関して、説明され得る。例えば、図３は、共通データ構造を使用して異なる構造の型に対応するデータにアクセスするか若しくはデータへのアクセスを提供する。図１Ａから図２の要素及び図に関して図３に示された動作について説明する。
【００４５】
例えば、図３は、アプリケーション１２０の観点からの方法が、データアクセス要求を送信する動作３００を含み得ることを示している。動作３００は、１つ以上の異なる型の構造に対応するデータに対して１つ以上のアクセス要求を送信することを含む。例えば、図１Ｂに示されているように、アプリケーション１２０は、アクセス要求１８０を処理モジュール１０５に送信する。同様に、要求１８０は、別のアプリケーション（例えば、１２５）によって保持されたいくつかのデータのアクセス又は操作を含む。その別のアプリケーション（例えば、１２５）は、別の型の構造（若しくは明確に定義されていない型の構造）を使用している。
【００４６】
また、図３は、アプリケーション１２０の観点からの方法が、データを共通データ構造にマップするデータ構造を受信する動作３１０を含み得ることを示している。動作３１０は、当該要求されたデータと共通データ構造との間のマッピング情報を含む１つ以上のデータ構造を受信することを含む。例えば、図１Ｂに示されているように、アクセス要求１８０を受信する際に、処理モジュール１０５は、１つ以上の要求１８５を送信して、プロキシ１７０を始動する。そして、プロキシ１７０はアプリケーション１２５におけるデータ構造に行き来して、様々なデータシェイプが識別されることができる程度に、識別して、マップされたデータ構造１９５を返信する。そのマップされたデータ構造１９５は、要求されたデータを共通データ構造１１０に相互に関連付ける。
【００４７】
さらに、図３は、アプリケーション１２０の観点からの方法が、受信されたデータ構造を介して要求されたデータに対してオペレーションを実行する動作３２０を含み得ることを示している。動作３２０は、１つ以上のデータ構造に対して１つ以上の動作を要求することを含み、当該要求された１つ以上のオペレーションは、１つ以上の異なる型の構造に対応する。例えば図２に示されているように、アプリケーション１２０は、データ構造１９５におけるデータ要素ＥをＥ´に変更する要求を含む要求２００を処理モジュール１０５に送信する。そして、この要求はマップされたデータ構造１９５及びメッセージ２４０を介して転送され、アプリケーション１２５を介して続いて処理される。
【００４８】
その上、図３は、アプリケーション１２０の観点からの方法が、オペレーションが完了していることを確認する動作３３０を含み得ることを示している。動作３３０は、前記１つ以上の要求された動作が前記１つ以上の異なる型の構造に対応する前記要求されたデータに対して完了した旨の１つ以上の確認を受信することを含む。例えば、図２は、データ要素Ｅに対応するレコードがＥ´に変更されたことを確認するアプリケーション１２５が、１つ以上の確認応答２５０をアプリケーション１２０に送り返すことを示している。
【００４９】
前述に加えて、図３は、全体的なシステム１００の観点からの方法が、異なる型の構造に対応するデータを要求するアクセス要求を受信する動作３４０を含み得ることを示している。動作３４０は、１つ以上の異なるアプリケーションによって保持されたデータに対する１つ以上のアクセス要求をアプリケーションから受信することを含み、当該要求されたデータは１つ以上の異なる型の構造に対応する。例えば、図１Ｂは、システム１００が、処理モジュール１０５を介して、アプリケーションプログラム１２０から要求１８０を受信して、アプリケーション１２５のデータにアクセスすることを示している。この場合は、少なくとも１つのデータ要素がアプリケーション１２５に対して定義されるものの、他のデータ要素のいくつかは特定の構造型を有しておらず且つデータシェイプ（例えば、データ要素Ｅ）のみ有する。
【００５０】
また、図３は、システム１００の観点からの方法が、異なる型の構造に対する対応するプロキシを識別する動作３５０を含み得ることを示している。動作３５０は、前記１つ以上の異なるアプリケーションに対応する１つ以上のプロキシを識別することを含む。例えば、図３は、処理モジュール１０５が、要求１８０を受信する際に、プロキシ１７０がアプリケーション１２５と相関することをレジストリ１１５において識別し、１つ以上の要求１８５を送信して、プロキシ１７０を始動することを示している。
【００５１】
さらに、図３は、システム１００の観点からの方法が、当該要求されたデータを共通データ構造にマップする動作３６０を含み得ることを示している。動作３６０は、当該識別された１つ以上のプロキシを使用して、当該要求されたデータを共通データ構造にマップすることを含み、当該識別された１つ以上のプロキシはマップされたデータ構造を作成する。例えば、プロキシ１７０はデータ要素に行き来し、例えば、どのデータシェイプが、共通データ構造１１０のどの構造型に対応するのかを識別する。そして、プロキシ１７０は、マッピング情報を含むデータ構造１９５を作成する。そのマッピング情報は、要求されたデータ要素を共通データ構造の構造型に関連付ける（又は指定する）。
【００５２】
その上、図３は、システム１００の観点からの方法が、マッピング情報を含むデータ構造を共通データ構造に送信する動作３７０を含むことを示している。動作３７０は、当該マップされたデータ構造を前記要求するアプリケーションに提供することを含む。例えば、図１Ｂに示されているように、処理モジュール１０５はマップされたデータ構造１９５をアプリケーション１２０に送信する。上述したように、アプリケーション１２０は、マップされたデータ構造１９５に適切にマップされたアプリケーション１２５におけるデータのいずれも操作することができる。
【００５３】
従って、図１−３及び対応する本文は、種々のアプリケーションが異なる型のフレームワークで構築され得るものの、それらアプリケーションが互いのデータにアクセスし得ることを確実になす多くの要素及び機構を提供する。先に説明したように、本発明の少なくとも１つの利点は、開発者が特定の型のコンベンションよりむしろデータシェイプに対する考慮を主に依存することができるということである。型コンベンションを時々変更することよりも、データシェイプに関して集中することによって、旧来の若しくは新規な型のフレームワークで構築されたアプリケーションは、多数のオペレーションを享有することが可能となる。
【００５４】
本発明の実施形態は、以下でさらに詳細に説明するように、種々のコンピュータハードウェアを含む専用若しくは汎用のコンピュータを含み得る。また、本発明の範囲内の実施形態は、コンピュータ実行可能命令又はデータ構造を転送し若しくは有するコンピュータ読取可能媒体を含む。かかるコンピュータ読取可能媒体は、汎用若しくは専用コンピュータによってアクセスされ得る全ての利用可能な媒体であり得る。
【００５５】
限定ではなく、実施例として、かかるコンピュータ読取可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、他の光ディスク記憶装置、磁気ディスク記憶装置、他の磁気記憶装置、又はいかなる他の媒体を含み得る。その他の媒体は、コンピュータ実行可能命令又はデータ構造の形態で所望のプログラムコード手段を転送し又は記憶するのに使用され得るし、汎用若しくは専用コンピュータによってアクセスされ得る。（配線接続、ワイヤレス、又は配線接続若しくはワイヤレスの組み合わせのいずれかの）ネットワーク又は別の通信接続上に情報がコンピュータに転送されるか又は提供されるとき、コンピュータは接続をコンピュータ読取可能な媒体であると適切にみなす。したがって、すべてのかかる接続はコンピュータ可読媒体と適切に称されている。上記組み合わせも、コンピュータ可読媒体の範囲内に含まれるべきである。
【００５６】
コンピュータ実行可能命令は、汎用コンピュータ、専用コンピュータ、又は専用処理デバイスに特定の機能又は一群の機能を実行せしめる命令及びデータを例えば含む。本発明は、構造の機能及び／又は方法の動作に対して特定の言語によって説明されてきたが、添付した特許請求の範囲において画定された本発明は、上述した特定の特徴又は動作に必ずしも制限されるというわけではないことが理解されるべきであり、むしろ、上述した特定の特徴又は動作は特許請求の範囲を実装する典型的な形態として開示されている。
【００５７】
本発明は、その精神又は本質的な特徴より出発することなく、他の形態により具体化され得る。上述した実施形態は、すべての点において単なる実例として考慮されるべきであり、限定するものではないと考慮すべきである。それゆえに、本発明の範囲は、前述した説明ではなく、添付した特許請求の範囲に示されている。本特許請求の範囲と均等の意味であり且つ本特許請求の範囲の範囲内にあるすべての変更が、特許請求の範囲に含まれるものとする。
【図１Ａ】
0005400068.tif 000002
【図１Ｂ】
0005400068.tif 000003
【図２】
0005400068.tif 000004
【図３】
0005400068.tif 000005