Content deleted Content added
Disambiguated: service-oriented → Service-orientation |
m Adding short description: "Type of software system" |
||
| (36 intermediate revisions by 29 users not shown) | |||
Line 1:
{{Short description|Type of software system}}
A '''business rules engine ''' is a [[software system]] that executes one or more [[business rules]] in a runtime [[Production system (computer science)|production environment]]. The rules might come from legal [[regulation]] ("An employee can be fired for any reason or no reason but not for an illegal reason"), company policy ("All customers that spend more than $100 at one time will receive a 10% discount"), or other sources. A business rule system enables these company policies and other operational decisions to be defined, tested, executed and maintained separately from [[application code]].
Rule engines typically support rules, facts, priority (score), mutual exclusion, preconditions, and other functions.
Rule engine software is commonly provided as a component of a [[business rule management system]] which, among other functions, provides the ability to: register, define, classify, and manage all the rules, verify consistency of rules definitions (”Gold-level customers are eligible for free shipping when order quantity > 10” and “maximum order quantity for Silver-level customers = 15” ), define the relationships between different rules, and relate some of these rules to [[Information Technology|IT]] applications that are affected or need to enforce one or more of the rules.
==IT use case==
In any [[Information Technology|IT]] application, business rules can change more frequently than other parts of the application code. Rules engines or [[inference engine]]s serve as pluggable [[software component]]s which execute business rules that a [[business rules approach]] has externalized or separated from application code. This externalization or separation allows business users to modify the rules without the need for IT [[wikt:intervene|intervention]]. The system as a whole becomes more easily adaptable with such external business rules, but this does not preclude the usual requirements of [[Software quality assurance|QA]] and other testing.
== History==
An article in ''[[Computerworld]]'' traces rules engines to the early 1990s and to products from the likes of [[Pegasystems]], [[Fair Isaac]] Corp
{{cite journal
| title = Do you know where all of your company's business rules are?
| url =
| journal = Computerworld
|date = 23 May 2005| volume = 39
| issue = 21
| publisher = IDG Enterprise
Line 25:
| quote = Rules engines have been around since the early 1990s when companies such as Pegasystems Inc. in Cambridge, Mass., Fair Isaac Corp. in Minneapolis and ILOG in Mountain View, Calif., sold them. They were typically used in rules-heavy industries such as finance and insurance. Over the past few years, however, many vendors have entered the market, and more companies are looking at rules engines as a way to gain greater flexibility in business operations.
}}
</ref> and eMerge<ref>{{Cite web |title=eMerge Rule-based software development platform |url=https://sapiens.com/products/emerge-development-platform/}}</ref> from [[Sapiens International Corporation|Sapiens]].
==Design strategies==
Many organizations' rules efforts combine aspects of what is generally considered [[workflow]] design with traditional rule design. This failure to separate the two approaches can lead to problems with the ability to re-use and control both business rules and workflows. Design approaches that avoid this quandary separate the role of business rules and workflows as follows:<ref>Is Your Rules Engine Event-Driven? Retrieved from http://www.sapiens-tech.com/iDuneDownload.dll?GetFile?AppId=225&FileID=216581&Anchor=&ext=.pdf {{
* Business rules produce knowledge;
* Workflows perform business work.
Line 51 ⟶ 50:
Most rules engines used by businesses are [[forward chaining]], which can be further divided into two classes:
* The first class processes so-called production/[[inference]] rules. These types of rules are used to represent behaviors of the type IF condition THEN action. For example, such a rule could answer the question: "Should this customer be allowed a mortgage?" by executing rules of the form "IF some-condition THEN allow-customer-a-mortgage".
* The other type of rule engine processes so-called reaction/[[Event
The biggest difference between these types is that production rule engines execute when a user or application invokes them, usually in a stateless manner. A reactive rule engine reacts automatically when events occur, usually in a stateful manner. Many (and indeed most) popular commercial rule engines have both production and reaction rule capabilities, although they might emphasize one class over another. For example, most business rules engines are primarily production rules engines, whereas [[complex event processing]] rules engines emphasize reaction rules.
Line 60 ⟶ 59:
A fourth class of rules engine might be called a deterministic engine. These rules engines may forgo both forward chaining and backward chaining, and instead utilize [[domain-specific language]] approaches to better describe policy. This approach is often easier to implement and maintain, and provides performance advantages over forward or backward chaining systems.
There are some circumstance where [[Fuzzy Logic]] based inference may be more appropriate, where heuristics are used in rule processing, rather than Boolean rules. Examples might include customer classification, missing data inference, customer value calculations, etc. The DARL language<ref>{{Cite web |url=https://darl.ai/home/darl |title=The DARL language |access-date=2018-09-01 |archive-date=2018-09-01 |archive-url=https://web.archive.org/web/20180901215801/https://darl.ai/home/darl |url-status=dead }}</ref> and the associated inference engine and editors is an example of this approach.
One common use case for rules engines is standardized access control to applications. [[OASIS_(organization)|OASIS]] defines a rules engine architecture and standard dedicated to access control called [[XACML]] (eXtensible Access Control Markup Language).▼
==Rules engines for access control / authorization==
▲One common use case for rules engines is standardized access control to applications. [[
One key difference between a XACML rule engine and a business rule engine is the fact that a XACML rule engine is stateless and cannot change the state of any data.
The XACML rule engine, called a [[XACML#Terminology|Policy Decision Point]] (PDP), expects a binary Yes/No question e.g. "Can Alice view document D?" and returns a decision e.g. Permit /
== See also ==
Line 70 ⟶ 71:
*[[Inference engine]]
*[[Rete algorithm]]
*[[Ripple
*[[Business
*[[Semantic reasoner]]
*[[Workflow engine]]
*[[
*[[
*
==References==
Line 83:
==Bibliography==
*Taylor, James; Raden, Neil (2007). Smart (Enough) Systems. Prentice Hall. {{ISBN
*David Linthicum (2007-02-14). "Rules Engines and SOA". InfoWorld, 2007-02-14. Retrieved on 2009-09-23 from http://www.infoworld.com/d/architecture/rules-engines-and-soa-158.
==External links==
*[https://web.archive.org/web/20081208082720/http://herzberg.ca.sandia.gov/guidelines.shtml Guidelines for deciding whether to use a rules engine?]
[[Category:Rule engines]]
[[Category:Decision
[[Category:Expert systems]]
| |||