JPH07281974A - ネットワーク内のコンピュータ間でデータを交換するための通信システム - Google Patents

Abstract

(57)【要約】 【目的】 クライアント／サーバ装置において動作する
ようにネットワーク内で接続された、第１のコンピュー
タと第２のコンピュータとの間のデータの交換を容易に
する。 【構成】 このシステムは、第１のコンピュータ上で走
行する第１のアプリケーションからの、第２のコンピュ
ータとの接続を求める要求を処理して、複数の通信サー
ビスのうちの１つを実施するための第１の論理手段と、
第２のコンピュータ上の第２のアプリケーションに通信
サービスを実施するよう指示し、第２のアプリケーショ
ンによって提供されたデータを第１のコンピュータに戻
すための第２の論理手段と、各コンピュータ上にあって
各論理手段によってアクセス可能であり、複数の通信サ
ービスのそれぞれに関する定義を提供する単一のオブジ
ェクト・クラスを記憶する記憶装置とを含む。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ネットワーク内で接続
された２台以上のコンピュータ間でのデータ交換を容易
にするための、通信システムおよびそのようなシステム
の動作方法に関する。詳細には、この通信システムはク
ライアント／サーバ型に基づくものであり、典型的なク
ライアント／サーバ型では、ネットワークの両端に接続
されたクライアント・コンピュータとサーバ・コンピュ
ータにおけるアプリケーション・プログラムの間で定期
的な通信をおこなう。クライアント・コンピュータは通
常、システムの使用者の近くにあり、サーバ・コンピュ
ータは様々な中央サービスを提供する。

【０００２】

【従来の技術】クライアント・コンピュータとサーバ・
コンピュータのアーキテクチャはしばしば、データを表
現しタスクを管理する方式が異なる。またその性質上、
サーバ・コンピュータのオペレーティング・システム
は、非常に複雑なことがあり（たとえば、ＩＢＭ社のＭ
ＶＳオペレーティング・システム）、十分な性能で動作
し、かつクライアント・システムによるユーザが十分に
サービスを受けるためは不可欠な十分な信頼性、可用
性、保守容易性（一般にＲＡＳとして知られる）を備え
るためには、システムの構造と機能に関する深い知識を
必要とする。

【０００３】通信システムは、クライアント・コンピュ
ータとサーバ・コンピュータの間の「インターフェー
ス」を提供し、クライアント・アプリケーション・プロ
グラムを書き込むプログラマは、このインターフェース
を利用して、クライアントとサーバの間で広範囲の基本
的要求および応答を通信する。これらの基本的要求に加
えてさらに、クライアント・アプリケーションに特に関
係する高レベルの要求を実施する必要があることもあ
る。

【０００４】クライアント・コンピュータとサーバ・コ
ンピュータの間の協働的処理をある程度容易にするイン
ターフェースを確立するために、様々な既知の技法があ
る。これらの技法は、多かれ少なかれ、ＡＰＰＣ（拡張
プログラム間通信機能：ＬＵ６．２ともいう）やＴＣＰ
／ＩＰプロトコルなどの基礎的通信プロトコルに依存す
る。

【０００５】既知のプログラミング・インターフェース
の１つは、たとえばＡＰＰＣなどの基本通信インターフ
ェースである。当業者には周知のように、ＡＰＰＣは、
分散データ・モデルのようなものについてのアーキテク
チャ「towers」を含む１組の膨大な数のＬＵ６．２機能
への「アプリケーション・プログラム・インターフェー
ス」（ＡＰＩ）アクセスを可能にする。他の通信プロト
コル（たとえば、ＴＣＰ／ＩＰ）は、その代替機能を提
供する。

【０００６】各クライアント・アプリケーション・プロ
グラムは、ＡＰＰＣの上にそれ自体の実施態様（インプ
リメンテーション）を開発することができるが、インタ
ーフェースの使用境界が予め定義されないので、特に複
雑な分野において労力や訓練の重複が生じ、全コードの
再使用がより困難になる。

【０００７】大部分のクライアント／サーバのための効
率的な実施態様は、クライアント・アプリケーション・
プログラマがＬＵ６．２などの通信プロトコルを深く理
解する必要のないものでなければならない。

【０００８】もう１つの既知のプログラミング・インタ
ーフェースは、リモート手順呼出し（ＲＰＣ）によって
提供される。この機能では、クライアント・アプリケー
ション・プログラムは単にサブルーチンを呼び出すだけ
でデータベースなどのリモート機能にアクセスし、通信
システムが、サブルーチンがローカルかリモートかを認
識する。リモートの場合には、呼出しはパッケージ化さ
れて、リンク（たとえば、ＬＵ６．２リンク）上をリモ
ート・システムに送られる。クライアント・アプリケー
ションはこの「機能伝送」について知らないので、呼出
しが戻るまで待機する。

【０００９】このＲＰＣ技法は、現在の強力なクライア
ント／サーバ・システムの必要性に対して十分な柔軟性
がない。この技法は、応答を受け取る前に他の処理を実
行可能にする柔軟性をもたず、リンクの透過性を維持す
る必要があるため実施が複雑になることがある。

【００１０】この型のインターフェースは、プログラマ
が、リモート・コンピュータへの通信が行われているこ
とをまったく知らないという点でまったく「透過」であ
るが、これは、クライアント／サーバ・システムがその
性能と可用性を最適化することが望まれる場合には理想
的ではない。そのような場合は、クライアント・アプリ
ケーション・プログラマが、要求のタイプ（リモート手
順呼出し、ファイル転送など）を非透過な方法で選択で
き、したがって、サーバ・アクセスが必要なとき、要求
のタイプに応じて、プログラマが最終ユーザに過度に影
響を与えない最良の決定を行えることが重要である。

【００１１】メッセージ駆動式処理技法において、（Ｉ
ＢＭの「ＭＱ Ｓｅｒｉｅｓ（キュー管理を行う）」の
製品によって提供されるような）アプリケーション・イ
ンターフェースは、分散されたアプリケーション間で完
全に非同期の待機通信を実現する。分散アプリケーショ
ンは、２台以上のコンピュータに部分的に存在するアプ
リケーションであり、それらの部分は互いに通信する必
要がある。このアプリケーション・インターフェース
は、ワークフロー管理に適した広範囲のメッセージ配布
と複雑な回復および保全性を提供する。

【００１２】分散アプリケーション間のメッセージを使
用する他のより簡単な通信方法も、特にワークステーシ
ョンのみの環境では存在する。

【００１３】より複雑なメッセージ駆動式処理技法（完
全なＭＱ Series の解法）は、密結合の協働的アプリケ
ーションには妥当ではなく「高価」すぎる。そのような
アプリケーションは、異なるコンピュータ上で走行する
別々の部分が、互いにいつ対話し聴取すべきかを知って
いるものである。１つの例は、専用クライアント／サー
バ通信システムである。この場合、クライアントは、サ
ーバに質問してサーバが答え、サーバは、質問されるま
でクライアントに決して話しかけない。そのようなアプ
リケーションでは、クライアントが要求を出しサーバが
すぐにそれを処理するので、非同期に待機する必要がな
い。

