-複数の読取りスレッドと書込みスレッドの並列動作をサポート高スループットの待機時間の短い読取り高い同時実行性とデータのスケーラビリティを実現するインメモリ・キャッシングアプリケーションの実行ではRDBアクセスを必要としないRDBシステムではアクセス数増加や格納するデータ量が多くなるにつれパフォーマンス低下が顕著になります。システム増強を行う場合、WebサーバやAPサーバでは負荷分散装置などを使ってサーバ台数の増強などで対応できますが、RDBサーバの増強は難しく、高性能なサーバに入れ替えるなどの対応しかできないのが現状です。分散KVSはキーと値(バリュー)からなる比較的単純な構造をしており、複数のサーバに分散配置されたデータを高速に処理できます。単純なノード追加で処理能力を増強できるためRDBよりも低コストで実現可能です。Edition)を採用しています。JEは完全にJavaで実装されている高性能のストレージエンジンであり、高いパフォーマンスを実現できます。新たな開発費などの追加費用は不要RDBシステムでは一貫性を保証するためのロック機能があるため、たとえ複数のデータベースサーバを準備できたとしてもロック機能がボトルネックとなり、サーバの台数に比例した性能を得ることは困難です。ReflexWorksは分散配置(シャーディング)を基本としており、WebサーバやAPサーバと同じようにシステム増強により単純に性能を向上させることができます。各ノード上のデータはシステムの追加・削除によって影響を受ける範囲が限定的であり、再編成にかかる時間も短く済みます。Isolation)原子性(Atomicity)、一貫性(Consistency)、独立性(Isolation)、および永続性(Durability)を保証Revision番号管理による楽観的排他機能ほとんどの分散KVS製品はトランザクション処理機能といったデータの一貫性保証がなく、複合検索、ソートといった複雑な検索機能を備えていないため、複雑な業務アプリケーションを構築することは非常に困難です。ECサイトではカートと在庫引当処理においてデータの一貫性保証が必要ですが、分散KVSにはトランザクション処理機能がないため実現することはできません。Editionをデータストアとして採用しているため、情報をすばやく、簡単かつ確実に格納、取得することができます。FeedもしくはEntryの単位で実行しますが一貫した状態のデータベースを維持するよう設計されており、相互依存のある複数の操作が全て完了するか全てキャンセルされることを保証します。楽観的排他機能を利用することでブロックしない並列処理として実行できます。トランザクション処理ができれば、在庫引当処理のような一貫性が要求される業務アプリケーションの構築が可能になります。分散化によってスケーラビリティが確保できたとしても、特定のノードが故障するとシステム全体がダウンするような単一障害点のあるシステムではミッションクリティカルな分野において使うことができません。ReflexWorksはバックグラウンドサービスによって非同期にBDBから読み込んだデータをRDBに書き込みます。その際ノード上のプロセスが何らかの理由で応答しなくなると自動的にノードリストが書き換えられ、その障害ノードを自動的に分散対象から切り離します。ダウンしたノードのデータを他の正常なノードに引き継ぎます。分散対象は各ノードのノードリストで管理しているため、障害が発生したノードの影響を受けずにサービスを継続させることができます。引き継ぐデータはRDBから取得するため、データは重複して持つこと(レプリケーション)はしません。すべてのノードのデータをRDBに書き出すため、データ集計などのバッチ業務等はこれまでと同様にRDBを参照することで実行できます。疎結合の汎用性の高いインターフェース分散KVSはトランザクション処理機能がなく、また範囲検索や絞り込みといった検索条件を指定できないなど、アプリケーション開発には困難がつきまといます。アプリケーションが扱うデータの中には、構造化されていなかったり書き込みが膨大であったりするケースがあるため、データストアへの格納が容易でないと工数が膨らんでしまいます。JEの単純なKey/Valueストアをドキュメント指向のデータストアに拡張しています。)により直感的なアクセスが可能です。様々な条件検索指定など豊富な機能で業務アプリケーションの作成を容易にします。Coreは、JavaオブジェクトからXML、JSON、MessagePackなどに変換するシリアライズ機能とXML、JSON、MessagePackをオブジェクトに変換するデシリアライズ機能を提供します。スキーマはATOM形式をユーザ定義のスキーマに拡張可能です。これはJavaクラス(エンティティ)によって定義するソフトスキーマです。データ操作のためのAPIは基本的に疎結合であり、RDBやKVSなどのデータストアにも依存しないため可搬性を維持できます。-ビジネスロジックの組み込みユーザ定義スキーマの組み込みORM不要のソフトスキーマ業務アプリケーションにおいてはサーバ側でデータをチェックしたいケースがあります。ECシステムにおける受注処理においては、在庫確認や注文商品の値段などをサーバの商品マスターを使ってチェックする必要があるでしょう。APIを使ったデータ操作だけではなく、ユーザが作成したビジネスロジックをサービスとして追加することができます。サービスはjarファイルとして簡単にサーバにデプロイすることが可能です。ReflexWorksはアプリケーションで定義するスキーマ(ソフトスキーマ)を採用しており項目の追加変更が容易にできます。スキーマはJavaクラスによって定義し(これをエンティティと呼んでいます)、1つのjarファイルにパッケージしたものをサーバに配置(デプロイ)します。JEに格納するためORM(オブジェクト関係マッピング)は必要ありません。項目ごとに暗号化の設定が可能データを格納するフォルダにはアクセス権限(ACL)をつけることができます。アクセス権限が付いたフォルダの配下のデータはログイン済の許可されたユーザのみがアクセスできます。ACLは基本的には許可ユーザを個々に指定しますが、ワイルドカードが記述できるためグルーピング指定も可能です。Providerとの連携も可能です。認証においてはリピート攻撃、総当たり攻撃(含む辞書攻撃)に対応し安全性を確保しています。APIを安全にインターネットに公開できるようになります。HTMLを出力する際にCSRF対策のためのトークンを付与する機能もあります。-WebHookによる外部システム通知機能WebSocketによりブラウザへの通知機能メール送信機能ソーシャルなアプリケーションでは更新通知機能が欲しくなるケースがあります。第三者の発信情報をリアルタイムで見たり、データが更新されたことをすぐに知りたい場合などです。ReflexWorksではあらかじめフォルダにアクションをセットしておくことで、フォルダ配下のデータにアクセスしたタイミングでイベントを通知することができます。イベントが発生すると外部システムやブラウザへ通知されます。これらの機能によりインタラクティブなアプリケーションは容易に作れるようになります。技術要件(システム実現方法や開発方式など)が一貫していないと高い品質を維持するのが難しくなります。汎用性のない作りでリリースしてしまい、後にメンテナンスや機能追加をする作業が大変になってしまいます。ReflexWorksは統一したエンティティモデルを採用しているため、DB、サービス、画面で一貫した項目名が使われます。マッパー)を必要としません。その結果項目変換処理はほとんど存在せず、同意語(synonym)が発生しにくいという利点をもちます。このためシステム全体として統一感のある品質の高いシステムができあがります。-帳票生成処理はCPU負荷が高くメモリも多く消費します。業務アプリケーションには必ずといっていいほど帳票出力があり、それがサーバ資源を圧迫させています。iTextの2つの方式を提供します。PrintAPIはサーバで帳票を作成するのではなくFlashのPrintAPIを使って印刷するもので、基本的にクライアントのリソースだけを使うためサーバ資源を圧迫させることはありません。iTextはサーバのインスタンスを動的に複数起動させ、帳票レイアウト(HTML)とデータを動的に与えることで大規模なPDF生成処理を可能にします。iTextインスタンスは基本的に疎結合でありサーバの資源を圧迫させる心配がありません。Technology,Ltd.。