JP2010503905A - 発見ウェブサービス - Google Patents

Abstract

本発明は、少なくとも１つのサービス（２１０３、２１０４、２１０５）のデータモデルを識別するための構成に関し、構成は、少なくとも１つのサービスのデータモデルを記憶するための記憶手段と、データモデル間の関係を記憶するための記憶手段とを備える発見サービス（２１０６）を備え、構成は、サービスのデータモデルを収集するための検査手段と、データモデルと少なくとも１つのサービスのデータモデルの間の関係を確立するための検査手段とを備える。本発明はまた、サービスを検査して、サービスのデータモデルを導き、少なくとも１つのサービスの既に知られているデータモデル間の関係を確立して、これらのサービスのデータモデルおよびデータモデル間の関係を提供することによって、少なくとも１つのサービスのデータモデルを識別するためのデータ・フェデレーション方法にも関する。

Description

本発明は、サービス指向アーキテクチャ（ＳＯＡ）においてサービスの公開記述からサービス・データ・モデルを識別して、サービス・データ・モデル間の関係を自動的に決定するための構成に関する。本発明はまた、データ・フェデレーション（連携）方法、発見サービス、対応するコンピュータ・ソフトウェア製品、およびサーバホストにも関する。

現在のサービス技術は主にサービスの機能性に重点を置いている。しかし、利用可能なサービスのかなりの部分は、機能性主導の特徴ではなく、現在の技術をより適切でないものにするデータ主導の特徴を示す。本願は、データ・フェデレーションの一環としてデータ主導のサービスのためのデータ発見に重点を置く。

サービス指向アーキテクチャという状況に関して、サービス、より詳細には、ウェブサービスは、通常、サービスがサポートする機能によって特徴づけられる。サービスの開発および使用は機能性主導である。すなわち、サービスは、それらのサービスの機能性に基づいて、定義され、探索され、それらのサービスの機能性と関係づけられる。

データは、多くの場合、サービス内でも管理されるが、これはサービスの機能的な「ビュー」の一部である。しかし、一部のタイプのサービスの場合、機能性はサービスのデータの管理に酷似する。例えば、典型的なカレンダー・サービスの大部分の動作は、このデータに基づく機能性ではなくデータ管理に関係する。これらのサービスは、機能性主導ではなくデータ主導である。近年、サービスに関するデータ主導の手法は、例えば、この手法を支持する表現可能な状態転送（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ）アプリケーション・プログラマ・インターフェースを提供する多くのオンライン・サービスによって例示されるように、重要性が増している。

サービス指向アーキテクチャにおけるウェブサービス間のフェデレーション（連携）の場合を検討しよう。ウェブサービスは、ＸＭＬ書式化されたインターフェース記述文書（ＷＳＤＬ文書）の形で提供する機能性を公開する、インターネット上でアドレス可能な機能的エンティティである。

２つのウェブサービスが互いに通信することを可能にするために、ウェブサービスは共通プロトコル（一般に、ＳＯＡＰ）、およびメッセージ・コンテンツ（すなわち、インターフェース）の共通理解に関して合意しなければならない。

ＳＯＡ（サービス指向アーキテクチャ）では、サービスは粗結合される。これは、サービスは通常互いから独立して開発され、したがって、合意された共通のインターフェースを有するとは限らないことを意味する。したがって、提供しているウェブサービスが消費しているウェブサービスによって送られたメッセージを理解することを確実にするために、マッピングが実行されなければならない。このマッピングは、通常、ＸＳＬＴ変換の形をとる。

メッセージは特定のサービスが共通に有するデータに影響を与える可能性があるため、本発明は、これらのサービス宛のメッセージが１つまたは複数のその他のサービスにも同様に転送される必要があり得るデータ・フェデレーション・システムに（限定されないが）特に関する。この場合、本発明は、サービス・インフラストラクチャ全体の一部として、ＵＤＤＩまたはｅｂＸＭＬレジストリなどの発見サービスにおいて実施されることが好ましい。

ＳＯＡの典型的な実施形態は、エンタープライズ・サービス・バス（ＥＳＢ）である。ＥＳＢは、メッセージングにおいて、サービスの相互作用を確実に接続および調整するための知的経路指定能力と変換能力とを予測する分散された標準ベースの統合プラットフォームである。上に例示されたように、かかる設定では、機能性に加えて、利用可能なデータに重点を置く必要もある。要約すると、サービス・バス上で利用可能なデータの管理は異なる種類の問題をもたらす。
− データは分散され、多くの場合、バス上で登録されたサービス間で重複する、
− サービスは異なる位置に存在する類似データを操作し、したがって、これらの（意味的に等価な）データ項目の同期が課題である、
− 相互作用しているサービスのデータモデルは互換性がなく、橋絡される必要がある。

ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）は、（ウェブ）サービスをネットワーク上で相互運用可能な機械間相互作用をサポートするように設計されたソフトウェア・システムの一部と定義した。このシステムは、ウェブサービス記述言語（ＷＳＤＬ）などの機械可読形式で記述されたインターフェースを有する。その他のシステムは、簡易オブジェクト・アクセス・プロトコル（ＳＯＡＰ）エンベロープ内に封入され得る、メッセージを使用してそのインターフェースによって規定された方式でウェブサービスと相互作用するか、またはＲＥＳＴな（Ｒｅｓｔｆｕｌ）（表現可能な状態転送（ＲＥＳＴ））手法に従う。これらのメッセージは、通常、ハイパーテキスト・トンランスファー・プロトコル（ＨＴＴＰ）を使用して伝達され、通常、その他のウェブ関連標準と共に拡張可能マークアップ言語（ＸＭＬ）を備える。様々なプログラミング言語で書かれ、様々なプラットフォーム上で実行しているソフトウェア・アプリケーションは、単一のコンピュータ上のプロセス間通信に類似した方式でインターネットなどのコンピュータ・ネットワーク上でデータを交換するために（ウェブ）サービスを使用することが可能である。

