JP5517255B2 - 複数のサービスノードサーバにおけるサービス連結制御方法、制御ノードサーバ及びプログラム - Google Patents

Description

本発明は、ネットワークに分散配置された複数のサービスノードサーバを利用する技術に関する。

ユーザ端末から、ネットワークに接続されたサービスノードサーバを利用する技術として、クラウドコンピューティングやＳＤＰ(Service Delivery Platform)の技術がある。

「クラウドコンピューティング」によれば、計算機資源及びソフトウェアなどのリソースがサービスプロバイダによって提供され、ユーザはネットワークを介してそれらサービスを利用することができる。ユーザにとっては、計算機資源及びソフトウェアを自ら用意する必要がなく、所望サービスを低コスト且つ短時間で利用することができる。一方で、サービスプロバイダにとっては、複数のユーザに対して、リソースを共有且つ効率的に利用させることができる。しかしながら、サービスプロバイダによっては、利用できるサービスに偏りや制限があり、ユーザ個々の所望サービスの全てに対応することが難しい。

「ＳＤＰ」は、ライブラリ（例えば認証機能や通信機能など）によるサービス部品（「イネーブラ」とも称される）を連携することができるサービスプラットフォームを提供するアーキテクチャである。ＳＯＡ(Service Oriented Architecture)に基づいたＳＤＰサーバによれば、サービス部品は、それらの実行順序がＢＰＥＬ(Business Process Execution Language)などで記述されたシナリオに従って連携される。一般的に、サービスプロバイダによってサービス機能毎に専用サーバが備えられている。そのために、ユーザ自ら、サービス部品を自由に作成し、シナリオを自由に記述することによって、それらサービス部品を連結させることができるものではない。

これらに対して、Open APIによってネットワーク上にサービスを構築する、Ｗｅｂアプリケーションの技術がある。代表的にはGoogle API（登録商標）（例えば非特許文献１参照）やYahoo! Pipes（登録商標）（例えば非特許文献２参照）がある。

図１は、従来技術におけるシステム構成図である。

図１のシステムによれば、クライアント用の端末２と、サービス機能を実行する複数のサービスノードサーバ３とが、アクセスネットワーク及びインターネットなどのＩＰネットワークを介して接続されている。端末２は、携帯電話機やスマートフォンであってもよいし、パーソナルコンピュータであってもよい。アクセスネットワークは、例えば携帯電話網や、無線／有線ブロードバンドアクセス網である。サービスノードサーバ３は、Ｗｅｂサーバであって、ユーザ端末のブラウザから呼び出し可能なＡＰＩを公開している。端末２は、ブラウザによってこれらＡＰＩ(Application Programming Interface)を組み合わせることによってサービス部品を連結させて、様々なサービス機能をユーザに提供する。勿論、端末のＷｅｂブラウザを用いることに限られず、一方のＷｅｂサーバから、他方のＷｅｂサーバのＡＰＩを直接的に呼び出すこともできる。

例えばYahoo! Pipes（登録商標）によれば、Ｗｅｂサーバにスクリプトを記述することなく、Open APIをGUI上で組み合わせるだけで、ユーザは、簡単にサービスを構築することができる。具体的には、Ajax(Asynchronous JavaScript＋XML)によるグラフィカルユーザインタフェースを持った「Pipes Editor」上で、「モジュール」をドラッグして「パイプ」で接続する。そして、異なる「ソース」から取得した情報を、どのように加工（例えばフィルタリング）すべきかのルールを設定する。

松田惇、「WebサービスAPIで構築するWebアプリケーション」、ThinkIT、２００６年６月２９日、[online]、［平成２２年８月１５日検索］、インターネット＜URL:http://thinkit.co.jp/free/article/0606/17/＞ 「Yahoo!Pipes」、[online]、［平成２２年８月１５日検索］、インターネット＜URL:http://pipes.yahoo.com/pipes/＞

前述した従来技術によれば、クライアント用の端末が、Open APIを提供する複数のサービスノードサーバへ分散的にサービス要求メッセージを送信し、その応答メッセージに含まれる実行結果データを連結させるものであった。１つの端末から、集中的に多数のＡＰＩを呼び出しているために、ネットワーク上で転送される通信データ量が大きくなるという課題があった。

また、クライアント用の端末によって取り扱われるデータ量が大きい場合（例えばストリーミングデータである場合）、それらデータが端末と各サービスノードサーバとの間を行き来し、ネットワーク上には大量のトラフィックが発生することとなる。

これに対して、分散コンピューティングにおけるクローズなネットワーク環境の場合、ネットワーク上の複数のサービス機能の間でデータを直接的に送受信する仕組みがある。しかしながら、オープンなネットワーク環境の場合、サービス機能（例えばシェアウェア、フリーソフトやアプレット）を公開するサードパーティには、サービスプロバイダに関わらず、多数のユーザ個人も含まれる。また、通信プロトコルも、ＨＴＴＰ(HyperText Transfer Protocol)やＦＴＰ(File Transfer Protocol)のように様々なものが用いられる。そのために、複数のサービス機能の間で、順次にデータを送受信しながら連携して動作させることも難しい。

