JP4140448B2 - Ｗｅｂサービスシステムおよびその情報通知方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、Webサービスシステムに関するものであり、とくに、WebサービスのRPC（Remote Procedure Call)において片方向だけでHTTP（Hyper Text Transfer Protocol)通信するネットワーク環境等のWebサービスシステムに適用して好適なものであり、また、本発明は、Webサービスシステムの情報通知方法に関するものであり、Webサービスシステムにてそれぞれ互いにファイアウォールが形成され、片方向通信でありながら、リアルタイム性を保つ通信シーケンス等に適用して好適なものである。
【０００２】
【従来の技術】
現在、XML（eXtensible Markup Language）とHTTP（Hyper Text Transfer Protocol）を応用したRPC（Remote Procedure Call）技術を利用したシステム構築が行われている。このRPC技術をXML Webサービスという。このサービスでは、非特許文献１〜５に挙げる技術を使用している。XML Webサービスにおいてクライアント側にはWebサービスクライアントおよびWebサービススタブが設けられている。また、サーバ側にはWebサービスサーバ、WebサービススケルトンおよびWebサーバが設けられている。クライアント側のWebサービススタブとWebサーバのゲート側にはファイアウォールがそれぞれ形成されている。WebサービススタブとWebサーバは、HTTPに基づいて通信を行っている。
【０００３】
Webサービスクライアントは、Webサービスサーバから提供されるプログラムをクライアントプログラムとして利用して動作する機能を有している。Webサービスクライアントは、通常UDDI（Universal Description Discovery and Integration Protocol)のレジストリにアクセスして利用するサービスのWSDL（Web Service Description Language)を獲得する機能と、獲得したWSDLからWebサービススタブを生成する機能とを有している。
【０００４】
Webサービススタブは、Webサービスクライアントが使用するプログラムモジュールである。Webサービススタブは、Webサービスを利用する関数呼出しまたはメソッド呼出しをSOAP（Simple Object Access Protocol)メッセージに変換する機能を有し、SOAPメッセージをHTTP等に応じて動作する通信路を利用してサーバ側に送信する機能も持っている。クライアント側では、内部から外部へのアクセスだけを可能とする場合が多い。
【０００５】
一方、Webサーバは、クライアントからのHTTP要求（リクエスト）を受信し、受信したURL（Universal Resource Locater)情報からWebサーバ上で稼動するWebサービスサーバを検索し、WebサービススケルトンにHTTP要求を配送する。
【０００６】
Webサービススケルトンは、Webサービスサーバが構築する環境に応じて生成されるサーバモジュールである。Webサービススケルトンは、Webサーバから供給されるHTTP要求内のSOAPメッセージを解釈し、SOAPメッセージが指定するWebサービスサーバ上の関数またはメソッドを呼び出す機能を有している。Webサービスサーバは、Webサービスが提供する機能を実装したサーバである。Webサーバ以外のサーバ環境は、クライアント側からのアクセスが可能なように設定されている。
【０００７】
XML Webサービスの構成においてRPCを実行する手順を説明する。最初に、WebサービスクライアントはWebサービススタブに対してWebサービスで利用する関数呼出しを発行する。Webサービススタブは、この発行を受けて、関数呼出しの内容をSOAPメッセージに格納し、このSOAPメッセージを本体に格納したHTTP要求をWebサーバに転送する。
【０００８】
Webサーバは、HTTP要求に含まれるURL情報からSOAPメッセージの転送先を検索する。Webサーバは、検索結果をSOAPメッセージにしてクライアント側のWebサービススケルトンに転送する。Webサービススケルトンは、転送されたSOAPメッセージを解釈し、Webサービスサーバに解釈結果を供給する。
【０００９】
Webサービスサーバは、解釈結果を基に対応して提供する関数を呼び出す。この関数は、最初に発行した関数呼出しと同等のものである。Webサービスサーバは、呼び出した関数を処理する。処理内容は、サービス提供者（サーバ）側が任意に実装するもので、XML Webサービスにおけるこの処理に関する規定はない。Webサービスサーバは、処理結果をWebサービススケルトンに返す。
【００１０】
Webサービススケルトンは、処理結果をSOAPメッセージに変換し、Webアクセスの応答としてWebサーバに返す。Webサーバは、受信したSOAPメッセージを本文とするHTTP応答（レスポンス）をサーバ側からクライアント側のWebサービススタブに返される。
【００１１】
Webサービススタブは、供給されたSOAPメッセージを解釈し、SOAPメッセージ内の応答情報をWebサービスクライアントに返して一連の処理を終える。
【００１２】
ところで、近年、IP（Internet Protocol)電話等のようにIPネットワーク上で音声等のリアルタイムコミュニケーションを実現する技術やプロトコルが開発されている。IETF（the Internet Engineering Task Force)が規定するセッション初期化プロトコル（SIP: Session Initiation Protocol)は、このリアルタイムコミュニケーションを行うためのシグナリングを目的とするプロトコルである。このプロトコルは、今後広く利用されることが予想されている。
【００１３】
音声等のリアルタイムコミュニケーションには、Webサーバ等の単純なクライアント・サーバによるモデルと異なり、双方向に通信できることが要求される。すなわち、どちらの端末装置からでも通信相手側を呼び出すことが要求される。しかしながら、前述したように、それぞれクライアント側やWebサーバ側には、現在、ファイアウォールが設置され、片方向の通信しかできない設定になっているものが多い。このような環境では双方向通信がHTTPと同様に行えない。
【００１４】
そこで、これを考慮してSIPの標準化が進められている。これにより、たとえば、UPnP（Universal Plug and Play)に対応したデバイスは、要求に応じてSIPメッセージを受信するポートを開くことができ、双方向の通信を実現している（非特許文献５を参照）。
【００１５】
【非特許文献１】
http://www.w3.org/2002/ws/, SOAP（Simple Object Access Protocol), WSDL: Web Service Description Languageに関する
【非特許文献２】
http://www.uddi.org/, UDDI: Universal Description, Discovery and Integration Protocolに関する
【非特許文献３】
http://www.w3.org/XML/, XML: eXtensible Markup Languageに関する
【非特許文献４】
http://www.ietf.org/, HTTP: Hyper Text Transfer Protocolに関し、とくに、RFC（Request For Comments)2616やRFC2617等の規格がある
【非特許文献５】
http://www.upnp.org/, UPnP: Universal Plug and Playに関する。
【００１６】
【発明が解決しようとする課題】
ところで、このようにHTTPプロトコルを転送層に用いたXML Webサービスでは、WebサービスサーバがWebサービスクライアントにイベントを通知する場合、またはWebサーバ側からクライアント側に対して明示的にRPCを起動する場合のようにSOAPメッセージを逆方向に転送するときに制約が存在する。
【００１７】
第１の制約は、通常のネットワーク構成においてクライアント側がHTTP要求を受信可能なファイアウォールの設定にないことである。HTTPは片方向だけの通信である。第２の制約は、SOAPプロトコル自体が本来転送プロトコルに依存しない定義であることから、SMTP（Simple Mail Transfer Protocol)等を双方向通信に利用することも検討されているが、リアルタイム性に欠ける点でイベント通知に適さない。
【００１８】
第３の制約は、双方通信可能なネットワークを構築し、単にXML Webサービス環境を対向して設置しても、これらのサービス環境が互いに独立したものであることから、関連した動作を行わせる上で大幅なサーバ環境の変更が要求される。ここで、一つのXML Webサービス環境でイベント通知を行う場合、定期的にクライアントがサーバ側にポーリングしてイベントメッセージを獲得することができる。しかしながら、この方法は、第４の制約として、不要なメッセージ通信が大量に発生する。これを回避するためポーリング間隔の時間を長くしてメッセージ通信量を減らすと、イベント通知間隔も長くなることから、この方法ではリアルタイム性が失われてしまう。
【００１９】
SIPのようなリアルタイムコミュニケーションを行うシグナリングプロトコルは、双方向通信の技術が開発されてきているが、SOAPの転送プロトコルとして利用する場合に問題がある。高速・軽量のシグナリングプロトコル、たとえばSIPにおけるメッセージは、ボディに非常に少量の情報しか添付できないという特徴がある。一方、SOAPメッセージは、メッセージサイズが可変で、上限が定められていない。このような両者の関係を考慮すると、このシグナリングプロトコルにはSOAPメッセージをボディとして利用できない。
【００２０】
本発明はこのような従来技術の欠点を解消し、片方向通信のネットワーク環境でもリアルタイムにイベント通知することができるWebサービスシステムおよびその情報通知方法を提供することを目的とする。
【００２１】
【課題を解決するための手段】
本発明は上述の課題を解決するために、提供される機能を利用するクライアントプログラムを有する情報処理手段およびこのクライアントがWebサービスの利用要求に対応するメッセージ情報に変換し、Webサービスを提供するサーバ側と前記メッセージ情報を第１のネットワークプロトコルにより通信する第１の通信機能ブロックを有するクライアント端末装置と、第１の通信機能ブロックと第１のネットワークプロトコルで通信するWebサーバ、このWebサーバを介して供給されるメッセージ情報に対する逆変換を行って利用要求の要求情報を復元し、この復元された要求情報に対応するプログラムを呼び出して実行処理を行うサービス実行機能ブロックおよびWebサービスが提供する機能をプログラム化して実装する機能提供手段を有するWebサービス装置とを含むWebサービスシステムにおいて、クライアント端末装置は、第１の通信機能ブロックに接続して、得られる情報を第２のネットワークプロトコルによりWebサービス装置と双方向通信する第２の通信機能ブロックを含み、Webサービス装置は、サービス実行機能ブロックに接続して、得られる情報を第２のネットワークプロトコルにより第２の通信機能ブロックと双方向通信するユーザ通信機能ブロックを含むことを特徴とする。
【００２２】
本発明のWebサービスシステムは、クライアント端末装置とWebサービス装置で構築されているクライアント-サーバのシステムにおいて、第１のネットワークプロトコルにより通信を行うとともに、第２の通信機能ブロックを第１の通信機能ブロックに接続し、ユーザ通信機能ブロックをサービス実行機能ブロックに接続して、得られる情報を第２のネットワークプロトコルによりクライアント端末装置とWebサービス装置との間で双方向通信させることにより、片方向の通信システムを用いて、サーバ環境の大幅な変更を行うことなく、要求に応じた通信だけを行って、メッセージ通信の大量発生を防止し、第２のネットワークプロトコルによる通信をトリガとして利用してリアルタイム性も保つことができる。
【００２３】
また、本発明は上述の課題を解決するために、提供される機能を利用するクライアント端末装置とWebサービスを提供するWebサービス装置とで構築したネットワーク間を第１のネットワークプロトコルに応じて通信するWebサービスシステムの情報通知方法において、この方法は、このWebサービスにおける事象の発生条件を満たす状況に応じた情報の登録に用いるプログラムを要求する第１の工程と、クライアント端末装置とWebサービス装置との間を第２のネットワークプロトコルで動作させるクライアント端末装置にてWebサービス装置からの情報を着信する際に用いる着信情報が何かを問い合せて、この問い合せた着信情報を取得する第２の工程と、この着信情報を第１のネットワークプロトコルで規定されたメッセージ情報に格納した要求信号としてクライアント端末装置からWebサービス装置に転送する第３の工程と、Webサービス装置にて受信したメッセージ情報から転送先の検索およびこのメッセージ情報を解釈し、このメッセージ情報の中からこのWebサービスの配送で用いる情報を格納する第４の工程と、この格納した情報が取り出された残りの情報に対して登録するプログラムを呼び出して、実行する第５の工程と、この実行結果をメッセージ情報の形式に変換し、第１のネットワークプロトコルにおける応答信号としてクライアント端末装置に返す第６の工程と、メッセージ情報の内容を解釈する第７の工程とを含むことを特徴とする。
【００２４】
本発明のWebサービスシステムの情報通知方法は、情報の登録に用いるプログラムを要求し、第２のネットワークプロトコルで動作させるクライアント端末装置にてWebサービス装置からの情報を着信する際に用いる着信情報が何かを問い合せて、この問い合せた着信情報を取得してトリガにするとともに、登録されたものか判別して管理を可能にし、この着信情報を第１のネットワークプロトコルで規定されたメッセージ情報に格納した要求信号としてクライアント端末装置からWebサービス装置に転送し、Webサービス装置にて受信したメッセージ情報から転送先の検索およびこのメッセージ情報を解釈し、このメッセージ情報の中からこのWebサービスの配送で用いる情報を格納して、クライアント端末装置での着信情報および事象の発生条件を管理することができ、この格納した情報が取り出された残りの情報に対して登録するプログラムを呼び出して、実行し、この実行結果をメッセージ情報の形式に変換し、第１のネットワークプロトコルにおける応答信号としてクライアント端末装置に返し、メッセージ情報の内容を解釈することにより、事象の発生条件に応じた着信情報がクライアント端末装置およびWebサーバ装置でそれぞれ、管理されることから、リアルタイムな情報の通知を可能にする。
【００２５】
【発明の実施の形態】
次に添付図面を参照して本発明によるWebサービスシステムの一実施例を詳細に説明する。
【００２６】
本実施例は、本発明のWebサービスシステムをWebクライアントサーバシステム10に適用した場合である。本発明と直接関係のない部分について図示および説明を省略する。以下の説明で、信号はその現れる接続線の参照番号で指示する。
【００２７】
Webクライアントサーバシステム10は、クライアント端末装置12およびWebサービス装置14を含んでいる。クライアント端末装置12は、便宜上一つだけ図示しているが、Webサービス装置14にはネットワーク16を介して複数接続できることは言うまでもない。
【００２８】
クライアント端末装置12は、Webサービスクライアント18、Webサービススタブ20およびSIPユーザエージェント22を含む。また、Webサービス装置14は、Webサービスサーバ24、Webサービススケルトン26、Webサーバ28およびSIPユーザエージェント30を含む。
【００２９】
クライアント端末装置12におけるWebサービスクライアント18およびWebサービススタブ20は、従来の技術で説明した機能と同じ機能を有し、互いに接続されている。すなわち、Webサービスクライアント18は、クライアントプログラムであり、情報処理機能部である。Webサービスクライアント18は、Webサービス装置14、とくに、Webサービスサーバ24が提供する、サービスの利用機能およびイベント情報の受信機能を有している。
【００３０】
Webサービススタブ20は、Webサービスクライアント18が使用するプログラムモジュールで、Webサービスのプロキシとして動作する。Webサービススタブ20は、Webサービスにおいて利用するローカルクラスの関数呼出しまたはメソッド呼出しをSOAPメッセージに変換する第１の機能、SOAPメッセージをハイパーテキスト記述言語の転送用プロトコルHTTP（第１のネットワークプロトコル）に基づきWebサービス装置14に送信する第２の機能、SIPユーザエージェント22からのイベント着信を受信する第３の機能およびSIPユーザエージェント22で受信したイベントをWebサービス装置14に送信する第４の機能を有している。
【００３１】
ここで、SOAPについて簡単に説明する。現在、SOAPは、version1.2（2003年1月24日）で、分散化した分布環境において交換するように構造化された情報を目的とした軽いプロトコルとしてW3C（World-Wide-Web Consortium)の候補勧告がある。
【００３２】
SIPユーザエージェント22は、セッション初期化プロトコル（SIP)を用いてWebサービス装置14のSIPユーザエージェント30と相互通信するプログラムモジュールである。SIPユーザエージェント22は、Webサービススタブ20に接続され、イベント情報を授受する機能を有し、SIP要求を生成する際にUAC（User Agent Client)として動作し、要求を処理して応答を生成する際にUAS（User Agent Server)として動作している。また、SIPユーザエージェント22は、要求-応答のやりとりを表すトランザクションを実行し、各トランザクションを管理する。
【００３３】
なお、SIPユーザエージェント22は、単体のプログラムとしての動作やWebサービススタブ20内のモジュールとしての動作のいずれで動作させても構わない。
【００３４】
Webサービスサーバ24は、Webサービスを提供する機能が実装されたサーバである。Webサービスサーバ24は、Webサービススケルトン26と接続されている。Webサービススケルトン26は、Webサーバ28から受信したHTTP要求内のSOAPメッセージを解釈して、解釈した結果のSOAPメッセージが指定するWebサービスサーバ24上の関数またはメソッドを適切に呼び出す機能を有している。スケルトンは、タイクラスとも呼ばれる。Webサービススケルトン26は、Webサーバ28だけでなく、SIPユーザエージェント30とも接続している。Webサービススケルトン26は、SIPユーザエージェント30を用いてイベントの送受信を行う機能を有している。
【００３５】
Webサーバ28は、クライアント端末装置12（クライアント側）からHTTP要求を受信し、受信した情報に含まれるURL情報に基づいてWebサーバ上で稼動するWebサービスサーバを検索し、HTTP要求を適切なサーバモジュール、たとえばWebサービススケルトン26に配送する機能を有している。
【００３６】
SIPユーザエージェント30は、SIPユーザエージェント22と同じ構成で、SIPを用いてSIPユーザエージェント22と相互通信するプログラムモジュールである。また、SIPユーザエージェント30は、単体動作およびWebサーバ28またはWebサーバスケルトン26内のモジュールの動作のいずれとしても構わない。上述の動作にかかわらず、SIPユーザエージェント30は、Webサービススケルトン26と接続して、イベント情報の授受を行う機能を有している。
【００３７】
クライアント端末装置12およびWebサービス装置14には、それぞれクライアント環境とサーバ環境を保護するファイアウォール32, 34が設けられている。ファイアウォール32は、クライアント側からのHTTP要求およびSIPプロトコルが受信可能なように設定されている。また、ファイアウォール34は、HTTPプロトコルが内部から外部へのアクセスだけを可能にするように設定されている。ただし、ファイアウォール34は、SIPプロトコルに関してたとえば、UPnP等の技術を用いて要求に応じて受信が制御できるように設定されている。
【００３８】
このように構成して、Webクライアントサーバシステム10は、片方向通信のネットワーク環境でも、SIPユーザエージェント22, 30の相互通信を利用してリアルタイムにイベント通知ができるようにしている。Webクライアントサーバシステム10の有利な点についていくつかの動作により説明する。
【００３９】
最初に、Webクライアントサーバシステム10においてWebクライアント18がWebサービスサーバ24にイベント登録する場合を説明する（図２を参照）。ここで、イベントを受信するクライアントにはあらかじめWebサービス装置14に対して受信するイベントの種別や条件が登録されている。登録処理は、図２に示すように、Webサービスクライアント18は、時刻T10にてWebサービススタブ20に対してイベント登録用の関数呼出しを発行する（FUNC_CALL 40)。この呼出しは、受信するイベントに対する指定が明示的または暗黙的に行われ、この条件をイベント発火条件という。
【００４０】
Webサービススタブ20は、SIPユーザエージェント22にイベントの着信に用いる情報の問合せを行う（REQUEST 42）。SIPユーザエージェント22は、時刻T14にて問合せに対する各種情報を返して応答する（RESPONSE 44）。ここで、各種情報とは、イベントの着信を待ち受けるポート番号や着信したイベントを判別する識別情報（ID: IDentify）等である。この要求-応答により、Webサービススタブ20は、SIPユーザエージェント22に着信したイベント情報がWebサービスクライアント18内のどのモジュールが登録したものであるかを判別する情報として取得し、管理することができるようになる。
【００４１】
Webサービススタブ20は、この要求-応答をトリガとしてイベント登録時の引数およびSIPユーザエージェント22からの応答（RESPONSE)に含まれる情報をSOAPメッセージに格納し、さらに、SOAPメッセージをHTTPのボディに格納したHTTP要求信号を生成する。Webサービススタブ20は、時刻T16において生成したHTTP要求信号（HTTP REQ. 46)をWebサーバ28に転送する。
【００４２】
Webサーバ28は、受信したHTTP要求信号に含まれるURLからSOAPメッセージの転送先を検索する。この検索後、時刻T18でWebサーバ28は、SOAPメッセージをWebサービススケルトン26に供給する（MESSAGE 48)。
【００４３】
Webサービススケルトン26は、供給されたSOAPメッセージを解釈する。Webサービススケルトン26は、この解釈により得られたイベント配送に要求される情報（DIST_INF 50）を時刻T20にて内部に格納する。この格納は、データベース等を用いた永続的なものに限定されず、メモリ上への一時的な格納でもよい。このような格納は、配送されるイベント情報の重要度等に応じて決められる。Webサービススケルトン26は、この格納によりイベント発火時、イベント情報を通知するSIPユーザエージェント22に関する情報を管理することになる。
【００４４】
Webサービススケルトン26は、時刻T24にてイベント配送の情報を取り出した後に残るイベント発火条件に関連する情報をWebサービスサーバ24に通知する。この情報は、Webサービスサーバ24に通知される。通知は、Webサービスサーバ24が提供する関数をWebサービススケルトン26に呼び出して、この関数を介してWebサービスサーバ24に返すことで行う（FUNC_CALL 51）。Webサービスサーバ24は、イベント発火のための条件を管理することになる。
【００４５】
Webサービスサーバ24は、時刻T26にて呼び出された関数を基にイベント登録処理を実行する（IMPLEMENT 52）。この処理内容は、サービス提供者側、すなわちWebサービス装置14が任意に実装するものである。XML Webサービスではこの処理に関して規定しない。Webサービスサーバ24は、時刻T28にて処理結果をWebサービススケルトン26に返す（RESPONSE 54)。Webサービススケルトン26は、時刻T30で処理結果（RESPONSE 54）に含まれる情報をSOAPメッセージに変換してWebアクセス応答とするメッセージをWebサーバ28に返す（MESSAGE 56）。
【００４６】
さらに、Webサーバ28は、受信したSOAPメッセージを本文とするHTTP応答信号（HTTP RES. 58）を生成し、時刻T32にWebサービススタブ20に供給する。Webサービススタブ20は、供給されるHTTP応答信号に含まれるSOAPメッセージを解釈して、時刻T34にてSOAPメッセージの内の応答情報をWebサービスクライアント18に返して、イベント登録処理を終了する（RESPONSE 60）。
【００４７】
このように動作させることで、片方向だけのアクセスが可能なネットワーク環境であっても、SIPプロトコルでの要求-応答をイベント配送のトリガとして利用してクライアント端末装置12とWebサービス装置14との間におけるイベントの通知をリアルタイムに行うことができる。また、HTTPプロトコルおよびSIPプロトコルがWebサービススタブ20およびWebサービススケルトン26で制御されることから、クライアントおよびサーバ側のアプリケーションは制御を意識することなく、既存のアプリケーションをそのまま利用することができる。
【００４８】
次にWebクライアントサーバシステム10におけるイベント配送処理の手順について図３を参照しながら説明する。このイベント配送処理は、あらかじめ上述したイベント登録処理が行われていることが前提にある。
【００４９】
イベント発火条件に合った事象がWebサービスサーバ24の内部で発生する（EVENT 62）。Webサービスサーバ24は、イベント発火したイベントの受信を登録するクライアントのリストおよび発火した事象に関する情報を指定し、Webサービススケルトン26でイベント配送に用いる関数を呼び出して、時刻T36にて出力する（FUNC_CALL 64)。また、Webサービスサーバ24は、クライアントのリストを指定せずに、クライアント毎にイベント発火を順次通知するようにしてもよい。Webサービススケルトン26は、関数を介して供給されたイベント情報をSOAPメッセージに変換し、変換したSOAPメッセージを受信者情報とともに、時刻T38にてSIPユーザエージェント30に通知する（MESSAGE 66)。
【００５０】
SIPユーザエージェント30は、SIPプロトコル（第２のネットワークプロトコル）を用いて、SIPユーザエージェント22にSIPメッセージを生成して、時刻T40で供給する（SIP MESSAGE 68)。SIPユーザエージェント22は、イベントの受信者であるクライアントが管理している。SIPメッセージ68には、ボディにSOAPメッセージが格納されている。SIPユーザエージェント22は、時刻T42にてSIPメッセージ中のSOAPメッセージをWebサービススタブ20に渡す（MESSAGE 70）。
【００５１】
Webサービススタブ20は、イベント情報として渡されたSOAPメッセージを解釈し、Webサービスクライアント18における適切なクライアントモジュールに対してイベント情報を引数とする関数を呼び出し、関数を介してイベント情報を時刻T44にて提供する（FUNC_CALL 72）。Webサービスクライアント18は、時刻T46にて関数によるイベント呼出しに対応して内部的にイベント処理を行う（IMPLEMENT 74)。
【００５２】
時刻T48にてWebサービスクライアント18は、イベント処理の結果を関数呼出しの戻り値としてWebサービススタブ20に返す（RESPONSE 76)。Webサービススタブ20は、供給されたイベント処理結果をSOAPメッセージに変換する。Webサービススタブ20は、さらにSOAPメッセージをHTTPのボディに格納したHTTP要求信号を生成し、時刻T50にてWebサーバ28に発信する（HTTP REQ. 78)。
【００５３】
Webサーバ28は、通常行う処理と同様に、HTTP要求信号に含むSOAPメッセージ内のURL情報からHTTP要求信号（メッセージ）の配送先を検索し、時刻T52にてHTTP要求を適切なWebサービススケルトン26に配送する（MESSAGE 80)。Webサービススケルトン26は、供給されたHTTP要求信号中のSOAPメッセージを解析し、時刻T54にて解析結果をWebサービスサーバ24から呼び出した関数呼出しの戻り値として返す（RESPONSE 82)。時刻T56にWebサービスサーバ24は、関数呼出しの戻り値（RESPONSE 82)を受信し、イベント配送処理が完了する。
【００５４】
ところで、クライアント端末装置12とWebサービス装置14との間におけるHTTPトランザクションは、HTTP要求を送信しただけの状況にあり、クライアント端末装置12はまだHTTP応答を受けていない。HTTPトランザクション（要求-応答）を満足させるため、Webサービススケルトン26は、HTTP応答信号を生成し、時刻T58にWebサーバ28へと出力する（HTTP RES. 84)。HTTP応答信号は、ボディに何等かの情報が格納されている。また、何等かの情報は、空でもよい。
【００５５】
Webサーバ28は、時刻T60にて供給されるHTTP応答信号（HTTP RES. 84)をWebサービススタブ20に出力する。Webサービススタブ20がHTTP応答信号（HTTP RES. 86)を時刻T62にて受信して、HTTPトランザクションも完了する。時刻T62でイベント配送に関する処理を終了する。このような手順でリアルタイム性を保ってWebクライアントサーバシステム10におけるイベント配信を行うことができる。
【００５６】
次に上述した動作の例における変形例について図４を参照しながら説明する。本実施例は、通知すべきイベント情報の情報量が多く、SIPメッセージのボディとしての格納が不適当な場合の対応シーケンスである。したがって、本実施例は、この対応シーケンスに注目して説明し、共通するシーケンスには図３で用いた参照符号を使用する。イベント条件を満たす事象（EVENT 62)が発生し、時刻T36にてWebサービスサーバ24は、イベント配送の関数呼出しを行い、関数を介してイベント情報をWebサービススケルトン26に供給する（FUNC_CALL 64)。
【００５７】
Webサービススケルトン26は、供給されたイベント情報をSOAPメッセージに変換する。ここで、Webサービススケルトン26は、情報量判断機能部36で変換したSOAPメッセージの情報量がSIPメッセージのボディとして許容可能量か否かを判断する。情報量が許容可能量な場合、図３のシーケンスでイベント配送処理を行う。また、情報量が許容可能量を越えていると判断した場合も、SOAPメッセージの受信に用いる識別情報（ID）と受信者に関する情報だけを時刻T40にてSIPユーザエージェント22に通知する。時刻T42にてSIPユーザエージェント22は、Webサービススタブ20に識別情報等を格納するSOAPメッセージ（MESSAGE 70)を渡す。許容量を越えたSOAPメッセージは、Webサービススケルトン26に一時保存される。
【００５８】
Webサービススタブ20は、イベント情報にアクセスするため識別情報（ID）をSOAPメッセージ（MESSAGE 70)から取り出して、SOAPメッセージを含む新たなSOAPメッセージを生成する。Webサービススタブ20は、さらに新たなSOAPメッセージをボディとするHTTP要求信号を作成し、時刻T64にてWebサーバ28に対して発行する（HTTP REQ. 86）。
【００５９】
Webサーバ28は、受信したHTTP要求信号から得られるURLを基に配送先を検索し、時刻T66にて適切なWebサービススケルトン26にHTTP要求信号を配送する（HTTP REQ. 88)。Webサービススケルトン26は、供給されたHTTP要求信号に含まれるSOAPメッセージを取り出して、解析し、識別情報（ID）の格納を認識する。Webサービススケルトン26は、比較部38で時刻T38において作成した識別情報に現在、認識した識別情報が一致するか否かを判断する。一致と判断した場合、識別情報に対応する保存していたSOAPメッセージを時刻T68にてWebサーバ28に返す（MESSAGE 90)。Webサーバ28は、供給されたSOAPメッセージ90をHTTP応答のボディに格納して、時刻T70にてWebサービススタブ20に返す（HTTP RES. 92)。Webサービススタブ20は、SIPメッセージのボディとして許容量を越えたSOAPメッセージを得ることができる。これ以降の手順は、図３に示した時刻T44以降の手順に同じで、処理する時刻が異なるだけである。すなわち、時刻T44〜T62は、それぞれ、図４における時刻T72〜T90に対応している。
【００６０】
このように動作させることにより、高速、軽量のシグナリングを行うSIPプロトコルのようなプロトコルでは、ボディに非常に少量のメッセージしか添付できないが、一旦、SIPプロトコルでクライアント側の受信者に情報（識別情報）を提供し、HTTPプロトコルで提供した情報を送って識別情報の確認に応じて保存していた許容量を超えたSOAPメッセージをHTTP応答のボディに格納して返すことにより、それぞれの有利な機能を有効に発揮させて、リアルタイムにイベントを通知することができる。
【００６１】
なお、本発明の実施例は、イベント配信に限定して説明したが、この実施例に限定されるものでなく、まったく同じ構造、シーケンスでサーバ側からクライアント側が提供するサービス（本実施例と逆の配信）を呼び出して利用できることは言うまでもない。
【００６２】
以上のように構成することにより、クライアント端末装置12とWebサービス装置14で構築されているクライアント-サーバのシステムにおいて、HTTPプロトコル（第１のネットワークプロトコル）により通信を行うとともに、SIPユーザエージェント22をWebサービススタブ20接続し、SIPユーザエージェント30をWebサービススケルトン26に接続して、得られる情報をSIPプロトコル（第２のネットワークプロトコル）によりクライアント端末装置12とWebサービス装置14との間で双方向通信させて、これまでの片方向の通信システムを用いて、サーバ環境の大幅な変更を行うことなく、要求に応じた通信だけを行って、メッセージ通信の大量発生を防止し、SIPプロトコルによる通信をトリガとして利用してリアルタイム性も保つことができることにより、RPCにおいて有効なWebサービス技術を提供することができる。
【００６３】
第１のネットワークプロトコルに片方向通信のHTTP（Hyper Text Transfer Protocol)を用い、第２のネットワークプロトコルに、双方向通信のSIP（Session Initiation Protocol)を用いて、両者のプロトコルが有する欠点を相互に補うように用いることにより、システムの大幅な構築変更を行うことなく、リアルタイム性を有するWebサービスシステムを提供することができる。
【００６４】
SIPユーザエージェント30は、事象の発生を満足する条件に応じて生成される情報をクライアント端末装置12のSIPユーザエージェント22に供給し、SIPユーザエージェン22は、Webサービススタブ20に生成した情報を供給し、クライアント端末装置12からの配信応答は、HTTPプロトコルを利用してWebサービススタブ20とWebサーバ28との間により行うことにより、リアルタイムにWebサービスサーバ24で発生したイベントを配送することができる。
【００６５】
SIPユーザエージェント30は、Webサービスサーバ24にて生じた事象の発生条件の満足にともなって生じる情報の発生を受けて、Webサービスサーバ24から配送する情報量がSIPプロトコルにおいて転送可能な情報量以上あるとの判断に応じて発生条件にともなって得られる情報だけをクライアント端末装置12のSIPユーザエージェント22にトリガとして通知し、Webサービスサーバ24の配送する情報をWebサービススケルトン26に保存し、SIPユーザエージェント22は、Webサービススタブ20に供給された情報を出力し、Webサービススタブ20は、Webサーバ28とHTTPプロトコルで供給された情報を通信し、Webサーバ28は、この供給された情報に合うWebサービススケルトン26に保存された情報を読み出してWebサービススタブ20と通信することにより、SIPプロトコルが転送可能な情報量が少なくても、Webサービススタブ20からのHTTP要求信号に対するHTTP応答信号に保存した情報をメッセージ情報に変換してWebサーバ28に送り、配送することができる。配送処理の結果を示す値をHTTP要求信号でWebサービス装置14に送り、要求-応答のHTTPトランジェントに対応したHTTP応答信号をWebサービス装置14からクライアント端末装置12に返して情報（イベント）の配送を完了させることができる。
【００６６】
また、本発明のWebサービスシステムのイベント通知方法によれば、情報の登録に用いるプログラムを要求し、SIPプロトコルで動作させるクライアント端末装置12にてWebサービス装置14からの情報を着信する際に用いる着信情報が何かを問い合せて、この問い合せた着信情報を取得してトリガにするとともに、登録されたものか判別して管理を可能にし、この着信情報をHTTPプロトコルで規定されたメッセージ情報に格納した要求信号としてクライアント端末装置12からWebサービス装置14に転送し、Webサービス装置14にて転送先の検索および解釈をメッセージ情報に施し、このWebサービスの配送で用いる情報を格納して、Webサービス装置14にてクライアント端末装置12での着信情報および事象の発生条件を管理することができることから、リアルタイムな情報の通知を可能にする。
【００６７】
とくに、この方法は、上述した処理（第７の工程）の後に、Webサービス装置12内にて事象の発生条件に合った、新たな事象の発生を受けて、この事象の情報およびこの情報の利用者情報を含む関連情報を指定して、この関連情報の配送に用いるプログラムを準備し、この準備により得られた事象の情報をメッセージ情報に変換し、このメッセージ情報をSIPプロトコルでクライアント端末装置12に供給し、クライアント端末装置12にてこの供給されたメッセージ情報を解釈し、この解釈した事象の情報に応じた処理を内部的に実行し、この処理結果を示す値をメッセージ情報に変換し、HTTPプロトコルにおける要求信号としてこの変換したメッセージ情報をWebサービス装置14に発信し、受信したメッセージ情報を解析し、処理結果を示す値を受け、この後、要求信号に対する応答信号をクライアント端末装置12に返すことにより、リアルタイム性を保ってWebサービスをクライアント端末装置12に提供することができる。
【００６８】
さらに、SIPプロトコルで転送可能な情報量が少ないことから、得られた事象の情報をメッセージ情報に変換し、このメッセージ情報をSIPプロトコルでクライアント端末装置12に供給する際において（第９の工程）、生成したメッセージ情報がSIPプロトコルにおける転送可能な許容量の範囲にあるか否かを判断し、この許容量の範囲を越える場合、関連情報のうち、このメッセージ情報の受信に用いる識別情報および利用者情報をSIPプロトコルによりクライアント端末装置12に通知し、この許容量の範囲を越えたメッセージ情報を保存し、（第10の工程の前に、）このクライアント端末装置12では受信したメッセージ情報から識別情報を取り出し、この識別情報を含むメッセージ情報を新たに生成し、HTTPプロトコルの要求信号としてWebサービス装置14に発行し、Webサービス装置14で配送先を検索し、供給されたメッセージ情報を解釈し、識別情報の格納を認識し、この識別情報が先に作成した識別情報に該当するか否かを判断し、該当する場合にこの識別情報に対応するメッセージ情報をクライアント端末装置12にHTTPプロトコルの応答信号として返して、応答信号のメッセージ情報を解釈する処理（第10の工程）以降を行うことにより、大量のWebサービス情報が要求されても、リアルタイム性を保ちながら、情報を配送することができる。
【００６９】
【発明の効果】
このように本発明のWebサービスシステムによれば、クライアント端末装置とWebサービス装置で構築されているクライアント-サーバのシステムにおいて、第１のネットワークプロトコルにより通信を行うとともに、第２の通信機能ブロックを第１の通信機能ブロックに接続し、ユーザ通信機能ブロックをサービス実行機能ブロックに接続して、得られる情報を第２のネットワークプロトコルによりクライアント端末装置とWebサービス装置との間で双方向通信させて、片方向の通信システムを用いて、サーバ環境の大幅な変更を行うことなく、要求に応じた通信だけを行って、メッセージ通信の大量発生を防止し、第２のネットワークプロトコルによる通信をトリガとして利用してリアルタイム性も保つことができることにより、RPCにおいて有効なWebサービス技術を提供することができる。
【００７０】
また、本発明のWebサービスシステムのイベント通知方法によれば、情報の登録に用いるプログラムを要求し、第２のネットワークプロトコルで動作させるクライアント端末装置にてWebサービス装置からの情報を着信する際に用いる着信情報が何かを問い合せて、この問い合せた着信情報を取得してトリガにするとともに、登録されたものか判別して管理を可能にし、この着信情報を第１のネットワークプロトコルで規定されたメッセージ情報に格納した要求信号としてクライアント端末装置からWebサービス装置に転送し、Webサービス装置にて転送先の検索および解釈をメッセージ情報に施し、このWebサービスの配送で用いる情報を格納して、Webサービス装置にてクライアント端末装置での着信情報および事象の発生条件を管理することができることから、リアルタイムな情報の通知を可能にする。
【図面の簡単な説明】
【図１】本発明のWebサービスシステムを適用したWebクライアントサーバシステムの概略的な構成を示すブロック図である。
【図２】図１のWebクライアントサーバシステムでイベント登録する手順を説明するシーケンスチャートである。
【図３】図２のイベント登録後に生じたイベント発火にともなうイベント配送処理の手順を説明するシーケンシャルチャートである。
【図４】図３のイベント配送処理における変形例を説明するシーケンシャルチャートである。
【符号の説明】
10 Webクライアントサーバシステム
12 クライアント端末装置
14 Webサービス装置
16 ネットワーク
18 Webサービスクライアント
20 Webサービススタブ
22, 30 SIPユーザエージェント
24 Webサービスサーバ
26 Webサービススケルトン
28 Webサーバ

