JP3777196B2 - クライアント／サーバシステム用の通信制御装置 - Google Patents
クライアント／サーバシステム用の通信制御装置 Download PDFInfo
- Publication number
- JP3777196B2 JP3777196B2 JP12195794A JP12195794A JP3777196B2 JP 3777196 B2 JP3777196 B2 JP 3777196B2 JP 12195794 A JP12195794 A JP 12195794A JP 12195794 A JP12195794 A JP 12195794A JP 3777196 B2 JP3777196 B2 JP 3777196B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- communication
- application
- server
- server application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Multi Processors (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は、クライアント／サーバシステムに係り、特にフロントエンド処理用のアプリケーション（クライアント・アプリケーション）をクライアント・マシン側にバックエンド処理用のアプリケーション（サーバ・アプリケーション）をサーバ・マシン側に実装する形態のクライアント／サーバシステムで両アプリケーション間のメッセージの授受を制御する通信制御装置に関する。
【０００２】
【従来の技術】
企業の情報システムでパソコンＬＡＮが定着すると共に、クライアント／サーバシステム、特にクライアント／サーバ型のデータベースシステムへの関心が高まっている。
【０００３】
クライアント／サーバ型データベースシステムは、ホスト集中型のデータベースシステムに比べて数々のメリットが得られる。すなわち、マルチベンダ環境でデータベースアプリケーションが実現できる。サーバ側とクライアント側で処理を分担できるので、パフォーマンスが高い。エンド・ユーザが４ＧＬ（第４世代言語）を用いて容易に業務に適したアプリケーションを開発できる。ユーザは、ミドルウェアを利用することにより表計算などの流通ソフト（パッケージ・ソフトウェア）を用いてデータベース・サーバから受け取った結果を好みに合わせて加工できる。分散型データベースを構築することにより、データの分散化が可能となり、またミラーリング機能によりシステム・ダウン時の損失を最小限に抑えることができる。クライアント・マシンとして低価格なパーソナル・コンピュータ（パソコン）を利用できるので、システムを低コストで構築できるなどである。また、クライアント・マシンとしてのパソコンを基幹業務と連携させて利用していくことにより業務の効率化がはかれる。
【０００４】
クライアント／サーバ型データベースシステムにおいて、クライアント・マシン上に実装されたクライアント・アプリケーションがデータベース・サーバマシン（以後、データベース・サーバと記述）のデータベースをアクセスする形態に、ＲＤＡ（リモート・データベース・アクセス：Remote Data Base Access ）とＲＰＣ（リモート・プロセジャ・コール：Remote Procedure Call)がある。
【０００５】
ＲＤＡは、ＩＳＯ（国際標準化機構）が定めたリモート・データベース・アクセスの標準プロトコルであるＲＤＡプロトコルを用いてクライアント・アプリケーションがデータベースをアクセスするものである。この場合、データベース・サーバ側に、クライアント・アプリケーションがネットワークを介して送信してくるＳＱＬ文を直接、ＤＢＭＳ（データベース管理システム）に渡し、該ＤＢＭＳからの結果を、クライアント・アプリケーションに返すミドルウェア（以後、ＲＤＡサーバと呼ぶ）を設ける。このため、クライアント・アプリケーションの開発者は、データベース・サーバ上のデータベースの構成を直接知っている必要がある。
【０００６】
一方、ＲＰＣはクライアント・アプリケーションがデータベース・サーバ上に実装されたサーバ・アプリケーションを、あたかもサブルーチンのようにネットワークを介して呼び出させて業務処理の一部分（手続き）を実行させ、該サーバアプリケーションからその結果を受け取ることにより分散アプリケーションを実現するものである。ＲＰＣ機能を利用することにより、協調分散処理を容易に実現することができる。協調分散処理とは、１つのトランザクション処理をクライアント・マシンと１または複数台のデータベース・サーバに振り分けて処理するものである。これにより、ＵＮＩＸデータベース・サーバのように比較的小さなマシンでも、複数台のサーバを使って大規模なＯＬＴＰシステム（オンライン・トランザクション処理システム）を構築できる。
【０００７】
【発明が解決しようとする課題】
まず、クライアント・アプリケーションがＲＤＡによりデータベース・サーバをアクセスする形態のＣ／Ｓデータベースシステム（クライアント／サーバ型データベースシステム）の問題点を述べる。
【０００８】
この形態においては、クライアント・アプリケーションの開発者はデータベース・サーバ上のデータベースの構成を知っている必要がある。したがって、該データベースの設計を行うデータベース管理者とクライアント・アプリケーションの開発者は、互いに密接な関係を保ちながらそれぞれの設計・開発を行う必要がある。
【０００９】
また、クライアント・アプリケーションの内容とデータベース構造が互いに影響し合う。このため、データベース管理は、データベース構造を変更する際にも、該変更が現在のクライアント・アプリケーションにどの程度まで影響するかを考慮せねばならず、クライアント・アプリケーションの内容にまで精通していなければならないなどの問題があった。
【００１０】
また、上述したような構成であるが故に、データベースの構造変更（データベースの分離／配置替え等）時には、必然的にクライアント・アプリケーションを修正する必要がある。
【００１１】
図２５は、その一例である。この場合、業務追加等によりデータベースサーバ１のデータベースＤＢ１のテーブル２（ＴＡＢＬＥ１）の項目数が増加し、アクセス性能が劣化したので、同図（Ｂ）に示すように該テーブル２（ＴＡＢＬＥ１）をテーブル３（ＴＡＢＬＥ１−１）とテーブル４（ＴＡＢＬＥ１−２）に分割した。これにより、クライアント・マシン６上のクライアント・アプリケーション７の一部は、同図（Ａ）に示す内容（ＩＮＳＥＲＴ ＴＡＢＬＥ１）から同図（Ｂ）に示す内容（ＩＮＳＥＲＴ ＴＡＢＬＥ１−１，ＩＮＳＥＲＴ ＴＡＢＬＥ１−２）に修正される。このため、該修正作業が新たなコスト増を招く、クライアント・マシンが一時的に使用できなくなる等の弊害をもたらしていた。
【００１２】
また、データベース・サーバの管理者にとっても、利用者の業務に支障をきたさないように、データベースの負荷分散やデータ管理単位に係わる変更作業はクライアント・アプリケーションの変更時と同一期間内に作業する必要があるなど、変更作業が可能な期間が制限されるなどの問題があった。
【００１３】
さらに、データベースのテーブル構成を、直接利用者に公開するため、利用者側でのデータの利用形態とデータベースの管理形態の両局面を考慮してデータベースのテーブル設計をする必要があり、システムを構築する上でテーブル設計が非常に難しいものとなっている。
【００１４】
また、ＲＤＡにおいては、図２６に模式的に示すように、例えば受注処理のような業務を行う場合、クライアント・アプリケーション１１は、顧客チェック、在庫チェック、在庫更新、受注登録などの処理をＳＱＬ文によりデータベース・サーバ２０に対して依頼する。また、各ＳＱＬ文の発行は前回のＳＱＬ文に対する応答をデータベース・サーバ２０から受け取った後に行う。このため該受注処理の間、クライアント・マシン１０とデータベース・サーバ２０との間で、何回もデータの送受信が行われることになる。このため、ネットワークのトラフィック量が増大し、システムの処理性能が落ちる場合がある。
【００１５】
また、さらに、ＲＤＡでは、クライアント・アプリケーションからのＳＱＬ文の依頼がＲＤＡサーバを介して直ちにＤＢＭＳに渡されるので、システム管理者が利用者に対してデータベースの運用ルールとして以下のような［１］〜［４］のルールを定めても、管理者がシステムの運用を監視／コントロールすることは実質的にできなかった。
【００１６】
［１］ アクセス時間に関する制限（大量のデータアクセスの禁止、データアクセス中の離席等の防止など）
［２］ アクセス時間帯の制限（管理者がデータベースのメンテナンス時間を確保するなどのため）
［３］ 過負荷制御（データベース・サーバ過負荷時のアクセス禁止）
［４］ 優先度制御（各業務（サービス）の実行を、その優先度に応じて動的に制御）
また、クライアント・アプリケーションのＲＤＡによるアクセス方法としては、上記ＳＱＬ文単位での処理依頼以外に、予めデータベース・サーバに予め一連のトランザクション処理（プロシジャ）を登録しておいて、このプロシジャを呼び出すことにより、所定のデータベース処理を行う、いわゆるストアド・プロシジャ・コールの方法がある。しかし、現状では、クライアント・アプリケーショが、上記ＳＱＬ文単位でのアクセスとストアド・プロシジャ・コールを使い分けて業務ロジックを作成する必要があるため、業務ロジックが複雑となり、開発の生産性を向上させるのが難しい。
【００１７】
現状のＤＢＭＳのデータベース・アクセスに対するセキュリティ機能は、テーブル単位及び列（項目）単位である。このため、利用者に対して項目単位にデータ公開を行う場合、アクセス権限の設定が図２７に示すように煩雑となる。また、業務システムを構築する場合、利用者の資格（エンドユーザ、業務管理者）毎にデータベースのアクセス権を変えることが一般的である。このため、例えば、同一利用者がエンドユーザにも業務管理者にもなる場合、該利用者に対して項目毎に当該権限を変えなければならないが、セキュリティ定義者は、同一利用者という観点から、全項目について同一権限を与えてしまう恐れがある。
【００１８】
次に、アプリケーションをユーザ・インタフェース用の入出力処理を担当するクライアント・アプリケーションとデータベース・アクセスに係わる業務ロジックを実行するサーバ・アプリケーションの２つに分け、それぞれをクライアント・マシンとデータベース・サーバに実装して、クライアント・アプリケーションがサーバ・アプリケーションを、ＲＰＣ等によりコール（ＣＡＬＬ）しながら業務処理を実行して行く形態のデータベースシステム（以下、便宜上、Ｃ／Ｓアプリ型データベースシステムと記述する）は、以下のような問題点をかかえている。
【００１９】
この場合、アプリケーション開発においては、上記両アプリケーション間で授受するデータの形式のみならず、サーバ・アプリケーションの処理時間やサーバ・アプリケーションの運用時間帯などに対応する処理形態についても配慮する必要がある。
【００２０】
上記処理形態としては、例えば、リアル通信、ディレイド通信がある。リアル通信においては、サーバ・アプリケーションがクライアント・アプリケーションから依頼された処理を終了した時点で、クライアント・アプリケーションに処理完了が通知される。
【００２１】
一方、ディレイド通信においては、サーバ・アプリケーションの処理完了を待たずにクライアント・アプリケーションからメッセージ（データ）を受信・保持した時点で、クライアント・アプリケーションに完了を通知する。
【００２２】
したがって、例えば、クライアント・アプリケーションがサーバ・アプリケーションに対して一方的にデータを集信する形態の集信型処理を、リアル通信で処理していた場合、サーバ・アプリケーションの処理時間が非常に長くなると、クライアント・アプリケーションに対する応答時間が遅延する。このような場合には、上記集信型処理を“リアル通信”から“ディレイド通信”に変更する必要がある。したがって、両アプリケーションの開発は、互いに密接な関係を持ち、両者を独立に開発することは難しい。また、上記処理形態の変更がアプリケーションのロジックに影響を及ぼすので、両アプリケーションの変更が必要となる場合が多く、生産性が低い。
【００２３】
クライアント・アプリケーションは、ユーザ・インタフェースに係わる処理を取り扱うので、処理するデータの属性（型式）は画面処理に適したものが望ましい。一方、サーバ・アプリケーションは、データベース・アクセスやそのアクセスにより得られたデータの加工などを行うので、このような処理に適した属性のデータで処理するのが好ましい。このため、クライアント・アプリケーションとサーバ・アプリケーション間でデータの授受を行う場合、いずれかのアプリケーション側でデータの属性変換処理が必要となる。これは、アプリケーション開発において作業量の負担をもたらし、アプリケーションの生産性を低下させる。
【００２４】
また、開発時のアプリケーションの動作試験は、図２８（Ａ）のようにクライアント・アプリケーション３１とサーバ・アプリケーション３２の両方が揃わないと行えない。また、ＲＰＣのテストにおいては、同図（Ｂ），（Ｃ）にそれぞれ示すようにドライバ３６やスタブ３７を作らないといけない。
【００２５】
すなわち、サーバ・アプリケーション３２を単独でテストしたい場合には、クライアント・アプリケーション３１に代わって該サーバ・アプリケーション３２に対して要求を発行するドライバを作成する必要がある（図２８（Ｂ）。一方、クライアント・アプリケーション３１を単独でテストしたい場合には、サーバ・アプリケーション３２に代わってクライアント・アプリケーション３１からの要求を受け取るスタブ３７を作成する必要がある（図２８（Ｃ））。
【００２６】
一方、独自のテスト支援ツールを使用してもよいが、この場合、その操作方法などに関する知識を習得する必要がある。
また、一般にクライアント・アプリケーションとサーバ・アプリケーションはＴＰモニタを介して連携させる形態をとるため、ＴＰモニタのＡＰＩ（アプリケーション・プログラミング・インタフェース）に従って作成する必要がある。このため、ＰＣ（パソコン）上に実装された市販パッケージ・ソフトの表ソフトやデータベース・アクセスソフトなどをクライアント・アプリケーションとして使用して、ＲＰＣ対応のＣ／Ｓアプリ型データベースシステムを構築することは、現状では不可能となっている。
【００２７】
さらに、現状のＣ／Ｓアプリ型のデータベースシステムでは、クライアント・アプリケーションがＲＰＣにより指定するサーバ・アプリケーションはデータベース・サーバ上で同一の実行環境でしか動作できない。換言すれば、同一のサーバ・アプリケーションは１つの業務処理でしか使用できないようになっている。このため、既存のサーバ・アプリケーションを新たな業務処理に流用しようとした場合、該サーバ・アプリケーションを複数の実行環境で動作可能とするために、その名称を変更する必要がある。このため、該名称の変更に伴う各種作業が必要となってくる。
【００２８】
すなわち、例えば、図２９に示すように、現在運用中のシステムにおいて、クライアント・アプリケーション４１がサーバ・アプリケーションＡをコール（ＣＡＬＬ）形態のある業務処理が稼働しているものとする。この後、業務拡張のため同図に示すように、サーバ・アプリケーションＡを流用して新たな業務処理を構築するために新規にクライアント・アプリケーション４２を開発する場合（［１］）、該新たな業務処理は別実行環境となるため、上記サーバ・アプリケーションＡを別名称のサーバ・アプリケーションＡ′で管理する必要がある（［２］）。ところが、このようにすると、障害発生等によりサーバ・アプリケーションＡを修正する保守作業を行う場合、サーバ・アプリケーションＡのみならずサーバ・アプリケーションＡ′についても保守作業を行わねばならなない（［３］）。すなわち、同一のサーバ・アプリケーションＡを二重管理しなければならないため、保守作業の負担が増大する。
【００２９】
【発明が解決しようとする課題】
本発明は、上述のような問題点に鑑みなされたもので、その目的は、以下のようなものである。
【００３０】
(1) クライアント・アプリケーションとサーバ・アプリケーションの開発・変更等の作業を互いに独立して進めることができるようにする。
(2) クライアント／サーバ方式のデータベースシステムにおいて、クライアント・アプリケーションを修正することなくデータベースの構造を変更することを可能とする。また、管理者は、クライアント・アプリケーションの内容を意識することなく、データベースの構造を変更できる。
【００３１】
(3) クライアント／サーバ方式のデータベースシステムにおいて、利用者側に公開するテーブルとデータベース・サーバ上のデータベースのテーブルを別々に設計可能とする。
【００３２】
(4) クライアント／サーバ方式のデータベースシステムにおいて、データベースのセキュリティ管理を容易なものとする。
(5) クライアント・アプリケーションとサーバ・アプリケーション間でのネットワークのトラフィック量を減少させると共に、業務処理の高速化を可能とする。
【００３３】
(6) 運用ルールを利用者に委ねなくても、管理者の裁量でデータベース・サーバを監視・制御できるようにする。
(7) クライアント・アプリケーションとサーバ・アプリケーションにリアル通信、ディレイド通信などのデータの処理形態を実現する機能を組み込まなくても、該データ処理形態を実現できるようにする。
【００３４】
(8) クライアント・アプリケーションとサーバ・アプリケーションがデータの送受信をする際に、いずれのアプリケーションにも該データ属性変換処理を組み込むことを不要にする。
【００３５】
(9) クライアント・アプリケーションとサーバ・アプリケーションの動作試験を、それぞれ独立に行えるようにする。
(10)既存の表計算ソフトやデータベース・アクセスソフト（ＤＢアクセスソフト）をクライアント・アプリケーションとして、クライアント／サーバデータベースシステムを構築できるようにする。
【００３６】
(11)同一のサーバ・アプリケーションを名称を変更することなく新たな業務処理に流用できるようにする。
【００３７】
【課題を解決するための手段】
図１は、本発明の原理説明図である。
以下に述べる請求項１〜４記載の発明は、業務処理をクライアント・アプリケーション５２とサーバ・アプリケーション６２によって実行するクライアント／サーバシステムの該クライアント・アプリケーション５２と該サーバ・アプリケーション６２間の情報の授受を制御する通信制御装置を前提とする。
【００３８】
請求項１記載の発明は、少なくともデータ処理形態とテーブル定義情報とを含む公開サービス情報（図２の公開サービス情報３００）を管理する公開サービス情報記憶手段（図２の通信データベース２２１）と、前記テーブル定義情報に基づいて入力テーブル（図５の入力テーブル３５１）を作成するテーブル作成手段（図２のメッセージキュー制御部２２５）と、前記クライアント・アプリケーション（図２のクライアント・アプリケーション１１０）からのＳＱＬを解析してデータを前記入力テーブルに格納する第一のＳＱＬ解析制御部（図２のＳＱＬ制御部２２２Ｃ）と、前記サーバ・アプリケーションからのＳＱＬを解析して前記入力テーブルからデータを取り出す第二のＳＱＬ解析制御部（図２のＳＱＬ制御部２２２Ｓ）と、前記入力テーブルにデータを格納した際に、前記サービス定義情報内のデータ処理形態が第一の処理形態（リアル通信）の場合には、前記サーバ・アプリケーションからの完了通知を待って前記クライアント・アプリケーション５２に対して完了通知を行い、前記サービス定義情報内のデータ処理形態が第二の処理形態（ディレイド通信）の場合には、前記サーバ・アプリケーション６２からの完了通知を待つことなく前記クライアント・アプリケーション５２に対して完了通知を行うメッセージ応答制御部 （図２のメッセージ応答制御部２２８）とを有する。
【００３９】
請求項２記載の発明は、請求項１記載の通信制御装置において、前記入力テーブルにデータが格納された際に前記サーバ・アプリケーションの状態を確認し、前記サーバ・アプリケーションが処理待状態である場合のみ、前記サーバ・アプリケーションに対して起動要求を行うサーバ・アプリケーション起動要求手段（図２のアプリ起動要求制御部２２９）を、更に備える。
【００４０】
請求項３記載の発明は、請求項２記載の通信制御装置において、前記公開サービス情報記憶手段は、公開情報として更に、前記テーブル定義情報で定義されるテーブルの各項目の第一の属性情報を記憶する。そして、前記入力テーブルに入力されるデータを前記第一の属性情報に従って変換して格納する第一の変換手段（コード変換／属性変換部２２３Ｃ）を、更に有する。
【００４１】
請求項４記載の発明は、請求項３記載の通信制御装置において、前記公開サービス情報記憶手段は、公開情報として更に、前記テーブル定義情報内で定義されるテーブルの各項目の第二の属性情報を記憶する。そして、前記入力テーブルから取り出されるデータを前記第二の属性情報に従って変換する第二の変換手段（コード変換／属性変換部２２３Ｓ）を、更に有する。
【００４２】
【作用】
請求項１記載の発明によれば、公開サービス情報を参照することにより、クライアント・アプリケーション５２とサーバ・アプリケーション６２の開発・変更作業を、互いに独立して進めることができる。また、クライアント・アプリケーション５２は公開サービス情報で提供される仕様に沿っていればよいので、データベースサーバ（図２のデータベースサーバ２００）上のデータベース（図２のデータベース６３）の構造を変更する際、クライアント・アプリケーション５２の修正が不要となる。管理者も、クライアント・アプリケーション５２の内容を意識することなく、データベースを変更できる。
【００４３】
また、さらに、クライアント・アプリケーション５２に公開する入力テーブルと、データベースサーバ（図２のデータベースサーバ２００）の管理するデータベースのテーブルを、別々に設計できる。
【００４４】
また、さらに、クライアント・ アプリケーション５２とサーバ・アプリケーション６２にリアル通信、ディレイド通信などのデータ処理形態を実現する機構を組み込まなくても、それらのデータ処理形態を実現できる。
【００４５】
請求項２記載の発明によれば、管理者側で、クライアント／サーバ・データベースシステムなどにおいて大量データアクセスの禁止や、データベース・アクセス中のクライアントの離席等の防止、データベースのメンテナンス時間の確保、データベース・サーバ過負荷時の入力抑止、さらには各業務処理（サービス）毎の優先度制御が可能になる。
【００４６】
請求項３記載の発明によれば、クライアント・アプリケーション５２は、内部でデータの属性変換処理を行わなくとも、自身のデータ処理に適した属性（形式）でデータの各項目を取り扱うことができる。
【００４７】
請求項４記載の発明によれば、クライアント・アプリケーション５２とサーバ・アプリケーション６２は、内部でデータの属性変換処理を行わなくとも、それぞれのデータ処理に適した属性（形式）でデータの各項目を取り扱うことができる。
【００４８】
【実施例】
以下、図面を参照しながら本発明の実施例を説明する。
図２は、本発明の一実施例のシステム構成図である。
【００４９】
同図において、クライアント・マシン１００とデータベース・サーバ２００とは、ＬＡＮ（ローカル・エリア・ネットワーク）またはＷＡＮ（ワイド・エリア・ネットワーク）を介して接続されている。また、データベース・サーバ２００にはコンソール３００が接続されている。このシステムは、Ｃ／Ｓアプリ型のデータベースシステムであり、クライアント・マシン１００側にクライアント・アプリケーション１１０が、データベース・サーバ２００側にサーバ・アプリケーション２１０が実装されている。そして、このクライアント・アプリケーション１１０とサーバ・アプリケーション２１０とが一体となって業務処理を実行する。
【００５０】
データベース・サーバ２００内には、通信ＤＢ制御機構（通信制御装置）２２０が設けられている。この通信ＤＢ制御機構２２０は、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０との間に介在し、これら両者にＡＰＩ（アプリケーション・プログラミング・インタフェース）を提供している。通信ＤＢ制御機構２２０は、利用者（クライアント）に対して各種公開サービスを提供する通信ＤＢ（通信データベース）２２１を内蔵しており、クライアント・アプリケーション１１０並びにサーバ・アプリケーション２１０は該公開サービスに従って作成される。
【００５１】
データベース・サーバ２００は、データベースシステム２４０を備えており、該データベースシステム２４０はＤＢＭＳ（データベース管理システム）２４２とデータベース（ＤＢ）２４４とから成っている。
【００５２】
サーバ・アプリケーション２１０は、このデータベースシステム２４０に対して、アクセスして、当該サービスに対応する処理（データベースの更新・参照、検索データの加工など）を行う。
【００５３】
通信手順制御部２０１は、例えばＴＣＰ／ＩＰプロトコルなどの通信プロトコルによりクライアント・アプリケーション１１０とネットワークを介してメッセージ（データ）の送受信を行う。このとき、クライアント・アプリケーション１１０からＳＱＬ文（ＩＮＳＥＲＴ）を受信すると、該クライアント・アプリケーション１１０を実行した利用者が、データベースサーバ２００を利用可能かをチェックする利用者認証処理を行う。
【００５４】
この利用者認証処理は、実際には、通信手順制御部２０１の依頼を受けて、利用者認証部２０２が実行する。
利用者は、通信ＤＢ２２１にアクセスする際、まず、データベースサーバ２００にログインする必要がある。この際、クライアント・マシン１００からデータベースサーバ２００に対して利用者識別子とパスワードが送られ、これらは通信手順制御部２０１に受信される。
【００５５】
利用者認証部２０２は、該利用者識別子とパスワードを通信手順制御部２０１から受け取り、これらを基に上記利用者がデータベースサーバ２００のサービスを受ける権利を有しているか否かの利用者認証及び、通信ＤＢ２２１へのアクセス権を有しているか否かをチェックする。このとき、後述する通信ＤＢ２２１内に登録されている該通信ＤＢ２２１のセキュリティ情報を参照する。そして、そのチェック結果を通信手順制御部２０１に返す。
【００５６】
また、上記のように、クライアント・アプリケーション１１０がＳＱＬ文の実行を依頼してきた際にも、上記利用者認証のチェック処理を行う。
通信手順制御部２０１は、上記ＳＱＬ文の実行依頼者がアクセス権限を有していると判断すると該ＳＱＬ文並びに上記実行依頼者の利用者識別子を通信ＤＢ制御機構２２０のＳＱＬ解析制御部２２２Ｃに送信する。
【００５７】
次に、通信ＤＢ制御機構２２０内の各ブロックを説明する。
通信ＤＢ（通信データベース）２２１は、一過性のデータを取り扱う特殊なデータベースであり、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０間で授受されるデータを仲介する。そして、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０に対するＡＰＩとして“ＩＮＳＥＲＴ”と“ＳＥＬＥＣＴ”という２つのデータ操作言語（ＤＭＬ）を提供している。
【００５８】
通信ＤＢ２２１の内部構成を図３に示す。
同図に示されているように、通信ＤＢ２２１内には、複数の公開サービス情報３００が登録される。この公開サービス情報３００は、利用者に対して公開されるサービス単位に登録され、サービス定義情報３０１とこれに包含されるテーブル定義情報３０３とから成る。サービス定義情報３０１は、利用者に対して公開されるサービスのデータの処理形態や、該サービスを実行するサーバ・アプリケーション２１０とのリンク情報が定義されるものであり、以下の［１］〜［４］の項目から成る。
【００５９】
［１］ サービス名
［２］ データ処理形態
［３］ クライアント・アプリケーション１１０により入力されたデータ（メッセ ージ）を通知すべきサーバ・アプリケーション２１０の名称
［４］ このサービスが公開されている利用者のユーザＩＤ／グループＩＤ
また、サービス定義情報３０１は、上記データ処理形態に応じて入力テーブル定義情報３０３Ｉのみまたは入力テーブル定義情報３０３Ｉと応答テーブル定義情報３０３Ｒの２個のテーブル定義を保有する。
【００６０】
ここで、上記［２］のデータ処理形態の種類を図４に示す。
各データ処理形態での通信方法には、リアル通信とディレイド通信がある。尚、同図において、入力テーブル３５１は、クライアント・アプリケーション１１０が“ＩＮＳＥＲＴ”文によりサーバ・アプリケーション２１０に対して通知するデータのキュー（リクエスト・キュー）として機能する。一方、応答テーブル３５２はサーバ・アプリケーション２１０が“ＩＮＳＥＲＴ”文によりクライアント・アプリケーション１１０に対して通知するデータのキュー（レスポンス・キュー）として機能する。
【００６１】
まず、同図（Ａ）は応答型（リアル通信）のデータ処理を説明する図である。このデータ処理においては、１つのサービス定義内に、入力テーブル３５１と応答テーブル３５２の２つのテーブルが生成される。
【００６２】
この応答型（リアル通信）のデータ処理では、クライアント・アプリケーション１１０は依頼データを組み立て、該データを“ＩＮＳＥＲＴ”文によりデータベース・サーバ２００に依頼する（［１］）。このデータは、入力テーブル３５１にキューイングされ、サーバ・アプリケーション２１０が“ＳＥＬＥＣＴ”文を発行することによって、該サーバ・アプリケーション２１０により読み出される（［２］）。サーバ・アプリケーション２１０は、該読み出したデータを基にデータベースシステム２４０をアクセスしてチェック並びに当該処理を行い、その処理結果を“ＩＮＳＥＲＴ”文により応答テーブル３５２にキューイングする（［３］）。そして、ＲＥＴＵＲＮ命令を発行することにより、クライアント・アプリケーション１１０に処理の終了が通知される（［４］）。クライアント・アプリケーション１１０は、該通知を受けた後に、“ＳＥＬＥＣＴ”文を発行して応答テーブル３５２にキューイングされている上記処理結果を受け取る（［５］）。尚、サーバ・アプリケーション２１０は、上記データのチェック時に誤りを検出した場合にも、その旨をクライアント・アプリケーション１１０に通知する。このように、応答型（リアル通信）データ処理は、クライアント・アプリケーション１１０とサーバ・アプリケーション１２０が、一問一答の会話形式により業務処理を実行するものである。
【００６３】
次に、同図（Ｂ）は、集信型（リアル通信）データ処理を説明する図である。この処理においては、サービス定義３０１内には入力テーブル３５１のみが登録される。この処理は、クライアント・アプリケーション１１０がサーバ・アプリケーション２１０に一方的にデータを集信するものである。すなわち、クライアント・アプリケーション１１０は、“ＩＮＳＥＲＴ”文により入力テーブル３５１にサーバ・アプリケーション２１０宛の通知データをキューイングする（［１］）。サーバ・アプリケーション２１０は、“ＳＥＬＥＣＴ”文を発行して該通知データを受け取る（［２］）。これに対して上記と同様にデータベースシステム２４０をアクセスしてチェック並びに当該処理を行い、該処理終了後のＲＥＴＵＲＮ命令により、クライアント・アプリケーション１１０にその処理結果の完了（正常または異常）が通知される（［３］）。クライアント・アプリケーション１１０は、該処理完了後に、上記と同様にして次のデータをサーバ・アプリケーション２１０に通知する。これにより、データベース・サーバ２００側に処理待ちデータが滞留することがなくなり、別の業務へ悪影響を与えることもない。
【００６４】
続いて、同図（Ｃ）は集信型（ディレイド通信）を説明する図である。この処理が上述した集信型（リアル通信）と異なる点は、クライアント・アプリケーション１１０が“ＩＮＳＥＲＴ”文により通信ＤＢ制御機構２００にデータ（メッセージ）を送信すると（［１］）、通信ＤＢ制御機構が該データ（メッセージ）を入力テーブル３５１にキューイングし、該データの保証がなされた時点で、クライアント・アプリケーション１１０に該“ＩＮＳＥＲＴ”文による処理の依頼の完了を通知する点である（［２］）。尚、この場合、上記クライアント・アプリケーション１１０の通知データは、後述するメッセージ保証制御部２２８内の不揮発性記憶媒体上に作成された通信データ保証ファイルにスタックされる。これにより、データベース・サーバ２００側での処理待ちデータの滞留が解決される。
【００６５】
サーバ・アプリケーション２１０は、動作可能な状態になったときに、“ＳＥＬＥＣＴ”文を発行して入力テーブル３５１から上記通知データを受け取り（［６］）、該データに対するチェック並びに当該処理終了後、ＲＥＴＵＲＮ命令を実行し、通信ＤＢ制御機構２２０に処理完了を通知する（［７］）。
【００６６】
上述したように、集信型（リアル通信）では、サーバ・アプリケーション２１０が動作しないと、クライアント・アプリケーション１１０は次のデータ処理に移行できない。これに対し、集信型（ディレイド通信）では、サーバ・アプリケーション２１０の動作に関係なく、直ちに次の処理に移行できる。したがって、集信型（リアル通信）と集信型（ディレイド通信）は、集信するデータの即時性の有無によって使い分ける。すなわち、集信したデータを即時に他の目的で利用する場合にはリアル通信を利用し、発送指示のようなある範囲（時間等）までに処理する場合にはディレイド通信を利用する。
【００６７】
さらに、同図（Ｄ）は、配信型（ディレイド通信）のデータ処理を説明する図である。この処理においては、サーバ・アプリケーション２１０が“ＩＮＳＥＲＴ”文によりクライアント・アプリケーション１１０に通知するデータを入力テーブル３５３にキューイングする（［１］）。通信ＤＢ制御機構２２０は、該通知データをメッセージ保証部２２８内の通信データ保証ファイルにスタックすると、完了通知をサーバ・アプリケーション２１０に返す（［２］）。クライアント・アプリケーション１１０は、この入力テーブル３５３にキューイングされているデータを、必要となった時点で“ＳＥＬＥＣＴ”文を発行することにより受け取る（［６］）。
【００６８】
このように、このデータ処理は、サーバ・アプリケーション２１０側で処理したデータを、クライアント・アプリケーション１１０が必要となった時点で受け取るものである。これは、例えば、別業務のデータをデータベース・サーバ２００側で一括処理し、その処理結果をクライアント・マシン１００側に通知する場合に使用される。
【００６９】
テーブル定義情報３０３Ｉ，３０３Ｒは自己が従属するサービス定義情報３０１で定義されたデータ処理形態に従って処理されるデータ（レコード）の形式を定義するものである。
【００７０】
ここで、図４に示す上述した入力テーブル３５１，３５３または応答テーブル３５２にキューイングされるレコードの形式を定義しているテーブル定義情報３０３Ｉ，３０３Ｒの内容について説明する。両テーブル定義情報は、同一の内容であり以下の［１］〜［３］の項目から成る。
【００７１】
［１］ テーブル名
［２］ レコードの全てのデータ項目名
［３］ 各データ項目の属性（データの形式：CHARACTER, NUMERIC, INTEGER,・・・)
［４］ 各データ項目のデータ長
上記公開サービス定義情報３００は、利用者が業務処理を構築するためのＡＰＩとして、すなわちクライアント・アプリケーション１１０を作成するための情報として、利用者に公開される。すなわち、公開サービス情報３００は、利用者が業務処理を構築するために、データベース・サーバ２００側が利用者に提供可能な公開サービスである。
【００７２】
該公開サービスとしては、各種の予約サービス、照会サービス、受注サービス、通知サービス等がある。
また、公開サービス情報３００の内容に従って、サーバ・アプリケーション２１０が開発されることになる。すなわち、通信ＤＢ２２１へ公開サービス情報３００を登録することによって、システム導入時のシステム設計及びシステム稼働後の業務処理の追加／変更が可能となる。換言するならば、最初のシステム設計またはシステム稼働後の業務処理の追加／変更の際には、まず導入しようとする業務処理の内容を規定する公開サービス情報３００を通信ＤＢ２２１に登録する必要がある。そして、これにより、業務処理の開発または追加／変更時に、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０の開発作業を、互いに独立に進めていくことが可能になる。
【００７３】
再び、図２に戻って、通信ＤＢ制御機構２２０の他のブロックについて説明する。
ＳＱＬ解析制御部２２２Ｃは、前記通信制御部２０１を介して入力するクライアント・アプリケーション１１０から発行されたＳＱＬの解析／チェックを行う。すなわち、そのＳＱＬ文を解析し、該ＳＱＬ文がアクセスしようとする通信ＤＢ２２１の利用資源（テーブル）に対する利用者のアクセス権をチェックする。そして、正当なアクセス権限を有していれば、該ＳＱＬ文による通信ＤＢ２２１の入力テーブルへの登録データをコード変換／属性変換部２２３Ｃへ出力する。尚、上記利用者のテーブルに対するアクセス権限のチェックは、資源利用認証部２２４によって行われる。
【００７４】
資源利用認証部２２４は、ＳＱＬ文解析制御部２２２Ｃを介して、上記ＳＱＬ文を送信してきたクライアント・アプリケーション１１０の実行者の利用者識別子と上記ＳＱＬ文がアクセスしようとする通信ＤＢ２２１のテーブルについての情報を受け取り、後述する通信ＤＢ２２１内に登録されたテーブルのセキュリティ情報を基に、上記テーブルに対するアクセス権の有無をチェックする。そして、そのチェック結果をＳＱＬ解析制御部２２２Ｃに返す。
【００７５】
コード変換／属性変換部２２３Ｃは、ＳＱＬ解析制御部２２２Ｃから受け取るデータに対して、通信ＤＢ２２１内の当該サービス定義情報３０１のテーブル定義情報３０３を参照して、コード並びに属性変換を行う。そして、変換後のデータをメッセージキュー制御部２２５に送る。
【００７６】
コード変換は、異機種間のコード系の変換であり、例えば、シフトＪＩＳ←→ＥＵＣ，ＥＢＣＤＩＣ←→ＥＵＣ等の変換が行われる。
一方、属性変換は、受信データの属性を通信ＤＢ２２１の当該入力テーブルの属性に変換するものであり、例えば、ＤＥＣＩＭＡＬ→ＩＮＴＥＧＥＲ等の変換が行われる。
【００７７】
メッセージキュー制御部２２５は、クライアント・アプリケーション１１０及びサーバ・アプリケーション２１０から発行される通知データの処理の待ち合わせ制御（キュー制御）を行うものである。この待ち合わせ制御に際しては、前述した図４に示す入力テーブル３５１，３５３及び応答テーブル３５２を用いる。これらのテーブル３５１〜３５３は、メッセージキュー制御部２２５自身によって、メモリ上に作成される。
【００７８】
図５は、メッセージ制御部２２５が上記テーブル３５１〜３５３を作成する方法を説明する図である。同図は、例えば、集信型のデータ処理が行われる公開サービス用の入力テーブル３５１の構成及びその作成方法を示している。
【００７９】
メッセージキュー制御部２２５は、通信ＤＢ２２１に登録されている該入力テーブル３５１の形式を定義している入力テーブル定義情報３０３Ｉを、当該公開サービス情報３００から読み出し、メモリ４００上に、キュー先頭ポインタ４１１、キュー最終ポインタ４１２、及び上記読み出した入力定義情報３０３Ｉと同一内容のテーブル情報４１３とから成るキューノード４１０を作成する。そして、このキューノード４１０によって通信バッファ２２６内に作成される連結リスト構造のキューを管理する。
【００８０】
該キューは、チェイン部５０１とデータ部５０２とから成るセル５００が、チェイン部５０１に設定されるポインタによって連結されていく構成の連結リストとなっており、データ部５０２にクライアント・アプリケーション１１０からサーバ・アプリケーション２１０宛の通知データが格納される。メッセージキュー制御部２２５は、キューノード４１０のキュー先頭ポインタ４１１、キュー最終ポインタ４１２、及びセル５００のチェイン部５０１を操作することによって、入力テーブル３５１に入力されるまたは入力テーブル３５１から取り出される通知データのキューイング制御を行う。
【００８１】
図６は通信バッファ２２６にキューイングされるデータの形式を示し、各データ部５０２にはデータ項目の長さとデータ項目の内容とからなる。
尚、図５においては、入力テーブル３５１の構成のみを示したが、応答テーブル３５２及び入力テーブル３５３も同様な構成で、メッセージキュー制御部２２５によって生成される。
【００８２】
また、図２のメッセージ保証制御部２２８は、ディレイド通信によるデータ処理、すなわち集信型（ディレイド通信）、配信型（ディレイド通信）において、それぞれサーバ・アプリケーション２１０またはクライアント・アプリケーション１１０に確実に通知データが渡るまでの間に、該通知データが電源断などのデータベースサーバ２００の各種異常状態から消失してしまうことを防止するために設けられたものであり、上記通知データを内蔵の不揮発性記憶媒体上に作成された不図示の通信データ保証ファイル内に格納して管理する。
【００８３】
アプリ起動要求制御部２２９は、入力テーブル３５１に通知データがキューイングされていれば、該当するサーバ・アプリケーション２１０の起動を、アプリ実行制御部２４１に要求する。
【００８４】
アプリ実行制御部２４１は、該要求を受けて、上記サーバ・アプリケーション２１０を起動させる。
サーバ・アプリケーション２１０は、起動されると、まず、ＳＱＬ文（ＳＥＬＥＣＴ文）を、通信ＤＢ制御機構部２２０内のＳＱＬ解析制御部２２２Ｓに発行する。
【００８５】
ＳＱＬ解析制御部２２２Ｓは、メッセージキュー制御部２２５に依頼して該ＳＱＬ文で依頼された入力テーブル３５１のキューから通知データを取り出し、該通知データをコード変換／属性変換部２２３Ｓに送る。
【００８６】
コード変換／属性変換部２２３Ｓは、上記通知データの属性をサーバ・アプリケーション２１０から依頼された属性に変換し、該変換後の通知データをＳＱＬ解析制御部２２２Ｓに送る。
【００８７】
ＳＱＬ解析制御部２２２Ｓは、上記受け取った通知データをサーバ・アプリケーション２１０に送り、ＳＱＬ文の完了を通知する。
ＳＱＬ解析制御部２２２Ｓは、応答型（リアル通信）のデータ処理を行うサーバ・アプリケーション２１０からは、そのデータ処理結果すなわちクライアント・アプリケーション１１０宛の通知データをＳＱＬ文（ＩＮＳＥＲＴ）により、該サーバ・アプリケーション２１０から受け取る。ＳＱＬ解析制御部２２２Ｓは、該通知データをコード変換／属性変換部２２３Ｓに送り、属性変換を依頼する。
【００８８】
コード変換／属性変換部２２３Ｓは、通信ＤＢ２２１内の上記ＳＱＬ文で指定された応答テーブル３５２の項目属性情報に従って、上記通知データの属性変換を行う。そして、この変換後の通知データをＳＱＬ解析制御部２２２Ｓに返す。
【００８９】
ＳＱＬ解析制御部２２２Ｓは、その受け取った通知データをメッセージキュー
制御部２２５に対して応答テーブル３５２にキューイングするよう要求する。
メッセージキュー制御部２２５は、これを受けて上記通知データを上記応答テーブル３５２にキューイングし、キューイングが終了するとＳＱＬ解析制御部２２２Ｓを介して、サーバ・アプリケーション２１０にＳＱＬ文（ＩＮＳＥＲＴ）の完了を通知する。
【００９０】
サーバ・アプリケーション２１０は、リアル通信の場合には処理が完了するとＲＥＴＵＲＮ命令の実行によりメッセージ応答制御部２３０に対して、クライアント・アプリケーション１１０に対して処理結果を通知してくれるように依頼する。
【００９１】
メッセージ応答制御部２３０は、該依頼に応じて、通信手順制御部２０１を介して、クライアント・アプリケーション１１０がデータベースサーバ２００に対して依頼したＳＱＬ文の実行完了を、該クライアント・アプリケーション１１０に通知する。
【００９２】
さらに、通信ＤＢサービス定義部２３１は、通信ＤＢ２２１に公開サービス情報３００を登録、更新または削除したりするもので、コンソール３００から例えばＤＤＬ（データ定義言語：Data Definition Language）系のＳＱＬ文を受け取ることにより、該ＳＱＬの指示に従って、新たな公開サービス情報３００の登録や、既存の公開サービス情報３００の更新や削除を実行する。これには、サービス定義情報３０１、入力テーブル定義情報３０３Ｉ、及び応答テーブル定義情報３０３Ｒをそれぞれ個々に登録、更新、削除することが可能である。
【００９３】
上記のような作業を行える利用者は、通信ＤＢ２２１の創成時に通信ＤＢ２２１内に登録される。そして、該利用者はコンソール３００からＧＵＩ（グラフィカル・ユーザ・インタフェース）の画面を介して、会話形式により上記作業を行えるようになっている。また、利用者作成のプログラムを、コンソール３００上で実行することによっても可能である。また、このコンソール３００を介して、通信ＤＢ２２１を創成することも可能となっている。
【００９４】
図７は、データ処理形態が応答型の場合に、通信ＤＢ制御機構２２０に対する命令と、通信ＤＢ制御機構２２０を介したデータの流れを図示するとともに、さらに他のクライアント・アプリケーションとの通信データがキューとして入力テーブル３５１、応答テーブル３５２に接続されることを図示したものである。
【００９５】
次に、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０と連携により行われる、図４に示す４種類のデータ処理形態の処理の流れを図２の実施例にそって説明する。
（Ａ）応答型（リアル通信）のデータ処理
《クライアント・アプリケーション１１０→通信ＤＢ制御機構２２０》
(1)クライアント・アプリケーション１１０がＳＱＬ文（ＩＮＳＥＲＴ）を実行すると、通信手順制御部２０１が該ＳＱＬ文を受け取り、利用者認証部２０２を介し利用者認証を行う。そして、通信ＤＢ２２１に対するアクセス権を認めると、そのＳＱＬ文をＳＱＬ解析制御部２２２Ｃに渡す。
【００９６】
(2)ＳＱＬ解析制御部２２２Ｃは、ＳＱＬ文を解析し、該ＳＱＬ文により指定されたテーブルに対するアクセス権を、資源利用認証部２２４を介しチェックする。そして、アクセス権が認められれば、指定データの属性変換をコード変換／属性変換部２２３Ｃに依頼する。
【００９７】
(3)コード変換／属性変換部２２３Ｃは、通信ＤＢ２２１に登録されている当該入力テーブル定義情報３０３Ｉに従い、上記指定データのコード変換／属性変換を行う。
【００９８】
(4)メッセージキュー制御部２２５は、変換後のデータを入力テーブル３５１にキューイングする。
《サーバ・アプリケーション２１０の起動》
(5)アプリ起動要求制御部２２９は、上記入力テーブル３５１に対応するサーバ・アプリケーション２１０の起動を、アプリ実行制御部２４１に要求する。
【００９９】
(6)アプリ実行制御部２４１は、サーバ・アプリケーション２１０が受信可能状態であれば、これを起動する。
《通信ＤＢ制御機構２２０→サーバ・アプリケーション２１０》
(7)サーバ・アプリケーション２１０は入力テーブル３５１からクライアント・アプリケーション１１０からの通知データを受信する為にＳＱＬ文（ＳＥＬＥＣＴ）を、ＳＱＬ解析制御部２２２Ｓに発行する。
【０１００】
(8)ＳＱＬ解析制御部２２２Ｓは、該ＳＱＬ文を解析し、メッセージキュー制御部２２５を介してＳＱＬ文で指定された入力テーブル３５１から上記通知データを取り出す。
(9) コード変換／属性変換部２２３Ｓは、ＳＱＬ解析制御部２２２Ｓからの依頼を受けて、上記通知データをサーバ・アプリケーション２１０が取り扱うデータ属性に変換する。
(10)ＳＱＬ解析制御２２２Ｓは、サーバ・アプリケーション２１０に、変換後の通知データを送ると共にＳＱＬ文の完了を通知する。
《サーバ・アプリケーション２１０→通信ＤＢ制御機構２２０》
(11)サーバ・アプリケーション２１０は、上記通知データを基に、データベースシステム２４０をアクセスし、当該データ処理を行う。
(12)サーバ・アプリケーション２１０は、該データ処理の結果をＳＱＬ文（ＩＮＳＥＲＴ）をＳＱＬ解析制御部２２２Ｓに出力する。
(13)コード変換／属性変換部２２３は、ＳＱＬ解析制御部２２２Ｓからの依頼を受けて、上記処理結果（クライアント・アプリケーション１１０宛の通知データ）を通信ＤＢ２２１に登録されている応答データ３５２のテーブル属性に従って属性変換する。
(14)メッセージキュー制御部２２５は、上記通知データを応答テーブル３５２にキューイングする。そして、このキューイングの完了をＳＱＬ解析制御部２２２Ｓに通知する。
(15)ＳＱＬ解析制御２２２Ｓは、サーバ・アプリケーション２１０にＳＱＬ文の処理完了を通知する。
《サーバ・アプリケーション２１０の完了》
(16)サーバ・アプリケーション２１０は、処理が完了すると、メッセージ応答制御部２３０にクライアント・アプリケーション１１０へのＳＱＬ文の実行完了通知を依頼する。
(17)メッセージ応答制御部２３０は、通信手順制御部２０１を介して、クライアント・アプリケーション１１０にＳＱＬ文（ＩＮＳＥＲＴ）の実行完了を通知する。
《クライアント・アプリケーション１１０→通信ＤＢ制御機構２２０》
(18)クライアント・アプリケーション１１０は、サーバ・アプリケーション２１０からの応答データ（上記通知データ）を受信する為にＳＱＬ文（ＳＥＬＥＣＴ）をデータベース・サーバ２００に発行する。
(19)通信手順制御部２０１は、このＳＱＬ文を受信すると、利用者認証部２０２を介して通信ＤＢ２２１に対するアクセス権の利用者認証を行い、該アクセス権を認めると、ＳＱＬ解析部２２２Ｃに上記ＳＱＬ文（ＳＥＬＥＣＴ）を送る。
(20)ＳＱＬ解析制御部２２２Ｃは、このＳＱＬ文を解析し、資源利用認証部２２４を介して指定応答テーブル３５２に対するアクセス権をチェックし、アクセス権が認められれば、メッセージキュー制御部２２５を介し、上記ＳＱＬ文で依頼された応答テーブル３５２から応答データを取り出す。
(21)コード変換／属性変換部２２３Ｃは、ＳＱＬ解析制御部２２２Ｃの依頼を受けて、上記応答データをクライアント・アプリケーション１１０が取り扱うデータ属性に変換する。
(22)ＳＱＬ解析制御部２２２Ｃは、変換後の応答データと共に通信手順制御部２０１を介して、ＳＱＬ文の完了をクライアント・アプリケーション１１０に通知する。
（Ｂ）集信型（リアル通信）のデータ処理
この処理は、基本的には、上述した応答型（リアル通信）のデータ処理からサーバ・アプリケーション２１０のＳＱＬ文（ＩＮＳＥＲＴ）の発行に対する処理を除いたものとなる。したがって、処理手順は、以下のようになる。
《クライアント・アプリケーション１１０→通信ＤＢ制御機構２２０》
上述した(1) 〜(4) の処理
《サーバ・アプリケーション２１０の起動》
上述した(5) 〜(6) の処理》
《通信ＤＢ制御機構２２０→サーバ・アプリケーション２１０》
上述した(7) 〜(10)の処理
《サーバ・アプリケーション２１０の完了》
上述した(16)〜(17)の処理
（Ｃ）集信型（ディレイド通信）のデータ処理
この処理は、基本的には上述した集信型（リアル通信）のデータ処理と同様であるが、一部の処理が異なっている。
《クライアント・アプリケーション１１０→通信ＤＢ制御機構２２０》
上記(1) 〜(4) の後に、次に述べる(4) ′の処理が行われる。
(4) ′メッセージ・キュー制御部２２５は、メッセージ保証制御部２２８に依頼して、入力テーブル３５１にキューイングしたサーバ・アプリケーション２１０宛の通知データを、通信データ保証ファイルに格納・保持してもらう。そして、メッセージ・キュー制御部２２５は、メッセージ保証制御部２２８から処理完了の通知を受けると、メッセージ応答制御部２３０にクライアント・アプリケーション１１０宛のＳＱＬ文（ＩＮＳＥＲＴ）の実行完了通知を依頼する。メッセージ応答制御部２３０は、これを受けて、通信手順制御部２０１を介してクライアント・アプリケーション１１０に上記ＳＱＬ文（ＩＮＳＥＲＴ）の実行完了を通知する。
《サーバ・アプリケーション２１０の起動》
上述した(5) 〜(6) の処理
《通信ＤＢ制御機構２２０→サーバ・アプリケーション２１０》
上述した(7) 〜(10)の処理
尚、(8) の処理の際、メッセージ保証制御部２２８は、メッセージ・キュー制御部２２５からの通知を受けて、通信データ保証ファイル内に保持されていた上記通知データを取り出す。この際、通信データ保証フィルタ内に保証されていた上記通知データを消去する。
《サーバ・アプリケーション２１０の完了》
(16)′サーバ・アプリケーション２１０は、処理が完了すると、通知ＤＢ制御機構２２０にその旨を通知する。
（Ｄ）配信型（ディレイド通信）のデータ処理
この処理は、上記（Ｃ）集信型（ディレイド通信）とは、通知データの流れが逆になる。すなわち、
［１］ 《サーバ・アプリケーション２１０→通信ＤＢ制御機構２２０》
［２］《通信ＤＢ制御機構２２０→クライアント・アプリケーション１１０》という順になる。
【０１０１】
次に、図８は、上述した応答型（リアル通信）のデータ処理の一具体例を示す模式図である。
同図に示す業務処理は、ある顧客から商品（この例では、２９型のカラーＴＶ）の注文を受けた際に、発送伝票を作成する処理を示している。この業務処理を連携して行うクライアント・アプリケーション１１０とサーバ・アプリケーション２１０は、データベース・サーバ２００側の通信ＤＢ制御機構２２０内の通信ＤＢ２２１に登録されている公開サービス情報３００に従って作成される。
【０１０２】
同図に示すように、該公開サービス情報３００には、サービス定義情報３０１として、データ処理形態が“応答型”である旨が登録されている。
また、入力テーブル定義情報３０３Ｉとしては、
［１］ データ項目名として、「顧客名」、「商品名」、「数量」、「単価」の４項目が定義されている。
【０１０３】
［２］ 上記データ項目の属性として、顧客名（CHARACTER)、商品名（CHARACTER)、数量（DECIMAL)、単価(DECIMAL) が定義されている。
［３］ 上記データ項目の項目長として、顧客名（30桁）、商品名（20桁）が定義されている。
【０１０４】
一方、応答テーブル定義情報３０３Ｒとしては、
［２］ データ項目名として、「消費税」、「合計」、「発送予定日」の３項目が定義されている。
【０１０５】
［２］ 上記データ項目の属性として、消費税（DECIMAL)、合計(DECIMAL) 、発送予定日(CHARACTER) が定義されている。
［３］ 上記データ項目の項目長として、消費税（５桁）、合計（７桁）、発送予定日（８桁）が定義されている。
【０１０６】
また、上述の公開サービス定義情報３００によって利用者に提供される公開サービスＡの利用者（参照可能ユーザまたは更新可能ユーザ）としてUser−１，User−２が登録されている。
【０１０７】
上述したような、公開サービスＡの公開サービス情報３００に従って作成されるクライアント・アプリケーション１１０は、下記の［１］〜［４］の部分から成る。
【０１０８】
［１］ 通信ＤＢ制御機構２２０の通信ＤＢ２２１の当該入力テーブル３５１にキューイングするデータ（入力データ）を作成する処理。上記入力データは、公開サービスＡの入力テーブル定義表の内容に従った形式にする。また、上記入力データの作成のために必要となるデータ（顧客名、商品名、数量、単価）の入力画面を表示部１２０に表示し、該入力画面から上記入力データを読み込むユーザ・インタフェースに係わる処理を行う。
【０１０９】
［２］ 上記の［１］で作成された入力データを、通信ＤＢ制御機構２２０内の公開サービスＡの入力テーブル３０３Ｉに登録してくれるように、ＳＱＬ文（ＩＮＳＥＲＴ）によりデータベース・サーバ２００に依頼する処理。
【０１１０】
［３］ 公開サービスＡの応答テーブル３０３Ｒに登録されているサーバ・アプリケーションの応答結果の取り出しを、ＳＱＬ文（ＳＥＬＥＣＴ）により、データベース・サーバ２００に求める処理。
【０１１１】
［４］ 上記［３］の処理でデータベース・サーバ２００から受け取った応答結果を加工して、クライアント・マシン１００の表示部１２０に伝票画面を表示させる処理。
【０１１２】
上記応答結果のデータ形式は、通信ＤＢ２２１内の公開サービスＡの応答テーブル定義表３５２に定義されているので、これに従って上記加工処理は作成される。このように、クライアント・アプリケーション１１０は、データベース・サーバ２００の通信ＤＢ２２１に登録されている公開サービスＡの公開サービス情報３００を参照することにより作成される。
【０１１３】
一方、上記クライアント・アプリケーション１１０からの依頼を、通信ＤＢ制御機構２２０を介して受け付け、処理するサーバ・アプリケーション２１０も、公開サービスＡの公開サービス情報３００の内容に従って作成される。
【０１１４】
該サーバ・アプリケーション２１０は、以下の［１］〜［４］の部分から成る。
［１］ ＳＱＬ文（ＳＥＬＥＣＴ）により、通信ＤＢ制御機構２２０に対して公開サービスＡの入力テーブル３５１にキューイングされている自己宛の通知データ（前記クライアント・アプリケーション１１０の入力データ）の転送を要求し、該通知データを通信ＤＢ制御機構２２０から受け取る処理。
【０１１５】
［２］ 上記通知データを基に、データベースシステム２４０をアクセスして、該データベースシステム２４０内のデータベース２４４の当該ファイル（この例では、顧客マスタファイル２４４１、商品マスタファイル２４４２、在庫マスタファイル２４４３、取引履歴ファイル２４４４）のデータの参照・更新を行う処理。そして、公開サービスＡの応答テーブル定義表３０３Ｒの定義に行って、通信ＤＢ制御機構２２０の公開サービスＡの応答テーブル３５２に登録するデータ（応答データ）を作成する処理。この応答データは、クライアント・アプリケーション１１０がデータベース・サーバ２００に対して依頼した要求の応答結果となるものであるが、サーバ・アプリケーション２１０はこれをあえて意識する必要はなく、あくまでも応答テーブル定義表３０３Ｒの内容に従って、上記応答データを作成すればよい。
【０１１６】
［３］ ＳＱＬ文（ＩＮＳＥＲＴ）により、通信ＤＢ制御機構２２０に対して上記応答データを応答テーブル３５２に登録するように依頼する処理。
［４］ ＲＥＴＵＲＮ命令により、通信ＤＢ制御機構２２０内のメッセージ応答制御部２３０に対して、クライアント・アプリケーション１１０のＳＱＬ文（ＩＮＳＥＲＴ）の実行完了を通知するように依頼する処理。
【０１１７】
以上のようにして作成されたクライアント・アプリケーション１１０とサーバ・アプリケーション２１０は、互いに通信ＤＢ制御機構２２０を介して、データの送受信を行う。そして、この場合、クライアント・アプリケーション１１０は、データベース・サーバ２００の通信ＤＢ制御機構２２０を２回アクセスするだけである。すなわち、要求依頼時に公開サービスＡの入力テーブル３５１を１回、該要求に対する応答結果の受信時に公開サービスＡの応答テーブル３５２を１回アクセスするだけである。そして、実際のデータベースすなわちデータベースシステム２４０のデータベース２４４に対する検索・更新などを行うバックエンド処理は、サーバ・アプリケーション２１０が担当する。このサーバ・アプリケーション２１０も、通信ＤＢ制御機構２２０に対するアクセスは２回（入力テーブル３５１と応答テーブル３５２をそれぞれ１回）である。
【０１１８】
上記例は、応答型（リアル通信）のデータ処理の例であるが、次に示す図９は、前述した従来、クライアント・アプリケーション１１０がＲＤＡにより行っていた受注処理を本実施例の集信型のデータ処理により行う例を示す模式図である。
【０１１９】
この場合、データベース・サーバ２００の通信ＤＢ制御機構２２０内の通信ＤＢ２２１にクライアント・アプリケーション１１０からサーバ・アプリケーション２１０に渡すべきデータ項目（この場合、「顧客No. 」、「部品No. 」、「発注数」、「受注番号」）について、上述したような形式で集信型の公開サービス情報３００の入力テーブル定義情報３０３Ｉに定義する。そして、この入力テーブル定義情報３０３Ｉに従って、利用者からそれに定義されているデータ項目のデータを利用者から入力し、その入力データをＳＱＬ文（ＩＮＳＥＲＴ）により、通信ＤＢ制御機構２２０の当該入力テーブル３０３Ｉに登録するように依頼する処理を、クライアント・アプリケーション１１０として作成する。
【０１２０】
一方、ＳＱＬ文（ＳＥＬＥＣＴ）により、上記入力テーブル３０３Ｉからクライアント・アプリケーション１１０から入力データを受け取ってデータベースシステム２４０の当該データベース（ＤＢ）２４４、（顧客情報ファイル２４４６、在庫情報ファイル２４４７、受注情報ファイル２４４８を有する）をアクセスして、顧客チェック、在庫チェック、在庫更新、受注登録などのバックエンド処理を行うサーバ・アプリケーション２１０を作成する。
【０１２１】
これにより、クライアント・アプリケーション１１０は、データベース・サーバ２００に対し１回アクセスするだけで、すなわち入力テーブル３０３Ｉへ入力データを挿入するＳＱＬ文（ＩＮＳＥＲＴ）をデータベース・サーバ２００へ送信するだけで、１回の受注処理が終了する。これにより、従来に比べ、短時間で処理が終了すると共に、ネットワーク上のトラヒック量が削減され、通信コストが低減される。
【０１２２】
また、特に具体例は示さないが、配信型（ディレイド通信）においても、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０は、通信ＤＢ２２１の当該入力テーブル定義情報３０３Ｉの定義内容に従って、それぞれ独立に作成することが可能である。
【０１２３】
また、データベースシステム２４０に対するアクセスは、サーバ・アプリケーション２１０のみが担当するので、該データベースシステム２４０のデータベース２４４の構造が変更されても、クライアント・アプリケーション１１０の修正は不要となる。
【０１２４】
図１０は、クライアント・アプリケーション１１０がデータベース２４４のデータ更新を行い、このデータ更新をサーバ・アプリケーション２１０がクライアント・アプリケーションに通知することを示す。
【０１２５】
図１１は、データベース２４４の構造が変更されても、クライアント・アプリケーション１１０の修正が不要となる例を模式的に示す。これは、従来システムの問題点で取り上げた図２５に対応するものである。
【０１２６】
図１１（Ａ）に示すように、サーバ・アプリケーション２１０が、通信ＤＢ制御機構２２０内の入力テーブル３５１（通信ＤＢ−ＴＡＢＬＥ１）を介して、クライアント・アプリケーション１１０からの依頼データを受け取り、該依頼データをデータベースシステム２４０のデータベース２４４（ＤＢ１）のＴＡＢＬＥ１（ＤＢ１−ＴＡＢＬＥ１）に挿入する業務処理が行われていたとする。
【０１２７】
この場合、業務追加等によりＤＢ１−ＴＡＢＬＥ１の項目数が増加し、データベースＤＢ１に対するアクセス性能が低下し、同図（Ｂ）に示すようにデータベースＤＢ１において上記ＤＢ１−ＴＡＢＬＥ１をＤＢ１−ＴＡＢＬＥ１−１とＤＢ１−ＴＡＢＬＥ１−２に分割するものとする。この場合、サーバ・アプリケーション２１０の修正だけで対処できる。すなわち、同図（Ａ）に示すサーバ・アプリケーション２１０の中の“INSERT DB1-TABLE1 ”という1 つのステートメントを、同図（Ｂ）に示すように、“INSERT DB1-TABLE1-1 ”と“INSERT DB1-TABLE1-2 ”の２つのステートメントに変更するだけでよい。この変更は、通信ＤＢ制御機構２２０の入力テーブル３５１（通信ＤＢ−ＴＡＢＬＥ１）の構成に変更を及ぼさない。従って、クライアント・アプリケーション１１０の変更は不要である。したがって、データベースシステム２４０の管理者は、クライアント・アプリケーション１１０を意識することなく、データベース２４４の構造を変更することができる。
【０１２８】
また、利用者（クライアント・アプリケーション１１０の開発者）には、通信ＤＢ２２１に登録された公開サービス情報３００（サービス定義情報３０１、入力テーブル定義情報３０３Ｉ、応答テーブル定義情報３０３Ｒ）のみが公開され、データベース・サーバ２００側のデータベースシステム２４０のデータベース２４４の構造については公開されない。したがって、利用者に公開するテーブルの設計・管理とデータベースシステム２４０のデータベース２４４に登録するテーブルの設計・管理を分離してとられることができる。これにより、データベースのテーブル設計において、利用者に公開する通信ＤＢ２２１のテーブルとデータベースシステム２４０のデータベース２４４とを、独立して別々に設計することができる。通信ＤＢ２２１のテーブル設計者（データ公開者）は、利用者の使い易さを考慮してテーブルを設計・管理すればよく、データベースシステム２４０のデータベース２４４のテーブル設計者（データベース管理者）は、該データベース２４４のアクセス性能等や共用管理を考慮してテーブルを設計・管理すればよい。
【０１２９】
図１２は、通信ＤＢ２２１に登録されるセキュリティ情報の内容を説明する模式図である。
同図において、利用権を与えられた利用者を“利用可能ユーザ”、更新権を与えられたユーザを“更新可能ユーザ”として示している。
【０１３０】
該セキュリティ情報としては、通信ＤＢ２２１に対するアクセス権に係るセキュリティ情報１２１０と公開サービス情報３００（同図に示すサービスＡ，Ｂ，Ｃ）に対するアクセス権に係わるセキュリティ情報１２２０がある。
【０１３１】
通信ＤＢ２２１のセキュリティ情報１２１０は、利用権と更新権の２つの項目がある。利用権が与えられた利用者（ユーザ）は、通信ＤＢ２２１へのアクセスは可能であるが通信ＤＢ２２１の更新はできない。更新権が与えられた利用者は、通信ＤＢ２２１の更新も可能である。
【０１３２】
通信ＤＢ２２１に対する接続要求が行われたときには、該アクセス者が上記利用権または更新権のいずれかを有しているかのチェックが行われ、いずれも有していない場合には、通信ＤＢ２２１に対するアクセスは禁止される。
【０１３３】
また、公開サービス情報３００（公開サービス）のセキュリティ情報には、参照権と更新権がある。参照権が与えられた利用者は、当該公開サービス情報３００に対応するテーブル３５１〜３５３へのアクセスのみが可能であり、公開サービス情報３００の内容の更新（サービス定義情報３０１及びテーブル定義情報３０２，３０３）の更新はできない。一方、更新権が与えられた利用者は上記アクセスのみならず、公開サービス情報３００の更新並びに削除が可能である。同図において、参照権が与えられた利用者を“参照可能ユーザ”、更新権が与えられたユーザを“更新可能ユーザ”として示している。
【０１３４】
尚、通信ＤＢ２２１に対する更新権を与えられた利用者は、公開サービス情報３００の更新・削除も可能である。
次に、上記構成の実施例の動作を説明する。
【０１３５】
まず、通信ＤＢ２２１にクライアント・アプリケーション１１０に公開するサービス定義情報３０１を登録する際の動作を説明する。この登録は、上述した公開サービス情報３００の更新権が与えられた利用者のみが可能である。
【０１３６】
ア）該利用者は、コンソール３００のＧＵＩ画面上で通信ＤＢ２２１のテーブルを設計し、データベース・サーバ２００に対し、該テーブルの定義情報をＳＱＬ文により登録依頼する。
【０１３７】
通信手順制御部２０１は、この要求を受け取ると、利用者認証部２０２を介し利用者認証を行い、通信ＤＢ２２１に対するアクセス権を認めるとＳＱＬ解析制御部２２２Ｃに上記ＳＱＬ文を渡す。
【０１３８】
イ）ＳＱＬ解析制御部２２２Ｃは、このＳＱＬ文を解析し、資源利用認証部２２４を介し通信ＤＢ２２１に対する登録権をチェックする。
ウ）該チェックにより、登録権の確認がとれると、コード変換／属性変換部２２３Ｃを介し、コード変換する。
【０１３９】
エ）通信ＤＢサービス定義部２３１は、依頼されたテーブル定義情報を通信ＤＢ２２１に登録する。
オ）通信ＤＢサービス定義部２３１は、登録が完了すると、ＳＱＬ解析制御部２２２Ｃに完了通知を行う。
【０１４０】
カ）ＳＱＬ解析制御部２２２Ｃは、通信手順制御部２０１を介し、クラアイント・アプリケーション１１０に登録完了を通知する。
キ）コンソール３００は、これを受けて、ＧＵＩ画面上に登録完了を表示する。
【０１４１】
次に、本実施例におけるセキュリティ管理の方法を説明する。
このセキュリティ管理は、通信ＤＢ２２１への接続要求時と該通信ＤＢ２２１内の入力テーブル３０３Ｉ及び応答テーブル３０３Ｒに対するアクセス時に行われる。
【０１４２】
１．通信ＤＢ２２１への接続要求時にセキュリティ・チェック
このセキュリティ・チェックは、通信手順制御部２０１が利用者認証部２０２を介して行う。図１３は、このチェック処理を説明するフローチャートである。
【０１４３】
通信手順制御部２０１は、クライアント・アプリケーション１１０から、ネットワークを介して通信ＤＢ２２１への接続要求を受信すると、該要求時に送られてきた利用者識別子を利用者認証部２０２に送り、上記クライアント・アプリケーション１１０の実行者が通信ＤＢ２２１に対する利用権を有しているか否かのチェックを依頼する（Ｓ１）。
【０１４４】
利用者認証部２０２は、通信ＤＢ２２１に登録されている通信ＤＢ２２１のセキュリティ情報１２１０（図１２）を参照して、上記利用者が該通信ＤＢ２２１の利用権を有しているか否かチェックし、そのチェック結果を通信手順制御部２０１に返す（Ｓ２）
通信手順制御部２０１は、該チェック結果を受け取り、利用者が通信ＤＢ２２１の利用権を有していることが分かると（Ｓ３，ＹＥＳ）、クライアント・アプリケーション１１０に対して“通信ＤＢ２２１への接続が成功した”旨の応答メッセージを返し（Ｓ４）、クライアント・アプリケーション１１０から該通信ＤＢ２２１のテーブルへのアクセス要求を待つ（Ｓ５）。
【０１４５】
一方、上記ステップＳ３で、利用者が通信ＤＢ２２１の利用権を有していないことが分かると（Ｓ３，ＮＯ）、クライアント・アプリケーション１１０に対して、“通信ＤＢ２２１への接続が失敗した”旨の応答メッセージを返す（Ｓ６）。
【０１４６】
２．テーブルアクセス要求受信時のセキュリティチェック
このセキュリティチェック処理は、通信ＤＢ制御機構２２０のＳＱＬ解析制御部２２２Ｃが資源利用認証部２２４を介して行う。
【０１４７】
図１４は、このチェック処理を説明するフローチャートである。
ＳＱＬ解析制御部２２２Ｃは、通信手順制御部２０１からテーブルのアクセス要求のＳＱＬ文を受信すると、資源利用認証部２２４に該指定テーブル名と該アクセスを行ったクライアントの利用者識別子を送り、資源利用認証部２２４へ該クライアントが上記指定テーブルに対するアクセス権を有しているか否かのチェックを依頼する（Ｓ１１）。
【０１４８】
資源利用認証部２２４は、通信ＤＢ２２１の上記指定されたテーブルが属する公開サービスのセキュリティ情報１２２０を参照し、上記受け取った利用者識別子を基に、上記指定テーブルに対するクライアントのアクセス権をチェックする。該アクセスには、“参照”と“更新”の２種類があり、“参照依頼”の場合は上記セキュリティ情報１２２０に登録されている参照権情報を、“更新依頼”の場合は上記セキュリティ情報１２２０に登録されている更新権情報をチェックする。そして、そのチェック結果をＳＱＬ解析制御部２２２Ｃに返す（Ｓ１２）。
【０１４９】
ＳＱＬ解析制御部２２２Ｃは、上記チェック結果を判別し、クライアントの指定テーブルに対するアクセスが正当であれば（Ｓ１３，ＹＥＳ）、上記公開サービスに対応したサーバ・アプリケーション２１０にクライアントからの通知データが渡るように、メッセージキュー制御部２２５に上記通知データを上記指定テーブルに登録（キューイング）するように依頼する（Ｓ１４）。
【０１５０】
一方、上記ステップＳ１３で、クライアントが指定テーブルに対する正当なアクセス権を有していないことが分かると（Ｓ１３，ＮＯ）、通信手順制御部２０１を介してクライアント（クライアント．アプリケーション１１０）に“アクセス権が無い旨”の応答メッセージを通知する（Ｓ１５）。
【０１５１】
また、本実施例では、あるクライアントがデータベースシステム２４０のデータベース２４４（以後便宜上実ＤＢ２４４と記述する）に対して大量のデータのアクセスをしても、他のクライアントへの応答性に悪影響を与えることはない。
【０１５２】
これは、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０との間に通信ＤＢ制御機構２２０を介在させ、クライアント・アプリケーション１１０による通信ＤＢ２２１へのデータの格納処理（通信ＤＢ格納処理）と該格納データを用いたサーバ・アプリケーション２１０に実ＤＢ２４４へのアクセス（実ＤＢアクセス処理）を、通信ＤＢ制御機構２２０内に設けたキュー制御機構により分類させ、それぞれ非同期に動作させることにより実現している。
【０１５３】
これを、図１５のフローチャートを参照しながら説明する。
通信ＤＢ制御機構２２０において、メッセージキュー制御部２２５が開設されている公開サービスの入力テーブル３５１に対するデータの格納要求待ち状態にあるときに、クライアント・アプリケーション１１０から該入力テーブル３５１に対するデータの格納要求（ＩＮＳＥＲＴ）があると（Ｓ３１）、メッセージキュー制御部２２５は、該データを入力テーブル３５１にキューイングする。すなわち、メモリ上に獲得した通信バッファ２２６に上記データを格納し、これを入力テーブル３５１のキューにリンクさせる（Ｓ３２）。
【０１５４】
そして、このキューイング処理が完了すると、通信ＤＢ２２１への格納要求の実行が完了した旨の応答メッセージを、該要求元のクライアント・アプリケーション１１０に通知する（Ｓ３３）。
【０１５５】
メッセージキュー制御部２２５は、上記入力テーブル３５１にキューイングされるデータを処理する当該サーバ・アプリケーション２１０の現在の状態を調べ、現在、処理の実行中ならば、前記ステップＳ３１に戻り、再びクライアント・アプリケーション１１０からの格納要求待ちとなる（Ｓ３４，処理中）。
【０１５６】
一方、上記当該サービス・アプリケーション２１０が現在、処理待ち状態にあれば（Ｓ３４，処理待ち）、アプリ起動要求制御部２２９を介してアプリ実行制御部２４１に上記当該サーバ・アプリケーション２１０の起動要求を行う（Ｓ３５）。
【０１５７】
これにより、アプリ実行制御部２４１は、上記当該サーバ・アプリケーション２１０の状態を“起動要求待ち”（Ｓ３６）から“処理中”に変更させる（Ｓ３７）。そして、上記当該サーバ・アプリケーション２１０を実行させる（Ｓ３８）。
【０１５８】
当該サーバ・アプリケーション２１０は、通信ＤＢ２２１すなわち上記入力テーブル３５１からクライアント・アプリケーション１１０により格納されたデータを取り出し、該データを基に実ＤＢ２４４をアクセスし、当該データ処理を行う（Ｓ３９）。
【０１５９】
アプリ実行制御部２４１は、上記当該サーバ・アプリケーション２１０の処理が終了すると、上記入力テーブル３５１に上記当該サーバ・アプリケーション２１０宛のデータが格納（キューイング）されていないか調べ、有れば（Ｓ４０，データ有り）、再び、上記ステップＳ３８に戻り上記当該サーバ・アプリケーション２１０を起動させる。これにより、入力テーブル３５１に格納されているデータがなくなるまで上記ステップＳ３８〜Ｓ３９の処理が繰り返される。
【０１６０】
そして、アプリ実行制御部２４１は、入力テーブル３５１に格納されているデータが無くなると（Ｓ４０，データ無し）、上記当該サーバ・アプリケーション２１０の状態を“処理待ち”にさせる（Ｓ４１）。これにより、上記当該サーバ・アプリケーション２１０は再び起動要求待ちとなる（Ｓ３６）。
【０１６１】
このように、通信ＤＢ制御機構２２０は、クライアント・アプリケーション１１０からの通信ＤＢ２２１へのデータ格納要求に対して、該格納データを当該公開サービスの入力テーブル３５１へのキューイングが終了した時点でその格納要求の完了を直ちにクライアント・アプリケーション１１０に通知する。したがって、クライアント・アプリケーション１１０は、通信ＤＢ２２１へのアクセスに対して常に速い応答を受け取ることができる。また、通信ＤＢ制御機構２２０も、多くのクライアント・アプリケーションからの通信ＤＢ２２１へのアクセスを、短時間で多量に受け付けることができる。
【０１６２】
次に、図１６は、本実施例における、管理者のアクセス時間帯、データベースサーバ２００の過負荷制御、及び業務毎の優先度制御の運用管理方法を説明する図である。
【０１６３】
同図において、データベースサーバ２００には、２台のクライアント・マシン１１０−１，１１０−２が接続され、データベースサーバ２００内には２つの通信ＤＢ２２１Ａ，２２１Ｂが構築されている。また、通信ＤＢ２２１Ａには公開サービスＡが、通信ＤＢ２２１Ｂには公開サービスＢが登録されている。そして、公開サービスＡに対応するサーバ・アプリケーション２１０Ａが、公開サービスＢに対応するサーバ・アプリケーション２１０Ｂが実装されている。
【０１６４】
また、データベースサーバ２００内のデータベースシステム２４０のデータベース（実ＤＢ）２４４は、テーブル群Ａ（テーブルＡ１，Ａ２）、テーブル群Ｂ（テーブルＢ１）が登録されている。そして、サーバ・アプリケーション２１０Ａは実ＤＢ２４４のテーブル群Ａをアクセスし（これをアクセスａ２と呼ぶ）、サーバ・アプリケーション２１０Ｂは実ＤＢ２４４のテーブル群Ｂをアクセスする（これをアクセスｂ２と呼ぶ）。また、クライアント・マシン１１０−１からの通信ＤＢ２２１Ａの公開サービスＡに対するアクセスはａ１、クライアント・マシン１１０−２からの通信ＤＢ２２１Ｂの公開サービスＢに対するアクセスはｂ１と呼ぶことにする。
【０１６５】
１．アクセス時間帯の運用・管理
例えば、実ＤＢ２４４においてテーブル群Ａについてのみメンテナンスを行う事態が生じたとする。この場合、管理者は、クライアント・マシン１１０−１の通信ＤＢ２２１Ａに対するアクセスａ１またはサーバ・アプリケーション２１０の実ＤＢ２４４に対するアクセスａ２を抑止させる。この間、実ＤＢ２４４のテーブル群Ｂに対するアクセス、すなわちクライアント・マシン１１０−２の通信ＤＢ２２１Ｂに対するアクセスｂ１及びサーバ・アプリケーション２１０Ｂの実ＤＢ２４４に対するアクセスｂ２は抑止させる必要はない。すなわち、テーブル群Ｂに対する処理は中断させることなく、テーブル群Ａをメンテナンスすることが可能となる。
【０１６６】
尚、アクセスａ１の抑止は、通信ＤＢ２２１Ａのサービス閉塞機能により行う。また、アクセスａ２の抑止は、サーバ・アプリケーション２１０Ｂの実行環境の停止により行う。アクセスａ２のみの抑止を行った場合、クライアント・マシン１１０−１に対しては、通信ＤＢ２２１Ａに対するアクセスａ１、すなわち公開サービスＡは停止させることなく、実ＤＢ２４４のメンテナンスを行うことができる。何故なら、この間、アクセスａ１による要求は通信ＤＢ２２１Ａの公開サービスＡに対応する入力テーブル３５１にキューイングされるからである。
【０１６７】
このように、本実施例においては、通信ＤＢ２２１を設けたことにより、システムの停止範囲を局所化した運用が可能となる。
２．過負荷制御
これは、各公開サービスに対して重要度を設定し、データベースサーバ２００の負荷が高くなったときには、重要度の低い公開サービスへのアクセスを停止することにより行う。
【０１６８】
例えば、図１６の例では、公開サービスＡの方が公開サービスＢよりも重要度が低い場合、クライアント・マシン１１０−１からの通信ＤＢ２２１−Ａの公開サービスＡへのアクセスａ１またはサーバ・アプリケーション２１０Ａの実ＤＢ２４４のテーブル群Ａへのアクセスａ２を抑止する。すなわち、これによりサーバ・アプリケーション２１０Ａの処理を停止させる。これにより、データベースサーバ２００の負荷が軽減される。
【０１６９】
この場合にも、上記アクセスａ１及びアクセスａ２の抑止は、上述したアクセス時間帯の制御のときと同様にして行う。また、この場合においても、アクセスａ２の抑止のみを行い、クライアント・マシン１１０−１に対してはサービスを停止させずに、負荷を抑えることが可能である。これは、サーバ・アプリケーション２１０Ａの負荷が高い場合に有効である。
【０１７０】
３．優先度制御
この制御においても、各公開サービスに重要度を設定しておく。そして、重要度の低い業務処理の動作を一時的に停止させ、より重要度の高い業務処理を優先的に動作させる制御を行う。
【０１７１】
すなわち、例えば図１６に示す例において、公開サービスＡの方が公開サービスＢよりも重要度が低い場合、上記アクセスａ１またはアクセスａ２を抑止させて、サーバ・アプリケーション２１０Ａの処理を停止させる。これにより、サーバ・アプリケーション２１０Ｂの処理能力が高まり、この結果としてクライアント・マシン１１０−１に対する公開サービスＢが優先的に実行される。すなわち、公開サービスＢの優先度を上げた運用が可能になる。
【０１７２】
この場合においても、上記アクセスａ１及びアクセスａ２の抑止は、上述したアクセス時間帯及び過負荷制御のときと同様にして行うことができる。この場合においても、アクセスａ２の抑止のみを行った場合、クライアント・マシン１１０−１側に対しては公開サービスを停止させるようにすることができる。
【０１７３】
図１７は、上述したアクセス時間帯、過負荷制御、及び優先度制御を実現する通信ＤＢ制御機構２２０の動作を説明するフローチャートである。
この場合、通信ＤＢ２２１のサービス閉塞機能は、当該公開サービスに対応する入力テーブル３０３Ｉへのデータの格納（格納サービス）の禁止を意味する。また、サーバ・アプリケーション２１０の実行環境の停止は、サーバ・アプリケーション２１０が停止状態にあることを意味する。
【０１７４】
同図において、メッセージキュー制御部２２５は、入力テーブル３０３Ｉへのデータ格納要求待ちにあるときに、クライアント・アプリケーション１１０からデータの格納要求を受信すると（Ｓ５１）、メッセージキュー制御部２２５はその入力テーブル３０３Ｉの現在の格納サービス状態をチェックする（Ｓ５２）。そして、該格納サービスが閉塞状態にあれば、上記クライアント・アプリケーション１１０に対して“格納失敗”のエラーメッセージを、通信手順制御部２０１を介して通知する（Ｓ５２，格納不可）。
【０１７５】
すなわち、この場合、前記図１７に示す例の場合、クライアント・マシン１１０−１からの公開サービスＡに対するアクセスａ１が抑止される。
一方、上記ステップＳ５２で閉塞状態でなければ（Ｓ５２，格納可）、要求のあった格納データを入力テーブル３０３Ｉへキューイングし（Ｓ５３）、該キューイング完了時点で、データ格納要求が完了した旨の応答メッセージをクライアント・アプリケーション１１０に通知する（Ｓ５４）。
【０１７６】
続いて、上記当該入力テーブル３０３Ｉに対応するサーバ・アプリケーション２１０の状態をチェックして（Ｓ５５）、該サーバ・アプリケーション２１０が現在、停止中ならば上記ステップＳ５１に戻り、次のデータ格納要求待ちとなる。
【０１７７】
すなわち、サーバ・アプリケーション２１０の実行環境が停止中であれば、クライアント・アプリケーション１１０からのサービス要求に対してサーバ・アプリケーション２１０の実ＤＢ２４４に対するアクセスが停止される。
【０１７８】
一方、上記ステップＳ５５で上記サーバ・アプリケーション２１０が処理待ち状態にあれば、アプリ起動要求制御部２２９を介してアプリ実行制御部２４１に上記サーバ・アプリケーション２１０の起動要求を行う（Ｓ５６）。
【０１７９】
該起動要求後は、前述した図１６に示すときと同様にして、上記サーバ・アプリケーション２１０が実行される。
図２に示すように、本実施例では通信ＤＢ制御機構２２０内に、２つのコード変換／属性変換部２２３Ｃ，２２３Ｓを設けている。そして、さらに、これらの変換部２２３Ｃ，２２３Ｓの間に通信ＤＢ２２１を設けている。通信ＤＢ２２１内にはクライアント・アプリケーション１１０とサーバ・アプリケーション２１０間のメッセージ（データ）の授受に使用される入力テーブル３５１，３５３，応答テーブル３５２が生成されるが、キューとして機能するこれらのテーブルに格納されるデータの各項目の型式（属性）は通信ＤＢ２２１に登録されているテーブル定義情報３０３（入力テーブル定義情報３０３Ｉ、応答テーブル定義情報３０３Ｒ）に項目属性として定義されている。
【０１８０】
図１８は、本実施例が上記構成によって実現しているクライアント・アプリケーション１１０とサーバ・アプリケーション２１０間で授受されるデータの項目属性変換機構を示す模式図である。
【０１８１】
コード変換／属性変換部２２３Ｃは、クライアント・アプリケーション１１０が送受信するデータの各項目に対して、以下のような属性変換処理を行う。
［１］ 通信ＤＢ２２１へのデータ挿入時
クライアント・アプリケーション１１０から送信されてくるデータの各項目をテーブル定義情報によって定義されている属性に変換・出力する。
【０１８２】
［２］ 通信ＤＢ２２１からのデータ取り出し時
サーバ・アプリケーション２１０が通信ＤＢ２２１へ挿入したデータ（応答テーブル３５２または入力テーブル３５３に挿入したデータ）の各項目をクライアント・アプリケーション１１０により要求される項目属性に変換・出力する。
【０１８３】
一方、コード変換／属性変換部２２３Ｓは、サーバ・アプリケーション２１０が送受信するデータの各項目に対して以下のような項目属性変換処理をする。
［３］ 通信ＤＢ２２１からのデータ取り出し時
通信ＤＢ２２１（入力テーブル３５１）から取り出したデータの各項目の属性を、サーバ・アプリケーション２１０から要求される属性に変換・出力する。
【０１８４】
［４］ 通信ＤＢ２２１へのデータ挿入時
サーバ・アプリケーション２１０から送信されてくるデータの各項目の属性を、通信ＤＢ２２１のテーブル定義情報３０３に定義されている属性に変換・出力する。
【０１８５】
次に、上述した［１］〜［４］の属性変換処理を、図１９乃至図２２のフローチャートにより、個々に説明する。
図１９は、コード変換／属性変換部２２３Ｃが実行する上記［１］の属性変換処理を説明するフローチャートである。
【０１８６】
コード変換／属性変換部２２３Ｃは、クライアント・アプリケーション１１０が依頼してきた通信ＤＢ２２１（入力テーブル３５１）への挿入データをＳＱＬ解析制御部２２２Ｃから受け取ると（Ｓ１１１）、通信ＤＢ２２１内の上記入力テーブル３５１の定義情報３０３Ｉに定義されている項目属性情報と上記受信データの各項目の属性とを比較し（Ｓ１１２）、属性が一致しない項目があれば（Ｓ１１２，不一致）、該項目を入力テーブル定義情報３０３Ｉに定義されている属性に変換する（Ｓ１１３）。
【０１８７】
一方、上記ステップＳ１１２で、受信データの全項目の属性が入力テーブル定義情報３０３Ｉに定義されている属性と一致すれば（Ｓ１１２，一致）、該受信データの属性変換は行わない。
【０１８８】
次に、図２０は、コード変換／属性変換部２２３Ｓが実行する上記［３］の属性変換処理を説明するフローチャートである。
コード変換／属性変換部２２３Ｓは、入力テーブル３５１からクライアント・アプリケーション１１０により挿入されたサーバ・アプリケーション２１０宛のデータを取り出すと（Ｓ１２１）、該入力テーブル３５１の定義情報３０３Ｉを参照して、上記取り出したデータの各項目の属性を、サーバ・アプリケーション２１０から依頼された属性と比較する（Ｓ１２２）。
【０１８９】
そして、上記取り出したデータの項目の中に、サーバ・アプリケーション２１０から依頼された属性と一致しないものがあれば（Ｓ１２２，不一致）該項目をサーバ・アプリケーション２１０により依頼された属性に変換する（Ｓ１２３）。
【０１９０】
そして、該変換後のデータをサーバ・アプリケーション２１０に送信する（Ｓ１２４）。一方、上記ステップＳ１２２で上記取り出したデータの全項目の属性がサーバ・アプリケーション２１０から依頼された属性と一致しているならば（Ｓ１２２，一致）、直ちに上記ステップＳ１２４の処理を実行する。
【０１９１】
上述した図１９及び図２０のフローチャートに示す属性変換処理により、クライアント・アプリケーション１１０がサーバ・アプリケーション２１０へデータを送信する際、それぞれのアプリケーション１１０，２１０はそれぞれの処理に適した属性でデータ処理が行える。
【０１９２】
次に、図２１は、コード変換／属性変換部２２３Ｓが実行する上記［４］の属性変換処理を説明するフローチャートである。
コード変換／属性変換部２２３Ｓは、サーバ・アプリケーション２１０がＳＱＬ文（ＩＮＳＥＲＴ）により依頼する通信ＤＢ２２１（応答テーブル３５２または入力テーブル３５３）に挿入するデータを受信すると（Ｓ１３１）、通信ＤＢ２２１に登録されている上記テーブル３５２または３５３の定義情報３０３Ｒまたは３０３Ｉを参照して、該受信したデータの全項目の属性が上記定義情報３０３Ｒまたは３０３Ｉに定義されている属性と一致しているか否か比較する（Ｓ１３２）。
【０１９３】
そして、属性が一致していない項目があれば（Ｓ１３２，不一致）、該項目を上記定義情報３０３Ｒまたは３０３Ｉで定義されている属性に変換する（Ｓ１３３）。
【０１９４】
一方、上記ステップＳ１３２で、受信データの全項目がテーブル定義情報３０３Ｒまたは３０３Ｉで定義されている属性と一致すれば（Ｓ１３２，一致）、上記受信データについて項目の属性変換は行わない。
【０１９５】
次に、図２２は、コード変換／属性変換部２２３Ｃが実行する上記［２］の項目属性変換処理を説明するフローチャートである。
コード変換／属性変換部２２３Ｃは、通信ＤＢ２２１（応答テーブル３５２または入力テーブル３５３）からクライアント・アプリケーション宛のデータ（サーバ・アプリケーション２１０からの送信データ）を取り出すと（Ｓ１４１）、上記応答テーブル３５２または入力テーブルの定義情報（３０３Ｒまたは３０３Ｉ）を参照して、上記取り出したデータの全項目の属性がクライアント・アプリケーション１１０から依頼された属性に一致しているか否か比較する（Ｓ１４２）。
【０１９６】
そして、属性が一致しない項目があれば（Ｓ１４２，不一致）、該項目をクライアント・アプリケーション１１０により依頼された属性に変換し（Ｓ１４３）、変換後のデータを通信手順制御部２０１を介してクライアント・アプリケーション１１０に送信する（Ｓ１４４）。
【０１９７】
一方、上記ステップＳ１４２で上記取り出したデータの全項目の属性がクライアント・アプリケーション１１０から依頼された属性に一致する場合には（Ｓ１４２，一致）直ちに上記ステップＳ１４４の処理を実行する。
【０１９８】
上述した、図２１及び図２２の項目属性変換処理により、サーバ・アプリケーション２１０からクライアント・アプリケーション１１０へデータを送信する場合にも、両アプリケーション２１０，１１０は、それぞれが処理しやすい属性でデータ処理が行える。
【０１９９】
このように、本実施例では、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０に対し、遣り取りするデータ項目属性を規定させない。このことにより、例えば数値の遣り取りに対し、クライアント・マシン１００とデータベースサーバ２００でのアプリケーションで属性が不一致の場合でも遣り取りが可能となる。例えば、数値属性としてＤＥＣＩＭＡＬ属性を使用したサーバ・アプリケーション２１０と数値属性としてＩＮＴＥＧＥＲ属性しかないクライアント・アプリケーション１１０間でのデータの遣り取りが可能となる。
【０２００】
そして、これにより、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０は、処理するデータの各項目の属性をそれぞれの処理に適した型に決定できる。
【０２０１】
図２３は、現在、実行環境＃１で動作しているサーバ・アプリケーションＡをサーバ・アプリケーション名を変更せずに、新しい実行環境＃２で動作させて、新しい業務処理を構築できることを説明する図である。
【０２０２】
本実施例においては、サーバ・アプリケーション２１０の実行環境は通信ＤＢ２２１単位で存在する。これは、通信ＤＢ２２１のサービス定義情報３０１によって、公開サービスと該公開サービスで提供されるデータ処理を実行するサーバ・アプリケーション２１０とが対応付けられているからである。また、クライアント・アプリケーション１１０が通信ＤＢ２２１を使用する（アクセスする）場合、該使用開始はＣＯＮＮＥＣＴ命令で宣言する。一方、使用終了は、ＤＩＳＣＯＮＮＥＣＴ命令で宣言する。このように、ＣＯＮＮＥＣＴ命令の発行により、クライアント・アプリケーション１１０に対して通信ＤＢ２２１がアロケーションされる。
【０２０３】
このような機構となっているため、本実施例では、同一のサーバ・アプリケーション２１０を、複数の実行環境で動作させることが可能である。すなわち、複数の通信ＤＢ２２１の公開サービス情報３０１に同一名で同一のサーバ・アプリケーション２１０を登録できる。
【０２０４】
このため、図２３に示すように、異なる実行環境＃１，＃２で同一のサーバ・アプリケーション２１０を同一名称のまま動作させることが可能になる。すなわち、サーバ・アプリケーションＡを流用して新たな業務処理を構築する際に、該サーバ・アプリケーションＡを別名称にすることなく、同一の名称のまま使用することができる。
【０２０５】
図２４は、クライアント・アプリケーション１１０−１（＃１）が公開サービスＡを使用した業務を行い、クライアント・アプリケーション１１０−２（＃２）が公開サービスＡとＢを使用した業務を処理する場合、クライアント・アプリケーション１１０−１（＃１）とクライアント・アプリケーション１１０−２（＃２）とは共にサーバ・アプリケーションＡに対して通信することが可能なことを示した。
【０２０６】
また、本実施例では、通信ＤＢ制御機構２２０を用いて、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０の動作試験を、それぞれ単独で行うことが可能である。
【０２０７】
すなわち、サーバ・アプリケーション２１０に対しては、通信ＤＢ制御機構２２０をドライバの代替として機能させ、クライアント・アプリケーション１１０に対してはスタブの代替として機能させる。
【０２０８】
クライアント・アプリケーション１１０の動作試験
［１］ クライアント・アプリケーション１１０は、ＳＱＬプログラミング（ＩＮＳＥＲＴ）により通信ＤＢ制御機構２２０の入力テーブル３５１にデータを書き込む。
【０２０９】
［２］ 該データ書き込み後、上記入力テーブル３５１の内容を確認する。
サーバ・アプリケーション２１０の動作試験
［１］ 通信ＤＢ制御機構２００の入力テーブル３５１に予めデータを登録する。
【０２１０】
［２］ サーバ・アプリケーション２１０からＳＱＬ命令（ＳＥＬＥＣＴ）を通信ＤＢ制御機構２００に送信して、上記入力テーブル３５１からデータを取り出し、該データを確認する。
【０２１１】
また、本実施例では、通信ＤＢ制御機構２００に対するアクセスは、一般的なＳＱＬプログラミングの発行と類似した方式で行えるため、市販の表計算ソフトやＤＢアクセスソフト（データベース・アクセス）ソフトを、容易にクライアント・アプリケーション１１０として活用させることができる。
【０２１２】
【発明の効果】
以上、説明したように本発明によれば、以下のような効果が得られる。
クライアント・アプリケーションとサーバ・アプリケーションは、当該公開サービス情報によってその形式が定義されているテーブル（以後、公開テーブルと記述する）に対して、該定義に沿ったデータを挿入または取り出すことによりデータ（メッセージ）の授受を行う。このため、クライアント・アプリケーションとサーバ・アプリケーションの開発は、該公開サービス情報のみを意識して行えばよく、互いに独立して行うことができる。 このため、例えば、公開テーブルのレコードを、データベース・サーバ上の１または複数のデータベース（以後、実データベースと記述する）の１または複数のテーブルの各レコードに属する項目で構成することにより、以下のような効果が得られる。
【０２１３】
クライアント・アプリケーションの作成は、実データベース上に構築されているテーブル（以後、実テーブルと記述する）の形式を意識することなく、当該公開テーブルに対するアクセスのみを意識して行えばよい。そして、サーバ・アプリケーションは、該公開テーブルから取り出すデータを基に、データベースに対するアクセスを行う。
【０２１４】
従って、データベースの構造の変更は、サーバ・アプリケーションのみの修正により対処でき、クライアント・アプリケーションの修正は不要である。
このため、データベースの管理者は、クライアント・アプリケーションを意識することなく、実データベースの構造を変更できる。
【０２１５】
また、利用者に公開する公開テーブルと管理者が管理する実データベース上の実テーブルとを、別々に設計できる。このため、両テーブルを、利用者側、管理者側それぞれにとって最適な形式に設計できる。また、各々のテーブルの設計者を分離することも可能となるので、テーブル設計の負担が軽減される。また、テーブル情報の保全も、それぞれのテーブル設計者が個別に管理できるので、管理も分担可能である。
【０２１６】
公開テーブル単位で利用者のアクセス権を設定することにより、アクセス権の設定が容易になる。すなわち、利用者のデータベースアクセス単位は、公開テーブル単位なので、管理者は、該公開テーブル単位で利用者にアクセス権を設定するだけでよい。また、業務管理者に対するデータベース・サーバ上の実データベースのアクセス権は、利用者とは別個に設定・管理できる。
【０２１７】
クライアント・アプリケーションの１回の公開テーブルへのアクセスで、サーバ・アプリケーションが実データベース上の複数の実テーブルをアクセスすることが可能となるので、クライアント・アプリケーションとサーバ・アプリケーション間でのネットワーク上のトラフィック量が軽減されると共に、業務処理も高速に行えるようになる。
【０２１８】
また、公開サービスの停止や、サーバ・アプリケーションの停止をデータベース・サーバ管理者が制御することが可能になるので、アクセス時間の制限、過負荷制御、業務処理毎の優先度制御などの運用ルールを利用者に委ねることなく、該管理者の裁量で行うことが可能になる。
【０２１９】
リアル通信／ディレイド通信などのデータ処理形態に係わる機能ロジックを、アプリケーション（クライアント・アプリケーションとサーバ・アプリケーション）側に組み込む必要がなくなるので、クライアント・アプリケーションとサーバ・アプリケーション間のインタフェースは互いに通信するデータの形式のみとなり、両アプリケーション間の独立化が図れる。このため、両アプリケーションの生産性が向上する。
【０２２０】
クライアント・アプリケーションとサーバ・アプリケーションのいずれにも、互いに通信するデータの属性変換処理ロジックを組み込む必要がなくなるので、両アプリケーションの生産性が向上する。
【０２２１】
また、本発明をサーバ・アプリケーションに対してはドライバの代替、クライアント・アプリケーションに対してはスタブの代替として機能させることにより、両アプリケーションが揃わなくても、互いに独立に動作試験を行うことができる。
【０２２２】
また、既存の表計算ソフトやデータベースアクセスソフトなどの市販の業務パッケージを、容易にクライアント・アプリケーションとして活用することができる。
【０２２３】
さらに、同一のサーバ・アプリケーションをその名称を変更させずに新しい実行環境で動作させることが可能になるので、既存のサーバ・アプリケーションを新たな業務処理に利用する場合、その構築が容易であり、該サーバ・アプリケーションの修正時のメンテナンスも容易となる。
【図面の簡単な説明】
【図１】 本発明の原理説明図である。
【図２】 本発明の実施例のシステム構成図である。
【図３】 通信データの内部構成を説明する図である。
【図４】 サービス定義情報に設定されるデータ処理形態の動作を説明する模式図である。
【図５】 入力テーブルの構成を説明する図である。
【図６】 通信バッファにキューイングされるデータの形式を説明する図である。
【図７】 データ処理形態応答型の命令とデータの流れとキューイングを説明する図である。
【図８】 応答型（リアル通信）による業務処理の一具体例を示す図である。
【図９】 集信型の業務処理の一例を説明する模式図である。
【図１０】 データベースの更新を説明する図である。
【図１１】 データベースサーバ上のデータベース構造を変更したときの対処方法を説明する図である。
【図１２】 通信データベースに設定されるセキュリティ情報を説明する図である。
【図１３】 通信データベースに接続要求があったときのセキュリティ・チェック処理を説明するフローチャートである。
【図１４】 通信データベースで定義されているテーブルにアクセス要求があったときのセキュリテ ィ・チェック処理を説明する図である。
【図１５】 通信データベース・アクセス処理及び実データベース・アクセス処理を説明するフローチャートである。
【図１６】 過負荷制御の方法を説明する図である。
【図１７】 アクセス時間帯、過負荷制御、及び優先度制御を実現する通信ＤＢ制御機構の動作を説明するフローチャートである。
【図１８】 項目属性変換機構を示す模式図である。
【図１９】 クライアント・アプリケーションからテーブル挿入要求を受信したときの項目属性変換処理を説明するフローチャートである。
【図２０】 サーバ・アプリケーションからテーブルにキューイングされているデータの取り出し要求があったときの項目属性変換処理を説明するフローチャートである。
【図２１】 サーバ・アプリケーションからテーブルへのデータ挿入要求を受信したときの項目属性変換処理を説明するフローチャートである。
【図２２】 クライアント・アプリケーションからテーブルにキューイングされているデータの取り出し要求を受信したときの動作を説明するフローチャートである。
【図２３】 新しい実行環境でクライアント・サーバ関係を構築するとき説明図である。
【図２４】 サーバ・アプリケーションの使い分の他の例を示す図である。
【図２５】 従来のＲＤＡによりデータベース・アクセスを行うクライアント／サーバ・データベースシステムの問題点を説明する図（その１）である。
【図２６】 従来のＲＤＡによりデータベース・アクセスを行うクライアント／サーバ・データベースシステムの問題点を説明する図（その２）である。
【図２７】 従来のＲＤＡによりデータベース・アクセスを行うクライアント／サーバ・データベースシステムの問題点を説明する図（その３）である。
【図２８】 従来のＣ／Ｓアプリ型のデータベースシステムにおける、アプリケーションの動作試験時の問題点を説明する図である。
【図２９】 従来のＣ／Ｓアプリ型のデータベースシステムにおいて、既存のサーバ・アプリケーションを流用して新たな業務処理を開発する場合に発生する問題点を説明する図である。
【符号の説明】
５２ クライアント・アプリケーション
６２ サーバ・アプリケーション
２００ データベースサーバ
２０１ 通信手順制御部
２０２ 利用者認証部
２２０ 通信ＤＢ制御機構（通信制御装置）
２２１ 通信ＤＢ（通信データベース）
２２２Ｃ、２２２Ｓ ＳＱＬ解析制御部
２２３Ｃ、２２３Ｓ コード／属性変換部
２２４ 資源利用認証部
２２５ メッセージキュー制御部
２２６ 通信バッファ
２２８ メッセージ保証制御部
２２９ アプリ起動要求制御部
３０１ サービス定義情報（公開サービス情報）
３０３Ｉ 入力テーブル定義情報
３０３Ｒ 応答テーブル定義情報
３５１、３５３ 入力テーブル
３５２ 応答テーブル
４００ メモリ
４１０ キューノード
４１１ キュー先頭ポインタ
４１２ キュー最終ポンタ
４１３ テーブル情報
５００ セル
５０１ チェイン部
５０２ データ部
【産業上の利用分野】
本発明は、クライアント／サーバシステムに係り、特にフロントエンド処理用のアプリケーション（クライアント・アプリケーション）をクライアント・マシン側にバックエンド処理用のアプリケーション（サーバ・アプリケーション）をサーバ・マシン側に実装する形態のクライアント／サーバシステムで両アプリケーション間のメッセージの授受を制御する通信制御装置に関する。
【０００２】
【従来の技術】
企業の情報システムでパソコンＬＡＮが定着すると共に、クライアント／サーバシステム、特にクライアント／サーバ型のデータベースシステムへの関心が高まっている。
【０００３】
クライアント／サーバ型データベースシステムは、ホスト集中型のデータベースシステムに比べて数々のメリットが得られる。すなわち、マルチベンダ環境でデータベースアプリケーションが実現できる。サーバ側とクライアント側で処理を分担できるので、パフォーマンスが高い。エンド・ユーザが４ＧＬ（第４世代言語）を用いて容易に業務に適したアプリケーションを開発できる。ユーザは、ミドルウェアを利用することにより表計算などの流通ソフト（パッケージ・ソフトウェア）を用いてデータベース・サーバから受け取った結果を好みに合わせて加工できる。分散型データベースを構築することにより、データの分散化が可能となり、またミラーリング機能によりシステム・ダウン時の損失を最小限に抑えることができる。クライアント・マシンとして低価格なパーソナル・コンピュータ（パソコン）を利用できるので、システムを低コストで構築できるなどである。また、クライアント・マシンとしてのパソコンを基幹業務と連携させて利用していくことにより業務の効率化がはかれる。
【０００４】
クライアント／サーバ型データベースシステムにおいて、クライアント・マシン上に実装されたクライアント・アプリケーションがデータベース・サーバマシン（以後、データベース・サーバと記述）のデータベースをアクセスする形態に、ＲＤＡ（リモート・データベース・アクセス：Remote Data Base Access ）とＲＰＣ（リモート・プロセジャ・コール：Remote Procedure Call)がある。
【０００５】
ＲＤＡは、ＩＳＯ（国際標準化機構）が定めたリモート・データベース・アクセスの標準プロトコルであるＲＤＡプロトコルを用いてクライアント・アプリケーションがデータベースをアクセスするものである。この場合、データベース・サーバ側に、クライアント・アプリケーションがネットワークを介して送信してくるＳＱＬ文を直接、ＤＢＭＳ（データベース管理システム）に渡し、該ＤＢＭＳからの結果を、クライアント・アプリケーションに返すミドルウェア（以後、ＲＤＡサーバと呼ぶ）を設ける。このため、クライアント・アプリケーションの開発者は、データベース・サーバ上のデータベースの構成を直接知っている必要がある。
【０００６】
一方、ＲＰＣはクライアント・アプリケーションがデータベース・サーバ上に実装されたサーバ・アプリケーションを、あたかもサブルーチンのようにネットワークを介して呼び出させて業務処理の一部分（手続き）を実行させ、該サーバアプリケーションからその結果を受け取ることにより分散アプリケーションを実現するものである。ＲＰＣ機能を利用することにより、協調分散処理を容易に実現することができる。協調分散処理とは、１つのトランザクション処理をクライアント・マシンと１または複数台のデータベース・サーバに振り分けて処理するものである。これにより、ＵＮＩＸデータベース・サーバのように比較的小さなマシンでも、複数台のサーバを使って大規模なＯＬＴＰシステム（オンライン・トランザクション処理システム）を構築できる。
【０００７】
【発明が解決しようとする課題】
まず、クライアント・アプリケーションがＲＤＡによりデータベース・サーバをアクセスする形態のＣ／Ｓデータベースシステム（クライアント／サーバ型データベースシステム）の問題点を述べる。
【０００８】
この形態においては、クライアント・アプリケーションの開発者はデータベース・サーバ上のデータベースの構成を知っている必要がある。したがって、該データベースの設計を行うデータベース管理者とクライアント・アプリケーションの開発者は、互いに密接な関係を保ちながらそれぞれの設計・開発を行う必要がある。
【０００９】
また、クライアント・アプリケーションの内容とデータベース構造が互いに影響し合う。このため、データベース管理は、データベース構造を変更する際にも、該変更が現在のクライアント・アプリケーションにどの程度まで影響するかを考慮せねばならず、クライアント・アプリケーションの内容にまで精通していなければならないなどの問題があった。
【００１０】
また、上述したような構成であるが故に、データベースの構造変更（データベースの分離／配置替え等）時には、必然的にクライアント・アプリケーションを修正する必要がある。
【００１１】
図２５は、その一例である。この場合、業務追加等によりデータベースサーバ１のデータベースＤＢ１のテーブル２（ＴＡＢＬＥ１）の項目数が増加し、アクセス性能が劣化したので、同図（Ｂ）に示すように該テーブル２（ＴＡＢＬＥ１）をテーブル３（ＴＡＢＬＥ１−１）とテーブル４（ＴＡＢＬＥ１−２）に分割した。これにより、クライアント・マシン６上のクライアント・アプリケーション７の一部は、同図（Ａ）に示す内容（ＩＮＳＥＲＴ ＴＡＢＬＥ１）から同図（Ｂ）に示す内容（ＩＮＳＥＲＴ ＴＡＢＬＥ１−１，ＩＮＳＥＲＴ ＴＡＢＬＥ１−２）に修正される。このため、該修正作業が新たなコスト増を招く、クライアント・マシンが一時的に使用できなくなる等の弊害をもたらしていた。
【００１２】
また、データベース・サーバの管理者にとっても、利用者の業務に支障をきたさないように、データベースの負荷分散やデータ管理単位に係わる変更作業はクライアント・アプリケーションの変更時と同一期間内に作業する必要があるなど、変更作業が可能な期間が制限されるなどの問題があった。
【００１３】
さらに、データベースのテーブル構成を、直接利用者に公開するため、利用者側でのデータの利用形態とデータベースの管理形態の両局面を考慮してデータベースのテーブル設計をする必要があり、システムを構築する上でテーブル設計が非常に難しいものとなっている。
【００１４】
また、ＲＤＡにおいては、図２６に模式的に示すように、例えば受注処理のような業務を行う場合、クライアント・アプリケーション１１は、顧客チェック、在庫チェック、在庫更新、受注登録などの処理をＳＱＬ文によりデータベース・サーバ２０に対して依頼する。また、各ＳＱＬ文の発行は前回のＳＱＬ文に対する応答をデータベース・サーバ２０から受け取った後に行う。このため該受注処理の間、クライアント・マシン１０とデータベース・サーバ２０との間で、何回もデータの送受信が行われることになる。このため、ネットワークのトラフィック量が増大し、システムの処理性能が落ちる場合がある。
【００１５】
また、さらに、ＲＤＡでは、クライアント・アプリケーションからのＳＱＬ文の依頼がＲＤＡサーバを介して直ちにＤＢＭＳに渡されるので、システム管理者が利用者に対してデータベースの運用ルールとして以下のような［１］〜［４］のルールを定めても、管理者がシステムの運用を監視／コントロールすることは実質的にできなかった。
【００１６】
［１］ アクセス時間に関する制限（大量のデータアクセスの禁止、データアクセス中の離席等の防止など）
［２］ アクセス時間帯の制限（管理者がデータベースのメンテナンス時間を確保するなどのため）
［３］ 過負荷制御（データベース・サーバ過負荷時のアクセス禁止）
［４］ 優先度制御（各業務（サービス）の実行を、その優先度に応じて動的に制御）
また、クライアント・アプリケーションのＲＤＡによるアクセス方法としては、上記ＳＱＬ文単位での処理依頼以外に、予めデータベース・サーバに予め一連のトランザクション処理（プロシジャ）を登録しておいて、このプロシジャを呼び出すことにより、所定のデータベース処理を行う、いわゆるストアド・プロシジャ・コールの方法がある。しかし、現状では、クライアント・アプリケーショが、上記ＳＱＬ文単位でのアクセスとストアド・プロシジャ・コールを使い分けて業務ロジックを作成する必要があるため、業務ロジックが複雑となり、開発の生産性を向上させるのが難しい。
【００１７】
現状のＤＢＭＳのデータベース・アクセスに対するセキュリティ機能は、テーブル単位及び列（項目）単位である。このため、利用者に対して項目単位にデータ公開を行う場合、アクセス権限の設定が図２７に示すように煩雑となる。また、業務システムを構築する場合、利用者の資格（エンドユーザ、業務管理者）毎にデータベースのアクセス権を変えることが一般的である。このため、例えば、同一利用者がエンドユーザにも業務管理者にもなる場合、該利用者に対して項目毎に当該権限を変えなければならないが、セキュリティ定義者は、同一利用者という観点から、全項目について同一権限を与えてしまう恐れがある。
【００１８】
次に、アプリケーションをユーザ・インタフェース用の入出力処理を担当するクライアント・アプリケーションとデータベース・アクセスに係わる業務ロジックを実行するサーバ・アプリケーションの２つに分け、それぞれをクライアント・マシンとデータベース・サーバに実装して、クライアント・アプリケーションがサーバ・アプリケーションを、ＲＰＣ等によりコール（ＣＡＬＬ）しながら業務処理を実行して行く形態のデータベースシステム（以下、便宜上、Ｃ／Ｓアプリ型データベースシステムと記述する）は、以下のような問題点をかかえている。
【００１９】
この場合、アプリケーション開発においては、上記両アプリケーション間で授受するデータの形式のみならず、サーバ・アプリケーションの処理時間やサーバ・アプリケーションの運用時間帯などに対応する処理形態についても配慮する必要がある。
【００２０】
上記処理形態としては、例えば、リアル通信、ディレイド通信がある。リアル通信においては、サーバ・アプリケーションがクライアント・アプリケーションから依頼された処理を終了した時点で、クライアント・アプリケーションに処理完了が通知される。
【００２１】
一方、ディレイド通信においては、サーバ・アプリケーションの処理完了を待たずにクライアント・アプリケーションからメッセージ（データ）を受信・保持した時点で、クライアント・アプリケーションに完了を通知する。
【００２２】
したがって、例えば、クライアント・アプリケーションがサーバ・アプリケーションに対して一方的にデータを集信する形態の集信型処理を、リアル通信で処理していた場合、サーバ・アプリケーションの処理時間が非常に長くなると、クライアント・アプリケーションに対する応答時間が遅延する。このような場合には、上記集信型処理を“リアル通信”から“ディレイド通信”に変更する必要がある。したがって、両アプリケーションの開発は、互いに密接な関係を持ち、両者を独立に開発することは難しい。また、上記処理形態の変更がアプリケーションのロジックに影響を及ぼすので、両アプリケーションの変更が必要となる場合が多く、生産性が低い。
【００２３】
クライアント・アプリケーションは、ユーザ・インタフェースに係わる処理を取り扱うので、処理するデータの属性（型式）は画面処理に適したものが望ましい。一方、サーバ・アプリケーションは、データベース・アクセスやそのアクセスにより得られたデータの加工などを行うので、このような処理に適した属性のデータで処理するのが好ましい。このため、クライアント・アプリケーションとサーバ・アプリケーション間でデータの授受を行う場合、いずれかのアプリケーション側でデータの属性変換処理が必要となる。これは、アプリケーション開発において作業量の負担をもたらし、アプリケーションの生産性を低下させる。
【００２４】
また、開発時のアプリケーションの動作試験は、図２８（Ａ）のようにクライアント・アプリケーション３１とサーバ・アプリケーション３２の両方が揃わないと行えない。また、ＲＰＣのテストにおいては、同図（Ｂ），（Ｃ）にそれぞれ示すようにドライバ３６やスタブ３７を作らないといけない。
【００２５】
すなわち、サーバ・アプリケーション３２を単独でテストしたい場合には、クライアント・アプリケーション３１に代わって該サーバ・アプリケーション３２に対して要求を発行するドライバを作成する必要がある（図２８（Ｂ）。一方、クライアント・アプリケーション３１を単独でテストしたい場合には、サーバ・アプリケーション３２に代わってクライアント・アプリケーション３１からの要求を受け取るスタブ３７を作成する必要がある（図２８（Ｃ））。
【００２６】
一方、独自のテスト支援ツールを使用してもよいが、この場合、その操作方法などに関する知識を習得する必要がある。
また、一般にクライアント・アプリケーションとサーバ・アプリケーションはＴＰモニタを介して連携させる形態をとるため、ＴＰモニタのＡＰＩ（アプリケーション・プログラミング・インタフェース）に従って作成する必要がある。このため、ＰＣ（パソコン）上に実装された市販パッケージ・ソフトの表ソフトやデータベース・アクセスソフトなどをクライアント・アプリケーションとして使用して、ＲＰＣ対応のＣ／Ｓアプリ型データベースシステムを構築することは、現状では不可能となっている。
【００２７】
さらに、現状のＣ／Ｓアプリ型のデータベースシステムでは、クライアント・アプリケーションがＲＰＣにより指定するサーバ・アプリケーションはデータベース・サーバ上で同一の実行環境でしか動作できない。換言すれば、同一のサーバ・アプリケーションは１つの業務処理でしか使用できないようになっている。このため、既存のサーバ・アプリケーションを新たな業務処理に流用しようとした場合、該サーバ・アプリケーションを複数の実行環境で動作可能とするために、その名称を変更する必要がある。このため、該名称の変更に伴う各種作業が必要となってくる。
【００２８】
すなわち、例えば、図２９に示すように、現在運用中のシステムにおいて、クライアント・アプリケーション４１がサーバ・アプリケーションＡをコール（ＣＡＬＬ）形態のある業務処理が稼働しているものとする。この後、業務拡張のため同図に示すように、サーバ・アプリケーションＡを流用して新たな業務処理を構築するために新規にクライアント・アプリケーション４２を開発する場合（［１］）、該新たな業務処理は別実行環境となるため、上記サーバ・アプリケーションＡを別名称のサーバ・アプリケーションＡ′で管理する必要がある（［２］）。ところが、このようにすると、障害発生等によりサーバ・アプリケーションＡを修正する保守作業を行う場合、サーバ・アプリケーションＡのみならずサーバ・アプリケーションＡ′についても保守作業を行わねばならなない（［３］）。すなわち、同一のサーバ・アプリケーションＡを二重管理しなければならないため、保守作業の負担が増大する。
【００２９】
【発明が解決しようとする課題】
本発明は、上述のような問題点に鑑みなされたもので、その目的は、以下のようなものである。
【００３０】
(1) クライアント・アプリケーションとサーバ・アプリケーションの開発・変更等の作業を互いに独立して進めることができるようにする。
(2) クライアント／サーバ方式のデータベースシステムにおいて、クライアント・アプリケーションを修正することなくデータベースの構造を変更することを可能とする。また、管理者は、クライアント・アプリケーションの内容を意識することなく、データベースの構造を変更できる。
【００３１】
(3) クライアント／サーバ方式のデータベースシステムにおいて、利用者側に公開するテーブルとデータベース・サーバ上のデータベースのテーブルを別々に設計可能とする。
【００３２】
(4) クライアント／サーバ方式のデータベースシステムにおいて、データベースのセキュリティ管理を容易なものとする。
(5) クライアント・アプリケーションとサーバ・アプリケーション間でのネットワークのトラフィック量を減少させると共に、業務処理の高速化を可能とする。
【００３３】
(6) 運用ルールを利用者に委ねなくても、管理者の裁量でデータベース・サーバを監視・制御できるようにする。
(7) クライアント・アプリケーションとサーバ・アプリケーションにリアル通信、ディレイド通信などのデータの処理形態を実現する機能を組み込まなくても、該データ処理形態を実現できるようにする。
【００３４】
(8) クライアント・アプリケーションとサーバ・アプリケーションがデータの送受信をする際に、いずれのアプリケーションにも該データ属性変換処理を組み込むことを不要にする。
【００３５】
(9) クライアント・アプリケーションとサーバ・アプリケーションの動作試験を、それぞれ独立に行えるようにする。
(10)既存の表計算ソフトやデータベース・アクセスソフト（ＤＢアクセスソフト）をクライアント・アプリケーションとして、クライアント／サーバデータベースシステムを構築できるようにする。
【００３６】
(11)同一のサーバ・アプリケーションを名称を変更することなく新たな業務処理に流用できるようにする。
【００３７】
【課題を解決するための手段】
図１は、本発明の原理説明図である。
以下に述べる請求項１〜４記載の発明は、業務処理をクライアント・アプリケーション５２とサーバ・アプリケーション６２によって実行するクライアント／サーバシステムの該クライアント・アプリケーション５２と該サーバ・アプリケーション６２間の情報の授受を制御する通信制御装置を前提とする。
【００３８】
請求項１記載の発明は、少なくともデータ処理形態とテーブル定義情報とを含む公開サービス情報（図２の公開サービス情報３００）を管理する公開サービス情報記憶手段（図２の通信データベース２２１）と、前記テーブル定義情報に基づいて入力テーブル（図５の入力テーブル３５１）を作成するテーブル作成手段（図２のメッセージキュー制御部２２５）と、前記クライアント・アプリケーション（図２のクライアント・アプリケーション１１０）からのＳＱＬを解析してデータを前記入力テーブルに格納する第一のＳＱＬ解析制御部（図２のＳＱＬ制御部２２２Ｃ）と、前記サーバ・アプリケーションからのＳＱＬを解析して前記入力テーブルからデータを取り出す第二のＳＱＬ解析制御部（図２のＳＱＬ制御部２２２Ｓ）と、前記入力テーブルにデータを格納した際に、前記サービス定義情報内のデータ処理形態が第一の処理形態（リアル通信）の場合には、前記サーバ・アプリケーションからの完了通知を待って前記クライアント・アプリケーション５２に対して完了通知を行い、前記サービス定義情報内のデータ処理形態が第二の処理形態（ディレイド通信）の場合には、前記サーバ・アプリケーション６２からの完了通知を待つことなく前記クライアント・アプリケーション５２に対して完了通知を行うメッセージ応答制御部 （図２のメッセージ応答制御部２２８）とを有する。
【００３９】
請求項２記載の発明は、請求項１記載の通信制御装置において、前記入力テーブルにデータが格納された際に前記サーバ・アプリケーションの状態を確認し、前記サーバ・アプリケーションが処理待状態である場合のみ、前記サーバ・アプリケーションに対して起動要求を行うサーバ・アプリケーション起動要求手段（図２のアプリ起動要求制御部２２９）を、更に備える。
【００４０】
請求項３記載の発明は、請求項２記載の通信制御装置において、前記公開サービス情報記憶手段は、公開情報として更に、前記テーブル定義情報で定義されるテーブルの各項目の第一の属性情報を記憶する。そして、前記入力テーブルに入力されるデータを前記第一の属性情報に従って変換して格納する第一の変換手段（コード変換／属性変換部２２３Ｃ）を、更に有する。
【００４１】
請求項４記載の発明は、請求項３記載の通信制御装置において、前記公開サービス情報記憶手段は、公開情報として更に、前記テーブル定義情報内で定義されるテーブルの各項目の第二の属性情報を記憶する。そして、前記入力テーブルから取り出されるデータを前記第二の属性情報に従って変換する第二の変換手段（コード変換／属性変換部２２３Ｓ）を、更に有する。
【００４２】
【作用】
請求項１記載の発明によれば、公開サービス情報を参照することにより、クライアント・アプリケーション５２とサーバ・アプリケーション６２の開発・変更作業を、互いに独立して進めることができる。また、クライアント・アプリケーション５２は公開サービス情報で提供される仕様に沿っていればよいので、データベースサーバ（図２のデータベースサーバ２００）上のデータベース（図２のデータベース６３）の構造を変更する際、クライアント・アプリケーション５２の修正が不要となる。管理者も、クライアント・アプリケーション５２の内容を意識することなく、データベースを変更できる。
【００４３】
また、さらに、クライアント・アプリケーション５２に公開する入力テーブルと、データベースサーバ（図２のデータベースサーバ２００）の管理するデータベースのテーブルを、別々に設計できる。
【００４４】
また、さらに、クライアント・ アプリケーション５２とサーバ・アプリケーション６２にリアル通信、ディレイド通信などのデータ処理形態を実現する機構を組み込まなくても、それらのデータ処理形態を実現できる。
【００４５】
請求項２記載の発明によれば、管理者側で、クライアント／サーバ・データベースシステムなどにおいて大量データアクセスの禁止や、データベース・アクセス中のクライアントの離席等の防止、データベースのメンテナンス時間の確保、データベース・サーバ過負荷時の入力抑止、さらには各業務処理（サービス）毎の優先度制御が可能になる。
【００４６】
請求項３記載の発明によれば、クライアント・アプリケーション５２は、内部でデータの属性変換処理を行わなくとも、自身のデータ処理に適した属性（形式）でデータの各項目を取り扱うことができる。
【００４７】
請求項４記載の発明によれば、クライアント・アプリケーション５２とサーバ・アプリケーション６２は、内部でデータの属性変換処理を行わなくとも、それぞれのデータ処理に適した属性（形式）でデータの各項目を取り扱うことができる。
【００４８】
【実施例】
以下、図面を参照しながら本発明の実施例を説明する。
図２は、本発明の一実施例のシステム構成図である。
【００４９】
同図において、クライアント・マシン１００とデータベース・サーバ２００とは、ＬＡＮ（ローカル・エリア・ネットワーク）またはＷＡＮ（ワイド・エリア・ネットワーク）を介して接続されている。また、データベース・サーバ２００にはコンソール３００が接続されている。このシステムは、Ｃ／Ｓアプリ型のデータベースシステムであり、クライアント・マシン１００側にクライアント・アプリケーション１１０が、データベース・サーバ２００側にサーバ・アプリケーション２１０が実装されている。そして、このクライアント・アプリケーション１１０とサーバ・アプリケーション２１０とが一体となって業務処理を実行する。
【００５０】
データベース・サーバ２００内には、通信ＤＢ制御機構（通信制御装置）２２０が設けられている。この通信ＤＢ制御機構２２０は、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０との間に介在し、これら両者にＡＰＩ（アプリケーション・プログラミング・インタフェース）を提供している。通信ＤＢ制御機構２２０は、利用者（クライアント）に対して各種公開サービスを提供する通信ＤＢ（通信データベース）２２１を内蔵しており、クライアント・アプリケーション１１０並びにサーバ・アプリケーション２１０は該公開サービスに従って作成される。
【００５１】
データベース・サーバ２００は、データベースシステム２４０を備えており、該データベースシステム２４０はＤＢＭＳ（データベース管理システム）２４２とデータベース（ＤＢ）２４４とから成っている。
【００５２】
サーバ・アプリケーション２１０は、このデータベースシステム２４０に対して、アクセスして、当該サービスに対応する処理（データベースの更新・参照、検索データの加工など）を行う。
【００５３】
通信手順制御部２０１は、例えばＴＣＰ／ＩＰプロトコルなどの通信プロトコルによりクライアント・アプリケーション１１０とネットワークを介してメッセージ（データ）の送受信を行う。このとき、クライアント・アプリケーション１１０からＳＱＬ文（ＩＮＳＥＲＴ）を受信すると、該クライアント・アプリケーション１１０を実行した利用者が、データベースサーバ２００を利用可能かをチェックする利用者認証処理を行う。
【００５４】
この利用者認証処理は、実際には、通信手順制御部２０１の依頼を受けて、利用者認証部２０２が実行する。
利用者は、通信ＤＢ２２１にアクセスする際、まず、データベースサーバ２００にログインする必要がある。この際、クライアント・マシン１００からデータベースサーバ２００に対して利用者識別子とパスワードが送られ、これらは通信手順制御部２０１に受信される。
【００５５】
利用者認証部２０２は、該利用者識別子とパスワードを通信手順制御部２０１から受け取り、これらを基に上記利用者がデータベースサーバ２００のサービスを受ける権利を有しているか否かの利用者認証及び、通信ＤＢ２２１へのアクセス権を有しているか否かをチェックする。このとき、後述する通信ＤＢ２２１内に登録されている該通信ＤＢ２２１のセキュリティ情報を参照する。そして、そのチェック結果を通信手順制御部２０１に返す。
【００５６】
また、上記のように、クライアント・アプリケーション１１０がＳＱＬ文の実行を依頼してきた際にも、上記利用者認証のチェック処理を行う。
通信手順制御部２０１は、上記ＳＱＬ文の実行依頼者がアクセス権限を有していると判断すると該ＳＱＬ文並びに上記実行依頼者の利用者識別子を通信ＤＢ制御機構２２０のＳＱＬ解析制御部２２２Ｃに送信する。
【００５７】
次に、通信ＤＢ制御機構２２０内の各ブロックを説明する。
通信ＤＢ（通信データベース）２２１は、一過性のデータを取り扱う特殊なデータベースであり、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０間で授受されるデータを仲介する。そして、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０に対するＡＰＩとして“ＩＮＳＥＲＴ”と“ＳＥＬＥＣＴ”という２つのデータ操作言語（ＤＭＬ）を提供している。
【００５８】
通信ＤＢ２２１の内部構成を図３に示す。
同図に示されているように、通信ＤＢ２２１内には、複数の公開サービス情報３００が登録される。この公開サービス情報３００は、利用者に対して公開されるサービス単位に登録され、サービス定義情報３０１とこれに包含されるテーブル定義情報３０３とから成る。サービス定義情報３０１は、利用者に対して公開されるサービスのデータの処理形態や、該サービスを実行するサーバ・アプリケーション２１０とのリンク情報が定義されるものであり、以下の［１］〜［４］の項目から成る。
【００５９】
［１］ サービス名
［２］ データ処理形態
［３］ クライアント・アプリケーション１１０により入力されたデータ（メッセ ージ）を通知すべきサーバ・アプリケーション２１０の名称
［４］ このサービスが公開されている利用者のユーザＩＤ／グループＩＤ
また、サービス定義情報３０１は、上記データ処理形態に応じて入力テーブル定義情報３０３Ｉのみまたは入力テーブル定義情報３０３Ｉと応答テーブル定義情報３０３Ｒの２個のテーブル定義を保有する。
【００６０】
ここで、上記［２］のデータ処理形態の種類を図４に示す。
各データ処理形態での通信方法には、リアル通信とディレイド通信がある。尚、同図において、入力テーブル３５１は、クライアント・アプリケーション１１０が“ＩＮＳＥＲＴ”文によりサーバ・アプリケーション２１０に対して通知するデータのキュー（リクエスト・キュー）として機能する。一方、応答テーブル３５２はサーバ・アプリケーション２１０が“ＩＮＳＥＲＴ”文によりクライアント・アプリケーション１１０に対して通知するデータのキュー（レスポンス・キュー）として機能する。
【００６１】
まず、同図（Ａ）は応答型（リアル通信）のデータ処理を説明する図である。このデータ処理においては、１つのサービス定義内に、入力テーブル３５１と応答テーブル３５２の２つのテーブルが生成される。
【００６２】
この応答型（リアル通信）のデータ処理では、クライアント・アプリケーション１１０は依頼データを組み立て、該データを“ＩＮＳＥＲＴ”文によりデータベース・サーバ２００に依頼する（［１］）。このデータは、入力テーブル３５１にキューイングされ、サーバ・アプリケーション２１０が“ＳＥＬＥＣＴ”文を発行することによって、該サーバ・アプリケーション２１０により読み出される（［２］）。サーバ・アプリケーション２１０は、該読み出したデータを基にデータベースシステム２４０をアクセスしてチェック並びに当該処理を行い、その処理結果を“ＩＮＳＥＲＴ”文により応答テーブル３５２にキューイングする（［３］）。そして、ＲＥＴＵＲＮ命令を発行することにより、クライアント・アプリケーション１１０に処理の終了が通知される（［４］）。クライアント・アプリケーション１１０は、該通知を受けた後に、“ＳＥＬＥＣＴ”文を発行して応答テーブル３５２にキューイングされている上記処理結果を受け取る（［５］）。尚、サーバ・アプリケーション２１０は、上記データのチェック時に誤りを検出した場合にも、その旨をクライアント・アプリケーション１１０に通知する。このように、応答型（リアル通信）データ処理は、クライアント・アプリケーション１１０とサーバ・アプリケーション１２０が、一問一答の会話形式により業務処理を実行するものである。
【００６３】
次に、同図（Ｂ）は、集信型（リアル通信）データ処理を説明する図である。この処理においては、サービス定義３０１内には入力テーブル３５１のみが登録される。この処理は、クライアント・アプリケーション１１０がサーバ・アプリケーション２１０に一方的にデータを集信するものである。すなわち、クライアント・アプリケーション１１０は、“ＩＮＳＥＲＴ”文により入力テーブル３５１にサーバ・アプリケーション２１０宛の通知データをキューイングする（［１］）。サーバ・アプリケーション２１０は、“ＳＥＬＥＣＴ”文を発行して該通知データを受け取る（［２］）。これに対して上記と同様にデータベースシステム２４０をアクセスしてチェック並びに当該処理を行い、該処理終了後のＲＥＴＵＲＮ命令により、クライアント・アプリケーション１１０にその処理結果の完了（正常または異常）が通知される（［３］）。クライアント・アプリケーション１１０は、該処理完了後に、上記と同様にして次のデータをサーバ・アプリケーション２１０に通知する。これにより、データベース・サーバ２００側に処理待ちデータが滞留することがなくなり、別の業務へ悪影響を与えることもない。
【００６４】
続いて、同図（Ｃ）は集信型（ディレイド通信）を説明する図である。この処理が上述した集信型（リアル通信）と異なる点は、クライアント・アプリケーション１１０が“ＩＮＳＥＲＴ”文により通信ＤＢ制御機構２００にデータ（メッセージ）を送信すると（［１］）、通信ＤＢ制御機構が該データ（メッセージ）を入力テーブル３５１にキューイングし、該データの保証がなされた時点で、クライアント・アプリケーション１１０に該“ＩＮＳＥＲＴ”文による処理の依頼の完了を通知する点である（［２］）。尚、この場合、上記クライアント・アプリケーション１１０の通知データは、後述するメッセージ保証制御部２２８内の不揮発性記憶媒体上に作成された通信データ保証ファイルにスタックされる。これにより、データベース・サーバ２００側での処理待ちデータの滞留が解決される。
【００６５】
サーバ・アプリケーション２１０は、動作可能な状態になったときに、“ＳＥＬＥＣＴ”文を発行して入力テーブル３５１から上記通知データを受け取り（［６］）、該データに対するチェック並びに当該処理終了後、ＲＥＴＵＲＮ命令を実行し、通信ＤＢ制御機構２２０に処理完了を通知する（［７］）。
【００６６】
上述したように、集信型（リアル通信）では、サーバ・アプリケーション２１０が動作しないと、クライアント・アプリケーション１１０は次のデータ処理に移行できない。これに対し、集信型（ディレイド通信）では、サーバ・アプリケーション２１０の動作に関係なく、直ちに次の処理に移行できる。したがって、集信型（リアル通信）と集信型（ディレイド通信）は、集信するデータの即時性の有無によって使い分ける。すなわち、集信したデータを即時に他の目的で利用する場合にはリアル通信を利用し、発送指示のようなある範囲（時間等）までに処理する場合にはディレイド通信を利用する。
【００６７】
さらに、同図（Ｄ）は、配信型（ディレイド通信）のデータ処理を説明する図である。この処理においては、サーバ・アプリケーション２１０が“ＩＮＳＥＲＴ”文によりクライアント・アプリケーション１１０に通知するデータを入力テーブル３５３にキューイングする（［１］）。通信ＤＢ制御機構２２０は、該通知データをメッセージ保証部２２８内の通信データ保証ファイルにスタックすると、完了通知をサーバ・アプリケーション２１０に返す（［２］）。クライアント・アプリケーション１１０は、この入力テーブル３５３にキューイングされているデータを、必要となった時点で“ＳＥＬＥＣＴ”文を発行することにより受け取る（［６］）。
【００６８】
このように、このデータ処理は、サーバ・アプリケーション２１０側で処理したデータを、クライアント・アプリケーション１１０が必要となった時点で受け取るものである。これは、例えば、別業務のデータをデータベース・サーバ２００側で一括処理し、その処理結果をクライアント・マシン１００側に通知する場合に使用される。
【００６９】
テーブル定義情報３０３Ｉ，３０３Ｒは自己が従属するサービス定義情報３０１で定義されたデータ処理形態に従って処理されるデータ（レコード）の形式を定義するものである。
【００７０】
ここで、図４に示す上述した入力テーブル３５１，３５３または応答テーブル３５２にキューイングされるレコードの形式を定義しているテーブル定義情報３０３Ｉ，３０３Ｒの内容について説明する。両テーブル定義情報は、同一の内容であり以下の［１］〜［３］の項目から成る。
【００７１】
［１］ テーブル名
［２］ レコードの全てのデータ項目名
［３］ 各データ項目の属性（データの形式：CHARACTER, NUMERIC, INTEGER,・・・)
［４］ 各データ項目のデータ長
上記公開サービス定義情報３００は、利用者が業務処理を構築するためのＡＰＩとして、すなわちクライアント・アプリケーション１１０を作成するための情報として、利用者に公開される。すなわち、公開サービス情報３００は、利用者が業務処理を構築するために、データベース・サーバ２００側が利用者に提供可能な公開サービスである。
【００７２】
該公開サービスとしては、各種の予約サービス、照会サービス、受注サービス、通知サービス等がある。
また、公開サービス情報３００の内容に従って、サーバ・アプリケーション２１０が開発されることになる。すなわち、通信ＤＢ２２１へ公開サービス情報３００を登録することによって、システム導入時のシステム設計及びシステム稼働後の業務処理の追加／変更が可能となる。換言するならば、最初のシステム設計またはシステム稼働後の業務処理の追加／変更の際には、まず導入しようとする業務処理の内容を規定する公開サービス情報３００を通信ＤＢ２２１に登録する必要がある。そして、これにより、業務処理の開発または追加／変更時に、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０の開発作業を、互いに独立に進めていくことが可能になる。
【００７３】
再び、図２に戻って、通信ＤＢ制御機構２２０の他のブロックについて説明する。
ＳＱＬ解析制御部２２２Ｃは、前記通信制御部２０１を介して入力するクライアント・アプリケーション１１０から発行されたＳＱＬの解析／チェックを行う。すなわち、そのＳＱＬ文を解析し、該ＳＱＬ文がアクセスしようとする通信ＤＢ２２１の利用資源（テーブル）に対する利用者のアクセス権をチェックする。そして、正当なアクセス権限を有していれば、該ＳＱＬ文による通信ＤＢ２２１の入力テーブルへの登録データをコード変換／属性変換部２２３Ｃへ出力する。尚、上記利用者のテーブルに対するアクセス権限のチェックは、資源利用認証部２２４によって行われる。
【００７４】
資源利用認証部２２４は、ＳＱＬ文解析制御部２２２Ｃを介して、上記ＳＱＬ文を送信してきたクライアント・アプリケーション１１０の実行者の利用者識別子と上記ＳＱＬ文がアクセスしようとする通信ＤＢ２２１のテーブルについての情報を受け取り、後述する通信ＤＢ２２１内に登録されたテーブルのセキュリティ情報を基に、上記テーブルに対するアクセス権の有無をチェックする。そして、そのチェック結果をＳＱＬ解析制御部２２２Ｃに返す。
【００７５】
コード変換／属性変換部２２３Ｃは、ＳＱＬ解析制御部２２２Ｃから受け取るデータに対して、通信ＤＢ２２１内の当該サービス定義情報３０１のテーブル定義情報３０３を参照して、コード並びに属性変換を行う。そして、変換後のデータをメッセージキュー制御部２２５に送る。
【００７６】
コード変換は、異機種間のコード系の変換であり、例えば、シフトＪＩＳ←→ＥＵＣ，ＥＢＣＤＩＣ←→ＥＵＣ等の変換が行われる。
一方、属性変換は、受信データの属性を通信ＤＢ２２１の当該入力テーブルの属性に変換するものであり、例えば、ＤＥＣＩＭＡＬ→ＩＮＴＥＧＥＲ等の変換が行われる。
【００７７】
メッセージキュー制御部２２５は、クライアント・アプリケーション１１０及びサーバ・アプリケーション２１０から発行される通知データの処理の待ち合わせ制御（キュー制御）を行うものである。この待ち合わせ制御に際しては、前述した図４に示す入力テーブル３５１，３５３及び応答テーブル３５２を用いる。これらのテーブル３５１〜３５３は、メッセージキュー制御部２２５自身によって、メモリ上に作成される。
【００７８】
図５は、メッセージ制御部２２５が上記テーブル３５１〜３５３を作成する方法を説明する図である。同図は、例えば、集信型のデータ処理が行われる公開サービス用の入力テーブル３５１の構成及びその作成方法を示している。
【００７９】
メッセージキュー制御部２２５は、通信ＤＢ２２１に登録されている該入力テーブル３５１の形式を定義している入力テーブル定義情報３０３Ｉを、当該公開サービス情報３００から読み出し、メモリ４００上に、キュー先頭ポインタ４１１、キュー最終ポインタ４１２、及び上記読み出した入力定義情報３０３Ｉと同一内容のテーブル情報４１３とから成るキューノード４１０を作成する。そして、このキューノード４１０によって通信バッファ２２６内に作成される連結リスト構造のキューを管理する。
【００８０】
該キューは、チェイン部５０１とデータ部５０２とから成るセル５００が、チェイン部５０１に設定されるポインタによって連結されていく構成の連結リストとなっており、データ部５０２にクライアント・アプリケーション１１０からサーバ・アプリケーション２１０宛の通知データが格納される。メッセージキュー制御部２２５は、キューノード４１０のキュー先頭ポインタ４１１、キュー最終ポインタ４１２、及びセル５００のチェイン部５０１を操作することによって、入力テーブル３５１に入力されるまたは入力テーブル３５１から取り出される通知データのキューイング制御を行う。
【００８１】
図６は通信バッファ２２６にキューイングされるデータの形式を示し、各データ部５０２にはデータ項目の長さとデータ項目の内容とからなる。
尚、図５においては、入力テーブル３５１の構成のみを示したが、応答テーブル３５２及び入力テーブル３５３も同様な構成で、メッセージキュー制御部２２５によって生成される。
【００８２】
また、図２のメッセージ保証制御部２２８は、ディレイド通信によるデータ処理、すなわち集信型（ディレイド通信）、配信型（ディレイド通信）において、それぞれサーバ・アプリケーション２１０またはクライアント・アプリケーション１１０に確実に通知データが渡るまでの間に、該通知データが電源断などのデータベースサーバ２００の各種異常状態から消失してしまうことを防止するために設けられたものであり、上記通知データを内蔵の不揮発性記憶媒体上に作成された不図示の通信データ保証ファイル内に格納して管理する。
【００８３】
アプリ起動要求制御部２２９は、入力テーブル３５１に通知データがキューイングされていれば、該当するサーバ・アプリケーション２１０の起動を、アプリ実行制御部２４１に要求する。
【００８４】
アプリ実行制御部２４１は、該要求を受けて、上記サーバ・アプリケーション２１０を起動させる。
サーバ・アプリケーション２１０は、起動されると、まず、ＳＱＬ文（ＳＥＬＥＣＴ文）を、通信ＤＢ制御機構部２２０内のＳＱＬ解析制御部２２２Ｓに発行する。
【００８５】
ＳＱＬ解析制御部２２２Ｓは、メッセージキュー制御部２２５に依頼して該ＳＱＬ文で依頼された入力テーブル３５１のキューから通知データを取り出し、該通知データをコード変換／属性変換部２２３Ｓに送る。
【００８６】
コード変換／属性変換部２２３Ｓは、上記通知データの属性をサーバ・アプリケーション２１０から依頼された属性に変換し、該変換後の通知データをＳＱＬ解析制御部２２２Ｓに送る。
【００８７】
ＳＱＬ解析制御部２２２Ｓは、上記受け取った通知データをサーバ・アプリケーション２１０に送り、ＳＱＬ文の完了を通知する。
ＳＱＬ解析制御部２２２Ｓは、応答型（リアル通信）のデータ処理を行うサーバ・アプリケーション２１０からは、そのデータ処理結果すなわちクライアント・アプリケーション１１０宛の通知データをＳＱＬ文（ＩＮＳＥＲＴ）により、該サーバ・アプリケーション２１０から受け取る。ＳＱＬ解析制御部２２２Ｓは、該通知データをコード変換／属性変換部２２３Ｓに送り、属性変換を依頼する。
【００８８】
コード変換／属性変換部２２３Ｓは、通信ＤＢ２２１内の上記ＳＱＬ文で指定された応答テーブル３５２の項目属性情報に従って、上記通知データの属性変換を行う。そして、この変換後の通知データをＳＱＬ解析制御部２２２Ｓに返す。
【００８９】
ＳＱＬ解析制御部２２２Ｓは、その受け取った通知データをメッセージキュー
制御部２２５に対して応答テーブル３５２にキューイングするよう要求する。
メッセージキュー制御部２２５は、これを受けて上記通知データを上記応答テーブル３５２にキューイングし、キューイングが終了するとＳＱＬ解析制御部２２２Ｓを介して、サーバ・アプリケーション２１０にＳＱＬ文（ＩＮＳＥＲＴ）の完了を通知する。
【００９０】
サーバ・アプリケーション２１０は、リアル通信の場合には処理が完了するとＲＥＴＵＲＮ命令の実行によりメッセージ応答制御部２３０に対して、クライアント・アプリケーション１１０に対して処理結果を通知してくれるように依頼する。
【００９１】
メッセージ応答制御部２３０は、該依頼に応じて、通信手順制御部２０１を介して、クライアント・アプリケーション１１０がデータベースサーバ２００に対して依頼したＳＱＬ文の実行完了を、該クライアント・アプリケーション１１０に通知する。
【００９２】
さらに、通信ＤＢサービス定義部２３１は、通信ＤＢ２２１に公開サービス情報３００を登録、更新または削除したりするもので、コンソール３００から例えばＤＤＬ（データ定義言語：Data Definition Language）系のＳＱＬ文を受け取ることにより、該ＳＱＬの指示に従って、新たな公開サービス情報３００の登録や、既存の公開サービス情報３００の更新や削除を実行する。これには、サービス定義情報３０１、入力テーブル定義情報３０３Ｉ、及び応答テーブル定義情報３０３Ｒをそれぞれ個々に登録、更新、削除することが可能である。
【００９３】
上記のような作業を行える利用者は、通信ＤＢ２２１の創成時に通信ＤＢ２２１内に登録される。そして、該利用者はコンソール３００からＧＵＩ（グラフィカル・ユーザ・インタフェース）の画面を介して、会話形式により上記作業を行えるようになっている。また、利用者作成のプログラムを、コンソール３００上で実行することによっても可能である。また、このコンソール３００を介して、通信ＤＢ２２１を創成することも可能となっている。
【００９４】
図７は、データ処理形態が応答型の場合に、通信ＤＢ制御機構２２０に対する命令と、通信ＤＢ制御機構２２０を介したデータの流れを図示するとともに、さらに他のクライアント・アプリケーションとの通信データがキューとして入力テーブル３５１、応答テーブル３５２に接続されることを図示したものである。
【００９５】
次に、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０と連携により行われる、図４に示す４種類のデータ処理形態の処理の流れを図２の実施例にそって説明する。
（Ａ）応答型（リアル通信）のデータ処理
《クライアント・アプリケーション１１０→通信ＤＢ制御機構２２０》
(1)クライアント・アプリケーション１１０がＳＱＬ文（ＩＮＳＥＲＴ）を実行すると、通信手順制御部２０１が該ＳＱＬ文を受け取り、利用者認証部２０２を介し利用者認証を行う。そして、通信ＤＢ２２１に対するアクセス権を認めると、そのＳＱＬ文をＳＱＬ解析制御部２２２Ｃに渡す。
【００９６】
(2)ＳＱＬ解析制御部２２２Ｃは、ＳＱＬ文を解析し、該ＳＱＬ文により指定されたテーブルに対するアクセス権を、資源利用認証部２２４を介しチェックする。そして、アクセス権が認められれば、指定データの属性変換をコード変換／属性変換部２２３Ｃに依頼する。
【００９７】
(3)コード変換／属性変換部２２３Ｃは、通信ＤＢ２２１に登録されている当該入力テーブル定義情報３０３Ｉに従い、上記指定データのコード変換／属性変換を行う。
【００９８】
(4)メッセージキュー制御部２２５は、変換後のデータを入力テーブル３５１にキューイングする。
《サーバ・アプリケーション２１０の起動》
(5)アプリ起動要求制御部２２９は、上記入力テーブル３５１に対応するサーバ・アプリケーション２１０の起動を、アプリ実行制御部２４１に要求する。
【００９９】
(6)アプリ実行制御部２４１は、サーバ・アプリケーション２１０が受信可能状態であれば、これを起動する。
《通信ＤＢ制御機構２２０→サーバ・アプリケーション２１０》
(7)サーバ・アプリケーション２１０は入力テーブル３５１からクライアント・アプリケーション１１０からの通知データを受信する為にＳＱＬ文（ＳＥＬＥＣＴ）を、ＳＱＬ解析制御部２２２Ｓに発行する。
【０１００】
(8)ＳＱＬ解析制御部２２２Ｓは、該ＳＱＬ文を解析し、メッセージキュー制御部２２５を介してＳＱＬ文で指定された入力テーブル３５１から上記通知データを取り出す。
(9) コード変換／属性変換部２２３Ｓは、ＳＱＬ解析制御部２２２Ｓからの依頼を受けて、上記通知データをサーバ・アプリケーション２１０が取り扱うデータ属性に変換する。
(10)ＳＱＬ解析制御２２２Ｓは、サーバ・アプリケーション２１０に、変換後の通知データを送ると共にＳＱＬ文の完了を通知する。
《サーバ・アプリケーション２１０→通信ＤＢ制御機構２２０》
(11)サーバ・アプリケーション２１０は、上記通知データを基に、データベースシステム２４０をアクセスし、当該データ処理を行う。
(12)サーバ・アプリケーション２１０は、該データ処理の結果をＳＱＬ文（ＩＮＳＥＲＴ）をＳＱＬ解析制御部２２２Ｓに出力する。
(13)コード変換／属性変換部２２３は、ＳＱＬ解析制御部２２２Ｓからの依頼を受けて、上記処理結果（クライアント・アプリケーション１１０宛の通知データ）を通信ＤＢ２２１に登録されている応答データ３５２のテーブル属性に従って属性変換する。
(14)メッセージキュー制御部２２５は、上記通知データを応答テーブル３５２にキューイングする。そして、このキューイングの完了をＳＱＬ解析制御部２２２Ｓに通知する。
(15)ＳＱＬ解析制御２２２Ｓは、サーバ・アプリケーション２１０にＳＱＬ文の処理完了を通知する。
《サーバ・アプリケーション２１０の完了》
(16)サーバ・アプリケーション２１０は、処理が完了すると、メッセージ応答制御部２３０にクライアント・アプリケーション１１０へのＳＱＬ文の実行完了通知を依頼する。
(17)メッセージ応答制御部２３０は、通信手順制御部２０１を介して、クライアント・アプリケーション１１０にＳＱＬ文（ＩＮＳＥＲＴ）の実行完了を通知する。
《クライアント・アプリケーション１１０→通信ＤＢ制御機構２２０》
(18)クライアント・アプリケーション１１０は、サーバ・アプリケーション２１０からの応答データ（上記通知データ）を受信する為にＳＱＬ文（ＳＥＬＥＣＴ）をデータベース・サーバ２００に発行する。
(19)通信手順制御部２０１は、このＳＱＬ文を受信すると、利用者認証部２０２を介して通信ＤＢ２２１に対するアクセス権の利用者認証を行い、該アクセス権を認めると、ＳＱＬ解析部２２２Ｃに上記ＳＱＬ文（ＳＥＬＥＣＴ）を送る。
(20)ＳＱＬ解析制御部２２２Ｃは、このＳＱＬ文を解析し、資源利用認証部２２４を介して指定応答テーブル３５２に対するアクセス権をチェックし、アクセス権が認められれば、メッセージキュー制御部２２５を介し、上記ＳＱＬ文で依頼された応答テーブル３５２から応答データを取り出す。
(21)コード変換／属性変換部２２３Ｃは、ＳＱＬ解析制御部２２２Ｃの依頼を受けて、上記応答データをクライアント・アプリケーション１１０が取り扱うデータ属性に変換する。
(22)ＳＱＬ解析制御部２２２Ｃは、変換後の応答データと共に通信手順制御部２０１を介して、ＳＱＬ文の完了をクライアント・アプリケーション１１０に通知する。
（Ｂ）集信型（リアル通信）のデータ処理
この処理は、基本的には、上述した応答型（リアル通信）のデータ処理からサーバ・アプリケーション２１０のＳＱＬ文（ＩＮＳＥＲＴ）の発行に対する処理を除いたものとなる。したがって、処理手順は、以下のようになる。
《クライアント・アプリケーション１１０→通信ＤＢ制御機構２２０》
上述した(1) 〜(4) の処理
《サーバ・アプリケーション２１０の起動》
上述した(5) 〜(6) の処理》
《通信ＤＢ制御機構２２０→サーバ・アプリケーション２１０》
上述した(7) 〜(10)の処理
《サーバ・アプリケーション２１０の完了》
上述した(16)〜(17)の処理
（Ｃ）集信型（ディレイド通信）のデータ処理
この処理は、基本的には上述した集信型（リアル通信）のデータ処理と同様であるが、一部の処理が異なっている。
《クライアント・アプリケーション１１０→通信ＤＢ制御機構２２０》
上記(1) 〜(4) の後に、次に述べる(4) ′の処理が行われる。
(4) ′メッセージ・キュー制御部２２５は、メッセージ保証制御部２２８に依頼して、入力テーブル３５１にキューイングしたサーバ・アプリケーション２１０宛の通知データを、通信データ保証ファイルに格納・保持してもらう。そして、メッセージ・キュー制御部２２５は、メッセージ保証制御部２２８から処理完了の通知を受けると、メッセージ応答制御部２３０にクライアント・アプリケーション１１０宛のＳＱＬ文（ＩＮＳＥＲＴ）の実行完了通知を依頼する。メッセージ応答制御部２３０は、これを受けて、通信手順制御部２０１を介してクライアント・アプリケーション１１０に上記ＳＱＬ文（ＩＮＳＥＲＴ）の実行完了を通知する。
《サーバ・アプリケーション２１０の起動》
上述した(5) 〜(6) の処理
《通信ＤＢ制御機構２２０→サーバ・アプリケーション２１０》
上述した(7) 〜(10)の処理
尚、(8) の処理の際、メッセージ保証制御部２２８は、メッセージ・キュー制御部２２５からの通知を受けて、通信データ保証ファイル内に保持されていた上記通知データを取り出す。この際、通信データ保証フィルタ内に保証されていた上記通知データを消去する。
《サーバ・アプリケーション２１０の完了》
(16)′サーバ・アプリケーション２１０は、処理が完了すると、通知ＤＢ制御機構２２０にその旨を通知する。
（Ｄ）配信型（ディレイド通信）のデータ処理
この処理は、上記（Ｃ）集信型（ディレイド通信）とは、通知データの流れが逆になる。すなわち、
［１］ 《サーバ・アプリケーション２１０→通信ＤＢ制御機構２２０》
［２］《通信ＤＢ制御機構２２０→クライアント・アプリケーション１１０》という順になる。
【０１０１】
次に、図８は、上述した応答型（リアル通信）のデータ処理の一具体例を示す模式図である。
同図に示す業務処理は、ある顧客から商品（この例では、２９型のカラーＴＶ）の注文を受けた際に、発送伝票を作成する処理を示している。この業務処理を連携して行うクライアント・アプリケーション１１０とサーバ・アプリケーション２１０は、データベース・サーバ２００側の通信ＤＢ制御機構２２０内の通信ＤＢ２２１に登録されている公開サービス情報３００に従って作成される。
【０１０２】
同図に示すように、該公開サービス情報３００には、サービス定義情報３０１として、データ処理形態が“応答型”である旨が登録されている。
また、入力テーブル定義情報３０３Ｉとしては、
［１］ データ項目名として、「顧客名」、「商品名」、「数量」、「単価」の４項目が定義されている。
【０１０３】
［２］ 上記データ項目の属性として、顧客名（CHARACTER)、商品名（CHARACTER)、数量（DECIMAL)、単価(DECIMAL) が定義されている。
［３］ 上記データ項目の項目長として、顧客名（30桁）、商品名（20桁）が定義されている。
【０１０４】
一方、応答テーブル定義情報３０３Ｒとしては、
［２］ データ項目名として、「消費税」、「合計」、「発送予定日」の３項目が定義されている。
【０１０５】
［２］ 上記データ項目の属性として、消費税（DECIMAL)、合計(DECIMAL) 、発送予定日(CHARACTER) が定義されている。
［３］ 上記データ項目の項目長として、消費税（５桁）、合計（７桁）、発送予定日（８桁）が定義されている。
【０１０６】
また、上述の公開サービス定義情報３００によって利用者に提供される公開サービスＡの利用者（参照可能ユーザまたは更新可能ユーザ）としてUser−１，User−２が登録されている。
【０１０７】
上述したような、公開サービスＡの公開サービス情報３００に従って作成されるクライアント・アプリケーション１１０は、下記の［１］〜［４］の部分から成る。
【０１０８】
［１］ 通信ＤＢ制御機構２２０の通信ＤＢ２２１の当該入力テーブル３５１にキューイングするデータ（入力データ）を作成する処理。上記入力データは、公開サービスＡの入力テーブル定義表の内容に従った形式にする。また、上記入力データの作成のために必要となるデータ（顧客名、商品名、数量、単価）の入力画面を表示部１２０に表示し、該入力画面から上記入力データを読み込むユーザ・インタフェースに係わる処理を行う。
【０１０９】
［２］ 上記の［１］で作成された入力データを、通信ＤＢ制御機構２２０内の公開サービスＡの入力テーブル３０３Ｉに登録してくれるように、ＳＱＬ文（ＩＮＳＥＲＴ）によりデータベース・サーバ２００に依頼する処理。
【０１１０】
［３］ 公開サービスＡの応答テーブル３０３Ｒに登録されているサーバ・アプリケーションの応答結果の取り出しを、ＳＱＬ文（ＳＥＬＥＣＴ）により、データベース・サーバ２００に求める処理。
【０１１１】
［４］ 上記［３］の処理でデータベース・サーバ２００から受け取った応答結果を加工して、クライアント・マシン１００の表示部１２０に伝票画面を表示させる処理。
【０１１２】
上記応答結果のデータ形式は、通信ＤＢ２２１内の公開サービスＡの応答テーブル定義表３５２に定義されているので、これに従って上記加工処理は作成される。このように、クライアント・アプリケーション１１０は、データベース・サーバ２００の通信ＤＢ２２１に登録されている公開サービスＡの公開サービス情報３００を参照することにより作成される。
【０１１３】
一方、上記クライアント・アプリケーション１１０からの依頼を、通信ＤＢ制御機構２２０を介して受け付け、処理するサーバ・アプリケーション２１０も、公開サービスＡの公開サービス情報３００の内容に従って作成される。
【０１１４】
該サーバ・アプリケーション２１０は、以下の［１］〜［４］の部分から成る。
［１］ ＳＱＬ文（ＳＥＬＥＣＴ）により、通信ＤＢ制御機構２２０に対して公開サービスＡの入力テーブル３５１にキューイングされている自己宛の通知データ（前記クライアント・アプリケーション１１０の入力データ）の転送を要求し、該通知データを通信ＤＢ制御機構２２０から受け取る処理。
【０１１５】
［２］ 上記通知データを基に、データベースシステム２４０をアクセスして、該データベースシステム２４０内のデータベース２４４の当該ファイル（この例では、顧客マスタファイル２４４１、商品マスタファイル２４４２、在庫マスタファイル２４４３、取引履歴ファイル２４４４）のデータの参照・更新を行う処理。そして、公開サービスＡの応答テーブル定義表３０３Ｒの定義に行って、通信ＤＢ制御機構２２０の公開サービスＡの応答テーブル３５２に登録するデータ（応答データ）を作成する処理。この応答データは、クライアント・アプリケーション１１０がデータベース・サーバ２００に対して依頼した要求の応答結果となるものであるが、サーバ・アプリケーション２１０はこれをあえて意識する必要はなく、あくまでも応答テーブル定義表３０３Ｒの内容に従って、上記応答データを作成すればよい。
【０１１６】
［３］ ＳＱＬ文（ＩＮＳＥＲＴ）により、通信ＤＢ制御機構２２０に対して上記応答データを応答テーブル３５２に登録するように依頼する処理。
［４］ ＲＥＴＵＲＮ命令により、通信ＤＢ制御機構２２０内のメッセージ応答制御部２３０に対して、クライアント・アプリケーション１１０のＳＱＬ文（ＩＮＳＥＲＴ）の実行完了を通知するように依頼する処理。
【０１１７】
以上のようにして作成されたクライアント・アプリケーション１１０とサーバ・アプリケーション２１０は、互いに通信ＤＢ制御機構２２０を介して、データの送受信を行う。そして、この場合、クライアント・アプリケーション１１０は、データベース・サーバ２００の通信ＤＢ制御機構２２０を２回アクセスするだけである。すなわち、要求依頼時に公開サービスＡの入力テーブル３５１を１回、該要求に対する応答結果の受信時に公開サービスＡの応答テーブル３５２を１回アクセスするだけである。そして、実際のデータベースすなわちデータベースシステム２４０のデータベース２４４に対する検索・更新などを行うバックエンド処理は、サーバ・アプリケーション２１０が担当する。このサーバ・アプリケーション２１０も、通信ＤＢ制御機構２２０に対するアクセスは２回（入力テーブル３５１と応答テーブル３５２をそれぞれ１回）である。
【０１１８】
上記例は、応答型（リアル通信）のデータ処理の例であるが、次に示す図９は、前述した従来、クライアント・アプリケーション１１０がＲＤＡにより行っていた受注処理を本実施例の集信型のデータ処理により行う例を示す模式図である。
【０１１９】
この場合、データベース・サーバ２００の通信ＤＢ制御機構２２０内の通信ＤＢ２２１にクライアント・アプリケーション１１０からサーバ・アプリケーション２１０に渡すべきデータ項目（この場合、「顧客No. 」、「部品No. 」、「発注数」、「受注番号」）について、上述したような形式で集信型の公開サービス情報３００の入力テーブル定義情報３０３Ｉに定義する。そして、この入力テーブル定義情報３０３Ｉに従って、利用者からそれに定義されているデータ項目のデータを利用者から入力し、その入力データをＳＱＬ文（ＩＮＳＥＲＴ）により、通信ＤＢ制御機構２２０の当該入力テーブル３０３Ｉに登録するように依頼する処理を、クライアント・アプリケーション１１０として作成する。
【０１２０】
一方、ＳＱＬ文（ＳＥＬＥＣＴ）により、上記入力テーブル３０３Ｉからクライアント・アプリケーション１１０から入力データを受け取ってデータベースシステム２４０の当該データベース（ＤＢ）２４４、（顧客情報ファイル２４４６、在庫情報ファイル２４４７、受注情報ファイル２４４８を有する）をアクセスして、顧客チェック、在庫チェック、在庫更新、受注登録などのバックエンド処理を行うサーバ・アプリケーション２１０を作成する。
【０１２１】
これにより、クライアント・アプリケーション１１０は、データベース・サーバ２００に対し１回アクセスするだけで、すなわち入力テーブル３０３Ｉへ入力データを挿入するＳＱＬ文（ＩＮＳＥＲＴ）をデータベース・サーバ２００へ送信するだけで、１回の受注処理が終了する。これにより、従来に比べ、短時間で処理が終了すると共に、ネットワーク上のトラヒック量が削減され、通信コストが低減される。
【０１２２】
また、特に具体例は示さないが、配信型（ディレイド通信）においても、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０は、通信ＤＢ２２１の当該入力テーブル定義情報３０３Ｉの定義内容に従って、それぞれ独立に作成することが可能である。
【０１２３】
また、データベースシステム２４０に対するアクセスは、サーバ・アプリケーション２１０のみが担当するので、該データベースシステム２４０のデータベース２４４の構造が変更されても、クライアント・アプリケーション１１０の修正は不要となる。
【０１２４】
図１０は、クライアント・アプリケーション１１０がデータベース２４４のデータ更新を行い、このデータ更新をサーバ・アプリケーション２１０がクライアント・アプリケーションに通知することを示す。
【０１２５】
図１１は、データベース２４４の構造が変更されても、クライアント・アプリケーション１１０の修正が不要となる例を模式的に示す。これは、従来システムの問題点で取り上げた図２５に対応するものである。
【０１２６】
図１１（Ａ）に示すように、サーバ・アプリケーション２１０が、通信ＤＢ制御機構２２０内の入力テーブル３５１（通信ＤＢ−ＴＡＢＬＥ１）を介して、クライアント・アプリケーション１１０からの依頼データを受け取り、該依頼データをデータベースシステム２４０のデータベース２４４（ＤＢ１）のＴＡＢＬＥ１（ＤＢ１−ＴＡＢＬＥ１）に挿入する業務処理が行われていたとする。
【０１２７】
この場合、業務追加等によりＤＢ１−ＴＡＢＬＥ１の項目数が増加し、データベースＤＢ１に対するアクセス性能が低下し、同図（Ｂ）に示すようにデータベースＤＢ１において上記ＤＢ１−ＴＡＢＬＥ１をＤＢ１−ＴＡＢＬＥ１−１とＤＢ１−ＴＡＢＬＥ１−２に分割するものとする。この場合、サーバ・アプリケーション２１０の修正だけで対処できる。すなわち、同図（Ａ）に示すサーバ・アプリケーション２１０の中の“INSERT DB1-TABLE1 ”という1 つのステートメントを、同図（Ｂ）に示すように、“INSERT DB1-TABLE1-1 ”と“INSERT DB1-TABLE1-2 ”の２つのステートメントに変更するだけでよい。この変更は、通信ＤＢ制御機構２２０の入力テーブル３５１（通信ＤＢ−ＴＡＢＬＥ１）の構成に変更を及ぼさない。従って、クライアント・アプリケーション１１０の変更は不要である。したがって、データベースシステム２４０の管理者は、クライアント・アプリケーション１１０を意識することなく、データベース２４４の構造を変更することができる。
【０１２８】
また、利用者（クライアント・アプリケーション１１０の開発者）には、通信ＤＢ２２１に登録された公開サービス情報３００（サービス定義情報３０１、入力テーブル定義情報３０３Ｉ、応答テーブル定義情報３０３Ｒ）のみが公開され、データベース・サーバ２００側のデータベースシステム２４０のデータベース２４４の構造については公開されない。したがって、利用者に公開するテーブルの設計・管理とデータベースシステム２４０のデータベース２４４に登録するテーブルの設計・管理を分離してとられることができる。これにより、データベースのテーブル設計において、利用者に公開する通信ＤＢ２２１のテーブルとデータベースシステム２４０のデータベース２４４とを、独立して別々に設計することができる。通信ＤＢ２２１のテーブル設計者（データ公開者）は、利用者の使い易さを考慮してテーブルを設計・管理すればよく、データベースシステム２４０のデータベース２４４のテーブル設計者（データベース管理者）は、該データベース２４４のアクセス性能等や共用管理を考慮してテーブルを設計・管理すればよい。
【０１２９】
図１２は、通信ＤＢ２２１に登録されるセキュリティ情報の内容を説明する模式図である。
同図において、利用権を与えられた利用者を“利用可能ユーザ”、更新権を与えられたユーザを“更新可能ユーザ”として示している。
【０１３０】
該セキュリティ情報としては、通信ＤＢ２２１に対するアクセス権に係るセキュリティ情報１２１０と公開サービス情報３００（同図に示すサービスＡ，Ｂ，Ｃ）に対するアクセス権に係わるセキュリティ情報１２２０がある。
【０１３１】
通信ＤＢ２２１のセキュリティ情報１２１０は、利用権と更新権の２つの項目がある。利用権が与えられた利用者（ユーザ）は、通信ＤＢ２２１へのアクセスは可能であるが通信ＤＢ２２１の更新はできない。更新権が与えられた利用者は、通信ＤＢ２２１の更新も可能である。
【０１３２】
通信ＤＢ２２１に対する接続要求が行われたときには、該アクセス者が上記利用権または更新権のいずれかを有しているかのチェックが行われ、いずれも有していない場合には、通信ＤＢ２２１に対するアクセスは禁止される。
【０１３３】
また、公開サービス情報３００（公開サービス）のセキュリティ情報には、参照権と更新権がある。参照権が与えられた利用者は、当該公開サービス情報３００に対応するテーブル３５１〜３５３へのアクセスのみが可能であり、公開サービス情報３００の内容の更新（サービス定義情報３０１及びテーブル定義情報３０２，３０３）の更新はできない。一方、更新権が与えられた利用者は上記アクセスのみならず、公開サービス情報３００の更新並びに削除が可能である。同図において、参照権が与えられた利用者を“参照可能ユーザ”、更新権が与えられたユーザを“更新可能ユーザ”として示している。
【０１３４】
尚、通信ＤＢ２２１に対する更新権を与えられた利用者は、公開サービス情報３００の更新・削除も可能である。
次に、上記構成の実施例の動作を説明する。
【０１３５】
まず、通信ＤＢ２２１にクライアント・アプリケーション１１０に公開するサービス定義情報３０１を登録する際の動作を説明する。この登録は、上述した公開サービス情報３００の更新権が与えられた利用者のみが可能である。
【０１３６】
ア）該利用者は、コンソール３００のＧＵＩ画面上で通信ＤＢ２２１のテーブルを設計し、データベース・サーバ２００に対し、該テーブルの定義情報をＳＱＬ文により登録依頼する。
【０１３７】
通信手順制御部２０１は、この要求を受け取ると、利用者認証部２０２を介し利用者認証を行い、通信ＤＢ２２１に対するアクセス権を認めるとＳＱＬ解析制御部２２２Ｃに上記ＳＱＬ文を渡す。
【０１３８】
イ）ＳＱＬ解析制御部２２２Ｃは、このＳＱＬ文を解析し、資源利用認証部２２４を介し通信ＤＢ２２１に対する登録権をチェックする。
ウ）該チェックにより、登録権の確認がとれると、コード変換／属性変換部２２３Ｃを介し、コード変換する。
【０１３９】
エ）通信ＤＢサービス定義部２３１は、依頼されたテーブル定義情報を通信ＤＢ２２１に登録する。
オ）通信ＤＢサービス定義部２３１は、登録が完了すると、ＳＱＬ解析制御部２２２Ｃに完了通知を行う。
【０１４０】
カ）ＳＱＬ解析制御部２２２Ｃは、通信手順制御部２０１を介し、クラアイント・アプリケーション１１０に登録完了を通知する。
キ）コンソール３００は、これを受けて、ＧＵＩ画面上に登録完了を表示する。
【０１４１】
次に、本実施例におけるセキュリティ管理の方法を説明する。
このセキュリティ管理は、通信ＤＢ２２１への接続要求時と該通信ＤＢ２２１内の入力テーブル３０３Ｉ及び応答テーブル３０３Ｒに対するアクセス時に行われる。
【０１４２】
１．通信ＤＢ２２１への接続要求時にセキュリティ・チェック
このセキュリティ・チェックは、通信手順制御部２０１が利用者認証部２０２を介して行う。図１３は、このチェック処理を説明するフローチャートである。
【０１４３】
通信手順制御部２０１は、クライアント・アプリケーション１１０から、ネットワークを介して通信ＤＢ２２１への接続要求を受信すると、該要求時に送られてきた利用者識別子を利用者認証部２０２に送り、上記クライアント・アプリケーション１１０の実行者が通信ＤＢ２２１に対する利用権を有しているか否かのチェックを依頼する（Ｓ１）。
【０１４４】
利用者認証部２０２は、通信ＤＢ２２１に登録されている通信ＤＢ２２１のセキュリティ情報１２１０（図１２）を参照して、上記利用者が該通信ＤＢ２２１の利用権を有しているか否かチェックし、そのチェック結果を通信手順制御部２０１に返す（Ｓ２）
通信手順制御部２０１は、該チェック結果を受け取り、利用者が通信ＤＢ２２１の利用権を有していることが分かると（Ｓ３，ＹＥＳ）、クライアント・アプリケーション１１０に対して“通信ＤＢ２２１への接続が成功した”旨の応答メッセージを返し（Ｓ４）、クライアント・アプリケーション１１０から該通信ＤＢ２２１のテーブルへのアクセス要求を待つ（Ｓ５）。
【０１４５】
一方、上記ステップＳ３で、利用者が通信ＤＢ２２１の利用権を有していないことが分かると（Ｓ３，ＮＯ）、クライアント・アプリケーション１１０に対して、“通信ＤＢ２２１への接続が失敗した”旨の応答メッセージを返す（Ｓ６）。
【０１４６】
２．テーブルアクセス要求受信時のセキュリティチェック
このセキュリティチェック処理は、通信ＤＢ制御機構２２０のＳＱＬ解析制御部２２２Ｃが資源利用認証部２２４を介して行う。
【０１４７】
図１４は、このチェック処理を説明するフローチャートである。
ＳＱＬ解析制御部２２２Ｃは、通信手順制御部２０１からテーブルのアクセス要求のＳＱＬ文を受信すると、資源利用認証部２２４に該指定テーブル名と該アクセスを行ったクライアントの利用者識別子を送り、資源利用認証部２２４へ該クライアントが上記指定テーブルに対するアクセス権を有しているか否かのチェックを依頼する（Ｓ１１）。
【０１４８】
資源利用認証部２２４は、通信ＤＢ２２１の上記指定されたテーブルが属する公開サービスのセキュリティ情報１２２０を参照し、上記受け取った利用者識別子を基に、上記指定テーブルに対するクライアントのアクセス権をチェックする。該アクセスには、“参照”と“更新”の２種類があり、“参照依頼”の場合は上記セキュリティ情報１２２０に登録されている参照権情報を、“更新依頼”の場合は上記セキュリティ情報１２２０に登録されている更新権情報をチェックする。そして、そのチェック結果をＳＱＬ解析制御部２２２Ｃに返す（Ｓ１２）。
【０１４９】
ＳＱＬ解析制御部２２２Ｃは、上記チェック結果を判別し、クライアントの指定テーブルに対するアクセスが正当であれば（Ｓ１３，ＹＥＳ）、上記公開サービスに対応したサーバ・アプリケーション２１０にクライアントからの通知データが渡るように、メッセージキュー制御部２２５に上記通知データを上記指定テーブルに登録（キューイング）するように依頼する（Ｓ１４）。
【０１５０】
一方、上記ステップＳ１３で、クライアントが指定テーブルに対する正当なアクセス権を有していないことが分かると（Ｓ１３，ＮＯ）、通信手順制御部２０１を介してクライアント（クライアント．アプリケーション１１０）に“アクセス権が無い旨”の応答メッセージを通知する（Ｓ１５）。
【０１５１】
また、本実施例では、あるクライアントがデータベースシステム２４０のデータベース２４４（以後便宜上実ＤＢ２４４と記述する）に対して大量のデータのアクセスをしても、他のクライアントへの応答性に悪影響を与えることはない。
【０１５２】
これは、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０との間に通信ＤＢ制御機構２２０を介在させ、クライアント・アプリケーション１１０による通信ＤＢ２２１へのデータの格納処理（通信ＤＢ格納処理）と該格納データを用いたサーバ・アプリケーション２１０に実ＤＢ２４４へのアクセス（実ＤＢアクセス処理）を、通信ＤＢ制御機構２２０内に設けたキュー制御機構により分類させ、それぞれ非同期に動作させることにより実現している。
【０１５３】
これを、図１５のフローチャートを参照しながら説明する。
通信ＤＢ制御機構２２０において、メッセージキュー制御部２２５が開設されている公開サービスの入力テーブル３５１に対するデータの格納要求待ち状態にあるときに、クライアント・アプリケーション１１０から該入力テーブル３５１に対するデータの格納要求（ＩＮＳＥＲＴ）があると（Ｓ３１）、メッセージキュー制御部２２５は、該データを入力テーブル３５１にキューイングする。すなわち、メモリ上に獲得した通信バッファ２２６に上記データを格納し、これを入力テーブル３５１のキューにリンクさせる（Ｓ３２）。
【０１５４】
そして、このキューイング処理が完了すると、通信ＤＢ２２１への格納要求の実行が完了した旨の応答メッセージを、該要求元のクライアント・アプリケーション１１０に通知する（Ｓ３３）。
【０１５５】
メッセージキュー制御部２２５は、上記入力テーブル３５１にキューイングされるデータを処理する当該サーバ・アプリケーション２１０の現在の状態を調べ、現在、処理の実行中ならば、前記ステップＳ３１に戻り、再びクライアント・アプリケーション１１０からの格納要求待ちとなる（Ｓ３４，処理中）。
【０１５６】
一方、上記当該サービス・アプリケーション２１０が現在、処理待ち状態にあれば（Ｓ３４，処理待ち）、アプリ起動要求制御部２２９を介してアプリ実行制御部２４１に上記当該サーバ・アプリケーション２１０の起動要求を行う（Ｓ３５）。
【０１５７】
これにより、アプリ実行制御部２４１は、上記当該サーバ・アプリケーション２１０の状態を“起動要求待ち”（Ｓ３６）から“処理中”に変更させる（Ｓ３７）。そして、上記当該サーバ・アプリケーション２１０を実行させる（Ｓ３８）。
【０１５８】
当該サーバ・アプリケーション２１０は、通信ＤＢ２２１すなわち上記入力テーブル３５１からクライアント・アプリケーション１１０により格納されたデータを取り出し、該データを基に実ＤＢ２４４をアクセスし、当該データ処理を行う（Ｓ３９）。
【０１５９】
アプリ実行制御部２４１は、上記当該サーバ・アプリケーション２１０の処理が終了すると、上記入力テーブル３５１に上記当該サーバ・アプリケーション２１０宛のデータが格納（キューイング）されていないか調べ、有れば（Ｓ４０，データ有り）、再び、上記ステップＳ３８に戻り上記当該サーバ・アプリケーション２１０を起動させる。これにより、入力テーブル３５１に格納されているデータがなくなるまで上記ステップＳ３８〜Ｓ３９の処理が繰り返される。
【０１６０】
そして、アプリ実行制御部２４１は、入力テーブル３５１に格納されているデータが無くなると（Ｓ４０，データ無し）、上記当該サーバ・アプリケーション２１０の状態を“処理待ち”にさせる（Ｓ４１）。これにより、上記当該サーバ・アプリケーション２１０は再び起動要求待ちとなる（Ｓ３６）。
【０１６１】
このように、通信ＤＢ制御機構２２０は、クライアント・アプリケーション１１０からの通信ＤＢ２２１へのデータ格納要求に対して、該格納データを当該公開サービスの入力テーブル３５１へのキューイングが終了した時点でその格納要求の完了を直ちにクライアント・アプリケーション１１０に通知する。したがって、クライアント・アプリケーション１１０は、通信ＤＢ２２１へのアクセスに対して常に速い応答を受け取ることができる。また、通信ＤＢ制御機構２２０も、多くのクライアント・アプリケーションからの通信ＤＢ２２１へのアクセスを、短時間で多量に受け付けることができる。
【０１６２】
次に、図１６は、本実施例における、管理者のアクセス時間帯、データベースサーバ２００の過負荷制御、及び業務毎の優先度制御の運用管理方法を説明する図である。
【０１６３】
同図において、データベースサーバ２００には、２台のクライアント・マシン１１０−１，１１０−２が接続され、データベースサーバ２００内には２つの通信ＤＢ２２１Ａ，２２１Ｂが構築されている。また、通信ＤＢ２２１Ａには公開サービスＡが、通信ＤＢ２２１Ｂには公開サービスＢが登録されている。そして、公開サービスＡに対応するサーバ・アプリケーション２１０Ａが、公開サービスＢに対応するサーバ・アプリケーション２１０Ｂが実装されている。
【０１６４】
また、データベースサーバ２００内のデータベースシステム２４０のデータベース（実ＤＢ）２４４は、テーブル群Ａ（テーブルＡ１，Ａ２）、テーブル群Ｂ（テーブルＢ１）が登録されている。そして、サーバ・アプリケーション２１０Ａは実ＤＢ２４４のテーブル群Ａをアクセスし（これをアクセスａ２と呼ぶ）、サーバ・アプリケーション２１０Ｂは実ＤＢ２４４のテーブル群Ｂをアクセスする（これをアクセスｂ２と呼ぶ）。また、クライアント・マシン１１０−１からの通信ＤＢ２２１Ａの公開サービスＡに対するアクセスはａ１、クライアント・マシン１１０−２からの通信ＤＢ２２１Ｂの公開サービスＢに対するアクセスはｂ１と呼ぶことにする。
【０１６５】
１．アクセス時間帯の運用・管理
例えば、実ＤＢ２４４においてテーブル群Ａについてのみメンテナンスを行う事態が生じたとする。この場合、管理者は、クライアント・マシン１１０−１の通信ＤＢ２２１Ａに対するアクセスａ１またはサーバ・アプリケーション２１０の実ＤＢ２４４に対するアクセスａ２を抑止させる。この間、実ＤＢ２４４のテーブル群Ｂに対するアクセス、すなわちクライアント・マシン１１０−２の通信ＤＢ２２１Ｂに対するアクセスｂ１及びサーバ・アプリケーション２１０Ｂの実ＤＢ２４４に対するアクセスｂ２は抑止させる必要はない。すなわち、テーブル群Ｂに対する処理は中断させることなく、テーブル群Ａをメンテナンスすることが可能となる。
【０１６６】
尚、アクセスａ１の抑止は、通信ＤＢ２２１Ａのサービス閉塞機能により行う。また、アクセスａ２の抑止は、サーバ・アプリケーション２１０Ｂの実行環境の停止により行う。アクセスａ２のみの抑止を行った場合、クライアント・マシン１１０−１に対しては、通信ＤＢ２２１Ａに対するアクセスａ１、すなわち公開サービスＡは停止させることなく、実ＤＢ２４４のメンテナンスを行うことができる。何故なら、この間、アクセスａ１による要求は通信ＤＢ２２１Ａの公開サービスＡに対応する入力テーブル３５１にキューイングされるからである。
【０１６７】
このように、本実施例においては、通信ＤＢ２２１を設けたことにより、システムの停止範囲を局所化した運用が可能となる。
２．過負荷制御
これは、各公開サービスに対して重要度を設定し、データベースサーバ２００の負荷が高くなったときには、重要度の低い公開サービスへのアクセスを停止することにより行う。
【０１６８】
例えば、図１６の例では、公開サービスＡの方が公開サービスＢよりも重要度が低い場合、クライアント・マシン１１０−１からの通信ＤＢ２２１−Ａの公開サービスＡへのアクセスａ１またはサーバ・アプリケーション２１０Ａの実ＤＢ２４４のテーブル群Ａへのアクセスａ２を抑止する。すなわち、これによりサーバ・アプリケーション２１０Ａの処理を停止させる。これにより、データベースサーバ２００の負荷が軽減される。
【０１６９】
この場合にも、上記アクセスａ１及びアクセスａ２の抑止は、上述したアクセス時間帯の制御のときと同様にして行う。また、この場合においても、アクセスａ２の抑止のみを行い、クライアント・マシン１１０−１に対してはサービスを停止させずに、負荷を抑えることが可能である。これは、サーバ・アプリケーション２１０Ａの負荷が高い場合に有効である。
【０１７０】
３．優先度制御
この制御においても、各公開サービスに重要度を設定しておく。そして、重要度の低い業務処理の動作を一時的に停止させ、より重要度の高い業務処理を優先的に動作させる制御を行う。
【０１７１】
すなわち、例えば図１６に示す例において、公開サービスＡの方が公開サービスＢよりも重要度が低い場合、上記アクセスａ１またはアクセスａ２を抑止させて、サーバ・アプリケーション２１０Ａの処理を停止させる。これにより、サーバ・アプリケーション２１０Ｂの処理能力が高まり、この結果としてクライアント・マシン１１０−１に対する公開サービスＢが優先的に実行される。すなわち、公開サービスＢの優先度を上げた運用が可能になる。
【０１７２】
この場合においても、上記アクセスａ１及びアクセスａ２の抑止は、上述したアクセス時間帯及び過負荷制御のときと同様にして行うことができる。この場合においても、アクセスａ２の抑止のみを行った場合、クライアント・マシン１１０−１側に対しては公開サービスを停止させるようにすることができる。
【０１７３】
図１７は、上述したアクセス時間帯、過負荷制御、及び優先度制御を実現する通信ＤＢ制御機構２２０の動作を説明するフローチャートである。
この場合、通信ＤＢ２２１のサービス閉塞機能は、当該公開サービスに対応する入力テーブル３０３Ｉへのデータの格納（格納サービス）の禁止を意味する。また、サーバ・アプリケーション２１０の実行環境の停止は、サーバ・アプリケーション２１０が停止状態にあることを意味する。
【０１７４】
同図において、メッセージキュー制御部２２５は、入力テーブル３０３Ｉへのデータ格納要求待ちにあるときに、クライアント・アプリケーション１１０からデータの格納要求を受信すると（Ｓ５１）、メッセージキュー制御部２２５はその入力テーブル３０３Ｉの現在の格納サービス状態をチェックする（Ｓ５２）。そして、該格納サービスが閉塞状態にあれば、上記クライアント・アプリケーション１１０に対して“格納失敗”のエラーメッセージを、通信手順制御部２０１を介して通知する（Ｓ５２，格納不可）。
【０１７５】
すなわち、この場合、前記図１７に示す例の場合、クライアント・マシン１１０−１からの公開サービスＡに対するアクセスａ１が抑止される。
一方、上記ステップＳ５２で閉塞状態でなければ（Ｓ５２，格納可）、要求のあった格納データを入力テーブル３０３Ｉへキューイングし（Ｓ５３）、該キューイング完了時点で、データ格納要求が完了した旨の応答メッセージをクライアント・アプリケーション１１０に通知する（Ｓ５４）。
【０１７６】
続いて、上記当該入力テーブル３０３Ｉに対応するサーバ・アプリケーション２１０の状態をチェックして（Ｓ５５）、該サーバ・アプリケーション２１０が現在、停止中ならば上記ステップＳ５１に戻り、次のデータ格納要求待ちとなる。
【０１７７】
すなわち、サーバ・アプリケーション２１０の実行環境が停止中であれば、クライアント・アプリケーション１１０からのサービス要求に対してサーバ・アプリケーション２１０の実ＤＢ２４４に対するアクセスが停止される。
【０１７８】
一方、上記ステップＳ５５で上記サーバ・アプリケーション２１０が処理待ち状態にあれば、アプリ起動要求制御部２２９を介してアプリ実行制御部２４１に上記サーバ・アプリケーション２１０の起動要求を行う（Ｓ５６）。
【０１７９】
該起動要求後は、前述した図１６に示すときと同様にして、上記サーバ・アプリケーション２１０が実行される。
図２に示すように、本実施例では通信ＤＢ制御機構２２０内に、２つのコード変換／属性変換部２２３Ｃ，２２３Ｓを設けている。そして、さらに、これらの変換部２２３Ｃ，２２３Ｓの間に通信ＤＢ２２１を設けている。通信ＤＢ２２１内にはクライアント・アプリケーション１１０とサーバ・アプリケーション２１０間のメッセージ（データ）の授受に使用される入力テーブル３５１，３５３，応答テーブル３５２が生成されるが、キューとして機能するこれらのテーブルに格納されるデータの各項目の型式（属性）は通信ＤＢ２２１に登録されているテーブル定義情報３０３（入力テーブル定義情報３０３Ｉ、応答テーブル定義情報３０３Ｒ）に項目属性として定義されている。
【０１８０】
図１８は、本実施例が上記構成によって実現しているクライアント・アプリケーション１１０とサーバ・アプリケーション２１０間で授受されるデータの項目属性変換機構を示す模式図である。
【０１８１】
コード変換／属性変換部２２３Ｃは、クライアント・アプリケーション１１０が送受信するデータの各項目に対して、以下のような属性変換処理を行う。
［１］ 通信ＤＢ２２１へのデータ挿入時
クライアント・アプリケーション１１０から送信されてくるデータの各項目をテーブル定義情報によって定義されている属性に変換・出力する。
【０１８２】
［２］ 通信ＤＢ２２１からのデータ取り出し時
サーバ・アプリケーション２１０が通信ＤＢ２２１へ挿入したデータ（応答テーブル３５２または入力テーブル３５３に挿入したデータ）の各項目をクライアント・アプリケーション１１０により要求される項目属性に変換・出力する。
【０１８３】
一方、コード変換／属性変換部２２３Ｓは、サーバ・アプリケーション２１０が送受信するデータの各項目に対して以下のような項目属性変換処理をする。
［３］ 通信ＤＢ２２１からのデータ取り出し時
通信ＤＢ２２１（入力テーブル３５１）から取り出したデータの各項目の属性を、サーバ・アプリケーション２１０から要求される属性に変換・出力する。
【０１８４】
［４］ 通信ＤＢ２２１へのデータ挿入時
サーバ・アプリケーション２１０から送信されてくるデータの各項目の属性を、通信ＤＢ２２１のテーブル定義情報３０３に定義されている属性に変換・出力する。
【０１８５】
次に、上述した［１］〜［４］の属性変換処理を、図１９乃至図２２のフローチャートにより、個々に説明する。
図１９は、コード変換／属性変換部２２３Ｃが実行する上記［１］の属性変換処理を説明するフローチャートである。
【０１８６】
コード変換／属性変換部２２３Ｃは、クライアント・アプリケーション１１０が依頼してきた通信ＤＢ２２１（入力テーブル３５１）への挿入データをＳＱＬ解析制御部２２２Ｃから受け取ると（Ｓ１１１）、通信ＤＢ２２１内の上記入力テーブル３５１の定義情報３０３Ｉに定義されている項目属性情報と上記受信データの各項目の属性とを比較し（Ｓ１１２）、属性が一致しない項目があれば（Ｓ１１２，不一致）、該項目を入力テーブル定義情報３０３Ｉに定義されている属性に変換する（Ｓ１１３）。
【０１８７】
一方、上記ステップＳ１１２で、受信データの全項目の属性が入力テーブル定義情報３０３Ｉに定義されている属性と一致すれば（Ｓ１１２，一致）、該受信データの属性変換は行わない。
【０１８８】
次に、図２０は、コード変換／属性変換部２２３Ｓが実行する上記［３］の属性変換処理を説明するフローチャートである。
コード変換／属性変換部２２３Ｓは、入力テーブル３５１からクライアント・アプリケーション１１０により挿入されたサーバ・アプリケーション２１０宛のデータを取り出すと（Ｓ１２１）、該入力テーブル３５１の定義情報３０３Ｉを参照して、上記取り出したデータの各項目の属性を、サーバ・アプリケーション２１０から依頼された属性と比較する（Ｓ１２２）。
【０１８９】
そして、上記取り出したデータの項目の中に、サーバ・アプリケーション２１０から依頼された属性と一致しないものがあれば（Ｓ１２２，不一致）該項目をサーバ・アプリケーション２１０により依頼された属性に変換する（Ｓ１２３）。
【０１９０】
そして、該変換後のデータをサーバ・アプリケーション２１０に送信する（Ｓ１２４）。一方、上記ステップＳ１２２で上記取り出したデータの全項目の属性がサーバ・アプリケーション２１０から依頼された属性と一致しているならば（Ｓ１２２，一致）、直ちに上記ステップＳ１２４の処理を実行する。
【０１９１】
上述した図１９及び図２０のフローチャートに示す属性変換処理により、クライアント・アプリケーション１１０がサーバ・アプリケーション２１０へデータを送信する際、それぞれのアプリケーション１１０，２１０はそれぞれの処理に適した属性でデータ処理が行える。
【０１９２】
次に、図２１は、コード変換／属性変換部２２３Ｓが実行する上記［４］の属性変換処理を説明するフローチャートである。
コード変換／属性変換部２２３Ｓは、サーバ・アプリケーション２１０がＳＱＬ文（ＩＮＳＥＲＴ）により依頼する通信ＤＢ２２１（応答テーブル３５２または入力テーブル３５３）に挿入するデータを受信すると（Ｓ１３１）、通信ＤＢ２２１に登録されている上記テーブル３５２または３５３の定義情報３０３Ｒまたは３０３Ｉを参照して、該受信したデータの全項目の属性が上記定義情報３０３Ｒまたは３０３Ｉに定義されている属性と一致しているか否か比較する（Ｓ１３２）。
【０１９３】
そして、属性が一致していない項目があれば（Ｓ１３２，不一致）、該項目を上記定義情報３０３Ｒまたは３０３Ｉで定義されている属性に変換する（Ｓ１３３）。
【０１９４】
一方、上記ステップＳ１３２で、受信データの全項目がテーブル定義情報３０３Ｒまたは３０３Ｉで定義されている属性と一致すれば（Ｓ１３２，一致）、上記受信データについて項目の属性変換は行わない。
【０１９５】
次に、図２２は、コード変換／属性変換部２２３Ｃが実行する上記［２］の項目属性変換処理を説明するフローチャートである。
コード変換／属性変換部２２３Ｃは、通信ＤＢ２２１（応答テーブル３５２または入力テーブル３５３）からクライアント・アプリケーション宛のデータ（サーバ・アプリケーション２１０からの送信データ）を取り出すと（Ｓ１４１）、上記応答テーブル３５２または入力テーブルの定義情報（３０３Ｒまたは３０３Ｉ）を参照して、上記取り出したデータの全項目の属性がクライアント・アプリケーション１１０から依頼された属性に一致しているか否か比較する（Ｓ１４２）。
【０１９６】
そして、属性が一致しない項目があれば（Ｓ１４２，不一致）、該項目をクライアント・アプリケーション１１０により依頼された属性に変換し（Ｓ１４３）、変換後のデータを通信手順制御部２０１を介してクライアント・アプリケーション１１０に送信する（Ｓ１４４）。
【０１９７】
一方、上記ステップＳ１４２で上記取り出したデータの全項目の属性がクライアント・アプリケーション１１０から依頼された属性に一致する場合には（Ｓ１４２，一致）直ちに上記ステップＳ１４４の処理を実行する。
【０１９８】
上述した、図２１及び図２２の項目属性変換処理により、サーバ・アプリケーション２１０からクライアント・アプリケーション１１０へデータを送信する場合にも、両アプリケーション２１０，１１０は、それぞれが処理しやすい属性でデータ処理が行える。
【０１９９】
このように、本実施例では、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０に対し、遣り取りするデータ項目属性を規定させない。このことにより、例えば数値の遣り取りに対し、クライアント・マシン１００とデータベースサーバ２００でのアプリケーションで属性が不一致の場合でも遣り取りが可能となる。例えば、数値属性としてＤＥＣＩＭＡＬ属性を使用したサーバ・アプリケーション２１０と数値属性としてＩＮＴＥＧＥＲ属性しかないクライアント・アプリケーション１１０間でのデータの遣り取りが可能となる。
【０２００】
そして、これにより、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０は、処理するデータの各項目の属性をそれぞれの処理に適した型に決定できる。
【０２０１】
図２３は、現在、実行環境＃１で動作しているサーバ・アプリケーションＡをサーバ・アプリケーション名を変更せずに、新しい実行環境＃２で動作させて、新しい業務処理を構築できることを説明する図である。
【０２０２】
本実施例においては、サーバ・アプリケーション２１０の実行環境は通信ＤＢ２２１単位で存在する。これは、通信ＤＢ２２１のサービス定義情報３０１によって、公開サービスと該公開サービスで提供されるデータ処理を実行するサーバ・アプリケーション２１０とが対応付けられているからである。また、クライアント・アプリケーション１１０が通信ＤＢ２２１を使用する（アクセスする）場合、該使用開始はＣＯＮＮＥＣＴ命令で宣言する。一方、使用終了は、ＤＩＳＣＯＮＮＥＣＴ命令で宣言する。このように、ＣＯＮＮＥＣＴ命令の発行により、クライアント・アプリケーション１１０に対して通信ＤＢ２２１がアロケーションされる。
【０２０３】
このような機構となっているため、本実施例では、同一のサーバ・アプリケーション２１０を、複数の実行環境で動作させることが可能である。すなわち、複数の通信ＤＢ２２１の公開サービス情報３０１に同一名で同一のサーバ・アプリケーション２１０を登録できる。
【０２０４】
このため、図２３に示すように、異なる実行環境＃１，＃２で同一のサーバ・アプリケーション２１０を同一名称のまま動作させることが可能になる。すなわち、サーバ・アプリケーションＡを流用して新たな業務処理を構築する際に、該サーバ・アプリケーションＡを別名称にすることなく、同一の名称のまま使用することができる。
【０２０５】
図２４は、クライアント・アプリケーション１１０−１（＃１）が公開サービスＡを使用した業務を行い、クライアント・アプリケーション１１０−２（＃２）が公開サービスＡとＢを使用した業務を処理する場合、クライアント・アプリケーション１１０−１（＃１）とクライアント・アプリケーション１１０−２（＃２）とは共にサーバ・アプリケーションＡに対して通信することが可能なことを示した。
【０２０６】
また、本実施例では、通信ＤＢ制御機構２２０を用いて、クライアント・アプリケーション１１０とサーバ・アプリケーション２１０の動作試験を、それぞれ単独で行うことが可能である。
【０２０７】
すなわち、サーバ・アプリケーション２１０に対しては、通信ＤＢ制御機構２２０をドライバの代替として機能させ、クライアント・アプリケーション１１０に対してはスタブの代替として機能させる。
【０２０８】
クライアント・アプリケーション１１０の動作試験
［１］ クライアント・アプリケーション１１０は、ＳＱＬプログラミング（ＩＮＳＥＲＴ）により通信ＤＢ制御機構２２０の入力テーブル３５１にデータを書き込む。
【０２０９】
［２］ 該データ書き込み後、上記入力テーブル３５１の内容を確認する。
サーバ・アプリケーション２１０の動作試験
［１］ 通信ＤＢ制御機構２００の入力テーブル３５１に予めデータを登録する。
【０２１０】
［２］ サーバ・アプリケーション２１０からＳＱＬ命令（ＳＥＬＥＣＴ）を通信ＤＢ制御機構２００に送信して、上記入力テーブル３５１からデータを取り出し、該データを確認する。
【０２１１】
また、本実施例では、通信ＤＢ制御機構２００に対するアクセスは、一般的なＳＱＬプログラミングの発行と類似した方式で行えるため、市販の表計算ソフトやＤＢアクセスソフト（データベース・アクセス）ソフトを、容易にクライアント・アプリケーション１１０として活用させることができる。
【０２１２】
【発明の効果】
以上、説明したように本発明によれば、以下のような効果が得られる。
クライアント・アプリケーションとサーバ・アプリケーションは、当該公開サービス情報によってその形式が定義されているテーブル（以後、公開テーブルと記述する）に対して、該定義に沿ったデータを挿入または取り出すことによりデータ（メッセージ）の授受を行う。このため、クライアント・アプリケーションとサーバ・アプリケーションの開発は、該公開サービス情報のみを意識して行えばよく、互いに独立して行うことができる。 このため、例えば、公開テーブルのレコードを、データベース・サーバ上の１または複数のデータベース（以後、実データベースと記述する）の１または複数のテーブルの各レコードに属する項目で構成することにより、以下のような効果が得られる。
【０２１３】
クライアント・アプリケーションの作成は、実データベース上に構築されているテーブル（以後、実テーブルと記述する）の形式を意識することなく、当該公開テーブルに対するアクセスのみを意識して行えばよい。そして、サーバ・アプリケーションは、該公開テーブルから取り出すデータを基に、データベースに対するアクセスを行う。
【０２１４】
従って、データベースの構造の変更は、サーバ・アプリケーションのみの修正により対処でき、クライアント・アプリケーションの修正は不要である。
このため、データベースの管理者は、クライアント・アプリケーションを意識することなく、実データベースの構造を変更できる。
【０２１５】
また、利用者に公開する公開テーブルと管理者が管理する実データベース上の実テーブルとを、別々に設計できる。このため、両テーブルを、利用者側、管理者側それぞれにとって最適な形式に設計できる。また、各々のテーブルの設計者を分離することも可能となるので、テーブル設計の負担が軽減される。また、テーブル情報の保全も、それぞれのテーブル設計者が個別に管理できるので、管理も分担可能である。
【０２１６】
公開テーブル単位で利用者のアクセス権を設定することにより、アクセス権の設定が容易になる。すなわち、利用者のデータベースアクセス単位は、公開テーブル単位なので、管理者は、該公開テーブル単位で利用者にアクセス権を設定するだけでよい。また、業務管理者に対するデータベース・サーバ上の実データベースのアクセス権は、利用者とは別個に設定・管理できる。
【０２１７】
クライアント・アプリケーションの１回の公開テーブルへのアクセスで、サーバ・アプリケーションが実データベース上の複数の実テーブルをアクセスすることが可能となるので、クライアント・アプリケーションとサーバ・アプリケーション間でのネットワーク上のトラフィック量が軽減されると共に、業務処理も高速に行えるようになる。
【０２１８】
また、公開サービスの停止や、サーバ・アプリケーションの停止をデータベース・サーバ管理者が制御することが可能になるので、アクセス時間の制限、過負荷制御、業務処理毎の優先度制御などの運用ルールを利用者に委ねることなく、該管理者の裁量で行うことが可能になる。
【０２１９】
リアル通信／ディレイド通信などのデータ処理形態に係わる機能ロジックを、アプリケーション（クライアント・アプリケーションとサーバ・アプリケーション）側に組み込む必要がなくなるので、クライアント・アプリケーションとサーバ・アプリケーション間のインタフェースは互いに通信するデータの形式のみとなり、両アプリケーション間の独立化が図れる。このため、両アプリケーションの生産性が向上する。
【０２２０】
クライアント・アプリケーションとサーバ・アプリケーションのいずれにも、互いに通信するデータの属性変換処理ロジックを組み込む必要がなくなるので、両アプリケーションの生産性が向上する。
【０２２１】
また、本発明をサーバ・アプリケーションに対してはドライバの代替、クライアント・アプリケーションに対してはスタブの代替として機能させることにより、両アプリケーションが揃わなくても、互いに独立に動作試験を行うことができる。
【０２２２】
また、既存の表計算ソフトやデータベースアクセスソフトなどの市販の業務パッケージを、容易にクライアント・アプリケーションとして活用することができる。
【０２２３】
さらに、同一のサーバ・アプリケーションをその名称を変更させずに新しい実行環境で動作させることが可能になるので、既存のサーバ・アプリケーションを新たな業務処理に利用する場合、その構築が容易であり、該サーバ・アプリケーションの修正時のメンテナンスも容易となる。
【図面の簡単な説明】
【図１】 本発明の原理説明図である。
【図２】 本発明の実施例のシステム構成図である。
【図３】 通信データの内部構成を説明する図である。
【図４】 サービス定義情報に設定されるデータ処理形態の動作を説明する模式図である。
【図５】 入力テーブルの構成を説明する図である。
【図６】 通信バッファにキューイングされるデータの形式を説明する図である。
【図７】 データ処理形態応答型の命令とデータの流れとキューイングを説明する図である。
【図８】 応答型（リアル通信）による業務処理の一具体例を示す図である。
【図９】 集信型の業務処理の一例を説明する模式図である。
【図１０】 データベースの更新を説明する図である。
【図１１】 データベースサーバ上のデータベース構造を変更したときの対処方法を説明する図である。
【図１２】 通信データベースに設定されるセキュリティ情報を説明する図である。
【図１３】 通信データベースに接続要求があったときのセキュリティ・チェック処理を説明するフローチャートである。
【図１４】 通信データベースで定義されているテーブルにアクセス要求があったときのセキュリテ ィ・チェック処理を説明する図である。
【図１５】 通信データベース・アクセス処理及び実データベース・アクセス処理を説明するフローチャートである。
【図１６】 過負荷制御の方法を説明する図である。
【図１７】 アクセス時間帯、過負荷制御、及び優先度制御を実現する通信ＤＢ制御機構の動作を説明するフローチャートである。
【図１８】 項目属性変換機構を示す模式図である。
【図１９】 クライアント・アプリケーションからテーブル挿入要求を受信したときの項目属性変換処理を説明するフローチャートである。
【図２０】 サーバ・アプリケーションからテーブルにキューイングされているデータの取り出し要求があったときの項目属性変換処理を説明するフローチャートである。
【図２１】 サーバ・アプリケーションからテーブルへのデータ挿入要求を受信したときの項目属性変換処理を説明するフローチャートである。
【図２２】 クライアント・アプリケーションからテーブルにキューイングされているデータの取り出し要求を受信したときの動作を説明するフローチャートである。
【図２３】 新しい実行環境でクライアント・サーバ関係を構築するとき説明図である。
【図２４】 サーバ・アプリケーションの使い分の他の例を示す図である。
【図２５】 従来のＲＤＡによりデータベース・アクセスを行うクライアント／サーバ・データベースシステムの問題点を説明する図（その１）である。
【図２６】 従来のＲＤＡによりデータベース・アクセスを行うクライアント／サーバ・データベースシステムの問題点を説明する図（その２）である。
【図２７】 従来のＲＤＡによりデータベース・アクセスを行うクライアント／サーバ・データベースシステムの問題点を説明する図（その３）である。
【図２８】 従来のＣ／Ｓアプリ型のデータベースシステムにおける、アプリケーションの動作試験時の問題点を説明する図である。
【図２９】 従来のＣ／Ｓアプリ型のデータベースシステムにおいて、既存のサーバ・アプリケーションを流用して新たな業務処理を開発する場合に発生する問題点を説明する図である。
【符号の説明】
５２ クライアント・アプリケーション
６２ サーバ・アプリケーション
２００ データベースサーバ
２０１ 通信手順制御部
２０２ 利用者認証部
２２０ 通信ＤＢ制御機構（通信制御装置）
２２１ 通信ＤＢ（通信データベース）
２２２Ｃ、２２２Ｓ ＳＱＬ解析制御部
２２３Ｃ、２２３Ｓ コード／属性変換部
２２４ 資源利用認証部
２２５ メッセージキュー制御部
２２６ 通信バッファ
２２８ メッセージ保証制御部
２２９ アプリ起動要求制御部
３０１ サービス定義情報（公開サービス情報）
３０３Ｉ 入力テーブル定義情報
３０３Ｒ 応答テーブル定義情報
３５１、３５３ 入力テーブル
３５２ 応答テーブル
４００ メモリ
４１０ キューノード
４１１ キュー先頭ポインタ
４１２ キュー最終ポンタ
４１３ テーブル情報
５００ セル
５０１ チェイン部
５０２ データ部
Claims (2)
- 業務処理をクライアント・アプリケーションとサーバ・アプリケーションによって実行するクライアント／サーバシステムの該クライアント・アプリケーションと該サーバ・アプリケーション間の情報の授受を制御する通信制御装置であって、
少なくともデータ処理形態とテーブル定義情報と該テーブル定義情報で定義されるテーブルの各項目の属性情報とを含む公開サービス情報を管理する公開サービス情報記憶手段と、
前記テーブル定義情報に基づいて入力テーブルを作成するテーブル作成手段と、
前記入力テーブルに入力されるデータを前記属性情報に従って変換して格納する変換手段と、
前記クライアント・アプリケーションからのＳＱＬを解析してデータを前記入力テーブルに格納する第一のＳＱＬ解析制御部と、
前記入力テーブルにデータが格納された際に前記サーバ・アプリケーションの状態を確認し、前記サーバ・アプリケーションが処理待状態である場合のみ、前記サーバ・アプリケーションに対して起動要求を行うサーバ・アプリケーション起動要求手段と、
前記サーバ・アプリケーションからのＳＱＬを解析してデータを前記入力テーブルから取り出す第二のＳＱＬ解析制御部と、
前記入力テーブルにデータを格納した際に、前記公開サービス情報内のデータ処理形態が応答型あるいはリアル通信による集信型による処理形態である場合には、前記サーバ・アプリケーションからの完了通知を待って前記クライアント・アプリケーションに対して完了通知を行い、前記サービス定義情報内のデータ処理形態がディレイド通信による集信型あるいは配信型による処理形態である場合には、前記サーバ・アプリケーションからの完了通知を待つことなく前記クライアント・アプリケーションに対して完了通知を行うメッセージ応答制御部と、
を有する通信制御装置。 - 前記公開サービス情報提供手段は、公開情報として更に、前記テーブル定義情報で定義されるテーブルの各項目の第二の属性情報を記憶し、
前記入力テーブルから取り出されるデータを前記第二の属性情報に従って変換する第二の変換手段を有する、
請求項１に記載の通信制御装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP12195794A JP3777196B2 (ja) | 1994-05-10 | 1994-05-10 | クライアント／サーバシステム用の通信制御装置 |
| US08/968,477 US5873086A (en) | 1994-05-10 | 1997-11-12 | Communications control apparatus and client/server computer system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP12195794A JP3777196B2 (ja) | 1994-05-10 | 1994-05-10 | クライアント／サーバシステム用の通信制御装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH07306821A JPH07306821A (ja) | 1995-11-21 |
| JP3777196B2 true JP3777196B2 (ja) | 2006-05-24 |
Family
ID=14824098
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP12195794A Expired - Fee Related JP3777196B2 (ja) | 1994-05-10 | 1994-05-10 | クライアント／サーバシステム用の通信制御装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5873086A (ja) |
| JP (1) | JP3777196B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103605355A (zh) * | 2013-12-10 | 2014-02-26 | 贵州电力试验研究院 | 快速远程在线监测汽轮发电机组振动参数的方法及系统 |
Families Citing this family (70)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3178342B2 (ja) * | 1996-06-17 | 2001-06-18 | 松下電器産業株式会社 | ネットワークを利用した情報提供システム |
| US6170017B1 (en) * | 1997-05-08 | 2001-01-02 | International Business Machines Corporation | Method and system coordinating actions among a group of servers |
| US6092197A (en) * | 1997-12-31 | 2000-07-18 | The Customer Logic Company, Llc | System and method for the secure discovery, exploitation and publication of information |
| JP3865483B2 (ja) * | 1997-10-16 | 2007-01-10 | 富士通株式会社 | クライアント・サーバ型のデータベース管理システムおよびそのプログラムを記録した記録媒体 |
| US6058389A (en) * | 1997-10-31 | 2000-05-02 | Oracle Corporation | Apparatus and method for message queuing in a database system |
| US6175832B1 (en) * | 1998-05-11 | 2001-01-16 | International Business Machines Corporation | Method, system and program product for establishing a data reporting and display communication over a network |
| JP3863291B2 (ja) * | 1998-05-28 | 2006-12-27 | 株式会社日立製作所 | データベース処理方法、データベース処理システム及び媒体 |
| US6298347B1 (en) * | 1998-08-25 | 2001-10-02 | Numoda Corporation | System and method for remote data entry |
| AU2322900A (en) * | 1999-01-29 | 2000-08-18 | Degitaldesign, ltd. | Data transmission method, computer-readable medium, and data transmission apparatus |
| US7937364B1 (en) | 1999-03-09 | 2011-05-03 | Oracle International Corporation | Method and system for reliable access of messages by multiple consumers |
| US8335775B1 (en) * | 1999-08-05 | 2012-12-18 | Oracle International Corporation | Versioning in internet file system |
| US6601234B1 (en) | 1999-08-31 | 2003-07-29 | Accenture Llp | Attribute dictionary in a business logic services environment |
| US6640244B1 (en) | 1999-08-31 | 2003-10-28 | Accenture Llp | Request batcher in a transaction services patterns environment |
| US6636242B2 (en) | 1999-08-31 | 2003-10-21 | Accenture Llp | View configurer in a presentation services patterns environment |
| US6954220B1 (en) | 1999-08-31 | 2005-10-11 | Accenture Llp | User context component in environment services patterns |
| US6640249B1 (en) | 1999-08-31 | 2003-10-28 | Accenture Llp | Presentation services patterns in a netcentric environment |
| US7289964B1 (en) | 1999-08-31 | 2007-10-30 | Accenture Llp | System and method for transaction services patterns in a netcentric environment |
| US6615253B1 (en) | 1999-08-31 | 2003-09-02 | Accenture Llp | Efficient server side data retrieval for execution of client side applications |
| US6742015B1 (en) | 1999-08-31 | 2004-05-25 | Accenture Llp | Base services patterns in a netcentric environment |
| US6601192B1 (en) | 1999-08-31 | 2003-07-29 | Accenture Llp | Assertion component in environment services patterns |
| US6578068B1 (en) | 1999-08-31 | 2003-06-10 | Accenture Llp | Load balancer in environment services patterns |
| US6715145B1 (en) | 1999-08-31 | 2004-03-30 | Accenture Llp | Processing pipeline in a base services pattern environment |
| US6640238B1 (en) | 1999-08-31 | 2003-10-28 | Accenture Llp | Activity component in a presentation services patterns environment |
| US6842906B1 (en) | 1999-08-31 | 2005-01-11 | Accenture Llp | System and method for a refreshable proxy pool in a communication services patterns environment |
| US6549949B1 (en) | 1999-08-31 | 2003-04-15 | Accenture Llp | Fixed format stream in a communication services patterns environment |
| US6529909B1 (en) * | 1999-08-31 | 2003-03-04 | Accenture Llp | Method for translating an object attribute converter in an information services patterns environment |
| US6571282B1 (en) | 1999-08-31 | 2003-05-27 | Accenture Llp | Block-based communication in a communication services patterns environment |
| KR20020053814A (ko) * | 1999-09-20 | 2002-07-05 | 이반 충슝 황 | 전자상거래 서비스를 수행하는 시스템 및 방법 |
| US6470350B1 (en) * | 1999-12-15 | 2002-10-22 | Unisys Corporation | Method and system for simulating a database table in response to a database query |
| US6834285B1 (en) | 2000-03-24 | 2004-12-21 | Numoda Corporation | Computer system for portable digital data capture and data distribution |
| US6535871B1 (en) * | 2000-07-24 | 2003-03-18 | Pitney Bowes Inc. | Method for searching a digital rights management package |
| DE10049610A1 (de) * | 2000-10-05 | 2002-04-18 | Alcatel Sa | Netzwerkmanagement-Client |
| EP1271342A1 (en) * | 2001-04-30 | 2003-01-02 | Sun Microsystems, Inc. | Method for accessing database table columns |
| US7233960B1 (en) | 2001-10-31 | 2007-06-19 | Numoda Corporation | System and method for mobile wireless electronic data capture and distribution of a merchant card-processing application |
| US20030172185A1 (en) * | 2002-03-07 | 2003-09-11 | Rockwell Electronic Commerce Technologies, L.L.C. | Method and system for adding text data to data communication sessions |
| US20040064430A1 (en) * | 2002-09-27 | 2004-04-01 | Klein Jonathan D. | Systems and methods for queuing data |
| US7467018B1 (en) * | 2002-11-18 | 2008-12-16 | Rockwell Automation Technologies, Inc. | Embedded database systems and methods in an industrial controller environment |
| US7260599B2 (en) * | 2003-03-07 | 2007-08-21 | Hyperspace Communications, Inc. | Supporting the exchange of data by distributed applications |
| US7346905B2 (en) * | 2003-06-10 | 2008-03-18 | International Business Machines Corporation | Apparatus and method for maintaining resource integrity without a unified transaction manager in a software environment |
| US7636941B2 (en) * | 2004-03-10 | 2009-12-22 | Microsoft Corporation | Cross-domain authentication |
| US7921076B2 (en) * | 2004-12-15 | 2011-04-05 | Oracle International Corporation | Performing an action in response to a file system event |
| US7519601B2 (en) * | 2004-12-17 | 2009-04-14 | Sap Ag | Method and apparatus for implementing recursive remote procedure calls |
| US20060133412A1 (en) * | 2004-12-22 | 2006-06-22 | Rockwell Automation Technologies, Inc. | Integration of control and business applications using integration servers |
| US7706895B2 (en) * | 2005-02-25 | 2010-04-27 | Rockwell Automation Technologies, Inc. | Reliable messaging instruction |
| US7565351B1 (en) | 2005-03-14 | 2009-07-21 | Rockwell Automation Technologies, Inc. | Automation device data interface |
| US7233830B1 (en) * | 2005-05-31 | 2007-06-19 | Rockwell Automation Technologies, Inc. | Application and service management for industrial control devices |
| US7757269B1 (en) | 2006-02-02 | 2010-07-13 | Mcafee, Inc. | Enforcing alignment of approved changes and deployed changes in the software change life-cycle |
| US7895573B1 (en) * | 2006-03-27 | 2011-02-22 | Mcafee, Inc. | Execution environment file inventory |
| US8225311B1 (en) * | 2006-03-30 | 2012-07-17 | Emc Corporation | Deploying and distributing content management code |
| JP4983100B2 (ja) * | 2006-05-31 | 2012-07-25 | 富士通株式会社 | データ差異解消プログラムおよびデータ差異解消装置 |
| US7730478B2 (en) * | 2006-10-04 | 2010-06-01 | Salesforce.Com, Inc. | Method and system for allowing access to developed applications via a multi-tenant on-demand database service |
| US9424154B2 (en) | 2007-01-10 | 2016-08-23 | Mcafee, Inc. | Method of and system for computer system state checks |
| US8332929B1 (en) | 2007-01-10 | 2012-12-11 | Mcafee, Inc. | Method and apparatus for process enforced configuration management |
| US8925101B2 (en) | 2010-07-28 | 2014-12-30 | Mcafee, Inc. | System and method for local protection against malicious software |
| US8938800B2 (en) | 2010-07-28 | 2015-01-20 | Mcafee, Inc. | System and method for network level protection against malicious software |
| JP2012059136A (ja) * | 2010-09-10 | 2012-03-22 | Oki Electric Ind Co Ltd | 業務支援システム、業務支援方法及びプログラム |
| CN102075527A (zh) * | 2010-12-30 | 2011-05-25 | 合肥恒卓科技有限公司 | 一种互联网数据通信系统及其通信方法 |
| US9112830B2 (en) | 2011-02-23 | 2015-08-18 | Mcafee, Inc. | System and method for interlocking a host and a gateway |
| US9167443B2 (en) * | 2011-05-18 | 2015-10-20 | Radius Networks, Inc. | System and method for managing content exchanges in a wireless network using a listener module |
| CN102231213A (zh) * | 2011-06-29 | 2011-11-02 | 哈尔滨工业大学深圳研究生院 | Ecg门禁卡身份识别方法及系统 |
| US9191298B1 (en) * | 2011-08-01 | 2015-11-17 | Google Inc. | Distributed forensic investigation |
| US9594881B2 (en) | 2011-09-09 | 2017-03-14 | Mcafee, Inc. | System and method for passive threat detection using virtual memory inspection |
| US8713668B2 (en) | 2011-10-17 | 2014-04-29 | Mcafee, Inc. | System and method for redirected firewall discovery in a network environment |
| US8739272B1 (en) | 2012-04-02 | 2014-05-27 | Mcafee, Inc. | System and method for interlocking a host and a gateway |
| US9749813B2 (en) * | 2012-12-17 | 2017-08-29 | Radius Networks, Inc. | System and method for associating a MAC address of a wireless station with personal identifying information of a user of the wireless station |
| US8973146B2 (en) | 2012-12-27 | 2015-03-03 | Mcafee, Inc. | Herd based scan avoidance system in a network environment |
| US9400825B2 (en) * | 2013-05-23 | 2016-07-26 | Strategy Companion Corporation | Pivot analysis method using condition group |
| WO2015060857A1 (en) | 2013-10-24 | 2015-04-30 | Mcafee, Inc. | Agent assisted malicious application blocking in a network environment |
| US9442944B2 (en) | 2013-11-12 | 2016-09-13 | Dropbox, Inc. | Content item purging |
| CN103838855A (zh) * | 2014-03-17 | 2014-06-04 | 广东创能科技有限公司 | 余票更新的方法 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4855906A (en) * | 1987-10-23 | 1989-08-08 | Allen-Bradley Company, Inc. | System for handling unsolicited messages from lower-tier controllers |
| JPH0325947U (ja) * | 1989-07-14 | 1991-03-18 | ||
| US5257369A (en) * | 1990-10-22 | 1993-10-26 | Skeen Marion D | Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes |
| US5557798A (en) * | 1989-07-27 | 1996-09-17 | Tibco, Inc. | Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes |
| US5339392A (en) * | 1989-07-27 | 1994-08-16 | Risberg Jeffrey S | Apparatus and method for creation of a user definable video displayed document showing changes in real time data |
| US5265250A (en) * | 1990-03-29 | 1993-11-23 | At&T Bell Laboratories | Apparatus and methods for performing an application-defined operation on data as part of a system-defined operation on the data |
| US5280610A (en) * | 1990-08-14 | 1994-01-18 | Digital Equipment Corporation | Methods and apparatus for implementing data bases to provide object-oriented invocation of applications |
| US5497319A (en) * | 1990-12-31 | 1996-03-05 | Trans-Link International Corp. | Machine translation and telecommunications system |
| US5291416A (en) * | 1991-03-08 | 1994-03-01 | Software Algoritms Incorporated | Event feedback for numerically controlled machine tool and network implementation thereof |
| US5465351A (en) * | 1992-08-14 | 1995-11-07 | Noblenet Inc. | Client-side memory management process for client-server computing |
| US5553235A (en) * | 1992-10-23 | 1996-09-03 | International Business Machines Corporation | System and method for maintaining performance data in a data processing system |
| DE69318571T2 (de) * | 1992-12-01 | 1998-09-17 | Microsoft Corp | Verfahren und system für die in-ort-wechselwirkung mit eingebetteten objekten |
| US5446842A (en) * | 1993-02-26 | 1995-08-29 | Taligent, Inc. | Object-oriented collaboration system |
| US5566069A (en) * | 1994-03-07 | 1996-10-15 | Monsanto Company | Computer network for collecting and analyzing agronomic data |
| US5544354A (en) * | 1994-07-18 | 1996-08-06 | Ikonic Interactive, Inc. | Multimedia matrix architecture user interface |
| US5586312A (en) * | 1994-10-11 | 1996-12-17 | Unisys Corporation | Method and apparatus for using an independent transaction processing application as a service routine |
-
1994
- 1994-05-10 JP JP12195794A patent/JP3777196B2/ja not_active Expired - Fee Related
-
1997
- 1997-11-12 US US08/968,477 patent/US5873086A/en not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103605355A (zh) * | 2013-12-10 | 2014-02-26 | 贵州电力试验研究院 | 快速远程在线监测汽轮发电机组振动参数的方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| US5873086A (en) | 1999-02-16 |
| JPH07306821A (ja) | 1995-11-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3777196B2 (ja) | クライアント／サーバシステム用の通信制御装置 | |
| US11243920B2 (en) | Distributed database system, transaction processing method, lock server and storage medium | |
| US7680793B2 (en) | Commit-time ordered message queue supporting arbitrary read and dequeue patterns from multiple subscribers | |
| US7503052B2 (en) | Asynchronous database API | |
| US7366751B2 (en) | Framework system | |
| US6304873B1 (en) | System and method for performing database operations and for skipping over tuples locked in an incompatible mode | |
| US6397227B1 (en) | Database management system and method for updating specified tuple fields upon transaction rollback | |
| US6339772B1 (en) | System and method for performing database operations on a continuous stream of tuples | |
| US7454516B1 (en) | Scalable virtual partitioning of resources | |
| US6349310B1 (en) | Database management system and method for accessing rows in a partitioned table | |
| US5881315A (en) | Queue management for distributed computing environment to deliver events to interested consumers even when events are generated faster than consumers can receive | |
| US5893128A (en) | Distributed work flow management | |
| US7421440B2 (en) | Method and system for importing data | |
| US20070162421A1 (en) | Real-Time Messaging System for Bridging RDBMSs and Message Buses | |
| JPH035846A (ja) | リモート・アプリケーシヨン実行方式 | |
| US9560123B2 (en) | Using a same program on a local system and a remote system | |
| US6701323B2 (en) | Object management system and method for distributed object system | |
| US7805422B2 (en) | Change notification query multiplexing | |
| US7136859B2 (en) | Accessing heterogeneous data in a standardized manner | |
| US8621010B2 (en) | Method and system for protecting messaging consumers | |
| US20050080759A1 (en) | Transparent interface to a messaging system from a database engine | |
| US20060282460A1 (en) | Method and system for generic data objects | |
| Long et al. | IMS primer | |
| US20200125569A1 (en) | Method and system to implement sql macros | |
| JPH09160847A (ja) | クライアント・サーバ型分散処理システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040106 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040308 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050125 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050325 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060221 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060227 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100303 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100303 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110303 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |