JPH05158850A

JPH05158850A - アプリケーション・プログラム間における情報交換システム及び方法

Info

Publication number: JPH05158850A
Application number: JP4143697A
Authority: JP
Inventors: Albert J Martinsky; アルバート・ジェイ・マーチンスキィ
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1991-06-12
Filing date: 1992-05-11
Publication date: 1993-06-25
Anticipated expiration: 2010-08-23
Also published as: EP0518195A3; EP0518195A2; JPH0778775B2

Abstract

(57)【要約】【目的】コンピュータの型及びモデルに関係なく、異
なるコンピュータ設備間でコンピュータ・プログラムを
作動させることができ、異なるコンピュータ設備を介し
て容易に情報交換しうるようにすること。【構成】要求端末アプリケーション２０はシステムの
インターフェース・スタブ２２，２５、及びネットワー
ク機能２４を通して指令動詞を送信することによってサ
ーバ・アプリケーション２６と通信し、要求端末アプリ
ケーション２０はこれら動詞によりトランザクションを
開き、及び閉じ、メッセージを取得し、要求及び応答を
送受信するほか、各アプリケーション２０，２６は共通
セットの動詞を使用して他の如何なるアプリケーション
とも通信するようにしたことを特徴とする。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は異なるコンピュータ設備
において作動する２又は２以上のコンピュータ・アプリ
ケーション・プログラム間で情報を交換する方法及びシ
ステムに関し、特に異なる処理環境において走行するア
プリケーション間で情報を交換するインターフェースを
開示する。

【０００２】

【従来の技術】金融産業においては、他の産業同様、規
則、大域経済、及び情報上の要求等の変化のため、継続
的な情報の変更が必要である。このような環境下におい
て、データは屡々世界中の多様なコンピュータ設備を介
して分配されてくるかもしれない。明らかに、すべての
コンピュータに同一のデータ及びアプリケーションを記
憶させることは最適な解決とはならない。しかし、典型
的に、このような解決方法は多様なコンピュータ環境を
介して特定のタスクを実行するアプリケーション・プロ
グラム及びデータの分配によって満足していた。

【０００３】

【発明が解決しようとする課題】しかしながら、不幸に
も、これらアプリケーション・プログラムは常に相互に
連絡するとは限らないので、情報を交換しなければなら
ない場合、相互に通信又は連絡するための注文によるイ
ンターフェースを開発する必要性が屡々発生していた。
しかし、このような解決方法は特別な環境の限定された
状況の下では働くが、多くの異なるコンピュータ及び処
理環境を含むシステムのアプリケーション間においては
適切な連絡方法を提供するものではない。従って、多様
な異なるコンピュータ設備を介して分配される異なるア
プリケーション・プログラム間でデータ交換する汎用イ
ンターフェースの実現が望まれていた。

【０００４】従って、本発明の目的は異なるコンピュー
タ・オペレーティング設備を介して情報を交換するシス
テムを提供することである。本発明の目的は、又異なる
支援コンピュータ設備を介してそこに滞在するアプリケ
ーション・プログラミング・インターフェースを提供す
ることである。更に、本発明の目的は異なるコンピュー
タ設備を介して情報を交換する方法を提供することであ
る。更に、本発明の他の目的はアプリケーション・プロ
グラム間で好適な情報の交換を促進するため、異なるコ
ンピュータ設備を介して作動するコンピュータ・プログ
ラムを提供することである。

【０００５】

【課題を解決するための手段】上記の課題を解決するた
め、本発明はアプリケーション・プログラムと連係した
ライブラリ・プログラム・ルーチンを通して、各コンピ
ュータ設備から独立のアプリケーション・プログラム・
インターフェース（API ）を使用する方法及びシステム
を提供する。本API は通信プロトコル及びプロトコル境
界から独立であり、通信の支援、データの交換のため、
及び効率のよい統合システムの達成のために使用するこ
とができる。

【０００６】要求端末のアプリケーションはシステムに
対し指令動詞を送信することによってサーバ・アプリケ
ーションと通信する。要求端末アプリケーションは、こ
れらの動詞により、トランザクションを開き、及び閉
じ、メッセージを取得し、要求を送受信し、応答を送受
信することができる。すべてのアプリケーションはこの
共通セットの動詞を使用して他のすべてのアプリケーシ
ョンと情報を交換することができる。

【０００７】