【００１４】一方、より簡単なメッセージ方法は、今日
の強力なクライアント／サーバ機能（ホストのデータベ
ースへの無制限のアクセスおよび性能を含む）に必要と
される、ＭＶＳなどのホスト・システム上ですぐには使
用できない。

【００１５】もう１つの既知の技法は、一般に「ローカ
ルＡＰＩエミュレーション」と呼ばれる。様々な協働的
プログラミング・インターフェースは、「ローカル」の
ＡＰＩの一部または全部をエミュレートすることに依拠
しており、この技法はある種の改良ＲＰＣと見なすこと
ができる。たとえば、ＩＢＭ社の製品 "ＡＣｏｎｎＳ"
は、ＯＳ／２プレゼンテーション・マネージャ・インタ
ーフェースのサブセットの分散バージョンによって、協
働的機能を提供した。標準的なＲＰＣ技法に勝る利点
は、クライアント・アプリケーションのプログラマが、
通信が進行中であり、したがって自分のアクティビティ
を最適化できることをはっきりと知っていることであ
る。一方、欠点は、複雑なローカルＡＰＩの分散が、扱
いにくく、高価で、不自然なことがあり得ることであ
る。さらに、分散ＡＰＩの概念は、広すぎたり、あるい
は、クライアント／サーバ・システムの特定の必要から
遠くかけ離れていたりすることがある。

【００１６】今日、多くのデータ処理システムは、シス
テム上で走行するアプリケーションによって「オブジェ
クト・インスタンス」が作成され使用される、メッセー
ジ・ベースの環境を有する。

【００１７】メッセージ・ベースの環境は、オブジェク
ト指向プログラミング（ＯＯＰ）技法によって使用さ
れ、このＯＯＰは、「オブジェクト」に送られる「メッ
セージ」によって必要な機能を実施するソフトウェア開
発の具体的手法である。「オブジェクト」は、関連する
手順（以下、「メソッド」と呼ぶ）とデータの集合体を
含むソフトウェア構成要素である。さらに、オブジェク
トは、「オブジェクト・クラス」に分類することがで
き、オブジェクト・クラスは、特定タイプのオブジェク
トに関するメソッドおよびデータを定義するためのテン
プレートである。所与のクラスのすべてのオブジェクト
は、形式と挙動が同一であるが、それに関連するデータ
が異なる。

【００１８】「メッセージ」は、オブジェクトにそのメ
ソッドのうちの１つを実行するように要求するために、
オブジェクトに送られる信号である。したがって、オブ
ジェクトに送られるメッセージは、必要な機能を実施す
るためにメソッドを呼び出す。

【００１９】今日、プログラミング・インターフェース
分野にＯＯＰ技法を適用することは一般的になってきて
いる。オブジェクト指向の設計において、最初のタスク
は、アプリケーション（実世界）、ユーザ・インターフ
ェース、システム・サービス、通信などの「定義域（do
main）」を識別することである。これらの境界を明確に
定めるのことは難しい。

【００２０】第２のタスクは、それぞれの定義域内で、
クラス（属性と関連サービスを有するオブジェクト）を
識別することである。結果として生じるソフトウェアの
複雑さは、この分析に極めて大きく依存する。

【００２１】オブジェクトを使って通信機能を表現する
従来のシステムは、一般に、既存のＡＰＩ（たとえば、
ＡＰＰＣ）を反映する必要に駆られて、関連のない１組
のオブジェクトで終了する。その結果として、通常は通
信定義域の境界は明確に識別できない。たとえば、典型
的なＯＯＰシステムは、その開発の対象であったアプリ
ケーション・プログラムに強く拘束された「セッション
開始」、「バッファ獲得」、「送信／受信」、「エラー
応答」、「データ除去」などの通信機能を、関連のない
オブジェクトとして実施するかもしれない。したがっ
て、それらのオブジェクトを再使用するのは難しい。

【００２２】

【発明が解決しようとする課題】クライアント／サーバ
環境において、クライアントとサーバの間のプログラミ
ング・インターフェースが、クライアント・アプリケー
ションを通信アーキテクチャまたは通信ＡＰＩに露出
（exposure）させずに、たとえば、ローカルのクライア
ント・アプリケーションが機能の呼出し、ファイルの操
作、データの転送、およびリモート・サーバ・プラット
フォームとの対話通信ができるようにする、主要なクラ
イアント／サーバ機能を提供する必要がある。

【００２３】これは、クライアントとサーバの間で、ク
ライアント／サーバに関して最適化でき、複雑で強力な
ホスト・システムを利用でき、異なるデータ表現を支援
できるような形で動作できると好都合である。

【００２４】さらに、好ましい実施例においては、イン
ターフェースを実施した通信システムは、他の様々な種
類のクライアント／サーバに再使用でき、たとえば他の
サーバ・プラットフォームに拡張可能でなければならな
い。

【００２５】

【課題を解決するための手段】したがって、本発明は、
基本的な通信アプリケーション・プログラム・インター
フェース（ＡＰＩ）を有し、クライアント／サーバ装置
において動作するようにネットワーク内で接続された、
第１のコンピュータと、第１のコンピュータとは異なる
オペレーティング・システムを使用する第２のコンピュ
ータとの間のデータの交換を容易にする通信システムを
提供する。このシステムは、第１のコンピュータ上で走
行する第１のアプリケーションからの、第２のコンピュ
ータとの接続を求める要求を処理して、複数の通信サー
ビスのうちの１つを実施するための第１の論理手段と、
第２のコンピュータ上の第２のアプリケーションに通信
サービスを実施するよう指示し、第２のアプリケーショ
ンによって提供されたデータを第１のコンピュータに戻
すための第２の論理手段と、各コンピュータ上にあって
各論理手段によってアクセス可能であり、それぞれが複
数の各通信サービスに関する定義を提供するための単一
のオブジェクト・クラスを記憶する記憶装置を有するこ
とを特徴とする。

【００２６】好ましい実施例においては、各記憶装置
は、単一のオブジェクト・クラスから派生した（導出さ
れた）オブジェクト・クラスのコヒーシブな（cohesiv
e：単一クラスから導出された密な）フレームワーク（f
ramework）を記憶する。さらに、オブジェクト・クラス
のフレームワークによって定義された通信サービスが、
機能呼出し、ファイル操作およびデータ転送を容易にす
る。すなわち引用可能な複数の通信サービスのそれぞれ
についての定義を与える単一のオブジェクト・クラスが
記憶されており、この単一のオブジェクト・クラスから
派生し強固に関連付けられたオブジェクト・クラスのフ
レームワークがこの単一のクラスをインプリメントす
る。

【００２７】この通信システムの好ましい実施例におい
ては、第１のコンピュータによって使用されるオペレー
ティング・システムは、ＩＢＭ社のＯＳ／２オペレーテ
ィング・システムである。さらに、第２のコンピュータ
によって使用されるオペレーティング・システムは、Ｉ
ＢＭ社のＭＶＳオペレーティング・システムである。そ
のような装置では、基本的通信ＡＰＩはＡＰＰＣでもよ
い。