Claims (7)

1. 提供される機能を利用するクライアントプログラムを有する情報処理手段および該クライアントがWebサービスの利用要求に対応するメッセージ情報に変換し、前記Webサービスを提供するサーバ側と前記メッセージ情報を第１のネットワークプロトコルにより通信する第１の通信機能ブロックを有するクライアント端末装置と、
   第１の通信機能ブロックと第１のネットワークプロトコルで通信するWebサーバ、該Webサーバを介して供給されるメッセージ情報に対する逆変換を行って前記利用要求の要求情報を復元し、該復元された要求情報に対応するプログラムを呼び出して実行処理を行うサービス実行機能ブロックおよび前記Webサービスが提供する機能をプログラム化して実装する機能提供手段を有するWebサービス装置とを含むWebサービスシステムにおいて、
   前記クライアント端末装置は、第１の通信機能ブロックに接続して、得られる情報を第２のネットワークプロトコルにより前記Webサービス装置と双方向通信する第２の通信機能ブロックを含み、
   前記Webサービス装置は、前記サービス実行機能ブロックに接続して、得られる情報を第２のネットワークプロトコルにより第２の通信機能ブロックと双方向通信するユーザ通信機能ブロックを含むことを特徴とするWebサービスシステム。
2. 請求項１に記載のシステムにおいて、第１のネットワークプロトコルは、HTTP（Hyper Text Transfer Protocol)であり、第２のネットワークプロトコルは、SIP（Session Initiation Protocol)であることを特徴とするWebサービスシステム。
3. 請求項１または２に記載のシステムにおいて、前記ユーザ通信機能ブロックは、事象の発生を満足する条件に応じて生成される情報を前記クライアント端末装置の第２の通信機能ブロックに供給し、第２の通信機能ブロックは、第１の通信機能ブロックに生成した情報を供給し、前記クライアント端末装置からの配信応答は、第１のネットワークプロトコルを利用して前記第１の通信機能ブロックと前記Webサーバとの間により行うことを特徴とするWebサービスシステム。
4. 請求項１、２または３に記載のシステムにおいて、前記ユーザ通信機能ブロックは、前記機能提供手段にて生じた前記事象の発生条件の満足にともなって生じる情報の発生を受けて、該機能提供手段から配送する情報量が第２のネットワークプロトコルにおいて転送可能な情報量以上あるとの判断に応じて前記発生条件にともなって得られる情報だけをクライアント端末装置の第２の通信機能ブロックに通知し、該機能提供手段の配送する情報を前記サービス実行機能ブロックに保存し、
   第２の通信機能ブロックは、第１の通信機能ブロックに供給された情報を出力し、
   第１の通信機能ブロックは、前記Webサーバと第１のネットワークプロトコルで供給された情報を通信し、
   前記Webサーバは、該供給された情報に合う前記サービス実行機能ブロックに保存された情報を読み出して第１の通信機能ブロックと通信することを特徴とするWebサービスシステム。