【実施例】以下、添付図面を参照して本発明の実施例を
詳細に説明する。図１は要求端末アプリケーションとサ
ーバ・アプリケーションとの間のデータ交換の例を示す
図、図２はインターフェース・スタブと、要求端末、サ
ーバ及びネットワーク機構との間の関係を示すブロック
図、図３は本発明方法の流れ図である。

【０００８】金融サービス産業においては、他の産業同
様、多様な異なるコンピュータ設備を介してアプリケー
ション・プログラムを分配する必要がある。図１におい
て、例えば、コンピュータ・ワークステーション１２の
前に着席している個人又は使用者１０は１又はそれ以上
の共通な販売在庫についての情報の入手を必要とするか
もしれない。しかし、この情報は要求端末場所では入手
できないが、遠隔に、又は要求端末のコンピュータ・ワ
ークステーション１２に隣接配置されているかもしれな
い他のコンピュータ・システム１４においては使用可能
であるかもしれない。従って、問題はサーバと称するコ
ンピュータ・システム１４に対して情報要求を送信し、
要求端末コンピュータ・ワークステーション１２におい
てデータを受信することである。

【０００９】コンピュータ１２とコンピュータ１４とは
類似するコンピュータ設備が、総体的に異なり、互換性
がないシステムかもしれない。本発明の利点の１つはコ
ンピュータ・プラットホーム又はコンピュータ設備の型
とは関係なく情報を交換することができることである。
この例におけるコンピュータ１２はOS／２オペレーティ
ング・システムを走行するIBM パーソナル・システム／
２ワークステーションであり、コンピュータ１４はAIX
オペレーティング・システムを走行するRISCシステム／
６０００コンピュータである（IBM 、AIX 、RISCシステ
ム／６０００、OS／２、及びパーソナル・システム／２
はIBM 社の商標である）。しかし、コンピュータ１２及
び１４はいかなるメーカーのものでも、いかなる型のも
のでもよく、本発明の背景にある主な動機付けはコンピ
ュータの型及びモデルに関係なく、コンピュータ・アプ
リケーション間において通信可能にすることである。

【００１０】図２は要求端末コンピュータ・システム１
２とサーバ・コンピュータ・システム１４との間の関係
を示すブロック図である。コンピュータ１２には、この
例では、同一型式の情報要求を発行する金融アプリケー
ション・プログラムである要求端末アプリケーション２
０が存在する。要求端末アプリケーション２０は後に十
分記述するインターフェース・スタブ２２と共同する。
インターフェース・スタブ２２はコンピュータ１２，１
４間の通信のすべてを処理するネットワーク機能構成要
素（以下、単にネットワーク機能と呼ぶ）２４と通信す
る。ネットワーク機能２４は公知の如何なる型式の通信
機能でもよい。例としては、構内通信網、広域通信網、
APP 通信網、 LU 6.2 通信網等を含む。しかし、これら
通信網の機能は当該技術分野の人々にとっては知られた
ものであり、この発明の範囲外であるからこれ以上の詳
細な説明は行わない。

【００１１】サーバ・コンピュータ・システム１４内に
は、ネットワーク機能２４とも通信する他のインターフ
ェース・スタブ２５を有する。この第２のインターフェ
ース・スタブ２５は要求端末アプリケーション２０が要
求した情報を提供するアプリケーション・プログラムで
あるサーバ・アプリケーション２６と通信する。図から
容易に判断することができるように、要求端末アプリケ
ーション２０とサーバ・アプリケーション２６との間の
すべてのアプリケーションはネットワーク機能２４を使
用して、スタブ２２，２５により処理される。

【００１２】アプリケーション・プログラム・インター
フェース（API ）はそれぞれインターフェース・スタブ
２２，２５と通信する要求端末アプリケーション及びサ
ーバ・アプリケーションが使用する要求プロトコル及び
応答プロトコルを定義する。要求端末及びサーバ両アプ
リケーションはスタブ２２，２５との通信にAPI 動詞を
使用する。API 処理を実行するソフトウェアはアプリケ
ーション・プログラムと連係するインターフェース・ス
タブ２２，２５内に含まれ、機能を要求するための“呼
出し”（CALL）インターフェースを提供する。

【００１３】API オペレーションは概念的に下記３種類
の１つに入る。・制御フローこれらのオペレーションは、インターフェース・スタブ
とアプリケーション・プログラムとの間の制御パラメー
タ及びプロトコルを取扱う。・データ・フローこれらのオペレーションは、要求端末及びサーバ両アプ
リケーションに対し、インターフェース・スタブから及
びインターフェース・スタブへ如何にアプリケーション
に特定のデータ・エンティティを送信するかを取扱う。
データ・フローはAPI 動詞引数を通して特定される。

