Transaction Rules Rule

Mar. 12, 2002 12:00 AM

One of the primary uses of Enterprise JavaBeans (EJBs) is to free developers from routine infrastructure issues such as distribution, security, and persistence so they can concentrate on business logic. This recognizes that the truly valuable part of an application is the set of data and control flows that implement its business functions.

The WebSphere Application Server (WAS) has supported EJBs since version 3.0. Placing the business logic of a WebSphere application into the EJB layer should allow the logic to be centralized, understood, reused, and maintained more easily. In theory at least, leveraging EJB container services should simplify development and greatly improve programmer productivity.

The reality is usually very different. Many organizations have discovered that delivering systems with this layered architecture is a challenge. In their report, “Putting J2EE to Work,” Forrester Research concludes that most organizations will face a bumpy adoption road that won’t be fixed by advances in the J2EE specification. For EJBs, the difficulties include a steep learning curve, the complexity of designing for both flexibility and performance, and the relatively low-level Java language used to implement business functions.

All this points to the need for another approach that specifically addresses the development and management of business logic in WebSphere applications. According to Forrester, this approach would automate away complexity, so developers “never have to know or care that EJBs require six different deployment files.”

An approach using declarative logic, also known as rules, to specify transaction business logic is delivering a high degree of EJB automation for J2EE application servers such as WebSphere.

Automated Business Rules
Within the software industry, the term “rule” is defined quite broadly. IBM’s MQSeries uses routing rules to direct messages; WebSphere Personalization uses parameter-driven rules to control content delivery; finally, an expert system uses inference rules to make complex decisions.

To clarify our discussion, the rules used to automate EJBs are transaction-logic rules. Rules expert Barbara von Halle explains that such rules are data-change–oriented, which means that they execute when the data to which they are attached is touched.

Specifying business logic through rules has many benefits. First, because a single rule can control the behavior of a whole set of objects, rules are much more productive than procedural or even object-oriented languages. Next, because they are centralized and easy to understand, rules can be located and changed quickly. Finally, because they are unambiguous and self-documenting, rules become a tool for communication between users, analysts, and developers.

Rule-based specifications, of course, only begin the business logic automation process; for the specifications to be useful, they must be executable. That is, they must be turned into a set of business objects whose sophisticated interactions can be driven by changes to data values. This is done through a transaction logic “server” or “engine.” The engine is typically installed in an EJB container within the WebSphere application server.

In addition to executing rule events, a transaction logic engine may also provide other services to improve the performance and manageability of rule-based logic. Ideally, these services would include:

Optimizations for chained and intra-object logic
A prebuilt framework for fast client access to sets of business objects
Tools to trace rule execution and monitor logic statistics

An Application Example
P> The IBM Redbook, Application Development Using Versata Business Logic Automation for WebSphere, shows how transaction logic rules can be used to implement the business logic in a well-known application, IBM’s Trade 2 application performance benchmark.

Trade 2 has a sophisticated Model-View-Controller architecture that simulates an online stock brokerage. Its functionality includes buying and selling stock “holdings.” By default, the business logic in Trade 2 is implemented in EJBs.

Using Versata, the Trade 2 EJBs are automated using rules. In addition, the Trade 2 business logic is extended to include additional functions, such as controlling margin selling, selling partial holdings, and charging personalized commission rates.

The model of the rules-extended Trade 2 application has five core business objects, described as:

Account: The user ID, cash balance, and number of transactions
Profile: Descriptive information about the account
Quote: Stock symbols and prices
Holding: A block of stock purchased by an account
Transaction: Individual buy and sell transactions against a holding

The next section uses the Trade 2 object model for its examples.

Classification of Rules
Over the years, there’s been considerable analysis of the types of rules needed to specify application business logic. The classification below is largely based on the 1995 GUIDE Business Rule Project (see Fig.1).

Relationship rules specify associations between entities. Rather than controlling transaction behavior itself, they enable other rules to be designed and enforced.
Derivation rules are algorithms that derive attributes from other attributes. Typically, derived attri-butes can be persisted or nonpersisted (in which case they represent runtime-only values.)
Inference rules use one or more truths to arrive at a new truth. The new truth usually derives an attribute.
Constraint rules specify the policies of a business. They govern under what conditions operations can proceed.
Action rules initiate another business event, message, or activity based on some condition.