5. 提供される機能を利用するクライアント端末装置とWebサービスを提供するWebサービス装置とで構築したネットワーク間を第１のネットワークプロトコルに応じて通信するWebサービスシステムの情報通知方法において、該方法は、
   該Webサービスにおける事象の発生条件を満たす状況に応じた情報の登録に用いるプログラムを要求する第１の工程と、
   前記クライアント端末装置と前記Webサービス装置との間を第２のネットワークプロトコルで動作させるクライアント端末装置にて前記Webサービス装置からの情報を着信する際に用いる着信情報が何かを問い合せて、該問い合せた着信情報を取得する第２の工程と、
   該着信情報を第１のネットワークプロトコルで規定されたメッセージ情報に格納した要求信号として前記クライアント端末装置から前記Webサービス装置に転送する第３の工程と、
   前記Webサービス装置にて受信したメッセージ情報から転送先の検索および該メッセージ情報を解釈し、該メッセージ情報の中から該Webサービスの配送で用いる情報を格納する第４の工程と、
   該格納した情報が取り出された残りの情報に対して登録するプログラムを呼び出して、実行する第５の工程と、
   該実行結果を前記メッセージ情報の形式に変換し、第１のネットワークプロトコルにおける応答信号として前記クライアント端末装置に返す第６の工程と、
   前記メッセージ情報の内容を解釈する第７の工程とを含むことを特徴とするWebサービスシステムの情報通知方法。
