集成Java Webapp + drools + Guvnor的方式和价值是什么? [英] How and is it worth to integrate Java Webapp + drools + Guvnor?

查看:159
本文介绍了集成Java Webapp + drools + Guvnor的方式和价值是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正计划引入Java规则,目前正在评估Drools以从物理上和逻辑上将应用程序中的业务规则外部化.

I am planning on introducing Java rules and currently in the process of evaluating Drools to externalize (physically and logically) the business rules from the application.

由于这些业务规则经常由企业使用,因此我希望该业务通过GUI对该规则进行必要的更改.

Since these business rules would be very often by the business, I would want the business to make necessary changes to the rules via GUI.

我在Google上集成了Java Web应用程序+ Drools + Guvnor,但我一无所获.

I have Googled on integrating java web app + Drools + Guvnor and I'm not getting anywhere.

我的问题:

  1. Drools是否支持轻量级GUI来编辑规则?
  2. Drools Guvnor是轻量级的GUI,还是有办法降低它的使用率?
  3. 将应用程序集成到Guvnor以读取规则有多容易?

关于集成Java应用程序+ Drools + Guvnor的简单实现的任何其他建议都是很好的.

Any other suggestions on the generally a Simple implementation of Integrating Java Application + Drools + Guvnor would be great.

任何指向教程的指针也将为我做到这一点.

Any pointers to tutorials would also do it for me.

推荐答案

我正在做与您想做的事情类似的事情.

I'm in the process of doing something akin to what you want to do.

由于这些业务规则经常由企业使用,因此我希望该业务通过GUI对该规则进行必要的更改.

警告警告警告!这是一个普遍的误解,即只要有GUI,非程序员都可以使用它.那不是我得出的结论.它有帮助,但是编程的难点不是写代码,而是针对正确的问题提出了很好的解决方案.我敢肯定,有些更聪明,技术上更偏向商务的人可以用Guvnor做事,但是不要指望这是通向极乐世界"的黄砖砌成的道路.您仍然必须为业务人员提供一个理智的数据模型和API,使他们可以执行所需的工作,但可以防止他们偶然地执行不想执行的操作.

WARNING WARNING WARNING!!! It's a common misconception that as long as there's a GUI, non-programmers can use it. That's... not the conclusion I've come to. It helps, but the hard part of programming isn't writing code, it's coming up with good solutions to the right problems. I'm certain some of the more intelligent and technically inclined business folks can do stuff with Guvnor, but don't expect it to be some kind of yellow brick road to the Land of Magical Bliss. You still have to provide the business people with a sane data model and API which lets them do what they need but which prevents them from doing by accident what they don't want to do.

1. Drools是否支持轻量级GUI来编辑规则?

2. Drools Guvnor是轻量级的GUI,还是有降低它的方法?

嗯,轻量级"是讨论的主题,但是Guvnor可以很好地工作,并且不需要浏览器,因此我认为还可以.

Well, "lightweight" is subject for discussion, but Guvnor works fairly well and doesn't require more than a browser, so I think it's OK.

3.将应用程序集成到Guvnor以读取规则有多容易?

好吧,一旦Guvnor启动并运行,连接您的应用程序以使用KnowledgeAgent连接到Guvnor并监听新规则更新就不是特别困难.

Well, once you've got Guvnor up and running, wiring up your application to use a KnowledgeAgent to connect to Guvnor and listen for new rule updates isn't particularly hard.

不幸的是,一般而言,Drools尤其是Guvnor都有很多怪癖,您可能需要解决这些怪癖(例如,您必须分解Guvnor WAR文件并编辑WEB-INF/beans.xml中的文件才能进行设置)非默认配置...).但是,一旦您弄清楚了这一点,我认为它会很好地工作.

Unfortunately, Drools in general and Guvnor in particular has a bunch of quirks which you may have to work around (for instance, you have to explode the Guvnor WAR file and edit files in WEB-INF/beans.xml to set up a non-default configuration...). But once you've got that straightened out, I think it works pretty well.

