JPH09512358A - インタフェース装置及び方法 - Google Patents

Abstract

(57)【要約】 インタフェース装置は、データ管理システムにおいて使用されるものであり、複数のアプリケーションプログラム間のインタフェースを行う。各アプリケーションは、トランザクションを実行するための装置依存メッセージを要求し、クライアント装置は実行すべきトランザクションを要求できるようになっている。インタフェース装置は、クライアント装置から装置独立メッセージを受ける。各メッセージはキーワードを含んでいる。そしてインタフェース装置がこれらを装置依存メッセージに翻訳する。その翻訳したメッセージはアプリケーションプログラムに送られる。

Description

【発明の詳細な説明】 インタフェース装置及び方法 本発明は、データ管理システムにおいてアプリケーションプログラム間のイン タフェースを行い、トランザクションを実行するために各アプリケーションプロ グラムが装置依存メッセージを要求することができ、クライアント装置は実行す べきトランザクションを要求することのできるインタフェース装置及び方法に関 する。 大型コンピュータシステムの開発は、企業にとって莫大な資金の投資を要する 。これらのコンピュータシステムを用いてソフトウェアを開発する場合には、ハ ードウェア以上にコストが一層かかる。この理由としては、ハードウェアがしば しば改良されたりリプレースされたりするのに対し、ソフトウェアは長年にわた ってそのまま使用され続け、他のコンピュータシステムによく再使用されるもの だからである。大型コンピュータシステム、例えばデータベースにアクセスする ためのシステムは、通常、多くのアプリケーションプログラムの形のソフトウェ アを備えている。これらアプリケーションプログラムは、中央メインフレームコ ンピュータ及び多数のクライアント装置又は端末に常駐しており、メインフレー ムから遠隔の場所にあり、データベースからの情報を要求するコンピュータシス テムのユーザによって使用されるものである。 アプリケーションは、多くの機能を実行する。例えば、これらアプリケーショ ンは、クライアント装置との対話を特定 し、データベースにアクセスし（通常、データベース管理システムを通じてアク セスする）、ある仕事の規則を割り当てる。例えば、ひとたび顧客の注文が取ら れると、顧客のアポイントメントだけを行う等を特定し、これにより所定のもの だけが製作され得る等が挙げられる。一般には、多くのアプリケーションプログ ラムが存在し、各アプリケーションプログラムは、データベース上に記憶されて いるデータに関連する特定のトランザクションを実行する。例えば、特定の口座 にアクセスし、注文を乗せ、特定の位置に備考の詳細を加え、広告に出す等をす る。大型コンピュータ上のアプリケーションプログラムは、何百もの行からなる ソフトウェアコードを有しており、これにより大きな投資を行っている。アプリ ケーションプログラムは一般にモジューラとして設計されており、例えば異種の データベースのために再使用される。 １９８０年代に書かれた多くのアプリケーションプログラムは、いわゆる“ダ ム(dumb)”端末によってアクセスされるように設計されており、装置依存データ ストリームの授受や出力をするように設計されている。ダム端末には、次のこと が必要とされる。すなわち、ダム端末に送られてくる情報には、ハードウェア制 御が含まれている必要がある。このハードウェア制御は、ダム端末として使用さ れる所定の装置を特定するものであり、ダム端末に送られた情報が表示されるよ うに特定する。 低コストのパーソナルコンピュータ（ＰＣ）の出現により、大型コンピュータ の多くのユーザは、このＰＣをメインフレ ームコンピュータにアクセスするためのクライアント装置として利用している。 このことは、ダム端末をエミュレートするＰＣ上のソフトウェアを走らせること によって達成できる。さらに、ＰＣ又は他のインテリジェントクライアント装置 のユーザは、アクセスのために、それら端末の知能を使用してダム端末の場合よ りも一層柔軟な方法でメインフレームコンピュータによって記憶されたデータを 操作することを求めている。 これを達成するための周知の技術の一つとして、“フェースリフティング(fac e lifting)”として知られる“画面スクラッピング(screen scraping)”がある 。画面スクラッピング技術は、ダム端末エミュレータを用いるが、ユーザとの対 話を要せず、更なる別のプログラムがＰＣ上を走る。このＰＣは、ダム端末エミ ュレータを介してメインフレームとの対話を自動的に操作する。この場合、ユー ザとの対話は必要とされない。ひとたびメインフレームからの要求されているデ ータがＰＣにおいて受け取られると、そのデータは連結され、メインフレームコ ンピュータによって指示された画面のフォーマットに制限されることなく、ユー ザにより選択されたフォーマットで表示される。これにより、ＰＣのユーザは、 より現代的で親しみやすい画面インタフェースを特定できることになる。さらに 、ＰＣ上における画面スクラッピングのソフトウェアは、メインフレームコンピ ュータによって出力される多くフォーマットされたダム端末画面からデータが得 られ、このデータは単一の画面上に表示できるようにプログラ ムされる。例えば、もしコンピュータシステムが電話オペレータ用の顧客データ ベースを備えていれば、ＰＣ上の画面スクラッピングプログラムに入力された顧 客の電話番号は、顧客のプロフィール（例えば、住所、登録電話機、最終領収日 など）を得るために使用される。こうして、ＰＣのユーザは、新機能のもとで大 型コンピュータに要求すべきことを決定することができ、また、ＰＣのもとで画 面スクラッピングソフトウェアをプログラミングすることによって、メインフレ ームコンピュータ上に常駐している大型アプリケーションプログラムを再プログ ラミングすることによって達成させる場合に比べ、一層速く上記機能を達成でき る。このような画面スクラッピングのソフトウェアは、購入可能となっている。 例えば、アタッチメイト社（アタッチメイト・セールス・ユーケー有限会社，ア タッチメイト・ハウス，１０２ マークハムミューズ，ボード通り，ウォーキン ガム，バークシァー，ＲＧ１１ １ＡＨ）は、“Ｅｘｔｒａ！”及び“Ｅｘｔｒ ａ！ ｆｏｒ Ｗｉｎｄｏｗｓ”と呼ばれる画面スクラッピングソフトウェアを 販売している。 画面スクラッピングはＰＣユーザの要求に応じてすぐにに処理するけれども、 コンピュータシステム全体としては困難な問題が多く発生する。画面スクラッピ ングソフトウェアの使用にあたっては、アプリケーションプログラムによって出 力される装置依存データストリームについての詳しい知識を必要とする。すなわ ち、アプリケーションプログラムによって送られるフォーマットされた画面に現 れるデータの特定位 置を知っている必要がある。このため、出力に影響するようなアプリケーション プログラムに対する変更は、画面スクラッピングソフトウェアの動作に影響を与 えることになる。したがって、アプリケーションプログラムを開発するときには いつでも、メインフレームコンピュータによって提供される全てのインテリジェ ントクライアント装置を同時に変更する必要がある。こうした厳しい構築管理の 問題から次のようなことが生じる。すなわち、アプリケーションプログラムが改 善させず更新されないことに関して、画面スクラッピング能力の向上を求めるＰ Ｃユーザからの圧迫を生じさせることになる。この結果、前端のＰＣクライアン トが後端のメインフレームの開発を束縛することになる。 さらに、画面スクラッピングソフトウェアを介して、メインフレームのアプリ ケーションプログラムのＰＣクライアントが多くのトランザクションを簡単に要 求できることから生じる問題もある。これらのトランザクションはＰＣクライア ントによって逐次動作するので、ＰＣにおける応答時間が逆効果として表れ、Ｐ Ｃとメインフレームとの間におけるネットワークのトラフィック量が実質的に増 加する。さらに、多数のＰＣクライアントが画面スクラッピングを使用すること になると、ダム端末のクライアントと対話するユーザのワークレートを扱うため に設計／調整されたメインフレームコンピュータの性能が低下することになる。 本発明の第１の観点によれば、データ管理システムにおいて複数のアプリケー ションプログラム間のインタフェースを 行い、トランザクションを実行するために各アプリケーションプログラムが装置 依存メッセージを要求し、実行すべきトランザクションをクライアント装置が要 求することのできるインタフェース装置であって、 前記クライアント装置から、キーワードを含んだ装置独立メッセージを受ける 第１の入力手段と、 装置依存メッセージをアプリケーションプログラムに送る第１の出力手段と、 アプリケーションプログラムから装置依存メッセージを受ける第２の入力手段 と、 装置独立メッセージを前記クライアント装置に送る第２の出力手段と、 キーワードと、前記キーワードの各々が関連するトランザクションを識別する ためのデータと、前記トランザクションの各々を実行することが要求されている 前記装置依存メッセージとを記憶する記憶手段と、 前記第１の入力手段によって受け取られたメッセージから前記キーワードを抽 出し、前記キーワードに関連する装置依存メッセージを決定するために前記記憶 手段にアクセスし、前記第１の出力手段を介して前記装置依存メッセージを前記 アプリケーションプログラムに送り、前記第２の入力手段によって受け取られた メッセージからデータを抽出し、前記第２の出力手段を介して装置独立メッセー ジ中の前記データを前記クライアント装置に送る処理手段と を備えたインタフェース装置が提供される。 これにより、本発明の実施例は、クライアント装置からの装置独立メッセージ をアプリケーションプログラムが求める装置依存メッセージに（あるいは逆方向 に）翻訳する能力を向上させるインタフェース装置を提供する。したがって、ク ライアント装置を、アプリケーションプログラムの正確な要求から独立したもの とすることができる。 ＰＣクライアントはデータ管理システムに要求を送る。データ管理システムは 、本発明によるインタフェース装置を備えているので、例えば特定のトランザク ションを実行するために特定のアプリケーションプログラムに要求される画面の 座標を知る必要がない。ＰＣクライアントは、単に、インタフェース装置に送ら れる装置独立メッセージ内のキーワードを介して、関連するトランザクション及 び必要なデータを識別することを必要とするだけである。インタフェース装置は 、アプリケーションプログラムを介して特定のトランザクションを実行するため に必要とされる装置依存メッセージに、送られてきたキーワードを関連付ける。 もし、アプリケーションプログラムが異なる装置依存メッセージを必要とするよ うに、又はアプリケーションプログラムが異なったフォーマットでのトランザク ションの結果を出力するように当該アプリケーションプログラムが変更された場 合には、インタフェース装置のメモリ手段内に記憶されている適当な装置依存メ ッセージだけが変更を要する。ＰＣクライアントは、同じキーワードを介して同 じようにして同じアプリケーションプログラムにアクセスし続けることができる 。アプリケーションプ ログラムの改善点は、多くのＰＣクライアントには何の変更も必要とされないこ とである。 インタフェース装置のメモリ手段内においては、単一のキーワードは複数の装 置依存メッセージに関連付けさせることが望ましい。こうすると、クライアント 装置からの単一の要求に基づき、多くのトランザクションをインタフェース装置 に実行させることができ、アプリケーションプログラムから出力された複数のフ ォーマット済み画面から独立メッセージを介してクライアント装置に情報をイン タフェース装置に返答させることができる。したがって、画面スクラッピング技 術に比較すると、クライアント装置とアプリケーションプログラムとの間の多元 シリアル通信は、単一通信に置き換えられてきた。このため、クライアント装置 においてユーザにより観察される応答時間はかなり改善され、クライアント装置 と中央計算処理資源との間のネットワークトラヒックは縮減される。 本発明によるインタフェース装置を有する中央計算処理資源は、クライアント 装置からトランザクションの要求を受ける対話マネージャをさらに備えており、 この対話マネージャは、装置独立メッセージと装置依存メッセージとを区別する ことができ、前記インタフェース装置に装置独立メッセージを通すことができる ものであることが望ましい。こうすることにより、装置依存データストリームを 介して中央計算処理資源と交信する両ダム端末を支援するとともに、装置独立メ ッセージを介して中央計算処理資源と交信するインテリジェ ントクライアント装置をも支援するデータ管理システムを実現できる。 本発明の第２の観点によれば、データ管理システムにおいて複数のアプリケー ションプログラム間のインタフェースを行う方法であって、トランザクションを 実行するために各アプリケーションプログラムが装置依存メッセージを要求し、 実行すべきトランザクションをクライアント装置が要求することができるように なっており、 i) 前記クライアント装置から、キーワードを含んだ装置独立メッセージを受 けるステップと、 ii) 前記装置独立メッセージから得られるキーワードと、一つ又は複数の記憶 された装置依存メッセージに各々が関連付けされている記憶されたキーワードと を比較し、一致するキーワードを見つけるステップと、 iii)前記装置依存メッセージ又は前記記憶された一致キーワードに関連付けさ れているメッセージを前記アプリケーションプログラムに送るステップと、 iv) 一つ又は複数のアプリケーションプログラムから、トランザクションの結 果として取り出されるデータを含んだ装置依存メッセージを受けるステップと、 v) 前記装置依存メッセージから、前記キーワードに従ってデータを抽出する ステップと、 vi) 装置独立メッセージ内の抽出されたデータを前記クライアント装置に送る ステップと を有する方法が提供される。 本発明の実施例について一つの例を挙げて以下に説明する。また、この際に参 照する図面は次の通りである。 図１は、本発明によるデータ管理システムの概略図であり、 図２は、図１のデータ管理システムのミドルウェア構成要素をより詳細に示す 概略図であり、 図３は、本発明の実施例によるデータ管理システムで使用される画面に関連す る静的テーブルの概略図であり、 図４は、本発明の実施例によるデータ管理システムにおける構成要素間の関係 を示す概略図であり、 図５は、本発明の実施例によるデータ管理システム及び従来技術によるデータ 管理システム上で走る複数のトランザクションの例を示す概略図である。 本発明の実施例の説明においては、インタフェース装置を備えた大型データ管 理システムが含まれ、このインタフェース装置は、本発明の実施例においては、 ＭＭＢＩ（ミドルウエアメッセージ基準インタフェース：Middleware Message-B ased Interface）と称される。データ管理システムは、ハードウェアとソフトウ ェアとを備えている。ハードウェア構成要素は、ＩＢＭ３０９０シリーズのメイ ンフレームである。標準ＩＢＭソフトウェアは、オペレーティングシステム（Ｍ ＶＳ）及びテレプロセッシングモニタ（ＣＩＣＳ）のために利用され、データベ ース管理システムはＩＤＭＳである。このＩＤＭＳは、コンピュータ・アソシエ ーツ・ハウスのコンピュータ・アソシエーツ（１８３−１８７ バスロード，ス ロー，バークシァー，ＳＬ１ ４ＡＡ）により販売されてい る。ＩＢＭのハードウェア及びソフトウェア構成要素は、ＩＢＭ ＵＫ有限会社 （ＰＯボックス４１，ノースナーバー，ポーツマウス，ＰＯ６ ３ＡＵ）から購 入することができる。上記システムは、さらに、多くのソフトウェアモジュール を備えている。これらはまとめてミドルウェアとして知られている。ミドルウェ アは、ソフトウェアの分野では、アプリケーションプログラム間に位置するソフ トウェアの層を示すものとして知られる用語である。これらは、コンピュータシ ステムのオペレータによる特定要求のために書かれたものであり、コンピュータ システムのオペレータによって購入される専用ソフトウェアである。ミドルウェ アの主な役割は、アプリケーションプログラムをテレプロセッシングモニタ即ち ＩＭＢのＣＩＣＳの要求から隔絶させることにある。ＣＩＣＳは、ＩＢＭ社によ り作製された複雑なソフトウェアであり、定期的に更新されている。ミドルウェ アを使用することにより、アプリケーションプログラマはＣＩＣＳについて非常 にわずかな知識をもっているだけで済む。ＣＩＣＳとの複雑なインタフェースの 取り扱いや、ＣＩＣＳが更新されたために必要とされる変更内容の組み込みにつ いては、アプリケーションプログラマはミドルウェアプログラマに任せることが できるからである。 また、ミドルウェアによれば、署名、メニュー、確証、及びアベンドといった 多くのルーチン機能は、アプリケーションプログラムの各々において再生される のではなく、統合して取り扱われる。 図１及び図２は、データ管理システムのソフトウェアの概略図を示している。 端末１からの全ての入力は、ＭＶＳ２を介してＣＩＣＳ３に送られる。ＣＩＣ Ｓ３は、それを順番にミドルウェア４に送る。ミドルウェア４は、適当なアプリ ケーションプログラム５にそれを送る前に、アクセス制御や確証といったデータ に関する機能を実行する。データは、ミドルウェア４、ＣＩＣＳ３及びＭＶＳ２ を介して端末に返される。 ミドルウェア４の統合部分には、ミドルウェアテーブル１３がある。これらの テーブル１３は、オンラインシステムの構成を記述した参照データを保持してい る。システムが動作している間、これらのテーブルは、装置メモリの中に保持さ れている。この装置メモリは、ＭＶＳ（ＣＩＣＳアドレス空間に関連付けされた ＭＶＳプライベート記憶エリア）に属するものである。テーブル１３用のデータ は、ミドルウェアデータベースに保持される。このデータは、システム起動時に メモリにロードされるリニアデータセット（ＬＤＳ）のために使用される。その データは、ミドルウェアの補助ソフトウェア７によってミドルウェアデータベー ス内に登録され、保管される。 アプリケーションプログラム５のほとんどは、ミドルウェアによって制御され る。ミドルウェアの制御から離れたＣＩＣＳ環境の下で走るアプリケーションプ ログラム５は、わずかである。一般に、アプリケーションプログラム５は、一時 記憶キュー（temporary storage queue：ＴＳＱ）及びプロ グラム制御を除いては、ＣＩＣＳによって提供されるサービスを利用しない。ミ ドルウェアは、図２に示すように、複数の異なった構成要素から成っている。 図２を参照して、各ミドルウェア構成要素について以下に述べる。 ［ミドルウェアテーブル(middleware tables)］ ミドルウェア構成要素６の各々は、一つ又は複数のミドルウェアテーブル１３ にアクセスする。補助ソフトウェア７を用いれば、テーブル内のある要素を追加 及び変更することによってシステムを再構成することができる。テーブルに対し て変更をしても、すぐには有効とならない。システムの起動の間、テーブルは装 置メモリにロードされる。このため、テーブルが再ロードされるとき（即ち、Ｌ ＤＳが次に再生されてリフレッシュされるか又はＣＩＣＳシステムが再起動され るとき）までは、上記の変更は有効とはならない。 ［対話マネージャ(dialogue manager)］ 対話マネージャ８は、ミドルウェアの主要な構成要素である。端末がデータを 送るたびに、対話マネージャ８が起動される。対話マネージャ８は、入力におけ る処理を制御し、必要に応じて種々のミドルウェア構成要素やアプリケーション プログラム５を呼び出す。アプリケーションプログラム５がデータの処理を終え た後、対話マネージャ８は、出力メッセージを処理するための制御に取りかかる 。 ［アクセス制御(access control)］ アクセス制御９は、ミドルウェアのセキュリティ面での特 徴をもつ主要な構成要素である。オンラインシステムが使用される前に、ユーザ は“署名”をしなければならない。ひとたびユーザが“署名”をすると、アクセ ス制御部は、下に示す項目に従い、ユーザが特定のトランザクション又はアプリ ケーションにアクセスできるか否かを判別する。 １． ユーザプロフィール中にユーザＩＤが入っている。 ２． 端末グループ中に端末が入っている（なお、端末グループに基づくアク セス制御については構築可能である）。 ［メニュー管理(menu management)］ ミドルウェアで開発されたシステムは、メニュー起動型となっている。ユーザ が“署名”をしたときには、基本メニューが表示される。このメニューは、メニ ュー管理部１０によって形成される。ここでは、ユーザの使用を可能とさせるた めのアプリケーションプログラムだけが示される。もしユーザが特定のアプリケ ーションプログラムを選択すれば、メニュー管理部１０は、ユーザがアクセスで きる選択アプリケーションに属するトランザクションのみを示すアプリケーショ ンメニューを形成する。 ［ルーチングプロセス(routing process)］ “ルーチング”は、トランザクションスイッチングにおいて使用されるプロセ ス１１である。その機能は、画面入力データ（電話番号、口座番号、又は住所デ ータ）を検査し、そのデータによってトランザクションが実行されるシステムを 識別することである。これを実現するためには、入力データ について“ルックアップ”し、それをシステムに関連付けするためのルーチング テーブルを用いる。ルーチングテーブルには、次のような五つのものがある。 １． 電話 ２． 口座番号 ３． 郵便番号 ４． 郵便管轄町 ５． 地域 さらに、ルーチングにおいては使用されないが、高性能されたルーチングにお いて使用されるものとして、郵便管轄町テーブル内に含まれたデータを補充する 州テーブルがある。 ［確証(validation)］ 確証部１２は、端末入力の処理の大部分を行う処理部である。ミドルウェアテ ーブル１３の中には、基本的確証を特定するための一組のテーブルがある。この 基本的確証は、各画面上のフィールドごとに実行されるべきものである。端末入 力がアプリケーションプログラム５に入ってくる前に、確証部１２は、テーブル １３内で特定されているルールに従って画面上の各フィールドについて確証を行 う。 実行される確証の種類には、フォーマット用、範囲用及び特定値用といったも のがある。アプリケーションデータベースに対する確証検査やフィールドの内部 依存性検査はない。アプリケーションプログラム５の応答性検査がある。 もしフィールドについての確証がなければ、ユーザに対する適当なエラーメッ セージが付された現行の画面が再表示さ れる。データはアプリケーションプログラム５には送られない。 ［ＭＭＢＩ(Middleware Message-Based Interface)サーバ］ ＭＭＢＩ１４によれば、インテリジェント前端システム（例えばＰＣクライア ント）は、自己定義の種類，長さ，値（type/length/value：ＴＬＶ）からなる メッセージを介して、後端システムの機能を呼び出せるようになる。 ＭＭＢＩサーバ１４は、前端クライアントと対話マネージャ（標準画面に基づ くビジネストランザクションを実行する）との間におけるエージェントとして、 論理的に動作する。これにより、オブジェクトスクリプト言語による制御の下で 一つ又は複数のトランザクションが実行されるようになる。ＭＭＢＩ１４は、新 たなミドルウェアシステムテーブル１３を導出する。これらのテーブルは、新た なリニアデータセットによって支援されるものである。 古典的なＣＩＣＳ画面の表現法を用いるのではなく、自己定義データストリー ムメッセージを用いることにより、あらゆるミドルウェアやビジネス機能も実現 することができる。入力と出力の両方に関し、メッセージは、種類(type)，長さ (length)，値(value)（ＴＬＶ）によるフォーマットで形成されている。 ＭＭＢＩサーバ１４は、メッセージを処理し、（対話マネージャへの要求を通 じて）トランザクションの実行を制御し、最後には自己定義フォーマットに基づ く出力結果を返す。 ［エラーメッセージ(error message)］ ユーザの画面上に出力されるエラーメッセージに対して、特別なＩＤが割り当 てられる。各メッセージに関連付けされたテキストは、ミドルウェアテーブル１ ３のうちの一つに記憶される。例えば確証のようなミドルウェア又はアプリケー ションプログラムがユーザに対するメッセージの表示を望んでいるときには、上 記の特別なＩＤを対話マネージャに与える。ミドルウェアテーブル上のテキスト を用いることにより、メッセージが対話マネージャ８によって表示される。 ［オペレータインタフェース(operator interface)］ ミドルウェアで開発されたシステムには特有の複雑さがあるため、各地点にお いてテレプロセッシング環境を監視でき、制御できるようにすることが必要であ る。このため、オペレータインタフェース１５が設けられてる。このインタフェ ース１５によれば、ユーザは、全てのメッセージを監視することができる。これ らのメッセージは、次のようなシステム、監視及び制御の項目によって生成され るものである。 ・ユーザの署名 ・端末 ・プリンタ ・バックグラウンドスケジューラ ［メッセージサービス(message service)］ メッセージサービス１６は、システム間でのデータの転送に使用される。これ らシステムは、トランザクションの切り換えを行う際に交信する必要があるもの である。メッセージサービスには次のような二つの側面がある。 ・局所メッセージサービス（Local Message Service：ＬＭＳ）… デー タの遠隔システムへの送信及び遠隔システムからの受信を行うために、ユーザの ホームシステムで使用されるプロセス ・遠隔メッセージシステム（Remote Message Service：ＲＭＳ）… デー タのホームシステムへの送信及び局所システムからの受信を行うために、遠隔シ ステムで使用されるプロセス ［システム統計（system statistics：ＳＵＳＴ）１７］ 後の解析のためにシステム統計が集められる。オペレータインタフェース１５ を用いることにより、停止又は開始がされるようになっている。 ［レポートプリンティング（Report Printing：ＲＰ）サブシステム］ ＣＩＣＳは遠隔のプリンタを使用するための機能を提供するが、装備されてい る標準の機能はそれほど高性能化されていない。レポートプリンティングサブシ ステム１８によれば、アプリケーションは、ミドルウェアデータベース内にレポ ートを生成する。これにより、ミドルウェア内のプリンティング機能は、レポー トの実際のプリンティングを制御する。 サブシステムは、バックグラウンド内ではなく、ＣＩＣＳ内で動作する。サブ システムは、ＣＩＣＳシステムが導入され、対話マネージャ８ではなくてオペレ ータインタフェース１５を介して制御されるときに起動される。 ［アベンド制御(abend control)］ ミドルウェアは自己自身の環境を用意するので、故障が起こった場合に、ユー ザがその環境から逸脱したり既存のＣＩＣＳに入り込むことはない。これは重要 なことである。このことは、潜在的にはユーザに対して混乱を招く結果となる。 アベンド制御部１９は、故障が起こったときに制御に取りかかる。アベンド制 御部１９は、関連情報が付与されたアベンド画面を表示する。この関連情報によ り、ユーザはプリントを行ったり支援スタッフに通じたりできる。ひとたびユー ザがアベンド画面を処理したならば、ユーザはこれを継続することができる（例 外的に、ユーザは継続を停止されることもあり得る）。 ［バックグラウンドスケジューラ(background schedular)］ どんなシステム内にも、実行されることを必要とする機能が多く存在する。す なわち、端末入力された結果、これらの機能は資源をきわめて沢山使用するもの である。もしこれらの機能が端末から実行されると、許容できないほどの時間が かかるため、端末を使用することができない。バックグラウンドスケジューラ２ ０は、これらの機能を向上させるものであり、これらの機能がＣＩＣＳバックグ ラウンドにおいて実行されるように制御する。スケジューラ２０は、オペレータ インタフェース１５によって制御される。 一般に、端末から駆動されたトランザクションは、データの処理をバックグラ ウンド２０に依頼する。これにより、各アプリケーションは、データが処理され たか否かを判別することになる。 ［バッチジョブサブミッション(batch job submission)］ ミドルウェア２１の中のバッチジョブサブミッションによれば、アプリケーシ ョンプログラム５は、ジョブをＪＥＳ（Job Entry Subsystem）に依頼できるよ うになり、これによりユーザはシステムを通じてジョブの進捗状況を監視できる ようになる。この高機能の一般的な使用法としては、レポートを作成するための バッチジョブを、アプリケーショントランザクションがレポートプリンティング サブシステム１８に依頼することなどが挙げられる。ひとたびユーザがミドルウ ェアトランザクションを用いることによってジョブの終了を認めると、レポート プリンティングサブシステム１８によってレポートがオンラインで読み込まれる 。 ［補助ソフトウェア(ancillary softwase)］ ミドルウェアテーブル１３にロードされた参照データは、ミドルウェアデータ ベースに保管される。補助ソフトウェアトランザクションは、このデータを生成 して保持するために使用される。 ［画面関連テーブル(screen-related tables)］ ミドルウェアは、所望の機能を実行するために大量の参照データを用いる。こ の参照データには、オンラインシステムの構成要素及びある制御情報が表されて いる。 テーブル用のデータは、ミドルウェアデータベースに保管されている。それは 、上記データにアクセスする際のオーバーヘッドを縮減するために、装置メモリ にロードされる。ＭＶＳプライベート記憶エリア内には、常駐する二種類のテー ブルがある。すなわち、静的テーブル（更新に対して保護される）と動的テーブ ル（更新に対して保護されない）とがある。 これらのテーブルは、ＣＩＣＳスタートアッププロセスの一部としてロードさ れるか、又はテーブル作動中に再ロードされる。データは、リニアデータセット （ＬＤＳ）からＭＶＳプライベート記憶エリアにロードされる。ミドルウェア用 のデータベース制御テーブル（ＤＢＣＴ）は、特定のＬＤＳデータが静的である か動的であるかを示す情報を含んでいる。 その他のテーブルは、ＣＩＣＳ一時的データキューを介して逐次ファイルから 読み出される。 ロードされた各テーブルのアドレスは、ＣＩＣＳ ＣＷＡ（Common Work Area ：共用作業エリア）に記憶される。 ひとたびロードがされると、静的テーブルは変更できないようになっている。 動的テーブルにおける詳述内容はシステムによって変更され得るが、新たな内容 は追加できないようになっている。署名メッセージテーブル及び放送テーブルは 、記録なしの状態でロードされる。これらはＣＩＣＳ駆動中に更新される。 ［静的テーブル(static tables) ］ 静的テーブルは、次のようないくつかの部分に分けられる。 ・画面関連 ・アクセス関連 ・トランザクション切換え関連 ・コンフィギュレーション関連 ・ＭＭＢＩ関連 ［画面関連テーブル(screen-related tables)］ ［確証テーブル(validation tables)］ ミドルウェア機能の一つは、全てのアプリケーション画面上の基本的確証を行 うことである。これを実行するためには、ミドルウェアは、あらゆるアプリケー ション画面の詳細（即ち、フィールドの位置、サイズ及び確証ルール）を知る必 要がある。 画面がアプリケーション開発の一部として作成されるときに、画面の詳細がミ ドルウェアデータベースの中に生成される。画面用のロードモジュールがサイト に送られるときに、画像の詳細がさらに送られる。その詳細は、コンフィギュレ ーションシステムの一部としてサイトのデータベースにロードされる。 図３に示すように、画面の詳細は、四つのテーブルにロードされる。 各テーブルの目的は次の通りである。 “マップヘッダ(map headers)２２” マップヘッダ２２は、システムにおけるあらゆる画面の名称を含んでい る。それは、各画面についてのフィールドの詳細を見つけるために使用される。 “マップフィールド(map fields)２３” マップフィールド２３は、あらゆる画面上の各フィールドの定義を含ん でいる。それは、各フィールドの開始位置、長さ及び確証種類を定義している。 も し確証の種類が範囲検査である場合は、それはさらに範囲の下限及び上限を含ん でいる。 “確証値(validation values)Ｉｄｓ” フィールドが特定の値又は（複数の値からなる）リストに対して確証す べきときには、その値又はリストにはＩＤが割り当てられる。特定のＩＤは一つ 以上のフィールドによって参照することができる。このテーブルは有効な全ての ＩＤを含んでいる。 “確証値(validation values)” 確証種類テーブルは、該テーブル中の各有効ＩＤごとに、特定の値又は リスト（複数の値からなる）を有している。 “新規マップ／プログラムテーブル(new maps/program tables)” 新規マップ／プログラムテーブルは、テーブルロードマネージャによっ て使用される。これは、最後のシステムが起動した後に新規のマップが導入され たかを判別するために再ロードを行っている間に使用される。このマップ及びそ れらの関連するプログラムのリストは、自動ＣＩＣＳニューコピーを駆動するた めに使用される。この自動ＣＩＣＳニューコピーは、マップマスク及び確証テー ブル情報の新しいバージョンの導入に同期するものである。 確証種類テーブルは、通常の処理の間においては使用されない。このテーブル の目的は、該テーブルがロードされると きに、確証詳細テーブル間のリンクを行うことである。テーブルのロード後は、 そのテーブルは使用されない。 ［ＭＭＢＩの動作(operation of MMBI)］ ＭＭＢＩにアクセスできるようにするためには、クライアントは、ミドルウェ アシステムに対して通常の端末アクセスをすることしか必要としない。 ひとたび接続されれば、クライアントは、ミドルウェア署名画面から通常の画 面スクラッピング技術を用いて署名する。 もし早急なＭＭＢＩアクセスが求められるのであれば、トランザクションの識 別子“ＭＭＢＩ”が署名画面上に入力される。一方、トランザクションは、署名 のセッションの際中においてはいつでも使用できる。 このトランザクション識別子の呼び出しの際に、ＭＭＢＩ装置及び端末セッシ ョンとしてのクライアントは、フォーマットされた画面から自由形式のテキスト に切り替えられる。 その後の全ての通信は、有効なＭＢＩメッセージを用いて行われる。クライア ントの通信の順序は、常に、以下の通りである。 要求メッセージを送る 応答を待つ ＭＭＢＩの応答を処理する 要求メッセージを送る その他 ＭＭＢＩ要求の許容される組の中で、必要時にフォーマットされた画面モード に切り替って戻るためにクライアントが 使用できるのは一つだけである。ここで、トランザクション“ＭＭＢＩ”は、Ｍ ＭＢＩモードに再び切り替わるために使用されるものである。 ［ＭＭＢＩオブジェクト(MMBI objects)］ 標準トランザクションに加え、ＭＭＢＩオブジェクトが実行される。 オブジェクトによれば、クライアントは、順に実行されるべき一つ又は複数の トランザクションのグループを予め定義できるようになる。その定義は、ＭＭＢ Ｉスクリプト言語を用いて書かれる。全てのオブジェクトの定義は、起動時にオ ブジェクトテーブルにロードされ、一つが実行されればいつでもそこからアクセ スされる。 言語については次のように定義できる。 ・（ＥＸＥＣコマンドで）実行されるべき（パラメータの付加／不付加の ）トランザクションのシーケンス ・結果としての画面ＩＤ（オンイベントコマンド）に基づく条件ロジック ・データの値（ＩＦコマンド）に基づく条件ロジック ・データ（ＥＸＴＲＡＴコマンド）の抽出 ひとたびオブジェクトの実行が完了すると、クライアントへの返答メッセージ は、ＥＸＴＲＡＣＴコマンドによって特定されたデータだけを含んでいる。例え ば、十個のトランザクションを実行しているオブジェクトは、トランザクション から得ることが可能な数百の値のうち、五つのデータ値しか 返さない。 ・画面上のデータフィールドの値および内部変数（ＳＥＴコマンド）につ いての設定 ［ＭＭＢＩマップビューテーブル(MMBI mapview table)］ ＭＭＢＩモードにおいてメッセージを受けるか又は送るときに、ミドルウェア は、ＭＭＢＩ機能によって現在支援されている全てのアプリケーション画面の詳 細を知る必要がある。これらの詳細には、フィールドの標準名称、位置およびサ イズが含まれている。一つの画面に対するロードモジュールがサイトに送り出さ れるとき、画面の詳細はさらに送られる。 画面の詳細は二つのテーブルにロードされる。これは、図３におけるマップヘ ッダ及びマップフィールドテーブルの関係に類似している。 各テーブルの目的は次の通りである。 “マップビューヘッダ(mapview headers)” マップビューヘッダは、画面を支援するあらゆるＭＭＢＩの名称を含ん でいる。それは、各画面のマップビューフィールドの詳細を見つけるために使用 される。 “マップビューフィールドテーブル(mapview field table)” マップビューフィールドテーブルは、全てのＭＭＢＩ支援画面上の各フ ィールドの定義を含んでいる。それは、各フィールドの開始位置、長さ及び標準 名称（実際には標準名称辞書における名称の数値的な 識別子）を定義している。 ［ＭＭＢＩ関連テーブル(MMBI-related table)］ 標準名称辞書テーブルは、全てのＭＭＢＩメッセージを確認するために使用さ れる。 オブジェクトテーブルは、クライアントからの要求があったときに、支援オブ ジェクトを実行するために使用される。それは、二つのテーブルであり、ヘッダ テーブル及び詳細テーブルがある。 テーブルの内容は次の通りである。 “標準名称辞書(standard name disctionary)” 標準名称辞書は、ＭＭＢＩによって支援される全ての標準名称を含んで いる。各エントリは、名称を識別するためにマップビューテーブルとオブジェク トテーブルの両方において使用される特別な数値サブスクリプトを含んでいる。 “オブジェクトヘッダテーブル(object header table)” オブジェクトヘッダテーブルは、ＭＭＢＩによって支援される全てのオ ブジェクトを含んでいる。各エントリは、オブジェクトによって操作されるべき 一つ又は複数のイベントを含んでいる。各イベントは、詳細テーブル中に組み込 まれ、該イベントのために実行されるべきオブジェクト言語ステートメントを定 義する。 “オブジェクト詳細テーブル(object detail table)” オブジェクト詳細テーブルは、ヘッダテーブル内の 全てのオブジェクトについての全てのイベントにサービスを供給するために必要 な全てのステートメントを含んでいる。 ［ＭＭＢＩ(Middleware Message-Based Interface)サーバ］ メッセージ基準インタフェースを介してミドルウェアに対して機能又はデータ の要求がなされると、ＭＭＢＩサーバ１４が呼び出される。 インタフェースを媒介する通信は、種類，長さ，値（typｅ/length/value：Ｔ ＬＶ）の符号を用いて自己定義することによって行われる。メッセージの内容に よれば、クライアントプロセス（例えば、ＰＣ）はサーバプロセス（ミドルウェ アシステム）に対して要求を出したりデータを受けたりすることが可能となる。 ［ＭＭＢＩメッセージフォーマット(MMBI message format)］ 入力及び出力の両方についてのシンタクスの主なルールに関しては、最初の五 つの文字（ＭＭＢＩ及び一つのブランク）は別として、完成されたメッセージは ＴＬＶフォーマットで形成されており、デリミタによって区切られている。 このＴＬＶフォーマットの構築については次の通りである。 tttttttt;1111;vvvvvvvv; ここで、“tttttttt”は、データ列を示す有意名称である（最大で３１文字） 。 “；”は、デリミタであり、全てのメッセージ要素を区分けするものである。 “1111”は、送られるデータの実際の長さである（最大で ４桁）。 “vvvvvvvv”は、データの値そのものである（最大で９９９９文字）。 メッセージのフォーマットは次の通りである。 MMBI 'control-TVL';'control-TVL';...;CTL-END;1;*;'data-TLV';'data -TLV';...;END;1;*; ここで、“MMBI”は、プロセスの識別子である。実際のＴＬＶメッセージは、 六つの文字上で開始する。 “control-TLV”は、一連の制御ワードの値であり、要求や動作上の報告を行 い、データの流れを制御する。そのデータは、例えば“run-TRNSN;3;DCA;”であ る。 “data-TLV”は、データを定義する一連のＴＬＶ項目である。これらは、ＭＷ プロセスを実行するために必要な主要データであるか、又はプロセスによって返 されるデータである。 “END;1;*;”は、メッセージの終わりを示すものであり、クライアントとサー バの両者は、この位置の後には処理すべきデータがないことを知る。 クライアントプロセスがトランザクションＤＣＡを口座番号１０００００００ で実行することを要求する場合に、このクライアントプロセスによって送られる メッセージの例を挙げると、次の通りとなる。 MMBI RUN-TRNSN;3;DCA;CTL-ND;1;*;PARM;8;10000000;END;1;*; ［ＭＭＢＩサーバＭＭＢＩ機能(MMBI server MMBI functions)］ 図４を参照して、サーバ１４の呼び出し及び動作を説明する。 ・クライアントが通常の画面モードとなっているとき ・クライアントプロセスは、通常の画面動作からＭＭＢＩモードへの切り 替えの要求をする。 クライアント用の全ての分脈データは、ＭＭＢＩモードでトランザクシ ョンを実行するのに有効となっている。サーバ１４が呼び出されて、初期メッセ ージが比較される。この初期メッセージは、切り替えが完了したことを示すもの である。ミドルウェアシステムは、いま、ユーザ（クライアント）のためにＭＭ ＢＩモードで動作している。 ・クライアントがＭＭＢＩモードとなっているとき、対話マネージャ８は、サ ーバ１４を呼び出し、データを通す。そのデータはサーバ１４上で受け取られる 。サーバ１４は、メッセージを復号化し、次のように動作する。 一つの手順としては、次の通りである。 ・クライアントは、ＭＭＢＩ支援の機能（例えば、実行処理、機能キー、 オーバーフローデータなど）のうちの一つを要求している。処理を実行している とき、標準トランザクション又はＭＭＢＩオブジェクトが要求され得る。 １．メッセージの中に送られたデータ列は標準画面に変換される。これ を行うためにサーバは二つのＭＭＢＩテーブルを使用する。 ａ．標準名称辞書テーブル これは、サーバによって支援されるデータ列の全ての名称を含 んでいる。入力メッセージ中の各名称は、テーブルの中においてサーチされる。 ｂ．マップビューテーブル これは、サーバによって支援される全てのトランザクションの 全マップ（画面）を含んでいる。マップごとに、その標準名称の全てに対する数 値的識別子がリストにされる（これを特に“マップビュー”と呼ぶ）。（アプリ ケーションプログラムから期待されるものとしての）仮想画面が作成される。こ の際に、メッセージ要素とマップビューに含まれる位置情報と標準名称辞書との 関係を用いられる。 もしオブジェクトが要求されたならば、サーバは第３のテーブル、 オブジェクトテーブルにアクセスする。オブジェクトテーブルは、全ての支援さ れたオブジェクトを含んでいる。各オブジェクトごとに、実行されるべきトラン ザクション、抽出されるべきデータ及びオブジェクト中の論理制御がリストにさ れる。 ２．仮想画面は、対話マネージャ８に送られる。この際には、トランザ クションの詳細や機能キー データなどが伴っている。 ３．これにより、対話マネージャ８は、通常の画面ユーザが要求した時 のようなアプリケーションコードを実行する。 ４．ひとたびトランザクションが完了すれば（もしオブジェクトが要求 されれば、上記のステップ１，２及び３が各トランザクションごとに実行される ）、仮想画面（結果物）がサーバ１４に送られることになる。 ５．出力データは、ＴＬＶフォーマットに変換され、クライアントに返 される。 もう一つの手順としては、次の通りである。 ・クライアントは、ＭＭＢＩモードから通常画面動作に切り替えることを 望む。 クライアントに対する全ての分脈データは、画面モードの処理において 有効である。要求に基づき、サーバは基本メニューを送るように対話マネージャ ８に要求するか、又はトランザクションを開始する。これにより、対話マネージ ャ８は、画面出力を操作できるようになる。 ［ＭＭＢＩオブジェクトの例(example of MMBI object)］ 図５は、複数のトランザクションを含んだＭＭＢＩオブジェクトがいかにして トランザクションの組を実行するかを示している。なお、この際に、ＰＣクライ アントからの単一の要求とＭＭＢＩサーバ１４からの単一の応答が用いられる。 また、図５は、ダム端末２５が同じトランザクションの組を読み出す手順を示し ている。要求された各トランザクションごとに、装置依存メッセージがダム端末 ２５と対話マネージャ８との間で交換されなければならないことが示されている 。 ＭＭＢＩオブジェクトＣＲＳＳ０１が要求されるときにＰＣクライアント１と ＭＭＢＩサーバ１４との間で交換される装置依存メッセージの特別例を以下に示 す。 オブジェクトＣＲＳＳ０１は、トランザクションＤＣＳ（顧客概要表示：Disp lay Customer Summary）、ＤＣＡ（顧客口座表示：Display Customer Account） 、ＤＣＲＤ（顧客賃借詳細表示：Display Customer Rental Details）ＤＭＵ（ 計測使用表示：Display Metered Usage）及びＤＩＸ（表示送り状表示：Display Invoice）を有している。 ＰＣクライアントは、次のものを発行する。 MMBI RUN-OBJECT;6;CRSS01;TKN-ID;6;123456;CTL-END;*;PARM;10;0375814 881;END;1;*; ＭＭＢＩサーバは、次のものを返す（ＣＲＳＳオブジェクトによれば、構成ト ランザクションに含まれるデータのサブセットだけの返答となる）。 MMBI OBJECT-RSLT;6;CRSS01;TKN-ECHO;6;123456;STS;2;OK;OBJECT-VER;4; 0001;CTL-END;1;*;CUST-NM(01);16;JONES & HILT PLC;CUST-ADDR(01);14;200 BAULK LANE;CUST-ADDR(02);5;SULLY;CUST-ADDR(03);9;RINGSHIRE;CUST-ADDR (04);8;RF19 3CH;TEL-NR;12;037581 4881;RCNT-ORD;3;YES;CURR-FAULT;2;NO;CO MPLAINT;2;NO;FU-RTNG;1;D;EXCH-NM;5;S ULLY;LN(01);75;1 A10006 C EXCL EXCH LINE ON SOCKET22.55;LN(02);1;*;LN(03 );75;2 A10118 C STATESMAN TELE SC 4.00 8.00;LN(04);1;*;DIS-BL-ID(01);4;S 003;DIS-BL-DTE(01);8;15/15/87;DIS-BL-AMT(01);7;$308.00;DIS-BL-ID(02);4;Q 002;DIS-BL-DTE(02);8;30/12/86;DIS-BL-AMT(02);7;$137.80;DIS-BL-ID(03);4;i 001;DIS-BL-DTE(03);8;15/12/86;DIS-BL-DTE(03);8;15/12/86;DIS-BL-AMT(03);0 7;$137.80;END;1;* この例においては、標準画面スクラッピングは八つの組＝２４秒を必要とする 。 ＭＭＢＩを用いると、たった一つのメッセージの組＝約４秒（通常時）だけを 必要とする。 ［更新(updating)］ メインフレーム又はＰＣクライアントの更新は、ＰＣアプリケーションからの 物理情報（例えば、どのトランザクションか、データ列は何か、データ列を見つ けるためにどこの画面像上にあるか）を分離することによって簡単化された。Ｐ アプリケーションは簡単に“オブジェクト”を呼び出す。メインフレーム側にお いては、この物理的位置情報が要求される。そして、画面変更においては、項目 位置は更新されなければならない。ファイル“マップビュー”は、マップ生成処 理を介して画面変更のために生成される。これにより、“外部”メッセージ要素 と“内部”（位置的に依存）のアプリケーションプログラムビューとの間にリン クができる。このようにして、作動環境のもとへ導かれた画面変更には、それ自 身のための新たな“マップビュー”が伴っている。これは、実行時にＭＭＢＩサ ーバ１４によってアクセスされる。これにより、画面変換は自動的に最適化され る。 本発明によるインタフェース装置はＰＣクライアントとメインフレームコンピ ュータシステムとのインタフェースを行うのに使用されているが、同様に、メイ ンフレームや例えば（ＬＡＮに基づくＰＣを備えた）ＵＮＩＸサーバからメイン フレームコンピュータシステムへのインタフェースを行う場合にも適用可能であ る。さらに、クライアントとメインフレームとの間の通信リンクは、例えばＩＢ Ｍ３２７０のように直列であってもよく、例えばＬＵ６．２のように並列であっ てもよい。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ダーリワル、マンディープ・シング イギリス国、アイディ−５・０エーエル、 エセックス、イルフォード、コリンウッ ド・ガーデンズ 107 (72)発明者 ケネディー、ピーター イギリス国、エムイー15・９エスエー、ケ ント、メイドストーン、ルース、ランセッ ト・レーン 33、ファクターフィールド・ リミテッド

