JPH11224226A - クライアント・サーバ間のゲートウェイにおけるインタフェース及びクライアント・サーバ間のプロトコルマッピング方法 - Google Patents

Abstract

(57)【要約】 【課題】 クライアント・サーバゲート・ウェイシステ
ムにおいて、クライアント又はサーバのを変更に伴うゲ
ートウェイシステムの変更が少なくて済むシステムをを
提供する。 【解決手段】 インタフェースには、フロントエンドモ
ジュール４０２、マッピングモジュール４０３及びバッ
クエンドモジュール４０４が含まれる。各フロントエン
ドモジュール４０２は、各クライアント通信プロトコル
を用いて、１又は複数のクライアント４０１への通信パ
スを提供する。バックエンドモジュール４０４は、サー
バ通信プロトコルを用いてサーバ４０５への通信パスを
提供する。マッピングモジュール４０３は、バックエン
ドモジュール４０４が受け取るサーバ通信プロトコルの
通信データ、又はフロントエンドモジュール４０２が受
け取るクライアント通信プロトコルの通信データを、そ
れぞれクライアント通信プロトコルの通信データ、又は
サーバ通信プロトコルの通信データに変換する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ある通信プロト
コルを別の通信プロトコルにマッピングする装置及び方
法に関する。特に、この発明は、クライアントプロトコ
ルとサーバプロトコルとの間のマッピングを行う時に、
クライアントプロトコルまたはサーバプロトコルが修正
されたときの変更を最小限に抑えるゲートウェイアーキ
テクチャ及び方法に関する。

【０００２】

【従来の技術】職場のコンピュータ化が進むに従い、コ
ンピュータ及びコンピュータアプリケーションの数は急
激に増加した。コンピュータの利用は、クライアントと
サーバが含まれたネットワークに見ることが出来る。し
かし、この場合、クライアントが使用する通信プロトコ
ルとサーバが使用する通信プロトコルとが異なると、問
題が発生する。この問題を解決するために、ゲートウェ
イアプリケーションを使用したゲートウェイアーキテク
チャが幾つか考案されている。ゲートウェイアプリケー
ションでは、あるプロトコルの命令、オペレーション、
及び引数を別のプロトコルの命令、オペレーション、及
び引数にマッピング（変換）している。図１は、そのよ
うな従来のゲートウェイアーキテクチャを示している。

【０００３】図１では、ゲートウェイアプリケーション
１０７は、クライアントアプリケーション１０１が使用
する第１のプロトコルＡをサーバアプリケーション１１
０が使用する第２のプロトコルＸに変換し、クライアン
トアプリケーション１０１がサーバ１１０と通信できる
ようにしている。図１に示されているゲートウェイモデ
ルでは、クライアント１０１は通信モジュール１０２、
１０３及びネットワーク１１１を介して、サーバ１１０
への命令及び要求をゲートウェイアプリケーション１０
７に送る。ゲートウェイの通信モジュール１０３は、こ
れらの命令と要求をクライアントプロトコルモジュール
１０４へ中継する。このクライアントプロトコルモジュ
ール１０４は、コマンドとその引数を組み立て、必要な
データ構造体を作成し、ゲートウェイアプリケーション
１０７へ命令を中継する。ゲートウェイアプリケーショ
ン１０７は、クライアントインフラストラクチャモジュ
ール１０６とサーバインフラストラクチャモジュール１
０９とを介して、クライアントインフラストラクチャと
サーバインフラストラクチャに関する情報にアクセスす
る。ゲートウェイアプリケーション１０７は、この情報
を使用してクライアントプロトコルＡからサーバプロト
コルＸへクライアント命令をマッピングし、通信モジュ
ール１０５、１０８及びネットワーク１１２を介して、
変換された命令をサーバ１１０へ渡す。

【０００４】上記で説明した方法では、クライアントの
側からは、ゲートウェイアプリケーション１０７があた
かもサーバ１１０であるかの如く応答しているように見
える。サーバの側からは、ゲートウェイアプリケーショ
ン１０７があたかもクライアントアプリケーション１０
１であるかの如く応答しているように見える。

