JP5134456B2

JP5134456B2 - サービスフロー処理装置及びサービスフロー処理方法

Info

Publication number: JP5134456B2
Application number: JP2008171233A
Authority: JP
Inventors: 晋吾岩崎
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2008-06-30
Filing date: 2008-06-30
Publication date: 2013-01-30
Anticipated expiration: 2028-06-30
Also published as: US20090327454A1; JP2010009519A; CN101621544A

Description

本発明は、サービスフロー記述文書に記述されたフロー処理を実行するサービスフロー処理技術に関する。

従来、ＷＥＢサービスを順次実行させるためのＷＥＢサービスフロー記述文書（構造化文書）に従って、ＷＥＢサービスを順次実行させる技術が知られている（例えば、非特許文献１参照）。この構造化文書としては、ＷＳＢＰＥＬ（Web Service Business Process Execution）が広く用いられている。このＷＳＢＰＥＬは、拡張可能なマークアップ言語であるＸＭＬ（eXtensible Markup Language）によって記述されたＷＥＢサービスフロー記述言語である。ＷＳＢＰＥＬの仕様は、ＯＡＳＩＳ（organization for the Advancement of Structured Information Standards）で管理されている。

尚、ＷＳＢＰＥＬでは、ＷＥＢサービスを識別するインターフェースとして、ＷＳＤＬ（Web Services Description Language）を用いている。ＷＳＤＬは、ＷＥＢサービスのインターフェースを記述するために用いる言語であり、仕様はｗｗｗコンソーシアム（Ｗ３Ｃ）によって公開されている。その内容は、http://www.w3.org/TR/wsdlにて参照可能である。

ＷＥＢサービスフロー記述文書を読み込み、その記述内容に従って、ＷＥＢサービスを順次実行させるフロー処理装置においては、ＷＥＢサービスフロー記述の内容に応じて、ＷＥＢサービスを以下の流れで呼び出す。

まず、呼び出し対象となるＷＥＢサービスのＷＥＢサービスインターフェース記述文書（ＷＳＤＬ）を読み込む。そして、対象のＷＥＢサービスが受け取れるメッセージの型を知るために、ＷＳＤＬに記述された構造定義であるスキーマ言語（ＸＭＬSchema）を参照する。ＸＭＬSchemaは、Ｗ３Ｃで定義されている。参照したスキーマを利用することで、ＸＭＬ形式であるＳＯＡＰ（Simple Object Access Protocol）メッセージの骨格を生成する。このＳＯＡＰは、Ｗ３Ｃで定義されている。

次に、生成したＳＯＡＰメッセージの骨格に対して、送信するデータを、ＸＰａｔｈ（XML Path Language）を利用して挿入し、ＳＯＡＰメッセージを完成させ、そのＳＯＡＰメッセージを送信する。ＸＰａｔｈはＷ３Ｃで定義されている。呼び出した結果、ＷＥＢサービスからの応答をＳＯＡＰメッセージで受信する。

次に、受信したＳＯＡＰメッセージからデータを抽出、或いはメッセージの加工などの処理を行う。そして、その処理結果を上述した方法でＳＯＡＰメッセージとして生成し、次のＷＥＢサービスに対して送信する。

また、外部ＷＥＢサービスが停止している場合に対応するために、外部ＷＥＢサービスの状態を管理することで、外部ＷＥＢサービスへアクセスするサービスリクエスタの負担を軽減させる提案がなされている。例えば、特許文献１参照。
特開２００４−１８５１３８号公報「ビジネス・プロセス：ＢＰＥＬ４ＷＳについて第１回」http://www.ibm.com/developerworks/jp/webservices/library/ws-bpelcol1/

しかしながら、従来のフロー処理装置では、外部ＷＥＢサービスに対してアクセスを行ったときに外部ＷＥＢサービスを公開している機器の電源が切られているか、外部ＷＥＢサービスが停止していると、フロー処理が停止してしまう。従って、このような場合には、サービスフロー記述文書に記述されている次に予定されていたフロー処理を進めることが困難である、という問題があった。

このような場合、フロー処理を停止させないように、予めサービスフロー記述文書に様々な異常状態を想定し、回避処理内容を記述することが考えられる。しかし、様々な異常状態に対応させるためには、サービスフロー記述文書自体が複雑になり、サービスフロー記述文書を作成する人間の手間が増え、人的コストが増大する。

