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

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

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

【０００６】上述の問題に対する部分的解決策として、
各種適用業務によるデータの共用を可能にする分散ネッ
トワークの形成が提案された。その場合には、これらの
適用業務は、サン・マイクロシステム（Ｓｕｎ　Ｍｉｃ
ｒｏｓｙｓｔｅｍｓ）のネットワーク・ファイル・シス
テム（Ｎｅｔｗｏｒｋ　Ｆｉｌｅ　Ｓｙｓｔｅｍ　（Ｎ
ＦＳ））、ＡＴ＆Ｔのリモート・ファイル・シェアリン
グ（Ｒｅｍｏｔｅ　Ｆｉｌｅ　Ｓｈａｒｉｎｇ　（ＲＦ
Ｓ））、ＦＴＡＭ（ＭＡＰ／ＴＯＰ仕様で規定）、また
は、アポロ（Ａｐｏｌｌｏ）のドメイン・ファイル・シ
ステム（Ｄｏｍａｉｎ　ＦｉｌｅＳｙｓｔｅｍ）といっ
た透過方式データ共用機構依存した。しかし、これらの
システムには、データの共用は可能になるが、さまざま
な適用業務プログラムの真の統合は可能にならないとい
う点で限界がある。

【０００７】分散ネットワークで接続された異なるコン
ピュータプロセス間におけるプロセス間通信を可能にす
るシステムのもう１つの例は、ディジタル・イクイップ
メント社（Ｄｉｇｉｔａｌ　Ｅｑｕｉｐｍｅｎｔ　Ｃｏ
ｒｐ）によるプロセス・アクティベーション・アンド・
メッセージ・サポート（Ｐｒｏｃｅｓｓ　Ａｃｔｉｖａ
ｔｉｏｎ　ａｎｄ　Ｍｅｓｓａｇｅ　Ｓｕｐｐｏｒｔ　
（ＰＡＭＳ））システムである。このシステムの場合、
一般に、プロセスが共通ネットワークのどこに位置する
かに関係なく、プロセス相互間の通信を可能ならしめる
。こうしたプロセスは、単一のＣＰＵに位置する場合も
あれば、ワークステーション、クラスタ、あるいは、局
域ネットワークまたは広域ネットワーク（ＬＡＮまたは
ＷＡＮ）間に散在している場合もある。ＰＡＭＳシステ
ムは、ネットワークを介した全ての接続を管理し、統合
機能を提供して、それぞれのワークステーション、クラ
スタ等におけるプロセスの通信を可能にする。すなわち
、ＰＡＭＳメッセージ処理システムは、他のネットワー
クより上位で実施され、新しいネットワーク及び事象を
透過方式で統合し、共通メッセージバスに送り込むネッ
トワーク層である。こうしたシステムによって、ネット
ワーク構成のモニター及びメッセージバスにおけるメッ
セージの流れのモニターを単一ポイントで行なうことが
可能になる。 その結果、コンピュータシステムが接続される全てのホ
スト環境に対する共通のプログラミングインタフェース
が得られる。従って、全てのホスト環境が、ユーザには
同じに思われる。

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

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

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

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

【００１２】ＮＣＳシステムは、プログラマがサブルー
チンの呼出しを利用して、遠隔サブルーチンによって用
いられ、戻されるデータの数及びタイプを規定できるよ
うにする働きをする。すなわち、ＮＣＳによって、適用
業務開発者が、ネットワークインタフェース定義言語（
ＮＩＤＬ）と呼ばれる言語でインタフェース定義１１４
を行ない、これが、さらに、ＮＩＤＬコンパイラ１１６
を介して送られ、ユーザスタブとサーバスタブの両方に
対するＣ原始コードを自動的に発生させることが可能に
なる。すなわち、ＮＩＤＬコンパイラ１１６が、スタブ
原始コード１１８及び１２０を発生し、これが、さらに
、Ｃコンパイラ１２４及び１２６によって、ＲＰＣ実行
時間原始コード１２２とコンパイルされ、適用業務、及
び、ユーザの機械で実行されるユーザ側スタブ１０４と
リンクされることになり、一方、サブルーチン１１２及
びそのサーバ側スタブ１１０は、サーバ機械でコンパイ
ルされ、リンクされる。適用業務１０２が書き込まれ、
ネットワークに分散されると、ユーザは、ネットワーク
情報１３０を含むロケーションブローカ１２８を利用し
て、必要とされるサービス（ＲＰＣ）がサーバシステム
で得られるか否かを尋ねることが可能になる。