そこで、本発明は、ネットワーク上に分散された複数のサービスノードサーバについて、端末に対するＡＰＩを含む様々なサービス機能を連結させて１つのサービス機能を提供することができるサービス連結制御方法、制御ノードサーバ及びプログラムを提供することを目的とする。

本発明によれば、クライアント用の端末と、サービス機能を実行する複数のサービスノードサーバと、複数のサービスノードサーバにおけるサービス機能を管理する制御ノードサーバとが、ネットワークを介して相互に通信するシステムにおけるサービス連結制御方法であって、
端末が、ユーザ所望のサービスに必要なパラメータを含むサービス開始要求を、制御ノードサーバへ送信する第１のステップと、
制御ノードサーバが、サービス開始要求に基づくサービスを提供するために必要な複数のサービスノードサーバの実行シナリオを決定する第２のステップと、
制御ノードサーバが、当該実行シナリオの中で最初に実行すべき第１のサービスノードサーバへ、実行シナリオに基づくサービス開始要求を送信する第３のステップと、
第１のサービスノードサーバが、当該サービス機能を実行し、サービス応答を制御ノードサーバへ送信する第４のステップと、
制御ノードサーバが、実行シナリオの中で最後に実行すべき最終実行サービスノードサーバへ、実行シナリオに基づくサービス開始要求を送信する第５のステップと、
最終実行サービスノードサーバが、実行シナリオに基づく先の実行サービスノードから取得した先の実行結果を用いて当該サービス機能を実行し、サービス応答を制御ノードサーバへ送信する第６のステップと、
制御ノードサーバが、実行シナリオに含まれる全てのサービスノードサーバからサービス応答を受信した場合、サービス開始応答を端末へ返信する第７のステップと、
端末が、最終実行サービスノードサーバへアクセスする第８のステップと、
最終実行サービスノードサーバが、一連の実行結果に基づくサービス応答を端末へ返信する第９のステップと
を有することを特徴とする。

本発明のサービス連結制御方法における他の実施形態によれば、
第２のステップについて、
制御ノードサーバが、実行シナリオに含まれる全てのサービスノードサーバへ、実行すべきパラメータを含む問合せ要求を送信し、
サービスノードサーバが、処理可能か否かを含む問合せ応答を、制御ノードサーバへ返信し、
制御ノードサーバが、実行シナリオに含まれる全てのサービスノードサーバについて処理可能となるように、実行シナリオを決定することも好ましい。

本発明のサービス連結制御方法における他の実施形態によれば、
最終のステップについて、
端末が、サービス終了要求を、制御ノードサーバへ送信し、
制御ノードサーバが、サービス終了要求を、実行シナリオに含まれる全てのサービスノードサーバへ送信し、
サービスノードサーバが、サービスを終了すると共に、サービス終了応答を制御ノードサーバへ返信し、
制御ノードサーバが、端末へ、サービス終了応答を返信し、
端末が、ユーザ操作に応じて当該サービスにおける評価値を取得し、当該評価値を、制御ノードサーバへ送信し、
制御ノードサーバが、実行シナリオに対応付けて評価値を蓄積することも好ましい。

本発明のサービス連結制御方法における他の実施形態によれば、
制御ノードサーバは、実行シナリオに対応付けた評価値に基づいて、各サービスノードサーバの評価値を導出し、
第２のステップについて、制御ノードサーバが、評価値が高くなるように、実行シナリオを決定することも好ましい。

本発明のサービス連結制御方法における他の実施形態によれば、
端末と、複数のサービスノードサーバと、制御ノードサーバとは、サービス指向アーキテクチャ(ＳＯＡ(Service Oriented Architecture))によってサービス機能が部品化されており、
サービスノードサーバは、制御ノードサーバ及び他のサービスノードサーバに対してＡＰＩ(Application Programming Interface)を提供しており、
端末と、複数のサービスノードサーバと、制御ノードサーバとの間は、プロキシベースの要求メッセージ／応答メッセージを交換することによって実現されていることも好ましい。

本発明によれば、クライアント用の端末と、サービス機能を実行する複数のサービスノードサーバとの間で、ネットワークを介して相互に通信すると共に、複数のサービスノードサーバにおけるサービス機能を管理する制御ノードサーバであって、
端末から、ユーザ所望のサービスに必要なパラメータを含むサービス開始要求を受信するサービス開始要求受信手段と、
サービス開始要求に基づくサービスを提供するために必要な複数のサービスノードサーバの実行シナリオを決定するサービス構成制御手段と、
実行シナリオの実行順序に基づいて、実行すべき全てのサービスノードサーバへサービス開始要求を送信するサービス開始要求送信手段と、
実行シナリオに含まれる全てのサービスノードサーバから、サービス応答を受信するサービス開始応答受信手段と、
実行シナリオに含まれる全てのサービスノードサーバから、サービス応答を受信した後、サービス開始応答を端末へ返信するサービス開始応答返信手段と
を有し、
端末が、実行シナリオの中で最後に実行された最終実行サービスノードサーバへアクセスし、最終実行サービスノードサーバが、実行シナリオに基づいて連結されたサービス応答を端末へ返信するように動作させることを特徴とする。

