** Under Construction
This explains how to leverage ABL in the context of Spring Data and STS. If you already have the prerequisites, you can install and run the demo in about 5 minutes.
Background: Data Access and Business Logic
In any database-oriented application, you must provide data access APIs to read / write your data, and business logic to ensure that data is properly derived and constrained.
provides Java-oriented APIs to read / write Domain Objects (POJOs - Plain Old Java Objects) to relational databases. This is an important advance over jdbc, providing key features such as POJO-based access
(as distinct from clumsy string arrays used by jdbc), and relational mapping
, so your POJOs can utilize Java features such as inheritance).
Hibernate is fine for many applications, but there are many cases where you wish to hide the Hibernate APIs, for example for discoverability, or to enable your application to be retargeted to noSql engines. Spring Data
provides an excellent approach wherein simple interface definitions generate Repository Objects that present a pure Java api for data access.
But you still must implement the business logic, which presents issues that directly affect business agility and TCO:
- Time: logic is built manually, without automation tools such as UI frameworks. So, the 5 simple requirements shown here result in 500 lines of code. Rete-based Business Rule Engines don't provide active enforcement of logic, and deal poorly with aggregates (sums and counts).
- Complexity: debates persist - Anemic Domain Objects? Services Layers? Logic-enhanced Domain Objects? Data Access Objects?
ABL is designed to enable you to build your business logic with competitive advantages in agility, TCO and transparency, operating as follows:
- Familiar annotations declare multi-table logic, somewhat like spreadsheet formulas. Annotations are powerful (each representing 100+ lines of code), yet so simple they are transparent to both IT and Business Users. Annotations address over 95% of your logic, and you can use Logic Methods to address more complex requirements.
- The ABL Logic Engine plugs into Hibernate events - since you don't directly call the logic, you do not need to recode your application, and integrity / re-use is assured. The engine automates multi-table execution order based on dependencies, so that development cycles and maintenance simple entail simply changing the logic, without the tedious archaeology to decipher existing code.
This short tutorial illustrates how you can utilize Spring Data for pure Java API, and use ABL declarative annotations for complex, multi-table business logic.
This tutorial presumes a basic understanding of Hibernate/JPA and Java. It does not presume a strong background in STS or Spring Data.
- You will need SpringSource Tool Suite (STS), as explained here. STS is an extended version of Eclipse, which includes elements required for this demo.
- You also need to verify proper operation of Spring Data, as described here.
Install and verify the demo as described below.
Create a folder for the workspace:
BusLogicDemo Spring Data WS
We'll use this in the steps below.
BusLogicDemo Spring Data project
Download and unzip the
BusLogicDemo Spring Data (use the download arrow link at the bottom of this page) into the folder created above. You will get a folder with the same name as the zip
, as shown in the diagram below.
BusLogicDemo Spring Data Project
- Open the workspace
BusLogicDemo Spring Data WS in STS
- Import > Existing Maven Project > BusLogicDemo Spring Data project from the previous step
- Important: you may encounter errors - correct them as described under the previous Prerequisites section.
Use the diagram below to confirm your folder structure (this screen shot was taken after the project import, which creates the
Verification: Run the jUnit Test
To run the jUnit test, right click on
BusLogicDemoBasic, and select Debug as > Junit test. It should pass.
However, it currently fails as shown below, since the autowired simpleCustomerRepository returns null. I suspect the repository is not using the existing
em, so is using a new, empty database. This sample was adapted from the existing BasicSample, all of whose artifacts are currently still included for ease in comparing.
How the Project was built
The sub-sections below describe how the project was built.
Defining the Repository Object
The steps to build the Repository object were:
- Define the interface (
SimpleCustomerRepository) that specifies the NamedQuery. It extends Spring-supplied
CrudRepository to inherit definitions of methods such as
save(), used above in the jUnit test
- Register the base packages in
- Standard JPA Domain Objects (here,
Customer), with the @NamedQuery annotation as shown below
Spring Data Magic
As you can see from the screen shot above, there is no implementation. The Spring Data services built the executable
SimpleCustomerRepository class from the interface definition. As shown in the jUnit code, this object provides executable implementations to read 1 / many Customer instances, and perform crud (create, read, update and delete) operations via discoverable Java APIs.
Since these crud APIs ultimately invoke Hibernate APIs, the business logic engine plugs into Hibernate to execute the business logic per the annotations you supply in the
classes as summarized here