(57)【要約】アダプタインターフェースを介して複数のアプリケーションをイベントバスに接続する分散コンピューティングシステム。アプリケーション間でやり取りされるメッセージは、イベントバス上で送信され、ルールリポジトリ内に格納されているルールに従って処理される。
2004520641.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションと、
それぞれのアプリケーションに対応するアダプタであって、それぞれが前記アプリケーションとイベントバスインターフェースとの間のインターフェースを提供するアダプタと、
メッセージを受信し、メッセージをアダプタおよびルールエンジンに分配するためのイベントバスインターフェースを備えるイベントバスと、
メッセージを処理するためのルールを有するルールリポジトリと、
メッセージを受信し、ルールリポジトリに従ってメッセージを生成し、イベントバスを介して生成されたメッセージを送信するためのルールエンジンとを備えることを特徴とするコンピュータシステム。
【発明の詳細な説明】
【０００１】
（関連出願の相互引用）
本出願は、２０００年７月１９日に出願された米国仮特許出願第 ６０／２１９３０４号の利益を主張し、２０００年１１月１６日に出願された米国仮特許出願第６０／２４９４１２号、２００１年２月１２日に出願された米国仮特許出願第６０／２６８３８６号、および２０００年１２月２２日に出願された米国仮特許出願第０９／７４７３０７号と関連し、これらの特許出願は参照により本明細書に組み込まれている。
【０００２】
（背景）
既存のアプリケーションプラットフォームの問題は、それらのプラットフォーム向けにアプリケーションを作成することが難しいという点である。Ｗｉｎｄｏｗｓ（登録商標）プラットフォームを例にとる。Ｗｉｎｄｏｗｓ（登録商標）以前には、プログラマはＤＯＳの制約のもとで作業を行い、全画面を１つのアプリケーションで一度に占有し、専用のプリンタドライバを作成し、メモリを管理し、ＴＳＲを処理し、どれも各ベンダが自主的に解決しなければならないやっかいな問題であった。Ｗｉｎｄｏｗｓ（登録商標）により、複数のプロセスに対するウィンドウ管理およびメモリセグメント化による画面への共有アクセス、共有プリンタドライバモデル、およびアプリケーションでカップルに名前を付けるための抽象化アクセスなど、アプリケーション作成者にとって多くの事柄が容易になった。消費者にとっての利点は、ＤＯＳの世界と比べて比較的容易かつ低コストの開発によって入手可能となった豊富なアプリケーションによる共通のユーザ体験であった。
【０００３】
Ｗｉｎｄｏｗｓ（登録商標）などのプラットフォームで問題になるのは、アプリケーションを他のプラットフォームに移植する難しさである。たとえば、Ｗｉｎｄｏｗｓ（登録商標）アプリケーションは大幅な書き換えを行うことなしにＵｎｉｘ（登録商標）プラットフォームで実行させることはできない。修正することなく複数のプラットフォーム上でアプリケーションを開発し、実行できる環境を備えることが望ましい。また、異なるプラットフォーム上で実行されているアプリケーション同士の信頼性の高い確実な通信が可能であることも望ましい。
【０００４】
（詳細な説明）
分散アプリケーションおよびサービスが稼働されるプログラム可能な高水準ネットワークコンピュータインフラストラクチャを提供する。一実施形態では、ネットワークコンピュータインフラストラクチャは、既存のネットワーク技術およびプロトコルを使用して接続されているアクティブなマシンから構築される。これらのネットワークマシンをノードと呼ぶ。アプリケーションおよびサービスは、１つまたは複数のノード上で実行され、メッセージ交換により通信が行われる。アプリケーションおよびサービスはネットワーク上で名前が付けられ、登録される。ノードもネットワーク上で名前が付けられ、登録される。単一の名前付きアプリケーションまたはサービスが複数のノードにまたがることもある。ネットワークでは以下を使用する。
【０００５】
・ＯＳアプリケーションまたはメタアプリケーション（．Ｒファイル）により発行され、消費されるアドレッシング、ロジック、およびコンテンツを含むメッセージ。（ＯＳアプリケーションとは、特定のＯＳおよびハードウェアプラットフォーム上で実行されるように書かれたアプリケーションのことである。このようなアプリケーションの例として、Ｗｏｒｄなどの従来のデスクトップアプリケーションや、Ａｐａｃｈｅ Ｗｅｂサーバなどのサーバアプリケーションがある。）（メタアプリケーションとは、ルールベースのアプリケーションのことであり、モジュールとも呼ばれる。）
・異なる種類のアプリケーションがタスクを実行するメッセージを発行する。
・メッセージは、プラットフォームに用意されている命令、ペイロード、および宛先アドレスを含むことができる。
・メッセージ命令は、アプリケーションネットワークルータをプログラムするために使用される命令と同じ命令のサブセットである（．Ｒファイル）。
・アプリケーション通信では、要求／応答を含む複数のメッセージパターン、一方向の送信をサポートするか、または、ネットワークの複数の要素間の要求および応答の組み合わせまたはネットワークのどれか１つの要素との複数の交換で構築することができる。
・各ノードは、メタアプリケーションに従って評価され、他のノードまたはノードローカルアプリケーションプロセッサに経路設定される、経路指定メッセージのプラットフォームを形成する経路指定プロセッサインフラストラクチャルータをサポートする。
・メッセージに含まれるコードを実行できる、またはメッセージ内のデータをアプリケーションまたはメタアプリケーションに送ることができるプロセッサ。
・アプリケーションおよびメタアプリケーションは、他のメタアプリケーションによって公開されているサービスで構成できる。
【０００６】
専用のハイスケールメッセージルータであるアプリケーションネットワークルータは、コンピュータインフラストラクチャまたはプラットフォームの一要素である。これは各ノード上で実行され、サービス配信およびコンテンツの品質を制御することによりイベントを１つまたは複数のエンドポイントに、マシン内／ノード内で、またはマシン間／ノード間で受け渡すことができる。サービス品質とは、二重チャネルの制御、通信エンティティ識別の認証、システムおよびアプリケーション側で用意する基準に基づき分散サービスに適宜メッセージを分散する機能、アプリケーションおよびプラットフォームポリシーの適用、およびメッセージの内容のセキュリティ機能に用いるものである。メッセージ受け渡し機構は、ユニキャスト（単一宛先）およびマルチキャスト（複数宛先）メッセージ送受信の概念をエミュレートすることができる。プラグイン論理モジュールは、入来または送出メッセージと関連する（このプログラム可能な経路指定は、ＸＭＬ経路指定とすることはできない。ＸＭＬ経路指定およびメッセージ送受信ミドルウェアは、メッセージと件名に基づいて経路を定める。経路指定は、固定された機能であって、プログラム可能ではない場合がある）。メッセージは、ポートと呼ばれる接続点の間で送信される。ポートは、ユニキャストまたはマルチキャストのエンドポイントであってよい。ルータは、入来または送出メッセージフローの方向に基づきこれらのモジュールを段階的に適用することにより受入、送出、および転送トラフィックを制御する。モジュールには数多くの種類がある。共通モジュールタイプは、経路指定、パフォーマンス制御ベース（パフォーマンス測定基準ベース）、構成ベース、セキュリティポリシー、アプリケーションポリシー、およびプロキシ（専用のメッセージ転送機能）などがあるが、これらに限られるわけではない。
【０００７】
ネットワークでは、「モジュール」にまとめられたルールと、推論エンジンを使用してルータをプログラムする。これらの要素は、カーネルの一部であってもよい。ネットワークでは、メッセージ転送、メッセージ命令構文解析、およびメッセージ配信を制御（またはそのルータをプログラム）するアプリケーションおよびシステムロジックにＸＭＬベースのルール言語を使用する。図１は、カーネルの機能を示すブロック図である。ルールを使用すると、ルールベースのルータのプログラム機能に基づくルールを基に２つのコア値を提供することができる。
【０００８】
・ネットワーク内の動的な変更に応答してサービスおよび接続を分配するアプリケーションおよびネットワークの拡張可能な制御。この制御は、アプリケーションプロバイダだけでなくシステム管理者およびネットワークプロバイダにも拡大適用される。
・プロファイリング：ノードごとに格納される、または一カ所に集められるデータとなる、アプリケーション、ユーザ、メッセージタイプ、メッセージソースなどの監視。このデータは、ルールのターゲットとなるイベントにすることができる。これらのルールは、ネットワークとアプリケーションの両方の再構成ロジックを提供できるだけでなく、新しいビジネスモデルに合わせて手直ししたアプリケーションの開発も行うことができる。
【０００９】
１．０  イベントバスアプローチ
Ｏｐｅｎ Ｄｅｓｉｇｎ Ａｐｐｌｉｃａｔｉｏｎｓは（潜在的に）どこでも、つまりＷｉｎｄｏｗｓ（登録商標）でも、Ｕｎｉｘ（登録商標）でも、Ｍａｃｉｎｔｏｓｈでも、Ｐａｌｍ Ｐｉｌｏｔｓでも、インターネット電話でも実行され、実行時に配布されるかまたは配布可能である。
【００１０】
１．１  分散プラットフォーム
Ｏｐｅｎ Ｄｅｓｉｇｎシステムは、ネットワーク上のアプリケーションおよびサービスのホストとなり、管理することができる。システムは、一組のコアインフラストラクチャサービスを実行する接続済みノードのネットワークで構成される。サービスは、単一の名前で複数のノードにまたがることもある。サービスは、管理ドメイン内のノードおよびアプリケーションに対して指定されたポリシー制御の下でネットワーク帯域幅、接続、およびノードリソースを最も効率よく使用できるよう伸縮できる。アプリケーション、およびそれらのアプリケーションと関連するポリシーは一斉に配布されため、アプリケーションに対して定められているポリシーをサービスのホスティングに適用されるトポロジまたはリソースに関係なくそのまま有効にすることができる。ポリシー、およびアプリケーションまたはサービスロジックは両方とも、Ｏｐｅｎ Ｄｅｓｉｇｎ Ｒｕｌｅｓ言語で表され、Ｏｐｅｎ Ｄｅｓｉｇｎ分散プラットフォームにより処理される。
【００１１】
１．１．１  ホスティングおよび管理アプローチ
「高度集中管理」から「分散管理」にわたる分散アプリケーションのホスティングおよび管理を行う方法は次のようにいくつかある。
【００１２】
１）単一マシン−データセンター内の「大型コンピュータ（Ｂｉｇ ｉｒｏｎ）」または小規模な単一ＰＣアプリケーション。
２）クラスタ−密結合のマシンのグループがアプリケーションを実行する。
３）データセンター−集中管理マシンのグループがアプリケーションを実行する。
４）複数のデータセンター−アプリケーションを実行する集中管理データセンターのグループ。
５）分散−独立に管理されているマシンのグループがアプリケーションを実行する。
【００１３】
これらそれぞれついて、「密結合のハードウェア−ソフトウェア」から「粗結合のハードウェア−ソフトウェア」まで各種あり、後者は、実行時、レイヤード、またはＯＳアプローチと呼ばれることが多い。専用アプリケーションは前者であり、基本のハードウェア構成を変更したときには、ソフトウェアも変更する。オペレーティングシステムは後者であり、ソフトウェアは基本ハードウェアの変更の影響を受けず、また基本ハードウェアもソフトウェアの変更の影響を受けない。一般に、単一マシンから分散方式に移行するとランタイムの精巧さが低下する。
【００１４】
１）単一マシン−Ｗｉｎｄｏｗｓ（登録商標）またはＬｉｎｕｘ。
２）クラスタ−ＢＥＡアプリケーションサーバ、ハイエンドのＷｉｎｄｏｗｓ（登録商標）ＮＴ、Ｂｅｏｗｕｌｆ、およびＳｏｌａｒｉｓ
３）データセンター−Ｌｏｕｄｃｌｏｕｄ、Ｊ２ＥＥ、および．ＮＥＴ
４）複数のデータセンター−ＡＳＰがこのモデルに発展する。
５）分散−ＳｕｎのＪｉｎｉやＳｏｎｙのＨＡＶｉ
【００１５】
Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームは、「分散管理」アプローチを使用して、ハードウェアリソースを制御し、「ランタイムまたは粗結合アプローチ」を使用してハードウェア−ソフトウェアを統合するものと言うことができる。
【００１６】
分散管理の利点は次のものを含むことができる。
【００１７】
１）ネットワークの有機的な拡大。ネットワークまたはそのリソースを拡張する承認を中央に求める必要がない。
２）連邦モデル。組織は、複雑な統合作業を行わずに、アプリケーションへのエンリストおよびアンエンリストを実行できる。システムは通常、障害およびセキュリティ問題が存在する中で動作する必要があるため「防御的に」構築される。
３）分散化されたカスタマイズ。アプリケーションに参加する組織は、アプリケーションの担当部分をカスタマイズしたり、自システムと統合したりでき、たとえば、アプリケーション全体に干渉せずに（または中央への承認を必要とせずに）ＥＲＰシステムと統合することができる。現在、一方の当事者の一統合作業はアプリケーション全体に影響を与えたり、あるいは「最小公分母」の承認プロセスで行き詰まってしまう。
【００１８】
ランタイムアプローチの利点は次のものを含むことができる。
【００１９】
１）新しい技術の有機的選択。アプリケーションは抽象化された形で描かれるため、根幹のハードウェアを変更できる。マシンの高速化、マシンの増設、さまざまな接続帯域幅の混在など、アプリケーションを無理やり書き換えなくても可能である。
２）設計モデルが単純になる。ソフトウェアプログラマは、プログラムを作成するのにネットワークアーキテクチャの詳細を知る必要がない。プログラマは、ユーザ名などのソフトウェア概念をフィルタ、ＩＰアドレス、およびポート番号などのネットワーク概念にマッピングすることができる。同様に、ハードウェア設計者は、ハードウェアの機能をアプリケーションオブジェクトにマッピングすることに煩わされなくて済む。設計者はＭＰＬＳタグをユーザ優先度レベルにマッピングすることができる。現在、マッピングはそれぞれソフトウェアまたはハードウェア内で変更が加えられたときにやり直す必要がある。
３）管理がしやすい。通常、企業はアプリケーション開発とハードウェア管理機能とを分離している。現在、Ｂ２Ｂ交換などのネットワークで接続されたアプリケーションは、このようなインターフェースを重視しており、実行中に管理および通信オーバーヘッドを要する。
【００２０】
これらの機能を持たないシステムでは、アプリケーションに対する変更を中央で頻繁に管理する必要があるため、アプリケーションが不安定になり、システムが脆弱になる可能性がある。また、同時配備と中央集中管理されたアプリケーションのコストおよびリスクが高くなるため、提携先にとってあまり魅力的でないものとなる可能性もある。この種のシステムで最も成功した例が、データネットワーキングに使われているインターネットである。
【００２１】
欠点は、分散システムだと複雑さが増し、ランタイムは分散の仕方と信頼性に依存することになるという点である（つまり、ランタイムをアプリケーションが置かれるすべての場所になければならず、また少なくともアプリケーションと同程度には安定していなければならないということである）。
【００２２】
１．１．２  Ｏｐｅｎ Ｄｅｓｉｇｎモジュール
ネットワーク上で分散アプリケーションを制御し管理するためにＯｐｅｎ Ｄｅｓｉｇｎプラットフォームによって提供される制御点は、上記のモジュールクラス群と同じものから導かれる。つまり、経路指定、パフォーマンス（パフォーマンス測定基準ベース）、構成（ロードを、またはシステムポリシーベース）、セキュリティポリシー、アプリケーション、アプリケーションポリシー、およびプロキシ（専用メッセージ転送機能）である。Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームは、一貫性のあるメカニズム、および言語、およびネットワーク上でデータをメッセージとして制御し、抽出し、経路指定し、処理するマルチプラットフォームランタイムを備える。
【００２３】
図２は、アプリケーション配備の一部となりうる５種類のモジュールを表すブロック図である。各モジュールタイプとそれに付随する利点について以下の節で説明する。アプリケーションアダプタ、その機能、およびインターフェースについては、「ルータのアーキテクチャ」の節で説明する。以下で説明するルールタイプ、つまり経路指定、ネットワーク構成、セキュリティ、アプリケーション統合、およびユーザプロファイリングのサンプルコードは、本書の「イベントバス」の節で説明する。
【００２４】
１．１．２．１  分散および経路指定−アプリケーションおよびシステムで用意される経路指定ルール
Ｏｐｅｎ Ｄｅｓｉｇｎ Ｓｙｓｔｅｍは、アプリケーション側でそのサービスの名前を指定するためのアプリケーションネーミングサービスおよびインフラストラクチャを備え、これに基づきアプリケーション要求メッセージをネットワーク全体に送る。ポリシーまたはネットワーク管理ルールによりサービスのパーティション分割および／または複製が行われるときに経路指定の更新が必要になることがある。Ｏｐｅｎ Ｄｅｓｉｇｎインフラストラクチャでは、更新を必要とするネットワーク内のすべてのノードに対して自動経路指定更新、サービス名、および関連経路指定データを供給する。
【００２５】
たとえば、ディレクトリサービス名前空間に対する単一のプログラムで以下のことを行える。
【００２６】
・ディレクトリ名前空間を増大に合わせてパーティション分割する
・ディレクトリ名前空間を複製する
・ディレクトリ名前空間にクエリを実行する
・ディレクトリのホストとなるノードの障害を管理する
【００２７】
これらのメカニズムにより、ネットワークアプリケーションおよびサービスにロケーションおよびリソースを抽象化した方法でアクセスし、サービスクライアントへのサービスを中断することなくロードや障害に対しネットワークで動的に対応すようにできる。この種のモジュールをルートレットと呼ぶ。
【００２８】
１．１．２．２  ネットワークおよび使用ポリシー−アプリケーションおよびシステムで用意される応答モジュール
現在成功している経路指定アルゴリズムは「適応型」または「動的」なアルゴリズムである。これらのアルゴリズムは、故障モードおよびネットワーク内の輻輳に応じてメッセージに対して選ばれた経路を変更する。これらは、スケーリングが非常にうまくゆき、またネットワーク障害も透過的に取り扱えるため、現在最も効果的な経路指定アルゴリズムである。
【００２９】
最も洗練された経路指定プロトコルでは、新しい経路への収束を早める方法と、ライブとデッドロックおよび経路指定のループを回避する方法を重視している。これは重要ではあるが、ルータアルゴリズムを経路指定が行われるアプリケーションに適応させることのほうが有用な場合がある（たとえば、トラフィックがマルチメディアをストリーム化する高い優先度を付けることなどを理解する）。この利点は、理論的には、回線事業者が差別化されたサービスに対する課金、つまり保証帯域幅と低い待ち時間により高い料金を設定することを望むことで得られる。
【００３０】
そのため、最も成長率の高い市場はデータセンター内のネットワークデバイス、またはＷｅｂサーバなどのアプリケーションサービスとインターフェースするネットワークのエッジ近くにあり、そのトラフィックニーズがよく理解される。やがてルータおよびキャッシュはプログラム可能なものが考案され、データセンターの担当者がさまざまな基準に基づきデータトラフィックの形状および優先度を設定できるようになった。この単純な例が、Ｎａｐｓｔｅｒトラフィックがキャンパスネットワークを無力にするのを防止することである。
【００３１】
現代的なルータではますます多くの基準、宛先アドレスとローカル接続だけから数１０個のパラメータまで考慮している。基準が複雑になるにつれ、これらをアプリケーション配備およびアプリケーション管理環境に結合しなければならなくなってきている。ここに、プログラム可能な経路指定が登場するのである。
【００３２】
アプリケーションの詳細を知り、この知識に基づきルータの動作を手直しすることにより、データネットワークの効率を大幅に高められる。
【００３３】
Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームは、一組の接続ノードで構築され、それぞれのノードはＯｐｅｎ Ｄｅｓｉｇｎルールベースのプログラム可能ルータを備える。ノードは、プログラム、データ、接続、およびセッション状態を移動する経路指定アルゴリズムを実行する。これらの経路指定および分配ルール（上述）は、管理者、アプリケーション開発者、およびシステム管理開発者側で用意する。これらのルールのロジックは、アプリケーションおよびメッセージの配布および経路指定に影響を及ぼすだけでなく、ネットワークピアの選択、および接続応答や要求オーバーロードにも影響を及ぼす。ロード、接続要求、ＣＰＵ、またはディスクフル応答に対する応答などのルールは、ネットワーク管理モジュールと呼ばれる。
【００３４】
Ｏｐｅｎ Ｄｅｓｉｇｎ Ｓｙｓｔｅｍは、ネットワーク管理モジュールを作成する際の基準となるＯＳおよびシステムイベントメッセージを備える。Ｏｐｅｎ Ｄｅｓｉｇｎ Ｓｙｓｔｅｍは、アプリケーションシステム側で用意する経路指定基準を使用して経路指定およびサービス分配を手直しし、ハードウェアおよび通信リソースの使用効率を最大限まで高められるプラットフォームを提供する。
【００３５】
１．１．２．３  セキュリティ−アプリケーションおよびシステムで用意するアクセス制御モジュール
Ｏｐｅｎ Ｄｅｓｉｇｎ Ｓｙｓｔｅｍは、プラットフォームおよびサービスの一部にアクセスするためのポリシーを制御するメカニズムを備える。サービス、ＯＳ、またはノード機能にアクセスするためのルールを書いて、指定モジュール、ユーザ、ドメイン、アダプタなどに対するアクセスを禁止したり制限したりするディレクティブを記述することができる。これらのポリシー表現は、アクティベーションが行われる前に、ルール処理の１段階として宛先で評価される。ルールのアクティベーションは、ポリシー表現が失敗した場合には呼び出されない。
【００３６】
ポリシールールは、他のルールタイプのどれかのＬＨＳ（「左側」）に出現する表現である。
【００３７】
１．１．２．４  アプリケーション統合−プロキシおよびサービスレット （ｓｅｒｖｉｃｅｌｅｔ） モジュール
Ｏｐｅｎ Ｄｅｓｉｇｎアプリケーションはモジュールである。モジュールは、名前登録メカニズムを呼び出し、Ｏｐｅｎ Ｄｅｓｉｇｎサービスのイベントバスでイベントのメッセージ照合を行う。つまり、モジュールは実際にはＯｐｅｎ Ｄｅｓｉｇｎプラットフォームによって稼働されるサービスの実装である。要求メッセージを直接処理する、またはＯＳアプリケーションにそれを転送するサービスロジックは、ルールのアクティベーション、つまりＲＨＳとして表現される。
【００３８】
サービスレットとは、サービスのロジックが完全にルールとして表現されていることを示すために使用される名前である。プロキシモジュールとは、要求を処理するため適切なロジックを呼び出す要求をアダプタに転送するモジュールのことである。
【００３９】
１．１．２．５  プロファイリング
ルールエンジンから利用できるプロファイリングデータを使用するアプリケーションを用いれば、興味深いが議論を呼ぶ商機がつかめる。ルールエンジンをルータをプログラムするメカニズムとして使用することにより、この機会を実現できる。ルールアプリケーションから利用できるプロファイリングとしては、ユーザ、アプリケーション、ノード、メッセージ送信元、メッセージ宛先などがある。それぞれのデータ型は、データによって作成されるパターンに応答するルールと合わせて、技術およびビジネスに関する興味深い機会を表す。
【００４０】
ユーザプロファイリングに対するＯｐｅｎ Ｄｅｓｉｇｎ Ｐｌａｔｆｏｒｍの価値は、Ｏｐｅｎ Ｄｅｓｉｇｎ Ａｐｐｌｉｃａｔｉｏｎｓから消費者のイベント履歴およびユーザプロファイルが利用できるようになるという点にある。これを説得力のある環境とするために新しいＯＳアプリケーションをいっさい必要としない。ユーザのブラウザ操作だけで、さまざまな対話操作が可能である。ブラウザで対話操作した結果暗黙のユーザプロファイルが得られるとすればユーザにとって都合のよいことであろう。ユーザが購入する品目、ユーザが訪れるサイト、ユーザが操作を行うことになる回数など、ユーザのマシンのプライバシに基づき格納され分析されるアクションのすべてが、Ｗｅｂをブラウズするときに、さらにカスタマイズされ個人化された経験に役立つ。これに、他のＯＳアプリケーションのもとでユーザアクションが関わることにより、ユーザに関するより大量でより詳細な情報が得られる。
【００４１】
Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームでは、新しいＯＳアプリケーションを作成するのではなくこれら既存のＯＳアプリケーションを活用する。Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームが備えているのは、ＯＳアプリケーション固有のイベントおよびユーザアクションを、分析し詳細なユーザプロファイルにコンパイルできる高水準の抽象化されたＯｐｅｎ Ｄｅｓｉｇｎイベントストリームに変換するためのメカニズムである。プロファイルが詳細になるのに合わせて、ルールを適用し、新しい意味論的アクションを実行させることができる。
【００４２】
１．２  ネットワークトポロジ
Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームは、小規模な配備でも大規模な配備でもインストールすることができるが、その際に既存のハードウェアリソースを使用するか、またはノードの専用構成を追加する。ノード構成には、ホスティング、プロキシ、ルータ、ストレージ、および管理を含めることができる。
【００４３】
図３は、既存のサーバにインストールされているＯｐｅｎ Ｄｅｓｉｇｎプラットフォームの小規模な構成を示すブロック図である。
【００４４】
大規模な配備でインストールされているＯｐｅｎ Ｄｅｓｉｇｎプラットフォームには、既存のサーバにインストールされているソフトウェアと、プロキシ、管理、および大規模な経路指定用の専用サーバ構成が必要になることがある。図４は、可能な大規模な配備構成を表すブロック図である。
【００４５】
Ｄｉｓｔｒｉｂｕｔｅｄ Ｍａｎａｇｅｍｅｎｔ Ｆｒａｍｅｗｏｒｋ（ＤＭＦ）が提供するＯｐｅｎ Ｄｅｓｉｇｎプラットフォームを使用すると、構成、経路指定、ポリシー、およびアプリケーションの各モジュールをＯｐｅｎ Ｄｅｓｉｇｎネットワーク要素に拡大 （ｐｕｓｈ） することができる。これにより、管理ドメイン内で一定の範囲でプログラムを行い、管理することが可能になる。ネットワーク要素にプッシュされたポリシーモジュールでは、Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームに用意されている動的経路指定、負荷分散、アプリケーション配布、およびネットワーク再構成機能を管理者によって指定されている固定フレームワーク内で実行できる。
【００４６】
１．４  モデル言語
Ｏｐｅｎ Ｄｅｓｉｇｎアプリケーションは、大部分が、特定の形式のＸＭＬのチャンクであるルールにより表現される。ルールは、クライアントマシン上のリポジトリを使用しＯｐｅｎ Ｄｅｓｉｇｎプラットフォームにより管理され、Ｏｐｅｎ Ｄｅｓｉｇｎイベントストリーム内の抽象化されたイベントへの応答としてトリガされる。ルールが起動すると、Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームは、これが含むルールセットの過渡的状態を表すチケットを構成する。
【００４７】
ルールとはテキストのチャンクのことである。これらは、比較的読みやすく、編集しやすく、まとめやすい。これらはＸＭＬなので、いろいろな軸をとったときも非常に拡張性が高い。コンパイルは必要なく、またバイナリはビルドされない。同じ目的のルールの集まり、つまりモジュールが、Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームの下で論理アプリケーションを形成する。Ｏｐｅｎ Ｄｅｓｉｇｎアプリケーションまたはサービスを作成したり実行したりするのにコンパイル済みコードがなくてもよい。
【００４８】
Ｏｐｅｎ Ｄｅｓｉｇｎアプリケーションを表すモジュールは、Ｗｅｂページに挿入するためのＤＨＴＭＬを含むＵＩを定義する宣言的構造、既存のＷｅｂページの動作を指定変更するための命令、既存のスクリプト作成可能なアプリケーション、ポリシー、構成、管理、および経路指定規則を制御するためのコマンドを含む。場合によっては、アプリケーション作成者側で、カスタマイズしたＵＩ、新しいアプリケーションロジック、または既存のサードパーティー製レガシアプリケーションのアダプタを用意することができる。この場合、特定のＯＳプラットフォームのバイナリ形式でコードを配信し、既存のＯＳアプリケーションとの対話操作を補完するようにできる。
【００４９】
図５は、配備ツール（「ＤＴ」）との対話操作を示すブロック図である。
【００５０】
図６は、Ｏｐｅｎ Ｄｅｓｉｇｎアプリケーション開発で使用可能な配備要素のいくつかを表すブロック図である。すべてのアプリケーションがすべての要素を必要とするわけではないが、アプリケーションロジックを用意するだけでなく、アプリケーションに対する経路指定、ポリシー、およびきめ細かな分配制御を行えることで、分散環境において高機能、高可用性、高信頼性の豊富なアプリケーションを配備することができる。
【００５１】
２．０  ルータのアーキテクチャ
Ｏｐｅｎ Ｄｅｓｉｇｎアーキテクチャの要素には次のものがある。
【００５２】
・アダプタ
・イベントバス（ａｋａメッセージバス）
・Ｒｅｔｅ型ルールエンジン
・ルールリポジトリ
・ローカルストレージ（ａｋａカーネルツリー）
・モジュール（ルールバンドル）
【００５３】
アダプタは、未処理のアプリケーションイベントを、Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームによって認識される標準形式に変換する要素である。これらはまたアクティベーションをアプリケーション固有のコマンドまたはメッセージに変換する。
【００５４】
イベントバスは、Ｏｐｅｎ Ｄｅｓｉｇｎ形式のメッセージがアプリケーションアダプタを通じて生成されるときにそのＯｐｅｎ Ｄｅｓｉｇｎ形式のメッセージを捕捉する。イベントバスは、ルールから起動されたコマンドを処理し、それらのコマンドをアプリケーションアダプタに送る。
【００５５】
ルールエンジンは、イベント、およびＲｅｔｅネットワーク内のデータ（または事実）に基づいてルールを処理し、新しい事実をそのＲｅｔｅネットワーク内にアサートするか、またはアダプタ固有のアクティベーションによりそれらのイベントに基づきアクションを実行させる。
【００５６】
ルールリポジトリには、ノード上で構成されているルールバンドまたはモジュールの集まりが含まれる。モジュールタイプとしては、デフォルトおよびサイト構成モジュール、経路指定モジュール、およびアプリケーションモジュールがある。
【００５７】
ローカルストレージは、セッションまたは継続的データを格納するためにモジュールからアクセス可能な作業用メモリの一領域である。
【００５８】
モジュールは、ルータを制御するためにルールエンジンによって解釈されるロジックである。モジュールはルールリポジトリ内に常駐する。
【００５９】
図７は、アダプタ、アプリケーション、およびイベントバスの間の通信を示すブロック図である。
【００６０】
２．１  アダプタ
ＯＳアプリケーションは、そのアプリケーションに一意的で固有の未処理（ｒａｗ）イベントを生成し、それぞれのアプリケーションは特定のコマンドセットをサポートすることができる。Ｏｐｅｎ Ｄｅｓｉｇｎアダプタオブジェクトは、それらのイベントおよびコマンドを一般的な用途のために抽象化する手段を提供する。
【００６１】
２．２  アダプタとメッセージ
アダプタは、プロシージャコードがＯｐｅｎ Ｄｅｓｉｇｎイベントバスと（また間接的にＯｐｅｎ Ｄｅｓｉｇｎルールエンジンと）交信するためのオブジェクトである。アダプタを通じて、アプリケーションはメッセージ（イベント）をＯｐｅｎ Ｄｅｓｉｇｎプラットフォームに発行し処理することができる。アダプタは、対応するＯＳアプリケーションに関する情報を持ち、またＯｐｅｎ Ｄｅｓｉｇｎプラットフォームの構造およびスキーマも認識する。したがって、これはＯＳアプリケーションイベントとＯｐｅｎ Ｄｅｓｉｇｎ抽象化イベントとの間のギャップを埋めることができる。
【００６２】
アダプタは数種類の異なる方法で作成できる。１つは、ＯＳアプリケーションに直接組み込み、その際にアダプタコードをアプリケーションの主要コードの一部として書く方法である。この場合、ＯＳアプリケーションの作成者は、アプリケーションの設定および実装時にＯｐｅｎ Ｄｅｓｉｇｎプラットフォームに関する知識を持ち、この変換レイヤを直接コードに組み込む。
【００６３】
もう１つの方法では、アプリケーションが備えている拡張メカニズムを使って既存のＯＳアプリケーション用のアダプタを作成する。場合によっては、アプリケーションに、イベントを検出するための自動化インターフェースが備えられていることもある。あるいは、ある種のＷｉｎｄｏｗｓ（登録商標）アプリケーションの場合、アプリケーションのウィンドウをサブクラス化するか、またはフックして、未処理イベントを取得することができる。Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒを例にとると、プログラマは、ＤＨＴＭＬ ＤＯＭを活用して、注目している未処理イベントを見張るＢｒｏｗｓｅｒ Ｈｅｌｐｅｒ Ｏｂｊｅｃｔを作成することができる。
【００６４】
２．３  アダプタとアクティベーション
アダプタが未処理イベントを抽象化されたＯｐｅｎ Ｄｅｓｉｇｎメッセージに変換する場合とまったく同様に、アダプタはさらにＯｐｅｎ Ｄｅｓｉｇｎのアクティベーションを処理のためアプリケーション固有のコマンドまたはメッセージに変換する。このため、Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームは一般化されたコマンドインターフェースを通じてアプリケーションを呼び出すことができる。これらのアクティベーションは、起動されたルールへの応答として発行されるが、アクティベーションは、ターゲットのＯＳアプリケーションの機能とアクティベーションスキーマを理解しているルール作成者が作成する。
【００６５】
２．４  アダプタおよびアプリケーション毎のスキーマ定義
Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームで管理できるイベントおよびコマンドの集まりはサイズに制限がない。Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームは、特定のイベントまたはコマンドの背後にある意味を特に理解するわけではない。そうではなく、アダプタとＯｐｅｎ Ｄｅｓｉｇｎルールエンジンとの間でそのイベントまたはアクティベーションを移動するトランスポートメカニズムを備える。アダプタ作成者は、ＯＳアプリケーションに固有のイベントスキーマおよびアクティベーションスキーマを定義し、ルール作成者とその知識を共有する。
【００６６】
プラットフォームでは、ルールエンジンとアダプタとの間でイベントおよびアクティベーションを搬送することができる。ルール作成者は、ターゲットとしている特定のアダプタの機能を理解している。ルール作成者が理解しているのは、アダプタで発行できるイベントおよび受け付けられるアクティベーションの種類である。ルール作成者は、それらのイベントに基づいて動作するルールを作成し、アダプタのコマンドセットに基づいてアクティベーションを発行する。ルール作成者は通常、それぞれのアダプタに付属して出荷されたマニュアルからそれらのスキーマについての知識を得る。
【００６７】
アダプタによってそのスキーマが定義される。スキーマはアダプタに固有のものなので、プラットフォームのスキーマ全体は拡張可能である。スキーマを理解するのにエンドポイント（アダプタおよびルール）だけがあればよい。媒介要素、つまりシステム周辺のデータを搬送するプラットフォーム要素は、データの入れ物ラッパーとして使用される。
【００６８】
３．０  Ｏｐｅｎ Ｄｅｓｉｇｎアダプタインターフェース
Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームでは、「アダプタ」という用語は、メッセージバスに接続されているコード断片を表す。アダプタはさまざまな形式をとり、Ｗｅｂページはアダプタをスクリプトの一部として含み、Ｖｉｓｕａｌ Ｂａｓｉｃアプリケーションはアダプタコードを直接実装し、 ＡＳＰページはアダプタを含むといったことが可能である。重要なのは、アダプタがメッセージバスにメッセージを発行するためのコードの断片であるという点である。メッセージは、カーネルによってアダプタに戻すこともできる。
【００６９】
３．１  アダプタの要件
アダプタが満たす要件はごくわずかである。メッセージバスに接続するアダプタはＩＤを持つ。このＩＤは、ＧＵＩＤ文字列として表される。それぞれの異なるアダプタクラスは一意的なＧＵＩＤを持つ。内部では、このＧＵＩＤ（「ｉｄ」）を使って、メッセージをアダプタに送る経路を指定する。メッセージへの応答としてアダプタが実行できるアクションの集まりは、特定のアダプタクラスに固有のものである。
【００７０】
カーネルがメッセージをアダプタに送る経路を指定できるように、アダプタ側でカーネルがメッセージをディスパッチできるオブジェクトモデルを提供する。アダプタによって処理されるメッセージは、アダプタのオブジェクトモデルに基づくメソッドコールである。しかし、このオブジェクトモデルは、アダプタがメッセージを発行するだけの場合には用意する必要はない。
【００７１】
一実施形態では、アダプタを開発するために使用されるプログラミングモデルは、アダプタ作成者の選択に任される。Ｗｉｎ３２上でのＣＯＭオブジェクトの使用をサポートするプログラミング言語を使用してアダプタを作成することができる。このような従来のプログラミング言語としては、Ｃ／Ｃ＋＋、Ｊａｖａ（登録商標）、およびＶｉｓｕａｌ Ｂａｓｉｃ、Ｖｉｓｕａｌ Ｂａｓｉｃ ｆｏｒ Ａｐｐｌｉｃａｔｉｏｎｓなどのマクロ言語、およびＰＥＲＬ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、およびＶＢＳｃｒｉｐｔなどのスクリプト言語がある。
【００７２】
３．２  基本的なアダプタ機能
次のコード断片は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔで書かれた非常に単純な仮説的なアダプタを示している。スクリプト自体は、ＨＴＭＬファイル内で稼働される。
【００７３】
2004520641.tif 000003
【００７４】
このアダプタは、ＨＴＭＬブラウザがページを表示し、メッセージバスに登録するときに必ず自動的に作成する。また、ブラウザが文書をアンロードするときには、アダプタは自動的に登録解除し、終了する。
【００７５】
３．３  アダプタの作成
アダプタを作成するにはまず、アダプタプロキシオブジェクトのインスタンスを作成する。これは、カーネルとアダプタコード自体との間に「居座る」オブジェクトである。
【００７６】
サンプルから取った以下のコード行は、アダプタプロキシの新規インスタンスを作成する。
【００７７】
2004520641.tif 000004
【００７８】
Ｖｉｓｕａｌ Ｂａｓｉｃでは、同じコードは次のようなサンプルコードである。
【００７９】
2004520641.tif 000005
【００８０】
Ｃ＋＋開発者の場合は次のコードを使用する。
【００８１】
2004520641.tif 000006
【００８２】
３．４  カーネルへの接続
カーネルでアダプタを認識できるように、アダプタは自分をカーネルに登録する。この作業は、アダプタプロキシオブジェクト上でＲｅｇｉｓｔｅｒ（）を呼び出すことにより行う。Ｒｅｇｉｓｔｅｒ（）には４つのパラメータがあり、最後の２つはオプションのパラメータである。このコードスニペットは、最後の２つのパラメータを省略するように選択されている。
【００８３】
2004520641.tif 000007
【００８４】
この呼び出しでは、プロキシをカーネルに接続しようとする。最初のパラメータは、適切に構成されているＧＵＩＤで、これにより、このアダプタクラスを一意に識別する。開発者はｇｕｉｄｇｅｎ．ｅｘｅユーティリティを使用して一意的なアダプタＧＵＩＤを作成しなければならない。このパラメータは、カーネルで、アダプタによって生成されるメッセージを識別するためだけでなく、メッセージをアダプタに戻す経路指定するためにも使用される。
【００８５】
Ｒｅｇｉｓｔｅｒの第２のパラメータは、アダプタの人間が読み取れる名前である。このパラメータは便宜上使用されるものであり、ＮＵＬＬであってもよい。
【００８６】
Ｒｅｇｉｓｔｅｒの呼び出しが成功する場合、アダプタはカーネルに接続されている。この時点で、アダプタはメッセージを発行し、着信メッセージを受信する用意ができている。
【００８７】
アダプタがカーネルから切断するには、Ｕｎｒｅｇｉｓｔｅｒを呼び出す。Ｕｎｒｅｇｉｓｔｅｒにはパラメータはないか、アダプタは、ホストプロセスが終了するまでクリーンアップされないメモリリークを避けるために破壊の前にＵｎｒｅｇｉｓｔｅｒを呼び出す。
【００８８】
アダプタがすでにカーネルに接続されており、再度Ｒｅｇｉｓｔｅｒを呼び出そうとすると、Ｒｅｇｉｓｔｅｒはエラーを返す。アダプタが登録されている間、アダプタのＩＤ、名前、アクティベーションインターフェース、または実行オブジェクトテーブル（”ＲＯＴ”）の挙動を変更しようとしても無効である。アダプタはＲｅｇｉｓｔｅｒを２度目に呼び出す前に自分の登録をＵｎｒｅｇｉｓｔｅｒで解除する。
【００８９】
３．５  遅延接続の許可
一実施形態では、カーネルは、カーネルが実行されていない場合でもアダプタを登録するための組み込みメカニズムを有する。Ｒｅｇｉｓｔｅｒへの４番目のパラメータは論理値で、これが真に設定されている場合にこの機能を使用できる。このパラメータを省略した場合、真がデフォルト値となる。
【００９０】
Ｏｐｅｎ ＤｅｓｉｇｎプラットフォームのＷｉｎｄｏｗｓ（登録商標）実装では、実行中オブジェクトテーブルを使用してアダプタの登録を行うが、これは、プログラムで実行中のオブジェクトを「見る」ために使用できる。カーネルが起動されているときに、このテーブルを見て、登録が必要と思われるアダプタを探す。見つかると、カーネルはアダプタへの接続を試み、アダプタがメッセージを送信し、メッセージに応答できるようにする。Ｒｅｇｉｓｔｅｒの４番目のパラメータが真の場合、実行中オブジェクトテーブルにそのアダプタ用のエントリが作成される。パラメータを省略した場合、または偽に設定した場合、ＲＯＴにそのアダプタ用のエントリは作成されない。
【００９１】
ある種の条件によりＲＯＴは破損するが、このような場合、実行中オブジェクトテーブルを通じて列挙を行っている内部カーネルコードは失敗する。このような破損は、ＲＯＴの動作から生じる。このような挙動があると、ＲＯＴの列挙を行えない場合に、Ｏｐｅｎ ＤｅｓｉｇｎカーネルがＲＯＴにすでに登録されているアダプタを見つけない。ＲＯＴの破損の原因と考えられる条件だけで強制的にｏｄｉｋｒｎｌ．ｅｘｅプロセスが終了させられるように見える。
【００９２】
カーネルによる遅延接続を有効にするようアダプタで指定している場合、カーネルが実行中でないときにアダプタが登録することが可能である。カーネルが起動すると、遅延接続を使用できるアダプタを探し、その時にアダプタを接続する。アダプタ作成者は、カーネルが生成するｏｎＣｏｎｎｅｃｔおよびｏｎＤｉｓｃｏｎｎｅｃｔイベントをシンクすることができる。アダプタがＵｎｒｅｇｉｓｔｅｒを呼びだしたときに、アダプタのプロセスが作成されていればカーネルはそのアダプタに接続しようとしなくなる。
【００９３】
３．６  Ｒｅｇｉｓｔｅｒ／Ｕｎｒｅｇｉｓｔｅｒの戻り値
次の表は、アダプタプロキシからの戻り値と、カーネルに関係するアダプタの状態をまとめたものである。
【００９４】
【表１】
2004520641.tif 000008
【００９５】
３．７  メッセージの発行
アダプタは、ＳｅｎｄＭｅｓｓａｇｅというプロキシオブジェクト上で別のメソッドを呼び出すことによりメッセージを発行する。仮想的アダプタＨＴＭＬページのコンテキストで実行される以下のＪａｖａ（登録商標）Ｓｃｒｉｐｔは、パラメータなしで「ｈｅｌｌｏ ｗｏｒｌｄ」タイプのメッセージを発行する。
【００９６】
2004520641.tif 000009
【００９７】
Ｖｉｓｕａｌ Ｂａｓｉｃでは次のようになる。
【００９８】
2004520641.tif 000010
【００９９】
Ｃ＋＋では次のようになる。
【０１００】
2004520641.tif 000011
【０１０１】
ＳｅｎｄＭｅｓｓａｇｅが呼び出されたときにアダプタがカーネルに接続されていない場合、ＳｅｎｄＭｅｓｓａｇｅはエラーを返す。
【０１０２】
３．８  メッセージのパラメータ
多数のアダプタが、発行するメッセージとともに一組のパラメータを送る。一実施形態では、メッセージパラメータオブジェクト（ＭｓｇＰａｒａｍｓ）を使用してこれを実行する。ＭｓｇＰａｒａｍｓオブジェクトは、ルールの中で基準として使用できるパラメータを渡すのに使用される別のカーネルオブジェクトである。ＭｓｇＰａｒａｍｓは配列オブジェクトである。これは、ＨＴＭＬページアダプタはパラメータ化されたイベントを発行するために使用する単純な機能である。
【０１０３】
2004520641.tif 000012
【０１０４】
カーネルはさらに、ＭｓｇＰａｒａｍｓオブジェクトをネストできるようにすることにより構造化パラメータをサポートする。つまり、アダプタ作成者はパラメータの任意の構造を構築して、ルール内にマッピングできるということである。たとえば、以下のとおりである。
【０１０５】
2004520641.tif 000013
【０１０６】
３．９  メッセージの受信
プラットフォーム内のアダプタは、イベント（メッセージ）バス上のメッセージの論理「エンドポイント」である。メッセージは、接続時にメッセージリスナーを登録したアダプタを宛先とすることができる。以下は、メッセージリスナーを示している。
【０１０７】
2004520641.tif 000014
【０１０８】
これらはＪａｖａ（登録商標）Ｓｃｒｉｐｔの関数プロトタイプである。カーネルがアクティベーションをアダプタにディスパッチできるように、Ｒｅｇｉｓｔｅｒ（）の呼び出し時にアダプタ側でオブジェクトモデルを登録する。以下は、サンプルＷｅｂページでどのようにこれが実行されるかを示している。
【０１０９】
2004520641.tif 000015
2004520641.tif 000016
【０１１０】
このアダプタが登録すると、カーネルはメッセージ「ａｄｄＳｏｍｅＴｅｘｔ（’ｈｅｙ ｔｈｅｒｅ ｆｒｏｍ ｔｈｅ ｋｅｒｎｅｌ’）；」を発行してテキストをページに付加したり、メッセージ”ｓａｙＨｅｌｌｏ（）”を発行してｈｅｌｌｏを送ることができる。
【０１１１】
アダプタによって提供されるオブジェクトモデルはアダプタ内の既存のオブジェクトと関連付けられるため、ＨＴＭＬページでは、ドキュメントオブジェクトモデルをアクティベーションインターフェースとして登録し、ＤＨＴＭＬページの完全な制御をメッセージバスに結合することができる。Ｖｉｓｕａｌ Ｂａｓｉｃアプリケーションの場合は、アクティベーションインターフェースとしての形式でステータスバーまたは通知ラベルに表示できる。開発者の選択したプログラミング環境でオートメーション（ＩＤｉｓｐａｔｃｈ）に使用可能なオブジェクトをアクティベーションインターフェースとして登録することができる。
【０１１２】
一実施形態では、カーネルはｐｒｏｐｅｒｔｙ−ｇｅｔメッセージリスナーをサポートしていないが、ｐｒｏｐｅｒｔｙ−ｐｕｔとメソッドの両方をサポートしている。
【０１１３】
３．１０  アダプタが接続されているかどうかの判別
一実施形態では、カーネルプロセス、したがってイベントバスは、いつでも停止することができるため、アダプタ作成者は（メッセージ）バスさえ使用可能であると安全に仮定することはできない。アダプタプロキシオブジェクトは、メッセージバスに接続したときに真を返すＡｄａｐｔｅｒＩｓＣｏｎｎｅｃｔｅｄと呼ばれるプロパティをサポートしている。
【０１１４】
2004520641.tif 000017
【０１１５】
ＳｅｎｄＭｅｓｓａｇｅで発生するエラーを捕捉する言語のエラー処理機能を使用する方法もある。
【０１１６】
2004520641.tif 000018
【０１１７】
アダプタ作成者は、特定のアダプタの要件に適合するエラー処理構造を使用することができる。
【０１１８】
３．１１  アダプタプロキシイベントの受信
アダプタプロキシでは、メッセージバスが使用可能になったときと使用不可能になったときにアダプタ作成者側で通知を受け取るようにトラップできる２つのイベントをサポートしている。これら２つのイベントはＯｎＣｏｎｎｅｃｔおよびＯｎＤｉｓｃｏｎｎｅｃｔと呼ばれるものである。
【０１１９】
ＯｎＣｏｎｎｅｃｔは、メッセージバスが使用可能になったときにプロキシによって起動される。同様に、ＯｎＤｉｓｃｏｎｎｅｃｔは、メッセージバスが使用不可能になったときにプロキシによって起動される。これらのイベントは、Ｗｉｎｄｏｗｓ（登録商標）上にＣＯＭ接続点として実装されているため、これはＶｉｓｕａｌ Ｂａｓｉｃでイベントを「ｃａｔｃｈ」する例となっている。
【０１２０】
2004520641.tif 000019
【０１２１】
アダプタが多数の大きなメッセージを送信したり、重い処理のスレッドプールを実装する場合、アダプタ作成者側でこのイベントを使用してリソースの割り当てを管理することができる。
【０１２２】
３．１２  アクティベーションメッセージの処理
プラットフォーム言語では、カーネルからアダプタに送られるメッセージをアクティベーションと呼ぶ。アクティベーションはルールエンジン内でルールを起動することによりカーネルからアダプタにディスパッチされるため、アクティベーションメッセージに詳細情報が関連付けられ、これを使ってアダプタはイベント（メッセージ）バス内で機能を拡張できる。この付加情報をアクティベーションコンテキストと呼ぶ。
【０１２３】
アダプタはアクティベーションコンテキストを使用して、モジュールルール内で宣言されているアプリケーションデータ、アクティベーションを引き起こしたメッセージ内のデータ、およびアクティベーションを引き起こしたモジュールに関する情報にアクセスすることができる。
【０１２４】
３．１２．１  アクティベーションコンテキストオブジェクト
アダプタプロキシオブジェクトは、アクティベーションコンテキストをＡｃｔｉｖＣｔｘと呼ばれるプロパティを通じてアダプタホストに公開する。アクティベーションコンテキストオブジェクトモデルとそこに含まれるデータを説明するために、アクティベーションメソッドの以下のスケルトンを考察する。
【０１２５】
2004520641.tif 000020
【０１２６】
アクティベーションコンテキストオブジェクトは、アクティベーションメソッドの呼び出しが行われる間中有効である。上の例では、アクティベーションメソッドが終了すると、コンテキストオブジェクトがＪａｖａ（登録商標）Ｓｃｒｉｐｔランタイムによりクリーンアップされる。また、ホストがＡｃｔｉｖＣｔｘを呼び出したときにアダプタプロキシが現在アクティベーションを処理していない場合、エラーが返される。
【０１２７】
アダプタ作成者は、必要ならばアクティベーションコンテキストへの参照をメモリ内に保持するようにできる。アクティベーション毎に、新規アクティベーションコンテキストオブジェクトが作成され、そのため、アダプタがアクティベーションコンテキストへの参照メモリ内に保持している場合、キャッシュされているアクティベーションコンテキスト内のデータは新規アクティベーションがカーネルからディスパッチされたときに変更されない。
【０１２８】
コンテキストが有効であれば、アダプタはアクティベーションを引き起こしたモジュールのＩＤを表示することができる。
【０１２９】
2004520641.tif 000021
【０１３０】
または、モジュールのリソースのパスを表示する。
【０１３１】
2004520641.tif 000022
【０１３２】
ルールの一部として宣言されているデータ値を使用するには、Ｄｅｃｌｓコレクションをアクティベーションコンテキストオブジェクト上で使用する。
【０１３３】
2004520641.tif 000023
【０１３４】
Ｄｅｃｌｓオブジェクトは標準コレクションなので、ｆｏｒ．．ｅａｃｈループ内で列挙をサポートする。以下に例を示す。
【０１３５】
2004520641.tif 000024
【０１３６】
アクティベーションコンテキストはさらに、アクティベーションを引き起こすためにカーネル内でルールにより照合されたメッセージのすべてのフィールドを公開する。これにより、アダプタ作成者はイベントデータを「覗く （ｐｅｅｒ） 」ことができる。
【０１３７】
３．１２．２  カーネルがアクティベーションを処理しているかどうかの判別
アプリケーションと直接統合されるコードとして存在するアダプタもある。このような状況では、カーネルがアダプタコード上で呼び出し側を呼び出しているかどうかをプログラムで判別すると便利である。
【０１３８】
アダプタは、ユーザ側では閉じられず、カーネルからのみ閉じることができるウィンドウとして実装することも可能である。アダプタがこのメッセージを処理するのにユーザ対話操作で生成されたｏｎＣｌｏｓｅイベントを処理するのと同じ機能を使用する場合、アクティベーションメッセージを処理しているかどうかを通知する必要がある。そのためには、アダプタコードにより、ＰｒｏｃｅｓｓｉｎｇＡｃｔｉｖａｔｉｏｎと呼ばれるアダプタプロキシオブジェクトについて別のプロパティを問い合わせることができる。
【０１３９】
2004520641.tif 000025
【０１４０】
３．１２．３  モジュールメッセージ
メッセージから新しくメッセージを生成できるアダプタもある。たとえば、スクリプトホストアダプタは、ＳｅｎｄＭｅｓｓａｇｅと呼ばれるアクティベーションメソッドを公開することができる。
【０１４１】
2004520641.tif 000026
【０１４２】
アクティベーションでメッセージを発行させるようにすることで、ある種のアクティベーションでアダプタがメッセージに使用するのと同じメッセージタイプを使用できる可能性がある。これは、カーネルモジュールのコンテキストで第２のメッセージが生成される場合である。「派生」メッセージがアダプタを呼び出すモジュールの代わりに発行されるこのような場合、ＳｅｎｄＭｅｓｓａｇｅを使用する代わりに、アダプタはＳｅｎｄＭｏｄｕｌｅＭｅｓｓａｇｅと呼ばれるプロキシで別のメソッドを呼び出すことができる。
【０１４３】
2004520641.tif 000027
【０１４４】
モジュールメッセージは、他のメッセージのように「見える」。唯一の違いは、ＳｅｎｄＭｏｄｕｌｅＭｅｓｓａｇｅから発行されたメッセージはアダプタのＩＤの代わりにメッセージ送信元としてアクティブ化するモジュールのＩＤを持つという点である。ＳｅｎｄＭｅｓｓａｇｅおよびＳｅｎｄＭｏｄｕｌｅＭｅｓｓａｇｅは同じシグネチャを持つ、つまり、アダプタは非モジュールメッセージにＳｅｎｄＭｅｓｓａｇｅを使用する場合と同様にパラメータとともにモジュールメッセージを送信することができるということである。
【０１４５】
ＳｅｎｄＭｏｄｕｌｅＭｅｓｓａｇｅにはオプションの第３のパラメータがあり、これにより、生成されたメッセージ内で使用するモジュールＩＤを指定することができる。これは、アダプタが、たとえば、非同期に処理するアクティベーションをキューに入れる場合に役立つ。アクティベーションの処理の準備が整ったら、アダプタは指定されている第３のパラメータでＳｅｎｄＭｏｄｕｌｅＭｅｓｓａｇｅの呼び出しを行うことができる。
【０１４６】
2004520641.tif 000028
【０１４７】
アクティベーションのコンテキストの外部でＳｅｎｄＭｏｄｕｌｅＭｅｓｓａｇｅを呼び出し、モジュールＩＤを指定していないと、エラーが返される。
【０１４８】
３．１３  チャネルメッセージ
一実施形態では、チャネルメッセージにより制約モジュール間通信が可能になっている。チャネルを確立するモジュールのみがイベントバス上に出ているチャネルメッセージを「見られる」というのが制約であり、アダプタプロキシはＳｅｎｄＣｈａｎｎｅｌＭｅｓｓａｇｅメソッドをサポートする。アダプタはこのメソッドを使用して、メッセージチャネル経由でメッセージを発行することができる。
【０１４９】
３．１４  要求−応答メッセージ
一実施形態では、アダプタプロキシは要求−応答メッセージをサポートする。要求−応答は、特定のメッセージクラスが発行され（ＭＣ＿ＲＥＱＵＥＳＴ）、応答が期待されるメッセージ交換パターンである。所定の要求と合致するルールのみがそれらの要求に対する応答を捕捉するように、カーネル側は要求−応答ルールを備えている。要求メッセージは、ＳｅｎｄＲｅｑｕｅｓｔＭｅｓｓａｇｅアダプタプロキシメソッドを使用して発行することができる。同様に、応答メッセージは、ＳｅｎｄＲｅｓｐｏｎｓｅＭｅｓｓａｇｅメソッドを使用して発行することができる。
【０１５０】
これは、メッセージ相関ｉｄの格納と照合により動作する。システム内で生成される各メッセージは、それ専用のほぼ一意のｉｄを持つ。応答メッセージと所定の要求とを照合するために、メッセージの応答ＩＤフィールドに要求メッセージの相関ｉｄを与える。アダプタプロキシは、アクティベーションの処理中にＳｅｎｄＲｅｓｐｏｎｓｅＭｅｓｓａｇｅが呼び出されると必ずこれを自動的に実行する。アダプタがアクティベーションを処理していない場合、またはアダプタが応答ｉｄを別の要求メッセージのｉｄで指定変更 （ｏｖｅｒｒｉｄｅ） する場合、これを実行するためにＳｅｎｄＲｅｓｐｏｎｓｅＭｅｓｓａｇｅでオプションのパラメータを使用することができる。
【０１５１】
３．１５  アダプタドライバ
アダプタドライバは、カーネルモジュール、つまりノードメッセージをアダプタに送る経路を指定するルールファイルである。一般に、アプリケーション作成者がアダプタとの通信を行いたい場合、直接アダプタにメッセージを発行することをしない。そうする代わりに、ドライバによって定義された論理プログラミングインターフェースにしたがってメッセージを発行する。
【０１５２】
この関係の良い例が、内部カーネルファイルシステムアダプタとファイルコマンドＡＰＩである。ファイルシステムアダプタは、ディスク操作を実行するカーネル内の組み込みアダプタコードの低レベルな要素である。これは、ファイルおよびフォルダの移動、コピー、ファイルの検索などを実行する。しかし、一般にアプリケーションはファイルアダプタと通信しない。これらは、ＡＰＩ要求を変換する経路指定ルールを実装するカーネルサービスと突き合わせてメッセージを発行する。
【０１５３】
2004520641.tif 000029
【０１５４】
この呼び出しにより、ファイルアダプタアクティベーションが起動する。ファイルシステムアダプタの例の経路指定は単純ではあるが、ドライバでさらに詳細な経路指定ルールを実装することができる。このようなドライバは、電子メールのキューアダプタや支払取引アダプタなどの、複雑なアダプタに必要になることがある。またドライバを使用することで、アダプタはＡＰＩのバージョニングを行ったり、さらにはコンパイル済みのアダプタコードを変更せずに機能をインクリメンタルに追加することもできる。
【０１５５】
３．１６  アダプタインスタンスの処理
アダプタクラスは、ＩＤによって互いに区別される。同じアダプタの重複するインスタンスは、実行時登録のｃｏｏｋｉｅとカーネル接続時のアダプタインスタンスＩＤによって互いに区別される。カーネルは、モジュール作成者（およびアダプタドライバ作成者）が特定のアダプタインスタンスの追跡に使用する「ＡｄａｐｔｅｒＲｅｇｉｓｔｅｒｅｄ」と呼ばれるメッセージを登録後発行する。
【０１５６】
カーネルで発行されたすべてのアダプタメッセージは、送信元および送信元インスタンス「ｃｏｏｋｉｅ」が割り当てられる。メッセージ送信元は、アダプタＩＤまたはモジュールＩＤ（モジュールイベントの）であり、送信元ｃｏｏｋｉｅは上述の登録インスタンス値に設定される。
【０１５７】
アダプタプロキシは、カーネルに登録するときにアダプタの送信元インスタンス値を決定するために呼び出すことができる読み取り専用プロパティ「ＳｒｃＩｎｓｔａｎｃｅ」をサポートしている。これは次のように使用する。
【０１５８】
2004520641.tif 000030
【０１５９】
カーネルがイベント送信元と同じＩＤを持つアダプタに対してアクティベートしている場合、カーネルは自動的に、元のメッセージを発行したアダプタのインスタンスへのアクティベーションに対して経路を指定する。カーネルが元メッセージを引き起こしたアダプタでないアダプタに対してアクティベートしている場合、カーネルはアクティベーションをその特定のＩＤで登録されている最初のアダプタに送る。
【０１６０】
モジュール作成者は、ルール内のアクティベーションの一部として送信先ｃｏｏｋｉｅを指定することによりその動作を指定変更できる。実行時までインスタンスｃｏｏｋｉｅはわからないため、モジュール作成者は使用するインスタンスｃｏｏｋｉｅを決定することができる。モジュールは、送信元ｃｏｏｋｉｅをツリーノードにキャッシュすることによりメッセージ交換に現在参加しているアダプタに対するアダプタｃｏｏｋｉｅを識別することができる。一般に、モジュール作成者がカスタムインスタンス処理を実装する必要はないが、特別な環境に対してこの機能を利用することができる。
【０１６１】
３．１７  カーネル管理アダプタ
一実施形態では、いくつかのアダプタをルールにロードし、アンロードすることができる。これは、カーネルアクティベーションＬｏａｄＡｄａｐｔｅｒおよびＵｎｌｏａｄＡｄａｐｔｅｒを通じてサポートする。アダプタがこの機能を実装するため、ＩＡｄａｐｔｅｒＣｏｎｔｒｏｌインターフェースをサポートしている。アダプタ制御インターフェースは、ＳｔａｒｔｕｐとＳｈｕｔｄｏｗｎという２つのメンバメソッドを用意している。
【０１６２】
カーネルがＬｏａｄＡｄａｐｔｅｒを使用してアダプタをロードすると、新規アダプタ制御が作成され、パラメータとしてアダプタのＣＬＳＩＤ（ｇｕｉｄ）またはＰｒｏｇＩＤで渡す。次に、プロセスは、Ｗｉｎｄｏｗｓ（登録商標）上で、標準ＣＯＭ ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ呼び出しを使用してアダプタを作成しようとする。この呼び出しが成功すると、プロセスは次に、新規作成したオブジェクでＩＡｄａｐｔｅｒＣｏｎｔｒｏｌ：：Ｓｔａｒｔｕｐを呼び出す。このときに、アダプタは自らをカーネルに登録する。同様に、ＵｎｌｏａｄＡｄａｐｔｅｒアクティベーションが呼ばれると、カーネルはオブジェクトでＩＡｄａｐｔｅｒＣｏｎｔｒｏｌ：：Ｓｈｕｔｄｏｗｎを呼び出す。そこでプロセスは終了する。一般に、ＩＡｄａｐｔｅｒＣｏｎｔｒｏｌを使用してアダプタを実装することは通常は、必要ない。
【０１６３】
３．１８  アダプタプロキシＡＰＩ
このセクションでは、一実施形態でアダプタプロキシにより公開されている各メソッドおよびプロパティについて説明する。このセクションでは、ＩＤＬファイルから直接取り出したある形式のメソッドおよびプロパティを使用する。Ｃ＋＋でない場合、ＩＤＬ構文の以下の説明は、後述のＡＰＩの解釈に役立つであろう。
【０１６４】
まず、インターフェース呼び出しでＨＲＥＳＵＬＴが返される。これは、Ｃ＋＋ Ｗｉｎｄｏｗｓ（登録商標）ＣＯＭ開発者にはなじみのものであるが、ＶＢやスクリプトの開発者にとってはなじみのあるものではない。ＶＢまたはスクリプトを使用する場合、実行時例外でのＨＲＥＳＵＬＴ不成功結果は Ｊａｖａ（登録商標）Ｓｃｒｉｐｔではｔｒｙ／ｃａｔｃｈで、ＶＢではＯｎ Ｅｒｒｏｒ．．でトラップすることができる。呼び出しが成功すると、実行時例外はスローされない。ここで［ｉｎ］とリストされているパラメータは、入力パラメータであることを意味している。［ｏｕｔ］でリストされているパラメータは、出力パラメータを表す。いくつかのｐｒｏｐｅｒｔｙ−ｇｅｔメソッドには、［ｏｕｔ， ｒｅｔｖａｌ］パラメータがある。これらのパラメータは、ＶＢまたはスクリプトからの呼び出しの戻り値となる。いくつかのパラメータは［ｏｐｔｉｏｎａｌ］で示される。つまり、呼び出しでパラメータを省略できるということである。他のパラメータは、［ｄｅｆａｕｌｔｖａｌｕｅ（．．．）］とリストされる。省略された場合、これらのパラメータは、呼び出しの中で括弧で囲まれているデフォルト値を取る。最後に、スクリプトとＶＢでは、時間変数のほとんどはＶＡＲＩＡＮＴ型である。つまり、変数は、有効なオブジェクトポインタ、整数値、文字列などとすることができる。通常は、変数が間違った型の場合にＣＯＭは値を変換する。ときには、型を変換できない場合もあり、そうすると、不成功ＨＲＥＳＵＬＴがスローされる（実行時エラーが発生する）。
【０１６５】
３．１８．１  ＩＡｄａｐｔｅｒ
ＩＡｄａｐｔｅｒは、アダプタプロキシオブジェクトのインターフェースである。これは、アダプタからメッセージメソッドの送信をサポートする。
【０１６６】
メソッド
2004520641.tif 000031
【０１６７】
このメソッドは、アダプタをカーネルに登録する。アダプタのＩＤは文字列として設定されているＧＵＩＤである。Ｗｉｎｄｏｗｓ（登録商標）Ｇｕｉｄｇｅｎ．ｅｘｅまたはｕｕｉｄｇｅｎ．ｅｘｅを使用して、新規ＧＵＩＤを作成できる。第２のパラメータは、アダプタの人間が読み取れる名前である。このパラメータは、人間が読み取れるアダプタ名に対してのみアドレス指定に使用される。ＮＵＬＬであってもよい。第３のパラメータは、アダプタのオプションのアクティベーションインターフェースである。これもＮＵＬＬであってよい。アクティベーションインターフェースは、ＩＤｉｓｐａｔｃｈ−ＶＢオブジェクトおよびＪａｖａ（登録商標）Ｓｃｒｉｐｔオブジェクトをサポートし、両方ともＩＤｉｓｐａｔｃｈを使用できる。最後のパラメータは、アダプタ側で遅延接続を望んでいるかどうかを記述する真／偽のバリアント型である。
【０１６８】
2004520641.tif 000032
【０１６９】
このメソッドは、アダプタをカーネルから切断する。
【０１７０】
2004520641.tif 000033
【０１７１】
このメソッドは、ブロードキャストメッセージを送信する。メッセージの種類が第１のパラメータ（文字列）であり、メッセージパラメータオブジェクト（「ＩＭｓｇＰａｒａｍｓ」を参照）はオプションの第２のオブジェクトとして渡すことができる。
【０１７２】
2004520641.tif 000034
【０１７３】
このメソッドは、モジュールメッセージを送信する。メッセージの種類が第１のパラメータ（文字列）であり、メッセージパラメータオブジェクトはオプションの第２の引数として渡すことができる。この最後の引数は、モジュールメッセージのターゲットへのモジュールのインスタンスｉｄである。アクティベーションの処理中にＳｅｎｄＭｏｄｕｌｅＭｅｓｓａｇｅを呼び出す場合、このパラメータは省略することができる。アダプタプロキシは、自動的に、この場合にはアクティベーションコンテキストからのモジュールｉｄを使用する。アクティベーションの処理の外側で呼び出された場合、インスタンスｉｄパラメータを指定するコードができる。
【０１７４】
2004520641.tif 000035
【０１７５】
このメソッドは、ブロードキャストメッセージを送信する。このメソッドはＳｅｎｄＭｅｓｓａｇｅと同じであるが、生成されたメッセージの相関ＩＤが呼び出し側に戻されるだけである。
【０１７６】
2004520641.tif 000036
【０１７７】
このメソッドは、要求メッセージを送信する。メッセージの種類が第１のパラメータ（文字列）であり、メッセージパラメータオブジェクトはオプションの第２の引数として渡すことができる。
【０１７８】
2004520641.tif 000037
【０１７９】
このメソッドは、応答メッセージを送信する。メッセージの種類が第１のパラメータ（文字列）であり、メッセージパラメータオブジェクトはオプションの第２の引数として渡すことができる。最後の引数は、生成されるメッセージの応答ＩＤである。アクティベーションの処理中にＳｅｎｄＲｅｓｐｏｎｓｅＭｅｓｓａｇｅを呼び出す場合、このパラメータは省略することができる。アダプタプロキシは、自動的に、この場合にはアクティベーションコンテキスト内のメッセージからの相関ＩＤを使用する。アクティベーションの処理の外側で呼び出された場合、応答ＩＤパラメータを指定するコードができる。
【０１８０】
2004520641.tif 000038
【０１８１】
このメソッドは、チャネルメッセージを送信する。ターゲットのモジュールのインスタンスＩＤが、最初のパラメータである。第２のパラメータ（文字列）は、メッセージが発行されるチャネル名である。第３のパラメータは、発行するメッセージの種類であり、最後のパラメータは、オプションのメッセージパラメータオブジェクトである。
【０１８２】
プロパティの取得
【０１８３】
2004520641.tif 000039
【０１８４】
このメソッドは、アダプタがカーネルに接続されている場合に真を返し、アダプタがカーネルに接続されていない場合に偽を返す。
【０１８５】
2004520641.tif 000040
【０１８６】
このメソッドは、アダプタがアクティベーションを処理している場合に真を返し、アダプタがアクティベーションを処理していない場合に偽を返す。
【０１８７】
2004520641.tif 000041
【０１８８】
このメソッドは、現在のアクティベーションに対するアクティベーションコンテキストを返す。アダプタがアクティベーションを処理していないときに呼び出されると、実行時エラーが発生する。
【０１８９】
2004520641.tif 000042
【０１９０】
アダプタの送信元インスタンスを返す（「アダプタインスタンスの処理」を参照）。
【０１９１】
３．１８．２  ＩＡｄａｐｔｅｒＣｏｎｔｒｏｌ
アダプタ制御インターフェースを使用することで、カーネルはカーネルＬｏａｄＡｄａｐｔｅｒおよびＵｎｌｏａｄＡｄａｐｔｅｒを使用してアダプタの寿命を管理することができる。
【０１９２】
メソッド
2004520641.tif 000043
【０１９３】
アダプタプロセスが作成されると必ず、カーネルはＳｔａｒｔｕｐを呼び出す。アダプタでのＳｔａｒｔｕｐの実装では、アダプタをカーネルに登録するには、Ｒｅｇｉｓｔｅｒを呼び出す必要がある。
【０１９４】
2004520641.tif 000044
【０１９５】
アダプタプロセスを終了する場合、カーネルはＳｈｕｔｄｏｗｎを呼び出す。アダプタでのＳｈｕｔｄｏｗｎの実装では、アダプタをカーネルから登録解除するには、Ｕｎｒｅｇｉｓｔｅｒを呼び出す必要がある。
【０１９６】
３．１８．３  ＩＭｓｇＰａｒａｍｓ
ＩＭｓｇＰａｒａｍｓは、メッセージパラメータオブジェクトにより公開されるインターフェースである。メッセージパラメータオブジェクトは、メッセージに接続されたパラメータの集まりである。アダプタでは、メッセージパラメータオブジェクトを使用し、ＳｅｎｄＭｅｓｓａｇｅを通じてメッセージをパラメータ付きでカーネルに発行し、アクティベーションを処理するときにはアクティベーションコンテキストを通じてメッセージパラメータにアクセスする。
【０１９７】
メソッド
2004520641.tif 000045
【０１９８】
このメソッドは、メッセージパラメータオブジェクトを初期化する。オプションのサイズを単独のパラメータとして渡すこともできる。メッセージパラメータオブジェクトを使用するのに、ｉｎｉｔｉａｌｉｚｅを呼び出さなくてもよい。
【０１９９】
2004520641.tif 000046
【０２００】
このメソッドは、メッセージパラメータオブジェクトをクリアし、すべてのパラメータを解放する。パラメータのカウントを０に設定する。このメソッドは、複数のＳｅｎｄＭｅｓｓａｇｅ呼び出しで同じメッセージパラメータオブジェクトを使用する場合に使用する。
【０２０１】
プロパティの取得
【０２０２】
2004520641.tif 000047
【０２０３】
このメソッドは、メッセージパラメータオブジェクトのパラメータの個数を返す。
【０２０４】
2004520641.tif 000048
【０２０５】
このメソッドは、所定のインデックスに対応するパラメータ値を返す。最初のパラメータは、返すパラメータの０から始まるインデックスである。
【０２０６】
プロパティの書き出し （ｐｕｔ）
【０２０７】
2004520641.tif 000049
【０２０８】
このメソッドは、パラメータ値をパラメータオブジェクトに割り当てる。最初のパラメータは、設定するパラメータの０から始まるインデックスである。
【０２０９】
３．１８．４  ＩＡｃｔｉｖＣｔｘ
アクティベーションコンテキストは、現在のアクティベーションと関連するメタデータをアダプタに供給するオブジェクトである。アクティベーションコンテキストオブジェクトモデルは、アクティベーションを発生させたモジュール、アクティベーションを発生させたメッセージ、アクティベーションを起動したルール内のセッション宣言、アクティベーションを起動したルール内の永続的宣言を判別するためのフックを備えている。
【０２１０】
プロパティの取得
2004520641.tif 000050
【０２１１】
このメソッドは、アクティベーションのモジュールオブジェクトを返す。
【０２１２】
2004520641.tif 000051
【０２１３】
このメソッドは、アクティベーションのメッセージオブジェクトを返す。
【０２１４】
2004520641.tif 000052
【０２１５】
このメソッドは、アクティベーションに対するルール内のセッション宣言を返す。
【０２１６】
2004520641.tif 000053
【０２１７】
このメソッドは、アクティベーションに対するルール内の永続的宣言を返す。
【０２１８】
３．１８．５  ＩＭｏｄｕｌｅ
モジュールインターフェースは、アクティベーションコンテキストの子の１つである。モジュールインターフェースは、アクティベーションを発生させたモジュールに関する情報を出力する。
【０２１９】
プロパティの取得
2004520641.tif 000054
【０２２０】
このメソッドは、モジュールのＧＵＩＤ（文字列）を返す。アクティベーションではサポートされていない。
【０２２１】
2004520641.tif 000055
【０２２２】
このメソッドは、モジュールの名前を返す。アクティベーションではサポートされていない。
【０２２３】
2004520641.tif 000056
【０２２４】
このメソッドは、モジュールの説明を返す。アクティベーションではサポートされていない。
【０２２５】
2004520641.tif 000057
【０２２６】
このメソッドは、モジュールのファイル名を返す。アクティベーションではサポートされていない。
【０２２７】
2004520641.tif 000058
【０２２８】
このメソッドは、モジュールのモジュールパスを返す。
【０２２９】
2004520641.tif 000059
【０２３０】
このメソッドは、モジュールのリングレベルを返す。アクティベーションではサポートされていない。
【０２３１】
2004520641.tif 000060
【０２３２】
このメソッドは、アクティベーションを引き起こしたモジュールのインスタンスＩＤを返す。
【０２３３】
2004520641.tif 000061
【０２３４】
このメソッドは、モジュールがライブラリの場合に真を返し、そうでない場合に偽を返す。アクティベーションではサポートされていない。
【０２３５】
３．１８．６  ＩＭｓｇ
メッセージインターフェースは、アクティベーションコンテキストを通じてアクティベーションを生成したメッセージを公開する。
【０２３６】
プロパティの取得
2004520641.tif 000062
【０２３７】
このメソッドは、メッセージを生成したアダプタの送信元を返す。
【０２３８】
2004520641.tif 000063
【０２３９】
このメソッドは、メッセージが作成された日時を返す（ｌｏｃａｌ ｔｉｍｅｚｏｎｅ）。
【０２４０】
2004520641.tif 000064
【０２４１】
このメソッドは、メッセージを生成したアダプタの送信元インスタンスを返す。
【０２４２】
2004520641.tif 000065
【０２４３】
このメソッドは、メッセージの種類を返す。
【０２４４】
2004520641.tif 000066
【０２４５】
このメソッドは、メッセージの相関ｉｄを返す。
【０２４６】
2004520641.tif 000067
【０２４７】
このメソッドは、メッセージのモジュールｉｄを返す。これは、クラス値がＭＣ＿ＭＯＤＵＬＥまたはＭＣ＿ＣＨＡＮＮＥＬのメッセージの場合のみ有効である。
【０２４８】
2004520641.tif 000068
【０２４９】
このメソッドは、メッセージの応答ｉｄを返す。これは、クラス値がＭＣ＿ＲＥＳＰＯＮＳＥのメッセージの場合のみ有効である。
【０２５０】
2004520641.tif 000069
【０２５１】
このメソッドは、メッセージのチャネル名を返す。これは、クラス値がＭＣ＿ＣＨＡＮＮＥＬのメッセージの場合のみ有効である。
【０２５２】
2004520641.tif 000070
【０２５３】
このメソッドは、メッセージのクラス値を返す（「ＭＳＧ＿ＣＬＡＳＳ列挙型」を参照）。
【０２５４】
2004520641.tif 000071
【０２５５】
このメソッドは、メッセージのパラメータにアクセスする場合に使用する。この呼び出しの最初のパラメータは、アクセスするメッセージパラメータの０から始まるインデックスである。メッセージパラメータオブジェクトでパラメータを使用するのと同じである。
【０２５６】
2004520641.tif 000072
【０２５７】
このメソッドは、メッセージ内のパラメータの個数を返す。
【０２５８】
３．１８．７  ＩＤｅｃｌｓ
宣言と永続的宣言のインターフェース。宣言および永続的宣言は、アクティベーションコンテキストオブジェクトを通じて渡されるルール内で宣言される情報である。これを使用すると、アダプタからルール内の宣言にアクセスできる。
【０２５９】
宣言インターフェースは、標準のコレクションインターフェースである。コレクションインターフェースでは、Ｆｏｒ ｅａｃｈ．．Ｎｅｘｔ構文を使用できる。インデックス付きアクセスもサポートする。
【０２６０】
メソッド
2004520641.tif 000073
【０２６１】
このメソッドは、新しい列挙子 （ｅｎｕｍｅｒａｔｏｒ） を作成する。通常、このメソッドを使用する必要はない。
【０２６２】
プロパティの取得
2004520641.tif 000074
【０２６３】
このメソッドは、宣言または永続的宣言の個数を返す。
【０２６４】
2004520641.tif 000075
【０２６５】
このメソッドは、宣言または永続的宣言の値を返す。最初のパラメータは、０から始まるインデックスとすることができる。
【０２６６】
2004520641.tif 000076
このメソッドは、宣言または永続的宣言の値を返す。最初のパラメータは、０から始まるインデックスとすることができる。ｄａｔａ（）と同じである。
【０２６７】
３．１８．８  ＭＳＧ＿ＣＬＡＳＳ
メッセージクラス列挙型によって、生成されるメッセージの各クラスに数値が関連付けられる。たとえば、ＳｅｎｄＭｏｄｕｌｅＭｅｓｓａｇｅを使用すると、メッセージのクラス値が３２であるメッセージが得られる。
【０２６８】
ＭＣ＿ＵＮＤＥＦＩＮＥＤ ＝ ０
ＭＣ＿ＢＲＯＡＤＣＡＳＴ ＝ １
ＭＣ＿ＲＥＱＵＥＳＴ ＝ ２
ＭＣ＿ＲＥＳＰＯＮＳＥ ＝ ４
ＭＣ＿ＰＲＯＸＹ ＝ ８
ＭＣ＿ＣＨＡＮＮＥＬ＝ １６
ＭＣ＿ＭＯＤＵＬＥ ＝ ３２
【０２６９】
４．０  ネットワークレイヤ
ネットワークレイヤは、システムの一構成要素であり、ネットワーク上のデバイス同士の間のイベント（または通信）の拡張として使用される。一実施形態では、ユーザレベルのモジュールはネットワークレイヤに直接アクセスすることはできず、論理名でのみネットワークと交信できる。Ｏｐｅｎ Ｄｅｓｉｇｎシステムは明示的なネットワークアダプタを備えていないが、その代わりにカーネルアダプタを介したネットワーク選択機能を公開している。他のすべてのアダプタと同様、ネットワークアダプタも、メッセージをイベントバスに送信し、イベントバスを介してルールエンジンからメッセージを受信することによりシステムと通信する。ネットワークアダプタは、各ノード上のルータをネットワーク上の１つまたは複数のピアノードに接続する。
【０２７０】
一実施形態では、アダプタはＯｐｅｎ Ｄｅｓｉｇｎメッセージスキーマを介してイベントバスと通信する。それぞれのアダプタは、ルールエンジン内でこのアダプタと突き合わせて作成されたルールによって認識されるそのアダプタ専用のメッセージスキーマを提示する。ネットワークレイヤは、主にシステム提供ルールと会話するシステム提供アダプタであるという点で幾分特殊である。
【０２７１】
まず、ネットワークレイヤは他のアダプタと同様に、イベントをネットワークレイヤ固有のスキーマが含まれるイベントバスに送信する。これらのイベントは、ネットワークレイヤによって直接生成されるシステムイベントとみなすことができ、それらを取り扱うためにシステム側で指定するルールがルールエンジン内でコンパイルされる。このような種類のイベントは、「ネットワークはオンライン／オフラインである」、「ネットワーク帯域伝送速度はＸＸＸである」などのＯｐｅｎ Ｄｅｓｉｇｎプラットフォームの意味をサポートしている。これらのイベントは幾分まれであるが、システム固有の活動およびＵＩ表示を行う。
【０２７２】
第２に、ネットワークレイヤはネットワーク上からデータのパケットを受信することができる。このパケットは、ネットワークレイヤ固有のスキーマでラップされるが、ラップされているパケットをＯｐｅｎ Ｄｅｓｉｇｎメッセージ構造に戻すのがネットワークレイヤの仕事である。このＯｐｅｎ Ｄｅｓｉｇｎイベントは、送出マシン上で起動されたルールにより指定されているリモートメッセージ用のラッパーである。受信側マシン上のシステム提供ルールはイベントを処理し、メッセージヘッダとペイロードを使用して、メッセージを別のピアに転送するか、またはそのメッセージをローカルイベントバスに送出し、次に、そのメッセージを適切なアダプタまたは送信先アプリケーションに配信する。実行されるこのアクション（アクティベーション）は、受信側マシン上でインスタンス化されるという点を除き、発信元マシン上で指定されたものとまったく同じである。
【０２７３】
図８は、ネットワークレイヤ、イベントバス、ルールエンジン、およびネットワーク上のネットワークレイヤのインスタンス間のプライベートコールの間の高水準の制御の流れを示している。
【０２７４】
４．１  ネットワークレイヤからイベントバスへ
他のアダプタの場合と同様に、ネットワークレイヤはＯｐｅｎ Ｄｅｓｉｇｎイベントをイベントバスにメッセージとして書き込む。
【０２７５】
４．２  イベントバスからルールエンジンへ
イベントバスは、ルールエンジンと通信し、入力イベントをメッセージとして供給する。
【０２７６】
４．３  ルールエンジンからネットワークレイヤへ
ルールエンジンは、ネットワークレイヤへのメッセージに埋め込んだアクティベーションを起動する。
【０２７７】
４．４  ネットワークレイヤからネットワークレイヤへ
ネットワークレイヤは、Ｏｐｅｎ Ｄｅｓｉｇｎネットワークサービスを通じてネットワーク上でネットワークレイヤと通信を行う。これらの呼び出し（プロキシサーバレイヤを通ることがある）は、図８で点線により表される。この図に示されているのは、他方のネットワークレイヤから一方のネットワークレイヤにより受信されたデータをＯｐｅｎ Ｄｅｓｉｇｎメッセージに変換できるということである。
【０２７８】
図９は、Ｏｐｅｎ Ｄｅｓｉｇｎメッセージのアドレス指定レイヤを示すブロック図である。下のイベント要素が、ローカルイベントバス上に現れるときのメッセージの内部表現である。一実施形態では、タグ名および値を含むメッセージヘッダの特定の要素が変わる。イベント本体の前にあるトランスポート、物理および論理ヘッダは、ノード間およびホップバイホップアドレス指定情報および命令を備える。これらの追加アドレス指定要素は、回線上のイベントのラッパーである。
【０２７９】
図１０は、ノードＡおよびＢ上で稼働されているアプリケーション間のノード間メッセージ交換に関わるアーキテクチャ要素のすべてを含むより完全な図である。
【０２８０】
Ｏｐｅｎ Ｄｅｓｉｇｎメッセージは、上に示されている回線形式からラッパーを取り外した内部メッセージである。イベントバスメッセージのスキーマは次のとおりである。
【０２８１】
４．５  メッセージスキーマ
2004520641.tif 000077
2004520641.tif 000078
【０２８２】
５．０  ルールエンジン
ルールは、ロジックを表現する一手段である。条件、つまり左側（ＬＨＳ）を一組の依存関係として書き、アクション、つまり右側（ＲＨＳ）を他のルールの条件のトリガとなるものとして書く。たとえば、次のようである。
【０２８３】
2004520641.tif 000079
【０２８４】
2004520641.tif 000080
【０２８５】
ルール１と４２は、別々の開発者が作成することも、また別の時に作成することもでき、システムが共有されている「ｐｅｒｓｏｎ．ａｄｕｌｔ」基準により「リンク」してまとめる。他の人のルールをこのように拡張できることをコンポジビリティと呼ぶ。ルールエンジンはルール同士をリンクしてまとめることにより、起動する必要のあるルールを、自動的に非常に効率よく決定することができる。実際、良いルールエンジンはルールの数に直線的に比例する以上によくなり、１００，０００個のルールを持つシステムは２，０００個のルールを持つシステムと比べて実行速度がほとんど変わらない。
【０２８６】
Ｏｐｅｎ Ｄｅｓｉｇｎイベントバスは、メッセージディスパッチ用のルールエンジンと、ノード内およびノード間のメッセージディスパッチおよび転送の実行に使用されるルールを供給するアプリケーションおよびシステムに付属するモジュールに基づくアプリケーションのメッセージ通信媒体である。
【０２８７】
５．１  ルールの利点
・手続き的ではなく宣言的である
・ルールにより、どのようにするかではなく、何をするかを指定するので、（オプションの）最適化が可能である。一実施形態では、ＲＥＴＥと呼ばれるデータ駆動方式の最適化が使用される。
・ルールにより依存関係とアクションは明示的に指定されるため、ルールセットの分析が可能である（たとえば、安全およびセキュリティに関して）。一実施形態では、ルータポリシーフィルタはルール条件に基づいている。
・一般的なツールでルールを構築することができ、たとえば、Ｏｐｅｎ Ｄｅｓｉｇｎではルールトランスレータ、統計量などにＸＭＬを使用する。
・不可避であり、たとえば、アクションから条件に戻るだけでなく、条件からアクションに戻ることができる。
・ルールシステムをそれぞれの間で変換することができる。
・ルールを作成可能 （ｃｏｍｐｏｓａｂｌｅ） にできる、つまり、異なる作成者がルールを追加、削除することができ、エンジンはそれらを保持することができる。
・ルールの衝突を自動的に検出できる。
・異なる「作成者」がすべてのイベントおよび条件を見なくても基本システムを作成し、その自分専用の「表示」を見ることができる。
・信頼できる。最も宣言的なエンジンは、単純な数学的基盤を持つため、手続き的なエンジンよりも遙かに信頼性が高い。
・強力なロジックシステム。
・リレーショナル演算が強力であり、実際、ＳＱＬの表現力のスーパーセットである。
・結合をインクリメンタルに更新されるデータ構造に入れる。
【０２８８】
５．２  経路指定のルール
従来の経路指定アルゴリズムはプログラム可能ではない。その代わりに、データ共有のピアツーピアに基づいて動作を変更する。つまり、従来の経路指定アルゴリズムは、固定ＬＨＳ条件を使用し固定ルールで拡張可能である。たとえば、経路指定決定を下すために検査した基準の集まりはＢＧＰ（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）では決して変化しない。
【０２８９】
一実施形態では、ルールを使用して、プロトコルを大域的に変更せずに基準に追加することが可能である。たとえば、以下のとおりである。
【０２９０】
2004520641.tif 000081
【０２９１】
ネットワーク内の複数のルータが新しい経路指定ルールに更新されない場合、グローバルシステムは動作を続ける。新しい経路指定ルールに更新されるルータは、高優先度トラフィックと低優先度のトラフィックとを区別できる。
【０２９２】
従来のルータはルールを使用せず、プロシージャコードを使用する。アルゴリズムはあまり更新されず、新しい条件が追加されないので、別の人々がアルゴリズム、プロシージャコードワークを追加することはない。
【０２９３】
一実施形態では、Ｏｐｅｎ Ｄｅｓｉｇｎシステムによって、第三者がアプリケーション固有の基準（顧客番号、時刻、注文タイプ）など新しい条件を経路指定に追加することができる。従来のモデルでは、第三者にプロシージャコードの作成を要求しており、安全性、最適化、構成可能性、反転可能性、衝突検査などのルールの利点が本質的に失われる。
【０２９４】
・ルールを使用して経路指定に使う基準を追加し修正する。
○経路指定に影響を及ぼすと思われる情報の正しいスキーマを追加し、その情報をルールによりアクセスできる「データベース」に書き込む。
・ルールを分散することができる。
○ルールを一方のノードから他方のノードに移動する場合、どのようなデータにアクセスし、どのようなデータをアサートするかを確認することができる。これにより、あるレベルの安全検査を決定することができる。
・ルールとプログラムとの対話操作が可能である。
○経路指定テーブルとは異なり、ＬＨＳまたはＲＨＳにあるプログラムデータまたはオブジェクト属性を指定することによりルールとプログラムとの対話操作が可能である。これによりルールがプログラムを「呼び出す」か、またはプログラムにルールを起動させることができる。このように、あるレベルの安全性とスケーラビリティを保持しながらプログラムとの統合を果たすことは経路指定テーブルまたは従来の「レイヤ７」の経路指定を超える特色となっている。
○対話は、プロトコルおよび／またはＸＭＬレベルで行われる、つまりプログラム側でＸＭＬを使用して情報を吐き出すかまたは消費するということである。
・ルールを使用して分散アルゴリズムを作成する。
○ユーザのディレクトリが分散されている場合、ディレクトリ内を移動しなければならないときにルールを使用してそれを表現することができる。
【０２９５】
５．３  Ｒｅｔｅ
Ｒｅｔｅはルールエンジンで使用するアルゴリズムである。Ｒｅｔｅアルゴリズムには２つの部分がある。
【０２９６】
指定された式の値が繰り返しごとに変化する可能性がないため、式は繰り返し再評価されない。
【０２９７】
たとえば、以下のとおりである。
2004520641.tif 000082
【０２９８】
新しい事実は、関連する可能性のあるルールに対してのみ比較する。
【０２９９】
ルールは、「ワーキングメモリ」−その領域に関して知られている事実の集まり−と突き合わせて書き込む。
【０３００】
一実施形態では、ワーキングメモリはモジュールおよびイベントストリームによって作成されたセッションおよび永続的データで構成される。
【０３０１】
ルールは式のツリー内の最も下のノードである。
【０３０２】
複数のルールおよび共通の式がルール間にあるとすぐに、別の最適化で複数の式のツリー内に単一の式を置くことになる。
【０３０３】
Ｒｅｔｅで式が起動すると、起動は満たすことができないノードに達するまで下へ浸透してゆく。
【０３０４】
５．４  ルール言語
一実施形態では、プラットフォーム言語はそのスキーマ内のいくつかの要素の概念に意味がさらに課されている場合にその意味と結合したＸＭＬスキーマである。（これは、＜ｅｘｐｒ＞ｍｓｇ．ｐａｒａｍｓ（２）＜／ｅｘｐｒ＞が＜ｅｘｐｒ＞”Ｈｅｌｌｏ， ｗｏｒｌｄ．”＜／ｅｘｐｒ＞と違った解釈が行われるということである。）
【０３０５】
この言語で書かれたプログラムを「モジュール」と呼ぶ。モジュールはプラットフォームに対するプログラム可能性の単位である。
【０３０６】
このセクションは次のように構成される。まず、言語のＢａｃｋｕｓ−Ｎａｕｒ Ｆｏｒｍ（ＢＮＦ）文法について説明する。次に、ＢＮＦの例外を取り上げて明確に説明する。最後に、言語での式の使用について説明するが、これは、使用可能な固有の記号、許可されているリテラルの種類、および実行時に呼び出せる機能の組を含む。
【０３０７】
５．４．１  ＢＮＦ
ＢＮＦは次のように解釈される。
−文法の開始記号は”ＳＴＡＲＴ”で表される。
−与えられた記号のプロダクションは”；”で終端する。
−与えられた記号に対する複数のプロダクションは”｜”で区切る。
−”？”が後に続く記号は０回または１回出現できる。
−”＊”が後に続く記号は０回または１回以上出現できる。
−”＋”が後に続く記号は１回または複数回出現できる。
−与えられたプロダクション内の記号は、指定された順序で出現できる。
【０３０８】
2004520641.tif 000083
2004520641.tif 000084
2004520641.tif 000085
2004520641.tif 000086
2004520641.tif 000087
2004520641.tif 000088
2004520641.tif 000089
2004520641.tif 000090
2004520641.tif 000091
【０３０９】
５．４．２  ＢＮＦに関する注意事項
一実施形態では、言語で許されている構文でも、ＢＮＦで記述されない構文、あるいはその構文に用意されているプロダクションルールよりもさらに説明を要するような構文がある。
【０３１０】
５．４．２．１  ホワイトスペース
ＸＭＬ要素内の先行または後続のホワイトスペースは削除できる。つまり、＜ａｃｔｉｖ−ｄｅｓｔ＞ｆｏｏ＜／ａｃｔｉｖ−ｄｅｓｔ＞は、＜ａｃｔｉｖ−ｄｅｓｔ＞ ｆｏｏ ＜／ａｃｔｉｖ−ｄｅｓｔ＞と同じである。
【０３１１】
５．４．２．２  式
言語には、プロダクションにオプションの＜ｅｘｐｒ＞要素が含まれる複数の要素がある、つまりプロダクションは”：：＝ ｅｘｐｒ？ ；”に似た形式である。たとえば、ａｃｔｉｖ−ｃｍｄ、ｄｅｃｌｓ−ｄａｔｕｍ−ｎａｍｅ、ｔｎ−ｖａｌｕｅなどがある。
【０３１２】
これらの要素については、子＜ｅｘｐｒ＞ ＸＭＬ要素がない場合、要素の内容は”＜ｅｘｐｒ＞”と”＜／ｅｘｐｒ＞”で囲まれているかのように取り扱われる。これはプログラマの便宜のため行われるものであり、”＜ｔｎ−ｖａｌｕｅ＞７＜／ｔｎ−ｖａｌｕｅ＞”などのコードをより冗長な”＜ｔｎ−ｖａｌｕｅ＞＜ｅｘｐｒ＞７＜／ｅｘｐｒ＞＜／ｔｎ−ｖａｌｕｅ＞”の代わりに書くことができる。
【０３１３】
以下の要素はこのルールの例外である。
【０３１４】
−ａｃｔｉｖ−ｐａｒａｍ：ａｃｔｉｖ−ｐａｒａｍｓ、またはｅｘｐｒ、または単純なＸＭＬ文字データを含むことができる。
−ルール、要求、および応答：ｅｘｐｒを省略することは、単に、ルールはその左側（ＬＨＳ）の一部として追加テストを含まないことを意味する。
【０３１５】
５．４．２．３  終端ノード
言語には、文法内で終端ノードとなる要素がある、つまりプロダクションは”：：＝ ；”という形式である。このセクションでは、これらの要素の内容を解釈する方法について説明する。プラットフォーム言語および変換エンジンの一実施形態では、変換エンジンの中に記号テーブルが存在するためすべての終端ノードを”ｅｘｐｒ？”に解決できる。
【０３１６】
−ａｃｔｉｖ−ｄｅｓｔ：この要素のＸＭＬ文字データ内容に対して特別な処理または解釈は一切行われない。
−ａｃｔｉｖ−ｄｅｓｔ−ｉｎｓｔａｎｃｅ：要素のＸＭＬ文字データは＜ｅｘｐｒ＞の内容のルールに従うことができる、つまり、データを数値、文字列、または記号として構文解析できる。
−ａｃｔｉｖ−ｒｅｃｐｔ−ｒｅｑｄ：要素の内容は無視される−要素の有無は重要なことである。
−ａｐｐ−ｄｅｓｃおよびａｐｐ−ｎａｍｅ：要素のＸＭＬ文字データ内容は、推論エンジン内で有効な文字列として使用できるようにエスケープされる。
−ａｐｐ−ｕｕｉｄ：すべての小文字は大文字に変換される。
−ａｐｐ−ｖｅｒ：この要素のＸＭＬ文字データ内容に対して特別な処理または解釈は一切行われない。
【０３１７】
５．４．２．４  式
式はプラットフォーム言語の動的な部分を形成し、記号の実行時置換とリテラルのオーサリング時使用が組み合わされてモジュールの動作に影響を及ぼす。
【０３１８】
モジュール変換エンジンは、正規表現を使用して変換時にそれぞれの式の種類を決定する。
【０３１９】
５．４．２．５  リテラル
言語は、文字列リテラル（たとえば、”Ｈｅｌｌｏ， ｗｏｒｌｄ．”）、１０進数および１６進数整数リテラル（たとえば、７および０ｘａ）、および浮動小数点数リテラル（たとえば、３．１４）をサポートする。
【０３２０】
式の中のＣＤＡＴＡセクションは、文字列リテラルとして解釈される。
【０３２１】
５．４．２．６  記号
言語はさらに、実行時にメッセージおよび宣言のフィールドの値にアクセスしたり、現在のモジュールのプロパティにアクセスしたり、表記上の便宜のため特別に解釈される多数の記号をサポートしている。プラットフォーム言語および変換エンジンの一実施形態では、ユーザ定義記号がサポートされている。
【０３２２】
以下の記号がサポートされている。
【０３２３】
ｍｓｇ．ｐａｒａｍｓ（ｎｏｎ−ｎｅｇａｔｉｖｅ ｉｎｔｅｇｅｒ）
ｍｓｇ．ｓｒｃ
ｍｓｇ．ｓｒｃＩｎｓｔａｎｃｅ
ｍｓｇ．ｃｏｒｒｅｌａｔｉｏｎＩＤ
ｍｓｇ．ｔｙｐｅ
ｍｓｇ．ｒｅｓｐｏｎｓｅＩＤ
ｍｓｇ．ｃｈａｎｎｅｌ
ｍｓｇ．ｃｌｓ
ｄｅｃｌｓ．ｄａｔａ（ｎｏｎ−ｎｅｇａｔｉｖｅ ｉｎｔｅｇｅｒ）
ｐｄｅｃｌｓ．ｄａｔａ（ｎｏｎ−ｎｅｇａｔｉｖｅ ｉｎｔｅｇｅｒ）
ｍｏｄ．ｇｕｉｄ
ｍｏｄ．ｎａｍｅ
ｍｏｄ．ｖｅｒ
ｍｏｄ．ｄｅｓｃ
ｍｏｄ．ｐａｔｈ
ｍｏｄ．ｉｎｓｔａｎｃｅＩＤ
ｔｒｕｅ
ｆａｌｓｅ
ｎｕｌｌ
【０３２４】
５．４．２．７  関数
言語は、関数値を持つ式をサポートする。つまり、リテラルまたは記号プロダクションの代わりに”ｅｘｐｒ”の”ｆｕｎｃ”プロダクションを使用する。関数は、名前と引数リストを持つ。引数リストは、それ自体式の集まりであり、このようにして、文法に従って任意に複雑な式を作成できる。
【０３２５】
プラットフォーム言語は、以下の関数をサポートする。それぞれの関数について、予期される引数の個数と簡単な説明を付けて一覧にした。プラットフォーム言語および変換エンジンの一実施形態では、式は型付き、関数は型付き、関数は型付き戻り値を持つ。
【０３２６】
ａｎｄ
引数：少なくとも１つ。
説明：すべての引数が真に評価される場合に真に評価される。
ｏｒ
引数：少なくとも１つ。
説明：引数のどれかが真に評価される場合に真に評価される。
ｎｏｔ
引数：ちょうど１つ。
説明：引数が偽に評価される場合に真に評価される。
ｇｔ
引数：ちょうど２つ。
説明：第１の引数が第２の引数よりも大きい場合に真に評価される。
ｌｔ
引数：ちょうど２つ。
説明：第１の引数が第２の引数よりも小さい場合に真に評価される。
ｅｑ
引数：ちょうど２つ。
説明：第１の引数が第２の引数に等しい場合に真に評価される。
ｎｅｑ
引数：ちょうど２つ。
説明：第１の引数が第２の引数に等しくない場合に真に評価される。
ｇｔｅ
引数：ちょうど２つ。
説明：第１の引数が第２の引数よりも大きいかまたは等しい場合に真に評価される。
ｌｔｅ
引数：ちょうど２つ。
説明：第１の引数が第２の引数よりも小さいかまたは等しい場合に真に評価される。
ｓｔｒｉｎｇ−ａｐｐｅｎｄ
引数：少なくとも２つ。
説明：引数すべてを連結して得られる文字列に評価される。
ｓｔｒｉｎｇ−ｃｏｍｐａｒｅ
引数：ちょうど２つ。
説明：第１の引数と第２の引数が語彙的に等価な場合に真に評価される。
ｓｔｒｉｎｇ−ｉｃｏｍｐａｒｅ
引数：ちょうど２つ。
説明： 大文字小文字を無視して第１の引数と第２の引数が語彙的に等価な場合に真に評価される。
ｓｔｒｉｎｇ−ｃｏｎｔａｉｎｓ
引数：ちょうど２つ。
説明：第２の引数が第１の引数内のどこかに出現する場合に真に評価される。
ｓｔｒｉｎｇ−ｉｃｏｎｔａｉｎｓ
引数：ちょうど２つ。
説明： 大文字小文字を無視して第２の引数が第１の引数内のどこかに出現する場合に真に評価される。
ｅｓｃａｐｅ−ｄｅｌｉｍｉｔｅｒ
引数：ちょうど１つ。
説明：”／”のすべての出現を”％２Ｆ”で置き換えて得られる文字列に評価される。これで、”／”を含むツリーノードを作成できる。
ｐｌｕｓ
引数：ちょうど２つ。
説明：第１の引数を第２の引数に加えた結果に評価される。
ｍｉｎｕｓ
引数：ちょうど２つ。
説明：第１の引数から第２の引数を引いた結果に評価される。
ｍｕｌｔｉｐｌｙ
引数：ちょうど２つ。
説明：第１の引数を第２の引数で乗算した結果に評価される。
ｄｉｖｉｄｅ
引数：ちょうど２つ。
説明：第１の引数を第２の引数で除算した結果に評価される。
【０３２７】
５．４．３  モジュール変換エンジン
モジュール変換エンジンとは、それぞれ前の変換入力の出力を取り、ある種の処理を実行し、その出力をシーケンスの中の次の変換に手渡す一連の変換のことである。
【０３２８】
一般に、この変換のパイプラインはプラットフォームによりロードし実行できるコードを生成する。しかし、たとえば、モジュールの妥当性を確認するだけでよく、したがって、コード生成変換が省略されることもある。
【０３２９】
このセクションは次のように構成される。まず、変換パイプラインフレームワークについて説明する。次に、変換について説明する。最後に、変換エンジンの応用例としてコマンドラインドライバについて説明する。
【０３３０】
５．４．３．１  変換パイプラインフレームワーク
モジュール変換エンジンを使用することにより、変換のシーケンスを作成するアプリケーションをそのエンジンの上に構築し、与えられた入力に対して１つずつ呼び出すようにできる。この作業を簡単にするために、他のすべての変換が派生する基になる抽象基本変換クラスを用意する。ベースでは次の（仮想的）メソッドを公開する。
【０３３１】
2004520641.tif 000092
【０３３２】
これを与えると、次の形式のコードを書くことができる。
【０３３３】
2004520641.tif 000093
【０３３４】
５．４．３．２  変換
このセクションでは、モジュール変換エンジンのそれぞれの変換について取り上げる。
【０３３５】
ＲｅａｄＦｉｌｅ
【０３３６】
この変換は、ファイル名を入力として取り、ファイルの内容を出力として返す。
【０３３７】
Ｐｒｅｐｒｏｃｅｓｓｏｒ
【０３３８】
この変換は、正しく構築されたＸＭＬのバッファを入力として取り、バッファ内にある前処理ディレクティブを実行し、それらのディレクティブで実行された結果を出力として返す。
【０３３９】
以下では、プロセッサでサポートしている各前処理ディレクティブとその取扱方について説明する。
【０３４０】
＜ｐｒｅｐｒｏｃｅｓｓｏｒ＞：何もしない。
＜ｄｅｆｉｎｅ＞：このタグは、「記号」属性を含むことができる。これが見つかった場合、現在の変換の呼び出しのために指定された記号をプリプロセッサの記号テーブルに追加する。
＜ｉｆｄｅｆ＞：このタグは、「記号」属性を含むことができる。指定された記号が記号テーブル内に存在する場合、＜ｉｆｄｅｆ＞の開きタグおよび閉じタグの内容が出力バッファに含まれる。存在しない場合には、内容は省略される。＜ｉｆｄｅｆ＞タグが出力をオフにした囲んでいる＜ｉｆｄｅｆ＞または＜ｉｆｎｄｅｆ＞ディレクティブ内にある場合、出力はオフのままである。
＜ｉｆｎｄｅｆ＞：このタグは、「記号」属性を含むことができる。指定された記号が記号テーブル内に存在する場合、＜ｉｆｎｄｅｆ＞の開きタグおよび閉じタグの内容は出力バッファから省かれる。存在しない場合には、内容が含まれる。＜ｉｆｎｄｅｆ＞タグが出力をオフにした囲んでいる＜ｉｆｄｅｆ＞または＜ｉｆｎｄｅｆ＞ディレクティブ内にある場合、出力はオフのままである。
＜ｉｎｃｌｕｄｅ＞：このタグは、「ファイル」属性を含むことができる。ファイル（”．ｒｉ”）の内容はインラインでｉｎｃｌｕｄｅディレクティブの代わりに配置される。ｉｎｃｌｕｄｅのサポートされる最大の深さは５０である。
【０３４１】
プリプロセッサディレクティブは、返される出力バッファから省かれる。概して、これらのディレクティブは、Ｃプリプロセッサにあるものと意味的に同一である。
【０３４２】
Ｖａｌｉｄａｔｅ
この変換は正しく構成されたＸＭＬのバッファを入力として取り、プラットフォーム言語の文法に従って妥当性を確認し、すべてが適切であればその内容としてバッファを変更せず返す。バッファが正しく構成されたＸＭＬでないか、またはプラットフォーム言語の文法に関して無効である場合、エラーを返す。
【０３４３】
Ｔｒａｎｓｌａｔｅ
この変換は正しく構成されたＸＭＬのバッファを入力として取り、Ｅｃｌｉｐｓｅコードに変換し、出力としてＥｃｌｉｐｓｅコードのバッファを返す。
【０３４４】
ＷｒｉｔｅＦｉｌｅ
この変換は任意のバッファを入力として取り、ファイルをディスクに書き出し、バッファを出力として変更せずに返す。使用されるファイル名は、現在処理中のファイルの名前に基づく。パス区切り記号はすべて下線に変換され、先頭に付く”．”は除去され、”．ｒｅａ”が付加される。
【０３４５】
５．４．３．３  応用例：ａｐｐｇｅｎ
モジュール変換エンジンは、実行時にモジュールのロードに使用できるように、コンパイルのときにプラットフォームのバイナリにリンクされる。このツールは、”ａｐｐｇｅｎ”と呼ばれる（または、Ｗｉｎ３２では”ａｐｐｇｅｎ．ｅｘｅ”）。これは、上記の５つの変換をインスタンス化し、次の順序で接続する。
【０３４６】
2004520641.tif 000094
【０３４７】
サポートされているコマンドラインオプションは以下のとおりである。
【０３４８】
−ｓｏｕｒｃｅｆｉｌｅ：単一のファイル名引数を取る。このオプションを指定した場合、−ｓｏｕｒｃｅｄｉｒおよび−ｔａｒｇｅｔｄｉｒオプションは無視される。指定されたファイル名がＲｅａｄＦｉｌｅ変換への入力として使用される。
−ｓｏｕｒｃｅｄｉｒ：単一のディレクトリ名引数を取り、指定されない場合デフォルト値は”．”である。−ｓｏｕｒｃｅｆｉｌｅオプションを指定しない場合、ａｐｐｇｅｎはファイルシステムの指定されたディレクトリの下を横断し、出会ったすべての．ｒファイルを処理する。
−ｔａｒｇｅｔｄｉｒ：単一のディレクトリ名引数を取り、指定されない場合デフォルト値は”．”である。変換されたファイルはこのディレクトリ内に保管される。
−ｒｉｎｇ：０から１０までの単一の引数をとる。デフォルトは１０である。この値がＴｒａｎｓｌａｔｅ変換に渡される。
−Ｄ：単一の文字列引数を取る。Ｐｒｅｐｒｏｃｅｓｓｏｒ変換で使用する記号を定義する。
【０３４９】
以下にいくつかのドライバ呼び出し例を示す。
【０３５０】
2004520641.tif 000095
【０３５１】
上の最後の呼び出しでは、カレントディレクトリの下のディレクトリツリーが処理され、変換されたすべてのファイルがカレントディレクトリに落とされる。
【０３５２】
５．４．４  コード生成
このセクションの目的は、プラットフォーム言語の構文からコードを生成する方法について説明することである。コード生成の各主要単位に応じてセクションを構成している。
【０３５３】
５．４．４．１  式
このセクションでは、＜ｅｘｐｒ＞言語構文要素の内容からコードをどのように生成するかについて説明する。リテラルを最初に取り上げ、次に記号、そして関数を取り上げる。
【０３５４】
５．４．４．２  リテラル
整数
整数式としては１０進数および１６進数がサポートされている形式である。使用する形式が何であれ、表現は出力する前に１０進数に変換できる。
つまり、次のコードスニペット
【０３５５】
＜ｅｘｐｒ＞１０＜／ｅｘｐｒ＞
と
＜ｅｘｐｒ＞０ｘａ＜／ｅｘｐｒ＞
から、次のようなコードが生成される。
１０
【０３５６】
浮動小数点数値
１０進数形式の整数と同様に、浮動小数点数値は直接出力され、コード生成に特別な変換は不要である。
【０３５７】
つまり、次のコードスニペット
【０３５８】
＜ｅｘｐｒ＞１．０＜／ｅｘｐｒ＞
から、次のようなコードが生成される。
１．０
【０３５９】
文字列
文字列には、単純文字列と、セクション２．１およびＣＤＡＴＡセクションに取り上げられている正規表現に従う書式の二重引用符で囲まれた文字列の２つの形式がある。
【０３６０】
最初のは次のようである。
＜ｅｘｐｒ＞”Ｈｅｌｌｏ．”＜／ｅｘｐｒ＞
【０３６１】
次のコードが生成される前に、この値に対し特別な変換は一切実行されない。
”Ｈｅｌｌｏ．”
【０３６２】
もう１つは次のとおりである。
2004520641.tif 000096
【０３６３】
この場合、ＣＤＡＴＡセクション区切り記号は剥ぎ取られ、すべての二重引用符とバックスラッシュはバックスラッシュでエスケープされ、得られる文字列は二重引用符で囲まれ、次のようなコードになる。
【０３６４】
2004520641.tif 000097
【０３６５】
５．４．４．３  記号
ｍｓｇ．ｃｈａｎｎｅｌ：”？ｃｈａｎｎｅｌ”に解決される。
ｍｓｇ．ｃｌｓ：可能なメッセージクラス文字列の１つに解決される。
ｍｓｇ．ｃｏｒｒｅｌａｔｉｏｎＩＤ：”？ｃｉｄ”に解決される。
ｍｓｇ．ｐａｒａｍｓ（ｎ）：”？ｐｎ”に解決される。
ｍｓｇ．ｒｅｓｐｏｎｓｅＩＤ：”？ｒｉｄ”に解決される。
ｍｓｇ．ｓｒｃ：ルールでｍｓｇ−ｓｒｃを指定した場合、この記号は指定されたものに解決される。指定していない場合、この記号は”？ｓｏｕｒｃｅ”に解決される。
ｍｓｇ．ｓｒｃＩｎｓｔａｎｃｅ：”？ｓｏｕｒｃｅ−ｃｏｏｋｉｅ”に解決される。
ｍｓｇ．ｔｙｐｅ：ルールでｍｓｇ−ｔｙｐｅを指定した場合、この記号は指定されたものに解決される。指定していない場合、この記号は”？ｔｙｐｅ”に解決される。
ｄｅｃｌｓ．ｄａｔａ（ｎ）：”？ｄｅｃｌｎ”に解決される。
ｐｄｅｃｌｓ．ｄａｔａ（ｎ）：”？ｐｄｅｃｌｎ”に解決される。
ｍｏｄ．ｄｅｓｃ
ｍｏｄ．ｇｕｉｄ
ｍｏｄ．ｎａｍｅ
ｍｏｄ．ｖｅｒ：ａｐｐ−ｄｅｓｃに対して指定されたものに解決されるが、ただしＣＤＡＴＡ区切り文字列値を持つ式の場合と全く同じようにデータはエスケープされる。
ｍｏｄ．ＩｎｓｔａｎｃｅＩＤ：２個の０バイトに解決される。
ｍｏｄ．ｐａｔｈ：”？ｐａｔｈ”に解決される。
ｔｒｕｅ：”（＝ １ １）”に解決される。
ｆａｌｓｅ：”（＝ Ｏ １）”に解決される。
ｎｕｌｌ：”０”に解決される。
【０３６６】
５．４．４．４  関数
関数への引数を構成する式のツリーを再帰的に降下 （ｄｅｓｃｅｎｄｉｎｇ） することにより関数のコードを生成する。それぞれの関数は次のテンプレートに従う。
【０３６７】
2004520641.tif 000098
【０３６８】
与えられた式引数のコードを生成するといっても、式のルール（関数を含む）を単に再び適用するだけである。本書の目的のために、与えられた関数の引数に対し生成されるコードを”ａｒｇｓ”で表す。
【０３６９】
2004520641.tif 000099
【０３７０】
６．０  Ｏｐｅｎ Ｄｅｓｉｇｎアプリケーションモデル
Ｏｐｅｎ Ｄｅｓｉｇｎモジュールと呼ばれるＸＭＬベーススキーマにより、Ｏｐｅｎ Ｄｅｓｉｇｎアプリケーションを定義する。＜ｍｏｄｕｌｅ＞は、このスキーマのエントリタグであり、アプリケーションの名前、作成者、バージョン、アプリケーションを定義するルールの集まり、およびＯｐｅｎ Ｄｅｓｉｇｎカーネルがシステムユーザインターフェースにエントリポイントを提供するためのその他のスキーマを識別するタグを含む。
【０３７１】
ルールは、外部参照することも、またＯｐｅｎ Ｄｅｓｉｇｎアプリケーション定義内でインライン参照することもできる。
【０３７２】
アプリケーションロジックを．ｒファイル内のモジュールとして全部書かれている以下のサンプルアプリケーション、つまり「サービスレット」は、Ｏｐｅｎ Ｄｅｓｉｇｎの言語を規定している。このアプリケーションは、Ｏｐｅｎ Ｄｅｓｉｇｎプラットフォームの「ａｂｏｕｔ Ｗｉｎｄｏｗ」を表示する。
【０３７３】
2004520641.tif 000100
2004520641.tif 000101
2004520641.tif 000102
2004520641.tif 000103
2004520641.tif 000104
【０３７４】
このアプリケーションに追加できる追加ルール要素は経路指定ルール、ポリシールールなどを含む。より現実的なアプリケーションを構築する追加ルール要素の例については、「イベントバス」セクションで取り上げている。
【０３７５】
７．０  イベントバス
イベントバスは、Ｏｐｅｎ Ｄｅｓｉｇｎアプリケーションルータによって公開されるメッセージングインターフェースである。このインターフェースでは、すでに述べたそれぞれのモジュールタイプを書いて、Ｏｐｅｎ Ｄｅｓｉｇｎノード上のルールリポジトリ内にインストールすることができる。これらのインターフェースは、システム内にインストールされているルールによって呼び出される。イベントバスの基本的な機能は次のとおりである。
【０３７６】
・モジュールのロードおよびアンロード
・メッセージの送信
・名前の登録
・プラットフォーム、ネットワーク、およびＯＳポリシートリガーの公開：メッセージキューの長さ、ＣＰＵ使用度など
・チャネルの確立
・イベントバスの管理
・ネットワークの設定
【０３７７】
７．１  イベントバスインターフェース
サンプルをルールで記述されたサンプルのいくつかはアダプタインターフェースを呼び出す。これらのサンプルはルール言語で書かれている。これは、イベントバスインターフェースの完全なセットではなく、ここで取り上げているサンプルはイベントバスのインターフェースの種類と、それらを呼び出すためのルールの書き方を説明することを目的としている。
【０３７８】
７．１．１  モジュールロードルール
このメソッドは、ファイルからモジュールをロードする。モジュールファイルは、拡張子”．ｒｅａ”を持つ変換済みファイルまたは拡張子”．ｒ”を持つローＯＤＩ ＸＭＬファイルである。モジュールに拡張子”．ｒ”が付いている場合、トランスレータによって自動的に実行できる。
【０３７９】
2004520641.tif 000105
【０３８０】
インターフェースＬｏａｄ Ｍｏｄｕｌｅはリポジトリに新しいルールを追加するためのメカニズムの１つである。このルールの式部分は、ＬｏａｄＭｏｄｕｌｅＦｒｏｍＦｉｌｅを呼び出す以下のアクションが発生する条件を表す。
【０３８１】
2004520641.tif 000106
【０３８２】
７．１．２  メッセージ送信ルール
ｓｅｎｄＭｅｓｓａｇｅインターフェースを使用して宛先にメッセージを送信する。
【０３８３】
2004520641.tif 000107
【０３８４】
このインターフェースを呼び出すルールは以下のとおりである。
【０３８５】
2004520641.tif 000108
【０３８６】
宛先は、呼び出しのパラメータを認識することが期待される。この例では、パラメータはこのメッセージの宛先アプリケーションによって表示できる単純な文字列である。
【０３８７】
７．１．３  名前登録ルール
サービスまたはアプリケーションをネットワークに公開するには、ＲｅｇｉｓｔｅｒＬｏｇｉｃａｌＮａｍｅを呼び出す。インターフェースは次のとおりである。
【０３８８】
2004520641.tif 000109
【０３８９】
このインターフェースは、アプリケーション側で用意する名前登録ルールから呼び出される。次に、アプリケーション名を登録するために呼び出す例を示す。
【０３９０】
2004520641.tif 000110
【０３９１】
この呼び出しに渡すパラメータのいくつかはルールスニペットそれ自体である。上の名前登録ルールと照合するため、イベントバスへのアダプタを介してパラメータリストを構築し、ついでルールを起動するために使用するＣロジックは以下のとおりである。
【０３９２】
2004520641.tif 000111
2004520641.tif 000112
【０３９３】
この例で登録したサービス名「ＡｄｄｒｅｓｓＢｏｏｋ」についてインストールされている最終的な完了経路指定ルールは次のとおりである。
【０３９４】
2004520641.tif 000113
2004520641.tif 000114
【０３９５】
この名前登録では、経路指定ルールテンプレートで名前登録呼び出し内のパラメータを調べ、完全な経路指定ルールを形成する。
【０３９６】
この経路指定ルールはインフラストラクチャにより、’ＡｄｄｒｅｓｓＢｏｏｋ’サービスを呼び出すクライアントに伝播される。このサービスを呼び出すには、上述のｓｅｎｄＭｅｓｓａｇｅアクティベーションを使用する。ｓｅｎｄＭｅｓｓａｇｅイベントを生成し、イベントバス上に出すコードは次のとおりである。
【０３９７】
2004520641.tif 000115
【０３９８】
上のメッセージは、クライアントの実行時経路指定ルールによりイベントバス上のメッセージとして捕捉される。
【０３９９】
2004520641.tif 000116
【０４００】
クライアント経路指定ルールにより、呼び出しメッセージが捕捉され、ｓｙｓｓｖｃアダプタ＿ＳｅｎｄＬｏｇｉｃａｌＭｅｓｓａｇｅアクティベーションがアクティブにされる。
【０４０１】
2004520641.tif 000117
2004520641.tif 000118
【０４０２】
ＮｅｔＳｅｎｄに対する最後の呼び出しで、ネットワーク「アダプタ」がラップし、（適切な場合に）ピア接続に配信できるようにメッセージをエンコードする。
【０４０３】
７．１．４  応答ルール−しきい値負荷増大
ｅｂ＿ＬｏａｄＩｎｃｒｅａｓｅｄｅｖｅｎｔイベントは、イベントバス上の保留イベントの個数がしきい値より大きい場合に起動される。始めは、しきい値が最初にヒットすると起動し、次に負荷が間隔値だけ増大すると起動される。
【０４０４】
イベントバス上の保留イベントの個数がしきい値よりも大きくなった後、システムサービスによりＥＢＬｏａｄＩｎｃｒｅａｓｅｄ／Ｄｅｃｒｅａｓｅｄイベントの送信が開始する。イベントは、イベントの「間隔」数だけ負荷が変化すると発行される。しきい値のデフォルト値は１０００イベントである。間隔のデフォルト値は２００イベントである。ＥＢＬｏａｄＩｎｃｒｅａｓｅｄ／Ｄｅｃｒｅａｓｅｄイベントは、イベントバスに追加されないが、すぐに処理できるようにルールエンジンに直接入る。
【０４０５】
2004520641.tif 000119
【０４０６】
７．１．５  チャネルの確立−チャネルを作成する
ＣｒｅａｔｅＣｈａｎｎｅｌインターフェースは一方のモジュールと他方のモジュールとの間で交わされるメッセージのチャネルを作成する。チャネルは、イベントバスに送信されたメッセージがメッセージの所定の受け手のみが受信することを確実なものとするために使用される。
【０４０７】
ＣｒｅａｔｅＣｈａｎｎｅｌ（ ｔａｒｇｅｔＭｏｄｕｌｅ， ｃｈａｎｎｅｌＮａｍｅ， ）
【０４０８】
このイベントバスインターフェースを呼び出すアクティベーションルールスニペットは以下のとおりである。
【０４０９】
2004520641.tif 000120
【０４１０】
イベントバスは「ブロードキャスト」バスであり、アプリケーションによって供給されるルールがバス上のメッセージに対して起動する。チャネルは、通信先を決定するためのメカニズムである。このため、プライベートメッセージに対する詮索や不適切なルールの起動を防止できる。
【０４１１】
７．１．６  イベントバス管理ルール−しきい値の設定
ＥＢＬｏａｄＴｈｒｅｓｈｏｌｄ Ａｃｔｉｖａｔｉｏｎは、イベントバスの負荷しきい値を設定する。イベントバス上の保留イベントの個数がしきい値よりも大きくなった後、システムサービスによりＥＢＬｏａｄＩｎｃｒｅａｓｅｄ／Ｄｅｃｒｅａｓｅｄイベントの送信が開始する。イベントは、イベントの「間隔」数で負荷が変化すると発行される。しきい値のデフォルト値は１０００イベントである。ＥＢＬｏａｄＩｎｃｒｅａｓｅｄ／Ｄｅｃｒｅａｓｅｄイベントは、イベントバスに追加されないが、処理できるようにルールエンジンに直接入る。
【０４１２】
ＥＢＬｏａｄＴｈｒｅｓｈｏｌｄ（ｎｕｍＥｖｅｎｔｓ， ）
【０４１３】
しきい値の最小値はない。しきい値を負の値に設定しようとすると、アクティベーションは失敗し、ＯＤＩＫＲＮＬ＿Ｅ＿ＩＬＬＩＧＡＬＴＨＲＥＳＨＯＬＤＶＡＬＵＥが結果の値として返る。
【０４１４】
このアクティベーションにより、しきい値の値が１００イベントにリセットされる。
【０４１５】
2004520641.tif 000121
【０４１６】
このアクティベーションにアクセスできるように、このルールの左側にポリシーの適切な式を置く必要がある。
【０４１７】
７．１．７  構成ルール−接続を行う
このルールにより、Ｏｐｅｎ Ｄｅｓｉｇｎルータカーネルによって公開されているインターフェースＭａｋｅＣｏｎｎｅｃｔｉｏｎが呼び出される。
【０４１８】
2004520641.tif 000122
【０４１９】
アクティベーションのみがあるルールスニペットは以下のとおりである。
【０４２０】
2004520641.tif 000123
【０４２１】
管理者側でこのタイプのルールを用意し、非常に接続度の高い中央ノードが管理ドメイン内のすべてのＯｐｅｎ Ｄｅｓｉｇｎノードの設定済みピアの１つとなるようにできる。正しいアクセス権を持つエンティティのみがこのルールを起動させられるようにこのルールの左側を書く。
【０４２２】
８．０  Ｏｐｅｎ Ｄｅｓｉｇｎポリシーモデル
このセクションの目的は、プラットフォームでルールベースのポリシーの宣言および実行をサポートするためのメカニズムを説明することである。「ポリシー」は、ここでは、メッセージの内容に基づいて条件付きで適用されるシステムを通過するメッセージの処理を指す一般的な用語として使用している。この条件付きのポリシー適用は、システムとユーザの両方で定義したルールを通じて行う。
【０４２３】
このセクションで取り上げるのは以下のとおりである。
【０４２４】
・メッセージ状態の概念について説明する
・メッセージをさまざまな状態に進める方式
・このメカニズムでポリシールールを実装する方法。
・衝突するポリシーの問題と、システムが衝突を検出し処理するための設計の詳細。
・メッセージ処理シナリオの簡単な説明
【０４２５】
８．１  メッセージ状態
メッセージの寿命は一組の状態遷移としてモデル化され、メッセージがシステム内を通過するときにメッセージ上で行われる処理タイプを分割する。この寿命をモデル化するために定義されている状態の組をメッセージ状態と総称する。
【０４２６】
メッセージ状態は、その方向、つまりメッセージがアプリケーションにより発行され経路指定インフラストラクチャに向かい外に出る方向と、メッセージが回線から外れ、アプリケーションに向かって中へ入ってくる方向に基づく２つの補完的分類に分けられる。
【０４２７】
これらの経路のサブセットが使用可能である。たとえば、プロセッサとモジュールの間で発行されるノード内メッセージは、ｉｎ｜ａｐｐおよびｏｕｔ｜ａｐｐ以外の状態を通らずに遷移する。
【０４２８】
状態とその定義を以下に示す。これらは方向別に列挙されている。それぞれの方向においては、メッセージが遷移する順序で並べてある。
【０４２９】
入来：
ｉｎ｜ｗｉｒｅ：メッセージが回線から発信されたばかりである。物理的経路指定インフラストラクチャにより、宛先がそのノードであり、ルールエンジンにメッセージを導いたこととが判別される。
ｉｎ｜ｉｎｓｔｒｕｃｔｉｏｎｓ：メッセージが伝送する命令が処理される。
ｉｎ｜ｌｏｇｉｃａｌ ：メッセージの論理経路指定ヘッダが処理される。
ｉｎ｜ａｐｐ：処理のためメッセージがアプリケーションにディスパッチされる。
【０４３０】
送出：
ｏｕｔ｜ａｐｐ：メッセージがアプリケーションによって発行された。
ｏｕｔ｜ｌｏｇｉｃａｌ：メッセージを処理し、論理経路指定ヘッダを生成するようにできる。
ｏｕｔ｜ｉｎｓｔｒｕｃｔｉｏｎｓ ：メッセージを処理し、宛先で適切に処理させる命令を含むようにできる。
Ｏｕｔ｜ｗｉｒｅ ：メッセージは回線上にシリアライズできる状態にある。
【０４３１】
８．２  状態遷移メカニズム
状態遷移メカニズムを実装するには、ルールエンジン内でメッセージを表現するために使用するデータモデルにフィールドを追加する。このフィールドの目的は、メッセージの現在の状態にマークを付けることにある。システム内のメッセージは実際には、任意に長いパラメータリストを許容するようにデータモデル全体を使って表されるため、モデルのヘッダ構成要素のみがこのフィールドを伝送することができる。
【０４３２】
2004520641.tif 000124
【０４３３】
隣接する状態のペア毎に、たとえば、ｉｎ｜ｉｎｓｔｒｕｃｔｉｏｎからｉｎ｜ｌｏｇｉｃａｌへの移動が旧い状態にあるメッセージと突き合わせ、新しい状態に進める状態遷移ルールである。
【０４３４】
2004520641.tif 000125
【０４３５】
このルールは、メッセージ上の状態遷移に適切な影響を及ぼすが、ｉｎ｜ｉｎｓｔｒｕｃｔｉｏｎ状態を対象としたポリシールールの前に起動させることがあり、またポリシールール内の潜在的衝突を検出できないという２つの理由で不完全である。
【０４３６】
８．３  ポリシールール
ポリシールールは、システムとユーザが定義する。与えられたポリシールールは、特定のメッセージ状態を見て書かれる。一致するメッセージが与えられたときに実行できるアクションは、与えられた状態でサポートされている動詞により制限される。
【０４３７】
ポリシールールを宣言するために、以下を用意することができる。
−ポリシーを適用する状態。
−オプションで、ポリシーを適用する前にメッセージが満たす他の基準。
−その基準と一致しているメッセージが与えられた場合に実行するアクション。
−検出された衝突があった場合に実行するアクション。
【０４３８】
言語指定により、ポリシールールを実際にオーサリングし、インストールする仕組みを指定する。
【０４３９】
８．４  ポリシー衝突検出と処理
ポリシールールは、システムとエンドユーザの両方で定義する。さらに、複数の独立のエンドユーザポリシー作成者もありえる。互いに矛盾するポリシールール（つまり、一方のポリシーがメッセージを消費すると主張し、他方のメッセージが破棄すると主張する）もありえる。
【０４４０】
一般的には、与えられたメッセージ状態に対するポリシールール間の衝突は判別できない。むしろ、衝突はサポートされているメッセージ状態のサブセットで検出され、衝突が検出されると、メッセージが発行され、アプリケーションロジックによりさらに処理することができる。
【０４４１】
与えられた状態で衝突が検出されると、それ以降すべてのポリシーの適用は停止する。その代わりに、衝突が検出されたメッセージが発行され、そのペイロードはオフェンディングメッセージである。
【０４４２】
次の方式を使用して衝突を検出する。
【０４４３】
−状態遷移ルールに低特性値をタグとして付け、状態遷移ルールがアクティブになる前に旧い状態に対するポリシールールが起動することを確実にする。
−衝突を検出したい状態から次の状態へメッセージを移動するルールは、そのアクションに、ルールエンジンラッパオブジェクトによって維持されるアクションディスパッチキューをスキャンするコールアウトが含まれる。
【０４４４】
ポリシールールは状態遷移ルールよりも顕著なので、コールアウトが呼び出されるまで、アクションディスパッチキューにその段階に実行されるすべてのアクションが含まれることがわかっている。
【０４４５】
−コールアウトの実装では、矛盾する動詞に対してアクションディスパッチキューをスキャンする。動詞は、メッセージに対して実行する操作を参照する抽象的な手段である。
【０４４６】
衝突検出は、メッセージ状態のサブセットに制約される場合があり、それらの状態では、ある種の高水準アクションのみが実行を許される（転送、破棄、消費など）。
【０４４７】
−衝突が検出された場合（つまり、メッセージを消費する命令とメッセージを破棄する命令の両方に対するアクションが指定されている場合）、コールアウトは、ルールによって現在の状態からそこに置かれたすべてのアクションをアクションディスパッチキューから削除し、ペイロードとしてオフェンディングメッセージとともに新しい衝突検出メッセージを発行する。
−次にコールアウトは、ルールに偽を返し、ルールがメッセージを次の状態に進めないようにする。このメッセージに対するポリシーの処理および適用をさらに行うことを停止する。
【０４４８】
上のように指定した場合、状態遷移ルールの例は次のようになるであろう。
【０４４９】
2004520641.tif 000126
【０４５０】
ｄｅｔｅｃｔ−ｃｏｎｆｌｉｃｔｓ関数は、ルールエンジンにあるアクションの出キュー内を検索する際に使用するメッセージ状態をその第１引数として取る。ｄｅｔｅｃｔ−ｃｏｎｆｌｉｃｔｓ呼び出しの引数の残りは、相互排他的と考えられる動詞であり、したがってそれらの動詞のうち２つまたはそれ以上が出ルールエンジンキュー上にメッセージに対して実行するアクションとして出現する場合、衝突が生じる。
【０４５１】
ｄｅｔｅｃｔ−ｃｏｎｆｌｉｃｔｓ関数は、この場合、指定された状態のすべてのアクションを削除し、「ｃｏｎｆｌｉｃｔ−ｄｅｔｅｃｔｅｄ」メッセージを発行し、偽を返して状態遷移ルールの起動を防ぐ。
【０４５２】
ｄｅｔｅｃｔ−ｃｏｎｆｌｉｃｔｓの引数は、システム定義であるが、周知のものである。つまり、ポリシー作成者は衝突のないポリシーを作成できるだけの十分な知識を持つが、システムでは相互排他的な動詞を決定する。
【０４５３】
上の意味は、状態毎に、ポリシールールが書かれた際のメッセージに対して実行できるきちんと定義された「動詞」の組があるということである。
【０４５４】
メッセージ状態とその関連する動詞を以下に示す。
【０４５５】
ｉｎ−ｗｉｒｅ：破棄する
ｉｎ−ｉｎｓｔｒｕｃｔｉｏｎｓ：配信する、要求する、応答する、転送する、実行する
ｉｎ−ｌｏｇｉｃａｌ：破棄する、ディスパッチする
ｉｎ−ａｐｐ：破棄する、ディスパッチする
ｏｕｔ−ａｐｐ：破棄する
ｏｕｔ−ｌｏｇｉｃａｌ：破棄する、経路指定する
ｏｕｔ−ｉｎｓｔｒｕｃｔｉｏｎｓ：
ｏｕｔ−ｗｉｒｅ：破棄する、発行する
【０４５６】
８．５  シナリオ
システムを通る可能なメッセージ処理経路は次のとおりである。
【０４５７】
・ネットワークレイヤからモジュールまで
・モジュールからネットワークレイヤまで
・サービスからモジュールまで
・モジュールからサービスまで
・サービスから別のサービスまで
【０４５８】
モジュールとは、前述のように、一組のルールのことである。サービスとはここでは、サービスロジックを稼働する外部プロセスのことである。これは、Ｏｐｅｎ Ｄｅｓｉｇｎ ．ｒ言語で表されたサービスのロジックに加えられる。
【０４５９】
アプリケーションサービスルータは、処理経路内で、上記の要素の間の接続を提供する、つまりＯｐｅｎ Ｄｅｓｉｇｎメッセージがルータコアルールエンジンを「短絡し」、ルータによって課されているポリシーインフラストラクチャの外部と通信するためのメカニズムを用意しないのが好ましいということである。
【０４６０】
前記の内容から、本発明の特定の実施形態について例示のために本明細書で説明したが、本発明の範囲を逸脱することなくさまざまな修正を加えられることは理解されるであろう。したがって、本発明は特許請求の範囲で規定されている場合を除き制限されない。
【図面の簡単な説明】
【図１】
カーネルの機能を示すブロック図である。
【図２】
合わせてアプリケーション配備の一部となる５つのモジュールタイプを表すブロック図である。
【図３】
既存のサーバにインストールされているＯｐｅｎ Ｄｅｓｉｇｎプラットフォームの小規模な構成を示すブロック図である。
【図４】
可能な大規模な配備構成を表すブロック図である。
【図５】
配備ツール（「ＤＴ」）との対話操作を示すブロック図である。
【図６】
Ｏｐｅｎ Ｄｅｓｉｇｎアプリケーション開発で使用可能な配備要素のいくつかを表すブロック図である。
【図７】
アダプタ、アプリケーション、およびイベントバスの間の通信を示すブロック図である。
【図８】
ネットワークレイヤ、イベントバス、ルールエンジン、およびネットワーク上のネットワークレイヤのインスタンス間のプライベートコールの間の高水準の制御の流れを示す図である。
【図９】
Ｏｐｅｎ Ｄｅｓｉｇｎ Ｍｅｓｓａｇｅのアドレッシングレイヤを示すブロック図である。
【図１０】
ノードＡおよびＢ上で稼働されているアプリケーション間のノード間メッセージ交換に関わるすべてのアーキテクチャ要素を含むより完全な図である。
【図１】
2004520641.tif 000127
【図２】
2004520641.tif 000128
【図３】
2004520641.tif 000129
【図４】
2004520641.tif 000130
【図５】
2004520641.tif 000131
【図６】
2004520641.tif 000132
【図７】
2004520641.tif 000133
【図８】
2004520641.tif 000134
【図９】
2004520641.tif 000135
【図１０】
2004520641.tif 000136
【国際公開パンフレット】
2004520641.tif 000137
2004520641.tif 000138
2004520641.tif 000139
2004520641.tif 000140
2004520641.tif 000141
2004520641.tif 000142
2004520641.tif 000143
2004520641.tif 000144
2004520641.tif 000145
2004520641.tif 000146
2004520641.tif 000147
2004520641.tif 000148
2004520641.tif 000149
2004520641.tif 000150
2004520641.tif 000151
2004520641.tif 000152
2004520641.tif 000153
2004520641.tif 000154
2004520641.tif 000155
2004520641.tif 000156
2004520641.tif 000157
2004520641.tif 000158
2004520641.tif 000159
2004520641.tif 000160
2004520641.tif 000161
2004520641.tif 000162
2004520641.tif 000163
2004520641.tif 000164
2004520641.tif 000165
2004520641.tif 000166
2004520641.tif 000167
2004520641.tif 000168
2004520641.tif 000169
2004520641.tif 000170
2004520641.tif 000171
2004520641.tif 000172
2004520641.tif 000173
2004520641.tif 000174
2004520641.tif 000175
2004520641.tif 000176
2004520641.tif 000177
2004520641.tif 000178
2004520641.tif 000179
2004520641.tif 000180
2004520641.tif 000181
2004520641.tif 000182
2004520641.tif 000183
2004520641.tif 000184
2004520641.tif 000185
2004520641.tif 000186
2004520641.tif 000187
2004520641.tif 000188
2004520641.tif 000189
2004520641.tif 000190
2004520641.tif 000191
2004520641.tif 000192
2004520641.tif 000193
2004520641.tif 000194
2004520641.tif 000195
2004520641.tif 000196
2004520641.tif 000197
2004520641.tif 000198
2004520641.tif 000199
2004520641.tif 000200
2004520641.tif 000201
2004520641.tif 000202
2004520641.tif 000203
2004520641.tif 000204
2004520641.tif 000205
2004520641.tif 000206
2004520641.tif 000207
2004520641.tif 000208
2004520641.tif 000209
2004520641.tif 000210
2004520641.tif 000211
2004520641.tif 000212
2004520641.tif 000213
2004520641.tif 000214
2004520641.tif 000215
2004520641.tif 000216
2004520641.tif 000217
2004520641.tif 000218
2004520641.tif 000219
2004520641.tif 000220
2004520641.tif 000221
2004520641.tif 000222
2004520641.tif 000223
2004520641.tif 000224
2004520641.tif 000225
【国際公開パンフレット（コレクトバージョン）】
2004520641.tif 000226
2004520641.tif 000227
【国際調査報告】
2004520641.tif 000228
2004520641.tif 000229
2004520641.tif 000230