JP4057925B2 - サービス管理方法及び装置 - Google Patents
サービス管理方法及び装置Info
- Publication number
- JP4057925B2 JP4057925B2 JP2003021073A JP2003021073A JP4057925B2 JP 4057925 B2 JP4057925 B2 JP 4057925B2 JP 2003021073 A JP2003021073 A JP 2003021073A JP 2003021073 A JP2003021073 A JP 2003021073A JP 4057925 B2 JP4057925 B2 JP 4057925B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- server
- identifier
- services
- web
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、インターネットなどのネットワーク上で提供されるサービスのより高度な統合を実現し、ネットワーク上での複数のサービス提供システムを連携する技術に関する。
以下では、ネットワーク上での複数のサービス提供システムを連携することにより提供される、より付加価値の高いサービスを、メタサービスという。
【０００２】
【従来の技術】
最近のインターネットの普及にともない、インターネット上でメタサービスを提供するための枠組みが提供されている。具体的には、ＸＭＬ(eXtensible Markup Language)技術の進歩により、コンピュータが直接アクセス可能なサービス部品（ビジネスコンポーネント）をインターネット上で公開・検索・実行することが可能になっている。サービス部品の公開・検索は、ＵＤＤＩ（Universal Description, Discovery and Integration）仕様によって行われる。また、サービス部品への処理（実行）の依頼と結果の受け取りは、ＳＯＡＰ（Simple Object Access Protocol）仕様によって行う。また、個々のサービス部品にどのように処理を依頼するかのサービス記述は、ＷＳＤＬ（Web Services Description Language）仕様に基づいて行う。このような仕組みによって、各サービス提供システムは、必要なサービス部品を発見し呼び出すことができる環境の構築が可能となっている。この環境は、Web Servicesアーキテクチャとして提案され、仕様の標準化作業が進められている。以下では、Web Servicesアーキテクチャに基づくサービス部品をＷｅｂサービスと呼ぶ。
【０００３】
更に、個々のＷｅｂサービスを組み合わせてメタサービスを構築するための仕組みが提案されている。その仕組みは、手続き表現（フロー）に基づいて、個々のＷｅｂサービスを呼び出すというものである。その手続き表現として、ＷＳＦＬ（Web Services Flow Language）、ＸＬＡＮＧなどが提案されている。フローに必要な部品、すなわちＷｅｂサービスは、ＵＤＤＩにアクセスして検索することにより、自動的に取得される。このようにして取得されたＷｅｂサービスを、順次呼び出して連携させることで、動的なサービス統合を行うことができる。１つのメタサービスは、別のメタサービスのＷｅｂサービス部品となることができる。
【０００４】
【発明が解決しようとする課題】
今後、Ｗｅｂサービスの普及につれて、複数のＷｅｂサービスを連携させたメタサービスが普及することが見込まれる。手続表現に基づいて呼び出される各Ｗｅｂサービスは、予め決まったメタサービスから呼び出されることを想定して作成されているわけではなく、どこから呼び出されるかは分からない。
【０００５】
一方、メタサービスを利用するユーザにとって、「実行を依頼したメタサービスの状態がどうなっているのか」は、知りたい情報の１つであると考えられる。すなわち、メタサービスを実行させている状態を通知する状態通知サービスが求められている。銀行振り込みのようにすぐに終了するサービスであれば、ユーザがその場ですぐに結果を得られるので、状態を問い合わせる必要もない。しかし例えば、インターネットで商品を購入した場合、購入操作自体はすぐに終了するものの、それと同時に商品が届くわけではない。実際には、購入操作により注文した商品を届けてもらうための段取りを、１）商品を手配するサービス提供システム、２）物流を行うサービス提供システム、３）お金の引き落としを行うサービス提供システムに対して行ったにすぎない。実際の商品の移動は、その段取りに従って、順次行われていくことになる。このような場合の商品の配送状態についての問い合わせは、やはり日常よく行われる行為である。
【０００６】
Ｗｅｂサービスを使用した環境で上記のような状態通知サービスを可能とするためには、個々のＷｅｂサービスが、呼び出し元の各メタサービスに対し、自分の状態の通知サービスを行えるようにする必要がある。そのためには、各Ｗｅｂサービスが、呼び出し元のメタサービスの情報を保存し、そこに対して呼び出しを行える処理能力を有していることが必要である。
【０００７】
しかし、Ｗｅｂサービスは様々なメタサービスから呼び出される可能性があり、その数が増えれば増えるほど、状態を通知するための処理コストが高くなる。個々のＷｅｂサービスがそのような処理コストを負担してまで状態通知サービスに対応することは、Ｗｅｂサービスの提供主体にとって負担が大きく、困難な場合が多いと考えられる。
【０００８】
複雑な段取りを行う場合でも、個々の段取りに使用する部品（各要素）が１つのシステムで構成されているような場合は、共通のデータベースに各部品の状態を保存することによって状態通知サービスを行うことができる。例えば、Ｆｅｄｅｘのトラッキングサービスなどは、そのような例にあたると考えられる。しかし、フローの個々のサービス部品がインターネット上に分散して存在するＷｅｂサービスである場合は、各種のメタサービスに対応した構成を各Ｗｅｂサービスに持たせることは現実的でない。従って、各メタサービスが、各Ｗｅｂサービスから直接状態通知を受け、状況を把握することは難しいと考えられる。
【０００９】
本発明は、Ｗｅｂサービスを連携して実現されるメタサービスの状態通知を、各Ｗｅｂサービスの提供者に負担をかけることなく実現することを目的とする。
また本発明は、メタサービスを利用するユーザに合う状態通知を、前記ユーザに行うことを目的とする。
【００１０】
【課題を解決するための手段】
前記課題を解決するために、本願第１発明は、コンピュータが行うサービス管理方法を提供する。このコンピュータは、ネットワーク上で提供されるサービスを統合して統合サービスを提供する複数のサービス統合装置と、前記サービスを提供するサービス提供装置群とに接続することができる。前記方法は以下のステップを含む。
・前記複数のサービス統合装置のそれぞれに要求された各統合サービスを実行するために必要な各サービスを提供する各サービス提供装置の識別子を、前記複数のサービス統合装置のそれぞれから取得する予定取得ステップ、
・前記各サービス提供装置が提供する各サービスを特定するサービス識別子を、前記各サービス提供装置から取得するサービス取得ステップ、
・前記各サービスのうちのいずれかの提供予定の変更を、そのサービスを提供するサービス提供装置から受信する状況取得ステップ、
・前記サービスの提供予定の変更を、前記予定取得ステップにおいてそのサービスを提供するサービス提供装置の識別子を送信してきたサービス統合装置に通知する変更通知ステップ。
【００１１】
この方法は、例えばメタサービスを提供するメタサービスサーバと、メタサービスの部品であるサービスの提供サーバと、に接続可能なコンピュータが実行する。このコンピュータは、実行予定のサービスと各サービスの提供サーバとを記憶しておき、いずれかのサービスの提供予定に変更が生じると、メタサービスサーバに通知する。複数のメタサービスから呼び出される可能性のある提供サーバを、いちいち各メタサービスに対応させた構成にすることなく、各種メタサービスの実行に不可欠なサービスの変更を各種メタサービスサーバに通知できる。従って、メタサービスサーバは、不測の事態によりメタサービスの実行が遅れている原因などを、ユーザに通知することができる。
【００１２】
本願第２発明は、前記第１発明において、前記状況取得ステップは、前記各サービスの実行状況を、前記各サービス提供装置からさらに取得するサービス管理方法を提供する。この方法は、以下のステップをさらに含む。
・前記各サービスの実行状況と前記各サービス識別子とを対応付けて記憶する状況記憶ステップ、
・前記状況取得ステップで取得した各サービスの実行状況に基づいて、記憶されたサービスの実行状況を更新する状況更新ステップ、
・前記各サービスの実行状況を、前記サービス統合装置に通知する状況通知ステップ。
【００１３】
この方法を実行するコンピュータは、メタサービスの実行に必要な各サービスの実行状況を、各サービスの提供装置から取得し、一元的に記憶している。従って、各サービスの実行状況をメタサービスサーバに通知すれば、メタサービスサーバはユーザにメタサービスの実行状況を通知することができる。
本願第３発明は、前記第１発明において、以下のステップをさらに含むサービス管理方法を提供する。
・任意のサービス提供装置により提供される少なくとも１つのサービスを指定する監視対象と、前記監視対象に生じた提供予定の変更を通知する監視者の識別子と、を対応付けて記憶する監視条件記憶ステップ、
・前記状況取得ステップで提供予定の変更が受信されたサービスが、監視対象に含まれているかどうかを判別する判別ステップ、
・提供予定が変更されたサービスが監視対象に含まれている場合、前記サービスの監視者に、前記サービスの提供予定の変更を通知する監視ステップ。
【００１４】
提供予定に変更が生じたサービスが監視対象である場合、生じた変更を監視者に通知する。監視者とは、例えば、同種のサービスを提供する同業他社のサービス提供装置や、変更が生じたサービスを部品に含むメタサービスを提供するサービス統合装置である。提供予定の変更を積極的に通知することにより、代行サービスの必要を通知し、迅速に代行サービスを見つけるきっかけを作ることができる。従って、メタサービス全体の実行への支障を最小限に押さえることにつながる。
【００１５】
本願第４発明は、前記第３発明において、前記監視対象及び監視者の識別子の登録を受け付ける登録ステップをさらに含むサービス管理方法を提供する。
監視者を広く募ることにより、不測のアクシデントに迅速かつ柔軟に対応しやすくなり、メタサービスの付加価値を間接的に高めることができる。
本願第５発明は、前記第１発明において、以下のステップをさらに含むサービス管理方法を提供する。
・提供予定が変更となったサービスに代わる代行サービスの識別子と、その代行サービスを提供する代行サービス提供装置の識別子と、を含む代行の申し出を受信する代行登録ステップ、
・前記代行サービス提供装置による代行サービスの提供予定を、前記サービス統合装置に通知する代行通知ステップ。
【００１６】
代行の申し出は、例えば前記監視者からなされることが考えられる。また例えば、予定が変更になったサービスと同種のサービスを統合して提供しているメタサービスサーバから代行の申し出が自発的になされることが考えられる。代行の申し出は、メタサービスサーバに通知される。これにより、メタサービスを構成する１つのサービスが実行不可能になった場合でも、メタサービス全体の実行に大きな支障を来すことなくメタサービスを実行することができる。つまり、代行の申し出を受け付けることは、メタサービスの危機管理体制を高め、メタサービスの付加価値を高めることにつながる。
【００１７】
本願第６発明は、前記第１発明の方法を実行するサービス管理装置を提供する。
本願第７発明は、前記第１発明の方法をコンピュータに実行させるサービス管理プログラムを提供する。
本願第８発明は、前記サービス管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
【００１８】
ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
【００１９】
【発明の実施の形態】
＜第１実施形態例＞
（１）全体構成
図１は、本発明の第１実施形態例を適用したサービス管理装置が動作する環境を示す。サービス管理装置１、メタサービスサーバ２、Ｗｅｂサーバ３ａ、３ｂ、３ｃ、ユーザ端末４及びＵＤＤＩ５は、ネットワーク６を介して接続される。この例では、ネットワーク６はインターネットである。Ｗｅｂサーバ３ａ、３ｂ、３ｃ（以下、Ｗｅｂサーバ３という）は、それぞれＷｅｂサービスＸ，Ｙ，Ｚを提供している。メタサービスサーバ２は、ＷｅｂサービスＸ，Ｙ，Ｚを統合したサービスであるメタサービスを、ユーザ端末４に提供する。各Ｗｅｂサーバ３のアドレスは、ＵＤＤＩ５から取得可能である。なお、各Ｗｅｂサービスがメタサービスであっても良い。つまり、Ｗｅｂサーバ３が、また別のＷｅｂサービスＰ１，Ｐ２・・・を統合したメタサービスを提供していても良い。サービス管理装置１は、メタサービスサーバ２からの通知に応じ、メタサービスの実行に必要なＷｅｂサービスの実行状況を管理する。
（２）サービス管理装置及びメタサービスサーバ
図２は、サービス管理装置１及びメタサービスサーバ２の機能構成を示すブロック図である。まず、メタサービスサーバ２について説明し、ついでサービス管理装置１について説明する。
【００２０】
（２−１）メタサービスサーバ
メタサービスサーバ２は、ユーザインターフェース（以下、ユーザＩ／Ｆという）２１と、管理インターフェース（以下、管理Ｉ／Ｆという）２２とを有している。
ユーザＩ／Ｆ２１は、メタサービスの要求を、ユーザ端末４から受け付ける。また、ユーザＩ／Ｆ２１は、ユーザ端末４に、メタサービスの実行に必要なＷｅｂサービスのいずれかの提供予定が変更したことを通知する。
【００２１】
管理Ｉ／Ｆ２２は、メタサービスの要求を解釈し、メタサービスの実行に必要な各ＷｅｂサービスＸ，Ｙ，Ｚを提供するＷｅｂサーバ３の識別子を、サービス管理装置１に通知する。各Ｗｅｂサービスを提供するＷｅｂサーバ３の識別子は、例えばＵＲＬ(Uniform Resource Locator)で記述され、ＵＤＤＩ５から取得可能である。また管理Ｉ／Ｆ２２は、サービス管理装置１に通知した各Ｗｅｂサービスのうち、いずれかのＷｅｂサービスＸの提供予定の変更を、サービス管理装置１から受信する。
【００２２】
さらに、管理Ｉ／Ｆ２２は各ＷｅｂサービスＸ，Ｙ，Ｚの実行状況をサービス管理装置１から受信し、ユーザＩ／Ｆ２１はその実行状況をユーザ端末４に通知することが好ましい。ユーザＩ／Ｆ２１からユーザ端末４への予定変更の通知や、実行状況の通知は、ユーザ端末４からの要求に応じて行っても良いが、プッシュ方式で強制的に通知しても良い。不測の事態によりサービスの実行予定が狂ったことをユーザに迅速に通知でき、メタサービスの付加価値が高まると期待できる。
【００２３】
（２−２）サービス管理装置
（２−２−１）基本構成
サービス管理装置１は、基本的にはモジュール群１１〜１３と、サービス管理テーブル１１１を有している。予定取得モジュール１１は、メタサービスサーバ２に要求されたメタサービスを実行するために必要な各Ｗｅｂサービスを提供する各Ｗｅｂサーバ３の識別子を、メタサービスサーバ２から取得する。Ｗｅｂサーバ３の識別子はＵＲＬなどで記述される。取得したＷｅｂサーバ３の識別子（図中、サーバＩＤと記載）は、サービス管理テーブル１１１に記憶される。
【００２４】
更新モジュール１２は、必要なＷｅｂサービスを特定するサービス識別子（図中、サービスＩＤと記載）を、各Ｗｅｂサーバ３から取得し、サービス管理テーブル１１１に書き込む。サービス識別子は、各Ｗｅｂサーバ３により生成される。更新モジュール１２は、受信したサービス識別子を、サービス管理装置１内でユニークな識別子により識別しても良い。また、更新モジュール１２は、前記各Ｗｅｂサービスのうちのいずれかの提供予定の変更を、そのＷｅｂサービスを提供するＷｅｂサーバ３から受信する。提供予定の変更とは、例えば予定していたＷｅｂサービスを提供できなくなったことが挙げられる。
【００２５】
変更通知モジュール１３は、前記Ｗｅｂサービスの提供予定の変更を、メタサービスサーバ２に通知する。この通知は、メタサービスサーバ２からの要求に応じて行っても良いが、プッシュ方式で強制的に行うことも好ましい。メタサービスの実行にトラブルが起きたことを迅速に通知でき、メタサービスの付加価値を高めることに間接的に寄与できると考えられる。
【００２６】
このような構成のサービス管理装置１をネットワーク６上に設けることにより、複数のメタサービスから呼び出される可能性のあるＷｅｂサーバ３を、いちいち各メタサービスに対応させた構成にすることなく、各種メタサービスの実行に不可欠なＷｅｂサービスの予定変更を各種メタサービスサーバ２に通知できる。従って、メタサービスサーバ２は、不測の事態によりメタサービスの実行が遅れている原因などを、ユーザ端末４に通知することができる。
【００２７】
（２−２−２）Ｗｅｂサービスの実行状況の把握
上述の基本機能に加え、前記更新モジュール１２は、メタサービスの実行に必要な各Ｗｅｂサービスの予約内容や実行状況、Ｗｅｂサービスに関する連絡先などを、各Ｗｅｂサーバ３からさらに取得することが好ましい。取得した予約内容や実行状況、連絡先は、各Ｗｅｂサービスの識別子及び各Ｗｅｂサーバ３の識別子と対応付けて、サービス管理テーブル１１１に記憶される。さらに、更新モジュール１２は、各Ｗｅｂサービスの実行状況を新たに受信すると、サービス管理テーブル１１１に記憶されている該当サービスの実行状況を更新する。実行状況は、例えば更新されるたびに、変更通知モジュール１３によりメタサービスサーバ２に通知される。この通知も、前記と同様の理由から、プッシュ方式で行うことが好ましい。
【００２８】
この構成を有するサービス管理装置１は、メタサービスの実行に必要な各Ｗｅｂサービスの内容及びその実行状況を、一元的に管理する。従って、各Ｗｅｂサービスの実行状況を把握してメタサービスサーバに通知でき、メタサービスの付加価値をさらに高めることができる。
（２−２−３）予定変更の監視
サービス管理装置１は、上述の構成にくわえ、監視モジュール１４と監視テーブル１１２とを有していることが好ましい。監視テーブル１１２は、監視対象と、監視者の識別子とを対応付けて記憶している。監視対象は、Ｗｅｂサーバ３により提供される少なくとも１つのＷｅｂサービスを指定する。監視対象としては、例えば以下のデータａ）〜ｃ）が記述される。
ａ）Ｗｅｂサーバの識別子、
ｂ）Ｗｅｂサービスの種類を示す識別子、
ｃ）サービス管理テーブル１１１に記憶されているいずれかのＷｅｂサービスの識別子。
【００２９】
監視者とは、前記監視対象であるＷｅｂサービスに生じた提供予定の変更の通知先である。監視者の具体例としては、以下のａ）、ｂ）が挙げられる。監視者の識別子は、例えばＵＲＬで記述される。
ａ）キャンセルされたサービスと同種のサービスを提供する同業他社のサービス提供装置、
ｂ）変更が生じたサービスを部品に含むメタサービスを提供するメタサービスサーバ２。
【００３０】
監視モジュール１４は、提供予定が変更されたＷｅｂサービスが、監視対象に含まれているかどうかを判断し、含まれていれば前記Ｗｅｂサービスの監視者に
前記Ｗｅｂサービスの提供予定の変更を通知する。さらに、監視モジュール１４は、要求に応じて監視対象及び監視者の識別子の登録を受け付け、監視テーブル１１２を更新すると良い。
【００３１】
提供予定に変更が生じたＷｅｂサービスが監視対象である場合、生じた変更を監視者に通知する。提供予定の変更を積極的に通知することにより、監視者に代行サービスの必要を通知し、迅速に代行サービスを見つけるきっかけを作ることができる。また監視者の登録を受け付けることで代行サービスが提供される確率が高くなるので、不測のアクシデントに迅速かつ柔軟に対応しやすくなる。結果として、メタサービスの付加価値を間接的に高めることができる。
【００３２】
（２−２−４）代行サービス
上述の構成に加え、サービス管理装置１は、代行モジュール１５と、代行テーブル１１３とをさらに有することが好ましい。代行モジュール１５は、代行の申し出を受信する。この代行の申し出には、提供予定が変更となったＷｅｂサービスに代わる代行Ｗｅｂサービスの識別子（図中、代行サービスＩＤと記載）と、その代行Ｗｅｂサービスを提供する代行Ｗｅｂサーバの識別子と、が含まれる。代行サービスの識別子と代行Ｗｅｂサーバの識別子とは、代行テーブル１１３に記憶され、またサービス管理テーブル１１１にも書き込まれる。その結果、代行サービスがメタサービスサーバ２に通知される。
【００３３】
代行の申し出は、例えばＷｅｂサービスの提供予定の変更を受けた監視者からなされる。また例えば、予定が変更になったＷｅｂサービスと同種のＷｅｂサービスを統合して提供しているメタサービスサーバから、代行の申し出が自発的になされてもよい。別のウェブサーバによる代行サービスを受け付けることにより、メタサービスを構成する１つのサービスが実行不可能になった場合でも、メタサービス全体の実行に大きな支障を来すことなくメタサービスを実行することができる。つまり、メタサービスの危機管理体制を高め、メタサービスの付加価値を高めることにつながる。
（３）処理の流れ
次に図３を参照し、前述の構成を有するサービス管理装置１、メタサービスサーバ２、Ｗｅｂサーバ３が行う処理の流れについて説明する。説明を容易にするために、メタサービスサーバ２は、ＷｅｂサービスＸとＷｅｂサービスＹとを統合したメタサービスを提供しているとする。
【００３４】
（３−１）メタサービスが代行サービスを検索する場合
まず、ユーザ端末４からメタサービスサーバ２に対し、メタサービスの提供要求が発生する（＃１０１）。要求はメタサービスサーバ２の管理Ｉ／Ｆ２２によりにより解釈される。ついで、要求されたメタサービスの実行に必要なＷｅｂサービスを提供するＷｅｂサーバ３の識別子が、管理Ｉ／Ｆ２２によりサービス管理装置１に通知される（＃１０２）。通知されたＷｅｂサーバの識別子は、予定取得モジュール１１が受信し、更新モジュール１２によりサービス管理装置１のサービス管理テーブル１１１に書き込まれる。
【００３５】
さらに、メタサービスの実行に必要なＷｅｂサービスＸ，Ｙの予約要求が、メタサービスサーバ２の管理Ｉ／Ｆ２２からＷｅｂサーバ３ａ，３ｂに送信される（＃１０３，＃１０５）。これに対し、各Ｗｅｂサーバ３ａ，３ｂが提供するＷｅｂサービスの識別子が、Ｗｅｂサーバ３ａ，３ｂからサービス管理装置１に送信される（＃１０４，＃１０６）。Ｗｅｂサービスの識別子は、更新モジュール１２により取得され、Ｗｅｂサーバ３ａ、３ｂの識別子と対応付けてサービス管理テーブル１１１に記憶される。
【００３６】
その後、トラブルの発生により、例えばＷｅｂサービスＹの提供が不可能になったとする。その場合、ＷｅｂサービスＹの予定変更通知が、Ｗｅｂサーバ３ｂからサービス管理装置１に送信される（＃１０７）。これを受け、サービス管理テーブル１１１の該当Ｗｅｂサービスの識別子と、Ｗｅｂサーバ３ｂの識別子とが、更新モジュール１２により削除される。サービス管理テーブル１１１が更新されると、その更新内容が、更新モジュール１２から変更通知モジュール１３に渡され、メタサービスサーバ２に送信される（＃１０８）。メタサービスサーバ２は、例えばプッシュ方式でメタサービスの実行予定の変更をユーザ端末４に送信する（＃１０９）。
【００３７】
いま、メタサービスサーバ２の管理Ｉ／Ｆ２２は、自分が提供するメタサービスの範囲内で代行サービスを検索することができるとする。管理Ｉ／Ｆ２２は、ＷｅｂサービスＹと同種のＷｅｂサービスＺを提供するＷｅｂサーバ３ｃに、サービスＺの予約要求を送信する（＃１１０）。これに対応し、代行ＷｅｂサービスＺの識別子と、Ｗｅｂサーバ３ｃの識別子とが、Ｗｅｂサーバ３ｃからサービス管理サーバ１に送信される（＃１１１）。代行ＷｅｂサービスＺの識別子と代行Ｗｅｂサーバ３ｃの識別子とは、代行モジュール１５により受信され、代行テーブル１１３に書き込まれる。また、これらのデータは更新モジュール１２に渡され、サービス管理テーブル１１１に書き込まれる。サービス管理テーブル１１１が更新されるので、更新内容が更新モジュール１２から変更通知モジュール１３に渡され、メタサービスサーバ２に通知される（＃１１２）。これを受け取ったメタサービスサーバ２は、ＷｅｂサービスＹに代えて代行ＷｅｂサービスＺが提供されることを、ユーザ端末４に通知する（＃１１３）。
【００３８】
上記の例はトラブルを例にとっているが、同様にして、各Ｗｅｂサービスの実効状態が変わるたびにサービス管理装置１に通知することができる。従って、以上の処理により、メタサービスを実行するのに必要なＷｅｂサービスの状態を一元的に管理し、ユーザに提供することが可能となる。また、いずれかのＷｅｂサービスの予定が変更になった場合であっても、代行サービスが提供されることをサービス管理装置１が把握でき、また代行サービスの提案をメタサービスを介してユーザに通知することができる。
【００３９】
（３−２）監視テーブルを用いる場合
前記＃１１０〜＃１１３の処理は、メタサービスサーバ２が代行サービスの検索機能を有する場合の処理を示している。しかし、メタサービスサーバ２がその機能を有さない場合、監視テーブル１１２を用いた図４に示す処理が実行される。説明を容易にするために、監視テーブル１１２には、監視対象をＷｅｂサービスＹ、監視者をＷｅｂサーバ３ｃとするレコードが記憶されていたとする。
【００４０】
処理＃１０１〜＃１０９までは前述と同様に行われる。そうすると、メタサービスサーバ２の管理Ｉ／Ｆ２２は、ＷｅｂサービスＹの代行サービスを、サービス管理装置１に要求する（＃２１０）。この要求を受け、サービス管理装置１の監視モジュール１４は、ＷｅｂサービスＹの監視者であるＷｅｂサーバ３ｃに、ＷｅｂサービスＹの予定が変更になったことを通知する（＃２１１）。複数の監視者が存在する場合には、各監視者にこの通知が送信される。
【００４１】
ついで、代行モジュール１５が、Ｗｅｂサーバ３ｃから代行の申し出を受信する（＃２１２）。複数の監視者に予定の変更を通知している場合には、そのいずれかから代行の申し出を受信する。この申し出には、代行ＷｅｂサービスＺの識別子とＷｅｂサーバ３ｃの識別子とが含まれる。代行ＷｅｂサービスＺの識別子と代行Ｗｅｂサーバ３ｃの識別子とは、代行モジュール１５により代行テーブル１１３に書き込まれる。また、これらのデータは更新モジュール１２に渡され、サービス管理テーブル１１１に書き込まれる。サービス管理テーブル１１１が更新されるので、更新内容が更新モジュール１２から変更通知モジュール１３に渡され、メタサービスサーバ２に通知される（＃２１３）。これを受け取ったメタサービスサーバ２は、ＷｅｂサービスＹに代えて代行ＷｅｂサービスＺが提供されることを、ユーザ端末４に通知する（＃２１４）。
【００４２】
以上の処理により、メタサービスやＷｅｂサービスに代行サービスを検索する機能がない場合であっても、代行サービスの提供を監視者から募り、メタサービスの実行を行うことができる。
［実施例１］
（１）構成
次に、本発明の一実施例を参照し、本発明をより具体的に説明する。図５は、実施例１に係るサービス管理装置１が動作する環境を示す。サービス管理装置１、出張管理サーバ２、Ｗｅｂサーバ群３ａ〜ｄ、ユーザ端末４及びＵＤＤＩ５は、インターネット６により接続される。飛行機予約サーバ３ａは飛行機予約サービスを、宿予約サーバ３ｂは宿予約サービスを、電車時刻サーバ３ｃは交通機関の乗り換えルート計算サービスを、それぞれ提供する。出張管理サーバ２は、飛行機予約サーバ３ａ、宿予約サーバ３ｂ、電車時刻サーバ３ｃの各サービスを統合したメタサービスを提供する。新幹線予約サーバ３ｄは新幹線予約サービスを提供している。このＷｅｂサービスは、出張管理サーバ２のメタサービスの範囲外である。
（２）処理の概要
図６は、サービス管理装置１、出張管理サーバ２、Ｗｅｂサーバ３ａ〜ｄが行う処理の流れを示す説明図である。まず図６を参照し、出張管理サービスにおける処理を説明する。
【００４３】
（２−１）サービス管理テーブルへのサーバの登録
まず、ユーザ端末４が出張管理サービスを出張管理サーバ２に要求する（＃１）。例えば、出張管理サーバ２の管理Ｉ／Ｆ２２は、図７に例示する画面をユーザ端末４に提供し、出張管理サービスの実行に必要なデータを取得する。ついで、出張管理サーバ２の管理Ｉ／Ｆ２２は、自分自身と、飛行機予約サーバ３ａ・宿予約サーバ３ｂのＵＲＬとを、サービス管理装置１に通知する（＃２、＃５、＃８）。出張管理サービスをするために状態の管理が必要なＷｅｂサービスは、飛行機予約サービスと宿予約サービスだからである。サービス管理装置１の予定取得モジュール１１は、出張管理サーバ２、飛行機予約サーバ３ａ、及び宿予約サーバ３ｂのＵＲＬを、サービス管理テーブル１１１に登録する。
【００４４】
（２−２）サービス管理テーブルへの予約サービス情報の登録
また、管理Ｉ／Ｆ２２は、飛行機予約サーバ３ａ、宿予約サーバ３ｂに、Ｗｅｂサービスの予約を要求する（＃３，＃６）。これに応じ、飛行機予約サーバ３ａからはフライト予定の登録通知がサービス管理装置１に送信される（＃４）。この通知には、ユーザの要求に合うフライト予約内容、連絡先などを含む予約サービス情報が含まれる。また、宿予約サーバ３ｂからは宿泊予定の登録通知がサービス管理装置１に送信される（＃７）。この通知には、ユーザの要求に合う宿予約内容、連絡先などを含む予約サービス情報が含まれる。各Ｗｅｂサーバ３ａ、３ｂからの予約サービス情報は、サービス管理テーブル１１１に飛行機予約サーバ３ａ及び宿予約サーバ３ｂのＵＲＬと対応付けて記憶される。書き込まれた内容は、更新モジュール１２から変更通知モジュール１２に渡され、出張管理サーバ２に通知される。
【００４５】
（２−３）出張管理サービスの予定の通知
出張管理サーバ２は、管理Ｉ／Ｆ２２により電車時刻サーバ３ｃに電車の乗り換えルートの計算を要求し、その結果を取得する（＃９）。取得した乗り換えルートは、飛行機の予約サービス情報及び宿の予約サービス情報とともに、一括してユーザＩ／Ｆ２１からユーザ端末４に提供される（＃１０）。図８は、出張管理サーバ２が提供する移動プランの提示画面例である。サービス管理装置１を介して取得した飛行機の予約サービス情報及び宿の予約サービス情報が、乗り換えルートと共に表示されている。
【００４６】
（２−４）監視テーブルへの登録
これらの処理とは独立に、新幹線予約サーバ３ｄ及び宿予約サーバ３ｂは、飛行機や電車など輸送サービスを監視対象とし、自分自身を監視者として、サービス管理装置１に登録の依頼を要求する（＃２０）。この依頼は、監視モジュール１４により受信され、監視テーブル１１２に書き込まれる。
【００４７】
（２−５）トラブルの通知
ところで、移動プランの決定後、天候悪化などにより予定していた往路のフライトが飛ばなくなったとする。この場合、飛行機予約サーバ３ａから往路のフライトの中止通知がサービス管理サーバ１に送信される（＃２１）。サービス管理サーバ１の更新モジュール１２は、この通知を受信すると、実行不可能となったサービスを出張管理サーバ２に通知する（＃２２）。
【００４８】
（２−６）監視者への通知
サービス監視装置１の監視モジュール１４は、飛行機の予約サービスが監視対象であるか否かを判断する。監視対象であれば、飛行機予約サービスを監視対象としている監視者のうち、宿予約サーバ３ｂに対し、飛行機予約サービスの予定変更を通知する（＃２３）。同様にして、監視者のうち新幹線予約サーバ３ｄに対しても通知する（＃２５）。また新幹線予約サーバ３ｄに対するこの通知を、出張管理サーバ２からの要求（＃２４）に応じて行っても良い（＃２５）。新幹線予約サーバに対する通知には、代行者が代行サービスを提供するために必要な情報が含まれている。例えば出発地、目的地、出発日時などである。
【００４９】
（２−７）代行サービスの申し出と通知
ついで、サービス管理装置の代行モジュール１５は、代行サービスの申し出を、新幹線予約サーバ３ｄから受信する（＃２６）。この例では、この申し出は、ユーザの要求に合う新幹線の予約内容、連絡先などを含む予約サービス情報と、新幹線予約サーバ３ｄのＵＲＬとを含む。これらの情報は、代行モジュール１５により代行テーブル１１３に書き込まれる。またこれらの情報は、代行モジュール１５から変更通知モジュール１３に供給され、出張管理サーバ２に送信される（＃２７）。その後、出張管理サーバ２は、再度乗り換えルートの算出を電車時刻サーバ３ｃに要求した後（＃２８）、変更後の移動プランをユーザ端末４に提供する（＃２９）。図９は、変更後の移動プランの表示例である。この画面例は、変更後の移動プランをユーザが承認するか否かの選択を受け付ける。
【００５０】
（２−８）サービス管理テーブルの更新
出張管理サーバ２の管理Ｉ／Ｆ２２は、変更後のプランに対するユーザの承認がでると、往路の飛行機予約サービスをサービス管理テーブル１１１から削除するための処理を行う。もちろん、ユーザの承認なしに以下の処理を行うことも可能である。まず管理Ｉ／Ｆ２２は、当初の往路の飛行機のキャンセルを、飛行機予約サーバ３ａとサービス管理装置１とに通知する（＃３０、＃３１）。この通知に応じ、サービス管理装置１の更新モジュール１２は、往路の飛行機の予約サービス情報のエントリを、サービス管理テーブル１１１から削除する。また、飛行機予約サービスを監視対象としている宿予約サーバ３ｂに、往路の飛行機予約サービスがキャンセルされたことを通知する（＃３２）。この通知は、代行サービスを申し出た監視者には通知しなくてよい。
【００５１】
ついで、出張管理サーバ２の管理Ｉ／Ｆ２２は、代行サービスをサービス管理テーブル１１１に登録してもらうための処理を行う。まず管理Ｉ／Ｆ２２は、往路の新幹線の予約を新幹線予約サーバ３ｄに要求（＃３３）し、新幹線予約サーバ３ｄの登録をサービス管理装置１に要求する（＃３４）。この要求に応じ、更新モジュール１２は、代行テーブル１１３に記憶されている新幹線の予約サービス情報や新幹線予約サーバ３ｄのＵＲＬを、サービス管理テーブル１１１に登録する。さらに、出張管理サービスで実行する輸送サービスに変更が生じたので、輸送サービスを監視している宿予約サーバ３ｂに、新たな輸送サービスの内容が送信される（＃３５）。受信側は、飛行機に代わり、新幹線によるサービスが実行されることを知ることができる。
【００５２】
以上では、トラブルを例にとっているが、同様にして各Ｗｅｂサービスの実効状態をサービス管理装置１に通知することができる。従って、出張管理サービスを構成する各Ｗｅｂサービスの状態が、サービス管理装置１により一元的に管理される。そのため、出張管理サービスの実行状況や、トラブルがあったときのその原因などを、出張管理サーバ２や各Ｗｅｂサーバ３がすぐに把握でき、出張管理サービスの付加価値が高まる。例えばユーザだけでなく、出張管理サービスの部品を提供するＷｅｂサービス提供者も、出張管理サービスの状態を知ることができるようになる。しかも、トラブルに対する代行サービスを出張管理サービスに提案可能なため、トラブルが生じたときにも出張管理サービス全体の実行に大きな支障がでることを防止できる。さらに、ユーザに提供するメタサービスの実行状態や代行サービス案は、そのユーザの要求にあったものを提供することができる。
（３）各テーブルの具体例
次に、前記図６に示す処理における、各テーブル１１１〜１１３の具体例を説明する。図１０は、当初の移動プランを実行するためのサービス管理テーブル１１１の内容を示す。図１１は、トラブル発生後のサービス管理テーブル１１１を示す。図１２は監視テーブル、図１３は代行テーブルの具体例を示す。図１４は、代行サービスが記述されたサービス管理テーブル１１１を示す。
【００５３】
（３−１）当初のサービス管理テーブル
まず図１０を参照する。この例では、サービス管理テーブル１１１は、サービスエントリテーブル、予約サービス情報テーブル、及び連絡先情報テーブルの３つのテーブルから構成されている。サービスエントリテーブルには、Ｗｅｂサービスを提供するＷｅｂサーバの識別子「サーバＩＤ」、予約サービス情報の識別子「サービスＩＤ」、連絡先情報の識別子「連絡先情報ＩＤ」が対応付けられている。予約サービス情報の詳細は、予約サービス情報テーブルに記述されている。連絡先情報の詳細は、連絡先情報テーブルに記述されている。従って、サービスＩＤ及び連絡先情報ＩＤは、サーバＩＤと、サービスの実行状況を含む予約サービス情報と、連絡先情報とを対応付けるためのキーとなっている。
【００５４】
また、「ノード番号」、「親ノード番号」、「処理ＩＤ」及び「種別ＩＤ」が、前述の情報と対応付けられて記憶されている。「ノード番号」は、予約サービスの実行順序を示す。ただし、必ずしも通し番号や連番である必要はない。「親ノード番号」は、ノード番号で特定される予約サービスの前に実行される予約サービスのノード番号である。ノード番号と親ノード番号とが同一の場合、そのレコードのサーバＩＤで特定されるＷｅｂサーバがメタサービスの提供者であることを示す。この図では、ノード番号及び親ノード番号が「１００」のwww.travel.comが、ノード番号１０１−１０３の各Ｗｅｂサービスを統合していることを示す。「処理ＩＤ」は、Ｗｅｂサーバ３が行う内部処理をＷｅｂサーバ３自身が識別するための識別子である。「種別ＩＤ」は、Ｗｅｂサービスの種類を表す。この例では、“travel.kind”は出張管理サービスを、“passenger.kind”は飛行機予約や新幹線予約などの輸送サービスを、“hotel.kind”はホテルや旅館など宿泊サービスを示す。
【００５５】
予約サービス情報テーブルには、予約サービス情報が、サービスＩＤと対応付けられて記憶されている。この例では、予約サービス情報は、「リソースＩＤ」、「予定情報」、「代行要求」、「実行状況」を含む。「リソースＩＤ」は、各Ｗｅｂサーバ３が、予約サービス情報を識別するための識別子である。「予定情報」は、Ｗｅｂサービスの「開始予定時刻」と「終了予定時刻」とを含む。「代行要求」は、各Ｗｅｂサービスが実行不可能になった場合に、その代行サービスの検索を要求されているか否かを示す。「実行状況」は、各Ｗｅｂサービスの「開始時刻」、「終了時刻」、実行待ち／実行中／実行済みを示す「状態」を含む。予約サービス情報は、各Ｗｅｂサーバ３からサービス管理装置１の更新モジュール１２に送信される。
【００５６】
連絡先情報テーブルには、連絡先情報が、連絡先情報ＩＤと対応付けられて記憶されている。この例では、連絡先情報は、「担当者」、「電話番号」、「電子メールアドレス」を含む。連絡先情報は、各Ｗｅｂサーバ３からサービス管理装置１の更新モジュール１２に送信される。
（３−２）トラブル発生後のサービス管理テーブル
図１１（Ａ）は、飛行機予約サービスにトラブルが発生した通知を飛行機予約サーバ３ａから受けた（＃２１）直後の予約サービス情報テーブルを示す。前記通知には、中止された予約サービス情報のリソースＩＤ“ＢＢ００１”が含まれている。これをキーに予約サービス情報テーブルのエントリが検索され、飛行機予約サービスを示すエントリの「状態」が「実行不可」に書き換えられる。
【００５７】
図１１（Ｂ）は、さらにその後、出張管理サーバ２から代行サービスの要求を受けた（＃２４）後の予約サービス情報テーブルを示す。要求に応じ、飛行機予約サービスの代行サービスの「代行要求」が「あり」に書き換えられている。
（３−３）監視テーブル
図１２は、宿予約サーバ３ｂや新幹線予約サーバ３ｄなど、監視者からの監視要求が登録された監視テーブル１１２の一例を示す。この例では、監視者ＩＤ、監視対象、通知先が対応付けられて記憶されている。監視者ＩＤは、監視対象に生じる予定の変更を監視している主体の識別子、例えばＵＲＬである。監視対象は、この例では監視リソースＩＤ及び／または監視種別ＩＤで特定される。例えば、往路の飛行機予約サービスのリソースＩＤは「ＢＢ００１」であり、種別ＩＤは「passenger.kind」である。この場合、飛行機予約サービスの予定が変更されると、「ＢＢ００１」または「passenger.kind」をキーとしてヒットする監視対象があるかどうかが検索される。通知先は、ヒットした監視対象の予定の変更を通知する先であり、この例では監視者ＩＤと一致している。この例では、飛行機予約サービスに生じた予定変更は、「www.travel.com」、「www.hotel.com」、「www.train.com」に通知される。なお、「www.travel.com」は出張管理サーバ２、「www.hotel.com」は宿予約サーバ３ｂ、「www.train.com」は新幹線予約サーバ３ｄの識別子である。また、監視者への通知には、中止された往路の飛行機予約サービスの予約サービス情報が含まれている。
【００５８】
（３−４）代行テーブル
図１３は、新幹線予約サーバ３ｄからの代行の申し出（＃２６）により更新された代行テーブル１１３の説明図である。代行テーブルには、代行されるＷｅｂサービスの内容を示す代行サービス情報が、代行ＷｅｂサーバＩＤと対応付けられて記憶されている。この例では、代行サービス情報は、「リソースＩＤ」、「予定情報」を含む。「リソースＩＤ」は、代行する予約サービス情報のリソースＩＤを示す。「予定情報」は、代行サービスの「開始予定時刻」と「終了予定時刻」とを含む。
【００５９】
（３−５）代行提案後のサービス管理テーブル
図１４は、図６に示す処理の終了後のサービス管理テーブル１１１の状態を示す。同図（Ａ）のサービスエントリテーブルには、往路の飛行機予約サービスのサーバＩＤ及び処理ＩＤに代えて、新幹線予約サービスのサーバＩＤ「www.train.com」と処理ＩＤ「Ｆ００００１」とが書き込まれている。同図（Ｂ）の予約サービス情報テーブルには、往路の飛行機予約サービスに代えて、新幹線予約サービスの開始予定時刻や終了予定時刻、状態が書き込まれている。さらに同図（Ｃ）の連絡先情報テーブルには、新幹線予約サービスの連絡先情報が書き加えられている。すなわち、サービス管理テーブル１１１には、代行サービスが登録されていることが分かる。
【００６０】
以上から、サービス管理テーブル１１１には、メタサービスである出張管理サービスを構成する各Ｗｅｂサービスの状況の変化が実質的にリアルタイムに反映されていることが分かる。
［実施例２］
（１）構成
次に、本発明の別の実施例を参照し、本発明をさらに具体的に説明する。図１５は、実施例２に係るサービス管理装置１が動作する環境を示す。サービス管理装置１、ショッピングサーバ２、Ｗｅｂサーバ群３ａ〜ｄ、ユーザ端末４及びＵＤＤＩ５は、インターネット６により接続される。第１配送サーバ３ｂは第１配送サービスを、第２配送サーバ３ｃは第２配送サービスを、決済サーバ３ｄは決済サービスを、第３配送サーバ３ｅは第３配送サービスを、それぞれ提供する。配送サーバ３ａは、第１配送サービス及び第２配送サービスを統合した配送サービスを提供する。第３配送サービスは、メタサービスである配送サービスの範囲外とする。ショッピングサーバ２は、配送サービス及び決済サービスを統合したメタサービスを提供する。
（２）処理の概要
図１６は、サービス管理装置１、ショッピングサーバ２、Ｗｅｂサーバ３ａ〜ｅが行う処理の流れを示す説明図である。まず図１６を参照し、ショッピングサービスにおける処理を説明する。
【００６１】
（２−１）サービス管理テーブルへのサーバの登録
まず、ユーザ端末４がショッピングサービスをショッピングサーバ２に要求する（＃４１）。すると、ショッピングサーバ２の管理Ｉ／Ｆ２２は、自分自身と、配送サーバ３ａ・決済サーバ３ｄのＵＲＬとを、サービス管理装置１に通知する（＃４２、＃４９、＃５２）。ショッピングサーバ２、配送サーバ３ａ及び決済サーバ３ｄのＵＲＬは、予定取得モジュール１１によりサービス管理テーブル１１１に登録される。
【００６２】
また、管理Ｉ／Ｆ２２は、配送サービスの予約を配送サーバ３ａに要求する（＃４３）。これに応じ、配送サーバ３ａは、第１配送サーバ３ｂ及び第２配送サーバ３ｃのＵＲＬを、サービス管理装置１に通知する（＃４４）。配送サービスの実行に必要な部品は、第１配送サービス及び第２配送サービスだからである。これらのＵＲＬは、予定取得モジュール１１により、サービス管理テーブル１１に登録される。
【００６３】
以上により、ショッピングサービスの部品である各Ｗｅｂサービスを提供しているＷｅｂサーバのＵＲＬが、サービス管理テーブル１１１に登録される。
（２−２）サービス管理テーブルへの予約サービス情報の登録
配送サーバ３ａは、ショッピングサーバ２からの配送サービスの要求（＃４２）に応じ、第１配送サーバ３ｂ、第２配送サーバ３ｃに対し、配送サービスの予約を要求する（＃４５，＃４７）。配送サーバ３ａは、この要求に対する応答を各Ｗｅｂサーバ３ｂ、３ｃから取得し、配送予定の登録通知をサービス管理装置１に送信する（＃４６，４８）。配送予定にはユーザの要求に合う配送予定、連絡先などを含む予約サービス情報が含まれる。
【００６４】
さらに、ショッピングサーバ２の管理Ｉ／Ｆ２２は、決済サービスの予約を決済サーバ３ｄに要求する（＃５０）。これに応じ、決済サーバ３ｄは、決済の予定を示す予約サービス情報を、サービス管理装置１に送信する（＃５１）。
各Ｗｅｂサーバ３ａ〜ｄからの予約サービス情報は、更新モジュール１２により、各ＷｅｂサーバのＵＲＬと対応付けてサービス管理テーブル１１１に書き込まれる。
【００６５】
その後、ショッピング処理の完了が、ショッピングサーバ２からユーザ端末４に通知される（＃５３）。
（２−３）監視テーブルへの登録
これらの処理とは独立に、任意のＷｅｂサーバ３、例えば第３配送サーバ３ｅは、配送サービスを監視対象とし、自分自身を監視者として、サービス管理装置１に登録の依頼を要求する（＃６０）。この依頼は、監視モジュール１４により受信され、監視テーブル１１２に書き込まれる。
【００６６】
（２−４）トラブルの通知
ところで、ショッピング処理の完了後、予定していた第１配送サービスが実行不可能になったとする。この場合、第１配送サーバ３ｂから第１配送サービスの中止通知がサービス管理サーバ１に送信される（＃６１）。サービス管理サーバ１の更新モジュール１２は、実行不可能となった第１配送サービスを統合する配送サーバ３ａに、このことを通知する（＃６２）。
【００６７】
（２−５）監視者への通知
第１配送サービスの中止は、第１配送サービスの監視者にも送信できる。サービス監視装置１の監視モジュール１４は、第１配送サービスが監視対象であるか否かを判断し、監視対象であればその監視者を監視テーブル１１２から読み出す。監視者が第２配送サーバ３ｃと第３配送サーバ３ｅであるとすると、まず第２配送サーバ３ｃに対し、第１配送サービスの予定変更を通知する（＃６３）。第３配送サーバ３ｅに対しては、配送サーバ３ａからの代行サービス要求（＃６４）を受信した後で通知すると良い（＃６５）。第３配送サーバ３ｅへの通知には、代行者が代行サービスを提供するために必要な情報が含まれている。例えば配送元、配送先、希望配送日、配送物などである。
【００６８】
（２−６）代行サービスの申し出と通知
ついで、サービス管理装置の代行モジュール１５は、代行サービスの申し出を、第３配送サーバ３ｄから受信する（＃６６）。この例では、この申し出は、ユーザの要求に合う配送サービスの内容、連絡先などを含む予約サービス情報と、第３配送サーバ３ｅのＵＲＬとを含む。これらの情報は、代行モジュール１５により代行テーブル１１３に書き込まれる。またこれらの情報は、代行モジュール１５から変更通知モジュール１３に供給され、配送サーバ３ａに送信される（＃６７）。
【００６９】
（２−７）サービス管理テーブルの更新
配送サーバ３ａの管理Ｉ／Ｆ２２は、代行サービスが決定すると、第１配送サービスをサービス管理テーブル１１１から削除するための処理を行う。まず配送サーバ３ａは、第１配送サービスのキャンセルを、第１配送サーバ３ｂとサービス管理装置１とに通知する（＃７１、＃７２）。この通知に応じ、サービス管理装置１の更新モジュール１２は、第１配送サービスの予約サービス情報のエントリを、サービス管理テーブル１１１から削除する。
【００７０】
ついで、配送サーバ３ａの管理Ｉ／Ｆ２２は、代行サービスをサービス管理テーブル１１１に登録してもらうための処理を行う。まず管理Ｉ／Ｆ２２は、第３配送サービスの予約を第３配送サーバ３ｅに要求し（＃７３）、第３配送サーバ３ｅの登録をサービス管理装置１に要求する（＃７４）。この要求に応じ、更新モジュール１２は、代行テーブル１１３に記憶されている第３配送サービスの予約サービス情報や第３配送サーバ３ｅのＵＲＬを、サービス管理テーブル１１１に登録する。
【００７１】
さらに、監視モジュール１４は、ショッピングサービスで実行する配送サービスを監視している配送サーバ３ａ及び第２配送サーバ３ｃに、代行の第３配送サービスの内容を送信する（＃７５，＃７６）。受信側は、第３配送サービスが第２配送サービスに代わって実行されることを知ることができる。
以上では、トラブルを例にとっているが、同様にして各Ｗｅｂサービスの実効状態をサービス管理装置１に通知することができる。従って、ショッピングサービスを構成する各Ｗｅｂサービスの状態がサービス管理装置１により一元的に管理される。これは、Ｗｅｂサービスそのものがメタサービスであっても同様である。そのため、ショッピングサービスの実効状態や、トラブルがあったときの原因などを、ショッピングサーバ２や各Ｗｅｂサーバ３がすぐに把握できる。また、トラブルに対する迅速な処置をとりやすく、ショッピングサービスの付加価値を高めることができる。しかも、ユーザに提供するメタサービスの実行状態や代行サービス案は、そのユーザの要求にあったものを提供することができる。
（３）各テーブルの具体例
次に、前記図１６に示す処理における、各テーブル１１１〜１１３の具体例を説明する。図１７は、当初の移動プランを実行するためのサービス管理テーブル１１１の内容を示す。図１８は、トラブル発生後のサービス管理テーブル１１１を示す。図１９は監視テーブル、図２０は代行テーブルの具体例を示す。図２１は、代行サービスが記述されたサービス管理テーブル１１１を示す。
【００７２】
（３−１）当初のサービス管理テーブル
まず図１７を参照する。実施例１と同様、サービス管理テーブル１１１は、サービスエントリテーブル、予約サービス情報テーブル、及び連絡先情報テーブルの３つのテーブルから構成されている。各テーブルに蓄積される情報の内容は実施例１と同様である。
【００７３】
（３−２）トラブル発生後のサービス管理テーブル
図１８は、第１配送サービスにトラブルが発生した通知を第１配送サーバ３ｂから受け（＃６１）、ついで配送サーバ３ａから代行サービスの要求を受けた（＃６４）後の予約サービス情報テーブルを示す。前記通知には、中止された予約サービス情報のリソースＩＤ“ＤＤ００１”が含まれている。これをキーに第１配送サービスの予約サービス情報が記述されたエントリが検索され、第１配送サービスの「状態」が「実行不可」に書き換えられる。また代行サービスの要求に応じ、「代行要求」が「あり」に書き換えられる。
【００７４】
（３−３）監視テーブル
図１９は、第２配送サーバ３ｃや第３配送サーバ３ｅなど、監視者からの監視要求が登録された監視テーブル１１２の一例を示す。記憶されている情報は、実施例１の監視テーブルと同様である。例えば、第１配送サービスのリソースＩＤは「ＤＤ００１」であり、種別ＩＤは「transport.kind」である。この場合、第１配送サービスの予定が変更されると、「ＤＤ００１」または「transport.kind」をキーとしてヒットする監視対象があるかどうかが検索される。この例では、第１配送サービスに生じた予定変更は、「www.transport.com」、「www.transport2.com」、「www.transport3.com」に通知される。なお、「www.transport.com」は配送サーバ３ａ、「www. transport1.com」は第２配送サーバ３ｃ、「www. transport3.com」は第２配送サーバ３ｅの識別子である。監視者への通知には、中止された第１配送サービスの予約サービス情報が含まれている。
【００７５】
（３−４）代行テーブル
図２０は、第３配送サーバ３ｅからの代行の申し出（＃６６）により更新された代行テーブル１１３の説明図である。記憶される情報は、前記実施例１の代行テーブルと同様である。この例では、代行サービス情報は、代行する予約サービス情報のリソースＩＤ「ＤＤ００１」、第３配送サービスの予定開始時刻、予定終了時刻、処理ＩＤ、第３配送サーバ３ｅのＵＲＬを含む。
【００７６】
（３−５）代行提案後のサービス管理テーブル
図２１は、図１６に示す処理の終了後のサービス管理テーブル１１１の状態を示す。同図（Ａ）のサービスエントリテーブルには、第１配送サービスのサーバＩＤ及び処理ＩＤに代えて、第３配送サービスのサーバＩＤ「www.transport3.com」と処理ＩＤ「Ｆ００００１」とが書き込まれている。同図（Ｂ）の予約サービス情報テーブルには、第１配送サービスに代えて、第３配送サービスの開始予定時刻や終了予定時刻、状態が書き込まれている。さらに同図（Ｃ）の連絡先情報テーブルには、第３配送サービスの連絡先情報が書き加えられている。
【００７７】
以上から、サービス管理テーブル１１１には、メタサービスであるショッピングサービスを構成する各Ｗｅｂサービスの状況の変化が実質的にリアルタイムに反映されていることが分かる。
［第３実施例］
前記実施例２において、メタサービスを提供する配送サーバ３ａが、第１配送サービスを代行する第３配送サービスを自ら検索する場合も考えられる。図２２は、その場合の処理の流れを示す説明図である。
【００７８】
処理＃４１〜＃５２までは実施例２と同様である。また、第３配送サーバ３ｅは監視要求を行わない。
ショッピング処理の完了後、予定していた第１配送サービスが実行不可能になると、第１配送サーバ３ｂから第１配送サービスの中止通知がサービス管理サーバ１に送信される（＃８１）。サービス管理サーバ１の更新モジュール１２は、実行不可能となった第１配送サービスを統合する配送サーバ３ａに、このことを通知する（＃８２）。
【００７９】
第１配送サービスの中止は、第１配送サービスの監視者にも送信される。サービス監視装置１の監視モジュール１４は、第１配送サービスが監視対象であるか否かを判断し、監視対象であればその監視者を監視テーブル１１２から読み出す。監視者が第２配送サーバ３ｃであるとすると、まず第２配送サーバ３ｃに対し、第１配送サービスの予定変更を通知する（＃８３）。
第３配送サーバ３ｅへの通知には、代行者が代行サービスを提供するために必要な情報が含まれている。例えば配送元、配送先、希望配送日、配送物などである。
【００８０】
ついで、配送サーバ３ａは、自ら代行サービスとして第３配送サービスを探し出し、第１配送サービスをサービス管理テーブル１１１から削除するための処理を行う。まず配送サーバ３ａは、第１配送サービスのキャンセルを、第１配送サーバ３ｂとサービス管理装置１とに通知する（＃８４、＃８５）。この通知に応じ、サービス管理装置１の更新モジュール１２は、第１配送サービスの予約サービス情報のエントリを、サービス管理テーブル１１１から削除する。
【００８１】
ついで、配送サーバ３ａの管理Ｉ／Ｆ２２は、代行サービスをサービス管理テーブル１１１に登録してもらうための処理を行う。まず管理Ｉ／Ｆ２２は、第３配送サービスの予約を第３配送サーバ３ｅに要求し（＃８６）、第３配送サービスの予約サービス情報を取得する。この予約サービス情報は、ユーザの要求に合う配送サービスの内容、連絡先などを含む。代行サービスの予約サービス情報と、第３配送サーバ３ｅのＵＲＬは、代行サービスの申し出として配送サーバ３ａからサービス管理装置１に送信される（＃８７）。この申し出は、更新モジュール１２によりサービス管理テーブル１１１に書き込まれる。
【００８２】
その後、予約サービス情報の更新が配送サーバ３ａと、監視者である第２配送サーバ３ｃとに通知される（＃８８，＃８９）。
（３）各テーブルの具体例
サービス管理テーブル１１１は、実施例２と同様の内容を有する。また、配送サーバ３が自ら代行サービスを探し出すため、代行テーブル１１３はこの実施例では用いない。
【００８３】
図２３は、実施例３における監視テーブル１１２の具体例である。第３配送サーバ(transport3.com)が「transport.kind」の監視者になっていない点を除き、前期実施例２と同様の内容を有している。
＜その他の実施形態例＞
（Ａ）本発明の適用範囲は、前述の例に限定されない。また、インターネット上に限らず、ネットワーク上で提供されるサービスを組み合わせて提供される全ての種類のメタサービスに適用可能である。
【００８４】
（Ｂ）ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
【００８５】
【発明の効果】
本発明を用いれば、複数のサービスを連携して実現されるメタサービスの実行状態を、各サービスの提供者に負担をかけることなく、メタサービスのユーザや各サービスの提供者に通知することができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態例を適用したサービス管理装置が動作する環境を示す説明図。
【図２】サービス管理装置１及びメタサービスサーバ２の機能構成を示すブロック図。
【図３】図１のサービス管理装置、メタサービスサーバ、Ｗｅｂサーバが行う処理の流れの一例を示す説明図（メタサービスサーバが代行サービスを検索する場合）。
【図４】図１のサービス管理装置、メタサービスサーバ、Ｗｅｂサーバが行う処理の流れの一例を示す説明図（サービス管理装置が代行サービスを検索する場合）。
【図５】実施例１に係るサービス管理装置１が動作する環境を示す説明図。
【図６】出張管理サービスにおける処理の流れの一例を示す説明図。
【図７】出張管理サービスの登録画面例。
【図８】移動プラン確認画面例。
【図９】移動プランの変更画面例。
【図１０】当初の移動プランを実行するためのサービス管理テーブルの概念説明図（実施例１）。
（Ａ）サービスエントリテーブル
（Ｂ）予約サービス情報テーブル
（Ｃ）連絡先情報テーブル
【図１１】トラブル発生後のサービス管理テーブル（予約サービス情報テーブル）の概念説明図（実施例１）。
【図１２】実施例１の監視テーブルの概念説明図。
【図１３】実施例１の代行テーブルの概念説明図。
【図１４】代行サービスが記述されたサービス管理テーブルの概念説明図（実施例１）。
（Ａ）サービスエントリテーブル
（Ｂ）予約サービス情報テーブル
（Ｃ）連絡先情報テーブル
【図１５】実施例２、３に係るサービス管理装置１が動作する環境を示す説明図。
【図１６】ショッピングサービスにおける処理の流れの一例を示す説明図（実施例２）。
【図１７】当初の購入処理を実行するためのサービス管理テーブルの概念説明図（実施例２）。
（Ａ）サービスエントリテーブル
（Ｂ）予約サービス情報テーブル
（Ｃ）連絡先情報テーブル
【図１８】トラブル発生後のサービス管理テーブル（予約サービス情報テーブル）の概念説明図（実施例２）。
【図１９】実施例２の監視テーブルの概念説明図。
【図２０】実施例２の代行テーブルの概念説明図。
【図２１】代行サービスが記述されたサービス管理テーブルの概念説明図（実施例２）。
（Ａ）サービスエントリテーブル
（Ｂ）予約サービス情報テーブル
（Ｃ）連絡先情報テーブル
【図２２】ショッピングサービスにおける処理の流れの一例を示す説明図（実施例３）。
【図２３】実施例３の監視テーブルの概念説明図。
【符号の説明】
１：サービス管理装置
１１：予定取得モジュール（予定取得ステップ）
１２：更新モジュール（サービス取得ステップ、状況取得ステップ、条項更新ステップ）
１３：変更通知モジュール（変更通知ステップ、状況通知ステップ、代行通知ステップ）
１４：監視モジュール（判別ステップ、監視ステップ、登録ステップ）
１５：代行モジュール（代行登録ステップ）
１１１：サービス管理テーブル（状況記憶ステップ）
１１２：監視テーブル（監視条件記憶ステップ）
１１３：代行テーブル
２：メタサービスサーバ
２１：ユーザＩ／Ｆ
２２：管理Ｉ／Ｆ
【発明の属する技術分野】
本発明は、インターネットなどのネットワーク上で提供されるサービスのより高度な統合を実現し、ネットワーク上での複数のサービス提供システムを連携する技術に関する。
以下では、ネットワーク上での複数のサービス提供システムを連携することにより提供される、より付加価値の高いサービスを、メタサービスという。
【０００２】
【従来の技術】
最近のインターネットの普及にともない、インターネット上でメタサービスを提供するための枠組みが提供されている。具体的には、ＸＭＬ(eXtensible Markup Language)技術の進歩により、コンピュータが直接アクセス可能なサービス部品（ビジネスコンポーネント）をインターネット上で公開・検索・実行することが可能になっている。サービス部品の公開・検索は、ＵＤＤＩ（Universal Description, Discovery and Integration）仕様によって行われる。また、サービス部品への処理（実行）の依頼と結果の受け取りは、ＳＯＡＰ（Simple Object Access Protocol）仕様によって行う。また、個々のサービス部品にどのように処理を依頼するかのサービス記述は、ＷＳＤＬ（Web Services Description Language）仕様に基づいて行う。このような仕組みによって、各サービス提供システムは、必要なサービス部品を発見し呼び出すことができる環境の構築が可能となっている。この環境は、Web Servicesアーキテクチャとして提案され、仕様の標準化作業が進められている。以下では、Web Servicesアーキテクチャに基づくサービス部品をＷｅｂサービスと呼ぶ。
【０００３】
更に、個々のＷｅｂサービスを組み合わせてメタサービスを構築するための仕組みが提案されている。その仕組みは、手続き表現（フロー）に基づいて、個々のＷｅｂサービスを呼び出すというものである。その手続き表現として、ＷＳＦＬ（Web Services Flow Language）、ＸＬＡＮＧなどが提案されている。フローに必要な部品、すなわちＷｅｂサービスは、ＵＤＤＩにアクセスして検索することにより、自動的に取得される。このようにして取得されたＷｅｂサービスを、順次呼び出して連携させることで、動的なサービス統合を行うことができる。１つのメタサービスは、別のメタサービスのＷｅｂサービス部品となることができる。
【０００４】
【発明が解決しようとする課題】
今後、Ｗｅｂサービスの普及につれて、複数のＷｅｂサービスを連携させたメタサービスが普及することが見込まれる。手続表現に基づいて呼び出される各Ｗｅｂサービスは、予め決まったメタサービスから呼び出されることを想定して作成されているわけではなく、どこから呼び出されるかは分からない。
【０００５】
一方、メタサービスを利用するユーザにとって、「実行を依頼したメタサービスの状態がどうなっているのか」は、知りたい情報の１つであると考えられる。すなわち、メタサービスを実行させている状態を通知する状態通知サービスが求められている。銀行振り込みのようにすぐに終了するサービスであれば、ユーザがその場ですぐに結果を得られるので、状態を問い合わせる必要もない。しかし例えば、インターネットで商品を購入した場合、購入操作自体はすぐに終了するものの、それと同時に商品が届くわけではない。実際には、購入操作により注文した商品を届けてもらうための段取りを、１）商品を手配するサービス提供システム、２）物流を行うサービス提供システム、３）お金の引き落としを行うサービス提供システムに対して行ったにすぎない。実際の商品の移動は、その段取りに従って、順次行われていくことになる。このような場合の商品の配送状態についての問い合わせは、やはり日常よく行われる行為である。
【０００６】
Ｗｅｂサービスを使用した環境で上記のような状態通知サービスを可能とするためには、個々のＷｅｂサービスが、呼び出し元の各メタサービスに対し、自分の状態の通知サービスを行えるようにする必要がある。そのためには、各Ｗｅｂサービスが、呼び出し元のメタサービスの情報を保存し、そこに対して呼び出しを行える処理能力を有していることが必要である。
【０００７】
しかし、Ｗｅｂサービスは様々なメタサービスから呼び出される可能性があり、その数が増えれば増えるほど、状態を通知するための処理コストが高くなる。個々のＷｅｂサービスがそのような処理コストを負担してまで状態通知サービスに対応することは、Ｗｅｂサービスの提供主体にとって負担が大きく、困難な場合が多いと考えられる。
【０００８】
複雑な段取りを行う場合でも、個々の段取りに使用する部品（各要素）が１つのシステムで構成されているような場合は、共通のデータベースに各部品の状態を保存することによって状態通知サービスを行うことができる。例えば、Ｆｅｄｅｘのトラッキングサービスなどは、そのような例にあたると考えられる。しかし、フローの個々のサービス部品がインターネット上に分散して存在するＷｅｂサービスである場合は、各種のメタサービスに対応した構成を各Ｗｅｂサービスに持たせることは現実的でない。従って、各メタサービスが、各Ｗｅｂサービスから直接状態通知を受け、状況を把握することは難しいと考えられる。
【０００９】
本発明は、Ｗｅｂサービスを連携して実現されるメタサービスの状態通知を、各Ｗｅｂサービスの提供者に負担をかけることなく実現することを目的とする。
また本発明は、メタサービスを利用するユーザに合う状態通知を、前記ユーザに行うことを目的とする。
【００１０】
【課題を解決するための手段】
前記課題を解決するために、本願第１発明は、コンピュータが行うサービス管理方法を提供する。このコンピュータは、ネットワーク上で提供されるサービスを統合して統合サービスを提供する複数のサービス統合装置と、前記サービスを提供するサービス提供装置群とに接続することができる。前記方法は以下のステップを含む。
・前記複数のサービス統合装置のそれぞれに要求された各統合サービスを実行するために必要な各サービスを提供する各サービス提供装置の識別子を、前記複数のサービス統合装置のそれぞれから取得する予定取得ステップ、
・前記各サービス提供装置が提供する各サービスを特定するサービス識別子を、前記各サービス提供装置から取得するサービス取得ステップ、
・前記各サービスのうちのいずれかの提供予定の変更を、そのサービスを提供するサービス提供装置から受信する状況取得ステップ、
・前記サービスの提供予定の変更を、前記予定取得ステップにおいてそのサービスを提供するサービス提供装置の識別子を送信してきたサービス統合装置に通知する変更通知ステップ。
【００１１】
この方法は、例えばメタサービスを提供するメタサービスサーバと、メタサービスの部品であるサービスの提供サーバと、に接続可能なコンピュータが実行する。このコンピュータは、実行予定のサービスと各サービスの提供サーバとを記憶しておき、いずれかのサービスの提供予定に変更が生じると、メタサービスサーバに通知する。複数のメタサービスから呼び出される可能性のある提供サーバを、いちいち各メタサービスに対応させた構成にすることなく、各種メタサービスの実行に不可欠なサービスの変更を各種メタサービスサーバに通知できる。従って、メタサービスサーバは、不測の事態によりメタサービスの実行が遅れている原因などを、ユーザに通知することができる。
【００１２】
本願第２発明は、前記第１発明において、前記状況取得ステップは、前記各サービスの実行状況を、前記各サービス提供装置からさらに取得するサービス管理方法を提供する。この方法は、以下のステップをさらに含む。
・前記各サービスの実行状況と前記各サービス識別子とを対応付けて記憶する状況記憶ステップ、
・前記状況取得ステップで取得した各サービスの実行状況に基づいて、記憶されたサービスの実行状況を更新する状況更新ステップ、
・前記各サービスの実行状況を、前記サービス統合装置に通知する状況通知ステップ。
【００１３】
この方法を実行するコンピュータは、メタサービスの実行に必要な各サービスの実行状況を、各サービスの提供装置から取得し、一元的に記憶している。従って、各サービスの実行状況をメタサービスサーバに通知すれば、メタサービスサーバはユーザにメタサービスの実行状況を通知することができる。
本願第３発明は、前記第１発明において、以下のステップをさらに含むサービス管理方法を提供する。
・任意のサービス提供装置により提供される少なくとも１つのサービスを指定する監視対象と、前記監視対象に生じた提供予定の変更を通知する監視者の識別子と、を対応付けて記憶する監視条件記憶ステップ、
・前記状況取得ステップで提供予定の変更が受信されたサービスが、監視対象に含まれているかどうかを判別する判別ステップ、
・提供予定が変更されたサービスが監視対象に含まれている場合、前記サービスの監視者に、前記サービスの提供予定の変更を通知する監視ステップ。
【００１４】
提供予定に変更が生じたサービスが監視対象である場合、生じた変更を監視者に通知する。監視者とは、例えば、同種のサービスを提供する同業他社のサービス提供装置や、変更が生じたサービスを部品に含むメタサービスを提供するサービス統合装置である。提供予定の変更を積極的に通知することにより、代行サービスの必要を通知し、迅速に代行サービスを見つけるきっかけを作ることができる。従って、メタサービス全体の実行への支障を最小限に押さえることにつながる。
【００１５】
本願第４発明は、前記第３発明において、前記監視対象及び監視者の識別子の登録を受け付ける登録ステップをさらに含むサービス管理方法を提供する。
監視者を広く募ることにより、不測のアクシデントに迅速かつ柔軟に対応しやすくなり、メタサービスの付加価値を間接的に高めることができる。
本願第５発明は、前記第１発明において、以下のステップをさらに含むサービス管理方法を提供する。
・提供予定が変更となったサービスに代わる代行サービスの識別子と、その代行サービスを提供する代行サービス提供装置の識別子と、を含む代行の申し出を受信する代行登録ステップ、
・前記代行サービス提供装置による代行サービスの提供予定を、前記サービス統合装置に通知する代行通知ステップ。
【００１６】
代行の申し出は、例えば前記監視者からなされることが考えられる。また例えば、予定が変更になったサービスと同種のサービスを統合して提供しているメタサービスサーバから代行の申し出が自発的になされることが考えられる。代行の申し出は、メタサービスサーバに通知される。これにより、メタサービスを構成する１つのサービスが実行不可能になった場合でも、メタサービス全体の実行に大きな支障を来すことなくメタサービスを実行することができる。つまり、代行の申し出を受け付けることは、メタサービスの危機管理体制を高め、メタサービスの付加価値を高めることにつながる。
【００１７】
本願第６発明は、前記第１発明の方法を実行するサービス管理装置を提供する。
本願第７発明は、前記第１発明の方法をコンピュータに実行させるサービス管理プログラムを提供する。
本願第８発明は、前記サービス管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
【００１８】
ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
【００１９】
【発明の実施の形態】
＜第１実施形態例＞
（１）全体構成
図１は、本発明の第１実施形態例を適用したサービス管理装置が動作する環境を示す。サービス管理装置１、メタサービスサーバ２、Ｗｅｂサーバ３ａ、３ｂ、３ｃ、ユーザ端末４及びＵＤＤＩ５は、ネットワーク６を介して接続される。この例では、ネットワーク６はインターネットである。Ｗｅｂサーバ３ａ、３ｂ、３ｃ（以下、Ｗｅｂサーバ３という）は、それぞれＷｅｂサービスＸ，Ｙ，Ｚを提供している。メタサービスサーバ２は、ＷｅｂサービスＸ，Ｙ，Ｚを統合したサービスであるメタサービスを、ユーザ端末４に提供する。各Ｗｅｂサーバ３のアドレスは、ＵＤＤＩ５から取得可能である。なお、各Ｗｅｂサービスがメタサービスであっても良い。つまり、Ｗｅｂサーバ３が、また別のＷｅｂサービスＰ１，Ｐ２・・・を統合したメタサービスを提供していても良い。サービス管理装置１は、メタサービスサーバ２からの通知に応じ、メタサービスの実行に必要なＷｅｂサービスの実行状況を管理する。
（２）サービス管理装置及びメタサービスサーバ
図２は、サービス管理装置１及びメタサービスサーバ２の機能構成を示すブロック図である。まず、メタサービスサーバ２について説明し、ついでサービス管理装置１について説明する。
【００２０】
（２−１）メタサービスサーバ
メタサービスサーバ２は、ユーザインターフェース（以下、ユーザＩ／Ｆという）２１と、管理インターフェース（以下、管理Ｉ／Ｆという）２２とを有している。
ユーザＩ／Ｆ２１は、メタサービスの要求を、ユーザ端末４から受け付ける。また、ユーザＩ／Ｆ２１は、ユーザ端末４に、メタサービスの実行に必要なＷｅｂサービスのいずれかの提供予定が変更したことを通知する。
【００２１】
管理Ｉ／Ｆ２２は、メタサービスの要求を解釈し、メタサービスの実行に必要な各ＷｅｂサービスＸ，Ｙ，Ｚを提供するＷｅｂサーバ３の識別子を、サービス管理装置１に通知する。各Ｗｅｂサービスを提供するＷｅｂサーバ３の識別子は、例えばＵＲＬ(Uniform Resource Locator)で記述され、ＵＤＤＩ５から取得可能である。また管理Ｉ／Ｆ２２は、サービス管理装置１に通知した各Ｗｅｂサービスのうち、いずれかのＷｅｂサービスＸの提供予定の変更を、サービス管理装置１から受信する。
【００２２】
さらに、管理Ｉ／Ｆ２２は各ＷｅｂサービスＸ，Ｙ，Ｚの実行状況をサービス管理装置１から受信し、ユーザＩ／Ｆ２１はその実行状況をユーザ端末４に通知することが好ましい。ユーザＩ／Ｆ２１からユーザ端末４への予定変更の通知や、実行状況の通知は、ユーザ端末４からの要求に応じて行っても良いが、プッシュ方式で強制的に通知しても良い。不測の事態によりサービスの実行予定が狂ったことをユーザに迅速に通知でき、メタサービスの付加価値が高まると期待できる。
【００２３】
（２−２）サービス管理装置
（２−２−１）基本構成
サービス管理装置１は、基本的にはモジュール群１１〜１３と、サービス管理テーブル１１１を有している。予定取得モジュール１１は、メタサービスサーバ２に要求されたメタサービスを実行するために必要な各Ｗｅｂサービスを提供する各Ｗｅｂサーバ３の識別子を、メタサービスサーバ２から取得する。Ｗｅｂサーバ３の識別子はＵＲＬなどで記述される。取得したＷｅｂサーバ３の識別子（図中、サーバＩＤと記載）は、サービス管理テーブル１１１に記憶される。
【００２４】
更新モジュール１２は、必要なＷｅｂサービスを特定するサービス識別子（図中、サービスＩＤと記載）を、各Ｗｅｂサーバ３から取得し、サービス管理テーブル１１１に書き込む。サービス識別子は、各Ｗｅｂサーバ３により生成される。更新モジュール１２は、受信したサービス識別子を、サービス管理装置１内でユニークな識別子により識別しても良い。また、更新モジュール１２は、前記各Ｗｅｂサービスのうちのいずれかの提供予定の変更を、そのＷｅｂサービスを提供するＷｅｂサーバ３から受信する。提供予定の変更とは、例えば予定していたＷｅｂサービスを提供できなくなったことが挙げられる。
【００２５】
変更通知モジュール１３は、前記Ｗｅｂサービスの提供予定の変更を、メタサービスサーバ２に通知する。この通知は、メタサービスサーバ２からの要求に応じて行っても良いが、プッシュ方式で強制的に行うことも好ましい。メタサービスの実行にトラブルが起きたことを迅速に通知でき、メタサービスの付加価値を高めることに間接的に寄与できると考えられる。
【００２６】
このような構成のサービス管理装置１をネットワーク６上に設けることにより、複数のメタサービスから呼び出される可能性のあるＷｅｂサーバ３を、いちいち各メタサービスに対応させた構成にすることなく、各種メタサービスの実行に不可欠なＷｅｂサービスの予定変更を各種メタサービスサーバ２に通知できる。従って、メタサービスサーバ２は、不測の事態によりメタサービスの実行が遅れている原因などを、ユーザ端末４に通知することができる。
【００２７】
（２−２−２）Ｗｅｂサービスの実行状況の把握
上述の基本機能に加え、前記更新モジュール１２は、メタサービスの実行に必要な各Ｗｅｂサービスの予約内容や実行状況、Ｗｅｂサービスに関する連絡先などを、各Ｗｅｂサーバ３からさらに取得することが好ましい。取得した予約内容や実行状況、連絡先は、各Ｗｅｂサービスの識別子及び各Ｗｅｂサーバ３の識別子と対応付けて、サービス管理テーブル１１１に記憶される。さらに、更新モジュール１２は、各Ｗｅｂサービスの実行状況を新たに受信すると、サービス管理テーブル１１１に記憶されている該当サービスの実行状況を更新する。実行状況は、例えば更新されるたびに、変更通知モジュール１３によりメタサービスサーバ２に通知される。この通知も、前記と同様の理由から、プッシュ方式で行うことが好ましい。
【００２８】
この構成を有するサービス管理装置１は、メタサービスの実行に必要な各Ｗｅｂサービスの内容及びその実行状況を、一元的に管理する。従って、各Ｗｅｂサービスの実行状況を把握してメタサービスサーバに通知でき、メタサービスの付加価値をさらに高めることができる。
（２−２−３）予定変更の監視
サービス管理装置１は、上述の構成にくわえ、監視モジュール１４と監視テーブル１１２とを有していることが好ましい。監視テーブル１１２は、監視対象と、監視者の識別子とを対応付けて記憶している。監視対象は、Ｗｅｂサーバ３により提供される少なくとも１つのＷｅｂサービスを指定する。監視対象としては、例えば以下のデータａ）〜ｃ）が記述される。
ａ）Ｗｅｂサーバの識別子、
ｂ）Ｗｅｂサービスの種類を示す識別子、
ｃ）サービス管理テーブル１１１に記憶されているいずれかのＷｅｂサービスの識別子。
【００２９】
監視者とは、前記監視対象であるＷｅｂサービスに生じた提供予定の変更の通知先である。監視者の具体例としては、以下のａ）、ｂ）が挙げられる。監視者の識別子は、例えばＵＲＬで記述される。
ａ）キャンセルされたサービスと同種のサービスを提供する同業他社のサービス提供装置、
ｂ）変更が生じたサービスを部品に含むメタサービスを提供するメタサービスサーバ２。
【００３０】
監視モジュール１４は、提供予定が変更されたＷｅｂサービスが、監視対象に含まれているかどうかを判断し、含まれていれば前記Ｗｅｂサービスの監視者に
前記Ｗｅｂサービスの提供予定の変更を通知する。さらに、監視モジュール１４は、要求に応じて監視対象及び監視者の識別子の登録を受け付け、監視テーブル１１２を更新すると良い。
【００３１】
提供予定に変更が生じたＷｅｂサービスが監視対象である場合、生じた変更を監視者に通知する。提供予定の変更を積極的に通知することにより、監視者に代行サービスの必要を通知し、迅速に代行サービスを見つけるきっかけを作ることができる。また監視者の登録を受け付けることで代行サービスが提供される確率が高くなるので、不測のアクシデントに迅速かつ柔軟に対応しやすくなる。結果として、メタサービスの付加価値を間接的に高めることができる。
【００３２】
（２−２−４）代行サービス
上述の構成に加え、サービス管理装置１は、代行モジュール１５と、代行テーブル１１３とをさらに有することが好ましい。代行モジュール１５は、代行の申し出を受信する。この代行の申し出には、提供予定が変更となったＷｅｂサービスに代わる代行Ｗｅｂサービスの識別子（図中、代行サービスＩＤと記載）と、その代行Ｗｅｂサービスを提供する代行Ｗｅｂサーバの識別子と、が含まれる。代行サービスの識別子と代行Ｗｅｂサーバの識別子とは、代行テーブル１１３に記憶され、またサービス管理テーブル１１１にも書き込まれる。その結果、代行サービスがメタサービスサーバ２に通知される。
【００３３】
代行の申し出は、例えばＷｅｂサービスの提供予定の変更を受けた監視者からなされる。また例えば、予定が変更になったＷｅｂサービスと同種のＷｅｂサービスを統合して提供しているメタサービスサーバから、代行の申し出が自発的になされてもよい。別のウェブサーバによる代行サービスを受け付けることにより、メタサービスを構成する１つのサービスが実行不可能になった場合でも、メタサービス全体の実行に大きな支障を来すことなくメタサービスを実行することができる。つまり、メタサービスの危機管理体制を高め、メタサービスの付加価値を高めることにつながる。
（３）処理の流れ
次に図３を参照し、前述の構成を有するサービス管理装置１、メタサービスサーバ２、Ｗｅｂサーバ３が行う処理の流れについて説明する。説明を容易にするために、メタサービスサーバ２は、ＷｅｂサービスＸとＷｅｂサービスＹとを統合したメタサービスを提供しているとする。
【００３４】
（３−１）メタサービスが代行サービスを検索する場合
まず、ユーザ端末４からメタサービスサーバ２に対し、メタサービスの提供要求が発生する（＃１０１）。要求はメタサービスサーバ２の管理Ｉ／Ｆ２２によりにより解釈される。ついで、要求されたメタサービスの実行に必要なＷｅｂサービスを提供するＷｅｂサーバ３の識別子が、管理Ｉ／Ｆ２２によりサービス管理装置１に通知される（＃１０２）。通知されたＷｅｂサーバの識別子は、予定取得モジュール１１が受信し、更新モジュール１２によりサービス管理装置１のサービス管理テーブル１１１に書き込まれる。
【００３５】
さらに、メタサービスの実行に必要なＷｅｂサービスＸ，Ｙの予約要求が、メタサービスサーバ２の管理Ｉ／Ｆ２２からＷｅｂサーバ３ａ，３ｂに送信される（＃１０３，＃１０５）。これに対し、各Ｗｅｂサーバ３ａ，３ｂが提供するＷｅｂサービスの識別子が、Ｗｅｂサーバ３ａ，３ｂからサービス管理装置１に送信される（＃１０４，＃１０６）。Ｗｅｂサービスの識別子は、更新モジュール１２により取得され、Ｗｅｂサーバ３ａ、３ｂの識別子と対応付けてサービス管理テーブル１１１に記憶される。
【００３６】
その後、トラブルの発生により、例えばＷｅｂサービスＹの提供が不可能になったとする。その場合、ＷｅｂサービスＹの予定変更通知が、Ｗｅｂサーバ３ｂからサービス管理装置１に送信される（＃１０７）。これを受け、サービス管理テーブル１１１の該当Ｗｅｂサービスの識別子と、Ｗｅｂサーバ３ｂの識別子とが、更新モジュール１２により削除される。サービス管理テーブル１１１が更新されると、その更新内容が、更新モジュール１２から変更通知モジュール１３に渡され、メタサービスサーバ２に送信される（＃１０８）。メタサービスサーバ２は、例えばプッシュ方式でメタサービスの実行予定の変更をユーザ端末４に送信する（＃１０９）。
【００３７】
いま、メタサービスサーバ２の管理Ｉ／Ｆ２２は、自分が提供するメタサービスの範囲内で代行サービスを検索することができるとする。管理Ｉ／Ｆ２２は、ＷｅｂサービスＹと同種のＷｅｂサービスＺを提供するＷｅｂサーバ３ｃに、サービスＺの予約要求を送信する（＃１１０）。これに対応し、代行ＷｅｂサービスＺの識別子と、Ｗｅｂサーバ３ｃの識別子とが、Ｗｅｂサーバ３ｃからサービス管理サーバ１に送信される（＃１１１）。代行ＷｅｂサービスＺの識別子と代行Ｗｅｂサーバ３ｃの識別子とは、代行モジュール１５により受信され、代行テーブル１１３に書き込まれる。また、これらのデータは更新モジュール１２に渡され、サービス管理テーブル１１１に書き込まれる。サービス管理テーブル１１１が更新されるので、更新内容が更新モジュール１２から変更通知モジュール１３に渡され、メタサービスサーバ２に通知される（＃１１２）。これを受け取ったメタサービスサーバ２は、ＷｅｂサービスＹに代えて代行ＷｅｂサービスＺが提供されることを、ユーザ端末４に通知する（＃１１３）。
【００３８】
上記の例はトラブルを例にとっているが、同様にして、各Ｗｅｂサービスの実効状態が変わるたびにサービス管理装置１に通知することができる。従って、以上の処理により、メタサービスを実行するのに必要なＷｅｂサービスの状態を一元的に管理し、ユーザに提供することが可能となる。また、いずれかのＷｅｂサービスの予定が変更になった場合であっても、代行サービスが提供されることをサービス管理装置１が把握でき、また代行サービスの提案をメタサービスを介してユーザに通知することができる。
【００３９】
（３−２）監視テーブルを用いる場合
前記＃１１０〜＃１１３の処理は、メタサービスサーバ２が代行サービスの検索機能を有する場合の処理を示している。しかし、メタサービスサーバ２がその機能を有さない場合、監視テーブル１１２を用いた図４に示す処理が実行される。説明を容易にするために、監視テーブル１１２には、監視対象をＷｅｂサービスＹ、監視者をＷｅｂサーバ３ｃとするレコードが記憶されていたとする。
【００４０】
処理＃１０１〜＃１０９までは前述と同様に行われる。そうすると、メタサービスサーバ２の管理Ｉ／Ｆ２２は、ＷｅｂサービスＹの代行サービスを、サービス管理装置１に要求する（＃２１０）。この要求を受け、サービス管理装置１の監視モジュール１４は、ＷｅｂサービスＹの監視者であるＷｅｂサーバ３ｃに、ＷｅｂサービスＹの予定が変更になったことを通知する（＃２１１）。複数の監視者が存在する場合には、各監視者にこの通知が送信される。
【００４１】
ついで、代行モジュール１５が、Ｗｅｂサーバ３ｃから代行の申し出を受信する（＃２１２）。複数の監視者に予定の変更を通知している場合には、そのいずれかから代行の申し出を受信する。この申し出には、代行ＷｅｂサービスＺの識別子とＷｅｂサーバ３ｃの識別子とが含まれる。代行ＷｅｂサービスＺの識別子と代行Ｗｅｂサーバ３ｃの識別子とは、代行モジュール１５により代行テーブル１１３に書き込まれる。また、これらのデータは更新モジュール１２に渡され、サービス管理テーブル１１１に書き込まれる。サービス管理テーブル１１１が更新されるので、更新内容が更新モジュール１２から変更通知モジュール１３に渡され、メタサービスサーバ２に通知される（＃２１３）。これを受け取ったメタサービスサーバ２は、ＷｅｂサービスＹに代えて代行ＷｅｂサービスＺが提供されることを、ユーザ端末４に通知する（＃２１４）。
【００４２】
以上の処理により、メタサービスやＷｅｂサービスに代行サービスを検索する機能がない場合であっても、代行サービスの提供を監視者から募り、メタサービスの実行を行うことができる。
［実施例１］
（１）構成
次に、本発明の一実施例を参照し、本発明をより具体的に説明する。図５は、実施例１に係るサービス管理装置１が動作する環境を示す。サービス管理装置１、出張管理サーバ２、Ｗｅｂサーバ群３ａ〜ｄ、ユーザ端末４及びＵＤＤＩ５は、インターネット６により接続される。飛行機予約サーバ３ａは飛行機予約サービスを、宿予約サーバ３ｂは宿予約サービスを、電車時刻サーバ３ｃは交通機関の乗り換えルート計算サービスを、それぞれ提供する。出張管理サーバ２は、飛行機予約サーバ３ａ、宿予約サーバ３ｂ、電車時刻サーバ３ｃの各サービスを統合したメタサービスを提供する。新幹線予約サーバ３ｄは新幹線予約サービスを提供している。このＷｅｂサービスは、出張管理サーバ２のメタサービスの範囲外である。
（２）処理の概要
図６は、サービス管理装置１、出張管理サーバ２、Ｗｅｂサーバ３ａ〜ｄが行う処理の流れを示す説明図である。まず図６を参照し、出張管理サービスにおける処理を説明する。
【００４３】
（２−１）サービス管理テーブルへのサーバの登録
まず、ユーザ端末４が出張管理サービスを出張管理サーバ２に要求する（＃１）。例えば、出張管理サーバ２の管理Ｉ／Ｆ２２は、図７に例示する画面をユーザ端末４に提供し、出張管理サービスの実行に必要なデータを取得する。ついで、出張管理サーバ２の管理Ｉ／Ｆ２２は、自分自身と、飛行機予約サーバ３ａ・宿予約サーバ３ｂのＵＲＬとを、サービス管理装置１に通知する（＃２、＃５、＃８）。出張管理サービスをするために状態の管理が必要なＷｅｂサービスは、飛行機予約サービスと宿予約サービスだからである。サービス管理装置１の予定取得モジュール１１は、出張管理サーバ２、飛行機予約サーバ３ａ、及び宿予約サーバ３ｂのＵＲＬを、サービス管理テーブル１１１に登録する。
【００４４】
（２−２）サービス管理テーブルへの予約サービス情報の登録
また、管理Ｉ／Ｆ２２は、飛行機予約サーバ３ａ、宿予約サーバ３ｂに、Ｗｅｂサービスの予約を要求する（＃３，＃６）。これに応じ、飛行機予約サーバ３ａからはフライト予定の登録通知がサービス管理装置１に送信される（＃４）。この通知には、ユーザの要求に合うフライト予約内容、連絡先などを含む予約サービス情報が含まれる。また、宿予約サーバ３ｂからは宿泊予定の登録通知がサービス管理装置１に送信される（＃７）。この通知には、ユーザの要求に合う宿予約内容、連絡先などを含む予約サービス情報が含まれる。各Ｗｅｂサーバ３ａ、３ｂからの予約サービス情報は、サービス管理テーブル１１１に飛行機予約サーバ３ａ及び宿予約サーバ３ｂのＵＲＬと対応付けて記憶される。書き込まれた内容は、更新モジュール１２から変更通知モジュール１２に渡され、出張管理サーバ２に通知される。
【００４５】
（２−３）出張管理サービスの予定の通知
出張管理サーバ２は、管理Ｉ／Ｆ２２により電車時刻サーバ３ｃに電車の乗り換えルートの計算を要求し、その結果を取得する（＃９）。取得した乗り換えルートは、飛行機の予約サービス情報及び宿の予約サービス情報とともに、一括してユーザＩ／Ｆ２１からユーザ端末４に提供される（＃１０）。図８は、出張管理サーバ２が提供する移動プランの提示画面例である。サービス管理装置１を介して取得した飛行機の予約サービス情報及び宿の予約サービス情報が、乗り換えルートと共に表示されている。
【００４６】
（２−４）監視テーブルへの登録
これらの処理とは独立に、新幹線予約サーバ３ｄ及び宿予約サーバ３ｂは、飛行機や電車など輸送サービスを監視対象とし、自分自身を監視者として、サービス管理装置１に登録の依頼を要求する（＃２０）。この依頼は、監視モジュール１４により受信され、監視テーブル１１２に書き込まれる。
【００４７】
（２−５）トラブルの通知
ところで、移動プランの決定後、天候悪化などにより予定していた往路のフライトが飛ばなくなったとする。この場合、飛行機予約サーバ３ａから往路のフライトの中止通知がサービス管理サーバ１に送信される（＃２１）。サービス管理サーバ１の更新モジュール１２は、この通知を受信すると、実行不可能となったサービスを出張管理サーバ２に通知する（＃２２）。
【００４８】
（２−６）監視者への通知
サービス監視装置１の監視モジュール１４は、飛行機の予約サービスが監視対象であるか否かを判断する。監視対象であれば、飛行機予約サービスを監視対象としている監視者のうち、宿予約サーバ３ｂに対し、飛行機予約サービスの予定変更を通知する（＃２３）。同様にして、監視者のうち新幹線予約サーバ３ｄに対しても通知する（＃２５）。また新幹線予約サーバ３ｄに対するこの通知を、出張管理サーバ２からの要求（＃２４）に応じて行っても良い（＃２５）。新幹線予約サーバに対する通知には、代行者が代行サービスを提供するために必要な情報が含まれている。例えば出発地、目的地、出発日時などである。
【００４９】
（２−７）代行サービスの申し出と通知
ついで、サービス管理装置の代行モジュール１５は、代行サービスの申し出を、新幹線予約サーバ３ｄから受信する（＃２６）。この例では、この申し出は、ユーザの要求に合う新幹線の予約内容、連絡先などを含む予約サービス情報と、新幹線予約サーバ３ｄのＵＲＬとを含む。これらの情報は、代行モジュール１５により代行テーブル１１３に書き込まれる。またこれらの情報は、代行モジュール１５から変更通知モジュール１３に供給され、出張管理サーバ２に送信される（＃２７）。その後、出張管理サーバ２は、再度乗り換えルートの算出を電車時刻サーバ３ｃに要求した後（＃２８）、変更後の移動プランをユーザ端末４に提供する（＃２９）。図９は、変更後の移動プランの表示例である。この画面例は、変更後の移動プランをユーザが承認するか否かの選択を受け付ける。
【００５０】
（２−８）サービス管理テーブルの更新
出張管理サーバ２の管理Ｉ／Ｆ２２は、変更後のプランに対するユーザの承認がでると、往路の飛行機予約サービスをサービス管理テーブル１１１から削除するための処理を行う。もちろん、ユーザの承認なしに以下の処理を行うことも可能である。まず管理Ｉ／Ｆ２２は、当初の往路の飛行機のキャンセルを、飛行機予約サーバ３ａとサービス管理装置１とに通知する（＃３０、＃３１）。この通知に応じ、サービス管理装置１の更新モジュール１２は、往路の飛行機の予約サービス情報のエントリを、サービス管理テーブル１１１から削除する。また、飛行機予約サービスを監視対象としている宿予約サーバ３ｂに、往路の飛行機予約サービスがキャンセルされたことを通知する（＃３２）。この通知は、代行サービスを申し出た監視者には通知しなくてよい。
【００５１】
ついで、出張管理サーバ２の管理Ｉ／Ｆ２２は、代行サービスをサービス管理テーブル１１１に登録してもらうための処理を行う。まず管理Ｉ／Ｆ２２は、往路の新幹線の予約を新幹線予約サーバ３ｄに要求（＃３３）し、新幹線予約サーバ３ｄの登録をサービス管理装置１に要求する（＃３４）。この要求に応じ、更新モジュール１２は、代行テーブル１１３に記憶されている新幹線の予約サービス情報や新幹線予約サーバ３ｄのＵＲＬを、サービス管理テーブル１１１に登録する。さらに、出張管理サービスで実行する輸送サービスに変更が生じたので、輸送サービスを監視している宿予約サーバ３ｂに、新たな輸送サービスの内容が送信される（＃３５）。受信側は、飛行機に代わり、新幹線によるサービスが実行されることを知ることができる。
【００５２】
以上では、トラブルを例にとっているが、同様にして各Ｗｅｂサービスの実効状態をサービス管理装置１に通知することができる。従って、出張管理サービスを構成する各Ｗｅｂサービスの状態が、サービス管理装置１により一元的に管理される。そのため、出張管理サービスの実行状況や、トラブルがあったときのその原因などを、出張管理サーバ２や各Ｗｅｂサーバ３がすぐに把握でき、出張管理サービスの付加価値が高まる。例えばユーザだけでなく、出張管理サービスの部品を提供するＷｅｂサービス提供者も、出張管理サービスの状態を知ることができるようになる。しかも、トラブルに対する代行サービスを出張管理サービスに提案可能なため、トラブルが生じたときにも出張管理サービス全体の実行に大きな支障がでることを防止できる。さらに、ユーザに提供するメタサービスの実行状態や代行サービス案は、そのユーザの要求にあったものを提供することができる。
（３）各テーブルの具体例
次に、前記図６に示す処理における、各テーブル１１１〜１１３の具体例を説明する。図１０は、当初の移動プランを実行するためのサービス管理テーブル１１１の内容を示す。図１１は、トラブル発生後のサービス管理テーブル１１１を示す。図１２は監視テーブル、図１３は代行テーブルの具体例を示す。図１４は、代行サービスが記述されたサービス管理テーブル１１１を示す。
【００５３】
（３−１）当初のサービス管理テーブル
まず図１０を参照する。この例では、サービス管理テーブル１１１は、サービスエントリテーブル、予約サービス情報テーブル、及び連絡先情報テーブルの３つのテーブルから構成されている。サービスエントリテーブルには、Ｗｅｂサービスを提供するＷｅｂサーバの識別子「サーバＩＤ」、予約サービス情報の識別子「サービスＩＤ」、連絡先情報の識別子「連絡先情報ＩＤ」が対応付けられている。予約サービス情報の詳細は、予約サービス情報テーブルに記述されている。連絡先情報の詳細は、連絡先情報テーブルに記述されている。従って、サービスＩＤ及び連絡先情報ＩＤは、サーバＩＤと、サービスの実行状況を含む予約サービス情報と、連絡先情報とを対応付けるためのキーとなっている。
【００５４】
また、「ノード番号」、「親ノード番号」、「処理ＩＤ」及び「種別ＩＤ」が、前述の情報と対応付けられて記憶されている。「ノード番号」は、予約サービスの実行順序を示す。ただし、必ずしも通し番号や連番である必要はない。「親ノード番号」は、ノード番号で特定される予約サービスの前に実行される予約サービスのノード番号である。ノード番号と親ノード番号とが同一の場合、そのレコードのサーバＩＤで特定されるＷｅｂサーバがメタサービスの提供者であることを示す。この図では、ノード番号及び親ノード番号が「１００」のwww.travel.comが、ノード番号１０１−１０３の各Ｗｅｂサービスを統合していることを示す。「処理ＩＤ」は、Ｗｅｂサーバ３が行う内部処理をＷｅｂサーバ３自身が識別するための識別子である。「種別ＩＤ」は、Ｗｅｂサービスの種類を表す。この例では、“travel.kind”は出張管理サービスを、“passenger.kind”は飛行機予約や新幹線予約などの輸送サービスを、“hotel.kind”はホテルや旅館など宿泊サービスを示す。
【００５５】
予約サービス情報テーブルには、予約サービス情報が、サービスＩＤと対応付けられて記憶されている。この例では、予約サービス情報は、「リソースＩＤ」、「予定情報」、「代行要求」、「実行状況」を含む。「リソースＩＤ」は、各Ｗｅｂサーバ３が、予約サービス情報を識別するための識別子である。「予定情報」は、Ｗｅｂサービスの「開始予定時刻」と「終了予定時刻」とを含む。「代行要求」は、各Ｗｅｂサービスが実行不可能になった場合に、その代行サービスの検索を要求されているか否かを示す。「実行状況」は、各Ｗｅｂサービスの「開始時刻」、「終了時刻」、実行待ち／実行中／実行済みを示す「状態」を含む。予約サービス情報は、各Ｗｅｂサーバ３からサービス管理装置１の更新モジュール１２に送信される。
【００５６】
連絡先情報テーブルには、連絡先情報が、連絡先情報ＩＤと対応付けられて記憶されている。この例では、連絡先情報は、「担当者」、「電話番号」、「電子メールアドレス」を含む。連絡先情報は、各Ｗｅｂサーバ３からサービス管理装置１の更新モジュール１２に送信される。
（３−２）トラブル発生後のサービス管理テーブル
図１１（Ａ）は、飛行機予約サービスにトラブルが発生した通知を飛行機予約サーバ３ａから受けた（＃２１）直後の予約サービス情報テーブルを示す。前記通知には、中止された予約サービス情報のリソースＩＤ“ＢＢ００１”が含まれている。これをキーに予約サービス情報テーブルのエントリが検索され、飛行機予約サービスを示すエントリの「状態」が「実行不可」に書き換えられる。
【００５７】
図１１（Ｂ）は、さらにその後、出張管理サーバ２から代行サービスの要求を受けた（＃２４）後の予約サービス情報テーブルを示す。要求に応じ、飛行機予約サービスの代行サービスの「代行要求」が「あり」に書き換えられている。
（３−３）監視テーブル
図１２は、宿予約サーバ３ｂや新幹線予約サーバ３ｄなど、監視者からの監視要求が登録された監視テーブル１１２の一例を示す。この例では、監視者ＩＤ、監視対象、通知先が対応付けられて記憶されている。監視者ＩＤは、監視対象に生じる予定の変更を監視している主体の識別子、例えばＵＲＬである。監視対象は、この例では監視リソースＩＤ及び／または監視種別ＩＤで特定される。例えば、往路の飛行機予約サービスのリソースＩＤは「ＢＢ００１」であり、種別ＩＤは「passenger.kind」である。この場合、飛行機予約サービスの予定が変更されると、「ＢＢ００１」または「passenger.kind」をキーとしてヒットする監視対象があるかどうかが検索される。通知先は、ヒットした監視対象の予定の変更を通知する先であり、この例では監視者ＩＤと一致している。この例では、飛行機予約サービスに生じた予定変更は、「www.travel.com」、「www.hotel.com」、「www.train.com」に通知される。なお、「www.travel.com」は出張管理サーバ２、「www.hotel.com」は宿予約サーバ３ｂ、「www.train.com」は新幹線予約サーバ３ｄの識別子である。また、監視者への通知には、中止された往路の飛行機予約サービスの予約サービス情報が含まれている。
【００５８】
（３−４）代行テーブル
図１３は、新幹線予約サーバ３ｄからの代行の申し出（＃２６）により更新された代行テーブル１１３の説明図である。代行テーブルには、代行されるＷｅｂサービスの内容を示す代行サービス情報が、代行ＷｅｂサーバＩＤと対応付けられて記憶されている。この例では、代行サービス情報は、「リソースＩＤ」、「予定情報」を含む。「リソースＩＤ」は、代行する予約サービス情報のリソースＩＤを示す。「予定情報」は、代行サービスの「開始予定時刻」と「終了予定時刻」とを含む。
【００５９】
（３−５）代行提案後のサービス管理テーブル
図１４は、図６に示す処理の終了後のサービス管理テーブル１１１の状態を示す。同図（Ａ）のサービスエントリテーブルには、往路の飛行機予約サービスのサーバＩＤ及び処理ＩＤに代えて、新幹線予約サービスのサーバＩＤ「www.train.com」と処理ＩＤ「Ｆ００００１」とが書き込まれている。同図（Ｂ）の予約サービス情報テーブルには、往路の飛行機予約サービスに代えて、新幹線予約サービスの開始予定時刻や終了予定時刻、状態が書き込まれている。さらに同図（Ｃ）の連絡先情報テーブルには、新幹線予約サービスの連絡先情報が書き加えられている。すなわち、サービス管理テーブル１１１には、代行サービスが登録されていることが分かる。
【００６０】
以上から、サービス管理テーブル１１１には、メタサービスである出張管理サービスを構成する各Ｗｅｂサービスの状況の変化が実質的にリアルタイムに反映されていることが分かる。
［実施例２］
（１）構成
次に、本発明の別の実施例を参照し、本発明をさらに具体的に説明する。図１５は、実施例２に係るサービス管理装置１が動作する環境を示す。サービス管理装置１、ショッピングサーバ２、Ｗｅｂサーバ群３ａ〜ｄ、ユーザ端末４及びＵＤＤＩ５は、インターネット６により接続される。第１配送サーバ３ｂは第１配送サービスを、第２配送サーバ３ｃは第２配送サービスを、決済サーバ３ｄは決済サービスを、第３配送サーバ３ｅは第３配送サービスを、それぞれ提供する。配送サーバ３ａは、第１配送サービス及び第２配送サービスを統合した配送サービスを提供する。第３配送サービスは、メタサービスである配送サービスの範囲外とする。ショッピングサーバ２は、配送サービス及び決済サービスを統合したメタサービスを提供する。
（２）処理の概要
図１６は、サービス管理装置１、ショッピングサーバ２、Ｗｅｂサーバ３ａ〜ｅが行う処理の流れを示す説明図である。まず図１６を参照し、ショッピングサービスにおける処理を説明する。
【００６１】
（２−１）サービス管理テーブルへのサーバの登録
まず、ユーザ端末４がショッピングサービスをショッピングサーバ２に要求する（＃４１）。すると、ショッピングサーバ２の管理Ｉ／Ｆ２２は、自分自身と、配送サーバ３ａ・決済サーバ３ｄのＵＲＬとを、サービス管理装置１に通知する（＃４２、＃４９、＃５２）。ショッピングサーバ２、配送サーバ３ａ及び決済サーバ３ｄのＵＲＬは、予定取得モジュール１１によりサービス管理テーブル１１１に登録される。
【００６２】
また、管理Ｉ／Ｆ２２は、配送サービスの予約を配送サーバ３ａに要求する（＃４３）。これに応じ、配送サーバ３ａは、第１配送サーバ３ｂ及び第２配送サーバ３ｃのＵＲＬを、サービス管理装置１に通知する（＃４４）。配送サービスの実行に必要な部品は、第１配送サービス及び第２配送サービスだからである。これらのＵＲＬは、予定取得モジュール１１により、サービス管理テーブル１１に登録される。
【００６３】
以上により、ショッピングサービスの部品である各Ｗｅｂサービスを提供しているＷｅｂサーバのＵＲＬが、サービス管理テーブル１１１に登録される。
（２−２）サービス管理テーブルへの予約サービス情報の登録
配送サーバ３ａは、ショッピングサーバ２からの配送サービスの要求（＃４２）に応じ、第１配送サーバ３ｂ、第２配送サーバ３ｃに対し、配送サービスの予約を要求する（＃４５，＃４７）。配送サーバ３ａは、この要求に対する応答を各Ｗｅｂサーバ３ｂ、３ｃから取得し、配送予定の登録通知をサービス管理装置１に送信する（＃４６，４８）。配送予定にはユーザの要求に合う配送予定、連絡先などを含む予約サービス情報が含まれる。
【００６４】
さらに、ショッピングサーバ２の管理Ｉ／Ｆ２２は、決済サービスの予約を決済サーバ３ｄに要求する（＃５０）。これに応じ、決済サーバ３ｄは、決済の予定を示す予約サービス情報を、サービス管理装置１に送信する（＃５１）。
各Ｗｅｂサーバ３ａ〜ｄからの予約サービス情報は、更新モジュール１２により、各ＷｅｂサーバのＵＲＬと対応付けてサービス管理テーブル１１１に書き込まれる。
【００６５】
その後、ショッピング処理の完了が、ショッピングサーバ２からユーザ端末４に通知される（＃５３）。
（２−３）監視テーブルへの登録
これらの処理とは独立に、任意のＷｅｂサーバ３、例えば第３配送サーバ３ｅは、配送サービスを監視対象とし、自分自身を監視者として、サービス管理装置１に登録の依頼を要求する（＃６０）。この依頼は、監視モジュール１４により受信され、監視テーブル１１２に書き込まれる。
【００６６】
（２−４）トラブルの通知
ところで、ショッピング処理の完了後、予定していた第１配送サービスが実行不可能になったとする。この場合、第１配送サーバ３ｂから第１配送サービスの中止通知がサービス管理サーバ１に送信される（＃６１）。サービス管理サーバ１の更新モジュール１２は、実行不可能となった第１配送サービスを統合する配送サーバ３ａに、このことを通知する（＃６２）。
【００６７】
（２−５）監視者への通知
第１配送サービスの中止は、第１配送サービスの監視者にも送信できる。サービス監視装置１の監視モジュール１４は、第１配送サービスが監視対象であるか否かを判断し、監視対象であればその監視者を監視テーブル１１２から読み出す。監視者が第２配送サーバ３ｃと第３配送サーバ３ｅであるとすると、まず第２配送サーバ３ｃに対し、第１配送サービスの予定変更を通知する（＃６３）。第３配送サーバ３ｅに対しては、配送サーバ３ａからの代行サービス要求（＃６４）を受信した後で通知すると良い（＃６５）。第３配送サーバ３ｅへの通知には、代行者が代行サービスを提供するために必要な情報が含まれている。例えば配送元、配送先、希望配送日、配送物などである。
【００６８】
（２−６）代行サービスの申し出と通知
ついで、サービス管理装置の代行モジュール１５は、代行サービスの申し出を、第３配送サーバ３ｄから受信する（＃６６）。この例では、この申し出は、ユーザの要求に合う配送サービスの内容、連絡先などを含む予約サービス情報と、第３配送サーバ３ｅのＵＲＬとを含む。これらの情報は、代行モジュール１５により代行テーブル１１３に書き込まれる。またこれらの情報は、代行モジュール１５から変更通知モジュール１３に供給され、配送サーバ３ａに送信される（＃６７）。
【００６９】
（２−７）サービス管理テーブルの更新
配送サーバ３ａの管理Ｉ／Ｆ２２は、代行サービスが決定すると、第１配送サービスをサービス管理テーブル１１１から削除するための処理を行う。まず配送サーバ３ａは、第１配送サービスのキャンセルを、第１配送サーバ３ｂとサービス管理装置１とに通知する（＃７１、＃７２）。この通知に応じ、サービス管理装置１の更新モジュール１２は、第１配送サービスの予約サービス情報のエントリを、サービス管理テーブル１１１から削除する。
【００７０】
ついで、配送サーバ３ａの管理Ｉ／Ｆ２２は、代行サービスをサービス管理テーブル１１１に登録してもらうための処理を行う。まず管理Ｉ／Ｆ２２は、第３配送サービスの予約を第３配送サーバ３ｅに要求し（＃７３）、第３配送サーバ３ｅの登録をサービス管理装置１に要求する（＃７４）。この要求に応じ、更新モジュール１２は、代行テーブル１１３に記憶されている第３配送サービスの予約サービス情報や第３配送サーバ３ｅのＵＲＬを、サービス管理テーブル１１１に登録する。
【００７１】
さらに、監視モジュール１４は、ショッピングサービスで実行する配送サービスを監視している配送サーバ３ａ及び第２配送サーバ３ｃに、代行の第３配送サービスの内容を送信する（＃７５，＃７６）。受信側は、第３配送サービスが第２配送サービスに代わって実行されることを知ることができる。
以上では、トラブルを例にとっているが、同様にして各Ｗｅｂサービスの実効状態をサービス管理装置１に通知することができる。従って、ショッピングサービスを構成する各Ｗｅｂサービスの状態がサービス管理装置１により一元的に管理される。これは、Ｗｅｂサービスそのものがメタサービスであっても同様である。そのため、ショッピングサービスの実効状態や、トラブルがあったときの原因などを、ショッピングサーバ２や各Ｗｅｂサーバ３がすぐに把握できる。また、トラブルに対する迅速な処置をとりやすく、ショッピングサービスの付加価値を高めることができる。しかも、ユーザに提供するメタサービスの実行状態や代行サービス案は、そのユーザの要求にあったものを提供することができる。
（３）各テーブルの具体例
次に、前記図１６に示す処理における、各テーブル１１１〜１１３の具体例を説明する。図１７は、当初の移動プランを実行するためのサービス管理テーブル１１１の内容を示す。図１８は、トラブル発生後のサービス管理テーブル１１１を示す。図１９は監視テーブル、図２０は代行テーブルの具体例を示す。図２１は、代行サービスが記述されたサービス管理テーブル１１１を示す。
【００７２】
（３−１）当初のサービス管理テーブル
まず図１７を参照する。実施例１と同様、サービス管理テーブル１１１は、サービスエントリテーブル、予約サービス情報テーブル、及び連絡先情報テーブルの３つのテーブルから構成されている。各テーブルに蓄積される情報の内容は実施例１と同様である。
【００７３】
（３−２）トラブル発生後のサービス管理テーブル
図１８は、第１配送サービスにトラブルが発生した通知を第１配送サーバ３ｂから受け（＃６１）、ついで配送サーバ３ａから代行サービスの要求を受けた（＃６４）後の予約サービス情報テーブルを示す。前記通知には、中止された予約サービス情報のリソースＩＤ“ＤＤ００１”が含まれている。これをキーに第１配送サービスの予約サービス情報が記述されたエントリが検索され、第１配送サービスの「状態」が「実行不可」に書き換えられる。また代行サービスの要求に応じ、「代行要求」が「あり」に書き換えられる。
【００７４】
（３−３）監視テーブル
図１９は、第２配送サーバ３ｃや第３配送サーバ３ｅなど、監視者からの監視要求が登録された監視テーブル１１２の一例を示す。記憶されている情報は、実施例１の監視テーブルと同様である。例えば、第１配送サービスのリソースＩＤは「ＤＤ００１」であり、種別ＩＤは「transport.kind」である。この場合、第１配送サービスの予定が変更されると、「ＤＤ００１」または「transport.kind」をキーとしてヒットする監視対象があるかどうかが検索される。この例では、第１配送サービスに生じた予定変更は、「www.transport.com」、「www.transport2.com」、「www.transport3.com」に通知される。なお、「www.transport.com」は配送サーバ３ａ、「www. transport1.com」は第２配送サーバ３ｃ、「www. transport3.com」は第２配送サーバ３ｅの識別子である。監視者への通知には、中止された第１配送サービスの予約サービス情報が含まれている。
【００７５】
（３−４）代行テーブル
図２０は、第３配送サーバ３ｅからの代行の申し出（＃６６）により更新された代行テーブル１１３の説明図である。記憶される情報は、前記実施例１の代行テーブルと同様である。この例では、代行サービス情報は、代行する予約サービス情報のリソースＩＤ「ＤＤ００１」、第３配送サービスの予定開始時刻、予定終了時刻、処理ＩＤ、第３配送サーバ３ｅのＵＲＬを含む。
【００７６】
（３−５）代行提案後のサービス管理テーブル
図２１は、図１６に示す処理の終了後のサービス管理テーブル１１１の状態を示す。同図（Ａ）のサービスエントリテーブルには、第１配送サービスのサーバＩＤ及び処理ＩＤに代えて、第３配送サービスのサーバＩＤ「www.transport3.com」と処理ＩＤ「Ｆ００００１」とが書き込まれている。同図（Ｂ）の予約サービス情報テーブルには、第１配送サービスに代えて、第３配送サービスの開始予定時刻や終了予定時刻、状態が書き込まれている。さらに同図（Ｃ）の連絡先情報テーブルには、第３配送サービスの連絡先情報が書き加えられている。
【００７７】
以上から、サービス管理テーブル１１１には、メタサービスであるショッピングサービスを構成する各Ｗｅｂサービスの状況の変化が実質的にリアルタイムに反映されていることが分かる。
［第３実施例］
前記実施例２において、メタサービスを提供する配送サーバ３ａが、第１配送サービスを代行する第３配送サービスを自ら検索する場合も考えられる。図２２は、その場合の処理の流れを示す説明図である。
【００７８】
処理＃４１〜＃５２までは実施例２と同様である。また、第３配送サーバ３ｅは監視要求を行わない。
ショッピング処理の完了後、予定していた第１配送サービスが実行不可能になると、第１配送サーバ３ｂから第１配送サービスの中止通知がサービス管理サーバ１に送信される（＃８１）。サービス管理サーバ１の更新モジュール１２は、実行不可能となった第１配送サービスを統合する配送サーバ３ａに、このことを通知する（＃８２）。
【００７９】
第１配送サービスの中止は、第１配送サービスの監視者にも送信される。サービス監視装置１の監視モジュール１４は、第１配送サービスが監視対象であるか否かを判断し、監視対象であればその監視者を監視テーブル１１２から読み出す。監視者が第２配送サーバ３ｃであるとすると、まず第２配送サーバ３ｃに対し、第１配送サービスの予定変更を通知する（＃８３）。
第３配送サーバ３ｅへの通知には、代行者が代行サービスを提供するために必要な情報が含まれている。例えば配送元、配送先、希望配送日、配送物などである。
【００８０】
ついで、配送サーバ３ａは、自ら代行サービスとして第３配送サービスを探し出し、第１配送サービスをサービス管理テーブル１１１から削除するための処理を行う。まず配送サーバ３ａは、第１配送サービスのキャンセルを、第１配送サーバ３ｂとサービス管理装置１とに通知する（＃８４、＃８５）。この通知に応じ、サービス管理装置１の更新モジュール１２は、第１配送サービスの予約サービス情報のエントリを、サービス管理テーブル１１１から削除する。
【００８１】
ついで、配送サーバ３ａの管理Ｉ／Ｆ２２は、代行サービスをサービス管理テーブル１１１に登録してもらうための処理を行う。まず管理Ｉ／Ｆ２２は、第３配送サービスの予約を第３配送サーバ３ｅに要求し（＃８６）、第３配送サービスの予約サービス情報を取得する。この予約サービス情報は、ユーザの要求に合う配送サービスの内容、連絡先などを含む。代行サービスの予約サービス情報と、第３配送サーバ３ｅのＵＲＬは、代行サービスの申し出として配送サーバ３ａからサービス管理装置１に送信される（＃８７）。この申し出は、更新モジュール１２によりサービス管理テーブル１１１に書き込まれる。
【００８２】
その後、予約サービス情報の更新が配送サーバ３ａと、監視者である第２配送サーバ３ｃとに通知される（＃８８，＃８９）。
（３）各テーブルの具体例
サービス管理テーブル１１１は、実施例２と同様の内容を有する。また、配送サーバ３が自ら代行サービスを探し出すため、代行テーブル１１３はこの実施例では用いない。
【００８３】
図２３は、実施例３における監視テーブル１１２の具体例である。第３配送サーバ(transport3.com)が「transport.kind」の監視者になっていない点を除き、前期実施例２と同様の内容を有している。
＜その他の実施形態例＞
（Ａ）本発明の適用範囲は、前述の例に限定されない。また、インターネット上に限らず、ネットワーク上で提供されるサービスを組み合わせて提供される全ての種類のメタサービスに適用可能である。
【００８４】
（Ｂ）ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
【００８５】
【発明の効果】
本発明を用いれば、複数のサービスを連携して実現されるメタサービスの実行状態を、各サービスの提供者に負担をかけることなく、メタサービスのユーザや各サービスの提供者に通知することができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態例を適用したサービス管理装置が動作する環境を示す説明図。
【図２】サービス管理装置１及びメタサービスサーバ２の機能構成を示すブロック図。
【図３】図１のサービス管理装置、メタサービスサーバ、Ｗｅｂサーバが行う処理の流れの一例を示す説明図（メタサービスサーバが代行サービスを検索する場合）。
【図４】図１のサービス管理装置、メタサービスサーバ、Ｗｅｂサーバが行う処理の流れの一例を示す説明図（サービス管理装置が代行サービスを検索する場合）。
【図５】実施例１に係るサービス管理装置１が動作する環境を示す説明図。
【図６】出張管理サービスにおける処理の流れの一例を示す説明図。
【図７】出張管理サービスの登録画面例。
【図８】移動プラン確認画面例。
【図９】移動プランの変更画面例。
【図１０】当初の移動プランを実行するためのサービス管理テーブルの概念説明図（実施例１）。
（Ａ）サービスエントリテーブル
（Ｂ）予約サービス情報テーブル
（Ｃ）連絡先情報テーブル
【図１１】トラブル発生後のサービス管理テーブル（予約サービス情報テーブル）の概念説明図（実施例１）。
【図１２】実施例１の監視テーブルの概念説明図。
【図１３】実施例１の代行テーブルの概念説明図。
【図１４】代行サービスが記述されたサービス管理テーブルの概念説明図（実施例１）。
（Ａ）サービスエントリテーブル
（Ｂ）予約サービス情報テーブル
（Ｃ）連絡先情報テーブル
【図１５】実施例２、３に係るサービス管理装置１が動作する環境を示す説明図。
【図１６】ショッピングサービスにおける処理の流れの一例を示す説明図（実施例２）。
【図１７】当初の購入処理を実行するためのサービス管理テーブルの概念説明図（実施例２）。
（Ａ）サービスエントリテーブル
（Ｂ）予約サービス情報テーブル
（Ｃ）連絡先情報テーブル
【図１８】トラブル発生後のサービス管理テーブル（予約サービス情報テーブル）の概念説明図（実施例２）。
【図１９】実施例２の監視テーブルの概念説明図。
【図２０】実施例２の代行テーブルの概念説明図。
【図２１】代行サービスが記述されたサービス管理テーブルの概念説明図（実施例２）。
（Ａ）サービスエントリテーブル
（Ｂ）予約サービス情報テーブル
（Ｃ）連絡先情報テーブル
【図２２】ショッピングサービスにおける処理の流れの一例を示す説明図（実施例３）。
【図２３】実施例３の監視テーブルの概念説明図。
【符号の説明】
１：サービス管理装置
１１：予定取得モジュール（予定取得ステップ）
１２：更新モジュール（サービス取得ステップ、状況取得ステップ、条項更新ステップ）
１３：変更通知モジュール（変更通知ステップ、状況通知ステップ、代行通知ステップ）
１４：監視モジュール（判別ステップ、監視ステップ、登録ステップ）
１５：代行モジュール（代行登録ステップ）
１１１：サービス管理テーブル（状況記憶ステップ）
１１２：監視テーブル（監視条件記憶ステップ）
１１３：代行テーブル
２：メタサービスサーバ
２１：ユーザＩ／Ｆ
２２：管理Ｉ／Ｆ
Claims (8)
- ネットワーク上で提供されるサービスを統合して統合サービスを提供する複数のサービス統合装置と、前記サービスを提供するサービス提供装置群と、に接続するコンピュータが行うサービス管理方法であって、
前記複数のサービス統合装置のそれぞれに要求された各統合サービスを実行するために必要な各サービスを提供する各サービス提供装置の識別子を、前記複数のサービス統合装置のそれぞれから取得する予定取得ステップと、
前記各サービス提供装置が提供する各サービスを特定するサービス識別子を、前記各サービス提供装置から取得するサービス取得ステップと、
前記各サービスのうちのいずれかの提供予定の変更を、そのサービスを提供するサービス提供装置から受信する状況取得ステップと、
前記サービスの提供予定の変更を、前記予定取得ステップにおいてそのサービスを提供するサービス提供装置の識別子を送信してきたサービス統合装置に通知する変更通知ステップと、
を含む、サービス管理方法。 - 前記状況取得ステップは、前記各サービスの実行状況を、前記各サービス提供装置からさらに取得し、
前記各サービスの実行状況と前記各サービス識別子とを対応付けて記憶する状況記憶ステップと、
前記状況取得ステップで取得した各サービスの実行状況に基づいて、記憶されたサービスの実行状況を更新する状況更新ステップと、
前記各サービスの実行状況を、前記サービス統合装置に通知する状況通知ステップと、
をさらに含む、請求項１に記載のサービス管理方法。 - 任意のサービス提供装置により提供される少なくとも１つのサービスを指定する監視対象と、前記監視対象に生じた提供予定の変更を通知する監視者の識別子と、を対応付けて記憶する監視条件記憶ステップと、
前記状況取得ステップで提供予定の変更が受信されたサービスが、監視対象に含まれているかどうかを判別する判別ステップと、
提供予定が変更されたサービスが監視対象に含まれている場合、前記サービスの監視者に、前記サービスの提供予定の変更を通知する監視ステップと、
をさらに含む請求項１に記載のサービス管理方法。 - 前記監視対象及び監視者の識別子の登録を受け付ける登録ステップをさらに含む、請求項３に記載のサービス管理方法。
- 提供予定が変更となったサービスに代わる代行サービスの識別子と、その代行サービスを提供する代行サービス提供装置の識別子と、を含む代行の申し出を受信する代行登録ステップと、
前記代行サービス提供装置による代行サービスの提供予定を、前記サービス統合装置に通知する代行通知ステップと、
をさらに含む、請求項１に記載のサービス管理方法。 - ネットワーク上で提供されるサービスを統合して統合サービスを提供する複数のサービス統合装置と、前記サービスを提供するサービス提供装置群と、に接続するサービス管理装置であって、
前記複数のサービス統合装置のそれぞれに要求された各統合サービスを実行するために必要な各サービスを提供する各サービス提供装置の識別子を、前記複数のサービス統合装置のそれぞれから取得する予定取得手段と、
前記各サービス提供装置が提供する各サービスを特定するサービス識別子を、前記各サービス提供装置から取得するサービス取得手段と、
前記各サービスのうちのいずれかの提供予定の変更を、そのサービスを提供するサービス提供装置から受信する状況取得手段と、
前記サービスの提供予定の変更を、そのサービスを提供するサービス提供装置の識別子を送信してきたサービス統合装置に通知する変更通知手段と、
を備えるサービス管理装置。 - ネットワーク上で提供されるサービスを統合して統合サービスを提供する複数のサービス統合装置と、前記サービスを提供するサービス提供装置群と、に接続するコンピュータを機能させるサービス管理プログラムであって、
前記複数のサービス統合装置のそれぞれに要求された各統合サービスを実行するために必要な各サービスを提供する各サービス提供装置の識別子を、前記複数のサービス統合装置のそれぞれから取得する予定取得手段、
前記各サービス提供装置が提供する各サービスを特定するサービス識別子を、前記各サービス提供装置から取得するサービス取得手段、
前記各サービスのうちのいずれかの提供予定の変更を、そのサービスを提供するサービス提供装置から受信する状況取得手段、及び
前記サービスの提供予定の変更を、そのサービスを提供するサービス提供装置の識別子を送信してきた前記サービス統合装置に通知する変更通知手段、
として前記コンピュータを機能させるサービス管理プログラム。 - ネットワーク上で提供されるサービスを統合して統合サービスを提供する複数のサービス統合装置と、前記サービスを提供するサービス提供装置群と、に接続するコンピュータが行うサービス管理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記複数のサービス統合装置のそれぞれに要求された各統合サービスを実行するために必要な各サービスを提供する各サービス提供装置の識別子を、前記複数のサービス統合装置のそれぞれから取得する予定取得ステップと、
前記各サービス提供装置が提供する各サービスを特定するサービス識別子を、前記各サービス提供装置から取得するサービス取得ステップと、
前記各サービスのうちのいずれかの提供予定の変更を、そのサービスを提供するサービス提供装置から受信する状況取得ステップと、
前記サービスの提供予定の変更を、前記予定取得ステップにおいてそのサービスを提供するサービス提供装置の識別子を送信してきたサービス統合装置に通知する変更通知ステップと、
を実行するサービス管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003021073A JP4057925B2 (ja) | 2003-01-29 | 2003-01-29 | サービス管理方法及び装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003021073A JP4057925B2 (ja) | 2003-01-29 | 2003-01-29 | サービス管理方法及び装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004235894A JP2004235894A (ja) | 2004-08-19 |
| JP4057925B2 true JP4057925B2 (ja) | 2008-03-05 |
Family
ID=32950523
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003021073A Expired - Fee Related JP4057925B2 (ja) | 2003-01-29 | 2003-01-29 | サービス管理方法及び装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4057925B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0503141D0 (en) * | 2005-02-15 | 2005-03-23 | British Telecomm | Process configuration in a network |
| US20070078969A1 (en) * | 2005-10-04 | 2007-04-05 | Ngo Chuong N | Composite communication service management |
| US10417037B2 (en) * | 2012-05-15 | 2019-09-17 | Apple Inc. | Systems and methods for integrating third party services with a digital assistant |
-
2003
- 2003-01-29 JP JP2003021073A patent/JP4057925B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004235894A (ja) | 2004-08-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4202309B2 (ja) | プレゼンスシステム及びプレゼンス管理方法 | |
| US7401054B1 (en) | Content bank for objects | |
| US8538837B2 (en) | Methods and systems for providing wireless enabled inventory peering | |
| US20090307115A1 (en) | Facilitating procurement functions over a computer network | |
| US20110029336A1 (en) | Method to keep coherent a travel shopping basket | |
| US11681972B2 (en) | Centralized status monitoring in a multidomain network | |
| KR20140010960A (ko) | 다수의 소프트웨어 애플리케이션이 연계된 세션을 제공하는 방법 및 시스템 | |
| JP2002132987A (ja) | インターネットを利用した集中保守管理システム及び方法 | |
| KR102391435B1 (ko) | 클라우드 컴퓨팅 환경에서 고 가용 및 확장 가능한 분산형 데이터베이스를 관리하기 위한 시스템 및 방법 | |
| JP4057925B2 (ja) | サービス管理方法及び装置 | |
| KR101955707B1 (ko) | 비주기성 물품 및 구매대행 물품 배송 서비스 제공 방법 | |
| JP3950331B2 (ja) | タイムスケジュール管理システムとモバイル端末装置 | |
| US12008633B2 (en) | Computerized systems and methods for large-scale product listing | |
| JP2003128252A (ja) | 荷物配送管理システム、荷物配送管理サーバ、移動体端末、および荷物配送管理方法 | |
| JP2002203096A (ja) | 販売支援システムおよび方法 | |
| EP1671229A1 (en) | Automatic registration and deregistration of message queues | |
| KR20230100714A (ko) | 고 가용 분산형 하이브리드 트랜잭션 및 분석 데이터베이스를 관리하기 위한 시스템 및 방법 | |
| TW202223678A (zh) | 用於使區域快取同步的電腦實行系統以及方法 | |
| US20040039654A1 (en) | Device and method for carrying out a remote e-business transaction | |
| KR102003941B1 (ko) | 서비스 공통 실행 환경에서의 서비스 통합 관리 시스템 | |
| KR102676143B1 (ko) | 이벤트 저장 관리를 위한 시스템 및 방법 | |
| US20080114634A1 (en) | Method, system, and computer program product for determining availability and order scheduling of diverse products and services | |
| JP2003132433A (ja) | 商品管理サーバおよび商品管理システム | |
| JP2002312468A (ja) | ふとんクリーニングシステム | |
| KR20240096896A (ko) | 이벤트 저장 관리를 위한 시스템 및 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051205 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070808 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070814 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071015 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20071211 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071214 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4057925 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101221 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111221 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111221 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121221 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121221 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131221 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |