Introduction

In the first paper in this series (see Resources) we introduced an on demand business process scenario for an Order to Manufacturing Processing System (OTMPS). Over time, the OTMPS executives or owners will introduce new requirements on the OTMPS implementation. For example, they might ask to change the policies (for a definition of policy see the sidebar entitled "Policy, rules, and enforcement points") for deciding which manufacturing plant to use for specific orders. Policies might change as a result of competitive requirements, external regulations, new business models, and other factors.

Analysts might specify intended policies as natural language annotations in the business process model using IBM® WebSphere® Business Integration Modeler (Business Integration Modeler), as described in Part 3 of this series (see Resources). However, policies don't have to be enforced if rules are executed at the appropriate locations. We cannot automate the implementation of these rules from the policy statements. In some cases, policies are not explicitly specified, but are rather implicitly defined by a set of implemented rules.

In traditional applications, rules are embedded with the logic inside the application. In such applications, when policies change, the application code needs to be updated and re-deployed to reflect the change. Externalizing the rules allows analysts and other less-technical users to dynamically modify policies that have been defined without changing the process logic.

Given the long-running nature of business processes, there is usually a need to change these policies dynamically. To reuse the existing workflow and service artifacts, it is essential that the architecture enables late customization for policy changes. These customizations are achieved during workflow execution through dynamic changes to the rules that implement and enforce polices. Some polices can be enforced through configuration parameters (see the side-bar entitled "When to use rules versus configuration parameters" for details).

In this article, we describe Business Rules Beans (BRBeans) framework and the implementation of a rule service facade. In addition, we illustrate an example through the following step-by-step methods:

• Specify a policy using Business Integration Modeler.
• Create the necessary rules to implement that policy.
• Enforce those policies through enforcement points in the process and workflow model.

Back to top

Business Rules Beans

BRBeans is a rules framework (see Figure 1) in IBM WebSphere Business Integration Server Foundation. It is implemented using Enterprise Java Beans components such as Rule, RuleFolder, and RuleHelper. Each rule is represented by an entity bean that persistently stores information related to that rule. Each rule is assigned an appropriate rule name and associated properties (for example, start date, end date, available, javaRuleImplementorName) and is stored in an appropriate rule folder. A rule implementation is an algorithm written in Java language and associated with the rule through a javaRuleImplementorName rule property. Listing 1 shows a sample rule implementation.

public class RuleSelectManufacturingPlant implements RuleImplementor {
	public Object fire(TriggerPoint arg0, Object arg1, IRuleCopy arg2,
		Object[] arg3) throws BusinessRuleBeansException {
		String mfgPlant = null;
		? //set mfgPlant using the initialization and input parameters i.e. arg3
		return mfgPlant;
	}
	public void init(Object[] arg0, String[] arg1, String arg2, IRuleCopy arg3){
		? //set initialization parameters
	}
}
			

When the rule is fired, it takes its persistent data plus any parameters, and together these are passed to the RuleImplementor code. A rule management application is provided to create and modify rules. A Trigger point framework is provided to execute a rule from the application code. This framework implementation can dynamically associate a rule name with a particular rule implementation. As Listing 2 shows, BRBeans clients execute the rules by invoking the trigger() method in the TriggerPoint class. This class is used to transfer control to the trigger point framework to find and fire the rules specified in the application's trigger point.

TriggerPoint tp = new TriggerPoint();
params [ ] = { var1, var2, var3 };
String ruleName = "com/xyz/Rule?";
Object result = tp.trigger(this, params, ruleName);
			

Back to top

Rules service facade

We suggest a service invocation which uses the BRBeans APIs, as shown in Figure 2, as an alternative to directly invoking the BRBeans APIs. This provides a service-oriented method for invoking the rules without directly invoking the middleware-provided APIs. This service façade approach provides a loosely coupled rule access mechanism that fits well with the web services programming model and process modeling. In addition, by using the façade pattern, you can later plug-in extended capabilities, such as rule mediation, versioning, and others.

There are many ways to logically partition and package the rules as part of service façade. For example:

1. You could wrap all the application specific rules in a service façade with each rule being exposed as a method or,
2. You could wrap each rule in a service façade with an access method.

All rules that can be shared across applications (such as security, business performance, and so on) can be defined in other common services façade.

Figure 3 illustrates the interaction between the workflow component, the OTMPS Rule service façade that we defined, and BRBeans rule framework.

In the OTMPS service façade, we wrapped all rules in a single service (OTMPSRules), where each rule is exposed as a method of the service, as shown in Listing 3.

public class OTMPSRules {
	public String SelectManufacturingPlant (Order  order) { 
		return ?.;
	};
public String DetermineConfigurator(Order  order) { 
		return ?.;
	};

}
			

This rule façade service exposes the rules using WSDL portTypes, as shown in Listing 4.

<portType name=" OTMPSRules">
        <operation name="SelectManufacturingPlant" parameterOrder="order">
        </operation>
        <operation name=" DetermineConfigurator" parameterOrder="order">
        </operation>
</portType>
			

