【発明の詳細な説明】

【０００１】

【発明の分野】本発明は、ネットワークにおける分散処理用アプリケーションプログラミングインタフェース（ＡＰＩ）に関し、特に、ストリーム指向型プロトコルをメッセージ指向型プロトコルに変換し、クライアントおよびサーバのプラットフォーム間での複数論理接続を単一仮想回路を通じて多重送信するアプリケーションプログラムインタフェースと関連ミドルウェアライブラリとに関するものである。

【０００２】

【発明の背景】現在用いられている通信ネットワークアーキテクチャは、階層化プロトコルアーキテクチャを利用してネットワーク通信を達成するものがほとんどである。 通常、ネットワークアーキテクチャの各層は、階層的な配列をなすように並べられている。 ここで、低位層は、端末ユーザやデータアプリケーションプログラム等のユーザ間やプロセス間に接続を提供すべく機能する。
一方上位層は、ユーザ間やプロセス間で正確なデータ交換を提供すべく機能する。 一般的に、各層はそれら指定機能を実行すべくそれぞれ異なるプロトコルを利用する。

【０００３】図１は７層アーキテクチャを利用し、開放型システム間相互接続（ＯＳＩ）参照モデルとして知られる共通階層型アーキテクチャを示す。 このアーキテクチャは、中間ノードを備えたデータアプリケーションＸ
およびＹ間の論理接続を表している。 両端ノードにおいて、情報は７層すべてを通り抜けるが、一つ、もしくはいくつかの中間ノードにおいて、情報は下位の３層だけを通過する。 また、図１は対応する層間のピアツーピア（等価層同士の）コミュニケーションも示している。

【０００４】下位３層、すなわち物理層、データ回線層およびネットワーク層が、ユーザ間に透過接続を提供し、主として一ホップづつ(hop-by-hop)で動作し、ノード間の個々のデータ回線を通じてコミュニケーションを処理する。 また上位３層、すなわちアプリケーション層、プレゼンテーション層およびセッション層は、情報が適切なフォーマットで転送されるのを請け負う。 中間層、すなわちトランスポート層は上位および下位層間のインタフェースであり、データアプリケーション間の透過エンドツーエンド論理接続を確保する。

【０００５】図２は階層型アーキテクチャの他の例を示すもので、ＤｏＤ参照モデルとして知られる。 このＤｏ
Ｄ参照モデルは４層のアーキテクチャを利用するもので、広い範囲で相違が見られる異種ホストコンピュータ用に開発されたものである。 これら異種ホストコンピュータは、それぞれ通信プロセッサを経由して通信サブネットワークに結びつけられている。 上記通信プロセッサは、インタフェースメッセージプロセッサ（ＩＭＰ）
と、通信サブネットプロセッサ（ＣＳＮＰ）とを備えている。 ＤｏＤ参照モデルの４つの層は、それぞれネットワークアクセス層、インターネット層、ホスト・ホスト層、およびプロセス・データアプリケーション層である。

【０００６】上述したアーキテクチャを利用するおびただしい数の通信ネットワークが、現在世界の至る所で使用されている。 そのようなネットワークは、ビルやキャンパスへ個別に情報を提供するローカルエリアネットワークから、世界にまたがるワイドエリアネットワークにまで及んでいる。 これらネットワークのいくつかは特定アプリケーション専用のものであり、その他のものは、
クライアント／サーバアプリケーションでの資源共用等、遠隔値で各種機能にアクセスすべく主に使用される。 このようなネットワークにおいては、ＵＮＩＸ，Ｖ
ＡＸ／ＶＭＳ，ＤＯＳ／ＷＩＮＤＯＷＳ（以上登録商標、以下同）等、それぞれ異なるオペレーティングシステムを使用する多数のプラットフォームがあり、それに伴い、ＴＣＰ／ＩＰ，ＤＥＣｎｅｔ，ＡＰＰＣ／ＬＵ
６．２（以上登録商標、以下同）等、それぞれ異なるネットワークプロトコルが存在する。 その結果、複数のプロバイダ、複数のプロトコル環境でのデータアプリケーション間で均一な分配処理を達成するのが困難となる。
したがって、プロバイダプラットフォーム間での相互操作性を提供するために、端末エミュレーション、ゲートウェイ、およびバッチファイル転送等の方法論が用いられてきた。 しかしながら、上記方法論では、均一な接続を同等アプリケーション間に提供することができず、ユーザ集約型となる。

