JP2019061437A - 情報処理装置、情報処理システムおよびプログラム - Google Patents

Abstract

【課題】アプリケーションインタフェースの整合性の検査を効率化する。【解決手段】情報処理装置１０は、記憶部１１と通信部１２と処理部１３とを有する。記憶部１１は、データベースに定義された１以上のデータ項目を示すデータ構造情報から生成された符号１１ａを記憶する。通信部１２は、データベースに対するデータの読み出しまたは書き込みを要求するメッセージであって符号１４ａを含む要求メッセージ１４を受信する。処理部１３は、符号１１ａと符号１４ａとを比較し、一致する場合は要求された読み出しまたは書き込みを許容し、異なる場合はデータベースのデータ項目と要求メッセージ１４との間の整合性についての例外処理１５を実行する。【選択図】図１

Description

本発明は情報処理装置、情報処理システムおよびプログラムに関する。

ネットワークに接続された複数の情報処理装置が通信してデータ処理を行うオンラインシステムが利用されることがある。オンラインシステムでは、サーバとしての情報処理装置にデータベースを構築し、データベースに対するデータ操作を要求するための通信規約を示すアプリケーションインタフェースを定義しておくことがある。そして、アプリケーションインタフェースに従ってサーバと通信するクライアントアプリケーションを作成し、クライアントとしての情報処理装置に配置することがある。

オンラインシステムを構築して運用を開始した後、そのオンラインシステムを改修することもある。オンラインシステムの改修の典型例として、データベースのデータ構造の変更が挙げられる。データベースのデータ構造を変更する場合、クライアントからサーバにデータ操作を要求するためのアプリケーションインタフェースも変更されることがあり、クライアントアプリケーションの修正を要することがある。

データ構造の変更後にそのデータ構造と互換性のない既存のクライアントアプリケーションが実行されてしまうと、クライアントサーバ間のアプリケーションインタフェースの不整合により、サーバ処理の中でエラーが発生するおそれがある。アプリケーションインタフェースの不整合によるエラーは、クライアントアプリケーションの修正ミスや修正後のクライアントアプリケーションの配置ミスによって発生し得る。そこで、データベースのデータ構造を変更する改修を行う場合には、退行テスト（リグレッションテスト）によってアプリケーションインタフェースの不整合を検出することが行われている。

なお、起動後にアプリケーションプログラムの検査を行う複合機が提案されている。提案の複合機は、当該複合機がサポートしている機能を示す機器サポート情報と、アプリケーションプログラムが利用する機能を示すアプリ利用情報とを取得する。複合機は、機器サポート情報とアプリ利用情報とを比較し、アプリ利用情報に列挙された機能が機器サポート情報に含まれていない場合、アプリケーションプログラムの起動を抑止する。

また、符号化されたデータオブジェクト識別子を用いてデータオブジェクトの記憶場所を特定するアーカイブ記憶システムが提案されている。提案のアーカイブ記憶システムは、データオブジェクトのアクセス制御情報、サイズ、ペイロード部分のダイジェスト、エラー検出コードなどからデータオブジェクト識別子を生成する。

特開２０１３−１６４８６６号公報 国際公開第２０１４／０２５８２１号

しかし、リグレッションテストにおいて、クライアントからサーバに様々なバリエーションの要求メッセージを送信してアプリケーションインタフェースの整合性を検査することは、リグレッションテストの負担が大きく非効率であるという問題がある。

１つの側面では、本発明は、アプリケーションインタフェースの整合性の検査を効率化できる情報処理装置、情報処理システムおよびプログラムを提供することを目的とする。

１つの態様では、記憶部と通信部と処理部とを有する情報処理装置が提供される。記憶部は、データベースに定義された１以上のデータ項目を示すデータ構造情報から生成された第１の符号を記憶する。通信部は、データベースに対するデータの読み出しまたは書き込みを要求するメッセージであって第２の符号を含む要求メッセージを受信する。処理部は、第１の符号と第２の符号とを比較し、第１の符号と第２の符号とが一致する場合、要求された読み出しまたは書き込みを許容し、第１の符号と第２の符号とが異なる場合、データベースのデータ項目と要求メッセージとの間の整合性についての例外処理を実行する。また、１つの態様では、第１の情報処理装置と第２の情報処理装置とを有する情報処理システムが提供される。また、１つの態様では、コンピュータに実行させるプログラムが提供される。

１つの側面では、アプリケーションインタフェースの整合性の検査を効率化できる。

第１の実施の形態の情報処理システムを説明する図である。 第２の実施の形態の情報処理システムの例を示す図である。 開発端末のハードウェア例を示すブロック図である。 ソフトウェアの配置例を示す図である。 開発端末およびサーバの機能例を示すブロック図である。 テーブル定義ファイルの第１の例を示す図である。 ハッシュ値テーブルの第１の例を示す図である。 要求メッセージの第１の例を示す図である。 開発端末処理の手順例を示すフローチャートである。 データベース設定の第１の手順例を示すフローチャートである。 データベース操作の第１の手順例を示すフローチャートである。 インタフェース整合性の第１の判定例を示す図である。 インタフェース整合性の第２の判定例を示す図である。 テーブル定義ファイルの第２の例を示す図である。 要求メッセージの第２の例を示す図である。 ハッシュ値テーブルの第２の例を示す図である。 データベース設定の第２の手順例を示すフローチャートである。 データベース操作の第２の手順例を示すフローチャートである。 インタフェース整合性の第３の判定例を示す図である。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態を説明する。

図１は、第１の実施の形態の情報処理システムを説明する図である。
第１の実施の形態の情報処理システムは、情報処理装置１０，２０を有する。情報処理装置１０と情報処理装置２０とはネットワークを介して接続されている。

情報処理装置１０は、不揮発性の記憶装置を用いてデータベースを保持し、データベースへのアクセスを制御する。情報処理装置１０は、データベースに定義されたデータ構造に合わせて、データベースからのデータの読み出しやデータベースへのデータの書き込みを要求するためのアプリケーションインタフェースを提供する。情報処理装置２０は、情報処理装置１０に対して、データベースからの読み出しやデータベースへの書き込みを要求する。情報処理装置１０と情報処理装置２０との関係に着目すれば、情報処理装置１０はサーバに相当し、情報処理装置２０はクライアントに相当する。

情報処理装置１０が保持するデータベースのデータ構造は、事後的に変更されることがある。情報処理装置２０から情報処理装置１０への要求が、情報処理装置１０の提供するアプリケーションインタフェースと整合している場合、情報処理装置１０においてデータベースからの読み出しやデータベースへの書き込みが正常に実行され得る。一方、情報処理装置２０から情報処理装置１０への要求が、情報処理装置１０の提供するアプリケーションインタフェースと整合していない場合、情報処理装置１０においてデータベースからの読み出しやデータベースへの書き込みについてエラーが発生し得る。アプリケーションインタフェースの不整合は、情報処理装置１０が保持するデータベースのデータ構造と情報処理装置２０が想定するデータ構造とが異なることによって生じる。

情報処理装置１０は、記憶部１１、通信部１２および処理部１３を有する。記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性の半導体メモリでもよいし、ＨＤＤ（Hard Disk Drive）などの不揮発性のストレージでもよい。通信部１２は、情報処理装置２０と通信を行う通信インタフェースである。通信部１２は、有線通信インタフェースでもよいし無線通信インタフェースでもよい。処理部１３は、例えば、ＣＰＵ（Central Processing Unit）やＤＳＰ（Digital Signal Processor）などのプロセッサである。ただし、処理部１３は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの特定用途の電子回路を含んでもよい。プロセッサは、ＲＡＭなどのメモリに記憶されたプログラムを実行する。複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。

記憶部１１は、データベースのデータ構造情報から生成された符号１１ａを記憶する。データ構造情報は、データベースに定義された１以上のデータ項目を示す。例えば、データ構造情報は、各データ項目の項目名、データ型、データ長、その他の属性などを示す。符号１１ａは、他の符号との間で同一性を判定可能な固定長または可変長のビット列である。同じデータ構造情報からは同じ符号が生成され、異なるデータ構造情報からは異なる符号が生成されることが好ましい。例えば、符号１１ａは、所定のハッシュ関数を用いてデータ構造情報から算出されるハッシュ値である。記憶部１１は、データ構造情報を更に記憶してもよい。情報処理装置１０は、データ構造情報から符号１１ａを生成してもよいし、他の情報処理装置で生成された符号１１ａを取得してもよい。

通信部１２は、要求メッセージ１４を情報処理装置２０から受信する。要求メッセージ１４は、データベースに対する操作、すなわち、データベースからのデータの読み出しまたはデータベースへのデータの書き込みを要求するものである。要求メッセージ１４は符号１４ａを含む。符号１４ａは、情報処理装置２０が想定する１以上のデータ項目を示すデータ構造情報から生成された符号であり、情報処理装置２０によって保持されている。

符号１１ａと符号１４ａとは、同一のデータ構造情報から生成されたものであることが期待される。ただし、データベースのデータ項目の定義が事後的に変更され、その変更が情報処理装置２０に正しく反映されていない場合、符号１４ａが符号１１ａよりも古いデータ構造情報から生成されている可能性がある。よって、符号１１ａと符号１４ａとが、異なるデータ構造情報から生成されており一致しないことがある。

情報処理装置２０は、他の情報処理装置から符号１４ａを取得してもよいし、他の情報処理装置からデータ構造情報を取得して符号１４ａを生成してもよい。また、情報処理装置２０は、符号１４ａが埋め込まれたクライアントプログラムを他の情報処理装置から取得し、クライアントプログラムを実行してもよい。当該クライアントプログラムは、例えば、要求メッセージ１４の送信に用いられる。

