JP2017111834A - 動的サービス統合システム及び方法 - Google Patents

Abstract

【課題】クライアントは広範なカスタマイズなしで様々なデータソースにアクセスすることを可能にする。
【解決手段】サービス統合モジュールは複数のサービスレコード２５０を備え、各サービスレコードは別のデータソース２３０と夫々関連付けられる。サービス統合モジュールは、データソースドライバ、信用情報及び接続情報を含むデータソース統合を管理するように構成される。クライアント２８０からのサービス要求に応答して、前記サービス統合モジュールは、サービスレコードを識別し、データソースクエリを生成し、クエリの結果２１９にアクセスし、その結果をクライアントに送信する。また、サービス統合モジュールは、データソースから返される生データを標準フォーマットにマッピングする。サービス統合モジュールは、前記結果をクライアントにより指定されたフォーマット又はデータ符号化に再フォーマット化する。
【選択図】図２

Description

本発明は、サービスの生成及び提供に関し、より詳しくはデータソース及びクライアン
トの動的統合に関する。

現在の情報技術システムは様々なタイプのデータソースへのアクセスにますます依存し
ている。

しかしながら、クライアントを様々なデータソースに適応させることは時間を要し、間
違いを起こしやすいタスクである。一部のデータソース及び／又はサービスはサービス記
述を公開しているが、これらのサービスを利用したいクライアントは依然としてサービス
記述に従ってカスタマイズされなければならない。更に、このカスタマイズオーバヘッド
は、多数の異なるクライアントを異なるデータソースにアクセスするように適応化させる
場合に増大する。

本明細書に開示されるシステム及び方法は、クライアントを様々なタイプのデータソー
スと統合するのに要するカスタマイズオーバヘッドを最小化又は削減するために使用する
ことができる。ユーザは、クライアントを様々なタイプのデータソースと統合するために
、本明細書に開示される動的サービス統合システム及び方法を、データソースで使用され
ている基本的な技術及び／又はデータフォーマット及び／又は通信機構に関する最小限の
知識で利用することができる。新しいデータソース及びサービスは、それらを登録すると
直ちに利用可能になるため、コンパイル（編集）及びデプロイメント（展開）の遅れを生
じない。

いくつかの実施形態では、サービス統合モジュールは１つ以上のデータソースへのアク
セスを簡単にすることができる。サービス統合モジュールは１つ以上のデータソースをそ
れぞれのデータソースレコードに登録することができる。各データソースレコードは特定
のデータソースに関連する情報を含むことができる。データソースレコードは、データソ
ースのドライバ、データソース信用情報、データソース接続情報等を含むことができるが
、それらに限定されない。本明細書において、データソースのドライバは、特定のタイプ
のデータソースと相互作用するように構成されたコンポーネント又はライブラリ（例えば
、コンピュータ読取り可能な命令）を指す。ドライバは、ＪＤＢＣ(Java Database Conne
ctivity)ドライバ、ＯＤＢＣ(Object Database Connectivity)ドライバ、ＳＱＬ(Structu
red Query Language)データベースドライバ、セマンティックデータソースコネクティビ
ティドライバなどを含むことができるが、それらに限定されない。データソースレコード
は、ドライバ自体とは対照的に、データソースドライバへのリファレンス又はリンクを含
むことができる。データソース信用情報はデータソースの認証に使用することができる。
データソース信用情報は、ユーザ名、パスワード、ＰＩＮ、証明書、鍵等を含むことがで
きる。データソース接続情報は、特定のデータソースへの接続（対応するドライバを用い
る）を開始するために使用される接続文字列（ストリング）又は他の情報を含むことがで
きる。接続文字列は、データソースのアドレス（例えば、データソースのＵＲＬ）を含み
、データソース名（例えば、テーブル又はデータベース名）を識別し、データソースドラ
イバを特定する。

サービス統合モジュールは、１つ以上のサービスのためにデータソースへのアクセスを
提供することができる。サービス統合モジュールは１つ以上のサービスをそれぞれのサー
ビスレコードを用いて登録することができる。サービスレコードは、識別子、データソー
ス（例えば、データソースへのリファレンス）、パラメータ化されたクエリ、結果マッピ
ング等を含むが、それらに限定されない。サービスは１つ以上のデータソースを参照し得
る。データソースは複数の異なるサービスで使用され得る（例えば、参照され得る）。

サービスのパラメータ化されたクエリはクエリ文字列（又は他のクエリフォーマット）
を含むことができ、これは１つ以上のパラメータプレースホルダを含むことができる。プ
レースホルダはデータソースクエリを形成するためにサービス要求のパラメータと置き換
えることができる。本明細書で使用される「サービス要求」は、サービス及び／又はデー
タソースを対象にする要求を指す。サービス要求は、１つ以上の要求パラメータ、サービ
ス識別子又は名前、認証信用情報等を含むことができる。１つ以上の要求パラメータはデ
ータソースクエリを生成するためにパラメータ化されたクエリに挿入することができる。
本明細書において、「データソースクエリ」は、特定のデータソースとともに使用するよ
う構成されたクエリを指す。例えば、ＳＱＬ(Structured Query Language)データベース
内の特定の人を検索するためのパラメータ化されたクエリは、”select*from TABLE wher
e FIRST_NAME=%search_parameter%”を含むことができる。”%search_parameter%”の値
はサービス要求からのパラメータと交換することができる。いくつかの実施形態では、デ
ータソースクエリの生成は、更に、１つ以上の要求パラメータを特定のデータソースに適
したフォーマットに再フォーマットすることを含むことができる。例えば、要求パラメー
タはＵＴＦ−８エンコーディングからＡＳＣIIエンコーディング等に変換することができ
る。

サービスレコードの結果マッピングは、データソースからの生結果データと標準データ
フォーマットとの間のマッピングを含むことができる。標準フォーマットは、ＸＭＬ（eX
tensible Markup Language）、ＪＳＯＮ（Javascript Object Notation）、ＹＡＭＬ、Ｔ
ｕｒｔｌｅ（Terse RDF Triple Language）などのＲＤＦ（Resource Description Format
）、デリミテッドテキスト、又はそれらのフォーマットの組合せなどを含むことができる
が、それらに限定されない。いくつかの実施形態では、結果は代替フォーマット又は代替
エンコーディングに変換することができる。変換はサービス要求内で指定することができ
る。例えば、結果はバイナリフォーマット、特定のテキストエンコーディング（例えば、
ＡＳＣII、ＵＴＦ−８等）などに変換することができる。例えば、サービス要求は、ＸＭ
Ｌ標準フォーマットの結果はＵＴＦ−８キャラクタエンコーディングを用いて符号化する
ことを指定することができる。