また、様々な異常状態に対応させるためには、サービスフロー記述文書自体のサイズも膨大になるため、低資源のデバイス機器でサービスフロー記述文書を読み込むと、処理可能な資源のサイズを超える可能性がある。従って、その時点で処理不能となり、サービスフロー記述文書の処理を継続させることが困難である、という問題もあった。

また、外部ＷＥＢサービスの状態を管理するサービスブローカーを用意し、必ずサービスブローカーを経由して外部ＷＥＢサービスへアクセスする方法が提案されている。

しかし、外部ＷＥＢサービスが、サービスブローカーに対して停止予告有りと通知していない状態で、外部ＷＥＢサービスが予期せぬトラブルで停止した場合、サービスリクエスタは外部ＷＥＢサービスに対してアクセスできず処理が停止してしまう。

また、外部ＷＥＢサービスが停止していない状態でも、必ずサービスブローカーを経由するため、外部ＷＥＢサービスを呼び出し、処理を行わせ、処理結果を受け取るまでに、直接接続するよりも時間がかかることが想定される。

また、サービスブローカー自体にトラブルが発生した場合、外部ＷＥＢサービスが停止していなくても、外部ＷＥＢサービスにアクセスできなくなる。

更に、サービスブローカーで外部ＷＥＢサービス毎にプロキシを生成し、外部ＷＥＢサービスが停止していない場合でも生成したプロキシが存在し続けるため、サービスブローカーを搭載する機器の資源を圧迫することもある。

本発明は、外部サービスの状態に応じて、該外部サービスを実行するか、装置内に生成した内部サービスを実行するかを切り替えることを目的とする。

本発明は、サービスフロー記述文書に記述されたフロー処理を実行するサービスフロー処理装置であって、
外部サービスへのアクセスにおいてエラーが発生した場合、前記外部サービスのサービスインターフェース記述文書に記述された、前記外部サービスの所在を示すエンドポイントの記述を、前記サービスフロー処理装置の内部に生成された内部サービスの所在を示すエンドポイントの記述に変換する変換手段と、
前記変換手段により変換されたサービスインターフェース記述文書に基づいて前記内部サービスを実行する実行手段とを有することを特徴とする。

また、本発明は、サービスフロー記述文書に記述されたフロー処理を実行するサービスフロー処理装置にて実行されるサービスフロー処理方法であって、
変換手段が、外部サービスへのアクセスにおいてエラーが発生した場合、前記外部サービスのサービスインターフェース記述文書に記述された、前記外部サービスの所在を示すエンドポイントの記述を、前記サービスフロー処理装置の内部に生成された内部サービスの所在を示すエンドポイントの記述に変換する変換工程と、
実行手段が、前記変換工程において変換されたサービスインターフェース記述文書に基づいて前記内部サービスを実行する実行工程とを有することを特徴とする。

本発明によれば、外部サービスの状態に対してサービスフロー記述文書自体に回避処理を記述する必要が無いため、サービスフロー記述文書を作成する手間やスキルなどの人的コストを低減させることができる。

また、回避処理を記述しないで済むので、サービスフロー記述文書自体のサイズも増大しない。更に、外部サービスの異常時に生成する内部サービスは、不必要になった時点で削除する。そのため、サービスフロー記述文書を読み込み実行するデバイス機器の資源の使用量を低減でき、本装置の搭載が可能となる。

以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。

［第１の実施形態］
第１の実施形態として、外部サービス呼び出し処理自動切り替え処理の概要を、図１を用いて説明する。尚、以下の実施形態においては、外部サービスをＷＥＢサービスとして扱う。

図１は、第１の実施形態におけるＷＥＢサービスフロー処理装置の概略を示す図である。図１において、１０１はコピー、スキャン、プリントなどの複数の機能を有する複合機である。第１の実施形態では、複合機１０１はＷＥＢサービスフロー記述文書を読み込み、その記述内容に従ってＷＥＢサービスを順次実行可能なＷＥＢサービスフロー処理装置１０２として機能する。

更に、ＷＥＢサービスフロー処理装置１０２内部には、外部サービス呼び出し処理自動切り替えサービスフロー処理部１０３が含まれる。

１０４はＷＥＢサービスフロー処理装置１０２が呼び出す対象の外部ＷＥＢサービスＡであり、また１０５はＷＥＢサービスフロー処理装置１０２が呼び出す対象の外部ＷＥＢサービスＢである。

