図面 (/)

技術 サービスフロー処理装置及びサービスフロー処理方法

出願人 キヤノン株式会社
発明者 岩崎晋吾
出願日 2008年6月30日 (13年4ヶ月経過) 出願番号 2008-171233
公開日 2010年1月14日 (11年10ヶ月経過) 公開番号 2010-009519
状態 特許登録済
技術分野 デバッグ/監視 ハードウェアの冗長性 計算機・データ通信 エラー時の再試行 エラーの検出
主要キーワード 停止予告 フロー処理装置 サービスブローカー 記憶媒体ドライブ装置 エンドポイント情報 フロー記述 WSDL文書 エラー判定処理
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2010年1月14日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (8)

課題

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

解決手段

サービスフロー記述文書記述されたフロー処理を実行するサービスフロー処理装置において、外部サービスに関する情報を受信する。外部サービスにアクセスし、該外部サービスから応答が得られない場合、外部サービスに関する情報から外部サービス用のサービスインターフェース記述文書を取得し、サービスインターフェース記述文書に記述された外部サービスのエンドポイントを記憶する。そのエンドポイントをサービスフロー処理装置の内部に生成された内部サービスのエンドポイントに変換し、変換されたサービスインターフェース記述文書に基づいて、内部サービスを実行する。

概要

背景

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

尚、WSBPELでは、WEBサービスを識別するインターフェースとして、WSDL(Web Services Description Language)を用いている。WSDLは、WEBサービスのインターフェースを記述するために用いる言語であり、仕様はwwwコンソーシアム(W3C)によって公開されている。その内容は、http://www.w3.org/TR/wsdlにて参照可能である。

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

まず、呼び出し対象となるWEBサービスのWEBサービスインターフェース記述文書(WSDL)を読み込む。そして、対象のWEBサービスが受け取れるメッセージの型を知るために、WSDLに記述された構造定義であるスキーマ言語(XMLSchema)を参照する。XMLSchemaは、W3Cで定義されている。参照したスキーマを利用することで、XML形式であるSOAP(Simple Object Access Protocol)メッセージの骨格を生成する。このSOAPは、W3Cで定義されている。

次に、生成したSOAPメッセージの骨格に対して、送信するデータを、XPath(XML Path Language)を利用して挿入し、SOAPメッセージを完成させ、そのSOAPメッセージを送信する。XPathはW3Cで定義されている。呼び出した結果、WEBサービスからの応答をSOAPメッセージで受信する。

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

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

概要

外部サービスの状態に応じて、該外部サービスを実行するか、装置内に生成した内部サービスを実行するを切り替える。サービスフロー記述文書に記述されたフロー処理を実行するサービスフロー処理装置において、外部サービスに関する情報を受信する。外部サービスにアクセスし、該外部サービスから応答が得られない場合、外部サービスに関する情報から外部サービス用のサービスインターフェース記述文書を取得し、サービスインターフェース記述文書に記述された外部サービスのエンドポイントを記憶する。そのエンドポイントをサービスフロー処理装置の内部に生成された内部サービスのエンドポイントに変換し、変換されたサービスインターフェース記述文書に基づいて、内部サービスを実行する。

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

サービスフロー記述文書記述されたフロー処理を実行するサービスフロー処理装置であって、外部サービスに関する情報を受信する受信手段と、前記外部サービスにアクセスし、該外部サービスから応答が得られない場合、前記外部サービスに関する情報から、外部サービスのサービスインターフェース記述文書を取得し、前記サービスインターフェース記述文書に記述された外部サービスのエンドポイントを記憶する記憶手段と、前記サービスインターフェース記述文書に記述された外部サービスのエンドポイントを前記サービスフロー処理装置の内部に生成された内部サービスのエンドポイントに変換し、変換されたサービスインターフェース記述文書に基づいて前記内部サービスを実行する実行手段とを有することを特徴とするサービスフロー処理装置。

請求項2

前記実行手段で前記内部サービスを実行しているときに、前記外部サービスへ一定間隔でアクセスし、該外部サービスから応答が得られるか否かを判定する判定手段と、前記判定の結果、前記応答が得られた場合、前記変換されたサービスインターフェース記述文書におけるエンドポイントを前記記憶手段に記憶されたエンドポイントに切り替え、切り替えられたサービスインターフェース記述文書に基づいて前記外部サービスを実行する手段とを更に有することを特徴とする請求項1に記載のサービスフロー処理装置。

請求項3

前記判定の結果、前記応答が得られた場合、前記応答の内容に応じて切り替えを行うか否かを設定する設定手段を更に有することを特徴とする請求項2に記載のサービスフロー処理装置。

請求項4

サービスフロー記述文書に記述されたフロー処理を実行するサービスフロー処理装置にて実行されるサービスフロー処理方法であって、外部サービスに関する情報を受信する受信工程と、前記外部サービスにアクセスし、該外部サービスから応答が得られない場合、前記外部サービスに関する情報から、外部サービスのサービスインターフェース記述文書を取得し、前記サービスインターフェース記述文書に記述された外部サービスのエンドポイントを記憶手段に記憶する記憶工程と、前記サービスインターフェース記述文書に記述された外部サービスのエンドポイントを前記サービスフロー処理装置の内部に生成された内部サービスのエンドポイントに変換し、変換されたサービスインターフェース記述文書に基づいて前記内部サービスを実行する実行工程とを有することを特徴とするサービスフロー処理方法。

請求項5

コンピュータを請求項1乃至3の何れか1項に記載のサービスフロー処理装置として機能させるためのプログラム

請求項6

請求項5に記載のプログラムを記録した、コンピュータによって読み取りが可能な記録媒体

技術分野

0001

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

背景技術

0002

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

0003

尚、WSBPELでは、WEBサービスを識別するインターフェースとして、WSDL(Web Services Description Language)を用いている。WSDLは、WEBサービスのインターフェースを記述するために用いる言語であり、仕様はwwwコンソーシアム(W3C)によって公開されている。その内容は、http://www.w3.org/TR/wsdlにて参照可能である。

0004

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

0005

まず、呼び出し対象となるWEBサービスのWEBサービスインターフェース記述文書(WSDL)を読み込む。そして、対象のWEBサービスが受け取れるメッセージの型を知るために、WSDLに記述された構造定義であるスキーマ言語(XMLSchema)を参照する。XMLSchemaは、W3Cで定義されている。参照したスキーマを利用することで、XML形式であるSOAP(Simple Object Access Protocol)メッセージの骨格を生成する。このSOAPは、W3Cで定義されている。

0006

次に、生成したSOAPメッセージの骨格に対して、送信するデータを、XPath(XML Path Language)を利用して挿入し、SOAPメッセージを完成させ、そのSOAPメッセージを送信する。XPathはW3Cで定義されている。呼び出した結果、WEBサービスからの応答をSOAPメッセージで受信する。

0007

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

0008

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

発明が解決しようとする課題

0009

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

0010

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

0011

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

0012

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

0013

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

0014

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

0015

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

0016

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

0017

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

課題を解決するための手段

0018

本発明は、サービスフロー記述文書に記述されたフロー処理を実行するサービスフロー処理装置であって、
外部サービスに関する情報を受信する受信手段と、
前記外部サービスにアクセスし、該外部サービスから応答が得られない場合、前記外部サービスに関する情報から、外部サービスのサービスインターフェース記述文書を取得し、前記サービスインターフェース記述文書に記述された外部サービスのエンドポイントを記憶する記憶手段と、
前記サービスインターフェース記述文書に記述された外部サービスのエンドポイントを前記サービスフロー処理装置の内部に生成された内部サービスのエンドポイントに変換し、変換されたサービスインターフェース記述文書に基づいて前記内部サービスを実行する実行手段とを有することを特徴とする。

0019

また、本発明は、サービスフロー記述文書に記述されたフロー処理を実行するサービスフロー処理装置にて実行されるサービスフロー処理方法であって、
外部サービスに関する情報を受信する受信工程と、
前記外部サービスにアクセスし、該外部サービスから応答が得られない場合、前記外部サービスに関する情報から、外部サービスのサービスインターフェース記述文書を取得し、前記サービスインターフェース記述文書に記述された外部サービスのエンドポイントを記憶手段に記憶する記憶工程と、
前記サービスインターフェース記述文書に記述された外部サービスのエンドポイントを前記サービスフロー処理装置の内部に生成された内部サービスのエンドポイントに変換し、変換されたサービスインターフェース記述文書に基づいて前記内部サービスを実行する実行工程とを有することを特徴とする。

発明の効果

0020

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

0021

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

発明を実施するための最良の形態

0022

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

0023

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

0024

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

0025

更に、WEBサービスフロー処理装置102内部には、外部サービス呼び出し処理自動切り替えサービスフロー処理部103が含まれる。

0026

104はWEBサービスフロー処理装置102が呼び出す対象の外部WEBサービスAであり、また105はWEBサービスフロー処理装置102が呼び出す対象の外部WEBサービスBである。

0027

106は外部WEBサービスA104及び外部WEBサービスB105を順次呼び出すための手順が記述されているWEBサービスフロー記述文書である。107は外部WEBサービスA用WEBサービスインターフェース記述文書であり、また108は外部WEBサービスB用WEBサービスインターフェース記述文書である。これらの記述文書の詳細な構成は、更に後述する。

0028

ここで、WEBサービスフロー処理装置102及び外部サービス呼び出し処理自動切り替えサービスフロー処理部103の処理を説明する。

0029

まず、WEBサービスフロー処理装置102は、不図示のスキャナにてWEBサービスフロー記述文書106を読み込み、その記述内容に従ってフロー処理を開始する。そして、外部WEBサービスA104の呼び出しに関連する記述内容までWEBサービスフロー記述文書106の記述内容を順次実行していく。

0030

次に、リクエストSOAPメッセージA109を生成し、外部WEBサービスA104に送信する。外部WEBサービスA104で処理が行われ、その結果として、レスポンスSOAPメッセージA110が返信される。そのレスポンスSOAPメッセージA110を受信し、そのメッセージから必要なデータを抽出し、リクエストSOAPメッセージB111を生成する。そして、外部WEBサービスB105にアクセスする。

0031

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

0032

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

0033

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

0034

このように、WEBサービスフロー処理装置102は、内部WEBサービスB115にアクセスし、リクエストSOAPメッセージB116(リクエストSOAPメッセージB111と同一)を送信する。そして、内部WEBサービスB115は、呼び出した相手解釈できるレスポンスSOAPメッセージ仮想B117を自動生成して返信する。即ち、内部WEBサービスB115は、外部WEBサービスB105の代わりに、仮のレスポンスSOAPメッセージを返信する。

0035

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

0036

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

0037

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

0038

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

0039

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

0040

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

0041

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

0042

ここで、エンドポイントが変換された外部WEBサービスB用WEBサービスインターフェース記述文書108から内部WEBサービスB115を自動生成し、サービスとして公開する。そして、外部サービス監視処理部203に外部WEBサービスB用WEBサービスインターフェース記述文書108と、保存された外部WEBサービスB105を示すエンドポイントの情報を渡す。

0043

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

0044

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

0045

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

0046

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

0047

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

0048

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

0049

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

0050

宣言部301は、WEBサービスフロー記述文書106を特定する情報及び呼び出し先各WEBサービスのインターフェース記述文書を特定する情報311と、WEBサービスフロー処理で用いる変数情報312とが記述されている。

0051

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

0052

321は外部WEBサービスAを呼び出し、外部WEBサービスAに処理を行わせ、その処理結果のレスポンスメッセージを受信する処理内容が記述される。322は受信した処理結果のレスポンスメッセージから、処理結果を抽出し、外部WEBサービスBが解釈できるリクエストメッセージを生成する処理内容が記述される。323は外部WEBサービスBを呼び出し、外部WEBサービスBに処理を行わせ、その処理結果のレスポンスメッセージを受信する処理内容が記述される。324は受信した処理結果を含むレスポンスメッセージから処理結果を抽出し、次の外部WEBサービスが解釈できるリクエストメッセージを生成する処理内容が記述される。