【００２８】第２の態様について見ると、本発明は、基
本的な通信アプリケーション・プログラム・インターフ
ェース（ＡＰＩ）を有し、クライアント／サーバ装置に
おいて動作するようにネットワーク内で接続された、第
１のコンピュータと、第１のコンピュータとは異なるオ
ペレーティング・システムを使用する第２のコンピュー
タとの間のデータの交換を容易にする通信システムを操
作する方法を提供する。この方法は、第１の論理手段を
使用して、第１のコンピュータ上で実行する第１のアプ
リケーションからの、第２のコンピュータとの接続を求
める要求を処理して、複数の通信サービスのうちの１つ
を実施する段階と、第２の論理手段を使用して、第２の
コンピュータ上の第２のアプリケーションに通信サービ
スを実施するよう指示する段階と、第２のアプリケーシ
ョンによって提供されたデータを、第２の論理手段を経
由して第１のコンピュータに戻す段階と、それぞれのコ
ンピュータにおいて、各論理手段によってアクセス可能
な記憶領域に、複数の通信サービスのそれぞれに関する
定義を提供する単一のオブジェクト・クラスを記憶する
段階とを有することを特徴とする。

【００２９】本発明は、異なる通信サービスを単一の
「オブジェクト・クラス」によって表すことができると
いう認識にたっており、このアプローチは、クライアン
ト／サーバ通信において多くの著しい改良をもたらす。
「通信」（クライアント←→サーバ）を「それ自体」ク
ラスとして表すことができるので、通信定義域（そのク
ラスおよびその派生クラスのサービス）が明確に定義で
きる。

【００３０】本発明の技法は、上記の従来技術のどの技
法とも異なり、ＡＰＩ自体の内部に、明確で再使用可能
な１組のクライアント／サーバ機能を提供する。

【００３１】通常、「一般的（generic）」サービスを
提供する際の問題点は、特定の環境のために最適化し、
あるいは特定のアプリケーションの必要に合わせて機能
の容易な変更または強化を可能にすることがすぐにはで
きないことである。

【００３２】通信定義域内で動作するコードが（どのよ
うなコードも理論的にはオブジェクト指向方式で作成さ
れるので）必ずオブジェクト指向方式で作成できること
は明らかであるが、１組の基本的クライアント／サーバ
通信機能を単一のＣ＋＋オブジェクト・クラス自体とし
て表すことによって、柔軟性のある簡単なインターフェ
ースを構築できることが本発明の最も重要な点である。
言い換えると、本発明は、クライアント／サーバ・アプ
リケーション用の、極めて有用な協働的インターフェー
スを確立するための新しい技法をカプセル化するもので
ある。

【００３３】この技法は、オブジェクト指向の概念の利
用とあいまって、クライアント／サーバの協働的必要性
をクラスの属性とみなす着想から生まれた（たとえば、
クラスの導出により、基本機能の容易な変更と拡張が可
能になり、それにより、インターフェースがシステムの
特定要件に合わせて調整される）。

【００３４】ＲＰＣ、ファイル転送、データ変換、送受
信などのサービスをクラス・サービスとして表すことに
よって、通信は、通常の機能呼出しと同様に複雑でない
が、その基本的性質に影響を及ぼすことなく拡張可能か
つ最適化可能であり、いかなる既存の使用にも影響を及
ぼすことなしにクラスを拡張またはサブクラス化でき
る。さらに、新しいクライアント／サーバ・アプリケー
ション用の新しいクラスを導出できるので、再使用可能
性が極めて高い。

【００３５】

【実施例】本発明の好ましい実施例において、典型的な
クライアント／サーバ・モデルに基づく通信システムを
検討する。クライアント・コンピュータは、通常はＩＢ
ＭのＯＳ／２オペレーティング・システムなどのオペレ
ーティング・システムを使用し、サーバ・コンピュータ
は、ＩＢＭのＭＶＳオペレーティング・システムなどの
ホスト・ベースのオペレーティング・システムを使用す
る。

【００３６】通信システムを構築する際の問題点は、一
般に、いくつかの具体的分野に分けることができる。こ
れを行うためには、まず、問題の通信システムの特定の
機能要件を検討しなければならない。たとえば、通信シ
ステムに関するいくつかの特定の機能要件は、以下のよ
うなものである。

【００３７】ＲＰＣ（リモート手順呼出し）：本質的
に、クライアントの要求に応じて、通信システムがホス
ト・サーバ上の手順を呼び出す。利用可能な手順の初期
の数は比較的少ないかもしれないが、この機能は、将来
新しい手順を加えるために容易に拡張可能でなければな
らない。

【００３８】データ変換：通信システムは、混合された
データ・タイプからなり、クライアントとホスト・サー
バの間で交換される、多数の複雑な制御ブロックを有す
ることがある。これらの制御ブロックは、適切なプラッ
トフォーム・フォーマットに変換しなければならず、漢
字などのＤＢＣＳ（２バイト文字セット）データに対応
しなければならないこともある。

【００３９】バッファ管理：任意の量のデータがサーバ
から戻されるが、戻されるデータの量は前もってはわか
らない。送信バッファの限度を越える大きさのこともあ
る（送信バッファは、リンク上に送られるデータの記憶
域である）。

【００４０】ファイル管理：順次メンバおよびＰＤＳ
（区分データ・セット）メンバを含むファイルの、ダウ
ンロードとアップロードを必要とすることがある。削
除、印字、コピーなど、他の潜在的要件がある。

【００４１】透過動作：通信システムの使い易さという
目標のためには、通信の諸態様は「不可視」でなければ
ならない。ユーザが開始する起動と終了の必要をなくす
べきである。

【００４２】柔軟性：通信システムは、広範囲の異なる
システム構成上で使用可能なので、重要な性能要因がか
なり変化することがある。これに対処するために、キー
性能パラメータの修正が容易でなければならない。しか
しまた、使い易さのために、省略時構成を提供しなけれ
ばならない。

【００４３】環境：本発明の好ましい実施例において
は、通信システムは、ＡＰＰＣ通信を使用するＯＳ／２
クライアントとＭＶＳサーバとの間に上記の機能を必要
とする。

【００４４】これらの要件は、いくつかの別個の問題を
もたらす。たとえば、１つの問題は性能と資源使用にあ
り、ＯＳ／２のユーザ駆動型多重スレッド式の性質は特
に、クライアント／サーバに関して、たとえば以下のよ
うないくつかの問題をＭＶＳに提示する。

【００４５】１．並行性：応答時間が許容できるもので
ある場合、並行サーバ・アクティビティ（処理動作）
は、並行フロント・エンド・アクティビティを処理する
ことが必要とされる。これは、ＭＶＳサーバでは特に困
難である。

【００４６】２．セッション制御：予測できないユーザ
・アクティビティ・シーケンスは、通信セッションをど
れだけ長く活動状態に保つべきかを決定できない。セッ
ションの頻繁な停止と開始は、大きな性能のオーバヘッ
ドを伴う。

【００４７】３．資源使用：ＯＳ／２処理、ＭＶＳアド
レス空間、ＡＰＰＣ対話などの資源の有効使用を最大に
するための試みを行わない限り、ワークステーション上
の並行アクティビティは、様々なネットワーク資源とプ
ラットフォーム資源の激しい使用をもたらすことがあ
る。これは、コストを高め、全体的処理能力を低下させ
る。

【００４８】４．資源共用：資源の使用を管理する試み
が行われない限り、あるユーザによる著しいアクティビ
ティが、他のユーザが使用可能な資源に影響し、他のユ
ーザのアプリケーションの性能に悪影響を与えることが
ある。理想的には、あるユーザによる著しいアクティビ
ティが、そのユーザ自体の性能だけに影響を与えるべき
である。