模範的なサービスレコードのデータ構造及び模範的なデータソースレコードのデータ構造を示す図である。 動的サービス統合を提供するシステムの一実施形態のブロック図である。 動的サービス統合方法の一実施形態のフローチャートである。 動的サービス統合方法の別の実施形態のフローチャートである。 動的サービス統合方法の別の実施形態のフローチャートである。 動的サービス統合方法の別の実施形態のフローチャートである。

図１は模範的なサービスレコードのデータ構造及び模範的なデータソースレコードのデ
ータ構造を示す。模範的なサービスレコードのデータ構造１５０は、識別子１５２、デー
タソースリファレンス１５４、パラメータ化されたクエリ１５６及び結果マッピング１５
８を含む。データソースリファレンス１５４はデータソースレコード１６０を参照し、デ
ータソースレコード１６０は、データソース識別子１６２、ドライバ１６４、データソー
ス信用情報１６６及び接続情報１６８（例えば接続文字列）を含む。代わりに又は加えて
、データソースレコード１６０はサービスレコードのデータ構造１５０の１つ以上のフィ
ールド内に組み込むことができる。

データ構造１５０及び１６０は、ハードディスク、不揮発性メモリ等の非一時的コンピ
ュータ読取り可能記録媒体上で具体化することができる。図１は模範的なデータ構造１５
０及び１６０を示すが、本発明はこれに限定されず、任意の適切なデータ構造を任意の適
切なフォーマットで使用するように適応させることができる。

クライアントは、任意の適切な要求機構を用いてサービス統合モジュールのサービスに
アクセスすることができる。いくつかの実施形態では、クライアントは、ＨＴＴＰ（Hype
r Text Transfer Protocol）ＧＥＴ要求を用いてサービス統合モジュールのサービスにア
クセスすることができる。ＧＥＴ要求は要求サービスを識別する及び／又は１つ以上の要
求パラメータを含むことができる。サービス要求に応答して、サービス統合モジュールは
サービスレコードを識別し、データソースクエリを生成し、（データソース又は結果キャ
ッシュ内の）データソースクエリの結果にアクセスし、その結果をクライアントに送信す
ることができる。サービス統合モジュールは結果を標準フォーマットにマッピングするこ
と及び／又は結果を上述したように変換することができる。

いくつかの実施形態では、サービス統合モジュールはデータソース要求の結果をキャッ
シュするように構成される。サービス統合モジュールは結果を記録媒体への記録に適した
フォーマットにシリアル化し、シリアル化した結果をデータソースクエリ及び／又は１つ
以上の要求パラメータに関連付けてキャッシュ内に格納することができる。同じ結果に対
する後続のサービス要求（同じ要求パラメータを有し及び／又は同等のデータソースクエ
リを生じる）は結果キャッシュから戻すことができる。いくつかの実施形態では、キャッ
シュされた結果は所定の期間に亘って及び／又はキャッシュポリシ（例えば、最長時間未
使用（ＬＲＵ）ポリシ又は他の適切なキャッシュポリシ）に従って格納される。いくつか
の実施形態では、サービス統合モジュール２１０はデータソースへの書込み及び／又は変
更などの他の記録操作に応答してキャッシュから無効（例えば、ダーティ（不正））エン
トリを除去することができる。

いくつかの実施形態では、サービス要求はアグリゲート要求を含むことができ、この要
求は１つ以上のデータソースから複数のデータのセットを要求するものである。アグリゲ
ート要求は複数のクエリを１つのデータソースに発行し、各クエリが１つ以上の結果を生
じるものとし得る。アグリゲート要求は複数の区切られた要求パラメータ（例えばＧＥＴ
要求パラメータ）とすることができ、各パラメータはサービスのパラメータ化されたクエ
リに適用してそれぞれ異なるデータソースクエリ及び対応する結果を生成することができ
る。結果の各々は上述したように標準フォーマットにマッピングする及び／又は変換する
ことができる。いくつかの実施形態では、アグリゲート結果は上述したようにシリアル化
し、キャッシュすることができる。結果はアグリゲートクエリに及び／又は個別のデータ
ソースクエリとしてキャッシュすることができる。

いくつかの実施形態は結果のグラフィック（図表）表示を提示のために表示装置上に自
動的に生成するように構成された提示モジュールを備えることができる。グラフィック表
示は、チャート、グラフ、複数のグラフィック表示の組み合わせ等を含むことができるが
、それらに限定されない。かわりに又は加えて、提示モジュールは、表形式、円柱形式、
集計表形式等の特定の形式で結果のテキスト（文字）表示を生成することができる。

図２は動的サービス統合用システム２００の一実施形態のブロック図である。システム
２００はコンピュータ装置２２０上で動作するサービス統合モジュール２１０を備えるこ
とができる。コンピュータ装置２２０は、プロセッサ２２２、メモリ、非一時的記録媒体
２２４（例えば、ハードディスク、固体記録装置等）、通信インタフェース２２６等を備
えることができる。いくつかの実施形態では、サービス統合モジュール２１０は、非一時
的記録媒体２２４に格納され、プロセッサ２２２で実行されるように構成された命令とし
て具体化される。図２は単一のプロセッサ２２２を有する単一のコンピュータ装置２２０
上で動作するサービス統合モジュール２１０を示すが、本発明はこれに限定されない。い
くつかの実施形態では、システム２００は、クラスタ化された環境及び／又は高可用性環
境において複数のコンピュータ装置２２０（又は仮想コンピュータ装置）上で動作する複
数のサービス統合モジュール２１０を備えることができる。

