(57)【要約】【課題】片方向通信のネットワーク環境でもリアルタイムにイベント通知することができるＷｅｂサービスシステムおよびその情報通知方法を提供。【解決手段】Ｗｅｂクライアントサーバシステム１０は、クライアント端末装置１２とＷｅｂサービス装置１４で構築されているシステムであり、クライアント端末装置１２とＷｅｂサービス装置１４との間をＨＴＴＰプロトコルにより片方向通信を行うとともに、ＳＩＰユーザエージェント２２をＷｅｂサービススタブ２０接続し、ＳＩＰユーザエージェント３０をＷｅｂサービススケルトン２６に接続して、得られる情報をＳＩＰプロトコルでクライアント端末装置１２とＷｅｂサービス装置１４との間で双方向通信させてトリガとして利用して、リアルタイム性を保っている。【選択図】        図１
2004356967.tif 000002
【特許請求の範囲】
【請求項１】
提供される機能を利用するクライアントプログラムを有する情報処理手段および該クライアントがＷｅｂサービスの利用要求に対応するメッセージ情報に変換し、前記Ｗｅｂサービスを提供するサーバ側と前記メッセージ情報を第１のネットワークプロトコルにより通信する第１の通信機能ブロックを有するクライアント端末装置と、
第１の通信機能ブロックと第１のネットワークプロトコルで通信するＷｅｂサーバ、該Ｗｅｂサーバを介して供給されるメッセージ情報に対する逆変換を行って前記利用要求の要求情報を復元し、該復元された要求情報に対応するプログラムを呼び出して実行処理を行うサービス実行機能ブロックおよび前記Ｗｅｂサービスが提供する機能をプログラム化して実装する機能提供手段を有するＷｅｂサービス装置とを含むＷｅｂサービスシステムにおいて、
前記クライアント端末装置は、第１の通信機能ブロックに接続して、得られる情報を第２のネットワークプロトコルにより前記Ｗｅｂサービス装置と双方向通信する第２の通信機能ブロックを含み、
前記Ｗｅｂサービス装置は、前記サービス実行機能ブロックに接続して、得られる情報を第２のネットワークプロトコルにより第２の通信機能ブロックと双方向通信するユーザ通信機能ブロックを含むことを特徴とするＷｅｂサービスシステム。
【請求項２】
請求項１に記載のシステムにおいて、第１のネットワークプロトコルは、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）であり、第２のネットワークプロトコルは、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）であることを特徴とするＷｅｂサービスシステム。
【請求項３】
請求項１または２に記載のシステムにおいて、前記ユーザ通信機能ブロックは、事象の発生を満足する条件に応じて生成される情報を前記クライアント端末装置の第２の通信機能ブロックに供給し、第２の通信機能ブロックは、第１の通信機能ブロックに生成した情報を供給し、前記クライアント端末装置からの配信応答は、第１のネットワークプロトコルを利用して前記第１の通信機能ブロックと前記Ｗｅｂサーバとの間により行うことを特徴とするＷｅｂサービスシステム。
【請求項４】
請求項１、２または３に記載のシステムにおいて、前記ユーザ通信機能ブロックは、前記機能提供手段にて生じた前記事象の発生条件の満足にともなって生じる情報の発生を受けて、該機能提供手段から配送する情報量が第２のネットワークプロトコルにおいて転送可能な情報量以上あるとの判断に応じて前記発生条件にともなって得られる情報だけをクライアント端末装置の第２の通信機能ブロックに通知し、該機能提供手段の配送する情報を前記サービス実行機能ブロックに保存し、
第２の通信機能ブロックは、第１の通信機能ブロックに供給された情報を出力し、
第１の通信機能ブロックは、前記Ｗｅｂサーバと第１のネットワークプロトコルで供給された情報を通信し、
前記Ｗｅｂサーバは、該供給された情報に合う前記サービス実行機能ブロックに保存された情報を読み出して第１の通信機能ブロックと通信することを特徴とするＷｅｂサービスシステム。
【請求項５】
提供される機能を利用するクライアント端末装置とＷｅｂサービスを提供するＷｅｂサービス装置とで構築したネットワーク間を第１のネットワークプロトコルに応じて通信するＷｅｂサービスシステムの情報通知方法において、該方法は、
該Ｗｅｂサービスにおける事象の発生条件を満たす状況に応じた情報の登録に用いるプログラムを要求する第１の工程と、
前記クライアント端末装置と前記Ｗｅｂサービス装置との間を第２のネットワークプロトコルで動作させるクライアント端末装置にて前記Ｗｅｂサービス装置からの情報を着信する際に用いる着信情報が何かを問い合せて、該問い合せた着信情報を取得する第２の工程と、
該着信情報を第１のネットワークプロトコルで規定されたメッセージ情報に格納した要求信号として前記クライアント端末装置から前記Ｗｅｂサービス装置に転送する第３の工程と、
前記Ｗｅｂサービス装置にて受信したメッセージ情報から転送先の検索および該メッセージ情報を解釈し、該メッセージ情報の中から該Ｗｅｂサービスの配送で用いる情報を格納する第４の工程と、
該格納した情報が取り出された残りの情報に対して登録するプログラムを呼び出して、実行する第５の工程と、
該実行結果を前記メッセージ情報の形式に変換し、第１のネットワークプロトコルにおける応答信号として前記クライアント端末装置に返す第６の工程と、
前記メッセージ情報の内容を解釈する第７の工程とを含むことを特徴とするＷｅｂサービスシステムの情報通知方法。
【請求項６】
請求項５に記載の方法において、該方法は、第７の工程の後に、前記Ｗｅｂサービス装置内にて前記事象の発生条件に合った、新たな事象の発生を受けて、該事象の情報および該情報の利用者情報を含む関連情報を指定して、該関連情報の配送に用いるプログラムを準備する第８の工程と、
該準備により得られた事象の情報を前記メッセージ情報に変換し、該メッセージ情報を第２のネットワークプロトコルで前記クライアント端末装置に供給する第９の工程と、
該クライアント端末装置にて該供給されたメッセージ情報を解釈し、該解釈した事象の情報に応じた処理を内部的に実行する第１０の工程と、
該処理結果を示す値を前記メッセージ情報に変換し、第１のネットワークプロトコルにおける要求信号として該変換したメッセージ情報を前記Ｗｅｂサービス装置に発信する第１１の工程と、
受信したメッセージ情報を解析し、前記処理結果を示す値を受ける第１２の工程と、
この後、前記要求信号に対する応答信号をクライアント端末装置に返す第１３の工程とを含むことを特徴とするＷｅｂサービスシステムの情報通知方法。
【請求項７】
請求項５または６に記載の方法において、第９の工程は、生成したメッセージ情報が第２のネットワークプロトコルにおける転送可能な許容量の範囲にあるか否かを判断し、該許容量の範囲を越える場合、前記関連情報のうち、該メッセージ情報の受信に用いる識別情報および前記利用者情報を第２のネットワークプロトコルにより前記クライアント端末装置に通知し、該許容量の範囲を越えたメッセージ情報を保存し、
第１０の工程の前に、該クライアント端末装置では受信したメッセージ情報から前記識別情報を取り出し、該識別情報を含むメッセージ情報を新たに生成し、第１のネットワークプロトコルの要求信号として前記Ｗｅｂサービス装置に発行する第１４の工程と、
該Ｗｅｂサービス装置で配送先を検索し、供給されたメッセージ情報を解釈し、前記識別情報の格納を認識し、該識別情報が先に作成した識別情報に該当するか否かを判断し、該当する場合に該識別情報に対応する前記メッセージ情報を前記クライアント端末装置に第１のネットワークプロトコルの応答信号として返す第１５の工程とを含み、以後、第１０の工程を行うことを特徴とするＷｅｂサービスシステムの情報通知方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、Ｗｅｂサービスシステムに関するものであり、とくに、ＷｅｂサービスのＲＰＣ（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ）において片方向だけでＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）通信するネットワーク環境等のＷｅｂサービスシステムに適用して好適なものであり、また、本発明は、Ｗｅｂサービスシステムの情報通知方法に関するものであり、Ｗｅｂサービスシステムにてそれぞれ互いにファイアウォールが形成され、片方向通信でありながら、リアルタイム性を保つ通信シーケンス等に適用して好適なものである。
【０００２】
【従来の技術】
現在、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）とＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を応用したＲＰＣ（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ）技術を利用したシステム構築が行われている。このＲＰＣ技術をＸＭＬ  Ｗｅｂサービスという。このサービスでは、非特許文献１〜５に挙げる技術を使用している。ＸＭＬ  Ｗｅｂサービスにおいてクライアント側にはＷｅｂサービスクライアントおよびＷｅｂサービススタブが設けられている。また、サーバ側にはＷｅｂサービスサーバ、ＷｅｂサービススケルトンおよびＷｅｂサーバが設けられている。クライアント側のＷｅｂサービススタブとＷｅｂサーバのゲート側にはファイアウォールがそれぞれ形成されている。ＷｅｂサービススタブとＷｅｂサーバは、ＨＴＴＰに基づいて通信を行っている。
【０００３】
Ｗｅｂサービスクライアントは、Ｗｅｂサービスサーバから提供されるプログラムをクライアントプログラムとして利用して動作する機能を有している。Ｗｅｂサービスクライアントは、通常ＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）のレジストリにアクセスして利用するサービスのＷＳＤＬ（Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）を獲得する機能と、獲得したＷＳＤＬからＷｅｂサービススタブを生成する機能とを有している。
【０００４】
Ｗｅｂサービススタブは、Ｗｅｂサービスクライアントが使用するプログラムモジュールである。Ｗｅｂサービススタブは、Ｗｅｂサービスを利用する関数呼出しまたはメソッド呼出しをＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）メッセージに変換する機能を有し、ＳＯＡＰメッセージをＨＴＴＰ等に応じて動作する通信路を利用してサーバ側に送信する機能も持っている。クライアント側では、内部から外部へのアクセスだけを可能とする場合が多い。
【０００５】
一方、Ｗｅｂサーバは、クライアントからのＨＴＴＰ要求（リクエスト）を受信し、受信したＵＲＬ（Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｅｒ）情報からＷｅｂサーバ上で稼動するＷｅｂサービスサーバを検索し、ＷｅｂサービススケルトンにＨＴＴＰ要求を配送する。
【０００６】
Ｗｅｂサービススケルトンは、Ｗｅｂサービスサーバが構築する環境に応じて生成されるサーバモジュールである。Ｗｅｂサービススケルトンは、Ｗｅｂサーバから供給されるＨＴＴＰ要求内のＳＯＡＰメッセージを解釈し、ＳＯＡＰメッセージが指定するＷｅｂサービスサーバ上の関数またはメソッドを呼び出す機能を有している。Ｗｅｂサービスサーバは、Ｗｅｂサービスが提供する機能を実装したサーバである。Ｗｅｂサーバ以外のサーバ環境は、クライアント側からのアクセスが可能なように設定されている。
【０００７】
ＸＭＬ  Ｗｅｂサービスの構成においてＲＰＣを実行する手順を説明する。最初に、ＷｅｂサービスクライアントはＷｅｂサービススタブに対してＷｅｂサービスで利用する関数呼出しを発行する。Ｗｅｂサービススタブは、この発行を受けて、関数呼出しの内容をＳＯＡＰメッセージに格納し、このＳＯＡＰメッセージを本体に格納したＨＴＴＰ要求をＷｅｂサーバに転送する。
【０００８】
Ｗｅｂサーバは、ＨＴＴＰ要求に含まれるＵＲＬ情報からＳＯＡＰメッセージの転送先を検索する。Ｗｅｂサーバは、検索結果をＳＯＡＰメッセージにしてクライアント側のＷｅｂサービススケルトンに転送する。Ｗｅｂサービススケルトンは、転送されたＳＯＡＰメッセージを解釈し、Ｗｅｂサービスサーバに解釈結果を供給する。
【０００９】
Ｗｅｂサービスサーバは、解釈結果を基に対応して提供する関数を呼び出す。この関数は、最初に発行した関数呼出しと同等のものである。Ｗｅｂサービスサーバは、呼び出した関数を処理する。処理内容は、サービス提供者（サーバ）側が任意に実装するもので、ＸＭＬ  Ｗｅｂサービスにおけるこの処理に関する規定はない。Ｗｅｂサービスサーバは、処理結果をＷｅｂサービススケルトンに返す。
【００１０】
Ｗｅｂサービススケルトンは、処理結果をＳＯＡＰメッセージに変換し、Ｗｅｂアクセスの応答としてＷｅｂサーバに返す。Ｗｅｂサーバは、受信したＳＯＡＰメッセージを本文とするＨＴＴＰ応答（レスポンス）をサーバ側からクライアント側のＷｅｂサービススタブに返される。
【００１１】
Ｗｅｂサービススタブは、供給されたＳＯＡＰメッセージを解釈し、ＳＯＡＰメッセージ内の応答情報をＷｅｂサービスクライアントに返して一連の処理を終える。
【００１２】
ところで、近年、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）電話等のようにＩＰネットワーク上で音声等のリアルタイムコミュニケーションを実現する技術やプロトコルが開発されている。ＩＥＴＦ（ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）が規定するセッション初期化プロトコル（ＳＩＰ：  Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）は、このリアルタイムコミュニケーションを行うためのシグナリングを目的とするプロトコルである。このプロトコルは、今後広く利用されることが予想されている。
【００１３】
音声等のリアルタイムコミュニケーションには、Ｗｅｂサーバ等の単純なクライアント・サーバによるモデルと異なり、双方向に通信できることが要求される。すなわち、どちらの端末装置からでも通信相手側を呼び出すことが要求される。しかしながら、前述したように、それぞれクライアント側やＷｅｂサーバ側には、現在、ファイアウォールが設置され、片方向の通信しかできない設定になっているものが多い。このような環境では双方向通信がＨＴＴＰと同様に行えない。
【００１４】
そこで、これを考慮してＳＩＰの標準化が進められている。これにより、たとえば、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）に対応したデバイスは、要求に応じてＳＩＰメッセージを受信するポートを開くことができ、双方向の通信を実現している（非特許文献５を参照）。
【００１５】
【非特許文献１】
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００２／ｗｓ／，  ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ），  ＷＳＤＬ：  Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅに関する
【非特許文献２】
ｈｔｔｐ：／／ｗｗｗ．ｕｄｄｉ．ｏｒｇ／，  ＵＤＤＩ：  Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌに関する
【非特許文献３】
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＸＭＬ／，  ＸＭＬ：  ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅに関する
【非特許文献４】
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／，  ＨＴＴＰ：  Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌに関し、とくに、ＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ）２６１６やＲＦＣ２６１７等の規格がある
【非特許文献５】
ｈｔｔｐ：／／ｗｗｗ．ｕｐｎｐ．ｏｒｇ／，  ＵＰｎＰ：  Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙに関する。
【００１６】
【発明が解決しようとする課題】
ところで、このようにＨＴＴＰプロトコルを転送層に用いたＸＭＬ  Ｗｅｂサービスでは、ＷｅｂサービスサーバがＷｅｂサービスクライアントにイベントを通知する場合、またはＷｅｂサーバ側からクライアント側に対して明示的にＲＰＣを起動する場合のようにＳＯＡＰメッセージを逆方向に転送するときに制約が存在する。
【００１７】
第１の制約は、通常のネットワーク構成においてクライアント側がＨＴＴＰ要求を受信可能なファイアウォールの設定にないことである。ＨＴＴＰは片方向だけの通信である。第２の制約は、ＳＯＡＰプロトコル自体が本来転送プロトコルに依存しない定義であることから、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）等を双方向通信に利用することも検討されているが、リアルタイム性に欠ける点でイベント通知に適さない。
【００１８】
第３の制約は、双方通信可能なネットワークを構築し、単にＸＭＬ  Ｗｅｂサービス環境を対向して設置しても、これらのサービス環境が互いに独立したものであることから、関連した動作を行わせる上で大幅なサーバ環境の変更が要求される。ここで、一つのＸＭＬ  Ｗｅｂサービス環境でイベント通知を行う場合、定期的にクライアントがサーバ側にポーリングしてイベントメッセージを獲得することができる。しかしながら、この方法は、第４の制約として、不要なメッセージ通信が大量に発生する。これを回避するためポーリング間隔の時間を長くしてメッセージ通信量を減らすと、イベント通知間隔も長くなることから、この方法ではリアルタイム性が失われてしまう。
【００１９】
ＳＩＰのようなリアルタイムコミュニケーションを行うシグナリングプロトコルは、双方向通信の技術が開発されてきているが、ＳＯＡＰの転送プロトコルとして利用する場合に問題がある。高速・軽量のシグナリングプロトコル、たとえばＳＩＰにおけるメッセージは、ボディに非常に少量の情報しか添付できないという特徴がある。一方、ＳＯＡＰメッセージは、メッセージサイズが可変で、上限が定められていない。このような両者の関係を考慮すると、このシグナリングプロトコルにはＳＯＡＰメッセージをボディとして利用できない。
【００２０】
本発明はこのような従来技術の欠点を解消し、片方向通信のネットワーク環境でもリアルタイムにイベント通知することができるＷｅｂサービスシステムおよびその情報通知方法を提供することを目的とする。
【００２１】
【課題を解決するための手段】
本発明は上述の課題を解決するために、提供される機能を利用するクライアントプログラムを有する情報処理手段およびこのクライアントがＷｅｂサービスの利用要求に対応するメッセージ情報に変換し、Ｗｅｂサービスを提供するサーバ側と前記メッセージ情報を第１のネットワークプロトコルにより通信する第１の通信機能ブロックを有するクライアント端末装置と、第１の通信機能ブロックと第１のネットワークプロトコルで通信するＷｅｂサーバ、このＷｅｂサーバを介して供給されるメッセージ情報に対する逆変換を行って利用要求の要求情報を復元し、この復元された要求情報に対応するプログラムを呼び出して実行処理を行うサービス実行機能ブロックおよびＷｅｂサービスが提供する機能をプログラム化して実装する機能提供手段を有するＷｅｂサービス装置とを含むＷｅｂサービスシステムにおいて、クライアント端末装置は、第１の通信機能ブロックに接続して、得られる情報を第２のネットワークプロトコルによりＷｅｂサービス装置と双方向通信する第２の通信機能ブロックを含み、Ｗｅｂサービス装置は、サービス実行機能ブロックに接続して、得られる情報を第２のネットワークプロトコルにより第２の通信機能ブロックと双方向通信するユーザ通信機能ブロックを含むことを特徴とする。
【００２２】
本発明のＷｅｂサービスシステムは、クライアント端末装置とＷｅｂサービス装置で構築されているクライアント−サーバのシステムにおいて、第１のネットワークプロトコルにより通信を行うとともに、第２の通信機能ブロックを第１の通信機能ブロックに接続し、ユーザ通信機能ブロックをサービス実行機能ブロックに接続して、得られる情報を第２のネットワークプロトコルによりクライアント端末装置とＷｅｂサービス装置との間で双方向通信させることにより、片方向の通信システムを用いて、サーバ環境の大幅な変更を行うことなく、要求に応じた通信だけを行って、メッセージ通信の大量発生を防止し、第２のネットワークプロトコルによる通信をトリガとして利用してリアルタイム性も保つことができる。
【００２３】
また、本発明は上述の課題を解決するために、提供される機能を利用するクライアント端末装置とＷｅｂサービスを提供するＷｅｂサービス装置とで構築したネットワーク間を第１のネットワークプロトコルに応じて通信するＷｅｂサービスシステムの情報通知方法において、この方法は、このＷｅｂサービスにおける事象の発生条件を満たす状況に応じた情報の登録に用いるプログラムを要求する第１の工程と、クライアント端末装置とＷｅｂサービス装置との間を第２のネットワークプロトコルで動作させるクライアント端末装置にてＷｅｂサービス装置からの情報を着信する際に用いる着信情報が何かを問い合せて、この問い合せた着信情報を取得する第２の工程と、この着信情報を第１のネットワークプロトコルで規定されたメッセージ情報に格納した要求信号としてクライアント端末装置からＷｅｂサービス装置に転送する第３の工程と、Ｗｅｂサービス装置にて受信したメッセージ情報から転送先の検索およびこのメッセージ情報を解釈し、このメッセージ情報の中からこのＷｅｂサービスの配送で用いる情報を格納する第４の工程と、この格納した情報が取り出された残りの情報に対して登録するプログラムを呼び出して、実行する第５の工程と、この実行結果をメッセージ情報の形式に変換し、第１のネットワークプロトコルにおける応答信号としてクライアント端末装置に返す第６の工程と、メッセージ情報の内容を解釈する第７の工程とを含むことを特徴とする。
【００２４】
本発明のＷｅｂサービスシステムの情報通知方法は、情報の登録に用いるプログラムを要求し、第２のネットワークプロトコルで動作させるクライアント端末装置にてＷｅｂサービス装置からの情報を着信する際に用いる着信情報が何かを問い合せて、この問い合せた着信情報を取得してトリガにするとともに、登録されたものか判別して管理を可能にし、この着信情報を第１のネットワークプロトコルで規定されたメッセージ情報に格納した要求信号としてクライアント端末装置からＷｅｂサービス装置に転送し、Ｗｅｂサービス装置にて受信したメッセージ情報から転送先の検索およびこのメッセージ情報を解釈し、このメッセージ情報の中からこのＷｅｂサービスの配送で用いる情報を格納して、クライアント端末装置での着信情報および事象の発生条件を管理することができ、この格納した情報が取り出された残りの情報に対して登録するプログラムを呼び出して、実行し、この実行結果をメッセージ情報の形式に変換し、第１のネットワークプロトコルにおける応答信号としてクライアント端末装置に返し、メッセージ情報の内容を解釈することにより、事象の発生条件に応じた着信情報がクライアント端末装置およびＷｅｂサーバ装置でそれぞれ、管理されることから、リアルタイムな情報の通知を可能にする。
【００２５】
【発明の実施の形態】
次に添付図面を参照して本発明によるＷｅｂサービスシステムの一実施例を詳細に説明する。
【００２６】
本実施例は、本発明のＷｅｂサービスシステムをＷｅｂクライアントサーバシステム１０に適用した場合である。本発明と直接関係のない部分について図示および説明を省略する。以下の説明で、信号はその現れる接続線の参照番号で指示する。
【００２７】
Ｗｅｂクライアントサーバシステム１０は、クライアント端末装置１２およびＷｅｂサービス装置１４を含んでいる。クライアント端末装置１２は、便宜上一つだけ図示しているが、Ｗｅｂサービス装置１４にはネットワーク１６を介して複数接続できることは言うまでもない。
【００２８】
クライアント端末装置１２は、Ｗｅｂサービスクライアント１８、Ｗｅｂサービススタブ２０およびＳＩＰユーザエージェント２２を含む。また、Ｗｅｂサービス装置１４は、Ｗｅｂサービスサーバ２４、Ｗｅｂサービススケルトン２６、Ｗｅｂサーバ２８およびＳＩＰユーザエージェント３０を含む。
【００２９】
クライアント端末装置１２におけるＷｅｂサービスクライアント１８およびＷｅｂサービススタブ２０は、従来の技術で説明した機能と同じ機能を有し、互いに接続されている。すなわち、Ｗｅｂサービスクライアント１８は、クライアントプログラムであり、情報処理機能部である。Ｗｅｂサービスクライアント１８は、Ｗｅｂサービス装置１４、とくに、Ｗｅｂサービスサーバ２４が提供する、サービスの利用機能およびイベント情報の受信機能を有している。
【００３０】
Ｗｅｂサービススタブ２０は、Ｗｅｂサービスクライアント１８が使用するプログラムモジュールで、Ｗｅｂサービスのプロキシとして動作する。Ｗｅｂサービススタブ２０は、Ｗｅｂサービスにおいて利用するローカルクラスの関数呼出しまたはメソッド呼出しをＳＯＡＰメッセージに変換する第１の機能、ＳＯＡＰメッセージをハイパーテキスト記述言語の転送用プロトコルＨＴＴＰ（第１のネットワークプロトコル）に基づきＷｅｂサービス装置１４に送信する第２の機能、ＳＩＰユーザエージェント２２からのイベント着信を受信する第３の機能およびＳＩＰユーザエージェント２２で受信したイベントをＷｅｂサービス装置１４に送信する第４の機能を有している。
【００３１】
ここで、ＳＯＡＰについて簡単に説明する。現在、ＳＯＡＰは、ｖｅｒｓｉｏｎ１．２（２００３年１月２４日）で、分散化した分布環境において交換するように構造化された情報を目的とした軽いプロトコルとしてＷ３Ｃ（Ｗｏｒｌｄ−Ｗｉｄｅ−Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）の候補勧告がある。
【００３２】
ＳＩＰユーザエージェント２２は、セッション初期化プロトコル（ＳＩＰ）を用いてＷｅｂサービス装置１４のＳＩＰユーザエージェント３０と相互通信するプログラムモジュールである。ＳＩＰユーザエージェント２２は、Ｗｅｂサービススタブ２０に接続され、イベント情報を授受する機能を有し、ＳＩＰ要求を生成する際にＵＡＣ（Ｕｓｅｒ  Ａｇｅｎｔ  Ｃｌｉｅｎｔ）として動作し、要求を処理して応答を生成する際にＵＡＳ（Ｕｓｅｒ  Ａｇｅｎｔ  Ｓｅｒｖｅｒ）として動作している。また、ＳＩＰユーザエージェント２２は、要求−応答のやりとりを表すトランザクションを実行し、各トランザクションを管理する。
【００３３】
なお、ＳＩＰユーザエージェント２２は、単体のプログラムとしての動作やＷｅｂサービススタブ２０内のモジュールとしての動作のいずれで動作させても構わない。
【００３４】
Ｗｅｂサービスサーバ２４は、Ｗｅｂサービスを提供する機能が実装されたサーバである。Ｗｅｂサービスサーバ２４は、Ｗｅｂサービススケルトン２６と接続されている。Ｗｅｂサービススケルトン２６は、Ｗｅｂサーバ２８から受信したＨＴＴＰ要求内のＳＯＡＰメッセージを解釈して、解釈した結果のＳＯＡＰメッセージが指定するＷｅｂサービスサーバ２４上の関数またはメソッドを適切に呼び出す機能を有している。スケルトンは、タイクラスとも呼ばれる。Ｗｅｂサービススケルトン２６は、Ｗｅｂサーバ２８だけでなく、ＳＩＰユーザエージェント３０とも接続している。Ｗｅｂサービススケルトン２６は、ＳＩＰユーザエージェント３０を用いてイベントの送受信を行う機能を有している。
【００３５】
Ｗｅｂサーバ２８は、クライアント端末装置１２（クライアント側）からＨＴＴＰ要求を受信し、受信した情報に含まれるＵＲＬ情報に基づいてＷｅｂサーバ上で稼動するＷｅｂサービスサーバを検索し、ＨＴＴＰ要求を適切なサーバモジュール、たとえばＷｅｂサービススケルトン２６に配送する機能を有している。
【００３６】
ＳＩＰユーザエージェント３０は、ＳＩＰユーザエージェント２２と同じ構成で、ＳＩＰを用いてＳＩＰユーザエージェント２２と相互通信するプログラムモジュールである。また、ＳＩＰユーザエージェント３０は、単体動作およびＷｅｂサーバ２８またはＷｅｂサーバスケルトン２６内のモジュールの動作のいずれとしても構わない。上述の動作にかかわらず、ＳＩＰユーザエージェント３０は、Ｗｅｂサービススケルトン２６と接続して、イベント情報の授受を行う機能を有している。
【００３７】
クライアント端末装置１２およびＷｅｂサービス装置１４には、それぞれクライアント環境とサーバ環境を保護するファイアウォール３２，  ３４が設けられている。ファイアウォール３２は、クライアント側からのＨＴＴＰ要求およびＳＩＰプロトコルが受信可能なように設定されている。また、ファイアウォール３４は、ＨＴＴＰプロトコルが内部から外部へのアクセスだけを可能にするように設定されている。ただし、ファイアウォール３４は、ＳＩＰプロトコルに関してたとえば、ＵＰｎＰ等の技術を用いて要求に応じて受信が制御できるように設定されている。
【００３８】
このように構成して、Ｗｅｂクライアントサーバシステム１０は、片方向通信のネットワーク環境でも、ＳＩＰユーザエージェント２２，  ３０の相互通信を利用してリアルタイムにイベント通知ができるようにしている。Ｗｅｂクライアントサーバシステム１０の有利な点についていくつかの動作により説明する。
【００３９】
最初に、Ｗｅｂクライアントサーバシステム１０においてＷｅｂクライアント１８がＷｅｂサービスサーバ２４にイベント登録する場合を説明する（図２を参照）。ここで、イベントを受信するクライアントにはあらかじめＷｅｂサービス装置１４に対して受信するイベントの種別や条件が登録されている。登録処理は、図２に示すように、Ｗｅｂサービスクライアント１８は、時刻Ｔ１０にてＷｅｂサービススタブ２０に対してイベント登録用の関数呼出しを発行する（ＦＵＮＣ＿ＣＡＬＬ  ４０）。この呼出しは、受信するイベントに対する指定が明示的または暗黙的に行われ、この条件をイベント発火条件という。
【００４０】
Ｗｅｂサービススタブ２０は、ＳＩＰユーザエージェント２２にイベントの着信に用いる情報の問合せを行う（ＲＥＱＵＥＳＴ  ４２）。ＳＩＰユーザエージェント２２は、時刻Ｔ１４にて問合せに対する各種情報を返して応答する（ＲＥＳＰＯＮＳＥ  ４４）。ここで、各種情報とは、イベントの着信を待ち受けるポート番号や着信したイベントを判別する識別情報（ＩＤ：  ＩＤｅｎｔｉｆｙ）等である。この要求−応答により、Ｗｅｂサービススタブ２０は、ＳＩＰユーザエージェント２２に着信したイベント情報がＷｅｂサービスクライアント１８内のどのモジュールが登録したものであるかを判別する情報として取得し、管理することができるようになる。
【００４１】
Ｗｅｂサービススタブ２０は、この要求−応答をトリガとしてイベント登録時の引数およびＳＩＰユーザエージェント２２からの応答（ＲＥＳＰＯＮＳＥ）に含まれる情報をＳＯＡＰメッセージに格納し、さらに、ＳＯＡＰメッセージをＨＴＴＰのボディに格納したＨＴＴＰ要求信号を生成する。Ｗｅｂサービススタブ２０は、時刻Ｔ１６において生成したＨＴＴＰ要求信号（ＨＴＴＰ  ＲＥＱ．  ４６）をＷｅｂサーバ２８に転送する。
【００４２】
Ｗｅｂサーバ２８は、受信したＨＴＴＰ要求信号に含まれるＵＲＬからＳＯＡＰメッセージの転送先を検索する。この検索後、時刻Ｔ１８でＷｅｂサーバ２８は、ＳＯＡＰメッセージをＷｅｂサービススケルトン２６に供給する（ＭＥＳＳＡＧＥ  ４８）。
【００４３】
Ｗｅｂサービススケルトン２６は、供給されたＳＯＡＰメッセージを解釈する。Ｗｅｂサービススケルトン２６は、この解釈により得られたイベント配送に要求される情報（ＤＩＳＴ＿ＩＮＦ  ５０）を時刻Ｔ２０にて内部に格納する。この格納は、データベース等を用いた永続的なものに限定されず、メモリ上への一時的な格納でもよい。このような格納は、配送されるイベント情報の重要度等に応じて決められる。Ｗｅｂサービススケルトン２６は、この格納によりイベント発火時、イベント情報を通知するＳＩＰユーザエージェント２２に関する情報を管理することになる。
【００４４】
Ｗｅｂサービススケルトン２６は、時刻Ｔ２４にてイベント配送の情報を取り出した後に残るイベント発火条件に関連する情報をＷｅｂサービスサーバ２４に通知する。この情報は、Ｗｅｂサービスサーバ２４に通知される。通知は、Ｗｅｂサービスサーバ２４が提供する関数をＷｅｂサービススケルトン２６に呼び出して、この関数を介してＷｅｂサービスサーバ２４に返すことで行う（ＦＵＮＣ＿ＣＡＬＬ  ５１）。Ｗｅｂサービスサーバ２４は、イベント発火のための条件を管理することになる。
【００４５】
Ｗｅｂサービスサーバ２４は、時刻Ｔ２６にて呼び出された関数を基にイベント登録処理を実行する（ＩＭＰＬＥＭＥＮＴ  ５２）。この処理内容は、サービス提供者側、すなわちＷｅｂサービス装置１４が任意に実装するものである。ＸＭＬ  Ｗｅｂサービスではこの処理に関して規定しない。Ｗｅｂサービスサーバ２４は、時刻Ｔ２８にて処理結果をＷｅｂサービススケルトン２６に返す（ＲＥＳＰＯＮＳＥ  ５４）。Ｗｅｂサービススケルトン２６は、時刻Ｔ３０で処理結果（ＲＥＳＰＯＮＳＥ  ５４）に含まれる情報をＳＯＡＰメッセージに変換してＷｅｂアクセス応答とするメッセージをＷｅｂサーバ２８に返す（ＭＥＳＳＡＧＥ  ５６）。
【００４６】
さらに、Ｗｅｂサーバ２８は、受信したＳＯＡＰメッセージを本文とするＨＴＴＰ応答信号（ＨＴＴＰ  ＲＥＳ．  ５８）を生成し、時刻Ｔ３２にＷｅｂサービススタブ２０に供給する。Ｗｅｂサービススタブ２０は、供給されるＨＴＴＰ応答信号に含まれるＳＯＡＰメッセージを解釈して、時刻Ｔ３４にてＳＯＡＰメッセージの内の応答情報をＷｅｂサービスクライアント１８に返して、イベント登録処理を終了する（ＲＥＳＰＯＮＳＥ  ６０）。
【００４７】
このように動作させることで、片方向だけのアクセスが可能なネットワーク環境であっても、ＳＩＰプロトコルでの要求−応答をイベント配送のトリガとして利用してクライアント端末装置１２とＷｅｂサービス装置１４との間におけるイベントの通知をリアルタイムに行うことができる。また、ＨＴＴＰプロトコルおよびＳＩＰプロトコルがＷｅｂサービススタブ２０およびＷｅｂサービススケルトン２６で制御されることから、クライアントおよびサーバ側のアプリケーションは制御を意識することなく、既存のアプリケーションをそのまま利用することができる。
【００４８】
次にＷｅｂクライアントサーバシステム１０におけるイベント配送処理の手順について図３を参照しながら説明する。このイベント配送処理は、あらかじめ上述したイベント登録処理が行われていることが前提にある。
【００４９】
イベント発火条件に合った事象がＷｅｂサービスサーバ２４の内部で発生する（ＥＶＥＮＴ  ６２）。Ｗｅｂサービスサーバ２４は、イベント発火したイベントの受信を登録するクライアントのリストおよび発火した事象に関する情報を指定し、Ｗｅｂサービススケルトン２６でイベント配送に用いる関数を呼び出して、時刻Ｔ３６にて出力する（ＦＵＮＣ＿ＣＡＬＬ  ６４）。また、Ｗｅｂサービスサーバ２４は、クライアントのリストを指定せずに、クライアント毎にイベント発火を順次通知するようにしてもよい。Ｗｅｂサービススケルトン２６は、関数を介して供給されたイベント情報をＳＯＡＰメッセージに変換し、変換したＳＯＡＰメッセージを受信者情報とともに、時刻Ｔ３８にてＳＩＰユーザエージェント３０に通知する（ＭＥＳＳＡＧＥ  ６６）。
【００５０】
ＳＩＰユーザエージェント３０は、ＳＩＰプロトコル（第２のネットワークプロトコル）を用いて、ＳＩＰユーザエージェント２２にＳＩＰメッセージを生成して、時刻Ｔ４０で供給する（ＳＩＰ  ＭＥＳＳＡＧＥ  ６８）。ＳＩＰユーザエージェント２２は、イベントの受信者であるクライアントが管理している。ＳＩＰメッセージ６８には、ボディにＳＯＡＰメッセージが格納されている。ＳＩＰユーザエージェント２２は、時刻Ｔ４２にてＳＩＰメッセージ中のＳＯＡＰメッセージをＷｅｂサービススタブ２０に渡す（ＭＥＳＳＡＧＥ  ７０）。
【００５１】
Ｗｅｂサービススタブ２０は、イベント情報として渡されたＳＯＡＰメッセージを解釈し、Ｗｅｂサービスクライアント１８における適切なクライアントモジュールに対してイベント情報を引数とする関数を呼び出し、関数を介してイベント情報を時刻Ｔ４４にて提供する（ＦＵＮＣ＿ＣＡＬＬ  ７２）。Ｗｅｂサービスクライアント１８は、時刻Ｔ４６にて関数によるイベント呼出しに対応して内部的にイベント処理を行う（ＩＭＰＬＥＭＥＮＴ  ７４）。
【００５２】
時刻Ｔ４８にてＷｅｂサービスクライアント１８は、イベント処理の結果を関数呼出しの戻り値としてＷｅｂサービススタブ２０に返す（ＲＥＳＰＯＮＳＥ  ７６）。Ｗｅｂサービススタブ２０は、供給されたイベント処理結果をＳＯＡＰメッセージに変換する。Ｗｅｂサービススタブ２０は、さらにＳＯＡＰメッセージをＨＴＴＰのボディに格納したＨＴＴＰ要求信号を生成し、時刻Ｔ５０にてＷｅｂサーバ２８に発信する（ＨＴＴＰ  ＲＥＱ．  ７８）。
【００５３】
Ｗｅｂサーバ２８は、通常行う処理と同様に、ＨＴＴＰ要求信号に含むＳＯＡＰメッセージ内のＵＲＬ情報からＨＴＴＰ要求信号（メッセージ）の配送先を検索し、時刻Ｔ５２にてＨＴＴＰ要求を適切なＷｅｂサービススケルトン２６に配送する（ＭＥＳＳＡＧＥ  ８０）。Ｗｅｂサービススケルトン２６は、供給されたＨＴＴＰ要求信号中のＳＯＡＰメッセージを解析し、時刻Ｔ５４にて解析結果をＷｅｂサービスサーバ２４から呼び出した関数呼出しの戻り値として返す（ＲＥＳＰＯＮＳＥ  ８２）。時刻Ｔ５６にＷｅｂサービスサーバ２４は、関数呼出しの戻り値（ＲＥＳＰＯＮＳＥ  ８２）を受信し、イベント配送処理が完了する。
【００５４】
ところで、クライアント端末装置１２とＷｅｂサービス装置１４との間におけるＨＴＴＰトランザクションは、ＨＴＴＰ要求を送信しただけの状況にあり、クライアント端末装置１２はまだＨＴＴＰ応答を受けていない。ＨＴＴＰトランザクション（要求−応答）を満足させるため、Ｗｅｂサービススケルトン２６は、ＨＴＴＰ応答信号を生成し、時刻Ｔ５８にＷｅｂサーバ２８へと出力する（ＨＴＴＰ  ＲＥＳ．  ８４）。ＨＴＴＰ応答信号は、ボディに何等かの情報が格納されている。また、何等かの情報は、空でもよい。
【００５５】
Ｗｅｂサーバ２８は、時刻Ｔ６０にて供給されるＨＴＴＰ応答信号（ＨＴＴＰ  ＲＥＳ．  ８４）をＷｅｂサービススタブ２０に出力する。Ｗｅｂサービススタブ２０がＨＴＴＰ応答信号（ＨＴＴＰ  ＲＥＳ．  ８６）を時刻Ｔ６２にて受信して、ＨＴＴＰトランザクションも完了する。時刻Ｔ６２でイベント配送に関する処理を終了する。このような手順でリアルタイム性を保ってＷｅｂクライアントサーバシステム１０におけるイベント配信を行うことができる。
【００５６】
次に上述した動作の例における変形例について図４を参照しながら説明する。本実施例は、通知すべきイベント情報の情報量が多く、ＳＩＰメッセージのボディとしての格納が不適当な場合の対応シーケンスである。したがって、本実施例は、この対応シーケンスに注目して説明し、共通するシーケンスには図３で用いた参照符号を使用する。イベント条件を満たす事象（ＥＶＥＮＴ  ６２）が発生し、時刻Ｔ３６にてＷｅｂサービスサーバ２４は、イベント配送の関数呼出しを行い、関数を介してイベント情報をＷｅｂサービススケルトン２６に供給する（ＦＵＮＣ＿ＣＡＬＬ  ６４）。
【００５７】
Ｗｅｂサービススケルトン２６は、供給されたイベント情報をＳＯＡＰメッセージに変換する。ここで、Ｗｅｂサービススケルトン２６は、情報量判断機能部３６で変換したＳＯＡＰメッセージの情報量がＳＩＰメッセージのボディとして許容可能量か否かを判断する。情報量が許容可能量な場合、図３のシーケンスでイベント配送処理を行う。また、情報量が許容可能量を越えていると判断した場合も、ＳＯＡＰメッセージの受信に用いる識別情報（ＩＤ）と受信者に関する情報だけを時刻Ｔ４０にてＳＩＰユーザエージェント２２に通知する。時刻Ｔ４２にてＳＩＰユーザエージェント２２は、Ｗｅｂサービススタブ２０に識別情報等を格納するＳＯＡＰメッセージ（ＭＥＳＳＡＧＥ  ７０）を渡す。許容量を越えたＳＯＡＰメッセージは、Ｗｅｂサービススケルトン２６に一時保存される。
【００５８】
Ｗｅｂサービススタブ２０は、イベント情報にアクセスするため識別情報（ＩＤ）をＳＯＡＰメッセージ（ＭＥＳＳＡＧＥ  ７０）から取り出して、ＳＯＡＰメッセージを含む新たなＳＯＡＰメッセージを生成する。Ｗｅｂサービススタブ２０は、さらに新たなＳＯＡＰメッセージをボディとするＨＴＴＰ要求信号を作成し、時刻Ｔ６４にてＷｅｂサーバ２８に対して発行する（ＨＴＴＰ  ＲＥＱ．  ８６）。
【００５９】
Ｗｅｂサーバ２８は、受信したＨＴＴＰ要求信号から得られるＵＲＬを基に配送先を検索し、時刻Ｔ６６にて適切なＷｅｂサービススケルトン２６にＨＴＴＰ要求信号を配送する（ＨＴＴＰ  ＲＥＱ．  ８８）。Ｗｅｂサービススケルトン２６は、供給されたＨＴＴＰ要求信号に含まれるＳＯＡＰメッセージを取り出して、解析し、識別情報（ＩＤ）の格納を認識する。Ｗｅｂサービススケルトン２６は、比較部３８で時刻Ｔ３８において作成した識別情報に現在、認識した識別情報が一致するか否かを判断する。一致と判断した場合、識別情報に対応する保存していたＳＯＡＰメッセージを時刻Ｔ６８にてＷｅｂサーバ２８に返す（ＭＥＳＳＡＧＥ  ９０）。Ｗｅｂサーバ２８は、供給されたＳＯＡＰメッセージ９０をＨＴＴＰ応答のボディに格納して、時刻Ｔ７０にてＷｅｂサービススタブ２０に返す（ＨＴＴＰ  ＲＥＳ．  ９２）。Ｗｅｂサービススタブ２０は、ＳＩＰメッセージのボディとして許容量を越えたＳＯＡＰメッセージを得ることができる。これ以降の手順は、図３に示した時刻Ｔ４４以降の手順に同じで、処理する時刻が異なるだけである。すなわち、時刻Ｔ４４〜Ｔ６２は、それぞれ、図４における時刻Ｔ７２〜Ｔ９０に対応している。
【００６０】
このように動作させることにより、高速、軽量のシグナリングを行うＳＩＰプロトコルのようなプロトコルでは、ボディに非常に少量のメッセージしか添付できないが、一旦、ＳＩＰプロトコルでクライアント側の受信者に情報（識別情報）を提供し、ＨＴＴＰプロトコルで提供した情報を送って識別情報の確認に応じて保存していた許容量を超えたＳＯＡＰメッセージをＨＴＴＰ応答のボディに格納して返すことにより、それぞれの有利な機能を有効に発揮させて、リアルタイムにイベントを通知することができる。
【００６１】
なお、本発明の実施例は、イベント配信に限定して説明したが、この実施例に限定されるものでなく、まったく同じ構造、シーケンスでサーバ側からクライアント側が提供するサービス（本実施例と逆の配信）を呼び出して利用できることは言うまでもない。
【００６２】
以上のように構成することにより、クライアント端末装置１２とＷｅｂサービス装置１４で構築されているクライアント−サーバのシステムにおいて、ＨＴＴＰプロトコル（第１のネットワークプロトコル）により通信を行うとともに、ＳＩＰユーザエージェント２２をＷｅｂサービススタブ２０接続し、ＳＩＰユーザエージェント３０をＷｅｂサービススケルトン２６に接続して、得られる情報をＳＩＰプロトコル（第２のネットワークプロトコル）によりクライアント端末装置１２とＷｅｂサービス装置１４との間で双方向通信させて、これまでの片方向の通信システムを用いて、サーバ環境の大幅な変更を行うことなく、要求に応じた通信だけを行って、メッセージ通信の大量発生を防止し、ＳＩＰプロトコルによる通信をトリガとして利用してリアルタイム性も保つことができることにより、ＲＰＣにおいて有効なＷｅｂサービス技術を提供することができる。
【００６３】
第１のネットワークプロトコルに片方向通信のＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用い、第２のネットワークプロトコルに、双方向通信のＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて、両者のプロトコルが有する欠点を相互に補うように用いることにより、システムの大幅な構築変更を行うことなく、リアルタイム性を有するＷｅｂサービスシステムを提供することができる。
【００６４】
ＳＩＰユーザエージェント３０は、事象の発生を満足する条件に応じて生成される情報をクライアント端末装置１２のＳＩＰユーザエージェント２２に供給し、ＳＩＰユーザエージェン２２は、Ｗｅｂサービススタブ２０に生成した情報を供給し、クライアント端末装置１２からの配信応答は、ＨＴＴＰプロトコルを利用してＷｅｂサービススタブ２０とＷｅｂサーバ２８との間により行うことにより、リアルタイムにＷｅｂサービスサーバ２４で発生したイベントを配送することができる。
【００６５】
ＳＩＰユーザエージェント３０は、Ｗｅｂサービスサーバ２４にて生じた事象の発生条件の満足にともなって生じる情報の発生を受けて、Ｗｅｂサービスサーバ２４から配送する情報量がＳＩＰプロトコルにおいて転送可能な情報量以上あるとの判断に応じて発生条件にともなって得られる情報だけをクライアント端末装置１２のＳＩＰユーザエージェント２２にトリガとして通知し、Ｗｅｂサービスサーバ２４の配送する情報をＷｅｂサービススケルトン２６に保存し、ＳＩＰユーザエージェント２２は、Ｗｅｂサービススタブ２０に供給された情報を出力し、Ｗｅｂサービススタブ２０は、Ｗｅｂサーバ２８とＨＴＴＰプロトコルで供給された情報を通信し、Ｗｅｂサーバ２８は、この供給された情報に合うＷｅｂサービススケルトン２６に保存された情報を読み出してＷｅｂサービススタブ２０と通信することにより、ＳＩＰプロトコルが転送可能な情報量が少なくても、Ｗｅｂサービススタブ２０からのＨＴＴＰ要求信号に対するＨＴＴＰ応答信号に保存した情報をメッセージ情報に変換してＷｅｂサーバ２８に送り、配送することができる。配送処理の結果を示す値をＨＴＴＰ要求信号でＷｅｂサービス装置１４に送り、要求−応答のＨＴＴＰトランジェントに対応したＨＴＴＰ応答信号をＷｅｂサービス装置１４からクライアント端末装置１２に返して情報（イベント）の配送を完了させることができる。
【００６６】
また、本発明のＷｅｂサービスシステムのイベント通知方法によれば、情報の登録に用いるプログラムを要求し、ＳＩＰプロトコルで動作させるクライアント端末装置１２にてＷｅｂサービス装置１４からの情報を着信する際に用いる着信情報が何かを問い合せて、この問い合せた着信情報を取得してトリガにするとともに、登録されたものか判別して管理を可能にし、この着信情報をＨＴＴＰプロトコルで規定されたメッセージ情報に格納した要求信号としてクライアント端末装置１２からＷｅｂサービス装置１４に転送し、Ｗｅｂサービス装置１４にて転送先の検索および解釈をメッセージ情報に施し、このＷｅｂサービスの配送で用いる情報を格納して、Ｗｅｂサービス装置１４にてクライアント端末装置１２での着信情報および事象の発生条件を管理することができることから、リアルタイムな情報の通知を可能にする。
【００６７】
とくに、この方法は、上述した処理（第７の工程）の後に、Ｗｅｂサービス装置１２内にて事象の発生条件に合った、新たな事象の発生を受けて、この事象の情報およびこの情報の利用者情報を含む関連情報を指定して、この関連情報の配送に用いるプログラムを準備し、この準備により得られた事象の情報をメッセージ情報に変換し、このメッセージ情報をＳＩＰプロトコルでクライアント端末装置１２に供給し、クライアント端末装置１２にてこの供給されたメッセージ情報を解釈し、この解釈した事象の情報に応じた処理を内部的に実行し、この処理結果を示す値をメッセージ情報に変換し、ＨＴＴＰプロトコルにおける要求信号としてこの変換したメッセージ情報をＷｅｂサービス装置１４に発信し、受信したメッセージ情報を解析し、処理結果を示す値を受け、この後、要求信号に対する応答信号をクライアント端末装置１２に返すことにより、リアルタイム性を保ってＷｅｂサービスをクライアント端末装置１２に提供することができる。
【００６８】
さらに、ＳＩＰプロトコルで転送可能な情報量が少ないことから、得られた事象の情報をメッセージ情報に変換し、このメッセージ情報をＳＩＰプロトコルでクライアント端末装置１２に供給する際において（第９の工程）、生成したメッセージ情報がＳＩＰプロトコルにおける転送可能な許容量の範囲にあるか否かを判断し、この許容量の範囲を越える場合、関連情報のうち、このメッセージ情報の受信に用いる識別情報および利用者情報をＳＩＰプロトコルによりクライアント端末装置１２に通知し、この許容量の範囲を越えたメッセージ情報を保存し、（第１０の工程の前に、）このクライアント端末装置１２では受信したメッセージ情報から識別情報を取り出し、この識別情報を含むメッセージ情報を新たに生成し、ＨＴＴＰプロトコルの要求信号としてＷｅｂサービス装置１４に発行し、Ｗｅｂサービス装置１４で配送先を検索し、供給されたメッセージ情報を解釈し、識別情報の格納を認識し、この識別情報が先に作成した識別情報に該当するか否かを判断し、該当する場合にこの識別情報に対応するメッセージ情報をクライアント端末装置１２にＨＴＴＰプロトコルの応答信号として返して、応答信号のメッセージ情報を解釈する処理（第１０の工程）以降を行うことにより、大量のＷｅｂサービス情報が要求されても、リアルタイム性を保ちながら、情報を配送することができる。
【００６９】
【発明の効果】
このように本発明のＷｅｂサービスシステムによれば、クライアント端末装置とＷｅｂサービス装置で構築されているクライアント−サーバのシステムにおいて、第１のネットワークプロトコルにより通信を行うとともに、第２の通信機能ブロックを第１の通信機能ブロックに接続し、ユーザ通信機能ブロックをサービス実行機能ブロックに接続して、得られる情報を第２のネットワークプロトコルによりクライアント端末装置とＷｅｂサービス装置との間で双方向通信させて、片方向の通信システムを用いて、サーバ環境の大幅な変更を行うことなく、要求に応じた通信だけを行って、メッセージ通信の大量発生を防止し、第２のネットワークプロトコルによる通信をトリガとして利用してリアルタイム性も保つことができることにより、ＲＰＣにおいて有効なＷｅｂサービス技術を提供することができる。
【００７０】
また、本発明のＷｅｂサービスシステムのイベント通知方法によれば、情報の登録に用いるプログラムを要求し、第２のネットワークプロトコルで動作させるクライアント端末装置にてＷｅｂサービス装置からの情報を着信する際に用いる着信情報が何かを問い合せて、この問い合せた着信情報を取得してトリガにするとともに、登録されたものか判別して管理を可能にし、この着信情報を第１のネットワークプロトコルで規定されたメッセージ情報に格納した要求信号としてクライアント端末装置からＷｅｂサービス装置に転送し、Ｗｅｂサービス装置にて転送先の検索および解釈をメッセージ情報に施し、このＷｅｂサービスの配送で用いる情報を格納して、Ｗｅｂサービス装置にてクライアント端末装置での着信情報および事象の発生条件を管理することができることから、リアルタイムな情報の通知を可能にする。
【図面の簡単な説明】
【図１】本発明のＷｅｂサービスシステムを適用したＷｅｂクライアントサーバシステムの概略的な構成を示すブロック図である。
【図２】図１のＷｅｂクライアントサーバシステムでイベント登録する手順を説明するシーケンスチャートである。
【図３】図２のイベント登録後に生じたイベント発火にともなうイベント配送処理の手順を説明するシーケンシャルチャートである。
【図４】図３のイベント配送処理における変形例を説明するシーケンシャルチャートである。
【符号の説明】
１０  Ｗｅｂクライアントサーバシステム
１２  クライアント端末装置
１４  Ｗｅｂサービス装置
１６  ネットワーク
１８  Ｗｅｂサービスクライアント
２０  Ｗｅｂサービススタブ
２２，  ３０  ＳＩＰユーザエージェント
２４  Ｗｅｂサービスサーバ
２６  Ｗｅｂサービススケルトン
２８  Ｗｅｂサーバ
【図１】
2004356967.tif 000003
【図２】
2004356967.tif 000004
【図３】
2004356967.tif 000005
【図４】
2004356967.tif 000006