Transcription
INESS RULES Exploring Model-driven BRMS and theDeTI Engine
TABLE OF CONTENTSIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1Business Rules Primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Definition of Business Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1Procedural vs. Declarative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Inferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Categorization of Rule Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .First-generation Business Rules Management Systems (BRMS). . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Design Principles: Built for Decision Support .Shortcomings of First-generation BRMS .3First-generation BRMS Performance Bottleneck: The “RETE Wall” . . . . . . . . . . . . . . . 4Next-generation BRMS: CorticonModel-driven BRMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Benefits of Second-generation BRMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Corticon Excels in Performance and Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Measured Corticon Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6RETE vs. Corticon DeTI: A Detailed Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7RETE Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Comparison of Alternate Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7First-generation BRMS Better Suited to Decision Support, NotDecision Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9A Synopsis of RETE and DeTI .SummaryAppendix A—Details of an Inferencing Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10An Inferencing Use Case: Miss Manners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Appendix B—Comparing RETE and DeTI Using a Sample ScenarioA Business Scenario in RETE . . . . . . . . . . . . . . . . . 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12A Business Scenario in DeTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18About Progress Corticon .www.progress.com. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1INTRODUCTIONThe primary objective of this document is to educate decisionmakers on the evolution and current state-of-the-art inthe business rules industry, as well as the critical successfactors for employing business rules technologies in businessautomation initiatives. The focus of discussion will be acomparison of two fundamentally different approaches torule authoring and rules execution. It is not intended to be acomprehensive review of the Progress Corticon product line. Because the business rules industry has for years beenlargely influenced by the first vendors in the industry, whoembraced the same common technology and algorithms,erroneous perceptions have settled into the collective psyche.Having personally suffered through the shortcomings oflegacy business rules offerings, Progress Corticon foundersdeveloped a breakthrough solution that addresses the realneeds of decision automation and fulfills the order-ofmagnitude improvements in automation project timelines,agility, and business control that have been the promise andpotential of business rules.After a brief primer on business rules, this white paper willdiscuss characteristics of first-generation business rulesmanagement systems (BRMS), with particular emphasison key issues hindering customer success. This will set thestage for a deep dive into the next-generation Corticon BRMS,tracing its unique model-driven approach and raison d’être(reason for being) back to fundamental customer needs thathave been underserved by first-generation products. Finally,this paper will compare the technical differences betweenrule execution between the Corticon engine and other BRMSvendors’ engines, providing insights into performance andscalability.BUSINESS RULES PRIMERDEFINITION OF BUSINESS RULESLet’s start with the basics of business rules. Ron Ross, a guruof business rules, provides the following definition: A business rule is a discrete operational business policy orpractice. A business rule may be considered a user requirement thatis expressed in a non-procedural and non-technical form.For additional clarity, we should further explore two of theterms used above: “non-procedural” and “non-technical.“To express a business rule in a procedural way would be towww.progress.comdefine the control flow or exactly how to process the logic.Non-procedural, therefore, is equivalent to declarative, whichmeans that business rules specify what logic is to be applied,not how to execute a set of operations (the control flow andsequencing). As this topic will be covered in greater detaillater, suffice it to say that expressing rules declaratively isfundamental to the definition of business rules.Also critical to the definition of business rules is that theyshould be expressed in a non-technical format. Businessrules should be business-friendly, understandable to businessstakeholders, without requiring knowledge of programming ortechnical languages.Traditionally, business rules that were automated werecoded directly into applications as “business logic.” Becausebusiness logic is the most volatile aspect of businessapplications, however, the pains of maintaining rules inapplication code have become more obvious and significantas the pace of business demands greater agility. The obviousanswer is to externalize business rule logic and to managethis logic in a way that is easy-to-build, easy-to-change, andeasy-to-integrate (as decision services) while still meetingenterprise performance and scalability demands.PROCEDURAL VS. DECLARATIVEWhy is “non-procedural” such an important capability in ruleauthoring? For the simple reason that rule authoring should bea natural exercise for business domain experts, who understandthe business policies and underlying business logic that is tobe implemented. These business domain experts should beempowered to complete the entire rule authoring process frominception to deployment-ready without relying on others. Ruleauthoring that employs a procedural language or approachmeans that rule authors must master a technical programminglanguage and concepts and the complex interactions of rulesand how they are processed. Such a requirement often forcesrule authoring to be segregated into two phases (requirementscapture and rule implementation), often with differentindividuals owning and participating in each phase and multipleiterations between the two. Rule authoring that involvesprocedural elements in rule definitions demands the traditionalcoding methodology of business-driven requirements thrownover the fence to developers who implement in a technicallanguage. Realizing the goal of “non-procedural” enables avery different way to author and manage business rules and toachieve order-of-magnitude better business results.The distinction between declarative and procedural may bebest articulated with a familiar example: the spreadsheet.
2The spreadsheet is a good example of a declarative metaphor.Users define financial models using declarative operators—such as “ SUM ()”—and may combine them into sophisticatedexpressions. The common usage pattern is that the userdefines what needs to be done. In the example in Figure 1below, cell B8 is defined simply as the sum of cells B2 throughB7.organization to understand the business logic that is drivingtheir automated decisions.INFERENCINGA working definitionInferencing, simply defined, is the action of inferring a new factbased on known facts. Inferencing is often associated withdeductive reasoning, which itself is defined as using deductivearguments to move from given statements (premises) toconclusions, which must be true if the premises are true(source: Wikipedia). A oft-quoted example by Aristotle is asfollows: All men are mortal. (major premise) Socrates is a man. (minor premise) Socrates is mortal. (conclusion)Figure 1A spreadsheet is an example of a declarative metaphor.Contrast this with a procedural approach. The proceduralapproach requires the user to tell the system how to executethe function. In the simple example used above, summing agroup of values, the user would have to explicitly specify thetechnical steps required to loop through each value, addingeach one to the accumulated total (see Figure 2 below). This isa far cry from empowering business domain experts to authorbusiness rules in an intuitive way and for everyone in theInteger iFloat tmptmp 0For i 2 to 7tmp B[i]Next IB[8] tmpFigure 2Procedural equivalent of a simple summation functionwww.progress.comIn the context of BRMS, inferencing is generally equated tothe practice of rule engines determining the sequence ofrule execution based on logical dependencies. Rule enginesthat support automatic sequencing of rule processing arecommonly viewed as “inferencing capable rule engines”and offer a measure of flexibility in rule authoring because,theoretically, users do not need to concern themselves withrule sequencing.An example of rule logical dependency would be the following:1.IF a person is a skydiver, THEN the person is high risk .2.IF a person is high risk , THEN the person is rejected.Rule 2 in this example is logically dependent on Rule 1 andmust execute after Rule 1.Types of iterationInferencing-capable rule engines typically perform two typesof iteration: fact iteration and logical loop iteration (aka “rulerecursion”). Fact iteration is the simple concept of processingeach rule against all relevant facts in working memory. Logicalloop iteration, or rule recursion, happens when there is a cyclein the rule dependency graph. For instance, if Rule 2 dependson Rule 1, and Rule 3 depends on Rule 2, and Rule 1 dependson Rule 3, there is a logical loop. To support logical looping, arule engine must iterate over the logical loop until there are nomore updates in working memory.For a detailed exploration of how iteration is employed to solvean inferencing use case, see Appendix A.
3CATEGORIZATION OF RULE ENGINESBecause the earliest rule engines employed the RETEalgorithm, RETE-based engines have often been synonymouswith inferencing engines. But to generalize the problemor solution space (inferencing) to one implementation orapproach (RETE) would be unwise. In fact, a leading industryanalyst has identified three types of rule engines or ruleprocessing algorithms: inferencing, sequential, and extendedsequential.If we look at algorithms more as a class of use cases, we canmap engine architectures to one or more of the use caseclasses and gain a better understanding of what enginesare best suited to which classes of use cases. As shown inFigure 3, inferencing algorithms arrived first on the sceneand provided a degree of rule authoring flexibility, but werevulnerable to performance bottlenecks. The RETE-based ruleengines fit into this classification. In an attempt to addressperformance issues, most first-generation vendors added acompletely separate engine mode that employed sequentialalgorithms, but this came at a price of authoring flexibility,and/or the types of use cases that could be solved. Forresterhas identified a third category of “algorithms” as somewhat ofa hybrid and has called this category “extended sequential.”From the perspective of the characteristics of this thirdcategory, notably rule authoring flexibility, high performanceand scalability, and capable of solving inferencing problems,the Progress Corticon Deployment-Time Inferencing (DeTI)solution fits into the extended sequential category of engines. Flexible authoring-Performance-Flexible authoring RITHMSEXTENDEDSEQUENTIALDeTIFigure 3Rule engine classifications Flexible authoring PerformanceDEPLOYMENT-TIME INFERENCINGScalable, high-performanceinferencingFIRST-GENERATION BUSINESS RULESMANAGEMENT SYSTEMS (BRMS)First-generation BRMS vendors have played an important rolein developing the business rules market. Thanks to them, thereis a growing recognition of the power and value of externalizingbusiness rules and managing decisions as critical corporateassets with purposeful business rules management systems.However, first-generation BRMS do not fully realize thepotential of business rules.First-generation BRMS vendors can be characterized as suchby their approach to processing rules. These vendors offera RETE-based approach and by and large have introducedprocedural elements to their rule languages. They handleinferencing types of problems by building dependencynetworks in the engine’s working memory at runtime.DESIGN PRINCIPLES: BUILT FOR DECISIONSUPPORTThe core technology embraced by first-generation BRMSvendors, the RETE algorithm, evolved from the expert systemsmarket. This heritage is evident from the lingering designprinciples originally employed to satisfy expert systems usecases. These use cases may be characterized as “decisionsupport,” centering on complex problems, defined by large andrather fluid rule bases, where one or a few experts tease outmultiple possible “answers” that contribute to their decisionmaking process. The underlying technology and relatedfirst-generation BRMS architectures are suited to ongoingtinkering of the rule base and use of a technical language formaximum flexibility. But first-generation BRMS are vulnerableto a number of problems including non-deterministic behavior,a lack of integrity in rule sets, and performance bottlenecksdue to larger data sets. Figure 4 below summarizes the designpriorities and primary focus of the RETE algorithm and, byassociation, first-generation BRMS vendors.PRIMARY SEGMENT SERVEDEXPERT SYSTEMSConsumer of decisionsExpertUse Case CategoryDecision supportDeterministicNot alwaysInconsistencies (integrity)ToleratedMessage size (data payload)Small (query)WorkloadSmallFigure 4Design priorities and characteristics of RETE and first-generation BRMSwww.progress.com
4SHORTCOMINGS OF FIRST-GENERATION BRMSAt the highest level, there are two categories of shortcomingsassociated with first-generation BRMS: ease-of-use andperformance. First-generation BRMS products are difficult touse because they require most or all of the following: Proprietary programming languages Complex engine algorithms Proprietary rule development infrastructures Specialized debugging techniques to increase the chancesof getting rules rightFirst-generation BRMS solutions are also challenged byperformance and scalability bottlenecks. The fundamentalnature of the RETE approach, in-memory dependency networkprocessing, is taxing on servers. So it should be no surprisethat there is an inherent architectural performance andscalability ceiling, which is typically reached when the datato be evaluated against a rule set is large and/or complex.This bottleneck is such a well-known phenomenon, it hasa nickname: the “RETE wall.” Optimizing RETE-type engineperformance is also challenging because it requires extremelydeep expertise in the detailed mechanics of a particularvendor’s engine (and the logic of the rule sets themselves) tomanually tune performance.Multiple rule languages and the impact on ease-of-useIn the earliest days of the business rules industry, the rulelanguages in use included OPS5 and CLIPS. These languageswere declarative, but they were very difficult to use by bothtechnical and non-technical users.To make the rule authoring language more appealing totechnical users, legacy vendors introduced proceduralconstructs, violating the objective of keeping rule definitiondeclarative. In addition, these vendors created their ownspecialized, proprietary syntax and required users to gain adeep knowledge of proprietary engine algorithms.Having strayed off the path of a non-procedural, non-technicalrule authoring solution, legacy vendors added secondarylanguages in an effort to appeal to non-technical users. Thesesecondary languages often employed natural-languagestyle constructs and may have had good intentions, butthey introduce a set of new problems instead of solving thefundamental objective. Secondary languages, or businesslanguages, invariably handle only the simplest business rulelogic and often require a supporting proprietary technicalinfrastructure. In the end, synchronizing rules authored in twowww.progress.comlanguages, by two classes of users, is fraught with problems—and in many ways is a step backward to a traditional codingmethodology (business users author requirements; developersimplement in technical languages).Other ease-of-use issuesBeyond the more obvious challenges of the legacy approachidentified above, there exist other crucial flaws in firstgeneration BRMS offerings. One of the major obstaclesto the widespread adoption of business rules “referentialrule integrity” (RRI). Essentially, RRI is the concept of“guaranteeing” logical integrity of a set of rules. With anyset of rules there is the potential that there are conflicts(an instance of data can satisfy the conditions of multiplerules, yet the prescribed actions for those rules are inconflict), incompleteness (the set of rules does not covercertain instances of data), and circular logic. Conflicts areundesirable because they cause non-deterministic behavior.Incompleteness is undesirable because it can lead to a lack ofan appropriate response. Circular logic is undesirable becauseit can cause infinite loops. First-generation BRMS offeringshave yet to fully solve RRI.Other ease-of-use challenges that continue to plaguemany first-generation BRMS offerings include the difficultyin managing large rule bases, the lack of a full-function,business-friendly testing environment, and a complexdeployment and integration model.FIRST-GENERATION BRMS PERFORMANCEBOTTLEN
rule execution between the Corticon engine and other BRMS vendors’ engines, providing insights into performance and scalability. BUSINESS RULES PRIMER DEFINITION OF BUSINESS RULES Let’s start with the basics of business rules. Ron Ross, a g
