(57)【要約】【課題】Ｗｅｂサービスを利用するクライアントおよびそのサービスを提供するサーバ側の双方の利便性を考慮した技術を提供する。【解決手段】クライアント装置（20）がサーバ装置（10）に対し同期通信により処理の実行要求を送信すると（S1）、サーバ装置が、同期通信を終了させる情報を応答する（S2）。サーバ装置は、要求された処理を実行すると共に（S3）、処理の実行状況を表すメタデータを生成する（S4）。クライアント装置は、処理の実行状況についてサーバ装置へ問い合わせを行い、サーバ装置は、その問い合わせに対し当該メタデータを送信する（S6,S10）。クライアント装置は、要求した処理の完了をメタデータにより認識したとき（S11）、処理の実行結果の通知要求をサーバ装置へ送信する（S12）。サーバ装置は、クライアント装置からの通知要求に対し当該実行結果を応答する（S13）。【選択図】図２
2008003689.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークに接続されたサーバ装置およびクライアント装置を備え、
前記クライアント装置は、前記サーバ装置に対し同期通信により処理の実行要求を送信する手段と、前記処理の実行状況を前記サーバ装置へ問い合わせる手段と、前記処理の実行結果の通知要求を前記サーバ装置へ送信する手段とを有し、
前記サーバ装置は、前記クライアント装置からの処理の実行要求に対し同期通信を終了させる情報を応答する手段と、前記クライアント装置から要求された処理を実行し且つ該処理の実行状況を表すメタデータを生成する手段と、処理の実行状況に関する前記クライアント装置からの問い合わせに対し当該メタデータを送信する手段と、処理の実行結果に関する前記クライアント装置からの通知要求に対し当該実行結果を応答する手段とを有することを特徴とする情報処理システム。
【請求項２】
前記サーバ装置は、処理の実行状況に関する前記クライアント装置からの問い合わせを受けたとき認証処理を実行し、認証に成功した場合に当該メタデータを送信することを特徴とする請求項１記載の情報処理システム。
【請求項３】
前記サーバ装置は、同期通信を終了させる前記情報として、例外処理に対応するメッセージを応答し、
前記クライアント装置は、前記サーバ装置から前記メッセージを含む応答を受けたとき、前記サーバ装置に対し処理の実行状況の問い合わせを開始することを特徴とする請求項１又は２記載の情報処理システム。
【請求項４】
前記サーバ装置は、メタデータをＸＭＬに基づく文書形式により生成することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
【請求項５】
自装置と通信ネットワークを介して接続されたサーバ装置に対し同期通信により処理の実行要求を送信する手段と、前記処理の実行状況を前記サーバ装置へ問い合わせる手段と、前記処理の実行結果の通知要求を前記サーバ装置へ送信する手段とを備えることを特徴とする情報処理装置。
【請求項６】
コンピュータを請求項５記載の情報処理装置として機能させることを特徴とするプログラム。
【請求項７】
自装置と通信ネットワークを介して接続されたクライアント装置からの同期通信による処理の実行要求に対し同期通信を終了させる情報を応答する手段と、前記クライアント装置から要求された処理を実行し且つ該処理の実行状況を表すメタデータを生成する手段と、処理の実行状況に関する前記クライアント装置からの問い合わせに対し当該メタデータを送信する手段と、処理の実行結果に関する前記クライアント装置からの通知要求に対し当該実行結果を応答する手段とを備えることを特徴とする情報処理装置。
【請求項８】
処理の実行状況に関する前記クライアント装置からの問い合わせを受けたとき認証処理を実行し、認証に成功した場合に当該メタデータを送信することを特徴とする請求項７記載の情報処理装置。
【請求項９】
同期通信を終了させる前記情報として、例外処理に対応するメッセージを応答することを特徴とする請求項７又は８記載の情報処理装置。
【請求項１０】
メタデータをＸＭＬに基づく文書形式により生成することを特徴とする請求項７乃至９のいずれか１項に記載の情報処理装置。
【請求項１１】
コンピュータを請求項７乃至１０のいずれか１項に記載の情報処理装置として機能させることを特徴とするプログラム。
【請求項１２】
クライアント装置が、自装置と通信ネットワークを介して接続されたサーバ装置に対し同期通信により処理の実行要求を送信するステップと、
前記サーバ装置が、前記クライアント装置からの処理の実行要求に対し同期通信を終了させる情報を応答するステップと、
前記サーバ装置が、前記クライアント装置から要求された処理を実行し且つ該処理の実行状況を表すメタデータを生成するステップと、
前記クライアント装置が、前記処理の実行状況を前記サーバ装置へ問い合わせるステップと、
前記サーバ装置が、処理の実行状況に関する前記クライアント装置からの問い合わせに対し当該メタデータを送信するステップと、
前記クライアント装置が、前記処理の実行結果の通知要求を前記サーバ装置へ送信するステップと、
前記サーバ装置が、処理の実行結果に関する前記クライアント装置からの通知要求に対し当該実行結果を応答するステップとを備えることを特徴とする情報処理方法。
【請求項１３】
前記サーバ装置が、メタデータを送信する前記ステップにおいて、
処理の実行状況に関する前記クライアント装置からの問い合わせを受けたとき認証処理を実行し、認証に成功した場合に当該メタデータを送信することを特徴とする請求項１２記載の情報処理方法。
【請求項１４】
前記サーバ装置が、同期通信を終了させる情報を応答する前記ステップにおいて、例外処理に対応するメッセージを前記情報として応答し、
前記クライアント装置が、処理の実行結果の通知要求を送信する前記ステップを、前記サーバ装置から前記メッセージを含む応答を受けたとき開始することを特徴とする請求項１２又は１３記載の情報処理方法。
【請求項１５】
前記サーバ装置が、メタデータを生成する前記ステップにおいて、
メタデータをＸＭＬに基づく文書形式により生成することを特徴とする請求項１２乃至１４のいずれか１項に記載の情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、HTTP（HyperText Transfer Protocol）/HTTPS（HTTP Security）のような同期通信の通信プロトコルを利用したＷｅｂサービスの技術に関する。
【背景技術】
【０００２】
図９に、一般的なＷｅｂサービスの形態を模式的に示す。Ｗｅｂサービスを提供するサーバ１と、サーバ１に対しサービスを要求するクライアント２との間では、他のコンピュータにあるデータを取得するための通信プロトコルとしてSOAP（Simple Object Access Protocol）が利用される。
【０００３】
SOAPを利用するサーバ１及びクライアント２は、例えば、WSDL（Web Services Description Language）なるフォーマットに従い作成されたXML（eXtensible Markup Language）ベースのSOAPメッセージをHTTP/HTTPSにより授受する。このようなHTTP/HTTPSにSOAPを適用した通信形態は「SOAP over HTTP/HTTPS」と称され、Ｗｅｂサービスに広く利用されている。
【０００４】
ところで、HTTP/HTTPSによる通信は、サーバがクライアントからリクエストを受信したとき所定期間内にレスポンスを送ることを基本とする同期通信である。よって、HTTP/HTTPSは、例えば、通信帯域や時間に使用制限があるクライアントのように、非同期通信が望まれるクライアントには対処が困難である。
【０００５】
一方、SOAP自体は、ベースとなる通信プロトコルが指定されていないことから、HTTP/HTTPS以外のプロトコルにも適用可能である。よって、非同期通信のニーズに応じるためには、例えば図１０に示すように、POP（Post Office Protocol）/SMTP（Simple Mail Transfer Protocol）あるいはJMS（Java（登録商標） Message Service）のようなプロトコルをSOAPと併用すればよい。
【０００６】
図１０に示す通信形態において、クライアント４は、HTTP/HTTPSにより交信するサーバ１とは別個に設けられた、POP/SMTPやJMS専用のサーバ３と交信する。そして、この専用のサーバ３を介して、HTTP/HTTPSによるサーバ１からデータを取得する。
【０００７】
このようにネットワークを利用して他のコンピュータからデータを取得する技術に関し、例えば、後述の特許文献１に記載のものがある。特許文献１に記載の技術は、機器の状態やその機器の動作ログなどの情報を外部に提供する機能を持つネットワーク装置が、RDF等のXML形式のフォーマットにより上記情報を作成し、その情報をクライアント側の仕様に合わせてHTML形式等に変換して提供するというものである。
【特許文献１】特開２００５−２０９０５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、前述の図１０に示すような通信形態の場合、クライアント４は、一般に普及している「SOAP over HTTP/HTTPS」のサービスを利用することができない。また、ＷｅｂサービスのためにPOP/SMTPやJMS専用のサーバ３の介在が必要とされることで、このサーバ３の処理負荷が増大するという問題もある。
【０００９】
一方、上記特許文献１に記載の技術では、HTML形式等、クライアント側のフォーマット形式に合わせてＷｅｂサービスが提供される。しかしながら、そのためには、サーバ（ネットワーク装置）が、XML形式にて作成した情報をその都度HTML形式等に変換する必要がある。よって、サーバでは、クライアント側の多様なフォーマット形式に対処すべく複数の変換パターンを想定する必要があり、そのようなサーバの管理は容易ではない。
【００１０】
本発明は、上記課題に鑑みてなされたものであり、同期通信のＷｅｂサービスを利用するクライアントおよびそのサービスを提供するサーバ側の双方の利便性を考慮した技術を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明に係る情報処理システムは、通信ネットワークに接続されたサーバ装置およびクライアント装置を備え、前記クライアント装置は、前記サーバ装置に対し同期通信により処理の実行要求を送信する手段と、前記処理の実行状況を前記サーバ装置へ問い合わせる手段と、前記処理の実行結果の通知要求を前記サーバ装置へ送信する手段とを有し、前記サーバ装置は、前記クライアント装置からの処理の実行要求に対し同期通信を終了させる情報を応答する手段と、前記クライアント装置から要求された処理を実行し且つ該処理の実行状況を表すメタデータを生成する手段と、処理の実行状況に関する前記クライアント装置からの問い合わせに対し当該メタデータを送信する手段と、処理の実行結果に関する前記クライアント装置からの通知要求に対し当該実行結果を応答する手段とを有する。
【発明の効果】
【００１２】
本発明によれば、クライアント装置から同期通信により処理の実行要求を受けたサーバ装置が、一旦その同期通信を終了させ、別途、その処理の実行結果をクライアント装置へ応答するよう構成したことから、同期通信の環境下で、非同期通信と同様な通信形態を提供することができる。さらに、処理の要求から処理結果の応答までの間、その処理の実行状況をクライアント装置から確認することができるため、処理結果を取得すべきタイミングを適切に認識することができる。これにより、処理の要求から処理結果の取得までを迅速に行うことができ、結果、ユーザの利便性が高められる。
【発明を実施するための最良の形態】
【００１３】
図１に、本発明の実施形態のシステム構成を示す。本実施形態のシステムは、通信ネットワーク１００に接続されたサーバ１０およびクライアント２０を備える。サーバ１０は、クライアント２０に対し通信ネットワーク１００を介してＷｅｂサービスを提供する事業者のコンピュータである。クライアント２０は、サーバ１０によるＷｅｂサービスを利用する個人あるいは企業等のユーザが使用するコンピュータである。
【００１４】
サーバ１０は、図１に示すように、クライアント２０から要求されるＷｅｂサービスに関する処理を実行するＷｅｂサービス処理部１１と、Ｗｅｂサービスの処理状況に関する後述のメタデータを処理するメタデータ処理部１２とを備える。これらは、クライアント２０のＣＰＵ（図示略）が実行するプログラムに対応する機能である。
【００１５】
クライアント２０は、サーバ１０により提供されるＷｅｂサービスを利用するためのプログラムに対応するＷｅｂサービスクライアント部２１を備える。
【００１６】
図２に示すシーケンスを参照して、本実施形態の動作について説明する。まず、クライアント２０のＷｅｂサービスクライアント部２１は、Ｗｅｂサービスを利用すべく、サーバ１０に対しHTTP/HTTPS通信によりSOAPメッセージを送信する（ステップＳ１）。このSOAPメッセージは、サーバ１０に対し処理の実行要求を通知するためのHTTP/HTTPSリクエストに記述されるメッセージであり、一般のSOAP仕様のフォーマットに基づき作成される。
【００１７】
サーバ１０のＷｅｂサービスクライアント部２１は、クライアント２０からのSOAPメッセージを受信すると、そのリクエストに対するレスポンス処理を例外処理として取り扱う。これは、現時点のセッションを終了させるための、便宜上の取り扱いであり、クライアント２０から要求された処理自体が例外処理の対象であることを意味するものではない。
【００１８】
Ｗｅｂサービスクライアント部２１は、便宜上の例外処理として、「SOAP Fault」のメッセージを記述したHTTP/HTTPSレスポンスをクライアント２０へ送信する（ステップＳ２）。このとき送信されるレスポンスの一例を図３に示す。
【００１９】
図３に示すように、HTTP/HTTPSレスポンスのステータスコード（３ａ）は、受信確認を表す「202」のようなコードとし、レスポンス内のSOAPメッセージには「SOAP Fault」（３ｂ）を作成する。また、この「SOAP Fault」のdetail要素（３ｃ）には、クライアント２０から受けた処理に割り当てたＩＤと、後述のメタデータが公開されるＵＲＬとを記述する。なお、HTTP/HTTPSレスポンスのステータスコード（３ａ）は、図示の例のように「202」とすることが望ましいが、不都合がある場合は、「500」（Internal Server Error）などであってもよい。
【００２０】
サーバ１０からの上記HTTP/HTTPSレスポンスがクライアント２０により受信されると、いったん両者間のHTTP/HTTPS通信が終了する。
【００２１】
続いて、サーバ１０のＷｅｂサービス処理部１１は、クライアント２０から要求された処理を実行する（ステップＳ３）。この間、メタデータ処理部１２は、処理の実行状況を表すメタデータを生成し、それを記憶デバイス（図示略）へ保存する（ステップＳ４）。メタデータは、RSS（Really Simple Syndication / RDF Site Summary）あるいはAtomのようなXMLベースのフォーマットに従い作成される。
【００２２】
図４、図５及び図６に、メタデータの事例を示す。図４は、RSS1.0形式のフォーマットにより作成されたメタデータの例であり、図５は、RSS2.0形式のメタデータの例であり、そして、図６は、Atom0.3形式のメタデータの例である。
【００２３】
メタデータ処理部１２は、図４乃至図６のような形態で生成したメタデータを、前述のHTTP/HTTPSレスポンスによりクライアント２０に通知したＵＲＬ（図３：３ｃ）にて公開する（ステップＳ５）。そして、処理の開始から所定期間ごとに実行状況のメタデータを生成し、生成の都度、公開するメタデータを更新する。
【００２４】
ここで、サーバ１０により公開されるメタデータは、少なくとも、処理が完了したか否かを公開することを目的としたものである。よって、メタデータの更新は、本実施形態のように定期的に行うことに替えて、例えば、処理の開始時および完了時、あるいは完了時のみに行うようにしてもよい。これにより、サーバ１０の処理負荷が軽減される。
【００２５】
一方、クライアント２０は、サーバ１０から受信したHTTP/HTTPSレスポンス（図３）に記述されている処理ＩＤとメタデータの公開ＵＲＬとを用いて、処理の実行状況を定期的にサーバ１０へ問い合わせる（ステップＳ６）。すなわち、サーバ１０に要求した処理に関し公開されているメタデータの更新を確認する。この確認は、予めＷｅｂサービスクライアント部２１に設定した、いわゆるRSSリーダ等のソフトウェアにより行うことができる。
【００２６】
サーバ１０は、クライアント２０から要求された処理を実行し終えると（ステップＳ７）、処理の完了を表すメタデータを生成し公開する（ステップＳ８、Ｓ９）。
【００２７】
クライアント２０は、問い合わせにより取得したメタデータから処理の完了を認識すると（ステップＳ１０、Ｓ１１）、処理結果を要求するための図７に示すようなHTTP/HTTPSリクエストをサーバ１０へ送信する（ステップＳ１２）。このリクエストに含まれるSOAPメッセージのヘッダ（７ａ）には、先にサーバ１０から通知された処理ＩＤを記述する。
【００２８】
サーバ１０は、上記リクエストをクライアント２０から受信すると、その応答としてのHTTP/HTTPSレスポンスにより、処理ＩＤに対応する処理結果を送信する（ステップＳ１３）。なお、実際に例外処理が発生していた場合、すなわち、当初にクライアント２０から要求された処理がサーバ１０における例外処理の対象であった場合は、このHTTP/HTTPSレスポンス（ステップＳ１３）に、例外処理の旨を示すSOAPメッセージを記述する。
【００２９】
このように上記実施形態によれば、HTTP/HTTPSによる同期通信の環境下で、非同期通信と同様な形態によりＷｅｂサービスを提供することができる。その理由は、サーバ（１０）が、クライアント（２０）からの処理要求に対し、一旦そのセッションを終了させる応答を返すからである。また、「SOAP Fault」に処理状況の参照先ＵＲＬを記述してクライアント（２０）へ通知し、別途、その処理状況をメタデータで提供することから、クライアント側は、別のＷｅｂサービスなどを併用することなく、単一のＵＲＬにより非同期通信によるサービスを受けることができる。
【００３０】
また、ファイヤーウォールを介在させたＷｅｂサービスを維持することができる。その理由は、既存のHTTP/HTTPS通信の環境を利用するからである。通常、HTTP/HTTPS通信に設定するファイヤーウォールは、他の通信プロトコルよりも制限が比較的少なく、セキュリティ設定に関しての柔軟性がある。
【００３１】
さらにまた、Ｗｅｂサービスクライアント（２１）にメタデータの解析機能が具備されていない場合でも、本実施形態のＷｅｂサービスを利用することができる。その理由は、広く普及しているRSSやAtom等のフォーマットを利用してメタデータが生成されるからである。
【００３２】
［他の実施形態］
サーバ１０が、公開したメタデータをクライアント２０に供給する際、そのクライアント２０に対し認証処理を行うようにしてもよい。例えば、サーバ１０がRSSリーダ等により問い合わせを受けたとき、該当のメタデータを送信するに先立ち、従来知られたBasic認証等の認証技術により、クライアント２０の正当性を判定する。そして、クライアント２０から取得した個人情報（ユーザＩＤ／パスワード等）の認証が成功した場合に、そのクライアント２０へ該当のメタデータを送信する。これにより、Ｗｅｂサービスの処理に関し、その処理状況を正当なユーザのみが確認することができ、結果、各ユーザのサービス利用状況等が漏洩することを防止できる。
【００３３】
また、クライアント２０から送信するHTTP/HTTPSリクエストにＷｅｂサービスの処理ＩＤを記述することに関し、例えば図８に示すように、そのＩＤをHTTP/HTTPSリクエストのヘッダにCookieとして記述するようにしてもよい（図８：８ａ）。このように既存のCookie技術を利用することにより、クライアント２０がHTTP/HTTPSリクエストに処理ＩＤを設定すること、及び、そのＩＤをサーバ１０で判別することが簡便となる。
【図面の簡単な説明】
【００３４】
【図１】本発明の実施形態のシステム構成を示すブロック図である。
【図２】実施形態の動作手順を示すシーケンス図である。
【図３】実施形態におけるSOAP_Faultに関する説明図である。
【図４】実施形態におけるメタデータの事例（RSS1.0）に関する説明図である。
【図５】実施形態におけるメタデータの事例（RSS2.0）に関する説明図である。
【図６】実施形態におけるメタデータの事例（Atom）に関する説明図である。
【図７】実施形態における処理結果の要求に関する説明図である。
【図８】本発明の他の実施形態におけるSOAP_Faultに関する説明図である。
【図９】従来のＷｅｂサービスのシステムに関する説明図である。
【図１０】従来のＷｅｂサービスの他のシステムに関する説明図である。
【符号の説明】
【００３５】
１００  通信ネットワーク
１０  サーバ
１１  Ｗｅｂサービス処理部
１２  メタデータ処理部
２０  クライアント
２１  Ｗｅｂサービスクライアント部
【図１】
2008003689.tif 000003
【図２】
2008003689.tif 000004
【図３】
2008003689.tif 000005
【図４】
2008003689.tif 000006
【図５】
2008003689.tif 000007
【図６】
2008003689.tif 000008
【図７】
2008003689.tif 000009
【図８】
2008003689.tif 000010
【図９】
2008003689.tif 000011
【図１０】
2008003689.tif 000012