|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 41
Messages: 41
Messages: 41
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
TSS Article: An Introduction to the Drools Project
In this article, Alex Rupp discusses how Rules Engines can improve the agility of your business by helping you isolate the "logic of the bottom line" from the technical logic of your software applications. He introduces the JSR-94 Rules Engine API and an open source product called Drools, an implementation of this up-and-coming technology.
Read The Logic of the Bottom Line - An Introduction to the Drools Project
|
|
|
Message #124091
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS Article: An Introduction to the Drools Project
some time ago I got some interest about it, but it's poor&fragmental doc failed me. I have to turned to JESS recently
|
|
|
Message #124095
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How does it compete with JESS
Same here, I went through the drools website but could not find enough docs. to get me started. Eventually I had to turn to JESS. Also because its more mature and there's a book "JESS in action" available.
/t
|
|
|
Message #124130
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Evaluation Reports on Rules Engine
Is there any evaluation report on the open source products of rules engine? What's the common features of rules engine? What's the advantage and disadvantage of the specific product? Which one is popular one and widely adopted?
|
|
|
Message #124133
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
about mandarax..
Hey Colin,
Thanks for your post.
Have been looking for a rule engine which regards _retrieving the proof_
as worthy enough to be in the docs and API !
Haven't really tried it yet but looks nice.
Some might view yours as a 'shameless plug', but drools seemingly not moving
anywhere these days(?) -docs or otherwise-, other good OS rule engines certainly
deserve as much attention as d(ead?)rools
|
|
|
Message #124134
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
about drools..
To the good folks at drools:
Just read in the article "Drools is approaching its 2.0-beta-14 release"
..so isn't dead at all, also has JSR-API support, which is good.
I apologize for my hasty judgement on drools.
But still I am missing in drools: _getting the proof_ , good docs
|
|
|
Message #124147
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RETE vs. PROLOG
Be careful to compare apples to apples (or oranges to oranges if you want).
You may find that the PROLOG based backward-chaining rules engines are not performant enough for your needs...
|
|
|
Message #124203
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
drools is alive!
drools is alive! its just not very active :)
yes, more documentation is needed and articles such as this help address that deficiency. things are looking good!
|
|
|
Message #124207
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No shame in plugging
Some might view yours as a 'shameless plug', but drools seemingly not moving anywhere these days(?) -docs or otherwise-, other good OS rule engines certainly deserve as much attention as d(ead?)rools There's no shame in plugging other projects or in criticizing our documentation, but please let's keep things clean and fair around here. I think Drools is a great product, and with a little more momentum, it could be a fantastic Open Source project.
When I started working with Drools, I was attracted to the JSR-94 interface layer, because I could use it to get started with Rules engines, without much fear of vendor lock-in (even from an Open Source project--it's the principle of the thing that matters).
What I found was that the JSR-94 module for Drools had been shut down, the tests turned off and the code left unfinished. Also, there wasn't very great documentation for it. But I didn't gripe about it. It's an Open Source project, and the guys who wrote it are busy working on other stuff. I downloaded the code from CVS, hopped on the project IRC channel at irc.codehaus.org/#drools, asked a few questions and took some initiative. In a couple of weeks I'd finished the JSR-94 module, got the tests running, and added a top-level maven build. Now I'm working on documentation and articles to help others get started with Drools, and doing whatever I can to promote what I consider a very good project. That is how Open Source projects get written.
I don't think the Jess or Mandarax guys have anything to be ashamed of by letting other people know about their projects. If their PR guys or user evangelists want to ride on my coattails and plug their projects, so be it (nothing like a good-natured inflammatory comment to stir up the crowd ;)
But I'll have you know--this project is not dead. I know the documentation sucks--I had to figure out how it all worked by digging around in the code. Now I'm working on more and better documenation, example code, and the like, and I'd encourage anyone who wants to participate to come hang out with the rest of the developers in IRC.
Besides, anything beats paying $25k per processor per year for a license to the BizTalk rule engine, right?
|
|
|
Message #124215
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No shame in plugging
Besides, anything beats paying $25k per processor per year for a license to the BizTalk rule engine, right? Yep. Because it doesn't stop there because of all the other things you will need or have to use because of the platform choice.
|
|
|
Message #124224
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS Article: An Introduction to the Drools Project
That example is scary. The "rules" embedded in XML are integers, strings, and floating points. You might as well give the "executive" pre-build SQL queries and tell him to go to town on the database. The only increase in security your "XML rules" have over raw SQL is that there are more failure points (thanks to the complexity of XML parsing) so the likelihood that he breaks something important on accident with a typo or accidentally malicious query is reduced directly proportional to to probabilility your system will fail due to invalid data.
|
|
|
Message #124233
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Vendor lock-in
I could use it to get started with Rules engines, without much fear of vendor lock-in All you are gaining via the JSR is no code changes to move to a different vendor. You would still have to convert your rules into the language/syntax of the vendor you are trying to port to, which, for a decent sized application could be a major effort. I wish that there was more standardization in the JSR/JCP regarding the rule definition language. That would be true vendor independence.
|
|
|
Message #124268
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No shame in plugging
I appreciate these open-sources guys' work.And I also know clearly about the hardness of rolling the ball.
If u can't afford the time for a comprehensively docs, may I suggest you to supple a sample program for ppl to get started, it's easy and very helpful.
|
|
|
Message #124280
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BizTalk does not have a real chaining rule engine
Besides, anything beats paying $25k per processor per year for a license to the BizTalk rule engine, right? Yep. Because it doesn't stop there because of all the other things you will need or have to use because of the platform choice.
If I'm not mistaken, BPML is converted to SQL in Biztalk. Strictly speaking BizTalk is not a rule engine and doesn't provide any chaining capabilities. It is strictly procedural. This approach has been tried numerous times in the past to great failures. A backward or forward chaining rule engine is much more powerful, since rules are compiled into a network of nodes.
|
|
|
Message #124319
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No shame in plugging
Good article Alex.
I'd like to see the JSR improved to allow the back-end be pluggable - perhaps using Service Data Objects. This would allow me to store my rule configuration in a relational database, an xml database, a DRL file or something else. I'd also prefer to see a rules description language as a standard - it helps with portability and reduces the learning curve. As with EJB3.0 I guess some of this could be meta-data driven.
Other items amongst my wish list - the ability to intercept the execution of a rule (for logging for example rather than stopping execution) - similiar to the servlet filters concept, the use of a composite pattern to allow rulesets to contain other rulesets, standardisation of concepts (perhaps alignment with the OMG spec.).
I also think that DROOLS has potential but as a user its frustrating to work with.
|
|
|
Message #124320
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rule Building using gui, xml and xslt
An XML language is not ideal by any standard, but its a start - the goal is to definitely move away to a more user oriented langauge. To leverage what we have in a usefull way I instead create "rule building" screens for specific problem domains, in this case absence tracking. A business user can define how things like service, age grade affect the base entitlement or how warnings and resets happen on carryovers - this is all country specific and doing it programmatically is not desirable.
The rule builder screens store their information in a DB which I dump to XML I then have XSLT transfer them into drools DRL files - this works great, it means I have a generic framework to allow users to build rules within a given/known problem domain. The only work I do is in building/tailoring the rule building screens and in the XSLT files to map the various options to a a resulting DRL. So I can concentate of programming a framework, not on business rules, and business concentrate on building the rules. If we change vendor I only need to update the XSLT files to output the rules to a different format.
As each rule builder screen is tailored to the problem domain it presents the relevant facts, conditions and consequencs that make sense to the current context so little training is needed.
|
|
|
Message #124322
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS Article: An Introduction to the Drools Project
Technical support or development should be the only people able to edit the configuration of rules manually. Otherwise - as you say it ends up being a complete nightmare. For example, DROOLS allows the adding of Java expressions in its ruleset configuration files. These expressions are only evaluated at run-time.
BTW. this does not exclude the use of a user interface with validation constraints that subsequently regenerates the ruleset files.
|
|
|
Message #124327
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
www.javarules.org/
More general information on rule-based programming in Java:
http://www.javarules.org/
If you would like to discuss ideas for future evolutions of the Java Rule Engine API please subscribe to the mailing list on the site.
All contributions welcome.
Sincerely,
Daniel Selman
|
|
|
Message #124330
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
the challenge with declarative rules
I've been using Rete Rule engines since 2K and often the hardest part of implementing rules is the learning curve. It takes time and patience to really think in a declarative mode to optimize pattern matching. If you look at the questions on Jess mailing list and countless other mailing lists for Expert Systems, you'll see people try to wedge procedural logic into rules. For those who are interested in Rule engines and more specifically Rete algorithm, I would recommend Earnest's Jess In Action from manning. Drools is a backward chaining engine that implements a modified version of Rete. Mandarax on the other hand is a query based rule engine and doesn't implement Rete. It fits well into query centric applications, but it is difficult to scale to large datasets. Query based rule engies are better suited to applications that use small amounts of data, which means the queries should ideally return atomic facts and not thousands of rows of data. Backward chaining rule engines are often used in ECA (event condition action) systems. In practice, you don't need a backward chaining rule engine to implement ECA. Forward chaining rule engines can achieve the same result. Most of the modern Java Rule engines can achieve 30-80K rule activations per second on a 1.4ghz CPU with Jdk1.4.x.
|
|
|
Message #124352
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS Article: An Introduction to the Drools Project
Very good article. One thing not mentioned is the extent of a Rule Engine approach applicable in a project. It appears on first reading that these just allow conditional logic to be made declaritive.
However, in the 'old' large IT corporate industry, a Business Rule system is much more then that (see for example, the book "Business Rules Applied"). Do the Rule Engine's mentioned, like Drools, allow use for "Business Rule" use? According to the Drools document, Drools is not intended for Business Rules that use a 'higher-level' form, that do not use the if-then format, see the drools-manual-2.0-beta-13, section 3.4.
Or is this just a notational issue, and transforms are applicable?
--- J. Betancourt
|
|
|
Message #124357
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS Article: An Introduction to the Drools Project
The JSR and Drools allows for the use of logical rules (if-else conditions). These are lower-level than business rules. Business rules can be written as a combination of these logical rules along with a mapping exercise.
To create a business rule you need a ruleset. But currently a ruleset cannot contain a another ruleset which is a problem. There are vendor-dependant ways to work around this.
|
|
|
Message #124372
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Differences between engines
Correct me if I'm wrong on the difference between a Rete style system and a Backward Chaining (BC) system.
Using the example of "What is the discount for customer X".
My understanding is that for a Rete system, all of the factors related to, in this case, pricing are presented to the rule set, and as those factors are interpreted and distributed through the system, eventually the "discount" bucket will be populated correctly.
So, in essence, you provide the "facts" of the example to the system, and then you'll simply pull out the result (in this case the discount).
With a BC system, instead you present it with the base query and the engine then determines from its rule what facts it actually needs to come up with a correct result.
Consider that perhaps the three criteria necessary to determine discount are Customer Type, Customer Volume, and, Customer History to calculate a Loyatly Bonus.
In a Rete system, we must "know" that we have to provide Type, Volume, and History to the system in order to determine Discount, whereas in a backward chaining system, the system will inevitably ASK for those pieces of data.
As a corollary though, it seems that Rete systems are better designed to be reactive, whereas BC are more informative.
Simple example, if you want to send an email to the Account Manager when a Customers outstanding balance is approaching some credit limit, in a Rete system, you'd simply add a rule "If creditBalance - outstandingBalance < margin then email manager", and that would "automatically" be fired when either the creditBalance or outstandingBalance were changed. In a BC system, wouldn't you need to have a nightly process "asking" if an email needed to be sent? Rete systems figure things out as the data comes in, where as BC system figure things out as the questions are asked. Is that a good distinction between the two?
I'm in a quandry with our system, on which we have a hacked, very coarse rule system.
On the one hand, the Rete system makes a lot of sense, as most of our things are event based "if this changes then do that". But, we have hundreds of variables for each case, as well as the entire history of those variables. So, it seems execessive to have to load the entire data set to manage the changing of a single variable. On the other hand, a BC system would fetch the data as required (which is what our generic java code does anyway), but how does it "know" which rules to fire? Currently we coordinate this stuff by hand "when variable X changes, do rules A, B, C". A better rule system would make those associations automatically.
Perhaps I'm completely missing the boat, and the two systems are essentially identical with only subtle difference at the fringes of the bell curve.
Finally, does anyone have a good online reference to the Rete algorithm? Everything I've seen points to an AI magazine article from, like, 1982, and I've never seen it discussed in any real detail online.
|
|
|
Message #124392
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rete reference
The "Jess in Action" contains a good overview of the Rete algorithm. Also, check out the Rete section on Ernest Friedman-Hill's Jess page at:http://herzberg.ca.sandia.gov/jess/docs/61/rete.html As does the ILOG JRules documentation! See the "Rule Engine User's Manual" for example. ;-)
Also note that JRules (as well as other commercial rule engines) also support multiple execution algorithms for when the stateful nature of RETE is not required.
Go download an eval (http://www.ilog.com/products/jrules/) and you will see that much of the value of business rules comes from the tool support that enables business users to author/edit rules in a controlled way with minimal interaction with IT. This includes using higher-level authoring constructs like decision tables or decision trees.
JRules 4.6.x includes a rule-enabled version of Petstore (what else!) that runs out of the box (on Tomcat+JOnAS+HSQLDB) for you to tinker with.
Sincerely,
Daniel Selman
Product Manager
ILOG JRules
|
|
|
Message #124399
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
License for JESS
Same here, I went through the drools website but could not find enough docs. to get me started. Eventually I had to turn to JESS. Also because its more mature and there's a book "JESS in action" available./t I have read that the license is $10.000 (Google: jess + license).
Is that true ?
Best regards,
Andres
|
|
|
Message #124400
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It can be, but not necessarily
Correct me if I'm wrong on the difference between a Rete style system and a Backward Chaining (BC) system.Using the example of "What is the discount for customer X".My understanding is that for a Rete system, all of the factors related to, in this case, pricing are presented to the rule set, and as those factors are interpreted and distributed through the system, eventually the "discount" bucket will be populated correctly.So, in essence, you provide the "facts" of the example to the system, and then you'll simply pull out the result (in this case the discount).With a BC system, instead you present it with the base query and the engine then determines from its rule what facts it actually needs to come up with a correct result.Consider that perhaps the three criteria necessary to determine discount are Customer Type, Customer Volume, and, Customer History to calculate a Loyatly Bonus.In a Rete system, we must "know" that we have to provide Type, Volume, and History to the system in order to determine Discount, whereas in a backward chaining system, the system will inevitably ASK for those pieces of data.As a corollary though, it seems that Rete systems are better designed to be reactive, whereas BC are more informative.Simple example, if you want to send an email to the Account Manager when a Customers outstanding balance is approaching some credit limit, in a Rete system, you'd simply add a rule "If creditBalance - outstandingBalance < margin then email manager", and that would "automatically" be fired when either the creditBalance or outstandingBalance were changed. In a BC system, wouldn't you need to have a nightly process "asking" if an email needed to be sent? Rete systems figure things out as the data comes in, where as BC system figure things out as the questions are asked. Is that a good distinction between the two?I'm in a quandry with our system, on which we have a hacked, very coarse rule system.On the one hand, the Rete system makes a lot of sense, as most of our things are event based "if this changes then do that". But, we have hundreds of variables for each case, as well as the entire history of those variables. So, it seems execessive to have to load the entire data set to manage the changing of a single variable. On the other hand, a BC system would fetch the data as required (which is what our generic java code does anyway), but how does it "know" which rules to fire? Currently we coordinate this stuff by hand "when variable X changes, do rules A, B, C". A better rule system would make those associations automatically.Perhaps I'm completely missing the boat, and the two systems are essentially identical with only subtle difference at the fringes of the bell curve.Finally, does anyone have a good online reference to the Rete algorithm? Everything I've seen points to an AI magazine article from, like, 1982, and I've never seen it discussed in any real detail online. I'm most familiar with Jess, so I'll use it as an example. Jess can work in both forward and backward chaining. The normal mode of operation with Jess is you add an object to the rule engine using definstance method. The rule engine converts the object to unordered facts and asserts them to the working memory of RETE. when that happens, the facts begin at the root node of the object and traverse through the RETE network.
Say you have this rule, "if the balance is less than 100.00 and there's no pending deposit, send an email notice to the customer." If I add the a withdraw transaction to the rule engine, it will perform the pattern matching for the first condition. If my account data isn't in the working memory, the rule won't fire. If my account information is already in the rule engine, the rule engine will fire if I have no pending deposits. If we run this same scenario in BC mode, the rule engine would match on the withdraw transaction and update the join node to the next condition. Assuming the app is setup to query the database, it would fetch the data and assert it to the working memory. If both conditions are satisfied, the engine would fire the rule.
For me, BC is a powerful tool for figuring out "what conditions do I need to satisfy a rule." I'm definitely biased on this topic, so take this with a grain of salt. Running an engine in BC mode and letting it query automatically can lead to undesirable results, like loading a ton of data unnecessarily. To avoid that, you have to code the rules and queries such that you get the smallest piece of data from the database. I prefer to separate the logic of what data is needed with the actual reasoning in two components. This way, the reasoning process happens very quickly and the process of getting data doesn't block the rule engine. Forward chaining can achieve the same query like process, but that's a complex topic.
|
|
|
Message #124402
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ILOG
I know this is supposed to be a Drools plug, but I must say, ILOG is definitely a very good product. The only product I could find (sometime back when I was evaluating) that allows a non-IT person to create business rules in a natural-english language via a web browser (not forced to use the rule builder GUI). It's got a nice, intuitive web interface for rule building. For most other products, you would have to build your own high level, natural language to low level,vendor-specific translation. The demo is definitely worth checking out.
|
|
|
Message #124429
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Example applications
... If u can't afford the time for a comprehensively docs, may I suggest you to supple a sample program for ppl to get started, it's easy and very helpful. We've got a module in CVS with three example applications. We also have a lot of unit tests. The tests in the JSR-94 package do a great job of showing how to use the Java semantics. In addition, I'm working on a tutorial with it's own "dirt-simple" example, so beginners can get started. Things are coming along :)
|
|
|
Message #124431
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Great points--it's a start, though
I could use it to get started with Rules engines, without much fear of vendor lock-in All you are gaining via the JSR is no code changes to move to a different vendor.
Believe me, that's a great start! God I love open standards :)You would still have to convert your rules into the language/syntax of the vendor you are trying to port to, which, for a decent sized application could be a major effort. One of the huge attractions for Drools is that I can write my own Domain Specific Language. As long as other vendors have some sort of semantic module framework like Drools has, I should be able to write a compability layer for other engines (which would probably end up being easier than porting all the rules). At least the client code has a common interface. I know it isn't perfect independence, but then again it turned out that I became a developer in the project, which I wasn't really expecting. That's almost as good as competely avoiding vendor-lock in.I wish that there was more standardization in the JSR/JCP regarding the rule definition language. That would be true vendor independence. Or, perhaps the next JSR could address the requirements for building a Drools-style semantics language framework. The SMF and IO modules in Drools are very simple, straightforward, and they allow an incredible degree of language independence.
Very good points, though :)
|
|
|
Message #124432
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Yeah, the example isn't the best.
Yeah, the example is pretty scary. Obviously, you'd want to write a Domain Specific Language for working with the rules and give the executives a GUI editing tool. That's just common sense, but I couldn't hack out a complete DSL and toolset for this article--I'll work toward that in future articles, though :)
Thanks for the feedback. I appreciate it :)
--
Alex
|
|
|
Message #124434
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Vendor-specific AST objects
Good article Alex. : )I'd like to see the JSR improved to allow the back-end be pluggable - perhaps using Service Data Objects. This would allow me to store my rule configuration in a relational database, an xml database, a DRL file or something else. While the moniker "AST" might not be fitting, the API does allow for the creation of RuleExecutionSet objects from vendor-specific objects. So, presumably, you could write an implementation that supports everything you've mentioned above. I'll have a talk with Bob about it and see what we can do--I've thought the same myself.I'd also prefer to see a rules description language as a standard - it helps with portability and reduces the learning curve. Actually, rather than standardizing the rule description language, it might be better to standardize something similar to Drools' semantics module framework. Then application developers could customize their own Domain Specific Languages and write a quick-and-dirty compatibility layer to hook it into the SMF. If you look at how the Java semantics library hooks into the SMF in Drools, you'll see how simple this is. My next article is going to explore this concept in depth.As with EJB3.0 I guess some of this could be meta-data driven.Other items amongst my wish list - the ability to intercept the execution of a rule (for logging for example rather than stopping execution) We actually have an experimental AOP branch that does exactly this. We use AspectJ to monitor events in the WorkingMemory. It's very useful for debugging and performance monitoring. You can probably expect to see it in the beta-14 release.similiar to the servlet filters concept, the use of a composite pattern to allow rulesets to contain other rulesets, I've been kicking around some ideas in my head for how to better organize Rule Execution Sets for doing composite patterns. If there were a distinction in the JSR API between RuleExecutionSets and RuleSets, we'd be able to cobble together RESs. Bob and I have asked about this a couple of times. We're also looking into ways to execute Rule subsets, but I don't know how quickly these features will make it into a release.standardisation of concepts (perhaps alignment with the OMG spec) That gives me the willies. I'd rather write a Business Rule Language semantics module to plug into the Drools SMF than to drag the OMG stuff into the JSR. Just Say No.I also think that DROOLS has potential but as a user its frustrating to work with. Hey, man, I sympathize and take your feedback seriously. I consider myself a user as well, and it can get tough. It helps for people to be able to tell us that in a forum where we have to listen (this was a major part of my impetus for writing the article). The test now is whether or not the project's members and developers respond. But there's a lot of room for new users and developers to get involved as well. The cool thing about the project is that it's wide open for enterprising users to get involved as developers and contributors. I'm working on the documentation, and on getting the drools.org site migrated to the Confluence docs section of Codehaus (http://docs.codehaus.org/display/DROOLS/Home).
Thanks for the feedback, man--I appreciate it.
--
Alex
|
|
|
Message #124435
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Domain Specific Languages
An XML language is not ideal by any standard, but its a start - the goal is to definitely move away to a more user oriented langauge. Mark's right here, and there's been some talk about it in the IRC channel. I wrote a Java.net blog on Domain Specific Languages (http://weblogs.java.net/pub/wlg/1359).
It's tough to talk about DSLs without having pictures, but high level and narrowly-scoped languages captured in innovative UIs and tool sets are definitely the future of this. DSLs can more easily be translated to code or XML, which is where the Drools SMF comes in. Being able to support any type of XML you want makes Drools an incredibly powerful competitor as far as Rule Engines go.
I've only just begun to explore the possibilities of that myself, and I'll cover the topic in greater depth in future articles.
|
|
|
Message #124436
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Already exists in Jess and ILog
If there were a distinction in the JSR API between RuleExecutionSets and RuleSets, we'd be able to cobble together RESs. Bob and I have asked about this a couple of times. We're also looking into ways to execute Rule subsets, but I don't know how quickly these features will make it into a release. I believe both Jess and ILog have the concept of modules, which basically achieves the same results as executionsets. Modules in Jess are very power and allow you to manage execution of rulesets into separate modules. If I'm not mistaken, quite a bit of research in this topic occurred in the 80's and early 90's. The concept isn't new and the major Rete engines already have it. Also, JSR94 uses jess for the reference implementation. There have been several papers in the past using the concept of modules to categorize large rulesets. The resulting modules could then run within the same rule engine, or be distributed across multiple machines. ACMQueue has some of these old papers, so look there and you'll see some useful information.
|
|
|
Message #124513
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Domain Specific Languages
Would it be possible to generate the DSL from your Domain Model? So when you're "MDA-ing" your code you also spit out the DSL?
Just wondering...
|
|
|
Message #125649
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who's actually going to use it ?
From a techie point of view rules engines are great. But realistically who's going to be using them. In the article there was mention of techno savy managers or whatever who're going to write the rules in xml. Come on guys, business people DON'T want to know about anything technical, that's what the techies are for. For those old timers out there, remember the days when case tools which could automatically generate "business logic" code were in vogue, where are they now ? We've been down a variant of this path before. Rule Engines are great for non-business type industries, where the main users are technical in nature e.g. biotech, .... But they'll never gather enough momentum in the business world to take off.
|
|
|
Message #308127
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Help required in drools
Can someone please send me a sample drl file which has java functions in it? My requirement is as follows:
I have a set of rules in a xml file. I need to read the xml and store the values in a HashMap.How do i do this in a drl file?
|
|
|
Message #326123
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Announcing RulesWorld.com
Please join www.rulesworld.com today. This is an open business rules modeling and collaborative community designed to educate the market about the value of rules. RulesWorld also provides to community members, at no cost, Corticon's flagship Business Rules Modeling Studio (a $5K per seat value). This is not a crippled version of the product. It’s full featured and is meant to give the user a complete rule modeling experience.
We believe that until users are hands-on, they can’t fully appreciate the value of business rules and to know what to look for in a BRMS. We therefore have lowered the barrier to entry and allow community members to use rules without having to invest any money upfront. Users can:
• capture their business policies as rule models
• analyze rule models to:
o ensure completeness of their policies
o identify/resolve policy conflicts and loopholes
o remove policy redundancies
• scenario test rule models to see them in action
• put together POCs to demonstrate to end users the value and agility of rules
All this can be done in without the need for programming. Think of it as the Microsoft Excel for business rules modeling. Of course once they have gotten this far, then they can make an educated decision as to whether a BRMS purchase and rules automation make sense for them. Should they choose Corticon BRMS, then their rule models are directly deployable as Decision Services. Should they choose another BRMS, at least they have made an informed and educated buy decision. We hope that RulesWorld helps promote the business rules domain overall.
This site is also meant to allow business rules experts to do self-promotion and in the process help educate the community about the value of business rules. Look forward to seeing you there.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