【０００５】図２はゲートウェイモデル２００の別の公
知例を示しており、図６はこのゲートウェイモデルの処
理シーケンスを説明している。このゲートウェイモデル
２００では、クライアント２０１はクライアントプロト
コルＡに従った命令、オペレーション、及び属性をネッ
トワーク２０６を介してゲートウェイ２００のフロント
エンドモジュール２０２へ送っている（図６の６０
１）。フロントエンドモジュール２０２は、クライアン
トアプリケーション２０１が送信し得るすべてのオペレ
ーションを解釈できる。フロントエンドモジュール２０
２は、クライアントプロトコルＡをデータ構造体とオペ
レーションに変換する。これらのデータ構造体とオペレ
ーションは、フロントエンド２０２とマッピングモジュ
ール２０３との間のインタフェース２０８により定義さ
れたものである。データ構造体とオペレーションが正し
く作成されたら、フロントエンドモジュール２０２はク
ライアントの命令をマッピングモジュール２０３へ渡す
（図６のステップ６０２）。マッピングモジュール２０
３は、データ構造体とオペレーションをマッピングテー
ブルに登録する。これは、図７で説明するコマンド状態
２である。登録が正常に完了したら、フロントエンドモ
ジュール２０２はバックエンド関数ＤｏＯｐ（）を呼び
出し、オペレーションを実行する（図６の６０３）。こ
れは、図７に示しているコマンド状態３である。バック
エンドモジュール２０４は、マッピングモジュール関数
を呼び出し、サーバ側のオペレーションとデータ構造体
を獲得する（図６の６０４）。マッピングモジュール２
０３は、フロントエンドからのオペレーションとデータ
構造体を、対応するサーバ側のオペレーションとデータ
構造体に変換する。これらは、図７に示しているコマン
ド状態４及び５である。次に、マッピングモジュール２
０３はクライアントプロトコルＡのクライアント命令を
サーバプロトコルＸの命令に変換する。これらの命令
は、サーバ２０５のバックエンドモジュール２０４に戻
される。次に、バックエンドモジュール２０４は、フロ
ントエンドモジュール２０２について上記で概説した機
能と同じ機能を、サーバ側について実行する。バックエ
ンドモジュール２０４は、サーバ側のオペレーションの
結果をマッピングテーブルに登録する（図６の６０
５）。これは、図７で説明しているコマンド状態６であ
る。結果がエラーの場合は、結果はエラーフィールドに
登録される。バックエンドモジュール２０４はサーバプ
ロトコル１０６と通信モジュール１０５のクライアント
インタフェースを使用して、実際のサーバ２０５と対話
する。

【０００６】

【発明が解決しようとする課題】これらのゲートウェイ
アーキテクチャはクライアントプロトコルをサーバプロ
トコルへ変換するが、ゲートウェイ１０７または２００
は、与えられたクライアントプロトコルとサーバプロト
コルとの対に固有のものとして設計される。したがっ
て、クライアントプロトコルＡからサーバプロトコルＸ
へのマップを実行するように設計されているゲートウェ
イでは、クライアントプロトコルＡから別のサーバプロ
トコルＹへ、または別のクライアントプロトコルＢから
サーバプロトコルＸへ、マッピングを実行することはで
きない。したがって、システム１００のクライアント側
またはサーバ側のいずれかが変更されると、ゲートウェ
イアーキテクチャを完全に再作成しなければならない。
図３では、このことを説明している。この図では、クラ
イアントプロトコルＡ、Ｂ、またはＣとサーバプロトコ
ルＸ間で変換を実行するために、３つの異なったフロン
トエンドモジュール２０２Ａ〜２０２Ｃと３つの異なっ
たマッピングモジュール２０３Ａ〜２０３Ｃとが必要で
ある。このようなゲートウェイアーキテクチャの再作成
作業には、莫大な時間と費用がかかる。

【０００７】

【課題を解決するための手段】この発明は、クライアン
ト・サーバ・ゲートウェイシステムにおいて、ゲートウ
ェイシステムを全面的に再加工しなくても、クライアン
ト側またはサーバ側を変更することができるシステム及
び方法を提供する。

【０００８】さらに、この発明は、サーバとのインタフ
ェースが変更された場合は、ゲートウェイが新しいマッ
ピングモジュールと新しいバックエンドモジュールだけ
を生成することで、新しいサーバプロトコルへの変換を
サポートできるようにするシステム及び方法を提供す
る。

【０００９】また、この発明は、クライアント・サーバ
・ゲートウェイシステムに新しいクライアントを追加す
る場合、マッピングモジュールとフロントエンドモジュ
ール間のインタフェースには手を加えずに新しいフロン
トエンドモジュールを作成するだけで、新しいゲートウ
ェイを作成でき、新しいクライアントプロトコルとサー
バプロトコル間の変換を容易にすることができるシステ
ム及び方法も提供する。新しいクライアントのフロント
エンドモジュールとマッピングモジュール間のインタフ
ェースに新しい定義が必要な場合でも、フロントエンド
モジュールに新しいインタフェース定義をプラグインす
るだけで新しい定義を簡単に実現できる。この場合、新
しいインタフェースは既存の定義に影響を与えない。