【００１４】・サービス・フローこれらのオペレーションは、インターフェース・スタブ
が要求端末及びサーバ両オペレーションに提供するサー
ビスを取扱う。以下に示す７個のAPI 動詞がある。・OPEN−この動詞はスタブに対するアプリケーションの
識別に使用される。スタブはスタブに対するその後の全
呼出しに使用されるトークンに戻る。要求端末及びサー
バ両アプリケーションは複数のOPEN動詞を発行すること
ができる。アプリケーションによってOPENが発行される
まで、スタブはアプリケーションが存在しないものとみ
なす。

【００１５】・SEND＿REQUEST −この動詞は要求端末の
サーバに対する要求の発送に使用される。SEND＿REQUES
T の開始により作業の単位（Unit of Work）を設定す
る。スタブは作業の単位を個有的に識別するためそれら
作業の単位に対する識別（ID）を発生する。SEND＿REQU
EST の結果であるその後の通信のすべてはUNIT＿OF＿WO
RK＿IDによって識別される。

【００１６】・GET ＿REQUEST −この動詞はサーバ・ア
プリケーションにより要求される受信に使用される。GE
T ＿REQUEST 動詞を使用して、サーバ・アプリケーショ
ンはそれが提供する機能の１つと共動する要求のための
単一ブロックを検索する。アプリケーションは要求を待
つか、又は要求を受信したか否かの制御を受信するかの
いずれかを選択することができる。要求と共同するUNIT
＿OF＿WORK＿IDはサーバに送られ、その後の全通信にお
いて、この要求に対して使用される。・SEND＿RESPONSE−この動詞は要求端末及びサーバ・ア
プリケーションにより応答の送信に使用される。

【００１７】・GET ＿RESPONSE−この動詞は両アプリケ
ーションによりSEND＿RESPONSE動詞と共に送信されたデ
ータの検索に使用される。以下の２つのオプションが与
えられる：（１）応答を受信したときに戻す，（２）応答か、又は応答が使用不能の表示かのどちらか
を直ちに戻す。この動詞の総称的形式は特定の要求に対し応答を戻すこ
とである。しかし、数個の作業の単位からの応答を戻す
ため、及び数個の特定の要求に対する応答を戻すため
に、GET ＿RESPONSE動詞を編成するパラメータが使用可
能である。これらパラメータを使用する場合、規準に合
致する数個の応答が使用可能であったとしても、１個の
動詞当り１個の応答のみが戻される。

【００１８】・MESSAGE −この動詞は非零の（０でな
い）REASON＿CODES を説明するスタブからのメッセージ
を検索するため、要求端末及びサーバ・アプリケーショ
ンを使用することができる。この動詞はメッセージの定
義が要求されたときはいつでもアプリケーション・プロ
グラムにより発行することができるよう、すべて他のも
のから独立である。それはTOKEN 又はUNIT＿OF＿WORK＿
IDの設定を要求しない。・CLOSE −この動詞はスタブに対するアプリケーション
の接続の終了に使用される。アプリケーションは単一TO
KEN か、又は開放している全トークン（TOKEN)を閉止す
ることができる。CLOSE 動詞の後はトークン（TOKEN ）
に対し、それ以上の動詞は許容されない。

【００１９】要求端末及びサーバ両アプリケーション・
プログラムとも、特定の要求／応答のため複数のデータ
・ビットを送信する必要があるかもしれない。これらの
ブロックがすべて同一の要求／応答と共同することを保
証するため、アプリケーション・プログラムはLAST BL
OCK 標識を利用しなければならない。複数ブロックの要
求／応答を送信する場合、アプリケーション・プログラ
ムは、このブロックはLAST BLOCK フィールドを一群の
最後ではないということを表示する“ノー”（Ｎ）に設
定する。最後のブロックを除き、全ブロックは“ノー”
に設定されたLAST BLOCK フィールドと共にスタブへ送
信される。アプリケーション・プログラムは、その群の
最後のブロックにおいて、LAST BLOCK フィールドをこ
の動詞と共同する最後のデータ・ブロックであることを
表示する“イエス”（Ｙ）に設定する。アプリケーショ
ンが要求／応答に対する単一ブロックを送信する場合、
LAST BLOCK フィールドはこの動詞と共同するブロック
がもはやないということを表示する“イエス”に設定さ
れなければならない。

【００２０】要求端末アプリケーションがSEND＿REQUES
T 動詞を発行する場合、BEGIN ＿UNIT＿WORKを作業の単
位の開始であることを表示する“イエス”に設定する。
スタブは、要求端末に戻され又サーバに送信される固有
のUNIT＿OF＿WORK＿IDを発生する。UNIT＿OF＿WORK＿ID
は要求を識別し、要求に対するすべての追加通信に使用
される。作業の単位の終了はEND ＿UNIT＿WORKフィール
ドによって制御される。それが“イエス”に設定された
場合、スタブは現作業の単位を終了させる。

【００２１】作業の単位はサーバ・アプリケーションに
対して送信される単一データ項目同様に小さくすること
ができる。この場合、要求端末アプリケーションは“イ
エス”に設定されたBEGIN ＿UNIT＿WORKと、作業の開始
及び終了であることを表示する“イエス”に設定された
END ＿UNIT＿WORKと共に、SEND＿REQUEST 動詞を発行す
るであろう。サーバ・アプリケーションはデータ検索の
ためGET＿REQUEST 動詞を発行することができるが、作
業の単位は完了しているため、SEND＿RESPONSEを発行す
ることはできない。作業の単位の更に複雑な例として
は、要求端末が要求を複数ブロックで送信するため複数
のSEND＿REQUEST 動詞を発行する場合である。ブロック
のすべては単一のUNIT＿OF＿WORK＿IDに結合される。

【００２２】サーバはデータを検索し、処理し、そして
複数のSEND＿RESPONSE動詞を発行するため、複数のGET
＿REQUEST 動詞を発行する。要求端末は、応答を正しく
受信したことをサーバに通知するため、SEND＿RESPONSE
動詞を発行する。BEGIN＿UNIT＿WORKは、先行する段階
において、最初のSEND＿REQUEST で“イエス”に設定さ
れ、機能要求に対するその後のすべてのSEND＿REQUEST
動詞で“ノー”に設定される。END ＿UNIT＿WORKは最後
の要求端末のSEND＿RESPONSEを除き、すべての動詞に対
して“ノー”に設定される。END ＿UNIT＿WORKが“イエ
ス”に設定されたとき、スタブは、これはこの作業の単
位の終端であることを確認する。スタブはこの作業の単
位と共同する情報を削除し、作業の単位に対するその後
のデータは送信されないかもしれない。

【００２３】アプリケーションは複雑な数個の異なるレ
ベルにおいて作業することができる。最も簡単なものは
特定の機能を要求するアプリケーションであり、その機
能を供給するものである。この場合、下記の筋書が適用
される。スタブ間のすべての通信はネットワーク機能２
４を介して行われる。下記の例は要求端末及びサーバ両
アプリケーションがそれぞれのスタブに対してそれらを
一致させるため予めOPEN呼出しを発行したものと仮定す
る。

【００２４】図３において、要求端末アプリケーション
は、機能の実行を要求するためSEND＿REQUEST 動詞を発
行するであろう（ブロック３００）。SEND＿REQUEST 動
詞の結果、スタブは戻される個有のUNIT＿OF＿WORK＿ID
を発生する（ブロック３０２）。このIDはこの要求と共
同するすべてのデータを識別するために使用される。要
求端末のスタブはサーバのスタブに対し機能要求を送信
する（ブロック３０４）。

【００２５】サーバ・アプリケーションは要求を受信す
るため、GET ＿REQUEST 動詞を発行する。スタブはサー
バに対し、要求データを供給し、この要求に対応するUN
IT＿OF＿WORK＿IDを供給する（ブロック３０８）。サー
バは要求を処理し（ブロック３１０）、要求端末に対し
て応答データを返送するため、そのスタブに対しSEND＿
RESPONSE呼出しを発行する（ブロック３１２）。サーバ
・アプリケーションは共同するUNIT＿OF＿WORK＿IDが特
定されることを保証しなければならない。サーバはSEND
＿RESPONSEが続くGET ＿REQUEST を発行する場合、サー
バ・アプリケーションはUNIT＿OF＿WORK＿IDフィールド
を変更する必要がなく、まだそれはGET＿REQUEST 動詞
で受信したIDに設定されるであろう。

