JP2000353153A

JP2000353153A - メッセージ・ルーティング方法及びその実施装置並びにその処理プログラムを記録した記録媒体

Info

Publication number: JP2000353153A
Application number: JP11166466A
Authority: JP
Inventors: Yuji Mizote; 裕二溝手; Tetsuya Hashimoto; 哲也橋本; Tatsuto Aoshima; 達人青島; Makoto Kitagawa; 誠北川
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1999-06-14
Filing date: 1999-06-14
Publication date: 2000-12-19

Abstract

(57)【要約】【課題】サービス形態の動的変更やサービスユーザが
送信する任意のメッセージ形式に応じてルーティングを
行うことが可能な技術を提供する。【解決手段】プログラム間で送受信されるメッセージ
のルーティングを行うメッセージ・ルーティング方法に
おいて、メッセージの内容を解析し、メッセージにより
要求されたサービスを決定するステップと、サービスに
適合するサービスプロバイダを検索し、メッセージが要
求するサービスの処理を行うサービスプロバイダを決定
するステップとを有するものである。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はプログラム間のメッ
セージングにおけるメッセージルータに関し、特にサー
ビスを要求するサービスユーザプログラムのメッセージ
を、サービスの提供を行うサービスプロバイダプログラ
ムにルーティングするメッセージルータに適用して有効
な技術に関するものである。

【０００２】

【従来の技術】従来のクライアント・サーバシステム
は、サービスを要求するクライアントプログラムとサー
ビスを実行するサーバプログラムから構成され、クライ
アントはサーバに対してサービス実行の要求を行う。こ
の意味で、本明細書では、クライアントをサービスユー
ザと呼び、サーバをサービスプロバイダと呼ぶことにす
る。

【０００３】従来、サービスユーザ・プログラムがサー
ビスプロバイダ・プログラムにサービス要求を行う方式
として、次の２つの方式が知られている。それらは、送
信先サービスプロバイダ指定方式とトレーダ方式の２つ
である。

【０００４】送信先サービスプロバイダ指定方式は、サ
ービスユーザがサービスを提供するサービスプロバイダ
を直接指定してサービス要求を行うものであり、従来の
クライアント・サーバシステムで実現されている方式で
ある。例えば、ＯＭＧ（ＯｂｊｅｃｔＭａｎａｇｅｍ
ｅｎｔＧｒｏｕｐ）が規定したＴｈｅＣｏｍｍｏｎＯ
ｂｊｅｃｔＲｅｑｕｅｓｔＢｒｏｋｅｒ：Ａｒｃｈｉ
ｔｅｃｔｕｒｅａｎｄＳｐｅｃｉｆｉｃａｔｉｏｎ
（ＣＯＲＢＡ）を利用したアプリケーションの多くは、
オブジェクト間のメッセージ方式を、本方式で実現して
いる。ＣＯＲＢＡを利用したアプリケーションでは、サ
ービスユーザはサービスプロバイダのオブジェクト名或
いはインタフェース名を指定してサービスプロバイダと
のネットワーク接続を行い、サービス実行の要求を行
う。

【０００５】トレーダ方式は、サービスユーザ・プログ
ラム、サービスプロバイダ・プログラム及びサービスユ
ーザの要求を適切なサービスプロバイダにルーティング
するトレーダ・プログラムの３つを有する。トレーダ
は、サービス名、サービス属性及びそのサービスを提供
するサービスプロバイダのネットワーク位置情報等から
構成されるサービス情報を管理し、実行時にサービスユ
ーザがトレーダに対してサービスの問い合わせを行い、
問い合わせを満たすサービスプロバイダを解決する。こ
れにより、サービスユーザは利用したいサービスのみ意
識すれば良く、サービスプロバイダ構成の動的変更は、
サービスユーザに影響を与えない。トレーダ方式の例と
して、ＣＯＲＢＡＳｅｒｖｉｃｅｓのＯｂｊｅｃｔＴ
ｒａｄｉｎｇＳｅｒｖｉｃｅがある。

【０００６】ＯｂｊｅｃｔＴｒａｄｉｎｇＳｅｒｖｉ
ｃｅでは、サービスユーザをインポータと、サービスプ
ロバイダをエクスポータと呼ぶ。エクスポータは、自身
が提供するサービスに関する情報を決められた手順でト
レーダに登録する。一方、インポータはインポータが要
求するサービスをどのエクスポータが提供するのかを決
められた手順でトレーダに問い合わせ、トレーダはイン
ポータが要求するサービスからそのサービスを提供する
エクスポータを解決し、インポータは解決された前記エ
クスポータに対してメッセージを送信する。

【０００７】

【発明が解決しようとする課題】前記従来の送信先サー
ビスプロバイダ指定方式では、サービス自体には変更は
ないが、サービスを実現するサービスプロバイダの構成
が変更された場合、例えば、あるサービスを実現するサ
ービスプロバイダの入れ替えを行う場合等では、サービ
スユーザ側のプログラムになんらかの修正を加えない限
り、サービスユーザは旧サービスプロバイダにサービス
要求を行ってしまう為、サービスプロバイダ構成の動的
変更にサービスユーザが対応できないという問題があ
る。

【０００８】また、前記のトレーダ方式において、サー
ビスユーザは、トレーダとの間で決められた手順及びメ
ッセージ形式でサービス要求を行い、サービスプロバイ
ダを解決する必要がある為、独自の手順とメッセージ形
式を持つレガシーシステムは容易にトレーダに接続でき
ないという問題がある。

