JP3179513B2 - 異種ネットワーク環境における適用業務プログラムの統合システム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ネットワーク環境に存
在する適用業務プログラムを統合するシステムに関する
ものであり、とりわけ、１つまたは複数のネットワーク
を介して接続され、同じ、または、異なるコンピュータ
アーキテクチャを備える同じコンピュータまたは異なる
コンピュータにおける異なる適用業務間の転送のため
に、データメッセージを変換し、操作するためのメカニ
ズムを有するシステムに関するものである。

【０００２】

【従来の技術】コンピュータ時代の初めから、コンピュ
ータ、とりわけ、コンピュータソフトウェアプログラム
は、以前は機械的に処理されていたプロセスを自動化す
るためにさまざまな環境で利用されてきた。一般に、こ
の自動化によって、効率が良くなり、生産性が増大し
た。しかしながら、こうした自動化はコストがかかるた
めに大企業及び大工場の自動化は、しばしば、ばらばら
に実施されてきた。例えば、組立ラインの異なる部分
が、異なる時期に自動化されてきたが、その自動化は、
購入時に利用可能な各種コンピュータシステムの機能が
異なるために、しばしば、異なるコンピュータ装置によ
ってなされてきた。その結果、多くの組立ライン及び企
業において、プロセス全体の中のさまざまな機能は自動
化されるが、それらは必然的に互いに連絡のとれない
「自動化群島（islands of automation）」を生じるこ
とになった。さらに、オフィス環境においては、新しい
コンピュータ装置との通信を可能にするため、ＬＡＮが
用いられてきたが、データに互換性がないために、一般
に、ソフトウェア適用業務の統合はされていない。

【０００３】同じネットワークに接続されており、互換
性のないデータタイプをもつ、これらの異なる「自動化
群島」及びマシンはそれ程容易には互いに通信を行なう
ことができないので、このような異種接続システムの場
合、自動化の効率を上げることに対して重大な問題を生
じる。結果として、相互通信可能な同種の装置で同時に
工場全体の自動化を行なう場合を除き、中央位置から大
規模な製造設備用の組立ラインのプロセス全体を制御す
ることは、個々のプロセスを別個に制御しない限り、困
難でもあり高価でもあった。従って、既にばらばらに自
動化された企業及び工場の場合、全ての装置を排除して
同種の装置に取り換えることができるようにするか（極
端に高い関連費用を払って）、あるいは、交換が可能な
ように既存のシステムが老朽化するのを待つか（やはり
かなりの費用を払って）という選択に直面することにな
る。

【０００４】上記問題に対する解決策の１つは、ソフト
ウェアプログラマを雇って、異なる「自動化群島」が互
いに通信できるようにするカスタムコードを作成するこ
とである。しかしながら、こうしたアプローチはやはり
高くつき、かなり融通性に乏しいので、システム全体が
静的な状態にとどまるものと思われる。すなわち、さら
に装置及び適用業務ソフトウェアをシステム全体に統合
しなければならない場合には、ソフトウェアプログラマ
を呼び戻して、関係する全ての適用業務のコードを書き
直させ、インタフェースのために追加のカスタムコード
を用意させる必要がある。従って、より融通性に富み、
コストのかからない解決策が必要になる。

【０００５】既存の異種の適用業務の統合は、これから
十分に解決しなければならない問題である。ハードウェ
ア及び関連するオペレーティングシステムが違うため
に、また、適用業務自体が異なるために既存の適用業務
のこうした統合には、数多くの重要な問題がある。例え
ば、コンピュータが、所有権をもつハードウェアアーキ
テクチャ及びオペレーティングシステムによって構築さ
れているので、あるシステムで実行されている適用業務
からのデータが、別のシステムでは利用できないという
場合がよくある。また、多様なネットワークサービスが
存在するために、プログラマは、しばしば、適用業務の
コードを変更して、異なるネットワークサービス群に対
するインタフェースを生成しなければならない。さら
に、異なる適用業務は、その特定の必要性に応じて、異
なるデータタイプを使用するので、結果として、プログ
ラマは、別の適用業務からのデータを受信側の適用業務
が利用できるように、受信側の適用業務のコードを変更
しなければならない。さらに、適用業務によるデータ要
素のグループ化が異なるため、しばしば、互換性のない
データ構造が生じることになる。例えば、２つの適用業
務における共通の論理定義を備えた要素は、やはり、２
つの異なる物理的方法で記憶される場合がある（すなわ
ち、適用業務Ａは１つの２次元配列にそれを記憶し、適
用業務Ｂは２つの１次元配列にそれを記憶する場合があ
る）。さらに、記述言語が異なる適用業務は、しばし
ば、データの値も異なる値として解釈するので、異なる
言語で記述された他の適用業務とは通常は、通信できな
い。例えば、Ｃ及びＦＯＲＴＲＡＮは、論理値すなわち
ブール値を異なる値として解釈する。

【０００６】上述の問題に対する部分的解決策として、
各種適用業務によるデータの共有を可能にする分散ネッ
トワークの形成が提案された。その場合には、これらの
適用業務は、サン・マイクロシステムズ（Sun Microsys
tems）のネットワーク・ファイル・システム (NFS)、Ａ
Ｔ＆Ｔのリモート・ファイル ・シェアリング (RFS)、
ＦＴＡＭ（MAP/TOP仕様で規定）、または、アポロ（Apo
llo）のドメイン・ファイル・システム（Domain File S
ystem）といった透過データ共有メカニズムに依存し
た。しかし、これらのシステムでは、データの共有は可
能になるが、実行される異なる適用業務プログラムの真
の統合は可能にならないという点で限界がある。

【０００７】分散ネットワークで接続された異なるコン
ピュータプロセス間におけるプロセス間通信を可能にす
るシステムのもう１つの例は、ディジタル・イクイップ
メント社（Digital Equipment Corp）によるプロセス・
アクティベーション・アンド・メッセージ・サポート
（Process Activation and Message Support (PAMS)）
システムである。このシステムでは、一般に、プロセス
が、共通のネットワークのどこに位置するかに関係な
く、互いに通信することが可能となる。こうしたプロセ
スは、単一のＣＰＵ上にある場合もあれば、ワークステ
ーション、クラスタ、あるいは、ローカルネットワーク
または広域ネットワーク（ＬＡＮまたはＷＡＮ）間に広
がって存在している場合もある。ＰＡＭＳシステムは、
ネットワーク上の全ての接続を管理し、統合機能を提供
して、それぞれのワークステーション、クラスタ等にお
けるプロセスの通信を可能にする。すなわち、ＰＡＭＳ
メッセージ処理システムは、他のネットワークより上位
で実施され、新しいネットワーク及び事象を透過的に統
合して共通のメッセージバスに送り込むネットワーク層
である。こうしたシステムによって、ネットワーク構成
のモニター及びメッセージバス上のメッセージの流れの
モニターを単一ポイントで行なうことが可能になる。そ
の結果、コンピュータシステムが接続される全てのホス
ト環境に対して共通のプログラミングインタフェースが
得られる。こうして、ユーザにとっては、全てのホスト
環境が同じに見える。

【０００８】例えば、ＵＬＴＲＩＸ−ＰＡＭＳを実行す
るＵＬＴＲＩＸのホスト環境は、そのネットワーク上で
ＶＡＸ−ＰＡＭＳを実行するＶＭＳホストに直接続され
ており、ＵＬＴＲＩＸ−ＰＡＭＳは、ＶＡＸ転送プロセ
スを利用して、ネットワーク上の全てのメッセージの経
路指定を行なう。そこで、ＵＬＴＲＩＸ−ＰＡＭＳとＶ
ＡＸ転送プロセスを使用して、メッセージの経路指定を
行なうための特定の規則が規定されるが、この場合、Ｕ
ＬＴＲＩＸ−ＰＡＭＳは、全機能を備えたＰＡＭＳルー
タに対するネットワークを介してしか他のＰＡＭＳプロ
セスと通信できないという点で、従属転送機構として機
能する。結果として、ＰＡＭＳシステムは、ＵＬＴＲＩ
Ｘプロセス間の「直接の」タスク間通信に対して支援し
ないという点で限界がある。さらに、ＶＡＸ−ＰＡＭＳ
の経路指定ノードを介して、全てのトラフィックを経路
指定しなければならないので、システムにとっては、単
一の故障ポイントが存在することになる。

【０００９】さまざまなマシンが１つの単一統合情報シ
ステムとして機能する情報処理環境のために、他のシス
テムが提案されている。しかし、これまでのところ、こ
うしたシステムは、共通のネットワークに接続された異
なるマシンで実行される同種の適用業務の各種サブルー
チンの接続に限定されている。例えば、アポロ（Apoll
o）のネットワーク・コンピューティング・システム
（ＮＣＳ）は、プロセス（ユーザ適用業務）が、リモー
トサーバプロセスによって送り出されるサービスに対す
る手続き呼出しを行なえるようにする、リモート手続き
呼出し（ＲＰＣ）のソフトウェアパッケージである。し
かしながら、ＮＣＳは既存の適用業務の統合を可能にす
るメッセージ及びファイル処理システム、データ操作シ
ステム、ローカル及びリモートのプロセス制御システム
等を提供しないので、こうしたＲＰＣシステムは、ネッ
トワークトランザクション管理システムの開発には適合
しないのが普通である。すなわち、ＮＣＳは、新しい分
散適用業務の構築を可能にするが、既存の異種の適用業
務の統合を可能にするものではない。その代り、ＲＰＣ
はネットワーク化の細部及びマシンのアーキテクチャか
らユーザを切り離し、同時に、適用業務の開発者が、既
存のネットワークを介して提供されるサービスに対する
構造化インタフェースを定義できるようにする。

【００１０】ＲＰＣモデルは、それらがどうように使用
されるべきかについて指示しないので、さまざまなレベ
ルで使用される可能性がある。一般に、開発者は、単一
適用業務のサブルーチンを選択し、適用業務またはサブ
ルーチンコードを変更せずに、リモートマシン上で実行
することができる。ＲＰＣの最も単純な利用は、プリン
タ、プロッタ、バックアップタスク用のテープ駆動装
置、複雑で、時間を浪費する数学プロセッサ等のよう
な、適用業務によって直接呼び出すことが可能な分散資
源に固有のアクセスを行なうことである。適用業務レベ
ルにおけるＲＰＣのより効率的な利用は、適用業務を区
分して、ソフトウェアモジュールとそれらが使用する資
源とを同じ場所に配置することである。例えば、データ
ベースからデータを抽出する必要のある適用業務を分離
して、データベースにアクセスするモジュールをデータ
ベースマシンに配置するようにすることが可能である。

【００１１】図１にはＮＣＳの図が示されている。そこ
に示されているシステム100は、一般に、３つの構成要
素、すなわち、データのパッケージ化、送受信、及びユ
ーザプロセスとサーバプロセス間におけるエラー補正を
扱うＲＰＣランタイム環境132、134、高レベルのネット
ワークインタフェース定義言語（ＮＩＤＬ）をコンパイ
ルして、接続の両側（ユーザコンピュータとサーバコン
ピュータ）で実行するＣ言語コードにするネットワーク
インタフェース定義コンパイラ（ＮＩＤＣ）136、及
び、実行時に、ネットワーク上のどのリモートコンピュ
ータがユーザコンピュータに必要なサービスを提供する
ことができるかを適用業務に決定させるロケーションブ
ローカ(Lacation Broker)128から構成される。すなわ
ち、図１に示すように、ユーザ適用業務102は、リモー
トコンピュータ上の所望のサブルーチンのように見せか
ける手続き呼出しトランスレータスタブ104とインタフ
ェースする。動作時、ユーザコンピュータのＲＰＣラン
タイムシステム106、及び、サーバシステムのＲＰＣラ
ンタイムシステム108は、標準的なネットワークを介し
て互いに通信を行い、リモート手続き呼出しを可能にす
る。リモートサブルーチン112の適用業務のように見せ
かけるサーバ側スタブ110は、それゆえ、リモートサブ
ルーチン112をネットワークを介してユーザシステムに
接続する。

【００１２】ＮＣＳシステムは、プログラマがサブルー
チンの呼出しを利用して、リモートサブルーチンによっ
て使用され、返されるデータの数及びタイプを規定でき
るようにする働きをする。さらに詳しくは、ＮＣＳによ
って、適用業務開発者が、ネットワークインタフェース
定義言語（ＮＩＤＬ）と呼ばれる言語でインタフェース
定義114 を行ない、これが、さらに、ＮＩＤＬコンパイ
ラ116を介して送られ、ユーザスタブとサーバスタブの
両方に対するＣのソースコードを自動的に発生させるこ
とが可能になる。すなわち、ＮＩＤＬコンパイラ116
が、スタブソースコード118及び120 を発生し、これ
が、さらに、Ｃコンパイラ124及び126によって、ＲＰＣ
ランタイムソースコード122と共にコンパイルされ、適
用業務102、及び、ユーザマシンで実行されるユーザ側
スタブ104とリンクされることになり、一方、リモート
サブルーチン112及びそのサーバ側スタブ110は、サーバ
マシンでコンパイルされ、リンクされる。適用業務102
が書き込まれ、ネットワークに配信されると、ユーザ
は、ネットワーク情報130を含むロケーションブローカ
(location broker)128を利用して、必要とされるサービ
ス（ＲＰＣ）がサーバシステムで利用可能かどうかを問
い合わせることが可能になる。

【００１３】このように、ＮＣＳでは、ＮＩＤＬコンパ
イラが、適用業務とリモートサブルーチンの間で送られ
るデータを生成し、解釈するスタブを自動的に発生す
る。結果として、リモートサブルーチン呼出しは、リモ
ートホスト上で実行するためにたまたま発生したローカ
ルのサブルーチン呼出しにすぎないように見え、適用業
務開発者は、プロトコル操作を実施する必要がない。す
なわち、ＮＣＳシステムは、主として、リモート実行サ
ービスであり、１つのデータタイプから他のデータタイ
プへの変換を可能にするために、メッセージの再構成を
行なうことにより、転送のためのデータ操作を実施する
必要はない。1987年６月のユニックス・レビュー（Unix
Review）66〜75頁に記載されている「Each Piece In I
ts Place」と題するH.Johnsonによる論文には、ＮＣＳ
システムに関するより詳細な解説がある。