【００２６】要求端末アプリケーションは共同するUNIT
＿OF＿WORK＿IDと共にGET ＿RESPONSE動詞を発行する
（ブロック３１４）。スタブは応答データを要求端末に
戻す。再び、アプリケーションがGET ＿RESPONSEが後続
するSEND＿REQUEST 動詞を発行する場合、要求端末アプ
リケーションはSEND＿REQUEST 動詞を更新する必要はな
い。この処理シーケンスは全データが処理されるまで継
続される。アプリケーションが完了したとき、両アプリ
ケーションともCLOSE 動詞を発行して、もはや要求／支
援機能がないことをスタブに通知する（ブロック３１
６）。

【００２７】要求端末及びサーバ両アプリケーション・
プログラムによりOPEN動詞が発行される。OPEN動詞の目
的はスタブに対するアプリケーション・プログラムを識
別することである。サーバ・アプリケーションは１又は
１以上の機能をサービスすることができる。アプリケー
ションはすべてを、又はそれが供給する機能の部分集合
を開放することができる。各機能は独立して開放し、閉
止することができる。

【００２８】アプリケーション・プログラムは下記動詞
を発行する。 AIM ＿PARMはスタブに使用されるべきパラメータを含む
データ構造である。

【００２９】NUM ＿FUNCTION＿NAMES パラメータはFUNC
TION＿NAMES ＿ARRAY で指定された機能名の数を含むア
プリケーションが定義するフィールドである。その数は
零（０）又はそれ以上である。零（０）は、そのアプリ
ケーションは要求端末のみ、又は、サービスする機能は
開放されるべきでない、ということを表示する。FUNCTI
ON＿NAMES ＿ARRAY はこのサーバ・アプリケーションの
ために開放されるべき機能の完全修飾名を含むユーザ定
義のアレイである。

【００３０】要求端末アプリケーションはSEND＿REQUES
T 動詞を発行して、特定の機能を実行することを要求す
る。アプリケーション・プログラムは下記の動詞を発行
する。 AIM ＿PARMはスタブが使用するべきパラメータを含むデ
ータ構造である。REQUEST ＿DATA＿AREAパラメータは要
求した機能が必要とする情報を含む、アプリケーション
定義のデータ領域である。

【００３１】GET ＿REQUEST はスタブからの機能要求を
得るため、サーバ・アプリケーション・プログラムによ
って発行される。要求がない場合、サーバ・アプリケー
ションは、要求が使用可能でなかったことを表示するRE
TURN＿CODEと共に制御を受信するか、又は要求が到着す
るまで待つことができる。アプリケーションが要求を待
つことを選択した場合、超過待ちを防止するため、タイ
ムアウト値を指定することができる。RETURN＿CODE及び
REASON＿CODEは有効な要求の到着に対抗してタイムアウ
トが発生したことを指定する。アプリケーション・プロ
グラムは下記の動詞を発行する。 REQUEST ＿DATA＿AREA， NUM ＿FUNCTION＿NAMES ， FUNCTION＿NAMES ＿ARRAY

【００３２】AIM ＿PARMはスタブが使用するべきパラメ
ータを含むデータ構造である。REQUEST ＿DATA＿AREAは
スタブがこの動詞と共同するデータを記憶する場所をア
プリケーション・プログラムが定義するフィールドであ
る。NUM ＿FUNCTION＿NAMES フィールドはFUNCTION＿NA
MES ＿ARRAY で指定された機能名称の数を含むアプリケ
ーション定義のフィールドである。

【００３３】FUNCTION＿NAMES ＿ARRAY はサーバが要求
データを受諾するための１又は１以上の機能の完全に修
飾された名称を含むアプリケーション定義のアレイであ
る。アプリケーションはNUM ＿FUNCTION＿NAMES フィー
ルドを１に設定し、アステリスク“＊”が空白の右側に
埋込まれるようFUNCTION＿NAMES＿ARRAY の最初の入力
を設定することができる。この場合、スタブはアプリケ
ーションがサービスする如何なる機能とも共同するすべ
ての単一の未済要求を返送する。AIM ＿PARMのFUNCTION
＿NAMEフィールドは要求と共同する完全修飾の機能名を
更新するであろう。完全修飾の機能名は機能名と、終止
符“．”と、修飾名（例えば、“ファンドトランスフ
ァ．ロンドン”）とから成る。