【０００９】例えば、銀行システムを従来の送信先サー
ビスプロバイダ指定方式から、より柔軟なシステム構成
であるトレーダ方式に変更しようとした場合、レガシー
システムであるＡＴＭ制御プログラムは、勘定系サーバ
と独自のメッセージ形式で接続しており、ＡＴＭ制御プ
ログラムを修正することなくトレーダと接続する為に
は、ＡＴＭ制御プログラムとトレーダとの間に中継プロ
グラムを開発する必要がある。この様な中継プログラム
を、接続するレガシーシステムのメッセージ形式毎に開
発する作業は、大変な手間のかかる作業である。

【００１０】また、前記従来の技術では、業務のサービ
ス形態が変わり、サービスプロバイダが受け付けるメッ
セージ形式が変更になった場合、サービスユーザ或いは
中継プログラムを修正する必要がある為、サービス形態
の変更が大変な作業となってしまうという問題がある。

【００１１】本発明の目的は上記問題を解決し、サービ
ス形態の動的変更やサービスユーザが送信する任意のメ
ッセージ形式に応じてルーティングを行うことが可能な
技術を提供することにある。

【００１２】

【課題を解決するための手段】本発明は、プログラム間
で送受信されるメッセージのルーティングを行うメッセ
ージルータにおいて、サービスユーザからのメッセージ
に対応するサービスに適合するサービスプロバイダへ当
該メッセージをルーティングするものである。

【００１３】本発明では、メッセージ・ルーティングを
制御する為の情報として、ルーティング対象となるメッ
セージのメッセージ形式定義、メッセージ中のデータに
関する制約条件を条件部として持つと共にメッセージが
要求するサービスが満たすべき条件であるサービス検索
条件を結論部として持つサービス決定ルール、サービス
とサービスプロバイダの対応やサービス属性を記述した
サービス情報の定義を行っておく。

【００１４】本発明のメッセージルータは、サービスを
受けるサービスユーザからのメッセージを受信すると、
そのメッセージを前記メッセージ形式定義に基づいて解
析し、前記メッセージ中のデータがサービス決定ルール
の条件部を満たすかを判定して前記メッセージに対応す
るサービスを決定する。次に前記サービス定義から前記
サービス検索条件を満たすサービスプロバイダを決定し
た後、決定したサービスプロバイダへ当該メッセージを
送信する。

【００１５】以上の様に本発明のメッセージルータによ
れば、サービスユーザからのメッセージに対応するサー
ビス検索条件を満たすサービスプロバイダへ当該メッセ
ージをルーティングするので、サービス形態の動的変更
やサービスユーザが送信する任意のメッセージ形式に応
じてルーティングを行うことが可能である。

【００１６】

【発明の実施の形態】以下にプログラム間で送受信され
るメッセージのルーティングを行う一実施形態のメッセ
ージルータについて説明する。

【００１７】本実施形態の説明において、コンテナ型デ
ータ及び定数ＮＵＬＬを用いる。定数ＮＵＬＬは、他の
任意のデータ値と区別することができる特別な値であ
る。コンテナ型データは、０個以上のデータを保持する
オブジェクトで、メソッドＦｉｒｓｔ、Ｎｅｘｔ、Ａｄ
ｄ、ＬｏｏｋＵｐにより操作される。Ａｄｄは、引数を
コンテナに加える。Ｆｉｒｓｔは、要素数が０の場合Ｎ
ＵＬＬ値を返し、１以上の場合先頭要素を返す。Ｎｅｘ
ｔはその次の要素を返し、次のデータが存在しない場合
はＮＵＬＬを返す。Ｆｉｒｓｔで先頭要素を取得し、Ｎ
ｅｘｔを繰り返し呼び出すことにより、コンテナ内に含
まれる要素を走査することができる。ＬｏｏｋＵｐは、
コンテナの要素が構造データであり主キー属性を持つ場
合、引数をキーとして持つ要素を検索する。引数をキー
として持つ要素が存在しない場合は、ＮＵＬＬ値を返
す。

【００１８】また、コンテナデータＳｏｍｅＤａｔａに
Ａｄｄメソッド等を引数ｄａｔａ適用する場合、Ｓｏｍ
ｅＤａｔａ．Ａｄｄ（ｄａｔａ）等と表記する。Ｓｏｍ
ｅＤａｔａ．ＬｏｏｋＵｐ（ｋｅｙＤａｔａ）を、Ｓｏ
ｍｅＤａｔａ［ｋｅｙＤａｔａ］と略記する。これら記
法は、図６から図１０のＰＡＤ図内で利用している。

【００１９】本実施形態では、次の機能を提供すること
により、前記問題を解決する。（１）メッセージ・ルーティング制御情報定義機能メッセージ・ルーティング制御情報定義機能は、ルーテ
ィング制御情報として、ルーティング対象となるメッセ
ージのメッセージ形式定義、サービス決定ルール及びサ
ービス定義を定義し編集する。

【００２０】（２）サービス決定機能サービス決定機能は、任意の形式のメッセージに対し
て、メッセージ形式定義及びサービス解決ルールに基づ
いて、メッセージを解析し、メッセージが要求するサー
ビスを決定する。

【００２１】（３）サービスプロバイダ決定機能サービスプロバイダ決定機能は、前記機能で解決したサ
ービスとサービス定義に基づいて、サービスプロバイダ
を決定する。サービスユーザが送信するメッセージ形式
とサービスプロバイダが受信するメッセージ形式が異な
る場合、必要に応じてメッセージ変換を行う。

【００２２】以降において、サービス決定機能及びサー
ビスプロバイダ決定機能で利用するデータ構造と処理フ
ローを説明した後、メッセージ・ルーティング制御情報
定義機能の画面イメージを説明する。

【００２３】図１は本実施形態のメッセージ・ルーティ
ングを行うシステムの概略構成を示す図である。図１に
示す様に本実施形態のメッセージルータ計算機１０１
は、メッセージ受信処理部１１０と、サービス決定処理
部１１１と、サービスプロバイダ決定処理部１１２と、
メッセージ送信処理部１１３と、登録情報編集処理部１
１４とを有している。