本発明のサービス連結制御用の制御ノードサーバにおける他の実施形態によれば、
実行シナリオに含まれる全てのサービスノードサーバへ、実行すべきパラメータを含む問合せ要求を送信すると共に、全てのサービスノードサーバから、処理可能か否かを含む問合せ応答を受信する問合せ処理手段を更に有し、
サービス構成制御手段は、実行シナリオに含まれる全てのサービスノードサーバについて処理可能となるように、実行シナリオを決定することも好ましい。

本発明のサービス連結制御用の制御ノードサーバにおける他の実施形態によれば、
端末からサービス終了要求を受信すると共に、端末へサービス終了応答を返信する端末側サービス終了処理手段と、
端末からサービス終了要求を受信した際に、サービス終了要求を、実行シナリオに含まれる全てのサービスノードサーバへ送信し、全てのサービスノードサーバからサービス終了応答を受信するサーバ側サービス終了処理手段と、
端末から、ユーザ操作に応じた当該サービスにおける評価値を受信するサービス評価値受信手段と、
実行シナリオに対応付けて評価値を蓄積するサービス評価値蓄積手段と
を有することも好ましい。

本発明のサービス連結制御用の制御ノードサーバにおける他の実施形態によれば、
実行シナリオに対応付けた評価値に基づいて、各サービスノードサーバの評価値を導出する評価値解析手段を更に有し、
サービス構成制御手段は、評価値が高くなるように、実行シナリオを決定することも好ましい。

本発明のサービス連結制御用の制御ノードサーバにおける他の実施形態によれば、
複数のサービスノードサーバとの間で、サービス指向アーキテクチャ(ＳＯＡ)によってサービス機能が部品化されており、
サービスノードサーバによって提供されたＡＰＩを用いて、端末及び複数のサービスノードサーバとの間で、プロキシベースの要求メッセージ／応答メッセージを交換することによって実現されていることも好ましい。

本発明によれば、クライアント用の端末と、サービス機能を実行する複数のサービスノードサーバとの間で、ネットワークを介して相互に通信すると共に、複数のサービスノードサーバにおけるサービス機能を管理する制御ノードサーバに搭載されたコンピュータを機能させるプログラムであって、
端末から、ユーザ所望のサービスに必要なパラメータを含むサービス開始要求を受信するサービス開始要求受信手段と、
サービス開始要求に基づくサービスを提供するために必要な複数のサービスノードサーバの実行シナリオを決定するサービス構成制御手段と、
実行シナリオの実行順序に基づいて、実行すべき全てのサービスノードサーバへサービス開始要求を送信するサービス開始要求送信手段と、
実行シナリオに含まれる全てのサービスノードサーバから、サービス応答を受信するサービス開始応答受信手段と、
実行シナリオに含まれる全てのサービスノードサーバから、サービス応答を受信した後、サービス開始応答を端末へ返信するサービス開始応答返信手段と
してコンピュータを機能させ、
端末が、実行シナリオの中で最後に実行された最終実行サービスノードサーバへアクセスし、最終実行サービスノードサーバが、実行シナリオに基づいて連結されたサービス応答を端末へ返信するように動作させることを特徴とする。

本発明のサービス連結制御方法、制御ノードサーバ及びプログラムによれば、ネットワーク上に分散された複数のサービスノードサーバについて、端末に対するＡＰＩを含む様々なサービス機能を連結させて１つのサービス機能を提供することができる。

従来技術におけるシステム構成図である。 本発明におけるシステム構成図である。 本発明におけるサービス開始時のシーケンス図である。 サービス終了時のシーケンス図である。 本発明における制御ノードサーバの機能構成図である。

以下、本発明の実施の形態について、図面を用いて詳細に説明する。

図２は、本発明におけるシステム構成図である。

図２によれば、図１と比較して、インターネットに、制御ノードサーバ１が更に接続されている。制御ノードサーバ１は、端末２及び複数のサービスノードサーバ３と、インターネットを介して通信する。制御ノードサーバ１は、複数のサービスノードサーバ３におけるサービス機能を管理する。サービス機能としては、例えば認証機能、データ取得機能、コーデック機能、プレゼンス機能、グループ機能、呼制御機能、メディア制御機能等様々なものである。

端末２は、ユーザ操作に基づく所望サービスについて、制御ノードサーバ１へ、サービス開始要求を送信する。これに対して、制御ノードサーバ１は、その所望サービスに応じて、複数のサービスノードサーバ３のサービス機能を連結する実行シナリオを決定する。その実行シナリオに基づいて、複数のサービスノードサーバ３のサービス機能を、順次に連結して構成する。そして、最終実行サービスノードサーバに、これら連結されたサービス結果が集約される。端末２は、その最終実行サービスノードサーバに対してアクセスし、所望サービスの提供を受けることができる。

複数のサービスノードサーバ３それぞれのサービス機能は、サービス指向アーキテクチャ(ＳＯＡ(Service Oriented Architecture))によって部品化されている。各サービス機能は、Ｗｅｂアプリケーションをベースとして、クライアントのブラウザから利用可能なＡＰＩを提供する。従って、サービスノードサーバ３は、制御ノードサーバ１及び他のサービスノードサーバ３に対して、自ら実装しているサービス機能のＡＰＩ(Application Programming Interface)を公開する。そして、制御ノードサーバ１等は、そのＡＰＩに対してサービス開始要求を送信する。また、制御ノードサーバ１と、端末２と、複数のサービスノードサーバ３との間は、プロキシベースの要求メッセージ／応答メッセージを交換することによって実現されている。

尚、サービスノードサーバ３は、サーバであるが、ブラウザを搭載したクライアントソフトウェアであってもよい。例えばJava Script（登録商標）によってサービス機能を記述することによって、ブラウザのページを開くと同時に、制御ノードサーバ１へそのブラウザを登録することが考えられる。この場合、ブラウザを開くだけで、計算機資源を含むサービス機能を提供することができる。

図３は、本発明におけるサービス開始時のシーケンス図である。

（Ｓ３００）各サービスノードサーバ３は、自ら提供するサービス機能やＩＰアドレス等のアクセス情報を、制御ノードサーバ１へ登録する。制御ノードサーバ１は、サービスノードサーバ３がネットワークから切り離された場合やそのサービス機能が停止された場合、そのアクセス情報を解除する。

（Ｓ３０１）端末２が、ユーザ所望のサービスに必要なパラメータを含むサービス開始要求を、アクセスネットワーク及びインターネットを介して、制御ノードサーバ１へ送信する。サービス開始要求は、例えばＸＭＬ(eXtensible Markup Language)によって記述される。

例えば、端末２が、当該端末で表示可能な最高品質のストリーミングデータの受信におけるサービス開始要求を、制御ノードサーバ１へ送信したとする。このとき、サービス開始要求は、以下のパラメータを含む。
（１）端末がサポートするコーデック
（２）端末の解像度
（３）端末が利用可能なネットワーク帯域
（４）所望のストリーミング名
［サービス開始要求］端末２->制御ノードサーバ１
<ServiceRequest>
<clientInfo address="205.132.6.2" phone="9737159569" vendor="・・・"
email="kddi@mail.com"/>
<service name="streamviewer">
<attribute source="http://stream.server.com/movie1.wmv" / >
<attribute supportcodec="mpeg4v2"/>
<attribute supportcodec="h.264"/>
<attribute required_protocol="rtsp"/>
<attribute resolution_h="800"/>
<attribute resolution_w="600"/>
<attribute bandwith="1500000"/>
</ service >
</ ServiceRequest >

（Ｓ３０２）次に、制御ノードサーバ１は、サービス開始要求に基づくサービスを提供するために必要な複数のサービスノードサーバの実行シナリオを決定する。図３によれば、制御ノードサーバ１は、３つのサービスノードdmz-f2〜f4のサービス機能を管理する。

サービスノードサーバdmz-f2〜f4は、以下のようなサービス機能を提供しているとする。
［dmz-f2］ストリーミング名に基づいて、ストリーミングサーバやキャッシュサーバを検索し、そのストリーミングデータを送信する機能
［dmz-f3］文書ファイルのフォーマットを変換する機能
［dmz-f4］ストリーミングデータのコーデックを変換する機能

このとき、制御ノードサーバ１は、以下のように実行シナリオを決定する。
［実行シナリオ］
<routes>
<route name=" task1">
<stop host="dmz-f4" input="rstp " operation="convert" output="rstp"/>
<convert input_format="mpeg4"/>
<convert output_format="h.264"/>
</route>
<route name=" task2">
<stop host=" dmz-f2" operation="streaming " output="rstp"/>
<streaming source="http://stream.server.com/movie1.wmv"/>
<streaming format="mpeg4"/>
</route>

この実行シナリオは、サービスノードサーバdmz-f2によってストリーミングデータを取得し、そのストリーミングデータをサービスノードサーバdmz-f4へ送信する。サービスノードサーバdmz-f4は、そのストリーミングデータを所定のコーデックへ変換し、端末２からアクセスを待つ。また、実装されたそのサービス機能を一意に識別するためのサービス識別子を生成する。

ここで、制御ノードサーバ１は、実行シナリオに含まれる全てのサービスノードサーバへ、実行すべき処理内容を含む問合せ要求を送信する。図３によれば、制御ノードサーバ１は、サービスノードサーバdmz-f2及びdmz-f4へ、処理内容のパラメータを含む問合せ要求を送信する。これに対し、各サービスノードサーバdmz-f2及びdmz-f4は、処理可能か否かを含む問合せ応答を、制御ノードサーバ２へ返信する。

（Ｓ３０３）制御ノードサーバ１は、実行シナリオに含まれる全てのサービスノードサーバ３から処理可能となる問合せ応答を受信した場合、サービス開始応答を、端末２へ返信する。可能な実行シナリオが複数ある場合は、ここで複数のシナリオリストをユーザへ返答し、ユーザの選択を待つ。それぞれのシナリオは、各サービスノードの処理能力や利用料金などがあり、これをユーザに表示する。尚、所望サービスを提供できない場合、例えば実行シナリオに基づくサービスノードサーバが処理可能でない場合、サービス提供が不可能である旨を、サービス開始応答によって返信する。この場合、端末２は、再度、サービス開始要求を送信する。これは、所望サービスの提供が可能となるまで繰り返される。

端末２は、次のサービス提供通知（Ｓ３３１）を受信するまで待機する。サービス提供通知には、サービス開始応答には、サービス開始要求に基づく連結されたサービス機能が、いずれのサービスノードサーバに実装されているかを表すアドレス（例えばＵＲＬ(Uniform Resource Locator)）を含む。ここでは、実行シナリオについて、最終実行サービスノードのアドレスが指定される。

（Ｓ３１１）制御ノードサーバ１は、実行シナリオの中で最初に実行すべきサービスノードサーバdmz-f2へ、実行シナリオに基づくサービス開始要求を送信する。サービス開始要求には、例えば以下のパラメータが含まれる。
（１）サービス識別子
（２）ストリーミング名
（３）再配信のためのＵＲＬ
［サービス開始要求］制御ノードサーバ１->サービスノードサーバdmz-f2
<jobRequest>
<job number="dmz-f1.0.775593988532"/>
<clientInfo address="205.132.6.2" email="kddi@mail.com"
phone="9737159569" vendor="・・・"/>
<route name="task2">
<stop host="dmz-f2" operation="streaming " output="rstp"/>
<streaming source="http://stream.server.com/movie1.wmv"/>
<streaming format="mpeg4"/>
</route>
</jobRequest>

（Ｓ３１２）サービスノードサーバdmz-f2は、制御ノードサーバ１へ、処理開始の旨を表すサービス開始応答を返信する。

（Ｓ３１３）次に、サービスノードサーバdmz-f2は、当該サービス機能を実行する。例えば、サービスノードサーバdmz-f2は、所定のストリーミングデータをネットワーク上で検索し、そのストリーミングデータをダウンロードを開始する。

（Ｓ３１４）そして、サービスノードサーバdmz-f2は、制御ノードサーバ１へ、サービス完了通知を送信する。例えばストリーミングのように、データが長期間に渡って処理されるサービスの場合、全データの処理完了を待たずに開始完了通知を送信してもよい。サービス開始完了通知には、例えば以下のパラメータが含まれる。
（１）サービス識別子
（２）成功／失敗
（３）コーデック
（４）サービスノードdmz-f2におけるストリーミングデータを送信するＵＲＬ
（５）再配信のためのＵＲＬ
［サービス完了通知］サービスノードサーバdmz-f2->制御ノードサーバ１
<jobResponse>
<job number="dmz-f1.0.775593988532"/>
<clientInfo address="205.132.6.2" email="kddi@mail.com"
phone="9737159569" vendor="・・・"/>
<status host="dmz-f2" ret="success"/>
<output url="rstp://stream.service2.com/3123dDe33ddefadf/"/>
</jobResponse>

（Ｓ３２１）制御ノードサーバ１は、実行シナリオの中で次に実行すべきサービスノードサーバdmz-f4（図３によれば最終実行サービスノードサーバ）へ、実行シナリオに基づくサービス開始要求を送信する。サービス開始要求には、例えば以下のパラメータが含まれる。
（１）サービス識別子
（２）サービスノードdmz-f2におけるストリーミングデータを送信するＵＲＬ
（３）再配信のためのＵＲＬ
［サービス開始要求］制御ノードサーバ１->サービスノードサーバdmz-f4
<jobRequest>
<job number="dmz-f1.0.775593988532"/>
<clientInfo address="205.132.6.2" email="kddi@mail.com"
phone="9737159569" vendor="・・・"/>
<route name=" task1">
<stop host="dmz-f4" input="rstp " operation="convert" output="rstp"/>
<convert input_format="mpeg4"/>
<convert output_format="h.264"/>
<convert input url=" rstp://stream.service2.com/3123dDe33ddefadf/"/>
<convert output url="*"/>
</route>

（Ｓ３２２）サービスノードサーバdmz-f4は、制御ノードサーバ１へ、処理開始の旨を表すサービス開始応答を返信する。

（Ｓ３２３）次に、サービスノードサーバdmz-f4は、当該サービス機能を実行する。ここで、サービスノードサーバdmz-f4は、サービスノードサーバdmz-f2のＵＲＬから、所定のストリーミングデータを取得し、サービスノードサーバdmz-f4は、そのストリーミングデータを所定のコーデックへ変換を開始する。

（Ｓ３２４）サービスノードサーバdmz-f2は、制御ノードサーバ１へ、サービス開始完了通知を送信する。例えばストリーミングのように、データが長期間に渡って処理されるサービスの場合は、全データの処理完了を待たずに開始完了通知を送信してもよい。サービス完了通知には、例えば以下のパラメータが含まれる。
（１）サービス識別子
（２）成功／失敗
［サービス完了通知］サービスノードサーバdmz-f4->制御ノードサーバ１
<jobResponse>
<job number="dmz-f1.0.775593988532"/>
<clientInfo address="205.132.6.2" email="kddi@mail.com"
phone="9737159569" vendor="・・・"/>
<status host="servce#2" ret="success"/>
<output url="rstp://stream.converter.com/39fasdf313ddfee1111/"/>
</jobResponse>

サービスノードサーバdmz-f4は、端末２からのサービス要求を待つ。尚、図３によれば、２段のサービスノードサーバのサービス機能が連結されているが、勿論、何段連結されてもよい。

（Ｓ３３１）制御ノードサーバ１は、実行シナリオに含まれる全てのサービスノードサーバからサービス応答を受信した場合、サービス提供通知を端末２へ返信する。サービス提供通知には、端末２が、最終実行サービスノードサーバにアクセスするために必要な情報が含まれる。例えば、次の情報が含まれる。
（１）サービス識別子
（２）サービスノードdmz-f4におけるストリーミングデータの送信のＵＲＬ
（３）サービスノードにアクセスする手段、プロトコル