【００４９】第２の問題は、ソフトウェア再使用および
拡張性の分野において生じる。通信システムのために開
発された機能は、使用、再使用および拡張が容易でなけ
ればならない。これは、以下のような潜在的な用途に対
応するためである。 １．追加の機能や新しいプラットフォーム（たとえば、
ＶＭ）など、通信システムの将来の拡張。 ２．他のプロダクト用の「ビルディング・ブロック」と
しての通信システムの再使用。

【００５０】これらの問題は、本発明の好ましい実施例
においては、機能性と性能に関する必要な通信要件を提
供し、かつ容易に拡張可能で調整可能である単一でコヒ
ーシブな統合された「プロダクト」によって克服され
る。このプロダクトを、今後、クライアント／サーバ・
アプリケーション・イネーブラ（ＣＳＡＥ）と呼ぶ。そ
の特性は以下の通りである。

【００５１】１．通信アーキテクチャまたは通信ＡＰＩ
にクライアント・アプリケーションを露出させずに、ク
ライアント・アプリケーションが機能を呼び出し、ファ
イルを操作し、データを転送し、リモート・プラットフ
ォームとの対話通信を実施できるようにするための、サ
ービスをクライアント・アプリケーションに提供する。

【００５２】２．特定の必要のために機能が導出できる
ように、これらのサービスを、ＡＰＩ機能ではなく、単
一のＣ＋＋クラスから導出可能なＣ＋＋クラスのコヒー
シブなフレームワークとして提示する。

【００５３】３．通信プロトコルやリモート・プラット
フォーム環境に関係なく、標準的な１組の機能と標準イ
ンターフェースを提供する。

【００５４】４．性能が最大になり、資源使用量が最小
になるように、プラットフォーム／プロトコル特有の諸
特徴を内部的に実施する。

【００５５】５．ユーザまたは使用アプリケーションに
対して自動的かつ透過に動作する。通信「セッション」
を確立し、あるいはＣＳＡＥ構成要素を活動化するため
に、ユーザはなにも動作を実行する必要がない。

【００５６】これらの特徴の主な意義は、異なる通信プ
ロトコルおよび動作環境にわたって標準のサービスとイ
ンターフェースが提供され、同時に、各環境に対して最
適化され、特定の必要のために提供されたサービスが容
易に拡張できることである。通常、「一般的」サービス
を提供する際の問題点は、特定の環境のために最適化
し、あるいは特定のアプリケーションの必要に合わせて
機能を変更／強化する能力を失うことにある。

【００５７】ＣＳＡＥの主な使用法は、その名前が示す
ように、クライアント／サーバ・アプリケーションの実
施を容易にすることである。好ましい実施例において
は、ＣＳＡＥは、ＡＰＰＣ通信を使用して、クライアン
トとしてのＯＳ／２と、サーバとしてのＭＶＳに送られ
る。これはおそらく、最適化すべき最も複雑な環境であ
る。その結果、可能な最適化および機能調整の例とし
て、以下に、いくつかの特徴を強調して示す。ＣＳＡＥ
が任意のプラットフォームで実施できることに留意され
たい。

【００５８】＜機能性＞ リモート手順呼出し（ＲＰＣ）：ＣＳＡＥは、標準のＲ
ＰＣ機構を提供する。クライアント・アプリケーション
は、ＣＳＡＥに、リモート機能の名前と、入力パラメー
タおよび出力パラメータのリストとを提供する。ＣＳＡ
Ｅは、必要な通信を確立し、リモート手順を呼び出し、
その入力パラメータを提供し出力パラメータを戻す世話
をする。リモート手順は、その環境用の標準機能を介し
て呼び出されることに留意されたい。リモート手順は、
それが「リモート」で呼び出されていることを知らな
い。これは、既存の機能が使用できることを意味し、そ
の機能をわざわざ書く必要はない。

【００５９】ＭＶＳサーバは、バッチ・ジョブとしてま
たはサーバＣＳＡＥ構成要素のサブタスクとして、リモ
ート手順を呼び出すことができる。サブ・タスクとして
は、手順は、静的連係モジュールまたは独立負荷モジュ
ールのいずれでもよい。バッチ・ジョブとして開始され
た場合でも、リモート手順はクライアントと通信できる
ことに留意されたい。

【００６０】データ変換：ＣＳＡＥは、パラメータのデ
ータ・タイプを、リモート・パラメータ・クラス（後で
詳しく説明する）として知られるＣ＋＋クラスとして提
供し、このＣ＋＋クラスは、すべてのデータ変換を処理
し、複雑なデータ構造、すなわち任意の深さにネストさ
れたアレイおよび構造体を任意に構築できるようにす
る。これらのクラスは、ＤＢＣＳ ＯＳ／２の下で動作
する場合はＤＢＣＳデータに対応し、以下の基本的なデ
ータ・タイプに対応できる（新しいデータ・タイプが容
易に追加できる）。 固定長文字列 可変長文字列（任意サイズ） 無符号の短い整数（２バイト） 無符号の長い整数（４バイト） ８ビット２進変数（ビット列、フラグなど） １６ビット２進変数

【００６１】次の複合データ・タイプが支援される。 構造体 アレイ（サイズ制限の事前設定なし）

【００６２】バッファ管理：ＣＳＡＥは、送信データと
戻りデータの両方について、データ・バッファ用のメモ
リの割振りを処理する。使用アプリケーションは、この
情報が要求されない限りバッファ・サイズの知識をもた
ない。データは、リモート・パラメータによってバッフ
ァに入れられそこから引き出される。ＣＳＡＥとアプリ
ケーションの間のインターフェースは、リモート・パラ
メータだけを処理する。リモート・パラメータ・オブジ
ェクトのサイズに対する制限はなく、伝送バッファ・サ
イズを超えた場合は、複数回の送信で伝送される。クラ
イアントがサーバから受け取るアレイのサイズは、サイ
ズ制限の事前設定がないことに留意されたい。必要に応
じて要素がアレイに加えられる。

【００６３】ファイル管理：ファイルのダウンロードと
アップロードが提供される。リモート・ファイルをロー
カル・ファイルにダウンロードでき、または走査／更新
のためにメモリ内にただ保持することもできる。リモー
ト・ファイルに書き込まれるデータは、ローカル・ファ
イルまたはメモリから取り出すことができる。ローカル
・ファイルとリモート・ファイルの両方を、作成し、拡
張し、上書きし、あるいは削除することができる。文字
と２進データの混合、反復グループ、ＤＢＣＳなどの複
雑なレコード構造のファイルが転送でき、必要に応じて
ローカル・フォーマットとリモート・フォーマットの間
で変換される。

【００６４】ＭＶＳについては、ＰＳ（物理順次）デー
タセットおよびＰＤＳメンバが送受信できる。

【００６５】透明動作：ＣＳＡＥ通信機能は、最初のア
プリケーションがサービスを要求したときに「開始」
し、最後のアプリケーションが終了したときに「停止」
するダイナミック・リンク・ライブラリ（ＤＬＬ）に含
まれる。このＤＤＬは、これらのサービスを透明な形で
提供するだけでなく、次の要求のための開始オーバヘッ
ドを繰り返さなくてもよいようにする。必要でなくなっ
たらすぐに停止することによって、資源はできるだけ速
く解放される。