【００１４】ＮＣＳのＲＰＣシステムは、主として、ク
ライアント及びサーバが、あらかじめ、どんな要求及び
回答が生じるかについて合意しているクライアント／サ
ーバ関係において、同期して動作するリモート実行サー
ビスを提供する。適用業務は、ＮＣＳで実行されるよう
に明確に開発されるか、あるいは、ＮＣＳで実行される
ように十分に記録されなければならない。さらに、リモ
ート手続きは、いつ再び呼び出されるかを明らかにでき
ないので、通信をいつもその実行の始めから開始し、そ
の終りで終了することになる。呼出し毎に開始と終了を
行なうことは、リモート手続きが、その発呼者との接続
をセットアップする際の性能において多くの犠牲を払う
ことになる。結果として、ほとんどのＲＰＣシステムに
は、接続がない。これが、ＮＣＳのようなＲＰＣシステ
ムが、既存のプロトコルの上位にもう１つのプロトコル
を構築して、信頼性を確保しなければならない理由であ
る。このオーバヘッドによって、性能を低下させる追加
処理を実施することになる。

【００１５】従って、ＮＣＳは、異種のネットワーク環
境におけるリモート実行に対して、一貫した方法を提供
するが、主として、ネットワークを介したプリンティン
グ及びプロッティングといったブローカが割り当てるサ
ービスに対して設計されており、ユーザは、プリントさ
れる限り、どのプリンタが情報をプリントするかについ
ては気にしない。他のタイプのサービスは、適用業務の
処理時間を提供するものであるが、そこでは、メッセー
ジの少量のデータによって、それ自体がメッセージに変
わりうる、ある解答を得るための集中的で、時間のかか
る計算努力がトリガされる。しかし、ＮＣＳシステム
は、互換性のないノードタイプのフォーマット及びデー
タ処理言語に対して、真に統合化されたシステムを提供
することはできない。

【００１６】

【発明が解決しようとする課題】既知の先行技術による
システムには、異種のネットワーク環境と同種のネット
ワーク環境の両方または一方において既存の異種の適用
業務を統合するという重要な問題に取り組んでいるもの
はない。従って、ユーザには明白な方法で、異種のコン
ピュータと同種のコンピュータの両方または一方のネッ
トワーク環境においてプログラムされた既存の適用業務
間における、フレキシブルなデータ転送および変換、及
び、データ操作を提供する統合システムが、当該技術に
おいて長年にわたって必要と考えられてきた。本発明
は、これらの要求に応えるために設計されたものであ
る。

【００１７】

【課題を解決するための手段】本書で開示され、請求さ
れる内容の発明者は、システムインテグレータまたはエ
ンドユーザが、異種のコンピュータのネットワーク環境
において既存の適用業務を統合するためのランタイムソ
フトウェアをフレキシブルに、かつ、効率良く作成でき
るようにするソフトウェアツールを開発することによっ
て、当該技術において長年にわたり感じられてきた上述
の要求を満たした。この目的を達成するため、本発明
は、メッセージ及びファイル処理システム、データ操作
システム、及び、ローカル及びリモートプログラム制御
システムを組み合わせたものに等しい機能性を提供す
る。システムインテグレータの観点からすると、本発明
は、メッセージシステムの各端部でデータタイプ及びデ
ータフォーマットが異なってもよく、同時に、メッセー
ジのデータ要素、データタイプ、あるいは、データフォ
ーマットに変化があった場合に、起動前にシステムを再
構築することだけを必要とするメッセージ処理システム
を提供するものである。システムの再構築は、管理レベ
ルのアクティビティであるため、ユーザは通信適用業務
において、ユーザのソースコードを変更する必要がな
い。

【００１８】従って、本発明は、やりとりするデータタ
イプ及びデータフォーマットを簡単に修正して、異なる
タイプのマシン上での異なるフォーマットのデータプロ
セス間で透過的な通信を可能にするように特殊化された
ものである。結果として、通信する適用業務プログラム
は、同じ言語で書いたり、あるいは、同じタイプのコン
ピュータにダウンロードする必要はない。さらに、本発
明は、ユーザが、既存の適用業務のコードに対して、最
小限の変更で、あるいは、全く変更を加えずに、既存の
適用業務をリンクすることができるようにするが、この
ことによって、既存のシステムを統合するために書き、
維持し、支援するために必要なカスタムコードの量を減
らすことができる。

【００１９】本発明は、適用業務に対して、最小限の修
正で、あるいは、全く修正を加えずに既存の適用業務を
リンクすることをを可能とするローカル及びリモート適
用業務間のデータ転送を提供することによって、本明細
書の背景部分で述べた重要な統合の問題を取り扱ってい
る。適用業務間における同期及び非同期メモリに基づく
メッセージ転送及びファイル転送もまた支援される。さ
らに、言語、データフォーマット、及び、データタイプ
の違いは、フィールドの再構成、追加または削除、及
び、ハードウェア、言語のアライメント、及びデータサ
イズの相違に応じたデータタイプ間の変換といったデー
タ操作機能を利用することによって解決される。これ
は、望ましい実施例においては、共通データ表現（ＣＤ
Ｒ）を利用して、異種のノード間でメッセージの転送が
行われるようにすることによって実現される。

【００２０】本発明のデータマニプレータ（ＤＭＭ）
は、実行時にデータの自動操作を行うことによって、２
つの通信プロセスが、それ自体のデータモデルの変更を
必要とせずに、互いのデータを使用することができるよ
うにする。本発明のデータマニプレータは、ハードウェ
アの相違、適用業務の依存性、コンピュータ言語の意味
上の違いについて処理を施す。それは、１つのデータタ
イプを他のデータタイプに変換し、メッセージフォーマ
ットを再構成し、データ項目に値を割り当てることがで
きる。

【００２１】一般に、変換ルーチンは、関係する２つの
マシンのアーキテクチャと２つの言語の両方または一方
にしか有効ではない。このネットワークシステムに新し
い言語または新しいマシンアーキテクチャを追加する
と、ネットワークにおける以前のマシンアーキテクチャ
の全てについて、新しい組をなすルーチンを生成して、
新しいマシンでの適用業務、または、新しい言語で書か
れた適用業務に対するデータ転送を支援しなければなら
ない。本発明は、システムに新しいマシンまたは言語を
追加する場合に、古いマシンアーキテクチャについて書
かれたルーチンに対する変更または追加を最小限にとど
めるように設計されている。また、データ操作モジュー
ルをノードに固有のものにすることによって、特定のマ
シンが、他のマシンへデータを送信するために、また
は、他のマシンからデータを受信するために必要なルー
チンの組数を、本発明に従って削減することも可能であ
る。

【００２２】

【実施例】本発明の現在のところ望ましい実施例による
上述の有効な特徴を備えたシステムについて、図２〜図
９に関連して以下に説明する。当業者であれば明らかな
ように、これらの図に関連して本書で行う説明は、例示
を目的としただけのものであり、本発明の範囲に制限を
加える意図は全くない。本発明の範囲に関する全ての疑
問は、付記した特許請求の範囲の欄を参照することによ
って解決される。

【００２３】上述のように、今日の製造用コンピュータ
システムは最初から既成されている場合が多く、そのた
め、孤立した「自動化群島」が生じることになる。例え
ば、設計及び工学、製造資源プランニング、及び、製造
の領域は、一般に、個別に自動化される。結果として、
これら自動化群島は、異種の、コンピュータシステム、
オペレーティングシステム、及び、データベースシステ
ムから構成される。しかし、製造業者は、今やこうした
先行技術のシステムで得られるものに比べて、より高レ
ベルの効率及び生産性を求めている。コンピュータ統合
化製造（ＣＩＭ）、すなわちこれら自動化群島の統合
は、こうしたよりレベルの高い効率及び生産性を獲得す
る手段である。本発明の望ましい実施例は、ＣＩＭソリ
ューションの開発を容易にするために設計されたもので
ある。下記から明らかなように、これは、フレキシブル
なデータ転送、変換、及び、操作メカニズムを提供し
て、既存の適用業務プログラムを異種のコンピュータの
ネットワーク環境に統合することによって達成される。

【００２４】一般に、本発明は、同じまたは異なるノー
ドで適用業務間の通信を行なうため、実行時に用いられ
るいくつかの活動プログラム（またはソフトウェアモジ
ュール）からなるランタイムコードを作成する。ここ
で、ノードとはネットワーク領域内の任意のコンピュー
タである。適用業務は、異なるコンピュータシステムに
も、あるいは、同じコンピュータシステムにものせるこ
とが可能であり、同じまたは異なるコンピュータ言語で
作成することもできる。これらのランタイムプログラム
は、ＣＤＲを用いて、送信元のプログラムからのデータ
をアーキテクチャ及び言語に依存しないフォーマットに
変換することによって、送信元の適用業務プログラムか
ら、送信先の適用業務プログラムへのデータ転送を処理
する。例えば、送信元のマシンのフォーマットによるフ
ィールド及びレコードのデータは、送信元のマシンのデ
ータの内部表現を共通データ表現フォーマットに変換す
るローカルに記憶されたルーチンを用いて、そのデータ
をまずＣＤＲに変換し、そのＣＤＲデータの転送後、ロ
ーカルに記憶されたルーチンを用いて、そのＣＤＲデー
タを送信先のマシンのデータの内部表現に変換すること
により、送信先のマシンのフォーマットに変換される。
さらに、送信元のマシンと送信先のマシンとの間で予め
規定されているリンクが、本発明のソフトウェアモジュ
ールによって呼び出され、その情報が、送信元のマシン
から送信先のマシンに正確に経路指定されているかを確
認する。この後者の情報は、構成データと呼ばれ、シス
テムインテグレータによって提供される、ネットワーク
上のノードとネットワーク上で実行されるプロセス及
び、実行される可能性のあるデータ操作に関連する情報
に対応する。

【００２５】本発明のシステムは、一般に、ランタイム
構成要素と非ランタイム構成要素によって構成される。
本発明のランタイム構成要素について、図２〜図４に関
してさらに詳述し、一方、非ランタイム構成要素につい
ては、図５及び図６に関してさらに詳細に後述する。

【００２６】図２に示すように、ランタイム構成要素20
8には、データマニプレータ／トランスレータ、データ
転送装置、構成テーブル、及び、システム管理が含まれ
ている。さらに詳細に下記するように、データマニプレ
ータ／トランスレータは、特定のホストコンピュータの
所定のプロセスにアクセス可能なＣＤＲフォーマットへ
の、及び、ＣＤＲフォーマットからのデータ変換を行な
う働きをし、一方、データ転送装置は、送信先の適用業
務に対して送信を行なうために、ネットワークシステム
への、及び、該ネットワークシステムからの共通データ
表現によるデータを転送する働きをする。ただし、下記
するように、送信元の適用業務及び送信先の適用業務が
同じタイプ及びフォーマットであり、従って、メッセー
ジデータに操作を施す必要のない場合、データ転送装置
は、操作を施していないデータを送信先の適用業務に送
る働きもする。

【００２７】従って、図２に示すように、本発明のシス
テムの場合、本発明のランタイム構成要素208と通信す
るため、複数のユーザ適用業務202が、アクセスルーチ
ンライブラリ206を利用し、適用業務アダプタ204を介し
て接続される。適用業務アダプタ204は、ユーザの適用
業務と本発明のシステムとの間におけるソフトウェアブ
リッジとして動作する、ユーザによって書かれたプログ
ラムから構成される。詳しくは、これらのユーザによっ
て書かれた適用業務アダプタプログラムは、本発明のネ
ットワークでメッセージの送信、ファイルのコピー、プ
ロセスの制御等を行なうために、アクセスルーチンライ
ブラリ206からアクセスルーチンを呼び出す。こうし
て、これらのアクセスルーチンを利用して適用業務アダ
プタプログラムの作成に必要なコマンドがユーザに与え
られる。

【００２８】システムマネージャ210は、ユーザがラン
タイム構成要素の動作中にシステム動作の管理を行なえ
るようする。例えば、システムマネージャ210は、ユー
ザが本発明のソフト ウェアにアクセスして、構成の妥
当性を確め、システムの始動、停止を行ない、他のシス
テムの管理機能を実施できるようにする。一方、コマン
ドプロセッサ212は、ユーザが対話によってメッセージ
のテストを行なえるようにするために、システムマネー
ジャ210を介してアクセスされるモジュールに対応し、
本発明の領域内にあるプロセスまたはノードとリンクす
る（本書で用いられる「領域」は、本発明に従って、協
調して動作するように構成されたコンピュータの集合を
意味している）。さらに、構成ファイル214には、ノー
ドに関する情報、プロセスによって作成され、使用され
るデータ構造、異なるプロセスがアクセスできるように
するために、適用業務によって作成されるデータについ
て実施しなければならない操作、及び、操作と特定の言
語を結びつけるリンクが含まれている。こうした情報
は、実行時前に、システムインテグレータによって与え
られが、この情報については、さらに詳細に下記する。
ランタイム構成要素が、システムマネージャ210を用い
て、始動時に各ノードにロードされ、これらのランタイ
ム構成要素は、メッセージを操作し（必要に応じて）、
データ転送装置を利用してその転送を行なう。操作は、
各ノード毎に、メモリに保持された構成ファイル214 の
データに基づいて実施される。最後に、データ転送装置
は、ネットワークサービス216と通信し、メッセージを
送信先のノードに送る。