１０６は外部ＷＥＢサービスＡ１０４及び外部ＷＥＢサービスＢ１０５を順次呼び出すための手順が記述されているＷＥＢサービスフロー記述文書である。１０７は外部ＷＥＢサービスＡ用ＷＥＢサービスインターフェース記述文書であり、また１０８は外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書である。これらの記述文書の詳細な構成は、更に後述する。

ここで、ＷＥＢサービスフロー処理装置１０２及び外部サービス呼び出し処理自動切り替えサービスフロー処理部１０３の処理を説明する。

まず、ＷＥＢサービスフロー処理装置１０２は、ＷＥＢサービスフロー記述文書１０６を読み込み、その記述内容に従ってフロー処理を開始する。そして、外部ＷＥＢサービスＡ１０４の呼び出しに関連する記述内容までＷＥＢサービスフロー記述文書１０６の記述内容を順次実行していく。

次に、リクエストＳＯＡＰメッセージＡ１０９を生成し、外部ＷＥＢサービスＡ１０４に送信する。外部ＷＥＢサービスＡ１０４で処理が行われ、その結果として、レスポンスＳＯＡＰメッセージＡ１１０が返信される。そのレスポンスＳＯＡＰメッセージＡ１１０を受信し、そのメッセージから必要なデータを抽出し、リクエストＳＯＡＰメッセージＢ１１１を生成する。そして、外部ＷＥＢサービスＢ１０５にアクセスする。

このとき、サービスを搭載したサーバ機器などの電源が切られているため、外部ＷＥＢサービスＢ１０５が停止していたとする。このような場合、外部ＷＥＢサービスＢ１０５からの応答１１２がないため、ＷＥＢサービスフロー処理装置１０２では、エラーと判断する。外部サービスに対してアクセスした結果、エラーが起こった場合は、外部サービス呼び出し処理自動切り替えサービスフロー処理部１０３に対してエラー通知を行う。

ここで、エラー通知を受信した外部サービス呼び出し処理自動切り替えサービスフロー処理部１０３は、エラーが起きた外部ＷＥＢサービスＢ１０５用の外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８を取得する。外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８に記述されたエンドポイントは、ネットワーク上のサービスの所在を示す。そして、外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８に記述されたエンドポイントを、複合機１０１上の仮想的なサービスである内部サービスの所在を示すエンドポイントに変換する。

この変換前の外部ＷＥＢサービスＢ１０５のエンドポイントは記憶しておく。そして、エンドポイントを変換した外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８から、内部ＷＥＢサービスＢ１１５を自動生成する。内部ＷＥＢサービスＢ１１５が自動生成された後、ＷＥＢサービスフロー処理装置１０２は、エラーが起きたときに実行していたフロー処理を再び実行する。ここで、外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８を再度読み込み直し、エンドポイントが変更されているため、アクセス先が自動的に変更される。

このように、ＷＥＢサービスフロー処理装置１０２は、内部ＷＥＢサービスＢ１１５にアクセスし、リクエストＳＯＡＰメッセージＢ１１６（リクエストＳＯＡＰメッセージＢ１１１と同一）を送信する。そして、内部ＷＥＢサービスＢ１１５は、呼び出した相手が解釈できるレスポンスＳＯＡＰメッセージ仮想Ｂ１１７を自動生成して返信する。即ち、内部ＷＥＢサービスＢ１１５は、外部ＷＥＢサービスＢ１０５の代わりに、仮のレスポンスＳＯＡＰメッセージを返信する。

これにより、ＷＥＢサービスフロー処理装置１０２が外部ＷＥＢサービスに対してアクセスした時にエラーが起きても、フロー処理を停止することなく、ＷＥＢサービスフロー記述文書１０６に記述された次のフロー処理を実行することが可能となる。その後、外部サービス呼び出し処理自動切り替えサービスフロー処理部１０３は、外部ＷＥＢサービスＢ１０５を監視１１８する。

例えば、外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８からスタブを自動生成し、外部サービス呼び出し処理自動切り替えサービスフロー処理部１０３で記憶されていたエンドポイントにアクセスを繰り返し、反応を確かめる。この動作を外部ＷＥＢサービスＢ１０５が再び動き出すまで一定間隔或いは不規則に繰り返すことで監視する。

外部ＷＥＢサービスＢ１０５からアクセスに対して反応があり、再び動き出したことを確認すると、外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８のエンドポイントを元に戻す。これにより、ＷＥＢサービスフロー処理装置１０２は、再び外部ＷＥＢサービスＢ１０５とのやりとりが可能となる。

次に、外部サービス呼び出し処理自動切り替えサービスフロー処理部１０３の具体的な処理内容を、図２を用いて説明する。