処理部１３は、要求メッセージ１４が受信されると、記憶部１１に記憶された符号１１ａと要求メッセージ１４に含まれる符号１４ａとを比較する。符号１１ａと符号１４ａとが一致する場合、処理部１３は、アプリケーションインタフェースの不整合は生じていないと判定する。すなわち、処理部１３は、要求メッセージ１４が想定するデータ項目とデータベースに定義されたデータ項目とが整合していると判定する。すると、処理部１３は、要求された読み出しや書き込みをデータベースに対して実行することを許容する。

一方、符号１１ａと符号１４ａとが異なる場合、処理部１３は、アプリケーションインタフェースの不整合が生じている可能性があると判定する。すなわち、処理部１３は、要求メッセージ１４が想定するデータ項目とデータベースに定義されたデータ項目とが整合しない可能性があると判定する。すると、処理部１３は、要求メッセージ１４とデータベースのデータ項目との間の整合性に関して例外処理１５を実行する。

例外処理１５は、例えば、要求メッセージ１４とデータベースのデータ項目とが整合しないことを示すエラー情報を出力することを含む。また、例外処理１５は、例えば、エラー情報を出力する前に、要求メッセージに含まれるクエリや書き込みデータを分析して、データ構造情報が示すデータ項目の定義と照合する詳細分析を含む。

要求メッセージ１４とデータベースのデータ項目とが整合していることが詳細分析によって確認された場合、要求された読み出しや書き込みをデータベースに対して実行することを許容してもよい。データベースのデータ項目の変更方法によっては、古いデータ項目を想定して生成された要求メッセージ１４が、データベースの現在のデータ項目と矛盾しないこともある。一方、要求メッセージ１４とデータベースのデータ項目とが整合していないことが詳細分析によって確認された場合、要求された読み出しや書き込みを拒否してエラー情報を出力するようにしてもよい。

第１の実施の形態の情報処理装置１０によれば、符号１４ａを含む要求メッセージ１４が情報処理装置２０から受信され、情報処理装置１０が保持する符号１１ａと要求メッセージ１４に含まれる符号１４ａとが比較される。符号１１ａと符号１４ａとが一致する場合、データベースに対する読み出しまたは書き込みが許容され、符号１１ａと符号１４ａとが異なる場合、データ項目の整合性に関して例外処理１５が実行される。

これにより、データベースの現在のデータ構造と要求メッセージ１４が想定するデータ構造とが一致しているか否かを迅速に判定することができる。例えば、データベースの現在のデータ構造と要求メッセージ１４が想定するデータ構造とが一致する場合、両者を照合する詳細分析を行わなくても一致していることを確認できる。よって、アプリケーションインタフェースの整合性の検査が効率化される。このため、例えば、データベースのデータ項目の定義を変更した後、その変更をクライアントに反映させる作業が正しく行われたか確認する検査を効率的に行うことが可能となる。

［第２の実施の形態］
次に、第２の実施の形態を説明する。
図２は、第２の実施の形態の情報処理システムの例を示す図である。

第２の実施の形態の情報処理システムは、ユーザ端末６１、開発端末１００、Ｗｅｂサーバ２００、アプリケーションサーバ（ＡＰサーバ）３００、キャッシュサーバ４００およびデータベースサーバ（ＤＢサーバ）５００を有する。ユーザ端末６１、開発端末１００、Ｗｅｂサーバ２００、ＡＰサーバ３００、キャッシュサーバ４００およびＤＢサーバ５００は、ネットワーク６０に接続されている。ネットワーク６０は、インターネットなどの広域ネットワークを含んでもよく、ＬＡＮ（Local Area Network）を含んでもよい。

ユーザ端末６１は、ユーザが操作するコンピュータである。ユーザ端末６１は、ＷｅｂブラウザなどのＷｅｂクライアントアプリケーションを実行する。ユーザ端末６１は、ＨＴＴＰ（Hypertext Transfer Protocol）を用いてＷｅｂサーバ２００にアクセスし、Ｗｅｂサーバ２００からＷｅｂコンテンツを受信する。

開発端末１００は、サーバアプリケーションの開発者が操作するコンピュータである。開発端末１００は、Ｗｅｂサーバ２００、ＡＰサーバ３００、キャッシュサーバ４００およびＤＢサーバ５００に、作成した各種のプログラムや設定情報を送信する。

Ｗｅｂサーバ２００は、ユーザ端末６１とＨＴＴＰ通信を行うサーバコンピュータである。Ｗｅｂサーバ２００は、ユーザ端末６１からＨＴＴＰリクエストを受信し、受信したＨＴＴＰリクエストに応じてＡＰサーバ３００にデータ処理を要求する。Ｗｅｂサーバ２００は、ＡＰサーバ３００からデータ処理結果を受信し、受信したデータ処理結果に基づいてＨＴＴＰレスポンスを生成してユーザ端末６１に送信する。

ＡＰサーバ３００は、ビジネスロジックを実装したサーバアプリケーションを実行するサーバコンピュータである。ＡＰサーバ３００は、Ｗｅｂサーバ２００からの要求に応じてデータ処理を行い、データ処理結果をＷｅｂサーバ２００に送信する。ＡＰサーバ３００は、キャッシュサーバ４００にアクセスして、データ処理に用いるデータをキャッシュサーバ４００から取得することがある。また、ＡＰサーバ３００は、ＤＢサーバ５００にアクセスして、データ処理に用いるデータをＤＢサーバ５００から取得することがある。また、ＡＰサーバ３００は、キャッシュサーバ４００にデータを送信することがあり、ＤＢサーバ５００にデータを送信することがある。

キャッシュサーバ４００は、ＡＰサーバ３００によって使用されるデータをキャッシュするサーバコンピュータである。データのキャッシュには、キーバリュー形式でデータを保持するデータベースであるキーバリューストア（ＫＶＳ）が用いられる。キャッシュサーバ４００は、ＡＰサーバ３００からのアクセスに応じてＫＶＳから所望のデータを検索してＡＰサーバ３００に送信することがある。また、キャッシュサーバ４００は、ＤＢサーバ５００にアクセスして、ＫＶＳに存在しないデータをＤＢサーバ５００から取得してＫＶＳに格納することがある。また、キャッシュサーバ４００は、ＡＰサーバ３００からのアクセスに応じてＫＶＳにデータを格納することがある。また、キャッシュサーバ４００は、ＫＶＳのデータをＤＢサーバ５００に転送することがある。

ＤＢサーバ５００は、データベースを保持し、データベースへのアクセスを制御するデータベース管理システム（ＤＢＭＳ）を実行するサーバコンピュータである。データベースとして、テーブル形式でデータを保持する関係データベース（ＲＤＢ）が用いられる。ＤＢサーバ５００は、ＡＰサーバ３００からのアクセスに応じてＲＤＢから所望のデータを検索してＡＰサーバ３００に送信することがある。また、ＤＢサーバ５００は、ＡＰサーバ３００からのアクセスに応じてＲＤＢにデータを格納することがある。また、ＤＢサーバ５００は、キャッシュサーバ４００からのアクセスに応じてＲＤＢから所望のデータを検索してキャッシュサーバ４００に送信することがある。また、ＤＢサーバ５００は、キャッシュサーバ４００からのアクセスに応じてＲＤＢにデータを格納することがある。

図３は、開発端末のハードウェア例を示すブロック図である。
開発端末１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７を有する。ユーザ端末６１、Ｗｅｂサーバ２００、ＡＰサーバ３００、キャッシュサーバ４００およびＤＢサーバ５００も、開発端末１００と同様のハードウェアを用いて実装できる。なお、ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１に対応する。通信インタフェース１０７は、第１の実施の形態の通信部１２に対応する。ＣＰＵ１０１は、第１の実施の形態の処理部１３に対応する。

ＣＰＵ１０１は、プログラムの命令を実行するプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、ＣＰＵ１０１は複数のプロセッサコアを含んでもよく、開発端末１００は複数のプロセッサを有してもよく、以下で説明する処理を複数のプロセッサまたはプロセッサコアを用いて並列に実行してもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。

ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、開発端末１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。

ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、開発端末１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。

画像信号処理部１０４は、ＣＰＵ１０１からの命令に従って、開発端末１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなど、任意の種類のディスプレイを用いることができる。

入力信号処理部１０５は、開発端末１００に接続された入力デバイス１１２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス１１２としては、マウス、タッチパネル、タッチパッド、トラックボール、キーボード、リモートコントローラ、ボタンスイッチなど、任意の種類の入力デバイスを用いることができる。また、開発端末１００に、複数の種類の入力デバイスが接続されていてもよい。

媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、磁気ディスク、光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤが含まれる。光ディスクには、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）が含まれる。

媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、ＣＰＵ１０１によって実行される。なお、記録媒体１１３は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体１１３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。

通信インタフェース１０７は、ネットワーク６０を介してＷｅｂサーバ２００、ＡＰサーバ３００、キャッシュサーバ４００およびＤＢサーバ５００と通信を行うインタフェースである。通信インタフェース１０７は、スイッチやルータなどの有線通信装置に接続される有線通信インタフェースでもよいし、基地局やアクセスポイントなどの無線通信装置に接続される無線通信インタフェースでもよい。

図４は、ソフトウェアの配置例を示す図である。
前述のように、Ｗｅｂサーバ２００、ＡＰサーバ３００、キャッシュサーバ４００およびＤＢサーバ５００が連携して、ユーザ端末６１に対してサービスを提供する。Ｗｅｂサーバ２００は、ユーザ端末６１に対する窓口として動作する。

Ｗｅｂサーバ２００にはサーブレット２１０が配置される。サーブレット２１０は、ユーザ端末６１から受信されるＨＴＴＰリクエストに応じたデータ処理を行うアプリケーションである。Ｗｅｂサーバ２００は、サーブレット２１０の起動や通信などを制御するアプリケーション実行基盤としてのミドルウェアを実行してもよく、サーブレット２１０はそのアプリケーション実行基盤上で起動される断片的プログラムでもよい。サーブレット２１０は、ＡＰサーバ３００に対して要求メッセージを送信することがある。

ＡＰサーバ３００にはＡＰサーバモジュール３１０が配置される。ＡＰサーバモジュール３１０は、Ｗｅｂサーバ２００から受信される要求メッセージに応じたデータ処理を行うアプリケーションである。ＡＰサーバ３００は、ＡＰサーバモジュール３１０の起動や通信などを制御するアプリケーション実行基盤としてのミドルウェアを実行してもよく、ＡＰサーバモジュール３１０はそのアプリケーション実行基盤上で起動される断片的プログラムでもよい。ＡＰサーバモジュール３１０は、キャッシュサーバ４００またはＤＢサーバ５００に要求メッセージを送信することがある。

キャッシュサーバ４００にはＫＶＳ４１０が配置される。ＫＶＳ４１０は、キーバリュー形式のデータベースを管理するミドルウェアである。キーバリュー形式のデータベースは、キャッシュサーバ４００において、ＨＤＤなどの不揮発性ストレージまたはＲＡＭなどの揮発性メモリに記憶されている。ＫＶＳ４１０は、ＡＰサーバ３００から受信される要求メッセージに応じて、検索や更新などのデータベース操作を実行する。ＫＶＳ４１０は、ＤＢサーバ５００に要求メッセージを送信することがある。

ＤＢサーバ５００にはＤＢＭＳ５１０が配置される。ＤＢＭＳ５１０は、テーブル形式の関係データベースを管理するミドルウェアである。関係データベースは、ＤＢサーバ５００において、ＨＤＤなどの不揮発性ストレージまたはＲＡＭなどの揮発性メモリに記憶されている。ＤＢＭＳ５１０は、ＡＰサーバ３００またはキャッシュサーバ４００から受信される要求メッセージに応じて、検索や更新などのデータベース操作を実行する。

２つのコンピュータ間の通信に着目すれば、一方が要求メッセージを送信する「クライアント」として動作し、他方が要求メッセージを待ち受ける「サーバ」として動作することになる。同一のコンピュータがクライアントとサーバを兼ねることもある。

Ｗｅｂサーバ２００とＡＰサーバ３００に着目すれば、Ｗｅｂサーバ２００はクライアントに相当し、ＡＰサーバ３００はサーバに相当する。ＡＰサーバ３００とキャッシュサーバ４００に着目すれば、ＡＰサーバ３００はクライアントに相当し、キャッシュサーバ４００はサーバに相当する。ＡＰサーバ３００とＤＢサーバ５００に着目すれば、ＡＰサーバ３００はクライアントに相当し、ＤＢサーバ５００はサーバに相当する。キャッシュサーバ４００とＤＢサーバ５００に着目すれば、キャッシュサーバ４００はクライアントに相当し、ＤＢサーバ５００はサーバに相当する。

例えば、サーブレット２１０は、ユーザ端末６１に対するサーバとＡＰサーバ３００に対するクライアントとを兼ねる。ただし、Ｗｅｂサーバ２００において、サーバ用モジュールとクライアント用モジュールが分離して存在し、前者が後者を呼び出すようにしてもよい。同様に、ＡＰサーバモジュール３１０は、Ｗｅｂサーバ２００に対するサーバとキャッシュサーバ４００およびＤＢサーバ５００に対するクライアントとを兼ねる。ただし、ＡＰサーバ３００において、サーバ用モジュールとクライアント用モジュールが分離して存在し、前者が後者を呼び出すようにしてもよい。ＫＶＳ４１０は、ＡＰサーバ３００に対するサーバとＤＢサーバ５００に対するクライアントとを兼ねる。ただし、キャッシュサーバ４００において、サーバ用モジュールとクライアント用モジュールが分離して存在し、前者が後者を呼び出すようにしてもよい。

ここで、第２の実施の形態の情報処理システムの運用を開始した後、データベースのデータ構造を変更することがある。例えば、関係データベースに新規カラムを追加することや既存カラムのデータ長を大きくすることなどによって、情報処理システムを拡張することがある。データベースのデータ構造の変更は、異なるアプリケーション間で送信される要求メッセージの規約に影響を与え、要求メッセージの送信元に影響を与える。

例えば、ＤＢサーバ５００のデータベースのデータ構造を変更することは、キャッシュサーバ４００からＤＢサーバ５００への要求メッセージに影響を与え、ＫＶＳ４１０に影響を与える。また、ＤＢサーバ５００のデータベースのデータ構造を変更することは、ＡＰサーバ３００からＤＢサーバ５００への要求メッセージに影響を与え、ＡＰサーバモジュール３１０に影響を与える。また、キャッシュサーバ４００のデータベースのデータ構造を変更することは、ＡＰサーバ３００からキャッシュサーバ４００への要求メッセージに影響を与え、ＡＰサーバモジュール３１０に影響を与える。

よって、データベースのデータ構造を変更すると、アプリケーション間でインタフェース不整合が発生するおそれがある。インタフェース不整合は、宛先のサーバが想定するデータ構造と送信元のクライアントが想定するデータ構造（すなわち、要求メッセージが想定するデータ構造）とが異なるために、サーバのデータ処理の中で想定外のエラーが発生することである。インタフェース不整合は、データベースのデータ構造の変更に合わせて、クライアントアプリケーションが適切に修正されなかった場合や、クライアントアプリケーションが適切に配信されなかった場合に発生し得る。

そこで、第２の実施の形態の情報処理システムは、インタフェース整合性を効率的に検査できるよう支援する。以下で説明するインタフェース整合性の検査は、例えば、データベースのデータ構造を変更して情報処理システムの運用を再開した後に常時行われる。ただし、当該インタフェース整合性の検査を、データベースのデータ構造を変更してから情報処理システムの運用を再開するまでの間のテスト期間に行うようにしてもよい。その場合、テスト期間経過後は情報処理システムから検査機能を除去してもよい。

以下では一例として、ＡＰサーバ３００とＤＢサーバ５００の間のインタフェース整合性に着目して検査処理を説明する。後述するように、ＡＰサーバ３００とキャッシュサーバ４００の間のインタフェース整合性や、キャッシュサーバ４００とＤＢサーバ５００の間のインタフェース整合性についても、同様の検査処理を適用することが可能である。

図５は、開発端末およびサーバの機能例を示すブロック図である。
開発端末１００は、ソースコード記憶部１２１、テーブル定義記憶部１２２、クライアント更新部１２３およびサーバ更新部１２４を有する。ソースコード記憶部１２１およびテーブル定義記憶部１２２は、例えば、ＲＡＭ１０２またはＨＤＤ１０３の記憶領域を用いて実装される。クライアント更新部１２３およびサーバ更新部１２４は、例えば、ＣＰＵ１０１が実行するプログラムを用いて実装される。

ソースコード記憶部１２１は、開発者によって作成されるクライアントプログラムのソースコード（ユーザソースコード）を記憶する。また、ソースコード記憶部１２１は、クライアント更新部１２３によって生成されるＡＰＩ（Application Programming Interface）プログラムのソースコード（ＡＰＩソースコード）を記憶する。ＡＰＩプログラムは、ＤＢサーバ５００に要求メッセージを送信する具体的方法を記載した関数（メソッドや手続きなどと言うこともある）を含み、ユーザソースコードから見てライブラリに相当する。ユーザソースコードからＡＰＩプログラムを呼び出すことで、ユーザソースコードの中に要求メッセージを送信する具体的方法を記載しなくてもよい。

テーブル定義記憶部１２２は、ＤＢサーバ５００のデータベースのデータ構造を示すテーブル定義ファイルを記憶する。テーブル定義ファイルは、例えば、ＳＱＬに含まれる文法などの所定のデータ定義言語で記述される。データベースのデータ構造を変更する場合、開発者によってテーブル定義記憶部１２２のテーブル定義ファイルが更新される。

クライアント更新部１２３は、テーブル定義記憶部１２２に記憶されたテーブル定義ファイルが更新されると、更新後のテーブル定義ファイルに基づいてＡＰＩソースコードを生成してソースコード記憶部１２１に格納する。生成されるＡＰＩソースコードは、変更後のデータ構造に合った適切な要求メッセージを送信する方法を記載している。例えば、変更後のデータ構造のカラムに対応する引数を含み、変更後のデータ構造のカラムに合ったフォーマットの要求メッセージを生成する関数が生成される。要求メッセージは、例えば、ＳＱＬに含まれる文法などの所定のデータ操作言語で記述される。

このとき、クライアント更新部１２３は、更新後のテーブル定義ファイルから符号を生成し、生成した符号をＡＰＩソースコードに埋め込む。ＡＰＩソースコードは、要求メッセージの送信時に当該符号が要求メッセージに付加されるように生成される。

第２の実施の形態では、符号としてテーブル定義ファイルのハッシュ値を使用する。ハッシュ値の算出には、ＭＤ５（Message Digest Algorithm 5）やＳＨＡ−１（Secure Hash Algorithm - 1）などのハッシュ関数が使用される。ハッシュ値は、例えば、１６バイトや２０バイトなどの固定長であり、元のテーブル定義ファイルが再現されない不可逆性をもつ。異なるテーブル定義ファイルからは異なるハッシュ値が算出されることが期待される。ただし、符号はテーブル定義ファイルの同一性を判定可能であればよく、暗号文などハッシュ値以外のビット列を符号として使用することも可能である。符号は、可変長であってもよく、元のテーブル定義ファイルが再現される可逆性をもっていてもよい。

なお、１つのテーブル定義ファイルは関係データベースの１つのテーブルのデータ構造を記載しており、ハッシュ値はテーブル毎に算出される。
ＡＰＩソースコードが生成されると、クライアント更新部１２３は、ユーザソースコードおよびＡＰＩソースコードをコンパイルし、両者やその他のライブラリをリンクしてクライアントモジュールを生成する。クライアント更新部１２３は、コンパイラおよびリンカとして動作するソフトウェアを含んでいる。ユーザソースコードは、ＡＰＩソースコードの生成後に、ＡＰＩソースコードに合うように開発者によって修正されてもよい。生成されるクライアントモジュールは、ＡＰサーバモジュール３１０に相当する。クライアント更新部１２３は、生成したクライアントモジュールをＡＰサーバ３００に配信する。

ＡＰサーバ３００に相当するコンピュータが複数存在する場合、クライアント更新部１２３は、生成したクライアントモジュールをそれら複数のコンピュータに配信する。ただし、開発者によってユーザソースコードが適切に修正されないことにより、ＡＰサーバ３００とＤＢサーバ５００の間でインタフェース不整合が生じる可能性がある。また、ＡＰサーバ３００にクライアントモジュールが適切に配信されないことにより、ＡＰサーバ３００とＤＢサーバ５００の間でインタフェース不整合が生じる可能性がある。

サーバ更新部１２４は、テーブル定義記憶部１２２に記憶されたテーブル定義ファイルが更新されると、更新後のテーブル定義ファイルをＤＢサーバ５００に送信する。そして、サーバ更新部１２４は、送信したテーブル定義ファイルをデータベースに反映させるようＤＢサーバ５００に指示する。例えば、サーバ更新部１２４は、テーブル定義変更のコマンドをＤＢサーバ５００に送信する。更新後のテーブル定義ファイルは、当該コマンドと共にＤＢサーバ５００に送信されてもよい。

ＡＰサーバ３００は、モジュール記憶部３２１およびアプリケーション制御部３２２を有する。モジュール記憶部３２１は、例えば、ＡＰサーバ３００が有するＲＡＭまたはＨＤＤの記憶領域を用いて実装される。アプリケーション制御部３２２は、例えば、ＡＰサーバ３００が有するＣＰＵが実行するプログラムを用いて実装される。

モジュール記憶部３２１は、開発端末１００から配信されたコンパイル済みのクライアントモジュールを記憶する。クライアントモジュールは、例えば、ＡＰサーバモジュール３１０に相当する断片的プログラムである。アプリケーション制御部３２２は、モジュール記憶部３２１に記憶されたクライアントモジュールを起動し、クライアントモジュールの実行を制御するアプリケーション実行基盤である。アプリケーション制御部３２２は、クライアントモジュールに従って要求メッセージをＤＢサーバ５００に送信する。

ＤＢサーバ５００は、テーブル定義記憶部５２１、ハッシュ値記憶部５２２、データ記憶部５２３、データベース設定部５２４およびデータベース操作部５２５を有する。テーブル定義記憶部５２１、ハッシュ値記憶部５２２およびデータ記憶部５２３は、例えば、ＤＢサーバ５００が有するＲＡＭまたはＨＤＤの記憶領域を用いて実装される。データベース設定部５２４およびデータベース操作部５２５は、例えば、ＤＢサーバ５００が有するＣＰＵが実行するプログラムを用いて実装される。データベース設定部５２４およびデータベース操作部５２５は、例えば、ＤＢＭＳ５１０に含まれる。

テーブル定義記憶部５２１は、開発端末１００から配信されたテーブル定義ファイルを記憶する。テーブル定義記憶部５２１は、最新のテーブル定義ファイルに加えて、１つ前の古いテーブル定義ファイルを記憶していてもよい。

ハッシュ値記憶部５２２は、データベース設定部５２４によって算出されるハッシュ値を記憶する。同じテーブル定義ファイルから開発端末１００が算出するハッシュ値とＤＢサーバ５００が算出するハッシュ値とは同一になる。前述のように、ハッシュ値に代えて他の符号をテーブル定義ファイルから生成することもでき、その場合には他の符号がハッシュ値記憶部５２２に記憶される。ハッシュ値記憶部５２２は、最新のハッシュ値に加えて、古いテーブル定義ファイルに対応するハッシュ値を記憶することも可能である。

データ記憶部５２３は、関係データベースを保持する。データ記憶部５２３には、１以上のカラム（列）と１以上のレコード（行）とを含むテーブルが記憶される。開発端末１００から受信されるコマンドに応じて、新規テーブルの追加や既存テーブルの削除が行われ得る。また、開発端末１００から受信されるコマンドに応じて、既存テーブルへのカラムの追加、カラムの削除、カラム属性の変更などが行われ得る。

データベース設定部５２４は、開発端末１００からの指示に応じてデータベースのデータ構造の設定を行う。データベース設定部５２４は、開発端末１００からテーブル定義ファイルを受信してテーブル定義記憶部５２１に格納する。データベース設定部５２４は、開発端末１００からコマンドを受信すると、テーブル定義ファイルをデータベースに対して実行する。このとき、データベース設定部５２４は、テーブル定義ファイルからハッシュ値を算出し、算出したハッシュ値をハッシュ値記憶部５２２に格納する。

データベース操作部５２５は、ＡＰサーバ３００から要求メッセージを受信する。すると、データベース操作部５２５は、受信した要求メッセージと最新のデータベースとの間のインタフェース整合性を検査する。要求メッセージで指定されたカラムがデータベースに存在しない場合や、要求メッセージに含まれるデータのデータ型がデータベースのカラムの定義と異なる場合には、インタフェース不整合が生じている。

インタフェース不整合が生じていない場合、データベース操作部５２５は、要求メッセージに従ってデータベース操作を実行する。例えば、データベース操作部５２５は、データベースからのデータの検索、データベースへのデータの挿入、データベースに含まれるデータの更新、データベースに含まれるデータの削除などを行う。データベース操作部５２５は、データベース操作の結果を示す応答メッセージをＡＰサーバ３００に送信する。一方、インタフェース不整合が生じている場合、データベース操作部５２５は、データベース操作を拒否し、エラーメッセージをＡＰサーバ３００に送信する。また、データベース操作部５２５は、ＤＢサーバ５００のシステムログにエラー情報を書き込む。

ここで、データベース操作部５２５は、インタフェース整合性の検査を効率化するため、最初にハッシュ値を利用した簡易検査を行う。データベース操作部５２５は、受信した要求メッセージに含まれるハッシュ値とハッシュ値記憶部５２２に記憶されたハッシュ値とを比較する。２つのハッシュ値が同一である場合、データベース操作部５２５は、以下の詳細検査をスキップして、インタフェース不整合は生じていないと判定する。

一方、２つのハッシュ値が異なる場合、データベース操作部５２５は、インタフェース整合性を確認する詳細検査を行う。詳細検査では、データベース操作部５２５は、受信した要求メッセージを分析し、テーブル定義記憶部５２１に記憶されたテーブル定義ファイルと照合する。例えば、データベース操作部５２５は、要求メッセージで指定されたカラムがテーブル定義ファイルに記載されているか判断する。また、例えば、データベース操作部５２５は、要求メッセージに含まれるデータのデータ型（例えば、文字列型や整数型など）およびデータ長を確認し、テーブル定義ファイルの定義と整合するか判断する。なお、要求メッセージが古いテーブル定義ファイルに準拠して生成されている場合であっても、データ構造の変更内容によってはインタフェース不整合とならない場合もある。

図６は、テーブル定義ファイルの第１の例を示す図である。
テーブル定義ファイル１３１は、更新前の古いテーブル定義ファイルの例である。テーブル定義ファイル１３２は、更新後の新しいテーブル定義ファイルの例である。テーブル定義ファイル１３３は、更新後の新しいテーブル定義ファイルの例であって、テーブル定義ファイル１３２とは異なる例である。テーブル定義ファイル１３１，１３２，１３３は、テーブル定義記憶部１２２に記憶され得る。また、テーブル定義ファイル１３１，１３２，１３３は、テーブル定義記憶部５２１にコピーされ得る。

テーブル定義ファイル１３１は、関係データベースの１つのテーブルのデータ構造を表している。テーブル定義ファイル１３１では、テーブルに含まれる各カラムのカラム名、データ型、データ長、その他の属性が定義される。テーブル定義ファイル１３１には、ＵＳＥＲ＿ＩＤ、ＤＥＰＴ＿ＮＯ、ＵＳＥＲ＿ＮＡＭＥおよびＢＩＲＴＨＤＡＹの４つのカラムが定義されている。ＵＳＥＲ＿ＩＤのデータ型は文字列型であり、データ長は８バイトであり、ＮＵＬＬ値が禁止されている。ＤＥＰＴ＿ＮＯのデータ型は文字列型であり、データ長は８バイトである。ＵＳＥＲ＿ＮＡＭＥのデータ型は文字列であり、データ長は３２バイトである。ＢＩＲＴＨＤＡＹのデータ型は日付型である。