【００３４】サーバ及び要求端末両アプリケーションは
SEND＿RESPONSE動詞を使用してUNIT＿OF＿WORK＿IDと共
同するデータを送信する。UNIT＿OF＿WORK＿IDはスタブ
が使用してデータを要求端末に返送する。アプリケーシ
ョンはAIM ＿PARM構造のUNIT＿OF＿WORK＿IDを前の動詞
と同一に維持するかもしれず、又は異なる要求からのID
に変更するかもしれない。アプリケーションは下記の動
詞を発行する。

【００３５】AIM ＿PARMはスタブが使用するパラメータ
を含むデータ構造である。RESPONSE＿DATA＿AREAはこの
動詞と共同する応答データを含むアプリケーション・プ
ログラムによって定義されたフィールドである。EXCEPT
ION ＿DATA＿AREAはこの動詞と共同する例外データを含
むアプリケーション・プログラムによって定義されたフ
ィールドである。

【００３６】サーバ又は要求端末いずれのアプリケーシ
ョンも、GET ＿RESPONSE動詞を使用することにより、SE
ND＿RESPONSE動詞を使用して他のアプリケーションが送
信したUNIT＿OF＿WORK＿IDと共同する応答を検索する。
GET ＿RESPONSE動詞のホーマットは次のとおりである。

【００３７】AIM ＿PARMはスタブが使用するパラメータ
を含むデータ構造である。RESPONSE＿DATA＿AREAはスタ
ブがこの要求と共同する応答データを記憶する場所をア
プリケーションにより定義された領域である。EXCEPTIO
N ＿DATA＿AREAはこの動詞と共同するいかなる例外情報
をも記憶するよう、スタブが使用するアプリケーション
が定義するデータ領域である。

【００３８】NUM ＿UNIT＿OF＿WORK＿IDはUNIT＿OF＿WO
RK＿ID＿ARRAY に含まれているUNIT＿OF＿WORK＿IDの計
算の指定に使用されるフィールドである。UNIT＿OF＿WO
RK＿ID＿ARRAY はアプリケーション・プログラムにより
更新される単一次元アレイである。それは、１又は１以
上のUNIT＿OF＿WORK＿IDを含み、そのために動詞が応答
を取得するかもしれない。

【００３９】NUM ＿UNIT＿OF＿WORK＿ID及びUNIT＿OF＿
WORK＿ID＿ARRAY はアプリケーション・プログラムが使
用して、要求リストと共同する単一の応答を要求するこ
とができる。スタブがIDのリストをチェックしてそれら
の１つに対して使用可能な応答がある場合、スタブはRE
SPONSE＿DATA＿AREAに応答データを記憶し、応答と共同
するIDを有するAIM ＿PARM構造のUNIT＿OF＿WORK＿IDフ
ィールドを更新する。

【００４０】NUM ＿TOKENSはTOKEN ＿ARRAY に含まれる
TOKEN の計数の指定に使用される。その数は零又はそれ
以上でよい。数が零の場合、AIM ＿PARMのTOKEN フィー
ルドは有効なTOKEN を含まなければならない。TOKEN ＿
ARRAY はアプリケーション・プログラムによって更新さ
れる単一次元アレイである。TOKEN ＿ARRAY は１又はそ
れ以上のTOKEN を含まなければならないか、又はAIM ＿
PARMのTOKEN フィールドは動詞がそのために応答を得る
だろう有効なTOKEN を得なければならないかのいずれか
である。

【００４１】NUM ＿TOKENS及びTOKEN ＿ARRAY はスタブ
によって使用され、複数のOPENに対して発行された要求
と共同する応答をチェックする。この場合、スタブはTO
KENのリストをチェックして、いずれか使用可能な応答
があるか否かを判断する。応答が使用可能な場合、スタ
ブはその応答をRESPONSE＿DATA＿AREAに記憶して、正し
いTOKEN 及びIDを示すTOKEN 及びUNIT＿OF＿WORK＿IDフ
ィールドを更新する。NUM ＿TOKENS及びTOKEN ＿ARRAY
が使用されたとき、スタブはTOKEN ＿ARRAY に指定され
たこれらTOKENSのみをチェックする。

【００４２】NUM ＿UNIT＿WORK＿ID及びNUM ＿TOKENSは
零（０）でもよい。この場合、GET＿RESPONSE動詞はAIM
＿PARMのTOKEN フィールドが有効TOKEN を含むという
ことを要求する。有効TOKEN はGET ＿RESPONSE動詞の発
行が要求される。スタブはAIM ＿PARMのTOKEN と共同す
る未済応答があるか否かをチェックする。