図２は、外部サービス呼び出し処理自動切り替えサービスフロー処理部の内部処理構成を示す図である。外部サービス呼び出し処理自動切り替えサービスフロー処理部１０３は、エラー通知受信処理部２０１、サービス自動公開処理部２０２、外部サービス監視処理部２０３から構成される。

ＷＥＢサービスフロー処理装置１０２が外部ＷＥＢサービスＢ１０５にアクセス２１１したときに、外部ＷＥＢサービスＢ１０５が機器のトラブルやその他の原因で停止していると、アクセス２１１に対する応答２１２が無い。この場合、ＷＥＢサービスフロー処理装置１０２は、外部ＷＥＢサービスＢ１０５にエラーが発生したと解釈する。そして、エラーが発生したことを、アクセスした外部ＷＥＢサービスＢ１０５に関する情報と共に、エラー通知受信処理部２０１に通知する。

エラー通知受信処理部２０１は、エラーの対象となった外部ＷＥＢサービスＢ１０５に関する情報をサービス自動公開処理部２０２に通知する。サービス自動公開処理部２０２は、まず外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８に記述された外部ＷＥＢサービスＢ１０５のネットワーク上の所在を示すエンドポイントが記述された場所を特定する。次に、そのエンドポイントをＷＥＢサービスフロー処理装置１０２及び外部サービス呼び出し処理自動切り替えサービスフロー処理部１０３が搭載された機器に公開する内部ＷＥＢサービスのネットワーク上の所在を示すエンドポイントに変換する。この変換前のエンドポイント情報も保存しておく。

ここで、エンドポイントが変換された外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８から内部ＷＥＢサービスＢ１１５を自動生成し、サービスとして公開する。そして、外部サービス監視処理部２０３に外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８と、保存された外部ＷＥＢサービスＢ１０５を示すエンドポイントの情報を渡す。

これにより、外部サービス監視処理部２０３は、外部ＷＥＢサービスＢ１０５の状態の監視を開始する。内部ＷＥＢサービスＢ１１５が自動生成された後、ＷＥＢサービスフロー処理装置１０２は、エラーが起きたときに実行していたフロー処理を再び実行する。その際に外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８を再度読み込み直すので、エンドポイントが変更されたアクセス先へ自動的にアクセスすることができる。よって、内部ＷＥＢサービスＢ１１５に対してアクセスし、その応答を受け取ることができる。

このように、ＷＥＢサービスフロー処理装置１０２は、外部ＷＥＢサービスＢ１０５にアクセスしたときにエラーが起きても、フロー処理を停止することなく、ＷＥＢサービスフロー記述文書１０６に記述された次のフロー処理を実行することが可能となる。

その間、外部サービス監視処理部２０３は、外部ＷＥＢサービスＢ１０５の監視を継続している。監視方法としては、例えば外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８からスタブを自動生成し、サービス自動公開処理部２０２で記憶したエンドポイントに対してアクセスを繰り返し、反応を確かめる。この動作を外部ＷＥＢサービスＢ１０５が再び動き出すまで一定間隔で繰り返すことで監視する。

その後、外部ＷＥＢサービスＢ１０５からアクセスに対して反応があり、再び動き出したことを確認すると、サービス自動公開処理部２０２に再び動き出したことを通知する。サービス自動公開処理部２０２は、外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８のエンドポイントを、保存しておいた外部ＷＥＢサービスＢ１０５のネットワーク上の所在を示すエンドポイントに戻す。

更に、内部ＷＥＢサービスＢ１１５の公開を停止し、内部ＷＥＢサービスＢ１１５自体の情報を全て削除する。その後、ＷＥＢサービスフロー処理装置１０２は外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８を読み込むので、再び動き出した外部ＷＥＢサービスＢ１０５にアクセスすることができる。その結果、再び正常な応答を受け取ることができる。

ここで、外部サービス呼び出し処理自動切り替えサービスフロー処理部１０３の詳細な処理を、具体的なデータを用いて説明する。

図３は、ＷＥＢサービスフロー記述文書とその具体例を示す図である。図３に示すように、ＷＥＢサービスフロー記述文書１０６は、プログラムで言う変数宣言などを記述する宣言部３０１と、フロー処理のロジックなどを記述するロジック部３０２から構成されている。

宣言部３０１は、ＷＥＢサービスフロー記述文書１０６を特定する情報及び呼び出し先各ＷＥＢサービスのインターフェース記述文書を特定する情報３１１と、ＷＥＢサービスフロー処理で用いる変数情報３１２とが記述されている。