ウェブサービス記述言語（ＷＳＤＬ）は、ウェブサービスを記述するために公開されたＸＭＬ形式である。ＷＳＤＬは、ウェブサービスを使用してどのように通信するかに関するＸＭＬベースのサービス記述、すなわち、そのディレクトリ内に列挙されたウェブサービスと相互作用するために要求されるプロトコル結合およびメッセージ形式である。サポートされた動作およびメッセージは抽象的に記述され、次いで、具体的なネットワーク・プロトコルおよびメッセージ形式に結合される。これは、ＷＳＤＬはウェブサービスに対する公衆インターフェースを記述することを意味する。

ＷＳＤＬは、インターネット上でウェブサービスを提供するためにＳＯＡＰおよびＸＭＬスキーマと共に使用される。ウェブサービスに接続しているクランアント・プログラムは、サーバ上で何の機能が利用可能であるかを決定するためにＷＳＤＬを読み取ることが可能である。使用される任意の特別なデータタイプは、ＸＭＬスキーマの形でＷＳＤＬファイル内に埋め込まれる。クライアントは、次いで、ＷＳＤＬ内に列挙された機能のうちの１つを実際に呼び出すためにＳＯＡＬを使用することが可能である。

ＵＤＤＩは、「ユニバーサルな記述、発見と統合」の頭文字であり、世界中の会社がインターネット上で自らを列挙するためのプラットフォーム独立のＸＭＬベースのレジストリである。ＵＤＤＩは、会社がサービス・リストを公開して、互いを発見し、アドレス、連絡先、および知られている識別子、標準の分類学に基づく工業範疇、ならびにサービスに関する技術情報を提供しているサービスまたはソフトウェア・アプリケーションがインターネット上でどのように相互作用するかを定義することを可能する開放型の業界イニシアチブである。

ＵＤＤＩは、ＳＯＡＰメッセージによって問い合わされ、そのディレクトリ内に列挙されたウェブサービスと相互作用するために要求されるプロトコル結合およびメッセージ形式を記述するウェブサービス記述言語文書へのアクセスを提供するように設計される。ｈｔｔｐ：／／ｕｄｄｉ．ｏｒｇ／ｐｕｂｓ／ｕｄｄｉ＿ｖ３．ｈｔｍを参照されたい。

拡張可能スタイルシート言語変換（Ｅｘｔｅｎｓｉｂｌｅ Ｓｔｙｌｅ−ｓｈｅｅｔ Ｌａｎｇｕａｇｅ Ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ）（ＸＳＬＴ）は、ＸＭＬ文書の変換のために使用されるＸＭＬベースの言語である。これはＡＷＫインスパイヤされたＸＭＬ専用フィルタ言語であり、機能的言語である。

ＸＳＬＴは、あるＸＭＬ文書を別のＸＭＬ文書にマップすることを可能にする標準である。ＸＳＬＴは、多くの場合、異なるＸＭＬスキーマ間でデータをコンバートするために、またはＸＭＬデータをコンバートするためにサービス・コンテキスト内で使用される。ＸＳＬＴスクリプトは、通常、ＸＳＬＴスクリプト自体を書き込むことによって、またはかかるＸＳＬＴスクリプトの生成を支援するツールを使用することによって、手動で作成されなければならない。ツールを使用することは、通常、ＸＭＬ文書の図形表現においてフィールド間でリンクを描くことによって達成されるが、それぞれのフィールドをリンクさせる明示的な必要性は面倒なプロセスを助長する。

本発明は、前述のＵＤＤＩまたはＣＯＲＢＡネーミング・サービスなど、典型的な発見サービスの機能性を、意味的なクエリに基づいてサービスに対する参照を戻すこと（すなわち、特定のクライアント・アプリケーションによってそのサービスから要求される機能性）だけでなく、探索されたサービスに関する参照を戻すことに加えて、参照がサービスに引き渡される前に、探索されたサービスにアドレス指定されたメッセージに対して何が実行される必要があるべきかを戻すことまでも拡張する。

メッセージは異なる形式／異なるプロトコル／異なるインターフェース宛であるため、これはクライアントが関心を持つ機能性を提供することが可能な探索されたサービスによってメッセージが理解され得ない場合に大変価値がある。本発明による発見サービスは、メッセージが通過しなければならないサービスの経路を導くためにすら十分な情報を収集し、その経路内のそれぞれのサービスはメッセージに対して必要な適応、すなわち、形式適応（例えば、ＸＳＬＴ変換）、プロトコル変換（例えば、ＳＯＡＰ／ＨＴＴＰからＳＯＡＰ／ＪＭＳに）、インターフェース適応（例えば、ＸＳＬＴ変換）を実行する。

先行技術によれば、典型的なシナリオは、ＵＤＤＩに連絡して、サービスが何を提供すべきであるかの意味的記述を提供し、要求された機能性を提供するサービスのＷＳＤＬ記述を取り出し、ＷＳＤＬ記述に適合するクライアント・アプリケーションを符号化し、ＵＤＤＩからラインタイム基準を発見し、目標サービスを起動することであった。

本発明によれば、方法の意味的記述を伴う、一部のサービスによって理解されるべきメッセージを用いてＵＤＤＩに連絡し、次いで、目標サービスに対する参照に加えて、メッセージを戻されたサービスの実際のインターフェースに適合させるために進むための経路を取り出すことが可能である。次いで、発見された経路を経由して、メッセージを目標サービスに転送することが可能である。

したがって、本発明の寄与は、オフライン・ステップに加えて、先行技術によるオンライン・ステップに関してサービス発見を活用するためのワンステップ手法である。

この改善は、少なくとも１つのサービスのデータモデルを識別するための構成によって達成され、構成は、少なくとも１つのサービスのデータモデルを記憶するための記憶手段と、データモデル間の関係を記憶するための記憶手段とを備える発見サービスを備え、構成は、サービスのデータモデルを収集するための検査手段と、データモデルと少なくとも１つのサービスのデータモデルの間の関係を確立するための検査手段とを備える。