6. 請求項５に記載の方法において、該方法は、第７の工程の後に、前記Webサービス装置内にて前記事象の発生条件に合った、新たな事象の発生を受けて、該事象の情報および該情報の利用者情報を含む関連情報を指定して、該関連情報の配送に用いるプログラムを準備する第８の工程と、
   該準備により得られた事象の情報を前記メッセージ情報に変換し、該メッセージ情報を第２のネットワークプロトコルで前記クライアント端末装置に供給する第９の工程と、
   該クライアント端末装置にて該供給されたメッセージ情報を解釈し、該解釈した事象の情報に応じた処理を内部的に実行する第10の工程と、
   該処理結果を示す値を前記メッセージ情報に変換し、第１のネットワークプロトコルにおける要求信号として該変換したメッセージ情報を前記Webサービス装置に発信する第11の工程と、
   受信したメッセージ情報を解析し、前記処理結果を示す値を受ける第12の工程と、
   この後、前記要求信号に対する応答信号をクライアント端末装置に返す第13の工程とを含むことを特徴とするWebサービスシステムの情報通知方法。
7. 請求項５または６に記載の方法において、第９の工程は、生成したメッセージ情報が第２のネットワークプロトコルにおける転送可能な許容量の範囲にあるか否かを判断し、該許容量の範囲を越える場合、前記関連情報のうち、該メッセージ情報の受信に用いる識別情報および前記利用者情報を第２のネットワークプロトコルにより前記クライアント端末装置に通知し、該許容量の範囲を越えたメッセージ情報を保存し、
   第10の工程の前に、該クライアント端末装置では受信したメッセージ情報から前記識別情報を取り出し、該識別情報を含むメッセージ情報を新たに生成し、第１のネットワークプロトコルの要求信号として前記Webサービス装置に発行する第14の工程と、
   該Webサービス装置で配送先を検索し、供給されたメッセージ情報を解釈し、前記識別情報の格納を認識し、該識別情報が先に作成した識別情報に該当するか否かを判断し、該当する場合に該識別情報に対応する前記メッセージ情報を前記クライアント端末装置に第１のネットワークプロトコルの応答信号として返す第15の工程とを含み、以後、第10の工程を行うことを特徴とするWebサービスシステムの情報通知方法。

Images