Rule-based Web services depend on the use of XML data for their request and response format. The involved rules must be able to access and compare XML data in their conditions and modify and generate XML data in their actions.
An existing commercial credit approval service deployed as a Web service takes an applicant credit request document as input and returns an approval or denial (with reason). It is implemented as 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 enough information (SSN, mother's maiden name, etc.) is available to request a credit history. If so, BPEL then requests a credit history 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 part of a Web service, existing BPEL diagramming and execution facilities can be used to integrate rules into this credit approval service. The credit evaluation 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.
The credit evaluation rules are themselves 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:
- number of times a payment was 60 days late
- debt-to-income ratio
- number of foreclosures or repossessions
- number of garnishments
- number of liens
- bankruptcy
A red flag above the threshold results in denial of credit.
Rules in the second ruleset increment a credit score variable. For example:
If applicant owns residence then add 40. If applicant rents then add 30. If applicant has lived at current address 2 to 4 years then add 20. If applicant's income is under 20000 then add 10. If applicant's income is between 40000 and 50000 then add 40.
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.
Motivates:
- The scoring rules express actions and not logical conclusions. Therefore production rules are required. These additional RAF discriminants are also relevent:
- Syn 5: Slotted (Keyed, Role-Named) Arguments, since they directly correspond to attributes in Web service descriptions
- Syn 6: Webized Names, since URIs are fundamental to Web service descriptions
- SeS 9: Priority, since conflicts between credit evaluation rules can often be solved based on relative rule importance
- Sem 2: Decidable, since there must be a definitive answer for every credit request
- Sem 3: Finite-Model Rulebases, because of the reason given for Sem 2
- Prag 2: Computational complexity should be tractable, since response time should be acceptable
- Prag 3: Interoperability Annotations should use Controlled English, since justifications/explanations of decisions should be understandable without formal training
- Web services depend on XML request and response formats.
- Rule variables must be bound to fields from the XML request and response formats.