サービス統合モジュール２１０はネットワーク２４０を介して１つ以上のデータソース
２３０に通信可能に結合され得る。各データソース２３０はそれぞれのサーバコンピュー
タ、クラスタ又は他の適切なコンピュータ装置上で動作し得る。ネットワーク２４０は任
意の適切な通信ネットワークとすることができ、インターネットプロトコル（ＩＰ）ネッ
トワーク、インターネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネッ
トワーク（ＷＡＮ）、無線ネットワーク、セルラー方式データネットワーク、公衆交換電
話ネットワーク（ＰＳＴＮ）等を含み得るが、それらに限定されない。

図２は模範的なネットワークアクセス可能なデータソース２３０を示すが、本発明はこ
れに限定されない。いくつかの実施形態では、システム２００は、ネットワークアクセス
可能なデータソース２３０に加えて（又は代わりに）１つ以上のローカルデータソースを
備えることができる。ローカルデータソースは、サービス統合モジュール２１０及び／又
はコンピュータ装置２２０に、１つ以上のバス又は他の通信リンク（例えば、ユニバーサ
ルシリアルバス、ＩＥＥＥ１３９４、ＳＣＳＩ、ＰＣＩ（Peripheral Component Interco
nnect）等）を介して通信可能に結合することができる。

サービス統合モジュール２１０はデータストア２１２を備えることができ、このデータ
ストアには１つ以上のサービスレコード２５０及び／又は１つ以上のデータソースレコー
ド２６０が格納される。各データソースレコード２６０は、上述したように、識別子、ド
ライバ、信用情報及び接続情報を含むことができる。いくつかの実施形態では、データス
トア２１２は、上述したように、１つ以上のデータソースクエリの結果をキャッシュする
結果キャッシュ２７０を備えることができる。

サービス統合モジュール２１０は、データソース識別子、ドライバ、信用情報、接続情
報等を含むデータソース追加要求に応答して、新しいデータソースレコード２６０をデー
タストア２１２に追加するように構成することもできる。いくつかの実施形態では、サー
ビス統合モジュール２１０は、対応するデータソースレコード２６０をデータストア２１
２に追加する前に、新しいデータソースが提供される情報と接触できることを検証する。

いくつかの実施形態では、サービス統合モジュール２１０はサービス登録インタフェー
ス２１４（例えば、ウェブインタフェース）を備え、ユーザはこのインタフェースを介し
てデータソースレコード２６０及び／又はサービスレコード２５０を生成、編集もしくは
管理することができる。サービス統合モジュール２１０は、サービス登録インタフェース
２１４を介して新しいサービスレコード２５０及び／又はデータソースレコード２６０を
データストア２１２に追加するように構成することができる。サービスレコード２５０を
追加する要求は、識別子、データソース、パラメータ化されたクエリ、結果マッピング等
を含むことができる。いくつかの実施形態では、サービス統合モジュール２１０は、新し
いサービスレコード２５０をデータストア２１２に追加する前にそのサービスを検証する
。サービスの検証は、指定のデータソースがデータストア２１２に存在するかどうかの決
定、データソースの検証、パラメータ化されたクエリの検証（例えば、クエリの構文（シ
ンタックス）の検証、１つ以上の試験パラメータを有するデータソースに対するクエリの
試験等）、及び／又は結果マッピングの検証（例えば、マッピングの構文の検証等）を含
むことができる。サービスの検証は、更に、クライアントが新しいサービスレコードの追
加を許可していることを確かめるために要求を認証することも含むことができる。

サービス登録インタフェース２１４は、データソース２３０の１つ以上の生データタイ
プと標準データフォーマットとの間の結果マッピングをユーザが指定することを可能にす
ることができる。マッピングは上述したように１つ以上のサービスレコード２５０に適用
することができる。サービス登録インタフェース２１４は１つ以上のデータソース２３０
への接続を試験し、試験クエリを１つ以上のサービスに通すこと等によって１つ以上のサ
ービス及び／又はデータソースを試験するように構成することができる。いくつかの実施
形態では、サービス登録インタフェース２１４は結果キャッシュ２７０に対するポリシを
指定することもユーザに可能にすることができる。キャッシュポリシはエージアウト（削
除）タイム、最大キャッシュ容量、ＬＲＵポリシ等を含み得る。

データソース及びサービスは登録時にサービス統合モジュール２１０に追加することが
できる。従って、新しいデータソース及び／又はサービスは、対応するデータソースレコ
ード及び／又はサービスレコード２５０がデータストア２１２に生成されると同時に使用
可能になり得る。

サービス統合モジュール２１０は、サービス統合モジュール２１０に登録された１つ以
上のサービスを、ネットワーク１４０を介してクライアント２８０に提示するように構成
されたサービスインタフェース２１６を備えることができる。本明細書で使用される「ク
ライアント」は、クライアントコンピュータ装置を指し、例えばパーソナルコンピュータ
装置、ラップトップ、ノートブック、タブレット、携帯情報端末（ＰＤＡ）、スマートフ
ォン等を含み得るが、それらに限定されない。いくつかの実施形態では、サービス統合モ
ジュール２１０は各サービスレコード２５０をそれぞれのＵＲＩ（Uniform Resource Ide
ntifier）と関連させることができる。クライアント２８０はＵＲＩを使って要求を特定
のサービスに向けることができる。サービスレコード２５０のＵＲＩはサービスレコード
の識別子から導出することができる。例えば、サービスインタフェース２１６のホストネ
ームが”service.com”である場合、“Service_A”として識別されるサービスのＵＲＩは
”service.com／services／Service_A”とし得る。いくつかの実施形態では、サービスは
要求パラメータで識別することができる。例えば、サービスインタフェース２１６に向け
られたＨＴＴＰ要求は、値”Service_A”を有する「サービス識別子」パラメータを含む
ことができる。サービスを登録及び／又は提示する模範的なメカニズムをここに記載した
が、本発明はこれに限定されず、任意の適切な登録メカニズムを使用するように適応化さ
せることができる。

いくつかの実施形態では、サービスインタフェース２１６は利用可能なサービス及び／
又はデータソースのリスティング又はディレクトリを提供する。サービスインタフェース
２１６は１つ以上の登録サービスのパラメータを列挙すること及び／又は模範的なサービ
ス要求を提供することができる。サービスインタフェース２１６は、更に、サービスマッ
ピング情報を提供する及び／又はサービスの結果を返し得る標準フォーマットを指定する
ことができる。サービスインタフェース２１６は、上述したように１つ以上のサービスを
サービス登録インタフェース２１４により編集及び／又は変更することをユーザに可能に
することができる。