ロジック部３０２は、本来であればクライアントからリクエストメッセージを受信する記述やクライアントにレスポンスメッセージを返信する記述など全てのフロー処理の内容が記述される。しかし、この例では、本発明を説明するために必要な情報のみを記述することとする。

３２１は外部ＷＥＢサービスＡを呼び出し、外部ＷＥＢサービスＡに処理を行わせ、その処理結果のレスポンスメッセージを受信する処理内容が記述される。３２２は受信した処理結果のレスポンスメッセージから、処理結果を抽出し、外部ＷＥＢサービスＢが解釈できるリクエストメッセージを生成する処理内容が記述される。３２３は外部ＷＥＢサービスＢを呼び出し、外部ＷＥＢサービスＢに処理を行わせ、その処理結果のレスポンスメッセージを受信する処理内容が記述される。３２４は受信した処理結果を含むレスポンスメッセージから処理結果を抽出し、次の外部ＷＥＢサービスが解釈できるリクエストメッセージを生成する処理内容が記述される。

３０３はＷＥＢサービスフロー記述文書１０６の具体例である。この例では、ＷＳＢＰＥＬというＷＥＢサービスの処理フローをＸＭＬ文書で記述するための標準仕様になっている言語で記述されている。ＷＳＢＰＥＬは、Web Service Business Process Execution Languageの略である。また、ＸＭＬは、eXtensible Markup Languageの略である。以下、ＷＥＢサービスフロー記述文書１０６の構成と、ＷＥＢサービスフロー記述文書３０３とを比較する。

３３１は３１１の記述内容に対応し、ＷＥＢサービスフロー記述文書を特定する情報と呼び出し先の各ＷＥＢサービスのインターフェース記述文書（ＷＳＤＬ文書）を特定する情報が記述される。ここでは、＜process＞タグの属性値としてネームスペースで記述されている。

３３２は３１２の記述内容に対応し、フロー処理を行うときに使用するメッセージ変数の型情報がそれぞれ＜variable＞タグで記述されている。

３３３は３２１の記述内容に対応し、外部ＷＥＢサービスＡを呼び出し、処理を行わせた結果のレスポンスメッセージを受信する処理内容が＜invoke＞タグで記述されている。

３３４は３２２の記述内容に対応し、受信したレスポンスメッセージからＸＰａｔｈを利用して抽出した処理結果とＸＰａｔｈから外部ＷＥＢサービスＢが解釈できるリクエストメッセージを生成する処理内容が記述される。ここでは、＜assign＞タグなどで記述されている。

３３５は３２３の記述内容に対応し、外部ＷＥＢサービスＢを呼び出し、処理を行わせた結果のレスポンスメッセージを受信する処理内容が記述される。ここでは、＜invoke＞タグで記述されている。

３３６は３２４の記述内容に対応し、受信したレスポンスメッセージからＸＰａｔｈを利用して抽出した処理結果とＸＰａｔｈから次に呼び出す外部ＷＥＢサービスが解釈できるリクエストメッセージを生成する処理内容が記述される。ここでは、＜assign＞タグなどで記述される。

ロジック部３０２の記述内容に対応する＜assign＞、＜invoke＞タグは、ＷＳＢＰＥＬではアクティビティと呼ぶ。＜assign＞タグはメッセージの加工、変換、＜invoke＞タグは外部のＷＥＢサービスの呼び出しといったように、ＷＥＢサービスフロー処理の表現を抽象化したものである。本実施形態においては、３３５のinvokeアクティビティの実行時に発生したエラーの場合について説明する。

３３５のinvokeアクティビティを実行し、外部サービスにアクセスした結果、応答がなければ、次の３３６で示すアクティビティの処理に移ることができず、その時点でフロー処理が停止してしまう。本実施形態においては、このフロー処理が処理の途中で停止してしまうことを防ぐことを目的としている。

次に、サービス自動公開処理部２０２の処理内容を、外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８の具体例としてＷＳＤＬで記述された例を用いて説明する。

図４は、外部ＷＥＢサービスＢ用インターフェース記述文書１０８の具体例４０１を示す図である。４０２には外部ＷＥＢサービスＢ１０５のネットワーク上の所在を指し示すエンドポイントの情報４０３がＷＳＤＬの＜address＞タグとして記述されている。このエンドポイントの情報を、サービス自動公開処理部２０２では、自動生成する内部ＷＥＢサービスＢ１１５のネットワーク上の所在を指し示すエンドポイントの情報４０４に変換する。内部ＷＥＢサービスＢ１１５は、複合機１０１内部に公開するため、４０４に示すエンドポイントは、複合機１０１のネットワーク上の所在を指し示すものになる。