【００１３】従って、ＮＣＳの場合、ＮＩＤＬコンパイ
ラが、適用業務と遠隔サブルーチンの間で送られるデー
タを生成し、解釈するスタブを自動的に発生する。結果
として、遠隔サブルーチン呼出しは、たまたま遠隔ホス
トで実行されたばかりの局所サブルーチン呼出しにすぎ
ないように見えるので、適用業務開発者は、プロトコル
操作を実施する必要がない。すなわち、ＮＣＳシステム
は、主として、遠隔実行サービスであり、１つのデータ
タイプからもう１つのデータタイプへの変換を可能にす
るために、メッセージの再構造化を行なうことにより、
転送に備えたデータ操作を実施する必要はない。１９８
７年６月のユニックス・レビュー（Ｕｎｉｘ　Ｒｅｖｉ
ｅｗ）第６６〜７５頁所載の「適所配置（Ｅａｃｈ　Ｐ
ｉｅｃｅ　Ｉｎ　Ｉｔｓ　Ｐｌａｃｅ）」と題するエイ
チ・ジョンソン（Ｈ．　Ｊｏｈｎｓｏｎ）による論文に
は、ＮＣＳシステムに関するより詳細な解説がある。

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

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

【００１６】

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

【００１７】

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

【００１８】従って、本発明は、送られるデータタイプ
及びデータフォーマットを簡単に修正して、異なるタイ
プの機械において異なるフォーマットのデータプロセス
間における透過方式通信を可能にするように特殊化され
たものである。結果として、通信中の適用業務プログラ
ムは、同じ言語で書いたり、あるいは、同じコンピュー
タタイプにダウンロードする必要はない。本発明は、さ
らに、ユーザが、最小限の変更で、あるいは、全く変更
を加えずに、既存の適用業務と適用業務のコードをリン
クさせることによって、既存のシステムの統合のために
書き、維持し、支援しなければならないカスタムコード
の量を減らすことができるようにする。本発明は、局所
及び遠隔適用業務間転送を可能にすることによって、本
明細書の背景部分で述べた重要な統合の問題を取り扱い
、最小限の修正で、あるいは、全く修正を加えずに、既
存の適用業務と適用業務をリンクさせることができるよ
うにするものである。適用業務間における周期及び非同
期メモリに基づくメッセージ転送及びファイル転送も支
援される。さらに、言語、データフォーマット、及び、
データタイプの差は、フィールドの再構成、追加、また
は、削除、及び、ハードウェア、言語アライメント、及
び、データサイズの相違に基づくデータタイプ間の変換
といったデータ操作機能を利用することによって解決さ
れる。これは、共通データ表現（ＣＤＲ）を利用して、
異種のノード間でメッセージの転送が行われるようにす
ることによって、望ましい実施例で行なわれる。

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

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

【００２１】

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

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

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

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

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

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

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

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

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

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

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

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

【００３３】送信プロセスによって、「待機して」メッ
セージを送るように指定される場合、メッセージを宛先
ノードに送ることができなければ、ＯＮＭ４１６は、要
求マネージャ４０６の入力待ち行列に状態情報を送る。 しかし、メッセージに操作の必要がなく、宛先プロセス
が同じノードにある場合、メッセージは、ＯＮＭ４１６
を介して送られない。代りに、宛先プロセスのメッセー
ジ領域の待ち行列に、メッセージが直接送り込まれ、不
必要なデータ送信が防止される。送信プロセスによって
、「保証付配送」でメッセージを送るように指定される
場合、要求マネージャ４０６は、ディスクファイル４１
０に受信したメッセージを保管し、適用業務プログラム
４０２から削除要求のある場合に限って、こうしたメッ
セージを削除する。一般に、削除要求が行なわれる前に
、受信プロセスによって、読取り要求が行われる。メッ
セージが保証付配送で送られることにならない場合、要
求マネージャ４０６は、メッセージをメモリ領域４０９
に保管し、このメッセージは読取りメッセージ要求によ
って、受信プロセスに利用できる。受信プロセスが、読
取り要求を行なう場合、メッセージを削除すべきか否か
を指定することができる。

【００３４】入力ネットワークマネージャ（ＩＮＭ）４
１８が、ネットワークから入力メッセージを受信し、宛
先適用業務プログラム４０２に送られる前に、これらの
メッセージを共通のデータ表現フォーマットから局所フ
ォーマットに変換する必要があるか否かを判定する。原
始ノードが、異なるデータタイプである場合、あるいは
、原始プログラミング言語が異なる場合のように、こう
した翻訳が必要な場合、メッセージを要求マネージャ４
０６の入力待ち行列に送る前に、変換（アンマーシャリ
ング（ｕｎｍａｒｓｈａｌｌｉｎｇ））ルーチンのライ
ブラリを用いて、共通のデータ表現から局所データ表現
にメッセージを変換する。こうした操作を必要としない
入力メッセージは、直接、要求マネージャ４０６の入力
待ち行列に送られる。

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

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

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