サービスインタフェース２１６は、１つ以上のクライアント２８０からのサービス要求
２１７を受信するように構成される。サービスインタフェース２１６はサービス要求２１
７を、例えばＨＴＴＰ、ＳＯＡＰ（Simple Object Access Protocol）、ＲＰＣ（Remote
Procedure Call）、ＲＭＩ（Remote Method Invocation）等の任意の適切なメカニズムを
用いて受信することができるが、それらに限定されない。

サービス要求２１７の受信時に、サービス統合モジュール２１０は要求２１７を検証す
ることができ、この検証は要求構文の検証、要求パラメータの検証等を含み得る。いくつ
かの実施形態では、サービス統合モジュール２１０へのアクセスは認証されたユーザに制
限される。サービス統合モジュール２１０はユーザデータベース、ディレクトリ等（図示
せず）を備えることができ、及び／又はそれらに通信可能に結合することができる。サー
ビス要求２１７の検証は、サービス要求２１７内の信用情報、例えばユーザ名及びパスワ
ード、ＰＩＮ、ディジタル署名等を検証することも含むことができる。

サービス要求２１７の検証時に、サービス統合モジュール２１０は、上述したように、
対応するサービスレコード２５０を識別することができる。サービス統合モジュール２１
０は、要求２１７が向けられたＵＲＩ、サービス要求２１７のパラメータ等に基づいてサ
ービスレコード２５０を識別することができる。

サービス統合モジュール２１０は識別されたサービスレコード２５０のパラメータ化さ
れたクエリ及び／又はサービス要求のパラメータを用いてデータソースクエリを生成する
ことができる。データソースクエリの生成は、サービス要求２１７の１つ以上の要求パラ
メータをサービスレコード２５０のパラメータ化されたクエリに挿入することを含むこと
ができる。いくつかの実施形態では、要求パラメータはデータソース２３０に対して適切
なフォーマットにフォーマット化及び／又は符号化することができる。

サービス要求２１７は複数のデータのセットに対する要求を含むことができる。例えば
、サービス要求２１７は複数の要求パラメータのセットを含むことができる。このような
要求に応答して、サービス統合モジュール２１０は複数の異なるデータソースクエリを生
成することができ、各データソースクエリはそれぞれの要求パラメータのセットを含む。
要求パラメータは特定の文字で区切ること及び／又はサービス要求２１７のフォーマット
で示すことができる。

サービス統合モジュール２１０は、データソースクエリを用いて結果を生成し及び／又
はクライアントへ送信することができる。いくつかの実施形態では、サービス統合モジュ
ール２１０は、結果が結果キャッシュ２７０にキャッシュされているかどうかを決定する
。そうであれば、サービス統合モジュール２１０は、データソース２３０に問い合わせる
ことなく、キャッシュされた結果をクライアントに送信することができる。

結果がキャッシュ２７０内に見つからない場合（又はキャッシュされた結果が無効であ
る場合）には、サービス統合モジュール２１０はネットワーク２４０を介してデータソー
ス２３０からの結果にアクセスすることができる。サービス統合モジュール２１０は、サ
ービスレコード２５０により参照されるデータソースレコード２６０のドライバ、信用情
報及び／又は接続情報を用いてデータソース２３０にアクセスすることができる。サービ
ス統合モジュール２１０はクライアントクエリ２１７に結果を含む応答２１９を送信する
ことができる。

いくつかの実施形態では、サービス統合モジュール２１０は、上述したように、サービ
スレコード２５０の結果マッピングを適用し、データソースから取得した結果を標準フォ
ーマットにマッピングするように構成される。応答２１９は標準フォーマットの結果を含
む。いくつかの実施形態では、サービス統合モジュール２１０は結果をサービス要求２１
７に指定されたフォーマットにフォーマット化するよう構成することができる。上述した
ように、フォーマットは、バイナリフォーマット、テキストフォーマット、又はクライア
ント２８０の使用に適した他のフォーマットとすることができる。

サービス統合モジュール２１０は、結果を結果キャッシュ２７０にキャッシュするよう
に構成することができる。結果のキャッシングは、結果を非一時的コンピュータ読取り可
能記録媒体に記録するのに適したフォーマットに「シリアル化」し、シリアル化した結果
を結果クエリと関連させることを含むことができる。シリアル化した結果は、最終アクセ
ス時間、アクセス周波数メトリック、経過時間等のキャッシュ管理データと関連させるこ
とができる。

クライアント２８０は応答２１９を受信し、そこから結果を抽出することができる。い
くつかの実施形態では、クライアント２８０は、結果２１９を表示装置、オーディオ出力
装置などのクライアント２８０の１つ以上の人間−機械インタフェースコンポーネントに
提示するように構成されたクライアント提示モジュール２８２を備える。クライアント提
示モジュール２８２は、結果をグラフィック、テキスト等の任意の方式で提示するように
構成することができる。いくつかの実施形態では、クライアント提示モジュール２８２は
、サービス統合モジュール２１０から利用可能であり、及び／又はネットワーク２４０を
介してアクセス可能である（例えば、クライアント提示モジュール２８２はサービス統合
モジュール２１０により提供されるアプレットを備えることができる）。

クライアント提示モジュール２８２は、結果２１９に対して適切なグラフィック表示形
式を選択することができる。グラフィック表示形式は、チャート、テキストベース形式（
例えば、表形式、円柱形式、集計表形式等）、複数の形式の組合せ等を含み得るが、それ
らに限定されない。クライアント提示モジュール２８２は、結果２１９の「構造」、例え
ば結果２１９に表示される変数の数及び／又はタイプ、結果２１９の入力／出力変数の数
、サービス要求２１７のパラメータ等に基づいてグラフィック表示形式を選択することが
できる。従って、クライアント提示モジュール２８２は結果２１９を分析して適切なグラ
フィック表示形式を選択することができる。この選択は１つ以上のユーザ決定選択基準又
は好みに基づくものとすることができる。

代わりに又は加えて、サービス統合モジュール２１０は、クライアント２８０への提示
のために結果２１９のグラフィック表示を自動的に生成するように構成されたサーバ側提
示モジュール２１３を備えることができる。サーバ側提示モジュール２１３は、上述した
ように、結果２１９に対して適切なグラフィック表示形式を自動的に選択することができ
る。フォーマット化された結果を提示のためにクライアント２８０に供給することができ
る。

いくつかの実施形態では、クライアント２８０は、サービス統合モジュールから得られ
た結果をネットワーク２４０を介して１つ以上のクライアント２８４に提示するように構
成されたサーバコンピュータ装置を備えることができる。例えば、クライアント２８０は
、結果をアグリゲートし複数のクライアントコンピュータ装置２８４に公開するように構
成されたウェブサーバを備えることができる。

図３は、動的サービス統合方法３００の一実施形態のフローチャートである。ステップ
３１０において、方法３００は開始し、初期化される。方法３００は非一時的記録媒体上
のコンピュータ読取り可能な命令として具体化することができる。従って、ステップ３１
０は、１つ以上のコンピュータ読取り可能な命令をロードし及び／又はこの１つ以上の命
令をコンピュータ装置で実行するステップを含むことができる。方法３００の１つ以上の
ステップは、通信インタフェース、コンピュータ読取り可能な記録媒体等の特定のマシン
コンポーネントに関連し得る。従って、ステップ３１０はこれらのマシンコンポーネント
へのアクセス及び／又はそれらの初期化も含み得る。

ステップ３２０において、方法３００はネットワーク通信インタフェースを介してサー
ビス要求を受信することができる。サービス要求はサービス識別子及び／又は１つ以上の
要求パラメータを含み得る。上述したように、サービス識別子はステップ３３０において
サービスレコード及び／又はデータソースレコードを識別するために使用される。ステッ
プ３２０で識別されたサービスレコード及び／又はデータソースレコードはコンピュータ
装置の非一時的コンピュータ読取り可能記録媒体に格納し得る。

ステップ３４０は、サービスレコードのパラメータ化されたクエリ及び／又はサービス
要求の要求パラメータの１つ以上を用いてデータソースクエリを生成するステップを含む
ことができる。ステップ３４０は、１つ以上の要求パラメータをパラメータ化されたクエ
リに挿入するステップを含むこともできる。いくつかの実施形態では、ステップ３４０は
、１つ以上の要求パラメータを特定のデータソースに適切なフォーマットにフォーマット
化及び／又は符号化するステップを含むこともできる。代わりに又は加えて、結果はデー
タソースからアクセスすることもできる。データソースからのアクセスは、ステップ３３
０で識別されたデータソースレコードのドライバ、信用情報及び／又は接続情報を用いて
クエリをデータソースに発行するステップを含むこともできる。

ステップ３５０は、結果をクライアントにネットワークを介して送信するステップを含
むことができる。いくつかの実施形態では、ステップ３５０は、サービスレコードの結果
マッピングを適用して生結果データを標準フォーマットにマッピングするステップを含む
こともできる。ステップ３５０は更に、上述したように、結果をクライアントに対して適
切なフォーマットに変換するステップを含むこともできる。いくつかの実施形態では、ス
テップ３５０は更に、上述したように、結果を結果キャッシュに含めるステップを含むこ
ともできる。

ステップ３６０において、方法３００は別のサービス要求が受信されるまで終了となる
。

図４はサービス統合を動的に提供する方法４００の別の実施形態のフローチャートであ
る。

ステップ４１０において、方法４００は開始し、初期化される。方法４００は、非一時
的記録媒体上のコンピュータ読取り可能な命令として具体化することができる。従って、
ステップ４１０は、１つ以上のコンピュータ読取り可能な命令をロードし及び／又はこの
１つ以上の命令をコンピュータ装置で実行するステップを含み得る。方法４００の１つ以
上のステップは、通信インタフェース、コンピュータ読取り可能な記録媒体等の特定のマ
シンコンポーネントに関連し得る。従って、ステップ４１０はこれらのマシンコンポーネ
ントへのアクセス及び／又はそれらの初期化も含み得る。ステップ４２０は、上述のよう
に、サービス要求を受信するステップを含む。

ステップ４２２において、サービス要求を検証することができる。サービス要求の検証
は、要求の構文の検証、要求の信用情報の検証（例えば、要求が許可されたユーザからの
ものであるかの検証）等を含むことができる。ステップ４２２は更に、サービス要求が有
効なサービスレコード及び／又はデータソースレコードを参照するかを検証するステップ
を含むこともできる。サービス要求が有効である場合、方法４００はステップ４３０に進
み、さもなければ、方法４００はステップ４２４に進む。

ステップ４２４は、エラー応答をクライアントに返すステップを含むことができる。ス
テップ４２４は、エラーの性質を示し、後続のサービス要求においてこのエラーの対処方
法に関する指示を提供するエラー応答を生成するステップを含むこともできる。

ステップ４３０において、方法４００は上述のようにサービス要求に対応するサービス
レコードを識別する。ステップ４３２において、方法４００は、サービス要求の結果が結
果キャッシュで入手可能かを決定することができる。ステップ４３２は、サービス要求の
１つ以上の要求パラメータ（又はデータソースクエリ）で結果キャッシュに問い合わせ（
クエリ）を行うことを含むことができる。ステップ４３２は更に、キャッシュ結果が有効
であるか（例えば、期限切れでなく、「ダーティ（不正）」でないか）を決定するステッ
プを含むこともできる。有効な結果がキャッシュで得られる場合には、方法４００はステ
ップ４７０に進み、さもなければ、方法４００はステップ４４０に進む。

ステップ４４０は、サービス要求に対してデータソースクエリを生成するステップを含
むことができる。ステップ４４０はステップ４３０で識別されたサービスレコードのパラ
メータ化されたクエリ内に１つ以上の要求パラメータを挿入するステップを含むこともで
きる。ステップ４３０は更に、要求パラメータの１つ以上をデータソースに適したフォー
マットに再フォーマット及び／又は符号化するステップを含むこともできる。

