JP2005504455A - 適応マルチプロトコル通信システム - Google Patents

適応マルチプロトコル通信システム Download PDF

Info

Publication number
JP2005504455A
JP2005504455A JP2002584522A JP2002584522A JP2005504455A JP 2005504455 A JP2005504455 A JP 2005504455A JP 2002584522 A JP2002584522 A JP 2002584522A JP 2002584522 A JP2002584522 A JP 2002584522A JP 2005504455 A JP2005504455 A JP 2005504455A
Authority
JP
Japan
Prior art keywords
interface card
state machine
finite state
application protocol
intermediate language
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2002584522A
Other languages
English (en)
Other versions
JP2005504455A5 (ja
Inventor
エイヴェリー ムーン
Original Assignee
インフォトーン コミュニケイションズ コーポレイション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by インフォトーン コミュニケイションズ コーポレイション filed Critical インフォトーン コミュニケイションズ コーポレイション
Publication of JP2005504455A publication Critical patent/JP2005504455A/ja
Publication of JP2005504455A5 publication Critical patent/JP2005504455A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

適応マルチプロトコル通信システムが、共通のバックプレーン又は相互接続部に接続された複数の単一コンピュータ・インターフェース・カードを提供する。各々のインターフェース・カードは、特定のアプリケーション・プロトコルのビットストリームを送り、これを受け取り、異なるアプリケーション・プロトコルの間でデータを交換する。インターフェース・カードは、特定のアプリケーション・プロトコルのビットストリームを、例えばＥＤＩ、ＸＭＬといった特定の通信プロトコル、又は本発明の中間変換表示のための多次元マトリックス表示に変換するための専用有限状態機械に、入ってくるバイナリ・ストリームを与える。本発明は、有限状態機械を用いて、最初の通信プロトコルのビットストリームから本発明の中間表示に変換する。受信インターフェース・カード上の有限状態機械を用いて、入ってくるビットストリームを中間言語の多次元マトリックスに変換し、該中間言語の多次元マトリックスをアプリケーション・プロトコルのビットストリームに変換するのに用いられる有限状態機械を有する宛先インターフェース・カードに該マトリックスを送る。次に、アプリケーション・プロトコルのビットストリームは、受信コンピュータ・システムに送られる。

Description

【技術分野】
【０００１】
本発明は、コンピュータ・ネットワークにわたるデータ通信に関する。より具体的には、本発明は、異なる通信プロトコル間で変換を行い、異なるコンピュータ・ネットワークにわたってデータを伝送することに関する。
【背景技術】
【０００２】
過去５０年間にわたって、いろいろな機能を実行するために、企業用の多数のコンピュータ・プログラムが書かれてきた。企業が異なる機能を有する多くのコンピュータ・システムを蓄積するので、企業はいっそう多くのこれらの別個のコンピュータ・プログラムを蓄積することになる。技術が進化するにつれて、企業は既存のシステムをアップグレードし、特有の間隔で新しいシステムを手に入れる。企業のニーズ及び産業全体にわたる技術革新の結果として、企業は、異種の組のコンピュータ・プログラムを実行する異なる組のコンピュータ・システムを時間が経つにつれて蓄積していく。
【０００３】
過去２０年間にわたって、企業の大部分は、ハードウェア及びソフトウェアの混合を用いて、企業のコンピュータ・システムの全てを互いに相互接続した。スイッチ及びルータ、ネットワーク化ソフトウェア、ウェブ・サーバ、及びファイアウォールのようなネットワーク化ハードウェアは、今日企業用コンピュータ・システムがどのように構築され、用いられるかの礎となった。今日コンピュータ・ソフトウェアにより与えられる多くの能力は、各々のコンピュータが共通の共有ネットワークに接続されることを必要とする。マクロレベルにおいて、インターネットは、単純に、企業、教育機関、及び政府機関からのコンピュータ・ネットワークの世界的合同体である。
【０００４】
各々のコンピュータをネットワークに接続することを必要とするようになったことは、コンピュータ・ソフトウェアに大きな影響を及ぼした。具体的には、現在多くのタイプのコンピュータ・ソフトウェアは、その能力を実行するために、相互に共有するネットワークを介して、他のソフトウェアと通信する能力を必要とする。電子メール、ウェブページ、ファイル・サーバの全てが、コンピュータ・ソフトウェア間で情報を伝送するための共有ネットワークに対するこの依存性を例示する。
【０００５】
共有ネットワーク上で動作するコンピュータ・ソフトウェア間の情報の共有を助けるために、この共有の意味規則を定義する様々なコンピュータ・プロトコルが作られた。さららに、過去３０年間にわたって、別個のものではあるが相互に依存する多数のコンピュータ・プロトコル層が定められた。例えば、ＯＳＩネットワーク・スタック・モデルは、これらのプロトコル及びそれらの相互関係の１つの定式化である。
【０００６】
このコンテクストの中で、３つの一般的なコンピュータ・プロトコル層、すなわち物理層、ネットワーク層、及びアプリケーション層を識別することができる。物理ネットワーク・プロトコルは、コンピュータのネットワーク化を実行するのに用いられるワイヤ及びハードウェアの物理的特性についての詳細を定めることに関する。例えば、電気信号及びバイトのビット数は、物理プロトコル内で定められる。
【０００７】
ネットワーク・プロトコルは、コンピュータ・ネットワークの構成、表示、及び識別意味規則についての詳細を定めることに関する。例えば、基本データユニット、フレーム・スキーマ、エラー回復／再試行機構、及びパケット組立（分解）は、ネットワーク・プロトコル内で定められる。
【０００８】
アプリケーション・プロトコルは、セッション・ネゴシエーション、回線パラメータ（圧縮、暗号化など）、データ変換、データ表示フォーマット、データ・スキーマ、トランザクション意味規則、及び要求・応答意味規則に関する。このプロトコル分解は、今日コンピュータ・システムによってそれらがどのように実装されるかに基づいて、ＯＳＩスタックからの概念的集合層から得られる。アプリケーション・プロトコルは、こうしたプロトコルを用いて、データへのアクセスを要求する特定のソフトウェア・プログラム内で、コンピュータ・ソフトウェアに実装される。
【０００９】
物理及びネットワーク・プロトコル層を実装するために、様々なハードウェア・コンピュータ・システム及びコンピュータ・ソフトウェア・プログラムが考案された。特定の配線及び電気信号動作は、シリコンで実装し、物理ネットワーク・プラグを介して接続可能にしなければならないので、物理ネットワーク・プロトコル層を実装するために、特別設計のハードウェアが必要とされる。ネットワーク・プロトコル層は、最初は（１９９０年以前）汎用コンピュータ上で動作するソフトウェアにより実装された。つい最近では、ネットワーク・プロトコルは、カスタム特定用途向け集積回路（ＡＳＩＣ）、又はプログラム可能なネットワーク・プロセッサを用いて実装された。物理及びネットワーク層プロトコル処理を実装するこれらの個々のコンポーネントは、ルータ及びスイッチを含む製品内にパッケージされている。
【００１０】
アプリケーション・プロトコルは、様々な要因のために、ハードウェアには実装されなかった。第１に、アプリケーション論理をハードウェア統合システムに接続することは、性能及びプログラム可能性の理由により実行可能ではないと考えられる。第２に、このようなハードウェア統合システムについて予期される財政的価値は、その開発及び商業化を保証するのに十分なものではなかった。第３に、テクノロジー産業における急速な技術の変化、及びハードウェアのハードウェア設計の長い周期により、財政的動機づけが疑問視された。第４に、過去の多くのプロトコルの知的所有権は特定の企業が有しており、ハードウェアの実装が、知的所有権を侵害することがある。第５に、多くのソフトウェア技術者が、ハードウェア・ベースの統合システムへの必要性を予期しなかった。第６に、ハードウェアに統合システムを実装することが、ソフトウェア技術者又はハードウェア技術者のいずれにとっても、最良の技術的手法と考えられなかった。第７に、一般に合意されたプロトコル基準がないことにより、何百ものアプリケーション・プロトコルがハードウェア統合システムによってサポートされるという実行不可能な要求が求められた。第８に、ソフトウェア技術には、ハードウェア手法を用いて複雑なコンピュータ・ソフトウェアをどのように実装するかについての最良の手法及び過去の先例が不足している。
【００１１】
各々の層について多くのコンピュータ・プロトコルが存在するので、データを交換するために異なるプロトコルを用いてシステム間の通信を助ける解決への必要性が常にあった。これらの解決の全ては、別個のシステムの各々がそのネットワーク接続を介して公開されるプロトコル・インターフェースを理解しブリッジングすることによって、多数のシステムがデータを交換するのを可能にする機能を実装する。この文書の場合には、この機能の説明に適合する能力を実装する全ての解決を、抽象的に統合システムと呼ぶ。
【００１２】
１９８０年代半ばに始まり、マルチプロトコル・ネットワーク・ルータは、異種の物理及びネットワーク層プロトコルの統合を開拓した。具体的には、マルチプロトコル・ネットワーク・ルータは、異なる種類の物理及びネットワーク層プロトコルを実行するネットワーク間でデータを交換するのに必要な機能を実装した。このクラスの革新の原型的例は、知的所有権を有するＩＢＭ ＳＮＡとインターネット・プロトコル（ＩＰ）との間でデータを交換できるルーティング・ハードウェアの開発であった。
【００１３】
アプリケーション層のプロトコルが交換レベルにあるアプリケーション層にこの類推をもたらすと、ソフトウェア・レベルにおいて異種のアプリケーション・レベルのプロトコルを有するコンピュータ間のデータ交換は、よくても複雑なものである。図１を参照すると、従来の手法は、例えば、ｎ個のアプリケーション・プロトコルが２つのコンピュータ・システム１０１、１０２の間で交換される際、大量のソフトウェアの変換を必要とした。各々の変換は固有のものであるので、従来の手法は、ルーチン１０３をマッピングするｎ2個の変換を必要とした。ここで、ｎは、変換の組み合わせを完全にカバーするように交換されるアプリケーション・プロトコルの別個の例の数である。ｎが大きくなると、ｎ2個の変換ルーチンをサポートすることは実行不可能になる。このｎ2個の複雑さのために、従来の手法は、コストが高くなり、開発周期が長くなった。
【００１４】
従来の手法は、通常、交換に用いられる各々のアプリケーション・プロトコルについての多くの別個のソフトウェア・コンポーネントも必要とする。したがって、ユーザがこれらの本質的に異なるコンポーネントを使用するためにシステムのソフトウェア及びシステムを絶えず適合させなければならないので、多数のシステム間での交換を容易にすることは、ユーザにとって厄介なことである。さらに、各々のデータ交換用コンポーネントのための設計は、プログラミング言語、プロトコル・タイプ、及びオペレーティング・システムのような多くの異なる要因に基づいて異なる。したがって、従来の手法は、共通の設計又は実装がないために、技術的に複雑なだけでなく使用するのが難しい。
【００１５】
多数のアプリケーション・プロトコル間で通信するハードウェア統合システムを提供し、必要とされる変換プロセスの数を劇的に減少させる適応マルチプロトコル通信システムを提供することが有利である。さらに、付加的なアプリケーション・プロトコルを適合させるように、ユーザがシステムを容易に拡張することを可能にする適応マルチプロトコル通信システムを提供することも有利である。
【００１６】
（発明の開示）
本発明は、適応マルチプロトコル通信システムを提供するものである。このシステムは、多数のアプリケーション・プロトコルの間で通信し、ｎ個まで必要とされる変換プロセスの数を減少させるハードウェア統合システムを提供する。さらに、本発明は、付加的なアプリケーション・プロトコルを適合させるように、ユーザがシステムを容易に拡張することを可能にするモジュール式システムを提供する。
【００１７】
本発明は、共通のバックプレーン又は相互接続部に接続された複数の単一コンピュータ・インターフェース・カードを提供する。カード間の通信は、メモリ・マップ・スキーマを介して達成される。各々のインターフェース・カードは、特定のアプリケーション・プロトコルのビットストリームを送り、これを受け取る。インターフェース・カードは、異なるアプリケーション・プロトコルの間でデータを交換する。
【００１８】
インターフェース・カードは、入ってくるバイナリ・ストリームを有限状態機械に与える。各々の有限状態機械は、特定のアプリケーション・プロトコルのビットストリームを多次元のマトリックス表示に変換するために専ら用いられる。有限状態機械は、ビットストリーム上で作動し、例えば、ＥＤＩ、ＸＭＬといった特定の通信プロトコル、又は本発明の中間変換表示のための多次元スキーマ・マトリックスを形成する。
【００１９】
前の状態値を用いて多次元マトリックスを適切に形成するために、ルックアサイド・バッファが有限状態機械によって用いられる。ルックアサイド・バッファは、有限状態機械によってルックアサイド・バッファ内に置かれた前のストリーム値を含む。
【００２０】
ユーザは、１組の構成テーブル及び例外テーブルを用いて、有限状態機械の動作を調整することができる。構成テーブルは、ユーザが、有限状態機械が入ってくるバイトストリーム上でどのように作動するかを定め、スキーマ・マトリックスの正しい構文を達成することを可能にする。例外テーブルは、マトリックスの多次元領域にわたる１組の制約である。
【００２１】
本発明の好ましい実施形態は、ビットストリームを変換するのに２段階の手法を用いる。受信インターフェース・カード上の第１の有限状態機械が、入ってくるビットストリームを該ビットストリームのアプリケーション・プロトコルの多次元マトリックス表示に変換するために用いられる。第２の有限状態機械が、アプリケーション・プロトコルの多次元マトリックスを中間表示の多次元マトリックスに変換するために用いられる。
【００２２】
中間表示の多次元マトリックスは、宛先インターフェース・カードに送られる。宛先インターフェース・カードは、中間表示の多次元マトリックスをアプリケーション・プロトコルの多次元マトリックスに変換するために用いられる第１の有限状態機械を有する。第２の有限状態機械は、アプリケーション・プロトコルの多次元マトリックスをアプリケーション・プロトコルのビットストリームに変換するために用いられる。次に、アプリケーション・プロトコルのビットストリームは、コンピュータ・システムに送られる。
【００２３】
本発明の別の好ましい実施形態は、複合有限状態機械を用いる。複合有限状態機械は、最初の通信プロトコルから直接本発明の中間表示に変換する。受信インターフェース・カード上の有限状態機械は、入ってくるビットストリームを中間表示の多次元マトリックスに変換するために用いられる。
【００２４】
中間表示の多次元マトリックスは、宛先インターフェース・カードに送られる。宛先インターフェース・カードは、中間表示の多次元マトリックスをアプリケーション・プロトコルのビットストリームに変換するために用いられる有限状態機械を有する。次に、アプリケーション・プロトコルのビットストリームは、コンピュータ・システムに送られる。
【００２５】
本発明の他の態様及び利点は、例として本発明の原理を示す添付部面と併せて以下の詳細な説明から明らかになるであろう。
【００２６】
（発明を実施するための最良の形態）
本発明は、適応マルチプロトコル通信において具体化される。本発明によるシステムは、多数のアプリケーション・プロトコル間で通信し、ｎ個まで必要とされる変換プロセスの数を減少させるハードウェア統合システムを提供するものである。さらに、本発明は、付加的なアプリケーション・プロトコルを適合させるように、ユーザがシステムを容易に拡張することを可能にするモジュラーシステムを提供するものである。
【００２７】
マルチプロトコル・ネットワーク・ルータが、如何なる物理及びネットワーク・プロトコルとも通信するハードウェア・コンポーネントを適合させることができると同時に、本発明は、如何なるアプリケーション・プロトコルとも通信するハードウェア・コンポーネントを適合させる統合システムを提供する。本発明によるアプリケーション・プロトコルは、データ・プロトコル、データ・フォーマット、データ・スキーマ、要求・応答意味規則、アプリケーション間の同時性意味規則、及びアプリケーション間のトランザクション処理意味規則のような、アプリケーション層において考慮される際の用語プロトコルの一般的な解釈が意味する別個の相互に関係する概念の全てを含む。
【００２８】
図２に関して、本発明は、複数のインターフェースを含む。各々のインターフェースは、１つ又はそれ以上のネットワーク・ストリーム２０１を受け入れる単一のコンピュータ・インターフェース・カードからなる。ネットワーク・ストリームは、有限状態機械２０２に与えられる。この有限状態機械２０２は、ネットワーク・ストリーム２０１上で作動し、中間仮想表示２０４を作成する。有限状態機械２０２の作動は、以下に詳述される。中間仮想表示２０４は、例えばＥＤＩ、ＸＭＬのような特定のアプリケーション・プロトコル、又は本発明の中間仮想変換表示のいずれかに特有なものとしてもよい。
【００２９】
中間仮想表示２０４を適切に作成するために、有限状態機械２０２によってルックアサイド・バッファ２０３を用いることができる。幾つかのデータ交換演算の場合には、有限状態機械２０２は、正しい値を中間表示２０４内に配置するために、前のストリーム値を見返すことができなければならない。ルックアサイド・バッファ２０３は、前のストリーム値又は１つ又はそれ以上の前のストリーム値から生成された複合値を含み、これらは、有限状態機械２０２によってルックアサイド・バッファ２０３内に配置され、引き続き該ルックアサイド・バッファ２０３から読み取ることができる。ルックアサイド・バッファ２０３及び中間表示２０４が同じインターフェースにまとめて配置された場合には、該ルックアサイド・バッファ２０３又は該中間表示２０４のいずれかを多数の有限状態機械２０２の中で共有することができる。
【００３０】
有限状態機械２０２は、適切な中間仮想表示２０４を作成するために、特定のアプリケーション・プロトコルのために特に作成される。以下に説明されるように、中間仮想表示２０４は、引き続いて、別のインターフェース又は別の有限状態機械によって用いられる。さらに、本発明は、別のインターフェース又は別の有限状態機械のいずれかによって次に使用される前に、中間仮想表示２０４についての複数の明確な演算を実行することができる。
【００３１】
図３を参照すると、２進数のシーケンスが、インターフェース上に配置されたネットワーク・インターフェース・カード（ＮＩＣ）３０１から出てくる。２進数は、有限状態機械３０２によって多次元スキーマ・マトリックス３０３にマッピングされる。この例において、ソース・プロトコルはＥＤＩであり、宛先プロトコルはＸＭＬである。当業者であれば、この例のＥＤＩ及びＸＭＬプロトコルを何らかの２つのアプリケーション・プロトコルに同等に置換え得ることをすぐに理解するであろう。
【００３２】
多次元スキーマ・マトリックスは、一般にスキーマと呼ばれるアプリケーション・プロトコルと、構造がこのようなアプリケーション・プロトコルに準拠する、一般に値と呼ばれるデータの両方についての構造上の特徴を表す。スキーマ・マトリックスの好ましい実施形態が、以下に説明される。
【００３３】
ＥＤＩマトリックス３０３は、有限状態機械３０４に送られる。この有限状態機械３０４は、ＥＤＩマトリックス３０３を本発明の中間変換仮想表示マトリックス３０５に変換する。仮想表示マトリックス３０５は、例えばスキームをマッピングするメモリを用いて、相互接続を介して宛先側のインターフェース・カードに転送される。
【００３４】
仮想表示は、カードが宛先プロトコルを知る必要なしに、いずれかのコンピュータ・インターフェース・カードが、いずれかの他のコンピュータ・インターフェース・カードにデータを転送することを可能にする。コンピュータ・インターフェース・カードを、他のコンピュータ・インターフェース・カードに通信可能に接続することができ、仮想表示マトリックスを転送データに自由に交換することができる。
【００３５】
宛先側の有限状態機械３０７は、仮想表示マトリックス３０６のコピーを読み取る。以下に説明されるように、相互接続は、有限状態機械３０７が、例えばゼロコピー通信スキームを用いて、コピーすることなく中間仮想表示マトリックス３０５を直接使用するための手段を提供することができる。有限状態機械３０７は、マトリックス３０６をＸＭＬ多次元マトリックス３０８に変換する。ＸＭＬ多次元マトリックス３０８は、有限状態機械３０９に送られる。この有限状態機械３０９は、ＸＭＬマトリックス３０８をＸＭＬバイトストリームに変換し、該ＸＭＬストリームをＮＩＣ３１０に流す。
【００３６】
図４に関して、本発明の好ましい実施形態が、複合有限状態機械を用いる。複合有限状態機械は、通信プロトコルと本発明の中間仮想表示の間を直接変換する。例えば、ＮＩＣ４０１は、ＥＤＩストリームを有限状態機械４０２に送る。有限状態機械４０２は、最初のＥＤＩから単一の中間仮想表示マトリックス４０３までマッピングする。
【００３７】
宛先側の有限状態機械４０５は、仮想表示マトリックス４０４のコピーを読み取る。次に、有限状態機械４０５は、仮想表示マトリックス４０４をＸＭＬストリームに変換し、該ＸＭＬをＮＩＣ４０６に流す。
【００３８】
中間仮想表示マトリックス４０３から中間仮想表示マトリックス４０４まで変換するために用いられる１つ又はそれ以上の特定の中間と中間の間の変換方法は、本発明の属性とは考えられない。
【００３９】
図５を参照すると、本発明は、有限状態機械５０１をルックアサイド・バッファ５０２と組み合わせて、スキーマ・マトリックス５０５を作成する。上述のように、有限状態機械は、特定の通信プロトコルのために作成される。ユーザが、有限状態機械の交換又は変換プロセスに修正及びカスタマイゼーションを必要とする場合には、本発明は、ユーザに構成テーブル５０３及び例外テーブル５０２を提供し、有限状態機械の動作を調整する。
【００４０】
ユーザにより直接的又は間接的に特定された要求、又は有限状態機械５０１により処理される演算の特性に基づいて、各々の有限状態機械５０１を任意に修正又はカスタマイズすることができる。構成テーブル５０３は、入ってくるバイトストリーム５０６上で有限状態機械５０１がどのように作動するかをユーザが判断することを可能にする。当業者であれば、ユーザが、修正又はカスタマイゼーションに関するこのような命令をどのように提供するかについてのプロセスは、本発明を定義する属性ではないことを理解するであろう。
【００４１】
例外テーブル５０４は、マトリックス５０５の多次元領域にわたる１組の制約であると共に、制約に違反した際に取るべき任意の組の対応する動作である。例外テーブル５０４の図示された例のように、入ってくるバイトストリームにスキーマ・マトリックス５０５と両立性のある正しい構文を使用させるために、この制約を有限状態機械５０１による規則として用いることができる。
【００４２】
上記は、本発明を定める属性を構成する。本発明の好ましい実施形態が、ここに説明される。
【００４３】
図６を参照すると、本発明の好ましい実施形態は、適応マルチプロトコル通信システムによって、多くの異なる方法で具体化することができる。一例として、システム６０１は、異なるアプリケーション・プロトコル６０６、６０７を用いて、コンピュータ・システムに適合させるマルチプロセッサ・システムを提供する。本発明は、１つ又はそれ以上の宛先コンピュータ・システム６０３に接続しながら、１つ又はそれ以上のソース・コンピュータ・システム６０２に接続する。各々のソース・コンピュータ・システム６０２は、１つ又はそれ以上のアプリケーション・プロトコル６０６を使用し、各々の宛先コンピュータ・システム６０３は、１つ又はそれ以上のアプリケーション・プロトコル６０７を使用する。不必要な詳細を減少させるのが通例なので、この中に内在する多くのコンポーネント及び電気接続、並びに後続するブロック図は示されない。
【００４４】
各々のソース及び宛先コンピュータ・システム６０２、６０３は、インターフェース６０４を介してシステム６０１に接続する。以下に説明されるように、各々のインターフェース６０４は、多くの別個の部品から構成される。複数のインターフェース６０４は、内部の相互接続６０５を介して直接通信し合うことができる。インターフェース６０４がソース及び宛先コンピュータ・システム６０２、６０３と通信する方法に加えて、インターフェース６０４が相互接続６０５を介して通信し合う方法は、このシステムを定義する属性でない。当業者であれば、相互接続６０５が、各々のインターフェース６０４の間の電気的接続を助けるように働き、よって、該相互接続６０５は、こうした電気的接続を助ける何らかの別個の組又は複合の組のコンポーネントで構成されることを理解するであろう。
【００４５】
ソース及び宛先コンピュータ・システム６０２、６０３は、別個のエンティティとして図６に示されるが、本発明の好ましい実施形態は、ソース及び宛先コンピュータ・システム６０２、６０３の両方として働く単一のコンピュータ・システムも同等にサポートすることができる。システム６０１に接続する１つ又はそれ以上のソース・コンピュータ・システム６０２又は宛先コンピュータ・システム６０３は、２つ又はそれ以上のアプリケーション・プロトコルを用いて同時に接続することができる。１つ又はそれ以上のソース・コンピュータ・システム６０２又は宛先コンピュータ・システム６０３は、同じアプリケーション・プロトコルを用いて２つ又はそれ以上の交換を同時に行うことができる。ソース又は宛先コンピュータ・システム６０２、６０３、及びインターフェース６０４を接続する各々のアプリケーション・プロトコル６０６、６０７は、単方向性又は双方向性としてもよく、またユニキャスト又はマルチキャストとしてもよい。
【００４６】
図７を参照すると、各々のインターフェース７０４上に実装された１つ又はそれ以上の有限状態機械７０３の観点を中心とした、本発明に焦点を当てた図６の拡大図が示される。本発明のインターフェースの各々は、有限状態機械７０３を用いて交換される中間仮想表示のデータを効率的に生成し、該中間仮想表示のデータは、共通の中間仮想表示７０４を用いて相互接続にわたってインターフェース間で通信される。中間仮想表示は、異なるアプリケーション・プロトコル7０１、7０２を用いて、コンピュータ・システムの間でデータを交換するのに用いられる。
【００４７】
図６及び図７は、本発明により実行されるデータ交換にｎ回の変換プロセスだけが必要とされる理由を示す。具体的には、交換についてのｎ回のプロセスの最大限度は、２つの理由により生じる。第１に、適切な有限状態機械７０３を介して、何らかのアプリケーション・プロトコル６０６、６０７を中間仮想表示７０４に変換することができる。第２に、所定のアプリケーション・プロトコルについての有限状態機械７０３及び対応する中間仮想表示７０４は、本発明への入力（アプリケーション・プロトコル７０１、７０２から中間仮想表示７０４へ）及び本発明からの出力（中間仮想表示７０４からアプリケーション・プロトコル７０１、７０２へ）の両方と同等である。
【００４８】
本発明が、共用ネットワークを介して本発明によりアクセス可能な、全てのアプリケーション・プロトコル６０６、６０７の間の交換に対してサポートを提供する拡張可能なハードウェア・アーキテクチャを定めるので、本発明は、非公式に、ユニバーサル統合プラットフォーム（ＵＩＰ）と呼ばれる。本発明は、各々がネットワーク接続を介して本発明とインターネットワーク化された状態で、如何なる数の任意のコンピュータ・システム（ソース及びターゲット・コンピュータ・システム６０２、６０３のような）の間でのデータ交換プロセスを実行する。さらに、コンピュータ・システムが共通の共用ネットワークを介してインターネットワーク化された場合、私的なイントラネットに配置されようと公的なインターネットに配置されようと、本発明は、任意のコンピュータ・システムについてのこれらの能力をサポートする。本発明の装置は、例えば交換／経路指定ネットワーク又はインターネットにわたる、直接ネットワーク接続により提供されるものと論理的に同等な接続を提供する何らかのネットワークを介して、如何なるコンピュータ・システムにも接続することができる。アプリケーション・プロトコル６０６、６０７、７０１、及び７０２は、本発明の装置と任意のコンピュータ・システムとの間のこれらのネットワーク接続にわたって運ばれる。
【００４９】
その際に、本発明は、
本発明内に内蔵して、又は既成のアプリケーション・プロトコルによる遠隔呼び出し機能を介して任意のコンピュータ上に外付けして、任意の計算演算の実行を助けるプログラム可能な計算システムのためのハードウェア実装を提供する。したがって、本発明は、交換されるデータにわたって任意の論理変換を実行するように動的に構成することができるので、物理及びネットワーク層プロトコルを実装するコンピュータ・ハードウェアとさらに異なる。当業者であれば、本発明は、汎用プログラミング言語を用いて特定することができる如何なる変換もサポートし得ることを理解するであろう。これらの一般化された論理変換が、以下に与えられる。この一般性及び拡張性は、その主要な機能が一般的にプログラム可能ではないネットワーク・ルータ及びスイッチと異なるものである。
【００５０】
参照として上述されたＯＳＩネットワーク・モデルを用いると、本発明は、多数のアプリケーション層プロトコルをサポートする、セッション層（層５）及びそれ以上の層におけるデータ及び計算論理に影響を及ぼす統合方法を実行する能力に関係する。さらに、本発明は、それ自体とＯＳＩ層１−４の外部の計算システムとの間の相互関係について、物理ネットワーク接続（ＰＮＣ）が本発明と複数の計算システムとの間に確立される必要がある、という単一の仮説だけを立てる。当業者であれば、例えばコネクション・オリエンテッドか、コネクションレスかといったＰＮＣの属性が、本発明を定義する属性ではないことを理解するであろう。
【００５１】
したがって、このようなＰＮＣ及び内部に固有のＯＳＩ層１−４に対するプロトコル・スタック操作がどのように確立され、複数の外部の計算システムに保持されるかについての意味規則及び実装の詳細は、本発明には関連しないと考えられる。同様な意味合いで、こうした装置は、物理的ネットワーク・ケーブルを介して、外部のコンピュータ・システムに物理的に接続される。こうした接続が存在する場合、正確にどのように実装されるかは、本発明に関係するものではない。
【００５２】
本発明の装置の観点から、各々のＰＮＣは、双方向性のネットワーク通信抽象化によって、抽象ネットワーク接続エンドポイントとして、プログラマチックにモデル化される。このネットワーク通信抽象化についての好ましい実施形態は、ネットワーク・ソケットである。このソケットは、２つのコンピュータ・システム間の双方向のＩ／Ｏ容量をモデル化するネットワーク・プログラミングに用いられる普及している抽象化である。ソケット抽象化により具体化されるこうしたネットワーク通信抽象化を用いることは、本発明が特定の属性をもつＰＮＣプロトコル・タイプ又は実装機構から独立したままであること、すなわち言い換えるとこれらに依存しないままであることを保証する。したがって、本発明は、ルータ及びスイッチのようなシステムにより実行されるような、物理及びネットワーク・プロトコルの処理から独立している。
【００５３】
本発明の１つの好ましい実施形態は、密結合された非対称のマルチ計算、マルチ処理装置を介して、複数のアプリケーション・プロトコルの間でデータ交換を実行する。全てのコンポーネントが、物理的に単一のエンクロージャ内に含まれるので、こうした装置は、閉鎖結合と定義される。こうしたエンクロージャが、物理的に独立した多数のシングル・ボード・コンピュータ（ＳＢＣ）の挿入をサポートするので、この装置は、マルチ計算と定義される。各々のＳＢＣが、多数の中央演算処理装置（ＣＰＵ）を含むことができるので、この装置は、さらにマルチ処理と定義される。このようなものを、ＡＳＩＣ、ＥＰＧＡ、又はネットワーク・プロセッサのような特定用途向けプロセッサとしてもよいので、各々のＣＰＵは、汎用ＣＰＵである必要はない。図６のインターフェース６０４の各々は、ＳＢＣ上で具体化される。当業者であれば、インターフェースとＳＢＣとの間の対応が、本発明を定義する属性ではないことを理解するであろう。
【００５４】
各々のＳＢＣは、専用の高速相互接続を介して相互接続される。この専用の相互接続は、図２の相互接続２０５の役割を果たす。当業者であれば、この専用の相互接続は、ＳＢＣ間の電気的接続を助ける何らかの物理的コンポーネント（一般に、バックプレーン又はバスと呼ばれる）によって具体化できることを理解するであろう。代表的な例には、共用バス、交換バス、統合されたスイッチ、交換ファブリック、又は１つ又はそれ以上の特殊ブリッジ・チップが含まれる。
【００５５】
この装置を定義する重要な特性は、ＳＢＣが、プログラマチックに独立していることである。同様な意味合いで、各々のＳＢＣは、ＣＰＵごとに１つの独立したコンピュータ命令のストリームを実行し、独立したランダム・アクセス・メモリ（ＲＡＭ）を利用する。本発明の適合性及び拡張性は、部分的にはこのＳＢＣの独立性から生じ、このことは、本発明の機能が、本発明に挿入される個々のＳＢＣによって定められることを可能にする。例えば、ＳＢＣｍのＣＰＵｎは、プロセッサの直接アドレス指定を介して、ＳＢＣｍ以外の他のＳＢＣのＲＡＭにアクセスすることはできない。こうしたＳＢＣを含み、相互接続を提供するために、各々が様々な数のこれらの計算ユニットを含み得る種々のエンクロージャを利用することができる。
【００５６】
性能の実行可能性及び同時マルチ処理のような本発明の多くの属性は、各々のアプリケーション層プロトコル（ＡＬＰ）についてのデータ交換演算の各々が、単一の専用ＳＢＣによって処理されるという設計要因に依存する。ＳＢＣとアプリケーション・プロトコルの間の結合のため、ＳＢＣは、同様な意味合いで、本明細書においてはＡＬＰ論理アダプタ（ＡＬＡ）と呼ばれる。
【００５７】
同様な意味合いで、本発明の利点は、このような非対称型アーキテクチャに依存しており、このような非対称性をもたないシステムを用いて達成することはできない。したがって、この装置は、各々のＣＰＵが汎用プロセッサである一般的な対称型マルチ計算及びマルチ処理機械（一般にＳＭＰ、ＮＵＭＡ、又は同等物と呼ばれる）とは著しく異なる。こうした対照的な設計において、ＣＰＵは、作動システム及び該システム上で実行するアプリケーション層ソフトウェアの観点からすると、大部分は交換可能である（幾つかの場合においては、区別できるが）。したがって、各々のＣＰＵは、データ交換機能を実行するように計画された確実な確率的可能性を有し、或いは、そこにおいて特定のＣＰＵ及びＳＢＣへのプログラマチック・タスクの割り当ては、プロセス計画、又は他のアプリケーション層ソフトウェア・プログラミングを介して、マシンのユーザにより特定される。
【００５８】
単に特定のハードウェア・アーキテクチャを超えて、本発明は、機能がどのように部品に分解され、これに応じてこうした装置内のＳＢＣによってどのように実行されるかに密接に依存している。装置内のＳＢＣの各々は、単一の特定の明確な組の能力を実行する。ＵＩＰは、一般的にアダプタと呼ばれる２つの別個のカテゴリー・タイプのこうしたＳＢＣ、すなわち（１）プログラム可能な解釈用アダプタ、及び（２）ＡＬＰ論理アダプタを含む。この拡張可能なマルチプロトコル統合システム内のＰＩＡ及びＡＬＡ ＳＢＣの設計及び目的は、ブロックを構築する柔軟な機能特定のコンポーネントと同様である。
【００５９】
図８、図９、図１０及び図１１に関して、多数のアダプタ（ＳＢＣ）８０３、８１６、８１７、８１８、８１９を有する本発明のコンポーネント・レベル図の例示的な図が示される。ＳＢＣ８０３、８１６、８１７、８１８、８１９は、コンパクトな共用周辺機器コンポーネント・インターフェース（コンパクトＰＣＩ）・バス・バックプレーン８００を介して、内部に相互接続される。上述のように、この好ましい実施形態のコンパクトＰＣＩバス・バックプレーンを、共用バス、交換バス、統合されたスイッチ、交換ファブリック、又は１つ又はそれ以上の特殊ブリッジ・チップのような、同等の電気機能を提供するハードウェア・コンポーネントで、同等に置き換えることができる。
【００６０】
個々のアダプタの各々は、任意のネットワーク・ケーブル８１０を介してユーザ８１１による接続をサポートするネットワーク・ファブリック８１３に外部８０９から接続されるか、又は単一のＬＲＣＳ８１２、８２６、８２７、８２８に外部から接続されており、各々のアダプタは、独立した別個のネットワーク・ファブリック８３３、８２９、８３０、８３１を介してＬＲＣＳに外部から接続され、アダプタとＬＲＣＳとの間に同時接続を与える。ネットワーク・ファブリックという用語は、ここでは、スイッチ又はルータのような任意の中間ブリッジング・システムを用いてネットワーク・ケーブルを介して与えられる何らかの電気的接続を意味するように定義される。
【００６１】
ユーザ８１１に接続する８０３により識別されるように、アダプタ８０３は、プログラム可能な解釈アダプタ（ＰＩＡ ＳＢＣ）である。ＳＢＣ８１６、８１７、８１８、８１９は、それぞれＬＲＣＳ８１２、８２６、８２７、及び８２８に接続する各々のＳＢＣによって識別されるような、ＡＬＰ論理アダプタである。これらのアダプタの内蔵コンポーネントは、アダプタ８１６のものと実質的に類似しているので、明確にするために、アダプタ８１７、８１８、８１９についての詳細は省略されることに注意されたい。
【００６２】
好ましい実施形態において、各々のＳＢＣは、アダプタの各々とバックプレーン８００との間に電気的接続をもたらすＰＣＩインターフェース８０１、８０２を介して、バックプレーン８００に挿入される。同様な意味合いで、各々のＳＢＣの間に電気的接続をもたらす機構は、相互接続の属性によって決まる。例えば、幾つかの相互接続タイプは、電気的接続の挿入に依存せず、寧ろネットワーク・ケーブルの使用に依存する。ＰＣＩインターフェース８０１は、現在ＳＢＣが中に挿入されていない空のＰＣＩインターフェースである。ＰＣＩインターフェース８０２は、アダプタ８０３をバックプレーン８００に挿入することによりもたらされる空でないＰＣＩインターフェースである。将来付加的なＳＢＣを挿入する可能性を有した状態で、ＰＣＩインターフェース８０１内にＳＢＣがないことは、本発明の拡張性の基礎となる。将来の如何なる時点においても、付加的な容量又は能力を与えるために、付加的なＳＢＣ（図示されないが、ＰＣＩインターフェース・バスの消費電力と一致する）をＰＣＩインターフェース８０１に挿入することができる。
【００６３】
ＰＣＩバスは、１つから数ダース又はそれ以上の範囲にわたる広範な量のアダプタをサポートすることができる。さらに、このコンテクストにおけるアダプタとみなすのに必要な機能を実装する、ｉｎｔｅｌ Ｐｅｎｔｉｕｍ及びＳｕｎ Ｓｐａｒｋ ＳＢＣのようなＰＣＩバス・アーキテクチャと両立性のある様々な計算装置が存在する。このように、このようなアダプタの正確な数及び物理的ブロックの仕様書は、本発明の実施形態の属性と考えるべきではなく、本発明を定義する属性ではない。しかしながら、ＰＣＩバスと両立性のあるアダプタのタイプの幅広さは、本発明により与えられる適合性及び拡張性の固有の柔軟性を例証するものである。
【００６４】
ＳＢＣ８０３、８１６、８１７、８１８、８１９は、ＣＰＵ８０７、ＲＡＭ８０６、持続性記憶装置８０５、及びコンパクトＰＣＩアーキテクチャに用いる他の暗に含まれるボードレベル・コンポーネントのいずれかの一般的な組み合わせから構成することができる。さらに、図８に示されるようなブロック図を実質的に修正することなく、わずかな数のＣＰＵ８０７（一般的には、４又はそれより少ない）を単一のＳＢＣ上に適合させることができるので、各々のＳＢＣ上のプロセッサの数は、単に実施形態の詳細である。この実施形態の場合には、各々のＳＢＣは単一のＣＰＵである。その正確な寸法、タイプ、及びタイミングは、本発明の実施に関係しないので、ＲＡＭ８０６及び持続性記憶装置８０５の寸法及びタイプもまた、実施形態の詳細である。
【００６５】
本発明により定められる別個のタイプのＳＢＣアダプタ、すなわちＰＩＡ及びＡＬＡの両方が、図８に示される。ＲＣＳ８１１へのネットワーク接続８１０により識別されるＳＢＣ８０３は、ＰＩＡアダプタである。それぞれＬＲＣＳ８１２、８２６、８２７、８２８へのネットワーク接続８３２、８２０、８２２、８２４により識別される、ＳＢＣ８１６、８１７、８１８、８１９は、ＡＬＡアダプタである。
【００６６】
実施形態における幾つかの共通点が、ＰＩＡアダプタ８０３とＡＬＡアダプタ８１６、８１７、８１８、８１９との間に存在する。具体的には、ＰＩＡアダプタ及びＡＬＡアダプタは、高性能のＣＰＵ９０７、９１５を高性能のネットワークＩ／Ｏ（この例においては、イーサネット（Ｒ））９０７と結びつける共通のアーキテクチャ、すなわちＣＰＵ及びネットワークＩ／Ｏ指向のＳＢＣを共有する。ＣＰＵ９０７及び９１５は、明示的に区別され、ＣＰＵのタイプ、速度、及び他の実行属性が、本発明の機能に影響を及ぼすことなく、ＳＢＣ間で実質的に異なり得ることをはっきりと例示する。この例において、ＣＰＵ９０７、９１５は、質的に類似し、同じアーキテクチャに基づいており、ＳＢＣによって処理されるＡＬＰの複雑さに基づいた異なる速度だけを用いている。さらに、同じ理由から、ネットワークＩ／Ｏ９０７は、各々のＳＢＣについて異なることがあるが、この実施形態においては、図を簡単にするために、全てのネットワークＩ／Ｏ９０７が、イーサネット・コンポーネント及び１０／１００ベースＴネットワーク・アダプタ８０９で構成されている。計算ＳＢＣに必要なように、各々のアダプタは、ＲＡＭ９０６及び持続性記憶装置９０５も含む。同じ理由から、当業者であれば、持続性記憶装置を、従来のハードディスク（磁気物理的回転特性に基づいた）、又はフラッシュ・メモリのようなソリッドステート装置のいずれかにしてもよいことを容易に理解するであろう。いずれの場合においても、持続性記憶装置８０５は、本発明より必要とされるソフトウェア・コード及びデータのための持続性記憶装置を提供する。さらに、当業者であれば、持続性記憶装置の寸法、アクセス速度、及び他の作動パラメータが、本発明の実施に直接関係しないことを理解するであろう。
【００６７】
本発明により与えられる能力を呼び出す目的を有するＰＩＡ及びＡＬＡ ＳＢＣアダプタ８０３、８１６、８１７、８１８、８１９の双方は、上述のような各々の接続についての制約に従って、複数のＬＲＣＳの８１１、８１２、８２６、８２７、８２８とのネットワーク接続により識別される。代表するものとして単一のＳＢＣの接続を考えると、ＳＢＣ８０３は、ネットワーク接続８１０を介してこうしたユーザ８１１に接続し、該ネットワーク接続８１０は、挿入プラグ８０９を介してＳＢＣ８０３に物理的に挿入される。ネットワーク接続８１０は、任意の組の交換又はブリッジされたネットワーク接続（まとめて、ネットワーク・ファブリック８１３と呼ばれる）を介して、ユーザ８１１に接続される。
【００６８】
本発明は、ＰＩＡ ＳＢＣについてのｎ方向の接続、及び各々のＡＬＡ ＳＢＣアダプタについての２方向の接続を最小限必要とする。ＰＩＡ ＳＢＣは、各々のＡＬＡアダプタと双方向に通信することができるが、ＡＬＡアダプタは、互いの間で通信し合うことを最小限必要としているわけではない。しかしながら、この実施形態は、この最小限の要件を一般化し、ｎ方向の接続、又は全てのアダプタ（ＰＩＡ及びＡＬＡ）についてＳＢＣｉがＳＢＣｊと通信する能力（ここで、ｉ≠ｊ）をサポートする。好ましい実施形態において、この一般化は、各々のＳＢＣ上に配置されるか、又は相互接続内に組み入れられた（この例においては、コンパクトＰＣＩ・バックプレーン）ＰＣＩ間のブリッジ・チップ（ＰＢＣ）を組み込むことから生じる。
【００６９】
図１０は、コンパクトＰＣＩ相互接続を用いる好ましい実施形態に特有の、ＰＣＩ間ブリッジ・チップ（ＰＢＣ）及びバックプレーンに関連する図８及び図９のサブセットを示す。以下は、好ましい実施形態の属性であるので、本発明を定義する属性と考えるべきではない。以下に定められるように、例えば、Ｉｎｆｉｎｉｂａｎｄのようなアイソメトリックな交換ファブリックは、従来のＰＢＣに依存せず、「マスター」と「スレーブ」の間も区別しない。ＰＢＣ８０４は、ＰＩＡ ＳＢＣ８０３上に配置されたトランスペアレントでないＰＢＣであり、９０１を介してバックプレーン８００上のＰＣＩインターフェース８０２に電気的に接続される。ＰＢＣ８１４は、トランスペアレントなＰＢＣであり、ＡＬＡ ＰＢＣごとに１つあり、９１０を介してＰＣＩインターフェース８０２に電気的に接続される。
【００７０】
好ましい実施形態において、ＰＩＡ ＳＢＣは、バス・マスタ装置（コンパクトＰＣＩの好ましい実施形態のシャシー内で、「マスター」又は「システム」ＳＢＣと呼ばれる）として電気的に働くことができ、よって、取り付けられたＰＣＩの外部周辺機器の列挙を制御し、トランスペアレントでないＰＣＩ間ブリッジを使用する。ＡＬＡ ＳＢＣは、それらがＰＣＩ信号において「スレーブ」又は「周辺機器」の役割を実行するので、バスの干渉を防ぐためにトランスペアレントなＰＣＩ間ブリッジを用いる。ＰＩＡ及びＡＬＡ ＳＢＣ ＰＢＣは、ＰＣＩバス・アーキテクチャに対する標準的な動作を実行する。
【００７１】
上述のように、本発明は、抽象ネットワーク接続、及びエンドポイント間に双方向のネットワーク通信を提供する通信抽象化に依存する。この抽象化の好ましい実施形態は、各々のＳＢＣアダプタ間の通信用のプログラマティック・イディオムを特定するためのネットワーク・ソケット抽象化である。別の好ましい実施形態は、ＵＩＰにおける１つ又はそれ以上のＳＢＣからの物理的メモリから構成される論理的にフラットなメモリ空間にわたって、ネットワーク接続及び通信抽象化をエミュレートすることにより同等の抽象化を提供する、分散型共有メモリとすることができる。
【００７２】
ＰＢＣ９０４及び９１４は、バス・タイミング、信号、及び他の電気的バス指向演算における機能を定義する。したがって、その抽象化が、如何なる機能のバス指向演算も含まない双方向性の通信経路に依存するので、ＰＢＣ／バックプレーンの実装は、必要とされるソケット抽象化を提供するのに適していない。
【００７３】
図１１は、シミュレーション・プロセスに含まれる主要なコンポーネントを示す。不必要な詳細を減らすのが通例であるので、このブロック図に暗に含まれる多くのコンポーネント及び電気的接続は図示されていない。こうした抽象化を達成するために、各々のＳＢＣ上のＣＰＵ８０７及びＰＢＣ８０４は協働し、装置ドライバ・ソフトウェアを用いてソケットをシミュレートする。こうした装置ドライバ・ソフトウェアは、持続性記憶装置８０５から、ＣＰＵ８０７上で動作するオペレーティング・システム・カーネルに用いるためのＲＡＭ８０６に読み込まれる。装置ドライバには普通にあることだが、ドライバは、ＣＰＵ８０７上のＯＳの起動シーケンス中にカーネルに読み込まれる。ネットワークのシミュレーションは、ＰＣＩインターフェース８０２を介してソケット要求をバックプレーン８００上のＰＣＩバス演算に、またその逆に変換するＣＰＵ８０７上の装置ドライバによって実行される。
【００７４】
データ値は、ＰＢＣ８０４、ＣＰＵ８０７、及び直接メモリーアクセス（ＤＭＡ）１１０３の間の協働によってＲＡＭ８０６内に配置される。データが、ＰＣＩインターフェース８０２を介してバックプレーン８００に読み取られる場合には、ＰＢＣ８０４及びＣＰＵ８０７上の装置ドライバが協働して、バス信号をソケット読取演算に変換し、ＤＭＡ１１０３を介してその読取演算の結果をＲＡＭ８０６内に移動させる。同様に、ＰＣＩインターフェース８０２を介するバックプレーン８００へのソケット書き込みについての逆の演算も生じる。
【００７５】
当業者であれば、ＳＢＣ接続について他の幾つかの技術が知られていることを容易に理解するであろう。例えば、同じ機能の実施形態が、外部のイーサネット・アダプタを介して各々のＳＢＣをイーサネット・スイッチに接続することにより可能になる。したがって、各々のカード間にｎ方向の電気的接続が存在し、イーサネット・スイッチ（図示せず）及びＳＢＣイーサネット・チップ９０７が、ＰＢＣ８０４、８１４、及びバックプレーン８００と同じ機能的役割をもたらす。この例において、イーサネット・チップ９０７は、ライブ・ネットワークスタックを実装し、ここで、ＰＢＣが用いられる場合には、代わりにＣＰＵ８０７、８１５が、同じ機能のネットワークスタックをシミュレートする。別の例として、相互接続は、ＤＭＡ１１０３又はＣＰＵ８０７を含むことなく、或いはこれらと協働することなく、ソースＲＡＭ８０６から、異なるＳＢＣ上の１つ又はそれ以上のＲＡＭ８０６への直接処理として実装された、シミュレートされたネットワーク通信演算を自律的に実行する。
【００７６】
本発明上で動作する内蔵されたコンピュータ・ソフトウェア（ファームウェア）が、この拡張可能な非対称型マルチ計算装置を用いて、以下に説明される抽象ＰＰＦモデルをプログラマチックに実行する。本発明は、ソケット・ネットワーク抽象化のようなプログラマチック構成の利用可能性に対する特定の要求を満たす抽象プログラミング・システムに依存する。したがって、これらの条件を満たす一般に使用されているプログラミング言語は、ここに定められる必要とされる最小の機能を実装することができる。当業者であれば、１つ又は１組のＡＳＩＣ、ＦＰＧＡ、或いは本発明の中の同様の機能のシリコン・コンポーネントによって、以下に説明される次の抽象的ＰＰＦモデルを同様な意味合いで実行できることもすぐに理解するであろう。したがって、抽象的ＰＰＦが、ファームウェア、シリコン・コンポーネント、又はその組み合わせとして実行されるかどうかは、本発明を定義する属性ではなく、実施形態の属性である。
【００７７】
マルチプロトコル統合システムを具体化する好ましい実施形態の装置のハードウェア・コンポーネントについて説明したが、その構造及び相互依存性についての観察を明らかにすることができる。当業者であれば、装置内の個々のＳＢＣが、以下の説明に著しく影響を及ぼすことなく、プログラム可能な解釈アダプタ及びＡＬＰ論理アダプタの両方の機能を組み合わせ得ることを理解するであろう。組み合わせられたこのようなアダプタは、両方のタイプのアダプタの機能の組み合わせを提供する。本発明の装置の特定の例の中に、如何なる数のプログラム可能な解釈アダプタ又はＡＬＰ論理アダプタも含むことができる。したがって、本発明におけるアダプタの量及び混合は、本発明の実施形態の属性と考えるべきであり、本発明を定義する属性と考えるべきではない。こうした多数のアダプタの詳細及び解釈は、以下のように定められる。
【００７８】
図１２に関して、多数のアダプタ（ＳＢＣ）１２０２、１２０７と共に、本発明のアダプタ・レベル図の例示的な図が示される。この装置におけるプログラム可能な解釈アダプタ（ＰＩＡ ＳＢＣ）１２０２の各々は、ＵＩＣ内の機能の実行を制御する機能を実装する。各々のＰＩＡ ＳＢＣは、管理、事務管理、構成、又は装置のユーザにより必要とされるような如何なる類似した機能も提供することができる。構成のために、ＰＩＡ ＳＢＣの実施形態が以下に説明される。
【００７９】
既存のシステムと対照的に、各々のＰＩＡ ＳＢＣ１２０２は、ＡＬＰに固有のソフトウェア命令を実行しない（以下に説明されるように、ユーザ１２０４が、ＲＦＣ８５４又はＲＦＣ２０６８のようなＰＩＡ ＳＢＣ１２０２にアクセスすることを必要とするアプリケーション・プロトコルの潜在的排除を用いて）。したがって、上述のように、ＰＩＡ ＳＢＣ１２０２は、こうしたユニバーサル統合プラットフォームに必要な特性を実行するのに必要とされる、必要管理又は仲介機能を実行する。装置のユーザ１２０４は、ＰＩＡ ＳＢＣ１２０２とのＰＮＣ１２０６を確立することによって、ＵＩＣ１２０１から機能を要求し、受け取る。
【００８０】
マルチプロトコル統合システムのコンテクストの中で、各々のＰＩＡ ＳＢＣ１２０２は、システムのユーザ１２０４が、該システムからサービスを要求できる入口点である。こうしたサービス要求を実行するために、ＰＮＣ１２０６が、ＰＩＡ ＳＢＣ１２０２と入ってくるユーザ要求（ＩＵＲ）の実行を要求するユーザ１２０４の各々との間に確立される。ＵＩＣ１２０１内のＰＩＡ ＳＢＣ１２０２の各々は、該ＵＩＣに特有の明確なＡＬＰ１２０５を介して、ユーザに入口点を提供する。ＵＩＣ特定のＡＬＰ１２０５は、ＰＩＡＰと呼ばれる。如何なる合意されたＡＬＰもＰＩＡＰに十分である。本発明の好ましい実施形態は、ＰＩＡＰとして、ＲＦＣ２０６８に定められるような、開放型の標準化されたインターネット・ハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いる。
【００８１】
入口点として働くことを超えて、各々のＰＩＡ ＳＢＣ１２０２は、要求しているユーザ１２０４の観点からプログラム可能なシステム制御を提供する。上述のように、このシステムのようなプログラム可能性（管理、事務管理、構成であろうと、又は同様の機能であろうと）は、物理又はネットワーク層プロトコルを実行する装置から本発明を区別する特性を定義する。こうした装置を制御するユーザ１２０４は、ＰＩＡ ＳＢＣの２つの幅広い使用を介して、ＵＩＰの機能をカスタマイズする。第１に、ユーザ１２０４は、ソフトウェア命令をＰＩＡ ＳＢＣ１２０１に読み込むことができ、その意味規則は、本発明の決定要因ではない。したがって、ソケット抽象化をサポートする如何なるプログラミング言語もこのコンテクストに用いることができる。第２に、ユーザ１２０４は、以下に説明されるように、プログラマチック・コード又はソフトウェア命令を用いずに装置１２０１を構成するようにＰＩＡ ＳＢＣ１２０２により与えられた特定の構成能力を用いることができる。
【００８２】
様々な作動上の理由のため（増加した帯域幅、減少する待ち時間、増加した冗長性、耐故障性の提供、又はユーザ接続能力の拡大のような）、単一のＵＩＣエンクロージャ１２０１内の１つ又はそれ以上のＳＢＣ１２０２を用いて装置を構成することができる。各々のＳＢＣが、独立した命令ストリームを実行し、独立したＲＡＭを利用するので、ＵＩＣ１２０１内のＰＩＡ ＳＢＣ１２０２の各々は、シャシー内の他の全てのＰＩＡ ＳＢＣに対して自律的に働く。同様な意味合いで、各々のＰＩＡ ＳＢＣ１２０２は、ＵＩＣ１２０１内の他の全てのＰＩＡ ＳＢＣ１２０２により処理される、入ってくる要求の処理に関連する如何なる動的情報（動的サービス状態情報、又はＤＳＳＩと呼ばれる）も共有することなく、ユーザ１２０４から入ってくる要求を受け入れ、これを処理することができる同時実行機構を提供する。
【００８３】
続けて図１２を参照すると、ＡＬＰ論理アダプタ（ＡＬＡ ＳＢＣ）１２０７が、正確に１つのアプリケーション・プロトコルを実装する。多くとも１つのアプリケーション・プロトコルしかサポートすることができないが、各々のＡＬＡ ＳＢＣは、多くの異なるバージョン、サブバージョン、改訂、又はそのアプリケーション・プロトコルの他の同様の改良をサポートすることができる。ＡＬＡ ＳＢＣ１２０７の各々と実装しているＡＬＰとの間の１対１の関係は、本発明に固有の属性である。具体的には、専用のＳＢＣによって各々のＡＬＰを実装しなければならないという認識は、本発明に固有のものである。今日一般的な方法を用いて構築される統合解決は、このような手法を用いない。
【００８４】
各々のＡＬＡ ＳＢＣ１２０７は、非対称ではないが一定の論理関数の組（ＦＬＦＳ）に論理的に制約される機能を実装する。このＦＬＦＳは、ＡＬＡ ＳＢＣ１２０７が接続する特定のタイプの計算システム、及び該ＡＬＡ ＳＢＣ１２０７によって実装されるＡＬＰの属性の機能的要件に基づいて予め定義される。ここに、ＡＬＡ ＳＢＣと、アプリケーション層プロトコルを実行する他のあらゆるコンピュータ・ハードウェア又はソフトウェア・システムとの間の対比がある。各々のＡＬＡ ＳＢＣは、ＡＬＡ ＳＢＣ１２０７によってサポートされる単一のＡＬＰに関係するコンピュータ命令だけを実行するように特別に専用に設けられる。同様の意味合いで、ＡＬＡ ＳＢＣ１２０７は、単一のＡＬＰと関係がない如何なる命令も実行しない。ＡＬＡ ＳＢＣ１２０７は、任意の汎用コンピュータの命令を実行しない。
【００８５】
図１３に関して、多数のアダプタ（ＳＢＣ）１３０２、１３０３、１３０４と共に、本発明のアダプタのレベル図の例示的な図が示される。この図は、装置１３０１のＡＬＡ ＳＢＣ１３０２、１３０３、１３０４によって、３つのＬＲＣＳ１３０６、１３０７の間の代表的なデータ交換及び変換操作を示す。２つのソースＬＲＣＳ１３０６が、アプリケーション・プロトコル１３０９及び１３１０を用いて、対応するＰＮＣ１３０８を介して、装置１３０１内のＡＬＡ ＳＢＣ１３０２、１３０３に接続される。１つの宛先ＬＲＣＳ１３０７は、アプリケーション・プロトコル１３１１を用いて、ＰＮＣ１３０８を介して、装置１３０１内のＡＬＡ ＳＢＣ１３０４に接続される。上述のように、全てのＡＬＡ ＳＢＣが、相互接続１３０５を介して接続される。この実施形態内では、データ交換及び変換は、ソースＬＲＣＳ１３０６から発するデータを変換し、これを宛先ＬＲＣＳ１３０７に交換することによって生じる。この図は、このデータ交換及び変換に必要な構成が、上の説明に準拠したＰＩＡ ＳＢＣを用いて前もって確立されたことを仮定する。前に詳述されたように、図１３に含まれるＡＬＡ ＳＢＣの数及びタイプは、本発明の実施形態の属性と考えるべきであり、本発明を定義する属性と考えるべきではない。
【００８６】
さらに、各々のＡＬＡ ＳＢＣ１２０７が同時接続をサポートする論理遠隔計算システム（ＬＲＣＳ）１２０９の数は、従来の技術と異なる。具体的には、各々のＡＬＡ ＳＢＣ１２０７は、該ＡＬＡ ＳＢＣ１２０７の各々に同時に接続することができるＬＲＣＳの数についての限界制限を強制することができる。ＬＲＣＳの数についての限界制限は、ユーザが特定してもよく、ＡＬＡ ＳＢＣ１２０７の特性としてもよい。したがって、本発明は、如何なる数のＬＲＣＳにも接続するように設計されたこのような他の解決とさらに異なり、各々のＬＲＣＳとの如何なる数の同時接続も実行する。
【００８７】
さらに、全てのＡＬＡ ＳＢＣ１２０７は、ユーザから入ってくるＩＵＲを受け入れることができず、このようなユーザＩＵＲに関連した汎用論理も実装しない。上述のコンテクストにおいて、各々のＬＲＣＳは、物理的に独立した１つ又はそれ以上の計算システムによって実行することができ、論理計算システムについての様々な作動要件に依存する。例えば、ランタイム障害、ソフトウェア・プログラミング・エラー、又は性能上の理由に弾力的でなければならない計算システムは、通常、クラスタ又はフェイルオーバーの対に集約される。
【００８８】
本発明は、各々のＡＬＡ ＳＢＣ１２０７の能力が、専らＵＩＰ１２０１内のＰＩＡ ＳＢＣ１２０２を介した上述の機能に対して、ユーザによりアクセス可能であるという点で特有のものである。同様な意味合いで、各々のＡＬＡ ＳＢＣ１２０７は、ＰＩＡ ＳＢＣ１２０２の能力を呼び出すことによってしかユーザにアクセス可能でない能力を実装し、次に、ＰＩＡ ＳＢＣ１２０２によって、こうしたＡＬＰに特定のＡＬＡ ＳＢＣ１２０７にデリゲートされる。このことは、ユーザが、システム内の何らかの汎用ＣＰＵを介してＡＬＰにアクセスするのを助けるこうした非対称性をもたない別のシステムとは異なる。
【００８９】
さらに本発明に特有であると考えられるが、ＬＲＣＳ１２０９は、ＵＩＰ１２０１をＬＲＣＳ１２０９に相互接続するＡＬＡ ＳＢＣ１２０７ごとに、特定のＰＮＣ１２１０を介して単一のタイプの機能を提供するように要求される。この制約は、各々のＡＬＡ ＳＢＣ１２０７が、単一のＡＬＰに関連した論理を実行するという要求からすぐに分かる。この機能特定のＬＲＣＳ１２０９は、ＦＳ−ＬＲＣＳと呼ばれ、該ＬＲＣＳ１２０９が、一定の関数の組を介してその特定の論理機能から能力を与えるだけに制限されるという制約に重点を置く。例えば、ＰＮＣ１２１０を介するＬＲＣＳ１２０９は、構造化クエリー言語（ＳＱＬのような）において必要とされるような表フォーマットにおける矩形のような、任意のフォーマットで格納されたデータにアクセスする特定のタイプのコンピュータ・データベース接続を実行することができる。
【００９０】
さらに、このような関係が、ＵＩＲ、該ＵＩＲを処理するＰＩＡ ＳＢＣ１２０２、及び該ＵＩＲにおいて必要とされるＡＬＰを実行する１つ又はそれ以上のＡＬＡ ＳＢＣ１２０７の間の関係を定めるので、本発明は、ＡＬＡ ＳＢＣ１２０７とＡＬＰとの間の１対１の関係の特定の意味に依存する。上述のように、ＡＬＡ ＳＢＣとＰＮＣ ＳＢＣとの間の接続は、相互接続１２０３を介してもたらされる。ＳＢＣとＦＳ−ＬＲＣＳの間のＰＮＣ１２１０は、明確な組の特徴の交換に基づいているので、各々のＳＢＣは、こうした特徴の組のネットワーク符号化に特有のＡＬＰを用いる。したがって、ＰＮＣ１２１０が、ＦＳ−ＬＲＣＳにより与えられた機能に適切な単一のＡＬＰを実装するように論理的に制約されているので、ＵＩＰ１２０１及びＦＳ−ＬＲＣＳ１２０９を接続する該ＰＮＣ１２１０を、ＦＳ−ＰＮＣと呼ぶことができる。したがって、各々のＳＢＣは、一定の明確な組の機能を含むだけでなく、一定の明確なＡＬＰを介してＬＲＣＳと排他的にも相互接続する。ＳＢＣの機能は、特定の機能の組に制限されるが、ＡＬＰにより定められる該組の中の機能を再帰的に構成し、任意に複雑な演算を構築することができる。例えば、データベース接続の例を有するＦＳ−ＮＩＣのためのＡＬＰは、ＳＱＬ言語の機能的要求を表すのに十分なネットワーク符号化となる。
【００９１】
多数のＰＩＡ ＳＢＣ１２０２が単一のＵＩＰの中でどのようにサポートされるかと同じように、様々な作動上の理由から、同じＡＬＰを実装する多数のＡＬＰ ＳＢＣが、単一のＵＩＰ内に存在してもよい。ユーザ１２０７が要求する各々のＡＬＰをサポートするために、単一のＡＬＡ ＳＢＣ１２０７だけが厳密に必要とされるが、作動性能（増加した帯域幅、減少した待ち時間、減少した冗長性、耐故障性の提供、又はユーザの接続能力の拡大のような）を改善するために、多数のＡＬＡ ＳＢＣ１２０７を含ませることができる。ＰＩＡ ＳＢＣ１２０２と同様に、ＵＩＣ１２０１内の各々のＡＬＰ ＳＢＣ１２０７は、シャシー内の他の全てのＰＩＡ ＳＢＣ１２０２に対して自律的に働く。同様の意味合いで、各々のＰＩＡ ＳＢＣ１２０７は、ＵＩＣ内の他の全てのＡＬＡ ＳＢＣにより処理される、入ってくる要求の処理に関連する如何なるＤＳＳＩも共有することなく、如何なる数のＬＲＣＳ１２０９からＡＬＰを同時に受け入れ、処理することができる同時実行機構を提供する。
【００９２】
相補的コンポーネント
上述のように、上記は、マルチプロトコル統合システムを具体化する装置を介する、本発明の好ましい実施形態について説明した。次に、その能力が装置において有利であるマルチプロトコル統合システムの付加的な相補的コンポーネントの説明が続く。このように、当業者であれば、以下のコンポーネントが本発明を定義する属性ではなく、好ましい実施形態を定義する属性でもなく、本発明の装置を定義する属性でもないことをすぐに理解するであろう。以下に説明されるように、こうした相補的コンポーネントは、それぞれ方法又はプロセスである。
【００９３】
以下に説明されるコンポーネントを、本発明、如何なる特定の好ましい実施形態、又は本発明の装置から独立して同等に定義することができる。以下のコンポーネントは、その利点を実証し、説明の分かりやすさを改善するように、マルチプロトコル統合システムのコンテクストの中で以下に説明される。
【００９４】
相補的コンポーネントの説明は、２つのグループ、すなわち構成及び作動に二分される。この二分化スキームが、マルチプロトコル統合システムにより実行される予め構成された統合方法の結果、ユーザ
（構成）により駆動される方法とプロセスとの間の差を含むので、この方法は、慎重なものである。従来のシステムとの基本的な相違において、相補的コンポーネントは、これらの２つのグループを明瞭にセグメント化する。
【００９５】
以下に説明される構成相補的コンポーネントは、アプリケーション・プロトコルから独立した構成及びその実施形態のための抽象定式化である、一般化された機能的統合方法（ＧＦＩＰ）で構成される。以下に説明されるように、ユーザが、アプリケーション・プロトコルから独立してマルチプロトコル統合システムへの構成命令を特定する能力は、従来のシステムと根本的に異なる。手続き型プロセスフロー（ＰＰＦ）と呼ばれるＧＦＩＰの好ましい実施形態が、以下に説明される。宣言型構成と呼ばれる、ＰＰＦに依存するＧＦＩＰの好ましい実施形態が、以下に説明される。宣言型構成の好ましい実施形態が提供される。これらの特性のコンテクストの中で、実施形態においてこのようなシステム、及びマルチ処理／マルチ計算装置内の相互関係を構成することができる特定のハードウェア・コンポーネントが説明され、類型化される。
【００９６】
構成相補的コンポーネントの説明に続いて、複数の作動相補的コンポーネントが以下に説明される。具体的には、マルチプロトコル統合システム内の論理データフローのための方法が、内部に対応するデータ処理アルゴリズムと共に、ユニバーサル論理統合データフロー（ＵＬＩＤ）として説明される。前述のコンテクストの中で、ＵＬＩＤは、インターフェース間の交換中に中間仮想表示をどのように処理することができるかを定義する演算を具体化する。当業者であれば、以下に説明されるように、特定の組の前提条件を提供するあらゆるシステムによってＵＬＩＤを具体化できることを理解するであろう。したがって、マルチプロトコル統合システムのための装置内にＵＬＩＤを具体化することは、ＵＬＩＤについての適切に考えられた好ましい実施形態であると。
【００９７】
一般的な機能統合方法
参照として従来のシステムを用いる異種のアプリケーション・レベル・プロトコルを有するコンピュータ間のデータの交換を容易にする際の上述の複雑性を用いて、ＧＦＩＰを用いるマルチプロトコル統合システムの構成を、従来のシステムと対比することができる。ＧＦＩＰは、アプリケーション・プロトコルから独立した一般的なプロセスを用いて、マルチプロトコル統合システムのために統合方法を構成するのを助ける。本発明の装置内で、ＧＦＩＰは、各々のＡＬＡ ＳＢＣについての本発明における構成テーブルの構成を助ける。ＧＦＩＰの構成が、構成される統合方法に含まれる１つ又はそれ以上のアプリケーション・プロトコルに依存するので、ＧＦＩＰは、こうした構成をもたない従来のシステムと対照をなす。
【００９８】
一般的な機能統合方法（ＧＦＩＰ）は、ユーザが、マルチプロトコル統合システムのための統合方法を構成するのを助ける、全てのアプリケーション・プロトコルに共通のプロセスである。好ましい実施形態のコンテクストにおいて以下に説明されるように、構成の普遍性は、様々なＳＢＣアダプタ間の明確なプログラマチックな相互関係から生じ、ＧＦＩＰにより定められるように、その各々が、各々のＵＩＲを実行する大きなサービス・プロセス内の特定の明確な部分を実行する。
【００９９】
ＧＦＩＰは、以下の段階、すなわち（１）ＰＮＣを介してユーザからＩＵＲを受け入れる、（２）ＩＵＲを解釈し、構成される特定の統合方法、及びこうしたプロセスを実行するのに必要とされるＡＬＰを識別する、（３）対応するＡＬＰの各々を実装するＡＬＡ ＳＢＣの各々を識別する、（４）各々のＡＬＰの構成についてのそれぞれの要求及び応答処理を取り扱うために、各々のＡＬＡと双方向に通信する、（５）前の段階内で通信された全てのＡＬＰ ＳＢＣからの結果を集計する、及び（６）統合構成の結果を、オリジナルのＩＵＲを要求したユーザに戻す段階から構成される。このプロセスは、このようなユニバーサル統合プラットフォームを実装するのに必要な機能意味規則抽象的定式化である。
【０１００】
ＧＦＩＰの好ましい実施形態は、１３の段階の手続き型プロセスフロー（ＰＰＦ）プロセスからなる。上述の本発明の装置のコンテクストの中で、ＰＰＦは、マルチプロトコル統合システムの構成を助けるために必要なものとして、ＰＩＡとＡＬＡ ＳＢＣとの間の相互関係を定式化する。ＧＦＩＰ、ＰＰＦ、及びＰＩＡ ＳＢＣの間の関係は次のとおりである。すなわち、ＰＰＦは、ＧＦＩＰの好ましい実施形態であり、各々のＰＩＡ ＳＢＣは、ＰＰＦの実施形態を実行する。
【０１０１】
ＧＦＩＰ及びＰＰＦは、結合して、統合方法についての本発明の構成を助ける好ましい実施形態のための本質的な目的及び設計を表現する。さらに、このことは、本発明が、特定の統合方法と組み合わせられた特定の構成のハードウェアを用いることによって、ユニバーサル統合システムのために、アプリケーション・プロトコルから独立した構成を伝達することを例示する。
【０１０２】
１３の段階の手続き型プロセスフローは、本発明を用いる統合のための単一のユーザ構成要求についての要求・応答周期である。作動面において、ＰＰＦは、多数のアプリケーション層プロコトルの統合を必要とする各々のタスクを実行するために、ユーザがＵＩＰとどのように通信するかを説明する。この装置内に実装されるような、このＰＰＦ内の各々の段階の特定の実装の意味規則は、この抽象計算システムについての機能要件を満たす何らかの制御機構を通してインスタンス化することができる。このような要求を満たすように、多くのこうした実施形態をプログラムすることができるので、特定のソフトウェアの実施形態は必要とされない。
【０１０３】
所定のＵＩＰの所定のＰＩＡ ＳＢＣによって実行される所定のＩＵＲについてのＰＰＦプロセスは、次のとおりである。上に詳細に説明されるように、ＰＰＦを定義する本質的な特性は、このＰＰＦがアプリケーション・プロトコルから独立しており、よって、本発明における複数の任意のアプリケーション・プロトコルを用いる任意の統合方法を構成するために普遍的に使用可能であるという点である。このコンテクストにおいて、事例という用語は、特定のプロセスを完了するのに必要とされる段階の手順の実行を意味するように定義される。
【０１０４】
このコンテクストにおいて、ＩＵＲは、１つ又はそれ以上の構成命令に対応し、その構造及び組織は、実施形態の属性である。最後に、このコンテクストにおいて、構成更新という用語は、有限状態機械、論理経路、接合部、格納された値のような、マルチプロトコル統合システムの１つ又はそれ以上のパラメータを更新する命令に対応する。
【０１０５】
このＰＰＦの段階は次のとおりである。
（１）ＩＵＲの開始：ユーザは、ユーザの論理遠隔計算システムＬＲＣＳとＰＩＡ ＳＢＣ（こうしたＰＮＣ確立要求をリッスンする）との間にＰＮＣを確立することにより、ＵＩＰから機能を要求し、合意されたＰＩＡＰに定められたフォーマット及び意味規則を用いてＩＵＲを投入する。具体的には、ユーザは、バイトのシーケンス、又はＰＩＡ ＳＢＣとＬＲＣＳの間のＰＮＣを介するＵＩＰへのＩＵＲを表すＰＩＡＰによって定められる制約に準拠する何らかの同等の計算形式を書き込む。
【０１０６】
（２）要求の受け取り：ＰＩＡ ＳＢＣは、（１）において確立されたＰＩＡ ＳＢＣとＬＲＣＳ間のＰＮＣを介して、ＩＵＲを受け取り、バイトのシーケンス又はＩＵＲ（ＰＩＡＰの制約に準拠する）を表す何らかの同等の計算形式を、ＵＩＰにより使用可能な表示に構文解析する。ＩＵＲの表示は、ＰＩＡＰ及び構成更新の特定の実施形態の計算表示の両方によって決まる。具体的には、ＩＵＲは、ＰＩＡ ＳＢＣ上に配置されたＲＡＭを用いて、ＰＩＡＰに必要とされるネットワーク符号化から中間統合表示（ＩＩＲ）に変換される。このＩＩＲは、前に定義された中間仮想表示に関係していず、これによりさらに具体化することができる。
【０１０７】
（３）要求の解釈：ＰＩＡ ＳＢＣは、（２）において受け取ったようなＩＩＲを解釈し、ＩＵＲ内にカプセル封入された１つ又はそれ以上のユーザ構成要求を実行する。その際に、ＩＩＲの解釈は、その機能を要求しなければならないＡＬＡ ＳＢＣ（よってＬＲＣＳ及びＡＬＰ）を示す。ＩＩＲは、ＰＩＡ ＳＢＣ上の１つ又はそれ以上のＣＰＵによって実行される１組の機械コード命令として解釈されるか、又は１組の機械コード命令に変換される。上述のように、解釈の正確な意味規則は、構成更新の実施形態によって決まる。実施形態に関わりなく、ＰＩＡ ＳＢＣ ＣＰＵによる解釈プロセスは、ＩＵＲを実行するのに必要とされる別個の機能の組を列挙することによって、どのＡＬＡ ＳＢＣを要求すべきかを固有に識別し、先のＰＰＦの事例又は機能的等価物を介して、ＵＩＰ内に構成された、又は部分的に構成された統合方法についての１つ又はそれ以上のパラメータの評価を任意に要求することができる。ＡＬＡ ＳＢＣの中で互いに相反するものとすることができ、各々の特定のＡＬＡ ＳＢＣによって実行しなければならないＩＵＲのサブセットは、ＡＬＡ ＳＢＣに対して特定用途向けＩＵＲ（ＡＳＩＵＲ）と呼ばれる。
【０１０８】
（４）ＩＵＲのデリゲーション：（３）におけるＡＳＩＵＲに対応する構成更新を実行するために必要とされるＡＬＡ ＳＢＣの各々について、ＰＩＡ ＳＢＣは、適切なＡＬＡ ＳＢＣを用いて、動的サービス状態情報接続（Ｃ−ＤＳＳＩ）を確立する。各々のＡＬＡ ＳＢＣについて、（１）において定められるユーザの要求を取り扱うＰＩＡ ＳＢＣとの１対１の関係がある。したがって、実行されるべきｎ個のＡＳＩＵＲがある場合には、ｎ個のＡＬＡ ＳＢＣを用いてｎ個のＣ−ＤＳＳＩが確立され、ＰＩＡ ＳＢＣは、適切な接続信号機構を用いて相互接続からＣ−ＤＳＳＩの接続を物理的に要求する。
【０１０９】
（５）ＡＬＡの接続：（４）におけるＰＩＡ ＳＢＣを用いてＣ−ＤＳＳＩを確立したＡＬＡ ＳＢＣについて、ＰＩＡ ＳＢＣは、該Ｃ−ＤＳＳＩを介して、そのＡＬＡに特有のＡＳＩＵＲを伝送する。ＰＩＡ ＳＢＣは、バイトのシーケンス、又は何らかの計算形式を伝送し、Ｃ−ＤＳＳＩにわたる通信に適した形式で、ＡＳＩＵＲをそれぞれのＡＬＡ ＳＢＣにエンコードする。
【０１１０】
（６）ＡＬＡの解釈：（５）におけるＰＩＡ ＳＢＣからＡＳＩＵＲを受け取るＡＬＡ ＳＢＣの各々について、ＡＬＡは、該ＡＳＩＵＲを解釈し、ＡＳＩＵＲ要求を、潜在的にそのＡＬＡ ＳＢＣに特有の構成更新命令のシーケンスに変換し、該ＡＳＩＵＲを実現するために、これをＡＬＡ ＳＢＣによって実行することができる。ＩＵＲの解釈と同様に、ＡＳＩＵＲのＡＬＡ ＳＢＣの解釈は、構成更新が、ＩＵＲ及びＰＩＡＰによってどうように計算により表されるかについての特定の実施形態に依存し得る。このＡＬＡ特定のシーケンスの命令は、特定用途向け統合表示（ＡＳＩＲ）と呼ばれる。具体的には、ＡＬＡ ＳＢＣは、Ｃ−ＤＳＳＩを介してＡＳＩＵＲを受け取り、バイトのシーケンス又は如何なる同等の計算形式を、ＲＡＭに格納された内部の機能表示に構文解釈する。この内部の表示は、ＩＵＲによって要求される構成更新を実行するのに必要とされるように、通常ＡＬＡが、ＬＲＣＳと通信するために用いるＡＬＰに適切な一連の命令として定められるＡＬＡ上での実行のために適切に構成され、ＡＳＩＵＲを実現する。
【０１１１】
（７）ＡＬＡ−ＬＲＣＳの通信：ＩＵＲは、ＩＵＲにより定められたような特定のＡＬＡ ＳＢＣに対応する１つ又はそれ以上のＬＲＣＳに構成パラメータの変化を伝播するように、ＡＬＡ ＳＢＣに要求することができる。そのような場合には、（６）におけるＡＳＩＵＲを実行するためにＡＳＩＲを定めるＡＬＡ ＳＢＣの各々について、ＡＬＡ ＳＢＣは、それぞれのＬＲＣＳを用いてＰＮＣを確立し、始発ＡＬＡ ＳＢＣ及びＬＲＣＳにより互いに共有されるＡＬＰを介して、ＬＲＣＳに適切なＡＳＩＲのサブセットの適切な変換と双方向に通信する。このＰＮＣにわたる双方向通信は、ＬＲＣＳが用いるＡＬＡを用いて、ＬＲＣＳ特定の変換されたＩＵＲのサブセットの意味規則をＬＲＣＳに伝えるのに必要なＡＬＰ特定のフォーマット設定及び論理の実装をもたらす。ＡＬＡ ＳＢＣによるＡＬＰ特定の論理の実装により、ＬＲＣＳが、ＰＮＣにわたるＡＬＰに組み込まれたＡＬＡ ＳＢＣからの特定の結果に応答して戻った結果に基づいて、１組のＡＳＩＲパラメータ結果（ＡＳＩＲＰＲ）を生成するＡＬＡ ＳＢＣがもたらされる。具体的には、ＡＬＡ ＳＢＣは、必要に応じて、ＬＲＣＳを用いて１つ又はそれ以上の物理的ＰＮＣを確立する。ＡＬＡ ＳＢＣは、このようなＰＮＣにわたって、ＬＲＣＳ特定の変換されたＡＳＩＲのサブセットをＬＲＣＳに伝える。ＡＬＡ ＳＢＣは、ＡＬＡ ＳＢＣとＬＲＣＳとの間の双方向通信の中間結果をＲＡＭに格納する。
【０１１２】
（８）ＰＩＡの結果の受け取り：（７）においてＡＳＩＲＰＲを生成するＡＬＡ ＳＢＣの各々について、ＡＬＡ ＳＢＣは、Ｃ−ＤＳＳＩを介して、こうしたＡＳＩＲＰＲを（６）における始発ＰＩＡ ＳＢＣに通信する。具体的には、各々のＡＬＡ ＳＢＣは、対応するＬＲＣＳからのＡＳＩＲパラメータ結果を、バイトのシーケンス又は何らかの同等な計算形式に変換し、次に、（４）において確立されたＣ−ＤＳＳＩを介して、ＰＩＡとＡＬＡ ＳＢＣの間で物理的に伝送される。
【０１１３】
（９）結果の解釈：ＰＩＡにより各々のＡＳＩＲＰＲを受け取ると、（３）において定められたそれぞれのＡＬＡの各々について、ＰＩＡは、該ＡＳＩＲＰＲの符号化を解釈し、その結果を格納し、ＩＩＲの解釈を完了させる。ＰＩＡは、Ｃ−ＤＳＳＩを介してＡＳＩＲＰＲを受け取り、バイトのシーケンス、又はＣ−ＤＳＳＩにわたる伝送のためにＡＬＡ ＳＢＣが該ＡＳＩＲＰＲをエンコードした何らかの同等な計算形式を解釈し、解釈された結果をＰＩＡ ＳＢＣ上のＲＡＭに格納する。
【０１１４】
（１０）中間ＩＵＲの終了：各々のＡＬＡ ＳＢＣについて、Ｃ−ＤＳＳＩが（３）において確立され、特定のＡＬＡ ＳＢＣに対応するＩＵＲのサブセットを実行するのに必要とされるＡＬＡ ＳＢＣからの全てのパラメータを受け取った後、Ｃ−ＤＳＳＩのＰＮＣを任意に切断し、ＡＳＩＵＲの終了を反映させることができる。ＰＩＡは、Ｃ−ＤＳＳＩが、適切な接続信号機構を用いて相互接続から切断されることを任意に物理的に要求する。
【０１１５】
（１１）結果の構成：ＰＩＡ ＳＢＣは、各々のＡＬＡ ＳＢＣにより（８）におけるＰＩＡ ＳＢＣに伝えられたような全てのＡＳＩＲＰＲを集約し、ＵＩＰから構築されたＩＩＲのあらゆる解釈を終了し、次に、ＰＩＡＰによって要求される制約を適切に用いてパラメータ結果の組をフォーマット設定する。ＰＩＡ ＳＢＣのＲＡＭに格納されたＡＳＩＲＰＲ結果の組は、ＩＵＲにおいて特定される機能要件に基づいて適切に一緒に機能変換される。機能変換後、この結果は、ＰＩＡＰについてのフォーマット設定要件に合致する送出バイトのシーケンスにエンコードされる。ＩＵＲが必要とする正確な解釈及び変換演算は、構成更新の実施形態の特定の計算表示に依存し得る。
【０１１６】
（１２）結果の伝達：（１０）及び（１１）において定められた送出バイト・シーケンスは、ＰＩＡ ＳＢＣと（１）におけるユーザの間に確立されたＰＮＣを介してユーザに伝えることができる。或いは、ＰＩＡ ＳＢＣ（非同期的に）又はユーザ（同期的に）のいずれかにより始められるように、（１０）及び（１１）において定められた送出バイト・シーケンスは、（１）において特定された方法と同等な、ＰＩＡ ＳＢＣとユーザとの間に確立された第２のＰＮＣを介してユーザに伝えることができる。ＵＩＲにより定められた機能変換の結果をカプセル封入するバイトのシーケンス又は何らかの同等な計算形式は、（１）において確立されたＰＮＣに物理的に書き込まれる。
【０１１７】
（１３）ＩＵＲの終了：任意にＰＩＡＰの適切な規則に基づいて、（１）において確立されたＰＩＡとＲＣＳとの間のＣ−ＤＳＳＩが論理的に閉じられ、ＩＵＲの終了を示す。Ｃ−ＤＳＳＩが論理的に閉じられない場合には、ＰＩＡＰ特定の幾つかの機構を用いてＩＵＲのための要求・応答周期の終了を信号で送る。ＰＩＡ ＳＢＣは、適切な接続信号機構を用いて相互接続からのＣ−ＤＳＳＩの切断を物理的に要求し、対の間の通信経路を切断する。ＰＮＣが物理的に閉じられない場合には、代わりに、ＰＩＡＰ特定のトークンが、ＰＮＣを介して（切断せずに）ＰＩＡ ＳＢＣからＬＲＣＳに送られ、ＩＵＲが終了したことを示す。この信号は、ＵＩＣ内で処理するために、別のＩＵＲを引き続きＰＩＡに投入できることを暗黙的に示す。
【０１１８】
ＰＰＦは、単一のユーザのための単一のＩＵＲ構成更新を実行するのに必要な１３の段階を定める。如何なる所定の時間においても、ＰＩＡは、任意の数の独立したＩＵＲ要求を同時に処理することができる。ＰＩＡ ＳＢＣにより解釈される独立したＩＵＲの各々について、このプロセスは、全体的に実行される。当業者であれば、ＰＩＡ ＳＢＣとＡＬＡ ＳＢＣの間でＣ−ＤＳＳＩ接続を再使用するような、多数の同時ＩＵＲ要求に代わって行われる論理最適化が、ＰＰＦの実施形態の属性であり、したがって、ＧＦＩＰを定義する属性でも本発明を定義する属性でもないことを理解するであろう。
【０１１９】
ＰＰＦについてのプロセス段階を識別すると、複合装置内の個々のハードウェア・コンポーネントに対する要件についての幾つかの抽象化が観察できる。これらの抽象化は、本発明が、どのように特定のコンピュータ・ハードウェア・コンポーネントが組み合わせられ（コンポーネント自体の固有の物理又は設計特性ではなく）、明確な統合方法を実行するのに用いられるかにどれだけ依存するかをさらに例証する。
【０１２０】
第１に、ＩＵＲにより必要とされるような非退化型構成更新機能を実行するために、少なくとも１つのＰＩＡ ＳＢＣと１つのＡＬＡ ＳＢＣが必要とされる。この非退化型構成更新機能は、１つ又はそれ以上のデータにアクセスするか、又は１つ又はそれ以上の遠隔アプリケーション・ソフトウェア能力を呼び出すために、１つ又はそれ以上のＬＲＣＳにアクセスする必要がある何らかの機能と定義される。非退化型機能のために、ＩＵＲを実現するのに必要とされるプログラム可能な解釈を提供するために、少なくとも１つのＰＩＡ ＳＢＣが必要とされる。非退化型機能のために、ＬＲＣＳにアクセスし、内部に必要とされるＡＬＰを実装するために、少なくとも１つのＡＬＡ ＳＢＣが必要とされる。
【０１２１】
第２に、上述のように、ＰＩＡ及びＡＬＡ ＳＢＣは、動的サービス状態情報（ＤＳＳＩ）を互いに共有する。ＩＵＲの実施は、ＩＵＲの解釈を駆動するＰＩＡ ＳＢＣと、ＩＵＲを介してユーザにより要求される特定用途向けのタスクに必要な論理を実行するＡＬＡとの間で、リアルタイムに状態情報を動的に共有することに依存している。ＡＬＡ ＳＢＣは、正確に１つのＰＩＡ ＳＢＣを用いて、単一のＩＵＲに対応するＤＳＳＩを共有することができる。ＰＩＡ ＳＢＣは、あらゆる数のＡＬＡ ＳＢＣを用いて、単一のＩＵＲに対応するＤＳＳＩを共有することができる。ＰＩＡ ＳＢＣを用いてＤＳＳＩを共有するＡＬＡ ＳＢＣの数は、ＩＵＲに定められる機能を実行するのに必要とされるＬＲＣＳ接続の数に基づいている。
【０１２２】
第３に、ＩＵＲが、各々のＡＬＡに必要とされるＡＬＰを実装するＬＲＣＳから独立した計算システムのユーザから発するので、ＰＩＡ及びＡＬＡ ＳＢＣは、互いに別個の組のＬＲＣＳを用いてＰＮＣを確立する。当業者であれば、ユーザが、別個のソフトウェア・アプリケーションをＬＲＣＳ上で作動させ、さらに、この制約に違反することなく、構成のためにＰＩＡ ＳＢＣにアクセスできることを理解するであろう。
【０１２３】
ＰＩＡ及びＡＬＡがこうしたＤＳＳＩを物理的に共有する正確な方法は、２つのＳＢＣ間の電気的接続をサポートする何らかの方法を介して実行することができる。本発明の好ましい実施形態において、理想的には、ＳＢＣは、シャシーの相互接続にわたって確立された物理的接続を介してＤＳＳＩを共有する。この物理的接続は、以前よりＣ−ＤＳＳＩと呼ばれる。しかしながら、この要件をサポートする接続のための如何なる機構も十分なものである。例えば、接続について例証となる手段は、スイッチ又はルータを介して直接接続されるか又はブリッジされた、２つのＳＢＣ間の外部のイーサネット接続としてもよい。
【０１２４】
以下は、上述のマルチプロトコル統合システムのハードウェアの実施形態を用いる、１３段階のＰＰＦモデルのサンプル実施形態の実装である。このフローモデルは、この手続きプロセスを物理的実施形態にどのようにマッピングするかを明白に説明するブロックフロー図に依存する代わりに、物理的コンポーネントの詳細を要約する。図８及び図９を３つの別個の領域に分解することができ、これらは、（１）ＰＣＩバックプレーン８００、（２）左の分岐線が、ブロック８１１及び８０２により境界付けられたＰＢＩ ＳＢＣアダプタ、（３）右の分岐線が、ブロック８１２及び８０２により境界付けられた代表的なＡＬＡ ＳＢＣアダプタに対応する。
【０１２５】
以下の１３段階のプロセスは、ＰＰＦの実施形態について説明する。ＩＵＲ要求及びユーザが経験したＩＵＲの作動の意味規則についての別の好ましい実施形態を提供する構成更新の実施形態が、この実施形態に続いて説明される。以下は、このようなプロセスを実施する特定の物理的コンポーネントに機能仕様書をマッピングするものである。
【０１２６】
（１）ＩＵＲの開始：ユーザ８１１は、ファブリック８１３を介してＩＵＲに信号を送るためにＰＮＣをＳＢＣ８０３に開放し（９０７は、ＳＢＣ８０３上の必要なイーサネットプロコトル・スタックを実装する）、ネットワーク接続８１０を介してＳＢＣ８０３に物理的に接続する。ＰＮＣ８１０は、イーサネット・チップ９０７との共通のＴＣＰ／ＩＰ接続を要求し、ソケット・ネットワーク抽象化を用いて、ユーザ８１１とＳＢＣ８０３との間に双方向のデータ交換能力をもたらす。この例の場合には、こうしたＰＮＣのためのＰＡＩＰは、ＴＣＰ／ＩＰにわたってＨＴＴＰを介して定められ、共通の要求・応答モデルを用い、ＩＵＲを実行するのに必要なデータを交換する。
【０１２７】
（２）要求の受け取り：ＰＩＡ ＳＢＣ８０３のＣＰＵ８０７は、従来の割込み信号を介して、イーサネット・チップ９０７からＩＵＲについての要求を受け取り、該イーサネット・チップ９０７及びＯＳに依存するネットワーク・ソケットとして入ってくるＰＮＣを受け入れ、フレーミング及びプロコトル層意味規則を実装する。ＣＰＵ８０７は、ＲＡＭと共に、該ＣＰＵ８０７による共通の字句解析を用い、ＨＴＴＰをそのコンポーネント部品に構文解析する。構文解析された結果は、ＰＩＡ ＳＢＣ８０３上の迅速なアクセスのためＲＡＭ８０６に格納される。
【０１２８】
（３）要求の解釈：ユーザ８１１からのＩＵＲをカプセル封入する、ＨＴＴＰから構文解析された要求に基づいて、ＳＢＣ８０３は、どのＡＬＡ ＳＢＣアダプタ（使用可能な組の８１６、８１７、８１９、及び８１９から）が、ＩＵＲにおいて定められる機能を実装するために必要とされるかを解釈する。この実施形態は、インターネットのために設計された多くのプログラミング・システムには一般的であるように、ＵＲＬにおいて明示的にＡＬＰを特定するようにフォーマット設定されているＨＴＴＰ要求に依存する。ＩＵＲからトランスペアレントに認識可能なＡＬＰを用いる場合には、ＰＩＡ ＳＢＣは、ＡＬＰとＡＬＡ ＳＢＣの間の単純なマッピングを実行しなければならないだけである。具体的には、ＰＩＡ ＳＢＣは、関数ｆを実行するハッシュテーブルを保持しなければならず、ここで、ｆ（ＡＬＰi）−＞ＡＬＡ ＳＢＣjである。一般的なハッシュテーブルのいずれの実装も、この単純な関数を実行するのに十分なものである。
【０１２９】
この例において、ユーザ８１１からのＩＵＲは、多くても１つの実装すべきＡＬＡ ＳＢＣを要求する機能を特定すると仮定される。この簡単化仮定は、説明のためだけになされるものであり、本発明の属性と考えるべきではない。ここに説明されるのと同じ実装を用いて、他のＡＬＡアダプタにより同じプロセスを同時に実行することができる。さらに、ＡＳＩＵＲのフォーマット及びバイトストリーム表示を様々なプロセスによって表すことができる。この実施形態は、ＨＴＴＰに基づいてユーザ８１１により提供されるように、単純な文字表示に依存する。このように、この実施形態についてのＩＩＲは、多くの実施形態において一般的であるように、ＩＵＲ要求と同じである。このＩＵＲの中間表示はＰＩＡ８０３上のＲＡＭ８０６に格納される。
【０１３０】
（４）ＩＵＲのデリゲーション：ＰＩＡ８０３は、ソケット抽象化を用いるＡＬＡ ＳＢＣjを用いて、Ｃ−ＤＳＳＩを確立する。このようなＣ−ＤＳＳＩ接続の確立は、図１０に示された上述のＰＣＢブリッジング技術を用いるネットワーク・ソケット・シュミレーション技術を用いて、バックプレーン８００、ＰＢＣ８０４、８１４、ＲＡＭ８０６、接続９０１、９１０、及びＤＭＡ９０３を介して実行される。
【０１３１】
（５）ＡＬＡの接続：ＰＩＡ８０３は、上の（４）において構成されたシミュレートされたソケット接続を用いて、ＡＳＩＵＲをＡＬＡ ＳＢＣに伝達する。具体的には、ＳＢＣ８０３上のＲＡＭ８０６に格納されたＩＩＲは、バックプレーン８００にわたる電気的接続として接続９０１、９１０を用いて、ＰＢＣ８０４、８１４を介して該バックプレーン８００にわたって伝送される。ＰＢＣ８１４により受信されると、ＣＰＵ８１５及びＤＭＡ９０３は、協働し、電気的接続９０４及び９０５を介して、ＡＳＩＵＲをＲＡＭ８０６に格納する。このことにより、ＡＳＩＵＲは、ＲＡＭ８０６に格納され、ＡＬＡ ＳＢＣj上のＣＰＵ８１５による解釈のために使用可能となる。
【０１３２】
（６）ＡＬＡの解釈：Ｃ−ＤＳＳＩを介してＡＳＩＵＲを受け取ったＬＲＣＳ８１２への伝送のために、ＡＬＡ ＳＢＣjは、ＡＬＰにエンコードされるＡＳＩＲに備えて、ＣＰＵ８１５を用いてＡＳＩＵＲをＡＳＩＲに変換する。この例においては、ＡＳＩＲは、ＡＳＩＵＲと同じである。ＬＲＣＳ８１２によって予想されるＡＬＰは、ＬＲＣＳ８１１がオリジナルのＩＵＲにおいて提供したものと同じである。したがって、ＡＬＡ ＳＢＣjによってＡＳＩＵＲの中間変換は必要とされない。ＡＳＩＲは、ＡＬＡ ＳＢＣj上のＲＡＭ８０６に格納され、ＬＲＣＳ８１２への伝送を待つ。他の簡単化仮定と同様に、当業者であれば、多くのより高度化した符号化及びＡＳＩＵＲ−＞ＡＳＩＲ変換を、別の実施形態によって実行できることに気付くであろう。しかしながら、この例は、過度に複雑なものではなく、主な実施属性を最も効率的に伝えるように意図するものである。
【０１３３】
（７）ＡＬＡ−ＬＲＣＳの伝達：抽象定式化においてこれまでに定められた方法に従って、特定のＩＵＲの意味規則により必要とされる場合には、ＡＬＡ ＳＢＣjは、ＡＬＡ ＳＢＣアダプタに特有の上述の方法で、ＬＲＣＳ８１２までのＰＮＣを確立し、ＡＬＡ ＳＢＣj及びＬＲＣＳ８１２により互いに合意されたＡＬＰフォーマットで、ＡＳＩＲを伝送する。ＣＰＵ８１５は、ＰＮＣが、電気的接続９０８及び９０９を介するイーサネット・チップ９０７を用いて、ソケット抽象化式に構成されることを要求する。他のネットワーク接続と同じように、ＬＲＣＳ８１２は、ネットワーク接続を受け取り、該ＬＲＣＳ８１２とＣＰＵ８１５との間に双方向の通信経路を確立する。普通に見られるように、イーサネット・チップ９０７を介して伝送されるデータの中間表示は、ＡＬＡ ＳＢＣj上のＲＡＭ８０６に格納される。この実施形態において、ＡＳＩＲはＡＬＰと同じであるので、ＡＬＡ ＳＢＣjは、単にＰＮＣによってＡＳＩＲをＬＲＣＳ８１２に伝える。受信すると、ＬＲＣＳ８１２は、ＡＳＩＲにおいて定められた要求のＡＳＩＲＰＲをもとのＡＬＡ ＳＢＣjに伝えることによって応答する。受信すると、ＡＬＡ ＳＢＣjは、こうしたパラメータの結果をＲＡＭ８０６に格納する。
【０１３４】
（８）ＰＩＡ結果の受信：（５）において定められた同じ双方向のプロセスを用いて、逆方向のＣ−ＤＳＳＩ、ＡＬＡ ＳＢＣjは、ＰＩＡ８０３がＡＳＩＲをデリゲートしたオリジナルのユーザ８１１から（４）におけるＡＬＡ ＳＢＣjまで、ＩＵＲに対応するそれぞれのＡＳＩＲ要求に応答して、（７）においてＬＲＣＳ８１２から受け取ったパラメータ結果をＳＢＣ８０３に伝える。ＰＩＡ ＳＢＣ８０３は、次の解釈のために、ＡＳＩＲＰＲをＲＡＭ８０６に格納し、もとのユーザ８１１に伝える。
【０１３５】
（９）結果の解釈：一時的にＲＡＭ８０６に格納された、Ｃ−ＤＳＳＩを介して（８）においてＡＬＡ ＳＢＣjから受け取ったＡＳＩＲＰＲは、ＰＩＡ８０３においてＣＰＵ８０７により解釈される。この例において、ＡＳＩＲＰＲは、中間変換することなく、一語一句たがわずユーザ８１１に戻される。このことにより、ＡＳＩＲＰＲは、変換の複雑性を有する中間層を付加することなく、ユーザ８１１に直接戻される。上記のように、この簡単化仮定は、実施形態の実行の詳細であり、本発明を定義する属性ではない。
【０１３６】
（１０）中間ＩＵＲの終了：ＰＩＡ ＳＢＣ８０３とＡＬＡ ＳＢＣjとの間に確立されたＣ−ＤＳＳＩ接続は、シミュレートされたソケットへの閉鎖操作を介して切断される。具体的には、ＣＰＵ８０７のＯＳにおいて実行される装置ドライバは、シミュレートされたソケットを閉じるべきであるという信号をＰＢＣ８０４に送り、次に、この信号は、待ち状態の接続閉鎖の信号ＰＢＣ８１４に適したＰＣＩバス信号に変換される。ＰＢＣ７１４は、ＣＰＵ８１５に閉鎖を通知し、閉鎖の受け入れの信号をＰＢＣ８０３に送る。最後に、ＰＢＣ８０４は、シミュレートされたソケットの閉鎖の物理的受け入れの信号をＣＰＵ８０７に送り、接続は、ＣＰＵ８０７及びＣＰＵ８１５の両方により別個に終了する。
【０１３７】
（１１）結果の構成：単一のＡＬＡ ＳＢＣが関係した際には、結果の構成は必要でなく、（３）においてＩＵＲにより識別されるように多数のＡＬＡ ＳＢＣが関係した場合には、ＰＩＡ８０３上のＣＰＵ８０７は、共通の文字連結操作を介して、（９）における各々のＡＬＡ ＳＢＣからＡＳＩＲＰＲの簡単な集約を実行する。連結された文字は、構成されたＡＳＩＲＰＲと考えられ、その複合物もまたＲＡＭ８０６に格納される。
【０１３８】
（１２）結果の伝達：ＰＩＡ８０３とユーザ８１１との間に確立されたＰＮＣは、（１）に定められるように、接続８１０、ファブリック８１３、イーサネット・チップ９０７、接続９０８、９０９を用いて同じであるが逆のソケット抽象化を介して、構成されたＡＳＩＲＰＲをＬＲＣＳに伝えるために用いられる。ＡＳＩＲＰＲは、ＰＩＡＰにおいてエンコードし、再びユーザ８１１に伝達する。この実施形態において、ＰＩＡＰは、ＴＣＰ／ＩＰにわたるＨＴＴＰであり、ＣＰＵ８０７による標準化されたＨＴＴＰ応答パケット、及びユーザ８１１からのオリジナルのＩＵＲへの構成されたＡＳＩＲＰＲ応答をカプセル封入するイーサネット・チップ９０７の生成をもたらす。この例におけるＰＩＡＰ（ＨＴＴＰ）は、共通の要求・応答プロトコルであるので、ＰＩＡＰについて適切にエンコードされた応答をユーザに戻すために、（１）において開始されたＰＮＣをこの例において用いることができる。
【０１３９】
（１３）ＩＵＲの終了：ユーザ８１１により実現される要件によって、ＰＮＣは、ユーザ８１１により任意に閉じることができる。この実施形態におけるＰＩＡＰ ＡＬＰ、すなわちＨＴＴＰは、この段階における物理的閉鎖を任意に指定するために、ユーザ８１１又はＰＩＡ ＳＢＣのいずれかについてのプロビジョンを含む。ユーザ８１１が物理的にＰＮＣを閉じることを選ぶ場合には、通常のＴＣＰ／ＩＰ接続意味規則を介して、イーサネット・チップ９０７に閉鎖要求を通知する。イーサネット９０７は、閉鎖要求をＣＰＵ ８０７に中継し、次にソケット抽象化を切断し、このプロセスのために割り当てられたＲＡＭ８０６における計算リソースを解除する。この例において、ＰＩＡＰ ＡＬＰ（ＨＴＴＰ）は、バックプレーン２００のＯＫ結果状態コードを介して、任意のＰＩＡＰ特定の非物理的トークン閉鎖機構を実行する。このバックプレーン２００の結果コードは、ＰＮＣを介して投入された最後の要求の無事完了を示す。
【０１４０】
宣言型構成
図１４を参照すると、宣言型構成１４０３と呼ばれる構成についてのプロセスが定められる。宣言型構成１４０３は、ユーザ１４０１がプログラマチック・コードを明示的に又は暗黙的に特定する必要なく、ユーザ１４０１による統合方法の任意の構成を助けるように働く。このコンテクストにおいて、プログラマチック・コードは、ソース・コード、オブジェクト・コード、実行可能コード、又はプログラミング言語を用いるか、論理的にプログラミング言語と同等の方法で書かれた両者の中間の何らかの同等の中間形式である人間可読、機械可読、又はその組み合わせとなるように定められる。宣言型構成についての好ましい実施形態が、以下に説明される。
【０１４１】
宣言型構成１４０３は、統合方法についてのマルチプロトコル統合システムを構成するためにここに説明される３つの好ましい実施形態のうちの１つである。この宣言型構成１４０３は、本発明に特有のものであり、従来のシステムにも見られる他の２つは、プログラマチック・コード構成及びグラフィカル構成である。したがって、宣言型構成は、ＰＰＦのようなＧＦＩＰの実施形態の範囲内で、上述のようにＩＵＲを解釈するように働くことができる抽象定式化の実施形態である。
【０１４２】
宣言型構成を従来のシステムと対比するために、プログラマチック・コード構成及びグラフィカル構成についての要約が説明される。具体的には、プログラマチック・コード構成は、ユーザが、特定用途向けのプログラミング・インターフェース（ＡＰＩ）に準拠するプログラミング・コード（ＪＡＶＡ（Ｒ）におけるように）を書き込み、コンパイルすることによって、事例に対する特定の手続き命令を命令することを可能にする。コンパイルされたプログラマチック・コードは、使用に供する際にインストール又はアップロードしなければならない。さらに、グラフィカル構成は、ユーザが、インターネット上のブラウザ又はマイクロソフト・ウィンドウズのための顧客プログラムを介した使用のためにＨＴＭＬで書かれたプログラムのような、グラフィカル・ユーザ・インターフェース（ＧＵＩ）の使用によって、事例に対する特定の手続き命令を命令することを可能にする。ＧＵＩを実装するシステムは、ＧＵＩを介してユーザにより当てられた構成命令を用いて、コンパイルされるか又は解釈されたプログラマチック・コード、又はコンピュータ・システム上で実行可能な形式への他の別の変換、或いはその機能的等価物の何らかの例を生成する。
【０１４３】
宣言型構成１４０３を定義する特性は、従来のシステムに一般的であるように、ユーザが、如何なるプログラマチック・コードも書き込むことなく、又はグラフィカル・ユーザ・インターフェースを用いてコードを生成することなく、マルチプロトコル統合システムの実施形態１４０２の例に構成命令を与えることができる方法を該宣言型構成１４０３が提供するという点である。図１４に示されるように、以下は、宣言型構成１４０３の属性であり、従来のシステムとの対比をさらに実証する。第１に、宣言型構成１４０３は、ユーザ１４０１により開始されるので、非プログラマチック構成は、独立した機能又は拡張性、よって「アドオン」又は均等物ではなく、ＧＦＩＰの能力である。第２に、ユーザ１４０１によって宣言型構成１４０３に与えられた命令は、引き続きコンパイルし、解釈し、取り込み、又は他の方法で管理しなければならない、ユーザによるプログラマチック・コードに類似したプログラマチック・コードを生成しない。第３に、抽象定式化も実施形態も、宣言型構成１４０３の構造が、プログラミング・コード又は等価物のためのアプリケーション・プログラミング・インターフェース（ＡＰＩ）によって定められ、これに準拠し、或いは影響を受けることを必要としない。
【０１４４】
引き続き図１４を参照すると、上述のように、宣言型構成１４０３により提供される方法が、ユーザ１４０１からの１つ又はそれ以上の構成命令（例えば、上述のようにＵＩＲにより具体化されるような、或いは何らかの論理的等価物のような）を、有限状態機械１４０７、バイトストリーム１４０９、及び中間仮想表示１４０８の複合の組１４０５の１つ又はそれ以上の例に関連した１つ又はそれ以上の構成テーブル１４０６に変換する。宣言型構成１４０３は、接続１４０４を介する複合の組１４０５の各々との相互交信性に依存する。このような接続１４０４についての抽象化定式化が上に提供され、一方、このような接続１４０４についての好ましい実施形態が下に提供される。マルチプロトコル統合システム内の構成テーブル１４０６についての抽象機能的役割は、それらが、有限状態機械１４０７及び例外テーブル（分かりやすくするために図示されていない。説明については以下を参照されたい）に対応するので、以下に説明される。
【０１４５】
当業者であれば、２つの構成テーブルを有する２つの複合の組が図１４に示されるが、複合の組の数は、宣言型構成１４０３を定義する属性ではないことを理解するであろう。代わりに、宣言型構成１４０３は、如何なる複数の構成テーブル及び対応する複合の組１４０５を構成することもできる。さらに、さらに分かりやすくするために、図１４は、複合の組についての特定の詳細を省いており、これらは、上記及び下記に詳細に説明される。
【０１４６】
従来のシステムと異なるマルチプロトコル統合システムに特有の宣言型構成の好ましい実施形態は、２つのコンポーネントの組み合わせである。第１に、ＲＦＣ８５４のような接続１４１０にわたるネットワーク・プロセスをサポートするコマンド・ライン・インターフェース（ＣＬＩ）をユーザ１４０１に提供することができるコンポーネントである（このような実施形態は、任意にＶＴ１００のようなターミナル・エミュレーションを含むことができる）。第２に、接続１４１０を介してユーザ１４０１により与えられたＣＬＩコマンドを、構成テーブル１４０６に適したフォーマットに変換できるコンポーネントである。１つ又はそれ以上のＣＬＩコマンド内に組み込まれたような１つ又はそれ以上の構成命令のこのような変換を提供するための好ましい実施形態が、ＲＦＣ２０６８について上述される。
【０１４７】
宣言型構成１４０３のこうした好ましい実施形態により、ユーザ１４０１が、任意の統合方法について任意の構成命令を指定することを可能にした非プログラマチックな人間可読の表示フォーマットを提供した実施形態がもたらされる。
【０１４８】
多次元表示変換及びトランザクション表示
中間仮想表示についての１つの好ましい実施形態がここに提供され、その属性は、この実施形態に特有であると考えるべきであり、よって本発明の特性を定義する属性ではない。中間仮想表示の以下の実施形態は、多次元表示変換及びトランザクション表示（ＭＲＴＲ）と呼ばれる。
【０１４９】
図２１を参照すると、中間仮想表示が、１つ又はそれ以上の論理連続シーケンス２１０２のゼロ又はそれ以上の論理要素２１０３を介してこの実施形態により示される。シーケンス２１０２の個々の要素２１０３の各々は、スロットと呼ばれる。論理スロットの論理連続シーケンス２１０２の各々は、「次元」と呼ばれる。１つ又はそれ以上の次元２１０２からなる、本実施形態に対応する中間表示の例の各々は、領域２１０１と呼ばれる。図２１における次元２１０２の量は、特定の領域の例の属性であり、同様な意味合いで、領域における次元の数は、本発明の属性ではない。
【０１５０】
このコンテクスト内で、各々のスロット２１０３は、何らかの特定の物理的解釈（例えば、前に説明されたようにハードウェアの実施形態で見出すことができるような）から生じる挿入点又は類似解釈ではなく、「プレースホルダ」又は「論理ユニット」として解釈すべきである。したがって、こうした所定の構造を実施形態又は実施形態の特定の例によって示すことができるが、スロットの構造は特定の事例を意味しないという解釈において、スロットを不透明にすることができる。以下に説明されるように、スロットの不透明性は、例えば、多数の同時データ消費者が、論理的に矛盾する方法で同じ次元を見ることを可能にする多くの利点を提供する。さらに、スロット２１０３、次元２１０２、及び領域２１０１が計算により実装される機構は、本発明によって定められない。
【０１５１】
図２２を参照すると、図２１におけるように、多次元の領域２１０１は、次元２１０２から構成される。連続した範囲のスロット２２０１、２２０３、２００６は、それぞれの次元２１０１内に含まれており、ここで、範囲は、同じ次元において連続した１つ又はそれ以上のスロットとなるように定義される。領域内の次元は、明示的であろうと暗黙的であろうと、ゼロ又はそれ以上の関係を有することができる。このコンテクストにおいて、関係は、領域２１０１上で実行される１つ又はそれ以上の操作に著しく影響を及ぼし得る論理対応として定義される。以下に説明されるように、ＭＲＴＲ内の関係を操作できるようにするための１つの実施形態は、注釈によるものである。当業者であれば、全てのＭＲＴＲの中間表示に適用可能であろうと、或いは１つ又はグループのプロトコル又はフォーマットに特有なだけであろうと、計算により定量化できる如何なる基準も、次元間の関係として同等に表すことができることを理解するであろう。
【０１５２】
図２３を参照すると、明示的注釈２３０２は、同じ次元２１０１における１つ又はそれ以上のスロット２３０１内の特定の対応する値を介して示される関係である。暗黙的注釈２３０３は、同じ次元における１つ又はそれ以上のスロット内の特定の対応する値を介して示されない関係である。代わりに、暗黙的関係についての対応する注釈の値が、対応する値を一時的に格納できる何らかの機構を介して、次元２１０１及び対応する次元の外部から保持される。したがって、注釈は、明示的なもの又は暗黙的もののいずれであってもよい。暗黙的な関係の場合には、１つ又はそれ以上のスロット２３０１を有する対応する値を格納する注釈に論理的に関連させるために、１つ又はそれ以上のタイプの注釈識別子２３０４を要求することができる。複数のこのような関係が可能である場合には、領域の間の関係の数もタイプもその作動上の解釈も、ＭＲＴＲの属性と考えられない。
【０１５３】
図２４を参照すると、ＭＲＴＲ内の注釈についての２次的な機能は、次元内の個々のスロット２４０２又は範囲のスロット２４０４の属性を提供することである。図２４に示されるように、プログラミング言語理論に定められるように、属性の一例をタイプにすることができる。したがって、図２４におけるブロックは、次元の特定の例についてのタイプ属性を実装し、解釈する属性と考えるべきであり、よって、ＭＲＴＲ注釈についての特性を定義するものではない。具体的には、次元２４０１は、１つ又はそれ以上の同時統合方法のデータ演算２４０３に用いられるデータを保持することができる。各々のデータ演算は、タイプが両立性のない方法で、タイプの注釈と共にスロットによって保持されるデータを見ることができる。例えば、代表的なデータ演算１は、スロット・データをタイプｔ１ ２４０５として見ることができ、データ演算２及びデータ演算ｎは、スロット・データをタイプｔ２ ２４０６及びタイプｔ３ ２４０７として解釈し、ここで、各々のタイプｔ１、ｔ２、ｔ３は、互いに異なる。このコンテクストにおける見るという用語は、論理解釈又は類似した何らかのプロセスを指すために、一般的に解釈されるように意図される。タイプの差は、スロットの図２４０５、２４０６、２４０７における異なる視覚的パターンによって図２４に示される。視覚的パターンは、単に分かりやすく表示するためのものであり、ＭＲＴＲを定義する属性ではない。
【０１５４】
図２５を参照すると、こうした演算をあらゆる明確な抽象定式化にわたって定めることができるように、ＭＲＴＲは、スロット、範囲、次元、及び領域の何らかの組み合わせにわたって定められた任意の計算演算の定義、事例、及び操作化をサポートする。さらに、本発明により必要に応じて、任意に複雑なデータ交換及び変換アルゴリズムを容易にするのに必要とされるように、基本演算及び複合演算の両方を生成することができる。
【０１５５】
ＭＲＴＲでの計算演算２５０１の抽象定式化についての１つの実施形態が、ソース領域２５０２と宛先領域２５０３との間の機能関係を定める。ソース領域２５０２からの機能入力は、１つ又はそれ以上のスロット又は範囲２５０４からなる。宛先領域２５０３への機能出力は、１つ又はそれ以上のスロット又は範囲２５０５からなる。入力されたスロット及び範囲２５０４と出力されたスロット及び範囲２５０５との間の関係は、独立している。したがって、機能演算は、異なる数、寸法、又は形状の出力スロット又は範囲２５０５をもたらすことができる。さらに、機能演算は、ソース領域２５０２と比べて異なる次元の宛先領域２５０３内のスロットに修正をもたらすことができる。最終的に、機能演算は、ソース領域２５０２において連続し、宛先領域２５０３において不連続になるスロット又は範囲２５０４をもたらすことができる。当業者であれば、演算２５０１を再帰的に構成することもでき、演算間の暗黙的依存性を助ける条件付論理を利用することもできることを理解するであろう。
【０１５６】
このタイプの柔軟な計算演算の重要な利点は、単一の論理演算を用いて、スロット、範囲、次元、又は領域にわたって、他の方法で何が複雑な演算、潜在的複合演算（例えば、Ｊａｖａのような従来のプログラミング言語において、多くの個々のプログラミング・コード・ラインを要求するなど）を特定する能力である。最後に、当業者であれば、別個の計算演算２５０１の構成を介して、任意の多対多の計算演算を定めることができることを理解するであろう。
【０１５７】
図２６を参照すると、２５０１、２５０２、及び２５０３は、図２５からのものであり、説明のために詳細が除かれている。上述のように、派生演算２６０１は、計算演算２５０１の呼び出しに応答して暗黙的に呼び出される計算演算である。演算２５０１の呼び出しの観点からトランスペアレントに暗黙的演算を呼び出すＭＲＴＲの能力は、多くの利点を提供する。例えば、統合方法に対する一般的な要求は、局所的トランザクション又は分散トランザクションに関係することである。したがって、派生演算２６０１の一例は、開始トランザクション演算を呼び出すことができ、後続する派生演算は、コミット又はロールバック演算を呼び出すことができる。こうした後続の派生演算を、同じ演算２５０１、別の機能演算、何らかの任意の非同期機能（タイマーの期間満了のような）、或いは何らかの等価物と関連させことができる。このコンテクストにおける開始、コミット、及びロールバック演算の定義は、トランザクション処理理論内の承認された定義に等しい。派生演算は、演算の論理呼び出しの観点から不透明なことも不透明でないこともあり、構成を必要とすることも必要としないこともある。
【０１５８】
レジューム可能なプル・ストリーム・オートマトン
図２７を参照すると、図３に関連して最初に説明されたように、特定のプロセスが、有限状態機械の１つの好ましい実施形態を提供し、重要な計算処理上の利点及び従来のシステムとの対比を提供する。以下に説明されるように、プロセスの定義コンポーネントは、その属性が以下に定義されるバイトストリーム２７０２、及び、適切に定義されたレジューム可能なプル・ストリーム・オートマトン（ＲＰＳＡ）２７０１である。ＲＰＳＡ２７０１は、図３の有限状態機械３０３の実施形態であり、よって、本発明を定義する属性と考えるべきではない。説明を明確にするために、抽象オートマトンの観点、及び、実際にＲＰＳＡをどのように使用することができるかという例を説明する作動上の観点の両方から、該ＲＰＳＡを説明する。これらの定義コンポーネント、バイトストリームに対する以下の要件、及び任意のバイトストリーム２７０２の条件の組の組み合わせが、このプロセスを従来のシステムと対比するのに役立つ。プロセスの定義のために必要とされないが、このプロセスは、このプロセスの評価中に保持されるスカラー整数Ｖの値も必要とすることがある。Ｖは、有限長のバイトストリームについて必要とされるだけなので、Ｖは、このプロセスの属性ではない。さらに、スキーマ・マトリックス、ルックアサイド・バッファ、又は本発明内の他の一時的な記憶機構にＶを格納することができるので、Ｖが計算記憶装置である場合の物理的位置も、このプロセスの属性と考えられない。Ｖの値は、開始状態２７０６に入った時に数値ゼロ（０）に設定される。
【０１５９】
このプロセスにおけるＲＰＳＡの属性を示すために、単一の通信プロセスの事例の反復を考える。図示された例について、バイトストリームからＮバイトを読み取るこのような通信プロセスの実施形態の事例を考える。当業者であれば、如何なるシーケンスのＲＰＳＡの事例も、個々の事例の一連の一時的構成として定め得ることをすぐに理解するであろう。さらに、当業者であれば、処理するデータの尺度及び処理通信の基本的ユニットのようなバイトを、バイトと他の基本的ユニットとの間の両立性がある変換をサポートする何らかの通信の尺度と置換できることを理解するであろう。
【０１６０】
バイトストリーム２７０２の要件は、データを単方向に取り出すことができること、及びＲ２７１３と呼ばれる特定の論理関数２７１３を特定の意味規則を有するバイトストリームにわたって定め得ることである。当業者であれば、Ｒ２７１３は、ＲＰＳＡ２７０１における状態又は遷移ではなく、寧ろバイトストリーム２７０２からデータを要求するために、ＲＰＳＡ２７０１によって呼び出すことができる関数であることを理解するであろう。具体的には、Ｒ２７１３関数の意味規則は、要求と同時にＲ関数が、バイトストリームから正のデータ量に戻るか、又は現在使用可能なデータがないという表示に戻るかのいずれかである。戻される場合には、正のデータ量は、Ｄと呼ばれる。ＤがＲ２７１３の呼び出しのために戻される場合には、Ｄの長さは、｜Ｄ｜と表記される。Ｒ２７１３が正のデータ量に戻らない場合には、Ｒ２７１３からの結果は、＿と表記され、対応する長さの尺度は、＿と定められない。バイトストリーム（関数名、パラメータ値、バッファの寸法、又はデータ・アライメントのような）にわたって、こうした読み取り関数が正確にどのように実装されるかは、このプロセスの実施形態の属性である。当業者であれば、このプロセスの定義を実質的に変えることなく、バイトストリーム２７０２を同等に双方向のバイトストリームとすることができることを理解するであろう。さらに、当業者であれば、このプロセスの定義を実質的に変えることなく、バイトストリーム２７０２及びスキーマ・マトリックス２７０４を交換することができるので、このプロセスは、対称性であり、よって、入力及び出力処理の両方に適用可能であることをすぐに理解するであろう。
【０１６１】
このプロセスは、バイトストリーム２７０２の処理において、以下の条件が生じ得ると仮定する。こうした条件の発生率、規則正しさ、及び関連した他の作動パラメータは、本プロセスに関連しないと考えられる。第１の条件は、バイトストリーム２７０２が、通信プロセス中にゼロ又はそれ以上の回数だけストールできるという点である。このコンテクストにおいて、ストールという用語は、使用可能なデータがない通信作動中（開始後及び終了前）にゼロでない長さの時間が存在することを意味するように定められる。入力／出力の従来システムにおいて考える場合には、ストールに応答して生じる条件は、一般に「ブロッキング」と呼ばれる。具体的には、バイトストリーム２７０２がストールする場合には、Ｒが＿に戻る。こうしたストールが生じた場合には、通信プロセス中にストールの中間のバイトストリーム２７０２で受信したデータのシーケンスは、チャンクと呼ばれる。第２の条件は、バイトストリーム２７０２は、厳密に一連の（ランダムでないアクセス）順序で、このプロセスによって一回だけ読み取り可能であるという点である。このような場合には、バイトストリーム２７０２を、同様な意味合いで、一連のバイトストリームと呼ぶことができる。第３の条件は、バイトストリーム２７０２が有限（限界のある）長又は無限（限界のない）長を有することができ、よって、バイトストリームは、何らかの限界制約に準拠することが要求されない。
【０１６２】
スキーマ・マトリックス２７０４及びルックアサイド・バッファ２７０３は、本発明を定義する属性であるが、有限状態機械のこの好ましい実施形態には必要とされない。これらがこのプロセスと共に任意に用いられる場合には、プロセス状態２７０８及びスキーマ・マトリックス２７０４、並びにルックアサイド・バッファ２７０３を接続する破線は、それぞれの中間仮想表示又はルックアサイド・バッファから値を読み取り書き込むのに必要な関数を表す。それらを必要としないことは、スキーマ・マトリックス２７０４又はルックアサイド・バッファ２７０３のいずれかを、同等な組の読取り・書込み操作をサポートするヌル関数で置き換えることができるという、当業者には認識可能な観察により生じるものである。このコンテクストにおいて、ヌル関数は、その呼び出しが実質的な計算動作を実行しない関数を意味するように定められる。
【０１６３】
続いて図２７から、ＲＰＳＡは、５つの状態、すなわちＢｅｇｉｎ２７０６、Ｐｕｌｌ２７０７、Ｐｒｏｃｅｓｓ２７０８、Ｈａｌｔ２７１０、及びＥｎｄ２７１２からなる。オートマトン状態の遷移は、Ｂｅｇｉｎ＿Ｐｕｌｌ、Ｐｕｌｌ＿Ｐｒｏｃｅｓｓ、Ｐｕｌｌ＿Ｈａｌｔ、Ｐｕｌｌ＿Ｅｎｄ、Ｈａｌｔ＿Ｐｕｌｌ、Ｐｒｏｃｅｓｓ＿Ｐｕｌｌである。ＲＰＳＡの外部から論理によって呼び出される動作、すなわち、開始動作２７０５、レジューム動作２７１１、及び継続動作２７０９は、点線で表される。当業者であれば、動作は、ＲＰＳＡ内の状態でも遷移でもない（これらが、呼び出しに応答して、ＲＰＳＡ内の遷移をトリガし得るが）ことを理解するであろう。当業者であれば、実質的にＲＰＳＡ又はこのプロセスの定義に影響を及ぼすことなく、Ｐｕｌｌ状態２７０７及びＰｒｏｃｓｓ状態２７０８を組み合わせて単一の複合状態にできることを理解するであろう。Ｐｕｌｌ状態２７０７の機能及びＰｒｏｃｅｓｓ状態２７０８の機能が、図２７に示され、厳密に説明を理解しやすくするために、別個のオートマトンとしてここに説明される。
【０１６４】
ＲＰＳＡ２７０１によって処理される通信プロセスは、状態Ｂｅｇｉｎ２７０６において通信処理を始める。ＲＰＳＡは、開始動作２７０５が呼び出されるまでＢｅｇｉｎ状態にとどまり、Ｂｅｇｉｎ＿Ｐｕｌｌ遷移を生じさせる。開始動作２７０５が呼び出されると、制御は、次の状態まで、ＲＰＳＡを呼び出した論理に戻されない。このコンテクストにおいて、制御という用語は、実行される単一のシーケンスの命令を指す（例えば、１つの好ましい実施形態において、ＣＰＵが命令のストリームを実行し、任意の関数ｆが呼び出され、呼び出しプログラムは、ｆが実行を完了するまで継続するのを待たねばならない場合など）。
【０１６５】
Ｐｕｌｌ状態２７０７は、複合演算を実行する、すなわち、（Ｖ＜Ｎ）の場合には、ＶとＮの値を比較し、Ｒ２７１３を呼び出し、次にこの結果の評価に基づいて、状態遷移を受ける。ＲＰＳＡは、開始動作２７０５がＰｒｏｃｅｓｓ状態上に呼び出されるまでＥｎｄ状態にとどまる。Ｒ２７１３の呼び出しの結果がＤである場合には、Ｐｕｌｌ＿Ｐｒｏｃｅｓｓ遷移が生じる。Ｒ２７１３の呼び出しの結果が＿である場合には、Ｐｕｌｌ＿Ｈａｌｔ遷移が生じる。
【０１６６】
Ｐｒｏｃｅｓｓ状態２７０８に入ると、処理演算が呼び出される。Ｐｒｏｃｅｓｓ状態２７０８に入る度に、Ｖが１ずつ増加する。上述のように、こうした処理演算は、スキーマ・マトリックス又はルックアサイド・バッファのいずれか又は両方からのデータの読み取り又は書き込みをもたらすことができる。Ｐｒｏｃｅｓｓ演算を完了すると（処理の完了と呼ばれる）、ＲＰＳＡは、ＲＰＳＡを呼び出した論理に制御を戻すが、ＲＰＳＡは、Ｐｒｏｃｅｓｓ状態２７０８に依然としてとどまる。したがって、オートマトン状態は、ＲＰＳＡを呼び出す何らかの論理に関連した状態から独立している。従来のシステムと対照的に、Ｐｒｏｃｅｓｓ状態に依然としてとどまりながら（及び、スキーマ・マトリックス２７０４及びルックアサイド・バッファ２７０３への参照を任意に保持しながら）、ＲＰＳＡを呼び出す論理に制御を戻すＲＰＳＡの能力は、このプロセスの重要な識別属性である。
【０１６７】
Ｐｒｏｃｅｓｓ状態２７０８について、Ｈａｌｔ状態２７０１又は処理・完了のいずれかにある場合には、ＲＰＳＡを呼び出す論理が、それぞれの継続動作２７０９又はレジューム動作２７１１を介して、いつでも通信を処理し続けるよう、引き続いてＲＰＳＡに要求することができる（Ｈａｌｔ状態２７０１に入った際、又はＰｒｏｃｅｓｓ状態２７０８においてＰｒｏｃｅｓｓ演算を終えた際に、制御が戻された際に）。レジューム動作２７１１を呼び出す際に、Ｈａｌｔ＿Ｐｕｌｌ遷移が生じる。継続動作２７０９を呼び出す際に、Ｐｒｏｃｅｓｓ＿Ｐｕｌｌ遷移が生じる。
【０１６８】
図２８を参照すると、本発明についてのサービスの質の一つの例を実行するためにこのプロセスを用いる単一の図示された例が説明される。このコンテクストにおいて、サービスの質（ＱｏＳ）は、異なるクラスの性能の優先順位をサポートすることを意味するように定められるが、これは、外部から設定される要因（通常、ユーザにより設定された）に基づいて、異なるＲＰＳＡプロセスに対して実施形態により定められるものである。一般化されたＱｏＳの抽象定式化は、本発明に特有のものではないが、統合システムにおいてＱｏＳ原理をアプリケーション・プロトコルに適用することは、本発明に特有のものである。
【０１６９】
ＱｏＳ実施形態２８０１は、命令のシーケンスを実行し、一時的データ（ＲＡＭと組み合わされたＣＰＵのような）を保持する能力をサポートする何らかの計算の実施からなる。ＱｏＳループ２８０１は、一定の組の演算にわたる有限又は無限フロー制御ループと定められる処理ループ２８０４を実行しており、例えば、多くのプログラミング言語（例えばＪａｖａ）において見出される「ｆｏｒ」フロー制御命令文は十分なものである。処理ループ２８０４は、図２８に示される３つのＲＰＳＡ２８０３と共に、複数のＲＰＳＡ２８０３にわたって定められた演算を呼び出す。図２７のコンテクストにおいて説明されるように、上の説明によると、ＲＰＳＡの各々に、単一のバイトストリーム２８０２を通してデータが与えられる。
【０１７０】
この処理ループ２８０４により、単一のＱｏＳ優先順位付けアルゴリズムを実行することができる。具体的には、上述のように、ＲＰＳＡの現在状態に適切なように、ＲＰＳＡについての複合処理演算、すなわち継続動作２７１１又はレジューム動作２７０９のいずれかを意味するように、反復という用語を定める。概念上、ＱｏＳ２８０４の反復の各々は、ＲＰＳＡの各々に、データを処理するための「ターン」を提供する。各々の反復について、ＱｏＳ論理２８０４が、各々のＲＰＳＡ２８０３に対応する幾つの別個の処理演算を呼び出すかの尺度となるように、ｆｒｅｑ（ＲＰＳＡ）という用語を定義する。この例において、異なるＲＰＣＳを１からｎまで列挙する。したがって、基本的なＱｏＳの優先順位付けを、各々のｎＲＰＣＳの例のｆｒｅｑ（ＲＰＣＳ）の差の値として定めることができる。例えば、ｎ＝３であり、等しい優先順位が必要とされると考えられる場合には、ｆｒｅｑ（１）＝ｆｒｅｑ（２）＝ｆｒｅｑ（３）＝１である。別の例を考えると、ｎ＝３であり、ＲＰＣＳ１の優先順位がＲＰＣＳ２の優先順位の２倍でなければならず、そのことがそれぞれＲＰＣＳ３の優先順位を２倍にする場合には、ｆｒｅｑ（１）＝４、ｆｒｅｑ（２）＝２、ｆｒｅｑ（３）＝１である。
【０１７１】
動的適応オートマトン
図２９は、動的有限状態機械２９０１に関連した論理コンポーネントを示す。視覚的に図１と類似しているが、動的有限状態機械を示す際の分かりやすさを保証するように、前の図に示された詳細を排除しているので、この図は異なるものである。
【０１７２】
上述のように、これまで説明された有限状態機械は、静的な、その属性が事例の属性及び任意に構成テーブルに依存する一定のオートマトンである。図２９に示される有限状態機械は、動的有限状態機械２９０１である。動的有限状態機械の定義は、内部に含まれる全ての対応する計算の事例と共に、状態及び遷移の組が、特定の明確な条件に応答して変化し得るというものである。オートマトンが静的であるか動的であるかは、本発明の実施形態の属性であり、よって本発明を定義する属性ではない。
【０１７３】
前に説明されたように、動的有限状態機械２９０１は、有限状態機械と同じコンポーネントを含む。バイトストリーム２９０４及び中間仮想表示２９０５が、この説明に特に重要である。静的有限状態機械と同様に、動的有限状態機械２９０１は、入力処理のためにバイトストリームから中間仮想表示にデータを移動し、出力処理のために中間仮想表示からバイトストリームにデータを移動する、上述のような状態プロセスを実行する。当業者であれば、その定義の対称性のために、動的有限状態機械を入力処理及び出力処理の両方のために用いることができることを理解するであろう。
【０１７４】
１組の状態及び遷移規則Ｚ１ ２９０３及びＺ２ ２９０２について、動的有限状態機械２９０１を定めることができる。動的有限状態機械２９０１を定める必要に応じて、状態の対という用語を対｛状態の組、遷移規則｝と定義する。したがって、Ｚ１ ２９０３及びＺ２ ２９０２の両方は、状態の対の例である。当業者であれば、状態の組及び遷移規則が、上のように定められた場合に有限状態機械を固有に定義するのに十分であることを理解するであろう。例えば、依存している機能呼び出しを含む実施形態において必要とされるように、これらが十分でない場合には、このような付加的な値を保持するために、必要に応じてＺ１ ２９０３及びＺ２ ２９０２の定義を適切に広げるべきである。
【０１７５】
動的有限状態機械２９０１が定めるものは、その状態の対が実行中に変化する能力である。この変化についてのタイミング、間隔、周波数、及び他の特定の一時的パラメータは、動的有限状態機械２９０１を定義する属性と考えられない。さらに、図２９における２つの状態対の図は、動的有限状態機械を定義する属性ではない。より具体的には、動的有限状態機械２９０１は、該動的有限状態機械２９０１を定義することができる複数の潜在的な状態の組の例を有することができる。このコンテクストにおいて、割当てという用語は、動的有限状態機械２９０１の状態の対が特定の例の値（Ｚ１ ２９０３及びＺ２ ２９０２のような）に割り当てられるプロセスを意味するように定義される。条件、タイミング、及び動的有限状態機械２９０１に対して割当てを生じさせる他の作動特性は、該動的有限状態機械２９０１を定義する属性と考えられない。
【０１７６】
こうした割当て条件についての両方が従来のシステムと対照をなす２つの好ましい実施形態、すなわち動的自動生成及び動的刺激がここに定められ、本発明の実施形態又は装置において動的有限状態機械２９０１をどのように用い得るかについて図示された例を提供する。同様な意味合いで、動的有限状態機械への状態の対の割当ては、抽象定式化、及び統合処理中に用いられるオートマトンの作動特性の両方を、量的パラメータに基づいて変化させる。さらに、これらの実施形態が実証するように、割当てのタイミングは、ユニバーサル統合システムの実施形態の作動中にいつでも起こり得るものであり、よって、タイミングを実行することは、必ずしも割当て条件を定義する特性ではない。
【０１７７】
動的自動生成は、一般にユーザにより与えられる構成パラメータを表す状態の対の生成をもたらす割当て条件である。具体的には、上述のように、ユーザによって構成更新を実行することができ、このことにより、１つ又はそれ以上の有限状態機械に適した対応する状態の対の動的生成がもたらされる。この例において、Ｚ２ ２９０２は、ユーザによって実行された構成更新に応答して生成された状態の対を表すことができる。当業者であれば、動的自動生成が、特定の動的有限状態機械について状態の組又は遷移規則から独立しており、よって、本発明の範囲内で広く適用可能であることを理解するであろう。
【０１７８】
動的刺激は、その時点で生じる特定の統合方法の特性に依存するか又はこれから独立した量的な動的パラメータに基づいて、動的有限状態機械２９０１により用いられる状態の対を修正する割当て条件である。動的刺激は、少なくとも２つの方法、すなわち自己反射型又は非自己反射型で生じ得る。自己反射型の動的刺激割当ては、動的有限状態機械自体によって呼び出される割当て条件によって定められる。しかしながら、同様な意味合いで、動的有限状態機械は、割当てを実行するために実施形態において実装することができる必要な演算を呼び出す。上述のように、非自己反射型の動的刺激割当ては、量的な動的パラメータに応答して生じる動的有限状態機械に対する何らかの割り当てとして定められ、その状態の対が修正された動的有限状態機械以外の何らかの論理により実行される。
【０１７９】
ユニバーサル論理統合データフロー
マルチプロトコル統合システム段階の作動相補的コンポーネントは、ユニバーサル論理統合データフロー（ＵＬＩＤ）と呼ばれるマルチプロトコル統合システムの論理データフローについてのプロセスの定義である。より具体的には、この定義は、本発明の実施形態を用いる機能マルチプロトコル統合方法を実行する本質的な目的及び設計を表す。さらに、ＵＬＩＤの定式化は、本発明が、アプリケーション・プロトコルと関係なく統合方法を用いることによって、マルチプロトコル統合システムの作動を伝えることをさらに例示する。ＵＬＩＤが一般にプログラム可能でないデータフローの定式化を具体的に定めるので、該ＵＬＩＤは、本発明がこれまでのシステム、及び汎用コンピュータとどのように異なるかをさらに実証する。
【０１８０】
ＵＬＩＤは、各々が本発明の論理データフローの１つの実施形態を定める際に協働する、多数の別個のコンポーネントからなる。ＵＬＩＤの説明は、インターフェースのデータフロー、有限状態機械、及び図２及び図３に関連して上述したような仮想中間表示について詳述することで始まる。これらのコンポーネントを用いる最初のデータフローは、ユニバーサル統合システムとして本発明についての要件を実現するのに十分なものである。ＵＬＩＤの１つの好ましい実施形態である、一連の多段階条件データフロー（ＳＭＣＤ）について以下に説明される。さらに、ＰＰＦについての好ましい実施形態において上述された手段と概念的に類似した技術を用いると、上述のような本発明のハードウェアの実施形態を用いて、ＵＬＩＤについての好ましい実施形態を同様に実行することができる。
【０１８１】
一連の多段階条件データフロー
ＵＬＩＤの独立部分を具体化する多数の別個のコンポーネントの抽象定式化について説明したが、こうした別個のコンポーネントについての統一フレームワークを提供する、一連の多段階条件データフロー（ＳＭＣＤ）と呼ばれる論理データフローについての１つの実施形態がここで説明される。具体的には、アプリケーション・プロトコルから独立し、構成可能に適応できる、一連の３つのパイプラインのデータフロー・アーキテクチャが、ここで説明され示される。
【０１８２】
図１５は、付加的なデータフロー、及び対応する統合交換、並びに変換演算１５０１を、中間仮想表示マトリックス１３０３、１３０４間でどのように任意に簡単なものにできるかを示すことに的を絞った図１３の拡大図を提供する。図１５を考えるにあたって、以下は、インターフェースのデータフロー、有限状態機械、及び上述の仮想中間表示を一連の多段階条件データフロー（ＳＭＣＤ）１５０１と呼ばれるデータフローの複合抽象定式化にどのように組み込むことができるかを説明する。
【０１８３】
図１６は、３つのパイプライン１６０１、１６０２、１６０３が重なり合った図１３の図を提供する。この図におけるコンポーネントは、ＵＬＩＤのＳＭＣＤ実施形態の属性を表し、よって、本発明について定義する属性と考えられるべきはない。具体的には、ＳＭＣＤにおけるデータフローは、３つのパイプライン、すなわち接頭パイプライン、挿入パイプライン、及び接尾パイプラインに分解され、全て同時に動作する。パイプラインの主要な依存性が、それらの間で連続的に送られるデータから生じるので、パイプラインは、半ば独立した状態で動作する。さらに、本発明により処理される特定の統合方法に依存する、独立且つ並行して動作する各々のパイプラインの１つ又はそれ以上の例があり得る。
【０１８４】
上述のようなインターフェース、有限状態機械、及び中間表示の１つ又はそれ以上の例を、接頭パイプライン１６０１又は接尾パイプライン１６０３のいずれか又は両方に含まれるコンポーネントとすることができる。以下に詳述されるように、接頭パイプライン１６０１又は接尾パイプライン１６０３のいずれかの属性が、対応する有限状態機械についての特定の機能要求を含んでもよい。
【０１８５】
データは、パイプラインを通って連続的に流れ、接頭部１６０１から始まり、挿入部に流れ、接尾部で終わる。しかしながら、所定のプロセスに対する統合要求が、挿入パイプラインによりもたらされる能力を必要としない場合には、プロセスごと、データごと、又は他の識別ベースの処理中に該挿入パイプラインを省略することができる。接頭パイプライン１６０１又は接尾パイプライン１６０３が、特定の（すなわち、前もって定められた）統合インターフェースで実行されるので、それらは、物理的なパイプラインであり、該接頭パイプラインは入力インターフェースで実行し、該接尾パイプラインは、出力インターフェースで実行する。挿入パイプライン１６０２は、仮想化パイプラインとすることができ、「概念的便利さ」のために存在させてもよく、よって、特定の統合カード上に常駐するものではない。代わりに、挿入パイプラインは、入力及び出力インターフェースにわたって分散することができる構成可能な変換演算から構成されてもよい。したがって、当業者であれば、挿入パイプラインを仮想化することができるので、この３段階のＳＭＣＤ設計を２段階の設計として同等に定式化することができることを理解するであろう。３段階の設計は、説明を分かりやすくするためにだけここで示される。
【０１８６】
図１７を参照すると、ＳＭＣＤ１７００は、１つ又はそれ以上の接頭パイプライン１７０１、１つ又はそれ以上の挿入パイプライン１７０２、及び１つ又はそれ以上の接尾パイプライン１７０３の集合である。個々の統合方法についてのデータは、接頭パイプライン１７０４によって受け取られ、任意に挿入パイプライン１７０２に送られ、接尾パイプライン１７０６に送られ、該接尾パイプライン１７０６によって宛先システムに送られる。いずれかのパイプラインの単一の反復は、周期と呼ばれる。プロセス全体を通じたデータの論理断片（すなわち、１７０４、１７０５、１７０６によって図により例示されるように、構成可能な変換規則によって定義されるような）の転送が、完了と呼ばれる。
【０１８７】
データフローの設計は、単一のクロスバーを最小限必要とする。クロスバーは、１つ又はそれ以上のパイプラインの間の中間仮想表示の表示交換とも呼ばれる交換を助ける論理相互接続と定義される。単一のクロスバー設計の場合には、この設計は、挿入クロスバー１７０８を用いる。３つのクロスバー設計の場合には、この設計は、示される３つのクロスバー１７０７、１７０８、及び１７０９の全てを用いる。説明のために、本発明の特定の例において、α個の接頭パイプライン、β個の挿入パイプライン、及びχ個の接尾パイプラインがあると仮定する。したがって、最小のクロスバーは、αとβの間の相互接続を必要とする。クロスバー１７０７は、α個の接頭パイプライン、β個の挿入パイプライン、及びχ個の接尾パイプラインの間の接続を提供する接頭クロスバーである。クロスバー１７０８は、β個の挿入パイプラインの各々を接続する挿入クロスバーである。接尾パイプラインの交換は、以下に説明される。
【０１８８】
接頭パイプラインと接尾パイプラインの間の直接接続がクロスバーをわたってもたらされるので、クロスバー１７０７及び１７０９が等しいものであることを、当業者は理解するであろう。したがって、２つのクロスバーかあるか又は３つのクロスバーがあるかどうかは、本発明の詳細であり、データフロー・クロスバー・アーキテクチャを定義する属性ではない。電気的接続、光相互接続、及び他のクロスバーの作動属性（例えば、ブロッキング、交換、ウォームホールなど）も、実施形態の詳細であると考えられる。クロスバーがパイプラインの周期時間により時分割されるかどうかもまた、実施形態の属性ではないが、データフロー・クロスバー・アーキテクチャを定義する属性と考えられない。
【０１８９】
全ての変換がバイトの論理シーケンス（同じような意味合いで、ストリームと呼ばれる）上で実行されるので、このデータフロー・アーキテクチャにおける全ての変換は、仮想シーケンスと呼ばれ、単一時間にメモリ内にバイトを全て配置することができず、ランダムにアクセス可能ではないが（例えば、反復的にバイトを処理することができる）、この変換は、シーケンス全体の中のバイトがランダム・アクセス手法でアクセス可能であると事実上仮定する。さらに、ＲＰＳＡを用いるＳＭＣＤの好ましい実施形態は、ＳＰＣＤが、論理的に有限のストリームだけをサポートする従来のシステムとは違って、論理的に有限（限界のある）長のストリーム及び論理的に無限（限界のない）長のストリームの両方を処理するのを助ける。
【０１９０】
ＳＭＣＤを定義する属性ではないが、上述のように、ＳＭＣＤの好ましい実施形態が、全てのパイプラインにわたって一般的に用いられる標準的な中間表示として、ＭＲＴＲを用いる。こうした実施形態において、ＭＲＴＲの使用は慎重であり、システムを通って流れる全てのデータは、可変長の多次元領域に別個にパケット化できなければならない。したがって、ＭＲＴＲは、物理層のデバイスにおける「パケット」に概念的と同等なものとして働く。さらに、ＭＲＴＲのような均一の中間表示を用いることにより、全てのパイプラインが同じ周期を使用することが可能になる。ＭＲＴＲはアプリケーション・プロトコルとは関係ないので、ＭＲＴＲは、各々のパイプラインにより処理されるアプリケーション・プロトコルに関わりなく、全てのパイプラインにわたって共通の中間表示としてさらに用いることができる。
【０１９１】
統合作動について全てのパイプラインにわたって均一の粒状性を有した状態で処理周期を用いる能力は、本発明に特有のものであり、アプリケーション・プロトコル又は統合方法にわたって如何なるこうした規則化された周期も持たない従来のシステムと根本的に異なる。したがって、従来のシステムにおいて見出される通信の全ての共通イディオム（ストリーム、ソケット、ポートなど）は、ＭＲＴＲを利用するＳＭＣＤの単一の抽象化（ＭＲＴＲ）にまとめられる。また、このデータフロー・アーキテクチャにおいて、１つ又はそれ以上のデータシンクを設けることができる。このコンテクストにおいて、データシンクは、データフローを通る別の処理経路と定義され、一時的又は持続性記憶装置において停止され配置されたデータをもたらす。データシンクは、メッセージ・キューイング（ＭＱ）内のデッド・メッセージ・キュー、又はパブリッシュ及びサブスクライブ（ＰＳ）アーキテクチャと同じように理解することができる。従来のシステムと対照的に、ルータ又はスイッチのような物理層のデバイスは、如何なるデータシンクの類似性も有さない。パケットは、静かにドロップされるか（競合におけるように、又は到達不能なＵＤＰパケットのために）、或いは全く接続されない（ＴＣＰにおけるように）のいずれかである。データシンクは、一度きりのデリバリ（Ｏ３）、トランザクション意味規則、データの妥当性検査、例外の処理、状態の調整、及び状態の保存をサポートするように、このデータフロー・アーキテクチャにおいて必要である。
【０１９２】
以下に例示されるように、パイプライン内の個々の処理段階の各々は、接合部と呼ばれ、全ての接合部の集まりは、接合部の組と呼ばれる。パイプライン、接合部、中間仮想表示、及びＳＭＣＤ内の他の全てのコンポーネントは、不透明な識別子に依存するので、このデータフロー・アーキテクチャは、前後関係上不透明であると言われる。不透明な識別子は、データを次に処理する物理的コンテクストを定めない識別子と定義される。このことは、宛先のアイデンティティを明示的に知っていることが前提条件である全ての他の種類のミドルウェア及び従来のシステムと根本的に異なる。例えば、ソケットにおいて、アドレス：ポートを、ＭＱ／ＰＳにおいてはアドレス：キュー名を、ＲＰＣにおいてはアドレス：機能＿名前を、そしてデータベースにおいてはアドレス：テーブルを知らなければならない。当業者であれば、名前解決サービス（インターネットＤＮＳのような）の使用が、宛先アドレスを知る必要性を軽減せず、人がより容易に覚えられるシステムについての名前を提供するだけであることを理解するであろう。
【０１９３】
図１８を参照すると、データフローは、接頭パイプライン１８０１で始まり、処理される特定のデータについての挿入処理の選択性によって、１８０４を介して挿入パイプライン又は接尾パイプラインのいずれかに送られ、結果物としての中間表示１８０５で終わる。接頭パイプライン１８０１は、バイトストリーム１８０３を通して通信されるアプリケーション・プロトコルを介して、統合システムにより接続されるアプリケーション・プロトコルを受け入れることによって開始する。１つ又はそれ以上の処理段階が、接合部１８０８、１８０９、１８１０、１８１１、及び１８１３を順次に実行する有限状態機械１８０２によって最初に実行される。接頭パイプライン１８０１における処理中に生じる如何なる例外も、本発明の属性である作動機構を用いて、１８１６を介して例外テーブル１８０７に報告される。最後に、実施形態の属性であると考えられる作動機構を用いて、１８１５を介してルックアサイド・バッファ１８０６にアクセスされる。
【０１９４】
プロトコル解釈接合部１８０８は、特定のアプリケーション・プロトコルの基本機構を解釈するように働く。例えば、プロトコルの解釈は、デコード、解読、順序付け、エラー回復、フロー制御、及びデータの概略解釈に依存していない他の同様のタスクのための全ての処理を実行する。この接合部１８０８は、機能的には異なるが、フレーミング、及び物理層のデバイスにおける類似したフレーム指向演算（例えば、ＯＳＩレイヤ２）に概念的と同等である。
【０１９５】
必要な場合には、フィーマット構文解釈／ブロック組立体接合部１８０９が、プロトコル解釈接合部１８０８による解釈のための準備されたデータ・フォーマットを解釈するように働く。この接合部１８０９の主要な目的は、その入力構造が、アプリケーション・プロトコルに直接依存するデータを、アプリケーション・プロトコル抽象化（例えば、ＭＱ、ＲＰＣなど）のために規則化されたブロック構造に変換することである。例えば、フォーマット構文解釈は、データの妥当性検査及びスキーマのマッピングのような操作を含むデータ・フォーマットの意味規則を解釈するのに必要な全ての処理を実行する。
【０１９６】
必要な場合には、フィルタ／ソート接合部１８１０が、アプリケーション・プロトコルに関して定められたパラメータに基づいて、ブロックについて複雑なフィルタリング及びソート操作を任意に実行するように働く。論理的に特定することができる如何なる操作も、この接合部１８１０によってサポートされる。この接合部１８１０の主要な目的は、データの選択、データの妥当性検査、データの形成、及びデータの構造又は順序を変化させることによって決まる他の概念的に類似した規則を実施することである。
【０１９７】
交差接合部１８１１は、アプリケーション・プロトコルを処理する接合部のための周期であるブロックを、中間仮想表示１８１２（ＭＲＴＲのような）に変換するように働く。したがって、これは、共有の中間表示１８１２を用いて統合システムの残りによって処理されることになるアプリケーション・プロトコルから発するデータを準備する有限状態機械１８０２内の重大な接合部である。
【０１９８】
必要に応じて、フィルタ／ソースと表示接合部１８１３は、中間仮想表示に関して定められたパラメータに基づいて、該中間仮想表示の例１８１２についての複雑なフィルタリング及びソート操作を任意に実行するように働く。この接合部１８１３からの出力は、接頭パイプライン１８０１からの結果物としての中間仮想表示１８０５である。接合部１８１３と接合部１８１０との間の差は、フィルタ／ソート操作が、接合部１８１０においてはアプリケーション・プロトコルにわたって定められるが、接合部１８１３においては中間仮想表示にわたって定められるという点である。
【０１９９】
接頭パイプライン１８０１の有限状態機械についての周期は、データのインクリメントであるブロックである。インクリメントという用語の定義は、アプリケーション・プロトコルによって決まるが、抽象は、データの集合体を表し、論理グループに組織化される。例えば、キューイング抽象化を実装するアプリケーション・プロトコル（Ｊａｖａメッセージ・サービスのような）は、単一の論理デキュー操作のインクリメントにおいてブロックを定義する。対照的に、（オブジェクト）遠隔手続呼び出しを実行するアプリケーション・プロトコル（ＣＯＲＢＡ、ＲＭＩ、又はＳＯＡＰのような）は、機能呼び出しのインクリメントにおいてブロックを定義する。
【０２００】
上述のように、有限状態機械は、中間仮想表示１８１２を出力する。このような中間仮想表示１８１２は、該有限状態機械の外部のゼロ又はそれ以上の接合部（接合部１８１３のような）により処理され、結果として生じる中間表示１８０５が、上で定義された条件に従って、挿入パイプライン又は接尾パイプラインのいずれかに送られる。
【０２０１】
有限状態機械１８０２及び接合部１８１３の機能又は実行操作は、構成テーブル１８１４により与えられたパラメータによって特殊化することができる。構成テーブル、ＧＦＩＰにおけるその役割、及び宣言型構成を提供する際のその役割は、上で説明される。また、ＳＭＣＤを定義する属性ではないが、ＳＭＣＤの好ましい実施形態は、動的有限状態機械を用いて動的構成を助ける。
【０２０２】
構成テーブル、バイトストリーム１８０３を介して接続されたシステムの特性、又は他の概念的に類似したパラメータによって保持される統合方法の特性又はパラメータに基づいて、１つ又はそれ以上の接合部の処理を省略することができる。例えば、フィルタ／ソート・ブロック接合部１８１０の実行は、一般に、論理フィルタ操作を定義しない統合方法に要求されない。最後に、当業者であれば、有限状態機械１８０２、又はフィルタ／ソート表示接合部１８１３のような該有限状態機械１８０２の外部の論理のいずれか又は両方における接合部によってパイプラインの機能を実行できることを理解するであろう。
【０２０３】
図１９を参照すると、接尾パイプライン１９０１は、接頭パイプラインの対称的なリフレクションである。したがって、接尾パイプラインのデータフローの入力は、中間仮想表示１９０３のシーケンスであり、出力は、互いに合意されたアプリケーション・プロトコルに従って、接続されたシステムと通信する有限状態機械１９０２により処理されるバイトストリーム１９０４である。接尾接合部の作動は、接頭接合部について定義されたものとそれぞれ順次対称的に同等である。図１８及び図１９のブロック間の対称の対応関係は、１８０４−１９０３、１８０５−１９０５、１８０６−１９０６、１８０７−１９０７、１８０８−１９１３、１８０９−１９１２、１８１０−１９１１、１８１１−１９１０、１８１２−１９０９、１８１３−１９０８、１８１４−１９１４、１８１５−１９１６、１８１６−１９１５である。こうした対応関係が与えられた場合には、各々の接合部についての説明は、中間仮想表示１９０５から入力され、バイトストリーム１９０４へ出力されたデータを有する、接頭パイプラインについて上で与えられたものの説明の逆の順次的・対称的等価物である。
【０２０４】
図２０を参照すると、挿入パイプライン２００１が、接頭パイプライン２００５の実行後で接尾パイプライン２０１６の実行前に任意に実行される。挿入パイプラインは、接頭パイプラインから中間仮想表示２００６を入力として受け取る。挿入パイプラインは、中間仮想表示２０１５を出力し、該中間仮想表示２０１５は、接尾パイプラインに送られる。挿入パイプラインは、ゼロ又はそれ以上の構成テーブル２００２を含み、それらは、２０１９を介して接合部の各々によってアクセスされる。挿入パイプライン２００１の処理中に生じ得る例外は、実施形態の属性である作動機構を用いて、２０１８を介して接合部によりアクセスされるゼロ又はそれ以上の例外テーブル２００４に報告することができる。実施形態の属性と考えられる作動機構を用いて、２０１７を介して接合部によりゼロ又はそれ以上のルックアサイド・バッファ２００３にアクセスすることができる。
【０２０５】
挿入パイプライン２００１の一連の接合部処理は次のとおりである。分類、組み立て、断片化２００７接合部は、ｎとｍの間の中間表示変換を可能にする任意の分類アルゴリズムに基づいて、任意の組み立て及び断片化操作を実行する。ｍ＜ｎの場合には、組み立て操作が実行され、他の場合には、断片化操作が実行された。フィルタ／ソート表示２００８接合部は、任意のフィルタリング及びソート・アルゴリズムに基づいて、中間表示のフィルタリング及びソートを実行する。フィルタ／ソート表示２０１３接合部及び分類、組み立て、断片化２０１４接合部は、それぞれの接合部２００８及び２００７と連続的・対象的に等価である。分類、組み立て、断片化２０１４からの出力は、接尾パイプライン２０１６に出力される中間仮想表示２０１５である。
【０２０６】
接頭変換２００９、ユニバーサル仮想表示２０１０、及び接尾の移送２０１２は、本発明により定義されたデータフローの一般性の核心を形成する。具体的には、接頭変換２００９は、接頭パイプラインから入ってくる中間表示を、ユニバーサル仮想表示２０１０に変換する。接合部変換２０１２は、逆の変換を実行し、ユニバーサル仮想表示２０１０を中間表示に変換する。
【０２０７】
データフロー・アーキテクチャは、接頭中間表示２００６及び接尾中間表示２０１５の両方から独立したユニバーサル仮想表示２０１０の表示を規定する以外は、このユニバーサル仮想表示２０１０についての如何なる特定の属性も定義しない。こうしたユニバーサル仮想表示を提供することができる操作についての好ましい実施形態は、上述した以下のもの、すなわち値・マッピング、スキーマ・マッピング、及び一次論理を含む。
【０２０８】
上述のように、挿入クロスバー２０１１は、挿入パイプライン間の中間仮想表示の交換を助ける挿入パイプライン交換を提供する。挿入パイプライン間での中間仮想表示の交換は、最小機能のデータフロー設計について必要とされる属性ではないが、挿入クロスバー２０１１の存在又は不存在は、実施形態の属性と考えられる。
【０２０９】
一連の不透明なマルチキュー・データ処理
当業者であれば、多くの異なる論理的に同等の技術を用いる実施形態において、本発明内の個々の接合部を計算により実行することができることを理解するであろう。さらに、接合部は、別個の計算エンティティとしての実行さえ必要としない。例えば、全ての個々の接合部は、統合された制御フローを有する１つの大きな論理ブロックにおいて理論的に実行することができる。
【０２１０】
これらの接合部の計算実行アーキテクチャについての１つの特定の実施形態は、本発明に特有のものであり、別の実行と比較した場合に重要な計算利点により動機付けられる。この特定の実施形態は、部分的に連続した不透明な多段階キューイング（ＰＯＭＳＱ）の実施形態と呼ばれる。
【０２１１】
ＰＯＭＳＱは、以下の条件によって定義される。すなわち、本発明における１つ又はそれ以上の接合部は、キューにわたって定義された標準的なエンキュー及びデキュー操作によって排他的に定義された接合部の両側の間のインターフェースを用いて、キュー・データ構造によって実行される（したがって、キューにより定義される意味規則に準拠しない両側の間のデータ交換を除く）。本発明は多数の接合部を明確な構造に組み入れるので、ＰＯＭＳＱは多段階式である。
【０２１２】
本発明が接合部の各々の間の所定の関係を定義するので、ＰＯＭＳＱは連続している。接合部の各々が所定の関係を有するが、これらの関係は、一連の接合部の各々にアクセスするように本発明を通って流れる別個のデータを制約しないので、ＰＯＭＳＱは部分的に連続しているだけである。具体的には、別個のデータは、データ処理要求によって本発明における接合部を通る所定の可変経路を与えることができる。
【０２１３】
従来技術に見出される以外の別の抽象化を提供するので、接合部にキューを用いることは、本発明に特有のことである。具体的には、本発明内のネットワーク通信を考えると、ネットワーク通信にキューを用いることは、遠隔手続呼び出し、ソケット、ストリーム、又は分散されたオブジェクトに依存する従来技術と異なる。対照的に、この実施形態は、ネットワーク通信をキュー・データ構造として要約する。
【０２１４】
本発明内で接合部についてのキュー抽象化を提供する主要な役割は、データ処理段階間の分離を助けることである。分離は、別個の段階が、入力されたデータの位置又は出力されたデータの位置を認識することなく明確な機能を提供する能力をもたらす。この分離は、ＭＲＴＲを用いることによって、より効果的になすことができ、入力されたデータ及び出力されたデータにわたって呼び出された構造及び従属する操作さえも段階から分離されることを保証する。
【０２１５】
本発明の１つの実施形態は、個々の接合部キューを識別するために、人間可読の文字列のような不透明な識別子を用いることができる。したがって、全てのデータ処理操作は、本発明が通信するコンピュータが識別するあらゆる属性から明示的に分離された不透明な識別子にわたって定義される。対照的に、従来技術は、計算において不透明でない識別子（ネットワーク通信のためのＩＰアドレスのような）に依存する。
【０２１６】
ＰＯＭＳＱキューの有界性は、本発明内の高度な機能を実装するために同等に重要な属性である。例えば、キューが本質的に制限されている場合には、サービスの質及びリソース割当てを著しく容易に実行することでき、よって、例えば、メタ・キュー操作を実行し、キューの「十分さ」を測定し、キューのオーバーフローの際の段階を通知し、平均的なキューの「十分さ」を統計的に計算することができる。
【０２１７】
対スペース
本発明の対スペース部分は、全てのノードの間で論理的に共有される名前・値の対の連想の組上に構築された、ルーズ結合されたアイソメトリック分散システムを実行する特定の方法及びシステムに関する。こうした分散システムは、広いクラスの問題範囲内の特定の計算問題を解決するのに最適な、以下に列挙される多数の固有の属性を有する。図３０乃至図５３は、本発明の対スペースの対の説明に対応する。
【０２１８】
本発明の対スペース部分の特性は、上述の分散システムについての垂直方向スキーマと同じ順序で定義される。システム内の複数のコンポーネント間の相互依存性を等しく強調しながら、各々のコンポーネントの明確な説明を可能にするので、こうした順序付けは最適なものである。
【０２１９】
本発明の対スペース部分は、単一の概念、すなわち、システム内の全てノードからアクセス可能な、（名前、値）として記号的に示される互いに共有する組の単一の対に基づいている。全てノードの間で論理的に共有されるこの対の組は、対スペースと呼ばれる。上述の用語において、対スペースは、通信抽象化である。システム内の各々のノードは、対スペースを同じに認識するので、この互いに共有された対の組は、アイソメトリックである。対照的に、従来の技術は、例えば、顧客サーバシステムにおけるようなアイソメトリックでないシステムに依存しており、「顧客」の役割を演じるノードと「サーバ」機能を提供するノードの役割を果たすノードとの間に明らかな差がある。
【０２２０】
対スペースを介して通信するノードが固有の識別子を有していず、個々のノード間の「直接」通信が形成されないので、対スペースは匿名である。匿名性はまた、アイデンティティの役割が極めて重要である従来技術とも異なる。大部分の日常的レベルにおいて、データソケットは、宛先ノードのアイデンティティを特定するソース・ノードによってノード間に接続される。したがって、定義上は、ソケットは、作動のためのアイデンティティの概念に依存しており、よって匿名ではない。
【０２２１】
アイソメトリック性及び匿名性が与えられた場合には、分散システムにおける多くの一般的概念は、こうした対スペースに適用できない。すなわち「サーバ」及び「顧客」の非対称概念も、２つのノードを連結するデータの双方向のストリームの概念も、個々のノード間の区別もない。したがって、通信抽象化は、あらゆるノードからアイソメトリックにアクセス可能な連想（名前、値）対の集まりである。対照的に、対スペースが、同時により表現に富み、さらに簡単な抽象化を定義するので、従来技術において非常に普及しているソケット及びデータストリームの抽象化は、本発明の対スペース部分により定義される通信抽象化において果たす役割はない。
【０２２２】
対スペースを定義する特性は、対の組が連想的に組織化されるという点である。ノードは、もっぱら対をなすグローバルな連想関数ｐ（名前）・値によってスペース内の値にアクセスする（又は、値を読み込む）。この関数の中で、記号「名前」は、何らかの書かれた自然言語｛例えば、英語、フランス語、日本語｝からなるテキスト文字のシーケンスに制約される。したがって、スペース内の各対は、その名前によって固有に識別され、それは、単一の値に連想的に結び付けられる。この関数の中で、記号「値」は、プログラミング言語において構成することができる任意のオブジェクトを指し、こうしたオブジェクトは、バイト、シーケンスの数、ハッシュテーブル、会計元帳、又は従来技術からの操作かされた他の概念のような、手続き型からオブジェクト指向型にわたる何らかの言語からの構造を含むことができる。
【０２２３】
対をなす関数ｐにわたって、６つの基本操作、すなわち読み取る、書き込む、除去する、通知する、ｔｅｓｔＡｎｄＳｅｔ、及びｆｅｔｃｈＡｎｄＡｄｄ（ＲＷＲＮＴＦ）が定義される。以下の変換、基本操作は、サブオペレーションに分解することができない対スペース上に定められた操作であり、これは、基本操作の構成として定められる複合操作と対照的をなす。
【０２２４】
この６つの基本操作は、次のように定められる。書き込み操作は、新しい対をなす連想をスペース内に結び付けることからなり、この新しい連想は、引き続きｐによってアクセス可能になる。この操作は、名前・値の対が引数としてスペースに挿入されることを必要とする。読み取り操作は、所定の名前にｐを適用することにより、スペース内にこれまで結び付けられた対をなす連想を取り出すこと、及び組｛＿，値｝から正確に１つから構成される値を取り出すことからなり、ここで、値は、上で定められたオブジェクトの組からの任意のヌルでないオブジェクトである。このコンテクストにおいて、記号「＿」は、「名前」に結び付けられた値がないことを意味するように定義される。
【０２２５】
除去操作は、これまで結び付けられた対をなす連想を除去することからなり、除去された対は、その後、もはやｐによりスペースからアクセスできなくなる。この操作は、名前・値の対からの名前が引数として除去されることを必要とする。通知操作は、連想が、引数として与えられた名前に文字上合致するスペースにおいて結び付けられた際に、該通知操作を呼び出したノードに信号を送る通知トリガを特定することからなる。この操作は、後続する結合ｉｌすなわち１からスペースまでに応対される名前・値対からの名前を必要とする。
【０２２６】
ｔｅｓｔＡｎｄＳｅｔ操作は、読み取り及び書き込みをマージする原子操作からなる。所定の名前の対をなす連想は、スペースから読み取られる。名前がｐにより有効な値にマッピングしない（すなわち、スペースにこのような名前に対するマッピングがない）場合には、名前・値対が、該スペース内に原子的に書き込まれる。この操作は、名前・値対を必要とし、ブールに戻る。値が書き込まれた場合はｔｒｕｅであり、その他の場合はｆａｌｓｅとなる。
【０２２７】
ｆｅｔｃｈＡｎｄＡｄｄ操作は、読み取り、書き込み、及び数値加算をマージする原子操作である。（名前、値）対の値が読み取られ、ゼロでない量が値の数値量に加えられ、新しく加えられた値がスペースに書き込まれ、予め加えられた値が戻される。この操作は、名前、ゼロでない加算量を必要とし、数値を戻すが、対の値は数値型からなると仮定される。
【０２２８】
上述の垂直方向スキーマに関して、これらの基本操作は、本発明の対スペース部分についての使用方法を定義する。これまで与えられた対スペースの機能定義は、対スペースが生成的な通信抽象化であることを確立するのに十分であり、対スペース内に挿入された各々の（名前、値）対は、それを挿入したノードから切り離され、対スペース内の如何なる対のライフサイクルとシステム内の如何なるノード（特に、このような対を挿入したノード）の関与との間に、相互依存性は存在しない。このように、ノードｎが対（名前、値）を書き込む場合には、（名前、値）は、ｎが分散システムにおいて関係し続けるかどうかに関わらず、引き続きスペース内でアクセス可能のままである。
【０２２９】
基本操作ＲＷＲＮＴは、スペースにわたって原子的に定義され、特に、対スペースは、如何なる対も結合されない間、該対スペースにアクセスするノードに対して如何なる時間も存在しないように定められる。このコンテクストにおいて、非結合は、２つの条件、すなわち（１）名前がスペース内に存在するが、値に有効にマッピングされていない、又は（２）名前がスペース内に存在するが、有効な名前によってマッピングされていない、のうちの１つ又は両方の存在と定義される。こうした通知トリガは、非結合対に結合が生じた場合に生じるように保証されるので、原子性は、通知操作の有効性も保証する。
【０２３０】
電気信号がコンピュータ間の二進数字をどのようにエンコードするかが、データソケットの固有の特性であると考えられないように、こうした基本操作が対スペースにわたってどのように実行されるかは、該対スペースの固有特性ではない。しかしながら、１つのこうした好ましい実施形態がここに提供され、このような操作についての一般的な実行の詳細を示す。
【０２３１】
従来技術の対比点として、対スペースは、タプルスペースとは著しく異なる。タプルスペースは、形式的で実際のフィールドからなるテンプレート・タプルを用いるタプルの集まり（一般にパターンと呼ばれる）にわたるパターン合致機能を定義する。形式的に、タプルは、その要素が「名前と値」対である集合クラスの例である。こうしたタプスペースのパターン合致機能は、値及びタイプ識別子及び事例タイプの両方を同等なものと考える。したがって、対スペース及びタプルスペースは、概念的に類似していると考えることができるが、その固有特性及び好ましい実施形態は著しく異なる。
【０２３２】
したがって、本発明の対スペース部分が定義する分散システムのための通信抽象化は、単に５つの基本操作を有する連想の対スペースを定義し、明示的に述べようと暗黙的に述べようと、基本の通信抽象化として２方向の２地点間のデータソケットを定める従来の技術とこれを対照させる。
【０２３３】
対スペースを２つの別個のカテゴリ、すなわち一時的なもの及び持続的なものに二分することができる。特に、各々の対スペースの固有の属性は、名前・値対が一時的に格納するか、又は持続的に格納されるかということである。一時的な対スペースは、「メモリのない」通信抽象化であり、スペースが閉じると該スペース内の全ての値が失われる（スペースの閉鎖は、ノードを介して明示的に閉じられようと、又は分散システムへの電力損失のために暗黙的に閉じられようと、スペースがもはやノードにアクセスできなくなるようになる何らかの組の段階と定義される）。持続性対スペースは、「メモリ」を有する通信抽象化であり、中間スペースの閉鎖にも関わりなく、スペース内に書き込まれた全ての値が、ノードによって明示的に除去されるまでアクセス可能なままである。
【０２３４】
通信抽象化の属性として一時性を考慮することは、従来技術と著しく異なる。従来技術は、こうした時間・動的特性が、通信抽象化の上に機能をオーバーレイする独立したコンポーネントによって定められると仮定する。例えば、持続性がバイトの読み取り及び書き込みの範囲を超えているので、持続性は、２方向のデータソケットの方法及びシステムにおける考慮事項でさえない。
【０２３５】
前に定められた垂直方向スキーマについては、その属性が、データ・プロトコル、すなわち（名前、値）対の組、６つの基本操作、操作の原子性、及び設定一時性を十分に表している自己記述的なものであるので、通信抽象化としての対スペースは注目に値するものである。全ての操作は、テキスト文字のシーケンスの同等比較に基づいている（自然言語の文字同等規則に関する。例えば、ある自然言語は、スペイン語の「ｃｈ」のように特定の文字の組み合わせについて異なるテキスト比較を行う）。同様な意味合いで、対スペースは、ノードが、構造化された通信を助けるようにデータ・プロトコルを定義することを必要としない。このことは、ノードが何らかのタイプの構造化された通信を助けるためにこのようなデータ・プロトコルを定義することを、従来技術において定められた通信抽象化が必要とするという点で、注目に値するものである。例えば、データソケットは、オブジェクトの交換についてバイト指向エンコード化及びフォーマット化を特定するノードを必要とし、タプルスペースは、システム内の明確なあらゆるオブジェクトについて、例のタイプ及び値の操作｛最小に、同等に｝特定するノードを必要とする。
【０２３６】
前に定められた垂直方向スキーマに続いて、本発明の対スペース部分は、対スペースの通信抽象化、すなわちトランスペアレントな分散ガーベッジ・コレクション、適応デリゲーション・ベースのオブジェクト呼び出し、及びトランスペアレントな一般的な適応デリゲーションを介する異種の分散オブジェクト・システムのためのサポート上に構築された幾つかの付加的な論理構造を定める。対スペースの定義と共に構成されたこれらの論理構造は、明確な分散システムをもたらす。さらに、このような付加的な論理構造は、従来技術の顕著な態様と本発明の対スペース部分を対比するために重要である。
【０２３７】
リソース管理：トランスペアレントな分散ガーベッジ・コレクション
これらの方針が、対スペースの通信抽象化についてのリソース管理を定義するので、本発明の対スペース部分の実際の適用を考える際、対スペース内に挿入されたオブジェクトのライフサイクルの管理は、特別の関心事である。具体的には、これまでの対スペースの定義には、中に挿入される｛名前、値｝対のライフサイクルについての如何なる意味規則もない。引き続いて除去されることなく、無限の数のオブジェクトがスペース内に挿入される可能性が非常に高い場合、このことは特に重要である。もちろん、こうした条件は、分散システムに利用可能な全ての計算リソースの枯渇のため、システムの故障をもたらす。
【０２３８】
本発明の対スペース部分は、該対スペースにわたって参照カウント型の分散ガーベッジ・コレクション・アルゴリズムを定め、このことは、範囲ベースのガーベッジ・コレクションをサポートするノードのためのシステムと組み合わせられた場合に、本発明の対スペース部分のためのトランスペアレントな分散ガーベッジ・コレクション｛ＴＤＧＣ｝のリソース管理方法及びシステムをもたらす。以下の説明は、各々のノードについての範囲ベースのガーベッジ・コレクションの存在を仮定する。従来技術がこのようなシステムを構成できることを実証するので、このことは、正当な仮定である。さらに、こうした非分散型ガーベッジ・コレクションをサポートするシステムは、今日一般に用いられている（例えば、ｊａｖａ）。
【０２３９】
対スペースが生成的な通信抽象化であるという事実のために、本発明の対スペース部分内のＴＤＧＣの実装は、従来技術と異なる。このように、「局所的表示」という概念がないので、従来技術において用いられる共通の構造であるプロクシ・オブジェクトに基づいた局所的参照カウントは、このようなＴＤＧＣに不適切であり、対スペースを介して通信する全てのノードが分散システムに対してアイソメトリックであるので、「プロセス」と「プロセス」の間に区別はない。
【０２４０】
トランスペアレントな分散ガーベッジ・コレクションは、参照カウント（従来技術において確立した技術である）の概念を抽象化することによって、対スペースにわたって定義される。具体的には、各々の対についてグローバル・アイソメトリック参照カウント｛ＧＩＲＣ｝を定めることができ、これは、負の値でないものに制限される。この参照カウントは、如何なる個々のノードにも制限されないが、それ自体がスペース内の｛名前、値｝対であるので、アイソメトリックである。したがって、対スペース内の対（ｘ、ｙ）ごとに、第２の「ＧＣ対」が存在し
Figure 2005504455
ここで、
Figure 2005504455
は、対（ｘ、ｙ）についての参照カウント識別子を表し、Πは、現在の数値ＧＩＲＣを表す負でない整数である。
【０２４１】
対スペースにわたって定められる２つの複合操作、すなわちロック及びロック解除は、ＴＤＧＣについての基本である。ロック操作は、ＧＩＲＣの対を増加させ、ロック解除操作は、ＧＩＲＣの対を減少させる。両方の操作は、
機能ロック（名前で）
リターンｆｅｔｃｈＡｎｄＡｄｄ（名前Ω、１）エンド機能
機能ロック解除（名前で）
リターンｆｅｔｃｈＡｎｄＡｄｄ（名前Ω、−１）エンド機能
のような擬似コードにおいて特定された、ロックされた対と関連したＧＩＲＣについてのｆｅｔｃｈＡｎｄＡｄｄの基本形を用いることによって実行される。
【０２４２】
これらの定義が意味するように、対スペース内の対（名前、値）のＧＩＲＣの値は、（名前、値）について呼び出されたロック解除操作の数より少ない、（名前、値）について呼び出されたロック操作の数として定義される。このようなロック／ロック解除操作が保持される時間は、対スペースの一時性によって決まる。具体的には、持続性対スペースは、ＧＩＲＣを永久的に定め、一時的対スペースは、各々のスペースが閉鎖されると全てのＧＩＲＣをゼロにする。
【０２４３】
この定式化を用いて、対スペースＤＧＣアルゴリズムを、ＧＣ対が
Figure 2005504455
である場合及びその場合に限って、対（ｘ、ｙ）を除去する、といったように簡潔に述べることができる。従来技術のＧＣアルゴリズムは著しくより複雑であるので、この簡潔な定式化は注目に値する。原子性を保証するために、対スペースは、このアルゴリズムを熱心に（怠惰にではなく）実行しなければならず、スペースを介して通信するノードに対して
Figure 2005504455
となるような対（ａ、ｂ）が決してないことを保証する。スペースにおける全ての対にわたるこのアルゴリズムの実装は、対スペース通信抽象化の属性である本発明の対スペース部分によって定められる。
【０２４４】
ＧＩＲＣ及び対スペースのＤＢＣアルゴリズムが、従来技術において一般的な範囲ベースの「到達可能性」アルゴリズムのような、トランスペアレントな局所化ガーベッジ・コレクション（ＬＧＣ）を実装するノードと組み合わせられたときに、分散ガーベッジ・コレクションの透明性が生じる。それが存在する場合には、各々のノードによってＬＧＣがどのように実装されるかという正確な機構は関係ない。透明性は、読み取り操作を介して既に取り出された対がノードに達成できなくなる度に、ロック解除操作を呼び出すことによって（ＬＧＣ、又は関連したシステムにより）実行される。したがって、ＬＧＣについてのスコーピング達成可能性規則が必要に応じてロック解除操作を暗黙的に呼び出すので、ＬＧＣは、プログラマーが明示的にＧＩＲＣを追跡する必要性を排除するための手段を提供する。
【０２４５】
範囲ベースのガーベッジ・コレクションの従来技術を用いて、このＴＤＧＣアルゴリズムは、こうした対についてＧＩＲＣを明示的にゼロまで減少させることなく、分散システム内のあらゆるノードがこうした対への到達可能な参照を保持する間いつでも、対がアクセス可能なままである（すなわち対スペースから制限されないのではない）ことを保証する対スペースに関するＧＣポリシーを実行する。
【０２４６】
機能呼び出し：適応デリゲーション・ベースのオブジェクト呼び出し
このような通信抽象化についてのトランスペアレントなリソース管理ポリシーと共に、対スペースを定義する属性を識別すると、垂直方向スキーマを考える際の次の目前の課題は、コンピュータ・プログラム論理の実装を容易にすることである。プログラム論理の実装手段を持たない通信抽象化は、一般に有用でないと考えられるので、このことは重要である。
【０２４７】
対スペースは、基本操作を介したルーズ結合された計算構造を定めるが、より一般的なオブジェクト指向プログラミング構造のためのサポートが、熟知性及び両立性のために必要である。上述の垂直スキーマのコンテクストの中で、該垂直方向スキーマにおいて上で紹介したように、本発明の対スペース部分は、明確なプログラマチック・インターフェースをさらに定義し、分散システムについての広い組の文脈上の意味規則を特定しなければならない。
【０２４８】
対スペース内のこうしたオブジェクト呼び出しのコンテクストは、次の基準を満たす対（名前、ｆｎ）を用いるものであり、値ｆｎは、１つ又はそれ以上の明確な機能を提供する適応機能オブジェクト（ＡＦＯ）である。例えば、単純ＡＦＯは、付加的な操作を実行することができる。ＡＦＯは、２つの数値引数を受け入れ、それらの数値合計を戻す。ＡＦＯオブジェクトは、コンピュータ・プログラミング論理を用いて特定することができる如何なる関数も実行することができる。
【０２４９】
適応デリゲーション・ベースのオブジェクト呼び出しの概念を取り入れるために、オブジェクト指向言語を用いる擬似コード・フラグメント
ｏｂｊ．ｆｏｏ（「ｔｅｓｔ」）
を考える。
【０２５０】
このコードにおいて、方法「ｆｏｏ」は、値が「ｔｅｓｔ」である単一の文字列引数を用いて、オブジェクト「ｏｂｊ」上に呼び出される。対スペースにわたってこのような関数を実行するための比較可能な構文が、再び、オブジェクト指向言語擬似コード
ｖａｒ ｆｎ＝対スペース．読み取り（「ｆｏｏ」）
ｖａｒ ａｒｇｓ＝｛「ｔｅｓｔ」｝
ｆｎ．ｃａｌｌ（ａｒｇｓ）
を用いるように表される。
【０２５１】
この擬似コードにおいて、「読み取り」基本操作は、対スペース上に呼び出され、「ｆｎ」と名づけられたＡＦＯオブジェクトを戻す。次に、長さが１である「ａｒｇｓ」と呼ばれるオブジェクトのシーケンスが構成される。シーケンスの第１インデックスには、文字列の値「ｔｅｓｔ」が割り当てられる。最後に、「ｃａｌｌ」方法は、ＡＦＯ上に呼び出され、「ｃａｌｌ」すべき引数として「ａｒｇｓ」を送る。操作の例が取り入れられると、次のオブジェクト呼び出しの公式定義を考える。
【０２５２】
対スペースにわたって定められたオブジェクト呼び出しは、適応デリゲーション・ベースのプロトタイプ機構（ＡＤＰＭ）を介して実行される。文脈付けの点で、ＡＤＰＭは、デリゲーション・ベースのプロトタイプ・プログラミング言語（例えば、Ｓｅｌｆ）において従来技術によって動機づけられる。具体的には、ＡＦＯは、デリゲーション式プロトタイプを介して何らかの関数を実行する単一のオブジェクト方法インターフェースである。上の例において、「ｆｎ」は、デリゲーション式プロトタイプとして働く。このように、ＡＦＯは、強くタイプされており（メソッド・シグニチャを定めた際に）、依然として一般的である。特定のオブジェクト上に方法を呼び出すことは、デリゲーション式プロトタイプを介して呼び出しを経路づけすることによって実行される。
【０２５３】
具体的には、ＡＦＯにわたる方法の呼び出しは、デリゲーションを介して動的に生じ、呼び出される方法のパラメータは、方法呼び出し引数パラメータに変換され（対（ｘ、ｆｎ）において名前はｘであるので、方法の名前は関係ない）、よってｆｎ内に含まれる。デリゲーション・ベースのプロトタイプ言語におけるように、ＡＦＯは、順序付けられたシーケンスの引数を受け入れる「呼び出し」（ここでは記号を使ってｃａｌｌ（）と呼ばれる）と名付けられた単一の一般的な呼び出し方法を定めるので、オブジェクト指向言語において、引数は、オブジェクトのアレイとなり、手続き型言語において、引数は、値又はポインタ参照のアレイとなる。
【０２５４】
この直感を次のように定式化することができる。すなわち、ここでは記号を使ってｍ（）と呼ばれる「ｍ」と名付けられる方法を有するｆｖ（ここで、
Figure 2005504455
）を考える。上で識別されたように、対スペースは、ｆｖの従来の知識なしに、プロクシを使用することなく、何らかのノードによってｍ（）のアイソメトリック呼び出しをサポートする。ｑパラメータ（ｐａｒａｍ１、ｐａｒａｍ２、・・・、ｐａｒａｍｑ）を用いてこのようなノードがｍ（）を呼び出すと仮定する。ここで、ｑは負でない。ＡＦＯは、ｍ（）の呼び出しを、ｃａｌｌ（）の一般的な呼び出しに動的にデリゲートし、必要に応じてパラメータを配列付けする。ｍ（）が定められた戻り値を有すると仮定すると、ｃａｌｌ（）からの戻り値が元に配列付けされ、ｍ（）からの戻り値としてトランスペアレントに戻される。上の例のコンテクストにおいて、ｍは、「ｆｏｏ」であり、ｐａｒａｍは「ａｒｇｓ」であり。ｆｖは「ｆｎ」である。記号で表すと、
ｍ（ｐａｒａｍ１、ｐａｒａｍ２、・・・、ｐａｒａｍｍ）＿ｆｖ：ｃａｌｌ（ｐａｒａｍ１、ｐａｒａｍ２、・・・、ｐａｒａｍｍ）
となる。
【０２５５】
適応機能オブジェクトの結合方法により、全ての方法が固有の（名前、値）対から「値」について呼び出されることに注意されたい。したがって、この条件は、対スペースにわたって定義された機能だけが６つの基本操作であることを保証する。したがって、デリゲーション・ベースのオブジェクト呼び出し能力を保証することは、１組の連想対から完全に構成される対スペースの仮定に反するものではない。代わりに、対スペースにわたって呼び出された方法を個々のＡＦＯ（この場合のｆｖのような）に特定しなければならず、このようなＡＦＯは、対スペース内に制限された連想対の値にしなければならない。
【０２５６】
ＡＦＯは、対スペースの全ての属性、すなわち、生成力、匿名性、及びルーズ結合を保持する。さらに、ＡＦＯがこのような属性を保持するという事実は、該ＡＦＯを従来技術とさらに区別する。
【０２５７】
ＡＦＯの存在がＡＦＯを定義するノードから制限されないという点において、ＡＦＯは生成的である。同様な意味合いで、ノードは、対を対スペース内に挿入することができ、次に、関与を停止する。生成力は、たとえノードが関与しなくなった後でもこのような対が対スペース内に存在し続けることを保証する。ＡＦＯを用いるノードが、始発ノードが現在も関係しているかどうかを確かめる手段を持たないことを保証することによって、対スペースがこのことを可能にする。
【０２５８】
ＡＦＯオブジェクトは、始発ノードを識別する如何なる情報も提供しないので、ＡＦＯは、対スペースの匿名性も保持する。このことは、特定のノードのアイデンティティが重要である従来技術において定められたシステムと対照をなす。例えば、インターネットのような顧客・サーバシステム（ＤＮＳを介してドメイン名を使用する）は、アイデンティティを用いなければ可能ではない。
【０２５９】
最後に、始発ノードと呼び出しノードとの間の唯一の通信が、適応呼び出し意味規則の実装であるので、ＡＦＯはルーズ結合である。同様な意味合いで、対スペースにおいて互いに共有する組の対により与えられる以外のあらゆる方法で、ノードｆがノードｇと通信する機能はない。
【０２６０】
従来技術により定められる方法及びシステムと異なり、ＡＦＯは、「サーバ」（呼び出されたオブジェクトがホストとして働くノードと定義される）又は「顧客」（ホストとして働くオブジェクト上の機能を遠隔呼び出しするノードと定義される）のいずれかに対するプロクシの生成を必要としない。従来技術において、各々のプロクシは、それぞれのノードについて、１組の強くタイプされたメソッド・シグニチャを定める（ＲＭＩにおけるようにオブジェクトにカプセル封入されるか、または手続き的に）。各々のノードは、呼び出し意味規則、パラメータ配列付け、戻り値の処理、及び分散システムに特有の他の意味規則を管理するのに、このプロクシに依存する。対照的に、ＡＤＰＭは、強くタイプされた方法インターフェースを有する単一の一般的なＡＦＯに依存しており、よって、ＡＦＯをＪａｖａのような強くタイプされた言語と両立性がある。
【０２６１】
対スペースがプロクシの使用を必要としないという事実は、実際的理由及び理論的理由から極めて重要である。具体的には、従来技術に定められるシステムは、分散システム内で用いられるあらゆるオブジェクトについて、プロクシを生成しなければならないことを例示する。このように、プロクシの使用により、ユーザがシステム内で使用される可能性がある全てのオブジェクトを予め定めることが要求される。対照的に、対スペースは、スペース内に挿入することができるＡＦＯオブジェクトについての制限がなく、さらに、こうしたＡＦＯオブジェクトについての先験的な知識を必要としない。このように、対スペースを用いるプロクシの使用は、該プロクシの固有の定義に反するので、理論的にこれらを一緒に使用することはできない。
【０２６２】
最後に、本発明の対スペース部分は、デリゲーション・ベースのオブジェクト呼び出しを使用し、該対スペースにわたるオブジェクト特定の強いタイプの点検を実行する必要性を排除する。プロクシは強いタイプの点検を実行するが、対スペースと共に使用することができないので、このことは必要である。代わりに、デリゲーション・ベースのオブジェクト呼び出しは、ｃａｌｌ（）を介する単一の明確なＡＦＯを用いて、機能が対スペースにわたって定められることを可能にし、強くタイプされたメソッド呼び掛けを弱くタイプされた遠隔デリゲーションに変換する。上の例において、強くタイプされたメソッド呼び掛けはｆｏｏ（）であり、弱くタイプされた遠隔デリゲーションは、「ａｒｇｓ」を有するｃａｌｌ（）を介する。
【０２６３】
形式的に、ＡＤＰＭに対する必要性は、（１）強くタイプされた点検は、コンパイル前（実行前）にオブジェクト及びメソッド・シグニチャを必要とし、それは不可能である、（２）対スペースは、（名前、値）対の値として任意のオブジェクトをサポートし、該オブジェクト、そのタイプ、またはそのメソッド・シグニチャについての先験的な知識がないと仮定する、（３）対スペースは、アイソメトリック及び動的であり、静的にコンパイルされたインターフェース定義（ＩＤＬを介した）又は非アイソメトリック・プロクシ（例えば、スタブ及びスケルトン）をサポートする可能性を排除する、という幾つかの理論的理由から、上述のように、文字列タイプの点検を対スペースによってサポートすることができないという事実によって必要とされる。
【０２６４】
相互運用性：トランスペアレントな一般的な適応デリゲーション
トランスペアレントな一般的な適応デリゲーション（ＴＧＡＤ）は、既存の分散オブジェクト・プロトコル（例えば、ＣＯＲＢＡ、ＣＯＭ、ＲＭＩ）により実行されるオブジェクトからの機能の呼び出しをサポートする、上述の適応オブジェクト呼び出しの一般化である。具体的には、使用のシナリオは、ノードが、ＡＦＯ以外の分散オブジェクト・プロクシにおいて定義された対スペースのオブジェクトから機能を呼び出そうと望む場合である。もちろん、既存のシステムとの相互運用性及び両立性を与えるために、このタイプの異種の適合は重要である。
【０２６５】
前段落の例において、「ｏｂｊ」が別の分散プロトコル（例えば、ＣＯＢＲＡ）を介してアクセス可能なオブジェクトであり、「ｆｏｏ」が「ｏｂｊ」を介して遠隔呼び出しされる場合には、ＴＧＡＤが必要である。
【０２６６】
本発明の対スペース部分は、分散プロトコルごとに１つの固有のＡＦＯ適応ブリッジを介してＴＧＡＤを実行する。適応ブリッジは、ＡＦＯを分散プロトコルにエクスポートし、引数を適切に配列付けし、対スペースと他の分散プロトコルとの間の値をトランスペアレントに戻すために必要とされるプロクシ又はＩＤＬを定義する。具体的には、ブリッジは、呼び出しに対してプロトコル特定のパラメータを定義し、他の分散プロトコルに局所的ＡＦＯオブジェクトを認識させ、２方向の呼び出しをサポートする。すなわち、（１）他の分散プロトコル・ネットワーク全体にわたってオブジェクトから機能を呼び出すように、対スペースにおけるノードにより呼び出されるか、又は（２）分散プロトコル・ネットワークを通じて、オブジェクトは、対スペースのＡＦＯから機能を呼び出すことができる。
【０２６７】
ＲＭＩをこのコンテクスト内の分散プロトコルの例と考える。対スペースを用いて呼び出しを双方向に交換するＲＭＩのために、単一の固有のＡＦＯブリッジを定義しなければならない。具体的には、このブリッジは、デリゲーション・ベースのｃａｌｌ（）方法をエクスポートするＲＭＩプロクシ・スタブを定義しなければならず、そのため、該ブリッジは、ＲＭＩネットワークにアクセス可能となる。その際に、ＲＭＩオブジェクトは、ブリッジを介して対スペース内のノードにアクセス可能となり、その逆も同様である。
【０２６８】
形式的に、強くタイプされたＡＦＯは、プロトコルによって、ＡＦＯについての全ての方法を双方向に呼び出すことができる一般的なオブジェクトデリゲーションを提供するので、分散プロトコルにつき、正確に１つの適応ブリッジが必要とされる。概念的には、対スペースについて単一のＡＦＯが存在するという同じ理由のために、プロトコルにつき正確に１つのブリッジが存在する。ＡＦＯは、オブジェクト特定のプロクシへの必要性を排除し、よって、単一の一般的なインターフェースによって、全てのオブジェクトに対するメソッド呼び掛けを定義することができる。
【０２６９】
分散プロトコルが、対スペースの意味規則を認識していず、ブリッジにアクセスする対スペース内のノードが、ＡＦＯを実行するオブジェクトが他の分散プロトコルを用いることを認識してもいないので、この適応変換の透明性が生じる。さらに、この透明性は、ＴＧＡＤを実装する際に対スペースの意味規則の全てが保持されることを保証するのに必要かつ十分である。
【０２７０】
統一されたデータ基準変換
今日、多数の個々のコンピュータ・システムを互いに通信させ、データを交換させるのに必要なのは、ほぼ全ての情報システムにとって基礎となる機能である。具体的には、コンピュータを使用する大半の組織は、多数のコンピュータを有しており、コンピュータを利用した多くの種類のビジネス・プロセスを実行するためにデータを交換しなければならない。
【０２７１】
本発明の統一されたデータ基準変換の部分の目的は、データ交換、変換、及び処理規則を定めることができる１つの共通の抽象化を定義することである。より具体的には、ソースと宛先コンピュータ・システムとの間に抽象的マッピングを定義する方法及びシステムである。個々のコンピュータ・システム間の通信を実行するために、全てのミドルウェア・システムが同じ抽象的方式を共有するが、マップ、その構造、及びその実装技術の正確な意味規則は、特定の実施形態に密接に依存する。
【０２７２】
本発明のこの統一されたデータ基準変換の部分は、一般性を失うことなく、既存のミドルウェアの意味規則から独立した普遍的抽象化を用いてデータを表す技術に基づいて、このようなミドルウェアの処理を眺める別の技術を定義するものであり、こうした既存のミドルウェアの意味規則の代表的な例には、バイト順序付け、データ表示、プロトコルのエンコード、及びセキュリティ・パラメータが含まれる。
【０２７３】
本発明のこの統一されたデータ基準変換の部分は、データを、何らかの特定のミドルウェア抽象化から本発明の統一されたデータ基準変換の部分と両立性のある表現に双方向に変換する基準変換の組を定義する。本発明のこの統一されたデータ基準変換の部分は、既存のミドルウェア抽象化とは明示的に互換性のない（変換されない）表現を定めるので、こうした基準変換は、既存のシステムとユニバーサル・データ基準との間にインターフェースを定めることが必要である。図５１は、ソース及び宛先変換（以下に定義される）と共に、ＵＤＢの線形代数ブロック図を提供する。
【０２７４】
ユニバーサル・データ基準（ＵＤＢ）は、基本操作の組を定義すると共に、何らかのミドルウェア通信抽象化からのデータの表示及び変換を助ける新規な抽象化である。プロセス境界の非同期通知を提供するために、１つ又はそれ以上の同期化プリミティブも、ＵＤＢにおいて定義される。ＵＤＢの新規性は、それらのミドルウェア抽象化の発生に関係なく、単一の表示手段を用いて、あらゆるデータ及びプロセス論理を一意的に表すことができるという事実から生じる。このように、ＵＤＢは、該ＵＤＢ内で処理するデータを利用可能にするために、既存のミドルウェア・システムとの間で双方向にデータを変換する一対のソース及び宛先変換が必要であるという点で、従来技術と異なる。図４３は、ＵＤＢについての抽象的ブロック図を図示する。
【０２７５】
ＵＤＢは、３つのコンポーネントからなる。第１に、ＵＤＢ内のデータを表す１つ又はそれ以上の同等の手段、第２に、ソフトウェア論理によって、ＵＤＢ内のデータについての変換がどのように特定されるかを定義する基本操作の組、第３に、ＵＤＢにわたって非同期及び同期処理イベントにどのように信号を送るか特定する非同期化プリミティブの組である。このように、３つのコンポーネントの全ては、本発明のこの統一されたデータ基準変換の部分の固有の特質であるが、双方の特定の特性は、好ましい実施形態の事例である。
【０２７６】
ＵＤＢにおいて表される間、データが読み取られ、書き込まれ、変換される方法を容易にするために、１つ又はそれ以上の操作プリミティブが必要とされる。具体的には、操作プリミティブは、データがＵＤＢにおいて表される方法と両立性がある、このような読み取り／書き込み操作についての技術を定義する。本発明のこの統一されたデータ基準変換の部分は、ＵＤＢにおいて表されたデータについての特定の操作を定義しないので、操作プリミティブの正確な意味規則は、実施形態に特有のものである。
【０２７７】
基準変換の間で信号を送るのを助けるために、１つ又はそれ以上の同期化プリミティブが必要とされる。同期化プリミティブにより、こうした同期化は、各々の変換の間の同期又は非同期関係のいずれも容易にすることができる。一般性を失うことなく、ブロック同期化アルゴリズムを用いることは、ＵＤＢの同期実行を助け、非ブロッキング同期化アルゴリズムを用いることは、ＵＤＢの非同期実行を助ける。一般性を失うことなく、図４６は、ＵＤＢの同期実行を示し、図４７はＵＤＢの非同期実行を示す。当業者であれば、ＵＤＢの非同期又は同期性質は、特定の実施形態によってＵＤＢのために選択された同期化プリミティブのアーチファクトであることを理解するであろう。
【０２７８】
既存のミドルウェア・システムにおいて構成されたデータは、定義上は、このようなＵＤＢと両立性がないので、ミドルウェア抽象化の各々の事例のために、一対の基準変換（ＢＴ）が必要とされる。第１は、ミドルウェア抽象化の事例から生じるデータ及びプロセス論理をＵＤＢに変換するソース基準変換（ＳＢＴ）である。第２は、ＵＤＢ内のデータ及びプロセス論理をデータ宛先のために必要とされるフォーマットに変換する宛先基準変換（ＤＢＴ）である。本質的に、基準変換は、ＵＤＢと両立性がある別のフォーマットに含まれるデータを作成するための、最小限必要な変換である。
【０２７９】
ソース基準の変換及び宛先基準の変換の双方は、２つの別個の段階、すなわちフォーマット変換及びプロトコル変換からなる。フォーマット変換は、データをＵＢＴとの間でデータ・ソース又は宛先の論理データ・フォーマットに変換する段階である。プロトコル変換は、ミドルウェア抽象化に適したプロトコルを介してフォーマットされたデータを変換、獲得、又は伝送する段階である。ＳＢＴは、プロトコル変換を実行し、次にフォーマット変換を実行する。ＤＢＴは、フォーマット変換を実行し、次にプロトコル変換を実行する。図４５は、ユニキャスト、単方向のＵＤＢ処理のサンプル事例のためのフロー図を定める。
【０２８０】
例えば、ソース抽象化がＲＭＩを介して受け取ったＸＭＬデータである場合を考える。この例において、ＸＭＬはデータ・フォーマットであり、ＲＭＩはプロトコル（ミドルウェア抽象化であるＲＰＣを有する）である。ＸＭＬは、エンコード化、文字の組の解釈、及び意味の解釈（明示的又は暗黙的スキーマ）を定義する。ＲＭＩは、ワイヤライン・プロトコル及びＲＰＣと同等な取り決めを定義する。この場合のＳＢＴは、次の２つの一連の段階からなる。第１に、ＸＭＬデータをＲＭＩプロトコル層から受け取り、アンラップしなければならない。第２に、ＸＭＬデータ（この場合には、ＲＭＩデータ・ペイロードにおけるバイトのストリームによって表される）は、ＵＤＢに適したフォーマットに変換しなければならない。
【０２８１】
対称的に、宛先抽象化が、ＲＭＩを介して送られたＸＭＬデータである場合を考える。前の例におけるように、ＸＭＬはデータ・フォーマットであり、ＲＭＩはプロトコル（ミドルウェア抽象化であるオブジェクト指向ＲＰＣを有する）。この場合のＤＢＴは、次の２つの一連の段階からなる。第１に、ＵＤＢフォーマットのデータをＸＭＬデータに変換しなければならない。第２に、ＸＭＬデータをＲＭＩプロトコル層内にラップし、宛先に送らなければならない。
【０２８２】
ＳＢＴの後に、かつＤＢＴの前に、一旦データがＵＤＢ内でアクセス可能になると、１組の中間変換（ＩＴ）を定義することができる。このような中間変換は、ＵＤＢにわたって定義された共通の基本操作の単一の組を用いて、こうしたＩＴの組を定義する。変換論理を簡潔かつ的確に表現するこの能力は、今日こうした変換を成文化するのが困難なことが多い従来のミドルウェアと対照をなす。今日のこうした複雑さの理由は、互換性がない抽象化、互換性がないデータ・フォーマット、互換性がないＡＰＩ、又は複雑なアダプタ／インターフェースへの要求から生じる。図４８は、中間変換についてのブロック図を提供する。
【０２８３】
ＵＤＢにおける中間変換の単純性は、幾つかの要因から生じる。第１に、ＵＤＢは、複数のミドルウェア・システムからのデータ及びプロセス論理が同様の方法で中間変換論理を介して表され、作用されることになるのを助ける操作及び同期化プリミティブの共通の組と共に、共通の表示を提供する。第２に、共通の操作プリミティブの共用の組は、どのタイプのミドルウェア・システムとＵＤＢが通信するかに関わりなく、任意の複雑な中間変換が一旦特定されることを可能にする。したがって、各々のミドルウェアを抽象化するために、固有の成文化を要求する代わりに、変換論理を一旦書き込み、複数のシステムに適用することができる。第３に、単一のＩＴによって多数の抽象化からのデータをトランスペアレントに作用させることができるので、ＵＤＢの３つの共通特性により、中間変換論理の表現力を広げることが可能になる。より具体的には、ＵＤＢは、別個のミドルウェア・システムの間のパーティション境界をマスクする能力を提供し、操作及び同期化のために共用された共通のプリミティブを用いて、統一化されたデータ表示の仮想化をもたらす。第４に、ＵＤＢは、今日では互換性のない複数のミドルウェア抽象化にわたる中間変換論理を定義する能力を提供する。第５に、ミドルウェア抽象化の数に関わりなく、ＵＤＢを横断する中間変換を書き込む必要性は１回だけであり、このようなＩＴを再使用するための基礎を提供する。このような再使用は、（１）互換性のない多数のミドルウェア抽象化を横断するＩＴを定義するこうした能力が存在しない、（２）こうした能力がないことにより、一度定義されたＩＴが他の抽象化を横断して再使用されることが防止される、という２つの理由のために、従来技術では不可能である。
【０２８４】
ＵＤＢを定義する操作属性は、ＳＢＴ及びＤＢＴが、中間変換に対してトランスペアレントであるという点である。具体的には、共用プリミティブの共通の組を用いて変換論理を表現し、データがどのように到着し、ソースから変換され、宛先に送られ変換されるかという意味規則を無視することができる。本質的に、変換論理は、データがＵＤＢの単一の表示で存在し、変換が、正確にその表示にわたって定義されるべきであると仮定するように書き込まれる。さらに、ＵＤＢ上に定義された変換は、それがＳＢＴ及びＤＢＴによる作用を受けるので、データ・ソース及び宛先からのデータ、属性、及びプロセス論理にアクセスできるだけである。同様な意味合いで、中間変換論理は、ソース又は宛先のデータ・フォーマット、表示、又はミドルウェア抽象化の特性にアクセスすることができず、又はこれらに左右される。したがって、ソース及び宛先データストリームの基礎となる「ロウ」に対して「不正をはたらく」又はアクセスする方法はない。この透明性は、ソース及び宛先変換の意味規則が、正確にミドルウェアが定義するものである従来技術とは著しく異なる。
【０２８５】
ソース基準変換及び宛先基準変換は、一緒に構成される１つ又はそれ以上の独立した段階から構成することができる。例えば、ＤＢＴは、多数のデータ宛先にわたってＵＤＢに含まれるデータをトランスペアレントに多重化することができる。一般性を失うことなく、こうした多重化の意味規則に対する代表的な動機付けは、ＵＤＢにおいて連続的に表されたデータを、１つ又はそれ以上の異機種のミドルウェア抽象化を利用できる独立した多数のデータ宛先に分散させることである。対称的に、ＳＢＴは、多数のデータ・ソースに含まれるデータを、ＵＤＢにトランスペアレントに逆多重化することができる。このような逆多重化の意味規則に対する代表的な動機付けは、１つ又はそれ以上の異機種のミドルウェア抽象化を利用できる独立した多数のデータ・ソースからのデータを、連続的にＵＤＢに集約することである。
【０２８６】
その構成と共に個々の段階の意味規則と定められたこうした構成論理を任意に高度に実行することは、全て特定の実施形態の属性であると考えるべきである。前の事例の両方において、隣接性の解釈は、実施形態に特有である。例えば、個々に開示された実施形態において、隣接性は、ストリームにおける連続するバイトの組、又はリング・バッファにおける連続するバイトの範囲と定義される。
【０２８７】
ここで定式化されたように、ユニバーサル・データ基準は、従来技術における別の定式化からこれを明確に定義する幾つかの属性を有する。
【０２８８】
第１は、ユニバーサル変換の互換性である。ＵＤＢの実施形態は、全てのミドルウェア抽象化についてＳＢＴ及びＤＢＴをサポートする能力をもたなければならない。具体的には、ＵＤＢの実施形態は、実行可能であり明確に定義された変換を理論的にサポートするのに十分に一般化されなければならない。実施形態は、このような変換の全てを実際に定義するために要求されるのではなく、ＵＤＢが、理論的にこうした変換を連続的に定義できなければならない。
【０２８９】
この第１の属性は、既存のミドルウェア抽象化を用いて最もよく例示される。具体的には、他の全てのミドルウェア抽象化と変換・互換可能なこうした抽象化は存在しないので、ミドルウェア処理の複雑さは今日確かに存在する。例えば、メッセージ・キューは、ルーズ結合されたコネクションレス型通信を提供するための非同期キュー・ベースの構造である。本来、ＲＰＣは、コネクション型の同期密結合通信を必要とするので、定義上は、メッセージ・キューは、遠隔手続き呼び出しと互換性がない。従来技術は、中間変換を定義できる基本操作の組を提供する一方で、メッセージ・キューと、ソース及び宛先データ・ソースの意味規則を互いに保持する何らかの任意のミドルウェア抽象化との間に変換が存在しないことを確立した。このように、メッセージ・キューは、ＵＤＢの潜在的な実施形態としてふさわしくはない。
【０２９０】
第２に、ＵＤＢの操作定義は、ＵＤＢの実施形態が、２つ又はそれ以上の既存のミドルウェア抽象化の組合せでないことを要求する。具体的には、ＵＤＢの実施形態の表示及び変換の意味規則は、他のミドルウェア抽象化と変換・互換性がなければならないが、別の抽象化を用いて定義しなければならない。
【０２９１】
第３に、ＵＤＢが実際的に有用になるように、こうした実施形態は、利用可能なハードウェアで許容可能な性能に修正できるようにしなければならない。生来、本発明のこの統一されたデータ基準変換の部分の新規で実際的な適用可能性は、ＵＤＢが一般的に利用可能なコンポーネントを用いて実際的にＵＤＢを実行する能力によって決まる。
【０２９２】
メッセージ・マップ変換に比較して、基準変換は、ＵＤＢと従来技術との間の対比を明白に例示する。具体的には、メッセージ・マップ変換（ＭＭＴ）は、多くのタイプのミドルウェアによって実行され、メッセージ・ブローカは、このようなものの代表的な例である。概略的な流れ表示については、図４４を参照されたい。具体的には、ＭＭＴは、ソースデータ表示と１つ又はそれ以上のターゲット・データ宛先との間でデータを直接変換するための命令である。このようなＭＭＴの代表的な例は、スキーマ変換、データ変換、及びプロトコル変換である。このようなメッセージ・マップ変換の利点は、これらが、依然として単一のミドルウェア抽象化（この場合にはメッセージ・ブローカリング）にわたって定義されながら、基礎となるデータ表示フォーマット（ＥＤＩ又はＸＭＬ）を隠すことによって、複雑さをマスクしようとする点である。したがって、ＭＭＴは、ソースから来るデータがどのようにして、宛先と互換性があるように変換されるかを定義する、１つ又はそれ以上の中間変換である。ミドルウェア用語において、メッセージ変換層は、ソースから入ってくるデータを収集し、ＭＭＴに適用し、発信されるデータを宛先に分散させる機能の集まりである。
【０２９３】
ＭＭＴと対照的に、ＵＤＢは、最小限の３つの別個の変換のカテゴリを定め、それら３つ！のうち、多くとも１つの変換のカテゴリを、アイデンティティ変換の組とすることができる。第１に、１つ又はそれ以上のソース基準変換は、データを起点ソースフォーマットからＵＤＢに変換するための規則を定義する。第２に、１つ又はそれ以上の宛先基準変換は、データをＵＤＢから発信宛先フォーマットに変換するための規則を定義する。第３に、１組の中間変換が、ＵＤＢのデータをどのように操作して所望の中間論理を達成するかについての規則を定義する。ソース及び宛先フォーマットはＵＤＢと単純に互換性がないので、定義上は、第１及び第２のカテゴリは、アイデンティティ変換とすることができない。第３のカテゴリは、データが何の変換もなしにソースと宛先との間で送られるヌルの場合に、アイデンティティ変換とすることができる。
【０２９４】
このような統一されたデータ基準の利点は、その特定の属性が、その基準内のデータについて定義された操作を、こうした基準で定義されていない個々の異機種のデータストリームに対して定義された同等の操作より実質的に容易にするという点である。本発明のこの統一されたデータ基準変換の部分の新規性は、ＵＤＢのプログラマチックな透明性と組み合わされた、２つの境界変換、中間変換の特定の組み合わせから生じる。
【０２９５】
本発明のこの統一されたデータ基準変換部分の１つの実施形態は、拡張可能な非同期のイベント駆動型モデルを介して、異機種のデータストリームをこの基準に変換することによって、ＵＤＢを実行する。このような実施形態は、ユーザが望むとおりに、境界のないバイトストリーム又はリング・バッファのいずれかを介して、ＵＤＢと個々の異機種のストリームとの間の境界を露出させる。以下の全体にわたって、説明は、リング・バッファを介した本実施形態の定式化に限定される。従来技術が実証するように、リング・バッファと境界のないバイトストリームとの間の自然変換が存在する。リング・バッファ内の読み取り及び書き込みポインタを保持し、該読み取り及び書き込みポインタ間の循環性を守りながら該リング・バッファから連続的に読み取ることによって、バイトストリームを構成することができる。当業者であれば、これが確立されありふれた変換であることを容易に理解するであろう。
【０２９６】
この実施形態の場合には、各々の特定のミドルウェア抽象化のためにＳＢＴ及びＤＢＴが必要とされる。具体的には、この実施形態のＳＢＴは、ミドルウェアに適したフォーマット及びプロトコルを用いて物理的ネットワーク・インターフェースを介して伝送されたデータを受け入れ、これをリング・バッファに変換する。したがって、どのミドルウェア・システムがこの実施形態と通信しているかに関わらず、該ミドルウェア・システムによって通信されるデータ及びプロセス論理は、固定長のリング・バッファにわたる連続したバイトアレイに変換される。図９は、ＳＢＴ変換を図示する。対称的に、この実施形態のＤＢＴは、連続したバイトアレイを有する固定長のリング・バッファ内に格納されたデータを、宛先ミドルウェア・システムに適したフォーマット及びプロトコルに受け入れる。図４６は、ＤＢＴの変換を図示する。
【０２９７】
本発明の統一されたデータ基準変換の部分は、帰納的に構成された際に、複雑な中間変換論理を任意に定めるのに十分な２つの基本操作を定義する。具体的には、読み取り操作及び書き込み操作を定める。これらの基本読み取り及び書き込み操作は、標準的マイクロプロトコルのランダム・アクセス・メモリ上の標準ＬＯＡＤ及びＳＴＯＲＥ操作に等しい。従来技術において広範囲に詳述されるように、ＬＯＡＤ操作は、一般にＵＤＢを実行するプロセスの仮想メモリ・スペース内にあるメモリ・アドレスを受け入れ、そのアドレスでランダム・アクセス・メモリに格納された値を戻す。ＳＴＯＲＥ操作は、一般にＵＤＢを実行するプロセスの仮想メモリ・スペース内にあるメモリ・アドレスと値とを受け入れ、次に、その値をランダム・アクセス・メモリ内のメモリ・アドレスに書き込む。一般に、ＬＯＡＤ及びＳＴＯＲＥ操作の両方は、ランダム・アクセス・メモリ又は何らかの中間キャッシュと、マイクロプロセッサ内の物理的レジスタとの間でデータを交換する。
【０２９８】
３つのカテゴリの変換は、同期化条件変数を介して遷移境界に信号を送る。一般性を失うことなく、このような遷移境界は、基準変換、すなわちソース変換、中間変換、及び宛先変換を完了することからなる。具体的には、中間変換は、ソース変換の完了を示し中間変換を要求するＳＢＴからの通知を非同期的に待つ。ＤＢＴは、中間変換の完了を示し宛先変換を要求するＩＴからの通知を非同期的に待つ。条件変数は、非同期的な待ちについて、高性能な非ポーリング技術を定義するので、同期化プリミティブとして条件変数を定義することは、実際の実行における最適な性能を提供する。同期化プリミティブの中で、一般に、従来技術では、条件変数は、待ちによる計算プロセッサ容量の消費を最小にするのに最適な機構であると考えられている。条件変数は、一般に従来技術が「ビジーウェイティング」と呼ぶものを排除する。
【０２９９】
本発明の統一されたデータ基準変換の部分は、中間変換論理を特定する自然手段及び直観的手段を提供することによって、すなわちメモリ内の連続範囲のバイトについての読み取り及び書き込み操作だけを用いることによって、ＵＤＢの新規性及びプログラマチックな値をカプセル化する。本質的に、ＵＤＢは、ＳＢＴ及びＤＢＴを用いて、ソース及び宛先ミドルウェア・システムからのデータを連続した領域のバイトに変換する。このような表示は、これまで、従来のミドルウェア・プログラミング技術を用いて手続き的に特定しなければならなかった複雑な変換論理を、メモリの読み取り及び書き込みを簡単化するものとして特定することを可能にする。図４７は、ＵＤＢのこの実施形態において中間変換が定義できるフロープロセスを図示する。偶然ではなく、ＵＤＢのこの実施形態は、ミドルウェアのデータ、及び独立型コンピュータのものと概念的に等しいプロセス論理のパースペクティブを提供する。したがって、ＵＤＢは、現在のところ別個のミドルウェア・システムを区分する物理的及び論理的境界をマスクすることによって、ミドルウェア変換のこれまでの複雑さを排除するものである。さらに、データがどこから発生し、又はどこに送られるかに関わらず、メモリ内のバイト範囲が同じ技術（読み取り及び書き取り）を用いて変換されるので、ＵＤＢのこの実施形態は、本発明のこの統一されたデータ基準変換の部分の同質でトランスペアレントな事例を提供する。
【０３００】
さらに、本発明のこの統一されたデータ基準変換の部分と従来技術との間の相違が、共通の中間技術を実行するための、例のプログラミング技術及び対応する擬似コードを介してさらに対比される。例えば、２つのデータベース間でデータを直接移動させる単純化した例を考える。従来技術は、このようなプロセス「データベース指向ミドルウェア」を実行する技術を定める。専門的に言えば、どちらの場合においても同じ概念実行が存在するので、このプロセスがアプリケーション論理を介して実行されるか又はデータベース・ゲートウェイを介して実行されるかのいずれであるかは関係ない。
【０３０１】
図４９に図示された、従来技術の技術を用いるプロセスは、おおよそ次のような論理を定義する。
（１）ソース・データベースｓへの接続を開く
（２）宛先データベースｄへの接続を開く
（３）取り出しデータｄについてのデータベース・コマンドを実行する
（４）ｓからのデータベース・コマンド結果を保存する
（５）必要に応じてｄを変換する
（６）ｄについてのデータベース・コマンドを実行し、ｄを送信する
（７）ｄを消去する
（８）ｄへの接続を閉じる
（９）ｓへの接続を閉じる
【０３０２】
明らかに、前の論理は、データベース・アクセス基準（例えば、ＳＱＬ）、データベース・ワイヤ・プロトコル（各々のデータベースに適した）、及び「ｄ」の変換を実行するのに用いることができる所定の操作の組のような、データベース・ミドルウェア抽象化に依存する。
【０３０３】
当業者であれば、分散トランザクション処理を付加する、又は読み取られ書き込まれるデータについての安全アクセス点検を実行するといった複数の機能強化を用いて、簡略化の例を飾ることができることを理解するであろう。さらに、プロセスの目的を変えることなく、第１及び第２のコマンドを逆にするといったような、こうした論理の正確な順序を再順序付けすることができる。
【０３０４】
図５０に図示されたこれまでのデータベース指向のプロセス論理を、以下のＵＤＢ論理と対照させる。
（１）値をソースメモリの長さｎのバイト範囲から宛先メモリの長さｍのバイト範囲に変換する（ｍは、ｎと等しくても等しくなくてもよい）
（２）同期化技術によって処理完了信号を送る
【０３０５】
当業者であれば、これまでのものと比較して、本実施の利点を容易に理解するであろう。さらに、当業者であれば、共通の複数の機能強化を、データベース指向のミドルウェアによって定められたプロセスよりも、ＵＤＢプロセスに対して著しく容易に直感的に定め得ることに同意するであろう。
【０３０６】
ゼロコピー方式のトランスペアレントなネットワーク通信
２つ又はそれ以上の独立したコンピュータ間の情報のバイトストリームを通信するプロセスは、全てのコンピュータ・システムのインターネットワーキングの基礎である。全てのネットワーク及びサーバ・ベースのソフトウェア・プログラムの機能は、このような能力によって決まる。さらに、このようなネットワーク通信の速度が増加するにつれて、一般に、このようなプログラムの性能及び有用性が良くなると考えられる。このように、コンピュータ・ネットワーキングの重要な目的は、処理能力（一般に、バイト／秒として測定される）を連続的に増加させ、物理的相互接続の待ち時間（一般に、伝送においてミリ秒の遅れで測定される）（例えば、情報のパケットが物理的ネットワークのインターフェース・カード間に分散される速度）を減少させ、アプリケーションにおけるネットワーク通信の処理に費やされる待ち時間を連続的に減少させ、操作システム・カーネル／ライブラリにおけるネットワーク通信の処理に費やした待ち時間を連続的に減少させることを含む。
【０３０７】
このような性能要件の最適な実行を達成するために、現在のところ最良であると考えられる方法は、従来技術において一般的に「ゼロコピー」と呼ばれる技術を用いることである。このゼロコピーは、単に、一方向のネットワーク通信に関係するバイトを、ユーザレベルのアプリケーションと、ネットワーク・インターフェース・カードのカーネル又はメモリ・マップ・バッファのいずれかとの間で共用されるメモリ領域内に正に一度だけコピーする技術である。ゼロコピーは、共通点のないメモリ領域間の過剰なコピーの全てを排除するので、理想的であると考えられる。このようなコピーには、多くのコンピュータ・プロセッサ及び記憶バス・サイクルが必要とされるので、こうした過剰なコピーの排除は重要である。現在、バス、ネットワーク・インターフェース・カード、及びネットワーク相互接続製品によって与えられる性能は、伝送されたデータを配信エンド及び受信エンド上のホストコンピュータ・プロセッサによって処理できる速度を超えているので、近年これらの技術は特に重要である。このように、現在、より速いネットワーク配信の解決は、コンピュータの中央演算処理装置（ＣＰＵ）及びランダム・メモリ・アクセス（ＲＡＭ）コンポーネント内のこれらのボトルネックを排除することに依存する。
【０３０８】
ストリーム及びソケットのような、コア・ライブラリ内の多くの基本ネットワーク操作を提供するので、過去数年間にわたって、高度なネットワーク中心のソフトウェア・アプリケーションを書き込むためプログラミング言語Ｊａｖａが普及するようになった。本発明のこのトランスペアレントなゼロコピー・ネットワーク通信の部分は、既存のアプリケーションより高性能のオーダーである次世代アプリケーションを書き込む技術を定義するので、トランスペアレントな反射型ゼロコピー・ネットワーク通信とＪａｖａは、互いに適合するものである。近年、Ｊａｖａプログラミング言語は、Ｊａｖａネイティブ・インターフェース｛ＪＮＩ）を通して定義されるように、任意のメモリ領域をＪａｖａヒープ管理／ガーベッジ・コレクションのｊａｖａ仮想計算機｛ＪＶＭ）アルゴリズムにマッピングするためのゼロコピー・メモリ・サポートを含むように拡張された。このように、本発明のこのトランスペアレントなゼロコピー・ネットワーク通信部分は、リフレクティブ・メモリの実際の実行と組み合わされて、こうしたゼロコピー・サポートがＪａｖａで与えられた時にのみ実行可能となる。
【０３０９】
前述の従来技術の問題及び欠点は、本発明のこのトランスペアレントなゼロコピー・ネットワーク通信部分によって対処され、明示的な基本ネットワーク操作の必要性を排除しながら、独立したコンピュータ・システム間のゼロコピー通信を実行する方法及びシステムが提供される。本発明のトランスペアレントなゼロコピー・ネットワーク通信部分は、限定する意味ではないが、マルチ計算又はルーズ結合されたクラスタを介して共に組織化された多数の独立したコンピュータ間でデータを交換するための通信技術として用いるのに特に適している。
【０３１０】
この方法は、ネットワーク通信に関係している全てのコンピュータ・システム（ここでは、「ノード」と定義される）間のリフレクティブ・メモリを物理的に実装するシステムの存在を仮定する。こうしたリフレクティブ・メモリを提供する如何なるシステムも、本発明のゼロコピーに用いるのに適している。従来技術のこうしたシステムの例には、マルチプロセッサ、共用バックプレーンを有するマルチコンピュータ、及びルーズ結合されインターネットワーク化されたコンピュータのクラスタのための実装が含まれる。
【０３１１】
本発明のこのトランスペアレントなゼロコピー・ネットワーク通信部分は、それらの相互依存性のための新規な方法に加えて、２つのアルゴリズム、すなわちネットワーク相互接続性に関係するソース計算機のための「トランスペアレントなゼロコピーＪａｖａネットワーク配信」アルゴリズムと、ネットワーク相互接続性に関係する１つ又はそれ以上の宛先計算機のための「トランスペアレントなゼロコピーＪａｖａネットワーク受信」アルゴリズムが組み合わされたものと定義される。
【０３１２】
１配信と１受信は、ユニキャスト・ネットワークを定め、１配信と任意の数の受信は、マルチキャスト・ネットワークを定めることに注意されたい。リフレクティブ・メモリ特有の構成の詳細についての可能性を超える、実装における違いがないので（基礎となるリフレクティブ・メモリを定義する特性によって保証されるように）、本発明のこのトランスペアレントなゼロコピー・ネットワーク通信部分により定義されたアルゴリズムは、意図的に２つの場合を区別しない。さらに、多くの実際のリフレクティブ・メモリの実装の性能特性に起因して、多くの実施形態におけるユニキャストとマルチキャストの間の性能の差は取るに足りないくらい小さい。これらが、従来技術に定義されるコンピュータ・ネットワーク通信方法及びシステムと異なるので、本発明のこのトランスペアレントなゼロコピー・ネットワーク通信部分のこれらの２つの属性も注目に値する。
【０３１３】
各々のアルゴリズムは、その具体的実装を２つのプログラミング言語、すなわち（１）トランスペアレントなゼロコピー・ネットワーク相互接続のために、クラス、インターフェース、及び実装を定めるＪａｖａコード、及び（２）従来技術において一般に「ネイティブ・コード」と呼ばれる操作システム特有のコードに区分化しなければならないコンポーネントを含み、リフレクティブ・メモリ・システムと（１）のＪａｖａコードとの間に実行時間インターフェースを与える。当業者であれば、以下のソフトウェアにおけるトランスペアレントなゼロコピー・ネットワーク相互接続アルゴリズムの実装の詳細は、特定の実施形態のアーチファクトであり、本発明のこのトランスペアレントなゼロコピー・ネットワーク通信部分の固有の属性ではないことを容易に理解するであろう。
【０３１４】
メソッド呼び出し、又は他の言語特有の属性を定める以下の段階の各々について、実施形態が、当業者であれば、このようなアルゴリズムの特性の実装と同じであると考える様々な実装技術（動的タイプのリフレクション、デリゲーション、又は他の意味規則的に同一のメソッドを用いる、多くの別個のサブメソッド呼び出しを介する実装のような）を選択することができる。同様な意味合いで、以下のアルゴリズムにおける多くの段階は、依然として同じ意味規則解釈を保持しながら、その順序を変えることができる。当業者であれば、このような順序付けは、このようなアルゴリズムの特性の実装と同じであるともみなすであろう。
【０３１５】
トランスペアレントなゼロコピーＪａｖａネットワーク配信アルゴリズムは、以下の段階によって定められる。
（１）特定のサイズのＪａｖａバイト指向メモリ・アレイである（例えば、バイト［ｎ］、ここでｎ＞＝０）、Ｊａｖａ変数「ｊＢｕｆ」を定める。
（２）使用時にリフレクティブ・メモリ・システムと互換性のある操作システム特有のコードを用いて、本発明の現在のトランスペアレントなゼロコピー・ネットワーク通信部分によって定められるような、受信アルゴリズムを実装する全てのノードの間の仮想又は物理的メモリ・スペースにおいて共有され（リフレクションさせられ）アクセス可能にされた、ここでは「Ｂｕｆ」と呼ばれるメモリ・バッファを割り当てる。この段階は、ネイティブ・コードを用いて実行され、ネイティブ・メソッド・インターフェース（例えば、「ネイティブ」メソッド・アクセス修飾子を有するＪａｖａ方式）を用いて定められるＪａｖａインターフェース又はクラスにおける方式である「ネイティブ・メソッド呼び出し」（従来技術において呼ばれるような）を介してＪａｖａから呼び出される、「Ｓａｌｌｏｃ（）」と呼ばれる関数の段階１と定義される。
（３）Ｊａｖａのバイト指向のメモリ・アレイを割り当て、操作システム・コード及び／又はＪＶＭ特有のコード（「ｊａｖａネイティブ・インターフェース」のような）を用いて、これをＢｕｆと関連付け、ＪａｖａのＪｂｕｆからデータを読み取り又は書き込むことで、Ｂｕｆによって定められたネイティブ・メモリ領域から（Ｊａｖａヒープのガーベッジ収集されたメモリの任意の領域ではなく）データが読み取られ、書き込まれる。この段階は、ネイティブ・コードを用いて実行されるＳａｌｌｏｃ（）の段階２と定められる。
（４）段階（２）及び（３）において実行されたように、Ｓａｌｌｏｃ（）から戻されたＪａｖａメモリ・アレイと等しくなるようにｊＢｕｆの値を割り当てる。当業者であれば、同じ目的を保持しながら、便宜上、Ｊａｖａの単一の定義及び割り当てステートメントにこの段階及び段階（１）を一体化できることを容易に理解するであろう。
（５）データを伝送するこの本発明のトランスペアレントなゼロコピー・ネットワーク通信部分を利用するソフトウェア・プログラムにより望まれるように、特定のバイト値（個別に又はブロックで）をｊＢｕｆの個々のバイト・データ・フィールドに書き込むために、Ｊａｖａ関数呼び出し、割り当てステートメント、又は他の同等の技術の何らかの組み合わせ及び順列を用いる。
（６）実施形態特定の同期化アルゴリズムの要求どおりに、共用反射型における１つ又はそれ以上のバイトを用いて、何らかの基本の共用メモリ同期化アルゴリズムを介してトランスペアレントなゼロコピーＪａｖａネットワーク受信アルゴリズムを実行するコンピュータ・システムに、このアルゴリズム終了の信号を送る。多数のこうした同期化技術は、従来技術において定められ（１９９２年にＬｙｎｃｈによって調査された）、この特定の実行は、本発明のこの現在のトランスペアレントなゼロコピー・ネットワーク通信部分の属性ではなく、実施形態の属性と考えられる。
（７）ｊＢｕｆの使用が終了すると（ソフトウェア・プログラムによる通知により暗黙的に、又はガーベッジ・コレクションのような非同期信号技術により明示的に）、「Ｓｆｒｅｅ（）」と呼ばれるＪａｖａネイティブ・メソッド（上述と同じ「ネイティブ・メソッド」の定義を用いる）が呼び出され、ｊＢｕｆが割り当て解除され、そのリフレクティブ・メモリのマッピングが排除されることを要求する。
（８）Ｓｆｒｅｅ（）は、Ｂｕｆを共用メモリからマッピング解除し、割り当て解除することを要求する。リフレクティブ・メモリ・システムの場合、この段階は、ネットワーク相互接続に関係するコンピュータ・システム間のあらゆる後続のリフレクションを暗黙的に中止させる。
（９）Ｓｆｒｅｅ（）は、（８）において定義された操作の成功を示すブール値を、（７）においてＳｆｒｅｅ（）を呼び出したソフトウェア呼び出し側に戻す。この戻りブール値の値は、後続する明示的なリフレクションを中止するために、リフレクティブ・メモリ・システムの成功又は失敗と等しくなるように定められる。リフレクティブ・メモリ・システムによってこのようなブール値が与えられない場合には、真の戻り値が仮定される。当業者であれば容易に理解するように、この段階は、同等の目的を有する戻り値（従来技術においては「ヌル」戻り値）を用いずに実行することもできる。
【０３１６】
（３）の対をなすマッピングにより定められたように、Ｊａｖａを用いる段階（５）のデータ割り当ては、ＪａｖａバイトアレイｊＢｕｆの基礎をなす共用リフレクティブ・メモリを暗黙的に変える。リフレクティブ・メモリの定義によって、こうした変化は、トランスペアレントなゼロコピーＪａｖａネットワーク受信アルゴリズムを実装するコンピュータ・システムの各々の対応する共用リフレクティブ・メモリ・バッファに自動的に伝播する。一般性を失わずに、こうした伝播は、相互接続性（例えば、共用バックプレーン、共通のバス、又はイーサネットのような従来の有線ネットワークによりインターネットワーク化されたコンピュータ・システムのルーズ結合されたクラスタ）に関係するコンピュータの各々を接続する共用媒体にわたるトラフィックに加えて、カーネル共用メモリ及び仮想メモリ機構と協働することを要求する。
【０３１７】
トランスペアレントなゼロコピーＪａｖａネットワーク受信アルゴリズムは、以下の段階によって定められる。
（１）「Ｊｂｕｆ」と呼ばれる特定のサイズのＪａｖａバイト指向メモリ・アレイである（例えば、バイト［ｎ］、ここでｎ＞＝０）、Ｊａｖａ変数「ｊＢｕｆ」を定義する。
（２）使用時にリフレクティブ・メモリ・システムと互換性のある操作システム特定のコードを用いて、本発明の現在のトランスペアレントなゼロコピー・ネットワーク通信部分によって定められるような、受信アルゴリズムを実装する全てのノードの間の仮想又は物理的メモリ・スペースにおいて共有され（リフレクションさせられ）アクセス可能にされた、ここでは「Ｂｕｆ」と呼ばれるメモリ・バッファを割り当てる。この段階は、ネイティブ・コードを用いて実行され、ネイティブ・メソッド・インターフェース（例えば、「ネイティブ」メソッド・アクセス修飾子を有するＪａｖａ方式）を用いて定められるＪａｖａインターフェース又はクラスにおける方式である「ネイティブ・メソッド呼び出し」（従来技術において呼ばれるような）を介してＪａｖａから呼び出される、「Ｓａｌｌｏｃ（）」と呼ばれる関数の段階１と定義される。
（３）Ｊａｖａのバイト指向のメモリ・アレイを割り当て、操作システム・コード及び／又はＪＶＭ特定のコード（「ｊａｖａネイティブ・インターフェース」のような）を用いて、これをＢｕｆと関連付け、ＪａｖａのＪｂｕｆからデータを読み取り又は書き込むことで、Ｂｕｆによって定められたネイティブ・メモリ領域から（Ｊａｖａヒープのガーベッジ収集されたメモリの任意の領域ではなく）データが読み取られ、書き込まれる。この段階は、ネイティブ・コードを用いて実行されるＳａｌｌｏｃ（）の段階２と定められる。
（４）段階（２）及び（３）において実行されたように、Ｓａｌｌｏｃ（）から戻されたＪａｖａメモリ・アレイと等しくなるようにｊＢｕｆの値を割り当てる。当業者であれば、同じ目的を保持しながら、便宜上、Ｊａｖａの単一の定義及び割り当てステートメントにこの段階及び段階（１）を一体化できることを容易に理解するであろう。
（５）このデータ交換のためのネットワーク相互接続性のデータ・ソースとして働くコンピュータ・システムによって実行されるように、ｊＢｕｆを使用する際に同意された同期化アルゴリズムを用いて、限界のある期間又は限界のない期間、対応するトランスペアレントなゼロコピーＪａｖａネットワーク配信アルゴリズムの信号の終了を待つ。多くのこうした同期化技術は、従来技術において定められ（１９９２年にＬｙｎｃｈによって調査された）、特定の実行は、本発明のこの現在のトランスペアレントなゼロコピー・ネットワーク通信部分の属性ではなく、実施形態の属性と考えられる。
（６）信号を送る際に、限界のあるタイムアウトの前にこうした信号が生じる場合には、（７）に進む。限界のあるタイムアウト中にこうした信号が生じない場合には、（８）に進む。
（７）データを送信するために、本発明のこの現在のトランスペアレントなネットワーク通信部分を利用するソフトウェア・プログラムの要求どおりに、ＪａｖａにおけるｊＢｕｆからバイト値を読み取り、これを使用する。この段階中、如何なる任意の関数の順列又は組み合わせも実行することができ、本発明の現在のトランスペアレントなゼロコピー・ネットワーク通信部分により定められるネットワーク通信においてデータを送信するコンピュータからのデータの受信から生じる所望の関数結果を達成する。
（８）ｊＢｕｆの使用が終了すると（ソフトウェア・プログラムによる通知により暗黙的に、又はガーベッジ・コレクションのような非同期信号技術により明示的に）、「Ｓｆｒｅｅ（）」と呼ばれるＪａｖａネイティブ・メソッド（上述の「ネイティブ・メソッド」と同じ定義を用いる）が呼び出され、ｊＢｕｆが割り当て解除され、そのリフレクティブ・メモリ・マッピングが排除されるよう要求する。
（９）Ｓｆｒｅｅ（）は、Ｂｕｆを共用メモリからマッピング解除し、割り当て解除することを要求する。リフレクティブ・メモリ・システムの場合、この段階は、ネットワーク相互接続に関係するコンピュータ・システム間のあらゆる後続のリフレクションを暗黙的に中止させる。
（１０）Ｓｆｒｅｅ（）は、（８）において定義された操作の成功を示すブール値を、（７）においてＳｆｒｅｅ（）を呼び出したソフトウェア呼び出し側に戻す。この戻りブール値の値は、後続する明示的なリフレクションを中止するために、リフレクティブ・メモリ・システムの成功又は失敗と等しくなるように定められる。リフレクティブ・メモリ・システムによってこのようなブール値が与えられない場合には、真の戻り値が仮定される。当業者であれば容易に理解するように、この段階は、同等の目的を有する戻り値（従来技術においては「ヌル」戻り値）を用いないで実行することもできる。
【０３１８】
従来技術の用語において、本発明の現在のトランスペアレントなゼロコピー型ネットワーク通信部分は、リフレクティブ・メモリ（共用メモリに対立するものとして）と定義され、共用反射型バッファに書き込まれたバイトは、必要とされる如何なる固有の同期化サポートも用いずに、ネットワーク相互接続性に関係する全てのコンピュータ・システムに自動的に伝播される（こうしたネットワーク通信技術を用いることは、このように終了信号を提供することを必要とするが）。したがって、キャッシュ一貫性、又は書き込み待ち時間をマスクし、読み取り待ち時間をマスクし、或いは最適化アルゴリズムを介してシステム間でバイトを転送する必要性を減少させようとする他の技術に対するサポートは意図的にない（ユーザにより所望されるように、そのようなものを本発明の現在のトランスペアレントなゼロコピー型ネットワーク通信部分に加えることができるが）。意図するのは、関係するシステムの各々の間に完全なリフレクティブ・メモリを定め、それらをネットワーク通信抽象化として用いることである。
【０３１９】
前のアルゴリズムの定義は、本発明の現在のトランスペアレントなゼロコピー型ネットワーク通信部分を定義する幾つかの重要な鍵を示す。第１に、本発明の現在のトランスペアレントなゼロコピー型ネットワーク通信部分は、「ゼロコピー」型通信技術を用い、ネットワーク通信前又はネットワーク通信中、バイト・アレイｊＢｕｆのバイトは、二次的なバッファに転送されない。このことは、ｊＢｕｆが局所的及び／又は物理的伝送を実行するのにこうした中間バッファに（通常、カーネル通信バッファ又はネットワーク・バッファ・インターフェース・カードに）転送されることを必要とする、ソケット又はストリームのような従来技術のネットワーク通信方式と異なる。
【０３２０】
第２に、本発明の現在のトランスペアレントなゼロコピー型ネットワーク通信部分は、「トランスペアレントな」ネットワーク通信技術に依存している。ネットワーク相互接続性に関係するコンピュータ間に信号を送る又はデータ伝送を実行するために、入力／出力もソケット方式も呼び出されない。代わりに、データ伝送は、値をバイトアレイｊＢｕｆに書き込む際に暗黙的に信号が送られ、起こる。この透明性の属性は、本発明の現在のトランスペアレントなゼロコピー型ネットワーク通信部分の著しく低い待ち時間及び高性能特性を達成する手段を定めるので、重要なものである。従来技術において定義された用語においては、本発明の現在のトランスペアレントなゼロコピー型ネットワーク通信部分のこの属性は、「トランスペアレント」と呼ばれる。このように、この方法で用いられるリフレクティブ・メモリは、対称のマルチ処理（ＳＭＰ）コンピュータ・システムにおいて開拓された技術、すなわちメッセージの引渡し及び共用メモリを実行できる柔軟なプログラミング・モデルを提供する。Ｊａｖａのリフレクティブ・メモリは、特にマルチ計算及びルーズ結合クラスタ化を用いて構成されるコンピュータに、これらの利点を提供する。
【０３２１】
最後に、トランスペアレントなネットワーク通信は、従来の待ち時間、及びＴＣＰ／ＩＰのようなネットワーク・プロトコル・スタックに関連した計算性能コストを排除するので、既存のネットワークより優れてもいる。具体的には、トランスペアレントなゼロコピー機構を用いるリフレクティブ・メモリは、操作システムのネット・インフラストラクチャによって処理されず、代わりに、一般性を失うことなく、直接メモリ・アクセス（ＤＭＡ）及びユーザ・カーネル・メモリ・マッピングを通して、メモリに直接マッピングされる。
【０３２２】
自動システム統合
システム統合（ＳＩ）は、複数の別個のコンピュータ・システムにわたるドメイン駆動型プロセスの一部として、１つ又はそれ以上の別個のコンピュータにデータを交換させ、プロセス状態を保持させることに関連した技術分野である。システム統合の仕事は、以下、個々に「ＳＩグループ」と呼ばれる企業のグループによって実行される。図５４ａ、図５４ｂ及び図５５−図６０は、本発明の自動システム統合の部分の以下の説明に対応する。
【０３２３】
データ交換は、通信ネットワークを介して独立したコンピュータ間で情報のバイトを移動させる一般的な方法である。こうした交換は、単一のエンティティ又は多数のエンティティ間で所有されるコンピュータの間で生じる。何らかのこうした交換におけるデータのバイトは、異質のタイプにフォーマットされることが多く、このように共通のフォーマットが欠如しているのは、交換されるデータが、複数の異なるデータ・フォーマット規格（例えば、ＡＳＣＩＩテキストファイル、構造化照会言語（ＳＱＬ）、又は拡張可能なマークアップ言語（ＸＭＬ））を用いる複数の異なるコンピュータ・プログラムから発生するためである。
【０３２４】
プロセス状態は、データ交換を実行する論理プロセスフローの「ロードメーカー」を表すコンピュータである。具体的には、全てのコンピュータ・プログラムは、ソフトウェア及びハードウェア・プログラムの命令がこうした交換に対して実行する所定のプロセスフローを有する。多数のコンピュータ間でデータを移動させるプログラムについては、このプロセスの論理「ロードメーカー」は、該プロセスに関係するコンピュータの各々を横切って分散される。プロセス状態は、ランダム・アクセス・メモリ（ＲＡＭ）及び該プロセスに関係するコンピュータの各々の持続性記憶装置（ハード・ドライブのような）に格納されたバイトとして明示される。データ交換を制御するソフトウェア・プログラムは、このようなプロセス状態が、いつどのように定められ、ＲＡＭ又は持続性記憶装置に保存されるかについての「規則」（又は、論理条件及び制約の組）を定める。このように、プロセス状態を保持することは、該プロセスにアルゴリズム及びソフトウェア論理を提供するソフトウェアと該プロセスの実行から生じる状態データを格納するハードウェアとの間の共同作業である。
【０３２５】
このようなプロセス状態が関係するコンピュータの各々の間に一貫性を保持し、人間のオペレータがコンピュータに要求する統合方法の意図を正確に反映し続けることを保証することは、特に重要である。多くのシステム統合問題において、一貫したプロセス状態を保持することは、技術的に最も困難な態様の１つである。このようなシステム統合解決における多くの技術的実装の詳細を動機付けるので、このことは重要である。
【０３２６】
原理として、今日、システム統合は、２つの別の手段すなわちサービス駆動型手段及び製品駆動型手段を介して実行される。これらの２つの手段は、これを通して実際の企業がユーザにシステム統合を提供する主要な技術である。以下の全体にわたって、「統合解決」は、データ交換を要求する特定の統合方法及びプロセス状態保持のための要件を解決するための、互いに依存するハードウェア及びソフトウェアのグループの実行と定義される。以下、用語「顧客」は、このような統合解決を求める１つ又はそれ以上のエンティティと定義される。
【０３２７】
サービス駆動型システム統合（ＳＤＳＩ）は、各々が相補的なドメイン特定の技能領域をもち、協働して統合解決を実行する各種学問分野の個人のグループによって駆動される人間の手のかかるプロセスである。顧客に与えられるこのような解決は、特定の統合問題に対処するため、互いにインテリジェントに組み合わせられた、コンピュータ・サーバ及びソフトウェアのような、技術コンポーネントの組から構成される。有形の技術解決である最終結果にもかかわらず、サービス駆動型ＳＩによって与えられる真の価値は、個々の技術コンポーネントではなく、ＳＩグループの個々の人間のメンバーによってもたらされる専門技術及び知識である。定義上は、サービス駆動型システム統合は、彼らが顧客の解決を開発するためにカスタマイズする技術を可能にするグループと共に、ドメイン専門家のグループの存在を仮定する。ＳＩグループによって、ユーザ教育のような他のサービスを提供することもできるが、このような非技術駆動型サービスは、システム統合の実行の範囲外であると考えられる。
【０３２８】
システム統合を実行するこの手段を定義する属性が幾つかある。当業者であれば、サービス駆動型システム統合を実行する如何なる特定の企業も、以下の属性のサブセットだけを示すか、又は以下に定められる厳密な属性に何らかの適度な差異を有することができることを理解するであろう。こうした差異にかかわらず、企業の目的は変わらない。
【０３２９】
第１に、サービス駆動型システム統合は、ほとんど例外なく、具体的に特定された顧客のための別個のプロジェクトの実行を中心に構成される。特定の「プロジェクト」の仕事の範囲は、単一の顧客の問題を解決するプロセスと定義される。サービス駆動型システム統合の経済的正当化は、人間の労働及び物理的技術についてプロジェクトを実行するコストより高い料金をプロジェクトごとに請求することにある。
【０３３０】
第２に、特定のＳＩ問題を実行するプロセスは、将来のプロジェクトのために再使用することができる有形の知的所有権（ＩＰ）をほとんど又は全くもたらさず、よってＳＩグループは、プロジェクト間で再使用できるソフトウェアをほとんど開発しない。多くの場合、ＳＤＳＩグループのプロジェクト間で保持されるＩＰは、プロジェクト中にグループのメンバーが繰り返して得る知識のみである。さらに、サービス駆動型ＳＩについての顧客とＳＩグループとの間の顧客契約の構成は、このようなプロジェクトの過程において開発された全ての有形の知的所有権は顧客が所有することを規定することが多く、同様な意味合いで、多くのＳＩグループは、このようなプロジェクト中に開発する有形のＩＰを再使用することを契約によって禁止される。
【０３３１】
第３に、サービス駆動型ＳＩグループは、コンピュータ・ハードウェア及び／又はソフトウェアを提供する信頼できるグループの独立した技術企業に依存し、システム統合解決は、ＳＩグループによって作られる。多くの場合、ＳＩグループによって顧客に与えられる価値の重要な部分は、特定のビジネス問題を解決するために彼らの選択された技術コンポーネントの組を用いる際に、該グループが保有する教育及び技術技能の中にカプセル封入される。この属性についての主要な特性は、サービス駆動型ＳＩグループが、ハードウェア及びソフトウェアを提供する技術パートナー企業から独立していることである。
【０３３２】
第４に、サービス駆動型ＳＩグループは、顧客により定義された問題を解決するのに必要な如何なる技術ツールの組をも使用する。具体的には、ＳＩグループは、プロジェクト間においてハードウェア又はソフトウェアの特定部分に独自の忠誠をほとんど保持しない。同様な意味合いで、サービス駆動型ＳＩは、製品指向型ではなく、顧客及び解決指向型である。
【０３３３】
第５に、サービス駆動型ＳＩの技能を購入する顧客は、ＳＩグループの役割及び範囲が明らかであることを保証するために、解決される問題を厳密に定めることが多い。この問題の範囲を狭めることは、慎重にサービス駆動型ＳＩの経済性に基づいて行われる。問題が大きくなるにつれて、解決を実行する全体のコストが指数的に大きくなる。
【０３３４】
サービス駆動型システム統合の実行は、一般に手続きプロセスに従う。当業者であれば、特定の企業は、通常、知識、技能、及び財源の特定の混合を強調するために、これらの手続き段階を控えめに変化させることを理解するであろう。具体的には、このプロセスは、以下の段階、すなわち、問題の識別、既存の技術システムの分析、顧客により雇用された人々との徹底的な討議、技術の設計及びアーキテクチャ、技術の実施、妥当性検査、試験、及び事後点検からなる。上の属性によって例示されるように、プロジェクトの開始から終了までの、ＳＩグループと顧客との間の打ち合わせ、緊密なコミュニケーションが、このプロセスの重要な特性である。このような段階を、厳密に上述の順序で行う必要はない。具体的には、ＳＤＳＩプロセスは、こうした段階を控えめに変えて実行することが多い。
【０３３５】
サービス駆動型システム統合は、問題の識別で開始し、この問題の識別は、顧客によって提示される問題を慎重に識別する、コミュニケーション中心で、時間がかかり、人間主体の作業プロセスである。ここでは、この段階は「調査段階」と呼ばれる。続いて、プロセスは、顧客の設備に設置された技術製品のタイプ、及び該顧客がビジネス過程においてこのような技術をどのように使用するかの詳細を分析するＳＩグループによって続く。これら最初の２段階の重要なコンポーネントは、様々な技能及び地位を有するＳＩグループと従業員との間の深く掘り下げたコミュニケーションである。この段階の出力は、通常、ＳＩプロジェクトを介して解決するために考慮される問題を定義し、定量化し、限定する何らかの形態の具体的な文書である。
【０３３６】
調査段階の次に来るのは、システム統合解決の技術コンポーネントの設計、仕様、及び開発である。本質的に、この「実施」段階は、主に、調査段階において定められた仕様に関する要求事項に対処するために、１組のハードウェア及びソフトウェアをカスタマイズすることに関連する。ここでは、ＳＩグループは、独立した技術企業に依存し、ハードウェア及び解決に適したパッケージ化されたソフトウェアを導入し、次に、サービス駆動型ＳＩのスタッフは、自分達が独自に開発した知識及び技能を用いてカスタマイズする。
【０３３７】
最後に、ＳＩグループによってカスタマイズされたコンピュータ・ハードウェア及びソフトウェアのグループが顧客の設備内にインストールされる。インストール段階は、多くの段階を含む。すなわち、ハードウェア又はソフトウェアを顧客の設備で利用可能にするのに物理的インストールが必要とされ、調査段階中に識別された顧客の要求事項に対処する解決を検証するのに妥当性検査が必要とされ、顧客により用いられる他のハードウェア及びソフトウェアと技術的に両立する解決を検証するのに試験が必要とされる。インストール段階の後、インストールされた解決に対する特定の要求事項からの何らかの異常又は逸脱を確認するために、通常、顧客がサービス駆動型ＳＩグループとの連絡をもち続けるある一定の期間が存在する。
【０３３８】
ＳＤＳＩの実施についての上記の説明から保持すべき重要な観察は、こうした規律を実際にどのように実行できるかという点で広範な程度の差異が存在することである。当業者であれば、各々の段階内で、種々のサブステップをほぼあらゆる順序で実行できることを容易に理解するであろう。さらに、これらのサブステップを実行する一般に同意された順序は存在しない。したがって、機械的段階の厳密に順序付けされた手続きの組への如何なるＳＤＳＩの変換も、定義上は、個々のＳＩグループがＳＤＳＩをどのように実行してもその差異を正確に反映しない。
【０３３９】
製品駆動型のシステム統合（ＰＤＳＩ）は、コンピュータ・システム内のデータ又はプログラム状態の統合に関係する特定の問題の解決ソフトウェアに成文化することである。製品駆動型ＳＩの本質は、顧客のグループが直面した統合問題を識別し、こうした問題を解決するソフトウェアを開発し、商業化することである。製品駆動型のシステム統合の限定要因は、どれだけ迅速に統合問題を識別し、それらの解決をソフトウェアに成文化するかである。このような統合問題は、顧客と共に識別されることが多いが、製品駆動型のシステム統合の目的は、単一の、標準化された、一定の明確な機能の組の使用を通じて、大多数にとっての顧客の統合の難題を解決することである。製品駆動型のシステム統合は、適切な範囲及びソフトウェア開発において技能を有するエキスパートのグループの存在を仮定する。
【０３４０】
ソフトウェア・ドメインと同様に、多くの共通の統合問題に利用可能な無数のソフトウェアが存在する。システム統合を実行するこの手段は、幾つかの属性を定義する。当業者であれば、製品駆動型のシステム統合を実行する如何なる特定の企業も、以下の属性のサブセットだけを示すことができる（或いは、以下に定められる厳密な属性に何らかの適度な差異を有することができる）ことを理解するであろう。しかしながら、企業の目的は変わらない。
【０３４１】
第１に、製品駆動型のシステム統合は、反復型である。ソフトウェアの機能は、遅れずに非任意の間隔で固定され、このような機能、すなわち識別マーク（バージョン又は年のような）を有する別個の製品が与えられ、別個のエンティティとして商業化される。したがって、製品駆動型統合は、プロジェクト駆動型ではなく、所定の機能の組を有する決まった公表日時に基づいているので、製品駆動型統合は、サービス駆動型統合と著しく異なる。サービス駆動型ＳＩと対照的に、製品駆動型ＳＩは、開発段階中、特定の顧客の範疇を外れて製品を開発する。
【０３４２】
第２に、製品駆動型ＳＩは、必ずしも特定の顧客の考えられるあらゆる要求事項を満たす必要はないが、どちらかと言えば、顧客のグループの大部分の要求事項を考えられる限り満たすことができる一般化されたソフトウェアの部分を定義する必要がある。製品駆動型統合の経済的正当化は、統合製品には、開発の総コストの一部分をかけるべきであり、代わりに収益は、製品を広範なグループの顧客に売ることによって発生するという考えから得られる。
【０３４３】
第３に、製品駆動型ＳＩから生じた製品は、マクロ言語、図形構成、又は他の製品特定の機能のような技術を通じて狭く定義された母数空間内のみによって、限られた度合いまでカスタマイズ可能である。このことは、カスタマイズの或る程度の部分を構成するが、各々のソフトウェア・パッケージは、設計、アーキテクチャ、及び該ソフトウェアを具体化する統合の見通しによって制約される。具体的には、カスタマイズのタイプは、機能の安定化及び商業化のときに固定される。
【０３４４】
第４に、製品駆動型ＳＩは、完全な解決をもたらさない。むしろ、製品駆動型ＳＩは、何らかの訓練を受けたドメイン・エキスパートが、購入し、インストールし、設定し、配置し、管理しなければならないソフトウェアを提供する。具体的には、製品駆動型ＳＩは、主に如何なる人間駆動型プロセスも欠いている。このことは、特定の顧客に非常に特化された解決を与えるサービス駆動型ＳＩと対照をなす。
【０３４５】
第５に、製品駆動型ＳＩは、主に、詳細に文書で記録されたソフトウェアの経済的効果の影響を受けやすい。すなわち、競争者がいなくなるか又は市場の需要がなくなるまで、新しい機能が絶え間なく付加される。したがって、製品駆動型ＳＩは、時間が経つにつれて徐々に新しい機能を付加するモノリシック・ソフトウェアを開発する。さらに、めったにこのような製品の機能をインテリジェントにセグメント化又はサブセット化することができず、個々の顧客が、必要とされるそれらの機能だけを選択することを防止する。代わりに、顧客の潜在的な層を最大限にするという名目で、このような製品は、顧客が必要とする可能性のある、ほぼあらゆる考え得る機能を取り入れることが多い。サービスベースの統合と対照的に、顧客は、今日使われない機能が将来いつか必要になるという考えをもって、すぐに必要とするよりも多くの機能を購入する傾向がある。
【０３４６】
第６に、製品駆動型ＳＩは、反復して特定の製品を供給することを中心に構築される。具体的には、通常、このような製品は、様々な反復にわたって主として安定した状態である幾つかの特性を定義する。例えば、ソフトウェアのグラフィカルな「ルック・アンド・フィール」は、通常、一貫性があるままである。ソフトウェアを利用可能にするプログラミング・インターフェース（一般にアプリケーション・プログラミング・インターフェース又はＡＰＩと呼ばれる）は、下位互換性があるままであることが多く、結果的に発展して、より多くの機能を含むようになっただけである。統合を実行するためにソフトウェアが使用する手法又は「ソフトウェア・パラダイム」は、全体的に一貫性があるままである。
【０３４７】
上で列挙された属性によって示されるように、製品駆動型のシステム統合の実行は、サービス駆動型システム統合と著しく異なる。製品駆動型のシステム統合は、産業界内で通常「製品開発サイクル」と呼ばれる反復プロセスに従う。このプロセスは、以下の段階、すなわちドメインの選択、問題の定義、パラダイムの選択、要求事項の特定化、トレードオフの分析、機能の選択、技術の特定化、アーキテクチュアルな設計、実施、検証、内部試験、及び外部の顧客試験からなる。製品駆動型のシステム統合から構築された製品の大部分においては、この反復サイクルの期間は、一般に１年又はそれ以上延びる。さらに、当業者であれば、これらの製品開発サイクルは、ドメイン・エクスポートのインタディシプリナリ・チームからの長期間の関与を必要とすることを理解する。確かに、こうした製品は、にわか作りで又は長い企画立案及び文書化なくして開発されるものではない。
【０３４８】
これまでの議論に示されるように、製品駆動型のシステム統合をソフトウェア開発の特定の例と考えることができる。製品駆動型のシステム統合は、データ交換又はプロセス状態の維持を必要とする特定の問題を解決する１つのソフトウェアを設計することに関係している。当業者であれば、参考資料に詳しく述べられたように、ソフトウェア開発モデルに関する幅広いグループの刊行印刷物が存在し、したがって、そのようなものについての議論は略され、上で定義されたものを含むことを容易に理解するであろう。広汎なソフトウェア開発産業によっても例示されるように、当業者であれば、特定の企業は、通常これらの手続き段階を適度に変え、該企業の知識、技能、及び財源の特定の混合を強調することを理解するであろう。
【０３４９】
ＳＤＳＩと同様に、ＰＤＳＩが、定義上は、個々のＰＤＳＩグループの彼らの製品の開発の仕方の差異を正確に反映しないので、これらを厳密な手続きの組の機械的段階に変換することができない。その多くが処方にておいて互いに両立しない、多くのソフトウェア開発方法の存在及び実行が、この実行を当業者に明確に例示する。
【０３５０】
幾つかの点において、製品駆動型及びサービス駆動型システム統合は、それらの原型及び実際の形式における２つの両極端を表す。顧客ごとのカスタマイズに関して、ＳＤＳＩは、絶対的な個々のカスタマイゼーションを表し、ＰＤＳＩは、大量生産を表す。コストに関して、ＳＤＳＩは、生産コストを上回る額を顧客に請求し、ＰＤＳＩは、見込まれる広汎なグループの顧客によって開発コストを償却する。機能に関して、ＳＤＳＩは、顧客のニーズを的確に満たそうと努め、ＰＤＳＩは、関連する機能を最大にするよう努める。構成に関して、ＳＤＳＩは、「一品生産の」プロジェクト指向であり、ＰＤＳＩは、製品指向で反復型である。有形の知的所有権に関して、ＳＤＳＩは、再使用可能なＩＰをほとんど開発しないが、ＰＤＳＩは、著作権法により承認されていない再配布から法的に保護されるソフトウェアの販売を中心に構築される。
【０３５１】
ＳＤＳＩ及びＰＤＳＩの両方は、３つの共通の態様、すなわち複雑さ、時間の要求、及び供給コストを共有する。両方のシステム統合方法は、協働して非常に高度な解決を開発する各種学問分野のドメイン専門家グループに依存しており、本質的に、ＳＤＳＩ及びＰＤＳＩは、コンピュータを介して最適化又は自動化されるように改められない人間中心のプロセスである。この複雑さの結果は、システム統合が、有効に実行するのに多くの時間とコストを必要とする点である。両方のコストは、単一の顧客（ＳＤＳＩ）又は共通のグループの顧客（ＰＤＳＩ）のいずれかのために働く専門家の高い給料コストによって駆動され、両方に対する時間の要求は、問題の固有の複雑さ、及び個々のグループメンバーの生産性を増加させるためにどちらかの技術によって用いられる相対的に小さな組の技術ツールから生じる。
【０３５２】
この目的のために設計された５つの技術コンポーネントに依存する新規なビジネス・プロセスを用いてＳＩグループにより実行されるように、本発明は、システム統合解決の識別、設計及び実行を自動化して顧客に届ける方法及びシステムに関係する。これは、こうした技術コンポーネントの使用により高度に自動化されるプロセスを定めるので、本発明により定められる方法及び技術は、「自動化システム統合」と呼ばれる。
【０３５３】
自動化システム統合（ＡＳＩ）は、５つの別個であるが互いに依存する技術のコンポーネントの存在を仮定する。
（１）構成可能なハードウェア：明示的に他のコンポーネントと両立性があり、迅速で柔軟なカスタマイゼーションに適した特殊化したタイプのコンピュータ・ハードウェア。
（２）システム論理：主要なソフトウェア・アルゴリズム及びプログラム論理を実装する共通の再使用可能なソフトウェア論理の組であって、これは、別個のコンポーネント内に組織化することができ、特殊化されたハードウェアと両立性があるように適切に設計される。
（３）グラフィカル・ユーザ・インターフェース：任意の方法で柔軟に組み合わせることができる再使用可能なグラフィカル・ユーザ・インターフェース（ＧＵＩ）の組の定義であり、複数のＧＵＩを生成する。こうしたグラフィカル定義は、直接又は中間変換を介してのいずれかで互いに両立できる１つ又はそれ以上のグラフィカル定義言語において定義される。
（４）共通の技術標準：データ、ソフトウェア・プログラム構成、ハードウェア・インターフェース、データ境界、安全機構、エラー処理、及びデータ交換及びプロセス状態の他の意味規則属性の特性を説明する１組の共通の技術標準。
（５）統合結合：自動化共通標準、再使用可能なシステム論理、及び再使用可能なグラフィカル・ユーザ・インターフェース定義を用いてシステム統合を解釈し実行する、１組の高度に専門化されたコンピュータ・コンパイラ、実行時間環境、アプリケーション・サーバ、変換言語、データ・インターフェース、及び非同期プロセス状態維持機構。
【０３５４】
それらがシステム統合方法の自動化を助けるコンポーネントを定めるので、本発明を通じて、前の５つのコンポーネントは、全体で「標準化された自動化コンポーネント」と呼ばれる。前の５つのコンポーネントの定義の一部として意図されるのではないが、ＡＳＩ自動化コンポーネントは、概念的に、高度に専門化された新規なタイプの「統合ツールボックス」、又は自動化システム統合を一括して助ける相互に依存する技術ツールの組と考えられる。
【０３５５】
当業者であれば、これらの５つのコンポーネントは、単一の会社が所有し、以下のプロセスを個々に実行することができるか、或いは以下のプロセスを協働して実行する幾つかの会社が所有することができるかのいずれかであることを容易に理解するであろう。個々のコンポーネントの所有権を分割するにもかかわらず、本発明は、このようなコンポーネントを介した自動化システム統合の方法及びシステムを定める（該コンポーネントがここで列挙された定義属性を満たす場合には）。
【０３５６】
自動化システム統合は、以下に定められ、自動化ＳＩグループによって実行される、周期的で反復的な組の明確な手続き段階であり、プロセスが継続して事項される際に、ＡＳＩは周期的であり、このプロセスのこうした多数の事例を同時に任意に実行することができる。ＡＳＩグループは、このような手続き的段階をそれらが以下に示される順序で反復的に実行する。
【０３５７】
ＡＳＩとＳＤＳＩ／ＰＤＳＩとの間の幾つかの対比を定義から識別することができる。第１に、ＡＳＩは、上記の技術コンポーネントの存在、及び以下のプロセスを厳密に遵守することに密接に依存する。具体的には、これらの条件のいずれかが満たされない場合には、システム統合の実行は、本発明により定められた方法及びシステムの精神の範囲内にない。このことは、それらの定義により、何らかの特定の構造化された組の技術ではなく、もっぱらＳＩグループに依存するＰＤＳＩ及びＳＤＳＩと対照をなす。
【０３５８】
ＡＳＩは、同時に以下のプロセスの実行を明示的にサポートし、ＰＤＳＩ及びＳＤＳＩは、一連のプロセスである。ＰＤＳＩについては、ＰＤＳＩグループは、多数の製品を別個に開発することができるが、個々の製品の各々は、一定の組の機能を定義できるだけである。したがって、単一の製品の各々についてＰＤＳＩグループにより開発された製品は、定義上は、１つの経路に沿って進む。ＳＤＳＩについては、個々のＳＩグループ・メンバーの各々は、システム統合プロジェクトに寄与するのに利用可能な一定量の時間単位の時間を有するだけである。一旦こうした時間が実行中のプロジェクトに完全に割り当てられると、定義上は、個人が付加的なプロジェクトに寄与する能力はない。したがって、ＳＤＳＩ及びＰＤＳＩの両方についての主なリソースは、平行する業務なしに本質的に割り当て可能である。
【０３５９】
自動化システム統合は、便宜上要約された（しかし、厳密な定義ではない）７つの段階、すなわち（１）問題を定義する、（２）問題定義を要求事項の組へ変換する、（３）要求事項から技術実行仕様を蒸留する、（４）標準化された自動化コンポーネントから現在入手可能でない技術的機能の組を識別する、（５）前に識別された現在利用可能でない機能を実装する、（６）標準化された自動化コンポーネントに新しく開発された能力を統合する、（７）自動化コンポーネントからの機能の集合に基づいて顧客に解決を提供する、段階からなる。これらの段階は、以下に詳細に定められる。
【０３６０】
第１に、ＡＳＩグループは、職業上の経験、又は１人又はそれ以上の潜在的な顧客とのコミュニケーションに基づいて、明確な属性を有する特定のシステム統合問題を識別し、定義する。こうした問題の本質的な属性は、問題が、１人より多い潜在的顧客に影響を及ぼすとＡＳＩグループが考えていることである。このように、ＡＳＩ問題の定義は、問題の識別及び定義が、個々の顧客についての特定のシステム統合プロジェクトの範囲外に存在するという点でＳＤＳＩと異なる。
【０３６１】
第２に、ＡＳＩグループは、問題の定義を取り入れ、これを以下に明確に定義される「要求ドメイン」の組に含まれる１組の特定の要求に変換する。当業者は、この段階を非常に特殊なタイプの形式的な要求分析と理解するであろう。
（１）ユーザ・インターフェース機能：顧客がどのように手作業で解決と対話するかについてのグラフィカル・ユーザ・インターフェース（ＧＵＩ）の組。
（２）論理データ・インターフェース：解決が、論理ネットワーク及びプロトコル・アルゴリズム（ＯＳＴネットワークスタックのレベル５＋に常駐するデータの解釈を定義するアルゴリズムとなるように広く考えられる）を介して、論理データ交換及びプロセス状態の維持を提供する独立したコンピュータ・システム（及び対応するプロトコル及びデータ・フォーマット）の量及びタイプ。
（３）物理的データ・インターフェース：解決が、物理的ネットワーク・アダプタを介して、ネットワーク接続性及び物理的データ交換を提供する独立したコンピュータ・システム（及び対応するプロトコル及びデータ・フォーマット）の量及びタイプ。
（４）持続性状態規則：ソフトウェア・アルゴリズム、プログラム論理、及び専用のハードウェアに取り付けられた記憶装置を介して、別個の計算の間で保存しなければならない、独立したコンピュータ間で交換されるデータのタイプ及び解釈。
（５）イベント処理：トリガ、時間ベースのタイマー、及び自動ポーリングのような、イベント駆動型手続きを取り扱うのに適した、同期及び非同期ソフトウェア・アルゴリズム及びプログラム論理。
（６）トランザクション境界：適切な耐故障性、例外回復、ロールバック、及びソフトウェア・アルゴリズムを介する再試行意味規則を提供するための、データ交換及び状態維持プロセスにおいて別個の計算（従来技術において、一般にトランザクションと呼ばれる）の間に分けることができる境界を定める、原子の／一貫性のある／隔離された／耐久性のある（ＡＣＩＤ）特性の使用。
（７）特権の強化：安全及びプライバシーに対する顧客の要求を満たすために解決によって遵守しなければならない安全状況、イベント監査、特権状態、安全な・安全でない遷移境界、及び論理役割の組。
（８）エラー処理手続き：実行時間に生じる逸脱が、ソフトウェア・アルゴリズム及びプログラム論理を介して解決によりどのように処理されるかについての、検知、処理、人間の通知、自動化された拡大、持続性記録、グラフィカル表示、及び方針報告。
（９）ビジネス規則：ソフトウェア・アルゴリズム及びプログラム論理を介して、各々のコンポーネントの解決処理の実施及び意味規則を支配する、包括的で技術的に定義可能な条件の組（従来技術において、一般に「メタ規則」として知られる）。
【０３６２】
第３に、ＡＳＩグループは、これらの要求をＡＳＴが標準化される技術仕様書に変換する。この段階は、前に識別された機能要求を満たすＡＳＩ自動化コンポーネントを用いて、どのように解決を構成するかについての技術実施ガイドラインの開発をもたらす。本発明は、こうしたものに対して一般的な機構を定めるが、従来技術に通じている人ならば、この変換の特定の実施は、標準化された自動化コンポーネントの各々によって決まることを理解する。具体的には、本発明の好ましい実施形態の各々は、標準化されたＡＳＩ自動化コンポーネントの各々についてこのような変換を行うための特定の手段を定めることができる。本質的に、この段階は、機能要求から技術自動化コンポーネントへの変換の各々の論理構成からなる。
【０３６３】
こうした要求・コンポーネント変換についての重要な観察は、１対多数の関係があるという点であり、各々の機能要求は、１つ又はそれ以上の標準化されたＡＳＩ自動化コンポーネントにおける実行要求をもたらすことができる。この関係の重要で新規な特性は、この関係が、周期的プロセスの反復の各々の間、一貫性があるままであるという点である（ＳＤＳＩにおけるように特定のプロジェクトの意味に基づいて変化する、又はＰＤＳＩにおけるように別個のプロジェクトの定式化に基づいて変化するのと対照的に）。このように、２つを接続するこの関係及び変換プロセスは、ＡＳＩの静的属性であると考えられる。
【０３６４】
第４に、ＡＳＩグループは、ＡＳＩ自動化コンポーネントによって与えられた既存の機能を用いてどの技術仕様書を実行することができないかを識別するように進む。この反復に対する要求ドメインにおいて定められたが、まだ既存の自動化コンポーネントを満たさない新しい機能の組は、「デルタの組」と呼ばれる。デルタの組は、標準化された自動化コンポーネントの各々において必要とされる機能の個々の差の組の全ての合成である。
【０３６５】
デルタの組の正確な意味規則は、好ましい実施形態の技術標準によって決まり、要求分析において定められたドメインについて一般的規則を定めることができる（以下のリストは、要求ドメインの前のリストに直接対応する）：
（１）ユーザ・インターフェース機能：ＧＵＩ定義言語を介してＡＳＩ反復によって前に定義されなかったグラフィカル・ユーザ・インターフェース（ＧＵＩ）定義の一部分。同様な意味合いで、解決は、ＡＳＩ反復と異なる「ルック・アンド・フィール」（ＧＵＩ定義言語のスタイル属性と定められ、文字又は画像内容から分けられても分けられなくてもよい）を要求することができる。
（２）論理データ・インターフェース：ＡＳＩ反復によって前に定められなかった、特定のプロトコル及びデータ・フォーマット、又はサブセット、或いは内部専用の方言。
（３）物理的データ・インターフェース：ＡＳＩ反復によってこれまで定められなかった、特定のネットワーク・プロトコル、通信ネットワーク、又は相互接続設計。
（４）持続性状態規則：ＡＳＩ反復によって前に定められなかった、統合解決の要求に適切に基づいた、データを持続するのに必要なソフトウェア・アルゴリズム及びプログラム論理。
（５）イベント処理：ＡＳＩ反復によって前に定められなかった、特殊なタイプの非同期又は同期イベント処理をサポートするのに必要なアルゴリズム及びプログラム論理。
（６）トランザクション境界：特定の統合解決に含まれるデータ及びプロセス状態についての適切な耐故障性、例外回復、ロールバック、及び再試行意味規則を保証するために、ＡＣＩＤプロパティの使用を必要とするデータ交換及びプログラム状態の境界を定める。
（７）特権の強化：特定の統合解決に固有であり、前のＡＳＩ反復によって定められなかった、安全状態、遷移境界、特権状態、及び論理役割の定義、並びにそこで必要な適切なソフトウェア・アルゴリズム及びプログラム論理。
（８）エラー処理手続き：特定の統合解決に必要なエラー検知、エスカレーション・パターン、持続性記録保存、グラフィカル表示、及び報告の定義、並びにそこで必要な適切なソフトウェア・アルゴリズム及びプログラム論理。
（９）ビジネス規則：特定の統合解決に固有であり、前のＡＳＩ反復によって定められなかった、特定の技術的に定義可能な条件、及びそこで必要な適切なソフトウェア・アルゴリズム及びプログラム論理。
【０３６６】
この段階は、ＡＳＩにより与えられる自動化を可能にする重要な機構を利用するので、本発明により定められる方法及びシステムの新規性の最重要点である。
（１）再使用可能性：このプロセスの多数の同時の別個の反復を実行するために、ＡＳＩ自動化コンポーネントにより与えられた機能の別個のコンポーネントを独立して用いることができる。
（２）迅速で柔軟なカスタマイゼーション：特定の反復特定の要求を満たすために、ＡＳＩ標準化された技術を迅速かつ容易に扱う１組のツールを利用する能力。このようなカスタマイゼーション・ツールの正確な定義及び使用法は、好ましい実施形態により定められる標準化された自動化コンポーネントの性質によって決まる。
（３）技術の標準化：明確に定義され合意された技術標準の組に準拠するこの反復プロセス実装技術を用いる全ての解決実行。本質的に、再使用可能性及びカスタマイゼーションは、ほぼ定義によるこうした準拠によって決まる。
（４）設計の均質性：要求がどのように実装標準に変換されるかについてのプロセスと共に、全てのＡＳＩ自動化コンポーネントは、共通の技術設計テーマを共有し、自動化コンポーネントにより用いられる技術標準の各々は、互いに両立でき、まとまって働くように適切に選択され、ＡＳＩ反復を実行するのに必要とされる時間を最小にするように設計される。
（５）共通の分解及び変換：このような再使用可能な自動化解決は、問題を要求に分解し、要求を技術仕様書に変換するために同じ標準化手法を用いる各々の反復によって決まる。
【０３６７】
第５に、ＡＳＩグループは、デルタの組において識別されたような必要な５つの自動化コンポーネントにおいて要求される機能を実装するように進む。この実装は、明確で順序だった方法で生じ、正確な意味規則は、好ましい実施形態により定められる自動化コンポーネントによって決まる。
【０３６８】
この開発段階は、２つの明示的な目的、すなわち１つは独立目的、１つは従属目的を有する。独立目的は、まだ自動化コンポーネント内に存在しない技術機能をデルタの組から実装し、標準化することである。この主要な独立目的は、ＡＳＩ統合の目的を理解するのに重要である。デルタの組は、特定の統合問題についてＡＳＩ反復から生じるが、この開発段階の第１及び最も重要な目的は、自動化コンポーネントに与えられた新しい機能の増強及び標準化を助けることである。同様な意味合いで、周期的なＡＳＩ反復の真の目標は、システム統合機能を迅速に実装し、標準化することである。この段階の２次的な従属目的は、デルタの組が実装され、標準化された後、ＡＳＩ反復により考慮された特定の統合問題を解決するため、標準化された自動化コンポーネントを利用することである。
【０３６９】
標準化された自動化コンポーネントは、各々の反復について付加的な新しい差別的機能を獲得し続けるので、後続する反復の各々のデルタの組の大きさ及び複雑さは、指数関数的に減少する。複雑さ及び時間のこの指数関数的減少は、自動化を可能にする。このような自動化は、反復ｉに関するデルタの組の機能は、反復（ｉ＋１）、（ｉ＋２）、・・・（ｉ＋ｎ）において決して実装する必要はない、というように論理的に表すことができる。このように、このシステム統合の周期的な反復プロセスは、時間が経つにつれて新しい機能が増加する標準化されたコンポーネントにより自動的に駆動される。
【０３７０】
第６に、デルタの組により定められる要求を満たすように実装される技術機能は、標準化された自動化コンポーネントに併合される。この段階は、開発段階により助けられる独立目的を実行する。
【０３７１】
最後に、標準化された自動化コンポーネントを用いて、単に適切なコンポーネントの組を選択し、完全な解決に一体化させることによって、ＡＳＩ反復により対処された特定の統合問題への解決を構築することができる。具体的には、グラフィカル・ユーザ・インターフェース及び再使用可能なシステム論理が、統合結合を用いて織り込まれ、設定可能なハードウェアに読み込まれる。この織り込みプロセスは、共有する技術標準及び統合結合の意味によって定められ、その正確な意味規則は、各々の好ましい実施形態によって定められる。最後に、この完全な解決は、要求ドメインにおいて定められたものに合致する要求を述べる全ての顧客に送付される。この段階は、開発段階によって助けられる従属目的を実行する。
【０３７２】
前の説明を通して例示されたように、ＡＳＩをＳＤＳＩ及びＰＤＳＩから区別するＡＳＩの重要な特性は、同時に実行することができる。同じＡＳＩ自動化コンポーネントの組を用いて、同時にこのプロセスの多数の例を実行することができる。さらに、ＡＳＩは、異なる顧客の要求を満たすのに必要とされるように繰り返される周期的なプロセスである。長いタイムテーブルを有するＰＤＳＩと対照的に、ＡＳＩの実装は、何週間から何ヶ月までの期間続くことがある。
【０３７３】
ＳＤＳＩと対照的に、ＡＳＩの反復の各々は、必ずしも単一の顧客の知られている要求の全てを満たす必要はない。したがって、多数の反復は、必然的に独立したＡＳＩ解決を開発することができ、これを後で組み合わせて、所定の顧客の特定の問題に対する総合的な解決を提供することができる。このように、当業者であれば、ＳＤＳＩの明示的目的が顧客の認識された要求を満たす解決を実行することであるので、ＡＳＩは、ＳＤＳＩと大きく異なることを理解する。
【０３７４】
これまでの要約を明らかにするのを保証するために、自動化システム統合とサービス駆動型／製品駆動型のシステム統合の間で幾つかの比較をなすことができる。
【０３７５】
当業者であれば、前のプロセスを様々な成功段階まで実行できることを容易に理解するであろう。具体的には、ＡＳＩグループは、ＡＳＩ技術を用いてシステム統合を実行することを決定できるが、個々のメンバー、顧客、又は他の影響についての組織的な特性又は特有の特性の組に基づいて不十分に実行する。したがって、各々の段階に従う意図を有するものとして定められるが、こうした遵守を有効に操作可能にすることができない不十分な実行でさえも、本発明により定められる方法及びシステムの例であると考えられる。当業者であればすぐに認識するように、多くの会社がＳＤＳＩ及びＰＤＳＩの理想化されたプロセスを実行しようとするが、その際に、各々の段階についての要求をあまり操作可能にすることができない。うまくいってもいかなくても、これらの会社の各々は、依然としてシステム統合のそれぞれの技術を実行するように考えられる。
【０３７６】
自動化システム統合は、高度にカスタマイズ可能な標準化された自動化コンポーネントの組に依存する。この方法及びシステムにおける自動化は、明確なプロセスと組み合わされた高度にカスタマイズ可能なハードウェア、ファームウェア、ソフトウェア及びグラフィカル・レイアウト・コンポーネントに影響を及ぼすことから生じ、システム統合問題を反復的に識別し、それらの解決を実行し、結果として生じる統合システムを複数の顧客に届ける。このプロセス全体は、このプロセスの大半を自動化し標準化する、特別に設計されたシステム統合カスタマイゼーション・ツールの周りを回転する。
【０３７７】
本発明は、好ましい実施形態を参照してここに説明されたが、当業者であれば、本発明の精神及び範囲から逸脱することなく、他の用途をここに示したものと置き換えることができることを容易に理解するであろう。したがって、本発明は、上記に含まれる特許請求の範囲によってのみ制限されるべきである。
【図面の簡単な説明】
【０３７８】
【図１】本発明による、本発明によるｎ2個の変換ルーチンを用いてアプリケーション・プロトコルを変換する従来技術の手法の概略的なブロック図である。
【図２】本発明による、複数のインターフェースを介して本発明に接続する、代表的な複数のシステムの説明的な例を示す概略的なブロック図である。
【図３】本発明による、アプリケーション・プロトコルの変換をもたらすためにマルチ計算アーキテクチャを用いる、本発明の好ましい実施形態の概略的なブロック図である。
【図４】本発明による、ユーザ、本発明、及び複数の相互接続されたシステムを含む構成動作の説明的な例を示す概略的なブロック図である。
【図５】本発明による、本発明及び複数の相互接続されたシステムを含む統合動作の説明的な例を示す概略的なブロック図である。
【図６】本発明による、宣言型構成を用いる汎用構成機能の好ましい実施形態を示す概略的なブロック図である。
【図７】本発明による、本発明のアプリケーション・プロトコルの変換を実行するマルチコンピュータ・システムの概略的なブロック図である。
【図８】本発明による、２つのタイプのシングル・ボード・コンピュータの主なコンポーネントの概略的なブロック図である。
【図９】本発明による、シングル・ボード・コンピュータ上のＰＣＩ間ブリッジのハイレベル図の概略的なブロック図である。
【図１０】本発明による、シングル・ボード・コンピュータ上のＣＰＵを囲む主なコンポーネントの概略的なブロック図である。
【図１１】本発明による、多次元マトリックス表示へのビットストリーム変換の概略的なブロック図である。
【図１２】本発明による、本発明による３段階の変換パイプラインの概略的なブロック図である。
【図１３】本発明による、有限状態機械を用いる２段階の多次元マトリックスの変換プロセスを示す概略的なブロック図である。
【図１４】本発明による、複合有限状態機械を用いる１段階の多次元マトリックスの変換プロセスを示す概略的なブロック図である。
【図１５】本発明による、ソース多次元マトリックス表示、ターゲット多次元マトリックス表示、及び一連の多段階条件データフローの概略的なブロック図である。
【図１６】本発明による、接頭パイプライン、挿入パイプライン、及び接尾パイプラインの概略的なブロック図である。
【図１７】本発明による、複数の接頭パイプライン、挿入パイプライン、接尾パイプライン、及びパイプライン・クロスバーの説明的な例を示す概略的なブロック図である。
【図１８】本発明による、接頭パイプラインについての一連の多段階条件データフローの好ましい実施形態を示す概略的なブロック図である。
【図１９】本発明による、接尾パイプラインについての一連の多段階条件データフローの好ましい実施形態を示す概略的なブロック図である。
【図２０】本発明による、挿入パイプラインについての一連の多段階条件データフローの好ましい実施形態を示す概略的なブロック図である。
【図２１】本発明による、スロット、次元、及び多次元領域を用いる、本発明についての多次元マトリックスの好ましい実施形態を示す概略的なブロック図である。
【図２２】本発明による、本発明の多次元マトリックスの好ましい実施形態についての次元を横切るスロットの間の関係を示す概略的なブロック図である。
【図２３】本発明による、本発明の多次元マトリックスの好ましい実施形態に関するスロット注釈を示す概略的なブロック図である。
【図２４】本発明による、本発明の多次元マトリックスの好ましい実施形態に関するスロット注釈の説明的な例を示す概略的なブロック図である。
【図２５】本発明による、２つの多次元マトリックスにわたって定められた抽象機能演算の好ましい実施形態を示す概略的なブロック図である。
【図２６】本発明による、２つの多次元マトリックスにわたって定められた抽象機能演算から派生した演算の好ましい実施形態を示す概略的なブロック図である。
【図２７】本発明による、本発明についての有限状態機械の好ましい実施形態を示す概略的なブロック図である。
【図２８】本発明による、本発明についての有限状態機械の好ましい実施形態を用いる説明的な例を示す概略的なブロック図である。
【図２９】本発明による、本発明についての有限状態機械の好ましい実施形態を示す概略的なブロック図である。
【図３０】本発明による、対スペース抽象定式化に関連した複数のノードを有する対スペースの概略的なブロック図である。
【図３１】本発明による、対スペース抽象定式化に関連したｐ関数の機能コンポーネントの概略的なブロック図である。
【図３２】本発明による、対スペース抽象定式化に関連した基本操作を読み取るための有限状態機械の概略的なブロック図である。
【図３３】本発明による、対スペース抽象定式化に関連した基本操作に書き込むための有限状態機械の概略的なブロック図である。
【図３４】本発明による、対スペース抽象定式化に関連した基本操作を除去するための有限状態機械の概略的なブロック図である。
【図３５】本発明による、対スペース抽象定式化に関連した基本操作を通知するための有限状態機械の概略的なブロック図である。
【図３６】本発明による、対スペース抽象定式化に関連した白色ラムダプロセスのための有限状態機械の概略的なブロック図である。
【図３７】本発明による、対スペース抽象定式化に関連したｔｅｓｔＡｎｄＳｅｔ基本操作のための有限状態機械の概略的なブロック図である。
【図３８】本発明による、対スペース抽象定式化に関連したｆｅｔｃｈＡｎｄＡｄｄ基本操作のための有限状態機械の概略的なブロック図である。
【図３９】本発明による、対スペース抽象定式化の生成的な時間ダイナミック属性の概略的なブロック図である。
【図４０】本発明による、対スペース抽象定式化についての否定非結合性の機能表示を特定する概略的なブロック図である。
【図４１】本発明による、一時的対スペース抽象定式化と持続的対スペース抽象定式化との間の状態の時間ダイナミック比較である。
【図４２】本発明による、ＴＤＧＣ抽象定式化の主なコンポーネントの概略的なブロック図である。
【図４３】本発明による、ＧＩＲＣ対と（名前、値）対との間の対応を示す概略的なブロック図である。
【図４４】本発明による、対スペース抽象定式化に関連したロック基本操作のための有限状態機械の概略的なブロック図である。
【図４５】本発明による、対スペース抽象定式化に関連した複合ロック解除基本操作のための有限状態機械の概略的なブロック図である。
【図４６】本発明による、対スペース抽象定式化のための分散ガーベッジ・コレクション・アルゴリズムの好ましい実施形態の概略的なブロック図である。
【図４７】本発明による、対スペース抽象定式化のための分散ガーベッジ・コレクション・アルゴリズムの好ましい実施形態に到達可能なノードの説明的な例の概略的なブロック図である。
【図４８】本発明による、対スペース抽象定式化についてのＡＦＯと（名前、値）対との間の対応を示すスキーマである。
【図４９】本発明による、対スペース抽象定式化のためのＡＤＰＭにおけるオブジェクト呼び出しを実行する好ましい実施形態の有限状態機械の概略的なブロック図である。
【図５０】本発明による、プロクシ・オブジェクト呼び出しを実行する従来技術の有限状態機械図の概略的なブロック図である。
【図５１】本発明による、対スペース抽象定式化に対する強く型付けされたオブジェクト呼び掛けの適応デリゲーションについての好ましい実施形態の有限状態機械の概略的なブロック図である。
【図５２】本発明による、対スペース抽象定式化についてのＴＧＡＤとブリッジとの間の論理対応を示す概略的なブロック図である。
【図５３】本発明による、対スペース抽象定式化について複数のアプリケーション・プロトコルを利用する分散システムを用いて、ブリッジを通じてＴＧＡＤを実行するための好ましい実施形態の有限状態機械の概略的なブロック図である。
【図５４ａ】本発明による、自動化システム統合方法のサブセットの概略的なブロック図である。
【図５４ｂ】本発明による、自動化システム統合方法のサブセットの概略的なブロック図である。
【図５５】本発明による、自動化システム統合方法の複数の一連の反復の間の対応を示す概略的なブロック図である。
【図５６】本発明による、重複しないデルタの組を有する自動化システム統合方法の実施形態の多数の例についてのブロック流れ図である。
【図５７】本発明による、重複するデルタの組を有する自動化システム統合方法の実施形態の多数の例についてのブロック流れ図である。
【図５８】本発明による、自動化システム統合方法の実施形態の多数の事例についての単調な一連の時間減少を示すブロック流れ図である。
【図５９】本発明による、自動化システム統合方法の実施形態の単一の反復についての主要なコンポーネントの概略的なブロック図である。
【図６０】本発明による、自動化システム統合方法の具体化装置の時間ダイナミックなコンポーネントの展開及び構成のブロック流れ図である。

Claims (68)

  1. アプリケーション・プロトコル間でデータを交換する統合システムのための方法であって、
    少なくとも２つのインターフェース・カードを準備する段階を含み、
    各々のインターフェース・カードが、特定のアプリケーション・プロトコルを送り、前記特定のアプリケーション・プロトコルを受け取るように構成され、
    各々のインターフェース・カードが、コンピュータ・システムに通信可能に接続され、
    前記インターフェース・カードが、共通の相互接続に接続され、
    第１のインターフェース・カードが、受け取った第１のアプリケーション・プロトコルのビットストリームを、前記第１のアプリケーション・プロトコルを表す多次元マトリックスに変換し、
    第１のインターフェース・カードが、前記第１のアプリケーション・プロトコルの多次元マトリックスを、中間言語を表す多次元マトリックスに変換し、
    前記第１のインターフェース・カードが、前記中間言語の多次元マトリックスを第２のインターフェース・カードに送り、
    前記第２のインターフェース・カードが、前記中間言語の多次元マトリックスを、第２のアプリケーション・プロトコルを表す多次元マトリックスに変換し、
    前記第２のインターフェース・カードが、前記第２のアプリケーション・プロトコルの多次元マトリックスを、第２のアプリケーション・プロトコルのビットストリームに変換し、
    前記第２のインターフェース・カードが、前記第２のアプリケーション・プロトコルのビットストリームをコンピュータ・システムに送ることを特徴とする方法。
  2. 前記第１のインターフェース・カードが、フレームベースで前記変換を行うことを特徴とする請求項１に記載の方法。
  3. 前記第１のインターフェース・カードが、第１の有限状態機械を用いて、前記第１のアプリケーション・プロトコルのビットストリームの変換を行い、該第１のインターフェース・カードは、第２の有限状態機械を用いて、前記第１のアプリケーション・プロトコルの多次元マトリックスの変換を行うことを特徴とする請求項１に記載の方法。
  4. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項３に記載の方法。
  5. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項３に記載の方法。
  6. 前記構成テーブル及び例外テーブルが、ユーザ設定可能であることを特徴とする請求項５に記載の方法。
  7. 前記第２のインターフェース・カードが、第１の有限状態機械を用いて、前記中間言語の多次元マトリックスの変換を行い、前記第１のインターフェース・カードは、第２の有限状態機械を用いて、前記第２のアプリケーション・プロトコルの多次元マトリックスの変換を行うことを特徴とする請求項１に記載の方法。
  8. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項７に記載の方法。
  9. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項７に記載の方法。
  10. 前記構成テーブル及び例外テーブルがユーザ設定可能であることを特徴とする請求項９に記載の方法。
  11. アプリケーション・プロトコル間でデータを交換する統合システムのための装置であって、
    少なくとも２つのインターフェース・カードを備え、
    各々のインターフェース・カードが、特定のアプリケーション・プロトコルを送り、前記特定のアプリケーション・プロトコルを受け取るように構成され、
    各々のインターフェース・カードが、コンピュータ・システムに通信可能に接続され、
    前記インターフェース・カードが、共通の相互接続に接続され、
    第１のインターフェース・カードが、受け取った第１のアプリケーション・プロトコルのビットストリームを、前記第１のアプリケーション・プロトコルを表す多次元マトリックスに変換し、
    第１のインターフェース・カードが、前記第１のアプリケーション・プロトコルの多次元マトリックスを、中間言語を表す多次元マトリックスに変換し、
    前記第１のインターフェース・カードが、前記中間言語の多次元マトリックスを第２のインターフェース・カードに送り、
    前記第２のインターフェース・カードが、前記中間言語の多次元マトリックスを、第２のアプリケーション・プロトコルを表す多次元マトリックスに変換し、
    前記第２のインターフェース・カードが、前記第２のアプリケーション・プロトコルの多次元マトリックスを、第２のアプリケーション・プロトコルのビットストリームに変換し、
    前記第２のインターフェース・カードが、前記第２のアプリケーション・プロトコルのビットストリームをコンピュータ・システムに送ることを特徴とする装置。
  12. 前記第１のインターフェース・カードが、フレームベースで前記変換を行うことを特徴とする請求項１１に記載の装置。
  13. 前記第１のインターフェース・カードが、第１の有限状態機械を用いて、前記第１のアプリケーション・プロトコルのビットストリームの変換を行い、該第１のインターフェース・カードは、第２の有限状態機械を用いて、前記第１のアプリケーション・プロトコルの多次元マトリックスの変換を行うことを特徴とする請求項１１に記載の装置。
  14. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項１３に記載の装置。
  15. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項１３に記載の装置。
  16. 前記構成テーブル及び例外テーブルが、ユーザ設定可能であることを特徴とする請求項１５に記載の装置。
  17. 前記第２のインターフェース・カードが、第１の有限状態機械を用いて、前記中間言語の多次元マトリックスの変換を行い、前記第１のインターフェース・カードは、第２の有限状態機械を用いて、前記第２のアプリケーション・プロトコルの多次元マトリックスの変換を行うことを特徴とする請求項１１に記載の装置。
  18. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項１７に記載の装置。
  19. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項１７に記載の装置。
  20. 前記構成テーブル及び例外テーブルがユーザ設定可能であることを特徴とする請求項１９に記載の装置。
  21. アプリケーション・プロトコル間でデータを交換する統合システムのための方法であって、
    少なくとも２つのインターフェース・カードを準備する段階を含み、
    各々のインターフェース・カードが、特定のアプリケーション・プロトコルを送り、前記特定のアプリケーション・プロトコルを受け取るように構成され、
    各々のインターフェース・カードが、コンピュータ・システムに通信可能に接続され、
    前記インターフェース・カードが、互いに通信可能に接続され、
    第１のインターフェース・カードが、受け取った第１のアプリケーション・プロトコルのビットストリームを、中間言語を表す多次元マトリックスに変換し、
    前記第１のインターフェース・カードが、前記中間言語の多次元マトリックスを、第２のインターフェース・カードに送り、
    前記第２のインターフェース・カードが、前記中間言語の多次元マトリックスを、第２のアプリケーション・プロトコルのビットストリームに変換し、
    前記第２のインターフェース・カードが、前記第２のアプリケーション・プロトコルのビットストリームをコンピュータ・システムに送ることを特徴とする方法。
  22. 前記第１のインターフェース・カードが、フレームベースで前記変換を行うことを特徴とする請求項２１に記載の方法。
  23. 前記第１のインターフェース・カードが、有限状態機械を用いて、前記第１のアプリケーション・プロトコルのビットストリームの変換を行うことを特徴とする請求項２１に記載の方法。
  24. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項２３に記載の方法。
  25. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項２３に記載の方法。
  26. 前記構成テーブル及び例外テーブルが、ユーザ設定可能であることを特徴とする請求項２５に記載の方法。
  27. 前記第２のインターフェース・カードが、有限状態機械を用いて、前記中間言語の多次元マトリックスの変換を行うことを特徴とする請求項２１に記載の方法。
  28. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項２７に記載の方法。
  29. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項２７に記載の方法。
  30. 前記構成テーブル及び例外テーブルが、ユーザ設定可能であることを特徴とする請求項２９に記載の方法。
  31. アプリケーション・プロトコル間でデータを交換する統合システムのための装置であって、
    少なくとも２つのインターフェース・カードを備え、
    各々のインターフェース・カードが、特定のアプリケーション・プロトコルを送受信するように構成され、
    各々のインターフェース・カードが、コンピュータ・システムに通信可能に接続され、
    前記インターフェース・カードが、互いに通信可能に接続され、
    第１のインターフェース・カードが、受け取った第１のアプリケーション・プロトコルのビットストリームを、中間言語を表す多次元マトリックスに変換し、
    前記第１のインターフェース・カードが、前記中間言語の多次元マトリックスを第２のインターフェース・カードに送り、
    前記第２のインターフェース・カードが、前記中間言語の多次元マトリックスを、第２のアプリケーション・プロトコルのビットストリームに変換し、
    前記第２のインターフェース・カードが、前記第２のアプリケーション・プロトコルのビットストリームをコンピュータ・システムに送ることを特徴とする装置。
  32. 前記第１のインターフェース・カードが、フレームベースで前記変換を行うことを特徴とする請求項３１に記載の装置。
  33. 前記第１のインターフェース・カードが、有限状態機械を用いて、前記第１のアプリケーション・プロトコルのビットストリームの変換を行うことを特徴とする請求項３１に記載の装置。
  34. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項３３に記載の装置。
  35. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項３３に記載の装置。
  36. 前記構成テーブル及び例外テーブルが、ユーザ設定可能であることを特徴とする請求項３５に記載の装置。
  37. 前記第２のインターフェース・カードが、有限状態機械を用いて、前記中間言語の多次元マトリックスの変換を行うことを特徴とする請求項３１に記載の装置。
  38. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項３７に記載の装置。
  39. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項３７に記載の装置。
  40. 前記構成テーブル及び例外テーブルが、ユーザ設定可能であることを特徴とする請求項３９に記載の装置。
  41. アプリケーション・プロトコル統合システムのための方法であって、
    少なくとも２つのインターフェース・カードを準備する段階を含み、
    各々のインターフェース・カードが、外部コンピュータシステムとの間で(with)特定のアプリケーション・プロトコルを送り、前記特定のアプリケーション・プロトコルを受け取るように構成され、
    前記インターフェース・カードが、互いに通信可能に接続され、
    前記インターフェース・カードにアプリケーション・プロトコル変換手段を設けて、前記特定のアプリケーション・プロトコルを中間言語表示に変換する段階をさらに含み、
    インターフェース・カードが、前記中間言語表示を別のインターフェース・カードに送り、
    前記中間言語表示を受け取ると、インターフェース・カードが、該中間言語表示を特定のアプリケーション・プロトコルのビットストリームに変換し、
    前記受信インターフェース・カードが、前記特定のアプリケーション・プロトコルのビットストリームをコンピュータ・システムに送ることを特徴とする方法。
  42. 前記アプリケーション・プロトコル変換手段が、専用の有限状態機械を用いて、前記変換を行うことを特徴とする請求項４１に記載の方法。
  43. 前記受信インターフェース・カードが、専用の有限状態機械を用いて、前記中間言語の変換を行うことを特徴とする請求項４１の方法。
  44. 前記インターフェース・カードが、相互接続にわたって(across a interconnect)通信可能に接続されることを特徴とする請求項４１に記載の方法。
  45. アプリケーション・プロトコル統合システムであって、
    少なくとも２つのインターフェース・カードを備え、
    各々のインターフェース・カードが、外部コンピュータシステムとの間で(with)特定のアプリケーション・プロトコルを送り、前記特定のアプリケーション・プロトコルを受け取るように構成され、
    前記インターフェース・カードが、互いに通信可能に接続され、
    更に、前記インターフェース・カードに、前記特定のアプリケーション・プロトコルを中間言語表示に変換するための、アプリケーション・プロトコル変換手段を備え、
    インターフェース・カードが、前記中間言語表示を別のインターフェース・カードに送り、
    前記中間言語表示を受け取ると、インターフェース・カードが、該中間言語表示を特定のアプリケーション・プロトコルのビットストリームに変換し、
    前記受信インターフェース・カードが、前記特定のアプリケーション・プロトコルのビットストリームをコンピュータ・システムに送ることを特徴とするシステム。
  46. 前記アプリケーション・プロトコル変換手段が、専用の有限状態機械を用いて、前記変換を行うことを特徴とする請求項４５に記載の装置。
  47. 前記受信インターフェース・カードが、専用の有限状態機械を用いて、前記中間言語の変換を行うことを特徴とする請求項４５の装置。
  48. 前記インターフェース・カードが、相互接続にわたって(across a interconnect)通信可能に接続されることを特徴とする請求項４５に記載の装置。
  49. アプリケーション・プロトコル間でデータを交換する統合システムのための方法であって、
    少なくとも２つのインターフェース・カードを準備する段階を含み、
    各々のインターフェース・カードが、特定のアプリケーション・プロトコルを送り、前記特定のアプリケーション・プロトコルを受け取るように構成され、
    各々のインターフェース・カードが、コンピュータ・システムに通信可能に接続され、
    前記インターフェース・カードが、互いに通信可能に接続され、
    第１のインターフェース・カードが、受け取った第１のアプリケーション・プロトコルのビットストリームを中間言語表示に変換し、
    前記第１のインターフェース・カードが、前記中間言語表示を第２のインターフェース・カードに送り、
    前記第２のインターフェース・カードが、前記中間言語表示を第２のアプリケーション・プロトコルのビットストリームに変換し、
    前記第２のインターフェース・カードが、前記第２のアプリケーション・プロトコルのビットストリームをコンピュータ・システムに送ることを特徴とする方法。
  50. 前記第１のインターフェース・カードが、フレームベースで前記変換を行うことを特徴とする請求項４９に記載の方法。
  51. 前記第１のインターフェース・カードが、有限状態機械を用いて、前記第１のアプリケーション・プロトコルのビットストリームの変換を行うことを特徴とする請求項４９に記載の方法。
  52. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項５１に記載の方法。
  53. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項５１に記載の方法。
  54. 前記構成テーブル及び例外テーブルが、ユーザ設定可能であることを特徴とする請求項５３に記載の方法。
  55. 前記第２のインターフェース・カードが、有限状態機械を用いて、前記中間言語の変換を行うことを特徴とする請求項４９に記載の方法。
  56. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項５５に記載の方法。
  57. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項５５に記載の方法。
  58. 前記構成テーブル及び例外テーブルが、ユーザ設定可能であることを特徴とする請求項５７に記載の方法。
  59. アプリケーション・プロトコル間でデータを交換する統合システムのための装置であって、
    少なくとも２つのインターフェース・カードを備え、
    各々のインターフェース・カードが、特定のアプリケーション・プロトコルを送り、前記特定のアプリケーション・プロトコルを受け取るように構成され、
    各々のインターフェース・カードが、コンピュータ・システムに通信可能に接続され、
    前記インターフェース・カードが、互いに通信可能に接続され、
    第１のインターフェース・カードが、受け取った第１のアプリケーション・プロトコルのビットストリームを中間言語表示に変換し、
    前記第１のインターフェース・カードが、前記中間言語表示を第２のインターフェース・カードに送り、
    前記第２のインターフェース・カードが、前記中間言語表示を第２のアプリケーション・プロトコルのビットストリームに変換し、
    前記第２のインターフェース・カードが、前記第２のアプリケーション・プロトコルのビットストリームをコンピュータ・システムに送ることを特徴とする装置。
  60. 前記第１のインターフェース・カードが、フレームベースで前記変換を行うことを特徴とする請求項５９に記載の装置。
  61. 前記第１のインターフェース・カードが、有限状態機械を用いて、前記第１のアプリケーション・プロトコルのビットストリームの変換を行うことを特徴とする請求項５９に記載の装置。
  62. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項６１に記載の装置。
  63. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項６１に記載の装置。
  64. 前記構成テーブル及び例外テーブルが、ユーザ設定可能であることを特徴とする請求項６３に記載の装置。
  65. 前記第２のインターフェース・カードが、有限状態機械を用いて、前記中間言語の変換を行うことを特徴とする請求項５９に記載の装置。
  66. 前記有限状態機械が、ルックアサイド・バッファを用いて、前の状態を保持することを特徴とする請求項６５に記載の装置。
  67. 前記有限状態機械が、構成テーブル及び例外テーブルを用いて、該有限状態機械の変換動作を調整することを特徴とする請求項６５に記載の装置。
  68. 前記構成テーブル及び例外テーブルが、ユーザ設定可能であることを特徴とする請求項６７に記載の装置。
JP2002584522A 2001-04-25 2002-04-25 適応マルチプロトコル通信システム Pending JP2005504455A (ja)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US28659501P 2001-04-25 2001-04-25
US29835501P 2001-06-14 2001-06-14
US30827501P 2001-07-26 2001-07-26
US30828001P 2001-07-26 2001-07-26
US10/128,941 US20020161907A1 (en) 2001-04-25 2002-04-24 Adaptive multi-protocol communications system
PCT/US2002/013182 WO2002087136A2 (en) 2001-04-25 2002-04-25 Adaptive multi-protocol communications system

Publications (2)

Publication Number Publication Date
JP2005504455A true JP2005504455A (ja) 2005-02-10
JP2005504455A5 JP2005504455A5 (ja) 2006-01-05

Family

ID=27537817

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002584522A Pending JP2005504455A (ja) 2001-04-25 2002-04-25 適応マルチプロトコル通信システム

Country Status (6)

Country Link
US (1) US20020161907A1 (ja)
EP (1) EP1381962A2 (ja)
JP (1) JP2005504455A (ja)
CN (1) CN1516840A (ja)
AU (1) AU2002309605A1 (ja)
WO (1) WO2002087136A2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012513639A (ja) * 2008-12-22 2012-06-14 グーグル インコーポレイテッド 複製ストレージクラスタのための非同期式分散ガーベッジコレクション
JP2012513640A (ja) * 2008-12-22 2012-06-14 グーグル インコーポレイテッド 複製されたコンテンツアドレス可能ストレージクラスタのための非同期分散型重複排除

Families Citing this family (189)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10137574B4 (de) * 2001-07-31 2006-01-19 Infineon Technologies Ag Verfahren, Computerprogramm und Datenverarbeitungsanlage zur Verarbeitung von Netzwerktopologien
US20030065505A1 (en) * 2001-08-17 2003-04-03 At&T Corp. Systems and methods for abstracting portions of information that is represented with finite-state devices
JP2003076620A (ja) * 2001-09-04 2003-03-14 Fujitsu Ltd 動的プロトコル交換システムおよび方法
US7401336B2 (en) * 2002-05-30 2008-07-15 Oracle International Corporation Role based integrated platform
US7277963B2 (en) * 2002-06-26 2007-10-02 Sandvine Incorporated TCP proxy providing application layer modifications
WO2004014065A2 (en) * 2002-08-05 2004-02-12 John Campbell System of finite state machines
WO2004023322A1 (en) * 2002-09-09 2004-03-18 Atitania Ltd. Method and apparatus for converting data between two dissimilar systems
US7257575B1 (en) 2002-10-24 2007-08-14 At&T Corp. Systems and methods for generating markup-language based expressions from multi-modal and unimodal inputs
US7512531B1 (en) * 2002-12-30 2009-03-31 Daniel Shia Method and apparatus for specifying reactive systems
US6985910B2 (en) * 2003-02-06 2006-01-10 International Business Machines Corporation Tilting tree spinning cones method and system for mapping XML to n-dimensional data structure using a single dimensional mapping array
US7860916B2 (en) * 2003-03-18 2010-12-28 Microsoft Corporation Systems and methods for transforming data in buffer memory without unnecessarily copying data to additional memory locations
US7953891B2 (en) 2003-03-18 2011-05-31 Microsoft Corporation Systems and methods for scheduling data flow execution based on an arbitrary graph describing the desired data flow
US7131077B1 (en) * 2003-03-28 2006-10-31 Xilinx, Inc Using an embedded processor to implement a finite state machine
US20040199622A1 (en) * 2003-04-07 2004-10-07 Huscher Anthony Alan eRoom operations console
US7702729B2 (en) * 2003-04-08 2010-04-20 Johanson Bradley E Event heap: a coordination infrastructure for dynamic heterogeneous application interactions in ubiquitous computing environments
JP4136857B2 (ja) * 2003-09-11 2008-08-20 キヤノン株式会社 機器検索方法およびプログラム
WO2005052703A1 (de) * 2003-11-17 2005-06-09 Siemens Aktiengesellschaft Redundantes automatisierungssystem zur steuerung einer tech­nischen einrichtung sowie verfahren zum betrieb eines derar­tigen automatisierungssystems
US7372946B2 (en) * 2003-12-11 2008-05-13 Agilent Technologies, Inc. Measurement deferral and aggregation for extensible test configuration
US7519719B2 (en) * 2004-04-15 2009-04-14 Agilent Technologies, Inc. Automatic creation of protocol dependent control path for instrument application
CN100334821C (zh) * 2004-04-19 2007-08-29 中兴通讯股份有限公司 一种通信系统有限状态机的测试方法
US7810103B2 (en) * 2004-04-30 2010-10-05 Microsoft Corporation System and method for validating communication specification conformance between a device driver and a hardware device
US7789308B2 (en) * 2004-05-13 2010-09-07 Cisco Technology, Inc. Locating and provisioning devices in a network
US7336175B2 (en) * 2004-05-13 2008-02-26 Cisco Technology, Inc. Methods and devices for locating and uniquely provisioning RFID devices
US8249953B2 (en) * 2004-05-13 2012-08-21 Cisco Technology, Inc. Methods and apparatus for determining the status of a device
US7422152B2 (en) 2004-05-13 2008-09-09 Cisco Technology, Inc. Methods and devices for providing scalable RFID networks
US8113418B2 (en) * 2004-05-13 2012-02-14 Cisco Technology, Inc. Virtual readers for scalable RFID infrastructures
US7325734B2 (en) * 2004-05-13 2008-02-05 Cisco Technology, Inc. Methods and devices for assigning RFID device personality
US7322523B2 (en) * 2004-05-13 2008-01-29 Cisco Technology, Inc. Methods and devices for uniquely provisioning RFID devices
US7930432B2 (en) * 2004-05-24 2011-04-19 Microsoft Corporation Systems and methods for distributing a workplan for data flow execution based on an arbitrary graph describing the desired data flow
WO2005122078A2 (en) 2004-06-04 2005-12-22 Sap Ag Consistent set of interfaces derived from a business object model
US8604910B2 (en) * 2004-07-13 2013-12-10 Cisco Technology, Inc. Using syslog and SNMP for scalable monitoring of networked devices
JP4534904B2 (ja) * 2004-10-21 2010-09-01 株式会社デンソー ブルートゥース無線機、近距離無線通信機およびプログラム
US7509431B2 (en) * 2004-11-17 2009-03-24 Cisco Technology, Inc. Performing message and transformation adapter functions in a network element on behalf of an application
US7664879B2 (en) 2004-11-23 2010-02-16 Cisco Technology, Inc. Caching content and state data at a network element
CN100358302C (zh) * 2004-12-06 2007-12-26 华为技术有限公司 一种使用状态机测试网元接口的方法
US7987272B2 (en) 2004-12-06 2011-07-26 Cisco Technology, Inc. Performing message payload processing functions in a network element on behalf of an application
US7496750B2 (en) * 2004-12-07 2009-02-24 Cisco Technology, Inc. Performing security functions on a message payload in a network element
US7725934B2 (en) 2004-12-07 2010-05-25 Cisco Technology, Inc. Network and application attack protection based on application layer message inspection
US8082304B2 (en) 2004-12-10 2011-12-20 Cisco Technology, Inc. Guaranteed delivery of application layer messages by a network element
US7606267B2 (en) 2004-12-10 2009-10-20 Cisco Technology, Inc. Reducing the sizes of application layer messages in a network element
US8059539B2 (en) * 2004-12-29 2011-11-15 Hewlett-Packard Development Company, L.P. Link throughput enhancer
US7551567B2 (en) * 2005-01-05 2009-06-23 Cisco Technology, Inc. Interpreting an application message at a network element using sampling and heuristics
US7836202B2 (en) * 2005-01-19 2010-11-16 Iona Technologies Limited Communication system integrating a plurality of middleware and implementing sophisticated paths for data flow
US7721005B2 (en) * 2005-01-19 2010-05-18 Iona Technologies Limited Data bus between middleware layers
US7904587B2 (en) * 2005-01-19 2011-03-08 Iona Technologies Limited Flexibly deployable communication device facilitating interoperation between middleware
US20060161718A1 (en) * 2005-01-20 2006-07-20 Berke Stuart A System and method for a non-uniform crossbar switch plane topology
US7698416B2 (en) * 2005-01-25 2010-04-13 Cisco Technology, Inc. Application layer message-based server failover management by a network element
US8205046B2 (en) 2005-01-31 2012-06-19 Hewlett-Packard Development Company, L.P. System and method for snooping cache information using a directory crossbar
WO2006094428A1 (en) * 2005-03-05 2006-09-14 Intel Corporation Asynchronous network stack operation in an operating system independent environment
US8121148B2 (en) * 2005-03-24 2012-02-21 Ixia Protocol stack using shared memory
US7414975B2 (en) * 2005-03-24 2008-08-19 Ixia Protocol stack
US9363481B2 (en) * 2005-04-22 2016-06-07 Microsoft Technology Licensing, Llc Protected media pipeline
US20060271698A1 (en) * 2005-05-16 2006-11-30 Shrader Anthony G Boa back office integration protocol
US7953826B2 (en) 2005-07-14 2011-05-31 Cisco Technology, Inc. Provisioning and redundancy for RFID middleware servers
US7345585B2 (en) * 2005-08-01 2008-03-18 Cisco Technology, Inc. Network based device for providing RFID middleware functionality
US20070030816A1 (en) * 2005-08-08 2007-02-08 Honeywell International Inc. Data compression and abnormal situation detection in a wireless sensor network
US20070038432A1 (en) * 2005-08-15 2007-02-15 Maurice De Grandmont Data acquisition and simulation architecture
US7782873B2 (en) * 2005-08-23 2010-08-24 Slt Logic, Llc Omni-protocol engine for reconfigurable bit-stream processing in high-speed networks
US8189599B2 (en) * 2005-08-23 2012-05-29 Rpx Corporation Omni-protocol engine for reconfigurable bit-stream processing in high-speed networks
US8698603B2 (en) 2005-11-15 2014-04-15 Cisco Technology, Inc. Methods and systems for automatic device provisioning in an RFID network using IP multicast
US7447707B2 (en) * 2005-12-16 2008-11-04 Microsoft Corporation Automatic schema discovery for electronic data interchange (EDI) at runtime
US8522194B2 (en) 2005-12-30 2013-08-27 Sap Ag Software modeling
US8448137B2 (en) 2005-12-30 2013-05-21 Sap Ag Software model integration scenarios
US8326703B2 (en) 2005-12-30 2012-12-04 Sap Ag Architectural design for product catalog management application software
US8676617B2 (en) 2005-12-30 2014-03-18 Sap Ag Architectural design for self-service procurement application software
US8327319B2 (en) 2005-12-30 2012-12-04 Sap Ag Software model process interaction
US8407664B2 (en) 2005-12-30 2013-03-26 Sap Ag Software model business objects
US8316344B2 (en) 2005-12-30 2012-11-20 Sap Ag Software model deployment units
US8660904B2 (en) 2005-12-30 2014-02-25 Sap Ag Architectural design for service request and order management application software
US8370794B2 (en) 2005-12-30 2013-02-05 Sap Ag Software model process component
US8396731B2 (en) 2005-12-30 2013-03-12 Sap Ag Architectural design for service procurement application software
US8402426B2 (en) 2005-12-30 2013-03-19 Sap Ag Architectural design for make to stock application software
US8380553B2 (en) 2005-12-30 2013-02-19 Sap Ag Architectural design for plan-driven procurement application software
US8321831B2 (en) 2005-12-30 2012-11-27 Sap Ag Architectural design for internal projects application software
US8326702B2 (en) 2006-03-30 2012-12-04 Sap Ag Providing supplier relationship management software application as enterprise services
US8442850B2 (en) 2006-03-30 2013-05-14 Sap Ag Providing accounting software application as enterprise services
US8396749B2 (en) 2006-03-30 2013-03-12 Sap Ag Providing customer relationship management application as enterprise services
US20070233539A1 (en) * 2006-03-30 2007-10-04 Philipp Suenderhauf Providing human capital management software application as enterprise services
US8396761B2 (en) 2006-03-30 2013-03-12 Sap Ag Providing product catalog software application as enterprise services
US8538864B2 (en) 2006-03-30 2013-09-17 Sap Ag Providing payment software application as enterprise services
US8438119B2 (en) 2006-03-30 2013-05-07 Sap Ag Foundation layer for services based enterprise software architecture
US8321832B2 (en) 2006-03-31 2012-11-27 Sap Ag Composite application modeling
US8312416B2 (en) 2006-04-13 2012-11-13 Sap Ag Software model business process variant types
KR100783679B1 (ko) * 2006-05-11 2007-12-07 한국과학기술원 데이터 스트림에 기반하는 서비스의 개발, 배치, 제공을용이하게 하는 미들웨어 시스템
US7738456B2 (en) * 2006-08-07 2010-06-15 Cisco Technology, Inc. Techniques to map switch and router ports to physical locations
US20080071887A1 (en) * 2006-09-19 2008-03-20 Microsoft Corporation Intelligent translation of electronic data interchange documents to extensible markup language representations
US8108767B2 (en) 2006-09-20 2012-01-31 Microsoft Corporation Electronic data interchange transaction set definition based instance editing
US8161078B2 (en) 2006-09-20 2012-04-17 Microsoft Corporation Electronic data interchange (EDI) data dictionary management and versioning system
US8745486B2 (en) * 2007-01-25 2014-06-03 Microsoft Corporation Streamable interactive rendering-independent page layout
WO2008127474A1 (en) * 2007-04-17 2008-10-23 Edward Frederick Publishing, importing, and formatting web page modules
US7925783B2 (en) * 2007-05-23 2011-04-12 Microsoft Corporation Transparent envelope for XML messages
US7552405B1 (en) 2007-07-24 2009-06-23 Xilinx, Inc. Methods of implementing embedded processor systems including state machines
US8103785B2 (en) * 2007-12-03 2012-01-24 Seafire Micros, Inc. Network acceleration techniques
US8671033B2 (en) 2007-12-31 2014-03-11 Sap Ag Architectural design for personnel events application software
US8510143B2 (en) 2007-12-31 2013-08-13 Sap Ag Architectural design for ad-hoc goods movement software
US8315900B2 (en) 2007-12-31 2012-11-20 Sap Ag Architectural design for self-service procurement application software
US8401936B2 (en) 2007-12-31 2013-03-19 Sap Ag Architectural design for expense reimbursement application software
US8447657B2 (en) 2007-12-31 2013-05-21 Sap Ag Architectural design for service procurement application software
US8671032B2 (en) 2007-12-31 2014-03-11 Sap Ag Providing payment software application as enterprise services
US8671034B2 (en) 2007-12-31 2014-03-11 Sap Ag Providing human capital management software application as enterprise services
US8266686B1 (en) * 2008-01-11 2012-09-11 Sprint Communications Company L.P. System and method for VoIP firewall security
EP2139193B1 (en) * 2008-06-26 2012-10-17 TELEFONAKTIEBOLAGET LM ERICSSON (publ) A method of performing data mediation, and an associated computer program product, data mediation device and information system
US8453126B1 (en) * 2008-07-30 2013-05-28 Dulles Research LLC System and method for converting base SAS runtime macro language scripts to JAVA target language
US8868532B2 (en) 2008-08-08 2014-10-21 Microsoft Corporation Message exchange pattern rendezvous abstraction
US8386325B2 (en) 2008-09-18 2013-02-26 Sap Ag Architectural design for plan-driven procurement application software
US8818884B2 (en) 2008-09-18 2014-08-26 Sap Ag Architectural design for customer returns handling application software
US8374896B2 (en) 2008-09-18 2013-02-12 Sap Ag Architectural design for opportunity management application software
US8326706B2 (en) 2008-09-18 2012-12-04 Sap Ag Providing logistics execution application as enterprise services
US8321250B2 (en) 2008-09-18 2012-11-27 Sap Ag Architectural design for sell from stock application software
US8359218B2 (en) 2008-09-18 2013-01-22 Sap Ag Computer readable medium for implementing supply chain control using service-oriented methodology
US8315926B2 (en) 2008-09-18 2012-11-20 Sap Ag Architectural design for tax declaration application software
US8380549B2 (en) 2008-09-18 2013-02-19 Sap Ag Architectural design for embedded support application software
US8352338B2 (en) 2008-09-18 2013-01-08 Sap Ag Architectural design for time recording application software
US8595077B2 (en) 2008-09-18 2013-11-26 Sap Ag Architectural design for service request and order management application software
US8401928B2 (en) 2008-09-18 2013-03-19 Sap Ag Providing supplier relationship management software application as enterprise services
CN101409673B (zh) * 2008-11-12 2013-07-03 北京恒光创新科技股份有限公司 一种网络适配器数据传输方法、网络适配器及系统
US8401908B2 (en) 2008-12-03 2013-03-19 Sap Ag Architectural design for make-to-specification application software
US8321306B2 (en) 2008-12-03 2012-11-27 Sap Ag Architectural design for selling project-based services application software
US8321308B2 (en) 2008-12-03 2012-11-27 Sap Ag Architectural design for manual invoicing application software
US8311904B2 (en) 2008-12-03 2012-11-13 Sap Ag Architectural design for intra-company stock transfer application software
US8738476B2 (en) 2008-12-03 2014-05-27 Sap Ag Architectural design for selling standardized services application software
US8671035B2 (en) 2008-12-11 2014-03-11 Sap Ag Providing payroll software application as enterprise services
WO2010103341A1 (en) * 2009-03-10 2010-09-16 Telefonaktiebolaget L M Ericsson (Publ) System and methods for a managed application server restart
US8990324B2 (en) * 2010-04-22 2015-03-24 Bae Systems Information And Electronic Systems Integration Inc. Distributing messages in multiple formats in tactical communications networks
US20110264880A1 (en) * 2010-04-23 2011-10-27 Tatu Ylonen Oy Ltd Object copying with re-copying concurrently written objects
US8375045B2 (en) * 2010-06-23 2013-02-12 Raytheon Company Translating a binary data stream using binary markup language (BML) schema
US8639858B2 (en) 2010-06-23 2014-01-28 International Business Machines Corporation Resizing address spaces concurrent to accessing the address spaces
US9195623B2 (en) 2010-06-23 2015-11-24 International Business Machines Corporation Multiple address spaces per adapter with address translation
US8650335B2 (en) 2010-06-23 2014-02-11 International Business Machines Corporation Measurement facility for adapter functions
US9213661B2 (en) 2010-06-23 2015-12-15 International Business Machines Corporation Enable/disable adapters of a computing environment
US8566480B2 (en) 2010-06-23 2013-10-22 International Business Machines Corporation Load instruction for communicating with adapters
US8635430B2 (en) 2010-06-23 2014-01-21 International Business Machines Corporation Translation of input/output addresses to memory addresses
US8650337B2 (en) * 2010-06-23 2014-02-11 International Business Machines Corporation Runtime determination of translation formats for adapter functions
US8626970B2 (en) 2010-06-23 2014-01-07 International Business Machines Corporation Controlling access by a configuration to an adapter function
US8468284B2 (en) 2010-06-23 2013-06-18 International Business Machines Corporation Converting a message signaled interruption into an I/O adapter event notification to a guest operating system
US8549182B2 (en) 2010-06-23 2013-10-01 International Business Machines Corporation Store/store block instructions for communicating with adapters
US8572635B2 (en) 2010-06-23 2013-10-29 International Business Machines Corporation Converting a message signaled interruption into an I/O adapter event notification
US9342352B2 (en) 2010-06-23 2016-05-17 International Business Machines Corporation Guest access to address spaces of adapter
US8621112B2 (en) 2010-06-23 2013-12-31 International Business Machines Corporation Discovery by operating system of information relating to adapter functions accessible to the operating system
US8615645B2 (en) 2010-06-23 2013-12-24 International Business Machines Corporation Controlling the selectively setting of operational parameters for an adapter
CN101964798A (zh) * 2010-10-15 2011-02-02 德讯科技股份有限公司 基于远程桌面协议的多图形协议统一代理系统
US8819286B2 (en) * 2010-10-19 2014-08-26 Hewlett-Packard Development Company, L.P. Methods, systems, and apparatus for processing messaging data sets using structured data sets
CN102255802B (zh) * 2011-06-27 2014-01-01 中国建设银行股份有限公司 一种sna主机报文解析的方法及系统
CN103095661A (zh) * 2011-11-01 2013-05-08 镇江华扬信息科技有限公司 一种基于Javascript虫洞技术的SSO实现方式
CN103685041B (zh) * 2012-09-04 2017-04-19 清华大学 一种基于比特粒度可编程的路由器及路由方法
US8996061B2 (en) * 2012-09-21 2015-03-31 Bae Systems Information And Electronic Systems Integration Inc. Bridging communications between tactical SDR and cellular telephone networks
US9189441B2 (en) * 2012-10-19 2015-11-17 Intel Corporation Dual casting PCIE inbound writes to memory and peer devices
WO2014169227A1 (en) * 2013-04-12 2014-10-16 Northeastern University Ontology-based waveform reconfiguration
CN103269285B (zh) * 2013-05-24 2016-08-17 杭州华三通信技术有限公司 网络通信集群装置和用于实现网络通信集群的方法
CN104243512B (zh) * 2013-06-07 2018-05-04 上海联影医疗科技有限公司 一种医疗服务的集成方法
US9323620B2 (en) 2013-06-12 2016-04-26 International Business Machines Corporation Implementing shared adapter configuration updates concurrent with maintenance actions in a virtualized system
US9304849B2 (en) 2013-06-12 2016-04-05 International Business Machines Corporation Implementing enhanced error handling of a shared adapter in a virtualized system
US9400704B2 (en) 2013-06-12 2016-07-26 Globalfoundries Inc. Implementing distributed debug data collection and analysis for a shared adapter in a virtualized system
US9317317B2 (en) 2013-06-12 2016-04-19 International Business Machines Corporation Implementing concurrent device driver maintenance and recovery for an SRIOV adapter in a virtualized system
US9111046B2 (en) 2013-06-12 2015-08-18 International Business Machines Corporation Implementing capacity and user-based resource allocation for a shared adapter in a virtualized system
US9720775B2 (en) 2013-06-12 2017-08-01 International Business Machines Corporation Implementing concurrent adapter firmware update for an SRIOV adapter in a virtualized system
US10543706B2 (en) * 2013-08-09 2020-01-28 MeccoPartners, LLC EIP protocol converter system for laser for dot peen marking systems
CN104392192A (zh) * 2014-10-11 2015-03-04 昆腾微电子股份有限公司 在非接触卡中实现通信协议复用的装置和方法
US10069928B1 (en) * 2015-01-21 2018-09-04 Amazon Technologies, Inc. Translating requests/responses between communication channels having different protocols
JP6356909B2 (ja) * 2015-04-23 2018-07-11 株式会社東芝 クライアントシステム、クライアントシステムの管理方法、システムコントローラ
US10255336B2 (en) 2015-05-07 2019-04-09 Datometry, Inc. Method and system for transparent interoperability between applications and data management systems
CN106357706A (zh) * 2015-07-13 2017-01-25 青岛海尔滚筒洗衣机有限公司 电器设备控制方法、电器设备控制装置及其电器设备
US10594779B2 (en) 2015-08-27 2020-03-17 Datometry, Inc. Method and system for workload management for data management systems
SG10201507051WA (en) * 2015-09-03 2017-04-27 Certis Cisco Security Pte Ltd System and method for high frequency heuristic data acquisition and analytics of information security events
EP3139548B1 (en) * 2015-09-04 2018-04-11 Airbus Operations High assurance segregated gateway interconnecting different domains
CN105516158A (zh) * 2015-12-18 2016-04-20 山东海量信息技术研究院 一种可配置协议转换状态机电路结构及协议配置方法
CN105812368A (zh) * 2016-03-15 2016-07-27 山东超越数控电子有限公司 一种多种通讯协议通用编程方法
KR102421791B1 (ko) 2016-05-26 2022-07-15 삼성전자주식회사 Mmt 네트워크 시스템에서 미디어 시간 정보를 전송 하는 방법 및 장치
CN108076110B (zh) * 2016-11-14 2021-02-26 北京京东尚科信息技术有限公司 电子数据交换系统和包含电子数据交换系统的装置
US10783287B2 (en) * 2017-06-14 2020-09-22 International Business Machines Corporation Employing natural language processing to facilitate geospatial analysis
CN108595731B (zh) * 2018-01-23 2022-02-08 苏州盛科通信股份有限公司 一种以太网芯片中动态表项的设计方法及装置
US10402380B1 (en) * 2018-05-09 2019-09-03 Carecloud Corporation Interactive user interface for schema transformation
US10944850B2 (en) * 2018-10-29 2021-03-09 Wandisco, Inc. Methods, devices and systems for non-disruptive upgrades to a distributed coordination engine in a distributed computing environment
US11436213B1 (en) 2018-12-19 2022-09-06 Datometry, Inc. Analysis of database query logs
US11294869B1 (en) 2018-12-19 2022-04-05 Datometry, Inc. Expressing complexity of migration to a database candidate
US11403282B1 (en) 2018-12-20 2022-08-02 Datometry, Inc. Unbatching database queries for migration to a different database
US11178113B2 (en) * 2019-07-30 2021-11-16 Ppip, Llc Protocol isolation for security
CN111343196B (zh) * 2020-03-19 2020-12-08 广州市城建开发集团名特网络发展有限公司 一种兼容多种通讯协议的通信系统与通信方法
CN111414266B (zh) * 2020-03-23 2024-04-05 浪潮通用软件有限公司 一种分布式事务的同步异步通信方法和装置
CN111625224B (zh) * 2020-05-28 2023-11-24 北京百度网讯科技有限公司 代码生成方法、装置、设备及存储介质
US11625230B2 (en) 2020-09-22 2023-04-11 Cisco Technology, Inc. Identifying execution environments for deploying network functions
US11442703B2 (en) 2020-09-22 2022-09-13 Cisco Technology, Inc. Domain-specific language for serverless network functions
US11126415B1 (en) * 2020-09-22 2021-09-21 Cisco Technology, Inc. Combining domain-specific language with general-purpose language for serverless network functions
CN113300893B (zh) * 2021-05-25 2022-03-08 西北工业大学 一种基于硬件的反射内存网络系统
US20230004573A1 (en) * 2021-06-30 2023-01-05 Optx Solutions, Llc Systems and methods for ingesting data in disparate formats
CN113836060B (zh) * 2021-09-24 2024-05-28 北京机电工程研究所 一种适用于仿真模型及流程模型的分布式实时仿真平台
CN114679502B (zh) * 2022-03-15 2023-11-21 珠海格力电器股份有限公司 用于数控系统的通信方法和系统
CN114697131A (zh) * 2022-04-27 2022-07-01 京东科技控股股份有限公司 数据调用方法及装置、存储介质及电子设备
CN116846863B (zh) * 2023-08-30 2023-11-10 东方空间技术(山东)有限公司 一种光纤反射内存网内存映射方法、装置及计算设备

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5410675A (en) * 1989-08-21 1995-04-25 Lisa M. Shreve Method of conforming input data to an output data structure and engine for accomplishing same
US5574919A (en) * 1991-08-29 1996-11-12 Lucent Technologies Inc. Method for thinning a protocol
US5826017A (en) * 1992-02-10 1998-10-20 Lucent Technologies Apparatus and method for communicating data between elements of a distributed system using a general protocol
US5555415A (en) * 1994-01-10 1996-09-10 Metasphere, Inc. Object oriented event message dispatching subsystem and method utilizing a disposition matrix
US5680552A (en) * 1994-09-20 1997-10-21 Lucent Technologies Inc. Gateway system for interconnecting different data communication networks
US5826030A (en) * 1995-11-30 1998-10-20 Excel Switching Corporation Telecommunication switch having a universal API with a single call processing message including user-definable data and response message each having a generic format
US6134598A (en) * 1997-05-23 2000-10-17 Adobe Systems Incorporated Data stream processing on networked computer system lacking format-specific data processing resources
US6111893A (en) * 1997-07-31 2000-08-29 Cisco Technology, Inc. Universal protocol conversion
US6785730B1 (en) * 1999-02-16 2004-08-31 Rebecca S. Taylor Generic communications protocol translator
US6401132B1 (en) * 1999-08-03 2002-06-04 International Business Machines Corporation Subchaining transcoders in a transcoding framework
KR100476895B1 (ko) * 2002-05-21 2005-03-18 삼성전자주식회사 가변 가능한 데이터 전송 모드를 갖는 인터페이스 장치 및그것의 동작 방법

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012513639A (ja) * 2008-12-22 2012-06-14 グーグル インコーポレイテッド 複製ストレージクラスタのための非同期式分散ガーベッジコレクション
JP2012513640A (ja) * 2008-12-22 2012-06-14 グーグル インコーポレイテッド 複製されたコンテンツアドレス可能ストレージクラスタのための非同期分散型重複排除
US9081841B2 (en) 2008-12-22 2015-07-14 Google Inc. Asynchronous distributed garbage collection for replicated storage clusters
US10291699B2 (en) 2008-12-22 2019-05-14 Google Llc Asynchronous distributed de-duplication for replicated content addressable storage clusters
US11943290B2 (en) 2008-12-22 2024-03-26 Google Llc Asynchronous distributed de-duplication for replicated content addressable storage clusters

Also Published As

Publication number Publication date
WO2002087136A3 (en) 2003-02-13
WO2002087136B1 (en) 2003-11-13
EP1381962A2 (en) 2004-01-21
AU2002309605A1 (en) 2002-11-05
CN1516840A (zh) 2004-07-28
WO2002087136A2 (en) 2002-10-31
US20020161907A1 (en) 2002-10-31
WO2002087136A9 (en) 2003-04-10

Similar Documents

Publication Publication Date Title
JP2005504455A (ja) 適応マルチプロトコル通信システム
Schmidt et al. C++ Network Programming, Volume 2: Systematic Reuse with ACE and Frameworks
Schmidt et al. Pattern-oriented software architecture, patterns for concurrent and networked objects
US6453356B1 (en) Data exchange system and method
Pyarali et al. Design and Performance of an Object-Oriented Framework for High-Performance Electronic Medical Imaging.
KR100679809B1 (ko) 분산객체간 통신장치 및 방법
JP5026415B2 (ja) データセントリックワークフロー
US20030135850A1 (en) System of reusable software parts and methods of use
Astley et al. Customization and composition of distributed objects: Middleware abstractions for policy management
WO2002001349A9 (en) System and method for coordination-centric design of software systems
Tari et al. Fundamentals of distributed object systems: the CORBA perspective
Bever et al. Distributed systems, OSF DCE, and beyond
CN101188624A (zh) 基于虚拟机的网格中间件系统
US20030055921A1 (en) Method and apparatus for reengineering legacy systems for seamless interaction with distributed component systems
Voth et al. Distributed application development for three-tier architectures: Microsoft on Windows DNA
Gomaa et al. Reusable component interconnection patterns for distributed software architectures
Waddington et al. A distributed multimedia component architecture
Shinde et al. Modeling NICs with Unicorn
Papadopoulos et al. Control-driven coordination programming in shared dataspace
Singhai QuarterWare: A middleware toolkit of software RISC components
Satyanarayanan et al. RPC2 User Guide and Reference Manual
Liu A distributed data flow model for composing software services
Sheu et al. A New Architecture for Integration of CORBA and OODB
Kindberg Reconfiguring distributed computations
Brightwell et al. Experiences implementing the MPI standard on Sandias lightweight kernels

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050421

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050421

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050518

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080317

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20080818