【００１０】さらに、この発明は、マッピングポリシー
が変更された場合、マッピングモジュールを変更するだ
けでゲートウェイの変更を実現できるシステムと方法を
提供する。

【００１１】この発明には、異なる通信プロトコルを使
用する複数のクライアントとサーバ通信プロトコルを使
用するサーバとの間の通信パス（経路）を提供するイン
タフェースが含まれる。このインタフェースは、複数の
フロントエンドモジュール、バックエンドモジュール、
及びマッピングモジュールを含む。フロントエンドモジ
ュールは、各々、複数のクライアント通信プロトコルの
いずれかを用いてそのプロトコルに対応する少なくとも
１つのクライアントに対する通信パスを提供する。バッ
クエンドモジュールは、サーバ通信プロトコルを用いて
サーバへの通信パスを提供する。マッピングモジュール
は、サーバ通信プロトコルを用いてバックエンドモジュ
ールが受信した通信データ、またはクライアント通信プ
ロトコルを使用して各フロントエンドモジュールが受信
した通信データを、それぞれ、複数のフロントエンドモ
ジュールに提供されている異なったクライアント通信プ
ロトコルのいずれかを使用する通信データ、またはバッ
クエンドモジュールに提供されているサーバ通信プロト
コルを使用する通信データに、変換する。

【００１２】

【発明の実施の形態】図４は、この発明に係る基本的な
ゲートウェイモデルを示したものである。このモデルに
は、クライアントアプリケーション４０１（これは、グ
ラフィカルユーザインタフェース（ＧＵＩ）、コマンド
ラインインタフェース（ＣＬＩ）、またはアプリケーシ
ョンプログラミングインタフェース（ＡＰＩ）等のアプ
リケーションであり、プロトコルとしてはクライアント
プロトコルＡを使用する）、クライアントアプリケーシ
ョン４０１と通信するフロントエンドモジュール４０
２、マッピングモジュール４０３、及びサーバアプリケ
ーション４０５（これはサーバプロトコルＸを使用す
る）と通信するバックエンドモジュール４０４が含まれ
ている。マッピングモジュール４０３には、クライアン
トプロトコルとサーバプロトコルとの間の対応づけを行
うためのマッピングテーブルが含まれている。これらの
マッピングテーブルには、固定的なマッピングテーブル
と動的に生成されるマッピングテーブルとがある。固定
的マッピングテーブルは、クライアントとサーバ間のマ
ッピングポリシー（方針）を規定するテーブルであり、
クライアント側とサーバ側との間のオペレーションマッ
ピングリストと属性マッピングリストが含まれる。以下
に説明する動的に生成されるマッピングテーブルは、マ
ッピングオペレーション生成時に生成され、そのオペレ
ーションの破棄時に破棄される。

【００１３】図４に示しているように、この発明のゲー
トウェイモデルは、図１から図３の従来のゲートウェイ
モデルに比べて拡張したインタフェースを、フロントエ
ンドモジュール４０２とマッピングモジュール４０３の
間に設けている。

【００１４】従来のゲートウェイにおけるジョブ処理の
流れは、図６で説明している。従来のゲートウェイで
は、フロントエンドモジュール２０２はオペレーション
とその引数をクライアントから受け取り、フロントエン
ドモジュール２０２とマッピングモジュール２０３の間
のインタフェースの１つである ＣｒｅａｔｅＯｐｅｒ
ａｔｉｏｎ関数６０２の引数にそれらを直接設定してい
る。マッピングモジュール２０３はこれらの引数を受け
取り、図７に示したような動的に生成されるマッピング
テーブルに登録する。この場合、マッピングモジュール
２０３の一部分がフロントエンドモジュール２０２のオ
ペレーションの引数処理に使用されることになるが、そ
の部分は特定のクライアントのプロトコルにだけしか使
用できない。

【００１５】この発明によるジョブ処理の流れを、図８
で説明する。この発明に係るシステム及び方法では、関
数８０１〜８０４を使用してクライアントオペレーショ
ンと引数の構造体を作成した後、フロントエンドモジュ
ール４０２がフロントエンドモジュール４０２とマッピ
ングモジュール４０３との間のインタフェースライブラ
リに含まれるＣｒｅａｔｅＯｐｅｒａｔｉｏｎ関数８０
５を呼び出す。一時的な関数、すなわちＣｒｅａｔｅＨ
ａｎｄｌｅ ８０１、ＳｅｔＦｉｌｔｅｒＮａｍｅ ８０
２、ＳｅｔＡｔｔｒｉｂｕｔｅ ８０３、及びＤｅｓｔ
ｒｏｙＨａｎｄｌｅ ８０４により、クライアント引数
を入れる構造体が作成される。フロントエンドモジュー
ル４０２は、クライアントプロトコルに従って各種印刷
制御データを収集し、記憶する。その際、そのデータを
マッピングモジュール４０３へ送信するために用いるハ
ンドルをインタフェース関数の引数として使用する。こ
の発明では、任意のゲートウェイシステムに適用できる
情報を記憶できるようにしている。このようにして、複
数のクライアントプロトコルについて、フロントエンド
モジュール４０２とマッピングモジュール４０３の間の
共通インタフェースを提供している。

【００１６】この構成では、クライアントアプリケーシ
ョン４０１は、クライアントプロトコルＡを使用しフロ
ントエンドモジュール４０２を介して命令を送り、要求
を受け取る。フロントエンドモジュール４０２は、主
に、クライアントアプリケーション４０１、マッピング
モジュール４０３、及びバックエンドモジュール４０４
の間のプロトコルと通信に関与する。フロントエンドモ
ジュール４０２は、クライアント側の各種情報にアクセ
スできる。これらの情報には、セキュリティに関するラ
イブラリを含むクライアント側のプロトコルスタック、
及び参照ファイルに対するユーザのアクセスについての
認証（クレデンシャル）あるいはアクセスについての認
証が不十分な時に通知を送るための認証等がある。

【００１７】また、フロントエンドモジュール４０２
は、関連するサーバ４０５、サーバオブジェクト、及び
ゲートウェイオブジェクトの名前に関する情報も有して
いる。フロントエンドモジュール４０２には、クライア
ント側のプロトコルに関する情報を十分に持っているの
で、ゲートウェイ４００の構成（コンフィギュレーショ
ン）データベース（不図示）に、適切なサーバ４０５を
登録することができる。

【００１８】フロントエンドモジュール４０２は、クラ
イアント側のイベント通知プロトコルに関する十分な情
報を持っていて、クライアント４０１に通知を配信する
機能をサポートすることができる。フロントエンドモジ
ュール４０２は、適切な通知アドレスをメッセージその
ものと共にマッピングモジュール４０３から受け取る。
サーバが通知サービスを提供している場合、サーバ側の
通知サービス機能は、サーバ側の印刷プロトコルにより
登録されたメッセージを、クライアントに直接送る。つ
まり、フロントエンドモジュール４０２とマッピングモ
ジュール４０３との間のインタフェースには、イベント
通知またはメッセージデリバリ要求をサーバ４０５に登
録するための手段が含まれている。

【００１９】クライアントアプリケーションプロトコル
とサーバプロトコルとの間のマッピング（変換）は、マ
ッピングモジュール４０３で実行される。マッピング
は、クライアント側のオペレーション、オブジェクト、
及び属性をどのようにサーバ側のオペレーション、オブ
ジェクト、及び属性に変換するかを記述している。単純
なオペレーションをマップする場合、マッピングモジュ
ール４０３は、通常、クライアントオペレーションを単
一のサーバオペレーションに変換するだけでよい。この
場合、マッピングモジュール４０３は、クライアントオ
ペレーションをサーバオペレーションに（またはその逆
に）正しく変換するには、クライアント・サーバ間で正
しい情報が受け渡されていることを確認するだけでよ
い。マッピングがさらに複雑でサーバプロトコルのオペ
レーションが単一ではない場合、マッピングモジュール
４０３は状態情報を保存することにより必要なオペレー
ションの順序を管理すると共に、オペレーションが失敗
した場合にはエラー回復処理を実行する。マッピングモ
ジュール４０３は、必要なデータを追跡し、どの時点で
サーバ側の呼出しを実行できるようになったかを判別す
る。

【００２０】マッピングモジュール４０３は、クライア
ント４０１からサーバ４０５への情報の転送あるいはサ
ーバ４０５からクライアント４０１への情報の転送（あ
るいはその両方）を調整する。通常、マッピングモジュ
ール４０３は、送信元及び送信先のアドレスを判別し、
フロントエンドモジュール４０２に送信元とのコネクシ
ョンを生成するのに十分な情報を与え、バックエンドモ
ジュール４０４にサーバとのコネクションを作成するの
に十分な情報を与え、クライアント側またはサーバ側の
うち適切な側に、ゲートウェイ４００を介して情報をや
り取りするための命令を送る。

【００２１】フロントエンドモジュール４０２は、マッ
ピングテーブルのハンドルを入手する。このハンドルに
は、図８で説明したＣｒｅａｔｅＯｐｅｒａｔｉｏｎ関
数８０５を使用してフロントエンドモジュール４０２が
登録したフロントエンドオペレーションと引数に関する
情報が含まれている。フロントエンドモジュール４０２
は、このハンドルを保持し、目標とする動的生成された
マッピングテーブルにアクセスする。フロントエンドモ
ジュール４０２は、ＤｏＯｐ（Ｄｏ Ｏｐｅｒａｔｉｏ
ｎ）関数８０６を呼び出す時、このハンドルをバックエ
ンドモジュール４０４へ渡す。これにより、バックエン
ドモジュール４０４は、上記動的生成されたマッピング
テーブルにアクセスできるようになる。サーバのクライ
アントインタフェースを通してオペレーションをサーバ
４０５へ提出する前に、バックエンドモジュール４０４
は、図８に示されているＧｅｔＤＰＡＯｐｅｒａｔｉｏ
ｎ関数８０７及びＧｅｔＡｒｇｕｍｅｎｔｓ関数８０８
を呼び出す。マッピングモジュール４０３がバックエン
ドモジュール４０４からの要求に従ってサーバ側オペレ
ーションのための引数構造体を作成すると、送信先アド
レスが引数の値として設定される。例えば、アドレス引
数は、論理プリンタ名、及び目標とするサーバが属する
ドメイン名である。サーバ側プロトコルのクライアント
ライブラリでは、送信先アドレスは自動的に決定され
る。

【００２２】したがって、この実施の形態では、マッピ
ングモジュール４０３は、ＣｒｅａｔｅＯｐｅｒａｔｉ
ｏｎ関数８０５により作成されたハンドルが指定してい
るマッピングテーブルだけを管理すればよい。マッピン
グモジュール４０３には、特定クライアントとサーバと
の間のマッピングポリシーを規定する固定的なマッピン
グテーブルを組み込むこともできる。厳密なマッピング
方法は、使用するプロトコルに依存している。この発明
は特定のマッピング方法に依存するものではない。各種
のマッピング方法は、当業者にとっては明白な事項であ
る。したがって、これらのマッピング方法は説明しな
い。

【００２３】この実施の形態では、図５に示されている
ように、異なったクライアントプロトコルＡ〜Ｃを同じ
サーバプロトコルＸとともに使用する時でも、クライア
ントプロトコルＡ〜ＣをサーバプロトコルＸへ変換する
ためには共通のマッピングモジュール４０３だけで十分
である。フロントエンドモジュール４０２Ａ〜４０２Ｃ
とマッピングモジュール４０３とのインタフェースが拡
張されすべてのクライアントプロトコルＡ〜Ｃを処理で
きるようになっているため、新しいクライアントアプリ
ケーション４０１Ｃが追加されても、新しいクライアン
トプロトコルＣを処理するためにマッピングモジュール
４０３を大幅に変更する必要はない。

【００２４】この発明は、クライアントアプリケーショ
ンが、既存の印刷プロトコル、つまり業界で一般的に使
用されているプロトコルを使用する時に特に有用であ
る。既存の印刷プロトコルは、印刷属性、またはリスト
オペレーション、取消しオペレーション、及び修正オペ
レーション等、印刷以外のオペレーションの属性を保存
するための自分自身の構造体を持っていない。これは、
既存の印刷プロトコルは簡素化されたプロトコルである
ためである。既存の印刷プロトコルは上記で説明した印
刷属性を持つことができず、印刷に関する基本的な属性
だけしか提供していない。ゲートウェイのフロントエン
ドモジュール４０２は、既存の印刷プロトコルで提供さ
れていないクライアントのアドレスやクライアントのホ
スト名等の追加情報を必要とする。例えば、ＮｅｔＷａ
ｒｅ（商標）ゲートウェイの場合は、印刷属性すべて
が、ＮｅｔＷａｒｅサーバから送られてくる１組のＮＣ
Ｐ（ＮｅｔＷａｒｅ Ｃｏｒｅ Ｐｒｏｔｏｃｏｌ）パケ
ットにより配信される。ゲートウェイのフロントエンド
モジュール４０２は、これらの属性を収集し保持するた
めの手段が必要である。