【０００７】また、プラットフォーム間の相互操作性を向上すべくある種のインタフェースを用いる方法もとられてきた。 例えば、トランスポートレベルインタフェース（ＴＬＩ）やソケットインタフェースがクライアント・サーバ間アプリケーションで利用されている。 これらのインタフェースは、ネットワークアプリケーションをそれぞれ独立して移送させる機能セットをなしている。
しかしながら、上記インタフェースはバイト指向型ストリームモードでデータを転送するネットワークプロトコルを利用するので、遠隔地に存在する同一データアプリケーションと通信するのに、局所データアプリケーションごとに個別の仮想回路を作成しなければならない。 さらに、各データアプリケーションは、かなり多く作成される可能性がある仮想回路を管理する必要が生じるので、ネットワーク通信管理のために、各データアプリケーションごとに割り当てられるＣＰＵのサイクル時間を拡大しなければならない。 大規模なクライアント・サーバ間アプリケーションにおいては、上記インタフェースでは、クライアントおよびサーバ双方のプラットフォームに課せられる負担を減らし、確立されたおびただしい数の仮想回路を管理することができない。 さらにまた、
上記インタフェースは概してユーザに優しい設計がなされておらず、プラットフォームの相互操作性を達成するためには熟達したプログラマーが必要となる。

【０００８】上記のような経緯から、異なるプロバイダのプラットフォームに属し、複数のプロトコルの様々な階層ネットワークインフラストラクチャを利用するデータアプリケーション間で分配アプリケーションの相互操作性を提供するために、アプリケーションプログラミングインタフェースおよび関連メッセージ指向型ミドルウェアが開発されてきた。 メッセージ指向型ミドルウェアはアプリケーションプログラミングインタフェース（Ａ
ＰＩ）の一層をなし、それぞれのデータアプリケーションとネットワークインフラストラクチャとの間に属し、
均一な接続を同等なアプリケーション同士間に提供するものである。

【０００９】メッセージ指向型ミドルウェアの一例としては、米国マサチューセッツ州ニーダムのHorizon Stra
tegies社製のメッセージ・エクスプレス・インタフェースがあげられる。 このメッセージ・エクスプレス・インタフェースは、標準プロバイダＡＰＩとビジネス（あるいはデータ）アプリケーションとの間に常駐するものであり、標準プロバイダＡＰＩと双方向で情報を交換し、
標準プロバイダＡＰＩがビジネスアプリケーションに伝えるエラー状態を解決するものである。 しかしながら、
このメッセージ・エクスプレス・インタフェースは、現行ネットワークトポロジーを利用しているので、アプリケーションおよび伝送制御プロトコル（ＴＣＰ）等のバイト指向型プロトコルごとに専用の仮想回路が必要となる。

【００１０】さらに、データアプリケーションの開発の間にも、プログラマーは、ネットワークエラー、同等プロセス同士のエラー、あるいはデータ無しアプリケーション等、他の問題を頻繁に解決しなければならない。 そして、これらの問題を訂正するうちに、データアプリケーションプログラムは、データアプリケーションの開発、検査および保全を困難にするシステムレベルサービスに侵害されて穴だらけになる。

【００１１】それゆえ、クライアントおよびサーバのプラットフォーム間に常駐するクライアント・サーバ間アプリケーションプログラミングインタフェースに対しては、クライアントおよびサーバのプラットフォーム上のアプリケーション間に透過トランスポートを提供しながら、複数プラットフォームおよび複数プロトコルの相互操作性を高めると共に、クライアントおよびサーバ双方のプラットフォームの要請する仮想回路管理を著しく軽減することが求められる。

【００１２】