ステップ４５０は、サービスレコード内で参照されるデータソースレコードのドライバ
、信用情報及び／又は接続情報を用いて、データソースにクエリを発行するステップを含
むことができる。ステップ４５０は更に、データソースからのクエリに対する応答を受信
するステップを含むこともできる。ステップ４６０は、上述のように、データソースから
返される生データに結果マッピングを適用するステップを含むことができる。いくつかの
実施形態では、ステップ４６０は更に、結果を結果キャッシュにキャッシュするステップ
を含むこともできる。

いくつかの実施形態では、方法４００は更に、上述のように、ステップ４７０において
、結果をサービス要求内で指定されているフォーマットに変換するステップを含む。結果
はステップ４８０においてネットワークインタフェースを用いてクライアントコンピュー
タ装置に送信することができる。ステップ４９０において、方法４００は次の要求が受信
されるまで終了となる。

図５は動的サービス統合方法の別の実施形態のフローチャートである。ステップ５１０
において、方法５００は開始し、初期化される。方法５００は、非一時的記録媒体上のコ
ンピュータ読取り可能な命令として具体化することができる。従って、ステップ５１０は
、１つ以上のコンピュータ読取り可能な命令をロードし及び／又はこの１つ以上の命令を
コンピュータ装置で実行するステップを含み得る。方法５００の１つ以上のステップは、
通信インタフェース、コンピュータ読取り可能な記録媒体等の特定のマシンコンポーネン
トに関連し得る。従って、ステップ５１０はこれらのマシンコンポーネントへのアクセス
及び／又はそれらの初期化も含み得る。

新しいサービスレコードを追加する要求はステップ５２０で受信される。この要求はネ
ットワークを介してクライアントから受信され得る。ステップ５２０の要求は、サービス
識別子、パラメータ化されたクエリ、結果マッピングを含み、データソースを参照し、及
び／又はデータソース識別子、ドライバ、信用情報及び／又は接続情報を指定する。

ステップ５２２は要求を検証し、この検証は、要求の構文の検証、要求が許可されたク
ライアントからのものかどうかを確定する要求の信用情報の検証等を含み得る。要求が有
効である場合、方法５００はステップ５３０に進む。いくつかの実施形態では、要求の検
証は、更に、新しいサービスレコード（及び／又は新しいデータソースレコード）を非一
時的コンピュータ読取り可能記録媒体に格納するステップを含む。新しいサービスは、ス
テップ５２２で有効とされると直ちに利用可能にし得る。従って、新しいサービスをコン
パイル及び／又はデプロイメント遅延なしで利用可能にすることができる。

要求が有効でない場合には、方法５００はステップ５２４に進み、ここでエラー応答が
返される。エラー応答は、エラーの性質を指示すること及び／又は後続のサービス要求に
おいてこのエラーにどのように対処できるか指示することができる。

ステップ５４０は、上述のように、新しいサービス要求に向けられたサービス要求を受
信するステップを含む。ステップ５５０は、上述のように、サービス要求に応答して結果
を生成し、その結果をクライアントに送信するステップを含み得る。ステップ５４０及び
５５０は、ステップ５２２で新しいサービスレコードが有効と検証されると直ちに生起す
る。

方法５００は、ステップ５５０において、別のサービス要求が追加されるまで及び／又
は別のサービス要求が受信されるまで、終了とされる。

図６は動的サービス統合方法の別の実施形態のフローチャートである。ステップ６１０
において、方法６００は開始し、初期化される。方法６００は、非一時的記録媒体上のコ
ンピュータ読取り可能な命令として具体化することができる。従って、ステップ６１０は
、１つ以上のコンピュータ読取り可能な命令をロードし及び／又はこの１つ以上の命令を
コンピュータ装置で実行するステップを含み得る。方法６００の１つ以上のステップは、
通信インタフェース、コンピュータ読取り可能な記録媒体等の特定のマシンコンポーネン
トに関連し得る。従って、ステップ６１０はこれらのマシンコンポーネントへのアクセス
及び／又はそれらの初期化も含み得る。

ステップ６１０において、クライアントのコンピュータ装置がサービス要求をネットワ
ークアクセス可能なサービス統合モジュールへ送信する。サービス要求はサービス識別子
及び１つ以上の要求パラメータを含むことができる。サービス要求はデータソースから独
立させ、データソースは要求の結果にアクセスするために問い合わせを受けるようにする
ことができる。従って、サービス要求は、ＨＴＴＰ、ＳＯＡ等の簡単なフォーマットで生
成することができる。サービス要求は、データソースドライバ、データソース信用情報等
を含まなくても、それらにリファレンスさせなくてもよい。いくつかの実施形態では、サ
ービス要求は要求の結果に対するフォーマット及び／又は符号化を指定することができる
（例えば、ＡＳＣIIテキスト、ＵＴＦ−８等）。

いくつかの実施形態では、ステップ６２０のサービス要求はコンピュータ装置上で動作
するアプリケーションで発生される。代わりに又は加えて、サービス要求は１つ以上のク
ライアントコンポーネント装置にコンテンツを提供するように構成されたウェブサーバの
コンポーネントにより発生され及び／又は送信されるようにし得る。

ステップ６３０において、クライアントコンピュータ装置は要求に対する応答を受信し
、この応答は結果をＸＭＬ、ＪＳＯＮ、ＹＡＭＬ、ＲＤＦ、Ｔｕｒｔｌｅ等の標準フォー
マットで含んでいる。これらの結果はサービス要求の指定に従ってフォーマット化及び／
又は符号化され得る。ステップ６３０で受信される応答は上述のようにサービス統合モジ
ュールにより生成することができる。

ステップ６４０において、クライアントコンピュータ装置は結果のグラフィック表示を
自動的に生成する。グラフィック表示は、チャート、グラフ、テキストベース表示、複数
のグラフィック表示形式の組合せ等の任意の適切なグラフィック表示形式を含み得るが、
それらに限定されない。いくつかの実施形態では、ステップ６４０は、グラフィック表示
をステップ６３０で得られる結果に基づいて選択する（例えば、結果を表示するのに適し
た形式を選択する）ことができる。この選択は結果の「構造」に基づくものとし得る。従
って、ステップ６４０は、上述のように、ユーザが決めた選択基準に基づいて結果を分析
するステップも含むことができる。代わりに、いくつかの実施形態では、グラフィック表
示は、上述のように、ネットワークアクセス可能なサーバ統合モジュールにより生成され
るようにすることができる。

