JPH05189333A - 言語プリプロセッサ及び実行時ライブラリをネットワークで利用するためのシステム - Google Patents

Abstract

(57)【要約】 【目的】 特性の異なるネットワーク化プラットホーム
（以下ＮＰ）間における通信を容易にし、各種トランス
ポートを介したＮＰ間の通信を容易化する。 【構成】 特性の異なるＮＰ上に常駐するアフ゜リケーションフ゜ロ
ク゛ラム（以下ＡＰ）がその相違から生じる異なるデータフ
ォーマットを考慮せずにユーザデータの交換を可能とす
るシステム及び方法である。又特定のトランスポート
（以下ＴＰ）用に特別にＡＰを書く必要がなく、種々の
ＴＰを介した様々なＮＰ間での通信を容易化する。これ
はＡＰ内にその開発者が特殊な組み込みコマンドを組み
込むことを可能とすることにより達成される。そのネッ
トワークコマンドは本発明の実行時／コンフィキ゛ュレーション機構
を有効に使用できる。前記機構は、データ変換に備えた
もので、また種々のＴＰ間の通信を容易化する。また、
組み込みネットワークコマンドを用いずに前記機構の有
利な特徴をＡＰにより直接利用可能とした。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、それぞれが様々な特性
を備えたネットワーク化プラットホーム（即ち、ネット
ワークに接続されたコンピュータ）において開発され、
及び／又は、そのネットワーク化プラットホーム上で実
行されるアプリケーションプログラムが、各種ネットワ
ークトランスポートを用いて互いに通信を行うことを可
能にするシステム及び方法である。より詳細には、本発
明は、異なる言語、及び／又はコンパイラ、及び／又は
ＣＰＵを利用してアプリケーションプログラムの開発が
行われるネットワーク化プラットホームにおいて開発さ
れ、及び／又はそのネットワーク化プラットホーム上で
実行されるアプリケーションプログラム間の通信を容易
にするためのシステム及び方法に関するものである。更
に、本発明は、各種トランスポートを介して通信が行わ
れる上述のネットワーク化プラットホーム上で実行され
るアプリケーションプログラム間の通信も容易にする。
こうした各種トランスポートが用いられる場合に、本発
明は、更に、各トランスポートを複数のネットワーク化
プラットホームに接続することを意図したものである。

【０００２】

【従来の技術及び発明が解決しようとする課題】個々の
コンピュータシステムをリンクするネットワークの利用
は、過去数年間のうちに劇的に増大した。ネットワーク
の重要な側面の１つは、個々のコンピュータ間で資源の
共有が可能になるということである。特に、ネットワー
クにより、データのアクセス、転送、及び、共有が可能
になる。

【０００３】一般的なネットワーク環境は、ネットワー
ク化プラットホーム（即ち、ネットワーク化環境と通信
を行う個々のコンピュータ又はその離散的グループ）を
有している。これらのネットワーク化プラットホーム
は、「サーバ」（即ち、ネットワーク環境にサービスを
提供するもの）と、ワークステーション又は「クライア
ント」（即ち、サーバによるサービスの実行を要求する
もの）とから構成される。「サーバ」及び「クライアン
ト」の名称は、機能的なものであり、従って、同じネッ
トワーク化プラットホームは、特定の対話時における役
割に応じてサーバとクライアントとの両方として機能す
ることが可能である。

【０００４】各ネットワーク化プラットホームは、ある
種の中央処理装置（ＣＰＵ）を備えている。このＣＰＵ
を利用してネットワーク化プラットホーム上で１つ以上
のアプリケーションプログラムが実行されること、及び
これらのアプリケーションプログラムがネットワーク環
境に対するサービスの提供及び／又はネットワーク環境
からのサービスの要求を行うことが予測される。これら
のアプリケーションプログラムは、ユタ州 Orem の Wor
dperfect Corporation製の Wordperfect等の既製のプロ
グラムとすることもできるし、或いは、特定用途プログ
ラムとすることもできる。いずれにせよ、ネットワーク
化プラットホームに用いられるＣＰＵのタイプは、アプ
リケーションプログラムにより生成されるユーザデータ
を最終的に表現する方法に影響を及ぼすことになる。そ
の結果として、異なるデータ表現を有するネットワーク
化プラットホームから受信したユーザデータは、２つの
プラットホームがそのデータを共有する場合には、翻訳
が行われる必要がある。

【０００５】アプリケーションプログラム自体は、Ｃ、
ＰＡＳＣＡＬ、ＣＯＢＯＬといった高級プログラミング
言語で書かれているのが普通である。各プログラミング
言語毎に任意数のコンパイラが存在する可能性がある。
例えば、各種Ｃコンパイラには、カリフォルニア州Palo
Alto のヒューレットパッカード社製のHP-C、及びワシ
ントン州 Redmondの Microsoft Corporation製の Micro
soft Cが含まれる。また、各プログラミング言語及び各
コンパイラは、様々な機構を用いてデータの編成及び表
現を行う。従って、異なるプログラミング言語、及び／
又はコンパイラを用いて開発されたアプリケーションプ
ログラムを備えた２つのネットワーク化プラットホーム
は、データの共有が困難となる可能性がある。

【０００６】ＣＰＵ、プログラミング言語、及びコンパ
イラのタイプの相違に加え、ネットワーク環境は、各種
のネットワーク化プラットホームを接続する複数のトラ
ンスポートを含んでいる可能性がある。「トランスポー
ト」は、ネットワーク化プラットホーム間で情報の交換
を行うプロトコルである。トランスポートの例として、
防衛先進研究企画庁（ＤＡＲＰＡ）のために開発された
伝送制御プロトコル／インターネットプロトコル（ＴＣ
Ｐ／ＩＰ）がある。これは、ＵＮＩＸベースの環境、及
びユタ州 Provoの Nobell による Sequential Package
Exchange（ＳＰＸ）と共に広く用いられるものである。
アプリケーションプログラムの開発者が、そのアプリケ
ーションプログラムを複数のトランスポートを同時に利
用できるものにしたい場合、各トランスポート毎にアプ
リケーションプログラムを特別に開発する必要がある。
これは、アプリケーションプログラムが各トランスポー
トで別個に作業を行うことを開発者が望む場合にも当て
はまることである。

【０００７】異なる装置が互いに通信を行えるようにす
ることの重要性は早くから明らかであった。個々の製品
の販促のため、相手先商標製造会社（ＯＥＭ）は、１セ
ットのアプリケーションプログラムインターフェイス
（ＡＰＩ）ルーチンを提供することにより、サードパー
ティに対するネットワークアーキテクチャの公開を開始
して、ネットワークを介して得られる強化された計算力
を利用するために新しいネットワークアプリケーション
を開発することができるようにした。このようにして、
アプリケーションプログラムの開発者は、特定のトラン
スポートに関するアプリケーションプログラムの開発を
容易に行えるようになった。

【０００８】ＴＣＰ／ＩＰトランスポートにより用いら
れる「ソケット」等の従来のネットワークＡＰＩは、ネ
ットワーク環境における異なるネットワーク化プラット
ホームで実行される２つのプロセス（例えば、コードの
実行部分）間の通信を提供するＡＰＩの例である。しか
し、こうした従来のＡＰＩは、アプリケーションプログ
ラムのプログラマが、異なるネットワーク化プラットホ
ーム間で、及び異なるタイプのトランスポートを介し
て、効率的かつ生産的に移植できるようにアプリケーシ
ョンプログラムを開発することを妨げる欠陥を有するも
のである。これらの欠陥の理由には以下に示すものがあ
る。

【０００９】１．ＡＰＩの複雑さ。

【００１０】２．これらのＡＰＩを有効なものにするた
めにアプリケーションプログラムの開発者は大量の追加
ルーチン（例えば、ネットワークアドレスの操作、トラ
ンスポートの制御パラメータの構成、通信バッファの管
理、及びデータフロー制御機構のためのもの）を作成す
る必要がある。

【００１１】３．新しいトランスポートをサポートする
（即ち、追加する）毎に、アプリケーションプログラム
の開発者は、アプリケーションプログラム（又は、少な
くともその通信部分）を書き直し、コンパイルし直す必
要がある。これは、各トランスポート毎に、同じアプリ
ケーションプログラムについて複数のバージョンを開発
し、維持しなければならないことを意味する。

【００１２】４．これらのＡＰＩは、端末間通信向けの
ものである。その結果として、同じタイプのネットワー
クトランスポートを介して複数のアプリケーションプロ
グラムと通信できるアプリケーションプログラムを開発
するのは、極めて困難となる。このため、複数のクライ
アントをサポートするのに必要なサーバアプリケーショ
ンプログラムを開発者が書くことが妨げられる。複数の
トランスポートを介して複数のアプリケーションプログ
ラムと同時に通信可能なアプリケーションプログラムを
開発することは更に困難となる。

【００１３】５．これらのＡＰＩは、限られた数の従来
のプログラミング言語（Ｃ、ＣＯＢＯＬ、ＰＡＳＣＡＬ
等）のサポートに資するものである。これらの言語間の
相違はアプリケーションプログラムにより生成されるデ
ータの編成に劇的な影響を与え、また同一の言語であっ
ても、それが異なるコンピュータ言語コンパイラの専門
業者により提供されたものである場合には上述と同様の
影響を与えることになる。このことは、これらのＡＰＩ
では取り扱われていない。 新しいネットワークＡＰＩには、上述の問題のいくつか
に取り組もうとしているものがある。例えば、Microsof
t Corporation製のLanManager用のNamedPipesは、多く
のオペレーティングシステム（例えばＯＳ／２及びＵＮ
ＩＸ）上で利用可能であり、ＨＰ社製のソケットは、複
数のトランスポート（例えばＮＳ及びＴＣＰ／ＩＰ）を
サポートする。しかし、これらのＡＰＩで、実際に上述
の主たる欠陥を解決するものはない。

【００１４】コンピュータ及び通信ハードウエア産業が
拡大し続けることにより、分散形計算環境において機能
するアプリケーションプログラムに対する差し迫った必
要性が生じてきた。上述の新しいＡＰＩの「上位で（on
top of)」（即ち、該ＡＰＩに関連して）実行される新
しい分散形計算技術が数多く発明されている。こうした
技術の例としては、カリフォルニア州 Palo Altoの HP/
Apollo Corporation製の NCSのような「遠隔手順呼び出
し」（ＲＰＣ）装置がある。

【００１５】ＲＰＣにより、プログラマは、既存のアプ
リケーションプログラムに関する知識を利用して分散形
アプリケーションプログラムを開発することが可能にな
り、馴染みの無い下位レベルのネットワークインターフ
ェイスについて学習する必要がなくなる。ＲＰＣ装置を
用いる利点は、ネットワーク通信の複雑さがアプリケー
ションのプログラマから見えないようにして、プログラ
マが、単純なスタンドアロン型のアプリケーションプロ
グラムに対する場合と同様の方法でプログラムを開発す
ることができるということである。しかし、ＲＰＣに
は、以下のような制限がある。

