العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
EspañolBUSINESS RULES ENGINE
A 'business rules engine ' is a software system that helps manage and automate business rules. The rules a business follows may 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. The Rule Engine software, among other functions, may help to register, classify and manage all these rules; verify consistency of formal rules ("Flooring material must be flattish to ease cleaning" is inconsistent with "flooring material must be rough to avoid slipping"); infer some rules based on other rules; and relate some of these rules to Information Technology applications that are affected or need to enforce one or more of the rules. Rules can also be used to detect interesting business situations automatically. For example, "notify sales when inventory is lower than 10 and we have more than 5 pending orders on a Monday."
For any IT application, the business rules change more frequently than the rest of the application code. Rules Engines or Inference Engines are the pluggable software components that separate the business rules from the application code. This allows the business users to modify the rules frequently without the need of IT intervention and hence allowing the applications to be more adaptable with the dynamic rules.
In previous generation applications, data was meant to be dynamic which was supposed to be operated upon by the logic and rules to get the desired results. Data Dynamics are no longer the only need of the hour but the focus has been shifted to the dynamic rules.
Most 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 an organization's ability to reuse and control both business rules and workflows. Design approaches that avoid this quandary separate the role of business rules and workflow as follows: business rules produce knowledge; workflow performs business work. Concretely that means that a business rule may do things like detect that a business situation has occurred and raise a business event (typically carried via a messaging infrastructure) or create higher level business knowledge (e.g. evaluating the series of organizational, product and regulatory-based rules concerning whether or not a loan meets underwriting criteria). On the other hand, a workflow would respond to an event that indicated something such as the overloading of a routing point by initiating a series of activities.
This separation is important because the same business judgment (mortgage meets underwriting criteria) or business event (router is overloaded) can be reacted to by many different workflows. Embedding the work done in response to rule driven knowledge creation into the rule itself greatly reduces the ability of business rules to be reused across an organization because it makes them workflow specific.
To deliver this type of architecture it is essential to establish the integration between a BPM (Business Process Management) and BRM (Business Rules Management) platform that is based upon processes responding to events and/or examining business judgement that are defined by business rules. JSR-94 establishes a technical call level interface that does not provide this level of abstraction. There are some products in the marketplace that provide this integration natively. In other situations this type of abstraction and integration will have to be developed within a particular project or organization.
Most rule engines supply the ability to develop a data abstraction that represents the business entities and relationships that rules should be written against. This business entity model can typically be populated from a variety of sources including XML, POJOs, flat files, etc. There is no standard language for writing the rules themselves. Many engines use a java-like syntax while some allow the definition of custom business friendly languages.
Most rules engines function as a callable library. However, it is becoming more popular for them to run as a generic process akin to the way that RDBMSs behave. Most engines treat rules as a configuration to be loaded into their process instance although some are actually code generators for the whole rule execution instance and others allow the user to choose.
There are two different classes of rule engines, both of which are usually forward chaining. The first 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 Condition Action rules. The reactive rule engines detect and react to incoming events and process event patterns. For example a reactive rule engine could be used to alert a manager when certain items are out of stock.
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 may emphasize one class over another. For example, most business rule(s) engines are primarily production rule engines, whereas Complex Event Processing rule engines emphasize reaction rules.
Here is a list of a few non-commercial open source Rules Engines:
★ Workflow Magic is an open source, robust, simple and fast, Business Rules Engine. It has a full MVC architecture, an ORM for mapping any relational model and more.
★ OpenLexicon is a complete open source Business Rule Management System. OpenLexicon provides a rules repository with a simple web-based wizard. In addition to simple Java API's, OpenLexicon provides a comprehensive web services interface that integrates rule sets with no code. OpenLexicon is highly scalable and in use in numerous production systems today.
★ OpenRules is a full-scale open source Business Rule Management System. It is based on commonly used tools such as MS Excel, Google Spreadsheets, and Eclipse IDE. OpenRules also supports rules-based interaction processes with a quick and intuitive GUI generation and integrates Business Rules with Machine Learning and Optimization tools.
★ NxBRE is a lightweight Open Source Business Rule Engine (aka Rule Based Engine) for the .NET platform, composed of a forward-chaining inference engine and an XML-driven flow control engine. It supports RuleML 0.9 Naf Datalog and Visio 2003 modeling.
★ Rools is a pure ruby inference engine available on RubyForge. It supports decision tables, XML rules and, of course, Ruby Rules. It integrates seamlessly with Rails, XForms and OpenWFEru for a complete Ruby Solution to BPMS.
★ JBoss Rules (formerly Drools) is an Open Source Java engine.
★ Production system
★
★ Open Source Rule Engines in Java
★ Open Source Rule Engines in C#
★ Business Rules Knowledge Base
★ JSR-94 Java Rule Engine API
★ RealRules Blogzine
★ Business Rules Blog
| Contents |
| IT use |
| Design strategies |
| Types of rule engines |
| Business Rules Open Source Engines |
| See also |
| External links |
IT use
For any IT application, the business rules change more frequently than the rest of the application code. Rules Engines or Inference Engines are the pluggable software components that separate the business rules from the application code. This allows the business users to modify the rules frequently without the need of IT intervention and hence allowing the applications to be more adaptable with the dynamic rules.
In previous generation applications, data was meant to be dynamic which was supposed to be operated upon by the logic and rules to get the desired results. Data Dynamics are no longer the only need of the hour but the focus has been shifted to the dynamic rules.
Design strategies
Most 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 an organization's ability to reuse and control both business rules and workflows. Design approaches that avoid this quandary separate the role of business rules and workflow as follows: business rules produce knowledge; workflow performs business work. Concretely that means that a business rule may do things like detect that a business situation has occurred and raise a business event (typically carried via a messaging infrastructure) or create higher level business knowledge (e.g. evaluating the series of organizational, product and regulatory-based rules concerning whether or not a loan meets underwriting criteria). On the other hand, a workflow would respond to an event that indicated something such as the overloading of a routing point by initiating a series of activities.
This separation is important because the same business judgment (mortgage meets underwriting criteria) or business event (router is overloaded) can be reacted to by many different workflows. Embedding the work done in response to rule driven knowledge creation into the rule itself greatly reduces the ability of business rules to be reused across an organization because it makes them workflow specific.
To deliver this type of architecture it is essential to establish the integration between a BPM (Business Process Management) and BRM (Business Rules Management) platform that is based upon processes responding to events and/or examining business judgement that are defined by business rules. JSR-94 establishes a technical call level interface that does not provide this level of abstraction. There are some products in the marketplace that provide this integration natively. In other situations this type of abstraction and integration will have to be developed within a particular project or organization.
Most rule engines supply the ability to develop a data abstraction that represents the business entities and relationships that rules should be written against. This business entity model can typically be populated from a variety of sources including XML, POJOs, flat files, etc. There is no standard language for writing the rules themselves. Many engines use a java-like syntax while some allow the definition of custom business friendly languages.
Most rules engines function as a callable library. However, it is becoming more popular for them to run as a generic process akin to the way that RDBMSs behave. Most engines treat rules as a configuration to be loaded into their process instance although some are actually code generators for the whole rule execution instance and others allow the user to choose.
Types of rule engines
There are two different classes of rule engines, both of which are usually forward chaining. The first 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 Condition Action rules. The reactive rule engines detect and react to incoming events and process event patterns. For example a reactive rule engine could be used to alert a manager when certain items are out of stock.
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 may emphasize one class over another. For example, most business rule(s) engines are primarily production rule engines, whereas Complex Event Processing rule engines emphasize reaction rules.
Business Rules Open Source Engines
Here is a list of a few non-commercial open source Rules Engines:
★ Workflow Magic is an open source, robust, simple and fast, Business Rules Engine. It has a full MVC architecture, an ORM for mapping any relational model and more.
★ OpenLexicon is a complete open source Business Rule Management System. OpenLexicon provides a rules repository with a simple web-based wizard. In addition to simple Java API's, OpenLexicon provides a comprehensive web services interface that integrates rule sets with no code. OpenLexicon is highly scalable and in use in numerous production systems today.
★ OpenRules is a full-scale open source Business Rule Management System. It is based on commonly used tools such as MS Excel, Google Spreadsheets, and Eclipse IDE. OpenRules also supports rules-based interaction processes with a quick and intuitive GUI generation and integrates Business Rules with Machine Learning and Optimization tools.
★ NxBRE is a lightweight Open Source Business Rule Engine (aka Rule Based Engine) for the .NET platform, composed of a forward-chaining inference engine and an XML-driven flow control engine. It supports RuleML 0.9 Naf Datalog and Visio 2003 modeling.
★ Rools is a pure ruby inference engine available on RubyForge. It supports decision tables, XML rules and, of course, Ruby Rules. It integrates seamlessly with Rails, XForms and OpenWFEru for a complete Ruby Solution to BPMS.
★ JBoss Rules (formerly Drools) is an Open Source Java engine.
See also
★ Production system
★
External links
★ Open Source Rule Engines in Java
★ Open Source Rule Engines in C#
★ Business Rules Knowledge Base
★ JSR-94 Java Rule Engine API
★ RealRules Blogzine
★ Business Rules Blog
This article provided by Wikipedia. To edit the contents of this article, click here for original source.
psst.. try this: add to faves
