Sign In Start Free Trial

Mastering JBoss Drools 6

By : Mariano De Maio, Salatino, Aliverti

3 (1)

Mastering JBoss Drools 6

3 (1)

By: Mariano De Maio, Salatino, Aliverti

Overview of this book

Mastering JBoss Drools 6 will provide you with the knowledge to develop applications involving complex scenarios. You will learn how to use KIE modules to create and execute Business Rules, and how the PHREAK algorithm internally works to drive the Rule Engine decisions. This book will also cover the relationship between Drools and jBPM, which allows you to enrich your applications by using Business Processes. You will be briefly introduced to the concept of complex event processing (Drools CEP) where you will learn how to aggregate and correlate your data based on temporal conditions. You will also learn how to define rules using domain-specific languages, such as spreadsheets, database entries, PMML, and more. Towards the end, this book will take you through the integration of Drools with the Spring and Camel frameworks for more complex applications.

Preface

Preface

What this book covers

What you need for this book

Who this book is for

Conventions

Reader feedback

Customer support

Free Chapter

1. Rules Declarative Nature

1. Rules Declarative Nature

What are rules?

Why do we use rules?

When should we use rules?

When not to use a rule engine

Summary

2. Writing and Executing Rules

2. Writing and Executing Rules

Setting up our environment

Creating our first Drools project

Writing and executing our first rule

The Rule language

Organizing our projects

Summary

3. Drools Runtime

3. Drools Runtime

Understanding the Drools runtime instances

KieModule configurations (KieBases, KieSessions & StatelessKieSessions)

KieScanner

Summary

4. Improving Our Rule Syntax

4. Improving Our Rule Syntax

Adding external interactions with global variables

Modifying the data in the working memory

Rule attributes

Controlling loops in rules

Special Drools operations

Working memory breakdown: the from clause

Drools syntactic sugar

Decorating our objects in memory

Logical insertion of elements

Rule inheritance

Summary

5. Understanding KIE Sessions

5. Understanding KIE Sessions

Stateless and stateful Kie Sessions

Kie runtime components

Kie Base components

Summary

6. Complex Event Processing

6. Complex Event Processing

What is complex event processing?

Declaring CEP-based Rules

Event-driven architecture

Running CEP-based Scenarios

Drools CEP limitations

Summary

7. Human-Readable Rules

7. Human-Readable Rules

Domain Specific Languages

Decision tables

Rule templates

PMML

Summary

8. Rules' Testing and Troubleshooting

8. Rules' Testing and Troubleshooting

Create loosely coupled DRLs

Prefer KieHelper over a KieContainer classpath

Benefits of using globals

Debugging the left-hand side of a rule

Debugging the right-hand side of a rule

Reporting a bug in Drools

Summary

9. Introduction to PHREAK

9. Introduction to PHREAK

Introducing PHREAK

Special nodes in the network

Queries and backward-chaining

PHREAK improvements over RETE

Phreak Inspector

Summary

10. Integrating Rules and Processes

10. Integrating Rules and Processes

jBPM – the process engine

Simple business process example

Drools and jBPM: integration patterns

Persistence and transactions

Summary

11. Integrating Drools with our Apps

11. Integrating Drools with our Apps

Architecture considerations

Integrating with the rest of an application

CDI integration

Spring integration

Camel integration

Kie Execution Server

Kie Workbench

Drools and beyond: extending our functionality

Summary

Index

Index

Customer Reviews

3 (1)

5 star

0

4 star

0

3 star

100%

2 star

0

1 star

0

When not to use a rule engine

Every project, in one way or another, can benefit from using business rules. They are highly performing, easy to change, and self-explanatory software components. However, there are a group of conditions that a project might have that would make use of business rules a bit of overkill. Some of the characteristics that make a project benefit the least from business rules are shown in the following:

There are very few, self-contained rules involved in the project: If the business rules identified in the requirement gathering are very simple and span about one or two objects at most, we don't need a rule engine to run them. A good rule of thumb is that if we can write the business rules that we need as the pseudo code in less than a page and with less than two nested if-then clauses, we might not need a rule engine at this particular time.
The business logic doesn't change often: If changing rules at runtime is not going to be needed but the logic is still complex, a rule engine might still be a good idea. However, if the complexity behind the rules is not that high and we can assume it will remain that way for a long time, we might not need a rule engine.
A very strict control of the execution flow is crucial for the application: As we stated before, a sequence-flow control is not provided when we execute our business rules. If the business logic behind the business rules depends a lot on a strict set of steps that need to be executed sequentially, business rules might not be the right fit. However, if it does change frequently, perhaps a business process would be worth considering.

It is still a responsibility of the project team to determine whether business rules might be a good fit even if these conditions are met. After all, our experience can lead us to think that the amount of rules has a big chance of growing in the future or there might be situations where the rules will eventually need to change more frequently. Each project has its own unique characteristics and it might be that a project with no need for business rules right now cannot be thought without them in the future.

Search

Your notes and bookmarks