【００２４】メッセージ受信処理部１１０は、サービス
ユーザ計算機１０８からのメッセージ１２４及びメッセ
ージ１２４のメッセージ形式１２３を受信し、メッセー
ジ１２４及びメッセージ形式１２３を引数としてサービ
ス決定処理部１１１を起動する処理部である。

【００２５】サービス決定処理部１１１は、メッセージ
１２５の内容を解析し、メッセージ１２５により要求さ
れたサービスを決定する処理部である。サービスプロバ
イダ決定処理部１１２は、サービスに適合するサービス
プロバイダを検索し、メッセージ１２５が要求するサー
ビスの処理を行うサービスプロバイダを決定する処理部
である。

【００２６】メッセージ送信処理部１１３は、サービス
プロバイダ情報１１６に基づいてメッセージ１２５をサ
ービスプロバイダ計算機１０９に送信する処理部であ
る。登録情報編集処理部１１４は、２次記憶装置１０４
上のサービス決定ルールセット１２０、メッセージ形式
定義テーブル１２１、サービス定義テーブル１２２及び
メッセージ変換手続きテーブル１２７の定義情報の登録
及び変更を行う処理部である。

【００２７】メッセージルータ計算機１０１をメッセー
ジ受信処理部１１０、サービス決定処理部１１１、サー
ビスプロバイダ決定処理部１１２、メッセージ送信処理
部１１３及び登録情報編集処理部１１４として機能させ
る為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録
され磁気ディスク等に格納された後、メモリにロードさ
れて実行されるものとする。なお前記プログラムを記録
する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良
い。

【００２８】図１を利用してシステム構成と処理の概要
を説明する。サービスを利用するサービスユーザが動作
するサービスユーザ計算機１０８、サービスを提供する
サービスプロバイダが動作するサービスプロバイダ計算
機１０９及びサービスユーザ計算機１０８とサービスプ
ロバイダ計算機１０９を仲介するメッセージルータが動
作するメッセージルータ計算機１０１が、計算機ネット
ワーク１０７を介して接続される。サービスユーザ計算
機１０８及びサービスプロバイダ計算機１０９は、計算
機ネットワーク１０７上に複数存在して良いし、同一計
算機上に１つ以上のサービスユーザ、１つ以上のサービ
スプロバイダ或いは１つ以上のメッセージルータが動作
していて良い。

【００２９】メッセージルータ計算機１０１、サービス
ユーザ計算機１０８及びサービスプロバイダ計算機１０
９はいずれも、中央演算装置１０２、主記憶装置１０
３、２次記憶装置１０４、入出力装置１０５及び通信装
置１０６を有している。

【００３０】図１を利用して、メッセージルータ計算機
１０１の内部構成に関して説明する。主記憶装置１０３
には、プログラムとして、メッセージ受信処理部１１
０、メッセージ送信処理部１１３、サービス決定処理部
１１１、サービスプロバイダ決定処理部１１２、登録情
報編集処理部１１４が格納され、データとしてサービス
情報１１５、サービスプロバイダ情報１１６、サービス
決定ルールセット１１７、メッセージ形式定義テーブル
１１８、サービス定義テーブル１１９及びメッセージ変
換手続きテーブル１２６が格納される。

【００３１】２次記憶装置１０４には、データとして、
サービス決定ルールセット１２０、メッセージ形式定義
テーブル１２１、サービス定義テーブル１２２及びメッ
セージ変換手続きテーブル１２７が格納される。

【００３２】主記憶装置１０３上のデータであるサービ
ス決定ルールセット１１７、メッセージ形式定義テーブ
ル１１８、サービス定義テーブル１１９及びメッセージ
変換手続きテーブル１２６は、２次記憶装置１０４上の
サービス決定ルールセット１２０、メッセージ形式定義
テーブル１２１、サービス定義テーブル１２２及びメッ
セージ変換手続きテーブル１２７を主記憶装置１０３上
にロードしたものである。

【００３３】図１を利用して、本実施形態の全体処理手
順に関して説明する。サービスユーザ計算機１０８は、
計算機ネットワーク１０７を介してメッセージルータ計
算機１０１にサービス要求のメッセージ１２４及びメッ
セージ１２４のメッセージ形式１２３を送信する。メッ
セージルータ計算機１０１のメッセージ受信処理部１１
０は、通信装置１０６を介してメッセージ１２４及びメ
ッセージ形式１２３を受信し、メッセージ１２４及びメ
ッセージ形式１２３を引数としてサービス決定処理部１
１１を起動する。

【００３４】サービス決定処理部１１１は、サービス決
定ルールセット１１７とメッセージ形式定義テーブル１
１８を参照して、メッセージ１２４を解析し、サービス
ユーザ計算機１０８がメッセージ１２４により要求する
サービスのサービス情報１１５を決定し、サービス情報
１１５とメッセージ形式１２３を引数として、サービス
プロバイダ決定処理部１１２を起動する。

【００３５】サービスプロバイダ決定処理部１１２は、
サービス定義テーブル１１９からサービス情報１１５に
適合するサービスプロバイダを検索し、メッセージ１２
４が要求するサービスを処理するサービスプロバイダの
サービスプロバイダ情報１１６を決定する。必要に応じ
て、サービスプロバイダが受理できる形式にメッセージ
１２４のメッセージ変換を行い、メッセージ１２５を生
成する。メッセージ変換を行わない場合は、メッセージ
１２４とメッセージ１２５は同一内容を持つデータであ
る。

【００３６】メッセージ送信処理部１１３は、サービス
プロバイダ情報１１６に基づいてメッセージ１２５をサ
ービスプロバイダ計算機１０９に送信する。なお、メッ
セージ受信処理部１１０及びメッセージ送信処理部１１
３のメッセージ送受信部分に関してＣＯＲＢＡ等が利用
できる。

