Business process automation made easy with Java, Part 1
Implement business rule engines in a J2EE enterprise
These days, severe market demands drive enterprises to reduce costs and increase shareholder value. In such an environment, businesses can realize significant cost reductions and efficiencies by automating business process flows, eliminating nonvalue-adding human interventions, and allowing enterprise applications to communicate and intelligently and seamlessly share information. In this two-part series, we present the technology building blocks for automating an enterprise, how those blocks fit within an enterprise component architecture such as J2EE, and how you can design and build a business rule engine solution based on this architecture.
We begin by explaining business process automation components, then introduce existing J2EE-based (Java 2 Platform, Enterprise Edition) rules engines, and conclude by explaining how rule engines fit within an enterprise architecture.
Read the whole series, “Business Process Automation Made Easy with Java:”
- Part 1: Implement business rule engines in a J2EE enterprise
- Part 2: Design options for rule engine integration
What is business process automation?
We define business process automation as technology components substituting and/or supplementing manual processes to manage information flow within an organization to lower costs, reduce risk, and increase consistency. For example, Figure 1 illustrates a generic risk-assessment business process inherent in most financial applications such as mortgage preprocessing, claims processing, underwriting, and so on.
Such a manual risk-assessment process can lead to problems such as:
- Laborious data entry/re-entry
- Manual risk assessment that potentially varies from field to field
- No analytical data to validate past decisions (for improvements)
- Long turnaround times
Added up, such problems can make manual risk assessment an expensive process.
Figure 2 illustrates the same process in an automated environment.
Clearly, the transformed environment can significantly lower costs by eliminating manual data re-entry, shortening decision cycles via automated risk assessment, centralizing decision making, and lowering risk due to the analytical input.
Technology building blocks of a business process automation solution
Automation can deliver benefits only with a combination of process re-engineering, enabling technology, and an organizational structure that can support both. We believe the following four key technology building blocks are mandatory for an automated enterprise:
- Business rule engine: Business rules describe the structure, operation, and strategy of an organization’s business process. A few key people in the organization enforce business rules, typically captured in policy and procedure manuals, customer contracts, supplier agreements, and so on. That manual decision making proves error-prone and inconsistent. In legacy environments that support business processes, rules encoded inside the application can be expensive or difficult to change. A business rule engine lets you separate application code from business rules, maintain rules in a central/shareable repository, and promote consistent decision making. Such an engine proves central to any automation solution.
- Application integration platform: Automation implies that manual processes will make way for system processes, which in turn implies that the systems that help realize a business process can seamlessly communicate and exchange information without manual intervention. That requirement calls for a strong application-integration platform that supports multiple communication protocols and data semantics between systems.
- Workflow engine: In typical business scenarios, including the risk management example we saw earlier, automation needs some manual processes on an exception basis. For example, if a rule engine cannot establish the credit worthiness of an applicant based on the rules defined in its repository, someone must take a second look. Workflow engines enable a smooth hand-off between systems, between people, and between systems and people.
- Common data interchange standards: To lower costs through automation over the long term, enterprises need a common, XML-based data interchange standard that reduces development and maintenance efforts.
In this article, we focus on a J2EE-centric automation solution built around the business rule engine component.
Elements of a business rule engine
Let’s examine the rule engine elements common to most commercial products such as Blaze Advisor, ILOG JRules, or Expert Shell technologies such as Jess.
Figure 3 introduces the three common rule engine elements.
The first element, the rules repository, contains the domain knowledge coded in the form of rules. Developers generally write rules in a high-level business language that relates to the domain, storing the rules in the repository in a compiled form to enhance performance. Both the rule engine and the rules authoring tool employ the rules repository.
The second element, the rule engine core implementation, consists of:
- Rules management module: Accesses the repository and loads the correct rules-set into the engine.
- The agenda: Tracks the prioritized rules selected by the inference engine during the pattern-matching logic cycle.
- The working memory: Contains the current state of facts that led to the current rules in the agenda.
- Execution context module: Represents the runtime environment for the inference engine’s execution. During the inference engine’s execution cycle (logic cycle), an execution context would hold a physical grouping between a specific instance of the agenda and the working memory. More than one execution context can simultaneously exist and share the same rules-set.
- The inference engine: Puts rules into the agenda based on the facts in the working memory. If a rule executes, then adds more facts, those facts become inserted into the working memory, then are used later to match more rules until the logic cycle’s end, where no more rules can be matched with facts from the working memory.
The third element, the rules authoring studio, is the user interface with which to input rules to the repository. Most currently available rules engines include a rules editor to compose rules in a high-level rules language that usually includes syntax checking. Testing and debugging functions let the user build test scenarios to simulate the rules’ effects in a real environment.
Architecture
Now that you understand process automation and business rules, let’s see how and where a rule engine fits in an automated enterprise.
J2EE as an enterprise-application architecture foundation
In this article, we employ J2EE as the as the component architecture, but the general ideas apply to other environments, such as CORBA. J2EE today represents the preferred platform for building open standards-based, multitier, server-centric applications. The J2EE 1.4 specification introduces new APIs that implement core Web services protocol stacks, new management and deployment APIs, new JavaServer Pages (JSPs), Enterprise JavaBeans (EJB), and Java Connector Architecture (JCA) API versions, and provides a robust service and integration platform. For enterprises employing J2EE as their foundation platform, the road to automation can start with Figure 4’s application architecture.
In Figure 4, notice:
- The architecture follows industry best practices as outlined in Sun Microsystems’ “Sun Java Blueprints for Enterprise“
- You can expose the business rule engine (and other middle-tier components) either synchronously (with Remote Method Invocation (RMI)) or asynchronously (with Java Message Service (JMS)) to Web applications needing decision support
- The integration layer uses JCA for legacy system integration and, as mentioned above, JMS for asynchronous communication
- By isolating the core business services from the supporting automation infrastructure, you can reuse them in a manual context
Rule engines and J2EE
Let’s see how to integrate a business rule engine within a J2EE enterprise to build business automation applications. We’ve based the architecture (Figure 5) on the Model-View-Controller (MVC) design pattern. Within MVC, we employ a Model 2 architecture in the view (Model 2 is a hybrid approach based on both JSPs and servlet technologies).
The architecture’s presentation tier handles the client interaction by abstracting the low-level protocol details into an event-based mechanism. The communication protocol employed can range from HTML over HTTP (Web-based thin client browsers), RMI over IIOP (Internet Inter-ORB Protocol) (Java Foundation Classes- (JFC) or Swing-based clients), or even XML over HTTP (SOAP (Simple Object Access Protocol)) for Web services (Web service client). In this article, we concentrate on the Web-based presentation tier based on HTML over HTTP.
The Business Object tier, known in J2EE as the EJB tier, has the application’s business logic implementation. The Business Object tier contains all the components that model the business, including the business rules that operate on them. The Web-based presentation tier propagates the user responses, which require changes to data, to the Business Object tier for processing in the form of events.
Finally, the integration tier implements the integration architecture with external engines.
You can deploy a business rule engine in two modes:
- As a standalone server that handles its own life cycle and low-level server architecture details such as threading, locking, and network connections
- As an embedded, J2EE-distributed component such as an EJB or servlet in which the container that hosts the component handles the low-level connectivity and threading details
The integration tier includes two main components, which give two levels of abstraction to the rule engine:
- The rules engine controller acts as an application-specific interface to execute business rules. The controller abstracts the implementation details of rule engine interaction including initialization, invocation, and removal through managing the lifecycle of the adapter contained inside.
- The rules engine adapter acts as an engine-specific interface to the rule engine proprietary APIs. The adapter abstracts those APIs from the rules engine controller implementation. The adapter handles the low-level details for initializing and communicating with the rule engine.
Using these two levels of abstraction, you can write code to interact with the controller without any dependency on the internal implementation. Moreover, you can make the controller itself largely independent from the rule engine’s internals or its deployment mode through the second level of abstraction as achieved by the adapter.
JSR 94: Java Rule Engine API
At the time of this article’s publication, JSR 94: Java Rule Engine API (Java Specification Request) was a Community Draft Ballot in the JCP (Java Community Process). When final, JSR 94 will define common APIs for basic rule engine operations, such as rules for parsing, adding facts to the working memory, and firing rules.
Figure 5’s adapter component defines an interface similar to what JSR 94 will define. When rule engine vendors implement the JSR 94 specification, you can drop this article’s adapter and move initialization to the controller.
The rule engine that could
In this article, you learned why many enterprises are implementing business process automation, the key business process automation technology components, and the role a business rule engine plays as an automation solution component. You also saw what types of business rule engines exist, where they fit within a J2EE enterprise, and how to integrate the business tier with a rule engine component.
In Part 2, we’ll delve deeper by detailing the integration tier’s internal design with the two aforementioned deployment options—standalone server or J2EE-distributed component—for the rule engine, as well as best-practice implementation methods. We will also cover emerging APIs and data interchange standards that enable more flexible solutions.