【００２５】この実施の形態では、フロントエンドモジ
ュール４０２とマッピングモジュール４０３の間に共通
インタフェースを提供し、そのような印刷属性を保持で
きるようにしている。マッピングモジュール４０３はこ
の共通インタフェースを使用し、複数のクライアント及
びクライアントプロトコルの場合と同様に、クライアン
ト属性を処理する。複数のクライアントをサポートする
ため、フロントエンドモジュール４０２とマッピングモ
ジュール４０３との間のこのインタフェースには、各種
クライアントプロトコルに関するすべての定義が含まれ
る。このことは、インタフェースのサイズの増大につな
がる。

【００２６】この問題を解決するために、この実施の形
態の共通インタフェースは、特定されたクライアントか
らのある特別な要求をサポートするための特別な手段を
用意している。例えば、ＬＰＤプロトコルは、制御ファ
イルを持っており、この点が他の既存の印刷プロトコル
と大きく異なっている。設計段階でこの制御ファイルに
記述されているすべての属性を定義しようとすると、イ
ンタフェースのサイズは増大し、フロントエンドモジュ
ール４０２は制御ファイルの構文解析を実行しすべての
属性をインタフェース構造体に設定しなければならな
い。これは、印刷属性の重複マッピングを引き起こす。
フロントエンドモジュール４０２は制御ファイルから共
通インタフェースへ属性をマッピングしなければなら
ず、マッピングモジュール４０３は共通インタフェース
からサーバ側プロトコルへそれら属性をマッピングしな
ければならない。

【００２７】これらの問題を回避するために、共通イン
タフェースに、特別のインタフェースをプラグインでき
るようになっている。この場合、属性の定義は制御ファ
イルのハンドルに追加される。フロントエンドモジュー
ル４０２は、制御ファイルを示す新しい属性を使用し
て、制御ファイルに含まれる印刷情報をマッピングモジ
ュール４０３に渡すことができる。マッピングモジュー
ル４０３は、この制御ファイルを処理し、新しい属性を
サーバ側属性へ簡単に変換できる。

【００２８】図４に示されているように、この実施の形
態のゲートウェイ４００は、好ましくは、プログラムさ
れた汎用コンピュータで実現される。しかし、ゲートウ
ェイ４００は、専用コンピュータ、プログラムされたマ
イクロプロセッサまたはマイクロコントローラと周辺集
積回路要素、ＡＳＩＣその他の集積回路、ディスクリー
ト回路などのハードウェア電子回路または論理回路、Ｐ
ＬＤ、ＰＬＡ、ＥＧＰＡ、ＰＡＬなどのプログラマブル
論理デバイスでも実現できる。一般的に、図６に示され
ているフローチャートを実行できる有限状態マシンが構
築可能な装置であれば、この発明のゲートウェイを実現
するのに利用できる。

【００２９】以上説明したように、この実施の形態で
は、異なるクライアントプロトコルに対応した複数のフ
ロントエンドモジュール４０２と、マッピングモジュー
ル４０３との間を、共通インタフェースによって媒介す
る構成とした。すなわち、各フロントエンドモジュール
４０２は、各自のクライアントのプロトコル、属性を、
共通インタフェースに従った形式に変換してマッピング
モジュール４０３に渡す。逆も同様であり、フロントエ
ンドモジュール４０２とマッピングモジュール４０３と
の間では、その共通インタフェースを用いてコマンド、
データのやり取りがなされる。このため、マッピングモ
ジュール４０３は、想定した複数のクライアントプロト
コルに対して一つで済むので、マッピングモジュールの
開発の手間が省け、信頼性も向上する。一般に、既存の
印刷プロトコルは、プロトコルの種類が異なっても、利
用しているオペレーションや属性はかなり似通っている
ので、マッピングモジュール４０３を複数の複数のクラ
イアントプロトコルに対応できるようにしたとしても、
その規模はそれほど大きくならず、現実的な規模で実現
することができる。また、サーバ側のプロトコルが変更
された場合、バックエンドモジュール４０４とマッピン
グモジュール４０３をそれに応じて変更するだけでよ
く、各フロントエンドモジュール４０２の変更は必要な
い。また、この実施の形態によれば、システムに新たな
クライアントプロトコルを追加する場合、そのクライア
ントプロトコルと共通インタフェースとの間の変換を行
うフロントエンドモジュール４０２を新たに作成するだ
けでよい。

【００３０】この発明の具体的な実施の形態を説明して
きたが、当業者にとって明らかなように、この発明は上
記実施の形態に限定されるものではなく、様々な代替、
変更、変形が可能である。

【図面の簡単な説明】

【図１】 従来のゲートウェイモデルの一例を示すブロ
ック図である。

【図２】 従来の別のゲートウェイアーキテクチャを示
す図である。

【図３】 従来のゲートウェイアーキテクチャにおいて
クライアントプロトコルを変更するために必要な変更を
説明するための図である。