【００１６】１．ＲＰＣは単なる１つの機能である。こ
の機能は、ある１つのネットワーク化プラットホーム上
で実行されるが、異なるネットワーク化プラットホーム
上のアプリケーションプログラムから呼び出される。Ｒ
ＰＣは、ネットワーク環境における様々なネットワーク
化プラットホームに作業負荷を分散させるだけである。

【００１７】２．ＲＰＣは、クライアント／サーバ通信
パラダイムに基づくものである。これにより、同類間(p
eer to peer)通信（即ち、全てのネットワーク化プラッ
トホームが同類(peer)である場合）を必要とするアプリ
ケーションを、アプリケーションプログラムの開発者が
実施することができなくなる。

【００１８】３．ＲＰＣの基礎構造(infrastructure)は
かなり複雑で利用が困難なものである。これには、デー
タ定義操作用のネットワーク言語コンパイラが含まれて
おり、ユーザは、クライアント及びサーバの通信を可能
にするためにデータ構造を定義しなければならない。

【００１９】４．ＲＰＣの同期方法は手順向けのもので
ある。アプリケーションプログラムは制御が遠隔手順か
ら戻るまで先へ進むことはできない。

【００２０】５．ＲＰＣは、ＵＮＩＸオペレーティング
システム及びＣプログラミング言語で用いるために開発
されたものである。複数のプログラミング言語を用いる
各種オペレーティングシステム上での利用は容易ではな
い。

【００２１】６．ＲＰＣは複数のトランスポートの同時
サポートを容易にするものではない。 ７．ＲＰＣのデータ変換は、ソースアプリケーションデ
ータを中立フォーマットに変換し、次にそれを宛先アプ
リケーションのターゲットフォーマットに変換する必要
がある２ステップのプロセスによるものである。

【００２２】従って、必要なのは、上述の装置が実行す
ることのできない機能を実行することができるシステム
及び／又は方法である。

【００２３】

【課題を解決するための手段】本発明は、特性の異なる
ネットワーク化プラットホーム間における通信を容易に
し、またユーザにとって分かりやすい方法で、各種トラ
ンスポートを介したネットワーク化プラットホーム間の
通信を容易にする、システム及び方法を提供することに
より、上述の装置の欠陥を克服するものである。

【００２４】より詳細には、本発明は、ネットワークト
ランスポート上に常駐するアプリケーションプログラム
が、ネットワーク化プラットホームが利用するＣＰＵの
タイプ、アプリケーションプログラムの開発に用いたア
プリケーションプログラム言語のタイプ、アプリケーシ
ョンプログラムのコンパイルに用いられたコンパイラの
タイプ等の特性によって決まるフォーマットでユーザデ
ータを生成するという事実を考慮に入れたものである。
特性の異なるネットワーク化プラットホーム間において
ユーザデータの交換を行えるようにするため、本発明
は、送信側のネットワーク化プラットホームからユーザ
データを受信するネットワーク化プラットホームにより
いかなるフォーマットが用いられる場合であっても、ユ
ーザデータの変換を容易にするものである。この方法に
よれば、アプリケーションプログラムの開発者は、開発
者のアプリケーションプログラムがどんなタイプのネッ
トワーク化プラットホームと通信することになるかに気
を配る必要がない。従って、通信先のネットワーク化プ
ラットホームの各タイプ毎に、複数バージョンの同じア
プリケーションプログラムを開発する必要がない。

【００２５】本発明は、また、様々なトランスポートを
利用するネットワーク化アプリケーション間における通
信を容易にする。即ち、本発明は、アプリケーションプ
ログラムの開発者が、ネットワーク化プラットホーム間
における情報の通信に用いられるトランスポートのタイ
プに対する配慮を必要とせずに、アプリケーションプロ
グラムの開発を行えるようにするものである。従って、
アプリケーションプログラムの開発者は、利用されるト
ランスポートの各タイプ毎にアプリケーションプログラ
ムを書く必要がない。

【００２６】本発明の実施例は、アプリケーションプロ
グラムの開発者が比較的小さなセットのネットワークコ
マンドを利用してアプリケーションプログラムの開発を
行えるようにすることにより上述の利点を提供するもの
である。これらのネットワークコマンドは、ネットワー
ク化プラットホーム間における通信の初期設定を行うた
めに用いられ、また、ネットワーク化プラットホーム
（互いに通信することを企図したもの）に相違がある場
合に何らかのデータ変換が必要であることを示すために
も用いられる。しかし、これらの実施例には、ネットワ
ーク化プラットホームに相違のあることを示しさえすれ
ばよく、その相違がどんなものかについて詳細に述べる
必要のないものもある。

【００２７】本発明の実施例には、プログラミング言語
のコンパイラを利用する前に、組み込みネットワークコ
マンドを含むアプリケーションプログラムが、ネットワ
ークコマンドプリプロセッサを利用することを意図した
ものもある。プログラミング言語のコンパイラを利用し
た後、アプリケーションプログラムは、アプリケーショ
ンプログラムの実行時におけるデータ変換及び複数トラ
ンスポートの容易化の義務を負うエンティティである実
行時／コンフィギュレーション機構にリンクされる。本
発明の他の実施例は、ネットワークコマンドプリプロセ
ッサを用いずに、この実行時／コンフィギュレーション
機構を利用することを企図したものであるという点に留
意されたい。但し、これらの実施例においては、ユーザ
は実行時／コンフィギュレーション機構に直接アクセス
する必要がある。

【００２８】本発明の様々な目的、特徴、及び付随する
利点は、図面に関連づけて以下に示す本発明の詳細な説
明を参照することにより、完全に認識し、一層良く理解
することができるものである。

【００２９】

【実施例】

Ｉ． 概要 本発明は、それぞれ特性の異なるネットワーク化プラッ
トホーム（即ち、ネットワークに接続されたコンピュー
タ）において開発され、及び／又は前記ネットワーク化
プラットホーム上で実行されるアプリケーションプログ
ラムが、様々なネットワークトランスポートを用いて互
いに通信を行うことができるようにするシステム及び方
法である。（本発明の実施例により企図するネットワー
ク化プラットホームの一例が、ヒューレットパッカード
社製のHP9000/700シリーズのコンピュータである。）よ
り詳細には、本発明は、異なる言語及び／又はコンパイ
ラ及び／又はＣＰＵを用いてアプリケーションプログラ
ムの開発が行われたネットワーク化プラットホームにお
いて開発され、及び／又は前記ネットワーク化プラット
ホーム上で実行されるアプリケーションプログラム間で
の通信を容易にするためのシステム及び方法に関するも
のである。更に、本発明はまた、各種トランスポートを
介して通信が行われる上述のネットワーク化プラットホ
ーム上で実行されるアプリケーションプログラム間の通
信も容易にする。本発明は更に、こうした様々なトラン
スポートが用いられる場合に、各トランスポートを複数
のネットワーク化プラットホームに接続できることを企
図したものである。

【００３０】一般に、本発明は、アプリケーションプロ
グラムの開発者が、ネットワーク環境内における他のア
プリケーションプログラムと簡単に通信し、データ転送
を行うことが可能なアプリケーションプログラムの開発
を行うための方法を提供するものであり、異なる特性の
ネットワーク化プラットホーム及びトランスポートをア
プリケーションプログラムの開発者にとって分かりやす
いものとする。例えば、本発明は、通信を所望するアプ
リケーションプログラムが、異なるデータ表現機構を有
するネットワーク化プラットホーム上で開発されたもの
である場合に、効率の良いデータ変換が容易に行えるよ
うにするものである。この方法によれば、アプリケーシ
ョンプログラムの開発者は、開発者のアプリケーション
プログラムが通信を行うことになる遠隔ネットワーク化
プラットホームのデータ表現機構に関与する必要がな
い。このため、各種ネットワーク化プラットホームとの
通信のために、アプリケーションプログラムの様々なバ
ージョンを開発する必要がなくなる。更に、本発明は、
単一バージョンのアプリケーションプログラムが、各ネ
ットワークトランスポート毎に異なるバージョンのアプ
リケーションプログラムを必要とすることなく、様々な
ネットワークトランスポート間で通信を行うことができ
るようにする。

【００３１】次に、図１に関連して本発明の企図する特
徴について一層詳細な説明を行う。図１を参照すると、
各種ネットワーク化プラットホームから構成されるネッ
トワーク環境が示されている。これらのネットワーク化
プラットホームの一部はサーバとして利用され、１０
４，１０６，１０８，１１０で示されている。他のネッ
トワーク化プラットホームはクライアントとして利用さ
れ、１１２，１１４，１１６，１１８で示されている。
留意すべきは、図１に示す構成は例示を目的としたもの
であり、本発明は任意数の異なる構成が可能になるよう
に企図したものである。

【００３２】従来の技術の欄において示したように、
「サーバ」及び「クライアント」の名称は、特定のネッ
トワーク化プラットホームがいかに用いられるかという
機能にすぎない。この実施例では、「クライアント／サ
ーバ」１０２は、クライアント又はサーバのいずれとし
ても機能することができるネットワーク化プラットホー
ムの例示として用いられている。即ち、クライアント／
サーバ１０２がサーバ（１０４，１０６，１０８，１１
０）のうちの１つと通信する場合、それはクライアント
として働くことになる。逆に、クライアント／サーバ１
０２が、クライアント（１１２，１１４，１１６，１１
８）のうちの１つと通信する場合には、それはサーバと
して働くことになる。

【００３３】ここでは例示のために用いられているが、
そのようなクライアント／サーバ１０２のネットワーク
化プラットホームは（現実の状況では）同類ベースのネ
ットワーク環境において見受けられるのが普通である。
もちろん、本発明が用いることを意図する他のタイプの
ネットワーク環境では、サーバ又はクライアントの一方
としてしか用いることのできないネットワーク化プラッ
トホームが利用される。いずれにせよ、図１に示す例に
関連する本発明の特徴は、論述の中心基準点としてクラ
イアント／サーバ１０２を利用して最も良く説明され
る。

【００３４】従って、クライアント／サーバ１０２につ
いて言及すると、本発明の実施例は、クライアント／サ
ーバ１０２は（各ネットワーク化プラットホームと同様
に）、何らかのタイプの中央処理装置（ＣＰＵ）を備え
ている。このＣＰＵは、任意の市販のＣＰＵ（カリフォ
ルニア州 Cupertinoの Intel Corporation製のIntel803
86 等のマイクロコンピュータにより用いられているも
のからスーパコンピュータにより用いられているものま
で）で構成することを意図するものであり、また、単一
プロセッサから大規模な並列演算処理マシンにわたる範
囲のマシンを用いることを意図したものである。クライ
アント／サーバ１０２により示されるように、１つ以上
のアプリケーションプログラムをクライアント／サーバ
１０２上でそのＣＰＵを用いて実行することが企図さ
れ、また、それらのアプリケーションプログラムがネッ
トワーク環境に対してサービスを提供し、及び／又はネ
ットワーク環境によるサービスを要求することが企図さ
れている。特に、これらのサービスにはネットワーク化
プラットホーム間でのユーザデータの転送が含まれる
（但し、他のタイプの情報も転送可能である点に留意さ
れたい）。