【００２９】図３には、本発明に従ったシステムを示し
ているが、ここでは、ＬＡＮ上の２つのノードが、適用
業務１〜４を統合するために、本発明によるランタイム
統合システムＡ及びＢを備えている。図示のように、た
とえデータタイプ及び言語フォーマットが異なっていて
も、プロセス１〜４が通信を行なえるようにするため、
各ノード毎に、本発明のランタイムシステム（図２に示
す全ての要素が含まれる）がロードされる。図３の場
合、図示プロセス間における通信にはさまざまな可能性
がある。例えば、適用業務１は、統合システムＡを介し
て適用業務２と通信可能である。適用業務１は、ホスト
コンピュータの共有メモリに、おるいは、ホストのディ
スクに常駐するファイルの形態で、適用業務２を表わす
データを発生することかできる。このデータは、適用業
務アダプタ１によって検出されて、統合システムＡに送
られ、統合システムＡによって、さらに、このデータは
適用業務アダプタ２に渡されて、適用業務２に送られ
る。適用業務２に送る前に、統合システムＡに命じて、
データを操作することも随意に可能である。データ操作
は、データに対するリテラル割当て、１つの構造から他
の構造へのデータの移動、及び１つの構造から他の構造
へのデータの変換から構成することができる。

【００３０】一方、データを適用業務アダプタ１によっ
て検出し、統合システムＡに送ることが可能である。こ
のデータは、次に、ＬＡＮを介して統合システムＢに送
られる。適用業務アダプタ３は、統合システムＢからデ
ータを受け取り、次に、それを利用するために適用業務
３に送信する。ユーザは、必要なデータ操作を統合シス
テムＡと統合システムＢのどちらで行なうかを決めるこ
とができる。

【００３１】図４には、実行時に、異種のネットワーク
システムの所定のノード400で実施される本発明が示さ
れている。図示のように、本発明の統合システムは、ノ
ード400で実行するユーザ適用業務プログラム（プロセ
ス）402の全てを統合する。他のノード（不図示）で実
行する適用業務も、同様に統合される。図２に関連して
上述したように、これらの適用業務プログラム402は、
それぞれ、アクセスルーチン404を介して本発明の統合
システムにアクセスが許され、アクセスルーチンのライ
ブラリを介して、本発明の統合システムとの通信を行な
う。

【００３２】リクエストマネージャ（ＲＭ）406は、全
てのユーザ適用業務プログラムの要求に関する単一の待
ち行列を維持し、ノード400で規定されているプロセス
毎に、１つの入力が、所定の時間に読み取られるように
することができる。リクエストマネージャ406 は、適用
業務プログラム402から要求を読み取り、要求されたア
クションを実施する。要求は、以下のタイプを取りう
る。即ち、サンプルとしてあげたアクセスルーチンから
明らかなように、メッセージの読取り、メッセージの送
信、ファイルの送信、別のプロセスの開始、別のプロセ
スの停止、ＲＭメッセージの待ち行列領域のクリア、ス
プリーング装置（以下では、ディスク装置と記載）410
へのエラーの記録、データ転送に対するオプションの設
定、特定のメッセージの削除などである。例えば、ユー
ザの適用業務プログラム402は、アクセスルーチンを呼
び出して、他のノードの適用業務プログラムにメッセー
ジを送り、適用業務プログラム402によってモニタされ
る値が状態を変えたことを指摘する。次に、リクエスト
マネージャ406がその構成テーブル408、及び、適用業務
アダプタからの要求をチェックし、データ操作が要求さ
れたか否か、及び、メッセージをリモートノードに送る
のにデータ操作が必要か否かを確かめる。図５に関連し
て後述するように、構成テーブル408には、ネットワー
ク内の全てのノード、プロセス、及び、全てのメッセー
ジ転送について可能性のあるデータ操作に関する情報が
含まれている。従って、それぞれのノードだけでなく、
要求されたメッセージの送信元のプロセスと送信先のプ
ロセスを確め、要求されたメッセージがリンクの論理名
の指定を行なったか否かを確認することによって、リク
エストマネージャ406は、データが転送のための操作を
必要とするか否かを判定することができる。リクエスト
マネージャ406は、また、他のプロセスからの入力デー
タについてのリンクしたデータメッセージのリストを含
む、メッセージ待ち行列（メモリ領域）409の保持も行
なう。さらに、リクエストマネージャ406は、要求があ
れば、送信プロセスによってユーザメッセージをディス
ク410に記録することができる。エラーメッセージなど
のような情報もまた、システム診断時の利用のために記
憶することも可能である。

【００３３】リクエストマネージャ406によって、指示
されたメッセージに操作の必要がある（すなわち、送信
元のメッセージが、異なるフォーマットと異なる言語の
両方または一方に変換する必要がある）と判定される
と、その要求は、データ操作モジュール（ＤＭＭ）412
に送られ、後述するように、そのメッセージは、送信先
のノードへ送られる前に、共通データ表現（ＣＤＲ）に
変換される。適用業務プログラム402からのメッセージ
が、データファイルの転送を要求する場合には、指定さ
れたファイルは、ファイル転送モジュール（ＦＴＭ）41
4によって送信先のノードに転送される。ファイル情報
を含むファイルメッセージは、ファイル転送が正常に終
了した後、出力ネットワークマネージャ（ＯＮＭ）416
に送られる。リクエストマネージャ406によって、適用
業務プログラムは、操作を加えずに、メッセージを送信
先のプロセスへ送るべきであると判定されると、操作は
実施されない。メッセージデータは、従って、直接、出
力ネットワークマネージャ（ＯＮＭ）416に送られる。
ＯＮＭ416は、リクエストマネージャ406から操作を施し
ていないメッセージを受信し、ファイル転送モジュール
414からファイルが転送されたことを示すメッセージを
受信し、あるいは、データ操作モジュール412によって
共通データ表現に変換されたメッセージを受信し、そし
て、送信先のノードへメッセージを送るためにネットワ
ークサービス呼出しを行なうことによって、ＬＡＮ上に
メッセージを出力する。送信プロセスによって「クリテ
ィカル」と指定され、ネットワークを介して送信先のノ
ードへうまく送ることのできないメッセージは、ＯＮＭ
416によってディスクファイル420に記憶（スプール）さ
れる。ノードまたはネットワークの故障、あるいは、シ
ステムの停止を含むいくつかの理由で、メッセージを送
れなくなる可能性がある。メッセージを送れなくなった
もとの原因が修正されると、ＯＮＭは、ディスク420に
スプール済みのメッセージの送信を再度試みる。

【００３４】送信プロセスが、「待機して(with-wai
t)」メッセージを送るように指定している場合は、メッ
セージを送信先のノードに送ることができなかった時
は、ＯＮＭ416はリクエストマネージャ406の入力待ち行
列にステータス情報を送る。しかし、メッセージに操作
の必要がなく、送信先のプロセスが同じノードにある場
合は、メッセージは、ＯＮＭ416を介しては送られな
い。代りに、送信先のプロセスのメッセージ領域の待ち
行列に、メッセージが直接送り込まれ、不必要なデータ
送信が防止される。送信プロセスが「保証付配送(guara
nteed delivery)」でメッセージを送るように指定して
いる場合は、リクエストマネージャ406は、受信したメ
ッセージをディスク410に保管し、適用業務プログラム4
02から削除要求のある場合に限って、こうしたメッセー
ジを削除する。一般に、削除要求が行なわれる前に、受
信プロセスによって、読取り要求が行われる。メッセー
ジが保証付配送で送られることにならない場合には、リ
クエストマネージャ406は、そのメッセージをメモリ領
域409に保管し、このメッセージは読取りメッセージ要
求によって、受信プロセスに利用できる。受信プロセス
が、読取り要求を行なう場合、このメッセージを削除す
るか否かを指定することができる。

【００３５】入力ネットワークマネージャ（ＩＮＭ）41
8は、ネットワークから入力メッセージを受信し、送信
先の適用業務プログラム402に送られる前に、これらの
メッセージを共通データ表現フォーマットからローカル
のフォーマットに変換する必要があるか否かを判定す
る。送信元のノードが、異なるデータタイプのノードで
ある場合、あるいは、送信元のプログラミング言語が異
なる場合のように、こうした変換が必要な場合は、メッ
セージをリクエストマネージャ406の入力待ち行列に送
る前に、変換（アンマーシャリング（unmarshallin
g））ルーチンのライブラリを用いて、共通データ表現
からローカルのデータ表現にメッセージを変換する。こ
うした操作を必要としない入力メッセージは、直接、リ
クエストマネージャ406の入力待ち行列に送られる。

【００３６】最後に、図２に関連して上述したように、
システムマネージャ422は、実行時に、ユーザが本発明
の統合システムのシステム管理機能を管理できるように
するために設けることもまた、望ましい。この目的のた
めに、特定のノードを選択することが望ましい。

【００３７】操作は、第１の言語Ａ及び第１のタイプの
データフィールドを備えた適用業務Ａが、第２の言語Ｂ
及び第２のタイプのデータフィールドを備えた適用業務
Ｂと実行時に通信を行う時に、行なわなければならな
い。本発明の操作技法によれば、データ定義言語（ＤＤ
Ｌ）を利用して、適用業務プログラムＡ及び適用業務プ
ログラムＢのデータフィールドが定義される。次に、Ｄ
ＤＬのデータフィールドに操作（再構成）が施される
か、あるいは、データタイプが、データ操作言語（ＤＭ
Ｌ）によって抽象構文表記１（ＡＳＮ．１）の基本コー
ド化ルール（ＢＥＲ）のような汎用コード化体系を備え
た共通データ表現（ＣＤＲ）のデータタイプに変換され
る。次に、操作を施されたデータが、送信先のノードに
おいて、適用業務Ｂに関連したデータフィールドを備え
た言語Ｂに変換される。ＤＤＬとＤＭＬについて、今か
らさらに詳細に説明する。

【００３８】前述のデータ定義言語（ＤＤＬ）は、ネッ
トワークの全ての適用業務プログラムで用いられる論理
構造及びデータタイプを定義するために、本発明に従っ
て使用される高レベルの言語である。さらに具体的に
は、ＤＤＬは、図５に関連してさらに詳細に下記するよ
うに、データ定義構成ファイル（Ｄｄｅｆ）において、
宣言を有するデータタイプの定義を行なうために使用さ
れる。Ｃ、ＦＯＲＴＲＡＮ、及び、ＰＡＳＣＡＬのよう
な伝統的な言語は、それらが、実行されるマシンアーキ
テクチャに直接結合される。これは、異なる言語が同じ
論理データタイプであっても、データタイプの物理的表
現が異なる場合があるためである。例えば、ＣとＦＯＲ
ＴＲＡＮは、両方とも、多次元配列形式を有している
が、このデータタイプを記憶するため、Ｃは、行優先順
を使用し、一方、ＦＯＲＴＲＡＮは、列優先順を使用す
る。ＤＤＬは、システムインテグレータが、適用業務プ
ログラムで使用されるデータの論理レイアウトを記述す
る、既定の完全なデータタイプのセットを提供する。ほ
とんどの言語における基本的なデータタイプに加え、Ｄ
ＤＬには、本発明に従って「不透明」と呼ばれる追加の
データタイプを含むことができるが、「不透明」とは、
「形式のない」データの記述に使用されるカスタムのデ
ータタイプである。

【００３９】ＤＤＬのデータは、Ｃにおける型定義また
はＰＡＳＣＡＬにおける型宣言と大体同様のやり方で定
義される。本発明によるＤＤＬ宣言は、Ｃ及びＰＡＳＣ
ＡＬといった標準言語のデータ宣言セクションと同様で
あり、従って、当業者の有する技術レベルの範囲に十分
納まるものと信ずる。例えば、本発明のＤＤＬは、全て
の手続のデータタイプについての情報を含むことが望ま
しく、先行技術とは違って、本発明のＤＤＬは、さらに
詳細に後述されるＤＭＬに従って、１つのデータタイプ
から他のデータタイプへの変換を可能にする。さらに、
従来の言語とは異なり、本発明によるＤＤＬ定義は、特
定の言語またはマシンの表現をデータ定義に結びつけな
い。むしろ、データ定義とマシンは後述するように、リ
ンク定義によってリンクされている。このように、本発
明によるＤＤＬは、主としてデータの論理レイアウトに
関するものであり、従って、結合すべきネットワークの
言語を支援するのに適したＤＤＬは、当業者の有する技
術範囲に十分納まるものと信ずる。

【００４０】ここで用いられるデータ操作言語（ＤＭ
Ｌ）は、データの操作に用いられる高レベル言語であ
る。データタイプがＤＤＬで定義されると（Ｄｄｅｆに
おいて）、そのデータについて実施しなければならない
操作は、図５に関連して後述するように、ＤＭＬを利用
して、データ操作定義構成ファイル（Ｄｍａｎ）に定義
される。データ操作宣言は、割当てステートメントかま
たは、移動ステートメントのどちらかとすることができ
る。割当てステートメントは、送信先の構造に対してデ
フォルト値を設定し、一方、移動ステートメントは、送
信元のデータ構造を送信先のデータ構造に移行し、言語
及びマシンアーキテクチャにおける差を補正し、必要が
あれば、タイプ変換を行なう。これらのタイプ変換は、
ブール、整数、浮動小数点、及び、ＡＳＣＩＩフィール
ドで実行することができる。

【００４１】セットアップ手順 図５〜図７には、システムを始動させ、図４に関連して
上述したＤＭＭランタイムモジュールをセットアップす
るための手順が示されている。ただし、これらの図につ
いて説明する前に、システムインテグレータまたはエン
ドユーザが、本発明のシステムに従って実施することに
なる統合解析のタスクにおける基本ステップについて解
説する。プロセス時に、システムインテグレータは、規
定の機能要件を満たすために必要なプロセスの数と一般
的な機能を決めることによって、本発明の統合システム
の高レベルの設計を完成する。この情報は、システムの
構成とそれに対する適用業務アダプタの開発の両方に必
要である。