（Ｓ３３２）端末２が、指定されたアドレス先となる最終実行サービスノードサーバdmz-f4へ、ＲＴＳＰ(Real Time Streaming Protocol)などの指定のプロトコルでアクセスする。

（Ｓ３３３）最終実行サービスノードサーバdmz-f4が、一連のサービスノードの実行結果に基づくサービス応答を端末２へ返信する。これによって、端末２は、連結サービス機能の提供を受けることができる。

図４は、サービス終了時のシーケンス図である。

（Ｓ４０１）端末２は、サービス終了要求を、制御ノードサーバ１へ送信する。サービス終了要求には、終了すべきサービスのサービス識別子が含められる。
（Ｓ４０２）制御ノードサーバ１は、サービス識別子に基づく実行シナリオに含まれる複数のサービスノードサーバに対して、サービス終了要求を送信する。図４によれば、制御ノードサーバ１は、サービスノードサーバdmz-f2及びdmz-f4へ、サービス終了要求を送信する。
（Ｓ４０３）サービスノードサーバdmz-f2及びdmz-f4は、サービス終了要求に含まれるサービス識別子に基づくサービスを終了する。そして、サービス終了応答を、制御ノードサーバ１へ送信する。
（Ｓ４０４）制御ノードサーバ１は、全てのサービスノードサーバからサービス終了応答を受信した際に、端末２へサービス終了応答を返信する。

（Ｓ４１１）ここで、端末２は、ユーザ操作に応じて当該サービスにおける評価値を取得する。「評価値」とは、提供されたサービス機能に対するユーザの評価であって、実行時間又は品質情報であってもよい。評価値は、ユーザ自身が端末２へ入力するものであってもよいし、実行時間であれば自動的に計測することができる。この評価値は、端末２から制御ノードサーバ１へ送信される。制御ノードサーバ１は、実行シナリオに対応付けて評価値を蓄積する。そして、制御ノードサーバ１は、実行シナリオに対応付けた評価値に基づいて、連結された各サービス機能の評価値を導出する。

制御ノードサーバ１は、Ｓ３０２について、評価値が高くなるように実行シナリオを決定する。これによって、複数のサービス機能の中でも、評価値が高いサービス機能を用いて、実行シナリオを構成することができる。

図５は、本発明における制御ノードサーバの機能構成図である。

制御ノードサーバ１は、通信インタフェース１０と、サービス構成制御部１００と、サービス開始要求受信部１０１と、サービス開始応答返信部１０２と、問合せ処理部１０３と、サービス開始要求送信部１０４と、サービス開始応答受信部１０５と、端末側サービス終了処理部１０６と、サーバ側サービス終了処理部１０７と、サービス評価値受信部１０８と、評価値解析部１０９と、サービス評価値蓄積部１１０と、サービスノード管理部１１１とを有する。通信インタフェースを除くこれら機能構成部は、サーバに搭載されたコンピュータを機能させる制御ノード用プログラムを実行することによって実現される。

通信インタフェース１０は、インターネットに接続され、端末２及び複数のサービスノードサーバ３と通信する。

サービス構成制御部１００は、サービス開始要求に基づくサービスを提供するために必要な複数のサービスノードサーバの実行シナリオを決定する。サービス構成制御部１００は、サービス評価値蓄積部１１０と、サービスノード管理部１１１とを含む。サービス評価値蓄積部１１０には、ユーザによって実行された連結サービス機能に関連する実行シナリオに対応付けて、評価値が蓄積されている。サービス構成制御部１００は、評価値が所定閾値以上低い実行シナリオが決定されないようにする。また、サービスノード管理部１１１は、サービスノードサーバにおけるサービス機能に関する情報を蓄積する。

サービス開始要求受信部１０１は、端末２から、ユーザ所望のサービスに必要なパラメータを含むサービス開始要求を受信する。受信したサービス開始要求に含まれるパラメータは、サービス構成制御部１００へ出力される。

サービス開始応答返信部１０２は、実行シナリオに含まれる全てのサービスノードサーバからサービス開始応答を受信した後、サービス構成制御部１００の指示に応じて、サービス開始応答を端末２へ返信する。

問合せ処理部１０３は、実行シナリオに含まれる全てのサービスノードサーバへ、実行すべきパラメータを含む問合せ要求を送信すると共に、全てのサービスノードサーバから、処理可能か否かを含む問合せ応答を受信する。これによって、サービス構成制御部１００は、実行シナリオに含まれる全てのサービスノードサーバについて処理可能となるように、実行シナリオを決定する。

サービス開始要求送信部１０４は、実行シナリオの実行順序に基づいて、実行すべき全てのサービスノードサーバへサービス開始要求を送信する。

サービス開始応答受信部１０５は、実行シナリオに含まれる全てのサービスノードサーバから、サービス応答を受信する。

端末側サービス終了処理部１０６は、端末からサービス終了要求を受信すると共に、端末へサービス終了応答を返信する。

サーバ側サービス終了処理部１０７は、端末からサービス終了要求を受信した際に、サービス終了要求を、実行シナリオに含まれる全てのサービスノードサーバへ送信し、全てのサービスノードサーバからサービス終了応答を受信する。

