RDBシステムではアクセス数増加や格納するデータ量が多くなるにつれパフォーマンス低下が顕著になります。システム増強を行う場合、WebサーバやAPサーバでは負荷分散装置などを使ってサーバ台数の増強などで対応できますが、RDBサーバの増強は難しく、高性能なサーバに入れ替えるなどの対応しかできないのが現状です。

この問題を解決しうる技術として注目されているのが、「分散KVS（キーバリュー型データストア ： Key-Value Store）」です。分散KVSはキーと値（バリュー）からなる比較的単純な構造をしており、複数のサーバに分散配置されたデータを高速に処理できます。また、単純なノード追加で処理能力を増強できるためRDBよりも低コストで実現可能です。

ReflexWorksはトランザクション処理が可能な分散KVSであるBDB JE(Berkelry DB Java Edition)を採用しています。BDB JEは完全にJavaで実装されている高性能のストレージエンジンであり、高いパフォーマンスを実現できます。

RDBシステムでは一貫性を保証するためのロック機能があるため、たとえ複数のデータベースサーバを準備できたとしてもロック機能がボトルネックとなり、サーバの台数に比例した性能を得ることは困難です。

ReflexWorksは分散配置（シャーディング）を基本としており、WebサーバやAPサーバと同じようにシステム増強により単純に性能を向上させることができます。また、各ノード上のデータはシステムの追加・削除によって影響を受ける範囲が限定的であり、再編成にかかる時間も短く済みます。

ほとんどの分散KVS製品はトランザクション処理機能といったデータの一貫性保証がなく、複合検索、ソートといった複雑な検索機能を備えていないため、複雑な業務アプリケーションを構築することは非常に困難です。例えば、ECサイトではカートと在庫引当処理においてデータの一貫性保証が必要ですが、分散KVSにはトランザクション処理機能がないため実現することはできません。

ReflexWorksはトランザクショナルなKVSであるBerkeley DB Java Editionをデータストアとして採用しているため、情報をすばやく、簡単かつ確実に格納、取得することができます。ReflexWorksはデータの操作をAtom FeedもしくはEntryの単位で実行しますが一貫した状態のデータベースを維持するよう設計されており、相互依存のある複数の操作が全て完了するか全てキャンセルされることを保証します。また、楽観的排他機能を利用することでブロックしない並列処理として実行できます。トランザクション処理ができれば、在庫引当処理のような一貫性が要求される業務アプリケーションの構築が可能になります。

分散化によってスケーラビリティが確保できたとしても、特定のノードが故障するとシステム全体がダウンするような単一障害点のあるシステムではミッションクリティカルな分野において使うことができません。

ReflexWorksはバックグラウンドサービスによって非同期にBDBから読み込んだデータをRDBに書き込みます。その際ノード上のプロセスが何らかの理由で応答しなくなると自動的にノードリストが書き換えられ、その障害ノードを自動的に分散対象から切り離します。また、ダウンしたノードのデータを他の正常なノードに引き継ぎます。

分散対象は各ノードのノードリストで管理しているため、障害が発生したノードの影響を受けずにサービスを継続させることができます。

引き継ぐデータはRDBから取得するため、データは重複して持つこと（レプリケーション）はしません。また、すべてのノードのデータをRDBに書き出すため、データ集計などのバッチ業務等はこれまでと同様にRDBを参照することで実行できます。

分散KVSはトランザクション処理機能がなく、また範囲検索や絞り込みといった検索条件を指定できないなど、アプリケーション開発には困難がつきまといます。 また、アプリケーションが扱うデータの中には、構造化されていなかったり書き込みが膨大であったりするケースがあるため、データストアへの格納が容易でないと工数が膨らんでしまいます。

ReflexWorksはBDB JEの単純なKey/Valueストアをドキュメント指向のデータストアに拡張しています。データをURLのツリー構造で管理し、URLに対してREST APIを使ってのCRUD操作（作成・読込・更新・削除）により直感的なアクセスが可能です。また、様々な条件検索指定など豊富な機能で業務アプリケーションの作成を容易にします。