【００６６】柔軟性：ＣＳＡＥは、実行時に使用アプリ
ケーションごとに、さらには１つのアプリケーション内
の異なる機能ごとに変化し得るタイミングおよび性能パ
ラメータを提供する。省略値が提供される。

【００６７】「性能と資源使用」の問題に関して（一般
にＯＳ／２からＭＶＳ）、以下の特徴が提供される。

【００６８】並行性：並行要求は、ＳＮＡセッションの
構成最大許容数まで対処できる。並行性は、複数のアプ
リケーションまたは１つのアプリケーション内の複数の
プロセスおよびスレッドに特定のＭＶＳサーバへの通信
を要求させることによって、ＰＷＳクライアント上で発
生する。これらの要求はすべて、実際の通信を管理する
単一のクライアント処理に送られる。ＭＶＳサーバ上で
は、以下の２つの技法が使用される。

【００６９】サブタスクをＭＶＳサーバのＣＳＡＥアド
レス空間に付加することにより、複数の要求を１つのＭ
ＶＳ ＡＰＰＣアドレス空間によって処理することがで
きる。

【００７０】たとえば、リモート手順がＭＶＳサーバの
ＣＳＡＥ構成要素（たとえば、ＳＴＥＰＬＩＢ、ＳＹＳ
ＵＤＵＭＰなど）の環境とは異なる「環境」を必要とす
る場合に、バッチ・ジョブを開始することによって、よ
り「高価」なＡＰＰＣ領域ではなくバッチ領域に処理が
オフロードされる。また、これは、１ユーザの影響を１
つのＡＰＰＣアドレス空間（スケジューラ）に制限する
ことに留意されたい。

【００７１】セッション制御：ＰＷＳ （プログラマブ
ル・ワークステーション・マシン）ＣＳＡＥは、いつ対
話を最良に割振りまた割振り解除するかを決定する制御
機能を含む。この機能が適用される場合、資源の共用と
再使用を可能にする。これにより、まだ必要な場合、こ
れらの資源を活動状態に保つことができ、対話、セッシ
ョンの停止と開始、およびその結果行われるパートナー
・オブジェクト（これは後で説明する）のスケジューリ
ングが削減される。

【００７２】資源使用：前述のセッションおよび対話の
管理と、サブタスクおよびバッチ領域の使用により、資
源が最大限に使用されるようになる。

【００７３】資源共用：１人のユーザしかＡＰＰＣアド
レス空間上でスケジュールをたてることができないた
め、１人のユーザが資源を独占することが妨げられる。

【００７４】「ソフトウェア再使用と拡張性」に関して
は、以下の特徴が提供される。簡単さ：ＣＳＡＥは、Ｒ
ＰＣ、送信、受信などの非常に簡単な機能を提供する。
このため、プログラミングの視点から、通信は、通常の
機能呼出しの発行と同様に複雑でないものとなる。基礎
となる通信インターフェース（すなわち、ＣＰＩ−Ｃ／
ＡＰＰＣ）は露出されない。

【００７５】機能的拡張可能性： ＣＳＡＥがクラスで
あるという事実は、その基本機能の変更および拡張が可
能になるようにそれを導出できることを意味する。通信
システム自体は、この概念を使用してクラスを導出する
ことにより、一定の強化されたファイル管理機能を提供
する。

【００７６】環境的拡張可能性：ＣＳＡＥの好ましい実
施例はＯＳ／２クライアントとＭＶＳサーバのみに対応
するが、ＰＷＳ ＣＳＡＥ内のすべてのパートナ特有の
コードは、別々のモジュールに含まれる。ＣＳＡＥは、
他のプラットフォーム特有のモジュールを提供すること
によって、他のサーバ・プラットフォームにアクセスす
るように簡単に拡張でき、一般的ＣＳＡＥコードは将来
のモジュールを受け入れることができる。

【００７７】次に、上記の好ましい実施例の通信システ
ムを、さらに図１に関連して説明する。クライアント・
コンピュータ１０には、ＩＢＭ社のＯＳ／２オペレーテ
ィング・システムが導入されており、アプリケーション
・プログラム４０がそのオペレーティング・システム上
で走行する。アプリケーション・プログラムは、通信サ
ービスをサーバ・コンピュータ２０上で実行すること、
またはアプリケーション・プログラム４０による次の使
用のためにデータをサーバ２０から戻すことを定期的に
必要とする。本発明にとっては、通信サービスをサーバ
が実行することを求める要求が、第１のアプリケーショ
ン・プログラム４０とのユーザ対話によって生成された
か、それともアプリケーション・プログラム４０がユー
ザ対話とは関係なく動作し、プログラムの実行中に自動
的に要求を行うかどうかは重要でない。

【００７８】通信サービスがサーバ・コンピュータ２０
から要求されたとき、第１のアプリケーション・プログ
ラムは、第１の論理手段５０に要求サービスを伝える。
たとえば、第１の論理手段に、入力パラメータおよび出
力パラメータのリストと一緒にリモート手順の名前を送
ることによって、これを行うことができる。次に、第１
の論理手段５０は、記憶装置６０に記憶された使用可能
な通信サービスの定義に関して、第２のコンピュータ２
０との必要な通信を確立するタスクを処理する。すべて
の可能なサービスは、オブジェクト・クラス７０のコヒ
ーシブなフレームワークとして定義され、これらのクラ
スは、単一のオブジェクト・クラスから導出される。す
でに前に詳しく説明したように、このようにサービスを
定義することで、性能と再使用可能性の点で多くの利点
が得られる。

【００７９】サーバ２０との必要な通信を確立するため
に、第１の論理手段５０は、フレームワークのうちのど
のオブジェクト・クラスを使用する必要があるかを決定
し、次にそのオブジェクトのインスタンスを作成し、そ
のオブジェクトにメッセージを送って、そのメソッドの
うちの１つを呼び出せる。これによっては、接続手段８
０を介したサーバ・コンピュータとの接続が確立され、
その後に第２の論理手段９０へ次の要求が送られる。

【００８０】次に、第２の倫理手段９０は、サーバ・コ
ンピュータ２０上で走行する第２のアプリケーション・
プログラム１００（以後、サービス・アプリケーション
と呼ぶ）に要求を渡して、サービス・アプリケーション
１００が、データ検索手順の実行など、その要求が必要
とする特定のタスクを実行できるようにする。このタス
クが完了した後、サービス・アプリケーションは、結果
を第１のコンピュータ１０に返送する必要がありうる。
サーバ・アプリケーション１００は、要求されたタスク
の実行中、および結果を第１のコンピュータ１０に返送
すべきとき、第２の論理手段９０と対話する。第２の論
理手段９０は、オブジェクトのインスタンスを確立し、
サーバ・アプリケーション１００が必要とするとき、そ
のオブジェクトの適切なメソッドを呼び出す。オブジェ
クト・インスタンスは記憶装置１１０に記憶されたオブ
ジェクト・クラスのコヒーシブなフレームワークから作
成される。オブジェクト・クラス１２０のフレームワー
クによって提供されるメソッドの例は、後で考察する。

