This is one of the possible Use Cases.
1. Abstract
Of the deployed rules in use today, a large number are used in vendor-specific production rule engines (and derivative technologies, such as decision table processors).
A common use case for these rule technologies is that an organisation needs to switch rules from 1 rule engine vendor to another. This requires rule interchange in a common format.
2. Status
This use case is proposed by Paul Vincent of Fair Isaac. See also the existing effort at OMG for PRR - Production Rule Representation - which defines a common metamodel for production rule engine use, and a framework for other rule types to be defined in future.
3. Links to Related Use Cases
Portability is fundamentally similar - this use case is from a customer of VendorA who would like to be able to run their rules using VendorB, for example to gain performance advantages, or because their organisation uses multiple rule vendors
RIF RuleML FOAF references JDrew http://www.jdrew.org/jDREWebsite/jDREW.html which is more a reasoning engine than the usual commercial rule engine - indicating a need for some rule engine classification?
Operationally Equivalent Translations references SWI PROLOG http://www.swi-prolog.org/ and the need to interchange to other rule engines - although it is not given whether multiple rule engines have indeed been tried in this project
Automated Trust Establishment for eCommerce implies a need for rule interchange but does not postulate any other rule engines than the custom mechanism constructed for this project - Peertrust http://www.l3s.de/peertrust/
Rule-Based Email Manipulation talks about rule interchange for the MS Outlook rule mechanism. However, it is not clear whether other rule vendors should be considered for MS Outlook users: if not then the only interchange issue is transmission of MS Outlook rules; if so, then clearly there needs to be the ability to invoke an external email policy rule engine, and define interchange aspects about level of service (eg what if I cannot interpret a given email rule because I am limited by Outlook's engine?).
Message Transformation is very common for vendor intechange (although the use case as described is about the subset of SOA services using ontologies and rules for automating ontology conversion). Many BPM vendors for example provide the ability to use rule vendors for process automation OR process decisions. The latter in SOA environments means that some complex rules may be defined for service selection using UDDI data, message content and SLA information... currently such rules can only be portably described as procedures in BPEL, but are in fact a candidate for RIF representation for delegation from BPEL, and execution in some other rule vendor engine in intranet / extranet SOA environments.
Importing rules to check data compliance is really an extension of the previous SOA-based use case, except that here the service is able to publish, as part of its preamble communications with consumers, its rules for data validation. Data validation is a common use for production rules and therefore all PR vendors would apply.
Refund Policies in E-Commerce is another use for production rules (and indeed I have seen one application of this as a B2C service provider using Blaze Advisor). Interchange would be required if such services were generalised and the policies dictated by businesses which were different from those executing the policies. The same comments apply to Supply Chain Ordering Lead Time, Price Discounting.
Credit Card Transaction Authorization is another use for production rules with interchange requirements depending on different businesses wanting to define rules versus execute them.
Interchange of Business Rules between People Who Run Organizations and Internally/Externally Supplied IT Systems may apply to commercial business rule management systems, that realise production rules for example in business terminology for users. There is no current standardisation around this at the vendor level except for the new computation-independent OMG SBVR standard.
Rule-based Service Level Agreements (SLA) and Web Services and its similar use case Rule Based Service Level Management and SLAs for Service Oriented Computing involves production rules that could be executed by a number of vendors (and would therefore deem interchange).
Real-time contract exchange implies use of multiple / portability across multiple production rule vendors, for example.
Decision making in Health Care is also covered by HL7 Arden Syntax, for which a common RIF and portability across multiple vendor rule engines would be considered advantageous.
Automatically generated rules is a use case for a standardised rule representation from analytic tools: there are already tools that generate rules from data warehouses, and being able to export from 1 rule vendor representation to another would be a secondary use case for these (the first being a common rule representation).
- References to OWL/RDF rule engines in the other use cases may also be candidates for vendor interchange (however, mostly these seem to be academic rule projects rather than commercial rule vendors).
4. Benefits of Interchange
Transfering rules between vendor engines is a fundamental transport and interchange use case.
5. Requirements on the RIF
- RIF is defined to and from common rule engine implementations (ie rule formats)
Vendors (for example Fair Isaac, Ilog, IBM, LibRT, PegaSystems and Corticon who are already participating in PRR for standardising at the modeling level) have customers who will also want to support rule interchange into and outof their proprietary (production) rule formats.
- Rule transfers may be 1-time type events and as such are supported by RIF. Examples are: (i) CompanyA using VendorF acquires CompanyB using VendorI and transfers rules from VendorI to VendorF to standardise on vendor environments (or just to share the rules). (ii) CompanyA using VendorJ determines that VendorF provides better runtime performance for certain rule services, and wishes to pass rules to that vendor's environment for execution.
- Rule transfers may be transaction-based events and as such are supported by RIF.
6. Breakdown
6.1. Actors and their Goals
RuleDeveloper - wants to publish rules to 1 or more RuleConsumers. Rules represent business rules / decisions used in some business process. Rules are defined in FormatA as production rules.
RuleConsumer - wants to consume rules for further development and/or execution. Rules are maintained in FormatB as production rules.
6.2. Main Sequence
RuleDeveloper exports rules into a RIF package or stream.
RuleConsumer imports rules from a RIF package or stream. Semantic meaning is maintained.
7. Narratives
7.1. Transfer of rules from 1 vendor product to another
Generally, the semantics of rule engines are similar (see PRR).
- Vendors have many proprietary extensions to basic PR features (eg event rules, exclusive tables, rule priorities, ...). RIF may support some extensions and may delegate others to simple textual notation (eg for manual update).
- Rules eg PR production rules are defined against a data / object model. This is typically an in-memory model like Java objects, but for W3C work could be represented as either XML, RDF, or an XML metamodel of the data model. The data / object model may be called the Business Object Model for PRs representing business rules. This needs to be either identified or communicated with the rules in RIF.
- Example rule engine vendors' (languages) include Fair Isaac Blaze Advisor (SRL Structured Rule Language); ILOG JRules (IRL Ilog Rule Language); and rule formats for JESS, DROOLS, etc
8. Commentary
The most common rule vendors are for production rules (as defined in PRR). A RIF / RIF subset following the PRR metamodel would allow rapid support and use for RIF as well as providing an established vendor community for RIF-based software projects.