【本件発明の概要】本発明は上記従来の問題を除去するためになされたものであり、クライアントおよびサーバのアプリケーション間での通信独立トランスポートに備えるアプリケーションプログラムインタフェースを提供する。 このアプリケーションプログラムインタフェースは、論理的にサーバアプリケーションと接続された複数のクライアントアプリケーション間に単一仮想回路を確立する手段を有している。 クライアントアプリケーションはクライアントプラットフォーム上に常駐しており、
サーバアプリケーションはそこから離れた位置にあるサーバプラットフォームに備わっている。 また、このインタフェースは、仮想回路上でクライアントおよびサーバのアプリケーション間データ通信を多重化すると共に、
伝達されたデータを分離する手段をも有している。 ネットワークに基礎を置く典型的なデータ通信はバイトストリーム指向型プロトコルにあり、それゆえ多重送信のために、データ通信を多重化および分離化する手段としては、バイトストリームモードでデータをメッセージ指向型データパケットに変換するものが好ましい。 クライアントアプリケーションがデータか情報をサーバアプリケーションに要請したことの確認は、各クライアントアプリケーションに割り当てられた識別コードや識別番号によって与えられる。 この識別コードはメッセージパケットに含まれている。

【００１３】本発明の一実施例において、単一仮想回路を確立する手段は、インタープロセス通信に基礎を置く仮想回路を提供すべく設計された第一のインタフェースと、インターネットワークに基礎を置く仮想回路を提供すべく設計された第二のインタフェースとを備えている。

【００１４】また本発明は、クライアントおよびサーバのアプリケーション間通信用ネットワークを提供する。
この通信ネットワークは、サーバアプリケーションと通信ブローカとを常駐するサーバプラットフォームと、該サーバプラットフォームと論理的に接続された少なくとも一つのクライアントプラットフォームとを備えている。 この少なくとも一つのクライアントプラットフォームは、少なくとも一つのクライアントアプリケーションと通信ブローカとを内在している。

【００１５】上記通信ブローカは、アプリケーションに対して透過性を有するネットワーク通信路を両アプリケーション間に提供すべく、クライアントおよびサーバのアプリケーション間に備わっているのが好ましい。 上記通信路を設け、単一仮想回路上のアプリケーション間でデータ通信を多重化することにより、仮想回路管理が軽減される。 これらの機能を達成するために、上記少なくとも一つのクライアントアプリケーションとサーバアプリケーションとの間に単一仮想回路を確立する手段と、
該単一仮想回路上の両アプリケーション間にデータ通信を多重化すると共に分離化する手段とを備えるべく、両通信ブローカは設計される。

【００１６】さらに、ポイントツーポイント走行ルート等の個別走行情報や、局所的な交通渋滞および天候等の一般走行情報をクライアント（例えば顧客）が得られるようにする走行車情報サービスネットワークも提供される。 この走行車情報ネットワークは、データ収集プラットフォームと論理的に接続され、その間でデータを転送すべく構成された少なくとも一つの情報プロバイダと、
該データ収集プラットフォームから走行データを受信すべく設計されたサーバプラットフォームと、サーバプラットフォームと論理的に接続された少なくとも一つのクライアントプラットフォームとからなる。 サーバプラットフォームは、サーバアプリケーションと通信ブローカとを内在している。 また、少なくとも一つのクライアントプラットフォームは、少なくとも一つのクライアントアプリケーションと通信ブローカとを内在している。

【００１７】さらにまた、本発明は、クライアントおよびサーバのアプリケーション間のデータ通信接続方法を提供する。 該方法は以下のステップを含んでいる。 すなわち、複数のクライアントアプリケーションとサーバアプリケーションとの間に単一仮想回路を確立し、複数のクライアントアプリケーションからのバイトストリームデータをメッセージパケットに変換し、該メッセージパケットを単一乾燥回路上へ多重送信してサーバアプリケーションに転送する。 メッセージパケットがサーバアプリケーションに転送されると、サーバアプリケーションはこのメッセージパケットを分離し、バイトストリームデータに変換する。

【００１８】

【詳細な記述】本発明は、ミドルウェアライブラリと双方向で情報を交換するアプリケーションプログラムインタフェース（ＡＰＩ）を提供するものであり、ネットワークに基礎を置くデータアプリケーションからシステム指向型サービスを抽出し、該ネットワーク基盤のデータアプリケーションの開発を簡略化する。 このネットワーク基盤のデータアプリケーションの簡略化によって、システム開発者は、高品質のデータアプリケーションプログラムを商品化するのに要する開発とテスト時間を縮小することができる。