【００３５】また、クライアント／サーバ１０２に常駐
するアプリケーションプログラムが、そのクライアント
／サーバ１０２と通信を行う他のネットワーク化プラッ
トホーム上で用いられるのと同じプログラミング言語又
はコンパイラである場合も、そうでない場合もあり得る
高級プログラミング言語を用いて開発され及びコンパイ
ラを用いてコンパイルされたものであることも考えられ
ている。更に、クライアント／サーバ１０２は、様々な
異なるトランスポートを用いて他のネットワーク化プラ
ットホームとリンクすることを意図したものである。

【００３６】上述のように、本発明は、アプリケーショ
ンのプログラマにとって分かりやすい方法で、特性の異
なるネットワーク化プラットホーム間での通信、及び各
種トランスポートを介した通信を容易にする。これは、
ネットワークコマンドプリプロセッサを利用し、実行時
／コンフィギュレーション機構を用いることにより可能
となる。これらのエンティティに関する詳細については
後述することとする。現時点では、本発明の実施例は、
各ネットワーク化プラットホームの一部として実行時／
コンフィギュレーション機構を利用することを意図した
ものであると、言えば十分である。

【００３７】次に、図１に例示のクライアント／サーバ
１０２と各種のサーバ及びクライアントとの間における
対話について論じることにより、本発明の意図する特徴
の例を解説することにする。より詳細に言えば、ユーザ
データの交換が、クライアント／サーバ１０２のアプリ
ケーションプログラムと他のネットワーク化プラットホ
ームのアプリケーションプログラムとの間で発生するこ
とになるということが考えられている。分かりやすくす
るため、この実施例における全てのネットワーク化プラ
ットホーム上のアプリケーションプログラムが同一であ
ると仮定する。但し、本発明は、各ネットワーク化プラ
ットホーム上のアプリケーションプログラムが異なる状
況も考慮に入れたものである。

【００３８】これから解説する第１の対話は、クライア
ント／サーバ１０２のアプリケーションプログラムとサ
ーバ１０４のアプリケーションプログラムの間での対話
である。この実施例で示すように、クライアント／サー
バ１０２及びサーバ１０４上のアプリケーションプログ
ラムは、両方とも、同じプログラミング言語、コンパイ
ラ、及びオペレーティングシステム（分かりやすくする
ため、これらの特性をそれぞれ、言語１、コンパイラ
１、及びオペレーティングシステム１と称す）を用いて
開発されたものである。但し、この状況において、サー
バ１０４上のＣＰＵはクライアント／サーバ１０２上の
ＣＰＵとは異なるものである。これは一般に、これらの
ネットワーク化プラットホームのそれぞれにおいて生成
されるユーザデータが多少異なって編成される（例え
ば、それらのアライメントが変化する）ことを意味する
ため、２つのネットワーク化プラットホームがユーザデ
ータを交換する場合にはユーザデータの変換が必要にな
る。

【００３９】本発明の実施例では、ユーザデータを受信
するのがどのネットワーク化プラットホームであろう
と、必要な変換が容易に行われるように企図されてい
る。該方法によれば、ネットワーク化プラットホーム
は、通信相手のネットワーク化プラットホームに関する
特性に配慮する必要がない。但し、ユーザデータを送る
ネットワーク化プラットホームがその特性（例えば、Ｃ
ＰＵのタイプ、コンパイラ等）を示すことは必要であ
る。この実施例の場合、ＣＰＵ１を Intel 80386マイク
ロプロセッサとする一方、ＣＰＵ２をマサチューセッツ
州 Maynardの DigitalEquipment Corporation 製の Vax
780プロセッサとすることができる。いずれにせよ、デ
ータ変換（受信側におけるもの）とデータ特性記述（送
信側におけるもの）とは両方とも、本発明により、とり
わけ、実行時／コンフィギュレーション機構により、容
易となる。このため、アプリケーションプログラムの開
発者は、異なるＣＰＵを備えたネットワーク化プラット
ホームとユーザデータの交換を行うことが可能な単一バ
ージョンのアプリケーションプログラムを開発すること
が可能になるので、アプリケーションプログラムの開発
者は、通信相手であるＣＰＵのタイプを気にする必要が
なくなる。

【００４０】ここでサーバ１０６について説明する。図
示のように、アプリケーションプログラムの作成に用い
られるプログラミング言語は、サーバ１０６の場合も、
クライアント／サーバ１０２の場合も同じである。しか
しながら、そのアプリケーションプログラムをコンパイ
ルするために用いられるコンパイラは、２つのネットワ
ーク化プラットホーム上で異なるものである（即ち、サ
ーバ１０６上のコンパイラは「コンパイラ２」であり、
クライアント／サーバ１０２上のコンパイラは「コンパ
イラ１」である）。従って、アプリケーションプログラ
ムが両方とも、Ｃプログラミング言語を用いて開発され
た場合であっても、その一方は、例えばMicrosoft Corp
oration 製の Microsoft Cコンパイラを用いてコンパイ
ルされ、もう一方はヒューレットパッカード社製のHP-C
コンパイラを用いてコンパイルされた可能性がある。２
つのアプリケーションプログラムにより生成されたユー
ザデータは、アライメント及びビット配列が異なる可能
性がある。本発明は、また、データを受信するネットワ
ーク化プラットホームがどれであっても、適正なデータ
変換が行われることを意図したものである。

【００４１】ここでサーバ１０８について説明する。こ
のネットワーク化プラットホーム上のアプリケーション
プログラムは、クライアント／サーバ１０２とは異なる
言語（従って異なるコンパイラ）を用いて開発されたも
のである。例えば、サーバ１０８上のアプリケーション
プログラムはＣＯＢＯＬで書かれ（従ってＣＯＢＯＬコ
ンパイラを用いてコンパイルされ）、一方、クライアン
ト／サーバ１０２上のアプリケーションプログラムはＣ
で書かれた（従ってＣコンパイラを用いてコンパイルさ
れた）ものとすることができる。これが当てはまる場
合、生成されたユーザデータにおける差は、やはり、何
らかのタイプのデータ変換を必要とするのに十分である
と言える。本発明は適切な変換を容易にするものであ
る。

【００４２】サーバ１１０は、そのアプリケーションプ
ログラムが、クライアント／サーバ１０２とは異なるオ
ペレーティングシステムの下で実行中であることを示し
ている。一般に、オペレーティングシステムが異なって
もユーザデータの編成に相違は生じないが、本発明は、
それでもなお、データ編成に相違が生じる状況において
適切なデータ変換を実行することを意図したものであ
る。

【００４３】図１に示す言語、コンパイラ等の様々な組
み合わせは単なる例示にすぎない。サーバ１０４〜１１
０とクライアント／サーバ１０２との間の異なる構成の
組み合わせもまた考えられている。従って、ネットワー
ク化プラットホームの全てがクライアント／サーバ１０
２に接続されているという事実は、単に例示を目的とし
たものにすぎない。

【００４４】上述のように、本発明は、データ変換を容
易にするだけでなく、複数のトランスポートの利用も容
易にするものである。例えば、図１に示すように、クラ
イアント／サーバ１０２は、異なるトランスポート（ト
ランスポート１〜３）を用いてサーバ１０４，１０６，
１０８に取り付けられる。本発明の実施例は、クライア
ント／サーバ１０２上に常駐するアプリケーションプロ
グラムが、これら３つのトランスポートのうちの１つを
任意に（別個に又は同時に）利用することができると同
時に、前記３つのトランスポートの特定のプロトコルを
考慮して開発を行う必要がないようにすることを意図し
たものである。そのアプリケーションプログラムは、通
信を所望するネットワーク化プラットホームにおけるサ
ービスについて単に選択を行うだけであり、特定のトラ
ンスポートのプロトコルに対する特定のアドレス指定及
び利用については本発明がその処理を行う。

【００４５】本発明は、一般に、複数のトランスポート
を利用可能とすることに加え、アプリケーションプログ
ラムが常駐するネットワーク化プラットホームに、その
アプリケーションプログラムをコンパイルし直すことな
く追加トランスポートを追加することができるようにす
るものである。これが、図１において、クライアント／
サーバ１０２とサーバ１１０との間にトランスポートｎ
を追加することにより示されている。本発明の実施例
は、アプリケーションプログラムがトランスポートｎを
介してサーバ１１０を利用する場合に、クライアント／
サーバ１０２とサーバ１１０との実行時／コンフィギュ
レーション機構にアドレス情報を追加することしか必要
とされないということを考慮したものである。但し、こ
れは、新しいトランスポートにアクセスする情報が、ア
プリケーションプログラムのリンク段階において実行時
／コンフィギュレーション機構に含まれているというこ
とを仮定したものである。そうでない場合には、実行時
／コンフィギュレーション機構は、その更新が必要とな
り、アプリケーションプログラムをリンクし直すことに
なる（但し、コンパイルし直すことはない）。これにつ
いては以下で更に詳述することとする。

【００４６】本発明は、クライアント／サーバ（クライ
アントとして機能する場合）を複数のサーバ（１０４，
１０６，１０８，１１０）に取り付けることができるよ
うにするだけでなく、１つ以上のクライアント（１１
２，１１４，１１６，１１８）と通信を行う場合に同一
のクライアント／サーバ１０２がサーバとして働くこと
もできるように考えられたものである。本発明の実施例
は、上述のものと同一のデータ変換機構及びトランスポ
ート間の関係が、クライアント／サーバ１０２とクライ
アント（１１２，１１４，１１６，１１８）との間の関
係にも当てはまるように考慮している。これは、複数の
トランスポートの接続、及び、各種の言語、コンパイ
ラ、オペレーティングシステム、ＣＰＵの使用により示
されている。やはり、理解すべきは、本発明では任意の
数の各種組み合わせが考えられており、図１は単に例示
のためのものでしかないということである。更に、本発
明では、複数のサーバ及び／又はクライアントを各トラ
ンスポートに取り付けることができるように考えられて
いる点も理解されるべきである。

