Rule Processing and Rule flow language

Introduction

This paper provides the foundational description of rule flow processing technologies and along with it architectural pattern and practices involved in applying rule flow processing with in business rule management system. This paper suggest the need of rule flow execution language which is agnostic of the underlying rule engine.

What is a Business Rule?

The word ‘rule’ is a surprisingly general term which is difficult to define in a formal, succinct and precise manner.

Tony Morgan Definition

“A compact statement about an aspect of a business [that] can be expressed in terms that can be directly related to the business, using simple, unambiguous language that’s accessible to all interested parties: business owner, business analyst, technical architect, and so on”.

The formula margin = revenue – direct.costs is not a rule. It is a statement of identity. It could even be regarded as a procedure for computing margin, as can many algebraic equations of this sort.

In the domain of Business Process Management (BPM), rules are very critical and utmost important. These are the rules that constrain and govern commercial organizations and processes they enact.

In general rules are of following types: -

1. Integrity constraints
2. Derivation rules
3. Transformation rules
4. Reaction rules
5. Production rules
6. Deontic rule

Rule processing for BPM

Business flows are orchestrated by BPM where rules act as their brain i.e. decision logic. An emphasis on rule processing can lead to the mistaken impression that rules represent a species of logic separate to other programmatic approaches. However, rules processing is just another form of computation that emphasizes the evaluation of conditions in order to control execution of actions. We could characterize this as

‘rules-orientated’ programming.

The most common category of rules processing patterns in BPM are implemented within individual executable process definitions such as orchestrations. Rule processing can classified as Intra – process (that is, a rule set can potentially orchestrate a process) and Inter – process (that is, rule set can potentially orchestrate different process and itself act as controller)

Inter – process orchestration via rules

The most common category of rules processing in BPM is implemented within individual executable process definitions such as orchestrations.

Rule process aid Inter – process orchestration as: -

1. Rules based derivation that is, drive and infer new facts from existing fact and are used in data and message generation and data & message transformation.
2. Rule based assertion that is, enforce validity and integrity constraint with in a process and are used in data and message validation
3. Rule driver process flow that is, control sequence of process activities and are used in processes decision point, conditional process logic and process with branch and loop

Intra – process orchestration via rules

Inter-process patterns apply rules to the control of interactions and message exchange between multiple orchestrations or workflows.

Rule process aid Intra – process orchestration as: -

1. Rule – driven Process routing that is, helps in process invocation
2. Policy driven Process versioning that is, helps in dynamic composition of discrete services and processes based on version
3. Policy driven Process composition that is, helps in dynamic composition of discrete services and processes

Rule flow language

Rule processing can aid BPM in inter – process or intra process orchestration but different question pops into mind

1. What about flow with in rule a set?
   
2. What about orchestration of different rules with in rule set?
3. How to orchestrate different artifact of capture first order logic like decision table, decision tree, and score card and off course rule set?
4. What about conditionally calling rules etc? That is, how to aspectize execution of rules.
5. How to execute rules or its artifact in parallel?

BPM fails to answer these questions. But the answer to the above question lies in making a new language on the line of BPEL which will be able to cater to above need and answer above questions also.

I have researching on above point and came up with rule flow execution language which is agnostic of the underlying rule engine. Rule flow execution language exploit and use all the feature of the rule engine but using jsr 94 specifications.

There is some development in this direction in JBoss Rules, refer to blog http://markproctor.blogspot.com/search/label/Rule%20Flow

But this fails to address above mentioned questions/concerns.

The rule flow execution language has been created using xsd that is grammar of language is defined in it. Here are few silent feature of the rule flow execution language I conceptualized: -

· Each node or lex is a self executable

· Creating of dependent resources is made on the fly.

· Execution if optimized by using parallel execution concept, which make the rule execution faster.

· Construction of runtime lex component of the rule execution language is based on AST (Abstract Sytax Tree) with some deviations. That is, since, rule execution flow is nothing but execution of rules/ruleset/decisions table based on flow chart; as a result a linear linked list is created which contains the complete execution plan of the flow, with each node as self executable component. Also each node is also aware of its evaluating condition.

· Introspect the flow file and all the drools resources (i.e. rule and decision table) in it and create xml containing all the facts used in it. (which gets passed to the working memory while execution)

· Of course rule flow language is xml based which can traditionally make the application slow. This problem is taken care by ability to produce deployable objects rather parsing the xml again and again for execution. That is, after first execution the rule flow will be expanded as an sequence self executable lex objects