(57)【要約】クライアントは広範なカスタマイズなしで様々なデータソースにアクセスすることができる。サービス統合モジュールは複数のサービスレコードを備え、各サービスレコードは各別のデータソースと関連付けられる。サービス統合モジュールは、データソースドライバ、信用情報及び接続情報を含むデータソース統合を管理するように構成される。クライアントからのサービス要求に応答して、前記サービス統合モジュールは、サービスレコードを識別し、データソースクエリを生成し、クエリの結果にアクセスし、その結果をクライアントに送信する。サービス統合モジュールは、データソースから返される生データを標準フォーマットにマッピングすることができる。サービス統合モジュールは、前記結果をクライアントにより指定されたフォーマット又はデータ符号化に再フォーマット化することもできる。【選択図】図２
2015505387.tif 000002
【特許請求の範囲】
【請求項１】
動的サービス統合方法であって、
クライアントからサービス識別子及び１つ以上の要求パラメータを含むサービス要求をコンピュータ装置で受信するステップ、
前記サービス識別子を用いて、パラメータ化されたクエリを含み且つ複数のデータソースレコードのうちの１つを参照する複数のサービスレコードのうちの１つを識別するステップであって、前記複数のサービスレコード及び前記複数のデータソースレコードは非一時的コンピュータ読取り可能な記録媒体に格納されている、ステップ、
前記要求パラメータのうちの１つ以上を前記パラメータ化されたクエリに挿入してデータソースクエリを生成するステップ、及び
前記データソースクエリの結果を前記クライアントに前記コンピュータ装置のネットワークインタフェースで送信するステップ、
を備える方法。
【請求項２】
データソースの生データを標準フォーマットにマッピングするために前記サービスレコードの結果マッピングを適用するステップを更に備える、請求項１記載の方法。
【請求項３】
データソースの生データをＸＭＬ（eXtensible Markup Language）フォーマット、ＪＳＯＮ（Javascript Object Notation）フォーマット、ＹＡＭＬフォーマット、ＲＤＦ（Resource Description Format）フォーマット、Ｔｕｒｔｌｅ（Terse RDF Triple Language）フォーマット、及びデリミテッドテキストフォーマットのうちの１つにマッピングために、前記サービスレコードの結果マッピングを適用するステップを更に備える、請求項１記載の方法。
【請求項４】
前記結果を前記サービス要求で指定されたフォーマットにフォーマット化するステップを更に備える、請求項１記載の方法。
【請求項５】
前記データソースクエリを用いて、前記コンピュータ装置の結果キャッシュ内の前記結果にアクセスするステップを更に備える、請求項１記載の方法。
【請求項６】
前記結果をシリアル化するステップ、及び
前記シリアル化した結果を前記データソースクエリに関連付けて前記コンピュータ装置の結果キャッシュ内にキャッシュするステップ、
を更に備える、請求項１記載の方法。
【請求項７】
前記識別されたサービスレコードにより参照される前記データソースレコードのドライバ、信用情報及び接続情報を用いて、前記データソースクエリをデータソースに発行するステップを更に備える、請求項１記載の方法。
【請求項８】
前記サービス識別子は前記サービス要求のＵＲＩ（Uniform Resource Identifier）を含む、請求項１記載の方法。
【請求項９】
前記サービス識別子は前記サービス識別子のパラメータを含む、請求項１記載の方法。
【請求項１０】
前記サービス要求を前記サービス要求に含まれる信用情報を用いて認証するステップを更に備える、請求項１記載の方法。
【請求項１１】
前記コンピュータ読取り可能な記録媒体上の新しいデータソースレコードを参照する新しいサービスレコードを前記コンピュータ読取り可能な記録媒体に追加するステップ、
前記新しいサービスレコードを識別するサービス要求を受信し、前記新しいサービスレコードの追加時にデータソースクエリの結果を前記新しいデータソースレコードのデータソースに送信するステップ、
を更に備える、請求項１記載の方法。
【請求項１２】
前記結果のグラフィック表示を表示装置に提示するステップを更に備える、請求項１記載の方法。
【請求項１３】
前記結果の構造に基づいてグラフィック表示形式を選択するステップ、及び
前記結果のグラフィック表示を、前記選択したグラフィック表示形式で表示装置に提示するステップ、
を更に備える、請求項１記載の方法。
【請求項１４】
コンピュータ装置に動的サービス統合方法を実行させるように構成された命令を含む非一時的コンピュータ読取り可能な記録媒体であって、前記方法は、
クライアントからサービス識別子及び１つ以上の要求パラメータを含むサービス要求を受信するステップ、
前記サービス識別子を用いて、パラメータ化されたクエリを含み且つ複数のデータソースレコードのうちの１つを参照する複数のサービスレコードのうちの１つを識別するステップ、
前記要求パラメータのうちの１つ以上を前記パラメータ化されたクエリに挿入してデータソースクエリを生成するステップ、
結果キャッシュ及びデータソースのうちの１つから前記データソースクエリの結果にアクセスするステップ、及び
前記データソースクエリの結果を前記クライアントにネットワークを介して送信するステップを備える、
コンピュータ読取り可能な記録媒体。
【請求項１５】
前記方法は標準フォーマットに前記結果をマッピングするステップを更に備える、請求項１４記載のコンピュータ読取り可能な記録媒体。
【請求項１６】
前記方法は、前記結果を要求されたフォーマットに再フォーマット化するステップを更に備える、請求項１４記載のコンピュータ読取り可能な記録媒体。
【請求項１７】
前記方法は、
前記結果をシリアル化するステップ、及び
前記シリアル化した結果を前記データソースクエリに関連付けて結果キャッシュ内にキャッシュするステップ、
を更に備える、請求項１４記載のコンピュータ読取り可能な記録媒体。
【請求項１８】
前記データソースレコードのドライバ、信用情報及び接続情報を用いて、前記データソースクエリをネットワークアクセス可能なデータソースに発行するステップを更に備える、請求項１４記載のコンピュータ読取り可能な記録媒体。
【請求項１９】
前記サービス識別子は前記サービス要求のＵＲＩ（Uniform Resource Identifier）及び前記サービス要求の要求パラメータを含む、請求項１４記載のコンピュータ読取り可能な記録媒体。
【請求項２０】
前記データソースクエリの生成ステップは、前記要求パラメータのうちの１つ以上を再フォーマット化することを含む、請求項１４記載のコンピュータ読取り可能な記録媒体。
【請求項２１】
前記方法は、
前記結果の構造に基づいてグラフィック表示形式を選択するステップ、及び
前記結果のグラフィック表示を前記選択したグラフィック表示形式で表示装置に提示するステップ、
を更に備える、請求項１４記載のコンピュータ読取り可能な記録媒体。
【請求項２２】
動的サービス統合装置であって、
プロセッサ、ネットワークインタフェース、メモリ及び非一時的コンピュータ読取り可能な記録媒体を備えるコンピュータ装置、及び
前記コンピュータ装置上で動作するサービス統合モジュールを備え、
前記サービス統合モジュールは、クライアントからサービス識別子及び１つ以上の要求パラメータを含むサービス要求を前記ネットワークインタフェースで受信し、前記サービス識別子を用いて、複数のサービスレコードのうちの１つを識別し、前記識別したサービスレコードのパラメータ化されたクエリ及び前記要求パラメータのうちの１つ以上からデータソースクエリを生成し、前記データソースクエリの結果を前記クライアントに前記ネットワークインタフェースで送信するように構成されている、装置。
【請求項２３】
それぞれのデータソースクエリの複数の結果を含む結果キャッシュを更に備え、前記サービス統合モジュールは前記結果キャッシュ及びネットワークアクセス可能なデータソースのうちの１つから前記データソースクエリの前記結果にアクセスするように構成されている、請求項２２記載の装置。
【請求項２４】
前記サービス統合モジュールは、前記サービスレコードの結果マッピングを用いて、データソースの生データを前記データソースクエリの前記結果の標準フォーマットにマッピングするように構成されている、請求項２２記載の装置。
【請求項２５】
前記サービス統合モジュールは、前記識別されたサービスレコードのドライバ、信用情報及び接続情報を用いて、ネットワークアクセス可能なデータソースから前記データソースクエリの前記結果にアクセスするように構成されている、請求項２２記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスの生成及び提供に関し、より詳しくはデータソース及びクライアントの動的統合に関する。
【背景技術】
【０００２】
現在の情報技術システムは様々なタイプのデータソースへのアクセスにますます依存している。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
しかしながら、クライアントを様々なデータソースに適応させることは時間を要し、間違いを起こしやすいタスクである。一部のデータソース及び／又はサービスはサービス記述を公開しているが、これらのサービスを利用したいクライアントは依然としてサービス記述に従ってカスタマイズされなければならない。更に、このカスタマイズオーバヘッドは、多数の異なるクライアントを異なるデータソースにアクセスするように適応化させる場合に増大する。
【０００４】
本明細書に開示されるシステム及び方法は、クライアントを様々なタイプのデータソースと統合するのに要するカスタマイズオーバヘッドを最小化又は削減するために使用することができる。ユーザは、クライアントを様々なタイプのデータソースと統合するために、本明細書に開示される動的サービス統合システム及び方法を、データソースで使用されている基本的な技術及び／又はデータフォーマット及び／又は通信機構に関する最小限の知識で利用することができる。新しいデータソース及びサービスは、それらを登録すると直ちに利用可能になるため、コンパイル（編集）及びデプロイメント（展開）の遅れを生じない。
【課題を解決するための手段】
【０００５】
いくつかの実施形態では、サービス統合モジュールは１つ以上のデータソースへのアクセスを簡単にすることができる。サービス統合モジュールは１つ以上のデータソースをそれぞれのデータソースレコードに登録することができる。各データソースレコードは特定のデータソースに関連する情報を含むことができる。データソースレコードは、データソースのドライバ、データソース信用情報、データソース接続情報等を含むことができるが、それらに限定されない。本明細書において、データソースのドライバは、特定のタイプのデータソースと相互作用するように構成されたコンポーネント又はライブラリ（例えば、コンピュータ読取り可能な命令）を指す。ドライバは、ＪＤＢＣ(Java Database Connectivity)ドライバ、ＯＤＢＣ(Object Database Connectivity)ドライバ、ＳＱＬ(Structured Query Language)データベースドライバ、セマンティックデータソースコネクティビティドライバなどを含むことができるが、それらに限定されない。データソースレコードは、ドライバ自体とは対照的に、データソースドライバへのリファレンス又はリンクを含むことができる。データソース信用情報はデータソースの認証に使用することができる。データソース信用情報は、ユーザ名、パスワード、ＰＩＮ、証明書、鍵等を含むことができる。データソース接続情報は、特定のデータソースへの接続（対応するドライバを用いる）を開始するために使用される接続文字列（ストリング）又は他の情報を含むことができる。接続文字列は、データソースのアドレス（例えば、データソースのＵＲＬ）を含み、データソース名（例えば、テーブル又はデータベース名）を識別し、データソースドライバを特定する。
【０００６】
サービス統合モジュールは、１つ以上のサービスのためにデータソースへのアクセスを提供することができる。サービス統合モジュールは１つ以上のサービスをそれぞれのサービスレコードを用いて登録することができる。サービスレコードは、識別子、データソース（例えば、データソースへのリファレンス）、パラメータ化されたクエリ、結果マッピング等を含むが、それらに限定されない。サービスは１つ以上のデータソースを参照し得る。データソースは複数の異なるサービスで使用され得る（例えば、参照され得る）。
【０００７】
サービスのパラメータ化されたクエリはクエリ文字列（又は他のクエリフォーマット）を含むことができ、これは１つ以上のパラメータプレースホルダを含むことができる。プレースホルダはデータソースクエリを形成するためにサービス要求のパラメータと置き換えることができる。本明細書で使用される「サービス要求」は、サービス及び／又はデータソースを対象にする要求を指す。サービス要求は、１つ以上の要求パラメータ、サービス識別子又は名前、認証信用情報等を含むことができる。１つ以上の要求パラメータはデータソースクエリを生成するためにパラメータ化されたクエリに挿入することができる。本明細書において、「データソースクエリ」は、特定のデータソースとともに使用するよう構成されたクエリを指す。例えば、ＳＱＬ(Structured Query Language)データベース内の特定の人を検索するためのパラメータ化されたクエリは、”select*from TABLE where FIRST_NAME=%search_parameter%”を含むことができる。”%search_parameter%”の値はサービス要求からのパラメータと交換することができる。いくつかの実施形態では、データソースクエリの生成は、更に、１つ以上の要求パラメータを特定のデータソースに適したフォーマットに再フォーマットすることを含むことができる。例えば、要求パラメータはＵＴＦ−８エンコーディングからＡＳＣIIエンコーディング等に変換することができる。
【０００８】
サービスレコードの結果マッピングは、データソースからの生結果データと標準データフォーマットとの間のマッピングを含むことができる。標準フォーマットは、ＸＭＬ（eXtensible Markup Language）、ＪＳＯＮ（Javascript Object Notation）、ＹＡＭＬ、Ｔｕｒｔｌｅ（Terse RDF Triple Language）などのＲＤＦ（Resource Description Format）、デリミテッドテキスト、又はそれらのフォーマットの組合せなどを含むことができるが、それらに限定されない。いくつかの実施形態では、結果は代替フォーマット又は代替エンコーディングに変換することができる。変換はサービス要求内で指定することができる。例えば、結果はバイナリフォーマット、特定のテキストエンコーディング（例えば、ＡＳＣII、ＵＴＦ−８等）などに変換することができる。例えば、サービス要求は、ＸＭＬ標準フォーマットの結果はＵＴＦ−８キャラクタエンコーディングを用いて符号化することを指定することができる。
【図面の簡単な説明】
【０００９】
【図１】模範的なサービスレコードのデータ構造及び模範的なデータソースレコードのデータ構造を示す図である。
【図２】動的サービス統合を提供するシステムの一実施形態のブロック図である。
【図３】動的サービス統合方法の一実施形態のフローチャートである。
【図４】動的サービス統合方法の別の実施形態のフローチャートである。
【図５】動的サービス統合方法の別の実施形態のフローチャートである。
【図６】動的サービス統合方法の別の実施形態のフローチャートである。
【発明を実施するための形態】
【００１０】
図１は模範的なサービスレコードのデータ構造及び模範的なデータソースレコードのデータ構造を示す。模範的なサービスレコードのデータ構造１５０は、識別子１５２、データソースリファレンス１５４、パラメータ化されたクエリ１５６及び結果マッピング１５８を含む。データソースリファレンス１５４はデータソースレコード１６０を参照し、データソースレコード１６０は、データソース識別子１６２、ドライバ１６４、データソース信用情報１６６及び接続情報１６８（例えば接続文字列）を含む。代わりに又は加えて、データソースレコード１６０はサービスレコードのデータ構造１５０の１つ以上のフィールド内に組み込むことができる。
【００１１】
データ構造１５０及び１６０は、ハードディスク、不揮発性メモリ等の非一時的コンピュータ読取り可能記録媒体上で具体化することができる。図１は模範的なデータ構造１５０及び１６０を示すが、本発明はこれに限定されず、任意の適切なデータ構造を任意の適切なフォーマットで使用するように適応させることができる。
【００１２】
クライアントは、任意の適切な要求機構を用いてサービス統合モジュールのサービスにアクセスすることができる。いくつかの実施形態では、クライアントは、ＨＴＴＰ（Hyper Text Transfer Protocol）ＧＥＴ要求を用いてサービス統合モジュールのサービスにアクセスすることができる。ＧＥＴ要求は要求サービスを識別する及び／又は１つ以上の要求パラメータを含むことができる。サービス要求に応答して、サービス統合モジュールはサービスレコードを識別し、データソースクエリを生成し、（データソース又は結果キャッシュ内の）データソースクエリの結果にアクセスし、その結果をクライアントに送信することができる。サービス統合モジュールは結果を標準フォーマットにマッピングすること及び／又は結果を上述したように変換することができる。
【００１３】
いくつかの実施形態では、サービス統合モジュールはデータソース要求の結果をキャッシュするように構成される。サービス統合モジュールは結果を記録媒体への記録に適したフォーマットにシリアル化し、シリアル化した結果をデータソースクエリ及び／又は１つ以上の要求パラメータに関連付けてキャッシュ内に格納することができる。同じ結果に対する後続のサービス要求（同じ要求パラメータを有し及び／又は同等のデータソースクエリを生じる）は結果キャッシュから戻すことができる。いくつかの実施形態では、キャッシュされた結果は所定の期間に亘って及び／又はキャッシュポリシ（例えば、最長時間未使用（ＬＲＵ）ポリシ又は他の適切なキャッシュポリシ）に従って格納される。いくつかの実施形態では、サービス統合モジュール２１０はデータソースへの書込み及び／又は変更などの他の記録操作に応答してキャッシュから無効（例えば、ダーティ（不正））エントリを除去することができる。
【００１４】
いくつかの実施形態では、サービス要求はアグリゲート要求を含むことができ、この要求は１つ以上のデータソースから複数のデータのセットを要求するものである。アグリゲート要求は複数のクエリを１つのデータソースに発行し、各クエリが１つ以上の結果を生じるものとし得る。アグリゲート要求は複数の区切られた要求パラメータ（例えばＧＥＴ要求パラメータ）とすることができ、各パラメータはサービスのパラメータ化されたクエリに適用してそれぞれ異なるデータソースクエリ及び対応する結果を生成することができる。結果の各々は上述したように標準フォーマットにマッピングする及び／又は変換することができる。いくつかの実施形態では、アグリゲート結果は上述したようにシリアル化し、キャッシュすることができる。結果はアグリゲートクエリに及び／又は個別のデータソースクエリとしてキャッシュすることができる。
【００１５】
いくつかの実施形態は結果のグラフィック（図表）表示を提示のために表示装置上に自動的に生成するように構成された提示モジュールを備えることができる。グラフィック表示は、チャート、グラフ、複数のグラフィック表示の組み合わせ等を含むことができるが、それらに限定されない。かわりに又は加えて、提示モジュールは、表形式、円柱形式、集計表形式等の特定の形式で結果のテキスト（文字）表示を生成することができる。
【００１６】
図２は動的サービス統合用システム２００の一実施形態のブロック図である。システム２００はコンピュータ装置２２０上で動作するサービス統合モジュール２１０を備えることができる。コンピュータ装置２２０は、プロセッサ２２２、メモリ、非一時的記録媒体２２４（例えば、ハードディスク、固体記録装置等）、通信インタフェース２２６等を備えることができる。いくつかの実施形態では、サービス統合モジュール２１０は、非一時的記録媒体２２４に格納され、プロセッサ２２２で実行されるように構成された命令として具体化される。図２は単一のプロセッサ２２２を有する単一のコンピュータ装置２２０上で動作するサービス統合モジュール２１０を示すが、本発明はこれに限定されない。いくつかの実施形態では、システム２００は、クラスタ化された環境及び／又は高可用性環境において複数のコンピュータ装置２２０（又は仮想コンピュータ装置）上で動作する複数のサービス統合モジュール２１０を備えることができる。
【００１７】
サービス統合モジュール２１０はネットワーク２４０を介して１つ以上のデータソース２３０に通信可能に結合され得る。各データソース２３０はそれぞれのサーバコンピュータ、クラスタ又は他の適切なコンピュータ装置上で動作し得る。ネットワーク２４０は任意の適切な通信ネットワークとすることができ、インターネットプロトコル（ＩＰ）ネットワーク、インターネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、無線ネットワーク、セルラー方式データネットワーク、公衆交換電話ネットワーク（ＰＳＴＮ）等を含み得るが、それらに限定されない。
【００１８】
図２は模範的なネットワークアクセス可能なデータソース２３０を示すが、本発明はこれに限定されない。いくつかの実施形態では、システム２００は、ネットワークアクセス可能なデータソース２３０に加えて（又は代わりに）１つ以上のローカルデータソースを備えることができる。ローカルデータソースは、サービス統合モジュール２１０及び／又はコンピュータ装置２２０に、１つ以上のバス又は他の通信リンク（例えば、ユニバーサルシリアルバス、ＩＥＥＥ１３９４、ＳＣＳＩ、ＰＣＩ（Peripheral Component Interconnect）等）を介して通信可能に結合することができる。
【００１９】
サービス統合モジュール２１０はデータストア２１２を備えることができ、このデータストアには１つ以上のサービスレコード２５０及び／又は１つ以上のデータソースレコード２６０が格納される。各データソースレコード２６０は、上述したように、識別子、ドライバ、信用情報及び接続情報を含むことができる。いくつかの実施形態では、データストア２１２は、上述したように、１つ以上のデータソースクエリの結果をキャッシュする結果キャッシュ２７０を備えることができる。
【００２０】
サービス統合モジュール２１０は、データソース識別子、ドライバ、信用情報、接続情報等を含むデータソース追加要求に応答して、新しいデータソースレコード２６０をデータストア２１２に追加するように構成することもできる。いくつかの実施形態では、サービス統合モジュール２１０は、対応するデータソースレコード２６０をデータストア２１２に追加する前に、新しいデータソースが提供される情報と接触できることを検証する。
【００２１】
いくつかの実施形態では、サービス統合モジュール２１０はサービス登録インタフェース２１４（例えば、ウェブインタフェース）を備え、ユーザはこのインタフェースを介してデータソースレコード２６０及び／又はサービスレコード２５０を生成、編集もしくは管理することができる。サービス統合モジュール２１０は、サービス登録インタフェース２１４を介して新しいサービスレコード２５０及び／又はデータソースレコード２６０をデータストア２１２に追加するように構成することができる。サービスレコード２５０を追加する要求は、識別子、データソース、パラメータ化されたクエリ、結果マッピング等を含むことができる。いくつかの実施形態では、サービス統合モジュール２１０は、新しいサービスレコード２５０をデータストア２１２に追加する前にそのサービスを検証する。サービスの検証は、指定のデータソースがデータストア２１２に存在するかどうかの決定、データソースの検証、パラメータ化されたクエリの検証（例えば、クエリの構文（シンタックス）の検証、１つ以上の試験パラメータを有するデータソースに対するクエリの試験等）、及び／又は結果マッピングの検証（例えば、マッピングの構文の検証等）を含むことができる。サービスの検証は、更に、クライアントが新しいサービスレコードの追加を許可していることを確かめるために要求を認証することも含むことができる。
【００２２】
サービス登録インタフェース２１４は、データソース２３０の１つ以上の生データタイプと標準データフォーマットとの間の結果マッピングをユーザが指定することを可能にすることができる。マッピングは上述したように１つ以上のサービスレコード２５０に適用することができる。サービス登録インタフェース２１４は１つ以上のデータソース２３０への接続を試験し、試験クエリを１つ以上のサービスに通すこと等によって１つ以上のサービス及び／又はデータソースを試験するように構成することができる。いくつかの実施形態では、サービス登録インタフェース２１４は結果キャッシュ２７０に対するポリシを指定することもユーザに可能にすることができる。キャッシュポリシはエージアウト（削除）タイム、最大キャッシュ容量、ＬＲＵポリシ等を含み得る。
【００２３】
データソース及びサービスは登録時にサービス統合モジュール２１０に追加することができる。従って、新しいデータソース及び／又はサービスは、対応するデータソースレコード及び／又はサービスレコード２５０がデータストア２１２に生成されると同時に使用可能になり得る。
【００２４】
サービス統合モジュール２１０は、サービス統合モジュール２１０に登録された１つ以上のサービスを、ネットワーク１４０を介してクライアント２８０に提示するように構成されたサービスインタフェース２１６を備えることができる。本明細書で使用される「クライアント」は、クライアントコンピュータ装置を指し、例えばパーソナルコンピュータ装置、ラップトップ、ノートブック、タブレット、携帯情報端末（ＰＤＡ）、スマートフォン等を含み得るが、それらに限定されない。いくつかの実施形態では、サービス統合モジュール２１０は各サービスレコード２５０をそれぞれのＵＲＩ（Uniform Resource Identifier）と関連させることができる。クライアント２８０はＵＲＩを使って要求を特定のサービスに向けることができる。サービスレコード２５０のＵＲＩはサービスレコードの識別子から導出することができる。例えば、サービスインタフェース２１６のホストネームが”service.com”である場合、“Service_A”として識別されるサービスのＵＲＩは”service.com／services／Service_A”とし得る。いくつかの実施形態では、サービスは要求パラメータで識別することができる。例えば、サービスインタフェース２１６に向けられたＨＴＴＰ要求は、値”Service_A”を有する「サービス識別子」パラメータを含むことができる。サービスを登録及び／又は提示する模範的なメカニズムをここに記載したが、本発明はこれに限定されず、任意の適切な登録メカニズムを使用するように適応化させることができる。
【００２５】
いくつかの実施形態では、サービスインタフェース２１６は利用可能なサービス及び／又はデータソースのリスティング又はディレクトリを提供する。サービスインタフェース２１６は１つ以上の登録サービスのパラメータを列挙すること及び／又は模範的なサービス要求を提供することができる。サービスインタフェース２１６は、更に、サービスマッピング情報を提供する及び／又はサービスの結果を返し得る標準フォーマットを指定することができる。サービスインタフェース２１６は、上述したように１つ以上のサービスをサービス登録インタフェース２１４により編集及び／又は変更することをユーザに可能にすることができる。
【００２６】
サービスインタフェース２１６は、１つ以上のクライアント２８０からのサービス要求２１７を受信するように構成される。サービスインタフェース２１６はサービス要求２１７を、例えばＨＴＴＰ、ＳＯＡＰ（Simple Object Access Protocol）、ＲＰＣ（Remote Procedure Call）、ＲＭＩ（Remote Method Invocation）等の任意の適切なメカニズムを用いて受信することができるが、それらに限定されない。
【００２７】
サービス要求２１７の受信時に、サービス統合モジュール２１０は要求２１７を検証することができ、この検証は要求構文の検証、要求パラメータの検証等を含み得る。いくつかの実施形態では、サービス統合モジュール２１０へのアクセスは認証されたユーザに制限される。サービス統合モジュール２１０はユーザデータベース、ディレクトリ等（図示せず）を備えることができ、及び／又はそれらに通信可能に結合することができる。サービス要求２１７の検証は、サービス要求２１７内の信用情報、例えばユーザ名及びパスワード、ＰＩＮ、ディジタル署名等を検証することも含むことができる。
【００２８】
サービス要求２１７の検証時に、サービス統合モジュール２１０は、上述したように、対応するサービスレコード２５０を識別することができる。サービス統合モジュール２１０は、要求２１７が向けられたＵＲＩ、サービス要求２１７のパラメータ等に基づいてサービスレコード２５０を識別することができる。
【００２９】
サービス統合モジュール２１０は識別されたサービスレコード２５０のパラメータ化されたクエリ及び／又はサービス要求のパラメータを用いてデータソースクエリを生成することができる。データソースクエリの生成は、サービス要求２１７の１つ以上の要求パラメータをサービスレコード２５０のパラメータ化されたクエリに挿入することを含むことができる。いくつかの実施形態では、要求パラメータはデータソース２３０に対して適切なフォーマットにフォーマット化及び／又は符号化することができる。
【００３０】
サービス要求２１７は複数のデータのセットに対する要求を含むことができる。例えば、サービス要求２１７は複数の要求パラメータのセットを含むことができる。このような要求に応答して、サービス統合モジュール２１０は複数の異なるデータソースクエリを生成することができ、各データソースクエリはそれぞれの要求パラメータのセットを含む。要求パラメータは特定の文字で区切ること及び／又はサービス要求２１７のフォーマットで示すことができる。
【００３１】
サービス統合モジュール２１０は、データソースクエリを用いて結果を生成し及び／又はクライアントへ送信することができる。いくつかの実施形態では、サービス統合モジュール２１０は、結果が結果キャッシュ２７０にキャッシュされているかどうかを決定する。そうであれば、サービス統合モジュール２１０は、データソース２３０に問い合わせることなく、キャッシュされた結果をクライアントに送信することができる。
【００３２】
結果がキャッシュ２７０内に見つからない場合（又はキャッシュされた結果が無効である場合）には、サービス統合モジュール２１０はネットワーク２４０を介してデータソース２３０からの結果にアクセスすることができる。サービス統合モジュール２１０は、サービスレコード２５０により参照されるデータソースレコード２６０のドライバ、信用情報及び／又は接続情報を用いてデータソース２３０にアクセスすることができる。サービス統合モジュール２１０はクライアントクエリ２１７に結果を含む応答２１９を送信することができる。
【００３３】
いくつかの実施形態では、サービス統合モジュール２１０は、上述したように、サービスレコード２５０の結果マッピングを適用し、データソースから取得した結果を標準フォーマットにマッピングするように構成される。応答２１９は標準フォーマットの結果を含む。いくつかの実施形態では、サービス統合モジュール２１０は結果をサービス要求２１７に指定されたフォーマットにフォーマット化するよう構成することができる。上述したように、フォーマットは、バイナリフォーマット、テキストフォーマット、又はクライアント２８０の使用に適した他のフォーマットとすることができる。
【００３４】
サービス統合モジュール２１０は、結果を結果キャッシュ２７０にキャッシュするように構成することができる。結果のキャッシングは、結果を非一時的コンピュータ読取り可能記録媒体に記録するのに適したフォーマットに「シリアル化」し、シリアル化した結果を結果クエリと関連させることを含むことができる。シリアル化した結果は、最終アクセス時間、アクセス周波数メトリック、経過時間等のキャッシュ管理データと関連させることができる。
【００３５】
クライアント２８０は応答２１９を受信し、そこから結果を抽出することができる。いくつかの実施形態では、クライアント２８０は、結果２１９を表示装置、オーディオ出力装置などのクライアント２８０の１つ以上の人間−機械インタフェースコンポーネントに提示するように構成されたクライアント提示モジュール２８２を備える。クライアント提示モジュール２８２は、結果をグラフィック、テキスト等の任意の方式で提示するように構成することができる。いくつかの実施形態では、クライアント提示モジュール２８２は、サービス統合モジュール２１０から利用可能であり、及び／又はネットワーク２４０を介してアクセス可能である（例えば、クライアント提示モジュール２８２はサービス統合モジュール２１０により提供されるアプレットを備えることができる）。
【００３６】
クライアント提示モジュール２８２は、結果２１９に対して適切なグラフィック表示形式を選択することができる。グラフィック表示形式は、チャート、テキストベース形式（例えば、表形式、円柱形式、集計表形式等）、複数の形式の組合せ等を含み得るが、それらに限定されない。クライアント提示モジュール２８２は、結果２１９の「構造」、例えば結果２１９に表示される変数の数及び／又はタイプ、結果２１９の入力／出力変数の数、サービス要求２１７のパラメータ等に基づいてグラフィック表示形式を選択することができる。従って、クライアント提示モジュール２８２は結果２１９を分析して適切なグラフィック表示形式を選択することができる。この選択は１つ以上のユーザ決定選択基準又は好みに基づくものとすることができる。
【００３７】
代わりに又は加えて、サービス統合モジュール２１０は、クライアント２８０への提示のために結果２１９のグラフィック表示を自動的に生成するように構成されたサーバ側提示モジュール２１３を備えることができる。サーバ側提示モジュール２１３は、上述したように、結果２１９に対して適切なグラフィック表示形式を自動的に選択することができる。フォーマット化された結果を提示のためにクライアント２８０に供給することができる。
【００３８】
いくつかの実施形態では、クライアント２８０は、サービス統合モジュールから得られた結果をネットワーク２４０を介して１つ以上のクライアント２８４に提示するように構成されたサーバコンピュータ装置を備えることができる。例えば、クライアント２８０は、結果をアグリゲートし複数のクライアントコンピュータ装置２８４に公開するように構成されたウェブサーバを備えることができる。
【００３９】
図３は、動的サービス統合方法３００の一実施形態のフローチャートである。ステップ３１０において、方法３００は開始し、初期化される。方法３００は非一時的記録媒体上のコンピュータ読取り可能な命令として具体化することができる。従って、ステップ３１０は、１つ以上のコンピュータ読取り可能な命令をロードし及び／又はこの１つ以上の命令をコンピュータ装置で実行するステップを含むことができる。方法３００の１つ以上のステップは、通信インタフェース、コンピュータ読取り可能な記録媒体等の特定のマシンコンポーネントに関連し得る。従って、ステップ３１０はこれらのマシンコンポーネントへのアクセス及び／又はそれらの初期化も含み得る。
【００４０】
ステップ３２０において、方法３００はネットワーク通信インタフェースを介してサービス要求を受信することができる。サービス要求はサービス識別子及び／又は１つ以上の要求パラメータを含み得る。上述したように、サービス識別子はステップ３３０においてサービスレコード及び／又はデータソースレコードを識別するために使用される。ステップ３２０で識別されたサービスレコード及び／又はデータソースレコードはコンピュータ装置の非一時的コンピュータ読取り可能記録媒体に格納し得る。
【００４１】
ステップ３４０は、サービスレコードのパラメータ化されたクエリ及び／又はサービス要求の要求パラメータの１つ以上を用いてデータソースクエリを生成するステップを含むことができる。ステップ３４０は、１つ以上の要求パラメータをパラメータ化されたクエリに挿入するステップを含むこともできる。いくつかの実施形態では、ステップ３４０は、１つ以上の要求パラメータを特定のデータソースに適切なフォーマットにフォーマット化及び／又は符号化するステップを含むこともできる。代わりに又は加えて、結果はデータソースからアクセスすることもできる。データソースからのアクセスは、ステップ３３０で識別されたデータソースレコードのドライバ、信用情報及び／又は接続情報を用いてクエリをデータソースに発行するステップを含むこともできる。
【００４２】
ステップ３５０は、結果をクライアントにネットワークを介して送信するステップを含むことができる。いくつかの実施形態では、ステップ３５０は、サービスレコードの結果マッピングを適用して生結果データを標準フォーマットにマッピングするステップを含むこともできる。ステップ３５０は更に、上述したように、結果をクライアントに対して適切なフォーマットに変換するステップを含むこともできる。いくつかの実施形態では、ステップ３５０は更に、上述したように、結果を結果キャッシュに含めるステップを含むこともできる。
【００４３】
ステップ３６０において、方法３００は別のサービス要求が受信されるまで終了となる。
【００４４】
図４はサービス統合を動的に提供する方法４００の別の実施形態のフローチャートである。
【００４５】
ステップ４１０において、方法４００は開始し、初期化される。方法４００は、非一時的記録媒体上のコンピュータ読取り可能な命令として具体化することができる。従って、ステップ４１０は、１つ以上のコンピュータ読取り可能な命令をロードし及び／又はこの１つ以上の命令をコンピュータ装置で実行するステップを含み得る。方法４００の１つ以上のステップは、通信インタフェース、コンピュータ読取り可能な記録媒体等の特定のマシンコンポーネントに関連し得る。従って、ステップ４１０はこれらのマシンコンポーネントへのアクセス及び／又はそれらの初期化も含み得る。ステップ４２０は、上述のように、サービス要求を受信するステップを含む。
【００４６】
ステップ４２２において、サービス要求を検証することができる。サービス要求の検証は、要求の構文の検証、要求の信用情報の検証（例えば、要求が許可されたユーザからのものであるかの検証）等を含むことができる。ステップ４２２は更に、サービス要求が有効なサービスレコード及び／又はデータソースレコードを参照するかを検証するステップを含むこともできる。サービス要求が有効である場合、方法４００はステップ４３０に進み、さもなければ、方法４００はステップ４２４に進む。
【００４７】
ステップ４２４は、エラー応答をクライアントに返すステップを含むことができる。ステップ４２４は、エラーの性質を示し、後続のサービス要求においてこのエラーの対処方法に関する指示を提供するエラー応答を生成するステップを含むこともできる。
【００４８】
ステップ４３０において、方法４００は上述のようにサービス要求に対応するサービスレコードを識別する。ステップ４３２において、方法４００は、サービス要求の結果が結果キャッシュで入手可能かを決定することができる。ステップ４３２は、サービス要求の１つ以上の要求パラメータ（又はデータソースクエリ）で結果キャッシュに問い合わせ（クエリ）を行うことを含むことができる。ステップ４３２は更に、キャッシュ結果が有効であるか（例えば、期限切れでなく、「ダーティ（不正）」でないか）を決定するステップを含むこともできる。有効な結果がキャッシュで得られる場合には、方法４００はステップ４７０に進み、さもなければ、方法４００はステップ４４０に進む。
【００４９】
ステップ４４０は、サービス要求に対してデータソースクエリを生成するステップを含むことができる。ステップ４４０はステップ４３０で識別されたサービスレコードのパラメータ化されたクエリ内に１つ以上の要求パラメータを挿入するステップを含むこともできる。ステップ４３０は更に、要求パラメータの１つ以上をデータソースに適したフォーマットに再フォーマット及び／又は符号化するステップを含むこともできる。
【００５０】
ステップ４５０は、サービスレコード内で参照されるデータソースレコードのドライバ、信用情報及び／又は接続情報を用いて、データソースにクエリを発行するステップを含むことができる。ステップ４５０は更に、データソースからのクエリに対する応答を受信するステップを含むこともできる。ステップ４６０は、上述のように、データソースから返される生データに結果マッピングを適用するステップを含むことができる。いくつかの実施形態では、ステップ４６０は更に、結果を結果キャッシュにキャッシュするステップを含むこともできる。
【００５１】
いくつかの実施形態では、方法４００は更に、上述のように、ステップ４７０において、結果をサービス要求内で指定されているフォーマットに変換するステップを含む。結果はステップ４８０においてネットワークインタフェースを用いてクライアントコンピュータ装置に送信することができる。ステップ４９０において、方法４００は次の要求が受信されるまで終了となる。
【００５２】
図５は動的サービス統合方法の別の実施形態のフローチャートである。ステップ５１０において、方法５００は開始し、初期化される。方法５００は、非一時的記録媒体上のコンピュータ読取り可能な命令として具体化することができる。従って、ステップ５１０は、１つ以上のコンピュータ読取り可能な命令をロードし及び／又はこの１つ以上の命令をコンピュータ装置で実行するステップを含み得る。方法５００の１つ以上のステップは、通信インタフェース、コンピュータ読取り可能な記録媒体等の特定のマシンコンポーネントに関連し得る。従って、ステップ５１０はこれらのマシンコンポーネントへのアクセス及び／又はそれらの初期化も含み得る。
【００５３】
新しいサービスレコードを追加する要求はステップ５２０で受信される。この要求はネットワークを介してクライアントから受信され得る。ステップ５２０の要求は、サービス識別子、パラメータ化されたクエリ、結果マッピングを含み、データソースを参照し、及び／又はデータソース識別子、ドライバ、信用情報及び／又は接続情報を指定する。
【００５４】
ステップ５２２は要求を検証し、この検証は、要求の構文の検証、要求が許可されたクライアントからのものかどうかを確定する要求の信用情報の検証等を含み得る。要求が有効である場合、方法５００はステップ５３０に進む。いくつかの実施形態では、要求の検証は、更に、新しいサービスレコード（及び／又は新しいデータソースレコード）を非一時的コンピュータ読取り可能記録媒体に格納するステップを含む。新しいサービスは、ステップ５２２で有効とされると直ちに利用可能にし得る。従って、新しいサービスをコンパイル及び／又はデプロイメント遅延なしで利用可能にすることができる。
【００５５】
要求が有効でない場合には、方法５００はステップ５２４に進み、ここでエラー応答が返される。エラー応答は、エラーの性質を指示すること及び／又は後続のサービス要求においてこのエラーにどのように対処できるか指示することができる。
【００５６】
ステップ５４０は、上述のように、新しいサービス要求に向けられたサービス要求を受信するステップを含む。ステップ５５０は、上述のように、サービス要求に応答して結果を生成し、その結果をクライアントに送信するステップを含み得る。ステップ５４０及び５５０は、ステップ５２２で新しいサービスレコードが有効と検証されると直ちに生起する。
【００５７】
方法５００は、ステップ５５０において、別のサービス要求が追加されるまで及び／又は別のサービス要求が受信されるまで、終了とされる。
【００５８】
図６は動的サービス統合方法の別の実施形態のフローチャートである。ステップ６１０において、方法６００は開始し、初期化される。方法６００は、非一時的記録媒体上のコンピュータ読取り可能な命令として具体化することができる。従って、ステップ６１０は、１つ以上のコンピュータ読取り可能な命令をロードし及び／又はこの１つ以上の命令をコンピュータ装置で実行するステップを含み得る。方法６００の１つ以上のステップは、通信インタフェース、コンピュータ読取り可能な記録媒体等の特定のマシンコンポーネントに関連し得る。従って、ステップ６１０はこれらのマシンコンポーネントへのアクセス及び／又はそれらの初期化も含み得る。
【００５９】
ステップ６１０において、クライアントのコンピュータ装置がサービス要求をネットワークアクセス可能なサービス統合モジュールへ送信する。サービス要求はサービス識別子及び１つ以上の要求パラメータを含むことができる。サービス要求はデータソースから独立させ、データソースは要求の結果にアクセスするために問い合わせを受けるようにすることができる。従って、サービス要求は、ＨＴＴＰ、ＳＯＡ等の簡単なフォーマットで生成することができる。サービス要求は、データソースドライバ、データソース信用情報等を含まなくても、それらにリファレンスさせなくてもよい。いくつかの実施形態では、サービス要求は要求の結果に対するフォーマット及び／又は符号化を指定することができる（例えば、ＡＳＣIIテキスト、ＵＴＦ−８等）。
【００６０】
いくつかの実施形態では、ステップ６２０のサービス要求はコンピュータ装置上で動作するアプリケーションで発生される。代わりに又は加えて、サービス要求は１つ以上のクライアントコンポーネント装置にコンテンツを提供するように構成されたウェブサーバのコンポーネントにより発生され及び／又は送信されるようにし得る。
【００６１】
ステップ６３０において、クライアントコンピュータ装置は要求に対する応答を受信し、この応答は結果をＸＭＬ、ＪＳＯＮ、ＹＡＭＬ、ＲＤＦ、Ｔｕｒｔｌｅ等の標準フォーマットで含んでいる。これらの結果はサービス要求の指定に従ってフォーマット化及び／又は符号化され得る。ステップ６３０で受信される応答は上述のようにサービス統合モジュールにより生成することができる。
【００６２】
ステップ６４０において、クライアントコンピュータ装置は結果のグラフィック表示を自動的に生成する。グラフィック表示は、チャート、グラフ、テキストベース表示、複数のグラフィック表示形式の組合せ等の任意の適切なグラフィック表示形式を含み得るが、それらに限定されない。いくつかの実施形態では、ステップ６４０は、グラフィック表示をステップ６３０で得られる結果に基づいて選択する（例えば、結果を表示するのに適した形式を選択する）ことができる。この選択は結果の「構造」に基づくものとし得る。従って、ステップ６４０は、上述のように、ユーザが決めた選択基準に基づいて結果を分析するステップも含むことができる。代わりに、いくつかの実施形態では、グラフィック表示は、上述のように、ネットワークアクセス可能なサーバ統合モジュールにより生成されるようにすることができる。
【００６３】
いくつかの実施形態では、ステップ６４０はグラフィック表示を表示装置に提示する。グラフィック表示はユーザ入力を受信するように構成されたユーザインタフェースコンポーネントを備えることができる。ステップ６４０は、グラフィック表示をユーザインタフェースを介して受信されるユーザ入力に応答して変更するステップを含むことができる。例えば、ステップ６４０は、グラフィック表示の一部分へのズームイン、グラフィック表示内におけるパンニング、グラフィック表示のタイプの変更（例えば、グラフから円グラフ）等を含み得る。いくつかの実施形態では、ユーザインタフェースコンポーネントが要求パラメータを受信するように構成する、及び／又は、ユーザがコンピュータ装置によりステップ６２０で別のサービス要求を送信させることができるように構成することができる。新しいサービス要求に対する応答の受信に応答して、グラフィック表示を更新し、ステップ６３０及び６４０でユーザに提示することができる。
【００６４】
ステップ６５０において、フローは次のサービス要求がサービスインタフェースモジュールに送信されるまで終了となる。
【００６５】
上述の記載は、本願明細書に記載されている実施形態の理解のため、多くの具体的な詳細を提供する。しかしながら、当業者によれば、１つ以上の具体的な詳細が省略可能であり、また他の方法、構成要素、又はデータが使用可能であることが認められるだろう。一部の例では、動作は示されず又は詳細に記載されていない。
【００６６】
更に、記載された機能、動作、又は特徴は１つ以上の実施形態において任意の適切な態様に結合することができる。当業者に明らかなように、開示された実施形態と関連して記載された方法に係るステップ及び動作の順序は変更可能であることは容易に理解されるだろう。そして、順序が必須であると特定されていない限り、図面又は詳細な説明におけるいかなる順序も、説明のためだけであって、必須の順序を意味するものではない。
【００６７】
実施形態は様々なステップを含んでもよく、これらは汎用または専用コンピュータ（又は他の電子デバイス）により実行し得る機械実行可能な命令として具体化してもよい。また、ステップは、ステップを実行する特定の論理回路を含むハードウェア要素により、又はハードウェア、ソフトウェア、及び／又はファームウェアの組み合わせにより、実行してもよい。
【００６８】
実施形態は、本願明細書に記載されている処理を実行するようにコンピュータをプログラムするために使用し得る命令が格納されたコンピュータ読取り可能媒体を含むコンピュータプログラム製品として実現してもよい。コンピュータ読取り可能媒体としては、ハードドライブ、フロッピー（登録商標）ディスク、光学ディスク、ＣＤＲＯＭ、ＤＶＤＲＯＭ、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、ソリッドステートメモリ装置、又は電気的命令を格納するのに適した他の形式の媒体／コンピュータ読取り可能媒体を含むことができるが、これらに限られるものではない。
【００６９】
本願明細書において、ソフトウェアモジュール又は要素は、メモリ装置及び／又はコンピュータ読取り可能な媒体内に格納された任意のタイプのコンピュータ命令又はコンピュータ実行可能なコードを含んでもよい。ソフトウェアモジュールは、例えば、コンピュータ命令の１つ以上の物理的又は論理的ブロックを備えてもよい。このブロックは、１つ以上のタスクを実行する又は特定の抽象データ型を実行するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等として編成してもよい。
【００７０】
いくつかの実施形態では、特定のソフトウェアモジュールは、メモリ装置内の異なる位置に格納された、モジュールの記載の機能を実行する全く異なる命令を備えてもよい。実際は、モジュールは１つの命令又は複数の命令を備えることができ、またいくつかの異なるコードセグメントに、異なるプログラム間で、及びいくつかのメモリ装置に、分散させてもよい。いくつかの実施形態は分散型コンピュータ環境において実施され、通信ネットワークを介して接続されるリモート処理装置によりタスクが処理される。分散型コンピュータ環境において、ソフトウェアモジュールは、ローカル及び／又はリモートのメモリ記録装置内に存在させてもよい。更に、結合された又はデータベースレコードにされたデータは、同一のメモリ内に又はいくつかのメモリにわたって常駐させてもよく、またネットワークの全域にわたってデータベース内のレコードのフィールドで相互に結合してもよい。
【００７１】
本発明の基本原理から逸脱することなく、先に述べた実施形態の詳細について多くの変更をなし得ることは当業者に理解されよう。
【図１】
2015505387.tif 000003
【図２】
2015505387.tif 000004
【図３】
2015505387.tif 000005
【図４】
2015505387.tif 000006
【図５】
2015505387.tif 000007
【図６】
2015505387.tif 000008
【国際調査報告】
2015505387.tif 000009
2015505387.tif 000010