構成は、少なくとも１つのサービスのデータモデルを識別するためのデータ・フェデレーション方法を実現し、データ・フェデレーション方法は、サービスを検査するステップと、サービスのデータモデルを導くステップと、少なくとも１つのサービスの既に知られているデータモデル間の関係を確立するステップと、これらのサービスのデータモデルとデータモデル間の関係とを提供するステップとを備える。

発見は、少なくとも１つのサービスのデータモデルを識別するための発見サービスによって実行されることが好ましく、発見サービスは、少なくとも１つのサービスのデータモデルを記憶するための記憶手段と、データモデル間の関係を記憶するための記憶手段とを備え、構成は、サービスのデータモデルを収集するための検査手段と、データモデルと少なくとも１つのサービスのデータモデルの間の関係を確立するための検査手段とを備える。

さらに本発明は、データ・フェデレーション方法を実行するためのプログラミング手段を備えるコンピュータ・ソフトウェア製品の形で実施される。

すなわち、本発明はサービス・レベルでデータ・フェデレーション手法を可能にする。データ・フェデレーションの主な利点はサービス間のメディエーション（媒介）である。バス上のサービスは第三者によって提供されて、先験的な合意なしに配備される。結果として、サービスは共通のデータモデルに適合する必要がない。このため、データ・フェデレーションはこれらのサービス間のメディエータとして動作し得る。

データを基盤とする合成。サービスの明示的な機能性ベースの合成に加えて、サービスは関連データモデルに基づいて合成されることが可能である。データ・フェデレーションの例示的な使用は、重複するデータモデルを有するサービス間の同期である。

例えば、独立して配備されるアドレス・ブック・サービスおよびインスタント・メッセージング・サービスを考慮されたい。クライアントは、アドレス・ブック内のエンティティのうちの１つのアドレスを変更することを望む場合がある。インスタント・メッセージング・サービスは、やはりアドレス情報を含むＶカードの収集物を記憶する。データ・フェデレーション環境では、アドレス・ブック記入項目のアドレスが変更するところである場合、インスタント・メッセージング・サービス内の対応するＶカードも更新されることが可能になり得る。

構想は、ウェブサービスに関連づけられたＸＭＬ文書を意味的に別の等価なウェブサービスにマップする目的で変換の生成を自動化するためにメタデータを使用することである。

この自動化の際に支援することが可能な様々なタイプのメタデータが存在する。公衆ウェブ・サービス・インターフェースを記述しているＷＳＤＬ文書は、そのインターフェース上でサポートされるすべての方法を列挙する。これらの方法が型づけの強いもの（ｓｔｒｏｎｇｌｙ−ｔｙｐｅｄ）である場合、方法の属性／引数に対応するデータモデルはＷＳＤＬ仕様から自動的に抽出され得る。オプションで、管理者／インテグレータ（ｉｎｔｅｇｒａｔｏｒ）／サービス・プロバイダは、配備記述子など、ウェブサービスの動作をさらに詳述する追加の構成ファイルを提供することが可能である。

ウェブサービスを介して暴露されたデータをオントロジー（存在論）記述に分類することは、異なって指名されたが、意味的に関連するデータフィールドのマッピングを円滑にする、もう１つのタイプのメタデータと見なされ得る。オントロジー記述は、通常、クラスとクラス間の関係とを定義する分類学の形をとる。オブジェクト、属性、方法およびそれらの引数、データモデル・フィールドなどが等価な関係を定義している特定のオントロジー（すなわち、コンテキスト）を指す場合、オブジェクト、属性、方法およびそれらの引数、データモデル・フィールドなどの用語の意味は解明され得る。

最終的に、インターフェースの意味的記述は、例えば、方法が読出し専用動作を実行するかまたは読み書き動作を実行するかを示すために提供され得る。

本発明は図面を用いて詳細に説明される。

本発明による構成を示す図である。 本発明による構成を示す図である。 本発明によるデータ・フェデレーション方法を示す図である。 本発明による発見サービスのハイレベル・アーキテクチャを示す図である。 本発明による発見サービスのハイレベル・アーキテクチャを示す図である。 本発明による発見サービスによって記憶された発見されたサービス・ネットワークを示す図である。 発見されたサービス・ネットワークの情報がどのようにサービス起動を促進し得るかを例示する図である。 発見されたサービス・ネットワークの情報がどのようにサービス起動を促進し得るかを例示する図である。 発見されたサービス・ネットワークの情報がどのようにサービス起動を促進し得るかを例示する図である。 発見されたサービス・ネットワークの情報がどのようにサービス起動を促進し得るかを例示する図である。 本発明に従って、サービスに関する情報がどのようにデータ・フェデレーション方法を用いて統合されるかを示す図である。

基本的なシナリオは図１によって例示される。図において、２つのサービス１１０３および１１０４はサービス・インフラストラクチャ１５００上に既に配備されている。結果として、発見サービス１１０６はその知識ベース１２０６およびメタデータ・リポジトリ１２０７の中にサービス１１０３および１１０４のデータモデルに関する情報を既に有する。ピクチャ１１０３、１１０４、および１１０５内のすべての３つのサービスは、重複するデータモデル１２０２、１２０３、および１２０４を有することも想定される。したがって、変換機能１２００はシステムによって既に推論されており、この変換機能は変換エンジン１１０２上に配備された。

シナリオは、サービス・インフラストラクチャ１５００上に追加のサービス１１０５を引き続き配備する。管理者はサービス・インフラストラクチャ１５００上に新しいサービス１１０５を配備する。

したがって、管理者はサービスのＷＳＤＬインターフェースならびにサービス実装に対応するパッケージを管理ツール１１０７に提供する。管理ツール１１０７は、発見サービス１１０６に要求１４００を送る。発見サービスはＷＳＤＬインターフェースを解析して、この文書からデータモデルを抽出する。

データモデルは、ＷＳＤＬインターフェースに関して定義された方法に対応するデータ構造ならびにＷＳＤＬ文書におけるＸＭＬスキーマとして記述される方法引数データ構造からなる。このデータモデルはメタデータ・リポジトリ１２０７内に記憶される。

