Downloaded 23 times
Uploaded byZoran Hristov
Jboss drools 3 key drools functionalities
This document provides an introduction to Jboss Drools, a business rules management system. It outlines some of the traditional problems with implementing business logic in an imperative style, and how Drools takes a declarative approach using rules. The benefits of rules include being more readable and mappable to requirements, easier to maintain and modify with changing needs, and ability to deal with evolving complexity. Some disadvantages and cases when not to use a rules engine are also presented. Finally, it briefly describes different Drools architecture options.
Jboss drools 3 key drools functionalities
- 1. Jboss Drools JbossDrools Introduction Training By ITgma
- 2. Scope, out-of –scope- benefits, shortfalls Jboss Drools Introduction Training By ITgma
- 3. Traditional approach –problems Spaghetti code Requirements are in Business Logic layer On evolving system imperative style language change often growing in complexity Not well defined way on representing the business logic Changes in Requirements massively affect solution For Developers it is hard to change the business logic. For domain experts, it is impossible to verify the business logic Copyright © ITgma 2012
- 4. Solution? In Imperative style language, we are implementing both, WHAT need to be done and HOW it needs to be done Declarative, such as SQL also(in RDBMS), tend to describe what we want to search. It doesnt know anything about how DB should find data To implement Business Logic we need declarative model, and Drools approach this with rules Copyright © ITgma 2012
- 5. Solution - benefits Rules engine take this rules and execute them over our data, in the most efficient way Rule are in form of what BA are defining, like if- then statements Rules which have all their conditions true, have their then part evaluated first. This is different from imperative style language as developer has to specify how it needs to be done explicitly(with sequence of conditionals and loops) Each rule represent one requirement. This is more readable and maps to business requirements more naturally Copyright © ITgma 2012
- 6. Advantages Easier to understand(for BA or Dev. Or Bus. Dev.). It is more likely technically skilled business analyst to verify or change rules than a Java program Improved maintainability: As rules are easier to understand, a developer can spend more time solving the actual problem. We don’t care about how to implement a solution. We only care about what need to be done to solve the problem Copyright © ITgma 2012
- 7. Advantages - continued Deals with evolving complexity: It is much easier to add new rules, modify or remove existing rules than to change, for example, a Java program Flexibility : It deals with changes to the requirements or changes to the data model in a much better way. Changing or rewriting and application is never an easy task. However, thanks to formalism that rules bring, it is much easier to change rules than to change Java program Copyright © ITgma 2012
- 8. Advantages - continued Reasonable performance: Thanks to Rete algorithm that is behind Drools, in theory, the performance of the system doesn’t depend on the number of rules. Because a rule engine is essentially a generic if-then statement executor, there are numerous performance optimizations that can be applied independently of the rules. With every release of Drools, the performance engine is getting better, by adding various optimizations such as Rete node sharing, node indexing, parallel execution. Copyright © ITgma 2012
- 9. Advantages - continued Requirements can be naturally translated into rules: The representation of business rules is consistent. For example, lets take some business rule and implement it in Java. Developers, depending on their experience, tend to use different ways to solve a problem. We’ll find out that the possible solution will wary greatly. Whereas with rules, this diversification becomes less apparent. It is simply because we are expressing ‘what’ instead of ‘how’. As a result, the code is much easier to read even by new developers. Copyright © ITgma 2012
- 10. Advantages - continued Ability to apply enterprise management to our rules Reusability Rules model the application invariants more closely The Drools platform brings unification of rules and processes Independent Lifecycle Embedded ability Copyright © ITgma 2012
- 11. Disadvantages It is not an easy task to write systems that make complex decisions We don’t specify how the business rules should be implemented. Instead we just specify what need to happened. Therefore, we don’t know how it happened, and it may be difficult to troubleshoot Copyright © ITgma 2012
- 12. When not touse a rule engine If your project is small, less than 20 rules If your business logic is well defined/static and doesn't change often, you don’t need to change rules at run-time If your rules are simple, self-contained, and usually spanning only a single object. If in a pseudo-code you don’t have more than two nested if-then statements Copyright © ITgma 2012
- 13. When not touse a rule engine - continued If performance is your primary concern If your project is a one-shot effort and it will never be used again or maintained over time If you don’t have the time and money to train your developers to use a rule engine Copyright © ITgma 2012
- 14. Alternative Architectures Drools AlternativeArchitectures Embedded As a Service Copyright © ITgma 2012
- 15. Drools Embedded Architecture, centralizedKnowledge Copyright © ITgma 2012
- 16. Drools As AService (Centralized) Architecture Copyright © ITgma 2012
Editor's Notes
- #4 Questions:What is our Platform?Build ON THIS!