【００３８】ＤＤＬのデータは、Ｃにおけるタイプ定義
またはＰＡＳＣＡＬにおけるタイプ宣言とほぼ同様のや
り方で定義される。本発明によるＤＤＬ宣言は、Ｃ及び
ＰＡＳＣＡＬといった標準言語のデータ宣言セクション
と同様であり、従って、当該技術における通常の技術者
の技能レベル範囲に十分納まるものと思われる。例えば
、本発明のＤＤＬには、全ての手順のデータタイプに関
する情報を含むことが望ましく、先行技術とは違って、
本発明のＤＤＬは、さらに詳細に後述されるＤＭＬに基
づく１つのデータタイプからもう１つのデータタイプへ
の変換を可能にする。さらに、従来の言語とは異なり、
本発明によるＤＤＬ定義は、特定の言語または機械表現
をデータ定義に結合しない。その代り、データ定義と機
械は、後述のように、リンク定義によってリンクされて
いる。従って、本発明によるＤＤＬは、主としてデータ
の論理レイアウトに関するものであり、従って、結合す
べきネットワークの言語を支援するのに適したＤＤＬは
、当該技術における通常の技術者の技能範囲に十分納ま
るものと思われる。例えば、付録Ｃには、ネットワーク
においてＣ、ＦＯＲＴＲＡＮ、及びＰＡＳＣＡＬを支援
する可能性のあるＤＤＬの部分的説明が行なわれている
。付録Ｃには、こうした場合のＤＤＬ宣言に関するＢＮ
Ｆ構文図も含まれている。

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

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

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

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

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

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

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

【００４６】５．リンクのセッティング最後に、ユーザ
は、原始データが作成され、データの原始言語と宛先言
語が転送されることになる、データ定義及びデータ操作
とノードのリストとの連係のため、リンクの規定を行な
う。この情報は、リンク定義構成ファイル（Ｌｉｎｋ）
に記憶される。Ｌｉｎｋファイルには、メッセージの原
始側と宛先側におけるデータの物理特性が記載されてお
り、特定のデータまたは操作定義を特定のリンクに結び
つける。リンク定義は、データ定義及び操作を原始位置
及びアーキテクチャタイプ、原始言語及び宛先言語、及
び、ファイル定義に結びつける。

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

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

【００４９】図５に示すように、構成ファイル５０２が
、管理ノードにロードされる。妥当性確認プログラム５
０４は、構成ファイル５０２からネットワーク定義（Ｎ
ｅｔｗ）にプロセス定義（Ｐｒｏｃ）、リンク定義（Ｌ
ｉｎｋ）、及び、ファイル定義（Ｆｄｅｆ）を読み取る
。構成ファイル５０２は、妥当性確認プログラム５０４
に対して識別された登録簿に常駐しなければならない。 妥当性確認プログラム５０４は、構性ファイルの保全性
をチェックし、始動時に必要な２進データファイル５１
０に変換する。次に、妥当性確認プログラムは、ＤＤＬ
コンパイラ５０６を呼び出して、データ定義（Ｄｄｅｆ
）を読み取り、メモリ内にＤＤＬ記号テーブルを作成す
る。次に、妥当性確認プログラム５０４によってＤＭＬ
コンパイラ５０８が呼び出され、Ｄｍａｎファイルにお
けるデータ操作定義を読み取って、データ操作を実施し
、原始データを共通のデータ表現に変換するＣ言語命令
を含む、Ｃ原始ファイル５１２を発生する。次に、ＤＭ
Ｌコンパイラ５０８は、ＤＭＬコンパイラ５０８に関す
るデータ定義情報妥当性確認プロセス５０４からのリン
ク定義、及び、Ｄｍａｎ５０２からの操作定義を利用し
て、ルックアップテーブルのＣ原始ファイル５３０、操
作Ｃ原始ファイル５１２、及び、Ｃ原始索引ファイル５
１４を発生する。異なる原始ファイル索引が、各機械タ
イプ毎に生成される。

【００５０】従って、ある意味では、妥当性を確認され
た構成ファイル５１０、操作Ｃ原始ファイル５１２、及
び、Ｃ原始索引ファイル５１４、及び、ルックアップテ
ーブルのＣ原始ファイル５３０は、メモリにロードする
ことができるが、代りに、ＤＭＭ４１２の構築にも利用
される構成情報を表わしている。これらのファイルは、
始動プロセス５１６時に管理ノードによって利用され、
統合領域の全てのノードに分散される構成テーブルが生
成される。Ｃ原始索引ファイル５１４、ルックアップテ
ーブルＣ原始ファイル５３０、及び、操作Ｃ原始ファイ
ル５１２が、ノードに固有のデータ操作モジュールの形
成に用いられる。

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

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

