(57)【要約】【課題】複数のサービスコンポーネントをサービス利用者状況に応じて連携し、サービス利用者に適切なサービスを提供する。【解決手段】ユーザ端末７は、サービスを連携するサービス連携エンジン１に対して、利用したいサービスのサービスシナリオを入力して設定する（Ｓ１）。サービス連携エンジン１は、サービスシナリオが設定されると、サービスシナリオに記述されたサービスコンポーネントのメタデータを用いて、利用可能な同等サービスコンポーネント群を検索して検出する（Ｓ２）。次に、サービス利用者状況に応じて、該サービスコンポーネント群から適切なサービスコンポーネントを選択する（Ｓ３）。その後、サービスシナリオに記述された制御ロジックに基づいてサービスコンポーネントを実行および連携する（Ｓ４）。【選択図】図５
2008130033.tif 000002
【特許請求の範囲】
【請求項１】
指定されたサービスシナリオに基づいて、サービスコンポーネントを連携するサービス連携方法あって、
複数のサービスコンポーネントを記憶させる第１の記憶ステップと、
サービス利用者状況を示すユーザコンテキストを記憶させる第２の記憶ステップと、
サービスコンポーネントのインターフェース情報、もしくは、サービスコンポーネントの動作を表すメタデータ情報が記述されたサービスシナリオを設定するサービスシナリオ設定ステップと、
前記設定されたサービスシナリオに記述されたインターフェース情報、もしくは、メタデータ情報に基づいて、前記複数のサービスコンポーネントの中から、利用するサービスコンポーネント群を検出するサービスコンポーネント群検出ステップと、
前記検出されたサービスコンポーネント群から、前記ユーザコンテキストに応じたサービスコンポーネントを選択するサービスコンポーネント選択ステップと、
前記選択されたサービスコンポーネントを実行および連携するサービスコンポーネント実行・連携ステップと
を含むことを特徴とするサービス連携方法。
【請求項２】
サービスコンポーネントのメタデータ同士の同値関係または継承関係を記憶させる第３の記憶ステップを更に含み、
前記サービスコンポーネント群検出ステップは、前記メタデータ同士の同値関係または継承関係に基づいて、利用するサービスコンポーネント群を検出することを特徴とする請求項１記載のサービス連携方法。
【請求項３】
前記検出されたサービスコンポーネント群から、サービス利用者状況を示すユーザコンテキスト情報と、サービス利用者がどのようなサービスコンポーネントを優先するかを示す情報であるユーザポリシ情報と、サービスコンポーネントの性質を表すメタデータ情報とのマッチング度合いに基づいて点数付けを行う点数付けステップを更に含み、
前記サービスコンポーネント選択ステップは、付けられた点数が高い方のサービスコンポーネントを選択することを特徴とする請求項１記載のサービス連携方法。
【請求項４】
前記サービスコンポーネント実行・連携ステップは、前記サービスシナリオに記述されているメタデータ情報を、前記選択されたサービスコンポーネントの動作を表すメタデータ情報と、そのサービスコンポーネントのインターフェース情報との間のマッピングを表すマッピング情報とを用いて、サービスコンポーネントの実際のインターフェースに変換して、選択されたサービスコンポーネントを実行および連携することを特徴とする請求項１記載のサービス連携方法。
【請求項５】
前記インターフェース情報は、少なくとも、オペレーション情報、入力メッセージ情報、出力メッセージ情報を含み、
前記サービスコンポーネント群検出ステップは、前記オペレーション情報、入力メッセージ情報、出力メッセージ情報を含むインターフェース情報に基づいて、利用可能なサービスコンポーネント群を検出することを特徴とする請求項１記載のサービス連携方法。
【請求項６】
前記検出されたサービスコンポーネント群をサービス利用者に選択させるべく提示する提示ステップを更に含み、
前記サービスコンポーネント選択ステップは、サービス利用者により選択されたサービスコンポーネントを、実行および連携すべきサービスコンポーネントとして選択することを特徴とする請求項５記載のサービス連携方法。
【請求項７】
前記サービスコンポーネント選択ステップは、前記検出されたサービスコンポーネント群の中から、実行および連携すべきサービスコンポーネントをランダムに選択することを特徴とする請求項５記載のサービス連携方法。
【請求項８】
前記サービスコンポーネント実行・連携ステップは、サービスシナリオにてサービスコンポーネントがインターフェース情報で指定されている場合には、該インターフェース情報に基づいて、選択されたサービスコンポーネントを実行および連携することを特徴とする請求項５記載のサービス連携方法。
【請求項９】
前記サービスシナリオは、
ネットワークを介して直接入力されるか、あるいは、
予め記憶しておいた複数のサービスシナリオの中から、利用するサービスシナリオを取得して入力されるか、あるいは、
予め記憶しておいた複数のサービスシナリオのうち、利用するサービスシナリオの識別情報が指定されることを特徴とする請求項１記載のサービス連携方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上のサービスコンポーネントを検出して連携することで、適切なサービスを提供するサービス連携方法に関する。
【背景技術】
【０００２】
ＩＴ技術の進歩に伴い、ＰＣだけでなく、携帯、家電、センサなどの様々な機器をネットワークに接続し、ユーザの生活を支援するためのユビキタス環境が実現しつつある。ユビキタス環境では、これらの機器・機能が有機的に連携することで、従来は実現が困難であったコンテキストアウェアサービスが期待される。ユーザニーズは、位置などの実世界の状況に応じて動的に変化するため、従来の様にサービス提供者が予め全サービスを作り込んでおく形でなく、その場の状況に応じてサービスコンポーネントを組み合わせてサービスを提供するサービス連携の考え方が重要である。
【０００３】
既存技術として、個々のＷＳ（Web Service）を連携させる手法であるＢＰＥＬ（Business Process Execution Language for Web Services）が注目を集めている（例えば、非特許文献１参照）。該ＢＰＥＬとは、複数のＷｅｂサービスを順に呼び出して実行する手順を、一連のビジネスの流れとして記述するための言語である。該ＢＰＥＬを用いると、「注文を受け付ける」、「在庫を確認する」といった一連のビジネス・プロセスのなかで、いつ、どのような条件のときに、どのＷＳを呼び出すかを定義することができる。
【非特許文献１】OASIS, Web Service Business Process Execution LanguageVersion2.0 Committee Draft, [online], 17th May, 2006,[平成１８年１０月１９日検索],インターネット<URL: http://www.oasis-open.org/committees/download.php/18714/webpel-specification-draft-May17.htm
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、ＢＰＥＬは、元来、Ｂ２Ｂ（Business to Business）が対象であり、予め利用するＷＳを決定し、それに合わせたサービスフローであるＢＰＥＬ文書と接続定義とを、ＢＰＥＬ実行エンジンにデプロイする必要があるため、ユーザの状況に応じてＷＳを検出し、バインド・実行することは困難である。なお、上記デプロイとは、ネットワークアプリケーションや、ＷＳなどを、利用可能なように準備することである「インストール」に近い意味であるが、インストールは、コンピュータにソフトウェアを導入することを意味するのに対して、デプロイメントは、外部からネットワーク経由で利用されるソフトウェアや、他のソフトウェアなどから参照されるコンポーネントを、利用可能な状態にすることである。
【０００５】
ユーザ状況に合わせたサービス合成にＢＰＥＬを適用する場合、具体的には、以下の問題がある。すなわち、
（１）ＢＰＥＬ文書には、個々のＷＳのインターフェース情報であるＷＳＤＬ（Web Service Description Language）のポートタイプ名とオペレーション名とが記述されるため、それらが完全マッチするＷＳにしか適用できないという問題がある。
（２）ＢＰＥＬ実行には、ＢＰＥＬ文書及びどのＷＳに接続するかの接続定義情報を予めデプロイしておく必要があり、実行前に既にＷＳは決まっているという問題がある。
【０００６】
本発明は、このような事情を考慮してなされたものであり、その目的は、ネットワーク上の複数のサービスコンポーネントをサービス利用者状況に応じて連携することで、サービス利用者に適切なサービスを提供することができるサービス連携方法を提供することにある。
【課題を解決するための手段】
【０００７】
上述した課題を解決するために、本発明は、指定されたサービスシナリオに基づいて、サービスコンポーネントを連携するサービス連携方法あって、複数のサービスコンポーネントを記憶させる第１の記憶ステップと、サービス利用者状況を示すユーザコンテキストを記憶させる第２の記憶ステップと、サービスコンポーネントのインターフェース情報、もしくは、サービスコンポーネントの動作を表すメタデータ情報が記述されたサービスシナリオを設定するサービスシナリオ設定ステップと、前記設定されたサービスシナリオに記述されたインターフェース情報、もしくは、メタデータ情報に基づいて、前記複数のサービスコンポーネントの中から、利用するサービスコンポーネント群を検出するサービスコンポーネント群検出ステップと、前記検出されたサービスコンポーネント群から、前記ユーザコンテキストに応じたサービスコンポーネントを選択するサービスコンポーネント選択ステップと、前記選択されたサービスコンポーネントを実行および連携するサービスコンポーネント実行・連携ステップとを含むことを特徴とする。
【０００８】
本発明は、上記の発明において、サービスコンポーネントのメタデータ同士の同値関係または継承関係を記憶させる第３の記憶ステップを更に含み、前記サービスコンポーネント群検出ステップは、前記メタデータ同士の同値関係または継承関係に基づいて、利用するサービスコンポーネント群を検出することを特徴とする。
【０００９】
本発明は、上記の発明において、前記検出されたサービスコンポーネント群から、サービス利用者状況を示すユーザコンテキスト情報と、サービス利用者がどのようなサービスコンポーネントを優先するかを示す情報であるユーザポリシ情報と、サービスコンポーネントの性質を表すメタデータ情報とのマッチング度合いに基づいて点数付けを行う点数付けステップを更に含み、前記サービスコンポーネント選択ステップは、付けられた点数が高い方のサービスコンポーネントを選択することを特徴とする。
【００１０】
本発明は、上記の発明において、前記サービスコンポーネント実行・連携ステップは、前記サービスシナリオに記述されているメタデータ情報を、前記選択されたサービスコンポーネントの動作を表すメタデータ情報と、そのサービスコンポーネントのインターフェース情報との間のマッピングを表すマッピング情報とを用いて、サービスコンポーネントの実際のインターフェースに変換して、選択されたサービスコンポーネントを実行および連携することを特徴とする。
【００１１】
本発明は、上記の発明において、前記インターフェース情報は、少なくとも、オペレーション情報、入力メッセージ情報、出力メッセージ情報を含み、前記サービスコンポーネント群検出ステップは、前記オペレーション情報、入力メッセージ情報、出力メッセージ情報を含むインターフェース情報に基づいて、利用可能なサービスコンポーネント群を検出することを特徴とする。
【００１２】
本発明は、上記の発明において、前記検出されたサービスコンポーネント群をサービス利用者に選択させるべく提示する提示ステップを更に含み、前記サービスコンポーネント選択ステップは、サービス利用者により選択されたサービスコンポーネントを、実行および連携すべきサービスコンポーネントとして選択することを特徴とする。
【００１３】
本発明は、上記の発明において、前記サービスコンポーネント選択ステップは、前記検出されたサービスコンポーネント群の中から、実行および連携すべきサービスコンポーネントをランダムに選択することを特徴とする。
【００１４】
本発明は、上記の発明において、前記サービスコンポーネント実行・連携ステップは、サービスシナリオにてサービスコンポーネントがインターフェース情報で指定されている場合には、該インターフェース情報に基づいて、選択されたサービスコンポーネントを実行および連携する。
【００１５】
本発明は、上記の発明において、前記サービスシナリオは、ネットワークを介して直接入力されるか、あるいは、予め記憶しておいた複数のサービスシナリオの中から、利用するサービスシナリオを取得して入力されるか、あるいは、予め記憶しておいた複数のサービスシナリオのうち、利用するサービスシナリオの識別情報が指定されることを特徴とする。
【発明の効果】
【００１６】
この発明によれば、複数のサービスコンポーネントを記憶させ、サービス利用者状況を示すユーザコンテキストを記憶させておき、サービスコンポーネントのインターフェース情報、もしくは、サービスコンポーネントの動作を表すメタデータ情報が記述されたサービスシナリオが設定されると、設定されたサービスシナリオに記述されたインターフェース情報、もしくは、メタデータ情報に基づいて、複数のサービスコンポーネントの中から、利用するサービスコンポーネント群を検出し、該検出されたサービスコンポーネント群から、ユーザコンテキストに応じたサービスコンポーネントを選択し、選択されたサービスコンポーネントを実行および連携する。したがって、利用するサービスコンポーネントを、サービスコンポーネントがどのような動作を持つかのメタデータ情報を用いて抽象的に記述することで、インターフェースは異なるが、機能が同等なサービスコンポーネントを検出して選択可能にすることで、ユーザ状況に応じた適切なサービスを提供することができるという利点が得られる。
【００１７】
また、本発明によれば、サービスコンポーネントのメタデータ同士の同値関係または継承関係を記憶させておき、サービスコンポーネント群を検出する際に、メタデータ同士の同値関係または継承関係に基づいて、利用するサービスコンポーネント群を検出する。したがって、メタデータの語彙が異なっていても、同等なメタデータのサービスコンポーネントを検出することができるという利点が得られる。
【００１８】
また、本発明によれば、検出されたサービスコンポーネント群から、サービス利用者状況を示すユーザコンテキスト情報と、サービス利用者がどのようなサービスコンポーネントを優先するかを示す情報であるユーザポリシ情報と、サービスコンポーネントの性質を表すメタデータ情報とのマッチング度合いに基づいて点数付けを行い、付けられた点数が高い方のサービスコンポーネントを選択する。したがって、サービス利用者の状況及び要求の優先度に対して適切なサービスコンポーネントを選択することができるという利点が得られる。
【００１９】
また、この発明によれば、サービスシナリオに記述されているメタデータ情報を、選択されたサービスコンポーネントの動作を表すメタデータ情報と、そのサービスコンポーネントのインターフェース情報との間のマッピングを表すマッピング情報とを用いて、サービスコンポーネントの実際のインターフェースに変換して、選択されたサービスコンポーネントを実行および連携する。したがって、サービスコンポーネントのオペレーション呼出しなどがサービスシナリオにメタデータで記述されていても、サービスコンポーネントの実際のインターフェースに変換することができ、ユーザ状況に応じた適切なサービスを提供することができるという利点が得られる。
【００２０】
また、本発明によれば、サービスコンポーネント群を検出する際に、オペレーション情報、入力メッセージ情報、出力メッセージ情報を含むインターフェース情報に基づいて、利用可能なサービスコンポーネント群を検出する。したがって、ポートタイプ名、オペレーション名、入力メッセージ名、出力メッセージ名などのインターフェース情報に従って、容易にサービスコンポーネントを検出することができるという利点が得られる。
【００２１】
また、本発明によれば、サービスコンポーネントを選択する際に、検出されたサービスコンポーネント群をサービス利用者に選択させるべく提示し、サービス利用者により選択されたサービスコンポーネントを、実行および連携すべきサービスコンポーネントとして選択する。したがって、Ｐｒｏｆｉｌｅ情報などのメタデータがない場合であっても、柔軟にサービスコンポーネントを選択することができるという利点が得られる。
【００２２】
また、この発明によれば、検出されたサービスコンポーネント群の中から、実行および連携すべきサービスコンポーネントをランダムに選択する。したがって、Ｐｒｏｆｉｌｅ情報などのメタデータがない場合であっても、柔軟にサービスコンポーネントを選択することができるという利点が得られる。
【００２３】
また、本発明によれば、サービスシナリオにてサービスコンポーネントがインターフェース情報で指定されている場合には、該インターフェース情報に基づいて、選択されたサービスコンポーネントを実行および連携する。したがって、サービスシナリオのメタデータから実際のインターフェースに変換することなく、より容易にサービスコンポーネントを実行および連携することができるという利点が得られる。
【００２４】
また、この発明によれば、サービスシナリオは、ネットワークを介して直接入力されるか、あるいは、予め記憶しておいた複数のサービスシナリオの中から、利用するサービスシナリオを取得して入力されるか、あるいは、予め記憶しておいた複数のサービスシナリオのうち、利用するサービスシナリオの識別情報が指定される。したがって、サービスシナリオの入力方法を多様化することで、より柔軟に対応することができるという利点が得られる。
【発明を実施するための最良の形態】
【００２５】
以下、本発明の一実施形態を、図面を参照して説明する。
【００２６】
＜システム構成＞
図１は、本発明の実施形態によるサービス連携システムの構成を示すブロック図である。図１において、本実施形態によるシステムは、サービス連携エンジン１、サービスコンポーネント情報ＤＢ（データベース）２、ユーザコンテキスト・ポリシＤＢ３、オントロジＤＢ４、サービスシナリオＤＢ５、サービスコンポーネント提供端末６、ユーザ端末７を備えており、それぞれネットワーク８を介して接続されている。
【００２７】
サービス連携エンジン１は、サービスシナリオに基づいてサービスコンポーネントの検出、選択、実行を行う。サービスコンポーネント提供端末６は、サービスコンポーネントを提供する端末である。サービスシナリオＤＢ５は、上記サービスシナリオを記憶する。サービスコンポーネント情報ＤＢ２は、サービスコンポーネント情報を記憶し、インターフェース情報による検索とメタデータ情報による検索の両方が可能である。
【００２８】
オントロジＤＢ４は、メタデータ同士の同値関係や、継承関係などの関係を記憶し、異なる語彙のメタデータの関係解決に用いられる。ユーザコンテキスト・ポリシＤＢ３は、ユーザコンテキスト情報とユーザポリシ情報とを記憶し、ユーザ識別子に応じてユーザコンテキスト情報や、ユーザポリシ情報が取得可能となっている。ユーザ端末７は、ユーザに操作される端末であり、サービス連携エンジン１にサービスシナリオを入力して実行したり、サービスを終了したりするための、指示端末である。
【００２９】
本実施形態では、ユーザが、個人端末やサーバに搭載されたサービス連携エンジン１を用いて、ユーザ状況に応じてサービスコンポーネントを連携し、適切なサービスを利用可能にする技術を確立することを特徴としている。
【００３０】
本実施形態では、サービスコンポーネントに関して、以下の２つの事項を前提とする。
（１）対象とするコンポーネントは、ＷＳや、ＵＰｎＰ（Universal Plug and Play）などの疎結合型のコンポーネントとする。
（２）また、サービスコンポーネントは、どのような機能であるかのサービス記述（インタフェース、属性など）をネットワークに公開しているとする。
【００３１】
＜サービスシナリオの記述例＞
図２は、本実施形態によるサービスシナリオの記述の一例である。上述したＢＰＥＬやＰＤ４Ｊ（Process Definition for Java（Javaは登録商標））では、ＷＳＤＬのポートタイプや、オペレーション名を用いて厳密なインターフェース情報で記述している。これに対して、本実施形態によるサービスシナリオでは、カテゴリやプロセスなどのメタデータを用いてサービスコンポーネントを指定している。また、ＢＰＥＬやＰＤ４Ｊなどとのもう１つの違いとして、連携サービス実行中にサービスコンポーネントを検索するという、ｓｅａｒｃｈタグがあるのも、本実施形態によるサービスシナリオの特徴である。ＢＰＥＬでは、サービス開始前に全てのＷＳは決まっており、実行中にＷＳを切換えるということは不可能である。これに対して、本実施形態によるサービスシナリオでは、サービス実行中のパラメータ値などに基づいて、サービスコンポーネントを検索するという記述も可能である。
【００３２】
つまり、本実施形態によるサービスシナリオは、サービスコンポーネントをメタデータで指定している点、ｓｅａｒｃｈというサービス実行中にサービスコンポーネントを検索する記述がある点で、ＢＰＥＬとは異なっている。
【００３３】
＜サービスシナリオ、サービスコンポーネント記述＞
ＢＰＥＬの課題を解決するため、本実施形態では、サービスフローであるサービスシナリオに個々のサービスコンポーネントのインターフェース情報を記述するのではなく、所望する機能の動作を表すメタデータを用いて抽象的に記述し、インターフェース名は異なるが、機能は同等なサービスコンポーネント群を検出して選択可能にすることで、状況に応じたサービスの実現を目指している。
【００３４】
図３は、本実施形態によるサービスシナリオを説明するための概念図である。図３に示す丸形状のブロック、四角形のブロック、六角形のブロックは、意味的に同等な機能を示し、矢印は、制御の順番を示す。ＢＰＥＬでは、１つ１つのＷＳを厳密に指定した制御フローを記述する必要があるが、サービスシナリオでは、同等なサービスコンポーネントから選択することができる。
【００３５】
ここで、メタデータを用いてサービスシナリオを記述して、サービス連携することを考えた場合、所望する機能にマッチするサービスコンポーネントを数多く検出して利用できることが、多くの候補により選択肢が増え、カスタマイズ性、耐障害性に優れることになり、これを実現するために、以下の３つが必要となる。
【００３６】
（１）サービスシナリオ記述者が個々のサービスコンポーネントの詳細実装を意識せず記述できるよう、統一的形式で記述が可能であること。
（２）既存コンポーネントをそのまま利用できるように、サービスコンポーネントの記述は標準又は練準候補の記述を採用すること。
（３）メタデータの語彙定義を統一的に定めるのは困難であるため、語彙の違いを解決し、同等機能ならば利用可能であること（例：車とｃａｒは両方利用可能）。
【００３７】
次に、機能に関して説明をする。機能とは、ＷＳＤＬやＵＰｎＰｄｏｃなどでネットワークにインターフェースを公開し、そのインターフェースを介して利用可能なメソッドや、イベント等のオペレーションを指す。また、同等機能のサービスコンポーネントとは、ＵＲＬやインターフェースが異なっていても、同様の動作をするサービスコンポーネントのことである（例：５ＦのメーカＡのプリンタと６ＦのメーカＢのプリンタとのＵＲＬは異なるが、動作は同様である）。
【００３８】
上記３つの条件から、サービスコンポーネント記述に近年進んできたＳｅｍａｎｔｉｃＷｅｂ  Ｓｃｒｖｉｃｅｓ技術のＯＷＬ−Ｓ（Web Ontology Language for Services：http://www.daml.org/services）を用いる。ＯＷＬ−Ｓは、３つの記述からなり、Ｐｒｏｆｉｌｅ記述は、どのようなサービスを提供するかを記述し、Ｐｒｏｃｅｓｓ記述は、どのように動作するかの抽象的Ｐｒｏｃｅｓｓの入出力や、条件、効果を記述し、Ｇｒｏｕｎｄｉｎｇ記述は、どのようにアクセスするかの抽象Ｐｒｏｃｅｓｓと実際のオペレーションのマッピングとを記述する。
【００３９】
次に、ＯＷＬ−Ｓを利用する理由を説明する。まず、実際のオペレーションにマッピングされるＰｒｏｃｅｓｓは、ＵＰｎＰ、ＷＳなどに対して中立であり、ユーザは、Ｐｒｏｃｅｓｓを実際のオペレーションのメタデータとして使うことで、サービスコンポーネントの詳細実装を意識せず、サービスシナリオを記述できる。次に、ＯＷＬ−Ｓは、標準候補として挙がっており、将来的には、ＯＷＬ−Ｓで記述されたサービスがネットワークに遍在することが予想されている。また、語彙違いを解決する。メタデータ関係をＯＷＬで記述し、該リンクを辿って解決する方法（後述するサービスコンポーネント選択方法）と親和性が高い。
【００４０】
このような理由から、サービスコンポーネントは、ＯＷＬ−Ｓで記述された情報を、ネットワークに公開することとし、それに対応してサービスシナリオは、以下のように記述する。サービスシナリオは、利用するサービスコンポーネントの機能を、カテゴリ名（同等サービスコンポーネント機能をカテゴライズした単位）とオペレーションメタデータとで指定し、指定した各カテゴリ間の情報引継ぎや、制御ロジックを併せて記述する。ここで、オペレーションメタデータは、ＯＷＬ−ＳのＰｒｏｃｅｓｓとそのパラメータとに相当する。カテゴリ間の情報引継ぎには、前のカテゴリのパラメータを、別カテゴリのどのパラメータに入れるかのマッピングが記述される。制御ロジックとは、オペレーション呼出や、分岐、繰り返し、イベント受信、並列処理など、サービスフローを制御するためのロジックのことで、これらはＢＰＥＬやＰＤ４Ｊなどの制御ロジックと同様である。
【００４１】
本実施形態は、サービスコンポーネントを抽象的に指定し、ユーザ状況に応じて選択可能にすることが特徴であり、サービスコンポーネントの制御ロジックに関しては、従来技術を利用すればよい。例えば、ＢＰＥＬでは、オペレーション呼出は、ｉｎｖｏｋｅ、分岐は、ｓｗｉｔｃｈ、繰り返しは、ｗｈｉｌｅなどの制御タグを用意し、ＢＰＥＬ文書は、ＸＭＬを用いて記述する。サービスシナリオも、ＢＰＥＬと同様にＸＭＬなどの制御タグ言語で記述できる。
【００４２】
＜サービス連携エンジンの構成＞
次に、図４は、本実施形態によるサービス連携エンジンの構成を示すブロック図である。サービス連携エンジン１は、サービスシナリオ設定部１−１、サービスコンポーネント群検出部１−２、サービスコンポーネント選択部１−３及びサービスコンポーネント実行・連携部１−４を備えている。サービスシナリオ設定部１−１は、ユーザ端末７からのサービスシナリオ、またはユーザ端末７により指定され、サービスシナリオＤＢ５から検出したサービスシナリオを設定する。サービスコンポーネント群検出部１−２は、サービスシナリオに記述されたサービスコンポーネントのメタデータを用いて、サービスコンポーネント情報ＤＢ２を検索することで、利用可能な同等サービスコンポーネント群を検索して検出する。
【００４３】
サービスコンポーネント選択部１−３は、サービスコンポーネント群検出部１−２により検出されたサービスコンポーネント群から、ユーザコンテキスト・ポリシＤＢ３に記憶されているユーザ状況に応じたサービスコンポーネントを選択する。サービスコンポーネント実行・連携部１−４は、サービスシナリオに記述された制御ロジックに従って、選択したサービスコンポーネントの実行および連携を行う。
【００４４】
＜サービス連携エンジンによる動作＞
次に、ユーザがサービスを利用する際のフローについて説明する。ここで、図５は、サービス連携エンジンによる動作を説明するための概念図である。ユーザがサービスを利用する際は、ユーザ端末７を用いて、サービスを連携するサービス連携エンジン１に対して、利用したいサービスのサービスシナリオを入力して設定する（Ｓ１）。サービスシナリオの設定は、後述するサービスシナリオ設定方法に従って、自分で記述したサービスシナリオをサービス連携エンジン１に送信してもよいし、サービスシナリオＤＢ５から検出したサービスシナリオを指定してもよい。このときに、ユーザ端末７は、ユーザ識別子もサービス連携エンジン１に送信する。
【００４５】
サービス連携エンジン１は、サービスシナリオ設定部１−１にサービスシナリオが設定されると、サービスコンポーネント群検出部１−２によりサービスシナリオに記述されたサービスコンポーネントのメタデータを用いて、利用可能な同等サービスコンポーネント群を検索して検出する（Ｓ２）。検出する際は、サービスシナリオに記述されたサービスコンポーネントのメタデータをキーとして、サービスコンポーネント情報ＤＢ２を検索することで、そのメタデータにマッチするサービスコンポーネントを検出することができる。
【００４６】
＜サービスコンポーネント群の検出＞
サービスコンポーネント群を検出する際、サービス連携エンジン１は、サービスコンポーネント情報ＤＢ２から、サービスシナリオに記述されたメタデータをキーとして、利用可能なサービスコンポーネント群を検出する。メタデータには、サービスコンポーネントがどのようなカテゴリであるかを表すカテゴリ情報、サービスコンポーネントのオペレーションがどのようなオペレーションであるかを表すアトミックプロセスや、アトミックプロセスの効果、前提条件、入力パラメータのメタデータ、出力パラメータのメタデータなどが含まれる。サービスコンポーネント群が検出される際、メタデータの語彙が異なる場合には（例：ある人は車カテゴリと定義しているが、別の人はｃａｒカテゴリと定義している場合など）、同等機能のサービスコンポーネント群でも検出できない。この場合、オントロジＤＢ４と連携することで、より柔軟な検出が可能であり、詳細は後述する。
【００４７】
サービスコンポーネント情報ＤＢ２は、検出したサービスコンポーネント群のＯＷＬ−ＳのＵＲＬ情報をサービス連携エンジン１に返すことで、サービス連携エンジン１は、そのＵＲＬを用いて、サービスコンポーネント群のメタデータであるＯＷＬ−Ｓを取得できる。なお、ＯＷＬ−Ｓは、サービスコンポーネント提供端末６にて記憶していてもよいし、サービスコンポーネント情報ＤＢ２にて記憶していてもよい。
【００４８】
＜オントロジ解決＞
上述したように、同等機能でも異なる語彙で定義されたメタデータが設定されている場合には（例：車とｃａｒ等）、オントロジＤＢ４に記憶されたメタデータ同士の関係を辿って、語彙変換することで同等機能として検出可能である。語彙変換により、代替候補のサービスコンポーネント数を増やし、検出の柔軟性を確保することができる。
【００４９】
ここで、上記オントロジＤＢ４について説明する。
メタデータの管理は、サービスシナリオ記述者、サービスコンポーネント作成者、ユーザの全てが利用しやすい形でなければならない。そのため、以下の３つが必要となる。
【００５０】
（１）サービスシナリオ記述者が、記述したいサービスシナリオに必要なオペレーションメタデータをすぐに検出、選択が可能である。
（２）サービスコンポーネント作成者が、新機能を作成したときに、新たなオペレーションのメタデータを追加可能である。また、異なる語彙のメタデータの関係を登録することも可能である。
（３）ユーザが、サービスシナリオに基づいてサービスコンポーネントを検索する際、所望する機能と同等機能を持つサービスコンポーネントを全て検索可能である。
【００５１】
これらを実現するため、以下の３つを特徴としたオントロジ管理方法を提案する。
（１）それぞれの目的毎にオペレーションメタデータ群をカテゴライズして管理する。
（２）新しい機能を加えた新カテゴリを登録可能である。異なる語彙で定義したカテゴリ間の関係を記述可能である。
（３）カテゴリ間で、メタデータの関係（同値、継承関係）を双方向にリンクする。
【００５２】
図６は、オントロジ管理方法を説明するための概念図である。ここで、オペレーションメタデータ群を目的毎にカテゴライズしたものをカテゴリと呼ぶ（例：ビデオ、旅行予約カテゴリなど）。図６において、長方形は、カテゴリであり、小文字（ａ１，ａ２、ｂ１、ｂ２、…、ｈ３、ｉ３、ｊ４）は、該カテゴリに属するオペレーションメタデータ、矢印は、メタデータの関係を示す。
【００５３】
例えば、カテゴリＡにいくつかのオペレーションメタデータが定義されているが、新しい機能を作ったサービスコンポーネント作成者がＣというカテゴリを作り、新たなオペレーションメタデータを追加し、既存カテゴリとの継承関係を記述する。これが繰り返されることで、カテゴリツリーが形成される。カテゴリの継承関係だけでなく、異なる語彙のメタデータの同値関係も記述できる（カテゴリＣとＫ）。サービスシナリオ作成者は、オントロジＤＢ４に登録されたメタデータを参照してサービスシナリオを記述する。また、合成エンジンがサービスコンポーネントを検索する際、図６で、サービスシナリオに必要な機能としてメタデータＣ３が記述されている場合には、リンクを辿り、ｃ３かｃ３’を有するＣ、Ｅ、Ｆ、Ｋというカテゴリにマッピングしているサービスコンポーネントが検索される。
【００５４】
このように、サービスコンポーネント作成者がメタデータを追加可能にすることで、業界や、目的毎に、インターフェースを完全共通化する作業を行う必要がない。なお、ルートとなるカテゴリは、誰かが最初に作成する必要があるが、インターネットのサイト（例えば、travelXML http://www.xmlconsortium.org/wg/TravelXML/TravelXML_index.htmlなど）に公開されている、共通化された最小限のメタデータセットを利用するようにしてもよい。サービスコンポーネント作成者が新たな機能を追加してくれるため、自然選択によってユーザに使いやすいカテゴリが普及していくことが期待される。
【００５５】
本実施形態では、オペレーションメタデータにＯＷＬ−ＳのＰｒｏｃｅｓｓを用い、メタデータの同値関係や継承関係をＯＷＬのｅｑｕｉｖａｌｅｎｔＣｌａｓｓ、ｓｕｂＣｌａｓｓＯｆプロパティを用いて記述し、これらが記述されたＯＷＬファイルをオントロジＤＢ４で記憶する形とした。運用方法としては、同値や、継承、新規登録などを、サービスコンポーネント作成者などから登録依頼があった際に、オントロジＤＢ４の管理者が確認後、オントロジＤＢ４に登録する運用を想定している。
【００５６】
このように、ＯＷＬリンクを辿ることで、同等機能のメタデータが分かるため、そのメタデータを用いてサービスコンポーネント情報ＤＢ２を検索することで、利用できるサービスコンポーネント数をさらに増やすことができる。
【００５７】
さらに、上述したオントロジ解決で説明した通り、サービスコンポーネント情報ＤＢ２を検索する際に、オントロジＤＢ４により管理されているメタデータの同値関係や、継承関係を用いることで、メタデータの語彙が異なっていても（例：車とｃａｒなど）、同等なメタデータのサービスコンポーネント群を検出することができる。サービスコンポーネント群を検出した際には、該サービスコンポーネントのメタデータ記述であるＯＷＬ−Ｓをサービスコンポーネント提供端末６、もしくは、サービスコンポーネント情報ＤＢ２より取得する（サービスコンポーネント情報ＤＢ２は、検出の際にＯＷＬ−ＳのＵＲＬをサービス連携エンジン１に返すことで、サービス連携エンジン１は、ＯＷＬ−ＳのＵＲＬを検出でき、ＯＷＬ−Ｓを取得できる）。
【００５８】
次に、サービス連携エンジン１は、サービスコンポーネント選択部１−３により、図５に示すように、検出されたサービスコンポーネント群から適切なサービスコンポーネントを選択する（Ｓ３）。選択する際は、後述するサービスコンポーネント選択方法に従って、ユーザコンテキスト情報とユーザポリシ情報、検出されたサービスコンポーネントのＰｒｏｆｉｌｅ情報とをマッチングすることで、適切なサービスコンポーネントを選択する。ユーザコンテキスト情報、ユーザポリシ情報は、利用するユーザの識別子に基づいて、サービス連携エンジン１がユーザコンテキスト・ポリシＤＢ３より取得する。また、サービスコンポーネントのＰｒｏｆｉｌｅ情報は、ＯＷＬ−Ｓの情報の一部である。なお、他候補がなく、選択する必要がない場合には、サービスコンポーネント選択過程を行わなくて良い。
【００５９】
＜サービスコンポーネント選択方法＞
ここで、上述したサービスコンポーネント選択方法について説明する。
オントロジＤＢ４とＧｒｏｕｎｄｉｎｇ記述とにより、同等機能のサービスコンポーネントを柔軟に検出し、実際のインターフェースに変換して実行することが可能となる。ここでは、検出されたサービスコンポーネント群から、適切なサービスコンポーネントを選択することについて説明する。
【００６０】
状況に応じたサービスを実現するため、利用可能なサービスコンポーネント群から、ユーザ状況に適切なサービスコンポーネントを選択する必要がある。適切なサービスコンポーネントを選択するため、どのようなサービスコンポーネントを優先するかのユーザポリシ情報、ユーザがどのような状況であるかのユーザコンテキスト情報、サービスコンポーネントがどのような性質を持つかのサービスコンポーネントＰｒｏｆｉｌｅ情報の３つの組のマッチングで、サービスコンポーネントに点数を付け、高得点のサービスコンポーネントを自動選択、または、その点数を参考に手動選択してもらうことで、適切なサービスコンポーネントの選択が可能である。
【００６１】
ユーザポリシ、ユーザコンテキスト、サービスコンポーネントＰｒｏｆｉｌｅは、それぞれ、いくつかのデータの重ね合せで表される。位置を例に上げると、ユーザの位置がユーザコンテキストの一部で、サービスコンポーネントの位置がサービスコンポーネントＰｒｏｆｉｌｅの一部であり、近いサービスコンポーネントを優先したいという要望がユーザポリシの一部である。その他にも、例えば、ユーザの所持金がユーザコンテキストの一部で、サービスコンポーネントの利用料がサービスコンポーネントＰｒｏｆｉｌｅの一部であり、安いサービスコンポーネントを優先したいという要望がユーザポリシの一部である。
【００６２】
ここで、図７は、上述した点数付け方法を説明するための概念図である。
まず、ユーザポリシについて説明する。ユーザポリシは、いくつかの評価基準の重ね合わせであり、評価基準として、値段の安さなどの全コンポーネント共通の評価基準と、距離の近さなどカテゴリ種類に応じた評価基準がある。ユーザは、各評価基準に重み付けを設定することで、近さ重視や、安さ重視など、自分用のポリシを設定することができる。
【００６３】
ユーザコンテキストは、位置などのユーザ状況を示すデータの集合であり、ユーザコンテキストファイルとしてユーザコンテキスト・ポリシＤＢ３に記憶される。なお、コンテキスト収集機能として、ＧＰＳ（Global Positioning System）や、温度センサなど色々あるが、これらの実装は本発明対象外とする。本実施形態では、それらから集めた情報や、ユーザが入力した情報が集約された、コンテキストファイルがユーザコンテキスト・ポリシＤＢ３に記憶されているとする。
【００６４】
サービスコンポーネントＰｒｏｆｉｌｅには、ＯＷＬ−ＳのＰｒｏｆｉｌｅのパラメータとして記述されており、サービスコンポーネントの位置や、値段などのサービスコンポーネントのプロパティが記述されている。
【００６５】
各評価基準には、点数付け関数が設定されており、評価基準毎に、サービスコンポーネントのＰｒｏｆｉｌｅとユーザコンテキストとをマッチングすることで点数を付ける。例えば、位置の近さである「ｐｒｏｘｉｍｉｔｙ」評価基準の場合は、ユーザ位置とサービスコンポーネント位置とを用いた、ｅｘｐ（−（ユーザ緯度−サービスコンポーネント緯度）２−（ユーザ経度−サービスコンポーネント経度）２）のような評価式が用いられる。あるいは、単に近い順に点数が高くなるようなシンプルな方法でも良い。
【００６６】
各評価基準の点数は、重みに応じて重ね合わせられ、サービスコンポーネントの総合点が算出される。このように、ユーザは、ポリシを詳細に設定することで、状況に応じてサービスコンポーネントの点数付けをし、サービスコンポーネントの自動選択、または、その点数を参考に手動選択することができる。なお、詳細なポリシ設定を行いたくないユーザには、デフォルトポリシを準備することも可能である。また、サービスコンポーネントのＰｒｏｆｉｌｅ情報が無い場合など、選択するための情報が少ない場合には、ランダムに選択しても良いし、ユーザが手動で選択してもよい。
【００６７】
上述したように、サービスシナリオで利用するサービスコンポーネントが全て選択された後で、サービス連携エンジン１は、サービスコンポーネント実行・連携部１−４により、図５に示すように、サービスシナリオに記述されているメタデータと、選択したサービスコンポーネントのＯＷＬ−ＳのＧｒｏｕｎｄｉｎｇ記述を用いて、サービスコンポーネントの実際のインターフェース（ＷＳＤＬやＵＰｎＰなど）に変換して、サービスシナリオに記述された制御ロジックに基づいて、以下に説明するサービスコンポーネントを実行および連携することで連携サービスを実現する（Ｓ４）。
【００６８】
＜サービスコンポーネント実行方法＞
図８は、プロセスから実際のインターフェースへの変換過程を示す概念図である。サービス連携エンジン１は、サービスシナリオに記述された制御ロジックに従って、サービス実行および連携を行う。前述した通り、制御ロジックには、オペレーション呼出や、パラメータコピー、分岐、繰り返しなどがあるが、制御ロジックの解釈は、ＢＰＥＬなどと同様であるため、サービスシナリオの制御タグに基づいて解釈すればよい。但し、サービスコンポーネントのオペレーション呼出しなどの際は、サービスシナリオにはメタデータで記述されているため、サービスコンポーネントの実際のインターフェースに変換して呼び出す必要がある。
【００６９】
サービスコンポーネントの動作メタデータであるプロセス情報と、サービスコンポーネントの実際のインターフェース（ＷＳＤＬやＵＰｎＰなど）は、ＯＷＬ−ＳのＧｒｏｕｎｄｉｎｇ記述により、マッピングが記述されているため、サービス連携エンジン１がサービスコンポーネントを呼び出す際には、Ｇｒｏｕｎｄｉｎｇ記述を介して、メタデータから実際のインターフェースに合致する変換を行って呼び出すことで連携サービスを実現する。この変換は、オペレーション呼出だけでなく、イベント受信などの場合も同様である。
【００７０】
＜サービスシナリオ設定方法＞
以上のように、サービス連携エンジン１に、サービスシナリオを設定することで、ユーザは、状況に応じて多彩なサービスを利用することができる。ユーザがサービスシナリオを設定する際には、様々な方法を取ることができる。まず、ユーザ白身がサービスシナリオを記述して、記述したサービスシナリオをローカルのサービス連携エンジンに設定する方法がある。次に、記述したサービスシナリオを、ネットワーク８を介して、サービス連携エンジン１に送信して、サービス連携エンジン１に設定、実行させる方法がある。さらに、自分でサービスシナリオを記述しなくても、ネットワーク８上にあるサービスシナリオＤＢ５から利用したいサービスシナリオを検索することもできる。
【００７１】
サービスシナリオＤＢ５からサービスシナリオを検索する際には、サービスシナリオ名、サービスシナリオ作成者名、サービスシナリオ識別子、サービスシナリオジャンル、サービスシナリオ説明などの検索キーを用いて、サービスシナリオを検索する。サービスシナリオＤＢ５から検索したサービスシナリオを、サービス連携エンジン１に送信して設定、実行させても良いし、サービス連携エンジン１には、サービスシナリオ識別子だけ指定して、サービス連携エンジン１からその識別子を用いてサービスシナリオを取得させて実行させることもできる。
【００７２】
ここまでは、サービスシナリオにて、サービスコンポーネントを、メタデータを用いて指定する方法について説明を行った。サービスシナリオ中には、複数のサービスコンポーネントが利用されるわけであるが、利用するサービスコンポーネントのうち、一部、または全てを、メタデータではなく、実際のインターフェース情報で指定することもできる。
【００７３】
ＢＰＥＬでは、全てのサービスコンポーネントがＷＳＤＬに記載されたインターフェース情報で指定されていることを述べた。サービスシナリオでも、サービスコンポーネントを指定する際に、ＷＳＤＬや、ＵＰｎＰなどを直接指定して利用するオペレーションを厳密に記述することもできる。例えば、クレジット決済サービスコンポーネントなど、信頼性が高く要求されるサービスコンポーネントに関しては、ＷＳＤＬ直指定で厳密に記述し、モニタや、レンタカー予約サービスコンポーネントなどは、メタデータで抽象指定するといった形が可能である。
【００７４】
また、全てのサービスコンポーネントをインターフェースで指定する場合には、ＢＰＥＬと同様の動作である。そのため、全てのサービスコンポーネントをインターフェースで指定する場合には、ＢＰＥＬや、ＰＤ４Ｊなどで代用することも可能である。
【００７５】
上述した実施形態において、インターフェース情報で指定された場合には、サービスコンポーネントを検出する際、サービスコンポーネント情報ＤＢ２から、メタデータを用いて検索するのではなく、サービスシナリオに記載されたインターフェース情報を用いて検索する形となる。検索に用いるインターフェース情報とは、例えば、ＷＳの場合には、ポートタイプ名、オペレーション名、入力メッセージ名、出力メッセージ名などである。これらが一致するサービスコンポーネント群を検出する。
【００７６】
また、検出されたサービスコンポーネント群から選択する際、もし、検出されたサービスコンポーネントにＯＷＬ−ＳのＰｒｏｆｉｌｅ情報がある場合には、前述したような点数付け方法で点数を付けて選択してもよいし、Ｐｒｏｆｉｌｅ情報などのメタデータがない場合には、ランダムに選択してもよいし、ユーザが手動選択してもよい。
【００７７】
また、インターフェース情報で指定されたサービスコンポーネントを実行および連携する際には、サービスシナリオのメタデータから実際のインターフェースに変換する必要が無いので、サービスシナリオに記述されたインターフェース情報のまま、制御ロジックに従い、サービスコンポーネントを実行および連携すればよい。
【００７８】
上述した実施形態によれば、ＢＰＥＬの課題を解決するため、サービスシナリオを、個々のサービスコンポーネントのインターフェース情報を用いて記述するのではなく、利用するサービスコンポーネントを、サービスコンポーネントがどのような動作を持つかのメタデータ情報を用いて抽象的に記述することで、インターフェースは異なるが、機能が同等なサービスコンポーネントを検出して選択可能にすることで、ユーザ状況に応じた適切なサービスを提供することができる。
【００７９】
なお、上述した実施形態において、サービス連携エンジン１の各部の機能、すなわち、サービスシナリオ設定部１−１、サービスコンポーネント群検出部１−２、サービスコンポーネント選択部１−３及びサービスコンポーネント実行・連携部１−４は、図示しない記憶部に記憶されたプログラムを実行することで実現するようになっている。記憶部は、ハードディスク装置や光磁気ディスク装置、フラッシュメモリ等の不揮発性メモリやＲＡＭ（Random Access Memory）のような揮発性のメモリ、あるいはこれらの組み合わせにより構成されるものとする。また、上記記憶部とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含む。
【００８０】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワークや電話回線等の通信回線のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、上述した処理の一部を実現するためのものであってもよい。さらに、上述した処理を既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【図面の簡単な説明】
【００８１】
【図１】本発明の実施形態によるサービス連携システムの構成を示すブロック図である。
【図２】サービスシナリオの記述の一例である。
【図３】サービスシナリオを説明するための概念図である。
【図４】サービス連携エンジンの構成を示すブロック図である。
【図５】サービス連携フローを説明するための概念図である。
【図６】オントロジ管理方法を説明するための概念図である。
【図７】点数付け方法を説明するための概念図である。
【図８】プロセスから実際のインターフェースへの変換過程を示す概念図である。
【符号の説明】
【００８２】
１  サービス連携エンジン
２  サービスコンポーネント情報ＤＢ
３  ユーザコンテキスト・ポリシＤＢ
４  オントロジＤＢ
５  サービスシナリオＤＢ
６  サービスコンポーネント提供端末
７  ユーザ端末
８  ネットワーク
１−１  サービスシナリオ設定部
１−２  サービスコンポーネント群検出部
１−３  サービスコンポーネント選択部
１−４  サービスコンポーネント実行・連携部
【図１】
2008130033.tif 000003
【図２】
2008130033.tif 000004
【図３】
2008130033.tif 000005
【図４】
2008130033.tif 000006
【図５】
2008130033.tif 000007
【図６】
2008130033.tif 000008
【図７】
2008130033.tif 000009
【図８】
2008130033.tif 000010