【００１９】図３は複数プラットフォーム型クライアントおよびサーバ間通信アーキテクチャ１０を示すもので、サーバプラットフォーム１４とそれぞれ異なるクライアントプラットフォーム１６および１８との間に通信ブローカ１２が用いられている。 この通信ブローカ１２
はＡＰＩとその関連ミドルウェアライブラリとを備えている。 また、ＡＰＩは二つの構成要素を有している。 その第一の要素は、図３ではインタフェースＡとして示され、クライアントまたはサーバのアプリケーションインタフェースに対する通信ブローカである。 第二の要素は同図でインタフェースＢとして示され、通信ブローカインタフェースに対する通信ブローカである。

【００２０】このＡインタフェース構成要素は、クライアントアプリケーション２０と通信ブローカ１２との間に、インタープロセス通信（ＩＰＣ）に基礎を置く仮想回路を提供する。 Ａインタフェースは、ＩＰＣ通信サービスをアプリケーションから抽出し、再使用可能なミドルウェアライブラリモジュール（以下、「ＩＰＣモジュール」と称す）にそれらを格納するために設けられている。 このＩＰＣモジュールは通信ブローカ１２に内在するものである。 そして、Ａインタフェース構成要素の原形式としては以下のものが含まれる。

【００２１】(1) (int) ipc ref =ipc server init
((long) network address) (2) (int) ipc ref ipc client init ((long) network address) (3) (int) status =ipc write ((char*) buf, (int) b
uf length, (int) ipc ref) (4) (int) status =ipc read ((char**) buf, (int*)
buf length, (int) ipc ref) (5) (int) status = ipc close ((int) ipc ref)

【００２２】また、Ｂインタフェース構成要素は、伝送制御プロトコルおよびインターネットプロトコル（ＴＣ
Ｐ／ＩＰ）に基礎を置く通信ブローカ１２間の仮想回路等、インターネットワーク基盤の仮想回路を提供する。
このＢインタフェースは、ネットワーク通信サービスをアプリケーションから抽出し、再使用可能なミドルウェアライブラリモジュール（以下、「ネットワークモジュール」と称す）にそれらを格納するために設けられている。 このネットワークモジュールもまた通信ブローカ１
２に内在するものである。 Ｂインタフェース構成要素の原形式としては以下のものが含まれる。