关于文档,Javadocs有时可能会比较稀疏,但是网站有一些不错的东西,包括几本书.

As for documentation, the Javadocs can be a bit sparse at times, but the web site has some pretty good stuff, and including several books.

总而言之,Drools和Guvnor是功能强大的工具,但是让它们正常工作并非易事.如果您确实需要它们所提供的东西,那是值得的,但是如果更简单的脚本解决方案就足够了,那也许也值得考虑.

All in all, Drools and Guvnor are powerful tools, but it's not trivial to get them working. If you really need what they have to offer, they're worth it, but it might also be worth considering if a simpler scripting solution will suffice.

现在,如果您发现自己确实需要Drools,这是我的首要建议-为数据库和规则保留单独的数据模型.这确实意味着有很多无聊的转换代码要编写,但这是值得的.

Now, if you find yourself actually needing Drools, here's my top piece of advice - keep separate data models for your database and your rules. It does mean there's a lot of boring conversion code to write, but it's well worth it.

我正在使用的应用程序将JPA用于数据库事务,并且在我们的规则中使用该数据模型并不是一件令人愉快的事情.几个原因:

The app I'm working on uses JPA for database matters, and it wouldn't have been very pleasant to use that data model in our rules. Several reasons:

适合您的数据层并不一定适合Drools,反之亦然.

我们有一个树形结构,在JPA中自然是与父节点列表中的子代之间的@OneToMany关系.在Drools中使用列表非常麻烦,因此我们将其展平为一个结构,在该结构中插入一个ParentNode对象和一堆ChildNode对象,这比使用起来容易得多.

We have a tree structure, which in JPA naturally is a @OneToMany relation with the children in a list in the parent node. Working with lists in Drools was rather painful, so we flattened it to a structure where we insert one ParentNode object, and a bunch of ChildNode objects, which was far easier to work with.

敢于重构.

规则的数据模型也必须存在于Guvnor中-这意味着如果重命名实体类或类似的东西,则可能会破坏所有规则.规则的单独数据模型意味着您可以无忧地重构数据库内容.

The rule's data model needs to live inside of Guvnor, too - and that means you could break all rules if you rename an entity class or something like that. A separate data model for rules means you can refactor your database stuff without worries.

向他们展示他们需要看的东西.

数据库可能会变得相当复杂,但是规则通常不需要关心其中的许多复杂性.将这些复杂性暴露给人们编辑规则可能会引起很多不必要的混乱.例如,我们发现对于我们的场景,绝对不需要使规则编写者暴露于多对多关系(事实证明,在Drools中处理起来非常复杂)-因此,我们使它们看起来像一对多,一切都会变得更加自然.

Databases can grow fairly complex, but the rules normally don't need to care about many of these complexities. Exposing these complexities to the people editing rules can cause a lot of unnecessary confusion. For example, we've found that for our scenarios, there's absolutely no need to expose rule writers to many-to-many relationships (which proved very complicated to handle in Drools) - so we make them look like one-to-many instead, and everything becomes more natural.

保护.

我们已将大多数规则设计为类似于以下伪代码:

We've designed most our rules to work like this pseudo-code:

rule "Say hello to user"
when 
  user : User
then
  insert(new ShowMessageCommand("Hello " + user.getName() + "!"))
end

...,因此,对于每个规则包,都明确定义了您可以插入哪些响应命令以及它们的作用.在我们的应用中运行规则之后,我们会选择规则插入到会话中的对象并对其执行操作(

... and so, for each rule package, it's clearly defined which response commands you can insert, and what they do. After we've run the rules in our app, we pick out the objects inserted into the session by the rules and act upon them (the visitor pattern has proven very useful to avoid long if instanceof/else if instanceof/else chains).

我很高兴我们以这种方式做到了这一点,而不是让规则编写者做他们想对我们的JPA对象做的任何事情.

I'm very happy we did it this way, instead of letting the rule writers do whatever they think they want to do with our JPA objects.

无论如何,希望这会有所帮助.

Anyway, hope this helps.

这篇关于集成Java Webapp + drools + Guvnor的方式和价值是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