home‎ > ‎

Evaluation Guide

ABL Evaluators can use this page to get a quick sense of what ABL does, its value proposition, and how it differs from other alternatives.

What problem does ABL address?

Transactional Business Logic is important - often half the app for update oriented database applications.  And there are issues that directly affect business agility and TCO:
  • Time: logic is built manually, without automation tools such as UI frameworks.  
  • Complexity: debates persist about the basic architectural approach - Anemic Domain Objects? Services Layers? Logic-enhanced Domain Objects? Data Access Objects?

What is ABL?

Developers use ABL to define simple annotations for business logic, which are enforced by the ABL runtime engine by plugging in to Hibernate/JPA events.  ABL is for transactional logic, so is complementary to Rete-based Decision Rules and Process Engines.  It does require the use of Hibernate/JPA.

What is the Value Proposition?

There are a number of approaches for "simple" business logic such as JSR-303 to ensure fields are not null, conform to specified values, etc.  But this is not the source of the labor and complexity.  Instead, we need solutions for complex, multi-table business logic - not just multi-field/multi-table constraints, but more importantly, multi-table derivations.

To communicate the value as simply as possible, we defined a database with complex logic that rolls up Line Items amounts into a Purchase Order and Customer (see the "cocktail napkin spec" below).  Such a database involves many Use Cases over which the logic must apply.  

And then we built it:
  • A conventional approach requires 500 lines, mainly due to addressing dependencies (what changed?  what depends on that?).  You can have a look at the actual code here, or review the in-depth description here.

  • The Automated Business Logic approach requires just 5 annotations shown below - which address all the Use Cases.
So, 500 lines vs. 5 annotations - ABL reduces effort by 2 orders of magnitude, is dramatically simpler, and continues to provide agility in maintenance.    And they're simple enough to be transparent to Business Users, enabling a new era of partnership between IT and the business.




What about Real World complexity?

The example above is designed to communicate the point as simply as possible.  But of course, your application will likely contain more complicated requirements, so it's important to understand whether these are addressed. 

ABL automates Advanced Examples with remarkable power, including
  • A Bill of Materials Price Rollup with 4 rules (a bolt is used in a Wing, Engine, etc - how does a price change affect the cost of a plane?)
  • A Bill of Materials Part Explosion with 3 rules (how many bolts remain in stock after building n planes?)
  • An Allocation of a Payment to a Customer with 4 rules (which Purchase Orders are paid off, and what is the resulting balance?)
  • Copy examples, such as auditing or cloning a Purchase Order and its Line Items

What does it take to get started?

Very little - update your HIbernate configuration, add the jars and you are ready to define logic.  You can start very simply, for example with constraints or auditing.

Note you can introduce ABL into existing code, since plugging into Hibernate events means you don't directly call ABL, yet your logic is enforced.

What about Architectural issues: performance, extensibility, debugging?

Multi-table logic is optimized to reduce and eliminate SQL operations.  Logic is extensible and debuggable using conventional Java/Groovy approaches.  It does not interfere with decisions regarding a Service Layer - in fact, it can make your service layer thin by factoring out complex multi-table logic.

Quick Links

You can explore the following links:
Comments