【００８１】また、先に記載した利点を活用するため
に、使用可能な通信技法は、単一のオブジェクト・クラ
スから派生したオブジェクト・クラス１２０のコヒーシ
ブなフレームワークとして定義される。

【００８２】上記技法を使うと、クライアント・アプリ
ケーション・プログラム４０が、通信アーキテクチャま
たは通信ＡＰＩに露出されない。さらに、サービス・ア
プリケーション１００は、その環境用の標準機構を通じ
て呼び出され、リモートで呼び出されていることを知ら
ない。

【００８３】次に、オブジェクト・クラスのコヒーシブ
なフレームワークとしての通信サービスの確立について
説明する。通信サービスをこのように定義する概念が導
出され、その結果前に論じた多くの利点が実現されるこ
とが理解されれば、当業者は一般に、適切なオブジェク
ト・クラスを構成できるようになる。しかし、以下の説
明で、フレームワークを確立できる１つの方法を例示す
る。

【００８４】クライアント・アプリケーション４０が必
要とする機能を実施するために、第１の論理手段５０に
よって使用されるクラスを記憶装置６０内で定義する必
要がある。好ましい実施例においては、このクラスは、
クライアント側とより関連するものであるのでクライア
ントパイプ・クラスと呼ばれる。

【００８５】クライアントパイプ・クラスは、基礎とな
る通信機能をカプセル化し、ＯＳ／２クライアントとＭ
ＶＳサーバの間のＡＰＰＣを介してリモート手順を呼び
出すための簡単なモデルを提示する。

【００８６】クライアント・クラスは、同期ＲＰＣ環境
に呼出し機能を提供する。パイプは単一スレッド式であ
り、組込みの並行性保護を提供しない。

【００８７】クライアントパイプのオブジェクトをイン
スタンス化して、基本的な汎用ＲＰＣ機能を提供するこ
とができる。ただし、アプリケーション特有のパイプ・
クラスは、クライアントパイプ・クラスから導出して、
改善されたアプリケーション特有の機能性を提供するこ
とができる。

【００８８】クライアントパイプ・クラスは、以下のよ
うな定義されたメソッドを有する。 Ａ．クライアント・アプリケーション４０によって呼出
し可能な５つの公用のメソッド。 （１）クラス・コンストラクタ・メソッド （２）クラス・デストラクタ・メソッド （３）後で検討する「パートナ」オブジェクトにおいて
リモート手順を呼び出すためのメソッド。 （４）パラメータを、クライアントＰＷＳフォーマット
からサーバ・ホスト・フォーマットに変換するためのメ
ソッド （５）パラメータを、サーバ・ホスト・フォーマットか
らクライアントＰＷＳフォーマットに変換するためのメ
ソッド。

【００８９】Ｂ．派生パイプ・クラスによってのみ呼出
し可能な３つの保護されたメソッド。 （１）データを「パートナ」オブジェクトに送るための
メソッド。これはＲＰＣアーキテクチャの呼出し部分を
表し、データをパートナの名前付き機能に送る。 （２）データを「パートナ」オブジェクトから受け取る
ためのメソッド。これはデータ・バッファをパートナか
ら受け取り、これをパラメータとして呼出し機能に戻す
（各パラメータは、後で説明するようなリモートパラメ
ータ・オブジェクトとしてカプセル化される）。 （３）たとえば、エラーがパートナから戻されると
き、" ＣｏｎＸｎ"オブジェクトを削除するためのメソ
ッド（ＣｏｎＸｎオブジェクトは後でも説明する）。

【００９０】Ｃ．クライアントパイプ・オブジェクト内
部の４つのメソッド。 （１）データをパートナに送るときに呼び出され、パー
トナへの伝送の準備として、すべての入力パラメータを
変換し適切な制御ブロックを構築するためのメソッド。 （２）パートナから送られるトランザクション・ヘッダ
を受け取り解釈するためのメソッド。 （３）ＤＬＬにおいて実施され、ＣｏｎＸｎパートナ・
オブジェクトの作成を管理し、パイプ（図１の接続手段
８０で表される）をＣｏｎＸｎパートナ（ＣｏｎＸｎパ
ートナ・オブジェクトは後で説明する）に「登録」する
ための”Ｃ”メソッド。 （４）ＤＬＬにおいて実施され、ＣｏｎＸｎパートナに
おけるパイプを「登録解除」し、必要ならばＣｏｎＸｎ
パートナを削除するための”Ｃ”メソッド。

【００９１】また、サーバ・アプリケーション１００が
必要とする機能を実施するため、第２の論理手段９０に
よって使用される対応するクラスを記憶装置１１０内で
定義する必要がある。好ましい実施例においては、これ
はサーバ側とより関連するものであるので、サーバパイ
プ・クラスと呼ばれる。

【００９２】サーバパイプ・クラスは、以下のような定
義されたメソッドを有する。 Ａ．サーバ・アプリケーションによって呼出し可能な６
つの公用メソッド。 （１）制御対話を処理するためのメソッド。これは制御
対話割振りの結果としてサーバ・アプリケーションがス
ケジューリングされるときに必ず呼び出される。 （２）データをクライアント・コンピュータ１０に送っ
て、標準サブルーチン機構を提供するためのメソッド。
これはクライアントパイプ・クラスにおける等価な機能
と同じように機能し、この方法によって送られるデータ
は、クライアントパイプ・クラスの受信メソッドを使用
して、クライアントによって受け取られる。 （３）動的データセット割振りサービスを提供するため
のメソッド。 （４）外部ロード・モジュールの動的ロードおよび呼出
しを実施するためのメソッド。 （５）現在実行中の機能用のプログラム変数を保持する
ために使用される記憶域を割り振りまたは増加させるた
めのメソッド。 （６）前記記憶域を解放または減少させるためのメソッ
ド。

【００９３】Ｂ．サーバパイプ・クラス内部の３つの私
用メソッド。 （１）非同期のサブタスクとして動作し、クライアント
ＣｏｎＸｎパートナとのデータ対話を割り振るためのメ
ソッド。これはクライアント・コンピュータによって送
られたデータを受け取り、該当する場合には、これをサ
ーバ・アプリケーション１００に渡す。 （２）送られたデータのための記憶域をクライアント・
コンピュータから供給された情報に従って割り振り、ク
ライアントから送られたデータを呼び出し受け取るため
のメソッド。 （３）クライアント・コンピュータ１０に代わって、サ
ーバのデータセットを配置するためのメソッド。

【００９４】Ｃ．サービス・アプリケーション１００の
機能性を完全なものとするために、ユーザによって供給
されることが必要ないくつかのユーザ作成メソッド。 （１）ユーザ作成のディスパッチャ機能であり、クライ
アント・アプリケーション４０によって要求される適切
なユーザ機能を呼び出すメソッド。このメソッドは、サ
ーバパイプ・クラスからアプリケーション機能への標準
インターフェースを提供するために使用され、リンク時
に決定される外部参照である。 （２）呼び出す必要があるかもしれない１つまたは複数
のユーザ機能を表すメソッド。