サービス評価値受信部１０８は、端末２から、ユーザ操作に応じた当該サービスにおける評価値を受信する。

評価値解析部１０９は、実行シナリオに対応付けた評価値に基づいて、各サービスノードサーバの評価値を導出する。

端末２は、実行シナリオの中で最後に実行された最終実行サービスノードサーバへサービス要求を送信する。そして、最終実行サービスノードサーバが、実行シナリオに基づいて連結されたサービス応答を、端末２へ返信する。

以上、詳細に説明したように、本発明のサービス連結制御方法、制御ノードサーバ及びプログラムによれば、ネットワーク上に分散された複数のサービスノードサーバについて、端末に対するＡＰＩを含む様々なサービス機能を連結させて１つのサービス機能を提供することができる。特に、本発明によれば、専用の通信プロトコルを用いることなく、オープンなネットワーク環境で、ユーザ個人によって公開されたサービス機能を自由に連結させることができる。また、通信データ量が大量であっても、処理すべきデータはサービスノードサーバ間で転送されるので、最終データ以外は、クライアント用の端末まで転送されない。これは、ネットワークの負荷を低減する。

前述した本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。

１ 制御ノードサーバ
１０ 通信インタフェース
１００ サービス構成制御部
１０１ サービス開始要求受信部
１０２ サービス開始応答返信部
１０３ 問合せ処理部
１０４ サービス開始要求送信部
１０５ サービス開始応答受信部
１０６ 端末側サービス終了処理部
１０７ サーバ側サービス終了処理部
１０８ サービス評価値受信部
１０９ 評価値解析部
１１０ サービス評価値蓄積部
１１１ サービスノード管理部
２ 端末
３ サービスノードサーバ

Claims (11)

1. クライアント用の端末と、サービス機能を実行する複数のサービスノードサーバと、複数のサービスノードサーバにおける前記サービス機能を管理する制御ノードサーバとが、ネットワークを介して相互に通信するシステムにおけるサービス連結制御方法であって、
   前記端末が、ユーザ所望のサービスに必要なパラメータを含むサービス開始要求を、前記制御ノードサーバへ送信する第１のステップと、
   前記制御ノードサーバが、前記サービス開始要求に基づくサービスを提供するために必要な複数のサービスノードサーバの実行シナリオを決定する第２のステップと、
   前記制御ノードサーバが、当該実行シナリオの中で最初に実行すべき第１のサービスノードサーバへ、前記実行シナリオに基づくサービス開始要求を送信する第３のステップと、
   第１のサービスノードサーバが、当該サービス機能を実行し、サービス応答を前記制御ノードサーバへ送信する第４のステップと、
   前記制御ノードサーバが、前記実行シナリオの中で最後に実行すべき最終実行サービスノードサーバへ、前記実行シナリオに基づくサービス開始要求を送信する第５のステップと、
   前記最終実行サービスノードサーバが、前記実行シナリオに基づく先の実行サービスノードから取得した先の実行結果を用いて当該サービス機能を実行し、サービス応答を前記制御ノードサーバへ送信する第６のステップと、
   前記制御ノードサーバが、前記実行シナリオに含まれる全てのサービスノードサーバから前記サービス応答を受信した場合、サービス開始応答を前記端末へ返信する第７のステップと、
   前記端末が、前記最終実行サービスノードサーバへアクセスする第８のステップと、
   前記最終実行サービスノードサーバが、当該サービス機能を実行すると共に、一連のサービスノードの実行結果に基づくサービス応答を前記端末へ返信する第９のステップと
   を有することを特徴とするサービス連結制御方法。
2. 第２のステップについて、
   前記制御ノードサーバが、前記実行シナリオに含まれる全てのサービスノードサーバへ、実行すべきパラメータを含む問合せ要求を送信し、
   前記サービスノードサーバが、処理可能か否かを含む問合せ応答を、前記制御ノードサーバへ返信し、
   前記制御ノードサーバが、前記実行シナリオに含まれる全てのサービスノードサーバについて処理可能となるように、前記実行シナリオを決定する
   ことを特徴とする請求項１に記載のサービス連結制御方法。
3. 最終のステップについて、
   前記端末が、サービス終了要求を、前記制御ノードサーバへ送信し、
   前記制御ノードサーバが、サービス終了要求を、前記実行シナリオに含まれる全てのサービスノードサーバへ送信し、
   前記サービスノードサーバが、サービスを終了すると共に、サービス終了応答を前記制御ノードサーバへ返信し、
   前記制御ノードサーバが、前記端末へ、サービス終了応答を返信し、
   前記端末が、ユーザ操作に応じて当該サービスにおける評価値を取得し、当該評価値を、前記制御ノードサーバへ送信し、
   前記制御ノードサーバが、前記実行シナリオに対応付けて前記評価値を蓄積する
   ことを特徴とする請求項１又は２に記載のサービス連結制御方法。
4. 前記制御ノードサーバは、前記実行シナリオに対応付けた評価値に基づいて、各サービスノードサーバの評価値を導出し、
   第２のステップについて、前記制御ノードサーバが、評価値が高くなるように、前記実行シナリオを決定する
   ことを特徴とする請求項３に記載のサービス連結制御方法。