発見サービス１１０６は、データ構造のオントロジー定義および／もしくは意味的定義またはこれまでのサービス配備の間（すなわち、配備しているとき）にモデル内に挿入された類似のオントロジー定義および／もしくは意味的定義を含むその知識ベース１２０６を調べ、サービス１１０３または１１０４は、新しいデータモデルとサービス１１０３または１１０４が予め既に発見したものの間の任意の依存および関係を解明しようと試みる。

それらのデータ構造内の新しいデータ構造または特定のフィールドが解明されずに残る場合、すなわち、任意の既存のオントロジーと関係し得ない場合、オペレータは、管理ツール１１０７を介して、当該構造または当該フィールドに関する追加のオントロジー記述を提供するように要求される１４０１。

管理ツールは新しい関連性を用いて応答する１４０２。新しい関連性は発見サービス１１０６によって知識ベース１２０６内に記憶される。

すべてのデータ構造およびフィールドが分類された場合、関係はリーゾナ（ｒｅａｓｏｎｅｒ）１２０５によってデータ構造間で探索される。それは一種のタイプ推論機構である。

かかる関係に関して、システムは、複合データ構造の個々のフィールド間で予め発見された関係に基づいて、マッピング機能を自動的に構築しようと試みる。

自動的に生成されたマッピングが正確であることを確実にするために手動の検証ステップが要求される可能性がある。加えて、ＸＳＬＴスクリプトによって容易に処理され得ない複雑なマッピング・シナリオまたは属性プロバイダなど、外部のシステムから追加の情報が取り出されることを要求する複雑なマッピング・シナリオの場合、手動介入が要求される可能性がある。

関係が自動的に十分に解明され得ない場合、オペレータはマッピングを提供するように再度要求され得る１４０１。このマッピングは発見サービス１１０６の知識ベース１２０６内に記憶される。

関係するマッピング機能は、それに応じて変換されるために、当該マッピング機能がそれを介してメッセージが経路指定されるべきサービス・インフラストラクチャにおいてサービス１２０１として利用可能になるように、変換エンジン１１０２内に配備される１４０３。

個々のデータ構造フィールド間でますます多くの関係が発見されるにつれて、将来のサービス配備はこの情報から利益を得ることが可能になり、その結果、プロセスはますます自動的になる。

図２は、メッセージ２４００がクライアント・アプリケーションまたは別のサービス２１００によってサービスＡ２１０３に送られるランタイム・シナリオを例示する。このメッセージは、サービスＡ２１０３のデータベース２２０２内に記憶されたデータ記録を更新するための要求に対応する。シナリオは、サービスＢ２１０４およびサービスＣ２１０５の両方がメッセージ２４００によって更新されているデータを、それぞれのデータベース２２０３および２２０４内で共有することをさらに想定する。

すべてのサービス２１０３、２１０４および２１０５はサービス・インフラストラクチャ２５００に接続される。これはエンタープライズ・サービス・バスまたは等価メッセージ・ブローカであり得る。サービス・インフラストラクチャは、それによってサービス・インフラストラクチャ２５００上に配備されたサービス２１０３、２１０４、および２１０５宛のすべての要求が傍受されて、経路指定されるコンテンツベースのルータ２１０１を含む。

クライアント２１００からメッセージ２４００を受信するとすぐ、コンテンツベースのルータ２１０１はまず、図において矢印２４０２によって表示されるように、メッセージ２４００をその意図された宛先（サービス２１０３）に経路指定する前に、その他のサービスがメッセージ２４００に関連する更新動作によって影響を受けたかどうかを発見するために発見サービス２１０６を調べる。

この例示的なシナリオでは、発見サービス２１０６は２つの経路を用いて応答する。すなわち、目標サービス２１０４のための第１の変換機能２２００を経由した１つの経路と、目標サービス２１０５のための第２の変換機能２２０１を経由した１つの経路である。それぞれの変換機能は、元のメッセージ２４００を等価メッセージ、すなわち、それぞれ矢印２４０４および２４０６によって表示されるように、それぞれの影響を受けたサービス２４０１および２１０５によって露出されたインターフェースに適合する、影響を受けたサービス２１０４および２１０５のデータベース２２０３および２２０４内の共有データに対して同じ更新を引き起こす効果を有するメッセージに変換する。

発見サービス２１０６から経路を受信しているコンテンツベースのルータ２１０１は、まず、矢印２４０２によって表示されるように、元のメッセージ２４００をその当初意図された目標サービス２１０３に転送する。次いで、コンテンツベースのルータ２１０１は、矢印２４０３によって表示されるように、まずメッセージ２４００を第１の変換機能２２００に送り、次に、矢印２４０４によって表示されるように、結果として生じたメッセージ、すなわち、変換されたメッセージをサービスＢ２１０４に送ることによって第１の経路を処理する。最終的に、コンテンツベースのルータ２１０１は、矢印２４０５によって表示されるように、まずメッセージ２４００を第２の変換機能２２０１に送り、次に、結果として生じたメッセージ、すなわち、変換されたメッセージをサービスＣ２１０５に送ることによって、第２の経路を処理する。

サービス２１０４および２１０５は両方とも、それぞれメッセージ２４０４および２４０６に関連する論理を実行する。すなわち、サービス２１０４および２１０５は、それぞれ、データ記憶２２０３および２２０４を更新する。

本発明が重要であるもう１つの領域は、サービス／構成要素３１００、３１０１、３１０２、および３１０３がインポート３３００、３３０１、および３３０２（すなわち、サービス／構成要素３１００、３１０１、３１０２、および３１０３が別の構成要素が提供することを期待するインターフェース）、ならびにエクスポート３２００、３２０１、３２０２、および３２０３（すなわち、構成要素自体が別の構成要素に提供するインターフェース）の両方を宣言し、特定の機能性を提供している新しい構成要素／サービスを構成するためにインポート３３００、３３０１、および３３０２がエクスポート３２００、３２０１、３２０２、および３２０３にリンク／結合３４００、３４０１、および３４０２されているＳＣＡ適合（サービス構成要素アーキテクチャ）サービス環境（図３を参照されたい）のものである。