【００４２】基本的に、本発明のシステムの構成は、転
送されるデータと動作環境を記述する１組の構成ファイ
ルを、テキストエディタで生成することから成る。構成
ファイルは、データの構造化の方法、データのアクセス
方法、データの操作方法、及び、データの表示方法とい
ったデータに関する情報を提供する。構成ファイルは、
ネットワークにおけるコンピュータ、コンピュータのリ
ンク、及びプロセスのタイプを定義することによって、
動作環境を記述する。構成ファイルは、下記ステップに
従って、システムインテグレータまたはエンドユーザに
よって作成される。

【００４３】１．機能要件解析 機能要件解析は、本発明による統合を実施すべき環境を
明確に規定して、システムインテグレータが、統合すべ
きシステムの高レベルの設計を行なえるようにすること
を意味している。すなわち、ユーザが、統合によって何
を実現できるかを決定し、こうした統合の要件をプログ
ラムインタフェースの開発段階で指定できるようにす
る。例えば、ユーザは、作業順序のトラッキング及びス
ケジューリングといった、製造システムの一部を管理す
るいくつかの適用業務が、お互いに通信し、データの交
換を行なえることを望む。ユーザは、資源、すなわち、
特定の機能またはプロセスを実行する適用業務、適用業
務が常駐するマシンノード（すなわち、論理ノード名、
マシンタイプ、物理ノード名、その他）、及び、ネット
ワーク特性を知る必要がある。こうしたネットワーク情
報は、ネットワーク定義（Ｎｅｔｗ）構成ファイルに記
憶される。

【００４４】２．データの流れと適用業務の解析 ユーザは、また、データのタイプ、及び、統合される適
用業務間におけるデータの移動を解析しなければならな
い。ユーザは、また、データの流れを制御するために必
要な同期を確認し、あるいは、データが整合のとれたま
まであること保証する必要がある。データが、同じシス
テム上の異なる適用業務間で流れようと、異なるシステ
ム上の適用業務間で流れようと、ユーザは、適用業務間
で移動するデータの仕様もまた、知らなければならな
い。例えば、ユーザは、送信されるメッセージ及び送信
元の適用業務の構造、及び、送信先の適用業務が受け入
れるフォーマットが何かを知らなければならない。ユー
ザは、また、送信元のメッセージを作成するために使用
されるプログラミング言語、及び、送信先の適用業務に
おいて、そのメッセージを読みとるために使用される言
語が何かを知らなければならない。メッセージデータを
受信側の適用業務が受け入れ可能なフォーマットに変換
するために、操作が必要な場合には、ユーザは、ＤＤＬ
で書かれたデータ定義ファイル（Ｄｄｅｆ）及びＤＭＬ
で書かれたデータ操作ファイル（Ｄｍａｎ）を作成す
る。Ｄｄｅｆファイルは、適用業務間で送られるメッセ
ージのフォーマット、具体的には、１つの適用業務の出
力ともう１つの適用業務の入力を構成する整数、ストリ
ング、配列、構造、レコード、及び、バイトを定義す
る。一方、Ｄｍａｎは、上述した各データ操作の定義を
含んでいる。各データ操作は、送信先の適用業務が受け
入れ可能なフォーマットとタイプを送信元のデータ構造
が備えるようにするために、そのデータ構造に実施しな
ければならない操作を規定する。

【００４５】３．プロセス設計 ユーザは、データの流れによって必要とされるタスクま
たはプロセスを決定することによって、本発明の統合シ
ステムを設計する。ユーザは、また、これらのタスクを
適用業務アダプタにグループ化する方法を決め、この情
報をプロセス定義構成ファイル（Ｐｒｏｃ）に記憶す
る。Ｐｒｏｃファイルの情報には、データ、デフォルト
のランストリング、及び、種々の実行情報を送受信する
プロセスが記載されている。特定のプロセス定義エント
リを参照するため、アクセスルーチンによってプロセス
論理名が利用される。

【００４６】４．データフォーマットの決定 ユーザは、また、交換されるデータが、ファイルフォー
マットとメッセージフォーマットのいずれであるかを決
定する。ファイルフォーマットの場合には、ユーザは、
使用するファイルコピーオプションを決定する。この情
報は、ファイル定義ファイル（Ｆｄｅｆ）に記憶しなけ
ればならない。メッセージフォーマットの場合には、ど
んな操作等が必要かを決めなければならない。

【００４７】５．リンクの設定 最後に、ユーザは、データ定義及びデータ操作をノード
のリストに結合させるためにリンクを定義するが、その
ノードで、送信元のデータが作成されて、送信元と送信
先のデータの言語が転送される。この情報は、リンク定
義構成ファイル（Ｌｉｎｋ）に記憶される。Ｌｉｎｋフ
ァイルには、メッセージの送信元の適用業務と送信先の
適用業務でのデータの物理特性が記載されており、特定
のデータまたは操作定義を特定のリンクに結びつける。
リンク定義は、データ定義及び操作を送信元の位置及び
アーキテクチャのタイプ、送信元及び送信先の言語、及
びファイル定義に結びつける。

【００４８】このように、本発明に従う構成とは、適用
業務、ネットワークのノード、プロセス、ファイル、リ
ンク、及び本発明の統合装置に対する操作を記述するこ
とを意味している。これは、情報を集めるプロセスであ
る。本発明の望ましい実施例において、６つの構成ファ
イル502（図５）は、本発明によって統合されるシステ
ムをモデル化するために、テキストエディタによって生
成される。

【００４９】これらの構成ファイルが生成され、妥当性
が確められると、本発明のシステムの始動準備が整うこ
とになる。詳しくは、図４に示す本発明のランタイムシ
ステムは、ネットワークの各ノード上で確立されて、ネ
ットワーク内の各ノードでのプロセスが、構成ファイル
の指定に従って互いに通信できるようにしなければなら
ない。すなわち、図４に示す本発明のＤＭＭモジュール
を、ノードに固有のものとし、統合領域の全てのノード
に導入しなければならないし、構成テーブル408をメモ
リにロードしなければならない。しかし、これを行なう
前に、システムインテグレータは、始動、停止、及びセ
キュリティのような機能を提供する管理ノードを指定
し、主管理ノードが故障の場合、所定の数の代替管理ノ
ードも設定することが望ましい。後述するように、次に
システムマネージャ422を使用して、システムのセキュ
リティが構成され、始動が行われる。次に、ユーザは、
さまざまなプロセスに対する適用業務アダプタを書い
て、コンパイルする。ただし、適用業務アダプタは、構
成情報を必要とするので、構成及び適用業務アダプタの
開発は、連係して、あるいは、任意の順序で行なわれ
る。一方、ユーザは、コマンドプロセッサを利用して、
テスト目的で他のアダプタをシミュレートすることがで
きるので、ユーザは、最終ステップとしてアダプタの開
発を実施するのが望ましい。これで、ユーザは、図５に
示すように、本発明のシステムの実行を開始して、ＤＭ
Ｍモジュールを生成する準備が整ったことなる。

【００５０】図５に示すように、構成ファイル502が、
管理ノードにロードされる。妥当性確認プログラム504
は、構成ファイル502からネットワーク定義（Ｎｅｔ
ｗ）にプロセス定義（Ｐｒｏｃ）、リンク定義（Ｌｉｎ
ｋ）、及び、ファイル定義（Ｆｄｅｆ）を読み込む。構
成ファイル502は、妥当性確認プログラム504に識別され
たディレクトリに常駐しなければならない。妥当性確認
プログラム504は、構性ファイルの完全性をチェック
し、それらを、始動時に必要な２進データファイル510
に変換する。次に、妥当性確認プログラムは、ＤＤＬコ
ンパイラ506を呼び出して、データ定義（Ｄｄｅｆ）を
読み取り、メモリ内にＤＤＬシンボルテーブルを作成す
る。次に、ＤＭＬコンパイラ508が妥当性確認プログラ
ム504によって呼び出されて、Ｄｍａｎのデータ操作定
義を読み取り、操作Ｃソースファイル512を生成する
が、このソースファイルは、データ操作を行い、送信元
のデータを共通データ表現に変換するＣ言語命令を含
む。次に、ＤＭＬコンパイラ508は、ＤＭＬコンパイラ5
08に関するデータ定義情報、妥当性確認プログラム504
からのリンク定義、及びＤｍａｎからの操作定義を使用
して、ルックアップテーブルＣソースファイル530、操
作Ｃソースファイル512、及び、Ｃソースインデックス
ファイル514を生成する。Ｃソースインデックスファイ
ルは、領域内のさまざまなノードについて生成されたす
べてのＣソースファイルのリストを含む。異なるソース
ファイルのインデックスが、各マシンタイプ毎に生成さ
れる。

【００５１】従って、妥当性を確認された構成ファイル
510、操作Ｃソースファイル512、及び、Ｃソースインデ
ックスファイル514、及び、ルックアップテーブルＣソ
ースファイル530は、メモリにロードすることができる
が、むしろ、ＤＭＭ412を構築するために利用すること
ができるという意味では、構成情報を表わしている。こ
れらのファイルは、始動プロセス516の間、管理ノード
によって利用されて、統合領域の全てのノードに配信さ
れる構成テーブルを生成する。Ｃソースインデックスフ
ァイル514、ルックアップテーブルＣソースファイル53
0、及び操作Ｃソースファイル512は、ノードに固有なデ
ータ操作モジュールの形成に使用される。

【００５２】詳しくは、ＤＤＬＯＡＤプログラム518を
呼び出して、構成テーブルをメモリにロードすることに
よって、管理ノードにおける始動が開始する。構成テー
ブルには、(1)統合領域内のノードのリスト、及び(2)コ
ンパイルノードのリストが含まれているが、ここで、コ
ンパイルノードは、統合システムがノードに固有のＤＭ
Ｍを生成するために、そのコンピュータアーキテクチャ
のファミリーに属する全てのノードについて、ルックア
ップテーブルＣソースファイル530、及び、操作Ｃソー
スファイル512をコンパイルするノードとして定義され
る。統合領域内のコンピュータアーキテクチャの各タイ
プ毎に、コンパイルノードとして定義されているノード
が少なくとも１つは存在しなければならない。すなわ
ち、異種のコンピータネットワーク環境内のコンピュー
タアーキテクチャの各タイプ毎に、コンパイルノードが
設けられる。もちろん、同種のコンピュータネットワー
ク環境の場合、コンパイルノードは、１つしか必要とさ
れない。

【００５３】始動時に、構成テーブルが管理ノードにロ
ードされると、始動プロセス516は、始動させるべきノ
ードを指示し、システムマネージャに対し、各コンパイ
ルノードにあるＤＭＭビルダ520のスケジュール作成を
行なうように要求する。 上述したように、システム内
の各マシンタイプ毎にコンパイルノードが存在しなけれ
ばならない。もし、特定のマシンタイプに対するコンパ
イルノードが見つからなければ、エラーメッセージが出
され、そのマシンタイプの全てのノードについて始動が
停止される。

【００５４】各コンパイルノードにおいて、引き続き行
われる始動動作は、ＤＭＭビルダ520によって管理され
る。ＤＭＭビルダ520は、関連するＣソースファイル
（ルックアップ及び操作）及び、コンパイルノードに新
しいＤＭＭを必要とするネットワーク内のノードのリス
トと共に、その特定のマシンタイプに対するＣソースイ
ンデックスファイルを引き出し（コピーし）、そのＣソ
ースファイルをオブジェクトモジュールにコンパイルす
る。結果として、ＤＭＭモジュール528がコンパイルノ
ードで得られるが、それは、図４に示すように、実行時
にそのノードで使用されるＤＭＭ412に対応する。Ｃコ
ンパイラ524は、操作Ｃソースファイル512を、そのマシ
ンまたはアーキテクチャタイプに固有のオブジェクトフ
ァイルのカストマイズされたライブラリ526コンパイル
する。コンパイラ524は、ルックアップテーブルＣソー
スファイル530をノードに固有のオブジェクトファイル
にコンパイルする。

【００５５】次に、コンパイルノードは、ノード固有の
ＤＭＭモジュールを必要とするネットワーク上のマシン
タイプを持つ各ノードに対して、そのＤＭＭモジュール
528を配信する。図６には、コ ンパイルノードがそのよ
うな全てのノードに対して、ＤＭＭモジュールを配分す
る方法が示されている。図示のように、妥当性を確認さ
れた構成ファイル510、ルックアップＣソースファイル5
30、操作Ｃソースファイル512、及び、Ｃソースインデ
ックスファイル514が、たった今説明したように、マシ
ンアーキテクチャに固有のＤＭＭモジュール528を形成
するために、コンパイルノードによって引き出される
（コピーされる）。次に、このＤＭＭモジュール528
は、ＤＭＭを必要とする、ネットワーク上のアーキテク
チャタイプを持つ他の全てのノード（ノード３〜６）に
配分され、これらのノードが、今度は、ＤＭＭを受信し
たことをコンパイルノードに知らせる。コンパイルノー
ドは、このステータスを始動ノードに送る。

【００５６】要するに、該プロセスは、始動ノードから
開始して、各ノードについて、以下のアクティビティを
実行する。即ち、妥当性が確認されたファイルをそのノ
ードにコピーし、構成テーブルをメモリにロードし、始
動のためのランタイムプログラムを準備し、ユーザの決
定に従ってランタイムプログラムを始動／停止させ、１
組の構成ファイルを全ての代替管理ノードにコピーし、
操作Ｃソースファイル512、ルックアップＣソースファ
イル530、及び、Ｃソースインデックスファイル514を全
ての代替管理ノードにコピーする。