【００９５】次に、前に参照したＣｏｎＸｎおよびＣｏ
ｎＸｎパートナ・クラスについて説明する。ＣｏｎＸｎ
クラスは、パートナへの基本的通信をカプセル化する。
好ましい実施例では、これはすべての通信アクティビテ
ィに対するインターフェースを提供する。ＣｏｎＸｎク
ラスは、ＭＶＳサーバ・コンピュータ２０に対するＡＰ
ＰＣ通信を提供するが、異なる通信プロトコル（たとえ
ば、ＴＣＰ／ＩＰ）を使用し、あるいは他のプラットフ
ォームと通信するために、導出することができる。

【００９６】ＣｏｎＸｎクラスは、クライアント・アプ
リケーション・プログラム４０によって呼出し可能な以
下のメソッドを有する。 （１）ＣｏｎＸｎパートナに「登録」して、パートナと
のデータ対話を得るメソッド。 （２）ＣｏｎＸｎパートナに「登録解除」して、パート
ナとのデータ対話を解除するメソッド。 （３）データのバッファをパートナに送るためのメソッ
ド。 （４）データのバッファをパートナから受け取るための
メソッド。 （５）データが首尾よく受け取られたことをパートナに
確認するメソッド。これは、パートナからの確認要求に
応じてのみ行われる。 （６）パートナにエラーを通知するメソッド。これは非
同期にまたは確認要求に応じて行える。

【００９７】ＣｏｎＸｎパートナ・クラスは、パートナ
従属情報および機能をカプセル化する。これは１つの制
御対話および複数のデータ対話の通信アーキテクチャを
実施し制御する。ＣｏｎＸｎパートナ・クラスは、特定
ユーザＩＤに関して特定のクライアント・アプリケーシ
ョンにアクセスしているすべてのＣｏｎＸｎを一緒に結
合する。ＣｏｎＸｎパートナ・クラスは、ＤＬＬ内で実
行時ダイナミック・リンキングを使って実施され、以下
のメソッドを有する。 Ａ．クライアント・アプリケーション４０によって呼出
し可能な５つの公用メソッド。 （１）ＣｏｎＸｎパートナ・オブジェクトが作成される
ときに呼び出されるメソッド。これはデータ項目を初期
設定し、開始アプリケーション呼出しを発行する。 （２）ＣｏｎＸｎパートナ・オブジェクトが作成される
ときに呼び出されるメソッド。これは制御対話がＡＰＰ
Ｃアプリケーションを終了するために、終了アプリケー
ション呼出しを発行する。 （３）ＣｏｎＸｎオブジェクトが作成されるたびに呼び
出されるメソッド。これはＣｏｎＸｎのためのデータ対
話を適切に割り振りまたは再使用し、必要ならば制御対
話を割り振る。 （４）ＣｏｎＸｎオブジェクトが破壊されるたびに呼び
出されるメソッド。これはデータ対話を割振り解除しま
たは使用可能なものとフラグを立て、必要ならば制御対
話を割振り解除する。 （５）パートナにコード・ページを戻すためのメソッ
ド。

【００９８】Ｂ．パートナとの制御対話を割り振るＣｏ
ｎＸｎパートナ・クラス内部の私用メソッド。安全保護
検査は、割振り処理の一部として実行できる。

【００９９】前に述べたリモートパラメータは、リモー
ト機能との間で伝送するためにクライアントパイプ・オ
ブジェクトに渡されるすべてのパラメータに関する抽象
的基本クラスを構成するクラスとして定義される。これ
は、複雑な任意のデータ構造を渡す手段を提供する。派
生リモートパラメータ・クラスは、特定のデータ・タイ
プごとに作成され、データ構造をカプセル化し、したが
ってそのデータをクライアントＰＷＳフォーマットから
リモート（パートナ）フォーマットにどのように変換す
るかを知っている。

【０１００】リモートパラメータ・オブジェクトは、ロ
ーカル・フォーマットおよびリモート・フォーマットの
両方のデータを含む。ローカル・データは、たとえば不
連続なデータ項目として保持されるアプリケーション・
データである。これはアプリケーションにとって意味の
ある整数、文字列、抽象データ・タイプなどのデータ・
タイプである。これらのデータ項目を「獲得」し「配
置」するために、メンバ機能が提供される。リモート・
データは、連続するバッファに保持され、変換済みのロ
ーカル・データと、リモート機能によって伝送し使用す
るために必要な「足場（scaffolding）」情報とからな
る。これには、目印（eyecatcher:識別子）や様々な長
さフィールドなどのデータが含まれる。

【０１０１】リモート・データ・バッファおよびそれを
操作する機能は、汎用性があるので、基本リモートパラ
メータ・クラス内で実施される。ローカル・データ項目
とその機能は、派生リモートパラメータ・クラス内で実
施される。

【０１０２】ローカル・データ項目は、オリジナル・デ
ータのコピーとして保持される。ローカル・データが派
生リモートパラメータ・オブジェクトに渡されるたび
に、メモリが割り振られデータがコピーされる。これ
は、ローカル・データ項目がアプリケーションに「属す
る」からである。データを削除するかまたはデータを含
むメモリを再使用するためのアプリケーションとリモー
トパラメータ・オブジェクトとの間に相互依存性があっ
てはならない。リモート・データ・バッファは、リモー
トパラメータ・オブジェクトに属する。これは公用メン
バ機能によって割り振られ削除される。

【０１０３】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０１０４】（１）通信アプリケーション・プログラム
・インターフェース（ＡＰＩ）を有し、ネットワークで
接続された第１のコンピュータ（１０）及び該第１のコ
ンピュータ（１０）とは異なるオペレーティング・シス
テムを使用する第２のコンピュータ（２０）の間でのデ
ータの交換を行うための通信システムであって、第１の
コンピュータ（１０）上で走行する第１のアプリケーシ
ョン（４０）からの、第２のコンピュータ（２０）との
接続を求める要求を処理して、複数の通信サービスのう
ちの１つを実施するための第１の論理手段（５０）と、
第２のコンピュータ（２０）上の第２のアプリケーショ
ン（１００）に通信サービスを実施するよう指示し、第
２のアプリケーション（１００）によって提供されたデ
ータを第１のコンピュータ（１０）に戻すための第２の
論理手段（９０）と、各コンピュータ上にあって各論理
手段（５０、９０）によってアクセス可能であり、複数
の通信サービスそれぞれに関する定義を提供するための
単一のオブジェクト・クラスをそれぞれ記憶する記憶装
置（６０、１１０）とを含む通信システム。 （２）各記憶装置（６０、１１０）が、単一のオブジェ
クト・クラスから派生したオブジェクト・クラス（７
０、１２０）のコヒーシブなフレームワークを記憶す
る、上記（１）に記載の通信システム。 （３）オブジェクト・クラスのフレームワークによって
定義された通信サービスが、機能呼出し、ファイル操
作、およびデータ転送を行う、上記（２）に記載の通信
システム。 （４）通信アプリケーション・プログラム・インターフ
ェース（ＡＰＩ）を有し、クライアント／サーバ装置に
おいて動作するようにネットワーク内で接続された、第
１のコンピュータ（１０）と第１のコンピュータ（１
０）とは異なるオペレーティング・システムを使用する
第２のコンピュータ（２０）との間のデータの交換を容
易にする通信システムを操作する方法であって、第１の
論理手段（５０）を使用して、第１のコンピュータ（１
０）上で走行する第１のアプリケーション（４０）から
の、第２のコンピュータ（２０）との接続を求める要求
を処理して、複数の通信サービスのうちの１つを実施す
る段階と、第２の論理手段（９０）を使用して、第２の
コンピュータ（２０）上の第２のアプリケーション（１
００）に通信サービスを実施するよう指示する段階と、
第２のアプリケーション（１００）によって提供された
データを、第２の論理手段（９０）経由で第１のコンピ
ュータに戻す段階と、それぞれのコンピュータにおい
て、各論理手段（５０、９０）によってアクセス可能な
記憶領域（６０、１１０）に、複数の通信サービスのそ
れぞれに関する定義を提供する単一のオブジェクト・ク
ラスを記憶する段階とを含むことを特徴とする方法。 （５）単一のオブジェクト・クラスから派生するオブジ
ェクト・クラス（７０、１２０）のコヒーシブな枠組
が、各記憶領域（６０、１１０）に記憶されることを特
徴とする、上記（４）に記載の方法。 （６）オブジェクト・クラスの枠組によって定義される
通信サービスが、機能呼出し、ファイル操作およびデー
タ転送を容易にすることを特徴とする、上記（５）に記
載の方法。