【００４３】アプリケーションはNUM ＿UNIT＿OF＿WORK
＿ID、UNIT＿OF＿WORK＿ID＿ARRAY、NUM ＿TOKENS、及
びTOKEN ＿ARRAY フィールドを使用してGET ＿RESPONSE
動詞を発行するかもしれない。この場合、スタブは最初
UNIT＿OF＿WORK＿ID＿ARRAYをチェックした後、未済応
答があるか否かを判断するようTOKEN ＿ARRAY をチェッ
クする。判明した最初の応答はアプリケーションに戻さ
れる。すべての場合、GET ＿RESPONSEが単一の応答を返
送する。

【００４４】メッセージ動詞が使用され、スタブからメ
ッセージを検索する。スタブにより非零（０でない）RE
ASON＿CODEが戻されたときはいつでも、コードを説明す
るメッセージは、メッセージ動詞を介し、アプリケーシ
ョン・プログラムにより検索することができる。メッセ
ージ動詞のホーマットは次のとおりである。

【００４５】AIM ＿PARMはスタブが使用するパラメータ
を含むデータ構造である。MESSAGE ＿DATA＿AREAは、ス
タブがアプリケーションへ戻されたメッセージを記憶す
る場所をアプリケーションが定義した領域である。MESS
AGE ＿RETURN＿CODEは、MESSAGE 動詞の完成状況を指定
するコードでスタブを更新するということをアプリケー
ション・プログラムにより定義されるフィールドであ
る。

【００４６】CLOSE 動詞はアプリケーションとスタブ間
の接続の終了に使用される。CLOSE動詞のホーマットは
次のとおりである。 AIM ＿PARMはスタブが使用するパラメータを含むデータ
構造である。

【００４７】NUM ＿FUNCTION＿NAMES パラメータはFUNC
TION＿NAMES ＿ARRAY で指定された機能名の数を含むア
プリケーション指定フィールドである。FUNCTION＿NAME
S ＿ARRAY は閉止されるこのアプリケーションによりサ
ービスされた機能の完全に修飾された名称を含むユーザ
定義アレイである。完全に修飾された機能名は機能名、
終止符“．”、及び修飾名（例えば、“ファンドトラン
スファ．ロンドン”）により構成される。

【００４８】サーバ・アプリケーションは複数機能に対
してサービスを提供することができる。しかし、一日を
通じ、アプリケーションが個々の機能を供給できないか
もしれないときがある（例えば、データベースを更生し
なければならないかもしれない）かもしれない。その期
間中、サーバ・アプリケーションは特定機能に対しCLOS
E を発行するであろう。アプリケーションが機能供給の
継続のために作動可能となったとき、アプリケーション
は特定機能に対しOPENを発行する。アプリケーションは
NUM ＿FUNCTION＿NAMES 及びFUNCTION＿NAMES ＿ARRAY
パラメータを特定することにより、もはや提供しない特
定機能を識別することができる。以上、本発明の実施例
を説明したが、本発明はそれに限定されるものではな
く、本発明の精神及び範囲内で変化変更しうることは明
らかである。

【００４９】

【発明の効果】本発明は、以上説明したように構成する
ことにより、コンピュータの型及びモデル等に関係な
く、異なるコンピュータ設備間でコンピュータ・プログ
ラムを作動することができ、異なるコンピュータ設備を
介して容易に情報交換を可能にすることにより効率のよ
い統合システムを達成することができた。

【図面の簡単な説明】

【図１】要求端末アプリケーションとサーバ・アプリケ
ーションとの間のデータ交換の例を示す図

【図２】インターフェース・スタブと、要求端末、サー
バ、及びネットワーク機構との間の関係を示すブロック
図

【図３】本発明方法の流れ図

【符号の説明】

１０使用者１２要求端末１４サーバ２０要求端末アプリケーション２２，２５インターフェース・スタブ２４ネットワーク機能構成要素２６サーバ・アプリケーション

Claims

【特許請求の範囲】