【００４７】次に、本発明が意図する実施例が上述の特
徴を実現する方法について、図２に関連して説明を行
う。図２を参照すると、ユーザは何らかのプログラミン
グ言語を用いてアプリケーションプログラムを作成する
（即ち、ソースコードが生成される）。本発明は、Ｃ、
ＣＯＢＯＬ、ＰＡＳＣＡＬ、ＦＯＲＴＲＡＮを含む任意
の数のプログラミング言語のソースコードを用いてアプ
リケーションプログラムを開発することができることを
意図するものである。このソースコード内にユーザが特
殊なネットワークコマンドを組み込むように考えられて
いる。これをブロック２０２に示す。本発明の実施例
は、これらのコマンドを、一般に、初期設定に関するも
の、他のネットワーク化プラットホームへのメッセージ
の送信に関するもの、及び他のネットワーク化プラット
ホームからのメッセージの受信に関するものとして分類
することができるように構想されている。

【００４８】「初期設定」（即ち、接続の設定）に関連
するネットワークコマンドの例には、サーバに常駐する
アプリケーションプログラムが（既述名に基づいて）、
メッセージを受け取ることになる物理アドレスを決定す
るコマンドや、クライアントに常駐するアプリケーショ
ンプログラムが、やはり既述名に基づいてサーバの物理
アドレスを決定するコマンドがある。

【００４９】初期設定処理が完了すれば、サーバ及びク
ライアント間でメッセージを送ることが可能になる。本
発明の実施例は、あらゆる必要なデータ変換が、メッセ
ージを受信するネットワーク化プラットホームにより行
われ、データの記述（即ち、メッセージを発したネット
ワーク化プラットホームの特性）が、メッセージを送信
するネットワーク化プラットホームにより送られるよう
に考慮したものである。このデータ記述は、極めて特定
されたもの（例えば、ＣＰＵのタイプ、プログラミング
言語等）にすることも、或いは、より一般的なもの（例
えば、送信側のネットワーク化プラットホームの所定の
特性が受信側のネットワーク化プラットホームと「異な
っている」ということのみ）にすることも可能である。
留意すべきは、本発明の実施例では、送信側のネットワ
ーク化プラットホームにより変換が行われる状況も考え
られているという点である。

【００５０】組み込みネットワークコマンドを有するア
プリケーションプログラムは、一旦作成されると、楕円
２０４で示すように、ネットワークコマンドプリプロセ
ッサにより受信される。このプリプロセッサ２０４は、
組み込みネットワークコマンドを受け取って、適合する
プログラム言語のソースコード（初期アプリケーション
プログラムの開発に用いられたプログラム言語に一致す
るもの）を生成する。この生成されたソースコードのほ
とんどは、後述するように、実行時／コンフィギュレー
ション機構（ここではブロック２１６として示されてい
る）にアクセスするための特殊機能呼び出しを含んでい
る。

【００５１】ネットワークコマンドプリプロセッサ２０
４がその前処理を完了すると、結果として、ブロック２
０６に示すように、ネットワークで利用可能なアプリケ
ーションプログラムが得られることになる。次に、使用
されるプログラミング言語に応じて、適合するプログラ
ミング言語のコンパイラ（楕円２０８で示す）を用い
て、ネットワークで利用可能なアプリケーションプログ
ラムが目的コードにコンパイルされる。これをブロック
２１０で示す。次に、使用されるオペレーティングシス
テムに応じて、リンカ（楕円２１２で示す）を用いて、
ブロック２１４で示すように、目的コードが実行可能フ
ォーマットに変換される。

【００５２】リンク処理中に、ネットワークコマンドの
結果として生じた特殊機能呼び出しをアプリケーション
プログラムが利用できるようにするために、実行時機構
２１８が用いられる。これらの機能呼び出しにより、図
１に関連して上述した特徴の実施が容易となる。

【００５３】アプリケーションプログラムの実行中に
は、実行時機構２１８及びコンフィギュレーション情報
２２０が利用される。本発明の実施例の場合、コンフィ
ギュレーション情報２２０が、ネットワーク化プラット
ホームのコンフィギュレーションに関する情報（例え
ば、利用可能なトランスポートの数及びタイプ、及び各
トランスポート毎のネットワーク化プラットホームの物
理アドレス等）を含むように考えられている。図２に示
すように、実行時機構２１８及びコンフィギュレーショ
ン情報２２０は、両方とも、実行時／コンフィギュレー
ション機構２１６の一部である。

【００５４】本発明の意図するところによれば、プログ
ラミング言語のコンパイラ２０８は、アプリケーション
プログラムを書くのに用いられたプログラミング言語に
適合する任意の標準的な言語コンパイラとすることが可
能である。同様に、リンカ２１２も、使用されるオペレ
ーティングシステムに応じて、任意の標準的なリンカと
することができる（例えば、Microsoft 社は、同社のＤ
ＯＳオペレーティングシステムのためのリンカを提供し
ている）。ネットワークコマンドプリプロセッサ２０４
及び実行時／コンフィギュレーション機構２１６の詳細
については後述することとする。

【００５５】ＩＩ． ネットワークコマンドプリプロセ
ッサ 次に、本発明の実施例が意図するネットワークコマンド
プリプロセッサ２０４について図３に関連して解説を行
う。図３において、語彙分析器３０４は、組み込みネッ
トワークコマンドを有するアプリケーションプログラム
２０２を受信する。語彙分析器３０４は、受信した組み
込みネットワークコマンドを有するアプリケーションプ
ログラム２０２の各文字を分析し、受信したステートメ
ントが、ネットワークコマンドなのか、或いは、使用さ
れているプログラミング言語で書かれた単なるステート
メントなのかを識別しようとする。本発明の実施例で
は、語彙分析器３０４が、受信したステートメントのエ
ラー（例えばステートメントが長すぎること等）を検出
するように考えられている。これが当てはまる場合、エ
ラーのあるステートメント及び／又はエラーメッセージ
がエラーファイル３０８に納められる。

【００５６】語彙分析器３０４が、前記ステートメント
が、使用されるプログラミング言語のステートメントに
すぎないものであると判定した場合、データパス３１２
を介して、ネットワークで利用可能なアプリケーション
プログラムを含むファイル２０６に前記ステートメント
を送る。このファイルは、コンパイラに対する入力とし
て用いられる最終的なソースコードである。

【００５７】また、語彙分析器３０４が、前記ステート
メントがネットワークコマンドであると判定した場合に
は、そのステートメントはデータパス３１４を介してパ
ーサ３０６に送られる。パーサ３０６は、ネットワーク
コマンドが適正な形式であるか否か（例えば、ネットワ
ークコマンドに適正な数のパラメータが含まれているか
否か）を判定する。受信したネットワークコマンドが適
正な形式でない場合には、エラーのあるネットワークコ
マンドは、エラーファイル３０８に送られる。また、ネ
ットワークコマンドが適正な形式である場合には、その
ネットワークコマンドはコードジェネレータ３１０に送
られる。本発明の意図する実施例の中には、コードジェ
ネレータ３１０が、ネットワークコマンドだけでなく、
ネットワークデータ宣言（即ち、実際にプログラミング
言語の一部をなし、ネットワーク環境を介してデータ転
送を行うための構造を提供する、宣言されたデータ構
造）を受信するものがある。これらの実施例は、ユーザ
により、アプリケーションプログラムが、現在のネット
ワーク化プラットホームと同じ特性を有するネットワー
ク化プラットホームと通信することになる、ということ
が示された場合に、コードジェネレータ３１０が宣言デ
ータ構造を変更しないように考えられたものである。し
かし、異なる特性を有するネットワーク化プラットホー
ム上で生成され及び／又は実行されるアプリケーション
プログラムと通信が行われる場合には、データ構造は、
両方のネットワーク化プラットホームにより認識可能な
一般的なフォーマットに変換される。

【００５８】コードジェネレータ３１０がネットワーク
コマンドを受信する場合、そのネットワークコマンドは
適切なソースコードに変換される。即ち、ネットワーク
コマンドは、アプリケーションプログラムのソースコー
ドに用いられているプログラミング言語がいかなるもの
にせよ、そのプログラミング言語による１つ以上のステ
ートメントに翻訳される。次いで、この翻訳は、データ
パス３１６を介して、「ネットワークで利用可能なアプ
リケーションプログラム」と示されたファイル２０６に
送られる。本発明の実施例は、どのプログラミング言語
が用いられているかに関する情報がユーザにより入力さ
れるように意図したものである。しかし、本発明は、プ
ログラミング言語のタイプを自動的に判定する実施例に
ついても考慮している。

【００５９】上述のように、ネットワークコマンドは一
般に、実行時／コンフィギュレーション機構２１６にア
クセスする機能呼び出しを（適用可能なプログラミング
言語に合ったフォーマットで）コードジェネレータ３１
０に生成させる。本発明の実施例では、これらの機能呼
び出しが（他のプログラミング言語のステートメントと
同様に）、問題となるプログラミング言語及びコンパイ
ラに応じて、また、ＣＰＵ間で予想される相違によりど
んなタイプの変換を行う必要があるかに応じて、変更可
能となることを考慮している。

【００６０】次に、図４のフローチャートを用いて、ネ
ットワークコマンドプリプロセッサ２０４の動作方法に
関する実施例について解説する。図４において、最初の
ステップで、組み込みネットワークコマンドを有するア
プリケーションプログラム２０２を含むファイルから受
信したステートメントが、ネットワークコマンド又はネ
ットワークデータ宣言であるかを判定する。これを判定
ブロック４０２で示す。そのステートメントがネットワ
ークコマンドとネットワークデータ宣言とのいずれでも
ない場合、そのステートメントは、プログラミング言語
のステートメント（ネットワークデータ宣言以外の）と
みなされて、ネットワークで利用可能なアプリケーショ
ンプログラム２０６を含むファイルに納められる。

【００６１】また、ステートメントが、ネットワークコ
マンドとネットワークデータ宣言とのいずれかである場
合には、次いでそのステートメントがネットワークコマ
ンドであるか否かの判定が行われる。これをブロック４
０４で示す。そのステートメントは、それがネットワー
クコマンドでないと判定された場合には、ネットワーク
データ宣言として扱われる。これが当てはまる場合、ネ
ットワークデータ宣言はその構文解析が行われて、その
適合するプログラミング言語のステートメントが生成さ
れる。これをブロック４０６及びブロック４１０に示
す。

【００６２】また、ステートメントがネットワークコマ
ンドである場合には、ブロック４０８及びブロック４１
２で示すように、そのネットワークコマンドの構文解析
が行われて、その適合するプログラミング言語のステー
トメントが生成される。次いで、これらのプログラミン
グ言語のステートメントは、ネットワークで利用可能な
アプリケーションプログラム２０６を含むファイルに送
られる。

【００６３】図５のフローチャートには、本発明に用い
ることを意図した各種ネットワークコマンドの受信時に
プリプロセッサ２０４により生成される、プログラミン
グ言語のソースコードの機能性が示されている。従っ
て、このフローチャート内のブロックは、生成されたソ
ースコードの機能性を表している。このため、図５はま
た、アプリケーションプログラムのこれらの部分が実行
される実行時にアプリケーションプログラムが行う措置
も表している。図５の上部における「状況」ステートメ
ントは、ネットワークコマンドのタイプに応じてネット
ワークコマンドが別様に処理されることになるというこ
とを表している。上述のように、本発明の実施例は、ネ
ットワークコマンドから生成されたソースコードが、ネ
ットワークで利用可能なアプリケーションプログラム２
０６の一部になるということを意図したものである。