At enforcement points, rules are invoked as normal web services, passing the necessary parameters for execution. The OTMPPSRules service façade is invoked from the workflow using the Business Process Execution Language (BPEL) partnerLink and the BPEL invoke operation.

Each rule service façade operation creates an instance of the TriggerPoint class and invokes the trigger() function on that class with the reference to invoker, input parameters, and the rule name. Listing 5 illustrates this implementation.

public class OTMPSRules {
public String SelectManufacturingPlant (Order order) { 
	TriggerPoint tp = new TriggerPoint();
params [ ] = { order };
String ruleName = "com/ibm/otmps/RuleSelectManufacturingPlant";
String result = (String)tp.trigger(this, params, ruleName);
	return result;
	};
public String DetermineConfigurator (Order order) { 
??.. 
	}	
}
			

Back to top

Policy implementation example

In our sample scenario, the business owners defined a policy for manufacturing plant selection for specific orders. For example, a policy might specify that orders with a value exceeding US$1 million should be processed by certain manufacturing plants according to some priority criteria, for example, turn-around time. Another example policy might specify how to handle orders when the preferred plant is not in production.

Figure 4 shows the roles, tools, and the specific activities conducted by each role while implementing the policies. Analysts collect the required polices from the business owners and document these policies in the process models created in Business Integration Modeler. You can later add the necessary code to actually implement these policies by implementing rules and rule services and connecting the workflow to the rule services. Deployment managers are responsible for deployment and administration of these rules.

Back to top

Document policies in Business Integration Modeler

The analyst documents the policies through annotations. Each of these policy statements annotations should eventually be implemented through enforcement points. For example, they can be implemented as rules external to the workflow. Figure 5 shows an example of a policy annotation in Business Integration Modeler.

We suggest two ways to add enforcement points to the process model:

1. Add to the model service elements which represent pre-existing services that provide enforcement points.
2. Add tasks to represent placeholders for code which will enforce policies.

Figure 5 shows a task (Apply manufacturing Plant Selection Policy) that is defined to be a placeholder for enforcing the policy (Select Manufacturing Plant). You can later add the necessary code to actually implement the task.

Back to top

Create rules and rule services

Using the annotations in the process model as requirements, the developer codes the necessary rules and rules service implementation.

As the developer, you should complete the following tasks:

1. Create the rule implementation using BRBeans APIs for the corresponding polices defined in the modeler.
2. Deploy and configure the rules in the BRBeans framework.
3. Create a service façade for the created rules.
4. Create the necessary interfaces and bindings for the rule service.

We detail these steps here:

1. Rule implementation

package com.ibm.coats.poc2004.ruleimplementors;

import coats.objects.order.item.OrderItem;

import com.ibm.websphere.brb.BusinessRuleBeansException;
import com.ibm.websphere.brb.RuleImplementor;
import com.ibm.websphere.brb.TriggerPoint;
import com.ibm.websphere.brb.mgmt.IRuleCopy;
import java.util.StringTokenizer;

public class RuleSelectManufacturingPlant implements RuleImplementor {
	
	private StringTokenizer Plant1Codes;
	private StringTokenizer Plant2Codes;
	private String delimeter = ",";

	public Object fire(
		TriggerPoint arg0,
		Object arg1,
		IRuleCopy arg2,
		Object[] arg3)
		throws BusinessRuleBeansException {
			
		String mfgPlant = null;
		String mfgCode = ((OrderItem)arg3[0]).getMfgCode();
				
		if (findCode(Plant1Codes, mfgCode)) {
			mfgPlant = "Plant1";
		} else if (findCode(CRSCodes, mfgCode)) {
			mfgPlant = "Plant2"; 
		} else throw new BusinessRuleBeansException("No manufacturing 
		plant found for \"" + mfgCode + "\"\n\n");
		
		
		return mfgPlant;
	}

	public String getDescription() {
		return "This rule finds the manufacturing plant to send the order to by 
		comparing the manuPlant code for the order against the 
		initialization parameters.";
	}

	public void init(Object[] arg0, String[] arg1, String arg2, IRuleCopy arg3)
		throws BusinessRuleBeansException {
			
			String plant1CodeString = (String)arg0[0];
			String plant2CodeString = (String)arg0[1];

			Plant1Codes = new StringTokenizer(plant1CodeString, delimeter);
			Plant2Codes = new StringTokenizer(plant2CodeString, delimeter);
	}
	
	private boolean findCode(StringTokenizer st, String code){
	
		String token;		
		
		while (st.hasMoreTokens()) {
	            	
				token = st.nextToken().trim();	
				if (token.equals(code)){return true;};
		}	
		
		return false;
	}
	
	

}
			

Listing 6 shows the implementation of the rule Select Manufacturing Plant. In BRBeans a rule is implemented as a Java class (for example, RuleSelectManufacturingPlant). Each rule class implements the RuleImplementor interface which includes two methods: fire and init. The fire method is triggered for the rule execution and the necessary logic is provided for the execution of business rules, such as selection of the manufacturing plant. The fire method uses the persistent data stored in the rule bean and the parameters passed as arguments for the execution of the rule. The ?init? method provides an initialization routine for rule bean.

