(57)【要約】  公称型フレームワークは、共通の型シェイプ又は構造の最小のセットに基づいて、異なる公称型を共に効率的に相関させるよう構成できる。ある実装において、開発者は興味のある多くの異なる公称型（ソースの型）を特定し、アプリケーションプログラムによりアクセスされる共通の型シェイプの最小のセットを特定する。共通の型シェイプの最小のセットはその後、他の異なるソースの型のそれぞれをマップできる中間型（対象の型）を生成するのに使用できる。例えば、１以上プロキシを生成でき、これは１以上のソースの型のシェイプを生成された対象の型の対応するシェイプにマップする。次に、開発者により生成されたアプリケーションプログラムは、単一の対象の型を通して、異なるソースの型のそれぞれのマップされたデータにアクセス、動作又は使用できる。
2011514596.tif 000002
【特許請求の範囲】
【請求項１】
１以上のアプリケーションプログラム（１０３、１０５、１０７）により使用される公称型フレームワーク（１００）及び１以上の公称的に互換性のない型（１１０、１２０、１３０）を実装するオブジェクト指向のコンピューター化されたシステムにおいて、前記アプリケーションプログラムによる前記１以上の公称的に互換性のない型に関連付けられたデータへのアクセスを自動的に提供する方法であって、
アプリケーションプログラム（１０３）により使用される対象の型（１１０）の１以上の必要な型シェイプ（１１５、１１７）を特定するステップ（２００）と、
前記対象の型の前記１以上の必要な型シェイプ（１１５、１１７）を含む、対応する１以上の公称的に互換性のないソースの型（１２０、１３０）を有する１以上の異なるアプリケーションプログラム（１０５、１０７）を特定するステップ（２１０）と、
１以上の命令（１５３）を受信して、前記対象の型を使用して前記アプリケーションプログラム（１０３）を実行するステップ（２２０）と、
前記アプリケーションプログラムの実行の後、１以上のプロキシ（１６５、１７０、１７５）を使用して、前記公称的に互換性のない型における前記必要な型シェイプに関連付けられたデータに対する、前記アプリケーションプログラム（１０３）による１以上のアクセス要求を処理するステップ（２３０）と
を備えたことを特徴とする方法。
【請求項２】
ランタイムにおいて前記対象の型を表す中間型（１５５）を生成するステップをさらに備え、前記中間型は、前記特定された１以上の必要な型シェイプ（１１５、１１７）を備えたことを特徴とする請求項１に記載の方法。
【請求項３】
ランタイムにおいて前記特定された１以上の公称的に互換性のないソースの型（１２０、１３０）について、前記１以上のプロキシ（１６５、１７０）を自動的に生成するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項４】
１以上のプロキシ（１６５、１７０）のそれぞれがメモリ内データ構造を備えたことを特徴とする請求項３に記載の方法。
【請求項５】
各プロキシ（１６５、１７０）が、前記１以上の異なるアプリケーションプログラム（１０５、１０７）の少なくとも一つに関連付けられていることを特徴とする請求項３に記載の方法。
【請求項６】
前記１以上のプロキシ（１６５、１７０）の少なくとも１つが、アプリケーションプログラムにまだ関連づけられていないデータ構造のバックエンドのデータストア（１８０）に関連づけられることを特徴とする請求項３に記載の方法。
【請求項７】
前記１以上のプロキシ（１６５、１７０）のそれぞれが、前記特定されたソースの型における前記１以上の必要な型シェイプ（１１５、１１７）を、前記対象の型における前記同じ型シェイプにマップすることを特徴とする請求項３に記載の方法。
【請求項８】
前記１以上のアクセス要求を処理するステップ（２３０）は、
第１のアプリケーション（１０３）からの要求を受信して、公称的に互換性のない型（１２０）に対応するデータにアクセスするステップと、
前記要求に対して自動的に生成されたプロキシ（１６５）を特定するステップと
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項９】
前記第１のアプリケーション（１３０）からの前記データアクセス要求は、前記公称的に互換性のない型（１２０）に対応する前記データの読み込み又は書き込み修正の少なくとも１つを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記要求を処理する、前記自動的に生成されたプロキシ（１６５）に要求を渡すステップと、
前記アクセスを処理した、前記自動的に生成されたプロキシ（１６５）から１以上の確認を受け取るステップと
をさらに備えたことを特徴とする請求項８に記載の方法。
【請求項１１】
バックエンドのデータストア（１８０）から、１以上の異なるアプリケーションプログラム（１０５、１０７）のうちの１つにより管理されるデータストアに、要求を通して修正されたデータ構造を渡すステップをさらに備えたことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記対象の型の前記１以上の必要な型シェイプ（１１５、１１７）の特定は、前記アプリケーションプログラムがインストールされると起こることを特徴とする請求項１に記載の方法。
【請求項１３】
前記システムにおける他の任意の既存の型と公称的に互換性のない別の型を使用する別のアプリケーションプログラムのインストールを特定するステップと、
前記他の公称的に互換性のない型と前記システムに存在するアプリケーションに対応する前記既存の型との間で共通である１以上の新しい型シェイプを特定するステップと
をさらに備えたことを特徴とする請求項１２に記載の方法。
【請求項１４】
ランタイムにおいて、新しくインストールされた前記アプリケーションプログラムについて、前記１以上の新しい型シェイプを前記システム内の１以上の前記既存の型における対応する型シェイプにマップする１以上の新しいプロキシを生成するステップと、
前記１以上の新しいプロキシを使用して、前記存在するアプリケーションにより管理されるデータ構造上で、前記新しくインストールされたアプリケーションプログラムによる１以上のアクセス要求を処理するステップと
をさらに備えたことを特徴とする請求項１３に記載の方法。
【請求項１５】
１以上のアプリケーションプログラム（１０３、１０５、１０７）により使用される公称型フレームワーク（１００）及び１以上の公称的に互換性のない型（１１０、１２０、１３０）を実装するオブジェクト指向のコンピューター化されたシステムにおいて、前記アプリケーションプログラムにより、前記１以上の公称的に互換性のない型に関連付けられたデータへのアクセスを自動的に提供する方法であって、
前記システムにインストールされたアプリケーションプログラム（１０３）により使用される型（１１０）の１以上の必要な型シェイプ（１１５、１１７）を特定するステップ（３００）と、
１以上の異なるアプリケーションプログラム（１０５、１０７）により使用される前記１以上の公称的に互換性のないソースの型（１２０、１３０）において、前記１以上の必要な型シェイプ（１１５、１１７）を特定するステップ（３１０）と、
前記アプリケーションプログラム（１０３）により使用される前記型（１１０）の表示を備えた中間型（１５５）を自動的に生成するステップ（３２０）と、
前記１以上の公称的に互換性のない型（１２０、１３０）の前記１以上の必要な型シェイプを前記生成された中間型（１５５）に相関させる１以上のプロキシ（１６５、１７０）を自動的に生成するステップ（３３０）と
を備えたことを特徴とする方法。
【請求項１６】
前記生成されたプロキシ（１６５、１７０）を通して、前記１以上のソースの型（１２０、１３０）における前記特定された１以上の型シェイプ（１１５、１１７）に対して、新しくインストールされたアプリケーションによる１以上のアクセス要求を処理するステップをさらに備えたことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記１以上のアクセス要求は、前記システム内の別のアプリケーションにより管理された公称的に互換性のない型に対応する１以上のデータ構造への修正又は書き込みの要求を含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記１以上のプロキシ（１７５）の少なくとも１つは、前記１以上の必要な型シェイプを一時的なデータストア（１８０）に対応する新しい型（１８５）にマップすることを特徴とする請求項１５に記載の方法。
【請求項１９】
新しいデータ構造を生成する要求を受信するステップと、
前記データストア（１８０）についての前記１以上のプロキシ（１７５）を使用して、前記要求を処理するステップと、
前記データストアから前記１以上の異なるアプリケーションプログラム（１０３、１０５、１０７）のうちの１つに、前記新しいデータ構造の制御を渡すステップと
をさらに備えたことを特徴とする請求項１８に記載の方法。
【請求項２０】
１以上のアプリケーションプログラム（１０３、１０５、１０７）により使用される公称型フレームワーク（１００）及び１以上の公称的に互換性のない型（１１０、１２０、１３０）を実装するオブジェクト指向のコンピューター化されたシステムにおいて、実行されると、コンピューター化されたシステムにおける１以上のプロセッサーに、
アプリケーションプログラム（１０３）により使用される対象の型（１１０）の１以上の必要な型シェイプ（１１５、１１７）を特定するステップ（２００）と、
前記対象の型の前記１以上の必要な型シェイプ（１１５、１１７）を含む、対応する１以上の公称的に互換性のないソースの型（１２０、１３０）を有する１以上の異なるアプリケーションプログラム（１０５、１０７）を特定するステップ（２１０）と、
１以上の命令（１５３）を受信して、前記対象の型を使用して前記アプリケーションプログラム（１０３）を実行するステップ（２２０）と、
前記アプリケーションプログラムの実行の後、１以上のプロキシ（１６５、１７０、１７５）を使用して、前記公称的に互換性のない型において前記必要な型シェイプに関連付けられたデータに対する、前記アプリケーションプログラム（１０３）による１以上のアクセス要求を処理するステップ（２３０）と
を実行させるためのコンピューター実行可能な命令を有するコンピュータープログラムのストレージ製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、公称的に互換性のない型を効率的に相関させることに関する。
【背景技術】
【０００２】
コンピューター化されたシステムが一般に増加してきたので、様々なアプリケーションプログラム及び文書がコンピューター化されたシステム上で使用されてきた。特に、今やあらゆる目的のために構成された広い範囲のアプリケーションプログラムが存在し、複合的なオペレーティングシステム、データベース等として機能するか、又は狭い目的のために構成されたより単純なアプリケーションプログラムとして機能するかである。多くの場合において、ソフトウェア開発者は、あらゆる適切なアプリケーションプログラム言語を使用して、特定のオペレーティングシステム／フレームワークを考慮して新しいアプリケーションプログラム書くこととなる。ソフトウェアが完成すると、開発者はアプリケーションをコードにコンパイルすることになり、これはその後に適切なオペレーティングシステムでコンピューターシステム上にインストールできる。多くの場合において、新しいアプリケーションプログラムを動作させることは、システム／フレームワークにおける多くの他のコンポーネント又はアプリケーションとの相互動作を引き起こすこととなる。
【０００３】
従って、オペレーティングシステム又は汎用化されたフレームワークの開発者だけでなくフレームワーク内で動作している個々のアプリケーションプログラムの開発者も、多くの場合考慮すべきたくさんの検討事項があることを理解されたい。これらの興味の多くは競合さえするかもしれない。例えば、多くのアプリケーションプログラムの開発者は、早くそしてカスタマイズ可能な動作に関して興味を有するかもしれない一方で、多くのオペレーティングシステム／フレームワーク開発者はセキュリティ及び安定性に興味を有するかもしれない。あるケースでは、セキュリティ及び安定性の要件は、いくつかのアプリケーションプログラムが動作する方式のスピード及びカスタマイズ可能性を制限する可能性がある。
【０００４】
この対立が顕著になり得る１つの分野が、ある種の「型フレームワーク」に関する分野である。型フレームワークでは、関数、引数及びデータ値さえも、特定の「型（ｔｙｐｅ）」に相関し得る。「型」は、別のアプリケーション又はコンポーネントが、対応するデータにアクセス／処理できる前に、どのように様々なデータ（つまり、関数、引数又は値）が現れる必要があるかを一般に定義する。強い型フレームワークを採用するシステムでは、ある型フレームワークを使用するアプリケーション又はコンポーネントが他の型フレームワークに対応する関数及びデータを実行する又はアクセスすることを禁止するように、構成され得る。フレームワークのいくつかの例は、公称型（ｎｏｍｉｎａｌ又はｎｏｍｉｎａｔｉｖｅ）及び構造型（ｓｔｒｕｃｔｕａｌ）の型フレームワークを含むが、異なる種類の型フレームワークも含み得る。
【０００５】
一般に、公称型フレームワークは、ある公称型におけるデータが（いくつかの公称型の）まったく同じ型名を使用する他のデータにのみアクセスできる（またはアクセスされる）か、又は生成／コンパイルについて知っている型名にアクセスする（又はアクセスされる）ように構成され、逆の場合も同様である。従って、型構造が同一であったとしても、「顧客レコード」と呼ばれる型名（ｔｙｐｅ ｎａｍｅ）を使用するあるアプリケーションは、「メンバーレコード」と呼ばれる型名の下で別のアプリケーションプログラムにより管理された同様のデータにアクセスすることを、両方の型が互いに気付いていない場合は、禁止されるかもしれない。例えば、顧客レコードの公称型及びメンバーレコードの公称型の両方が等しい数及び種類のフィールドを含む（例えば、ファーストネーム＝「文字列（ｓｔｒｉｎｇ）」及びセカンドネーム＝「文字列」を含むセット等）、構造的な同一性が起こる恐れがある。対照的に構造型フレームワークは、名前よりむしろ、データ構造又はシェイプの間の一致に依存する。構造型は不正確な型名に限定されない一方で、型の１つが別の型より多くの又は異なる種類の構造／シェイプを含むとき（例えば、ファーストネーム＝「文字列」、セカンドネーム＝「文字列」及び電話番号＝値を含むメンバーレコード）に、構造的な不一致が起こりうる。
【０００６】
多くの場合、公称型及び構造型を含む、様々な異なる型間での不一致に対する様々な回避策があり、アプリケーションは相互動作できる。例えば、公称型フレームワーク内で、開発者は、ある公称型における型構造を別の公称型における同一の型構造にマップ又は変換することに興味のあるそれぞれのアプリケーションのための新しいコードを書くことができる。不一致の型構造間での同様の回避策も可能だが、このような構造型の変換はより複雑になる傾向にある。例えば、ＬＩＳＰプログラミング言語はある共通で従来型の構造型フレームワークを実装し、その基本構造はデータのペアである。従って、別のアプリケーションプログラムのデータを使用するために、ＬＩＳＰベースのアプリケーションは、一般的に他のアプリケーションにおけるデータ構造をデータのペア構造に変換する必要があるが、これは難しい可能性がある。
【０００７】
同様に、ＬＩＳＰのデータのペア構造から別のアプリケーションにおける別の型構造に変換することは難しい可能性がある。どのようにデータをＬＩＳＰにおいて編成するかの違いだけでなく、多くの場合、ＬＩＳＰのデータのペアの値は計算コストをかけずに解明することが難しいので、データのペアを完全に走査することも事実である。これは、ＬＩＳＰのデータのペアが「シーケンス」である以外に、基本のクエリを介して十分な情報を提供しない傾向にあることも理由の一つである。しかし、ＬＩＳＰのプログラミングのフレームワークだけが、異なる型構造での問題が生じ得る唯一の言語ではない。それぞれがそれら自身の異なる型フレームワークを使用する他の共通言語は、ＸＭＬ、ＳＱＬ、．ＮＥＴ及びＪＡＶＡ（登録商標）があり、相互動作は同じ型変換を意味する場合が多い。
【０００８】
従って、アプリケーションプログラム間の相互運用性を保証する一つの方法は、同様のプラットフォーム上で働くアプリケーション開発者が、規定どおりに、公称及び／又は型の詳細に前もって合意することである。当然、このような厳格及び緻密な合意が常に可能なわけではなく、後に同じシステムで使用されるコンポーネントを生成し得る他の開発者に対して、ほとんど柔軟性を提供しない。従って、開発者は、より新しいアプリケーションの型におけるデータを別のアプリケーションの型におけるデータに変換又はマップする１以上のインターフェースを書くことを最終的に（前述のように）試みる場合が多い。例えば、ある型フレームワークにおいて書かれたアプリケーションを書く開発者は、ＬＩＳＰプログラミング言語で書かれた他のアプリケーションのためのアダプター（ａｄａｐｔｏｒ）及び／又はＸＭＬ、ＳＱＬ、．ＮＥＴ及びＪＡＶＡ（登録商標）のプログラミング言語のそれぞれで書かれたアプリケーションのための別々のアダプターも書く必要があるかもしれない。
【０００９】
これは、新しいアプリケーションプログラムの開発者が他のプログラムで使用される型について知る（又は学ぶ）必要が出てくることを意味することを理解されたい。少数のアプリケーションを考慮する中で、この問題はささいな不都合であるかもしれない。しかし、より一般的に、この種のシナリオは、特に、システム上で同様又は同一の種類のデータ（例えばメンバーレコード、関数等）を使用するアプリケーションプログラムの数が増えるにつれて、多くの開発者にとって急激に問題のあるものとなる。様々なアプリケーションプログラムのそれぞれが変更又はアップグレードを通じて、さらに型名を及び／又は構造の変更をもたらし得るので、この問題はさらに悪化する可能性がある。
【００１０】
このような種類の問題を解決しようとして試みてきたさらに別の方法が、「ルーズ（ｌｏｏｓｅ）」又は動的な型付けである。ルーズ又は動的な型付けでは、より新しいアプリケーションプログラムは、以前から存在しているアプリケーションプログラムにおける型名又は構造の正確な理解を必ずしも有する必要はない。むしろ、このアプリケーションコンポーネントは、型の構造／シェイプの間の完全な一致があるかをランタイムで判定でき、その後実行時にこれらの型シェイプをマップする。残念ながら、動的又はルーズな型付けは、興味のある項目が構造的に似ているが同一ではないときに何をすべきかの問題を解決しない。さらに、そしておそらくはより重要なことに、動的又はルーズな型付けは、強く型付けするシステム又は公称的な型付けシステムでない傾向にあるアプリケーションによるランタイム検査のために、重要なパフォーマンス及びセキュリティを失う結果となる傾向にある。
【００１１】
したがって、型フレームワークにおける関数又はデータのアクセス及び使用に関連付けられた多くの困難がある。
【発明の概要】
【００１２】
開発者に異なるアプリケーションのそれぞれに対する新しく異なる対応プラグイン又はアダプターを生成することを必ずしも要求することなく、公称型のフレームワークにおいて複数の異なる型の間でのデータを効率的に相関させるよう構成された、システム、方法及びコンピュータープログラム製品を、本発明の実装は提供する。特に、本発明の実装は、開発者が、興味のある１以上のアプリケーションプログラム間で共通の型シェイプのセットに基づく単一の中間型（ｉｎｔｅｒｍｅｄｉａｔｅ  ｔｙｐｅ）を使用することを可能にする。本発明の実装は、興味のある様々なアプリケーションプログラムにより使用でき、様々なアプリケーションプログラムとインターフェースをとり得る、および異なる型における型シェイプ／構造を中間型において定義された共通の型シェイプ／構造にマップする１以上のプロキシをさらに含む。
【００１３】
例えば、本発明の実装による方法は、アプリケーションプログラムにより使用される対象の型の１以上の必要な型シェイプを特定することに関与できる。本方法は、対象の型の１以上の必要な型シェイプを含む、対応する１以上の公称的に互換性のないソースの型を有する１以上の異なるアプリケーションプログラムを特定することにも関できる。さらに、対象の型を使用してアプリケーションプログラムを実行するための１以上の命令を受信することに本方法は関与できる。さらに、アプリケーションプログラムを実行した後に、アプリケーションプログラムによる、１以上の自動的に生成されたプロキシを使用して公称的に互換性のない型における必要な型シェイプに関連付けられたデータに対する１以上のアクセス要求を処理することに本方法は関与できる。
【００１４】
さらに、本発明の実装による別の又は代替の方法は、システムにインストールされたアプリケーションプログラムにより使用される型の１以上の必要な型シェイプを特定することに関与できる。本方法は、１以上の異なるアプリケーションプログラムにより使用される１以上の公称的に互換性のない型における１以上の必要な型シェイプを特定することにも関与できる。さらに、本方法は、アプリケーションプログラムにより使用される型の表現を含む中間型を自動的に生成することに関与できる。さらに、本方法は、１以上の公称的に互換性のない型の１以上の必要な型シェイプを生成された中間型に相関させる１以上のプロキシを自動的に生成することに関与できる。
【００１５】
本概要は、以下の発明を実施するための形態でさらに説明されている選択した概念を簡略化した形式で紹介するために提供するものである。本概要は、特許請求の範囲に記載されている主題事項の重要な特徴または本質的な特徴を特定することを目的とするものでも、特許請求の範囲に記載されている主題事項の範囲の決定に際して、補助として使用することを目的とするものでもない。
【００１６】
本発明の更なる特徴及び利点は、以下の発明を実施するための形態において説明され、一部は発明を実施するための形態から明らかとなるか、又は発明の実施から理解されうる。本発明の特徴及び利点は、添付の特許請求の範囲において具体的に指摘された手段及び組み合わせによって理解され取得されうる。本発明のこれら及び他の特徴は、以下の発明を実施するための形態及び添付の特許請求の範囲からより完全に明白になるか、又は以降で説明されるように本発明の実施により理解されうる。
【００１７】
本発明の上述及び他の利点及び特徴を取得できる方式を説明するために、上で簡潔に説明された本発明のより特定の詳細は、添付の図面において図示されるその特別な実施形態を参照して示される。これらの図面が本発明の典型的な実施形態のみ示し、従って本発明の範囲を限定することを意図しないことを理解されたく、添付の図面の使用を通して本発明はさらに特定及び詳細に記述及び説明される。
【図面の簡単な説明】
【００１８】
【図１Ａ】本発明の実装による公称型フレームワークの全体的なスキーマ図である。
【図１Ｂ】１以上のデータ構造が生成され、公称的に互換性のない型における型シェイプにマップされる、本発明の実装による全体的なスキーマ図である。
【図２】本発明の実装による公称的に互換性のない型の間での要求を処理する方法における一連の動作を含むフローチャート図である。
【図３】本発明の実装による公称的に互換性のない型をマップするのに使用される１以上のデータ構造を生成するための方法における１以上の動作を含むフローチャート図である。
【発明を実施するための形態】
【００１９】
本発明の実装は、異なるアプリケーションのそれぞれに新しく異なる対応プラグイン又はアダプターを生成することを開発者に必ずしも要求することなく、公称型フレームワークにおける複数の異なる型の間でデータを効率的に相関させるよう構成されたシステム、方法及びコンピュータープログラム製品に拡張する。特に本発明の実装は、１以上の興味のあるアプリケーションプログラムの間の共通の型シェイプのセットに基づく単一の中間型を開発者が使用することを可能にする。本発明の実装は、興味のある様々なアプリケーションプログラムにより使用でき、様々なアプリケーションプログラムとインターフェースをとり得る、および異なる型における型シェイプ／構造を中間型において定義された共通の型シェイプ／構造にマップする１以上のプロキシをさらに含む。
【００２０】
従って、ここでより完全に理解されるように、本発明の実装は、あるインターフェースに適合するソースの型インスタンスを別のインターフェースに適合する対象の型インスタンスに効果的に変換するための１以上のメカニズムを提供し、これは型インターフェースの知識のみを有するソフトウェアにより消費されることになる。一般に、インターフェースを消費するソフトウェア、および第１のインターフェースから第２のインターフェースへの変換を引き起こすソフトウェアのいずれにも、初期のインターフェースの知識を要求しない。異なるインターフェースは、ＣＬＲ（ｃｏｍｍｏｎ  ｌａｎｇｕａｇｅ ｒｕｎｔｉｍｅ）型、構造化された値又はＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ  ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ）スキーマ、その他などの異なる型のシステムからとし得ることを、ここでより完全に理解されたい。このような本発明の実装は、ソフトウェアが未知のフォーマットにおいてデータを提供するコンポーネントと相互動作することを可能にし、ソフトウェアが本来作り出すよう設計されていないスキーマに適合するデータを要求するフレームワークを利用することを可能にする。
【００２１】
図１Ａは、本発明の１以上の実装により使用できる公称型フレームワーク１００の概要スキーマ図を示す。示されるように図１Ａは、いくつかの異なるアプリケーション１０３、１０５及び１０７がインストールされる公称型フレームワーク１００を示す。次にそれぞれのアプリケーションは、別のアプリケーションの公称型と公称的に互換性のない公称型を使用する。例えば図１Ａは、アプリケーション１０３が公称型「Ａ」１１０を使用している（又は公称型「Ａ」１１０により構成されている）ことを示す。示されるように型名Ａ１１０は要素１１５、１１７及び１１９を有する１以上の型シェイプ１１３を含む。
【００２２】
説明の目的で、公称型Ａは、レコードに関連付けられた関数、変数又は文字列さえも含む任意の数又は種類のデータを表し得る。例えば公称型Ａは、顧客レコード、及び／又はデータベースプログラムで顧客データを扱うための１以上の関数を定義し得る。顧客レコードの場合、型シェイプ１１３の要素１１５はファーストネームに基づく文字列を表すフィールドを含むかもしれず、一方で要素１１７はラストネームに基づく文字列を表すフィールドを含むかもしれない。次に要素１１９は、アドレスフィールドに基づく文字列を表す別のフィールドを含むかもしれず、又は可能性として評価される関数（例えば誕生日文字列から計算された年齢の値）を含むかもしれない。従ってレコードのケースでは、要素１１５、１１７及び１１９のそれぞれは、まださらなる下層のデータ及びデータフォーマット要求を有するいくつかのフィールド名を含むかもしれない。
【００２３】
図１Ａはまた、アプリケーション１０３と対照的に、アプリケーション１０５が公称型「Ｂ」１２０に基づいて構成され、アプリケーション１０７が公称型「Ｃ」１３０に基づいて構成されることを示す。一方、公称的に互換性がない域を越えて、公称型Ｂ及びＣは、公称型Ａに対する型シェイプ１１３と比較して異なる型シェイプ１２３及び１３３も含む。例えば、図１Ａは、型名Ｂ１２０の型シェイプ１２３が要素１１５及び要素１１７を含むが、要素１２５に関して型シェイプ１１３と異なることを示す。同様に図１Ａは、公称型Ｃが、要素１３５に関して異なる型シェイプ１３３で構成されることを示す。
【００２４】
このような同様なもの及び異なるものが異なるアプリケーション又はコンポーネントにおいて同時に示されうる多くの状況がある。例えば、アプリケーション１０３、１０５及び１０７が、顧客レコードを使用する異なるデータベースアプリケーションプログラムをそれぞれ含むかもしれないが、顧客レコードのフィールドを異なって関連付けるかもしれない。例えば、型シェイプ１２３における要素１２５が顧客の固有の識別子についてのフィールドを表す一方で、型シェイプ１３３における要素１３５が電子署名のためのフィールドを含み得る。
【００２５】
公称型間のこれらの様々な構造／シェイプの違いにも関わらず、本発明の実装は、アプリケーション１０３、１０５及び／又は１０７が公称型フレームワーク１００における１以上のコンポーネントを使用して相互動作することを可能にする。公称型フレームワーク１００は、どの型名があるアプリケーションプログラムから次のアプリケーションプログラムへ使用されているかだけでなく、対応する型シェイプもランタイムに先立って特定するよう構成された１以上のコンポーネント又はモジュールを含み得ることを、以下でより完全に理解されたい。実行時、公称型フレームワーク１００は、様々なアプリケーションが構造的な要素をある公称型から次の公称型へ容易にマップする１以上のプロキシを初期化することを可能とし、公称的に互換性のない型を使用しているにも関わらずアプリケーション間の相互動作を可能にする。
【００２６】
図１Ａは、公称型フレームワーク１００が処理モジュール１４０を含むことを示す。処理モジュール１４０は、アプリケーション内の公称型を分析及び／又は検査するよう構成できる。例えば、図１Ａは、処理モジュール１４０が、要素１１５及び要素１１７を含む型シェイプ１１３の使用に関して、アプリケーション１０３から指示（すなわちメッセージ１５０）を受け取ることを示す。同様に、アプリケーション１０３における１以上のインターフェースは、処理モジュール１４０からの、型名、構造及び／又は対応する関数の特定に対する１以上の要求に応答し得る。追加又は代替の実装において、アプリケーション１０３は、処理モジュール１４０によりアクセスできる１以上のインターフェースを介してこの情報を単に公開する。さらに追加又は代替の実装において、処理モジュール１４０は、アプリケーション１０３（１０５、１０７などにおいても同様）の詳細な検査を複数回実行するか、任意のコンポーネント又はアップデートがアプリケーション１０３（又はシステム内の別のアプリケーション）において任意の回数インストールされる。
【００２７】
処理モジュール１４０が、インストールの任意の時点の間及びランタイムの間でさえも、様々なアプリケーションとの／の通信及び／又は検査を実行できることを理解されたい。例えば、アプリケーションがインストールされるか又はアプリケーションにインストールされるコンポーネントがある度に、使用されているすべての型を特定するために、アプリケーションに通信又はアプリケーションを解析するために、公称型フレームワーク１００は処理モジュール１４０を初期化できる。さらに、アプリケーションプログラム１０３がランタイムの間に初期化されるとき、処理モジュール１４０はこれらの検査を実行できる。一方、通信及び／又は検査が実行されても、各アプリケーションプログラムは公称型フレームワーク１００と直接対話するのみであり、従って、それ自身の型の評価及びマッピングを実行する必要がない。
【００２８】
任意のイベントにおいて、公称型フレームワーク１００は、任意の数の異なる方法で、様々な型の情報を保持できる。例えば、図１Ａは、処理モジュール１４０がアプリケーション１０３、１０５及び１０７における公称型の間で型シェイプの相関関係のセットを含む結果セット１６０を準備することを示す。結果１６０が生成されると、ストレージ内の１以上のレジスター（図示せず）に結果１６０を渡すよう、公称型フレームワーク１００を構成できる。追加又は代替の実装において、所与のアプリケーションプログラムを初期化する度に新たに生成されるメモリ内データ構造などの様々なデータ構造として１以上のレジスターをロードするようにも又は代替としても、公称型フレームワーク１００を構成できる。要するに、必要に応じて様々な相関関係を検査、相関、格納及び取り出しのいずれについても、広範囲のメカニズムが存在する。
【００２９】
任意のイベントにおいて、図１Ａは、処理モジュール１４０がアプリケーション１０３、１０５、１０７の異なる公称的に互換性のない型Ａ、Ｂ及びＣの間で共通である様々な型シェイプを特定する（例えば結果１６０）ことを示す。特に、図１Ａは、メッセージ１５０において要求されるなど、公称型Ａ、Ｂ、Ｃのそれぞれが要素１１５及び１１７を含むことを処理モジュール１４０が特定したことを示す。公称型フレームワーク１００はその後、異なる公称型をマップするランタイムのデータ構造を生成するためにこれらの結果１６０を使用でき、従ってアプリケーションプログラム間の少なくともいくつかの相互動作を容易にする。
【００３０】
例えば、図１Ｂは、これらの様々な公称型シェイプ１１３、１２３及び１３３が公称型フレームワーク１００によりランタイムで相関されるスキーマ図を示す。公称型フレームワーク１００は、１以上の一時的なランタイムのデータ構造を通してこれらの型シェイプ１１３、１２３及び１３３を相互に関連付けることを、以下でより完全に理解されたい。例えば、図１Ｂは、処理モジュール１４０が、公称型Ａ１１０を呼び出す１以上の関数を実行又は初期化する１以上の要求１５３を、アプリケーション１０３から受信することを示す。実行（ランタイム）において、処理モジュール１４０はその後、一時的な新しい公称型「Ａ」１５５の形式で中間データ構造を生成する。一般に、この中間の公称型Ａは、型シェイプ１１３ａを含み、型シェイプ１１３ａは、事前に特定された共通型シェイプ、すなわち要素１１５及び１１７を含むよう生成されたメモリ内のシェイプを含むことができる。
【００３１】
処理モジュール１４０はその後、中間の公称型１５５を他のアプリケーションプログラム１０５、１０７等のそれぞれにおける中間型にマップする１以上のランタイムプロキシを生成する。例えば、図１Ｂは、処理モジュール１４０が、要素１１５及び１１７のマッピングを介する公称型１５５及び公称型１２０間の型シェイプにおける関係を示す１以上のマッピングテープルを含むプロキシ１６５を生成することを示す。同様に、図１Ｂは、処理モジュール１４０がプロキシ１７０を生成し、プロキシ１７０が要素１１５及び１１７のマッピングを介する公称型１５５及び公称型１３０の間の型シェイプにおける関係を示す１以上のマッピングテーブルを含むことを示す。
【００３２】
まとめて、これらの様々なプロキシ１６５、１７０等を自動的に生成できる多くの方法がある。ほとんどの場合において、例えばプロキシ１６５及び１７０を生成するために使用されるコードは公称型フレームワーク１００内に含まれ（例えば中間言語コード等）、ランタイムにおいて所与のアプリケーションプログラム１０３、１０５等によりコンパイルまたは呼び出され得る。このような場合において、所与のアプリケーションの開発者ニーズは、公称型フレームワーク１００への１以上の参照のみを含み、公称型のマッピングに利用可能な１以上のデフォルトのプロキシのアクセスを要求する。一方、さらなる又は代替の実装において、アプリケーション１０３、１０５、１０７を、所与のアプリケーションがランタイムにおいて公称型フレームワーク１００に提供する常駐プロキシコードで構成することもできる。
【００３３】
常駐プロキシコードで提供されると、公称型フレームワーク１００は、関連のあるプロキシコードを最終的に実行し、要求された実行に適切なように所与のプロキシを構成する。つまり、（例えば、処理モジュール１４０を介して）公称型フレームワーク１００と対話するためだけでなく、所与のアプリケーションと直接インターフェースをとるための１以上のインターフェースを含むように、各プロキシをランタイムにおいて構成し、別のアプリケーションによってなされる１以上の実行／アクセス要求を実装する。例えば、公称型１２０の一部としてアプリケーション１０５において保持される関数若しくはデータ、又は公称型１３０の一部としてアプリケーション１０７におけるデータにアクセス又はこれらを扱うことを要求する１以上の異なる要求を、アプリケーション１０３は渡しうる。アプリケーション１０３が要素１１５に関連するデータ要素のアクセスを要求している限り、処理モジュール１４０はプロキシ１６５、１７０を使用して様々なデータ構造を通して要求を容易にマップし、その後に関連性のあるアプリケーションデータ（例えばストレージ内に）への変更を処理する。
【００３４】
例えば、顧客レコードに関するイベント型１１０、１２０及び１３０において、アプリケーション１０３は、特定のレコード内の（例えば、要素１１５により表される）ファーストネームを「ジョン」から「ジャック」に変更するように、アプリケーション１０５により管理されるレコードの変更を要求するかもしれない。処理モジュール１４０はその後、この特定の変更要求が中間型シェイプ１１３ａにおける要素１１５に関連することを特定でき、（アプリケーション１０５が名付けられたので）プロキシ１６５を通してデータ変更要求を処理できる。同様に、アプリケーション１０３は、特定のレコード内の（例えば、要素１１７により表される）ラストネームを「ブラウン」から「スミス」に変更するように、アプリケーション１０７により管理されるレコードの変更を次に要求するかもしれない。処理モジュール１４０はその後、この特定の変更要求が中間型シェイプ１１３ａにおける要素１１５に関連することを特定でき、（アプリケーション１０７が名付けられたので）プロキシ１７０を通してデータ変更要求を処理できる。従って、公称型フレームワーク１００は、公称型及びある程度公称型シェイプが、あるアプリケーションから次のアプリケーションへ異なるにも関わらず、アプリケーション１０３による要求を否定しない。
【００３５】
さらに、図１Ｂはバックエンドのストア１８０に関して本発明の別の潜在的な実装を示す。特に、本発明の実装は、中間の公称型Ａに基づく新しいレコードを生成するのに使用でき、新しいレコードがどこへ行くべきかはまだ決められていない。例えば、上述の例において顧客レコードを単に変えるのと対照的に、アプリケーション１０３はアプリケーション１０５及び１０７に対する１以上の両方のデータストアに最終的に置かれる新しい顧客レコードを生成するかもしれない。
【００３６】
一方、この特別な特徴を使用するために、図１Ｂは、処理モジュール１４０が、バックエンドのストア１８０において使用する公称型１８５をさらに生成し、１以上のプロキシ１７５をさらに生成することを示す。プロキシ１６５及び１７０と同様に、プロキシ１７５は、公称型１５５における型シェイプ１１３ａの要素を公称型１８５の要素にマップするのに使用される。当然のことながら、新しい公称型１８５は公称型フレームワークにより生成されているので、新しい公称型１８５は中間の公称型１５５について既に生成されてきたのと同じ型シェイプを含む傾向になる。従って、例えば、アプリケーション１０３が、アプリケーション１０５、１０７の任意の１つにおいて（及び潜在的にアプリケーション１０３においても）使用される新しいレコードを要求した場合、処理モジュール１４０はプロキシ１７５を介してこのような要求（及びそれに対応するアップデート）を扱うことができる。
【００３７】
従って、図１Ａ及び図１Ｂは、異なる公称的に互換性のない型を使用するアプリケーションがそれでもなお互いに対話し、必要に応じて各アプリケーションにより管理される下層のデータにまだアクセスすることを可能とする、多くの異なるコンポーネント及びスキーマ図を示す。前述のように、このような相互運用性は、異なる公称型間の型シェイプ／型の構造において類似性があるという考えに第一に基づく。このように開発者は、システムにおける他のアプリケーションにより使用されている異なる公称型のそれぞれに必ずしも関与する必要はなく、ほとんどの場合において、型の非互換性のこのような扱いをシステムに任せることができる。
【００３８】
以上に加えて、特定の結果を達成するための方法における１以上の動作を含むフローチャートにおいて、本発明の実装を説明することもできる。例えば図２は、公称的に互換性のない型における必要なデータ構造を使用するアプリケーションプログラムによる１以上のアクセス要求を処理する一連の動作を含むフローチャートを示す。さらに図３は、公称的に互換性のない型を共に使用できるように相関させるのに使用される１以上のデータ構造を自動的に生成するための方法における動作のフローチャートである。図２及び図３の動作は、図１Ａ及び図１Ｂのコンポーネント及び概略図と結び付けて以下で説明される。
【００３９】
例えば、図２は、本発明による方法が対象の型における必要な型シェイプを特定する動作２００を含むことができることを示す。動作２００は、アプリケーションプログラムにより使用される対象の型の１以上の必要な型シェイプを特定することを含む。例えば、図１Ａに示されるように、処理モジュール１４０は、要素１１５及び１１７を含む型シェイプの使用に関して要求（又は通信）１５０を受け取る。このような場合に、アプリケーション１０３が公称的に互換性のない型を使用しているかもしれない他のアプリケーションと相互動作できるように、要素１１５及び１１７は他の公称型において共通でなければならない要求された型の要素のセットを含み得る。
【００４０】
図２はまた、本発明による方法が公称的に互換性のない型における必要な型シェイプを特定する動作２１０を含むことができることを示す。動作２１０は、対象の型の１以上の必要な型シェイプを含む、対応する１以上の公称的に互換性のないソースの型を有する１以上の異なるアプリケーションプログラムを特定することを含む。例えば、図１Ａに示されるように、処理モジュール１４０は、アプリケーション１０５及び１０７と対話し、異なる型シェイプ１２３及び１３３を特定する。型シェイプ１２３及び１３３は、型シェイプ１１３の要素と類似か又は同一である少なくともいくつかの型の要素１１５及び１１７を有する。
【００４１】
さらに、図２は、本方法がアプリケーションの実行命令を受け取る動作２２０を含むことができることを示す。動作２２０は、対象の型を使用してアプリケーションプログラムを実行するための１以上の命令を受け取ることを含む。例えば、図１Ｂに示されるように、処理モジュール１４０は、例えばアプリケーションがランタイムに初期化されるとき等、アプリケーション１０３を実行するために要求１５３を受け取る。
【００４２】
さらに、図２は、本発明による方法が、自動的に生成されたプロキシを使用して公称的に互換性のない型の間で要求を処理する動作２３０を含むことができることを示す。動作２３０は、アプリケーションプログラムの実行の後に、１以上の自動的に生成されたプロキシを使用して公称的に互換性のない型における必要な型シェイプに対する、アプリケーションプログラムによる１以上のアクセス要求を処理する。例えば、図１Ｂは、ランタイムにおいてプログラムモジュール１４０がプロキシ１６５及びプロキシ１７０を生成することを示し、プロキシ１６５及びプロキシ１７０は、それに相応して中間の公称型１５５の型シェイプを公称型１２０及び１４０に一致させる。
【００４３】
以上に加えて、図３は、公称的に互換性のない型をマップする１以上のデータ構造を生成するための本発明の実装による追加又は代替の方法のフローチャートを示す。特に、図３は、追加又は代替の方法が、アプリケーションにより使用される型における必要な型シェイプを特定する動作３００を含むことができることを示す。動作３００は、システムにおいてインストールされたアプリケーションプログラムにより使用される型の１以上の必要な型シェイプを特定することを含む。例えば、図１Ａは、処理モジュール１４０が、例えばメッセージ１５０を介して、アプリケーション１０３が公称型１１０における型シェイプ１１３の要素１１５及び１１７と類似か又は同一の要素を使用する他のアプリケーションと相互動作できることを特定することを示す。
【００４４】
図３は、本方法が、異なる公称的に互換性のない型における必要な型シェイプを特定する動作３１０を含むことができることを示す。動作３１０は、１以上の異なるアプリケーションプログラムにより使用される１以上の公称的に互換性のない型における１以上の必要な型の構造を特定することを含む。例えば、図１Ａは、処理モジュール１４０がアプリケーション１０５及び１０７と対話して、例えば結果１６０を介して、公称型Ｂ及びＣ（１２０及び１３０）も公称型Ａ（１１０）における要素１１５及び１１７に対応する要素を有する型シェイプを含むことを特定することを示す。
【００４５】
さらに図３は、本方法が中間型を自動的に生成する動作３２０を含むことができることを示す。動作３２０は、アプリケーションプログラムにより使用される型の表示を含む中間型を自動的に生成することを含む。例えば、図１Ｂは、処理モジュールが、型シェイプ１１３ａを含む中間の公称型１５５を生成することを示す。型シェイプ１１３ａは、例えばメッセージ１５０において事前に示されるなど、要素１１５及び１１７を含むデータ構造を含むことができる。ある実装において、型シェイプ１１３ａはメモリ内データ構造を含むが、他のデータ形式もまた本発明により可能である。
【００４６】
さらに、図３は、本発明による方法が、中間型シェイプを互換性のない公称型の型シェイプにマップする１以上のプロキシを生成する動作３３０を含むことができることを示す。動作３３０は、１以上の公称的に互換性のない型の１以上の必要な型シェイプ／構造を、生成された中間型に相関させる１以上のメモリ内プロキシを自動的に生成することを含む。例えば、図１Ｂに示されるように、処理モジュール１４０は、（実行命令１５３を受け取った後に）ランタイムにおいてプロキシ１６５及び１７０を自動的に生成する。次にプロキシ１６５及び１７０は、既存の公称型１２０及び１３０を用いて、中間の公称型１５５の間の要素１１５及び１１７を効率的にマップする。
【００４７】
従って、図１Ａから図３に関して図示され及び／又は説明されたコンポーネント、モジュール及びメカニズムが、公称型システム内でプロジェクト型としてだけでなく、すべてのランタイムにおいて構造型システムから公称型システムへのプロジェクト型としても使用できることを理解されたい。さらに、本発明の実装は、開発者が、（インスタンスのためのストレージの自動的な生成で）インターフェースを与えられた公称型インスタンスを生成し、さらにプロジェクト化されたインターフェースを介して元の型にアクセスし、操作することを可能にする。再度、このようなアクセス及び操作は、ランタイムにおいてシステムにより生成される１以上の型特有のプロキシを介して起こることができ、他のアプリケーションと型を相関させるために任意の労力、アプリケーション特有の苦労を必要としないことができる。ここで説明された実装が、例えばＣＬＲ及びＸＭＬに関連付けられたものを含む、型及び型の構造の広い範囲に適用できることを理解されたい。
【００４８】
本発明の実施形態は、以下でより詳細に論じられるように、様々なコンピューターハードウェアを含む専用又は汎用のコンピューターを含み得る。本発明の範囲内の実施形態もまた、コンピューター実行可能な命令又はそこに格納されたデータ構造を運ぶか又は有するためのコンピューターで読み取り可能な媒体を含む。このようなコンピューター読み取り可能な媒体は、汎用又は専用のコンピューターによりアクセスできる任意の利用可能な媒体であり得る。
【００４９】
例として、限定ではなく、このようなコンピューター読み取り可能な媒体は、コンピューターで実行可能な命令又はデータ構造の形式で所望のプログラムコード意味を運ぶ又は格納するのに使用でき、汎用又は専用のコンピューターによりアクセスできる、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ若しくは他の光ディスクストレージ、磁気ディスクストレージ若しくは他の磁気ストレージデバイス、又は他の任意の媒体を含むことができる。情報がネットワーク上で又は別の通信接続（有線、無線、又は有線若しくは無線の組み合わせのいずれか）でコンピューターに転送又は提供されるとき、コンピューターは、接続をコンピューター読み取り可能な媒体として適切にみなす。従って任意のこのような接続は、適切にコンピューター読み取り可能な媒体と称される。上述の組み合わせもまた、コンピューター読み取り可能な媒体の範囲内に含まれるべきである。
【００５０】
例えば、コンピューター実行可能な命令は、汎用コンピューター、専用コンピューター、又は専用処理デバイスにある機能又は機能のグループを実行することを引き起こす命令及びデータを含む。本発明の主題事項を構造的特徴および／または方法論的動作に固有の言語で説明したが、添付の特許請求の範囲で定義される本発明の主題事項は、必ずしも説明した特定の特徴または動作に必ずしも限定されないことを理解されたい。むしろ、特定の特徴および動作は、本発明を実装する例示的な形態として開示されている。
【００５１】
本発明はその精神又は重要な特徴から逸脱することなく他の特定の形態において実装されうる。説明された実施形態は、すべての個々において、例示のためのものであると解釈されるべきであり、限定の意味で解釈されるべきではないことが意図される。従って本発明の範囲は、上記の説明よりむしろ添付の特許請求の範囲により示される。特許請求の範囲の均等の意味及び範囲内での全ての変更は、本発明の範囲内に包含されることとなる。
【図１Ａ】
2011514596.tif 000003
【図１Ｂ】
2011514596.tif 000004
【図２】
2011514596.tif 000005
【図３】
2011514596.tif 000006
【国際調査報告】
2011514596.tif 000007
2011514596.tif 000008