Book Image

Drools JBoss Rules 5.X Developer's Guide

By : Michal Bali
Book Image

Drools JBoss Rules 5.X Developer's Guide

By: Michal Bali

Overview of this book

<p>Writing business rules has always been a challenging task. Business rules tend to change often leading to a maintenance nightmare. This book shows you various ways to code your business rules using Drools, the open source Business Rules Management System.<br /><br />Drools JBoss Rules 5.X Developer's Guide shows various features of the Drools platform by walking the reader through several real-world examples. Each chapter elaborates on different aspects of the Drools platform. The reader will also learn about the inner workings of Drools and its implementation of the Rete algorithm.<br /><br />The book starts with explaining rule basics, then builds on this information by going through various areas like human readable rules, rules for validation, and stateful rules, using examples from the banking domain. A loan approval process example shows the use of the jBPM module. Parts of a banking fraud detection system are implemented with the Drools Fusion module which is the complex event processing part of Drools. Finally, more technical details are shown detailing the inner workings of Drools, the implementation of the ReteOO algorithm, indexing, node sharing, and partitioning.</p>
Table of Contents (22 chapters)
Drools JBoss Rules 5.X Developer's Guide
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Setting Up the Development Environment
Creating Custom Operators
Dependencies of Sample Application
Index

Drools Fusion


Drools Fusion is a Drools module that is a part of the Business Logic Integration Platform. It is the Drools event processing engine covering both CEP and ESP (these terms will be used interchangeably in this book). Each event has a type, a time of occurrence, and possibly a duration. Both point-in-time (zero duration) and interval-based events are supported. An event can also contain other data such as any other fact: properties with name and type. All events are facts, but not all facts are events. An event's state should not be changed; however, it should be noted that is valid to populate unpopulated values. Events have clear life cycle windows and may be transparently garbage collected after the life cycle window expires (for example, we may be interested only in transactions that happened in the last 24 hours). Rules can deal with time relationships between events.