テーブル定義ファイル１３２は、テーブル定義ファイル１３１を修正したものである。テーブル定義ファイル１３２では、末尾にＭＹＮＵＭＢＥＲというカラムが追加されている。ＭＹＮＵＭＢＥＲのデータ型は文字列であり、データ長は１２バイトである。テーブル定義ファイル１３３は、テーブル定義ファイル１３１を修正したものである。テーブル定義ファイル１３３では、ＤＥＰＴ＿ＮＯのデータ長が１０バイトに修正されている。

図７は、ハッシュ値テーブルの第１の例を示す図である。
ハッシュ値テーブル５３１は、ハッシュ値記憶部５２２に記憶される。ハッシュ値テーブル５３１は、データベース名、スキーマ名、テーブル名およびハッシュ値の項目を含む。ＤＢサーバ５００には複数のデータベースを作成することが可能であり、それら複数のデータベースがデータベース名によって識別される。１つのデータベースの中には複数のスキーマを定義することが可能であり、それら複数のスキーマがスキーマ名によって識別される。１つのスキーマの中には複数のテーブルを定義することが可能であり、それら複数のテーブルがテーブル名によって識別される。

第２の実施の形態では、１つのテーブルに対して１つのハッシュ値が登録される。ハッシュ値テーブル５３１に登録される１つのハッシュ値は、１つのテーブルの最新のテーブル定義ファイルから算出される。あるテーブルのテーブル定義ファイルが更新されると、ハッシュ値テーブル５３１では当該テーブルに対応するハッシュ値が更新される。要求メッセージには、操作対象テーブルに対応するハッシュ値が含まれている。

ここで、ハッシュ値は、テーブル名、カラム名、データ型、データ長、その他の属性などのデータ構造に関係する本質的情報に依存し、空白やコメントなどのデータ構造に関係しない非本質的情報に依存しないよう算出される。テーブル定義ファイルからは非本質的情報が削除されて本質的情報のみが抽出され、本質的情報を示す文字列がハッシュ関数に入力される。例えば、図６のテーブル定義ファイル１３１の場合、「ｔａｂｌｅ ｔｂｌ＿ａ」から「ＢＩＲＴＨＤＡＹ ＤＡＴＥ」までの部分が抽出され、この部分から空白が削除され、残った文字列がハッシュ関数に入力される。

図８は、要求メッセージの第１の例を示す図である。
要求メッセージ３３１は、ＡＰサーバ３００からＤＢサーバ５００に送信される。要求メッセージ３３１は、サーバＩＰ（Internet Protocol）アドレス、サーバポート番号、クライアントＩＤ、依頼番号、クライアントＩＰアドレス、クライアントポート番号、クライアントプロセスＩＤおよびクライアントスレッドＩＤの項目を含む。また、要求メッセージ３３１は、セッションＩＤ、送信時刻、処理種別、対象リソース、ハッシュ値、入力情報、出力情報およびデータ格納域長の項目を含む。

サーバＩＰアドレスは、ＤＢサーバ５００のＩＰアドレスである。サーバポート番号は、ＤＢサーバ５００が要求メッセージの待ち受けに使用しているポート番号である。クライアントＩＤは、ＡＰサーバ３００のアプリケーション実行基盤に対して割り当てられた識別子である。依頼番号は、ＡＰサーバ３００のアプリケーション実行基盤が各要求メッセージに付与する識別番号である。クライアントＩＰアドレスは、ＡＰサーバ３００のＩＰアドレスである。クライアントポート番号は、ＡＰサーバ３００が要求メッセージの送信に使用する送信元ポート番号である。クライアントプロセスＩＤは、クライアントモジュールから起動されたプロセスの識別番号である。クライアントスレッドＩＤは、クライアントモジュールから起動されたスレッドの識別番号である。

セッションＩＤは、ＡＰサーバ３００とＤＢサーバ５００の間に確立されたコネクションの識別番号である。送信時刻は、ＡＰサーバ３００が要求メッセージを送信した時刻である。処理種別は、データベース操作の種別であり、検索（ＳＥＬＥＣＴ）、挿入（ＩＮＳＥＲＴ）、更新（ＵＰＤＡＴＥ）または削除（ＤＥＬＥＴＥ）である。対象リソースは、操作対象テーブルのテーブル名である。ハッシュ値は、操作対象テーブルに対応するハッシュ値である。入力情報は、操作対象レコードを特定する検索条件や書き込むデータを含む。出力情報は、検索結果に含めるカラムのカラム名である。

データ格納域長は、クライアントモジュールが検索結果を格納するために用意した１レコード当たりのＲＡＭの記憶領域のバイト数である。データ格納域長を超える長さのレコードがＤＢサーバ５００からＡＰサーバ３００に送信された場合、ＡＰサーバ３００において末尾側のカラムのデータが切り捨てられる可能性がある。また、ＤＢサーバ５００は、ＡＰサーバ３００に送信するレコードの長さがデータ格納域長を超えないように、末尾側のカラムのデータを切り捨てることがある。

次に、開発端末１００およびＤＢサーバ５００の処理について説明する。
図９は、開発端末処理の手順例を示すフローチャートである。
（Ｓ１０）開発端末１００は、開発端末１００を使用する開発者からの入力に応じて、テーブル定義記憶部１２２に記憶されたテーブル定義ファイルを更新する。

（Ｓ１１）クライアント更新部１２３は、更新後のテーブル定義ファイルから、ＭＤ５やＳＨＡ−１などのハッシュ関数を用いてハッシュ値を算出する。
（Ｓ１２）クライアント更新部１２３は、更新後のテーブル定義ファイルからＡＰＩソースコードを生成する。ＡＰＩソースコードは、テーブル定義ファイルが示すデータ構造をもつデータベースに対して、データベース操作を要求する要求メッセージを送信するためのＡＰＩプログラムのソースコードである。要求メッセージの送信についてはＡＰＩプログラムを呼び出すようにユーザソースコードを作成することで、開発者によるユーザソースコードの作成負担が軽減される。クライアント更新部１２３は、要求メッセージの送信時にステップＳ１１のハッシュ値が要求メッセージに付加されるよう、生成したＡＰＩソースコードの中にハッシュ値を埋め込む。

（Ｓ１３）クライアント更新部１２３は、クライアントモジュールの処理を記載したユーザソースコードを取得する。このユーザソースコードは、ステップＳ１２の後にＡＰＩソースコードを参照して開発者が修正したものであってもよい。クライアント更新部１２３は、ユーザソースコードとＡＰＩソースコードをコンパイルし、両者とその他のライブラリとをリンクしてクライアントモジュールを生成する。

（Ｓ１４）クライアント更新部１２３は、ステップＳ１３で生成したクライアントモジュールをＡＰサーバ３００などの特定のコンピュータに対して配信する。配信先のコンピュータは、開発端末１００を使用する開発者によって指定されてもよい。

（Ｓ１５）サーバ更新部１２４は、更新されたテーブル定義ファイルをＤＢサーバ５００などの特定のコンピュータに対して配信する。配信先のコンピュータは、開発端末１００を使用する開発者によって指定されてもよい。

（Ｓ１６）サーバ更新部１２４は、ステップＳ１５の配信先のコンピュータに対して、テーブル定義ファイルをデータベースに反映させるよう指示する。反映指示のコマンドは、テーブル定義ファイルと合わせて送信してもよい。なお、第２の実施の形態ではＤＢサーバ５００が配信されたテーブル定義ファイルからハッシュ値を算出しているが、開発端末１００が算出したハッシュ値をＤＢサーバ５００に通知するようにしてもよい。

図１０は、データベース設定の第１の手順例を示すフローチャートである。
（Ｓ２０）データベース設定部５２４は、開発端末１００からテーブル定義ファイルを受信し、受信したテーブル定義ファイルをテーブル定義記憶部５２１に格納する。

（Ｓ２１）データベース設定部５２４は、開発端末１００からの指示に応じて、ステップＳ２０のテーブル定義ファイルをデータベースに反映させる。テーブル定義ファイルに記載されたテーブル名のテーブルがデータベースの中に存在しない場合、データベース設定部５２４は、テーブル定義ファイルに従って新規テーブルを生成する。一方、テーブル定義ファイルに記載されたテーブル名のテーブルがデータベースの中に存在する場合、データベース設定部５２４は、テーブル定義ファイルに従って既存テーブルを修正する。既存テーブルの修正は、新規カラムの追加や既存カラムの修正を含むことがある。既存カラムの修正は、当該カラムのデータを変換することを含む場合がある。

（Ｓ２２）データベース設定部５２４は、ステップＳ２０のテーブル定義ファイルから、ＭＤ５やＳＨＡ−１などのハッシュ関数を用いてハッシュ値を算出する。
（Ｓ２３）データベース設定部５２４は、テーブル定義ファイルに記載されたテーブル名に対応付けて、ステップＳ２２で算出したハッシュ値をハッシュ値テーブル５３１に登録する。当該テーブル名に対応する古いハッシュ値がハッシュ値テーブル５３１に存在する場合、データベース設定部５２４は、新しいハッシュ値を上書き保存する。よって、１つのテーブルに対しては最新のハッシュ値のみが登録される。

図１１は、データベース操作の第１の手順例を示すフローチャートである。
（Ｓ３０）データベース操作部５２５は、データベース操作を要求する要求メッセージをクライアントモジュールから受信する。要求メッセージには、クライアントモジュールに埋め込まれたハッシュ値が含まれている。

（Ｓ３１）データベース操作部５２５は、要求メッセージからハッシュ値を抽出する。
（Ｓ３２）データベース操作部５２５は、ハッシュ値テーブル５３１から、要求メッセージが示す操作対象テーブルに対応付けられたハッシュ値を検索する。