0053

303はWEBサービスフロー記述文書106の具体例である。この例では、WSBPELというWEBサービスの処理フローXML文書で記述するための標準仕様になっている言語で記述されている。WSBPELは、Web Service Business Process Execution Languageの略である。また、XMLは、eXtensible Markup Languageの略である。以下、WEBサービスフロー記述文書106の構成と、WEBサービスフロー記述文書303とを比較する。

0054

331は311の記述内容に対応し、WEBサービスフロー記述文書を特定する情報と呼び出し先の各WEBサービスのインターフェース記述文書(WSDL文書)を特定する情報が記述される。ここでは、<process>タグの属性値としてネームスペースで記述されている。

0055

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

0056

333は321の記述内容に対応し、外部WEBサービスAを呼び出し、処理を行わせた結果のレスポンスメッセージを受信する処理内容が<invoke>タグで記述されている。

0057

334は322の記述内容に対応し、受信したレスポンスメッセージからXPathを利用して抽出した処理結果とXPathから外部WEBサービスBが解釈できるリクエストメッセージを生成する処理内容が記述される。ここでは、<assign>タグなどで記述されている。

0058

335は323の記述内容に対応し、外部WEBサービスBを呼び出し、処理を行わせた結果のレスポンスメッセージを受信する処理内容が記述される。ここでは、<invoke>タグで記述されている。

0059

336は324の記述内容に対応し、受信したレスポンスメッセージからXPathを利用して抽出した処理結果とXPathから次に呼び出す外部WEBサービスが解釈できるリクエストメッセージを生成する処理内容が記述される。ここでは、<assign>タグなどで記述される。

0060

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

0061

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

0062

次に、サービス自動公開処理部202の処理内容を、外部WEBサービスB用WEBサービスインターフェース記述文書108の具体例としてWSDLで記述された例を用いて説明する。

0063

図4は、外部WEBサービスB用インターフェース記述文書401の具体例を示す図である。402には外部WEBサービスB105のネットワーク上の所在を指し示すエンドポイントの情報403がWSDLの<address>タグとして記述されている。このエンドポイントの情報を、サービス自動公開処理部202では、自動生成する内部WEBサービスB115のネットワーク上の所在を指し示すエンドポイントの情報404に変換する。内部WEBサービスB115は、複合機101内部に公開するため、404に示すエンドポイントは、複合機101のネットワーク上の所在を指し示すものになる。

0064

次に、内部WEBサービスB115が、WEBサービスフロー処理装置102からのアクセスに対してどのような応答405をするかを説明する。WSDL401には、WEBサービスがリクエスト時に解釈できるメッセージの型と、その応答時に返すメッセージの型に関する情報が、XMLSchema406として記述されている。サービス自動公開処理部202では、実際のWEBサービスとのやりとりと同様に、SOAPメッセージをやりとりできるように内部WEBサービスB115を自動生成する。

0065

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

0066

その結果、WEBサービスフロー処理装置102は、応答としてSOAPメッセージを受信することができるため、その時点で処理が停止せず、受信した後のフロー処理を実行することが可能となる。

0067

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

0068

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

0069

次に、S502で、S501で生成したスタブを利用して外部WEBサービスB105にアクセスする。そして、S503で、外部WEBサービスB105から応答があったか否かを判定する。ここで応答がなければ、S502に戻り、上述の処理を繰り返す。

0070

一方、S502でアクセスした結果、外部WEBサービスB105が再び起動し、応答があれば、S503で応答ありと判定し、S504へ処理を進める。このS504では、サービス自動公開処理部202に外部WEBサービスB用WEBサービスインターフェース記述文書108のエンドポイント記述を元に戻すように通知する。

0071

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

0072

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

0073

[第2の実施形態]
次に、図面を参照しながら本発明に係る第2の実施形態を詳細に説明する。第2の実施形態でも、第1の実施形態と同様に、外部サービスをWEBサービスとして扱う。

