A Services-Oriented Approach to Business Rules Development
by Kevin Geminiuc

In this first installment of the SOA Best Practices: The BPEL Cookbook, learn how to reduce maintenance costs and improve organizational flexibility through a services-oriented approach to business rules development and management.

Downloads for this article: Oracle BPEL Process Manager and Designer

Many organizations are moving from an object-oriented paradigm for managing business processes toward a service-oriented approach; indeed, services are becoming the fundamental elements of application development. At the same time, Business Process Execution Language (BPEL) has become the de facto standard for orchestrating these services and managing flawless execution of business process. The confluence of these trends is presenting some interesting opportunities for more flexible, cost-effective management of business processes.

Most business processes—loan-approval processes being a good example—contain multiple decision points. At these decision points, certain criteria are evaluated. Based on these criteria or business rules, business processes change their behavior. In essence, these business rules drive the business process. Frequently, these rules are embedded within the business process itself or inside custom Java code, which can cause several problems down the road:

• Business rules change more often than the processes themselves, but changing and managing embedded business rules is a complex task beyond the abilities of most business analysts. Thus, as business rules change, programmers often have commit expensive time to this task.
• Most organizations lack a central rules repository. Consequently, any organization-wide change in policy cannot be applied across all business processes.
• Business processes cannot reuse rules. Hence, IT personnel end up designing rules for each and every process, often leading to inconsistency or redundancy.

Rules engines and BPEL are complementary technologies. Oracle BPEL Process Manager provides high-level tools to visualize, design, and manage BPEL process flows, whereas third-party rule engines allow complicated business logic to be expressed in English-like syntax and edited by nonprogrammer domain experts.

In this first installment of The BPEL Cookbook, I'll provide best practices for separation of process and rules based on my team's own experience. Using code examples, I'll also offer a development approach and change management strategy for integrating BPEL with a rules engine. Finally, I'll explain how this architecture leads to proper separation of logic across different layers.

Separating Rules from Processes

Integrating a rules engine within a process management framework requires some investment up front. Before you attempt this integration, it is important to delineate rules from process. Hence, a major decision in system architecture is how to implement business policies, business processes, and supporting business logic. Indeed, the architect must communicate or invent best practices so that designers know where each of the relevant technologies—BPEL, business rules, Java/Web services—should be applied when designing system functionality.

As illustrated in Figure 1, business logic is spread across three different layers of the IT infrastructure: business process, Web services, and rules. Let's address each in turn.

Figure 1 Architecture: separating rules from processes

Business Process Layer. This layer is responsible for managing the overall execution of the business process. These business processes, implemented using BPEL, can be long running, transactional, and persistent. Process logic supports high-level transactions ("sagas") across Web service/EJB calls as well as nested sub-process transactions. The BPEL engine supports audit and instrumentation of workflow and thus is well suited for

• Separating less volatile workflow steps from more volatile business rules
• Implementing line-of-business processes
• Implementing process flows requiring compensation
• Supporting large-scale instantiation of process flows
• Designing process flows that need auditing
• Orchestrating heterogeneous technologies such as connectors, Web services, and Web Services Invocation Framework (WSIF)-enabled logic

Web services implement functional and domain logic. Functional methods are typically stateless and medium-grained. Web services may for example contain utility methods, entity operations, and inquiry methods for system data. You can implement Web services using multiple technologies and hide differences among implementation platforms. Thus, this layer is well suited for:

• Implementing medium-grained methods for a particular entity/domain area
• Integrating legacy code/third-party party tools
• Encapsulating logic, custom code, and implementation from the application layer

Rules engines allow for evaluation of rules sets in parallel and in a sequential order. In addition, rules have the ability to evaluate the values of input and intermediate data and determine if a rule should be fired. This modular design provides a simpler and more maintainable solution than traditional Java procedural code.

Furthermore, as I mentioned previously, rules are declarative and allow high-level GUI editing by business analysts. Modern rule engines execute extremely quickly and provide built-in audit logging. The typical traits of a rules layer are

• Contains coupled and complex logic
• Supports efficient business logic evaluation using parallel execution
• Contains complex return structure built from multiple business rule evaluations
• Allows for translation of domain logic into simple rules
• Implements highly volatile business policy

Development and Maintenance

To illustrate the development process, we will use the example of a business process called Eligibility Process. This process assesses the eligibility of a family for a specific healthcare program. Depending on the attributes of the family (income, total number of children), it assigns the family to Healthcare Program 1 or Healthcare Program 2. During the analysis phase, logic is categorized into different buckets based on volatility and complexity. As discussed in the previous section, rules typically model complex return structures that require multiple business validations as well as policies that change frequently or that affect large parts of the organization. In contrast, departmental or organizational processes are modeled in the business process layer.

