From the Desk of Mohamad Afshar, PhD

Mohamad Afshar

Subscribe to Mohamad Afshar: eMailAlertsEmail Alerts
Get Mohamad Afshar: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: SOA & WOA Magazine

SOA & WOA: Article

Building Flexible Business Processes Using BPEL and Rules

Don't embed business policies in your business processes: Automate them with a business rules engine!

Business Rules as a Decision Service Using the Service-Oriented Approach
Now let's talk about how you can embed rules in your composite application using a decision service. A decision service is a mechanism for publishing rules and rule sets as a reusable service that can be invoked from multiple business processes and applications. To set this up you have to: (1) define the facts and the corresponding rule sets that will be used by various applications, (2) publish these as a decision service that can then be invoked from the business process.

  • Define facts: As discussed earlier, each rule that is exposed as a service will use different types of facts. These facts have to be created via XSD definitions or by importing the corresponding Java classes. If you are using an open standards-based BPM solution based on BPEL, it is preferable to use the same XSD definition for defining facts for the rules engine and variables in the BPEL process to avoid the need for transformations when exchanging data with the decision service. If a rules engine supports only Java-based objects, you could use a Java Architecture for XML Binding (JAXB) translator to generate Java objects from XSDs.
  • Design rules: Rules are generally authored using the rules designer of the BRE or the rules tooling provided by the BPM solution. For some complex rules, you may have to directly use the underlying rules language. At this point, you may also decide which rules are modifiable by business analysts. For this you may have to define aliases for certain fields in your data model and also define appropriate constraints on the rules; for example, you could say that [customer.loanapplication.loan_amount] has an alias "Loan Amount." By using these aliases, you don't have to worry about the actual hierarchical structure of the data model. The business analyst defining the rules does not really need to know where this attribute is retrieved from in the hierarchical data model. The rules can be grouped into rule sets and deployed to the repository.
  • Create the decision service: The decision service is a Web service that wraps the rule session to the underlying rules engine. This service lets business processes assert and retract facts as part of the process. In some cases all facts may be asserted from the business process as one unit, while in other cases, the business process may incrementally assert facts and eventually consult the rules engine for inferences. Hence, the service has to support both stateless as well as stateful interactions. Various interaction patterns are possible with this service - assert, assert/execute, etc.
  • Load facts: Facts may be passed in directly from the business process or may be periodically loaded from a back-end repository, such as a database, file system or an external application. Adapters or other fact-retrieving mechanisms can be used to load facts periodically from back-end systems such as databases or files. The adapter services can be used internally as part of the decision service to load facts. For example, for the credit rating decision service, facts such as the customer's SSN and loan amount may be passed in from the business process, but other facts, such as the customer's credit history and outstanding loans, may be retrieved using adapters from a back-end repository.

The aforementioned architecture is illustrated in Figure 1. The rules engine works off a common rules repository, and all rules are exposed via a decision service. The process developer defines the rules metadata, creates the service, and designs the BPEL process to interact with the rules. The business analyst generally uses the rules metadata to define the rules and customize rules on an ongoing basis after the process is deployed. The BPEL processes, BAM, and other applications assert facts and execute rules by interacting with the decision service.

We have provided details on the approaches that you can take for implementing decision logic in business processes, and given some guidance on when to apply each approach. Monolithic BPM suites limit your flexibility in integrating process and rules logic because they don't allow you to easily assert facts from external sources or use your existing rules engines. We believe that an open standard, BPEL-based BPM solution is ideal. Such an open approach enables you to develop rules in a code-based, model-driven, or service-oriented manner. It provides an embedded business rules capability, yet allows you to replace the rules engine with your choice of third-party rules engine, or make the embedded and your third-party rules engine coexist. By delivering on this, it yields ease of development through common tooling for process and rules, and improved performance, yet delivers full flexibility. Who says choice is a bad thing?

Further details on how to implement a service-based business rules service in the context of BPEL can be found at under the link "SOA Best Practices: The BPEL Cookbook."

More Stories By Mohamad Afshar

Mohamad Afshar, PhD, is VP of Product Management at Oracle. He has product management responsibilities for Oracle's middleware portfolio and is part of the team driving Oracle's investments in SOA on Application Grid - which brings together SOA and data grid technologies to ensure predictable low latency for SOA applications. Prior to joining Oracle, he founded Apama, a complex event processing vendor acquired by Progress Software. He has a PhD in Parallel Systems from Cambridge University, where he built a system for processing massive data sets using a MapReduce framework.

More Stories By Bhagat Nainani

Bhagat Nainani is a product development manager in the Oracle Application Server division. He currently leads the development of BPM services for the Oracle BPEL Process Manager. He has more than 10 years of experience with distributed systems, enterprise software, and integration technologies.

Comments (3)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.