(57)【要約】【課題】本発明の目的は、メッセージ中継システムに接続された一部のアプリケーションに変更があっても、全体のメッセージ交換への影響を少なく、変更を実施可能とすることである。【解決手段】メッセージ中継システムに接続される各アプリケーションに共通のメッセージ中継制御部を設け、この中に受信メッセージ解析機能、メッセージルーティング機能、送信メッセージ組立機能を持たせ、メッセージ中継定義により、それらの機能を使用して、個々のアプリケーション間のメッセージ中継を可能とする。【選択図】  図１
2005025487.tif 000002
【特許請求の範囲】
【請求項１】
複数のプログラム間で通信されるメッセージを中継するメッセージ中継装置において、
前記プログラム毎に予め設定された所定の通信手順でメッセージを通信する通信制御手段と、前記プログラム毎に該プログラムに対応する所定のメッセージフォーマットを相互に変換するメッセージ解析手段と、前記複数プログラム間について前記メッセージについて当該プログラムに対応する所定の順序で中継するメッセージルーティング手段とを備えることを特徴とするメッセージ中継装置。
【請求項２】
前記メッセージ解析手段による受信したメッセージ解析処理と送信するメッセージの組立処理とメッセージルーティング手段によるメッセージルーティング処理をメッセージ中継定義として予め定義する手段とを備えたことを特徴とする請求項１記載のメッセージ中継装置。
【請求項３】
前記メッセージ中継定義は、前記メッセージ中継システムの動作中に変更可能であり、前記メッセージ中継定義により前記メッセージ中継システムにより相互にメッセージ交換を行うプログラムの追加や通信を行っているプログラムの削除またはメッセージフォーマットの変更、メッセージルーティング経路の変更を行う手段とを備えたことを特徴とした請求項２記載のメッセージ中継装置。
【請求項４】
複数のプログラム間で通信されるメッセージを中継するメッセージ中継方法において、
前記プログラム毎に予め設定された所定の通信手順でメッセージを通信し、前記プログラム毎に該プログラムに対応する所定のメッセージフォーマットを相互に変換し、前記複数プログラム間について前記メッセージについて当該プログラムに対応する所定の順序で中継することを特徴とするメッセージ中継方法。
【請求項５】
複数のプログラム間で通信されるメッセージを中継するメッセージ中継プログラムにおいて、
前記プログラム毎に予め設定された所定の通信手順でメッセージを通信する通信制御ステップと、前記プログラム毎に該プログラムに対応する所定のメッセージフォーマットを相互に変換するメッセージ解析ステップと、前記複数プログラム間について前記メッセージについて当該プログラムに対応する所定の順序で中継するメッセージルーティングステップとを備えることを特徴とするメッセージ中継プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、プログラム間のメッセージ交換を中継するメッセージ中継技術に関する。
【０００２】
【従来の技術】
近年、インターネット技術の発展とそれを利用したサービスの普及とともに、例えばＷＥＢサービスと既存の業務アプリケーションを連繋したいといったニーズが高まっている。また、既存の業務アプリケーションを部品化して再利用し、新規開発した業務アプリケーションと連携することにより新しいシステムを構築する試みも行われている。このように複数のアプリケーション間を連携するためには、個々のアプリケーションが持つ通信手順やメッセージフォーマットの違いを吸収する仕掛けが必要となる。
【０００３】
これに対して、個々のアプリケーション毎に、それに対応する通信制御機能とメッセージフォーマット変換機能を備えたアダプタを設け、アダプタ間を標準の通信手順および標準のメッセージフォーマットで接続し、更に複数のアダプタ間を連携してメッセージの経路を制御するフロー制御実行手段を設ける方式が実施されてきた。この方式によれば、複数のアプリケーション間を、個々のアプリケーションを変更せずに連携することが可能となる。なお、このような方式は、例えば引用文献１に開示されている。
【０００４】
【特許文献１】
特開２００１−１６０００６号
【０００５】
【発明が解決しようとする課題】
しかしながら上記従来技術では、クライアント・サーバ型の通信を中継する場合、一般にクライアント・アプリケーションは非常に数が多くしかも同種のものであるため、クライアント側のアダプタは多数のクライアント・アプリケーション（プログラムでも良い）が共用する形態となる。ここで、例えば新たなサーバ・アプリケーションが追加となった場合、それに対応するサーバ側のアダプタを追加するだけでなく、追加された新たなサーバ・アプリケーションにアクセスするクライアント・アプリケーションにも変更が生じ、それに対応するクライアント・アダプタにも変更が必要となる場合が多い。そして、クライアント・アダプタを変更するためには、そのアダプタを共用しているすべてのクライアント・アプリケーションからの通信を一時的に停止する必要があった。この結果、従来技術では新たなアプリケーションを追加するなどのシステム構成の変更を行う場合には、一時的にシステム全体の通信を止める必要があるという問題があった。
しかし、例えばインターネットを利用して不特定の顧客にサービスを提供するようなシステムでは、２４時間切れ目無くサービスを提供し続けることが求められており、変更が必要な一部の顧客のためにサービス全体を停止することは好ましくない。
【０００６】
本発明の目的は、複数プログラム間のメッセージ交換を中継するメッセージ中継装置にて、プログラムの追加や変更などについて、システムにおける通信への影響を少なくすることである。
【０００７】
【課題を解決するための手段】
上記目的を達成するため、本発明は、メッセージ中継システムに接続される各アプリケーションに共通のメッセージ中継制御部を設け、この中に受信メッセージ解析機能、メッセージルーティング機能、送信メッセージ組立機能を持たせ、メッセージ中継定義により、それらの機能を使用して、個々のアプリケーション間のメッセージ中継を可能とし、更に、メッセージ中継システムの動作を止めることなくメッセージ中継定義の変更を可能とした。
【０００８】
【発明の実施の形態】
以下、図を用いて本発明の実施例について説明する。図１は、本発明におけるメッセージ中継システムの構成の一例を示している。本発明のメッセージ中継システムは、クライアント・アプリケーション１００、サーバ・アプリケーションＡ３００，サーバアプリケーションＢ４００，およびメッセージ中継システム２００がネットワークを介して接続されている。ここでのアプリケーションは、プログラムや業務プログラム、オブジェクトでもかまわないものであり、本実施例はアプリケーションに限定されるものではない。
【０００９】
本実施例において、メッセージ中継システム２００は、クライアント・アプリケーション１００、サーバ・アプリケーションＡ３００およびサーバアプリケーションＢ４００と通信するための対クライアント・アプリケーション通信制御部２１０、対サーバ・アプリケーションＡ通信制御部２３０、対サーバ・アプリケーションＢ通信制御部２４０を備え、更にクライアント・アプリケーション１００と、サーバ・アプリケーションＡ３００およびサーバアプリケーションＢ４００との間のメッセージフォーマットの変換とメッセージの経路制御を行うメッセージ中継制御部２２０を備えている。
【００１０】
メッセージ中継制御部２２０は、受信メッセージ解析機能２２２とメッセージルーティング機能２２３および送信メッセージ組立機能２２４を持ち、これらの機能はメッセージ中継定義２２１によって制御される。
【００１１】
メッセージ中継システム２００に接続すアプリケーションの追加や、アプリケーションが使用するメッセージフォーマットの変更、アプリケーション間のメッセージルーティング経路に変更があった場合は、メッセージ中継定義２２１を変更することにより対応できる。
【００１２】
図２に、本実施例におけるメッセージ中継定義の変更に関わるより詳細な構成を示す。メッセージ中継制御部はメッセージ中継制御部Ａ２２０−１、メッセージ中継制御部Ｂ２２０−２、メッセージ中継制御部Ｃ２２０−３のような複数スレッドで構成され、各々のスレッド内メモリ上にメッセージ中継定義のコピーを保持している。また、メッセージ中継定義の変更は、メッセージ中継定義部２５０から共有メモリ２６０を介して行われる。共有メモリ２６０には、変更後のメッセージ中継定義を格納するメッセージ定義格納エリア２６５と、メッセージ中継定義管理２５０からメッセージ中継定義の変更を通知するための更新指示フラグ２６１と、メッセージ中継制御部Ａ２２１−１、メッセージ中継制御部Ｂ２２１−２およびメッセージ中継制御部Ｃ２２１−３がメッセージ中継定義の変更を受付けたことを通知する更新受付フラグＡ２６２、更新受付フラグＢ２６３および更新受付フラグＣ２６４がある。更新指示フラグ２６１と各更新受付フラグは、それぞれ計算機のハードウェアが１命令で更新可能な１語の領域である。
【００１３】
図３に、本実施例において、メッセージ更新定義管理部２５０がメッセージ中継定義を変更する際のフローチャートを示す。まずステップ５０１で、すべての更新受付フラグが更新指示フラグと同じ値となっていることを確認する。もし、更新受付フラグが更新指示フラグと同じ値でなければ、対応するメッセージ中継制御部ではまだ一回前のメッセージ中継定義の変更を完了していないことになるため、ステップ５０２で一定時間スリープし、再度すべての更新受付フラグが更新指示フラグと同じ値になるまでこの処理を繰返す。
【００１４】
次にステップ５０３ででメセージ中継定義格納エリア２６５に変更後のメッセージ中継定義を書込む。次にステップ５０４で更新指示フラグ２６１の値を参照し、０の場合はステップ５０５で１に、１の場合はステップ５０６で０に変更する。この処理によって、メッセージ中継制御部にメッセージ中継定義の変更が通知される。
【００１５】
続いて図４にメッセージ中継制御部が変更後のメッセージ中継定義を読込む際のフローチャートを示す。メッセージ中継制御部の各スレッドは、クライアント・アプリケーションから１つのメッセージを受信すると、メッセージ中継定義にしたがって一連の処理を行いクライアント・アプリケーションに応答を返した後、このメッセージ定義更新処理を実行する。したがって、メッセージ処理中にはメッセージ構成定義の変更には感知しない。
【００１６】
メッセージ中継定義更新処理は、まずステップ５１１で更新指示フラグと自更新受付フラグが等しいかどうかを確認する。等しい場合は、メッセージ中継定義は変更されていないか変更中のため、何もしないで、次のメッセージ受信処理に移る。更新指示フラグと自更新受付フラグの値が不一致の場合、ステップ５１２でメッセージ中継定義格納エリア２６５から、変更後のメッセージ中継定義を読込む。続いて、メッセージ中継定義の更新が完了したことを通知するため、自更新受付フラグに更新指示フラグの値を代入する。
【００１７】
次に、当初はクライアント・アプリケーション１００とサーバ・アプリケーションＡ３００の間のメッセージ中継が行われており、これにサーバ・アプリケーションＢ４００を追加するケースの実施例について説明する。図５は図１に対してメッセージ中継定義の種別のみを追加して明示したものである。即ち、現在使用されているメッセージ中継定義２２１−１は、クライアント・アプリケーション１００とサーバ・アプリケーションＡ３００の間のメッセージの中継のみを行うものであり、メッセージ中継定義２２１−２は、クライアント・アプリケーション１００とサーバ・アプリケーションＡ３００およびサーバ・アプリケーションＢ４００の間のメッセージ中継をおこなうもの、メッセージ中継定義２２１−１は、クライアント・アプリケーション１００とサーバ・アプリケーションＢ４００の間のメッセージの中継のみを行うものである。
【００１８】
図６は、本実施例においてメッセージ中継定義で使用されるスクリプトの概要を示している。
【００１９】
図７は、本実施例におけるメッセージ中継定義２２１−１の内容を示したものである。本実施例では、クライアント・アプリケーション１００とメッセージ中継システム２００の間はＨＴＴＰプロトコルで通信を行う。また、メッセージ中継システム２００とサーバ・アプリケーションＡ３００およびサーバ・アプリケーションＢ４００との間はＴＣＰ／ＩＰプロトコルで通信を行う。
【００２０】
図７では、まず変数定義ノード６００で、使用する構造体、変数、定数、サービス属性の定義を行っている。１行目は、受信データのヘッダ部分を解析して格納する構造体“ＰｒｍＨｔｔｐＲｅｑ”の定義、２行目は当該構造体の第１のデータ要素である“ＰｒｍＨｔｔｐＣｏｍｍａｎｄ”の定義、３行目は当該構造体の第２のデータ要素である“ＰｒｍＨｔｔｐＦｉｌｅ”の定義、４行目は当該構造体の第３のデータ要素である“ＰｒｍＨｔｔｐＶｅｒｓｉｏｎ”の定義、５行目は当該構造体定義の終りを示す。
【００２１】
６行目は受信データのボディ部分を格納するデータ要素の定義。７行目はクライアント・アプリケーション１００に対する正常応答の際の応答データのヘッダを示す定数の定義。８行目はクライアント・アプリケーション１００に対する異常応答の際の応答データのヘッダを示す定数の定義。９行目はサーバ・アプリケーションＡ３００と通信するためのソケットに設定する情報の組である“Ｓｅｒｖｉｃｅ１”の定義、１０行目は当該サービスの第１の要素であるホスト名の定義、１１行目は当該サービスの第２の要素であるポート番号の定義、１２行目は当該サービス定義の終りを示す。
【００２２】
次にノード６０１はこの定義スクリプトの中で最初に処理されるノードであり、受信データを参照して実際に行われるべき処理を決定する、振分処理を行っている。１行目はノード名“ＮｏｄｅＤｉｓｐａｔｃｈ”の定義。２行目はスクリプト処理中にエラーが発生した場合の、エラー処理ノードの定義。３行目では受信データからヘッダ部を読取り、構造体“ＰｒｍＨｔｔｐＲｅｑ”に格納する。ここで“ＬＩＮＥ＿ＩＮ＿ＷＯＲＤ”は受信データのヘッダ部の形式を示しており、空白で区切られた複数のワードがあり、最後に改行（０ｘ０ｄ０ａ）があるデータ形式を示している。４行目は条件分岐で、受信データから読取ったデータ要素“ＰｒｍＨｔｔｐＣｏｍｍａｎｄ”の値が“ｇｅｔ”であればノード“ＮｏｄｅＧｅｔ”にジャンプする。５行目も条件分岐で、データ要素“ＰｒｍＨｔｔｐＣｏｍｍａｎｄ”の値が“ｐｏｓｔ”であればノード“ＮｏｄｅＰｏｓｔ”にジャンプする。６行目は、データ要素“ＰｒｍＨｔｔｐＣｏｍｍａｎｄ”の値が“ｇｅｔ”でも“ｐｏｓｔ”でもなかった場合のエラー処理で、エラー処理ノード“ＮｏｄｅＥｒｒｏｒ”にジャンプする。７行目は当該ノードの終りを示す。
【００２３】
ノード６０２は、クライアント・アプリケーション１００からｇｅｔコマンドが送られた場合の処理を記述したもので、指定されたファイルの内容を読取り、メッセージにセットして応答している。１行目はノード名“ＮｏｄｅＧｅｔ”の定義。２行目ではデータ要素“ＰｒｍＨｔｔｐＦｉｌｅ”に格納された名前のファイルからデータを読取り受信バッファに格納。３行目では送信バッファに正常応答用ヘッダ“ＰｒｍＯＫＨｅａｄｄｅｒ”と受信バッファの内容をコピー。４行目で正常リタンして送信バッファの内容を、応答データとしてクライアント。アプリケーション１００に送信。５行目は当該ノードの終りを示す。
【００２４】
ノード６０３は、クライアント・アプリケーション１００からｐｏｓｔコマンドが送られた場合の処理を記述したもので、受信メッセージからメッセージ・ボディの部分を切り出して、サーバ・アプリケーションＡ３００に送り、その応答をクライアント・アプリケーション１００に応答している。１行目はノード名“ＮｏｄｅＰｏｓｔ”の定義。２行目では受信データ中のボディ部の直前にある空行をみつけるため、０ｘ０ｄ０ａ０ｄ０ａというパターンを検索。３行目では、みつかった０ｘ０ｄ０ａ０ｄ０ａのパターンに続くボディ部の先頭から受信データのエンドまでを、データ要素“ＰｒｍＨｔｔｐＢｏｄｙ”に格納。４行目では送信バッファにデータ要素“ＰｒｍＨｔｔｐＢｏｄｙ”の内容をコピー。５行目ではノード６００で定義した“Ｓｅｒｖｉｃｅ１”のソケット情報を用いてサーバ・アプリケーションＡ３００と通信し、送信バッファの内容を送信し、応答データを受信して受信バッファに格納。６行目では送信バッファに正常応答用ヘッダ“ＰｒｍＯＫＨｅａｄｄｅｒ”と受信バッファの内容をコピー。７行目で正常リタンして送信バッファの内容を、応答データとしてクライアント・アプリケーション１００に送信。８行目は当該ノードの終りを示す。
【００２５】
ノード６０４は、スクリプト処理中にエラーが発生した場合の処理を示しており、エラーメッセージを組立ててクライアント・アプリケーション１００に応答している。１行目はノード名“ＮｏｄｅＥｒｒｏｒ”の定義。２行目では送信バッファに異常応答用ヘッダ“ＰｒｍＮＧＨｅａｄｄｅｒ”の内容をコピー。３行目でエラーリタンして送信バッファの内容を、応答データとしてクライアント・アプリケーション１００に送信。４行目は当該ノードの終りを示す。
【００２６】
図８は、本実施例におけるメッセージ中継定義２２１−２の内容を示したものである。太字で記述した部分がメッセージ中継定義２２１−１からの変更点であり、メッセージ中継システム２００にサーバ・アプリケーションＢ４００を追加して接続する際に必要な処理を示している。以下、メッセージ中継定義２２１−１からの変更点について説明する。
【００２７】
まずノード６００−１では、サーバ・アプリケーションＢ４００と通信するためのサービス定義を追加している。ノード６００からの変更箇所は１３行目以降で、１３行目はサーバ・アプリケーションＢ４００と通信するためのソケットに設定する情報の組である“Ｓｅｒｖｉｃｅ２”の定義、１４行目は当該サービスの第１の要素であるホスト名の定義、１５行目は当該サービスの第２の要素であるポート番号の定義、１６行目は当該サービス定義の終りを示す。
【００２８】
次に、ノード６０３−１では、受信メッセージを判定し、サーバ・アプリケーションＡ３００にメッセージを送信するか、サーバ・アプリケーションＢ４００にメッセージを送信するかを選択する処理を追加している。ノード６０３からの変更箇所は、５行目から８行目にかけてであり、５行目ではデータ要素“ＰｒｍＨｔｔｐＦｉｌｅ”の値が“／ＳＲＶ１”の場合、６行目のサーバ・アプリケーションＡ３００と通信する処理を行う。６行目ではノード６００−１で定義した“Ｓｅｒｖｉｃｅ１”のソケット情報を用いてサーバ・アプリケーションＡ３００と通信し、送信バッファの内容を送信し、応答データを受信して受信バッファに格納。７行目ではデータ要素“ＰｒｍＨｔｔｐＦｉｌｅ”の値が“／ＳＲＶ２”の場合、８行目のサーバ・アプリケーションＢ４００と通信する処理を行う。８行目ではノード６００−１で定義した“Ｓｅｒｖｉｃｅ２”のソケット情報を用いてサーバ・アプリケーションＢ４００と通信し、送信バッファの内容を送信し、応答データを受信して受信バッファに格納。データ要素“ＰｒｍＨｔｔｐＦｉｌｅ”の値が“／ＳＲＶ１”でも“／ＳＲＶ２”でもなかった場合、クライアント・アプリケーション１００から受信したデータのボディ部のそのまま応答データとして送信する。
ノード６０１、ノード６０３およびノード６０４では、メッセージ中継定義２２１−１からの変更は無い。
【００２９】
図９は、当初はクライアント・アプリケーション１００とサーバ・アプリケーションＡ３００の間のメッセージ中継が行われており、これにサーバ・アプリケーションＢ４００を追加するケースの実施例における運用のフローチャートを示している。
まずステップ７０１で、追加するサーバ・アプリケーションＢ４００と通信するための対サーバ・アプリケーションＢ通信制御部２４０を起動する。次にステップ７０２で、メッセージ中継定義をクライアント・アプリケ−ション１００とサーバ・アプリケーションＡ３００との間の中継だけを行うメッセージ中継定義２２１−１から、サーバ・アプリケーションＢ４００への中継を追加したメッセージちゅ中継定義２２１−２に変更する。これによりサーバ・アプリケーションＢ４００の追加が完了する。
【００３０】
図１０は、当初はクライアント・アプリケーション１００とサーバ・アプリケーションＡ３００の間のメッセージ中継が行われており、これをサーバ・アプリケーションＢ４００に変更するケースの実施例における運用のフローチャートを示している。
まずステップ７１１で、追加するサーバ・アプリケーションＢ４００と通信するための対サーバ・アプリケーションＢ通信制御部２４０を起動する。次にステップ７１２で、メッセージ中継定義をクライアント・アプリケ−ション１００とサーバ・アプリケーションＡ３００との間の中継だけを行うメッセージ中継定義２２１−１から、クライアント・アプリケ−ション１００とサーバ・アプリケーションＢ４００との間の中継だけを行うメッセージ中継定義２２１−３に変更する。続いてステップ７１３とステップ７１４で、すべての更新受付フラグの値が更新指示フラグの値と等しくなるまで、一定の時間間隔で更新受付フラグと更新指示フラグを監視しながら待つ。そしてすべての更新受付フラグの値が更新指示フラグの値と等しくなったら、サーバ・アプリケーションＢ４００との通信は発生しなくなるため、ステップ７１５で、サーバ・アプリケーションＡ３００との通信を行うための対サーバ・アプリケーションＡ通信制御部２３０を停止する。これによりサーバ・アプリケーションＡ３００からサーバ・アプリケーションＢ４００への変更が完了する。
【００３１】
以上によれば、複数アプリケーション間のメッセージ交換を中継するメッセージ中継システムにおいて、アプリケーションの追加や変更などを、システム全体の通信を停止せずに実行可能とすることができる。
【００３２】
また、メッセージ中継に際してアプリケーション間で異なる通信手順やメッセージフォーマットを一旦標準の通信手順とメッセージフォーマットに変換することなく直接変換できるため、メッセージ中継システムとしてのパフォーマンスを向上させることができる。
【００３３】
【発明の効果】
本発明によれば、複数プログラム間のメッセージ交換を中継するメッセージ中継装置にて、プログラムの追加や変更などについて、システムにおける通信への影響を少なくすることができる。
【図面の簡単な説明】
【図１】本発明のシステム実施例
【図２】メッセージ中継制御部の詳細構成例
【図３】メッセージ中継定義管理部のメッセージ定義更新フロー
【図４】メッセージ中継制御部のメッセージ定義更新フロー
【図５】本実施例におけるメッセージ中継システム状態
【図６】本実施例におけるメッセージ中継定義の定義スクリプト一覧
【図７】本実施例におけるメッセージ中継定義２２１−１の定義内容
【図８】本実施例におけるメッセージ中継定義２２１−２の定義内容
【図９】本実施例においてサーバ・アプリケーションＢ４００を追加する場合のフロー
【図１０】本実施例においてサーバ・アプリケーションＡ３００をサーバアプリケーションＢ４００に変更する場合のフロー
【符号の説明】
１００…クライアント・アプリケーション
２００…メッセージ中継システム
２１０…対クライアント・アプリケーション通信制御部
２２０…メッセージ中継制御部
２２１…メッセージ中継定義
２２２…受信メッセージ解析機能
２２３…メッセージルーティング機能
２２４…送信メッセージ組立機能
２３０…対サーバ・アプリケーションＡ通信制御部
２４０…対サーバ・アプリケーションＢ通信制御部
３００…サーバ・アプリケーションＡ
４００…サーバ・アプリケーションＢ
【図１】
2005025487.tif 000003
【図２】
2005025487.tif 000004
【図３】
2005025487.tif 000005
【図４】
2005025487.tif 000006
【図５】
2005025487.tif 000007
【図６】
2005025487.tif 000008
【図７】
2005025487.tif 000009
【図８】
2005025487.tif 000010
【図９】
2005025487.tif 000011
【図１０】
2005025487.tif 000012