【０１０５】

【発明の効果】本発明の上記の好ましい実施例は、以下
の理由で既知の従来の通信システムよりも改善されてい
る。 １．リモート・ファイル操作や対話能力など、ＲＰＣを
越える追加のサービスを提供する。 ２．Ｃ＋＋オブジェクト・クラスのコヒーシブな（単一
のクラスから導出可能な）フレームワークとして実施さ
れ、提供されたＡＰＩに制限されるのではなく、ＣＳＡ
Ｅの機能性を高めることが容易である。 ３．ＣＳＡＥは、それぞれの動作環境に最適化される。 ４．ＣＳＡＥはパラメータを受け入れて戻し、戻される
データのためにバッファを動的に割り振る。 ５．ＣＳＡＥは、２つのフォーマット間でのすべてのデ
ータ変換を処理する。

【０１０６】通信システム用のプログラミング・インタ
ーフェースを構築する際に上記の手法を使用することに
より、クライアント・アプリケーションのプログラマ
は、この手法から得られる上記の利点を容易に活用する
ことができる。

【０１０７】さらに、通信オブジェクト・クラスは、Ｒ
ＰＣ、ファイル転送、送信／受信、データ変換、または
通信オブジェクト・クラスによって表される他の通信サ
ービスなど、通信システムの異なる部分から見ることが
できるという点で、「多形」である。

【０１０８】これらの通信サービスをＡＰＩ機能ではな
くオブジェクト・クラスとして提供することにより、特
定の必要性のための機能性の派生（導出）が可能であ
る。

【図面の簡単な説明】

【図１】本発明の好ましい実施例の通信システムを示す
ブロック図である。

【符号の説明】

１０ クライアント・コンピュータ ２０ サーバ・コンピュータ ３０ インターフェース ４０ クライアント・アプリケーション・プログラム ５０ 第１の論理手段 ６０ 記憶装置 ７０ オブジェクト・クラスのコヒーシブな枠組 ８０ 接続手段 ９０ 第２の論理手段 １００ サーバ・アプリケーション・プログラム １１０ 記憶装置 １２０ オブジェクト・クラスのコヒーシブな枠組

───────────────────────────────────────────────────── フロントページの続き (72)発明者 フィリップ・ヒューウィット イギリス シー・ダブリュー８ ４アー ル・イー チェシャー ノースウィッチ リトル・リー ウィロウ・グリーン・レー ン ウィロウ・グリーン・コッテージ (72)発明者 ジョナサン・オコナー アイルランド カウンティー・ダブリン ルカン ウィルスブルック・グリーン 13 (72)発明者 リチャード・トムソン アイルランド ダブリン２ アッパー・ラ ッド・レーン 21

Claims (6)

【特許請求の範囲】
1. 【請求項１】通信アプリケーション・プログラム・イン
   ターフェース（ＡＰＩ）を有し、ネットワークで接続さ
   れた第１のコンピュータ（１０）及び該第１のコンピュ
   ータ（１０）とは異なるオペレーティング・システムを
   使用する第２のコンピュータ（２０）の間でのデータ交
   換を行うための通信システムであって、 第１のコンピュータ（１０）上で走行する第１のアプリ
   ケーション（４０）からの、第２のコンピュータ（２
   ０）との接続を求める要求を処理して、複数の通信サー
   ビスのうちの１つを実施するための第１の論理手段（５
   ０）と、 第２のコンピュータ（２０）上の第２のアプリケーショ
   ン（１００）に通信サービスを実施するよう指示し、第
   ２のアプリケーション（１００）によって提供されたデ
   ータを第１のコンピュータ（１０）に戻すための第２の
   論理手段（９０）と、 各コンピュータ上にあって各論理手段（５０、９０）に
   よってアクセス可能であり、複数の通信サービスそれぞ
   れに関する定義を提供するための単一のオブジェクト・
   クラスをそれぞれ記憶する記憶装置（６０、１１０）と
   を含む通信システム。
2. 【請求項２】各記憶装置（６０、１１０）が、単一のオ
   ブジェクト・クラスから派生したオブジェクト・クラス
   （７０、１２０）のコヒーシブなフレームワークを記憶
   する、請求項１に記載の通信システム。
3. 【請求項３】オブジェクト・クラスのフレームワークに
   よって定義された通信サービスが、機能呼出し、ファイ
   ル操作、およびデータ転送を行う、請求項２に記載の通
   信システム。
4. 【請求項４】通信アプリケーション・プログラム・イン
   ターフェース（ＡＰＩ）を有し、ネットワークで接続さ
   れた、第１のコンピュータ（１０）及び該第１のコンピ
   ュータ（１０）とは異なるオペレーティング・システム
   を使用する第２のコンピュータ（２０）の間でのデータ
   交換を行うための通信システムを操作する方法であっ
   て、 第１の論理手段（５０）を使用して、第１のコンピュー
   タ（１０）上で走行する第１のアプリケーション（４
   ０）からの、第２のコンピュータ（２０）との接続を求
   める要求を処理して、複数の通信サービスのうちの１つ
   を実施する段階と、 第２の論理手段（９０）を使用して、第２のコンピュー
   タ（２０）上の第２のアプリケーション（１００）に通
   信サービスを実施するよう指示する段階と、 第２のアプリケーション（１００）によって提供された
   データを、第２の論理手段（９０）経由で第１のコンピ
   ュータに戻す段階と、 それぞれのコンピュータにおいて、各論理手段（５０、
   ９０）によってアクセス可能な記憶領域（６０、１１
   ０）に、複数の通信サービスのそれぞれに関する定義を
   提供する単一のオブジェクト・クラスを記憶する段階と
   を含む通信方法。
5. 【請求項５】単一のオブジェクト・クラスから派生する
   オブジェクト・クラス（７０、１２０）のコヒーシブな
   フレームワークが、各記憶領域（６０、１１０）に記憶
   される、請求項４に記載の方法。
6. 【請求項６】オブジェクト・クラスのフレームワークに
   よって定義される通信サービスが、機能呼出し、ファイ
   ル操作およびデータ転送を行う、請求項５に記載の方
   法。