NetKernel は、RESTとUNIXの基本的な機能を、リソース指向コンピューティング(resource oriented computing, 略してROC)と呼ばれる強力な抽象概念に組み込んだソフトウェアシステムです。リソース指向コンピューティングの核は、情報(リソース)に対し、それを配信する物理的なメカニズム(コード)から論理的なリクエストを分離することにあります。ROCを使用して作られたアプリケーションは、コンパクト、シンプル、フレキシブルであり、他のアプローチと比べて少ないコード量で済みます。
Hello World!
リソース指向のシステムでは、リクエストはリソースに対して行われ、具体的で不変のリソース表現が返されます。これは、RESTやWorld Wide Webの原則にそのまま従っています。Webでは、http://www.1060research.com といったリソースに対するリクエストは、 Domain Name Service (DNS)によってエンドポイントのIPアドレスが決定されます。リクエストはそのIPアドレスに送信され、Webサーバーは具体的で不変のリソース表現が含まれるレスポンスを返します。同様にして、NetKernelでは、リソースのリクエストはアクセッサと呼ばれるエンドポイントが決められ、それは具体的で不変の表現を返します。NetKernelはJavaで実装されているので、最初の実例はJavaを使用したいと思います。しかしながら、後でJavaがサポートされている多くの言語の一つであるということを説明したいと思います。
リクエストは、決められたアクセッサであるprocessRequestメソッドによって配信されます。以下の例では、"Hello World"というメッセージを含んだ不変のStringAspectを生成し、それをレスポンスとして返しています。
public void processRequest(INKFConvenienceHelper context) throws Exception
{ IURAspect aspect = new StringAspect("Hello World");
INKFResponse response = context.createResponseFrom(aspect);
context.setResponse(response);
}
コンテキストオブジェクトはマイクロカーネルへのインターフェースであり、エンドポイントにより論理的なリクエストと物理的なコードの橋渡しをします。 processRequestメソッドは、論理的なリクエストであるURIがエンドポイントを決定したときに実行されます。URIリクエストがWebからのみもたらされるJava Servletとは異なり、NetKernelアクセッサが解決するURIリクエストは、その他のエンドポイントを含むどこからでも可能です。
サーブレットがさらなる情報を必要とするならば、例えばデータベースへJDBCアクセスを利用するときのように、サーブレットがその他のJavaオブジェクトに対するリファレンスを利用し、深いコールスタックを作ります。これがROCの始まりでありWebの終わりです。アクセッサは他のアクセッサへのメモリ参照を持ちません。追加情報を取得したり、他のソフトウェアサービスを呼び出すには、論理的なリソース空間にサブリクエストを発行します。
NetKernelでは、リソースはURIアドレスによって特定されます。先に述べたとおり、ちょうどWorld Wide Webのようなものです。
さて、Javaオブジェクトの物理的レベルから離れて、URIがどのように解決され、どのようにしてコードと動的に紐づくのかについて見ていきましょう。NetKernelは、モジュールアーキテクチャです。ソフトウェアリソースは、モジュールと呼ばれる物理的なコンテナにパッケージ化されます。デプロイのための物理的なパッケージとしてあるだけでなく、モジュールは、リソースのための論理的なアドレス空間や、実際のコードとの関係を決定します。モジュールは、自己完結した小さなworld-wide-webのようなものです。モジュール定義の以下のエントリは、論理アドレス"ffcpl:/helloworld"をアクセッサであるHelloWorldオブジェクトにマップします。
<ura>
<match>ffcpl:/helloworld</match>
<class>org.ten60.netkernel.tutorial.HelloWorld</class>
</ura>
リクエストとエンドポイントの間のバインディングは、リクエストが決定されたときだけ発生します。一度アクセッサが完了すると、その関係は切り離されます。これは、バインディングを一度作ると永続的なものとなるJavaやその他の言語とは異なるところです。このダイナミックな論理バインディングは、実行時に再設定が可能な、非常に柔軟性のあるシステムをもたらします。
論理アドレス空間において、私たちは新しい自由度を持ちます。私たちは、論理的なものから論理的なものへ、論理的なものから物理的なものへ(上述したように)、もしくは、あるアドレス空間から他のアドレス空間へリクエストをマップすることができます。以下のrewriteタグのルールは、リクエストの URIを別のURIへ変更するために、正規表現を適用することができるということを示しています。つまり、このルールによる効果は、"ffcpl: /tutorial/helloworld" から "ffcpl:/helloworld" のようなリクエストをマップすることを意味しています。
<rewrite>
<from>ffcpl:/tutorial/(.*)</from>
<to>ffcpl:/$1</to>
</rewrite>
モジュールは、カプセル化されたプライベートな論理アドレス空間です。モジュールは、他のモジュールによってインポートすることが可能なパブリックなアドレス空間をエクスポートするかもしれません。以下の例では、モジュールがパブリックなアドレス空間"ffcpl:/tutorial/.*"をエクスポートし、tutorial のパス配下に位置する全てのリソースに適用されることを示しています。
<export>
<uri>ffcpl:/tutorial/(.*)</uri>
</export>
これまで、私たちはリクエストがどこから来るかについて、考えていませんでした。最初の出発点なしでは、システムで何も起きないでしょう。トランスポートとは、(外部の)イベントを見つけるエンドポイントです。トランスポートがイベントを見つけると、論理的なアドレス空間にルートリクエストを生成・発行し、処理のために配置、バインド、スケジュールされたエンドポイントを待って、表現を返します。モジュールはどんなトランスポートもホストし、それぞれのトランスポートはルートリクエストからホストしているモジュールへとインジェクトされます。例えば、HTTPトランスポートは、HTTPリクエストの到着を検知し、対応する内部NetKernelのルートリクエストを生成・発行します。以下の図では、HTTPリクエストがNetKernelリクエストに変換され、HelloWorldのアクセッサクラスにたどり着くまでの経緯を示しています。
http://localhost:8080/tutorial/helloworld (at the transport)
|
v
ffcpl:/tutorial/helloworld (request issued by transport)
|
v
ffcpl:/tutorial/helloworld (request that enters our module)
|
v
ffcpl:/helloworld (after rewrite rule)
|
v
org.ten60.netkernel.tutorial.HelloWorld (Physical Accessor code)
Hello Worldリソースに由来するリクエストの方法を指示したシステムはありません。そのアドレス空間は、同時にHTTP、JMS、SMTP、LDAPに接続することができます。そして、外部アプリケーションプロトコル、もしくは私たちのソフトウェアアーキテクチャの他のレイヤーにさえ、名前をつけることができます。NetKernelシステムのそれぞれのモジュールは、自己完結し、カプセル化されたリソース指向のサブシステムなのです。
アドレスとアドレス空間
NetKernelでは、モジュールはプライベートなアドレス空間を決定します。プライベートなアドレス空間では、3つのことが起こります。:
- 論理的なアドレスから論理的なアドレスへのマップ
- 論理的なアドレスから物理的なエンドポイントへのマップ
- 他のモジュールから論理的なアドレス空間をインポートする
これら3つの主要な関係によって、レイヤーアーキテクチャやチャネルアーキテクチャを手際よく作ることができます。これらの関係がダイナミックであるので、アーキテクチャそのものもダイナミックに作成することができます。下記の図は、典型的なNetKernelアプリケーションの高度な考え方を表しています。トランスポートは、ホスティングモジュールのプライベートアドレス空間にルートリクエストを発行します。そして、NetKernelはリクエストを処理するエンドポイントを検索します。例では、ホスティングしているモジュールがモジュール「A」、「B」、「C」をインポートしています。各々は、モジュールのプライベートアドレス空間をホストするために、パブリックアドレス空間を加えます。具体的には、ffcpl:/accounting/.*, ffcpl:/payroll/.*, ffcpl:/crm/.*です。
この例で、ルートリクエストがffcpl:/crm/contactsのURIに対して発行されるのであれば、それはエクスポートされたモジュール「C」のアドレス空間にマッチし、リクエストがモジュールに送信されます。そして、最終的にはffcpl:/crm/contactsに対するリクエストを実行することのできる物理的なコードが決定されます。おそらく、JDBCコネクションといった物理的なオブジェクトが利用されるか、より一般的には、モジュール「C」の範囲内で利用可能な論理的なリレーショナルデータベースサービスのサブリクエストを発行することになるでしょう。
アクセッサ
次に、私たちは物理的なレベルへ戻り、アクセッサについてより深く見ていきます。今まで見てきたように、アクセッサはリソース表現を返すエンドポイントです。アクセッサそれ自身は、非常に単純です。それは、4つのことを行います。
- 何のリソースがリクエストされているのかを解釈する(つまり、初めのリクエストを調べる)
- (同期・非同期リクエストによる)追加情報に対するサブリクエストを生成・発行する
- サービスを実行することで価値を生み出す(つまり、何かをするということ)
- 不変の物理的なリソース表現を生成し、返却する
アクセッサは、その内容からそれが何をするよう頼まれているかについて判断します。リクエストURIは、指定されたパラメータの値と同様にして取得することができます。アクセッサは、複数のアドレスが単一のエンドポイントにマップされている場合に、どのURIが現在のリクエストで使用されているのかを知る必要があるかもしれません。物理的/論理的な分離により、1つのコードで複数の論理的なロケーションをマップすることができます。
サービスは、指定したパラメータ active: URIスキームを使用して呼び出します。アクティブスキームは、以下の形式をとります。
active:{service-name}+{parameter-name}@{uri-address}
各々のアクティブURIは、1つのサービスと複数のパラメータを指定します。例えば、toUpper サービスは、operand というパラメータをとり、引数で指定されたURIによって特定されるリソースを大文字に変換して返します。
active:toUpper+operand@ffcpl:/resources/message.txt
以下のBeanShellスクリプトは、toUpper サービスを実装しています。sourceAspect メソッドの引数に、URI this:param:operandを渡して、"operand"リソースに対する不変な表現を取得します。リクエスト呼び出しをするために、コンテキストオブジェクトを使用することができます。パラメータで指定された"operand"を探し、そのURIを取得してそのリソースに対するサブリクエストを発行します。NetKernelの基本 APIの代わりに、リクエストの引数に対するローカルの内部論理アドレス空間を提供します。this:param:operandのURIをリクエストすることで、オペランドポインタを効果的に修飾参照することを要求しています。
import org.ten60.netkernel.layer1.representation.*;
import com.ten60.netkernel.urii.aspect.*;
void main()
{
sa=context.sourceAspect("this:param:operand",IAspectString.class);
s=sa.getString();
sa=new StringAspect(s.toUpperCase());
resp=context.createResponseFrom(sa);
resp.setMimeType("text/plain");
context.setResponse(resp);
}
このスクリプトでは、IAspectStringインターフェースの実装として返されたオペランドリソースを必要としていることが分かります。しかし、論理的レベルでは、コードが物理的なレベルの型を認識していません。これは、トランスリプリゼンテーションと呼ばれる新しい概念です。クライアントがエンドポイントを提供しない表現型をリクエストする場合、マイクロカーネルが仲介役となります。不整合が見つかると、マイクロカーネルがある型から別の型へと変換するトランスレプターを探します。
トランスレプターは非常に便利であることが分かります。概念的には、トランスレプターがある物理的形式から別の形式へ情報を変換します。これは、コンピュータ処理を含む多くのものをカバーします。
- オブジェクトタイプの変換
- オブジェクト構造の変換
- パース
- コンパイル
- シリアライズ
重要なポイントは、これが損失の無い変換であり、物理的な表現が変更されるまで情報が保存されます。トランスレプターは、開発者が重要であるもの(情報)に注力することができる論理的なレベルから、物理的なレベルの詳細を隠蔽することによる複雑さの低減を支援します。例えば、active:xsltのサービスは、DOMとして情報をリクエストします。そして、論理レベルで作業している開発者はリソース参照を提供し、その物理レベルでの表現はXMLを含むテキストファイルです。NetKernelでは、テキストベースのXML表現からDOM表現へとトランスレプト(解析)することのできるトランスレプターを自動的に検索します。トランスレプトにおけるアーキテクチャと設計の重要性は、型を分離してアプリケーションとシステムの柔軟性を強化することにあります。
加えて、トランスレプトにより、システムで非効率な形式から効率的に処理できる形式へと情報を変換することができます(例えば、ソースコードからバイトコード)。これらの変換はしばしば発生しますが、一回の変換コストで済むので、以降は効率的な形式で取得することができます。正確には、トランスレプトがリソースからエントロピーを削除します。
リソースモデル
私たちは、論理的レベルURIアドレスが物理的レベルのエンドポイントに決定づけられ、それがバインドして処理されるまでの仕組みについて見てきました。また、型のような物理的レベルでの関心事を物理的レベルに隔離することができることも見てきました。さらには、サービスがパラメータ指定で呼び出すことができ、全てがURIアドレスとしてエンコードされることも見てきました。
リソースモデルという考えに至ることで、物理的リソース表現型(オブジェクトモデル)のコレクションや関連するサービス(アクセッサ)が、特定の情報形式にまつわるツールを一緒に提供します。例えば、バイナリストリーム、XMLドキュメント、RDFグラフ、SQLステートメントや結果セット、イメージ、JMSメッセージ、 SOAPメッセージなどです。リソースモデルの考えにより、開発者が一つもしくは複数のリソースモデルの組み合わせでコンポジットアプリケーションを構築することができ、ソリューションとして特定の再利用可能なツールをさっとつなげられるUNIXの考えを持っています。
イメージリソースモデルは、imageCrop, imageRotate, imageDither などといったサービスを含んでいます。イメージリソースモデルを使用することで、開発者がイメージプロセスのパイプラインを作ることができ、以下のような簡単なリクエストになります。
active:imageCrop+operator@ffcpl:/crop.xml+operand@http://1060research.com/images/logo.png
NetKernel のXML リソースモデルは、言語変換、いくつかのバリデーション言語、その他多くのXML技術を含んでいます。このような、XMLリソースモデルの特化として、ATOMやRSS、多くの簡単なフィード処理をサポートするPiNKYフィード処理ツールキットがあり、それはXMLリソースモデルと100%下位互換です。トランスレプターにより、開発者はXMLリソースが実際にDOMであるのかSAXストリームであるのか、あるいはいくつかの表現型の一つなのかを知る必要がありません。XMLリソースモデルを使用することで、開発者はXML処理のシステムを迅速に構築することができます。例えば、以下のリクエストは、ffcpl:/style.xslのスタイルシートリソースをもったffcpl:/data.xml リソースを変換するために、XSLTサービスを使用しています。
active:xslt+operator@ffcpl:/style.xsl+operand@ffcpl:/data.xml
順序付け
リソースリクエストのURIは、本来、リソース指向コンピューティングモデルにおける「演算コード」です。Javaのバイトコードのように、一般的には非常に低レベルのものであり、手でコーディングするのは困難でしょう。その代わりに、これらのリクエストを決定・発行するための数多くのスクリプト言語を使用することができます。先に見てきたコンテキストオブジェクトは、一貫したPOSIXの例であり、NetKernelの基本APIと呼ばれるマイクロカーネルまわりの抽象概念のようなものです。このAPIは、サポートされている全ての動的な手続き言語で利用可能です。加えて、専門の宣言型言語が提供されており、その目的は、専らソースリクエストの決定と発行のためにあります。
そのようなスクリプト言語の一つに、DPML(XML構文を使用する簡単な言語)があります。何故XML構文を使用するのか？それは、他のものと同様にコードがリソースとなる動的な疎結合システムであるので、動的にコードを生み出すプロセスを作成することが非常に簡単です。加えて、XML構文は、コード生成のための簡単な出力形式です。DPMLの効果を発揮するために、下記では、前節で見られるような同じXSLT変換を行っています。それぞれの "instr"が、アクティブにやりとりをします。URIリクエストとそれぞれの"target"は、他のリソースへの指示となります。URI this:response は、スクリプトによって返されるリソースを示すための決まりとして利用されています。
<instr>
<type>xslt</type>
<operator>ffcpl:/style.xsl</operator>
<operand>ffcpl:/data.xml</operand>
<target>this:response</target>
</instr>
この基盤から、2つのリクエストにおいてデータベースからHTMLページを作成する以下のDPMLプログラムを解釈することは容易です。
<idoc>
<instr>
<type>sqlQuery</type>
<operand><sql>SELECT * from customers;</sql></operand>
<target>var:result</target>
</instr>
<instr>
<type>xslt</type>
<operand>var:result</operand>
<operator>ffcpl:/stylepage.xsl</operator>
<target>this:response</target>
</instr>
</idoc>
NetKernelでは、言語ランタイムはサービスです。他のサービスと同様に、それらはステートレスで、プログラムコードが状態として遷移されるときにプログラムの実行を行います。これは、情報を容易にするために言語があるのではなく、言語が情報の前にあるという、従来の物理レベルのソフトウェアの観点とかなり異なるものです。例えば、Groovy言語のランタイムサービスを使用することで、以下のリクエストは、リクエストに対する状態としてのプログラムを含むffcpl:/myprogram.gy リソースを提供します。
active:groovy+operator@ffcpl:/myprogram.gy
NetKernel は、BeanShell、Groovy、Ruby、JavaScript、Python、XQueryのようなDPML XML言語、そして、もちろん動的コンパイルされたJavaを含め、広範囲にわたる言語をサポートします。Java仮想マシンで動く言語であればなんでも、ワークフローエンジンのようなカスタム言語を含め、NetKernelに統合することができます。
パターン
ROC(リソース指向コンピューティング)には、論理的レベルでのアーキテクチャデザインパターンの新しいセットがあります。MapperとGateKeeper、2つの例を見てみましょう。
Mapperパターンは、リソースリクエストの無数の集合を単一の物理コード1点にまとめるように指示するための方法です。このパターンでは、ある領域のリソースに対するリクエストが実際のコードにマップされ、そのコードはそれぞれのリクエストをマップされたアドレス空間に解釈し再発行します。2つめにマップされたリクエストに対するレスポンスは、マッパーによって初めのリクエストの結果として返されます。
このパターンには様々なものがあり、active:mapperを呼んだあるサービスが、アドレス空間の中のルーティングマップを含んだリソースを使用します。もう一つの例はゲートキーパーで、アドレス空間にある全てのリクエストに対してアクセス制御を提供するのに使用します。リクエストを有効にするためのきちんとした証明書が利用できるときのみ、ゲートキーパーはリクエストを許可します。
様々なマッパーパターンの全てが、全てのアプリケーションアドレス空間上で透過的にレイヤー化されています。このパターンの他の利用法として、監査、ログ、セマンティックな妥当性確認、構造的な妥当性確認、その他の適切な制約などがあります。このパターン特有の長所は、アーキテクチャデザインに影響を与えずにアプリケーションに導入できるところです。
NetKernelでのソフトウェア間の関係が、論理的に結ばれて動的に決定されるので、リクエストのインターセプトと変換は、実に自然なモデルと言えます。AOPのような専門的な物理レベルの技術で手に入れられる機能の全てを、論理アドレス空間が、非常にきれいな方法で提示しているのです。
アプリケーション開発
ROCを使用したアプリケーション開発は、非常に単純です。新しいリソースモデルといった新たな物理レベルの機能が必要なら、アクセッサ、トランスレプターなどが必要ですが、それらは構築されています。次に、論理レベルでは、アプリケーションはリソースを特定し集計することで作成されます。最後に、リクエスト制限、セキュリティゲートキーパー、データの妥当性確認といった制約が適用されます。
ROC における3つの"C"があります。それは、「construct(構築)」、「compose(作成)」、「constrain(制約)」の順に適用されます。この順番は、変更の目的で逆にすることができます。つまり、制約は作成したアプリケーションを明確にし、変化を許容しながら向上させることができます。そして、その後で制約を再度適用することができます。これは、制約が先に考慮されるオブジェクト指向プログラミングとは異なります。本質的に、クラスはオブジェクトの利用に関し制約を強要します。それ故、その情報が含まれるのです。実際のオブジェクト指向システムでの情報構造を変更するには、再コンパイル、配布、システムの再起動等、ちょっとしたイベントが必要となります。それらすべてが、NetKernelシステムでは不要です。論理的なシステムの柔軟性と比較すると、物理レベルのオブジェクト指向システムは脆く見えます。
アプリケーションアーキテクチャ
物理的レベルでの技術で設計されたシステムは、通常はアーキテクチャの様々なレベルで変更可能なオブジェクトとなっています。例えば、Hibernate のようなORマッピング技術は、RDBMSによって管理される永続化ストアに適合するようなオブジェクトのレイヤーを作るために存在しています。そのような設計の場合、更新はオブジェクトに適用され、リレーショナルデータベースへ変更を反映するのはマッピングしているレイヤーの責任となります。
ROCでは、全ての表現は不変です。このことから、すぐに2つのアーキテクチャ上の結論が導かれます。まず初めに、不変なオブジェクトのキャッシュは、パフォーマンスを劇的に改善させます(これについては、後述します)。次に、不変なオブジェクトは更新されてはなりません。つまり、それらは無効化され再度リクエストされるべきなのです。
ROCで実装することのできる多くの有効なアプリケーションアーキテクチャがあるので、データチャネルアプローチは、普通に見られます。同様にして、この設計では、アプリケーションは論理的にレイヤー化されたアドレス空間が作成され、これらのレイヤーを通過したものは、アプリケーション情報に対して別々の読み込みチャネルと書き込みチャネルとなります。これらのチャネルとして、例えばffcpl:/customers や ffcpl:/register-user といったアドレスを持つでしょう。
下記の図の中で、インテグレーションレイヤーは、情報の形式を異なるソースから共通の構造へと変換します。読み込み情報チャネルは、ffcpl:/customers といったリソースをサポートし、目的の情報表現を返します。ffcpl:/register-user のような書き込みチャネルのURIアドレスサービスは、2つのことを行います。まず、永続化ストレージを更新し、更新情報に関連するリソース表現のキャッシュ全てを無効にします。ORマッピングアプローチ(例えば、Hibernate)を利用する開発者にとって、このことはとても奇妙に感じられるかもしれません。しかし実際は単純で、エレガントかつハイパフォーマンスのソリューションなのです。
パフォーマンス
そろそろ、ROCシステムが実際の作業よりも抽象概念を考える時間に費やしていることについて考える必要があります。しかしながら、直感的に重要であるのは、ROCの抽象概念が大きなパフォーマンスの利点を生んでいる点です。
キャッシュ
全てのリソースがURIアドレスによって特定され、リソースのリクエスト結果が不変なリソース表現であるので、算出された全てのリソースはURIアドレスをキャッシュキーとしてキャッシュすることができます。算出されたリソースに加えて、NetKernelのキャッシュはリソース依存情報に関するメタ情報や、算出されたキャッシュエントリーのそれぞれのコストを格納します。依存情報を使用することで、キャッシュされたリソースが有効である限り、それに依存する全てのリソースもまた有効であることが保証されます。リソースが無効になったときは、キャッシュされた表現と、それに依存する全てのリソース表現が自動的に無効になります。
NetKernelは、格納された算出コスト情報を、リソースの動的な最適化集合を保持するために使用します。キャッシュから取り出されているならば、システムの現在のワーキングセットの中にあるリソースが、再算出のコストと利用頻度によって有効であると判断されます。オペレーショナルシステムからの経験に基づく証跡では、通常のビジネスアプリケーションにおいて、一般的には、リソースリクエストの30%から50%がキャッシュから利用されます。読み込みがほとんどであるアプリケーションでは、擬似的な静的パフォーマンスで動的なシステムとすることで、100%近くまで上がることがあります。さらには、システムの特性に応じて、ロードやキャッシュの再調整、現在最も有効であるリソースの保持を行います。
CPUコアによるスケール
導入で述べたように、ROCの本質は物理的な実装から論理的な情報プロセスを分離することにあります。論理的なリクエストに対するそれぞれのリクエストは、結局のところ実行するために物理的なスレッドに割り当てられます。ROCシステムを実装しているマイクロカーネルは、それぞれの論理的なリクエストを実行するために利用可能なスレッドを繰り返しスケジューリングすることで、コンピュータのハード機能を最適に活用することができます。基本的には、論理的な情報システムは利用可能なCPUコアによってロードバランスされます。
非同期性
ROC は、元来、非同期です。NetKernelの基本APIは、一見同期モデルのように見えますが、実際はマイクロカーネルが内部で全てのリクエストを非同期でスケジュールします。従って、幅広いマルチコアのアーキテクチャを通じて、アプリケーションのスケーラビリティを透過的に得られるにも関わらず、開発者は、シーケンシャルな同期コードによる明快なロジックを考えれば良いのです。
加えて、アクセッサに対しスレッドセーフであるかどうかを明示的に示し、それが並列のリクエストをスケジュールできるかどうかをマイクロカーネルに伝えることができます。これにより、ライブラリの採用と統合や、予測不能な結果の恐れなくサードパーティの貢献が可能です。
まとめ
NetKernelは、根本的に異なるものです。それは、別の技術スタックを作るためではなく、中心となる原則(Web、UNIX、集合理論など)のシンプルなセットを得て、それらをひとまとまりの情報処理システムへ外挿するためにあります。実際、NetKernelの起源は、「Webの実用的な特性を、きめ細かいソフトウェアシステムの特性に移行することができるか？」という問いから始まっています。
NetKernel は、ヒューレットパッカード研究所を皮切りに、法人のエンタープライズアーキテクチャや次世代プラットフォームとして重要なWebインフラストラクチャ (Purl.org)に至るまで、約8年に渡って鍛えられた製品となりました。NetKernelは、非常に用途が広いものであることが分かっていて、他のアプリケーションと同じくらい容易に、データ統合、メッセージ処理、Web/Eメールのインターネットアプリケーションなどに適用することができます。
参考
- 1060 Research (サイト・英語)
- リソース指向コンピューティングのホワイトペーパー: http://www.1060research.com/netkernel/whitepapers/ (英語)
- NetKernel ダウンロード (サイト・英語)