ちょっと重くてUI不要な処理を、複数のPCで同時に実行させたい、と考えたのが、今回の事件の発端でした。

複数で同時に実行と言っても、それぞれ独立した処理の単位でおまけに協調動作も不要なので、グリッドコンピューティングとかP2Pとかそんな洗練されたシロモノではありません。要は、複数の処理の実行依頼を発行するClient役と、その依頼を待機して処理を実行するServer役を作ればいいのです。
で、流暢ではないし、かなり訛っているかもしれませんが、何とか読み書きできる唯一の言語なので、いつもの通り、Javaで書くことにしました。JVMを超えて起動する方法にはRMIとかもあるのでしょうが、EJBコンテナとかは使わずに済ませたいので、単純にネットワークプログラミングすることにしました。さらに、実行する処理は重くってトロいはずなので、Server役では、処理受付と処理実行のスレッドを分けようとか、生意気にも考えてみました。
そう構想しただけで、プログラミング初級者の私には緊張感が走ります。だって、ネットワーク、マルチスレッド、ですよ！ 高橋麻奈著「やさしいJava」の表紙を開いたのはつい昨日のことのようなのに、随分と遠くまで来たものだなあ、とここまでの軌跡を振り返りたくもなるというものです。

さて、そんな感慨はともかく。

ネットワークプログラミングとかいいながら、できるだけ高レベルなAPIで済ませたいと考えるのが怠け者の習性です。でも、適当なライブラリを探し出したり、その使い方を習得したり、それなりに大変です。もしかしたら、怠け者の習性、ではなくて、自分の腕に自信のない者の習性かもしれません。腕に覚えがあれば、さっさと自分で必要なものを作ればいいのですから。
さて、そんな繰言はともかく。

なにしろ、怠け者で自信のない私は、Apache MINAを使うことにしたのです。
MINAでは、ネットワークイベントのハンドラーを作成し、MINAが提供するServiceオブジェクト(呼び出される側)やIoConnectionオブジェクト(呼び出す側)にハンドラーをバインドすることによって、後はイベントドリブン的にMINAが面倒見てくれます。特に本来的な連携内容は、serializableなオブジェクトをIoSessionという通信オブジェクトへのwriteとrecieveイベントを通して実現することとなります。なので、本来のビジネスロジックをネットワークの低レベルな処理とは独立した形で実装し易いらしいのです。
ずいぶんと簡単そうです、簡単なはずだったのですが...結構、試行錯誤してしまいました。最大の陥穽は、sessionCreateの後に連続して起こるように説明されていたsessionOpenというイベントが起こらず、どこで最初のメッセージ用のオブジェクトを書き込めばいいかわからなかったことでした。結果的に、イベントハンドラ内ではなく、IoConnectionを作成する呼出側の主役で、IoSessionを取得してそのままメッセージをwriteすればよかったのでした。

それはそうと、今回の作業の前に大急ぎで、結城浩著「Java言語で学ぶデザインパターン入門 マルチスレッド編」を読みました。マルチスレッドという迷宮に踏み込む際の護符とか呪文を手に入れるようなつもりで。
実際の今回のプログラミングは、デザインパターンを意識する程のレベルではありませんでした。ただ、MINAのクラスの中でconnectFutureとかwriteFutureとかあって使うことになった際に、お、これはFutureパターンなんだな、とか把握できて、呪文もまんざら捨てたものではなかったのでした。
やっぱり、先人の知恵は重要だし、共通理解のためのイディオムの習得は大切なんだなと思えた、ちょっと教訓めいた話でした(!?)