Wagby 技術情報
Wagbyについて、jasminesoft社のホワイトペーパー、その他資料について紹介します。
Contents
機能リファレンス |
Wagbyでは、次のようなWebアプリの問題への対応が施されています。
・クロスサイトスクリプティング脆弱性を突いた攻撃。
・SQLインジェクション脆弱性を突いた攻撃。
・OSコマンドインジェクション脆弱性を突いた攻撃。
・クロスサイトリクエストフォージェリ脆弱性を突いた攻撃。
・監査ログ
・認証・認可機能
ID/パスワードによるユーザー認証、ロールベースの認可機能を保有します。
ユーザー認証では総当り攻撃への対応（ログイン失敗回数の指定）等、ID/パスワードでユーザー認証を運用する際の
対応が行われています。
Wagbyの提供する代表的な業務処理を紹介します。
1)入力チェック 必須チェック、文字形式チェック、長さチェック、関連性チェック、正規表現その他 ２） テーブル連携（Hibernateを利用したO/Rマッパー） 下記テーブルのリレーションを解決し、javaBeanオブジェクトとしてマッピングします。
@OneToOne → 参照連動 @OneToMany → 繰り返し項目 ※詳しくは下記「データアクセスのベストプラクティス」を参照ください。 ３） 自動計算 テーブルの導出項目として、シンプルなDSLを利用することができます。また、javaコードでカスタマイズすることも可能です。 ４） 帳票 ノンプログラミングでExcel帳票（PDFも可）を出力できます。 ５） メール送信 メール送信機能があります。 ６） BI（Business Intelligence) テーブルデータの多次元解析が可能です。ただし、解析用キューブを作成することはないため、大量データの解析は別途対応が必要です。 |
Generation Gap、Hook Operationパターンによるカスタマイズが可能です。これらにより自動生成ソースコードと、カスタマイズソースコードを完全に分離することができます。また、WagbyはStrus1.xベースのWebアプリケーションです。アクションの追加も自由に行うことができます。Ajaxに対応した独自アクションを追加することも可能です。
HTML, CSS, JSP の知識を使って Wagby が自動生成した画面を自由にカスタマイズすることができます。また、Ajaxに対応した独自アクションを利用し、RIA（Rich Internet Application）の実装も可能です。当社では、Ajaxで使用するJSONデータに対し、各ユーティリティを準備しています（JSON→プレゼンテーションモデル、プレゼンテーションモデル→JSON変換ユーティリティ等)
データアクセスのベストプラクティス |
Wagbyのデータアクセスの実装について、java標準であるJPAと比較しながら確認します。Wagbyは、JPAに準拠してはいませんが、DataMapperパターンのベストプラクティスと言えるでしょう。（JPAは、Google App Engineの標準データアクセス方法として採用されていることからも、現状のjava標準との位置づけと言えるでしょう。）
JPAは、「Patterns of Enterprise Application Architecture（PofEAA）」で提唱された「DataMapperパターン」の実践となります。なお、Ruby on Railsに同梱されているActiveRecordは、PofEAAでの「ActiveRecordパターン」となります。
ActiveRecordパターンは「アプリケーション側のモデル構造とDB側のテーブル構造を1:1対応させる」という割り切った特長を持っています。しかし、昨今の業務システムのテーブルは、性能上の理由や、みなし概念によりほどよく非正規化されており、アプリケーション側のモデルも崩れるケースが多数発生します。DataMapperパターンは「アプリケーション側のモデル構造とDB側のテーブル構造をn:n対応とし、それらをマッピングさせる」というもので、非正規化されたテーブル構造をより抽象的な業務モデルにマッピングすることができます。
DataMapperパターンは優秀ですが、現状を考えるとActiveRecordパターン（Ruby on Rails）が圧勝している状況です。DataMapperパターンは、それを簡単に実装する開発ツールが存在しない状況です（商用開発ツールには存在するかもしれません）。それは、「テーブル構成の崩れ」といった煩わしい問題を気持ちよく切り捨て、記述量を最小限に抑制したRuby on Railsの成功からも明らかです。
Wagbyは、DataMapperパターンをノンプログラミングで実装します。また、DBのマイグレーション機能も有しており、開発から運用まで低コストにDataMapperパターンをサポートします。Wagbyは、DataMapperパターンを実現するもっとも優れた開発ツールの一つではないでしょうか。
今回Wagbyと比較するJPAのおもなアノテーションを紹介します。
１) @PostLoad データベースから現在の永続性コンテキストにエンティティがロードされた後、また はリフレッシュ操作が適用された後に起動されます。 ２) @PrePersist,@PreUpdate データベースへの永続操作、実行操作が実行される前に起動されます。 ３） @PostPersist,@PostUpdate データベースへの永続操作、実行操作が実行された後に起動されます。 ４) @OneToOne 1対1マッピングを使用して、2つのJavaオブジェクト間の単純なポインタ参照を表します。 ５) @OneToMany 1対多マッピングを使用して、単一のソース・オブジェクトとターゲット・オブジェクトのコレクションの間の関連を表します。 ※@PostLoad,@PrePersist,@PreUpdate等の関連性 http://otndnld.oracle.co.jp/products/ias/toplink/jpa/resources/toplink-jpa-annotations.html#CHDCHFJJ |
Wagby機能との比較
Waggy機能と上記に揚げたアノテーションの機能を比較します。
１) @PostLoad Wagbyでは、下記２パターンの異なるロジックを生成します。@PostLoadで表示用ロジックは実装可能かと思いますが、更新用ロジックの実装は困難です。更新用ロジックのノンプログラミングでの実装は、非常に大きなアドバンテージと言えるでしょう。 表示用ロジック → 詳細表示データを作成する。コード値のマスタ参照、数値のフォーマット等 更新用ロジック → 表示用ロジックに加え、選択するコンボボックス、チェックボックス等のデータを作成する。 参照データが多いも のについては、検索画面、またはサジェスト機能を設定することも可能。 ２) @PrePersist,@PreUpdate データベースへの永続操作前のデータ操作ロジックを生成します。例えば「自動計算」です。４）、５）の設定を行えば、複数テーブルに関連する計算も可能です。 ３） @PostPersist,@PostUpdate Wagbyで該当する実装はありません。必要ではれば、Generation Gapパターンにてカスタマイズすることができます。 ４) @OneToOne Wagbyでは「モデル連携」で実現します。他テーブルのキーを設定すれば「参照連動」で必要な項目を連携することができます。 ５) @OneToMany Wagbyでは「繰り返しコンテナ」で実装可能です。また、単一項目の繰り返しの場合「繰り返し項目」、または「他のストアモデルの参照(チェックボックス)」で実装することができます。通常難しい１対多の実装を、ノンプログラミングで実現可能です。 ※WagbyのO/Rマッピングとパフォーマンス 上記機能は非常に複雑であり、シンプルなSQLでの実装することは困難です。シンプルなSQLの組み合わせでこれら機能を実装する場合、どうしても多数回のSQLがDBに発行されます。この問題に対し、Wagbyでは分散キャッシュ(ehcache)が導入されています。分散キャッシュであるため、クラスタ環境でも動作が保障されます。また、キャッシュ機能は自動生成部と切り離されているため、jp.jasminesoft.jfc.app.CacheManagerBaseを置き換えれば、memcached等への置き換えも可能でしょう。 |
Wagbyその他製品情報 |
ここでは、Wagbyおよびその他自動生成開発ツール群の情報をウォッチしていきたいと思います。
これら製品は、これまでのMicrosoft製品を置き換えていくことになるだろうと思います。
（あくまでも「これまでのMicrosoft製品」です。「Windows Azure AppFabric」を中核としたクラウドソリューションは要注目です）
CMはこちら
サイボウズがサービス開始を予定している業務アプリPaaS。「最短10分で業務アプリを運用開始」だそうです。業務アプリストアサービスが提供され、必要なアプリを購入可能とのこと。サイボウズであることからグループウェアアプリも充実していることが予想されます。このサービスモデルは「Google Apps Marketplace」と同等。価格面でGoogleと勝負することは不可能でしょうから、Googleより優れたサービス体系となることを期待します。なお、自動生成機能については、CMを見る限り単テーブルのCRUD操作のようです。
Googleの業務アプリサービス Googleが提供する業務アプリサービス群です。これらサービスすべてをシングルサインオン環境で利用可能です。 ・Google Apps ・・・ オフィス製品 ＋ グループウェア ・Google Apps Marketplace ・・・ オフィス製品の拡張モジュール群 ・Google App Engine ・・・ Googleのインフラを利用するWebアプリケーション。Javaでの実装が可能。 価格、機能ともに完璧なサービス群ですが問題もあります。Google App Engineでは、スケーラビリティと可用性の提供のためRDBが利用できません。Google App Engineを利用した高トラフィックサービス（SNSのイベント等）の成功例は多いかと思いますが、通常の業務アプリでそれほどまでのスケーラビリティは必要ないでしょう。 Googleでは、RDBを利用可能とする「App Engine For Business」を提唱していますが、まだサービス提供まではいたっていません。クラウド環境でのRDBは難しいのかもしれません。Amazon RDSの大規模障害からもその難しさがうかがえます。 |
セールスフォースが提供するPaaS環境。「kintone」の説明では「Force.com」は価格が高いとのこと。価格勝負では「kintone」が優勢でしょう。自動生成機能は単テーブルのCRUD操作コード程度、カスタマイズは高機能でAJAXツールキットJavaScriptライブラリを利用することで、自動生成したテーブルの操作（リレーションも含め）を自由に行うことができます。
Microsoft製品をフルに活用するERPパッケージ。Microsoftのアーキテクチャにより理想的なシステム構築が可能。が、現実的にここまでミドルウェアをロックする構成は難しいと思われます。また、ActiveDirectoryを中核としたシステム構成は、Microsoftとしても推奨していないでしょう。今後、ADFSを中核としたシステムへと移行されることに期待です。
自動生成面では、MSのソフトウェアモデリングプラットフォーム「Oslo」の実装だと思われます。「ノンプログラマーでも分散型アプリケーションを開発できる」そうです。
ただし、現状を考えると、これら技術は「HTML+Javascript」に落ち着いたと言えるでしょう。Force.com、Google等も「HTML+Javascript」で開発可能です。この頃Facebookも独自タグFBMLを廃止し、「HTML+Javascript」での開発が可能となりました。
業務用アプリケーションの開発に特化したVisual Studio。「クラウド対応のExcelとかAccess」（「Oslo」はどうなったのでしょうか）
良くも悪くも「Silverlight」。MetroUIで巻き返すか、それともこのまま「XAMLって何？」と沈没するか。
以上、いろいろな自動生成機能を保有する開発ツールを紹介してきました。どれも非常に優れた特性と生産性があります。ただ、共通的な問題点があります。それは、ベンダーにロックされているブラックボックスな点が多いことです。「Visual Studio LightSwitch」は非常にオープンですが良くも悪くもUIが「Silverlight」。どのツールも簡単に導入することは困難でしょう。
この点で、Wagbyは異なります。Wagbyはオープンソースツール群のみで構成されています。業務アプリも作成できますが、「認証、認可機能だけを利用する」ようなことも簡単です（これだけでも十分に導入価値があります）。Wagbyは、「通常のSpring + Hibernate開発をサポートする」という位置づけと言えるでしょう。