【００５３】各コンパイルノード毎に、後続の始動アク
ティビティは、ＤＭＭビルダ５２０によって管理される
。 ＤＭＭビルダ５２０は、コンパイルノードに新しいＤＭ
Ｍを必要とする、ネットワーク内の関連するＣ原始ファ
イル（ルックアップ及び操作）と共に、その特定の機械
タイプに関するＣ原始索引ファイルを引き出し（コピー
し）、Ｃ原始ファイルを目的モジュールにコンパイルす
る。結果として、図４に示すように、実行時にコンパイ
ルノードで用いられるＤＭＭ４１２に対応するＤＭＭ５
２８が該ノードで得られる。Ｃコンパイラ５２４は、操
作Ｃ原始ファイル５１２をコンパイルして、その機械ま
たはアーキテクチャタイプに固有の目的ファイル５２６
のカスタム化ライブラリを形成する。コンパイラ５２４
は、ルックアップテーブルＣ原始ファイル５３０をコン
パイルして、ノードに固有の目的ファイルにする。

【００５４】次に、コンパイルノードは、それを必要と
するネットワークにおけるその機械タイプの各ノードに
、固有のＤＭＭモジュール５２８を分散させる。図６に
は、コンパイルノードがＤＭＭをこうした全てのノード
に分散させる方法が示されている。図示のように、妥当
性を確認された構成ファイル５１０、ルックアップＣ原
始ファイル５３０、操作Ｃ原始ファイル５１２、及び、
Ｃ原始索引ファイル５１４が、説明したばかりのように
、アーキテクチャに固有のＤＭＭモジュール５２８を形
成するため、コンパイルノードによって引き出される（
コピーされる）。次に、このＤＭＭモジュール５２８は
、ＤＭＭを必要とする、ネットワークにおけるアーキテ
クチャタイプの他の全てのノード（ノード３〜６）に分
散され、これらのノードが、さらに、ＤＭＭを受信した
ことをコンパイルノードに知らせる。コンパイルノード
は、この状態を始動プロセスに送る。

【００５５】要するに、該プロセスは、始動ノードから
始めて、各ノード毎に、妥当性を確認されたファイルを
ノードにコピーし、構成テーブルをメモリにロードし、
始動のための実行時プログラムを作成し、ユーザの決定
に従って実行時プログラムを始動／停止させ、１組の構
成ファイルを全ての代替管理ノードにコピーし、操作Ｃ
原始ファイル５１２、ルックアップファイル５３０、及
び、Ｃ原始索引ファイル５１４を全ての代替管理ノード
にコピーするというアクティビティを実施する。

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

【００５７】ＤＭＭ実行時操作 図５に関連して解説のように、本発明のデータマニプレ
ータは、データ宣言に処理を加え、データマニプレータ
の他のソフトウェアモジュールによって用いられる記号
テーブルを発生するＤＤＬコンパイラから構成されるの
が望ましい。ＤＭＬコンパイラは、また、ユーザによっ
て定義のデータ操作ステートメントに処理を施し、共通
データ表現ライブラリのデータコード化機能（ＡＳＮ．
１基本コード化ルール）、及び、データ操作ライブラリ
のデータ変換及び操作機能によってコンパイルされるＣ
原始コードモジュールを発生するために設けられている
。コンパイル後に生成される目的コードモジュールは、
特定のメッセージにどんなタイプの操作が必要かを判定
し、ＤＭＬコンパイラによって発生する適正な操作モジ
ュールを呼び出して、アーキテクチャの異なるコンピュ
ータに対する送信のために、データを共通のデータ表現
による表示に変形する、データ操作シェルと呼ばれるモ
ジュールによって実行時に実行される。最後に、本発明
の望ましい実施例のデータマニプレータには、入力ネッ
トワークマネージャ３１８によって呼び出され、共通デ
ータ表現フォーマットによるメッセージを局所ホストデ
ータ及び言語表現に解読する「アンマーシャラー（ｕｎ
ｍａｒｓｈａｌｌｅｒ）」モジュールが含まれる。

【００５８】データ操作モジュールの動作時、データ操
作シェルは、その入力メールボックスから（要求マネー
ジャ３０６から）メッセージを読取り、適合するデータ
操作を呼び出して、ユーザの適用業務プログラムによっ
て要求されるデータを変形する（すなわち、宛先フォー
マットを整合させる）。メッセージの操作後、データ操
作シェルは、配送のため、出力ネットワークマネージャ
３１６に送る。受信ノードにおいて、入力ネットワーク
マネージャ３１８は、ネットワークからメッセージを得
て、アンマーシャリング（ｕｎｍａｒｓｈａｌｌｉｎｇ
）タスクが必要か否かを判定する。必要であれば、入力
ネットワークマネージャ３１８は、アンマーシャラー（
ｕｎｍａｒｓｈａｌｌｅｒ）モジュールを呼び出す。メ
ッセージ内容から、アンマーシャラー（ｕｎｍａｒｓｈ
ａｌｌｅｒ）モジュールは、どの機能が必要かを判定し
、アンマーシャリング（ｕｎｍａｒｓｈａｌｌｉｎｇ）
を実施するこれらの機能を呼び出す。

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

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

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

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