Claims (1)

1. 【特許請求の範囲】 １． データ管理システムにおいて複数のアプリケーションプログラム間のイ ンタフェースを行い、トランザクションを実行するために各アプリケーションプ ログラムが装置依存メッセージを要求し、実行すべきトランザクションをクライ アント装置が要求することのできるインタフェース装置であって、 前記クライアント装置から、キーワードを含んだ装置独立メッセージを受ける 第１の入力手段と、 装置依存メッセージをアプリケーションプログラムに送る第１の出力手段と、 アプリケーションプログラムから装置依存メッセージを受ける第２の入力手段 と、 装置独立メッセージを前記クライアント装置に送る第２の出力手段と、 キーワードと、前記キーワードの各々が関連するトランザクションを識別する ためのデータと、前記トランザクションの各々を実行することが要求されている 前記装置依存メッセージとを記憶する記憶手段と、 前記第１の入力手段によって受け取られたメッセージから前記キーワードを抽 出し、前記キーワードに関連する装置依存メッセージを決定するために前記記憶 手段にアクセスし、前記第１の出力手段を介して前記装置依存メッセージを前記 アプリケーションプログラムに送り、前記第２の入力手段によって受け取られた メッセージからデータを抽出し、前記第 ２の出力手段を介して装置独立メッセージ中の前記データを前記クライアント装 置に送る処理手段と を備えたインタフェース装置。 ２． 複数のアプリケーションプログラムと請求の範囲第１項記載のインタフ ェース装置とを有する中央計算処理資源と、 それぞれが通信リンクを通じて前記中央計算処理資源にリンクされている複数 のクライアント装置と を備えたデータ管理システム。 ３． 前記中央計算処理資源は、複数のクライアント装置からのトランザクシ ョンの要求を受けてトランザクションの結果を前記複数のクライアント装置にお くる対話マネージャをさらに備えている請求の範囲第２項記載のシステム。 ４． 前記対話マネージャは、前記インタフェース装置に対する装置独立メッ セージを有するクライアント装置からの要求を通過させるとともに、前記の関連 したアプリケーションプログラムに対する装置依存メッセージを有するクライア ントからの要求を通過させるように形成されている請求の範囲第３項記載のシス テム。 ５． 前記インタフェース装置の記憶手段に記憶されているキーワードは、複 数の装置依存メッセージに関連している請求の範囲第２乃至４項記載のシステム 。 ６． 各装置独立メッセージは、デリミタによって区切られた三つの部分を有 している請求の範囲第２乃至５項記載のシステム。 ７． 前記メッセージの前記三つの部分は、それぞれ種類、長さ、値といった 特徴を有している請求の範囲第６項記載のシステム。 ８． 前記装置依存メッセージは、データと、表示装置上の前記データの表示 に関連した情報とを有している請求の範囲第２乃至７項記載のシステム。 ９． データ管理システムにおいて複数のアプリケーションプログラム間のイ ンタフェースを行う方法であって、トランザクションを実行するために各アプリ ケーションプログラムが装置依存メッセージを要求し、実行すべきトランザクシ ョンをクライアント装置が要求することができるようになっており、 i) 前記クライアント装置から、キーワードを含んだ装置独立メッセージを受 けるステップと、 ii) 前記装置独立メッセージから得られるキーワードと、一つ又は複数の記憶 された装置依存メッセージに各々が関連付けされている記憶されたキーワードと を比較し、一致するキーワードを見つけるステップと、 iii)前記装置依存メッセージ又は前記記憶された一致キーワードに関連付けさ れているメッセージを前記アプリケーションプログラムに送るステップと、 iv) 一つ又は複数のアプリケーションプログラムから、トランザクションの結 果として取り出されるデータを含んだ装置依存メッセージを受けるステップと、 v) 前記装置依存メッセージから、前記キーワードに従っ てデータを抽出するステップと、 vi) 装置独立メッセージ内の抽出されたデータを前記クライアント装置に送る ステップと を有する方法。