• Discussion of UC1 - Negotiating eBusiness Contracts Across Rule Platforms

Discussion of UC1 - Negotiating eBusiness Contracts Across Rule Platforms

Processing model

Both actors, John the buyer and Jane the supplier, use a rule-based application to compute the price of requested or supplied items under various conditions (real or hypothetical). They interchange the pricing rules that are specific to a supply contract, e.g. specifying how the actual price is to be computed from the list price under specific circumstances. In the use case scenario, the processing of rules goes as follows:

1. John writes the pricing conditions he wants for a requested supply;
2. John issues a RFP, including the rules;
3. The RFP is serialized in XML according to an agreed-on XML schema, the serialization of the rules in compliance with RIF;
4. The XML documents, including a RIF document, are sent to Jane;
5. The RIF document is translated back into a set of rules;
6. Jane executes the rules to compute the revenue for her company under various hypotheses (some where the rules impact the revenue, e.g. shipping delays etc);
7. Jane modifies some of the rules (and execute them to analyse other hypotheses);
8. Jane prepares an answer to John's RFP, including the rules, some of which having been modified, and send it to John (the rules are translated into a RIF document on Jane's side, whci is translated back into a set of rules on John's side);
9. John executes the rules to compute the cost for his company under various hypotheses (where the rules impact the cost, such as shipping delays etc);
10. And so on, until they agree on a contract (or not).

Steps 7-9 are the same as step 1-6, only in the other direction. So, that, from a rule processing point of view, the architecture/processing model for the use case looks basically like the picture below, where Application A can be called : the producer of the rules (and of the RIF document), Application B : the consumer; and the applications that produce a RIF document from rules or rules from a RIF document (represented by the "maps" arrows in the figure): translators.

Benefits of RIF

Without RIF, John and Jane would interchange rules as text (that is, as they probably do now). Since she uses a rule-based application for pricing and invoicing, Jane has to translate that text into her rule language anyway.Thus, RIF certainly benefits Jane, especially since John and Jane have already agreed on a common vocabulary and XML schema for that vocabulary, since they interchange data about RFP and proposals as XML document (and, thus, there are no additional cost in using RIF).

An additional benefit, to both John and Jane, of using RIF for interchange is that the semantics of the rules is fixed and, thus, the risk of misunderstanding is reduced.

These benefits could be achieved if John and Jane used the same rule language as well. The use of RIF makes the technology used by Jane irrevelant to John and reciprocally: they do not have to know what rule language the other's application uses, nor even if it uses one.

Requirements

An obvious constraint on the rule languages used in application A (RLA) and B (RLB) is that they must support a RIF class of expressiveness that is sufficient to express the rules they need to interchange.Although this is obviously true whether they use RIF for the interchange or not, in the RIF case, the applications may need to be aware of the RIF expressiveness class of the other part. In that sense, it motivates the "compliance model" requirement.

The use case motivates the "semantic precision": although John and jane could check that their respective interpretations of the interchanged rules are the same by comparing the execution results on either side, they would lose part of the primary benefit of RIF, since they would still have to code the other side's rules in their own RL by hand in case their systems disagreed.

The use case motivates the "Translators" requirement, if implementing RIF required John's and Jane's rule systems to be changed, it would conceivably be as easy and better for them to decide to change them to use the same rule language (and avoid using an intermediary language). That arument is probably true of any UC, anyway.

The use case motivates the "XML types" requirement, since the agreed echange data model in terms of which the rules are specified is an XML schema: for example if the rules are going to do tests and arithmetic on values transmitted over that XML then the semantics of those tests ought to be compatible with the corresponding XML datatypes - including all the annoying corner cases of NaNs, treatment of equality in floats/doubles, type promotion etc. If either end use different representations for the concrete types internally then the RIF "translators" are going to have to compensate.

Nothing in the description of the use case motivates the "implementability" requirement, except that the cost of implementing RIF must be, at least for Jane, less than the cost of moving to the same technology John uses.

Nothing in the use case motivates the "XML data" (whatever it means) requirement: their respective applications interchange data as XML documents, but that tells us nothing about how they process the data they interchange.

I am not sure what kind of requirement it is, but one requirement from the use case is that John as well as Jane must be able to edit the rules and modify them (in addition to their rule-based systems interpreting them): it is likely that they would do so only if it is possible in their usualrule editor, that is, if the rules can be translated back from RIF not only into the machine-interpretable form of their rule language, but into its human-editable form as well, if it is different.