This is an archive of an inactive wiki and cannot be modified.

This is one of the possible Use Cases.

1. Abstract

This use case illustrates a real business application of (production) rules working with XML data.

2. Status

3. Links to Related Use Cases

4. Relationship to OWL/RDF Compatibility


5. Examples of Rule Platforms Supporting this Use Case

All the major business rule vendors have facilities to work together with business process modeling and execution software, such as Oracle BPEL.

6. Benefits of Interchange

7. Requirements on the RIF

8. Breakdown

8.1. Actors and their Goals

8.2. Main Sequence

  1. applicant submits credit application to approval service implemented with BPEL orchestration
  2. BPEL forwards application to decision service for validation of identity data
  3. BPEL requests credit history of applicant from web service
  4. BPEL forwards credit history to decision service for evaluation
  5. decision service returns approval or denial document also containing rationale
  6. BPEL forwards decision to applicant

9. Narrative

This use case is based on a real commercial credit approval service. The service is deployed as a Web service that takes an applicant credit request document as input and returns an approval or denial (with reason).

The implementation of the service is a BPEL orchestration of two web services -- a credit history providing service and a decision service containing a rules engine. BPEL first passes the credit request document to the decision service to determine, using rules, whether a enough information (SSN, Mother's maiden name, etc.) is available to request a credit history. If so, BPEL then requests a credit history and from the history providing service and passes the credit history document to the decision service to be evaluated. Based on the evaluation, credit is approved or denied.

Because the rule engine is a web service, existing BPEL diagramming and execution facilities can be used to integrate rules into this credit approval service. The credit evaluaton model can be changed easily using GUI tools to customize rules. Use of RIF would improve the situation further. First, the credit history vendor could supply a default set of rules for evaluating its histories. Second, there would be several rule editing and customization tools from different RIF compatible vendors to tailor the rules to meet specific business objectives.

Because web services use XML data for their request and response format, the rules must be able to access and compare XML data in their conditions, and modify and generate XML data in their actions.

The credit evaluation rules are grouped into three rulesets that are executed sequentially. Rules in the first ruleset apply thresholds to several "red flag" quantities in the credit report, such as

A red flag above the threshold results in denial of credit.

Rules in the second ruleset increment a credit score variable. For example,

The third and final ruleset compares the applicant's credit score and income to threshold values, and makes the final decision to approve or deny credit to the applicant.

The decision and supporting rationale is returned from the decision service as an XML document. This decision document is then used to construct the reply to the original credit approval request.

10. Commentary

Comments, issues, etc. Again, note that the wiki automatically keeps a revision history.