次に、内部ＷＥＢサービスＢ１１５が、ＷＥＢサービスフロー処理装置１０２からのアクセスに対してどのような応答４０５をするかを説明する。ＷＳＤＬ４０１には、ＷＥＢサービスがリクエスト時に解釈できるメッセージの型と、その応答時に返すメッセージの型に関する情報が、XMLSchema４０６として記述されている。サービス自動公開処理部２０２では、実際のＷＥＢサービスとのやりとりと同様に、ＳＯＡＰメッセージをやりとりできるように内部ＷＥＢサービスＢ１１５を自動生成する。

そのため、内部ＷＥＢサービスＢ１１５からの応答４０５はＳＯＡＰメッセージとなる。４０７に応答時にどのようなメッセージの型にするかが記述されており、その情報から４０８のＳＯＡＰメッセージを自動生成する。内部ＷＥＢサービスＢ１１５は実際に処理を行うわけではないため、例えば４０９に示すように、＜resultdata＞タグだけで中身のデータが空の状態にしてＳＯＡＰメッセージを生成する。また、４０７の＜xsd:element name="resultdata" type="xsd:string" /＞から、＜resultdata＞タグはString型の情報を持つことができると解釈できる。そこで、適当な文字列を挿入して返すことも可能である。以上のように、内部ＷＥＢサービスＢ１１５は、外部ＷＥＢサービスＢ１０５の代わりに、仮の応答ＳＯＡＰメッセージ４０８を返信する。

その結果、ＷＥＢサービスフロー処理装置１０２は、応答としてＳＯＡＰメッセージ４０８を受信することができるため、その時点で処理が停止せず、受信した後のフロー処理を実行することが可能となる。

次に、外部サービス監視処理部２０３における処理の一例を、図５を用いて説明する。

図５は、第１の実施形態における外部サービス監視処理部の処理を示すフローチャートである。まず、Ｓ５０１で、サービス自動公開処理部２０２から外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８と、外部ＷＥＢサービスＢ１０５を指し示すエンドポイントの情報を取得する。そして、それらの情報に基づいて外部ＷＥＢサービスＢ１０５にアクセスするためのスタブを生成する。

次に、Ｓ５０２で、Ｓ５０１で生成したスタブを利用して外部ＷＥＢサービスＢ１０５にアクセスする。そして、Ｓ５０３で、外部ＷＥＢサービスＢ１０５から応答があったか否かを判定する。ここで応答がなければ、Ｓ５０２に戻り、上述の処理を繰り返す。

一方、Ｓ５０２でアクセスした結果、外部ＷＥＢサービスＢ１０５が再び起動し、応答があれば、Ｓ５０３で応答ありと判定し、Ｓ５０４へ処理を進める。このＳ５０４では、サービス自動公開処理部２０２に外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書１０８のエンドポイント記述を元に戻すように通知する。

第１の実施形態によれば、障害の発生により停止している外部ＷＥＢサービスに対してＷＥＢサービスフロー処理装置がアクセスしても、その時点で処理を停止することなく、継続することが可能となる。

また、サービスフロー記述文書にエラー時の複雑な回避処理を記述する必要がないため、サービスフロー記述文書を作成する人の手間が減り、人的コストを低減できる。

［第２の実施形態］
次に、図面を参照しながら本発明に係る第２の実施形態を詳細に説明する。第２の実施形態でも、第１の実施形態と同様に、外部サービスをＷＥＢサービスとして扱う。

第１の実施形態では、外部サービス監視処理部２０３が外部ＷＥＢサービスＢ１０５へのアクセスに対して応答があるか否かを監視していた。第２の実施形態では、監視を終了できる判断基準を外部から与えることで、その判断基準に基づき、監視を終了させる場合の処理を説明する。

尚、第２の実施形態における複合機１０１、ＷＥＢサービスフロー処理装置１０２及び外部サービス呼び出し処理自動切り替えサービスフロー処理部１０３の構成は第１の実施形態で説明した図１及び図２に示す構成と同じであり、その説明は省略する。