【００６４】ここで図５を参照すると、プリプロセッサ
が受信しようとする第１のタイプのネットワークコマン
ドは、クライアントとサーバとの間の初期接続をセット
アップするために利用されるものである。従って、本発
明の実施例では、アプリケーションプログラムの常駐す
るネットワーク化プラットホームが、或る特定の状況に
おいてサーバとして働くことになる場合、次いでいくつ
かのステップを踏まなければならないように考えられて
いる。また、ネットワーク化プラットホームがクライア
ントとして用いられることになる場合には、別のステッ
プを踏む必要がある。

【００６５】以上の論考を考慮すると、初期設定に関す
るネットワークコマンドの受信時に本発明により踏まな
ければならない最初のステップは、ネットワーク化プラ
ットホームをサーバとして利用すべきか否かを決定する
ことである。これを判定ブロック５０２で示す。ネット
ワーク化プラットホームをサーバとして利用すべきであ
ると判定された場合には、サーバ（即ち、ポート）によ
り利用可能になるサービスが見つけ出されるべき物理ア
ドレスの設定機能を備えた、適合するプログラミング言
語コードが生成される。次いで、サーバは、該物理アド
レスからのメッセージを調べて、そのメッセージを、利
用可能なサービスに関するメッセージとして取り扱う。
これをブロック５０４に示す。

【００６６】本発明の実施例は、上述の機能を実施する
ネットワークコマンドが「LISTENON name adress」の形
式をとるように構想されている。ここで、「LISTEN O
N」は、ネットワーク化プラットホームをサーバとして
用いるべきであることを表しており、「name」は、サー
バにより提供されるサービスの名称であり、「ａｄｒｅ
ｓｓ」は、サーバが常駐する物理アドレスである。この
方法では、クライアントは、サービスの名称を知ること
しか必要とせず、次いで名称とサーバにより提供される
物理アドレスとを関連づけることができる。本発明の他
の実施例では、上述のネットワークコマンドの形式にト
ランスポートのタイプも含まれるように考えられてい
る。この方法の場合には、サーバは複数のトランスポー
トを介して利用することが可能である。

【００６７】「ＬＩＳＴＥＮ ＯＮ」タイプのコマンド
の結果として生成されることが可能なプログラミング言
語のソースコードとしては、例えば、Ｃプログラミング
言語を用いることができる。しかし、本発明は他の形式
のネットワークコマンドの利用も考慮したものであり、
他の各種プログラミング言語の利用が可能であるという
点も当然のことながら理解されるべきである。ネットワ
ークコマンドから生成された、プログラミング言語のソ
ースコードが、機能呼び出しを含む点に留意されたい。
こうした機能呼び出しは、実行時／コンフィギュレーシ
ョン機構２１６に対する呼び出しを意図したものであ
る。

【００６８】本発明の実施例としては、実行時／コンフ
ィギュレーション機構２１６に対する呼び出しを必要と
せず、必要な全ての機能性（プログラミング言語のソー
スコードの形式をとるもの）をネットワークコマンドプ
リプロセッサ２０４により生成することができるものも
考えられる。勿論、この場合には、ネットワークで利用
可能なアプリケーションプログラム２０６がかなり大き
くなってしまい、通常は効率の良い設計でなくなる。

【００６９】判定ブロック５０２を参照すると、ネット
ワーク化プラットホームがサーバとして利用されていな
い場合には、その代わりにクライアントとして利用され
る。従って、この場合の次のステップは、サーバとして
用いられているネットワーク化プラットホームとの接続
を行うことである。これをブロック５０６で示す。この
時点で、適合するプログラミング言語のソースコード
が、「LISTEN」ネットワークコマンド（又はそれと等価
なネットワークコマンド）についてソースコードを生成
する場合と同じ方法で生成される。

【００７０】本発明の実施例には、上述の機能を実施す
るネットワークコマンドが、「TALKTO name」の形式を
とるように構想されたものがあり、ここで、「TALK T
O」は、ネットワーク化プラットホームが他のネットワ
ーク化プラットホームとの通信を望んでいることを表し
ており、「name」は、他のネットワーク化プラットホー
ムで要求されたサービスの名称である。ネットワークコ
マンド「LISTEN ON」が、サーバの物理アドレスをクラ
イアントに提供するので、クライアントは、要求された
サービスの名称を知ることしか必要としない。

【００７１】本発明の実施例として考えられるもう１つ
のタイプのネットワークコマンドは、ネットワークから
のメッセージの受信に関するものである。本発明により
考えられる実施例の場合、ネットワーク化プラットホー
ムは、メッセージの読み出しを試みる前に、いつメッセ
ージが利用可能になるのかに関する指示を受信するか、
さもなければ所定時間だけウエイトすることになる。メ
ッセージの受信中に、その受信メッセージに必要なデー
タ変換が行われる。本発明のいくつかの実施例により考
えられるように、上述の機能を実施するネットワークコ
マンドは、「RECEIVE VALUES」の形式をとり、この場
合、メッセージの検索を試みる前に、オプションパラメ
ータが、メッセージが利用可能であるという指示を待つ
か、さもなければ所定時間だけウェイトするかの指示を
行うことができる。

【００７２】上述のように、本発明の実施例は、メッセ
ージの受信中に受信側のネットワーク化プラットホーム
により必要なデータ変換が行われるように考えられたも
のである。従って、メッセージを受信すると、データ変
換が必要であるか否かの判定を行う必要がある。これを
判定ブロック５０８に示す。本発明の実施例は、変換が
必要であるか否か（即ち、メッセージが送られてくる送
信側のネットワーク化プラットホームが、受信側のネッ
トワーク化プラットホームのものとは異なるコンパイ
ラ、プログラミング言語、及び／又はプロセッサを用い
たか否か）をユーザが指示するように考えられたもので
ある。但し、他の実施例では、いつ、どんなタイプのデ
ータ変換が必要であるかの判定が自動的に行われる。い
ずれにしても、変換が不要な場合には、ブロック５１４
に示すように（対応するデータ記述のない）ユーザデー
タを含むメッセージを受信する。次いで、メッセージ
は、ブロック２０６に示すネットワークで利用可能なア
プリケーションプログラムの一部として格納される。

【００７３】また、変換が必要である場合には、本発明
は、この場合、データ記述とユーザデータとから構成さ
れるメッセージを受信する。これをブロック５１０に示
す。上述のように、本発明の実施例では、このデータ記
述により、メッセージを送るネットワーク化プラットホ
ームの特性が示されるようになっている。

【００７４】データ記述を受信すると、次のステップ
は、送信側のネットワーク化プラットホームのアプリケ
ーションプログラムにより生成されるユーザデータと、
受信側のネットワーク化プラットホーム上のアプリケー
ションプログラムによるユーザデータとの間での考え得
る相違に対処するのに必要な変換を容易化することであ
る。これをブロック５１２に示す。本発明の実施例で構
想されているように、これは、実行時／コンフィギュレ
ーション機構２１６にアクセスしてデータ変換を実行す
る各種機能呼び出しが生成されることを意味する。前記
相違に対処するための考え得るタイプのデータ変換に
は、アライメント、バイト配列、ＣＰＵの相違、及びコ
ンパイラの言語の相違が含まれている。

【００７５】上述のように、本発明の実施例では、いつ
データ変換が必要となるかをユーザが指示するように考
えられている。この目的のため、本発明の実施例には、
ネットワークコマンド「COMPILER IS language＿vendor
＿name」及び「CONVERSION」を使用可能なものがある。
「COMPILER IS」の場合、そのパラメータ「language＿v
endor＿name」は、アプリケーションプログラム（例え
ば、Microsoft C)をコンパイルするために用いられるコ
ンパイラの言語及びタイプである。ネットワークコマン
ド「CONVERSION」の場合、パラメータを指定して、１）
サーバ及びクライアントのネットワーク化プラットホー
ムにおけるアプリケーションプログラム及びＣＰＵに相
違がないこと、２）サーバ及びクライアントのアプリケ
ーションプログラムが同じプログラミング言語を用いて
開発されているが、ネットワーク化プラットホームにお
けるコンパイラ及び／又はＣＰＵが異なること、或い
は、３）言語（従ってコンパイラ）及びＣＰＵが異なる
こと、を示すことができる。本発明の実施例は、サーバ
及びクライアントの両方におけるアプリケーションプロ
グラムに、特定の環境に対応した適切な変換コマンドが
含まれるように考えられたものである。

【００７６】ネットワーク化プラットホームへのメッセ
ージの送信に関して、まず、ブロック５１８に示すよう
に、他のネットワーク化プラットホームが最終的にメッ
セージを受信する際に、データ変換が必要であるか否か
に関して判定が行われる。変換が必要でないと判定され
た場合、ブロック５１６で示すように、ユーザデータだ
けしか含まないメッセージが送られる。また、変換が必
要であると判定された場合には、ブロック５２０に示す
ように、ユーザデータ及びメッセージと共に、データ記
述が送られる。

【００７７】本発明のいくつかの実施例により考えられ
ているように、メッセージの送信機能を実施するネット
ワークコマンドは、「SEND」コマンドである。このネッ
トワークコマンドを用いて、サーバがクライアントにメ
ッセージを送ったり、クライアントがサーバにメッセー
ジを送ったりすることができるようにすることが考えら
れている。それらの実施例の場合、ネットワークコマン
ド「COMPILER IS」及び「CONVERSION」（又はその等価
なもの）によりセットされるパラメータに応じて、ネッ
トワークコマンド「SEND」が、受信側のネットワーク化
プラットホームにデータ記述を送ってユーザデータの特
性を示すことができる。

【００７８】図６ないし図８には、或るデータ構造で宣
言された変数の一例、及び各種プロセッサを用いて該変
数内におけるデータ（アプリケーションプログラムによ
り生成される）をマシン上に表す方法、及び各種の言語
及びコンパイラを用いてアプリケーションプログラムの
開発が行われた場所が示されている。この特定の例にお
けるデータ構造は、「emp＿record」(「employee recor
d」の略)と題され、Ｃプログラミング言語で見受けられ
るフォーマットを用いるものである。この構造は、文字
及び各種形式の整数を含む異なるタイプの変数のいくつ
かを示すものである。もちろん、図６ないし図８に示す
データ構造は単なる一例でしかなく、他のタイプのデー
タ構造（他のプログラミング言語を用いて書かれるも
の）も考えられていることが理解されるべきである。