いくつかの実施形態では、ステップ６４０はグラフィック表示を表示装置に提示する。
グラフィック表示はユーザ入力を受信するように構成されたユーザインタフェースコンポ
ーネントを備えることができる。ステップ６４０は、グラフィック表示をユーザインタフ
ェースを介して受信されるユーザ入力に応答して変更するステップを含むことができる。
例えば、ステップ６４０は、グラフィック表示の一部分へのズームイン、グラフィック表
示内におけるパンニング、グラフィック表示のタイプの変更（例えば、グラフから円グラ
フ）等を含み得る。いくつかの実施形態では、ユーザインタフェースコンポーネントが要
求パラメータを受信するように構成する、及び／又は、ユーザがコンピュータ装置により
ステップ６２０で別のサービス要求を送信させることができるように構成することができ
る。新しいサービス要求に対する応答の受信に応答して、グラフィック表示を更新し、ス
テップ６３０及び６４０でユーザに提示することができる。

ステップ６５０において、フローは次のサービス要求がサービスインタフェースモジュ
ールに送信されるまで終了となる。

上述の記載は、本願明細書に記載されている実施形態の理解のため、多くの具体的な詳
細を提供する。しかしながら、当業者によれば、１つ以上の具体的な詳細が省略可能であ
り、また他の方法、構成要素、又はデータが使用可能であることが認められるだろう。一
部の例では、動作は示されず又は詳細に記載されていない。

更に、記載された機能、動作、又は特徴は１つ以上の実施形態において任意の適切な態
様に結合することができる。当業者に明らかなように、開示された実施形態と関連して記
載された方法に係るステップ及び動作の順序は変更可能であることは容易に理解されるだ
ろう。そして、順序が必須であると特定されていない限り、図面又は詳細な説明における
いかなる順序も、説明のためだけであって、必須の順序を意味するものではない。

実施形態は様々なステップを含んでもよく、これらは汎用または専用コンピュータ（又
は他の電子デバイス）により実行し得る機械実行可能な命令として具体化してもよい。ま
た、ステップは、ステップを実行する特定の論理回路を含むハードウェア要素により、又
はハードウェア、ソフトウェア、及び／又はファームウェアの組み合わせにより、実行し
てもよい。

実施形態は、本願明細書に記載されている処理を実行するようにコンピュータをプログ
ラムするために使用し得る命令が格納されたコンピュータ読取り可能媒体を含むコンピュ
ータプログラム製品として実現してもよい。コンピュータ読取り可能媒体としては、ハー
ドドライブ、フロッピー（登録商標）ディスク、光学ディスク、ＣＤＲＯＭ、ＤＶＤＲＯ
Ｍ、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、ソリッドステー
トメモリ装置、又は電気的命令を格納するのに適した他の形式の媒体／コンピュータ読取
り可能媒体を含むことができるが、これらに限られるものではない。

本願明細書において、ソフトウェアモジュール又は要素は、メモリ装置及び／又はコン
ピュータ読取り可能な媒体内に格納された任意のタイプのコンピュータ命令又はコンピュ
ータ実行可能なコードを含んでもよい。ソフトウェアモジュールは、例えば、コンピュー
タ命令の１つ以上の物理的又は論理的ブロックを備えてもよい。このブロックは、１つ以
上のタスクを実行する又は特定の抽象データ型を実行するルーチン、プログラム、オブジ
ェクト、コンポーネント、データ構造等として編成してもよい。

いくつかの実施形態では、特定のソフトウェアモジュールは、メモリ装置内の異なる位
置に格納された、モジュールの記載の機能を実行する全く異なる命令を備えてもよい。実
際は、モジュールは１つの命令又は複数の命令を備えることができ、またいくつかの異な
るコードセグメントに、異なるプログラム間で、及びいくつかのメモリ装置に、分散させ
てもよい。いくつかの実施形態は分散型コンピュータ環境において実施され、通信ネット
ワークを介して接続されるリモート処理装置によりタスクが処理される。分散型コンピュ
ータ環境において、ソフトウェアモジュールは、ローカル及び／又はリモートのメモリ記
録装置内に存在させてもよい。更に、結合された又はデータベースレコードにされたデー
タは、同一のメモリ内に又はいくつかのメモリにわたって常駐させてもよく、またネット
ワークの全域にわたってデータベース内のレコードのフィールドで相互に結合してもよい
。

本発明の基本原理から逸脱することなく、先に述べた実施形態の詳細について多くの変
更をなし得ることは当業者に理解されよう。

Claims (25)

1. 動的サービス統合方法であって、
   クライアントからサービス識別子及び１つ以上の要求パラメータを含むサービス要求を
   コンピュータ装置で受信するステップ、
   前記サービス識別子を用いて、パラメータ化されたクエリを含み且つ複数のデータソー
   スレコードのうちの１つを参照する複数のサービスレコードのうちの１つを識別するステ
   ップであって、前記複数のサービスレコード及び前記複数のデータソースレコードは非一
   時的コンピュータ読取り可能な記録媒体に格納されている、ステップ、
   前記要求パラメータのうちの１つ以上を前記パラメータ化されたクエリに挿入してデー
   タソースクエリを生成するステップ、及び
   前記データソースクエリの結果を前記クライアントに前記コンピュータ装置のネットワ
   ークインタフェースで送信するステップ、
   を備える方法。
2. データソースの生データを標準フォーマットにマッピングするために前記サービスレコ
   ードの結果マッピングを適用するステップを更に備える、請求項１記載の方法。
3. データソースの生データをＸＭＬ（eXtensible Markup Language）フォーマット、ＪＳ
   ＯＮ（Javascript Object Notation）フォーマット、ＹＡＭＬフォーマット、ＲＤＦ（Re
   source Description Format）フォーマット、Ｔｕｒｔｌｅ（Terse RDF Triple Language
   ）フォーマット、及びデリミテッドテキストフォーマットのうちの１つにマッピングため
   に、前記サービスレコードの結果マッピングを適用するステップを更に備える、請求項１
   記載の方法。
