JBoss Seam のバリデーションに Drools 使うのってどうでしょう
186 views
Skip to first unread message
ごとう
Dec 19, 2008, 9:57:45 AM12/19/08
to みんなのDrools
はじめまして、ごとうと申します。
最近、会社でWebアプリケーション構築のプロジェクトにたずさわり始めました。
プロジェクトは、クライアントサーバー型のWin32アプリケーションをWeb+Javaに焼き直そうというものです。
現行システムの課題の一つがバリデーションで、エントリ画面の入力チェックがとても複雑なため、ソースコードの可読性が低く、メンテナンスに苦労してい
ます。
私自身は、5年ほど前に少しだけ Struts をかじったことがある程度で、Web、Java、JEE、フレームワークとどれもこれも初心者でして、
現在少しずつお勉強しているところです。
開発フレームワークとして JBoss Seam を採用しました。JBoss Seam についていろいろ調べていたところ、Droolsを知りまし
た。Drools はまだその存在を知ったばかりというレベルなんですが、If-then 形式で入力チェックルールを積み重ねていけるのであれば、現
在の複雑でわかりにくいコードがすっきりするのではないかと思いました。
もう少し調べてみようと思いますが、「そもそもその考え方は的外れだ」とか、「だったら、こういう手段がある」といったご意見がいただければと思い、投
稿しました。
ご教授くださいませ。
最近、会社でWebアプリケーション構築のプロジェクトにたずさわり始めました。
プロジェクトは、クライアントサーバー型のWin32アプリケーションをWeb+Javaに焼き直そうというものです。
現行システムの課題の一つがバリデーションで、エントリ画面の入力チェックがとても複雑なため、ソースコードの可読性が低く、メンテナンスに苦労してい
ます。
私自身は、5年ほど前に少しだけ Struts をかじったことがある程度で、Web、Java、JEE、フレームワークとどれもこれも初心者でして、
現在少しずつお勉強しているところです。
開発フレームワークとして JBoss Seam を採用しました。JBoss Seam についていろいろ調べていたところ、Droolsを知りまし
た。Drools はまだその存在を知ったばかりというレベルなんですが、If-then 形式で入力チェックルールを積み重ねていけるのであれば、現
在の複雑でわかりにくいコードがすっきりするのではないかと思いました。
もう少し調べてみようと思いますが、「そもそもその考え方は的外れだ」とか、「だったら、こういう手段がある」といったご意見がいただければと思い、投
稿しました。
ご教授くださいませ。
Shigeaki Wakizaka
Dec 19, 2008, 10:37:33 AM12/19/08
to jd...@googlegroups.com
こんばんは、脇坂です。
私自身、バリデーションにDroolsを「仕事」で適用
したことはないのですが、
そんなに劇的にうれしー！ってなるかは微妙のような気がしています。
(グループメンバーにいる佐藤（匡）さんが仕事でバリデーション部分を
Drools使ってやったことあるっていってたなぁ。余裕があったら
経験談をshareしてほしーなー（ボソッ）
バリデーション内容にもよりますが
例えばバリデーションによっては、このバリデーションルールを実行してOKだったら
このバリデーションをやってー、といったNestされている場合や、
あそことあそこで同じルールを使うから共有したい、とかなると
Drools自体はFunctionという機能を用意して実現できますが
そこまでくるとJavaでちゃんと設計、実装するのとあんまり変わらなーい
ってなったりするケースもでてくると思います。
（むしろちょっとDroolsのほうが面倒くさいかも,ちょっと遅くなるし）
んなもので
「ソースコードの可読性が低く、メンテナンスに苦労しています。」
という動機だけでDroolsを持っていくのは個人的にあんまりBestかと
いうとちょっとはてながつく感じでとらえてます。
他にバリデーションルールの仕様がよく運用に入っても変更が想定されていて
顧客手動でルールを管理したい、という動機があればDroolsのうまみも
でてくると思いますけど。
まずは１意見として。
wkzk
私自身、バリデーションにDroolsを「仕事」で適用
したことはないのですが、
そんなに劇的にうれしー！ってなるかは微妙のような気がしています。
(グループメンバーにいる佐藤（匡）さんが仕事でバリデーション部分を
Drools使ってやったことあるっていってたなぁ。余裕があったら
経験談をshareしてほしーなー（ボソッ）
バリデーション内容にもよりますが
例えばバリデーションによっては、このバリデーションルールを実行してOKだったら
このバリデーションをやってー、といったNestされている場合や、
あそことあそこで同じルールを使うから共有したい、とかなると
Drools自体はFunctionという機能を用意して実現できますが
そこまでくるとJavaでちゃんと設計、実装するのとあんまり変わらなーい
ってなったりするケースもでてくると思います。
（むしろちょっとDroolsのほうが面倒くさいかも,ちょっと遅くなるし）
んなもので
「ソースコードの可読性が低く、メンテナンスに苦労しています。」
という動機だけでDroolsを持っていくのは個人的にあんまりBestかと
いうとちょっとはてながつく感じでとらえてます。
他にバリデーションルールの仕様がよく運用に入っても変更が想定されていて
顧客手動でルールを管理したい、という動機があればDroolsのうまみも
でてくると思いますけど。
まずは１意見として。
wkzk
ごとう
Dec 19, 2008, 11:02:39 AM12/19/08
to みんなのDrools
脇坂さま
さっそくのご意見ありがとうございます。
やっぱりそんなに効果絶大って訳にはいかなさそうですね。
このシステムは準パッケージ製品でして、お客様に導入する時は、お客様向けに少しだけ
手直し(カスタマイズ)して納品するというプロセスを踏みます。この「少しだけ手直し」ってのが
くせ者でして、本来は文字通り少しで済ませ、横展開すればするほどガッチリ！という
ストーリーなんですが、現行の準パッケージ製品の出来がイマイチなため、少しどころか
結構な大手術になってしまって、なかなかガッチリ！にならないのが現状です。
で、エントリー画面のバリデーションのコードは、お恥ずかしながらひどいモノでして、
「if文とcase文のじゅうにひとえや～」って感じなんです。カスタマイズ作業の都度、
「ああ、こりゃあなんてひでえコードなんだ」とぼやいておりまして、そんなものですから、
もーなんとかしたい、あーDroolsなら何とかしてくれるかも...と幻想をいだいてしまった訳です。
むかーし、もう20年近くも前、AIだとかエキスパートシステムというものをさわったことが
あってその頃は業務で遣うというレベルじゃなかったんですが、20年も経てば、
実用レベルになってるんじゃないかという期待もあったりしました。
追加説明(というより釈明)でした。
まだまだご意見お待ちしております。
よろしくお願いします。
さっそくのご意見ありがとうございます。
やっぱりそんなに効果絶大って訳にはいかなさそうですね。
このシステムは準パッケージ製品でして、お客様に導入する時は、お客様向けに少しだけ
手直し(カスタマイズ)して納品するというプロセスを踏みます。この「少しだけ手直し」ってのが
くせ者でして、本来は文字通り少しで済ませ、横展開すればするほどガッチリ！という
ストーリーなんですが、現行の準パッケージ製品の出来がイマイチなため、少しどころか
結構な大手術になってしまって、なかなかガッチリ！にならないのが現状です。
で、エントリー画面のバリデーションのコードは、お恥ずかしながらひどいモノでして、
「if文とcase文のじゅうにひとえや～」って感じなんです。カスタマイズ作業の都度、
「ああ、こりゃあなんてひでえコードなんだ」とぼやいておりまして、そんなものですから、
もーなんとかしたい、あーDroolsなら何とかしてくれるかも...と幻想をいだいてしまった訳です。
むかーし、もう20年近くも前、AIだとかエキスパートシステムというものをさわったことが
あってその頃は業務で遣うというレベルじゃなかったんですが、20年も経てば、
実用レベルになってるんじゃないかという期待もあったりしました。
追加説明(というより釈明)でした。
まだまだご意見お待ちしております。
よろしくお願いします。
wkzk
Dec 19, 2008, 11:40:38 AM12/19/08
to みんなのDrools
うおっ、なるほど～。
確かに外だしで簡潔に記述されていると確かにうれしそうですね～.
そういえば、ちょっと調べてたのですが
RuleFlowはどうでしょうか？
(Drools4からの機能でDrools5から永続機能付き（今回とは関係ないけど））
http://www.redhat.com/docs/ja-JP/JBoss_SOA_Platform/4.2/html/JBoss_Rules_Reference_Manual/sect-JBoss_Rules_Reference_Manual-Rule_Flow.html
私は未経験かつ未調査なのですが場合によっては結構いけそうな。。。
wkzk
> > ご教授くださいませ。- 引用テキストを表示しない -
>
> - 引用テキストを表示 -
確かに外だしで簡潔に記述されていると確かにうれしそうですね～.
そういえば、ちょっと調べてたのですが
RuleFlowはどうでしょうか？
(Drools4からの機能でDrools5から永続機能付き（今回とは関係ないけど））
http://www.redhat.com/docs/ja-JP/JBoss_SOA_Platform/4.2/html/JBoss_Rules_Reference_Manual/sect-JBoss_Rules_Reference_Manual-Rule_Flow.html
私は未経験かつ未調査なのですが場合によっては結構いけそうな。。。
wkzk
>
> - 引用テキストを表示 -
paco
Dec 20, 2008, 3:31:09 AM12/20/08
to みんなのDrools
はじめまして、つしまと申します。
同じくDroolsをバリデーションで使用したことはないので、
ご参考までということで・・・
ルールベースのツールの適用として
書類の不備のチェックとか・・・まさにそれを目的とすることも多いので、
バリデーションでの処理が単純なら、Droolsを使うまでもないと思いますが、
それなりの重みがある処理であればDroolsによる実装を考慮に入れる
余地は十分にあると思いますよ。
Paco
On 12月20日, 午前1:40, wkzk <wak...@gmail.com> wrote:
> うおっ、なるほど～。
> 確かに外だしで簡潔に記述されていると確かにうれしそうですね～.
>
> そういえば、ちょっと調べてたのですが
> RuleFlowはどうでしょうか？
> (Drools4からの機能でDrools5から永続機能付き（今回とは関係ないけど））
>
> http://www.redhat.com/docs/ja-JP/JBoss_SOA_Platform/4.2/html/JBoss_Ru...
同じくDroolsをバリデーションで使用したことはないので、
ご参考までということで・・・
ルールベースのツールの適用として
書類の不備のチェックとか・・・まさにそれを目的とすることも多いので、
バリデーションでの処理が単純なら、Droolsを使うまでもないと思いますが、
それなりの重みがある処理であればDroolsによる実装を考慮に入れる
余地は十分にあると思いますよ。
Paco
On 12月20日, 午前1:40, wkzk <wak...@gmail.com> wrote:
> うおっ、なるほど～。
> 確かに外だしで簡潔に記述されていると確かにうれしそうですね～.
>
> そういえば、ちょっと調べてたのですが
> RuleFlowはどうでしょうか？
> (Drools4からの機能でDrools5から永続機能付き（今回とは関係ないけど））
>
SATO, Tadayoshi
Dec 22, 2008, 9:22:27 AM12/22/08
to jd...@googlegroups.com
佐藤匡剛です。
遅くなりましたが、脇坂さんに指名されましたので、Droolsをバリデーションフレームワーク
として使ったときのことを書きます。
私がやってたのは、Webサービスなシステムでして、Webインタフェースを提供する
サーバと、Webサービス（ビジネスロジック）を提供するサーバの2台構成になってました。
入力データのバリデーションはWebサービス側で必ずやるのですが、Webインタフェースの
側でも同様のバリデーションをできるようにすれば、不要なWebサービス呼出を減らすことが
できるので、WebサービスをWSDLで公開するのと同じように、バリデーションルールをXMLで
公開して、Webサービス側のバリデーションをクライアント側でも実行できるような仕組みを
作っていました。
オーバースペックな感じにも聞こえますが、SOAを狙ったシステムなので、サービスとその
クライアントとはあくまで疎結合にすることが求められていました。
その、Webサービス側のXMLで定義されたバリデーションルールを読み込んで、データモデル
に対してバリデーションを実行するフレームワークを作るのにDroolsを使っていました。
独自定義のXMLからDroolsのルールに変換するのに、Droolsの内部APIを駆使しまくっていた
ので、あんまり一般的な使い方ではなかったかな、と思っています。
http://downloads.jboss.com/drools/docs/4.0.7.19894.GA/apidocs/org/drools/lang/descr/package-summary.html
Droolsの内部APIはドキュメントやJavaDocもほとんど無かったので、ソースコード読みながら
作ってました。今から思うと、あまりオススメできる使い方ではないですね・・・
Droolsのルール言語はかなりの記述力がありますが、なにぶんJavaプログラムではないので、
Eclipseのコード補完やリファクタリングが効きません。Javaで書くのとDrools使うのと、
どっちがメンテ性が高いかはちょっと難しいところですね。
Javaプログラムでバリデーションをもっときれいに書く、たとえばCommons LangのValidateクラス
とか、Commons Validator（？）とか、Hamcrestとか、そういうライブラリを使う、というのは
どうなんでしょうか？
以上、とりとめないメールですが、少しでもご参考になれば。
Shigeaki Wakizaka wrote on 08.12.20 0:37 AM :
--
佐藤 匡剛 <tada...@gmail.com>
http://www.ouobpo.org/
遅くなりましたが、脇坂さんに指名されましたので、Droolsをバリデーションフレームワーク
として使ったときのことを書きます。
私がやってたのは、Webサービスなシステムでして、Webインタフェースを提供する
サーバと、Webサービス（ビジネスロジック）を提供するサーバの2台構成になってました。
入力データのバリデーションはWebサービス側で必ずやるのですが、Webインタフェースの
側でも同様のバリデーションをできるようにすれば、不要なWebサービス呼出を減らすことが
できるので、WebサービスをWSDLで公開するのと同じように、バリデーションルールをXMLで
公開して、Webサービス側のバリデーションをクライアント側でも実行できるような仕組みを
作っていました。
オーバースペックな感じにも聞こえますが、SOAを狙ったシステムなので、サービスとその
クライアントとはあくまで疎結合にすることが求められていました。
その、Webサービス側のXMLで定義されたバリデーションルールを読み込んで、データモデル
に対してバリデーションを実行するフレームワークを作るのにDroolsを使っていました。
独自定義のXMLからDroolsのルールに変換するのに、Droolsの内部APIを駆使しまくっていた
ので、あんまり一般的な使い方ではなかったかな、と思っています。
http://downloads.jboss.com/drools/docs/4.0.7.19894.GA/apidocs/org/drools/lang/descr/package-summary.html
Droolsの内部APIはドキュメントやJavaDocもほとんど無かったので、ソースコード読みながら
作ってました。今から思うと、あまりオススメできる使い方ではないですね・・・
Droolsのルール言語はかなりの記述力がありますが、なにぶんJavaプログラムではないので、
Eclipseのコード補完やリファクタリングが効きません。Javaで書くのとDrools使うのと、
どっちがメンテ性が高いかはちょっと難しいところですね。
Javaプログラムでバリデーションをもっときれいに書く、たとえばCommons LangのValidateクラス
とか、Commons Validator（？）とか、Hamcrestとか、そういうライブラリを使う、というのは
どうなんでしょうか？
以上、とりとめないメールですが、少しでもご参考になれば。
Shigeaki Wakizaka wrote on 08.12.20 0:37 AM :
佐藤 匡剛 <tada...@gmail.com>
http://www.ouobpo.org/
ごとう
Dec 22, 2008, 10:25:47 AM12/22/08
to みんなのDrools
脇坂さま
つしまさま
佐藤匡剛さま
どうもお世話になります。
ごとうです。
貴重なアドバイス、ありがとうございます。
皆様からのメッセージを自分なりに要約してみました。
「うーん、うまくやれば効果あるかもしれないけど微妙だね。だけど
そんなに使いたいんなら、まあやってみたら？」
少し頭が冷えました。そして、かなーり短絡的にDroolsに幻想的期待を
抱いていたことに気がつきました。
現行システムのコードがひどい、ひどい...と思い詰めていた(?)ところに、
Droolsの存在を知り、これを使えば一気に悩みを解消してくれるのではないかと、
すがってしまっていたようです。
現行コードが複雑なのには、次のような理由があると思います。
1) 一カ所で全てのチェックをやろうとしてる
2) 「なんとか区分」とか「なんとか種別」にユーザロジックで意味を持たせている
3) 改修を重ねる中で、誰かがコードブロックをコピー＆ペーストしちゃった!!
:
これらは、Droolsを使うとか以前の問題ですよね。まずはちゃんとモデリングして、
それから、バリデーションの内容とかレベルに応じて、どの層でどのクラスが
バリデーションするかって感じで整理していけば、そんなに複雑にはならない気がします。
今更ですいません。問題をインプリメントで解決しようとするよりも、対象をきちんと分析、
整理する方が解決に近いですよね。
そもそも、「2.2.2. 何時ルールエンジンを使用すべきですか ?」にガイダンスが
書いてありましたね。重ね重ね、申し訳ないデス...
http://www.redhat.com/docs/ja-JP/JBoss_SOA_Platform/4.2/html/JBoss_Rules_Reference_Manual/sect-JBoss_Rules_Reference_Manual-Why_use_a_Rule_Engine-When_should_you_use_a_Rule_Engine.html
まずは Java で書いてみます。で、ちょっと余力があったら、あるいは、
まだDroolsへの思いがくすぶっていたら部分的にでも試してみようと思います。
そのときはご報告させていただきます。ホントかな...。
皆様、どうもありがとうございました。
これから JBoss Seam による開発で悩むことが多いと思います。そのときは
またお世話になります。
今後ともよろしくお願いします。
On 12月22日, 午後11:22, "SATO, Tadayoshi" <taday...@gmail.com> wrote:
> 佐藤匡剛です。
>
> 遅くなりましたが、脇坂さんに指名されましたので、Droolsをバリデーションフレームワーク
> として使ったときのことを書きます。
>
> 私がやってたのは、Webサービスなシステムでして、Webインタフェースを提供する
> サーバと、Webサービス（ビジネスロジック）を提供するサーバの2台構成になってました。
>
> 入力データのバリデーションはWebサービス側で必ずやるのですが、Webインタフェースの
> 側でも同様のバリデーションをできるようにすれば、不要なWebサービス呼出を減らすことが
> できるので、WebサービスをWSDLで公開するのと同じように、バリデーションルールをXMLで
> 公開して、Webサービス側のバリデーションをクライアント側でも実行できるような仕組みを
> 作っていました。
>
> オーバースペックな感じにも聞こえますが、SOAを狙ったシステムなので、サービスとその
> クライアントとはあくまで疎結合にすることが求められていました。
>
> その、Webサービス側のXMLで定義されたバリデーションルールを読み込んで、データモデル
> に対してバリデーションを実行するフレームワークを作るのにDroolsを使っていました。
>
> 独自定義のXMLからDroolsのルールに変換するのに、Droolsの内部APIを駆使しまくっていた
> ので、あんまり一般的な使い方ではなかったかな、と思っています。http://downloads.jboss.com/drools/docs/4.0.7.19894.GA/apidocs/org/dro...
> 佐藤 匡剛 <taday...@gmail.com>http://www.ouobpo.org/
つしまさま
佐藤匡剛さま
どうもお世話になります。
ごとうです。
貴重なアドバイス、ありがとうございます。
皆様からのメッセージを自分なりに要約してみました。
「うーん、うまくやれば効果あるかもしれないけど微妙だね。だけど
そんなに使いたいんなら、まあやってみたら？」
少し頭が冷えました。そして、かなーり短絡的にDroolsに幻想的期待を
抱いていたことに気がつきました。
現行システムのコードがひどい、ひどい...と思い詰めていた(?)ところに、
Droolsの存在を知り、これを使えば一気に悩みを解消してくれるのではないかと、
すがってしまっていたようです。
現行コードが複雑なのには、次のような理由があると思います。
1) 一カ所で全てのチェックをやろうとしてる
2) 「なんとか区分」とか「なんとか種別」にユーザロジックで意味を持たせている
3) 改修を重ねる中で、誰かがコードブロックをコピー＆ペーストしちゃった!!
:
これらは、Droolsを使うとか以前の問題ですよね。まずはちゃんとモデリングして、
それから、バリデーションの内容とかレベルに応じて、どの層でどのクラスが
バリデーションするかって感じで整理していけば、そんなに複雑にはならない気がします。
今更ですいません。問題をインプリメントで解決しようとするよりも、対象をきちんと分析、
整理する方が解決に近いですよね。
そもそも、「2.2.2. 何時ルールエンジンを使用すべきですか ?」にガイダンスが
書いてありましたね。重ね重ね、申し訳ないデス...
http://www.redhat.com/docs/ja-JP/JBoss_SOA_Platform/4.2/html/JBoss_Rules_Reference_Manual/sect-JBoss_Rules_Reference_Manual-Why_use_a_Rule_Engine-When_should_you_use_a_Rule_Engine.html
まずは Java で書いてみます。で、ちょっと余力があったら、あるいは、
まだDroolsへの思いがくすぶっていたら部分的にでも試してみようと思います。
そのときはご報告させていただきます。ホントかな...。
皆様、どうもありがとうございました。
これから JBoss Seam による開発で悩むことが多いと思います。そのときは
またお世話になります。
今後ともよろしくお願いします。
On 12月22日, 午後11:22, "SATO, Tadayoshi" <taday...@gmail.com> wrote:
> 佐藤匡剛です。
>
> 遅くなりましたが、脇坂さんに指名されましたので、Droolsをバリデーションフレームワーク
> として使ったときのことを書きます。
>
> 私がやってたのは、Webサービスなシステムでして、Webインタフェースを提供する
> サーバと、Webサービス（ビジネスロジック）を提供するサーバの2台構成になってました。
>
> 入力データのバリデーションはWebサービス側で必ずやるのですが、Webインタフェースの
> 側でも同様のバリデーションをできるようにすれば、不要なWebサービス呼出を減らすことが
> できるので、WebサービスをWSDLで公開するのと同じように、バリデーションルールをXMLで
> 公開して、Webサービス側のバリデーションをクライアント側でも実行できるような仕組みを
> 作っていました。
>
> オーバースペックな感じにも聞こえますが、SOAを狙ったシステムなので、サービスとその
> クライアントとはあくまで疎結合にすることが求められていました。
>
> その、Webサービス側のXMLで定義されたバリデーションルールを読み込んで、データモデル
> に対してバリデーションを実行するフレームワークを作るのにDroolsを使っていました。
>
> 独自定義のXMLからDroolsのルールに変換するのに、Droolsの内部APIを駆使しまくっていた
wkzk
Dec 22, 2008, 10:42:23 PM12/22/08
to みんなのDrools
佐藤（匡）さん
情報ありがとー＼(^o^)／
今回のQAから、はずれちゃうけどいろいろ考えさせられました。
バリデーションをどこに書くのがいいのか？
HibernateValidatorみたいにEntityに
アノテーションで宣言できるやり方もあるし。
バリデーションロジックの記述が分散されるのも
ちょっといやな気がするし。
（根拠のない心理的なものなのかもしれないけど）
さらにそこから飛躍して（もっと話をずれちゃう(><;）
今時の業務システム(web+db+java)で考えると
validation/ビジネスルールによってはSQLにルールが
埋め込まれてるんですよね。
ERモデルの関連って単なる関連じゃないんですよね。
データベースはプラットフォーム（いいすぎ？）って
思えてならない、休日の昼でした。。。
脇坂
> 佐藤 匡剛 <taday...@gmail.com>http://www.ouobpo.org/- 引用テキストを表示しない -
>
> - 引用テキストを表示 -
情報ありがとー＼(^o^)／
今回のQAから、はずれちゃうけどいろいろ考えさせられました。
バリデーションをどこに書くのがいいのか？
HibernateValidatorみたいにEntityに
アノテーションで宣言できるやり方もあるし。
バリデーションロジックの記述が分散されるのも
ちょっといやな気がするし。
（根拠のない心理的なものなのかもしれないけど）
さらにそこから飛躍して（もっと話をずれちゃう(><;）
今時の業務システム(web+db+java)で考えると
validation/ビジネスルールによってはSQLにルールが
埋め込まれてるんですよね。
ERモデルの関連って単なる関連じゃないんですよね。
データベースはプラットフォーム（いいすぎ？）って
思えてならない、休日の昼でした。。。
脇坂
> 佐藤匡剛です。
>
> 遅くなりましたが、脇坂さんに指名されましたので、Droolsをバリデーションフレームワーク
> として使ったときのことを書きます。
>
> 私がやってたのは、Webサービスなシステムでして、Webインタフェースを提供する
> サーバと、Webサービス（ビジネスロジック）を提供するサーバの2台構成になってました。
>
> 入力データのバリデーションはWebサービス側で必ずやるのですが、Webインタフェースの
> 側でも同様のバリデーションをできるようにすれば、不要なWebサービス呼出を減らすことが
> できるので、WebサービスをWSDLで公開するのと同じように、バリデーションルールをXMLで
> 公開して、Webサービス側のバリデーションをクライアント側でも実行できるような仕組みを
> 作っていました。
>
> オーバースペックな感じにも聞こえますが、SOAを狙ったシステムなので、サービスとその
> クライアントとはあくまで疎結合にすることが求められていました。
>
> その、Webサービス側のXMLで定義されたバリデーションルールを読み込んで、データモデル
> に対してバリデーションを実行するフレームワークを作るのにDroolsを使っていました。
>
> 独自定義のXMLからDroolsのルールに変換するのに、Droolsの内部APIを駆使しまくっていた
> ので、あんまり一般的な使い方ではなかったかな、と思っています。http://downloads.jboss.com/drools/docs/4.0.7.19894.GA/apidocs/org/dro...
>
> 遅くなりましたが、脇坂さんに指名されましたので、Droolsをバリデーションフレームワーク
> として使ったときのことを書きます。
>
> 私がやってたのは、Webサービスなシステムでして、Webインタフェースを提供する
> サーバと、Webサービス（ビジネスロジック）を提供するサーバの2台構成になってました。
>
> 入力データのバリデーションはWebサービス側で必ずやるのですが、Webインタフェースの
> 側でも同様のバリデーションをできるようにすれば、不要なWebサービス呼出を減らすことが
> できるので、WebサービスをWSDLで公開するのと同じように、バリデーションルールをXMLで
> 公開して、Webサービス側のバリデーションをクライアント側でも実行できるような仕組みを
> 作っていました。
>
> オーバースペックな感じにも聞こえますが、SOAを狙ったシステムなので、サービスとその
> クライアントとはあくまで疎結合にすることが求められていました。
>
> その、Webサービス側のXMLで定義されたバリデーションルールを読み込んで、データモデル
> に対してバリデーションを実行するフレームワークを作るのにDroolsを使っていました。
>
> 独自定義のXMLからDroolsのルールに変換するのに、Droolsの内部APIを駆使しまくっていた
>
> - 引用テキストを表示 -
Akihiro habu
Dec 24, 2008, 1:09:10 AM12/24/08
to jd...@googlegroups.com
はじめまして、羽生と申します。
出遅れてしまいましたが、思うところがあり
書かせて頂きます。
Droolsについては5年ほど前にWEB+DB PRESSにて
記事を書かせて頂きました。
その際のバックグラウンドとして、弊社の内部で
検証したのが「バリデーションルールにDroolsを使う」
というものでした。この検証自体は記事にはなっていません。
具体的には、WEB+DBの事例記事になったFX（外為）の
ネット取引のシステムへの適用可能性を検証しました。
結論から言うと、複雑なルールの集合に対しては非常に
開発性・保守性ともに有用と判断しました。
しかしながら、Droolsの仕様に伴う性能のばらつきが
最終的な採用を見送る最大の要因となりました。
以下、順番に説明します。
まず適用を検討したルールというのは、
「新規の買い注文の場合」
「新規の売り注文の場合」
「買いポジションに対する売り注文の場合」
「売りポジションに対する買い注文の場合」
などのように、注文の種別が多数に渡っており、
かつ、それぞれの状態で「金額がｎ以上であれば」
「有効期限がｎであれば」などという項目レベルの
ルールが非常に多く存在するというものです。
真面目に組み合わせを書いていくと、数100通りになります。
これをDroolsのルール記述形式で紋切り型的に
列挙していきました。通常のIF文による記述よりも
断然書きやすく見通しも良かったです。
また修正のしやすさも非常に高かったです。
ここまでが、開発と保守における有用性を実感した部分です。
一方で性能ということですが、これはDroolsに限らず
一般的なルールエンジンに共通しますが、一度評価した
ルールを再度評価するときがあったりします。
要するにルールの総当たりをして、条件に合致しないとなれば
初めて離脱するわけですから、当然です。
ですが、どのルールから適用されるかも一定ではないので
同じデータに対しての評価であっても、0.1秒未満～4秒程度の
ばらつきが確認されました。
このばらつきが相場の変動というものと照らし合わせたときに
リスクになるということで、最終的に採用を見送って苦しみながら
手書きでIF文を書き連ねることで対処しました。
逆に言うと、このばらつきを許容できれば間違いなく採用していた
と断言できます。
以上は5年以上前のことですから、恐らく最新のDroolsであれば
問題をクリアしていることも十分に考えられます。
単純なルールだと正直面倒が先に立ちますが、複雑なものであれば
採用する価値はあると考えます。
蛇足ですが、そのときの経験を活かしてバックトラックしない、
つまり評価順序の一定なルールエンジンというものを作りました。
その一部はOSSとして公開しています。またそれを使って現在も
複雑なバリデーションを実装していますが、お客様に書いてもらった
Excelに少し手を入れるだけできちんと動作するのは、非常に便利です。
バリデーションというのは、間違いなくルールの一種ですから
ルールエンジンに任せるというのは有用だと私は判断します。
以上、多少なりともご参考になれば幸いです。
2008/12/19 23:57 ごとう <ngo...@gmail.com>:
--
株式会社スターロジック
http://www.starlogic.jp/
羽生 章洋（HABU Akihiro）
出遅れてしまいましたが、思うところがあり
書かせて頂きます。
Droolsについては5年ほど前にWEB+DB PRESSにて
記事を書かせて頂きました。
その際のバックグラウンドとして、弊社の内部で
検証したのが「バリデーションルールにDroolsを使う」
というものでした。この検証自体は記事にはなっていません。
具体的には、WEB+DBの事例記事になったFX（外為）の
ネット取引のシステムへの適用可能性を検証しました。
結論から言うと、複雑なルールの集合に対しては非常に
開発性・保守性ともに有用と判断しました。
しかしながら、Droolsの仕様に伴う性能のばらつきが
最終的な採用を見送る最大の要因となりました。
以下、順番に説明します。
まず適用を検討したルールというのは、
「新規の買い注文の場合」
「新規の売り注文の場合」
「買いポジションに対する売り注文の場合」
「売りポジションに対する買い注文の場合」
などのように、注文の種別が多数に渡っており、
かつ、それぞれの状態で「金額がｎ以上であれば」
「有効期限がｎであれば」などという項目レベルの
ルールが非常に多く存在するというものです。
真面目に組み合わせを書いていくと、数100通りになります。
これをDroolsのルール記述形式で紋切り型的に
列挙していきました。通常のIF文による記述よりも
断然書きやすく見通しも良かったです。
また修正のしやすさも非常に高かったです。
ここまでが、開発と保守における有用性を実感した部分です。
一方で性能ということですが、これはDroolsに限らず
一般的なルールエンジンに共通しますが、一度評価した
ルールを再度評価するときがあったりします。
要するにルールの総当たりをして、条件に合致しないとなれば
初めて離脱するわけですから、当然です。
ですが、どのルールから適用されるかも一定ではないので
同じデータに対しての評価であっても、0.1秒未満～4秒程度の
ばらつきが確認されました。
このばらつきが相場の変動というものと照らし合わせたときに
リスクになるということで、最終的に採用を見送って苦しみながら
手書きでIF文を書き連ねることで対処しました。
逆に言うと、このばらつきを許容できれば間違いなく採用していた
と断言できます。
以上は5年以上前のことですから、恐らく最新のDroolsであれば
問題をクリアしていることも十分に考えられます。
単純なルールだと正直面倒が先に立ちますが、複雑なものであれば
採用する価値はあると考えます。
蛇足ですが、そのときの経験を活かしてバックトラックしない、
つまり評価順序の一定なルールエンジンというものを作りました。
その一部はOSSとして公開しています。またそれを使って現在も
複雑なバリデーションを実装していますが、お客様に書いてもらった
Excelに少し手を入れるだけできちんと動作するのは、非常に便利です。
バリデーションというのは、間違いなくルールの一種ですから
ルールエンジンに任せるというのは有用だと私は判断します。
以上、多少なりともご参考になれば幸いです。
2008/12/19 23:57 ごとう <ngo...@gmail.com>:
株式会社スターロジック
http://www.starlogic.jp/
羽生 章洋（HABU Akihiro）
ごとう
Dec 24, 2008, 11:44:10 AM12/24/08
to みんなのDrools
羽生さま
貴重なご意見をいただきありがとうございます。
大変参考になりました。
バリデーションにDrools、大いにアリだ!!
当社の悪評高きバリデーション部分の仕様書はExcelで作られてます。
マトリックスとして作られていて、「なんとか区分が0だったらこのルール、
なんとか区分が1だったら別のるーる」というようなことがマトリックス
形式になっているわけです。これを if 文と case 文でインプリメント
しちゃってるものだか見通しがわるいったらありゃあしなんです。
一度、あるプロジェクトで実験的にこの部分を書き換えてみたことが
あったんですが、あまりうまくいきませんでした。
羽生さんのご意見を伺って、また迷い道へ...
validation の目的はシステムにとって不整合な／ダーティな／都合の悪い
データが入り込むのを防ぐことだといえるのかなあと。だとしたら、システムの
データ整合性に責任があるのは誰なんだろうか。整合性を保つのは誰の
責務にするのが相応しいんだろうか。エンティティクラスには、それ単独で
判断できるようなチェックはやって欲しいし、それよりも単純な例えば
日付形式チェックなんかはプレゼンテーション層でやって欲しいしなあと。
しかし、他のエンティティの状態とか、コンテキスト(これも状態か)によって
あるべき姿が変わる、チェックすべき内容が変わる、しかもそれが結構
複雑だとしたら、だれの責務にしておけばいいんだろうと。
それこそバリデーション専任者をおいて専任者に任せてもよいわけで、
その実装は、ユーザの Java コードでもDrools でもいい。あとは保守性、
性能等の要件を勘案して決めてねってことなのだなあと。
また迷い始めましたが、Drools の適用先として、バリデーションはかなり
適しているうちのひとつだってことはなんとなく理解できました。
やっぱり、まずは Java コードでの実装を前提に設計してみます。
そしてDroolsでの実装も試してみたいと思います。再度、ホントか。
どうもありがとうございました。
しかし、Droolsって、5年前からあったんですか。驚き＋無知さが恥ずかしい。
> 株式会社スターロジックhttp://www.starlogic.jp/
> 羽生 章洋（HABU Akihiro）
貴重なご意見をいただきありがとうございます。
大変参考になりました。
バリデーションにDrools、大いにアリだ!!
当社の悪評高きバリデーション部分の仕様書はExcelで作られてます。
マトリックスとして作られていて、「なんとか区分が0だったらこのルール、
なんとか区分が1だったら別のるーる」というようなことがマトリックス
形式になっているわけです。これを if 文と case 文でインプリメント
しちゃってるものだか見通しがわるいったらありゃあしなんです。
一度、あるプロジェクトで実験的にこの部分を書き換えてみたことが
あったんですが、あまりうまくいきませんでした。
羽生さんのご意見を伺って、また迷い道へ...
validation の目的はシステムにとって不整合な／ダーティな／都合の悪い
データが入り込むのを防ぐことだといえるのかなあと。だとしたら、システムの
データ整合性に責任があるのは誰なんだろうか。整合性を保つのは誰の
責務にするのが相応しいんだろうか。エンティティクラスには、それ単独で
判断できるようなチェックはやって欲しいし、それよりも単純な例えば
日付形式チェックなんかはプレゼンテーション層でやって欲しいしなあと。
しかし、他のエンティティの状態とか、コンテキスト(これも状態か)によって
あるべき姿が変わる、チェックすべき内容が変わる、しかもそれが結構
複雑だとしたら、だれの責務にしておけばいいんだろうと。
それこそバリデーション専任者をおいて専任者に任せてもよいわけで、
その実装は、ユーザの Java コードでもDrools でもいい。あとは保守性、
性能等の要件を勘案して決めてねってことなのだなあと。
また迷い始めましたが、Drools の適用先として、バリデーションはかなり
適しているうちのひとつだってことはなんとなく理解できました。
やっぱり、まずは Java コードでの実装を前提に設計してみます。
そしてDroolsでの実装も試してみたいと思います。再度、ホントか。
どうもありがとうございました。
しかし、Droolsって、5年前からあったんですか。驚き＋無知さが恥ずかしい。
> 羽生 章洋（HABU Akihiro）
Reply all
Reply to author
Forward
0 new messages