【００７９】図６ないし図８におけるデータ構造の下位
は、各種マシンが（各種言語及びコンパイラを用いて）
ユーザデータを構成するフォーマットである。図６に
は、HP-UXオペレーティングシステムを実行する HP PA
RISCプロセッサを備えたヒューレットパッカード社のシ
リーズ800 マシンによるデータ表現の一例が示されてい
る。この場合、データを生成したアプリケーションプロ
グラムは、Ｃプログラミング言語を用いて開発され、HP
-Cコンパイラを用いてコンパイルされた。データ構造の
各種変数からのデータが送り出される方法に留意された
い。この場合、各英字／数字フィールドは１バイトを表
す。ハッシュブロックは空のフィールドを表し、その空
のフィールドの構成は、用いられる特定のプロセッサ、
言語、及び／又はコンパイラの関数となる。

【００８０】アプリケーションプログラムと共に用いら
れるプロセッサが、ヒューレットパッカード社のシリー
ズ300マシンからの Motorola 68030プロセッサであり、
従って２つのマシンのプロセッサが異なるという点を除
き、同じユーザデータを利用した一例を図７に示す。こ
のシリーズ300 ネットワーク化プラットホームにデータ
が格納される方法は、図６のシリーズ800 ネットワーク
化プラットホームの場合と同じである。しかし、これら
２つのフォーマットにおける１つの相違点は、変数「se
c」と変数「date of hire」との間の未使用スペース量
において明らかである。シリーズ800 マシンの場合、こ
れら２つの変数間における未使用スペース量は３バイト
であり、一方、シリーズ300 のマシン場合には、その未
使用スペース量は１バイトである。従って、２つのマシ
ン間におけるユーザデータは「アライメントがとれない
（misaligned）」と言われる。

【００８１】図６及び図７の例では、ユーザデータが、
シリーズ800 ネットワーク化プラットホームからシリー
ズ300 ネットワーク化プラットホームに送られている場
合に、シリーズ800 ネットワーク化プラットホームから
のユーザデータの「アライメントをとって」、ユーザデ
ータの構成がシリーズ300 ネットワーク化プラットホー
ムにより期待されるフォーマットと一致するようにしな
ければならない。上述のように、本発明の実施例は、こ
うした変換が、ユーザデータを受信するネットワーク化
プラットホームにより実施されることを意図したもので
ある。

【００８２】上述のように、図６及び図７の例の間の唯
一の相違点はプロセッサのタイプである。これらのマシ
ンに常駐するアプリケーションプログラムの開発に用い
られる言語及びコンパイラのタイプは同一である。同一
でなければ、別のタイプの変換を実施しなければならな
い可能性がある。前記２つの例のものとはコンパイラの
タイプが異なる（プロセッサのタイプも異なる）場合を
図８に示す。この図８の例の場合、生成されたユーザデ
ータは、ＤＯＳオペレーティングシステムを実行し、Mi
crosoft Cコンパイラを用いる、80286マイクロプロセッ
サを備えた、パーソナルコンピュータ上でコンパイルさ
れたアプリケーションプログラムによるものである。

【００８３】シリーズ800HP-C 又はシリーズ300HP-C ネ
ットワーク化プラットホームと、図８の 80286 Microso
ft Cネットワーク化プラットホームとの相違は、ユーザ
データのアライメントだけでなく、或る変数に割り当て
られたバイト量及びユーザその変数内のデータのオリエ
ンテーションも異なる。例えば、変数「request type」
には、図８の例では、２バイトしか割り当てられない
が、図６及び図７の例におけるフォーマットでは４バイ
トが割り当てられている。更に、変数内の数の表現が逆
になり、図８の例では数１が変数の最も左の部分に配置
され、図６及び図７の例では数１が変数の最も右のバイ
トにある。従って、データ変換は、いくつかのバイトの
アライメントを単にとり直す場合よりも一層実質的なも
のになる。こうした変換は本発明により有効に実施され
る。

【００８４】ＩＩＩ．実行時／コンフィギュレーション
機構 次に、図９に関連して、実行時／コンフィギュレーショ
ン機構２１６及びその周囲の環境について説明を行うこ
とにする。留意すべきは、下記説明で、アプリケーショ
ンプログラム（ブロック７０８で示す）の実行中におけ
る利用に関連して実行時／コンフィギュレーション機構
２１６の解説が行われる点である。但し、上述のよう
に、本発明の実施例は、図２のリンカ２１２に関連して
論じたリンク段階においても、実行時／コンフィギュレ
ーション機構２１６を利用する。

【００８５】上述のリンカ２１２を利用した実施例に
は、プログラミング言語ソースコードを生成して、アプ
リケーションプログラムの開発者が簡単かつ効率よく実
行時／コンフィギュレーション機構にアクセスできるよ
うにする、ネットワークコマンドプリプロセッサ２０４
を利用するものもある。しかし、本発明の意図する他の
実施例では、ネットワークコマンドプリプロセッサ２０
４及びそれに関連するネットワークコマンドを用いなく
ても、ユーザが直接アクセスすることができる、実行時
／コンフィギュレーション機構２１６が構想されてい
る。この方法の場合、ユーザは、一層柔軟性をもって、
実行時／コンフィギュレーション機構２１６を制御し、
ネットワーク環境にアクセスすることになる。しかしな
がら、これらの実施例の場合、ユーザは、手動で、別様
であれば、ネットワークコマンドプリプロセッサ２０４
により自動的に生成される情報を、実行時／コンフィギ
ュレーション機構２１６に供給する必要がある。

【００８６】次に、図９を参照すると、この図は、解説
目的のため、クライアント／サーバ１０２であるネット
ワーク化プラットホームの拡大図となるように意図され
たものであるが、これは、図１に示した任意のネットワ
ーク化プラットホームの拡大版ともなり得るものであ
る。図９に示すように、実行時／コンフィギュレーショ
ン機構２１６の周囲のネットワーク化プラットホームの
構成要素には、実行時／コンフィギュレーション機構２
１６が常駐するＲＡＭ７１６が含まれている。しかし、
留意すべきは、本発明が、ＲＡＭ７１６の代わりに、及
び／又はＲＡＭ７１６に関連して、各種のバッファ及び
磁気又は光学ディスク記憶装置を含む他のメモリ／記憶
装置を用いることができる実施例も考えているという点
である。

【００８７】本発明の実施例の意図するところによれ
ば、本発明に用いられるＲＡＭ７１６はバス７０２に取
り付けられる。このバスには、ＣＰＵ７０４及びＩ／Ｏ
装置７０６も取り付けられる。もちろん、本発明は複数
のＣＰＵ及び複数のＩ／Ｏ装置を備えた環境における利
用を考慮したものであるということが理解されよう。

【００８８】図９には、ネイティブトランスポート７１
４も示されている。これらネイティブトランスポート７
１４は、トランスポート機構の製造業者により作られ
た、データ転送を容易にするトランスポートの一部であ
る。従って、ＴＣＰ／ＩＰがトランスポートとして用い
られる場合には、そのトランスポートを介したデータ転
送を容易にするのに適したネイティブトランスポート
が、そのトランスポートの配給業者により提供される。
本発明の実施例では、クライアント／サーバ１０２が共
に利用されることになる各タイプのトランスポート毎に
ネイティブトランスポートが必要になる。こうしたネイ
ティブトランスポートの一例として、カリフォルニア州
マウンテンビューの 3Comm製の Ethernet Board を備え
た Novelle製のSPXがある。

【００８９】ＲＡＭ７１６内にはアプリケーションプロ
グラム７０８が示されており、このアプリケーションプ
ログラム７０８は、１つ以上のトランスポートを介して
メッセージを送ること、或いは、１つ以上のトランスポ
ートからメッセージを受け取ることが所望の場合に、実
行時／コンフィギュレーション機構２１６と（機能呼び
出しを介して）通信を行うものである。実行時／コンフ
ィギュレーション機構２１６自体は、図示のように、管
理エンティティ７１０及びトランスポートエージェント
（agent）７１２から構成される。