（識別性を含めて）少なくとも１つの変換機能３５００、３５０１、および３５０２はリンク／結合３４００、３４０１、および３４０２と関連づけられる。

ＥＳＢ環境という状況に関して、専用フェデレーテッド・データ・マネージャ（Ｆｅｄｅｒａｔｅｄ Ｄａｔａ Ｍａｎａｇｅｒ；ＦＤＭ）は、このデータ・フェデレーション・モデルを実現するために著しく役立つ可能性がある。概念的には、ＦＤＭは発見サービス、取出しサービス、および提供サービスからなると考えられ得る。

発見は、バス上で利用可能なデータの位置を突き止め、このデータを表すモデルを維持することを意味し、取出しまたはクエリは異なるサービスおよびデータモデルについて探索する統合されたクエリをサポートするためであり、提供はバス上で既に利用可能なデータに基づいて新しく登録されたサービスにデータを提供するためである。

ＦＤＭは、類似データを一貫性のある状態に保つことを目的とする同期のために使用されることも可能である。

ＵＤＤＩによって提供される伝統的なサービス発見は、会社がサービス・リストを公開して、その他の会社からのサービスを発見することを可能にする。レジストリ内で利用可能なメタデータは、ザービスに関して記述および探索するのに適している。この伝統的なサービス発見は、多少限定され、主に、会社、プロトコルおよび意味的表示を用いて一層強化された標準分類に関係する。

データ主導のサービスに照らして、この発見機能性は十分ではない。本発明の寄与は、データ主導のサービス発見の要件の解析および高度発見サービスの一般的なモデルの表現である。

ＦＤＭ Ｒｅｇが図４に例示される。発見サービスＤｉｓはＦＤＭの一部と見なされ得る。発見サービスは、サービスを発見して、それらの位置を突き止め、それらのサービスのデータモデルに基づいて、サービスのデータ使用を発見して、それらの位置を突き止める責任を有する。特定のサービスのデータモデルはそのインターフェースに基づかなければならない。発見サービスは、サービスのインターフェース（またはその点に関して任意の追加の仕様）を検査し、この記述からデータモデルを推論すべきである。

データ主導のサービス発見の場合、異なるサービスのデータモデルの統合をサポートするために、データタイプ間の関係を定義することが必要である。新しいサービスが発見サービスに登録されるときはいつでも、発見サービスはデータモデルを更新し、新しい関係を発見して、インスタンスを作成することになる。

拡張として、メタデータは、例えば、映画または書籍などのコンテンツを単に探すのではなく、マルチメディア・コンテンツを処理するサービスの位置を突き止めるために、より意味的なデータ発見をもたらす分類モデルに対するサポート（すなわち、メタ・レベルでの議論）を追加するために、これらのデータタイプおよび関係に関して使用され得る。

ＦＤＭサービス・メディエーションに関して、発見サービスは関連データタイプ間の意味的な差異を知る必要がある。例えば、アドレス・ブック・サービスによって使用されるアドレス情報の形式は、データフィールドが記憶される順序に関して、または１つのタイプにおける個別のデータフィールドとその他のタイプにおける集約されたフィールドの関係として表される情報に関して、インスタント・メッセージング・サービスと異なる可能性がある。

したがって、異なるデータタイプ間の関係に加えて、発見サービスは、好ましくは、これらのデータタイプをどのようにコンバートすなわち変換するかの知識を組み込むべきである。これは、すべてのデータ関係を変換サービス（をどのように活用するかに関する知識）と関連づけることによって達成されることが可能であり、関係が単向性であるか否かに応じて、関係内の１つのデータタイプを別のデータタイプにコンバートすること、またはその逆が可能である。

発見サービスは、結果として生じるデータモデルを介してナビゲートし、これらの変換を使用してそれらのデータモデルを経由して１つのサービスを別のサービスにどのようにマップするかを推論することが可能である。この状況において、用語「経路」はかかるマッピングのためにも使用される。それらの経路の主な使用は、組み込まれたサービス間のデータの自動同期Ｓｙである。

要約すれば、かかるデータベースの発見は３つの主な活動からなる：
− 登録サービスのインターフェースからデータモデルを抽出すること
− 抽出されたデータモデルをレジストリ内に記憶されたデータモデルと関係づけること
− サービスのデータモデルに基づいてサービスを発見するために記憶されたデータモデルに問い合わせること

新しいサービスが発見サービスにおいて登録される場合、サービスのインターフェースが検査されることになり、データモデルが抽出されることになる。インターフェースの性質およびインターフェース上のデータ部分の重要性に応じて、いくつかの状況が可能である。

最も困難な事例であり、かつ、かかるデータ・フェデレーションが適用されていないため、やはり現在最も頻繁に発生する事例は、データ・フェデレーションを認識していないサービスからのデータモデルの抽出である。インターフェース上のデータ部分の重要性は低くなり、発見サービスが抽出することが可能になる情報は多少制限されることになる。

例えば、ＷＳＤＬ記述は、通常、サービスの動作の入力または出力に関して使用されるデータタイプの基本的な記述だけを含む。データ主導のサービスによりふさわしいのは、データタイプおよび異なるデータタイプがどのように読み書きされ（すなわち、公衆アクセス動作を使用して操作され）得るかをより詳細に記述する、個別のデータ・タイプを有するインターフェースである。

Ｊａｖａ（登録商標）Ｂｅａｎｓコンポーネントの属性に関するゲッタ（ｇｅｔｔｅｒ）とセッタ（ｓｅｔｔｅｒ）は、かかるアクセス動作に関するよい例である。最も理想的な事例では、データタイプは、例えば、インライン・ウェブ・オントロジー言語（ＯＷＬ）構文を使用して、または個別のＯＷＬファイルを使用して、タイプをその他の、知られているタイプに関係づけて、またはタイプを一般的なオントロジーもしくは標準オントロジーに統合して、意味的にも記述される。

現在記憶されたデータモデル内にサービスのデータモデルを統合することは、新しいデータタイプと既に存在するデータタイプの間の識別をすること、および新しいデータタイプと予め知られているデータタイプの間の関係の識別をすることになる。