Relationship Example:
Relationships typically imply a parent-child association between entities, although they can be used for more complex models. An example of a simple relationship is:

“An Account Has Holdings.”

Relationships are the foundation of many rules, and transaction logic servers can automate many operations between related entities. For instance, through the relationship described above an Account can automatically count and sum all of its related Holdings. Holdings can automatically check for sufficient funds in the related Account. Furthermore, as they are entered, Holdings can automatically check to ensure they are associated with valid Accounts.

Derivation Example
Derivations are computational, which means that a formula determines the value of an attribute. An example is a rule for a Holding that says

“QuantityOnHand = QuantityPurchased – QuantitySold”

In addition, computational derivations can use the attribute values from several objects in computations. An example of this is a rule for selling a stock that says

“The Transaction Amount is the Transaction Quantity multiplied by the Price (from the Quote object) navigated to through the related Holding object”

Leveraging its relationship rules, the transaction logic server can automatically navigate to other objects to retrieve attribute values. A logic server will typically have a GUI for building rules.

Inference Example:
Inference rules can be thought of as a specialized type of derivation, where an attribute is derived from a truth. An example is a rule that says, for an Account,

“AccountType is wholesale if the Balance is greater than $500K.”

Like computational derivation, inference derivations can chain together evaluations and calculations from several entities. It’s possible, for instance, for a rule to say for an Account,

“An AccountType is wholesale if the Account Balance is greater than $500K (Account object) AND the number of ActiveHoldings is greater than 20 (Holding object) AND the average TransactionSize is > $10K (Transaction object).”

Constraint Example
Constraints define legal states in the system. For transactional systems they define legal values of data that are allowed to exist. A rule to restrict (constrain) margin selling defines one such state. It says, for Account

“Balance can’t be less than zero”

Although it sounds simple, this constraint shows the power behind some logic servers. These servers can compile high-level, unordered rules into automatically sequenced chains of object interactions.

For instance, in the Trade 2 example, the following “Buy” rule-chain is constrained by the margin-selling rule above. When buying a stock:

1. The Logic Server begins to create a new Holding for this Symbol, Date, and Quantity.

2. It gets the stock’s price from the associated Quote.

3. It begins to insert an initial “Buy” Transaction object .

4. It calculates the cost of the stock (multiply Price by Quantity).

5. It determines the Commission (by checking the Account entity to see whether the AccountType is a wholesale or retail account, checking the current CommissionRate for that Account Type and multiplying the CommissionRate by the Transaction Amount).

6. It calculates the total Transaction Amount.

7. It begins to update the Transaction Count for this Holding.

8. It begins to debit the Account Balance with the Transaction Amount.

9. Finally, it encounters the constraint.

10. If the constraint is violated (if the new Balance would be less than zero)

11. It unwinds the entire operation (rolls back changes to the Holding, Transaction, and Account objects).

In addition, to optimizing performance, a logic server may be able to bring all the objects needed for a transaction chain into a transaction cache, so the entire chain can be processed with a single database I/O.

Action Example
The final type of rule is an action rule, more completely called an Event/Condition/Action. The Event is the operation and entity being watched by the logic server. The Condition must be met in order to proceed. The Action is the result that should occur if a condition is met: An example of this is a rule that says,

“When adding a new Transaction, if the TransactionType is ‘sell,’ credit the related Holding’s related Account Balance.”

Typically, a transaction logic server will implement this with a rule “listening service.” The logic server will receive the event when all other rules leading up to this event/condition have evaluated “true.”

Extending Rules with Java
The Event/Condition/Action example above demonstrates a key requirement for a rules system – extensibility. The rule has been extended with a custom Java method “credit”.

While transaction logic rules are estimated to cover more than 90% of application business logic, any automation approach must address the remaining requirements. Extensibility can be provided in many ways: for instance, the rule system can:

Surface its underlying classes so that the Java developer can subclass and extend them