【００３７】また、システム１００の運用管理者は、入
出力装置１０５と登録情報編集処理部１１４を利用し
て、２次記憶装置１０４上のサービス決定ルールセット
１２０、メッセージ形式定義テーブル１２１、サービス
定義テーブル１２２及びメッセージ変換手続きテーブル
１２７の定義情報の登録及び変更を行う。

【００３８】以降において、本実施形態の構成要素であ
る処理フローとデータ構造について図１から図１０を利
用して、また、登録情報編集処理部１１４のツール画面
例について図１１から図１４を利用して説明する。処理
フローは、基本的にＰＡＤを用いて記述してあるが、処
理フローで参照するデータの図を必要に応じてＰＡＤ図
に付加してある。

【００３９】図１を用いて、サービス情報１１５、サー
ビスプロバイダ情報１１６、メッセージ形式１２３、メ
ッセージ１２４及びメッセージ１２５について説明す
る。

【００４０】サービス情報１１５は、サービス決定処理
部１１１の結果を格納する為に利用する一時変数であ
る。サービスプロバイダ情報１１６は、サービスプロバ
イダ決定処理部１１２の結果を保持する為に利用する一
時変数である。

【００４１】メッセージ１２４は、サービスユーザ計算
機１０８からメッセージルータ計算機１０１に送信され
るデータであり、メッセージ形式１２３は、メッセージ
１２４のメッセージ形式を示す識別子である。メッセー
ジ１２５は、メッセージルータ計算機１０１からサービ
スプロバイダ計算機１０９に送信されるデータである。

【００４２】図２は本実施形態のサービス決定ルールセ
ット１１７のデータ構造を示す図である。図３は本実施
形態のメッセージ形式定義テーブル１１８のデータ構造
を示す図である。図４は本実施形態のサービス定義テー
ブル１１９のデータ構造を示す図である。

【００４３】図２のサービス決定ルールセット１１７
は、メッセージ形式２０２、ルールの条件部として機能
する条件２０３、ルールの結論部として機能するサービ
ス情報２０４及びルール名２０５を有するサービス決定
ルール２０１を要素に持つコンテナである。

【００４４】メッセージ形式２０２は、メッセージ形式
定義テーブル１１８のメッセージ形式定義テーブルエン
トリ３０２のメッセージ形式３０３を参照する外部キー
である。

【００４５】条件２０３は、サービスを決定する為の条
件を表現する論理式である。本実施形態では、論理式を
次の様に定義する。論理演算子に対してオペランドであ
る論理変数と項の適用を意味する「論理変数論理演算
子項」という形式の表現は論理式である。更に、２つ
の論理式を論理結合子ＡＮＤとＯＲで連結したものは論
理式である。この２つの規則により生成される表現が論
理式である。条件２０３で利用できる論理変数は、メッ
セージ形式２０２で一意に特定されるメッセージ属性定
義３１２の属性名３１３とする。条件２０３で利用でき
る項は、文字列定数或いは整数値定数とする。論理演算
子として、＞（より大きい）、＝（等しい）、＜（より
小さい）、！＝（等しくない）、Ｌｉｋｅ（正規表現等
のパターンが一致する）、ＣＯＮＴＡＩＮ（を含む）等
が考えられる。例えば、「業務コード」及び「銀行コー
ド」がメッセージ形式定義の属性である場合、「業務コ
ード＝２ＡＮＤ銀行コード＝００２２」は、前記
定義と整合する論理式である。

【００４６】サービス情報２０４は、サービス定義テー
ブル１１９からサービスプロバイダ情報４０５を検索す
るときに利用する検索条件を論理式で表現したものであ
る。サービス情報２０４の論理式中で利用できる論理変
数は、サービス定義４０２のサービス４０３の名称及び
属性リスト４０４に含まれる属性名である。項は、文字
列定数、整数値定数或いはメッセージ形式２０２で一意
に特定されるメッセージ属性定義３１２の属性名３１３
である。論理演算子は、条件２０３と同様である。ルー
ル名２０５は、サービス決定ルールに対して付与した識
別子である。

【００４７】図３のメッセージ形式定義テーブル１１８
は、メッセージ形式３０３及びメッセージ形式定義３１
１への参照を有するメッセージ形式定義テーブルエント
リ３０２を要素に持つコンテナである。

【００４８】メッセージ形式３０３は、メッセージ形式
定義テーブル１１８の主キーであり、メッセージ形式定
義テーブルエントリ３０２を一意に特定する為の識別子
である。定義の参照３０４は、メッセージ形式定義３１
１へのポインタを保持する。

【００４９】メッセージ形式定義３１１は、属性名３１
３、型３１４及び型情報３１５を有するメッセージ属性
定義３１２を要素に持つコンテナである。属性名３１３
は、属性の名称を保持し、型３１４は属性の型を保持す
る。本実施形態では、型としてＳＴＲＩＮＧ（固定長文
字列）、ＢＹＴＥ（バイト）、ＩＮＴ３２（３２ビット
整数値）及びユーザ指定型（ＵＳＥＲ＿ＴＹＰＥ）があ
るものとする。メッセージ中のデータで、ユーザ独自処
理が必要となる部分がある場合、ユーザ指定型を利用す
る。型情報３１５は、型固有な補足情報を保持する。本
実施形態では、型情報としてＳＴＲＩＮＧ型に対しては
文字列の長さが、ユーザ指定型に対してはユーザ作成の
データ読み込み手続きに関する情報を保持するものとす
る。

【００５０】図４のサービス定義テーブル１１９は、サ
ービス４０３、属性リスト４０４、サービスプロバイダ
情報４０５及びメッセージ形式４０６を有するサービス
定義４０２を要素に持つコンテナである。サービス４０
３は、サービスを識別する為の識別子である。