インターフェースから抽出されるにつれて情報が詳細になればなるほど、現在記憶されたデータモデル内への新しいデータタイプのより重要な統合が発生し得る。この場合、重要な要因は明示的なタイプを使用することである。例えば、一部のサービスのすべてのデータが文字列を使用してモデル形成される場合、発見サービスは、その他のサービスのデータモデルとの多くの重要な関係を推論できないことになる。インターフェース内の意味の程度が高ければ高いほど、より自律的な統合が発生し得る。新しいデータタイプがその他のタイプの参照または関係を伴わずに、独立して定義される場合、これらのタイプを完全に自律的に統合することは不可能に近い。この場合、新しいタイプを記憶されたデータモデルに関係づけることは、例えば、発見管理者によって提供される世界的な知識を要求する。

しかし、意味的な情報がインターフェース内に存在する場合、レジストリ内およびインターフェース内に存在する意味的な情報を推理することによって統合が発生し得る。おそらく、この意味的な情報は標準オントロジーまたは一般的なオントロジーに対する参照の形で提供されることになる。この場合、発見サービスはこのオントロジーから正確な関係を直接的に抽出することが可能である。

発見サービスが関連サービスのデータモデルを介して関連サービスについて探索することを可能にするために、データモデルのレベルにおいてどの関係がサービス・レベルにおける関係をもたらし得るかを定義するためのいくつかの規則が必要である。

例えば、特定の動作の意味的に関連する動作のセットＳを動作間の関係Ｒの（推移）閉包として定義することが可能である。ＸおよびＹの入力が重複する場合、動作Ｘは動作Ｙに関係づけられる。これは、入力タイプは入力のサブタイプまたは一部であることを意味し得る。

より実用的な手法は、１つのデータタイプから別のデータタイプへの変換が存在することを単に意味する関係ｉｓＴｒａｎｓｆｏｒｍａｂｌｅＴｏからなり得る。関係のそれぞれ、すなわち、ｉｓＴｒａｎｓｆｏｒｍａｂｌｅＴｏのサブタイプ、ｉｓＴｒａｎｓｆｏｒｍａｂｌｅＴｏの部分、およびｉｓＴｒａｎｓｆｏｒｍａｂｌｅＴｏに関して、変換サービスとの関連が存在する。

関連動作の上の定義は、次いで、１つのデータタイプから進む一続きの変換または別のデータタイプもしくは別の動作に対する一続きの動作を特定する。この一続きの動作は、実際に、データ・フェデレーション・マネージャ内のサービス間の自動同期のために使用される経路である。

例えば、アドレス・ブックおよびインスタント・メッセンジャーの場合、「アドレス更新」をアドレス・データタイプにマップする変換を経由した「アドレス更新」動作から「Ｖカード更新」動作へ、アドレス・データタイプからＶカード・データタイプにおいて使用されるアドレス・タイプへ、そこからＶカードを経由した「Ｖカード更新」への経路が存在し得る。

具体的な実装形態の場合、データ記述とデータ発見技術の両方が必要である。例えば、さらなる統合の何らの必要なしに、ＷＳＤＬおよびＯＷＬの両方を使用することが可能である。すなわち、ＯＷＬはそれ自体ＷＳＤＬ仕様内で使用されることが可能であり、または個別の仕様ファイルとして使用されることも可能である。データ発見技術に関して、ｅｂＸＭＬはより表現的なデータモデルおよびクエリ・アプリケーション・プログラマ・インターフェースを提供するため、例えば、ＵＤＤＩに優先してｘｂＸＭＬを選択することが可能である。

ｅｂＸＭＬは、その発見は一部である、電子事業提携に関する仕様のセットとして使用され得る。ｅｂＸＭＬによって使用されるレジストリは、レジストリおよびリポジトリの両方からなる。リポジトリは、任意のタイプの電子コンテンツを記憶することが可能であり、一方、レジストリはそのコンテンツを記述するメタデータを記憶することが可能である。リポジトリ内のコンテンツは「リポジトリ項目」と呼ばれ、一方、レジストリ内のメタデータは「レジストリ・オブジェクト」と呼ばれる。

ｅｂＸＭＬレジストリは、レジストリに提出され得る標準メタデータを特定するレジストリ情報モデル（ＲＩＭ）を定義する。情報モデルの主な特徴は以下を含む。
・レジストリ・オブジェクト。ｅｂＲＩＭ内の最上位クラスはレジストリ・オブジェクトである。これはモデル内の大部分のクラスによって使用される抽象的な基本クラスである。これはレジストリ・オブジェクトに最小限のメタデータを提供する。
・分類。任意のレジストリ・オブジェクトは、個々のクラス階層要素を表す分類方式および分類ノードを使用して分類され得る。分類方式は、分類ノードで構成される木構造を定義する。分類方式はユーザ定義されることが可能である。
・関連性。任意のレジストリ・オブジェクトは、関連性インスタンスを使用して任意のその他のレジストリ・オブジェクトと関連づけられることが可能であり、１つのオブジェクトはソース・オブジェクトであり、その他のオブジェクトは関連性インスタンスの目標オブジェクトである。関連性インスタンスは関連性の性質を定義する関連性タイプを有する場合がある。レジストリがｅｂＭＸＬ準拠されるようにサポートしなければならないいくつかの所定の関連タイプが存在する。ｅｂＸＭＬはこのリストが拡張されることを可能にする。
・サービス記述クラス、サービス結合クラスおよび仕様リンク・クラスは、ＷＳＤＬを含めてサービス記述を定義するための能力を提供する。ｅｂＸＭＬはレジストリを使用するために２つのインターフェースをエクスポートする。
・ライフサイクル・マネージャ（ＬＣＭ）は、すべてのオブジェクト・ライフサイクル管理要求に対する責任を有する。
・クエリ・マネージャ（ＱＭ）は、すべてのクエリ要求を処理する責任を有する。クライアントは、レジストリに問い合わせて、オブジェクトを発見するために、このサービスによって定義された動作を使用する。