The typical development process comprises three steps:

1. Create rules in a ruleset
2. Expose the ruleset as a Web service
3. Invoke the ruleset Web service from BPEL

Figure 2 Development and maintenance roles

1. Create rules in a ruleset. The development phase begins with a rule developer creating the initial rules in an integrated graphical development environment, such as ILOG's JRules business rule management system. (See sidebar for information about business rules functionality in Oracle Fusion Middleware.)

After developers have created the object model and rule repository, you need to decide which rules will be maintainable by analysts versus those to be developed in the low-level language (IRL). After creating the developer-level rules, the developers work with analysts to identify the remaining rules and capture them in rule templates, which can be reused by multiple non-technical parties. This method simplifies and accelerates rule production and reduces the incidence of human error.

To start the template-based rule creation process, the analyst connects to the rule repository. When he or she has opened the rule package from the repository, they will have access to its BOM. ILOG supports the definition of high-level rules through its Business Application Language (BAL). The analyst can edit an existing rule or create new rules at this point. Rules may be modified through a template during the maintenance phase, which limit what modifications can be made to the rule.

The rule editor has a default template and allows a developer to create conditions and action using the IF–THEN construct. As shown in Figure 3, the business analyst is creating a rule that checks the total number of children in the family. If this variable equals 2, then the family qualifies for Healthcare Program 1. Rule returns the value true in datatype eligibilityResult.

Figure 3 Creating a rule that checks the total number of children in the family

After a new rule is developed it can be tested with sample data inside the ILOG Rule Builder tool. This debugger in Rule Builder supports breakpoints, allows the user to inspect working memory facts, and displays the rule execution order. When rule editing and testing are complete, the analyst will export the rule package into a ruleset and deploy back to the repository.

The code example below shows the implementation of Eligibility ruleset.

                               
// Eligibility ruleset receives an account and calculates eligibility results for multiple programs

ruleset eligibility {
        in Account account;
        out List eligibilityResultsList = new ArrayList();

}

// calculate program 1 then program 2 eligibility
flowtask Program1_TaskFlow {
        body = {
                Program1_Setup;
                Program1_Eligibility;
                Program2_Setup;
                Program2_Eligibility;
}
};

// Determine which rules are setup rules for program 1
ruletask Program1_Setup{
        body = select(?rule) {
                if("Program1_Setup".getTask(?rule) )
                        return true;
                else
                        return false;
        }
}

// Determine which rules are eligibility rules for program 1
ruletask Program1_Eligibility{
        body = select(?rule) {
                if("Program1_Eligibility".getTask(?rule) )
                        return true;
                else
                        return false;
        }
}

// Create an eligibility result (JAXB object) for program 1
rule Progam1.CreateEligibilityResult {
        property task = " Program1_Setup";
        when {
                ?account: Account();
                ?person: Person();

        }
        then {
                bind ?result = new EligibilityResult ();
                ?result.setPersonId(?person.getPersonId());
                ?result.setProgramType(ProgramEnum.PROGRAM1);
                ?result.setEligible(Boolean.FALSE);
modify ?person { getEligibilityResults().add(?result); };
        }
};


// simple rule make person eligible if over 6 years old and returns
// result back in finalResults map
rule Program1.AgeQualification {
        property task = " Program1_Eligibility";
        when {
                ?person: Person(?age: getAge().intValue(););
                evaluate(?age >= 6);
}
modify ?result {setEligible(Boolean.TRUE); };
finalResults.add(?result);
        }

};

                            

XML is a key standard for integrate rules, EJBs, BPEL process flows, and Web services. BPEL uses XML natively to access data while Web services use it to serialize data (and will use it unmodified in Doc/Literal invocations). XML can be used directly in rules. By marshalling, XML can be transformed directly into a JAXB object tree. Rules can be executed with native Java Objects.

Web services should import XML Schema in their respective WSDL definitions. Generated DTO objects from XML Schema (e.g. JAXB) can also help ensure that data is translated smoothly without conversion errors.

