Java.next -- Four languages that represent the future of Java
Blogger Stuart Halloway has begun a series of posts on trends that point to the future of the Java platform. In his first post, he compares Clojure, Groovy, JRuby, and Scala -- four wildly different languages that nonetheless all play together in the JRE. Find out what unites these languages and what they can tell us about the future of Java-based development ...

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Business process automation made easy with Java, Part 1

Implement business rule engines in a J2EE enterprise

By Ahmed Abulsorour and Siva Visveswaran, JavaWorld.com, 09/06/02

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:"



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.

Figure 1. Manual risk-assessment process



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.

Figure 2. Automated risk-assessment process



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.

Figure 3. Elements of a business rule engine



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.

Figure 4. An automated J2EE enterprise 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).

Figure 5. J2EE rule engine architecture



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.

Resources