Provide predefined extensibility points, for instance through predefined events, where custom Java code can be inserted

Allow rules to call methods from custom Java components to control rule behavior

Combined, these extensibility options should allow the developer to use a rule-based approach for almost any transactional application.

Application Use of Rules
Another way to look at rules is by application function. Here are just some of the common uses of rules that can have a big payoff for WebSphere applications.

To Automatically Sequence and Optimize Transactions
One of the most common patterns coded into EJB logic is the getting and setting of attributes in multiple objects within the scope of transactions.

The Trade 2 application “Buy” function is a simple example. Given a UserID, stock Symbol, and Quantity, the Buy operation:

Finds the related Quote using the stock’s Symbol
Checks that the Quote is valid and gets its Price
Finds the related Account for that UserID
Checks that the Account is valid and gets its Balance
Creates a Holding and checks to see that this succeeds
Debits the Account Balance

A 32-page session bean implements this (and other) logic in the original Trade 2 application. The automated logic demonstrated by Versata replaces the hand-coded Java with four rules.

For Data Validation
Validation is frequently overlooked when estimating the amount of business logic in an application; its design and development consumes costly programming resources. Moreover, validation (and related error handling) code is usually sprinkled throughout various client-tier and logic-tier components. This makes logic difficult to reuse and maintain.

Rules allow data validations to be attached to objects directly, as part of their metadata. Using rules to specify attribute validations has several benefits. First, validations, like all rules, will be applied consistently across all applications. This increases system integrity.

In addition, validation metadata, like other rule-based metadata, can be accessed through object methods. This makes it possible for client components to derive their behavior from business entity metadata. This extends the use of the Model in the Model-View-Controller architecture and could allow client components to adapt automatically to changes in business logic.

For EJB Referential Integrity
Referential integrity addresses the need to maintain consistency between one business object and all the other objects that refer to it.

In applications where all data is kept in the same relational database, enforcing referential integrity can be left to the database management system. If, however, there is the potential for data to come from more than one source, integrity must be assured through application code. In J2EE applications, the place for this code is in EJBs. (Whether it should be placed in the parent entity EJB, the child entity EJB, or in a third, session EBJ, is frequently debated.)

Rules provide an easy and consistent way to enforce relationships and integrity, even between objects in different databases or legacy applications.

For Ad Hoc Object Queries
Since rule chains frequently must find other objects by attribute name or value, the transaction logic server automatically implements a complete set of “finder” methods for objects and relationships. These methods may be available to developers, either directly through EJB remote interfaces or through APIs.

For instance, the Versata client library provides a JDBC-like API to submit ad hoc queries against objects, including objects that are joined from multiple entities. The libraries deliver optimized ResultSets of serialized “rows” of objects with client navigation (first, next, last) as well as buffered reads and saves. This simplifies client development and automatically provides the performance found in J2EE best-practice patterns such as value objects and value-object lists.

To Initiate Asynchronous Events
Events/Action rules integrate the automated system with external applications. Events initiate exception processing. Although Trade 2 is an entirely synchronous application (transactions are committed or rolled back immediately), most enterprise systems have some asynchronous operations, such as putting a message on a message queue.

Rules watch data changes and can initiate synchronous transactions or asynchronous events based on those changes.

Beyond Transactions to Processes
Beyond transactions, which are typically short-lived interactions with applications or services, lie processes. Processes typically involve a whole series of interactions that span systems, people, and time. Processes can be automated by their own set of specialized rules and engines.

A future article will examine the natural evolution of rule-based WebSphere applications into sophisticated process-driven systems.

Resources
GUIDE Business Rule Project: www.businessrulesgroup.org/first_paper/ von Halle, Barbara, Building Business Rule Systems, John Wiley & Sons, 2001.

WebSphere Performance Benchmark Sample (Trade 2 Application): www.ibm.com/software/webservers/appserv/wpbs_download.html

Application Development Using Versata Business Logic Automation for WebSphere: www.redbooks.ibm.com Koetzle Laura, "Putting J2EE to Work," Forrester Research, July, 2001.

Related Links

▪ Figure 1

▪ Figure 2

About Jackie McAlexander