【００５１】属性リスト４０４は、属性名と属性値を有
する属性値ペアを要素に持つコンテナであり、属性名は
属性リスト４０４の要素を一意に特定する為の主キーと
して機能する。サービスプロバイダ情報４０５は、サー
ビスプロバイダにメッセージを送信するのに必要なサー
ビスプロバイダのネットワーク上の論理的な位置情報で
ある。メッセージ送信処理部１１３にＣＯＲＢＡを利用
する場合、サービスプロバイダ情報４０５は、サービス
プロバイダのインタフェース名及びオブジェクト名等を
保持することになる。

【００５２】図５は本実施形態のメッセージ変換手続き
テーブル１２６のデータ構造を示す図である。メッセー
ジ変換手続きテーブル１２６は、変換元メッセージ形式
５０３、変換先メッセージ形式５０４及びメッセージ変
換手続き５０５を有するメッセージ変換手続きテーブル
エントリ５０２を要素に持つコンテナである。

【００５３】変換元メッセージ形式５０３は、変換の対
象となるメッセージのメッセージ形式３０３を参照する
外部キーである。変換先メッセージ形式５０４は、変換
した結果生成されるメッセージのメッセージ形式３０３
を参照する外部キーである。変換元メッセージ形式５０
３と変換先メッセージ形式５０４の組み合わせは、メッ
セージ変換手続きテーブル１２６の主キーであり、メッ
セージ変換手続きテーブルエントリ５０２を一意に特定
する。メッセージ変換手続き５０５は、メッセージ変換
の手続きを記述したものであり、ソースコード、コンパ
イルされた実行可能形式のプログラム或いは汎用変換エ
ンジンが解釈実行可能なスクリプト等のうちのいずれか
である。

【００５４】図６は本実施形態のサービス決定処理部１
１１の処理手順を示すフローチャートである。サービス
決定処理部１１１は、メッセージ受信処理部１１０で受
信したメッセージ１２４とメッセージ形式１２３を引数
として、メッセージ受信後に起動される。

【００５５】サービス決定処理部１１１は、一時変数と
してメッセージ属性値テーブル６０３を利用する。メッ
セージ属性値テーブル６０３は、属性名と属性値を有す
る属性値ペアを要素に持つコンテナであり、属性値ペア
の属性名は、メッセージ属性値テーブル６０３の主キー
である。また、メッセージ属性値テーブル６０３は、サ
ービスプロバイダ決定処理部１１２でも参照される。

【００５６】ステップ６０１において、サービス決定処
理部１１１は、メッセージ１２４とメッセージ形式１２
３を引数としてメッセージ解析処理を起動し、処理結果
をメッセージ属性値テーブル６０３に設定する。ステッ
プ６０２において、サービス決定処理部１１１は、メッ
セージ属性値テーブル６０３を引数としてサービス決定
ルール評価処理を起動する。

【００５７】図７は本実施形態のメッセージ解析処理の
処理手順を示すフローチャートである。メッセージ解析
処理７００は、メッセージ１２４を解析し、解析結果を
メッセージ属性値テーブル６０３に格納する処理であ
り、一時変数として、メッセージ形式定義３１１を格納
する一時変数Ｍ、メッセージ属性定義３１２を格納する
一時変数Ｐ及びメッセージ１２４の読み込み位置を保持
する一時変数Ｒを利用する。

【００５８】ステップ７０１において、メッセージ解析
処理７００は、メッセージ形式定義テーブル１１８から
メッセージ形式１２３をキーとしてメッセージ形式定義
３１１を検索し、取得したメッセージ形式定義３１１を
一時変数Ｍに代入する。

【００５９】分岐条件７０２において、ステップ７０１
でメッセージ形式定義が見つからなかった場合にはステ
ップ７０３を実行する。ステップ７０３においてメッセ
ージ解析処理７００は、「不明なメッセージである」と
いう例外メッセージを送出する。

【００６０】ステップ７０４において、一時変数Ｒに
「０」を代入し、ステップ７０５で一時変数ＰにＭの先
頭要素を代入する。そしてメッセージ解析処理７００
は、メッセージ形式定義Ｍに含まれる全ての属性定義Ｐ
に対して、ステップ７０７からステップ７１９を実行す
る。

【００６１】分岐条件７０７からステップ７１４におい
て、メッセージ解析処理７００は、属性定義Ｐの型、つ
まり「Ｐ．型」に応じて処理を分岐させる。すなわち分
岐条件７０７で属性定義Ｐの型がＢＹＴＥである場合に
メッセージ解析処理７００は、メッセージ１２４のＲバ
イト目から１バイトをバイトデータとして読み込み（ス
テップ７０８）、分岐条件７０９で属性定義Ｐの型がＩ
ＮＴ３２である場合にメッセージ解析処理７００は、メ
ッセージ１２４のＲバイト目から４バイトを３２ビット
整数値として読み込む（ステップ７１０）。

【００６２】また、分岐条件７１１で属性定義Ｐの型が
ＳＴＲＩＮＧである場合にメッセージ解析処理７００
は、メッセージ１２４のＲバイト目からＰの型情報つま
り「Ｐ．型情報」で指定された文字列数分の文字データ
を読み込み（ステップ７１２）、分岐条件７１３で属性
定義Ｐの型がＵＳＥＲ＿ＴＹＰＥである場合にメッセー
ジ解析処理７００は、「Ｐ．型情報」で指定されたデー
タ読み込み手続きを起動する。前記データ読み込み手続
きはメッセージ１２４のＲバイト目からデータとして読
み込み、読み込んだデータと読み込みだデータ長を結果
として返す（ステップ７１４）。

