(57)【要約】      （修正有）【課題】顧客毎に柔軟なバリデーションが可能なＸＭＬメッセージ変換装置、ＸＭＬメッセージ変換方法、およびプログラムを提供する。【解決手段】ＸＭＬメッセージ変換装置１００は、主記憶部１０１と、補助記憶部１０２と、制御部１０３と、通信部１０４と、入出力部１０５と、上記各部を相互に接続するシステムバス１０６と、を備え、メディアセンタ２００と複数の金融機関ホスト３００とそれぞれネットワークを介して通信可能に接続されて、受信した電文の構造が、特定した第１のスキーマにより定義されている構造であるか否かを判定し、電文の構造が前記第１のスキーマにより定義されている構造であると判定した場合、特定した第２のスキーマに基づいてインスタンスを生成し、生成したインスタンスに電文の情報を記録して、対応する顧客にネットワークを介して送信する。【選択図】図１
2012194764.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してＸＭＬ文書である電文を受信する受信手段と、
前記電文の構造が顧客毎にそれぞれ定義されている第１のスキーマと、前記第１のスキーマでそれぞれ共通して定義される項目が定義されている第２のスキーマと、前記電文と前記第１及び第２のスキーマを対応付ける対応情報と、を記憶する記憶手段と、
前記記憶手段で記憶されている対応情報に基づいて、前記受信手段で受信した電文に対応する前記第１のスキーマ及び前記第２のスキーマを特定する特定手段と、
前記受信手段で受信した電文の構造が、前記特定手段で特定した第１のスキーマにより定義されている構造であるか否かを判定する受信電文判定手段と、
前記受信電文判定手段により前記電文の構造が前記第１のスキーマにより定義されている構造であると判定された場合、前記特定手段で特定した第２のスキーマに基づいてインスタンスを生成するインスタンス生成手段と、
前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信手段と、
を備えることを特徴とするＸＭＬメッセージ変換装置。
【請求項２】
前記送信手段は、前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録した情報を、送信用のＸＭＬ文書である送信用電文に変換する変換手段と、
前記送信用電文の構造が前記特定手段で特定した第１のスキーマにより定義されている構造であるか否かを判定する送信電文判定手段と、
を備えることを特徴とする請求項１に記載のＸＭＬメッセージ変換装置。
【請求項３】
前記受信電文判定手段により前記電文の構造が前記第１のスキーマにより定義されていない構造であると判定された場合、ネットワークを介してエラーメッセージを通知する通知手段を、
さらに備えることを特徴とする請求項１又は２に記載のＸＭＬメッセージ変換装置。
【請求項４】
ネットワークを介してＸＭＬ文書である電文を受信する受信ステップと、
前記電文の構造が顧客毎にそれぞれ定義されている第１のスキーマと、前記第１のスキーマでそれぞれ共通して定義される項目が定義されている第２のスキーマと、前記電文と前記第１及び第２のスキーマを対応付ける対応情報と、を記憶する記憶ステップと、
前記記憶ステップで記憶された対応情報に基づいて、前記受信ステップで受信した電文に対応する前記第１のスキーマ及び前記第２のスキーマを特定する特定ステップと、
前記受信ステップで受信した電文の構造が、前記特定ステップにより特定された第１のスキーマにより定義されている構造であるか否かを判定する受信電文判定ステップと、
前記受信電文判定ステップにより前記電文の構造が前記第１のスキーマにより定義されている構造であると判定された場合、前記特定ステップで特定された第２のスキーマに基づいてインスタンスを生成するインスタンス生成ステップと、
前記インスタンス生成ステップで生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信ステップと、
を備えることを特徴とするＸＭＬメッセージ変換方法。
【請求項５】
コンピュータを、
ネットワークを介してＸＭＬ文書である電文を受信する受信手段、
前記電文の構造が顧客毎にそれぞれ定義されている第１のスキーマと、前記第１のスキーマでそれぞれ共通して定義される項目が定義されている第２のスキーマと、前記電文と前記第１及び第２のスキーマを対応付ける対応情報と、を記憶する記憶手段、
前記記憶手段で記憶されている対応情報に基づいて、前記受信手段で受信した電文に対応する前記第１のスキーマ及び前記第２のスキーマを特定する特定手段、
前記受信手段で受信した電文の構造が、前記特定手段で特定した第１のスキーマにより定義されている構造であるか否かを判定する受信電文判定手段、
前記受信電文判定手段により前記電文の構造が前記第１のスキーマにより定義されている構造であると判定された場合、前記特定手段で特定した第２のスキーマに基づいてインスタンスを生成するインスタンス生成手段、
前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信手段
として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＸＭＬメッセージ変換装置、ＸＭＬメッセージ変換方法、およびプログラムに関する。
【背景技術】
【０００２】
近年、多数の金融機関のシステムと接続するために共同利用型の中継装置が用いられている。顧客は、固定電話、携帯電話、パソコンなど様々な端末により、この中継装置を介して電文を送受信する。このような電文としては、各金融機関システムと中継装置の間の親和性の高さから、ＸＭＬ（eXtensible Markup Language）電文が用いられる。
ＸＭＬ電文を処理する方式として、一般的にＸＭＬ文書をツリー構造のまま扱う文書モデル方式と、ＸＭＬ文書構造を特に意識せず、アプリケーションで使用するＸＭＬデータの内容だけを操作するオブジェクトモデル（DataBinding）方式とがある。DataBinding方式は、ＸＭＬインスタンスの内容を保持するＪａｖａ（登録商標）インスタンスを生成し、アプリケーションがこのＪａｖａインスタンスを通じてＸＭＬインスタンスの内容にアクセスすることでＸＭＬ電文を処理する。
【０００３】
従来、金融機関システムでは、信頼性を確保するために１電文あたりの最大電文長が定められた固定長電文が利用されていた。しかし、金融機関によっては、電文項目を追加したり、電文サイズを拡張したい場合がある。そのためＸＭＬ文書構造を自由に定義できるオブジェクトモデル方式が提案されている（例えば、非特許文献１）。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】”ＪＡＸＢ  Ｕｓｅｒｓ  Ｇｕｉｄｅ”、［Online］、［平成23年2月1日検索］、インターネット<URL：https://jaxb.dev.java.net/guide/>
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、非特許文献１に記載のオブジェクトモデル方式では、個々の金融機関単位でＸＭＬスキーマを作成するため、ＸＭＬスキーマ量に応じて業務アプリケーションのプログラム製造規模が増加する。また、非特許文献１に記載のオブジェクトモデル方式では、ＸＭＬスキーマの数が増加すると、それに応じて生成されるクラスも増加するため、プログラム量も増加する。さらに、非特許文献１に記載のオブジェクトモデル方式では、金融機関の要望に応じてＸＭＬスキーマの定義を変更する度にプログラムを修正する必要があるが、当該プログラムは複数の金融機関で共同利用するため、特定の金融機関が希望する任意のタイミングで修正することが困難であった。そのため、金融機関毎に柔軟なバリデーションを行うという観点からみると、未だ十分ではない。ここで、バリデーションとは、あるＸＭＬインスタンス（ＸＭＬ形式で記述されたデータを含む文書）の内容が、対応するＸＭＬスキーマに定義されている情報に適合しているか否かを検証する処理のことである。
【０００６】
本発明は、上述のような事情に鑑みてなされたものであり、顧客毎に柔軟なバリデーションが可能なＸＭＬメッセージ変換装置、ＸＭＬメッセージ変換方法、およびプログラムを提供することを目的としている。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、本発明の第１の観点に係るＸＭＬメッセージ変換装置は、
ネットワークを介してＸＭＬ文書である電文を受信する受信手段と、
前記電文の構造が顧客毎にそれぞれ定義されている第１のスキーマと、前記第１のスキーマでそれぞれ共通して定義される項目が定義されている第２のスキーマと、前記電文と前記第１及び第２のスキーマを対応付ける対応情報と、を記憶する記憶手段と、
前記記憶手段で記憶されている対応情報に基づいて、前記受信手段で受信した電文に対応する前記第１のスキーマ及び前記第２のスキーマを特定する特定手段と、
前記受信手段で受信した電文の構造が、前記特定手段で特定した第１のスキーマにより定義されている構造であるか否かを判定する受信電文判定手段と、
前記受信電文判定手段により前記電文の構造が前記第１のスキーマにより定義されている構造であると判定された場合、前記特定手段で特定した第２のスキーマに基づいてインスタンスを生成するインスタンス生成手段と、
前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信手段と、
を備えることを特徴とする。
【０００８】
また、前記送信手段は、前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録した情報を、送信用のＸＭＬ文書である送信用電文に変換する変換手段と、
前記送信用電文の構造が前記特定手段で特定した第１のスキーマにより定義されている構造であるか否かを判定する送信電文判定手段と、
を備えていてもよい。
【０００９】
また、前記ＸＭＬメッセージ変換装置は、前記受信電文判定手段により前記電文の構造が前記第１のスキーマにより定義されていない構造であると判定された場合、ネットワークを介してエラーメッセージを通知する通知手段を、
さらに備えていてもよい。
【００１０】
上記目的を達成するため、本発明の第２の観点に係るＸＭＬメッセージ変換方法は、
ネットワークを介してＸＭＬ文書である電文を受信する受信ステップと、
前記電文の構造が顧客毎にそれぞれ定義されている第１のスキーマと、前記第１のスキーマでそれぞれ共通して定義される項目が定義されている第２のスキーマと、前記電文と前記第１及び第２のスキーマを対応付ける対応情報と、を記憶する記憶ステップと、
前記記憶ステップで記憶された対応情報に基づいて、前記受信ステップで受信した電文に対応する前記第１のスキーマ及び前記第２のスキーマを特定する特定ステップと、
前記受信ステップで受信した電文の構造が、前記特定ステップにより特定された第１のスキーマにより定義されている構造であるか否かを判定する受信電文判定ステップと、
前記受信電文判定ステップにより前記電文の構造が前記第１のスキーマにより定義されている構造であると判定された場合、前記特定ステップで特定された第２のスキーマに基づいてインスタンスを生成するインスタンス生成ステップと、
前記インスタンス生成ステップで生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信ステップと、
を備えることを特徴とする。
【００１１】
上記目的を達成するため、本発明の第３の観点に係るプログラムは、
コンピュータを、
ネットワークを介してＸＭＬ文書である電文を受信する受信手段、
前記電文の構造が顧客毎にそれぞれ定義されている第１のスキーマと、前記第１のスキーマでそれぞれ共通して定義される項目が定義されている第２のスキーマと、前記電文と前記第１及び第２のスキーマを対応付ける対応情報と、を記憶する記憶手段、
前記記憶手段で記憶されている対応情報に基づいて、前記受信手段で受信した電文に対応する前記第１のスキーマ及び前記第２のスキーマを特定する特定手段、
前記受信手段で受信した電文の構造が、前記特定手段で特定した第１のスキーマにより定義されている構造であるか否かを判定する受信電文判定手段、
前記受信電文判定手段により前記電文の構造が前記第１のスキーマにより定義されている構造であると判定された場合、前記特定手段で特定した第２のスキーマに基づいてインスタンスを生成するインスタンス生成手段、
前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信手段
として機能させることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、顧客毎に柔軟なバリデーションが可能となる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施の形態に係るＸＭＬ変換装置の構成を示すブロック図である。
【図２】図１のＸＭＬ変換装置が備える関連情報の一例を説明する図である。
【図３】ＸＭＬスキーマの構造を説明するための一例を示す図である。
【図４】図１のＸＭＬ変換装置が備える共通ＸＭＬスキーマと銀行別ＸＭＬスキーマの構造を説明するための一例を示す図である。
【図５】図１のＸＭＬ変換装置が備える銀行別ＸＭＬスキーマの構造の一例を示す図である。
【図６】図１のＸＭＬ変換装置における準備処理の動作を説明するフローチャートである。
【図７】図１のＸＭＬ変換装置における上り処理の動作を説明するフローチャートである。
【図８】図１のＸＭＬ変換装置における下り処理の動作を説明するフローチャートである。
【発明を実施するための形態】
【００１４】
本発明の実施形態に係るＸＭＬメッセージ変換装置について、図面を参照して説明する。ＸＭＬメッセージ変換装置は、メディアセンタと複数の金融機関ホストとの間で通信される業務電文を送受信するとともに、共通スキーマと個別スキーマを用いて業務電文の柔軟なバリデーションを行うバリデーション機能を備えている。
メディアセンタは、例えば、個人ユーザや業者等を含む利用者から送信される業務電文を収集するコンピュータである。また、金融機関ホストは、例えば、銀行や証券会社、生命保険会社等を含む金融機関に設置されるコンピュータで、受信した業務電文に基づく処理を行う。ここで、業務電文はＸＭＬ電文であり、クライアント番号、銀行コード、電文コード、及び、サービスコード等を含む業務データ、残高照会や振り込み等の処理要求、及び、各処理の結果が含まれる。
【００１５】
ＸＭＬメッセージ変換装置は、上記機能を実現する構成として、図１に示すように、主記憶部１０１と、補助記憶部１０２と、制御部１０３と、通信部１０４と、入出力部１０５と、上記各部を相互に接続するシステムバス１０６と、を備えている。ＸＭＬメッセージ変換装置１００は、メディアセンタ２００と複数の金融機関ホスト３００とそれぞれネットワークを介して通信可能に接続されている。
【００１６】
主記憶部１０１は、ＲＡＭ（Random Access Memory）等を含んで構成され、後述するＣＰＵの作業領域として用いられる。
【００１７】
補助記憶部１０２は、ＲＯＭ（Read Only Memory）、磁気ディスク、半導体メモリ等の不揮発性メモリを含んで構成されている。この補助記憶部１０２には、制御部１０３が処理を行うために必要なデータやパラメータ、プログラム等が記憶されている。
また、補助記憶部１０２には、後述する入出力部１０５からユーザの入力操作により入力される関連情報１１０と、共通ＸＭＬスキーマ１１１と、銀行別ＸＭＬスキーマ１１２と、が格納される。
【００１８】
関連情報１１０は、図２に示すように、業務電文中に含まれるクライアント番号、銀行コード、電文コード、及び、サービスコードに対応する共通ＸＭＬスキーマ１１１及び銀行別ＸＭＬスキーマ１１２を特定するための情報である。関連情報１１０は、ユーザの入力操作により後述する入出力部１０５から入力される。
【００１９】
ここで、クライアント番号とは、パソコン等の端末を利用して残高照会等の各種金融業務を要求する顧客を一意に特定するための情報である。銀行コードは、金融機関ホストを一意に特定するための情報である。電文コードは、業務電文を一意に特定するための情報である。サービスコードは、各種金融業務毎に割り振られ、金融業務を一意に特定するための情報である。
【００２０】
共通ＸＭＬスキーマ１１１は、ユーザにより生成され、後述するスキーマ準備処理においてユーザの入力操作により格納される。ここで、スキーマとは、ＸＭＬドキュメントの文法規則、すなわち、ＸＭＬドキュメントの取り得る構造を記述したデータである。スキーマは、ＸＭＬデータの文書構造と、値のデータ型が厳密にスキーマの定義内容と合っているかどうかを検証するために使用される。共通ＸＭＬスキーマ１１１は、全ての属性や構成要素、及び、業務電文であるＸＭＬドキュメントの構造タグ名称が定義されたスキーマである。なお、構造タグ名称とは、ＸＭＬドキュメント中の各構成要素の名称を示す。
【００２１】
銀行別ＸＭＬスキーマ１１２は、ユーザにより生成され、後述するスキーマ準備処理においてユーザの入力操作により格納される。銀行別ＸＭＬスキーマ１１２は、共通ＸＭＬスキーマ１１１で定義された構造タグ名称に従って、各金融機関別に、タグ名称、タグ出現回数、出現順序、桁数、及び、正規表現等のＸＭＬ構造が定義されたスキーマである。銀行別ＸＭＬスキーマ１１２は、各金融機関別の業務電文のバリデーションを行う際に用いられる。
【００２２】
ここで、ＸＭＬドキュメントの構造について図３を参照して説明する。タグ名称は、ＸＭＬドキュメント内の各要素を識別する名称である。タグ出現回数は、同一のタグ名称の要素の、ＸＭＬドキュメント内における出現回数を示す。出現順序は、それぞれのタグ名称により識別される要素の、ＸＭＬドキュメント内における出現順序を示す。桁数は、各タグ名称により識別される要素の桁数制限を示す。正規表現は、タグ名称により識別される各要素の、ＸＭＬドキュメント内における内容制限を示し、例えば、文字列のみ、数字のみ、といった制限を課すよう設定できる。
【００２３】
次に、共通ＸＭＬスキーマ１１１と銀行別ＸＭＬスキーマ１１２について図４を参照して詳細に説明する。ここで、銀行別ＸＭＬスキーマ１１２は、銀行毎に存在し、銀行別に各項目がそれぞれ定義される。
【００２４】
図示するように、銀行別ＸＭＬスキーマ１１２は、共通ＸＭＬスキーマ１１１で定義されたタグ名称及び出現順序に基づいてタグ名称及び出現順序が定義される。
【００２５】
出現回数については、図示するように、例えば、共通ＸＭＬスキーマ１１１では、最小が０、最大が無制限を意味するunboundedに定義され、銀行別ＸＭＬスキーマ１１２では、最小が０、最大が５０に定義される。
【００２６】
また、桁数については、共通ＸＭＬスキーマ１１１では、桁数は制限されず、銀行別ＸＭＬスキーマ１１２では、桁数が制限される。図示する例では、銀行別ＸＭＬスキーマ１１２での桁数は１２桁に制限される。
【００２７】
正規表現については、図示するように、共通ＸＭＬスキーマ１１１では、特に制限がされず、任意の文字列であればよい、ということだけが定義される。一方、銀行別ＸＭＬスキーマ１１２では、制限が課される。制限は、例えば、タグ名称により識別される各要素の内容が、図示するように、数字のみに制限したり、図５に示すように、所定の文字のみ許可されるように制限できる。
【００２８】
このように、銀行別ＸＭＬスキーマ１１２は、共通ＸＭＬスキーマ１１１で定義された範囲内において、各項目が銀行別にそれぞれ定義される。
【００２９】
制御部１０３は、ＣＰＵ（Central Processing Unit）等から構成される。制御部１０３は、補助記憶部１０２に格納されているプログラムに従って動作する。制御部１０３は、プログラムにより提供される主要な機能部として、記録部１３１と、送受信部１３２と、圧縮解凍部１３３と、ＸＭＬ解釈検証部１３４と、スキーマコンパイラ部１３５と、インスタンス生成部１３６と、電文編集部１３７と、電文変換部１３８と、を備えている。なお、上記各機能部で処理されるデータ等は、適宜後述する入出力部１０５へ出力され、表示されるものとする。
【００３０】
記録部１３１は、後述する準備処理において、後述する入出力部１０５からユーザの入力操作により入力された関連情報１１０、共通ＸＭＬスキーマ１１１、及び、銀行別ＸＭＬスキーマ１１２等を補助記憶部１０２へ記録する。
【００３１】
送受信部１３２は、後述する通信部１０４を介して、メディアセンタ２００や金融機関ホスト３００と業務電文の送受信処理を行う。
【００３２】
圧縮解凍部１３３は、送受信部１３２で受信した業務電文の圧縮及び解凍を行う。圧縮の形式は、例えばＺＩＰ形式等である。
圧縮解凍部１３３は、メディアセンタ２００又は金融機関ホスト３００から送受信部１３２の機能により受信した業務電文を解凍し、補助記憶部１０２へ格納する。また、圧縮解凍部１３３は、解凍した業務電文を、後述するＸＭＬ解釈検証部１３４及びスキーマコンパイラ部１３５へ渡す。また、圧縮解凍部１３３は、後述する電文変換部１３８から供給された送信用業務電文を圧縮し、送受信部１３２へ供給する。
【００３３】
ＸＭＬ解釈検証部１３４は、補助記憶部１０２に格納されている関連情報１１０を読み出し、圧縮解凍部１３３から供給された解凍済みの業務電文に対応する銀行別ＸＭＬスキーマを特定１１２する。具体的には、ＸＭＬ解釈検証部１３４は、業務電文中のクライアント番号、銀行コード、電文コード、及び、サービスコードをキーとして、関連情報からこれらに対応する銀行別ＸＭＬスキーマ１１２を特定する。
【００３４】
また、ＸＭＬ解釈検証部１３４は、特定した銀行別ＸＭＬスキーマ１１２を補助記憶部１０２から読み出し、業務電文の構造が妥当であるか否かを検証する。具体的には、ＸＭＬ解釈検証部１３４は、業務電文中に含まれている各種コードの桁数やタグ名称、及び出現順序等が、特定した銀行別ＸＭＬスキーマ１１２に定義されている桁数や名称、及び構造に含まれるか否かを検証する。これにより、銀行別に業務電文のバリデーションが行われる。
【００３５】
スキーマコンパイラ部１３５は、後述する準備処理において、補助記憶部１０２に格納されている共通ＸＭＬスキーマ１１１に基づいてＪａｖａ（登録商標）クラスファイルを生成し、共通ＸＭＬスキーマ１１１と対応付けて補助記憶部１０２に格納する。Ｊａｖａクラスファイルの生成は、例えば、ＸＭＬ文書からＪａｖａのオブジェクトへの変換およびＪａｖａのオブジェクトからＸＭＬ文書への変換をするＡＰＩであるＪＡＸＢ（Java Architecture for XML Binding）により行われる。
【００３６】
また、スキーマコンパイラ部１３５は、後述するサービス提供時の処理において、補助記憶部１０２に格納されている関連情報１１０を読み出し、圧縮解凍部１３３から受け取った解凍済みの業務電文に対応する共通ＸＭＬスキーマ１１１を、業務電文中のクライアント番号、銀行コード、電文コード、及び、サービスコードをキーとして特定する。スキーマコンパイラ部１３５は、特定した共通ＸＭＬスキーマ１１１に対応付けられて補助記憶部１０２に格納されているＪａｖａクラスファイルを読み込み、後述するインスタンス生成部１３６に渡す。
【００３７】
インスタンス生成部１３６は、スキーマコンパイラ部１３５から受け取ったＪａｖａクラスファイルに基づいてＪａｖａインスタンス（Ｊａｖａクラスファイルに定義されたデータ構造を、コンピュータのメモリ上に保持するための領域）を生成する。また、インスタンス生成部１３６は、生成したＪａｖａインスタンスに業務電文の内容を記録する。インスタンス生成部１３６は、業務電文の内容を記録したＪａｖａインスタンスを、後述する電文編集部１３７へ渡す。
【００３８】
電文編集部１３７は、インスタンス生成部１３６から受け取ったＪａｖａインスタンスの内容を編集し、電文変換部１３８へ渡す。なお、Ｊａｖａインスタンスの内容の編集は、例えば、各項目の通番の処理等を含んでいる。
【００３９】
電文変換部１３８は、電文編集部１３７から受け取ったＪａｖａインスタンスの内容を、金融機関ホスト３００又はメディアセンタ２００へ送信するためのＸＭＬメッセージである送信用業務電文に変換する。また、電文変換部１３８は、送信用業務電文を送受信部１３２へ渡す。
【００４０】
通信部１０４は、シリアルインタフェース、或いはアナログ信号を受信するためのアナログインタフェースを有している。メディアセンタ２００または金融機関ホスト３００から送信される情報は、通信部１０４によって受信され、システムバス１０６を介してＣＰＵへ供給される。また、通信部１０４は、ＣＰＵから受け取った業務電文をメディアセンタ２００または金融機関ホスト３００へ送信する。
【００４１】
入出力部１０５は、キーボード、マウス、表示装置などから構成される。入出力部１０５は、ユーザの入力操作により入力された種々の指示やデータを制御部１０３へ渡す。また、入出力部１０５は、制御部１０３から出力されるデータ等を取得して表示する。
以上が本実施形態に係るＸＭＬメッセージ変換装置１００の構成である。
【００４２】
次に、ＸＭＬメッセージ変換装置１００の動作について、図６乃至図８を参照して説明する。まず、ＸＭＬメッセージ変換装置１００によるバリデーション機能を実現するための準備を行う準備処理について、図６を参照して説明する。なお、準備処理は、入出力部１０５からのユーザによる入力操作に応じて開始される。
【００４３】
ＸＭＬメッセージ変換装置１００は、記録部１３１の機能により、入出力部１０５から入力された共通ＸＭＬスキーマ１１１を補助記憶部１０２へ格納する（ステップＳ１０１）。
【００４４】
次に、ＸＭＬメッセージ変換装置１００は、記録部１３１の機能により、入出力部１０５から入力された銀行別ＸＭＬスキーマ１１２を補助記憶部１０２へ格納する（ステップＳ１０２）。
【００４５】
続いてＸＭＬメッセージ変換装置１００は、記録部１３１の機能により、入出力部１０５から入力された関連情報１１０を補助記憶部１０２へ格納する（ステップＳ１０３）。
【００４６】
次に、ＸＭＬメッセージ変換装置１００は、スキーマコンパイラ部１３５の機能により、補助記憶部１０２に記憶されている共通ＸＭＬスキーマ１１１に基づいてＪａｖａクラスファイルを生成する（ステップＳ１０４）。
【００４７】
そしてＸＭＬメッセージ変換装置１００は、スキーマコンパイラ部１３５の機能により、生成したＪａｖａクラスファイルを共通ＸＭＬスキーマ１１１と対応付けて補助記憶部１０２に格納する（ステップＳ１０５）。
【００４８】
以上が準備処理におけるＸＭＬメッセージ変換装置１００の動作である。
【００４９】
次に、サービス提供時の処理におけるＸＭＬメッセージ変換装置１００の動作について、図７及び図８を参照して説明する。サービス提供時の処理には、上り処理と下り処理があり、これらの処理は、通信部１０４がメディアセンタ２００又は金融機関ホスト３００から業務電文を受信する度に開始される。まず、通信部１０４がメディアセンタ２００から業務電文を受信して金融機関ホスト３００へ送信する上り処理について、図７を参照して説明する。
【００５０】
ＸＭＬメッセージ変換装置１００は、送受信部１３２の機能により、メディアセンタ２００から送信された業務電文であるＸＭＬドキュメントを、通信部１０４を介して取得する（ステップＳ２０１）。
【００５１】
続いてＸＭＬメッセージ変換装置１００は、圧縮解凍部１３３の機能により、送受信部１３２で取得したＸＭＬドキュメントを解凍し、ＸＭＬ解釈検証部１３４及びスキーマコンパイラ部１３５へ渡す（ステップＳ２０２）。
【００５２】
ＸＭＬメッセージ変換装置１００は、ＸＭＬ解釈検証部１３４の機能により、補助記憶部１０２に格納されている関連情報１１０を読み出し、圧縮解凍部１３３から受け取った解凍済みのＸＭＬドキュメントに対応する銀行別ＸＭＬスキーマ１１２を特定する（ステップＳ２０３）。
【００５３】
続いてＸＭＬメッセージ変換装置１００は、ＸＭＬ解釈検証部１３４の機能により、特定した銀行別ＸＭＬスキーマ１１２を補助記憶部１０２から読み出し、ＸＭＬドキュメントの構造が妥当であるか否かを検証する（ステップＳ２０４）。
【００５４】
ステップＳ２０４において、ＸＭＬドキュメントの構造が妥当であると判断された場合（ステップＳ２０４；Ｙｅｓ）、ＸＭＬメッセージ変換装置１００は、スキーマコンパイラ部１３５の機能により、補助記憶部１０２に格納されている関連情報１１０を読み出し、圧縮解凍部１３３から供給された解凍済みのＸＭＬドキュメントに対応する共通ＸＭＬスキーマ１１１を特定する（ステップＳ２０５）。
【００５５】
一方、ステップＳ２０４において、ＸＭＬドキュメントの構造が妥当でないと判断された場合（ステップＳ２０４；Ｎｏ）、ＸＭＬメッセージ変換装置１００は、ＸＭＬ解釈検証部１３４の機能により、エラーメッセージを生成し、通信部１０４を介して金融機関ホスト３００へ送信する（ステップＳ２０６）。そしてＸＭＬメッセージ変換装置１００は、この処理を終了する。
【００５６】
次に、ＸＭＬメッセージ変換装置１００は、スキーマコンパイラ部１３５の機能により、特定した共通ＸＭＬスキーマ１１１に対応するＪａｖａ（登録商標）クラスファイルを補助記憶部１０２から読み込み、インスタンス生成部１３６に渡す（ステップＳ２０７）。
【００５７】
ＸＭＬメッセージ変換装置１００は、インスタンス生成部１３６の機能により、スキーマコンパイラ部１３５で読み込んだＪａｖａクラスファイルに基づいてＪａｖａインスタンスを生成し、生成したＪａｖａインスタンスにＸＭＬドキュメントの内容を記録する（ステップＳ２０８）。
【００５８】
次に、ＸＭＬメッセージ変換装置１００は、電文編集部１３７の機能により、インスタンス生成部１３６から受け取ったＪａｖａインスタンスの内容を編集し、電文変換部１３８へ渡す（ステップＳ２０９）。
【００５９】
続いてＸＭＬメッセージ変換装置１００は、電文変換部１３８の機能により、受け取ったＪａｖａインスタンスを、金融機関ホスト３００へ送信するためのＸＭＬメッセージである送信用業務電文に変換し（ステップＳ２１０）、圧縮解凍部１３３へ渡す。
【００６０】
ＸＭＬメッセージ変換装置１００は、圧縮解凍部１３３の機能により、受け取った送信用業務電文を圧縮し（ステップＳ２１１）、送受信部１３２へ渡す。
【００６１】
ＸＭＬメッセージ変換装置１００は、送受信部１３２の機能により、受け取った圧縮された送信用業務電文を、通信部１０４を介して対応する金融機関ホスト３００へ送信し（ステップＳ２１２）、この処理を終了する。
【００６２】
次に、通信部１０４が金融機関ホスト３００から業務電文を受信してメディアセンタ２００へ送信する下り処理について、図８を参照して説明する。
【００６３】
ＸＭＬメッセージ変換装置１００は、送受信部１３２の機能により、金融機関ホスト３００から送信された業務電文であるＸＭＬドキュメントを、通信部１０４を介して取得する（ステップＳ３０１）。
【００６４】
続いてＸＭＬメッセージ変換装置１００は、図示するようにステップＳ３０２からステップＳ３１１までの処理を行うが、このステップＳ３０２からステップＳ３１１までの処理は上り処理におけるステップＳ２０２からステップＳ２１１までの処理と同様であるため説明を省略する。
【００６５】
そしてＸＭＬメッセージ変換装置１００は、送受信部１３２の機能により、受け取った圧縮された送信用業務電文を、通信部１０４を介してメディアセンタ２００へ送信し（ステップＳ３１２）、この処理を終了する。
【００６６】
以上が、サービス提供時の処理におけるＸＭＬメッセージ変換装置１００の動作である。
【００６７】
このように、本実施形態の構成によれば、共通ＸＭＬスキーマ１１１によって業務電文中の前提となる部分を定義し、銀行毎に異なる業務電文中の項目の妥当性については個別に定義した銀行別ＸＭＬスキーマ１１２に基づいて確認する。このような独立した２段階構造のスキーマとすることで、共通ＸＭＬスキーマだけをコンパイルすればよい。したがって銀行毎に業務アプリケーションの修正を行うことなく、銀行毎に柔軟なバリデーションが可能となる。
【００６８】
また、本実施形態の構成によれば、金融機関側の要望によりＸＭＬスキーマの定義を変更する場合についても、その金融機関に対応する銀行別ＸＭＬスキーマ１１２を変更すればよく、共通ＸＭＬスキーマ１１１や他の銀行別ＸＭＬスキーマ１１２を変更する必要がなくなる。
【００６９】
（変形例）
この発明は、上記の実施の形態に限定されず、種々の変形及び応用が可能である。上記実施の形態では、関連情報１１０、共通ＸＭＬスキーマ１１１、及び、銀行別ＸＭＬスキーマ１１２がユーザの入力操作により入出力部１０５から入力される場合について説明したが、必ずしもこれに限定されない。搬送波に関連情報１１０、共通ＸＭＬスキーマ１１１、及び、銀行別ＸＭＬスキーマ１１２を重畳し、通信ネットワークを介して配信することも可能である。
【００７０】
また、上記実施の形態では、準備処理において、共通ＸＭＬスキーマ１１１、銀行別ＸＭＬスキーマ１１２、関連情報１１０の順に補助記憶部１０２へ格納する例について説明したが、これらを格納する順番は任意であり、共通ＸＭＬスキーマ１１１、銀行別ＸＭＬスキーマ１１２、関連情報１１０のいずれの情報から格納してもよい。
【００７１】
上記実施の形態では、ＸＭＬメッセージ変換装置１００がＸＭＬドキュメントの構造が妥当であるか否かを検証し、妥当でないと判断した場合に通信部１０４を介してエラーメッセージを金融機関ホスト３００へ送信する例を示したがこれは一例である。エラーメッセージは、例えば、金融機関ホスト３００ではなく、メディアセンタ２００を介してユーザに送信してもよい。また、エラーメッセージを金融機関ホスト３００に送信し、さらにメディアセンタ２００を介してユーザに送信してもよい。
【００７２】
この構成によれば、ユーザ側においても業務電文の構造エラーを検知することができ、早期に対応することが可能となる。
【００７３】
上記実施の形態では、各スキーマに定義される出現回数について、共通ＸＭＬスキーマ１１１では最小が０、最大が無制限を意味するunboundedに定義され、銀行別ＸＭＬスキーマ１１２では最小が０、最大が５０に定義される例を示したが、これは一例である。各スキーマにおける出現回数の定義は任意であり、銀行別ＸＭＬスキーマ１１２で定義される出現回数が共通ＸＭＬスキーマ１１１で定義されている出現回数の範囲内であれば任意の数でよい。
【００７４】
また、上記実施の形態では、Ｊａｖａインスタンスを送信用業務電文に変換する処理（ステップＳ２１０及びステップＳ３１０）の後に、送信用業務電文を圧縮する処理を行う（ステップＳ２１１及びステップＳ３１１）例について説明したが、これらの処理の間に、送信用業務電文の構造が妥当であるか否かを検証する処理（ステップＳ２０４及びステップＳ３０４）を再度行ってもよい。
【００７５】
この構成によれば、ＸＭＬドキュメントの編集処理等の前後において電文の構造の妥当性を検証することができ、より信頼性の高いバリデーションを行うことが可能になる。
【００７６】
なお、本発明の実施の形態にかかるバリデーション機能を実現するための情報処理装置は、専用のシステムによらず、通常のコンピュータシステムを用いて実現可能である。例えば、汎用コンピュータに、上述の処理を実行するためのプログラムを格納した媒体（ＣＤ−ＲＯＭなど）から当該プログラムをインストールすることにより、上述の処理を実行する各種サーバを構成することができる。
【００７７】
また、上述の機能を、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）とアプリケーションとの分担、またはＯＳとアプリケーションとの協同により実現する場合等には、ＯＳ以外の部分のみを媒体に格納してもよい。
【００７８】
また、搬送波にプログラムを重畳し、通信ネットワークを介して配信することも可能である。例えば、通信ネットワーク上の掲示板（ＢＢＳ、Ｂｕｌｌｅｔｉｎ  Ｂｏａｒｄ  Ｓｙｓｔｅｍ）に当該プログラムを掲示し、ネットワークを介して当該プログラムを配信してもよい。そして、これらのプログラムを起動し、オペレーティングシステムの制御下で、他のアプリケーションプログラムと同様に実行することにより、上述の処理を実行できるように構成してもよい。
【符号の説明】
【００７９】
１００  ＸＭＬメッセージ変換装置
１０１  主記憶部
１０２  補助記憶部
１０３  制御部
１０４  通信部
１０５  入出力部
１０６  システムバス
１１０  関連情報
１１１  共通ＸＭＬスキーマ
１１２  銀行別ＸＭＬスキーマ
１３１  記録部
１３２  送受信部
１３３  圧縮解凍部
１３４  ＸＭＬ解釈検証部
１３５  スキーマコンパイラ部
１３６  インスタンス生成部
１３７  電文編集部
１３８  電文変換部
２００  メディアセンタ
３００  金融機関ホスト
【図１】
2012194764.tif 000003
【図２】
2012194764.tif 000004
【図３】
2012194764.tif 000005
【図４】
2012194764.tif 000006
【図５】
2012194764.tif 000007
【図６】
2012194764.tif 000008
【図７】
2012194764.tif 000009
【図８】
2012194764.tif 000010