【００９０】次に、図１０に関して、管理エンティティ
７１０について詳述することにする。図１０において、
アプリケーションプログラム７０８は、ネットワーク環
境を介してどこにデータを転送すべきか、及び、どんな
データを送るべきかを示すコマンドを（ネットワークコ
マンドプリプロセッサ２０４により生成されたか、或い
はユーザにより直接生成された、機能呼び出しを介し
て）入力ボックス(inbox）８０２に送信する。従って、
入力ボックス８０２は、アプリケーションプログラム７
０８と管理エンティティ７１０の残りの部分との間にお
ける一種の待ち行列／インターフェイスとして働く。

【００９１】入力ボックス８０２の利用（及び本発明の
他の態様）の例として、管理エンティティ７１０の常駐
するネットワーク化プラットホームがサーバとして働く
場合、アプリケーションプログラム７０８は、ネットワ
ーク環境と接続を行うことを所望することが可能であ
り、これにより、アプリケーションプログラム７０８が
メッセージを受信することが可能となり、及びそのアプ
リケーションプログラム７０８の提供するサービスのネ
ットワーク環境による利用が可能となる。これを実施可
能にするコマンドは、入力ボックス８０２に送られ、次
いでコンフィギュレーションモジュール８０８に送られ
る。本発明の実施例中には、ネットワークコマンドLIST
EN ON の結果として生成された機能呼び出しにより、こ
うしたコマンドを送ることができるものもある。

【００９２】上述のコマンドをコンフィギュレーション
モジュール８０８が受信すると、次にコンフィギュレー
ション情報２２０をチェックして、ネットワーク化プラ
ットホームがコマンドの受信に待機すべき物理アドレス
を決定する。例えばアプリケーションプログラム７０８
は、サービス「受信可能な記述(accounts receivabl
e)」 に関するメッセージをクライアントから受信する
ことを所望することが可能である。アプリケーションプ
ログラム７０８がそのメッセージを入力ボックス８０２
に送ると、コンフィギュレーションモジュール８０８が
コンフィギュレーション情報２２０をチェックして、受
信可能な記述に関するサービスの受信に対してネットワ
ーク化プラットホームが待機すべき物理アドレスがどれ
かを確認する。本発明の実施例の意図するところによれ
ば、特定のサービスについて用いるべきネットワーク化
プラットホームにおける特定の物理アドレス（即ち、ポ
ート）をユーザが前もって指定しておくことになる。

【００９３】物理アドレスが決定すると、接続管理モジ
ュール８１０は、サービスにアクセスするためのメッセ
ージの受信に備えて、資源の割り当てを行うように命令
を受ける。本発明の実施例の構想によれば、トランスポ
ートエージェント７１２が、（事象ディスパッチモジュ
ール８２０を介して）資源を割り当てるための命令を受
信し、指定された物理アドレスからメッセージを受け取
る。

【００９４】また、管理エンティティ７１０が常駐する
ネットワーク化プラットホームが、クライアントとして
働く場合には、アプリケーションプログラム７０８は、
他のネットワーク化プラットホーム（即ち、サーバ）と
通信を行うことが所望である旨のコマンドを入力ボック
ス８０２に送ることが可能である。本発明の実施例に
は、コマンドTALK TO の結果として生成された機能呼び
出しにより、こうしたコマンドを送ることができるもの
もある。いずれにせよ、本発明の実施例の意図するとこ
ろによれば、アプリケーションプログラム７０８が、通
信を所望するサービス名を送り、このコマンドがコンフ
ィギュレーションモジュール８０８に送られる。次に、
適合するサーバ（及びその内部のポート）のネットワー
ク化プラットホームについての物理アドレスが、アプリ
ケーションプログラム７０８により供給された名称から
決定され、この物理アドレスが接続管理モジュール８１
０に送られる。次いで、接続管理モジュール８１０は、
事象ディスパッチャ８２０にメッセージを送り、該事象
ディスパッチャ８２０は、適合するトランスポートエー
ジェント７１２を用いて、指定物理アドレスにおける適
合するネットワーク化プラットホームとの接続を開始す
る。

【００９５】本発明の意図する実施例では、他のネット
ワーク化プラットホームにおける特定のサービスに対す
るアクセスを可能にするため、ユーザが、コンフィギュ
レーション情報２２０において物理アドレスを提供す
る。また、本発明の実施例の意図するところによれば、
特定のサービス名に関連して複数の物理アドレスが存在
する場合に、第１の物理アドレスは、遠隔ネットワーク
化プラットホームとの接続において常に主経路として用
いられ、残りの物理アドレスは、代替経路として用いら
れる。

【００９６】上述の実施例中には、クライアントとして
働くネットワーク化プラットホームが、要求されるサー
ビスのアドレスを得て、適合するサービスとの通信を開
始することができるものもある。また、本発明の実施例
の意図するところによれば、コンフィギュレーション情
報２２０には、アプリケーションプログラムに対して利
用可能なトランスポートがどれであるかに関する情報が
含まれる（即ち、利用可能なネイティブトランスポート
の収集についての参照が含まれる）。従って、新しいト
ランスポート及びサーバを用いることになる場合、該ト
ランスポートの名称及びアドレスはコンフィギュレーシ
ョン情報２２０に含めることができる。この方法によれ
ば、新たに追加されたトランスポートを利用するために
アプリケーションプログラムのコンパイルをやり直す必
要がなくなる。

【００９７】上述のように、クライアントとサーバとの
間での通信が確立されると、ネットワーク化プラットホ
ーム間においてユーザデータの送信が可能になる。アプ
リケーションプログラム７０８は、ユーザデータの送信
を所望する場合にそれを入力ボックス８０２に送り、該
入力ボックス８０２は次いでそのユーザデータをデータ
出力モジュール８１４に送る。このデータ出力モジュー
ル８１４には、それに送られてくる情報を入れるための
待ち行列が含まれている。待ち行列を操作するための機
構は、待ち行列管理モジュール８１２により容易にな
る。

【００９８】データ出力モジュール８１４は、送られて
くるデータに関するデータ記述を受け取り、それを事象
ディスパッチャ８２０に送る。本発明の意図する実施例
の場合、データ記述はネットワークコマンドプリプロセ
ッサ２０４により生成される。しかしながら、ネットワ
ークコマンドプリプロセッサ２０４を使用しない本発明
の実施例の場合、管理エンティティ７１０を使用してい
るユーザはデータ記述自体を生成する必要がある。

【００９９】ネットワーク化プラットホーム（サーバ又
はクライアント）が他のネットワーク化プラットホーム
からメッセージを受け取る場合には、モジュール８１６
内のデータが用いられる。データ出力モジュール８１４
の場合と同様に、モジュール８１６内のデータは待ち行
列を維持して、ユーザデータを格納し、及び待ち行列管
理モジュール８１２を用いてその待ち行列の管理を行
う。次いで、受信したメッセージが出力ボックス８０４
に送られる。この出力ボックス８０４は、管理エンティ
ティ７１０とアプリケーションプログラム７０８との間
のインターフェイスとして働くものである。或るデータ
記述（何らかのデータ変換が必要であることを示すも
の）と共にメッセージを受け取った場合、そのデータは
変換モジュール８０６に送られる。次いで変換モジュー
ル８０６は、そのユーザデータを、現在のネットワーク
化プラットホームに適合するフォーマットに変換する。
また、変換が不要である場合には、ユーザデータは次い
でアプリケーションプログラム７０８に直接送られる。

【０１００】上述のように、メッセージは、事象ディス
パッチャ８２０に送られると、次に、適合するトランス
ポートエージェント７１２に送られる。本発明の実施例
の意図するところによれば、ネットワーク化プラットホ
ームを取り付けることが予想される各トランスポートエ
ージェントは、実行時／コンフィギュレーション機構２
１６に最初から組み込んでおくべきである。この方法に
よれば、新しいトランスポートをネットワーク化プラッ
トホームに取り付ける際に、コンフィギュレーション情
報２２０を更新するだけですむ。上述の方法を用いなか
った場合には、新しいトランスポートエージェントを実
行時／コンフィギュレーション機構２１６に組み込まな
ければならないし、アプリケーションプログラムをリン
クし直さなければならない（但し、コンパイルし直す必
要はない）。

【０１０１】本発明の実施例により意図する一般的なト
ランスポートエージェントの例を、図１１に詳細に示
す。同図を参照すると、制御モジュール９０２が事象デ
ィスパッチャ８２０からメッセージを受信する。この制
御モジュール９０２は、トランスポートエージェント９
１２と事象ディスパッチャ８２０が属している管理エン
ティティ７１０との間のインターフェイスである。

【０１０２】開始／受信／維持・接続モジュール９０４
がネイティブトランスポート９１４との接続を行い、次
いで、そのネイティブトランスポート９１４がネットワ
ーク環境との接続を行う。本発明の実施例の意図すると
ころによれば、このモジュール９０４を用いることによ
り、通信中のネットワーク化プラットホームにエラーが
生じたかどうかを示すことができる。

【０１０３】データ送信モジュール９０６及びデータ受
信モジュール９０８が、それぞれ、ネットワーク化プラ
ットホームとの間のデータの送受信、及びネイティブト
ランスポート９１４との間のデータの送受信を容易にす
る。また、本発明の実施例の意図したところによれば、
これらのモジュールを用いて、特定のトランスポートが
１度に取り扱うことの可能なバイト数を決めることがで
きる。従って、データ送信モジュール９０６及びデータ
受信モジュール９０８は、トランスポートエージェント
９１２が送信又は受信可能な情報量（即ち、メッセージ
の量及び／又はサイズ）と、特定のトランスポートが取
り扱うことの可能なデータ量との間の不一致を自動的に
補償する。

【０１０４】エラーマッピングモジュール９１０は、メ
ッセージ転送処理中のエラーを受け取って、そのエラー
コードを標準フォーマットに変換する。この方法の場
合、たとえ、他のネットワーク化プラットホームでエラ
ーコードが発生して送られたとしても、エラーマッピン
グモジュール９１０が、現在のネットワーク化プラット
ホームにより簡単に認識することの可能なプロトコルに
そのエラーコードを変換する。この情報は、次いで、制
御モジュール９０２に、及び事象ディスパッチャ８２０
に戻される。

【０１０５】ＩＶ．コンピュータプログラム例 本発明の実施例に用いられる２つのコンピュータプログ
ラムの例を以下で説明する。本発明の実施例の働きが一
層良好に理解されるように、プログラムをその各行毎に
説明することとする。

【０１０６】より詳細には、この２つのコンピュータプ
ログラムは、クライアントとして働くネットワーク化プ
ラットホームについてのプログラムと、サーバとして働
くネットワーク化プラットホームについてのプログラム
とから構成される。クライアントプログラムは、Micros
oft ＤＯＳオペレーティングシステムを用いるIBM PC用
のMicrosoft Ｃで書かれ、またサーバプログラムは、Ｕ
ＮＩＸオペレーティングシステムを用いるヒューレット
パッカード社のシリーズHP9000マルチユーザマシン上で
ヒューレットパッカード社のＣＯＢＯＬにより書かれ
る。この例の場合、クライアントプログラムは、ユーザ
からの使用(employee)データベース要求（照会、更
新．．．）を受信し、次いでそのユーザの要求を、サー
バとして働くネットワーク化プラットホーム上のサーバ
プログラムに送る。

【０１０７】サーバプログラムは、続いて、クライアン
トプログラムから使用データベース要求を受信する。次
に、サーバプログラムは、使用データベースの更新、及
び／又は使用データベースからの情報の読み出しを実行
し、クライアントとして働くネットワーク化プラットホ
ームに回答を送る。クライアントプログラムは、サーバ
プログラムから回答を受信した後、新しい使用データを
ユーザのコンソールに表示させる。

【０１０８】次に、IBM PC用のMicrosoft Ｃを用いてク
ライアントプログラムを作成する場合の一例を、そのク
ライアントプログラムの各行を追って説明する（但し、
その具体的なソースコードの記載は省略することとす
る）。

【０１０９】行１： プログラムが、Microsoft 社のＣ
コンパイラ用に書かれたものであることを示す。

【０１１０】行２： クライアントプログラムとサーバ
プログラムとが異なる言語で書かれるため、コマンド C
ONVERSION DIFFERENT LANGUAGE を用いる。

【０１１１】行３及び行９：クライアントプログラムと
サーバプログラムとの間で交換されるデータ構造につい
ての宣言セクションとする。

【０１１２】行４〜行８：使用(employee)レコードのデ
ータ構造を宣言する。これには、４つのフィールド、即
ち、要求タイプフィールドと、使用(employee)名フィー
ルドと、使用(employee)数フィールドと、サラリー(sal
ary)フィールドとが含まれる。この例の目的のため、そ
のデータ構造がクライアントプログラムとサーバプログ
ラムとの間で送られる際に、そのアライメントとＣＰＵ
タイプと言語との相違により、該データ構造のデータ変
換が行われることになる点に留意されたい。

【０１１３】行１３： このクライアントプログラムか
らネットワークコマンド TALK を送出して、サーバとし
て働くネットワーク化プラットホーム上のサーバプログ
ラムに対する接続を行う。

【０１１４】行１４： 上述のステートメント TALK に
不具合がある場合には、Ncode を非ゼロにセットする。
この場合、クライアントプログラムは手順「close con
n」（即ち、close connection）を呼び出すことにより
終了する。

【０１１５】行１５： この行で下記の「Ｄｏ」行１６
〜行２２のループを開始させる。このループ（従ってク
ライアントプログラム）を出るのは何か不具合が生じた
場合（行１８及び２０）だけである。

【０１１６】行１６： ユーザから要求を受け入れる。
この例の場合、要求は、使用データベースからの「情報
読み出し」、又はクライアントにより入力された新しい
情報による使用データベースの更新を行うことができ
る。

【０１１７】行１７： ユーザ要求をサーバに送る。ク
ライアントプログラム及びサーバプログラムが、異なる
ネットワーク化プラットホーム（HP9000及びIBM PC）上
にあり、異なる言語で書かれており（Ｃ及びＣＯＢＯＬ
コンパイラ）、異なるデータアライメントを用いてお
り、データタイプが異なる（「サラリー」は、IBM PC上
では浮動小数点であり、HP9000上では数値表示である）
ため、ステートメントSEND が、使用(employee）データ
に加えて、使用データ構造記述子をクライアントプログ
ラムからサーバプログラムに送る。 行１８： エラーチェックステートメントとする。

【０１１８】行１９： この行を用いて、サーバプログ
ラムからの新しい使用(employee)情報を備えた回答を受
信する。クライアント及びサーバが、異なるネットワー
ク化プラットホーム上にあり、異なる言語を用い、異な
るデータアライメントを用い、異なるデータタイプを有
するため、ステートメント RECEIVEにより、データに加
えてデータ記述子を受信する。次いで、サーバプログラ
ムにより送られてきたデータ記述子に基づいてデータ変
換操作を実行し、その変換後のデータを行４〜行８で宣
言したデータ構造で格納するようにする。

【０１１９】行２０： エラーチェックステートメント
とする。

【０１２０】行２１： 新たに受信した使用情報をユー
ザのコンソールに表示させる。

【０１２１】行２２： 連続ループの終了行とする。

【０１２２】行２４〜行２８：手順 Close＿connを規定
する。ネットワークの動作に不具合が生じた場合にこの
手順を呼び出してクライアントプログラムの実行を終了
させるようにする。この手順は、行１４，１８，２０か
ら呼び出される。

【０１２３】次に、ヒューレットパッカード社のシリー
ズHP9000マルチユーザマシン上でヒューレットパッカー
ド社のＣＯＢＯＬを用いてサーバプログラムを作成する
場合の一例を、そのサーバプログラムの各行を追って説
明する（但し、その具体的なソースコードの記載は省略
することとする）。

【０１２４】行１〜７： 標準的なＣＯＢＯＬプログラ
ミングステートメントとする。

【０１２５】行８： プログラムが、ヒューレットパッ
カード社のＣＯＢＯＬコンパイラ用に書かれたものであ
ることを示す。

【０１２６】行９： クライアントプログラムが Micro
soft社のＣコンパイラ用に書かれているので、変換が必
要になる。

【０１２７】行１０及び１６：クライアントプログラム
とサーバプログラムとの間で交換されるデータ構造の宣
言セクションとする。

【０１２８】行１１〜１５：使用レコードのデータ構造
を宣言する。これには、４つのフィールド、即ち、要求
タイプフィールドと、使用名フィールドと、使用数フィ
ールドと、サラリーフィールドとが含まれる。アライメ
ントとＣＰＵタイプと言語との相違により、クライアン
トプログラムとサーバプログラムとの間でデータ変換が
行われることになる。

【０１２９】行２１： このサーバプログラムからステ
ートメント LISTEN を送出し、クライアントプログラム
からの要求の受信に備える。

【０１３０】行２２： ステートメント LISTEN が成功
したかどうかをチェックする。成功しなかった場合に
は、このサーバプログラムを CLOSE＿CONNに「移行」さ
せ、接続を打ち切って、このプログラムを出る。

【０１３１】行２３： ループ開始位置（ラベル）を定
義する。

【０１３２】行２５： このサーバプログラムによりス
テートメントRECEIVE を送出して、クライアントプログ
ラムからの要求を受信する。クライアント及びサーバ
が、異なるネットワーク化プラットホーム（HP9000及び
IBM PC）上にあり、異なる言語（Ｃ及びＣＯＢＯＬコン
パイラ）を用い、異なるデータアライメントを用い、及
び異なるデータタイプを有する（「サラリー」は、IBMP
C上では浮動小数点であり、HP9000上では数値表示であ
る）ため、このステートメントRECEIVE は、データに加
えてデータ記述子を受信する。このサーバプログラムに
より、次に、クライアントプログラムにより送られてき
たデータ記述子に基づいてデータ変換操作を実行し、そ
の変換後のデータを行１１〜１５に宣言したデータ構造
で格納するようにする。

【０１３３】行２７： このサーバプログラムにより
「データベース更新」プログラムを呼び出して読み出し
又は更新操作を実行させる。

【０１３４】行２８： このサーバプログラムからステ
ートメントSENDを送出することにより「データベース更
新」プログラムから結果を送り返す。クライアント及び
サーバが、異なるネットワーク化プラットホーム上にあ
り、異なる言語を用い、異なるデータアライメントを用
い、異なるデータタイプを有するため、ステートメント
SENDにより、使用データに加えて使用データ構造記述子
をクライアントプログラムからサーバプログラムに送る
ことになる。

【０１３５】行２９： 行２３に戻ってクライアントに
よる次の要求を処理する。

【０１３６】もちろん、本発明は上述の実施例に限定さ
れるものではなく、上述の例は単なる例示を目的とした
ものでしかない。従って、本発明の範囲は、上記説明及
び図面により明確にされた特許請求の範囲の記載に従っ
て解釈されるべきである。

【０１３７】

【発明の効果】本発明は上述のように構成したので、特
性の異なるネットワーク化プラットホーム間における通
信を容易化し、またユーザにとって分かりやすい方法
で、各種トランスポートを介したネットワーク化プラッ
トホーム間の通信を容易化する、システム及び方法を提
供することができる。これにより、どんなタイプのネッ
トワーク化プラットホームと通信することになるかに気
を配ることなくアプリケーションプログラムの開発を行
うことが可能となり、通信先のネットワーク化プラット
ホームの各タイプ毎に複数バージョンの同じアプリケー
ションプログラムを開発する必要がなくなる。更に、ネ
ットワーク化プラットホーム間における情報の通信に用
いられるトランスポートのタイプに配慮することなくア
プリケーションプログラムの開発を行うことが可能とな
り、利用されるトランスポートの各タイプ毎にアプリケ
ーションプログラムを作成する必要がなくなる。

【図面の簡単な説明】

【図１】本発明の実施例で用いることを企図したネット
ワーク環境の一例を示すブロック図である。

【図２】本発明の実施例を示す上位レベルのブロック図
である。

【図３】本発明の実施例により用いることを企図したネ
ットワークコマンドプリプロセッサに関する情報のフロ
ーを示すブロック図である。

【図４】本発明の実施例により用いることを企図したネ
ットワークコマンドプリプロセッサによる処理を示すフ
ローチャートである。

【図５】本発明の実施例により企図するネットワークコ
マンドによる結果及び効果を示すフローチャートであ
る。

【図６】種々のネットワーク化プラットホーム上のアプ
リケーションプログラムにより生成される様々なユーザ
データの例を示すデータフォーマット図である。

【図７】種々のネットワーク化プラットホーム上のアプ
リケーションプログラムにより生成される様々なユーザ
データの例（図６の場合とは異なるプロセッサを用いた
場合）を示すデータフォーマット図である。

【図８】種々のネットワーク化プラットホーム上のアプ
リケーションプログラムにより生成される様々なユーザ
データの例（図７の場合とは異なるプロセッサ及びコン
パイラを用いた場合）を示すデータフォーマット図であ
る。

【図９】本発明の実施例により企図するネットワーク化
プラットホーム内の実行時／コンフィギュレーション機
構を示す上位レベルのブロック図である。

【図１０】本発明の実施例により企図する実行時／コン
フィギュレーション機構内の管理エンティティを示すブ
ロック図である。

【図１１】本発明の実施例により企図する実行時／コン
フィギュレーション機構内のトランスポートエージェン
トを示すブロック図である。

【符号の説明】

104,106,108,110 サーバ 112,114,116,118 クライアント 216 実行時／コンフィギュレーション機
構 710 管理エンティティ 712,912 トランスポートエージェント 714,914 ネイティブトランスポート 808 コンフィギュレーションモジュール

Claims (1)

【特許請求の範囲】
1. 【請求項１】ユーザデータ及びデータ記述を含むメッセ
   ージの送受信をネットワーク環境との間で行うことによ
   り、第１のプログラミング言語及び第１のコンパイラを
   用いて開発された第１のアプリケーションプログラム
   が、ネットワーク環境内の遠隔ネットワーク化プラット
   ホーム上にある、第２のプログラミング言語及び第２の
   コンパイラを用いて開発された第２のアプリケーション
   プログラムと情報の交換を行うことを可能とする通信シ
   ステムであって、 この通信システムが、 前記第１のアプリケーションプログラムが実行されるネ
   ットワーク化プラットホームと、 前記ネットワーク化プラットホーム及び前記ネットワー
   ク環境に応答し、前記ネットワーク化プラットホームと
   前記ネットワーク環境との間の通信を容易化する１つ以
   上のネイティブトランスポートとからなり、 前記ネットワーク化プラットホームが、 中央処理装置と、 前記ネットワーク化プラットホームにより提供されるサ
   ービスの名称及び物理アドレスを維持し、及び／又は、
   前記遠隔ネットワーク化プラットホームにより提供され
   るサービスの名称及び物理アドレスを維持し、また前記
   第１のアプリケーションプログラムによりアクセス可能
   な前記ネイティブトランスポートがどれであるかを示す
   コンフィギュレーションモジュール手段と、 前記遠隔ネットワーク化プラットホーム上の第２のアプ
   リケーションプログラムと通信を行い、前記コンフィギ
   ュレーションモジュール手段により選択された前記１つ
   以上のネイティブトランスポートのうちの対応する１つ
   を有するトランスポートエージェント手段と、 前記第１のアプリケーションプログラムから第１のメッ
   セージを受信し、その第１のメッセージを前記選択され
   たネイティブトランスポートを用いて前記第２のアプリ
   ケーションプログラムへ送信するデータ出力手段とから
   なり、 前記第１のメッセージが、前記第２のアプリケーション
   プログラムに対応する記述名を含み、その記述名に基づ
   いて前記コンフィギュレーションモジュール手段が前記
   第２のアプリケーションプログラムに対応する物理アド
   レスを生成して、前記第１のメッセージが前記第２のア
   プリケーションプログラムにより受信されることを可能
   とし、 更に、前記ネットワーク化プラットホームが、前記第２
   のアプリケーションプログラムから第２のメッセージを
   受信するデータ入力手段と、 第１及び第２のプログラミング言語及び／又は第１又は
   第２のコンパイラが互いに異なるため、及び／又は、前
   記ネットワーク化プラットホームの中央処理装置と前記
   遠隔ネットワーク化プラットホームの中央処理装置との
   間の相違のため、データ変換が必要とされるか否かを、
   前記第２のメッセージのデータ記述から検出し、必要と
   される任意のデータ変換を実行する変換手段とからな
   る、言語プリプロセッサ及び実行時ライブラリをネット
   ワークで利用するためのシステム。