■

歯が痛むので、気晴らしにプログラムを書いている。書いているのは、例によって「みるく」。最近、開発コード名を変更して、「GraphSim_Milk」になったが。
みるくは当初の理想とは大きくかけ離れて、GraphSim2をベースにいろいろな修正が入ったバージョンにすることにした。ようするに、開発にかける時間が学生のときに比べて殆んどなくなってしまったから、使える資産は使おうという方針。といっても、コードそのものは、かなり書き直しが多いけど。
みるくは、大きく３つのパッケージから構成される。一つ目は、graphパッケージ。これは、グラフ構造を表現するためのライブラリに近いパッケージになる。二つ目は、coreパッケージ。これは、みるくの動作モデルを表現するためのパッケージ。三つ目は、componentパッケージ。これは、みるくで使用できるいろいろなクラスを寄せ集めたもの。
GraphSim2とみるくの違いは次のとおり。
GraphSim2では、graphパッケージとcoreパッケージの間に循環する依存関係が存在していた。みるくでは、coreパッケージがgraphパッケージを利用するだけで、graphパッケージそのものはcoreパッケージには依存しないように、がんばってgraphパッケージを構築している。
GraphSim2では、各種コンポーネントがあるクラスのサブクラスとして定義されることが多かったが、みるくでは、それを止める方向で設計している。具体的には、入出力メソッドやポート管理を専用のオブジェクト『Context』に全部押し込めて、モジュールは実行時にメソッドの引数に渡されるContextインスタンスのメソッドを呼ぶことで、入出力やポート、チャネル管理を行うようにした。こうすることで、モジュールそのものには、余計にメソッドを定義する必要がなくなり、POJOに近くなった。ただし、これでは本来のみるくが目指していた理想とは大分かけ離れてしまうため、もう一つ上のレイヤーも用意することにした。気持ちとしては、他のシステムとやりとりをおこなうコンポーネントは低いレイヤーで実装し、通常のコンポーネントは高いレイヤーで実装するというスタイルにしたい。この辺は、JBIのバインディングコンポーネントと、もう一つのコンポーネントみたいな関係。
GraphSim2では、全てのコンポーネントがマルチスレッド環境下で、非同期で実行されていた。みるくでは、コンポーネントの実行にシングルスレッドを用いるかマルチスレッドを用いるかを区別できるようにした。これにより、コンテキストスイッチによるスケーラビリティの低下や性能低下を防ぐことが出来るようになった。また、遅延評価を実現するためのスケジューリングアルゴリズムを導入することで、不必要なコンポーネントの実行は行わなくて済むようになった。ただし、判別のためのメソッドを新たに定義しなければならなくなり、コンポーネント作成のために定義しなければならないメソッド数が増えた。
GraphSim2では、コンポーネント間の通信は、全て一方向の非同期通信であったが、みるくでは、同期通信や双方向通信もサポートすることにした。これで、他のミドルウェアとの親和性が高くなるんじゃないかと考えている。
目指すところはメッセージ指向アプリケーション開発運用プラットホームで、主にクライアントサイドをターゲットにするといったところ。ただし、稼動があればの話だけど。
（追伸）
最近、SOAっていうキーワードがもてはやされてる。それで、自分なりにGraphSimをSOAフレームワークにしてみようと考えた結果が、みるくという形になると思う。
昔は、データフロー処理は一度は死に絶えかけたモデルだけど、絶対に将来もう一度ハヤルと思ってた時期があった。だけど最近は考えを変えて、小さなスレッドを大量に作成して、スレッド間で通信をしながらプログラムが動作するというプログラミングモデルがハヤルんじゃないかなと思い出した。だって、世間的にはスレッドのスループット向上を目指したマルチコアなＣＰＵがトレンドでしょ。行き着く先は、マルチコアからシンプルなコアを大量に並べたメニーコアになるんじゃないかなあと考えて、マルチスレッド→メッセージ指向マイクロスレッドプログラミングなんて単語が出来てもおかしくなさそうじゃない？