ｅｂＸＭＬクエリ・サービスはデータモデルを十分に活用する。すべての情報はレジストリ内の項目（例えば、ある分類ノードを用いて分類されたある項目またはすべてのサービス項目に関連するすべてのレジストリ・オブジェクト）を探索するために使用され得る。意味的な関係を用いてｅｂＸＭＬレジストリ内のデータ分類モデルを拡張するために、ｅｂＸＭＬにおいて利用可能な構文が使用され得る。ｅｂＸＭＬレジストリ情報モデルは、データクラスのＯＷＬ記述をシミュレートするために使用され得る。

バックボーン構成要素としてｅｂＸＭＬを使用する、データ発見サービス・プロトタイプのためのアーキテクチャが定義されている。

図５はアーキテクチャのハイレベルの構成要素ビューを示す。このアーキテクチャは、３つの構成要素Ｄ、ＱＦ、およびＥＢからなる。発見構成要素Ｄは、その他のＦＤＭサービスによって使用される３つのインターフェースＬＣ、Ｑ、およびＡを提供する。ライフサイクル・インターフェースＬＣは、登録されたサービスのライフサイクル管理のために使用される。ライフサイクル・インターフェースＬＣは、新しいサービスに加入し、新しいサービスを公開し、新しいサービスを活性化するためにシステム管理者によって使用され得る。構成要素は記述に基づいてサービス情報をレジストリ内に記憶することになり、サービスに対するデータモデルおよびレジストリ内のその他のデータタイプとの関係を提案することになる。インターフェースはまた、提案されたデータ関係を解明および記憶するための動作も含む。管理インターフェースＡはレジストリ上の保守動作のために使用される。

システム管理者は、管理インターフェースＡを特にデータモデルとデータモデル間の関係とに関する保守のために使用することになる。クエリ・インターフェースＱはレジストリ内に記憶された情報を探索するために使用される。クエリ・インターフェースＱは、主に関連サービスに対する経路を見つけるために同期サービスによって使用される１つの特定の動作と、ｅｂＸＭＬ標準において定義されるクエリなどの構造化クエリ言語（ＳＱＬ）に関する１つの一般的な動作とを提供する。ｅｂＸＭＬ構成要素ＥＢは、ｅｂＸＭＬ標準に十分に準拠するレジストリおよび発見サービスである。ｅｂＸＭＬ構成要素ＥＢは、発見構成要素Ｄおよび第三者クライアントの両方によって使用されることになる。発見構成要素Ｄは、利用可能なサービスのデータモデル間の関係と関連する変換とを含めて、利用可能なサービスのデータモデルと共に利用可能なサービスを記憶するレジストリとしてｅｂＸＭＬ構成要素ＥＢを使用することになり、一方、第三者クライアントは、伝統的な発見サービスとしてｅｂＸＭＬ構成要素ＥＢを使用することが可能である。クエリ・ファサード（ＱｕｅｒｙＦａｃａｄｅ）構成要素ＱＦは、例えば、推移関係を介して探索するために再帰的クエリを処理することが可能である。ｅｂＸＭＬ標準仕様はこの機能性を含まないため、この構成要素は必要である。

発見構成要素のインターフェースＱ、Ａ、およびＬＣは、入力および出力として主にＷＳＤＬ形式ならびにＯＷＬ形式を使用するが、内部で、発見レジストリはｅｂＸＭＬ形式に基づく。データモデルの抽出は、したがって、ＷＳＤＬおよびＯＷＬをｅｂＲＩＭ公開形式ならびにｅｂＲＳ公開形式に変換することになる。

サービスはサービスクラスを用いて表現されることが可能であり、ＷＳＤＬからの情報の残りの部分はサービス結合クラスおよび仕様リンク・クラスの形で提供される。サービスによって使用されるデータモデルは、それぞれの分類ノードがデータモデル内の１つのタイプを表し、かつ分類を使用してサービスに関連づけられる分類方式にマップされる。

例えば、前述のアドレス・ブック・サービスはｅｂＸＭＬレジストリ内に記憶されることが可能である。サービスは２つのデータタイプを用いて分類される。１つはアドレス情報を変更するためであり、もう１つはアドレス・ブックに新しい記入事項を追加するためである。これらのタイプをアドレス・タイプ、人物タイプ、および文字列から構成させる。

新しいサービスがレジストリ内で公開されると、新しいデータモデル要素がレジストリ内に挿入されなければならず、サービスのデータモデルは既にレジストリ内に記憶されているデータタイプと関連づけられるべきである。発見サービスは、後者を十分自律的に達成することができない可能性がある。その場合、発見サービスは、提案されたデータタイプ関係のセットは、例えば、システム管理者によって完成されると推論することが可能である。

関連性に関するいくつかの簡易化は、データタイプ間の十分な等価に基づき得る。例えば、タイプがレジストリ内で既に利用可能である場合、そのサービス特定の関係も同様にレジストリ内に追加されなければならない。この推論を信頼できる完全なものにするために、システム管理者は、ＯＷＬ構文をＷＳＤＬ発行物に埋め込むことによって意味的なデータ情報を用いてサービス記述を拡張することが可能である。

異なるサービスの動作間の経路に関するモデルの中を探索するために、フロイド・ワーシャル法（Ｆｌｏｙｄ−Ｗａｒｓｈａｌ）のようなアルゴリズム、または１対の最短経路発見（すなわち、ダイクストラ（Ｄｉｊｋｓｔｒａ）探索タイプからのアルゴリズム）を使用することが可能である。

図６は、サービス・ネットワークのより抽象的な表現を示す。前述のように、サービスは、矢印Ｔによって示されるように、機能に対応する。サービスは矢印Ｔの範疇を形成し、サービスＴは入力データタイプおよび出力データタイプＤを有する。これらのタイプはサービスを定義し、逆も同様である。２つのサービスの連結のために、タイプは適合しなければならない。すなわち、タイプは少なくとも、意味的なレベルでタイプのメタ情報から導かれ得るコンバージョン機能を用いて一致しなければならない。黒丸をより注意深く考察することは、タイプが、前述のデータモデルとして、概略された実現において実施されたデータ表現の等価クラスを形成することを意味することになる。