図６は、第２の実施形態における外部サービス監視処理部の処理を示すフローチャートである。第１の実施形態と同様に、Ｓ５０２で、アクセスした結果、外部ＷＥＢサービスＢ１０５から図６に示すようなＳＯＡＰメッセージ６１１が返ってきたとする。ＳＯＡＰメッセージ６１１は、＜env:Body＞タグの中に＜env:Fault＞タグ６１２がある。

つまり、ＳＯＡＰメッセージ６１１はＳＯＡＰＦａｕｌｔである。ＳＯＡＰＦａｕｌｔはＷＥＢサービスにアクセスした結果、ＷＥＢサービス側はリクエストを受け付けたが、ＷＥＢサービス内部で処理している最中にエラーが発生した場合など、アクセスしてきた相手に返すＳＯＡＰメッセージである。

ＳＯＡＰＦａｕｌｔでは、＜env:Code＞タグ６１３で、エラーが発生した原因として、リクエストしてきた相手の問題か、ＷＥＢサービス側の問題かを示す。この例では＜env:Value＞タグの値がReceiverなので、ＷＥＢサービス側に問題があるということがわかる。また、＜env:Value＞タグの値がSenderであれば、リクエストしてきた相手側に問題があるということになる。

リクエストしてきた相手側に問題がある場合としては、例えばリクエストしてきた相手が生成したリクエスト用のＳＯＡＰメッセージが仕様に適合していないなどがある。このように、ＳＯＡＰメッセージ６１１を受信した場合、Ｓ５０３で応答があるか否かを判定する処理では、応答ありと判定する。

図６に示す６１４はエラー条件設定情報の一例であり、例えばＸＭＬ形式で記述され、６１５の＜message＞タグの値としてSOAPFaultの値が記述され、６１６の＜code＞タグの値としてReceiverの値が記述されている。

Ｓ６０１で、エラー条件設定情報６１４を読み込み、ＳＯＡＰメッセージがＳＯＡＰＦａｕｌｔで、且つ、原因がＷＥＢサービス側であった場合、エラー判定と解釈する。そのため、Ｓ６０２で、エラー判定処理を行い、ＳＯＡＰメッセージ６１１とエラー条件設定情報６１４からＳＯＡＰメッセージ６１１では、まだエラーであると判定する。よって、Ｓ５０２に戻り、上述の処理を繰り返す。
第２の実施形態によれば、第１の実施形態の外部サービス監視処理において、外部からエラー条件設定情報を与えることで、外部サービスから応答があった場合にも監視を継続させるかを制御することが可能となる。

［第３の実施形態］
次に、図面を参照しながら本発明に係る第３の実施形態を詳細に説明する。第１及び第２の実施形態では、外部サービス呼び出し処理自動切り替えサービスフロー処理部の適用場面として、複合機というデバイス機器へ搭載する例を挙げた。しかし、本発明はこれに限らず、情報処理装置（コンピュータ）に適用することも可能である。

図７は、第３の実施形態におけるフロー処理装置として機能する情報処理装置の構成の一例を示す図である。上述した実施形態の機能を実現するソフトウェアを実行する情報処理装置のハードウェア構成の一例を示している。

情報処理装置は、ハードウェア構成として入力装置７０１と、表示装置７０２と、記憶媒体ドライブ装置７０３と、ＲＯＭ７０５と、ＲＡＭ７０６と、ＣＰＵ又はＭＰＵ７０７と、インターフェース装置７０８と、ＨＤ（ハードディスク）７０９とを含む。入力装置７０１は、情報処理装置の操作者（オペレータ）が操作するキーボード及びマウスなどで構成され、情報処理装置に各種操作情報などを入力するのに用いられる。表示装置７０２は、情報処理装置の操作者が利用するディスプレイなどで構成され、各種情報（又は画面）などを表示するのに用いられる。

インターフェース装置７０８は、情報処理装置をネットワークなどに接続するインターフェースである。上述した処理などに係るプログラムは、例えばＣＤ−ＲＯＭなどの記憶媒体７０４によって情報処理装置に提供されるか、ネットワークなどを通じてダウンロードされる。記憶媒体７０４は、記憶媒体ドライブ装置７０３にセットされ、プログラムが記憶媒体７０４から記憶媒体ドライブ装置７０３を介してＨＤ７０９にインストールされる。

ＲＯＭ７０５は情報処理装置の電源投入時に最初に読み込まれるプログラムなどを格納する。ＲＡＭ７０６は、情報処理装置のメインメモリである。ＣＰＵ７０７は、ＨＤ７０９よりプログラムを読み出して、ＲＡＭ７０６に格納し、プログラムを実行することで、前述の処理内容を実現したりする。ＨＤ７０９は、プログラム以外に、例えばＷＥＢサービスフロー記述文書、ＷＥＢサービスインターフェース記述文書などを格納する。