【００６３】分岐条件７１６で「０」より大きいデータ
の読み込みを行った場合にメッセージ解析処理７００
は、読み込んだデータをメッセージ属性値テーブル６０
３のＰの属性名つまり「Ｐ．属性名」に対応する属性値
として格納し（ステップ７１８）、読み込んだデータ長
をＲに加算する（ステップ７１９）。ステップ７２０で
は、一時変数ＰにＭの次の要素を代入し、繰り返し条件
７０６に戻って処理を続行する。

【００６４】図８は本実施形態のサービス決定ルール評
価処理の処理手順を示すフローチャートである。サービ
ス決定ルール評価処理８００は、一時変数としてサービ
ス決定ルールを保持する一時変数Ｒ、ブール値を保持す
る一時変数ＲｕｌｅＨｉｔを利用する。

【００６５】まずステップ８０１では、一時変数Ｒにサ
ービス決定ルールセット１１７の先頭要素を代入し、ス
テップ８０２では、一時変数ＲｕｌｅＨｉｔにＦＡＬＳ
Ｅを代入する。そしてステップ８０３からステップ８０
９において、サービス決定ルール評価処理８００は、サ
ービス決定ルールセット１１７に含まれる任意のサービ
ス決定ルールＲに対して、分岐条件８０４からステップ
８０９の処理を行う。但し、繰り返し条件８０３によ
り、途中でＲｕｌｅＨｉｔがＴＲＵＥになった時点で、
分岐条件８０４からステップ８０９の処理を抜け、ステ
ップ８１０に進む。

【００６６】分岐条件８０４でサービス決定ルール評価
処理８００は、Ｒのメッセージ形式つまり「Ｒ．メッセ
ージ形式」がメッセージ形式１２３と等しいかを判定す
る。等しい場合にはステップ８０６からステップ８０９
において、Ｒに対するルール評価処理を行う。

【００６７】ステップ８０６ではＲの条件２０３の論理
式を評価する。なお、この論理式中の論理変数はメッセ
ージ属性値テーブル６０３の属性値である。分岐条件８
０７において、ステップ８０６でのＲの条件２０３が成
立した場合には、Ｒのサービス情報２０４をサービス情
報１１５に代入し（ステップ８０８）、ＲｕｌｅＨｉｔ
にＴＲＵＥを代入する（ステップ８０９）。ステップ８
０５では、一時変数Ｒにサービス決定ルールセット１１
７の次の要素を代入し、繰り返し条件８０３に戻って処
理を続行する。

【００６８】前記繰り返し処理の後、分岐条件８１０で
ＲｕｌｅＨｉｔがＦＡＬＳＥの場合には「サービスプロ
バイダがみつからなかった」という例外メッセージを送
出する（ステップ８１１）。

【００６９】なお本実施形態のサービス決定ルール評価
処理８００では、条件２０３の論理式を逐次解釈するイ
ンタープリットを行う方法で説明しているが、条件２０
３からサービス決定ルール評価処理８００と同等の処理
を行うネイティブコードを予め生成しておく方法も考え
られる。

【００７０】図９は本実施形態のサービスプロバイダ決
定処理部１１２の処理手順を示すフローチャートであ
る。サービスプロバイダ決定処理部１１２は、一時変数
として、サービス定義４０２を保持する一時変数Ｓとブ
ール値を保持する一時変数Ｆｏｕｎｄを持つ。

【００７１】ステップ９０１においてサービスプロバイ
ダ決定処理部１１２は、一時変数Ｓをサービス定義テー
ブル１１９の先頭要素で初期化し、ステップ９０２にお
いて、一時変数ＦｏｕｎｄをＦＡＬＳＥで初期化する。

【００７２】ステップ９０３からステップ９０８におい
て、サービスプロバイダ決定処理部１１２は、サービス
定義テーブル１１９に含まれる任意のサービス定義Ｓに
対して処理を行う。但し、繰り返し条件９０３により、
途中でＦｏｕｎｄがＴＲＵＥになった時点で、ステップ
９０４からステップ９０８の処理を抜け、ステップ９０
９に進む。

【００７３】ステップ９０４においてサービスプロバイ
ダ決定処理部１１２は、サービス情報１１５に格納され
た論理式を評価する。論理式中の論理変数の値は、Ｓが
保持するサービス定義４０２のサービス４０３の値或い
は属性リスト４０４の属性値である。論理式中の項がメ
ッセージ形式定義３１１の属性名３１３の場合、項の値
は、属性名３１３に対応するメッセージ属性値テーブル
６０３の属性値である。

【００７４】分岐条件９０５において、ステップ９０４
のサービス情報１１５が保持する論理式が成立した場合
には、Ｓのサービスプロバイダ情報４０５をサービスプ
ロバイダ情報１１６に代入し（ステップ９０７）、Ｆｏ
ｕｎｄにＴＲＵＥを代入する（ステップ９０８）。ステ
ップ９０６では、一時変数Ｓにサービス定義テーブル１
１９の次の要素を代入し、繰り返し条件９０３に戻って
処理を続行する。

【００７５】分岐条件９０９において、変数Ｆｏｕｎｄ
の値がＦＡＬＳＥである場合にサービスプロバイダ決定
処理部１１２は、「サービスプロバイダがみつからなか
った」という例外メッセージを送出する。

【００７６】分岐条件９１１において、サービス定義Ｓ
のメッセージ形式がメッセージ形式１２３と等しくない
場合にはメッセージ変換処理を起動し、メッセージ１２
４をメッセージ形式１２３からサービス定義Ｓのメッセ
ージ形式に変換して変換後のメッセージをメッセージ１
２５とする。

【００７７】図１０は本実施形態のメッセージ変換処理
の処理手順を示すフローチャートである。ステップ１０
０１においてメッセージ変換処理１０００は、メッセー
ジ変換手続きテーブル１２６に対して、変換元メッセー
ジ形式５０３がメッセージ形式１２３であり、変換先メ
ッセージ形式５０４がサービスプロバイダ情報１１６で
示されるサービスプロバイダ計算機１０９のメッセージ
形式４０６である様なメッセージ変換手続き５０５を検
索する。