【図４】 この発明に係るゲートウェイモデルを示す図
である。

【図５】 この発明に係るゲートウェイアーキテクチャ
を示す図である。

【図６】 公知のゲートウェイモデルを使用して第１の
プロトコルを第２のプロトコルに変換する公知の変換方
法の概要を説明するための図である。

【図７】 公知のゲートウェイモデルによるマッピング
テーブルの状態遷移を説明するための図である。

【図８】 この発明による第１のプロトコルから第２の
プロトコルへの変換方法の概要を説明するための図であ
る。

【符号の説明】

４００ ゲートウェイ、４０１ クライアント、４０２
フロントエンドモジュール、４０３ マッピングモジ
ュール、４０４ バックエンドモジュール、４０５ サ
ーバ。

Claims (18)

【特許請求の範囲】
1. 【請求項１】 クライアント・サーバシステムにおい
   て、異なるクライアント通信プロトコルを使用する複数
   のクライアントとサーバ通信プロトコルを使用する１つ
   のサーバとの間の通信パスを提供するインタフェースで
   あって、 各々が複数のクライアント通信プロトコルのいずれかを
   用いてそのプロトコルに対応する少なくとも１つのクラ
   イアントに対する通信パスを提供することができる複数
   のフロントエンドモジュールと、 サーバ通信プロトコルを用いてサーバに対する通信パス
   を提供することができるバックエンドモジュールと、 バックエンドモジュールがサーバ通信プロトコルを用い
   て受信した通信データ、またはフロントエンドモジュー
   ルがクライアント通信プロトコルを用いて受信した通信
   データを、それぞれ、前記クライアント通信プロトコル
   のいずれかを用いた通信データ、または前記サーバ通信
   プロトコルを用いた通信データに変換することができる
   マッピングモジュールと、 を備えるインタフェース。
2. 【請求項２】 請求項１に記載のインタフェースであっ
   て、前記マッピングモジュールは、 前記クライアント通信プロトコルの基本部分と前記サー
   バ通信プロトコルとの間で通信データを変換できる固定
   的変換手段と、 動的に生成及び破棄され、前記クライアント通信プロト
   コルの特定部分と前記サーバ通信プロトコルとを用いて
   通信データを変換できる一時的変換手段と、 を含むことを特徴とするインタフェース。
3. 【請求項３】 請求項２に記載のインタフェースであっ
   て、前記マッピングモジュールは、いずれかの前記クラ
   イアント通信プロトコルの特定部分を用いて前記フロン
   トエンドモジュールから通信データを受け取ると、それ
   に応じて前記一時的変換手段を動的に生成することを特
   徴とするインタフェース。
4. 【請求項４】 請求項２に記載のインタフェースであっ
   て、前記固定的変換手段はすべてのプロトコルに適用さ
   れ、一時的変換手段は特定のプロトコルにだけ適用され
   ることを特徴とするインタフェース。
5. 【請求項５】 請求項１に記載のインタフェースであっ
   て、前記マッピングモジュールにはクライアントのオペ
   レーション及び属性をサーバのオペレーション及び属性
   にマッピングするためのマッピングテーブルを含むこと
   を特徴とするインタフェース。
6. 【請求項６】 請求項５に記載のインタフェースであっ
   て、新しいクライアントがクライアント・サーバシステ
   ムに追加されると、クライアントがそのシステムにプラ
   グインされ、前記クライアント属性が前記マッピングモ
   ジュールのマッピングテーブルに追加されることを特徴
   とするインタフェース。
7. 【請求項７】 請求項１に記載のインタフェースであっ
   て、特定されたクライアント・サーバの対に対応するマ
   ッピングテーブルのハンドルがフロントエンドモジュー
   ルに格納されることを特徴とするインタフェース。
8. 【請求項８】 請求項７に記載のインタフェースであっ
   て、フロントエンドモジュールは、オペレーションを実
   行するときに、特定のクライアント・サーバの対のマッ
   ピングテーブルのハンドルをバックエンドモジュールに
   渡すことを特徴とするインタフェース。
9. 【請求項９】 請求項７に記載のインタフェースであっ
   て、クライアントがフロントエンドモジュールに命令を
   送信する時、フロントエンドモジュールはクライアント
   オペレーションを作成する前に、クライアント引数とハ
   ンドルを作成することを特徴とするインタフェース。