【００５７】図７は、本発明の統合システムをセットア
ップし、始動させる手順の要約である。図示のように、
ユーザは、まず、ステップ702において統合を構成し、
統合の妥当性を確認し、それから、ステップ704におい
て、適用業務プログラムを統合システムにインタフェー
スするために、適用業務アダプタプログラムを生成し、
あるいは、修正する必要があるか否かを判定する。も
し、必要があれば、適用業務アダプタプログラムが、ス
テップ706において生成または修正され、次に、ステッ
プ708でコンパイルされて、始動時にシステムにリンク
される（ステップ710）。ユーザは、次に、ステップ712
において、コマンドプロセッサを用いて構成のテストを
行なうことができ、構成に問題がなければ、全てのノー
ドを始動させることができる。一方、始動に問題があれ
ば、ステップ714において、構成を変更する必要がある
か否かが判定される。もし、変更の必要がなければ、適
用業務アダプタプログラムは、ステップ716で修正さ
れ、次に、修正されたアダプタプログラムが、ステップ
708でコンパイルされ、ステップ710での始動に備えて、
もう１度システムにリンクされる。しかし、テスト後、
構成に変更を加える必要がある場合には、制御はステッ
プ714からステ ップ718へ分岐し、そこで、構成テーブ
ル408の再構成及び妥当性の確認を可能にするためにシ
ステムを停止する。このように、現在のところ望ましい
実施例においては、ノードの始動時に構成データがリン
クされるので、再構成のためにシステムを停止する。た
だし、当業者には明らかなように、システムを停止させ
ることなく、実行時に構成を変更し、妥当性を確認する
ことができるが、現行システムを停止しない限り、実行
システムに切り替えることはできない。統合システム
が、実行状態になると、制御は、日常の管理タスクのた
めに、システム管理装置に渡される。

【００５８】ＤＭＭ実行時動作 図５に関連して説明したように、本発明のデータマニプ
レータは、データ宣言を処理し、データマニプレータの
他のソフトウェアモジュールによって使用されるシンボ
ルテーブルを生成するＤＤＬコンパイラから構成される
のが望ましい。ＤＭＬコンパイラは、また、ユーザによ
って定義されたデータ操作ステートメントを処理し、共
通データ表現ライブラリにあるデータコード化機能（Ａ
ＳＮ．１基本コード化ルールのような）とデータ操作ラ
イブラリにある、データ変換及び操作機能と共にコンパ
イルされるＣソースコードモジュールを生成するために
提供される。コンパイル後に生成されるオブジェクトコ
ードモジュールは、データ操作シェルと呼ばれるモジュ
ールによって実行時に実行されるが、このモジュール
は、特定のメッセージに対してどんなタイプの操作が必
要かを判定し、ＤＭＬコンパイラによって生成される適
切な操作モジュールを呼び出して、異なるアーキテクチ
ャのコンピュータに対して送信するために、データを共
通のデータ表現による表記に変換する。最後に、本発明
の望ましい実施例のデータマニプレータは、入力ネット
ワークマネージャ318によって呼び出され、共通データ
表現フォーマットによるメッセージをデコードして、リ
モートのホストデータ及び言語表現にする「アンマーシ
ャラー（unmarshaller）」モジュールを含む。

【００５９】データ操作モジュールの動作時、データ操
作シェルは、それの入力メールボックスから（リクエス
トマネージャ306から）メッセージを読み取り、適切な
データ操作を呼び出して、ユーザの適用業務プログラム
の要求に応じてデータを変換する（すなわち、送信先の
フォーマットに整合させる）。メッセージの操作後、デ
ータ操作シェルは、配送のため、データを出力ネットワ
ークマネージャ316に送る。受信ノードにおいて、入力
ネットワークマネージャ318は、ネットワークからメッ
セージを取得して、アンマーシャリングタスクが必要か
否かを判定する。 もし、必要であれば、入力ネットワ
ークマネージャ318は、アンマーシャラーモジュールを
呼び出す。メッセージ内容から、アンマーシャラーモジ
ュールは、どの機能が必要かを判定し、アンマーシャリ
ングを実施するためにこれらの機能を呼び出す。

【００６０】上述のように、データ操作モジュールの目
的は、異なるマシンアーキテクチャに常駐し、異なる言
語で書かれた２つの適用業務の間で、ユーザがデータ転
送を行なえるようにすることである。これが試みられた
場合に生じる問題は、送信及び受信のマシンアーキテク
チャ／言語は、特定の表現または特定のデータサイズに
よる、または、アライメントのとれたデータを放出する
か、あるいは、これを期待するということである。例え
ば、ストリング表現、ブール表現、行／列優先アドレス
指定、データサイズ等は、言語に固有のものであり、一
方、バイト配列、２の補数表示、浮動小数点（実）表
現、文字セット、データサイズ等は、マシンアーキテク
チャに固有のものと考えられる。こうしたマシンアーキ
テクチャ及び言語における相違は、出力するデータにあ
る種のデータ操作を施して、受信側の適用業務が受け入
れることができるようにしなければならないということ
を意味している。このデータ操作を支援するために、変
換ルーチンが必要であり、こうした変換ルーチンは、図
５及び図６に関して上述したように、本発明のデータ操
作モジュールに含まれている。

【００６１】本発明は、共通データ表現（ＣＤＲ）を使
用するが、その中で必要とされる変換ルーチンが、ロー
カルのマシン及び言語フォーマットからマシン及び言語
に無関係なデータフォーマットに、また、その逆に変換
するために記述されている。従って、データの送信側
が、データをＣＤＲフォーマットに変換して、データを
送り出す。受信側のシステムは、ルーチンを呼び出し
て、ＣＤＲによるフォーマットのデータを受信側のシス
テムのローカルのデータフォーマットに変換する。従っ
て、各マシンアーキテクチャは、そのローカルのマシン
フォーマットからＣＤＲフォーマットに変換する方法に
ついて知っているだけでよい。さらに、ネットワークに
加えられる新しいマシンアーキテクチャは、そのデータ
変換について同じことを知っていさえすればよい。

【００６２】本発明に従えば、当業者は、ネットワーク
で支援されるべき全てのデータタイプを取り扱う、自分
自身の共通データ表現を設計することができる。ただ
し、本発明の現時点で望ましい実施例では、ＯＳＩ Ａ
ＳＮ．１基本コード化ルール（ＢＥＲ）と称する既存
の、標準的なＣＤＲコード化ルールを利用する。特に、
本発明の望ましい実施例では、前述のデータ定義及びデ
ータ操作言語で記述されるデータにＣＤＲによるコード
化を施すために、ＡＳＮ．１で指定されているバイトレ
ベル「転送構文」フォーマットを利用する。

【００６３】従って、本発明の望ましい実施例によれ
ば、マシン間で転送されるデータ要素は、ＡＳＮ．１
ＢＥＲによってコード化されるものである。ここでの問
題は、ＡＳＮ．１でコード化されたデータ要素が目標シ
ステムに到達すると、そのデータ要素は、いくつかの言
語に固有のデータタイプのうちの１つにアンマーシャリ
ングルされる可能性があるということである。従って、
ＡＳＮ．１コード化ユーザデータ要素が目標システム上
でアンマーシャリングされる言語に固有のデータタイプ
を識別するために、「タイプ属性ＩＤ」が、メッセージ
のＡＳＮ．１コード化ユーザデータ要素に付随していな
ければならない。これらのタイプ属性ＩＤもＡＳＮ．１
コード化によるものである。ＤＤＬタイプとＡＳＮ．１
データタイプ間で、マッピングが必要である。表１は、
現在のところ望ましいＤＤＬデータタイプ対ＡＳＮ．１
コード化データタイプの表である。

【００６４】

【表１】

【００６５】*アンマーシャリングモジュールは、マー
シャリング(marshalling)を行なうコードが、多次元配
列の要素を目標言語に対して行／列優先順で配置するこ
とを想定している。すなわち、アンマーシャラーは、Ａ
ＳＮ．１配列の要素が目標言語に対して適正な行／列優
先順であることを想定している。それは、配列要素の再
配置は行なわない。

【００６６】タイプ属性ＩＤ名の後の括弧（ ）内の数
は、コードで使用されるタイプ属性ＩＤの数値を示して
いる。

【００６７】表１に示すように、タイプ属性ＩＤは、Ａ
ＳＮ．１タイプの目標ＤＤＬタイプを識別する名称であ
る。識別名称の後の数は、ソースコードにおいてそのＩ
Ｄを表わすために使用される。タイプ属性ＩＤに加え
て、タイプ属性には、受信ノードによる、ターゲットの
ＤＤＬタイプへの正確なアンマーシャリングを可能にす
るために、ＡＳＮ．１データタイプと共に転送される特
別な情報もまた含まれている。ＡＳＮ．１データタイプ
フォーマットは、こうした情報のための領域を持たな
い。例えば、ＡＳＮ．１ストリングタイプのデータ要素
は、ストリング値の現在のサイズを示すフィールドを備
えているが、ストリング値が取りうる最大のサイズがい
くらかを示すフィールドは備えていない。この最大サイ
ズ情報は、タイプ属性情報である。タイプ属性ＩＤとタ
イプ属性は、両方とも、実際のＡＳＮ．１コード化ユー
ザデータ以外に必要とされる特別な情報であるため、本
書では両方とも、「タイプ属性」と称して、概念上ひと
まとめにして扱っている。

【００６８】データの「マーシャリング」には、上述し
たように、リモートのフォーマットによるデータをマシ
ン及び言語に無関係なＣＤＲフォーマットに変換するこ
とが含まれる。従って、こうしたマーシャリングされた
データは、ネットワーク内の自身のシステムまたは別の
システムに常駐する「アンマーシャリング」モジュール
に送ることが可能である。アンマーシャリングモジュー
ルは、次に、そのデータをマシン及び言語に依存したリ
モートのフォーマットに変換する。本発明によれば、マ
ーシャリングされたメッセージは２つの主要な部分、す
なわち、静的なフォーマットメッセージヘッダー、及び
動的なフォーマット適用業務データ部分に分割される。
これらの部分は、その部分が、既定の静的なフォーマッ
トデータを含んでいるか、あるいは、任意のタイプのフ
ォーマットを有することが可能な適用業務に密接に関連
したデータを含んでいるかに基づいて分割される。メッ
セージヘッダーには、送信元／送信先のノード手段、動
作フラグ、ターゲットのプロセス論理名等のような、メ
ッセージの転送に必要な管理情報が含まれている。それ
には、また、ファイルを送り、プロセスを始動／停止さ
せ、ステータスをマシン適用業務サーバに戻すといった
ような特定の機能の実施に必要な情報も含まれている。
一方、動的なフォーマット部分は、転送される適用業務
データに従って変化する。

【００６９】メッセージの動的部分には、重要なサブフ
ィールドが含まれている。これらは下記に示す通りであ
る。

【００７０】

【表２】

【００７１】データバッファヘッダーには、アンマーシ
ャリングプロセス を初期化するために必要な情報が含
まれており、一方、ユーザデータは、受信側の適用業務
が期待するＡＳＮ．１コード化の「純粋な」データであ
る。他方、タイプ属性は、ユーザデータのアンマーシャ
リングを助けるのに必要な、特別な非ＡＳＮ．１情報で
ある。例えば、このタイプ属性データは、ユーザデータ
をリモートのデータフォーマットタイプに変換できるよ
うにするノードに固有の情報である。マーシャリング時
には、ユーザデータを１つのバッファに保持し、タイプ
属性データを他のデータバッファに納めて、所定のプリ
ミティブについてのタイプ属性データを、関連するユー
ザデータに付加する（コピーする）ことを容易にするこ
とが望ましい。一方、データバッファヘッダーには、ど
れだけオフセットして、タイプ属性が始まるか、また、
その全長はどれだけになるかといった情報を含めること
ができる。ユーザデータは、既述のＤＤＬタイプ／ＡＳ
Ｎ．１タイプの表及びＡＳＮ．１基本コード化ルール
（ＢＥＲ）に従って、ＡＳＮ．１データ要素にマーシャ
リングされる。

【００７２】データ操作モジュールは、マーシャリング
ルーチンライブラ リ（ＭＲＬ）と呼ばれるライブラリ
を構築することによって、本発明に従ってデータをマー
シャリングする。各ＭＲＬは、特定のマシンアーキテク
チャに対してカストマイズされる。従って、支援される
各マシンアーキテクチャタイプ毎に１つのＭＲＬのバー
ジョンが存在する。望ましい実施例の場合、ＭＲＬは、
特定のコンピュータアーキテクチャについて統合システ
ムが支援する、ＣコンパイラでコンパイルされるＣ言語
コードによって呼び出されることを想定している。ま
た、ＭＲＬは、ランタイム共有ライブラリをなすように
は設計されておらず、代りに、ライブラリコードは、上
述したように、リンク時にＤＭＭのコードにリンクされ
る。

【００７３】ＤＭＬコンパイラ508によって出力される
コードは、以下のマーシャリングステップを実行する。
即ち、 １．ヘッダをマーシャリングすることによってマーシャ
リングプロセスを開始し、 ２．送信元のデータ要素を送信先のプログラムのバッフ
ァで生じる順をなすようにマーシャリングし、そして、 ３．全てのデータ要素のマーシャリングを終了すると、
トレーラ（もし存在すれば）のマーシャリングを行な
う。

【００７４】利用しやすくするため、マーシャリングル
ーチンは、２つの バッファ、すなわち、送信元のロー
カライズされたデータ要素を保持するための、送信元の
バッファと、もう一つのバッファである、マーシャリン
グされたデータ要素を保持するためのターゲットのバッ
ファを備えることが望ましい。

【００７５】次に、本発明の「アンマーシャリング」ル
ーチンについて 説明する。アンマーシャリングは、マ
シンと無関係なＣＤＲフォーマットによるデータを、何
らかのターゲットマシン及び言語フォーマットに変換す
るプロセスである。アンマーシャリングルーチンで使用
される情報のタイプには、２つのタイプがある。第１の
タイプは、符号付き／符号なし、パックされている／パ
ックされていないといったようなデータを利用して変更
できる情報である。この情報は、タイプ属性としてＣＤ
Ｒデータストリームのデータと共に送られる。もう１つ
のタイプの情報は、データアライメント及びバイト／ワ
ードのサイズのような安定した情報である。この情報
は、もちろん、静的なテーブルに組み込むことができ
る。