（Ｓ３３）データベース操作部５２５は、ステップＳ３１のハッシュ値とステップＳ３２のハッシュ値とを比較し、２つのハッシュ値が一致するか判断する。一致する場合、受信した要求メッセージについてインタフェース不整合は生じていないと判定され、ステップＳ３６に処理が進む。一致しない場合、ステップＳ３４に処理が進む。

（Ｓ３４）データベース操作部５２５は、インタフェース整合性の詳細検査を行う。詳細検査では、データベース操作部５２５は、受信した要求メッセージを分析してテーブル定義ファイルに記載されたカラムの定義と照合する。例えば、データベース操作部５２５は、カラム名、データ型、データ長などの整合性を確認する。

（Ｓ３５）データベース操作部５２５は、ステップＳ３４の詳細分析の結果から、インタフェース整合性が満たされているか判断する。インタフェース整合性が満たされている場合、すなわち、インタフェース不整合が生じていない場合、ステップＳ３６に処理が進む。インタフェース整合性が満たされていない場合、すなわち、インタフェース不整合が生じている場合、ステップＳ３８に処理が進む。

（Ｓ３６）データベース操作部５２５は、要求メッセージに従って、データベースに対する検索、挿入、更新、削除などのデータベース操作を実行する。
（Ｓ３７）データベース操作部５２５は、データベース操作の結果を示す応答メッセージを生成し、要求元のクライアントモジュールに対して送信する。応答メッセージは、検索されたデータを含むことがあり、書き込みの成否を示す制御情報を含むことがある。

（Ｓ３８）データベース操作部５２５は、インタフェース不整合が生じたことを示すエラーメッセージを生成し、要求元のクライアントモジュールに対して送信する。また、データベース操作部５２５は、ＤＢサーバ５００が保持するシステムログに、インタフェース不整合が生じたことを示すエラー情報を書き込む。システムログは、開発端末１００に送信されてもよく、障害原因の分析を行う担当者に対して送信されてもよい。

図１２は、インタフェース整合性の第１の判定例を示す図である。
ここでは、テーブル定義ファイル１３１がテーブル定義ファイル１３２に更新された場合を考える。すなわち、既存テーブルの末尾に新規カラムが追加されている。

クライアントモジュール３３３は、テーブル定義ファイル１３１に基づいて生成された古いクライアントモジュールである。クライアントモジュール３３３が送信する要求メッセージには、テーブル定義ファイル１３１から算出されたハッシュ値「０ｘｈｇｆｅｄｃｂａ」が付加される。クライアントモジュール３３４は、テーブル定義ファイル１３２から生成された新しいクライアントモジュールである。クライアントモジュール３３４が送信する要求メッセージには、テーブル定義ファイル１３２から算出されたハッシュ値「０ｘａｂｃｄｅｆｇｈ」が付加される。ＤＢＭＳ５１０は、最新のハッシュ値「０ｘａｂｃｄｅｆｇｈ」を保持している。これに対し、クライアントモジュール３３４の配信ミスによって、まだクライアントモジュール３３３が実行されるコンピュータが存在しているとする。

ＤＢＭＳ５１０は、クライアントモジュール３３４から受信する要求メッセージについては、要求メッセージに含まれるハッシュ値とＤＢＭＳ５１０が保持するハッシュ値とが一致するため、インタフェース不整合が生じていないと判定する。一方、ＤＢＭＳ５１０は、クライアントモジュール３３３から受信する要求メッセージについては、要求メッセージに含まれるハッシュ値とＤＢＭＳ５１０が保持するハッシュ値とが異なるため、インタフェース不整合が生じている可能性があると判定する。その場合、ＤＢＭＳ５１０は、詳細検査によりインタフェース整合性を判定する。

このように、カラムを末尾に追加するデータ構造の変更が行われた場合、テーブル定義ファイルのハッシュ値が変化する。第２の実施の形態の簡易検査では、カラム追加後の新しいデータ構造に依拠する要求メッセージのみがインタフェース不整合なしと判定される。カラム追加前の古いデータ構造に依拠する要求メッセージについては、インタフェース不整合の可能性があるとして詳細検査が実行される。

図１３は、インタフェース整合性の第２の判定例を示す図である。
ここでは、テーブル定義ファイル１３１がテーブル定義ファイル１３３に更新された場合を考える。すなわち、既存テーブルのカラムのデータ長が変更されている。

クライアントモジュール３３５は、テーブル定義ファイル１３３から生成された新しいクライアントモジュールである。クライアントモジュール３３５が送信する要求メッセージには、テーブル定義ファイル１３３から算出されたハッシュ値「０ｘｋｌｍｎｏｐｑｒ」が付加される。ＤＢＭＳ５１０は、最新のハッシュ値「０ｘｋｌｍｎｏｐｑｒ」を保持している。これに対し、クライアントモジュール３３５の配信ミスによって、まだクライアントモジュール３３３が実行されるコンピュータが存在しているとする。

ＤＢＭＳ５１０は、クライアントモジュール３３５から受信する要求メッセージについては、要求メッセージに含まれるハッシュ値とＤＢＭＳ５１０が保持するハッシュ値とが一致するため、インタフェース不整合が生じていないと判定する。一方、ＤＢＭＳ５１０は、クライアントモジュール３３３から受信する要求メッセージについては、要求メッセージに含まれるハッシュ値とＤＢＭＳ５１０が保持するハッシュ値とが異なるため、インタフェース不整合が生じている可能性があると判定する。その場合、ＤＢＭＳ５１０は、詳細検査によりインタフェース整合性を判定する。

このように、カラムのデータ長を変えるデータ構造の変更が行われた場合、テーブル定義ファイルのハッシュ値が変化する。第２の実施の形態の簡易検査では、データ長変更後の新しいデータ構造に依拠する要求メッセージのみがインタフェース不整合なしと判定される。データ長変更前の古いデータ構造に依拠する要求メッセージについては、インタフェース不整合の可能性があるとして詳細検査が実行される。

以上、ＡＰサーバ３００からＤＢサーバ５００に送信される要求メッセージの検査について説明した。キャッシュサーバ４００からＤＢサーバ５００に送信される要求メッセージも同様の方法で検査することができる。その場合、ユーザソースコードとＡＰＩソースコードからキャッシュサーバ４００用のクライアントモジュールが生成される。ただし、キャッシュサーバ４００用のユーザソースコードを、開発者が作成したＳＱＬ埋め込みプログラムからプレコンパイルにより生成するようにしてもよい。

また、ＡＰサーバ３００からキャッシュサーバ４００に送信される要求メッセージも同様の方法で検査することができる。その場合、開発者によりＫＶＳ４１０用のテーブル定義ファイルが作成され、そのテーブル定義ファイルからハッシュ値が算出されると共にＡＰＩソースコードが生成される。以下、ＫＶＳ４１０用のテーブル定義ファイルと、ＡＰサーバ３００からキャッシュサーバ４００への要求メッセージの例を説明する。

図１４は、テーブル定義ファイルの第２の例を示す図である。
テーブル定義ファイル１３４は、キーバリュー形式のデータベースのデータ構造を表している。キーバリュー形式のデータベースは、１つのキーに対応付けて１つのバリューを記憶する。バリューは２以上のバリュー項目を含んでもよい。

テーブル定義ファイル１３４では、キーおよび１以上のバリュー項目それぞれの名称、データ型およびデータ長が定義される。テーブル定義ファイル１３４には、ＵＳＥＲＩＤ、ＣＯＭＰＡＮＹ、ＬＮＡＭＥ、ＦＮＡＭＥ、ＥＭＡＩＬおよびＰＡＳＳＷＤが定義されている。ＵＳＥＲＩＤはキーであり、データ型は文字列型であり、データ長は４バイトである。ＣＯＭＰＡＮＹは１番目のバリュー項目であり、データ型は整数型である。ＬＮＡＭＥは２番目のバリュー項目であり、データ型は文字列型であり、データ長は２５５バイトである。ＦＮＡＭＥは３番目のバリュー項目であり、データ型は文字列型であり、データ長は２５５バイトである。ＥＭＡＩＬは４番目のバリュー項目であり、データ型は文字列型であり、データ長は２５５バイトである。ＰＡＳＳＷＤは５番目のバリュー項目であり、データ型は文字列型であり、データ長は２５５バイトである。

開発端末１００は、テーブル定義ファイル１３４からハッシュ値を算出し、テーブル定義ファイル１３４から当該ハッシュ値を埋め込んだクライアントモジュールを生成し、ＡＰサーバ３００に配信する。また、開発端末１００は、テーブル定義ファイル１３４をキャッシュサーバ４００に配信する。キャッシュサーバ４００は、テーブル定義ファイル１３４をデータベースに反映させる。また、キャッシュサーバ４００は、テーブル定義ファイル１３４からハッシュ値を算出して保持しておく。

図１５は、要求メッセージの第２の例を示す図である。
要求メッセージ３３２は、ＡＰサーバ３００からキャッシュサーバ４００に送信される。要求メッセージ３３２は、サーバＩＰアドレス、サーバポート番号、クライアントＩＤ、依頼番号、クライアントＩＰアドレス、クライアントポート番号、クライアントプロセスＩＤおよびクライアントスレッドＩＤの項目を含む。また、要求メッセージ３３２は、セッションＩＤ、送信時刻、処理種別、対象リソース、ハッシュ値、入力情報およびデータ格納域長の項目を含む。クライアントＩＤ、依頼番号、クライアントＩＰアドレス、クライアントポート番号、クライアントプロセスＩＤ、クライアントスレッドＩＤおよび送信時刻は、前述の要求メッセージ３３１と同様である。