【００６３】

【表１】

【００６４】＊アンマーシャリングモジュールは、マー
シャリングを行なうコードが、多次元アレイの要素を目
標言語に関する行／列主配列をなすようにするものと仮
定する。すなわち、アンマーシャラーは、ＡＳＮ．１ア
レイの要素が目標言語に関して適正な行／列主配列をな
すものと仮定する。これは、アレイ要素の再配列を行な
わない。

【００６５】タイプ属性ＩＤ名の後の括弧（　　）内の
数は、コードに用いられるタイプ属性ＩＤの数値を表わ
している。

【００６６】表１に示すように、タイプ属性ＩＤは、Ａ
ＳＮ．１タイプの目標ＤＤＬタイプを識別する名である
。識別名の後の数は、原始コードにおいてそのＩＤを表
わすために用いられる。タイプ属性ＩＤ以外に、タイプ
属性には、受信ノードによる目標ＤＤＬタイプへの正確
なアンマーシャリング（ｕｎｍａｒｓｈａｌｌｉｎｇ）
を可能にするため、ＡＳＮ．１データタイプと共に転送
される特別な情報も含まれている。ＡＳＮ．１データタ
イプフォーマットには、こうした情報のための余地がな
い。例えば、ＡＳＮ．１ストリングタイプのデータ要素
は、ストリング値の現在のサイズを表わすフィールドを
備えているが、ストリングの最大サイズがどれだけにな
り得るかを表わすフィールドはない。この最大サイズ情
報は、タイプ属性情報である。タイプ属性ＩＤとタイプ
属性は、両方とも、実際のＡＳＮ．１コード化ユーザデ
ータ以外に必要とされる特別な情報であるため、両方と
も、本書では「タイプ属性」と称して概念的に一様に扱
われている。

【００６７】データの「マーシャリング（ｍａｒｓｈａ
ｌｌｉｎｇ）」には、上述のように、局所フォーマット
によるデータを機械及び言語と無関係なＣＤＲフォーマ
ットに変換することが含まれる。従って、こうしたマー
シャル（ｍａｒｓｈａｌｌ）されたデータは、ネットワ
ーク内の二つのシステムまたは別のシステムに常駐する
「アンマーシャリング（ｕｎｍａｒｓｈａｌｌｉｎｇ）
」モジュールに送ることが可能である。アンマーシャリ
ング（ｕｎｍａｒｓｈａｌｌｉｎｇ）モジュールは、さ
らに、該データを機械及び言語に依存した局所フォーマ
ットに変換する。本発明によれば、マーシャルされたメ
ッセージは、２つの主要な部分、すなわち、静的フォー
マットメッセージ見出し、及び、動的フォーマット適用
業務データ部分に分類される。これらの部分の分類は、
その部分に、既定の静的フォーマットデータが含まれて
いるか、あるいは、任意のタイプのフォーマットを有す
ることが可能な適用業務束縛データが含まれているかに
基づくものである。メッセージ見出しには、原始／宛先
ノード手段、動作フラグ、目標プロセス論理名等のよう
な、メッセージの転送に必要な管理情報が含まれている
。それには、また、ファイルを送り、プロセスを始動／
停止させ、状態を機械適用業務サーバに戻すといったよ
うな特定の機能の実施に必要な情報も含まれている。一
方、動的フォーマット部分は、転送される適用業務デー
タに従って変動する。

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

【００６９】

【表２】

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

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

【００７２】ＤＭＬコンパイラ５０８によって送り出さ
れるコードは、下記のマーシャリング（ｍａｒｓｈａｌ
ｌｉｎｇ）ステップを行なう：１．見出しのマーシャリ
ング（ｍａｒｓｈａｌｌｉｎｇ）によってマーシャリン
グ（ｍａｒｓｈａｌｌｉｎｇ）プロセスを開始する。

【００７３】２．原始データ要素をバッファの宛先プロ
グラムに生じる順次配列をなすようにマーシャルする。

【００７４】３．全てのデータ要素のマーシャリング（
ｍａｒｓｈａｌｌｉｎｇ）を終了すると、トレーラのマ
ーシャリング（ｍａｒｓｈａｌｌｉｎｇ）を行なう（存
在する場合）。