4. 前記結果を前記サービス要求で指定されたフォーマットにフォーマット化するステップ
   を更に備える、請求項１記載の方法。
5. 前記データソースクエリを用いて、前記コンピュータ装置の結果キャッシュ内の前記結
   果にアクセスするステップを更に備える、請求項１記載の方法。
6. 前記結果をシリアル化するステップ、及び
   前記シリアル化した結果を前記データソースクエリに関連付けて前記コンピュータ装置
   の結果キャッシュ内にキャッシュするステップ、
   を更に備える、請求項１記載の方法。
7. 前記識別されたサービスレコードにより参照される前記データソースレコードのドライ
   バ、信用情報及び接続情報を用いて、前記データソースクエリをデータソースに発行する
   ステップを更に備える、請求項１記載の方法。
8. 前記サービス識別子は前記サービス要求のＵＲＩ（Uniform Resource Identifier）を
   含む、請求項１記載の方法。
9. 前記サービス識別子は前記サービス識別子のパラメータを含む、請求項１記載の方法。
10. 前記サービス要求を前記サービス要求に含まれる信用情報を用いて認証するステップを
    更に備える、請求項１記載の方法。
11. 前記コンピュータ読取り可能な記録媒体上の新しいデータソースレコードを参照する新
    しいサービスレコードを前記コンピュータ読取り可能な記録媒体に追加するステップ、
    前記新しいサービスレコードを識別するサービス要求を受信し、前記新しいサービスレ
    コードの追加時にデータソースクエリの結果を前記新しいデータソースレコードのデータ
    ソースに送信するステップ、
    を更に備える、請求項１記載の方法。
12. 前記結果のグラフィック表示を表示装置に提示するステップを更に備える、請求項１記
    載の方法。
13. 前記結果の構造に基づいてグラフィック表示形式を選択するステップ、及び
    前記結果のグラフィック表示を、前記選択したグラフィック表示形式で表示装置に提示
    するステップ、
    を更に備える、請求項１記載の方法。
14. コンピュータ装置に動的サービス統合方法を実行させるように構成された命令を含む非
    一時的コンピュータ読取り可能な記録媒体であって、前記方法は、
    クライアントからサービス識別子及び１つ以上の要求パラメータを含むサービス要求を
    受信するステップ、
    前記サービス識別子を用いて、パラメータ化されたクエリを含み且つ複数のデータソー
    スレコードのうちの１つを参照する複数のサービスレコードのうちの１つを識別するステ
    ップ、
    前記要求パラメータのうちの１つ以上を前記パラメータ化されたクエリに挿入してデー
    タソースクエリを生成するステップ、
    結果キャッシュ及びデータソースのうちの１つから前記データソースクエリの結果にア
    クセスするステップ、及び
    前記データソースクエリの結果を前記クライアントにネットワークを介して送信するス
    テップを備える、
    コンピュータ読取り可能な記録媒体。
15. 前記方法は標準フォーマットに前記結果をマッピングするステップを更に備える、請求
    項１４記載のコンピュータ読取り可能な記録媒体。
16. 前記方法は、前記結果を要求されたフォーマットに再フォーマット化するステップを更
    に備える、請求項１４記載のコンピュータ読取り可能な記録媒体。
17. 前記方法は、
    前記結果をシリアル化するステップ、及び
    前記シリアル化した結果を前記データソースクエリに関連付けて結果キャッシュ内にキ
    ャッシュするステップ、
    を更に備える、請求項１４記載のコンピュータ読取り可能な記録媒体。
18. 前記データソースレコードのドライバ、信用情報及び接続情報を用いて、前記データソ
    ースクエリをネットワークアクセス可能なデータソースに発行するステップを更に備える
    、請求項１４記載のコンピュータ読取り可能な記録媒体。
19. 前記サービス識別子は前記サービス要求のＵＲＩ（Uniform Resource Identifier）及
    び前記サービス要求の要求パラメータを含む、請求項１４記載のコンピュータ読取り可能
    な記録媒体。
20. 前記データソースクエリの生成ステップは、前記要求パラメータのうちの１つ以上を再
    フォーマット化することを含む、請求項１４記載のコンピュータ読取り可能な記録媒体。
21. 前記方法は、
    前記結果の構造に基づいてグラフィック表示形式を選択するステップ、及び
    前記結果のグラフィック表示を前記選択したグラフィック表示形式で表示装置に提示す
    るステップ、
    を更に備える、請求項１４記載のコンピュータ読取り可能な記録媒体。
22. 動的サービス統合装置であって、
    プロセッサ、ネットワークインタフェース、メモリ及び非一時的コンピュータ読取り可
    能な記録媒体を備えるコンピュータ装置、及び
    前記コンピュータ装置上で動作するサービス統合モジュールを備え、
    前記サービス統合モジュールは、クライアントからサービス識別子及び１つ以上の要求
    パラメータを含むサービス要求を前記ネットワークインタフェースで受信し、前記サービ
    ス識別子を用いて、複数のサービスレコードのうちの１つを識別し、前記識別したサービ
    スレコードのパラメータ化されたクエリ及び前記要求パラメータのうちの１つ以上からデ
    ータソースクエリを生成し、前記データソースクエリの結果を前記クライアントに前記ネ
    ットワークインタフェースで送信するように構成されている、装置。
23. それぞれのデータソースクエリの複数の結果を含む結果キャッシュを更に備え、前記サ
    ービス統合モジュールは前記結果キャッシュ及びネットワークアクセス可能なデータソー
    スのうちの１つから前記データソースクエリの前記結果にアクセスするように構成されて
    いる、請求項２２記載の装置。
24. 前記サービス統合モジュールは、前記サービスレコードの結果マッピングを用いて、デ
    ータソースの生データを前記データソースクエリの前記結果の標準フォーマットにマッピ
    ングするように構成されている、請求項２２記載の装置。
25. 前記サービス統合モジュールは、前記識別されたサービスレコードのドライバ、信用情
    報及び接続情報を用いて、ネットワークアクセス可能なデータソースから前記データソー
    スクエリの前記結果にアクセスするように構成されている、請求項２２記載の装置。