ターゲットシステムのデータへのアクセスを提供するコンピューターの方法およびシステム
【課題】コンピューターシステムおよび方法が、ターゲットシステムのウェブ（グローバル・コンピューターネットワーク）サービスデータへのアクセスを提供する。
【解決手段】ターゲットシステムは、複数のウェブサービスを介してデータを公開する。アプリケーションインターフェースが、ターゲットシステムと相互作用するように適合され、ターゲットシステムのためのアプリケーションの間で既存の（あらかじめ定義された）ウェブサービスを再利用する。アプリケーションインターフェースは、公開されたデータにクエリを行う。マッピングメンバーが、公開されたデータのアプリケーションインターフェースクエリと、対象アプリケーションにおいて使用可能なオブジェクトの構文との間をマップする。マッピングメンバーは、対象アプリケーションを、クエリに応答して生成されたオブジェクトインスタンスのデータにアクセスできるようにする。
【解決手段】ターゲットシステムは、複数のウェブサービスを介してデータを公開する。アプリケーションインターフェースが、ターゲットシステムと相互作用するように適合され、ターゲットシステムのためのアプリケーションの間で既存の（あらかじめ定義された）ウェブサービスを再利用する。アプリケーションインターフェースは、公開されたデータにクエリを行う。マッピングメンバーが、公開されたデータのアプリケーションインターフェースクエリと、対象アプリケーションにおいて使用可能なオブジェクトの構文との間をマップする。マッピングメンバーは、対象アプリケーションを、クエリに応答して生成されたオブジェクトインスタンスのデータにアクセスできるようにする。
【発明の詳細な説明】
【技術分野】
【０００１】
ターゲットシステムのデータへのアクセスを提供するコンピューターの方法およびシステムに関する。
【背景技術】
【０００２】
インターネットなどのグローバル・コンピューターネットワークが、新たなコンピューティング・プラットフォーム、およびコンピューティング・アプリケーション（ソフトウェア・アプリケーション設計を含む）を提供している。例えば、インターネット規模の分散コンピューティングは、いわゆるプラットフォーム・コンピューティングのようなネットワークを提供する。プラットフォームとしてのネットワークは、（ウェブ対応アプリケーションとして構成された）アプリケーションについて、ブラウザを介して全面的に実行できるようにする。さらに、プラットフォームとしてのネットワークによって、ユーザは、さまざまな役割にわたり、またはその役割の中で、共同作業することが可能になる。
【０００３】
所与のウェブ対応アプリケーションに関して、ユーザ／クライアント（分散オブジェクトアーキテクチャクライアント）は、個々のブラウザを介してアプリケーションを実行する。ブラウザは、アプリケーションサーバー（分散オブジェクト・サーバー）と通信する。さらにブラウザは、ウェブサーバーと通信する。認証サービス、トランザクションサービス、ネーミングサービス、アドミニストレーションサービス、およびセキュリティサービスなどの多くのサービスが、アプリケーションサーバーおよびウェブサーバーの両方に複製される。各ユーザ／クライアントは、一般的に、別々にプラットフォームに登録される。また、各ユーザ／クライアントは、各組のウェブサーバーサービスの実行に関与する。
【０００４】
今までのところ、プラットフォームにおけるクライアントとしてのユーザが、複数のアプリケーションにわたって、データをコピーし、他のデータに関与する、または既存のウェブサーバーサービスを活用するためのメカニズムはない。
【０００５】
プラットフォームとしてネットワークを利用する、コンピューター実施プログラムおよび協調システムの産業上の一例は、製品ライフサイクル管理（Ｐｒｏｄｕｃｔ Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ／ＰＬＭ）システムである。ＰＬＭソリューションは、企業活動の拡大を概念にして、製品開発のために、構想の段階から製品寿命の終わりまで、企業が、製品データを共有し、共通プロセスを適用し、企業知識を活用することを支援するビジネス戦略を指す。この概念によれば、企業は、その企業の部門のみならず、ビジネスパートナー、サプライヤ、ＯＥＭ（Ｏｒｉｇｉｎａｌ Ｅｑｕｉｐｍｅｎｔ Ｍａｎｕｆａｃｔｕｒｅｒｓ）、および顧客などの他の関係者からも構成される。これらの関係者を含めることにより、ＰＬＭは、このネットワークが単一のエンティティとして機能して、製品およびプロセスを概念化し、設計し、構築し、サポートすることを可能にする。
【０００６】
ＰＬＭソリューションの中には、コンピューター支援技術があり、コンピューター支援設計（Ｃｏｍｐｕｔｅｒ−Ａｉｄｅｄ Ｄｅｓｉｇｎ／ＣＡＤ）が知られている。コンピューター支援設計は、製品設計を記述するためのソフトウエアソリューションに関する。同様に、ＣＡＥは、コンピューター支援エンジニアリング（Ｃｏｍｐｕｔｅｒ−Ａｉｄｅｄ Ｅｎｇｉｎｅｅｒｉｎｇ）の頭字語であり、例えば、将来製品の物理的な動作をシミュレートするためのソフトウエアソリューションに関する。ＣＡＭは、コンピューター支援製造（Ｃｏｍｐｕｔｅｒ−Ａｉｄｅｄ Ｍａｎｕｆａｃｔｕｒｉｎｇ）を表し、一般的に、製造過程および製造作業を定義するためのソフトウエアソリューションを含む。いくつかのＰＬＭソリューションは、例えば、デジタルモックアップ（製品の３Ｄグラフィカルモデル）を作成することによって、製品を設計し、開発することを可能にする。適切なアプリケーションを使用して、最初にデジタル製品を定義し、シミュレートすることができる。次いで、無駄のないデジタル製造プロセスを定義し、モデル化することができる。
【０００７】
例えば、一般に、Ｄａｓｓａｕｌｔ Ｓｙｓｔｅｍｅｓにより（ＣＡＴＩＡ、ＥＮＯＶＩＡ、およびＤＥＬＭＩＡの商標下において）提供されるＰＬＭソリューションは、製品エンジニアリング知識を構成するエンジニアリングハブ、製造エンジニアリング知識を管理するマニュファクチャリングハブ、ならびにエンジニアリングハブおよびマニュファクチャリングハブの両方への事業統合および事業結合を可能にするエンタープライズハブを提供する。これら全てのシステムはともに、製品、プロセス、リソースをリンクするオープンなオブジェクトモデルを実現して、動的な知識ベースの製品創造、および最適化した製品定義、製造準備、生産およびサービスを推進する意思決定支援を可能にする。
【０００８】
このＰＬＭソリューションは、製品のリレーショナルデータベースを含む。リレーショナルデータベースは、一組のテキストデータを含み、かつデータ間の関係を含む。データは、一般的に、データの階層順に並べられた、製品に関連した技術データを含み、検索できるようにインデックス付けされている。データは、しばしばモデル化された製品およびプロセスである、モデル化されたオブジェクトを表す。
【０００９】
製品構成、プロセス知識、およびリソース情報を含むＰＬＭ情報は、一般的に、協調的な方法により編集されることを目的とする。例えば、協調的な方法で作業する設計者のチームは、ウェブ対応アプリケーションを介して、リモートサイトから製品に関連した共有情報にアクセスすることによって、個々に貢献して製品を設計する。各ユーザまたはリモートサイトは、システムプラットフォームに別々に登録され、それぞれが、このプロジェクトのアプリケーション用のそれぞれの組のウェブサーバーサービスの実装に関与する。ユーザは、もともと他のアプリケーション用に実装される既存のウェブサービスを有していることがあるけれども、進行中のプロジェクトに関して、これらのウェブサービスを再利用、または共有するためのメカニズムがない。プラットフォームのクライアントのユーザまたはアプリケーションが、既存のウェブサービスをコピーする、または別の方法で活用する必要がある。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】米国特許第６９３４７０９号明細書
【発明の概要】
【００１１】
本発明は、前述の先行技術の欠点に取り組む。詳細には、本発明は、２つ以上のアプリケーションにわたるクライアントシステムのウェブ（グローバルコンピューターネットワークサーバー）サービスの再利用、または共通使用を可能にする、コンピューター手法、システム、および装置を提供する。
【００１２】
好ましい実施形態では、本発明のシステムは、アプリケーションインターフェースと、マッピングメンバーとを含む。アプリケーションインターフェースは、複数のウェブサービスを介して、データを公開しているターゲット（クライアント）システムと相互作用する。アプリケーションインターフェースは、公開されたデータにクエリを行う。アプリケーションインターフェースは、２つ以上のアプリケーションにわたって、複数のウェブサービスのうちの少なくとも１つを共通して使用することにより、ターゲットシステムに関するアプリケーション間で、既存の（あらかじめ提供された）ウェブサービスを再利用する。
【００１３】
この再利用を実現するために、アプリケーションインターフェースは、ターゲットシステムからウェブサービスデータの結合されたビューをもたらす方法で、ターゲットシステムのウェブサービスのうちの少なくとも２つへ呼を連鎖させる。少なくとも２つのウェブサービスは、ターゲットシステムによってあらかじめ提供されている。
【００１４】
マッピングメンバーは、グローバルコンピューターネットワークサービスを介して、公開されるデータのアプリケーションインターフェースクエリ（ａ）と、対象アプリケーションにおいて使用可能なオブジェクトの構文（ｂ）の間をマップする。マッピングメンバーは、対象アプリケーションを、アプリケーションインターフェースによって実装されるクエリに応答して生成されたオブジェクトインスタンスのデータにアクセスできるようにする。
【００１５】
いくつかの実施形態では、ターゲットシステムは、協調プラットフォームまたは類似のプラットフォームに対して外部または外的なシステムであり、分散オブジェクトアーキテクチャクライアントとして構成されている。対象アプリケーションは、任意のコンピューターシステムとして実装される。また、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）クライアント、ＲＭＩ（ｒｅｍｏｔｅ ｍｅｔｈｏｄ ｉｎｖｏｃａｔｉｏｎ）クライアント、ＥＪＢ（ｅｎｔｅｒｐｒｉｓｅ ＪＡＶＡ（登録商標） Ｂｅａｎ）クライアント、およびＪＮＩ（ＪＡＶＡ（登録商標） Ｎａｉｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）クライアントのうちの任意のものとして実装される。
【００１６】
一実施形態では、本発明は、外部システム（ターゲットクライアント）と統合するコラボレーションプラットフォームの能力を強化する。具体的には、実施形態によって、プラットフォームが、クエリデータを提供するウェブサービスを供給する外部システムとデータを共有することが可能になることから、プラットフォームのストレージ層を拡張するためのインターフェースが、本発明により恩恵を受ける。本発明は、宣言的な方法により、ウェブサービス呼び出し（複数のクエリ）のシーケンスを記述する機能を提供する。本発明の実装は、ウェブサービス呼び出しのシーケンスを実行して、データの統合されたビューを生成する。これにより、外的なデータを記述する単純化した方法を促進し、この外的なデータを、ＰＬＭ（製品ライフサイクル管理）データモデルに容易にマッピングする方法を可能にする。ＰＬＭデータモデルは、（ＰＬＭ、ＣＶ５、その他などの）プラットフォームアプリケーションによって、固有に使われる。
【００１７】
したがって、本発明は、関係／従属関係に基づく「統一されたビュー」を見る一意のクエリ／マッピング構文を定義し、既存のウェブサービスを利用して外部データを連合する。本発明は、いかなる追加の「コード」も書くことなく、外部システムからデータを連合する問題を解決し、それにより、時間およびコストを節約する。本発明はまた、コラボレーションプラットフォームが、データ連合を必要とするさまざまなアプリケーションをホストするための機会を広げる。その目的のために、本発明は以下の問題に取り組む。
１．複数のシステムにわたって製品材料を探す無駄な時間
２．別々の企業システムが同期を取り続けるようにする複雑な統合
３．別々のシステムで作業するユーザ間の非効率なコラボレーション
４．データ移行の複雑さによりレガシーシステムを退却させる困難性
５．データを他のシステムに再入力することによる作業の重複
６．手作業のユーザ介入を使用する、外部サプライヤとの非効率なデータ共有
【００１８】
したがって、本発明の実施形態は、インフラストラクチャレベルのソリューションを提供し、このインフラストラクチャの使用を意図する任意のコンシューマによって定義されなければならない一意のクエリ構文を定義する。
【図面の簡単な説明】
【００１９】
前述の事項は、添付の図面において図示されるように、以下の本発明の例示的な実施形態のより詳細な説明から明らかになるであろう。添付の図面は、異なる図の全体にわたって同様の参照記号が同じ部品を指す。図面は必ずしも縮尺どおりではなく、むしろ、本発明の実施形態を例示することに重点を置いている。
【図１Ａ】本発明の実施形態が配置されたコラボレーションプラットフォームの概略ブロック図である。
【図１Ｂ】本発明の実施形態が配置されたコラボレーションプラットフォームの概略ブロック図である。
【図１Ｃ】本発明の実施形態が配置されたコラボレーションプラットフォームの概略ブロック図である。
【図２】ターゲットシステムの複数のウェブ（グローバル・コンピューターネットワーク）サービスへの呼び出しを連鎖させて、ターゲットシステムからデータの結合されたビューをもたらす、本発明の実施形態の概略図である。
【図３】本発明の原理に従って、図１のプラットフォームスキーマにマップされている図２の結合されたビューの概略図である。
【図４】図２および図３の例におけるクエリ／マッピング構文を実装する、本発明のマッピングエンジンの概略図である。
【図５】本発明の一実施形態における処理およびデータ制御の流れ図である。
【図６】本発明の実施形態が動作するコンピューターネットワーク環境の概略図である。
【図７】本発明の実施形態が動作するコンピューターネットワーク環境のブロック図である。
【発明を実施するための形態】
【００２０】
以下は、本発明の例示的な実施形態の説明である。
【００２１】
本発明の実施形態を用いるコラボレーションプラットフォーム２００が、図１Ａおよび図１Ｂに図示されている。コラボレーションプラットフォーム２００は、分散オブジェクトアーキテクチャとして構成されている。コラボレーションプラットフォーム２００の好ましい実施形態は、さまざまなウェブブラウザ２２８（簡略化を目的に、図１Ｂに１つだけを図示）、ウェブサーバー２３８（明確化のため１つのみを図示）、アプリケーションサーバー２３６、およびストレージ層２２０（アプリケーションサーバーデータベース、対応するデータサーバーおよびファイルサーバーを含む）を含む。ウェブブラウザ２２８を介して、アプリケーション２０２（ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｉｎｇ Ｌａｎｇｕａｇｅ）クライアント２０４’として実装される）が実行される。ウェブブラウザ２２８は、ウェブサーバー２３８’に常駐するＸＭＬサーバー２０６’と（ファイアウォール２０８を介して）通信する。ウェブサーバー２３８’はまた、ＲＭＩ（Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ）クライアント２１０およびＸＭＬ−ＲＭＩインターフェース２２２を含む。
【００２２】
同様に、このアプリケーションおよび他のアプリケーション２０２は、ＲＭＩクライアント、ＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ（登録商標） Ｂｅａｎ）クライアント、ＪＮＩ（Ｊａｖａ（登録商標） Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）クライアントとして、および他のウェブサーバーキテクチャ上のクライアントとして実装することができる。これらのクライアントは、図１Ａの２０４で概略的に参照される。（概略的に参照されるように）対応するサーバー２０６は、ウェブサーバー２３８’の構成と同様に（すなわちそれぞれの該当するクライアント２１０およびインターフェース２２２と共に）構成される、それぞれのウェブサーバー２３８（図１Ａに概略的に参照される）に常駐する。
【００２３】
さらに図１Ｂに示すように、アプリケーションサーバー２３６は、ＲＭＩサーバー２１２、ＥＪＢクライアント２１４、ＥＪＢサーバー２１６に常駐する情報サービス２１８（永続性、メッセージング、ライフサイクル、ワークフロー、ポリシーマネジャ、アドミニストレーション、および構造管理）、およびＲＭＩ−ＥＪＢインターフェース２２４を含む。ウェブサーバー２３８’は、それ自身に常駐するＸＭＬ−ＲＭＩインターフェース２２２を介して、アプリケーションサーバー２３６と通信する。ウェブサーバー２３８’は、ＲＭＩ−ＥＪＢインターフェース２２４を介して、ＥＪＢサーバー２１６に常駐する情報サービス２１８とさらに通信する。これにより、上述した構成を使用して、アプリケーション２０２を使用するユーザは、ＸＭＬクライアント２０４’からウェブサーバー２３８’を介して、ＥＪＢサーバー２１６上の情報サービス２１８にアクセスすることができる。ＣＯＲＢＡベースのアーキテクチャに複製されるサービス（認証、セキュリティ、トランザクション、ネーミング、およびデータベースアドミニストレーション）は、ウェブサーバー２３８’によって提供され、アプリケーションサーバー２３６と共有される。この構成は、「ウェブセントリック（ｗｅｂｃｅｎｔｒｉｃ）」と呼ばれ、アプリケーション２０２は、（例えば、３階層ＣＯＲＢＡベースのウェブ対応アプリケーションとは対照的に）Ｎ階層である。アプリケーション２０２は、ウェブ上に配置され、ウェブサーバー２３８’またはアプリケーションサーバー２３６の、サービスおよびアドミニストレーション能力を十分に活かすことができる。
【００２４】
情報サービス２１８には、ネットワーク内の任意の地点からアクセスが可能である。例えば、ファイアウォール２０８内部からＲＭＩクライアント２３４上のアプリケーション２３２を実装するユーザは、ＲＭＩサーバー２１２からＲＭＩ−ＥＪＢインターフェース２２４を介して、ＥＪＢサーバー２１６上の情報サービス２１８にアクセスすることができる。同様に、ファイアウォール２０８内部からＥＪＢクライアント２４２上のアプリケーション２４０を実装するユーザは、ＥＪＢサーバー２１６から直接、ＥＪＢサーバー２１６上の情報サービス２１８にアクセスすることができる。アプリケーション２０２、２３２、および２４０は、異なるサーバー上で実装される同じアプリケーションである。
【００２５】
このように、プラットフォーム２００は、（ＣＯＲＢＡベースのアーキテクチャを有するような）一般的なウェブ対応の３階層アプリケーションに限定されず、譲受人により、参照によってその全体が本明細書に組み込まれる特許文献１に記述されているシステムコンパイラによって、Ｎ階層アプリケーションを有する。ウェブサーバー２３８およびアプリケーションサーバー２３６を構築する際、任意の組合せおよび任意の数のインターフェース（Ｎ階層）を互いに積み重ねることができる。
【００２６】
好ましい実施形態では、コラボレーションプラットフォーム２００は、グローバルな、企業規模の配置をサポートするための柔軟なＰＬＭ（製品ライフサイクル管理）環境を提供する。好ましくは、コラボレーションプラットフォーム２００は、製品構想から製品経験までの情報および知識に関連した、すべての製品のアクセスおよび管理を可能にする、さまざまな非ネイティブおよびネイティブなアプリケーション２０２、２３２、２４０のための単一で開かれた環境／プラットフォームである。プラットフォーム２００は、すべてのエンジニアリング専門分野、およびすべてのＰＬＭ企業ビジネスプロセスとは言わないまでも、その多くにわたる。
【００２７】
コラボレーションプラットフォーム２００は、ビジネスプロセス、ユーザインターフェース、およびインフラストラクチャオプションを容易に構成するための柔軟性を提供して、できる限り低いトータルの維持費で、現在および将来において、それらが組織のニーズを満たすことを確実にする。その目的のために、プラットフォーム２００のインフラストラクチャサービスの１つが、図１Ａに示すアダプレット（Ａｄａｐｌｅｔ）１２０と呼ばれるアプリケーション適合インターフェースである。アダプレット１２０によって、アプリケーションサーバー２３６は、プラットフォーム２００にネイティブではないデータソースと通信し、このデータをあたかもコラボレーションプラットフォーム２００にネイティブであるかのように表すことが可能になる。
【００２８】
本発明は、図１Ｃ〜図５を参照して次に説明するように、プラットフォーム２００のアダプレット１２０インフラストラクチャを強化する。
【００２９】
アダプレットＡＰＩは、外的な（外部の）または非ネイティブなシステム３００（例えばＣＲＭ（Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ）、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）、または他の任意の企業アプリケーション）から、ビジネスエンティティ／オブジェクトを「適合させる」ことによって、コラボレーションプラットフォーム２００のストレージ管理層２２０（図１Ａ）の拡張を可能にする。アダプレットインターフェース／ＡＰＩの具体的な実装（インスタンス）は、アダプレット１２０と呼ばれ、ビジネスオブジェクト／エンティティ１２１、およびそのリレーションシップを収集し、それらがコラボレーションプラットフォーム２００（モデリングクエリ言語−ＭＱＬ層、およびアプリケーション開発キット−ＡＤＫ層）によって活用することができる。
【００３０】
各アダプレット１２０は、ターゲット（外部）システム３００に固有であり、プラットフォームネイティブアプリケーション２０２、２３２、２４０が活用することができる別個のヴォールト（Ｖａｕｌｔ）１２５（図１Ａ）として現れる。アダプレットヴォールト１２５に発行されたクエリは、非アダプレットヴォールト１２６から見分けがつかない方法で、ビジネスオブジェクト１２１およびリレーションシップを戻す。
【００３１】
アダプレット１２０は、プラットフォーム２００と他のシステム３００との間でリアルタイムな相互運用を可能にし、他のシステム３００の混乱を起こすことなく、ＩＴにわずかな負荷しかかけずに、複数のソースから統合された情報を提供する。アダプレット１２０を用いることで、プラットフォームユーザは、他のシステム３００に記憶されている情報に、あたかもそれが実際にプラットフォーム２００の一部であるかのようにアクセスできる。外部から記憶された情報は、ネイティブプラットフォームデータから見分けがつかないようにされる。ネイティブプラットフォーム情報上で実行可能なオペレーションは、ターゲットシステム３００から外部情報上でもまた実行可能である。
【００３２】
アダプレット１２０同士は、互いに類似した性能を有する。
（ａ）アダプレットは、統合されたトランザクションマネジメントと双方向である。ターゲットシステム３００は、二相コミットを実装してもよく、または一相データソースとしても扱われることができる。
（ｂ）アダプレットは、ビジネスオブジェクト１２１を公開し、適合した／外的なシステム３００のビジネスオブジェクト１２１同士の接続を公開する。
（ｃ）アダプレットは、スキーマを拡張し、複合オブジェクト１２１を構築する機能を有する。いくつかのオブジェクト１２１の属性は、コラボレーションプラットフォーム２００に常駐し、他は適合した／外的なシステム３００に常駐することができる。結合されたオブジェクト１２１は、コラボレーションプラットフォーム２００を介して、単一のオブジェクトとして現れる。
（ｄ）アダプレットは、異なる連合体においてオブジェクト同士を接続する機能を有する。プラットフォーム２００リレーションシップは、ネイティブビジネスオブジェクトを、適合した／外的なヴォールト１２５のオブジェクト１２１に接続する、または、別の適合した／外的なヴォールト１２５のオブジェクト１２１に接続するのに使用することができる。
【００３３】
本発明より以前において、アダプレットインターフェースは、以下のように、２つの異なるアーキテクチャを使用して構成することができた。１つのオプションは、外部データソースへの直接データベース接続に基づいていた。アダプレットはまた、ウェブサービスＡＰＩ１５０を使用して実装することができたが、以下ではそれをＷＳＡ（ウェブサービスアダプレット／Ｗｅｂ Ｓｅｒｖｉｃｅ Ａｄａｐｌｅｔ）と呼ぶ。
【００３４】
一実施形態では、ウェブサービスアダプレットは、ウェブサービス１５０を介して（ターゲットシステム３００の）外的な／外部データベースと対話するＪａｖａ（登録商標）アダプレットである。コラボレーションプラットフォーム２００は、ウェブサービス１５０のクライアントサイドを提供する。プラットフォームクライアント２００と、適合したシステム３００との間のハンドシェイクが、プラットフォーム２００が提供するＷＳＤＬファイル１３０によって定義される。ＷＳＤＬファイル１３０は、ウェブサービス１５０が理解するメッセージ、それらのメッセージに対する応答のフォーマット、サービス１５０がサポートするプロトコルなどを記述する。
【００３５】
顧客は、適切なＪａｖａ（登録商標）ツールまたはＣシャープツール１１０と一緒にこのＷＳＤＬファイル１３０を使用して、スタブおよびスケルトンファイル１１１を生成することができる。スタブおよびスケルトンファイル１１１は、ウェブサービス１５０を動かすためにランタイムで使用される。
【００３６】
ＷＳＤＬツール１１０により作成されたファイル１１１のうちの１つがスケルトンであり、スケルトンのパブリック関数は、クライアントプラットフォーム２００によって行われた呼び出しへの返答を提供するコードで書き込まれなければならない。このスケルトン１１１の関数の多くが、適合したシステム３００からのデータを入手、または設定する。他のいくつかは、トランザクション制御に従事する。
【００３７】
ＷＳＡアダプレットより戻されたオブジェクト／リレーションシップ１２１は、物理レベルおよび論理レベルの両方において、プラットフォーム２００内で構造オブジェクト／リレーションシップに合致しなければならない。ターゲットシステム３００からの応答データが、統合されたマッピングエンジンによって、プラットフォーム２００のビジネスオブジェクト／リレーションシップ１２１にマップされる。その目的のために、ＷＳＡアダプレットは、適合したシステム３００が公開するように要求する、「Ｔｙｐｅｓ」「Ａｔｔｒｉｂｕｔｅｓ」「Ｒｅｌａｔｉｏｎｓｈｉｐｓ」などを記述するスキーマファイル１３５を（統合されたマッピングエンジンを介して）使用する。
【００３８】
外部システム３００からビジネスオブジェクト／データ１２１を抽出するためには、ＷＳＡアダプレットを構成する必要があり、各ターゲットシステム３００は、アダプレットＡＰＩによって公開されたインターフェースに準拠する特定のそれぞれのウェブサービス１５０を実装（すなわち、ＷＳＤＬ１３０で定義され、スケルトンファイル１１１でコード化されたオペレーション／メソッドを実装）しなければならない。実際には、これは、コラボレーションプラットフォーム２００を外的な／外部システム３００に橋渡しするために、統合が、事実上、中間層（ターゲットシステム３００固有のＷＳＡアダプレット）が作成されるのを必要とすることを意味する。これは、統合をより複雑でコストのかかるものにする。
【００３９】
さらに、ＷＳＡ（ウェブサービスアダプレット）は、外的なシステム３００の既存のウェブサービス１５０を活かして、外部データを連合することができない。というのは、これらのウェブサービス１５０は、ＷＳＡアダプレットによって定義されたインターフェースに準拠していないからである。
【００４０】
最後に、これらのウェブサービスアダプレットの限界として、ウェブサービスアダプレットは、データを抽出している間に連合データの関係または誘導可能性を考慮しない。
【００４１】
本発明は、アダプレットインフラストラクチャを強化して、これに改良を加える。本発明により取られるアプローチは、上述されたものとは根本的に異なり、クエリ構文を定義しながら、連合データの関係およびその誘導可能性を見るものである。本発明は、以下にさらに説明するように、ウェブサービス呼び出しの連鎖を使用して、そこからオブジェクト１２１が生成される複合「ドキュメントオブジェクトモデル」を形成する。
【００４２】
したがって、本発明は、先行ＷＳＡ（ウェブサービスアダプレット）の使用をより容易にする。出願人は、本発明が、ＷＳＡ技術の採用を大いに増加させると考える。また、本発明の実施形態により、コラボレーションプラットフォーム２００は、非構造化データ（患者記録、その他）などの、従来とは異なるデータの中央レポジトリとなることができる。
【００４３】
コラボレーションプラットフォーム２００に対する本発明のいくつかの効果は以下である。
（１）企業間、さらにビジネスパートナー間で、データを交換し、プロセスを自動化する機能を提供する。
（２）ユーザが複数のシステムからの情報によって作業できるようにすることにより、グローバルなビジネスコラボレーションを奨励する。この情報の全体論的観点が、よりよい意思決定支援システム、低コストへの移行、およびより早い製品開発サイクルを可能にすることになる。
（３）他のデータベースからのデータの段階的な結合および移動を提供する。
（４）異なるシステムに常駐する製品情報を、それがあたかもプラットフォームデータベース／ストレージ層２２０に記憶されているかのように表示することを可能にする。
（５）複数のデータソースをリンクする際の、開発の手間および複雑なコーディングを軽減する。
【００４４】
先行ウェブサービスアダプレットと比較して、本発明の主要な効果は、外的なシステムまたはターゲットシステム３００での既存のソフトウエア資産（既存のウェブサービス１５０）の再利用である。本発明はまた、外部システム３００からデータを連合するための、いかなる追加の「コーディング」も必要としない。
【００４５】
図１Ｃ〜図４に戻って、次に、本発明の実施形態について詳細に説明する。本発明のアダプレット１２０アーキテクチャおよび実装によって、ターゲットシステム３００上の既存のウェブサービス１５０の利用が可能になる。この強化に加えて、本発明は、単一のルートから任意のドキュメント／サービス（応答）の任意のノードを識別することができる「一意の」クエリ／マッピング構文２５を定義する。
【００４６】
図２に示すように、ターゲットシステム３００は、「ｇｅｔＳｔａｎｄａｒｄＩｎｆｏ」および「ｇｅｔＭａｔｅｒｉａｌＩｎｆｏ」について、別々のウェブサービス１５０ａ、ｂを公開する。「ｇｅｔＳｔａｎｄａｒｄＩｎｆｏ」サービス呼び出し１５０ａからの応答は、「ｇｅｔＭａｔｅｒｉａｌＩｎｆｏ」ウェブサービス１５０ｂに必要な入力（「ｍａｔｅｒｉａｌｉｄ」）を含む。本発明のアダプレット１２０は、呼び出しを論理的に順番に追加する、または連鎖させることによって、これら２つのサービス呼び出し１５０ａ、１５０ｂの結合したビュー３２を形成する。結合したビュー３２は、単一の論理ドキュメントのように見ることができる。
【００４７】
結合されたビュー３２から、マッピングエンジン３５が、プラットフォームスキーマ１３５へのマッピングを単純化する（図３）。マップされたビュー３４が結果物となる。これは、以下のように実現される。パス言語が、単一の「ルート」から任意のドキュメント（またはサービス１５０）の任意のノードを識別することができる。次に、マッピングエンジン３５が、図４に示すように、クエリ／マッピング構文２５を実装する。
【００４８】
マッピング２５は、各ノードがサービス１５０を呼び出すことができる簡単なパスを示す。パス定義はまた、「マクロ」構文を利用して、ＵＲＬに似た方法で引き数またはパラメータを渡す。マッピング２５は、ルートコンテキスト２１および導出されたコンテキスト２３のような、オブジェクトコンテキストに基づく事前定義されたマクロを使用する。例えば、ルートコンテキスト２１として、＄（名前）が、図４に示す例の中で用いられている。
【００４９】
マッピング２５はまた、ドキュメント／応答メッセージ内容に基づく動的なマクロを使用する。これは、図示された例の中で、導出されたコンテキスト２３：＄（ｍａｔｅｒｉａｌｉｄ）として示されている。
【００５０】
図１Ｃおよび図５を参照すると、例示的な、限定しない一実施形態における本発明のアダプレット１２０の実装およびオペレーションは、以下の通りである。アダプレット１２０は、ターゲットシステム３００の既存の（あらかじめ定義された／提供された）ウェブサービス１５０を介してターゲットシステムデータベースと対話するＪＡＶＡ（登録商標）コンポーネントとして実装される。図１Ｂにおいて上で説明したように、プラットフォーム２００は、ＪＡＶＡ（登録商標）をはじめ、他の（複数の）コンピューターキテクチャをサポートすることができる。したがって、アダプレット１２０の実装は、ＪＡＶＡ（登録商標）に限定されない。コラボレーションプラットフォーム２００は、ウェブサービス１５０のクライアントサイドを提供する。アダプレット１２０インターフェースが、ターゲットシステム３００によって公開されるウェブサービス１５０のために、ＷＳＤＬファイル１３０を取得する（図５のステップ５０１）。ＷＳＡアダプレットの場合において前に述べたように、クライアントプラットフォーム２００と、ターゲットシステム３００との間のハンドシェイクは、ＷＳＤＬファイル１３０によって定義され、ＷＳＤＬファイル１３０は、それぞれのウェブサービス１５０が理解するメッセージ、それらのメッセージに対する応答のフォーマット、サービスがサポートするプロトコルなどを記述する。
【００５１】
ユーザは、適切なＪＡＶＡ（登録商標）ツール１１０と一緒にＷＳＤＬファイル１３０を使用して、スタブおよびスケルトンファイル１１１を生成する。スタブおよびクライアントクラスは、スキーマファイル１３５（例えば、Ｓｃｈｅｍａ．ｘｍｌ）に記述されているように複雑なビジネスオブジェクトを組み立てるために、プロバイダクラス１４０によってランタイムに使用される。ユーザは、先行ＷＳＡアダプレットでのように、ターゲットシステム３００によって実装されるべきメソッドを用いてスケルトンファイル１１１に書き込みをする必要はない。
【００５２】
次に、アダプレットインターフェースがパラメータファイル１３３を記述し（図５、ステップ５０３）、これが構成設定を行うためのメカニズムとなる。ステップ５０３はまた、プロバイダクラス１４０、およびターゲットシステム３００により公開されるウェブサービス１５０ａ、ｂ、・・・ｎへのエンドポイントを定義する。アダプレット１２０インターフェースは、ＸＭＬファイルを、アダプレットヴォールト１２５の記述と一緒にデータベース１２３に記憶する。このＸＭＬファイルが構文解析され、一部は「Ａｄｄ Ｖａｕｌｔ」コマンド（後述）への入力として使用され、一部はスキーママップとしてアダプレットプロバイダのｉｎｉｔ（ ）エントリポイントの中に渡される。
【００５３】
ステップ５０５で、スキーマファイル１３５を記述する。内容、すなわちスキーママップは、クライアントプラットフォーム２００を介して、プロバイダのｉｎｉｔ（ ）呼び出しに応答して戻される。一実施形態では、スキーママッピングファイル１３５は、ＸＭＬファイルである。アダプレット１２０によって戻されたオブジェクト／リレーションシップ１２１は、コラボレーションプラットフォーム２００内で構造オブジェクト／リレーションシップに合致しなければならない。マッピングは、アダプレット１２０実装の任務である。リレーショナルアダプレット１２０は、リレーショナルデータをビジネスオブジェクトに変換するマッピングエンジン３５を用いて、これを実現する。
【００５４】
ステップ５０７で、プロバイダクラス１４０は、インターフェース（例えば、一実施形態におけるｆｆプロバイダインターフェース）を実装する。これは、既存の対象ウェブサービス１５０インターフェースを使用して、クエリインターフェースを実装するために、プロバイダクラス１４０によって提供される。一実施形態では、図４のクエリ／マッピング構文２５が、プロバイダクラス１４０の中に構築される。しかしながら、他の実施形態では、クエリ／マッピング構文２５は、プロバイダクラス１４０の外側にあって、リレーションシップを誘導し、既存のウェブサービス１５０からの結果を結合してもよい。
【００５５】
プロバイダクラス１４０生成インターフェースは、先行ＷＳＡアダプレットのアプローチおよび以下のユーザの要件、（ｉ）ターゲットシステムによって実装されるメソッドを用いてスケルトンファイル１１１に書き込むこと、（ｉｉ）各ターゲットシステムにおいてウェブサービス／スケルトンクラスメソッドを実装すること、に取って替わることに留意されたい。
【００５６】
ステップ５０９で、アダプレット１２０インターフェースは、ＭＱＬコマンド：Ａｄｄ Ｖａｕｌｔ ［ｖａｕｌｔｎａｍｅ］ ｅｘｔｅｒｎａｌ ｆｉｌｅ ［ｆｉｌｅｎａｍｅ］を実行する。ここで、［ｆｉｌｅｎａｍｅ］が、ステップ５０３で記憶されたパラメータファイル１３３のＸＭＬファイルから読み出される。これにより、クライアントプラットフォーム２００／アダプレット１２０は、ターゲットシステム３００の、あらかじめ存在した／提供されたウェブサービス１５０呼び出しの１つまたは複数を利用することによって、複雑なビジネスオブジェクトについてターゲットシステムデータに対するクエリを行う。詳細には、図２においてあらかじめ説明したように、アダプレット１２０は、ウェブサービス呼び出しを連鎖させる。
【００５７】
次に、プロバイダクラス１４０は、スキーマファイル１３５のスキーママップに従って、対象の複雑なビジネスオブジェクト１２１を組み立てる（構築する）。詳細には、プロバイダクラス１４０は、呼び出された既存のウェブサービス１５０からの結果を結合し、マッピングエンジン３５は、（図３および図４において上で詳述したように）ウェブサービス呼び出し構文からプラットフォーム２００スキーマにマップする。
【００５８】
本発明のアダプレット１２０は、複数のウェブサービス１５０応答メッセージを連鎖させ、結合されたビュー３２およびマップされたビュー３４（ドキュメントオブジェクトモデル）を利用して、適切かつ「一意の」マッピング２５を定義するその能力においてユニークであり、それにより、外部システム３００からオブジェクト１２１を連合する。
【００５９】
可能性のある使用機会において、本発明のアダプレット１２０は、いかなる追加のコーディング／クラスメソッドのターゲットシステム実装なしに、既存のウェブサービス１５０の再利用を促進し、場合によっては、複数ドメインにわたり構文マッピング２５を連結することができる。本発明のアダプレット１２０は、ターゲットシステム３００がプラットフォーム２００定義のサービスを実装することを必要とする、既存のウェブサービスアダプレット実装に改良を加える。
【００６０】
本発明のアダプレット１２０の別の可能性のある適用は、ドキュメント／サービス１５０が内在する構造、従属関係を有し、誘導を必要とする場合の問題に対してである。一例は、ＲＴＦ（Ｒｉｃｈ Ｔｅｘｔ Ｆｏｒｍａｔ）／ｘｍｌフラグメントを、単一アセンブリに統合する要求管理（Ｒｅｑｕｉｒｅｍｅｎｔｓ Ｍａｎａｇｅｍｅｎｔ）においてである。別の例は、「元の場所に」残され、専用のウェブサービスを介して参照されるドキュメントである。８０％の企業知識は、リレーショナルデータベースではなく、ファイルサーバーの中に放置されている。適所にあるドキュメントにアクセスすることによって、ユーザは、人の仕事の方法を変更することなく、この情報を活かすことができる。
【００６１】
既存のアダプタおよび連合ツールキットが、ビジネスオブジェクトの２地点間統合を行う。それらは、関係／従属関係を有するオブジェクト／データについて、システム間のマッピングを定義する必要性には取り組まない。
【００６２】
図６は、本発明を実装することができるコンピューターネットワーク、または同様のデジタル処理環境を図示する。
【００６３】
クライアントコンピューター／デバイス５０（例えばアプリケーション実行クライアント２０４）、およびサーバーコンピューター６０（例えばウェブサーバー２３８、およびプラットフォーム２００のアプリケーションサーバー２３６）は、アプリケーションプログラムなどを実行する処理デバイス、ストレージデバイス、および入力／出力デバイスを提供する。クライアントコンピューター／デバイス５０はまた、通信ネットワーク７０を介して、他のクライアントデバイス／プロセッサー５０として実装されるターゲットシステム３００、およびサーバーコンピューター６０などの、他のコンピューティングデバイスにリンクされてよい。通信ネットワーク７０は、リモートアクセスネットワーク、グローバルネットワーク（例えばインターネット）、コンピューターのワールドワイドな集合形態、ローカルエリアネットワークまたはワイドエリアネットワーク、および一般にそれぞれのプロトコル（ＴＣＰ／ＩＰ、Ｂｌｕｅｔｏｏｔｈなど）を使用して互いに通信するゲートウェイの一部であってよい。他の電子デバイス／コンピューターネットワークアーキテクチャも適している。
【００６４】
図７は、図６のコンピューターシステムにおけるコンピューター（例えばクライアントプロセッサ／デバイス５０、またはサーバーコンピューター６０）の内部構造の図である。各コンピューター５０、６０は、システムバス７９を含み、ここでバスは、コンピューターまたは処理システムのコンポーネントの間でデータを転送するために使用される一組のハードウェアラインである。バス７９は、基本的に、コンピューターシステムの異なる要素（例えば、プロセッサ、ディスクストレージ、メモリ、入力／出力ポート、ネットワークポート、その他）を接続する共用の電線であり、バスによって要素間で情報の転送が可能になる。システムバス７９には、さまざまな入力および出力デバイス（例えば、キーボード、マウス、ディスプレイ、プリンタ、スピーカ、その他）を、コンピューター５０、６０に接続するためのＩ／Ｏデバイスインターフェース８２が取り付けられている。ネットワークインターフェース８６によって、コンピューターは、ネットワーク（例えば図６のネットワーク７０）に取り付けられた、さまざまな他のデバイスに接続することが可能になる。メモリ９０は、本発明の実施形態（例えば、アダプレット１２０、マッピングエンジン３５、ならびにクエリ／マッピング構文２５および詳細に上述された他のコードのサポート）を実装するのに使用されるコンピューターソフトウエア命令９２およびデータ９４に、揮発性ストレージを提供する。ディスクストレージ９５は、本発明の実施形態を実施するのに使用されるコンピューターソフトウエア命令９２およびデータ９４に、不揮発性ストレージを提供する。中央処理装置８４がまた、システムバス７９に取り付けられ、コンピューター命令の実行に備える。
【００６５】
一実施形態では、プロセッサルーチン９２およびデータ９４は、コンピュータープログラム製品（総称して参照９２）であり、これは、本発明のシステムのためのソフトウエア命令の少なくとも一部を提供するコンピューター可読媒体（例えば、１つまたは複数のＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ、ディスケット、テープ、その他などの着脱可能なストレージ媒体）を含む。コンピュータープログラム製品９２は、当技術分野でよく知られているように、任意の好適なソフトウエアインストール手続きによって、インストールすることができる。別の実施形態では、ソフトウエア命令の少なくとも一部をまた、ケーブル、通信接続および／またはワイヤレス接続を通してダウンロードすることができる。他の実施形態では、本発明のプログラムは、伝播媒体（例えば、電波、赤外線波、レーザー波、音波、またはインターネットなどのグローバルネットワークもしくは他のネットワーク上で伝播される電気波）上の伝播信号で具体化されるコンピュータープログラム伝播信号製品１０７である。そのようなキャリア媒体または信号は、本発明のルーチン／プログラム９２に、ソフトウエア命令の少なくとも一部を提供する。
【００６６】
代替実施形態では、伝播信号は、アナログキャリア波、または伝播媒体上で搬送されるデジタル信号である。例えば、伝播信号は、グローバルネットワーク（例えばインターネット）、電気通信ネットワーク、または他のネットワーク上で伝播されるデジタル化された信号であってよい。一実施形態では、伝播信号は、所定期間にわたって伝播媒体上に伝送される信号であり、例えば、ミリ秒、秒、分、またはより長い期間にわたってネットワーク上のパケットで送信されるソフトウェア・アプリケーション用の命令である。別の実施形態では、コンピュータープログラム製品９２のコンピューター可読媒体は、コンピュータープログラム伝播信号製品について上述したように、例えば伝播媒体を受信し、伝播媒体において具体化された伝播信号を識別することによって、コンピューターシステム５０が受信し、読み取ることができる伝播媒体である。
【００６７】
一般的に言えば、用語「キャリア媒体」すなわち遷移キャリアは、前述の遷移信号、伝播信号、伝播媒体、ストレージ媒体などを包含する。
【００６８】
本発明を、その例示的な実施形態を参照して詳細に示し、説明してきたが、当業者であれば、添付の特許請求の範囲によって包含される本発明の範囲から逸脱することなく、本発明において、形態および詳細にさまざまな変更を行うことができることを理解するであろう。
【技術分野】
【０００１】
ターゲットシステムのデータへのアクセスを提供するコンピューターの方法およびシステムに関する。
【背景技術】
【０００２】
インターネットなどのグローバル・コンピューターネットワークが、新たなコンピューティング・プラットフォーム、およびコンピューティング・アプリケーション（ソフトウェア・アプリケーション設計を含む）を提供している。例えば、インターネット規模の分散コンピューティングは、いわゆるプラットフォーム・コンピューティングのようなネットワークを提供する。プラットフォームとしてのネットワークは、（ウェブ対応アプリケーションとして構成された）アプリケーションについて、ブラウザを介して全面的に実行できるようにする。さらに、プラットフォームとしてのネットワークによって、ユーザは、さまざまな役割にわたり、またはその役割の中で、共同作業することが可能になる。
【０００３】
所与のウェブ対応アプリケーションに関して、ユーザ／クライアント（分散オブジェクトアーキテクチャクライアント）は、個々のブラウザを介してアプリケーションを実行する。ブラウザは、アプリケーションサーバー（分散オブジェクト・サーバー）と通信する。さらにブラウザは、ウェブサーバーと通信する。認証サービス、トランザクションサービス、ネーミングサービス、アドミニストレーションサービス、およびセキュリティサービスなどの多くのサービスが、アプリケーションサーバーおよびウェブサーバーの両方に複製される。各ユーザ／クライアントは、一般的に、別々にプラットフォームに登録される。また、各ユーザ／クライアントは、各組のウェブサーバーサービスの実行に関与する。
【０００４】
今までのところ、プラットフォームにおけるクライアントとしてのユーザが、複数のアプリケーションにわたって、データをコピーし、他のデータに関与する、または既存のウェブサーバーサービスを活用するためのメカニズムはない。
【０００５】
プラットフォームとしてネットワークを利用する、コンピューター実施プログラムおよび協調システムの産業上の一例は、製品ライフサイクル管理（Ｐｒｏｄｕｃｔ Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ／ＰＬＭ）システムである。ＰＬＭソリューションは、企業活動の拡大を概念にして、製品開発のために、構想の段階から製品寿命の終わりまで、企業が、製品データを共有し、共通プロセスを適用し、企業知識を活用することを支援するビジネス戦略を指す。この概念によれば、企業は、その企業の部門のみならず、ビジネスパートナー、サプライヤ、ＯＥＭ（Ｏｒｉｇｉｎａｌ Ｅｑｕｉｐｍｅｎｔ Ｍａｎｕｆａｃｔｕｒｅｒｓ）、および顧客などの他の関係者からも構成される。これらの関係者を含めることにより、ＰＬＭは、このネットワークが単一のエンティティとして機能して、製品およびプロセスを概念化し、設計し、構築し、サポートすることを可能にする。
【０００６】
ＰＬＭソリューションの中には、コンピューター支援技術があり、コンピューター支援設計（Ｃｏｍｐｕｔｅｒ−Ａｉｄｅｄ Ｄｅｓｉｇｎ／ＣＡＤ）が知られている。コンピューター支援設計は、製品設計を記述するためのソフトウエアソリューションに関する。同様に、ＣＡＥは、コンピューター支援エンジニアリング（Ｃｏｍｐｕｔｅｒ−Ａｉｄｅｄ Ｅｎｇｉｎｅｅｒｉｎｇ）の頭字語であり、例えば、将来製品の物理的な動作をシミュレートするためのソフトウエアソリューションに関する。ＣＡＭは、コンピューター支援製造（Ｃｏｍｐｕｔｅｒ−Ａｉｄｅｄ Ｍａｎｕｆａｃｔｕｒｉｎｇ）を表し、一般的に、製造過程および製造作業を定義するためのソフトウエアソリューションを含む。いくつかのＰＬＭソリューションは、例えば、デジタルモックアップ（製品の３Ｄグラフィカルモデル）を作成することによって、製品を設計し、開発することを可能にする。適切なアプリケーションを使用して、最初にデジタル製品を定義し、シミュレートすることができる。次いで、無駄のないデジタル製造プロセスを定義し、モデル化することができる。
【０００７】
例えば、一般に、Ｄａｓｓａｕｌｔ Ｓｙｓｔｅｍｅｓにより（ＣＡＴＩＡ、ＥＮＯＶＩＡ、およびＤＥＬＭＩＡの商標下において）提供されるＰＬＭソリューションは、製品エンジニアリング知識を構成するエンジニアリングハブ、製造エンジニアリング知識を管理するマニュファクチャリングハブ、ならびにエンジニアリングハブおよびマニュファクチャリングハブの両方への事業統合および事業結合を可能にするエンタープライズハブを提供する。これら全てのシステムはともに、製品、プロセス、リソースをリンクするオープンなオブジェクトモデルを実現して、動的な知識ベースの製品創造、および最適化した製品定義、製造準備、生産およびサービスを推進する意思決定支援を可能にする。
【０００８】
このＰＬＭソリューションは、製品のリレーショナルデータベースを含む。リレーショナルデータベースは、一組のテキストデータを含み、かつデータ間の関係を含む。データは、一般的に、データの階層順に並べられた、製品に関連した技術データを含み、検索できるようにインデックス付けされている。データは、しばしばモデル化された製品およびプロセスである、モデル化されたオブジェクトを表す。
【０００９】
製品構成、プロセス知識、およびリソース情報を含むＰＬＭ情報は、一般的に、協調的な方法により編集されることを目的とする。例えば、協調的な方法で作業する設計者のチームは、ウェブ対応アプリケーションを介して、リモートサイトから製品に関連した共有情報にアクセスすることによって、個々に貢献して製品を設計する。各ユーザまたはリモートサイトは、システムプラットフォームに別々に登録され、それぞれが、このプロジェクトのアプリケーション用のそれぞれの組のウェブサーバーサービスの実装に関与する。ユーザは、もともと他のアプリケーション用に実装される既存のウェブサービスを有していることがあるけれども、進行中のプロジェクトに関して、これらのウェブサービスを再利用、または共有するためのメカニズムがない。プラットフォームのクライアントのユーザまたはアプリケーションが、既存のウェブサービスをコピーする、または別の方法で活用する必要がある。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】米国特許第６９３４７０９号明細書
【発明の概要】
【００１１】
本発明は、前述の先行技術の欠点に取り組む。詳細には、本発明は、２つ以上のアプリケーションにわたるクライアントシステムのウェブ（グローバルコンピューターネットワークサーバー）サービスの再利用、または共通使用を可能にする、コンピューター手法、システム、および装置を提供する。
【００１２】
好ましい実施形態では、本発明のシステムは、アプリケーションインターフェースと、マッピングメンバーとを含む。アプリケーションインターフェースは、複数のウェブサービスを介して、データを公開しているターゲット（クライアント）システムと相互作用する。アプリケーションインターフェースは、公開されたデータにクエリを行う。アプリケーションインターフェースは、２つ以上のアプリケーションにわたって、複数のウェブサービスのうちの少なくとも１つを共通して使用することにより、ターゲットシステムに関するアプリケーション間で、既存の（あらかじめ提供された）ウェブサービスを再利用する。
【００１３】
この再利用を実現するために、アプリケーションインターフェースは、ターゲットシステムからウェブサービスデータの結合されたビューをもたらす方法で、ターゲットシステムのウェブサービスのうちの少なくとも２つへ呼を連鎖させる。少なくとも２つのウェブサービスは、ターゲットシステムによってあらかじめ提供されている。
【００１４】
マッピングメンバーは、グローバルコンピューターネットワークサービスを介して、公開されるデータのアプリケーションインターフェースクエリ（ａ）と、対象アプリケーションにおいて使用可能なオブジェクトの構文（ｂ）の間をマップする。マッピングメンバーは、対象アプリケーションを、アプリケーションインターフェースによって実装されるクエリに応答して生成されたオブジェクトインスタンスのデータにアクセスできるようにする。
【００１５】
いくつかの実施形態では、ターゲットシステムは、協調プラットフォームまたは類似のプラットフォームに対して外部または外的なシステムであり、分散オブジェクトアーキテクチャクライアントとして構成されている。対象アプリケーションは、任意のコンピューターシステムとして実装される。また、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）クライアント、ＲＭＩ（ｒｅｍｏｔｅ ｍｅｔｈｏｄ ｉｎｖｏｃａｔｉｏｎ）クライアント、ＥＪＢ（ｅｎｔｅｒｐｒｉｓｅ ＪＡＶＡ（登録商標） Ｂｅａｎ）クライアント、およびＪＮＩ（ＪＡＶＡ（登録商標） Ｎａｉｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）クライアントのうちの任意のものとして実装される。
【００１６】
一実施形態では、本発明は、外部システム（ターゲットクライアント）と統合するコラボレーションプラットフォームの能力を強化する。具体的には、実施形態によって、プラットフォームが、クエリデータを提供するウェブサービスを供給する外部システムとデータを共有することが可能になることから、プラットフォームのストレージ層を拡張するためのインターフェースが、本発明により恩恵を受ける。本発明は、宣言的な方法により、ウェブサービス呼び出し（複数のクエリ）のシーケンスを記述する機能を提供する。本発明の実装は、ウェブサービス呼び出しのシーケンスを実行して、データの統合されたビューを生成する。これにより、外的なデータを記述する単純化した方法を促進し、この外的なデータを、ＰＬＭ（製品ライフサイクル管理）データモデルに容易にマッピングする方法を可能にする。ＰＬＭデータモデルは、（ＰＬＭ、ＣＶ５、その他などの）プラットフォームアプリケーションによって、固有に使われる。
【００１７】
したがって、本発明は、関係／従属関係に基づく「統一されたビュー」を見る一意のクエリ／マッピング構文を定義し、既存のウェブサービスを利用して外部データを連合する。本発明は、いかなる追加の「コード」も書くことなく、外部システムからデータを連合する問題を解決し、それにより、時間およびコストを節約する。本発明はまた、コラボレーションプラットフォームが、データ連合を必要とするさまざまなアプリケーションをホストするための機会を広げる。その目的のために、本発明は以下の問題に取り組む。
１．複数のシステムにわたって製品材料を探す無駄な時間
２．別々の企業システムが同期を取り続けるようにする複雑な統合
３．別々のシステムで作業するユーザ間の非効率なコラボレーション
４．データ移行の複雑さによりレガシーシステムを退却させる困難性
５．データを他のシステムに再入力することによる作業の重複
６．手作業のユーザ介入を使用する、外部サプライヤとの非効率なデータ共有
【００１８】
したがって、本発明の実施形態は、インフラストラクチャレベルのソリューションを提供し、このインフラストラクチャの使用を意図する任意のコンシューマによって定義されなければならない一意のクエリ構文を定義する。
【図面の簡単な説明】
【００１９】
前述の事項は、添付の図面において図示されるように、以下の本発明の例示的な実施形態のより詳細な説明から明らかになるであろう。添付の図面は、異なる図の全体にわたって同様の参照記号が同じ部品を指す。図面は必ずしも縮尺どおりではなく、むしろ、本発明の実施形態を例示することに重点を置いている。
【図１Ａ】本発明の実施形態が配置されたコラボレーションプラットフォームの概略ブロック図である。
【図１Ｂ】本発明の実施形態が配置されたコラボレーションプラットフォームの概略ブロック図である。
【図１Ｃ】本発明の実施形態が配置されたコラボレーションプラットフォームの概略ブロック図である。
【図２】ターゲットシステムの複数のウェブ（グローバル・コンピューターネットワーク）サービスへの呼び出しを連鎖させて、ターゲットシステムからデータの結合されたビューをもたらす、本発明の実施形態の概略図である。
【図３】本発明の原理に従って、図１のプラットフォームスキーマにマップされている図２の結合されたビューの概略図である。
【図４】図２および図３の例におけるクエリ／マッピング構文を実装する、本発明のマッピングエンジンの概略図である。
【図５】本発明の一実施形態における処理およびデータ制御の流れ図である。
【図６】本発明の実施形態が動作するコンピューターネットワーク環境の概略図である。
【図７】本発明の実施形態が動作するコンピューターネットワーク環境のブロック図である。
【発明を実施するための形態】
【００２０】
以下は、本発明の例示的な実施形態の説明である。
【００２１】
本発明の実施形態を用いるコラボレーションプラットフォーム２００が、図１Ａおよび図１Ｂに図示されている。コラボレーションプラットフォーム２００は、分散オブジェクトアーキテクチャとして構成されている。コラボレーションプラットフォーム２００の好ましい実施形態は、さまざまなウェブブラウザ２２８（簡略化を目的に、図１Ｂに１つだけを図示）、ウェブサーバー２３８（明確化のため１つのみを図示）、アプリケーションサーバー２３６、およびストレージ層２２０（アプリケーションサーバーデータベース、対応するデータサーバーおよびファイルサーバーを含む）を含む。ウェブブラウザ２２８を介して、アプリケーション２０２（ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｉｎｇ Ｌａｎｇｕａｇｅ）クライアント２０４’として実装される）が実行される。ウェブブラウザ２２８は、ウェブサーバー２３８’に常駐するＸＭＬサーバー２０６’と（ファイアウォール２０８を介して）通信する。ウェブサーバー２３８’はまた、ＲＭＩ（Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ）クライアント２１０およびＸＭＬ−ＲＭＩインターフェース２２２を含む。
【００２２】
同様に、このアプリケーションおよび他のアプリケーション２０２は、ＲＭＩクライアント、ＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ（登録商標） Ｂｅａｎ）クライアント、ＪＮＩ（Ｊａｖａ（登録商標） Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）クライアントとして、および他のウェブサーバーキテクチャ上のクライアントとして実装することができる。これらのクライアントは、図１Ａの２０４で概略的に参照される。（概略的に参照されるように）対応するサーバー２０６は、ウェブサーバー２３８’の構成と同様に（すなわちそれぞれの該当するクライアント２１０およびインターフェース２２２と共に）構成される、それぞれのウェブサーバー２３８（図１Ａに概略的に参照される）に常駐する。
【００２３】
さらに図１Ｂに示すように、アプリケーションサーバー２３６は、ＲＭＩサーバー２１２、ＥＪＢクライアント２１４、ＥＪＢサーバー２１６に常駐する情報サービス２１８（永続性、メッセージング、ライフサイクル、ワークフロー、ポリシーマネジャ、アドミニストレーション、および構造管理）、およびＲＭＩ−ＥＪＢインターフェース２２４を含む。ウェブサーバー２３８’は、それ自身に常駐するＸＭＬ−ＲＭＩインターフェース２２２を介して、アプリケーションサーバー２３６と通信する。ウェブサーバー２３８’は、ＲＭＩ−ＥＪＢインターフェース２２４を介して、ＥＪＢサーバー２１６に常駐する情報サービス２１８とさらに通信する。これにより、上述した構成を使用して、アプリケーション２０２を使用するユーザは、ＸＭＬクライアント２０４’からウェブサーバー２３８’を介して、ＥＪＢサーバー２１６上の情報サービス２１８にアクセスすることができる。ＣＯＲＢＡベースのアーキテクチャに複製されるサービス（認証、セキュリティ、トランザクション、ネーミング、およびデータベースアドミニストレーション）は、ウェブサーバー２３８’によって提供され、アプリケーションサーバー２３６と共有される。この構成は、「ウェブセントリック（ｗｅｂｃｅｎｔｒｉｃ）」と呼ばれ、アプリケーション２０２は、（例えば、３階層ＣＯＲＢＡベースのウェブ対応アプリケーションとは対照的に）Ｎ階層である。アプリケーション２０２は、ウェブ上に配置され、ウェブサーバー２３８’またはアプリケーションサーバー２３６の、サービスおよびアドミニストレーション能力を十分に活かすことができる。
【００２４】
情報サービス２１８には、ネットワーク内の任意の地点からアクセスが可能である。例えば、ファイアウォール２０８内部からＲＭＩクライアント２３４上のアプリケーション２３２を実装するユーザは、ＲＭＩサーバー２１２からＲＭＩ−ＥＪＢインターフェース２２４を介して、ＥＪＢサーバー２１６上の情報サービス２１８にアクセスすることができる。同様に、ファイアウォール２０８内部からＥＪＢクライアント２４２上のアプリケーション２４０を実装するユーザは、ＥＪＢサーバー２１６から直接、ＥＪＢサーバー２１６上の情報サービス２１８にアクセスすることができる。アプリケーション２０２、２３２、および２４０は、異なるサーバー上で実装される同じアプリケーションである。
【００２５】
このように、プラットフォーム２００は、（ＣＯＲＢＡベースのアーキテクチャを有するような）一般的なウェブ対応の３階層アプリケーションに限定されず、譲受人により、参照によってその全体が本明細書に組み込まれる特許文献１に記述されているシステムコンパイラによって、Ｎ階層アプリケーションを有する。ウェブサーバー２３８およびアプリケーションサーバー２３６を構築する際、任意の組合せおよび任意の数のインターフェース（Ｎ階層）を互いに積み重ねることができる。
【００２６】
好ましい実施形態では、コラボレーションプラットフォーム２００は、グローバルな、企業規模の配置をサポートするための柔軟なＰＬＭ（製品ライフサイクル管理）環境を提供する。好ましくは、コラボレーションプラットフォーム２００は、製品構想から製品経験までの情報および知識に関連した、すべての製品のアクセスおよび管理を可能にする、さまざまな非ネイティブおよびネイティブなアプリケーション２０２、２３２、２４０のための単一で開かれた環境／プラットフォームである。プラットフォーム２００は、すべてのエンジニアリング専門分野、およびすべてのＰＬＭ企業ビジネスプロセスとは言わないまでも、その多くにわたる。
【００２７】
コラボレーションプラットフォーム２００は、ビジネスプロセス、ユーザインターフェース、およびインフラストラクチャオプションを容易に構成するための柔軟性を提供して、できる限り低いトータルの維持費で、現在および将来において、それらが組織のニーズを満たすことを確実にする。その目的のために、プラットフォーム２００のインフラストラクチャサービスの１つが、図１Ａに示すアダプレット（Ａｄａｐｌｅｔ）１２０と呼ばれるアプリケーション適合インターフェースである。アダプレット１２０によって、アプリケーションサーバー２３６は、プラットフォーム２００にネイティブではないデータソースと通信し、このデータをあたかもコラボレーションプラットフォーム２００にネイティブであるかのように表すことが可能になる。
【００２８】
本発明は、図１Ｃ〜図５を参照して次に説明するように、プラットフォーム２００のアダプレット１２０インフラストラクチャを強化する。
【００２９】
アダプレットＡＰＩは、外的な（外部の）または非ネイティブなシステム３００（例えばＣＲＭ（Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ）、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）、または他の任意の企業アプリケーション）から、ビジネスエンティティ／オブジェクトを「適合させる」ことによって、コラボレーションプラットフォーム２００のストレージ管理層２２０（図１Ａ）の拡張を可能にする。アダプレットインターフェース／ＡＰＩの具体的な実装（インスタンス）は、アダプレット１２０と呼ばれ、ビジネスオブジェクト／エンティティ１２１、およびそのリレーションシップを収集し、それらがコラボレーションプラットフォーム２００（モデリングクエリ言語−ＭＱＬ層、およびアプリケーション開発キット−ＡＤＫ層）によって活用することができる。
【００３０】
各アダプレット１２０は、ターゲット（外部）システム３００に固有であり、プラットフォームネイティブアプリケーション２０２、２３２、２４０が活用することができる別個のヴォールト（Ｖａｕｌｔ）１２５（図１Ａ）として現れる。アダプレットヴォールト１２５に発行されたクエリは、非アダプレットヴォールト１２６から見分けがつかない方法で、ビジネスオブジェクト１２１およびリレーションシップを戻す。
【００３１】
アダプレット１２０は、プラットフォーム２００と他のシステム３００との間でリアルタイムな相互運用を可能にし、他のシステム３００の混乱を起こすことなく、ＩＴにわずかな負荷しかかけずに、複数のソースから統合された情報を提供する。アダプレット１２０を用いることで、プラットフォームユーザは、他のシステム３００に記憶されている情報に、あたかもそれが実際にプラットフォーム２００の一部であるかのようにアクセスできる。外部から記憶された情報は、ネイティブプラットフォームデータから見分けがつかないようにされる。ネイティブプラットフォーム情報上で実行可能なオペレーションは、ターゲットシステム３００から外部情報上でもまた実行可能である。
【００３２】
アダプレット１２０同士は、互いに類似した性能を有する。
（ａ）アダプレットは、統合されたトランザクションマネジメントと双方向である。ターゲットシステム３００は、二相コミットを実装してもよく、または一相データソースとしても扱われることができる。
（ｂ）アダプレットは、ビジネスオブジェクト１２１を公開し、適合した／外的なシステム３００のビジネスオブジェクト１２１同士の接続を公開する。
（ｃ）アダプレットは、スキーマを拡張し、複合オブジェクト１２１を構築する機能を有する。いくつかのオブジェクト１２１の属性は、コラボレーションプラットフォーム２００に常駐し、他は適合した／外的なシステム３００に常駐することができる。結合されたオブジェクト１２１は、コラボレーションプラットフォーム２００を介して、単一のオブジェクトとして現れる。
（ｄ）アダプレットは、異なる連合体においてオブジェクト同士を接続する機能を有する。プラットフォーム２００リレーションシップは、ネイティブビジネスオブジェクトを、適合した／外的なヴォールト１２５のオブジェクト１２１に接続する、または、別の適合した／外的なヴォールト１２５のオブジェクト１２１に接続するのに使用することができる。
【００３３】
本発明より以前において、アダプレットインターフェースは、以下のように、２つの異なるアーキテクチャを使用して構成することができた。１つのオプションは、外部データソースへの直接データベース接続に基づいていた。アダプレットはまた、ウェブサービスＡＰＩ１５０を使用して実装することができたが、以下ではそれをＷＳＡ（ウェブサービスアダプレット／Ｗｅｂ Ｓｅｒｖｉｃｅ Ａｄａｐｌｅｔ）と呼ぶ。
【００３４】
一実施形態では、ウェブサービスアダプレットは、ウェブサービス１５０を介して（ターゲットシステム３００の）外的な／外部データベースと対話するＪａｖａ（登録商標）アダプレットである。コラボレーションプラットフォーム２００は、ウェブサービス１５０のクライアントサイドを提供する。プラットフォームクライアント２００と、適合したシステム３００との間のハンドシェイクが、プラットフォーム２００が提供するＷＳＤＬファイル１３０によって定義される。ＷＳＤＬファイル１３０は、ウェブサービス１５０が理解するメッセージ、それらのメッセージに対する応答のフォーマット、サービス１５０がサポートするプロトコルなどを記述する。
【００３５】
顧客は、適切なＪａｖａ（登録商標）ツールまたはＣシャープツール１１０と一緒にこのＷＳＤＬファイル１３０を使用して、スタブおよびスケルトンファイル１１１を生成することができる。スタブおよびスケルトンファイル１１１は、ウェブサービス１５０を動かすためにランタイムで使用される。
【００３６】
ＷＳＤＬツール１１０により作成されたファイル１１１のうちの１つがスケルトンであり、スケルトンのパブリック関数は、クライアントプラットフォーム２００によって行われた呼び出しへの返答を提供するコードで書き込まれなければならない。このスケルトン１１１の関数の多くが、適合したシステム３００からのデータを入手、または設定する。他のいくつかは、トランザクション制御に従事する。
【００３７】
ＷＳＡアダプレットより戻されたオブジェクト／リレーションシップ１２１は、物理レベルおよび論理レベルの両方において、プラットフォーム２００内で構造オブジェクト／リレーションシップに合致しなければならない。ターゲットシステム３００からの応答データが、統合されたマッピングエンジンによって、プラットフォーム２００のビジネスオブジェクト／リレーションシップ１２１にマップされる。その目的のために、ＷＳＡアダプレットは、適合したシステム３００が公開するように要求する、「Ｔｙｐｅｓ」「Ａｔｔｒｉｂｕｔｅｓ」「Ｒｅｌａｔｉｏｎｓｈｉｐｓ」などを記述するスキーマファイル１３５を（統合されたマッピングエンジンを介して）使用する。
【００３８】
外部システム３００からビジネスオブジェクト／データ１２１を抽出するためには、ＷＳＡアダプレットを構成する必要があり、各ターゲットシステム３００は、アダプレットＡＰＩによって公開されたインターフェースに準拠する特定のそれぞれのウェブサービス１５０を実装（すなわち、ＷＳＤＬ１３０で定義され、スケルトンファイル１１１でコード化されたオペレーション／メソッドを実装）しなければならない。実際には、これは、コラボレーションプラットフォーム２００を外的な／外部システム３００に橋渡しするために、統合が、事実上、中間層（ターゲットシステム３００固有のＷＳＡアダプレット）が作成されるのを必要とすることを意味する。これは、統合をより複雑でコストのかかるものにする。
【００３９】
さらに、ＷＳＡ（ウェブサービスアダプレット）は、外的なシステム３００の既存のウェブサービス１５０を活かして、外部データを連合することができない。というのは、これらのウェブサービス１５０は、ＷＳＡアダプレットによって定義されたインターフェースに準拠していないからである。
【００４０】
最後に、これらのウェブサービスアダプレットの限界として、ウェブサービスアダプレットは、データを抽出している間に連合データの関係または誘導可能性を考慮しない。
【００４１】
本発明は、アダプレットインフラストラクチャを強化して、これに改良を加える。本発明により取られるアプローチは、上述されたものとは根本的に異なり、クエリ構文を定義しながら、連合データの関係およびその誘導可能性を見るものである。本発明は、以下にさらに説明するように、ウェブサービス呼び出しの連鎖を使用して、そこからオブジェクト１２１が生成される複合「ドキュメントオブジェクトモデル」を形成する。
【００４２】
したがって、本発明は、先行ＷＳＡ（ウェブサービスアダプレット）の使用をより容易にする。出願人は、本発明が、ＷＳＡ技術の採用を大いに増加させると考える。また、本発明の実施形態により、コラボレーションプラットフォーム２００は、非構造化データ（患者記録、その他）などの、従来とは異なるデータの中央レポジトリとなることができる。
【００４３】
コラボレーションプラットフォーム２００に対する本発明のいくつかの効果は以下である。
（１）企業間、さらにビジネスパートナー間で、データを交換し、プロセスを自動化する機能を提供する。
（２）ユーザが複数のシステムからの情報によって作業できるようにすることにより、グローバルなビジネスコラボレーションを奨励する。この情報の全体論的観点が、よりよい意思決定支援システム、低コストへの移行、およびより早い製品開発サイクルを可能にすることになる。
（３）他のデータベースからのデータの段階的な結合および移動を提供する。
（４）異なるシステムに常駐する製品情報を、それがあたかもプラットフォームデータベース／ストレージ層２２０に記憶されているかのように表示することを可能にする。
（５）複数のデータソースをリンクする際の、開発の手間および複雑なコーディングを軽減する。
【００４４】
先行ウェブサービスアダプレットと比較して、本発明の主要な効果は、外的なシステムまたはターゲットシステム３００での既存のソフトウエア資産（既存のウェブサービス１５０）の再利用である。本発明はまた、外部システム３００からデータを連合するための、いかなる追加の「コーディング」も必要としない。
【００４５】
図１Ｃ〜図４に戻って、次に、本発明の実施形態について詳細に説明する。本発明のアダプレット１２０アーキテクチャおよび実装によって、ターゲットシステム３００上の既存のウェブサービス１５０の利用が可能になる。この強化に加えて、本発明は、単一のルートから任意のドキュメント／サービス（応答）の任意のノードを識別することができる「一意の」クエリ／マッピング構文２５を定義する。
【００４６】
図２に示すように、ターゲットシステム３００は、「ｇｅｔＳｔａｎｄａｒｄＩｎｆｏ」および「ｇｅｔＭａｔｅｒｉａｌＩｎｆｏ」について、別々のウェブサービス１５０ａ、ｂを公開する。「ｇｅｔＳｔａｎｄａｒｄＩｎｆｏ」サービス呼び出し１５０ａからの応答は、「ｇｅｔＭａｔｅｒｉａｌＩｎｆｏ」ウェブサービス１５０ｂに必要な入力（「ｍａｔｅｒｉａｌｉｄ」）を含む。本発明のアダプレット１２０は、呼び出しを論理的に順番に追加する、または連鎖させることによって、これら２つのサービス呼び出し１５０ａ、１５０ｂの結合したビュー３２を形成する。結合したビュー３２は、単一の論理ドキュメントのように見ることができる。
【００４７】
結合されたビュー３２から、マッピングエンジン３５が、プラットフォームスキーマ１３５へのマッピングを単純化する（図３）。マップされたビュー３４が結果物となる。これは、以下のように実現される。パス言語が、単一の「ルート」から任意のドキュメント（またはサービス１５０）の任意のノードを識別することができる。次に、マッピングエンジン３５が、図４に示すように、クエリ／マッピング構文２５を実装する。
【００４８】
マッピング２５は、各ノードがサービス１５０を呼び出すことができる簡単なパスを示す。パス定義はまた、「マクロ」構文を利用して、ＵＲＬに似た方法で引き数またはパラメータを渡す。マッピング２５は、ルートコンテキスト２１および導出されたコンテキスト２３のような、オブジェクトコンテキストに基づく事前定義されたマクロを使用する。例えば、ルートコンテキスト２１として、＄（名前）が、図４に示す例の中で用いられている。
【００４９】
マッピング２５はまた、ドキュメント／応答メッセージ内容に基づく動的なマクロを使用する。これは、図示された例の中で、導出されたコンテキスト２３：＄（ｍａｔｅｒｉａｌｉｄ）として示されている。
【００５０】
図１Ｃおよび図５を参照すると、例示的な、限定しない一実施形態における本発明のアダプレット１２０の実装およびオペレーションは、以下の通りである。アダプレット１２０は、ターゲットシステム３００の既存の（あらかじめ定義された／提供された）ウェブサービス１５０を介してターゲットシステムデータベースと対話するＪＡＶＡ（登録商標）コンポーネントとして実装される。図１Ｂにおいて上で説明したように、プラットフォーム２００は、ＪＡＶＡ（登録商標）をはじめ、他の（複数の）コンピューターキテクチャをサポートすることができる。したがって、アダプレット１２０の実装は、ＪＡＶＡ（登録商標）に限定されない。コラボレーションプラットフォーム２００は、ウェブサービス１５０のクライアントサイドを提供する。アダプレット１２０インターフェースが、ターゲットシステム３００によって公開されるウェブサービス１５０のために、ＷＳＤＬファイル１３０を取得する（図５のステップ５０１）。ＷＳＡアダプレットの場合において前に述べたように、クライアントプラットフォーム２００と、ターゲットシステム３００との間のハンドシェイクは、ＷＳＤＬファイル１３０によって定義され、ＷＳＤＬファイル１３０は、それぞれのウェブサービス１５０が理解するメッセージ、それらのメッセージに対する応答のフォーマット、サービスがサポートするプロトコルなどを記述する。
【００５１】
ユーザは、適切なＪＡＶＡ（登録商標）ツール１１０と一緒にＷＳＤＬファイル１３０を使用して、スタブおよびスケルトンファイル１１１を生成する。スタブおよびクライアントクラスは、スキーマファイル１３５（例えば、Ｓｃｈｅｍａ．ｘｍｌ）に記述されているように複雑なビジネスオブジェクトを組み立てるために、プロバイダクラス１４０によってランタイムに使用される。ユーザは、先行ＷＳＡアダプレットでのように、ターゲットシステム３００によって実装されるべきメソッドを用いてスケルトンファイル１１１に書き込みをする必要はない。
【００５２】
次に、アダプレットインターフェースがパラメータファイル１３３を記述し（図５、ステップ５０３）、これが構成設定を行うためのメカニズムとなる。ステップ５０３はまた、プロバイダクラス１４０、およびターゲットシステム３００により公開されるウェブサービス１５０ａ、ｂ、・・・ｎへのエンドポイントを定義する。アダプレット１２０インターフェースは、ＸＭＬファイルを、アダプレットヴォールト１２５の記述と一緒にデータベース１２３に記憶する。このＸＭＬファイルが構文解析され、一部は「Ａｄｄ Ｖａｕｌｔ」コマンド（後述）への入力として使用され、一部はスキーママップとしてアダプレットプロバイダのｉｎｉｔ（ ）エントリポイントの中に渡される。
【００５３】
ステップ５０５で、スキーマファイル１３５を記述する。内容、すなわちスキーママップは、クライアントプラットフォーム２００を介して、プロバイダのｉｎｉｔ（ ）呼び出しに応答して戻される。一実施形態では、スキーママッピングファイル１３５は、ＸＭＬファイルである。アダプレット１２０によって戻されたオブジェクト／リレーションシップ１２１は、コラボレーションプラットフォーム２００内で構造オブジェクト／リレーションシップに合致しなければならない。マッピングは、アダプレット１２０実装の任務である。リレーショナルアダプレット１２０は、リレーショナルデータをビジネスオブジェクトに変換するマッピングエンジン３５を用いて、これを実現する。
【００５４】
ステップ５０７で、プロバイダクラス１４０は、インターフェース（例えば、一実施形態におけるｆｆプロバイダインターフェース）を実装する。これは、既存の対象ウェブサービス１５０インターフェースを使用して、クエリインターフェースを実装するために、プロバイダクラス１４０によって提供される。一実施形態では、図４のクエリ／マッピング構文２５が、プロバイダクラス１４０の中に構築される。しかしながら、他の実施形態では、クエリ／マッピング構文２５は、プロバイダクラス１４０の外側にあって、リレーションシップを誘導し、既存のウェブサービス１５０からの結果を結合してもよい。
【００５５】
プロバイダクラス１４０生成インターフェースは、先行ＷＳＡアダプレットのアプローチおよび以下のユーザの要件、（ｉ）ターゲットシステムによって実装されるメソッドを用いてスケルトンファイル１１１に書き込むこと、（ｉｉ）各ターゲットシステムにおいてウェブサービス／スケルトンクラスメソッドを実装すること、に取って替わることに留意されたい。
【００５６】
ステップ５０９で、アダプレット１２０インターフェースは、ＭＱＬコマンド：Ａｄｄ Ｖａｕｌｔ ［ｖａｕｌｔｎａｍｅ］ ｅｘｔｅｒｎａｌ ｆｉｌｅ ［ｆｉｌｅｎａｍｅ］を実行する。ここで、［ｆｉｌｅｎａｍｅ］が、ステップ５０３で記憶されたパラメータファイル１３３のＸＭＬファイルから読み出される。これにより、クライアントプラットフォーム２００／アダプレット１２０は、ターゲットシステム３００の、あらかじめ存在した／提供されたウェブサービス１５０呼び出しの１つまたは複数を利用することによって、複雑なビジネスオブジェクトについてターゲットシステムデータに対するクエリを行う。詳細には、図２においてあらかじめ説明したように、アダプレット１２０は、ウェブサービス呼び出しを連鎖させる。
【００５７】
次に、プロバイダクラス１４０は、スキーマファイル１３５のスキーママップに従って、対象の複雑なビジネスオブジェクト１２１を組み立てる（構築する）。詳細には、プロバイダクラス１４０は、呼び出された既存のウェブサービス１５０からの結果を結合し、マッピングエンジン３５は、（図３および図４において上で詳述したように）ウェブサービス呼び出し構文からプラットフォーム２００スキーマにマップする。
【００５８】
本発明のアダプレット１２０は、複数のウェブサービス１５０応答メッセージを連鎖させ、結合されたビュー３２およびマップされたビュー３４（ドキュメントオブジェクトモデル）を利用して、適切かつ「一意の」マッピング２５を定義するその能力においてユニークであり、それにより、外部システム３００からオブジェクト１２１を連合する。
【００５９】
可能性のある使用機会において、本発明のアダプレット１２０は、いかなる追加のコーディング／クラスメソッドのターゲットシステム実装なしに、既存のウェブサービス１５０の再利用を促進し、場合によっては、複数ドメインにわたり構文マッピング２５を連結することができる。本発明のアダプレット１２０は、ターゲットシステム３００がプラットフォーム２００定義のサービスを実装することを必要とする、既存のウェブサービスアダプレット実装に改良を加える。
【００６０】
本発明のアダプレット１２０の別の可能性のある適用は、ドキュメント／サービス１５０が内在する構造、従属関係を有し、誘導を必要とする場合の問題に対してである。一例は、ＲＴＦ（Ｒｉｃｈ Ｔｅｘｔ Ｆｏｒｍａｔ）／ｘｍｌフラグメントを、単一アセンブリに統合する要求管理（Ｒｅｑｕｉｒｅｍｅｎｔｓ Ｍａｎａｇｅｍｅｎｔ）においてである。別の例は、「元の場所に」残され、専用のウェブサービスを介して参照されるドキュメントである。８０％の企業知識は、リレーショナルデータベースではなく、ファイルサーバーの中に放置されている。適所にあるドキュメントにアクセスすることによって、ユーザは、人の仕事の方法を変更することなく、この情報を活かすことができる。
【００６１】
既存のアダプタおよび連合ツールキットが、ビジネスオブジェクトの２地点間統合を行う。それらは、関係／従属関係を有するオブジェクト／データについて、システム間のマッピングを定義する必要性には取り組まない。
【００６２】
図６は、本発明を実装することができるコンピューターネットワーク、または同様のデジタル処理環境を図示する。
【００６３】
クライアントコンピューター／デバイス５０（例えばアプリケーション実行クライアント２０４）、およびサーバーコンピューター６０（例えばウェブサーバー２３８、およびプラットフォーム２００のアプリケーションサーバー２３６）は、アプリケーションプログラムなどを実行する処理デバイス、ストレージデバイス、および入力／出力デバイスを提供する。クライアントコンピューター／デバイス５０はまた、通信ネットワーク７０を介して、他のクライアントデバイス／プロセッサー５０として実装されるターゲットシステム３００、およびサーバーコンピューター６０などの、他のコンピューティングデバイスにリンクされてよい。通信ネットワーク７０は、リモートアクセスネットワーク、グローバルネットワーク（例えばインターネット）、コンピューターのワールドワイドな集合形態、ローカルエリアネットワークまたはワイドエリアネットワーク、および一般にそれぞれのプロトコル（ＴＣＰ／ＩＰ、Ｂｌｕｅｔｏｏｔｈなど）を使用して互いに通信するゲートウェイの一部であってよい。他の電子デバイス／コンピューターネットワークアーキテクチャも適している。
【００６４】
図７は、図６のコンピューターシステムにおけるコンピューター（例えばクライアントプロセッサ／デバイス５０、またはサーバーコンピューター６０）の内部構造の図である。各コンピューター５０、６０は、システムバス７９を含み、ここでバスは、コンピューターまたは処理システムのコンポーネントの間でデータを転送するために使用される一組のハードウェアラインである。バス７９は、基本的に、コンピューターシステムの異なる要素（例えば、プロセッサ、ディスクストレージ、メモリ、入力／出力ポート、ネットワークポート、その他）を接続する共用の電線であり、バスによって要素間で情報の転送が可能になる。システムバス７９には、さまざまな入力および出力デバイス（例えば、キーボード、マウス、ディスプレイ、プリンタ、スピーカ、その他）を、コンピューター５０、６０に接続するためのＩ／Ｏデバイスインターフェース８２が取り付けられている。ネットワークインターフェース８６によって、コンピューターは、ネットワーク（例えば図６のネットワーク７０）に取り付けられた、さまざまな他のデバイスに接続することが可能になる。メモリ９０は、本発明の実施形態（例えば、アダプレット１２０、マッピングエンジン３５、ならびにクエリ／マッピング構文２５および詳細に上述された他のコードのサポート）を実装するのに使用されるコンピューターソフトウエア命令９２およびデータ９４に、揮発性ストレージを提供する。ディスクストレージ９５は、本発明の実施形態を実施するのに使用されるコンピューターソフトウエア命令９２およびデータ９４に、不揮発性ストレージを提供する。中央処理装置８４がまた、システムバス７９に取り付けられ、コンピューター命令の実行に備える。
【００６５】
一実施形態では、プロセッサルーチン９２およびデータ９４は、コンピュータープログラム製品（総称して参照９２）であり、これは、本発明のシステムのためのソフトウエア命令の少なくとも一部を提供するコンピューター可読媒体（例えば、１つまたは複数のＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ、ディスケット、テープ、その他などの着脱可能なストレージ媒体）を含む。コンピュータープログラム製品９２は、当技術分野でよく知られているように、任意の好適なソフトウエアインストール手続きによって、インストールすることができる。別の実施形態では、ソフトウエア命令の少なくとも一部をまた、ケーブル、通信接続および／またはワイヤレス接続を通してダウンロードすることができる。他の実施形態では、本発明のプログラムは、伝播媒体（例えば、電波、赤外線波、レーザー波、音波、またはインターネットなどのグローバルネットワークもしくは他のネットワーク上で伝播される電気波）上の伝播信号で具体化されるコンピュータープログラム伝播信号製品１０７である。そのようなキャリア媒体または信号は、本発明のルーチン／プログラム９２に、ソフトウエア命令の少なくとも一部を提供する。
【００６６】
代替実施形態では、伝播信号は、アナログキャリア波、または伝播媒体上で搬送されるデジタル信号である。例えば、伝播信号は、グローバルネットワーク（例えばインターネット）、電気通信ネットワーク、または他のネットワーク上で伝播されるデジタル化された信号であってよい。一実施形態では、伝播信号は、所定期間にわたって伝播媒体上に伝送される信号であり、例えば、ミリ秒、秒、分、またはより長い期間にわたってネットワーク上のパケットで送信されるソフトウェア・アプリケーション用の命令である。別の実施形態では、コンピュータープログラム製品９２のコンピューター可読媒体は、コンピュータープログラム伝播信号製品について上述したように、例えば伝播媒体を受信し、伝播媒体において具体化された伝播信号を識別することによって、コンピューターシステム５０が受信し、読み取ることができる伝播媒体である。
【００６７】
一般的に言えば、用語「キャリア媒体」すなわち遷移キャリアは、前述の遷移信号、伝播信号、伝播媒体、ストレージ媒体などを包含する。
【００６８】
本発明を、その例示的な実施形態を参照して詳細に示し、説明してきたが、当業者であれば、添付の特許請求の範囲によって包含される本発明の範囲から逸脱することなく、本発明において、形態および詳細にさまざまな変更を行うことができることを理解するであろう。
【特許請求の範囲】
【請求項１】
ターゲットシステムのネットワークサービスデータへのアクセスを提供するコンピューターシステムであって、
複数のグローバルコンピューターネットワークサービスを介してデータを公開するターゲットシステムと相互作用し、かつ、公開されたデータにクエリを行うアプリケーションインターフェースであって、
前記ターゲットシステムのためのアプリケーションの間でグローバルコンピューターネットワークサービスを再利用するように、前記ターゲットシステムのために、２つ以上のアプリケーションにわたって前記複数のグローバルコンピューターネットワークサービスのうちの１つを共通して使用する、アプリケーションインターフェースと、
前記公開されたデータのクエリであって、前記アプリケーションインターフェースによって実装されるクエリ（ａ）と、対象アプリケーションにおいて使用可能なオブジェクトの構文（ｂ）との間をマッピングし、前記対象アプリケーションを、前記クエリに応答して生成されたオブジェクトインスタンスのデータにアクセスできるようにするマッピングメンバーと
を含むことを特徴とするコンピューターシステム。
【請求項２】
前記クエリの実装において、前記アプリケーションインターフェースは、前記ターゲットシステムからデータの結合されたビューをもたらす方法で、前記ターゲットシステムの前記グローバルコンピューターネットワークサービスのうちの少なくとも２つへ呼び出しを連鎖させ、
前記アプリケーションインターフェースが、前記ターゲットシステムの既存の資産を再利用するように、前記少なくとも２つのグローバルコンピューターネットワークサービスは、前記ターゲットシステムによってあらかじめ提供されていることを特徴とする請求項１に記載のコンピューターシステム。
【請求項３】
前記マッピングメンバーは、前記結合されたビューから、前記対象アプリケーションのオブジェクトのクエリ構文をマップすることを特徴とする請求項２に記載のコンピューターシステム。
【請求項４】
コラボレーションプラットフォームによって用いられているコンピューターシステムであって、
前記ターゲットシステムは、前記コラボレーションプラットフォームの外部システムであり、分散オブジェクトクライアントとして構成されていることを特徴とする請求項１に記載のコンピューターシステム。
【請求項５】
前記対象アプリケーションは、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｐｐｉｎｇ ｌａｎｇｕａｇｅ）クライアント、ＲＭＩ（ｒｅｍｏｔｅ ｍｅｔｈｏｄ ｉｎｖｏｃａｔｉｏｎ）クライアント、ＥＪＢ（ｅｎｔｅｒｐｒｉｓｅ ＪＡＶＡ Ｂｅａｎ）クライアント、およびＪＮＩ（ＪＡＶＡ Ｎａｉｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）クライアントのうちのいずれかとして実装されることを特徴とする請求項１に記載のコンピューターシステム。
【請求項６】
ターゲットシステムのネットワークサービスデータにアクセスするコンピューター実施方法であって、
対象アプリケーションと、複数のグローバルコンピューターネットワークサービスを介してデータを公開するターゲットシステムとの間で相互作用するステップであり、公開されたデータのクエリを実装するように相互作用するステップであって、
前記ターゲットシステムのためのアプリケーションの間でグローバルコンピューターネットワークサービスが再利用されるように、前記ターゲットシステムのために、２つ以上のアプリケーションにわたる前記複数のグローバルコンピューターネットワークサービスのうちの１つを共通して使用する、相互作用するステップと、
前記公開されたデータの前記クエリ（ａ）と、前記対象アプリケーションにおいて使用可能なオブジェクトの構文（ｂ）との間をマッピングするステップであって、前記対象アプリケーションを、前記クエリに応答して生成されたオブジェクトインスタンスのデータにアクセスできるようにする、マッピングするステップと
を含むことを特徴とするコンピューター実施方法。
【請求項７】
前記クエリの実装において、前記相互作用するステップは、前記ターゲットシステムからデータの結合されたビューをもたらす方法で、前記ターゲットシステムの前記グローバルコンピューターネットワークサービスのうちの少なくとも２つへの呼び出しを連鎖させ、
前記相互作用するステップが、前記ターゲットシステムの既存の資産を再利用するように、前記少なくとも２つのグローバルコンピューターネットワークサービスは、前記ターゲットシステムによってあらかじめ提供されていることを特徴とする請求項６に記載のコンピューター方法。
【請求項８】
前記マッピングするステップは、前記結合されたビューから、前記対象アプリケーションのオブジェクトのクエリ構文をマッピングするステップを含むことを特徴とする請求項７に記載のコンピューター方法。
【請求項９】
コラボレーションプラットフォームによって利用される方法であって、
前記ターゲットシステムは、前記コラボレーションプラットフォームの外部システムであり、分散オブジェクトクライアントとして構成されていることを特徴とする請求項６に記載のコンピューター方法。
【請求項１０】
前記対象アプリケーションは、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｐｐｉｎｇ ｌａｎｇｕａｇｅ）クライアント、ＲＭＩ（ｒｅｍｏｔｅ ｍｅｔｈｏｄ ｉｎｖｏｃａｔｉｏｎ）クライアント、ＥＪＢ（ｅｎｔｅｒｐｒｉｓｅ ＪＡＶＡ Ｂｅａｎ）クライアント、およびＪＮＩ（ＪＡＶＡ Ｎａｉｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）クライアントのうちのいずれかとして実装されることを特徴とする請求項６に記載のコンピューター方法。
【請求項１１】
アプリケーションを介して少なくとも１つの外部システムによって提供される少なくとも２つのウェブサービスにアクセスし、クエリを行うためのコンピューターシステムであって、（ｉ）各ウェブサービスは、少なくとも別のウェブサービスと統一されていないデータを保持し、（ｉｉ）前記アプリケーションは、各ウェブサービスのためのそれぞれのインターフェースを含み、
クエリを行い、統一された方法において前記ウェブサービスからクエリ結果を受信するために、前記アプリケーションのインターフェースを適合する適合ユニットと、
ウェブサービスからの統一されていないクエリ結果を、統一されたデータに結合するためのマッピング手段と
を含むことを特徴とするコンピューターシステム。
【請求項１２】
前記適合ユニットは、前記アプリケーションのインターフェースを適合して、前記ウェブサービスのうちの２つ以上への呼び出しを連鎖させ、クエリ結果の結合したビューをもたらすことを特徴とする請求項１１に記載のコンピューターシステム。
【請求項１３】
前記マッピング手段は、クエリ構文を統一されたデータスキーマにマップすることを特徴とする請求項１２に記載のコンピューターシステム。
【請求項１４】
前記インターフェースを適合する前記適合ユニットは、事実上、前記少なくとも１つの外部システムの資産の再利用であることを特徴とする請求項１１に記載のコンピューターシステム。
【請求項１５】
前記少なくとも１つの外部システムは、分散オブジェクトクライアントとして構成されていることを特徴とする請求項１１に記載のコンピューターシステム。
【請求項１６】
コラボレーションプラットフォームであることを特徴とする請求項１１に記載のコンピューターシステム。
【請求項１】
ターゲットシステムのネットワークサービスデータへのアクセスを提供するコンピューターシステムであって、
複数のグローバルコンピューターネットワークサービスを介してデータを公開するターゲットシステムと相互作用し、かつ、公開されたデータにクエリを行うアプリケーションインターフェースであって、
前記ターゲットシステムのためのアプリケーションの間でグローバルコンピューターネットワークサービスを再利用するように、前記ターゲットシステムのために、２つ以上のアプリケーションにわたって前記複数のグローバルコンピューターネットワークサービスのうちの１つを共通して使用する、アプリケーションインターフェースと、
前記公開されたデータのクエリであって、前記アプリケーションインターフェースによって実装されるクエリ（ａ）と、対象アプリケーションにおいて使用可能なオブジェクトの構文（ｂ）との間をマッピングし、前記対象アプリケーションを、前記クエリに応答して生成されたオブジェクトインスタンスのデータにアクセスできるようにするマッピングメンバーと
を含むことを特徴とするコンピューターシステム。
【請求項２】
前記クエリの実装において、前記アプリケーションインターフェースは、前記ターゲットシステムからデータの結合されたビューをもたらす方法で、前記ターゲットシステムの前記グローバルコンピューターネットワークサービスのうちの少なくとも２つへ呼び出しを連鎖させ、
前記アプリケーションインターフェースが、前記ターゲットシステムの既存の資産を再利用するように、前記少なくとも２つのグローバルコンピューターネットワークサービスは、前記ターゲットシステムによってあらかじめ提供されていることを特徴とする請求項１に記載のコンピューターシステム。
【請求項３】
前記マッピングメンバーは、前記結合されたビューから、前記対象アプリケーションのオブジェクトのクエリ構文をマップすることを特徴とする請求項２に記載のコンピューターシステム。
【請求項４】
コラボレーションプラットフォームによって用いられているコンピューターシステムであって、
前記ターゲットシステムは、前記コラボレーションプラットフォームの外部システムであり、分散オブジェクトクライアントとして構成されていることを特徴とする請求項１に記載のコンピューターシステム。
【請求項５】
前記対象アプリケーションは、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｐｐｉｎｇ ｌａｎｇｕａｇｅ）クライアント、ＲＭＩ（ｒｅｍｏｔｅ ｍｅｔｈｏｄ ｉｎｖｏｃａｔｉｏｎ）クライアント、ＥＪＢ（ｅｎｔｅｒｐｒｉｓｅ ＪＡＶＡ Ｂｅａｎ）クライアント、およびＪＮＩ（ＪＡＶＡ Ｎａｉｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）クライアントのうちのいずれかとして実装されることを特徴とする請求項１に記載のコンピューターシステム。
【請求項６】
ターゲットシステムのネットワークサービスデータにアクセスするコンピューター実施方法であって、
対象アプリケーションと、複数のグローバルコンピューターネットワークサービスを介してデータを公開するターゲットシステムとの間で相互作用するステップであり、公開されたデータのクエリを実装するように相互作用するステップであって、
前記ターゲットシステムのためのアプリケーションの間でグローバルコンピューターネットワークサービスが再利用されるように、前記ターゲットシステムのために、２つ以上のアプリケーションにわたる前記複数のグローバルコンピューターネットワークサービスのうちの１つを共通して使用する、相互作用するステップと、
前記公開されたデータの前記クエリ（ａ）と、前記対象アプリケーションにおいて使用可能なオブジェクトの構文（ｂ）との間をマッピングするステップであって、前記対象アプリケーションを、前記クエリに応答して生成されたオブジェクトインスタンスのデータにアクセスできるようにする、マッピングするステップと
を含むことを特徴とするコンピューター実施方法。
【請求項７】
前記クエリの実装において、前記相互作用するステップは、前記ターゲットシステムからデータの結合されたビューをもたらす方法で、前記ターゲットシステムの前記グローバルコンピューターネットワークサービスのうちの少なくとも２つへの呼び出しを連鎖させ、
前記相互作用するステップが、前記ターゲットシステムの既存の資産を再利用するように、前記少なくとも２つのグローバルコンピューターネットワークサービスは、前記ターゲットシステムによってあらかじめ提供されていることを特徴とする請求項６に記載のコンピューター方法。
【請求項８】
前記マッピングするステップは、前記結合されたビューから、前記対象アプリケーションのオブジェクトのクエリ構文をマッピングするステップを含むことを特徴とする請求項７に記載のコンピューター方法。
【請求項９】
コラボレーションプラットフォームによって利用される方法であって、
前記ターゲットシステムは、前記コラボレーションプラットフォームの外部システムであり、分散オブジェクトクライアントとして構成されていることを特徴とする請求項６に記載のコンピューター方法。
【請求項１０】
前記対象アプリケーションは、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｐｐｉｎｇ ｌａｎｇｕａｇｅ）クライアント、ＲＭＩ（ｒｅｍｏｔｅ ｍｅｔｈｏｄ ｉｎｖｏｃａｔｉｏｎ）クライアント、ＥＪＢ（ｅｎｔｅｒｐｒｉｓｅ ＪＡＶＡ Ｂｅａｎ）クライアント、およびＪＮＩ（ＪＡＶＡ Ｎａｉｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）クライアントのうちのいずれかとして実装されることを特徴とする請求項６に記載のコンピューター方法。
【請求項１１】
アプリケーションを介して少なくとも１つの外部システムによって提供される少なくとも２つのウェブサービスにアクセスし、クエリを行うためのコンピューターシステムであって、（ｉ）各ウェブサービスは、少なくとも別のウェブサービスと統一されていないデータを保持し、（ｉｉ）前記アプリケーションは、各ウェブサービスのためのそれぞれのインターフェースを含み、
クエリを行い、統一された方法において前記ウェブサービスからクエリ結果を受信するために、前記アプリケーションのインターフェースを適合する適合ユニットと、
ウェブサービスからの統一されていないクエリ結果を、統一されたデータに結合するためのマッピング手段と
を含むことを特徴とするコンピューターシステム。
【請求項１２】
前記適合ユニットは、前記アプリケーションのインターフェースを適合して、前記ウェブサービスのうちの２つ以上への呼び出しを連鎖させ、クエリ結果の結合したビューをもたらすことを特徴とする請求項１１に記載のコンピューターシステム。
【請求項１３】
前記マッピング手段は、クエリ構文を統一されたデータスキーマにマップすることを特徴とする請求項１２に記載のコンピューターシステム。
【請求項１４】
前記インターフェースを適合する前記適合ユニットは、事実上、前記少なくとも１つの外部システムの資産の再利用であることを特徴とする請求項１１に記載のコンピューターシステム。
【請求項１５】
前記少なくとも１つの外部システムは、分散オブジェクトクライアントとして構成されていることを特徴とする請求項１１に記載のコンピューターシステム。
【請求項１６】
コラボレーションプラットフォームであることを特徴とする請求項１１に記載のコンピューターシステム。
【図１Ａ】
【図１Ｂ】
【図１Ｃ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図１Ｂ】
【図１Ｃ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１１−１５９２７５（Ｐ２０１１−１５９２７５Ａ）
【公開日】平成２３年８月１８日（２０１１．８．１８）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１０−２３５９５７（Ｐ２０１０−２３５９５７）
【出願日】平成２２年１０月２０日（２０１０．１０．２０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（５１０２７９２３９）ダッソー システムズ エノビア コーポレーション (2)
【Ｆターム（参考）】
【公開日】平成２３年８月１８日（２０１１．８．１８）
【国際特許分類】
【出願番号】特願２０１０−２３５９５７（Ｐ２０１０−２３５９５７）
【出願日】平成２２年１０月２０日（２０１０．１０．２０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（５１０２７９２３９）ダッソー システムズ エノビア コーポレーション (2)
【Ｆターム（参考）】
[ Back to top ]