【００７５】利用しやすくするため、マーシャリング（
ｍａｒｓｈａｌｌｉｎｇ）ルーチンは、２つのバッファ
、すなわち、原始局所化データ要素を保持するための原
始バッファと、もう１つのバッファである、マーシャル
されたデータ要素を保持するための目標バッファを備え
ることが望ましい。

【００７６】次に、本発明の「アンマーシャリング（ｕ
ｎｍａｒｓｈａｌｌｉｎｇ）」ルーチンについて説明す
る。アンマーシャリング（ｕｎｍａｒｓｈａｌｌｉｎｇ
）は、機械と無関係なＣＤＲフォーマットによるデータ
が、何らかの目標機械及び言語フォーマットに変換され
る。アンマーシャリング（ｕｎｍａｒｓｈａｌｌｉｎｇ
）ルーチンで用いられる情報のタイプには、２つのタイ
プがある。第１のタイプは、符号付き／符号なし、パッ
ク／非パックといったようなデータを利用して変更でき
る情報である。この情報は、タイプ属性としてＣＤＲデ
ータストリームをなすデータと共に送られる。もう１つ
のタイプの情報は、データアライメント及びバイト／語
サイズのような安定情報である。この情報は、もちろん
、静的テーブルに組み入れることができる。

【００７７】各ＣＤＲデータ要素が読み取られる時、ア
ンマーシャリング（ｕｎｍａｒｓｈａｌｌｉｎｇ）ルー
チンライブラリ（ＵＴＬ）と呼ばれるライブラリに組み
込まれるアンマーシャリング（ｕｎｍａｒｓｈａｌｌｉ
ｎｇ）ルーチンを用いてアンマーシャル（ｕｎｍａｒｓ
ｈａｌｌ）される。ＭＲＬと同様、各ＵＴＬは、特定の
機械アーキテクチャのためカスタム化される。従って、
支援される機械アーキテクチャタイプ毎に１つのＵＴＬ
バージョンがある。このカスタム化のほとんどは、ライ
ブラリの構築時における値の変化によって取り扱われる
。ＭＲＬと同様、ＵＴＬは、実行時共用ライブラリをな
すようには設計されていない。代りに、ライブラリコー
ドは、リンク時に、ＩＮＭコードにリンクされる。

【００７８】選択的低レべルのルーチンを呼び出して、
対応するデータ要素をアンマーシャル（ｕｎｍａｒｓｈ
ａｌｌ）する。どの低レベルルーチンを呼び出すべきか
の判定は、ＣＤＲデータストリームにどんなタイプのＣ
ＤＲデータが含まれているかに基づいて行なわれる。従
って、これら低レベルルーチンの上位に、ＣＤＲストリ
ームにおける次のデータ要素を調べ、その要素のタイプ
属性ＩＤを利用して、呼び出すべき低レベルのアンマー
シャリング（ｕｎｍａｒｓｈａｌｌｉｎｇ）ルーチンを
選択する主ルーチンを構築しなければならない。こうし
たルーチンは、簡単であり、当該技術の熟練者であれば
容易に設計することができる。

【００７９】データタイプのサイズ及びアライメントに
関する言語に固有の情報、及び、宛先ノードでＤＤＬタ
イプを呼び出す変換ルーチンに対するポインタは、言語
テーブルと呼ばれる２×２のマトリックスに編成される
。機械タイプ毎の言語毎に１つの言語テーブルがある。 行は、ＤＤＬタイプであり、一方、列は、関連する局所
化データ要素のサイズ、アライメント、呼び出すべき特
定のＤＤＬアンマーシャリング（ｕｎｍａｒｓｈａｌｌ
ｉｎｇ）ルーチンに対するポインタである。

【００８０】

【表３】

【００８１】データ受信時にどの言語テーブルを選択す
べきかを判定するため、ＣＤＲの見出しを調べて、目標
言語が何かを選択する情報のバイトを確める。このバイ
トを利用して、大域ポインタをセットし、そのメッセー
ジをアンマーシャル（ｕｎｍａｒｓｈａｌｌ）するのに
用いられる言語テーブルを指示する。このバイト値から
大域ポインタへの移行は、言語テーブルに対するポイン
タの表４によって行うことができる。

【００８２】

【表４】

【００８３】言語テーブルポインタテーブル（ｌｔｐ　
　ｔａｂｌｅ）が、アンマーシャリング（ｕｎｍａｒｓ
ｈａｌｌｉｎｇ）コードの開始時にセットアップされる
。メッセージのアンマーシャリング（ｕｎｍａｒｓｈａ
ｌｌｉｎｇ）時に目標言語バイト値は、言語テーブルに
対するポインタを検索する、ｌｔｐｔａｂｌｅの索引と
して用いられる。大域ポインタは、この言語テーブルを
指示するようにセットされ、この言語テーブルが、アン
マーシャリング（ｕｎｍａｒｓｈａｌｌｉｎｇ）コード
によって、メッセージの残りの部分の変換に用いられる
。

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

