(57)【要約】      （修正有）【課題】サービス指向アーキテクチャによる処理システムに適用して最適なバス型メッセージ交換システムを提供する。【解決手段】クライアントとメッセージバスとの間に配置したクライアント用プロトコルコネクタと、前記メッセージバス上のサービス部と前記メッセージバスとの間にそれぞれ配置したサービス用プロトコルコネクタとを有している。前記クライアント用プロトコルコネクタは、前記クライアントから送信された通信データに、前記メッセージバス内での経路情報を付加して、その通信データを前記メッセージバスへ送信するものであり、前記サービス用プロトコルコネクタは、前記メッセージバスから送信された前記通信データから自装置宛の処理データを取り出して、これを自装置の前記サービス部に送信し、前記サービス部から処理データに、自装置に続く次のサブプロトコルコネクタへの宛先情報を付加して前記メッセージバスに送信するものである。【選択図】図１
2010231539.tif 000002
【特許請求の範囲】
【請求項１】
メッセージバス上に連繋させた２以上のサービス部とクライアントとの間で前記メッセージバスに通してメッセージの交換を行うバス型メッセージ交換システムであって、
前記クライアントと前記メッセージバスとの間に配置したクライアント用プロトコルコネクタと、
前記サービス部と前記メッセージバスとの間にそれぞれ配置したサービス用プロトコルコネクタとを有し、
前記クライアント用プロトコルコネクタは、前記クライアントから送信された通信データに、前記メッセージバス内での経路情報を付加して、その通信データを前記メッセージバスへ送信するものであり、
前記サービス用プロトコルコネクタは、前記メッセージバスから送信された前記通信データから自装置宛の処理データを取り出して、これを自装置の前記サービス部に送信し、前記サービス部から処理データに、自装置に続く次のサブプロトコルコネクタへの宛先情報を付加して前記メッセージバスに送信するものであることを特徴とするバス型メッセージ交換システム。
【請求項２】
前記クライアント用プロトコルコネクタは、前記クライアントからの通信データと同一言語により前記経路情報を記述して前記通信データを作成する請求項１に記載のバス型メッセージ交換システム。
【請求項３】
前記クライアント用プロトコルコネクタは、前記経路情報を自己管理し、その経路情報を前記通信データに付加するものである請求項２に記載のバス型メッセージ交換システム。
【請求項４】
前記クライアント用プロトコルコネクタは、前記クライアントからの通信データと異なる言語により前記経路情報を記述して前記通信データを作成する請求項１に記載のバス型メッセージ交換システム。
【請求項５】
前記経路情報をデータベースとして管理する記憶部を有し、
前記クライアント用プロトコルコネクタは、前記記憶部が管理する経路情報を読み出して前記通信データに付加するものである請求項４に記載のバス型メッセージ交換システム。
【請求項６】
メッセージバス上に連繋させた２以上のサービス部とクライアントとの間で前記メッセージバスに通してメッセージの交換を行うバス型メッセージ交換方法であって、
前記クライアントからの通信データをクライアント用プロトコルコネクタで受信し、前記通信データに前記メッセージバス内での経路情報を前記クライアント用プロトコルコネクタで付加することにより、その通信データを前記メッセージバスに送信し、
前記メッセージバスからの前記通信データをサービス用プロトコルコネクタで受信し、前記メッセージバスから送信された前記通信データから自装置宛の処理データを前記サービス用プロトコルコネクタで取り出して、これを自装置の前記サービス部に送信し、前記サービス部から処理データに、自装置に続く次のサービス用プロトコルコネクタへの宛先情報を付加して前記メッセージバスに送信することを特徴とするバス型メッセージ交換方法。
【請求項７】
前記クライアントからの通信データと同一言語により前記経路情報を記述して前記通信データを作成する請求項６に記載のバス型メッセージ交換方法。
【請求項８】
前記クライアントからの通信データと異なる言語により前記経路情報を記述して前記通信データを作成する請求項６に記載のバス型メッセージ交換方法。
【請求項９】
メッセージバス上に連繋させた２以上のサービス部とクライアントとの間で前記メッセージバスに通して行われるメッセージの交換を制御するバス型メッセージ交換プログラムであって、
コンピュータに、
前記クライアントからの通信データを受信し、前記通信データに前記メッセージバス内での経路情報を付加することにより、その通信データを前記メッセージバスに送信する機能と、
前記メッセージバスからの前記通信データを受信し、前記メッセージバスから送信された前記通信データから自装置宛の処理データを取り出して、これを自装置の前記サービス部に送信し、前記サービス部から処理データに、自装置に続く次のサブプロトコルコネクタへの宛先情報を付加して前記メッセージバスに送信する機能とを実行させることを特徴とするバス型メッセージ交換プログラム。
【請求項１０】
前記コンピュータに、
前記クライアントからの通信データと同一言語により前記経路情報を記述して前記通信データを作成する機能を実行させる請求項９に記載のバス型メッセージ交換プログラム。
【請求項１１】
前記コンピュータに、
前記クライアントからの通信データと異なる言語により前記経路情報を記述して前記通信データを作成する機能を実行させる請求項９に記載のバス型メッセージ交換プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、バス型メッセージ交換システム、バス型メッセージ交換方法及びプログラム、特にサービス指向アーキテクチャ（以下、ＳＯＡという。ＳＯＡ：Service  Oriented  Architecture）による処理システムに適用して最適なバス型メッセージ交換システム、バス型メッセージ交換方法及びプログラムに関する。
【背景技術】
【０００２】
ネットワークには、特許文献１〜特許文献４に示す様な各種の通信ネットワークを構築して、処理を行う構成のものが開発されている。
【０００３】
近年、上述した通信ネットワークに代わって、ＳＯＡとよばれる大規模なコンピュータ・システムを構築する際の概念あるいは手法が取り上げられてきている。ＳＯＡはアプリケーションやシステムを一定の粒度（規模）を持ったサービスという抽象化された単位による集合として構築する方法論である。
【０００４】
前記ＳＯＡを実現する手段の１つとして様々な通信プロトコルの接続機能をもったＥＳＢ（Enterprise  Service  Bus）のような実装技術が考えられている。前記ＥＳＢはバス型のメッセージングエンジンであり、業務上の一処理に相当するソフトウェアの機能などをサービスという集合として扱う。さらに、前記ＥＳＢは、前記サービス同士を接続して送受信メッセージを仲介する役割を持ち、連携させることができる。
【０００５】
前記ＥＳＢは、バス型のネットワーク形式であるため、メッセージは必ずバスを通過する必要があり、バス自体の重要度は極めて高く、高い精度での安全性や信頼性が求められる。このため、必要以上の負荷をかけず、効率的に通信処理を行うシステムが必要となってきている。
【０００６】
前記ＳＯＡにおけるバス型メッセージ交換システムは、図１２に示す様に、クライアント１０１とメッセージバス１０２との間はプロトコルコネクタ１０３により接続され、前記メッセージバス１０２とサービス部１０５との間はプロトコルコネクタ１０４により接続されている。ここで、前記プロトコルコネクタ１０３は、クライアント１０１とメッセージバス１０２との間でデータの遣り取りを行うのに必要な通信プロトコルや接続方法などを採用している。また、前記プロトコルコネクタ１０４は、前記サービス部１０５が処理を実行するアプリケーションに依存する通信プロトコルや接続方法を採用している。
【０００７】
図１２に示すバス型メッセージ交換システムは図１３に示す様に、クライアント１０１側のプロトコルコネクタ１０３が、メーセージバス１０２上に連繋させた２以上のサービス部１０５に対応する複数のコネクタ４を呼び出す、いわゆる一対多になるような構成で複数のサービス部１０５を呼び出すことができない。
【０００８】
そこで、アプリケーションを実行する複数のサービス部１０３を呼び出す場合は、図１４に示す様に、経路や順番が設定されたリクエストに対して代行処理する仲介部６をメッセージバス２に配置している。そして、クライアント１０１からのリクエストを仲介部１０６で一旦受け付けて、その仲介部１０６が複数のサービス部１０５を予め設定した順番で呼び出す代行処理を構築している。具体的に説明すると、仲介部１０６は、クライアント１０１からのリクエストを受け取ったとき、予め設定された順番に則って、先ず、最初のサービス部５を呼出し、そのサービス部１０５からのレスポンス情報を受信した後、その情報に基づいて、順番及び条件により次のサービス部を呼び出す、という手順で複数のサービス部５を呼び出すことを実現している。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０００−０３２１４６号公報
【特許文献２】特開２００５−１４９５１５号公報
【特許文献３】特開２００６−２７７０９８号公報
【特許文献４】特開２００８−３０５４１１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかし、前記バス型メッセージ交換システムの場合、すべてのメッセージ（データを含む）がシステムの根幹にあるメーセージバス１０２を通過するため、仲介部１０６を経由した呼出し方法では、データ流量や同時接続数による全体のデータサイズが飛躍的に増える。例えば、図１４に示すの構成では、クライアント１０２のプロトコルコネクタ１０３との間での送受信、各サービス部１０５と仲介部１０６との間での送受信に計６回メッセージバス１０２を使用して通信をしていることになる。
【００１１】
クライアント１０１が利用するサービス部５の数が増えればその増えた分だけ、メッセージバス２を利用した通信の回数が天文学的に増加する。この状態では、前記バス型メッセージ交換システム内ではメモリ不足などリソースの枯渇が発生しやすい傾向になるという問題が発生する。これは、テスト環境や簡易的なシステムであれば影響は少ないが、大規模なシステムで大量のメッセージをやりとりする場合、システム自体の不調を招く可能性があり、改善すべき問題である。
【００１２】
本発明の目的は、特にサービス指向アーキテクチャ（以下、ＳＯＡという。ＳＯＡ：Service  Oriented  Architecture）による処理システムに適用して最適なバス型メッセージ交換システム、バス型メッセージ交換方法及びプログラムを提供することにある。
【課題を解決するための手段】
【００１３】
前記目的を達成するため、本発明に係るバス型メッセージ交換システムは、メッセージバス上に連繋させた２以上のサービス部とクライアントとの間で前記メッセージバスに通してメッセージの交換を行うバス型メッセージ交換システムであって、
前記クライアントと前記メッセージバスとの間に配置したクライアント用プロトコルコネクタと、前記サービス部と前記メッセージバスとの間にそれぞれ配置したサービス用プロトコルコネクタとを有し、
前記クライアント用プロトコルコネクタは、前記クライアントから送信された通信データに、前記メッセージバス内での経路情報を付加して、その通信データを前記メッセージバスへ送信するものであり、前記サービス用プロトコルコネクタは、前記メッセージバスから送信された前記通信データから自装置宛の処理データを取り出して、これを自装置の前記サービス部に送信し、前記サービス部から処理データに、自装置に続く次のサービス用プロトコルコネクタへの宛先情報を付加して前記メッセージバスに送信するものであることを特徴とする。
【００１４】
以上では、本発明をハードウェアとしてのバス型メッセージ交換システムとして構築した場合を説明したが、これに限られるものではない。本発明は、バス型メッセージ交換方法、或いはソフトウェアとしてのバス型メッセージ交換プログラムとして構築してもよいものである。
【００１５】
本発明をバス型メッセージ交換方法として構築した場合、その本発明に係るバス型メッセージ交換方法は、メッセージバス上に連繋させた２以上のサービス部とクライアントとの間で前記メッセージバスに通してメッセージの交換を行うバス型メッセージ交換方法であって、
前記クライアントからの通信データをクライアント用プロトコルコネクタで受信し、前記通信データに前記メッセージバス内での経路情報を前記クライアント用プロトコルコネクタで付加することにより、その通信データを前記メッセージバスに送信し、
前記メッセージバスからの前記通信データをサービス用プロトコルコネクタで受信し、前記メッセージバスから送信された前記通信データから自装置宛の処理データを前記サービス用プロトコルコネクタで取り出して、これを自装置の前記サービス部に送信し、前記サービス部から処理データに、自装置に続く次のサービス用プロトコルコネクタへの宛先情報を付加して前記メッセージバスに送信する構成として構築する。
【００１６】
本発明をバス型メッセージ交換プログラムとして構築した場合、その本発明に係るバス型メッセージ交換プログラムは、メッセージバス上に連繋させた２以上のサービス部とクライアントとの間で前記メッセージバスに通して行われるメッセージの交換を制御するバス型メッセージ交換プログラムであって、
コンピュータに、
前記クライアントからの通信データを受信し、前記通信データに前記メッセージバス内での経路情報を付加することにより、その通信データを前記メッセージバスに送信する機能と、
前記メッセージバスからの前記通信データを受信し、前記メッセージバスから送信された前記通信データから自装置宛の処理データを取り出して、これを自装置の前記サービス部に送信し、前記サービス部から処理データに、自装置に続く次のサービス用プロトコルコネクタへの宛先情報を付加して前記メッセージバスに送信する機能とを実行させる構成として構築する。
【発明の効果】
【００１７】
本発明によれば、複数のサービス部を実行する際の経路、順番などを通信データ自体に埋め込むことにより、仲介の代行処理をするシーケンサを用意することなく、通信する回数を減らすことができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施形態１に係るバス型メッセージ交換システムを示す構成図である。
【図２】本発明の実施形態１に係るバス型メッセージ交換システムの動作を示す通信データの流れを示す図である。
【図３】本発明の実施形態１に係るバス型メッセージ交換システムにおけるクライアント用プロトコルコネクタの内部構成を示す図である。
【図４】メッセージバス内に向けて送信される通信データの一例を示す図である。
【図５】本発明の実施形態１に係るバス型メッセージ交換システムにおけるサービス用プロトコルコネクタの内部構成を示す図である。
【図６】サービス部相互間で送信される通信データを示す図である。
【図７】本発明の実施形態１に係るバス型メッセージ交換システムにおけるサービス用プロトコルコネクタの内部構成を示す図である。
【図８】本発明の実施形態１に係るバス型メッセージ交換システムの全体の動作を示すシーケンス図である。
【図９】本発明の実施形態２に係るバス型メッセージ交換システムを示す構成図である。
【図１０】本発明の実施形態２に係るバス型メッセージ交換システムにおけるクライアント用プロトコルコネクタの内部構成を示す図である。
【図１１】メッセージバス内に向けて送信される通信データの一例を示す図である。
【図１２】関連する技術に係るバス型メッセージ交換システムを示す構成図である。
【図１３】関連する技術に係るバス型メッセージ交換システムの動作を示す通信データの流れを示す図である。
【図１４】関連する技術に係るバス型メッセージ交換システムの動作を示す通信データの流れを示す図である。
【発明を実施するための形態】
【００１９】
以下、本発明の実施形態を図に基づいて詳細に説明する。
【００２０】
本発明の実施形態の基本的な原理について説明する。図１２に示す構成における課題を解決する方式としては、ハードウェアの交換や、バス型メッセージ交換システムの性能を改善するなどの直接的方法のほかに、メッセージバス内部を流れるメッセージの流量を減らすことが考えられる。
【００２１】
メッセージバス内を流れるメッセージの流量を減らすには、１メッセージあたりのサイズを減らす、または通信するメッセージの数自体を減らす方法がある。前者については、通信プロトコル、サービス部で実行されるアプリケーションの通信データに依存し、後者はメッセージの送受信、特に複数のアクセス箇所に対しての送受信モデルにより増減する。メッセージサイズにより違いはあるが、一般的に通信するメッセージの数を減らした方が負荷を低減するインパクトは大きい。
【００２２】
本発明の実施形態は、メッセージの通信回数を減らすことを意図したものであり、仲介部の仲介によって複数のサービスを呼び出す方式に代えて、メッセージバス上に連繋された２以上のサービス部相互間において直前のサービス部が次のサービス部を呼び出す方式を採用することにより、メッセージバスを利用した通信を行うように構築したものである。具体例を用いて、本発明の実施形態を詳細に説明する。
（実施形態１）
【００２３】
本発明の実施形態１に係るバス型メッセージ交換システムは図１に示す様に、メッセージバス１上に連繋させた２以上のサービス部２１，２２・・・２ｎとクライアント３との間で前記メッセージバス１に通してメッセージの交換を行うバス型メッセージ交換システムを対象とするものである。前記サービス部２１，２２・・・２ｎは、業務上の一処理に相当する単位でアプリケーションソフトウェアをそれぞれ実行するものであり、前記サービス部２１，２２・・・２ｎをメッセージバス１上に連繋させることにより、業務上の処理を一貫して実行するシステムの全体を構築している。
【００２４】
そして、本発明の実施形態１は図１に示す様に、前記クライアント３と前記メッセージバス１との間に配置したクライアント用プロトコルコネクタ４と、前記サービス部２１，２２・・・２ｎと前記メッセージバス１との間にそれぞれ配置したサービス用プロトコルコネクタ５１，５２，・・・５ｎとを有している。以下の説明では、前記サービス部２１，２２・・・２ｎとして２台のサービス部２１，２２を用い、それに対応させて２台のサービス用プロトコルコネクタ５１，５２を組み合わせた例について説明するが、前記サービス部２１，２２・・・２ｎと前記サービス用プロトコルコネクタ５１，５２，・・・５ｎとの設置台数は図１に示すものに限られないものであり、これらは業務の処理容量等によって増減するものである。この場合、呼び出されるサービス用プロトコルコネクタ５１，５２，・・・５ｎとサービス部２１，２２・・・２ｎとのペアとしては、処理数、例えば業務の処理を実行する数に相当するペアの数だけ存在する。
【００２５】
前記プロトコルコネクタ４、５１，５２，・・・５ｎは、クライアント３とメッセージバス１、またはサービス部２１，２２・・・２ｎとメッセージバス１を繋ぐためのものであり、サービス部２１，２２・・・２ｎに接続されるプロトコルコネクタ５１，５２，・・・５ｎは、関連付けられたサービス部２１，２２・・・２ｎを呼び出すための情報、例えばＨＴＴＰプロトコルで通信するならばＵＲＬ情報や、リクエストに必要なメッセージデータの構成、返却データの構成などを有している。
【００２６】
前記クライアント用プロトコルコネクタ４は、前記クライアント２から送信された通信データＤ１に、前記メッセージバス２内での経路情報Ｄ２を付加し、これをメッセージバス１内を通信するためのデータ形式に変換して通信データＤ３として前記メッセージバス２へ送信するものである。前記サービス用プロトコルコネクタ５１，又は５２のうち例えば前記サービス用プロトコルコネクタ５１は、前記メッセージバス２から送信された前記通信データＤ３から自装置宛の処理データＤ４を取り出して、これを自装置の前記サービス部２１に送信し、前記サービス部２１から処理データＤ５に、自装置に続く次のサービス部２２に対応するサービス用プロトコルコネクタ５２への宛先情報Ｄ６を付加し、これをメッセージバス１内を通信するためのデータ形式に変換して通信データＤ７として前記メッセージバス２に送信するものである。
【００２７】
なお、前記サービス用プロトコルコネクタ５１，５２・・・５ｎは、対応する前記サービス部２１，２２・・・２ｎがそれぞれ実行するアプリケーションソフトウェアに依存する通信プロトコル及びメッセージバス２で用いる通信プロトコルを使用して、メッセージバス２との間で通信データＤ３，Ｄ７の遣り取りを行うものであり、前記サービス用プロトコルコネクタ５１，５２・・・５ｎを介して接続されるバス型メッセージ交換システムの特性として様々な通信プロトコルを受信可能なように、複数の種類のサービス用プロトコルコネクタ５１，５２・・・５ｎを用意している。
【００２８】
さらに、図３、図５及び図７を用いて、各プロトコルコネクタについて詳細に説明する。
【００２９】
前記クライアントプロトコル４は図３に示す様に、リクエスト受信機能部４ａと、バス内通信データ作成機能部４ｂと、バス内送信機能部４ｃとを有している。また、実施形態１における前記クライアント用プロトコルコネクタ３は図３に示す様に、前記経路情報Ｄ２を経路ファイル４ｄに記録して自己管理し、その経路情報Ｄ２を前記通信データＤ１に付加するものである。
【００３０】
前記リクエスト受信機能部４ａは、クライアント１からのリクエストメッセージを受け取ってクライアント１からの通信データＤ１を受信するものである。
【００３１】
前記バス内通信データ作成機能部４ｂは、前記リクエスト受信機能部４ａから通信データＤ１を受信した際、経路ファイル４ｄからメッセージバス１内の経路情報Ｄ２を取得して、この経路情報Ｄ２を前記通信データＤ１に付加して通信データＤ３（Ｄ１＋Ｄ２）を作成する。前記バス内通信データ作成機能部４ｂは、実際の通信に必要なデータ（例えば図４の＜／ｍｅｓｓａｇｅ＞の欄に記述するデータ）と、経路情報Ｄ２（例えば図４の＜／ｒｏｕｔｅ＞の欄に記述するデータ）とを同一言語、例えば図４に示す様なＸＭＬ形式で通信データＤ３を作成する。具体的に説明すると、前記バス内通信データ作成機能部４ｂは、例えば図４に示す様にＸＭＬ形式で通信データＤ３を作成する場合、＜／ｍｅｓｓａｇｅ＞の欄に、本来メッセージバス１で通信すべきメッセージ（前記実際の通信に必要なデータ）の内容を記載し、＜／ｒｏｕｔｅ＞の欄に、最初に通信データＤ３をメッセージバス１に通してサービス部２１に送信し、次いでサービス部２２に送信することを示す経路情報Ｄ２を通信データＤ１に付加して通信データＤ３を作成する。なお、通信データＤ３を作成する形式（言語等）は、ＸＭＬ形式に限られるものではない。
【００３２】
前記バス内送信機能部４ｃは、前記バス内通信データ作成機能部４ｂが作成した通信データＤ３をメッセージバス１内に送信するものである。
【００３３】
前記メッセージバス１は、バス型メッセージ交換システムの中心となる構成であり、クライアント用プロトコルコネクタ４を介して送信された通信データＤ３を受け取り、その通信データＤ３に記述された情報に基づいて宛先となるサービス部２１又は２２が接続されているサービス用プロトコルコネクタ５１又は５２を呼び出す機能を有している。具体的には、前記メッセージバス１は図３、図５及び図７に示す様に、クライアント用プロトコルコネクタ３からの通信データＤ３を受信するバス内受信機能部１ａと、サービス部２１との間に通信データＤ３，Ｄ７の遣り取りを行うバス内送信機能部１ｂ及びバス内受信機能部１ｃと、サービス部２２との間に通信データＤ７，Ｄ１１の遣り取りを行うバス内送信機能部１ｄ及びバス内受信機能部１ｅとを有している。
【００３４】
そして、前記バス内受信機能部１ａとバス内送信機能部１ｂとは、前記メッセージバス１を介して通信データＤ３の遣り取りを行うものである。また、前記バス内受信機能部１ｃと前記バス内送信機能部１ｄとは、前記メッセージバス１を介して通信データＤ７の遣り取りを行うものである。また、前記バス内受信機能部１ｅと前記クライアント用プロトコルバス４とは、前記メッセージバス１を介して通信データＤ１１の遣り取りを行うものである。なお、前記クライアント用プロトコルバス４が前記バス内受信機能部１ｅからの通信データＤ１１を受信し、その受信した通信データＤ１１からサービス部２１，２２による処理済みのデータを抽出し、そのデータをクライアント３に送信する過程は、図１２等に示す構成と同様であり、その構成に特徴がないため、図示するのを省略している。
【００３５】
次に、前記サービス用プロトコルコネクタ５１，５２について説明する。これらのサービス用プロトコルコネクタ５１，５２は、その内部構成が同一であって、接続対象のサービス部２１，２２が異なることによってその機能の一部に相違する点を有しているため、その内部構成については同一符号を付して説明する。
【００３６】
前記サービス用プロトコルコネクタ５１，５２は図５及び図７に示す様に、バス内受信機能部５ａと、データ取り出し機能部５ｂと、リクエスト送受信機能部５ｃと、バス内通信データ作成機能部５ｄと、バス内送信機能部５ｅとを有している。
【００３７】
前記バス内受信機能部５ａは、前記メッセージバス１内のバス内送信機能部１ｂ又は１ｄから送信された通信データＤ３又はＤ７を受信するものである。
【００３８】
前記データ取り出し機能部５ｂは、前記メッセージバス１内のバス内送信機能部１ｂ又は１ｄから送信された通信データＤ３又はＤ７から自装置宛の処理データＤ４又はＤ８を取り出すものである。前記リクエスト送受信機能部５ｃは、前記データ取り出し機能部５ｂから受け取った前記処理データＤ４又はＤ８を自装置の前記サービス部２１又は２２に送信するものである。具体的には、前記サービス用プロトコルコネクタ５１の前記リクエスト送受信機能部５ｃは、前記処理データＤ４を自装置である前記サービス部２１に送信し、前記サービス用プロトコルコネクタ５２の前記リクエスト送受信機能部５ｃは、前記処理データＤ８を自装置である前記サービス部２２に送信するものである。
【００３９】
また、前記リクエスト送受信機能部５ｃは、前記サービス部２１又は２２で処理された処理データＤ５又はＤ９を受信するものである。具体的には、前記サービス用プロトコルコネクタ５１の前記リクエスト送受信機能部５ｃは、前記サービス部２１で処理された処理データＤ５を受信し、前記サービス用プロトコルコネクタ５１の前記リクエスト送受信機能部５ｃは、前記サービス部２２で処理された処理データＤ９を受信するものである。
【００４０】
前記サービス用プロトコルコネクタ５１の前記バス内通信データ作成機能部５ｄは図５に示す様に、前記リクエスト送受信機能部５ｃからサービス部２１による処理データＤ５を受け取ると、前記処理データＤ５に次のサービス部２２に対応するサービス用プロトコルコネクタ５２を呼び出すための通信データＤ７を作成するものである。具体的には、前記サービス用プロトコルコネクタ５１の前記バス内通信データ作成機能部５ｃは、例えば図６に示す様にＸＭＬ形式で通信データＤ７を作成する場合、＜／ｍｅｓｓａｇｅ＞の欄に、本来メッセージバス１で通信すべきメッセージの内容を記載し、＜／ｒｏｕｔｅ＞の欄に、次のサービス部２２に送信することを示す経路情報Ｄ６を処理データＤ５に付加して通信データＤ７を作成する。なお、通信データＤ７を作成する形式は、ＸＭＬ形式に限られるものではない。
【００４１】
前記サービス用プロトコルコネクタ５２の前記バス内通信データ作成機能部５ｄは図７に示す様に、前記リクエスト送受信機能部５ｃからサービス部２２による処理データＤ９を受け取ると、前記処理データＤ９にクライアント用プロトコルコネクタ４を呼び出すための通信データＤ１１を作成するものである。
【００４２】
前記バス内送信機能部５ｃは、前記バス内通信データ作成機能部５ｂが作成した通信データＤ７又はＤ１１をメッセージバス１内に送信するものである。
【００４３】
次に、本発明の実施形態１に係るバス型メッセージ交換システムを用いてバス型メッセージ交換方法を実行する場合を、図１，図２，図３，図５，図７及び図８に基づいて説明する。
【００４４】
図２、図３及び図８に示す様に、クライアントプロトコル４はクライアント３との間に遣り取りを行い、前記クライアント３から複数のサービス部２１、２２を利用して例えば業務の処理の依頼を受けた場合、前記クライアントプロトコル４のリクエスト受信機能部４ａは、クライアント１からのリクエストメッセージを受け取ってクライアント１からの通信データＤ１を受信する。
【００４５】
次に、図３に示す様に、バス内通信データ作成機能部４ｂは、前記リクエスト受信機能部４ａから通信データＤ１を受信した際、経路ファイル４ｄからメッセージバス１内の経路情報Ｄ２を取得して（図８のステップＳ１）、この経路情報Ｄ２を前記通信データＤ１に付加して通信データＤ３（Ｄ１＋Ｄ２）を作成する（図８のステップＳ２）。そして、バス内送信機能部４ｃは、前記バス内通信データ作成機能部４ｂが作成した通信データＤ３をメッセージバス１内に送信する（図８のステップＳ３）。
【００４６】
前記メッセージバス１は、クライアント用プロトコルコネクタ４を介して送信された通信データＤ３を受け取り、その通信データＤ３に記述された情報に基づいて宛先となるサービス部２１が接続されているサービス用プロトコルコネクタ５１を呼び出す。具体的には、前記メッセージバス１のバス内受信機能部１ａは図３に示す様に、クライアント用プロトコルコネクタ４を介して送信された通信データＤ３を受け取り、その通信データＤ３の経路情報Ｄ２を参照して、最初のサービス部２１を呼び出すために、前記メッセージバス１のバス内送信機能部１ｂに前記通信データＤ３を送信する（図８のステップＳ４）。
【００４７】
前記メッセージバス１のバス内送信機能部１ｂは図５に示す様に、最初に呼び出すべきサービス部２１に対応するサービス用プロトコルコネクタ５１に向けて前記通信データＤ３を送信する（図８のステップＳ４）。
【００４８】
図５に示す様に、前記サービス用プロトコルコネクタ５１のバス内受信機能部５ａは、前記メッセージバス１内のバス内送信機能部１ｂから送信された通信データＤ３を受信する。そして、データ取り出し機能部５ｂは、前記メッセージバス１内のバス内送信機能部１ｂから送信された通信データＤ３から自装置宛の処理データＤ４を取り出す。リクエスト送受信機能部５ｃは、前記データ取り出し機能部５ｂから受け取った前記処理データＤ４を自装置の前記サービス部２１に送信する（図８のステップＳ５）。最初のサービス部２１は、前記処理データＤ４を受け取ると、その処理データＤ４をアプリケーションソフトウェアにより処理して（図８のステップＳ６）、その処理データＤ５を前記リクエスト送受信機能部５ｃに送信する（図８のステップＳ７）。
【００４９】
また、前記リクエスト送受信機能部５ｃは、前記サービス部２１で処理された処理データＤ５を受信した場合、その処理データＤ５をバス内通信データ作成機能部５ｄに送信する。前記バス内通信データ作成機能部５ｄは図５に示す様に、前記リクエスト送受信機能部５ｃからサービス部２１による処理データＤ５を受け取ると、前記処理データＤ５に次のサービス部２２に対応するサービス用プロトコルコネクタ５２を呼び出すための通信データＤ７を作成し、その通信データＤ７をバス内送信機能部５ｃに通してメッセージバス１内に送信する（図８のステップＳ８）。
【００５０】
前記メッセージバス１のバス内受信機能部１ｃは図５に示す様に、最初のサービス用プロトコルコネクタ５１から送信された通信データＤ７を受け取り、その通信データＤ７の経路情報Ｄ６を参照して、次のサービス部２２を呼び出すために、前記メッセージバス１のバス内送信機能部１ｄに前記通信データＤ７を送信する（図８のステップＳ９）。
【００５１】
前記メッセージバス１のバス内送信機能部１ｄは図７に示す様に、次に呼び出すべきサービス部２２に対応するサービス用プロトコルコネクタ５２に向けて前記通信データＤ７を送信する（図８のステップＳ９）。
【００５２】
図７に示す様に、前記サービス用プロトコルコネクタ５２のバス内受信機能部５ａは、前記メッセージバス１内のバス内送信機能部１ｄから送信された通信データＤ７を受信する。そして、データ取り出し機能部５ｂは、前記メッセージバス１内のバス内送信機能部１ｄから送信された通信データＤ７から自装置宛の処理データＤ８を取り出す。リクエスト送受信機能部５ｃは、前記データ取り出し機能部５ｂから受け取った前記処理データＤ８を自装置の前記サービス部２２に送信する（図８のステップＳ１０）。サービス部２２は、前記処理データＤ８を受け取ると、その処理データＤ８をアプリケーションソフトウェアにより処理して（図８のステップＳ１１）、その処理データＤ９を前記リクエスト送受信機能部５ｃに送信する（図８のステップＳ１２）。
【００５３】
また、前記リクエスト送受信機能部５ｃは、前記サービス部２２で処理された処理データＤ９を受信した場合、その処理データＤ９をバス内通信データ作成機能部５ｄに送信する。前記バス内通信データ作成機能部５ｄは図７に示す様に、前記リクエスト送受信機能部５ｃからサービス部２２による処理データＤ９を受け取ると、前記処理データＤ９にクライアント用プロトコルコネクタ４を呼び出すための経路情報Ｄ１０を付加して通信データＤ１１を作成し、その通信データＤ１１をバス内送信機能部５ｃに通してメッセージバス１内に送信する（図８のステップＳ１３）。
【００５４】
前記メッセージバス１は、サービス用プロトコルコネクタ５２から送信された通信データＤ１１を受け取り、その通信データＤ１１の経路情報Ｄ１０を参照して、クライアント用プロトコルコネクタ４に前記通信データＤ１１を送信する（図８のステップＳ１４）。
【００５５】
前記クライアント用プロトコルコネクタ４は、前記通信データｄ１１を受け取ると、サービス部２１，２２による処理結果をクライアント３に通知する。
【００５６】
以上説明したように、本発明の実施形態１によれば、既存のバス型メッセージ交換システムにおいて、仲介部によるシーケンサを利用して複数のサービスを呼び出す方式と比較して、以下の効果がある。
【００５７】
すなわち、本発明の実施形態１では、メッセージバスを通してプロトコルコネクタ相互間で通信される通信データに経路情報を組み込むことにより、プロトコルコネクタ相互間で通信を実現するため、既存のバス型メッセージ交換システムにおけるシステム内部での通信データの通信回数を低減することができる。また、メッセージバスに通信を仲介するための機構を必要としないため、前記仲介機構との通信が不要となるため、通信する回数自体が低減できる。この効果は、処理を行うサービス部の数が多くなれば多くなるほど顕著となる。
【００５８】
次に、メッセージの通信回数低減によるサービス部との遣り取り、及びそれに伴う内部データ量を低減できることとなり、これによりバス型メッセージ交換システム内で消費されるメモリ不足などリソースの枯渇の発生を抑制することができる。このことは、バス型メッセージ交換プログラムとして構築させてバス型メッセージ交換システムの機能を実行させる場合、前記プログラムを実行するＣＰＵの利用低減を実現することができることとなる。
【００５９】
（実施形態２）
本発明の実施形態１におけるクライアント用プロトコルコネクタ４の変形例を実施形態２として図９〜図１１に基づいて説明する。本発明の実施形態２では、実施形態１との相違点のみを説明する。その他の構成は実施形態１と同様である。
【００６０】
本発明の実施形態では、クライアント用プロトコルコネクタ４は図９及び図１０に示す様に、経路ファイル４ｄに代えて、経路取得機能部４ｅを有している。そして、前記経路ファイル４ｄに記録したメッセージバス１内での経路情報をデータベースとして記憶部１０に記憶させている。なお、前記経路取得機能部４ｅは、ネットワークなどを介して記憶部１０にアクセスすることにより、経路情報を取得するようにしてもよい。
【００６１】
前記クライアント用プロトコルコネクタ４がクライアント３からリクエストを受信した際、前記クライアント用プロトコルコネクタ４の経路取得機能部４ｅは図９及び図１０に示す様に、前記記憶部１０のデータベースにアクセスして、メッセージバス１内での経路情報Ｄ２を取得する。そして、前記クライアント用プロトコルコネクタ４のバス内通信データ作成機能部４ｂは、前記経路取得機能部４ｅからの経路情報Ｄ２を受け取って、これをクライアント３からの通信データＤ１に付加して、バス内送信機能が利用する通信データＤ３を作成する。
【００６２】
この場合、バス内通信データ作成機能部４ｂは、図１１に示す様な、実際に通信するデータＤ３１と、経路情報Ｄ２を記述したデータＤ３２との２つを内部パラメータとして有する通信データＤ３を作成する。この場合、前記バス内通信データ作成機能部４ｂは、経路情報Ｄ２の欄に、最初に通信データＤ３をメッセージバス１に通してサービス部２１に送信し、次いでサービス部２２に送信することを示す情報を記述する。
【００６３】
本発明の実施形態２によれば、通信データＤ３に含まれる、メッセージ内での通信に用いられるデータＤ３１と経路情報Ｄ２のデータとを異なる言語で記述するため、データＤ３１の記述に例えばＸＭＬ形式の言語を用いる必要がなく、データＤ３１として例えばバイナリデータなど、テキストではない情報を取り扱うことができる。
【産業上の利用可能性】
【００６４】
本発明によれば、バス型メッセージ交換システムをハードウェア／ソフトウェアで実装したネットワーク機器、アプリケーション／システムを統合するアプリケーションサーバソフトウェアに適用できる。また、複数のサービス部の仲介を提供するようなサービスプロバイダにも利用することが可能である。
【符号の説明】
【００６５】
１  メッセージバス
２１，２２  サービス部
３  クライアント
４  クライアント用プロトコルコネクタ
５１，５２  サーバ用プロトコルコネクタ
１０  記憶部
【図１】
2010231539.tif 000003
【図２】
2010231539.tif 000004
【図３】
2010231539.tif 000005
【図４】
2010231539.tif 000006
【図５】
2010231539.tif 000007
【図６】
2010231539.tif 000008
【図７】
2010231539.tif 000009
【図８】
2010231539.tif 000010
【図９】
2010231539.tif 000011
【図１０】
2010231539.tif 000012
【図１１】
2010231539.tif 000013
【図１２】
2010231539.tif 000014
【図１３】
2010231539.tif 000015
【図１４】
2010231539.tif 000016