10. 【請求項１０】 クライアント・サーバシステムにおい
    て、異なるクライアント通信プロトコルを使用する複数
    のクライアントアプリケーションとサーバ通信プロトコ
    ルを使用するサーバアプリケーションとの間で通信を行
    うための方法であって、 前記クライアントアプリケーション又はサーバアプリケ
    ーションで要求を開始するステップと、 要求をシステムゲートウェイへ転送するステップと、 前記要求を、クライアント通信プロトコルからサーバ通
    信プロトコルへ、又はサーバ通信プロトコルからクライ
    アント通信プロトコルへマッピングするためのオペレー
    ションを、前記システムゲートウェイでクライアント要
    求またはサーバ要求から作成するステップと、 前記オペレーションを実行するステップと、 前記オペレーションが正常に前記要求をマッピングした
    かどうかを判別するステップと、 マッピングされた要求をクライアントアプリケーション
    またはサーバアプリケーションのうちマッピング先に対
    応するものに転送するステップと、 を含み、 前記システムゲートウェイは、クライアント・サーバの
    各対について、クライアント通信プロトコルとサーバ通
    信プロトコルとの間のマッピングを実行することを特徴
    とする方法。
11. 【請求項１１】 請求項１０に記載の方法であって、前
    記オペレーションを作成するステップには、 クライアントのオペレーションと属性とをサーバのオペ
    レーションと属性とにマッピングし、サーバのオペレー
    ションと属性とをクライアントのオペレーションと属性
    とにマッピングするためのマッピングテーブルのハンド
    ルを判別するステップ、 が含まれることを特徴とする方法。
12. 【請求項１２】 請求項１１に記載の方法であって、新
    しいクライアントをクライアント・サーバシステムに追
    加するとき、クライアントはそのシステムにプラグイン
    され、前記マッピングテーブルにクライアント属性が追
    加されることを特徴とする方法。
13. 【請求項１３】 請求項１０に記載の方法であって、前
    記オペレーションを実行するステップには、 前記クライアント通信プロトコルの基本部分と前記サー
    バ通信プロトコルとの間で、固定的変換手段を用いて通
    信データを変換するステップと、 前記クライアント通信プロトコルの特定部分と前記サー
    バ通信プロトコルを使用して、動的に生成及び破棄され
    る一時的変換手段を用いて通信データを変換するステッ
    プを含むことを特徴とする方法。
14. 【請求項１４】 請求項１０に記載の方法であって、前
    記オペレーションを実行するステップは、 いずれかの前記クライアント通信プロトコルの特定部分
    を用いて前記クライアントアプリケーションのいずれか
    から通信データを受け取ると、それに応じて前記一時的
    変換手段を動的に生成するステップ、 を含むことを特徴とする方法。
15. 【請求項１５】 請求項１３に記載の方法であって、前
    記固定的変換手段はすべてのプロトコルに適用され、前
    記一時的変換手段は特定のプロトコルにだけ適用される
    ことを特徴とする方法。
16. 【請求項１６】 請求項１０に記載の方法であって、前
    記オペレーションを実行するステップには、クライアン
    トのオペレーション及び属性をサーバのオペレーション
    及び属性にマッピングするためのマッピングテーブルを
    使用するステップを含むことを特徴とするインタフェー
    ス。
17. 【請求項１７】 請求項１０に記載の方法であって、前
    記オペレーションを実行するステップには、サーバのオ
    ペレーション及び属性をクライアントのオペレーション
    及び属性にマッピングするためのマッピングテーブルを
    使用するステップを含むことを特徴とするインタフェー
    ス。
18. 【請求項１８】 クライアント・サーバシステムにおい
    て、異なるクライアント通信プロトコルを使用する複数
    のクライアントとサーバ通信プロトコルを使用する１つ
    のサーバとの間の通信パスを提供するインタフェースで
    あって、 複数のクライアント通信プロトコルのいずれかを用いて
    そのプロトコルに対応する少なくとも１つのクライアン
    トに対する通信パスを提供する複数のフロントエンドモ
    ジュールと、 サーバ通信プロトコルを使用してサーバに対する通信パ
    スを提供するバックエンドモジュールと、 バックエンドモジュールがサーバ通信プロトコルを用い
    て受信した通信データ、またはフロントエンドモジュー
    ルがクライアント通信プロトコルを用いて受信した通信
    データを、フロントエンドモジュールが使用するクライ
    アント通信プロトコルの通信データ、またはバックエン
    ドモジュールが使用するサーバ通信プロトコルの通信デ
    ータ、に変換するマッピングモジュールと、 を備え、前記各フロントエンドモジュールと前記マッピ
    ングモジュールとの間を、それら各フロントエンドモジ
    ュールに共通のインタフェース手段により媒介すること
    を特徴とするインタフェース。