This summarizes Automated Business Logic: what, why, how, and for whom. In particular, it provides an overview of how you can optimize the use of Business Logic over your project life cycle.
What is Business Logic?
Business Logic is the processing you execute on save/submit:
These are the most obvious elements of business logic - multi-attribute, multi-table expressions that prevent bad data from being committed into the database. For example, you might want to ensure that the customers' balance does not exceed their credit limit.
The most challenging element is derivations, since these are typically chained (dependencies require detection and properly ordered change propagation), and multi-table (so performance-sensitive). For example, you might want to compute the customers' balance by summing their order totals, in turn derived from the Line Item amounts.
Actions include auditing, copying, messaging, business process initiation, etc. Ideally, these are generic, so they can be re-used over multiple Use Cases and Domain Models.
Such logic should be architected so that it encapsulates domain access, automatically shared over all User Interfaces and Message-based transactions. In interactive applications, it is the logic that must be executed in with save/submit operations. In addition to the classic example on the home page (summarized in the following section), you can see several examples in the Tutorial.
Automated Business Logic addresses only save (transaction) processing. It complements other familiar forms of business logic such as presentation logic (data retrieval / update processing, screen flow), Business Process Flow, or Decision Logic commonly associated with Rete engines. It complements Enterprise Integration packages for data exchange.
What is Automated Business Logic?
Automated Business Logic is a "logic engine" that plugs into Hibernate, and executes declarative (spreadsheet-like) logic you supply in companion classes that correspond to your POJOs. This encapsulates your business logic, while leaving Hibernate interfaces and POJO objects unchanged. You gain agility and transparence due to elimination of 90% of your business logic code, since the engine automates the "when/how" of conventional coding.
This sample problem (Customers, Orders and Parts - shipped in the download) is a simple way to illustrate the use and operation of business logic. The requirement Customer's balance may not exceed their credit limit is addressed as follows:
Far beyond simple single-attribute validations, the requirement is multi-attribute constraints, such as this Customer Constraint:
Constraints are the most familiar form of business logic, but derivations and actions are the most valuable, per dependency / re-use automation noted below. Derivations here include multi-table derivation rules such as
Customer.balance = sum(order.total where paid = false)
- Derivations are multi-table, as in the example above
- Derivations can chain, both to constraints, and other derivations:
Order.total = sum(Lineitem.amount)
Lineitem.amount = quantity * partPrice
Lineitem.partPrice = copy(Part.price)
- Chaining, ordering and dependencies are automatically handled (logic is declarative, somewhat similar to a spreadsheet)
- Derivations can include if/else logic, state transition logic, and reference related data
For more information on rules:
- Core Rules: a quick summary of all the core rules with link to their detail descriptions
- Extensibility: Click here to see how to extend the Rules
- Tutorial: uses a Case Study approach to illustrate how rule utilization
Why do I need Automated Business Logic?
The logic of Business Logic:
- Business Logic is 50% of the Build Phase
- Within Business Logic, a key need is multi-table logic (sums, counts, references to related parent data)
- Such needs are poorly addressed by
- Rete Business Rule Engines that perform poorly, and do not assure integrity
- Manual code requiring significant code expansion that is neither agile nor transparent
- Business Logic addresses multi-table logic using simple business expressions
- replacing 10 pages of code with 5 business-oriented rules, providing substantial agility and transparency to Business Users
- executing with Enterprise-class performance optimizations for SQL elimination/minimization
How does Automated Business Logic affect my project life-cycle?
Business Logic Overview
The sub-sections below illustrate the use of Business Logic over the life-cycle of your project:
- Analysis: uncover Business Logic Requirements by adding rigor to current process
- Design: automated by chained formulas - like a spreadsheet
- Development: declare 7 rules instead of 10 pages of code
- Execution: the Business Logic Engine minimizes/eliminates SQLs
- Maintenance: automated re-use, re-ordering and re-optimization - just change the rules
Use your existing methodology to uncover Business Processes and Use Cases. Automated Business Logic can enhance this process:
Logicdoc: requirements capture
provides a mechanism to capture the Use Case Requirements, with traceability to the Business Logic that implements them. This information is published through Javadoc (like this
), with special services to enable Business Users to read the relevant business-oriented sections (like here
Alert: excessive design detail
- In particular, watch out for extended pseudocode which simply expands on Business Logic automation services.
- Be aware that Automated Business Logic services eliminate many key elements of design, such as delineating the individual Use Cases for adjustment.
- Extension services (such as allocation) introduce concepts that can significantly increase the level of abstraction in team communications.
Design Automated by Chained Formulas - like a Spreadsheet
Unlike procedural approaches where there are very complex design decisions (re-use, ordering, partitioning, and optimization, etc), Automated Business Logic automates these elements of design. It does so by applying the metaphor of a spreadsheet to business logic, as described in the sub-sections below.
Design Process: familiar step-wise definition of terms
To nail down the understanding of the Check Credit Requirement, an Analyst might
- Have the the following conversation with a Business User in the course of elaborating the Check Credit requirement (left column), and then (perhaps afterward)
- Specify the Logic that implements the requirement (right column)
Check Credit Design Process - stepwise definition of terms
|Analyst / Business User Dialog
Captured in Logicdoc
|Resultant Business Logic
Is Executable: replaces 10 pages of code
|What does it mean to Check Credit?
- Balance can't exceed Credit Limit
customer.balance < customer.creditLimit
|What is the Credit Limit?
- Entered by the Sales Department
- (Assure Data Model contains this attribute, and that an Application exposes it to the Sales Department)
|What is the Balance?
- Sum of the unpaid orders marked "ready" by the user
customer.balance = Sum(orders.amountUnPaid where isReady)
|What is the AmountUnPaid?
- Discounted amount - amount paid
purchaseorder.amountUnPaid = purchaseorder.amountDiscounted - purchaseorder.amountPaid
|What is the discount amount?
- Platinum customers get a 5% discount off the total
purchaseorder.amountDiscounted = purchaseorder.amountTotal
if (purchaseorder.customer.creditLevel == "P")
purchaseorder.amountDiscounted = purchaseorder.amountTotal * 0.95
|What is the AmountPaid?
- Let's defer that until we discuss Make Payment, later in the Order Process
|What is the AmountTotal?
- The total of all the Lineitem Amounts
purchaseorder.totalAmount = Sum(lineitems.amount)
|What is the Lineitem Amount?
- Quantity Ordered * Part's Price
lineitem.amount = lineitem.qtyOrdered * lineitem.partPrice
|What if the Price changes after the PO?
- Ah, right, customer gets the original price
lineitem.partPrice = ParentCopy("Part.price") // no cascade
We have denoted the rules in the right column. As you can see, Business Logic solution closely matches the detailed statement of the problem: an Executable Design.
Optionally, as further explored in the Place Order Detail Description, you can preserve this analysis discussion in your Logicdoc generated documentation:
The first key concept of spreadsheets is that you don't write code, you declare formulas. As illustrated in the table below, Automated Business Logic uses the same declarative metaphor, and provides analogous execution automation for ordering and change propagation.
|In a Spreadsheet
|In Business Logic
|Define cell formulas:
cell A = sum (column B)
|Define Domain Object attribute formulas
Customer.balance = Sum(order.amountUnpaid where isReady)
- Note: to address a database of related tables, these formula are Multi-table.
|From this, the spreadsheet "knows" that
- adjust A when B elements are inserted, updated and deleted
|The Business Logic Engine "knows" to automate the transaction processing
Orders are inserted, updated and deleted and updated (reassigned to different customers, paid, etc)
Forward Chaining: automatic multi-table dependency management
Spreadsheets can express enormously complex problems - without programming - because they support what Computer Scientists call Forward Chaining: formulas can depend on each other.
So, you alter a cell, and its effects ripple through the spreadsheet. This is not a simple process, since the spreadsheet must determine a dependency-based execution order to get the correct answer.
The same ordering issue exists in Automated Business Logic, but now both within a row and - much more significantly - between rows.
The sub-sections below briefly examine the specific cases the Business Logic Engine must address to automate multi-table transactions (observe: all such Forward Chaining in executed in the context of a Hibernate transaction).
The Dependency Analyzer of the Business Logic Engine examines every Formula, and orders their execution with respect to their dependencies. This addresses within a row; the following sections address between rows.
Child Aggregate Adjustment
Customer.Balance rule involves two related parent/child Domain Objects.
As described in Business Logic Execution triggered by Child changes, changes to child attributes are analyzed. If (and only if) any attribute is changed that is part of a declared Sum (a summed attribute, a Foreign Key, any part of the Qualification Condition), the system:
- Adjusts the Parent Sum
- Forward Chains to execute Parent Business Logic (other Derivations, Constraints, etc)
This process can chain. The example above automates a conventional multi-table transaction involving Customer, Purchaseorder, Lineitem and Product.
Parent Reference Cascade
PurchaseOrder.AmountDiscounted rule also involves 2 tables with the
Customer.Level parent reference. The Business Rule Engine's Dependency Analyzer detects all Parent References from child Domain Objects.
If (and only if) Parent Referenced attributes are changed, the Business Logic Engine will Forward Chain to each referencing Child instance so that it can re-evaluate its Business Logic in light of the new data. This is called Cascade processing.
Constraints and Actions
The key point is that all derivation changes trigger automatic constraint / action processing. This is most common logic pattern, and the core of virtually every representative example. It is also the reason why simple constraints/actions - that do not address multi-table derivation results - fall quite short.
Referring again to the Design Process table above, we emphasize that the right hand column is fully executable. The system is responsible for all the activities usually meant by design:
Development: Declare Business Logic
Once your Analysis process has identified the rules, you declare them as follows:
Declaring Business Logic
|To declare Business Logic:
- Create a Java/Groovy Business Logic Component
- This is a class that corresponds to a Hibernate-managed Bean (Domain Object)
- The Logic Engine provides access to current/old values, and Logic Context
- Create a method for the Business Logic Rule (identified by Annotations)
- Your component can contain other methods
- Your Business Logic can reference these and other Java/Groovy services
The Check Credit example above illustrates how just 7 Business Logic Rules can replace 10 pages of code. Even if you think you can code and debug 1 page per day, the agility of automation is overwhelming.
Power through Open Declarative Business Logic
Your Business Logic is fully declarative: the Business Logic Engine is responsible for Ordering, Re-use and Optimization. You can declare your rules in either Java, or Groovy which provides a more natural syntax and automatic type. You acquire power at two levels:
Declarative Business Logic addresses complex logic
The Check Credit example is a typical transaction in terms of complexity. The Business Logic Rules scale to truly complex transactions, as shown by the fully worked / described examples in the Tutorial (full implementation is shipped with the product):
- Computing a Bill of Materials Kit Price, based on the transitive closure of all the components (and sub-components) of the kit
- Exploding a Bill of Materials on Place Order, so inventory reflects the remaining stock for the transitive closure of all the components (and sub-components)
- Cloning an Order (a deep copy)
- Computing a Department Budget, reflecting the transitive closure of all the sub-departments (and sub-sub Departments) budgets
- Placing a Payment, allocating to all the outstanding orders, oldest first
Most Business Logic specifications are simple spreadsheet-like expressions:
Beyond such expressions, significant additional power is provided by Open Business Logic: your logic can invoke Java/Groovy methods. You can use existing Java/Groovy methods, or utilize Extensibility. This enables your organization to use/build a library of re-usable logic services such as date functions, or completely new Business Logic Rule Types such as allocation or copy. The latter are shipped with the product, both for your use, and as illustrations of how to build Extensible logic.
In addition to logic extensibility, the Business Logic Engine is architected for systems extensibility. You can supply your own factories to select the Business Logic Component for a Domain Object (e.g., PurchaseorderRetail vs. PurchaseorderWholesale). Events are provided so you can determine all the changes in a transaction. And, mechanisms are provided to accomodate your Hibernate extensions, such as configuration.
You do not directly invoke Business Logic with explicit API calls. Instead, the Business Logic Engine is registered as a Hibernate Event. When invoked, Business Logic Engine locates and executes the Business Logic Rules you define in Business Logic Components that correspond to each Domain Object.
Unlike Rete Business Rule Engines which require explicit invocation, this means that integrity is assured. Elective integrity simply cannot guarantee integrity if it depends on a programmatic call.
Automation invocation also means Business Logic easy to adopt: you can introduce Automated Business Logic with minimal impact on the rest of your system (even if portions have already been coded). As shown in the BusLogicDemo, you need not recode existing logic such as JSP - you simply
- Introduce your Logic classes
- Add a line to your Hibernate Config file
In addition, the engine provides services to eliminate migration of existing logic, so you can use Automated Business Logic for new logic, even in systems which previously used procedural business logic.
Automatic Partitioning promotes re-use and performance
It is sadly true that far too much procedural business logic winds up in client event handlers. This can interfere with re-use between screens, and makes the logic unavailable for message processing. It can also lead to performance issues, since network traffic can be increased by not centralizing the logic in the server.
Unlike manual approaches, Business Logic guarantees that the logic is partitioned for re-use and performance.
Execution architected for high performance
The Business Logic Engine is architected to Minimize/Eliminate SQL overhead.
- Pruning: the Business Logic Engine analyzes updates, and avoids parent access, adjustment and cascade when the referenced data is not changed
- Adjustment Logic: maintains aggregates with a single SQL
- Unlike Rete Business Rule Engines that load all the data into memory, or issue aggregate
Select sum queries, this assures optimal performance. This is particularly important with there are chained aggregates
Maintenance is a process that is reduces business agility, is expensive, and hated by developers. Declarative Business Logic can automate large portions of maintenance as described in the sub-sections below.
Re-use is a core development objective, requiring substantial design effort in procedural approaches to maintain critical database integrity. It is certainly not automatic. And it is critical for Compliance Assurance.
Business Logic, however, operates as an Event Handler, so active enforcement of business rules and re-use is automatic. This re-use occurs at the level of both code and design, as described below.
Code Re-use - over transaction source
Object oriented languages provide this re-use, by requiring all accessing code to use an objects' method. Hibernate events enable an analogous level of encapsulation with events.
Automated Business Logic employs these to assure that all Hibernate-based updates are subjected to the Business Logic you specify. Such automatic invocation guarantees integrity regardless of transaction sources (customers get the same answer regardless of the interaction):
- Interactive business logic is not required in page actions (controllers), avoiding the anti-pattern of business logic in page actions which cannot be used for message-based transactions
- Message-based - services automatically re-use the domain logic, so that services are thin.
Design Re-use - over transaction type
Even more powerful - and much less common - is encapsulation of not just code, but design intent. This arises since your logic is declarative: you declare what the effect should be, not how (the methods that implement it). The power of this is best illustrated by a deceptively simple example.
Customer.Balance rule, perhaps declared for Place Order, simply states that its value is the sum of the unpaid orders. It does not tie this to an algorithm, enabling the system to optimize with efficient approaches such as adjustment. Nor is the rule tied to a particular method (Use Case) - it's design intent applies to all transaction types.
This design intent is declaratively encapsulated into the Order Domain Object, so that it is automatically re-used over all these related transactions:
- Delete Order - the balance is reduced
- Pay Order - the balance is reduced
- Reassign Order to a new customer - new customer balance increased, old balance decreased (for unpaid Orders)
- All the various cases of Change Order:
- Change a Line Item Quantity
- Change a Line Item Part
- Add a Line Item
- Delete a Line Item
So, when you make a maintenance change to your logic, the system automatically reflects it in all the relevant transactions. This emergent behavior means you define rules for 1 transaction, but solve many transactions you might even have overlooked.
The core element of maintenance is the archeology to determine how the current code was ordered, so that new code can be merged without error. Business Logic eliminates this requirement, since the ordering is executed automatically the the Business Rule Engine.
Unlike traditional systems whose performance degrades with each patch due to time constraints, the Business Logic Engine always applies the performance considerations noted above. On every change. So just like SQL query optimizers confer the benefits of database improvements to all retrievals, Automated Business Logic provides continuous optimization of transaction processing.
In this way, Business Logic provides many of the same benefits that were introduced by relational database. Before it was available, programmers hard-coded index access strategies into their code. When subsequent use revealed the need for an index, it was typically impractical to recode all the programs.
Business Logic provides the same benefits for transaction processing that relational database did for data retrieval. For example, imagine a hand-coded system where the decision to make a sum transient was based on a slight miscommunication. That presumption might be build into a multitude of services.
It might not be until near the end of the project during load testing that the assumption was revealed to be false. The development team is faced with the unpleasant aspect of finding/re-coding all the locations where transience was presumed.
With Business Logic, you simply change the specification. The system will automatically revise transaction processing strategies from SQL to adjustment, just as a program based on relational data need not be recoded as indices are added/dropped. This applies the concept of data independence to transaction processing.
Agility comes from a number of sources:
- Build Phase: the code reduction from Complexity Management results in a several orders of magnitude reduction. This is often about half of the build phase of a project (the other half being screen development).
- Iteration / Maintenance: here the effect is not so much code reduction as design reduction. Every time you alter the rules, the system recomputes the execution order, the re-use tactics (assuring the rules are called for all relevant transactions), and optimization strategies. These take time, and in some cases ignored (e.g., performance often degrades over time due to the cost of re-optimization).
Automated Business Logic provides transparency in a number of dimensions:
- Logicdoc (illustrated above) enables you to capture your Requirements in Business User terms, and track the actual implementation into executable Logic. Business Users become partners in the development effort, making your Business Logic a true corporate asset.
- Logic Debugging provides a full Console of logic execution, with the option to use your IDE's debugger.
- Logic Console enables you to manage a deployed application: understand which logic is running, monitor its performance, etc.
Who uses Business Logic?
Business Logic can represent a corporate asset since it forms a language understandable to many groups within the organization:
- Developers: use Business Logic to displace Java code they currently must otherwise implement, so they are the main users.
- Application Developers specify the actual rules
- Systems Developers and Architects leverage the Extensibility services to extend the Rule Types, and integrate Business Logic into their architecture
- Business Users: as illustrated below, the Business Logic Rules provide transparency to the organization, particularly when present in the context of PURL
- Managers: can also quickly inspect the implementation in ways that are impractical with code
- Business Analysts: can use Business Logic to document the Requirements in such a way as to facilitate the ensuing implementation
Business Logic as a Corporate Asset
Automated Business Logic can become a true Corporate Asset:
- Automation confers Business Agility, in building and revising systems of high quality - a strategic business advantage
- Transparency represents a common language between Business and IT - congruence in business needs and IT systems
When: Next Steps
If you think Business Logic holds promise for your organization,