なぜGPSSでS2を使用するのか - あもいもやっとく？

現行バージョンのGPSS(http://www.geocities.co.jp/SiliconValley-PaloAlto/8242/)の主な仕事は、Socket通信の管理、Sockletの管理の二つです。このうち、Sockletのインスタンス管理についてはS2に任せてしまえるんじゃないかと思いついたわけです。
シングルトンのSockletインスタンスの管理をS2に任せてしまうことには、以下のような利点があります。

GPSS本体の軽量化。
Sockletの初期化をdiconファイルにて柔軟に行えるようになる。
SockletにAOPを適用できる。
S2の強力なDBアクセス機能(S2JDBC, S2TX, S2Daoなどなど)を使用できる。

まずはざっとこれだけの利点が考えられます。

GPSS本体の軽量化

現行バージョンのGPSSを起動すると、まず設定ファイルを読み取り、XMLを解析し、Sockletとして登録できるかを検査し、…と言った処理が走るのですが、この部分をばっさり切ってしまうことができるのではないかと期待しています。
Sockletの起動・登録は、パラメータで指定されたdiconファイルをS2に渡してお終い。これぐらいあっさりした処理になるようにしてみます。

Sockletの初期化

現在はSockletの仕様と初期化XMLファイルの仕様が密接に関係しています。例えば、ある特定のSockletでのみ呼び出すような初期化メソッドを初期化ファイルで定義、ってなことは出来ません。
ですがS2のdiconファイルを使用すれば、作成したSocklet派生クラスの仕様に併せて自由に初期化を行えるようになります。

AOP

宴会のときにお話した未踏ソフトウェア事業の「AOPなXMLSocketサーバ」は、http://untrod.keihanna.ne.jp/whitedog/index.htmlです。>>ひがさん
GPSSの方もずっとAOPには興味があったのですが、なかなか実装するまでには至らなかったわけでして。
AOPの利点はここで述べるまでも無いと思います。

データベース連携

Socketアプリケーションを作る上でも、ユーザー管理を行う場合などやはりデータベースへのアクセスが欲しくなります。が、トランザクション管理、O/Rマッピングなどを自前でやるのはナンセンスです。
S2には既に強力なそれらの機能がありますので、それを利用しない手は無いと考えました。本当にGPSS/Sockletでも使えるのかどうか、S2のソースを読み直して検証しなおす必要はありますが。