サーバＩＰアドレスは、キャッシュサーバ４００のＩＰアドレスである。サーバポート番号は、キャッシュサーバ４００が要求メッセージの待ち受けに使用しているポート番号である。セッションＩＤは、ＡＰサーバ３００とキャッシュサーバ４００の間に確立されたコネクションの識別番号である。処理種別は、データベース操作の種別であり、取得（ｇｅｔ）、保存（ｐｕｔ）または削除（ｄｅｌｅｔｅ）である。

対象リソースは、操作対象データストアの名称である。ハッシュ値は、操作対象データストアに対応するハッシュ値である。キャッシュサーバ４００は、要求メッセージ３３２に含まれるハッシュ値と保持しているハッシュ値とを比較し、両者が一致した場合にはインタフェース不整合は生じていないと判定する。入力情報は、取得対象レコードのキー、保存するバリューまたは削除対象レコードのキーを含む。

データ格納域長は、クライアントモジュールが取得レコードを格納するために用意した１レコード当たりのＲＡＭの記憶領域のバイト数である。データ格納域長を超える長さのレコードがキャッシュサーバ４００からＡＰサーバ３００に送信された場合、ＡＰサーバ３００において末尾側のバリュー項目のデータが切り捨てられる可能性がある。また、キャッシュサーバ４００は、ＡＰサーバ３００に送信するレコードの長さがデータ格納域長を超えないように、末尾側のバリュー項目のデータを切り捨てることがある。

第２の実施の形態の情報処理システムによれば、更新されたテーブル定義ファイルのハッシュ値が算出され、ハッシュ値の埋め込まれたクライアントモジュールが生成されてクライアント側コンピュータに配信される。このクライアントモジュールを実行することで、ハッシュ値を含む要求メッセージが送信される。また、更新されたテーブル定義ファイルに基づいてデータベースのデータ構造が変更され、サーバ側コンピュータにハッシュ値が登録される。そして、要求メッセージに含まれるハッシュ値とサーバ側コンピュータがもつ最新のハッシュ値とが比較され、両者が一致する場合には詳細検査をスキップして、インタフェース不整合は生じていないと判定される。

これにより、クライアントモジュールの修正ミスや配信ミスなどによってインタフェース不整合が生じ得る場合であっても、インタフェース整合性の検査を効率的に行うことが可能となる。よって、データベースのデータ構造の変更後に、様々なバリエーションの要求メッセージを用いた長時間のリグレッションテストを行わなくてもよく、運用再開までの時間を短縮できる。また、サーバ側コンピュータの検査の負荷が軽減されるため、運用中に継続的にインタフェース整合性の検査を行うこともできる。また、データベースのデータ構造に合ったＡＰＩソースコードが自動的に生成されるため、開発者によるユーザソースコードの作成の負担が軽減される。

［第３の実施の形態］
次に、第３の実施の形態を説明する。第２の実施の形態との違いを中心に説明し、第２の実施の形態と同様の内容については説明を省略することがある。

第２の実施の形態では、末尾に新規カラムを追加する変更のみであっても、変更前のデータ構造を想定した要求メッセージと変更後のデータ構造をもつデータベースとの間で、インタフェース不整合が生じる可能性があると判定している。しかし、末尾に新規カラムを追加するだけでは、通常、インタフェース不整合によるエラーは発生しない。

特定のカラムに限定して検索や更新を行う要求メッセージについては、当該カラムが新規カラム追加の影響を受けないため、変更後のデータベースに対しても正しく実行することが可能である。特定のカラムに限定せずに全てのカラムを対象として検索を行う要求メッセージについては、新規カラム追加の影響を受けて、データベースから抽出される各レコードの長さが大きくなる。しかしながら、クライアントモジュールが用意する記憶領域の不足によって、末尾にある新規カラムのデータはクライアント側コンピュータで破棄される。または、要求メッセージで指定されたデータ格納域長に基づいて、末尾にある新規カラムのデータがサーバ側コンピュータで破棄される。よって、結果的にクライアントモジュールが認識するレコード長は新規カラム追加の影響を受けない。

そこで、第３の実施の形態では、末尾に新規カラムを追加するデータ構造の変更があった場合には、変更前のデータ構造を想定した要求メッセージに対して、インタフェース不整合は生じていないと簡易検査において判定できるようにする。第３の実施の形態の情報処理システムは、図２〜６に示した第２の実施の形態の情報処理システムと同様の構成によって実現できる。以下、図２〜６の符号を用いて第３の実施の形態を説明する。

図１６は、ハッシュ値テーブルの第２の例を示す図である。
ハッシュ値テーブル５３２は、第２の実施の形態のハッシュ値テーブル５３１に代えて、ＤＢサーバ５００のハッシュ値記憶部５２２に記憶される。ハッシュ値テーブル５３２は、データベース名、スキーマ名、テーブル名、ハッシュ値数、タイムスタンプおよびハッシュ値の項目を含む。第３の実施の形態では、１つのテーブルに対して１以上のハッシュ値が登録される。ハッシュ値数は、あるテーブルに対応付けて登録されているハッシュ値の数である。タイムスタンプは、ハッシュ値がハッシュ値テーブル５３２に登録された時刻を示す。１つのハッシュ値は１つのテーブル定義ファイルから算出される。

あるテーブルのテーブル定義ファイルが更新されると、更新内容に応じて、当該テーブルに対応付けられた既存ハッシュ値が削除されて新規ハッシュ値のみ記憶されるか、または、既存ハッシュ値を残して新規ハッシュ値が追加される。データ構造の変更が新規テーブルの追加または既存テーブルに対する新規カラムの後方追加である場合、既存ハッシュ値は削除されない。それ以外の場合、既存ハッシュ値が削除される。要求メッセージに含まれるハッシュ値が、ハッシュ値テーブル５３２に登録された１以上のハッシュ値の何れかと一致すれば、インタフェース不整合は生じていないと判定される。

図１７は、データベース設定の第２の手順例を示すフローチャートである。
（Ｓ４０）データベース設定部５２４は、開発端末１００からテーブル定義ファイルを受信し、受信したテーブル定義ファイルをテーブル定義記憶部５２１に格納する。

（Ｓ４１）データベース設定部５２４は、開発端末１００からの指示に応じて、ステップＳ４０のテーブル定義ファイルをデータベースに反映させる。
（Ｓ４２）データベース設定部５２４は、テーブル定義記憶部５２１に記憶されていた１以上の旧テーブル定義ファイルとステップＳ４０の新テーブル定義ファイルとを比較し、データ構造の変更の種別を判定する。新テーブル定義ファイルに記載されたテーブル名が何れの旧テーブル定義ファイルにも出現しない場合、種別はテーブル追加と判定される。新テーブル定義ファイルとテーブル名が同じ旧テーブル定義ファイルが存在し、当該旧テーブル定義ファイルのカラムの全てが新テーブル定義ファイルにも記載されており、その後方に新規カラムが追加されている場合、種別はカラム後方追加と判定される。新テーブル定義ファイルとテーブル名が同じ旧テーブル定義ファイルが存在し、当該旧テーブル定義ファイルに記載されたカラムの少なくとも１つについてカラム名、データ型またはデータ長が変化している場合、種別はカラム修正と判定される。

（Ｓ４３）データベース設定部５２４は、ステップＳ４２で判定したデータ構造の変更の種別がテーブル追加またはカラム後方追加であるか判断する。データ構造の変更の種別がテーブル追加またはカラム後方追加である場合、ステップＳ４５に処理が進む。データ構造の変更の種別がそれ以外の場合、ステップＳ４４に処理が進む。

（Ｓ４４）データベース設定部５２４は、ハッシュ値テーブル５３２から、新テーブル定義ファイルに記載されたテーブル名に対応するハッシュ値を全て削除する。
（Ｓ４５）データベース設定部５２４は、新テーブル定義ファイルから、ＭＤ５やＳＨＡ−１などのハッシュ関数を用いてハッシュ値を算出する。

（Ｓ４６）データベース設定部５２４は、新テーブル定義ファイルに記載されたテーブル名に対応付けて、ステップＳ４５で算出したハッシュ値をハッシュ値テーブル５３２に追加する。このとき、現在時刻を示すタイムスタンプをハッシュ値に付加する。

よって、データ構造の変更の種別がテーブル追加である場合、当該テーブルに対応するハッシュ値が新たに登録される。データ構造の変更の種別がカラム後方追加である場合、当該テーブルに対応する既存のハッシュ値を全て履歴として残したまま、新しいハッシュ値が追加される。履歴として残すハッシュ値の数は制限されず、カラム後方追加が連続して行われた場合には履歴として残すハッシュ値が増加する。これに対し、データ構造の変更の種別がテーブル追加でもカラム後方追加でもない場合、当該テーブルに対応する既存のハッシュ値の全てが削除され、新しいハッシュ値のみが登録される。

図１８は、データベース操作の第２の手順例を示すフローチャートである。
（Ｓ５０）データベース操作部５２５は、データベース操作を要求する要求メッセージをクライアントモジュールから受信する。要求メッセージには、クライアントモジュールに埋め込まれたハッシュ値が含まれている。

（Ｓ５１）データベース操作部５２５は、要求メッセージからハッシュ値を抽出する。
（Ｓ５２）データベース操作部５２５は、ハッシュ値テーブル５３２から、要求メッセージが示す操作対象テーブルに対応付けられた１以上のハッシュ値を検索する。