【００７８】分岐条件１００２において、ステップ１０
０１でメッセージ変換手続き５０５が見つからなかった
場合にメッセージ変換処理１０００は、「不明なメッセ
ージ形式である」という例外メッセージを送出する（ス
テップ１００３）。

【００７９】ステップ１００４においてメッセージ変換
処理１０００は、ステップ１００１で見つかったメッセ
ージ変換手続き５０５を起動し、メッセージ１２４をメ
ッセージ１２５に変換する。

【００８０】本実施形態の登録情報編集処理部１１４
は、ＧＵＩを持つ処理部であり、メッセージ形式定義編
集ツール、サービス決定ルール編集ツール、サービス定
義編集ツール及びメッセージ変換手続き編集ツールを有
している。図１１から図１４を用いて、登録情報編集処
理部１１４の編集画面の例を説明する。

【００８１】図１１は本実施形態のメッセージ形式定義
編集ツールの編集画面の一例を示す図である。メッセー
ジ形式定義編集ツール１１００は、メッセージ形式定義
テーブル１１８で説明したデータ構造を編集し、２次記
憶装置上のメッセージ形式定義テーブル１２１に格納す
る。

【００８２】画面領域１１０１は、メッセージ形式定義
テーブルに既に登録してあるメッセージ形式定義の一覧
を表示する。画面領域１１０２及び画面領域１１０３に
おいて、メッセージ形式定義を行う。

【００８３】図１２は本実施形態のサービス決定ルール
編集ツールの編集画面の一例を示す図である。サービス
決定ルール編集ツール１２００は、メッセージ形式定義
テーブル１２１及びサービス定義テーブルを参照して、
サービス決定ルール２０１で説明したデータ構造を編集
し、２次記憶装置上のサービス決定ルールセット１２０
に格納する。

【００８４】サービス決定ルール編集ツール１２００
は、メッセージ形式定義テーブル１２１のメッセージ形
式定義に基づいて条件２０３を編集し、メッセージ形式
定義テーブル１２１とサービス定義テーブル１２２とに
基づいてサービス情報を定義する。

【００８５】画面領域１２０１は、サービス決定ルール
セット１２０に既に登録してあるサービス決定ルールの
一覧を表示する。画面領域１２０２において、システム
１００の運用管理者は、ルールが処理することができる
メッセージ形式をメッセージ形式定義テーブル１２１か
ら選択する。画面領域１２０３において、システム１０
０の運用管理者は、ルールの条件を定義する。画面領域
１２０４において、システム１００の運用管理者は、ル
ールのサービス情報を定義する。

【００８６】図１３は本実施形態のサービス定義編集ツ
ールの編集画面の一例を示す図である。サービス定義編
集ツール１３００は、サービス定義テーブル１１９で説
明したデータ構造を編集し、２次記憶装置上のサービス
定義テーブル１２２に格納する。

【００８７】画面領域１３０１は、サービス定義テーブ
ルに既に登録してあるサービス定義の一覧を表示する。
画面領域１３０２及び画面領域１３０３において、サー
ビス定義を行う。

【００８８】ここでは、システム１００の運用管理者が
サービス定義を行う様に記述しているが、サービスプロ
バイダ・プログラム自体が、自身が提供するサービスを
プログラム起動時に、サービス定義テーブル１１９とサ
ービス定義テーブル１２２に登録し、プログラム終了時
に削除するという方法も考えられる。

【００８９】図１４は本実施形態のメッセージ変換編集
ツールの編集画面の一例を示す図である。メッセージ変
換編集ツール１４００は、メッセージ形式定義テーブル
１２１を参照して、サービス定義テーブル１１９で説明
したデータ構造を編集し、２次記憶装置上のメッセージ
変換手続きテーブル１２７に格納する。

【００９０】画面領域１４０１は、メッセージ変換手続
きテーブル１２７に既に登録してあるメッセージ変換の
一覧を表示する。画面領域１４０２及び画面領域１４０
３において、サービス定義を行う。画面領域１４０３で
は、メッセージ変換手続きの指定として変換を行うコー
ドを直接入力する方法を取っているが、変換元メッセー
ジ形式の属性と変換先メッセージ形式の属性の対応テー
ブルを定義する方法も考えられる。

【００９１】以上説明した様に本実施形態のメッセージ
ルータによれば、サービスユーザからのメッセージに対
応するサービス検索条件を満たすサービスプロバイダへ
当該メッセージをルーティングするので、サービス形態
の動的変更やサービスユーザが送信する任意のメッセー
ジ形式に応じてルーティングを行うことが可能である。

【００９２】

【発明の効果】本発明によればサービスユーザからのメ
ッセージに対応するサービス検索条件を満たすサービス
プロバイダへ当該メッセージをルーティングするので、
サービス形態の動的変更やサービスユーザが送信する任
意のメッセージ形式に応じてルーティングを行うことが
可能である。

【図面の簡単な説明】

【図１】本実施形態のメッセージ・ルーティングを行う
システムの概略構成を示す図である。

【図２】本実施形態のサービス決定ルールセット１１７
のデータ構造を示す図である。

【図３】本実施形態のメッセージ形式定義テーブル１１
８のデータ構造を示す図である。

【図４】本実施形態のサービス定義テーブル１１９のデ
ータ構造を示す図である。

【図５】本実施形態のメッセージ変換手続きテーブル１
２６のデータ構造を示す図である。

【図６】本実施形態のサービス決定処理部１１１の処理
手順を示すフローチャートである。

【図７】本実施形態のメッセージ解析処理の処理手順を
示すフローチャートである。