2. Rules management in BRBeans: BRBeans provides a Java application -- rulemgmt, for managing application rules. This rulemgmt application is invoked with a properties file as input that refers to the access information for BRBeans. Listing 7 shows the properties file for OTMPS.

host=localhost
port=2809
RuleJndi=brbeans/OTMPS/Rule
RuleFolderJndi=brbeans/OTMPS/RuleFolder
RuleHelperJndi=brbeans/OTMPS/RuleHelper
			

In order to run this application, the BRBeans server should be running. Figure 6 shows the GUI of rulemgmt. This application can be used to create new folders and rules. Three required attributes for a rule are: 1) fully qualified name, 2) implementation class, and 3) initialization properties. A double-click on a rule brings up the rule configuration window. Figure 7 shows the rule configuration window for the selectManufacturingPlant rule.

3. Rule service façade implementation: The above rule implementation can be invoked using a rule service façade, as shown in Listing 5.

4. Rule service interface: Once the service façade is implemented, a service interface and binding elements are generated. Listing 4 shows a simplified version of the WSDL generated for the OTMPSRule service.

You can create the WSDL interfaces using the IBM WebSphere Studio Application Developer Integration Edition feature Service build from?. For example, select the OTMPSRules service façade and invoke Service build from?. Check the methods that are to be exposed as service operations. This tool generates the WSDL interface and service and binding files required for accessing the OTMPSRules service.

Back to top

Access rule service from BPEL workflow

Each task in the Business Integration Modeler model is mapped to a partner service in the BPEL workflow. As Figure 8 shows, the policy enforcement task (Apply manufacturing Plant selection Policy) shown in the Business Integration Modeler model (Figure 5) is mapped to an invoke service in BPEL.

As explained earlier, this invoke activity can be connected to the correct rule service or can be pointing to a placeholder service. In the case of using a placeholder service, you connect the invoke activity to the correct rule service implementation through the BPEL partnerLink. There are three activities you perform to invoke the rule service:

1. Create a new Partner Link for the rule service.
2. Create the input and output variables that correspond to rule service operation messages.
3. Connect the Apply manufacturing Plant selection Policy BPEL invoke activity to the newly created partner link.
• Add partnerLink for rule services: Select the artnerLinks in the OrderProcessSystem process in the BPEL editor. Add a new partnerLink (RuleServicePartner). In the Implementation property sheet of the partner link, click Edit to edit the partner link type. Give the process a role name and link this process to the rule service interface. In addition, select the correct portType from the WSDL file.
• Create the input and output variables for the rule service: Figure 9 shows two variables, RulesServiceInput and RulesServiceOutput, with their corresponding message details, including WSDL file name, message name, and parts name.
  Figure 9. Variables and their properties
  
  
• Connect the invoke activity to partnerLink: Once the partnerLink and associated messages are defined, select the invoke activity (Apply manufacturing Plant selection Policy) and associate the correct partnerLink, portType, request variable, and response variable and associate the correct operation to the invoke activity. Figure 10 shows the properties of the invoke activity after connecting to the rule service façade created earlier.

Back to top

Customize rules

Various customization options are available through the BRBeans administration user interface (see Figure 6). Options include the following:

• Select the rule effective period.
• Add initialization parameters to the rule.
• Change the rule implementation class.
• Expire current rules.

The analyst could use these capabilities to enforce the customizations required for the business processes without changing the workflow code. For example, the analyst could change the initialization properties for the selectManufacturingPlant rule and redeploy the rule class without changing the workflow code.

The time it takes for a rule change to become effective depends upon the configurable PollFrequency of the system rule -- BRBCacheRule (in brb folder). The default value for PollFrequency is 10 minutes. Lowering this value means that a rule change becomes effective sooner, but it could have a negative performance impact, as the system will poll more often.

Back to top

Conclusion

Workflow customization to support dynamic polices is a key element of the on demand business process life cycle methodology. This paper described a method to customize an on demand business process using policies enforced by rules within a SOA framework.

Back to top

Acknowledgements

The authors would like to thank Mark H. Linehan, Margie Mago, Jon K. Peterson, and Catherine Rivi for their contributions, suggestions, and assistance with this content.

Resources

• Get a history and overview of Eclipse, including details on how to install Eclipse and plug-ins in the paper Getting started with the Eclipse Platform (developerWorks, November 2002).
  
  
• Read all parts of the On demand business process life cycle, and keep track as we add new installments.
  
  
• Read the specification Business Process Execution Language for Web Services, Version 1.1 on developerWorks.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Business Rules Beans
• Rules service facade
• Policy implementation example
• Document policies in Business Integration Modeler
• Create rules and rule services
• Access rule service from BPEL workflow
• Customize rules
• Conclusion
• Acknowledgements
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into SOA and Web services on developerWorks

Discover knowledge paths

Skill-building guides for Linux, open source, cloud, Java, business analytics, and more.

Special offers