0074

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

0075

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

0076

図6は、第2の実施形態における外部サービス監視処理部の処理を示すフローチャートである。第1の実施形態と同様に、S502で、アクセスした結果、外部WEBサービスB105から図6に示すようなSOAPメッセージ611が返ってきたとする。SOAPメッセージ611は、<env:Body>タグの中に<env:Fault>タグ612がある。

0077

つまり、SOAPメッセージ611はSOAPFaultである。SOAPFaultはWEBサービスにアクセスした結果、WEBサービス側はリクエストを受け付けたが、WEBサービス内部で処理している最中にエラーが発生した場合など、アクセスしてきた相手に返すSOAPメッセージである。

0078

SOAPFaultでは、<env:Code>タグ613で、エラーが発生した原因として、リクエストしてきた相手の問題か、WEBサービス側の問題かを示す。この例では<env:Value>タグの値がReceiverなので、WEBサービス側に問題があるということがわかる。また、<env:Value>タグの値がSenderであれば、リクエストしてきた相手側に問題があるということになる。

0079

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

0080

図6に示す614はエラー条件設定情報の一例であり、例えばXML形式で記述され、615の<message>タグの値としてSOAPFaultの値が記述され、616の<code>タグの値としてReceiverの値が記述されている。

0081

S601で、エラー条件設定情報614を読み込み、SOAPメッセージがSOAPFaultで、且つ、原因がWEBサービス側であった場合、エラー判定と解釈する。そのため、S602で、エラー判定処理を行い、SOAPメッセージ611とエラー条件設定情報614からSOAPメッセージ611では、まだエラーであると判定する。よって、S502に戻り、上述の処理を繰り返す。
第2の実施形態によれば、第1の実施形態の外部サービス監視処理において、外部からエラー条件設定情報を与えることで、外部サービスから応答があった場合にも監視を継続させるかを制御することが可能となる。

0082

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

0083

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

0084

情報処理装置は、ハードウェア構成として入力装置701と、表示装置702と、記憶媒体ドライブ装置703と、ROM705と、RAM706と、CPU又はMPU707と、インターフェース装置708と、HD(ハードディスク)709とを含む。入力装置701は、情報処理装置の操作者オペレータ)が操作するキーボード及びマウスなどで構成され、情報処理装置に各種操作情報などを入力するのに用いられる。表示装置702は、情報処理装置の操作者が利用するディスプレイなどで構成され、各種情報(又は画面)などを表示するのに用いられる。

0085

インターフェース装置708は、情報処理装置をネットワークなどに接続するインターフェースである。上述した処理などに係るプログラムは、例えばCD−ROMなどの記憶媒体704によって情報処理装置に提供されるか、ネットワークなどを通じてダウンロードされる。記憶媒体704は、記憶媒体ドライブ装置703にセットされ、プログラムが記憶媒体704から記憶媒体ドライブ装置703を介してHD709にインストールされる。

0086

ROM705は情報処理装置の電源投入時に最初に読み込まれるプログラムなどを格納する。RAM706は、情報処理装置のメインメモリである。CPU707は、HD709よりプログラムを読み出して、RAM706に格納し、プログラムを実行することで、前述の処理内容を実現したりする。HD709は、プログラム以外に、例えばWEBサービスフロー記述文書、WEBサービスインターフェース記述文書などを格納する。

0087

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

0088

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

0089

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

図面の簡単な説明

0090

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

符号の説明

0091

101複合機
102WEBサービスフロー処理装置
103外部サービス呼び出し処理自動切り替えサービスフロー処理部
104外部WEBサービスA
105 外部WEBサービスB
106WEBサービスフロー記述文書
107 外部WEBサービスA用WEBサービスインターフェース記述文書
108 外部WEBサービスB用WEBサービスインターフェース記述文書
109リクエストSOAPメッセージA
110レスポンスSOAPメッセージA
111 リクエストSOAPメッセージB
115 内部WEBサービスB
201エラー通知受信処理部
202サービス自動公開処理部
203 外部サービス監視処理部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