(57)【要約】      （修正有）【課題】メッセージ通信の信頼性を確保しつつ、アプリケーションと高信頼メッセージング機構とを分離する。【解決手段】クライアント装置１０とサーバ装置２０との各信頼性確保メッセージング送受信部１２，２２が互いに連携して高信頼性メッセージングの機能（(i)リクエストメッセージ自動再送、(ii)リクエストメッセージ処理状態の確認、(iii)レスポンスメッセージの再取得、(iv)リクエストメッセージ二重受信の防御）を実現することによりメッセージ通信の信頼性を確保できる。また、信頼性確保メッセージング送受信部１２，２２がクライアントアプリケーション１１及びサーバアプリケーション２１とは別に設けられることにより、アプリケーションと高信頼メッセージング機構とを分離できる。【選択図】図１
2005056260.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置で実行されるクライアントアプリケーションと、サーバ装置で実行されるサーバアプリケーションとの間のメッセージ通信を実行するためのメッセージ通信システムであって、
前記クライアント装置は、
前記クライアントアプリケーションからの要求に基づいてリクエストメッセージを前記サーバ装置に送信するリクエスト送信手段と、このサーバ装置から受信したレスポンスメッセージを前記クライアントアプリケーションに送出するレスポンス受信手段と、
前記リクエストメッセージの送信から所定時間内にレスポンスメッセージを受信しないとき、確認メッセージを前記サーバ装置に送信する確認メッセージ送信手段と、
前記確認メッセージに対応する処理状態情報を前記サーバ装置から受信すると、この処理状態情報に基づいて、「リクエストメッセージの再送」又は「レスポンスメッセージの取得」を実行するメッセージ処理実行手段と、を備えており、
前記サーバ装置は、
前記クライアント装置から受信したリクエストメッセージに関し、「当該リクエストメッセージの処理中」又は「対応するレスポンスメッセージの送信済」を示す処理状態情報が記憶される状態情報記憶手段と、
前記クライアント装置からリクエストメッセージを受信すると、このリクエストメッセージの処理状態情報が前記状態情報記憶手段にあるかどうかを確認し、このリクエストメッセージが前記状態情報記憶手段に無い場合、当該リクエストメッセージを前記サーバアプリケーションに送出するリクエスト受信手段と、
このサーバアプリケーションから受けたレスポンスメッセージを該当するクライアント装置に送信するレスポンス送信手段と、
前記クライアント装置から確認メッセージを受信すると、前記状態情報記憶手段を参照して該当するリクエストメッセージの処理状態情報を前記クライアント装置に送信する処理状態送信手段と、
を備えたことを特徴とするメッセージ通信システム。
【請求項２】
クライアント装置で実行されるクライアントアプリケーションと、サーバ装置で実行されるサーバアプリケーションとの間のメッセージ通信を実行するためのメッセージ通信方法であって、
前記クライアント装置が、前記クライアントアプリケーションからの要求に基づいてリクエストメッセージを前記サーバ装置に送信する工程と、
前記サーバ装置が、前記クライアント装置から受信したリクエストメッセージに関し、「当該リクエストメッセージの処理中」又は「対応するレスポンスメッセージの送信済」を示す処理状態情報を状態情報記憶装置に記憶する工程と、
前記サーバ装置が、前記クライアント装置からリクエストメッセージを受信すると、このリクエストメッセージの処理状態情報が前記状態情報記憶装置にあるかどうかを確認し、このリクエストメッセージが前記状態情報記憶手段に無い場合、当該リクエストメッセージを前記サーバアプリケーションに送出する工程と、
前記サーバ装置が、このサーバアプリケーションから受けたレスポンスメッセージを該当するクライアント装置に送信する工程と、
前記クライアント装置が、前記サーバ装置から受信したレスポンスメッセージを前記クライアントアプリケーションに送出する工程と、
前記クライアント装置が、対応するレスポンスメッセージを所定時間内に受信しないとき、確認メッセージを前記サーバ装置に送信する工程と、
前記サーバ装置が、前記クライアント装置からリクエストメッセージに対する確認メッセージを受信すると、前記状態情報記憶装置を参照して該当するリクエストメッセージの処理状態情報を前記クライアント装置に送信する工程と、
前記クライアント装置が、前記確認メッセージに対応する処理状態情報を受信すると、この処理状態情報に基づいて、「リクエストメッセージの再送」又は「レスポンスメッセージの取得」を実行する工程と、
を備えたことを特徴とするメッセージ通信方法。
【請求項３】
クライアント装置で実行されるクライアントアプリケーションと、サーバ装置で実行されるサーバアプリケーションとの間のメッセージ通信に用いられる前記クライアント装置のプログラムであって、
前記クライアント装置のコンピュータを、
前記クライアントアプリケーションからの要求に基づいてリクエストメッセージを作成して当該リクエストメッセージに関する情報をメモリに記憶し、前記リクエストメッセージを前記サーバ装置に送信するリクエスト送信手段と、このサーバ装置から受信したレスポンスメッセージを前記クライアントアプリケーションに送出するレスポンス受信手段、
前記リクエストメッセージの送信から所定時間内にレスポンスメッセージを受信しないとき、前記メモリの記憶内容に基づいて確認メッセージを作成し、この確認メッセージを前記サーバ装置に送信する確認メッセージ送信手段、
前記確認メッセージに対応する処理状態情報を受信すると、この処理状態情報に基づいて、「リクエストメッセージの再送」又は「レスポンスメッセージの取得」を実行するメッセージ処理実行手段、
として機能させるためのプログラム。
【請求項４】
請求項３に記載のプログラムにおいて、
前記メッセージ通信は、メッセージング方式が同期メッセージングに対応しており、
前記メッセージ処理実行手段は、前記処理状態情報を受信する際に、前記処理状態情報を含む応答メッセージから当該処理状態情報を抽出するように前記コンピュータを機能させることを特徴とするプログラム。
【請求項５】
請求項３又は請求項４に記載のプログラムにおいて、
前記リクエスト送信手段は、前記確認メッセージに応じて処理状態情報を返信する機能を持たない他のサーバ装置にもリクエストメッセージを送信するように前記コンピュータを機能させることを特徴とするプログラム。
【請求項６】
請求項３乃至請求項５のいずれか１項に記載のプログラムにおいて、
前記クライアント装置のコンピュータを、
外部から入力された命令に基づいて、前記リクエストメッセージ送信手段、前記確認メッセージ送信手段及び前記メッセージ処理実行手段の使用の可否が設定される使用可否設定手段、
として機能させるためのプログラム。
【請求項７】
請求項３乃至請求項６のいずれか１項に記載のプログラムにおいて、
前記メッセージ通信のプロトコルとしてＳＯＡＰを使用しており、
前記リクエストメッセージ送信手段、前記確認メッセージ送信手段及び前記メッセージ処理実行手段としては、ＪＡＸ−ＲＰＣで標準定義されたメッセージハンドラが実装されてなることを特徴とするプログラム。
【請求項８】
クライアント装置で実行されるクライアントアプリケーションと、サーバ装置で実行されるサーバアプリケーションとの間のメッセージ通信に用いられる前記サーバ装置のプログラムであって、
前記サーバ装置のコンピュータを、
前記クライアント装置から受信したリクエストメッセージに関し、「当該リクエストメッセージの処理中」又は「対応するレスポンスメッセージの送信済」を示す処理状態情報をメモリに書込む状態情報書込手段、
前記クライアント装置からリクエストメッセージを受信すると、このリクエストメッセージの処理状態情報が前記メモリに無い旨を確認し、当該リクエストメッセージを前記サーバアプリケーションに送出するリクエスト受信手段、
このサーバアプリケーションから受けたリクエストメッセージを該当するクライアント装置に送信するレスポンス送信手段、
前記クライアント装置からリクエストメッセージに対する確認メッセージを受信すると、前記メモリを参照して該当するリクエストメッセージの処理状態情報を前記クライアント装置に送信する処理状態送信手段、
として機能させるためのプログラム。
【請求項９】
請求項８に記載のプログラムにおいて、
前記メッセージ通信は、メッセージング方式が同期メッセージングに対応しており、
前記処理状態送信手段は、前記処理状態情報を前記クライアント装置に送信する際に、前記処理状態情報を含む応答メッセージをクライアント装置に送信するように前記コンピュータを機能させることを特徴とするプログラム。
【請求項１０】
請求項８又は請求項９のいずれか１項に記載のプログラムにおいて、
前記レスポンス送信手段は、前記確認メッセージを送信する機能を持たない他のクライアント装置からリクエストメッセージを受けたときでも、このリクエストメッセージに対応するレスポンスメッセージを当該他のクライアント装置に送信するように前記コンピュータを機能させることを特徴とするプログラム。
【請求項１１】
請求項８乃至請求項１０のいずれか１項に記載のプログラムにおいて、
前記サーバ装置のコンピュータを、
外部から入力された命令に基づいて、前記状態情報書込手段、前記リクエスト受信手段、前記レスポンス送信手段及び前記処理状態送信手段の使用の可否が設定される使用可否設定手段、
として機能させるためのプログラム。
【請求項１２】
請求項８乃至請求項１１のいずれか１項に記載のプログラムにおいて、
前記メッセージ通信のプロトコルとしてＳＯＡＰを使用しており、
前記リクエスト受信手段、前記レスポンス送信手段及び前記処理状態送信手段としては、ＪＡＸ−ＲＰＣで標準定義されたメッセージハンドラが実装されてなることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メッセージ通信システム、方法及びプログラムに関する。
【背景技術】
【０００２】
一般に、ネットワークを介して接続された複数の装置間の通信のうち、各装置で実行されるアプリケーション間でメッセージを送受信し合うことをメッセージ通信又はメッセージングなどと呼ぶことがある。また、メッセージを送信して処理を依頼するアプリケーションをクライアントアプリケーションと呼び、メッセージを受信して処理を実行するアプリケーションをサーバアプリケーションと呼ぶことがある。
【０００３】
この種のメッセージ通信は、ネットワーク上の通信相手のアプリケーションのダウン、ネットワーク障害など様々な要因により失敗する可能性がある。例えば図１７（ａ）,（ｃ）は、ネットワーク障害などによるリクエスト伝送異常及びレスポンス伝送異常を表し、図１７（ｂ）は、サーバアプリケーション異常による処理中のダウンを表している。
【０００４】
一方、メッセージ通信は、失敗の可能性があるにも関わらず、高い信頼性が求められる場面が多々ある。例えば、商品の購入依頼のように課金を伴うメッセージ送受信では、クライアントアプリケーションからのメッセージをサーバアプリケーションに確実に届ける必要がある。クライアントアプリケーション側で、送信したメッセージがサーバアプリケーションに届いたか否か不明確な場合、サーバアプリケーションでの処理状態を確認する必要や、場合によってはメッセージを再送する必要が生じる。クライアントアプリケーションがサーバアプリケーションにメッセージを再送しても二重に課金しないように、サーバアプリケーション側では同一メッセージを二重に処理しない仕組みが必要になる。
【０００５】
換言すると、高信頼なメッセージ通信には、（ｉ）クライアントアプリケーションからサーバアプリケーションへのメッセージ自動再送、（ii）メッセージ処理状態（処理状況）の確認、（iii）クライアントアプリケーションによるサーバからのレスポンスメッセージの再取得、（iv）サーバアプリケーションによるメッセージ二重受信の防御、のような機能が必要とされる場合が多い。そこで、本明細書中、上記（ｉ）〜（iv）の機能を備えたメッセージ通信を「高信頼メッセージ通信」又は「高信頼性メッセージング」と呼ぶ。
【０００６】
以上のような高信頼メッセージ通信は、近年のインターネットの普及に伴い、例えばインターネットを使った課金／決済サービスなどといった様々なサービスに利用され始めている。そこで、高信頼メッセージ通信に用いられる高信頼メッセージ通信プロトコルの標準化が進められている。
【０００７】
このような標準化の方式としては、例えば、ｅｂＸＭＬ(e-business XML)及びＷＳリライアビリティ（WS-Reliability：Web Services Reliability)が提案されている。ｅｂＸＭＬは、ＸＭＬを使った企業間システム連携のための標準であり、ｅｂＸＭＬが規定するメッセージ通信プロトコルには、信頼性向上のための仕組みが備わっている。ＷＳリライアビリティは、ＷｅｂサービスのＳＯＡＰ（Simple Object Access Protocol）通信の信頼性(reliability)向上のためのプロトコルである。
【０００８】
しかしながら、これら標準提案はまだ広く実用化されておらず、業界で広く認められた高信頼メッセージ通信プロトコル標準は確定していない。しかも、これら標準提案は、非同期メッセージングのみを対象としており、同期メッセージングについては標準提案すら登場していない。
【０００９】
なお、同期メッセージングは、クライアントからリクエストメッセージを送信すると、そのリクエストに対する結果をサーバからのレスポンスメッセージに入れて返却するメッセージング方式である。
【００１０】
一方、非同期メッセージングは、クライアントからリクエストメッセージを送信すると、始めにリクエストを受け付けた旨を通知するレスポンスメッセージをサーバから返却し、次にリクエストに対する結果をサーバからのリクエストメッセージに入れてクライアントに届けるメッセージング方式である。
【００１１】
いずれのメッセージング方式にしても、特に、インターネットを使ったサービスの利用／提供などでは、高信頼化を確保しつつ、更に以下の要望（ｗ１）〜（ｗ３）が個別に又は同時に存在している。  
（ｗ１）非同期メッセージングだけでなく、同期メッセージングの高信頼化。  
（ｗ２）アプリケーションと高信頼メッセージング機構の分離。  
（ｗ３）高信頼メッセージング機構を備えたアプリケーションと、備えていないアプリケーションとの間のメッセージングの保証。
【００１２】
ここで、要望（ｗ１）について述べる。非同期メッセージングでは通常、メッセージ通信時にクライアント端末にもサーバとしての機能が必要となる。しかし、例えばモバイル機器のような軽量クライアント端末では、メッセージ通信のための機能が限定される。軽量クライアント端末を対象とした場合には、非同期メッセージングは必ずしも適切とは限らず、同期メッセ−ジングも扱えることが望まれる。
【００１３】
要望（ｗ２）について述べる。前述した通り、高信頼メッセージ通信プロトコルの標準は確定していない。そのため、アプリケーションが特定の高信頼メッセージ通信機構に依存するのは好ましくない。例えば通信相手企業からの要求により、あるアプリケーションで使用した高信頼メッセージ通信機構を、標準プロトコルの確定により、別の高信頼メッセージ通信機構に切り替える必要が生じるかもしれない。あるいは、一つのアプリケーションが同時に複数種類の高信頼メッセージ通信機構をサポートする必要が生じるかもしれない。このような状況に対処するために、アプリケーションと高信頼メッセージング機構は、明確に分離されていることが望ましい。
【００１４】
要望（ｗ３）について述べる。特に、インターネットを使ったサービスの利用／提供などでは、通信したい相手が自分と同じ高信頼メッセージ通信機構を採用していない場合がある。但し、この場合でも、高信頼メッセージング機構を備えたアプリケーションと備えていないアプリケーションとの間において、少なくとも通常のメッセージ通信が可能なことが望まれる。ここでいう通常のメッセージ通信は、高信頼性を持たないメッセージ通信を意味している。
【００１５】
一方、要望（ｗ１）〜（ｗ３）とは別に、高信頼メッセージ通信を実現する技術が特許文献１に提案されている。
【００１６】
特許文献１では、異なる装置で実行される互いに関連する２つの処理に関して、共に１回ずつの実行を保証する技術が開示されている（段落［０００８］〜［００１１］参照）。詳しくは、クライアント装置では、処理要求送信手段が第１の処理要求メッセージをサーバ装置に送信する。サーバ装置では、第１の処理要求メッセージを受けると、第１の処理実行手段が第１の処理を実行し、完了通知送信手段が完了通知をクライアント装置に送信する。クライアント装置では、完了通知を受けると、第２の処理実行手段が第２の処理を実行する。
【００１７】
ここで、メッセージ通信の障害発生時には、クライアント装置では、再送手段が処理要求メッセージをサーバ装置に再送する。サーバ装置では、既に第１の処理が完了しているため、第１の処理を実行せず、完了通知送信手段が完了通知をクライアント装置に送信する。  
このように、特許文献１の提案では、処理要求メッセージが再送された際に、第１の処理の二重実行を防いでいる。
【特許文献１】特開２００３−１６０４１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１８】
しかしながら、特許文献１に記載の技術では、前述した高信頼メッセージ通信への要望（ｗ１）〜（ｗ３）のうち、要望（ｗ２）の「アプリケーションと高信頼メッセージング機構の分離」及び要望（ｗ３）の「高信頼メッセージング機構を備えたアプリケーションと備えていないアプリケーションとの間のメッセージングの保証」が解決されていない。
【００１９】
これら要望（ｗ１）〜（ｗ３）は、適用するサービスに応じて個別に又は同時に存在するものなので、必ずしも同時に解決する必要はないが、少なくとも個別には解決することが望まれている。
【００２０】
本発明は上記実情を考慮してなされたもので、メッセージ通信の信頼性を確保しつつ、アプリケーションと高信頼メッセージング機構とを分離し得るメッセージ通信システム、方法及びプログラムを提供することを目的とする。
【００２１】
また、本発明の他の目的は、メッセージ通信の信頼性を確保しつつ、同期メッセージングを高信頼化し得るプログラムを提供することを目的とする。
【００２２】
さらに、本発明の他の目的は、メッセージ通信の信頼性を確保しつつ、高信頼メッセージング機構を備えたアプリケーションと備えていないアプリケーションとの間のメッセージングを保証し得るプログラムを提供することを目的とする。
【課題を解決するための手段】
【００２３】
第１の発明は、クライアント装置で実行されるクライアントアプリケーションと、サーバ装置で実行されるサーバアプリケーションとの間のメッセージ通信を実行するためのメッセージ通信システムであって、前記クライアント装置としては、前記クライアントアプリケーションからの要求に基づいてリクエストメッセージを前記サーバ装置に送信するリクエスト送信手段と、このサーバ装置から受信したレスポンスメッセージを前記クライアントアプリケーションに送出するレスポンス受信手段と、前記リクエストメッセージの送信から所定時間内にレスポンスメッセージを受信しないとき、確認メッセージを前記サーバ装置に送信する確認メッセージ送信手段と、前記確認メッセージに対応する処理状態情報を前記サーバ装置から受信すると、この処理状態情報に基づいて、「リクエストメッセージの再送」又は「レスポンスメッセージの取得」を実行するメッセージ処理実行手段と、を備えており、前記サーバ装置としては、前記クライアント装置から受信したリクエストメッセージに関し、「当該リクエストメッセージの処理中」又は「対応するレスポンスメッセージの送信済」を示す処理状態情報が記憶される状態情報記憶手段と、前記クライアント装置からリクエストメッセージを受信すると、このリクエストメッセージの処理状態情報が前記状態情報記憶手段に無い旨を確認し、当該リクエストメッセージを前記サーバアプリケーションに送出するリクエスト受信手段と、このサーバアプリケーションから受けたレスポンスメッセージを該当するクライアント装置に送信するレスポンス送信手段と、前記クライアント装置から確認メッセージを受信すると、前記状態情報記憶手段を参照して該当するリクエストメッセージの処理状態情報を前記クライアント装置に送信する処理状態送信手段と、を備えている。
【００２４】
従って、第１の発明は以上のような手段を講じたことにより、各手段が連携して上記（ｉ）〜（iv）の機能を実現することによりメッセージ通信の信頼性を確保しつつ、各手段がクライアントアプリケーション及びサーバアプリケーションとは別に設けられることにより、アプリケーションと高信頼メッセージング機構とを分離することができる。
【００２５】
なお、第１の発明は、各装置の集合体を「システム」として名称を表現したが、これに限らず、各装置の集合体又は各装置個別に「装置」、「方法」、「コンピュータ読取り可能な記憶媒体」又は「プログラム」等といった任意の名称で表現しても良いことは言うまでもない。このことは第１の発明に限らず、他の発明でも同様である。また、次の第２及び第３の発明は、請求項には各装置個別のプログラムとして述べたが、ここでは各装置個別のプログラムではなく、メッセージ通信システムにまとめた場合を第１の発明を引用して説明する。
【００２６】
第２の発明は、第１の発明において、前記メッセージ通信としては、メッセージング方式が同期メッセージングに対応しており、前記メッセージ処理実行手段としては、前記処理状態情報を受信する際に、前記処理状態情報を含む応答メッセージから当該処理状態情報を抽出する機能を有し、前記処理状態送信手段としては、前記処理状態情報を前記クライアント装置に送信する際に、前記処理状態情報を含む応答メッセージをクライアント装置に送信する機能を有している。
【００２７】
このように、第２の発明は、第１の発明に対応する作用を有する同期メッセージングを実現するので、メッセージ通信の信頼性を確保しつつ、同期メッセージングを高信頼化することができる。
【００２８】
第３の発明は、第１又は第２の発明において、前記リクエスト送信手段としては、前記確認メッセージに応じて処理状態情報を返信する機能を持たない他のサーバ装置にもリクエストメッセージを送信し、前記レスポンス受信手段としては、前記確認メッセージを送信する機能を持たない他のクライアント装置からリクエストメッセージを受けたときでも、このリクエストメッセージに対応するレスポンスメッセージを当該他のクライアント装置に送信する。
【００２９】
これにより、第３の発明は、第１又は第２の発明に対応する作用に加え、メッセージ通信の信頼性を確保しつつ、高信頼メッセージング機構を備えたアプリケーションと備えていないアプリケーションとの間のメッセージングを保証することができる。
【発明の効果】
【００３０】
以上説明したように本発明によれば、メッセージ通信の信頼性を確保しつつ、アプリケーションと高信頼メッセージング機構とを分離できる。また、メッセージ通信の信頼性を確保しつつ、同期メッセージングを高信頼化できる。さらに、メッセージ通信の信頼性を確保しつつ、高信頼メッセージング機構を備えたアプリケーションと備えていないアプリケーションとの間のメッセージングを保証できる。
【発明を実施するための最良の形態】
【００３１】
以下、本発明の各実施形態について図面を参照しながら説明する。  
（第１の実施形態）
図１は本発明の第１の実施形態に係るメッセージ通信システムの構成を示す模式図である。このメッセージ通信システムは、クライアント装置１０で実行されるクライアントアプリケーション１１と、サーバ装置２０で実行されるサーバアプリケーション２１との間のメッセージ通信を実行するためのものである。なお、クライアント装置１０とサーバ装置２０とは、互いにネットワーク３０を介して接続され、リクエスト／レスポンスメッセージが送受信される。また、各装置１０，２０は、ハードウエア構成とソフトウエア構成の組合せにより構成されるが、ソフトウエア構成の部分は、各装置１０，２０の機能を実現させるためのプログラムが予め各装置１０，２０にインストールされて実現される。このプログラムのインストールによるソフトウエア構成の実現は、他の実施形態でも同様である。
【００３２】
ここで、クライアント装置１０は、クライアントアプリケーション１１、信頼性確保メッセージング送受信部１２及びメッセージ送受信ログ保存部１３を備えている。
【００３３】
クライアントアプリケーション１１は、任意のアプリケーションであり、サーバアプリケーション２１にメッセージ通信を実行する際に、サーバアプリケーション２１とは直接通信せずに、信頼性確保メッセージング送受信部１２を用いる機能をもっている。
【００３４】
信頼性確保メッセージング送受信部１２は、高信頼性メッセージングを実現する機能を持つもので、１つのアプリケーションに対して１つのインスタンスが作成される。高信頼性メッセージングを実現する機能としては、ログ機能、リクエスト送信機能、レスポンス受信機能、確認メッセージ送信機能及びメッセージ処理実行機能がある。
【００３５】
ログ機能は、クライアントアプリケーション１１からの要求に基づいてリクエストメッセージを作成し、リクエストメッセージに関する情報をメッセージ処理状態保存部２３に保存する機能と、サーバ装置２０からレスポンスメッセージを受信したとき、このレスポンスメッセージに関する情報をメッセージ処理状態保存部２３に保存する機能とがある。ここで、メッセージに関する情報は、例えばメッセージを一意に識別する情報（例、メッセージＩＤ）、送受信履歴、再送履歴などが含まれる。
【００３６】
リクエスト送信機能は、クライアントアプリケーション１１からの要求に基づいてリクエストメッセージをサーバ装置２０に送信する機能である。
【００３７】
レスポンス受信機能は、サーバ装置２０から受信したレスポンスメッセージをクライアントアプリケーション１１に送出する機能である。
【００３８】
確認メッセージ送信機能は、リクエストメッセージの送信から所定時間内にレスポンスメッセージを受信しないとき、確認再送リクエストメッセージ（確認メッセージ）をサーバ装置２０に送信する機能である。
【００３９】
メッセージ処理実行機能は、確認再送リクエストメッセージに対応する処理状態情報をサーバ装置２０から受信すると、この処理状態情報に基づいて、「リクエストメッセージの再送」又は「レスポンスメッセージの取得」を実行する機能である。なお、本実施形態は、メッセージング方式が同期メッセージングに対応するため、メッセージ処理実行機能は、処理状態情報を受信する際に、処理状態情報を含む確認再送レスポンスメッセージから当該処理状態情報を抽出する機能をもっている。
【００４０】
メッセージ送受信ログ保存部１３は、信頼性確保メッセージング送受信部１２により読出／書込されるメモリ等の記憶装置であり、クライアント装置１０が送受信するリクエスト／レスポンスメッセージに関する情報が保存される。メッセージに関する情報は、信頼性確保メッセージング送受信部１２のログ機能にて述べた通りである。
【００４１】
一方、サーバ装置２０は、サーバアプリケーション２１、信頼性確保メッセージング送受信部２２、メッセージ処理状態保存部２３及び確認再送部２４を備えている。
【００４２】
サーバアプリケーション２１は、任意のアプリケーションであり、クライアントアプリケーション１１とのメッセージ通信の際に、クライアントアプリケーション２１とは直接通信せずに、信頼性確保メッセージング送受信部２２を用いる機能をもっている。
【００４３】
信頼性確保メッセージング送受信部２２は、状態情報書込機能、リクエスト受信機能、レスポンス送信機能、処理状態送信機能を備えている。
【００４４】
状態情報書込機能は、クライアント装置１０から受信したリクエストメッセージに関し、「当該リクエストメッセージの処理中」又は「対応するレスポンスメッセージの送信済」を示す処理状態情報をメッセージ処理状態保存部２３に書込む機能である。
【００４５】
リクエスト受信機能は、クライアント装置１０からリクエストメッセージを受信すると、このリクエストメッセージの処理状態情報がメッセージ処理状態保存部２３に無い旨を確認し、当該リクエストメッセージをサーバアプリケーション２１に送出する機能である。
【００４６】
レスポンス送信機能は、このサーバアプリケーション２１から受けたレスポンスメッセージを該当するクライアント装置１０に送信する機能である。
【００４７】
処理状態送信機能は、クライアント装置１０から確認再送リクエストメッセージを受信すると、メッセージ処理状態保存部２３を参照して該当するリクエストメッセージの処理状態情報をクライアント装置１０に送信する機能である。本実施形態は、メッセージ通信は、メッセージング方式が同期メッセージングに対応するため、処理状態送信機能は、処理状態情報をクライアント装置１０に送信する際に、処理状態情報を含む確認再送レスポンスメッセージをクライアント装置１０に送信する機能をもっている。
【００４８】
メッセージ処理状態保存部２３は、信頼性確保メッセージング送受信部２２により読出／書込されるメモリ等の記憶装置であり、サーバ装置２０が送受信するリクエスト／レスポンスメッセージに関する情報が保存される。メッセージに関する情報は、例えば、メッセージを一意に識別する情報、送受信履歴、メッセージの処理状態、応答回数などがある。
【００４９】
なお、高信頼性メッセージングは、クライアント装置１０及びサーバ装置２０の両者が信頼性確保メッセージング送受信部１２，２２を使用した場合のみ実現可能となる。但し、いずれか一方又は両方が信頼性確保メッセージング送受信部１２，２２を使用しない場合でも、高信頼性ではない、通常のメッセージングを実行可能となっている。ここで、信頼性確保メッセージング送受信部１２，２２を使用しない場合とは、信頼性確保メッセージング送受信部１２，２２を持たない場合と、信頼性確保メッセージング送受信部１２，２２を持っているが使用しない場合とのいずれでもよい。信頼性確保メッセージング送受信部１２，２２を持っているが使用しない場合は、クライアント装置１０及びサーバ装置２０の各々に、例えば外部から入力された命令に基づいて、信頼性確保メッセージング送受信部１２，２２の使用の可否が設定される使用可否設定部を設けることにより、実現可能である。
【００５０】
次に、以上のように構成されたメッセージ通信システムの動作を説明する。  
（１）正常時
図１に示すように、クライアント装置１０において、クライアントアプリケーション１１は、リクエストメッセージを信頼性確保メッセージング送受信部１２に送信する（ステップＡ１）。
【００５１】
信頼性確保メッセージング送受信部１２は、このリクエストメッセージに基づいて、リクエストメッセージに関する情報をメッセージ送受信ログ保存部１３に保存し（ステップＡ２）、このリクエストメッセージに対して高信頼性メッセージング情報を付加して得られたリクエストメッセージをサーバ装置２０に送信する（ステップＡ３）。
【００５２】
サーバ装置２０においては、信頼性確保メッセージング送受信部２２がリクエストメッセージを受信し、このリクエストメッセージに関する情報をメッセージ処理状態保存部２３に保存する（ステップＡ４）。
【００５３】
その後、信頼性確保メッセージング送受信部２２は、サーバアプリケーション２１に実行処理を移す（ステップＡ５）。
【００５４】
しかる後、信頼性確保メッセージング送受信部２２は、サーバアプリケーション２１から処理結果を受けると（ステップＡ６）、処理結果に基づいてレスポンスメッセージを作成し、このレスポンスメッセージに高信頼性メッセージング情報を付加してレスポンスメッセージを得る。
【００５５】
続いて、信頼性確保メッセージング送受信部２２は、得られたレスポンスメッセージに関する情報をメッセージ処理状態保存部２３に保存した後（ステップＡ７）、このレスポンスメッセージをクライアント装置１０に送信する（ステップＡ８）。
【００５６】
クライアント装置１０においては、信頼性確保メッセージング送受信部１２が受信したレスポンスメッセージに関する情報をメッセージ送受信ログ保存部１３に保存し（ステップＡ９）、そのレスポンスメッセージをクライアントアプリケーション１１に送信する（ステップＡ１０）。
【００５７】
以上により、正常時のメッセージ通信の動作が完了する。
【００５８】
（２）異常時
次に、ネットワークエラーなどが生じてクライアント装置１０とサーバ装置２０との間でのメッセージ通信が正常に行われなかった場合の動作を述べる。  
図１に示すように、クライアント装置１０においては、信頼性確保メッセージング送受信部１２がサーバ装置２０内の確認再送部２４に対し、リクエストメッセージがサーバ装置２０に届いたか否かを確認することができる。
【００５９】
具体的には信頼性確保メッセージング送受信部１２は、リクエストメッセージの送信から所定時間内にレスポンスメッセージを受信しないとき、確認再送リクエストメッセージに関する情報をメッセージ送受信ログ保存部１３に保存し（ステップＢ１）、確認再送リクエストメッセージをサーバ装置２０に送信する（ステップＢ２）。
【００６０】
サーバ装置２０の確認再送部２４は、確認再送リクエストメッセージを受信すると、確認再送メッセージの識別情報を基にメッセージ処理状態保存部２３を検索し（ステップＢ３）、リクエストメッセージの処理状態として「未受信」、「応答済」、「エラー」、「処理中」のいずれかを示す検索結果を得る。
【００６１】
ここで、「未受信」は、クライアント装置１０からのリクエストメッセージをサーバ装置２０が受信してない場合に該当する。「応答済」は、サーバアプリケーション２１で正常に処理され、レスポンスメッセージを返信したがクライアント装置１０に届いていない場合に該当する。「エラー」は、サーバアプリケーション２１などが処理中にダウンした場合に該当する。「処理中」は、サーバアプリケーション２１の処理が終わっていない場合に該当する。
【００６２】
いずれにしても、確認再送部２４は、いずれかの検索結果を含む確認再送レスポンスメッセージを信頼性確保メッセージング送受信部１２に通知する（ステップＢ４）。但し、検索結果が「応答済」の場合には、検索結果に加え、返信したレスポンスメッセージをも確認再送レスポンスメッセージに含めてクライアント装置１０に送信する。
【００６３】
クライアント装置１０においては、信頼性確保メッセージング送受信部１２が、受信した確認再送レスポンスメッセージに関する情報をメッセージ送受信ログ保存部１３に保存する（ステップＢ５）。
【００６４】
ここで、メッセージの処理状態が「応答済」の場合、信頼性確保メッセージング送受信部１２は、確認再送レスポンスメッセージから「応答済」のレスポンスメッセージを抽出し、得られたレスポンスメッセージをクライアントアプリケーション１１に送信する（ステップＡ１０と同じ処理）。
【００６５】
「未受信」の場合、信頼性確保メッセージング送受信部１２は、リクエストメッセージを自動再送する。
【００６６】
（３）次に、信頼性確保メッセージング送受信部１２がクライアント装置１０内のみにある場合の動作を述べる。図２に示すように、サーバ装置２０内に信頼性確保メッセージング送受信部２２が無い場合でもメッセージの送受信は行われる。
【００６７】
（３−１）正常時
クライアント装置１０においては、前述同様にステップＡ１〜Ａ３を実行し、信頼性確保メッセージング送受信部１２が、クライアントアプリケーション１１から受けたリクエストメッセージに基づき、リクエストメッセージに関する情報をメッセージ送受信ログ保存部１３に保存し、高信頼性メッセージング情報を付加したリクエストメッセージをサーバ装置２０に送信する。
【００６８】
サーバ装置２０では、リクエストメッセージを受信するが、信頼性確保メッセージング送受信部２２が無いので、前述したステップＡ４〜Ａ７を行なわない。
【００６９】
すなわち、サーバ装置２０では、受信したリクエストメッセージをサーバアプリケーションが処理し、対応するレスポンスメッセージをクライアント装置に送信する（ステップＡ８’）。
【００７０】
一方、クライアント装置１０は、前述同様にステップＡ９’及びＡ１０を実行し、信頼性確保メッセージング送受信部１２がレスポンスメッセージに関する情報をメッセージ送受信ログ保存部１３に保存し、レスポンスメッセージをクライアントアプリケーション１１に送信する。
【００７１】
これにより、正常時のメッセージ通信の動作が完了する。  
（３−２）異常時
異常時のメッセージ通信の動作に関しては、クライアント装置１０が前述同様にステップＢ１，Ｂ２を実行し、確認再送リクエストメッセージを送出したとしても、サーバ装置２０では、信頼性確保メッセージング送受信部２２が無いので、前述したステップＢ３，Ｂ４を行なわない。
【００７２】
（４）信頼性確保メッセージング送受信部２２がサーバ装置２０内のみにある場合の動作を説明する。図３に示すように、クライアント装置１０内に信頼性確保メッセージング送受信部１２が無い場合でもメッセージの送受信は行われる。
【００７３】
（４−１）正常時
クライアント装置１０においては、前述したステップＡ２，Ａ３が実行されず、クライアントアプリケーション１１からステップＡ１同様に送信されたリクエストメッセージがサーバ装置２０に送信される（ステップＡ３’）。
【００７４】
サーバ装置２０においては、前述同様にステップＡ４’〜Ａ８’が実行され、受信したリクエストメッセージに関する情報をメッセージ処理状態保存部２３に保存した後、サーバアプリケーション２１に実行処理をし、処理結果に基づいて作成したレスポンスメッセージに対して高信頼性メッセージング情報を付加し、得られたレスポンスメッセージに関する情報をメッセージ処理状態保存部２３に保存し、このレスポンスメッセージをクライアント装置１０に送信する。
【００７５】
クライアント装置１０においては、前述したステップＡ９が実行されず、受信したレスポンスメッセージをクライアントアプリケーション１１が受信する。
【００７６】
以上により、正常時のメッセージ通信の動作が完了する。
【００７７】
（４−２）異常時
クライアント装置１０内に信頼性確保メッセージング送受信部１２が無いので、基本的にはステップＢ１〜Ｂ２が行われず、従って、後のステップＢ３〜Ｂ５も行われない。
【００７８】
しかしながら、高機能なクライアントアプリケーション１１の場合、確認再送リクエストの送信機能を有している場合がある。そこで、以下の説明はこの場合について述べる。
【００７９】
クライアントアプリケーション１１は、リクエストメッセージをサーバ装置２０に送信した際に、対応するレスポンスメッセージを所定時間内に受信しないとき、確認再送メッセージをサーバ装置２０に送信する（ステップＢ２’）。
【００８０】
サーバ装置２０は、前述同様にステップＢ３’，Ｂ４’を実行し、確認再送部２４が、メッセージ処理状態の検索結果を含む確認再送レスポンスメッセージをクライアント装置１０に送信する。また、検索結果が「応答済」の場合には、前述同様にレスポンスメッセージをも確認再送レスポンスメッセージに含めている。
【００８１】
クライアント装置１０においては、ステップＢ５が実行されず、クライアントアプリケーション１１が確認再送レスポンスメッセージを受信し、確認再送レスポンスメッセージ内のメッセージ処理状態に基づいて、レスポンスメッセージの抽出やリクエストメッセージの自動再送などを実行する。
【００８２】
上述したように本実施形態によれば、信頼性確保メッセージング送受信部１２，２２が連携して高信頼性メッセージングの機能（(i)リクエストメッセージ自動再送、(ii)リクエストメッセージ処理状態の確認、(iii)レスポンスメッセージの再取得、(iv)リクエストメッセージ二重受信の防御）を実現することによりメッセージ通信の信頼性を確保することができる。
【００８３】
詳しくは、リクエストメッセージがサーバ装置２０に届いたか否か、リクエストメッセージの処理状態を確認する確認再送機能を提供できる。また、確認した処理状態がリクエストメッセージの未受信を示すとき、リクエストメッセージを自動的に再送する自動再送機能を提供できる。また、確認した処理状態がリクエストメッセージの応答済を示すとき、レスポンスメッセージを確認再送レスポンスメッセージから抽出することができる。さらに、確認した処理状態が、リクエストメッセージの処理中を示すとき、所定時間後に再度、確認再送リクエストメッセージをサーバ装置に送信することができる。また、通信が長期間途絶えた時、又はサーバ装置２０がダウンしたとき、送受信メッセージをログとして保存することで手動復帰又は復旧後に自動復帰することができる。
【００８４】
また、上述したメッセージ通信の信頼性を確保しつつ、信頼性確保メッセージング送受信部１２，２２がクライアントアプリケーション１１及びサーバアプリケーション２１とは別に設けられることにより、アプリケーションと高信頼メッセージング機構とを分離することができる。
【００８５】
そして、このようにアプリケーションと高信頼メッセージング機構が明確に分離されるため、アプリケーションは、高信頼メッセージ通信機構の使用／不使用に依存することなく、メッセージング信頼性向上の恩恵を受けることができる。また、アプリケーション開発者にとっては、メッセージング信頼性向上のための開発コストを削減できる利点がある。
【００８６】
さらに、本実施形態を応用した複数種類の高信頼メッセージング機構が存在する場合、アプリケーションで使用するある高信頼メッセージング機構を、別の高信頼メッセージング機構に切り替えることが容易になる。あるいは、一つのアプリケーションが同時に複数種類の高信頼メッセージング機構をサポートすることも容易になる。
【００８７】
また、本実施形態によれば、メッセージング方式を同期メッセージングに適用することにより、同期メッセージングの高信頼化を実現することができる。補足すると、非同期メッセージングは、クライアント装置側にもサーバとしての機能が必要となる。しかしながら、モバイル機器のような軽量のクライアント装置では、メッセージ通信のためにサーバとしての機能を登載することは回避したい状況にある。本実施形態は、サーバとしての機能が不要な同期メッセージングを用いるので、軽量のクライアント装置のように、非同期メッセージングが不適切な状況でも、高信頼性メッセージングを実現させることができる。
【００８８】
さらに、本実施形態によれば、図２及び図３に示したように、高信頼メッセージング機構を備えたアプリケーションと、備えていないアプリケーションとの間のメッセージングを保証することができる。補足すると、インターネットを使ったサービスの利用／提供などでは、通信したい相手が自分と同じ高信頼メッセージ通信機構を採用していない場合がある。この場合でも、本実施形態によれば、高信頼メッセージング機構を備えたアプリケーションと、備えていないアプリケーションとの間で、高信頼性は無いものの、通常のメッセージ通信をすることができる。
【００８９】
（第２の実施形態）
図４は本発明の第２の実施形態に係るメッセージ通信システムの構成を示す模式図であり、図１と同一部分には同一符号を付してその詳しい説明を省略し、ここでは異なる部分について主に述べる。
【００９０】
すなわち、本実施形態は、第１の実施形態の具体例であり、信頼性確保メッセージング送受信部１２，２２として、Ｗｅｂサービス標準の通信プロトコルであるＳＯＡＰ通信における高信頼性メッセージング機能を提供するものである。
【００９１】
詳しくは、信頼性確保メッセージング送受信部１２，２２としては、汎用的なＳＯＡＰライブラリ全体を作成するのではなく、既存のＳＯＡＰライブラリのプラグイン（Plug-in）やハンドラ（Handler）として、ＳＯＡＰ通信における高信頼性メッセージングを実現するライブラリを作成することにより、既存のコードを変更せずに高信頼性メッセージングに対応するものである。
【００９２】
ここで、クライアント装置１０の信頼性確保メッセージング送受信部１２は、高信頼性メッセージング処理部１４、リクエストメッセージ送信部１５及びレスポンスメッセージ受信部１６を備えている。
【００９３】
高信頼性メッセージング処理部１４は、クライアントアプリケーション１１から受けたリクエストメッセージに基づいて、リクエストメッセージに関する情報をメッセージ送受信ログ保存部１３に保存する機能と、リクエストメッセージに対するレスポンスメッセージを所定時間内に受信しないとき、リクエストメッセージのＩＤを指定した確認メッセージをサーバ装置２０に送信する機能と、確認応答メッセージ内のメッセージ処理状態に応じ、「リクエストメッセージの再送」又は「レスポンスメッセージの抽出」を実行する機能とをもっている。なお、確認メッセージは、第１の実施形態における確認再送リクエストメッセージに相当し、確認応答メッセージは、第１の実施形態における確認再送レスポンスメッセージに相当する。
【００９４】
リクエストメッセージ送信部１５は、リクエストメッセージに関する情報がメッセージ送受信ログ保存部１３に保存された後、リクエストメッセージのＳＯＡＰヘッダに高信頼性メッセージング情報（メッセージＩＤ、リクエストメッセージ作成時のタイムスタンプ、メッセージの送信回数など）を付加して得られたリクエストメッセージをサーバ装置２０に送信する機能をもっている。
【００９５】
レスポンスメッセージ受信部１６は、サーバ装置２０から受信したレスポンスメッセージを解析してレスポンスメッセージに関する情報をメッセージ送受信ログ保存部１３に保存する機能と、そのレスポンスメッセージをクライアントアプリケーション１１に送出する機能とをもっている。
【００９６】
一方、サーバ装置２０の信頼性確保メッセージング送受信部２２は、リクエストメッセージ受信部２５及びレスポンスメッセージ送信部２６を備えている。
【００９７】
リクエストメッセージ受信部２５は、クライアント装置１０から受信したリクエストメッセージに関する情報をメッセージ処理状態保存部２３に保存する機能と、保存の後、リクエストメッセージをサーバアプリケーション２１に送出する機能とをもっている。
【００９８】
レスポンスメッセージ送信部２６は、サーバアプリケーション２１から受けた処理結果に基づいてレスポンスメッセージを作成し、このレスポンスメッセージに高信頼性メッセージング情報（メッセージＩＤ、レスポンスメッセージ作成時のタイムスタンプなど）を付加してレスポンスメッセージを得る機能と、得られたレスポンスメッセージに関する情報をメッセージ処理状態保存部２３に保存する機能と、得られたレスポンスメッセージをクライアント装置１０に送信する機能とをもっている。
【００９９】
なお、リクエストメッセージ受信部２５及びレスポンスメッセージ送信部２６は、受信及び処理したメッセージの処理状態を管理するために、図５に示す如き、メッセージに関する情報をメッセージ処理状態保存部２３内のメッセージステータス管理テーブル２３ｔに保存する。
【０１００】
メッセージに関する情報の各項目は、メッセージＩＤ、ステータス（処理状態）、メッセージ有効期限、送信時刻、二重送信チェックの実施有無、応答回数、受信時刻、クライアント装置１０のＩＰアドレス、リクエストメッセージのＨＴＴＰヘッダ、リクエストメッセージのＳＯＡＰメッセージ、レスポンスメッセージのＨＴＴＰヘッダ、レスポンスメッセージのＳＯＡＰメッセージ、からなる。
【０１０１】
図６にメッセージステータス管理テーブル２３ｔ内の行の例を示す。  
「ａ１」エントリは、クライアント装置１０からメッセージＩＤ「ＩＤ０１」で送られ、時刻ｔ_ｃ１に受信したリクエストメッセージに関する行である。このメッセージのステータス（処理状態）は「processing（処理中）」である。応答前であるため送信時刻及び応答回数はＮＵＬＬである。
【０１０２】
「ａ２」エントリは、クライアント装置１０からメッセージＩＤ「ＩＤ０２」で送られ、時刻ｔ_ｃ２に受信したリクエストメッセージに関する行である。このメッセージの応答は既に実施されているため、ステータスは「responded（応答済）」である。
【０１０３】
次に、以上のような信頼性確保メッセージング送受信部１２，２２が最新の標準技術に柔軟に対応可能な構成である旨を詳細に説明する。  
本実施形態は、アプリケーション１１，２１と、信頼性確保メッセージング送受信部（高信頼性メッセージング機構）１２，２２とを分離した構成を、既存のＳＯＡＰライブラリのプラグインやＳＯＡＰハンドラにより実現している。これにより、高信頼性メッセージング機構は、アプリケーション部分に依存しないだけでなく、最新の技術仕様が公開された場合、高信頼性メッセージング機構のみを新しいものに置換することで最新の標準技術に迅速に対応可能となっている。
【０１０４】
ここで、ハンドラ（Handler）は、クライアント−サーバ間でやり取りされるＳＯＡＰ リクエスト／レスポンスの送受信を仲介するコンポーネントであり、ＳＯＡＰヘッダのカスタマイズやメッセージ内の任意にセキュリティ設定など、ＳＯＡＰメッセージに対して直接的な処理を実行可能なものである。
【０１０５】
本実施形態では、図７にクラス図を示すように、リクエストメッセージ送信部１５、レスポンスメッセージ受信部１６、リクエストメッセージ受信部２５及びレスポンスメッセージ送信部２６がハンドラに相当する。各送信部１５，２６及び各受信部１６，２５は、業界標準のＪＡＸ−ＲＰＣのＡＰＩに準拠したjavax.xml.rpc.handler.GenericHandlerを継承してリクエスト、レスポンスのハンドラが実装されている。ハンドラの実装により、アプリケーションサーバなどのミドルウェアにも依存しない汎用的なライブラリとして高信頼性メッセージングに対応可能となっている。
【０１０６】
次に、以上のように構成されたメッセージ通信システムの動作を図８〜図１３のシーケンス図を参照しながら説明する。  
（１）正常時
図８及び図４に示すように、クライアント装置１０において、クライアントアプリケーション１１は、リクエストメッセージを信頼性確保メッセージング送受信部１２に送信する（ステップＡ１）。
【０１０７】
信頼性確保メッセージング送受信部１２においては、高信頼性メッセージング処理部１４がこのリクエストメッセージに基づいて、リクエストメッセージに関する情報をメッセージ送受信ログ保存部１３に保存する（ステップＡ２）。
【０１０８】
その後、リクエストメッセージ送信部１５は、このリクエストメッセージのＳＯＡＰヘッダに高信頼性メッセージング情報（メッセージＩＤ、リクエストメッセージ作成時のタイムスタンプ、メッセージの送信回数など）を付加して得られたリクエストメッセージをサーバ装置２０に送信する（ステップＡ３）。
【０１０９】
サーバ装置２０においては、信頼性確保メッセージング送受信部２２がリクエストメッセージを受信すると、リクエストメッセージ受信部２５がこのリクエストメッセージのＳＯＡＰヘッダに付加された高信頼性メッセージング情報を解析し、このリクエストメッセージに関する情報をメッセージ処理状態保存部２３に保存する（ステップＡ４）。
【０１１０】
その後、リクエストメッセージ受信部２５は、サーバアプリケーション２１に実行処理を移す（ステップＡ５）。
【０１１１】
しかる後、信頼性確保メッセージング送受信部２２内のレスポンスメッセージ送信部２６は、サーバアプリケーション２１から処理結果を受けると（ステップＡ６）、処理結果に基づいてレスポンスメッセージを作成し、このレスポンスメッセージのＳＯＡＰヘッダに高信頼性メッセージング情報（メッセージＩＤ、レスポンスメッセージ作成時のタイムスタンプなど）を付加してレスポンスメッセージを得る。
【０１１２】
続いて、信頼性確保メッセージング送受信部２２は、得られたレスポンスメッセージに関する情報をメッセージ処理状態保存部２３に保存した後（ステップＡ７）、このレスポンスメッセージをクライアント装置１０に送信する（ステップＡ８）。
【０１１３】
クライアント装置１０においては、信頼性確保メッセージング送受信部１２のレスポンスメッセージ受信部１６が受信したレスポンスメッセージのＳＯＡＰヘッダを解析してレスポンスメッセージに関する情報をメッセージ送受信ログ保存部１３に保存し（ステップＡ９）、そのレスポンスメッセージをクライアントアプリケーション１１に送信する（ステップＡ１０）。  
以上により、正常時のメッセージ通信の動作が完了する。  
（２）異常時
次に、異常時の動作を「送信経路上の異常」、「サーバ処理異常」及び「返信経路上の異常」の順に述べる。
【０１１４】
（２−ａ）送信経路上の異常
送信経路上の異常は、図９に示す第１の送信失敗（初回の確認メッセージ送信までに復旧する場合）、図１０に示す第２の送信失敗（再送処理の繰返し終了前に復旧する場合）、図１１に示す第３送信失敗（復旧しない場合）について述べる。
【０１１５】
図９は、リクエストメッセージがサーバ装置２０に届かないが（Ａ３→×）、早めに通信路が復旧し、初回の確認再送メッセージがサーバ装置２０内の確認再送部２４に届く場合の動作を表している。
【０１１６】
クライアント装置１０では、リクエストメッセージに対するレスポンスメッセージを所定時間内に受信しないため、高信頼性メッセージング処理部１４がリクエストメッセージのＩＤを指定した確認メッセージをサーバ装置２０に送信する（ステップＢ２）。
【０１１７】
サーバ装置２０内の確認再送部２４は、指定されたＩＤをもつメッセージの情報をメッセージ処理状態保存部２３から検索するが見当たらないため、メッセージの処理状態を「未受信」として確認応答メッセージを作成し、クライアント装置１０内の高信頼性メッセージング処理部１４へ返信する（ステップＢ４）。
【０１１８】
高信頼性メッセージング処理部１４は、確認応答メッセージ内のメッセージ処理状態に応じ、リクエストメッセージを再送するか否かを決めるが、ここでは再送する場合を述べる。
【０１１９】
高信頼性メッセージング処理部１４は、送信回数を“２”に代えて再送を表したリクエストメッセージを送信する（ステップＡ３）。以下、正常時と同様に、ステップＡ４〜Ａ１０の動作が実行される。
【０１２０】
図１０は、リクエストメッセージの送信に失敗するが、再送処理の繰り返しを終了する前に通信路が復旧する場合の動作を表している。クライアント装置１０内の高信頼性メッセージング処理部１４は、リクエストメッセージ送信後、所定時間後に１回目の確認メッセージを送信するが、通信路が復旧していないため、送信が失敗して返信が得られない。
【０１２１】
その後、通信路が復旧し、２回目の確認メッセージはサーバ装置２０に到達する（ステップＢ２）。以後の処理は図９と同様であり、サーバ装置２０内の確認再送部２４はメッセージの処理状態を「未受信」として、確認応答メッセージを返信する（ステップＢ４）。
【０１２２】
図１１は、送信に失敗し通信路が復旧しない場合の動作を表している。クライアント装置１０の高信頼性メッセージング処理部１４は、一定時間毎に確認メッセージの送信を試みるが、通信路が復旧していないため、返信が得られない。再送回数の上限（Ｎ回）を越えるかリクエストメッセージの有効期限を過ぎた場合に再送処理を終了し、クライアントアプリケーション１１に例外処理を通知又は提供する（以下、例外処理を投げるという）。
【０１２３】
（２−ｂ）サーバ処理異常
図１２は、サーバアプリケーション２１での処理中に中断等が発生して処理に時間がかかったため、所定時間内にリクエストメッセージがクライアント装置１０へ返らない場合の動作を表している。
【０１２４】
クライアント装置１０内の信頼性確保メッセージング送受信部１２は、一定時間待った後にサーバ装置２０内の確認再送部２４へ１回目の確認メッセージを送信する（ステップＢ２）。確認再送部２４では、１回目の確認メッセージ中で指定するＩＤに基づいてメッセージ処理状態保存部２３を検索する。
【０１２５】
指定されたＩＤを持つメッセージに関するエントリが見つかるが、サーバアプリケーション２１ではまだリクエストメッセージの処理を終えていないため、メッセージの処理状態は「処理中」である。
【０１２６】
従って、確認再送部２４は、メッセージ処理状態「処理中」を含む確認応答メッセージをクライアント装置１０へ返信する（ステップＢ４）。
【０１２７】
クライアント装置１０内の高信頼性メッセージング処理部１４は、メッセージの処理状態を確認するため、２回目の確認メッセージを送信する（ステップＢ２）。サーバ装置２０内で処理が終了していればメッセージの処理状態が「応答済」となる。このため、レスポンスメッセージを含む確認応答メッセージがサーバ装置２０の確認再送部２４から返信される（ステップＢ４）。
【０１２８】
（２−ｃ）返信経路上の異常
図１３は、サーバ装置２０が送信したレスポンスメッセージがクライアント装置１０に届かなかった場合の動作を表している。  
レスポンスメッセージが返ってこないため、クライアント装置１０の高信頼性メッセージング処理部１４は、所定時間後にサーバ装置２０に確認メッセージを送信する（ステップＢ２）。通信路が復旧している場合、サーバ装置２０内の確認再送部２４は、確認メッセージを受信してメッセージ処理状態保存部２３を検索し、確認対象であるリクエストメッセージについては「応答済」であることを確認する。そこで、確認再送部２４は、前回のレスポンスメッセージの内容と、メッセージ処理状態「応答済」とを含む確認応答メッセージを作成してクライアント装置１０に返信する（ステップＢ４）。
【０１２９】
以上のようにメッセージ通信システムは動作し、クライアント装置１０のクライアントアプリケーション１１と、サーバ装置２０のサーバアプリケーション２１との間において高信頼性メッセージングを実現する。
【０１３０】
なお、ここで、信頼性確保メッセージング送受信部１２，２２及び確認再送部２４の処理の流れを図１４〜図１６のフローチャートを用いて補足的に説明する。
【０１３１】
図１４は、クライアント装置１０内の信頼性確保メッセージング送受信部１２の処理のうち、リクエストメッセージの送信に関するステップＡ３−１〜Ａ３−１１、レスポンスメッセージの受信に関するステップＡ９−１〜Ａ９−２、クライアントアプリケーション１１への通知に関するステップＡ１０−１〜Ａ１０−３について詳述している。
【０１３２】
図１４に示すように、ステップＡ３−１〜Ａ３−１１においては、レスポンスメッセージを所定時間内に受信しないとき、確認メッセージを送信する処理と、２回目以降の確認メッセージを送信する際に、送信回数の上限やリクエストメッセージの有効期限を確認する処理などが示されている。
【０１３３】
また、ステップＡ９−１〜Ａ９−２においては、レスポンスメッセージを受信したとき、レスポンスメッセージの有効期限を確認し、有効期限を過ぎていたらリクエストメッセージを再送するか否かを決める処理が示されている。
【０１３４】
ステップＡ１０−１〜Ａ１０−３においては、レスポンスメッセージを受信したとき、レスポンスメッセージが有効期限内であればクライアントアプリケーション１１にレスポンスメッセージを送出して終了するが、レスポンスメッセージが有効期限を過ぎておりリクエストメッセージを再送しない場合には例外処理をクライアントアプリケーション１１に投げる処理や、２回目以降の確認メッセージが送信回数の上限又はリクエストメッセージの有効期限を過ぎていた場合には例外処理をクライアントアプリケーション１１に投げる処理が示されている。
【０１３５】
図１５は、サーバ装置２０内の信頼性確保メッセージング送受信部２２の処理のうち、リクエストメッセージの受信に関するステップＡ４−１〜Ａ４−１３、サーバアプリケーション２１への通知に関するステップＡ５−１〜Ａ５−２について詳述している。
【０１３６】
図１５に示すように、ステップＡ４−１〜Ａ４−７においては、リクエストメッセージを受信してＳＯＡＰヘッダからメッセージＩＤを取出したりメッセージの有効期限を確認する処理が示されている。ステップＡ４−８〜Ａ４−１３においては、二重送信チェック処理が示されており、メッセージＩＤがメッセージ処理状態保存部２３内の既存のメッセージＩＤと重複する場合、ＳＯＡＰヘッダとサーバプロパティの設定値の組合せで決まる二重送信チェック処理の実施フラグを確認し、実施要の場合には例外処理をサーバアプリケーション２１に投げる処理が示されている。
【０１３７】
図１６は、サーバ装置２０内の確認再送部２４の処理において、確認メッセージの受信に関するステップＢ３−１〜Ｂ３−１０、クライアント装置１０への確認応答メッセージの送信に関するステップＢ４−１〜Ｂ４−２について詳述している。図１６に示すように、ステップＢ３−１〜Ｂ３−３においては、受信したメッセージが確認メッセージで無い場合には例外処理をサーバアプリケーション２１に投げる処理が示されている。残りのステップＢ３−４〜Ｂ３−１０及びＢ４−１〜Ｂ４−２に関しては、前述した通りである。
【０１３８】
上述したように本実施形態によれば、メッセージ通信プロトコルとしてＳＯＡＰを使用し、ＪＡＸ−ＲＰＣのメッセージハンドラを実装した具体的な構成として、第１の実施形態と同様の効果を得ることができる。
【０１３９】
なお、上記各実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。
【０１４０】
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
【０１４１】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が本実施形態を実現するための各処理の一部を実行しても良い。
【０１４２】
さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶又は一時記憶した記憶媒体も含まれる。
【０１４３】
また、記憶媒体は１つに限らず、複数の媒体から本実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【０１４４】
尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、本実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
【０１４５】
また、本発明におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【０１４６】
なお、本願発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。
【図面の簡単な説明】
【０１４７】
【図１】本発明の第１の実施形態に係るメッセージ通信システムの構成を示す模式図である。
【図２】同実施形態における変形例の動作を説明するための模式図である。
【図３】同実施形態における変形例の動作を説明するための模式図である。
【図４】本発明の第２の実施形態に係るメッセージ通信システムの構成を示す模式図である。
【図５】同実施形態におけるメッセージに関する情報を説明するための図である。
【図６】同実施形態におけるメッセージステータス管理テーブルの一例を示す模式図である。
【図７】同実施形態における各メッセージ送信部及び各メッセージ受信部に実装されたハンドラのクラス図である。
【図８】同実施形態における動作を説明するためのシーケンス図である。
【図９】同実施形態における動作を説明するためのシーケンス図である。
【図１０】同実施形態における動作を説明するためのシーケンス図である。
【図１１】同実施形態における動作を説明するためのシーケンス図である。
【図１２】同実施形態における動作を説明するためのシーケンス図である。
【図１３】同実施形態における動作を説明するためのシーケンス図である。
【図１４】同実施形態におけるクライアント装置の信頼性確保メッセージング送受信部の動作を説明するためのフローチャートである。
【図１５】同実施形態におけるサーバ装置の信頼性確保メッセージング送受信部の動作を説明するためのフローチャートである。
【図１６】同実施形態におけるサーバ装置の確認再送部の動作を説明するためのフローチャートである。
【図１７】従来のメッセージ通信が失敗する場合を説明するための模式図である。
【符号の説明】
【０１４８】
１０…クライアント装置、１１…クライアントアプリケーション、１２，２２…信頼性確保メッセージング送受信部、１３…メッセージ送受信ログ保存部、１４…高信頼性メッセージング処理部、１５…リクエストメッセージ送信部、１６…レスポンスメッセージ受信部、２０…サーバ装置、２１…サーバアプリケーション、２３…メッセージ処理状態保存部、２３ｔ…メッセージステータス管理テーブル、２４…確認再送部、２５…リクエストメッセージ受信部、２６…レスポンスメッセージ送信部、３０…ネットワーク。
【図１】
2005056260.tif 000003
【図２】
2005056260.tif 000004
【図３】
2005056260.tif 000005
【図４】
2005056260.tif 000006
【図５】
2005056260.tif 000007
【図６】
2005056260.tif 000008
【図７】
2005056260.tif 000009
【図８】
2005056260.tif 000010
【図９】
2005056260.tif 000011
【図１０】
2005056260.tif 000012
【図１１】
2005056260.tif 000013
【図１２】
2005056260.tif 000014
【図１３】
2005056260.tif 000015
【図１４】
2005056260.tif 000016
【図１５】
2005056260.tif 000017
【図１６】
2005056260.tif 000018
【図１７】
2005056260.tif 000019