技術解説
WEBシステム開発において必ず直面するのが、サーバ側プログラミングとクライアント側プログラミングを別々に作り分けなければならない難しさです。ひとつのアプリケーションのアルゴリズムを追ってみると、データベースへのアクセス、画面のDOM制御やマウス等イベント処理、サーバ側の動作とクライアント側の動作が、入り乱れて必要とされることが分かります。一般的に普及しているフレームワークは、大きく分けてサーバ側とクライアント側の二つがあ りますが、いずれも解決困難な問題点を抱えています。
サーバ側フレームワークの問題点
サーバ側フレームワークは、動作が小間切れになってしまう問題点があります。HTTPプロトコルの特徴から、一回のアクセスごとにスクリプトが終了し、インスタンスが消滅してしまいます。これに対処するためサーバ側でオブジェクト空間をシリアライズしてセッション内で引き継ぐといった方法が行われていますが、少し強引な方法といえます。ごく少ない頻度で特殊な場面に対してのみ使われる程度であればいいのですが、アプリケーション全体をこの方法で構築してしまうと負荷がとても大きくなり、また何より結局のところソースコードの一貫性の無さが問題として残ります。
クライアント側フレームワークの問題点
クライアント側フレームワークは、ソースコードがクライアント側から丸見えになってしまう問題点があります。さらに、サーバ側で必要とされるデータベースやネットワーク上の共有処理等を、例えばWEBサービスといった形で別途記述しなければならないことから、大規模なアプリケーションでは動作全体を高度にプロトコル化しなければならない困難があります。
解決方法
サーバ側でもクライアント側でもないフレームワークは作れないかと考え、以下のような構造を考案しました。アプリケーションごとにサーバ側には専属プロセスが常時起動し、クライアント側と常時接続状態を維持します。それらはメッセージを常に交換し、イベントなどの情報を伝え合うことで、サーバ側での能動的な処理にスコープを集約します。これにより、サーバ側でのクラス定義を永続的にすることができ、スクリプトをページ単位で終了する必要が無くなります。この枠組みを、Real-time Class-sharing Framework（RCF）と名付けます。
動作プロセス
上記を実現するための動作プロセスを説明します。
ステップ１
初回アクセス時に、サーバ側で常駐アプリケーションプロセスが起動します。
ステップ２
アプリケーションプロセスは、自らのIDを埋め込んだマイクロエージェントをクライアント側に送り返します。
ステップ３
以後、マイクロエージェントはクライアント側の状態や挙動を全て把握・制御し、サーバ側に報告するとともに、サーバ側からのメッセージに応じて処理を実行するイベント待ちループに入ります。
ステップ４
サーバ側ではアプリケーションプロセスがイベント待ちループに入り、以後、メッセージコントローラがクライアント側とサーバ側のイベント処理を自動的に結合します。
特徴
ページ単位でスクリプトが終了しないため、様々な特徴が生まれます。
共通クラス定義
サーバ側とクライアント側に共通のクラス定義が可能となります。これにより、例えばデータベース制御クラスとDOM制御クラスを同一スコープに収めたアプリケーションクラスの定義が可能となり、再利用性が格段に向上します。
リソース使用の効率化
例えばアプリケーションが待機状態でもサーバ側で常駐プロセスが存在することは、非効率ではないかという見解もあるかもしれません。ですが実際には、次のアクションのためにどのみち同じリソースの確保が必要とされ、そこには無駄なページや認証のためのオーバーヘッドを含むことになります。リソース消費総量においても、このフレームワークは有利に働きます。
ページ指向からの脱却
従来のWEBアプリケーションは、ページ単位で処理を記述することが通例でした。現在のページ内の情報を全て捨て、新しいページ全体を読み込み直す処理は無駄が大きく、連続した操作を想定するアプリケーション利用中において効率的ではない場面が多くあります。このフレームワークでは必要な最小限のメッセージ交換によって部分的な更新しか行いませんので、処理そのものが極めて効率的となります。
サーバ側仮想DOM
処理過程でサーバ側にもクライアント側と同じ仮想DOMツリーを保持することになります。サーバ側でのDOM探索により最小差分のみ処理することが可能となり、クライアント側の動作が軽くなります。
オブジェクト指向の真価
このフレームワークにより、オブジェクト指向が真価を発揮します。特にSPA(Single Page Application)、PWA(Progressive Web Application)との相性は抜群です。画面上のオブジェクト（物）をそのまま定義することは多くの場合自動的に優れた設計となります。
高負荷時制限の公平性
高負荷時の振る舞いとして、全ユーザのプロセスが重くなってしまうのは避けたいことです。ど のユーザも目的を果たせずリトライを繰り返してしまうかもしれません。アプリケーションプロセスごとに制限を設けることで、少人数ずつでも確実に利用できるユーザ用のリソースを確保することで、無駄なリトライによる消費を抑えることにつながります。