【００７６】各ＣＤＲデータ要素が読み取られる時、そ
れは、アンマーシャリングルーチンライブラリ（ＵＲ
Ｌ）と呼ばれるライブラリに組み込まれるアンマーシャ
リングルーチンを用いてアンマーシャリングされる。Ｍ
ＲＬと同様、各ＵＲＬは、特定のマシンアーキテクチャ
用にカストマイズされる。従って、支援されるマシンア
ーキテクチャタイプ毎に１つのＵＲＬのバージョンが存
在する。このカストマイズのほとんどは、ライブラリ構
築時の値の変化によって処理される。ＭＲＬと同様、Ｕ
ＲＬは、ランタイム共有ライブラリをなすようには設計
されない。代りに、ライブラリコードは、リンク時に、
ＩＮＭのコードにリンクされる。

【００７７】選択された低レべルのルーチンを呼び出し
て、対応するデータ要素をアンマーシャリングする。ど
の低レベルルーチンを呼び出すべきかの判定は、ＣＤＲ
データストリームにどんなタイプのＣＤＲデータが存在
しているかに基づいて行なわれる。従って、これら低レ
ベルルーチンの上位に、ＣＤＲストリームの中の次のデ
ータ要素を調べ、その要素のタイプ属性ＩＤを利用し
て、呼び出すべき低レベルのアンマーシャリングルーチ
ンを選択するメインルーチンを構築しなければならな
い。こうしたルーチンは簡単であり、当業者であれば容
易に設計することができる。

【００７８】データタイプのサイズとアライメントに関
する言語に固有の情報、及び、送信先のノードでＤＤＬ
タイプを呼び出す変換ルーチンへのポインタは、言語テ
ーブルと呼ばれる２×２のマトリックスに編成される。
マシンタイプ毎の言語毎に１つの言語テーブルがある。
好ましくは、行はＤＤＬタイプであり、一方、列は関連
するローカライズされたデータ要素のサイズ、アライメ
ントそして、呼び出すべき特定のＤＤＬアンマーシャリ
ングルーチンに対するポインタである。

【００７９】

【表３】

【００８０】データ受信時にどの言語テーブルを選択す
べきかを判定するために、ＣＤＲのヘッダーを、ターゲ
ットの言語が何かを選択する情報のバイトについて調べ
る。このバイトを使ってグローバルポインタをセット
し、そのメッセージをアンマーシャリングするために使
用される言語テーブルを指示する。このバイト値からグ
ローバルポインタへの移行は、言語テーブルへのポイン
タの表４によって行うことができる。

【００８１】

【表４】

【００８２】言語テーブルポインタテーブル（ｌｔｐ＿
ｔａｂｌｅ）が、アンマーシャリングコードの開始時に
セットアップされる。メッセージのアンマーシャリング
開始時に、ターゲット言語のバイト値は、言語テーブル
へのポインタを検索するｌｔｐ＿ｔａｂｌｅのインデッ
クスとして使用される。グローバルポインタは、この言
語テーブルを指示するようにセットされ、この言語テー
ブルは、アンマーシャリングコードによって、メッセー
ジの残りの部分を変換するために使用される。

【００８３】選択された言語テーブルを指示するグロー
バルポインタを設けることは、十分に容易である。しか
しながら、Ｐａｓｃａｌ及びパックされたデータタイプ
では、問題が生じる。すなわち、Ｐａｓｃａｌのターゲ
ット言語をもつシステムに到着するメッセージのＣＤＲ
には、パックされたデータ要素とパックされていないデ
ータ要素が混合している場合がある。パックされたデー
タタイプ対アンパックされたデータタイプのそれぞれ
が、Ｐａｓｃａｌ言語テーブルにおいてそれ自身のサイ
ズとアライメント情報を必要とする。従って、Ｐａｓｃ
ａｌ言語テーブルは、他の言語テーブルの２倍の量の情
報を納めなければならない。このため、Ｐａｓｃａｌ言
語テーブルの列索引は、データ要素のパックされたサイ
ズ／アライメントに関する特別な情報にアクセスするた
めに、別個になっていなければならないので、パックさ
れたデータ要素を操作するためには、特別なチェックも
また必要になる。パックされたＰａｓｃａｌのデータタ
イプに対する特別な操作及びチェックの量は最小限にと
どめることが望ましいので、パックされたＰａｓｃａｌ
のデータタイプは、別の言語テーブルにあるかのように
扱うことも可能である。さらに、Ｐａｓｃａｌ言語テー
ブルのパックされたバージョン間またはアンパックされ
たバージョン間で動的にアクセスする半透過メカニズム
を設けることによって、コードの実行を、より円滑に、
かつ、より高速にすることができる。また、パックされ
たＰａｓｃａｌ言語テーブルが特別に存在することによ
って、他の言語の言語テーブルをアクセスする方法に影
響があってはならない。提案するｌｔｐ＿ｔａｂｌｅ
は、表５のようである。

【００８４】

【表５】

【００８５】送信元のバッファのヘッダーからのバイト
は、表５に示すようにｌｔｐ＿ｔａｂｌｅのインデック
スとして使用される。このインデックスは、グローバル
変数の形で保管されており、従って、このインデックス
によって、どのターゲット言語がアンマーシャリングさ
れることになるかが分かる。また、インデックスが選択
する項目には、２つのポインタ、すなわち、パックされ
た言語テーブルのバージョンに対するポインタと、アン
パックされた言語テーブルのバージョンに対するもう１
つのポインタが含まれる。これがあてはまるのは、ｌｔ
ｐ＿ｔａｂｌｅのＰａｓｃａｌの項目だけであり、他の
言語は、パックされたポインタに対してＮＵＬＬポイン
タを備えている。

【００８６】アンマーシャリングプロセスが、パックさ
れた配列／レコードのタイプ属性ＩＤを見つけると（Ｐ
ａｓｃａｌはターゲット言語でなければならない）、こ
のタイプ属性は、ただちにスタックフレームに納められ
る。スタックフレームの残りのフィールドは、従って、
タイプ属性ＩＤを伴う情報で初期設定される。アンマー
シャリングプロセスは、入力バッファの次のデータ要素
を調べて、パージングを続ける。

【００８７】一方、データ要素のサイズ、アライメン
ト、及び呼び出すべき変換ルーチンへのポインタもまた
決定しなければならない。というのは、ｌｔｐ＿ｔａｂ
ｌｅに対するインデックスは利用できるが、その行にお
いてどのポインタ（列）を使用すべきかということが問
題になるためである。この決定は、前出のスタックフレ
ームがパックされているかどうかに依存する。対応する
値が、ｌｔｐ＿ｔａｂｌｅの選択された行におけるのイ
ンデックスとして使用される。特定の行において、パラ
メータ、及び呼び出すべきルーチンへのポインタを取得
するために、タイプ属性ＩＤが言語テーブルのインデッ
クスとして使用される。

【００８８】上述したように、送信されるメッセージの
ユーザデータは、ＡＳＮ．１ＢＥＲを使ってコード化さ
れる。これは、受信側が、このデータをターゲット言語
のデータタイプにアンマーシャリングするのには十分で
はない、というのは、タイプ属性及びデータのヘッダー
は、記述の際の手助けとして必要であるが、それらもま
たマーシャリングされるからである。すなわち、メッセ
ージの全ての部分が、ＡＳＮ．１基本コード化ルールに
従うので、他の部分はデータバッファヘッダー、及びタ
イプ属性の助けをかりずにデコードしなければならな
い。これは、データバッファのヘッダーフィールドがデ
ータバッファのヘッダーに対して特定の順序で配置され
ているものと期待して、取り扱われる。従って、データ
フィールドを適正に配置することによって、ＡＳＮ．１
アンマーシャリングルーチンを呼び出し、バージョン及
びターゲット言語のデータを含むデータをアンマーシャ
リングすることができる。しかしながら、タイプ属性フ
ィールドの配置順は、予測することができない。従っ
て、タイプ属性は、必要に応じて、実行時にオンザフラ
イでアンマーシャリングされる場合がある。同種のデー
タは、本発明に従ってマーシャリングされないので、Ｉ
ＮＭ418は、受信したメッセージがＣＤＲに変換されて
いるか否かを判定するためのなんらかのメカニズムを備
えていなければならない。一般に、これは、マーシャリ
ングが送信側で行なわれたか否かを示すフラグを受信デ
ータに含めることにより、本発明に従って達成すること
ができる。下記のデータ送信シーケンスを使用して、Ｉ
ＮＭ418によって、受信データがＣＤＲ形式によるもの
であるか否かの認識が確実に行なわれるようにすること
が望ましい。

【００８９】詳しくは、送信側において、送信元の適用
業務プログラムからのデータが、ＤＭＭ412によって操
作され、マーシャリングされる。ＤＭＭ412は、フラグ
ビットをセットし、メッセージの動的部分がマーシャリ
ングされていることを表示する。次に、ＤＭＭは、ロー
カルノードのＯＮＭ416にメッセージを送る。ＯＮＭ416
は、送るべきメッセージの前の位置に、全メッセージの
サイズを含むフィールドを配置する。次に、このメッセ
ージが送信先ノードに送られる。

【００９０】受信側では、ＩＮＭ418が、入力メッセー
ジを受信し、まず、ネットワークから受信中のメッセー
ジの全体のサイズを読み取る。次にＩＮＭは、全体サイ
ズによって指定されるバイト数を読み取って、全メッセ
ージを取得する。次のステップで、ＩＮＭ418は、メッ
セージヘッダーのフラグフィールドを調べ、もしフラグ
フィールドに「マーシャル」フラグビットがセットされ
ていれば、特別なアンマーシャリングルーチンを使用し
て、メッセージの動的な部分を新しいバッファにアンマ
ーシャリングする。一方、「マーシャル」フラグビット
がセットされていなければ、このステップをバイパスし
て、受信データをリクエストマネージャ406の入力待ち
行列に直接送る。こうして、リクエストマネージャ406
は、送信先の適用業務に適したフォーマットを有するデ
ータを確実に受信することになる。

【００９１】サンプル構成 上述したように、本発明に従って、統合システムを構成
できるようになる前に、システム要件、システム及び適
用業務の能力、適用業務が必要とする統合機能を完全に
理解していなければならない。こうした情報には、(1)
統合システムによってサービスを提供される適用業務、
(2)該適用業務間におけるデータの流れ（リンケージ要
件）、(3)適用業務を実行するマシンタイプ、及び、(4)
システムを結合するために使用されるネットワークのタ
イプがある。この情報は、上述のやり方で統合システム
を構築するために、供給されなければならない。

【００９２】以下の例には、作業命令を管理するコンピ
ュータ統合化製造システムの一部を利用する統合タスク
が示されている。この例は、図８及び図９に関連して説
明されるが、図８には、統合されるシステムが示され、
図９には、結果として生じる構成ファイルが示されてい
る。この例の場合、作業命令を取り扱う３つの適用業
務、すなわち、作業命令を発生し、ＨＰ9000／Ｓ800コ
ンピュータ（ＣＰＵ１）上で動作するマテリアルリソー
スプランナ（ＭＲＰ）、作業のスケジュール作成を行な
い、ＨＰ9000／Ｓ800コンピュータ（ＣＰＵ２）上で動
作するスケジューラ（ＳＣＨ）、及び、作業を管理し、
完了した作業の報告を行ない、ＨＰ9000／Ｓ300上で動
作するセルコントローラ（ＣＴＬ）が存在する。これら
の適用業務は、図８に示すようにＬＡＮで接続されてい
る。この例の場合、ＭＲＰ適用業務は、作業命令を生成
し、完了した作業の経過を記録し、Ｃプログラミング言
語で書かれているが、一方、ＳＣＨ適用業務は、命令に
従って作業を実施するために利用可能なマシン、人、及
び、資源についての情報を含んでおり、作業用のスケジ
ュールを生成し、やはり、Ｃプログラミング言語で書か
れていることを想定している。ＣＴＬ適用業務は、作業
を管理し、ＦＯＲＴＲＡＮで書かれている。

【００９３】システムの構成ファイルは、以下のように
形成される。

【００９４】ネットワーク解析によって、本発明の統合
システムで使用できるようになる前に知っておかなけれ
ばならない各ノードに関する情報が得られる。この情報
は、統合システムでノードを定義するために、ネットワ
ーク定義ファイル（Ｎｅｔｗ）の中で使用される。図９
に示すように、ネットワーク定義ファイルには、少なく
とも１つの適用業務が実行されている統合システム内の
各ノードについてのファイル項目が含まれている。この
例の場合、ネットワーク定義ファイルには、各ノードに
ついて、以下の項目が記載されていることが望ましい。
即ち、その論理名及びマシンタイプ、それがシステムの
始動時に始動するか否か、それがコンパイルノードであ
るか否か、それが行なえるクローンプロセスの最大数、
その最大メッセージ領域のサイズ、単一プロセスが利用
できるメッセージ領域の最大パーセンテージ、そのネッ
トワークタイプ、及び、その物理ノード名である。例え
ば、適用業務ＭＲＰは、ＣＰＵ１という論理ノード名と
ＨＰ90000／Ｓ800というマシンタイプを持ち、システム
の始動時に始動するように指定されており、コンパイル
ノードではなく、ＬＡＮタイプのネットワークに接続さ
れているノードで実行される。Ｎｅｔｗには、他のノー
ドについては、それらがコンパイルノードであるという
以外は、同様の情報が含まれている。

【００９５】次に、システムのデータの流れを解析し
て、メッセージデータを送信元の適用業務から送信先の
適用業務へ送る経路を決定する。具体的には、ユーザ
は、各適用業務がデータとして何を期待し、データを送
信する必要のある各適用業務がデータとして何を生成す
るか、データが、各適用業務においてどのように表現さ
れ、アクセスされるかを決定する。適用業務間で送られ
るデータの部分も決定される。この例では、作業命令管
理システムにおける３つの適用業務で交換されるデータ
のフォーマット及びタイプが決定される。適用業務は、
ファイルとメッセージパケットの両方におけるデータ交
換を行なうことを想定している。