（Ｓ５３）データベース操作部５２５は、ステップＳ５２で検索された１以上のハッシュ値のうち、タイムスタンプが新しい方から優先的にハッシュ値を１つ選択する。
（Ｓ５４）データベース操作部５２５は、ステップＳ５１のハッシュ値とステップＳ５３のハッシュ値とを比較し、２つのハッシュ値が一致するか判断する。一致する場合、受信した要求メッセージについてインタフェース不整合は生じていないと判断され、ステップＳ５８に処理が進む。一致しない場合、ステップＳ５５に処理が進む。

（Ｓ５５）データベース操作部５２５は、ステップＳ５２で検索された全てのハッシュ値を選択したか判断する。全てのハッシュ値を選択した場合はステップＳ５６に処理が進み、未選択のハッシュ値がある場合はステップＳ５３に処理が進む。よって、操作対象テーブルに履歴も含めて２以上のハッシュ値が対応付けられている場合、そのうち何れか１つのハッシュ値が要求メッセージのハッシュ値と一致すれば、インタフェース不整合は生じていないと判断される。３世代以上のハッシュ値が登録されていることがあり、そのうち最も古い世代のハッシュ値と要求メッセージのハッシュ値とが一致する可能性もある。

（Ｓ５６）データベース操作部５２５は、インタフェース整合性の詳細検査を行う。詳細検査では、データベース操作部５２５は、受信した要求メッセージを分析してテーブル定義ファイルに記載されたカラムの定義と照合する。

（Ｓ５７）データベース操作部５２５は、ステップＳ５６の詳細分析の結果から、インタフェース整合性が満たされているか判断する。インタフェース整合性が満たされている場合、すなわち、インタフェース不整合が生じていない場合、ステップＳ５８に処理が進む。インタフェース整合性が満たされていない場合、すなわち、インタフェース不整合が生じている場合、ステップＳ６０に処理が進む。

（Ｓ５８）データベース操作部５２５は、要求メッセージに従って、データベースに対する検索、挿入、更新、削除などのデータベース操作を実行する。
（Ｓ５９）データベース操作部５２５は、データベース操作の結果を示す応答メッセージを生成し、要求元のクライアントモジュールに対して送信する。

（Ｓ６０）データベース操作部５２５は、インタフェース不整合が生じたことを示すエラーメッセージを生成し、要求元のクライアントモジュールに対して送信する。また、データベース操作部５２５は、ＤＢサーバ５００が保持するシステムログに、インタフェース不整合が生じたことを示すエラー情報を書き込む。

図１９は、インタフェース整合性の第３の判定例を示す図である。
ここでは、図６のテーブル定義ファイル１３１がテーブル定義ファイル１３２に更新された場合を考える。すなわち、既存テーブルの末尾に新規カラムが追加されている。

クライアントモジュール３３３は、テーブル定義ファイル１３１に基づいて生成された古いクライアントモジュールであり、ハッシュ値「０ｘｈｇｆｅｄｃｂａ」を含む要求メッセージを送信する。クライアントモジュール３３４は、テーブル定義ファイル１３２から生成された新しいクライアントモジュールであり、ハッシュ値「０ｘａｂｃｄｅｆｇｈ」を含む要求メッセージを送信する。ＤＢＭＳ５１０は、データ構造の変更がカラム後方追加であるため、最新のハッシュ値「０ｘａｂｃｄｅｆｇｈ」に加えて少なくとも１つ前のハッシュ値「０ｘｈｇｆｅｄｃｂａ」を履歴として保持している。なお、ＤＢＭＳ５１０は、２つ前のハッシュ値など更に多くのハッシュ値を履歴として保持することもある。ＤＢＭＳ５１０は、種別がテーブル追加またはカラム後方追加であるデータ構造の変更のみが行われている間は、古いハッシュ値を何世代でも保持し続けることができる。

ＤＢＭＳ５１０は、クライアントモジュール３３４から受信する要求メッセージについて、要求メッセージに含まれるハッシュ値とＤＢＭＳ５１０が保持する最新のハッシュ値とが一致するため、インタフェース不整合が生じていないと判定する。また、ＤＢＭＳ５１０は、クライアントモジュール３３３から受信する要求メッセージについて、要求メッセージに含まれるハッシュ値とＤＢＭＳ５１０が保持するハッシュ値の履歴とが一致するため、インタフェース不整合が生じていないと判定する。

なお、テーブル定義ファイル１３１がテーブル定義ファイル１３３に更新された場合は、データ構造の変更がカラム修正であるため、ＤＢＭＳ５１０は１つ前のハッシュ値「０ｘｈｇｆｅｄｃｂａ」を削除し最新のハッシュ値「０ｘｋｌｍｎｏｐｑｒ」のみを保持する。よって、簡易検査の結果は図１３と同様となる。

第３の実施の形態の情報処理システムによれば、第２の実施の形態と同様の効果が得られる。更に、第３の実施の形態では、データ構造の変更がカラム後方追加のみである場合、変更前のデータ構造を想定した要求メッセージに対して、インタフェース不整合は生じないと簡易検査において判定される。よって、その場合には詳細検査をスキップでき、インタフェース整合性の検査を効率化できる。

１０，２０ 情報処理装置
１１ 記憶部
１１ａ，１４ａ 符号
１２ 通信部
１３ 処理部
１４ 要求メッセージ
１５ 例外処理

Claims (11)

1. データベースに定義された１以上のデータ項目を示すデータ構造情報から生成された第１の符号を記憶する記憶部と、
   前記データベースに対するデータの読み出しまたは書き込みを要求するメッセージであって第２の符号を含む要求メッセージを受信する通信部と、
   前記第１の符号と前記第２の符号とを比較し、前記第１の符号と前記第２の符号とが一致する場合、要求された前記読み出しまたは書き込みを許容し、前記第１の符号と前記第２の符号とが異なる場合、前記データベースのデータ項目と前記要求メッセージとの間の整合性についての例外処理を実行する処理部と、
   を有する情報処理装置。
2. 前記データ構造情報は、前記データベースに対してデータ項目の定義の変更が行われた場合における変更後のデータ項目を示しており、
   前記記憶部は、前記データ項目の定義の変更が所定の条件を満たす場合、変更前のデータ項目を示す他のデータ構造情報から生成された第３の符号を更に記憶しており、
   前記処理部は、前記記憶部に前記第３の符号が記憶されている場合、前記第１の符号と前記第２の符号とが異なっても、前記第３の符号と前記第２の符号とが一致すれば、要求された前記読み出しまたは書き込みを許容する、
   請求項１記載の情報処理装置。
3. 前記データ項目の定義の変更が前記所定の条件を満たさない場合、前記第３の符号が前記記憶部から削除されて前記第１の符号が前記記憶部に格納される、
   請求項２記載の情報処理装置。
4. 前記所定の条件は、前記データ項目の定義の変更が前記データベースの所定の位置に新しいデータ項目を追加することである、
   請求項２記載の情報処理装置。
5. 前記記憶部は、前記所定の条件を満たす複数回のデータ項目の定義の変更が行われた場合、前記複数回のデータ項目の定義の変更に対応する複数の符号を履歴として保持し、
   前記複数回のデータ項目の定義の変更の後に前記所定の条件を満たさないデータ項目の定義の変更が行われると、前記記憶部から前記履歴が削除される、
   請求項２記載の情報処理装置。
6. 前記第１の符号は、前記データ構造情報から生成されたハッシュ値である、
   請求項１記載の情報処理装置。
7. 前記ハッシュ値は、前記データ構造情報に記載されたデータ項目名、データ型およびデータ長の少なくとも１つと所定のハッシュ関数とを用いて生成される、
   請求項６記載の情報処理装置。
8. 前記記憶部は、前記データ構造情報を更に記憶し、
   前記例外処理は、前記データ構造情報と前記要求メッセージとを比較して前記整合性を判定し、不整合と判定した場合にエラー情報を出力することを含む、
   請求項１記載の情報処理装置。
9. データベースに対するデータの読み出しまたは書き込みを要求するメッセージであって第２の符号を含む要求メッセージを送信する第１の情報処理装置と、
   前記データベースに定義された１以上のデータ項目を示すデータ構造情報から生成された第１の符号を保持し、前記要求メッセージを受信する第２の情報処理装置とを有し、
   前記第２の情報処理装置は、前記第１の符号と前記第２の符号とを比較し、前記第１の符号と前記第２の符号とが一致する場合、要求された前記読み出しまたは書き込みを許容し、前記第１の符号と前記第２の符号とが異なる場合、前記データベースのデータ項目と前記要求メッセージとの間の整合性についての例外処理を実行する、
   情報処理システム。
10. 前記データ構造情報に基づいて、前記要求メッセージの送信に用いられるプログラムであって前記第２の符号が埋め込まれたクライアントプログラムを生成し、前記クライアントプログラムを前記第１の情報処理装置に配信する第３の情報処理装置を更に有する、
    請求項９記載の情報処理システム。
11. コンピュータに、
    データベースに対するデータの読み出しまたは書き込みを要求するメッセージであって第２の符号を含む要求メッセージを取得し、
    前記データベースに定義された１以上のデータ項目を示すデータ構造情報から生成された前記コンピュータが保持する第１の符号と、前記第２の符号とを比較し、
    前記第１の符号と前記第２の符号とが一致する場合、要求された前記読み出しまたは書き込みを許容し、前記第１の符号と前記第２の符号とが異なる場合、前記データベースのデータ項目と前記要求メッセージとの間の整合性についての例外処理を実行する、
    処理を実行させるプログラム。

Images