Business Rule Computation in Distributed Organizations
George Dimitoglou
Research AdvisorProf. Shmuel Rotenstreich
2
Outline
• Introduction• Related Work• Problem Description• Solution & Results• Conclusions • Future Work
3
Environment
• Complex, dynamic, distributed organizations• Activities
– Acquisition of services, resources– Collaboration, team formation
• Rules & Constraints– Business Rules are statements of “How to do business”– Faster, systematic decisions
4
Objectives
• To investigate Business Rule– Management– Distribution– Execution
• Develop a general computational model for constraint computation
5
Outline
• Introduction• Background and Related Work• Problem Description• Solution & Results• Conclusions• Future Work
6
Related Work: Organization Theory
• Organizational Design– Formalization (standardization): Number of rules, documentation
and policy manuals– Theories
• Bureaucracy: order, uniformity, consistency, well-defined hierarchy, record-keeping, rules.
• Systems Theory: inputs, outputs, transformations and prescribed interactions
• Organization Structure– Complexity
• Horizontal (specialization), Vertical (hierarchy), Spatial (geographic)– Centralization/decentralization
• decision-making locations (not spatial) within the organization– Theories
• Closed vs Open Systems:Simple, static, introverted environments Complex, dynamic, environment-interacting
10
Outline
• Introduction• Background and Related Work• Problem Description• Methodology and Solution• Results• Conclusion• Future Work
11
Problem Description
• Managing Constraints in distributed environments• Existing approaches
– Small, static, contained, monolithic systems• Shortcomings
– Centralization– Lack of operation capability in dynamic environments
• Application-only interaction
– Lack of distributed operation– Lack of Dynamic Rule support
• No real-time rule changes
12
Outline
• Introduction• Background and Related Work• Problem Description• Solution & Results• Conclusion• Future Work
13
Methodology
• Business Rules– Formulation – Developed/Extended a simple rule type classification
• Software prototype– Devised methods for Rule processing – Developed architecture for multiple rule engines and
repositories– Developed distributed and non-distributed processing
algorithms– Added features to enhance distributed processing
14
Business Rule Formulation
• Declarative statements that constraint, validate, compute, approve or perform any operation.
• Example rule (Stimulus/Response):
R: if P1 P2 … Pn then A1 A2 … Ak
wheren ≥ 1 is a conjunction of n predicates (conditions) k ≥ 1 is the set of conjunctions of k results (actions)
Predicates (Pn) and results (Ak) express values of operands using relational operators from the set S ={>, <, ≠, =, ≤, ≥}
16
Business Rule Elements
<ruleid>value</ruleid>(Unique rule identifier)
<task_type>value</task_type> (Matching applicable rules to tasks)
LHS
RHS
<creation-date><effect-date><expiry-date><lifetime><owner><status>(“Administrative” elements)
17
Business Rule TypesStimulus/Response
• Define what conditions must be met before an activity can legally take place:
RSR: if P1 P2 ... Pn then A1 A2 ... Ak or,
RSR': when P1 P2 ... Pn then A1 A2 ... Ak
Example: Task: check account balance, print a statement. Rule:
RSR: if (client has an account) then (check account balance) (print
statement) Task: add quarterly interest dividends to account.
RSR’: when (end of quarter) then (calculate interest)
(add interest to balance)
18
Business Rule TypesOperation Constraint Rules
• Define constraints that must hold before and/or after an activity.
ROC: if P1 P2 ... Pn then [Q] A1 A2 ... Ak [S]
where
Q: pre-condition stating properties that must hold when activity is to be performed
S: post-condition stating properties that will hold after the activity is completed.
• Example:
– Task: withdrawing funds from a bank account
ROC: if (client has an account) then [check account has funds]
(withdraw amount) (print statement) [balance 0]
19
Business Rule TypesStructure Constraint Rules
Specify constraints on tasks, which must never be violated. Software Engineering class and loop invariants – Class invariant: assertion describing a property, holding for all class
instances.– Loop invariant: assertion to be satisfied prior to the first loop execution,
preserved at each iteration, and still hold on loop termination.
• Rule R has an invariance property for task Ti:– if R is valid in every computation state ("must always hold")
during processing of Ti.
RSC: it must always hold that P1 P2 ... Pn
or,RSC: it must always hold that
if P1 P2 ... Pn then A1 A2 ... Ak
Example:RSC: it must always hold that (minimum balance=$100)
RSC: it must always hold that if ( account = savings) then (minimum balance=$500)
20
Business Rule TypesComputation
• Describe algorithm processing or equations. • Extension (or general case) of Stimulus/Response Rules. • Predicates are TRUE and activity is an algorithm execution or a computation.
RCR: y=f(x)• Example:
COMPUTE interest AS interest = principal * years * rate/100
Instantiate class Computation that parses parameters of the rule XML and call the relevant methods for execution.
21
Business Rule Lifecycle
• Rule execution can be formally expressed as a DFA R by the tuple:
R= (Q, , q0, F, )where Q: finite set of states: finite set of input events e. ={activate, trigger, execute, deactivate} F: set of final states. F={new, active, dormant}: transition function from Q x to Q so that (q, e) is a state for each state q and
input event e.
23
The Business Rule Engine (BRE)
• Components• FIFO Queue• Engine• Repository (RuleBase)• Interfaces
• Functionality• Rule storage• Search• Enforcement
24
Task Processing Search-Match-Process-Enforce
Search
MatchCollect
Enforce(modify task)
1) Create “candidate set”2) Resolve any conflicts3) Create execution sequence
25
Rule Processing Algorithm
ProcessTask– ParseTask
• Parameters
– RetrieveRules• Search Repository• Store in candidate set
– CategorizeRules• Type-specific
processing
– ResolveConflicts• Check for conflicts• Resolve• Create execution
sequence
– ApplyRules• Modify task
26
Rule Processing Algorithm Time-Complexity Analysis
• Methods• Time-Complexity Analysis
– Hash-based repository operations (search, retrieval) perform in constant time O(1).
– PARSETASK, RETRIEVERULES, CATEGORIZERULES, APPLYRULES perform in linear time O(n).
– Overall complexity depends on RESOLVECONFLICTS
• Quick sort with O(nlogn) – Empirical data
• Overall– O(nlogn)
27
Conflict Resolution
• Conflict categories – Sequence Conflicts. Affect rule execution sequence.
• Two applicable rules, one accepting the task and the other rejecting it. – Parameter Conflicts.
• Two or more rules modify same task parameter, but compute its value using different formulas and produce different results.
a) Rule A: modifies parameter - Rule B: with different values b)Rule A: Removes parameter - Rule B: adds itc) Rule A: Modifies parameter - Rule B: eliminates itd)Rule A & B: Compute same parameter using different
formulas.
• Resolution– Dynamic (each time) while in the candidate set– Execution sequence– Resolution factors
• Rule Type• Priority• Timestamp
28
Distributed Rule Processing
Overall Environment• Multiple units of one or more
organizations• Some units collaborate others don’t• BREs “scattered” throughout• BRE Locality
BRE infrastructure• “Underlying” network of peer BREs• BREs: Uniquely identifiable and
addressable• Shared and interconnected rule-sets
Example:IF operand=value THEN
<Rule Engine>.<Rule number>
29
Distributed Rule Processing Cont’d.
• Ad hoc team formation (TTL=2)– BRE0: Team Leader– Hash-table sharing. All rule results to
team leader BRE0
• Membership– New members– Existing members removed– Leader failure dealt via LEA
Team Leader
Team Formation
• Memory (Caching)• Optimistic Fault Tolerance
30
Distributed Rule Processing Algorithm
• Additional Functionality– Interaction with Resource Discovery mechanisms– Query Propagation– TTL for control– Ad hoc team maintains storage of shared rule sets
31
Distributed Rule ProcessingTime-Complexity Analysis
• Multiple P2P-connected BREs• Add network and communication costs• Performance of processing a single task:
where k is the number of rule enginesm represents a communication costs constant
Overall: O(nlogn*m)
32
“Nested” Rules
• Single BREIF operand=value THEN <Rule number>*
• Problem: Termination • Solution:
– forbid loops during formulation (smart interface)– Max occurrence limits in candidate set
• Multiple BREs IF operand=value THEN <Rule Engine>.<Rule number>
• Problem: Termination, Cascading rules - no global control• Solution: Max cycle occurrence in candidate set
Max depth-limit enforcement
* All rule types are subject to “nesting”
33
Procedures
• Ordered rule sequences• Executed/enforced on task(s) as a single rule• Precedence of execution over individual rules
• Advantages– Additional, useful construct, controlling the order of rule execution– For repetitive tasks, performance improvement (no conflict resolution)
• Disadvantages– Black box– User must ensure no conflicts
34
ProceduresImplementation
(a) Sample procedure expression using XML and (b) the corresponding XML tree
35
Global Variables
• Distributed System View• Variables with “scope” over organizational segments• Lack of global control facilities• No monitoring or controlling of activities• Local & “Global” inter-dependent constraints
• Rule processing is unaware of such variables• GVAR types:
– Counters (establish limits, tasks accepted/rejected)– Advisories (express an advise or suggestion, BRE may enforce/ignore
36
Global VariablesImplementation
• Distributed GVAR Network– Master (read/write)– Proxies (read)
• “replicate everywhere” algorithm
• Proxies– faster GVAR lookups– no bottlenecks
• Master– consistency
GLOBAL VAR IABLE VALUE APPLICABLE TASKS TYPE SCOPE
simultaneous_travel 5 faculty_travel-request counter departmentwireless_connections 100 wireless_net_access counter subnetmin_rescue_crew 3 rescue_operation (all) advisory universal
38
Task Temporal Relations
• BRE “Memory”– Organizational Memory– Learning
• Task Temporal Sequences– T1 happens before T2 (T1 T2)
– T1 overlaps T2 – Time delay
• Task Causal Sequences– T1 causes a task T2 (T1 T2)
– anti-symmetric– irreflexive
39
Task Temporal RelationsImplementation
TEMPORAL SEQUENCES DEFINITION
Def_ID Scope Task1 Relation LengthUnit
ofTime
Task2
243 CSDept,EEDept.
advising before registration
335 LawSchl.
pay_loans startduring/completeafter
graduation
567 Global doctoralproposal
delay 6 months doctoraldefense
: : : : : : :: : : : : : :
809 Global probation causes send letter
REAL-TIME SEQUENCES
Seq_ID Owner Task1 Timestamp1 Status1 Task2 Timestamp2 Status2
243 stdnt,181 meetAdvsr 1/3/01 12;15 Y RegForClass 2/3/01 9:30 Y243 stdnt.344 meetAdvsr 6/3/01 11:45 Y809 stdnt.676
: : : : : :: : : : : :
567 stdnt.852 onProbation
• Distributed TSEQ Network– Proxies contain both:
• Read-only
– Master contains both:• Read/Write
40
Performance Analysis
• Measurements– Capacity– Response Time (latency)– Throughput
• Methodology– Creation of multiple synthetic rule sets– For Capacity Testing: Multiple, variable size rule loads– For Latency and Throughput, multiple variable size rule
loads with variable percentages of applicable rules: 1%, 10%, 25%, 75% and 100%
41
Performance AnalysisCapacity Testing
• Repository type• Synthetic data set (1 x
rule=1342b)• 55K (Java tuning required)• > 105K, SAX limitation
• Memory-bound, CPU: idle
ID Number of Rules BRE Memory Foootprint (K) Memory Usage (K) Available File Cache
1 1 17,084 117,820 425,196 26,2922 100 17,992 118,092 426,888 24,1883 1,000 18,896 120,124 432,500 22,3484 2,000 19,876 119,576 433,480 21,1005 5,000 22,684 122,404 432,816 19,9206 10,000 28,104 135,408 425,732 19,8487 15,000 33,584 135,860 422,324 19,5048 20,000 39,116 150,676 415,144 19,6689 25,000 44,432 149,736 411,268 19,584
10 30,000 48,812 149,144 406,264 19,60411 35,000 55,568 172,224 404,600 17,48812 40,000 60,240 172,748 398,696 17,86813 45,000 66,140 174,784 394,152 17,63214 50,000 71,076 173,616 388,280 17,52415 55,000 75,052 180,760 385,588 17,66416 60,000 80,796 180,696 378,948 17,54017 65,000 86,688 206,996 354,352 23,67618 100,000 125,264 255,248 327,812 22,04819 105,000 163,840 303,500 301,272 20,42020 150,000 179,816 344,808 280,540 18,06421 200,000 232,084 351,844 224,688 20,95222 250,000 292,332 501,508 172,380 14,40823 300,000 337,144 502,924 123,364 18,54824 350,000 389,432 499,180 70,604 18,15625 400,000 425,196 531,164 37,284 19,51626 450,000 464,156 582,704 5,488 14,50827 460,000 457,116 581,348 5,116 11,876
Physical Memory (K)
42
Performance AnalysisResponse Time (Latency) Testing
• Objective: BRE time to process single task with variable loads. • Methodology: Load synthetic rule sets with variable applicable rule
loads and send task.
• Results: strong relation between latency - % of applicable rules
10-fold increaseFrom 200 to 2000 rules
Just doubles the latency
10-fold increaseFrom 200 to 2000 rules
Increase by a factor of ~11
43
Performance AnalysisResponse Time (Latency) Results
• Task latency has little variation with same number of applicable rules, even with variable total loads.
00:01.172
00:01.578
00:01.375
00:08.750
00:08.156
00:08.905
00:00.000 00:01.728 00:03.456 00:05.184 00:06.912 00:08.640 00:10.368
Same number of Applicable Rules over Single Task Latency (mm:ss.SSS)
10K/100K
10K/40K
10K/20K
100/100
100/1K
100/10K
44
Performance AnalysisThroughput
• Objective: Determine max number of tasks that can be processed during a given period of time (sec, min, hr).
• Methodology: Same synthetic rule sets as with latency experiments.
• Results: throughput affected by % of applicable rules AND total rules
45
Performance AnalysisQueuing Theory
• Objective: BRE response times as a function of utilization (“stress test”)
• Methodology: used Throughput results (service rate).
• Results:
46
Performance AnalysisQueuing Theory Results
• Result: a consistent way of identifying optimal BRE utilization at any rule load
BRE Utilization
1.0
Utilization Stability Condition
at p < 1
Max Throughput
Saturation
“unstable”
47
Outline
• Introduction• Related Work• Problem Description• Solution & Results• Conclusions• Future Work
48
Conclusions & Research Contributions
• Original approach computation of distributed constraints.
• Software prototype proof-of-concept novel ideas (in the context of BR): – “minimalist” expression of constraints in XML
• flexible rule formulation, minimal semantic specification– Lightweight standalone/distributed rule engines – Fast rule-searching algorithm– Rule Management, Task Processing, Conflict Resolution– Conflict resolution algorithm– Building “local caches” for fault tolerance– Managing global variables and ensuring consistency of temporal sequences
• Development of general computational model to solve problems in domains with similar computation and distribution requirements.
• Tool-set to understand dynamic environments.
49
Future Work
• Variable rule enforcement
• Task generation
• Business rules and context: distributed BREs as context awareness processors
• Business rules and policy
• Automatic "bottom-up" and "top-down", business rule generation– Bottom-up: local computations contribute in creating rules with
global scope– Top-down: automatic distribution of global rules and variables to
local rule engines
Business Rule Computation in Distributed Organizations
George Dimitoglou
Research Advisor Prof. Shmuel Rotenstreich
51
Performance AnalysisCompared to What?
Repository Capacity (number of rules)
0
20000
40000
60000
80000
100000
120000
BlazeAdvisor Repository
GW BRE (single)
EnvironmentBlazeAdvisorSystem: UnknownSoftware footprint: > 500KGW BRESystem: DELL 1.1Ghz, 512Mb RAMSoftware footprint: > 400K
BlazeAdvisor
GW BRE
52
Rule Processing as a Computational Model
• Objects– Contain data, access methods, resources (i.e. BRE)– Multiple interfaces
• Operations– Service primitives with method handles
• Activities– Collections of operations treated as a unit of work for
the objects• Environment
– Distributed, P2P (and client-server)• Constraints
53
Applying the Computational Model
Model Military Nature/Ecology BiologyObjectsContain data,access methods,resources andhave multipleinterfaces
Personnel (soldiers, units),assets or resources (ships,planes, radars) they allinterface differently.
Bees (guard,colony bees),assets (wings,stingers) andinterfacedifferently (sting,fetch nectar,mate).
Ants (queen,femaleworkers,males)
Cells (store andretrieve signals)transmitted viaassets (nerve cells)
OperationsServiceprimitives withmethod handles
Personnel acquiring andusing resources.Assets providing feedbackand reporting.
Flying to flowers.Returning andreporting to hive.
Carry food,mate.
Chemical reactions.
Activities (alsoprocedures)Collections ofoperationstreated as a unitof work for theobjects
Personnel preparing a planefor mission.Assets participating in anexercise.
Build hives, collectnectar.
Buildchambers,store food.
Sequence ofoperations (chainreactions)
EnvironmentDistributed, P2P,c/s
Distributed (geographically),P2P (multi-national forces),c/s within own hierarchies.
Distributed (wherethe nectar is),centralized hive.
Distributed(multiple antcolonies) orcentralized.
Distributed or,centralized
Constraints Military code, context-specific rules, guidelinesaccording to operationalplans.
Rules of flight,rules of nectarload, rules ofhierarchy andreproduction.
Rules foravoidingobstacles,chamberusage.
Chemical andbiological rules.
Complex Systems
54
Distributed “nested rule” example
Starting from BRE001:BRE001: 001.123: IF x=4 THEN 003.977BRE003: 003.997: IF y=7 THEN 019.789BRE019: 019.789: IF k=2 THEN 678.778BRE678: 678.778: IF v=1 THEN 001.123
a) Depth=3 does not mean stopping at BRE019.
b) Depth=3 means above sequence 3X in the candidate set
Top Related