【００９６】この例のデータは、異なる言語で記述され
た適用業務間で交換されるので、システムを構成する時
に、ユーザは、データのタイプを定義する必要がある。
これらのデータ記述は、データ定義ファイル（Ｄｄｅ
ｆ）に作成されるが、このデータ定義ファイル（Ｄｄｅ
ｆ）によって、上述したように、メッセージが異なるフ
ォーマットであってもよく、あるいは、適用業務を送信
元の適用業務で異なる言語に変換できるようにし、ま
た、送信先の適用業務では、Ｄｄｅｆファイルのデータ
定義及びＤｍａｎファイルの操作を使って変換できるよ
うになる。一方、データがファイルフォーマットの場合
には、ユーザは、ファイル定義ファイル（Ｆｄｅｆ）で
ファイル転送のオプションを指定することができる。

【００９７】例として、適用業務ＭＲＰは、作業命令番
号、部品番号、量情報、及び、期日を含む作業命令ファ
イルを適用業務ＳＣＨに対して転送することができる。
適用業務ＭＲＰは、また、製造が完了すると、適用業務
ＣＴＬから完了メッセージを受信することができる。ま
た、送信先のメッセージのレイアウトは、送信元のメッ
セージのレイアウトとは異なるので、このメッセージ転
送について、データ操作を定義する必要がある。

【００９８】適用業務ＳＣＨは、作業スケジュール作成
用のファイルにＭＲＰプログラムからの命令を転送し、
ＣＴＬ適用業務に対して、部品番号、量情報、開始日、
開始時刻、停止日、停止時刻、及び、作業命令番号を含
むメッセージを送ることができる。送信先のメッセージ
のレイアウトと送信元のメッセージのレイアウトが異な
るため、このメッセージ転送について、再度、データ操
作を定義しなければならない。また、適用業務ＳＣＨ
は、製造完了後に、ＣＴＬプログラムから完了メッセー
ジを受信することができる。さらに、送信元の適用業務
と送信先の適用業務の言語が異なるため、言語間におけ
る表現の相違を補正するためのリンクを識別しなければ
ならない。

【００９９】ＣＴＬ適用業務は、適用業務ＳＣＨから送
られた、作業命令番号、部品番号、量情報、開始日、及
び、開始時刻を含むメッセージを受信する。次に、作業
命令完了メッセージを適用業務ＭＲＰに送ることが可能
になるが、こうしたメッセージには、作業命令番号、量
情報、部品番号、完了日、及び、質情報が含まれる。ま
た、作業命令番号、量情報、部品番号、及び、完了日を
含む作業命令完了メッセージを適用業務ＳＣＨに送るこ
とも可能である。

【０１００】データの流れのレベルでは、システムのデ
ータ転送に必要なプロセス数、または、それらのプロセ
スの特定のタスクは、設計によって異なる。ただし、情
報収集手順及び構成へのマッピングは、同じままであ
る。例えば、プロセス構成ファイルが図９に示されてい
るが、ここでは、ＭＲＰ適用業務が、プロセスＭＲＰ01
ＣＰには作業命令ファイルを送り出すよう要求し、プロ
セスＭＲＰ02ＣＰには、完了情報を受け取るよう要求す
る、プロセス構成ファイルが示されている。また、ＳＣ
Ｈ適用業務は、２つのプロセス、すなわち、作業命令フ
ァイルを受信するＳＣＨ01ＣＰ、及び、送信メッセージ
を送信し、作業命令完了メッセージを受信するＳＣＨ02
ＣＰを必要とする。一方、ＣＴＬ適用業務は、１つのプ
ロセス、すなわち、その送信メッセージを受信し、完了
メッセージを送信するＣＴＬ01ＦＰのみを必要とする。
従って、３つの適用業務間のデータ転送には、５つのプ
ロセスが必要であり、また、言語及びマシンの相違のた
め、送信先の適用業務におけるデータのレイアウトは、
送信元の適用業務におけるデータのレイアウトと異なる
ので、２つの操作（ＭＡＮＩＰ１とＭＡＮＩＰ３）が必
要になる。プロセス情報は、Ｐｒｏｃファイルに記憶さ
れ、一方、操作情報は、図９に示すように、Ｄｍａｎフ
ァイルに記憶される。

【０１０１】例示の作業命令管理は、主にメッセージを
交換するので、ＭＲＰ適用業務が作業命令ファイルをＳ
ＣＨ適用業務に送る場合には、ファイル定義構成ファイ
ル（Ｆｄｅｆ）には、ＦＩＬＥＤＥＦ１だけが含まれて
いる。そのファイルがＳＣＨ適用業務に到達すると、既
存のターゲットファイルに取って代わる。

【０１０２】統合プロセスの次のステップでは、適用業
務データの言語及び構造の詳細について識別する必要が
ある。送信元の適用業務と送信先の適用業務の両方のデ
ータ構造を識別すると、ユーザは、送信元のデータ構造
を送信先の構造及びデータタイプに変換するために必要
な操作を決定することができる。このデータ情報は、デ
ータ定義ファイル（Ｄｄｅｆ）及びデータ操作ファイル
（Ｄｍａｎ）に置かれる。従って、ユーザは、対応する
ＤＤＬのデータタイプを使って、Ｄｄｅｆファイルのデ
ータを定義できるように、交換されるデータのサイズを
知らなければならない。下記の表６には、送信するメッ
セージのデータサイズを利用して、ＣとＤＤＬの間、及
び、ＦＯＲＴＲＡＮとＤＤＬの間で、データタイプを対
応させる方法が示されている。

【０１０３】

【表６】

【０１０４】表６からの情報を利用して、統合システム
のデータを変換するのに必要な操作パターンを決定する
ことができる。これらの操作は、データ操作ファイルＤ
ｍａｎに納められる。本例の場合、必要な操作のステー
トメントは、送信元の構造（Ｄｉｓｐ ｃ）から送信先
の構造（Ｄｉｓｐ ｆ）への移行(ＭＯＶＥ)である（す
なわち、ＭＯＶＥ ｄｉｓｐ ｃ ＴＯ ｄｉｓｐ
ｆ）。この操作ステートメントは、Ｍａｎｉｐ１と呼ぶ
操作例に含まれている。

【０１０５】これで、ユーザは、ノードを記述する準備
が整ったことになり、そのノードにおいて、ＤＤＬまた
はＤＭＬで定義された送信元のデータを生成することが
できる。この情報は、リンク定義ファイル（Ｌｉｎｋ）
に記憶される。リンクは、送信元の言語タイプ及び送信
先の言語タイプを、妥当性確認時に特定のデータ定義ま
たはデータ操作に結びつける。実行時、Ｌｉｎｋファイ
ルは、適切なノードに対してノードに固有のデータ操作
の割り当てを指定する。例えば、送信元のノードＣＰＵ
２で生じ、ノードＣＰＵ３に送られるメッセージについ
て、Ｌｉｎｋ１は、Ｍａｎｉｐ１に対して、送信元の言
語Ｃから送信先の言語ＦＯＲＴＲＡＮに変換するよう要
求する。

【０１０６】図８及び図９に示す例の場合、Ｌｉｎｋフ
ァイルは、作業命令管理システムの例に必要な４つのリ
ンクを定義する。Ｌｉｎｋ１は、Ｍａｎｉｐ１（ＳＣＨ
からＣＴＬに送られる送出メッセージに実施される操
作）をＳＣＨ適用業務によって使用されるＣ言語に結合
する。一方、Ｌｉｎｋ２は、ＦＯＲＴＲＡＮで記述され
た適用業務ＣＴＬからＣで記述された適用業務ＳＣＨに
送られる作業命令完了メッセージの表現上の差を補正す
る。メッセージは、レコードフォーマットは同じである
が、言語が異なっている。従って、Ｌｉｎｋ２は、Ｄｄ
ｅｆファイルにおける送信元のデータ構造のＤＤＬ定義
（ｗｏ ｃｏｍｐ ｆ）を指示する。Ｌｉｎｋ３は、Ｍ
ａｎｉｐ３（ＣＴＬからＭＲＰに送られる作業命令完了
メッセージに実施される操作）をＣＴＬ適用業務によっ
て使用されるＦＯＲＴＲＡＮ言語に結合する。最後に、
Ｌｉｎｋ１は、ファイル転送のリンクを定義する。転送
されるファイルｆｉｌｅｄｅｆ１は、ＭＲＰ適用業務が
ＳＣＨ適用業務に送る作業命令ファイルである。ＮＵＬ
Ｌ値は、操作が不要であり、送信先のファイル属性の仕
様のみが必要であることを示している。ＣＰＵ２及びＣ
ＰＵ３は、転送の処理を可能にするＤＭＭモジュールを
（始動時に）受信する。

【０１０７】図９には、上述した作業命令管理システム
例のために生成された構成ファイルが示されており、ま
た、各ファイルに定義されている情報が他のファイルに
よってどのように参照されるかが示されている。この構
成ファイルのセットは、図５に関して既に説明した方法
で始動時に使用される前に、妥当性が検証される。従っ
て、ＤＭＭ412は、構成ファイルにおいてユーザによっ
て指定された操作を処理するために、特別に生成され
る。このため、これらのファイルは、始動前に妥当性が
検証され、前述の構成テーブルに従って、各ノードに
（始動時に）ロードされる。

【０１０８】本発明の典型的な実施例について詳述した
が、当業者にはすぐに分かるように、本発明の新規の教
示及び利点から実質的に逸脱することなく、この典型的
な実施例に多くの修正を加えることが可能である。例え
ば、特定の組をなすデータベース管理システムの呼出し
に依存しないようにすることによって、本発明を使用し
たリモートデータベースへのアクセスが可能になる。従
って、リモートデータアクセスルーチンを介して、別の
適用業務のデータベースにアクセスする適用業務は、タ
ーゲットの適用業務によって使用されるデータベースの
構造またはデータベース管理システムが変化したとして
も、変更しなくてすむことになる。これは、構成ファイ
ルにおいて、ターゲットの適用業務データベースの構文
上及び構造上の定義をすることによって実現することが
できる。さらに、本発明の構成ファイルは領域を備える
ことができ、各領域には、物理ネットワークで実行され
るシステムについての構成が含まれている。従って、物
理ネットワークには、同時に動作するいくつかの領域が
存在することが可能であり、これらの領域は、ノードを
重複しない領域に構成することによって、本発明に従
い、ユーザによって管理することができる。また、本発
明は、システムの負荷のバランスをとるために、データ
操作の最適な割当てを自動的に決定することも可能であ
る。従って、これらの、及び、このようなすべての修正
は、本明細書の特許請求の範囲に定義された本発明の範
囲に含まれるものとする。

【０１０９】

【発明の効果】以上のように、本発明によれば、システ
ムインテグレータまたはエンドユーザが、異種のコンピ
ュータのネットワーク環境において既存の適用業務を統
合するためのランタイムソフトウェアをフレキシブル
に、かつ、効率良く作成できるようにするソフトウェア
ツールが提供される。すなわち、本発明によれば、メッ
セージ及びファイル処理システム、データ操作システ
ム、及び、ローカル及びリモートプログラム制御システ
ムを組み合わせたものに等しい機能を有するシステムが
提供される。

【０１１０】すなわち、本発明によれば、メッセージシ
ステムの各端部でデータタイプ及びデータフォーマット
が異なるようにすることができ、同時に、メッセージの
データ要素、データタイプ、または、データフォーマッ
トに変化があっても、起動前に、システムを再構成する
だけですむ、メッセージ処理システムが提供される。こ
の際、システムの再構成は、管理レベルのアクティビテ
ィであるため、ユーザは、通信適用業務におけるユーザ
のソースコードを変更する必要がない。

【０１１１】さらにまた、本発明では、送受信するデー
タのタイプ及びデータフォーマットを簡単に修正するだ
けで、異なるタイプのマシン上での異なるフォーマット
のデータプロセス間で透過方式通信が可能である。結果
として、通信する適用業務プログラムを、同じ言語で書
いたり、あるいは、同じタイプのコンピュータにダウン
ロードする必要はない。さらに、本発明では、ユーザ
は、既存の適用業務のコードに対して、最小限の変更
で、あるいは、全く変更を加えずに、既存の適用業務を
リンクさせることが可能であり、それによって、既存の
システムの統合のために書き、維持し、支援しなければ
ならないカスタムコードの量を減らすことができる。

【０１１２】さらにまた、本発明によれば、ローカル及
びリモートの適用業務間転送を可能にすることによっ
て、最小限の修正で、あるいは、全く修正を加えずに、
既存の適用業務をリンクさせることができる。適用業務
間における同期及び非同期メモリに基づくメッセージ転
送及びファイル転送もまた、支援される。さらに、言
語、データフォーマット、及び、データタイプの差は、
フィールドの再構成、追加、または、削除、及び、ハー
ドウェア、言語のアライメント、及び、データサイズの
相違に応じたデータタイプ間の変換といったデータ操作
機能を利用することによって解決される。

【０１１３】さらに、本発明のデータマニプレータ（Ｄ
ＭＭ）は、実行時にデータの自動操作を行うことによっ
て、２つの通信プロセスが、それ自体のデータモデルの
変更を必要とせずに、互いのデータを用いることができ
るようにする。本発明のデータマニプレータは、ハード
ウェアの相違、適用業務の依存性、コンピュータ言語の
意味上の相違について処理を施す。それは１つのデータ
タイプを他のデータタイプに変換し、メッセージフォー
マットを再構造化し、データ項目に値を割り当てること
ができる。