5. 前記端末と、前記複数のサービスノードサーバと、前記制御ノードサーバとは、サービス指向アーキテクチャ(ＳＯＡ(Service Oriented Architecture))によってサービス機能が部品化されており、
   前記サービスノードサーバは、前記制御ノードサーバ及び他のサービスノードサーバに対してＡＰＩ(Application Programming Interface)を提供しており、
   前記端末と、前記複数のサービスノードサーバと、前記制御ノードサーバとの間は、プロキシベースの要求メッセージ／応答メッセージを交換することによって実現されている
   ことを特徴とする請求項１から４のいずれか１項に記載のサービス連結制御方法。
6. クライアント用の端末と、サービス機能を実行する複数のサービスノードサーバとの間で、ネットワークを介して相互に通信すると共に、複数のサービスノードサーバにおける前記サービス機能を管理する制御ノードサーバであって、
   前記端末から、ユーザ所望のサービスに必要なパラメータを含むサービス開始要求を受信するサービス開始要求受信手段と、
   前記サービス開始要求に基づくサービスを提供するために必要な複数のサービスノードサーバの実行シナリオを決定するサービス構成制御手段と、
   前記実行シナリオの実行順序に基づいて、実行すべき全てのサービスノードサーバへサービス開始要求を送信するサービス開始要求送信手段と、
   前記実行シナリオに含まれる全てのサービスノードサーバから、サービス応答を受信するサービス開始応答受信手段と、
   前記実行シナリオに含まれる全てのサービスノードサーバから、サービス応答を受信した後、サービス開始応答を前記端末へ返信するサービス開始応答返信手段と
   を有し、
   前記端末が、前記実行シナリオの中で最後に実行された最終実行サービスノードサーバへアクセスし、前記最終実行サービスノードサーバが、前記実行シナリオに基づいて連結されたサービス応答を前記端末へ返信するように動作させることを特徴とするサービス連結制御用の制御ノードサーバ。
7. 前記実行シナリオに含まれる全てのサービスノードサーバへ、実行すべきパラメータを含む問合せ要求を送信すると共に、全てのサービスノードサーバから、処理可能か否かを含む問合せ応答を受信する問合せ処理手段を更に有し、
   前記サービス構成制御手段は、前記実行シナリオに含まれる全てのサービスノードサーバについて処理可能となるように、前記実行シナリオを決定する
   ことを特徴とする請求項６に記載のサービス連結制御用の制御ノードサーバ。
8. 前記端末からサービス終了要求を受信すると共に、前記端末へサービス終了応答を返信する端末側サービス終了処理手段と、
   前記端末からサービス終了要求を受信した際に、サービス終了要求を、前記実行シナリオに含まれる全てのサービスノードサーバへ送信し、全てのサービスノードサーバからサービス終了応答を受信するサーバ側サービス終了処理手段と、
   前記端末から、ユーザ操作に応じた当該サービスにおける評価値を受信するサービス評価値受信手段と、
   前記実行シナリオに対応付けて前記評価値を蓄積するサービス評価値蓄積手段と
   を有することを特徴とする請求項７に記載のサービス連結制御用の制御ノードサーバ。
9. 前記実行シナリオに対応付けた評価値に基づいて、各サービスノードサーバの評価値を導出する評価値解析手段を更に有し、
   前記サービス構成制御手段は、評価値が高くなるように、前記実行シナリオを決定することを特徴とする請求項８に記載のサービス連結制御用の制御ノードサーバ。
10. 前記複数のサービスノードサーバとの間で、サービス指向アーキテクチャ(ＳＯＡ)によってサービス機能が部品化されており、
    前記サービスノードサーバによって提供されたＡＰＩを用いて、前記端末及び前記複数のサービスノードサーバとの間で、プロキシベースの要求メッセージ／応答メッセージを交換することによって実現されている
    ことを特徴とする請求項６から９のいずれか１項に記載のサービス連結制御用の制御ノードサーバ。
11. クライアント用の端末と、サービス機能を実行する複数のサービスノードサーバとの間で、ネットワークを介して相互に通信すると共に、複数のサービスノードサーバにおける前記サービス機能を管理する制御ノードサーバに搭載されたコンピュータを機能させるプログラムであって、
    前記端末から、ユーザ所望のサービスに必要なパラメータを含むサービス開始要求を受信するサービス開始要求受信手段と、
    前記サービス開始要求に基づくサービスを提供するために必要な複数のサービスノードサーバの実行シナリオを決定するサービス構成制御手段と、
    前記実行シナリオの実行順序に基づいて、実行すべき全てのサービスノードサーバへサービス開始要求を送信するサービス開始要求送信手段と、
    前記実行シナリオに含まれる全てのサービスノードサーバから、サービス応答を受信するサービス開始応答受信手段と、
    前記実行シナリオに含まれる全てのサービスノードサーバから、サービス応答を受信した後、サービス開始応答を前記端末へ返信するサービス開始応答返信手段と
    してコンピュータを機能させ、
    前記端末が、前記実行シナリオの中で最後に実行された最終実行サービスノードサーバへアクセスし、前記最終実行サービスノードサーバが、前記実行シナリオに基づいて連結されたサービス応答を前記端末へ返信するように動作させることを特徴とする制御ノードサーバ用のサービス連結制御プログラム。

Images