非同期呼び出し
前のブロック上のサブ要求は、いずれも完了するまでブロックされますが、これはそうしなければならないものではありません。複数のステップを1つの非同期パイプラインにまとめることができます。結果を返す代わりに、Futureオブジェクトハンドルに相当するものを取得します。これらのハンドルでjoinすることで、プロセス全体をブロックしながら、個々のサブ要求を並列的にスケジュールすることでCPUの能力を余すことなく利用することが可能になります（リスト1を参照）。
main()
{
// Create and issue the request, but do not block here
req = context.createSubRequest("active:httpGet");
req.addArgument("url", "http://www.funnydog.net/images/cocktail-kitten.jpg");
handle1 = context.issueAsyncSubRequest(req); // Note: issueAsyncSubRequest, not issueSubRequest
// Create and issue the request, but do not block here
req = context.createSubRequest("active:xslt");
req.addArgument("operator", "ffcpl:/devx/style.xsl");
req.addArgument("operand", "ffcpl:/devx/foo.xml");
handle2 = context.issueAsyncSubRequest(req);
// Block here until both results are done
output1 = handle1.join();
output2 = handle2.join();
System.out.println("DONE!");
resp = context.createResponseFrom(output2);
context.setResponse(resp);
}
Try it: http://localhost:8080/workbench/devx/asynch.bsh
この例では、画像は実際には取り出しが完了するまで使われず、まだHTTPで取得されます。適切なパイプラインを設ければエラーや例外もキャッチされますが、ここでは非同期呼び出しの連携が簡単に実現できることを示すことが目的なので、それは行っていません。
論理的な抽象化によってバックエンド処理の詳細な呼び出しの方法をすべて表現できますが、クライアントはこれらの詳細へのアクセスを禁止され、非同期または同期サブ要求の処理のタイミングを選ぶことだけができます。すべてを自分で管理する場合と比べて、この方法は大幅な単純化をもたらしますが、それだけでなくスケーラビリティも高まるようです。
ここで重要な点は、リソース指向環境でこれらの呼び出しを発行した結果が、不変的なリソース表現となることです。つまり、NetKernelは状態なし（stateless）の要求機構という側面を強く持ち、少しだけRESTのようであり、少しだけ関数型プログラミング言語のように見えます。オブジェクト指向プログラマがこうした考え方に慣れるまでは少し時間がかかりますが、それは非常に大きな利益をもたらします。
Javaの並列性に関する通常の構造を用いて同じことを実現できなくもありませんが、非常に理解しにくいものとなるでしょう。マイクロカーネルをベースとするアーキテクチャでURIによるアドレス指定が可能な動作を記述する方法は非常に強力です。異機種のバックエンドシステムに置かれた複数のデータソース（リレーショナルデータベース、Webサービスなど）を横断的にアクセスして非同期的な問い合わせを統合するようなことが簡単に実現できます。
