watch stock | how to trade forex

Design for Rules in a Homegrown Service-Oriented Rules Capability

There are various ways you can build a simple service-oriented rules capability. Keep in mind that a commercial rules product will likely be more sophisticated than one that you build. For example, as indicated earlier, a commercial rules product may also automatically manage the generation and distribution of rule code.

Let's review the logic behind a service-oriented rules capability.

Again, recall that a business event is serviced by a business process, which consists of a flow of tasks and is supported by screens or Web pages. The system behind the process processes input, as any other system, until it arrives at a point of needing a decision to be made by the rules capability. The application invokes the rules capability, passes required information, and requests execution of the decision. The rules capability recognizes the decision, accepts the input, and executes the latest set of rules required to make that decision. The rules capability passes the result of the decision, which is the result of executing the underlying rules, back to the calling system.

So, for example, if the system were processing an employee salary change, it would invoke the rules capability to determine if a change in salary is acceptable. The rules capability would execute all rules associated with that decision. These would include perhaps the same constraints as above on the new versus old salary value, constraints on the maximum or minimum value, and so forth. If the system were taking an order from a customer, the system would invoke the rules capability to make several decisions, such as whether the total amount of the order is within the customer's credit limit. Perhaps the system would ask the rules capability to estimate the day of delivery to that customer. Perhaps the system would ask the rules capability to find the least expensive way to deliver the products to the customer. Each of these would be a decision, requiring the execution of many rules. The rules capability executes those rules and sends back a message as to the result.

In concept, then, you create a rules capability that accepts decision requests from various applications and has a predefined process by which to execute the rules that arrive at that decision. You may decide to organize rules into rule sets where each set relates to a decision.

Guideline 12.9.1

Create a rules capability that accepts invocation from your system and processes decisions requested.

To keep it simple, define an interface to your rules capability, by which an application requests a decision and passes arguments. You can create object classes for each business object for which the application passes data. Those object classes can contain the rules within corresponding methods, coordinated by the control object class that correlates those executions with the specific decision being requested. You may have a control object class that manages the rules capability by associating the decision request from the application with the execution of a specific rule set, hence execution of the appropriate methods.

As you can appreciate, complex decisions are probably best handled by the appropriate commercially available rules product.

Again, keep in mind that, if you develop your own rules capability, the need for your own rules repository is even greater because you will not be using a rules product that provides a repository function.