NetKernelの概要
1060 Research Ltd.が開発したNetKernelは、これらの問題の一部を解決し、マルチCPUをシームレスに利用し、そして論理的に結合された階層的なアプリケーションを作成するために役立つURIベースのマイクロカーネル環境です。NetKernelはオープンソースと商用開発の両方を可能にするデュアルライセンスを持ちます。
本稿では、NetKernelによって並行性の高いシステムが簡単に開発できることを中心に説明します。NetKernelのリソース指向方式の全貌を説明することは本稿の範囲を超えます。さらに興味のある方は、NetKernelについての詳しい解説を読むことを強くお勧めします。
NetKernelのマジックは、入念に設計されたマイクロカーネルアーキテクチャから始まります。これは「実」作業を10MBのVM内で処理できる効率の高い環境です（実際、本格的な多くのNetKernelアプリケーションが64MB以下で動作します！）。標準状態でNetKernelは一握りのスレッドしか使いませんが、実際の環境がもっと多くのスレッドを要求していれば、これを調整することもできます。
要求はトランスポート（通常はHTTPで、それ以外のものも可能）を通じて送られてきます。そして、いずれかのマイクロカーネルスレッドで非同期的に実行されるようにスケジュールされます。この点は重要です。あらゆるものは最終的に同じ方法、すなわち非同期的にスケジュールされます。簡便化のために、この非同期バックエンドは同期パターンによってラップされます。NetKernelのスケーラビリティを実現する上で、ここがポイントとなります。送られてくるすべての要求は、こちらの意図とは無関係に異なるカーネルスレッドに渡されます。後に説明するように、この動作を制御することもできますが、この環境は既に統制されたCPU利用の見通しの下で強制されています。アプリケーションが同じであれば、大抵はCPUの処理能力を自動的に余すことなく利用するようになるため、何かを明示的に行うことは必要ありません。
NetKernel内のすべてのものはURIでアドレス指定できます。ファイル、特定の機能など、あらゆるものがその対象となります。内部的にNetKernelは一定のURIスキームを使用して動作を参照します（これをアクティブURIと呼びます）。ディスク上のファイルなどを参照するためのデータURIもあります。ディスクからファイルを取り出したいときは、そのURIを要求するだけで済みます。
また、何らかのXSLT処理を起動したいときは、XSLT要求に応答する機構（active:xslt）で要求が実行されるようにスケジュールします。この処理の背後には、このURIをアドバタイズするモジュールが存在します。それに対して、指定した入力の変換を行うよう要求されます。変換で実際に何が使われるか気にする必要はありませんが、信頼性の高いJava XML変換ライブラリのSaxonが使われます。
多くの場合、既存のコードは論理的なURIでラップできます。コードによっては、起動時にオブジェクトのインスタンスを直接生成したりインスタンスに情報を送ったりしなくてよいことがあります。このとき実装技術を切り替えることにすれば、クライアントからのケアは不要になります。Javaのインターフェースでもこれと同じような柔軟性を実現することは可能ですが、この方式の方が論理的な名前だけを使うためにずっと明解で簡単です。これはJava開発者がリソース指向の環境を目にしたとき躊躇する点の1つですが、それをいったん乗り越えると、以前の思考方法に戻ることはなかなか難しくなります。
NetKernelに何かを実行するよう依頼するときは、サブ要求を作成し、それを実行するよう依頼します。これはクライアントから見たとき、最終的に舞台裏のマイクロカーネルスレッドで実行されますが、それは活動が完了するまでブロックされます。これは特に指定しない限りコードが動作することを多くの開発者が望むからです。NetKernel自体はJavaで書かれていますが、リソース指向の抽象化を用いて動作を呼び出します。JVM上で稼働する主要なほとんどの言語を用いて、モジュールを実装したりクライアントコードを書いたりすることが自由にできます（例えば、Java、JavaScript、Groovy、Python、Ruby、BeanShellを使用でき、さらにScalaとClojureも対象となりつつあります）。
「サンプルの実行」と「BeanShell」については、次章を参照ください。