【００８５】

【表５】

【００８６】原始バッファの見出しからのバイトは、表
５に示すｌｔｐ　　ｔａｂｌｅの索引として用いること
ができる。この索引は、大域変数の形で保管されており
、従って、この索引によって、どの目標言語がアンマー
シャル（ｕｎｍａｒｓｈａｌｌ）されることになるかが
分かる。また、索引が選択する項目には、２つのポイン
タ、すなわち、言語テーブルのパックバージョンに対す
るポインタと、言語テーブルの非パックバージョンに対
するもう１つのポインタが含まれる。これがあてはまる
のは、ｌｔｐ　　ｔａｂｌｅのＰａｓｃａｌ項目だけで
あり、他の言語は、パックポインタに対するＮＵＬＬポ
インタを備えている。

【００８７】アンマーシャリング（ｕｎｍａｒｓｈａｌ
ｌｉｎｇ）プロセスが、パックアレイ／記録タイプ属性
ＩＤを見つけると（Ｐａｓｃａｌは目標言語でなければ
ならない）、このタイプ属性は、スタックフレームにす
ぐ納められる。スタックフレームにおけるフィールドの
残りは、従って、タイプ属性ＩＤを随伴する情報から初
期設定される。アンマーシャリング（ｕｎｍａｒｓｈａ
ｌｌｉｎｇ）プロセスは、入力バッファにおける次のデ
ータ要素を調べて、パージングを続ける。

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

【００８９】上述のように、送信されるメッセージのユ
ーザデータは、ＡＳＮ．１ＢＥＲを用いてコード化され
る。これは、受信側が、このデータを目標言語データタ
イプにｕｎｍａｒｓｈａｌｌするのに十分ではない、と
いうのは、記述の手助けに必要であるが、タイプ属性及
びデータの見出しもｍａｒｓｈａｌｌされるからである
。すなわち、メッセージの全ての部分が、ＡＳＮ．１基
本コード化ルールに従うので、他の部分は、データバッ
ファ見出し、及び、タイプ属性の助けをかりずに、解読
しなければならない。これは、データバッファ見出しフ
ィールドが、データバッファ見出しについて特定の配列
になっているものと期待して、取り扱われる。従って、
データフィールドを適正に配置することによって、ＡＳ
Ｎ．１アンマーシャリング（ｕｎｍａｒｓｈａｌｌｉｎ
ｇ）ルーチンを呼び出し、バージョン及び目標言語デー
タを含むデータをアンマーシャル（ｕｎｍａｒｓｈａｌ
ｌ）することができる。ただし、タイプ属性フィールド
の配列は、予測することができない。従って、タイプ属
性は、必要に応じ、実行時に急いでアンマーシャル（ｕ
ｎｍａｒｓｈａｌｌ）することになる可能性がある。 　　同種のデータは、本発明に従ってマーシャルされて
いないので、ＩＮＭ４１８は、受信メッセージがＣＤＲ
に変換ずみか否かを判定するためのメカニズムを備えて
いなければならない。一般に、これは、マーシャリング
（ｍａｒｓｈａｌｌｉｎｇ）が送信側で行なわれたか否
かを示すフラグを受信データに含めることにより、本発
明に従って行なうことができる。下記のデータ送信シー
ケンスを利用し、ＩＮＭ４１８によって、受信データが
ＣＤＲ形式によるものであるか否かの認識が確実に行な
われるようにすることが望ましい。

【００９０】すなわち、送信側において、原始適用業務
プログラムからのデータが、ＤＭＭ４１２による操作及
びマーシャリング（ｍａｒｓｈａｌｌｉｎｇ）を受ける
。ＤＭＭ４１２は、フラグビットをセットし、メッセー
ジの動的部分がマーシャルされていることを表示する。 次に、ＤＭＭは、局所ノードのＯＮＭ４１６にメッセー
ジを送る。ＯＮＭ４１６は、送られるメッセージの前に
、全メッセージのサイズを含むフィールドを配置する。 次に、このメッセージが宛先ノードに送られる。