【請求項１】少くとも１つのコンピュータ処理装置に
おいて動作する第１及び第２のコンピュータ・アプリケ
ーション・プログラム間における情報交換を容易にする
インターフェース・コンピュータ・システムであって、（イ）インターフェース・コンピュータ・プログラムに
対する前記第１のコンピュータ・アプリケーション・プ
ログラムを識別する手段と、（ロ）第１のコンピュータ・アプリケーション・プログ
ラムからインターフェース・コンピュータ・プログラム
を介して第２のコンピュータ・アプリケーション・プロ
グラムに対して要求を送信する手段と、（ハ）前記第１のコンピュータ・アプリケーション・プ
ログラムからの要求を前記第２のコンピュータ・アプリ
ケーション・プログラムが受信する手段と、（ニ）前記第１のコンピュータ・アプリケーション・プ
ログラムからの要求に応答する手段と、（ホ）前記第２のコンピュータ・アプリケーション・プ
ログラムからの応答を検索する手段と、（ヘ）前記第１のコンピュータ・アプリケーション・プ
ログラムと前記インターフェース・コンピュータ・プロ
グラムとの間の接続を終了する手段とを含むことを特徴
とするインターフェース・コンピュータ・システム。
【請求項２】前記識別手段と、前記送信手段と、前記
受信手段と、前記応答手段と、前記検索手段と、前記終
了手段とは前記それぞれの手段と共同する呼出しを実行
するライブラリ・ルーチンを含むことを特徴とする請求
項１記載のインターフェース・コンピュータ・システ
ム。
【請求項３】前記インターフェース・コンピュータ・
プログラムは各々が前記第１及び第２のコンピュータ・
アプリケーション・プログラムの１つと共同する２つの
インターフェース・スタブに分割されることを特徴とす
る請求項１記載のインターフェース・コンピュータ・シ
ステム。
【請求項４】前記第１及び第２のコンピュータ・アプ
リケーション・プログラム間においてメッセージを交換
する手段を含むことを特徴とする請求項１記載のインタ
ーフェース・コンピュータ・システム。
【請求項５】各々が共同するインターフェース・プロ
グラムを有する要求端末コンピュータ・アプリケーショ
ン・プログラムとサーバ・コンピュータ・アプリケーシ
ョン・プログラムとの間で情報を交換する方法であっ
て、前記要求端末はそのインターフェース・スタブに対し要
求呼出しを発行し、前記要求端末インターフェース・スタブはサーバ・イン
ターフェース・スタブに対し要求呼出しを送信し、前記サーバはそのインターフェース・スタブに対し要求
取得呼出しを発行し、前記サーバ・インターフェース・スタブは前記サーバに
対し前記要求を供給し、前記サーバは前記要求を処理し、前記サーバはそのスタブに対し応答送信呼出しを発行
し、前記サーバ・インターフェース・スタブは要求端末イン
ターフェース・スタブに対し応答を送信し、前記要求端末はそのスタブに対し応答取得呼出しを発行
し、前記要求端末インターフェース・スタブは前記要求端末
に対して応答を送信する各工程を含むことを特徴とする
情報交換方法。
【請求項６】前記要求端末に対する応答送信の後、前
記要求端末及びサーバはそれぞれのインターフェース・
スタブに対し閉止呼出しを発行することを特徴とする請
求項５記載の情報交換方法。
【請求項７】前記要求端末インターフェース・スタブ
の要求送信工程は作業の単位識別を発生する工程を含む
ことを特徴とする請求項５記載の情報交換方法。
【請求項８】異なるコンピュータ設備を操作する少く
とも２つのコンピュータ・アプリケーション・プログラ
ム間において情報を交換するシステムであって、前記コンピュータ設備間においてデータを送信する手段
と、前記コンピュータ・アプリケーション・プログラムの各
々と共同し、前記コンピュータ・アプリケーション・プ
ログラムから共通のアプリケーション・プログラミング
・インターフェースを使用してプログラム呼出しを解釈
するライブラリ・ルーチンと、前記送信手段により情報
を交換する手段とを供給するインターフェース・プログ
ラミング手段とを含み、アプリケーション・プログラムはコンピュータ設備と関
係なく、共通のアプリケーション・プログラミング・イ
ンターフェースと情報を交換することができることを特
徴とする情報交換システム。
【請求項９】前記ライブラリ・ルーチンはプログラミ
ング呼出しステートメントを解釈するコンピュータ・プ
ログラミング・コードから成ることを特徴とする請求項
８記載の情報交換システム。
【請求項１０】前記呼出しステートメントは前記イン
ターフェース・プログラミング手段に対するアプリケー
ションを識別する呼出しと、情報を要求する呼出しと、
情報を送信する呼出しと、情報を受信する呼出しとを含
むことを特徴とする請求項８記載の情報交換システム。