【図８】本実施形態のサービス決定ルール評価処理の処
理手順を示すフローチャートである。

【図９】本実施形態のサービスプロバイダ決定処理部１
１２の処理手順を示すフローチャートである。

【図１０】本実施形態のメッセージ変換処理の処理手順
を示すフローチャートである。

【図１１】本実施形態のメッセージ形式定義編集ツール
の編集画面の一例を示す図である。

【図１２】本実施形態のサービス決定ルール編集ツール
の編集画面の一例を示す図である。

【図１３】本実施形態のサービス定義編集ツールの編集
画面の一例を示す図である。

【図１４】本実施形態のメッセージ変換編集ツールの編
集画面の一例を示す図である。

【符号の説明】

１００…システム、１０１…メッセージルータ計算機、
１０２…中央演算装置、１０３…主記憶装置、１０４…
２次記憶装置、１０５…入出力装置、１０６…通信装
置、１０７…計算機ネットワーク、１０８…サービスユ
ーザ計算機、１０９…サービスプロバイダ計算機、１１
５…サービス情報、１１６…サービスプロバイダ情報、
１１７…サービス決定ルールセット、１１８…メッセー
ジ形式定義テーブル、１１９…サービス定義テーブル、
１２０…サービス決定ルールセット、１２１…メッセー
ジ形式定義テーブル、１２２…サービス定義テーブル、
１２３…メッセージ形式、１２４…メッセージ、１２５
…メッセージ、１２６…メッセージ変換手続きテーブ
ル、１２７…メッセージ変換手続きテーブル、１１０…
メッセージ受信処理部、１１１…サービス決定処理部、
１１２…サービスプロバイダ決定処理部、１１３…メッ
セージ送信処理部、１１４…登録情報編集処理部、２０
１…サービス決定ルール、２０２…メッセージ形式、２
０３…条件、２０４…サービス情報、２０５…ルール
名、３０２…メッセージ形式定義テーブルエントリ、３
０３…メッセージ形式、３０４…定義の参照、３１１…
メッセージ形式定義、３１２…メッセージ属性定義、３
１３…属性名、３１４…型、３１５…型情報、４０２…
サービス定義、４０３…サービス、４０４…属性リス
ト、４０５…サービスプロバイダ情報、４０６…メッセ
ージ形式、５０２…メッセージ変換手続きテーブルエン
トリ、５０３…変換元メッセージ形式、５０４…変換先
メッセージ形式、５０５…メッセージ変換手続き、６０
３…メッセージ属性値テーブル、７００…メッセージ解
析処理、７０２、７０７、７０９、７１１、７１３及び
７１６…分岐条件、７０６…繰り返し条件、８００…サ
ービス決定ルール評価処理、８０３…繰り返し条件、８
０４、８０７及び８１０…分岐条件、９０３…繰り返し
条件、９０５、９０９及び９１１…分岐条件、１０００
…メッセージ変換処理、１００２…分岐条件、１１００
…メッセージ形式定義編集ツール、１１０１…画面領
域、１１０２…画面領域、１１０３…画面領域、１２０
０…サービス決定ルール編集ツール、１２０１…画面領
域、１２０２…画面領域、１２０３…画面領域、１２０
４…画面領域、１３００…サービス定義編集ツール、１
３０１…画面領域、１３０２…画面領域、１３０３…画
面領域、１４００…メッセージ変換編集ツール、１４０
１…画面領域、１４０２…画面領域、１４０３…画面領
域。

───────────────────────────────────────────────────── フロントページの続き (72)発明者青島達人神奈川県川崎市幸区鹿島田890番地株式会社日立製作所システム開発本部内 (72)発明者北川誠神奈川県川崎市幸区鹿島田890番地株式会社日立製作所システム開発本部内Ｆターム(参考） 5B045 BB01 5B085 BG07 CA04 5B089 GA31 GB01 JA11 KA01 KC44 KG08

Claims

【特許請求の範囲】

【請求項１】プログラム間で送受信されるメッセージ
のルーティングを行うメッセージ・ルーティング方法に
おいて、メッセージの内容を解析し、メッセージにより要求され
たサービスを決定するステップと、サービスに適合する
サービスプロバイダを検索し、メッセージが要求するサ
ービスの処理を行うサービスプロバイダを決定するステ
ップとを有することを特徴とするメッセージ・ルーティ
ング方法。
【請求項２】メッセージ中のデータがサービス決定ル
ールの条件を満たすかを判定し、メッセージに対応する
サービスを決定するステップを有することを特徴とする
請求項１に記載されたメッセージ・ルーティング方法。
【請求項３】サービスプロバイダが受理できる形式に
メッセージ変換を行うステップを有することを特徴とす
る請求項１または請求項２のいずれかに記載されたメッ
セージ・ルーティング方法。
【請求項４】プログラム間で送受信されるメッセージ
のルーティングを行うメッセージルータにおいて、メッセージの内容を解析し、メッセージにより要求され
たサービスを決定するサービス決定処理部と、サービス
に適合するサービスプロバイダを検索し、メッセージが
要求するサービスの処理を行うサービスプロバイダを決
定するサービスプロバイダ決定処理部とを備えることを
特徴とするメッセージルータ。
【請求項５】プログラム間で送受信されるメッセージ
のルーティングを行うメッセージルータとしてコンピュ
ータを機能させる為のプログラムを記録したコンピュー
タ読み取り可能な記録媒体において、メッセージの内容を解析し、メッセージにより要求され
たサービスを決定するサービス決定処理部と、サービス
に適合するサービスプロバイダを検索し、メッセージが
要求するサービスの処理を行うサービスプロバイダを決
定するサービスプロバイダ決定処理部としてコンピュー
タを機能させる為のプログラムを記録したことを特徴と
する記録媒体。