(57)【要約】本発明は、要求されたサービスを呼び出す構成であって、ディスカバリ・サービス（２１０６）を含み、ディスカバリ・サービス（２１０６）が、少なくとも１つのサービスのデータ・モデルを格納するストレージ手段と、サービス（２１０３、２１０４、２１０５）を取り出す取り出し手段とを含み、ストレージ手段が、サービスの間の関係を格納するように適合され、前記データ・モデル内の複数のサービスのパスを取り出す事前取り出し手段を含み、サービスの連結が、要求されたサービスに対応する、構成に関する。本発明は、要求されたサービスを呼び出す方法であって、前記データ・モデル内の複数のサービスのパスを事前に取り出すステップであって、サービスの連結が、パス上のサービスを連続して呼び出すために、要求されたサービスに対応するステップを含む方法にも関する。
2010503088.tif 000002
【特許請求の範囲】
【請求項１】
要求されたサービスを呼び出す構成であって、ディスカバリ・サービス（２１０６）を含み、前記ディスカバリ・サービス（２１０６）が、少なくとも１つのサービスのデータ・モデルを格納するストレージ手段と、サービス（２１０３、２１０４、２１０５）を取り出す取り出し手段とを含む構成において、前記ストレージ手段が、サービスの間の関係を格納するように適合され、前記データ・モデル内の複数のサービスのパスを取り出す事前取り出し手段を含み、前記サービスの連結が前記要求されたサービスに対応することを特徴とする構成。
【請求項２】
前記ディスカバリ手段が、データタイプの変換を関係に関連付けるように適合されることを特徴とする、請求項１に記載の構成。
【請求項３】
前記ディスカバリ手段が、前記サービスの以前に確立された関係およびセマンティック記述に基づくサービス・データ・モデルの間の新しい関係の自動演繹をサポートするように適合されたリーズナ（２２０５）を含むことを特徴とする、請求項１に記載の構成。
【請求項４】
前記少なくとも１つのサービスの前記データ・モデルおよび前記データ・モデルの間の前記関係に基づいて冗長データを自動的に識別する同期手段を含むことを特徴とする、請求項１に記載の構成。
【請求項５】
要求されたサービスを呼び出す方法であって、
少なくとも１つのサービスのデータ・モデルを発見することによって前記要求されたサービスに対応するサービスを取り出し、前記取り出されたサービスを呼び出すステップ
を含む方法において、
前記データ・モデル内の複数のサービスのパスを事前に取り出すステップであって、前記サービスの連結が前記要求されたサービスに対応するステップと、
前記パス上の前記サービスを連続して呼び出すステップと
を含むことを特徴とする方法。
【請求項６】
前記連結内のインターフェースを整列させる変換方法を取り出すステップを含むことを特徴とする、請求項５に記載の方法。
【請求項７】
要求されたサービスを呼び出すディスカバリ・サービス（２１０６）であって、少なくとも１つのサービスのデータ・モデルを格納するストレージ手段と、サービス（２１０３、２１０４、２１０５）を取り出す取り出し手段とを含むディスカバリ・サービスにおいて、前記ストレージ手段が、サービスの間の関係を格納するように適合され、前記データ・モデル内の複数のサービスのパスを取り出す事前取り出し手段を含み、前記サービスの連結が前記要求されたサービスに対応することを特徴とするディスカバリ・サービス。
【請求項８】
請求項５に記載の方法を実行するプログラミング手段を含むことを特徴とするコンピュータ・ソフトウェア製品。
【請求項９】
請求項６に記載のディスカバリ・サービスを実行する実行手段を含むことを特徴とするサーバ・ホスト。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス指向アーキテクチャ（ＳＯＡ）で要求されたサービスを呼び出す構成に関する。本発明は、要求されたサービスを呼び出す方法、ディスカバリ・サービス、対応するコンピュータ・ソフトウェア製品、およびサーバ・ホストにも関する。
【先行技術文献】
【非特許文献】
【０００２】
【非特許文献１】ｈｔｔｐ：／／ｕｄｄｉ．ｏｒｇ／ｐｕｂｓ／ｕｄｄｉ  ｖ３．ｈｔｍ
【０００３】
現在のサービス・テクノロジは、主に、サービスの機能性に焦点を合わせている。しかし、使用可能なサービスのかなりの部分は、機能駆動ではなくデータ駆動の特性を示し、これが、現在のテクノロジをより不適切にする。本願は、特にデータ駆動サービスのディスカバリに焦点を合わせたものである。
【０００４】
サービス指向アーキテクチャ、またはより具体的にウェブ・サービスの文脈でのサービスは、通常、それらがサポートする機能によって特徴を表される。サービスの展開および使用は、機能駆動であり、サービスは、その機能性に基づいて定義され、機能性について検索され、機能性に接続される。
【０００５】
データは、しばしば、サービス内で管理されるが、これは、サービスの機能的「ビュー」の一部である。しかし、いくつかのタイプのサービスについて、機能性は、サービスのデータの管理に非常に似ている。たとえば、通常のカレンダ・サービスのほとんどの動作は、このデータに基づく機能性ではなくデータ管理に関する。これらのサービスは、機能性駆動ではなくデータ駆動である。最近、たとえばデータ駆動手法を好むｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  ｓｔａｔｅ  ｔｒａｎｓｆｅｒアプリケーション・プログラマ・インターフェースを提供する多数のオンライン・サービスによって示されるように、サービスに関するデータ駆動手法が重要性を獲得しつつある。
【０００６】
サービス指向アーキテクチャ内のウェブ・サービスの間のフェデレーション（連携）の場合を検討されたい。ウェブ・サービスは、インターネット上でアドレス可能な機能的実体であり、それが提供する機能性をＸＭＬフォーマットのインターフェース記述文書すなわちＷＳＤＬ文書でパブリッシュする。
【０００７】
２つのウェブ・サービスが互いに通信できるためには、それらが、共通のプロトコル、通常はＳＯＡＰと、メッセージ内容の共通の理解すなわちインターフェースとに関して合意しなければならない。
【０００８】
ＳＯＡ（サービス指向アーキテクチャ）では、サービスは疎結合され、これは、サービスが、通常は互いに独立に開発され、したがって、必ずしも合意された共通のインターフェースを有さないことを意味する。したがって、提供するウェブ・サービスが消費するウェブ・サービスによって送られるメッセージを理解することを確かにするために、マッピングを実行しなければならない。このマッピングは、通常、ＸＳＬＴ変換の形をとる。
【発明の概要】
【０００９】
本発明は、データ・フェデレーション・システムに特に重要である（しかし、これに限定はされない）が、データ・フェデレーション・システムでは、特定のサービス宛のメッセージが、１つまたは複数の他のサービスにも転送される必要がある場合がある。というのは、そのメッセージが、これらのサービスが共通して有するデータに影響する可能性があるからである。この場合に、本発明は、好ましくは、全体的なサービス・インフラストラクチャの一部として、ＵＤＤＩレジストリまたはｅｂＸＭＬレジストリなどのディスカバリ・サービスで実施される。
【００１０】
ＳＯＡの通常の実施形態は、エンタープライズ・サービス・バス（ＥＳＢ）である。ＥＳＢは、サービスの相互作用を信頼できる形で接続し、調整するために、メッセージング機能、インテリジェント・ルーティング機能、および変換機能で先を見こす、分散式で標準ベースの統合プラットフォームである。上で例示したように、そのようなセッティングでは、機能性の他に、使用可能なデータに焦点を合わせる必要もある。要約すると、サービス・バスで使用可能なデータの管理は、次の異なる種類の問題をもたらす。
−データが、バスに登録されたサービスの間で分散され、しばしば複製され、
−サービスが、異なる位置に常駐する類似するデータを操作し、したがって、これらの（セマンティック的に同等の）データ・アイテムの同期化が問題であり、
−相互作用するサービスのデータ・モデルが、互換ではなく、ブリッジングされる必要がある。
【００１１】
ワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）は、（ウェブ）サービスを、ネットワークを介するインターオペラブルな機械対機械相互作用をサポートするように設計されたソフトウェア・システムの一部と定義した。この（ウェブ）サービスは、ｗｅｂ  ｓｅｒｖｉｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ｌａｎｇｕａｇｅ（ＷＳＤＬ）などの機械可読フォーマットで記述されるインターフェースを有する。他のシステムは、メッセージを使用して、そのインターフェースによって規定される形でウェブ・サービスと相互作用し、このメッセージは、ｓｉｍｐｌｅ  ｏｂｊｅｃｔ  ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）エンベロープに封入されるか、Ｒｅｓｔｆｕｌ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴ））手法に従うものとすることができる。これらのメッセージは、通常、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用して伝えられ、通常は、他のウェブ関連標準規格と共にＥｘｔｅｎｓｉｂｌｅ  Ｍａｒｋ−ｕｐ  Ｌａｎｇｕａｇｅ（ＸＭＬ）を含む。さまざまプログラミング言語で記述され、さまざまなプラットフォームで走行するソフトウェア・アプリケーションが、（ウェブ）サービスを使用して、インターネットなどのコンピュータ・ネットワーク上で、単一のコンピュータ上でのプロセス間通信に似た形でデータを交換することができる。
【００１２】
Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＷＳＤＬ）は、ウェブ・サービスを記述するためにパブリッシュされるＸＭＬフォーマットである。ＷＳＤＬは、ウェブ・サービスを使用してどのように通信するか、すなわち、そのディレクトリにリストされたウェブ・サービスと相互作用するのに必要なプロトコル・バインディングおよびメッセージ・フォーマットに関するＸＭＬベースのサービス記述である。サポートされる動作およびメッセージは、抽象的に記述され、その後、具体的なネットワーク・プロトコルおよびメッセージ・フォーマットにバインドされる。これは、ＷＳＤＬが、ウェブ・サービスへのパブリック・インターフェースを記述することを意味する。
【００１３】
ＷＳＤＬは、インターネット上でウェブ・サービスを提供するのに、ＳＯＡＰおよびＸＭＬスキーマと組み合わせて使用される。ウェブ・サービスに接続するクライアント・プログラムは、ＷＳＤＬを読み取って、どの機能がサーバで使用可能であるかを判定することができる。使用されるすべての特殊なデータ型は、ＸＭＬスキーマの形でＷＳＤＬファイルに埋め込まれる。次に、クライアントは、ＳＯＡＰを使用して、ＷＳＤＬにリストされた機能のうちの１つを実際に呼び出すことができる。
【００１４】
ＵＤＤＩは、Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ，ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎの頭字語であり、全世界の会社がインターネット上でそれら自体をリストするためのプラットフォーム独立のＸＭＬベースのレジストリである。ＵＤＤＩは、会社がサービス・リスティングをパブリッシュし、お互いを発見することを可能にするオープン産業イニシアティブであり、アドレス、連絡先、および既知の識別子、標準分類学に基づく産業分類、ならびにサービスに関する技術的情報を提供するサービスまたはソフトウェア・アプリケーションが、インターネット上でどのように相互作用するかを定義する。
【００１５】
ＵＤＤＩは、ＳＯＡＰメッセージによって問い合わされ、そのディレクトリにリストされたウェブ・サービスと相互作用するのに必要なプロトコル・バインディングおよびメッセージ・フォーマットを記述するＷｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ文書へのアクセスを提供する。ｈｔｔｐ：／／ｕｄｄｉ．ｏｒｇ／ｐｕｂｓ／ｕｄｄｉ  ｖ３．ｈｔｍを参照されたい。
【００１６】
Ｅｘｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅ−ｓｈｅｅｔ  Ｌａｎｇｕａｇｅ  Ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ（ＸＳＬＴ）は、ＸＭＬ文書の変換に使用されるＸＭＬベースの言語である。これは、ＡＷＫによってもたらされたＸＭＬ専用のフィルタ言語であり、関数型言語である。
【００１７】
ＸＳＬＴは、あるＸＭＬ文書を別のＸＭＬ文書にマッピングすることを可能にする標準規格である。ＸＳＬＴは、しばしば、サービス・コンテキスト内で、異なるＸＭＬスキーマの間でデータを変換するかＸＭＬデータを変換するのに使用される。ＸＳＬＴスクリプトは、通常、ＸＳＬＴスクリプト自体を記述することまたはそのようなＸＳＬＴスクリプトの生成を支援するツールを使用することのいずれかによって、手作業で構成されなければならない。後者は、通常、ＸＭＬ文書のグラフィカル表現内のフィールドの間にリンクを描くことによって達成されるが、各フィールドをリンクする明示的な必要は、面倒なプロセスに向かう。
【００１８】
本発明は、上で述べたＵＤＤＩまたはＣＯＲＢＡネーミング・サービスなどの通常のディスカバリ・サービスの機能性を、セマンティック照会すなわち特定のクライアント・アプリケーションがそのサービスに要求する機能性に基づくサービスへの参照を返すだけではなく、さらに、検索されるサービスに対する参照を返し、検索されたサービスにメッセージを配送する前に、そのサービス宛のそのメッセージに対して行う必要があることをも返すように拡張する。
【００１９】
これは、クライアントが関心を持っている機能性を提供できる検索されたサービスが、メッセージが異なるフォーマット／異なるプロトコルである／異なるインターフェース宛であるのでメッセージを理解できない時に高い価値を有する。本発明によるディスカバリ・サービスは、メッセージが通過しなければならないサービスのルートの導出にさえ十分な情報を収集し、そのルート内の各サービスは、メッセージに対する必要な適合すなわちフォーマット適合、たとえばＸＳＬＴ変換、プロトコル変換、たとえばＳＯＡＰ／ＨＴＴＰからＳＯＡＰ／ＪＭＳへ、インターフェース適合、たとえばＸＳＬＴ変換を実行する。
【００２０】
従来技術によれば、通常のシナリオは、次のようなものであった。サービスが提供しなければならないもののセマンティック記述を提供するＵＤＤＩに連絡し、要求された機能性を提供するサービスのＷＳＤＬ記述を取り出し、ＷＳＤＬ記述に従ってクライアント・アプリケーションをコーディングする。ＵＤＤＩからランタイム参照を発見し、ターゲット・サービスを呼び出す。
【００２１】
本発明によれば、メソッドのセマンティック記述が付随する、一部のサービスによって理解されなければならないメッセージを用いてＵＤＤＩに連絡し、その後、返されたサービスの実際のインターフェースにメッセージを適合させるためにターゲット・サービスへの参照と従うべきパスとを取り出すことが可能である。次に、発見されたパスを介してメッセージをターゲット・サービスに転送することが可能である。
【００２２】
したがって、本発明の貢献は、従来技術によるオンライン・ステップに加えてオフライン・ステップに関してサービス・ディスカバリを利用する１ステップ手法である。
【００２３】
この改善は、要求されたサービスを呼び出す構成によって達成され、この構成は、ディスカバリ・サービスを含む。ディスカバリ・サービスは、少なくとも１つのサービスのデータ・モデルを格納するストレージ手段と、サービス（２１０３、２１０４、２１０５）を取り出す取り出し手段とを含み、ストレージ手段は、サービスの間の関係を格納するように適合される。ディスカバリ・サービスは、前記データ・モデル内の複数のサービスのパスを取り出す事前取り出し手段を含み、サービスの連結は、要求されたサービスに対応する。
【００２４】
ディスカバリ、すなわち要求されたサービスを呼び出す方法は、少なくとも１つのサービスのデータ・モデルを発見することによって、要求されたサービスに対応するサービスを取り出し、その取り出されたサービスを呼び出すステップによって実行され、事前の取り出しは、前記データ・モデル内の複数のサービスのパスを含み、サービスの連結は、要求されたサービスに対応する。最後に、パス上の取り出されたサービスが、連続して呼び出される。
【００２５】
また、本発明は、上記の方法を実行するプログラミング手段を含むコンピュータ・ソフトウェア製品に実装される。
【００２６】
言い換えると、本発明は、サービス・レベルでのデータ・フェデレーション手法を可能にする。データ・フェデレーションの主な利益は、サービスの間の調停であり、バス上のサービスは、第三者によって提供され、先験的合意なしに展開される。その結果、サービスは、共通のデータ・モデルに従う必要がない。このゆえに、データ・フェデレーションは、これらのサービスの間のメディエータとして働くことができる。
【００２７】
データに基づくコンポジション。サービスの明示的な機能性ベースのコンポジションの他に、サービスを、関係付けられたデータ・モデルに基づいてコンポーズすることができる。データ・フェデレーションの例の使用は、オーバーラップするデータ・モデルを有するサービスの間の同期化である。
【００２８】
たとえば、独立に展開される、アドレス帳およびインスタント・メッセージング・サービスを検討されたい。クライアントは、アドレス帳のエントリのうちの１つのアドレスを変更することを望む可能性がある。インスタント・メッセージング・サービスは、やはりアドレス情報を含むＶｃａｒｄのコレクションを格納する。データ・フェデレーション環境では、アドレス帳エントリのアドレスが変更されようとしている時に、インスタント・メッセージング・サービス内の対応するＶｃａｒｄも更新されることを可能にすることができる。
【００２９】
この発想は、ウェブ・サービスに関連するＸＭＬ文書を別のセマンティック的に同等のウェブ・サービスにマッピングするために変換の生成を自動化するのにメタデータを使用することである。
【００３０】
この自動化を助けることができるさまざまなタイプのメタデータがある。パブリック・ウェブ・サービス・インターフェースを記述するＷＳＤＬ文書は、そのインターフェースでサポートされるすべてのメソッドをリストする。これらのメソッドが強く型付けされる時に、メソッド属性／引数に対応するデータ・モデルを、ＷＳＤＬ仕様から自動的に抽出することができる。任意選択で、管理者／インテグレータ／サービス・プロバイダは、デプロイメント記述子などの追加の構成ファイルを提供して、ウェブ・サービスの挙動をさらに詳細に示すことができる。
【００３１】
ウェブ・サービスを介してオントロジ記述に公開されるデータの分類は、異なって命名されるがセマンティック的に関連するデータ・フィールドのマッピングを容易にするもう１つのタイプのメタデータと考えることができる。オントロジ記述は、通常、クラスおよびその間の関係を定義する分類の形をとる。オブジェクト、属性、メソッドおよびその引数、データ・モデル・フィールドなどの諸項の意味は、それらが同等性関係を定義している特定のオントロジすなわちコンテキストをポイントする場合に、解決することができる。
【００３２】
最後に、インターフェースのセマンティック記述を提供して、たとえば、あるメソッドが読み取り専用動作または読み書き動作のどちらを実行するのかを示すことができる。
【発明が解決しようとする課題】
【００３３】
サービス指向アーキテクチャで要求されたサービスを呼び出す構成等に関する上記問題を解決する。
【課題を解決するための手段】
【００３４】
下記に解決のための手段を詳しく記す。
【００３５】
本発明の図面に関して説明する。
【図面の簡単な説明】
【００３６】
【図１】本発明による構成を示す図である。
【図２】本発明による構成を示す図である。
【図３】本発明によるデータ・フェデレーション方法を示す図である。
【図４】本発明によるディスカバリ・サービスの高水準アーキテクチャを示す図である。
【図５】本発明によるディスカバリ・サービスの高水準アーキテクチャを示す図である。
【図６】本発明によるディスカバリ・サービスによって格納される発見されたサービス・ネットワークを示す図である。
【図７】発見されたサービス・ネットワークの情報が、サービス呼出しをどれほど促進できるかを示す図である。
【図８】発見されたサービス・ネットワークの情報が、サービス呼出しをどれほど促進できるかを示す図である。
【図９】発見されたサービス・ネットワークの情報が、サービス呼出しをどれほど促進できるかを示す図である。
【図１０】発見されたサービス・ネットワークの情報が、サービス呼出しをどれほど促進できるかを示す図である。
【図１１】サービスに関する情報を本発明によるデータ・フェデレーション方法とどのように一体化できるかを示す図である。
【発明を実施するための形態】
【００３７】
基本的なシナリオが、図１によって示されている。この図では、２つのサービス１１０３および１１０４が、サービス・インフラストラクチャ１５００上で既に展開済みである。その結果、ディスカバリ・サービス１１０６は、その知識ベース１２０６およびメタデータ・リポジトリ１２０７内に、サービス１１０３および１１０４のデータ・モデルに関する情報を既に有する。この図の３つのサービス１１０３、１１０４、および１１０５のすべてが、オーバーラップするデータ・モデル１２０２、１２０３、および１２０４を有することも仮定する。したがって、変換関数１２００が、システムによって既に演繹されており、この変換関数は、変換エンジン１１０２上で展開された。
【００３８】
このシナリオは、サービス・インフラストラクチャ１５００上の追加サービス１１０５の展開に継続する。管理者が、サービス・インフラストラクチャ１５００上で新しいサービス１１０５を展開する。
【００３９】
したがって、管理者は、そのサービスのＷＳＤＬインターフェースならびにそのサービス実施態様に対応するパッケージを管理ツール１１０７に提供する。管理ツール１１０７は、要求１４００をディスカバリ・サービス１１０６に送る。ディスカバリ・サービスは、ＷＳＤＬインターフェースを解析し、この文書からデータ・モデルを抽出する。
【００４０】
データ・モデルは、ＷＳＤＬ文書内のＸＭＬスキーマとして記述された、ＷＳＤＬインターフェース上で定義されたメソッドに対応するデータ構造ならびにメソッド引数データ構造からなる。このデータ・モデルは、メタデータ・リポジトリ１２０７に格納される。
【００４１】
ディスカバリ・サービス１１０６は、データ構造のオントロジおよび／またはセマンティック定義あるいは以前のサービス・デプロイメント中にモデルに挿入された類似物を含む知識ベース１２０６に問い合わせる、すなわち、展開する時に、サービス１１０３または１１０４は、新しいサービス・データ・モデルとそれが以前に既に発見したものとの間のすべての依存性および関係を解決することを試みる。
【００４２】
新しいデータ構造またはこれらのデータ構造内の特定のフィールドが、未解決のままである、すなわち、これらを既存のオントロジに関係付けることができない時には、オペレータは、管理ツール１１０７を介して、それらに関する追加のオントロジ記述を提供するように要求される１４０１。
【００４３】
管理ツールは、新しい関連付けを応答することができる１４０２。これらは、ディスカバリ・サービス１１０６によって知識ベース１２０６内に格納される。
【００４４】
すべてのデータ構造およびフィールドが分類された時に、関係が、リーズナ（ｒｅａｓｏｎｅｒ）１２０５によってデータ構造の間で検索される。それは、一種の型インターフェース機構である。
【００４５】
そのような関係について、システムは、コンポジット・データ構造の個々のフィールドの間の以前に発見された関係に基づいて、マッピング関数を自動的に構成することを試みる。
【００４６】
自動的に生成されたマッピングが正確であることを確かめるために、手動検証ステップを要求することができる。さらに、ＸＳＬＴスクリプトによって簡単に扱うことができないか、属性プロバイダなどの外部システムから追加情報を取り出すことを必要とする、複雑なマッピング・シナリオについて、手動介入を要求することができる。
【００４７】
関係を完全には自動的に解決できない時に、オペレータに、マッピングを提供するようにもう一度要求することができる１４０１。このマッピングは、ディスカバリ・サービス１１０６によって知識ベース１２０６内に格納される。
【００４８】
関連付けられたマッピング関数は、変換エンジン１１０２内で展開され１４０３、その結果、サービス・インフラストラクチャ内でサービス１２０１として使用可能になり、このサービス・インフラストラクチャを介して、メッセージが、それ相応に変換されるためにルーティングされなければならない。
【００４９】
より多くの関係が個々のデータ構造フィールドの間で見つかるにつれて、さらなるサービス・デプロイメントがこの情報から利益を得られるようになり、その結果、このプロセスは、ますます自動的になる。
【００５０】
図２に、メッセージ２４００がクライアント・アプリケーションまたは他のサービス２１００からサービスＡ  ２１０３に送信される、ランタイム・シナリオを示す。このメッセージは、サービスＡ  ２１０３のデータベース２２０２に格納されたデータ・レコードを更新する要求に対応する。このシナリオは、さらに、サービスＢ  ２１０４とサービスＣ  ２１０５との両方が、そのめいめいのデータベース２２０３および２２０４内でメッセージ２４００によって更新されるデータを共有すると仮定する。
【００５１】
すべてのサービス２１０３、２１０４、および２１０５が、サービス・インフラストラクチャ２５００に接続される。これを、エンタープライズ・サービス・バスまたは同等のメッセージ・ブローカとすることができる。サービス・インフラストラクチャは、内容ベースのルータ２１０１を含み、この内容ベースのルータ２１０１によって、サービス・インフラストラクチャ２５００上で展開されたサービス２１０３、２１０４、および２１０５宛のすべての要求が、インターセプトされ、ルーティングされる。
【００５２】
クライアント２１００からメッセージ２４００を受信した時に、内容ベースのルータ２１０１は、まず、ディスカバリ・サービス２１０６に相談して、この図で矢印２４０２によって示されるようにメッセージ２４００をその所期の宛先（サービス２１０３）にルーティングする前に、他のサービスがメッセージ２４００に関連する更新動作によって影響されるかどうかを見つける。
【００５３】
この例のシナリオでは、ディスカバリ・サービス２１０６は、２つのルートすなわち、第１変換関数２２００を介してターゲット・サービス２１０４に向かう１つのルートと、第２変換関数２２０１を介してターゲット・サービス２１０５に向かう１つのルートとを応答する。各変換関数は、オリジナル・メッセージ２４００を同等のメッセージすなわち、それぞれ矢印２４０４および２４０６によって示される、各影響されるサービス２１０４および２１０５によって公開されたインターフェースに準拠する、影響されるサービス２１０４および２１０５のデータベース２２０３および２２０４内の共有データに対する同一の更新を引き起こすという効果を有するメッセージに変換する。
【００５４】
ディスカバリ・サービス２１０６からルートを受け取る内容ベースのルータ２１０１は、まず、矢印２４０２によって示されるように、オリジナル・メッセージ２４００をその最初に意図されたターゲット・サービス２１０３に転送する。その後、内容ベースのルータ２１０１は、まず矢印２４０３によって示されるように第１変換関数２２００にメッセージ２４００を送り、次に矢印２４０４によって示されるように結果のすなわち変換されたメッセージをサービスＢ  ２１０４に送ることによって、第１ルートを処理する。最後に、内容ベースのルータ２１０１は、まず矢印２４０５によって示されるように第２変換関数２２０１にメッセージ２４００を送り、次に結果のすなわち変換されたメッセージをサービスＣ  ２１０５に送ることによって、第２ルートを処理する。
【００５５】
サービス２１０４と２１０５との両方が、それぞれメッセージ２４０４および２４０６に関連するロジックを実行する、すなわち、これらは、それぞれそのデータ・ストア２２０３および２２０４を更新する。
【００５６】
本発明が重要であるもう１つの領域は、ＳＣＡ準拠（サービス・コンポーネント・アーキテクチャ）サービス環境内であり、図３を参照されたく、図３では、サービス／コンポーネント３１００、３１０１、３１０２、および３１０３が、インポート３３００、３３０１、および３３０２すなわち別のコンポーネントが提供するとこれらが期待するインターフェースと、エクスポート３２００、３２０１、３２０２、および３２０３すなわちそのコンポーネント自体が他のコンポーネントに提供するインターフェースとの両方を宣言し、インポート３３００、３３０１、および３３０２は、特定の機能性を提供する新しいコンポーネント／サービスをコンポーズするために、エクスポート３２００、３２０１、３２０２、および３２０３にリンク／バインドされている３４００、３４０１、および３４０２。
【００５７】
少なくとも１つの変換関数（恒等を含む）３５００、３５０１、および３５０２が、リンク／バインディング３４００、３４０１、および３４０２に関連する。
【００５８】
ＥＳＢ環境のコンテキストでは、専用のフェデレーテッド・データ・マネージャ（Ｆｅｄｅｒａｔｅｄ  Ｄａｔａ  Ｍａｎａｇｅｒ、ＦＤＭ）が、このデータ・フェデレーション・モデルの実現を大幅に助けることができる。概念上、ＦＤＭは、ディスカバリ・サービス、取り出しサービス、およびプロビジョニング・サービスからなると考えることができる。
【００５９】
ディスカバリは、バス上で使用可能なデータを突き止め、このデータを表すモデルを維持することを意味し、取り出しまたは照会は、異なるサービスおよびデータ・モデルにまたがって検索する統合された照会をサポートすることであり、プロビジョニングは、バス上で既に使用可能なデータに基づいて新たに登録されるサービスのデータを提供することである。
【００６０】
ＦＤＭは、同期すなわち、類似するデータを一貫した状態に保つことにも使用することができる。
【００６１】
ＵＤＤＩによって提供される、伝統的なサービス・ディスカバリは、会社が、サービス・リスティングをパブリッシュし、他の会社からのサービスを発見することを可能にする。レジストリ内で使用可能なメタ・データは、サービスを記述し、検索するのに適する。このメタ・データは、どちらかといえば制限され、主に、会社、プロトコル、および標準分類に関し、セマンティック指定によって拡充されさえする。
【００６２】
データ駆動サービスに鑑みて、このディスカバリ機能性は、十分ではない。本発明の貢献は、データ駆動サービス・ディスカバリの要件の分析およびそのような高度なディスカバリ・サービスの一般的モデルの提示である。
【００６３】
ＦＤＭレジストリ（Ｒｅｇ）を図４に示す。ディスカバリ・サービスＤｉｓを、ＦＤＭの一部とみなすことができる。これは、サービスのデータ・モデルに基づいて、サービスおよびそのデータ使用を発見し、突き止める責任を負う。特定のサービスのデータ・モデルは、そのインターフェースに基づかなければならない。ディスカバリ・サービスは、サービスのインターフェース（またはそれに関するすべての追加の仕様）を点検し、この記述からデータ・モデルを推論しなければならない。
【００６４】
データ駆動サービス・ディスカバリに関して、異なるサービスのデータ・モデルの統合をサポートするために、データ型の間の関係を定義することが必要である。新しいサービスがディスカバリ・サービスに登録される時には必ず、ディスカバリ・サービスは、データ・モデルを更新し、新しい関係を発見し、インスタンス化する。
【００６５】
拡張として、メタ・データをこれらのデータ型および関係に使用して、よりセマンティックなデータ・ディスカバリにつながる分類モデルすなわちメタ・レベルでの議論のサポートを追加することができ、たとえば、映画または本などの内容だけを探すのではなくマルチメディア・コンテンツを扱うサービスを突き止めることができる。
【００６６】
ＦＤＭサービス調停に関して、ディスカバリ・サービスが、関係付けられたデータ型の間のセマンティックな相違を知ることが必要である。たとえば、アドレス帳サービスによって使用されるアドレス情報のフォーマットが、データ・フィールドが格納される順序において、またはある型において別々のデータ・フィールドとして表される情報対他の型で集約フィールドとして表される情報において、インスタント・メッセージング・サービスと異なる場合がある。
【００６７】
したがって、異なるデータ型の間の関係に加えて、ディスカバリ・サービスは、好ましくは、これらのデータ型をどのようにコンバートまたは変換すべきかの知識を組み込まなければならない。これは、関係が一方向であるか否かに応じて、関係内のあるデータ型を他のデータ型におよびその逆に変換できる変換サービス（をどのように利用すべきかの知識）にすべてのデータ関係を関連付けることによって達成することができる。
【００６８】
ディスカバリ・サービスは、結果のデータ・モデルを通ってナビゲートし、これらの変換を使用して、あるサービスをそれらのデータ・モデルを介して別のサービスにどのようにマッピングすべきかを演繹することができる。この文脈で、用語ルートは、そのようなマッピングにも使用される。これらのルートの主な使用は、組み込まれたサービスの間でのデータの自律的同期化Ｓｙである。
【００６９】
要約すると、そのようなデータベース・ディスカバリは、次の３つの主要なアクティビティからなる。
−登録するサービスのインターフェースからデータ・モデルを抽出すること
−抽出されたデータ・モデルをレジストリに格納されたデータ・モデルに関係付けること
−そのデータ・モデルに基づいてサービスを発見するために格納されたデータ・モデルを照会すること
【００７０】
新しいサービスが、ディスカバリ・サービスで登録される時に、そのサービスのインターフェースが点検され、データ・モデルが抽出される。インターフェースの性質およびインターフェース上のデータ部分の重要性に応じて、複数の情況が可能である。
【００７１】
最もむずかしいケース（現在は、そのようなデータ・フェデレーションが適用されないので最も頻繁なケースでもある）は、データ・フェデレーションを知らないサービスからのデータ・モデルの抽出である。インターフェース上のデータ部分の重要性は、小さく、ディスカバリ・サービスが抽出できる情報は、どちらかといえば限られている。
【００７２】
たとえば、ＷＳＤＬ記述は、通常、サービスの動作の入力または出力で使用されるデータ型の基本的な記述だけを含む。データ駆動サービスにより適切なのは、データ型をより詳細に記述し、パブリック・アクセス動作によって異なるデータ型をどのように読み取りまたは書き込むことができるか、すなわち、操作することができるかを記述する、別々のデータ・インターフェースを有するインターフェースである。
【００７３】
Ｊａｖａ（登録商標）Ｂｅａｎｓコンポーネントのプロパティのゲッタおよびセッタは、そのようなアクセス動作のよい例である。最も理想的な場合に、データ型は、たとえば、インライン化されたＷｅｂ  Ｏｎｔｏｌｏｇｙ  Ｌａｎｇｕａｇｅ（ＯＷＬ）の使用、コンストラクト、または別々のＯＷＬファイルの使用、他の既知の型への型の関係付け、あるいは共通のオントロジまたは標準オントロジでのそれらの統合など、セマンティックにも記述される。
【００７４】
現在格納されているデータ・モデル内でのサービスのデータ・モデルの統合は、新しいデータ型と既に存在するデータ型との間の区別ならびに新しいデータ型と以前に既知のデータ型との間の関係の識別と要約される。
【００７５】
インターフェースから抽出される情報が詳細であればあるほど、現在格納されているデータ・モデル内でのより意味のある新しいデータ型の統合が発生し得る。ここで捧げる要因は、明示的な型の使用である。たとえば、あるサービスのすべてのデータが、ストリングを使用してモデル化される場合に、ディスカバリ・サービスは、他のサービスのデータ・モデルとの多数の意味のある関係を推論することができない。インターフェース内のセマンティックスの度合が高ければ高いほど、より自律的な統合が発生し得る。新しいデータ型が、他の型への参照または関係付けなしに、独立に定義される場合に、これらの型を完全に自律的に統合することは、ほとんど不可能である。この場合に、格納されたデータ・モデルへの新しい型の関係付けは、たとえばディスカバリ管理者によって提供される、世界の知識を必要とする。
【００７６】
しかし、セマンティック情報がインターフェースに存在する場合には、統合は、レジストリおよびインターフェースに存在するセマンティック情報にまたがって推理することによって行うことができる。最もありそうなことに、このセマンティック情報は、標準オントロジまたは共通オントロジへの参照の形で現れる。この場合に、ディスカバリ・サービスは、このオントロジから正しい関係を直接に抽出することができる。
【００７７】
ディスカバリ・サービスが、関係付けられたサービスをそのデータ・モデルを介して検索できるようにするためには、ディスカバリ・サービスは、データ・モデルのレベルでのどの関係がサービスのレベルでの関係を導入できるかを定義するいくつかのルールを必要とする。
【００７８】
ディスカバリ・サービスは、たとえば、動作の間の関係Ｒの（推移）閉包として、特定の動作Ｓのセマンティックに関係付けられた動作の集合を定義することができる。動作Ｘは、ＸおよびＹの入力がオーバーラップする場合に、動作Ｙに関係付けられる。これを、入力型が入力のサブタイプまたは一部であるという意味におけるものとすることができる。
【００７９】
より実践的な手法は、あるデータ型から他のデータ型への変換が存在することだけを意味する関係ｉｓＴｒａｎｓｆｏｒｍａｂｌｅＴｏからなるものとすることができる。関係「〜のサブタイプ」、「〜の部分」、およびｉｓＴｒａｎｓｆｏｒｍａｂｌｅＴｏのそれぞれについて、変換サービスとの関連付けがある。
【００８０】
関係付けられた動作の上の定義は、あるデータ型または動作から別のデータ型または動作に進む変換のシーケンスを指定する。この動作のシーケンスは、実際には、データ・フェデレーション・マネージャ内のサービスの間の自動的同期化に使用されるルートである。
【００８１】
たとえば、アドレス帳およびインスタント・メッセンジャの場合に、ＵｐｄａｔｅＡｄｄｒｅｓｓをＡｄｄｒｅｓｓデータ型に、Ａｄｄｒｅｓｓデータ型をＶＣａｒｄデータ型で使用されるアドレス型に、およびそこからＶＣａｒｄを介してｕｐｄａｔｅＶＣａｒｄにマッピングする変換を介する、ＵｐｄａｔｅＡｄｄｒｅｓｓ動作からＵｐｄａｔｅＶＣａｒｄ動作へのルートがあるものとすることができる。
【００８２】
具体的な実施態様について、データ記述とデータ・ディスカバリ・テクノロジとの両方が必要である。たとえば、さらなる統合の必要を全く伴わずに、ＷＳＤＬとＯＷＬとの両方を使用することができる。すなわち、ＯＷＬを、ＷＳＤＬ仕様内でそれとして使用することができ、あるいは、ＯＷＬを、別々の仕様ファイルとして使用することができる。データ・ディスカバリ・テクノロジに関して、たとえば、ＵＤＤＩではなくｅｂＸＭＬを選択することができる。というのは、ｅｂＸＭＬが、はるかに表現力のあるデータ・モデルおよび照会アプリケーション・プログラマ・インターフェースを提供するからである。
【００８３】
ｅｂＸＭＬは、ディスカバリがその１つの部分である、電子ビジネス・コラボレーションの仕様のセットとして使用することができる。ｅｂＸＭＬによって使用されるレジストリは、レジストリとリポジトリとの両方からなる。リポジトリは、すべてのタイプの電子コンテンツを格納することができ、レジストリは、そのコンテンツを記述するメタ・データを格納することができる。リポジトリ内のコンテンツは、「リポジトリ・アイテム」と呼ばれるが、レジストリ内のメタ・データは、「レジストリ・オブジェクト」と呼ばれる。
【００８４】
ｅｂＸＭＬレジストリは、レジストリにサブミットできる標準メタ・データを指定するレジストリ情報モデル（ＲＩＭ）を定義する。この情報モデルの主要な特徴は、次を含む。
−ＲｅｇｉｓｔｒｙＯｂｊｅｃｔ  ｅｂＲＩＭ内のトップレベル・クラスが、ＲｅｇｉｓｔｒｙＯｂｊｅｃｔである。これは、このモデルのほとんどのクラスによって使用される抽象基底クラスである。これは、レジストリ・オブジェクトに最小限のメタ・データを提供する。
−Ｃｌａｓｓｉｆｉｃａｔｉｏｎ  すべてのＲｅｇｉｓｔｒｙＯｂｊｅｃｔを、個々のクラス階層要素を表すＣｌａｓｓｉｆｉｃａｔｉｏｎＳｃｈｅｍｅおよびＣｌａｓｓｉｆｉｃａｔｉｏｎＮｏｄｅを使用して分類することができる。ＣｌａｓｓｉｆｉｃａｔｉｏｎＳｃｈｅｍｅは、ＣｌａｓｓｉｆｉｃａｔｉｏｎＮｏｄｅから構成される木構造を定義する。ＣｌａｓｓｉｆｉｃａｔｉｏｎＳｃｈｅｍｅは、ユーザ定義とすることができる。
−Ａｓｓｏｃｉａｔｉｏｎ  すべてのＲｅｇｉｓｔｒｙＯｂｊｅｃｔを、Ａｓｓｏｃｉａｔｉｏｎインスタンスを使用して任意の他のＲｅｇｉｓｔｒｙＯｂｊｅｃｔに関連付けることができ、ここで、一方のオブジェクトが、ＡｓｓｏｃｉａｔｉｏｎインスタンスのｓｏｕｒｃｅＯｂｊｅｃｔであり、他方のオブジェクトがｔａｒｇｅｔＯｂｊｅｃｔである。Ａｓｓｏｃｉａｔｉｏｎインスタンスは、関連付けの性質を定義するａｓｓｏｃｉａｔｉｏｎＴｙｐｅを有することができる。ｅｂＸＭＬ準拠になるためにレジストリがサポートしなければならない複数の事前定義のＡｓｓｏｃｉａｔｉｏｎ型がある。ｅｂＸＭＬは、このリストを展開することを可能にする。
−サービス記述、ＳｅｒｖｉｃｅＢｉｎｄｉｎｇクラスおよびＳｐｅｃｉｆｉｃａｔｉｏｎＬｉｎｋクラスは、ＷＳＤＬを含むサービス定義を定義する能力を提供する。ｅｂＸＭＬは、レジストリを使用するためにこの２つのインターフェースをエクスポートする。
−Ｌｉｆｅ−ＣｙｃｌｅＭａｎａｇｅｒ（ＬＣＭ）は、すべてのオブジェクト・ライフサイクル管理要求の責任を負う。
−ＱｕｅｒｙＭａｎａｇｅｒ（ＱＭ）は、すべての照会要求を処理する責任を負う。クライアントは、レジストリを照会し、オブジェクトを発見するのに、このサービスによって定義された動作を使用する。
【００８５】
ｅｂＸＭＬ照会サービスは、このデータ・モデルをフルに利用する。すべての情報を、レジストリ内のアイテム、たとえば、ある種のアイテムまたはあるＣｌａｓｓｉｆｉｃａｔｉｏｎＮｏｄｅを用いて分類されたすべてのＳｅｒｖｉｃｅアイテムに関連するすべてのＲｅｇｉｓｔｒｙＯｂｊｅｃｔを検索するのに使用することができる。セマンティック関係を用いてｅｂＸＭＬレジストリ内のデータ分類モデルを機能強化するために、ｅｂＸＭＬ内で使用可能なコンストラクトを使用することができる。ｅｂＸＭＬレジストリ情報モデルは、データ・クラスのＯＷＬ記述をシミュレートするのに使用することができる。
【００８６】
バックボーン・コンポーネントとしてｅｂＸＭＬを使用するデータ・ディスカバリ・サービス・プロトタイプのために、アーキテクチャが定義されている。
【００８７】
図５に、このアーキテクチャの高水準コンポーネント図を示す。このアーキテクチャは、３つのコンポーネントすなわちＤ、ＱＦ、およびＥＢからなる。ディスカバリ・コンポーネントＤは、３つのインターフェースＬＣ、Ｑ、およびＡを提供し、これらは、他のＦＤＭサービスによって使用される。ライフサイクル・インターフェースＬＣは、登録されたサービスのライフサイクル管理に使用される。ライフサイクル・インターフェースＬＣは、システム管理者が、新しいサービスをサブスクライブし、パブリッシュし、アクティブ化するのに使用することができる。このコンポーネントは、記述に基づいてサービス情報をレジストリに格納し、サービスのデータ・モデルおよび他のデータ型との関係をレジストリ内で提案する。このインターフェースは、提案されたデータ関係を解決し、格納する動作をも含む。管理インターフェースＡは、レジストリ上の保守動作に使用される。
【００８８】
システム管理者は、これを、特にデータ・モデルおよびデータ・モデルの間の関係に対する、保守に使用する。照会インターフェースＱは、レジストリに格納された情報を検索するのに使用される。照会インターフェースＱは、主に関係付けられたサービスへのルートを見つけるのに同期サービスによって使用される、１つの特定の動作と、ｅｂＸＭＬ標準規格で定義された構造化照会言語（ＳＱＬ）様照会用の１つの包括的動作とを提供する。ｅｂＸＭＬコンポーネントＥＢは、ｅｂＸＭＬ標準規格に完全に準拠するレジストリおよびディスカバリ・サービスである。ｅｂＸＭＬコンポーネントＥＢは、ディスカバリ・コンポーネントＤとサードパーティ・クライアントとの両方によって使用される。前者は、データ・モデルと関連する変換との間の関係を含むこれらのモデルと一緒に使用可能なサービスを格納するレジストリとしてＥＢを使用し、後者は、伝統的なディスカバリ・サービスとしてＥＢを使用することができる。ＱｕｅｒｙＦａｃａｄｅコンポーネントＱＦは、たとえば推移関係を介して検索するために、再帰照会を処理することができる。このコンポーネントは、ｅｂＸＭＬ標準規格仕様がこの機能性を含まないので必要である。
【００８９】
ディスカバリ・コンポーネントＱ、Ａ、およびＬＣのインターフェースは、主に、入力および出力としてＷＳＤＬフォーマットおよびＯＷＬフォーマットを使用するが、内部的には、ディスカバリ・レジストリは、ｅｂＸＭＬフォーマットに基づく。したがって、データ・モデルの抽出は、ＷＳＤＬおよびＯＷＬをｅｂＲＩＭおよびｅｂＲＳパブリケーション・フォーマットに変換することに帰着する。
【００９０】
サービスは、Ｓｅｒｖｉｃｅクラスを用いて表すことができ、ＷＳＤＬからの残りの情報は、ＳｅｒｖｉｃｅＢｉｎｄｉｎｇクラスおよびＳｐｅｃｉｆｉｃａｔｉｏｎＬｉｎｋクラスに来る。サービスによって使用されるデータ・モデルは、ＣｌａｓｓｉｆｉｃａｔｉｏｎＳｃｈｅｍｅにマッピングされ、各ＣｌａｓｓｉｆｉｃａｔｉｏｎＮｏｄｅは、データ・モデル内の１つの型を表し、Ｃｌａｓｓｉｆｉｃａｔｉｏｎを使用してサービスに関連付けられる。
【００９１】
たとえば、上で述べたアドレス帳サービスを、ｅｂＸＭＬレジストリに格納することができる。このサービスは、一方はアドレス情報変更用、他方はアドレス帳への新しいエントリの追加用の、２つのデータ型を用いて分類される。これらの型が、ａｄｄｒｅｓｓ型、ｐｅｒｓｏｎ型、およびストリングからなるものとする。
【００９２】
新しいサービスがレジストリ内でパブリッシュされる時に、新しいデータ・モデル要素が、レジストリに挿入されなければならず、サービスのデータ・モデルが、既にレジストリに格納されているデータ型に関連付けられなければならない。ディスカバリ・サービスは、後者を完全に自律的に達成することができない場合がある。その場合に、ディスカバリ・サービスは、たとえばシステム管理者によってファイナライズされなければならない、提案されるデータ型関係のセットを演繹することができる。
【００９３】
関連付けに関するある単純化を、データ型の間の完全な同等性に基づくものとすることができ、たとえば、ある型がレジストリ内で既に使用可能である時に、そのサービス固有関係は、やはりレジストリに追加されなければならない。この演繹を適切で完全にするために、システム管理者は、ＷＳＤＬパブリケーションにＯＷＬコンストラクトを埋め込むことによってセマンティックデータ情報を用いてサービス記述を拡張することができる。
【００９４】
モデルを介して異なるサービスの動作の間のルートを検索するために、Ｆｌｏｙｄ−Ｗａｒｓｈａｌ様アルゴリズムを使用することができ、あるいは、ｏｎｅ  ｐａｉｒ  ｓｈｏｒｔｅｓｔ  ｐａｔｈディスカバリすなわちＤｉｊｋｓｔｒａ検索タイプからのアルゴリズムを使用することができる。
【００９５】
図６に、サービス・ネットワークのより抽象的な表現を示す。上で述べたように、サービスは、矢印Ｔによって示される関数に対応する。サービスは、矢印Ｔの１カテゴリを形成し、ここで、サービスＴは、入力および出力のデータ型Ｄを有する。これらの型は、サービスを定義し、逆も同様である。２つのサービスの連結について、型は、準拠しなければならない、すなわち、型を、少なくとも、セマンティック・レベルで型のメタ情報から導出できる変換関数によって、一致させなければならない。黒丸をより詳細に見ることは、型が、前述のデータ・モデルとして概要を示された実現で実施されるデータ表現の同等のクラスを形成することを意味する。
【００９６】
図７は、連結シナリオすなわち、適当なすなわち互換のインターフェースを有するサービスの連続する呼出しを示す。破線の矢印によって示される、結果の（連結された）サービスの、入力型Ｓおよび出力型Ｅがある。この（仮想）サービスは、３つの実サービスからなる。
【００９７】
サービスを、矢印のカテゴリで連結することができる。連結された呼出しのシーケンスは、開始Ｓおよび終了Ｅを有するグラフ内のパス（太い）に対応する。制約は、データ型が一貫している必要がある、すなわち、第Ｎ矢印が黒丸で終わり、そこで第Ｎ＋１矢印が始まることである。パスは、入力型Ｓおよび出力型Ｅを有する（仮想）サービス（破線）に対応する。
【００９８】
本発明によるディスカバリ・サービスは、図６に示されたサービス・ネットワークを意識する。ディスカバリ・サービスＸは、このサービス・ネットワークのマップを、図８に示されているように格納する。クライアントＣは、Ｓ？Ｅ、たとえば入力データ型Ｓおよび出力データ型Ｅによって定義されるサービスが存在するかどうかを照会することができる。この照会は、クライアントＣとディスカバリ・サービスＸとの間の接続によって図示されている。
【００９９】
図９では、サービス・ネットワークを介するルートがどのように発見されるかが示されている。ディスカバリ・サービスＸは、そのマップ内で入力データ型Ｓおよび出力データ型Ｅを識別しなければならず、サービスは、対応する点のデータ型（または同等性クラス）の間の接続すなわちデータ・モデルをマップ内で識別しなければならない。これは、サービスＴ１、Ｔ２、およびＴ３のパスすなわち、一般に、パスのセットである。この情報すなわちルーティング情報（任意選択で型変換のためのデータ変換を含む）が、クライアントＣに応答される。
【０１００】
それが、図１０に示されているように、クライアントがパスによって定義されるサービス・チェーンを呼び出すことを可能にする。この入力を用いて、第１サービスＴ１が呼び出されＩＴ１、この呼出しの結果を用いて第２サービスＴ２が呼び出されＩＴ２、最後に、第３サービスＴ３が呼び出され、提供された出力型Ｅの結果を作る。
【０１０１】
要約すると、入力データ型Ｓおよび出力データ型Ｅを有するサービスを探すクライアントＣは、専用サービスＸに、検索されるサービスを提供するサービス呼出しのシーケンスを要求することができる。専用サービスＸは、そのメモリ内でデータ型をルック・アップすることができ、たとえばＤｉｊｋｓｔｒａのアルゴリズムを介してまたはＦｌｏｙｄ−Ｗａｒｓｈａｌアルゴリズムを介する推移閉包によって、パスを計算することができる。それが、クライアントがサービスを連結された形で呼び出すことを可能にする。
【０１０２】
図１１に、ディスカバリ・サービス内に格納されるマップをどのように作成できるか（増分的に）を示す。図６に示された（既に発見された）サービス・ネットワークから始めて、新しいサービスＳが、登録されなければならないと仮定する。これは、破線の矢印によって示されている。このサービスは、入力データ型ＤＳおよび出力データ型ＤＥを有する。ルックアップは、入力データ型ＤＳが完全に新規すなわち未知であるが、セマンティック記述から、既知のデータ型と新規データ型との間の変換を導出することができる。これは、マップ内で新しい黒丸および新しい矢印を作成することによって記憶される。出力データ型ＤＥは、この例では既知のデータ型として識別することができる。これは、破線の円によって示されている。マップは、データ型ＤＳおよびＤＥを直接に接続する矢印の統合によって完成する。最後に、上で述べたディスカバリ・サービスは、サービス、データ型、およびデータ型変換の一貫した完全な像（モデル）を有する。
【０１０３】
この技法は、たとえばサービス指向アーキテクチャ内の、コンシューマ・サービスと複数のプロバイダ・サービスとの間で交換されるメッセージの適合のための構成を可能にし、この構成は、別個のサービス・データ・モデルのストレージ手段を含むディスカバリ・サービス（各サービス・データ・モデルは、プロバイダ・サービスに関連付けられる）と、前記サービス・データ・モデルの間の関係のためのストレージ手段とを含む。それは、ディスカバリ・メッセージ・ルートを可能にし、プロバイダ・サービスあたり１つのメッセージ・ルートがあり、各メッセージ・ルートは、０個以上のサービス呼出しのシーケンスとして、任意選択でデータ・モデル関係に関連付けられる変換と共に定義される。ディスカバリ手段は、前記コンシューマ・サービスのメッセージを指定されたプロバイダ・サービス宛のメッセージ・ルートに適合させることができる。好ましくは、ディスカバリ手段は、メッセージ・ルートの前記シーケンス内の最後のプロバイダ・サービスとして前記コンシューマ・サービスのメッセージを含めることができる。
【０１０４】
ディスカバリ手段は、さらに、以前に確立された関係に基づくサービス・データ・モデルの間の新しい関係の自動演繹をサポートするように適合されたリーズナ（２２０５）を含むことができる。ディスカバリ手段は、プロバイダ・サービスの間で共有されるデータの同期化をサポートするために、前記コンシューマ・サービスと前記指定されたプロバイダ・サービスとの間で交換される前記メッセージが他のプロバイダ・サービスのサービス・データ・モデルに対して有する影響に基づいて少なくとも１つの追加のターゲット・プロバイダ・サービスを自動的に判定するように適合させることができる。
【図１】
2010503088.tif 000003
【図２】
2010503088.tif 000004
【図３】
2010503088.tif 000005
【図４】
2010503088.tif 000006
【図５】
2010503088.tif 000007
【図６】
2010503088.tif 000008
【図７】
2010503088.tif 000009
【図８】
2010503088.tif 000010
【図９】
2010503088.tif 000011
【図１０】
2010503088.tif 000012
【図１１】
2010503088.tif 000013
【国際調査報告】
2010503088.tif 000014
2010503088.tif 000015
2010503088.tif 000016