Eligibility Web service provides the translation from XML to JAXB and then invokes the Eligibility Rules Delegate Session Bean. To hide the complexity of invoking JRules custom libraries, you would create a session façade. This approach makes the implementation rule engine "agnostic;" the system could be easily ported to a new rule engine provider. Eligibility Delegate Session Bean makes an RMI call to Eligibility façade Session Bean. This session bean invokes the Eligibility ruleset in the RuleApp package using ruleSession.executeRules("RuleApp/eligibility").

                               
import ilog.rules.bres.session.IlrRuleExecutionResult;
import ilog.rules.bres.session.IlrStatelessRuleSession;
import ilog.rules.bres.session.ejb.IlrManagedRuleSessionProvider;
import ilog.rules.bres.session.util.IlrRuleSessionHelper;
        .
        .
        .
    public List assessEligibility(AccountRoot account) {

        List eligibilityList = null;
        // get stateless rulesession instance
        IlrStatelessRuleSession ruleSession = null;
        try {
                ruleSession = IlrManagedRuleSessionProvider.getProvider()
                                .createStatelessRuleSession();
        } catch (ilog.rules.bres.session.IlrRuleSessionCreationException ce) {
                        String msg = "Failed to retrieve RuleSession Provider";
                        throw new InfrastructureException(msg, ce);
        }

        // pass borrower and credit as "in" parameters of the stateless session.
        IlrRuleSessionHelper helper = new IlrRuleSessionHelper(false);
        helper.addParameter("account", account);

        try{
        // execute rules and handle results
IlrRuleExecutionResult res = ruleSession.executeRules("/RuleApp/ eligibility", null,
helper.getJavaClassResolver(this), helper.getParameters());
                eligibilityList = (List)res.parametersOut.getHandle("finalResults").getValue();
        } catch(Throwable t) {

String msg = "Failed to execute rule!";
                        throw new InfrastructureException(msg, t);
        }
        return eligibilityList;

}

                            

For example, BPEL will invoke the underlying Eligibility Web service using the code below.

                               
<assign name="setAccount">
  <copy>
     <from variable="BPELInput" part="payload"
            query="/tns:EligibilityProcessRequest/tns:Account">
     </from>
     <to  part="parameters"
          query="/nsxml0:assessEligibility/nsxml0:Account"
          variable="webservice_account"/>
  </copy>
</assign>

<invoke name="CallEligibilityWebservice" partnerLink="EligibilityWebservice"
        portType="nsxml0:EligibilityService" operation=" assessEligibility "
        inputVariable="webservice_account" outputVariable="webservice_eligibilityResults"/>

                            

Executing JRules with Oracle BPEL Process Manager

Clearly, the design and development of rules, Web services, and BPEL processes involve multiple different technologies. In this section, I will discuss how these technologies work together at runtime to execute Eligibility Process. Although this example is based on Oracle BPEL Process Manager and ILOG JRules specifically, it is applicable to many other environments.

The rule engine invocation occurs across three tiers (see Figure 4): BPEL invoking the rules Web service, rules Web service invoking the rules engine, rules engine application code receiving input and returning results.

Figure 4 Rule engine invocation in action

In the context of our example business process, the application invokes Eligibility process with an XML payload. This payload contains information about the account, such as family attributes. Eligibility process in turn invokes the Eligibility Web service. Eligibility Web service provides the translation from XML to JAXB and then invokes the Eligibility Rules Delegate Session Bean. The latter interacts with session façade using RMI. Session façade activates the rules engine, which then calculates and returns eligibility results to the process. Eligibility Process will assess the return and assign either Program 1 or Program 2 to the account. In our example we provide a remote server to run eligibility rules, but this could just as well be hosted locally. (Note that it is best practice not to co-locate non-process services with the BPEL Process Manager to allow for better scalability.)

This example effectively illustrates the separation of business logic into rules, BPEL, and Web services:

• Eligibility BPEL Process explicitly defines the steps that must be executed based on the received Eligibility Results data. Based on the Eligibility Results, Eligibility BPEL Process will invoke different branchs. Program 1 and 2 each execute different steps, and these steps can be easily modified using a BPEL designer.
• Eligibility Web services execute medium-grained tasks for the BPEL Process Manager, which encapsulates the mechanics of how to send correspondence and queue tasks. Web services operate on summary data from the common data model such as database keys (such as an Account OID) that can be used to extract detailed data to perform the required task.
• Eligibility rules do not modify the original data, nor do they access external data sources. The rule-engine auditing trail is trivial because you have the exact record of the data in/out of the rules.

Figure 5 Integrating rules into a J2EE platform via Web services

Conclusion

In this BPEL "recipe," I've presented a strategy for spreading business logic across three different layers: business process layer, Web services layer, and rules layer. You can utilize these complementary technologies to minimize interdepencies between data and logic. However, to derive full benefits, the architect must perform a rigorous analysis to decompose the system components and design them using the appropriate technology. Development process involves multiple technologies and various roles. It is necessary to identify appropriate resources up front to participate in the development process. The resulting architecture is an agile platform on which business users handle most business changes without IT intervention.

Send us your comments