【００９１】受信側では、ＩＮＭ４１８が、入力メッセ
ージを受信し、まず、ネットワークから受信中のメッセ
ージの全体サイズを読み取る。次にＩＮＭは、全体サイ
ズによって指定のバイト数を読み取って、全メッセージ
を得る。次のステップで、ＩＮＭ４１８は、メッセージ
見出しのフラグフィールドを調べ、フラグフィールドに
おける「ｍａｒｓｈａｌｌ」フラグビットがセットされ
ていれば、特殊なアンマーシャリング（ｕｎｍａｒｓｈ
ａｌｌｉｎｇ）ルーチンを利用して、メッセージの動的
部分を新しいバッファにアンマーシャル（ｕｎｍａｒｓ
ｈａｌｌ）する。一方、「マーシャル」フラグビットが
セットされていなければ、このステップをバイパスして
、受信データが、要求マネージャ４０６の入力待ち行列
に直接送られる。こうして、要求マネージャ４０６は、
宛先適用業務に適したフォーマットを有するデータを確
実に受信することになる。　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　サンプル構成上述
のように、本発明に従って、統合システムを構成できる
ようになる前に、システム要件、システム及び適用業務
の能力、適用業務が必要とする統合機能を完全に理解し
なければならない。こうした情報には、（１）統合シス
テムがサービスを行なう適用業務、（２）該適用業務間
におけるデータの流れ（リンケージ要件）、（３）適用
業務を実行する機械タイプ、及び、（４）システムを結
合するために利用されるネットワークのタイプがある。 この情報は、上述のやり方で統合システムを構成するた
めに、供給されなければならない。

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

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

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

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

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

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

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

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

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

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

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

【０１０３】

【表６】

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

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

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

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

【０１０８】本発明の実施例について詳述したが、当該
技術の熟練者にはすぐ分るように、本発明の新規の教示
及び利点からあまり逸脱することなく、実施例に多くの
修正を加えることが可能である。例えば、本発明を利用
した遠隔データベースへのアクセスは、特定の組をなす
データベース管理システムの呼出しに対する依存を排除
することによって可能になる。従って、遠隔データアク
セスルーチンを介した別の適用業務のデータベースに対
する適用業務のアクセスは、目標適用業務によって用い
られるデータベース構造またはデータベース管理システ
ムが変化しても、変更しなくてもすむことになる。これ
は、構成ファイルにおける目標適用業務データベースの
構文上及び構造上の定義によって実施することができる
。さらに、本発明の構成ファイルは、領域を備えること
ができ、各領域毎に、物理的ネットワークで実行される
システムに関する構成が含まれている。従って、物理的
ネットワークには、同時に動作するいくつかの領域を設
けることが可能であり、これらの領域は、ユーザが、本
発明に従って、ノードを非オーバラップ領域に構成する
ことによって管理することができる。また、システムロ
ードのバランスをとるため、本発明は、データ操作に最
適な割当てを自動的に決定することも可能である。従っ
て、これらの、及び、全てのこうした修正は、本明細書
の特許請求の範囲の欄に定義された本発明の範囲内に含
まれるものとする。

【０１０９】

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

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

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

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

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

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

【図面の簡単な説明】

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

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

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

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

【図５】開始時に開始ノードのより本発明のデータ操作
モジュール（ＤＭＭ）を生成する様子を示した概略図で
ある。

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

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

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

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

【符号の説明】

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

Claims (1)

【特許請求の範囲】
1. 【請求項１】分散処理ネットワーク上で動作するユーザ
   ソフトウェア適用業務を統合するためのシステムであっ
   て：前記ユーザソフトウェア適用業務プログラムを前記
   分散処理ネットワークに可換アクセスさせるべく前記分
   散処理ネットワークの各ノード上で動作する、適用業務
   適応手段と；前記分散処理ネットワークの各ノードにあ
   って、前記各ノード上で動作する各ユーザソフトウェア
   適用業務プログラムと前記分散処理ネットワークに接続
   された他のソフトウェア適用業務プログラムとの間のデ
   ータ転送要求を管理するためのメッセージ管理手段と；
   データ転送要求を発したノードであって該ノード上で動
   作する原始ユーザソフトウェア適用業務プログラムを備
   えた原始ノードと、データが転送されるノードであって
   該ノード上で動作する宛先ユーザソフトウェア適用業務
   プログラムを備えた宛先ノードと、の間でノード対ノー
   ド通信を確立するための手段と；各ノードにあって、前
   記原始ユーザソフトウェア適用業務プログラムからのメ
   ッセージデータを前記宛先ユーザソフトウェア適用業務
   プログラムに転送するための共通データ表現に操作する
   ためのデータ操作手段であって、前記原始ユーザソフト
   ウェア適用業務プログラムからの前記メッセージデータ
   は、前記原始ユーザソフトウェア適用業務プログラムと
   前記宛先ユーザソフトウェア適用業務プログラムとのデ
   ータタイプ、データフォーマット及び物理的データ表現
   の少なくとも１つが相互に対応しない場合にのみ、処理
   されることと；から成ることを特徴とするシステム。