Reflex Coreは、JavaオブジェクトからXML、JSON、MessagePackなどに変換するシリアライズ機能とXML、JSON、MessagePackをオブジェクトに変換するデシリアライズ機能を提供します。スキーマはATOM形式をユーザ定義のスキーマに拡張可能です。これはJavaクラス（エンティティ）によって定義するソフトスキーマです。

データ操作のためのAPIは基本的に疎結合であり、RDBやKVSなどのデータストアにも依存しないため可搬性を維持できます。

業務アプリケーションにおいてはサーバ側でデータをチェックしたいケースがあります。 例えばECシステムにおける受注処理においては、在庫確認や注文商品の値段などをサーバの商品マスターを使ってチェックする必要があるでしょう。 ReflexWorksではクライアントからのREST APIを使ったデータ操作だけではなく、ユーザが作成したビジネスロジックをサービスとして追加することができます。 サービスはjarファイルとして簡単にサーバにデプロイすることが可能です。

ReflexWorksはアプリケーションで定義するスキーマ（ソフトスキーマ）を採用しており項目の追加変更が容易にできます。スキーマはJavaクラスによって定義し（これをエンティティと呼んでいます）、１つのjarファイルにパッケージしたものをサーバに配置（デプロイ）します。

ReflexWorksは、ATOM Feedのオブジェクトを直接BDB JEに格納するためORM(オブジェクト関係マッピング)は必要ありません。

データを格納するフォルダにはアクセス権限(ACL)をつけることができます。アクセス権限が付いたフォルダの配下のデータはログイン済の許可されたユーザのみがアクセスできます。 ACLは基本的には許可ユーザを個々に指定しますが、ワイルドカードが記述できるためグルーピング指定も可能です。 ReflexWorksには独自のユーザ管理機能がありますが、TwitterやFacebookといった外部のOAuth Providerとの連携も可能です。

認証においてはリピート攻撃、総当たり攻撃（含む辞書攻撃）に対応し安全性を確保しています。

項目ごとに暗号化指定が可能であり、これによりREST APIを安全にインターネットに公開できるようになります。また、HTMLを出力する際にCSRF対策のためのトークンを付与する機能もあります。

ソーシャルなアプリケーションでは更新通知機能が欲しくなるケースがあります。 例えば第三者の発信情報をリアルタイムで見たり、データが更新されたことをすぐに知りたい場合などです。 ReflexWorksではあらかじめフォルダにアクションをセットしておくことで、フォルダ配下のデータにアクセスしたタイミングでイベントを通知することができます。 イベントが発生すると外部システムやブラウザへ通知されます。これらの機能によりインタラクティブなアプリケーションは容易に作れるようになります。

技術要件（システム実現方法や開発方式など）が一貫していないと高い品質を維持するのが難しくなります。たいていは汎用性のない作りでリリースしてしまい、後にメンテナンスや機能追加をする作業が大変になってしまいます。ReflexWorksは統一したエンティティモデルを採用しているため、DB、サービス、画面で一貫した項目名が使われます。

BDBを使う場合においては、オブジェクトが直接格納されるためORM(O/R マッパー)を必要としません。その結果項目変換処理はほとんど存在せず、同意語(synonym）が発生しにくいという利点をもちます。 このためシステム全体として統一感のある品質の高いシステムができあがります。

帳票生成処理はCPU負荷が高くメモリも多く消費します。 業務アプリケーションには必ずといっていいほど帳票出力があり、それがサーバ資源を圧迫させています。 ReflexWorksでは、クライアントから直接印刷するFlash PrintAPIと複数のサーバを使ってPDFを生成するReflex iTextの２つの方式を提供します。

Flash PrintAPIはサーバで帳票を作成するのではなくFlashのPrintAPIを使って印刷するもので、基本的にクライアントのリソースだけを使うためサーバ資源を圧迫させることはありません。

Reflex iTextはサーバのインスタンスを動的に複数起動させ、帳票レイアウト(HTML)とデータを動的に与えることで大規模なPDF生成処理を可能にします。 アプリケーションとReflex iTextインスタンスは基本的に疎結合でありサーバの資源を圧迫させる心配がありません。