【００２３】(6) (int) net ref =net server init
((long) network address) (7) (int) net ref =net client init ((long) netw
ork address) (8) (int) net ref =net write ((char*) buf, (int)
buf length, (int) net ref) (9) (int) status =net read ((char**) buf, (int*)
buf length, (int) net ref) (10) (int) status = net close ((int) net ｒｅ
ｆ）

【００２４】原形式（１）および（６）はサーバアプリケーション通信を初期化する。 すなわち、これらはサーバエンドポイント初期化を実行し、クライアントの接続要請を聴取するようにサーバアプリケーションに命じる。 原形式（２）および（７）はクライアントアプリケーション通信を初期化する。 すなわち、これらはクライアントエンドポイント初期化を実行し、サーバアプリケーションとの仮想回路を確立する。

【００２５】次に、原形式（３）および（８）は通信書き込み機能であり、クライアントアプリケーションでは要請をサーバアプリケーションに送るために利用され、
サーバアプリケーションでは応答をクライアントアプリケーションに送るために利用される。 また、原形式（４）および（９）は通信読み出し機能であり、サーバアプリケーションではクライアントアプリケーションからの要請を読み出すために利用され、クライアントアプリケーションではサーバアプリケーションからの応答を読み出すために利用される。 原形式（３）および（４）
においては、特定アプリケーションプロトコルによってバッファメッセージが定義された完全なデータユニットを包含している。

【００２６】そして、原形式（５）および（１０）は仮想回路閉鎖機能であり、クライアントおよびサーバのアプリケーション間の仮想回路を作動停止とする。 これらＡＰＩの構成要素を利用することによって、ネットワークトランスポートおよびインタープロセス通信は、上記トランスポートを要するクライアントおよびサーバのアプリケーションに対して透過性を有するものとなる。 図４はネットワーク通信モデルを示し、このネットワーク通信モデルは、上述したＡおよびＢインタフェース構成要素によって、すなわち本発明のＡＰＩによって、クライアントおよびサーバアプリケーション間で透過トランスポートを実行するものである。

【００２７】これら原形式に関連するミドルウェアは、
各通信ブローカ内部のミドルウェアライブラリに格納されている。 付属のＡは各原形式に関連した所望の機能を実行するコードを表す。

【００２８】上述したように、従来のネットワークはバイト指向型ストリームモードにおけるトランスポートデータに対して仮想回路プロトコルを利用するのが一般的である。 また上記で述べたように、これらプロトコルは、遠隔地にある同一サーバアプリケーションとの通信に際し、局所クライアントアプリケーションごとに個々の仮想回路を確立するよう要請する。 それゆえ、幅広いスケールのクライアントおよびサーバアプリケーションに対しては、クライアントごとの仮想回路管理が、クライアントおよびサーバのプラットフォーム資源双方に殺到してしまう。

【００２９】図３に関して、本発明の通信ブローカは、
単一仮想回路上、複数のクライアントアプリケーション２０ａ〜２０ｘ、もしくは２０ｂ〜２０ｙと、サーバアプリケーション２２との間で通信データを多重送信すると共に、その伝達されたデータを分離するように設計されている。 図示されたように、各クライアントプラットフォーム１６もしくは１８は、関連する複数のクライアントアプリケーションを有しており、それらはプラットフォーム１６用アプリケーション２０ａ〜２０ｘとして、またはプラットフォーム１８用アプリケーション２
０ｂ〜２０ｙとして識別される。 そして、アプリケーション間のデータ通信を多重化することによって、クライアントおよびサーバのプラットフォーム上に課せられる時間割り付けを軽減し、複数のクライアントプラットフォームとサーバプラットフォーム間で仮想回路を管理する。

【００３０】論理接続を多重化するために、通信ブローカはバイトストリーム指向型プロトコル（ＴＣＰ等）をメッセージ指向型フォマットに変換する。 この機能は、
原形式および上述した関連ミドルウェアライブラリの読み書きによって実行される。 なお、通信ブローカ動作のより詳細な説明は後述する。

【００３１】クライアントおよびサーバアプリケーション間での多重化通信の一例は、図３に関して以下に説明する。 局所クライアントプラットフォーム１６に関連したクライアントアプリケーション２０ａと、遠隔サーバプラットフォーム１４上の遠隔サーバアプリケーション２２との間で通信を開始するために、クライアントアプリケーション２０ａが、例えば、目的とする遠隔サーバアプリケーション２２用のアドレッシング情報を有するｎｅｔ client init（） 機能コールを出す。 この要請は、インタフェースＡを通じ、インタープロセス通信（ＩＰＣ）を経由し、クライアントプラットフォーム通信ブローカ１２によって処理される。 始めに、通信ブローカ１２は、仮想回路がクライアントとサーバのアプリケーション間に存在するかどうかを判断する。 局所プラットフォーム上の通信ブローカがその局所クライアントアプリケーションと遠隔サーバアプリケーションとの間に仮想回路を生成させる場合、通信ブローカはその接続を接続テーブルに記録する。

【００３２】通常、接続テーブルエントリーは、仮想回路の遠隔ネットワークアドレスと、該仮想回路のデータを読み書きするのに用いられるソケット記述子と、いくつの論理接続が該仮想回路を使用しているかを示す論理接続（または回線）カウントとからなる。 それゆえ、通信ブローカ１２が仮想回路をＡおよびＢインタフェース上に生成させる前に、通信ブローカは要請のあった論理接続と接続テーブルに記録された接続とを比較し、仮想回路が局所アプリケーションおよび目的の遠隔アプリケーション間に存在するかを判断する。 仮想回路が存在するなら、通信ブローカはソケット記述子を通信用テーブルで利用し、回線カウントを一増分ふやす。 仮想回路が存在しない場合には、それを仮想回路を生成し、その接続が接続テーブルに記録される。 この例では、回線カウントが１に初期化される。 図５は、仮想回路を確立するための上記接続テーブル処理の流れを示している。

【００３３】仮想回路が存在するか、あるいはアプリケーション間に仮想回路が生成されると通信ブローカが判断すれば、局所クライアントプラットフォーム１６上の通信ブローカ１２は次に利用可能な論理チャネルＩＤを局所クライアントアプリケーションのＡインタフェースに割り当てる。 そして、Ａインタフェースから出ていくメッセージが論理チャネルＩＤに当てがわれ、Ｂインタフェースから入ってくるメッセージが論理チャネルＩＤ
によって対応する局所アプリケーション２２ａに急送される。 論理チャネルＩＤテーブルは、仮想回路両側の通信ブローカで維持され、多重化送信およびデータ分離動作を可能にする。

【００３４】局所クライアントアプリケーション２０ａ
が、遠隔サーバアプリケーションとの仮想回路接続をもはや必要としない場合には、局所クライアントアプリケーション２０ａが、クライアントプラットフォーム通信ブローカ１２によって処理されるnet close（）機能コールを出す。 これは、仮想回路を使用するための、両プラットフォーム間論理接続テーブルで解放され用いられる論理接続ＩＤをもたらす。

【００３５】さらに、通信ブローカは回線カウンタを一増分ふやす。 ここで、仮想回路を用いる論理回路が他にない場合には、すなわち、回線カウンタが減分されて０
になる場合には、仮想回路は閉じられ、通信ブローカごとに接続テーブルから取り除かれる。 図６は、仮想回路を閉じるための上記接続テーブル処理の流れを示している。

【００３６】 書き込み制御フロー情報を遠隔サーバアプリケーション２２に移送するために、局所クライアントアプリケーションは、メッセージ（該情報）とメッセージ長を有するネットワークパケットとを生じる。 このメッセージには、アプリケーションプロトコルに基礎を置くデータユニットが含まれている。 そして、局所クライアントアプリケーションは、例えば、Ａインタフェースを通じ、インタプロセス通信（バイトストリーム指向型プロトコル等）を経由してネットワークパケットを送出させるnet write（） 機能を呼びだす。 クライアントプラットフォーム１６上に常駐する通信ブローカ１２は、ネットワークパケットを処理し、バイトストリームデータをメッセージ指向型データフォーマットに変換する。 ここで、送信されるメッセージが、移送機構、すなわちインタフェースＢによって保持される最大セグメントサイズよりも大きい場合に、通信ブローカはメッセージを最大セグメントサイズ−２
（バイト）ごとに分ける。 分けられた各断片は、１バイト論理チャネルＩＤと次に予想される１バイトシーケンス番号とで事前に未決事項として処理される。 そして、
シーケンス中最後のパケットは次に予想されるシーケンス番号０が付与される。 ここで、このシーケンス番号０
は、もやは予想されるセグメントがないことを示している。 そして、一トランスポートセグメントのバイパス分割と、次に予想されるシーケンス番号とに適合するメッセージは０に設定される。 従って、論理チャネルＩＤあるいは次に予想されるシーケンス番号により多くのスペースを割り当てることにより、同時接続する任意番号に備えた任意サイズのメッセージを保持することができる。

【００３７】 読み出し制御フロー情報を遠隔サーバアプリケーション２２から読み出すために、局所クライアントプラットフォーム１６における通信ブローカ１２は、単一仮想回路、すなわちＢインタフェース上のネットワークパケットを読み込み、論理接続ＩＤによってソートする。 そして、通信ブローカ１２
は、論理チャネルＩＤおよびシーケンス番号を取り除き、次に予想されるシーケンス番号０を伴うパケットが受信されるまで、その断片をバッファメモリに格納する。 最後のパケットが受信されバッファメモリに格納されると、現在バッファに存在する断片を維持すべくメッセージメモリの一ブロックが割り当てられる。 そして、
バッファ中の完全なメッセージは、局所クライアントアプリケーション（アプリケーション２０ａ〜２０ｘ、または２０ｂ〜２０ｙ等）に転送され、Ａインタフェースを経由して論理接続ＩＤによって識別される。 このメッセージは、例えば、局所クライアントアプリケーションによって開始されるnet read（）機能によって検索される。

【００３８】本発明に係わるＡＰＩのＡおよびＢインタフェース構成要素に加え、他の公知インタフェースもネットワークを完成するのに利用することができる。 図３
に示すように、インタフェースＣとして示されたデータ収集インタフェースへの情報プロバイダと、インタフェースＤとして示されたサーバアプリケーションインタフェースへのデータ収集インタフェースとがホスト側のインタフェースとして設けられる。

【００３９】Ｃインタフェースは、データ収集プラットフォーム２６に常駐するデータ収集アプリケーション２
４に、走行および天候情報プロバイダ等、様々な情報プロバイダ２８および３０からデータを移入する。 このＣ
インタフェースとしては、ダイヤル回線を通して、組織化されていないデータファイルを転送する１Ｋ−Ｘモデムエラー訂正ファイル転送プロトコル等、公知のファイル転送プロトコルが利用できる。 適当なプロトコルの一例としては、ウインドズ用ＰＲＯＣＯＭＭ ＰＬＵＳ
（登録商標）があり、これは、データ収集プラットフォーム２６にインストールされる市販ソフトウェアパッケージである。

【００４０】再び図３に関して説明すると、Ｄインタフェースは、情報プロバイダデータをデータ収集アプリケーション２４からサーバアプリケーション２２に転送する。 このＤインタフェースは、ＴＣＰ／ＩＰプロトコルスタック状態でデータファイルを転送するネットワークファイルサービス（ＮＦＳ）から成るのが好ましい。 適当なインタフェースの一例としては、ウィンドウズ用カメレオンＮＦＳがあり、これもまたデータ収集プラットフォーム２６にインストールされる市販ソフトウェアパッケージである。

【００４１】ＣおよびＤインタフェース間のリンケージはデータ収集アプリケーションによって提供され、ＰＲ
ＯＣＯＭＭ ＰＬＵＳ（登録商標）環境に内包される１
０ライン・ウィンドウズ・アスペクトスクリプトであるのが好ましい。 このアスペクトスクリプトは、ファイル転送の間に、データ収集プラットフォーム上に入ってくるデータファイルの衝撃を和らげ、ファイル転送が完了すると、そのファイルは、サーバプラットフォーム１４
上のファイルシステムに対応するネットワークファイルサービスによって支援された仮想ドライブにコピーされる。

【００４２】他の実施例においては、図７に示すように、Ｄインタフェースが、ＡおよびＢインタフェース、
そして対応する通信ブローカ１２と取り替え可能となる。 その場合、ＡおよびＢインタフェース、そして通信ブローカ１２は上述したように動作し、クライアントおよびサーバアプリケーション間に透過性を有するネットワーク通信を提供するだけでなく、単一仮想回路上での通信を多重化し、分離化する。 図示されたクライアント・サーバ間アプリケーションは、交通渋滞および天候データのサーバ２９および３１と、複数ユーザクライアントプラットフォーム１６および１８と、インタフェースＡおよびＢ等の複数リアルタイムデータフィードとから成る走行車情報サービス（ＴＩＳ）である。 この走行車情報サービスは、ユーザ（クライアント）に個別（通勤区間走行情報等）および／または一般走行記録（局所交通渋滞や天候等）を供給する。 ＴＩＳ用のネットワークアーキテクチャは、図３に示し上述したネットワークアーキテクチャと同様である。

【００４３】動作中、交通渋滞データおよび天候データは、情報プロバイダ３２および３４により、Ｃインタフェースを経由して対応するデータ収集プラットフォーム２６および２７にそれぞれ転送される。 そして、これら交通渋滞および天候のデータは、Ｄインタフェースにのり、サーバプラットフォーム１４上に常駐するＴＩＳサーバアプリケーションに転送され、公知の値加算処理技術を用いて分割され再結合されてＴＩＳプラットフォームデータベース３６に格納される。 値加算処理は、個別走行車の記録、あるいはクライアントの要請に応じたサーバプラットフォームからクライアントへの情報の送信を容易にする。

【００４４】図４および図８に関して、ＴＩＳネットワークの動作を、上述した原形式（１）および（６）と、
クライアント要請の聴取とによって初期化されるサーバプラットフォーム１４で説明する。 走行者の記録を検索すべく、クライアントは、公知のダイヤルイン、あるいはＴ１／ＩＳＤＮアクセス手法を経由してＴＩＳクライアントアプリケーション２０ａにアクセスし、走行および／または天候データを要請する。 ＴＩＳクライアントアプリケーション２０ａは、例えば、目的とする遠隔アプリケーションに向けたアドレッシング情報をネットワークパケット（バイトストリームデータ等）に挿入し、
インタプロセス通信経由でデータをＡインタフェースに送出させるipc client init（） 機能コールを出してネットワーク要請をする。 局所クライアントプラットフォーム１６の通信ブローカ１２は、局所クライアントプラットフォーム１６で局所アプリケーションネットワーク要請を処理し、仮想回路接続テーブルをチェックして仮想回路が局所クライアントアプリケーション２０ａおよび遠隔サーバアプリケーション２２間に存在するかどうかを判断する。 仮想回路が存在しないなら、 int net ref = net client init ((long)network
address) の原形式をＢインタフェースを通して出すことによって仮想回路を生成させる。

【００４５】仮想回路が確立されると、局所プラットフォーム１６の通信ブローカ１２はデータ書き込み原形式（すなわち、int net ref = net write ((char*) bu
f, (int) buf length, (int) net ref) 原形式）を出し、バイト指向型ストリームデータをメッセージ指向型データパケットに変換し、そのデータ要請をＢインタフェースを通して転送する。 サーバプラットフォーム１
４に常駐する通信ブローカ１２は、そのデータ要請を処理し、インタフェースＡ経由でサーバアプリケーション２２に該データを送信するデータ書き込み原形式（すなわち、int status= ipc write ((char*) buf, (int) b
uf length, (int) ipc ref) 原形式）を出す。

【００４６】サーバアプリケーション２２はこのデータ要請に答え、標準バイトストリーム指向型プロトコルを用いて要請されたデータをＡインタフェースに送信する。 サーバプラットフォーム１４の通信ブローカ１２
は、送信データ要請を処理してデータ書き込み原形式（例えば、int net ref = net write ((char*) buf,
(int)buf length, (int) net ref) 原形式）を出す。
データ書き込み原形式を発すると、上述したように、バイト指向型データストリームがメッセージ指向型データストリームに変換され、Ｂインタフェースを経由して局所クライアントプラットフォーム１６に変換された情報が転送される。

【００４７】局所プラットフォーム１６の通信ブローカ１２は、メッセージ指向型データストリームをバイト指向型データストリームに再変換し、その情報をＡインタフェースを経由して適切なＴＩＳクライアントアプリケーション２０に転送するデータ読み出し原形式（すなわち、int status = net read ((char**) buf, (int*)bu
f length, (int) net ref原形式）を出してサーバの応答を読む。 それから、ＴＩＳクライアントアプリケーション２０は、受信したデータを処理し、公知のダイヤルイン、あるいはＴ１／ＩＳＤＮアクセス手法を経てデータを所望のフォーマットでクライアントに転送する。

【００４８】以上、実際の適応例を通して本発明の原理を説明したが、他の構成および方法も、本発明の範囲を逸脱することなく、当業者によって実行可能である。

【図面の簡単な説明】

【図１】従来の通信ネットワーク用階層型アーキテクチャの一例を示す図である。

【図２】従来の通信ネットワーク用階層型アーキテクチャの他の例を示す図である。

【図３】本発明に係わる通信ブローカを組み込んだ複数プラットフォーム間通信ネットワークのブロック図である。

【図４】クライアントおよびサーバのプラットフォーム間での通信シーケンスを示す図である。

【図５】仮想回路を確立する接続テーブル処理のフローチャートである。

【図６】仮想回路を閉じる接続テーブル処理のフローチャートである。

【図７】本発明に係わる複数プラットフォーム間通信ネットワークの他の実施例を示すブロック図である。

【図８】図３に類似した通信ネットワークのブロック図であり、交通渋滞および天候データについてのクライアント・サーバ間アプリケーションを示す。

【符号の説明】

１０ 複数プラットフォーム型クライアントおよびサーバ間通信アーキテクチャ １２ 通信ブローカ １４ サーバプラットフォーム １６，１８ クライアントプラットフォーム ２０ａ〜２０ｘ，２０ｂ〜２０ｙ クライアントアプリケーション ２２ サーバアプリケーション ２４ データ収集アプリケーション ２６ データ収集プラットフォーム ２８，３０ 情報プロバイダ Ａ，Ｂ，Ｃ，Ｄ インタフェース