図７は具体的なシナリオ、すなわち、適切な（すなわち互換性のある）インターフェースを用いたサービスの連続的な実施を示す。破線矢印で示される、結果として生じる（連結された）サービスの入力タイプＳと出力タイプＥが存在する。この（仮想）サービスは３つの実サービスから構成される。

サービスは矢印の範疇において連結され得る。一続きの連結された実施は、出発点Ｓおよび終点Ｅを有するグラフ（太線）内のパスに対応する。制約は、データタイプは一貫する必要があることである。すなわち、Ｎ番目の矢印はＮ＋１番目の矢印が始まる黒丸で終わる。パスは入力タイプＳおよび（破線の）出力タイプＥを有する（仮想）サービスに対応する。

本発明による発見サービスは、図６に示されるサービス・ネットワークを認識している。発見サービスＸは、図８に示されるように、サービス・ネットワークのマップを記憶する。クライアントＣは、例えば、入力データタイプＳおよび出力データタイプＥによって定義されたサービスが存在するかどうか問い合わせるＳ？Ｅことができる。クエリはクライアントＣと発見サービスＸの間の接続によって例示される。

図９は、経路がサービス・ネットワークを介してどのように発見されるかを例示する。発見サービスＸは、そのマップ内の入力タイプＳおよび出力タイプＥを識別しなければならず、サービスはマップ内の対応する点（すなわち、等価クラス）、すなわち、データモデルのデータタイプ間の接続を識別しなければならない。これはサービスＴ１、Ｔ２、およびＴ３のパス、または通常、パスのセットである。この情報、すなわち（オプションで、タイプ・コンバージョンのためのデータ変換を含む）経路指定情報はクライアントＣに応答される。

これは、図１０に示されるように、クライアントがパスによって定義されたサービス・チェーンを起動することを可能にする。入力を用いて、第１のサービスＴ１が起動されＩＴ１、この起動の結果を用いて、第２のサービスＴ２が起動されＩＴ２、最後に、第３のサービスＴ３が起動されて、提供された出力タイプＥの結果を明らかにする。

要約すると、入力データタイプＳおよび出力データタイプＥを用いてサービスを探索するクライアントＣは、専用サービスＸに探索されたサービスを提供する一続きのサービス起動を要求することが可能である。専用サービスＸは、そのクライアントのメモリ内のデータタイプを調べることが可能であり、例えば、ダイクストラのアルゴリズムを介してまたはフロイド・ワーシャル法アルゴリズムを介した推移閉包によってパスを計算することが可能である。これはクライアントが連結された方法でサービスを起動することを可能にする。

図１１は、発見サービス内に記憶されたマップがどのように（増分的に）作成され得るかを例示する。図６に示された既に発見されたサービス・ネットワークから開始して、新しいサービスＳが登録されなければならないと想定する。これは破線矢印で示される。サービスは入力データタイプＤＳおよび出力データタイプＤＥを有する。ルックアップは、入力データタイプＤＳがまったく新しいこと、すなわち、知られていないことを明らかにするが、意味的記述から知られているデータタイプと新しいデータタイプの間の変換が導かれ得る。これはマップ内に新しい黒丸と新しい矢印とを作成することによって記憶される。出力データタイプＤＥは、例において既に知られているデータタイプとして識別され得る。これは破線の輪によって示される。マップはデータタイプＤＳおよびＤＥを直接的に接続している矢印の統合によって完成される。最終的に、前述の発見サービスは、サービス、データタイプ、およびデータタイプ変換の一貫した整数ピクチャ（モデル）を有する。

Claims (8)

1. 少なくとも１つのサービス（２１０３、２１０４、２１０５）のデータモデルを識別するための構成であって、発見サービス（２１０６）を備え、前記発見サービス（２１０６）が、
   前記少なくとも１つのサービスのデータモデルを記憶するための記憶手段と、
   前記データモデル間の関係を記憶するための記憶装置とを備え、
   前記構成が、
   サービスのデータモデルを収集するための検査手段と、
   前記データモデルと前記少なくとも１つのサービスのデータモデルの間の関係を確立するための検査手段とを備えることを特徴とする構成。
2. 前記発見手段がデータタイプの変換を関係に関連づけるように適合されることを特徴とする、請求項１に記載の構成。
3. 前記発見手段が、予め確立された関係およびサービスの意味的記述に基づいてサービス・データ・モデル間の新しい関係の自動的な推論をサポートするように適合されたリーゾナ（２２０５）を備えることを特徴とする、請求項１に記載の構成。
4. 前記少なくとも１つのサービスの前記データモデルおよび前記データモデル間の前記関係に基づいて冗長的なデータを自動的に識別するための同期手段を備えることを特徴とする、請求項１に記載の構成。
5. 少なくとも１つのサービスのデータモデルを識別するためのデータ・フェデレーション方法であって、
   サービスを検査して、前記サービスのデータモデルを導くステップと、
   前記少なくとも１つのサービスの既に知られているデータモデル間の関係を確立するステップと、
   前記サービスの前記データモデルおよび前記データモデル間の前記関係を提供するステップとを備えることを特徴とする、データ・フェデレーション方法。
6. 少なくとも１つのサービス（２１０３、２１０４、２１０５）のデータモデルを識別するための発見サービスであって、
   前記少なくとも１つのサービスのデータモデルを記憶するための記憶手段と、
   前記データモデル間の関係を記憶するための記憶手段と、
   サービスのデータモデルを収集するための検査手段と、
   前記データモデルと前記少なくとも１つのサービスのデータモデルの間の関係を確立するための検査手段とを備えることを特徴とする発見サービス（２１０６）。
7. 請求項５に記載の前記データ・フェデレーション方法を実行するためのプログラミング手段を備えることを特徴とするコンピュータ・ソフトウェア製品。
8. 請求項６に記載の前記発見サービスを実行するための実行手段を備えることを特徴とするサーバホスト。

Images