【０１１４】一般に、変換ルーチンは関係する２つのマ
シンのアーキテクチャと２つの言語の両方または一方に
しか有効ではないため、このネットワークシステムに新
しい言語または新しいマシンのアーキテクチャを追加す
ると、ネットワークにおける以前のマシンアーキテクチ
ャの全てについて、新しい組をなすルーチンを生成し、
新しいマシンにおける適用業務、または、新しい言語で
書かれた適用業務に対するデータ転送を支援しなければ
ならないが、本発明によれば、システムに新しいマシン
または言語を追加する場合に、古いマシンアーキテクチ
ャについて書かれたルーチンに対する変更または追加を
最小限にとどめることが可能である。また、データ操作
モジュールをノードに固有のものにすることによって、
特定のマシンが、他のマシンへデータを送信するため
に、または、多のマシンからデータを受信するために必
要なルーチンの組数を、本発明に従って削減することも
可能である。

【図面の簡単な説明】

【図１】分散型環境で実行される適用業務が、計算及び
データを共有できるようにする、従来のネットワーク・
コンピューティング・システム（ＮＣＳ）の概略図であ
る。

【図２】本発明に基づく統合システムの基本的構成要素
を示した概略図である。

【図３】ある適用業務を、同じシステム上の他の適用業
務に、あるいは、１又は２以上のリモートのシステム上
にある適用業務に接続するために、本発明をどのように
用いることができるかを示した概略図である。

【図４】本発明に基づく統合システムのランタイム構成
要素の構成の概略図である。

【図５】始動ノードによる始動を通して、本発明のデー
タ操作モジュール（ＤＭＭ）が生成される様子を示した
概略図である。

【図６】コンパイルノードからコンパイルノードと同じ
コンピュータアーキテクチャの個々のノードに、構成情
報を配信する様子を示した概略図である。

【図７】本発明を用いる統合システムの開始手順を示し
た流れ図である。

【図８】本発明に基づく異種のネットワークシステムの
一例を示した概略図である。

【図９】図８に示したシステムの構成例に対する構成フ
ァイルの例を示している。

【符号の説明】

２０２ 適用業務 ２０４ 適用業務アダプタ ２０６ アクセスルーチンライブラリ ２０８ ランタイム構成要素 ２１０ システムマネージャ ２１２ コマンドプロセッサ ２１４ 構成ファイル ２１６ ネットワークサービス

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ダリル・ゴーマー アメリカ合衆国カリフォルニア州95129 サン・ノゼ，フィールズ・ドライヴ・ 1463 (72)発明者 ミッチ・アミノ アメリカ合衆国カリフォルニア州95117 サン・ノゼ，ブンディ・アヴェニュー・ 373 (72)発明者 マリ・バドニク アメリカ合衆国オレゴン州97005ビヴァ ートン，サウス・ウェスト・ワンハンド レッドサーティファースト・アヴェニュ ー・7625 (72)発明者 シンシア・ギヴェンス アメリカ合衆国カリフォルニア州95051 サンタ・クララ，ナイトブリッジ・レイ ン・2578 (72)発明者 マーク・イケモト アメリカ合衆国カリフォルニア州95035 ミルピタス，コルホ・ストリート・400 (72)発明者 シャラ・イスラニ アメリカ合衆国カリフォルニア州94025 メンロ・パーク，ローズ・アヴェニュ ー・922 (72)発明者 アラン・ミランダ アメリカ合衆国カリフォルニア州95124 サン・ノゼ，ジェニファー・ウェイ・ 3508 (72)発明者 クリーメン・ジュー アメリカ合衆国カリフォルニア州94022 ロス・アルトス・ヒルズ，ラ・バラン カ・12896 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 15/16 630 G06F 9/06 410 G06F 13/00 351 ＷＰＩ（ＤＩＡＬＯＧ)

Claims (3)

(57)【特許請求の範囲】
1. 【請求項１】少なくとも２つのノードを有する分散処理
   ネットワークのそれぞれのノードで動作するユーザソフ
   トウエア適用業務プログラムを統合するためのシステム
   であって、前記分散処理ネットワークの各ノードが、 前記各ノードで動作するユーザソフトウエア適用業務プ
   ログラムが、前記分散処理ネットワークに対して、通信
   アクセスができるようにするための適用業務適応手段
   と、 前記各ノードで動作する各ユーザソフトウエア適用業務
   プログラムと前記分散処理ネットワークに接続された他
   のノードで動作する他のユーザソフトウエア適用業務プ
   ログラムとの間のデータ転送要求を管理するためのメッ
   セージ管理手段と、 送信先のノードが、該送信先のノードで動作する送信先
   のユーザソフトウエア適用業務プログラムを有し、該プ
   ログラムに対して、前記ノードで動作する送信元のユー
   ザソフトウエア適用業務プログラムから、データが転送
   されてくるようにされており、前記送信元のノードと前
   記送信先のノードとの間で、前記分散処理ネットワーク
   を介して、ノード対ノードの通信を確立するために、前
   記ノードの任意のノードで動作する、前記送信元のユー
   ザソフトウエア適用業務プログラムからのデータ転送要
   求に応答する通信手段と、 前記各ノード間のハードウエアの違い、前記各ノードで
   動作する前記ユーザソフトウエア適用業務プログラム間
   のコンピュータ言語の意味上の相違、及び、前記データ
   転送要求のデータタイプフォーマットの違いを補償する
   ために前記分散処理ネットワークの全てのノードによっ
   て使用される一般的なコード化体系に従って、共通デー
   タ表現が構成されており、前記通信手段によって、前記
   送信先のノードで動作する、前記送信先のユーザソフト
   ウエア適用業務プログラムへの伝送に先だって、前記送
   信元と送信先のユーザソフトウエア適用業務プログラム
   のデータタイプ、データフォーマット、コンピュータ言
   語、及び、データ表現の少なくとも一つが互いに一致し
   ていない場合にのみ、前記送信元のユーザソフトウエア
   適用業務プログラムからの前記メッセージデータを操作
   して、前記共通データ表現に変換するためのデータ操作
   手段と、 前記分散処理ネットワークから受信した前記共通データ
   表現によるメッセージデータを操作して、前記各ノード
   のデータタイプ、データフォーマット、データ表現、及
   び、コンピュータ言語に変換するための各ノードにおけ
   る手段と、 前記送信先のユーザソフトウエア適用業務プログラムが
   前記ノードのうちの任意のノードで動作している場合
   に、前記送信先のユーザソフトウエア適用業務プログラ
   ムへ転送するために、前記送信元のユーザソフトウエア
   適用業務プログラムからのデータを操作して、前記共通
   データ表現に変換し、また、前記送信元のユーザソフト
   ウエア適用業務プログラムから受信した前記共通データ
   表現によるデータを前記送信先のソフトウエア適用業務
   プログラムと互換性のあるデータに変換するようになさ
   れたノード固有のデータ操作手段を、前記分散処理ネッ
   トワークの各ハードウエアタイプを有する各ノード毎に
   構成する手段であって、 前記分散処理ネットワーク上で動作するユーザソフトウ
   エア適用業務プログラム及びノードと、各送信元及び送
   信先ユーザソフトウエア適用業務プログラムに関連した
   データ特性と、各送信元及び送信先ユーザソフトウエア
   適用業務プログラムに関連したデータ特性に従って、送
   信元ユーザソフトウエア適用業務プログラムからのデー
   タを送信先ユーザソフトウエア適用業務プログラムのデ
   ータに変換するために必要な操作と、を表す複数の構成
   ファイルを格納するためのファイル手段と、 前記分散処理ネットワーク上で動作するユーザソフトウ
   エア適用業務プログラム及びノードを表す前記構成ファ
   イルによって提供される情報に応答して、妥当性が確認
   された始動ファイルを、管理ノードとして指定されたノ
   ードにおけるソースコードとして生成するための妥当性
   確認モジュール手段と、 操作始動ファイル及び操作を、前記管理ノードにおける
   ソースコードとして生成するための構成テーブルコンパ
   イル手段及びデータ操作コンパイル手段であって、各送
   信元及び送信先ユーザソフトウエア適用業務プログラム
   に関連したデータ特性を表す前記構成ファイルによって
   提供される情報に応答して、前記操作始動ファイルを生
   成し、各送信元及び送信先ユーザソフトウエア適用業務
   プログラムに関連したデータ特性に従って、送信元ユー
   ザソフトウエア適用業務プログラ ムからのデータを送信
   先ユーザソフトウエア適用業務プログラムのデータに変
   換するために必要な前記操作を生成する、構成テーブル
   コンパイル手段及びデータ操作コンパイル手段と、 ノード固有の 操作モジュールを生成するために、コンパ
   イルノードとして指定された各ノードで、前記操作始動
   ファイルをコピーし、コンパイルするためのデータ操作
   モジュール構築手段と、前記妥当性が確認された始動ファイルをコピーし、該フ
   ァイルをメモリにロードし、前記操作始動ファイルを適
   用 するための始動モジュール手段と、 からなる、ノード固有のデータ操作手段をノード毎に構
   成する前記手段からなることを特徴とするシステム。
2. 【請求項２】前記共通データ表現が前記分散処理ネット
   ワーク上のノードのアーキテクチャ及び、前記分散処理
   ネットワークで使用されるコンピュータプログラミング
   言語には依存しないことを特徴とする請求項１に記載の
   システム
3. 【請求項３】少なくとも２つのノードを有する分散処理
   ネットワークのそれぞれのノードで動作するユーザソフ
   トウエア適用業務プログラムを統合するための方法であ
   って、前記分散処理ネットワークの各ノードにおける該
   方法が、 前記各ノードで動作するユーザソフトウエア適用業務プ
   ログラムが、前記分散処理ネットワークに対して、通信
   アクセスができるようにするステップと、 前記各ノードで動作する各ユーザソフトウエア適用業務
   プログラムと、前記分散処理ネットワークに接続された
   他のノードで動作する別のユーザソフトウエア適用業務
   プログラムとの間のデータ転送要求を管理するステップ
   と、 送信先のノードが、該送信先のノードで動作する送信先
   のユーザソフトウエア適用業務プログラムを有し、該プ
   ログラムに対して、前記ノードの少なくとも一つのノー
   ドで動作する送信元のユーザソフトウエア適用業務プロ
   グラムから、データが転送されてくるようにされてお
   り、前記送信元のノードと前記送信先のノードとの間
   で、前記分散処理ネットワークを介して、ノード対ノー
   ドの通信を確立するステップと、 前記各ノード間のハードウエアの違い、前記各ノードで
   動作する前記ユーザソフトウエア適用業務プログラム間
   のコンピュータ言語の意味上の相違、及び、前記データ
   転送要求のデータタイプフォーマットの違いを補償する
   ために前記分散処理ネットワークの全てのノードによっ
   て使用される一般的なコード化体系に従って、共通デー
   タ表現が構成されており、前記送信先のノードで動作す
   る、前記送信先のユーザソフトウエア適用業務プログラ
   ムへの伝送に先だって、前記送信元と送信先のユーザソ
   フトウエア適用業務プログラムのデータタイプ、データ
   フォーマット、コンピュータ言語、及び、データ表現の
   少なくとも一つが互いに一致していない場合にのみ、前
   記送信元のユーザソフトウエア適用業務プログラムから
   の前記メッセージデータを操作して、前記共通データ表
   現に変換するステップと、 前記送信先のユーザソフトウエア適用業務プログラムが
   前記送信先のノードで動作している場合に、前記分散ネ
   ットワークから受信した前記共通データ表現によるメッ
   セージデータを操作して、前記送信先ノードの前記デー
   タタイプ、データフォーマット、データ表現、及び、前
   記送信先のユーザソフトウエア適用業務プログラムのコ
   ンピュータ言語に変換するステップと、 前記送信先のユーザソフトウエア適用業務プログラムが
   前記送信先のノードで動作している場合に、前記送信先
   のユーザソフトウエア適用業務プログラムへ転送するた
   めに、前記送信元のユーザソフトウエア適用業務プログ
   ラムからのデータを操作して、前記共通データ表現に変
   換し、また、前記送信元のユーザソフトウエア適用業務
   プログラムから受信した前記共通データ表現によるデー
   タを操作して、前記送信先のソフトウエア適用業務プロ
   グラムと互換性のあるデータに変換するようになされた
   各ノードにおけるノードに固有のデータ操作ステップ
   を、前記分散処理ネットワークの各ハードウエアタイプ
   を有する各ノード毎に構成するステップであって、 前記分散処理ネットワーク上で動作するユーザソフトウ
   エア適用業務プログラム及びノードと、各送信元及び送
   信先ユーザソフトウエア適用業務プログラムに関連した
   データ特性と、各送信元及び送信先ユーザソフトウエア
   適用業務プログラムに関連したデータ特性に従って、送
   信元ソフトウエア適用業務プログラムの データを送信先
   ソフトウエア適用業務のデータに変換するために必要な
   操作と、を記憶するステップと、 前記分散処理ネットワーク上で動作するユーザソフトウ
   エア適用業務プログラム及びノードを表す前記構成ファ
   イルによって提供される情報に応答して、始動ファイル
   を、管理ノードとして指定されたノードにおけるソース
   コードとして生成するステップと、 操作始動ファイル及び操作を、前記管理ノードのソース
   コードとして生成するためのステップであって、各送信
   元及び送信先ユーザソフトウエア適用業務プログラムに
   関連したデータ特性を表す前記構成ファイルによって提
   供される情報に応答して、前記操作始動ファイルを生成
   し、各送信元及び送信先ユーザソフトウエア適用業務プ
   ログラムに関連したデータ特性に従って、送信元ユーザ
   ソフトウエア適用業務プログラムのデータを送信先ユー
   ザソフトウエア適用業務プログラムのデータに変換する
   ために必要な前記操作を生成する、ステップと、 ノード固有の 操作モジュールを生成するために、コンパ
   イルノードとして指定された各ノードで、前記操作始動
   ファイルをコピーし、コンパイルするステップと、 前記始動ファイルをコピーし、該ファイルをメモリにロ
   ードし、前記操作始動ファイルを適用するステップとか
   らなる、前記ステップ からなることを特徴とする方法。