このプログラムコードを供給するための記録媒体として、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、次の場合も含まれることは言うまでもない。即ち、プログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合である。

更に、記録媒体から読出されたプログラムコードがコンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込む。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

第１の実施形態におけるＷＥＢサービスフロー処理装置の概略を示す図である。外部サービス呼び出し処理自動切り替えサービスフロー処理部の内部処理構成を示す図である。ＷＥＢサービスフロー記述文書とその具体例を示す図である。外部ＷＥＢサービスＢ用インターフェース記述文書の具体例を示す図である。第１の実施形態における外部サービス監視処理部の処理を示すフローチャートである。第２の実施形態における外部サービス監視処理部の処理を示すフローチャートである。第３の実施形態におけるフロー処理装置として機能する情報処理装置の構成の一例を示す図である。

符号の説明

１０１複合機
１０２ＷＥＢサービスフロー処理装置
１０３外部サービス呼び出し処理自動切り替えサービスフロー処理部
１０４外部ＷＥＢサービスＡ
１０５外部ＷＥＢサービスＢ
１０６ＷＥＢサービスフロー記述文書
１０７外部ＷＥＢサービスＡ用ＷＥＢサービスインターフェース記述文書
１０８外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書
１０９リクエストＳＯＡＰメッセージＡ
１１０レスポンスＳＯＡＰメッセージＡ
１１１リクエストＳＯＡＰメッセージＢ
１１５内部ＷＥＢサービスＢ
２０１エラー通知受信処理部
２０２サービス自動公開処理部
２０３外部サービス監視処理部

Claims

サービスフロー記述文書に記述されたフロー処理を実行するサービスフロー処理装置であって、
外部サービスへのアクセスにおいてエラーが発生した場合、前記外部サービスのサービスインターフェース記述文書に記述された、前記外部サービスの所在を示すエンドポイントの記述を、前記サービスフロー処理装置の内部に生成された内部サービスの所在を示すエンドポイントの記述に変換する変換手段と、
前記変換手段により変換されたサービスインターフェース記述文書に基づいて前記内部サービスを実行する実行手段とを有することを特徴とするサービスフロー処理装置。
前記外部サービスへ一定間隔でアクセスし、該外部サービスから応答が得られるか否かを判定する判定手段を更に有し、
前記判定の結果、前記応答が得られた場合、前記変換手段は、前記変換されたサービスインターフェース記述文書に記述された、前記内部サービスの所在を示すエンドポイントの記述を、前記外部サービスの所在を示すエンドポイントの記述に切り替え、
前記実行手段は、前記切り替えられたサービスインターフェース記述文書に基づいて前記外部サービスを実行することを特徴とする請求項１に記載のサービスフロー処理装置。
前記判定の結果、前記応答が得られた場合、前記応答の内容に応じて前記エンドポイントの切り替えを行うか否かを設定する設定手段を更に有することを特徴とする請求項２に記載のサービスフロー処理装置。
サービスフロー記述文書に記述されたフロー処理を実行するサービスフロー処理装置にて実行されるサービスフロー処理方法であって、
変換手段が、外部サービスへのアクセスにおいてエラーが発生した場合、前記外部サービスのサービスインターフェース記述文書に記述された、前記外部サービスの所在を示すエンドポイントの記述を、前記サービスフロー処理装置の内部に生成された内部サービスの所在を示すエンドポイントの記述に変換する変換工程と、
実行手段が、前記変換工程において変換されたサービスインターフェース記述文書に基づいて前記内部サービスを実行する実行工程とを有することを特徴とするサービスフロー処理方法。
判定手段が、前記外部サービスへ一定間隔でアクセスし、該外部サービスから応答が得られるか否かを判定する判定工程を更に有し、
前記判定の結果、前記応答が得られた場合、前記変換工程は、前記変換されたサービスインターフェース記述文書に記述された、前記内部サービスの所在を示すエンドポイントの記述を、前記外部サービスの所在を示すエンドポイントの記述に切り替え、
前記実行工程は、前記切り替えられたサービスインターフェース記述文書に基づいて前記外部サービスを実行することを特徴とする請求項４に記載のサービスフロー処理方法。
コンピュータを請求項１乃至３の何れか１項に記載のサービスフロー処理装置の各手段として機能させるためのプログラム。